JP5376753B2 - 状況情報を伝播する方法 - Google Patents

Description

ここに開示する技術は、ネットワーク化の分野に属する。

緊急警告システムや、衝突回避や、トラフィック監視や、ルート計画や、その他多くの分野などの重要な用途としての潜在性によって、車両アドホックネットワーク（ＶＡＮＥＴ）及びＶＡＮＥＴに基づいたインテリジェント輸送システムに関する重要な研究が促進されてきた。

ＶＡＮＥＴによる安全性に関する応用例（用途）については、たとえば、２０００年１０月のＩＥＥＥのインテリジェント車両シンポジウムの議事録におけるＬ．Ｂｒｉｅｓｅｍｅｉｓｔｅｒらによる「車両間通信に基づいた高度移動性ホスト同士でのメッセージの配信」（非特許文献１）を参照されたい。

レイヤ（層状）データを拡散（配信）させるというアイデアは、さまざまな用途における情報に対する近接性ベースの情報必要性を動機として、Ｌ．Ｂ．Ｍｉｃｈａｅｌによって検討されている（２００１年の第８回インテリジェント輸送に関する世界会議の議事録中の「アドホック通信ネットワーク上での車両間通信のための適応性層状データ構造」（非特許文献２）を参照）。Ｍｉｃｈａｅｌのデータ構造を用いると、パケットがデータの層とともに送信され、その情報がソースから離れるにつれて、これらの層がこのデータ構造から次々に除去される。この方式の欠点は、この層状のデータ構造中に存在する形態とは異なったいかなる形態の断片的な情報をも、その存在する可能性を抑止してしまうことである。
"Disseminating messages among highly mobile hosts based on inter-vehicle communications," Proc. IEEE Intelligent Vehicles Symposium, October 2000 "Adaptive layered data structure for inter-vehicle communication in ad hoc communication networks," Proc. 8th World Congress on Intelligent Transportation, 2001

本発明は、複数のノードを含んでいるネットワーク環境において、視認性関数を用い、ネットワーク環境中を伝播するように条件つけられている状況情報を、異なる分解能（データ解決度）を有するように送出する方法及び装置を提供する。視認性関数はネットワーク環境内において状況情報が有するべき異なる分解能を表す分解能プロフィールの特徴（特性）を表現するものである。

本発明の一態様は、ネットワーク化された情報に対して視認性関数を適用する方法であって、該方法は、ネットワーク環境中で視認性関数を用いることであって、前記ネットワーク環境が複数のノードを含み、前記複数のノードの内の少なくとも１つのノードが前記複数ノードの１つ以上のサブ集合に対して直接に通信可能であり、前記視認性関数が前記ネットワーク環境内における分解能プロフィールを特徴付け、前記分解能プロフィールが前記複数のノードの前記サブ集合外部の少なくとも１つのノードにまで伸張し、前記分解能プロフィールが不均一である、視認性関数を用いることと、前記ネットワーク環境中を伝播するように調整された第１の状況情報を前記視認性関数にしたがって送信すること、を含む。

上記の方法は、個別と組み合わせの双方の方式で最適化されたユーティリティを得るために、複数のユーティリティ意識アプリケーションのユーティリティを、その個別のユーティリティについて最適化すること、をさらに含んでもよい。

本発明の別の態様は、ネットワーク化された情報に対して視認性関数を適用する装置であって、第１の状況情報を提供するように構成されたデータソースと、データソースから提供された前記第１の状況情報と共に視認性パラメータを含むように構成された視認性割り当てロジックであり、前記視認性パラメータは視認性関数に応答する、前記ロジックと、視認性割り当てロジックに応答し、ネットワーク環境中の複数のノードから成るサブ集合の内の１つ以上のノードに対して前記第１の状況情報を送信するように構成される、ネットワークインタフェースと、を備え、前記視認性関数が前記ネットワーク環境内での分解能プロフィールを特徴付け、前記分解能プロフィールが不均一であり、また、前記複数のノードのサブ集合の外部の少なくとも１つのノードにまで伸張する。

本発明のさらに別の態様は、ネットワーク化された情報に対して視認性関数を適用する装置であって、該装置は、ネットワーク環境中の複数のノードの内の１つのノードからの第１の状況情報を受信するように構成された受信機であって、前記ネットワーク環境が複数のノードを含み、前記第１の状況情報が視認性パラメータを含み、前記視認性パラメータが、前記ネットワーク環境内での分解能プロフィールを特徴付ける視認性関数に応答する、前記受信機と、前記視認性パラメータに応答し、前記第１の状況情報が前記ネットワーク環境中を引き続き伝播する資格があるかどうかを判定するように構成された判定ロジックと、前記第１の状況情報を判断ロジックに応答して送信する準備をするように構成された送信準備ロジックと、を備える。

本書に開示する技術は、ノードの集合を含んでいるネットワーク環境において視認性関数を用いる方法、装置およびプログラム製品を教示するものである。ノードの内の少なくとも１つは、ノードの集合の中のサブ集合の１つ以上と、直接に通信することができる。この視認性関数は、このノードのサブ集合の外部にある少なくとも１つのノードにまで伸張するネットワーク環境内における不均一な分解能（データ解決）プロフィール（resolution profile）の特徴を表すものである。本方法は、視認性関数にしたがってネットワーク環境中を伝播するように調整されている状況情報を送信するものである。

この開示されている技術はまた、ネットワーク環境においてこれらノードの内の１つのノードによって状況情報を受信する方法、装置およびプログラム製品を教示するものである。この状況情報には、視認性関数に対応する視認性パラメータが含まれる。この視認性関数は、ネットワーク環境内の分解能プロフィールの特徴を表す。ノードは、いったん状況情報を受信すると、ノードは視認性パラメータを評価して、状況情報が、ネットワーク環境中を引き続き伝播し続ける資格があるかどうか判定する。状況情報が引き続き伝播する資格がある場合、ノードは状況情報を再送信する準備をする。

本発明者は、ネットワークのキャパシティ（容量）の使用を最小に抑えながらも、ネットワーク環境の一部分の中で状況情報を効率的に伝播させる必要性を認識した。本発明者はまた、多くの応用例にとって、データが必要とするまたは所望される「分解能（解決度：resolution）」は、ソースノードから状況情報が伝播する距離につれて変動しえるものであることを認識した。

多くの用途では、（たとえば、粒状度（granularity）と精度分解能双方の特長に対する）情報の分解能に対する要求は距離に連れて変化し、近接したノード同士は、遠隔のノード同士よりもより正確で時宜に適った情報を互いに必要とする。このような用途では、近距離情報は、より隔たったソースノードからの情報より即時的決断に関わるものである。情報の分解能はその情報中の詳細の内容の分量を示している応用例もある。状況情報の分解能が、この状況情報を保持するために用いられるデータフィールドのサイズ（したがって情報の精度）の関数であったりする応用例もある。さらに、情報の分解能が、情報の適時性または粒状度であったりする（より近いノード同士は、より遠いノード同士よりもより最近の情報を必要とし、したがって、近いノード同士は遠いノード同士よりもより微細な粒状度を必要とする）応用例もある。近接した同じロケーションにある複数のソースノードが、類似の状況情報を送出しうる応用例もある。どの特定のノードにおいても、分解能は、複数のソースから受信された状況情報、１つのソースからの複数の状況情報更新内容、またはこれらの何らかの組み合わせを平均化した結果であり得る。分解能はまた、受信された状況情報更新内容の数に依存しうる。したがって、ある推論に向かう傾向がある複数の更新内容は、状況情報が１つだけ得られたことによって裏付けられた推論よりも高い分解能を有する。このような特徴と本明細書には記載していない他の特徴の組み合わせである情報分解能を有しうる応用例もある。

たとえば、衝突回避という用途では、警告情報がネットワーク環境中を近距離に渡って伝播しさえすればよい。この用途ではまた、警告情報が正確で時宜に適っていることが必要とされる。この情報はソース車両の近くにある車両によって受信されなければならないが、それは、このような近くある車両は、ソース車両の警告情報に対しては短い応答時間しか有していないからである。しかしながら、この警告情報は、ソース車両からより隔たったところの車両に対してはあまり重要でないが、それは、このような遠隔にある車両は、近接した車両よりも警告情報に対してはるかに長い応答時間を有しているからである。

別の例では、車両の運転者は、大都市圏における道路状況、気象状況および／または交通状況などの情報を用いるトラフィック計画アプリケーションを呼び出すことができる。このような用途では、大都市圏からの可変の分解能情報で十分である（分解能は車両から遠ざかるに連れて劣化する）。

このような応用例の必要性を満たすために、本発明者は「視認性」というコンセプトを開発した。視認性とは、情報を用いる際の可変分解能に対する要件を定量化するために用いられる。本発明者は、確率的な仕組みを用いて、可変分解能情報普及（ＶＲＩＤ：variable-resolution information dissemination）プロトコルの視認性を実現した。くわえて、本発明者は、伝播した状況情報の値（ユーティリティ：utility）とこの状況情報の視認性との間に関係があると判断した。この関係は、アプリケーションの設計者が、特定のタイプおよび／または用途の状況情報にとって適切な視認性を決定する際に助けとなり得るものである。視認性関数は、ネットワーク環境の全体またはある部分にわたる分解能プロフィールを定義するものである。分解能プロフィールは、ソースノードから発した情報の、このソースノードからある距離だけ隔たったところに位置する受信側ノードでの分解能を示すものである。

可変分解能情報普及は、新しいタイプの１対多（マルチキャスト）の情報普及（伝播）パラダイムである。ＶＲＩＤは、ＩＰマルチキャスト、Geocast、Mobicastなどの従来の情報普及技法とは異なっているが、それは、分解能往路フィールが受信側ノード全体にわたって１００％一様ではないからである。期待される受信者の集合にとって視認性が１００％である場合、ＶＲＩＤはＩＰマルチキャストや、Geocastや、Mobicastをエミュレート可能であるが、その主要な用途は、可変分解能情報を提供することにある。

ＶＲＩＤを用いると、ネットワーク環境全体にわたる複数の受信者に対して状況情報を伝播させることが可能である。これが一般的なポイントツーポイント通信と異なる点は、目的がどれか特定のノードに情報を輸送することにあるのではなく、むしろ、ネットワーク環境中で何が発生しつつあるのかに関する情報を、ノードがそれに気が付くことが可能となるように、ある程度まで拡散させることにあるという点である。

ブロードキャストと比較して、可変分解能情報普及では、ネットワーク環境中では少ないリソースであるかなり小さい通信帯域幅を用いている。

可変分解能情報普及を用いると、次のような対処が可能となる：
（１）ＶＲＩＤは、ソースノードからの情報の値がソースノードからの距離の関数であるような状況を満足することが可能である（使用できる）。たとえば、実社会における多くの応用例では、情報は、情報のソースからの距離の関数である明確な値（「ユーティリティ（有用性値）」）を有する。たとえば、車両対車両衝突警告という用途の場合、ある特定の車両の位置と速度の情報およびこの情報の即時性はその隣接する車両にとっては高いユーティリティを有する。しかしながら、この情報は、この特定の車両から離れたところにある車両にとってはあまり役に立たない（ユーティリティが低い）。また、この情報は、地球の裏側にある車両にとっては何の価値もない。さらに、この特定の車両に隣接している車両は高い分解能の情報（たとえば、正確で時宜に適うロケーションと速度のデータを含む情報）を必要とする。しかしながら、この特定の車両からさらに隔たったところにある車両は、より低い分解能の情報でも許容しうる。

（２）ＶＲＩＤでは、高分解能情報がネットワーク環境中のすべてのノードに対して送られるわけではないため、ネットワーク環境の利用可能なキャパシティ（容量）をあまり使用しない。そうする代わりに、可変分解能情報が分解能プロフィールにしたがって提供され、これによって、ネットワーク環境のキャパシティの使用を軽減する。

（３）ＶＲＩＤによって、類似の状況情報を用途ごとに別様に用いることが可能となる。たとえば、情報の粒状度要件は、用途ごとに異なり、出口意識・車線変更アドバイスシステムでは、出口からかなり限られたある距離内のすべての車両からの時宜に適った（粒状度の細かい）正確な位置・速度情報が必要とされるが、一方、ピアツーピア協同トラフィック監視システムでは、非常に低い更新頻度で５００メートル間隔のところにある車両からの位置・速度情報を必要とするだけである（したがって、この情報の分解能は、進路粒状度特徴を有する）。

（４）ＶＲＩＤによって、類似した分解能プロフィールを有する状況情報を状況情報グループに分類することが可能である。ＶＲＩＤによって、ネットワーク環境キャパシティの使用（および他のリソースの使用）を軽減することが可能となるが、それは、ＶＲＩＤは、複数のアプリケーションからの状況情報を蓄積して、この情報を、送信用の状況情報グループに組織化することが可能であるからである。

（５）ＶＲＩＤは分解能プロフィールを決定するために情報のユーティリティ（有用性）を使用することができる。これにより、本発明を実施するプログラマが視認性関数を決定するタスクが簡単なものになる。

可変分解能情報の普及においては視認性関数というコンセプトが用いられるが、この関数は、ソースノードから発した状況情報がネットワーク環境においてどの範囲にまで「視認可能」であるかをあらわす分解能プロフィールを指定するものである。たとえば、一次元の直線ｘ∈Ｒに沿ったネットワークを想定してみる。視認性関数Ｖ（ｘ）は、［０，１］という間隔中の値を取って、ロケーションｘのところで維持されるソースノード（ｘ＝０と仮定する）からの情報の「分解能」を指定する。

図１に、本開示の技術の実施形態が動作可能なネットワーク環境１００を示す。該ネットワーク環境１００は、潜在的に状況情報を共有することが可能なノードの集合１０１を含んでいる（図１と２では、各々のノードは円形の投影物として示されている）。ノードの集合１０１の内の１つはソースノード１０３であり、これは、ネットワーク環境全体にわたる可変分解能伝播のための状況情報を送信することが可能である。ソースノード１０３から送信された内容は隣接するノード１０５に直接に到達可能であるが、隣接していないノード１０７には直接には到達不可能である。（隣接していないノード１０７は、自身に隣接するノードのうちの１つから、元々ソースノード１０３から送信され、その自身に隣接するノードが再送信した状況情報を受信する。）状況情報は、センサー、プロセッサ、ロジック、回路などのデータソースによって提供可能であり、また、生の形態でまたは処理された形態で提供されることができる。

送信された状況情報の中には可変分解能情報普及により処理されるものもあるが、されないものもある。

可変分解能情報普及により処理された状況情報は、ネットワーク環境１００中における各々のノードにおける状況情報の「分解能」を表す視認性関数によって定義された分解能プロフィール（たとえば、円形の分解能プロフィール１０９）にしたがってノードの集合１０１中を伝播する。

１つの実施形態では、視認性関数は、状況情報の伝播を伝播距離境界１１１までに制限する。したがって、ソースノードの状況情報を受信した伝播距離境界１１１の外部にあるノードは、状況情報を再送信しない。いくつかのタイプの状況情報／アプリケーションの組み合わせの場合、伝播距離境界１１１がソースノード１０３から遠隔地となりうるが、また別のタイプの状況情報／アプリケーションの組み合わせの場合では、伝播距離境界１１１がソースノード１０３の近くとなりうることが理解されるであろう。さらに他の実施形態では、ネットワーク環境中のあらゆるノードに伝播するために低分解能の状況情報を許容しうる。

図２は、楕円形の分解能プロフィール２０９を有するネットワーク環境２００を示す。

一実施形態では、分解能プロフィールは、ソースノード１０３が、更新された状況情報を周期的に送出することによって達成され、更新パケットは各々が、更新パケットがそこから伝播されるソースからの伝播距離を指定する伝播距離成分（コンポーネント）などの視認性パラメータを（視認性関数にしたがって）含んでいる。更新パケットは、伝播距離成分によって指定される距離より遠方に存在するノードに到達すると、そのノードによって再送信されることはない。供給された更新パケットはその各々が、互いに異なった伝播距離成分値を有することにより、時間の経過にしたがって更新パケットを介して提供される状況情報の分解能が分解能プロフィールに適合するようにさせることができる。別の実施形態では、分解能プロフィールは、送信される状況情報に視認性パラメータを含ませ、各々の転送ノードが、供給された視認性パラメータを用いて視認性関数を適用して、状況情報の伝播を継続すべきであるかどうかおよび／または更新パケットに含まれる情報の精度を下げるべきであるかどうかを判断できるようにすることによって、達成することが可能である。

ソースノード１０３からの伝播距離は地理的な距離であってよい。一部の実施形態では、伝播距離成分は「ホップカウント」を用いて指定することが可能である。

このように、視認性関数は、状況情報がどのようにネットワーク環境の一部分を伝播するかと、ネットワーク環境全体にわたる状況情報の分解能とを指定する。

視認性関数は、車両状態情報および／または環境情報を含むことができる更新パケット内で、イベントパケット中で送出されるイベント発生情報と、測定されたものであれ、処理されたものであれ、集約されたものであれ、推論されたものであれ、および／または誘導されたものであれ、１つ以上のセンサーによって提供されうる他の何らかの情報などの送出される状況情報に、たとえば無制限に適用することが可能である。イベント情報には、イベント開始情報、イベント更新情報およびイベント終了情報を含むことができる。

１つの実施形態では、視認性関数Ｖ（ｘ）は、たとえば、距離ｘのところにあるあて先に到達するパケットのパーセンテージとして定義することができる。この実施形態では、状況情報を含んでいるすべての更新パケットは関連するアプリケーションにとっては等しく重要である。視認性関数は、ソースノード１０３の観点から定義されたり（たとえば、ソースノード１０３は、特定の状況情報に対する分解能プロフィールや分解能がどのように変化すべきであるかを決定する）、アプリケーションの観点から定義されたり（たとえば、エアバッグの取り付けは政府に指定された分解能プロフィールを有する）、あるいは、状況情報を用いるアプリケーションが特定のユーティリティを有しており、情報ユーティリティ関数を用いて視認性関数を指定したりすることができる。

多くの方法を用いて視認性関数Ｖ（ｘ）を得ることができる。１つのソースが更新パケットを繰り返し送信することによって状況情報を提供するような環境においては、該ソースは、視認性関数を適用して、各々の更新パケットに対する伝播距離と分解能成分とを決定し、これにより、更新パケットの組み合わされた伝播範囲が視認性関数の制約内に収まり、したがって、時間の経過とともに望ましい分解能プロフィールを生成することができる。複数のソースがアプリケーションに対する更新パケットを提供している実施形態においては、これらのソースの各々が、視認性関数に従って伝播距離を互いに独立して指定することが可能である。

ソースは、更新パケット内に視認性パラメータを含めることができ、また、伝播距離を考慮することなく更新パケットを送信することが可能である。これらのパケットは次いで、受信側のノードにより個々の更新パケット内の視認性パラメータに応答して確率的に伝播される。この伝播側ノードはまた、視認性パラメータに応答して、更新パケット内の状況情報の精度を減少させることが可能である。これら送信のタイプの内の一方を可能としたり、他方を可能としたり、双方を可能としたりする実施形態がある。

いくつかの実施形態では、ソースノードは、更新パケットが移動する先の距離ｘ_cを更新パケットごとに選択することが可能である（更新パケットは、｜｜ｘ｜｜＞ｘ_cであるような第１のノードによって再送信されることはない。ここで｜｜ｘに｜｜はこのノードのソースノードからの距離である）。これらの実施形態では、ソースノードは、分布ｐ_d（ｘ）を決定して、各々の更新パケットに対して距離を選択することにより、所望の分解能プロフィールを達成する。

一部のＶＲＩＤ実施形態では、距離ｘのところにあるノードがメッセージを受信すると、ｘ以下の距離にあるすべてのノードもまたメッセージを受信しなければならない。このような状態では、視認性関数は単調に減少する関数とならざるを得ない。

このような実施形態では、視認性パラメータとしてｘ_cが（確率ｐ_d（ｘ_c）で）選択されると、距離ｘ_c以下の位置にあるすべてのノードがメッセージを受信するため、距離ｘにあるノードがメッセージを獲得する確率は次のようになる。

したがって、次式が得られる。

ｖが減少する値であって微分可能であれば、ｐ（ｘ）＝−ｖ’（ｘ）という設定は上の式を満たす。したがって、各々の更新パケットを送出する距離の分布はｐ_d（ｘ）＝−ｖ’（ｘ）となる。ｖが階段関数であれば、間隔ｉの端のところにおける距離ｄ_iはｖ_i−ｖ_i+1という確率で選択することが可能である。

この視認性関数はｎ次元で拡張される。各々のノードが同じ更新パケットの複数のコピーは単純に無視するため、この視認性関数は多経路ルーティングによって影響されることはない。

モバイルアドホックネットワークにおいては、ＶＲＩＤは周知のブロードキャストストームという問題に対処する必要がある。ブロードキャストストームは、アドホックネットワーク上でノードに対して更新パケットがあふれると発生する。その結果としての渋滞によって、ノードは更新パケットの伝播を遅延させ、この遅延させたノードが結局は、更新パケット中の情報の有用な期間がはるか過ぎた後で更新パケットを送信することになる。

ブロードキャストストーム問題を解決するには多くの手法がある。ある実施形態では、視認性関数を「ゴシップスタイル（Gossip-style）」障害検知によるストーム対策（アンチストーム）アルゴリズムと組み合わせている。このようなアンチストームアルゴリズムを用いるノードは、新しい更新パケットを受信しても、必ずしもその更新パケットをさじ送信するとは限らず、むしろ、受信側ノードは隣接するノードのブロードキャストをリッスン（待機検知）する。同じ更新パケットが所定の回数（「ゴシップカウント」）だけ検知されれば、その更新パケットはこの受信側ノードによって伝播されない。視認性関数はまた、他のアンチストームおよび／または伝播技法で用いることも可能である。このゴシップカウントはブロードキャストストーム制御パラメータと考えることができる。

アンチストームアルゴリズムを用いるということは一般に、更新パケットが不慮に失われたために一部のノードでは更新パケットが受信されないことを暗に含むものである。このパケット損失は、ノード密度（これには、隣接ノード密度や、ネットワーク環境全体にわたるノード密度が含まれる）などのネットワーク特徴（特性）の関数である。不慮の更新パケット損失によって、達成される分解能プロフィールが視認性関数で指定されたものとは異なるものとなる。

不慮のパケット損失は、「パケット損失」視認性関数Ｖ_fとしてあらわすことが可能である。たとえば、線形帯（linear strip）環境で一様なパケット損失が発生すると、「パケット損失」視認性関数はＶ_f（ｘ）＝ｅ^pxとなる。必要以上の実験をする必要なく、線形帯環境以外の環境のＶ_fをも決定することができる。

一実施形態では、ネットワーク環境にとって適切な「パケット損失」関数を用いることによって、視認性関数の偶発的更新パケット損失による誤差を補正することができる。したがって、線形帯環境においては、事前補正された視認性関数Ｖ_c（ｘ）＝（Ｖ_t（ｘ）／Ｖ_f（ｘ））は所望の視認性関数Ｖ_tを調整して、予想される更新パケット損失に対処することにより、所望の分解能プロフィールを達成する。視認性関数は、ネットワークの特徴に応答した視認性調整ロジックによって調整することが可能である。

本発明者はまた、更新パケット損失はゴシップカウント（またはその同等物）を調整することによって補償することが可能であることをも認識した。ネットワーク特徴（たとえば、ＶＡＮＥＴ内でのような時間とともに変化するノード密度）を有するネットワーク環境においては、各々のノードはその隣接するノード密度をサンプリングして、それにしたがってそのゴシップカウントを調整することができる。一部の実施形態においては、隣接ノード密度の判定は、隣接していないノードにまでその範囲が及ぶことがありえる。この調整が次式にしたがって実行することが可能である。

ここで、ｇｃはゴシップカウント、ｄは隣接ノード密度、その他の定数は実際の環境またはモデルとされた環境から決定されたものである。上記のゴシップカウント関数は、密度の低い領域でｇｃ（ｄ）を増加させることによって隣接ノード密度の関数としてゴシップカウントを調整するために用いることが可能な関数の内の１つに過ぎない。

このように、ゴシップカウントを変更して、システムを隣接ノード密度の変動に対してよりロバストなものとすることが可能である。また、このゴシップカウントを変更して、ネットワーク環境のキャパシティの使用を軽減することも可能である。

ネットワークトラフィックは、ゴシップカウントに対してほぼ線形に変化するため、ゴシップカウントは「よく消化される（well-spent）」べきである、すなわち、ゴシップカウントは、いまだ大きい距離を伝播しなければならない更新パケットに対しては高く（したがって、このパケットは、受信側ノードによって再送信される可能性がより高く）あるべきである。（なぜなら、このような更新パケットを欠落させてしまうことは、ネットワーク環境全体にわたって知られる情報に対して潜在的にかなり大きいインパクトを有するからである）より正確に言えば、ゴシップカウントは、ゴシップカウントに対する障害率のわずかな減少を均等化させるために、更新パケットがまだ伝播しなければならない距離に基づいて動的に調整されることができる。したがって、特定の更新パケットに関連するゴシップカウントｇｃ_pは、更新パケットがまだ伝播しなければならない距離の関数であることができ、一実施形態では、次のように表すことが可能である。

ｇｃ_pは更新パケットがまだ移動しなければならない距離に基づいてゴシップカウントを調整するために用いることが可能な多くの考えられる関数の内のほんの１つに過ぎないことが理解されるであろう。定数は、実測定またはネットワーク環境をモデリングすることによって決定することが可能である。定数は、更新パケットを再送信するときにノード環境に応じて選択することが可能である。

動的に調整されたゴシップカウントを用いると、トラフィックを減少させ、送信中の損失を軽減することが可能である。視認性関数を事前補正して、更新パケット損失の影響を除去することが可能となる。

視認性関数は、アプリケーションおよび／または伝播中の状況情報のタイプによって異なる。たとえば、分解能プロフィールの形状は、ルート計画アプリケーションと緊急警告アプリケーションを比較すると非常に異なる。視認性関数を決定するために用いることができる１つの方法は、さまざまなパラメータを実験（またはモデリング）して、アプリケーションに対する適切な視認性関数をヒューリスティック（発見的）に選択する方法である。また、情報ユーティリティ関数に関してアプリケーションの情報必要性をモデリングして、この情報ユーティリティ関数から視認性関数を決定することによって、視認性関数を決定することが可能である。

図３に、上記で検討したコンセプトを実施するためにネットワーク環境中のノードによって用いることができる送信／受信プロセス３００を示す。この送信／受信プロセス３００は、電力および／またはリセット信号の検出に応答して「開始」ターミナル３０１から始動され、いずれか必要とされる初期化を実行する「初期化」手順３０３に続く。次に、送信／受信プロセス３００はそのまま「パケット受信」手順３０５に進み、情報のパケット（たとえば更新パケット）を受信する。いったん情報のパケットが受信されると、送信／受信プロセス３００は「視認性有効パケット」判定手順３０７に進み、情報のパケットが視認性パラメータを含んでいるかどうか判定する。含んでいれば、送信／受信プロセス３００は「距離制限」判定手順３０９に進み、視認性パラメータデータを用いて、情報のパケット（または情報のパケット内の状況情報グループ）が引き続きネットワーク環境中を伝播すべきであるかどうか判定する。情報のパケットがその伝播距離に達したまたは超えた場合、送信／受信プロセス３００は「処理用パケットキューイング」手順３１１に進み、情報のパケットを、それが含む状況情報を後で処理するためにキューイングする（待ち行列に入れる）。次に、送信／受信プロセス３００は「パケット受信」手順３０５に復帰して、次の受信情報パケットを処理する。

「視認性有効パケット」判定手順３０７で、情報のパケットが視認性パラメータを含んでいない場合、送信／受信プロセス３００は「パケット再送信」判定手順３１３に進み、情報のパケットが再送信される資格があるかどうか判定される。情報のパケットが（アンチストームアルゴリズムの動作によってなどで）再送信される資格がない場合、送信／受信プロセス３００は「処理用パケットキューイング」手順３１１に進み、情報のパケットを、それが含む状況情報を後で処理するためにキューイングする。次に、送信／受信プロセス３００は「パケット受信」手順３０５に復帰して、次の受信された情報のパケットを処理する。

しかしながら、「パケット再送信」判定手順３１３で、情報のパケットが送信される資格がある場合、送信／受信プロセス３００は「送信用パケットキューイング」手順３１５に進み、再送信用の情報のパケットをキューイングし、さらに送信／受信プロセス３００は「処理用パケットキューイング」手順３１１に進みて、情報のパケットを、それが含む状況情報を後で処理するためにキューイングする。次に、送信／受信プロセス３００は「パケット受信」手順３０５に復帰して、次の受信された情報のパケットを処理する。一部の実施形態では、情報のパケットは送信されるためにキューイングされることはなく、即座に送信される。したがって、送信準備ロジックは、キューイングロジック、衝突ロジック、タイムスロットロジックなどを含みうる。

「距離制限」判定手順３０９で、情報のパケットがその伝播距離に達していない場合、送信／受信プロセス３００は「オプション分解能処理」手順３１６に進み、視認性パラメータに応答して、情報のパケットまたは状況情報グループ中に含まれる情報の分解能特徴の内の１つを調整することが可能である。

次に、「視認性有効パケット再送信」判定手順３１７に進み、送信／受信プロセス３００を実行しているデバイスに近接しているネットワーク環境の現状を考慮して、情報のパケットを再送信すべきであるかどうか評価する。情報のパケット（または状況情報グループ）が伝播し続けるべきであれば、送信／受信プロセス３００は「送信用パケットキューイング」手順３１５に進み、以前に述べたように、引き続き再送信と処理を実行する。しかしながら、ローカルネットワーク環境の状態が、情報のパケットを再送信する必要がない状態であれば、送信／受信プロセス３００は「処理用パケットキューイング」手順３１１に進み、以前に述べたように処理を実行する。

図３の実施形態は、より単純な実施形態に縮小されうることが理解されるであろう。たとえば、すべての情報パケットが視認性パラメータを含んでいる場合、「視認性有効パケット」判定手順３０７はもはや不必要である。さらに、「オプション分解能処理」手順３１６を省略すると、「距離制限」判定手順３０９は、送信／受信プロセス３００の必要とするキャパシティ次第で「送信用パケットキューイング」手順３１５か「視認性有効パケット再送信」判定手順３１７に直接に接続することが理解されるであろう。さらに、一部の実施形態では、「処理用パケットキューイング」手順３１１と「送信用パケットキューイング」手順３１５の代わりに、それぞれ実際の処理手順と送信手順を実行することが可能であることが理解されるであろう。さらに単純化して得られる全てのさらなる実施形態が図３に示す実施形態によって教示される。

ＶＲＩＤを用いて分布された情報のパケットは一般にネットワーク環境全体にわたって完全に伝播されることはないため、このような伝播目的で用いられるネットワークキャパシティを節約することができ、他の通信のためにキャパシティを用いることが可能である。

「視認性有効パケット再送信」判定手順３１７は、情報のパケット（または状況情報グループ）を再送信すべきであるかどうかをローカルネットワーク環境状態に基づいて評価する。ノード密度決定ロジックを用いて、ノードはその隣接するノード密度をサンプリングして、ゴシップカウントを調整することにより、ローカルネットワークトラフィックを軽減し、隣接ノード密度の変化に対応することが可能である。

ソースノードはまた、視認性パラメータと状況情報問い合わせとを含む情報探査（プローブ）要求を送信することによってネットワークから情報を要求することが可能である。ソースノードからのこのような要求によって、要求された情報を、ソースノードからある距離内にあるすべてのノードに対して更新することが可能である。たとえば、ソースノード自身がその隣接ノード密度情報を更新する必要があると判定すると、そのソースノードは、隣接ノードに限定された分解能プロフィールを定義する視認性関数に応答する視認性パラメータを有する情報探査要求を送信することができる。

状況情報問い合わせは、ソースノードのアドレスおよび／または要求された情報の識別子を含むことができる。ノード（応答側ソースノード）は、状況情報問い合わせを含む情報のパケットを受信すると、情報のパケットを以前述べたように伝播させ、状況情報問い合わせに応答して要求情報を含み、また、たとえば、（応答側ソースノードによって用いられる視認性パラメータの代わりに）ソースノードによって発行された情報探査要求からの視認性パラメータのコピー、情報探査要求からの視認性パラメータの修正済みコピーまたは、ソースノードによって提供された視認性パラメータが対称的でない視認性関数を表していれば、ソースノードによって用いられる視認性関数の変換済みコピー（たとえば、１８０度回転されたコピーおよび／または応答側ソースノードの原点に変換されたコピーなど）を表す視認性パラメータを含む問い合わせ応答パケットを生成して、この問い合わせ応答（パケット）を送信する。ソースノードが状況情報問い合わせに対する応答を認識するように構成されているため、ソースノードは最終的に、問い合わせ応答を受信するものの伝播はさせない。応答側のノードの範囲内にある隣接ノードは、問い合わせ応答が状況情報問い合わせと同じ視認性パラメータを含んでいるため、その隣接ノードはソースノードからの情報探査要求を伝播させたような場合には、問い合わせ応答のみを伝播させるだけである。視認性関数をこのように用いると、状況情報問い合わせも問い合わせ応答もネットワーク環境全体にわたって伝播されることはないため、これまた通信キャパシティが節約される。

調整され、変換されたおよび／または回転された視認性パラメータを用いることにより、ソースノードは確実に、問い合わせ応答の伝播をなお制限しながらも、問い合わせ応答を受信することができる。

一部の実施形態では、状況情報を状況情報グループに編成しており、これにより、特定の状況情報グループ内のすべての状況情報を伝播させるべきであるかどうかの判断を、グループ中の各々の状況情報に対して実施するのではなく状況情報グループに対して一括して実施することが可能となるようにしている。複数の状況情報グループを１つの情報パケットに含めることが可能である。状況情報グループをどのように情報のパケットに組み込むか、再送信されるべきでない状況情報グループを情報のパケットからどのようにして除去するか、状況情報グループから状況情報をどのようにして分離してこれを配信させるかなどは当業者には理解されるであろう。１つ以上の状況情報グループを含む情報のパケットは集約パケットである。別の実施形態では、状況情報は、状況情報の視認性パラメータの共通点を発見しようとはまったく試みられずに、情報のパケット内に組み込まれる。これによって、各々の状況情報に対する個々のパケットではなく、より大きいパケットを送出することが可能となる。

図４に、集約パケットに含まれる状況情報を伝播させる集約アーキテクチャ４００を示す。情報は、「センサーの集合」４０１からおよび／またはネットワークから「入力集約パケット」４０３を介して受信することが可能である。センサーの情報は「状況情報集約器」４０５に流れ、ここで、視認性パラメータを各々別個のセンサー読み取り値（または、同じ視認性パラメータを有するセンサー読み取り値の各々のグループ）に適用し、センサー状況情報を状況情報グループに結集し、すると、これらグループは、ネットワーク環境に送信するための「出力集約パケット」４０７に結集させることができる。「状況情報集約器」４０５は、視認性割り当てロジックを含むことが可能である。

「入力集約パケット」４０３中の状況情報グループは、「状況情報分離器」４０９によって分離され、続く処理のために「アプリケーション集合」４１１に分配されることができる。状況情報グループ（または、一部の実施形態では完全な「入力集約パケット」４０３）は、「視認性フィルタ」４１３にもまた提供されることができ、ここで、「入力集約パケット」４０３中に含まれる各々の状況情報グループを検査し、「視認性有効パケット」判定手順３０７、「距離制限」判定手順３０９および「視認性有効パケット再送信」判定手順３１７に関連して図３で説明したものと実質的に同じように、この状況情報グループを処理する。視認性パラメータを有しない状況情報グループと、伝播し続けることになっている状況情報グループとは、次いで、「出力集約パケット」４０７に包含される。

当業者は、イベントパケットは「出力パケット」４０７とは無関係に送出することが可能であり、これにより、優先度の高い状況情報を迅速に分配することが可能となることを理解するであろう。当業者はまた、「出力集約パケット」４０７の送信は、周期的または半周期的に発生しうるものであり、また、開示されている技術に同等な「入力集約パケット」４０３中で受信される状況情報グループを伝播させるには多くの方法があることを理解するであろう。当業者はまた、視認性パラメータに共通点をまったく発見しようとすることなく状況情報をパケットに組み込む方法を理解するであろう。

さらに、当業者は、「入力集約パケット」４０３は、たとえば、互いに別個のソースノード、情報の同じコピーを送出するさまざまな経路を介する同じソースノード、さまざまなパケットを送出する同じソースノードなどからの複数の入力集約パケットを表すことが可能である。「視認性フィルタ」４１３はまた、分離化（de-multiplexed）された状況情報を別個に「状況情報集約器」４０５に提供するとともに、別の集約体内に含まれることになっている集約体を提供することが可能である。

図５に、本明細書に開示する技術で用いることができるプロトコルスタック５００を示す。プロトコルスタック５００の最上層には、ネットワーク環境上で伝送される状況情報を送信したりおよび／または受信した状況情報を処理したりするアプリケーションプロトコルレイヤー（層）５０１がある。アプリケーションプロトコルレイヤー５０１は、視認性プロトコルレイヤー５０３と通信する。視認性プロトコルレイヤー５０３は、アプリケーションプロトコルレイヤー５０１にとって、プロトコルスタック５００を用いるノードから発せられた状況情報に対して視認性関数を直接的または間接的に設定することができるインタフェースとなる。視認性プロトコルレイヤー５０３はまた、隣接ノード密度を測定またはこれにアクセスして、隣接ノード密度の変化に応じてゴシップカウントを調整することが可能である。これより低いレベルの通信プロトコルスタック５０５は、技術上周知のプロトコルレイヤーを含んでいる。

「状況情報集約器」４０５に流れたセンサー情報は、アプリケーションプロトコルレイヤー５０１によって直接的または間接的に指定された視認性パラメータを適用するために、視認性プロトコルレイヤー５０３によって処理されることができる。視認性プロトコルレイヤー５０３は、アプリケーションプロトコルレイヤー５０１に、情報ユーティリティ関数に応じて視認性関数を設定する機能を付与することができる。

図６に、開示されている技術の実施形態を組み込むことが可能なネットワークコンピュータシステム６００を示す。ネットワークコンピュータシステム６００は、ＣＰＵ６０３、メモリー６０５およびネットワークインタフェース６０７を組み込んだコンピュータ６０１を含んでいる。ネットワークインタフェース６０７は、コンピュータ６０１がネットワーク６０９にアクセス可能とする。コンピュータ６０１はまた、ユーザインタフェースデバイス６１３に接続可能なＩ／Ｏインタフェース６１１、記憶システム６１５およびリムーバブル（可搬）データデバイス６１７を含んでいる。リムーバブルデータデバイス６１７は、一般的にはプログラム製品６２１を含んでいるコンピュータで使用可能なデータキャリア６１９（たとえば、メモリースティック、ＣＤ、フロッピディスク、ＤＶＤまたは他のいずれかの有形のメディア中のデバイス内のＲＯＭや、交換可能など）を読み取ることが可能である。ユーザインタフェースデバイス６１３は、表示デバイス６２５を含むことができる。記憶システム６１５やコンピュータで使用可能なデータキャリア６１９はファイル記憶メカニズムを備えている。コンピュータで使用可能なデータキャリア６１９上のプログラム製品６２１は、一般的に、指定された動作を実行するようにＣＰＵ６０３に指示するプログラム６２３としてメモリー６０５に読み込まれる。くわえて、プログラム製品６２１は、ネットワーク６０９を用いてアクセスされるデバイスから提供されることもできる。ネットワークは情報を伝送することが理解されるであろう。プログラムとデータは、通例、有形の物理的メディアとネットワーク６０９の双方から読み込まれる。したがって、有形の物理的メディアと同様に、ネットワーク６０９はコンピュータで使用可能なデータキャリアである。ネットワークコンピュータシステム６００は、車両、ロボット、倉庫（ware house）や、状況情報を分配、分析および／または受信することが可能な他のいずれかの環境にインストールすることができる。

ユーティリティ関数Ｕは、アプリケーションと関連付けることが可能であり、Ｕ＝Ｕ（ｒ，ｖ）はソースからの距離ｒと情報が受信されるロケーションにおける視認性ｖの関数である。ｒに依存しているということは、受信された状況情報の値が状況情報のソースからの距離の関数であるという事実を反映しており、ｖに依存しているということは、分解能プロフィールが再構成の品質に影響する、したがって、再構成された情報の値に影響するという事実を反映している。ユーティリティはまた、どのアプリケーションがより高い「優先順位」を有するか、したがって、どのアプリケーションが利用可能なネットワークキャパシティをより多く用いることができるかについて仲裁（調停）する助けとして用いることができる。

視認性関数ｖ（ｒ）は、ネットワーク環境上での全体的なユーティリティを最大化するように設計することが可能である。全体的なユーティリティとは、各々の距離ｒの点における情報ユーティリティ（有用性）をネットワーク環境全体にわたって積分したものである。アプリケーション開発者は各々が、アプリケーションが用いる状況情報の値が分解能によってどのように変化するかを決定することができる。アプリケーションの値と状況情報の値とに基づいて、アプリケーション開発者は、その特定のアプリケーションに対する状況情報の値を最大化するような情報ユーティリティ関数を決定すること（および、たとえば、隣接ノード密度を組み込むこと）が可能である。

複数のアプリケーションのそれぞれが、それぞれのアプリケーションによって用いられる状況情報に値を割り当てるために用いられる自分自身の情報ユーティリティ関数を有することができるよ。たとえば、道路の特定の一部が滑りやすいという知識に対して割り当てることができるユーティリティ値が存在する。このユーティリティ値は、たとえば、横滑りによる事故の経費、滑りやすい場所に近づいたら交通量が落ち込むことを知っていることによる利益、道路状態のために配送が遅延することを知っていることによる利益および滑りやすい場所を避けて迂回できうることによる利益を考慮することによって決定することが可能である。

道路上を走行する車両からのセンサー情報は、温度、高度および湿度などの環境データと、位置、速度および方向などの車両状態情報と、道路が滑りやすいことを示しうるイベントデータとを含むことができる。

このようなイベントデータを含んでいる更新パケットの数を考慮することによって推論することが可能である。道路の特定の部分から（たとえば、複数の車両から）発せられた上記のイベントデータを含んでいる更新パケットが多く存在する場合、その道路はその特定の場所で滑りやすくなっている確率（可能性）が高い。このようなイベントを含んでいる更新パケットの数が少なければ、道路が滑りやすくなっている確率は低い（すべる原因は、車両状態データを評価することによって決定することが可能である）。特定のロケーションから受信された更新パケットの数は推論の正しさの確率を決定する助けとなるため、更新パケットに含まれる状況情報から推論する場合には、視認性関数の分解能プロフィールの効果を考慮すべきである。くわえて、一部のノードではイベント情報を平均化し、平均化された情報を伝播させることが可能である。平均化された情報はしばしばユーティリティが高く、したがって、このユーティリティを用いて、平均化された情報に対する視認性関数を案出することが可能である。平均化することと別の視認性関数を用いることを組み合わせることによって、しばしば、ネットワーク付加が軽減され、受信された情報の全体的なユーティリティが増加する。

関数Ｕはまた、アプリケーションプロトコルレイヤー５０１中のアプリケーションから視認性プロトコルレイヤー５０３に提供されることができ、これを用いて、このアプリケーションによって取り扱われる状況情報に対する視認性関数を指定または選択することが可能できる。Ｕは記述しやすく、また、アプリケーション／視認性関数の双方の側における適切な数量は関連しているため、視認性関数をユーティリティと情報の損失などの数量と分析的に関連付けることが可能である。したがって、視認性レイヤー５０３は、アプリケーションプロトコルレイヤー５０１から視認性パラメータを受信して、対応する視認性関数を決定する視認性決定ロジックを含むことが可能である。この視認性関数は、最適な（全体的なユーティリティを最大化する）Ｕが１つのロケーションから別のロケーションに視認性が少量だけ移動しても影響されないように構成することが可能である。すなわち、マージナル（境界的）・ユーティリティは分解能プロフィール上で不変のままとどまる。

マージナル・ユーティリティを用いて、アプリケーション同士間に帯域幅を割り当てることもできる。すなわち、リソースの割り当ては、各々のアプリケーションのマージナル・ユーティリティが自分以外のアプリケーションのマージナル・ユーティリティと等しくなる傾向を持つように遂行される。したがって、この帯域幅は、これらアプリケーションのマージナル・ユーティリティが互いに等しくなるに調整することが可能である。次いで、アプリケーションの個々のユーティリティ（このアプリケーションの視認性関数から誘導される）が、このアプリケーションのマージナル・ユーティリティが視認性関数によって定められる分解能プロフィールの領域上で一定であるように調整される。

図７に、リセット信号の電力が印加されるとそれに反応して開始ターミナル７０１で開始されるソースノードに対する動的帯域幅割り当てプロセス７００を示す。この動的帯域幅割り当てプロセス７００は「初期化」手順７０３に進み、必要とされる何らかの電源投入またはリセット初期化が実行される。

次に、オプションとして「隣接ノード密度決定」手順７０７が直接隣接密度を決定し、隣接ノード密度がユーティリティに影響するようであれば、各々のアプリケーションの情報ユーティリティ関数に対応する視認性関数を隣接ノード密度に対して調整することができる。いったん隣接ノード密度が決定されると、「最大安全帯域幅決定」手順７０９が、隣接ノード密度と、ソースノードが使用可能なネットワーク設備とに照らしてソースノードにとって利用可能な最大安全帯域幅を決定する。次に、アプリケーション毎の反復手順７１１は、上記の利用可能帯域幅を用いることが可能なソースノードにおいて関連するアプリケーションのすべてに対して反復する。各々の関連アプリケーションに対して反復される間に、「アプリケーション帯域幅決定・分類要件」手順７１３が、アプリケーションを分類してその帯域幅要件を決定する。この分類には、アプリケーションがその視認性関数を決定する情報ユーティリティ関数を用いるかどうかが含まれる。

関連するアプリケーションがすべて反復されたら、「非ユーティリティ意識（使用）アプリケーション帯域幅割り当て」手順７１５が、利用可能な帯域幅のある部分をユーティリティベースのアプリケーションが使用するように確保し、残りの帯域幅を非ユーティリティベースのアプリケーションに割り当てる。

次に、「ユーティリティ最適化」手順７１７は、情報ユーティリティ関数の各々のユーティリティを最適化し、同時にまた、隣接ノード密度に照らしてソースノードの最適ユーティリティを達成するために、すべての情報ユーティリティ関数のユーティリティを最適化する。この最適化を達成するために適用可能な最適化技術が多く考えられることが理解されよう。いったん最適化されたユーティリティが決定されると、「ユーティリティ最適化」手順７１７はまた、各々のアプリケーションの最適化された情報ユーティリティ関数に応じて視認性関数および／または視認性パラメータを設定する。視認性関数が設定されると、動的帯域幅割り当てプロセス７００は「隣接ノード密度決定」手順７０７に復帰して、必要であれば、隣接ノード密度の変化に合わせて調整を実施する。

「ユーティリティ最適化」手順７１７は、たとえば、政府の規制によって設定されたユーティリティ値を車両の所有者、運転者またはこれらのなんらかの組み合わせによって用いることによってユーティリティ意識アプリケーションのマージナル・ユーティリティを最適化することが可能である。

本書で用いられる手順とは、プログラミングされたコンピュータ、用途特化された電子系または他の回路もしくは所望の結果をもたらすこれらの組み合わせによって実現されるロジックによって実行可能なステップからなる首尾一貫したシーケンスのことである。

ネットワークは、情報（たとえば、情報のデータやコンピュータプログラムを定義するようなデータ）を伝送することが理解されるであろう。この情報はまた、搬送波（carrier-wave）内で実現することも可能である。「搬送波」という用語は、電磁信号、可視もしくは不可視光線パルス、データバス上の信号、有線、無線もしくは情報をネットワークを介して送信することを可能とする光ファイバの技術のいずれかによりで送信される信号を含む。プログラムとデータは、通例、有形の物理的媒体（たとえば、コンパクトディスク、フロッピディスクまたは磁気ディスク）とネットワークの双方から読み込まれる。したがって、有形の物理的媒体と同様に、ネットワークはコンピュータが使用可能なデータキャリアである。

「可変分解能」という用語は、上述した距離によって異なる分解能特徴と本書で明示的もしくは暗示的に解説した特長さらに本書に開示するところに照らし合わせれば明瞭となるような特徴のすべてに適用されることを意図するものである。

上記から、本技術は（無制限に）次の長所を有することが理解されるであろう。
・ この技術によってユーザ（および／またはアプリケーション）は、潜在的な受信者ノードに対するグローバルな制約を表現して指定し、また、潜在的な受信者ノードの集合同士間の相対的な配信確率を指定することが可能となる。
・ アプリケーションは、潜在的な受信者ノードを、既存のマルチキャストパラダイムとは異なって、それぞれ別々に取り扱うことが可能である。
・ マルチキャスト情報普及において更なる（追加的な）次元の制御が可能となる。このさらなる次元の制御は無線アドホックネットワーク上でアプリケーションを開発する際に有用である。ＶＲＩＤによって、ＶＲＩＤサービスに対してたった１回コール（要求）するだけで、たとえば、近隣のノードに対して、より高い分解能で（たとえば、粒状度、精度および／または他の分解能特徴という点で）状況情報を遠隔のノードに対しては低い分解能で配信することが可能である。
・ 受信された集約済のデータと共にセンサー情報を集約するための、良好に動作するセンサー（検知）環境を実現し、これによって使用される帯域幅を最小とする。

ネットワーク環境と、分解能プロフィールが円形である場合の視認性関数に起因する分解能プロフィールとを示す図である。 ネットワーク環境と、分解能プロフィールが楕円形である場合の視認性関数に起因する分解能プロフィールとを示す図である。 視認性関数を利用したデバイスの動作を示す図である。 一実施形態による集約アーキテクチャを示す図である。 視認性層のロケーションを示すプロトコルスタックを示す図である。 好ましい実施形態によるネットワークコンピュータシステムを示す図である。 ダイナミック帯域幅割り当てプロセスを示す図である。

Claims (2)

1. ネットワーク環境（１００；２００）の少なくとも１つのソースノード（１０３）から前記ネットワーク環境（１００；２００）の少なくとも１つの受信ノード（１０７）に状況情報を伝播する方法であって、
   前記ネットワーク環境（１００；２００）の少なくとも１部にわたる不均一な分解能プロフィール（１０９；２０９）を定義する前記ネットワーク環境（１００；２００）における視認性関数を提供することであって、前記分解能プロフィール（１０９；２０９）は、前記受信ノード（１０７）での情報の分解能を示し、前記情報の分解能は、前記情報の詳細な量、精度、及び適時性の少なくとも１つによって与えられる、当該提供することと、
   前記視認性関数に従った分解能で前記状況情報を伝播すること、
   を含む方法。
2. 前記状況情報は他のノード（１０５）から受信ノード（１０７）で受信されることを特徴とする請求項１に記載の方法。

Images