JP2009538046A

JP2009538046A - 機能的冗長型のサービス品質の方法及びシステム

Info

Publication number: JP2009538046A
Application number: JP2009511037A
Authority: JP
Inventors: エルスミス，ドナルド; ピーガルッシオ，アンソニー; ジェイナズィック，ロバート
Original assignee: Harris Corp
Current assignee: Harris Corp
Priority date: 2006-05-18
Filing date: 2007-05-15
Publication date: 2009-10-29
Anticipated expiration: 2027-05-15
Also published as: WO2007136625A3; WO2007136625A2; KR20090017611A; US20070294393A1; CA2652638C; EP2030386A4; TWI356615B; US7894509B2; CN101449532A; EP2030386A2; JP4926242B2; CA2652638A1; TW200818775A; EP2030386B1; CN101449532B; KR100989484B1

Abstract

本発明の特定の実施例は、データネットワークで帯域を保持するシステム（100）及び方法（800）（900）を提供する。この方法（800）（900）は、現在のデータセットについて機能的冗長性処理を実行するか否かを決定することを含む（840）（940）。現在のデータセットについて機能的冗長性処理を実行するか否かを決定することは、冗長ルールに従って実行されてもよい。機能的冗長性処理を実行するときに、この方法は、現在のデータセット（に対して機能的に冗長であるデータセットについて少なくとも１つのキューを検索することを含む（850）（950）。検索は、冗長ルールに従って実行されてもよい。キューにあるデータセットが現在のデータセットに対して機能的に冗長であると検出されると、キューにあるデータセットはキューから破棄され、現在のデータセットがキューに追加される（860）（960）。このように、機能的に冗長なメッセージが送信前に破棄され、帯域が最適化される。

Description

ここに開示された技術は、概して通信ネットワークに関する。特に、ここに開示された技術は、サービス品質（Quality of Service）のプロトコルフィルタリングシステム及び方法に関する。

通信ネットワークは、様々な環境で利用されている。典型的には、通信ネットワークは、１つ以上のリンクにより接続された２つ以上のノードを含む。一般的に、通信ネットワークは、リンク上の２つ以上の参加ノードと通信ネットワークの中間ノードとの間の通信をサポートするために使用される。ネットワークに多くの種類のノードが存在してもよい。例えば、ネットワークは、クライアント、サーバ、ワークステーション、スイッチ、及び／又はルータのようなノードを含んでもよい。例えば、リンクは、電話回線上のモデム接続、配線、Ethernet（登録商標）リンク、非同期転送モード（ATM：Asynchronous Transfer Mode）回線、衛星リンク、及び／又は光ファイバケーブルでもよい。

実際に、通信ネットワークは、１つ以上の小さい通信ネットワークで構成されてもよい。例えば、インターネットは、相互接続されたコンピュータネットワークのネットワークとして、しばしば記載されている。各ネットワークは、異なるアーキテクチャ及び／又はトポロジを利用してもよい。例えば、１つのネットワークはスタートポロジーの交換Ethernet（登録商標）ネットワークでもよく、他のネットワークは、FDDI（Fiber-Distributed Data Interface）リングでもよい。

通信ネットワークは広範囲のデータを伝達してもよい。例えば、ネットワークは、インタラクティブなリアルタイム会話のデータと共にバルクファイル転送を伝達してもよい。ネットワークで送信されるデータは、しばしばパケット、セル又はフレームで送信される。代替として、データはストリームとして送信されてもよい。或る場合には、データのストリーム又はフローは、実際のパケットのシーケンスでもよい。インターネットのようなネットワークは、一連のノードの間で汎用のデータパスを提供し、異なる要件の多くのデータを伝達する。

ネットワークでの通信は、典型的には複数のレベルの通信プロトコルを含む。プロトコルスタック（ネットワーキングスタック又はプロトコルスイートとも呼ばれる）は、通信に使用されるプロトコルの集合を示す。各プロトコルは、特定の種類の機能又は特定の形式の通信を専門としてもよい。例えば、１つのプロトコルは、導線により接続された装置と通信するために必要な電気信号に関係してもよい。例えば、他のプロトコルは、多くの中間ノードにより分離された２つのノードの間での順序のある信頼できる送信を扱ってもよい。

典型的には、プロトコルスタックのプロトコルは階層に存在する。しばしば、プロトコルはレイヤに分類される。プロトコルレイヤの１つの参照モデルは、OSI（Open Systems Interconnection）モデルである。OSI参照モデルは、７つのレイヤ（物理レイヤ、データリンクレイヤ、ネットワークレイヤ、トランスポートレイヤ、セッションレイヤ、プレゼンテーションレイヤ、及びアプリケーションレイヤ）を含む。物理レイヤは、“最も低い”レイヤであり、アプリケーションレイヤは、“最も高い”レイヤである。２つの周知のトランスポートレイヤプロトコルは、TCP（Transmission Control Protocol）及びUDP（User Datagram Protocol）である。周知のネットワークレイヤプロトコルは、IP（Internet Protocol）である。

送信ノードでは、送信されるデータは、最も高いものから最も低いものに、プロトコルスタックのレイヤを下に伝えられる。逆に、受信ノードでは、データは、最も低いものから最も高いものに、レイヤを上に伝えられる。各レイヤでは、データは、そのレイヤのプロトコル処理通信により扱われ得る。例えば、トランスポートレイヤプロトコルは、宛先ノードに到達したときにパケットの並び替えを可能にするヘッダをデータに追加してもよい。アプリケーションに応じて、或るレイヤは存在しても使用されなくてもよく、データは単に通過してもよい。

１つの種類の通信ネットワークは、戦術データネットワーク（tactical data network）である。戦術データネットワークはまた、戦術通信ネットワークとも呼ばれることがある。戦術データネットワークは、軍隊（例えば、陸軍、海軍及び／又は空軍）のような組織内の部隊により利用され得る。例えば、戦術データネットワーク内のノードは、個々の軍人、航空機、指揮部隊、衛星、及び／又は無線機を含んでもよい。戦術データネットワークは、音声、位置測定データ、センサデータ、及び／又はリアルタイムビデオのようなデータを通信するために使用され得る。

どのように戦術データネットワークが使用され得るかの例は以下の通りである。後方支援部隊は、戦場の戦闘部隊に供給品を提供するためにルート内に存在し得る。後方支援部隊及び戦闘部隊は、衛星無線リンクで位置測定データを指揮所に提供していてもよい。無人機（UAV：unmanned aerial vehicle）は、部隊がいる道路を巡回しており、同様に衛星無線リンクでリアルタイムビデオデータを指揮所に送信していてもよい。指揮所では、コントローラが道路の特定の部分のビデオを提供するようにUAVに作業させている間に、分析者はビデオデータを検査していてもよい。分析者は、部隊が近づいている簡易爆発物（IED：improvised explosive device）を見つけ、直接無線リンクで部隊に止まるように命令を送信し、IEDの存在を部隊に警告する。

戦術データネットワーク内に存在し得る様々なネットワークは、多くの異なるアーキテクチャ及び特性を有し得る。例えば、指揮部隊のネットワークは、衛星への無線リンクと共に、ギガビットEthernet（登録商標）ローカルエリアネットワーク（LAN）を含んでもよく、作業部隊は、かなり低いスループット及び高い待ち時間で動作してもよい。作業部隊は、衛星及び直接パス無線周波数（RF：radio frequency）を介して通信してもよい。データは、データの性質及び／又はネットワークの特定の物理特性に応じて、ポイント・ツー・ポイント、マルチキャスト、又はブロードキャストで送信されてもよい。例えば、ネットワークは、データを中継するために設定された無線機を含んでもよい。更に、ネットワークは、長距離通信を可能にする高周波数（HF：high frequency）ネットワークを含んでもよい。例えば、マイクロ波ネットワークも使用されてもよい。他にも理由があるが、リンク及びノードの種類の多様性のため、戦術ネットワークは、しばしば過度に複雑なネットワークアドレス方式及びルーティングテーブルを有する。更に、無線型ネットワークのような或るネットワークは、バーストを使用して動作してもよい。すなわち、継続的にデータを送信するのではなく、データの定期的なバーストを送信する。無線機は参加者により共有される特定のチャネルでブロードキャストしており、一度に唯一の無線機が送信してもよいため、このことは有用である。

戦術データネットワークは、一般的に帯域に制約される。すなわち、何らかの所定の時点で、利用可能な帯域より一般的に多くのデータが通信される。例えば、これらの制約は、供給を超える帯域の需要のためであることがあり、及び／又はユーザの需要を満たすのに十分な帯域を供給しない利用可能な通信技術のためであることがある。例えば、或るノードの間で、帯域はキロビット／秒の単位になり得る。帯域に制約のある戦術データネットワークでは、あまり重要でないデータがネットワークを詰まらせ、より重要なデータが時間通りに通過することを妨げることがあり、或いは受信ノードに全く到達しないこともある。更に、ネットワークの一部は、信頼のないリンクを補うために内部バッファを含み得る。これは更なる遅延を生じることがある。更に、バッファが一杯になると、データが破棄されることがある。

多くの場合に、ネットワークに利用可能な帯域は増加不可能である。例えば、衛星通信リンクで利用可能な帯域は固定され、他の衛星を配置せずには有効に増加できない。これらの場合、帯域は需要に対処するように単に拡張されるのではなく、管理されなければならない。大規模システムでは、ネットワーク帯域は重要なリソースである。アプリケーションができるだけ効率的に帯域を利用することが望ましい。更に、アプリケーションが“パイプを詰まらせる（clogging the pipe）”ことを回避することが望ましい。すなわち、帯域が制限されているときに、データでリンクを圧倒することを回避することが望ましい。帯域割り当てが変化すると、好ましくは、アプリケーションは反応すべきである。帯域は、例えば、サービス品質、電波妨害、信号障害、優先度再割り当て、及び視野方向のため、動的に変化し得る。ネットワークはかなり不安定になる可能性があり、利用可能な帯域が急激に予告なしに変化する可能性がある。

帯域の制約に加えて、戦術データネットワークは、高い待ち時間を受けることがある。例えば、衛星リンクで通信に関与するネットワークは、0.5秒以上のオーダーの待ち時間を生じ得る。或る通信では、これは問題にならない可能性があるが、他の場合（リアルタイム、インタラクティブ通信（例えば、音声通信）等）では、できるだけ待ち時間を最小化することがかなり望ましい。

多くの戦術データネットワークに共通する他の特性は、データ損失である。データは、様々な理由で失われ得る。例えば、送信するデータを有するノードが損傷又は破壊されることがある。他の例として、宛先ノードは、一時的にネットワークから見えなくなることがある。これは、例えば、ノードが範囲外に移動したため、通信リンクが妨害されたため、及び／又はノードが電波妨害されたために生じることがある。宛先ノードが受信することができず、宛先ノードが利用可能になるまで中間ノードがデータをバッファするのに十分な容量を欠いているため、データが失われることがある。更に、中間ノードは、データを全くバッファしないことがあり、その代わりに、データが実際に宛先に到達したか否かを決定することを送信ノードに任せる。

しばしば、戦術データネットワークのアプリケーションは、ネットワークの特定の特性を認識及び／又は考慮しない。例えば、アプリケーションは、必要なだけ利用可能な大きい帯域を有することを単に仮定し得る。他の例として、アプリケーションは、データがネットワークで失われないことを仮定し得る。基礎となる通信ネットワークの特定の特性を考慮しないアプリケーションは、実際に問題を悪化させるように振る舞うことがある。例えば、アプリケーションは、大きい束であまり頻繁でなく有効に送信され得るかのように、データのストリームを継続して送信し得る。例えば、連続するストリームは、他のノードが通信することを有効に不足させるブロードキャスト無線ネットワークでは、かなり大きいオーバーヘッドを生じる可能性があり、その一方で、あまり頻繁でないバーストは、共有帯域が有効に使用されることを可能にする。

特定のプロトコルは、戦術データネットワークではうまく動作しない。例えば、TCPのようなプロトコルは、このようなネットワークが直面し得る高い損失率及び待ち時間のため、無線型戦術ネットワークでうまく機能しない可能性がある。TCPは、データを送信するために、いくつかの種類のハンドシェーク及び送達確認が生じることを必要とする。高い待ち時間及び損失は、TCPがタイムアウトになり、存在しても多くの重要なデータをこのようなネットワークで送信することができないことを生じ得る。

戦術データネットワークで通信される情報は、ネットワークの他のデータに対してしばしば様々なレベルの優先度を有する。例えば、飛行機の危険警告受信機は、数マイル離れた地上の部隊の位置測定情報より高い優先度を有し得る。他の例として、交戦に関する本部からの命令は、友好ラインの背後での後方支援の通信より高い優先度を有し得る。優先レベルは、送信機及び／又は受信機の特定の状況に依存し得る。例えば、位置測定データは、部隊が標準的な巡回ルートに単に従っているときに比べて、部隊が積極的に戦闘に関与しているときにかなり高い優先度になり得る。同様に、UAVからのリアルタイムデータは、単にルート内にいるときに比べて、目標地域上にいるときに高い優先度を有し得る。

ネットワークでデータを配信する複数の手法が存在する。多くの通信ネットワークにより使用される１つの手法は、“ベストエフォート型”手法である。すなわち、通信されるデータは、他の需要を前提として、容量、待ち時間、信頼性、並び替え及びエラーに関してネットワークが可能な限り処理される。従って、ネットワークは、何らかの所定のデータが時間通りに、又はとにかく宛先に到達するという保証を提供しない。更に、送信された順序で、又はデータの１つ以上のビットを変更する送信エラーなしにデータが到達するという保証も行われない。

他の手法は、サービス品質（QoS：Quality of Service）である。QoSは、伝達されるデータに関して様々な種類の保証を提供するネットワークの１つ以上の機能を示す。例えば、QoSをサポートするネットワークは、データストリームに対して特定の量の帯域を保証し得る。他の例として、ネットワークは、２つの特定のノードの間のパケットが何らかの最大の待ち時間を有することを保証し得る。このような保証は、２つのノードがネットワークで会話を有する２人の人間である音声通信の場合に有用になり得る。例えば、このような場合のデータ配信の遅延は、通信の不愉快な途切れ及び／又は全くの静寂を生じ得る。

QoSは、選択されたネットワークトラヒックにより良いサービスを提供するネットワークの機能としてみなされ得る。QoSの主な目標は、専用の帯域と、制御されたジッタ及び待ち時間（何らかのリアルタイムのインタラクティブなトラヒックにより要求される）と、改善した損失特性とを含む優先度を提供することである。他の重要な目標は、１つのフローの優先度を提供することで他のフローが失敗しないことを確保することである。すなわち、次のフローについて行われる保証は、既存のフローに行われた保証を壊してはならない。

QoSへの現在の手法は、しばしばネットワークの各ノードがQoSをサポートすること、或いは最低限でも特定の通信に関与するネットワークの各ノードがQoSをサポートすることを必要とする。例えば、現在のシステムでは、２つのノードの間の待ち時間の保証を提供するために、これらの２つのノードの間でトラヒックを伝達する各ノードは、特典（honor）を認識して合意し、保証を履行することができなければならない。

QoSを提供する複数の手法が存在する。１つの手法は、Integrated Services又は“IntServ”である。IntServは、ネットワークの各ノードがサービスをサポートし、接続が設定されるときにこれらのサービスが確保されるQoSシステムである。IntServは、各ノードで維持されなければならない大量の状態情報と、このような接続を設定することに関連するオーバーヘッドとのため、あまりスケーラビリティがない。

QoSを提供する他の手法は、Differentiated Services又は“DiffServ”である。DiffServは、インターネットのようなネットワークのベストエフォート型サービスを拡張したサービスモデルの一種である。DiffServは、ユーザ、サービス要件及び他の基準により、トラヒックを区別する。次に、DiffServは、優先キュー若しくは帯域割り当てを介して、又は特定のトラヒックフローの専用ルートを選択することにより、ネットワークノードが異なるレベルのサービスを提供できるようにパケットにマークを付ける。典型的には、ノードはサービスのクラス毎に様々なキューを有する。ノードは、クラスのカテゴリに基づいて、これらのキューから送信する次のパケットを選択する。

既存のQoSの対策は、しばしばネットワーク特有であり、各ネットワーク形式又はアーキテクチャは、異なるQoS構成を必要とし得る。既存のQoSの対策が利用する機構のため、現在のQoSシステムと同じように見えるメッセージは、メッセージ内容に基づいて実際に異なる優先度を有し得る。しかし、データ消費者は、低優先度のデータで溢れることなく、高優先度のデータにアクセスすることを必要とし得る。既存のQoSシステムは、トランスポートレイヤでのメッセージ内容に基づくQoSを提供することができない。

前述のように、既存のQoSの対策は、QoSをサポートするために特定の通信に関与するノードを少なくとも必要とする。しかし、ネットワークの“エッジ”にあるノードは、総合的な保証を行うことができなくても、QoSへの何らかの改善を提供するように適合され得る。ノードは、通信の参加ノード（すなわち、送信及び／又は受信ノード）である場合、及び／又はネットワークの関所（chokepoint）に位置する場合、ネットワークのエッジにあると考えられる。関所は、他の部分に対して全てのトラヒックが通過しなければならないネットワークの部分である。LANから衛星リンクへのルータ又はゲートウェイは関所である。この理由は、LANからLAN上にない何らかのノードへの全てのトラヒックは衛星リンクへのゲートウェイを通過しなければならないからである。

従って、戦術データネットワークでQoSを提供するシステム及び方法の必要性が存在する。戦術データネットワークのエッジでQoSを提供するシステム及び方法の必要性が存在する。更に、戦術データネットワークで適応可能な構成可能なQoSシステム及び方法の必要性が存在する。

本発明の実施例は、データ通信方法を提供する。この方法は、第１のデータセットを受信し、第１のデータセットをキューに格納することを含む。この方法はまた、第２のデータセットを受信することを含む。次に、この方法は、冗長ルールに基づいて第２のデータセットについて機能的冗長性処理を実行するか否かを決定することを含む。冗長ルールは、選択されたモードにより制御されてもよい。次に、この方法は、第１のデータセットについてキューを検索し、冗長ルールに基づいて第１のデータセットが第２のデータセットに対して機能的に冗長であるか否かを決定することを含む。第１のデータセットが第２のデータセットに対して機能的に冗長である場合、第１のデータセットはキューから破棄され、第２のデータセットがキューに追加される。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。

本発明の特定の実施例は、処理装置で実行する一式の命令を有するコンピュータ可読媒体を提供する。一式の命令は、第１のデータセットと第２のデータセットとを受信する受信ルーチンを含む。一式の命令はまた、第１のデータセットをキューに格納する格納ルーチンを含む。一式の命令はまた、冗長ルールに基づいて第２のデータセットについて機能的冗長性処理を実行するか否かを決定する決定ルーチンを含む。冗長ルールは、選択されたモードにより制御される。一式の命令はまた、第１のデータセットについてキューを検索し、冗長ルールに基づいて第１のデータセットが第２のデータセットに対して機能的に冗長であるか否かを決定する検索ルーチンを含む。第１のデータセットが第２のデータセットに対して機能的に冗長である場合、第１のデータセットをキューから破棄し、第２のデータセットをキューに追加する。

本発明の特定の実施例は、データ通信方法を含む。この方法は、第１のデータセットを受信し、第２のデータセットを受信することを有する。この方法はまた、選択されたモードを検査し、第２のデータセットで機能的冗長性処理を実行するか否かを決定することを含む。選択されたモードは、機能的冗長性処理を実行するか否かを決定する一式の冗長ルールを有する。この方法はまた、第２のデータセットが第１のデータセットに対して機能的に冗長であるか否かを決定することにより、機能的冗長性処理を実行することを含む。第２のデータセットは、一式の冗長ルールに従って第１のデータセットに対して機能的に冗長である。第１のデータセットが第２のデータセットに対して機能的に冗長である場合、第１のデータセットをキューから破棄し、第２のデータセットをキューに追加する。

本発明の実施例で動作する戦術通信ネットワーク環境本発明の実施例による７レイヤのOSIネットワークモデルにおけるデータ通信システムの位置本発明の実施例によるデータ通信システムを使用して容易になる複数ネットワークの例本発明の実施例で動作するデータ通信環境本発明の実施例で動作するデータ通信環境本発明の実施例によるフローチャート本発明の実施例によるフローチャート本発明の実施例による方法本発明の実施例による方法

前述の要約及び本発明の特定の実施例の以下の詳細な説明は、添付図面と共に読まれたときに良く理解される。本発明を説明する目的で、特定の実施例が図面に示されている。しかし、本発明は、添付図面に示す構成及び手段に限定されない。

図１は、本発明の実施例で動作する戦術通信ネットワーク環境100を示している。ネットワーク環境100は、複数の通信ノード110と、１つ以上のネットワーク120と、ノード及びネットワークを接続する１つ以上のリンク130と、ネットワーク環境100の構成要素での通信を容易にする１つ以上の通信システム150とを含む。以下の説明は、１つより多くのネットワーク120と１つより多くのリンク130とを含むネットワーク環境100を仮定するが、他の環境も可能であり想定されることがわかる。

例えば、通信ノード110は、無線機、送信機、衛星、受信機、ワークステーション、サーバ、及び／又は他の計算若しくは処理装置でもよく、及び／又はこれらを含んでもよい。

例えば、ネットワーク120は、ノード110の間でデータを送信するハードウェア及び／又はソフトウェアでもよい。例えば、ネットワーク120は、１つ以上のノード110を含んでもよい。

リンク130は、ノード110及び／又はネットワーク120の間での送信を可能にする有線及び／又は無線接続でもよい。

例えば、通信システム150は、ノード110とネットワーク120とリンク130との間でデータ送信を容易にするために使用されるソフトウェア、ファームウェア及び／又はハードウェアを含んでもよい。図１に示すように、通信システム150は、ノード110、ネットワーク120及び／又はリンク130に関して実装されてもよい。特定の実施例では、各ノード110が通信システム150を含む。特定の実施例では、１つ以上のノード110が通信システム150を含む。特定の実施例では、１つ以上のノード110が通信システム150を含まなくてもよい。

通信システム150は、戦術通信ネットワーク（ネットワーク環境100等）での通信を確保するために役立つデータの動的な管理を提供する。図２に示すように、特定の実施例では、システム150は、OSIの7レイヤのプロトコルモデルにおけるトランスポートレイヤの一部として及び／又は上位で動作する。例えば、システム150は、戦術ネットワークでトランスポートレイヤに渡される高優先度のデータを優先してもよい。システム150は、単一のネットワーク（ローカルエリアネットワーク（LAN）又は広域ネットワーク（WAN）等）での通信又は複数のネットワークを通じた通信を容易にするために使用されてもよい。複数ネットワークシステムの例が図３に示されている。例えば、システム150は、ネットワークに更なる帯域を追加するのではなく、利用可能な帯域を管理するために使用されてもよい。

特定の実施例では、システム150は、ソフトウェアシステムであるが、様々な実施例で、システム150は、ハードウェア構成要素とソフトウェア構成要素との双方を含んでもよい。例えば、システム150は、ネットワークハードウェアと独立してもよい。すなわち、システム150は、様々なハードウェア及びソフトウェアプラットフォームで機能するように適合されてもよい。特定の実施例では、システム150は、ネットワークの内部のノードではなく、ネットワークのエッジで動作する。しかし、システム150は、ネットワークの“関所（choke point）”のようなネットワークの内部で同様に動作してもよい。

システム150は、利用可能な帯域の最適化、情報優先度の設定、及びネットワークでのデータリンクの管理のようなスループット管理機能を実行するために、ルール及びモード又はプロファイルを使用してもよい。例えば、帯域使用の最適化は、機能的に冗長なメッセージを除去すること、メッセージストリーム管理又は順序付け、及びメッセージ圧縮を含んでもよい。帯域の“最適化”は、ここに記載の技術が１つ以上のネットワークでデータを通信するための帯域使用の効率を増加させるために使用され得ることを意味する。例えば、情報優先度の設定は、インターネットプロトコル（IP）型技術より細かい精度でメッセージ形式を区別すること、及び選択されたルール型順序付けアルゴリズムを介してデータストリームにメッセージを順序付けることを含んでもよい。例えば、データリンク管理は、ルール、モード及び／又はデータ転送における変化に影響を及ぼすネットワーク測定のルール型分析を含んでもよい。モード又はプロファイルは、特定のネットワーク健康状態又は状況の動作上の必要性に関する一式のルールを含んでもよい。システム150は、進行中に新しいモードを規定して切り替えることを含み、モードの動的な“進行中（on-the-fly）”の再構成を提供する。

通信システム150は、例えば不安定な帯域に制約のあるネットワークで、変化する優先度及びサービスのグレードに適応するように構成されてもよい。システム150は、ネットワークの応答能力を増加させ、通信待ち時間を低減することに役立つように、改善したデータフローの情報を管理するように構成されてもよい。更に、システム150は、通信の可用性と残存力と信頼性とを改善するようにアップグレード可能でスケーラブルである柔軟なアーキテクチャを介して、相互運用性を提供してもよい。例えば、システム150は、所定の予測可能なシステムリソース及び帯域を使用しつつ、動的に変化する環境に自律的に適応可能になり得るデータ通信アーキテクチャをサポートする。

特定の実施例では、システム150は、ネットワークを使用するアプリケーションに対してトランスペアレントのままで、帯域に制約のある戦術通信ネットワークにスループット管理を提供する。システム150は、ネットワークへの低減した複雑性で、複数のユーザ及び環境を通じたスループット管理を提供する。前述のように、特定の実施例では、システム150は、OSIの7レイヤのモデルのレイヤ4（トランスポートレイヤ）で及び／又はその上位でホストノードを動作し、専用のネットワークハードウェアを必要としない。システム150は、レイヤ4インタフェースに対してトランスペアレントに動作してもよい。すなわち、アプリケーションは、トランスポートレイヤについて標準的なインタフェースを利用し、システム150の動作を認識しなくてもよい。例えば、アプリケーションがソケットをオープンすると、システム150は、プロトコルスタックのこのポイントでデータをフィルタリングしてもよい。システム150は、アプリケーションがシステム150に特有のインタフェースではなく、例えばネットワーク上の通信装置のオペレーティングシステムにより提供されるTCP/IPソケットインタフェースを使用することを可能にすることにより、トランスペアレント性を実現する。例えば、システム150のルールは、XML（extensible markup language）で記述されてもよく、及び／又はカスタムのDLL（dynamic link library）を介して提供されてもよい。

特定の実施例では、システム150は、ネットワークのエッジでサービス品質（QoS）を提供する。例えば、システムのQoS機能は、ネットワークのエッジでコンテンツ型のルール型のデータ優先付けを提供する。例えば、優先付けは、区別及び／又は順序付けを含んでもよい。例えば、システム150は、ユーザ構成可能な区別ルールに基づいて、メッセージをキューに区別してもよい。メッセージは、ユーザ構成の順序付けルール（例えば、スターベーション（starvation）、ラウンドロビン、相対頻度等）により記述される順序で、データストリームに順序付けされてもよい。例えば、エッジでQoSを使用して、通常のQoSの手法で区別不可能なデータメッセージは、メッセージ内容に基づいて区別されてもよい。例えば、ルールは、XMLで実装されてもよい。特定の実施例では、XMLを超える機能に適応するため、及び／又は極めて低い待ち時間の要件をサポートするため、例えば、システム150は、動的リンクライブラリがカスタムコードを備えることを可能にする。

ネットワークのインバウンド及び／又はアウトバウンドデータは、システム150を介してカスタマイズされてもよい。例えば、優先付けは、大量の低優先度のデータからクライアントアプリケーションを保護する。システム150は、アプリケーションが特定の動作シナリオ又は制約をサポートするデータを受信することを確保することに役立つ。

特定の実施例では、帯域に制約のある戦術ネットワークへのインタフェースとしてのルータを含むLANにホストが接続されると、システムは、プロキシによるQoSとして知られる構成で動作してもよい。この構成では、ローカルLANに向かうパケットは、システムをバイパスし、直ちにLANに進む。システムは、帯域に制約のある戦術ネットワークに向かうパケットにネットワークのエッジでQoSを適用する。

特定の実施例では、システム150は、命令プロファイル交換（commanded profile switching）を介して、複数の動作シナリオ及び／又はネットワーク環境について動的なサポートを提供する。プロファイルは、ユーザ又はシステムが指名されたプロファイルに変更することを可能にする名前又は他の識別子を含んでもよい。例えば、プロファイルはまた、機能的冗長ルール識別子、区別ルール識別子、アーカイバル（archival）インタフェース識別子、順序付けルール識別子、事前送信インタフェース識別子、事後送信インタフェース識別子、トランスポート識別子、及び／又は他の識別子のような１つ以上の識別子を含んでもよい。例えば、機能的冗長ルール識別子は、データの陳腐化又は実質的に類似のデータのような機能的な冗長性を検出するルールを指定する。例えば、区別ルール識別子は、メッセージを処理するキューに区別するルールを指定する。例えば、アーカイバルインタフェース識別子は、アーカイバルシステムへのインタフェースを指定する。順序付けルール識別子は、キューのフロントのサンプルを制御する順序付けアルゴリズムを特定し、従って、データストリームでのデータの順序付けを特定する。例えば、事前送信インタフェース識別子は、暗号化及び圧縮のような特別の処理を提供する事前送信処理のインタフェースを指定する。例えば、事後送信インタフェース識別子は、復号化及び解凍のような処理を提供する事後送信処理のインタフェースを特定する。トランスポート識別子は、選択されたトランスポートのネットワークインタフェースを指定する。

例えば、プロファイルはまた、キューサイズ情報のような他の情報を含んでもよい。例えば、キューサイズ情報は、キューの数と、各キューに専用の二次記憶装置及びメモリの量とを特定する。

特定の実施例では、システム150は、帯域を最適化するためにルール型手法を提供する。例えば、システム150は、メッセージをメッセージキューに区別するためにキュー選択ルールを使用してもよく、これにより、メッセージがデータストリームの優先度と適切な相対頻度とを割り当てられてもよい。システム150は、機能的に冗長なメッセージを管理するために、機能的冗長ルールを使用してもよい。例えば、ネットワークでまだ送信されていない前のメッセージと（ルールにより規定されるように）十分に異ならない場合、メッセージは機能的に冗長である。すなわち、送信されるように既にスケジューリングされた古いメッセージと十分に異ならないが、まだ送信されていない新しいメッセージが提供された場合、新しいメッセージは破棄されてもよい。この理由は、古いメッセージが機能的に同等の情報を伝達しており、キューの更に前にあるからである。更に、機能的冗長の多くは、実際に重複したメッセージと、古いメッセージが送信される前に到達する新しいメッセージとを含んでいる。例えば、ノードは、基礎のネットワークの特性のため、耐障害性の理由で２つの異なるパスにより送信されたメッセージのように、特定のメッセージの同一のコピーを受信してもよい。他の例として、新しいメッセージは、まだ送信されていない古いメッセージに取り代わるデータを含んでもよい。この状態で、システム150は、古いメッセージを破棄し、新しいメッセージのみを送信してもよい。システム150はまた、データストリームの優先度型メッセージシーケンスを決定する優先度順序付けルールを含んでもよい。更に、システム150は、圧縮及び／又は暗号化のように、事前送信及び事後送信専用の処理を提供する送信処理ルールを含んでもよい。

特定の実施例では、システム150は、データインテグリティ及び信頼性を保護することに役立つため、耐障害性機能を提供する。例えば、システム150は、メッセージをキューに区別するために、ユーザ定義のキュー選択ルールを使用してもよい。例えば、キューは、ユーザ定義の構成に従ってサイズ決定される。例えば、この構成は、キューが消費し得る最大量のメモリを指定する。更に、この構成は、ユーザがキューのオーバーフローに使用され得る二次記憶装置の位置及び量を指定することを可能にし得る。キューのメモリが一杯になった後に、メッセージは、二次記憶装置のキューに入れられてもよい。二次記憶装置も一杯になると、システム150は、キューの最も古いメッセージを除去し、エラーメッセージをログ記録し、最新のメッセージをキューに入れてもよい。動作モードでアーカイブが可能である場合、キューから外れたメッセージは、メッセージがネットワークで送信されていないというインジケータと共にアーカイブされてもよい。

例えば、システム150のキューのメモリ及び二次記憶装置は、特定のアプリケーションについてリンク毎に構成されてもよい。ネットワークの可用性の期間の間の長い時間は、ネットワーク故障をサポートする多くのメモリ及び二次記憶装置に相当し得る。例えば、キューが適切にサイズ決定されることを確保するのに役立ち、故障の間の時間が定常状態を実現するのに役立ち、最終的なキューのオーバーフローを回避することに役立つのに十分であることを確保するのに役立つように、サイズ決定を特定するのに役立つため、システム150は、ネットワークモデリング及びシミュレーションアプリケーションと統合されてもよい。

更に、特定の実施例では、システム150は、インバウンド（“シェーピング処理（shaping）”）データ及びアウトバウンド（“ポリシー処理（policing）”）データを測定（調節）する機能を提供する。ポリシー処理及びシェーピング処理機能は、ネットワークのタイミングの不一致に対処することに役立つ。シェーピング処理は、ネットワークバッファが低優先度のデータの後のキューに入れられた高優先度のデータで溢れることを回避するのに役立つ。ポリシー処理は、データ消費者が低優先度のデータで溢れることを回避するのに役立つ。ポリシー処理及びシェーピング処理は、２つのパラメータ（有効リンク速度及びリンク比率）により支配される。例えば、システム150は、リンク比率で乗算された有効リンク速度より大きくないデータストリームを形成してもよい。パラメータは、ネットワークが変化すると共に動的に変更されてもよい。システムはまた、検出されたリンク速度へのアクセスを提供し、データ測定でアプリケーションレベルの判定をサポートしてもよい。システム150により提供される情報は、何のリンク速度が所定のネットワークシナリオに適切であるかを判定することに役立つ他のネットワーク動作情報と結合されてもよい。

図４は、本発明の実施例で動作するデータ通信環境400を示している。環境400は、データ通信システム410と、１つ以上のソースノード420と、１つ以上の宛先ノード430とを含む。データ通信システム410は、ソースノード420及び宛先ノード430と通信している。例えば、データ通信システム410は、有線、無線、衛星、ネットワークリンクのようなリンクで、及び／又はプロセス間通信を通じて、ソースノード420及び／又は宛先ノード430と通信してもよい。特定の実施例では、データ通信システム410は、１つ以上の戦術データネットワークで１つ以上のソースノード420及び／又は宛先ノード430と通信してもよい。システム400の構成要素は、単一のユニットでもよく、別々のユニットでもよく、様々な形式で統合されてもよく、ハードウェア及び／又はソフトウェアに実装されてもよい。

例えば、データ通信システム410は、前述の通信システム150と同様のものでもよい。特定の実施例では、データ通信システム410は、１つ以上のソースノード420からデータを受信するように適合される。特定の実施例では、データ通信システム410は、コンピュータ命令とルールとを格納するメモリユニット及び／又はデータベースを含んでもよい。データ通信システム410はまた、データとルールと命令とを処理するプロセッサを含んでもよい。特定の実施例では、データ通信システム410は、データを格納、構成及び／又は優先付けする１つ以上のキューを含んでもよい。代替として、データを格納、構成及び／又は優先付けする他のデータ構造が使用されてもよい。例えば、テーブル、ツリー又は連結リストが使用されてもよい。特定の実施例では、データ通信システム410は、１つ以上の宛先ノード430にデータを通信するように適合される。

特定の実施例では、データ通信システム410は、他のアプリケーションに対してトランスペアレントである。例えば、データ通信システム410により実行される処理、構成及び／又は優先付けは、１つ以上のソースノード420又は他のアプリケーション若しくはデータソースにトランスペアレントでもよい。例えば、データ通信システム410と同じシステム又はデータ通信システム410に接続されたソースノード420で動作するアプリケーションは、データ通信システム410により実行されるデータの優先付けを認識しなくてもよい。

例えば、データ通信システム410の構成要素、要素及び／又は機能は、単独で、又は様々な形式のハードウェア、ファームウェアの組み合わせで、及び／又はソフトウェアの一式の命令として実装されてもよい。特定の実施例は、汎用コンピュータ又は他の処理装置で実行するコンピュータ可読媒体（メモリ、ハードディスク、DVD又はCD等）に存在する一式の命令として提供されてもよい。

ソースノード420は、データ又は遠隔測定情報を収集するセンサ又は測定装置を含んでもよい。例えば、ソースノード420は、移動輸送手段（タンク、ハンビー（humvee）ユニット、個人用輸送車、又は個々の軍人等）の位置データを示すGPS（Global Positional System）センサでもよい。他の例では、ソースノード420は、映像又は画像を取得するビデオ又は静止画カメラのような撮影ユニットでもよい。他の例では、ソースノードは、無線機又はマイクロフォンのような通信モジュールでもよい。宛先ノード430は、ソースノード420により取得されたデータに関心のある如何なる装置又はシステムでもよい。例えば、宛先ノード430は、指揮所又は偵察部隊により利用される受信機、中央コンピュータシステム、及び／又はコンピュータでもよい。

データ通信システム410により受信、格納、優先付け、処理、通信、及び／又は送信されたデータは、データのブロックを含んでもよい。例えば、データのブロックは、パケット、セル、フレーム、及び／又はストリームでもよい。例えば、データ通信システム410は、ソースノード420からデータのパケットを受信してもよい。他の例として、データ通信システム410は、ソースノード420からのデータのストリームを処理してもよい。

特定の実施例では、データはプロトコル情報を含む。例えば、プロトコル情報は、データを通信するために１つ以上のプロトコルにより使用されてもよい。例えば、プロトコル情報は、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、及び／又はプロトコル形式を含んでもよい。例えば、ソース及び／又は宛先アドレスは、ソースノード420及び／又は宛先ノード430のIPアドレスでもよい。プロトコル形式は、データの通信の１つ以上のレイヤに使用されるプロトコルの種類を含んでもよい。例えば、プロトコル形式は、TCP（Transmission Control Protocol）、UDP（User Datagram Protocol）、又はSCTP（Stream Control Transmission Protocol）のようなトランスポートプロトコルでもよい。他の例として、プロトコル形式は、IP（Internet Protocol）、IPX（Internetwork Packet Exchange）、Ethernet（登録商標）、ATM（Asynchronous Transfer Mode）、FTP（File Transfer Protocol）、及び／又はRTP（Real-time Transport Protocol）を含んでもよい。特定の実施例では、データはまた、タイムスタンプ情報を含んでもよい。例えば、タイムスタンプ情報は、ソースノード420によるデータ取得時間を示してもよい。

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

実施例では、ソースノード420及びデータ通信システム410は、同じ移動ユニットの一部でもよい。移動ユニットは、タンク、ハンビーユニット、個人用輸送車、又は個々の軍人、無人機（UAV：unmanned aerial vehicle）、又は他の移動ユニットでもよい。タンクは、ソースユニット420として位置データを示すGPSセンサを有してもよい。位置データは、データ通信システム410に通信されてもよい。データ通信システム410は、タンクに配置されてもよい。データ通信システム410は、宛先ノード430に通信するデータを準備してもよい。宛先ノードへの通信の準備の一部として、データ通信システム410は、何らかの形式のネットワークアクセスプロトコルを実行してもよい。ネットワークアクセスプロトコルは、制御ユニットからネットワークアクセスを要求すること、搬送波の可用性を検出すること、又は他の形式のアクセス制御を含んでもよい。

一例では、データ通信システム410がアクセスを得ようとしているネットワークは帯域に制約されてもよい。更に、１つ以上のリンクは、信頼性がなくてもよく、及び／又は継続的に切断されてもよい。従って、データ通信システム410がネットワークにアクセスして宛先430にデータを通信することができるまで、データ通信システム410は、ソース420から受信したデータを一時的にキューに入れてもよい。例えば、ソース420は第１のデータセットを取得してもよい。ソース420は、第１のデータセットをデータ通信システム410に通信してもよい。データ通信システム410は、第１のデータセットを宛先430に送信するためのネットワークアクセスを現在有していなくてもよい。データ通信システム410がネットワークアクセスを有するまで、第１のデータセットは、キューに一時的に入れられてもよい。その間に、ソースは第２のデータセットを取得してもよい。第２のデータセットは、データ通信システム410に通信されてもよい。データ通信システム410は、第１のデータセット又は第２のデータセットを宛先430に送信するためのネットワークアクセスをまだ有していなくてもよい。データがデータのタイミングが関係するような形式である場合（例えば、最近のデータ（例えば位置データ等）は宛先430に関係する）、第１のデータセットはもはや関係ない。換言すると、第１のデータセットは、第２のデータセットを考慮して機能的に冗長になっている。従って、宛先430への第１のデータセットの送信は、不要にネットワーク帯域を消費し得る。

他の例では、ソースは、第１のデータセットを取得し、第１のデータセットをデータ通信システム410に通信してもよい。データ通信システム410は、宛先430に第１のデータセットを送信するためのネットワークアクセスを現在有していてもよく、有していなくてもよい。データ通信システム410がネットワークへのアクセスを有する場合、データ通信システム410は、第１のデータセットを宛先430に送信してもよい。ソース420は第２のデータセットを取得してもよい。データ通信システム410は、第２のデータセットを宛先430に送信するためのネットワークアクセスを現在有していてもよく、有していなくてもよい。データ通信システム410がネットワークへのアクセスを有する場合、データ通信システム410は、第２のデータセットを宛先430に送信してもよい。データが取得時間によりデータが連続する取得の間で比較的少量だけ変化するような形式である場合（例えば、地上5000フィートからの無人機（UAV）から毎秒撮影された写真等）、連続するデータセットは機能的に冗長である可能性がある。換言すると、主に同じ画像を取得している可能性がある。従って、宛先430への連続するデータセットの送信は、不要にネットワーク帯域を消費し得る。

他の例では、ソースは、第１のデータセットを取得し、第１のデータセットをデータ通信システム410に通信してもよい。データ通信システム410は、宛先430に第１のデータセットを送信するためのネットワークアクセスを現在有していてもよく、有していなくてもよい。データ通信システム410がネットワークへのアクセスを有する場合、データ通信システム410は、第１のデータセットを宛先430に送信してもよい。ソース420は第２のデータセットを取得してもよい。データ通信システム410は、第２のデータセットを宛先430に送信するためのネットワークアクセスを現在有していてもよく、有していなくてもよい。データ通信システム410がネットワークへのアクセスを有する場合、データ通信システム410は、第２のデータセットを宛先430に送信してもよい。第１のデータセットの内容が第２のデータセットの内容と同じである場合及び／又は類似する場合（オーディオ成分を有すると想定されるデータセットのオーディオ成分の欠如等）、連続するデータセットは機能的に冗長である可能性がある。従って、宛先430への連続するデータセットの送信は、不要にネットワーク帯域を消費し得る。

図５は、本発明の実施例で動作するデータ通信環境500を示している。環境500は、図４に示すデータ通信システム410と、ソース420と、宛先430とを含む。データ通信システム410は、本発明の特定の実施例を示すために拡大及び詳細化されている。

図５に示すデータ通信システム410は、冗長ルールデータベース510と、受信機520と、動作プロセッサ530と、１つ以上のキュー540と、送信機550とを含む。冗長ルールデータベース510は、動作プロセッサ530と通信する。受信機520は、動作プロセッサ530及びソース420と通信する。動作プロセッサ530は、キュー540と通信する。例えば、図５に示すデータ通信システム410は、有線、無線、衛星、ネットワークリンクのようなリンクで、及び／又はプロセス間通信を通じて、ソースノード420及び／又は宛先ノード430と通信してもよい。特定の実施例では、データ通信システム410は、１つ以上の戦術データネットワークで１つ以上のソースノード420及び／又は宛先ノード430と通信してもよい。システム500の構成要素、システム500の接続及びシステム500は、単一のユニットでもよく、別々のユニットでもよく、様々な形式で統合されてもよく、ハードウェア及び／又はソフトウェアで実装されてもよい。

実施例では、冗長ルールデータベース510は、様々なルール及び／又はプロトコルを格納し、動作プロセッサ530に通信するデータベースでもよい。冗長ルールデータベース510、及び冗長ルールデータベース510と動作プロセッサ530との間に示す接続は、動作を実行してルール及び命令を格納する様々な構成要素及び／又はソフトウェアを表す。受信機520は、ソース420からデータを受信する様々な構成要素及び／又はソフトウェアを表す。動作プロセッサ530は、冗長ルールデータベース510により通信されたルールに基づいてデータを処理して動作を実行するプロセッサを表す。キュー540は、データをキューに入れる様々な構成要素及び／又はソフトウェアを表す。送信機550は、データを宛先430に送信する様々な構成要素及び／又はソフトウェアを表す。

前述のように、データ通信システム410により受信、格納、優先付け、処理、通信、及び／又は送信されたデータは、データのブロックを含んでもよい。例えば、データのブロックは、パケット、セル、フレーム、及び／又はストリームでもよい。例えば、受信機520は、データのブロックを有するものとして示されている。データセットは、単一のデータのブロックを含んでもよく、複数のデータのブロックを含んでもよい。

動作中に、データセットは、１つ以上のデータソース420により提供及び／又は生成されてもよい。データセットは、受信機520で受信される。例えば、データセットは、１つ以上のリンクで受信されてもよい。例えば、データセットは、戦術データネットワークで無線機からデータ通信システム410で受信されてもよい。他の例として、データセットは、プロセス間通信機構により同じシステムで動作するアプリケーションにより、データ通信システム410に提供されてもよい。前述のように、例えば、データセットは単一のデータのブロックを含んでもよく、複数のデータのブロックを含んでもよい。

特定の実施例では、受信機520は、データセットを動作プロセッサ530に通信してもよい。動作プロセッサ530は、データセットを受信し、データセットで機能的冗長性処理を実行するか否かを決定してもよい。動作プロセッサ530は、データセットで機能的冗長性処理を実行するか否かの決定を、冗長ルールデータベース510からの冗長ルールに基づいて行ってもよい。

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

例えば、冗長ルールは、ユーザにより選択された“モード”に基づいて“オン”又は“オフ”として設定されてもよい。前述のように、データ通信システム410は、利用可能な帯域の最適化、情報優先度の設定、及びネットワークでのデータリンクの管理のようなスループット管理機能を実行するために、ルール及びモード又はプロファイルを使用してもよい。例えば、異なるモードは、ルール、モード、及び／又はデータ転送における変化に影響を及ぼしてもよい。モード又はプロファイルは、特定のネットワーク健康状態又は状況への動作上の必要性に関する一式のルールを含んでもよい。例えば、データ通信システム410は、“進行中”に新しいモードを規定して切り替えることを含み、モードの動的な再構成を提供してもよい。

選択されたモードが一式の冗長ルールを利用する場合、動作プロセッサ530は、データセットを分析し、冗長ルールに基づいて機能的冗長性処理を実行するか否かを決定してもよい。実施例では、利用可能なモードは異なる冗長ルールを有してもよい。例えば、モードAは第１の一式の冗長ルールを有してもよく、モードBは第２の一式の冗長ルールを有してもよい。一式の冗長ルールは、単一のモードに属してもよく、複数のモードに属してもよい。モードは、一式より多い冗長ルールを含んでもよい。

機能的冗長性処理を実行するか否かを決定するときに、動作プロセッサ530は、データブロックから情報（データブロックのプロトコル情報、ペイロード、及び／又はタイムスタンプ等）を読み取ってもよい。例えば、前述のように、プロトコル情報は、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、プロトコル形式、及び／又はタイムスタンプを含んでもよい。例えば、機能的冗長性が特定のソースからのデータについて実行されるべきであることを、選択されたモードでの冗長ルールデータベース510の冗長ルールが示す場合、動作プロセッサ530は、特定のソースからのデータについて機能的冗長性処理を実行する。例えば、選択されたモードの冗長ルールは、ソースノードBからのデータではなく、ソースノードAからのデータについて機能的冗長性処理を実行することを示してもよい。従って、この例では、機能的冗長性処理は、ソースノードBからのデータについて実行されない。

機能的冗長性処理がデータセットで実行されるべきであることを動作プロセッサ530が決定すると、動作プロセッサ530は、冗長ルールに従ってデータセットで機能的冗長性処理を実行してもよい。冗長ルールは、選択されたモードにより決定されてもよい。例えば、冗長ルールは、動作プロセッサ530が現在のデータセットと同じソースから生じたデータセットについてキュー540を検索することを示してもよい。冗長ルールは、特定のソースからの古いデータセットがキューに見つかった場合、古いデータセットが現在の新しいデータセットに対して機能的に冗長であることを示してもよい。代替として、冗長ルールは、動作プロセッサ530が現在のデータセットと同じソースから生じたデータセットについてキュー540を検索することを示してもよい。冗長ルールは、キューにあるデータセット及び現在のデータセットのタイムスタンプ情報を検査し、キューにあるデータセット及び現在のデータセットが機能的に冗長な情報を含んでいるか否かを決定するように、動作プロセッサに命令してもよい。他の代替例では、冗長ルールは、ペイロード情報を検査し、キューにあるデータセット及び現在のデータセットが類似の及び／又は同じ機能内容を有するか否か（従って、機能的に冗長であるか否か）を決定するように、動作プロセッサに命令してもよい。

例えば、第１のデータセット及び第２のデータセットが同じソースから取得されている場合、冗長ルールは、第１の前のデータセットを、第２の後のデータセットに対して機能的に冗長であるとして特定してもよい。他の例では、第１のデータセット及び第２のデータセットが第１のデータセットと第２のデータセットとの間の所定の期間未満で取得されている場合、冗長ルールは、第１の前のデータセットを、第２の後のデータセットに対して機能的に冗長であるとして特定してもよい。他の例として、第１のデータセット及び第２のデータセットが機能的に類似の及び／又は同じ内容を有する場合（例えば、オーディオ成分を有すると想定されるデータセットのオーディオ成分の欠如）、冗長ルールは、第２の後のデータセットを、第１の前のデータセットに対して機能的に冗長であると特定してもよい。

機能的に冗長であると分類され得るデータの例は、位置データでもよい。例えば、ソース420（例えば、GPSインジケータ）は、特定の時間にハンビーの位置を報告するために第１のデータセットを生成してもよい。ネットワークの制約により、第１のデータセットはキュー540に格納されてもよい。ハンビーは移動中でもよいため、ソース420は、第１のデータセットと異なる位置を報告するために第２のデータセットを生成してもよい。動作プロセッサ530が第２のデータセットを受信すると、動作プロセッサ530は、選択されたモードがソース420からの位置データについて機能的冗長性を利用することを決定してもよい。

動作プロセッサ530は、キュー540を検索し、ソース420からのデータセットがキュー540に格納されているか否かを決定してもよい。ソース420からのデータセットが見つかった場合、動作プロセッサ530は、位置データの第１のデータセットが位置データの第２のデータセットに対して機能的に冗長であることを決定してもよい。前の時間に取得された位置データの第１のデータセットは、後の時間に取得された位置データの第２のデータセットより現時点で正確ではないため、動作プロセッサ530は、位置データの前の第１のデータセットをキュー540から破棄してもよい。動作プロセッサ530は、位置データの第２のデータセットをキュー540に追加してもよい。動作プロセッサ530は、キュー540の送信順序が変わらないように、第２のデータセットをキュー540に追加してもよい。例えば、第２のデータセットは、キューの位置において第１のデータセットと置換してもよい。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。動作プロセッサ530は、先入れ先出しプロトコルで第２のデータセットをキュー540に追加してもよい。このように、もはや正確でない又は関係ない“古い”位置データでネットワークに負荷をかけずに、最近の位置データが宛先430に送信される。

機能的に冗長であると分類され得るデータの他の例は、短期間で取得された連続するデータセットでもよい。例えば、無人機（UAV）は、500フィートを飛行しており、毎秒１枚の写真を撮影してもよい。UAVは比較的遅く飛行しているため、UAVにより撮影された写真は、実質的には相互に異ならない。短期間に撮影された連続写真は、新しい情報を示さない可能性があるため、連続写真は機能的に冗長になる可能性がある。機能的に冗長な写真を送信することは、貴重な帯域を不要に消費し得る。

より良い理解のために提供される例では、UAVは、カメラ（この例でのソース420）から第１の写真（この例での第１のデータ）を取得し、第１の写真を受信機520に通信してもよい。受信機520は、第１の写真を動作プロセッサ530に通信してもよい。動作プロセッサ530は、第１の写真をキュー540に通信してもよい。送信機550がネットワークアクセスを有するまで、第１の写真はキュー540に待機してもよい。特定の実施例では、カメラ（この例でのソース420）から第２の写真（この例での第２のデータセット）が動作プロセッサ530に通信される前に、送信機550は、ネットワークアクセスを有さなくてもよく、ネットワークアクセスを要求しなくてもよい。

動作プロセッサ530は、第２のデータセットを受信すると、第２のデータセットで機能的冗長性処理を実行するか否かを決定する。前述のように、動作プロセッサ530は、データブロックから情報（データブロックのプロトコル情報、ペイロード、及び／又はタイムスタンプ等）を読み取ってもよい。例えば、プロトコル情報は、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、プロトコル形式、及び／又はタイムスタンプを含んでもよい。動作プロセッサ530が第２のデータセットを受信すると、動作プロセッサ530は、選択されたモードが冗長ルールに従ってソース420（この例でのUAVのカメラ）からデータについて機能的冗長性を利用することを決定してもよい。例えば、冗長ルールは、時間閾値の離れたデータセットがソース420から宛先430に送信されることを指定してもよい。

動作プロセッサ530は、キュー540を検索し、ソース420からのデータセットがキュー540に格納されているか否かを決定してもよい。ソース420からのデータセットが見つかると、動作プロセッサ530は、第１のデータセットのタイムスタンプと第２のデータセットのタイムスタンプとを検査してもよい。動作プロセッサ530は、タイムスタンプで特定された第１のデータセットと第２のデータセットとの間の取得時間の差が特定の時間閾値より小さいことを決定してもよい。第１のデータセット及び第２のデータセットの取得時間の差が特定の時間閾値より小さい場合、動作プロセッサ540は、第１のデータセットが第２のデータセットに対して機能的に冗長であることを決定してもよい。時間閾値の値は、選択されたモードにより決定されてもよい。

実施例では、時間的に前に取得された第１のデータセットが時間的に後に取得された第２のデータセット（第２の写真）より現時点であまり関係ないため、動作プロセッサ530は、キュー540から前の第１のデータセット（第１の写真）を破棄してもよい。動作プロセッサ530は、第２のデータセット（第２の写真）をキュー540に追加してもよい。動作プロセッサ530は、キュー540の送信順序が変わらないように、第２のデータセットをキュー540に追加してもよい。例えば、第２のデータセットは、キューの位置において第１のデータセットと置換してもよい。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。動作プロセッサ530は、先入れ先出しプロトコルで第２のデータセットをキュー540に追加してもよい。

機能的に冗長であると分類され得るデータの他の例は、同じ又は類似の内容を有するデータセットでもよい。第１のデータセットの内容が第２のデータセットの内容と同じである場合及び／又は類似する場合（オーディオ成分を有すると想定されるデータセットのオーディオ成分の欠如等）、連続するデータセットは、機能的に冗長する可能性がある。例えば、オーディオデータを含まないオーディオデータを含むことが想定されるデータセットは、データセットが電波沈黙時間（radio silence）を送信していることを示してもよい。電波沈黙時間は宛先430に有用な情報ではないため、電波沈黙時間を含むデータセットを送信することは、帯域を不要に消費し得る。従って、オーディオ成分が想定されるデータセットについて、オーディオ成分をほとんど又は全く含まない連続するデータセットは、機能的に冗長になる可能性がある。

より良い理解のために提供される例では、無線機又はマイクロフォン（この例でのソース420）は、第１のデータセットを取得し、第１のデータセットを受信機520に通信してもよい。受信機520は、第１のデータセットを動作プロセッサ530に通信してもよい。動作プロセッサ530は、第１のデータセットをキュー540に通信してもよい。送信機550がネットワークアクセスを有するまで、第１のデータセットはキュー540に待機してもよい。特定の実施例では、第２のデータセットがソース420から動作プロセッサ530に通信される前に、送信機550は、ネットワークアクセスを有さなくてもよく、ネットワークアクセスを要求しなくてもよい。

動作プロセッサ530は、第２のデータセットを受信すると、第２のデータセットで機能的冗長性処理を実行するか否かを決定する。前述のように、動作プロセッサ530は、データブロックから情報（データブロックのプロトコル情報、ペイロード、及び／又はタイムスタンプ等）を読み取ってもよい。例えば、プロトコル情報は、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、プロトコル形式、及び／又はタイムスタンプを含んでもよい。動作プロセッサ530が第２のデータセットを受信すると、動作プロセッサ530は、選択されたモードが冗長ルールに従ってソース420（この例での無線マイクロフォン）からデータについて機能的冗長性を利用することを決定してもよい。例えば、冗長ルールは、オーディオ成分がソース420からのデータペイロードに存在することを指定してもよい。

動作プロセッサ530は、キュー540を検索し、ソース420からのデータセットがキュー540に格納されているか否かを決定してもよい。ソース420からのデータセットが見つかると、動作プロセッサ530は、オーディオ成分の想定の位置で第１のデータセットのペイロードを検査してもよい。動作プロセッサ530はまた、オーディオ成分の想定の位置で第２のデータセットのペイロードを検査してもよい。動作プロセッサ530は、第１のデータセットがオーディオ成分を含まず、第２のデータセットがオーディオ成分を含まないことを決定してもよい。第１のデータセット及び第２のデータセットの双方がオーディオ成分を有さず、双方のデータセットがオーディオ成分を有すると想定される場合、第１及び第２のデータセットを送信することは、送信機に有用な情報を通信しない。従って、動作プロセッサ540は、第１のデータセットが第２のデータセットに対して機能的に冗長であること又は第２のデータセットが第１のデータセットに対して機能的に冗長であることを決定してもよい。

実施例では、動作プロセッサ530は、キュー540から前の第１のデータセットを破棄してもよい。動作プロセッサ530は、第２のデータセットをキュー540に追加してもよい。動作プロセッサ530は、キュー540の送信順序が変わらないように、第２のデータセットをキュー540に追加してもよい。例えば、第２のデータセットは、キューの位置において第１のデータセットと置換してもよい。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。動作プロセッサ530は、先入れ先出しプロトコルで第２のデータセットをキュー540に追加してもよい。

他の実施例では、動作プロセッサ530は、後の第２のデータセットを破棄し、第１のデータセットをキュー540に残してもよい。実施例では、動作プロセッサ530が第２のデータセットをキューに追加して第１のデータセットを破棄するより、第２のデータセットを破棄することが効率的になる可能性がある。第１のデータセット及び第２のデータセットが一般的に類似の及び／又は同じ内容を含む実施例では、システム500は、送信のために第１のデータセット又は第２のデータセットを選択することに概して無関心でもよい。他の要因が実質的に等しい場合、動作プロセッサ530は、特定のデータについて第１のデータセットを送信し、第２のデータセットを削除するように効率的に動作してもよい。

機能的冗長性の前述の例は単なる例である。冗長ルールは、ソース、時間、ペイロード又は他の要因に基づいて冗長データを規定するように作られてもよい。冗長ルールは、単一モード又は複数モードに適用可能になり得る。モードは、単一の一式の冗長ルールを利用してもよく、複数の一式の冗長ルールを利用してもよい。

図６は、本発明の実施例による動作プロセッサ530のフローチャート600を示している。ステップ610において、第１のデータセットが受信され、キュー540に格納される。第２のデータセットが受信され、動作プロセッサ530に通信される。データ通信システム410は、ソース420からのデータについて機能的冗長性を利用するモードにある。第２のデータセットは、動作プロセッサ530により動作される。動作プロセッサ530による動作は、選択されたモードにより規定される冗長ルールデータベース510からの冗長ルールに基づいて、第２のデータセットについて機能的冗長性処理を実行するか否かを決定することを含んでもよい。例えば、動作プロセッサ530は、第２のデータセットから情報（データセットのプロトコル情報、ペイロード、及び／又はタイムスタンプ等）を読み取ってもよい。例えば、前述のように、プロトコル情報は、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、プロトコル形式、及び／又はタイムスタンプを含んでもよい。例えば、選択されたモードについて冗長ルールデータベース510の冗長ルールが、機能的冗長性が現在のデータセットについて実行されるべきであることを示す場合、動作プロセッサは、機能的冗長性処理を実行する。

機能的冗長性処理が実行されるべきであることを冗長ルールが示す場合、動作プロセッサ530の機能を示すフローチャートは、ステップ620に移動する。機能的冗長性処理が実行されるべきでないことを機能的冗長ルールが示す場合、動作プロセッサ530（フローチャート）はステップ640に移動し、第２のデータをキュー540に追加する。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。第２のデータセットがキュー540に追加されると、第２のデータセットは宛先430への送信を待機する。

ステップ620において、動作プロセッサ530は、冗長ルールに従ってキュー540を検索する。実施例では、動作プロセッサ530は、第２のデータセットに対して機能的に冗長である第１のデータセットについてキュー540を検索する。前述のように、動作プロセッサは、選択されたモードにより示される冗長ルールデータベース510のルールに基づいて、第１のデータセットが第２のデータセットに対して機能的に冗長であるか否かを決定する。一例として、動作プロセッサ530は、第１及び第２のデータセットが同じソースから生じる場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを決定してもよい。他の例として、動作プロセッサ530は、第１及び第２のデータセットが同じソースから生じており、タイムスタンプの間の差が所定の閾値より大きくない場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを決定してもよい。更に他の例として、動作プロセッサ530は、第１及び第２のデータセットが宛先430に複数回送信するほど有用でない可能性がある共通の要素を有する場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを決定してもよい。

ステップ620において、動作プロセッサ530がキュー540で機能的に冗長なデータを見つけた場合、動作プロセッサ530はステップ630に移動する。ステップ630において、動作プロセッサがキュー540で機能的に冗長なデータを見つけない場合、動作プロセッサ530はステップ640に移動し、第２のデータセットをキュー540に追加し、送信を待機する。

ステップ630において、動作プロセッサ530は、キュー540から前の第１のデータセットを破棄してもよい。動作プロセッサ530は、後の第２のデータセットをキュー540に追加してもよい。実施例では、動作プロセッサ530は、キュー540の送信順序が変わらないように、第２のデータセットをキュー540に追加してもよい。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。動作プロセッサ530は、先入れ先出しプロトコルで第２のデータセットをキュー540に追加してもよい。フローチャート600のステップは、帯域を効率的に利用するために繰り返して実行されてもよい。

図７は、本発明の実施例による動作プロセッサ530のフローチャート700を示している。ステップ710において、第１のデータセットが受信され、キュー540に格納される。第２のデータセットが受信され、動作プロセッサ530に通信される。データ通信システム410は、ソース420からのデータについて機能的冗長性を利用するモードにある。第２のデータセットは、動作プロセッサ530により動作される。動作プロセッサ530による動作は、選択されたモードにより規定される冗長ルールデータベース510からの冗長ルールに基づいて、第２のデータセットについて機能的冗長性処理を実行するか否かを決定することを含んでもよい。例えば、動作プロセッサ530は、第２のデータセットから情報（データセットのプロトコル情報、ペイロード、及び／又はタイムスタンプ等）を読み取ってもよい。例えば、前述のように、プロトコル情報は、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、プロトコル形式、及び／又はタイムスタンプを含んでもよい。例えば、選択されたモードについて冗長ルールデータベース510の冗長ルールが、機能的冗長性が現在のデータセットについて実行されるべきであることを示す場合、動作プロセッサは、機能的冗長性処理を実行する。

機能的冗長性処理が実行されるべきであることを冗長ルールが示す場合、動作プロセッサ530の機能を示すフローチャートは、ステップ720に移動する。機能的冗長性処理が実行されるべきでないことを機能的冗長ルールが示す場合、動作プロセッサ530（フローチャート）はステップ740に移動し、第２のデータをキュー540に追加する。第２のデータセットがキュー540に追加されると、第２のデータセットは宛先430への送信を待機する。

ステップ720において、動作プロセッサ530は、冗長ルールに従ってキュー540を検索する。実施例では、動作プロセッサ530は、第２のデータセットに対して機能的に冗長である第１のデータセットについてキュー540を検索する。前述のように、動作プロセッサは、選択されたモードにより示される冗長ルールデータベース510のルールに基づいて、第１のデータセットが第２のデータセットに対して機能的に冗長であるか否かを決定する。一例として、動作プロセッサ530は、第１及び第２のデータセットが同じソースから生じる場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを決定してもよい。他の例として、動作プロセッサ530は、第１及び第２のデータセットが同じソースから生じており、タイムスタンプの間の差が所定の閾値より大きくない場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを決定してもよい。更に他の例として、動作プロセッサ530は、第１及び第２のデータセットが宛先430に複数回送信するほど有用でない可能性がある共通の要素を有する場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを決定してもよい。

ステップ720において、動作プロセッサ530がキュー540で機能的に冗長なデータを見つけた場合、動作プロセッサ530はステップ730に移動する。ステップ730において、動作プロセッサがキュー540で機能的に冗長なデータを見つけない場合、動作プロセッサ530はステップ740に移動し、第２のデータセットをキュー540に追加し、送信を待機する。

ステップ730において、動作プロセッサ530は、後の第２のデータセットを破棄し、第１のデータセットをキュー540に残してもよい。実施例では、動作プロセッサ530が第２のデータセットをキューに追加して第２のデータセットを破棄するより、第２のデータセットを破棄することが効率的になる可能性がある。第１のデータセット及び第２のデータセットが一般的に類似の及び／又は同じ内容を含む実施例では、システム500は、送信のために第１のデータセット又は第２のデータセットを選択することに概して無関心でもよい。他の要因が実質的に等しい場合、動作プロセッサ530は、特定のデータについて第１のデータセットを送信し、第２のデータセットを削除するように効率的に動作してもよい。フローチャート700のステップは、帯域を効率的に利用するために繰り返して実行されてもよい。

図８は、本発明の実施例による方法800を示している。ステップ810において、第１のデータセットが受信されてもよい。ステップ820において、第１のデータセットがキューに格納されてもよい。ステップ830において、第２のデータセットが受信されてもよい。ステップ840において、第２のデータセットについて機能的冗長性処理を実行するか否かが決定されてもよい。第２のデータセットについて機能的冗長性処理を実行するか否かの決定は、選択されたモードと、選択されたモードに関連する冗長ルールとに依存してもよい。モードは、例えばネットワーク状況に基づいて、手動又は自動で選択されてもよい。

ステップ850において、第２のデータセットに対して機能的に冗長になり得るデータセットについてキューが検索されてもよい。キューにあるデータセットが現在のデータセットに対して機能的に冗長であるか否かは、冗長ルールにより決定されてもよい。冗長ルールは、選択されたモードにより決定されてもよい。一例として、冗長ルールは、第１及び第２のデータセットが同じソースから生じる場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを示してもよい。他の例として、冗長ルールは、第１及び第２のデータセットが同じソースから生じており、タイムスタンプの間の差が所定の閾値より大きくない場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを示してもよい。更に他の例として、冗長ルールは、第１及び第２のデータセットが同じ及び／又は類似の内容を有する場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを示してもよい。

ステップ860において、第２のデータセットが第１のデータセットに対して機能的に冗長であると決定されると、前の第１のデータセットはキューから破棄されてもよい。ステップ870において、後の第２のデータセットはキューに追加されてもよい。実施例では、第２のデータセットは、キューの送信順序が変わらないように、キューに追加されてもよい。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。代替として、第２のデータセットは、先入れ先出しプロトコルでキューに追加されてもよい。フローチャート800のステップは、帯域を効率的に利用するために繰り返して実行されてもよい。

例えば、方法800の１つ以上のステップは、単独で、又はハードウェア、ファームウェアの組み合わせで、及び／又はソフトウェアの一式の命令として実装されてもよい。特定の実施例は、汎用コンピュータ又は他の処理装置で実行するコンピュータ可読媒体（メモリ、ハードディスク、DVD又はCD等）に存在する一式の命令として提供されてもよい。

本発明の特定の実施例は、１つ以上の方法800のステップを省略してもよく、及び／又は記載の順序と異なる順序でステップを実行してもよい。例えば、本発明の或る実施例では、いくつかのステップは実行されなくてもよい。更なる例として、特定のステップは、前述のものと異なる時間的順序で（同時も含む）実行されてもよい。

前述のシステム及び方法800は、コンピュータ用の一式の命令を含むコンピュータ可読記憶媒体の一部として実行されてもよい。一式の命令は、第１のデータセット及び第２のデータセットを受信する受信ルーチンを含んでもよい。一式の命令はまた、第１のデータセットをキューに格納する格納ルーチンを含んでもよい。一式の命令はまた、冗長ルールに基づいて第２のデータセットについて機能的冗長性処理を実行するか否かを決定する決定ルーチンを含んでもよい。

冗長ルールは、選択モードルーチンにより制御されてもよい。選択モードルーチンは、選択ルーチンにより選択されてもよい。選択ルーチンは、ユーザにより選択されてもよく、ネットワーク状況に基づいて動的に選択されてもよい。冗長ルールは、第２のデータセット及び第１のデータセットが同じソースノードから生じるか否かを決定する第１の冗長ルーチンを含んでもよい。冗長ルールはまた、第２のデータセットのタイムスタンプと第１のデータセットのタイムスタンプとの間の時間を決定する第２の冗長ルーチンを含んでもよい。冗長ルールはまた、第１のデータセットと第２のデータセットとの間に共通の要素が存在するか否かを決定する第３の冗長ルーチンを含んでもよい。

一式の命令はまた、第１のデータセットについてキューを検索する検索ルーチンを含んでもよい。第１のデータセットが第２のデータセットに対して機能的に冗長である場合、第１のデータセットがキューから破棄され、第２のデータセットがキューに追加されてもよい。実施例では、第１のデータセットが第２のデータセットにより置換されるときに、キューの場所は維持される。他の実施例では、第２のデータセットはキューの終わりに追加される。第２のデータセットをキューに追加するステップは、先入れ先出しプロトコルで第２のデータセットをキューに追加する先入れ先出しルーチンを含む。

図９は、本発明の実施例による方法900を示している。ステップ910において、第１のデータセットが受信されてもよい。ステップ920において、第１のデータセットがキューに格納されてもよい。ステップ930において、第２のデータセットが受信されてもよい。ステップ940において、第２のデータセットについて機能的冗長性処理を実行するか否かが決定されてもよい。第２のデータセットについて機能的冗長性処理を実行するか否かの決定は、選択されたモードと、選択されたモードに関連する冗長ルールとに依存してもよい。モードは、例えばネットワーク状況に基づいて、手動又は自動で選択されてもよい。

ステップ950において、第２のデータセットに対して機能的に冗長になり得るデータセットについてキューが検索されてもよい。キューにあるデータセットが現在のデータセットに対して機能的に冗長であるか否かは、冗長ルールにより決定されてもよい。冗長ルールは、選択されたモードにより決定されてもよい。一例として、冗長ルールは、第１及び第２のデータセットが同じソースから生じる場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを示してもよい。他の例として、冗長ルールは、第１及び第２のデータセットが同じソースから生じており、タイムスタンプの間の差が所定の閾値より大きくない場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを示してもよい。更に他の例として、冗長ルールは、第１及び第２のデータセットが複数回送信するほど有用でない可能性のある共通の要素を有する場合に、第１のデータセットが第２のデータセットに対して機能的に冗長であることを示してもよい。

ステップ960において、第２のデータセットが第１のデータセットに対して機能的に冗長であると決定されると、第２のデータセットがキューから破棄され、第１のデータセットがキューに残ってもよい。実施例において、第２のデータセットをキューに追加して第２のデータセットを破棄するより、第２のデータセットを破棄することが効率的になる可能性がある。第１のデータセット及び第２のデータセットが一般的に類似の情報を含む実施例では、送信のために第１のデータセットが選択されてもよく、第２のデータセットが選択されてもよい。他の要因が実質的に等しい場合、特定のデータについて第１のデータセットを送信し、第２のデータセットを破棄することが効率的になる可能性がある。フローチャート900のステップは、帯域を効率的に利用するために繰り返して実行されてもよい。

例えば、方法900の１つ以上のステップは、単独で、又はハードウェア、ファームウェアの組み合わせで、及び／又はソフトウェアの一式の命令として実装されてもよい。特定の実施例は、汎用コンピュータ又は他の処理装置で実行するコンピュータ可読媒体（メモリ、ハードディスク、DVD又はCD等）に存在する一式の命令として提供されてもよい。

本発明の特定の実施例は、１つ以上の方法900のステップを省略してもよく、及び／又は記載の順序と異なる順序でステップを実行してもよい。例えば、本発明の或る実施例では、いくつかのステップは実行されなくてもよい。更なる例として、特定のステップは、前述のものと異なる時間的順序で（同時も含む）実行されてもよい。

前述のシステム及び方法900は、コンピュータ用の一式の命令を含むコンピュータ可読記憶媒体の一部として実行されてもよい。一式の命令は、第１のデータセット及び第２のデータセットを受信する受信ルーチンを含んでもよい。一式の命令はまた、第１のデータセットをキューに格納する格納ルーチンを含んでもよい。一式の命令はまた、冗長ルールに基づいて第２のデータセットについて機能的冗長性処理を実行するか否かを決定する決定ルーチンを含んでもよい。

冗長ルールは、選択モードルーチンにより制御されてもよい。選択モードルーチンは、選択ルーチンにより選択されてもよい。選択ルーチンは、ユーザにより選択されてもよく、ネットワーク状況に基づいて動的に選択されてもよい。冗長ルールは、第２のデータセット及び第１のデータセットが同じソースノードから生じるか否かを決定する第１の冗長ルーチンを含んでもよい。冗長ルールはまた、第２のデータセットのタイムスタンプと第１のデータセットのタイムスタンプとの間の時間を決定する第２の冗長ルーチンを含んでもよい。冗長ルールはまた、第１のデータセットの内容が第２のデータセットの内容に対して機能的に冗長であるか否かを決定する第３の冗長ルーチンを含んでもよい。

一式の命令はまた、第１のデータセットについてキューを検索する検索ルーチンを含んでもよい。一式の命令はまた、第１のデータセットの内容が第２のデータセットの内容に対して機能的に冗長である場合、第１のデータセットを送信して第２のデータセットを破棄する送信ルーチンを含んでもよい。

Claims

第１のデータセットを受信し、
前記第１のデータセットをキューに格納し、
第２のデータセットを受信し、
冗長ルールに基づいて前記第２のデータセットについて機能的冗長性処理を実行するか否かを決定し、前記冗長ルールは、選択されたモードにより制御され、
前記第１のデータセットについて前記キューを検索し、前記冗長ルールに基づいて前記第１のデータセットが前記第２のデータセットに対して機能的に冗長であるか否かを決定し、
前記第１のデータセットが前記第２のデータセットに対して機能的に冗長である場合、前記第１のデータセットを前記キューから破棄し、前記第２のデータセットを前記キューに追加することを有するデータ通信方法。
前記選択されたモードは、ユーザにより選択される、請求項１に記載の方法。
前記冗長ルールは、前記第２のデータセットのデータのヘッダに含まれる情報に基づいて機能的冗長性処理を実行するか否かを決定する、請求項１に記載の方法。
前記冗長ルールは、前記第２のデータセットのタイムスタンプと前記第１のデータセットのタイムスタンプとの間の時間が所定の期間より小さい場合に、前記第１のデータセットが前記第２のデータセットに対して機能的に冗長であることを決定する、請求項１に記載の方法。
前記第２のデータセットを前記キューに追加するステップは、先入れ先出しプロトコルで前記第２のデータセットを前記キューに追加することを含む、請求項１に記載の方法。
処理装置で実行する一式の命令を有するコンピュータ可読媒体であって、
前記一式の命令は、
第１のデータセットと第２のデータセットとを受信する受信ルーチンと、
前記第１のデータセットをキューに格納する格納ルーチンと、
冗長ルールに基づいて前記第２のデータセットについて機能的冗長性処理を実行するか否かを決定する決定ルーチンであり、前記冗長ルールは、選択されたモードにより制御される決定ルーチンと、
前記第１のデータセットについて前記キューを検索し、前記冗長ルールに基づいて前記第１のデータセットが前記第２のデータセットに対して機能的に冗長であるか否かを決定する検索ルーチンであり、前記第１のデータセットが前記第２のデータセットに対して機能的に冗長である場合、前記第１のデータセットを前記キューから破棄し、前記第２のデータセットを前記キューに追加する検索ルーチンと
を有するコンピュータ可読媒体。
前記選択されたモードは、選択モードルーチンにより選択され、前記選択モードルーチンは、ユーザにより制御される、請求項６に記載の一式の命令。
第１のデータセットを受信し、
第２のデータセットを受信し、
選択されたモードを検査し、前記第２のデータセットで機能的冗長性処理を実行するか否かを決定し、前記選択されたモードは、機能的冗長性処理を実行するか否かを決定する一式の冗長ルールを有し、
前記第２のデータセットが前記第１のデータセットに対して機能的に冗長であるか否かを決定することにより、機能的冗長性処理を実行し、前記第２のデータセットは、前記一式の冗長ルールに従って前記第１のデータセットに対して機能的に冗長であり、
前記第１のデータセットが前記第２のデータセットに対して機能的に冗長である場合、前記第１のデータセットをキューから破棄し、前記第２のデータセットを前記キューに追加することを有するデータ通信方法。
前記冗長ルールは、前記第２のデータセットの前記ソースノードに基づいて機能的冗長性処理を実行するか否かを決定する、請求項８に記載の方法。
前記冗長ルールは、前記第２のデータセット及び前記第１のデータセットが同じソースノードから生じる場合に、前記第１のデータセットが前記第２のデータセットに対して機能的に冗長であることを決定する、請求項８に記載の方法。