JP5016034B2

JP5016034B2 - 圧縮ベースＱｏＳのための方法及びシステム

Info

Publication number: JP5016034B2
Application number: JP2009516641A
Authority: JP
Inventors: エルスミス，ドナルド; ピーガルッシオ，アンソニー; ジェイナズィック，ロバート
Original assignee: Harris Corp
Current assignee: Harris Corp
Priority date: 2006-06-20
Filing date: 2007-06-14
Publication date: 2012-09-05
Anticipated expiration: 2027-06-14
Also published as: EP2036279A2; CA2655982A1; TWI360337B; US20070291751A1; TW200810476A; JP2009542114A; CN101491031A; WO2007149769A3; US8730981B2; CA2655982C; KR20090031741A; WO2007149769A2

Description

本開示による技術は、一般に通信ネットワークに関する。より詳細には、本開示による技術は、ＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）のためのプロトコルフィルタリングシステム及び方法に関する。

様々な環境で通信ネットワークが利用されている。通信ネットワークは、典型的には、１以上のリンクにより接続された２以上のノードを有する。一般に、通信ネットワークは、リンク上の２以上の加入ノードと通信ネットワークの中間ノードとの間の通信をサポートするのに使用される。ネットワークには、多数のタイプのノードが存在するかもしれない。例えば、ネットワークは、クライアント、サーバ、ワークステーション、スイッチ及び／又はルータなどのノードを有するかもしれない。リンクは、例えば、電話線を介したモデム接続、配線、イーサネット(登録商標）リンク、ＡＴＭ（ＡｓｙｎｃｈｒｏｎｏｕｓＴｒａｎｓｆｅｒＭｏｄｅ）回路、衛星リンク及び／又は光ファイバケーブルなどであるかもしれない。

通信ネットワークは、実際には、１以上の小規模な通信ネットワークから構成されるかもしれない。例えば、インターネットはしばしば、相互に接続されたコンピュータネットワークのネットワークとして説明される。各ネットワークは、異なるアーキテクチャ及び／又はトポロジーを利用するかもしれない。例えば、１つのネットワークは、スタートポロジーを備えたスイッチされるイーサネット(登録商標）ネットワークであるかもしれず、他のネットワークは、ＦＤＤＩ（Ｆｉｂｅｒ−ＤｉｓｔｒｉｂｕｔｅｄＤａｔａＩｎｔｅｒｆａｃｅ）リングであるかもしれない。

通信ネットワークは、広範なデータを伝送するかもしれない。例えば、ネットワークは、インタラクティブなリアルタイムの会話のためのデータと共に、一括ファイル転送を伝送するかもしれない。ネットワーク上で送信されるデータはしばしば、パケット、セル又はフレームにより送信される。あるいは、データはストリームとして送信されるかもしれない。いくつかの具体例では、データのストリーム又はフローは、実際にはパケットのシーケンスであるかもしれない。インターネットなどのネットワークは、ある範囲のノード間のものであって、異なる要求により膨大なデータアレイを伝送する一般的な目的のためのデータパスを提供する。

ネットワークを介した通信は、典型的には、複数レベルの通信プロトコルを伴う。ネットワーキングスタック又はプロトコルパッケージとも呼ばれるプロトコルスタックは、通信に利用されるプロトコル群を意味する。各プロトコルは、特定タイプの能力又は特定形式の通信に利用されるかもしれない。例えば、１つのプロトコルは、銅線により接続される各装置と通信するのに必要とされる電気信号に関するものであるかもしれない。他のプロトコルは、例えば、多数の中間ノードにより分離される２つのノードの間の順序付け及び確実な送信に関するものであるかもしれない。

プロトコルスタックの各プロトコルは、典型的には、階層により存在する。しばしば、各プロトコルはレイヤに分類される。プロトコルレイヤの１つの参照モデルは、ＯＳＩ（ＯｐｅｎＳｙｓｔｅｍｓＩｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）モデルである。ＯＳＩ参照モデルは、物理レイヤ、データリンクレイヤ、ネットワークレイヤ、トランスポートレイヤ、セッションレイヤ、プレゼンテーションレイヤ及びアプリケーションレイヤの７つのレイヤを含む。物理レイヤが“最下位”レイヤであり、アプリケーションレイヤが“最上位”レイヤである。２つの周知なトランスポートレイヤプロトコルは、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）とＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）である。周知のネットワークレイヤプロトコルは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）である。

送信ノードにおいて、送信対象となるデータが、最上位から最下位にプロトコルスタックの各レイヤに下っていく。他方、受信ノードでは、データは、最下位から最上位に各レイヤを昇っていく。各レイヤでは、データは当該レイヤにおけるプロトコル処理通信により処理されるかもしれない。例えば、トランスポートレイヤプロトコルは、送信先ノードにおける到着に対するパケットの順序付けを可能にするヘッダをデータに追加するかもしれない。アプリケーションに応じて、一部のレイヤは利用されず又は存在しないかもしれず、またデータは単に通過するかもしれない。

１つのタイプの通信ネットワークは、戦術データネットワーク（ｔａｃｔｉｃａｌｄａｔａｎｅｔｗｏｒｋ）である。戦術データネットワークはまた、戦術通信ネットワークと呼ばれるかもしれない。戦術データネットワークは、軍隊（陸軍、海軍及び／又は空軍など）などの組織内の各ユニットにより利用されるかもしれない。戦術データネットワーク内の各ノードは、例えば、各兵士、航空機、コマンドユニット、衛星及び／又はラジオなどを含むかもしれない。戦術データネットワークは、音声、位置測定情報、センサデータ及び／又はリアルタイムビデオなどのデータを通信するのに利用されるかもしれない。

戦術データネットワークの利用方法の一例は、以下の通りである。後方支援部隊が、戦場の戦闘ユニットのための供給を提供するため展開中であるかもしれない。当該部隊と戦闘ユニットは共に、衛星無線リンクを介し指揮所に位置測定情報を提供しているかもしれない。無人航空機（ＵＡＶ）が、当該部隊がリアルタイムビデオデータを取得し、衛星無線リンクを介し指揮所に送信している道路に沿ってパトロールしているかもしれない。指揮所では、アナリストがビデオデータを調べながら、コントローラが道路の特定セクションのビデオを提供するようＵＡＶに指示している。このとき、アナリストは、当該部隊が近づいている即席爆発装置（ＩＥＤ）を検出し、停止するよう部隊に直接的な無線リンクを介し命令を送信し、部隊にＩＥＤの存在を警告する。

戦術データネットワーク内に存在するかもしれない各種ネットワークは、多数の異なるアーキテクチャ及び特性を有するかもしれない。例えば、戦闘ユニットにおけるネットワークは、極めて低いスループットと大きな遅延により動作する戦場ユニット及び衛星との無線リンクと共に、ギガビットイーサネット(登録商標）ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）を有するかもしれない。戦場ユニットは、衛星と直接的なパス無線周波数（ＲＦ）の双方を介して通信するかもしれない。データは、当該データの性質及び／又はネットワークの具体的な物理的特性に応じて、ポイント・ツー・ポイント、マルチキャスト又はブロードキャストにより送信されるかもしれない。ネットワークは、例えば、データを設定から中継までの各無線を含むかもしれない。さらに、ネットワークは、広範囲の通信を可能にする高周波数（ＨＦ）ネットワークを含むかもしれない。例えば、マイクロ波ネットワークがまた、利用されるかもしれない。他の理由のうちで、リンク及びノードのタイプの多様性によって、戦術ネットワークはしばしば、過度に複雑なネットワークアドレッシングスキームとルーティングテーブルとを有する。さらに、無線ベースネットワークなどの一部のネットワークは、バーストを利用して動作するかもしれない。すなわち、データを連続的に送信するのでなく、断続的なバーストデータを送信する。これは、無線がすべての参加者により共有される必要がある特定チャネル上でブロードキャストしていて、１つの無線しか一時に伝送しないため、有用である。

戦術データネットワークは、一般に帯域幅制限される。すなわち、典型的には、所与の時点において利用可能な帯域幅より大きな通信対象となるデータが存在する。これらの制約は、供給を超える帯域幅の要求、及び／又はユーザの要求を満たすのに十分な帯域幅を供給する利用可能な通信技術がないことによるかもしれない。例えば、いくつかのノードの間では、帯域幅は毎秒キロビットのオーダであるかもしれない。帯域幅制限のある戦術データネットワークでは、重要性の低いデータがネットワークを占有する可能性があり、重要性の高いデータがタイムリーに伝送されず、又は受信ノードに全く到着しない可能性もある。さらに、ネットワークの一部は、信頼性の低いリンクを補償するための内部バッファを含むかもしれない。これは、さらなる遅延をもたらすかもしれない。さらに、バッファが一杯になると、データが欠落されるかもしれない。

多くの例では、ネットワークに利用可能な帯域幅は、増やすことができない。例えば、衛星通信リンクを介し利用可能な帯域幅は、固定されており、他の衛星を配置させることなく効果的に増やすことはできない。これらの状況では、帯域幅は需要を処理するため単に拡大されずに管理される必要がある。大規模システムでは、ネットワーク帯域幅は重要なリソースである。アプリケーションが可能な限り効率的に帯域幅を利用することが望ましい。さらに、アプリケーションが“パイプの詰まり”、すなわち、帯域幅が制限されているときにデータがリンクを圧倒することを回避することが望ましい。帯域幅の割当てが変更されると、好ましくは、アプリケーションは反応すべきである。帯域幅は、例えば、ＱｏＳ、ジャミング（ｊａｍｍｉｎｇ）、信号障害、優先順位再割当、及び見通しなどにより動的に変化しうる。ネットワークは極めて不安定であり、利用可能な帯域幅は、急激にかつ通知なく変化しうる。

帯域幅制約に加えて、戦術データネットワークは大きな遅延が生じるかもしれない。例えば、衛星リンクを介した通信を伴うネットワークは、０．５秒又はそれ以上のオーダによる遅延を引き起こすかもしれない。いくつかの通信では、これは問題とはならないが、リアルタイムのインタラクティブ通信（音声通信など）などの他の通信では、可能な限り遅延を最小化することは望ましい。

多くの戦術データネットワークに共通する他の特徴は、データ欠落である。データは、様々な理由により欠落する。例えば、送信すべきデータを有したノードが故障又は損傷するかもしれない。他の例として、送信先ノードがネットワークから一時的に欠落するかもしれない。これは、例えば、ノードが範囲外に移動したため、通信リンクが遮断されたため、及び／又はノードが混雑しているためなどにより発生するかもしれない。送信先ノードが受信できず、中間ノードが送信先ノードが利用可能になるまでデータをバッファするのに十分な容量を欠いているため、データが欠落するかもしれない。さらに、中間ノードは、データを全くバッファリングせず、その代わりにデータが送信先に今まで実際に到達したか判断するため、送信ノードに任せる。

しばしば、戦術データネットワークにおけるアプリケーションは、ネットワークの特定の特性を認識せず、及び／又は考慮しない。例えば、あるアプリケーションは、それが必要とするのと同じくらい利用可能な帯域幅を有していると単に仮定するかもしれない。他の例として、アプリケーションは、データがネットワークにおいて欠落しないと仮定するかもしれない。基礎となる通信ネットワークの具体的特性を考慮しないアプリケーションは、実際に問題を悪化させないように動作するかもしれない。例えば、アプリケーションは、より大きな束によりより少ない頻度で効果的に送信可能なデータのストリームを連続的に送信するかもしれない。この連続的なストリームは、例えば、通信から他のノードを効果的に枯渇させるブロードキャスト無線ネットワークなどにおいて極めて大きなオーバヘッドをもたらし、より頻度の低いバーストは、共有されている帯域幅がより効果的に使用されることを可能にするであろう。

特定のプロトコルは、戦術データネットワークに対して良好に機能しない。例えば、ＴＣＰなどのプロトコルは、無線ベース戦術ネットワーク上では良好に機能しないかもしれない。なぜなら、当該ネットワークが高い損失レートと遅延に直面する可能性があるためである。ＴＣＰは、データを送信するため複数の形式のハンドシェイク及びアクノリッジメントが行われることを要求する。高い遅延とロスにより、ＴＣＰはタイムアウトに至り、当該ネットワークを介し存在する場合に多くの有意なデータを送信することができないかもしれない。

戦術データネットワークにより通信される情報はしばしば、ネットワークにおいて他のデータに関して様々なレベルの優先度を有する。例えば、航空機における脅威警告受信機は、数マイル離れた地上部隊の位置測定情報より高い優先度を有するかもしれない。他の例として、戦闘に関する本部からかの命令は、味方のラインの後方の後方支援通信より高い優先度を有するかもしれない。優先レベルは、送信者及び／又は受信者の特定の状況に依存するかもしれない。例えば、位置測定データは、ユニットが単に標準的なパトロールルートに従っているときより、ユニットが戦闘状態に積極的に従事しているときにはるかに大きな優先度を有するかもしれない。同様に、ＵＡＶからのリアルタイムビデオデータは、それが単にルート上にあるときより、ターゲットエリアにあるときに高い優先度を有するかもしれない。

ネットワークを介しデータを送信するアプローチは複数ある。多くの通信ネットワークにより利用される１つのアプローチは、“ベストエフォート”アプローチである。すなわち、通信されるデータが処理されると共に、他の要求が与えられると、ネットワークが能力、遅延、信頼性、順序付け及びエラーに関して処理可能である。従って、ネットワークは、所与のデータ部分がそれの送信先にタイムリーに又はすべて到達するということを保証しない。さらに、データが送信順序により又はデータの１以上のビットを変更する送信エラーなく到達するということは保証されない。

他のアプローチはＱｏＳである。ＱｏＳは、伝送されるデータに関して各種形式の保証を提供するためのネットワークの１以上の能力を表す。例えば、ＱｏＳをサポートするネットワークは、データストリームに対して特定量の帯域幅を保証するかもしれない。他の例として、ネットワークは、２つの特定ノードの間のパケットがある最大遅延しか有しないことを保証するかもしれない。このような保証は、これら２つのノードがネットワークを介し会話する２人の人である音声通信の場合に有用であるかもしれない。このようなケースでのデータ送信の遅延は、例えば、通信における苛々するギャップ及び／又は無音状態をもたらすかもしれない。

ＱｏＳは、選択されたネットワークトラフィックにより良好なサービスを提供するためのネットワークの能力としてみなされるかもしれない。ＱｏＳの主要な目的は、専用の帯域幅、制御されたジッタ及び遅延（リアルタイムでインタラクティブなトラフィックにより要求される）並びに向上した損失特性を含む優先度を提供することである。他の重要な目的は、１つのフローに優先順位を提供することが他のフローを失敗させないことを確実にすることである。すなわち、以降のフローについてなされる保証が、既存のフローについてなされる保証を破ってはならない。

ＱｏＳに対する現在のアプローチは、しばしばネットワークのすべてのノードがＱｏＳをサポートするか、又は少なくとも特定の通信に関係するネットワークのすべてのノードに対してＱｏＳをサポートすることを要求する。例えば、現在のシステムでは、２つのノードの間の遅延保証を提供するため、これら２つのノードの間のトラフィックを伝送するすべてのノードが、その保証を認識し、それを尊重することに同意し、尊重することができなければならない。

ＱｏＳを提供するアプローチは複数存在する。１つのアプローチは、ＩｎｔｅｇｒａｔｅｄＳｅｒｖｉｃｅｓ、すなわち、“ＩｎｔＳｅｒｖ”である。ＩｎｔＳｅｒｖは、ネットワークのすべてのノードがサービスをサポートし、接続が設定されるとこれらのサービスが予約されるＱｏＳシステムを提供する。ＩｎｔＳｅｒｖは、すべてのノードにおいて維持される必要がある大量の状態情報と、当該接続を設定することに係るオーバヘッドとにより良好にはスケーリングできない。

ＱｏＳを提供する他のアプローチは、ＤｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅｓ、すなわち、“ＤｉｆｆＳｅｒｖ”である。ＤｉｆｆＳｅｒｖは、インターネットなどのネットワークのベストエフォートサービスを向上させるサービスモデルのクラスである。ＤｉｆｆＳｅｒｖは、ユーザ、サービス要求及び他の基準によってトラフィックを区別する。このとき、ネットワークノードが優先キュー処理又は帯域幅割当てを介し、又は特定のトラフィックフローのための専用のルートを選択することによって、異なるレベルのサービスを提供できるように、ＤｉｆｆＳｅｒｖはパケットをマーク付けする。典型的には、ノードは、各サービスクラスについて各種キューを有する。このとき、ノードは、クラスカテゴリに基づきこれらのキューから送信する次のパケットを選択する。

既存のＱｏＳソリューションはしばしばネットワークに固有のものであり、各ネットワークタイプ又はアーキテクチャは異なるＱｏＳコンフィギュレーションを要求するかもしれない。既存のＱｏＳソリューションが利用するメカニズムによって、現在のＱｏＳシステムと同様のメッセージは、実際にメッセージコンテンツに基づき異なる優先順位を有するかもしれない。しかしながら、データ消費者は、優先度の低いデータにより充填されることなく高い優先度のデータへのアクセスを要求するかもしれない。既存のＱｏＳシステムは、トランスポートレイヤにおけるメッセージコンテンツに基づくＱｏＳを提供することができない。

上述されるように、既存のＱｏＳソリューションは、少なくとも特定の通信に関係するノードがＱｏＳをサポートすることを要求する。しかしながら、ネットワークの“エッジ”にあるノードは、それらがトータルの保証をすることができない場合でさえ、ＱｏＳの向上を提供するよう構成されるかもしれない。各ノードは、それらが通信に参加するノード（すなわち、送信及び／又は受信ノード）である場合、及び／又はそれらがネットワークのチョークポイントにある場合、ネットワークのエッジにいるとみなされる。チョークポイントは、すべてのトラフィックが他の部分にわたされる必要があるネットワークのセクションである。例えば、ＬＡＮから衛星リンクへのルータ又はゲートウェイは、チョークポイントとなるであろう。なぜなら、ＬＡＮからＬＡＮ上にない何れかのノードへのすべてのトラフィックは、ゲートウェイを介し衛星リンクにわたされる必要があるためである。

従って、戦術データネットワークにおいてＱｏＳを提供するシステム及び方法が必要とされる。戦術データネットワークのエッジ上でＱｏＳを提供するシステム及び方法が必要とされる。さらに、戦術データネットワークにおける適応的でコンフィギュラブルなＱｏＳシステム及び方法が必要とされる。

本発明の特定の実施例は、データ通信のＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）を制御する方法を提供する。本方法は、第１データセットと第２データセットとを受信するステップと、前記第１データセットをキューに格納するステップとを有する。本方法はまた、前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長であるか判断するステップを有する。本方法はまた、前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長である場合、前記第１データセットを送信し、前記第２データセットを排除するステップを有する。

本発明の特定の実施例は、処理装置上で実行される命令セットを有するコンピュータ可読媒体を提供する。前記命令セットは、第１データセットと第２データセットとを受信する受信ルーチンを有する。命令セットはまた、前記第１データセットをキューに格納する格納ルーチンを有する。命令セットはまた、前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長であるか判断する冗長性ルーチンを有する。命令セットはまた、前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長である場合、前記第１データセットを送信し、前記第２データセットを排除する送信ルーチンを有する。

本発明の特定の実施例は、データ通信のための方法を提供する。本方法は、第１データセットを受信するステップと、前記第１データセットをキューに格納するステップとを有する。本方法はまた、第２データセットを受信するステップを有する。次に、本方法は、冗長性ルールに基づき、前記第２データセットについて機能冗長性処理を実行するか判断するステップを有する。冗長性ルールは、選択されたモードにより制御される。次に、本方法は、前記第１データセットについて前記キューを検索し、前記冗長性ルールに基づき、前記第１データセットが前記第２データセットに機能的に冗長であるか判断するステップを有する。前記第１データセットが前記第２データセットに機能的に冗長である場合、前記第２データセットが排除される。

図１は、本発明の実施例により動作する戦術通信ネットワーク環境を示す。図２は、本発明の実施例による７レイヤＯＳＩネットワークモデルにおけるデータ通信システムの配置を示す。図３は、本発明の実施例によるデータ通信システムを利用して実現される複数のネットワークの一例を示す。図４は、本発明の実施例により動作するデータ通信環境を示す。図５は、本発明の実施例により動作するデータ通信環境を示す。図６は、本発明の実施例によるフロー図を示す。図７は、本発明の実施例によるフロー図を示す。図８は、本発明の実施例による方法を示す。図９は、本発明の実施例による方法を示す。

上記概要と、本発明の特定の実施例の以下の詳細な説明は、添付した図面と共に参照されるときより良好に理解されるであろう。本発明を説明するため、特定の実施例が図面に示される。しかしながら、本発明は添付した図面に示される構成及び装置に限定されるものでないことが理解されるべきである。

図１は、本発明の実施例により動作する戦術通信ネットワーク環境１００を示す。ネットワーク環境１００は、複数の通信ノード１１０と、１以上のネットワーク１２０と、ノード及びネットワークを接続する１以上のリンク１３０と、ネットワーク環境１００の各コンポーネントの通信を実現する１以上の通信システム１５０とを有する。以下の説明は、複数のネットワーク１２０と複数のリンク１３０とを有するネットワーク環境１００を想定するが、他の環境もまた可能であり想定されることが理解されるべきである。

通信ノード１１０は、無線、送信機、衛星、受信機、ワークステーション、サーバ及び／又は他の計算若しくは処理装置などであり、及び／又はそれらを含むかもしれない。

ネットワーク１２０は、例えば、ノード１１０の間でデータを送信するハードウェア及び／又はソフトウェアであるかもしれない。ネットワーク１２０は、例えば、１以上のノード１１０を含むかもしれない。

リンク１３０は、ノード１１０及び／又はネットワーク１２０の間の送信を可能にする有線及び／又は無線接続であるかもしれない。

通信システム１５０は、例えば、ノード１１０、ネットワーク１２０及びリンク１３０の間のデータ送信を実現するため使用されるソフトウェア、ファームウェア及び／又はハードウェアを含むかもしれない。図１に示されるように、通信システム１５０は、ノード１１０、ネットワーク１２０及び／又はリンク１３０に関して実現されてもよい。特定の実施例では、すべてのノード１１０は通信システム１５０を含む。特定の実施例では、１以上のノード１１０は通信システム１５０を含む。特定の実施例では、１以上のノード１１０は通信システム１５０を含まないかもしれない。

通信システム１５０は、ネットワーク環境１００などの戦術通信ネットワーク上の通信を確保するのに役立つためのデータの動的管理を提供する。図２に示されるように、特定の実施例では、システム１５０は、ＯＳＩの７レイヤプロトコルモデルにおけるトランスポートレイヤの一部として及び／又は上位において動作する。システム１５０は、トランスポートレイヤなどにわたされる戦術ネットワークにおける優先順位の高いデータに優先度を提供するかもしれない。システム１５０は、ＬＡＮ、ＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）などの単一ネットワークにおける通信又は複数のネットワーク間の通信を実現するのに利用されるかもしれない。図３において、マルチネットワークシステムの一例が示される。システム１５０は、例えば、追加的な帯域幅をネットワークに追加するのでなく、利用可能な帯域幅を管理するのに利用されるかもしれない。

特定の実施例では、システム１５０は、各種実施例においてハードウェアコンポーネントとソフトウェアコンポーネントの両方を有してもよいが、ソフトウェアシステムである。システム１５０は、例えば、ネットワークハードウェアに依存しないかもしれない。すなわち、システム１５０は、各種ハードウェア及びソフトウェアプラットフォーム上で機能するよう構成されるかもしれない。特定の実施例では、システム１５０は、ネットワークの内部のノード上でなく、ネットワークのエッジ上で動作する。しかしながら、システム１５０は、ネットワークの“チョークポイント（ｃｈｏｋｅｐｏｉｎｔ）”など、ネットワークの内部においても動作可能である。

システム１５０は、ルール及びモード又はプロファイルを利用して、ネットワークにおける利用可能な帯域幅の最適化、情報優先順位の設定及びデータリンクの管理などのスループット管理機能を実行するかもしれない。帯域幅使用の最適化は、機能的に冗長なメッセージの削除、メッセージストリーム管理若しくはシーケンス化、及びメッセージ圧縮などを含むかもしれない。帯域幅の“最適化”とは、ここに記載される技術が１以上のネットワークにおいてデータを通信するための帯域幅の使用の効率性を高めるのに利用可能であることを意味する。情報優先順位の設定は、ＩＰベース技術より詳細な単位によりメッセージタイプを区別すること、選択されたルールベースシーケンス化アルゴリズムを介しメッセージをデータストリームにシーケンス化することなどを含むかもしれない。データリンク管理は、例えば、ルール、モード及び／又はデータトランスポートの変化に影響を与えるネットワーク測定結果のルールベースの解析を含むかもしれない。モード又はプロファイルは、特定のネットワーク健全性状態の動作要求に関するルールセットを含むかもしれない。システム１５０は、無線による新たなモードの定義及びスイッチを含む、動的なモードの“無線（ｏｎ−ｔｈｅ−ｆｌｙ）”リコンフィギュレーション又は再設定を提供する。

通信システム１５０は、不安定な帯域幅制限のあるネットワークなどにおけるサービスの優先順位及びグレードの変更に適応するよう構成されるかもしれない。システム１５０は、ネットワークにおけるレスポンス能力の向上と通信遅延の低下に役立つように、改良されたデータフローのための情報を管理するよう構成されるかもしれない。さらに、システム１５０は、通信の利用性、生存性及び信頼性を向上させるようアップグレード可能かつスケーラブルなフレキシブルアーキテクチャを介し相互互換性を提供するかもしれない。システム１５０は、所定の予測可能なシステムリソース及び帯域幅などを利用しながら、動的に変化する環境に自律的に適応可能なデータ通信アーキテクチャをサポートする。

特定の実施例では、システム１５０は、ネットワークを利用するアプリケーションに対する透過性を維持しながら、帯域幅制限された戦術通信ネットワークにスループット管理を提供する。システム１５０は、低減された複雑さにより複数のユーザ及び環境におけるスループット管理をネットワークに提供する。上述されるように、特定の実施例では、システム１５０は、ＯＳＩの７レイヤモデルの第４レイヤ（トランスポートレイヤ）にある及び／又はの上位にあるホストノード上で実行され、特殊なネットワークハードウェアを必要としない。システム１５０は、第４レイヤインタフェースに透過的に動作するかもしれない。すなわち、アプリケーションは、トランスポートレイヤの標準的なインタフェースを利用し、システム１５０の動作に気付かないかもしれない。例えば、アプリケーションがソケットをオープンするとき、システム１５０は、プロトコルスタックの当該ポイントにおいてデータをフィルタリングするかもしれない。システム１５０は、アプリケーションがシステム１５０に固有のインタフェースでなくネットワーク上の通信装置におけるオペレーティングシステムにより提供されるＴＣＰ／ＩＰソケットインタフェースなどを利用することを可能にすることによって、透過性を実現する。システム１５０のルールは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）により記述されるか、及び／又はカスタムＤＬＬ（ＤｙｎａｍｉｃＬｉｎｋＬｉｂｒａｒｙ）を介し提供されるかもしれない。

特定の実施例では、システム１５０は、ネットワークのエッジ上でＱｏＳを提供する。システムのＱｏＳ能力は、ネットワークのエッジ上でコンテンツベース、ルールベースデータ優先順位付けを提供する。優先順位付けは、例えば、区別及び／又はシーケンス化を含むかもしれない。システム１５０は、例えば、ユーザコンフィギュラブルな区別ルールに基づきメッセージをキューに区別するかもしれない。これらのメッセージは、ユーザにより設定されたシーケンス化ルール（スタベーション、ラウンドロビン、相対頻度など）により規定される順序によりデータストリームにシーケンス化される。エッジ上のＱｏＳを利用して、従来のＱｏＳアプローチにより区別できないデータメッセージは、メッセージコンテンツなどに基づく区別されてもよい。ルールは、例えば、ＸＭＬにより実現されてもよい。特定の実施例では、ＸＭＬを超える能力を収容し、及び／又は極端に低い遅延要求をサポートするため、システム１５０は、例えば、ＤＬＬにカスタムコードを設けることを可能にする。

ネットワーク上の入力及び／又は出力データは、システム１５０を介しカスタマイズされるかもしれない。優先順位付けは、クライアントアプリケーションを大容量低優先順位データなどからプロテクトする。システム１５０は、アプリケーションが特定の動作シナリオ又は制約をサポートするようデータを受信することを確実にするのに供する。

特定の実施例では、ホストが帯域幅制限のある戦術ネットワークとのインタフェースとしてのルータを有するＬＡＮに接続されると、システムは、プロキシによりＱｏＳとして知られるコンフィギュレーションにより動作するかもしれない。このコンフィギュレーションでは、ローカルなＬＡＮ宛のパケットはシステムをバイパスし、ＬＡＮにすぐに向かう。システムは、ネットワークのエッジ上のＱｏＳを帯域幅制限のある戦術リンクに向かうパケットに適用する。

特定の実施例では、システム１５０は、命令されたプロファイルスイッチングを介し複数の動作シナリオ及び／又はネットワーク環境の動的サポートを提供する。プロファイルは、ユーザ又はシステムが指名されたプロファイルに変更を加えることを可能にする名称又は他の識別子を含むかもしれない。プロファイルはまた、例えば、機能冗長性ルール識別子、区別ルール識別子、アーカイブインタフェース識別子、シーケンス化ルール識別子、送信前インタフェース識別子、送信後インタフェース識別子、トランスポート識別子、及び／又は他の識別子などの１以上の識別子を含むかもしれない。機能冗長性ルール識別子は、古いデータ又は実質的に同様のデータなどから機能冗長性を検出するルールを規定する。区別ルール識別子は、例えば、処理のためメッセージをキューに区別するルールを規定する。アーカイブインタフェース識別子は、例えば、アーカイブシステムとのインタフェースを規定する。シーケンス化ルール識別子は、キューフロントのサンプルと、データストリームのデータのシーケンス化とを制御するシーケンス化アルゴリズムを特定する。送信前インタフェース識別子は、例えば、暗号化及び圧縮などの特別な処理を提供する送信前処理のためのインタフェースを特定する。送信後インタフェース識別子は、例えば、解読及び伸張などの処理を提供する送信後処理のためのインタフェースを特定する。トランスポート識別子は、選択されたトランスポートのネットワークインタフェースを規定する。

プロファイルはまた、例えば、キューサイジング情報などの他の情報を含むかもしれない。キューサイジング情報は、例えば、各キューに専用のメモリ及びセカンダリストレージの大きさとキューの個数を特定する。

特定の実施例では、システム１５０は、帯域幅を最適化するためのルールベースアプローチを提供する。例えば、システム１５０は、各メッセージに優先順位とデータストリーム上の適切な相対頻度とを割当てるよう、メッセージをメッセージキューに区別するためのキュー選択ルールを利用するかもしれない。システム１５０は、機能冗長性ルールを利用して、機能的に冗長なメッセージを管理するかもしれない。メッセージは、それが例えば、ネットワーク上でまだ送信されていない前のメッセージと十分異なるものでない場合（ルールにより規定されるように）、機能的に冗長である。すなわち、すでに送信がスケジューリングされたが、まだ送信されていない古いメッセージと十分異なるものでない新たなメッセージが提供された場合、この新たなメッセージは排除されてもよい。なぜなら、古いメッセージが機能的に等価な情報を搬送し、さらにキューにおいて前にあるためである。さらに、機能冗長性は、古いメッセージが送信される前に到着した新しいメッセージと実質的に重複したメッセージを含むかもしれない。例えば、ノードは、フォルトトレラント（ｆａｕｌｔｔｏｌｅｒａｎｔ）であるため、２つの異なるパスにより送信されたメッセージなど、基礎となるネットワークの特性により特定のメッセージの同一のコピーを受信するかもしれない。他の例として、新たなメッセージは、まだ送信されていない古いメッセージに優先するデータを含むかもしれない。この状況では、システム１５０は、古いメッセージを排除し、新たなメッセージのみを送信するようにしてもよい。システム１５０はまた、データストリームの優先順位ベースメッセージシーケンスを決定するための優先順位シーケンス化ルールを含むようにしてもよい。さらに、システム１５０は、圧縮及び／又は暗号化などの送信前及び送信後の特別な処理を提供するため、送信処理ルールを有してもよい。

特定の実施例では、データ完全性及び信頼性を保護するのに役立つように、フォルトトレラント機能を提供する。例えば、システム１５０は、ユーザにより規定されたキュー選択ルールを利用して、メッセージをキューに区別するようにしてもよい。キューは、例えば、ユーザにより規定されるコンフィギュレーションに従ってサイジングされる。コンフィギュレーションは、例えば、キューが使用するメモリの最大量を規定する。さらに、コンフィギュレーションは、ユーザがキューのオーバフローのために利用可能なセカンダリストレージの位置及び大きさを規定することを可能にするかもしれない。キューのメモリが充填された後、メッセージはセカンダリストレージにキュー処理されるかもしれない。セカンダリストレージがまたフルになると、システム１５０は、キューの最も古いメッセージを削除し、エラーメッセージを記録し、最も新しいメッセージをキュー処理する。この動作モードに対してアーカイブ処理が可能である場合、キュー解除されたメッセージは、当該メッセージがネットワーク上で送信されなかったという表示と共にアーカイブ化されてもよい。

システム１５０のキューのためのメモリ及びセカンダリストレージは、例えば、特定のアプリケーションについてリンク毎に設定されてもよい。ネットワーク利用可能期間の間の時間が長いことは、ネットワークの停止をサポートするためより大きなメモリ及びセカンダリストレージとなることに対応するかもしれない。システム１５０は、例えば、キューが適切にサイジングされ、停止時間が安定状態をアーカイブし、最終的なキューのオーバフローを回避するのに役立つよう十分なものとなることを保証するのに役立つようなサイジングを特定するのに供するためなどのネットワークモデリング及びシミュレーションアプリケーションと統合されてもよい。

さらに、特定の実施例では、システム１５０は、入力（シェイピング）と出力（ポリシング）データを測定する機能を提供する。ポリシングとシェイピング機能は、ネットワークにおけるタイミングミスマッチに対処するのに役立つ。シェイピングは、ネットワークバッファが低優先順位データの後に高優先順位データがキューされることによるフラッディングを防ぐのに役立つ。ポリシングは、アプリケーションデータ利用者が低優先順位データにより圧倒されることを防ぐのに役立つ。ポリシングとシェイピングは、有効リンクスピードとリンク比率という２つのパラメータにより決定される。システム１５０は、例えば、リンク比率と乗算された有効リンクスピードより大きくないデータストリームを構成するかもしれない。これらのパラメータは、ネットワークの変更に従って動的に変更されるかもしれない。システムはまた、データ測定に関するアプリケーションレベルの結果をサポートするため、検出されたリンクスピードへのアクセスを提供するかもしれない。システム１５０により提供される情報は、所与のネットワークシナリオに対して何れのリンクスピードが適切であるか決定するのに役立つ他のネットワーク動作情報と組み合わされてもよい。

図４は、本発明の実施例により動作するデータ通信環境４００を示す。環境４００は、１以上のソースノード４２０と、データ通信システム４１０と、１以上のデスティネーションノード４３０とを有する。データ通信システム４１０は、ソースノード４２０とデスティネーションノード４３０と通信する。データ通信システム４１０は、無線、衛星、ネットワークリンクなどのリンクを介し及び／又はプロセス間通信などを介しソースノード４２０及び／又はデスティネーションノード４３０と通信するかもしれない。特定の実施例では、データ通信システム４１０は、１以上の戦術データネットワークを介し１以上のソースノード４２０及び／又はデスティネーションノード４３０と通信するかもしれない。システム４００の各コンポーネントは、単一のユニット又は個別のユニットであってもよく、また各種形式により統合されてもよく、またハードウェア及び／又はソフトウェアにより実現されてもよい。

データ通信システム４１０は、例えば、上述されるように、通信システム１５０と同様のものであってもよい。特定の実施例では、データ通信システム４１０は、１以上のソースノード４２０からデータを受信するよう構成される。特定の実施例では、データ通信システム４１０は、コンピュータ命令及びルールを格納するための記憶ユニット及び／又はデータベースを有してもよい。データ通信システム４１０はまた、データ、ルール及び命令を処理するためのプロセッサを有してもよい。特定の実施例では、データ通信システム４１０は、データを保持、格納、整理及び／又は優先順位付けするための１以上のキューを有してもよい。あるいは、データを保持、格納、整理及び／又は優先順位付けするための他のデータ構造が利用されてもよい。例えば、テーブル、ツリー又はリンク付きリストが利用されるかもしれない。特定の実施例では、データ通信システム４１０は、１以上のデスティネーションノード４３０にデータを通信するよう構成される。

特定の実施例では、データ通信システム４１０は他のアプリケーションに透過である。例えば、データ通信システム４１０により実行される処理、整理及び／又は優先順位付けは、１以上のソースノード４２０又は他のアプリケーション若しくはデータソースに透過であるかもしれない。例えば、データ通信システム４１０と同一システム上又はデータ通信システム４１０に接続されるソースノード４２０上で実行されるアプリケーションは、データ通信システム４１０により実行されるデータの優先順位付けを認識していないかもしれない。

データ通信システム４１０のコンポーネント、要素及び／又は機能は、例えば、ハードウェア、ファームウェア及び／又はソフトウェアによる命令セットの各種形式により単独で又は組み合わせて実現されてもよい。特定の実施例は、汎用コンピュータ又は他の処理装置上で実行するため、メモリ、ハードディスク、ＤＶＤ又はＣＤなどのコンピュータ可読媒体上の命令セットとして提供されてもよい。

ソースノード４２０は、データ又は遠隔測定情報を収集するためのセンサ又は測定装置を有してもよい。例えば、ソースノード４２０は、戦車、ハンビー（ｈｕｍｖｅｅ）ユニット、個人輸送手段又は各兵士など、移動車両の位置データを示すＧＰＳ（ＧｌｏｂａｌＰｏｓｉｔｉｏｎａｌＳｙｓｔｅｍ）データであるかもしれない。他の例では、ソースノード４２０は、ビデオ又はイメージを取得するビデオ又はスチルピクチャカメラなどの撮像ユニットであってもよい。他の例では、ソースノードは、ラジオやマイクロフォンなどの通信モジュールであってもよい。デスティネーションノード４３０は、ソースノード４２０により取得されたデータに関心のある任意の装置又はシステムであってもよい。例えば、デスティネーションノード４３０は、指揮所又は偵察ユニットにより利用される受信機、中央コンピュータシステム及び／又はコンピュータであってもよい。

データ通信システム４１０により受信、格納、優先順位付け、処理、通信及び／又は送信されるデータは、データのブロックを含むかもしれない。データブロックは、例えば、データのパケット、セル、フレーム及び／又はストリームであってもよい。例えば、データ通信システム４１０は、ソースノード４２０からデータのパケットを受信するかもしれない。他の例として、データ通信システム４１０は、ソースノード４２０からデータのストリームを処理するかもしれない。

特定の実施例では、データはプロトコル情報を含む。プロトコル情報は、例えば、データを通信するため、１以上のプロトコルにより利用されるかもしれない。プロトコル情報は、例えば、ソースアドレス、デスティネーションアドレス、ソースポート、デスティネーションポート及び／又はプロトコルタイプなどを含むかもしれない。ソース及び／又はデスティネーションアドレスは、例えば、ソースノード４２０及び／又はデスティネーションノード４３０のＩＰアドレスなどであるかもしれない。プロトコルタイプは、データの１以上の通信レイヤに使用されるプロトコルの種類を含むかもしれない。例えば、プロトコルタイプは、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）、ＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）又はＳＣＴＰ（ＳｔｒｅａｍＣｏｎｔｒｏｌＴｒａｎｓｍｉｓｓｉｏｎＰｒｏｔｏｃｏｌ）などのトランスポートプロトコルであるかもしれない。他の例として、プロトコルタイプは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）、ＩＰＸ（ＩｎｔｅｒｎｅｔｗｏｒｋＰａｃｋｅｔＥｘｃｈａｎｇｅ）、イーサネット(登録商標）、ＡＴＭ（ＡｓｙｎｃｈｒｏｎｏｕｓＴｒａｎｓｆｅｒＭｏｄｅ）、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）及び／又はＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）を含むかもしれない。特定の実施例では、データはまたタイムスタンプ情報を含むかもしれない。タイムスタンプ情報は、例えば、ソースノード４２０によるデータ取得の時間を示すかもしれない。

特定の実施例では、データは、ヘッダとペイロードとを有する。ヘッダは、プロトコル情報と、タイムスタンプ情報などのすべて又は一部を含むかもしれない。特定の実施例では、プロトコル情報及びタイムスタンプ情報のすべて又は一部は、ペイロードに含まれるかもしれない。例えば、プロトコル情報は、データのブロックのペイロード部分に格納されるより高いレベルのプロトコルに関する情報を含むかもしれない。特定の実施例では、データはメモリにおいて隣接していない。すなわち、データの１以上の部分が、異なるメモリ領域に配置されてもよい。例えば、プロトコル情報は１つのメモリ領域に格納され、ペイロードは他のバッファに格納され、タイムスタンプ情報はさらなる他のバッファに格納される。

一実施例では、ソースノード４２０とデータ通信システム４１０とは、同一のモバイルユニットの一部であるかもしれない。モバイルユニットは、戦車、ハンビーユニット、個人輸送手段、各兵士、ＵＡＶ（ＵｎｍａｎｎｅｄＡｅｒｉａｌＶｅｈｉｃｌｅ）又は他のモバイルユニットであってもよい。戦車は、ソースユニット４２０として位置データを示すＧＰＳセンサを有するかもしれない。位置データは、データ通信システム４１０に通信されてもよい。データ通信システム４１０は、戦車に設けられてもよい。データ通信システム４１０は、デスティネーションノード４３０との通信用のデータを準備するかもしれない。デスティネーションノードとの通信の準備の一部として、データ通信システム４１０は、ある形式のネットワークアクセスプロトコルを実行してもよい。ネットワークアクセスプロトコルは、制御ユニット、検知キャリア利用性又は他の形式のアクセス制御からのネットワークアクセスの要求を含むかもしれない。

一例では、データ通信システム４１０がアクセスを取得することを試行しているネットワークは、帯域制限されているかもしれない。さらに、１以上のリンクは、信頼性が低く、及び／又は断続的に切断されるかもしれない。このため、データ通信システム４１０は、デスティネーション４３０にデータを通信するためネットワークにアクセス可能になるまで、ソース４２０から受信したデータを一時的にキュー処理するかもしれない。例えば、ソース４２０は第１データセットを取得するかもしれない。ソース４２０は、データ通信システム４１０と第１データセットを通信するかもしれない。データ通信システム４１０は、第１データセットをデスティネーション４３０に送信するため、ネットワークアクセスを現在有していないかもしれない。このとき、第１データセットは、データ通信システム４１０がネットワークアクセスを有するまで、キューに一時的にキュー処理されるかもしれない。しばらくして、ソースは第２データセットを取得するかもしれない。第２データセットは、データ通信システム４１０に通信されるかもしれない。データ通信システム４１０は、第１又は第２データセットをデスティネーション４３０に送信するため、まだネットワークアクセスを有していないかもしれない。データがデータのタイミングに関係するタイプである場合、例えば、直近のデータが位置データなどのデスティネーション４３０に関連している場合、第１データセットはもはや関連しない。すなわち、第１データセットは、第２データセットに関して機能的に冗長となる。従って、デスティネーション４３０への第１データセットの送信は、ネットワーク帯域幅を不必要に消費するかもしれない。

他の例では、ソースは、第１データセットを取得し、それをデータ通信システム４１０に通信するかもしれない。データ通信システム４１０は、第１データセットをデスティネーション４３０に送信するため、ネットワークアクセスを現在有しているか、又は有していないかもしれない。データ通信システム４１０がネットワークへのアクセスを有する場合、データ通信システム４１０は、第１データセットをデスティネーション４３０に送信するかもしれない。ソース４２０は、第２データセットを取得するかもしれない。データ通信システム４１０は、第２データセットをデスティネーション４３０に送信するためのネットワークアクセスを現在有しているかもしれないし、そうでないかもしれない。データ通信システム４１０がネットワークへのアクセスを有している場合、データ通信システム４１０は、第２データセットをデスティネーション４３０に送信するかもしれない。データが、取得時間が連続的な各取得の間にわずかな変化しかないタイプである場合、例えば、地上５０００フィートからのＵＡＶからの毎秒撮影される写真などである場合、連続的なデータセットは機能的に冗長であるかもしれず、すなわち、ほぼ同じイメージをキャプチャする。このため、連続的なデータセットのデスティネーション４３０への送信は、不必要にネットワーク帯域幅を消費するかもしれない。

他の例では、ソースは、第１データセットを取得し、それをデータ通信システム４１０に通信するかもしれない。データ通信システム４１０は、第１データセットをデスティネーション４３０に送信するため、ネットワークアクセスを現在有しているかもしれないし、又はそうでないかもしれない。データ通信システム４１０がネットワークへのアクセスを有する場合、データ通信システム４１０は、第１データセットをデスティネーション４３０に送信するかもしれない。ソース４２０は、第２データセットを取得するかもしれない。データ通信システム４１０は、第２データセットをデスティネーション４３０に送信するため、ネットワークアクセスを現在有しているかもしれないし、又はそうでないかもしれない。データ通信システム４１０がネットワークへのアクセスを有している場合、データ通信システム４１０は、第２データセットをデスティネーション４３０に送信するかもしれない。第１データセットのコンテンツが同じである場合、及び／又は第２データセットのコンテンツに類似している場合、オーディオコンポーネントを有すると予想されるデータセットにおけるオーディオコンポーネントの欠落など、連続するデータセットは機能的に冗長であるかもしれない。このため、連続的なデータセットのデスティネーション４３０への送信は、不必要にネットワーク帯域幅を消費するかもしれない。

図５は、本発明の実施例により動作するデータ通信環境５００を示す。環境５００は、図４に示されるようなデータ通信システム４１０と、ソース４２０と、デスティネーション４３０とを有する。データ通信システム４１０は、本発明の特定の実施例を説明するため、拡大及び詳細化される。

図５に示されるように、データ通信システム４１０は、冗長性ルールデータベース５１０と、受信機５２０と、演算プロセッサ（ｏｐｅｒａｔｉｏｎａｌｐｒｏｃｅｓｓｏｒ）５３０と、１以上のキュー５４０と、送信機５５０とを有する。冗長性ルールデータベース５１０は、演算プロセッサ５３０と通信する。受信機５２０は、演算プロセッサ５３０とソース４２０と通信する。演算プロセッサ５３０は、キュー５４０と通信する。図５に示されるように、データ通信システム４１０は、有線、無線、衛星、ネットワークリンクを介し及び／又はプロセス間通信などを介し、ソースノード４２０及び／又はデスティネーションノード４３０と通信するかもしれない。特定の実施例では、データ通信システム４１０は、１以上の戦術データネットワークを介し１以上のソースノード４２０及び／又はデスティネーションノード４３０と通信するかもしれない。システム５００の各コンポーネント、システム５００における各接続及びシステム５００は、単一のユニット又は個別のユニットであってもよく、また各種形式により統合されてもよく、またハードウェア及び／又はソフトウェアにより実現されてもよい。

一実施例では、冗長性ルールデータベース５１０は、各種ルール及び／又はプロトコルを格納し、演算プロセッサ５３０に通信するためのデータベースであってもよい。冗長性ルールデータベース５１０と、冗長性ルールデータベース５１０と演算プロセッサ５３０との間に示される接続とは、典型的には、処理を実行し、ルール及び命令を格納するための各種コンポーネント及び／又はソフトウェアである。受信機５２０は、典型的には、データをソース４２０から受信する各種コンポーネント及び／又はソフトウェアである。演算プロセッサ５３０は、典型的には、冗長性ルールデータベース５１０により通信されるルールに基づき、データ及び処理を実行するプロセッサである。キュー５４０は、典型的には、データをキュー処理する各種コンポーネント及び／又はソフトウェアである。送信機５５０は、典型的には、データをデスティネーション４３０に送信する各種コンポーネント及び／又はソフトウェアである。

上述されるように、データ通信システム４１０により受信、格納、優先順位付け、処理、通信及び／又は送信されるデータは、データのブロックを含むかもしれない。データブロックは、例えば、データのパケット、セル、フレーム及び／又はストリームであってもよい。例えば、受信機５２０は、データブロックを有するよう示される。データブロックは、１以上のデータブロックを含むかもしれない。

動作について、データセットは、１以上のデータソース４２０により提供及び／又は生成されるかもしれない。データセットが、受信機５２０において受信される。データセットは、例えば、１以上のリンクを介し受信されるかもしれない。例えば、データセットは、戦術データネットワークを介し無線からデータ通信システム４１０において受信されるかもしれない。他の例として、データセットは、プロセス間通信機構により同一システム上で実行されるアプリケーションによってデータ通信システム４１０に提供されるかもしれない。上述されるように、データセットは、１以上のデータブロックを含むかもしれない。

特定の実施例では、受信機５２０は、データセットを演算プロセッサ５３０に通信するかもしれない。演算プロセッサ５３０は、データセットを受信し、データセットに対して機能冗長性処理を実行するか決定するかもしれない。演算プロセッサ５３０は、冗長性ルールデータベース５１０からの冗長性ルールに基づき、データセットに対して機能的に冗長な処理を実行するか判断するかもしれない。

一実施例では、冗長性ルールは、特定のデータセットに対して機能冗長性処理を実行するか制御し、機能冗長性処理が実行されるべきである場合、機能冗長性処理をどのように実行するか制御するルールであるかもしれない。ユーザにより選択される、又は各種ファクタに基づきコンピュータソフトウェアにより選択されるモードは、データセットに適用可能な冗長性ルールの“セット”を規定するかもしれない。

例えば、冗長性ルールは、ユーザにより選択される“モード”に基づき、“オン”又は“オフ”として設定されるかもしれない。上述されるように、データ通信システム４１０は、ルール及びモード又はプロファイルを利用して、ネットワークにおける利用可能な帯域幅の最適化、情報優先順位の設定及びデータリンクの管理などのスループット管理機能を実行してもよい。異なるモードは、例えば、ルール、モード及び／又はデータ伝送の変更に影響を与えるかもしれない。モード又はプロファイルは、特定のネットワークの健全性状態について動作要求に関するルールセットを含むかもしれない。データ通信システム４１０は、例えば、新たなモードの“無線”による定義及びスイッチ又はユーザによるモードの選択を含むモードの動的な再設定を提供するかもしれない。

選択されたモードが冗長性ルールセットを利用する場合、演算プロセッサ５３０は、冗長性ルールに基づき機能冗長性処理を実行するか判断するため、データセットを解析するかもしれない。一実施例では、利用可能なモードは異なる冗長性ルールを有するかもしれない。例えば、モードＡは第１冗長性ルールセットを有し、モードＢは第２冗長性ルールセットを有するかもしれない。冗長性ルールセットは、単一又は複数のモードに属するかもしれない。モードは、複数の冗長性ルールセットを含むかもしれない。

機能冗長性処理を実行するか判断する際、演算プロセッサ５２０は、データブロックのプロトコル情報、ペイロード及び／又はタイムスタンプなどの情報をデータブロックから読み取るかもしれない。上述されるように、プロトコル情報は、例えば、ソースアドレス、デスティネーションアドレス、ソースポート、デスティネーションポート、プロトコルタイプ及び／又はタイムスタンプなどを含むかもしれない。例えば、冗長性ルールデータベース５１０の冗長性ルールが、選択されたモードについて、特定のソースからのデータに対して機能冗長性が実行されるべきであることを示している場合、演算プロセッサ５３０は、当該ソースからのデータに対して機能冗長性処理を実行する。例えば、選択されたモードの冗長性ルールは、ソースノードＡからのデータに対して機能冗長性処理を実行するが、ソースノードＢからのデータに対しては実行しないよう示しているかもしれない。このため、機能冗長性処理は、本例では、ソースノードＢからのデータに対しては実行されない。

演算プロセッサ５３０が、機能上調整処理がデータセットに対して実行されるべきであると判断した場合、演算プロセッサ５３０は、冗長性ルールに従ってデータセットに対して機能冗長性処理を実行するかもしれない。冗長性ルールは、選択されたモードにより決定されるかもしれない。例えば、冗長性ルールは、演算プロセッサ５３０が現在のデータセットと同じソースからのデータセットをキュー５４０から検索するよう指示するかもしれない。冗長性ルールは、特定のソースからのキューに古いデータセットが検出された場合、当該古いデータセットが現在のより新しいデータセットに対して機能的に冗長であることを指示するかもしれない。あるいは、冗長性ルールは、演算プロセッサ５３０が現在のデータセットと同じソースからのデータセットをキュー５４０から検索するよう指示するかもしれない。冗長性ルールは、演算プロセッサにキューされているデータセットと現在のデータセットのタイムスタンプ情報を確認して、キューされているデータセットと現在のデータセットが機能的に冗長な情報を有しているか判断するよう指示する。あるいは、冗長性ルールは、演算プロセッサにペイロード情報を確認して、キューされているデータセット及び現在のデータセットが同一及び／又は類似する機能的コンテンツを有しており、このため、機能的に冗長であるか判断するよう指示するかもしれない。

例えば、冗長性ルールは、第１データセットと第２データセットとが同一ソースから取得されている場合、第１の先のデータセットを第２の後のデータセットに機能的に冗長していると特定するかもしれない。他の例では、冗長性ルールは、第１データセットと第２データセットとが、それらの間で所定の時間内に取得された場合、第１の先のデータセットを第２の後のデータセットに機能的に冗長していると特定するかもしれない。他の例では、冗長性ルールは、例えば、オーディオコンポーネントを有すると予想されるデータセットにオーディオコンポーネントが欠落しているなど、第１データセットと第２データセットが機能的に類似した及び／又は同一のコンテンツを有する場合、第２の後のデータセットを第１の先のデータセットに機能的に冗長していると特定するかもしれない。

機能的に冗長していると分類されるデータの具体例は、位置データであるかもしれない。ＧＰＳインジケータなどのソース４２０は、特定の時間におけるハンビーの位置を通知するため、第１データセットを生成するかもしれない。ネットワークの制約のため、第１データセットはキュー５４０に格納されてもよい。ハンビーが移動するに従って、ソース４２０は、第１データセットと異なる位置を通知する第２データセットを生成するかもしれない。演算プロセッサ５３０が第２データセットを受信すると、演算プロセッサ５３０は、選択されたモードがソース４２０からの位置データについて機能冗長性を利用すると判断するかもしれない。

その後、演算プロセッサ５３０は、ソース４２０からのデータセットがキュー５４０に格納されているか判断するため、キュー５４０を検索するかもしれない。ソース４２０からのデータセットが特定された場合、演算プロセッサ５３０は、位置データの第１データセットが位置データの第２データセットに機能的に冗長していると判断するかもしれない。演算プロセッサ５３０は、時間的に先に取得された位置データの第１データセットが、時間的に後に取得された位置データの第２データセットより精度が低いとき、キュー５４０から先の第１データセットを排除するかもしれない。その後、演算プロセッサ５３０は、位置データの第２データセットをキュー５４０に追加するかもしれない。

演算プロセッサ５３０は、キュー５４０の送信順序が変わらないように、第２データセットをキュー５４０に追加するかもしれない。例えば、第２データセットは、キューの該当位置において第１データセットを置換するかもしれない。一実施例では、キューのスポットは、第１データセットが第２データセットと置換されると保持される。他の実施例では、第２データセットはキューのエンドに追加される。演算プロセッサ５３０は、ＦＩＦＯ（ＦｉｒｓｔＩｎＦｉｒｓｔＯｕｔ）プロトコルにより第２データセットをキュー５４０に追加するかもしれない。このようにして、直近の位置データが、“古い”もはや正確でなく関連性のない位置データによるネットワークの負荷なく、デスティネーション４３０に送信される。

機能的に冗長として分類されるデータの他の具体例は、短期間に取得された連続的なデータセットであるかもしれない。例えば、ＵＡＶは５０００フィートを飛行し、毎秒１枚の写真を撮影しているかもしれない。ＵＡＶは、ややゆっくりと飛行しており、このため、ＵＡＶにより取得される写真は実質的に互いに異なっていない。短期間に取得された連続的な写真が新たな情報を示していないとき、連続する写真は機能的に冗長であるかもしれない。機能的に冗長な写真の送信は、不必要に貴重な帯域幅を消費するかもしれない。

より良い理解のために与えられる具体例では、ＵＡＶは、カメラ（本例ではソース４２０）から第１ピクチャ（本例では第１データセット）をキャプチャし、これを受信機５２０に通信するかもしれない。受信機５２０は、第１ピクチャを演算プロセッサ５３０に通信するかもしれない。演算プロセッサ５３０は、第１ピクチャをキュー５４０に通信するかもしれない。第１ピクチャは、送信機５５０がネットワークアクセスを有するまで、キュー５４０に待機するかもしれない。特定の実施例では、送信機５５０は、ネットワークアクセスを有しないかもしれず、又はカメラ（本例ではソース４２０）からの第２ピクチャ（本例では第２データセット）が演算プロセッサ５３０に通信されるまでネットワークアクセスを要求しないかもしれない。

演算プロセッサ５３０は、第２データセットを受信すると、第２データセットに対して機能冗長性処理を実行するか判断する。上述されるように、演算プロセッサ５３０は、データブロックのプロトコル情報、ペイロード及び／又はタイムスタンプなどの情報をデータブロックから読み取るかもしれない。プロトコル情報は、例えば、ソースアドレス、デスティネーションアドレス、ソースポート、デスティネーションポート、プロトコルタイプ及び／又はタイムスタンプなどを含むかもしれない。演算プロセッサ５３０が第２データセットを受信すると、演算プロセッサ５３０は、選択されたモードが冗長性ルールに従ってソース４２０（本例ではＵＡＶのカメラ）からのデータに対して機能冗長性を利用すると判断するかもしれない。例えば、冗長性ルールは、時間閾値により分離されたデータセットが、ソース４２０からデスティネーション４３０に送信されることを規定するかもしれない。

演算プロセッサ５３０は、ソース４２０からのデータセットがキュー５４０に格納されているか判断するため、キュー５４０を検索するかもしれない。ソース４２０からのデータセットが特定された場合、演算プロセッサ５３０は、第１データセットと第２データセットのタイムスタンプを確認するかもしれない。演算プロセッサ５３０は、タイムスタンプで特定されるような第１データセットと第２データセットの間の取得時間の相違が特定の時間閾値未満であると判断するかもしれない。第１データセットと第２データセットの取得時間の間の相違が特定の時間閾値未満である場合、演算プロセッサ５４０は、第１データセットが第２データセットに機能的に冗長であると判断するかもしれない。時間閾値の値は、選択されたモードにより決定されるかもしれない。

一実施例では、演算プロセッサ５３０は、時間的に先に取得された第１データセット（第１ピクチャ）が時間的に後に取得された第２データセット（第２ピクチャ）より関連性が低くなっているとき、キュー５４０から先の第１データセットを排除するかもしれない。その後、演算プロセッサ５３０は、第２データセット（第２ピクチャ）をキュー５４０に追加するかもしれない。演算プロセッサ５３０は、キュー５４０の送信順序が変更されないように、第２データセットをキュー５４０に追加するかもしれない。例えば、第２データセットは、キューの該当位置において第１データセットと置換されるかもしれない。一実施例では、キューのスポットは、第１データセットが第２データセットにより置換されるとき、保持される。他の実施例では、第２データセットはキューのエンドに追加される。演算プロセッサ５３０は、ＦＩＦＯプロトコルにより第２データセットをキュー５４０に追加するかもしれない。

機能的に冗長と分類されるデータの他の具体例は、同一又は同様のコンテンツを有するデータセットであるかもしれない。オーディオコンポーネントを有すると予想されるデータセットにオーディオコンポーネントが欠落しているなど、第１データセットのコンテンツが第２データセットのコンテンツと同一及び／又は同様である場合、連続的なデータセットは機能的に冗長であるかもしれない。例えば、オーディオデータを含まないオーディオデータを含むと予想されるデータセットは、それが無線サイレンスを送信していることを示すかもしれない。無線サイレンスがデスティネーション４３０にとって有用でない場合、無線サイレンスを含むデータセットの送信は、不必要に帯域幅を消費するかもしれない。従って、オーディオコンポーネントが予想されるデータセットについて、オーディオコンポーネントをほとんど又は全く有しない連続的なデータセットは、機能的に冗長であるかもしれない。

より良い理解を提供する具体例では、ラジオ又はマイクロフォン（本例ではソース４２０）が、第１データセットを取得し、それを受信機５２０に通信するかもしれない。受信機５２０は、第１データセットを演算プロセッサ５３０に通信するかもしれない。演算プロセッサ５３０は、第１データセットをキュー５４０に通信するかもしれない。第１データセットは、送信機５５０がネットワークアクセスを有するまで、キュー５４０において待機するかもしれない。特定の実施例では、送信機５５０は、ソース４２０からの第２データセットが演算プロセッサ５３０に通信されるまで、ネットワークアクセスを有しないかもしれず、又はネットワークアクセスを要求しないかもしれない。

演算プロセッサ５３０は、第２データセットを受信すると、第２データセットに対して機能冗長性処理を実行するか判断する。上述されるように、演算プロセッサ５３０は、データブロックのプロトコル情報、ペイロード及び／又はタイムスタンプなどの情報をデータブロックから読み取るかもしれない。プロトコル情報は、例えば、ソースアドレス、デスティネーションアドレス、ソースポート、デスティネーションポート、プロトコルタイプ及び／又はタイムスタンプなどを含むかもしれない。演算プロセッサ５３０が第２データセットを受信すると、演算プロセッサ５３０は、選択されたモードがソース４２０（本例では、ラジオ又はマイクロフォン）からのデータに対して機能冗長性を利用すると判断するかもしれない。例えば、冗長性ルールは、ソース４２０からのデータペイロードにオーディオコンポーネントが存在すると規定するかもしれない。

演算プロセッサ５３０は、ソース４２０からのデータセットがキュー５４０に格納されているか判断するため、キュー５４０を検索するかもしれない。ソース４２０からのデータセットが特定された場合、演算プロセッサ５３０は、オーディオコンポーネントの予想される位置における第１データセットのペイロードを確認するかもしれない。演算プロセッサ５３０はまた、オーディオコンポーネントの予想される位置における第２データセットのペイロードを確認するかもしれない。演算プロセッサ５３０は、第１データセットがオーディオコンポーネントを有さず、第２データセットがオーディオコンポーネントを有しないと判断するかもしれない。第１データセットと第２データセットの両方がオーディオコンポーネントを有さず、オーディオコンポーネントを有すると予想される場合、第１データセットと第２データセットの両方の送信は、有用な情報をデスティネーション４３０に通信するものでない。従って、演算プロセッサ５４０は、第１データセットが第２データセットに機能的に冗長であるか、又は第２データセットが第１データセットに機能的に冗長であると判断するかもしれない。

一実施例では、演算プロセッサ５３０は、キュー５４０から先の第１データセットを排除するかもしれない。演算プロセッサ５３０は、その後、第２データセットをキュー５４０に追加するかもしれない。演算プロセッサ５３０は、キュー５４０の送信順序が変更されないように、第２データセットをキュー５４０に追加するかもしれない。例えば、第２データセットは、キューの該当位置において第１データセットと置換されるかもしれない。一実施例では、キューのスポットは、第１データセットが第２データセットと置換されるとき、保持される。他の実施例では、第２データセットは、キューのエンドに追加される。あるいは、演算プロセッサ５３０は、その後、ＦＩＦＯプロトコルにより第２データセットをキュー５４０に追加するかもしれない。

他の実施例では、演算プロセッサ５３０は、後の第２データセットを排除し、第１データセットをキュー５４０に残すかもしれない。一実施例では、演算プロセッサ５３０は、第２データセットをキューに追加して、第１データセットを排除するより、第２データセットを排除することが効率的であるかもしれない。第１データセットと第２データセットが全体的に同様の及び／又は同一のコンテンツを含む実施例では、システム５００は、送信のため第１データセット又は第２データセットを選択するのに差はないかもしれない。他の要因が実質的に等しい場合、演算プロセッサ５３０は、第１データセットを送信し、特定のデータについて第２データセットを削除するように、より効率的に動作するかもしれない。

機能冗長性の上記具体例は、単なる例示である。冗長性ルールは、ソース、時間、ペイロード又は他の要因に基づき、冗長なデータを規定するよう構成されるかもしれない。冗長性ルールは、単一のモード又は複数モードに適用可能であるかもしれない。モードは、単一の冗長性ルールセット又は複数の冗長性ルールセットを利用するかもしれない。

図６は、本発明の実施例による演算プロセッサ５３０のフロー図６００を示す。ステップ６１０において、第１データセットが受信され、キュー５４０に格納されている。第２データセットが受信され、演算プロセッサ５３０に通信されている。データ通信システム４１０は、ソース４２０からのデータに対して機能冗長性を利用するモードにある。第２データセットは、演算プロセッサ５３０により処理される。演算プロセッサ５３０による処理は、選択されたモードにより制御されるように、冗長性ルールデータベース５１０からの冗長性ルールに基づき、第２データセットに対して機能冗長性処理を実行するか判断することを含むかもしれない。例えば、演算プロセッサ５３０は、データセットのプロトコル情報、ペイロード及び／又はタイムスタンプなどの情報を第２データセットから読み込むかもしれない。上述されるように、プロトコル情報は、例えば、ソースアドレス、デスティネーションアドレス、ソースポート、デスティネーションポート、プロトコルタイプ及び／又はタイムスタンプなどを含むかもしれない。例えば、選択されたモードに対して、冗長性ルールデータベース５１０の冗長性ルールが、現在のデータセットに対して機能冗長性が実行されるべきであることを示す場合、演算プロセッサは、機能冗長性処理を実行する。

冗長性ルールが、機能冗長性処理が実行されるべきであることを示す場合、演算プロセッサ５３０の機能を示すフロー図は、ステップ６２０に移行する。機能冗長性ルールが、機能冗長性処理が実行されるべきでないと示す場合、演算プロセッサ５３０（フロー図）はステップ６４０に移行し、第２データセットをキュー５４０に追加する。一実施例では、キューのスポットが、第１データセットが第２データセットと置換されるとき、保持される。他の実施例では、第２データセットはキューのエンドに追加される。第２データセットがキュー５４０に追加されると、第２データセットは、デスティネーション４３０への送信を待機する。

ステップ６２０において、演算プロセッサ５３０は、冗長性ルールに従ってキュー５４０を検索する。一実施例では、演算プロセッサ５３０は、第２データセットに機能的に冗長な第１データセットをキュー５４０において検索する。上述されるように、演算プロセッサは、選択されたモードにより指定されるように、冗長性ルールデータベース５１０のルールに基づき、第１データセットが第２データセットに機能的に冗長であるか判断する。一例として、演算プロセッサ５３０は、第１データセットと第２データセットが同一のソースからのものである場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。他の例として、演算プロセッサ５３０は、第１データセットと第２データセットが同一のソースからのものであって、タイムスタンプの差が所定の閾値より大きくない場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。さらなる他の例として、演算プロセッサ５３０は、第１データセットと第２データセットとが、デスティネーション４３０に複数回送信するのに有用ではないかもしれない共通の要素を有している場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。

ステップ６２０において、演算プロセッサ５３０が、キュー５４０において機能的に冗長なデータを特定した場合、演算プロセッサ５３０はステップ６３０に移行する。ステップ６３０において、演算プロセッサは、キュー５４０において機能的に冗長なデータを特定しなかった場合、演算プロセッサ５３０はステップ６４０に移行し、送信を待機するため、第２データセットをキュー５４０に追加する。

ステップ６３０において、演算プロセッサ５３０は、キュー５４０から先の第１データセットを排除するかもしれない。その後、演算プロセッサ５３０は、後の第２データセットをキュー５４０に追加するかもしれない。一実施例では、演算プロセッサ５３０は、キュー５４０の送信順序が変更されないように、第２データセットをキュー５４０に追加するかもしれない。一実施例では、キューのスポットは、第１データセットが第２データセットに置換されるとき、保持される。他の実施例では、第２データセットはキューのエンドに追加される。演算プロセッサ５３０は、ＦＩＦＯプロトコルにより第２データセットをキュー５４０に追加するかもしれない。フロー図６００の各ステップは、帯域幅を効率的に利用するため、繰り返し実行されるかもしれない。

図７は、本発明の実施例による演算プロセッサ５３０のフロー図７００を示す。ステップ７１０において、第１データセットが受信され、キュー５４０に格納されている。第２データセットが受信され、演算プロセッサ５３０に通信されている。データ通信システム４１０は、ソース４２０からのデータに対して機能冗長性を利用するモードにある。第２データセットは、演算プロセッサ５３０により処理される。演算プロセッサ５３０による処理は、選択されたモードにより制御されるように、冗長性ルールデータベース５１０からの冗長性ルールに基づき、第２データセットに対して機能冗長性処理を実行するか判断することを含むかもしれない。例えば、演算プロセッサ５３０は、データセットのプロトコル情報、ペイロード及び／又はタイムスタンプなどの情報を第２データセットから読み込むかもしれない。上述されるように、プロトコル情報は、例えば、ソースアドレス、デスティネーションアドレス、ソースポート、デスティネーションポート、プロトコルタイプ及び／又はタイムスタンプなどを含むかもしれない。例えば、選択されたモードに対して、冗長性ルールデータベース５１０の冗長性ルールが、現在のデータセットに対して機能冗長性が実行されるべきであることを示す場合、演算プロセッサは、機能冗長性処理を実行する。

冗長性ルールが、機能冗長性処理が実行されるべきであることを示す場合、演算プロセッサ５３０の機能を示すフロー図は、ステップ７２０に移行する。機能冗長性ルールが、機能冗長性処理が実行されるべきでないと示す場合、演算プロセッサ５３０（フロー図）はステップ７４０に移行し、第２データセットをキュー５４０に追加する。第２データセットがキュー５４０に追加されると、第２データセットは、デスティネーション４３０への送信を待機する。

ステップ７２０において、演算プロセッサ５３０は、冗長性ルールに従ってキュー５４０を検索する。一実施例では、演算プロセッサ５３０は、第２データセットに機能的に冗長な第１データセットをキュー５４０において検索する。上述されるように、演算プロセッサは、選択されたモードにより指定されるように、冗長性ルールデータベース５１０のルールに基づき、第１データセットが第２データセットに機能的に冗長であるか判断する。一例として、演算プロセッサ５３０は、第１データセットと第２データセットが同一のソースからのものである場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。他の例として、演算プロセッサ５３０は、第１データセットと第２データセットが同一のソースからのものであって、タイムスタンプの差が所定の閾値より大きくない場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。さらなる他の例として、演算プロセッサ５３０は、第１データセットと第２データセットとが、デスティネーション４３０に複数回送信するのに有用ではないかもしれない共通の要素を有している場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。

ステップ７２０において、演算プロセッサ５３０が、キュー５４０において機能的に冗長なデータを特定した場合、演算プロセッサ５３０はステップ７３０に移行する。ステップ７３０において、演算プロセッサは、キュー５４０において機能的に冗長なデータを特定しなかった場合、演算プロセッサ５３０はステップ７４０に移行し、送信を待機するため、第２データセットをキュー５４０に追加する。

ステップ７３０において、演算プロセッサ５３０は、キュー５４０から後の第２データセットを排除し、第１データセットをキュー５４０に残すかもしれない。一実施例では、演算プロセッサ５３０が、第２データセットをキューに追加し、第１データセットを排除するより、第２データセットを排除することがより効率的であるかもしれない。第１データセットと第２データセットとが全体的に同様の及び／又は同一のコンテンツを含む実施例では、システム５００は、送信のため第１データセット又は第２データセットを選択するのに無関心であるかもしれない。他のファクタが実質的に同じである場合、演算プロセッサ５３０は、第１データセットを送信し、特定のデータについて第２データセットを削除するように動作することが効率的であるかもしれない。フロー図７００の各ステップは、帯域幅を効率的に利用するため、繰り返し実行されてもよい。

図８は、本発明の実施例による方法８００を示す。ステップ８１０において、第１データセットが受信される。ステップ８２０において、第１データセットがキューに格納される。ステップ８３０において、第２データセットが受信される。ステップ８４０において、第２データセットに対して機能冗長性処理を実行するか判断される。この判断は、選択されたモードと、選択されたモードに係る冗長性ルールとに依存するかもしれない。モードは、例えば、ネットワーク状態などに基づき、手動により又は自動的に選択されるかもしれない。

ステップ８５０において、キューが、第２データセットに機能的に冗長なデータセットについて検索される。キューで特定されたデータセットが現在のデータセットに機能的に冗長であるか否かは、冗長性ルールにより判断されるかもしれない。冗長性ルールは、選択されたモードにより決定されるかもしれない。一例として、冗長性ルールは、第１データセットと第２データセットとが同一のソースからのものである場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。他の例として、冗長性ルールは、第１データセットと第２データセットとが同一のソースからのものであって、それらのタイムスタンプの差が所定の閾値より大きくない場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。さらなる他の例として、冗長性ルールは、第１データセットと第２データセットとが同一の及び／又は同様のコンテンツを有する場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。

ステップ８６０において、第２データセットが第１データセットに機能的に冗長であると判断された場合、先の第１データセットがキューから排除されるかもしれない。ステップ８７０において、後の第２データセットがキューに追加されるかもしれない。一実施例では、キューの送信順序が変更されないように、第２データセットがキューに追加されるかもしれない。一実施例では、キューのスポットは、第１データセットが第２データセットに置換されるとき、保持される。他の実施例では、第２データセットは、キューのエンドに追加される。あるいは、第２データセットは、ＦＩＦＯプロトコルによりキューに追加されてもよい。フロー図８００の各ステップは、帯域幅を効率的に利用するため、繰り返し実行されてもよい。

方法８００の１以上のステップは、例えば、ハードウェア、ファームウェア及び／又はソフトウェアによる命令セットにより単独で又は組み合わせて実現されてもよい。特定の実施例は、汎用コンピュータ又は他の処理装置上で実行され、メモリ、ハードディスク、ＤＶＤ又はＣＤなどのコンピュータ可読媒体にある命令セットとして提供されるかもしれない。

本発明の特定の実施例は、列記された順序以外の順序により各ステップを実行し、及び／又は方法８００のステップの１以上を省略してもよい。例えば、一部のステップは本発明の特定の実施例では実行されないかもしれない。さらなる例として、特定のステップは、上述されたものと異なる時間的順序により同時を含めて実行されるかもしれない。

上述されたシステム及び方法８００は、コンピュータの命令セットを含むコンピュータ可読記憶媒体の一部として実行されるかもしれない。命令セットは、第１及び第２データセットを受信する受信ルーチンを含むかもしれない。命令セットはまた、第１データセットをキューに格納する格納ルーチンを含むかもしれない。命令セットはまた、冗長性ルールに基づき第２データセットに対して機能冗長性処理を実行するか判断する判定ルーチンを有するかもしれない。

冗長性ルールは、選択モードルーチンにより制御されてもよい。選択モードルーチンは、選択ルーチンにより選択されてもよい。選択ルーチンは、ユーザにより選択されてもよく、又はネットワーク状態に基づき動的に選択されてもよい。冗長性ルールは、第１データセットと第２データセットとが同一のソースノードからのものであるか判断する第１冗長性ルーチンを有するかもしれない。冗長性ルールはまた、第１データセットのタイムスタンプと第２データセットのタイムスタンプとの間の時間を決定する第２冗長性ルーチンを有するかもしれない。冗長性ルールはまた、第１データセットと第２データセットとの間に共通する要素が存在するか判断する第３冗長性ルーチンを有するかもしれない。

命令セットはまた、第１データセットについてキューを検索する検索ルーチンを有するかもしれない。第１データセットが第２データセットに機能的に冗長である場合、第１データセットはキューから排除され、第２データセットがキューに追加される。一実施例では、キューのスポットは、第１データセットが第２データセットに置換されるとき、保持される。他の実施例では、第２データセットは、キューのエンドに追加される。第２データセットのキューへの追加は、第２データセットをＦＩＦＯプロトコルによりキューに追加するＦＩＦＯルーチンを含む。

図９は、本発明の実施例による方法９００を示す。ステップ９１０において、第１データセットが受信される。ステップ９２０において、第１データセットがキューに格納される。ステップ９３０において、第２データセットが受信される。ステップ９４０において、第２データセットに対して機能冗長性処理を実行するか判断される。この判断は、選択されたモードと、選択されたモードに係る冗長性ルールとに依存するかもしれない。モードは、例えば、ネットワーク状態などに基づき、手動により又は自動的に選択されるかもしれない。

ステップ９５０において、キューが、第２データセットに機能的に冗長なデータセットについて検索される。キューで特定されたデータセットが現在のデータセットに機能的に冗長であるか否かは、冗長性ルールにより判断されるかもしれない。冗長性ルールは、選択されたモードにより決定されるかもしれない。一例として、冗長性ルールは、第１データセットと第２データセットとが同一のソースからのものである場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。他の例として、冗長性ルールは、第１データセットと第２データセットとが同一のソースからのものであって、それらのタイムスタンプの差が所定の閾値より大きくない場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。さらなる他の例として、冗長性ルールは、第１データセットと第２データセットとが同一の及び／又は同様のコンテンツを有する場合、第１データセットは第２データセットに機能的に冗長であると決定するかもしれない。

ステップ９６０において、第２データセットが第１データセットに機能的に冗長であると判断された場合、後の第２データセットがキューから排除され、第１データセットがキューに残されるかもしれない。一実施例では、第２データセットをキューに追加し、第１データセットを排除するより、第２データセットを排除することがより効率的であるかもしれない。第１データセットと第２データセットとが全体的に類似した情報を有する実施例では、送信のため、第１データセットと第２データセットの何れかが選択されるかもしれない。他のファクタが実質的に同一である場合、第１データセットを送信し、特定のデータについて第２データセットを排除することが効率的である。フロー図９００の各ステップは、帯域幅を効率的に利用するため、繰り返し実行されてもよい。

方法９００の１以上のステップは、例えば、ハードウェア、ファームウェア及び／又はソフトウェアによる命令セットにより単独で又は組み合わせて実現されてもよい。特定の実施例は、汎用コンピュータ又は他の処理装置上で実行され、メモリ、ハードディスク、ＤＶＤ又はＣＤなどのコンピュータ可読媒体にある命令セットとして提供されるかもしれない。

本発明の特定の実施例は、列記された順序以外の順序により各ステップを実行し、及び／又は方法９００のステップの１以上を省略してもよい。例えば、一部のステップは本発明の特定の実施例では実行されないかもしれない。さらなる例として、特定のステップは、上述されたものと異なる時間的順序により同時を含めて実行されるかもしれない。

上述されたシステム及び方法９００は、コンピュータの命令セットを含むコンピュータ可読記憶媒体の一部として実行されるかもしれない。命令セットは、第１及び第２データセットを受信する受信ルーチンを含むかもしれない。命令セットはまた、第１データセットをキューに格納する格納ルーチンを含むかもしれない。命令セットはまた、冗長性ルールに基づき第２データセットに対して機能冗長性処理を実行するか判断する判定ルーチンを有するかもしれない。

冗長性ルールは、選択モードルーチンにより制御されてもよい。選択モードルーチンは、選択ルーチンにより選択されてもよい。選択ルーチンは、ユーザにより選択されてもよく、又はネットワーク状態に基づき動的に選択されてもよい。冗長性ルールは、第１データセットと第２データセットとが同一のソースノードからのものであるか判断する第１冗長性ルーチンを有するかもしれない。冗長性ルールはまた、第１データセットのタイムスタンプと第２データセットのタイムスタンプとの間の時間を決定する第２冗長性ルーチンを有するかもしれない。冗長性ルールはまた、第１データセットのコンテンツが第２データセットのコンテンツに機能的に冗長であるか判断する第３冗長性ルーチンを有するかもしれない。

命令セットはまた、第１データセットについてキューを検索する検索ルーチンを有するかもしれない。第１データセットのコンテンツが第２データセットのコンテンツに機能的に冗長である場合、第１データセットを送信し、第２データセットを排除する送信ルーチンを含むかもしれない。

Claims

データ通信のＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）を制御する方法であって、
第１データセットと第２データセットとを受信するステップと、
前記第１データセットをキューに格納するステップと、
前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長であるか判断するステップであって、前記第１データセットのコンテンツは、ルールによって規定されるように十分異なっていない場合、前記第２データセットのコンテンツに機能的に冗長である、前記判断するステップと、
選択されたモードによって制御される冗長性ルールと前記第２データセットのペイロードに含まれる情報とに基づき、前記判断するステップを実行するか決定するステップと、
前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長である場合、前記第１データセットを送信し、前記第２データセットを排除するステップと、
を有する方法。
前記選択されたモードは、ユーザにより選択される、請求項１記載の方法。
前記選択されたモードは、ネットワーク状態に基づき動的に選択される、請求項１記載の方法。
前記冗長性ルールは、前記第２データセットのデータのヘッダに含まれる情報に基づき、前記判断するステップを実行するか決定する、請求項１記載の方法。
前記冗長性ルールは、前記第２データセットのソースノードに基づき、前記判断するステップを実行するか決定する、請求項１記載の方法。
前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長であるか判断するステップはさらに、前記第１データセットについて前記キューを検索し、前記ルールに基づき、前記第１データセットのコンテンツと前記第２データセットのコンテンツとを比較するステップを有する、請求項１記載の方法。
処理装置上で実行される命令セットを有するコンピュータ可読記憶媒体であって、
前記命令セットは、
第１データセットと第２データセットとを受信する受信ルーチンと、
前記第１データセットをキューに格納する格納ルーチンと、
前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長であるか判断する冗長性ルーチンであって、前記第１データセットのコンテンツは、ルールによって規定されるように十分異なっていない場合、前記第２データセットのコンテンツに機能的に冗長であり、前記判断は選択されたモードによって制御される冗長性ルールと前記第２データセットのペイロードに含まれる情報とに基づく、前記冗長性ルーチンと、
前記第１データセットのコンテンツが前記第２データセットのコンテンツに機能的に冗長である場合、前記第１データセットを送信し、前記第２データセットを排除する送信ルーチンと、
を有するコンピュータ可読記憶媒体。
データ通信のための方法であって、
第１データセットを受信するステップと、
前記第１データセットをキューに格納するステップと、
第２データセットを受信するステップと、
選択されたモードにより制御される冗長性ルールと前記第２データセットのペイロードに含まれる情報とに基づき、前記第２データセットについて機能冗長性処理を実行するか判断するステップと、
前記第１データセットについて前記キューを検索し、前記冗長性ルールに基づき、前記第１データセットが前記第２データセットに機能的に冗長であるか判断するステップであって、前記第１データセットのコンテンツは、ルールによって規定されるように十分異なっていない場合、前記第２データセットのコンテンツに機能的に冗長である、前記判断するステップと、
前記第１データセットが前記第２データセットに機能的に冗長である場合、前記第２データセットを排除するステップと、
を有する方法。