JP2013501401A

JP2013501401A - ベスト・エフォート型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムおよび方法

Info

Publication number: JP2013501401A
Application number: JP2012522892A
Authority: JP
Inventors: カーン，コリン，エル．; ヤング，トーマス，エス．
Original assignee: アルカテル−ルーセント
Priority date: 2009-07-31
Filing date: 2010-07-20
Publication date: 2013-01-10
Also published as: CN102484820B; CN102484820A; KR101428503B1; WO2011014382A1; US20110026412A1; EP2460374B1; KR20120039746A; US8625440B2; EP2460374A1; JP2016036164A

Abstract

本発明は、ベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムおよび方法に関する。システムは、パケットがＢＥ型通信リンクで送信されるために、（ｉ）アプリケーション識別子、および（ｉｉ）インターネット層よりも上位の少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを取得するように構成されたプロトコル専用プロセッサ（２１０）を含む。プロトコル専用プロセッサ（２１０）は、パケットが無線アクセス・ネットワーク（２００）でサービス品質（ＱｏＳ）処理を受けられるように、取得した（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つによってパケット用のパラメータを決定するように構成される。

Description

本発明は、ベスト・エフォート型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するシステム及び方法に関する。

可動性のために使用されるすべての無線技術は、無線インターフェースを介して送信されるデータ・パケットについてのサービス品質（ＱｏＳ）差を提供するためのメカニズムを十分に確立している。無線技術のタイプには、特にグローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）、符号分割多元接続（ＣＤＭＡ）、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）、ロング・ターム・エボリューション（ＬＴＥ）、およびＷｉＭａｘなどがある。

図１は、従来の無線通信ネットワークの一般的なアーキテクチャを示している。図１は、特にＵＭＴＳ無線ネットワークの一部を示している。図示されるように、ユーザ装置（ＵＥ）１３０は無線インターフェースを介してノードＢ１２０と通信する。ＵＥの例には、移動局、モバイル・ユニット、無線電話、無線を装備したＰＤＡまたはコンピュータなどがある。複数のノードＢ１２０は、無線データ・セッションごとにシグナリングおよびトラフィック処理を提供する無線ネットワーク・コントローラ（ＲＮＣ）１１０と通信する。ノードＢ１２０、ＲＮＣ１１０、およびこれらのコンポーネント間のインターフェースは、無線アクセス・ネットワーク（ＲＡＮ）として知られているネットワークを形成する。ＲＡＮは、たとえばインターネットにアクセスするために、コア・ネットワーク（図示せず）と通信する。ノードＢ１２０からＲＮＣ１１０に流れるパケット・データは逆方向リンクを介して流れると言われ、ＲＮＣ１１０からノードＢ１２０に流れるパケット・データは順方向リンクを介して流れると言われる。以下で使用される場合、ノードＢ１２０は、ＣＤＭＡ技術用のトランシーバ・ステーション（ＢＴＳ）およびＬＴＥ技術用のｅノードＢと同義でよい。

ＲＡＮは、ＵＥ１３０からの要求および制御要素１４０から受信した指示に従って、異なるＱｏＳ基準とのベアラを設定するよう指示される。たとえば、ＵＭＴＳでは、制御要素１４０はサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）またはゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）でよい。ＣＤＭＡでは、制御要素１４０は、たとえばパケット・データ・サービング・ノード（ＰＮＳＮ）でよい。また、ＬＴＥでは、制御要素１４０はＰＤＮ−ＧＷ／ＳＧＷでよい。制御要素１４０は、ＲＮＣ１１０およびノードＢ１２０にＱｏＳベアラを設定するよう指示する。

ＲＡＮ内にＱｏＳベアラを確立後、送信の無線リンク層アスペクトは確立されたベアラに関連付けられる。たとえば、ＲＡＮ内にボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）が確立されると、ＲＡＮは、下位のプロトコル層パラメータの特定のセットをＶｏＩＰに関連付けられるフローに関連付けることによって応答する。ＶｏＩＰフローを有するプロトコル層パラメータは、たとえばＲＦパワー制御目標、ＩＰヘッダ圧縮メカニズム（もしあれば）、パケット用最大許容可能遅延限界、スループット要求、ＲＬＰ再送、アドミッション制御をトリガするパケット損失レート目標、オーバーロード制御、パワー制御または他の機能、リソース・ホギング保護、ならびにプロトコルに関連するアプリケーションによって要求されるパケット・バッファ・サイズおよびタイム・トゥ・ミート（ｔｉｍｅｓｔｏｍｅｅｔ）遅延目標を含んでよい。一般的に、これらのパラメータは順方向および逆方向無線インターフェース・リンクに別々に実装される。

制御要素１４０によってＱｏＳ処理を必要とするものとして特に識別されていないアプリケーションが、ＲＮＣ１１０、ノードＢ１２０、およびＵＥ１３０への無線送信においてベスト・エフォート（ＢＥ）型またはデフォルト・ベアラ通信リンク内でサービスされる。一般的にキュー・サイズおよび優先制約などのパラメータだけを含む有線送信とは異なり、上述したプロトコル・パラメータなどの他の複数のパラメータがＲＡＮ内に設定される。現在、これらのパラメータは固定値に設定され、ＢＥ型通信リンクにおいて送信されているプロトコルおよびアプリケーションとは無関係である。その結果、ＢＥ型通信リンク内でデフォルト設定と一致しないアプリケーションがサービスされると、ＲＡＮリソースが浪費され、データ・パケット処理は準最適レベルで実行される。

たとえば、Ｓｋｙｐｅ（商標）は無線ネットワークにおけるＢＥ型通信リンクで送信されるＶｏＩＰアプリケーションである。従来の方法によれば、送信されるパケット用のパラメータは、アプリケーションがＶｏＩＰアプリケーションであるという事実、および／またはプロトコル層のタイプとは無関係の固定値によって設定される。たとえば、ＲＬＰ再送が可能であり、ヘッダ圧縮は行われず、無線インターフェース・パケット・エラー・レート目標がスピーチ関連アプリケーションに必要な目標よりもかなり低く設定される。その結果、ＲＡＮリソースが浪費され、ユーザ・エクスペリエンスが低下する。

本発明は、ベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムおよび方法に関する。

システムは、パケットがＢＥ型通信リンクで送信されるために、（ｉ）アプリケーション識別子、および（ｉｉ）インターネット層よりも上位の少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを取得するように構成されたプロトコル専用プロセッサを含む。プロトコル専用プロセッサは、パケットが無線アクセス・ネットワークでサービス品質（ＱｏＳ）処理を受けられるように、取得した（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つによってパケット用のパラメータを決定するように構成される。

決定されたパラメータは、取得した（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの１つに関連付けられるＱｏＳパラメータである。少なくとも１つの層は、アプリケーション層およびトランスポート層を含む。あるいは、少なくとも１つの層はインターネット層よりも上位のすべての層を含む。実施形態によれば、プロトコル専用プロセッサは、（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを決定するために、パケットを検査するように構成される。あるいは、プロトコル専用プロセッサは、外部ソースから（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを受信することによって、（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを決定する。また、プロトコル専用プロセッサは、パケット用のパラメータをリアルタイムで決定するように構成され得る。

プロトコル専用プロセッサは、順方向リンク通信のために決定されたパラメータを設定するように構成される。プロトコル専用プロセッサは、決定されたパラメータを逆方向リンク通信のためにアクセス・ターミナルにフィードバックするように構成される。

ＢＥ型通信リンクは、ＱｏＳ処理を必要とするものとして特に識別されていないアプリケーションをサービスする通信リンクである。アプリケーション識別子は、データ・パケットに関連付けられるアプリケーションのタイプを識別する識別子である。

方法は、プロトコル専用プロセッサによって、パケットがＢＥ型通信リンクで送信されるために、（ｉ）アプリケーション識別子、および（ｉｉ）インターネット層よりも上位の少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを取得するステップと、プロトコル専用プロセッサによって、パケットが無線アクセス・ネットワークでサービス品質（ＱｏＳ）処理を受けられるように、取得した（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つによってパケット用のパラメータを決定するステップとを含む。

方法は、（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを決定するために、パケットを検査するステップをさらに含んでよい。あるいは、方法は、外部ソースから（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを受信することによって、（ｉ）アプリケーション識別子、および（ｉｉ）少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを決定するステップを含んでよい。

方法は、順方向リンク通信のために決定されたパラメータを設定するステップと、決定されたパラメータを逆方向リンク通信のためにアクセス・ターミナルにフィードバックするステップとをさらに含んでよい。

例示的実施形態は、本明細書において以下に記載する詳細な説明および添付の図面から、より完全に理解されよう。添付の図面において、同様の要素は同様の参照番号によって示される。添付の図面は説明のためだけに示されるものであり、本発明を限定するものではない。

従来の無線通信ネットワークの一般的なアーキテクチャを示す図である。本発明の実施形態による、順方向リンク上のベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムを示す図である。本発明の実施形態による、逆方向リンク上のＢＥ型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムを示す図である。本発明の実施形態による、逆方向および順方向リンク通信のためのプロトコル専用プロセッサの機能を示す流れ図である。本発明の実施形態による、アプリケーション識別子、および／またはプロトコルのタイプに基づくデータ・パケット用のパラメータを示す図である。

次に、添付の図面を参照して本発明の様々な例示的実施形態をより完全に説明する。本発明のいくつかの例示的実施形態が図面に示されている。図面の説明を通じて、同様の番号は同様の要素を指す。

本明細書において、様々な要素を説明するために第１、第２などの用語が使用される場合があるが、これらの要素はこれらの用語によって限定されるべきではないことが理解されよう。これらの用語は、ある要素と他の要素を区別するためだけに使用される。たとえば、例示的実施形態の範囲から逸脱することなしに、第１の要素は第２の要素と呼ばれてもよく、同様に第２の要素は第１の要素と呼ばれてもよい。本明細書で使用されるように、「および／または」という用語は、関連するリストアップされた項目のうちの１つまたは複数の、あらゆるおよびすべての組合せを含む。

本明細書で使用される用語は、特定の実施形態を説明するためのものにすぎず、例示的実施形態を限定する意図はない。本明細書で使用されるように、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈に明確な指示のない限り複数形も含むことを意図する。本明細書で使用される場合、「ｃｏｍｐｒｉｓｅｓ（備える）」、「ｃｏｍｐｒｉｓｉｎｇ（備える）」、「ｉｎｃｌｕｄｅｓ（含む）」、および／または「ｉｎｃｌｕｄｉｎｇ（含む）」という用語は、述べられた特徴、整数、ステップ、操作、要素、および／またはコンポーネントの存在を示すが、１つまたは複数の他の特徴、整数、ステップ、操作、要素、コンポーネント、および／またはそれらのグループの存在または追加を除外しないことがさらに理解されよう。

いくつかの代替実装形態では、記載した機能／動作が図面に記載した順序とは異なる順序で発生する場合がある点にも留意されたい。たとえば、連続して示されている２つの図面は、関連する機能／動作に応じて、実際には同時に実行されてもよく、逆の順序で実行されることがあってもよい。

特に定義のない限り、本明細書で使用されるすべての用語（技術用語および科学用語を含む）は、例示的実施形態が属する分野の当業者によって通常理解される意味と同じ意味を有する。通常使用される辞書で定義される用語などの用語は、関連分野の文脈におけるそれらの意味と一致する意味を有するものと解釈されるべきであり、本明細書で明確に定義されない限り、理想的または過度に正式な意味で解釈されないことがさらに理解されよう。

以下の記述では、特定のタスクを実行する、または特定の抽象的データ・タイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含むプログラム・モジュールまたは機能処理として実装され得る、および既存のネットワーク要素で既存のハードウェアを使用して実装され得る、操作の動作および記号表現を参照して（たとえば、流れ図の形式で）、例示的実施形態を説明する。このような既存のハードウェアは、１つまたは複数の中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路、フィールド・プログラム可能ゲート・アレイ（ＦＰＧＡ）コンピュータなどを含んでよい。

しかし、これらおよび類似の用語のすべては適切な物理量に関連付けられるべきであり、これらの量に適用された便利なラベルにすぎないことを念頭に置くべきである。特に記載のない限り、または議論から明らかなように、「ａｃｑｕｉｒｉｎｇ（取得する）」または「ｄｅｔｅｒｍｉｎｉｎｇ（決定する）」などの用語は、コンピュータ・システムのレジスタおよびメモリ内で物理電子量として示されるデータを操作して、コンピュータ・システム・メモリまたはレジスタ、あるいは他のこのような情報ストレージ、伝送または表示装置内で物理量として同様に示される他のデータに変換するコンピュータ・システム、または類似の電子コンピューティング装置の動作および処理を指す。

図２Ａは、本発明の実施形態による、順方向リンク上のベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムを示している。

たとえば、図２Ａは、ＢＥ型通信リンクでコア・ネットワーク２２０からデータ・パケットを受信する無線アクセス・ネットワーク（ＲＡＮ）２００を示している。ＲＡＮ２００は、ＢＥ型通信リンクに沿ってコア・ネットワーク２２０から受信したデータ・パケットを処理するためのプロトコル専用プロセッサ（ＰＳＰ）２１０を含む。ＰＳＰ２１０は、特定のタイプのプロトコルを処理するＲＡＮ２００内に位置するあらゆるタイプのプロセッサである。データ・パケットは、たとえばＩＰデータ・パケットでもよい。ＲＡＮ２００とコア・ネットワーク２２０との間に、ＢＥ型通信リンクでデータ・パケットを転送するためのインターフェースが提供される。このインターフェースは、ＲＡＮ２００とコア・ネットワーク２２０との間のパケットの搬送に必要なルータ、スイッチ、または他のネットワーク要素を含んでよい。

ＢＥ型通信リンクは、図１の制御要素１４０によって、ＱｏＳ処理を必要とするものとして特に識別されていないアプリケーションをサービスする通信リンクである。ＢＥ型通信リンクは、たとえばデフォルト・ベアラ通信を含んでよい。

ＰＳＰ２１０によってデータ・パケットが処理された後、データ・パケットは無線インターフェースを介してＲＡＮ２００からアクセス・ターミナル（ＡＴ）２６０にＢＥ型通信リンクで送信される。ＡＴの例には、移動局、モバイル・ユニット、無線電話、無線を装備したＰＤＡまたはコンピュータなどがある。ＡＴ２６０は、ユーザ装置または他の何らかの類似装置と同義でよい。さらに、ＰＳＰ２１０を含むＲＡＮ２００は、これに限定されないが、たとえばＧＳＭ、ＣＤＭＡ、ＵＭＴＳ、ＬＴＥ、およびＷｉＭａｘを含むどのようなタイプの無線技術でも実装され得る。

図２Ｂは、本発明の実施形態による、逆方向リンク上のＢＥ型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムを示している。たとえば、図２Ｂは、ＢＥ型通信リンクでＡＴ２６０からデータ・パケットを受信する無線アクセス・ネットワーク（ＲＡＮ）２００を示している。順方向リンク処理と同様に、ＲＡＮ２００は、ＡＴ２６０から受信したデータ・パケットを処理するためのＰＳＰ２１０を含む。順方向リンク処理とは異なり、逆方向リンクでは、ＰＳＰ２１０は、ＡＴ２６０に逆方向リンク・パケットの処理を修正するよう指示できるように、ＡＴ２６０にパラメータをフィードバックするようにも構成される。ＰＳＰ２１０がＢＥ型通信リンク内のデータ・パケットを処理する方法の詳細は、図３を参照して説明する。

図３は、本発明の実施形態による、逆方向および順方向リンク通信のためのＰＳＰ２１０の機能を示す流れ図を示している。たとえば、ステップＳ３１０で、ＰＳＰ２１０は、コア・ネットワーク２２０（順方向リンク）またはＡＴ２６０（逆方向リンク）のいずれかから処理するために、ＢＥ型通信リンクでデータ・パケットを受信する。ステップＳ３２０で、ＰＳＰ２１０は、順方向または逆方向リンク上で送信されるデータ・パケットについての（ｉ）アプリケーション識別子、および／または（ｉｉ）インターネット層よりも上位の少なくとも１つの層に関連付けられるプロトコルのタイプを取得する。

たとえば、アプリケーション識別子は、データ・パケットに関連付けられるアプリケーションのタイプを識別する識別子である。たとえば、データ・パケットがＳｋｙｐｅ（商標）（たとえば、ＶｏＩＰアプリケーション）に関連付けられる場合、他のタイプのアプリケーションから区別するためにＳｋｙｐｅ（商標）アプリケーションを一意に識別するデータ・パケットとともに識別子が送信される。

インターネット・プロトコル・スイートのための層は、たとえばアプリケーション層、トランスポート層、インターネット層、およびネットワーク層の、４つのプロトコル層を含む。アプリケーション層のためのプロトコルのタイプは、特にＤＮＳ、ＴＦＴＰ、ＴＬＳ／ＳＳＬ、ＦＴＰ、Ｇｏｐｈｅｒ、ＨＴＴＰ、ＩＭＡＰ、ＩＲＣ、ＮＮＴＰ、ＰＯＰ３、ＳＩＰ、ＰＯＰ、およびＳＳＨなどでよい。トランスポート層のためのプロトコルのタイプは、特にＴＣＰ、ＵＤＰ、ＤＣＣＰ、ＳＣＴＰ、ＩＬ、およびＲＵＤＰなどでよい。インターネット層のためのプロトコルのタイプは、ＯＳＰＦなどでよい。ネットワーク・インターフェース層のためのプロトコルのタイプは、特にＡＲＰ、ＲＡＲＰ、ＯＳＰＦ、およびＮＤＰなどでよい。アプリケーション層およびトランスポート層は上位レベルの層と見なすことができ、インターネット層およびネットワーク・インターフェース層は下位レベルの層と見なすことができる。ＯＳＩモデルでは、トランスポート層、セッション・プレゼンテーション層、およびアプリケーション層はインターネット層よりも上位であると見なされる。

一実施形態では、ＰＳＰ２１０は、インターネット層よりも上位の１つ、２つ、または３つ以上の層に関連付けられるプロトコルのタイプを取得できる。さらに、ＰＳＰ２１０は、送信されるべきデータ・パケットに関連付けられるすべての上位レベルの層についてのプロトコルのタイプを取得できる。図４を参照して、上位レベルのプロトコル層についての異なる様々なタイプのプロトコルをさらに説明する。

ＰＳＰ２１０は、データ・パケットを検査することによって、アプリケーション識別子、および／または上位レベルのプロトコル層に関連付けられるプロトコルのタイプを取得できる。たとえば、ＰＳＰ２１０は、下位層のヘッダを削除すること、およびコンテンツを検査することによって、またはディープ・パケット・インスペクション（ＤＰＩ）のために使用される様々な良く知られた技術のうちのいずれかによって、データ・パケットを検査する。さらに、ＰＳＰ２１０は、外部ソース（図示せず）から上位レベルのプロトコル層に関連付けられるアプリケーション識別子、および／またはプロトコルのタイプを取得できる。外部ソースはルータでもよく、パケットに関連付けられるプロパティを決定するためにディープ・パケット・インスペクションまたはヘッダ検査を実行する他のネットワーク要素でもよい。たとえば、外部ソースは、上位レベルのプロトコル層に関連付けられるアプリケーション識別子、および／またはプロトコルのタイプを決定して、それらをＰＳＰ２１０に伝達できる。

ＰＳＰ２１０が少なくとも１つの上位レベルのプロトコル層についてのアプリケーション識別子、および／またはプロトコルのタイプを受信後、ステップＳ３３０で、ＰＳＰ２１０は少なくとも１つの上位レベルのプロトコル層に関連付けられるアプリケーション識別子、および／またはプロトコルのタイプによってパラメータを決定する。

図４は、本発明の実施形態による、上位レベルのプロトコル層に関連付けられるアプリケーション識別子、および／またはプロトコルのタイプに基づくデータ・パケット用のパラメータを示している。たとえば、図４は、アプリケーションおよびトランスポート層パラメータの組合せ、または特定のアプリケーションの識別が、上位層にとって最も適切なパラメータのセットを選択するために使用され得る方法を示している。これらのパラメータは、無線リンク層の機能を制御する。たとえば、パラメータは、上位レベルの層についての取得したアプリケーション識別子、および／またはプロトコルのタイプに関連付けられるどのようなタイプのＱｏＳパラメータでもよい。

本発明の一実施形態によれば、アプリケーション層に関連付けられるプロトコルのタイプがＨＴＴＰと決定され、トランスポート層に関連付けられるプロトコルのタイプがＴＣＰと決定されると、パラメータはそれに従って決定され得る。たとえば、この特定の例では、送信されるべきデータ・パケットについて、アプリケーション層に関連付けられるプロトコルのタイプがＨＴＴＰで、トランスポート層に関連付けられるプロトコルのタイプがＴＣＰの場合、データ・パケットを送信するためのパラメータは以下のように決定される：ＲＬＰ再送が可能であり、ハイブリッドＡＲＱが可能であり、ＩＰヘッダ圧縮が不可能であり、リソース・ホギング保護が不可能であり、また、ＡＴＲＦパワー制御目標、ＢＴＳ／ｅＮｏｄｅＴｘパワー制御目標、アドミッションおよびオーバーロード制御の目標パケット損失レート、ならびにパケット・バッファ・サイズが固定値（たとえば、それぞれＡ１、Ｂ１、Ｃ１、およびＤ１）によって設定される。上述のＨＴＴＰタイプのアプリケーション層、およびＴＣＰのタイプのトランスポート層用のパラメータは説明するために使用されるにすぎず、ＨＴＴＰタイプのアプリケーション層、およびＴＣＰタイプのトランスポート層について、他のタイプのパラメータも使用され得る。さらに、本発明の例示的実施形態は２つのプロトコル層だけに限定されない。たとえば、プロトコルのタイプは、インターネット層よりも上位の１つのプロトコル層、または３つ以上高いレベルの層によって決定され得る。

図４を参照すると、送信されるべきデータ・パケットについて、アプリケーション層に関連付けられるプロトコルのタイプがＲＴＰと識別され、トランスポート層に関連付けられるプトロコルのタイプがＵＤＰと識別される場合、他のセットのＱｏＳパラメータが設定される。たとえば、ＱｏＳパラメータは以下を含むことができる：ＲＬＰ再送が不可能であり、ハイブリッドＡＲＱが不可能であり、ＩＰヘッダ圧縮が不可能であり、リソース・ホギング保護が不可能であり、ＡＴＲＦパワー制御目標、ＢＴＳ／ｅＮｏｄｅＴＸパワー制御目標、アドミッションおよびオーバーヘッド制御についての目標パケット損失レート、ならびにパケット・バッファ・サイズが固定値（たとえば、それぞれＡ２、Ｂ２，Ｃ２、およびＤ２）によって設定される。

さらに、送信されるべきデータ・パケットについて、アプリケーション層に関連付けられるプロトコルのタイプがＦＴＰと識別され、トランスポート層に関連付けられるプロトコルのタイプがＴＣＰと識別される場合、ＲＬＰ再送が可能である。送信されるべきデータ・パケットについて、アプリケーション層に関連付けられるプロトコルのタイプがＰＯＰと識別され、トランスポート層に関連付けられるプロトコルのタイプがＴＣＰと識別される場合、ＲＬＰ再送は可能である。本発明の例示的実施形態は、上位レベルの層の様々なタイプのプロトコルのすべての組合せ、およびそれらの対応するパラメータを包含する。対応するパラメータは、識別されたアプリケーションおよびトランスポート層用の上述のパラメータだけに限定されず、識別されたアプリケーションおよびトランスポート層用の他のパラメータも使用され得る。

さらに、アプリケーション識別子は、パラメータの特定のセットを決定するために使用され得る。図４を参照すると、この特定の例では、アプリケーション識別子がデータ・パケットに関連付けられるアプリケーションはＳｋｙｐｅ（商標）であることを示すと、Ｓｋｙｐｅ（商標）アプリケーションにとって最適なパラメータのセットが決定される。たとえば、ＲＬＰ再送が不可能である。この例はＲＬＰ再送が不可能であることを示しているが、他のタイプのパラメータも設定され得る。さらに、例示的実施形態は、Ｓｋｙｐｅ（商標）タイプのアプリケーションに加えてすべてのタイプのアプリケーションも包含する。

再び図３を参照すると、ステップＳ３３５で、ＰＳＰ２１０は、順方向リンク通信チャネル上でデータ・パケットを送信するための決定されたパラメータを設定する。逆に、ステップＳ３４０で、逆方向リンク上でデータ・パケットを送信するための決定されたパラメータがＡＴ２６０にフィードバックされ、ＡＴ２６０がＰＳＰ２１０によって決定されたパラメータを設定する。

例示的実施形態は、ＲＡＮ内でＱｏＳ処理を受けるよう指定されていないアプリケーションおよびプロトコルのためのＲＡＮ機能を最適化するためのメカニズムを提供する。

本発明の例示的実施形態を説明してきたが、同じことが多くの方法で変化し得ることが明らかであろう。このような変化は本発明の例示的実施形態の趣旨および範囲からの逸脱と見なされるべきではなく、当業者には明らかなように、このようなすべての修正形態は、本発明の範囲内に含まれることを意図する。

Claims

ベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムであって、
パケットが前記ＢＥ型通信リンクで送信されるために、（ｉ）アプリケーション識別子、および（ｉｉ）インターネット層よりも上位の少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを取得して、前記パケットが無線アクセス・ネットワーク（２００）でサービス品質（ＱｏＳ）処理を受けられるように、前記取得した（ｉ）アプリケーション識別子、および（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルの前記タイプのうちの少なくとも１つによる前記パケット用のパラメータを決定するように構成されたプロトコル専用プロセッサ（２１０）を備える、システム。
前記決定されたパラメータが、前記取得した（ｉ）アプリケーション識別子、および（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプのうちの１つに関連付けられるＱｏＳパラメータである、請求項１に記載のシステム。
前記少なくとも１つの層がアプリケーション層およびトランスポート層を含む、請求項１に記載のシステム。
前記少なくとも１つの層が前記インターネット層よりも上位のすべての層を含む、請求項１に記載のシステム。
前記プロトコル専用プロセッサ（２１０）が、（ｉ）アプリケーション識別子、および（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプのうちの前記少なくとも１つを決定するために、前記パケットを検査するように構成される、請求項１に記載のシステム。
前記プロトコル専用プロセッサ（２１０）が、外部ソースから（ｉ）アプリケーション識別子、および（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプのうちの前記少なくとも１つを受信することによって、（ｉ）アプリケーション識別子、および（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプのうちの前記少なくとも１つを決定する、請求項１に記載のシステム。
前記プロトコル専用プロセッサ（２１０）が、前記パケット用の前記パラメータをリアルタイムで決定するように構成される、請求項１に記載のシステム。
前記プロトコル専用プロセッサ（２１０）が、順方向リンク通信のために前記決定されたパラメータを設定するように構成される、請求項１に記載のシステム。
前記プロトコル専用プロセッサ（２１０）が、前記決定されたパラメータを逆方向リンク通信のためにアクセス・ターミナルにフィードバックするように構成される、請求項１に記載のシステム。
前記ＢＥ型通信リンクが、前記ＱｏＳ処理を必要とするものとして特に識別されていないアプリケーションをサービスする通信リンクである、請求項１に記載のシステム。