"サービス品質情報を決定するための方法であって、アプリケーションの特定に関連するインスペクションのレベルを示すポリシーを受信するステップと、セッションに関連する情報を受信するステップと、前記ポリシーによって示された前記レベルで、前記受信された情報のインスペクションを実行するステップとを含むことを特徴とする方法。インスペクションの前記レベルはインスペクションの第1のレベルであり、前記受信された情報はアプリケーションが提供する情報を含み、インスペクションの前記第1のレベルは、前記インスペクションが、前記アプリケーションが提供する情報を検査することを含むことを示すことを特徴とする請求項1に記載の方法。前記アプリケーションが提供する情報は、ソケット呼び出しを含むことを特徴とする請求項2に記載の方法。インスペクションの前記第1のレベルは、前記ソケット呼び出しに関連するポートを特定されたポートと比較することを含むことを特徴とする請求項3に記載の方法。前記インスペクションに基づいて前記セッションに関連するアプリケーションを特定するステップをさらに含むことを特徴とする請求項4に記載の方法。インスペクションの前記レベルはインスペクションの第2のレベルであり、前記受信された情報はパケットデータを含み、インスペクションの前記第2のレベルは、前記インスペクションが、前記パケットデータのパケットインスペクションを含むことを示すことを特徴とする請求項1に記載の方法。インスペクションの前記第2のレベルは、実行すべきパケットインスペクションの深さをさらに示し、前記パケットインスペクションは、前記示された深さで実行されることを特徴とする請求項6に記載の方法。前記インスペクションに基づいて前記セッションに関連するアプリケーションを特定するステップをさらに含むことを特徴とする請求項7に記載の方法。前記ポリシーに基づいてオペレーティングシステムに問い合わせを行うステップをさらに含むことを特徴とする請求項1に記載の方法。インスペクションの前記レベルはインスペクションの第3のレベルであり、前記受信された情報はオペレーティングシステムが提供する情報を含み、インスペクションの前記第3のレベルは、前記インスペクションが、前記オペレーティングシステムが提供する情報を検査することを含むことを示すことを特徴とする請求項9に記載の方法。前記インスペクションに基づいて前記セッションに関連するアプリケーションを特定するステップをさらに含むことを特徴とする請求項10に記載の方法。サービス品質情報を決定するように構成されたユーザ機器UEであって、アプリケーションの特定に関連するインスペクションのレベルを示すポリシーを記憶するように構成されたメモリと、セッションに関連する情報を受信するように構成された受信機と、前記ポリシーのポリシーによって示された前記レベルで、前記受信された情報のインスペクションを実行するように構成されたプロセッサとを備えることを特徴とするユーザ機器UE。インスペクションの前記レベルはインスペクションの第1のレベルであり、前記受信された情報はアプリケーションが提供する情報を含み、インスペクションの前記第1のレベルは、前記インスペクションが、前記アプリケーションが提供する情報を検査することを含むことを示すことを特徴とする請求項12に記載の方法。前記アプリケーションが提供する情報は、ソケット呼び出しを含むことを特徴とする請求項13に記載の方法。インスペクションの前記第1のレベルは、前記ソケット呼び出しに関連するポートを特定されたポートと比較することを含むことを特徴とする請求項14に記載の方法。前記プロセッサは、前記インスペクションに基づいて前記セッションに関連するアプリケーションを特定するようにさらに構成されることを特徴とする請求項15に記載の方法。インスペクションの前記レベルはインスペクションの第2のレベルであり、前記受信された情報はパケットデータを含み、インスペクションの前記第2のレベルは、前記インスペクションが、前記パケットデータのパケットインスペクションを含むことを示すことを特徴とする請求項12に記載の方法。インスペクションの前記第2のレベルは、実行すべきパケットインスペクションの深さをさらに示し、前記パケットインスペクションは、前記示された深さで実行されることを特徴とする請求項17に記載の方法。前記プロセッサは、前記インスペクションに基づいて前記セッションに関連するアプリケーションを特定するようにさらに構成されることを特徴とする請求項18に記載の方法。前記プロセッサは、前記ポリシーに基づいてオペレーティングシステムに問い合わせを行うようにさらに構成されることを特徴とする請求項12に記載の方法。インスペクションの前記レベルはインスペクションの第3のレベルであり、前記受信された情報はオペレーティングシステムが提供する情報を含み、インスペクションの前記第3のレベルは、前記インスペクションが、前記オペレーティングシステムが提供する情報を検査することを含むことを示すことを特徴とする請求項20に記載の方法。前記プロセッサは、前記インスペクションに基づいて前記セッションに関連するアプリケーションを特定するようにさらに構成されることを特徴とする請求項21に記載の方法。以降、例示的な実施形態の詳細な説明が、図を参照して示される可能性がある。しかし、本発明が例示的な実施形態に関連して説明される可能性があるが、本発明はそれらの例示的な実施形態に限定されず、本発明の同様の機能を実行するために、本発明を逸脱することなくその他の実施形態が使用され得るか、または記載された実施形態に対して修正および追加が行われ得ることが理解されるべきである。さらに、図は、例示的であるように意図されるコールフローを示す可能性がある。その他の実施形態が使用され得ることを理解されたい。フローの順序は、必要に応じて変更され得る。また、フローは不必要な場合は省略される可能性があり、追加的なフローが追加される可能性がある。図1Aは、1つまたは複数の開示された実施形態が実装され得る例示的な通信システム100の図である。通信システム100は、複数の無線ユーザに音声、データ、ビデオ、メッセージング、放送などのコンテンツを提供する多元接続システムである可能性がある。通信システム100は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有によってそのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム100は、符号分割多元接続CDMA、時分割多元接続TDMA、周波数分割多元接続FDMA、直交FDMAOFDMA、シングルキャリアFDMASC-FDMAなどの1つまたは複数のチャネルアクセス方法を使用することができる。図1Aに示されるように、通信システム100は、無線送受信ユニットWTRU102a、102b、102c、および/または102dこれらは全体的にまたは集合的にWTRU102と呼ばれる可能性がある、無線アクセスネットワークRAN103/104/105、コアネットワーク106/107/109、公衆交換電話網PSTN108、インターネット110、ならびにその他のネットワーク112を含み得るが、開示された実施形態は、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を考慮することが理解されるであろう。WTRU102a、102b、102c、102dのそれぞれは、無線環境内で動作および/または通信するように構成された任意の種類のデバイスである可能性がある。例として、WTRU102a、102b、102c、102dは、無線信号を送信および/または受信するように構成される可能性があり、ユーザ機器UE、移動局、固定または移動加入者ユニット、ページャ、セルラ電話、携帯情報端末PDA、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサー、家庭用電化製品などを含み得る。通信システム100は、基地局114aおよび基地局114bも含み得る。基地局114a、114bのそれぞれは、コアネットワーク106/107/109、インターネット110、および/またはネットワーク112などの1つまたは複数の通信ネットワークへのアクセスを容易にするために、WTRU102a、102b、102c、102dのうちの少なくとも1つと無線でインターフェースをとるように構成された任意の種類のデバイスである可能性がある。例として、基地局114a、114bは、無線基地局BTS、Node-B、eNodeB、ホームNodeB、ホームeNodeB、サイトコントローラ、アクセスポイントAP、無線ルータなどである可能性がある。基地局114a、114bはそれぞれ単一の要素として示されているが、基地局114a、114bは、任意の数の相互に接続された基地局および/またはネットワーク要素を含み得ることが理解されるであろう。基地局114aは、RAN103/104/105の一部であることができ、RAN103/104/105は、その他の基地局、および/または基地局コントローラBSC、無線ネットワークコントローラRNC、中継ノードなどのネットワーク要素図示せずも含み得る。基地局114aおよび/または基地局114bは、セルと呼ばれる場合がある特定の地理的領域図示せず内で無線信号を送信および/または受信するように構成され得る。セルは、セルのセクタにさらに分割され得る。例えば、基地局114aに関連するセルは、3つのセクタに分割され得る。したがって、一実施形態において、基地局114aは、3つのトランシーバ、すなわち、セルの各セクタに対して1つのトランシーバを含み得る。別の実施形態において、基地局114aは、多入力多出力MIMO技術を使用することができ、したがって、セルの各セクタに対して複数のトランシーバを利用する可能性がある。基地局114a、114bは、任意の好適な無線通信リンク例えば、無線周波数RF、マイクロ波、赤外線IR、紫外線UV、可視光などである可能性がある無線インターフェース115/116/117を介してWTRU102a、102b、102c、102dのうちの1つまたは複数と通信することができる。無線インターフェース115/116/117は、任意の好適な無線アクセス技術RATを用いて確立され得る。より具体的には、上述のように、通信システム100は、多元接続システムである可能性があり、CDMA、TDMA、FDMA、OFDMA、SC-FDMAなどの1つまたは複数のチャネルアクセススキームを使用する可能性がある。例えば、RAN103/104/105内の基地局114a、およびWTRU102a、102b、102cは、広帯域CDMAWCDMA登録商標を用いて無線インターフェース115/116/117を確立することができるUMTSUniversalMobileTelecommunicationsSystemUTRATerrestrialRadioAccessなどの無線技術を実装することができる。WCDMA登録商標は、HSPAHigh-SpeedPacketAccessおよび/またはHSPAEvolvedHSPAなどの通信プロトコルを含み得る。HSPAは、HSDPAHigh-SpeedDownlinkPacketAccessおよび/またはHSUPAHigh-SpeedUplinkPacketAccessを含み得る。別の実施形態において、基地局114aおよびWTRU102a、102b、102cは、LTELongTermEvolutionおよび/またはLTE-ALTE-Advancedを用いて無線インターフェース115/116/117を確立することができるE-UTRAEvolvedUMTSTerrestrialRadioAccessなどの無線技術を実装することができる。その他の実施形態において、基地局114aおよびWTRU102a、102b、102cは、IEEE802.16すなわち、WiMAXWorldwideInteroperabilityforMicrowaveAccess、CDMA2000、CDMA20001X、CDMA2000EV-DO、IS-2000InterimStandard2000、IS-95InterimStandard95、IS-856InterimStandard856、GSM登録商標GlobalSystemforMobilecommunications、EDGEEnhancedDataratesforGSMEvolution、GERANGSMEDGEなどの無線技術を実装することができる。図1Aの基地局114bは、例えば、無線ルータ、ホームNodeB、ホームeNodeB、またはアクセスポイントである可能性があり、事業所、家庭、車両、キャンパスなどの局所的な地域で無線接続を容易にするための任意の好適なRATを利用することができる。一実施形態において、基地局114bおよびWTRU102c、102dは、無線ローカルエリアネットワークWLANを確立するためのIEEE802.11などの無線技術を実装することができる。別の実施形態において、基地局114bおよびWTRU102c、102dは、無線パーソナルエリアネットワークWPANを確立するためのIEEE802.15などの無線技術を実装することができる。さらに別の実施形態において、基地局114bおよびWTRU102c、102dは、セルラに基づくRAT例えば、WCDMA登録商標、CDMA2000、GSM登録商標、LTE、LTE-Aなどを利用してピコセルまたはフェムトセルを確立することができる。図1Aに示されたように、基地局114bは、インターネット110への直接的な接続を有する可能性がある。したがって、基地局114bは、コアネットワーク106/107/109を介してインターネット110にアクセスするように要求されない可能性がある。RAN103/104/105は、コアネットワーク106/107/109と通信している可能性があり、コアネットワーク106/107/109は、WTRU102a、102b、102c、102dのうちの1つまたは複数に音声、データ、アプリケーション、および/またはボイスオーバーインターネットプロトコルVoIPサービスを提供するように構成された任意の種類のネットワークである可能性がある。例えば、コアネットワーク106/107/109は、呼制御、課金サービス、モバイルの位置に基づくサービス、プリペイド電話、インターネット接続、映像配信などを提供し、および/またはユーザ認証などの高レベルのセキュリティ機能を実行することができる。図1Aには示されていないが、RAN103/104/105および/またはコアネットワーク106/107/109は、RAN103/104/105と同じRAT、または異なるRATを使用するその他のRANと直接的または間接的に通信している可能性があることが理解されるであろう。例えば、E-UTRA無線技術を利用している可能性があるRAN103/104/105に接続されることに加えて、コアネットワーク106/107/109は、GSM登録商標無線技術を使用する別のRAN図示せずとも通信している可能性がある。コアネットワーク106/107/109は、WTRU102a、102b、102c、102dがPSTN108、インターネット110、および/またはその他のネットワーク112にアクセスするためのゲートウェイとしても働くことができる。PSTN108は、POTSplainoldtelephoneserviceを提供する回線交換電話ネットワークを含み得る。インターネット110は、TCP/IPインターネットプロトコルスイートの伝送制御プロトコルTCP、ユーザデータグラムプロトコルUDP、およびインターネットプロトコルIPなどの共通の通信プロトコルを使用する相互に接続されたコンピュータネットワークおよびデバイスの全世界的なシステムを含み得る。ネットワーク112は、その他のサービスプロバイダによって所有および/または運用される有線または無線通信ネットワークを含み得る。例えば、ネットワーク112は、RAN103/104/105と同じRAT、または異なるRATを使用する可能性がある1つまたは複数のRANに接続された別のコアネットワークを含み得る。通信システム100のWTRU102a、102b、102c、102dの一部またはすべては、マルチモード能力を含む可能性があり、すなわち、WTRU102a、102b、102c、102dは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含む可能性がある。例えば、図1Aに示されたWTRU102cは、セルラに基づく無線技術を使用することができる基地局114aと、およびIEEE802無線技術を使用することができる基地局114bと通信するように構成され得る。図1Bは、例示的なWTRU102のシステム図である。図1Bに示されたように、WTRU102は、プロセッサ118、トランシーバ120、送信/受信要素122、スピーカー/マイクロホン124、キーパッド126、ディスプレイ/タッチパッド128、取り外し不可能なメモリ130、取り外し可能なメモリ132、電源134、全地球測位システムGPSチップセット136、およびその他の周辺機器138を含み得る。WTRU102は、実施形態に準拠したまま、上述の要素の任意の部分的な組み合わせを含み得ることが理解されるであろう。また、実施形態は、基地局114aおよび114b、ならびに/またはそれだけに限らないが無線基地局BTS、Node-B、サイトコントローラ、アクセスポイントAP、ホームNode-B、進化型ホームNode-Bevolvedhomenode-BeNodeB、ホーム進化型node-Bhomeevolvednode-BHeNB、ホーム進化型node-Bゲートウェイhomeevolvednode-Bgateway、およびプロキシノードなどの、基地局114aおよび114bによって表され得るノードは、図1Bに示され、本明細書において説明される要素の一部またはすべてを含み得ると想定する。プロセッサ118は、汎用プロセッサ、専用プロセッサ、通常のプロセッサ、デジタル信号プロセッサDSP、複数のマイクロプロセッサ、DSPコアと関連する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路ASIC、フィールドプログラマブルゲートアレイFPGA回路、任意のその他の種類の集積回路IC、状態機械などである可能性がある。プロセッサ118は、信号の符号化、データ処理、電力制御、入力/出力処理、および/またはWTRU102が無線環境で動作することを可能にする任意のその他の機能を実行することができる。プロセッサ118は、トランシーバ120に結合される可能性があり、トランシーバ120は、送信/受信要素122に結合される可能性がある。図1Bはプロセッサ118およびトランシーバ120を別個のコンポーネントとして示すが、プロセッサ118およびトランシーバ120は、電子的なパッケージまたはチップに一緒に統合され得ることが理解されるであろう。送信/受信要素122は、無線インターフェース115/116/117を介して基地局例えば、基地局114aに信号を送信するか、または基地局例えば、基地局114aから信号を受信するように構成され得る。例えば、一実施形態において、送信/受信要素122は、RF信号を送信および/または受信するように構成されたアンテナである可能性がある。別の実施形態において、送信/受信要素122は、例えば、IR、UV、または可視光信号を送信および/または受信するように構成されたエミッタ/ディテクタである可能性がある。さらに別の実施形態において、送信/受信要素122は、RF信号および光信号の両方を送信および受信するように構成され得る。送信/受信要素122は、無線信号の任意の組み合わせを送信および/または受信するように構成され得ることが理解されるであろう。加えて、送信/受信要素122は、図1Bにおいて単一の要素として示されているが、WTRU102は、任意の数の送信/受信要素122を含み得る。より具体的には、WTRU102は、MIMO技術を使用することができる。したがって、一実施形態において、WTRU102は、無線インターフェース115/116/117を介して無線信号を送信および受信するために2つ以上の送信/受信要素122例えば、複数のアンテナを含み得る。トランシーバ120は、送信/受信要素122によって送信されることになる信号を変調し、送信/受信要素122によって受信される信号を復調するように構成され得る。上述のように、WTRU102は、マルチモード能力を有する可能性がある。したがって、トランシーバ120は、WTRU102が例えばUTRAおよびIEEE802.11などの複数のRATを介して通信することを可能にするための複数のトランシーバを含み得る。WTRU102のプロセッサ118は、スピーカー/マイクロホン124、キーパッド126、および/またはディスプレイ/タッチパッド128例えば、液晶ディスプレイLCDディスプレイユニットまたは有機発光ダイオードOLEDディスプレイユニットに結合される可能性があり、それらからユーザ入力データを受信する可能性がある。プロセッサ118は、スピーカー/マイクロホン124、キーパッド126、および/またはディスプレイ/タッチパッド128にユーザデータを出力することもできる。さらに、プロセッサ118は、取り外し不可能なメモリ130および/または取り外し可能なメモリ132などの任意の種類の好適なメモリからの情報にアクセスし、それらのメモリにデータを記憶することができる。取り外し不可能なメモリ130は、ランダムアクセスメモリRAM、読み出し専用メモリROM、ハードディスク、または任意のその他の種類のメモリストレージデバイスを含み得る。取り外し可能なメモリ132は、加入者識別モジュールSIMカード、メモリスティック、セキュアデジタルSDメモリカードなどを含み得る。その他の実施形態において、プロセッサ118は、サーバまたはホームコンピュータ図示せずなどの、WTRU102に物理的に置かれていないメモリからの情報にアクセスし、そのメモリにデータを記憶することができる。プロセッサ118は、電源134から電力を受け取ることができ、WTRU102内のその他のコンポーネントに電力を分配し、および/またはその電力を制御するように構成され得る。電源134は、WTRU102に給電するための任意の好適なデバイスである可能性がある。例えば、電源134は、1つまたは複数の乾電池例えば、ニッケルカドミウムNiCd、ニッケル亜鉛NiZn、ニッケル水素NiMH、リチウムイオンLi-ionなど、太陽電池、燃料電池などを含み得る。プロセッサ118は、GPSチップセット136にも結合される可能性があり、GPSチップセット136は、WTRU102の現在位置に関する位置情報例えば、経度および緯度を提供するように構成され得る。GPSチップセット136からの情報に加えて、またはGPSチップセット136からの情報の代わりに、WTRU102は、基地局例えば、基地局114a、114bから無線インターフェース115/116/117を介して位置情報を受信し、および/または2つ以上の近隣の基地局から受信されている信号のタイミングに基づいてそのWTRU102の位置を判定することができる。WTRU102は、実施形態に準拠したまま、任意の好適な位置判定方法によって位置情報を取得することができることが理解されるであろう。プロセッサ118は、その他の周辺機器138にさらに結合される可能性があり、その他の周辺機器138は、追加的な特徴、機能、および/または有線もしくは無線接続を提供する1つまたは複数のソフトウェアおよび/またはハードウェアモジュールを含み得る。例えば、周辺機器138は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ写真または動画用、USBuniversalserialbusポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Bluetooth登録商標モジュール、FMfrequencymodulatedラジオユニット、デジタル音楽プレーヤー、メディアプレーヤー、ビデオゲームプレーヤーモジュール、インターネットブラウザなどを含み得る。図1Cは、一実施形態によるRAN103およびコアネットワーク106のシステム図である。上述のように、RAN103は、無線インターフェース115を介してWRTU102a、102b、102cと通信するためにUTRA無線技術を使用する可能性がある。RAN103は、コアネットワーク106とも通信している可能性がある。図1Cに示されるように、RAN103はNode-B140a、140b、140cを含む可能性があり、Node-B140a、140b、140cは、無線インターフェース115を介してWTRU102a、102b、102cと通信するための1つまたは複数のトランシーバをそれぞれが含み得る。Node-B140a、140b、140cは、RAN103内の特定のセル図示せずにそれぞれが関連付けられ得る。RAN103は、RNC142a、142bも含み得る。RAN103は、実施形態に準拠したまま、任意の数のNode-BおよびRNCを含み得ることが理解されるであろう。図1Cに示されるように、Node-B140a、140bは、RNC142aと通信している可能性がある。加えて、Node-B140cは、RNC142bと通信している可能性がある。Node-B140a、140b、140cは、Iubインターフェースを介してそれぞれのRNC142a、142bと通信することができる。RNC142a、142bは、Iurインターフェースを介して互いに通信している可能性がある。RNC142a、142bのそれぞれは、そのRNCが接続されているそれぞれのNode-B140a、140b、140cを制御するように構成され得る。さらに、RNC142a、142bのそれぞれは、アウターループ電力制御、負荷制御、アドミッション制御、パケットのスケジューリング、ハンドオーバー制御、マクロダイバーシティmacrodiversity、セキュリティ機能、データの暗号化などのその他の機能を実行またはサポートするように構成され得る。図1Cに示されるコアネットワーク106は、MGWmediagateway144、MSCmobileswitchingcenter146、SGSNservingGPRSsupportnode148、および/またはGGSNgatewayGPRSsupportnode150を含み得る。上述の要素のそれぞれはコアネットワーク106の一部として示されているが、これらの要素のうちの任意の要素は、コアネットワークの運用者以外の主体によって所有および/または運用される可能性があることが理解されるであろう。RAN103のRNC142aは、IuCSインターフェースを介してコアネットワーク106のMSC146に接続され得る。MSC146は、MGW144に接続され得る。MSC146およびMGW144は、WTRU102a、102b、102cがPSTN108などの回線交換ネットワークにアクセスできるようにして、WTRU102a、102b、102cと従来の固定電話回線通信デバイスとの間の通信を容易にすることができる。RAN103のRNC142aは、IuPSインターフェースを介してコアネットワーク106のSGSN148にも接続され得る。SGSN148は、GGSN150に接続され得る。SGSN148およびGGSN150は、WTRU102a、102b、102cがインターネット110などのパケット交換ネットワークにアクセスできるようにして、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。上述のように、コアネットワーク106は、その他のサービスプロバイダによって所有および/または運用されるその他の有線または無線ネットワークを含み得るネットワーク112にも接続され得る。図1Dは、一実施形態によるRAN104およびコアネットワーク107のシステム図である。上述のように、RAN104は、無線インターフェース116を介してWRTU102a、102b、102cと通信するためにE-UTRA無線技術を使用する可能性がある。RAN104は、コアネットワーク107とも通信している可能性がある。RAN104はeNode-B160a、160b、160cを含む可能性があるが、RAN104は、実施形態に準拠したまま、任意の数のeNode-Bを含み得ることが理解されるであろう。eNode-B160a、160b、160cは、無線インターフェース116を介してWTRU102a、102b、102cと通信するための1つまたは複数のトランシーバをそれぞれが含み得る。一実施形態において、eNode-B160a、160b、160cは、MIMO技術を実装することができる。したがって、eNode-B160aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、WTRU102aから無線信号を受信することができる。eNode-B160a、160b、160cのそれぞれは、特定のセル図示せずに関連付けられる可能性があり、無線リソース管理の決定、ハンドオーバーの決定、アップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成され得る。図1Dに示されるように、eNode-B160a、160b、160cは、X2インターフェースを介して互いに通信することができる。図1Dに示されるコアネットワーク107は、モビリティ管理ゲートウェイmobilitymanagementgatewayMME162、サービングゲートウェイ164、およびパケットデータネットワークPDNゲートウェイ166を含み得る。上述の要素のそれぞれはコアネットワーク107の一部として示されているが、これらの要素のうちの任意の要素は、コアネットワークの運用者以外の主体によって所有および/または運用される可能性があることが理解されるであろう。MME162は、S1インターフェースを介してRAN104内のeNode-B160a、160b、160cのそれぞれに接続される可能性があり、制御ノードとして働くことができる。例えば、MME162は、WTRU102a、102b、102cのユーザの認証、ベアラのアクティブ化/非アクティブ化、WTRU102a、102b、102cの最初のアタッチ中の特定のサービングゲートウェイの選択などの役割を担う可能性がある。MME162は、RAN104と、GSM登録商標またはWCDMA登録商標などのその他の無線技術を使用するその他のRAN図示せずとの間の切り替えのための制御プレーンの機能も提供することができる。サービングゲートウェイ164は、S1インターフェースを介してRAN104内のeNode-B160a、160b、160cのそれぞれに接続され得る。概して、サービングゲートウェイ164は、WTRU102a、102b、102cに/からユーザのデータパケットをルーティングおよび転送することができる。サービングゲートウェイ164は、eNodeB間のハンドオーバー中にユーザプレーンのアンカーになること、ダウンリンクのデータがWTRU102a、102b、102cに利用可能であるときにページングを引き起こすこと、WTRU102a、102b、102cのコンテキストを管理および記憶することなどのその他の機能も実行することができる。サービングゲートウェイ164は、PDNゲートウェイ166にも接続される可能性があり、PDNゲートウェイ166は、WTRU102a、102b、102cがインターネット110などのパケット交換ネットワークにアクセスできるようにして、WTRU102a、102b、102cとIP対応デバイスの間の通信を容易にすることができる。コアネットワーク107は、その他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク107は、WTRU102a、102b、102cがPSTN108などの回線交換ネットワークにアクセスできるようにして、WTRU102a、102b、102cと従来の固定電話回線通信デバイスとの間の通信を容易にすることができる。例えば、コアネットワーク107は、コアネットワーク107とPSTN108の間のインターフェースとして働くIPゲートウェイ例えば、IPマルチメディアサブシステムIMSサーバを含むことができるか、またはそのようなIPゲートウェイと通信することができる。さらに、コアネットワーク107は、WTRU102a、102b、102cが、その他のサービスプロバイダによって所有および/または運用されるその他の有線または無線ネットワークを含み得るネットワーク112にアクセスできるようにすることができる。図1Eは、一実施形態によるRAN105およびコアネットワーク109のシステム図である。RAN105は、IEEE802.16無線技術を使用して無線インターフェース117を介してWTRU102a、102b、102cと通信するASNaccessservicenetworkである可能性がある。以下でさらに検討されるように、WTRU102a、102b、102c、RAN105、およびコアネットワーク109の異なる機能エンティティ間の通信リンクは、リファレンスポイントreferencepointとして定義され得る。図1Eに示されたように、RAN105は、基地局180a、180b、180c、およびASNゲートウェイ182を含む可能性があるが、RAN105は、実施形態に準拠したまま任意の数の基地局およびASNゲートウェイを含み得ることが理解されるであろう。基地局180a、180b、180cは、RAN105の特定のセル図示せずにそれぞれ関連付けられる可能性があり、無線インターフェース117を介してWTRU102a、102b、102cと通信するための1つまたは複数のトランシーバをそれぞれが含み得る。一実施形態において、基地局180a、180b、180cは、MIMO技術を実装することができる。したがって、基地局180aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、WTRU102aから無線信号を受信することができる。基地局180a、180b、180cは、ハンドオフのトリガ、トンネルの確立、無線リソース管理、トラフィックの分類、サービス品質QoSポリシーの施行などのモビリティ管理機能を提供することもできる。ASNゲートウェイ182は、トラフィックの集約点として働くことができ、ページング、加入者プロファイルのキャッシュ、コアネットワーク109へのルーティングなどを担うことができる。WTRU102a、102b、102cとRAN105の間の無線インターフェース117は、IEEE802.16の仕様を実装するR1リファレンスポイントとして定義され得る。加えて、WTRU102a、102b、102cのそれぞれは、コアネットワーク109との論理インターフェース図示せずを確立することができる。WTRU102a、102b、102cとコアネットワーク109との間の論理インターフェースは、認証、認可、IPホストの構成管理、および/またはモビリティ管理のために使用され得るR2リファレンスポイントとして定義され得る。基地局180a、180b、180cのそれぞれの間の通信リンクは、WTRUのハンドオーバー、および基地局間のデータの転送を容易にするためのプロトコルを含むR8リファレンスポイントとして定義され得る。基地局180a、180b、180cとASNゲートウェイ182との間の通信リンクは、R6リファレンスポイントとして定義され得る。R6リファレンスポイントは、WTRU102a、102b、102cのそれぞれに関連するモビリティイベントmobilityeventに基づいてモビリティ管理を容易にするためのプロトコルを含み得る。図1Eに示されたように、RAN105は、コアネットワーク109に接続され得る。RAN105とコアネットワーク109との間の通信リンクは、例えばデータ転送およびモビリティ管理能力を助けるためのプロトコルを含むR3リファレンスポイントとして定義され得る。コアネットワーク109は、モバイルIPホームエージェントMIP-HA184、認証、認可、アカウンティングAAAサーバ186、およびゲートウェイ188を含み得る。上述の要素のそれぞれはコアネットワーク109の一部として示されているが、これらの要素のうちの任意の要素は、コアネットワークの運用者以外の主体によって所有および/または運用される可能性があることが理解されるであろう。MIP-HAは、IPアドレスの管理を担うことができ、WTRU102a、102b、102cが異なるASNおよび/または異なるコアネットワークの間をローミングすることを可能にすることができる。MIP-HA184は、WTRU102a、102b、102cがインターネット110などのパケット交換ネットワークにアクセスできるようにして、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。AAAサーバ186は、ユーザの認証およびユーザサービスのサポートを担うことができる。ゲートウェイ188は、その他のネットワークとの網間接続を容易にすることができる。例えば、ゲートウェイ188は、WTRU102a、102b、102cがPSTN108などの回線交換ネットワークにアクセスできるようにして、WTRU102a、102b、102cと従来の固定電話回線通信デバイスとの間の通信を容易にすることができる。さらに、ゲートウェイ188は、WTRU102a、102b、102cが、その他のサービスプロバイダによって所有および/または運用されるその他の有線または無線ネットワークを含み得るネットワーク112にアクセスできるようにすることができる。図1Eには示されていないが、RAN105は、その他のASNに接続される可能性があり、コアネットワーク109は、その他のコアネットワークに接続される可能性があることが理解されるであろう。RAN105とその他のASNとの間の通信リンクは、RAN105とその他のASNとの間でWTRU102a、102b、102cのモビリティを調整するためのプロトコルを含み得るR4リファレンスポイントとして定義され得る。コアネットワーク109とその他のコアネットワークの間との通信リンクは、ホームコアネットワークと滞在先のコアネットワークとの間の網間接続を容易にするためのプロトコルを含み得るR5リファレンスとして定義され得る。多接続とは、2つ以上のネットワーク接続を同時に維持するユーザ機器UEを指す可能性がある。異なる種類のネットワーク接続は、広帯域幅、低時間遅延、および高セキュリティなどの異なるユーザエクスペリエンスをユーザに提供する可能性がある。多接続は、異なる場所および時間からネットワークにアクセスするためにアクセス技術を連携させ、複数のアクセス技術の異なる利点を生かし、より良いユーザエクスペリエンスを提供するのに役立つことができる。接続は、例えば、2つ以上のピアNエンティティpeer-N-entity間のデータの転送のために確立される関連付けである可能性がある。関連付けは、ピアNエンティティを直下のレイヤのN-1エンティティN-1-entityと一緒にバインドする可能性がある。セッションは、例えば、テキスト形式の情報をリアルタイムで交換することを目的とする2つ以上のユーザ端末間の論理的な接続である可能性がある。所与のインターフェースにおけるIPフローは、所与の分類に当てはまるIPパケットの組がそのインターフェースに現れることとして定義される可能性がある。IPフローは、単一のアプリケーションのセッションからのパケットを含む可能性がある。IPフローは、いくつかのアプリケーションのセッションからの組み合わされたトラフィックを含む集まりである可能性がある。分類が別々のまたは重なり合う異なる下位分類に細分化されるとき、異なるIPサブフローが、対応するIPフローにおいて認識され得る。アプリケーションは、APIインターフェースによってサポート可能な1つまたは複数のサービスによってサポートされ得る付加価値の付いた機能を提供する構造化された1組の能力である可能性がある。多接続は、例えば、同時に受信および/または送信する2つ以上のピアNエンティティ間のいくつかの接続の集合である可能性がある。接続は、上位レイヤのエンティティにサービスを提供するために調整され得る。多接続通信においては、少なくとも1つのUEが、多接続のUEであるように要求される可能性がある。サービスの分解servicedecompositionは、1つのサービスをいくつかのサービスコンポーネントservicecomponentに分解することである可能性がある。元のサービスのロジックが、エンドユーザおよびアプリケーションに対して透過的に再構築され得る。メディアフローmediaflowは、送信者から関心のある受信者に送信されているメディアのストリームである可能性がある。多接続の能力は、多くの場合、例えば、ネットワークの負荷を分散すること、加入者により広い帯域幅を提供すること、サービスへの異なる利用可能な同時アクセスを利用することによってより適正にサービスに課金すること、同時に2つ以上のネットワークを訪れるときにユーザをサポートすることなどのために加入者によって必要とされる可能性がある。テレビ会議を例として用いると、音声が、回線交換ネットワークによるリアルタイムのサービスを確約するために2G/3Gネットワークによって送信され得る一方、映像コンポーネントは、より大きな帯域幅を有するWi-Fiによって送信され得る。多接続ネットワークにおいて、UEおよびネットワークは、アプリケーションに提供されるいくつかの同時アクセスによって生じるインタラクションと、それぞれに関する関連するQoSとを知っている可能性がある。組み合わせのまたは結果として得られるQoSは、特定のサービスに関連する各QoSの組み合わせを表す可能性がある。QoSを指定することは、優先度によるアプローチを用いて実施され得る。アプリケーションは、そのアプリケーションが必要とするデータレートまたはレイテンシを知らない可能性があるが、アプリケーションは、そのアプリケーションにとってどれがより重要であるか例えば、どれがより高い優先度を有するかをおそらく知っている可能性がある。アプリケーションがそのアプリケーションが必要とするサービス品質について偽りがない例えば、最大のレート未満のレートまたは最小のレイテンシを超えるレイテンシを要求しようとすることへの誘因はほとんどない可能性があるが、そのアプリケーションがどれがより高い優先度を有すると見なすかをアプリケーションが示そうとする誘因は存在する可能性がある。偽りがあるアプリケーション例えば、そのアプリケーションがデータレートを重視するよりもレイテンシを重視するということをその反対が正しいときに示すアプリケーションは、例えば、多接続プロトコルが使用されるときプロトコルから質の低いサービスを受ける危険を冒す可能性がある。追加的なパラメータが利用される可能性があるが、一例において、2つのパラメータ、データレートおよびレイテンシを有するQoS空間QoSspaceを考える。多接続エンドツーエンドプロトコルは、そのプロトコルに2つの接続を用意している可能性があり、そのプロトコルのアプリケーションインターフェースの一部として、どちらのパラメータ-データレートまたはレイテンシ-がアプリケーションにとってより高い優先度を有するかを示す例えば、優先されるリソースを示すようにアプリケーションに要求する可能性がある。例示的な多接続プロトコルは、以下のように動作し得る。アプリケーションからの各データパケットに関して、プロトコルは、どの接続を介してデータパケットを送信すべきかを決定する可能性がある。例えば、プロトコルは、接続1、接続2、またはそれらの両方を介してデータパケットを送信する可能性がある。パケットが両方の接続を介して送信される場合、2つの接続のうちのいずれか一方を介した肯定応答ACKがあれば、パケットが届けられたと見なすのに十分である可能性がある。アプリケーションからデータを受信すると、多接続プロトコルは、そのデータをどこに送信すべきかを決定する可能性がある。アプリケーションがそのアプリケーションがレイテンシよりもデータレートをより重視することを示した場合、プロトコルは、異なるデータを接続2を介して送信しながら、一部のデータを接続1を介して送信する可能性がある。達成される結果として得られるスループットのレートは、両方の接続を介して利用可能なレートの合計である可能性がある。アプリケーションがデータレートよりもレイテンシをより重視する場合、ポリシーが、両方の接続を介して重複するデータを送信する可能性がある。各パケットに関するレイテンシは、各接続におけるそのパケットに関するレイテンシのうちで最小のレイテンシである可能性がある例えば、レイテンシが最小化される。そのようなアプローチは、スループットが2つの接続を介したスループットのうちの最小のスループットとなり得るという犠牲を招く可能性がある。上記の例のように、データレートおよびレイテンシは、潜在的に対立するQoSの基準である可能性がある。偽りがある振る舞いはアプリケーションにとって不利益がある可能性があるので、アプリケーションがどちらのパラメータをより重視するかを示すようにアプリケーションに強制することによって、多接続プロトコルは、偽りがないようにアプリケーションに強制する可能性がある。QoSインターフェースQoSinterfaceを介して提供される情報が、多接続プロトコルによって利用できる可能性がある例えば、その情報は、送信パラメータをどのように優先順位付けするべきかに関する情報を多接続プロトコルに与える可能性がある。QoSは、多くのパラメータを含み得る。例えば、QoSは、以下、すなわち、データレート/スループット、レイテンシ、ジッタ、送達の保証DeliveryGuarantee、コスト、電力消費、または例えば、プライバシー、完全性、送達の確約DeliveryAssuranceなどにさらに分けられる可能性があるセキュリティのうちの1つまたは複数を含み得る。アプリケーション以外のその他のアクターが、通信エコシステムcommunicationecosystemにおいて利害関係を有する可能性がある。例えば、オペレーティングシステムOSは、電力消費の制約についてアプリケーションよりも大きな影響力を持つ可能性があり、リンクのコストの重要性linkcostimportanceは、オペレータおよび/またはユーザのニーズによって左右される可能性がある、等々である。図2は、多数のユースケースでQoS選択手順に影響を与える可能性がある例示的なアクターを示す図である。図2は、QoSサブシステムが含み得るさまざまなコンポーネントの高レベルの図を含む。優先度によるインターフェースpreferentialinterfaceは、アプリケーションとの1つまたは複数のインターフェースを含み得る。例として、アプリケーションとの単一のインターフェースを考える。インターフェースは、アプリケーションに露出される1組の利用可能なパラメータを含み得る。アプリケーションは、その組が何であるかを知らされる可能性がある。その組は、本明細書において開示されるパラメータのうちの1つまたは複数などの1つまたは複数のパラメータを含み得る。例として、{コスト,レイテンシ,スループット,電力消費}が、1組のQoSパラメータである可能性がある。アプリケーションは、重要性の順序でパラメータをランク付けするように求められる可能性がある。例えば、最大限可能なスループットを必要とし、レイテンシはそれよりも重視せず、コストはそれよりもさらに重視せず、電力消費は最も重視しないアプリケーションは、以下の順序付けられた組、すなわち、{スループット,レイテンシ,コスト,電力消費}を接続プロトコルに与える可能性がある。アプリケーションは、パラメータの一部をどうすればよいか分からない可能性がある。例えば、ラップトップで実行されるアプリケーションが、電源の制約または無線接続の性質を知らない可能性がある。この例において、アプリケーションは、電力消費またはコストについてどうすればよいか分からない可能性がある。インターフェースのコンポーネントが、定義され得る。例は、順序付けられたプリファレンスリストorderedpreferencelistOPLおよび例えば、アプリケーションがランク付けすることができないパラメータに関する情報なしリストnoinformationlistNILを含み得る。例を続けると、アプリケーションは、OPL={スループット,レイテンシ}およびNIL={コスト,電力消費}を与える可能性がある。NILリストは、例えば、OPLにないパラメータはNILにあるものと設計が仮定する場合は、明示的ではなく暗黙的である可能性がある。プリファレンスは、多接続プロトコルによって提供され得る定量的な性能に依存する可能性がある。例えば、アプリケーションは、最小限のレイテンシの要件が満たされるものとして、レイテンシよりもスループットをより重視する可能性がある。この種類および同様の種類の動作をサポートするために、インターフェースは、フィードバックによって改良され得る。プロトコルは、OPL内のパラメータに対する定量的な性能に関するアプリケーションのフィードバックを提供する可能性がある。アプリケーションは、いつでもOPLおよびNILの設定を変更し、そのアプリケーションのデータがどのように処理されるかを調整することができる。アプリケーションは、どのデータにどのQoSが適用されるべきかを特定する必要がある可能性がある。例として、ウェブブラウザは、以下の種類のトラフィック、すなわち、HTTPセッションネゴシエーション、通常のウェブページデータ、それ自体がさまざまなレイヤを有する可能性がある埋め込まれたオーディオおよびビデオストリーム、セキュアコンポーネントsecurecomponentなどのうちの1つまたは複数を生成する可能性がある。アプリケーション例えば、進化型のウェブブラウザは、そのようなデータを分けまたは接続プロトコルによって理解され得る方法でそのデータをラベル付けし、そのデータのサブフローのそれぞれに関してQoSインターフェースを設定する可能性がある。これは、既存のインターフェースの構成を発展させることを必要とする可能性がある。例えば、既存のL4プロトコルTCP、UDPとのインターフェースは、ポートの概念を用いる可能性がある。アプリケーションは、L4プロトコルを用いてポートを開くことができ、L4プロトコルは、ポートの概念を用いて異なるアプリケーションからのデータを分けることができる。アプリケーションは、複数のポートを開くことができる。コネクション型プロトコル、例えば、TCPは、単一のポートのデータを同期させておく-多くのサブフローにとって望ましい可能性がある特徴-ために使用され得る。異なるポートを使用することによって、この能力は失われる可能性がある。ポートの概念は、アプリケーションを一意に特定するのに役立つ可能性がある。例えば、現在は、3つ組み<L4プロトコル概してTCP/UDP,ポート番号,送信先IP>[さらに送信元IP]が、アプリケーションを一意に特定するために使用される可能性がある。異なるアプリケーションが、同じポートを用いて異なる送信先と通信する可能性がある。同じポート番号が、同じ送信先の異なるプロトコル例えば、UDPまたはTCPに対して使用される可能性がある。同じ<L4プロトコル,ポート番号,送信先IP>の使用は明確に禁じられていない可能性があるが、そのような使用は、TCP/IPプロトコルスタックを実装し得るオペレーティングシステムがアプリケーションによってデータを特定することを難しくする可能性があるので避けられる可能性がある。上述の内容に対する変更がなされる可能性がある。異なるサブフローが、それらのサブフローを異なる送信元IPアドレスにバインドすることによって異なるインターフェースにマッピングされ得るので、送信元IPが、フローまたはサブフローの識別子の極めて重要な部分になる可能性がある。フローIDの概念が、必要とされる可能性がある。ポートの概念は、サブポートの概念を含み得る。各サブポートが、アプリケーションのサブフローに関連付けられる可能性があり、異なるQoSの設定が、各サブフローに対して定義される可能性がある。別の例として、IPプロトコルがアプリケーションの役割をするL2接続プロトコルを考える。この場合、IPプロトコルスタックが、異なるQoSのニーズを異なるデータグラムに関連付けることができる例えば、この情報が、独自の方法でスタック中を伝播させられる可能性があると想定され得る。例えば、802.11eの拡張を経た802.11などの一部のMACレイヤは、各キューに異なるQoSが関連付けられた異なるキューにデータを入れることを提供する可能性がある。そのとき、QoSインターフェースを介して提供される情報は、各データグラムがどのキューに入れられるべきかを判定するためにMACプロトコルによって使用され得る。複数のアクターとのインターフェースが、提供される可能性がある例えば、アプリケーション、オペレーティングシステムOS、ユーザ、オペレータ。接続/ポートは、例えば発展型のソケット呼び出しを介してアプリケーションにより開かれる可能性がある。これは、アプリケーションが、例えば、OPL/NILによってかまたは別の実装によってかのどちらかでQoSを指定することを可能にすることができる。ポートを開けるプロセスは、その他のアクターがそれらのアクターの入力を与えるための直接的な手段を提供しない可能性がある。これは、例えば、これらのアクターがポートごとの入力を与えたいのか、または入力が与えられて以降に開けられたすべてのポートに、その入力が有効である限り適用され得るグローバルな入力を与えたいのかに応じて実現され得る。アプリケーションでないアクターによるグローバルなQoSのプロビジョニングの場合、アクター例えば、OS、ユーザ、オペレータは、QoS管理エンティティに、そのアクターが関心のあるパラメータに関する情報を与える可能性がある。情報は、アプリケーションによって与えられるのと同様の形態例えば、OPL/NILで与えられる可能性がある。内容は、異なる可能性がある。情報は、いかなる特定のポートにも関連付けられない可能性があり、ソケットが開かれるときに与えられない可能性がある。情報は、いつでも与えられ得る。この情報が与えられる方法は、アクターによって異なる可能性がある。例は、以下のうちの1つまたは複数を含み得る。オペレーティングシステムOSの情報は、QoSエージェントおよびOSからAPIを介して与えられる可能性がある。そのAPIは、そのAPIがソケット呼び出しを含まない可能性があるので、アプリケーションAPIとは異なる可能性がある。ユーザの情報は、ユーザインターフェースを介して与えられる可能性がある。オペレータの情報は、オペレータのポリシーを通じてデバイスに与えられる可能性があり、次に、デバイス管理エンティティ例えば、OMADMエンティティが、そのオペレータのポリシーを、QoSエージェントがデバイス管理エンティティに提供するAPIを介してそのQoSエージェントに渡す可能性がある。アプリケーションごとのプロビジョニングは、ポートを開けること例えば、ソケット呼び出しに結びつけられ得る。アプリケーションでないアクターは、ソケットが開かれていることが直接分からない可能性がある。そのようなアクターによるアプリケーションごとのプロビジョニングが可能にされる場合、QoSエージェントが、アクターが情報を与えることをトリガする必要がある可能性がある。トリガは、ポーリング呼び出しによって実現される可能性があり-例えば、各アクターとのAPIが、QoSエージェントがそのような情報に関してアクターにポーリングするための能力を含む可能性がある。例えば、QoSエージェントは、特定のアプリケーションがポートを開くことを要求するときに、そのアプリケーションに関するOSの電力のプリファレンスについてOSにポーリングする可能性がある。ユーザおよびオペレータの入力の場合、ポーリングプロセスは、追加的な動作を含み得る。ユーザに関して、ポーリングプロセスは、特定のデータを入力するようにユーザに要求するユーザインターフェースの動作例えば、アプリケーションがインターネットアクセスを許されるべきか、または許されるべきでないかをユーザに尋ねるのと同様のプロセスを開始する必要がある可能性がある。オペレータの場合、デバイス管理エンティティが、そのような情報に関してポーリングされる可能性がある。ローカルに記憶されたポリシー内でその情報が利用可能でない場合、デバイス管理エンティティは、その情報を得るためにオペレータと通信する必要がある可能性がある。優先度によるQoSの指定のためのアプローチは、それぞれのQoSのカテゴリーに関する記述的なプロパティdescriptivepropertyを使用する可能性がある。これは、それぞれのプロパティに関するそれぞれの値が直交するorthogonal例えば、アプリケーションまたはアプリケーションでないアクターが偽りがないままでいる必要がある可能性がある方法で実装され得る。例えば、1つのQoSのプロパティはスループットである可能性があり、そのプロパティは、例えば、表1に示されるように3つの値を用いて指定される可能性がある。電力のプロパティが、表2に示されるように指定される可能性がある。レイテンシのプロパティが、表3に示されるように指定される可能性がある。その他のプロパティが、同様にして指定される可能性がある。図3は、QoSサブシステムの例示的なアーキテクチャを示す。図3は、アプリケーションと接続プロトコルとの間のアーキテクチャを含む。図3は、システム全体の中にQoSのAPIおよびエージェントを含む。図3に示されるように、QoSサブシステムは、以下のうちの1つまたは複数を含み得る。QoSサブシステムは、デバイスに知られている可能性がある無線アクセス技術RATのリストおよびそれらのRATの特性を記憶することができる無線アクセス技術RATのデータベースを含み得る。QoSサブシステムは、QoSのニーズおよびそれらのニーズがどのようにして満たされ得るかの分析を実行することができるQoS分析モジュールを含み得る。QoSのAPIおよびQoSスニファによって与えられる入力に加えて、QoS分析モジュールは、アクティブな接続、アクティブ化され得る接続についての情報、無線環境とネットワークの両方からのセンシング情報、およびその他の潜在的な入力などを含むその他の入力を取得する可能性がある。各接続に関するQoSパラメータについての決定が、QoS分析モジュールによってなされ得る。QoSサブシステムは、QoS分析モジュールの意思決定を制御する1組の規則およびリソース割り当て/帯域幅プロセッサモデルResourceAllocation/BandwidthProcessormodelを含み得るポリシーデータベースを含む可能性がある。ポリシーは、デバイスに組み込まれ、プライマリネットワークの動作、ユーザ、OSなどによって提供される可能性がある。QoSサブシステムは、エラーイベントに反応することができるアラームプロセッサを含み得る。QoSサブシステムは、特定のアプリケーションから受信されたパケットを、正常な状態でQoS分析モジュールによって指示され、エラー状態の間にアラームプロセッサによって指示される接続に配信することができるリソース割り当て/帯域幅管理アルゴリズムを含み得る。QoSスニファ機能QSFは、QoSインターフェースを、アプリケーション、例えば、これを自身で行うことができない可能性があるアプリケーションの代わりに実行することができる。そのようにするために、QSFは、どの種類のアプリケーションからデータストリームが来ているのか、およびどのQoSをそのアプリケーションが必要とするかまたはおそらく必要とする可能性があるのかを判定する必要がある可能性がある。これは、以下を含み得る。QSFは、アプリケーションが送信しているデータに基づいてアプリケーションの種類を推測することを試みる可能性がある。これは、ディープパケットインスペクションDPIを用いて、例えば、DPIアルゴリズムによって実現され得る。DPIアルゴリズムは、使用されているトランスポートプロトコルTCPまたはUDPのポート、アプリケーションプロトコルのヘッダ、およびその他の情報などの情報に関してデータを検査することができる。これは、QSFが、使用されているアプリケーションプロトコル例えば、FTP、HTTP、RTSPなどの性質を判定することを可能にすることができる。アプリケーションの種類は、使用されているポートから推測され得る例えば、ウェブブラウザのセッションは、通常、TCPポート80およびHTTPプロトコルを用いて開始され得る。DPIアルゴリズムは、それぞれのアプリケーションのフローのサブフローを分析して、異なるQoSを必要とする可能性がある異なる種類のサブフローをさらに特定することができる。例えば、現在のHTTPのフローは、とりわけ、ウェブページデータ、ビデオストリーム、およびセキュアコンポーネントを含み得る。これらのそれぞれは、異なるQoSの扱いを必要とする可能性がある。DPIの実施は、HTTPのウェブブラウザのセッション内のこれらのサブフローのそれぞれに関する情報を運ぶデータパケットを特定することができる可能性がある。DPIは、それぞれのアプリケーション/データのサブフローを特定するために使用され得る。QSFは、この情報を用いて、サブフローの種類に基づいてQoSインターフェースを設定することができる。例えば、データのサブフローは、ピークスループットを最も重視すると想定される可能性があり、一方、インタラクティブな例えば、VoIPのサブフローは、レイテンシをより重視すると想定される可能性があり、httpsのサブフローは、セキュリティを最も重視すると想定される可能性がある。サブフローは、QSFによって分けられる可能性があり、QoSインターフェースは、それらのサブフローのそれぞれに対して設定される可能性がある。レガシーのアプリケーションに代わるQSFによるQoSの設定は、本明細書において説明されるように実行され得る。QoSインターフェースに関連して、QSFは、アプリケーションがNILの組に設定したQoSのプロパティに関する優先度を設定するために使用され得る。例えば、QSFは、それぞれの特定のアプリケーションが知らないデバイスの電力要件を知っている可能性がある。アプリケーションは、電力をNILの組に入れるが、QSFは、電力を適切な優先度でOPLに入れることによってこの設定を修正する可能性がある。QSFのための情報のソースは、デバイスのオペレーティングシステムである可能性がある。例えば、OSは、アプリケーションが知らない電力またはセキュリティの要件を知っている可能性がある。QSFのための情報のソースは、例えば、本明細書において開示されるようなユーザおよびオペレータの入力である可能性がある。コスト、電力、およびセキュリティの設定は、例えば、接続マネージャアプリケーションを通じてユーザによって入力され得る例である。QSFが提供し得る機能は、アプリケーションのニーズを発見するネゴシエータの機能である。この特徴は、本明細書において説明される優先度によるインターフェースに定量的なQoSの要素を加えるために使用され得る。例えば、アプリケーションが例えば、定量的なアドオンのインターフェースを通じてデータレートに関して特定の値を要求するものとする。QSF機能は、QoSインターフェースを介してその同じ値がレポートされることを可能にすることによって始まり、次いで、悪影響が観測されるまでその値を減らす例えば、データレートを絞り込む可能性がある。例えば、アプリケーションは、例えば図3に示されるようなその他の測定値をAPIを介してシグナリングする可能性があり、またはアプリケーションは、ストレスコンディションstresscondition、例えば、本明細書において説明される帯域幅の利用の監視によって発見される状態を示す可能性がある、等々である。場合によっては、アプリケーションの真のデータレートのニーズが、1つまたは複数のそのようなプロセスを用いて発見される可能性がある。より広くは、定量的なインターフェースのコンポーネントがQoSインターフェースの一部として利用可能である場合、QSFは、特定のQoSの観点例えば、データレート、レイテンシなどに関する真のニーズを徐々に絞り込むかまたは広げることによってインタラクティブに発見することをその後の潜在的な目的として、そのインターフェースのためにアプリケーションまたはOSの設定を傍受する可能性がある。そのようなアプローチは、例えば、把握される品質が、接続を維持することと引き替えに、利用可能な容量に基づいて犠牲にされる可能性がある、マルチレートオーディオまたはビデオコーデックと親和性がある可能性がある。絞り込みのアプローチは、アプリケーションの真のニーズを知るのが遅い可能性があり、非常に動的な変化に対応することができない可能性があり、および/または変動するデータレートを許容しない可能性がある一部のアプリケーションに関して問題を引き起こす可能性がある。アプリケーションと両立できる制御された例えば、低速な方法でデータレートを絞って調節することによってこれを緩和できる可能性があるが、これは、有効性を損なう可能性がある。帯域幅ステアリングbandwidthsteeringが、使用される可能性がある。帯域幅ステアリングは、以下のように使用される可能性がある。帯域幅の利用は、利用可能な帯域幅が利用されていることを判定するために監視される可能性がある。これは、例えば、物理レイヤの測定、MACキューの観測例えば、キューのサイズおよびキュー内のパケットの滞留時間、例えば、TCPの輻輳制御アルゴリズムにおけるネットワーク遅延の観測などを通じて行われ得る。デバイスが、帯域幅が不足するようになったことを検出するまたはそのデバイスの総データ出力を削減するようにネットワークオペレータによって指示される場合、そのデバイスは、以下のように動作する可能性がある。それぞれの既存のストリームに関して、ストリームのモメンタムstreammomentumが保存され得る。これは、現在実行されているアプリケーションが、何らかの最大値までの、そのアプリケーションが実際に使用している帯域幅を維持することを許される可能性があることを意味する。例えば、ビデオアプリケーションが4Mbpsを使用している場合、そのビデオアプリケーションは、例えば、4Mbpsが最大値未満であると仮定して4Mbpsのトラフィックを提供し続ける限り、そのような使用を継続することを許される可能性がある。残りの帯域幅は、QoS分析モジュールによって確立された優先度にしたがって新しいアプリケーションに割り当てられ得る。アプリケーションが帯域幅の使用を止める場合、そのアプリケーションは、そのアプリケーションのストリームのモメンタムを失う可能性があり、そのアプリケーションが使用していた帯域幅が、利用可能なプールに戻る可能性がある。そのアプリケーションは、すべてのその他のアプリケーションとともにその帯域幅をめぐる競争者になる可能性がある。接続をサポートするために、非ゼロの最小のレートが、アプリケーションに保証される可能性がある。プロセスは、緊急であるとされたアプリケーション例えば、健康、安全などのために割り込まれる可能性がある。これは、一部の帯域幅を取っておくこと、または割り当てられた帯域幅のわずかな部分が回収されることを可能にすることを必要とする例えば、4Mbpsを3.75Mbpsに減らす可能性がある。QoSの要件に基づく帯域幅ステアリングは、帯域幅を使用しているアプリケーションがその使用を維持することを可能にする可能性がある例えば、先着順サービスポリシーfirst-come,firstservedpolicyと同じようにして実施される可能性がある。ポリシーは、利用可能な十分な帯域幅がない状況を考慮する例えば、そのような状況のための規則の組を有する必要がある可能性がある。例えば、そのようなポリシーは、以下のうちの1つまたは複数を含み得る。新しいアプリケーションは、サービスを拒否される可能性がある。利用可能な帯域幅は、公平に分割され得る。例として例えば、上述の例を用いると、2つのストリームが、それぞれ2Mbpsを与えられる可能性がある。これは、削減されたレートが一方または両方のストリームを維持するために十分ではないという危険を冒す可能性があり、絞り込みのアプローチと同様の方法で認識される可能性がある。目的は、サービスの中断を避けるためにエラーの状況を認識し、それに反応することである可能性がある。例えば、新しいストリームは、ゆっくりと絞りを緩められる可能性がある一方、既存のストリームは、絞りをきつくされる。本明細書において説明される特徴を組み合わせるその他のポリシーの例も、実装され得る。サービス品質情報を決定するためのシステム、方法、および手法が、開示される。ユーザ機器UEなどのデバイスが、ポリシーを受信することができる。ポリシーは、セッションに関するアプリケーションの特定に関連するインスペクションのレベルを示す可能性がある。デバイスは、セッションに関連する情報を受信することができる。例えば、情報は、アプリケーションが提供する情報、パケットデータ、オペレーティングシステムが提供する情報などを含み得る。デバイスは、ポリシーによって示されたレベルで、受信された情報のインスペクションを実行することができる。デバイスは、セッションに関連するアプリケーションを特定するためにインスペクションを実行することができる。インスペクションの各レベルは、計算のインテンシティcomputationalintensityの異なるレベルに関連付けられる可能性がある。例えば、アプリケーションが提供する情報例えば、ソケット呼び出し、5つ組みのフローマーカーなどのインスペクションに関するインスペクションのレベルは、パケットインスペクションに関するインスペクションのレベルよりも計算のインテンシティが少ない可能性がある。インスペクションのより低いレベルが、より計算のインテンシティが少ないインスペクションを示す可能性がある一方、インスペクションのより高いレベルは、より計算のインテンシティが多いインスペクションを示す可能性がある。セッションのフロー、サブフローなどに関するインスペクションのレベルは、デバイスのリソースの使用を削減するためにポリシーによってより低いレベルに設定される可能性がある。例えば、ポリシーは、セッションに関してアプリケーションが特定されたときに、インスペクションのより低いレベルがそのセッションに関する情報に当てはまる可能性があることを示し得る。さらに、例として、ポリシーは、アプリケーションが特定のポートに関連付けられ得ることを示す可能性がある例えば、ポート21を使用するアプリケーションは、FTPとタグ付けされる可能性がある。そのような場合、ポリシーは、さらなるインスペクションが必要ないことを示す可能性がある。これは、以下で説明されるように、最上位レベルのインスペクションに関連する可能性がある。ポリシーが、インスペクションのレベルがインスペクションの第1のレベルであることを示す可能性があり、受信された情報が、アプリケーションが提供する情報例えば、ソケット呼び出し、5つ組みのフローマーカーなどを含む可能性がある。インスペクションの第1のレベルは、インスペクションが、アプリケーションが提供する情報を検査することを含むことを示す可能性がある。デバイスは、セッションに関連するアプリケーションを特定するためにインスペクションを実行することができる。例えば、アプリケーションが提供する情報は、ソケット呼び出しを含む可能性があり、インスペクションの第1のレベルは、ソケット呼び出しに関連するポートを特定されたポートと比較することを含む可能性がある。特定されたポートは、IANAInternetAssignedNumbersAuthorityによって特定されたポートなどの知られているポートである可能性がある。特定されたポートは、アプリケーションに関連付けられ得る。デバイスは、セッションに関連するアプリケーションを、特定されたポートに関連するアプリケーションとして特定することができる。ポリシーが、インスペクションのレベルがインスペクションの第2のレベルであることを示す可能性があり、受信された情報が、パケットデータを含む可能性がある。インスペクションの第2のレベルは、インスペクションがパケットデータのパケットインスペクションを含むことを示す可能性がある。インスペクションの第2のレベルは、パケットインスペクションの深さを示す可能性がある。異なる深さは、異なる計算のインテンシティのインスペクションを示す可能性がある。例えば、深さは、最上位レベルのプロトコルを特定/確認すること、プロトコルによって開かれたセッションを特定/確認すること、アプリケーションのサブフローを特定/確認することなどのためにパケットインスペクションを実行することを示す可能性がある。デバイスは、示されたレベルおよび深さでインスペクションを実行し、インスペクションに基づいてセッションに関連するアプリケーションを特定することができる。ポリシーは、インスペクションのレベルがインスペクションの第3のレベルであることを示す可能性がある。デバイスは、例えば、ポリシーに基づいてオペレーティングシステムに問い合わせを行う可能性がある。デバイスは、オペレーティングシステムが提供する情報を受信する可能性がある。受信された情報は、オペレーティングシステムが提供する情報を含む可能性がある。インスペクションの第3のレベルは、インスペクションが、オペレーティングシステムが提供する情報を検査することを含むことを示す可能性がある。デバイスは、そのインスペクションを実行し、インスペクションに基づいてセッションに関連するアプリケーションを特定することができる。ポリシーは、デフォルトのインスペクションレベルを含み得る。例えば、デフォルトのインスペクションレベルは、未知のフローに例えば、そのフローが未検証状態、検証済み状態などになるまで適用される可能性がある。ソケット例えば、インターネットソケットまたはネットワークソケットとは、インターネットなどのIPに基づくネットワーク中の双方向のプロセス間通信フローのエンドポイントを指す可能性がある。インターネットソケットという用語は、オペレーティングシステムによって提供され得るTCP/IPプロトコルスタックのためのアプリケーションプログラミングインターフェースAPIの名前として使用される可能性がある。インターネットソケットは、着信データパケットを、ローカルおよびリモートIPアドレスとポート番号との組み合わせに基づいて適切なアプリケーションのプロセスまたはスレッドに届けるためのメカニズムを提供することができる。ソケットは、オペレーティングシステムによって、通信するアプリケーションのプロセスまたはスレッドにマッピングされ得る。ソケットのアドレスは、アプリケーションプログラムのプロセスにマッピングされ得るIPアドレスおよびポートの、単一の識別情報への組み合わせを含む可能性があり、これは、電話接続の一端が電話番号と特定の内線番号との組み合わせとなる方法と同様である可能性がある。例えば、ウィンドウズ登録商標に基づく、Linux登録商標に基づく、UNIX登録商標に基づく一部のソケットは、BerkeleyまたはBSDソケットなどのAPIライブラリによって実装される可能性がある。カーネルによって提供されるソケットAPIは、BerkeleyソケットAPIに基づく可能性がある。表4の機能などの機能が、サポートされる可能性がある。ソケット関数呼び出しは、Linux登録商標に基づくAPIで使用されるソケット関数呼び出しである可能性があることに留意されたい。アプリケーションとは、例えば、ISOモジュールのL5以上で実行されるアプリケーションを指す可能性がある。アプリケーションは、ユーザによってそのユーザの端末上で見られるアプリケーションである可能性がある。例として、アプリケーションは、ウェブブラウザ、FTPアプリケーション、VoIPクライアント、Skypeアプリケーションなどである可能性がある。アプリケーションは、アプリケーションIDAIDによって一意に特定され得る。アプリケーションに関連するOSのプロセスIDが、アプリケーションIDとして使用される可能性がある。セッションとは、ソケットAPIを通じてアプリケーションによって開けられたL4トランスポートソケットを指す可能性がある。例示的なソケットは、UDP、TCP、MCTP、MNTPソケットなどを含み得る。セッションは、一意的なセッションIDによって一意に特定され得る。アプリケーションは、1つまたは複数のセッションを開く可能性がある。例えば、FTPアプリケーションは、2つのセッション-FTP制御セッションおよび別個のFTPデータセッション-を開く可能性がある。これらのセッションは、従属セッションと呼ばれる可能性がある。サブフローとは、多接続のL4トランスポートレイヤの概念を指す可能性がある。MCTPまたはMNTPの単一のセッションが、複数のサブフローを開く可能性がある。これらのサブフローは、それ自体としてはアプリケーションによって知られていない可能性があり、トランスポートレイヤによって処理される可能性がある。サブストリームは、アプリケーションの概念である可能性がある。これは、同じアプリケーションによって生成されたビットを区別するための方法である可能性がある。例えば、音声コーデックが、クラスA、B、およびCのサブストリームを生成する可能性がある。図4は、セッション、サブフロー、およびサブストリームをサポートする例示的なシステムを示す。図4の例において、アプリケーション1は、2つの従属セッション、TCPおよびMCTPを有する。MCTPのセッションは、2つのサブフローをサポートする。アプリケーション2は、1つのセッションおよび2つのサブフローを有し、アプリケーション2がVoIPアプリケーションであるとき、セッションで送信されるアプリケーションのデータストリームは、最終的に2つのサブフローに分割され得る例えば、クラスAおよびクラスBのビットに関する2つのサブストリームを含む。端末例えば、UEの通信能力が高まっているので、標準的なソケットインターフェースによって提供されるサービスは、不十分である可能性がある。標準的なソケットインターフェースは、そのソケットインターフェースのサービスのプリファレンスを示すこと例えば、サービス品質QoSの情報をプロトコルスタックに渡すことができない可能性がある。ソケットインターフェースは、QoS要求能力をアプリケーションに提供するように拡張され得る。例えば、ソケットインターフェースは、発展型の特徴を含むように拡張され得る。このアプローチは、そのような発展型のソケットインターフェースを利用するように実際に設計されたアプリケーションに適合する可能性がある。既存の例えば、レガシーのアプリケーションに関しては、アプリケーションが行うソケット呼び出しおよびアプリケーションが送受信するデータからそのアプリケーションが何を必要としているかを推定する必要がある可能性がある。これは、ディープパケットインスペクションDPIアルゴリズムを使用することによって実現され得る。そのようなプロトコルは、通常、計算のインテンシティが多い例えば、そのようなプロトコルは、電力消費および/またはスタックのスループットに影響を与える。DPIを使用せずに所望のレベルの特定を行うことができ、および/またはDPIの選択的な、ポリシーによって制御された使用を可能にすることができるシステム、方法、および手法が、開示される。DPIが使用され得る程度が、端末の制御エンティティ、例えば、セッションマネージャによって構成可能であってもよい。これは、DPIに専用のリソースのポリシーに基づく制御と、本明細書において説明される進化型のソケットインターフェースによって提供される特定のレベルとを可能にする。例えば、レガシーのアプリケーションをサポートするための発展型ソケットインターフェースAdvancedSocketInterfaceASIFが、本明細書において開示される。ASIFは、アプリケーションが通信セッションを開始し、利用するためのアクセス能力を提供する改良されたプロトコルスタックの実装のための機能コンポーネントである可能性がある。下位互換を目的として、ASIFは、アプリケーションに対して、自身を改良型のソケットインターフェースとして示す可能性がある。ASIFは、以下、すなわち、アプリケーションがそれらのアプリケーションの目的のためにIPスタック例えば、EIPSの接続を開き/閉じ、管理するための技術を提供すること、接続を必要とする可能性があるアプリケーションおよびそのアプリケーションのQoSの要件についての情報をセッション管理SMコンポーネントに提供すること、または例えば、接続マネージャによって定義されたように、アプリケーションデータを適切なトランスポートプロトコルに/から受け渡しすることのうちの1つまたは複数を行う可能性がある。図5は、例示的なASIF機能コンポーネントASIFFCの機能図である。図5に示されるように、ASIFは、例えば、例示的なインターフェースC1、D4、およびD5を通じて制御エンティティ例えば、セッションマネージャSM、トランスポートレイヤ、およびアプリケーションとインターフェースを取ることができる。アプリケーションと通信するために使用されるインターフェースD5は、BSDソケットインターフェースに基づく可能性がある。ASIFは、例えば、内部的な実装として以下の関数、すなわち、SessionOpen、SessionConnect、SessionClose、IncomingData、OutgoingData、またはPassThroughのうちの1つまたは複数をサポートする可能性がある。ASIF機能コンポーネントは、ソケット関数を通じてアプリケーションから受信されたパラメータに、および/またはパケットインスペクションPIの手順、例えばパケットを送受信するためのポートなどのセッションに関連する情報を抽出するディープパケットインスペクションアルゴリズムの変化形、セッションで使用されるアプリケーションプロトコルなどに依存する可能性がある。PIは、レガシーのアプリケーションおよび特定の発展型のアプリケーションの確認、特定、監視などのためにIncomingDataおよびOutgoingData関数で使用され得る。PI機能によって抽出されたセッション情報は、SMにレポートされ得る。セッションに関連するパラメータは、以下のうちの1つまたは複数を含み得る。セッションIDSIDは、ソケットIDと呼ばれることもあるパラメータである可能性がある。ソケットIDは、未知である場合、NULLに設定される可能性がある。アプリケーションプロトコル名PNAMEは、未知の場合にNULLに設定され得るパラメータである可能性がある。PNAMEの値は、PIによってサポートされるプロトコルにリンクされ得る例えば、表8。アプリケーションIDAIDは、未知の場合にNULLに設定され得るパラメータである可能性がある。セッションが同じアプリケーションのサブフローとして特定される場合、それらのセッションは同じAIDを有する可能性がある。例えば、FTPアプリケーションは、FTP制御セッションおよびFTPデータセッションを含む可能性がある。両方のセッションが、同じAIDを有する可能性がある。単一のSessionOpen、SessionClose、およびPassThroughプロセスが、ASIFのために必要とされる可能性がある。IncomingDataおよびOutgoingDataの別々のインスタンスが、それぞれのアクティブなセッションのために必要とされる可能性がある。ソケットインターフェース呼び出しは、ASIFのプロシージャにマッピングされる可能性がある。表5は、ソケットインターフェース呼び出しとASIFプロセスとの間の例示的なマッピングを示す。一部の呼び出しは、接続を受け付けることができるサーバ例えば、TCPサーバを対象としており、それらの接続を開始する端末を対象としていない可能性があるためにマッピングされない可能性がある。セッションは、関連する状態を有する可能性がある。アクティブなセッションは、SessionOpenプロセスによって生成され、SessionCloseプロセスによって削除される可能性がある。例示的なセッションのライフタイムが、図6に示される。ソケットのライフタイム中に、ASIFコンポーネントは、セッション状態マシンsessionstatemachineSSMを保有する可能性がある。SSMは、セッションのために使用されるアプリケーションプロトコルの種類の知識を示すことができる。SSMは、connectを用いて受信される5つ組みによって、およびPI機能によって更新され得る。例えば、SSMに関する例示的な状態遷移図が、図7に示され、図7は、ASIFにより監視されるセッションに関する状態遷移図を示す。図7を参照すると、1つの状態は、SessionOpenによって設定される開始状態である可能性がある新しいセッションNEW状態を含み得る。SessionConnectは、送信先ポート分析を実行することができる。その送信先ポートが、例えばIANAによって定義されているよく知られているポートである場合、SSMは、未検証/安定US状態に遷移する可能性がある。そうでない場合、SSMは、未知U状態に遷移する可能性がある。未知U状態は、セッションのために使用されるアプリケーションが特定されなかったことを示す可能性がある。図7は、違反V状態を示す。違反状態は、セッションのプロトコルが検証済みのまたは未検証の特定されたプロトコルの規則に違反していることが分かったことを示す可能性がある。この状態への遷移は、セッションのプロトコル違反をSMにレポートすることを引き起こす可能性がある。V状態での動作は、無制限にサポートされる可能性がある。図7は、未検証/安定US状態を示す。未検証/安定状態は、セッションを使用するアプリケーションプロトコルが、デフォルトの構成および/またはconnectの呼び出しで渡されたパラメータを用いて特定されたが、その特定が確認されていないことを示す可能性がある。未検証/安定状態は、セッションが、現在、再構成されるプロセス中でない例えば、いかなる再構成のトリガも生成されなかったことを示す可能性がある。図7は、未検証/再構成UR状態を示す。未検証/再構成状態は、セッションを使用するアプリケーションプロトコルが、デフォルトの構成ならびに/またはsocketおよびconnectの呼び出しで渡されたパラメータを用いて特定されたが、その特定が確認されていないことを示す可能性がある。図7は、検証済み/安定VS状態を示す。検証済み/安定状態は、セッションを使用するアプリケーションが、デフォルトの構成ならびに/またはsocketおよびconnectの呼び出しで渡されたパラメータを用いて特定され、その特定が、例えばPIによって確認されたことを示す可能性がある。検証済み/安定状態は、セッションが、現在、再構成されるプロセス中でない例えば、いかなる再構成のトリガも生成されなかったことを示す可能性がある。図7は、未検証/再構成VR状態を示す。未検証/再構成状態は、セッションを使用するアプリケーションが、デフォルトの構成ならびに/またはsocketの呼び出しで渡されたパラメータを用いて特定され、その特定が確認されたことを示す可能性がある。未検証/再構成状態は、特定されたプロトコルの詳細に基づいて、セッションが再構成されるプロセス中であり、再構成のトリガが生成されたことを示す可能性がある。NEW→UおよびNEW→USを除いたそれぞれの状態遷移は、発信方向か着信方向かのどちらかのパケットの受信の結果として起こり得る。遷移NEW→UおよびNEW→USは、本明細書において開示されるようにソケットを接続すると例えば、NEW状態発生する可能性がある。遷移の性質は、IncomingDataおよびOutgoingDataプロセスによってあらゆるパケットに関して呼び出される可能性があるパケットインスペクション機能の結果である可能性がある。SIDnに関する状態マシンの遷移は、PI機能がSIDnを返した場合に起こり得る。表6は、原因および結果を含み得る例示的なセッションの状態遷移の仕様を示す。パケットインスペクションPI機能は、例えば、着信方向かまたは発信方向かのどちらかのパケットに関して要求される可能性がある。PI機能は、以下、すなわち、パケットのSIDが未知であること例えば、これは、着信方向で起こり得る、またはパケットのSIDがU、US、もしくはUR状態のセッションに関連することのうちの1つまたは複数を満たす各パケットに対して呼び出される可能性がある。PI機能は、VSまたはVR状態のSIDを有するパケットに関して呼び出される可能性がある。この決定は、SMに任される可能性があり、プロセスごとに構成される可能性がある。受信されたパケットに加えて、パケットインスペクション機能は、以下の入力、すなわち、SID、PNAME、MODE、またはINSPECTIONLEVELのうちの1つまたは複数を受け取る可能性がある。SIDは、未知である場合例えば、これは、着信方向で起こり得る、NULLに設定される可能性がある。PNAMEは、プロトコル名を表す可能性がある。PNAMEは、未知である場合、NULLに設定される可能性がある。MODEは、{DISCOVER,CONFIRM,MONITOR}のうちの1つである可能性がある。DISCOVERモードにおいて、PI機能のタスクは、所与のSIDに関してどのアプリケーションプロトコルが使用されているかを発見することである可能性がある。PNAMEがNULLでない場合、プロトコルのリストが、候補リストとして扱われる可能性があり、検索空間を狭め、高速化するために使用される可能性がある。SIDがNULLである場合、パケットは、潜在的に、U状態の任意のセッションに属すると想定され得る。CONFIRMモードおよびMONITORモードにおいて、PI機能のタスクは、プロトコルの動作を監視し、再構成のトリガを設定することである可能性がある。これらの状態においては、SIDおよびPNAMEは、NULLに設定されることが許されない可能性がある。さらに、PNAMEは、一意な設定を有する必要がある可能性があり、この設定は、このSIDに関するPNAMEの前の設定と一貫している必要がある可能性がある。この規則に違反すると、PI機能が、所与のパケットでSIDに関してVIOLATIONを返す結果となる可能性がある。CONFIRMモードにおいて、PI機能は、プロトコルが確かにPNAMEに対応していることを確認するように要求される可能性がある。INSPECTIONLEVELパラメータは、特定のセッションに対してパケットインスペクションが行われる深さ例えば、レベルを決定する可能性がある。INSPECTIONLEVELパラメータは、PI機能が設定することができる可能性がある再構成のトリガおよびPI機能が行うことができる可能性があるプロトコルの測定の種類を決定する可能性がある。INSPECTIONLEVELは、1つまたは複数のSMのポリシーに基づいてSMによって設定され得る。DEFAULTINSPECTIONLEVELが、SMによって設定される可能性があり、SMが特定のINSPECTIONLEVELを設定しなかったセッションにASIFによって適用される可能性がある。例示的なINSPECTIONLEVELが、表7に示される。PI機能は、以下、すなわち、PNAME、アプリケーションプロトコル、現在のパケットのSIDに関するアプリケーションID、その他の関連するSID、以下の{NOCHANGE,VIOLATION,CONFIRM,PROTOCOLID}のうちの1つ、以下の{STABLE,RECONFIG}のうちの1つのうちの1つもしくは複数を返す可能性があり、またはRECONFIGが返される場合は、再構成の性質がレポートされる可能性がある。構成の性質は、以下、すなわち、NEXT_TP次のメッセージのトランスポートプロトコル、NEXT_PRT_S次の送信元ポート、NEXT_PRT_D次の送信先ポート、またはアプリケーションプロトコルに固有の情報のうちの1つまたは複数を含み得る。PI機能によってサポートされるプロトコルのリストは、構成可能なパラメータである可能性がある。実際のPI機能は、任意の知られているディープパケットインスペクションアルゴリズムのうちの1つである可能性がある。図8は、例示的なパケットインスペクションを示す。現在のパケットの分析において、PIが、現在のセッションにリンクされ、現在のセッションに関連するアプリケーションに属している可能性がある潜在的な将来開くセッションを検出する場合、PIは、潜在的なサブフローのトリガpotentialsub-flowtriggerを設定する可能性がある。潜在的なサブフローのトリガは、後でセッションを開くこと、および新しい開いたセッションが現在のセッションに関連するアプリケーションに属するかどうかを確認するための新しいセッションのパケットの分析のために使用され得る。このトリガに関連付けて、PIは、予測される将来のセッションに関連する詳細例えば、ポート番号、プロトコルなどを追跡することができる。例えば、TCP送信先ポート21および何らかの特定の送信先IPアドレスIPxを用いて端末で開始されたFTP制御接続で開始されたFTPセッションを考える。PI機能は、この接続を監視し、TCPポートAおよび送信先IPIPyを用いてFTPデータ接続を設定するための命令を有する、端末に戻るFTPコマンドを検出することができる。そのとき、PI機能は、潜在的なサブフローのトリガを設定する可能性がある。潜在的なサブフローのトリガは、以下、すなわち、サブフローのトリガのID、サブフローのトリガの詳細、サブフローのトリガの情報、またはサブフローのトリガのライフタイムのうちの1つまたは複数を含み得る。サブフローのトリガの詳細は、以下、すなわち、アプリケーションID例えば、FTPアプリケーションに関連するアプリケーションIDを使用する、送信先ポートの種類:TCP、送信先ポートアドレス:A、または送信先IP:IPyのうちの1つまたは複数を含み得る。サブフローのトリガの情報は、以下、すなわち、マスターセッションID:FTP制御セッションのセッションID、サブフローのトリガの種類:FTPデータ転送、またはサブフローのトリガの追加情報:追加的な情報、この種類のセッションに関連する可能性があるそのようなQoSの要件、例えば、要求されるファイルのサイズなどのうちの1つまたは複数を含み得る。サブフローのトリガのライフタイムは、有効期間、有効期限などを含み得る。SessionOpenプロセスは、アプリケーションに関する通信セッションを開始する役割を担う可能性がある。SessionOpenプロセスは、アプリケーションが、例えば、D5でsocketの呼び出しを行うときに開始される可能性があり、アプリケーションのためにその呼び出しに対する応答を生成する役割を担う可能性がある。アクティブ化されると、SessionOpenプロセスは、以下、すなわち、socketの呼び出しが新しいセッションに対応するかどうかを検査するか、もしくは潜在的なサブフローのトリガが立てられている場合にソケットが既存のセッションに関連付けられ得るかどうかを判定すること、その他のプロセスおよびコンポーネントとの、そのセッションについての通信で使用されるべきセッションIDSIDを定義すること、socketのパラメータからソケットの種類例えば、UDP、TCPなどの情報を取り出すこと、セッションマネージャおよび接続マネージャに新しいセッションを開く要求を知らせること、またはソケットが受け付けられる場合に、開いたセッションの状態に入ることのうちの1つまたは複数を実行する可能性がある。図9は、例示的なSessionStart/SessionOpenプロセスを示す。関数intsocketは、通信のエンドポイントを生成することができ、ソケットに関連するさらなる動作のために使用され得る記述子例えば、セッションIDを返すことができる。例えば、本明細書において開示されるTCP/IPに基づくソケットに関して、familyパラメータは、AF_INETに設定され得る。typeパラメータは、例えば、TCPに関してSOCK_STREAMまたは例えば、UDPに関してSOCK_DGRAMである可能性がある。protocolフィールドは、ネットワークモデルがさまざまな種類のストリームおよびデータグラムのモデルをサポートする場合に特定のプロトコルを指定することができる。このフィールドは、0に設定され得る例えば、TCP/IPは、それぞれに関して1つのプロトコルを有する可能性がある。関数のドメインdomainは、ソケットが生成されるべき通信のドメインを指定する可能性がある。例えば、本明細書において開示されるTCP/IPに基づくソケットに関して、familyパラメータは、PF_INETIPv4インターネットプロトコルおよびPF_INET6IPv6インターネットプロトコルに設定され得る。Typeは、生成されるべきソケットの種類を指定することができる。Protocolは、ソケットで使用されるべき特定のプロトコルを指定することができる。protocol引数が非ゼロである場合、その引数は、アドレスファミリーによってサポートされるプロトコルを指定することができる。protocol引数がゼロである場合、このアドレスファミリーおよび種類のためのデフォルトのプロトコルが使用され得る。システムによってサポートされるプロトコルは、実装で定義される可能性がある。セッションIDは、ASIFによってランダムに生成され得る。セッションIDは、そのソケットで動作し得るその後の関数呼び出しでアプリケーションによって使用され得るソケットIDとして返される可能性がある。例えば、D5でconnectの呼び出しを受信すると、SessionConnectプロセスが、関数呼び出しのパラメータとして渡されたソケットのSIDを、関数を通じて渡された送信先ポートおよびIPを有するピアに接続する役割を担う可能性がある。SessionConnectプロセスは、以下、すなわち、デフォルトのアプリケーションの構成を用いてセッションを特定するように試みること、セッションがアプリケーションのサブフローであるかどうかを特定するように試みること、SSMを未知U状態かもしくは未検証/安定US状態かのどちらかに更新すること、SM_SessionConnectを呼び出すことによって、既に開いているセッションに接続するように要求のセッションマネージャに要求すること、または値を返すことのうちの1つまたは複数を実行する可能性がある。図10は、例示的なSessionConnectプロセスを示す。connect関数呼び出しは、ソケットのファイル記述子によって特定されるソケットを、引数のリスト内のホストのアドレスによって指定されたそのリモートホストに接続することができる。特定の種類のソケットはコネクションレス型である可能性があり、UDPソケットが一例であり得る。これらのソケットに関して、connectは、以下の意味を持つ可能性があり、すなわち、データを送受信するためのデフォルトのターゲットが所与のアドレスに設定され、このことは、コネクションレス型のソケットでsendおよびrecvなどの関数を使用することを可能にすることができる。connectは、エラーコードを表す整数を返す可能性があり、0が成功を表す可能性があり、-1がエラーを表す可能性がある、等々である。connectのプロトタイプは、次の通りである可能性がある:intconnect。第1の引数は、ソケットのハンドル例えば、socket関数呼び出しから返された数である可能性がある。第2の引数は、sockaddr_in構造体である可能性がある。アドレス引数のsin_portフィールドは、このソケットに関連するローカルの送信元ポート番号である可能性がある。つまり、このソケットによるsend動作に関して、TCP/UDPヘッダの送信元ポートフィールドは、この値を用いて設定され得る。送信元ポートを指定することが必要とされない場合、この値をINADDR_ANY0に設定することによって、オペレーティングシステムが任意の利用可能なポート番号を選ぶことを可能にすることができる。sin_addrフィールドは、どのネットワークインターフェースデバイスを使用すべきかを指定することができる。多くのホストは1つのネットワークインターフェースおよび1つのIPアドレスを有する可能性があるので、このフィールドは、ホスト自身のIPアドレスを用いて設定され得る。ソケットライブラリは、ホストがそのホスト自身のIPアドレスを判定する直接的な方法を提供しない可能性がある。このフィールドにINADDR_ANY0の値を指定することは、任意の利用可能なインターフェースおよびアドレスを選択するようにオペレーティングシステムに指示することができる。sockaddr_in構造体のアドレスは、ソケットがリモートホストと通信する準備ができた状態になり得るようにbindの呼び出しに渡される可能性がある。bindに渡される第3のパラメータは、sockaddr_in構造体の長さである可能性がある。既知のアプリケーションプロトコルに関する調査が行われる可能性がある。LEGACYアプリケーションに関して、3つ組み<トランスポートプロトコル,送信元ポート,送信先ポート>が、IANAの知られているアプリケーションのテーブルと照合される可能性がある。表8は、connectのパラメータに基づくプロトコルの分析の例示的なテーブルである。connectのパラメータが上述のテーブルの一部である場合、SSMは、USに設定される可能性があり、関連するアプリケーションプロトコルPNAMEは、テーブルからの値を用いて設定される。そうでない場合、SSMは、U状態に遷移する可能性があり、PNAMEは、NULLに設定される可能性がある。アプリケーションがD5でrecvまたはrecevfromを呼び出すとき、IncomingDataが呼び出される可能性がある。パケットに関するセッションIDが例えば、5つ組みに基づいて特定され得る場合、データは、D5を通じて正しいアプリケーションに渡され得る。データが受信されるセッションがPI機能が呼び出されるべきであることを示す場合、これが行われる可能性がある。PI機能が完了するとき、表6に定義された動作が行われる。OutgoingDataが、それぞれの発信パケットに対して呼び出される。パケットに関するセッション番号が例えば、5つ組みに基づいて特定され得る場合、データは、正しいトランスポートプロトコルに渡され得る。SessionCloseが、アプリケーションがD5でcloseの呼び出しを行うときに開始される可能性があり、アプリケーションのためにこの呼び出しに対する応答を生成する役割を担う。アクティブ化されると、SessionCloseプロセスは、以下、すなわち、SIDに関連するSSMを終了させること、SMおよびCMに開いているセッションを閉じる要求を知らせること、またはセッションIDSIDの割り当てを解除することのうちの1つまたは複数を実行する可能性がある。PassThroughプロセスは、ソケット呼び出しを、ASIFに固有のプロセスを用いずに別のコンポーネントに転送することができる。D5でのgethostbynameまたはgethostbyaddrの呼び出しに関して、ASIFは、これらの関数を、処理されるようにSMに透過的に渡し、戻り値を、追加的な調査なしに応答として返すことができる。送信元アドレスに関して、アプリケーションは、アプリケーションにアドレスのリストを返す可能性があるAPI、例えば、getaddrinfoを使用することができる。リストは、IPv6および/またはIPv4アドレスを含み得る。ASIFの機能に関連するインターフェースの仕様が、与えられ得る。D5は、アプリケーションと発展型ソケットIFASIFとの間のインターフェースを指す可能性がある。このインターフェースは、レガシーのアプリケーションとADVアプリケーションADVApplicationの両方のためのBSDに似たソケットインターフェースを提供することができる。使用される機能は、クライアント側の機能に限られる可能性がある。例示的なD5の関数が、表9に示される。C1は、発展型ソケットIFASIFとSMなどの制御プレーンのエンティティとの間のインターフェースを指す可能性がある。このインターフェースは、ASIFが、新しいセッションが検出されたこと、またはアクティブなセッションに関して変更が行われたことをSMに知らせることを可能にすることができる。変更とは、以下、すなわち、セッションへの新しいソケット例えば、新しいセッション、サブフローなどの追加、サブフローの削除、またはセッションの記述の変更例えば、新しいQoS、モビリティが必要とされるか否か、セキュリティのレベルなどのうちの1つまたは複数を指す可能性がある。例示的C1の関数が、表10で与えられる。D4は、ASIFとトランスポートFCとの間で使用され得る。D4は、トランスポートFCにデータパケットを送信することとトランスポートFCからデータパケットを受信することとを可能にすることができる。例示的なD4の関数が、表11に示される。socketインターフェース関数はパラメータadvで拡張される可能性があり、その結果、表12に示される形式を有する。advパラメータは、以下のパラメータ、すなわち、アプリケーションID、QoSプリファレンスQoSPreference、プロトコル:ADV、master_socket_id、num_subflows、subflow_desc、またはPreferred_networkのうちの1つまたは複数を含み得る。アプリケーションIDは、同じアプリケーションによって開かれた複数のセッションをリンクするためにシステムによって使用され得る、アプリケーションによって選択されたアプリケーションIDである可能性がある。オペレーティングシステムによってアプリケーションに割り振られたプロセスIDが、アプリケーションIDとして使用され得る。QoSプリファレンスは、あるQoSプリファレンスを与えることができる。アプリケーションは、プロトコル:ADVを使用して、例えば、本明細書において開示される値を有するそのアプリケーションのアプリケーションプロトコルを送信することができる。master_socket_idは、ソケットが別のソケットidとの接続に関する下位接続と見なされるべきであることを示すことができる。num_subflowsは、ソケットが複数のサブフローを含むことを示すために使用され得る。値>1が使用される場合、サブフロー記述子sub-flowdescriptorが含まれる可能性があり、そうでない場合、これは無視される可能性がある。値>1は、サポートされない可能性がある。subflow_descは、サブフロー記述子である可能性がある。Preferred_networkは、アプリケーションのネットワークのプリファレンスを示すために使用され得る。2つの種類が、含まれる可能性がある。アプリケーションは、ネットワークとして<MOBILE,PUBLIC_IP,PRIVATE_IP>を優先することを示すことができるか、またはアプリケーションは、特定のネットワーク例えば、特定のモバイル運用者、SSIDのリストによる特定の公衆WiFIネットワークなどを示すことができる。MOBILEは、モバイル/セルラネットワークである可能性がある。PUBLIC_IPは、パブリックIP例えば、インターネットにアクセスするネットワークである可能性がある。PRIVATE_IPは、プライベートIPネットワーク-例えば、組織の企業ネットワーク-である可能性がある。QoSプリファレンスは、アプリケーションが必要とする接続の種類を指定する方法をアプリケーションに提供し、SMがセッションのリソースを割り当てることを可能にすることができる。QoSプリファレンスは、アプリケーションがプリファレンスの順序で配列することができるQoSインジケータQoSIndicatorの組を定義する可能性がある。アプリケーションは、QoSインジケータのうちの1つまたはサブセットを使用するように制限される例えば、最高のプリファレンスから最低に向かう順序でいくつかを指定する可能性がある。ASIFは、パケットインスペクションの分析に基づいてこれらを設定および/または修正することができる。QoSクラスQoSClassは、以下のうちの1つまたは複数を含み得る。QoSI_THROUGHPUT:このQoSインジケータは、スループットの最大化が重要であることをシグナリングするために使用され得る。QoSI_LATENCY:このQoSインジケータは、レイテンシの最小化が重要であることをシグナリングするために使用される可能性があり、これは、スループットを犠牲にする可能性がある。QoSI_RELIABILITY:このQoSインジケータは、パケット誤り率の最小化が重要であることをシグナリングするために使用される可能性があり、これは、スループットおよびレイテンシを犠牲にする可能性がある。QoS_POWER_EFF:このQoSインジケータは、電力消費の最小化が重要であることをシグナリングするために使用される可能性があり、これは、その他のQoSの観点を犠牲にする可能性がある。QoS_CRITICAL:このQoSインジケータは、アプリケーションがそのアプリケーション自身を重大な機能のサービス例えば、人の健康、動作の信頼性などと考えることをシグナリングするために使用され得る。アプリケーションは、そのアプリケーションに割り振られるべきリソースがSMによる決定を経る可能性があるが、これを用いて高い優先度のサービスを要求することができる。QoS_SECURE:このQoSインジケータは、高セキュリティの接続が必要とされることをシグナリングするために使用され得る。これが提供される程度は、SMに任される可能性がある。QoS_BACKGROUND:このQoSインジケータは、バックグラウンドサービスのために使用される可能性があり、SMが、例えば、コストを最小化するようにリソースを割り当てることなどを可能にすることができる。セルラ接続の場合、指定されたQoSクラスは、セルラシステムの仕様で規定されたQoSクラスにマッピングされ得る。特徴および要素が特定の組み合わせで上で説明されているが、当業者は、各特徴または要素が、単独で、またはその他の特徴および要素との任意の組み合わせで使用され得ることを理解するであろう。加えて、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装され得る。コンピュータ可読媒体の例は、有線または無線接続を介して送信される電子的な信号と、コンピュータ可読ストレージ媒体とを含む。コンピュータ可読ストレージ媒体の例は、読み出し専用メモリROM、ランダムアクセスメモリRAM、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能なディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびデジタルバーサタイルディスクDVDなどの光媒体を含むがこれらに限定されない。ソフトウェアに関連するプロセッサが、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用され得る。"