(57)【要約】車両作動データを、車両から遠隔モニタリングを行う受信側に送信する方法が開示され、この方法は、車両と遠隔モニタリングを行う受信側との間のデータリンクを確立し、車両におけるデータ源から車両の作動データを収集し、　ＳＮＭＰから導かれるプロトコルを用いて、データパケット内の車両の作動データをパッケージングし、前記データリンク上で前記データパケットを送信する、各ステップを有する。
2004511188.tif 000002
【特許請求の範囲】
【請求項１】
車両作動データを、車両から遠隔モニタリングを行う受信側に送信する方法であって、
車両と遠隔モニタリングを行う受信側との間のデータリンクを確立し、
車両におけるデータ源から車両の作動データを収集し、
ＳＮＭＰから導かれるプロトコルを用いて、データパケット内の車両の作動データをパッケージングし、
前記データリンク上で前記データパケットを送信する、各ステップを含むことを特徴とする方法。
【請求項２】
車両作動データを、車両のサーバー側から遠隔モニタリングを行う顧客に送信する方法であって、
車両と遠隔モニタリングを行う顧客との間のデータリンクを確立し、
車両サーバ内のデータ源から車両動作データを収集し、
２バイトのオブジェクト識別子フィールド、１バイトのバリュータイプフィールド、及びこのバリュータイプフィールドに従う可変バインディングのサイズ値を有する複数の可変バインディングフィールドを含んでいる、プロトコルデータユニットのペイロードを有するプロトコルデータユニット内に前記車両動作データをパッケージし、
前記プロトコルデータユニットをデータリンク上に送信する、各ステップを有することを特徴とする方法。
【請求項３】
車両から最新の送信状態に対する車両の作動データを、遠隔モニタリングを行う受信側に、前記最新の送信状態に対するバンド幅の要求を最小化するように収集する方法であって、
車載用計算装置を用意し、
一組の管理オブジェクトの現在値に対応する、前記車両の１つまたは複数の作動特性を各々測定するために複数のデータ収集モジュールを用意し、
前記車両の車載用計算装置を前記データ収集モジュールの各々に接続し、
（ａ）　前記対応するデータ収集モジュールの各々から前記管理オブジェクトの各々に対する値を受信しかつ記憶するための診断情報基準を形成し、
（ｂ）　前記診断情報基準に包含される情報に基づいた１つの事象レポートを集め、
（ｃ）　ＳＮＭＰによるプロトコルに従ってプロトコルデータユニット内の前記事象レポートをパッケージするように、前記車載用計算装置を設定する、各ステップを有することを特徴とする方法。
【請求項４】
車両の作動特性は、ＧＰＳ位置、エンジン速度、車両速度、又はエンジン温度、あるいは、車両のエミッションに関係するＯＢＤ−ＩＩパラメータを含んでいることを特徴とする請求項３記載の方法。
【請求項５】
ＯＢＤ−ＩＩパラメータは、不点火検出を含んでいることを特徴とする請求項４記載の方法。
【請求項６】
（ａ）　遠隔モニタリングを行う受信者側とのデータリンクを確立し、
（ｂ）　データリンク上でプロトコルデータユニットを送信するために、車載用計算装置を作動させるステップをさらに含んでいることを特徴とする請求項３記載の方法。
【請求項７】
車載用計算装置から特定組の管理オブジェクトに対する現在値を読み出すために、ＧＥＴプロトコルデータユニットを出力して遠隔モニタリングを行う受信側を起動させるステップをさらに含んでいることを特徴とする請求項６記載の方法。
【請求項８】
車載用計算装置によってＧＥＴプロトコルデータユニットへの受信通知を待つように、遠隔モニタリングを行う受信側を起動させるステップをさらに含んでいることを特徴とする請求項７記載の方法。
【請求項９】
ＴＲＡＰプロトコルデータユニットを出力して車両の事象を報告するために、車載用計算装置を起動させるステップをさらに含んでいることを特徴とする請求項６記載の方法。
【請求項１０】
（ａ）　各車両の事象に対する閾値または報告間隔を記憶し、
（ｂ）　閾値が対応する報告間隔にあるかまたはそれを超える状態のとき、各ＴＲＡＰを出力するために、
前記車載用計算装置を起動させるステップをさらに含んでいることを特徴とする請求項９記載の方法。
【請求項１１】
ＴＲＡＰプロトコルデータユニットは、ＧＳＰ位置を知らせることを特徴とする請求項１１記載の方法。
【請求項１２】
例外的な車両の事象を知らせるために、車両からのインフォーム（ＩＮＦＯＲＭ）プロトコルデータユニットを出力するステップをさらに含んでいることを特徴とする請求項６記載の方法。
【請求項１３】
（ａ）　１つまたは複数の規定に関する例外、メンテナンスに関する例外、または動作に関する例外を含む、診断情報基準における複数の特定の例外的車両事象のいずれか１つを記憶し、
（ｂ）　前記いずれか１つの特定事象が起こった時にインフォーム・プロトコルデータユニットを出力するように、
前記車載用計算装置を起動させるステップをさらに含んでいることを特徴とする請求項１２記載の方法。
【請求項１４】
規定の閾値レベルが越えている結果として、前記インフォームプロトコルデータユニットが出力されることを含んでいることを特徴とする請求項１３記載の方法。
【請求項１５】
以前のインフォーム・プロトコルデータユニットが、遠隔モニタリングを行う受信側によってデータベースに記録されたことを確認した後に、前記車載用計算装置を起動させるステップをさらに含んでいることを特徴とする請求項１３記載の方法。
【請求項１６】
以前のインフォーム・プロトコルデータユニットが、遠隔モニタリングを行う受信側によってデータベースに記録されたことを確認しないで、前記インフォーム・プロトコルデータユニットを再送信するステップをさらに含んでいることを特徴とする請求項１５記載の方法。
【請求項１７】
１つまたは複数の管理オブジェクトを設定するために、前記車載用計算装置にＳＥＴプロトコルデータユニットを出力するように、遠隔モニタリングを行う受信側を起動させることをさらに含んでいることを特徴とする請求項６記載の方法。
【請求項１８】
データリンクは、ワイヤレスであり、かつＩＥＥＥ８０２．１１基準、サテライトＲＦパケットネットワーク又は地球規模のＲＦパケットネットワークに基づく無線周波数帯域を含んでいることを特徴とする請求項６記載の方法。
【請求項１９】
プロトコルデータユニットは、リクエスト・プロトコルデータユニットであり、このデータユニットは、ＳＮＭＰプロトコルのエラーステータスおよびエラーインデックスフィールドを排除することを特徴とする請求項６記載の方法。
【請求項２０】
プロトコルデータユニットは、ＳＮＭＰプロトコルの可変バインディングの各々の長さフィールドを排除することを特徴とする請求項６記載の方法。
【請求項２１】
車両作動データを、車両から遠隔モニタリングを行う受信側に送信する方法であって、
車両と前記受信側との間のデータリンクを確立し、
車両におけるデータ源から車両作動データを収集し、
ＳＮＭＰから導かれるプロトコルを用いてデータパケット内の車両作動データをパッケージし、
前記データリンク上に前記データパケットを送信する、各ステップを有し、
前記プロトコルデータユニットは、遠隔モニタリングを行う受信側による要求に応答して出力され、さらに、前記プロトコルデータユニットは、前記要求及び要求された要求値の両方を含み、かつ単一のメッセージ及びフラグメント化されない単一のネットワークパケット内に封入されていることを特徴とする方法。
【請求項２２】
車両からの最新の送信状態に対する車両作動データを、遠隔モニタリングを行う受信側に、前記最新の送信状態に対するバンド幅の要求を最小化するように収集する方法であって、
車両の車載用計算装置を用意し、
前記車両の管理オブジェクトの現在値をそれぞれ記録するために、複数のデータ収集モジュールを用意し、
前記車両の車載用計算装置を前記データ収集モジュールの各々に接続し、
（ａ）　前記データ収集モジュールの各々から前記管理オブジェクトの各々に対する値を受信しかつ記憶するための診断情報基準を形成し、
（ｂ）　前記診断情報基準に包含される情報に基づいた１つの事象レポートを集め、
（ｃ）　プロトコルデータユニット内の前記事象レポートをパッケージするように、前記車載用計算装置を設定する、各ステップを有し、
前記プロトコルデータユニットは、複数の可変バインディングフィールドを有するプロトコルデータユニット・ペイロードを含み、前記可変バインディングフィールドは、それぞれ２バイトのオブジェクト識別子フィールド、１バイトのバリュータイプフィールド、及びこのバリュータイプフィールドに従う可変バインディングのサイズ値を有する複数の可変バインディングフィールドを含んでいることを特徴とする方法。
【請求項２３】
プロトコルデータユニットは、一組の値の一方に対応する値とともにＰＤＵタイプのデータ要素を有するヘッダーを含み、前記一組の値は、ＧＥＴ値、ＳＥＴ値、ＴＲＡＰ値、インフォーム値、及びレスポンス値を含んでいることを特徴とする請求項２２記載の方法。
【請求項２４】
車両作動データを、車両から遠隔モニタリングを行う受信側に送信するためのコンピュータ実行システムであって、
車両における複数の車両作動データ源と接続される車両の車載用計算装置と、
ワイヤレスデータリンクを車載用計算装置及び遠隔モニタリングの受信側と共に確立するためのワイヤレス通信装置とを含み、
前記車両の車載用計算装置は、ＳＮＭＰから導かれるプロトコルを用いて、ワイヤレスデータリンク上で遠隔モニタリングの受信側に伝送するために、データパケット内の車両作動データをパッケージできるようになっていることを特徴とするシステム。
【請求項２５】
車両作動データを、車両から遠隔モニタリングを行う受信側に収集しかつ送信するための、コンピュータで読取可能なデータ構造であって、
車両における複数のデータ源から車両作動データを受信するためのアプリケーションモジュールと、
診断情報基準、複数の車両作動パラメータ用の多数の管理オブジェクト、およびこれらの管理オブジェクトの各々に対する多数の値を記憶するための記憶モジュールと、
ワイヤレスデータリンク上のＳＮＭＰから導かれるプロトコルの下で、プロトコルデータユニットを、遠隔モニタリングを行う受信側に送信するための通信モジュールとを含んでいることを特徴とするデータ構造。
【請求項２６】
コンピュータで読取可能な媒体にエンコードされたコンピュータプログラム製品であって、
車両作動データを車両から遠隔モニタリングを行う受信側に収集しかつ送信するために、車載用コンピュータのためのコンピュータで実行可能な複数のステップを含んでおり、
車両における複数のデータ源から車両作動データを受信し、
診断情報基準、複数の車両作動パラメータ用の多数の管理オブジェクト、およびこれらの管理オブジェクトの各々に対する多数の値を記憶し、
前記コンピュータと前記受信側との間でワイヤレスデータリンクを確立し、
ワイヤレスデータリング上のＳＮＭＰから導かれるプロトコルの下で、複数のプロトコルデータユニットを前記遠隔モニタリングを行う受信側に送信する、各ステップを含んでいることを特徴とするコンピュータプログラム製品。
【請求項２７】
キャリア媒体上に伝搬される信号であって、この信号は、ＳＮＭＰから導かれるプロトコルに従う、自動車の予め決められた作動データをエンコードするペイロードを含むパッケージされたプロトコルデータユニットを含んでいることを特徴とする信号。
【請求項２８】
ペイロードは、複数の可変バインディングフィールドを含み、該可変バインディングフィールドの各々は、それぞれ２バイトのオブジェクト識別子フィールド、１バイトのバリュータイプフィールド、及びこのバリュータイプフィールドのデータユニットに従う可変バインディングのサイズ値を有する複数の可変バインディングフィールドを含んでいることを特徴とする請求項２７記載の信号。
【請求項２９】
ペイロードは、ＧＳＰ位置セグメント、ＧＳＰヘッディングセグメント、車両速度セグメント、またはＯＢＤＩＩの車両エミッション・セグメントを含んでいることを特徴とする請求項２７記載の信号。
【請求項３０】
車両作動データを、車両から遠隔モニタリングを行う受信側に送信するシステムであって、
車両における複数の車両作動データ源に接続される車両の車載用計算手段と、
ワイヤレスデータリンクを車載用計算装置及び遠隔モニタリングの受信側と共に確立するためのワイヤレス通信手段とを含み、
前記車両の車載用計算手段は、ＳＮＭＰから導かれるプロトコルを用いて、ワイヤレスデータリンク上で遠隔モニタリングの受信側に伝送するために、データパケット内の車両作動データをパッケージできるようになっていることを特徴とするシステム。
【請求項３１】
車両作動データを、車両から遠隔モニタリングを行う受信側に送信する方法であって、
前記車両と前記受信側との間のデータリンクを確立するための段階と、
前記車両におけるデータ源から車両作動データを収集するための段階と、
ＳＮＭＰから導かれるプロトコルを用いて、データパケット内の車両作動データをパッケージするための段階とを含むことを特徴とする方法。
【請求項３２】
複数の車両間のでデータを交換するための通信ネットワークであって、
対応する車両に搭載される計算ユニットを含み、所定車両に設けた前記計算ユニットが識別メッセージを放送し、かつ隣接する領域にある他の車両から等価な識別メッセージを受け取ることが可能であり、前記メッセージは、ネットワーク内の近くにいる車両を識別するために使用され、そこで、選択された１つの車両とデータを交換することを特徴とする通信ネットワーク。
【請求項３３】
計算ユニットは、近くにいる車両のリストを更新するように作動し、かつ、ＧＳＰ情報における固有のエラーが、全てのネットワークのノード間で一定であり、近くにいる車両の地理上の位置が絶対位置の代わりに相対関係によって確立できることを特徴とする請求項３２記載のネットワーク。
【請求項３４】
計算ユニットは、識別メッセージがその領域に入る新しい車両から受信されるときに、近くにいる新しい車両をリストに付加することを特徴とする請求項３３記載のネットワーク。
【請求項３５】
計算ユニットは、所定の時間経過後、識別メッセージが、特定の近くにいる車両から受信されなかったとき、特定の近くにいる車両をリストから削除することを特徴とする請求項３４記載のネットワーク。
【請求項３６】
計算ユニットは、近くにいる車両が隣接する領域から立ち去ったかまたは残っているかを示す識別メッセージが、特定の近くの車両から受信したとき、この近くにある車両のデータベースからこの車両を削除することを特徴とする請求項３５記載のネットワーク。
【請求項３７】
通信の媒体は、チャネル化されたＲＦ帯域の高周波であり、各計算ユニットによってこの高周波が用いられ、ＩＥＥＥ８０２．１１媒体アクセス制御（ＭＡＣ）プロトコルに従って制御されることを特徴とする請求項３３記載のネットワーク。
【請求項３８】
計算ユニットは、インターネットによりアドレス可能であることを特徴とする請求項３３記載のネットワーク。
【請求項３９】
計算ユニットは、ＩＰｖ６によりアドレス可能であることを特徴とする請求項３３記載のネットワーク。
【請求項４０】
計算ユニットは、ＳＮＭＰから導かれたプロトコルを用いてデータを交換することを特徴とする請求項３３記載のネットワーク。
【請求項４１】
識別メッセージは、送り手のＧＳＰ情報とＩＥＥＥ８０２．１１媒体アクセス制御（ＭＡＣ）アドレスを含んでいることを特徴とする請求項３３記載のネットワーク。
【請求項４２】
ＧＳＰ情報は、緯度、経度、速度及び機首方位の情報を含んでいることを特徴とする請求項４０記載のネットワーク。
【請求項４３】
近くにいる全ての車両は、特定の車両を近くの車両として認識できるために十分な、発見に必要な時間内で識別メッセージを送信することを特徴とする請求項４２記載のネットワーク。
【請求項４４】
少なくともいくつかのメッセージを伝送するためのチャネル選択は、ＧＳＰの機首方位に基づいていることを特徴とする請求項４３記載のネットワーク。
【請求項４５】
発見に必要な時間の長さ及び領域の地理的大きさの両方が、近くにいる車両の平均速度に比例して調整されることを特徴とする請求項４４記載のネットワーク。
【請求項４６】
計算ユニットの各々は、さらに、ＳＮＭＰプロトコルの下でメッセージを送信しかつ受信することができる、送信器及び受信器を含んでいることを特徴とする請求項４３記載のネットワーク。
【請求項４７】
請求項３２記載の構成を有する自動車。
【請求項４８】
速度セグメント、機首方位セグメント、及び位置セグメントを含んでいることを特徴とするデータ構造。
【請求項４９】
位置セグメントは、経度部分と緯度部分を含むことを特徴とする請求項４８記載のデータ構造。
【請求項５０】
キャリア媒体上に伝播される信号であって、この信号は、速度セグメント、機首方位セグメント、及び位置セグメントを含んでいることを特徴とする信号。
【請求項５１】
位置セグメントは、経度部分と緯度部分を含むことを特徴とする請求項５０記載の信号。
【請求項５２】
車載用計算ユニットは、リストされた車両の選択された車両とデータを交換するための隣接地区のリストを集めるために、隣接領域にある他の車両からのメッセージを受信するように作動可能であることを特徴とする車両。
【請求項５３】
モータビークル上でプログラム可能なコンピュータシステムを作動させるためのコンピュータプログラム製品であって、
隣接領域内の他の車両からのメッセージを受信し、リストされた車両の選択された車両とデータを交換するための隣接地区のリストを集める、コンピュータ実行ステップを含むコンピュータの読取可能媒体を含んでいることを特徴とするコンピュータプログラム製品。
【請求項５４】
車載用コンピュータと広帯域無線を含むモータビークルであって、前記広帯域無線は、近くにいる少なくとも１つの他の車両の無線とデータリンクを確立し、コンピュータが、隣接地区のリストを集めるために隣接領域にいる前記少なくとも１つの他の車両からのメッセージを記録し、さらに、前記データリンク上で受信したデータから少なくとも１つの車両の事象を識別するように作動可能であることを特徴とするモータビークル。
【請求項５５】
車載用計算装置及び遠隔モニタリングを行う受信側からのデータを収集しかつ送信するためのコンピュータ読取可能なデータ構造であって、
車載用計算装置及び遠隔モニタリングを行う受信側の間のデータ交換のために、役立つプロトコル値、対応する要求および応答をインデックスするためのモジュールと、
車両における複数の作動特性に対する一連の管理オブジェクトをインデックスするためのモジュールと、
管理オブジェクトの各々に対する値を記録するためのモジュールと、を含んでいる特徴とするデータ構造。
【請求項５６】
遠隔モニタリングを行う各受信側に対する識別をインデックスするためのモジュールをさらに含んでいることを特徴とする請求項５５記載のデータ構造。
【請求項５７】
遠隔モニタリングを行う各受信側に対する１つまたは複数の管理オブジェクトの状態リストをインデックスするためのモジュールをさらに含んでいることを特徴とする請求項５６記載のデータ構造。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
関連出願の参照
１９９７年８月２６日に出願された米国仮出願番号６０／０５６，３８８ 及び１９９８年８月２６日に出願された特許出願番号０９／１４０，７５９（両方の出願の発明の名称は、「自動車の自動遠隔測定を与えるためのシステム及び方法」である。）における主題は、参考として本明細書に含まれる。発明の名称が「通信システム」と名付けられた１９９８年１０月２３日に出願されかつ米国を指定国とした国際特許出願ＰＣＴ／ＣＡ９８／００９８６ の主題も参考として本明細書に含まれる。また、発明の名称が「車両用遠隔測定」と名付けられた１９９９年６月１７日に出願された米国仮出願番号６０／１３９，５７３ の主題も参考として本明細書に含まれる。また、発明の名称が「車両用計算装置」と名付けられた１９９９年８月１１日に出願された米国仮出願番号６０／１４８，２７０ の主題もまた参考として本明細書に含まれる。また、発明の名称が「車両用遠隔測定」と名付けられた２０００年３月６日に出願された米国仮出願番号６０／１８７，０２２ の主題もまた参考として本明細書に含まれる。また、発明の名称が「車両用遠隔測定」と名付けられた２０００年４月２４日に出願された米国出願番号０９／５５６，２８９ の主題もまた参考として本明細書に含まれる。さらに、発明の名称が「車両用遠隔測定」と名付けられた２０００年６月１９日に出願されかつ米国を指定国とした国際特許出願ＰＣＴ／ＣＡ００／００７１２ の主題も参考として本明細書に含まれる。
【０００２】
発明の名称が「ＡＤ ＨＯＣ ネットワーキングを用いるインテリジェント輸送システム」名付けられた２０００年１０月１３日に出願された米国仮出願番号６０／２３９，９２０ の主題もまた参考として本明細書に含まれる。また、発明の名称が「ＡＤ ＨＯＣ ネットワーキングを用いるインテリジェント輸送システム」と名付けられた２０００年１１月２７日に出願された米国仮出願番号６０／２５２，８８５ の主題もまた参考として本明細書に含まれる。さらに、発明の名称が「ＡＤ ＨＯＣ ネットワーキングを用いるインテリジェント輸送システム」と名付けられた２０００年１２月１８日に出願された米国仮出願番号６０／２５５，８９６ の主題もまた参考として本明細書に含まれる。
【０００３】
本発明の背景
１．　技術分野
本発明は、インテリジェント輸送システムにおける自動車の遠隔測定プロトコル及びそれらの使用に関する。
【０００４】
【従来の技術】
２．　関連技術の記述
通常、車両は、ハードワイヤ又は赤外線によるデータリンク上、または、低電力型のトランスポンダを用いてデータリンクによって（電子高速道路使用料［ｅｌｅｃｔｒｏｎｉｃ ｔｏｌｌ ｈｉｇｈｗａｙ］等の）調整コンピュータシステムでの診断用コンピュータシステム（補修ガレージ内での）を用いてデータの交換を行うことが知られている。
【０００５】
商業車のためのより洗練された車両遠隔測定は、最近の数年間で、地球上及び人工衛星を用いるＲＦパケットネットワークを介して行うことができるようになってきた。この車両の遠隔測定システムにおいて、車両センサによるデータ無線データリンク上でコンピュータに送信することができ、コンピュータは、自動車の現状を監視しかつ記録し、さらに、例えば、車両が特定のサービスベイにある必要なしに車両のメンテナンス用のデータベースシステムを支えるようにプログラムされる。しかし、これらのシステムは、作動させるのに比較的高価である。
【０００６】
車両のために道路輸送システムの品質及び効率を改善する目的で電子掲示板及び他の新制度を介して交通状態を前進させるように運転者に警告するために、かなり多くのリサーチが、高速インフラストラクチュア（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を管理し、交通信号を同期させ、交通量を測定するためのコンピュータ制御の方法である、発展可能なインテリジェント車両高速システム（ＩＶＨＳ）に向けられている。
【０００７】
カリフォルニア・エア・リソーシズ　ボード（ＣＡＲＢ）は、車両エミッションを監視するための基準を確立する先導を担ってきた。最近のＣＡＲＢの先導は、ＯＢＤ−ＩＩＩとして知られており、車載用の診断要求の第３段階である。車両からの遠隔診断データを読み出すために、１つのエミッション規制エージェントを必要とする。それゆえ、クリーンなエア検出ステーションを出向する必要を避けることができる。１つのパイロットプログラムにおいて、低出力トランスポンダが各車両で使用され、車両と道路側の受信者との間でデータを送信することができる。
【０００８】
もちろん、前進するように提案されたＯＢＤ−ＩＩＩのために、各車両は、トランスポンダを介して要求されたデータを収集しかつ処理できるシステムを備えなければならない。ＣＡＲＢは、現在有効な再調査可能な技術であり、将来の要求がどのようなものになるかを見るために電気通信産業を調査中である。ＣＡＲＢによってこれまで試験された作動プラットフォームは、比較的厄介なものであり、将来必要な他のデータ交換のために用いるには限界がある。このため、この提案を実行する消費者にかかる財政的な負担を最小限にするために、経済的に動作するようなプラットフォームを見出すことに関心がおかれている。
【０００９】
さらに、クリーンなエア媒体に対する診断情報を送ることができるような選択されたプラットフォームが望ましい。遠距離通信及び自動車産業の分野では、都市の通勤者が彼らの車で毎日数時間をかけて往復する間に、ビジネスの機会を利用できるような方法について検討中である。
【００１０】
車両交通は、都市計画者にとって重要な問題になってきた。土地の価値が急上昇し、土地の有効利用が緊急の関心事になっていることから、都市計画者は、通勤者の幹線道路を選択できるようにして、車両をより使用できる方法を捜している。また、交通が混雑するとき、道路の重み付けを行って交通量を整理することが知られている。それゆえ、衝突を避けるために安全運転距離等を制御する方法として車両間でデータを交換し、かつ運転速度等を制御するために交通監視システムを用いてデータを交換できるような車両を有することが望ましい。
【００１１】
【発明が解決しようとする課題】
それゆえ、本発明の目的は、車両の遠隔測定用の改良されたプラットフォームを提供することである。
【００１２】
本発明の更なる目的は、比較的安価で、車両と固定局との間のデータ通信システムを介して有効なデータを交換できる改良された車両の遠隔測定システムを提供することである。
【００１３】
本発明の更なる目的は、車両が、データ通信システムを介してかつこれらを用いて各々通信できる車両通信システムを提供することである。
発明の要約
【００１４】
【課題を解決するための手段】
本発明の１つの構成によれば、本発明は、車両作動データを、車両から遠隔モニタリングを行う受信側に送信する方法を提供し、この方法は、
車両と遠隔モニタリングを行う受信側との間のデータリンクを確立し、
車両におけるデータ源から車両の作動データを収集し、
ＳＮＭＰから導かれるプロトコルを用いて、データパケット内の車両の作動データをパッケージングし、
前記データリンク上で前記データパケットを送信する、各ステップを含んでいる。
【００１５】
本発明の別の構成によれば、本発明は、車両作動データを、車両のサーバー側から遠隔モニタリングを行う顧客に送信する方法を提供し、この方法は、
車両と遠隔モニタリングを行う顧客との間のデータリンクを確立し、
車両サーバ内のデータ源から車両動作データを収集し、
２バイトのオブジェクト識別子フィールド、１バイトのバリュータイプフィールド、及びこのバリュータイプフィールドに従う可変バインディングのサイズ値を有する複数の可変バインディングフィールドを含んでいる、プロトコルデータユニットのペイロードを有するプロトコルデータユニット内に前記車両動作データをパッケージし、
前記プロトコルデータユニットをデータリンク上に送信する、各ステップを含んでいる。
【００１６】
さらに、本発明の別の構成によれば、本発明は、車両から最新の送信状態に対する車両の作動データを、遠隔モニタリングを行う受信側に、前記最新の送信状態に対するバンド幅の要求を最小化するように収集する方法を提供し、この方法は、
車載用計算装置を用意し、
一組の管理オブジェクトの現在値に対応する、前記車両の１つまたは複数の作動特性を各々測定するために複数のデータ収集モジュールを用意し、
前記車両の車載用計算装置を前記データ収集モジュールの各々に接続し、
（ａ）　前記対応するデータ収集モジュールの各々から前記管理オブジェクトの各々に対する値を受信しかつ記憶するための診断情報基準を形成し、
（ｂ）　前記診断情報基準に包含される情報に基づいた１つの事象レポートを集め、
（ｃ）　ＳＮＭＰによるプロトコルに従ってプロトコルデータユニット内の前記事象レポートをパッケージするように、前記車載用計算装置を設定する、各ステップを含んでいる。
【００１７】
好ましくは、この作動特性は、ＧＰＳ位置、エンジン速度、車両速度、又はエンジン温度、あるいは、車両のエミッションに関係するＯＢＤ−ＩＩパラメータを含んでいる。１つのＯＢＤ−ＩＩパラメータは、不点火検出（ｍｉｓｆｉｒｅ ｄｅｔｅｃｔｉｏｎ）であり、他のパラメータは、Ｏ２センサ等を適用できる。
【００１８】
１つの実施形態によれば、本発明は、（ａ）遠隔モニタリングを行う受信者側とのデータリンクを確立し、（ｂ）データリンク上でプロトコルデータユニットを送信するために、車載用計算装置を作動させるステップをさらに含んでいる。
【００１９】
収集、パッケージング、及び送信ステップは、同時又は異なる時間で発生させることができる。この場合、計算装置は、規則的、または不規則的な間隔でデータを収集することができ、さらに、移動した距離等の最新の送信状態のためのデータのいくつかのタイプ、あるいは、現在のＧＳＰ位置または超過した規制閾値等の即時の送信状態のためのデータの他のタイプを蓄積することができる。これとは別に、計算装置が、ワイヤード又は他のデータリンク上でプロトコルデータユニットを送信できるいくつかの例がある。
【００２０】
好ましくは、この方法は、車載用計算装置から特定組の管理オブジェクトに対する現在値を読み出すために、ＧＥＴプロトコルデータユニットを出力して遠隔モニタリングを行う受信側を起動させるステップをさらに含んでいる。この場合、遠隔モニタリングを行う受信側は、車載用計算装置によってＧＥＴプロトコルデータユニットへの受信通知を待つようにすることができる。
【００２１】
好ましくは、ＴＲＡＰプロトコルデータユニットを出力して車両の事象を報告するために、車載用計算装置を起動させるステップをさらに含んでいる。
好ましくは、この方法は、（ａ）各車両の事象に対する閾値または報告間隔を記憶し、（ｂ）閾値が対応する報告間隔にあるかまたはそれを超える状態のとき、各ＴＲＡＰを出力するために、前記車載用計算装置を起動させるステップをさらに含んでいる。
【００２２】
この場合、　ＴＲＡＰプロトコルデータユニットは、ＧＳＰ位置等を知らせることができる。
好ましくは、本方法は、例外的な車両の事象を知らせるために、車両からのインフォームプロトコルデータユニットを出力するステップをさらに含んでいる。この方法は、この場合、好ましくは、
（ａ）１つまたは複数の規定の例外、メンテナンスの例外、またはオプション的な例外を含む、診断情報基準における複数の特定の例外的車両事象のいずれか１つを記憶し、（ｂ）前記いすれか１つの特定事象が起こった時にインフォームプロトコルデータユニットを出力するように、前記車載用計算装置を起動させるステップをさらに含んでいる。
【００２３】
ある実施形態において、診断情報基準は、１つの事象の発生が起こるか否かを構成する規格を含んでいる。この事象が起こると、この事象の記録が送信待ち行列で作成され、確認メッセージ（この場合ＲＥＳＰメッセージ）が車載用計算装置によって受信されるまで、そこに留まる。従って、この方法は、１つの実施形態において、レジスタまたは他の一時的記憶モジュール内に車両の事象を蓄積し、この事象は、診断情報基準において特定される。
【００２４】
管理オブジェクト（管理すべき対象物）は、例えば、エンジン温度とすることができる。また、管理オブジェクトのための状態は、最大閾値、現在値、及び現在値が測定されるとき記録するためのタイムカウントとすることができる。
【００２５】
診断情報基準の例としては、次のテーブルで示される。
【００２６】
【表１】
2004511188.tif 000003
事象の記録レジスタの例は、特定の時間Ｔ＝Ｔ１での管理オブジェクトのための現在値を示す次のテーブルにおいて示される。
【００２７】
【表２】
2004511188.tif 000004
１つの例において、インフォーム・プロトコルデータユニットは、規定の閾値レベルが越えている結果として、出力される。
【００２８】
好ましくは、この方法は、以前のインフォーム・プロトコルデータユニットが、遠隔モニタリングを行う受信側によってデータベースに記録されたことを確認した後に、前記車載用計算装置を起動させるステップを含んでいる。この場合、この方法は、好ましくは、以前のインフォーム・プロトコルデータユニットが、遠隔モニタリングを行う受信側によってデータベースに記録されたことを確認しないで、前記インフォーム・プロトコルデータユニットを再送信するステップをさらに含んでいる。
【００２９】
好ましくは、この方法は、１つまたは複数の管理オブジェクトを設定するために、前記車載用計算装置にＳＥＴプロトコルデータユニットを出力するように、遠隔モニタリングを行う受信側を起動させるステップを含んでいる。
【００３０】
ワイヤレスデータリンクは、ＩＥＥＥ８０２．１１基準、サテライトＲＦパケットネットワーク又は地球規模のＲＦパケットネットワークに基づく無線周波数帯域とすることができる。
【００３１】
１つの実施形態において、プロトコルデータユニットは、リクエスト（ＲＥＱＵＥＳＴ）タイプ（ＧＥＴ、ＳＥＴ、またはＩＮＦＯＲＭ）プロトコルデータユニットであり、このデータユニットは、ＳＮＭＰプロトコルのエラーステータスおよびエラーインデックスフィールドを排除する。
【００３２】
１つの実施形態において、プロトコルデータユニットは、ＳＮＭＰプロトコルの可変バインディングの各々の長さ（ＬＥＮＧＴＨ）フィールドを排除する。
さらに、別の構成によれば、本発明は、車両作動データを、車両から遠隔モニタリングを行う受信側に送信する方法を提供し、この方法は、
車両と前記受信側との間のデータリンクを確立し、
車両におけるデータ源から車両作動データを収集し、
ＳＮＭＰから導かれるプロトコルを用いてデータパケット内の車両作動データをパッケージし、
前記データリンク上に前記データパケットを送信する、各ステップを有し、
前記プロトコルデータユニットは、遠隔モニタリングを行う受信側による要求に応答して出力され、さらに、前記プロトコルデータユニットは、前記要求及び要求された要求値の両方を含み、かつ単一のメッセージ及びフラグメント化されない単一のネットワークパケット内に封入されていることを特徴とする。
さらに、別の構成によれば、本発明は、車両からの最新の送信状態に対する車両作動データを、遠隔モニタリングを行う受信側に、前記最新の送信状態に対するバンド幅の要求を最小化するように収集する方法を提供し、この方法は、
車両の車載用計算装置を用意し、
前記車両の管理オブジェクトの現在値をそれぞれ記録するために、複数のデータ収集モジュールを用意し、
前記車両の車載用計算装置を前記データ収集モジュールの各々に接続し、
（ａ）　前記データ収集モジュールの各々から前記管理オブジェクトの各々に対する値を受信しかつ記憶するための診断情報基準を形成し、
（ｂ）　前記診断情報基準に包含される情報に基づいた１つの事象レポートを集め、
（ｃ）　プロトコルデータユニット内の前記事象レポートをパッケージするように、前記車載用計算装置を設定する、各ステップを有し、
前記プロトコルデータユニットは、複数の可変バインディングフィールドを有するプロトコルデータユニット・ペイロードを含み、前記可変バインディングフィールドは、それぞれ２バイトのオブジェクト識別子フィールド、１バイトのバリュータイプフィールド、及びこのバリュータイプフィールドに従う可変バインディングのサイズ値を有する複数の可変バインディングフィールドを含んでいることを特徴とする。
【００３３】
１つの実施形態において、プロトコルデータユニットは、一組の値の一方に対応する値とともにＰＤＵタイプのデータ要素を有するヘッダーを含み、前記一組の値は、ＧＥＴ値、ＳＥＴ値、ＴＲＡＰ値、ＩＮＦＯＲＭ値、及びＲＥＳＰＯＮＳＥ値を含んでいる。
【００３４】
さらに、別の構成によれば、本発明は、車両作動データを、車両から遠隔モニタリングを行う受信側に送信するためのコンピュータ実行システムを提供し、このシステムは、
車両における複数の車両作動データ源と接続される車両の車載用計算装置と、
ワイヤレスデータリンクを車載用計算装置及び遠隔モニタリングの受信側と共に確立するためのワイヤレス通信装置とを含み、
前記車両の車載用計算装置は、ＳＮＭＰから導かれるプロトコルを用いて、ワイヤレスデータリンク上で遠隔モニタリングの受信側に伝送するために、データパケット内の車両作動データをパッケージできるようになっている。
さらに、別の構成によれば、本発明は、車両作動データを、車両から遠隔モニタリングを行う受信側に収集しかつ送信するための、コンピュータで読取可能なデータ構造（構造体）を提供し、このデータ構造（構造体）は、
車両における複数のデータ源から車両作動データを受信するためのアプリケーションモジュールと、
診断情報基準、複数の車両作動パラメータ用の多数の管理オブジェクト、およびこれらの管理オブジェクトの各々に対する多数の値を記憶するための記憶モジュールと、
ワイヤレスデータリンク上のＳＮＭＰから導かれるプロトコルの下で、プロトコルデータユニットを、遠隔モニタリングを行う受信側に送信するための通信モジュールとを含んでいる。
【００３５】
さらに、別の構成によれば、本発明は、コンピュータで読取可能な媒体にエンコードされたコンピュータプログラム製品を提供し、このコンピュータプログラム製品は、
車両作動データを車両から遠隔モニタリングを行う受信側に収集しかつ送信するために、車載用コンピュータのためのコンピュータで実行可能な複数のステップを含んでおり、
車両における複数のデータ源から車両作動データを受信し、
診断情報基準、複数の車両作動パラメータ用の多数の管理オブジェクト、およびこれらの管理オブジェクトの各々に対する多数の値を記憶し、
前記コンピュータと前記受信側との間でワイヤレスデータリンクを確立し、
ワイヤレスデータリンク上のＳＮＭＰから導かれるプロトコルの下で、複数のプロトコルデータユニットを前記遠隔モニタリングを行う受信側に送信する、各ステップを含んでいる。
【００３６】
さらに、別の構成によれば、本発明は、キャリア媒体上に伝搬される信号を提供し、この信号は、ＳＮＭＰから導かれるプロトコルに従う、自動車の予め決められた作動データをエンコードするペイロード（ｐａｙｌｏａｄ）を含むパッケージされたプロトコルデータユニットを含んでいる。
【００３７】
好ましくは、このペイロードは、複数の可変バインディングフィールドを含み、該可変バインディングフィールドの各々は、それぞれ２バイトのオブジェクト識別子フィールド、１バイトのバリュータイプフィールド、及びこのバリュータイプフィールドのデータユニットに従う可変バインディングのサイズ値を有する複数の可変バインディングフィールドを含んでいる。
【００３８】
好ましくは、　ペイロードは、ＧＳＰ位置セグメント、ＧＳＰヘッディングセグメント、車両速度セグメント、またはＯＢＤＩＩの車両エミッション・セグメントを含んでいる。
【００３９】
さらに、別の構成によれば、本発明は、車両作動データを、車両から遠隔モニタリングを行う受信側に送信するシステムを提供し、このシステムは、
車両における複数の車両作動データ源に接続される車両の車載用計算手段と、
ワイヤレスデータリンクを車載用計算装置及び遠隔モニタリングの受信側と共に確立するためのワイヤレス通信手段とを含み、
前記車両の車載用計算手段は、ＳＮＭＰから導かれるプロトコルを用いて、ワイヤレスデータリンク上で遠隔モニタリングの受信側に伝送するために、データパケット内の車両作動データをパッケージできるようになっていることを特徴とする。
【００４０】
さらに、別の構成によれば、本発明は、車両作動データを、車両から遠隔モニタリングを行う受信側に送信する方法を提供し、この方法は、
前記車両と前記受信側との間のデータリンクを確立するための段階と、
前記車両におけるデータ源から車両作動データを収集するための段階と、
ＳＮＭＰから導かれるプロトコルを用いて、データパケット内の車両作動データをパッケージするための段階とを含んでいる。
【００４１】
さらに、別の構成によれば、本発明は、複数の車両間のでデータを交換するための通信ネットワークを提供し、この通信ネットワークは、
対応する車両に搭載される計算ユニットを含み、所定車両に設けた前記計算ユニットが識別メッセージを放送し、かつ隣接する領域にある他の車両から等価な識別メッセージを受け取ることが可能であり、前記メッセージは、ネットワーク内の近くにいる車両を識別するために使用され、そこで、選択された１つの車両とデータを交換することを特徴とする。
【００４２】
好ましくは、この計算ユニットは、近くにいる車両のリストを更新するように作動する。この場合、この計算ユニットは、識別メッセージがその領域に入る新しい車両から受信されるときに、近くにいる新しい車両をリストに付加することができる。これとは別に、計算ユニットは、所定の時間経過後、識別メッセージが、特定の近くにいる車両から受信されなかったとき、特定の近くにいる車両をリストから削除することもできる。また、この計算ユニットは、近くにいる車両が隣接する領域から立ち去ったことを示す識別メッセージを、特定の近くの車両から受信しなかったとき、この近くにある車両のデータベースからこの車両を削除する。
【００４３】
好ましくは、通信の媒体は、チャネル化されたＲＦ帯域の高周波であり、各計算ユニットによってこの高周波が用いられ、ＩＥＥＥ８０２．１１媒体アクセス制御（ＭＡＣ）プロトコルに従って制御される。
【００４４】
好ましくは、計算ユニットは、インターネットによりアドレス可能である。
好ましくは、計算ユニットは、ＩＰｖ６によりアドレス可能である。
好ましくは、計算ユニットは、ＳＮＭＰから導かれたプロトコルを用いてデータを交換する。
【００４５】
望ましくは、識別メッセージは、送り手のＧＳＰ情報とＩＥＥＥ８０２．１１媒体アクセス制御（ＭＡＣ）アドレスを含み、ＧＳＰ情報は、緯度、経度、速度及び機首方位の情報を含んでいる。
１つの実施形態において、近くにいる全ての車両は、特定の車両を近くの車両として認識できるために十分な、発見に必要な時間内で識別メッセージを送信する。発見に必要な時間の長さ及び領域の地理的大きさの両方は、近くにいる車両の平均速度に比例して調整することができる。
【００４６】
所望であれば、少なくともいくつかのメッセージの送信用のチャンネル選択は、ＧＳＰヘディングに基づいている。
１つの実施形態において、計算ユニットの各々は、さらに、ＳＮＭＰプロトコルの下でメッセージを送信しかつ受信することができる、送信器及び受信器を含んでいる。
【００４７】
別の構成によれば、本発明は、上記の構成を含む自動車を提供する。
さらに別の構成によれば、本発明は、速度セグメント、機首方位セグメント、及び位置セグメントを含むデータ構造（構造体）を提供する。好ましくは、位置セグメントは、経度部分と緯度部分を含んでいる。
【００４８】
別の構成によれば、本発明は、キャリア媒体上に伝播される信号を提供し、この信号は、速度セグメント、機首方位セグメント、及び位置セグメントを含んでいる。好ましくは、位置セグメントは、経度部分と緯度部分を含んでいる。
【００４９】
別の構成によれば、本発明は、リストされた車両の選択された車両とデータを交換するための隣接地区のリストを集めるために、隣接領域にある他の車両からのメッセージを受信するように作動可能な車載用計算ユニットを含んでいる車両を提供する。
【００５０】
さらに別の構成によれば、本発明は、モータビークル上でプログラム可能なコンピュータシステムを作動させるためのコンピュータプログラム製品を提供し、このコンピュータプログラム製品は、隣接領域内の他の車両からのメッセージを受信し、リストされた車両の選択された車両とデータを交換するための隣接地区のリストを集める、コンピュータ実行ステップを含むコンピュータの読取可能媒体を含んでいる。
【００５１】
また、別の構成によれば、本発明は、車載用コンピュータと広帯域無線を含むモータビークルを提供し、前記広帯域無線は、近くにいる少なくとも１つの他の車両の無線とデータリンクを確立し、コンピュータが、隣接地区のリストを集めるために隣接領域にいる前記少なくとも１つの他の車両からのメッセージを記録し、さらに、前記データリンク上で受信したデータから少なくとも１つの車両の事象を識別するように作動可能であることを特徴とする。
また、別の構成によれば、本発明は、車載用計算装置及び遠隔モニタリングを行う受信側からのデータを収集しかつ送信するためのコンピュータ読取可能なデータ構造（構造体）を提供し、このデータ構造（構造体）は、
車載用計算装置及び遠隔モニタリングを行う受信側の間のデータ交換用のプロトコル値、対応する要求および応答をインデックスするためのモジュールと、
車両における複数の作動特性に対する一連の管理オブジェクトをインデックスするためのモジュールと、
管理オブジェクトの各々に対する値を記録するためのモジュールとを含んでいる。
【００５２】
好ましくは、データ構造（構造体）は、遠隔モニタリングを行う各受信側に対する識別をインデックスするためのモジュールをさらに含んでいる。
好ましくは、データ構造（構造体）は、遠隔モニタリングを行う各受信側に対する１つまたは複数の管理レベルのリストをインデックスするためのモジュールをさらに含んでいる。これらの管理レベルは、管理オブジェクトの値の状態を課するために用いられ、受信側に送信される。いくつかの受信側は、管理オブジェクトの全てに名前を付け、他の受信側は、管理オブジェクトの値のいくつかに名前を付け、そして、さらに、他の要求している構成要素（リストには入っていない）は名前を付けない。
【００５３】
【発明の実施の形態】
以下に、車両用の診断遠隔測定のためのプロトコルスタックに基づいて対等接続（ピアツーピア）インターネット基準のプロトコルスタックを実行するシステム及び方法が記載されている。このスタックは、車載用に組み込まれるシステム内に存在し、かつウインソック（Ｗｉｎｓｏｃｋ）等の標準通信ＡＰＩシステムを用いてこれらのシステムと相互作用するためのＰＣワークステーションを遠隔操作できるように意図されている。
【００５４】
このスタックのセッション及びプレゼンテーション用のレイヤーは、自動車遠隔測定プロトコル（ＡＴＰ）として名づけられている。このＡＴＰは、メッセージ　フォーマット、プロトコル手順、セキュリティ機構、及び外部インターフェースの明確な仕様を必要とし、これらのソフトウエアによって相互に動作可能となる移動及び固定の計算プラットフォーム上でのＯＢＤ−ＩＩＩを実行するために発展してきた。
【００５５】
以下において、オブジェクトを検索し、かつ３〜６のレイヤー（ネットワーク、輸送、セッション、及びプレゼンテーション）のより詳細な説明が与えられる。セッション及びプレゼンテーションは、単純ネットワーク管理プロトコル（ＳＮＭＰ）のための仕様から導かれる。基礎をなすトランスポート機構は、バンド幅効率のために圧縮されたＵＤＰヘッダーを有するＵＤＰ／ＩＰスタックである。
【００５６】
セキュリティーの出力は、下層にアドレスされ、かつ特定のデータ源が、特定の要求構成要素（顧客）に制限される得るようなスタックの実行を構成する能力がある。安全ソケットレイヤー（ＳＳＬ）プロトコルのアプリケーションは、車載用コンピュータによって外部源からの情報に対する要求の確認を示唆するために再調査される。
【００５７】
このプロトコルスタックは、道路上の車両間の作動データを交換するために利用される。これは、特定の車両の回りの隣接地区内に確立されるアドホック（ａｄ−ｈｏｃ）ネットワークの概念に基づいている。このアドホックネットワークは、道路側のインフラストラクチャが展開しているならば、同一のＲＦ媒体を用いてインターネットへのデータリンクと共に存在することができる。ハイウエイの安全に対するこの技術の重要性は、作動情報の車両間におけるデータ交換の種々の例と共に説明される。
【００５８】
インテリジェント車両とインテリジェントハイウエイシステムの両方におけるＩＥＥＥ８０２．１１コンプライアント技術を統合する方法が記載されている。車載または道路基礎構造の一部のいずれかに、このようなシステムの構成要素を含むインテリジェント輸送システム又はＩＴＳが、ここに参考として示される。
【００５９】
現在注目される多くのインテリジェント車両技術は、レーダーに基づく衝突回避に向けられている。他方、インテリジェントハイウエイシステムは、車両と道路基礎構造の間の短い範囲の通信に使用することに向けられてきた。しかし、政府機関及び自動車供給側の両方の専門家は、その領域を車両間通信に広げるべきであると認識するようになった。
【００６０】
ＩＥＥＥ８０２．１１規格は、高速ワイヤレス局エリアネットワーク（ＬＡＮ）のための比較的新しい基準である。この規格は、２．４ＧＨｚのレンジが不認可帯域として利用可能となっているスペクトル拡散として知られるＲＦ伝送の方法を用いている。また、この技術は、商業的なバナーＷｉ−Ｆｉ（ワイヤレス　フィデリティー）の下で識別される。ＩＴＳの領域における利用の重要性は、その商業的ポテンシャルに基づいている。計算装置に対するネットワーク基礎構造を支持する移動度を作ることができる商業的に利用可能なＷｉ−Ｆｉ製品が現在ある。ネットワークインターフェースカード（ＮＩＣ’Ｓ）は、Ｗｉ−Ｆｉを用いるために、ラップトップ型及びノートブック型を含むパーソナルコンピュータを利用することができる。Ｗｉ−Ｆｉの人気が高まると、モービル式ワイヤレス装置（例えば、ＰＤＡや、携帯電話）が市場に現れることが期待でき、現在１１Ｍｂｐｓとなっているデータ通信速度において、使用者は、ワイヤレスでインターネット接続できるアクセスポイントの拡大インフラストラクチャを活用できることになるであろう。
【００６１】
ＩＥＥＥ８０２．１１規格の１つの特徴は、固定のアクセスポイントを必要としないで、２つ以上の装置で互いに直接通信することが可能なアドホック・ネットワーキングの概念である。言い換えれば、ネットワークインフラストラクチャは、移動装置間における接続のための必要条件ではない。その結果、ＩＥＥＥ８０２．１１規格は、新規でかつ予測できない方法で、車両間及び車両とインフラストラクチャ（インフラ）との間の通信をサポートする。この組合せによる柔軟性は、技術的見通し及び商業的欲求から、ＩＴＳにおけるＩＥＥＥ８０２．１１規格を用いる正当性を有することを示している。
【００６２】
本明細書に記載される方法は、規格の修正なしに、ＩＴＳ用のアドホック・ネットワーキングの要求に一致して十分に組み入れられる８０２．１１ノードを満たす原理に基づいている。
【００６３】
ＡＴＰへの関係
ここに記載する方法は、２つの車両間で作動できる自動車遠隔計測システム（ＡＴＰ）のプラットフォームを与えることを意図している。このＡＴＰは、ＳＮＭＰから導かれるセッションレベルのプロトコルであり、それは、移動通信の２つのエンドポイント間で確立されるべき双方向の顧客サーバーの関係となる（［１］参照）。車両間通信の状況において、ＡＴＰは、「顧客」の車両が、確認を必要とする特定の「サーバー」の車両に同期した通知を送ることを可能にしている。このリクエスト−レスポンス機構は、本明細書において後述するアプリケーションを有している。
【００６４】
プロトコル　スタック
図１は、ＯＳＩ（オープン　システム相互接続）基準モデルを用いる、ＯＢＤＩＩＩのために必要とされる完全なプロトコルスタックを示す。
このプロトコルスタックは、以下の１つまたは複数のオブジェクトに合うように意図されている。
【００６５】
ワイヤレスデータ・リンク・トランスパレンシー
これは、技術−独立性のために必要とされるものである。種々のワイヤレスデータ・リンク技術を用いてＯＢＤＩＩＩコンプライアンスを一致させることが可能である。移動装置は、パケットセルラー、ＲＦパケットネットワーク、ワイヤレスＬＡＮ（Ｗｉ−Ｆｉ）、サテライト局、またはこれらのいくつかの組合せを用いることができる。
【００６６】
インターネット接続性（ＯＥＭポータルを越えて）
遠隔ＩＰアドレスにあるワークステーションが、ＯＢＤに接続され、車両内で他の作動データを利用する車載用の車両の機器と直接に相互作用することが可能になる。言い換えれば、車両と他の遠隔ホスト局との間の完全なインターネット接続は、所望の結果であり、ＯＥＭポータルを通過しないアプリケーション用いて公認ホスト局に接続できる。これは、車両の機器が標準プロトコル規格を含んでいることが必要であり、公認ホスト局とインターネットでピアツーピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）のデータ交換をサポートする。（公認ホスト局の通知に関連する以下の「セキュリティー」を参照のこと。）。
【００６７】
有効なバンド幅利用
モニタリングに対して信頼性がある固定局側との間のデータ交換、及び移動ユニットは、「バーボーズ（ｖｅｒｂｏｓｅ）」を必ずしも必要としない。ワイヤレスの利用において、ウエブ表示のいくつかの形式は、ユーザ・インターフェース（ＵＩ）を単純化することが要求されるという傾向があり、ワイヤレス利用プロトコル（ＷＡＰ）の展開にとって、部分的に責任を担ってきた。ＷＡＰは、ウエブのＵＩの特徴とエアリンク上でのバンド幅効率との間のいくつかの妥協を図る技術である。交通における遠隔測定は、ワイヤレスデータの他の形式とは全くその目的が異なっているという事実を考慮しておらず、また、標準の方法と異なる形でサポートされている。
【００６８】
標準データ交換機構
プロトコルスタックのより高いレベル（セッション及びプレゼンテーション）は、種々の理由から標準化される必要がある。これは、規則を実行するために選択される全ての管轄範囲においてＯＢＤ−ＩＩＩに追従する仕事を単純化する。
【００６９】
セキュリティー
セキュリティーの必要性は、ＣＡＲＢによって強調されてきた。ＯＢＤ−ＩＩＩの概念を政治的に受け入れることは、この技術が個人のプライバシーに侵入する状態とならないような公的信頼性に従っている。ドライバーや車の所有者は、情報の開放に対する電子制御が、ウエブベースのＥ−コマースにおいて現在使用されているものと同様の効果を少なくとも有することを自覚すべきである。現在のシステムは、必要ならば、企業と消費者との間のＥ−コマースにおいて行われているものと同一の方法で、セッションレイヤーの上にパブリックキーの暗号手法を用いることができると考えられている。インターネット上のホスト局と接続が可能であるが、それらのホストは、車両からの「注意」を受け入れるセキュリティー機構を介して許可を得ることを確実にする。
【００７０】
ネットワーク及びトランスポートレイヤーＵＤＰ／ＩＰ
ＡＰＴが作動する内容を理解するために、ＡＴＰをサポートする根本的なトランスポート機構を考慮する必要がある。ユーザ・データプロトコル（ＵＤＰ）は、接続不要（ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ）の顧客サーバー間の通信のための輸送レベル機構である。ＵＤＰは、トランスポートプロトコルの１つを構成し、インターネット上で作動できる。「接続不要」プロトコルの概念は、信頼性のあるエンドーエンド間の通信を維持するように努める必要がないことを表す。この意味で、ＵＤＰは、ＴＣＰ（トランスポートコントロールプロトコル）から区別される。より短いＵＤＰヘッダー（８バイト）は、この差異を表している。
【００７１】
インターネットの基本プロトコルデータユニット（ＰＤＵ）は、データグラムと呼ばれる。このデータグラム・ヘッダーは、スタックの次のレベルにおいてプロトコルを指定するのに用いられるフィールドを含んでいる。ＵＤＰ及びＴＣＰ用のＩＡＮＡ２ｆ値は、それぞれ１７と６である。異なるデータグラムのペイロードが、ＵＤＰ及びＴＣＰをどのようにできるかを示す以下の数値は、データグラム・ヘッダーにおける「プロトコル」フィールドの値によって決まる。
【００７２】
上述したように、標準ＵＤＰへッダーは、その長さが８バイトであり、転送元ポート（２バイト）、転送先ポート（２バイト）、ペイロード長さ（２バイト）、チェックサム（２バイト）からなっている。
【００７３】
従来のＵＤＰのユーザーにおいて、転送元及ポートび転送先ポートは、送り手と受け手のそれぞれのアドレス空間内で実行する処理に関連するＩＡＮＡの公認ナンバーである。現在の自動車遠隔測定利用に対して割り当てられる番号は、現状ではない。このシステムは、ＡＴＰポートを特定するために番号０ｘ０Ａ（整数１０）を用いる。
【００７４】
ＵＤＰヘッダーの圧縮
自動車遠隔測定の利用において、ＵＤＰヘッダーのオーバーヘッドは、柔軟性または信頼性に関するプロトコルに対して十分な利点を与えることなくワイヤレスバンド幅を使用している。転送元及び転送先ポートは、同一番号を用いるように強制することができる。ペイロード長さは、根本的なネットワークパケットのフィールドまたはＵＤＰセグメントが包含されているデータリンクフレームから導くことができる。最後に、根本的なデータリンクプロトコルは、とにかくデータ流れを完全にチェックするべきものであるので、チェックサムは、冗長なものとみることができる。
【００７５】
ワイヤレスバンド幅使用を最小にする必要から、ＵＤＰヘッダーは、１つの実施形態において、移動通信プロトコルスタックの実行において、図４に示すように、１バイト削減する。このバイト（０ｘ０Ａまたは整数１０）の値によって、転送元及び転送先の両方において、ＡＴＰポートを識別する。
【００７６】
セッション及びプレゼンテーション・レイヤー
ＡＴＰは、セッションレイヤーにおいて概念的に存在するものである。単純ネットワーク管理プロトコル（ＳＮＭＰ）と同様なリクエスト−レスポンス機構があり、これは、移動ユニットからベース位置に又はその逆への各メッセージに対して確認が求められる。このように、「持続性記憶装置」のデータベースにレポートが格納されることをベースシステムが確認するまで、移動計算プラットフォームによって車両からの例外レポーを廃棄することができない。
【００７７】
ＡＴＰの設計思想は、通信装置の遠隔診断とその設定ができ、かつインターネット基礎構造の要素が従うデ−ファクト（ｄｅ−ｆａｃｔｏ）基準である単純ネットワーク管理プロトコル（ＳＮＭＰ）に基づいている。通信装置と移動車両の遠隔診断において比較がなされる。これは、図５（ａ）と図５（ｂ）に図示されている。
【００７８】
ＳＮＭＰにおいて、「管理されたエントリー」は、一般的にブリッジ又はルータ等の通信切換装置である。この管理されたエントリーは、要求された情報を読み出し、インターフェースを介して通信プロトコルスタックに遠隔の「マネージャー」と対話するために応答可能なソフトウエアモジュールである「エージェント」を実行する。図５（ａ）は、このスタックのトップレベルがＳＮＭＰであるこを示しており、これは、セッション及びプレゼンテーション・レイヤーの組合せである。遠隔のマネージャーが要求するこの情報は、管理情報ベース（ＭＩＢ）に存在しており、この管理情報ベースは、ハードウエア・インターフェースを外部世界（通信モジュール）に対して制御する装置ドライバによって集められた作業データのためのローカル貯蔵所である。例えば、イーサネット（Ｒ）アダプタを有するルータは、イーサネット（Ｒ）インターフェースを通過する入口及び出口の数を統計的に報告する。この情報は、ＭＩＢに隠され、そして、要求を出力した遠隔のマネージャーのためにエージェントによって読み出される。
【００７９】
図５（ｂ）以下に示すＡＴＰの場合において、ＳＮＭＰマネージャーに等しいエントリーは、「モニタ」と呼ばれる。また、この管理されたエントリーは、種々のデータ収集モジュールに接続される車載用計算装置である。これは、ローカルデータの貯蔵所である診断情報ベース（ＤＩＢ）と呼ばれる。この情報は、ＥＣＵ診断ポート、アナログ及びデジタルセンサ、ＧＳＰ受信機等の種々のソースから発生するＤＩＢに隠される。図に示されているこれら３つの例示は、
・ＳＡＥＪ−１９７９（ＯＢＤ−ＩＩのために必要とされる診断テストモード）
・ＧＳＰ受信機
・ダイレクトアナログ及びデジタル入力チャネル
である。
【００８０】
これは、決して可能なデータ源の完全なリストではない。他の例は、
・ＳＡＥＪ−２１９０（法律上で推奨された補遺）
・ＳＡＥＪ−２１７８（通常の車両動作）
・ＳＡＥＪ−１７０８（大型トラック及びバス）
・ＳＡＥＪ−１９３９（Ｊ−１７０８に対する後継物）である。
【００８１】
ＳＮＭＰ及びＡＴＰメッセージフォーマット
このＳＮＭＰメッセージは、ヘッダーとプロトコルデータユニット（ＰＤＵ）からなる。このヘッダーは２つのフィールドを含んでいる。
・バーション番号
これは、メッセージの発信者によって用いられるＳＮＭＰのバージョンを特定する。
・通信名
これは、認証の原始的な方法として役立つ。１つのコミュニティーに属するマネージャーは、同一の管理ドメイン内に存在するといえる。管理エージェントがＳＮＭＰメッセージを認知されていないコミュニティー名を含むマネージャーから受け取るとき、このエージェントはＳＮＭＰ作業に参加しない。
現在のシステムにおいて、ワイヤレスバンド幅の使用を少なくするために、ポテンシャル的な冗長があるフィールドを削除することが望ましい。コミュニティー名が知られている場合、表現レベル（例えば、上記ＡＴＰ）においてより強い認証形式が必要とされる。ＡＴＰが実験段階を越えて発展するならば、バージョン番号のみが必要となるであろう。
【００８２】
ＳＮＭＰ　プロトコル動作
残りのＳＮＭＰメッセージは、プロトコルデータユニット（ＰＤＵ）である。ＳＮＭＰ規格において定義されるリクエストＰＤＵの基本形式は、４つある。
・Ｇｅｔ
マネージャーは、エージェントのＭＩＢから１つのアイテムを読み出すためにＧｅｔ（ゲット）ＰＤＵを用いる。
・Ｓｅｔ
Ｓｅｔ（セット）ＰＤＵは、エージェントＭＩＢにおいてある値を設定するためにマネージャーによって用いられる。
・Ｔｒａｐ
エージェントは、非同期通知、またはマネージャーに「警報」を送るために、Ｔｒａｐ（トラップ）ＰＤＵを用いる。
・Ｉｎｆｏｒｍ
Ｉｎｆｏｒｍ（インフォーム）ＰＤＵは、トラップＰＤＵに類似する。どのＳＮＭＰエントリー（他のメネージャーと通信するエージェントまたはマネージャーのいずれか）が非同期通知を送るためにインフォームＰＤＵを用いることができる。トラップＰＤＵと対比して、受け手のマネージャーは、インフォームＰＤＵを認識しなければならない。
【００８３】
プロトコルデータユニットフォーマット
ＰＤＵのこれら４つの範疇は、ＡＴＰに大いに適合している。これらの使用が自動車遠隔測定の内容において調べられる前に、ＳＮＭＰ・ＰＤＵの実際のフォーマット規格が要約される。図６は、ＧＥＴ値、ＳＥＴ値、ＴＲＡＰ値、ＩＮＦＯＲＭ値、及びＲＥＳＰＯＮＳＥ値の各ＰＤＵのためのフォーマットを示す。
【００８４】
ＰＤＵ形式
これは、ＰＤＵの形式を特定する。これは、すでに記載した又は応答した４つのリクエストＰＤＵのいずれか１つである。
【００８５】
リクエストＩＤ
これは、ＰＤＵのシーケンス番号である。リクエストＰＤＵの受け手は、レスポンスＰＤＵにおいてリクエストＰＤＵを用い、その結果、送り手は、この応答を前に送られたリクエストと適合させることができる。受け手は、複製メッセージを篩い分けことができる。これは、移動ワイヤレスネットワーク環境において特に重要である。この環境では、過度的状態が到達できない移動ノードにある場合、送り手に再試行を試みるようにさせる。この種のシナリオにおいて、複製メッセージが転送先に届く確率は非常に高い。これは、図７に示されている。データグラムに包含されているリクエストＰＤＵは、移動ネットワークに出入り口を介して移動エージェントに発送する。リクエストＰＤＵは、移動ネットワークパケットに包まれ、最も近いＲＦベースステーションからワイヤレスリンクを介して移動エージェントに発送される。移動エージェントが、ネットワークパケットを含むエアリンク・フレームを受け取るのに対して、一方、ＲＦベースステーションは、そのレスポンスが伝達された確認を「聞く」ことをしない。必要十分な時間が経過したのち、ＲＦベースは、移動エージェントが「到達できない」ことを、移動ネットワークの出入り口に戻って報告する。この報告が送り手（ＡＴＰモニター）に転送されると、メッセージは、再度送られる。
【００８６】
・誤差状態
このフィールドは、レスポンスＰＤＵにおいてのみ使用される。これは、誤差数及び誤差の形式の一方を示す。
・エラーインデックス
このフィールドは、レスポンスＰＤＵにおいてのみ使用される。これは、誤差（適用可能な）を残りのＰＤＵに包含される「可変バインディング」の１つと関連させる。
・可変バインディング
これは、ＳＮＭＰ ＰＤＵのデータフィールドである。各可変バインディングは、ＭＩＢの一部分である管理目的物の特定の例を、現在の値（ＧｅｔリクエストＰＤＵの例外としてその値が無視される）に結合することである。この目的物の識別器（ＯＩＤ）フィールドは、目的物の例を識別する。この可変値は、三つ組のＴＬＶ（形式、長さ、バリュー）に従ってエンコードされる。ここで、形式とは、データの形式を特定し、長さは、値が次に起こる流れにおいて表されるバイト数であり、また、バリューは、長さのバイトにおける値を含んでいる。このエンコードする方式は、アブストラクトシンタックス・ノーテーション言語（ＡＳＮ．１）の基本エンコード規則（ＢＥＲ）において設定されるプラクティスに従う。
【００８７】
ＡＳＮ．１は、ＯＳＩモデルのプレゼンテーション及びアプリケーション・レイヤーでのデータ交換プロトコルを定義するのに用いられるＩＳＯ特定言語である。その抽象品質は、異なる計算プラットフォームに現れる異なるデータ表現技術に独立させることができる。もちろん、データ構造を表現するためのシンタックスをより抽象化すればするほど、これらの構造が通信ネットワーク上のデータ流れをシリーズ化するとき、より多くのオーバーヘッドが必要とされる。
【００８８】
この理由として、ＳＮＭＰは、エンコード方式と関連したオーバーヘッドを制限し、そして、インターネット上のバンド幅を保持するために、ＡＳＮ．１（ＢＥＲの特定のサブセット）のサブセットのみに使用される（［２］［３］参照）。
【００８９】
ＡＴＰにおいて、バンド幅（ＡＴＰの移動環境においてより重要なものである）を保存するために、可変長さのストリングだけの長さフィールドを削除することによって、更なる制限をエンコード方式に課することができる。この点については、ＳＮＭＰ ＰＤＵフォーマットの以前の説明において、可変バインディングの詳細なフォーマットを示している。形式フィールドのみが用いられる。受け手は、バリューフィールドの長さを受け入れ側の形式から推量しなければならない。
【００９０】
この同一フォーマットが、１つの実施形態において、ＡＴＰ ＰＤＵのためのモデルとして採用されてきた。しかし、ワイヤレス環境におけるバンド幅の不必要な制限するために、次の例外をつくられた。
１．エラー状態とエラーインデックスのフィールドは、リクエストＰＤＵには現れない。
２．可変バンディング用のバリュ−フィールドは、ＧｅｔＰＤＵに現れない。
３．ＰＤＵにおける全てのフィールドの長さは、ＯＩＤと、可変バインディング（文字列を含まない）に内在するバリューフィールドとを含む。即ち、それらは、ＡＳＮ．１によって特定されるようなデータ流れの中に明確にエンコードなれない。全てのヘッダーフィールドの長さは、１バイトに制限されている。ＯＩＤフィールドの長さは、２バイトであり、また、可変バインディング値の長さは、１バイトでエンコードされるバリュー形式によって決まる。
【００９１】
ＳＮＭＰ ＰＤＵを有するＡＴＰプロトコル　オペレーションズ
すでに述べたように、前のセクションで記載した変更を伴うＳＮＭＰ ＰＤＵは、ＡＴＰのプロトコル要求に適用できる。ゲットＰＤＵは、ＡＴＰモニターが車両からの管理されたオブジェクトの特定組に対する現在値を読み出そうとするときに必要となる。この例は、図８に示されている。車両所有者が、固定位置のワークステーションから車両のＧＰＳ位置、エンジン速度、走行速度、及びエンジン温度を得ることができる。このデータの全てに対するリクエストと、それらの全てのリクエスト値を含む、車両からのレスポンスとの両方は、単一のＡＴＰメッセージ及びフラグメント化されていないネットワークパケット内に包含される。トラップＰＤＵは、確認を要求されない、車両からの事象レポートを送るために使用することができる。代表的な例は、繰り返されるＧＳＰ位置レポートである。車載用装置におけるアプリケーションソフトウエアは、ＧＳＰの管理オブジェクトのためのデータ構造内に特定された時間間隔でＧＳＰ位置を有するトラップＰＤＵを発生することができる。このレポーティングの目的は、実時間において車両を追跡することである。それゆえ、送り手が最新ではなくなったＧＳＰ位置を再送信する理由はないので、モニターからの確認は不必要である。
【００９２】
確認を必要とするインフォームＰＤＵは、車両からの非同期の事象レポートを送るために、一般的にＡＴＰにより用いられる機構である。これらの事象は以下のものに対応する。
・規定に関する例外（例えば、介入を要求するエミッションに関係した事象）
・メンテナンスに関する例外（例えば、至急の検査、評価、修理を必要とする欠陥状態）
・動作に関する例外（例えば、認可されていない方法での車両の使用）
このＰＤＵのために確認が必要となるので、車載用の監視エージェントは、事象レポートがデータベース内に格納されたか否かを判定する手段を有する。
【００９３】
セットＰＤＵは、車載用装置の動作パラメータを遠隔操作で変えるために使用される。これは、例えば、規定に関する例外が起こるときの閾値レベル、または自発的にＧＳＰ位置を報告する（トラップＰＤＵを用いて追跡利用のための）時間間隔である。
ＭＩＢ階層およびＤＩＢ導出
ＳＮＭＰ（単純ネットワーク管理プロトコル）がアクセスするＭＩＢ（管理情報基準）は、図９に示すように、階層的に編成された管理オブジェクト（管理すべき対象物）の集成である。管理オブジェクトは管理対象のデバイスの多くの特性の１つである。管理オブジェクトは本質的に変数である１つ、または複数のオブジェクト事例からなっている。
【００９４】
図９はＭＩＢ階層をツリーとして示しており、そのレベルは異なる組織によって割り当てられる。オブジェクト識別子（ＯＩＤ）はこの階層内の管理オブジェクトを一意的に識別する。トップレベルのＯＩＤは、異なる標準組織に属しており、一方、より低位レベルのＯＩＤは関連する組織によって割り当てられる。ＯＩＤは、管理オブジェクトがそれを介してツリーのルートから到達できるノードに対応する数のシーケンスから形成される。例えばシーケンス
１　３　６　１　２
はＴＣＰ／ＩＰプロトコル・スタックの仕様に準拠したエンティティ用のＭＩＢであるＭＩＢ−２オブジェクトを識別する。完全なオブジェクト名は：
ｉｓｏ．ｉｄｅｎｔｉｆｉｅｄ−ｏｒｇａｎｉｚａｔｉｏｎ．ｄｏｄ．ｉｎｔｅｒｎｅｔ．ｍｇｍｔ．ｍｉｂ−２
である。
【００９５】
このＭＩＢが幾つかのネットワークへのインターフェースを有する遠隔ルータ上に保存されているものと想定する。これらのインターフェースを表すオブジェクトはテーブル内に保存され、その各々のエントリはネットワーク・インターフェースに関連する変数の集成である。例えば、ＳＮＭＰマネージャーが第１のネットワーク・インターフェース上の（最前の始動以降の）オクテット数を検索したいものと想定してみる。このオブジェクトを識別するＯＩＤは：
１　３　６　１　２　１　２　１　１０
となり、オブジェクト名は、
ｉｓｏ．ｉｄｅｎｔｉｆｉｅｄ−ｏｒｇａｎｉｚａｔｉｏｎ．ｄｏｄ．ｉｎｔｅｒｎｅｔ．ｍｇｍｔ．ｍｉｂ−２．ｉｎｔｅｒｆａｃｅｓ．ｉｆｔａｂｌｅ．ｉｆｅｎｔｒｙ−１．ｉｆｏｃｔｅｔｓ
となるであろう。
【００９６】
同様の配置が診断情報ベースの階層についても考えられる。発生する問題はＤＩＤサブツリーがインターネット・ノードから分岐するのか、またはＳＡＥサブツリーが識別された組織から分岐するのか否かである。これらの２つのオプションが図１０に示すように出現することは明白である。この図は新たなサブツリーのルートがＤＩＢノードであるものとしている。さらに、ＡＴＰはプロトコルのインターネット・スイート内でＳＮＭＰと同じレベルで動作する（提案された）プロトコルであるので、ＤＩＢがインターネット・ノードで始まるサブツリーと共に存在するべきであることも明らかである。
【００９７】
インターネット・ノードの複製なしで、ＤＩＢがＳＡＥノードにルートがあるサブツリー内にいかにして存在し得るかは明らかではない。これは階層上の任意のノードを一意的に識別できるという規則違反であろう。したがって、新たなサブツリーがＡＴＰノードで発生することの方がより論理的であると思われる。
【００９８】
前述したように、ＡＴＰ　ＰＤＵの可変バインディング（ｖａｒｉａｂｌｅ ｂｉｎｄｉｎｇ）は２バイトの固定長でエンコードされる。これは、オブジェクトの親階層全体がＯＩＤが参照するものに含まれていないことを意味する。オブジェクト名
ｉｓｏ．ｉｄｅｎｔｉｆｉｅｄ−ｏｒｇａｎｉｚａｔｉｏｎ．ｄｏｄ．ｉｎｔｅｒｎｅｔ．ｍｇｍｔ．ｄｉｂ
に対応するプレフィックス
１　３　６　１　２　８
は各ＯＩＤの暗黙部分である。ＤＩＢノード以下の部分だけがシリアル化され、ネットワークを経て伝送される。
ユーザ・コンフィギュレーション
プロトコル・スタックの最高レベルに、インストーラ（または場合によってはドライバー）が内部の車両データのどのソースがどの遠隔「顧客」にアクセスできるかを特定できる、ある形式のユーザ・インターフェースが存在し得る。次の項では、任意の遠隔顧客のＩＤをどのようにして完全に認証できるか、および顧客と（車両）サーバー間の後続のデータ交換の盗聴者に対するセキュリティをどのようにして保てるのかを説明する。
セキュリティ
ＡＴＰによって、エージェントはリクエストの性質およびモニタのＩＤに基づいて、モニタからの要求を受諾するか拒絶する権限を有するものとする。例えば、現在のＧＰＳ位置を報告するという遠隔モニタからの要求は、それが車両の所有者によって管理されない位置から発したものである場合はプライバシーの侵害であるとみなし得る。同様に、ＯＢＤ情報（ＳＡＥ　Ｊ−１９７９）の要求も、ユーザ・コンフィギュレーションに基づいて認可されたモニタ（単数または複数）から発されたものでない限りは拒絶できよう。これらの要求を満たすためには、モバイル・エージェントとモニタとの間の通信リンクは、要求しているエンティティ、すなわちモニタのプライバシーおよび認証の双方を与えなければならない。そのための理想的なフレームワークはセキュア・ソケット・レイヤー（ＳＳＬ）プロトコルである。ＳＳＬはＮｅｔｓｃａｐｅによって開発されたものであり、インターネット内での顧客とサーバとの間で相互運用可能なセキュリティ用の、特にウェブをベースにした電子商取引用の事実上の基準になっている。ＳＳＬは効果的に破られない公開鍵暗号化方式を利用していずれかの当事者の他の当事者による認証を可能にするハンドウェーキング・プロトコルを定義するものである。
【００９９】
通常は、ＳＳＬはウェブ・トラフィック用の基礎をなすトランスポート機構を構成するＴＣＰ／ＩＰのトップで動作する。しかし、遠隔計測アプリケーションの性質により、ＡＴＰはＵＤＰ／ＩＰスタックを使用する。したがって、ＳＳＬレコードレイヤーの下エッジをＵＤＰトランスポート機構へのインターフェースに適応させなければならない。
【０１００】
図１１はＡＴＰレイヤーとプレゼンテーションレイヤーとの間に導入されたＳＳＬのセキュリティ機構を示しており、プロトコル・データ・ユニット（ＰＤＵ）は特定のデータソースへの個々の要求へとパーズされる。セキュリティレイヤーは無認可の侵入者に対する有効な「ファイヤウォール」として機能する。これは遠隔モニタを認証し、セッションを通して交換される後続のＰＤＵのコンテンツのプライバシーを保つ。ＳＳＬハンドシェーキング・プロトコルとプレゼンテーションレイヤーとの間のインターフェースは情報を要求する認証されたモニタのＩＤによって受信されたＰＤＵの告知に先立ちＳＳＬのための機構を提供する必要がある。
【０１０１】
この機構は後続のデータ交換と共に、図１１のシーケンスによって図示されている。
このシーケンスの個々のステップは下記のように記述することができる。
１．モニタのプレゼンテーションレイヤーはセキュリティレイヤーに対してモバイル・エージェントへの要求を発したい旨を通知する。
【０１０２】
ここで顧客（モニタ）とサーバー（モバイル・エージェント）との間でＳＳＬハンドシェイキングが行われなければならない。
２．ＳＳＬハンドシェイク・レイヤーはＳＳＬレコード・レイヤーに対して、必要なハンドシェイク・メッセージをカプセル化するように要求する。
３．ＳＳＬレコード・レイヤーは他のサイドに非対称暗号化メッセージ（公開鍵暗号）を送信する。
４．ＳＳＬレコード・レイヤーはＳＳＬハンドウェイク・レイヤーに解読されたメッセージを送る。
ステップ２−４は顧客の認証が確立されるまで双方向で反復される。
【０１０３】
５．モニターが認証されると、ＳＳＬはそのＩＤをプレゼンテーション・レイヤーに報告することで、後続の情報要求がユーザー・コンフィギュレーションにしたがって許諾され、または拒絶されることができる。
６．モニタ・サイドのセキュリティ・レイヤーはプレゼンテーション・レイヤーに認証が確認された旨を報告する。
７．モニタのプレゼンテーション・レイヤーはセキュリティ・レイヤーに対してセッションのプライバシー暗号化のためのＰＤＵを送信する。暗号化はＳＳＬハンドシェイキング中に当事者間で交換される（交換のプライバシーをも確保する）対称ワンタイム・キーで実行される。
８．暗号化されたＰＤＵはモバイル・エージェントに「伝送」される。言い換えると、これはモニタのプロトコル・スタックのセッション・レイヤーを経て受け渡される。
９．暗号化されたＰＤＵがモバイル・エージェントのＳＳＬプロトコル・レイヤーに到達すると、これはプレゼンテーション・レイヤーに引き渡される前に解読される。
１０．プレゼンテーション・レイヤーからの応答はＳＳＬレコード・レイヤーに送られる。この応答は次のものでよい。
・モニターによって要求されたデータ
・モニターによって送信されたコマンドが実行されたことの確認、または、
・モニターが要求またはコマンドに必要な権限を有していないことによるコマンドまたは要求の拒絶。
１１．ＳＳＬレコード・レイヤーは、対称セッション鍵で応答を暗号化し、モニタに返送する（すなわち、モバイル・エージェントのセッション・レイヤーから始まるプロトコル・スタックを経て）。
１２．モニターのＳＳＬレコード・レイヤーはＰＤＵを解読し、それをプレゼンテーション・レイヤーへと引き渡す。
【０１０４】
このシーケンスの全部または一部を逆方向で実行してもよいことに留意されたい。モニターがエミッション管理取り締まりエージェンシーを提示し、モバイル・エージェントがこのモニターからの要求を毎年受信して、全ての不履行事象を報告するものと想定する。モバイル・エージェントはプレゼンテーション・レイヤーで肯定応答で返答、すなわち要求を受諾できる。残りの３６５日の期間は、全ての例外条件によってモバイル・エージェントは通信を開始してこれらの条件を報告するようにされる。したがって、要求はモバイル・エージェントから発され、一方、モニターからの応答は例外報告が記録され、持久メモリにログされることを知らせる。（肯定応答がモニタから受信されるまで、これらの例外報告をフラッシュ・メモリに保存するようにＵ−ＯＢＤを構成することができる。それによって、車両が有効範囲内にある場合に発生する例外が確実に「忘れられない」ようにされる。）
【０１０５】
車両対車両の計測方法：ワイヤレスＬＡＮによるアドホックネットワーキング
ＯＢＤ−１ＩＩは、モバイル・サーバーと固定位置顧客から構成される遠隔計測方法の例である。
２台のモバイル車両間における顧客サーバーの関係のケースも念頭におかれる。２台の車両間のデータ・リンクは、ワイヤレスＬＡＮに対してＩＥＥＥ８０２．１１規格のアドホックネットワーキング能力を利用して確立することができる。ワイヤレスＬＡＮ内のアドホックネットワークはアクセスポイントと呼ばれる中央コーディネート・ノードなして作成される。図１２はアドホックワイヤレスＬＡＮとアクセスポイントを有するワイヤレスＬＡＮとの相違を示している。
【０１０６】
異なるスペクトル拡散チャネルを利用することによって、双方の種類のネットワークは同じハードウェア・プラットフォーム上に共存することができる。アクセスポイントは車両に広域ネットワーク（すなわちインターネット）への接続性をもたらすが、アドホックネットワークは要求されない。アドホックネットワークによって車両はその近接車両との論理リンクを確立することができ、これは車両間での重要な運転情報を交換するために利用することができる。
【０１０７】
アドホックネットワークは、各車両がその「隣接」車両とのリアルタイムの画像を保存できるようにする機構を用いて作成することができる。この隣接する車両には順方向と逆方向の双方で５００ヤードに及ぶ車両を含めることができる。各車両内に保存された画像は周囲条件の変化とともにダイナミックに変化する。
【０１０８】
ＡＴＰプロトコル・スタックは遠隔診断顧客と対話するために用いられるのとほぼ同様に車両相互間のメッセージング用に利用できる。相違点は、全ての車両が必ず、かつ自由に情報を交換しなければならないので、セキュリティの制約をこのケースでは適用できないことである。このことは図１３に示されている。
【０１０９】
アプリケーション：安全性対渋滞管理
車両相互間の通信はインテリジェント・トランスポート・システム（ＩＴＤ）用の「プラトーニング」（車群走行）の文脈で経験的に利用されてきた。プラトーニングは、ここで以下に道路上の「クラスター・インテリジェンス」と呼ばれるものの一例であるにすぎない。クラスタとは近接エリヤ内での車両の集合のことである。任意の車両の近接はこれを囲むフルイド・ネットワーク・トポロジーを構成するので、関連するクラスタの構成車両は動的である。
【０１１０】
クラスタ内の情報の交換（もしくは同報通信）は道路の安全性、並びに渋滞の緩和を目指す交通管理の双方に関して価値を有する。ある側面では、これらのエリア間には作為的な相違がある。より良好な交通管理の結果、安全性が高まり、またその逆である必要である。以下のアプリケーション領域の説明はこれらの２つの目的を区別するものではない。
【０１１１】
冗長性
クルーズ制御またはコックピット電子情報システムのようなビークル・オンボード・システムは準方向衝突回避レーダー、並びにアドホック・ネットワーキングを有するＡＴＰによって促進される車両相互間の情報交換を含む多様な入力による恩恵に浴するものである。
【０１１２】
したがってアドホック・ネットワーキングは制御／情報システムへの補助的な入力／サービスのセットを提供するものとみなされる。場合によっては、これらの入力／サービスは互いに相補的である一方、他の場合は互いに重複する。例えば、車両がＩＥＥＥ８０２．１１イネーブルド車両である場合は、すぐ近傍の車両用の近接情報を提供することによってレーダーはアドホック・ネットワーキングを補うことができる。勿論、これらの車両もＩＥＥＥ８０２．１１イネーブルド車両である場合は、この機能性はレーダーの機能と重複する。それによって、特にＩＥＥＥ８０２．１１に準拠したサービスを提供する限界コストが低いので、安全性の増強という目的にとって有益であるに過ぎないある程度の冗長性がもたらされる。
【０１１３】
遠隔オンボード・データ収集のためにモバイル・データ通信の利用度が高まることで、広域ネットワークにわたる車両遠隔計測に関与するモジュールの標準アーキテクチャを可能にする相互運用性に対する必要性が生じてきた。広範な使用の最大の可能性を有するアプリケーションはワイヤレス・オンボード診断（ＯＢＤ−１１１）であるが、車両のメインテナンスおよびトラッキングを含む他の多くのアプリケーションがある。ブリッジおよびルータのようなノードをマネージメント・エンティティによって遠隔診断可能である通信ネットワーク管理のパラダイムによって、遠隔車両診断の適切なモデルが得られる。したがって、シンプル・ネットワーク・マネージメト・プロトコル（ＳＮＭＰ）の仕様は、自動車遠隔計測プロトコル（ＡＴＰ）を導き出すための基盤として新規、かつ予測されない方法で使用される。ＡＴＰはネットワーク内のいずれかの場所に位置するオンボード診断「エージェント」と「モニタ」間の顧客サーバーの関係を可能にするオープン・インターネット環境で動作する。ＳＳＬプロトコルはセキュリティをもたらすためにこの上層に位置している。同じプロトコル・アーキテクチャからセキュリティを除いたものが、インテリジェント・トランスポート・システム（ＩＴＳ）内でのアプリケーション用のＩＥＥＥ８０２．１１に準拠したアドホック・ネットワークの最上層に位置することができる。
【０１１４】
ネットワークの近接性
ネットワーク近接性のコンセプトは、データ・リンク上での近接ノードを特徴付けるために、場所的な意味で用いられるので借用されたものである。ノードＡが通信ブリッジを横断せずにノードＢに到達（伝送）できる場合は、ＡとＢは同じ近接エリヤにあるものと言われる。このことは、ブリッジを介して接続された２つのデータ・リンクを示した図１４に図示されている。右側のデータ・リンクはＩＥＥＥ８０２．３（イーサネット（Ｒ））仕様によって定義されており、これはワイヤード・ローカルエリヤ・ネットワーク（ＬＡＮ）用に広く使用される。左側のデータ・リンクはワイヤレスＬＡＮであるＩＥＥＥ８０２．１１によって規定されている。図１４に示されているように、Ａ、Ｂ、およびＣはワイヤレスＬＡＮ上の近接車両であり、一方、Ｄ、Ｅ、Ｆ、およびＧはワイヤードＬＡＮ上の近接車両である。そのことは図１４には明示されていないものの、ワイヤレスＬＡＮとワイヤードＬＡＮの双方の近接性はノード間の物理的な距離によってではなく、場所的な関係性によって定義される。２つのノードが同じ媒体を共用し、これらの間の信号のクオリティが（エラー・レベルの点で）受け入れられる場合には、これらは場所的に同じ近傍にあり、すなわち隣接しているものである。
【０１１５】
インテリジェント・ハイウェー・ネットワーク近接の場合は、必要ならば隣接性の判定に追加の地理的な判断基準を加えることができる。データ・リンク上の他のノードのＧＰＳ位置報告とそれ自体のＧＰＳ位置とを比較することによって、各ノードは指定された地理的な境界外にあり、車両の運転にとって重要ではない他のノードを選別して排除することができる。
【０１１６】
上記の説明は単一のノードのパースペクティブからＩＴＳ Ｗｉ−Ｆｉ近接の定義まで提示することができる。
ＩＴＳ Ｗｉ−Ｆｉ近接は、共通の物理的媒体（すなわち指定された直接シーケンススペクトル分散チャネル）を共用する周囲のＩＥＥＥ８０２．１１ノード、並びに媒体アクセス制御のためのタイミング・パラメータの集成であり、任意の種類の公共道路上の車両の安全運転にとって重要な相対的な地理的な位置内にある。
【０１１７】
ネットワーク上の登録
ＩＥＥＥ８０２．１１仕様は媒体へのアクセスをコーディネートするための、すなわちチャネル競合を最小限にし、かつ衝突の可能性を低減するためのタイミング同期化機能と関連して用いられるタイミング・パラメータを定義している。ノードは既にネットワークの一部であるノードからの適宜の「登録」フレームを受信するまで、データを搬送するために媒体を仕様することができない。登録フレームには、新たなエントリーが既存のノードと同期化できるようにする時間スタンプを含む、媒体上で適正に動作するのに必要な情報が含まれている。
【０１１８】
８０２．１１では、媒体へのアクセスをコーディネートするために利用される方法は、８０２．３（イーサネット（Ｒ））で使用されているものと同様である衝突回避による搬送波感知多重アクセス／衝突回避方式（ＣＳＭＡ／ＣＡ）と呼ばれている。これは伝送前に搬送波用のチャネルを「スニッフィング（ｓｎｉｆｆｉｎｇ）」するという構想に基づいている。媒体が塞がっている場合は、送信されるデータを有するノードは再試行前にランダムに計算された待機時間に入り、それによってチャネルを待機する多重ノードによる同時的な再試行（およびその結果として、それが発生させる「交通渋滞」）の可能性を最小限にする。
【０１１９】
８０２．１１使用はこれを分散コーディネーション機能（ＤＣＦ）と称している。これはさらに、ポイント・コーディネーション機能（ＰＣＦ）と呼ばれる競合回避機構をも定義している。ＤＣＦはデフォルトの動作モードであるのに対して、ＰＣＦは、オーディオおよびビデオのような時間臨界的な交通の場合のような特定のシナリオを取り扱うために利用できるようにされている。標準的にはＰＣＦは固定アクセス・ポイントを経て提供され、一方、ＩＴＳの場合はロードサイド基地局の形態をとる。
【０１２０】
インターネットにアクセスすることを望む車両は、このアプリケーション用に割り当てられたチャネル（単数または複数）を使用してロードサイド・アクセス・ポイントを登録する。オーディオおよびビデオを流すための、またはＶＯＩＰ（ＩＰを介した音声）用の性能の判断基準には、チャネル管理のためのＰＣＦ方式が必要となることがある。しかし、同じ近接エリヤを共用する車両のアドホック・ネットワークはそのチャネル（単数または複数）を管理するためにＤＣＦを使用する。ＤＣＦは媒体へのアクセスをコーディネートするために「マスター」局の存在に依拠しないので、アドホック・ネットワークは適正に機能するためにロードサイドのインフラを必要としない。
【０１２１】
このことは、ロードサイドのインフラを利用することを排除するものではない。インターネット・アクセスおよび他のサービスがオプションである場合でさえ、基地局はディファレンシャルＧＳＰビーコン、ハイウエー・システムに関する地理的な方位、電子通行料徴収、電子道路標識、および交通情報を含む多様な補助的ＩＴＳ機能のために依然として必要であろう。
【０１２２】
登録機構自体は受動モードまたは能動モードのいずれかで動作することができる。これらの方法の双方を以下に説明する。
受動登録
受動モードでは、ビーコン・フレームのための候補ノードが既存のノードからビーコン・フレームを聞き分ける。アドホック・ネットワークでは、全ての既存のノードはビーコン・フレームを周期的に送信し、ノードがチャネル管理用の既存のノードと同期してネットワークに入れるようにする。ビーコン・フレームは競合がない期間の始まりを信号で伝え、その間に近隣の他の全てのノードが伝送を延期するので、存在を通知したい新たなノードはそうすることができる。ビーコン・フレーム間の間隔と後続の競合がない期間の双方とも、標準的には１−２秒、および１００ミリ秒−０．５秒の範囲にそれぞれ設定される構成可能なパラメータである。しかし、次の項で明らかになるように、特にこれらの設定を不可能にすることがある渋滞がひどいハイウェイ条件では、同じ近接エリヤに数百台の車両がある場合がある。ビーコン・フレーム間の間隔を増すことは解決方法の一部であるに過ぎない。図１５は、各々が１００ミリ秒の競合がない期間の始まりを通知するビーコン・フレームを１００台おきの車両が１０秒間隔で送信する場合は、いずれかのユーザ・データを送信するための時間は１０秒の間には残されないことを示している。
【０１２３】
完全な解決方法は、ＩＴＳのアドホック・ネットワーク・ノードは８０２．１１の媒体アクセス・コントロール（ＭＡＣ）レイヤーに規定されている連係および認証の論理的な管理機能のいずれかを交渉する必要がないという事実にある。連係とは、１つのノードが他のノードからの明示的な認識を要求する機構である。インフラストラクチャ・ネットワークでは、要求は要求するノードのアドレスをローカル・テーブル内に記憶し、応答フレームを送信するアクセス・ポイントに送られる。アクセス・ポイントによって保存されるアドレス・テーブルは、特定のアドレスを宛て先とするパケットが実際に送信されたか否かを制御する。そのアドレスに付いて連係が確立されない場合は、それにはユーザ・データは送信されない。
【０１２４】
しかし、近接の発見の項で説明されているように、ＩＴＳアドホック・ネットワーク内のほとんどのユーザ・データは、連係が必要ない同報通信アドレス（すなわちすべてのノード）に送信される。アプリケーションには周囲の車両との連係が必要であるが、物理的に隣接した車両との連係だけがあるアプリケーションもある。各ノードは、これらの近接車両の運転指針がユニキャスト・メッセージを保証するのに充分意義がある（すなわち特定の宛て先ノードにアドレス指定された）規定の境界内にある近接車両との連係だけを交渉する必要がある。各ノードは連係の必要がある近接車両からはるかに多くのビーコン・フレームを受信するので、これらのビコーン・フレームの後に続く競合がない期間は基本的に無駄になる。帯域幅を確保するために、競合がない期間は最小限の可能な値（すなわち１ミリ秒）に短縮されるべきであり、連係の交渉はビーコン・フレームの受信によってトリガされるのではなく、次項に記載されている発見プロセスを介して決定される条件によってトリガされるべきものである。
【０１２５】
認証とは要求ノードに対称暗号化鍵を使用して通信する許可が授与されるプロセスである。ＩＴＳアドホック・ネットワークでは、認証は必要ないばかりではなく、全ての当事者が制約なく、必ず、また自由に情報を交換しなければならないので、車両のプラトーニング、もしくは「クラスター・インテリジェンス」のコンセプトとは正反対である。
【０１２６】
能動登録
能動登録方式によって候補ノードは、基本的に他のいずれかのノードが応答する「ピング」要求であるプローブ・フレームを送信することが可能になる。アドホック・ネットワーク・トポロジーでは、常に存在することに依存できる（すなわち固定アクセス・ポイント）単一のノードがないので、プローブは全てのリスナーに同報通信されなければならない。ＩＥＥＥ８０２．１１規則は、プローブに対銑応答は最前のビーコン・フレームを送信したノードによって送信されるものとしている。
【０１２７】
能動登録の機能によって、ビーコン・フレームの送信によって帯域幅の利用を最小限にすることが可能になる。ビーコン・フレーム間の間隔が６０秒に構成されているものと想定しよう。各ビーコン・フレーム後の競合なし期間は僅か１ミリ秒であるので、５台の車両のプラトーン（車群走行）はビーコン・フレームの同報通信のために利用できる時間の約０．０１％を利用し、５００台の車両のプラトーンは僅か１％しか利用しない。
【０１２８】
図１６ａおよび１６ｂには車両が５台の場合のシナリオが示されている。ビーコン・フレーム間の平均時間は１２秒である。プラトーン内の各車両はビーコン・フレームを送信するための順番位置にしたがって番号付けされる。アクセス・ランプに入った車両６は、車両４がビーコン・フレームを送信した後、新たなアドホック・ネットワークを発見するためにプローブ要求フレームの送信を開始する。車両４はほぼ即座にプローブ応答で応答する。
【０１２９】
近接性の発見
近接発見の機構は動的なトポロジーでネットワーク環境内のデータ・トラフィックを経路指定するために使用される近接発見プロトコルのコンセプトに匹敵し得るものである。この方法は以前説明したように地理的な要素を組入れた非送信請求近接広告（ｕｎｓｏｌｉｃｉｔｅｄ ｎｅｉｇｈｂｏｒ ａｄｖｅｒｔｉｓｅｍｅｎｔｓ）に基づくものである。これらは緯度、経度、速度、および車頭方向を含むＧＳＰ情報を含む、各ノードが同報通信する周期的なメッセージである。
【０１３０】
近接広告は、近接している現在の構成の「画像」をメモリ内に設定するためにアドホック・ネットワーク内の各ノードによって使用される。図１７はこのコンセプトを図示しており、追い越し車線内の第２の車両によって形成される近接車両画像を示している。
【０１３１】
発見サイクルと呼ばれる同報通信間の時間間隔は、各近接車両の相対位置に関して正確な近接車両の画像を保持するのに充分に頻繁でなければならない。互いに地理的に隣接した２つのノードの相対位置に関するＧＰＳ報告の精度は、衛星信号の処理に特有のエラーが全てのノードに等しく影響するので、完全なＧＰＳ報告の精度よりも大幅に高い。したがって、各ノードの相互の相対位置は理論的には基本的にエラーを含まず、車両が衝突回避およびプラトーニングのタスクに有効な精密度のレベルで双方の距離を判定できるものでなければならない。例えば、７０マイル／時で走行する車両の位置は１００フィート／秒以上も変化する。このことは、精度を保つために毎秒数回の更新が必要であることを示唆している。しかし、更新の頻度は、チャネルの競合を回避するために、発見サイクル中に生成されるデータ・トラフィック量によって制約される。一方、これはＲＦ範囲内にある車両数、すなわち近接車両の密度の関数である。
【０１３２】
しかし、これらの変数の全てには循環の関係があることを認識する必要がある。近接車両密度は周囲の車両の平均速度の関数である。速度が速いほど、近接車両密度は少ない。したがって、より多くの更新頻度を許容する発見サイクル内のデータ・トラフィック量はより少ない。
【０１３３】
これは例示することができる。７０メートル／時では、安全停止距離は約２００フィートである。全ての車両が推奨停止距離を遵守し、最大ＲＦ範囲が３０００フィート、および同じ方向で最大４車線であると想定した場合、周囲の近接エリヤは最大６０台の車両を含むことができる。
【０１３４】
スペクトル拡散チャネルを介して送信される総トラフィック量を判定するため、先ず各発見パケットの全サイズを設定しなければならない。これは物理レイヤーからセッション（ＡＴＰ）レイヤーまでのプロトコル・スタックを図示した図１８に示されている。データ・リンクレイヤー（ＩＥＥＥ８０２論理リンク・コントロール）の上方の全ての必要なユーザー情報を８バイトに圧縮できるものと予期される。その結果は６４バイトの物理レイヤー収縮手順（ＰＬＣＰ）サブレーヤーのフレーム・サイズである。したがって、発見サイクルにおける総トラフィック量は、
６４ｘ６４＝３８４０バイト、もしくは３０，７７０ビットである。
【０１３５】
１１Ｍｂｐｓでは、スペクトル分散チャネルのデータ伝送速度は１秒間隔内で幾つかの発見サイクルをサポートでき、このような比較的多数のノードの場合のチャネル競合に起因する処理能力のある程度の劣化をも許容するものである必要がある。
【０１３６】
この変化を補償するため、「クラスター・インテリジェンス」の事象待ち行列には、最前の同報通信で報告された速度と車頭方向に基づいて、近接している全ての車両の位置の更新を駆動する周期的なタイマーが含まれている必要がある。
【０１３７】
近接広告のフィルタリング
各ノードは、車両の安全運転に対する影響の可能性を有するのに充分に近接した近接車両だけが含まれるように、隣接車両の密度を制限することができる。この境界を越えたノードを選別して除外することによって、メモリ内の近接「オブジェクト」の集成のサイズが限定され、これらのオブジェクトに所属する任意の状態変数を周期的に更新するのに必要な処理量が制限される。
【０１３８】
メッセージ圧縮
ＧＰＳ発見メッセージは８バイトに圧縮できることは既に述べたとおりである。これは緯度と経度の双方の最下位の２バイトだけを組入れることによって達成される。これらの２バイトは表示値のマイナス部分の少数部分を表す。これで充分であるのは、緯度また経度の１分は、０．５キロメートルの最大ＲＦ範囲を優に越える１マイル以上であるからである。したがって、受信ノードは緯度と経度の双方について独自のＧＰＳ位置の度と分を置き換えることによって、送信ノードのＧＰＳ位置を容易に再構成できる。これは計測境界の適宜の近傍でこれらの値を増分または減分も行わなければならない。例えば、受信ノードの緯度が４３度５６．９９８２分であり、一方、受信されたメッセージが０．００５３分の小数値を示す場合は、置き換えられる分の値は５６ではなく５７である。
【０１３９】
図１９は、完全なＧＰＳ発見メッセージのフォーマットを示している。速度は０から２５５（１バイト）の、また車頭方向は７ビットの少数度を伴う０−３６０（９ビット）の整数値である。最上位ビット内の先頭のバイトは、次の発見サイクルで同報通信用に送信局によって使用されるべきチャネルを示している。これは以下の項で説明される。先頭のバイトの他のビットは後に使用されるために確保される。
【０１４０】
Ｗｉ−Ｆｉチャネル選択
モバイルのアプリケーション用の８０２．１１仕様は、妨害なく同時に動作可能である直接拡散型系列（ＤＳＳ）の少なくとも３チャネルを要求している。しかし、送信機のソフトウェア・ベースの構造によって、より低いデータ伝送速度でより多くのチャネルを得ることができる。例えば、高速インターネット・アクセス用に単一の１１Ｍｂｐｓのチャネルを割り当てることによって、残りの帯域幅から少なくとも２Ｍｂｐｓのより多くのチャネルを得ることができる。それによって、モバイル・ノードはロードサイドのアクセス・ポイントを利用するインフラ・ベースのデータ・トラフィックからアドホック・ネットワーキングのデータ・トラフィックを分離することが可能になる。媒体の反対側にある車両間の通信は必要ないので、各ノードが、同じ方向に進行する他の全てのノードによって発見メッセージを同報通信するために使用されるチャネルを監視するために充分である。
【０１４１】
反対方向に進行する車両間の不要なチャネル競合を回避するために、発見同報通信のためのチャネル選択は、ヘッディング（先端の進行方向）に基づいて決定することができる。簡単な方式は、アドホック・ネットワーキング用に１０チャネルのうちの４チャネルを割り当て、コンパスを４象限に分割することであろう。　しかし、図２０に示すように、これは、道路の僅かなカーブによって、先行車両がはもはや送信しないチャネルを後続車両が聞いている場合には、対応できない。これは、次のメッセージがどのチャネルで送信されるかに関して近接車両に表示するように、発見メッセージにフラグをたてることによって解決できる。
【０１４２】
言い換えると、車両がその車頭を異なる象限に移動させたことを検知すると、車両が対応するチャネル上で直ちに送信を開始しないようにする。次のメッセージは現在のチャネルで送信されるが、全てのリスナーには後続のメッセージで使用される予定のチャネルがアドバイスされる。後続の車両だけが新たなチャネルを監視するように切換えられるのである。車両が車両の前方からチャネル・フラグの変更を受信する前に車頭の変更を検出した場合も切換えられる。
【０１４３】
この車両は、それが送信するチャネルとは異なるチャルを監視できる遷移段階に入る。この期間中に、次に続く車両が、「古い」（すなわち道路のカーブの前の）チャネルで送信する近接車両だけからメッセージを受信する。これは発見メッセージを受信しない。もっとも重要な点は、プラトーンの前方の数台の車両からのいずれかの非同期的な事象報告を受信しないことである。これを補償するため、前方の車両から「次のチャネル」フラグを受信するので、「古い」チャネルと「新たな」チャネルの双方を継続的に走査する必要がある。
【０１４４】
近接性の変更
車両が近接性を変更する条件を設定するため、前に記載したＩＴＳ Ｗｉ−Ｆｉ近接性の定義を参照する。近接性は共用媒体に変化が生ずると変化する。このような変更の例は既に記載したが、道路の先が新たなコンパス象限に移行し、新たなプラトーンのＷｉ−Ｆｉチャネルへの段階的な遷移がある場合である。
【０１４５】
この問題に対処するため、以下の疑問に答える必要がある。すなわち、車両はそれが詳細なディジタル地図を利用する必要なく高速道路に入ることをどのようにして判断するかである。車両が高速道路に入る他の車両に追従する場合は、答えは簡単である。それは先行車両の問題である！後続車両は現在のチャネルを監視して、先行車両から「次のチャネル」フラグを見いだすだけでよい。勿論、これは、先行車両に問題を転化し、その上、現在近接にある先行車両がない場合のシナリオに対処するものではないので、それは安易な解決方法である。
【０１４６】
回答はプローブ・フレームを使用した能動ネットワーク登録の機構によって与えられる。車両がその前方に車両がないことを検知すると、車両はその現在の車頭があるコンパスの象限に割り当てられたどの４チャネルのプローブをも開始しなければならない。車両が新たなチャネル上のあるノードからの応答を受信するまで、車両は分割されない高速道路および市街路用に使用される既存のチャネルの監視を継続する必要がある。２つの可能性の一方が生ずる。
・新たな近接車両が発見される（既存チャネル上の発見機構を介して）。これは同方向、または接近方向のいずれかを移動中であろう。それらの位置は、車両が高速道路へのアクセス・ランプ上にある可能性を排除する。この場合は、車両は周期的なプローブを中止する。
・プローブ応答が新たなチャネル上で受信される。車両はチャネル切換えの準備を行わなければならず、その現在の近接車両に対して、次の発見メッセージ内に「次のチャネル」フラグを設定することによって、切換え準備していることを通知しなければならない。
このシナリオは、車両が分割された高速道路を出る場合は逆になる。
【０１４７】
サービス広告
専用のノードが、帯域幅に関して非送信請求の態様で同報通信するにはコストがかかる情報の流れを提供できる場合があり得る。その代わりに、これらのノードは、全てのリスナーに対して、要求があればサービスを利用できる旨を通知するメッセージを周期的に同報通信することによって、これらのサービスを利用できることを広告することができる。その例は、車両のボードに搭載されたディジタル・ビデオカメラ、または交通信号灯があろう。
【０１４８】
アプリケーション
安全性対競合の管理
ＩＴＳタスクへのアドホック・ネットワークのアプリケーションは、道路の安全性、並びに渋滞の軽減を目指す交通管理の双方に関して価値を有している。ある側面では、これらのエリヤ間には作為的な区別がある。交通管理がより良好ならば安全性も高まり、逆も同様である。以下のアプリケーション・エリヤの説明はこれらの２つの目的を区別するものではない。
【０１４９】
事象の通知
アドホックＩＴＳネットワークに関与する全てのノードは、加速、ブレーキの適用、ターン、または車両変更等のような近接車両にとって重要などのような運転事象をも近接車両に知らせる必要がある。これらの事象は同報通信アドレスに送信される非対称通知として報告される必要がある。言い換えると、利いているどの近接車両も事象のリアルタイムの通知を受けなければならない。例えば、フットブレーキをかけることは、後方の後続車両だけにではなく、後続のプラトーン内の他の全ての車両にも報告されなければならない。ブレーキ・ランプ（作動している場合）への反応時間は標準的には０．５秒の範囲にある。したがって、７台の車両のプラトーンの先頭の車両がフットブレーキをかけた場合は、プラトーンの最後尾の車両は、その前の車両のブレーキ・ランプを見る３秒も前に通知を受けることができる。
【０１５０】
全ての非対称事象通知はｎ回まで反復される必要があり、但しｎはＩＥＥＥ８０２．１１　ＭＩＢ（マネージメント・インフォメーション・ベース）の構成可能なパラメータである。事象通知の反復によって、（Ｗｉ−Ｆｉチャネル選択の項に記載された遷移段階中に）１チャネル以上を聞く必要がある後続の近接車両がメッセージを聞く機会が確実なものになる。
【０１５１】
意図の通知
アドホック・ネットワークによって、運転指針に関する車両の意図の通知手段が得られる。通知の受信者からの明示的な肯定応答を必要とするこのような通知の等級を指定することができる。（ＬＬＣレイヤーの肯定応答無接続サービス）。これらはＡＴＰ顧客・サービスを利用することによって発されることができる設定コマンドに対応する。これらの通知に肯定応答することによって、受信者は送信者に対して、送信者の意図を「承知」したことを通報する。双方の当事者の知識の状態は次に、それぞれの制御またはコックピット電子情報システムへの入力となることができる。
【０１５２】
追い越し
図２１はアドホック・ネットワーキングによって補助されることができる運転指針の例を示している。追い越し車両内の車両Ａの速度は、低速車両内の車両Ｂの速度よりも速い。Ａは、それ自体の速度と、Ｂの近接位置とを利用して、Ｂを追い越すまでにどの程度の時間が残されているかを判断することができる。残り時間が事前通知に必要な期間（△τ）に等しい場合は、ＡはＢに対して左から追い越す意図があることの通知を含むユニキャスト・フレームを送信する。Ｂが肯定応答で応答した場合は、そこでＡは追い越される車両がその意図を「承知している」ことの確認を伴う適宜の制御情報、もしくはドライバー情報を提供することができる。
【０１５３】
車線変更
車線変更の意図は追い越し意図と同様に通知され、肯定応答されることができる。車線変更を準備している車両はその通知を、変更したい車両にいる最も近い後続車両に発する。この場合も、双方とも運転指針を承知し、その準備をする。
【０１５４】
合流／車線譲り
アドホック・ネットワーキングの最も関心を引くアプリケーションの１つは、高速道路での車線合流とアンセス・ランプでの車線譲り、および車線接近である。図２２に示すように、高速車両と合流車両は双方とも互いの位置と速度を承知しており、それによって、新たな条件にスムーズに調整する上でドライバーを補助する入力と共に、それぞれのコックピット電子情報システムが提供される。
【０１５５】
インテリジェント交通信号／ハイウエー情報システム
同時的なアドホック・ネットワーキングおよびインフラをベースにした通信をサポートするためのＷｉ−Ｆｉの能力については前述した。インテリジェント交通灯はロードサイドのインフラの一部であるが、これらは有効であるためにはアドホック・ネットワーキングに割り当てられたチャネルを使用する必要であろう。何故ならば、車両によって規則的に監視されるのがこれらのチャネルだけだからである。Ｗｉ−Ｆｉを利用して、インテリジェント交通灯は、例えば、
・接近車両に「黄色ランプ」通知を送信し、
・高速で接近する交通の横断方向の車両に警報を発し、
・赤ランプで走行中の車両を識別することができよう。
【０１５６】
これに対して、ハイウエー情報システム（電子信号、自動通行料金徴収等）は（最も渋滞した運転状態の下でも実質的な帯域幅が残っているものと判定できない限りは）アドホック・チャネルでは動作されるべきではない。車両はこれらのインフラストラクチャ・チャネルをドライバー入力機能によって開始、終了されたものとして監視することができよう。
【０１５７】
（参考文献）
以下に示す各参考文献は、参考として本明細書に包含される。
［１］　ジェー．ディー．ケース、エム．フェドール、エム．エル．ショッフストール、及びシー．デビン　氏らの「単純ネットワーク管理プロトコル（ＳＮＭＰ）」１９９０年５月、コンピュータサイエンスのためのパーフォーマンス　システムズ　インターナショナル及びＭＩＴ研究所の、ＳＮＭＰリサーチ、ＲＦＣ１１５７
［２］　情報処理システム−オープンシステムズ　インターコネクション、「抽象シンタックス表示法　１（ＡＳＮ．１）」、国際標準化機構、国際標準　８８２４、１９８７年１２月、（［３］　情報処理システム−オープンシステムズ　インターコネクション、「抽象表示法　１用の基本エンコードディング規則の仕様書（ＡＳＮ．１）」、インターナショナル
［４］　エイ．オー．フライヤー、ピー．カールトン、ピー．シー．コーヒェ、等の「ＳＳＬプロトコル、バーション３．０」ネットスケープ通信、インターネットドラフト、１９９６年３月、
［５］　インターネット　エンジニアリング　タスク　フォース、パーキンズ、シー．　（編集）の「ＩＰｖ６　モビリティー　サポート」１９９５年３月、
［６］　ナルテン、ティー．、ノルドマーク、イー．　及びダブリュ．シンプソン等の「ＩＰバーション６（Ｉｐｖ６）用のネイバー　ディスカバリー」ＲＥＣ　１９７０年、１９９６年８月、
［７］ ディーリング、エス．及びヒンデン、アール．の「インターネット　プロトコル　バージョン６（Ｉｐｖ６）用の仕様書」ＲＦＣ１８８３　１９９５年１２月
［８］ コンタ、エイ．及びディーリング、エス．の「インターネット　プロトコル　バージョン６（Ｉｐｖ６）用の仕様書のためのインターネット制御メッセージプロトコル（ＩＣＭＰｖ６）」ＲＦＣ１８８５　１９９５年１２月
【図面の簡単な説明】
【図１】
図１は、プロトコルスタックの概略図である。
【図２】
図２は、ＵＤＰベースのプロトコルの概略図である。
【図３】
図３は、ＴＰＣベースのプロトコルの概略図である。
【図４】
図４は、ＵＤＰベースのプロトコルにおけるヘッダの概略図である。
【図５ａ】
図５ａは、２つのネットワーク装置のそれぞれの概略図である。
【図５ｂ】
図５ｂは、２つのネットワーク装置のそれぞれの概略図である。
【図６】
図６は、ＳＮＭＰプロトコルデータユニットの概略図である。
【図７】
図７は、データグラム交換の概略シーケンス図である。
【図８】
図８は、ＧＥＴプロトコルデータユニット例の概略図である。
【図９】
図９は、ＳＮＭＰのＭＩＢ階層の概略図である。
【図１０】
図１０は、ＤＩＢ階層の一部分を示す概略図である。
【図１１】
図１１は、メッセージシーケンスの概略図である。
【図１２】
図１２は、ネットワークの概略図である。
【図１３】
図１３は、図１２のネットワークを用いてデータ交換するためのプロトコルスタックの概略図である。
【図１４】
図１４は、別のネットワークの概略図である。
【図１５】
図１５は、ビーコンフレームシーケンスの時間プロットを示す図である。
【図１６ａ】
図１６ａは、アドホックネットワークの一部分を示す概略図である。
【図１６ｂ】
図１６ｂは、図１６ａのネットワークにおいて車両により出力されるビーコンフレームの時間プロットを示す概略図である。
【図１７】
図１７は、別のアドホックネットワークの概略図である。
【図１８】
図１８は、別のプロトコルスタックの概略図である。
【図１９】
図１９は、別のプロトコルデータユニットの概略図である。
【図２０】
図２０は、４分割されたハイウェイセグメントの概略図である。
【図２１】
図２１は、運転操縦中のデータ交換の概略図である。
【図２２】
図２２は、別の運転操縦中のデータ交換の概略図である。
【図１】
2004511188.tif 000005
【図２】
2004511188.tif 000006
【図３】
2004511188.tif 000007
【図４】
2004511188.tif 000008
【図５ａ】
2004511188.tif 000009
【図５ｂ】
2004511188.tif 000010
【図６】
2004511188.tif 000011
【図７】
2004511188.tif 000012
【図８】
2004511188.tif 000013
【図９】
2004511188.tif 000014
【図１０】
2004511188.tif 000015
【図１１】
2004511188.tif 000016
【図１２】
2004511188.tif 000017
【図１３】
2004511188.tif 000018
【図１５】
2004511188.tif 000019
【図１６ｂ】
2004511188.tif 000020
【図１８】
2004511188.tif 000021
【図１９】
2004511188.tif 000022
【図２０】
2004511188.tif 000023
【図２１】
2004511188.tif 000024
【国際公開パンフレット】
2004511188.tif 000025
2004511188.tif 000026
2004511188.tif 000027
2004511188.tif 000028
2004511188.tif 000029
2004511188.tif 000030
2004511188.tif 000031
2004511188.tif 000032
2004511188.tif 000033
2004511188.tif 000034
2004511188.tif 000035
2004511188.tif 000036
2004511188.tif 000037
2004511188.tif 000038
2004511188.tif 000039
2004511188.tif 000040
2004511188.tif 000041
2004511188.tif 000042
2004511188.tif 000043
2004511188.tif 000044
2004511188.tif 000045
2004511188.tif 000046
2004511188.tif 000047
2004511188.tif 000048
2004511188.tif 000049
2004511188.tif 000050
2004511188.tif 000051
2004511188.tif 000052
2004511188.tif 000053
2004511188.tif 000054
2004511188.tif 000055
2004511188.tif 000056
2004511188.tif 000057
2004511188.tif 000058
2004511188.tif 000059
2004511188.tif 000060
2004511188.tif 000061
2004511188.tif 000062
2004511188.tif 000063
2004511188.tif 000064
2004511188.tif 000065
2004511188.tif 000066
2004511188.tif 000067
2004511188.tif 000068
2004511188.tif 000069
2004511188.tif 000070
2004511188.tif 000071
2004511188.tif 000072
2004511188.tif 000073
2004511188.tif 000074
2004511188.tif 000075
2004511188.tif 000076
2004511188.tif 000077
2004511188.tif 000078
2004511188.tif 000079
2004511188.tif 000080
2004511188.tif 000081
2004511188.tif 000082
2004511188.tif 000083
2004511188.tif 000084
2004511188.tif 000085
2004511188.tif 000086
2004511188.tif 000087
2004511188.tif 000088
2004511188.tif 000089
2004511188.tif 000090
2004511188.tif 000091
2004511188.tif 000092
2004511188.tif 000093
2004511188.tif 000094
2004511188.tif 000095
2004511188.tif 000096
2004511188.tif 000097
2004511188.tif 000098
2004511188.tif 000099
2004511188.tif 000100
2004511188.tif 000101
2004511188.tif 000102
2004511188.tif 000103
2004511188.tif 000104
2004511188.tif 000105
2004511188.tif 000106
【国際公開パンフレット（コレクトバージョン）】
2004511188.tif 000107
2004511188.tif 000108
【国際調査報告】
2004511188.tif 000109
2004511188.tif 000110