JP7481412B2 - クライアントデバイスによる無線アクセス乗物環境消費へのアクセスを認証、認可し、クライアントデバイスによる無線アクセス乗物環境消費を会計するシステム - Google Patents

Description

関連出願
以下の各出願は、出願時に提出された原著論文を含め、全体的に参照により本明細書に援用される：
ｉ）２０１６年７月１日付けで出願された米国仮特許出願第６２／３５７，５０４号；
ｉｉ）２０１７年６月３０日付けで出願されたＰＣＴ特許出願第ＰＣＴ／ＩＢ２０１７／０５３９８１号；
ｉｉｉ）２０１７年６月３０日付けで出願された米国特許出願第１５／６３９，０２２号。

２０１６年１月、アメリカ合衆国運輸長官は、米国運輸省（ＵＳＤＯＴ）が専用狭域通信（ＤＳＲＣ）と呼ばれる車々間（Ｖ２Ｖ）通信技術に基づいて米連邦自動車安全基準（ＦＭＶＳＳ）１５０を進めると発表した。ＤＳＲＣは、以前はＦＣＣにより広範囲の高度道路交通システム（ＩＴＳ）用途のサポートに割り当てられていた５．９ＧＨｚを中心とした７５ＭＨｚ周波数帯域にわたり動作する。２００２年から２００９年の期間中、ＩＥＥＥは、７つのチャネルに分割され、それぞれが１０ＭＨｚ幅を有する帯域の使用を支配する１６０９スイートのプロトコル仕様を開発した。チャネルのうちの４つはＩＰｖ６（インターネットプロトコルバージョン６）インターフェースをサポートし、ＵＤＰ／ＩＰｖ６又はＴＣＰ／ＩＰｖ６ベースのアプリケーションソフトウェアがこれらのチャネルにわたり動作することができることを意味する。

無線アクセス車両環境（ＷＡＶＥ）として一般に知られ、参照により本明細書に援用されるＩＥＥＥ１６０９スイートに含まれるプロトコル仕様は、路側機器（ＲＳＥ：roadside equipment）との通信を試みるＷＡＶＥ対応車載機器（ＯＢＥ：on-board equipment）の認証を保証するセキュリティプロビジョンを組み込んでいる。ＯＢＥ及びＲＳＥという用語はＯＢＵ（車載ユニット（On-board unit））及びＲＳＵ（路側ユニット（roadside unit））と一般に同義である。ＯＢＵは通常、限定ではなく、ＳＡＥ Ｊ２９４５／１及びＳＡＥ Ｊ２９４５／２に指定されているＶ２Ｖの要件又はＳＡＥ Ｊ２９４５の将来の変形において指定されるＶ２Ｐの要件を満たす、ＤＳＲＣ通信が可能なモバイル計算デバイスを含む。ＲＳＵは通常、限定ではなく、ＤＳＲＣ通信が可能であり、ＤＳＲＣ ＭＡＣ及びＰＨＹ層についてＩＥＥＥ８０２．１１ｐ仕様、ＷＡＶＥプロトコルスタックに準拠し、ＤＳＲＣ制御チャネル（ＣＣＨ）でＷＡＶＥサービスアドバタイズメント（ＷＳＡ：WAVE Service Advertisements）をブロードキャスト可能な静止又は準静止計算デバイスを含む。有効なセキュリティクレデンシャルなしのＯＢＵデバイスは、ＲＳＵのＷＳＡを事実上拒絶され得、これは通常、ＯＢＵによって送信された送信を単に破棄することによって達成される。ＷＳＡは、ネットワークで利用可能なサービスを識別する、ＩＥＥＥ１６０９プロトコルスイートによって定義される定期的なメッセージである。

ＩＥＥＥ１６０９プロトコルに存在するこれらの上述したセキュリティプロビジョンは、ＲＳＵに常駐するサービス又はＲＳＵにおける専用アプリケーションソフトウェアを通してＲＳＵにアクセス可能なサービス；すなわち、ＲＳＵが「認識」しており、ＲＳＵがアクセス制御のポリシー責任を有するサービスへのアクセスの制御を目的としている。そのようなサービスの例には、限定ではなく、トラベラー情報、車両内サイネージ、ナビゲーション、交通管理、天気情報、安全、電子支払い、ネットワークサービス、及び構成管理等がある。

ＩＰｖ６通信の場合、ＲＳＵの役割は、ＩＰｖ６データグラムを宛先アドレスに向けてルーティングすることである。ＷＡＶＥアーキテクチャは、ＯＢＵから発せられたＷＡＶＥショートメッセージプロトコル（ＷＳＭＰ）メッセージのヘッダにおけるデジタル署名に基づいてＯＢＵの認証を提供する。デジタル署名は、非対称暗号化技法に従ってＯＢＵによって生成され、送信されるメッセージは、受信側ＲＳＵが署名を復号化することができるように、公開鍵を含む証明書も含む。ＤＳＲＣ基盤機関（「基盤機関」）は、証明書取り消しリストをＲＳＵに伝搬し得、このリストは、セキュリティクレデンシャルがもはや有効ではないＯＢＵデバイスを識別する。これは、ＷＳＭＰを使用して送信されたＯＢＵメッセージを破棄する基準としてＲＳＵにより使用することができる。

参照により本明細書に援用される米国特許出願第１４／１５１，０３５号には、スマートフォン又はタブレット等のユーザインターフェースデバイスが、ルータ発見についてＲＦＣ４８６１に定義されるメカニズムを使用することによってインターネットへの接続を確立できるようにするシステムが開示されている。このメカニズムにより、ユーザデバイスは、例えばWiFiピアツーピア（WiFiダイレクト）インターフェースを通してステートレスアドレス自動設定（ＳＬＡＡＣ）を使用してＯＢＵにそれ自体をアタッチすることができる。ＯＢＵは、ユーザデバイスが、この目的で１つ又は複数のＷＡＶＥサービスチャネルの可用性を広告する任意のＲＳＵを通してインターネットと接続するＩＰｖ６ルータとして機能する。システムは、ユーザデバイスを認証する方法の基礎も提供する。

概要
一態様において、ＲＳＵ基盤オペレータが、ＷＡＶＥサービスチャネルを使用して車両内デバイスによる無線帯域幅消費をデバイス単位で定量化できるようにするために必要な認証、認可、及び会計（ＡＡＡ）機能を実行するシステム及び方法が開示される。

別の態様は、複数のモバイルデバイス及び／又は１つ又は複数のモバイルデバイスのサブネットを動作させるＯＢＵ、複数のＲＳＵとインターネットを通して通信して、認証、認可、及び会計（ＡＡＡ）を実行し、それにより、機関が、ＡＡＡサーバにより適切にプロビジョニングされた各モバイルデバイスによるＷＡＶＥサービスチャネル帯域幅消費を会計できるようにするよう構成された少なくとも１つのコンピュータプログラムを実行する少なくとも１つのプロセッサを有する、ＤＳＲＣ基盤機関により又はＤＳＲＣ基盤機関の代理として動作するＡＡＡサーバを提供する。

別の態様は、ＤＳＲＣ基盤機関により又はＤＳＲＣ基盤機関の代理として動作する複数のＡＡＡサーバであって、各サーバは、インターネットを通して複数のモバイルデバイス及び複数のＲＳＵと通信して、認証、認可、及び会計を実行するように構成された少なくとも１つのコンピュータプログラムを実行する少なくとも１つのプロセッサを有し、複数のＡＡＡサーバは、インバウンドインターネットトラフィックの負荷平衡のために配列化され、機関が、１つのデータベースにおいて適切にプロビジョニングされた各モバイルデバイス及び／又はモバイルデバイスの１つ又は複数のサブネットを動作させるＯＢＵによるＷＡＶＥサービスチャネル帯域幅消費を会計できるようにし、データベースへのアクセスは複数のＡＡＡサーバ間で同期される、複数のＡＡＡサーバを提供する。

別の態様は、拡張ＩＰｖ６管理情報ベース（ＭＩＢ）が構成され、クライアントデバイス毎のＷＡＶＥサービスチャネル使用のパケット及びバイトカウント統計を特定するように動作可能なＲＳＵを提供する。クライアントデバイスは、ＯＢＵ、ＯＢＵを通してＩＰｖ６到達可能な非ＤＳＲＣモバイルデバイス、又はＤＳＲＣ対応ユーザデバイスであり得る。ＩＰｖ６ ＭＩＢはまた、モバイルＩＰｖ６のルート最適化モードで動作しているＩＰｖ６ノードから受信する各データグラムについて、データグラムのモバイルＩＰｖ６ルーティングヘッダにおいて搬送されるモバイルノードの固定「ホームアドレス」を検索するように動作可能である。ＲＳＵは、不揮発性ランダムアクセスメモリ（ＮＯＶＲＡＭ）に、クライアントデバイス毎にＷＡＶＥサービスチャネル使用のパケット及びバイトカウント統計を蓄積するように動作可能であり、ＵＤＰ／ＩＰメッセージにカプセル化された統計をＡＡＡサーバに定期的に送信し、ＡＡＡサーバがＵＤＰ／ＩＰメッセージの受信を肯定応答した場合のみＮＯＶＲＡＭテーブルをリフレッシュする。

別の態様は、ＷＡＶＥ及びＩＥＥＥ８０２．１１ｐに準拠し、デュアル無線機能を構成可能であり、近傍非ＤＳＲＣモバイルデバイスの代理として又はそれ自体のためにインターネットにＩＰｖ６接続するためにＡＡＡサーバから認証及び認可を要求するように構成された少なくとも１つのアプリケーションレベルコンピュータプログラムを実行し、新しいエントリがルーティングテーブルに挿入された場合、ＳＮＭＰ ＧＥＴに基づく同期方法を使用してルーティングテーブルを定期的に検索するか、又はＳＮＭＰ ＴＲＡＰに基づく非同期方法を使用して、ルーティングテーブルにおける「リアルタイム」変化を報告して、近傍デバイスのアドレスを検索するように動作可能な拡張ＩＰｖ６ ＭＩＢが構成されるＯＢＵを提供する。本発明から逸脱せずに、ルーティングテーブルの更新に他の方法を実施することも可能なことを理解されたい。

別の態様は、ＳＳＬ又は手動認証及び鍵交換の同様のハンドシェークプロトコルを用いて確立された対称暗号化通信チャネルを使用してＡＡＡサーバから「インターネットサブスクリプション」クレデンシャルを要求するように動作可能であり、本明細書における１つ又は複数の例示的な実施形態又は態様により定義されるように、ＡＡＡサーバから受信される認証チャレンジメッセージに応答する場合、「インターネットサブスクリプション」クレデンシャルを使用するように動作可能な非ＤＳＲＣモバイルデバイスを提供する。

本発明の他の目的、特徴、及び利点は、添付図面と併せて解釈される続く説明を読んだ後、よりよく理解されるため、容易に理解されよう。

本発明によるユーザデバイスとＡＡＡサーバとの間の認可プロセス及び認証プロセスを示すシステムブロック図である。 簡易ネットワーク管理プロトコルを使用してルーティングテーブルからＩＰソースアドレスを検索する一方法を示すシステムブロック図である。 簡易ネットワーク管理プロトコルを使用してルーティングテーブルからＩＰソースアドレスを検索する別の方法を示すシステムブロック図である。 車載ユニットとＡＡＡサーバとの間の認可及び認証プロセスの別の実施形態を示すシステムブロック図である。 本発明による認証プロセスの実施形態を示すシステムブロック図である。 本発明による外部デバイスの認証プロセスを示すシステムブロック図である。 境界ゲートウェイプロトコルを利用して無線アクセス乗物環境の上のプロトコルスタックを示すブロック図である。 本発明の別の実施形態によるセキュリティクレデンシャルを配布するプロセスを示すシステムブロック図である。 本発明による外部デバイスの更に別の認証及び認可プロセスを示すシステムブロック図である。 ＡＡＡサーバと複数の路側ユニットとの間の通信を示すシステムブロック図である。 本発明による認可プロセスを示すフローチャートである。 ＡＡＡサーバにおける車載ユニット等のクライアントデバイスのブロック及びアンブロックを示すシステムブロック図及びフローチャートである。 本発明による会計プロセスを示すシステムブロック図及びフローチャートである。 マルチキャストメッセージ暗号化の鍵配布を可能にするハンドシェークプロトコルの概略図である。 マルチキャストメッセージ登録プロセスの概略図である。

詳細な開示
本発明が適用において以下の例示的な実施形態の説明に記載され、又は図面に示される構造の詳細又は構成要素の配置に限定されないことを理解されたい。本発明は、他の実施形態も可能であり、種々の方法で実施、実行することが可能である。また、本明細書において利用される語句及び用語が、説明を目的としており、限定として見なされるべきではないことを理解されたい。本明細書における「含む」、「備える」、又は「有する」及びそれらの変形の使用は、その後に列挙された項目及びその均等物並び追加の項目の包含を意味する。加えて、本明細書における「接続される」、「結合される」、「結合解除される」という用語、及びその変形は、物理的、機械的、又は電気的接続又は結合に限定されない。さらに、続く段落に記載されるように、図面に示される特定の機械的構成及び／又は他の構成は、本発明の実施形態の例示を意図する。しかしながら、他の代替の構成も可能であり、それらは本開示の教示内にあるものと見なされる。

幾つかの例示的な実施形態に関連して、ＷＡＶＥセキュリティ要件に起因して、全てのノード（モバイルノード及び静止ノードの両方）は、ＩＥＥＥ１６０９．２において指定される暗号化法を使用してクレデンシャルを有することが求められる。クレデンシャルは、デバイスがプロビジョニングされる際、発行され、モバイルデバイスが、発行されたクレデンシャルに基づいてデジタル署名を搬送する基本安全メッセージ（ＢＳＭ）をブロードキャストする場合のように、デバイス自体を認証できるようにするデジタル署名を作成するのに使用される。しかしながら、デバイスがプロビジョニングされる際、汎用ＩＰｖ６通信にサービスチャネルを使用する明示的な認可はない。サービスチャネルが使用可能であるか否かは、ＩＥＥＥ１６０９．１２に定義された手順に従って適切に登録された、このためのプロバイダサービス識別情報（ＰＳＩＤ）があるか否かに依存すべきである。ＤＳＲＣ基盤は、ビジネスモデルの枠組み内でスペクトルマネタイゼーションの問題に対処する、「基盤機関」の属性を全て共有する種々の形態の公開－秘密パートナーシップを使用して配備され管理されると一般に仮定される。ＯＢＵがＮＨＴＳＡ安全規格において確立される機能要件に準拠する場合、ＯＢＵ又はＯＢＵに接続された第三者ユーザデバイスにＷＡＶＥサービスチャネルを介したＩＰｖ６接続を認可することができるか否か及び帯域幅使用が課金されるか否かの判断は、基盤機関の自由裁量的選択になり得る。したがって、幾つかの例示的な実施形態は、基盤機関が個々のデバイスへのＩＰｖ６接続を許可又は拒絶でき、各デバイスに関連するサービスチャネル帯域幅消費を測定できるようにし得る。これは、本明細書に記載される本発明の実施によって達成される。

最初のステップは「認証」である。これは、ユーザデバイス（例えば、スマートフォン）を含むクライアントデバイスにより又は代替的には、ユーザデバイスの代理として動作するＯＢＵにより実行される「ログオン」手順に基づく。これらの２つのシナリオの差異は、基盤オペレータから利用可能なビジネスモデルの機能及びＯＥＭ製造デバイス若しくはアフターマーケットレトロフィットであることができるＯＢＵの所有者によって行われる選択である。例えば、ＯＢＵの所有者が、どの第三者ユーザデバイスが通信エンドポイントであるかに関係なく、ＩＰｖ６帯域幅消費に関わる全てのコストを吸収する場合、ログオンはＯＢＵデバイスから発せられる。コストが近傍第三者ユーザデバイスに帰する場合、帯域幅の会計はユーザデバイスに適用可能であり、したがって、ユーザデバイスがログオンの発起元であるべきである。

ログオンは基本的に、近傍ＲＳＵを通したＩＰｖ６接続要求である。ユーザデバイス又は上述したユーザデバイスの代理として機能するＯＢＵは、要求側デバイスであり、「クライアント」又は「クライアントデバイス」と呼ばれ得る。ログオンメッセージは、基盤オペレータにより又は基盤オペレータの代理として発行されたデジタル証明書から得られる暗号鍵を使用してデジタル署名される。デジタル証明書はログオンメッセージにカプセル化され、受信者が署名を復号化し、証明書に提示されたクレデンシャルを確認できるようにする。ログオンメッセージは、基盤オペレータにより維持される別個のホストである「道路認可サーバ」（ＲＡＳ：Roadway Authorization Server）にアドレス指定されたＵＤＰ／ＩＰパケットにカプセル化される。出願第１４／１５１，０３５号に開示されるように、特定のＲＳＵは、通過しつつあるＯＢＵにＩＰｖ６接続サービスを提供するように準備される場合、ＷＡＶＥサービスアドバタイズメント（ＷＳＡ）においてＲＡＳサービスのＩＰアドレス及びアプリケーションポートをブロードキャストする。クレデンシャルの確認は認証ステップを続け、本明細書における幾つかの例示的な実施形態は認可及び会計の相補的機能を定義するため、幾つかの例示的な実施形態におけるＲＡＳは、より詳細に後述するように、ＡＡＡサーバと表される。

認証ステップは、ログオンメッセージにおいて識別されたクレデンシャルを確認することが可能な外部システムによってサポートされる。そのようなシステムは、米連邦自動車安全基準（ＦＭＶＳＳ）１５０の一環として定義されており、セキュリティクレデンシャル及び管理システム（ＳＣＭＳ）と呼ばれている。ＳＣＭＳは公開鍵基盤（ＰＫＩ）アーキテクチャに基づき、非対称暗号鍵は、「ルート」証明局によって生成され、クライアントデバイスのクレデンシャルを構成するデジタル証明書にカプセル化される。ＳＣＭＳの技術的アーキテクチャは、衝突回避メトリスクパートナーシップ（ＣＡＭＰ）により表されるように、ＵＳＤＯＴ及び自動車業界による協働努力から発展した。ＳＣＭＳの詳細な説明はhttp://federalregister.gov/a/2014-24482において見出すことができ、これは参照により本明細書に援用される。ＳＣＭＳの主な目的は、ＦＭＶＳＳ １５０により定義される車々間（Ｖ２Ｖ）通信に参加しているデバイスが適切に証明され、それらの動作が消費者プライバシーを損なわないことを保証することである。ＡＡＡサーバとＳＣＭＳとの間のセキュアリンクを通して、ＡＡＡサーバは、特定のデバイスのセキュリティクレデンシャルを検証するに当たりＳＣＭＳ構成要素からの支援を要求できるようになる。検証プロセスは、デジタル署名、証明書情報、及びデバイスの暗号化された一意の識別子に基づき、これらは全て、そのデバイスから受信されるログオンにカプセル化される。デジタル署名、証明書情報、及び暗号化された一意の識別子が別個にセキュアに送信することができることを理解されたい。

次のステップは「認可」であり、認可には２つの態様がある。第１の態様は、クライアントデバイスのクレデンシャルがクレデンシャル機関により取り消されていないことの確認である。これは、ＳＣＭＳにより保持される証明書取り消しリストを使用して行われる。ＳＣＭＳの現在の仕様では、証明書取り消しリストをＯＢＵ及びＲＳＵのみに配布する必要がある。しかしながら、ＡＡＡサーバが上述した確認を行えるようにするために、証明書取り消しリストはＡＡＡサーバにも配布されるべきである。第２の態様はクライアントに関連する口座が優良状態であることであり、これは基盤オペレータのポリシーに従って判断される。

認可ステップは、認証ステップに合格した場合のみ、必要とされ得る。最初のステップの「不合格」というブール結果又は両ステップの論理積は、ＡＡＡサーバが、クライアントに接続を現在提供しているＲＳＵのＩＰｖ６ルーティングテーブルを管理できるようにするメカニズムへの入力になる。この機能の実装は、ＩＥＴＦ ＲＦＣにおいて指定される既存の方法の利用に基づく。特に、境界ゲートウェイプロトコル（ＢＧＰ）の機能をＡＡＡサーバ及びＲＳＵの両方に追加することにより、ＡＡＡサーバはＲＳＵ内でリモートトリガーブラックホール（ＲＴＢＨ）フィルタリングを行うことが可能になり、それにより、クライアントが認証及び認可ステップに合格したか否かに基づいて、クライアントからのＩＰｖ６トラフィックをブロック又はアンブロックすることができる。この方法論は、基盤オペレータが提供したいモバイルインターネットサービスへのアクセスを制御する効率的で規格に基づく手段を提供し、仕様のＷＡＶＥスイートを変更する必要なく、サービスを要求するクライアントデバイスの適切に認可されたクレデンシャルをＲＳＵのＩＰｖ６ルーティングテーブルにリンクする。

最後のステップは会計である。ＲＳＵは、ＩＰｖ６インターフェースを使用する場合、各デバイスによるサービスチャネル帯域幅消費を追跡し、リポートをＡＡＡサーバに定期的に送信するように構成される。これを達成するために、ＩＰｖ６層の管理情報ベース（ＭＩＢ）は、クライアント毎のパケット及びバイトカウント統計を取得するように拡張し得る。消費データは、標準ＳＮＭＰインターフェースを使用して検索され、例えばＴＣＰ接続を介してＡＡＡサーバに定期的に送信される。

幾つかの例示的な実施形態に関連して、ＤＳＲＣ ＲＳＵは、ＷＡＶＥサービスチャネルを介してＯＢＵから受信した又はＯＢＵに送信されたＩＰｖ６データグラムをルーティングする。「基盤機関」であり得るＲＳＵの所有者が、個々のＯＢＵ及びＯＢＵに接続されたデバイスによるサービスチャネル帯域幅仕様を制御し管理するポリシーを採用する場合、これらのデバイスを認証し、それらのサービスチャネルの使用を認可し、各デバイスにより消費された帯域幅量を会計するメカニズムが必要とされる。本発明は、通常、ＡＡＡ（認証、認可、及び会計）と呼ばれる、これらのメカニズムをサポートするサーバを提供する。

安全性又は「Ｖ２Ｖ」チャネル（ここではＤＳＲＣ帯域の「底」におけるＣＨ１７２において指定される）及び制御チャネル（ＣＣＨ又はＣＨ１７８）の両方を監視する、必要とされるデューティサイクルに準拠したシングル無線ＯＢＵデバイスは、ＩＰｖ６接続サービスの提供に適さないことがあり、その理由は、最低限でも、その受信機が時間を安全チャネル、ＣＣＨ、及び指定のサービスチャネル間で更に分割する必要があるためである。デュアル無線デバイスの増分費用は、ベンダーがデュアル無線デバイスとして、参照により本明細書に援用される「Ｖ２Ｖ準備リポート」において定義されるアフターマーケット安全デバイス（ＡＳＤ）又はレトロフィット安全デバイス（ＲＳＤ）の何れかであるＯＢＵ製品を構成するのを保証するのに十分に低い。したがって、本開示全体を通して、サービスチャネル帯域幅へのアクセスを提供するＯＢＵがデュアル無線デバイスとして構成されると仮定される。しかしながら、本発明がシングル無線デバイスを用いて実施することも可能なことを理解されたい。

ＷＡＶＥ規格では、いかなる制限もなくＩＰｖ６データグラムをサービスチャネルで伝送することができるため、データグラムを受信したＲＳＵは自動的に、データグラムを宛先に向けてルーティングする。しかしながら、ＲＳＵの管理ポリシーにより、ＩＰｖ６トラフィックがＡＡＡの認可を受ける必要がある場合、無線ＩＰｖ６通信の認可は、ＯＢＵ又はＯＢＵに接続された１つ又は複数のデバイスの代理として要求されるべきである。

図１は、本発明によるユーザデバイスとＡＡＡサーバとの間の認可プロセス及び認証プロセスを示す。認可の要件を示すＲＳＵからの通知は、ＷＡＶＥサービスアドバタイズメント（ＷＳＡ）３５において実施される。ＷＳＡは、ＲＳＵによるＷＡＶＥ ＣＣＨでのブロードキャストであり、ＷＳＡをブロードキャストするＲＳＵを通して何のサービスにアクセス可能であるかをＲＳＵがＯＢＵに通知する、ＷＡＶＥ規格により要求される方法を構成する。

ＲＳＵ３０は、ＯＢＵが認可要求を送信することができるＡＡＡサービスのＩＰアドレス及びポートを含むＷＳＡを発行するように基盤オペレータにより構成される。米国特許出願第１４／１５１，０３５号に開示されるように、ＷＳＡは従来、ＯＢＵが認可要求を送信すべきアドレスの識別のみに使用されてきた。本発明は、更に後述するように、ＯＢＵがチャネル構成に使用すべきチャネル可用性情報を含むためにもＷＳＡを利用する。ＷＳＡ３５はＡＡＡサーバのＩＰアドレス及びポートの両方をカプセル化する。ＷＳＡ３５はまた、このＲＳＵがＡＡＡ管理を受ける汎用ＩＰｖ６接続の可用性をサポートすること及び利用可能なサービスチャネルの識別子を示すプロバイダサービス識別情報（ＰＳＩＤ）もカプセル化する。ＯＢＵが、任意の近傍ユーザデバイスについてＯＢＵに課金料金を適用するサービスと、各ユーザデバイスにそれ自体の課金口座が関連付けられるサービスとを区別できるようにするために、異なるＰＳＩＤが確立される。この区別の利用について以下に更に説明する。その他の点では、先に示したように、サービスチャネルへのアクセスは自動であり得、又は制限されないため、ＡＡＡが必要ない場合、ＷＳＡ３５は必要とされない。本明細書で使用される場合、自動は、非手動又は人間の介入を必要としない１つ又は複数のプロセッサによるリアルタイム又は略リアルタイムの自動処理を意味する。しかしながら、本発明から逸脱せずに手動関与が必要とされ得ることを理解されたい。ＷＳＡ３５のペイロードはまた、ＡＡＡサーバに発行されたデジタル証明書に関連し、以下に更に説明するように、ＡＡＡサーバに送信される認可要求に含まれるデータを暗号化するためにＯＢＵにより必要とされる暗号化キーイング材料も含まなければならない。

ＷＳＡ３５の中味は、ＷＳＭＰインターフェースを通して、一般にＯＢＵ２０で実行されるユーザアプリケーションであるプロセス２１に報告される。プロセス２１は、ＯＢＵ２０に常駐するプロセッサにより実装され実施される。プロセッサが、本明細書に記載されるプロセスを実行可能な任意の容易に入手可能なデバイスであり得ることを理解されたい。プロセスステップ又は命令は、ＯＢＵ２０又はユーザデバイス１０のプロセッサを介して実行され、図全体を通して示されるフローチャート及び／又は図において指定され、本明細書で考察される機能／動作を実施する。次に、プロセス２１は、ＷＳＡにおいて指定されるサービスチャネル番号を指定するＭＡＣ層管理エンティティ（ＭＬＭＥ）に「送信機プロファイル」を登録する。送信機プロファイルのこの登録は、ポリシー変更によりＷＳＡにおいて広告されるサービスが変更された場合は常に、ＭＬＭＥが常に更新されることを保証する。ＩＰｖ６接続サービスが特定の時間又はロケーション（すなわち、特定のＲＳＵ又はＲＳＵのクラスタ）において非アクティブ化される場合、これらのサービスに対応するＰＳＩＤはＷＳＡに存在せず、プロセス２１は、対応するサービスチャネル番号を含まない新しい送信機プロファイルを登録する。ＩＥＥＥ１６０９．４において説明されるように、ＩＥＥＥ８０２．１１ｐＭＡＣ層（図１に示されず）のチャネルルータ機能がこのサービスチャネル番号を見つけることができない場合、このチャネルを使用した送信が意図されるパケットは破棄される。

認可機能には、認可要求又はメッセージ２５により図１に示される、ＯＢＵ２０によりＡＡＡサーバ４０に送信される要求が関わる。そのようなメッセージ２５の一例は米国特許出願第１４／１５１，０３５号に開示されており、ＵＤＰ／ＩＰｖ６メッセージの形態をとる。このメッセージ２５はプロセス２１により開始され、プロセス２１はＷＳＡ３５をリッスンする。要求がＡＡＡサーバ４０によりまだ許可されていなかった場合、プロセス２１は、ＩＰｖ６インターフェースを通して送信するためにメッセージ２５をキューに配置する。ＷＳＡ３５は、広告されたサービスが第三者ユーザデバイスの個々の口座に課金され、したがって、認可要求が第三者デバイス、例えば近傍スマートフォン又はタブレットの「代理」としてのＯＢＵからのものであることを示し、ＯＢＵと第三者デバイスとの間のインターフェースは、幾つかの例示的な実施形態では、WiFiダイレクト（WiFiピアツーピアとも呼ばれる）等の無線リンクである。この場合、メッセージ２５のＵＤＰペイロードはユーザデバイスのＩＰソースアドレスを含む。

ユーザデバイス１０がそれ自体をＯＢＵ２０にアタッチするメカニズムでは、ＯＢＵ２０が、参照により本明細書に援用されるＲＦＣ４８６１におけるＩＰｖ６「近傍発見」仕様をサポートするように構成される必要がある。この仕様では、ネットワークノードは、近傍がネットワークに参加したい可能性があるインターフェースを介して「ルータアドバタイズメント」（ＲＡ）の定期的なブロードキャストを通してルーティング機能を近傍に通知する。ルータアドバタイズメントは、ＲＡ１００として図１に示されている。米国特許出願第１４／１５１，０３５号には、これもまた参照により本明細書に援用されるＲＦＣ４８６２において指定されるステートレスアドレス自動設定（ＳＬＡＡＣ）のメカニズムに関するアタッチメントプロセスが開示されている。

米国特許出願第１４／１５１，０３５号に開示される等の従来のシステムは、メッセージ２５により例示される認可要求に含まれるＩＰソースアドレスが取得される方法を開示していなかった。ユーザデバイスがそれ自体をＯＢＵにアタッチする場合、ＯＢＵは、幾つかの例示的な実施形態では、ユーザデバイスからのルータ要請メッセージの受信に起因してＩＰソースアドレスを発見し得、ユーザデバイスからのルータ要請メッセージを受信すると、ＲＦＣ４８６１に定義されるように、ユーザデバイスのアドレスはＯＢＵルーティングテーブルに追加されることになる。この情報を取得するには、ＯＢＵにおいてＳＮＭＰを実装する必要がある。周知のプロトコル層をそれぞれ示す図１ｂ及び図１ｃに示される、可能な２つの代替の方法がある。最も簡易な方法（図１ｂ）は、ＳＮＭＰ ＧＥＴをローカルホストに定期的に発行して、ＩＰｖ６ ＭＩＢにおけるｉｐｖ６ＲｏｕｔｅＴａｂｌｅオブジェクトを検索するようにプロセス２１を構成することである。第２の方法（図１ｃ）は計算的により効率的であるが、ルーティングテーブルの変更に対応する新しいオブジェクトを定義する標準ＩＰｖ６ ＭＩＢへの拡張を必要とする。これが検出されると、ＴＲＡＰメッセージが生成され、ＴＲＡＰメッセージは、プロセス２１によりＳＮＭＰ層に登録されたハンドラ関数２５によって受信することができる。

ＷＡＶＥをトランスポート層においてＴＣＰに頼るモバイルインターネットサービスのプラットフォームとして使用することは、デバイスがあるＲＳＵから別のＲＳＵに移動するにつれてＯＢＵアドレスが変更されるため、往々にして阻止される。その結果、それ自体をＯＢＵにアタッチするユーザデバイスは常に、ＲＳＵ間の各遷移に伴ってそれ自体のＩＰｖ６アドレスの変更を発見し、これはＴＣＰセッションを中断させ、そしてトランスポート層よりも上の任意のコネクション指向ストリーミングサービスの品質を低下させることになる。本発明は、ＲＦＣ６２７５に指定され、参照により本明細書に援用され、「ルート最適化」（セクション１１．３．１）モードに向けて構成されたモバイルＩＰｖ６に向けてユーザデバイスを可能にすることによりこれらの問題を解消する。本発明の一態様によれば、ＯＢＵ２０は近傍ユーザデバイスのプライマリ「気付けアドレス」になる。「ルート最適化」モードでは、「ホームアドレス」はＩＰｖ６宛先オプションヘッダにおいて搬送される。このアドレスは固定され、ＩＰソースアドレス及び宛先アドレスの代用として使用され、その理由は、モバイルＩＰｖ６のルート最適化モードでは、ＩＰソースアドレス及び宛先アドレスは、ＯＢＵ自体であるか、又はＤＳＲＣインターフェースを組み込んだスマートフォン等のＤＳＲＣ対応ユーザデバイスの場合、ＲＳＵであるモバイルノードの「気付けアドレス」アドレスであるためである。したがって、アタッチされたＯＢＵの集計ではなく、後述する会計機能により実施される個々のユーザデバイス毎のトラフィック統計の粒状蓄積を保証するために代用は必要とされる。図１ｂ及び図１ｃに示されるＯＢＵがＩＰソースアドレスを取得することに関連して先に説明したメカニズムと同様に、必要とされる「ホームアドレス」情報は、ＳＮＭＰ ＧＥＴ呼び出しを使用してモバイルＩＰｖ６ ＭＩＢから検索するか、又はＲＳＵによりルーティングされた各データグラムに生成されるＴＲＡＰを処理することにより、ＲＳＵ３０で実行されるプロセス３１により取得することができる。

幾つかの例示的な実施形態では、ＯＢＵは要求メッセージ２５に認証情報を含み、認可及び認証の両方を１ステップに結合できるようにする。この手順は、サービスチャネル帯域幅消費の会計がＯＢＵ２０の近傍の全てのデバイスで集計され、ＯＢＵ２０に関連する１つの口座に課金される場合、使用される。図２に示されるように、ＷＳＡ３６は、サービスの性質を反映した別個のＰＳＩＤを使用する。この場合、ＡＡＡサーバ４０は、クライアントの認証に必要な情報を含むメッセージ２４を受信し、したがって、認証チャレンジに応答する必要はない。認証に必要な情報は周知であり、限定ではなく、スマートフォンの国際モバイル機器識別情報、車両識別番号、又は他のそのような個人識別情報を含み得る。認証方法について以下に説明する。図２におけるパスセグメント２８及び２９は機能的に図１のパスセグメント２７及び２６と均等である。またにおいて、幾つかの例示的な実施形態では、会計プロセスを促進するために、メッセージ２４におけるペイロードは、実際のソースＩＰアドレスの代わりにＯＢＵのＩＰアドレスを含むべきである。ユーザデバイスから発せられる続くＩＰｖ６データグラムは、このアドレスをルーティングヘッダに含むことになる。これにより、ＲＳＵは、より詳細に以下に説明するように、アクティブＯＢＵのデータグラムバイトカウントを蓄積することができる。

再び図１を参照すると、ＲＳＵ３０は、サービスチャネルを介して送信される認可要求２５の最初のＩＰｖ６ホップである。次に、ＲＳＵ３０はデータグラムをその宛先に向けてルーティングする。ルーティングは図１のパスセグメント２６及び２７により示され、これらはそれぞれサービスチャネルから受信されたインバウンドＩＥＥＥ８０２．１１ｐＭＡＣフレーム及び媒体が何であれ、インターネットへのバックホールのために配備される媒体上のアウトバウンドフレームである。個々のユーザデバイスによるサービスチャネル帯域幅消費の会計のために、ＲＳＵ３０はデータグラムのソースＩＰアドレスをそのようなアドレスの不揮発性ランダムアクセスメモリ（ＮＯＶＲＡＭ）テーブルにキャッシュする。本発明の会計プロセスでは、インバウンドデータグラムのソースＩＰ及びアウトバウンドデータグラムの宛先ＩＰアドレスは、このテーブル内のエントリと突き合わせて照合され、データグラムバイトカウントは、正確な一致に対応するエントリのＮＯＶＲＡＭテーブルに蓄積される。ＲＳＵが、ＯＢＵの近傍の全てのデバイスの集計されたサービスチャネル帯域幅消費を会計するように構成される場合、ＮＯＶＲＡＭテーブル内のエントリは、ＩＰｖ６ヘッダからパーズすることができるＯＢＵのアドレスでなければならない。

認可要求２５を受信すると、ＡＡＡサーバ４０はクライアントを認証するように構成される。図１は、ＡＡＡサーバ４０がＵＤＰ／ＩＰ認証チャレンジメッセージ１０５（又は認証チャレンジ）をユーザデバイス１０である要求に関連するＩＰソースアドレスに送信することを示している。応答メカニズムは、図１において認証チャレンジ応答１０３として示されている。チャレンジ応答１０３は送信側のクレデンシャルを確認するように機能し、したがって、送信側が真正性を基盤機関に証明できるようにするセキュア暗号化方法論を必要とする。ＤＳＲＣサイバーセキュリティプロビジョンはＩＥＥＥ１６０９．２に指定されており、暗号化キーイング材料は、基盤機関により運営されるか、又は基盤機関と協働する証明局により生成され配布されたデジタル証明書に含まれるため、これらの証明局も、ＯＢＵ及びＲＳＵに提供されることになる、同種の証明書（すなわち、ＩＥＥＥ１６０９．２仕様に準拠する）をユーザデバイスに提供することができるという結果になる。

ユーザデバイス１０は認証チャレンジ応答１０３を組み立て、認証チャレンジ応答１０３は、暗号化キーイング材料（基本的に、ユーザデバイスに発行された証明書の公開鍵）及び国際モバイル機器識別子（ＩＭＥＩ）等の何らかの一意の識別情報を含む暗号化されたペイロードを含む。復号化に成功すると、受信側は、ＩＥＥＥ１６０９．２に指定される非対称暗号化技法に従ってユーザデバイスを認証することができる。認証チャレンジ応答１０３を受信すると、ＡＡＡサーバ４０は、ＩＰソースアドレスを求めてデータベースを通してサーチを実行する。このデータベースはテーブルを含み、テーブルの行エントリは最低限でも一意のデバイス識別子、ＩＰｖ６アドレス、適切に認可された証明局によりデバイスに発行されたセキュリティクレデンシャル、及び現在の報告期間内の蓄積されたＷＡＶＥサービスチャネル帯域幅消費を含み得る。ＩＰソースアドレスの一致が見つかる場合、これは、このアドレスに以前、遭遇したことがあり、既に認証されていることを意味する。しかしながら、このアドレスが、全体的に異なるＯＢＵで以前、ＳＬＡＡＣに従って形成された別のＩＰｖ６アドレスの複製である場合、ＯＢＵがＲＳＵのカバレッジエリアから出て、それからＲＳＵのカバレッジエリアに戻るのにかかる最短時間が、ソースＩＰｖ６が複製アドレスの可能性があり得、したがって、ＡＡＡサーバ４０がクライアントを認証する必要があるポイントを定義し得る。

ＡＡＡサーバ４０がクライアントを認証し、サービスチャネルの使用を認可する能力は、要求において指定された暗号化／復号化プロセスを実施するか否かに依存する。認証に好ましいメカニズムを図３に示し、図３は、メッセージの受信側により認証される必要がある場合に利用するセキュリティクレデンシャルをクライアントデバイス１０に発行するプロセスを示す。セキュリティクレデンシャルは、ＳＣＭＳ内で定義される証明書管理エンティティ（ＣＭＥ）の１つであるエンロール証明局（ＥＣＡ）と呼ばれるエンティティによって発行される。

ＥＣＡ７０によるＯＢＵ２０へのセキュリティクレデンシャルの発行は、図３において動作７１によって示されている。しかしながら、セキュリティ証明書の発行の機能的仕様は、ＳＣＭＳにより定義されるブートストラッププロセスの一環であり、それにより、ＥＣＡは長期エンロール証明書等を各ＯＢＵに割り当て、これは周知であり、本開示の範囲を超える。可能な一形態では、エンロール証明書は、ＳＣＭＳの範囲内で定義される後続手順中、認証のためにＯＢＵが必要とするクレデンシャルを提供する。これらの手順は、基本安全メッセージが付随するデジタル署名が、デジタル署名の作成に使用される暗号化キーイング材料が認可された認証管理エンティティにより適切に発行されたという意味で署名が真正であることを保証しながら、個々の車両の匿名性を保持するという二重目的を果たすように設計されてきた。

ＳＣＭＳアーキテクチャの設計基準は、主な目的として、消費者匿名性の保護を有し、デバイス毎の帯域幅消費に基づいてＷＡＶＥサービスチャネルの「マネタイズ」という要件を含まない。本発明は会計手順を提供するため、帯域幅消費を特定のデバイスに関連付ける能力には、セキュリティクレデンシャル、すなわち、ＣＭＥによって発行される証明書が一意の個人識別情報（ＰＩＩ）を含むことが要求される。一般に、ＳＣＭＳ設計は、ＰＩＩが、基本安全メッセージ等のメッセージにデジタル署名するためにＯＢＵにより使用されるいかなる証明書でも利用可能ではないことを保証する。これは、送信デバイスのセキュリティクレデンシャルが検証可能でありながら、デバイスの識別が可能ではないため、その匿名性が保護されることを保証する。したがって、ＡＡＡ機能を必要とする基盤機関は、エンロール証明だけに頼っては、帯域幅消費を任意の特定のＯＢＵ又は第三者デバイスに関連付けることができない。

しかしながら、モバイルインターネットサービスの提供へのＷＡＶＥ帯域幅の使用は、消費者裁量選択に基づく。したがって、基盤機関が、サービスへの登録のために何らかの形態のＰＩＩを要求する場合、プライバシー違反はない。自動的に取得され、ＡＡＡサーバに送出され得るＰＩＩの一例は、車両識別番号（ＶＩＮ）であり、ＳＡＥ規格Ｊ－１９７９において定義されるプロトコル又は同様のプロトコルを使用してエンジン制御モジュール（ＥＣＭ）へのＣＡＮバス接続を用いてＯＢＵにより取得することができる。これは、ＯＢＵを通した集計トラフィックに適用される課金の場合、アフターマーケットＯＢＵデバイスはある車両から別の車両に移動することができるため、好ましいＰＩＩである。

エンロール証明にカプセル化されるＳＣＭＳ発行クレデンシャルと、課金口座に直接リンクすることができるＰＩＩとの間の関連付けを確立するのに好ましいメカニズムを図３に示す。プロセス２２は、２つの主な機能責任を有する、ＯＢＵ２０で実行されるアプリケーションレベルソフトウェアモジュールである。第１に、証明書をＥＣＡから送出する動作７１により示されるように、クレデンシャル証明書を受信するリスナー及び証明書の受信を確認（又は拒絶）する肯定応答７２を維持する。動作７１において受信される証明書は別個又は一緒に、エンロール証明書、識別証明書、又は認証機能に使用される他の証明クレデンシャルであり得ることを理解されたい。簡明にするために、以下の考察において、本発明を限定せずに、エンロール証明書を用いた認証について説明する。他のクレデンシャル証明書を同じように利用することも本開示内で考えられる。このために、プロセス２２は、ＯＢＵアプリケーションソフトウェアの必要とされる構成要素である。第２に、課金可能なＩＰｖ６接続サービスを広告するＲＳＵの範囲内で動作する場合、プロセス２２は、ＡＡＡサーバ４０へのＯＢＵ２０からの要求２５をトリガーする責任を負い、これは認可機能及び認証機能の両方を１ステップに結合する。プロセス２２は、ＳＡＥ Ｊ－１９７９において定義される標準プロトコルを使用してＥＣＭに問い合わせることによって取得されるＶＩＮを暗号化する。ＩＥＥＥ１６０９．２において指定される非対称暗号化方法論では、秘密鍵が復号化のみに使用され、一方、データの暗号化は公開鍵から導出される対称鍵を使用して実行されなければならないことは注目に値する。したがって、ＡＡＡサーバによってのみ復号化することができるデータを暗号化するために、ＯＢＵは、ＡＡＡサーバ自体によって公開される公開鍵を取得しなければならない。この公開鍵には、ＡＡＡサーバに発行されたエンロール証明書が関連付けられ、この公開鍵は、上述したように、ＡＡＡサーバと同じドメイン内で動作しているＲＳＵによりブロードキャストされるＷＳＡを通してＯＢＵに伝搬される。次に、プロセス２２は、ＯＢＵのエンロール証明書情報も含まなければならない認可要求２５のペイロードの一部として、デジタル署名及びその検証のために必要な公開鍵からなる暗号化されたＶＩＮをカプセル化する。次に、プロセス２２は認可要求２５をＡＡＡサーバ４０の受信者に送信し（プロセス４１）、ＡＡＡサーバ４０の受信者は、ＶＩＮの復号化に必要な秘密鍵を所有している。提示を簡明にするために、上述した２つのソフトウェア機能は１つのプロセス２２内で実施される。別の実施形態では、これらの２つの機能は切り離して、２つの別個のプロセスを生成することが可能である。

ＳＣＭＳ仕様は、定義により、これらのデバイスの証明に必要な全ての規格（ＩＥＥＥ１６０９．ｘ、ＩＥＥＥ８０２．１１ｐ、ＳＡＥ Ｊ－２７３５、及びＳＡＥ Ｊ－２９４５）に準拠するＤＳＲＣデバイスのエンロールの責任を負うものとしてＥＣＡを定義する。しかしながら、ＷＡＶＥサービスチャネルを使用したＩＰｖ６トラフィックが非ＤＳＲＣモバイルデバイスから発せられ、個々の非ＤＳＲＣモバイルデバイスに課金口座を作成することが基盤機関のポリシーである場合、これらのデバイスは、トラフィックがＡＡＡシステムにより認可されるべき場合、同種のクレデンシャルを必要とする。そのようなクレデンシャルを発行するために、ＡＡＡサーバは、ＯＢＵの近傍であり、ＩＰトラフィックをＷＡＶＥサービスチャネルにオフロードすることができる非ＤＳＲＣモバイルデバイスのみの証明書管理エンティティとして可能になる。生成される証明書は、ＯＢＵエンロール証明書等から区別するために、「インターネットサブスクリプション証明書」である。図３における動作７３及び７４は、そのようなクレデンシャルの発行を示す。幾つかの例示的な実施形態では、これらのクレデンシャルを配布するための通信パスは、非ＤＳＲＣモバイルデバイスとＡＡＡサーバとの間のＳＳＬセッションに基づく。

幾つかの例示的な実施形態では、ＡＡＡサーバ４０がＲＳＵ３０のＩＰｖ６接続サービスへのアクセスについてＯＢＵ２０を認可するために満たすべき３つの条件がある。第１に、ＯＢＵ２０のセキュリティクレデンシャルは検証される。これは、要求において送信されるエンロール証明書の公開鍵を使用して、要求２５にカプセル化され、プロセス４１により受信されたたＰＩＩの復号化の成功により達成される。復号化アルゴリズムは、ＡＡＡサーバ４０で実行されるソフトウェアモジュール４２として実施され、図３に示されるように、プロセス４１からの同期呼び出しを通して呼び出される。第２に、ＡＡＡサーバ４０に登録された加入者のデータベース４３がサーチ４５によって照会されて、ＰＩＩが見つけられるか否かを判断する。これはＯＢＵ２０の認証を構成する。

加えて、図９におけるフローチャートはこれらのステップをまとめている。ステップ１０１において、ＡＡＡサーバ４０は認証及び／又は認可要求を受信する。次に、ステップ１１０において、ＯＢＵ２０デジタル署名が復号化される。次に、ステップ１２０において、デジタル署名は検証され、署名が検証されない場合、通知がＯＢＵ２０に返される。署名もし検証された場合、ステップ１３０において、データベース４３がＰＩＩについて照会される。ステップ１４０においてＰＩＩが見つかった場合、通知がＯＢＵ２０に返される。その他の場合、ステップ１５０において要求はＥＣＡに転送される。

通常、ユーザ登録は、ＤＳＲＣ基盤オペレータにより提供されるウェブユーザ又はウェブサービスインターフェースを通して実行される。実際の登録方法は本開示の範囲外である。使用される方法が何であれ、基盤オペレータが、一意の識別情報（ＰＩＩ）、例えば車両のＶＩＮに関連する口座を作成できるようにすべきである。

ＤＳＲＣ基盤の動作が米国にわたって分散することがＵＳＤＯＴポリシーの基本的な信条である。市であれ、郡であれ、地方行政機関であれ、又は州ＤＯＴであれ関係なく、地域の管轄が独立したＤＳＲＣ基盤オペレータを確立するか、又はその確立を監督すると考えられる。多く又は恐らくは全ての事例で、これらの運営エンティティが公開－秘密パートナーシップの形態をとると予期されるが、パートナーの企業構造、役割、及び責任並びにＤＳＲＣ技術自体を使用して実施されるポリシーを確立する手順は様々であり得る。本開示を特に参照して、何故モバイルインターネットサービスに関するポリシーが全ての管轄にわたり標準化される必要があるのかについての技術的理由はない。各管轄は、テリトリー内に配備され、その管理下にあるＲＳＵが何れであっても、ＲＳＵを通してモバイルインターネットサービスをイネーブルし、適切であると思われるＷＡＶＥサービスチャネルの帯域幅消費の料金スケジュールが何であれ、料金スケジュールを適用する選択肢を有する。

認証の３ステップのうちの最後は、ＰＩＩとのローカルデータベース一致がない場合に生じ、その場合、後述する追加の手順が必要になる。モバイルインターネットサービスの地域にわたる相互運用性を保証するために、各基盤機関は、そのテリトリーに関連する車両を登録することができるＡＡＡサーバを維持すべきである。このニーズの一例は以下のシナリオで生じる。車両は、基盤機関のポリシーが無料モバイルインターネットサービス向けのものである領域内のアドレスを有するものとして登録される（ＤＭＶに）。この車両は現在、帯域幅消費に料金を課し、この目的で管理ツール（ＡＡＡサーバ）を運営する別の地域を走行中である。この地域内の各ＲＳＵは、地域の機関により所有され運営されるＡＡＡサーバのみのＩＰアドレス及びＵＤＰポート番号を広告する。車両内のＯＢＵは、サービスにアクセスするための認可を要求する。要求が非ＤＳＲＣモバイルデバイスからのものである場合、ＡＡＡサーバはクレデンシャルを検証しようとする。その他の場合、ＡＡＡサーバは、ＯＢＵにより使用されるエンロール証明書についてＥＣＡからの検証を要求する。しかし、復号化されたＰＩＩ（例えば、ＶＩＮ）はＡＡＡデータベースに現れないため、基盤機関は、モバイルインターネットサービスへの車両アクセスを拒絶する権利をアサートすることができる。モバイルインターネットサービスへのアクセスをイネーブル又は禁止するメカニズムについて以下に説明する。しかしながら、「外部」車両がＡＡＡサーバに登録されていない場合、基盤機関は、ＳＣＭＳにより支配される管轄全体を通して配備された場所がどこであれ、全集団のＡＡＡサーバに問い合わせるように動作可能である。基盤機関は、「外部」車両（すなわち、ＡＡＡサーバに登録されない車両）へのアクセスを禁止する場合、「リモート」ＡＡＡサーバに登録されたＰＩＩに関連する口座から生成することができた収益を放棄するように動作可能である。

要するに、モバイルインターネットサービスに、車両がどこで動作してもアクセス可能であるべき場合、サービスを提供するオペレータがテリトリー内で動作している「外部」車両を認証し、ホームテリトリー内のＡＡＡサーバを用いた帯域幅消費の料金を調停できるようにするメカニズムが必要である。

図４は、「外部」車両を見つけるために必要な一連のステップを示す。上述したように、モバイルデバイスへのクレデンシャルの発行に関するＥＣＡの役割は、ＳＣＭＳ仕様の範囲内で定義されている。しかしながら、ＥＣＡは、モバイルインターネットサービスを要求するが、ローカルＡＡＡサーバデータベースにおいて見つけることができないデバイスを認証する追加の役割を包含する。この新しい役割は、ＡＡＡサーバがＳＣＭＳの公開鍵基盤（ＰＫＩ）アーキテクチャに統合されることを必要とする。

ＰＫＩシステムは一般に、計算デバイスが真正性の証明を必要とする任意の他のデバイスにセキュリティクレデンシャルを提示するためのインターネットトランザクションで使用される。セキュリティクレデンシャルは、信頼「チェーン」又は「階層」から導出することができ、それにより、クレデンシャル自体を含むデジタル証明書が、証明書の発行者のデジタル署名に従って認証されるべきである。提示された証明書に基づくデバイスの認証は、「信頼階層」においてそれよりも上の別のエンティティから信用性を導出しない「ルート」証明局に達する前に幾つかの反復を必要とする。

ＥＣＡの役割は、本明細書における例示的な実施形態の種々の手順又は機能をサポートする必要機能を組み込むことである。特に、ＥＣＡは、基盤機関が配備を望む任意のＡＡＡサーバに証明書を発行するように構成される。そうすることにより、基盤機関がＷＡＶＥサービスチャネルスペクトルのマネタイズを管理する必要があるＡＡＡサーバまでＳＣＭＳの信頼階層を拡張する。さらに、証明書を発行した各ＡＡＡサーバのＩＰアドレスのＮＯＶＲＡＭテーブルを維持するものである。これは、クライアントのＰＩＩをローカルＡＡＡサーバのデータベースで見つけられない場合、ＥＣＡが、図９のフローチャートのステップ１５０に示されるように、問題となっている車両がどこかに登録されているか否かを特定するために、ＳＣＭＳの管轄下で動作している、適切に証明された全てのＡＡＡサーバに問い合わせることができることを保証する。

ＥＣＡによる「リモート」ＡＡＡサーバの問い合わせは、ＥＣＡ７０とＡＡＡサーバ５０及び６０との間の対話により図４に例示される。この表現は単に、図を簡易化する目的が意図され、問い合わせプロセスが２つのＡＡＡサーバのみに制限されることの暗示を意図しない。第１の事例では、ＥＣＡ７０はＡＡＡサーバ５０で実行中の指定されたリスナー５６に要求７５を送信し、そして指定されたリスナー５６は、ＶＩＮについての照会５５をデータベース５３に発行する。バイナリ結果（見つかった／見つからなかった）は、応答７６でＥＣＡに返される。同様に、リスナー４０及びデータベース４３と機能的に均等なリスナー６６及びデータベース６３を包含するＡＡＡサーバ６０におけるリスナー６６への要求７７は、クエリ６５及び応答７８における同じタイプのバイナリ結果をトリガーする。ＡＡＡサーバはＳＣＭＳシステムのＰＫＩアーキテクチャに統合されるため、ＥＣＡにより送信されたＶＩＮ情報の機密性を保証するセキュリティプロビジョンが存在する。

代替的には、ＳＣＭＳにおいて現在指定されるようにＥＣＡのクレデンシャル責任をモバイルＩＰ課金口座に関連する任意のデバイスのクレデンシャル要件から切り離すために、ＡＡＡサーバは、上述したように、「インターネットサブスクリプション」証明書をＤＳＲＣ ＯＢＵ及び非ＤＳＲＣモバイルデバイスに発行するように構成される。この場合、「インターネットサブスクリプション」証明書をＯＢＵに配布する通信パスは、セルラの代わりにＤＳＲＣを介するものであり、証明書情報は、幾つかの例示的な実施形態では、エンロール証明書を使用した非対称暗号化によりセキュア化される。ＯＢＵ２０からの認可要求２５は、インターネットサブスクリプション証明書（エンロール証明書の代わりに）を使用して、ＡＡＡサーバ４０からの認証を要求する。これは図６に示される。インターネットサブスクリプション証明書の取得に必要とされる一連のステップは以下である。
・ＷＳＡ３５（又は３６）が最初に受信されたとき、プロセス８０が、ＯＢＵ２０で実行されるプロセス２１（図１）によって生じる。
・ＯＢＵ２０は、ＡＡＡサーバ４０で実行されるプロセス８２にＵＰＤ／ＩＰメッセージ８１を送信して、インターネットサブスクリプション証明書を要求する。この要求はＯＢＵのエンロール証明書情報を含む。
・プロセス８２は要求／応答交換８３をＥＣＡ７０に送信して、エンロール証明書が取り消されていないことを検証する。
・プロセス８２は、要求／応答交換８４をモジュール８５に送信して、ＯＢＵ２０の非対称暗号鍵対及びこの情報を含むインターネットサブスクリプション証明書を生成する。
・プロセス８２は、メッセージ８１において受信されたエンロール証明書の公開鍵を使用してモジュール８５により生成された情報を暗号化し、これをメッセージ８６のペイロードとしてＯＢＵ２０のプロセス８０に返す。
・ＯＢＵ２０はメッセージ８７を用いて受信を肯定応答する。

ＯＢＵの「インターネットサブスクリプション」証明書の追加の利点は、「外部」車両をサーチするためにＥＣＡにより複数のＡＡＡサーバに問い合わせる必要性をなくすことである。インターネットサブスクリプション証明書は、インターネットサブスクリプション証明書を発行したＡＡＡサーバのドメイン名を含むべきであり、これはＯＢＵからの認可要求（又は非ＤＳＲＣモバイルデバイスからの認可チャレンジ応答）に含まれる。したがって、要求を受信したＡＡＡサーバは、ドメイン名を解決してＩＰアドレスにし得る。そして、一致が見つかるまで全てのリモートサーバをスキャンする（図４における要求７５、７７及び応答７６、７８）のではなく、１つのみのＵＤＰ／ＩＰ要求／応答が必要とされる。ＯＢＵからの要求又は認可チャレンジ応答には、インターネットサブスクリプションを発行したＡＡＡサーバのエンロール証明書の公開鍵も含まれ、公開鍵は、後述するように、要求／応答をリモートＡＡＡサーバに転送する必要がある場合、ＶＩＮの再暗号化に使用することができる。

「外部」デバイスの認可／認証のこの代替パスは図７に示される。ＡＡＡサーバ４０で実行されるプロセス４１は、ＤＮＳサーバ９０へのＤＮＳアドレス解決要求４７を使用して、リモートＡＡＡサーバ６０のＩＰアドレスを取得し、次に要求７９をＡＡＡサーバ６０に転送する。要求７９のペイロードにおけるＰＩＩの機密性を保証するために、ＡＡＡサーバ４０は、リモートＡＡＡサーバ６０の公開鍵から導出された対称鍵を使用してＰＩＩを再暗号化し、ＥＣＡから取得されたそれ自体のクレデンシャルを使用して、要求７９にデジタル署名し、その証明書情報及び再暗号化されたＰＩＩの両方を要求７９において送信し、それにより、リモートＡＡＡサーバ６０は、署名を検証するとともに、要求におけるＰＩＩを復号化することができる。ＡＡＡサーバ４０のクレデンシャルはＥＣＡから取得されるため、これは要求７９に含まれるプライベート情報を保護するとともに、リモートＡＡＡサーバ６０が、ＳＣＭＳ信頼チェーンにリンクされるものとして送信者を認証し、応答８８を提供できるようにする。

認可の第３の条件は、エンロール証明書自体が期限切れしていないもの又は何らかの理由により取り消されていないものとして確認されることを保証することである。認可を達成するメカニズムの幾つかの例示的な実施形態は、主な目的が、エンロール証明書が、ＳＣＭＳにより維持され広められた最新の証明書取り消しリストであるないことの確認であるように要求４６を構築することを含み得る。しかしながら、証明書取り消しリストがＳＣＭＳによりＡＡＡサーバに伝搬される場合、ＥＣＡに受信した証明書を証明書取り消しリストと突き合わせて確認するように求める要求４６はもはや必要ない。第２に、エンロール証明書が有効であり、「インターネットサブスクリプション」証明書において識別されたＡＡＡサーバに直接問い合わせる上述した方法が使用されない場合のみ、要求４６は、要求におけるＰＩＩ（すなわち、ＶＩＮ）がローカルデータベースで見つけられず、リモートＡＡＡサーバでサーチする必要があることを指定することができる。

ＡＡＡサーバ４０は、認可要求の送信者に応答し得る。セキュリティクレデンシャルが無効であるか、又は取り消されていた、課金口座が延滞又は単に存在しない場合、支配ポリシーは、要求の拒絶を求め得る。しかしながら、ＩＰｖ６トラフィックがブロックされることを保証するためには、ＡＡＡサーバ４０がクライアントに拒絶通知を送信するだけでは十分ではない。ＩＰｖ６接続の認可を認めるプロセスは、ＩＥＥＥ１６０９仕様の範囲外にあるため、そのような認可を要求する任意のデバイスは「自発的」にそうすることになり、認可が拒絶される場合、この判断に従う「義務」はない。ＷＡＶＥ仕様は、ＩＰｖ６トラフィックをデータグラムヘッダにおいて指定された宛先アドレスに向けてルーティングすることを禁止せず、ＲＳＵがこのトラフィックをブロックするプロビジョンはＷＡＶＥ内にない。その結果、ＡＡＡサーバ４０が特定のＯＢＵから発せられたＩＰｖ６トラフィックをフィルタリングさせられるようにし、認証され認可されると、逆に特定のＯＢＵに適用されたフィルタを除去させられるようにするメカニズムが必要になることになる。

そのようなメカニズムに好ましい方法論は、ＵＳＤＯＴ推奨に準拠することが証明されたＲＳＵにおいて実施することができるものであり、これは、図５に示されるＷＡＶＥよりも上のプロトコルスタックが完全に実装されることを暗示する。フィルタリングメカニズムは、プロトコルスタックのトランスポート層を露出するＲＳＵベンダーにより提供されるＡＰＩを使用するアプリケーション層ソフトウェアとして動作する。ルータがトラフィックの起点に基づいてトラフィックを破棄する要件は、サービス拒絶（ＤＯＳ）攻撃の場合、生じる。これらの攻撃から保護するためにＩＳＰにより使用される方法の１つは、リモートトリガーブラックホール（ＲＴＢＨ）フィルタリングと呼ばれる。ＲＴＢＨフィルタリングは、ソースアドレス及び宛先アドレスの両方に適用することができるが、ＤＯＳの特定の場合、フィルタリングはソースアドレスに適用される。この方法論は、ＲＴＢＨフィルタリング命令をルータに送るために内部境界ゲートウェイプロトコルの使用を指定する、参照により本明細書に援用される情報ＲＦＣ５６３５に記載される。参照により本明細書に援用されるＲＦＣ４２７１において指定される境界ゲートウェイプロトコルは、周知のポート（１７９）でのＴＣＰ接続を介したピアツーピアセッションとして動作し、ルータ対間でルーティング情報を伝搬できるようにする。

基盤オペレータは通常、全て同じ自律システム内で動作する複数のＲＳＵ及び１つでなければ非常に限られた数のＡＡＡサーバを有する。このトポロジは図８に示され、図８では、ＡＡＡサーバ４０は、それぞれが個々のＲＳＵ３０へのＴＣＰ接続を有する、ＲＦＣ４２７１において定義されたＢＧＰ有限状態マシンの複数のインスタンスを実行する。図１０に示されるように、ＲＴＢＨフィルタリング命令は、ＲＦＣ４２７１に定義され、受信側ＲＳＵ３０によりブロック（フィルタリング）又はアンブロックすべきアドレスを指定する更新メッセージとして送信される。図５は、より従来的なシナリオとは対照的に、ＢＧＰサービスがコマンドラインインターフェースを通してネットワーク管理者により呼び出されるソフトウェアアプリケーションによるＢＧＰの使用を示す。換言すれば、本開示の状況でのＢＧＰの使用は、以下のアルゴリズムステップに関して説明することができる図１０のフローチャートにより定義される完全に自動化されたプロセスである。
・ＯＢＵ２０からの認可要求２５が、ＡＡＡサーバ４０により受信される。
・認証及び認可が、ステップ２００において、本開示において既に記載されたメカニズムに従って実行される。
・ステップ２１０において、要求が検証される。要求が無効化される（認証に失敗するか、又は認可が認められない）場合、「拒絶通知」をＵＤＰメッセージ９２の形態でＯＢＵに返すことができる。
・要求が認可される場合、「認可通知」９４をＯＢＵに返すことができる。
・先の両事例において、ＯＢＵへの応答９６は、任意選択的であることを示すために点線として示される。認可要求はＷＡＶＥ規格の一環ではなく、したがって、先に示したように、ＯＢＵはこの要求を送信する義務もなければ、応答をリッスン又は応答に関していかなる動作もとる義務もない。したがって、ＡＡＡサーバにおける応答メッセージの実施は要件ではない。
・両事例において、認証／認可プロセスの結果は、ＯＢＵ要求をＡＡＡサーバにルーティングしたＲＳＵに更新メッセージを送信するＢＧＰサービスの発動への入力９８になる。結果に応じて、このメッセージは、要求側ＯＢＵから発せられたトラフィックをブロック又はアンブロックするように、ＲＳＵで実行されるピアＢＧＰエンティティに指示する。ＴＣＰ接続は、ＯＢＵのＩＰｖ６アドレスからのグローバルプリフィックス及びサブネットＩＤをパーズすることによって得られるＲＳＵのＩＰｖ６アドレスに従って選ばれる（参照により本明細書に援用されるＲＦＣ４２９１ＩＰバージョン６アドレッシングアーキテクチャ参照）。
・ＲＳＵブロックモバイル終端トラフィックを指定されたモバイル宛先アドレスに指示する代替の方法論は、指定されたモバイル宛先アドレスのｉｐｖ６ＲｏｕｔｅＴａｂｌｅエントリに対応するＭＩＢオブジェクトｉｐｖ６ＲｏｕｔｅＶａｌｉｄを真又は偽の何れかに設定するようにＲＳＵに指示するＳＮＭＰ ＳＥＴコマンドを送信することである。この手法は、モバイル起点トラフィックのルーティングのブロック（又はアンブロック）に適用可能ではない。

会計
本発明の一目標は無線スペクトルのマネタイズであるため、幾つかの例示的な実施形態では、ＲＳＵは、ＩＰｖ６インターフェースを使用する際、各デバイスによるサービスチャネル帯域幅消費を追跡し、リポートをＡＡＡサーバに定期的に送信するように構成される。これを達成するために、ＩＰｖ６層の管理情報ベース（ＭＩＢ）は、クライアント毎のパケット及びバイトカウント統計を取得するように拡張され、データは、標準ＳＮＭＰインターフェースを使用して検索され、幾つかの例示的な実施形態ではＴＣＰ接続を通して、ＡＡＡサーバに定期的に送信される。好ましい実装を図１１に示す。ＲＳＵで実行されているプロセス３１は、ＴＲＡＰハンドラ登録３３を呼び出して、ＴＲＡＰハンドラ３２をＳＮＭＰに登録し、それにより、クライアント毎にバイトカウント統計が非同期で報告される。パケットがＷＡＶＥ ＩＰｖ６インターフェースに送信されるか、又はＷＡＶＥ ＩＰｖ６インターフェースから受信されるときは常に、拡張ＭＩＢは、クライアント単位で統計（Ｉｐｖ６ＢｙｔｅＲｘｏｒＴｘＰａｃｋｅｔＢｙｔｅＣｏｕｎｔ）を提供し、それによりＴＲＡＰメッセージ３４が生成される。ＴＲＡＰハンドラ３２はＴＲＡＰを処理し、コールバック手順３７を使用してプロセス３１に通知する。プロセス３１は、クライアント毎の統計をＮＯＶＲＡＭテーブルに蓄積し、ＵＤＰ／ＩＰリポート（メッセージ３８）を永続的な（すなわち、肯定応答を要求する）ＡＡＡサーバに定期的に送信する。肯定応答を送信する前、ＡＡＡサーバ４０で実行されるプロセス４１はデータベース手順４３を呼び出して、リポートにおいて受信した情報を記憶する。

マルチキャストプッシュ通知
幾つかの例示的な実施形態に関連して、幾つかのＩ－Ｖ（基盤－車両）ＷＡＶＥアプリケーションは、「プッシュ通知」をモバイルデバイスに送出する「一対多」構成においてマルチキャスト技法を使用する。そのようなアプリケーションには２つの基本的なカテゴリがある。
（１）時空間商業広告：例えば、特定の日／時での特定の小売り場所での割引きされた製品又はサービスのプロモーション。
（２）路側アラート（ＲＡ）。これらは、北米での多くの州及び地方の管轄による電話サービスとして現在提供されるタイプの情報に対応する道路網オペレータからの助言メッセージである。ＲＡは、限定ではなく、事故通知、レーン閉鎖、走行時間助言、及び他の道路網運営イベントを含む。ＲＡはまた、速度制限、行き先までの距離、駐車制限、及びスクールゾーン又は工事ゾーン警告、等の準静的ナビゲーション情報を含むこともできる。ＲＡは、参照により本明細書に援用されるＳＡＥ Ｊ－２７３５メッセージセットにおいて定義される標準化フォーマットに従って構築される。

マルチキャストＷＡＶＥサービスの「一対多」通信トポロジに起因して、これらのサービスのモバイルサブスクリプションから収益を導出するタスクは、本明細書に記載されるインスタンスからわずかに異なる手法を必要とする。

ビジネスモデル
幾つかの例示的な実施形態では、プッシュ通知から収益を生み出す２つのモデルがある：「広告」及び「サブスクリプション」。「広告」モデルを用いる場合、プッシュ通知の発信者は、メッセージの送出を考慮して何らかの様式でネットワークオペレータを補償する。この状況では、「広告」は純粋に商業用途に限定されず、事故通知、レーン閉鎖、走行時間助言、及びＳＡＥ Ｊ－２７３５メッセージセットに提示される路側アラート（ＲＡ）の標準化フォーマットに従って報告される他の道路網運営イベント等の公的サービス告知に適用することもできる。

幾つかの例示的な実施形態の「サブスクリプション」モデルでは、メッセージは、支払ったサブスクリプション口座に関連するデバイスによってのみ受信されるべきである。両モデルにおいて、マルチキャスト又は「一対多」メッセージ送出方法を使用することによりネットワークリソース（すなわち、帯域幅）の効率的な利用が達成される。マルチキャストグループに参加するクライアントデバイスは、そのグループに関連するマルチキャストアドレスに送信されたメッセージを受信することができ、これは、有効なサブスクリプションを有するかどうかに関係なく、任意のデバイスがマルチキャストメッセージを受信できるようにするソフトウェアを実装することが技術的に実現可能であることを意味する。

「サブスクリプション」モデルにおけるクライアントデバイスの区別
「広告」モデルの場合、幾つかの例示的な実施形態では、収益はメッセージのソースから来るため、ビジネスの観点から、異なるカテゴリのクライアントデバイスでメッセージへのアクセスを制限する必要はない。しかしながら、収益ソースに個々のクライアントデバイスが関連付けられる「サブスクリプション」モデルが有効であるべき場合、有効なサブスクリプションを有するクライアントデバイスのみにアクセスを制限する必要がある。

幾つかの例示的な実施形態では、そのような制限付きアクセスは、マルチキャストメッセージのペイロードを暗号化することにより提供し得る。そのような例示的な実施形態は、必ずしもこのためにいかなる特定の暗号化方法論にも限定されるわけではなく、これらのメッセージの受信が認可された全ての受信者が復号化に必要なキーイング材料を保有することを保証するタスクに専ら関わる。復号化に必要な鍵を認可されたデバイスに安全に配布することができることを保証する方法の確立へのここでのフォーカス。

幾つかの例示的な実施形態では、マルチキャストメッセージの「サブスクリプション」モデルをサポートする信頼できセキュアなメカニズムは図１２に示され、このメカニズムにより、クライアントデバイスは、ユニキャストインターネットメッセージングに基づいてサービスへのアクセスについてのＡＡＡサーバからの認証／認可を要求し得る。図１２は、路側ユニット（ＲＳＵ）３０がＷＳＡ３７を使用し、「サブスクリプションモデル」に関連するＰＳＩＤ（プロバイダサービス識別子）を用いてマルチキャストサービスを広告し得ることを示す。図１及び図２において説明されるように、ＯＢＵ（車載ユニット）２０は、接続されたクライアント（ユーザ）デバイスのＩＰｖ６アドレスを識別する要求２５をＡＡＡサーバ４０に送信し得る。次に、ＡＡＡサーバ４０は認証チャレンジ１０５をクライアントデバイス１０に発行し、クライアントデバイス１０は、ＥＣＤＳＡ署名と、公開鍵及び楕円曲線ドメインパラメータからなるマルチキャストサービスのＳＣＭＳ識別証明書（ＩＤ証明書）により提供される確認についてのパラメータとを含むマルチキャストサービスへのアクセスに必要なデジタルクレデンシャルをカプセル化した認証チャレンジ応答１０６で応答する。既に指定したように、ＡＡＡサーバ４０は署名及び口座ステータスを確認して、クライアントデバイス１０に認可を認めるか否かを判断する。認可が認められる場合、ＡＡＡサーバ４０はＥＣＩＥＳ（楕円曲線統合暗号化方式）１０７を利用して、ＩＤ証明書で公開されるパラメータを使用して対称鍵を導出し、次に、ＥＣＩＥＳメッセージ１０８のペイロードを暗号化する。ＥＣＩＥＳメッセージ１０８内のペイロードの平文バージョンは、マルチキャストメッセージ１１０を復号化する認可が認められたありとあらゆるクライアントデバイスにより必要とされるキーイング材料をカプセル化する。クライアントデバイス１０は、ＥＣＩＥＳステップ１０９を実行することによりＥＣＩＥＳメッセージ１０８のペイロードを復号化する。ＡＡＡサーバ４０の異なる実施形態は、マルチキャストメッセージ１１０のペイロードの対称暗号化／復号化に異なるアルゴリズムを使用し得る。

ＲＳＵ３０により広告されるサービスは、好ましくは、ＡＡＡサーバ４０により管理され、その理由は、クライアントデバイスに関連するサブスクリプション口座の検証を担当するのがＡＡＡサーバであるためである。さらに、ＡＡＡサーバ４０のみが、マルチキャストメッセージを発するビジネス又は政府機関（「マルチキャスタ」）により指定される時空間パラメータを正確な選択されたＲＳＵターゲットアドレスにマッピングすることが可能である。このプロセスは図１３に示される。特定のターゲット地理的エリアのメッセージ内容が変わる各場合で、マルチキャスタ３００はメッセージ３０１を使用して新しいメッセージ内容及び時空間パラメータをＡＡＡサーバ４０に送信する。次に、ＡＡＡサーバ４０はプロセス３０２を実行して、適切なＲＳＵをターゲットとした新しい１組のマルチキャストメッセージを組み立て、それらの送信をスケジュールする。クライアントデバイスは新しいＲＳＵに遭遇した際、認証／認可要求を提出するため、ＡＡＡサーバ４０はまた、既に説明したＥＣＩＥＳメカニズムを使用して送出されるマルチキャストメッセージペイロードを暗号化するためのキーイング材料を変更することもできる。ＲＳＵを選択し、送信をスケジュールし、ペイロードを暗号化するこれらのステップの結果はマルチキャストメッセージ３０３である。

幾つかの例示的な実施形態において説明されたＡＡＡサーバは、機関が無線アクセス乗物環境サービスチャネル帯域幅消費を会計できるようにするが、幾つかの例示的な実施形態においてＡＡＡサーバにより提供される機能は、認証をサポートするためにＳＣＭＳ証明を必要とする、ＯＢＵ及び／又はＯＢＵに関連する１つ又は複数のユーザデバイスが有効な口座を有するか、又はサブスクライバーであり得る他のプロセス、用途、又はサービス等に利用することが可能である。例えば、交通信号先取りの場合、機関は、ＲＳＵと同じ場所にある交通信号の制御を担当する交通管理センターに対して、近づきつつある車両内の認証されたＯＢＵが、指定された交差点における優先シグナリングに認可されていることを検証し得る。他の例示的な実施形態は、特定の車両タイプの車両のみによる使用専用のレーンで動作するライセンスを有する車両を含み得る。

したがって、幾つかの例示的な実施形態では、ＯＢＵは、近傍の非ＤＳＲＣモバイルデバイスの代理として又はそれ自体のために、サブスクライブしている任意のサービスへのアクセスについてＡＡＡサーバからの認証及び認可を要求するように構成し得る。

添付図面において輪郭線で示されるか、又はブロックで示される個々の構成要素は全て、射出成形分野で周知であり、それらの特定の構築及び動作は、本発明を実行する動作又は最良の形態にとって重要ではない。

本発明について、現在好ましい実施形態と見なされるものに関して説明したが、本発明が開示された実施形態に限定されないことを理解されたい。逆に、本発明は、添付の特許請求の範囲内に含まれる種々の変更及び均等構成の包含を意図する。以下の特許請求の範囲は最も広い解釈に従い、そのような全ての変更並びに均等な構造及び機能を包含すべきである。

条項：
本明細書に記載される例示的な実施形態は、ＲＳＵ、ＯＢＵ、ＡＡＡサーバ、及び／又はクライアント又はリモートデバイスを含め、以下の条項に記載される。

１．車載ユニット（ＯＢＵ）及び路側ユニット（ＲＳＵ）間でメッセージを伝送する、専用狭域通信基盤機関により又は専用狭域通信基盤機関の代理として動作するＡＡＡサーバであって、上記ＡＡＡサーバは、インターネットを通して、複数のユーザデバイス及び／又は１つ又は複数のユーザデバイスのサブネットを動作させるＯＢＵ、複数のＲＳＵと通信するように構成された少なくとも１つのコンピュータプログラムを実行して、認証、認可、及び会計（ＡＡＡ）の機能を実行し、機関が、上記ＡＡＡサーバにより適切にプロビジョニングされた上記ユーザデバイスのそれぞれによる無線アクセス乗物環境サービスチャネル帯域幅消費を会計できるようにする少なくとも１つのプロセッサを有する、ＡＡＡサーバ。

２．車載ユニット（ＯＢＵ）及び路側ユニット（ＲＳＵ）間でメッセージを伝送する、専用狭域通信基盤機関により又は専用狭域通信基盤機関の代理として動作するＡＡＡサーバであって、上記ＡＡＡサーバは、インターネットを通して、複数のユーザデバイス及び／又は１つ又は複数のユーザデバイスのサブネットを動作させるＯＢＵ、複数のＲＳＵと通信するように構成された少なくとも１つのコンピュータプログラムを実行して、認証、認可、及び会計（ＡＡＡ）の機能を実行し、機関が、上記ユーザデバイス及び／又は上記ＯＢＵを認証し、それによりサブスクライブされる任意のサービスへのアクセスに関して上記ユーザデバイス及び／又は上記ＯＢＵを認可できるようにする、ＡＡＡサーバ。

３．証明書管理エンティティとして構成され、ＩＰｖ６アドレス指定可能ユーザデバイスのインターネットサブスクリプションデジタル証明書を発行し、セキュア通信チャネルを介して証明書を上記ユーザデバイスに送信するように動作可能であり、上記証明書はＡＡＡサーバのドメイン名を含む、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

４．セキュリティクレデンシャル及び管理システム（ＳＣＭＳ）の構成要素間のＰＫＩ信頼チェーンにリンクされ、上記デジタル証明書についてのＤＳＲＣ ＯＢＵからの要求を処理するように動作可能であり、上記要求は、上記ＯＢＵの個人識別情報（ＰＩＩ）をカプセル化し、ＩＥＥＥ１６０９．２において指定される非対称暗号化アルゴリズムによってセキュア化され、ＳＣＭＳによって上記ＯＢＵに発行されたエンロール証明書を使用し、上記エンロール証明書の暗号鍵を使用して上記ＯＢＵに上記証明書を送信するためのセキュア通信チャネルを確立するように動作可能である、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

５．上記デジタル証明書についての非ＤＳＲＣモバイルデバイスからの要求を処理するように動作可能であり、上記要求は上記モバイルデバイスのＰＩＩをカプセル化し、各モバイルデバイスはハンドシェークプロトコルを開始して、上記ＡＡＡサーバとのセキュアな対称暗号化通信チャネルを確立する、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

６．ＯＢＵから認可及び認証結合要求を受信するように動作可能であり、上記要求は上記ＡＡＡサーバによって上記ＯＢＵに発行された上記インターネットサブスクリプション証明書からの鍵を使用して生成されたデジタル署名の形態でクレデンシャルを組み込み、ＡＡＡサーバは、１つ又は複数のリモートＡＡＡサーバから上記インターネットサブスクリプション証明書を受信したＯＢＵの代理として上記リモートＡＡＡサーバから転送された上記認可及び認証結合要求を受信するように動作可能であり、上記ＯＢＵ及び上記リモートＡＡＡサーバによって対応して提示されたクレデンシャルの暗号検証によりＯＢＵ及びリモートＡＡＡサーバの両方からの要求を処理するように動作可能であり、各要求について、要求に含まれるＰＩＩとの一致について非リモートＡＡＡデータベースを照会し、認証を認めるか、又は拒絶理由を表すコードと共に認証を拒絶するメッセージを要求側ＯＢＵ又はリモートＡＡＡに返す、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

７．非ＤＳＲＣモバイルデバイスの代理として上記ＯＢＵからの認証要求を受信して、上記非ＤＳＲＣモバイルデバイスのＩＰｖ６アドレスに直接又は間接的にＵＤＰ／ＩＰ認証チャレンジメッセージを送信し、上記ＡＡＡサーバによって上記非ＤＳＲＣモバイルデバイスに発行された上記インターネットサブスクリプション証明書からの鍵を使用して生成されたデジタル署名の形態のクレデンシャルを組み込んだ、上記認証チャレンジへの応答を処理するように動作可能であり、上記ＡＡＡサーバからインターネットサブスクリプションクレデンシャルを受信した非ＤＳＲＣモバイルデバイスの代理としてリモートＡＡＡサーバから転送された上記認証要求を受信するように動作可能であり、提示されたクレデンシャルの暗号検証により非ＤＳＲＣモバイルデバイス及びリモートＡＡＡサーバの両方からの要求を処理するように動作可能であり、要求に含まれるＰＩＩとの一致についてローカルＡＡＡデータベースを照会し、認証を認めるか、又は拒絶理由を説明するコードと共に認証を拒絶するメッセージを要求側に返す、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

８．認証及び認可を要求するためにユーザデバイスによって使用されるクレデンシャルを発行した証明書管理エンティティのドメイン名が、リモートＡＡＡサーバを識別する場合、上記ＳＣＭＳ信頼チェーンから得られたクレデンシャルを使用して上記リモートサーバとセキュア通信して、上記要求を上記リモートＡＡＡサーバに転送するように動作可能である、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

９．上記ＡＡＡサーバからの認証チャレンジに応答するためにユーザデバイスによって使用されるクレデンシャルを発行した証明書管理エンティティのドメイン名が、リモートＡＡＡサーバを識別する場合、上記ＳＣＭＳ信頼チェーンから得られたクレデンシャルを使用して上記リモートＡＡＡサーバとセキュア通信して、上記要求を上記リモートＡＡＡサーバに転送するように動作可能である、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

１０．内部ｂ境界ゲートウェイプロトコルと共にリモートトリガーブラックホール（ＲＴＢＨ）フィルタリングを使用して、同じ自律システム内のＲＳＵに更新メッセージを送信するように動作可能であり、上記更新メッセージは、ユーザデバイスから受信したインターネットサブスクリプションサービスの認証及び認可要求によりトリガーされ、認証及び認可要求の結果をカプセル化し、上記結果は、上記モバイルデバイスの認証失敗又は上記ユーザデバイスへの認証の認可若しくは拒絶である、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

１１．要求にカプセル化されたＰＳＩＤによって識別された、マルチキャストサービスに発行されたＳＣＭＳクレデンシャルと共に認証要求を受信すると、ＥＣＩＥＳが、上記マルチキャストサービスによって提供されたマルチキャスト「プッシュ通知」のペイロードの対称暗号化に必要なパラメータ及びキーイング材料の暗号化及び要求側デバイスへの送信に使用される、先の条項又は以下の条項の何れか一項に記載のＡＡＡサーバ。

１２．拡張ＩＰｖ６管理情報ベース（ＭＩＢ）が構成され、クライアントデバイス毎の無線アクセス乗物車両（ＷＡＶＥ）サービスチャネル使用のパケット及びバイトカウント統計を特定するように動作可能な路側ユニット（ＲＳＵ）であって、上記クライアントデバイスは、車載ユニット（ＯＢＵ）、ＯＢＵを通してＩＰｖ６到達可能な非ＤＳＲＣモバイルデバイス、又はＤＳＲＣ対応ユーザデバイスの何れかであり、上記ＩＰｖ６ ＭＩＢはまた、モバイルＩＰｖ６のルート最適化モードで動作しているＩＰｖ６ノードから受信する各データグラムについて、上記データグラムのモバイルＩＰｖ６ルーティングヘッダにおいて搬送されるモバイルノードの固定「ホームアドレス」を検索するように動作可能であり、上記ＲＳＵは、不揮発性ランダムアクセスメモリ（ＮＯＶＲＡＭ）に、クライアントデバイス毎にＷＡＶＥサービスチャネル使用の上記パケット及びバイトカウント統計を蓄積し、上記ＵＤＰ／ＩＰメッセージにカプセル化された上記統計をＡＡＡサーバに定期的に送信し、ＡＡＡサーバがＵＤＰ／ＩＰメッセージの受信を肯定応答した場合のみ上記ＮＯＶＲＡＭテーブルをリフレッシュするように動作可能である、路側ユニット（ＲＳＵ）。

１３．http://docplayer.net/11087167-Dsrc-roadside-unit-rsu-specifications-document.html又はその機能的均等物において見られるＵＳＤＯＴ仕様に準拠する先の条項又は以下の条項の何れか一項に記載のＲＳＵ。

１４．同じ自律システム内のＡＡＡサーバからのＲＴＢＨフィルタリング命令を処理するように動作可能な先の条項又は以下の条項の何れか一項に記載のＲＳＵ。

１５．http://docplayer.net/11087167-Dsrc-roadside-unit-rsu-specifications-document.html又はその機能的均等物において見られるＵＳＤＯＴ仕様に準拠し、上記ＲＳＵと同じドメインで動作しているＡＡＡサーバに発行されたセキュリティクレデンシャル及び管理システム（ＳＣＭＳ）エンロール証明書の公開鍵をカプセル化したサービスアナウンスメント（ＷＳＡ）をブロードキャストするように動作可能なＲＳＵ。

１６．ＷＡＶＥ及びＩＥＥＥ８０２．１１ｐに準拠し、デュアル無線機能を構成可能であり、近傍非ＤＳＲＣモバイルデバイスの代理として又はそれ自体のためにインターネットにＩＰｖ６接続するためにＡＡＡサーバから認証及び認可を要求するように構成された少なくとも１つのアプリケーションレベルコンピュータプログラムを実行し、新しいエントリがルーティングテーブルに挿入された場合、ＳＮＭＰ ＧＥＴに基づく同期方法を使用してルーティングテーブルを定期的に検索するか、又はＳＮＭＰ ＴＲＡＰに基づく非同期方法を使用して、ルーティングテーブルにおける「リアルタイム」変化を報告して、近傍デバイスのアドレスを検索するように動作可能な拡張ＩＰｖ６ ＭＩＢが構成されるＯＢＵ。

１７．ＷＡＶＥ及びＩＥＥＥ８０２．１１ｐに準拠し、デュアル無線機能を構成可能であり、近傍非ＤＳＲＣモバイルデバイスの代理として又はそれ自体のために、サブスクライブする任意のサービスへのアクセスのためにＡＡＡサーバから認証及び認可を要求するように構成された少なくとも１つのアプリケーションレベルコンピュータプログラムを実行し、新しいエントリがルーティングテーブルに挿入された場合、ＳＮＭＰ ＧＥＴに基づく同期方法を使用してルーティングテーブルを定期的に検索するか、又はＳＮＭＰ ＴＲＡＰに基づく非同期方法を使用して、ルーティングテーブルにおける「リアルタイム」変化を報告して、近傍デバイスのアドレスを検索するように動作可能な拡張ＩＰｖ６ ＭＩＢが構成されるＯＢＵ。

１８．ＡＡＡサーバへの要求の暗号化及びＡＡＡサーバからの応答の復号化からのＳＣＭＳエンロール証明書を使用して上記ＡＡＡサーバから「インターネットサブスクリプション」クレデンシャルを要求するように動作可能であり、インターネットへの上記ＩＰｖ６接続についての上記ＡＡＡサーバからの認証及び認可を要求する場合、上記クレデンシャルを使用するように動作可能である先の条項又は以下の条項の何れか一項に記載のＯＢＵ。

１９．要求にカプセル化されたＰＳＩＤによって識別された、マルチキャストサービスに発行されたＳＣＭＳクレデンシャルと共に認証要求が送信された後、ＥＣＩＥＳ復号化が、上記マルチキャストサービスによって提供されるマルチキャスト「プッシュ通知」のペイロードの対称復号化に必要なＥＣＩＥＳ暗号化パラメータ及びキーイング材料の復号化に使用される、先の条項又は以下の条項の何れか一項に記載のＯＢＵ。

２０．先の条項又は以下の条項の何れか一項に記載される、インターネットにＩＰｖ６接続するためにＯＢＵと通信するように構成されたモバイルデバイスであって、要求にカプセル化されたＰＳＩＤによって識別された、マルチキャストサービスに発行されたＳＣＭＳクレデンシャルと共に認可要求を送信した後、ＥＣＩＥＳ復号化が、上記マルチキャストサービスによって提供されるマルチキャスト「プッシュ通知」のペイロードの対称復号化に必要なＥＣＩＥＳ暗号化パラメータ及びキーイング材料の復号化に使用される、モバイルデバイス。

２１．専用狭域通信（ＤＳＲＣ）を利用して、インターネットを通して複数のユーザデバイス及び／又は１つ又は複数のユーザデバイスのサブネットを動作させるＯＢＵと通信して、車載ユニット（ＯＢＵ）及び路側ユニット（ＲＳＵ）間の通信を促進するシステムであって、ＯＢＵ及びＲＳＵ間でメッセージを伝送するサーバであって、上記サーバは、ユーザデバイスを認証し、無線アクセス乗物環境（ＷＡＶＥ）サービスチャネルへのアクセスについてユーザデバイスを認可し、上記ＡＡＡサーバによって適切に認証され認可された上記ユーザデバイスのそれぞれによる帯域幅消費を会計するように構成された少なくとも１つのコンピュータプログラムを実行する少なくとも１つのプロセッサを有する、サーバ
を有するシステム。

２２．専用狭域通信（ＤＳＲＣ）基盤機関により又は専用狭域通信基盤機関の代理として動作する複数のサーバを有する先の条項の何れか一項に記載のシステム。

２３．先の条項の何れか一項に記載のシステム。

本開示、条項、特許請求の範囲、及び図は、単独で、又は本明細書における図、条項、及び／又は特許請求の範囲を含む本開示において記載される同じ又は任意の他の態様又は例示的な実施形態からの任意に１つ又は複数の要素、特徴、構造、機能、及び／又はステップと組み合わせて、本明細書における図、条項、及び／又は特許請求の範囲を含む本開示において記載される任意の態様及び／又は例示的な実施形態の任意の要素、特徴、構造、機能、及び／又はステップを記載する任意の特許請求の範囲をサポートすると見なされるべきである。

以下の引用文献は参照により本明細書に援用される。
WAVE: IEEE WIRELESS ACCESS IN VEHICULAR ENVIRONMENTS(WAVE)-IEEE 1609 SERIES, http://www.techstreet.com/standards/ieee-wireless-access-in-vehicular-environments-wave-ieee-1609-series?sid=goog&gclid=Clbc#ZfFxs0CFQ6naQodjolKlg&product#id=1893147において入手可能。
IEEE 802.11p: IEEE STANDARD 802.11p-2010-IEEE Standard for Information technology- Local and metropolitan area networks-Specific requirements-Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6:Wireless Access in Vehicular Environments, https://standards.ieee.org/findstds/standard/802.11p-2010.htmlにおいて入手可能
米国特許出願第１４／１５１，０３５号, http://www.google.com/patents/US20140195102において入手可能
SCMS Vehicle-to-Vehicle Security Credential Management System; Request for Information, A Notice by the National Highway Traffic Safety Administration on 10/15/2014, http://federalregister.gov/a/2014-24482において入手可能
Request For Comments (RFC) 4861 (Neighbor Discovery for IPv6) September 2007, https://tools.ietf.org/html/rfc4861において入手可能
RFC 4862 (Stateless Address Autoconfiguration) September 2007, https://tools.ietf.org/html/rfc4862において入手可能
RFC 6275 (Mobility Support in IPv6) July 2011, https://tools.ietf.org/html/rfc6275において入手可能
RFC 5635 (Remote Triggered Black Hole Filtering) August 2009, https://tools.ietf.org/html/rfc5635において入手可能
RFC 4271 (Border Gateway Protocol 4) January 2006, https://tools.ietf.org/html/rfc4271において入手可能
RFC 4291 (IPv6 Addressing Architecture) February 2006, https://tools.ietf.org/html/rfc4291において入手可能
V2V Readiness Report DOTHS 812 014 August 2014. Vehicle-to-Vehicle Communications: Readiness of V2V Technology for Application, http://docplayer.net/13180-Dot-hs-812-014-august-2014-vehicle-to-vehicle-communications-readiness-of-v2v-technology-for-application.htmlにおいて入手可能

上述した全ての米国特許及び特許出願並びに上記で参照された全ての記事、文献、論文、明細書等は、参照により本明細書に援用される。

Claims (6)

1. 車載ユニット（ＯＢＵ）及び路側ユニット（ＲＳＵ）間でメッセージを伝送する、専用狭域通信基盤機関により又は専用狭域通信基盤機関の代理として動作するＡＡＡサーバであって、前記ＡＡＡサーバは、インターネットを通して、複数のユーザデバイス及び／又は１つ又は複数のユーザデバイスのサブネットを動作させるＯＢＵ、複数のＲＳＵと通信するように構成された少なくとも１つのコンピュータプログラムを実行して、認証、認可、及び会計（ＡＡＡ）の機能を実行し、前記機関が、前記ユーザデバイス及び／又は前記ＯＢＵを認証し、それによりサブスクライブされる任意のサービスへのアクセスに関して前記ユーザデバイス及び／又は前記ＯＢＵを認可できるようにする少なくとも１つのプロセッサを有し、
   前記ＡＡＡサーバは、前記認証及び認可にあたりセキュリティクレデンシャル及び管理システム（ＳＣＭＳ）の構成要素からの支援を要求するように動作可能であり、
   （ｉ）前記認証は、前記ユーザデバイス及び／又は前記ＯＢＵから受信されたログオンメッセージ内にカプセル化されたデジタル署名の確認からなり、前記署名は、前記ＳＣＭＳによって前記ＯＢＵに発行されたエンロール証明書を用いて生成され、
   （ｉｉ）前記認可は、前記ユーザデバイス及び／又は前記ＯＢＵ用の一意の識別子を復号化することによって可能となり、前記識別子は、暗号化されて前記ログオンメッセージ内にカプセル化され、前記ＡＡＡサーバに発行され、前記ＡＡＡサーバと同一のドメイン内で動作しているＲＳＵによりブロードキャストされる無線アクセス車両環境（ＷＡＶＥ）サービスアドバタイズメント（ＷＳＡ）を通してＯＢＵに伝搬される前記証明書の公開鍵を、前記暗号化は使用する、ＡＡＡサーバ。
2. 一つ又は複数のリモートＡＡＡサーバからのエンロール証明書又は前記ＳＣＭＳからの前記エンロール証明書がプロビジョニングされたＯＢＵの代理として、前記リモートＡＡＡサーバから転送されるログオンメッセージを受信するように動作可能であり、前記ＯＢＵ又は前記リモートＡＡＡサーバのいずれかからの要求にカプセル化されたＰＩＩを復号化するように動作可能であり、前記ＰＩＩとの一致について非リモートＡＡＡデータベースを照会し、認証を認めるか、又は拒絶理由を説明するコードと共に認証を拒絶するメッセージを要求側ＯＢＵ又はリモートＡＡＡに返す、請求項１に記載のＡＡＡサーバ。
3. 前記ユーザデバイスのＩＰｖ６アドレスに直接又は間接的にＵＤＰ／ＩＰ認証チャレンジメッセージを送信し、前記ＡＡＡサーバによって前記ユーザデバイスに発行された前記証明書を使用して生成されたデジタル署名を組み込んだ、前記認証チャレンジメッセージへの応答を処理するように動作可能であり、前記ＡＡＡサーバからのエンロール証明書を受信したユーザデバイスの代理としてリモートＡＡＡサーバから転送された認証要求を受信するように動作可能であり、前記ユーザデバイス又は前記リモートＡＡＡサーバのどちらかからの要求に組み込まれたＰＩＩを復号化するように動作可能であり、前記ＰＩＩとの一致について非リモートＡＡＡデータベースを照会し、認証を認めるか、又は拒絶理由を説明するコードと共に認証を拒絶するメッセージを要求側に返す、請求項２に記載のＡＡＡサーバ。
4. 前記ＯＢＵ、又は、認証及び認可を要求する前記ユーザデバイスによって使用される前記証明書を発行した証明書管理エンティティのドメイン名が、リモートＡＡＡサーバを識別する場合、ＳＣＭＳ信頼チェーンから得られたクレデンシャルを使用して前記リモートＡＡＡサーバとセキュア通信して、前記要求を前記リモートＡＡＡサーバに転送するように動作可能である、請求項２に記載のＡＡＡサーバ。
5. 前記ＡＡＡサーバからの認証チャレンジメッセージに応答するためにユーザデバイスによって使用される前記証明書を発行した証明書管理エンティティのドメイン名が、リモートＡＡＡサーバを識別する場合、ＳＣＭＳ信頼チェーンから得られたクレデンシャルを使用して前記リモートＡＡＡサーバとセキュア通信して、前記認証チャレンジメッセージに対する応答を前記リモートＡＡＡサーバに転送するように動作可能である、請求項３に記載のＡＡＡサーバ。
6. 前記要求にカプセル化されたＰＳＩＤによって識別された、マルチキャストサービスに発行されたＳＣＭＳ証明書と共にサインされた認証及び認可要求を受信すると、ＥＣＩＥＳが、前記マルチキャストサービスによって提供されたマルチキャスト「プッシュ通知」のペイロードの対称暗号化に必要なパラメータ及びキーイング材料の暗号化及び要求側デバイスへの送信に使用される、請求項１～５の何れか一項に記載のＡＡＡサーバ。