(57)【要約】  コンピュータデバイス上で実行中であるＱｏＳを意識したネットワークアプリケーションに対するＱｏＳ（Quality of Service）制御メカニズムが開示される。メカニズムは、ネットワークアクセスデバイスのＭＡＣ層ＱｏＳ機能にアクセスするためのＱｏＳを意識したアプリケーションに対するＩＰソケットベースのＱｏＳ ＡＰＩ（Application Program Interface）を提供する。種々の実施例では、ＱｏＳメカニズムは、ネットワークアクセスデバイスで、ＱＡｏＳ（QoS API over Socket）ハンドラ、及び／又は、ＭＡＣ層ＱＡｏＳハンドララッパを利用して、アクティブネットワークインターフェース上でアプリケーションによって転送されるＱｏＳデータを制御及び監視する。
2010521829.tif 000002
【特許請求の範囲】
【請求項１】
システムであって、
１又は複数のＱｏＳを意識したアプリケーションと、
１又は複数のＱｏＳサポートネットワークアクセスデバイスと、
前記１又は複数のＱｏＳを意識したアプリケーションと、前記１又は複数のＱｏＳサポートネットワークアクセスデバイスとの間で動作する、ＱｏＳ管理及び報告通信プロトコルと
を備え、
前記１又は複数のＱｏＳを意識したアプリケーションは、前記１又は複数のＱｏＳを意識したネットワークアクセスデバイスを通じて、データ通信ストリームのＱｏＳを制御及び管理することを特徴とするシステム。
【請求項２】
前記管理及び報告通信プロトコルは、双方向接続を通じて交換されることを特徴とする請求項１に記載のシステム。
【請求項３】
前記ＱｏＳ管理及び報告通信プロトコル上で通信するＱｏＳを意識したアプリケーションとＱｏＳサポートネットワークアクセスデバイスのそれぞれのペア間に、１対１の関係があることを特徴とする請求項１に記載のシステム。
【請求項４】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークアクセスデバイスにおいて実行されることを特徴とする請求項１に記載のシステム。
【請求項５】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークデバイスに対するデバイスドライバにおいて実行されることを特徴とする請求項１に記載のシステム。
【請求項６】
前記ＱｏＳ管理及び報告通信プロトコルは、周知のデータ通信サービス上で動作することを特徴とする請求項１に記載のシステム。
【請求項７】
前記周知のデータ通信サービスは、インターネットプロトコルベースソケットであることを特徴とする請求項１に記載のシステム。
【請求項８】
前記ＱｏＳを意識したアプリケーションは、前記ＱｏＳ管理及び報告通信プロトコルを実行する中間デバイスを通じて、前記ＱｏＳサポートネットワークアクセスデバイスと通信することを特徴とする請求項１に記載のシステム。
【請求項９】
前記ＱｏＳサポートネットワークアクセスデバイスは、複数のネットワークアクセスデバイスに対する仲介であることを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ＱｏＳサポートネットワークアクセスデバイスは、１又は複数の前記ネットワークアクセスデバイス上で、前記データトラフィックをルートすることを特徴とする請求項９に記載のシステム。
【請求項１１】
前記ＱｏＳサポートネットワークアクセスデバイスは、前記ＱｏＳ管理及び報告通信プロトコルを使用して、前記ＱｏＳを意識したアプリケーションに、ＱｏＳ状況情報を提供することを特徴とする請求項１に記載のシステム。
【請求項１２】
前記ＱｏＳサポートネットワークアクセスデバイスは、データ通信リンクを通じて、前記ＱｏＳを意識したアプリケーションにリモートに接続されることを特徴とする請求項１に記載のシステム。
【請求項１３】
前記データ通信リンクは、有線通信リンクであることを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記データ通信リンクは、無線通信リンクであることを特徴とする請求項１２に記載のシステム。
【請求項１５】
方法であって、
ＱｏＳ管理及び報告通信プロトコルを使用して、１又は複数のＱｏＳを意識したアプリケーションと、１又は複数のＱｏＳサポートネットワークアクセスデバイスとの間で、データ通信するステップと、
１又は複数のネットワークアクセスデバイスを通じて、１又は複数のデータ通信ストリームのＱｏＳを制御及び管理するステップと
を具備することを特徴とする方法。
【請求項１６】
前記管理及び報告通信プロトコルは、双方向接続を通じて交換されることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ＱｏＳ管理及び報告通信プロトコル上で通信するＱｏＳを意識したアプリケーションとＱｏＳサポートネットワークアクセスデバイスのそれぞれのペア間に、１対１の関係があることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークアクセスデバイスにおいて実行されることを特徴とする請求項１５に記載の方法。
【請求項１９】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークデバイスに対するデバイスドライバにおいて実行されることを特徴とする請求項１５に記載の方法。
【請求項２０】
前記ＱｏＳ管理及び報告通信プロトコルは、周知のデータ通信サービス上で動作することを特徴とする請求項１５に記載の方法。
【請求項２１】
前記周知のデータ通信サービスは、インターネットプロトコルベースソケットであることを特徴とする請求項２０に記載の方法。
【請求項２２】
前記ＱｏＳを意識したアプリケーションは、前記ＱｏＳ管理及び報告通信プロトコルを実行する中間デバイスを通じて、前記ＱｏＳを意識したネットワークアクセスデバイスと通信することを特徴とする請求項１５に記載の方法。
【請求項２３】
前記ＱｏＳサポートネットワークアクセスデバイスは、複数のネットワークアクセスデバイスに対して仲介であることを特徴とする請求項１５に記載の方法。
【請求項２４】
前記ＱｏＳサポートネットワークアクセスデバイスは、１又は複数の前記ネットワークアクセスデバイス上で、前記データトラフィックをルートすることを特徴とする請求項２３に記載の方法。
【請求項２５】
前記ＱｏＳサポートネットワークアクセスデバイスは、前記ＱｏＳ管理及び報告通信プロトコルを使用して、前記ＱｏＳを意識したアプリケーションに、ＱｏＳ状況情報を提供することを特徴とする請求項１５に記載の方法。
【請求項２６】
前記ＱｏＳサポートネットワークアクセスデバイスは、データ通信リンクを通じて、前記ＱｏＳを意識したアプリケーションにリモートに接続されることを特徴とする請求項１５に記載の方法。
【請求項２７】
前記データ通信リンクは、有線通信リンクであることを特徴とする請求項２６に記載の方法。
【請求項２８】
前記データ通信リンクは、無線通信リンクであることを特徴とする請求項２６に記載の方法。
【請求項２９】
方法であって、
ＱｏＳを意識したアプリケーションと、ＱｏＳサポートネットワークアクセスデバイスとの間で、双方向接続を確立するステップと、
前記確立された双方向接続を通じて、ＱｏＳ関連データを通信するステップと
を具備することを特徴とする方法。
【請求項３０】
前記双方向接続はＩＰソケットであることを特徴とする請求項２９に記載の方法。
【請求項３１】
前記確立するステップは、ＱｏＳを意識したアプリケーションと、ＱｏＳサポートネットワークアクセスデバイスのＭＡＣ層との間で、双方向接続を確立するステップを具備することを特徴とする請求項２９に記載の方法。
【請求項３２】
前記通信するステップは、ＱｏＳ管理及び報告通信プロトコルを通じて、ＱｏＳ関連データを通信するステップを具備することを特徴とする請求項２９に記載の方法。
【請求項３３】
前記通信するステップは、ＱｏＳ関連データと共に、１又は複数のＱｏＳメッセージを送信するステップを具備することを特徴とする請求項２９に記載の方法。
【請求項３４】
前記ＱｏＳサポートネットワークアクセスデバイスを用いて、双方向接続を確立するステップのために、１又は複数のＱｏＳ ＡＰＩを設けるステップをさらに具備することを特徴とする請求項２９に記載の方法。
【請求項３５】
前記ＱｏＳサポートネットワークアクセスデバイスに対するＱｏＳ関連データの通信のために、１又は複数のＱｏＳ ＡＰＩを設けるステップをさらに具備することを特徴とする請求項２９に記載の方法。
【請求項３６】
ＱｏＳを意識したアプリケーションと通信するために、ＭＡＣ層ＱｏＳ ＡＰＩハンドラを設けるステップをさらに具備することを特徴とする請求項２９に記載の方法。
【請求項３７】
前記ＭＡＣ層ＱｏＳ ＡＰＩハンドラは、前記ネットワークアクセスデバイスに対するデバイスドライバにおいて具体化されることを特徴とする請求項３６に記載の方法。
【請求項３８】
前記ＭＡＣ層ＱｏＳ ＡＰＩハンドラは、前記ネットワークアクセスデバイスの前記ＭＡＣ層において具体化されることを特徴とする請求項３６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
§関連出願の相互参照
本出願は、米国仮出願第60/881,104号（2007年１月17日に出願された）のメリットを主張し、その全体を引用することにより本明細書に組み込まれる。
【０００２】
§技術分野
本発明は、通信ネットワーク分野に関し、特にネットワークアプリケーションのためのＱｏＳ（Quality of Service）サポートに関する。
【背景技術】
【０００３】
ネットワーク使用可能計算システム及びネットワークが偏在し、かつ、より多様になるにつれて、これらのネットワークを利用するアプリケーションのデータ通信条件もそのようになっている。計算デバイスのこの急増にともない、これらの通信サービスに対して、必要なＱｏＳ（Quality of Service）を提供するニーズが増大している。一般に、ＱｏＳは、リソースリザベーション制御メカニズム（ネットワークアプリケーションが、多様なネットワーク上のデータフローに対するパフォーマンスの保証レベルを維持することができる）のことを指す。ＱｏＳメカニズムを使用して、ネットワークアクセスデバイス（例えば、モデム、ルータ、スイッチ、及び、ネットワークサーバ）は、種々の優先順位を、種々のアプリケーション、ユーザ、又は、データフローに提供することができるか、又は、あるレベルのパフォーマンスを保証することができる。
【０００４】
固有のＱｏＳを必要とするアプリケーションネットワークトラフィックタイプは、ストリーミングマルチメディア、ＩＰ電話、ゲームなどを含む。各タイプのネットワークトラフィックは、異なるタイプのデータ配信サービスを必要とする。例えば、一般に、ストリーミングマルチメディアは、高保証スループット（高信頼データ配信、及び、低レベルの遅延の変動を有する）を必要とする。一方では、一般に、ＩＰ電話は、遅延及びジッタに対して厳しい制限を要求するが、データ損失にはより寛容である。したがって、ユーザの期待に応じつつ、その固有アプリケーションに対して良好なユーザ経験を提供するために、ネットワークが各アプリケーションに異なるＱｏＳを提供することが望ましい。
【０００５】
ＱｏＳを意識した（QoS-aware）アプリケーションがそのネットワークトラフィックに対する必要なＱｏＳを確立及び維持するための１つの既知のアプローチは、計算デバイス（アプリケーションが実行中である）のＱｏＳ ＡＰＩ（Application Programming Interface）であると考えられる。一般に、計算デバイスは、ＯＳ（Operating System）又はプラットフォーム固有ライブラリ又はサービスの一部として、ＱｏＳ ＡＰＩを提供する。したがって、そのＱｏＳ ＡＰＩは、本質的に、ＯＳ又はプラットフォーム固有である。このことから、多様なＯＳ、プラットフォーム、及び、ネットワークにわたるＱｏＳサポートを備えたネットワークアプリケーションを設計することは困難である。一般に、そのようにしようとする試みは、非常に複雑なＡＰＩ、又は、ＱｏＳコアレッセンス（coarseness）及びトランスペアレンシーのレベルを有するＡＰＩ（抽象化されすぎて、アプリケーションにＱｏＳレベルの有意義な仕様を提供することができない）となる。
【０００６】
この抽象化は、変わることなく、ＱｏＳ ＡＰＩ（ＭＡＣ層機能の詳細な制御監視なしで済ませる）を用いる結果となる。ＩＳＯ ＯＳＩアーキテクチャでは、ＭＡＣ（Media Access Control）機能は、デバイスの能力を制御して、ネットワークにアクセスし、かつ、データ通信サービスの全ＱｏＳに対して重大なインパクトを有する。加えて、ＭＡＣ機能は、ネットワークの動的な状態（例えば、インターフェース及び信号強度のレベル）を測定し、したがって、ネットワークトラフィックのＱｏＳのレベルを監視するのに重要である。したがって、ネットワークアプリケーションに対するＱｏＳの有効かつ成功裏のサポートを確実にするため、ＭＡＣ機能がＱｏＳサービスソリューションの一部であることが望まれる。
【発明の概要】
【課題を解決するための手段】
【０００７】
ＱｏＳ制御メカニズム（コンピュータデバイス上で実行中であるＱｏＳを意識したアプリケーションに対して、ＩＰソケットを介して、ネットワークデバイスのＱｏＳ機能にアクセスするため、ＱｏＳ ＡＰＩを提供する）が開示される。１態様では、ＡＰＩ（ＱｏＳを意識していないオペレーティングシステムに関連付けられた）は、ＱｏＳ ＡＰＩと置き換えられる。ＱｏＳ ＡＰＩは、ネットワークデバイスのＱｏＳ機能と協働して、アプリケーションに対して改善されたＱｏＳサポートを達成する。１態様では、ＱｏＳサポートは、物理ネットワークデバイスのファームウェア、及び／又は、デバイスに対するデバイスドライバ（複数可）において実行される。他の態様では、多数のネットワークデバイスにわたり通信を管理し、かつ、多数のネットワークにわたりデータ通信を調整して、所望のＱｏＳサービスレベルを保証するように、より高レベルのデバイスドライバの実装が行われる。
【０００８】
１態様では、新しいＱｏＳ制御メカニズムは、ＱＡｏＳ（QoS API over Socket）ハンドラ（handler）、及び／又は、ＭＡＣ層ＱＡｏＳハンドララッパー（wrapper）を利用して、データ（１又は複数のアクティブネットワークインターフェース上のアプリケーションによって転送及び受信されている）のＱｏＳを制御及び監視する。このメカニズムによって、ネットワークアクセスデバイス（コンピュータデバイスのシステムバスに直接接続されたか、又は、外部インターフェースを通じて間接的に接続された）をサポートすることができる。このサポートは、主としてＯＳ及びプラットフォームからは独立した方法で提供される。ＯＳ又はプラットフォーム固有のＱｏＳ ＡＰＩサポート又はアプリケーションの使用は必要とされていない。加えて、開示されるＱｏＳ制御メカニズムは、ＯＳ又はプラットフォームに変更を要求せず、将来の改訂例（新規のネットワーク及びＭＡＣ層ＱｏＳ体系に対する）に取り付けるための拡張性を提供する。開示されるＱｏＳ制御メカニズムの他の利点は、当業者には明らかである。
【０００９】
１態様では、ＱｏＳ制御のためのシステムは、１又は複数のＱｏＳを意識したアプリケーションと、１又は複数のＱｏＳサポートネットワークアクセスデバイスとを備えている。システムは、前記１又は複数のＱｏＳを意識したアプリケーションと、前記１又は複数のＱｏＳサポートネットワークアクセスデバイスとの間で動作するＱｏＳ管理及び報告通信プロトコルをさらに備えている。プロトコルは、ＩＰ（Internet Protocol）ソケットなどの双方向接続を通じて交換される。前記ＱｏＳを意識したアプリケーションは、ネットワークアクセスデバイスを通じて、データ通信ストリームのＱｏＳを制御及び管理する。
【００１０】
他の態様では、ＱｏＳ制御のための方法は、ＱｏＳ管理及び報告通信プロトコルを使用して、１又は複数のＱｏＳを意識したアプリケーションと、１又は複数のＱｏＳサポートネットワークアクセスデバイスとの間で、データを通信するステップを具備している。方法は、ネットワークアクセスデバイスを通じて、１又は複数のデータ通信ストリームに対するＱｏＳを制御及び管理するステップをさらに具備している。前記管理及び報告通信プロトコルは、ＩＰソケットなどの双方向通信を通じて交換される。
【００１１】
さらに他の態様では、ＱｏＳ制御のための方法は、ＱｏＳを意識したアプリケーションと、ＱｏＳサポートネットワークアクセスデバイスとの間で双方向通信を確立するステップと、前記確立された双方向通信を通じてＱｏＳ関連データを通信するステップとを具備している。前記双方向通信接続はＩＰソケットである。前記接続は、ＱｏＳを意識したアプリケーションと、ＱｏＳサポートネットワークアクセスデバイスのＭＡＣ層との間で確立される。前記ＱｏＳ関連データは、ＱｏＳ管理及び報告通信プロトコルを使用して通信される。
【００１２】
本発明は、以下の説明及び添付の図面（本発明の実施例を示すために使用される）を参照することによって最もよく理解される。
【図面の簡単な説明】
【００１３】
【図１】ネットワークアーキテクチャの１実施例の図である。
【図２】ＱｏＳメッセージの１実施例の図である。
【図３】ＱｏＳ制御メカニズムの１実施例の図である。
【発明を実施するための形態】
【００１４】
以下のＱｏＳシステム及び方法の説明は単に実例であって、どのような限定も意図されていないことが当業者には理解される。他の実施例が本開示の利益を有する当業者には容易に示唆される。添付図面に図示された実施例は、本発明の実施例を詳細に説明する。同じ参照表示は、同じ又は類似の項目を参照するため、可能な範囲内で図面及び以下の説明を通じて使用される。
【００１５】
明瞭性のため、ＱｏＳ制御メカニズムの実施例の所定の特徴の全てを図示及び説明してはいない。ネットワークアクセスメカニズムのそのような実際の実施例の開発では、開発者の固有の目標（例えば、アプリケーション、システム、ネットワーク、及び、ビジネス関連の制約に応じた）を達成するために、多数の実施例固有の判定がなされる必要があり、かつ、これらの固有の目標が実施例及び開発者によって異なることを当然理解しなければならない。さらに、開発労力は、煩雑かつ時間がかかるものであり、それにもかかわらず、この開示の利益を有する電気通信ネットワーク分野の当業者に対して、エンジニアリングの所定引き受けであることが理解される。
【００１６】
本開示に従って、本明細書に記載されたコンポーネント、プロセスステップ、及び／又は、データ構造は、多様なタイプのオペレーティングシステム、計算プラットフォーム、ネットワークデバイス、コンピュータプログラム、及び／又は、汎用機を使用して実施してもよい。加えて、本明細書に開示された発明コンセプトの範囲及び真の趣旨から逸脱することなく、汎用性の低いデバイス（例えば、ハードワイヤードデバイス、プログラマブルゲート配列（ＦＰＧＡ）、特定用途向けＩＣ（ＡＳＩＣ）など）を使用してもよいことが当業者には理解される。一連のプロセスステップを有する方法はコンピュータ又は機械によって実行され、かつ、これらのステップは一連の機械可読命令として格納することができ、それらは有形媒体に格納してもよい。
【００１７】
図１のブロック図は、本明細書に記載された原理に従って、１又は複数の通信ネットワーク上でデータ通信を実行する能力を備えたコンピュータシステムの１実施例を図示している。コンピュータシステム100は、パーソナルコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ、サーバ、セル電話、パーソナルデジタルアシスタント、マルチメディアデバイス（例えば、オーディオプレーヤ、ビデオプレーヤ、ゲーム機コンソール、デジタルカメラ、ビデオカメラ）、及び、その他のネットワーク300上でデータ通信可能なコンピュータ制御デバイスを含んでもよいが、これに限定されない。
【００１８】
通信ネットワーク300は、有線通信ネットワーク310,320と、無線通信ネットワーク360,370とを含んでもよいが、これに限定されない。例えば、通信ネットワーク300は、イーサネット（登録商標）（IEEE802.3）、IEEE802.11、又は、他の現在又は将来のＬＡＮシステムを利用する無線ローカルエリアネットワーク（ＷＬＡＮ）と、３ＧＰＰ（例えば、ＵＭＴＳ、ＨＳＤＰＡ、ＬＴＥ）、３ＧＰＰ２（例えば、ＣＤＭＡ、ＥＶＤＯ）、又は、他の現在又は将来のＷＷＡＮシステムを利用する無線ワイドエリアネットワーク（ＷＷＡＮ）と、ＷｉＭＡＸ（IEEE802.16）、又は、他の現在又は将来のＷＭＡＮシステムを利用する無線メトロポリタンエリアネットワーク（ＷＭＡＮ）と、IEEE802.15、ブルートゥース、及び、他のＷＰＡＮシステムを利用する無線パーソナルエリアネットワーク（ＷＰＡＮ）とを含んでもよいが、これに限定されない。
【００１９】
１実施例では、コンピュータシステム100は、処理ユニット140（例えば、Intel（登録商標）Dual-Core（登録商標）又はPentium（登録商標）プロセッサ、AMD Turion（登録商標）64プロセッサ、又は、他のタイプのＣＰＵ）を含む汎用コンピュータデバイス110を備えてもよい。それは、システムバス160（デバイス110のコンポーネントを相互接続する）をさらに備えている。デバイス110は、システムメモリ120（オペレーションシステム（ＯＳ）122を格納する）をさらに備えている。また、システムメモリ120は、処理ユニット140で実行される１又は複数のＱｏＳを意識したアプリケーション124と、他のタイプのデータ126とを格納してもよい。システムメモリは、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭ）、ＦＬＡＳＨ−ＥＰＲＯＭ、及び、他のタイプの動的、揮発性及び不揮発性の情報記憶媒体を含んでもよい。デバイス110は、１又は複数の有線及び／又は無線のネットワークインターフェースデバイス180（システムバス160を通じてコンピュータデバイス110に直接接続された）と、１又は複数の外部デバイスインターフェース（例えば、ＵＳＢシリアルバス166、シリアルポート、IEEE1394）とをさらに含んでもよい。
【００２０】
１実施例では、外部デバイスインターフェース（例えば、インターフェース166）は、コンピュータシステム100の代わりに、ネットワーク上でデータ通信を実行可能な１又は複数のコンピュータデバイスに接続してもよい。そのような外部デバイスは、モデムデバイス210（例えば、ダイアルアップモデム、ケーブルモデム、ＤＳＬモデム）、又は、他のネットワークアクセスデバイス（例えば、ルータ、スイッチ、無線アクセスポイント）などであってもよい。モデムデバイス210は、対応する外部デバイスインターフェース（例えば、ＵＳＢインターフェース240）（制御を交換し、かつ、トラフィックデータをネットワークするためのコンピュータデバイス110に接続を行うため）と、１又は複数の無線及び／又は有線ネットワークインターフェースデバイス260とを含んでいる。また、そのようなモデムデバイス210は、内部システムメモリ220（スタンドアローンＯＳ222及び他のデータ224を備えた）、及び、モデムデバイス210の複雑性によって内部システムバス280を含んでもよい。
【００２１】
ＱｏＳを意識したアプリケーション124がネットワーク300上でデータ通信に対する所望のＱｏＳを達成するため、アプリケーション124がベストエフォート（コンピュータデバイス110が達成及び保証することができる）よりも高いＱｏＳレベルを要求し、所望のＱｏＳレベルには通信ネットワーク300のＱｏＳ能力に対するインターフェースがないと仮定すれば、インターフェースがアプリケーション124と、ネットワークインターフェースデバイス180,260（通信ネットワーク300のＱｏＳ能力にアクセスするステップに関与する）のＭＡＣ層182,262における要素との間に存在しなければならないことが当業者には理解される。したがって、ＱｏＳを意識したアプリケーション124とネットワークインターフェースデバイス180,260のＱｏＳ機能との間に、特有のソケットベース又は他のタイプの双方向リンクが必要である。
【００２２】
１実施例では、新しいＱｏＳ制御メカニズムは、ネットワークインターフェースデバイス180,260のＭＡＣ層ＱｏＳ機能にアクセスするため、ＱｏＳを意識したアプリケーション124（コンピュータデバイス110上で実行中である）に対して、ＱｏＳ ＡＰＩを提供する。１実施例では、ＱｏＳ制御メカニズムは、ネットワークアクセスデバイス（コンピュータデバイス110のシステムバス160に直接接続されたか、又は、ＵＳＢインターフェース166などの外部インターフェースを通じて間接的に接続された）に対して、サポートを提供する。このサポートは、大部分は、ＯＳ及びプラットフォームから独立した方法で提供される。アプリケーション124においてＯＳ又はプラットフォーム固有のＱｏＳ ＡＰＩサポートは必要とされないことが当業者には理解される。
【００２３】
１実施例では、ネットワークアクセスメカニズムは、ＱｏＳ ＡＰＩメッセージを転送するために使用されるように、容易かつ十分に認識可能なデータ通信インターフェース（例えば、ソケット、ＩＰベース、又はその他）を備えてもよい。これらＱｏＳ ＡＰＩメッセージは、アプリケーション124と、直接又は間接的に接続されたネットワークインターフェースデバイス180,260のＭＡＣ層との間で転送してもよい。そのようなデータインターフェースの存在は、一般に、ネットワークトラフィックデータを転送又は受信するために、アプリケーションと、ネットワークデバイスのＭＡＣ層との間で使用されるので、ＱＡｏＳ（QoS API over Socket）メッセージングを運ぶのに必要とされるデータスタック（stack）は、一般に、そのような計算デバイス及びネットワークインターフェースデバイス180,260の中に含まれている。
【００２４】
ネットワークアクセスメカニズムの１実施例では、ネットワークインターフェースデバイス180,260のＭＡＣ層のＱＡｏＳ能力は、ＭＱＡ（MAC layer QAoS handler）において具体化してもよい。ＭＱＡは、ネットワークインターフェースデバイスの実際のＭＡＣ層、又は、１又は複数の対応するネットワークインターフェースデバイスに対する１又は複数のＭＡＣ層周りのラッパーとして作成してもよい。ＭＱＡがＭＡＣ層周りのラッパーとして存在する（ＭＱＡを本来的にサポートするか又はサポートしない）場合、ＭＱＡは、ＯＳ122の一部としてか又は他の方法で、ネットワークインターフェースデバイス内、コンピュータデバイス110とインターフェースするために、１又は複数のネットワークインターフェースデバイスに対するデバイス又は中間デバイスドライバ内に存在してもよい。後者のケースは、コンピュータシステム100が１以上のネットワークを同時にサポートするときに使用してもよく、かつ、データ通信が時間とともに異なるネットワーク320,370の中でハンドオフされるときにアプリケーション124とＭＱＡとの間でＱＡｏＳソケットを維持することが望まれる。
【００２５】
図３は、新規のＱｏＳ制御メカニズムの１実施例を図示している（ソケット522,524,527（例えば、ＴＣＰ／ＩＰ又はＵＤＰ／ＩＰソケット）上にトンネルされるＱｏＳ ＡＰＩメッセージングプロトコルを通じて、ＱｏＳを意識したアプリケーション510と、ネットワークインターフェースデバイス592,594,596,598のＭＡＣ層573,565,577,569ＱｏＳ管理要素との間で、アプリケーション510が実行中であるコンピュータデバイスのＯＳ及びプラットフォームのトランスポートプロトコル層（複数可）540及びネットワーキングプロトコル層（複数可）545を通じて、ＱｏＳを意識したアプリケーション510によって所望されたＱｏＳレベルを達成する）。開示されたＱＡｏＳ（QoS API over Socket）メカニズムは、大部分は、ＯＳ及びプラットフォームからは独立した方法を提供して、ネットワークインターフェースデバイスのＭＡＣ層573,565,577,569ＱｏＳ管理要素（ＱＡｏＳメッセージングのためのメカニズムが存在して、そのようなＱｏＳ管理要素にインターフェースすることを仮定する）にインターフェースする。
【００２６】
１実施例では、ＱＡｏＳ可能（capable）アプリケーション510は、ＱＡｏＳハンドラ520を含んでもよい。ハンドラ520は、同一又は類似のソケットインターフェース（アプリケーション510のＱＡｏＳ条件に合致しようとして、非ＱＡｏＳデータの通信に使用された）上のＱＡｏＳソケット522,524,527を開始、維持及び除去するように構成されている。したがって、ＯＳ及びプラットフォームに対するＱＡｏＳインターフェースの使用をサポートするために、アプリケーション510に対して要求される追加的な開発はほとんどない（アプリケーション510がＱＡｏＳ可能ネットワーキングインターフェースデバイスにわたり非ＱＡｏＳデータ通信を既にサポートする）。加えて、種々のＯＳ及びプラットフォームにわたるＱＡｏＳのためのポーティングサポートに対する労力のレベルは、大部分は、同じセットの種々のＯＳ及びプラットフォームにわたる非ＱＡｏＳデータ通信のためのポーティングサポートに対する労力に限定しなければならない。
【００２７】
１実施例では、ＭＱＡ（MAC QAoS API handler）が、アプリケーション510からＱＡｏＳソケット522,524,527を終了させるために設けられている。ＭＱＡ573,566,569,577は、ＱＡｏＳソケットの確立、維持及び終了のサーバタイプの管理を促進する。ＭＱＡ573,565,569,577は、下位のネットワーク及びネットワークインターフェースデバイス592,594,596,598のＭＡＣ層プロトコルメッセージングに対して、ＱＡｏＳソケットメッセージングリクエスト（アプリケーション510によって受信された）を、変換及び回送することを可能にする。ＭＱＡ573,565,569,577は、ＱＡｏＳソケット522,524,527を通じて、アプリケーション510に、関連のあるＭＡＣ層ＱｏＳ状況とイベント通知とを変換及び報告する。ＭＱＡ573,565,569,577は、アプリケーション510からＭＡＣ層に以前に回送されたリクエストに対して、ＭＡＣ層573,565,577,569ＱｏＳ管理要素から受信した応答を変換及び回送する。また、ＭＱＡ573,565,569,577は、当業者に既知の他の機能を提供するように構成可能である。
【００２８】
１実施例では、ＭＱＡ573,577は、ＭＡＣ層572,576に本来的に存在してもよい。しかし、他の実施例では、ネットワーキングインターフェースデバイスのＭＡＣ層がＭＱＡを本来的に含まない場合、ＭＱＡ（MAC QAoS handler）ラッパー565,569は、コンピュータデバイス（アプリケーション510が実行中である）のネットワーキングスタック545と、ネットワークインターフェースデバイス594,598のＭＡＣ層574,578との間の所定の場所に存在してもよく、したがって、ＭＡＣ層574,578のＱｏＳ管理要素に対するＱＡｏＳメッセージングのため、インターフェース565b，569bが存在する。上記した実施例は限定するものではなく、かつ、ＭＱＡは他の形態及びコンピュータシステムの他のロケーションで存在してもよいことが当業者には認識される。
【００２９】
１実施例では、ＭＱＡラッパー565,569は、デバイスドライバ564,568（ネットワーキングインターフェースデバイス594,598に対して設けられた）内に配置してもよく、したがって、ドライバ（非ＱＡｏＳデータ通信に必要とされる）がコンピュータデバイス（アプリケーション510が実行中である）のＯＳ及びプラットフォームに存在及びインストールされる限りは、デバイスは、ＯＳ、プラットフォーム及びアプリケーション510に対して、ＭＱＡサポートを本来的に提供するように見える。しかし、ＭＱＡがネットワーキングインターフェースデバイスのデバイスドライバよりも上位のプロトコル層に配置され、故に、コンピュータデバイス（アプリケーション510が実行中である）のＯＳ及びプラットフォーム上に、より多くのＱＡｏＳ従属性（dependency）を作成することが可能である。これはあまり所望されないが、このアプローチには他の利益（多様な実施例のさらなる説明から明らかになる）がある。
【００３０】
コンピュータシステムがいくつかのネットワークとの接続を同時にサポートする場合（例えば、有線及び無線）、データ通信が時間とともにハンドオフされ、かつ／又は、２以上の異なるインターフェースデバイス596,598を介して、同時に種々のネットワークの中で動的又は静的に分配される間に、アプリケーション510は、ＭＱＡを用いて、そのＱＡｏＳソケットを維持するように構成してもよい。そのためには、ＭＭＱＡＡ（Multi-MAC QAoS handler arbitrator）548が設けられて、アプリケーション510と２以上のＭＱＡ及び／又はＭＱＡラッパー577,569との間で、単一セットのＱＡｏＳソケット527,517を終了及び維持してもよく、したがって、ＱｏＳ関連のオペレーション（ネットワーク間のハンドオフによって生じた）、及び、対応するネットワークインターフェースデバイス596,598、又は、同じネットワークにわたるデータの動的又は静的分配は、複数のネットワーク接続にわたるこのシームレスＱｏＳオペレーションがアプリケーション510によって所望される場合、ＱＡｏＳソケット527,517を利用するアプリケーション510に対して透過的である。
【００３１】
１実施例では、ＭＭＱＡＡ548を、中間デバイス（例えば、中間ドライバ547）内に含んでもよく、ネットワーキングインターフェースデバイス596,598に直接又は間接的に関連付けてもよい。この方法では、ＭＭＱＡＡ548は、ＯＳ及び下位の計算プラットフォームからは比較的独立している。さらに、ＭＭＱＡＡ548は、ＱＡｏＳソケット527,517と、その上に運ばれたオペレーションとのアービトレーションを行うように構成されて、したがって、ドライバ（ネットワークインターフェースデバイスにわたる非ＱＡｏＳデータ通信アービトレーションに対して必要とされる）が、コンピュータデバイス（アプリケーション510が実行中である）のＯＳ及びプラットフォーム上に存在及びインストールされる限りは、中間ドライバ547は存在しなければならない。
【００３２】
他の実施例では、ＭＭＱＡＡ548を、コンピュータデバイス（アプリケーション510が実行中である）のＯＳ又はプラットフォーム固有の部分内に含んでもよい。この場合、ＭＭＱＡＡ548は、具体化されて、シームレスかつ透過的なＱＡｏＳソケット、及び、アプリケーション510を用いたオペレーション（コンピュータシステムに接続された利用可能なネットワーキングインターフェースデバイスにわたる）を維持することができる（ＭＭＱＡＡ548は、ネットワークインターフェースデバイスのＭＱＡと、同じコンピュータシステムに接続された１又は複数のネットワークインターフェースデバイスのＭＱＡ（複数可）との間で、ＱＡｏＳオペレーションのアービトレーションを行う能力を有する）。上記した実施例は限定するものではなく、かつ、ＭＭＱＡＡは他の形態及びコンピュータシステムの他のロケーションで存在してもよいことが当業者には認識される。
【００３３】
ＯＳ又はプラットフォーム固有のＱｏＳ ＡＰＩ530を既に利用するレガシーアプリケーション510に備えて（ＯＳ又はプラットフォームが既存のＯＳ又はプラットフォーム固有のＱｏＳ ＡＰＩを廃止しようとする）、ＱＡｏＳシム535を１実施例に従って提供してもよい。ＱＡｏＳシム535は、ＯＳ又はプラットフォーム固有のＱｏＳ ＡＰＩ530と、接続されたＭＱＡ可能ネットワークインターフェースデバイス592,594,596,598のＱＡｏＳメッセージングソケット512,514,517上のＭＱＡ573,565,577,569との間で、必要な変換531を実行してもよい。例えば、ＱｏＳ ＡＰＩ530によって設けられたＱｏＳリクエスト及び応答のフォーマットは、使用中のＭＱＡにおいてサポートされたＱｏＳリクエスト及び応答メッセージに対応（１対１でマッピング）しない（即ち、それらは、異なるＱｏＳ制御及び状況メッセージングプロトコル言語／ＡＰＩを話す）。この場合、ＱＡｏＳシム535は、ＯＳ／プラットフォームと使用中のＭＱＡとの間でＱｏＳ ＡＰＩ言語の変換を実行してもよい。他の実施例では、ＯＳ／プラットフォーム固有のＱｏＳ ＡＰＩ530は、ＱｏＳを意識したアプリケーション510に高レベル（例えば、サービス層）のＱｏＳ ＡＰＩだけを提供してもよく、かつ、ＱＡｏＳシム535は、上位レベルのＱｏＳ ＡＰＩ間で、下位レベル（例えば、ネットワーク層）のＱｏＳ ＡＰＩ（使用中のＭＱＡによってサポートされた）に変換してもよい。さらに他の実施例では、ＱｏＳサービスフロー、分類など（ＯＳ／プラットフォーム固有のＱｏＳ ＡＰＩ530を通じてアプリケーションによって指定されるように帰属する）は、同じグラニュール数、レンジ、エニュメレーション（enumeration）など（使用中の関連するネットワークインターフェースデバイス（複数可）のＭＱＡによってサポートされる）をサポートしなくてもよい。したがって、ＱＡｏＳシム533は、これらのＡＰＩ属性差異の間で変換する。他の実施例では、ＯＳ／プラットフォーム固有のＱｏＳ ＡＰＩは、ＯＳ／プラットフォームの開始のときに、業界において利用可能な無線アクセス技術（例えば、802.3及び802.11）のＱｏＳ能力を指定するようにだけ設計してもよい。この場合、拡張性のため、ＱＡｏＳシム535は、ＯＳ／プラットフォーム固有のＱｏＳ ＡＰＩを更新する必要がなく、それらが利用可能になるように、新規の無線アクセス技術（例えば、802.16m）においてサポートされた新規のＱｏＳ能力に対して必要な変換を提供してもよい。レガシーアプリケーション又はコンピュータシステムを用いて、開示されたＱｏＳ制御メカニズムの実施例を一体化するための他の方法が存在することを当業者は認識する。
【００３４】
ＭＱＡ使用可能（MQA-enabled）ネットワークデバイスがＩＰアドレスを有するとき、メッセージ（ＱｏＳを意識したアプリケーションによってこのＩＰアドレスに送信された）を、コンピュータデバイス（ＱｏＳを意識したアプリケーションが実行中である）のＯＳによってループバックしてもよいことを当業者は認識する。この問題点を回避するために、追加的なエントリがＯＳルーティングテーブルにおいてなされて、ＭＱＡ利用可能ネットワークデバイスに対して適合してもよい。ＭＱＡは、受信データトラフィック（その割り当てられたＩＰアドレス上でフィルタリングする）を監視してもよい。マッチングがあり、かつ、それがＱＡｏＳメッセージではない場合、それはＯＳにループバックされる（これは上位互換を維持する）。マッチングがあり、かつ、それが有効なＱＡｏＳメッセージである場合、次いで、それはＭＱＡによって処理される。ＱｏＳを意識したアプリケーションは、ＯＳコールバック（ネットワークデバイスがＩＰアドレスを取得したときを示す）を監視又は登録してもよい。これは、新規のネットワークデバイスのそれに、宛先アドレスセットを有するＱＡｏＳパケットを生成することによって、ＭＱＡ利用可能ネットワークデバイスを用いて、ＱＡｏＳセッションを開始するためのアプリケーションに対するトリガである。固有ポート番号は、通常のＴＣＰセッション方法によって決定してもよい。
【００３５】
したがって、割り当てられたＩＰアドレスは、アプリケーションによって使用されて、各ＭＱＡ利用可能ネットワークデバイスを識別し、かつ、固有ポート番号は、ＭＱＡによって使用されて、ＱｏＳを意識したアプリケーションを固有に定義する。この方法では、各ソケット（特定のＱｏＳを意識したアプリケーションと、１又は複数の関連したネットワークインターフェースデバイスのＭＱＡとの間の）は固有であり、したがって、ＭＱＡは、他のアプリケーションからリクエスト中のアプリケーションを識別及び区別することができ、かつ、リクエスト中のアプリケーションは、特定のＭＱＡと、関連するネットワークインターフェースデバイス（複数可）（ＱＡｏＳメッセージが受信された）とを識別及び区別することができる。さらに、ＯＳルーティングテーブル更新は、デフォルトのルーティングテーブルエントリ、又は、ＶＰＮが使用中であるか否かに拘わらず、常に、アプリケーションパケットが適したＭＱＡ利用可能ネットワークデバイスにルートされることを保証する。
【００３６】
１実施例では、ＱｏＳ ＡＰＩメッセージングプロトコルが設けられる。図２は、ＱＡｏＳメッセージフォーマットの１実施例である。メッセージ400は、インターネットプロトコルヘッダ410と、トランスポートプロトコルヘッダ420と、ＱＡｏＳヘッダ430と、ＱＡｏＳデータ440とを具備してもよい。ＱＡｏＳヘッダ430は、ＱＡｏＳバージョン番号434と、ＱＡｏＳプロトコルコード436とを含んでもよく、システムによって使用されたＱＡｏＳプロトコルの特定のタイプを識別する。図示したように、プロトコルメッセージは、ＱＡｏＳパケットヘッダ430内にカプセル化してもよい。このカプセル化メカニズムは、アプリケーションとＭＱＡとの間で、ＱＡｏＳメッセージングの実データペイロードフォーマットの明確化及び折衝を可能にする。これは、標準化及び固有のＱｏＳ ＡＰＩメッセージングプロトコルの両方、及び、そのプロトコルの複数の改訂版が、アプリケーションとＭＱＡとの間で、ＱｏＳ ＡＰＩメッセージングのトランスポートに対してサポートされることを可能にする。
【００３７】
いったんソケットがＱＡｏＳ及びＱｏＳ ＡＰＩメッセージングプロトコル上で確立され、かつ、改訂版がＭＱＡと折衝されると、アプリケーションは、ＱＡｏＳを使用して、ＱｏＳ通知を受信し、かつ、ＱｏＳリクエストを送信することができる。ＱｏＳ通知は、ネットワークにおける異なるレベル及びタイプのＱｏＳの現在の利用可能性に関する情報、利用可能及び／又はアクティブネットワークサービスフローのセット、対応する利用可能及び／又はアクティブ各サービスブローの分類子（複数可）、現在及び利用可能サービスフローデータ作成体系（ネットワークによってサポートされた）、確定及び／又はアクティブネットワークフィルタリング又はデータのスロットリング、及び、他のサービスを含んでもよい。ＱｏＳリクエストを使用して、ネットワークインターフェースデバイス（複数可）のＭＡＣ層及び対応するネットワーク（複数可）のＱｏＳサービスフロー、分類子、データフィルタリング、シェーピング、及び、データスロットリングフィーチャを、折衝、追加、変更、削除、添付、切り離し、活性化、非活性化してもよい。
【００３８】
また、アプリケーションとＭＱＡの間でＱＡｏＳリンクを使用して、対応するネットワーク（複数可）におけるＱｏＳ属性及び状況変化を報告することができる。１実施例では、ネットワークデバイスは、ネットワーク特性を定期的に監視していてもよく、かつ、これらの特性が取り決められたＱｏＳサービスレベルをもはや達成可能でないように変化した場合、ＱｏＳを意識したアプリケーションと通信し、かつ、それに変化を知らせ、したがって、ＱｏＳを意識したアプリケーションは、必要なアクションをとるか否かを判断してもよい。ＱｏＳを意識したアプリケーションからのＱｏＳリクエストに応答して、ネットワークデバイスは、ネットワーク層タグ又はネットワーク層メッセージを挿入／添付してもよく、それによって、ダウンストリームネットワークルーティングデバイスに指示して、所定のＱｏＳを意識したアプリケーションによってリクエストされたネットワーク層ＱｏＳメカニズムを実行する。
【００３９】
１実施例では、ネットワークインターフェースデバイスのＭＱＡは、ブロードキャストＱｏＳ ＡＰＩイベント通知を、容易に認識可能及び固有のマルチキャストソケット上の全てのリスニングＱｏＳを意識したアプリケーションに送信してもよい。ＱｏＳを意識したアプリケーションは、そのマルチキャストＱＡｏＳソケットを登録及び登録取消を実行してもよい。他の実施例では、アプリケーションは再登録し、かつ／又は、ＭＱＡに対して方法を提供して、無効のＱＡｏＳソケット、及び、関連するソケットの取得されたネットワークＱｏＳリソースを解放することがいつ許可されるかを決定するために、ＭＱＡは、アプリケーションをピング（ping）してもよい。多様な変形例では、ＭＱＡは当業者に既知の他の機能を提供してもよい。
【００４０】
本明細書に記載されたシステム及びモジュールは、ソフトウェア、ファームウェア、ハードウェア、又は、ソフトウェア、ファームウェア、又はハードウェアの組み合わせ（複数可）（本明細書に記載された目的に適した）を具備してもよい。ソフトウェア及び他のモジュールは、サーバ、ワークステーション、パーソナルコンピュータ、コンピュータタブレット、ＰＤＡ、及び、他のデバイス（本明細書に記載された目的に適した）に常駐してもよい。ソフトウェア及び他のモジュールは、ローカルメモリ、ネットワーク、ブラウザ又はＡＳＰコンテキストの他のアプリケーション、又は、他の手段（本明細書に記載された目的に適した）を介して、アクセス可能であってもよい。本明細書に記載されたデータ構造は、コンピュータファイル、変数、プログラミングアレイ、プログラミングストラクチャ、又は、電子情報記憶体系又は方法、又は、それらの組み合わせ（本明細書に記載された目的に適した）を具備してもよい。
【００４１】
実施例及びアプリケーションが図示及び説明されたが、本明細書に開示された発明のコンセプトから逸脱することなく、上記した以上の変形例が可能であることは、この開示の利益を有する当業者には明らかである。したがって、本発明は添付の特許請求の範囲の真の趣旨を除いて限定はされない。
【符号の説明】
【００４２】
100  コンピュータシステム
110  コンピュータデバイス
120  システムメモリ
122  ＯＳ
124  アプリケーション
126  他のデータ
140  処理ユニット
160  システムバス
166  ＵＳＢインターフェース
180  ネットワークインターフェース
182  ＭＡＣ層
210  モデムデバイス
220  システムメモリ
222  ＯＳ
224  他のデータ
240  ＵＳＢインターフェース
260  ネットワークインターフェース
262  ＭＡＣ層
280  システムバス
300  通信ネットワーク
【図１】
2010521829.tif 000003
【図２】
2010521829.tif 000004
【図３】
2010521829.tif 000005
【手続補正書】
【提出日】平成21年9月14日(2009.9.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
システムであって、
１又は複数のＱｏＳを意識したアプリケーションと、
１又は複数のＱｏＳサポートネットワークアクセスデバイスと、
前記１又は複数のＱｏＳを意識したアプリケーションと、前記１又は複数のＱｏＳサポートネットワークアクセスデバイスとの間で動作する、ＱｏＳ管理及び報告通信プロトコルと
を備え、
前記１又は複数のＱｏＳを意識したアプリケーションは、前記１又は複数のＱｏＳを意識したネットワークアクセスデバイスを通じて、データ通信ストリームのＱｏＳを制御及び管理することを特徴とするシステム。
【請求項２】
前記管理及び報告通信プロトコルは、双方向接続を通じて交換されることを特徴とする請求項１に記載のシステム。
【請求項３】
前記ＱｏＳ管理及び報告通信プロトコル上で通信するＱｏＳを意識したアプリケーションとＱｏＳサポートネットワークアクセスデバイスのそれぞれのペア間に、１対１の関係があることを特徴とする請求項１に記載のシステム。
【請求項４】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークアクセスデバイスにおいて実行されることを特徴とする請求項１に記載のシステム。
【請求項５】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークデバイスに対するデバイスドライバにおいて実行されることを特徴とする請求項１に記載のシステム。
【請求項６】
前記ＱｏＳを意識したアプリケーションは、前記ＱｏＳ管理及び報告通信プロトコルを実行する中間デバイスを通じて、前記ＱｏＳサポートネットワークアクセスデバイスと通信することを特徴とする請求項１に記載のシステム。
【請求項７】
前記ＱｏＳサポートネットワークアクセスデバイスは、複数のネットワークアクセスデバイスに対する仲介であることを特徴とする請求項１に記載のシステム。
【請求項８】
前記ＱｏＳサポートネットワークアクセスデバイスは、１又は複数の前記ネットワークアクセスデバイス上で、前記データトラフィックをルートすることを特徴とする請求項７に記載のシステム。
【請求項９】
前記ＱｏＳサポートネットワークアクセスデバイスは、前記ＱｏＳ管理及び報告通信プロトコルを使用して、前記ＱｏＳを意識したアプリケーションに、ＱｏＳ状況情報を提供することを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ＱｏＳサポートネットワークアクセスデバイスは、データ通信リンクを通じて、前記ＱｏＳを意識したアプリケーションにリモートに接続されることを特徴とする請求項１に記載のシステム。
【請求項１１】
方法であって、
ＱｏＳ管理及び報告通信プロトコルを使用して、１又は複数のＱｏＳを意識したアプリケーションと、１又は複数のＱｏＳサポートネットワークアクセスデバイスとの間で、データ通信するステップと、
１又は複数のネットワークアクセスデバイスを通じて、１又は複数のデータ通信ストリームのＱｏＳを制御及び管理するステップと
を具備することを特徴とする方法。
【請求項１２】
前記管理及び報告通信プロトコルは、双方向接続を通じて交換されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ＱｏＳ管理及び報告通信プロトコル上で通信するＱｏＳを意識したアプリケーションとＱｏＳサポートネットワークアクセスデバイスのそれぞれのペア間に、１対１の関係があることを特徴とする請求項１１に記載の方法。
【請求項１４】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークアクセスデバイスにおいて実行されることを特徴とする請求項１１に記載の方法。
【請求項１５】
前記ネットワークアクセスデバイスの前記ＱｏＳサポート機能は、前記ネットワークデバイスに対するデバイスドライバにおいて実行されることを特徴とする請求項１１に記載の方法。
【請求項１６】
方法であって、
ＱｏＳを意識したアプリケーションと、ＱｏＳサポートネットワークアクセスデバイスとの間で、双方向接続を確立するステップと、
前記確立された双方向接続を通じて、ＱｏＳ関連データを通信するステップと
を具備することを特徴とする方法。
【国際調査報告】
2010521829.tif 000006