JP2015173473A - 発展型アプリケーションインターフェースのためのスケーラブルなポリシー制御パケットインスペクションのシステムおよび方法 - Google Patents

Abstract

【課題】サービス品質情報を決定するためのシステム、方法、および手法が、開示される。
【解決手段】ユーザ機器（ＵＥ）などのデバイスが、ポリシーを受信することができる。ポリシーは、セッションに関するアプリケーションの特定に関連するインスペクションのレベルを示す可能性がある。デバイスは、セッションに関連する情報を受信することができる。例えば、情報は、アプリケーションが提供する情報、パケットデータ、オペレーティングシステムが提供する情報などを含み得る。デバイスは、ポリシーによって示されたレベルで、受信された情報のインスペクションを実行することができる。デバイスは、セッションに関連するアプリケーションを特定するためにインスペクションを実行することができる。
【選択図】図１Ａ

Description

本発明は、発展型アプリケーションインターフェースのためのスケーラブルなポリシー制御パケットインスペクションのシステムおよび方法に関する。

（関連出願の相互参照）
本出願は、２０１０年１０月２７日に出願された米国仮出願第６１／４０７，３６６号および２０１１年４月１１日に出願された米国仮出願第６１／４７４，０１７号の利益を主張するものであり、これらの仮出願の内容は、参照により本明細書に組み込まれる。

サービス品質（ＱｏＳ）のプロビジョニングは、広くは、異なるアプリケーション、ユーザ、もしくはデータフローに異なる優先度を与える能力か、またはデータフローに特定のレベルの性能を保証する能力と考えられる可能性がある。例えば、必要とされるビットレート、遅延、ジッタ、パケット破棄の確率、および／またはビット誤り率が、保証される可能性がある。ＱｏＳの保証は、ネットワークの容量が不十分である場合に重要であり、特に、ボイスオーバーＩＰ、オンラインゲーム、およびＩＰ−ＴＶなどのリアルタイムのストリーミングマルチメディアアプリケーションは、しばしば固定ビットレートを必要とし、遅延に影響されやすいので、これらのリアルタイムのストリーミングマルチメディアアプリケーションにとって、また、容量が限られたリソースであるネットワーク、例えば、セルラデータ通信において重要であり得る。

Ｌ４のＭＰＴＣＰまたはＭＡＣにおけるマルチＲＡＴの動的スペクトル管理（ｍｕｌｔｉ−ｒａｔ Ｄｙｎａｍｉｃ Ｓｐｅｃｔｒｕｍ Ｍａｎａｇｅｍｅｎｔ）技術などの多接続プロトコルの登場は、ＱｏＳの必要性を新しい観点から再びもたらす可能性がある。選択できる複数の接続オプションを持つことは、ＱｏＳの管理に関する新たな自由度を生み出す可能性がある。特に、１つのパラメータを最適化することは、ひいては異なるパラメータを最適化する異なる接続管理のアプローチにつながることが多い（例えば、レイテンシの最小化とピークアグリゲートレート（ｐｅａｋ ａｇｇｒｅｇａｔｅ ｒａｔｅ）とは、多くの場合、利用可能な接続をそれぞれ異なるやり方で利用することによって実現される）。

この「発明の概要」は、「発明を実施するための形態」において以下でさらに説明される抜粋した概念を簡素化された形態で紹介するために提供される。この「発明の概要」は、特許請求の対象の重要な特徴または必須の特徴を特定するように意図されておらず、特許請求の対象の範囲を限定するために使用されるように意図されてもいない。

サービス品質情報を決定するためのシステム、方法、および手法が、開示される。ユーザ機器（ＵＥ）などのデバイスが、ポリシーを受信することができる。ポリシーは、セッションに関するアプリケーションの特定に関連するインスペクションのレベルを示す可能性がある。デバイスは、セッションに関連する情報を受信することができる。例えば、情報は、アプリケーションが提供する情報、パケットデータ、オペレーティングシステムが提供する情報などを含み得る。デバイスは、ポリシーによって示されたレベルで、受信された情報のインスペクションを実行することができる。デバイスは、セッションに関連するアプリケーションを特定するためにインスペクションを実行することができる。

ポリシーが、インスペクションのレベルがインスペクションの第１のレベルであることを示す可能性があり、受信された情報が、アプリケーションが提供する情報（例えば、ソケット呼び出し、５つ組みのフローマーカー（ｆｌｏｗ ｍａｒｋｅｒ）など）を含む可能性がある。インスペクションの第１のレベルは、インスペクションが、アプリケーションが提供する情報を検査することを含むことを示す可能性がある。デバイスは、セッションに関連するアプリケーションを特定するためにインスペクションを実行することができる。例えば、アプリケーションが提供する情報は、ソケット呼び出しを含む可能性があり、インスペクションの第１のレベルは、ソケット呼び出しに関連するポートを特定されたポートと比較することを含む可能性がある。特定されたポートは、ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ）によって特定されたポートなどの知られているポートである可能性がある。特定されたポートは、アプリケーションに関連付けられ得る。デバイスは、セッションに関連するアプリケーションを、特定されたポートに関連するアプリケーションとして特定することができる。

ポリシーが、インスペクションのレベルがインスペクションの第２のレベルであることを示す可能性があり、受信された情報が、パケットデータを含む可能性がある。インスペクションの第２のレベルは、インスペクションがパケットデータのパケットインスペクションを含むことを示す可能性がある。インスペクションの第２のレベルは、パケットインスペクションの深さを示す可能性がある。それぞれ異なる深さは、それぞれ異なる計算集約的なインスペクションを示す可能性がある。例えば、深さは、最上位レベルのプロトコルを特定／確認すること、プロトコルによって開かれたセッションを特定／確認すること、アプリケーションのサブフローを特定／確認することなどのためにパケットインスペクションを実行することを示す可能性がある。デバイスは、示されたレベルおよび深さでインスペクションを実行し、インスペクションに基づいてセッションに関連するアプリケーションを特定することができる。

ポリシーは、インスペクションのレベルがインスペクションの第３のレベルであることを示す可能性がある。デバイスは、（例えば、ポリシーに基づいて）オペレーティングシステムに問い合わせを行う可能性がある。デバイスは、オペレーティングシステムが提供する情報を受信する可能性がある。受信された情報は、オペレーティングシステムが提供する情報を含む可能性がある。インスペクションの第３のレベルは、インスペクションが、オペレーティングシステムが提供する情報を検査することを含むことを示す可能性がある。デバイスは、そのインスペクションを実行し、インスペクションに基づいてセッションに関連するアプリケーションを特定することができる。

より詳細な理解が、添付の図面と併せて例として与えられる以下の説明から得られるであろう。

１つまたは複数の開示された実施形態が実装され得る例示的な通信システムのシステム図である。 図１Ａに示された通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａに示された通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ａに示された通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 図１Ａに示された通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 ＱｏＳの選択に影響を与え得る例示的なアクターを示す図である。 ＱｏＳサブシステムの例示的なアーキテクチャを示す図である。 セッション、サブフロー、およびサブストリームをサポートする例示的なシステムを示す図である。 例示的なＡＳＩＦ ＦＣを示す図である。 例示的なセッションのライフタイムを示す図である。 例示的な状態遷移図である。 例示的なパケットインスペクションを示す図である。 例示的なＳｅｓｓｉｏｎＯｐｅｎプロセスを示す図である。 例示的なＳｅｓｓｉｏｎＣｏｎｎｅｃｔプロセスを示す図である。

以降、例示的な実施形態の詳細な説明が、図を参照して示される可能性がある。しかし、本発明が例示的な実施形態に関連して説明される可能性があるが、本発明はそれらの例示的な実施形態に限定されず、本発明の同様の機能を実行するために、本発明を逸脱することなくその他の実施形態が使用され得るか、または記載された実施形態に対して修正および追加が行われ得ることが理解されるべきである。さらに、図は、例示的であるように意図されるコールフローを示す可能性がある。その他の実施形態が使用され得ることを理解されたい。フローの順序は、必要に応じて変更され得る。また、フローは不必要な場合は省略される可能性があり、追加的なフローが追加される可能性がある。

図１Ａは、１つまたは複数の開示された実施形態が実装され得る例示的な通信システム１００の図である。通信システム１００は、複数の無線ユーザに音声、データ、ビデオ、メッセージング、放送などのコンテンツを提供する多元接続システムである可能性がある。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有によってそのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの１つまたは複数のチャネルアクセス方法を使用することができる。

図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（これらは全体的にまたは集合的にＷＴＲＵ１０２と呼ばれる可能性がある）、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、ならびにその他のネットワーク１１２を含み得るが、開示された実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を考慮することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境内で動作および／または通信するように構成された任意の種類のデバイスである可能性がある。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成される可能性があり、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサー、家庭用電化製品などを含み得る。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含み得る。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインターフェースをとるように構成された任意の種類のデバイスである可能性がある。例として、基地局１１４ａ、１１４ｂは、無線基地局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどである可能性がある。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互に接続された基地局および／またはネットワーク要素を含み得ることが理解されるであろう。

基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であることができ、ＲＡＮ１０３／１０４／１０５は、その他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示せず）も含み得る。基地局１１４ａおよび／または基地局１１４ｂは、セルと呼ばれる場合がある特定の地理的領域（図示せず）内で無線信号を送信および／または受信するように構成され得る。セルは、セルのセクタにさらに分割され得る。例えば、基地局１１４ａに関連するセルは、３つのセクタに分割され得る。したがって、一実施形態において、基地局１１４ａは、３つのトランシーバ、すなわち、セルの各セクタに対して１つのトランシーバを含み得る。別の実施形態において、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を使用することができ、したがって、セルの各セクタに対して複数のトランシーバを利用する可能性がある。

基地局１１４ａ、１１４ｂは、任意の好適な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）である可能性がある無線インターフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができる。無線インターフェース１１５／１１６／１１７は、任意の好適な無線アクセス技術（ＲＡＴ）を用いて確立され得る。

より具体的には、上述のように、通信システム１００は、多元接続システムである可能性があり、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセススキームを使用する可能性がある。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を用いて無線インターフェース１１５／１１６／１１７を確立することができるＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）ＵＴＲＡ（Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）などの無線技術を実装することができる。ＷＣＤＭＡ（登録商標）は、ＨＳＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）および／またはＨＳＰＡ＋（Ｅｖｏｌｖｅｄ ＨＳＰＡ）などの通信プロトコルを含み得る。ＨＳＰＡは、ＨＳＤＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）および／またはＨＳＵＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）を含み得る。

別の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）および／またはＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）を用いて無線インターフェース１１５／１１６／１１７を確立することができるＥ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）などの無線技術を実装することができる。

その他の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００）、ＩＳ−９５（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５）、ＩＳ−８５６（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６）、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）、ＧＥＲＡＮ（ＧＳＭ ＥＤＧＥ）などの無線技術を実装することができる。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントである可能性があり、事業所、家庭、車両、キャンパスなどの局所的な地域で無線接続を容易にするための任意の好適なＲＡＴを利用することができる。一実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立するためのＩＥＥＥ８０２．１１などの無線技術を実装することができる。別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立するためのＩＥＥＥ８０２．１５などの無線技術を実装することができる。さらに別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラに基づくＲＡＴ（例えば、ＷＣＤＭＡ（登録商標）、ＣＤＭＡ２０００、ＧＳＭ（登録商標）、ＬＴＥ、ＬＴＥ−Ａなど）を利用してピコセルまたはフェムトセルを確立することができる。図１Ａに示されたように、基地局１１４ｂは、インターネット１１０への直接的な接続を有する可能性がある。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスするように要求されない可能性がある。

ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信している可能性があり、コアネットワーク１０６／１０７／１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスを提供するように構成された任意の種類のネットワークである可能性がある。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、課金サービス、モバイルの位置に基づくサービス、プリペイド電話、インターネット接続、映像配信などを提供し、および／またはユーザ認証などの高レベルのセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴ、または異なるＲＡＴを使用するその他のＲＡＮと直接的または間接的に通信している可能性があることが理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用している可能性があるＲＡＮ１０３／１０４／１０５に接続されることに加えて、コアネットワーク１０６／１０７／１０９は、ＧＳＭ（登録商標）無線技術を使用する別のＲＡＮ（図示せず）とも通信している可能性がある。

コアネットワーク１０６／１０７／１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとしても働くことができる。ＰＳＴＮ１０８は、ＰＯＴＳ（ｐｌａｉｎ ｏｌｄ ｔｅｌｅｐｈｏｎｅ ｓｅｒｖｉｃｅ）を提供する回線交換電話ネットワークを含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートの伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの共通の通信プロトコルを使用する相互に接続されたコンピュータネットワークおよびデバイスの全世界的なシステムを含み得る。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運用される有線または無線通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴ、または異なるＲＡＴを使用する可能性がある１つまたは複数のＲＡＮに接続された別のコアネットワークを含み得る。

通信システム１００のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部またはすべては、マルチモード能力を含む可能性があり、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含む可能性がある。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラに基づく無線技術を使用することができる基地局１１４ａと、およびＩＥＥＥ８０２無線技術を使用することができる基地局１１４ｂと通信するように構成され得る。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されたように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカー／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不可能なメモリ１３０、取り外し可能なメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、およびその他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、実施形態に準拠したまま、上述の要素の任意の部分的な組み合わせを含み得ることが理解されるであろう。また、実施形態は、基地局１１４ａおよび１１４ｂ、ならびに／またはそれだけに限らないが無線基地局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームＮｏｄｅ−Ｂ、進化型ホームＮｏｄｅ−Ｂ（ｅｖｏｌｖｅｄ ｈｏｍｅ ｎｏｄｅ−Ｂ）（ｅＮｏｄｅＢ）、ホーム進化型ｎｏｄｅ−Ｂ（ｈｏｍｅ ｅｖｏｌｖｅｄ ｎｏｄｅ−Ｂ）（ＨｅＮＢ）、ホーム進化型ｎｏｄｅ−Ｂゲートウェイ（ｈｏｍｅ ｅｖｏｌｖｅｄ ｎｏｄｅ−Ｂ ｇａｔｅｗａｙ）、およびプロキシノードなどの、基地局１１４ａおよび１１４ｂによって表され得るノードは、図１Ｂに示され、本明細書において説明される要素の一部またはすべてを含み得ると想定する。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、通常のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意のその他の種類の集積回路（ＩＣ）、状態機械などである可能性がある。プロセッサ１１８は、信号の符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする任意のその他の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合される可能性があり、トランシーバ１２０は、送信／受信要素１２２に結合される可能性がある。図１Ｂはプロセッサ１１８およびトランシーバ１２０を別個のコンポーネントとして示すが、プロセッサ１１８およびトランシーバ１２０は、電子的なパッケージまたはチップに一緒に統合され得ることが理解されるであろう。

送信／受信要素１２２は、無線インターフェース１１５／１１６／１１７を介して基地局（例えば、基地局１１４ａ）に信号を送信するか、または基地局（例えば、基地局１１４ａ）から信号を受信するように構成され得る。例えば、一実施形態において、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナである可能性がある。別の実施形態において、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタである可能性がある。さらに別の実施形態において、送信／受信要素１２２は、ＲＦ信号および光信号の両方を送信および受信するように構成され得る。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成され得ることが理解されるであろう。

加えて、送信／受信要素１２２は、図１Ｂにおいて単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含み得る。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を使用することができる。したがって、一実施形態において、ＷＴＲＵ１０２は、無線インターフェース１１５／１１６／１１７を介して無線信号を送信および受信するために２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含み得る。

トランシーバ１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成され得る。上述のように、ＷＴＲＵ１０２は、マルチモード能力を有する可能性がある。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が例えばＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数のトランシーバを含み得る。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカー／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合される可能性があり、それらからユーザ入力データを受信する可能性がある。プロセッサ１１８は、スピーカー／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。さらに、プロセッサ１１８は、取り外し不可能なメモリ１３０および／または取り外し可能なメモリ１３２などの任意の種類の好適なメモリからの情報にアクセスし、それらのメモリにデータを記憶することができる。取り外し不可能なメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、または任意のその他の種類のメモリストレージデバイスを含み得る。取り外し可能なメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。その他の実施形態において、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）などの、ＷＴＲＵ１０２に物理的に置かれていないメモリからの情報にアクセスし、そのメモリにデータを記憶することができる。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内のその他のコンポーネントに電力を分配し、および／またはその電力を制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に給電するための任意の好適なデバイスである可能性がある。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。

プロセッサ１１８は、ＧＰＳチップセット１３６にも結合される可能性があり、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えて、またはＧＰＳチップセット１３６からの情報の代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）から無線インターフェース１１５／１１６／１１７を介して位置情報を受信し、および／または２つ以上の近隣の基地局から受信されている信号のタイミングに基づいてそのＷＴＲＵ１０２の位置を判定することができる。ＷＴＲＵ１０２は、実施形態に準拠したまま、任意の好適な位置判定方法によって位置情報を取得することができることが理解されるであろう。

プロセッサ１１８は、その他の周辺機器１３８にさらに結合される可能性があり、その他の周辺機器１３８は、追加的な特徴、機能、および／または有線もしくは無線接続を提供する１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含み得る。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ（写真または動画用）、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（ｆｒｅｑｕｅｎｃｙ ｍｏｄｕｌａｔｅｄ）ラジオユニット、デジタル音楽プレーヤー、メディアプレーヤー、ビデオゲームプレーヤーモジュール、インターネットブラウザなどを含み得る。

図１Ｃは、一実施形態によるＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上述のように、ＲＡＮ１０３は、無線インターフェース１１５を介してＷＲＴＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＵＴＲＡ無線技術を使用する可能性がある。ＲＡＮ１０３は、コアネットワーク１０６とも通信している可能性がある。図１Ｃに示されるように、ＲＡＮ１０３はＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含む可能性があり、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、無線インターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバをそれぞれが含み得る。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、ＲＡＮ１０３内の特定のセル（図示せず）にそれぞれが関連付けられ得る。ＲＡＮ１０３は、ＲＮＣ１４２ａ、１４２ｂも含み得る。ＲＡＮ１０３は、実施形態に準拠したまま、任意の数のＮｏｄｅ−ＢおよびＲＮＣを含み得ることが理解されるであろう。

図１Ｃに示されるように、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信している可能性がある。加えて、Ｎｏｄｅ−Ｂ１４０ｃは、ＲＮＣ１４２ｂと通信している可能性がある。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信することができる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して互いに通信している可能性がある。ＲＮＣ１４２ａ、１４２ｂのそれぞれは、そのＲＮＣが接続されているそれぞれのＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを制御するように構成され得る。さらに、ＲＮＣ１４２ａ、１４２ｂのそれぞれは、アウターループ電力制御、負荷制御、アドミッション制御、パケットのスケジューリング、ハンドオーバー制御、マクロダイバーシティ（ｍａｃｒｏｄｉｖｅｒｓｉｔｙ）、セキュリティ機能、データの暗号化などのその他の機能を実行またはサポートするように構成され得る。

図１Ｃに示されるコアネットワーク１０６は、ＭＧＷ（ｍｅｄｉａ ｇａｔｅｗａｙ）１４４、ＭＳＣ（ｍｏｂｉｌｅ ｓｗｉｔｃｈｉｎｇ ｃｅｎｔｅｒ）１４６、ＳＧＳＮ（ｓｅｒｖｉｎｇ ＧＰＲＳ ｓｕｐｐｏｒｔ ｎｏｄｅ）１４８、および／またはＧＧＳＮ（ｇａｔｅｗａｙ ＧＰＲＳ ｓｕｐｐｏｒｔ ｎｏｄｅ）１５０を含み得る。上述の要素のそれぞれはコアネットワーク１０６の一部として示されているが、これらの要素のうちの任意の要素は、コアネットワークの運用者以外の主体によって所有および／または運用される可能性があることが理解されるであろう。

ＲＡＮ１０３のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６のＭＳＣ１４６に接続され得る。ＭＳＣ１４６は、ＭＧＷ１４４に接続され得る。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがＰＳＴＮ１０８などの回線交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線通信デバイスとの間の通信を容易にすることができる。

ＲＡＮ１０３のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介してコアネットワーク１０６のＳＧＳＮ１４８にも接続され得る。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続され得る。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがインターネット１１０などのパケット交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。

上述のように、コアネットワーク１０６は、その他のサービスプロバイダによって所有および／または運用されるその他の有線または無線ネットワークを含み得るネットワーク１１２にも接続され得る。

図１Ｄは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上述のように、ＲＡＮ１０４は、無線インターフェース１１６を介してＷＲＴＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を使用する可能性がある。ＲＡＮ１０４は、コアネットワーク１０７とも通信している可能性がある。

ＲＡＮ１０４はｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃを含む可能性があるが、ＲＡＮ１０４は、実施形態に準拠したまま、任意の数のｅＮｏｄｅ−Ｂを含み得ることが理解されるであろう。ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、無線インターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバをそれぞれが含み得る。一実施形態において、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装することができる。したがって、ｅＮｏｄｅ−Ｂ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。

ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれは、特定のセル（図示せず）に関連付けられる可能性があり、無線リソース管理の決定、ハンドオーバーの決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成され得る。図１Ｄに示されるように、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いに通信することができる。

図１Ｄに示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｇａｔｅｗａｙ）（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含み得る。上述の要素のそれぞれはコアネットワーク１０７の一部として示されているが、これらの要素のうちの任意の要素は、コアネットワークの運用者以外の主体によって所有および／または運用される可能性があることが理解されるであろう。

ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続される可能性があり、制御ノードとして働くことができる。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初のアタッチ中の特定のサービングゲートウェイの選択などの役割を担う可能性がある。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭ（登録商標）またはＷＣＤＭＡ（登録商標）などのその他の無線技術を使用するその他のＲＡＮ（図示せず）との間の切り替えのための制御プレーンの機能も提供することができる。

サービングゲートウェイ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続され得る。概して、サービングゲートウェイ１６４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／からユーザのデータパケットをルーティングおよび転送することができる。サービングゲートウェイ１６４は、ｅＮｏｄｅＢ間のハンドオーバー中にユーザプレーンのアンカーになること、ダウンリンクのデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能であるときにページングを引き起こすこと、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどのその他の機能も実行することができる。

サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６にも接続される可能性があり、ＰＤＮゲートウェイ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがインターネット１１０などのパケット交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスの間の通信を容易にすることができる。

コアネットワーク１０７は、その他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがＰＳＴＮ１０８などの回線交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線通信デバイスとの間の通信を容易にすることができる。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８の間のインターフェースとして働くＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができるか、またはそのようなＩＰゲートウェイと通信することができる。さらに、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、その他のサービスプロバイダによって所有および／または運用されるその他の有線または無線ネットワークを含み得るネットワーク１１２にアクセスできるようにすることができる。

図１Ｅは、一実施形態によるＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を使用して無線インターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するＡＳＮ（ａｃｃｅｓｓ ｓｅｒｖｉｃｅ ｎｅｔｗｏｒｋ）である可能性がある。以下でさらに検討されるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９の異なる機能エンティティ間の通信リンクは、リファレンスポイント（ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）として定義され得る。

図１Ｅに示されたように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃ、およびＡＳＮゲートウェイ１８２を含む可能性があるが、ＲＡＮ１０５は、実施形態に準拠したまま任意の数の基地局およびＡＳＮゲートウェイを含み得ることが理解されるであろう。基地局１８０ａ、１８０ｂ、１８０ｃは、ＲＡＮ１０５の特定のセル（図示せず）にそれぞれ関連付けられる可能性があり、無線インターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバをそれぞれが含み得る。一実施形態において、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装することができる。したがって、基地局１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。基地局１８０ａ、１８０ｂ、１８０ｃは、ハンドオフのトリガ、トンネルの確立、無線リソース管理、トラフィックの分類、サービス品質（ＱｏＳ）ポリシーの施行などのモビリティ管理機能を提供することもできる。ＡＳＮゲートウェイ１８２は、トラフィックの集約点として働くことができ、ページング、加入者プロファイルのキャッシュ、コアネットワーク１０９へのルーティングなどを担うことができる。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５の間の無線インターフェース１１７は、ＩＥＥＥ８０２．１６の仕様を実装するＲ１リファレンスポイントとして定義され得る。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれは、コアネットワーク１０９との論理インターフェース（図示せず）を確立することができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インターフェースは、認証、認可、ＩＰホストの構成管理、および／またはモビリティ管理のために使用され得るＲ２リファレンスポイントとして定義され得る。

基地局１８０ａ、１８０ｂ、１８０ｃのそれぞれの間の通信リンクは、ＷＴＲＵのハンドオーバー、および基地局間のデータの転送を容易にするためのプロトコルを含むＲ８リファレンスポイントとして定義され得る。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６リファレンスポイントとして定義され得る。Ｒ６リファレンスポイントは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれに関連するモビリティイベント（ｍｏｂｉｌｉｔｙ ｅｖｅｎｔ）に基づいてモビリティ管理を容易にするためのプロトコルを含み得る。

図１Ｅに示されたように、ＲＡＮ１０５は、コアネットワーク１０９に接続され得る。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、例えばデータ転送およびモビリティ管理能力を助けるためのプロトコルを含むＲ３リファレンスポイントとして定義され得る。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４、認証、認可、アカウンティング（ＡＡＡ）サーバ１８６、およびゲートウェイ１８８を含み得る。上述の要素のそれぞれはコアネットワーク１０９の一部として示されているが、これらの要素のうちの任意の要素は、コアネットワークの運用者以外の主体によって所有および／または運用される可能性があることが理解されるであろう。

ＭＩＰ−ＨＡは、ＩＰアドレスの管理を担うことができ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが異なるＡＳＮおよび／または異なるコアネットワークの間をローミングすることを可能にすることができる。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがインターネット１１０などのパケット交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。ＡＡＡサーバ１８６は、ユーザの認証およびユーザサービスのサポートを担うことができる。ゲートウェイ１８８は、その他のネットワークとの網間接続を容易にすることができる。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがＰＳＴＮ１０８などの回線交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線通信デバイスとの間の通信を容易にすることができる。さらに、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、その他のサービスプロバイダによって所有および／または運用されるその他の有線または無線ネットワークを含み得るネットワーク１１２にアクセスできるようにすることができる。

図１Ｅには示されていないが、ＲＡＮ１０５は、その他のＡＳＮに接続される可能性があり、コアネットワーク１０９は、その他のコアネットワークに接続される可能性があることが理解されるであろう。ＲＡＮ１０５とその他のＡＳＮとの間の通信リンクは、ＲＡＮ１０５とその他のＡＳＮとの間でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含み得るＲ４リファレンスポイントとして定義され得る。コアネットワーク１０９とその他のコアネットワークの間との通信リンクは、ホームコアネットワークと滞在先のコアネットワークとの間の網間接続を容易にするためのプロトコルを含み得るＲ５リファレンスとして定義され得る。

多接続とは、２つ以上のネットワーク接続を同時に維持するユーザ機器（ＵＥ）を指す可能性がある。異なる種類のネットワーク接続は、広帯域幅、低時間遅延、および高セキュリティなどの異なるユーザエクスペリエンスをユーザに提供する可能性がある。多接続は、異なる場所および時間からネットワークにアクセスするためにアクセス技術を連携させ、複数のアクセス技術の異なる利点を生かし、より良いユーザエクスペリエンスを提供するのに役立つことができる。

「接続」は、例えば、２つ以上のピア（Ｎ）エンティティ（ｐｅｅｒ−（Ｎ）−ｅｎｔｉｔｙ）間のデータの転送のために確立される関連付けである可能性がある。関連付けは、ピア（Ｎ）エンティティを直下のレイヤの（Ｎ−１）エンティティ（（Ｎ−１）−ｅｎｔｉｔｙ）と一緒にバインドする可能性がある。

「セッション」は、例えば、テキスト形式の情報をリアルタイムで交換することを目的とする２つ以上のユーザ端末間の論理的な接続である可能性がある。

所与のインターフェースにおける「ＩＰフロー」は、所与の分類に当てはまるＩＰパケットの組がそのインターフェースに現れることとして定義される可能性がある。ＩＰフローは、単一のアプリケーションのセッションからのパケットを含む可能性がある。ＩＰフローは、いくつかのアプリケーションのセッションからの組み合わされたトラフィックを含む集まりである可能性がある。分類が（別々のまたは重なり合う）異なる下位分類に細分化されるとき、異なるＩＰサブフローが、対応するＩＰフローにおいて認識され得る。

「アプリケーション」は、ＡＰＩインターフェースによってサポート可能な１つまたは複数のサービスによってサポートされ得る付加価値の付いた機能を提供する構造化された１組の能力である可能性がある。

「多接続」は、例えば、同時に受信および／または送信する２つ以上のピア（Ｎ）エンティティ間のいくつかの接続の集合である可能性がある。接続は、上位レイヤのエンティティにサービスを提供するために調整され得る。多接続通信においては、少なくとも１つのＵＥが、多接続のＵＥであるように要求される可能性がある。

「サービスの分解（ｓｅｒｖｉｃｅ ｄｅｃｏｍｐｏｓｉｔｉｏｎ）」は、１つのサービスをいくつかのサービスコンポーネント（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ）に分解することである可能性がある。元のサービスのロジックが、エンドユーザおよびアプリケーションに対して透過的に再構築され得る。

「メディアフロー（ｍｅｄｉａ ｆｌｏｗ）」は、送信者から関心のある受信者に送信されているメディアのストリームである可能性がある。

多接続の能力は、多くの場合、例えば、ネットワークの負荷を分散すること、加入者により広い帯域幅を提供すること、サービスへの異なる利用可能な同時アクセスを利用することによってより適正にサービスに課金すること、同時に２つ以上のネットワークを訪れるときにユーザをサポートすることなどのために加入者によって必要とされる可能性がある。テレビ会議を例として用いると、音声が、回線交換ネットワークによるリアルタイムのサービスを確約するために２Ｇ／３Ｇネットワークによって送信され得る一方、映像コンポーネントは、より大きな帯域幅を有するＷｉ−Ｆｉによって送信され得る。

多接続ネットワークにおいて、ＵＥおよびネットワークは、アプリケーションに提供されるいくつかの同時アクセスによって生じるインタラクションと、それぞれに関する関連するＱｏＳとを知っている可能性がある。組み合わせのまたは結果として得られるＱｏＳは、特定のサービスに関連する各ＱｏＳの組み合わせを表す可能性がある。

ＱｏＳを指定することは、優先度によるアプローチを用いて実施され得る。アプリケーションは、そのアプリケーションが必要とするデータレートまたはレイテンシを知らない可能性があるが、アプリケーションは、そのアプリケーションにとってどれがより重要であるか（例えば、どれがより高い優先度を有するか）をおそらく知っている可能性がある。アプリケーションがそのアプリケーションが必要とするサービス品質について偽りがない（例えば、最大のレート未満のレートまたは最小のレイテンシを超えるレイテンシを要求しようとする）ことへの誘因はほとんどない可能性があるが、そのアプリケーションがどれがより高い優先度を有すると見なすかをアプリケーションが示そうとする誘因は存在する可能性がある。偽りがあるアプリケーション（例えば、そのアプリケーションがデータレートを重視するよりもレイテンシを重視するということをその反対が正しいときに示すアプリケーション）は、（例えば、多接続プロトコルが使用されるとき）プロトコルから質の低いサービスを受ける危険を冒す可能性がある。

追加的なパラメータが利用される可能性があるが、一例において、２つのパラメータ、データレートおよびレイテンシを有するＱｏＳ空間（ＱｏＳ ｓｐａｃｅ）を考える。多接続エンドツーエンドプロトコルは、そのプロトコルに２つの接続を用意している可能性があり、そのプロトコルのアプリケーションインターフェースの一部として、どちらのパラメータ−データレートまたはレイテンシ−がアプリケーションにとってより高い優先度を有するかを示す（例えば、優先されるリソースを示す）ようにアプリケーションに要求する可能性がある。

例示的な多接続プロトコルは、以下のように動作し得る。アプリケーションからの各データパケットに関して、プロトコルは、どの接続を介してデータパケットを送信すべきかを決定する可能性がある。例えば、プロトコルは、接続１、接続２、またはそれらの両方を介してデータパケットを送信する可能性がある。パケットが両方の接続を介して送信される場合、２つの接続のうちのいずれか一方を介した肯定応答（ＡＣＫ）があれば、パケットが届けられたと見なすのに十分である可能性がある。アプリケーションからデータを受信すると、多接続プロトコルは、そのデータをどこに送信すべきかを決定する可能性がある。アプリケーションがそのアプリケーションがレイテンシよりもデータレートをより重視することを示した場合、プロトコルは、異なるデータを接続２を介して送信しながら、一部のデータを接続１を介して送信する可能性がある。達成される結果として得られるスループットのレートは、両方の接続を介して利用可能なレートの合計である可能性がある。アプリケーションがデータレートよりもレイテンシをより重視する場合、ポリシーが、両方の接続を介して重複するデータを送信する可能性がある。各パケットに関するレイテンシは、各接続におけるそのパケットに関するレイテンシのうちで最小のレイテンシである可能性がある（例えば、レイテンシが最小化される）。そのようなアプローチは、スループットが２つの接続を介したスループットのうちの最小のスループットとなり得るという犠牲を招く可能性がある。

上記の例のように、データレートおよびレイテンシは、潜在的に対立するＱｏＳの基準である可能性がある。偽りがある振る舞いはアプリケーションにとって不利益がある可能性があるので、アプリケーションがどちらのパラメータをより重視するかを示すようにアプリケーションに強制することによって、多接続プロトコルは、偽りがないようにアプリケーションに強制する可能性がある。ＱｏＳインターフェース（ＱｏＳ ｉｎｔｅｒｆａｃｅ）を介して提供される情報が、多接続プロトコルによって利用できる可能性がある（例えば、その情報は、送信パラメータをどのように優先順位付けするべきかに関する情報を多接続プロトコルに与える可能性がある）。

ＱｏＳは、多くのパラメータを含み得る。例えば、ＱｏＳは、以下、すなわち、データレート／スループット、レイテンシ、ジッタ、送達の保証（Ｄｅｌｉｖｅｒｙ Ｇｕａｒａｎｔｅｅ）、コスト、電力消費、または（例えば、プライバシー、完全性、送達の確約（Ｄｅｌｉｖｅｒｙ Ａｓｓｕｒａｎｃｅ）などにさらに分けられる可能性がある）セキュリティのうちの１つまたは複数を含み得る。

アプリケーション以外のその他のアクターが、通信エコシステム（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｅｃｏｓｙｓｔｅｍ）において利害関係を有する可能性がある。例えば、オペレーティングシステム（ＯＳ）は、電力消費の制約についてアプリケーションよりも大きな影響力を持つ可能性があり、リンクのコストの重要性（ｌｉｎｋ ｃｏｓｔ ｉｍｐｏｒｔａｎｃｅ）は、オペレータおよび／またはユーザのニーズによって左右される可能性がある、等々である。図２は、多数のユースケースでＱｏＳ選択手順に影響を与える可能性がある例示的なアクターを示す図である。図２は、ＱｏＳサブシステムが含み得るさまざまなコンポーネントの高レベルの図を含む。

優先度によるインターフェース（ｐｒｅｆｅｒｅｎｔｉａｌ ｉｎｔｅｒｆａｃｅ）は、アプリケーションとの１つまたは複数のインターフェースを含み得る。例として、アプリケーションとの単一のインターフェースを考える。インターフェースは、アプリケーションに露出される１組の利用可能なパラメータを含み得る。アプリケーションは、その組が何であるかを知らされる可能性がある。その組は、本明細書において開示されるパラメータのうちの１つまたは複数などの１つまたは複数のパラメータを含み得る。例として、｛コスト，レイテンシ，スループット，電力消費｝が、１組のＱｏＳパラメータである可能性がある。アプリケーションは、重要性の順序でパラメータをランク付けするように求められる可能性がある。例えば、最大限可能なスループットを必要とし、レイテンシはそれよりも重視せず、コストはそれよりもさらに重視せず、電力消費は最も重視しないアプリケーションは、以下の順序付けられた組、すなわち、｛スループット，レイテンシ，コスト，電力消費｝を接続プロトコルに与える可能性がある。

アプリケーションは、パラメータの一部をどうすればよいか分からない可能性がある。例えば、ラップトップで実行されるアプリケーションが、電源の制約または無線接続の性質を知らない可能性がある。この例において、アプリケーションは、電力消費またはコストについてどうすればよいか分からない可能性がある。

インターフェースのコンポーネントが、定義され得る。例は、順序付けられたプリファレンスリスト（ｏｒｄｅｒｅｄ ｐｒｅｆｅｒｅｎｃｅ ｌｉｓｔ）（ＯＰＬ）および（例えば、アプリケーションがランク付けすることができないパラメータに関する）「情報なしリスト（ｎｏ ｉｎｆｏｒｍａｔｉｏｎ ｌｉｓｔ）」（ＮＩＬ）を含み得る。例を続けると、アプリケーションは、ＯＰＬ＝｛スループット，レイテンシ｝およびＮＩＬ＝｛コスト，電力消費｝を与える可能性がある。ＮＩＬリストは、例えば、ＯＰＬにないパラメータはＮＩＬにあるものと設計が仮定する場合は、明示的ではなく暗黙的である可能性がある。

プリファレンスは、多接続プロトコルによって提供され得る定量的な性能に依存する可能性がある。例えば、アプリケーションは、最小限のレイテンシの要件が満たされるものとして、レイテンシよりもスループットをより重視する可能性がある。この種類および同様の種類の動作をサポートするために、インターフェースは、フィードバックによって改良され得る。プロトコルは、ＯＰＬ内のパラメータに対する定量的な性能に関するアプリケーションのフィードバックを提供する可能性がある。アプリケーションは、いつでもＯＰＬおよびＮＩＬの設定を変更し、そのアプリケーションのデータがどのように処理されるかを調整することができる。

アプリケーションは、どのデータにどのＱｏＳが適用されるべきかを特定する必要がある可能性がある。例として、ウェブブラウザは、以下の種類のトラフィック、すなわち、ＨＴＴＰセッションネゴシエーション、「通常の」ウェブページデータ、（それ自体がさまざまなレイヤを有する可能性がある）埋め込まれたオーディオおよびビデオストリーム、セキュアコンポーネント（ｓｅｃｕｒｅ ｃｏｍｐｏｎｅｎｔ）などのうちの１つまたは複数を生成する可能性がある。アプリケーション（例えば、進化型のウェブブラウザ）は、そのようなデータを分け（または接続プロトコルによって理解され得る方法でそのデータをラベル付けし）、そのデータのサブフローのそれぞれに関してＱｏＳインターフェースを設定する可能性がある。これは、既存のインターフェースの構成を発展させることを必要とする可能性がある。例えば、既存のＬ４プロトコル（ＴＣＰ、ＵＤＰ）とのインターフェースは、「ポート」の概念を用いる可能性がある。アプリケーションは、Ｌ４プロトコルを用いてポートを開くことができ、Ｌ４プロトコルは、ポートの概念を用いて異なるアプリケーションからのデータを分けることができる。アプリケーションは、複数のポートを開くことができる。コネクション型プロトコル、例えば、ＴＣＰは、単一のポートのデータを同期させておく−多くのサブフローにとって望ましい可能性がある特徴−ために使用され得る。異なるポートを使用することによって、この能力は失われる可能性がある。

ポートの概念は、アプリケーションを一意に特定するのに役立つ可能性がある。例えば、現在は、３つ組み＜Ｌ４プロトコル（概してＴＣＰ／ＵＤＰ），ポート番号，送信先ＩＰ＞［さらに送信元ＩＰ］が、アプリケーションを一意に特定するために使用される可能性がある。異なるアプリケーションが、同じポートを用いて異なる送信先と通信する可能性がある。同じポート番号が、同じ送信先の異なるプロトコル（例えば、ＵＤＰまたはＴＣＰ）に対して使用される可能性がある。同じ＜Ｌ４プロトコル，ポート番号，送信先ＩＰ＞の使用は明確に禁じられていない可能性があるが、そのような使用は、（ＴＣＰ／ＩＰプロトコルスタックを実装し得る）オペレーティングシステムがアプリケーションによってデータを特定することを難しくする可能性があるので避けられる可能性がある。

上述の内容に対する変更がなされる可能性がある。異なるサブフローが、それらのサブフローを異なる送信元ＩＰアドレスにバインドすることによって異なるインターフェースにマッピングされ得るので、送信元ＩＰが、フロー（またはサブフロー）の識別子の極めて重要な部分になる可能性がある。フローＩＤの概念が、必要とされる可能性がある。ポートの概念は、サブポートの概念を含み得る。各サブポートが、アプリケーションのサブフローに関連付けられる可能性があり、異なるＱｏＳの設定が、各サブフローに対して定義される可能性がある。

別の例として、ＩＰプロトコルが「アプリケーション」の役割をするＬ２接続プロトコルを考える。この場合、ＩＰプロトコルスタックが、異なるＱｏＳのニーズを異なるデータグラムに関連付けることができる（例えば、この情報が、独自の方法でスタック中を伝播させられる可能性がある）と想定され得る。例えば、８０２．１１ｅの拡張を経た８０２．１１などの一部のＭＡＣレイヤは、各キューに異なるＱｏＳが関連付けられた異なるキューにデータを入れることを提供する可能性がある。そのとき、ＱｏＳインターフェースを介して提供される情報は、各データグラムがどのキューに入れられるべきかを判定するためにＭＡＣプロトコルによって使用され得る。

複数のアクターとのインターフェースが、提供される可能性がある（例えば、アプリケーション、オペレーティングシステム（ＯＳ）、ユーザ、オペレータ）。接続／ポートは、例えば（発展型の）ソケット呼び出しを介してアプリケーションにより開かれる可能性がある。これは、アプリケーションが、例えば、ＯＰＬ／ＮＩＬによってかまたは別の実装によってかのどちらかでＱｏＳを指定することを可能にすることができる。ポートを開けるプロセスは、その他のアクターがそれらのアクターの入力を与えるための直接的な手段を提供しない可能性がある。これは、例えば、これらのアクターがポートごとの入力を与えたいのか、または入力が与えられて以降に開けられたすべてのポートに、その入力が有効である限り適用され得るグローバルな入力を与えたいのかに応じて実現され得る。

アプリケーションでないアクターによるグローバルなＱｏＳのプロビジョニングの場合、アクター（例えば、ＯＳ、ユーザ、オペレータ）は、ＱｏＳ管理エンティティに、そのアクターが関心のあるパラメータに関する情報を与える可能性がある。情報は、アプリケーションによって与えられるのと同様の形態（例えば、ＯＰＬ／ＮＩＬ）で与えられる可能性がある。内容は、異なる可能性がある。情報は、いかなる特定のポートにも関連付けられない可能性があり、ソケットが開かれるときに与えられない可能性がある。情報は、いつでも与えられ得る。

この情報が与えられる方法は、アクターによって異なる可能性がある。例は、以下のうちの１つまたは複数を含み得る。オペレーティングシステム（ＯＳ）の情報は、ＱｏＳエージェントおよびＯＳからＡＰＩを介して与えられる可能性がある。そのＡＰＩは、そのＡＰＩがソケット呼び出しを含まない可能性があるので、アプリケーションＡＰＩとは異なる可能性がある。ユーザの情報は、ユーザインターフェースを介して与えられる可能性がある。オペレータの情報は、オペレータのポリシーを通じてデバイスに与えられる可能性があり、次に、デバイス管理エンティティ（例えば、ＯＭＡ ＤＭエンティティ）が、そのオペレータのポリシーを、ＱｏＳエージェントがデバイス管理エンティティに提供するＡＰＩを介してそのＱｏＳエージェントに渡す可能性がある。

アプリケーションごとのプロビジョニングは、ポートを開けること（例えば、ソケット呼び出し）に結びつけられ得る。アプリケーションでないアクターは、ソケットが開かれていることが直接分からない可能性がある。そのようなアクターによるアプリケーションごとのプロビジョニングが可能にされる場合、ＱｏＳエージェントが、アクターが情報を与えることをトリガする必要がある可能性がある。トリガは、ポーリング呼び出しによって実現される可能性があり−例えば、各アクターとのＡＰＩが、ＱｏＳエージェントがそのような情報に関してアクターにポーリングするための能力を含む可能性がある。例えば、ＱｏＳエージェントは、特定のアプリケーションがポートを開くことを要求するときに、そのアプリケーションに関するＯＳの電力のプリファレンスについてＯＳにポーリングする可能性がある。

ユーザおよびオペレータの入力の場合、ポーリングプロセスは、追加的な動作を含み得る。ユーザに関して、ポーリングプロセスは、特定のデータを入力するようにユーザに要求するユーザインターフェースの動作（例えば、アプリケーションがインターネットアクセスを許されるべきか、または許されるべきでないかをユーザに尋ねるのと同様のプロセス）を開始する必要がある可能性がある。

オペレータの場合、デバイス管理エンティティが、そのような情報に関してポーリングされる可能性がある。ローカルに記憶されたポリシー内でその情報が利用可能でない場合、デバイス管理エンティティは、その情報を得るためにオペレータと通信する必要がある可能性がある。

優先度によるＱｏＳの指定のためのアプローチは、それぞれのＱｏＳのカテゴリーに関する記述的なプロパティ（ｄｅｓｃｒｉｐｔｉｖｅ ｐｒｏｐｅｒｔｙ）を使用する可能性がある。これは、それぞれのプロパティに関するそれぞれの値が直交する（ｏｒｔｈｏｇｏｎａｌ）（例えば、アプリケーションまたはアプリケーションでないアクターが偽りがないままでいる必要がある可能性がある）方法で実装され得る。例えば、１つのＱｏＳのプロパティはスループットである可能性があり、そのプロパティは、例えば、表１に示されるように３つの値を用いて指定される可能性がある。

電力のプロパティが、表２に示されるように指定される可能性がある。

レイテンシのプロパティが、表３に示されるように指定される可能性がある。

その他のプロパティが、同様にして指定される可能性がある。

図３は、ＱｏＳサブシステムの例示的なアーキテクチャを示す。図３は、アプリケーションと接続プロトコルとの間のアーキテクチャを含む。図３は、システム全体の中にＱｏＳのＡＰＩおよびエージェントを含む。図３に示されるように、ＱｏＳサブシステムは、以下のうちの１つまたは複数を含み得る。ＱｏＳサブシステムは、デバイスに知られている可能性がある無線アクセス技術（ＲＡＴ）のリストおよびそれらのＲＡＴの特性を記憶することができる無線アクセス技術（ＲＡＴ）のデータベースを含み得る。ＱｏＳサブシステムは、ＱｏＳのニーズおよびそれらのニーズがどのようにして満たされ得るかの分析を実行することができるＱｏＳ分析モジュールを含み得る。ＱｏＳのＡＰＩおよびＱｏＳスニファによって与えられる入力に加えて、ＱｏＳ分析モジュールは、アクティブな接続、アクティブ化され得る接続についての情報、無線環境とネットワークの両方からのセンシング情報、およびその他の潜在的な入力などを含むその他の入力を取得する可能性がある。各接続に関するＱｏＳパラメータについての決定が、ＱｏＳ分析モジュールによってなされ得る。ＱｏＳサブシステムは、ＱｏＳ分析モジュールの意思決定を制御する１組の規則およびリソース割り当て／帯域幅プロセッサモデル（Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ／Ｂａｎｄｗｉｄｔｈ Ｐｒｏｃｅｓｓｏｒ ｍｏｄｅｌ）を含み得るポリシーデータベースを含む可能性がある。ポリシーは、デバイスに組み込まれ、プライマリネットワークの動作、ユーザ、ＯＳなどによって提供される可能性がある。ＱｏＳサブシステムは、エラーイベントに反応することができるアラームプロセッサを含み得る。ＱｏＳサブシステムは、特定のアプリケーションから受信されたパケットを、正常な状態でＱｏＳ分析モジュールによって指示され、エラー状態の間にアラームプロセッサによって指示される接続に配信することができるリソース割り当て／帯域幅管理アルゴリズムを含み得る。

ＱｏＳスニファ機能（ＱＳＦ）は、ＱｏＳインターフェースを、アプリケーション、例えば、これを自身で行うことができない可能性があるアプリケーションの代わりに実行することができる。そのようにするために、ＱＳＦは、どの種類のアプリケーションからデータストリームが来ているのか、およびどのＱｏＳをそのアプリケーションが必要とするかまたはおそらく必要とする可能性があるのかを判定する必要がある可能性がある。これは、以下を含み得る。ＱＳＦは、アプリケーションが送信しているデータに基づいてアプリケーションの種類を推測することを試みる可能性がある。これは、ディープパケットインスペクション（ＤＰＩ）を用いて、例えば、ＤＰＩアルゴリズムによって実現され得る。ＤＰＩアルゴリズムは、使用されているトランスポートプロトコル（ＴＣＰまたはＵＤＰ）のポート、アプリケーションプロトコルのヘッダ、およびその他の情報などの情報に関してデータを検査することができる。これは、ＱＳＦが、使用されているアプリケーションプロトコル（例えば、ＦＴＰ、ＨＴＴＰ、ＲＴＳＰなど）の性質を判定することを可能にすることができる。アプリケーションの種類は、使用されているポートから推測され得る（例えば、ウェブブラウザのセッションは、通常、ＴＣＰポート８０およびＨＴＴＰプロトコルを用いて開始され得る）。ＤＰＩアルゴリズムは、それぞれのアプリケーションのフローのサブフローを分析して、異なるＱｏＳを必要とする可能性がある異なる種類のサブフローをさらに特定することができる。例えば、現在のＨＴＴＰのフローは、とりわけ、ウェブページデータ、ビデオストリーム、およびセキュアコンポーネントを含み得る。これらのそれぞれは、異なるＱｏＳの扱いを必要とする可能性がある。ＤＰＩの実施は、ＨＴＴＰのウェブブラウザのセッション内のこれらのサブフローのそれぞれに関する情報を運ぶデータパケットを特定することができる可能性がある。

ＤＰＩは、それぞれのアプリケーション／データのサブフローを特定するために使用され得る。ＱＳＦは、この情報を用いて、サブフローの種類に基づいてＱｏＳインターフェースを設定することができる。例えば、データのサブフローは、ピークスループットを最も重視すると想定される可能性があり、一方、インタラクティブな（例えば、ＶｏＩＰの）サブフローは、レイテンシをより重視すると想定される可能性があり、ｈｔｔｐｓのサブフローは、セキュリティを最も重視すると想定される可能性がある。サブフローは、ＱＳＦによって分けられる可能性があり、ＱｏＳインターフェースは、それらのサブフローのそれぞれに対して設定される可能性がある。レガシーのアプリケーションに代わるＱＳＦによるＱｏＳの設定は、本明細書において説明されるように実行され得る。

ＱｏＳインターフェースに関連して、ＱＳＦは、アプリケーションがＮＩＬの組に設定したＱｏＳのプロパティに関する優先度を設定するために使用され得る。例えば、ＱＳＦは、それぞれの特定のアプリケーションが知らないデバイスの電力要件を知っている可能性がある。アプリケーションは、「電力」をＮＩＬの組に入れるが、ＱＳＦは、「電力」を適切な優先度でＯＰＬに入れることによってこの設定を修正する可能性がある。

ＱＳＦのための情報のソースは、デバイスのオペレーティングシステムである可能性がある。例えば、ＯＳは、アプリケーションが知らない電力またはセキュリティの要件を知っている可能性がある。ＱＳＦのための情報のソースは、（例えば、本明細書において開示されるような）ユーザおよびオペレータの入力である可能性がある。コスト、電力、およびセキュリティの設定は、例えば、接続マネージャアプリケーションを通じてユーザによって入力され得る例である。

ＱＳＦが提供し得る機能は、アプリケーションのニーズを発見するネゴシエータの機能である。この特徴は、本明細書において説明される優先度によるインターフェースに定量的なＱｏＳの要素を加えるために使用され得る。例えば、アプリケーションが（例えば、定量的なアドオンのインターフェースを通じて）データレートに関して特定の値を要求するものとする。ＱＳＦ機能は、ＱｏＳインターフェースを介してその同じ値がレポートされることを可能にすることによって始まり、次いで、悪影響が観測されるまでその値を減らす（例えば、データレートを絞り込む）可能性がある。例えば、アプリケーションは、例えば図３に示されるようなその他の測定値をＡＰＩを介してシグナリングする可能性があり、またはアプリケーションは、ストレスコンディション（ｓｔｒｅｓｓ ｃｏｎｄｉｔｉｏｎ）、例えば、本明細書において説明される帯域幅の利用の監視によって発見される状態を示す可能性がある、等々である。場合によっては、アプリケーションの真のデータレートのニーズが、（１つまたは複数の）そのようなプロセスを用いて発見される可能性がある。より広くは、定量的なインターフェースのコンポーネントがＱｏＳインターフェースの一部として利用可能である場合、ＱＳＦは、特定のＱｏＳの観点（例えば、データレート、レイテンシなど）に関する真のニーズを（徐々に絞り込むかまたは広げることによって）インタラクティブに発見することをその後の潜在的な目的として、そのインターフェースのためにアプリケーション（またはＯＳ）の設定を傍受する可能性がある。そのようなアプローチは、例えば、把握される品質が、接続を維持することと引き替えに、利用可能な容量に基づいて犠牲にされる可能性がある、マルチレートオーディオまたはビデオコーデックと親和性がある可能性がある。

絞り込みのアプローチは、アプリケーションの真のニーズを知るのが遅い可能性があり、非常に動的な変化に対応することができない可能性があり、および／または変動するデータレートを許容しない可能性がある一部のアプリケーションに関して問題を引き起こす可能性がある。アプリケーションと両立できる制御された（例えば、低速な）方法でデータレートを絞って調節することによってこれを緩和できる可能性があるが、これは、有効性を損なう可能性がある。帯域幅ステアリング（ｂａｎｄｗｉｄｔｈ ｓｔｅｅｒｉｎｇ）が、使用される可能性がある。

帯域幅ステアリングは、以下のように使用される可能性がある。帯域幅の利用は、利用可能な帯域幅が利用されていることを判定するために監視される可能性がある。これは、例えば、物理レイヤの測定、ＭＡＣキューの観測（例えば、キューのサイズおよびキュー内のパケットの滞留時間）、（例えば、ＴＣＰの輻輳制御アルゴリズムにおける）ネットワーク遅延の観測などを通じて行われ得る。デバイスが、帯域幅が不足するようになったことを検出する（またはそのデバイスの総データ出力を削減するようにネットワークオペレータによって指示される）場合、そのデバイスは、以下のように動作する可能性がある。それぞれの既存のストリームに関して、「ストリームのモメンタム（ｓｔｒｅａｍ ｍｏｍｅｎｔｕｍ）」が保存され得る。これは、現在実行されているアプリケーションが、何らかの最大値までの、そのアプリケーションが実際に使用している帯域幅を維持することを許される可能性があることを意味する。例えば、ビデオアプリケーションが４Ｍｂｐｓを使用している場合、そのビデオアプリケーションは、（例えば、４Ｍｂｐｓが最大値未満であると仮定して）４Ｍｂｐｓのトラフィックを提供し続ける限り、そのような使用を継続することを許される可能性がある。残りの帯域幅は、ＱｏＳ分析モジュールによって確立された優先度にしたがって新しいアプリケーションに割り当てられ得る。

アプリケーションが帯域幅の使用を止める場合、そのアプリケーションは、そのアプリケーションの「ストリームのモメンタム」を失う可能性があり、そのアプリケーションが使用していた帯域幅が、利用可能なプールに戻る可能性がある。そのアプリケーションは、すべてのその他のアプリケーションとともにその帯域幅をめぐる競争者になる可能性がある。接続をサポートするために、非ゼロの最小のレートが、アプリケーションに保証される可能性がある。プロセスは、緊急であるとされたアプリケーション（例えば、健康、安全など）のために割り込まれる可能性がある。これは、一部の帯域幅を取っておくこと、または割り当てられた帯域幅のわずかな部分が回収されることを可能にすることを必要とする（例えば、４Ｍｂｐｓを３．７５Ｍｂｐｓに減らす）可能性がある。

ＱｏＳの要件に基づく帯域幅ステアリングは、帯域幅を使用しているアプリケーションがその使用を維持することを可能にする可能性がある（例えば、先着順サービスポリシー（ｆｉｒｓｔ−ｃｏｍｅ，ｆｉｒｓｔ ｓｅｒｖｅｄ ｐｏｌｉｃｙ）と同じようにして実施される可能性がある）。ポリシーは、利用可能な十分な帯域幅がない状況を考慮する（例えば、そのような状況のための規則の組を有する）必要がある可能性がある。例えば、そのようなポリシーは、以下のうちの１つまたは複数を含み得る。新しいアプリケーションは、サービスを拒否される可能性がある。利用可能な帯域幅は、公平に分割され得る。例として（例えば、上述の例を用いると）、２つのストリームが、それぞれ２Ｍｂｐｓを与えられる可能性がある。これは、削減されたレートが一方または両方のストリームを維持するために十分ではないという危険を冒す可能性があり、絞り込みのアプローチと同様の方法で認識される可能性がある。目的は、サービスの中断を避けるためにエラーの状況を認識し、それに反応することである可能性がある。例えば、新しいストリームは、ゆっくりと絞りを緩められる可能性がある一方、既存のストリームは、絞りをきつくされる。本明細書において説明される特徴を組み合わせるその他のポリシーの例も、実装され得る。

サービス品質情報を決定するためのシステム、方法、および手法が、開示される。ユーザ機器（ＵＥ）などのデバイスが、ポリシーを受信することができる。ポリシーは、セッションに関するアプリケーションの特定に関連するインスペクションのレベルを示す可能性がある。デバイスは、セッションに関連する情報を受信することができる。例えば、情報は、アプリケーションが提供する情報、パケットデータ、オペレーティングシステムが提供する情報などを含み得る。デバイスは、ポリシーによって示されたレベルで、受信された情報のインスペクションを実行することができる。デバイスは、セッションに関連するアプリケーションを特定するためにインスペクションを実行することができる。

インスペクションの各レベルは、計算のインテンシティ（ｃｏｍｐｕｔａｔｉｏｎａｌ ｉｎｔｅｎｓｉｔｙ）の異なるレベルに関連付けられる可能性がある。例えば、アプリケーションが提供する情報（例えば、ソケット呼び出し、５つ組みのフローマーカーなど）のインスペクションに関するインスペクションのレベルは、パケットインスペクションに関するインスペクションのレベルよりも計算のインテンシティが少ない可能性がある。インスペクションのより低いレベルが、より計算のインテンシティが少ないインスペクションを示す可能性がある一方、インスペクションのより高いレベルは、より計算のインテンシティが多いインスペクションを示す可能性がある。セッションのフロー、サブフローなどに関するインスペクションのレベルは、デバイスのリソースの使用を削減するためにポリシーによってより低いレベルに設定される可能性がある。例えば、ポリシーは、セッションに関してアプリケーションが特定されたときに、インスペクションのより低いレベルがそのセッションに関する情報に当てはまる可能性があることを示し得る。さらに、例として、ポリシーは、アプリケーションが特定のポートに関連付けられ得ることを示す可能性がある（例えば、ポート２１を使用するアプリケーションは、ＦＴＰとタグ付けされる可能性がある）。そのような場合、ポリシーは、さらなるインスペクションが必要ないことを示す可能性がある。これは、以下で説明されるように、最上位レベルのインスペクションに関連する可能性がある。

ポリシーが、インスペクションのレベルがインスペクションの第１のレベルであることを示す可能性があり、受信された情報が、アプリケーションが提供する情報（例えば、ソケット呼び出し、５つ組みのフローマーカーなど）を含む可能性がある。インスペクションの第１のレベルは、インスペクションが、アプリケーションが提供する情報を検査することを含むことを示す可能性がある。デバイスは、セッションに関連するアプリケーションを特定するためにインスペクションを実行することができる。例えば、アプリケーションが提供する情報は、ソケット呼び出しを含む可能性があり、インスペクションの第１のレベルは、ソケット呼び出しに関連するポートを特定されたポートと比較することを含む可能性がある。特定されたポートは、ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ）によって特定されたポートなどの知られているポートである可能性がある。特定されたポートは、アプリケーションに関連付けられ得る。デバイスは、セッションに関連するアプリケーションを、特定されたポートに関連するアプリケーションとして特定することができる。

ポリシーが、インスペクションのレベルがインスペクションの第２のレベルであることを示す可能性があり、受信された情報が、パケットデータを含む可能性がある。インスペクションの第２のレベルは、インスペクションがパケットデータのパケットインスペクションを含むことを示す可能性がある。インスペクションの第２のレベルは、パケットインスペクションの深さを示す可能性がある。異なる深さは、異なる計算のインテンシティのインスペクションを示す可能性がある。例えば、深さは、最上位レベルのプロトコルを特定／確認すること、プロトコルによって開かれたセッションを特定／確認すること、アプリケーションのサブフローを特定／確認することなどのためにパケットインスペクションを実行することを示す可能性がある。デバイスは、示されたレベルおよび深さでインスペクションを実行し、インスペクションに基づいてセッションに関連するアプリケーションを特定することができる。

ポリシーは、インスペクションのレベルがインスペクションの第３のレベルであることを示す可能性がある。デバイスは、（例えば、ポリシーに基づいて）オペレーティングシステムに問い合わせを行う可能性がある。デバイスは、オペレーティングシステムが提供する情報を受信する可能性がある。受信された情報は、オペレーティングシステムが提供する情報を含む可能性がある。インスペクションの第３のレベルは、インスペクションが、オペレーティングシステムが提供する情報を検査することを含むことを示す可能性がある。デバイスは、そのインスペクションを実行し、インスペクションに基づいてセッションに関連するアプリケーションを特定することができる。

ポリシーは、デフォルトのインスペクションレベルを含み得る。例えば、デフォルトのインスペクションレベルは、未知のフローに（例えば、そのフローが未検証状態、検証済み状態などになるまで）適用される可能性がある。

ソケット（例えば、インターネットソケットまたはネットワークソケット）とは、インターネットなどのＩＰに基づくネットワーク中の双方向のプロセス間通信フローのエンドポイントを指す可能性がある。インターネットソケットという用語は、オペレーティングシステムによって提供され得るＴＣＰ／ＩＰプロトコルスタックのためのアプリケーションプログラミングインターフェース（ＡＰＩ）の名前として使用される可能性がある。インターネットソケットは、着信データパケットを、ローカルおよびリモートＩＰアドレスとポート番号との組み合わせに基づいて適切なアプリケーションのプロセスまたはスレッドに届けるためのメカニズムを提供することができる。ソケットは、オペレーティングシステムによって、通信するアプリケーションのプロセスまたはスレッドにマッピングされ得る。

ソケットのアドレスは、アプリケーションプログラムのプロセスにマッピングされ得るＩＰアドレスおよびポートの、単一の識別情報への組み合わせを含む可能性があり、これは、電話接続の一端が電話番号と特定の内線番号との組み合わせとなる方法と同様である可能性がある。（例えば、ウィンドウズ（登録商標）に基づく、Ｌｉｎｕｘ（登録商標）に基づく、ＵＮＩＸ（登録商標）に基づく）一部のソケットは、ＢｅｒｋｅｌｅｙまたはＢＳＤソケットなどのＡＰＩライブラリによって実装される可能性がある。

カーネルによって提供されるソケットＡＰＩは、ＢｅｒｋｅｌｅｙソケットＡＰＩに基づく可能性がある。表４の機能などの機能が、サポートされる可能性がある。ソケット関数呼び出しは、Ｌｉｎｕｘ（登録商標）に基づくＡＰＩで使用されるソケット関数呼び出しである可能性があることに留意されたい。

アプリケーションとは、例えば、ＩＳＯモジュールのＬ５以上で実行されるアプリケーションを指す可能性がある。アプリケーションは、ユーザによってそのユーザの端末上で見られるアプリケーションである可能性がある。例として、アプリケーションは、ウェブブラウザ、ＦＴＰアプリケーション、ＶｏＩＰクライアント、Ｓｋｙｐｅアプリケーションなどである可能性がある。アプリケーションは、アプリケーションＩＤ（ＡＩＤ）によって一意に特定され得る。アプリケーションに関連するＯＳのプロセスＩＤが、アプリケーションＩＤとして使用される可能性がある。

セッションとは、ソケットＡＰＩを通じてアプリケーションによって開けられたＬ４トランスポートソケットを指す可能性がある。例示的なソケットは、ＵＤＰ、ＴＣＰ、ＭＣＴＰ、ＭＮＴＰソケットなどを含み得る。セッションは、一意的なセッションＩＤによって一意に特定され得る。アプリケーションは、１つまたは複数のセッションを開く可能性がある。例えば、ＦＴＰアプリケーションは、２つのセッション−ＦＴＰ制御セッションおよび別個のＦＴＰデータセッション−を開く可能性がある。これらのセッションは、従属セッションと呼ばれる可能性がある。

サブフローとは、多接続の（Ｌ４）トランスポートレイヤの概念を指す可能性がある。ＭＣＴＰまたはＭＮＴＰの単一のセッションが、複数のサブフローを開く可能性がある。これらのサブフローは、それ自体としてはアプリケーションによって知られていない可能性があり、トランスポートレイヤによって処理される可能性がある。

サブストリームは、アプリケーションの概念である可能性がある。これは、同じアプリケーションによって生成されたビットを区別するための方法である可能性がある。例えば、音声コーデックが、クラスＡ、Ｂ、およびＣのサブストリームを生成する可能性がある。

図４は、セッション、サブフロー、およびサブストリームをサポートする例示的なシステムを示す。図４の例において、アプリケーション１は、２つの従属セッション、ＴＣＰおよびＭＣＴＰを有する。ＭＣＴＰのセッションは、２つのサブフローをサポートする。アプリケーション２は、１つのセッションおよび２つのサブフローを有し、アプリケーション２がＶｏＩＰアプリケーションであるとき、セッションで送信されるアプリケーションのデータストリームは、最終的に２つのサブフローに分割され得る（例えば、クラスＡおよびクラスＢのビットに関する）２つのサブストリームを含む。

端末（例えば、ＵＥ）の通信能力が高まっているので、標準的なソケットインターフェースによって提供されるサービスは、不十分である可能性がある。標準的なソケットインターフェースは、そのソケットインターフェースのサービスのプリファレンスを示すこと（例えば、サービス品質（ＱｏＳ）の情報をプロトコルスタックに渡すこと）ができない可能性がある。

ソケットインターフェースは、ＱｏＳ要求能力をアプリケーションに提供するように拡張され得る。例えば、ソケットインターフェースは、発展型の特徴を含むように拡張され得る。このアプローチは、そのような「発展型の」ソケットインターフェースを利用するように実際に設計されたアプリケーションに適合する可能性がある。既存の（例えば、レガシーの）アプリケーションに関しては、アプリケーションが行うソケット呼び出しおよびアプリケーションが送受信するデータからそのアプリケーションが何を必要としているかを推定する必要がある可能性がある。これは、ディープパケットインスペクション（ＤＰＩ）アルゴリズムを使用することによって実現され得る。そのようなプロトコルは、通常、計算のインテンシティが多い（例えば、そのようなプロトコルは、電力消費および／またはスタックのスループットに影響を与える）。

ＤＰＩを使用せずに所望のレベルの特定を行うことができ、および／またはＤＰＩの選択的な、ポリシーによって制御された使用を可能にすることができるシステム、方法、および手法が、開示される。ＤＰＩが使用され得る程度が、端末の制御エンティティ、例えば、セッションマネージャによって構成可能であってもよい。これは、ＤＰＩに専用のリソースのポリシーに基づく制御と、本明細書において説明される進化型のソケットインターフェースによって提供される特定のレベルとを可能にする。

例えば、レガシーのアプリケーションをサポートするための発展型ソケットインターフェース（Ａｄｖａｎｃｅｄ Ｓｏｃｋｅｔ Ｉｎｔｅｒｆａｃｅ）（ＡＳＩＦ）が、本明細書において開示される。ＡＳＩＦは、アプリケーションが通信セッションを開始し、利用するためのアクセス能力を提供する改良されたプロトコルスタックの実装のための機能コンポーネントである可能性がある。下位互換を目的として、ＡＳＩＦは、アプリケーションに対して、自身を改良型のソケットインターフェースとして示す可能性がある。ＡＳＩＦは、以下、すなわち、アプリケーションがそれらのアプリケーションの目的のためにＩＰスタック（例えば、ＥＩＰＳ）の接続を開き／閉じ、管理するための技術を提供すること、接続を必要とする可能性があるアプリケーションおよびそのアプリケーションのＱｏＳの要件についての情報をセッション管理（ＳＭ）コンポーネントに提供すること、または例えば、接続マネージャによって定義されたように、アプリケーションデータを適切なトランスポートプロトコルに／から受け渡しすることのうちの１つまたは複数を行う可能性がある。

図５は、例示的なＡＳＩＦ機能コンポーネント（ＡＳＩＦ ＦＣ）の機能図である。図５に示されるように、ＡＳＩＦは、例えば、例示的なインターフェースＣ１、Ｄ４、およびＤ５を通じて制御エンティティ（例えば、セッションマネージャ（ＳＭ））、トランスポートレイヤ、およびアプリケーションとインターフェースを取ることができる。アプリケーションと通信するために使用されるインターフェースＤ５は、ＢＳＤソケットインターフェースに基づく可能性がある。ＡＳＩＦは、（例えば、内部的な実装として）以下の関数、すなわち、ＳｅｓｓｉｏｎＯｐｅｎ、ＳｅｓｓｉｏｎＣｏｎｎｅｃｔ、ＳｅｓｓｉｏｎＣｌｏｓｅ、ＩｎｃｏｍｉｎｇＤａｔａ、ＯｕｔｇｏｉｎｇＤａｔａ、またはＰａｓｓＴｈｒｏｕｇｈのうちの１つまたは複数をサポートする可能性がある。

ＡＳＩＦ機能コンポーネントは、ソケット関数を通じてアプリケーションから受信されたパラメータに、および／またはパケットインスペクション（ＰＩ）の手順、例えばパケットを送受信するためのポートなどのセッションに関連する情報を抽出するディープパケットインスペクションアルゴリズムの変化形、セッションで使用されるアプリケーションプロトコルなどに依存する可能性がある。ＰＩは、レガシーのアプリケーションおよび特定の発展型のアプリケーションの確認、特定、監視などのためにＩｎｃｏｍｉｎｇＤａｔａおよびＯｕｔｇｏｉｎｇＤａｔａ関数で使用され得る。ＰＩ機能によって抽出されたセッション情報は、ＳＭにレポートされ得る。セッションに関連するパラメータは、以下のうちの１つまたは複数を含み得る。セッションＩＤ（ＳＩＤ）は、ソケットＩＤと呼ばれることもあるパラメータである可能性がある。ソケットＩＤは、未知である場合、ＮＵＬＬに設定される可能性がある。アプリケーションプロトコル名（ＰＮＡＭＥ）は、未知の場合にＮＵＬＬに設定され得るパラメータである可能性がある。ＰＮＡＭＥの値は、ＰＩによってサポートされるプロトコルにリンクされ得る（例えば、表８）。アプリケーションＩＤ（ＡＩＤ）は、未知の場合にＮＵＬＬに設定され得るパラメータである可能性がある。セッションが同じアプリケーションのサブフローとして特定される場合、それらのセッションは同じＡＩＤを有する可能性がある。例えば、ＦＴＰアプリケーションは、ＦＴＰ制御セッションおよびＦＴＰデータセッションを含む可能性がある。両方のセッションが、同じＡＩＤを有する可能性がある。

単一のＳｅｓｓｉｏｎＯｐｅｎ、ＳｅｓｓｉｏｎＣｌｏｓｅ、およびＰａｓｓＴｈｒｏｕｇｈプロセスが、ＡＳＩＦのために必要とされる可能性がある。ＩｎｃｏｍｉｎｇＤａｔａおよびＯｕｔｇｏｉｎｇＤａｔａの別々のインスタンスが、それぞれのアクティブなセッションのために必要とされる可能性がある。

ソケットインターフェース呼び出しは、ＡＳＩＦのプロシージャにマッピングされる可能性がある。表５は、ソケットインターフェース呼び出しとＡＳＩＦプロセスとの間の例示的なマッピングを示す。一部の呼び出しは、接続を受け付けることができるサーバ（例えば、ＴＣＰサーバ）を対象としており、それらの接続を開始する端末を対象としていない可能性があるためにマッピングされない可能性がある。

セッションは、関連する状態を有する可能性がある。アクティブなセッションは、ＳｅｓｓｉｏｎＯｐｅｎプロセスによって生成され、ＳｅｓｓｉｏｎＣｌｏｓｅプロセスによって削除される可能性がある。例示的なセッションのライフタイムが、図６に示される。

ソケットのライフタイム中に、ＡＳＩＦコンポーネントは、セッション状態マシン（ｓｅｓｓｉｏｎ ｓｔａｔｅ ｍａｃｈｉｎｅ）（ＳＳＭ）を保有する可能性がある。ＳＳＭは、セッションのために使用されるアプリケーションプロトコルの種類の知識を示すことができる。ＳＳＭは、ｃｏｎｎｅｃｔ（）を用いて受信される５つ組みによって、およびＰＩ機能によって更新され得る。

（例えば、ＳＳＭに関する）例示的な状態遷移図が、図７に示され、図７は、ＡＳＩＦにより監視されるセッションに関する状態遷移図を示す。図７を参照すると、１つの状態は、ＳｅｓｓｉｏｎＯｐｅｎによって設定される開始状態である可能性がある新しいセッション（ＮＥＷ）状態を含み得る。ＳｅｓｓｉｏｎＣｏｎｎｅｃｔ（）は、送信先ポート分析を実行することができる。その送信先ポートが、例えばＩＡＮＡによって定義されているよく知られているポートである場合、ＳＳＭは、未検証／安定（ＵＳ）状態に遷移する可能性がある。そうでない場合、ＳＳＭは、未知（Ｕ）状態に遷移する可能性がある。未知（Ｕ）状態は、セッションのために使用されるアプリケーションが特定されなかったことを示す可能性がある。

図７は、違反（Ｖ）状態を示す。違反状態は、セッションのプロトコルが（検証済みのまたは未検証の）特定されたプロトコルの規則に違反していることが分かったことを示す可能性がある。この状態への遷移は、セッションのプロトコル違反をＳＭにレポートすることを引き起こす可能性がある。Ｖ状態での動作は、無制限にサポートされる可能性がある。

図７は、未検証／安定（ＵＳ）状態を示す。未検証／安定状態は、セッションを使用するアプリケーションプロトコルが、デフォルトの構成および／またはｃｏｎｎｅｃｔ（）の呼び出しで渡されたパラメータを用いて特定されたが、その特定が確認されていないことを示す可能性がある。未検証／安定状態は、セッションが、現在、再構成されるプロセス中でない（例えば、いかなる再構成のトリガも生成されなかった）ことを示す可能性がある。

図７は、未検証／再構成（ＵＲ）状態を示す。未検証／再構成状態は、セッションを使用するアプリケーションプロトコルが、デフォルトの構成ならびに／またはｓｏｃｋｅｔ（）およびｃｏｎｎｅｃｔ（）の呼び出しで渡されたパラメータを用いて特定されたが、その特定が確認されていないことを示す可能性がある。

図７は、検証済み／安定（ＶＳ）状態を示す。検証済み／安定状態は、セッションを使用するアプリケーションが、デフォルトの構成ならびに／またはｓｏｃｋｅｔ（）およびｃｏｎｎｅｃｔ（）の呼び出しで渡されたパラメータを用いて特定され、その特定が、例えばＰＩによって確認されたことを示す可能性がある。検証済み／安定状態は、セッションが、現在、再構成されるプロセス中でない（例えば、いかなる再構成のトリガも生成されなかった）ことを示す可能性がある。

図７は、未検証／再構成（ＶＲ）状態を示す。未検証／再構成状態は、セッションを使用するアプリケーションが、デフォルトの構成ならびに／またはｓｏｃｋｅｔ（）の呼び出しで渡されたパラメータを用いて特定され、その特定が確認されたことを示す可能性がある。未検証／再構成状態は、特定されたプロトコルの詳細に基づいて、セッションが再構成されるプロセス中であり、再構成のトリガが生成されたことを示す可能性がある。

ＮＥＷ→ＵおよびＮＥＷ→ＵＳを除いたそれぞれの状態遷移は、発信方向か着信方向かのどちらかのパケットの受信の結果として起こり得る。遷移ＮＥＷ→ＵおよびＮＥＷ→ＵＳは、本明細書において開示されるようにソケットを接続すると（例えば、ＮＥＷ状態）発生する可能性がある。遷移の性質は、ＩｎｃｏｍｉｎｇＤａｔａおよびＯｕｔｇｏｉｎｇＤａｔａプロセスによってあらゆるパケットに関して呼び出される可能性があるパケットインスペクション機能の結果である可能性がある。ＳＩＤ ｎに関する状態マシンの遷移は、ＰＩ機能がＳＩＤ ｎを返した場合に起こり得る。

表６は、原因および結果を含み得る例示的なセッションの状態遷移の仕様を示す。

パケットインスペクション（ＰＩ）機能は、例えば、着信方向かまたは発信方向かのどちらかのパケットに関して要求される可能性がある。ＰＩ機能は、以下、すなわち、パケットのＳＩＤが未知であること（例えば、これは、着信方向で起こり得る）、またはパケットのＳＩＤがＵ、ＵＳ、もしくはＵＲ状態のセッションに関連することのうちの１つまたは複数を満たす各パケットに対して呼び出される可能性がある。ＰＩ機能は、ＶＳまたはＶＲ状態のＳＩＤを有するパケットに関して呼び出される可能性がある。この決定は、ＳＭに任される可能性があり、プロセスごとに構成される可能性がある。

受信されたパケットに加えて、パケットインスペクション機能は、以下の入力、すなわち、ＳＩＤ、ＰＮＡＭＥ、ＭＯＤＥ、またはＩＮＳＰＥＣＴＩＯＮ ＬＥＶＥＬのうちの１つまたは複数を受け取る可能性がある。ＳＩＤは、未知である場合（例えば、これは、着信方向で起こり得る）、ＮＵＬＬに設定される可能性がある。ＰＮＡＭＥは、プロトコル名を表す可能性がある。ＰＮＡＭＥは、未知である場合、ＮＵＬＬに設定される可能性がある。ＭＯＤＥは、｛ＤＩＳＣＯＶＥＲ，ＣＯＮＦＩＲＭ，ＭＯＮＩＴＯＲ｝のうちの１つである可能性がある。

ＤＩＳＣＯＶＥＲモードにおいて、ＰＩ機能のタスクは、所与のＳＩＤに関してどのアプリケーションプロトコルが使用されているかを発見することである可能性がある。ＰＮＡＭＥがＮＵＬＬでない場合、プロトコルのリストが、候補リストとして扱われる可能性があり、検索空間を狭め、高速化するために使用される可能性がある。ＳＩＤがＮＵＬＬである場合、パケットは、潜在的に、Ｕ状態の任意のセッションに属すると想定され得る。

ＣＯＮＦＩＲＭモードおよびＭＯＮＩＴＯＲモードにおいて、ＰＩ機能のタスクは、プロトコルの動作を監視し、再構成のトリガを設定することである可能性がある。これらの状態においては、ＳＩＤおよびＰＮＡＭＥは、ＮＵＬＬに設定されることが許されない可能性がある。さらに、ＰＮＡＭＥは、一意な設定を有する必要がある可能性があり、この設定は、このＳＩＤに関するＰＮＡＭＥの前の設定と一貫している必要がある可能性がある。この規則に違反すると、ＰＩ機能が、所与のパケットでＳＩＤに関してＶＩＯＬＡＴＩＯＮを返す結果となる可能性がある。ＣＯＮＦＩＲＭモードにおいて、ＰＩ機能は、プロトコルが確かにＰＮＡＭＥに対応していることを確認するように要求される可能性がある。

ＩＮＳＰＥＣＴＩＯＮ ＬＥＶＥＬパラメータは、特定のセッションに対してパケットインスペクションが行われる深さ（例えば、レベル）を決定する可能性がある。ＩＮＳＰＥＣＴＩＯＮ ＬＥＶＥＬパラメータは、ＰＩ機能が設定することができる可能性がある再構成のトリガおよびＰＩ機能が行うことができる可能性があるプロトコルの測定の種類を決定する可能性がある。ＩＮＳＰＥＣＴＩＯＮ ＬＥＶＥＬは、１つまたは複数のＳＭのポリシーに基づいてＳＭによって設定され得る。ＤＥＦＡＵＬＴ ＩＮＳＰＥＣＴＩＯＮ ＬＥＶＥＬが、ＳＭによって設定される可能性があり、ＳＭが特定のＩＮＳＰＥＣＴＩＯＮ ＬＥＶＥＬを設定しなかったセッションにＡＳＩＦによって適用される可能性がある。例示的なＩＮＳＰＥＣＴＩＯＮ ＬＥＶＥＬが、表７に示される。

ＰＩ機能は、以下、すなわち、ＰＮＡＭＥ、アプリケーションプロトコル、現在のパケットのＳＩＤに関するアプリケーションＩＤ、その他の関連するＳＩＤ、以下の｛ＮＯ ＣＨＡＮＧＥ，ＶＩＯＬＡＴＩＯＮ，ＣＯＮＦＩＲＭ，ＰＲＯＴＯＣＯＬ ＩＤ｝のうちの１つ、以下の｛ＳＴＡＢＬＥ，ＲＥＣＯＮＦＩＧ｝のうちの１つのうちの１つもしくは複数を返す可能性があり、またはＲＥＣＯＮＦＩＧが返される場合は、再構成の性質がレポートされる可能性がある。構成の性質は、以下、すなわち、ＮＥＸＴ＿ＴＰ（次のメッセージのトランスポートプロトコル）、ＮＥＸＴ＿ＰＲＴ＿Ｓ（次の送信元ポート）、ＮＥＸＴ＿ＰＲＴ＿Ｄ（次の送信先ポート）、またはアプリケーションプロトコルに固有の情報のうちの１つまたは複数を含み得る。

ＰＩ機能によってサポートされるプロトコルのリストは、構成可能なパラメータである可能性がある。実際のＰＩ機能は、任意の知られているディープパケットインスペクションアルゴリズムのうちの１つである可能性がある。

図８は、例示的なパケットインスペクションを示す。

現在のパケットの分析において、ＰＩが、現在のセッションにリンクされ、現在のセッションに関連するアプリケーションに属している可能性がある潜在的な将来開くセッションを検出する場合、ＰＩは、潜在的なサブフローのトリガ（ｐｏｔｅｎｔｉａｌ ｓｕｂ−ｆｌｏｗ ｔｒｉｇｇｅｒ）を設定する可能性がある。潜在的なサブフローのトリガは、後でセッションを開くこと、および新しい開いたセッションが現在のセッションに関連するアプリケーションに属するかどうかを確認するための新しいセッションのパケットの分析のために使用され得る。このトリガに関連付けて、ＰＩは、予測される将来のセッションに関連する詳細（例えば、ポート番号、プロトコルなど）を追跡することができる。例えば、ＴＣＰ送信先ポート２１および何らかの特定の送信先ＩＰアドレス（ＩＰｘ）を用いて端末で開始されたＦＴＰ制御接続で開始されたＦＴＰセッションを考える。ＰＩ機能は、この接続を監視し、ＴＣＰポートＡおよび送信先ＩＰ ＩＰｙを用いてＦＴＰデータ接続を設定するための命令を有する、端末に戻るＦＴＰコマンドを検出することができる。そのとき、ＰＩ機能は、潜在的なサブフローのトリガを設定する可能性がある。潜在的なサブフローのトリガは、以下、すなわち、サブフローのトリガのＩＤ、サブフローのトリガの詳細、サブフローのトリガの情報、またはサブフローのトリガのライフタイムのうちの１つまたは複数を含み得る。

サブフローのトリガの詳細は、以下、すなわち、アプリケーションＩＤ（例えば、ＦＴＰアプリケーションに関連するアプリケーションＩＤを使用する）、送信先ポートの種類：ＴＣＰ、送信先ポートアドレス：Ａ、または送信先ＩＰ：ＩＰｙのうちの１つまたは複数を含み得る。サブフローのトリガの情報は、以下、すなわち、マスターセッションＩＤ：ＦＴＰ制御セッションのセッションＩＤ、サブフローのトリガの種類：「ＦＴＰデータ転送」、またはサブフローのトリガの追加情報：追加的な情報、この種類のセッションに関連する可能性があるそのようなＱｏＳの要件、例えば、要求されるファイルのサイズなどのうちの１つまたは複数を含み得る。サブフローのトリガのライフタイムは、有効期間、有効期限などを含み得る。

ＳｅｓｓｉｏｎＯｐｅｎプロセスは、アプリケーションに関する通信セッションを開始する役割を担う可能性がある。ＳｅｓｓｉｏｎＯｐｅｎプロセスは、アプリケーションが、例えば、Ｄ５でｓｏｃｋｅｔ（）の呼び出しを行うときに開始される可能性があり、アプリケーションのためにその呼び出しに対する応答を生成する役割を担う可能性がある。アクティブ化されると、ＳｅｓｓｉｏｎＯｐｅｎプロセスは、以下、すなわち、ｓｏｃｋｅｔ（）の呼び出しが新しいセッションに対応するかどうかを検査するか、もしくは潜在的なサブフローのトリガが立てられている場合にソケットが既存のセッションに関連付けられ得るかどうかを判定すること、その他のプロセスおよびコンポーネントとの、そのセッションについての通信で使用されるべきセッションＩＤ（ＳＩＤ）を定義すること、ｓｏｃｋｅｔ（）のパラメータからソケットの種類（例えば、ＵＤＰ、ＴＣＰなど）の情報を取り出すこと、セッションマネージャおよび接続マネージャに新しいセッションを開く要求を知らせること、またはソケットが受け付けられる場合に、開いたセッションの状態に入ることのうちの１つまたは複数を実行する可能性がある。

図９は、例示的なＳｅｓｓｉｏｎＳｔａｒｔ／ＳｅｓｓｉｏｎＯｐｅｎプロセスを示す。

関数ｉｎｔ ｓｏｃｋｅｔ (ｉｎｔ ｆａｍｉｌｙ, ｉｎｔ ｔｙｐｅ, ｉｎｔ ｐｒｏｔｏｃｏｌ)は、通信のエンドポイントを生成することができ、ソケットに関連するさらなる動作のために使用され得る記述子（例えば、セッションＩＤ）を返すことができる。（例えば、本明細書において開示される）ＴＣＰ／ＩＰに基づくソケットに関して、ｆａｍｉｌｙパラメータは、ＡＦ＿ＩＮＥＴに設定され得る。ｔｙｐｅパラメータは、（例えば、ＴＣＰに関して）ＳＯＣＫ＿ＳＴＲＥＡＭまたは（例えば、ＵＤＰに関して）ＳＯＣＫ＿ＤＧＲＡＭである可能性がある。ｐｒｏｔｏｃｏｌフィールドは、ネットワークモデルがさまざまな種類のストリームおよびデータグラムのモデルをサポートする場合に特定のプロトコルを指定することができる。このフィールドは、０に設定され得る（例えば、ＴＣＰ／ＩＰは、それぞれに関して１つのプロトコルを有する可能性がある）。

関数のドメイン（ｄｏｍａｉｎ）は、ソケットが生成されるべき通信のドメインを指定する可能性がある。（例えば、本明細書において開示される）ＴＣＰ／ＩＰに基づくソケットに関して、ｆａｍｉｌｙパラメータは、ＰＦ＿ＩＮＥＴ（ＩＰｖ４インターネットプロトコル）およびＰＦ＿ＩＮＥＴ６（ＩＰｖ６インターネットプロトコル）に設定され得る。

「Ｔｙｐｅ」は、生成されるべきソケットの種類を指定することができる。「Ｐｒｏｔｏｃｏｌ」は、ソケットで使用されるべき特定のプロトコルを指定することができる。ｐｒｏｔｏｃｏｌ引数が非ゼロである場合、その引数は、アドレスファミリーによってサポートされるプロトコルを指定することができる。ｐｒｏｔｏｃｏｌ引数がゼロである場合、このアドレスファミリーおよび種類のためのデフォルトのプロトコルが使用され得る。システムによってサポートされるプロトコルは、実装で定義される可能性がある。

セッションＩＤは、ＡＳＩＦによってランダムに生成され得る。セッションＩＤは、そのソケットで動作し得るその後の関数呼び出しでアプリケーションによって使用され得るソケットＩＤとして返される可能性がある。

例えば、Ｄ５でｃｏｎｎｅｃｔ（）の呼び出しを受信すると、ＳｅｓｓｉｏｎＣｏｎｎｅｃｔプロセスが、関数呼び出しのパラメータとして渡されたソケットのＳＩＤを、関数を通じて渡された送信先ポートおよびＩＰを有するピアに接続する役割を担う可能性がある。ＳｅｓｓｉｏｎＣｏｎｎｅｃｔプロセスは、以下、すなわち、デフォルトのアプリケーションの構成を用いてセッションを特定するように試みること、セッションがアプリケーションのサブフローであるかどうかを特定するように試みること、ＳＳＭを未知（Ｕ）状態かもしくは未検証／安定（ＵＳ）状態かのどちらかに更新すること、ＳＭ＿ＳｅｓｓｉｏｎＣｏｎｎｅｃｔ（）を呼び出すことによって、既に開いているセッションに接続するように要求のセッションマネージャに要求すること、または値を返すことのうちの１つまたは複数を実行する可能性がある。

図１０は、例示的なＳｅｓｓｉｏｎＣｏｎｎｅｃｔプロセスを示す。

ｃｏｎｎｅｃｔ（）関数呼び出しは、ソケットのファイル記述子によって特定されるソケットを、引数のリスト内のホストのアドレスによって指定されたそのリモートホストに接続することができる。特定の種類のソケットはコネクションレス型である可能性があり、ＵＤＰソケットが一例であり得る。これらのソケットに関して、ｃｏｎｎｅｃｔは、以下の意味を持つ可能性があり、すなわち、データを送受信するためのデフォルトのターゲットが所与のアドレスに設定され、このことは、コネクションレス型のソケットでｓｅｎｄ（）およびｒｅｃｖ（）などの関数を使用することを可能にすることができる。ｃｏｎｎｅｃｔ（）は、エラーコードを表す整数を返す可能性があり、０が成功を表す可能性があり、−１がエラーを表す可能性がある、等々である。

ｃｏｎｎｅｃｔのプロトタイプは、次の通りである可能性がある：ｉｎｔ ｃｏｎｎｅｃｔ (ｉｎｔ ｓｏｃｋｆｄ, ｃｏｎｓｔ ｓｔｒｕｃｔ ｓｏｃｋａｄｄｒ *ｓｅｒｖ_ａｄｄｒ, ｓｏｃｋｌｅｎ_ｔ ａｄｄｒｌｅｎ)。第１の引数は、ソケットのハンドル（例えば、ｓｏｃｋｅｔ（）関数呼び出しから返された数）である可能性がある。第２の引数は、ｓｏｃｋａｄｄｒ＿ｉｎ構造体である可能性がある。アドレス引数のｓｉｎ＿ｐｏｒｔフィールドは、このソケットに関連するローカルの送信元ポート番号である可能性がある。つまり、このソケットによる「ｓｅｎｄ」動作に関して、ＴＣＰ／ＵＤＰヘッダの送信元ポートフィールドは、この値を用いて設定され得る。送信元ポートを指定することが必要とされない場合、この値をＩＮＡＤＤＲ＿ＡＮＹ（０）に設定することによって、オペレーティングシステムが任意の利用可能なポート番号を選ぶことを可能にすることができる。ｓｉｎ＿ａｄｄｒフィールドは、どのネットワークインターフェースデバイスを使用すべきかを指定することができる。多くのホストは１つのネットワークインターフェースおよび１つのＩＰアドレスを有する可能性があるので、このフィールドは、ホスト自身のＩＰアドレスを用いて設定され得る。ソケットライブラリは、ホストがそのホスト自身のＩＰアドレスを判定する直接的な方法を提供しない可能性がある。このフィールドにＩＮＡＤＤＲ＿ＡＮＹ（０）の値を指定することは、任意の利用可能なインターフェースおよびアドレスを選択するようにオペレーティングシステムに指示することができる。ｓｏｃｋａｄｄｒ＿ｉｎ構造体のアドレスは、ソケットがリモートホストと通信する準備ができた状態になり得るようにｂｉｎｄの呼び出しに渡される可能性がある。ｂｉｎｄに渡される第３のパラメータは、ｓｏｃｋａｄｄｒ＿ｉｎ構造体の長さである可能性がある。

既知のアプリケーションプロトコルに関する調査が行われる可能性がある。ＬＥＧＡＣＹアプリケーションに関して、３つ組み＜トランスポートプロトコル，送信元ポート，送信先ポート＞が、ＩＡＮＡの知られているアプリケーションのテーブルと照合される可能性がある。表８は、ｃｏｎｎｅｃｔのパラメータに基づくプロトコルの分析の例示的なテーブルである。

ｃｏｎｎｅｃｔ（）のパラメータが上述のテーブルの一部である場合、ＳＳＭは、ＵＳに設定される可能性があり、関連するアプリケーションプロトコルＰＮＡＭＥは、テーブルからの値を用いて設定される。そうでない場合、ＳＳＭは、Ｕ状態に遷移する可能性があり、ＰＮＡＭＥは、ＮＵＬＬに設定される可能性がある。

アプリケーションがＤ５でｒｅｃｖ（）またはｒｅｃｅｖｆｒｏｍ（）を呼び出すとき、Ｉｎｃｏｍｉｎｇ Ｄａｔａが呼び出される可能性がある。パケットに関するセッションＩＤが（例えば、５つ組みに基づいて）特定され得る場合、データは、Ｄ５を通じて正しいアプリケーションに渡され得る。データが受信されるセッションがＰＩ機能が呼び出されるべきであることを示す場合、これが行われる可能性がある。ＰＩ機能が完了するとき、表６に定義された動作が行われる。ＯｕｔｇｏｉｎｇＤａｔａが、それぞれの発信パケットに対して呼び出される。パケットに関するセッション番号が（例えば、５つ組みに基づいて）特定され得る場合、データは、正しいトランスポートプロトコルに渡され得る。

ＳｅｓｓｉｏｎＣｌｏｓｅが、アプリケーションがＤ５でｃｌｏｓｅ（）の呼び出しを行うときに開始される可能性があり、アプリケーションのためにこの呼び出しに対する応答を生成する役割を担う。アクティブ化されると、ＳｅｓｓｉｏｎＣｌｏｓｅプロセスは、以下、すなわち、ＳＩＤに関連するＳＳＭを終了させること、ＳＭおよびＣＭに開いているセッションを閉じる要求を知らせること、またはセッションＩＤ（ＳＩＤ）の割り当てを解除することのうちの１つまたは複数を実行する可能性がある。

ＰａｓｓＴｈｒｏｕｇｈプロセスは、ソケット呼び出しを、ＡＳＩＦに固有のプロセスを用いずに別のコンポーネントに転送することができる。Ｄ５でのｇｅｔｈｏｓｔｂｙｎａｍｅ（）またはｇｅｔｈｏｓｔｂｙａｄｄｒ（）の呼び出しに関して、ＡＳＩＦは、これらの関数を、処理されるようにＳＭに透過的に渡し、戻り値を、追加的な調査なしに応答として返すことができる。送信元アドレスに関して、アプリケーションは、アプリケーションにアドレスのリストを返す可能性があるＡＰＩ、例えば、ｇｅｔａｄｄｒｉｎｆｏ（）を使用することができる。リストは、ＩＰｖ６および／またはＩＰｖ４アドレスを含み得る。

ＡＳＩＦの機能に関連するインターフェースの仕様が、与えられ得る。Ｄ５は、アプリケーションと発展型ソケットＩＦ（ＡＳＩＦ）との間のインターフェースを指す可能性がある。このインターフェースは、レガシーのアプリケーションとＡＤＶアプリケーション（ＡＤＶ Ａｐｐｌｉｃａｔｉｏｎ）の両方のためのＢＳＤに似たソケットインターフェースを提供することができる。使用される機能は、クライアント側の機能に限られる可能性がある。例示的なＤ５の関数が、表９に示される。

Ｃ１は、発展型ソケットＩＦ（ＡＳＩＦ）とＳＭなどの制御プレーンのエンティティとの間のインターフェースを指す可能性がある。このインターフェースは、ＡＳＩＦが、新しいセッションが検出されたこと、またはアクティブなセッションに関して変更が行われたことをＳＭに知らせることを可能にすることができる。変更とは、以下、すなわち、セッションへの新しいソケット（例えば、新しいセッション、サブフローなど）の追加、サブフローの削除、またはセッションの記述の変更（例えば、新しいＱｏＳ、モビリティが必要とされるか否か、セキュリティのレベル）などのうちの１つまたは複数を指す可能性がある。例示的Ｃ１の関数が、表１０で与えられる。

Ｄ４は、ＡＳＩＦとトランスポートＦＣとの間で使用され得る。Ｄ４は、トランスポートＦＣにデータパケットを送信することとトランスポートＦＣからデータパケットを受信することとを可能にすることができる。例示的なＤ４の関数が、表１１に示される。

ｓｏｃｋｅｔ（）インターフェース関数はパラメータ（ａｄｖ）で拡張される可能性があり、その結果、表１２に示される形式を有する。

ａｄｖパラメータは、以下のパラメータ、すなわち、アプリケーションＩＤ、ＱｏＳプリファレンス（ＱｏＳ Ｐｒｅｆｅｒｅｎｃｅ）、プロトコル：ＡＤＶ、ｍａｓｔｅｒ＿ｓｏｃｋｅｔ＿ｉｄ、ｎｕｍ＿ｓｕｂｆｌｏｗｓ、ｓｕｂｆｌｏｗ＿ｄｅｓｃ、またはＰｒｅｆｅｒｒｅｄ＿ｎｅｔｗｏｒｋのうちの１つまたは複数を含み得る。アプリケーションＩＤは、同じアプリケーションによって開かれた複数のセッションをリンクするためにシステムによって使用され得る、アプリケーションによって選択されたアプリケーションＩＤである可能性がある。オペレーティングシステムによってアプリケーションに割り振られたプロセスＩＤが、アプリケーションＩＤとして使用され得る。ＱｏＳプリファレンスは、あるＱｏＳプリファレンスを与えることができる。アプリケーションは、プロトコル：ＡＤＶを使用して、例えば、本明細書において開示される値を有するそのアプリケーションのアプリケーションプロトコルを送信することができる。ｍａｓｔｅｒ＿ｓｏｃｋｅｔ＿ｉｄは、ソケットが別のソケットｉｄとの接続に関する下位接続と見なされるべきであることを示すことができる。ｎｕｍ＿ｓｕｂｆｌｏｗｓは、ソケットが複数のサブフローを含むことを示すために使用され得る。値＞１が使用される場合、サブフロー記述子（ｓｕｂ−ｆｌｏｗ ｄｅｓｃｒｉｐｔｏｒ）が含まれる可能性があり、そうでない場合、これは無視される可能性がある。値＞１は、サポートされない可能性がある。ｓｕｂｆｌｏｗ＿ｄｅｓｃは、サブフロー記述子である可能性がある。Ｐｒｅｆｅｒｒｅｄ＿ｎｅｔｗｏｒｋは、アプリケーションのネットワークのプリファレンスを示すために使用され得る。２つの種類が、含まれる可能性がある。アプリケーションは、ネットワークとして＜ＭＯＢＩＬＥ，ＰＵＢＬＩＣ＿ＩＰ，ＰＲＩＶＡＴＥ＿ＩＰ＞を優先することを示すことができるか、またはアプリケーションは、特定のネットワーク（例えば、特定のモバイル運用者、ＳＳＩＤのリストによる特定の公衆ＷｉＦＩネットワークなど）を示すことができる。ＭＯＢＩＬＥは、モバイル／セルラネットワークである可能性がある。ＰＵＢＬＩＣ＿ＩＰは、パブリックＩＰ（例えば、インターネットにアクセスするネットワーク）である可能性がある。ＰＲＩＶＡＴＥ＿ＩＰは、プライベートＩＰネットワーク−例えば、組織の企業ネットワーク−である可能性がある。

ＱｏＳプリファレンスは、アプリケーションが必要とする接続の種類を指定する方法をアプリケーションに提供し、ＳＭがセッションのリソースを割り当てることを可能にすることができる。ＱｏＳプリファレンスは、アプリケーションがプリファレンスの順序で配列することができるＱｏＳインジケータ（ＱｏＳ Ｉｎｄｉｃａｔｏｒ）の組を定義する可能性がある。アプリケーションは、ＱｏＳインジケータのうちの１つまたはサブセットを使用するように制限される（例えば、最高のプリファレンスから最低に向かう順序でいくつかを指定する）可能性がある。ＡＳＩＦは、パケットインスペクションの分析に基づいてこれらを設定および／または修正することができる。

ＱｏＳクラス（ＱｏＳ Ｃｌａｓｓ）は、以下のうちの１つまたは複数を含み得る。ＱｏＳＩ＿ＴＨＲＯＵＧＨＰＵＴ：このＱｏＳインジケータは、スループットの最大化が重要であることをシグナリングするために使用され得る。ＱｏＳＩ＿ＬＡＴＥＮＣＹ：このＱｏＳインジケータは、レイテンシの最小化が重要であることをシグナリングするために使用される可能性があり、これは、スループットを犠牲にする可能性がある。ＱｏＳＩ＿ＲＥＬＩＡＢＩＬＩＴＹ：このＱｏＳインジケータは、パケット誤り率の最小化が重要であることをシグナリングするために使用される可能性があり、これは、スループットおよびレイテンシを犠牲にする可能性がある。ＱｏＳ＿ＰＯＷＥＲ＿ＥＦＦ：このＱｏＳインジケータは、電力消費の最小化が重要であることをシグナリングするために使用される可能性があり、これは、その他のＱｏＳの観点を犠牲にする可能性がある。ＱｏＳ＿ＣＲＩＴＩＣＡＬ：このＱｏＳインジケータは、アプリケーションがそのアプリケーション自身を重大な機能のサービス（例えば、人の健康、動作の信頼性など）と考えることをシグナリングするために使用され得る。アプリケーションは、そのアプリケーションに割り振られるべきリソースがＳＭによる決定を経る可能性があるが、これを用いて高い優先度のサービスを要求することができる。ＱｏＳ＿ＳＥＣＵＲＥ：このＱｏＳインジケータは、高セキュリティの接続が必要とされることをシグナリングするために使用され得る。これが提供される程度は、ＳＭに任される可能性がある。ＱｏＳ＿ＢＡＣＫＧＲＯＵＮＤ：このＱｏＳインジケータは、バックグラウンドサービスのために使用される可能性があり、ＳＭが、例えば、コストを最小化するようにリソースを割り当てることなどを可能にすることができる。

セルラ接続の場合、指定されたＱｏＳクラスは、セルラシステムの仕様で規定されたＱｏＳクラスにマッピングされ得る。

特徴および要素が特定の組み合わせで上で説明されているが、当業者は、各特徴または要素が、単独で、またはその他の特徴および要素との任意の組み合わせで使用され得ることを理解するであろう。加えて、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装され得る。コンピュータ可読媒体の例は、（有線または無線接続を介して送信される）電子的な信号と、コンピュータ可読ストレージ媒体とを含む。コンピュータ可読ストレージ媒体の例は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能なディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタルバーサタイルディスク（ＤＶＤ）などの光媒体を含むがこれらに限定されない。ソフトウェアに関連するプロセッサが、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用され得る。

Claims (20)

1. サービス品質（ＱｏＳ）情報を決定するための方法であって、
   第１のＱｏＳカテゴリープロパティを受信するステップであって、前記第１のＱｏＳカテゴリープロパティは、前記第１のＱｏＳカテゴリープロパティに関連付けられた優先順位付けレベルを示し、前記優先順位付けレベルは、前記第１のＱｏＳカテゴリープロパティに関連付けられた複数の優先順位付けレベルのうちの１つである、ステップと、
   第２のＱｏＳカテゴリープロパティを受信するステップであって、前記第２のＱｏＳカテゴリープロパティは、前記第２のＱｏＳカテゴリープロパティに関連付けられた優先順位付けレベルを示し、前記優先順位付けレベルは、前記第２のＱｏＳカテゴリープロパティに関連付けられた複数の優先順位付けレベルのうちの１つである、ステップと、
   前記第１のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルおよび前記第２のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルの評価に基づいて、適用するためのＱｏＳを決定するステップと
   を含むことを特徴とする方法。
2. 前記優先順位付けレベルは、互いに対して優先順位を決められることを特徴とする請求項１に記載の方法。
3. 前記第１のＱｏＳカテゴリープロパティはスループットであり、および、前記第２のＱｏＳカテゴリープロパティはレイテンシであることを特徴とする請求項１に記載の方法。
4. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティに関連付けられたデータストリームに、前記決定されたＱｏＳを適用するステップをさらに含むことを特徴とする請求項１に記載の方法。
5. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティに関連付けられたアプリケーションサブフローに、前記決定されたＱｏＳを適用するステップをさらに含むことを特徴とする請求項１に記載の方法。
6. 適用するための前記ＱｏＳは、前記決定されたＱｏＳに関連付けられたキューを選択することによって実装されることを特徴とする請求項１に記載の方法。
7. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティは、アプリケーションによって提供されることを特徴とする請求項１に記載の方法。
8. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティは、ユーザまたはオペレータによって提供されることを特徴とする請求項１に記載の方法。
9. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティは、前記ユーザまたは前記オペレータがポーリングされたことに応答して提供されることを特徴とする請求項８に記載の方法。
10. 前記第１のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルは、前記第２のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルに直交することを特徴とする請求項１に記載の方法。
11. 無線送受信ユニット（ＷＴＲＵ）であって、
    第１のＱｏＳカテゴリープロパティを受信し、前記第１のＱｏＳカテゴリープロパティは、前記第１のＱｏＳカテゴリープロパティに関連付けられた優先順位付けレベルを示し、前記優先順位付けレベルは、前記第１のＱｏＳカテゴリープロパティに関連付けられた複数の優先順位付けレベルのうちの１つであり、
    第２のＱｏＳカテゴリープロパティを受信し、前記第２のＱｏＳカテゴリープロパティは、前記第２のＱｏＳカテゴリープロパティに関連付けられた優先順位付けレベルを示し、前記優先順位付けレベルは、前記第２のＱｏＳカテゴリープロパティに関連付けられた複数の優先順位付けレベルのうちの１つであり、
    前記第１のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルおよび前記第２のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルの評価に基づいて、適用するためのＱｏＳを決定する
    ように構成されたプロセッサを備えたことを特徴とするＷＴＲＵ。
12. 前記優先順位付けレベルは、互いに対して優先順位を決められることを特徴とする請求項１１に記載のＷＴＲＵ。
13. 前記第１のＱｏＳカテゴリープロパティはスループットであり、および、前記第２のＱｏＳカテゴリープロパティはレイテンシであることを特徴とする請求項１１に記載のＷＴＲＵ。
14. 前記プロセッサは、前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティに関連付けられたデータストリームに、前記決定されたＱｏＳを適用するようにさらに構成されたことを特徴とする請求項１１に記載のＷＴＲＵ。
15. 前記プロセッサは、前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティに関連付けられたアプリケーションサブフローに、前記決定されたＱｏＳを適用するようにさらに構成されたことを特徴とする請求項１１に記載のＷＴＲＵ。
16. 適用するための前記ＱｏＳは、前記決定されたＱｏＳに関連付けられたキューを選択することによって実装されることを特徴とする請求項１１に記載のＷＴＲＵ。
17. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティは、アプリケーションによって提供されることを特徴とする請求項１１に記載のＷＴＲＵ。
18. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティは、ユーザまたはオペレータによって提供されることを特徴とする請求項１１に記載のＷＴＲＵ。
19. 前記第１のＱｏＳカテゴリープロパティおよび前記第２のＱｏＳカテゴリープロパティは、前記ユーザまたは前記オペレータがポーリングされたことに応答して提供されることを特徴とする請求項１８に記載のＷＴＲＵ。
20. 前記第１のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルは、前記第２のＱｏＳカテゴリープロパティに関連付けられた前記優先順位付けレベルに直交することを特徴とする請求項１１に記載のＷＴＲＵ。