特表 2024-528854 車両データ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-08-01

(54)【発明の名称】車両データ

(51)【国際特許分類】

   H04L 45/24 20220101AFI20240725BHJP

   H04L 61/4511 20220101ALI20240725BHJP

   H04W 4/40 20180101ALI20240725BHJP

   H04W 40/02 20090101ALI20240725BHJP

【ＦＩ】

H04L45/24

H04L61/4511

H04W4/40

H04W40/02

【審査請求】未請求

【予備審査請求】有

(21)【出願番号】P 2024503852

(86)(22)【出願日】2022-07-26

(85)【翻訳文提出日】2024-03-06

(86)【国際出願番号】 EP2022070894

(87)【国際公開番号】W WO2023006716

(87)【国際公開日】2023-02-02

(31)【優先権主張番号】2110791.7

(32)【優先日】2021-07-27

(33)【優先権主張国・地域又は機関】GB

(81)【指定国・地域】

(71)【出願人】

【識別番号】524027329

【氏名又は名称】キュービック テレコム リミテッド

【氏名又は名称原語表記】ＣＵＢＩＣ ＴＥＬＥＣＯＭ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】230118913

【弁護士】

【氏名又は名称】杉村 光嗣

(74)【代理人】

【識別番号】100180655

【弁理士】

【氏名又は名称】鈴木 俊樹

(72)【発明者】

【氏名】フランク モナハン

(72)【発明者】

【氏名】ダミアン パワー

(72)【発明者】

【氏名】マーク コンキャノン

(72)【発明者】

【氏名】バリー ネイピア

【テーマコード（参考）】

5K030

5K067

【Ｆターム（参考）】

5K030GA13

5K030HA08

5K030HC09

5K030HD03

5K030LB06

5K067DD11

5K067EE02

5K067EE10

(57)【要約】

車載データトラフィックを分類する方法が提供される。
【選択図】図２

【特許請求の範囲】

【請求項1】

車載データトラフィックを分類するネットワークノードにおける方法であって、
前記ネットワークノードにおいて、第１のネットワークネームスペース及び第２のネットワークネームスペースを定義し、
前記第１のネットワークネームスペースは、着信リクエストデータパケットを受信し、レスポンスデータパケットを配信するように構成されたイングレスネットワークインタフェースを含み、前記第２のネットワークネームスペースは、着信レスポンスデータパケットを受信し、リクエストデータパケットを配信するように構成されたエグレスネットワークインタフェースを含み、チャネルは、前記イングレスネットワークインタフェースと前記エグレスネットワークインタフェースとの間のトラフィックが前記チャネルを介してルーティングされるように、前記第１のネットワークネームスペースと前記第２のネットワークネームスペースとの間に設けられ、
車両から複数の着信リクエストデータパケットを前記ネットワークノードで受信し、前記データパケットは前記車両で実行中のアプリケーションから発信されることと、
前記複数の着信リクエストデータパケットの各データパケットについて
前記データパケットのヘッダから前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは前記車両と関連付けられ、
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記宛先ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットのヘッダを検査することにより、着信データパケットのデータ量を決定することと
前記宛先ＩＰアドレスをルーティングテーブルと照合し、
前記宛先ＩＰアドレスが前記ルーティングテーブル内で定義されていると判断された場合、前記着信データパケットを、前記宛先ＩＰアドレスのために定義されたチャネルを通じてルーティングし、又は
前記宛先ＩＰアドレスが前記ルーティングテーブル内で定義されていないと判断された場合、前記着信データパケットを、定義されていないすべての宛先ＩＰアドレスに提供されるデフォルトチャネルを通じてルーティングすることと、
前記着信リクエストデータパケットの決定されたデータ量に基づいて、チャネルボリュームのインジケータを更新することと
前記ネットワークノードから前記複数の着信リクエストデータパケットを、それぞれの前記リクエストデータパケットに関連付けられた前記宛先ＩＰアドレスに送信する、方法。

【請求項2】

前記着信リクエストデータパケットは、少なくとも部分的にセルラデータネットワークを介して受信される、請求項1に記載の方法。

【請求項3】

前記ルーティングテーブルは、同一の宛先ＩＰアドレスのトラフィックに対して同一のチャネルを使用する、請求項1又は請求項2に記載の方法。

【請求項4】

前記複数の着信リクエストデータパケットを前記ネットワークノードから前記宛先ＩＰアドレスへ送信することに応答して、前記ネットワークノードで複数の着信レスポンスデータパケットを受信することと
前記複数の着信レスポンスデータパケットの各データパケットについて
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記ＩＰアドレスは前記車両に関連付けられ、
前記データパケットのヘッダから、前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットの前記ヘッダを検査することにより、前記着信データパケットのデータ量を決定することと、
前記送信元ＩＰアドレスを前記ルーティングテーブルと照合し、且つ
前記送信元ＩＰアドレスが前記ルーティングテーブル内に定義されていると判断した場合、その送信元ＩＰアドレスに対して定義されたチャネルを通じて着信データパケットをルーティングし、又は、
前記送信元ＩＰアドレスが前記ルーティングテーブル内に定義されていないと判断した場合、前記着信データパケットを、未定義のすべての送信元ＩＰアドレスに対して定義されたデフォルトチャネルを通じてルーティングし
前記着信リクエストデータパケットの決定されたデータ量に基づいて、チャネルボリュームのインジケータを更新することと、
前記複数の着信レスポンスデータパケットの各々を、前記ネットワークノードから、前記レスポンスデータパケットの各々に対するＩＰアドレスに関連付けられた各車両に送信する、先行する任意の請求項に記載の方法。

【請求項5】

前記送信は、少なくとも部分的にセルラデータネットワークを使用して行われる、請求項４に記載の方法。

【請求項6】

前記ルーティングテーブルは、同一の送信元ＩＰアドレスのトラフィックに対して同一のチャネルを使用する、請求項４又は５に記載の方法。

【請求項7】

複数の前記チャネルの各々が、前記車両で実行される個別のアプリケーションに関連付けられている、請求項１から６のいずれか一項に記載の方法。

【請求項8】

前記ルーティングテーブル内で前記チャネルを定義することを含み、前記方法は、特定のチャネルに関連付けられたＩＰアドレス宛のトラフィックが、前記チャネルを通じてルーティングされるように、既知のＩＰアドレス値を特定のチャネルに関連付けることを含む、請求項１から７のいずれか一項に記載の方法。

【請求項9】

前記ルーティングテーブルを動的に更新することをさらに含み、前記方法は、着信ＤＮＳリクエストデータパケットに対して、まず、ＤＮＳクエリ内のドメインを定義された式の集合に対して照合することによってパケット検査を実行することを含み、各定義された式は特定のサービスと関連付けられ、一致が見つかった場合、この方法は、リクエストデータパケットに対するレスポンスデータパケットを受信する際に、これらのＩＰアドレスへの後続のトラフィック、及びこれらのＩＰアドレスからの後続のトラフィックが、ＤＮＳリクエストデータパケットに対して最初に一致した特定のサービスに関連するチャネルを通過するように、ドメインのＩＰアドレス又はアドレスでルーティングテーブルを更新することを含む、請求項１から８のいずれか一項に記載の方法。

【請求項10】

前記ルーティングテーブルを動的に更新することをさらに含み、
前記方法は、アップストリームのＴＬＳパケットを監視して、ＴＬＳハンドシェイクを識別することと、
前記ＴＬＳハンドシェイクが前記パケットを検査してＳＮＩヘッダが含まれているかどうかを判断するプロセス中であると判断した場合、ＳＮＩヘッダが見つけ、そのヘッダの値を抽出し、且つ、その値をサービスごとに定義されたＳＮＩマッチングルールと比較し、
ＳＮＩルールが一致した場合、そのルールを所有するサービスの前記ルーティングテーブルを前記ＴＬＳパケットの前記宛先ＩＰアドレスヘッダで更新する、請求項１から９のいずれか一項に記載の方法。

【請求項11】

プロセッサ、第１のネットワークインターフェース、及び第２のネットワークインターフェースを含むネットワークノードであって、前記ネットワークノードは、請求項１から１０のいずれか一項に記載の方法を実行するように構成される、ネットワークノード。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークトラフィックを分析するための方法及びシステムに関する。特に、本発明は、車両とデータサービスプロバイダとの間のデータトラフィックの分析を提供する方法及びシステムに関する。

【背景技術】

【0002】

車内のインターネットトラフィック使用量は年々増加している。ビデオ及びオーディオのストリーミングサービス、ナビゲーションシステム、ユーザ生成コンテンツの共有などの提供は、ユビキタスになってきている。多くの新車はインターネット接続を備えて納車される。これを可能にする他の方法には、車両の車載診断（ＯＢＤ）システムに後付けできるサードパーティ製Ｗｉ－Ｆｉデバイスの使用が含まれる。接続方法に関係なく、接続は通常、車両とリクエストされたトラフィックに関連する適切なデータサービスプロバイダの間でデータトラフィックを適切にルーティングするセルラネットワークを通じて提供される。これらのサービスプロバイダの例としては、Ｎｅｔｆｌｉｘ、Ｓｐｏｔｉｆｙ、グーグルなどがある。

【0003】

図１は、従来の車載ネットワークデータ提供の簡略化したアーキテクチャを示している。車両１０５は、セルラネットワーク１１０を通じてセルラサービスプロバイダ１１５と通信するように構成される。セルラネットワークは、トラフィックの出入り口となることによって、車両１０４から外部パケットデータネットワーク（ＰＤＮ）への接続を提供するパケットデータネットワークゲートウェイ、ＰＧＷなどの従来のネットワークコンポーネントを含む。セルラサービスプロバイダ１１５は、車両１０５に関連付けられている。セルラサービスプロバイダ１１５を介して、ネットワークサービスにアクセスすることを認可された車両は、通常、国際移動加入者識別子（IMSI）、又はその車両の他の固有のモバイルデバイス識別子を使用して識別される。ネットワークサービスへのアクセスリクエストを受信すると、サービスプロバイダ１１５は、クラウドベースのサービスプロバイダ１２０として図１の概略図に示されている適切なネットワークサービスプロバイダにトラフィックをルーティングする。図１のアーキテクチャでは、車両１０５は、エンドポイントデータ消費デバイス(end point data consuming device)として、モバイルデバイスネットワークとほぼ同じように動作する。実際には、サービスプロバイダ１１５で起こることは、認可された車両からのトラフィックが、トラフィックリクエストに関連付けられた適切な宛先にルーティングされるということである。例えば、リクエストが音楽ストリーミングサービスに対するものである場合、そのリクエストはインターネットベースの音楽ストリーミングサービスにルーティングされる。リクエストがビデオストリーミングの場合、リクエストはインターネットベースのビデオストリーミングサービスにルーティングされる。どちらの場合も、サービスプロバイダ１１５は、単にこれらのサービスと車両との間のトラフィックをルーティングする。従来の取り決めでは、サービスプロバイダ１１５は、これらのリクエストを一般的にデータサービスとして分類するだけであり、異なるタイプのデータサービスを区別する能力を有していない。

【0004】

車両データトラフィックをきめ細かいサービスレベルで分類すること、また、サービスごとに使用されるトラフィックの量を任意のレベルで細分化することには課題がある。車内トラフィックに関する詳細な分析が欠如しているため、ネットワークの使用状況をあらゆるレベルで詳細に特定する能力が低下し、且つ、セキュリティ及び運用上の問題を含む異常を特定する能力が低下する。

【0005】

また、車両製造業者が自社の車両アクセスを専用のサービスプロバイダ１１５に事前に関連付けることができるが、車両内でどのようなデータサービスが消費されるかを管理できる必要があるという問題もある。

【0006】

また、特定のネットワークトラフィックが特定のネットワークデータサービスプロバイダに関連するものであることを識別できるようにし、そのトラフィックを専用チャネルでルーティングしやすくする必要もある。

【0007】

これらの理由から、ネットワーク内で利用される実際のデータサービスに関して、より細分性を高める必要がある。

【発明の概要】

【0008】

したがって、本出願の第１の実施形態は、請求項１に定義された方法を提供する。有利な実施形態は、従属請求項にて提供する。また、この方法を提供するように構成されたネットワークノードも提供する。

【0009】

本発明の一態様によれば、ネットワークノードにおいて車内データトラフィックを分類する方法が提供され、この方法は以下を含む。

【0010】

前記ネットワークノードにおいて、第１のネットワークネームスペース及び第２のネットワークネームスペースを定義し、
前記第１のネットワークネームスペースは、着信リクエストデータパケット(incoming response data packets)を受信し、レスポンスデータパケットを配信するように構成されたイングレスネットワークインタフェースを含み、
前記第２のネットワークネームスペースは、着信レスポンスデータパケット(incoming response data packets)を受信し、リクエストデータパケットを配信するように構成されたエグレスネットワークインタフェースを含み、
チャネルは、前記イングレスネットワークインタフェースと前記エグレスネットワークインタフェースとの間のトラフィックが前記チャネルを通じてルーティングされるように、前記第１のネットワークネームスペースと第２のネットワークネームスペースとの間に提供されることと、
車両から、前記ネットワークノードで複数の着信リクエストデータパケットを受信し、前記データパケットは、前記車両において実行されるアプリケーションから発信され、
複数の着信リクエストデータパケットの各データパケットについて、
前記データパケットのヘッダから前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは前記車両と関連付けられ、
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記宛先ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットのヘッダを検査することによって、着信データパケットに対するデータ量を決定することと、
前記宛先ＩＰアドレスをルーティングテーブルと照合し、
前記宛先ＩＰアドレスが、前記ルーティングテーブル内で定義されていることを確認したら、前記宛先ＩＰアドレスに定義されたチャネルを通じて前記着信データパケットをルーティングし、又は、
前記宛先ＩＰアドレスが、前記ルーティングテーブル内で定義されていないと判断した場合、未定義のすべての宛先ＩＰアドレスに用意されたデフォルトチャネルを通じて前記着信データパケットをルーティングすることと、
前記着信リクエストデータパケットについて決定されたデータ量に基づいてチャネルボリュームのインジケータを更新することと、
前記ネットワークノードから前記複数の着信リクエストデータパケットを、それぞれの前記リクエストデータパケットに関連付けられた前記宛先ＩＰアドレスに送信する。
前記着信リクエストデータパケットは、セルラデータネットワークを通じて、少なくとも部分的に受信されることが望ましい。
前記ルーティングテーブルでは、同一の宛先ＩＰアドレストラフィックに同じチャネルを使用することが望ましい。

【0011】

望ましくは、この方法は以下を含む。
前記複数の着信リクエストデータパケットを前記ネットワークノードから前記宛先ＩＰアドレスに送信することに応答して、前記ネットワークノードで複数の着信レスポンスデータパケットを受信することと、
前記複数の着信レスポンスデータパケットの各データパケットについて、
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記ＩＰアドレスは前記車両に関連付けられ、
前記データパケットのヘッダから、前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットの前記ヘッダを検査することによって、前記着信データパケットに対するデータ量を決定することと、
前記送信元ＩＰアドレスを前記ルーティングテーブルと照合し、且つ
前記送信元ＩＰアドレスが、前記ルーティングテーブル内で定義されていることを判断した場合、前記送信元ＩＰアドレスに定義されたチャネルを通じて前記着信データパケットをルーティングし、又は、
前記送信元ＩＰアドレスが、前記ルーティングテーブル内で定義されていないと判断した場合、未定義のすべての前記送信元ＩＰアドレスに用意されたデフォルトチャネルを通じて前記着信データパケットをルーティングし、
前記着信リクエストデータパケットについて決定されたデータ量に基づいてチャネルボリュームのインジケータを更新することと、
前記複数の着信レスポンスデータパケットの各々を、前記ネットワークノードから、前記レスポンスデータパケットの各々に対する前記宛先ＩＰアドレスに関連付けられた各車両に送信することと、前記宛先ＩＰアドレスは、前記レスポンスデータパケットの各々についてのモバイルデバイスＩＤとして関連付けられるか、又はプロキシとして機能することが理解されるであろう。

【0012】

前記送信は少なくとも部分的にセルラデータネットワークを使用して行われることが望ましい。

【0013】

前記ルーティングテーブルは、同一の送信元ＩＰアドレストラフィックに対して、同じチャネルを使用することが望ましい。

【0014】

複数の前記チャネルのそれぞれは、前記車両で実行される個別のアプリケーションに関連付けられることが望ましい

【0015】

本方法は、前記ルーティングテーブル内で前記チャネルを定義することを含み、特定のチャネルに関連付けられたＩＰアドレス宛のトラフィックが前記チャネルを通じてルーティングされるように、既知のＩＰアドレス値を特定のチャネルに関連付けることを含むことが望ましい。

【0016】

本方法は、前記ルーティングテーブルを動的に更新することを含み、本方法は、着信ＤＮＳリクエストデータパケットに対して、まず、定義された式の集合に対して、ＤＮＳクエリ内のドメインを前記定義済み式の集合に対して照合することによってパケット検査を実行することを含み、前記各定義式は、特定のサービスに関連付けられ、かつ、一致が見出された場合に、前記リクエストデータパケットに対するレスポンスデータパケットを受信する際に、これらのＩＰアドレスへの後続のトラフィック、及びこれらのＩＰアドレスからの後続のトラフィックが、ＤＮＳリクエストデータパケットに対して最初に一致した特定のサービスに関連するチャネルを通過するように、ドメインのＩＰアドレス又はアドレスでルーティングテーブルを更新することが望ましい。

【0017】

本方法は、前記ルーティングテーブルを動的に更新することを含むことが望ましい。
ＴＬＳハンドシェイクを識別するためにアップストリームのＴＬＳパケットを監視することと、
ＴＬＳハンドシェイクが前記パケットを検査してＳＮＩヘッダが含まれているかどうかを判断するプロセス中であると判断した場合、
ＳＮＩヘッダが見つけ、ヘッダの値を抽出し、且つ、その値を各サービスに定義されたＳＮＩマッチングルールと比較し、ＳＮＩルールが一致する場合、前記ＴＬＳパケットの前記宛先ＩＰアドレスヘッダを使用して、そのルールを所有するサービスの前記ルーティングテーブルを更新する。

【0018】

本発明のさらなる態様によれば、プロセッサと第１のネットワークインターフェースと、第２のネットワークインターフェースを含むネットワークノードが提供され、
ネットワークノードは、本方法を実行するように構成されることが望ましい。

【図面の簡単な説明】

【0019】

次に、添付図面を参照して本出願を説明する。

【図1】図１は、従来技術によるシステムのネットワークアーキテクチャを示す概略図である。

【図2】図２は、本発明によるシステムのネットワークアーキテクチャを示す概略図である。

【図3】図３は、特定の車両との間で送受信されるトラフィックを分析する特定のインスタンスにおけるアーキテクチャを示す概略図である。

【図4】図４は、車両から発信されたデータがどのようにルーティングされ得るかを示すプロセスフロー図である。

【図5】図５は、車両宛てのデータをルーティングする方法を示すプロセスフロー図である。

【図6】図６は、本教示のシステムを用いて生成することができるチャネルごとのデータサービスの概要を示すヒストグラムの一例である。

【図7】図７は、本教示に従って使用できるＤＮＳルックアッププロセスフローの一部の例である。

【図8】図８は、本教示に従って使用できるＤＮＳルックアッププロセスフローの別の部分の例である。

【図9】図９は、本教示に従って使用できるＴＬＳパケット検査プロセスフローの例である。

【発明を実施するための形態】

【0020】

図２は、本発明による処理又は分類システム２００を統合するネットワークアーキテクチャである。処理又は分類システム２００は、そこを通過するネットワークトラフィックを宛先サービスに分類し、サービスごとのトラフィック量を報告するように構成されている。システム２００は、車両１０５から受信した任意のトラフィックの最終的な目的地を識別し、その識別された宛先をその車両１０５で消費されているデータサービスの分類器として使用するように構成されている。

【0021】

データパケットの形式で受信される車両１０５からの着信トラフィックは、そのトラフィックの宛先ＩＰアドレスを識別するために解析される。宛先ＩＰアドレスを決定すると、システム２００は、そのＩＰアドレスが既知のデータサービスプロバイダに事前に関連付けられているかどうかを判断するように構成される。既知のデータサービスプロバイダが存在すると判断すると、システムは、そのデータサービスプロバイダのトラフィック専用のシステム内のチャネルを通じて、その着信トラフィックをチャネルする。データサービスプロバイダA宛てのトラフィックはチャネルＡ経由でルーティングされ、データサービスプロバイダＢ宛てのトラフィックはチャネルＢ経由でルーティングされる。宛先ＩＰアドレスに基づいて専用チャネルを介してトラフィックをチャネル化することにより、パケットの実際のペイロードの任意の調査を必要とせずに、ヘッダ情報に基づいてトラフィックを分析及び分類できる。これにより、トラフィックのリアルタイムの最小遅延分類（minimal delay classification）が容易になる。

【0022】

したがって、本発明による分類システムは、任意の１つのチャネルを通過するデータ量が特定のデータサービスの実際の使用状況を反映し、監視、報告、又はその他の方法で制御され得ることを確実にする。

【0023】

システム機能は５つのコアブロック２０５～２２５で視覚化することができるが、これは理解を容易にするためであり、１つのブロックに関して、以下に説明する機能は別のブロックによって同様に提供できることが理解されるであろう。機能的には、特定の実装に制約されないが、システムは以下を含むと理解できる。

【0024】

コンフィギュレーションマネージャ２０５
コンフィギュレーションマネージャ２０５は、構成オプションを検証し、構成の更新をシステム２００の他のコンポーネントに公開する。

【0025】

ＤＮＳモニタ２１０
ＤＮＳモニタ２１０は、システムを通過するＤＮＳトラフィックをスキャンし、コンフィギュレーションマネージャのデータ構造内で定義されたサービスルールに対するクエリとレスポンスを比較し、一致が見つかった場合にルーティングコントローラ２２０に更新を公開する。

【0026】

ＳＮＩモニタ２１５
ＳＮＩモニタ２１５は、ＴＬＳハンドシェイクをスキャンし、サービス一致ルールをＳＮＩヘッダに適用する。一致するものが見つかると、更新がルーティングコントローラ２２０に公開される。

【0027】

ルーティングコントローラ２２０
ルーティングコントローラは、システム２００を通過するトラフィックの暗黙的な分類を可能にするようにルーティングテーブルを構成する。初期ルーティングテーブルの構成は、各サービスの構成に含まれるＩＰアドレスとネットワーク範囲に基づく。ただし、ルーティングコントローラは、ＤＮＳ及びＳＮＩモニタから受信した更新に応答して、実行時にルーティングテーブルを動的に変更することもできます。

【0028】

ＥＤＲジェネレータ２２５
ＥＤＲジェネレータ２２５は、システム内の各チャネルを流れるパケットのヘッダを監視し、車両ごとのサービスごとのトラフィックを要約した定期的な更新を公開する。

【0029】

分類システム２００のコンポーネント機能ブロック２０５～２２５は、管理システム２３０を使用して構成及び監視することができる。図２は、個別のデバイスである管理ネットワーク２３５上に設けられたこの管理システムを示すが、これは、分類システム２００を通過するトラフィックと能動的にインターフェースする機能コンポーネントから、管理及び後処理機能を視覚的に分離するための、概略的な目的のためのものであることが理解されるであろう。また、管理ネットワーク２３５は、ＥＤＲジェネレータ２２５によって公開されたＥＤＲデータを格納できるデータベース２４０と、データ分析エンジン２５０をホストすることもできる。任意選択の実施形態では、データベース２４０及び／又は分析エンジン２５０は、管理システム２３０とは別の１つ又は複数の追加デバイス上に提供されてもよい。図２のシステムの詳細の一部については、図３を参照して以下でさらに説明する。

【0030】

本発明の教示を任意の１つの特定のネットワークオペレーティングシステムなどに限定することは意図していないが、本目的のためには、分類システム２００は、３枚のネットワークカードを備えたＬＩＮＵＸ（登録商標）マシン（物理マシン又は仮想マシンであり得る）上でホストされることを仮定する。

【0031】

制御ＮＩＣ３１５は、システム２００と管理ネットワーク２３５との間の通信を提供する。制御ＮＩＣ３１５は、システム２００を管理するために使用される管理システム２３０から通信を送受信するために使用することができる。また、制御ＮＩＣ３１５は、ＥＤＲジェネレータ２２５からデータベース２４０及び分析エンジン２５０へのデータ送信を提供するためにも使用され得る。

【0032】

イングレスＮＩＣ３０５は、車両と通信するためにイングレスネットワークに接続される。そして、エグレスＮＩＣ３１０は、車両によってリクエストされるサービスなどの外部ネットワーク要素と通信するためにエグレスネットワークに接続される。

【0033】

分類システム２００内で発生する処理の少なくとも一部を概略形式で示す図３に示されるように、分類システムは、イングレスネームスペース３０１及びエグレスネームスペース３０２の２つのネットワークネームスペースを実行するように構成される。イングレスＮＩＣ３０５は、イングレスネームスペース３０１に位置し、エグレスＮＩＣ３１０はエグレスネームスペース３０２に位置する。イングレスネットワークは、リクエストパケットを受信し、レスポンスパケットを配信するために使用される。エグレスネットワークは、リクエストパケットの配信とレスポンスパケットの受信に使用されます。これらのパケットのルーティングは、ルーティングコントローラ２２０によって制御される。

【0034】

ネットワークネームスペースがＩＰスタックの独立した実装であることは、当業者には理解されよう。イングレスＮＩＣとエグレスＮＩＣを個別のネームスペースでホストすると、各ネットワーク上のトラフィックが効果的に分離される。ネットワーク間でパケットを転送するには、ネームスペース間でパケットを転送する必要がある。それぞれのネームスペース間のこの転送を実現するために、本教示のシステムは、それぞれのネームスペース間のローカルイーサネットトンネルの作成を可能にする仮想イーサネット（ＶＥＴＨ）の既知のＬｉｎｕｘ構成を採用する。ｖｅｔｈペアは、２つのエンドポイントを持つ仮想イーサネット接続である。一方のエンドポイントに書き込まれたパケットをもう一方のエンドポイントから読み取ることができ、その逆も同様である。図３のホストシステム内で、本教示は、ｖｅｔｈペア１～５を使用して、それぞれのペアの一端をイングレスネームスペース３０１内に配置し、他端をエグレスネームスペース３０２内に配置することによって、ネットワークネームスペースをブリッジする。

【0035】

トラフィックの分類を備えるためのシステムの初期構成の一部として、本教示では、最初に、分類される各サービスのイングレスネームスペースとエグレスネームスペースの間にｖｅｔｈペアを作成し、未分類のトラフィック用に１つの追加のｖｅｔｈペアを作成する。これらのｖｅｔｈペアは、分類されたトラフィックが通過するチャネルとして効果的に機能する。この例では、分類されるサービスはチャネルＡからＤで識別されるサービスであり、最後のチャネルであるチャネルＥは、分類されていないすべてのトラフィックがルーティングされるチャネルである。示されているチャネルの数は、単に説明を目的としたものであり、これも単に理解を容易にするために、チャネルＡは第１の音楽ストリーミングサービスに、チャネルＢはビデオストリーミングサービスに、チャネルＣは第２の音楽ストリーミングサービスに、チャネルＤは、Ｇｏｏｇｌｅマップによって提供されるようなナビゲーションサービスに使用され得ると考えることができることが理解され、チャネルＥは、他のすべてのインターネットトラフィック、ブラウジング、他のデータサービスプロバイダなど用である。このチャネル数又は特定のサービスとの関連付けは、システムの特定の要件に応じて変更できることが理解されよう。

【0036】

パケットベースのネットワークを通過する任意のパケットはヘッダとペイロードを含むことが理解されよう。ヘッダには、ペイロードを配信するためのデータ（送信元と宛先のネットワークアドレスなど）を提供する制御情報が含まれ、ペイロードにはユーザデータが含まれる。本システムは、車両発信パケットの宛先アドレスと車両終端パケットの送信元アドレスを検査することによってトラフィックを分類する。ルーティングテーブル内で特定のアドレスと特定のチャネルを関連付けるエントリを定義することにより、ヘッダ情報内の特定のアドレスを識別すると、ルーティングテーブル内のエントリを使用してパケットを適切なｖｅｔｈペアに転送することが可能となる。したがって、特定のチャネルを通じてトラフィックをルーティングする行為は、トラフィックを特定のタイプのデータサービスに関連付けられているものとして暗黙的に分類する。

【0037】

図４は、車両からのトラフィックのルーティングに関連するプロセスフローを示している。パケットは車両からイングレスＮＩＣに到着する（ステップ４０５）。従来、実際の車両識別子ＶＩＮ、又は車両のモバイル識別子ＩＭＳＩは、イングレスＮＩＣ３０５では表示されないことが理解されるであろう。従来のトラフィックセッションごとに、車両から発信されるトラフィックは、最初にパケットゲートウェイ（ＰＧＷ）にルーティングされ、パケットゲートウェイ（ＰＧＷ）は、セルラネットワーク１１０の従来のコンポーネントであると理解されるであろう。ＰＧＷは、セッションの間、車両にＩＰアドレスを割り当てる。ＰＧＷは、ＭＳＩＳＤＮ識別子をセッションに割り当てられたＩＰアドレスに関連付けるデータフィードも公開する。本教示によると、このフィードは、分析フェーズ中にＭＳＩＳＤＮが帯域外のＶＩＮ／ＩＭＳＩに解決されることができるため、その後、イングレス及びエグレスＮＩＣを介してルーティングされるトラフィックを調整するために使用され、サービストラフィックを特定の車両に帰属させることができる。例えば、システム２００を介してルーティングされるトラフィックの一部は、個々の車両１０５ａに帰属することができ、一方、トラフィックの他の部分は、車両１０５ｂ及び１０５ｃに帰属させることができる。通常、この調整は、分析エンジン２５０によるＰＧＷフィード及びＥＤＲジェネレータ２２５からのチャネルボリュームデータのオフライン処理を通じて行われる。したがって、分析エンジン２５０は、チャネルごと及び車両ごとにトラフィックを分析することができる。レスポンスパケットの宛先ＩＰアドレスとそれぞれの車両のＭＳＩＳＤＮとの間に関連性があることが理解されるであろうが、これは通常、パケットゲートウェイ（ＰＧＷ）でのみ知られる。このＩＰアドレスは特定の車両に関連付けることができるが、これは通常、ＰＧＷ自体としては行われない。それにも関わらず、一旦パケットがイングレスＮＩＣ３０１で車両から受信されると、宛先ＩＰアドレスについてヘッダが確認される（ステップ４１０）。そのＩＰアドレスが抽出され、次いでルーティングテーブルと照合される（ステップ４１５）。一致するものがあれば（ステップ４２０）、宛先ＩＰアドレスに従って、定義されたＶｅｔｈペアによって提供される適切なチャネルにルーティングされる（ステップ４２５）。

【0038】

宛先ＩＰアドレスに対して定義されたルーティングテーブル内に明示的なルートが定義されていないために一致しない場合（ステップ４２０）、パケットは、それ自身の特定のｖｅｔｈペアに関連付けられたデフォルトチャネル（ステップ４３０）にルーティングされる。図３の例では、このデフォルトチャネルはチャネル５で、他に分類されていないすべてのインターネットトラフィックに関連付けられている。

【0039】

どちらのシナリオ（一致又は一致しない）でも、パケットはエグレスネームスペースのｖｅｔｈペアを出て、サービスに関連付けられたアップストリームのゲートウェイを経由するか、明示的なゲートウェイが設定されていない場合はデフォルトゲートウェイを経由してルーティングされる。次いで、パケットは、送信元のエグレスＮＩＣに書き込まれる（ステップ４３５）。

【0040】

図５は、車両がトラフィックを終端する場合の同等のプロセスを示している。パケットはエグレスＮＩＣに到着し（ステップ５０５）、送信元ＩＰアドレス、すなわちパケットの発信元に従って、適切なｖｅｔｈペアにポリシールーティングされる。これは、送信元ＩＰアドレスのヘッダを確認し（ステップ５１０）、その識別された送信元アドレスのルーティングテーブルを確認する（ステップ５１５）ことによって達成される。明示的なポリシールートが存在しない場合（一致判定ステップ５２０で一致しない場合）、パケットはデフォルトのＶｅｔｈペアを介してルーティングされる（ステップ５３０）。明示的なポリシールートが存在する場合（一致判定ステップ５２０で一致）、パケットは、一致に関連付けられたチャネルにルーティングされる（ステップ５２５）。どちらのシナリオでも、パケットはイングレスネームスペースのｖｅｔｈペアを出て、宛先アドレスに関連付けられたダウンストリームゲートウェイ経由でルーティングされる。これらはイングレスＮＩＣ経由で送信される。

【0041】

ＩＰアドレスに従ってトラフィックを分類することにより、任意のチャネルを通過するトラフィックの量に関するデータを経時的に集約することができる。

【0042】

図６は、計算可能な時間の経過に伴うトラフィックのヒストグラムの例を示している。これは単に例示的なものであるが、車両又は車両のグループによって時間の経過とともに利用されるデータトラフィックの性質に関する有意義なデータを抽出できることを示していることが理解されるであろう。データは、パケットが各ｖｅｔｈペアを通過するときにパケットのヘッダを検査することにより、サービスごとのトラフィックを計算することによって集約される。図６のデータは、特定の車両１０５に対応する１つの特定のＩＰアドレスに関連付けられたチャネルごとのデータであってもよいし、システム２００を通るすべてのトラフィック（すなわち、複数の車両１０５ａからｃのトラフィック）に関連付けられた集約されたチャネルごとのデータであってもよい。

【0043】

車両発信パケットの場合、システムはパケット内のバイト数を記録し、パケットヘッダにある送信元ＩＰアドレスに関連付けることができる。車両終端パケットの場合、システムはヘッダのバイト数を記録し、パケットヘッダにある宛先ＩＰアドレスに関連付けるように設定できる。上で概説したように、送信元/宛先ＩＰアドレスは、ＰＧＷによって公開されたデータフィードとの比較を通じて特定の車両と関連付けることができる。このようにして、システムは各車両のサービスごとにアップロード及びダウンロードされたバイト数を維持できる。これらの統計は定期的に収集され、データ処理と分析のために送信され、その時点でカウントはリセットされるか、後で使用するためにアーカイブされる。

【0044】

システム２００によって収集された分類データは、集約されたデータセットとして出力され、保存及び／又はさらなる処理のためにデータベース２４０及び／又は分析エンジン２５０に送信される。

【0045】

一例では、チャネルごとのトラフィックデータを含む集約されたデータセットが、保存のためにシステム２００からデータベース２４０に送信される。分析エンジン２５０は、データベース２４０から集約されたデータセットを取得し、処理する。分析エンジン２５０は、特定のチャネル上のトラフィックを特定のＩＭＳＩ、車両及び／又は車両のグループと関連付けるために、集約されたデータセットをプラットフォームデータで強化する。たとえば、特定のブランド（例:ＶＷ、ポルシェなど）のすべての車両による特定のサービスプロバイダ（例:Ｎｅｔｆｌｉｘ、Ｓｐｏｔｉｆｙなど）の使用状況を、強化された集約データセットから推測することができ、これを請求データ及びレポートデータの提供に使用できる。

【0046】

分析エンジン２５０は、システム２００から出力されデータベース２４０に格納されたチャネルごと／ＩＰアドレスごとのトラフィックデータを取得し、それらを調整してサービスごと／車両ごとの同等のトラフィック概要を生成する。消費されたデータ（アップロード及びダウンロード）は、サンプリングされた頻度で収集され、データを消費するサービス（ユーザが契約したサービス）に対して保存される。

【0047】

システムを通過するパケットを有意義に分類するために必要なルーティングテーブルを作成するために、システムは特定のデータサービスプロバイダによって使用されているＩＰアドレスに関する知識を必要とする。Ｓｐｏｔｉｆｙ、Ｎｅｔｆｌｉｘなどの人気のあるデータサービスプロバイダが、それぞれのサービスのために既知の永久的なＩＰアドレス又はサブネットのリストを採用することが知られていることは理解されよう。これらは、そのサービスのトラフィックを分類する初期ルーティングコンフィギュレーションを作成するために使用される。

【0048】

しかし、この静的構成を強化するために、本システムは、ＤＮＳとＴＬＳパケットを検査することで、サービス用の新しいＩＰアドレスを動的に発見するようにも構成されている。

【0049】

この文脈では、従来のインターネットトラフィックのルーティングでは、クライアントデバイス上のアプリケーションがインターネットホストに接続したいが、そのホストの名前（例えばservices.cubictelecom.comなど）しか持っていない場合に、ＤＮＳルックアップがトリガされることが理解されるであろう。接続を開くには、デバイス（又はネットワークノード）上で実行されるアプリケーションは、アドレスが必要である。ＤＮＳの役割は、名前を検索し、関連するホストにコンタクトするために使用できる１つ以上のＩＰアドレスを返すことである。本教示によれば、特定のインターネットサービスが特定の車両によって使用されているかどうかのその後の分析を容易にするために、特定のトラフィックを特定のチャネルを通して誘導するために使用されるルーティングテーブルには、特定の既知のサービスごとに特定のＩＰアドレスが入力される。このように、ルーティングテーブルは、既知のサービスに対して既知のＩＰアドレスを使用し、それらのＩＰアドレスに関連付けられたチャネルを通じてそれらのサービスのトラフィックをルーティングする。

【0050】

特定のサービスには、それらのサービスに関連付けられた固定ＩＰアドレスがあり、本発明のシステムがトラフィック解析を必要とすると予想されるそれらのサービスについては、それらのサービスに関連付けられたチャネルのルーティングテーブルをそれらのＩＰアドレスで事前に設定することができる。複数のＩＰアドレスが１つのサービスプロバイダに関連付けられることもあり、本発明のルーティングテーブルは、１つの専用サービスのトラフィックをルーティングするために複数のＩＰアドレスを使用することに対応できることが理解されよう。

【0051】

その他のサービス、あるいは特定のサービスが特定のＩＰアドレスにトラフィックをジオフェンスする場合など、アプリケーションリクエストの処理に使用される実際のＩＰアドレスは、時間の経過とともに異なる可能性がある。本教示のシステムは、着信トラフィックを分析してサービスに関連するＩＰアドレスの変更を特定し、そのターゲットサービスの新しいＩＰアドレスが見つかったときにルーティングテーブルを更新することによって、この種の動的ＩＰアドレスに対処することができる。後続のパケットの分類に使用されるルーティングテーブルを動的に更新するこのような配置では、システムは、最初に正規表現のコレクションに対してＤＮＳクエリのドメインを照合することによって、ＤＮＳパケット（ＵＤＰポート５３）検査を実行するように構成することができる。システムの構成の一部として、分析チャネルが必要とされる各サービスは、照合する正規表現のセットを定義することができる。一致が見つかった場合、システムはリクエストＩＤをキャッシュし、対応するＤＮＳレスポンスを待つことができる。レスポンスが到着すると、ドメインに関連するＩＰアドレスがルーティングコントローラに転送され、ルーティングコントローラはサービスのルーティングテーブルエントリを更新する。レスポンスが到着すると、ドメインに関連付けられたＩＰアドレスがルーティングコントローラに転送され、ルーティングコントローラはサービスのルーティングテーブルエントリを更新する。これらのＩＰアドレスとの間で送受信される後続のトラフィックは、そのサービスに属するものとして分類される。

【0052】

場合によっては、照会されるドメインが一般的すぎて、サービスと関連付けることができないことがある。この場合、ＤＮＳルールは、ＤＮＳレスポンスのＣＮＡＭＥを照合するための追加ルールを含むことができる。レスポンスで返されたＩＰアドレスは、レスポンスがＣＮＡＭＥを含み、そのＣＮＡＭＥが提供されたルールのいずれかに一致する場合にのみ、ルーティングコントローラに転送される。

【0053】

図７及び図８は、本教示によるシステムが、適切なチャネルが使用されることを確実にするために、システムを通じてルーティングされるトラフィックをどのように解消できるかに関連する例示的なプロセスフローを示す概略図である。

【0054】

このプロセスは、ステップ７０５では、クライアントデバイスである車両がホストへの接続を開こうとするときに開始される。ステップ７１０では、クライアントデバイスはネームサーバにＤＮＳリクエストを送り、ホスト名を１つ以上のＩＰアドレスに解決する。ＤＮＳリクエストは、それがイングレスＮＩＣに到着すると識別される。ステップ７１５では、到着すると、リクエストは検査され、ホストが各サービスに定義されたルールと比較される。一致しない場合、リクエストＩＤは保存されないが（ステップ７３０）、ステップ７３５で、リクエストは依然としてＤＮＳネームサーバにルーティングされる。

【0055】

一致がある場合、ステップ７２０で、ホストに対して、ＤＮＳリクエストＩＤはキャッシュされ、ＤＮＳリクエストはエグレスＮＩＣを通過してＤＮＳネームサーバにルーティングされ、ＤＮＳネームサーバはリクエストを解決し、ＤＮＳレスポンスで返信する。

【0056】

ＤＮＳレスポンスがネームサーバから受信されると、ステップ７４０でＤＮＳレスポンスのレスポンスＩＤがリクエストＩＤキャッシュと照合され、ステップ７４１で、一致するかどうかが確認される。

【0057】

一致が見つかった場合、ステップ７４５で、システムはＡレコードをルーティングコントローラに転送するように構成されるが、Ａレコードはドメインに関連付けられたＩＰアドレスを含むＤＳＮレスポンスの部分であることを当業者は理解するであろう。その後、ルーティングコントローラは、関連するサービスのルーティングテーブルを更新する。

【0058】

ステップ７５０では、一致が見つかったか否かに関わらず、DNSレスポンスはリクエスト元のクライアントに送信される。

【0059】

ステップ７５５で、クライアントは、ＤＮＳレスポンスに含まれるＩＰアドレスの１つに接続を開く。

【0060】

ステップ７６０では、リクエストから生じるトラフィックは、ルーティングコントローラによって定義された正しいチャネルを経由してルーティングされる。

【0061】

図９のプロセスフローに従って、システムは、イングレスＮＩＣ上のすべてのアップストリームのＴＬＳパケット（ＴＣＰポート４４３）を監視するように構成することもできる。プロセスステップ８０５でＴＬＳハンドシェイクを識別すると、ステップ８１０でクライアントハンドシェイクパケットを検査し、ＳＮＩ（Ｓｅｒｖｅｒ Ｎａｍｅ Ｉｎｄｉｃａｔｉｏｎ）拡張ヘッダを含むかどうかを判断する。ＳＮＩヘッダが見つかった場合、ステップ８２０でヘッダの値が抽出され、各サービスに定義されたＳＮＩマッチングルールと比較される。サービスルールが一致すると、ステップ８２５で、パケットの宛先ＩＰアドレスがそのサービスの識別ＩＰアドレスであると仮定され、ステップ８３５で、宛先ＩＰアドレスがルーティングコントローラに転送される。ＤＮＳの一致の場合と同様に、ルーティングコントローラはサービス８４０のルーティングテーブルエントリを更新する。

【0062】

以上のことから、本教示によるシステムは、そのトラフィックを生成しているサービスに基づいて、ネットワークレベルでのデータ使用の分類を可能にすることが理解されよう。異なるデータサービスプロバイダのＩＰアドレスを特定することで、本教示によれば、ネットワークトラフィックを、これらの異なるデータサービスプロバイダに固有のチャネルを通してネットワークレベルでルーティングすることが可能になる。ルーティングは、ネットワークを通過するパケットのヘッダを解析し、送信元又は宛先ＩＰアドレスに基づいて特定のチャネルにパケットをルーティングすることによって行われる。このようにして、トラフィックの性質は、ネットワークを通過する個々のパケットを詳細にパケット分析する必要があるのとは対照的に、生成データサービスプロバイダのＩＰアドレスから推測される。

【0063】

本教示のシステムは、特定の車両から発信されたトラフィックを、異なるデータサービスプロバイダに固有のチャネルを介してルーティングするように構成されている。このようにして、特定の車両によって使用されているデータサービスの種類の詳細な概要がネットワークレベルで実現される。このシステムでは、例えばブラウジングアクティビティ又はクッキーなどを実際の車両に問い合わせる必要はない。分析は、ネットワークデバイスを通過するパケットに基づいて実行される。車両のデバイス識別子（通常はＩＭＳＩ）を使用することで、その車両から発信された、又は異なるデータサービスプロバイダからその車両にルーティングされたトラフィックを追跡することができる。これにより、データ使用量の監視が容易になるだけでなく、サービスブロック、使用中のデバイス又はデータサービスに基づくルーティング設定変更、課金データなどの追加機能も可能になる。

【0064】

本教示のシステムは、ブラウザ又は特定のアプリケーションレベルではなく、デバイス固有のレベルでのトラッキングを提供することが理解されよう。データ解析はデバイスごとに行われるが、トラフィックを推定するために統計的サンプリングを行うのとは対照的に、ネットワークを使用するすべてのデバイスを追跡し、ネットワーク上の指定されたすべてのデバイスのアクティビティを全体的に把握することが可能である。

【0065】

上記で詳述したように、本教示のシステムは、ウェブブラウザのようなアプリケーションからではなく、ネットワークレベルからリクエストを追跡するため、インターネットタイプのデータサービスプロバイダからのデータサービスに対するすべてのリクエストを確認し、追跡することが可能である。これにはウェブベースのサービスも含まれるが、テレマティクス、地図、その他のマシンツーマシンデータなどのマシンツーマシンサービス、ウェブサイトのリクエスト又はＮｅｔｆｌｉｘ／Ｓｐｏｔｉｆｙのようなストリーミングデータサービスのような消費者ベースのサービスのような、人間／ユーザ向けではないサービスも含まれる。

【0066】

データリクエストは、ネットワークを経由してくる生のリクエストレベルで追跡される。これは、他のトラフィック解析ツールとは異なり、ウェブブラウザからのリクエストを記録するもので、ターミナルウィンドウからのリクエスト、OSからのアップデートなど、他のリクエストは記録されない。

【0067】

データ分析システムの例示的な構成は、ネットワークノード内、例えば車両とデータサービスプロバイダとの間に配置されることが理解されよう。このシステムは、特定の車両から発信された、又は特定の車両に向けられたデータのパケットを解析し、それらのパケット内のヘッダ情報に基づいて、その車両によって使用されている特定のデータサービスの性質についてデータ解析を実行できるように、ネットワークノード内の特定のチャネルを介してパケットをルーティングするように構成される。以下の特許請求の範囲に照らして必要な限りにおいてのみ限定されることを意図する本出願の範囲から逸脱することなく、本明細書に記載されたものに変更を加えることができる。

【0068】

本明細書中で使用される、含む（ｃｏｍｐｒｉｓｅｓ）／含む（ｃｏｍｐｒｉｓｉｎｇ）という語は、記載された特徴、整数、ステップ又はコンポーネントの存在を特定するためのものであるが、１つ又は複数の他の特徴、整数、ステップ、構成要素又はそれらのグループの存在又は追加を排除するものではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【手続補正書】

【提出日】2023-05-09

【手続補正1】

【補正対象書類名】明細書

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークトラフィックを分析するための方法及びシステムに関する。特に、本発明は、車両とデータサービスプロバイダとの間のデータトラフィックの分析を提供する方法及びシステムに関する。

【背景技術】

【0002】

車内のインターネットトラフィック使用量は年々増加している。ビデオ及びオーディオのストリーミングサービス、ナビゲーションシステム、ユーザ生成コンテンツの共有などの提供は、ユビキタスになってきている。多くの新車はインターネット接続を備えて納車される。これを可能にする他の方法には、車両の車載診断（ＯＢＤ）システムに後付けできるサードパーティ製Ｗｉ－Ｆｉデバイスの使用が含まれる。接続方法に関係なく、接続は通常、車両とリクエストされたトラフィックに関連する適切なデータサービスプロバイダの間でデータトラフィックを適切にルーティングするセルラネットワークを通じて提供される。これらのサービスプロバイダの例としては、Ｎｅｔｆｌｉｘ、Ｓｐｏｔｉｆｙ、グーグルなどがある。

【0003】

ＵＳ２０１７２５１３３９Ａ１は、車両アドホックネットワークにおいて、送信元ノードから宛先ノードへデータパケットをルーティングするための経路を選択することを開示している。ＣＮ１０６９５３７８８Ｂは、第１の仮想ネットワークカード３１と第2の仮想ネットワークカード３２で構成される仮想ネットワークカード３を開示している。Ｎｇｕｙｅｎ Ｋｅｉｎら、「Ｅｍｐｏｗｅｒｉｎｇ ５Ｇ Ｍｏｂｉｌｅ Ｄｅｖｉｃｅｓ Ｗｉｔｈ Ｎｅｔｗｏｒｋ Ｓｏｆｔｗａｒｉｚａｔｉｏｎ」ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ ｎｅｔｗｏｒｋ ａｎｄ ｓｅｒｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ｖｏｌ．１８， ｎｏ．３ （２０２１）は、ネームスペースを使用したネットワークソフトウェアライゼーションを開示している。

【0004】

図１は、従来の車載ネットワークデータ提供の簡略化したアーキテクチャを示している。車両１０５は、セルラネットワーク１１０を通じてセルラサービスプロバイダ１１５と通信するように構成される。セルラネットワークは、トラフィックの出入り口となることによって、車両１０４から外部パケットデータネットワーク（ＰＤＮ）への接続を提供するパケットデータネットワークゲートウェイ、ＰＧＷなどの従来のネットワークコンポーネントを含む。セルラサービスプロバイダ１１５は、車両１０５に関連付けられている。セルラサービスプロバイダ１１５を介して、ネットワークサービスにアクセスすることを認可された車両は、通常、国際移動加入者識別子（IMSI）、又はその車両の他の固有のモバイルデバイス識別子を使用して識別される。ネットワークサービスへのアクセスリクエストを受信すると、サービスプロバイダ１１５は、クラウドベースのサービスプロバイダ１２０として図１の概略図に示されている適切なネットワークサービスプロバイダにトラフィックをルーティングする。図１のアーキテクチャでは、車両１０５は、エンドポイントデータ消費デバイス(end point data consuming device)として、モバイルデバイスネットワークとほぼ同じように動作する。実際には、サービスプロバイダ１１５で起こることは、認可された車両からのトラフィックが、トラフィックリクエストに関連付けられた適切な宛先にルーティングされるということである。例えば、リクエストが音楽ストリーミングサービスに対するものである場合、そのリクエストはインターネットベースの音楽ストリーミングサービスにルーティングされる。リクエストがビデオストリーミングの場合、リクエストはインターネットベースのビデオストリーミングサービスにルーティングされる。どちらの場合も、サービスプロバイダ１１５は、単にこれらのサービスと車両との間のトラフィックをルーティングする。従来の取り決めでは、サービスプロバイダ１１５は、これらのリクエストを一般的にデータサービスとして分類するだけであり、異なるタイプのデータサービスを区別する能力を有していない。

【0005】

車両データトラフィックをきめ細かいサービスレベルで分類すること、また、サービスごとに使用されるトラフィックの量を任意のレベルで細分化することには課題がある。車内トラフィックに関する詳細な分析が欠如しているため、ネットワークの使用状況をあらゆるレベルで詳細に特定する能力が低下し、且つ、セキュリティ及び運用上の問題を含む異常を特定する能力が低下する。

【0006】

また、車両製造業者が自社の車両アクセスを専用のサービスプロバイダ１１５に事前に関連付けることができるが、車両内でどのようなデータサービスが消費されるかを管理できる必要があるという問題もある。

【0007】

また、特定のネットワークトラフィックが特定のネットワークデータサービスプロバイダに関連するものであることを識別できるようにし、そのトラフィックを専用チャネルでルーティングしやすくする必要もある。

【0008】

これらの理由から、ネットワーク内で利用される実際のデータサービスに関して、より細分性を高める必要がある。

【発明の概要】

【0009】

したがって、本出願の第１の実施形態は、請求項１に定義された方法を提供する。有利な実施形態は、従属請求項にて提供する。また、この方法を提供するように構成されたネットワークノードも提供する。

【0010】

本発明の一態様によれば、ネットワークノードにおいて車内データトラフィックを分類する方法が提供され、この方法は以下を含む。

【0011】

前記ネットワークノードにおいて、第１のネットワークネームスペース及び第２のネットワークネームスペースを定義し、
前記第１のネットワークネームスペースは、着信リクエストデータパケット(incoming response data packets)を受信し、レスポンスデータパケットを配信するように構成されたイングレスネットワークインタフェースを含み、
前記第２のネットワークネームスペースは、着信レスポンスデータパケット(incoming response data packets)を受信し、リクエストデータパケットを配信するように構成されたエグレスネットワークインタフェースを含み、
チャネルは、前記イングレスネットワークインタフェースと前記エグレスネットワークインタフェースとの間のトラフィックが前記チャネルを通じてルーティングされるように、前記第１のネットワークネームスペースと第２のネットワークネームスペースとの間に提供されることと、
車両から、前記ネットワークノードで複数の着信リクエストデータパケットを受信し、前記データパケットは、前記車両において実行されるアプリケーションから発信され、
複数の着信リクエストデータパケットの各データパケットについて、
前記データパケットのヘッダから前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは前記車両と関連付けられ、
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記宛先ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットのヘッダを検査することによって、着信データパケットに対するデータ量を決定することと、
前記宛先ＩＰアドレスをルーティングテーブルと照合し、
前記宛先ＩＰアドレスが、前記ルーティングテーブル内で定義されていることを確認したら、前記宛先ＩＰアドレスに定義されたチャネルを通じて前記着信データパケットをルーティングし、又は、
前記宛先ＩＰアドレスが、前記ルーティングテーブル内で定義されていないと判断した場合、未定義のすべての宛先ＩＰアドレスに用意されたデフォルトチャネルを通じて前記着信データパケットをルーティングすることと、
前記着信リクエストデータパケットについて決定されたデータ量に基づいてチャネルボリュームのインジケータを更新することと、
前記ネットワークノードから前記複数の着信リクエストデータパケットを、それぞれの前記リクエストデータパケットに関連付けられた前記宛先ＩＰアドレスに送信する。
前記着信リクエストデータパケットは、セルラデータネットワークを通じて、少なくとも部分的に受信されることが望ましい。
前記ルーティングテーブルでは、同一の宛先ＩＰアドレストラフィックに同じチャネルを使用することが望ましい。

【0012】

望ましくは、この方法は以下を含む。
前記複数の着信リクエストデータパケットを前記ネットワークノードから前記宛先ＩＰアドレスに送信することに応答して、前記ネットワークノードで複数の着信レスポンスデータパケットを受信することと、
前記複数の着信レスポンスデータパケットの各データパケットについて、
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記ＩＰアドレスは前記車両に関連付けられ、
前記データパケットのヘッダから、前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットの前記ヘッダを検査することによって、前記着信データパケットに対するデータ量を決定することと、
前記送信元ＩＰアドレスを前記ルーティングテーブルと照合し、且つ
前記送信元ＩＰアドレスが、前記ルーティングテーブル内で定義されていることを判断した場合、前記送信元ＩＰアドレスに定義されたチャネルを通じて前記着信データパケットをルーティングし、又は、
前記送信元ＩＰアドレスが、前記ルーティングテーブル内で定義されていないと判断した場合、未定義のすべての前記送信元ＩＰアドレスに用意されたデフォルトチャネルを通じて前記着信データパケットをルーティングし、
前記着信リクエストデータパケットについて決定されたデータ量に基づいてチャネルボリュームのインジケータを更新することと、
前記複数の着信レスポンスデータパケットの各々を、前記ネットワークノードから、前記レスポンスデータパケットの各々に対する前記宛先ＩＰアドレスに関連付けられた各車両に送信することと、前記宛先ＩＰアドレスは、前記レスポンスデータパケットの各々についてのモバイルデバイスＩＤとして関連付けられるか、又はプロキシとして機能することが理解されるであろう。

【0013】

前記送信は少なくとも部分的にセルラデータネットワークを使用して行われることが望ましい。

【0014】

前記ルーティングテーブルは、同一の送信元ＩＰアドレストラフィックに対して、同じチャネルを使用することが望ましい。

【0015】

複数の前記チャネルのそれぞれは、前記車両で実行される個別のアプリケーションに関連付けられることが望ましい

【0016】

本方法は、前記ルーティングテーブル内で前記チャネルを定義することを含み、特定のチャネルに関連付けられたＩＰアドレス宛のトラフィックが前記チャネルを通じてルーティングされるように、既知のＩＰアドレス値を特定のチャネルに関連付けることを含むことが望ましい。

【0017】

本方法は、前記ルーティングテーブルを動的に更新することを含み、本方法は、着信ＤＮＳリクエストデータパケットに対して、まず、定義された式の集合に対して、ＤＮＳクエリ内のドメインを前記定義済み式の集合に対して照合することによってパケット検査を実行することを含み、前記各定義式は、特定のサービスに関連付けられ、かつ、一致が見出された場合に、前記リクエストデータパケットに対するレスポンスデータパケットを受信する際に、これらのＩＰアドレスへの後続のトラフィック、及びこれらのＩＰアドレスからの後続のトラフィックが、ＤＮＳリクエストデータパケットに対して最初に一致した特定のサービスに関連するチャネルを通過するように、ドメインのＩＰアドレス又はアドレスでルーティングテーブルを更新することが望ましい。

【0018】

本方法は、前記ルーティングテーブルを動的に更新することを含むことが望ましい。
ＴＬＳハンドシェイクを識別するためにアップストリームのＴＬＳパケットを監視することと、
ＴＬＳハンドシェイクが前記パケットを検査してＳＮＩヘッダが含まれているかどうかを判断するプロセス中であると判断した場合、
ＳＮＩヘッダが見つけ、ヘッダの値を抽出し、且つ、その値を各サービスに定義されたＳＮＩマッチングルールと比較し、ＳＮＩルールが一致する場合、前記ＴＬＳパケットの前記宛先ＩＰアドレスヘッダを使用して、そのルールを所有するサービスの前記ルーティングテーブルを更新する。

【0019】

本発明のさらなる態様によれば、プロセッサと第１のネットワークインターフェースと、第２のネットワークインターフェースを含むネットワークノードが提供され、
ネットワークノードは、本方法を実行するように構成されることが望ましい。

【図面の簡単な説明】

【0020】

次に、添付図面を参照して本出願を説明する。

【図1】図１は、従来技術によるシステムのネットワークアーキテクチャを示す概略図である。

【図2】図２は、本発明によるシステムのネットワークアーキテクチャを示す概略図である。

【図3】図３は、特定の車両との間で送受信されるトラフィックを分析する特定のインスタンスにおけるアーキテクチャを示す概略図である。

【図4】図４は、車両から発信されたデータがどのようにルーティングされ得るかを示すプロセスフロー図である。

【図5】図５は、車両宛てのデータをルーティングする方法を示すプロセスフロー図である。

【図6】図６は、本教示のシステムを用いて生成することができるチャネルごとのデータサービスの概要を示すヒストグラムの一例である。

【図7】図７は、本教示に従って使用できるＤＮＳルックアッププロセスフローの一部の例である。

【図8】図８は、本教示に従って使用できるＤＮＳルックアッププロセスフローの別の部分の例である。

【図9】図９は、本教示に従って使用できるＴＬＳパケット検査プロセスフローの例である。

【発明を実施するための形態】

【0021】

図２は、本発明による処理又は分類システム２００を統合するネットワークアーキテクチャである。処理又は分類システム２００は、そこを通過するネットワークトラフィックを宛先サービスに分類し、サービスごとのトラフィック量を報告するように構成されている。システム２００は、車両１０５から受信した任意のトラフィックの最終的な目的地を識別し、その識別された宛先をその車両１０５で消費されているデータサービスの分類器として使用するように構成されている。

【0022】

データパケットの形式で受信される車両１０５からの着信トラフィックは、そのトラフィックの宛先ＩＰアドレスを識別するために解析される。宛先ＩＰアドレスを決定すると、システム２００は、そのＩＰアドレスが既知のデータサービスプロバイダに事前に関連付けられているかどうかを判断するように構成される。既知のデータサービスプロバイダが存在すると判断すると、システムは、そのデータサービスプロバイダのトラフィック専用のシステム内のチャネルを通じて、その着信トラフィックをチャネルする。データサービスプロバイダA宛てのトラフィックはチャネルＡ経由でルーティングされ、データサービスプロバイダＢ宛てのトラフィックはチャネルＢ経由でルーティングされる。宛先ＩＰアドレスに基づいて専用チャネルを介してトラフィックをチャネル化することにより、パケットの実際のペイロードの任意の調査を必要とせずに、ヘッダ情報に基づいてトラフィックを分析及び分類できる。これにより、トラフィックのリアルタイムの最小遅延分類（minimal delay classification）が容易になる。

【0023】

したがって、本発明による分類システムは、任意の１つのチャネルを通過するデータ量が特定のデータサービスの実際の使用状況を反映し、監視、報告、又はその他の方法で制御され得ることを確実にする。

【0024】

システム機能は５つのコアブロック２０５～２２５で視覚化することができるが、これは理解を容易にするためであり、１つのブロックに関して、以下に説明する機能は別のブロックによって同様に提供できることが理解されるであろう。機能的には、特定の実装に制約されないが、システムは以下を含むと理解できる。

【0025】

コンフィギュレーションマネージャ２０５
コンフィギュレーションマネージャ２０５は、構成オプションを検証し、構成の更新をシステム２００の他のコンポーネントに公開する。

【0026】

ＤＮＳモニタ２１０
ＤＮＳモニタ２１０は、システムを通過するＤＮＳトラフィックをスキャンし、コンフィギュレーションマネージャのデータ構造内で定義されたサービスルールに対するクエリとレスポンスを比較し、一致が見つかった場合にルーティングコントローラ２２０に更新を公開する。

【0027】

ＳＮＩモニタ２１５
ＳＮＩモニタ２１５は、ＴＬＳハンドシェイクをスキャンし、サービス一致ルールをＳＮＩヘッダに適用する。一致するものが見つかると、更新がルーティングコントローラ２２０に公開される。

【0028】

ルーティングコントローラ２２０
ルーティングコントローラは、システム２００を通過するトラフィックの暗黙的な分類を可能にするようにルーティングテーブルを構成する。初期ルーティングテーブルの構成は、各サービスの構成に含まれるＩＰアドレスとネットワーク範囲に基づく。ただし、ルーティングコントローラは、ＤＮＳ及びＳＮＩモニタから受信した更新に応答して、実行時にルーティングテーブルを動的に変更することもできます。

【0029】

ＥＤＲジェネレータ２２５
ＥＤＲジェネレータ２２５は、システム内の各チャネルを流れるパケットのヘッダを監視し、車両ごとのサービスごとのトラフィックを要約した定期的な更新を公開する。

【0030】

分類システム２００のコンポーネント機能ブロック２０５～２２５は、管理システム２３０を使用して構成及び監視することができる。図２は、個別のデバイスである管理ネットワーク２３５上に設けられたこの管理システムを示すが、これは、分類システム２００を通過するトラフィックと能動的にインターフェースする機能コンポーネントから、管理及び後処理機能を視覚的に分離するための、概略的な目的のためのものであることが理解されるであろう。また、管理ネットワーク２３５は、ＥＤＲジェネレータ２２５によって公開されたＥＤＲデータを格納できるデータベース２４０と、データ分析エンジン２５０をホストすることもできる。任意選択の実施形態では、データベース２４０及び／又は分析エンジン２５０は、管理システム２３０とは別の１つ又は複数の追加デバイス上に提供されてもよい。図２のシステムの詳細の一部については、図３を参照して以下でさらに説明する。

【0031】

本発明の教示を任意の１つの特定のネットワークオペレーティングシステムなどに限定することは意図していないが、本目的のためには、分類システム２００は、３枚のネットワークカードを備えたＬＩＮＵＸ（登録商標）マシン（物理マシン又は仮想マシンであり得る）上でホストされることを仮定する。

【0032】

制御ＮＩＣ３１５は、システム２００と管理ネットワーク２３５との間の通信を提供する。制御ＮＩＣ３１５は、システム２００を管理するために使用される管理システム２３０から通信を送受信するために使用することができる。また、制御ＮＩＣ３１５は、ＥＤＲジェネレータ２２５からデータベース２４０及び分析エンジン２５０へのデータ送信を提供するためにも使用され得る。

【0033】

イングレスＮＩＣ３０５は、車両と通信するためにイングレスネットワークに接続される。そして、エグレスＮＩＣ３１０は、車両によってリクエストされるサービスなどの外部ネットワーク要素と通信するためにエグレスネットワークに接続される。

【0034】

分類システム２００内で発生する処理の少なくとも一部を概略形式で示す図３に示されるように、分類システムは、イングレスネームスペース３０１及びエグレスネームスペース３０２の２つのネットワークネームスペースを実行するように構成される。イングレスＮＩＣ３０５は、イングレスネームスペース３０１に位置し、エグレスＮＩＣ３１０はエグレスネームスペース３０２に位置する。イングレスネットワークは、リクエストパケットを受信し、レスポンスパケットを配信するために使用される。エグレスネットワークは、リクエストパケットの配信とレスポンスパケットの受信に使用されます。これらのパケットのルーティングは、ルーティングコントローラ２２０によって制御される。

【0035】

ネットワークネームスペースがＩＰスタックの独立した実装であることは、当業者には理解されよう。イングレスＮＩＣとエグレスＮＩＣを個別のネームスペースでホストすると、各ネットワーク上のトラフィックが効果的に分離される。ネットワーク間でパケットを転送するには、ネームスペース間でパケットを転送する必要がある。それぞれのネームスペース間のこの転送を実現するために、本教示のシステムは、それぞれのネームスペース間のローカルイーサネットトンネルの作成を可能にする仮想イーサネット（ＶＥＴＨ）の既知のＬｉｎｕｘ構成を採用する。ｖｅｔｈペアは、２つのエンドポイントを持つ仮想イーサネット接続である。一方のエンドポイントに書き込まれたパケットをもう一方のエンドポイントから読み取ることができ、その逆も同様である。図３のホストシステム内で、本教示は、ｖｅｔｈペア１～５を使用して、それぞれのペアの一端をイングレスネームスペース３０１内に配置し、他端をエグレスネームスペース３０２内に配置することによって、ネットワークネームスペースをブリッジする。

【0036】

トラフィックの分類を備えるためのシステムの初期構成の一部として、本教示では、最初に、分類される各サービスのイングレスネームスペースとエグレスネームスペースの間にｖｅｔｈペアを作成し、未分類のトラフィック用に１つの追加のｖｅｔｈペアを作成する。これらのｖｅｔｈペアは、分類されたトラフィックが通過するチャネルとして効果的に機能する。この例では、分類されるサービスはチャネルＡからＤで識別されるサービスであり、最後のチャネルであるチャネルＥは、分類されていないすべてのトラフィックがルーティングされるチャネルである。示されているチャネルの数は、単に説明を目的としたものであり、これも単に理解を容易にするために、チャネルＡは第１の音楽ストリーミングサービスに、チャネルＢはビデオストリーミングサービスに、チャネルＣは第２の音楽ストリーミングサービスに、チャネルＤは、Ｇｏｏｇｌｅマップによって提供されるようなナビゲーションサービスに使用され得ると考えることができることが理解され、チャネルＥは、他のすべてのインターネットトラフィック、ブラウジング、他のデータサービスプロバイダなど用である。このチャネル数又は特定のサービスとの関連付けは、システムの特定の要件に応じて変更できることが理解されよう。

【0037】

パケットベースのネットワークを通過する任意のパケットはヘッダとペイロードを含むことが理解されよう。ヘッダには、ペイロードを配信するためのデータ（送信元と宛先のネットワークアドレスなど）を提供する制御情報が含まれ、ペイロードにはユーザデータが含まれる。本システムは、車両発信パケットの宛先アドレスと車両終端パケットの送信元アドレスを検査することによってトラフィックを分類する。ルーティングテーブル内で特定のアドレスと特定のチャネルを関連付けるエントリを定義することにより、ヘッダ情報内の特定のアドレスを識別すると、ルーティングテーブル内のエントリを使用してパケットを適切なｖｅｔｈペアに転送することが可能となる。したがって、特定のチャネルを通じてトラフィックをルーティングする行為は、トラフィックを特定のタイプのデータサービスに関連付けられているものとして暗黙的に分類する。

【0038】

図４は、車両からのトラフィックのルーティングに関連するプロセスフローを示している。パケットは車両からイングレスＮＩＣに到着する（ステップ４０５）。従来、実際の車両識別子ＶＩＮ、又は車両のモバイル識別子ＩＭＳＩは、イングレスＮＩＣ３０５では表示されないことが理解されるであろう。従来のトラフィックセッションごとに、車両から発信されるトラフィックは、最初にパケットゲートウェイ（ＰＧＷ）にルーティングされ、パケットゲートウェイ（ＰＧＷ）は、セルラネットワーク１１０の従来のコンポーネントであると理解されるであろう。ＰＧＷは、セッションの間、車両にＩＰアドレスを割り当てる。ＰＧＷは、ＭＳＩＳＤＮ識別子をセッションに割り当てられたＩＰアドレスに関連付けるデータフィードも公開する。本教示によると、このフィードは、分析フェーズ中にＭＳＩＳＤＮが帯域外のＶＩＮ／ＩＭＳＩに解決されることができるため、その後、イングレス及びエグレスＮＩＣを介してルーティングされるトラフィックを調整するために使用され、サービストラフィックを特定の車両に帰属させることができる。例えば、システム２００を介してルーティングされるトラフィックの一部は、個々の車両１０５ａに帰属することができ、一方、トラフィックの他の部分は、車両１０５ｂ及び１０５ｃに帰属させることができる。通常、この調整は、分析エンジン２５０によるＰＧＷフィード及びＥＤＲジェネレータ２２５からのチャネルボリュームデータのオフライン処理を通じて行われる。したがって、分析エンジン２５０は、チャネルごと及び車両ごとにトラフィックを分析することができる。レスポンスパケットの宛先ＩＰアドレスとそれぞれの車両のＭＳＩＳＤＮとの間に関連性があることが理解されるであろうが、これは通常、パケットゲートウェイ（ＰＧＷ）でのみ知られる。このＩＰアドレスは特定の車両に関連付けることができるが、これは通常、ＰＧＷ自体としては行われない。それにも関わらず、一旦パケットがイングレスＮＩＣ３０１で車両から受信されると、宛先ＩＰアドレスについてヘッダが確認される（ステップ４１０）。そのＩＰアドレスが抽出され、次いでルーティングテーブルと照合される（ステップ４１５）。一致するものがあれば（ステップ４２０）、宛先ＩＰアドレスに従って、定義されたＶｅｔｈペアによって提供される適切なチャネルにルーティングされる（ステップ４２５）。

【0039】

宛先ＩＰアドレスに対して定義されたルーティングテーブル内に明示的なルートが定義されていないために一致しない場合（ステップ４２０）、パケットは、それ自身の特定のｖｅｔｈペアに関連付けられたデフォルトチャネル（ステップ４３０）にルーティングされる。図３の例では、このデフォルトチャネルはチャネル５で、他に分類されていないすべてのインターネットトラフィックに関連付けられている。

【0040】

どちらのシナリオ（一致又は一致しない）でも、パケットはエグレスネームスペースのｖｅｔｈペアを出て、サービスに関連付けられたアップストリームのゲートウェイを経由するか、明示的なゲートウェイが設定されていない場合はデフォルトゲートウェイを経由してルーティングされる。次いで、パケットは、送信元のエグレスＮＩＣに書き込まれる（ステップ４３５）。

【0041】

図５は、車両がトラフィックを終端する場合の同等のプロセスを示している。パケットはエグレスＮＩＣに到着し（ステップ５０５）、送信元ＩＰアドレス、すなわちパケットの発信元に従って、適切なｖｅｔｈペアにポリシールーティングされる。これは、送信元ＩＰアドレスのヘッダを確認し（ステップ５１０）、その識別された送信元アドレスのルーティングテーブルを確認する（ステップ５１５）ことによって達成される。明示的なポリシールートが存在しない場合（一致判定ステップ５２０で一致しない場合）、パケットはデフォルトのＶｅｔｈペアを介してルーティングされる（ステップ５３０）。明示的なポリシールートが存在する場合（一致判定ステップ５２０で一致）、パケットは、一致に関連付けられたチャネルにルーティングされる（ステップ５２５）。どちらのシナリオでも、パケットはイングレスネームスペースのｖｅｔｈペアを出て、宛先アドレスに関連付けられたダウンストリームゲートウェイ経由でルーティングされる。これらはイングレスＮＩＣ経由で送信される。

【0042】

ＩＰアドレスに従ってトラフィックを分類することにより、任意のチャネルを通過するトラフィックの量に関するデータを経時的に集約することができる。

【0043】

図６は、計算可能な時間の経過に伴うトラフィックのヒストグラムの例を示している。これは単に例示的なものであるが、車両又は車両のグループによって時間の経過とともに利用されるデータトラフィックの性質に関する有意義なデータを抽出できることを示していることが理解されるであろう。データは、パケットが各ｖｅｔｈペアを通過するときにパケットのヘッダを検査することにより、サービスごとのトラフィックを計算することによって集約される。図６のデータは、特定の車両１０５に対応する１つの特定のＩＰアドレスに関連付けられたチャネルごとのデータであってもよいし、システム２００を通るすべてのトラフィック（すなわち、複数の車両１０５ａからｃのトラフィック）に関連付けられた集約されたチャネルごとのデータであってもよい。

【0044】

車両発信パケットの場合、システムはパケット内のバイト数を記録し、パケットヘッダにある送信元ＩＰアドレスに関連付けることができる。車両終端パケットの場合、システムはヘッダのバイト数を記録し、パケットヘッダにある宛先ＩＰアドレスに関連付けるように設定できる。上で概説したように、送信元/宛先ＩＰアドレスは、ＰＧＷによって公開されたデータフィードとの比較を通じて特定の車両と関連付けることができる。このようにして、システムは各車両のサービスごとにアップロード及びダウンロードされたバイト数を維持できる。これらの統計は定期的に収集され、データ処理と分析のために送信され、その時点でカウントはリセットされるか、後で使用するためにアーカイブされる。

【0045】

システム２００によって収集された分類データは、集約されたデータセットとして出力され、保存及び／又はさらなる処理のためにデータベース２４０及び／又は分析エンジン２５０に送信される。

【0046】

一例では、チャネルごとのトラフィックデータを含む集約されたデータセットが、保存のためにシステム２００からデータベース２４０に送信される。分析エンジン２５０は、データベース２４０から集約されたデータセットを取得し、処理する。分析エンジン２５０は、特定のチャネル上のトラフィックを特定のＩＭＳＩ、車両及び／又は車両のグループと関連付けるために、集約されたデータセットをプラットフォームデータで強化する。たとえば、特定のブランド（例:ＶＷ、ポルシェなど）のすべての車両による特定のサービスプロバイダ（例:Ｎｅｔｆｌｉｘ、Ｓｐｏｔｉｆｙなど）の使用状況を、強化された集約データセットから推測することができ、これを請求データ及びレポートデータの提供に使用できる。

【0047】

分析エンジン２５０は、システム２００から出力されデータベース２４０に格納されたチャネルごと／ＩＰアドレスごとのトラフィックデータを取得し、それらを調整してサービスごと／車両ごとの同等のトラフィック概要を生成する。消費されたデータ（アップロード及びダウンロード）は、サンプリングされた頻度で収集され、データを消費するサービス（ユーザが契約したサービス）に対して保存される。

【0048】

システムを通過するパケットを有意義に分類するために必要なルーティングテーブルを作成するために、システムは特定のデータサービスプロバイダによって使用されているＩＰアドレスに関する知識を必要とする。Ｓｐｏｔｉｆｙ、Ｎｅｔｆｌｉｘなどの人気のあるデータサービスプロバイダが、それぞれのサービスのために既知の永久的なＩＰアドレス又はサブネットのリストを採用することが知られていることは理解されよう。これらは、そのサービスのトラフィックを分類する初期ルーティングコンフィギュレーションを作成するために使用される。

【0049】

しかし、この静的構成を強化するために、本システムは、ＤＮＳとＴＬＳパケットを検査することで、サービス用の新しいＩＰアドレスを動的に発見するようにも構成されている。

【0050】

この文脈では、従来のインターネットトラフィックのルーティングでは、クライアントデバイス上のアプリケーションがインターネットホストに接続したいが、そのホストの名前（例えばservices.cubictelecom.comなど）しか持っていない場合に、ＤＮＳルックアップがトリガされることが理解されるであろう。接続を開くには、デバイス（又はネットワークノード）上で実行されるアプリケーションは、アドレスが必要である。ＤＮＳの役割は、名前を検索し、関連するホストにコンタクトするために使用できる１つ以上のＩＰアドレスを返すことである。本教示によれば、特定のインターネットサービスが特定の車両によって使用されているかどうかのその後の分析を容易にするために、特定のトラフィックを特定のチャネルを通して誘導するために使用されるルーティングテーブルには、特定の既知のサービスごとに特定のＩＰアドレスが入力される。このように、ルーティングテーブルは、既知のサービスに対して既知のＩＰアドレスを使用し、それらのＩＰアドレスに関連付けられたチャネルを通じてそれらのサービスのトラフィックをルーティングする。

【0051】

特定のサービスには、それらのサービスに関連付けられた固定ＩＰアドレスがあり、本発明のシステムがトラフィック解析を必要とすると予想されるそれらのサービスについては、それらのサービスに関連付けられたチャネルのルーティングテーブルをそれらのＩＰアドレスで事前に設定することができる。複数のＩＰアドレスが１つのサービスプロバイダに関連付けられることもあり、本発明のルーティングテーブルは、１つの専用サービスのトラフィックをルーティングするために複数のＩＰアドレスを使用することに対応できることが理解されよう。

【0052】

その他のサービス、あるいは特定のサービスが特定のＩＰアドレスにトラフィックをジオフェンスする場合など、アプリケーションリクエストの処理に使用される実際のＩＰアドレスは、時間の経過とともに異なる可能性がある。本教示のシステムは、着信トラフィックを分析してサービスに関連するＩＰアドレスの変更を特定し、そのターゲットサービスの新しいＩＰアドレスが見つかったときにルーティングテーブルを更新することによって、この種の動的ＩＰアドレスに対処することができる。後続のパケットの分類に使用されるルーティングテーブルを動的に更新するこのような配置では、システムは、最初に正規表現のコレクションに対してＤＮＳクエリのドメインを照合することによって、ＤＮＳパケット（ＵＤＰポート５３）検査を実行するように構成することができる。システムの構成の一部として、分析チャネルが必要とされる各サービスは、照合する正規表現のセットを定義することができる。一致が見つかった場合、システムはリクエストＩＤをキャッシュし、対応するＤＮＳレスポンスを待つことができる。レスポンスが到着すると、ドメインに関連するＩＰアドレスがルーティングコントローラに転送され、ルーティングコントローラはサービスのルーティングテーブルエントリを更新する。レスポンスが到着すると、ドメインに関連付けられたＩＰアドレスがルーティングコントローラに転送され、ルーティングコントローラはサービスのルーティングテーブルエントリを更新する。これらのＩＰアドレスとの間で送受信される後続のトラフィックは、そのサービスに属するものとして分類される。

【0053】

場合によっては、照会されるドメインが一般的すぎて、サービスと関連付けることができないことがある。この場合、ＤＮＳルールは、ＤＮＳレスポンスのＣＮＡＭＥを照合するための追加ルールを含むことができる。レスポンスで返されたＩＰアドレスは、レスポンスがＣＮＡＭＥを含み、そのＣＮＡＭＥが提供されたルールのいずれかに一致する場合にのみ、ルーティングコントローラに転送される。

【0054】

図７及び図８は、本教示によるシステムが、適切なチャネルが使用されることを確実にするために、システムを通じてルーティングされるトラフィックをどのように解消できるかに関連する例示的なプロセスフローを示す概略図である。

【0055】

このプロセスは、ステップ７０５では、クライアントデバイスである車両がホストへの接続を開こうとするときに開始される。ステップ７１０では、クライアントデバイスはネームサーバにＤＮＳリクエストを送り、ホスト名を１つ以上のＩＰアドレスに解決する。ＤＮＳリクエストは、それがイングレスＮＩＣに到着すると識別される。ステップ７１５では、到着すると、リクエストは検査され、ホストが各サービスに定義されたルールと比較される。一致しない場合、リクエストＩＤは保存されないが（ステップ７３０）、ステップ７３５で、リクエストは依然としてＤＮＳネームサーバにルーティングされる。

【0056】

一致がある場合、ステップ７２０で、ホストに対して、ＤＮＳリクエストＩＤはキャッシュされ、ＤＮＳリクエストはエグレスＮＩＣを通過してＤＮＳネームサーバにルーティングされ、ＤＮＳネームサーバはリクエストを解決し、ＤＮＳレスポンスで返信する。

【0057】

ＤＮＳレスポンスがネームサーバから受信されると、ステップ７４０でＤＮＳレスポンスのレスポンスＩＤがリクエストＩＤキャッシュと照合され、ステップ７４１で、一致するかどうかが確認される。

【0058】

一致が見つかった場合、ステップ７４５で、システムはＡレコードをルーティングコントローラに転送するように構成されるが、Ａレコードはドメインに関連付けられたＩＰアドレスを含むＤＳＮレスポンスの部分であることを当業者は理解するであろう。その後、ルーティングコントローラは、関連するサービスのルーティングテーブルを更新する。

【0059】

ステップ７５０では、一致が見つかったか否かに関わらず、DNSレスポンスはリクエスト元のクライアントに送信される。

【0060】

ステップ７５５で、クライアントは、ＤＮＳレスポンスに含まれるＩＰアドレスの１つに接続を開く。

【0061】

ステップ７６０では、リクエストから生じるトラフィックは、ルーティングコントローラによって定義された正しいチャネルを経由してルーティングされる。

【0062】

図９のプロセスフローに従って、システムは、イングレスＮＩＣ上のすべてのアップストリームのＴＬＳパケット（ＴＣＰポート４４３）を監視するように構成することもできる。プロセスステップ８０５でＴＬＳハンドシェイクを識別すると、ステップ８１０でクライアントハンドシェイクパケットを検査し、ＳＮＩ（Ｓｅｒｖｅｒ Ｎａｍｅ Ｉｎｄｉｃａｔｉｏｎ）拡張ヘッダを含むかどうかを判断する。ＳＮＩヘッダが見つかった場合、ステップ８２０でヘッダの値が抽出され、各サービスに定義されたＳＮＩマッチングルールと比較される。サービスルールが一致すると、ステップ８２５で、パケットの宛先ＩＰアドレスがそのサービスの識別ＩＰアドレスであると仮定され、ステップ８３５で、宛先ＩＰアドレスがルーティングコントローラに転送される。ＤＮＳの一致の場合と同様に、ルーティングコントローラはサービス８４０のルーティングテーブルエントリを更新する。

【0063】

以上のことから、本教示によるシステムは、そのトラフィックを生成しているサービスに基づいて、ネットワークレベルでのデータ使用の分類を可能にすることが理解されよう。異なるデータサービスプロバイダのＩＰアドレスを特定することで、本教示によれば、ネットワークトラフィックを、これらの異なるデータサービスプロバイダに固有のチャネルを通してネットワークレベルでルーティングすることが可能になる。ルーティングは、ネットワークを通過するパケットのヘッダを解析し、送信元又は宛先ＩＰアドレスに基づいて特定のチャネルにパケットをルーティングすることによって行われる。このようにして、トラフィックの性質は、ネットワークを通過する個々のパケットを詳細にパケット分析する必要があるのとは対照的に、生成データサービスプロバイダのＩＰアドレスから推測される。

【0064】

本教示のシステムは、特定の車両から発信されたトラフィックを、異なるデータサービスプロバイダに固有のチャネルを介してルーティングするように構成されている。このようにして、特定の車両によって使用されているデータサービスの種類の詳細な概要がネットワークレベルで実現される。このシステムでは、例えばブラウジングアクティビティ又はクッキーなどを実際の車両に問い合わせる必要はない。分析は、ネットワークデバイスを通過するパケットに基づいて実行される。車両のデバイス識別子（通常はＩＭＳＩ）を使用することで、その車両から発信された、又は異なるデータサービスプロバイダからその車両にルーティングされたトラフィックを追跡することができる。これにより、データ使用量の監視が容易になるだけでなく、サービスブロック、使用中のデバイス又はデータサービスに基づくルーティング設定変更、課金データなどの追加機能も可能になる。

【0065】

本教示のシステムは、ブラウザ又は特定のアプリケーションレベルではなく、デバイス固有のレベルでのトラッキングを提供することが理解されよう。データ解析はデバイスごとに行われるが、トラフィックを推定するために統計的サンプリングを行うのとは対照的に、ネットワークを使用するすべてのデバイスを追跡し、ネットワーク上の指定されたすべてのデバイスのアクティビティを全体的に把握することが可能である。

【0066】

上記で詳述したように、本教示のシステムは、ウェブブラウザのようなアプリケーションからではなく、ネットワークレベルからリクエストを追跡するため、インターネットタイプのデータサービスプロバイダからのデータサービスに対するすべてのリクエストを確認し、追跡することが可能である。これにはウェブベースのサービスも含まれるが、テレマティクス、地図、その他のマシンツーマシンデータなどのマシンツーマシンサービス、ウェブサイトのリクエスト又はＮｅｔｆｌｉｘ／Ｓｐｏｔｉｆｙのようなストリーミングデータサービスのような消費者ベースのサービスのような、人間／ユーザ向けではないサービスも含まれる。

【0067】

データリクエストは、ネットワークを経由してくる生のリクエストレベルで追跡される。これは、他のトラフィック解析ツールとは異なり、ウェブブラウザからのリクエストを記録するもので、ターミナルウィンドウからのリクエスト、OSからのアップデートなど、他のリクエストは記録されない。

【0068】

データ分析システムの例示的な構成は、ネットワークノード内、例えば車両とデータサービスプロバイダとの間に配置されることが理解されよう。このシステムは、特定の車両から発信された、又は特定の車両に向けられたデータのパケットを解析し、それらのパケット内のヘッダ情報に基づいて、その車両によって使用されている特定のデータサービスの性質についてデータ解析を実行できるように、ネットワークノード内の特定のチャネルを介してパケットをルーティングするように構成される。以下の特許請求の範囲に照らして必要な限りにおいてのみ限定されることを意図する本出願の範囲から逸脱することなく、本明細書に記載されたものに変更を加えることができる。

【0069】

本明細書中で使用される、含む（ｃｏｍｐｒｉｓｅｓ）／含む（ｃｏｍｐｒｉｓｉｎｇ）という語は、記載された特徴、整数、ステップ又はコンポーネントの存在を特定するためのものであるが、１つ又は複数の他の特徴、整数、ステップ、構成要素又はそれらのグループの存在又は追加を排除するものではない。

【手続補正2】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

車載データトラフィックを分類するネットワークノードにおける方法であって、
前記ネットワークノードにおいて、第１のネットワークネームスペース及び第２のネットワークネームスペースを定義し、
前記第１のネットワークネームスペースは、着信リクエストデータパケットを受信し、レスポンスデータパケットを配信するように構成されたイングレスネットワークインタフェースを含み、前記第２のネットワークネームスペースは、着信レスポンスデータパケットを受信し、リクエストデータパケットを配信するように構成されたエグレスネットワークインタフェースを含み、複数のチャネルは、前記イングレスネットワークインタフェースと前記エグレスネットワークインタフェースとの間のトラフィックが前記チャネルを介してルーティングされるように、前記第１のネットワークネームスペースと前記第２のネットワークネームスペースとの間に設けられ、
車両（１０５）から複数の着信リクエストデータパケットを前記ネットワークノードで受信し、前記データパケットは前記車両（１０５）で実行中のアプリケーションから発信されることと、
前記複数の着信リクエストデータパケットの各データパケットについて
前記データパケットのヘッダから前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは前記車両（１０５）と関連付けられ、
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記宛先ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットのヘッダを検査することにより、着信データパケットのデータ量を決定することと
前記宛先ＩＰアドレスをルーティングテーブルと照合し、
前記宛先ＩＰアドレスが前記ルーティングテーブル内で定義されていると判断された場合、前記着信データパケットを、前記宛先ＩＰアドレスのために定義されたチャネルを通じてルーティングし、前記チャネルは、前記第１のネットワークネームスペースと前記第２のネットワークネームスペースとの間に設けられた複数のチャネルのうちの１つであり、又は
前記宛先ＩＰアドレスが前記ルーティングテーブル内で定義されていないと判断された場合、前記着信データパケットを、定義されていないすべての宛先ＩＰアドレスに提供されるデフォルトチャネルを通じてルーティングし、前記デフォルトチャネルは、前記第１のネットワークネームスペースと前記第２のネットワークネームスペースとの間に設けられる複数のチャネルのうちの１つであり、
前記着信リクエストデータパケットの決定されたデータ量に基づいて、チャネルボリュームのインジケータを更新することと
前記ネットワークノードから前記複数の着信リクエストデータパケットを、それぞれの前記リクエストデータパケットに関連付けられた前記宛先ＩＰアドレスに送信する、方法。

【請求項2】

前記着信リクエストデータパケットは、少なくとも部分的にセルラデータネットワークを介して受信される、請求項1に記載の方法。

【請求項3】

前記ルーティングテーブルは、同一の宛先ＩＰアドレスのトラフィックに対して同一のチャネルを使用する、請求項1又は請求項2に記載の方法。

【請求項4】

前記複数の着信リクエストデータパケットを前記ネットワークノードから前記宛先ＩＰアドレスへ送信することに応答して、前記ネットワークノードで複数の着信レスポンスデータパケットを受信することと
前記複数の着信レスポンスデータパケットの各データパケットについて
前記データパケットのヘッダから、前記データパケットの宛先ＩＰアドレスを抽出し、前記ＩＰアドレスは前記車両（１０５）に関連付けられ、
前記データパケットのヘッダから、前記データパケットの送信元ＩＰアドレスを抽出し、前記送信元ＩＰアドレスは、前記アプリケーションによってリクエストされたサービスに関連付けられ、
前記データパケットの前記ヘッダを検査することにより、前記着信データパケットのデータ量を決定することと、
前記送信元ＩＰアドレスを前記ルーティングテーブルと照合し、且つ
前記送信元ＩＰアドレスが前記ルーティングテーブル内に定義されていると判断した場合、その送信元ＩＰアドレスに対して定義されたチャネルを通じて着信データパケットをルーティングし、前記チャネルは、前記第１のネットワークネームスペースと前記第２のネットワークネームスペースとの間に設けられた複数のチャネルのうちの１つであり、又は、
前記送信元ＩＰアドレスが前記ルーティングテーブル内に定義されていないと判断した場合、前記着信データパケットを、未定義のすべての送信元ＩＰアドレスに対して定義されたデフォルトチャネルを通じてルーティングし、前記デフォルトチャネルは、第１のネットワークネームスペースと第２のネットワークネームスペースとの間に設けられる複数のチャネルのうちの１つであり、
前記着信リクエストデータパケットの決定されたデータ量に基づいて、チャネルボリュームのインジケータを更新することと、
前記複数の着信レスポンスデータパケットの各々を、前記ネットワークノードから、前記レスポンスデータパケットの各々に対するＩＰアドレスに関連付けられた各車両（１０５）に送信する、請求項１から３のいずれか一項に記載の方法。

【請求項5】

前記送信は、少なくとも部分的にセルラデータネットワークを使用して行われる、請求項４に記載の方法。

【請求項6】

前記ルーティングテーブルは、同一の送信元ＩＰアドレスのトラフィックに対して同一のチャネルを使用する、請求項４又は５に記載の方法。

【請求項7】

複数の前記チャネルの各々が、前記車両（１０５）で実行される個別のアプリケーションに関連付けられている、請求項１から６のいずれか一項に記載の方法。

【請求項8】

前記ルーティングテーブル内で前記チャネルを定義することを含み、前記方法は、特定のチャネルに関連付けられたＩＰアドレス宛のトラフィックが、前記チャネルを通じてルーティングされるように、既知のＩＰアドレス値を特定のチャネルに関連付けることを含む、請求項１から７のいずれか一項に記載の方法。

【請求項9】

前記ルーティングテーブルを動的に更新することをさらに含み、前記方法は、着信ＤＮＳリクエストデータパケットに対して、まず、ＤＮＳクエリ内のドメインを定義された式の集合に対して照合することによってパケット検査を実行することを含み、各定義された式は特定のサービスと関連付けられ、一致が見つかった場合、この方法は、リクエストデータパケットに対するレスポンスデータパケットを受信する際に、これらのＩＰアドレスへの後続のトラフィック、及びこれらのＩＰアドレスからの後続のトラフィックが、ＤＮＳリクエストデータパケットに対して最初に一致した特定のサービスに関連するチャネルを通過するように、ドメインのＩＰアドレス又はアドレスでルーティングテーブルを更新することを含む、請求項１から８のいずれか一項に記載の方法。

【請求項10】

前記ルーティングテーブルを動的に更新することをさらに含み、
前記方法は、アップストリームのＴＬＳパケットを監視して、ＴＬＳハンドシェイクを識別することと、
前記ＴＬＳハンドシェイクが前記パケットを検査してＳＮＩヘッダが含まれているかどうかを判断するプロセス中であると判断した場合、ＳＮＩヘッダが見つけ、そのヘッダの値を抽出し、且つ、その値をサービスごとに定義されたＳＮＩマッチングルールと比較し、
ＳＮＩルールが一致した場合、そのルールを所有するサービスの前記ルーティングテーブルを前記ＴＬＳパケットの前記宛先ＩＰアドレスヘッダで更新する、請求項１から９のいずれか一項に記載の方法。

【請求項11】

プロセッサ、第１のネットワークインターフェース、及び第２のネットワークインターフェースを含むネットワークノードであって、前記ネットワークノードは、請求項１から１０のいずれか一項に記載の方法を実行するように構成される、ネットワークノード。

【国際調査報告】