JP2012075173A - 動的なモードドリブンリンク管理のためのシステム及び方法 - Google Patents

Abstract

【課題】戦術データネットワークのエッジ上で適応的でコンフィギュラブルなＱｏＳシステム及び方法を提供する。
【解決手段】少なくとも１つの電子回路が、複数の選択可能なモードを規定する複数のルールを含むネットワーク通信システムのプロファイルを生成するステップ８１０と、ネットワーク測定の解析に基づきネットワーク状態を決定するステップと、ユーザにより規定される異なるシーケンス化ルールを含む複数の選択可能なモードからモードを選択するステップ８２０と、選択されたシーケンス化ルールに基づきメッセージをシーケンス化するステップと、ネットワーク通信システムから前記メッセージを通信するステップ８４０と、選択されたモードのルールセットに従って、通信のためのＱｏＳを提供するステップ８５０とを有し、ＱｏＳは、ネットワーク通信プロトコルスタックのトランスポートプロトコルレイヤとソケットレイヤとの間で提供される。
【選択図】図８

Description

本開示による技術は、一般に通信ネットワークに関する。より詳細には、本開示による技術は、動的なモードドリブンリンク管理のためのシステム及び方法に関する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現在のネットワークリンクの設計は、退屈で困難なものである。ネットワークリンク設計に対する動的な“無線（ｏｎ−ｔｈｅ−ｆｌｙ）”の変更もまた困難である。アプリケーションは、与えられた動作シナリオに対して最良の通信パスとスループット最適化機構を選択するのでなく、特定の通信パスを使用することが余儀なくされている。典型的には、トランザクション、プロトコル及び通信パスは一緒にされ、通信リンクは、それが伝送する情報から抽象化されない。実現形態はしばしば、ＯＳＩネットワークモデルの各種レイヤを分解又は結合する。多くのネットワークは、特定の加入者グループについてネットワークが設計されることを要求する。ネットワークは静的であり、小さな変更でさえかなりの再作業を必要とする。例えば、現在の戦術通信リンク（ＵＡＶなど）は、衛星通信リンクから見通せる無線リンクにスイッチするのにオペレータの大きな介入を必要とする。

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

本発明の実施例は、モードドリブン通信管理のためのシステム及び方法を提供する。

特定の実施例は、ネットワークを介しデータ通信する方法を提供する。本方法は、複数のパラメータを通信動作モードを表すプロファイルに整理するステップを有する。複数のパラメータは、ネットワークのモードを規定する。本方法はさらに、前記プロファイルのパラメータに従って前記ネットワークを設定するステップを有する。本方法はまた、前記プロファイルに従って前記ネットワーク上の通信のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を提供するステップを有する。

特定の実施例は、処理装置上で実行するための命令セットを有するコンピュータ可読媒体を提供する。命令セットは、通信システムにおけるメッセージの送信を制御する通信管理ルーチンを有する。命令セットはまた、通信システムにおけるメッセージの送信に影響を与えるルールを提供するルールルーチンを有する。命令セットはまた、ルールルーチンにおけるルールを設定するパラメータを規定するモードを含むプロファイルを有する。

特定の実施例は、ＱｏＳを提供するネットワーク通信システムを提供する。本システムは、ネットワークにおけるメッセージのフローを制御する通信マネージャを有する。本システムはまた、前記ネットワークにおけるメッセージのフローに影響を与える１以上のルールを適用するメッセージ管理ルールモジュールを有する。前記１以上のルールは、モードにより設定される。モードは、プロファイルに規定され、前記１以上のルールに関する１以上のパラメータを含む。

本発明によると、戦術データネットワークにおいてＱｏＳを提供するシステム及び方法、戦術データネットワークのエッジ上でＱｏＳを提供するシステム及び方法、並びに戦術データネットワークにおける適応的でコンフィギュラブルなＱｏＳシステム及び方法を提供することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

特定の実施例では、ＯＳＩプロトコルモデルのトランスポートレイヤの上位で、ＱｏＳが通信ネットワークに提供されるかもしれない。具体的には、ＱｏＳ技術は、トランスポートプロトコル接続のソケットレイヤの直下で実現されるかもしれない。トランスポートプロトコルは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）又はＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）などを含むかもしれない。他の例として、プロトコルタイプは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＩＰＸ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｅｔ Ｅｘｃｈａｎｇｅ）、イーサネット(登録商標）、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）及び／又はＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を含むかもしれない。説明のため、ＴＣＰを利用して１以上の具体例が提供される。

図４は、本発明の実施例により動作するデータ通信環境４００を示す。環境４００は、データ通信システム４１０と、１以上のソースノード４２０と、１以上のデスティネーションノード４３０とを有する。データ通信システム４１０は、ソースノード４２０とデスティネーションノード４３０と通信する。データ通信システム４１０は、無線、衛星、ネットワークリンクなどのリンクを介し及び／又はプロセス間通信などを介しソースノード４２０及び／又はデスティネーションノード４３０と通信するかもしれない。特定の実施例では、データ通信システム４１０は、１以上の戦術データネットワークを介し１以上のソースノード４２０及び／又はデスティネーションノード４３０と通信するかもしれない。

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

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

特定の実施例では、データは、ヘッダとペイロードとを有する。ヘッダは、プロトコル情報と、タイムスタンプ情報などを含むかもしれない。特定の実施例では、プロトコル情報、タイムスタンプ情報、コンテンツ及び他の情報は、ペイロードに含まれるかもしれない。特定の実施例では、データはメモリにおいて隣接してもよいし、そうでなくてもよい。すなわち、データの１以上の部分が、異なるメモリ領域に配置されてもよい。特定の実施例では、データは、例えば、データを有する他の位置へのポインタを含むかもしれない。

ソースノード４２０は、データ通信システム４１０により処理されるデータを少なくとも部分的に提供及び／又は生成する。ソースノード４２０は、例えば、アプリケーション、無線、衛星又はネットワークを含むかもしれない。ソースノード４２０は、上述されるように、リンクを介しデータ通信システム４１０と通信するかもしれない。ソースノード４２０は、連続するデータのストリームを生成してもよいし、又はデータをバーストしてもよい。特定の実施例では、ソースノード４２０とデータ通信システム４１０は、同一システムの一部である。例えば、ソースノード４２０は、データ通信システム４１０と同じコンピュータシステム上で実行されるアプリケーションであってもよい。

デスティネーションノード４３０は、データ通信システム４１０により処理されるデータを受信する。デスティネーションノード４３０は、例えば、アプリケーション、無線、衛星又はネットワークなどを含むかもしれない。デスティネーションノード４３０は、上述されるように、リンクを介しデータ通信システム４１０と通信する。特定の実施例では、デスティネーションノード４３０とデータ通信システム４１０は、同一システムの一部である。例えば、デスティネーションノード４３０は、データ通信システム４１０と同じコンピュータシステム上で実行されるアプリケーションであるかもしれない。

データ通信システム４１０は、上述されるように、１以上のソースノード４２０及び／又はデスティネーションノード４３０と通信するかもしれない。特定の実施例では、１以上のリンクは戦術データネットワークの一部であってもよい。特定の実施例では、１以上のリンクは帯域幅制限されるかもしれない。特定の実施例では、１以上のリンクは、信頼性が低く及び／又は断続的に切断されるかもしれない。特定の実施例では、ＴＣＰなどのトランスポートプロトコルは、リンクを介しソースノード４２０からデスティネーションノード４３０にデータを送信するため、ソースノード４２０とデスティネーションノード４３０においてソケット間の接続をオープンする。

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

特定の実施例では、データ通信システム４１０は、データを整理及び／又は優先順位付けしてもよい。特定の実施例では、データ通信システム４１０は、データブロックの優先順位を決定するかもしれない。例えば、データブロックがデータ通信システム４１０により受信されると、データ通信システム４１０の優先順位付けコンポーネントは、当該データブロックの優先順位を決定するかもしれない。他の例として、データブロックは、データ通信システム４１０のキューに格納され、優先順位付けコンポーネントが、データブロック及び／又はキューについて決定した優先順位に基づき、キューからデータブロックを抽出するようにしてもよい。

データ通信システム４１０によるデータの優先順位付けは、例えば、ＱｏＳを提供するのに利用されるかもしれない。例えば、データ通信システム４１０は、戦術データネットワークを介し受信されるデータの優先順位を決定するかもしれない。この優先順位は、例えば、データのソースアドレスに基づくものであってもよい。例えば、データ通信システム４１０が属する小隊と同じ小隊のメンバーの無線からのデータのソースＩＰアドレスが、異なる作戦エリアの異なる部門のユニットからのデータより優先されてもよい。この優先順位は、データ通信システム４１０による以降の通信のため、データが複数のキューの何れに配置されるべきか決定するのに利用されてもよい。例えば、より高い優先順位のデータが、より高い優先順位のデータを保持するためのキューに配置され、データ通信システム４１０は、次に通信するデータを決定する際、より高い優先順位のキューを最初に参照するようにしてもよい。

データは、少なくとも部分的に１以上のルールに基づき優先順位付けされるかもしれない。上述されるように、ルールはユーザにより規定されるかもしれない。特定の実施例では、ルールは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）により記述されてもよく、及び／又はカスタムＤＬＬ（Ｄｙｎａｍｉｃａｌｌｙ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ）を介し提供されてもよい。ルールは、例えば、ネットワーク上のデータを区別及び／又はシーケンス化するのに利用されるかもしれない。ルールは、例えば、あるプロトコルを用いて受信されたデータが他のプロトコルを用いたデータより優先されることを規定するかもしれない。例えば、命令データは、ルールを介して、他のプロトコルを用いて送信された位置遠隔測定データより優先される特定のプロトコルを利用してもよい。他の例として、ルールは、第１アドレス範囲からの位置遠隔測定データが第２アドレス範囲からの位置遠隔測定データより優先されることを規定するかもしれない。第１アドレス範囲は、例えば、実行中のデータ通信システム４１０を備えた航空機と同じ飛行隊の他の航空機のＩＰアドレスを表すかもしれない。第２アドレス範囲は、例えば、異なる作戦エリアにあって、データ通信システム４１０が実行されている航空機に関心が低い他の航空機のＩＰアドレスを表すかもしれない。

特定の実施例では、データ通信システム４１０は、データを排除しない。すなわち、データが低い優先順位であっても、データ通信システム４１０により排除されない。むしろ、データは、潜在的に受信される優先順位の高いデータのデータ量に応じて、ある期間だけ遅延されるかもしれない。特定の実施例では、データは、例えば、データを送信するため帯域幅が利用可能になるまで、データが失われず又は排除されないことを保証するのを助けるため、キュー処理又は格納されてもよい。

特定の実施例では、データ通信システム４１０は、モード又はプロファイルインジケータを有する。モードインジケータは、例えば、データ通信システム４１０の現在のモード又は状態を表すかもしれない。上述されるように、データ通信システム４１０は、ルール及びモード又はプロファイルを利用して、ネットワークにおける利用可能な帯域幅の最適化、情報優先順位の設定及びデータリンクの管理などのスループット管理機能を実行してもよい。異なるモードは、例えば、ルール、モード及び／又はデータトランスポートの変更に影響を与えるかもしれない。モード又はプロファイルは、特定のネットワークの健全性状態の動作要求に関するルールセットを含むかもしれない。例えば、異なるモードは、それに係る異なるルールを有するかもしれない。すなわち、１つのルールセットがモードＡにおいて利用され、潜在的に重複するかもしれないが、異なるルールセットがモードＢにおいて利用されるかもしれない。モード又はプロファイルは、特定のネットワークの健全性状態の動作要求に関するルールセットを含むかもしれない。特定の実施例では、データ及び／又は通信に適用されるのに選択されるルールは、少なくとも部分的にはモード又はプロファイルに基づき選択されるかもしれない。データ通信システム４１０は、例えば、新たなモードの“無線”による定義及びスイッチを含む動的なモードの再設定を提供するかもしれない。

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

データは、データ通信システム４１０を介し通信される。データは、例えば、１以上のデスティネーションノード４３０に通信されるかもしれない。データは、例えば、１以上のリンクを介し通信されるかもしれない。データは、例えば、データ通信システム４１０によって、戦術データネットワークを介し無線に通信されるかもしれない。他の例として、データは、プロセス間通信機構により同一システム上で実行されるアプリケーションにデータ通信システム４１０により提供されてもよい。

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

特定の実施例では、データは、データ伝送のための限定的な帯域幅及び／又は利用性を有する通信接続を介し通信されてもよい。このような接続は、例えば、データ選択、更新頻度、混雑制御及び／又は優先順位付けなどに関するルールを実現するかもしれない。ルール及び／又はフォーマットの下編成は、接続を介した通信における効率性の手助けとなるかもしれない。このようなルール、フォーマット及び／又は他のパラメータは、例えば、モード又はプロファイルにより指定されてもよい。モード／プロファイルは、例えば、通信システムにおいてソフトウェアにより自動的に生成されてもよく、管理者又は技術者により生成されてもよく、ユーザにより生成されてもよく、及び／又はデフォルトとして提供されてもよい。特定の実施例では、モード／プロファイルは、例えば、ソフトウェア、管理者及び／又はユーザにより変更されてもよい。

特定の実施例では、システムのノード間のリンクは、モード又はプロファイルに基づき管理（例えば、動的管理）される。モードは、例えば、ネットワークリンク上のトランスポートレイヤとの間のデータ伝搬を制御するためのルール及びコンフィギュレーション情報のセットを含む。通信システムは、ネットワークの健全性（利用可能な帯域幅、データトラフィック、バッファフラッディング（ｂｕｆｆｅｒ ｆｌｏｏｄｉｎｇ）など）を検出し、システムに適切なモードにより動作するよう動的に指示する。さらに、動作シナリオが変更されると、通信システムはモードを変更するよう指示されるかもしれない。システムは、モードを変更するよう手動により及び／又は自動的に指示されるかもしれない。モードは、例えば、スループット管理ルール、アーカイブ設定、送信前及び送信後ルール並びに／又はトランスポート選択などを規定する。このため、透過なリンク管理が、例えば、ＯＳＩプロトコルスタックのプレゼンテーションレイヤとセッションレイヤにおいて可能とされるかもしれない。

特定の実施例では、プロファイル及び／又は他の表現が、通信システムが動作可能な動作シナリオ又はモードの記述を提供する。通信システムは、通信システムの動作環境に基づき１以上の異なるモードにスイッチするかもしれない。例えば、通信システムのユーザが戦闘中である場合、システムは戦闘モードにより動作するかもしれない。ユーザが撤退中である場合、システムは撤退モードにより動作するかもしれない。ユーザがパトロール中である場合、システムはパトロールモードにより動作するかもしれない。異なるデータは、異なるモードにより異なる優先順位を有するかもしれない。異なるネットワークは、異なるモードについて異なる特性を有するかもしれない。このため、システムは、例えば、動作状態及び／又は目的に基づきあるモードに配置されるかもしれない。

特定の実施例では、単一のコマンドなどのコマンドが、通信システムを特定のモードに置くのに利用されるかもしれない。コマンドは、例えば、通信システムを特定のモードに置くため、手動により及び／又は自動的に実行されてもよい。異なるコマンドは、例えば、異なるモードに対応するかもしれない。単一のコマンドは、例えば、システムの複数の特性又はパラメータを変更するかもしれない。特性又はパラメータは、例えば、選択ルール、機能冗長性ルール、アーカイブ化能力、シーケンス化ルール、送信前ルール及び／又はリンク特性などを含むかもしれない。従って、状況は、“一緒”にされた複数のパラメータ／設定を含むコンテクストに変換されるか、又はコンテクストに含まれるかもしれない。特定の実施例では、アプリケーションプログラミングインタフェースは、モードベース通信機能がネットワーク処理ソフトウェア及び／又は他のハイレベル意志決定ソフトウェアと統合されることを可能にするよう実現されるかもしれない。特定の実施例では、モードをスイッチするのに使用される命令は、例えば、音声命令であってもよい。

例えば、戦闘機は他の戦闘機から遠く離れていて、信号強度が低下しているか、又は天候がこれら戦闘機の間の通信の帯域幅を変化させるかもしれない。戦闘機の間で帯域幅が低下するに従って、戦闘機で実行されているネットワーク処理ソフトウェアは、通信システムに通信リンクにおける優先順位の高いデータフローをより効果的に維持する低帯域幅モードなどの異なるモードにスイッチするよう指示する。

特定の実施例では、プロファイルは、モードを規定する設定ファイルのＸＭＬセクション又はＸＭＬファイルにおいてモードのパラメータを提供する。例えば、モードは１以上のＸＭＬ要素により定義され、通信システムは既存のＸＭＬモード又はＸＭＬ要素を選択するよう指示され、及び／又は新たなＸＭＬモードが動的に追加及び選択されるかもしれない。特定の実施例では、モードベース通信システムは、例えば、既存のモードを変更し、及び／又は新たなモードを追加して通信状態などに基づきこの新たなモードにスイッチするよう動的に反応するかもしれない。特定の実施例では、刊行購読システムは、通信において利用可能とされるＸＭＬモードドキュメントを１以上のサーバに“刊行”するのに利用されるかもしれない。あるいは、１以上のＤＬＬがプロファイル及び／又は対応するモードを規定するようにしてもよい。

図５は、本発明の実施例によるモードドリブンデータ通信システム５００を示す。システム５００は、クライアント５１０〜５１１と、データソース５２０〜５２１と、マネージャモジュール５３０〜５３１と、帯域幅管理ルール５４０〜５４１と、ネットワーク５５０とを有する。マネージャモジュール５３０〜５３１と帯域幅管理ルール５４０〜５４１などの各コンポーネントは、特定のモードにより制御されている。すなわち、マネージャモジュール５３０〜５３１と帯域幅管理ルール５４０〜５４１の動作及び／又は設定は、選択された動作モードにより制御されている。

上述されるように、モードはプロファイルにより規定されるかもしれない。プロファイルに記述されたモードは、少なくとも通信マネージャ５３０〜５３１と帯域幅マネージャ５４０〜５４１のパラメータ及び／又は他の動作特性に影響を与える。すなわち、ネットワーク上でトラフィックがどのように処理及び／又は優先順位付けされるか制御する帯域幅管理ルールと、ネットワークの状態とトラフィック混雑を解析する通信マネージャ５３０〜５３１とは、例えば、特定のルール、パラメータ及び／又は他の基準を規定する異なるモードにおいて異なる動作をするかもしれない。従って、例えば、データソース５２１からクライアント５１０へのデータの通信は、優先順位付け及び／若しくはデータトラフィック管理ルール、パラメータ並びに／又は選択されたモードで規定される他の基準によって制御される。これらのルール、パラメータ及び／又は他の基準は、例えば、マネージャ５３０〜５３１及び５４０〜５４１によりネットワーク及び通信システムにおいて実現される。このため、通信システム５００の処理及びデータフローは、選択された又はプロファイルに規定されたデフォルトモードなどのモードによって、少なくとも部分的に制御されるかもしれない。

機能冗長性ルール、圧縮ルール及びコンテンツ／プロトコル優先順位ルールなどのルールが、モード毎に異なる特性により規定されるかもしれない。さらに、一部のモードは、機能冗長性、圧縮及び／又は優先順位などの特定の特徴についてルールを有していないかもしれない。ユーザは、あるモードから他のモードにスイッチすることが可能とされ、及び／又は通信装置及び／又は通信システムは、あるモードから他のモードに自動的にスイッチするかもしれない。例えば、戦術通信ネットワークを使用するパトロール中のユーザが、様々なデータタイプに対して機能冗長性及び／又は圧縮を“オン”するモードにスイッチするかもしれない。ユーザが基地に戻ると、機能冗長性及び圧縮をオフする異なるモードにスイッチするかもしれない。

ユーザは、例えば、プロファイル又はモードタイプを選択することによって、モードをスイッチするかもしれない。あるいは及び／又はさらに、ユーザは、新たな又は既存のモード及び／又はプロトコルにおいて、１以上のデータ及び／又はプロトコルタイプに固有のルール、パラメータ及び／又は他の特性を規定及び／又は設定するようにしてもよい。例えば、複数の状況に対して、異なる機能を備えた複数のモードが予め設定されてもよく、ユーザ及び／又はシステムは、状況に適したモードを選択するようにしてもよい。しかしながら、特定の実施例は、動作状態に対する動的な反応を可能にする。例えば、既存のモードの特性が変更され、及び／又は新たなモードが通信中に遭遇する新たな優先順位又は動作状態に適用するよう追加されてもよい。

特定の実施例では、ルール及び／又はパラメータは、異なるタイプのデータに別々に適用されてもよい。例えば、あるモードは、あるタイプのデータに圧縮ルールを適用し、他のタイプのデータに機能冗長性ルールを適用するかもしれない。

図６は、本発明の実施例により利用されるデータを通信するモードベース通信システムを示す。システム６００は、メッセージインタフェース６１０と、メッセージキュー６２０と、ストリームフォーマッタ６３０と、ストレージ６４０と、メッセージ指向ミドルウェア６５０とを有する。メッセージインタフェース６１０は、１以上のプラットフォーム独立設定６１２と、機能冗長性ルール６１４と、キュー選択ルール６１６との１以上とやりとりするかもしれない。ストリームフォーマッタ６３０は、１以上のシーケンス化ルール６３２と、送信前ルール６３４とやりとりするかもしれない。機能冗長性ルール６１４、キュー選択ルール６１６、キュー６２０、ストレージ６４０、シーケンス化ルール６３２、送信前ルール６３４及び／又はメッセージ指向ミドルウェア６５０などのシステムの各種コンポーネントは、特定のモードに基づき設定されるかもしれない。

メッセージインタフェース６１０は、ノードに送信するための命令及び／又はデータを含むメッセージを受信する。メッセージインタフェース６１０は、命令及び／又はデータを含む命令を通信ネットワークのデスティネーションノードにルーティングする。メッセージインタフェース６１０は、例えば、１以上のルール、パラメータ及び／又は他の基準に基づきメッセージをルーティングする。メッセージインタフェース６１０は、例えば、プラットフォーム独立設定６１２、機能冗長性ルール６１４及び／又はキュー選択ルール７１７において検出されるルール、パラメータ及び／又は他の基準を利用する。機能冗長性ルール６１４は、冗長なメッセージコンテンツがどのように優先順位付け又は処理されるか指示する（例えば、古い冗長なメッセージの削除、新たな冗長なメッセージの削除、冗長なメッセージの優先順位の調整など）。キュー選択ルールは、異なるタイプのメッセージが何れのキューにルーティングされるか指定する。プラットフォーム独立設定６１２は、例えば、メッセージトラフィック制御及びシステム動作を管理する他の動作ルール、パラメータ及び／又は特性を含むかもしれない。

メッセージキュー６２０は、メッセージインタフェース６１０からメッセージを受信し、メッセージコンテンツの優先順位付け及び／又は他の処理のため、メッセージを１以上のキューに配置する。キュー６２０は、モードに基づきメッセージを優先順位付け及び／又は処理するための１以上の命令を有するかもしれない。命令は、例えば、フォーマッタアルゴリズム、アーカイブ制御、フォーマット化ルール及び／又はコンテンツ及び又はプロトコル優先順位付けルールなどを含む。これらの命令に対するキュー及び／又はパラメータに関する命令は、例えば、システム６００が動作しているモードに応じて変更されてもよい。

ストリームフォーマッタ６３０は、メッセージキュー６２０から送信されるメッセージのストリームをフォーマット化する。例えば、命令及び／又は他の基準に基づき、キュー６２０は、メッセージをストリームフォーマッタ６３０に送信する。シーケンス化ルール６３２、送信前ルール６３４及び／又は他の基準に基づき、ストリームフォーマッタ６３０は、デスティネーションノードへの送信のため、メッセージをストレージ６４０及び／又はメッセージ指向ミドルウェア６５０にルーティングする。ストレージ６４０は、例えば、特定のメッセージをアーカイブ及び／又は他のストレージに格納するモードに基づき制御されるかもしれない。シーケンス化ルールは、例えば、Ｋ^２若しくはＨＰＦ（Ｈｉｇｈｅｓｔ Ｐｒｉｏｒｉｔｙ Ｆｉｒｓｔ）及び／又はサンプリングシーケンスなどのメッセージストリームシーケンス化アルゴリズムを規定するモードに基づき制御されるかもしれない。送信前ルール６３４は、圧縮、暗号化及び／又は時間同期化などの特定の機能をストリームフォーマッタ６３０におけるメッセージに適用するモードに基づき制御されるかもしれない。その後、メッセージのフォーマット化されたストリームは、メッセージ指向ミドルウェア６５０に送信され、通信システムの１以上のノードに１以上のリンクのモードベースのサポートが提供される。一実施例では、通信は、メッセージインタフェース６１０が命令及び／又はデータを含むメッセージを送受信することを可能にする双方向のものであってもよい。

図７は、本発明の実施例により利用されるデータを受信するモードベース通信システム７００を示す。システム７００は、メッセージ指向ミドルウェア６５０と、ストリームプロセッサ６６０と、メッセージインタフェース６７０とを有する。ストリームプロセッサ６６０は、例えば、送信後ルール６６２とやりとりするかもしれない。メッセージインタフェース６７０は、プラットフォーム独立設定６７２及び／又は他のルール／パラメータなどとやりとりするかもしれない。メッセージ指向ミドルウェア６５０及び／又は送信後ルール６６２などのシステム７００の各種コンポーネントは、特定のモードに基づき設定されるかもしれない。

メッセージ指向ミドルウェア６５０は、フォーマット化されたメッセージなどのメッセージをストリームフォーマッタ６３０から受信する。メッセージ指向ミドルウェア６５０は、例えば、モードベースマルチリンクサポートを提供する。メッセージ指向ミドルウェアは、メッセージをストリームプロセッサ６６０にルーティングする。ストリームプロセッサ６６０は、例えば、送信後ルール６６２及び／又は他のルール／基準に従って受信したメッセージを処理する。例えば、ストリームプロセッサ６６０は、受信したメッセージに伸張、解読、時間同期化及び／又は他のルールを適用する。その後、処理されたメッセージストリームはメッセージインタフェース６７０に送信される。

メッセージインタフェース６７０は、ノードに送信するための命令及び／又はデータを含むメッセージを受信する。メッセージインタフェース６７０は、例えば、１以上のルール、パラメータ及び／又は他の基準に基づきメッセージをルーティングする。メッセージインタフェース６７０は、例えば、プラットフォーム独立設定６７２において検出されたルール、パラメータ及び／又は他の基準と共に、他のルール／パラメータを利用する。プラットフォーム独立設定６７２は、例えば、メッセージトラフィック制御及びシステム処理を管理する動作ルール、パラメータ及び／又は特性を含むかもしれない。メッセージインタフェース６７０は、ＸＭＬデータ及び／又は他のデータ／命令コンテンツなどのメッセージコンテンツを、デスティネーションへのさらなるルーティングのための中間ノード又はデスティネーションノードに送信する。

図８は、本発明の実施例によるデータ通信方法８００のフロー図を示す。本方法８００は、以下でより詳細に説明される以下の各ステップを含む。ステップ８１０において、プロファイルが生成される。ステップ８２０において、モードが選択される。ステップ８３０において、選択されたモードに基づき、通信システムの処理が設定される。ステップ８４０において、メッセージが送信される。ステップ８５０において、選択されたモードに基づき、ＱｏＳが提供される。ステップ８６０において、モードが調整されるかもしれない。本方法８００は、上述したシステムの各要素を参照して説明されるが、他の実現形態もまた可能であることが理解されるべきである。

ステップ８１０において、プロファイルが生成される。プロファイルは、動作モードを定義するパラメータ及び／又は動作特性を含むかもしれない。通信システム（及びネットワーク）は、モードに従って動作するかもしれない。例えば、モードは、何れのタイプのデータ及び／又は命令に何れのルールが適用されるか規定するかもしれない。プロファイルは、例えば、以降の利用のため保存されてもよい。

ステップ８２０において、モードが選択される。特定の実施例では、モードはデフォルトモードであるかもしれない。特定の実施例では、モードは自動的に選択されてもよい。特定の実施例では、モード選択は、動的かつ設定可能であるかもしれない。モード選択は、例えば、階層的及び／又はメニューベースであってもよい。モードは、例えば、プロファイルを選択することによって選択されてもよい。例えば、パトロールプロファイルは、パトロールで外出中に通信する兵士のため、パトロールモードで動作するよう選択されるかもしれない。

特定の実施例では、プロファイルは、環境又は設定における状態又は状況に応じて選択可能な複数のモードを含むかもしれない。例えば、パトロールプロファイルは、偵察時にパトロールの秘密の通信のための第１モードを含むかもしれない。パトロールプロファイルはまた、パトロール中の攻撃時の通信のための第２モードを含むかもしれない。ユーザは、プロファイルのモード間を手動によりスイッチしてもよく、及び／又は通信装置（無線など）が、モード間のスイッチを自動的に実行してもよい。

ステップ８３０において、通信システムの動作は、選択されたモードに基づき設定される。例えば、プロファイルは、ネットワーク及び／又は他の通信処理のためのパラメータ及び／又は特性を取得するため読み込まれるかもしれない。通信システムは、プロファイルのモードのパラメータ及び／又は特性に基づき調整される。例えば、メッセージフォーマット化、ストリーム化及び／又は他の処理が、選択された動作モードに係るルールにより影響を受けるかもしれない。

ステップ８４０において、メッセージが送信される。例えば、メッセージは、ソースノードからデスティネーションノードに送信されるかもしれない。１以上のメッセージが、モードに依存するかもしれない１以上のルール及び／又は基準に基づき、メッセージを優先順位付け及び／又は処理するため、通信中にキュー処理されるかもしれない。メッセージは、例えば、受信された順序及び／又は他の順序によりキュー処理されてもよい。特定の実施例では、メッセージは１以上のキューに格納されるかもしれない。１以上のキューには、例えば、異なる優先順位及び／又は処理ルールが割り当てられるかもしれない。異なる優先順位及び／又はルールは、例えば、モードに基づくかもしれない。キューのメッセージは、例えば、少なくとも部分的に動作モードなどに基づき優先順位付け及び／又は処理されるかもしれない。

ステップ８５０において、選択されたモードに基づき、ＱｏＳが提供される。例えば、モードを規定するプロファイルのパラメータ及び／又は動作特性は、データの通信のためなど、ルール及び／又は優先順位付けを規定する。

例えば、通信システムは、戦術通信ネットワークを介し受信したメッセージの優先順位を決定するかもしれない。優先順位は、例えば、メッセージのソースアドレスに基づくものであってもよい。例えば、通信システムが属する小隊と同じ小隊のメンバーの無線からのメッセージのソースＩＰアドレスは、異なる作戦エリアの異なる部門のユニットからのメッセージより優先されるかもしれない。優先順位は、以降の通信のため、メッセージが複数のキューの何れに配置されるべきか決定するのに利用されるかもしれない。例えば、より高い優先順位のデータは、高い優先順位のデータを保持するためのキューに配置され、通信システムは、何れのデータが次に通信されるか決定するのに、まず上位の優先順位のキューを参照するかもしれない。

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

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

ステップ８６０において、モードは調整されるかもしれない。特定の実施例では、モードは、例えば、ユーザによる手動の選択及び／又は動作状態に基づき自動的に調整される。調整は、あるモードから他のモードへのスイッチ、モードの変更及び／又は新たなモードの生成などを含むかもしれない。

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

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

本発明の特定の実施例は、プロファイル及び／又はモードドリブン通信リンク管理のためのシステム及び方法を提供する。特定の実施例は、１以上のモードを含むプロファイルを規定し、目的又は動作環境などの基準に応じて１以上のプロファイルの間のスイッチを可能にするという技術的効果を提供する。このため、特定の実施例は、伝送されるデータの種類に関係なく、ビットの伝送を可能にするデータとリンクの間の抽象化を設ける。特定の実施例は、単一のモードスイッチ命令を介したスループット管理、送信処理、アーカイブ設定及び伝送選択のためのフレキシブルなリンク設定を可能にする。自動的なモードスイッチは、ネットワーク健全性に対する動的な反応を提供する。特定の実施例は、命令されたモードスイッチを介し複数の動作シナリオをサポートする。特定の実施例は、例えば、スループット管理ルール、アーカイブ設定、送信前及び送信後ルール並びに伝送選択などを規定する各種モードを提供する。特定の実施例は、例えば、トランスポートレイヤの上位のトイかなリンク管理を可能にする。

１００ ネットワーク環境
１１０ 通信ノード
１２０ ネットワーク
１３０ リンク
１５０ 通信システム
４１０ データ通信システム

Claims (10)

1. ネットワークを介したデータ通信のための方法であって、
   少なくとも１つの電子回路が、複数の選択可能なモードを規定する複数のルールを含むネットワーク通信システムのプロファイルを生成するステップと、
   前記電子回路が、ネットワーク測定の解析に基づき複数のネットワーク状態からネットワーク状態を決定するステップと、
   前記電子回路が、前記ネットワーク状態に基づき、各シーケンス化ルールがデータストリームにおいてメッセージがシーケンス化されるべき順序を規定する、ユーザにより規定される異なるシーケンス化ルールを含む前記複数の選択可能なモードからモードを選択するステップと、
   前記電子回路が、以前に選択された前記モードのユーザにより規定されるシーケンス化ルールに基づき前記メッセージをシーケンス化するステップと、
   前記ネットワーク通信システムから前記メッセージを通信するステップと、
   前記以前に選択されたモードのルールセットに従って、前記ネットワーク上の通信のためのＱｏＳを提供するステップと、
   を有し、
   前記ＱｏＳは、前記ネットワーク通信システムのネットワーク通信プロトコルスタックのトランスポートプロトコルレイヤとソケットレイヤとの間で提供される方法。
2. 前記プロファイルは、前記ネットワークを設定するための複数のプロファイルから動的に選択される、請求項１記載の方法。
3. 前記プロファイルを変更するステップと、新たなプロファイルを生成するステップとの少なくとも１つをさらに有する、請求項１記載の方法。
4. 前記複数のルールの少なくとも１つのルールに基づき前記メッセージの少なくとも１つを優先順位付けするステップをさらに有する、請求項１記載の方法。
5. ネットワーク動作のための前記モードの選択は、前記ネットワークが動作する環境における帯域幅制限に少なくとも部分的に基づく、請求項１記載の方法。
6. 前記プロファイルのモードに基づき前記メッセージの少なくとも１つを送信するステップをさらに有する、請求項１記載の方法。
7. ＱｏＳを提供するネットワーク通信システムであって、
   複数の選択可能なモードを規定する複数のルールを含む当該ネットワーク通信システムのプロファイルを生成し、
   ネットワーク測定の解析に基づき複数のネットワーク状態からネットワーク状態を決定し、
   前記ネットワーク状態に基づき、各シーケンス化ルールがデータストリームにおいてメッセージがシーケンス化されるべき順序を規定する、ユーザにより規定される異なるシーケンス化ルールを含む前記複数の選択可能なモードからモードを選択し、
   以前に選択された前記モードのユーザにより規定されるシーケンス化ルールに基づき前記メッセージをシーケンス化し、
   前記ネットワーク通信システムから前記メッセージを通信する、
   ように構成される少なくとも１つの計算装置を有するネットワーク通信システム。
8. 前記プロファイルは、各プロファイルがユーザと前記計算装置との少なくとも１つにより選択可能な複数のモードを含む複数のプロファイルの１つである、請求項７記載のネットワーク通信システム。
9. 前記モードの選択は、前記ネットワークが動作する環境における帯域幅制限に少なくとも部分的に基づく、請求項７記載のネットワーク通信システム。
10. 前記ネットワーク通信システムはさらに、前記プロファイルの変更及び新たなプロファイルの生成の少なくとも１つを実行するよう構成される、請求項７記載のネットワーク通信システム。

Images