JP2011526092A - アプリケーション用ネットワーク認識アダプタ - Google Patents

Abstract

様々なアプリケーションからのデータトラフィックのストリームは、インテリジェントネットワーク構成要素へのストリームの通信をフィルタ処理する比較的大きいプラットフォームの一環としてネットワーク認識アダプタモジュールによって処理されてもよい。所定のデータストリームに関連する識別因子が決定されて所定のデータストリームに対するＱｏＳポリシー設定を選択する根拠として使用されてもよい。選択されたＱｏＳポリシー設定は、この後、アプリケーションに関する通信を実行するのに有効かつ最適（技術上およびビジネス上の両観点から）である埋め込み型の基本的な能動媒体タイプのＱｏＳ機能を利用するために媒体アクセス制御層に伝達されてもよい。

Description

本出願は、一般に、アプリケーションによって発生されるトラフィックのストリームの処理に関し、より詳細には、インテリジェントネットワーク構成要素にストリームを伝達するネットワーク認識アダプタに関する。

ネットワークデバイスのアプリケーション層で実行されるアプリケーションは、伝統的に、ネットワークデバイスが簡単な媒体アクセス制御（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）（ＭＡＣ）層を通じて接続されるネットワークを介して伝達されている。さらに、ＭＡＣ層はネットワークプロトコルごとに（すなわち、伝送媒体ごとに）異なるので、アプリケーションはデバイスが接続されるネットワークに使用される特定のネットワークプロトコルに関するＭＡＣ層の仕様を考慮に入れて開発されている。

比較的新しいネットワークプロトコルに関するＭＡＣ層は、アプリケーションによって発生するデータトラフィックの特定のストリームに関して要求されるサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）（ＱｏＳ）をアプリケーションが指定できる複雑さを増している。多くの場合、簡単なＭＡＣ層は、データトラフィックの特定のストリームに要求されるＱｏＳをアプリケーションが指定できる複雑さを欠いている。その結果として、多くのアプリケーションでは、アプリケーションからの伝送の根底にあるネットワーク技術を十分に利用するために必要なある程度のインテリジェンスが備えられていないか、あるいは、このようなインテリジェンスを有することが要求されていない。

このようなアプリケーションは、ある程度のインテリジェンスを有していないことによって、ＷｉＭＡＸなどのいくつかの新しいネットワーク技術に組み込まれたＱｏＳ機能を十分に利用することができないし、このような新しいネットワーク技術固有の技術的課題に対処することができない。残念なことに、新しいネットワーク技術を利用するために必要なインテリジェンスの程度が新しいアプリケーションに組み入れられると、新しいアプリケーションを実行するために設計されるデバイスの複雑さが増す。したがって、複雑さの増加分は、デバイスのコストを上昇させる可能性があり、特定用途向け集積回路技術の物理的限界を押し上げる可能性がある。

データトラフィックのストリームは、インテリジェントネットワーク構成要素へのストリームの通信をフィルタ処理する比較的大きいプラットフォームの一環としてネットワーク認識（ｎｅｔｗｏｒｋ−ａｗａｒｅ）アダプタモジュールによって処理され得る。所定のデータストリームに関連する識別因子が決定され、所定のデータストリームに対するＱｏＳポリシー設定を選択するための根拠として使用され得る。選択されたＱｏＳポリシー設定は、この後、媒体アクセス制御層に伝達され得る。

本発明の一態様による、データストリームが、ＱｏＳポリシー設定を受信するように適合されている媒体アクセス制御（ＭＡＣ）層に進む前にデータストリームを適合させる方法が提供される。方法は、データストリームに関連するパケットを受信すること、データストリームに関連する識別因子決定すること、識別因子に基づいてデータストリームに関するＱｏＳポリシー設定を選択すること、ＱｏＳポリシー設定をパケットに関連するＭＡＣ層に伝達することを含む。本発明の他の態様において、上記方法を実行するコンピュータデバイスが提供され、上記方法を実行するようにプロセッサを適合させるコンピュータ可読媒体が提供される。

本発明の他の態様および特徴は、添付図とともに本発明の具体的な実施形態の以下の説明を検討すると当業者に明らかになるであろう。

データ通信ネットワークに接続される可能性のあるコンピュータデバイスの構成要素の相互接続を示す図である。 ウィンドウズ・マネジメント・インストラメンテーション（Ｗｉｎｄｏｗｓ Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）を採用する通信の論理構造を示す図である。 ウィンドウズ・フィルタリング・プラットフォーム（Ｗｉｎｄｏｗｓ Ｆｉｌｔｅｒｉｎｇ Ｐｌａｔｆｏｒｍ）を採用する通信の論理構造を示す図である。 本発明の態様による、ネットワーク認識アダプタ、フィルタエンジン、およびＱｏＳマネジャを含む、ウィンドウズ・フィルタリング・プラットフォーム（Ｗｉｎｄｏｗｓ Ｆｉｌｔｅｒｉｎｇ Ｐｌａｔｆｏｒｍ）を示す図である。 本発明の一態様による、図４のフィルタエンジンの動作方法例におけるステップを示す図である。 本発明の一態様による、図４のＱｏＳマネジャの動作方法例におけるステップを示す図である。 本発明の一態様による、図４のネットワーク認識アダプタの動作方法例におけるステップを示す図である。

図１は、データ通信ネットワーク１０８に有線方式または無線方式で接続され得るコンピュータデバイス１００の構成要素の相互接続を示す。図示されたコンピュータデバイス１００の構成要素は、マイクロプロセッサ１１６と、マイクロプロセッサ１１６に接続された記憶装置１２０と、ランダム・アクセス・メモリ（ＲＡＭ）１１８と、ネットワーク・インターフェース・カード（ＮＩＣ）１０４とを含む。ＮＩＣ１０４によって、コンピュータデバイス１００をデータ通信ネットワーク１０８に接続することができる。

マイクロプロセッサ１１６は、記憶装置１２０に格納されているコードを用いた蓄積プログラム制御（ｓｔｏｒｅｄ ｐｒｏｇｒａｍ ｃｏｎｔｒｏｌ）の下で動作する。図１に描かれるように、動作中に、ＲＡＭ１１８は、既知のマイクロソフト・ウィンドウズ（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ）（登録商標）オペレーティングシステム用などのオペレーティング・システム・プログラムまたはコードモジュール１３６を含むプログラムを格納する。ウィンドウズ（Ｗｉｎｄｏｗｓ）などのオペレーティングシステムは、典型的に、ＲＡＭ１１８空間を２つの部分、すなわち、カーネル空間１３８またはこれと機能的に等価な空間などのユーザ空間１４０と制限されたアクセス空間とに分割する。さらに、ＲＡＭ１１８は、典型的にユーザ空間１４０に常駐する参照番号１４２によって一般に示されるソフトウェアアプリケーションと、典型的にカーネル空間１３８に常駐するドライバ１４４とを格納する。

図２は、ウィンドウズ・マネジメント・インストラメンテーション（Ｗｉｎｄｏｗｓ Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）（ＷＭＩ）を採用する通信の論理構造を示しており、アプリケーション２０２とＮＩＣ１０４の間で通信がある。ＷＭＩは、計測された構成要素からの情報および通知を提供するオペレーティング・システム・インターフェースを備える既知のウィンドウズ（Ｗｉｎｄｏｗｓ）ドライバモデルへの一組の拡張機能である。ＷＭＩは、分散管理調査特別委員会（Ｄｉｓｔｒｉｂｕｔｅｄ Ｍａｎａｇｅｍｅｎｔ Ｔａｓｋ Ｆｏｒｃｅ）（ＤＭＴＦ）からのウェブベースの企業管理（Ｗｅｂ−Ｂａｓｅｄ Ｅｎｔｅｒｐｒｉｓｅ Ｍａｎａｇｅｍｅｎｔ）（ＷＢＥＭ）規格および共通情報モデル（Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）（ＣＩＭ）規格のマイクロソフト（Ｍｉｃｒｏｓｏｆｔ）実装である。

ＮＩＣ１０４は、図１のドライバ１４４の中から選択されたドライバ２０６を必要とする。ＭＡＣ層を含むドライバ２０６は、カーネル空間にあるネットワーク・ドライバ・インターフェース仕様（ＮＤＩＳ）ドライバ２０８と通信する。ＮＤＩＳドライバ２０８は、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）社および３Ｃｏｍ社によって共同開発されたＮＩＣ用のＡＰＩを実装している。ＮＤＩＳは、ＯＳＩデータリンク層（７層中２層）の上位副層を形成し、ＯＳＩデータリンク層とネットワーク層（７層中３層）の間のインターフェースとしての機能を果たす論理リンク制御（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）（ＬＬＣ）である。下位副層はＭＡＣデバイスドライバである。ＮＤＩＳは、ＮＩＣ１０４のハードウェアに内在する複雑さを覆い隠し、レベル３ネットワーク・プロトコル・ドライバおよびハードウェアレベルＭＡＣドライバ用の標準インターフェースとしての機能を果たす一般に「ラッパー（ｗｒａｐｐｅｒ）」と呼ばれる機能のライブラリである。

ＮＤＩＳドライバ２０８は、やはりカーネル空間内にあるＷＭＩモジュール２１０と通信する。ＷＭＩモジュール２１０は、ユーザ空間内のＷＭＩ ＡＰＩ２１２と通信する。ＷＭＩ ＡＰＩ２１２は、アプリケーション２０２と通信する。

図３は、ウィンドウズ・フィルタリング・プラットフォーム（Ｗｉｎｄｏｗｓ Ｆｉｌｔｅｒｉｎｇ Ｐｌａｔｆｏｒｍ）を採用する通信の論理構造を示し、アプリケーション３０２とＮＩＣ１０４の間で通信がある。

図２に示されるようなＷＭＩを採用する構造と同様に、図３に示されるようなＷＦＰを採用する構造はドライバ２０６と通信するＮＩＣ１０４を含む。ドライバ２０６は、さらに、ＮＤＩＳドライバ２０８と通信する。図１のＷＭＩの場合と違って、ＮＤＩＳドライバ２０８はウィンドウズ・フィルタリング・プラットフォーム（Ｗｉｎｄｏｗｓ Ｆｉｌｔｅｒｉｎｇ Ｐｌａｔｆｏｒｍ）（ＷＦＰ）３１０と通信する。ＷＦＰ３１０は、カーネル空間１３８およびユーザ空間１４０にまたがり、ユーザ空間１４０においてＷＦＰ ＡＰＩ３１２と通信する。ＷＦＰ ＡＰＩ３１２は、アプリケーション３０２と通信する。

マイクロソフト・ウィンドウズ（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ）オペレーティングシステムのＶｉｓｔａ（登録商標）バージョンには、ＷＦＰ ＡＰＩが含まれる。ＷＦＰ ＡＰＩは、アプリケーションをウィンドウズ・ビスタ（Ｗｉｎｄｏｗｓ Ｖｉｓｔａ）およびウィンドウズ・サーバ２００８（Ｗｉｎｄｏｗｓ Ｓｅｒｖｅｒ ２００８）における新しいネットワークスタックのパケット処理およびフィルタリングパイプラインに結び付けることができる。ＷＦＰは統合通信を含む機能を備えている。さらに、ＷＦＰは、アプリケーションごとに処理論理を起動するように構成されうる。

コンピュータデバイス１００が接続するネットワークがトランスポート通信プロトコル（ＴＣＰ）およびインターネットプロトコル（ＩＰ）ネットワークであるとき、ネットワークスタック４４０はＴＣＰ／ＩＰスタックと呼ばれることがある。

図４を見ると、ＷＦＰ３１０は、フィルタリングエンジン、ネットワークスタック４４０、および一組の発信モジュール（ｃａｌｌｏｕｔ ｍｏｄｕｌｅ）として実施されてもよい。ネットワークスタック４４０は、複数の「シム（ｓｈｉｍ）」を備えていてもよい。シムはパケットの内部構造を特性として顕在化（ｅｘｐｏｓｅ）させる。様々なシムが様々な層におけるプロトコルに対して存在する。動作中に、フィルタリングエンジンは、受信されたパケット中のデータと指定された一組のルールとを比較する。ＷＦＰ３１０は、一組の内蔵シムであると考えられ、これをデフォルトで含む。さらに、他のプロトコル用シムは、ＷＦＰ ＡＰＩ３１２を用いてフィルタリングエンジンに登録されうる。一組の内蔵シムは、アプリケーション層実行（ＡＬＥ）シム４０４と、ストリームシム４０８と、トランスポート層モジュール（ＴＬＭ）シム４１０と、ネットワーク層モジュール（ＮＬＭ）シム４１４とを含む。図４に示される登録されたシムは、トランスポート・ドライバ・インターフェースＷｉｎｓｏｃｋカーネル（ＴＤＩ ＷＳＫ）シム４０６と、転送層シム４１２と、ＮＤＩＳ層シム４１６とを含む。

基本的なフィルタリング機能を提供するフィルタリングエンジンは、カーネル空間１３８とユーザ空間１４０の両方に及んでいる。図４に示されるように、カーネル空間１３８に常駐するフィルタリングエンジンの一部分は「フィルタエンジン」４０２と呼ばれ、ユーザ空間１４０に常駐するフィルタリングエンジンの一部分は「ベース・フィルタリング・エンジン」４１８と呼ばれる。

フィルタリングエンジンは、データがシムによって顕在化されている所定のパケットのデータをフィルタリングルールと照合する。データと１つまたは複数のルールとの照合に基づいて、フィルタリングエンジンは所定のパケットを通過させてもよいし、所定のパケットの通過を阻止してもよい。別の処置が必要な場合、他の処置が発信モジュールを使用して実施されうる。フィルタリングルールはアプリケーションごとに適用される。

ベース・フィルタリング・エンジン４１８は、フィルタリングエンジンを管理するモジュールである。ベース・フィルタリング・エンジン４１８は、フィルタリングルールを受け入れてアプリケーションに固有のセキュリティモデルを強制実施する。また、ベース・フィルタリング・エンジン４１８は、ＷＦＰ３１０に関する統計データを取り、ＷＦＰ３１０の状態のログを保持する。

発信モジュールは、フィルタリングドライバによって顕在化されるコールバック機能である。フィルタリングドライバは、パケットの通過が阻止または許容されるデフォルトのフィルタリング性能以外のフィルタリング性能を提供するために使用される。フィルタルールの登録中に、発信モジュールが指定されてもよい。フィルタルールに一致するデータを有するパケットが受信されると、フィルタエンジン４０２は一組の発信ＡＰＩ４２０、関連する発信モジュールを介して起動する。関連発信モジュールは、この後、ある特定のフィルタリング性能を実行する。

すべての層において登録されうる発信モジュールは、ＷＦＰ３１０の機能を拡張する。各発信モジュールは、固有のグローバル一意識別子（ＧＵＩＤ）を有する。発信モジュールは、深層検査（Ｄｅｅｐ Ｉｎｓｐｅｃｔｉｏｎ）に、すなわち、どのデータを阻止するか、許容するか、または別のフィルタに渡すべきかを判断するために、ネットワークデータの複雑な検査の実施に使用されてもよい。発信モジュールは、パケット修正に用いられてもよく、このパケット修正にはストリームの一部として受信されるパケットのヘッダおよびペイロードの修正と修正されたパケットをストリームに戻す注入とが含まれる。発信モジュールの他の使用法として、ストリーム修正およびデータロギングが挙げられる。

図４に示される発信モジュールの例は、ウィルス対策発信モジュール４２２と、ペアレンタルコントロール発信モジュール４２４と、侵入検知システム（ＩＤＳ）発信モジュール４２６と、ネットワークアドレス変換（ＮＡＴ）発信モジュール４２８とを含む。

ユーザ空間１４０において、ベース・フィルタリング・エンジン４１８はＷＦＰ ＡＰＩ３１２と通信し、ＷＦＰ ＡＰＩ３１２は、さらに、アプリケーション３０２、オペレーティング・システム・ベースのファイアウォール４５０、およびその他のアプリケーション４５２（これは追加的なファイアウォールであってもよい）などのアプリケーションと通信する。また、ＷＦＰ ＡＰＩ３１２は、本発明の態様を実施するＱｏＳマネジャ４３２と通信している。

概して、ＱｏＳマネジャ４３２は、アプリケーション３０２と、ＯＳベースのファイアウォール４５０と、他のアプリケーション４５２とからのストリームを優先するためにネットワーク認識アダプタ発信モジュール４３０を構成する。当業者には明らかであるように、図４に示されるアプリケーション３０２、４５０、４５２は、例にすぎず、コンピュータデバイス１００からの要求に応じてさらに多い、あるいはさらに少ない、あるいは種々のアプリケーションがあってもよい（図１）。

優先順位付けを実行する際に、ネットワーク認識アダプタ発信モジュール４３０は、ドライバ２０６においてＭＡＣ層（図示せず）と情報をやり取りする。さらに、ネットワーク認識アダプタ発信モジュール４３０は、アプリケーション３０２、４５０、４５２、およびポリシーと情報をやり取りする。当業者には明らかであるように、アプリケーション３０２、４５０、４５２からのストリームの処理に関する様々なポリシーがコンピュータデバイス１００によって中央ディレクトリから受信されてもよい。

アダプタ発信モジュール４３０の役割は、ポリシーおよび／またはサービスの特性化を利用して徹底したＱｏＳを実現するために伝達を知的に利用することである。ネットワーク認識アダプタ発信モジュール４３０は、さらに、ＱｏＳとスペクトル効率のトレードオフの管理と、ターミナル操作応答性と省電力のトレードオフの管理と、位置情報サービス（ＬＢＳ）およびマルチキャスト放送サービス（ＭＳＢ）など、埋め込まれうる他のネットワークインテリジェンスの管理とを行なうことができる。

動作中に、フィルタエンジン４０２は、各層が関連優先順位を有する一組のフィルタの層として構成される。所定のストリームは、優先順位の比較的高いフィルタが所定のストリームを許容している場合でも阻止されうる。フィルタ構造によって、同じストリームに対して複数の処理を実施することができる。フィルタエンジン４０２内の層は、副層に分けられる。副層内で、フィルタは重要性（ｗｅｉｇｈｔ）の順に評価される。評価は最初の照合（許容／阻止）で停止する。ストリームとフィルタの間で照合が発生すると、関連する発信モジュールが通知される。通知される発信応答が持続すると、次の照合フィルタが評価される。とりわけ、ストリームは各副層において評価される。

動作中に、アプリケーション３０２から次に得られるストリームに関して、ＱｏＳマネジャ４３２は命令をフィルタエンジン４０２に伝送して、ネットワーク認識アダプタ発信モジュール４３０の発信ドライバを初期化する。特に、命令はアンロード機能を指定してもよい。発信ドライバを初期化するための命令を受信すると（ステップ５０２、図５）、フィルタエンジン４０２はデバイスオブジェクトを生成してネットワーク認識アダプタ発信モジュール４３０を登録してもよい。

ＱｏＳマネジャ４３２の動作は図６に照らしてさらに検討されてもよい。初めに、ＱｏＳマネジャ４３２は、フィルタエンジン４０２へのセッションを開く（ステップ６０２）。ＱｏＳマネジャ４３２は、この後、副層を追加するようフィルタエンジン４０２に指示し（ステップ６０４）、追加されたばかりの副層にフィルタを追加するようフィルタエンジン４０２に指示する（ステップ６０６）。

ステップ６０６においてフィルタを追加するための指示の受信に応答して、フィルタエンジン４０２は、要求されたフィルタを追加してもよく、さらにネットワーク認識アダプタ発信モジュール４３０へのフィルタの追加を示すための一般に「Ｎｏｔｉｆｙｆｎ（）」と呼ばれる通知関数を処理してもよい（ステップ５０４、図５）。

フィルタが設定されているアプリケーション３０２に由来するストリームのパケットがネットワークスタック４４０内に到着すると、パケットはフィルタエンジン４０２によって処理される。

特に、フィルタエンジン４０２は、フィルタが設定されているアプリケーション３０２に由来するストリームのパケットがネットワークスタック４４０内に到着したことをネットワーク認識アダプタ発信モジュール４３０に示すための一般に「Ｃｌａｓｓｉｆｙｆｎ（）」と呼ばれる分類関数を処理してもよい（ステップ５０６、図５）。

図７は、ネットワーク認識アダプタ発信モジュール４３０におけるストリームを適合させる方法例のステップを示す。
特に、ネットワーク認識アダプタ発信モジュール４３０は、最初に、ストリームのパケットを受信し（ステップ７０２）、ストリームに関連する識別因子を決定する（ステップ７０４）。この後、ネットワーク認識アダプタ発信モジュール４３０は、識別因子に基づいて、データストリームに対するＱｏＳポリシー設定を選択する（ステップ７０６）。最後に、ネットワーク認識アダプタ発信モジュール４３０は、選択されたＱｏＳポリシー設定をドライバ２０６内のＭＡＣ層（図示せず）に伝達するためにストリームデータを修正する（ステップ７０８）。

ストリームデータを修正して選択されたＱｏＳポリシー設定をＭＡＣ層に伝達する（ステップ７０８）ためのパケットレベルにおいて、ネットワーク認識アダプタ発信モジュール４３０はステップ７０２において受信されたパケットのクローンを作成してもよい。ネットワーク認識アダプタ発信モジュール４３０は、この後、クローンを修正して修正されたクローンを形成してもよく、この場合、修正されたクローンは選択されたＱｏＳポリシーを代表する信号を包含する。ネットワーク認識アダプタ発信モジュール４３０は、この後、Ｃｌａｓｓｉｆｙｆｎ（）を用いてクローンをネットワークスタック４４０に注入してもよい。

「ＱｏＳポリシー設定」という用語は、本明細書では「サービスの品質」という既知の用語よりも包括的に使用される。サービスの品質という用語は、ビットレート、遅延、ジッター、およびパケット誤り率に関する設定を含むものとして知られている。これらの設定のほかに、ユーザの優先順位やユーザグループの優先順位などをさらに含めるために本明細書では「ＱｏＳポリシー設定」という用語が使用される。

識別因子は、たとえば、ストリームの発生源であるアプリケーション３０２の識別子、ストリームに関連する加入者の識別子、またはストリーム内のデータの媒体タイプの識別子であってもよい。

データストリームが複数のインターネットプロトコル（ＩＰ）パケットのストリームである場合、識別因子を決定すること（ステップ７０４）は、複数のＩＰパケットの中の所定のパケットにおけるヘッダフィールドを検査することを含んでいてもよい。その場合、識別因子は、たとえば、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート、または宛先ポートであってもよい。

識別因子がアプリケーション３０２の正体（ｉｄｅｎｔｉｔｙ）である場合、ＱｏＳポリシー設定の選択（ステップ７０６、図７）はアプリケーション３０２に関連する優先順位に基づいていてもよい。さらに、アプリケーション３０２の正体はアプリケーションのタイプに関連していてもよく、ＱｏＳポリシー設定の選択（ステップ７０６、図７）はアプリケーション３０２に関連するタイプに基づいていてもよい。アプリケーションタイプの例として、ビデオ、音声、ゲーム、コラボレーション、およびインスタントメッセージが挙げられる。

識別因子は、たとえば、ストリームの発生源であるアプリケーション３０２に関連する加入者の識別子であってもよい。
あるいは、識別因子は、たとえば、ネットワーク・インターフェース・カード１０４とデータ通信ネットワーク１０８とのリンクの媒体タイプの識別子であってもよい（図１参照）。媒体タイプは、たとえば、１０メガビット／秒イーサネット（登録商標）、ファストイーサネット、ギガビットイーサネット、または１０ギガビットイーサネットなど、ＩＥＥＥ８０２．３に関して電気電子技術者協会（ＩＥＥＥ）規格によって定められた有線イーサネットとして定義されてもよい。

さらに、媒体タイプは、たとえば、ＩＥＥＥ８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ、または８０２．１１ｎなど、電気電子技術者協会（ＩＥＥＥ）規格によって定められた無線ネットワーキングを意味する「ＷｉＦｉ」として定義されてもよい。

さらに、媒体タイプは、たとえば、ＩＥＥＥ８０２．１６−２００４規格およびＩＥＥＥ８０２．１６ｅ−２００４改正によって定められた無線ネットワーキングを意味するマイクロ波利用アクセスに関する世界的な相互運用（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）の略称である「ＷｉＭＡＸ」として定義されてもよい。

また、媒体タイプは、たとえば、「ロング・ターム・エボルーション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）（ＬＴＥ）」として定義されてもよい。ロング・ターム・エボルーションは、ユニバーサル・モバイル・テレコミュニケーション・システム携帯電話規格を改良するための第三世代パートナーシップ・プロジェクト（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）（３ＧＰＰ、ｗｗｗ．３ｇｐｐ．ｏｒｇ参照）内のプロジェクトに与えられた名称であり、ユニバーサル・モバイル・テレコミュニケーション・システム携帯電話規格も将来の要求に対処するために３ＧＰＰによって維持される。

フィルタエンジン４０２およびネットワーク認識アダプタ発信モジュール４３０によって処理されているストリームが終了すると、フィルタエンジン４０２は、ストリームが終了していることをネットワーク認識アダプタ発信モジュール４３０に示すための一般に「Ｆｌｏｗｄｅｌｅｔｅｆｎ（）」と呼ばれるフロー削除関数を処理する（ステップ５０８、図５）。

さらに、ＱｏＳマネジャ４３２は、フィルタを削除してもよい（ステップ６０８、図６）。
ステップ６０８におけるフィルタの削除に応答して、フィルタエンジン４０２はネットワーク認識アダプタ発信モジュール４３０にフィルタの削除を示すための通知関数を処理してもよい。

さらに、ＱｏＳマネジャ４３２は、副層を削除して（ステップ６１０、図６）、ステップ６０２において開かれたセッションを閉じてもよい（ステップ６１２）。セッションの終了に応答して、フィルタエンジン４０２は発信ドライバをアンロードしてもよい（ステップ５１０、図５）。

コンピュータデバイス１００の操作の際、ユーザは、実行するアプリケーションを選択するためにユーザインターフェースを採用してもよい。コンピュータデバイス１００は、たとえば、携帯用（すなわち、ノートブック）コンピュータであってもよく、選択されたアプリケーションはビデオ伝送アプリケーションであってもよい。さらに、ネットワーク・インターフェース・カード１０４とデータ通信ネットワーク１０８の接続は、ＷｉＭＡＸ接続であってもよい。したがって、ドライバ２０６内のＭＡＸ層は、ＷｉＭＡＸ ＭＡＣ層である。ＷｉＭＡＸ ＭＡＣ層は、ＱｏＳパラメータの仕様を受け入れるとことが分かっている。ＱｏＳマネジャ４３２は、ストリームのパケットをビデオ伝送アプリケーションからネットワーク認識アダプタ４３０に送信するためにフィルタエンジン４０２内にフィルタを作成する。さらに、ネットワーク認識アダプタ４３０は、ストリーム内のデータがビデオであると判断すると、毎秒２００ｋビットの帯域幅を選択し、ストリームのパケットを修正してストリームが毎秒２００ｋビットの帯域幅を受信するべき旨をＷｉＭＡＸ ＭＡＣ層に伝達する。

ＷｉＭＡＸ ＭＡＣ層において、修正されたストリーム内のパケットが受信されて信号伝達が処理される。処理に従って、ＷｉＭＡＸ ＭＡＣ層は、データ通信ネットワーク１０８を通じてビデオストリームの宛先まで毎秒２００ｋビットの帯域幅を予約しておいてもよい。ＷｉＭＡＸ ＭＡＣ層は、この後、データ通信ネットワーク１０８を通じて宛先にビデオストリームを伝送する準備をしてもよい。

別の状況において、コンピュータデバイス１００のユーザは、ＱｏＳポリシーパラメータを指定してもよい。これらのパラメータは詳述されうるし、ビットレート、遅延、ジッター、およびパケット損失などの一般的なＱｏＳパラメータは基本的な媒体タイプに埋め込まれているＱｏＳに直接変換されうる。しかし、すべての媒体タイプが構成されるすべてまたは一部のＱｏＳパラメータをサポートしている訳ではない。その場合、ネットワーク認識アダプタ４３０は、媒体タイプに基づいてマッピングを行ってもよい。

前述の内容は、選択されたＱｏＳポリシー設定がＭＡＣ層に伝達されるようにデータストリームを適合させる方法を提供する。しかし、今までのところ、現在のネットワーク条件が伝達されたＱｏＳポリシー設定を受け入れない状況をどう処理するかは検討されていない。このような場合、ネットワーク認識アダプタ４３０は、最善の努力に照らしてＱｏＳポリシー設定に関連するストリームのトラフィックを予定してもよい。あるいは、ＱｏＳポリシー設定がオール・オア・ナッシング・アプローチに関連している場合は特に、ネットワーク認識アダプタ４３０は、ストリームを拒絶して起点アプリケーション、そしてさらにはユーザに知らせてもよい。あるいはさらに、ＱｏＳポリシー設定が「劣化が許容される」アプローチに関連している場合は特に、ネットワーク認識アダプタ４３０は、劣化したＱｏＳ設定を有するストリームのトラフィックを予定してもよい。一部のネットワーク媒体タイプでは、それらのＱｏＳ状況（たとえば、利用可能帯域幅）がモニターされてネットワーク認識アダプタ４３０にフィードバックされうる（ＱｏＳマネジャ４３２を介して）。

好都合なことに、ネットワーク認識アダプタ４３０は、本発明の一態様に従って実行されるとき、アプリケーション層とＭＡＣ層との間に介在し、これによってアプリケーション層で実行されるアプリケーションにおける複雑さの必要性を緩和することが分かる。ネットワーク認識アダプタ４３０は、ＭＡＣ層におけるＱｏＳパラメータを指定できるように計画されうる。指定されたＱｏＳパラメータを適切に使用すると、スペクトル効率を改善してデータ通信ネットワーク１０８に固有の複雑さの管理を容易にすることができる。

好都合なことに、特定のネットワーキング技術専用に設計されているＭＡＣ層とのデータのやり取りよりもむしろネットワーク認識アダプタ４３０とのデータのやり取りを予想したアプリケーションが開発されうる。

当業者には明らかなはずであるように、本発明の態様は既知のウィンドウズ・フィルタリング・プラットフォーム（Ｗｉｎｄｏｗｓ Ｆｉｌｔｅｒｉｎｇ Ｐｌａｔｆｏｒｍ）（ＷＦＰ）を背景として提示されているが、ＷＦＰを採用することは、本発明の態様の動作にとって不可欠でなく本発明の態様が実施される場合の環境の一例として役立つにすぎない。

本出願の前述の実施形態は、単なる例を意図するものである。具体的な実施形態に対しては、本明細書に添付された特許請求の範囲で定められる本出願の範囲から逸脱することなく、変更形態、修正形態、および変形形態が当業者によって実施されてもよい。

Claims (23)

1. データストリームが、ＱｏＳポリシー設定を受信するように適合されている媒体アクセス制御（ＭＡＣ）層に進む前に、該データストリームを適合させる方法であって、
   データストリームに関連するパケットを受信すること、
   前記データストリームに関連する識別因子を決定すること、
   前記識別因子に基づいて、前記データストリームに対するＱｏＳポリシー設定を選択すること、
   前記ＱｏＳポリシー設定を前記パケットに関連する前記ＭＡＣ層に伝達すること
   を含む方法。
2. 前記ＱｏＳポリシー設定は、サービスの品質の設定を含む、請求項１に記載の方法。
3. 前記ＱｏＳポリシー設定は、ユーザエクスペリエンス設定を含む、請求項１に記載の方法。
4. 前記データストリームは、複数のインターネットプロトコル（ＩＰ）パケットのストリームであり、前記識別因子を決定することは、前記複数のＩＰパケットの中の所定のパケットにおけるヘッダフィールドを検査することを含む、請求項１に記載の方法。
5. 前記ヘッダフィールドは、前記所定のパケットに対する送信元アドレスの標示を保持する、請求項４に記載の方法。
6. 前記ヘッダフィールドは、前記所定のパケットに対する宛先アドレスの標示を保持する、請求項４に記載の方法。
7. 前記ヘッダフィールドは、前記所定のパケットに対する発信元ポートの標示を保持する、請求項４に記載の方法。
8. 前記ヘッダフィールドは、前記所定のパケットに対する宛先ポートの標示を保持する、請求項４に記載の方法。
9. 前記識別因子は、前記データストリームに関連するアプリケーションの識別子を含む、請求項１に記載の方法。
10. 前記アプリケーションは、優先順位に関連しており、前記データストリームに関するＱｏＳポリシー設定を選択することは、前記選択することを、前記優先順位と前記ＱｏＳポリシー設定との間の関連性に基づかせることを含む、請求項９に記載の方法。
11. 前記アプリケーションは、ビデオアプリケーションを含む、請求項９に記載の方法。
12. 前記アプリケーションは、音声アプリケーションを含む、請求項９に記載の方法。
13. 前記アプリケーションは、ゲームアプリケーションを含む、請求項９に記載の方法。
14. 前記アプリケーションは、コラボレーションアプリケーションを含む、請求項９に記載の方法。
15. 前記アプリケーションは、インスタント・メッセージ・アプリケーションを含む、請求項９に記載の方法。
16. 前記識別因子は、前記データストリームに関連する加入者の識別子を含む、請求項１に記載の方法。
17. 前記識別因子は、前記データストリームに関連する媒体タイプの識別子を含む、請求項１に記載の方法。
18. 前記媒体タイプは、ＩＥＥＥ８０２．３規格に基づく有線ネットワーキング技術を備える、請求項１７に記載の方法。
19. 前記媒体タイプは、ＩＥＥＥ８０２．１１規格に基づく無線ネットワーキング技術を備える、請求項１７に記載の方法。
20. 前記媒体タイプは、ＩＥＥＥ８０２．１６規格に基づく有線ネットワーキング技術を備える、請求項１７に記載の方法。
21. 前記媒体タイプは、３ＧＰＰロング・ターム・エボルーション・プロジェクトから派生する規格に基づく無線ネットワーキング技術を備える、請求項１７に記載の方法。
22. コンピュータデバイスであって、
    データストリームに関連するパケットを受信し、
    前記データストリームに関連する識別因子を決定し、
    前記識別因子に基づいて、前記データストリームに対するＱｏＳポリシー設定を選択し、
    前記ＱｏＳポリシー設定を前記パケットに関連する媒体アクセス制御層に伝達する、
    ように適合されたモジュールを有するフィルタリング・プラットフォームを実行するように適合されたプロセッサを備える、コンピュータデバイス。
23. コンピュータ実行可能命令を含むコンピュータ可読媒体であって、プロセッサによって実施されるとき、前記プロセッサに、
    データストリームに関連するパケットを受信させ、
    前記データストリームに関連する識別因子を決定させ、
    前記識別因子に基づいて、前記データストリームに対するＱｏＳポリシー設定を選択させ、
    前記ＱｏＳポリシー設定を前記パケットに関連する媒体アクセス制御層に伝達させるようにするコンピュータ実行可能命令を含む、コンピュータ可読媒体。

Images