ＵＴＲＡＮ無線アクセスネットワークにおける無線リソース管理方法、コアネットワークサービスノード、および無線アクセスネットワーク制御装置
本発明は、ＵＴＲＡＮ無線アクセスネットワークにおける無線ネットワーク制御装置により割り当てられる無線リソースを管理する方法に関するものである。上記無線リソースは、コアネットワークによって送信される無線アクセスベアラサービス要求によって各々識別されるサービス要求の多数をサポートし、コアネットワークの対応するＱｏＳパラメータをマッピングすることによりその値が規定されるＲＡＢパラメータの集合の形式で、要求されたＱｏＳを記述するものである。上記制御装置は、様々なベアラサービス間でリソースを分配するために、および、上記各ベアラサービスに関連付けられた優先レベルに従って上記リソース割り当てを調整するために、備えられるものである。上記優先レベルは、ＲＡＢパラメータである「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」のサブパラメータである「ｐｒｉｏｒｉｔｙ ｌｅｖｅｌ」によって規定され、その値は、一方では、コアネットワークのＱｏＳパラメータである上記「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」の値を考慮することにより決定され、他方では、サービスタイプに関連付けられたＱｏＳパラメータの少なくとも１つの値を考慮して決定される。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
本発明は、広く通信分野に関するものであり、特に、パケットモードおよび回線モードにおいて、ＵＭＴＳモバイル通信ネットワークにおけるアクセスネットワークのレベルで無線リソースを管理する方法に関するものである。
【０００２】
つまり、本発明に係る方法は、３ＧＰＰ標準規格の枠組みで標準化されたＵＭＴＳ技術を用いたモバイルネットワーク向けのアプリケーションを対象とする。記載が過多にならないようにするため、使用する全ての頭文字語の定義から成る用語解説を、読み手が有効に参照できるよう、本願明細書の末尾に提供している。
【０００３】
ＵＭＴＳ標準規格は新しいモバイルアクセスネットワークであるＵＴＲＡＮを明確化するものであり、ＵＴＲＡＮによって、携帯電話事業者の加入者に対してＩＰに基づくサービス（電子メッセージ、ファイルのダウンロード、ｗｅｂまたはＷＡＰサイトのコンサルテーション（consultation））または回線サービス（電話、テレビ電話）を提供することが可能となる。現時点では、ＵＭＴＳは導入段階であり、英語で「releases（リリース）」と呼ばれる様々なバージョンが存在する。特にリリース９９と呼ばれるバージョンについては、詳細に後述する。
【０００４】
アーキテクチャに関して言及すれば、ＵＭＴＳネットワークは、図１に示すように、コアネットワークＣＮと、ＵＴＲＡＮと称される無線アクセスネットワークとの、２つのサブネットワークに分割できる。
【０００５】
アクセスネットワークは、ＲＮＣ制御装置によって割り当てられる無線リソースを用いることにより無線インタフェースを通して利用者端末ＵＥに通信を提供する無線基地局ＮｏｄｅＢを多数備える。ある構成要素がいくつかの下位層の構成要素を制御するような階層的構造は、ＧＳＭ無線アクセスネットワークと同じである。ＲＮＣ無線ネットワーク制御装置は、ＧＳＭの基地局コントローラ（ＢＳＣ）の位置を保持している。しかし、情報転送に用いている無線技術は異なるものである。
【０００６】
ＵＭＴＳのコアネットワークＣＮは、電話に関する全てのサービスを含む回線システムＣＳと、パケット交換に関する全てのサービスを含むパケットシステムＰＳとの２つの別々のシステムを含んでいる。
【０００７】
コアネットワーク層には、上記両システムに共通なデータベースであるＨＬＲがある。ＨＬＲは、ネットワーク事業者の各加入者に関する情報（加入情報のみならず加入者の電話番号およびモバイルの識別子も含む）を格納している。ＨＬＲは、また、他の事項に加えて、加入者とサービスとに関する、サービスの質の情報を含んでいる。このサービスの質の情報に関しては、後に詳細に定義する。すなわち、上記データベースにより、ネットワーク内のモバイル加入者は管理される。
【０００８】
また、コアネットワークは、ＭＳＣ回線スイッチとＳＧＳＮパケットスイッチとを備える。コアネットワークのこれらサービスノードは、アクセスネットワーク内の通信リンクを管理する。これらのサービスノードは、ＨＬＲから送られて来る加入者プロファイルを格納しており、加入者により要求されたネットワークリソースを監視する。
【０００９】
パケットシステム層では、ＳＧＳＮは、他のサービスノードＧＧＳＮと接続されている。このＧＧＳＮは、パケット交換ネットワークの外側（例えば、インターネットなど）へのゲートウェイとして特に動作するものである。パケットシステムに関して言えば、ＵＭＴＳのコアネットワークは、ゲートウェイであるＧＧＳＮサービスノードを介して外部と接続されている。このゲートウェイは、セキュリティを保証すると同時に、モバイル電話が外部ネットワーク、特に、インターネットとの通信を可能とするためのルーティング情報を含むものである。モバイル電話に情報を送信できるようにするため、ＧＧＳＮは他のサービスノードであるＳＧＳＮを使用する。ＳＧＳＮは、コアネットワーク層のモビリティー（mobilite）、認証、および、暗号化を管理するものである。これらのネットワーク構成要素はＩＰルータの機能を統合し、ＩＰ系ネットワークを構成する。
【００１０】
回線システム層では、パケットシステムでの説明と同様に、ＭＳＣが他のサービスノードＧＭＳＣと関連している。ＧＭＳＣは、ＲＮＣタイプやＲＮＩＳタイプなどの定常（fixe）ネットワークへのゲートウェイとしての役目を果たすものである。
【００１１】
リリース９９では、全てのＵＭＴＳサービスは、次に示す４つの標準化されたトラフィッククラスによってサポートされている。すなわち、“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”（会話）、“Ｓｔｒｅａｍｉｎｇ”（ストリーミング）、“Ｉｎｔｅｒａｃｔｉｖｅ”（インタラクティブ）、“Ｂａｃｋｇｒｏｕｎｄ”（バックグラウンド）である。
【００１２】
“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”および“Ｓｔｒｅａｍｉｎｇ”クラスは、音声あるいは映像などのリアルタイムストリームを主に転送するために備えられるものである。しかしながら、利用者がリアルタイム映像（または音声）を観る（または聴く）場合に使用されるタイプに相当する“Ｓｔｒｅａｍｉｎｇ”クラスは、データ転送の時間的制約が“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”クラスよりも少ない。
【００１３】
“Ｉｎｔｅｒａｃｔｉｖｅ”および“Ｂａｃｋｇｒｏｕｎｄ”クラスは、非リアルタイムサービスに対応し、ナビゲーション、電子メール、ＦＴＰアプリケーションなどの従来のインターネットアプリケーションの枠組み内で使用されるために提供されるものである。非リアルタイムであることから、これらのクラスは再転送およびエンコード方式によってより低いエラー率を提供している。
【００１４】
本発明は、リソース、特に、アクセスネットワーク内における無線リソースの分配の管理に関する。このような管理には、サービス要求に関連付けられた、サービスの質（ＱｏＳ）のパラメータを考慮することが必要とされる。
【００１５】
ＵＭＴＳベアラサービスのＱｏＳパラメータは、ベアラサービスの利用者に対してＵＭＴＳネットワークにより提供されるサービスを記述する。ＱｏＳパラメータ一式から成るＱｏＳプロファイルが、このサービスを記述する。すなわちこれらは、特にスループット、トラフィックのタイプ、優先度などのネットワーク上のデータストリームの主な特性を規定することができる標準化されたパラメータである。このデータはＨＬＲ内の加入者プロファイルに格納されており、様々な手段によってＳＧＳＮおよびＭＳＣに転送される。
【００１６】
パケットシステムの加入者のＱｏＳプロファイルは、実際には、加入者によって要求される特定の値に関する許容上限に相当する。また、ＱｏＳプロファイルは事業者によって設定される初期プロファイルにも相当しうる。
【００１７】
ＱｏＳプロファイルに記述される主なＱｏＳパラメータは以下のとおりである。
【００１８】
・“Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”（ＡＲＰ）：このＱｏＳにより、ＵＭＴＳベアラサービスの割り当ておよび保持に関して、いくつかの加入者間のトラフィックを優先付けることができる。このタイプのパラメータは、パケットシステムと回線システムとのそれぞれについて個別に記述される。
【００１９】
・“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”（トラフィッククラス）：このＱｏＳパラメータは、サービスタイプに関連付けられた優先度を表すものである。リリース９９にみられるように、全てのサービスは４つのトラフィッククラスによりサポートされている。そこで、このＱｏＳパラメータは、“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”（リアルタイムな要求は非常に重要であるため、高優先レベルに相当）、“Ｓｔｒｅａｍｉｎｇ”、“Ｉｎｔｅｒａｃｔｉｖｅ”、“Ｂａｃｋｇｒｏｕｎｄ”（低優先）の値をとることができる。
【００２０】
・“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”（ＴＨＰ）（トラフィックハンドリング優先度）：このＱｏＳパラメータにより、“Ｉｎｔｅｒａｃｔｉｖｅ”トラフィッククラス向けの優先レベルを記述することができる。このパラメータは３つの値をとることができ、それにより、互いに関連する“Ｉｎｔｅｒａｃｔｉｖｅ”タイプのプロファイルを優先付けすることができる。
【００２１】
上記のパラメータに加えて以下のパラメータについても記述するが、本発明の枠組みでは使用しないので、情報提供の目的として記載する。
【００２２】
・“Ｔｒａｎｓｆｅｒ Ｄｅｌａｙ”（転送遅延）：このＱｏＳパラメータは、パケットの最大転送遅延を提供する。このＱｏＳパラメータはリアルタイムサービスでのみ使用される。
【００２３】
・“Ｇｕａｒａｎｔｅｅｄ ｂｉｔ ｒａｔｅ”（保証されたビットレート）：このＱｏＳパラメータはパケット転送の保証されたスループットを表す。このＱｏＳパラメータはリアルタイムサービスでのみ使用される。
【００２４】
・“Ｍａｘｉｍｕｍ ｂｉｔ ｒａｔｅ”（最大ビットレート）：このＱｏＳパラメータは最大スループットを表す。
【００２５】
上記すべてのＱｏＳパラメータは３ＧＰＰテレコミュニケーション標準規格の枠組み内で規定されているものである。しかし、これらの使用方法は標準化されていない。
【００２６】
ＵＭＴＳリリース９９において、ＨＬＲのレベルで、標準規格は、パケットおよび回線サービス向けに加入者データの中に優先レベルを持たせる可能性を見越している。“Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”（ＡＲＰ）が上記目的に使用されている。このパラメータは、パケットシステムでは登録されたＰＤＰコンテキスト毎に、または、回線システムでは加入者毎に、コアネットワークのＨＬＲレベルで通知される。
【００２７】
ＡＲＰパラメータによって、加入者間での無線リソースの割り当て／保持の優先度を決めることができる。ＡＲＰパラメータは、ＭＳＣ、ＳＧＳＮ、ＧＧＳＮで使用されており、コアネットワークでは次の３つの値をとることができる。すなわち、優先度１、優先度２、そして優先度３である。優先度３が最も低い値である。
【００２８】
ＡＲＰパラメータは、加入者からのサービス要求に対応する通信に優先レベルを関連付けるため、４つのサブパラメータの形式でＵＴＲＡＮのＲＮＣに送信される。そして、このパラメータは、ＵＴＲＡＮのＲＮＣに送信するためにコアネットワーク層で次の４つのサブパラメータに変換される。すなわち、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”（優先レベル）、“Ｐｒｅ-ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ”（プリエンプション能力）、“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”（プリエンプションの受けやすさ）、“Ｑｕｅｕｉｎｇ Ａｌｌｏｗｅｄ”（許容されるキューイング）である。これらの値は、コアネットワークのＡＲＰパラメータから得られる。これら４つのサブパラメータは３ＧＰＰ標準規格のＴＳ２５．４１３においてより詳細に定義されている。
【００２９】
ＵＴＲＡＮは、コアネットワークＣＮから送信される優先パラメータを使用して、システムの様々な利用者間で全てのリソース（例えば、無線リソース、転送リソース、処理容量）を割り当てる能力がなければならない。
【００３０】
ＰＤＰコンテキストのアクティベーション手続きを、図２を参照して記載する。モバイルＭＳ端末は、ＳＧＳＮおよびＧＧＳＮに格納されているＰＤＰコンテキストを要求することができ、また、加入者が望むサービスを実行するためのコアネットワークにおけるリソースを確保することができる。ＰＤＰコンテキストのアクティベーションの間、要求されたＰＤＰコンテキストおよび加入者の契約情報、特にＡＲＰパラメータで定義されるトラフィッククラスおよび加入者の優先度に関連付けられたサービスの質の情報をＵＴＭＳネットワークの様々なノードが受信する。
【００３１】
加入者の優先度に相当する情報、つまり、加入者が登録するＰＤＰコンテキストを定義するデータに含まれるＡＲＰパラメータは、加入者の場所が特定されたときにＳＧＳＮへ転送される。そして、この情報はＰＤＰコンテキストが加入者によってアクティベーションされたときにＧＧＳＮへ転送され、そして上述した４つのサブパラメータの形式でＲＮＣに転送される。
【００３２】
ＰＤＰコンテキストをアクティベーションする手続きは、加入者が、加入しているサービスを実行するためにネットワーク上にデータを送信または受信したいときに発生するものであり、モバイル加入者の最初の操作段階において実行されるものである。その結果、加入者によって要求された外部ネットワークとの相互接続要求を実行するＧＧＳＮサービスノードに端末を知らしめることができる。ＰＤＰコンテキストをアクティベーションする手続きの後、対応するサービスの質のプロファイルがネットワーク上の様々なノード間で交換され、そして、ＵＭＴＳネットワークと加入者が要求したサービスに対応する外部ネットワークとの間でデータ転送が開始される。
【００３３】
第１ステップでは、所望のＱｏＳを記述することにより、モバイルＭＳ端末が、親であるＳＧＳＮからのＰＤＰコンテキストのアクティベーションを要求する。ＳＧＳＮは、加入者データおよび他のパラメータに従って、要求されたＱｏＳを修正してもよい。
【００３４】
第２、第３ステップでは、ＳＧＳＮが、修正したＱｏＳパラメータとともに上記要求をＧＧＳＮに中継する。そして、これはネゴシエートされたＱｏＳに関する質問となる。そしてＧＧＳＮはＱｏＳを再修正し、それをＳＧＳＮに返送する。
【００３５】
第４、第５ステップでは、ＳＧＳＮは、無線アクセスベアラサービスに対する要求の形式でネゴシエートされたＱｏＳを記述することにより、要求された無線リソースをＲＮＳが割り当てることを要求する。無線アクセスベアラサービスは、特にコアネットワークのＡＲＰパラメータから得られるトラフィッククラスおよび４つのサブパラメータを含むＲＡＢパラメータの組で構成される。ＲＡＢパラメータは３ＧＰＰ標準規格ＴＳ２５．４１３のｖ４．０．０の９．２．１．３節に定義されている。
【００３６】
ＲＮＣは、上記要求を考慮するとともに、ＲＡＢパラメータを使って、サービス要求に対応するために必要な無線リソースを算出する。ＲＮＣは、要求されたリソースが使用可能であるかを検証し、使用可能でない場合は、すでに呼び出されているサービスのパラメータと新たな要求のパラメータとに基づいて、リソース不足を管理しなければならない。そしてＲＮＣは、要求された無線アクセスベアラサービスを許容または拒否する。
【００３７】
第６ステップでは、ＳＧＳＮが、ネットワーク上で得られたサービスの質を送信することによりモバイル電話からの要求を受けつける。
【００３８】
回線システムの層では、ビデオ電話タイプの発呼要求を例にあげる。第１ステップでは、モバイル電話がコアネットワークにサービス要求を送信する。要求されたＱｏＳの特性は、ベアラネットワークの容量（ベアラ伝送能力）に関連するフィールドに含まれている。スループット、望ましい接続形式については後述する。第２ステップでは、要求はＲＮＩＳタイプの定常（fixe）ネットワークに中継される。
【００３９】
最後に、コアネットワークが、ＲＡＢパラメータの形式でサービス要求を指定することにより、対応する無線リソース割り当て要求を送信する。ＲＮＣはこのサービス要求を持続するために必要なリソースの算出を実行する。ＲＮＣはこれらリソースが使用可能であるかを検証し、使用可能でなければ、すでに呼び出されているサービスのパラメータと新たな要求のパラメータとに基づいてリソース不足を管理しなければならない。そしてＲＮＣは要求されたＲＡＢを許容または拒否する。
【００４０】
考慮しなければならない重要な制約の一つとして、ＵＴＲＡＮはＣＮによって送信される優先度パラメータを使用するシステムの様々な利用者間で全てのリソース（無線リソース、転送リソース、処理能力）を分配することができなければならない。これを達成するために、標準規格に規定されているプリエンプション手続きを実行することができる。これにより、要求されたＱｏＳに返答するために使用可能なリソースがないときに、優先権を有しているとネットワーク事業者に見なされる利用者またはサービスがリソースを容易に獲得することができる。
【００４１】
ＣＮによって送信される優先度パラメータはＲＡＢパラメータの一部であり、以下のとおりである。すなわち、
− Ｔｒａｆｆｉｃ Ｃｌａｓｓ
− Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ
− Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ
である。
【００４２】
Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙは、次の４つのサブパラメータから構成される。すなわち、
− Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ
− Ｐｒｅ−ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ
− Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ
− Ｑｕｅｕｉｎｇ Ａｌｌｏｗｅｄ
である。
【００４３】
これらのパラメータにより、コアネットワークからのサービス要求に相当する各種無線アクセスベアラサービスのＲＡＢ間でリソースを割り当てるための優先レベルを規定することができる。さらに、新たなサービス要求の応答に必要なリソースが不十分である、または、使用可能でない場合には、標準規格に規定されているプリエンプション手続きがこの優先レベルに基づいて実行されてもよい。
【００４４】
実際には、プリエンプション手続きは、優先度の高い要求に対する応答に十分なリソースを当てられるように、利用者にすでに割り当てたリソースを減少させることが可能なアルゴリズムを使用している。
【００４５】
この点について、図３に、ＵＴＲＡＮリソースＣの様々な使用レベルを示す。これは、時間ｔの経過に応じたネットワークの様々な負荷のシナリオを示している。これら様々なシナリオにより、プリエンプション手続きを使用する場合を規定することができる。閾値Ｓは、過負荷であると考えられる領域を区切るものである。ここからわかることは、あるタイプのリソースに関しては、この閾値を超えることはない（物理的に全てのリソースが使用されており、そのような場合、追加可能なリソースが参照される）。逆に、他のタイプのリソース、非可算リソースに関しては、ある期間は閾値Ｓを超えてもよい。
【００４６】
領域１は、正常領域ともいうが、リソースの使用になんら制限がない。実際のところ、リソースを割り当てる新たな要求に応答するための十分なリソースがあり、プリエンプション手続きを使用する必要はない。換言すれば、ネットワーク上で現在使用されているリソースＣと、リソース割り当ての新たな要求を要求されたサービスの質で満たすのに必要なリソースＲとの合計は、過負荷領域を区切る閾値Ｓより小さい。よって、ここで検証することは、Ｃ＋Ｒ＜Ｓである。
【００４７】
領域２は、過負荷に近い領域であり、依然として使用可能なリソースは存在するが、これら使用可能なリソースだけでは新たなリソース割り当て要求に対する応答には不十分である。つまり、ネットワーク上のリソースＣの使用レベルが過負荷領域を区切る閾値Ｓより低いが、新たなリソース割り当て要求を満足するために必要なリソースＲが、要求されたサービスの質とともに、使用される全てのリソースの一部として見なされた場合、過負荷領域である領域３へ入るものが生じる。つまり、Ｃ＋Ｒ＞ＳかつＣ＜Ｓである。
【００４８】
このような状況においては、ネットワーク上でリソース割り当ての新たな要求に応答するためのいくつかの方策が前もって立てられる。
− 率直にかつ簡単に要求を拒否する。
− または、要求は受けつけるが、過負荷領域に入らないように、割り当てるリソースの量を要求された量よりも少なくする。
− もしくは、サービスの質に従って要求を受けつけ、要求に対して十分な応答をするために必要なリソースを補うために、プリエンプション手続きが引き起こされる。
【００４９】
過負荷領域３では、リソースの使用レベルは、過負荷領域を区切る閾値と等しいか、またはそれよりも大きい。この状況では、Ｃ＞＝Ｓという関係を検証する。
【００５０】
換言すると、この領域では、その瞬間に使用されているリソースのレベルに相当するネットワークの実際の負荷は、過負荷領域を区切る閾値よりも大きいかまたはそれと等しい。そして、ネットワークは過負荷または飽和状態である。この領域３においては、新たなＲＡＢの構築または、ネットワーク内にすでに受け入れられているＲＡＢのトラフィックにおける変化、あるいはＲＡＢのモビリティー（mobilite）に応答するためのＲＡＢの再構成要求といった、いかなる新たなリソース割り当て要求も、負荷レベルが過負荷閾値を下回るまで拒否される。
【００５１】
このように、ある状況下では、ＵＴＲＡＮリソースの一般的な使用レベルであっても、要求されたサービスの質を伴う新たなリソース割り当て要求に対する応答が問題になることが知られている。要求されたサービスの質に従った新たな要求に対する応答のために必要なリソースを正確に補う目的でプリエンプション手続きを引き起こすことは、優先権を有すると事業者に見なされた利用者がリソースを容易に利用するために必要不可欠である。
【００５２】
上記の理由で、３ＧＰＰ標準規格に準ずるＵＴＲＡＮにおけるリソースを優先的に割り当てるための手続きに対する照会は、極端に簡潔なもので、それにより基本的に規則の簡単な設定が行われる。その規則に従って、優先度の昇順に、低い優先度を有するＲＡＢをプリエンプトすることができる機構をＵＴＲＡＮ単独で実現する。しかしながら、他のＲＡＢとの関係でＲＡＢに優先レベルを割り当てる基準については、標準規格に記述されていない。それゆえ、ＵＴＲＡＮレベルで無線リソースへのアクセスが優先順位付けされる方法は、プリエンプション手続きを使用する様々なケースと同様に、実現されていない。それは、ＵＭＴＳ事業者にとって非常に重要な概念を含んでいる。なぜならば、それらは、例えば、加入者の様々なクラスに対してアクセスネットワークの無線リソースを共有および割り当てるための戦略を定義する主要な役割を果たすからである。
【００５３】
従って、本発明の目的は、無線アクセスネットワークレベルでサービスと加入者間の無線リソースを優先付けることによって、ＵＭＴＳアクセスネットワークのリソースを共有および割り当てる戦略を最適化できるようにするため、ＣＮから送られてくるサービス要求に相当する様々なＲＡＢの間で、ＵＴＲＡＮ内で優先度の異なる多数のレベルを規定することである。
【００５４】
本発明のもう一つの目的は、確立された優先順序を使って、ＵＭＴＳアクセスネットワークレベルで無線リソースを優先的に占有するための手続きを使用する様々なケースを規定することである。
【００５５】
それゆえ、本発明は、ＵＭＴＳタイプのモバイル通信ネットワークにおける無線リソースを管理する方法に関するものである。上記無線リソースは、利用者端末によってＵＭＴＳネットワークのコアネットワークへ送信される多数のサービス要求をサポートするために、ＵＴＭＳネットワークの無線アクセスネットワークの無線アクセス制御装置によって割り当てられるものである。上記サービスのそれぞれは、コアネットワークの構成要素の内部に記録されているサービスの質のパラメータの組によって指定されるものである。上記サービス要求のそれぞれは、対応する無線リソース割り当て要求をコアネットワークが上記無線ネットワーク制御装置に送信することにより処理され、上記無線リソース割り当て要求は、無線アクセスに対するベアラサービス要求を含み、当該ベアラサービス要求は、コアネットワークにおける対応するサービスの質のパラメータをマッピングすることによりその値が規定されるＲＡＢパラメータの集合の形式で、要求されたサービスの質を記述するものである。上記無線ネットワーク制御装置は、様々なサービス要求に対応する様々な無線アクセスベアラサービスの間でアクセスネットワークの無線リソースを分配するため、および、上記各ベアラサービスに関連付けられた優先レベルに従って上記ベアラサービスに対するリソース割り当てを調整する目的で上記リソースを優先的に割り当てるプリエンプション手続を行うために備えられるものであって、それにより、上記ベアラサービスの優先レベルに基づいて、上記ベアラサービスに対して要求されたサービスの質を満たすものである。上記優先レベルは、ＲＡＢパラメータである「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」のサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」によって各ベアラサービスに対して規定され、上記優先レベルの値は、一方では、コアネットワークのサービスの質のパラメータである上記「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」の値を考慮することにより決定され、他方では、サービスタイプに関連付けられた、サービスの質のパラメータの少なくとも１つの値を考慮することにより決定される。
【００５６】
本発明のある実施形態によれば、サービスの質のパラメータは、対応するベアラサービスに対して優先レベルを規定する“ｐｒｉｏｒｉｔｙ ｌｅｖｅｌ”サブパラメータに割り当てられる値を決めるために使用されるサービスタイプに関連し、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータを含むものである。
【００５７】
他の実施形態によれば、サービスの質のパラメータは、対応するベアラサービスに対して優先レベルを規定する“ｐｒｉｏｒｉｔｙ ｌｅｖｅｌ”サブパラメータに割り当てられる値を決めるために使用されるサービスタイプに関連し、互いに関連するｉｎｔｅｒａｃｔｉｖｅタイプのサービスを優先付けすることができる“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”パラメータをさらに含むものである。
【００５８】
ある特徴によれば、アクセスネットワークレベルでリソースを優先的に占有するための手続きは、無線アクセスに対する新たなベアラサービス要求を無線ネットワーク制御装置が少なくとも一つ受信する場合、使用可能な無線リソースがないか、または、新たな要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、実行されるものである。
【００５９】
別の特徴によれば、アクセスネットワークレベルでリソースを優先的に占有するための手続きは、上記ネットワークで既にアクティブな少なくとも一つのベアラサービスによってもたらされる上記ネットワーク上のトラフィックにおける変化に応答するための追加リソース要求を無線ネットワーク制御装置が少なくとも一つ受信する場合、使用可能な無線リソースがないか、または、新たな要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、実行されるものである。
【００６０】
好ましくは、ネットワーク内で既にアクティブである少なくとも２以上のベアラサービスがそれぞれ追加リソースの要求をしており、上記要求を満たすために必要なリソースは使用可能である場合、上記各ベアラサービスに関連付けられた優先レベルに基づいて、どの上記ベアラサービスに追加リソースが優先的に割り当てられるかを決定するために、リソースを割り当てるための優先順位付けステップが実行される。
【００６１】
好ましくは、ネットワーク内で既にアクティブである少なくとも２以上のベアラサービスが、最適な方法で割り当てられているリソースを使用しない場合、上記ベアラサービスに割り当てられているリソースを、上記各ベアラサービスに関連付けられた優先レベルによって定まる順に減少させるために、優先順位付けステップが上記ベアラサービス間で実行されることである。
【００６２】
例示であって限定されない目的で与えられる、後述する望ましい典型的な一実施形態における記載を読めば、本発明をより理解でき、他の詳細および利点がわかるであろう。後述の記載は以下の添付図面を参照する。
【００６３】
図１は、ＵＴＭＳネットワークのアーキテクチャを示しており、既に説明したとおりである。
【００６４】
図２は、パケットシステムに対してＰＤＰコンテキストをアクティベーションするための手続きを示しており、既に説明したとおりである。
【００６５】
図３は、ＵＴＲＡＮにおけるリソースの様々な使用レベルを示す概略図であり、既に説明したとおりである。
【００６６】
従って、すでに説明したように、ＵＴＲＡＮはシステムの様々な利用者間で全てのリソースを分配することができなければならない。これを達成するために、ネットワーク事業者に優先権があると見なされる無線アクセスベアラサービスあるいはＲＡＢに対するリソースを容易に利用する目的で、ＵＴＲＡＮ無線ネットワーク制御装置のレベルでプリエンプション手続きを実行する必要がある。
【００６７】
上記を達成するために、本発明では、ＵＴＲＡＮ内のＲＡＢに対するリソースに優先付きでアクセスするのに用いられる、様々なＲＡＢ間で多数の優先レベルを規定し、リソース割り当てにおいてリソースが不十分である、または使用できない時に、他のＲＡＢよりも優先されるＲＡＢを選択可能とすることを提案する。
【００６８】
これら様々な優先レベルの値は、リソース管理アルゴリズム、特に、リソースを優先的に占有する手続きを要求するアルゴリズムによって使用されるために備えられる。これにより、いくつかのＲＡＢが同じリソースを獲得するために競合したときに、無線アクセスネットワークのレベルで各ＲＡＢに割り当てられるリソースの割り当てを決めることができる。発明に係る優先レベルの値は、ＲＡＢからの要求を満たすために必要なリソースが使用できないかまたは、アクセスネットワークにおける負荷レベルを持ちこたえるという点で不十分であるときに、プリエンプション手続きによって使用される。それゆえ、要求したＲＡＢがアクセスネットワークレベルでリソースを優先的に占有するための権利を有しているかどうか、そしてこの場合、どのＲＡＢがプリエンプトされるリソースを有しているかを決定する目的で、プリエンプション手続きは、各ＲＡＢに関連付けられた、本発明に係るこれらの優先レベルの値を使用するために設けられる。
【００６９】
本発明に係る重要な特徴の一つに、アクセスネットワークレベルで無線リソースを割り当てるための様々なＲＡＢに関連付けられた様々な優先レベルは、コアネットワーク、特に、コアネットワークのＳＧＳＮおよび／またはＭＳＣサービスノードからＲＮＣに送信されるＲＡＢパラメータに基づいて事業者が構成できなければならない。様々なＲＡＢパラメータは、実際のところ、コアネットワークからアクセスネットワークへ送られてくるサービスの質のパラメータを用いてマッピングすることにより得られる。
【００７０】
従って、ＲＡＢパラメータには、以下のパラメータがある。すなわち、
− （１）“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”
− （２）“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”
− （３）“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”
である。
上記（１）および（２）のＲＡＢパラメータはそれぞれ、コアネットワークから送信され、サービスタイプに関連付けられた、対応するＱｏＳパラメータである“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”および“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”、および、加入者の優先レベルに関連付けられたＲＡＢパラメータを用いて直接マッピングすることにより得られる。
【００７１】
上記（３）は、コアネットワークのＱｏＳパラメータである“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”から導き出される以下の４つのサブパラメータから構成される。すなわち、
− “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”
− “Ｐｒｅ-ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ”
− “Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”
− “Ｑｕｅｕｉｎｇ Ａｌｌｏｗｅｄ”
である。
【００７２】
つまり本発明は、コアネットワークからアクセスネットワークに向けたサービスの質のパラメータの新たなマッピングを前もって実行し、その結果として、ＡＲＰパラメータに統合される４つのＲＡＢサブパラメータを決定する際に、コアネットワークのＡＲＰパラメータの値だけでなく、サービスタイプに関連付けられたＱｏＳパラメータの値をも考慮する。
【００７３】
より正確には、リソース割り当てを管理するための、発明に係る優先レベルは、ＲＡＢパラメータである“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”の“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータによってＲＡＢ毎に決定される。その値は、コアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータの値と、サービスタイプに関連付けられた少なくともひとつのＱｏＳパラメータの値とを考慮して決定される。サービスタイプに関連付けられたＱｏＳパラメータは、本発明に係る優先レベルを規定するための“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”サブパラメータに割り当てられる値を決めるために使用され、第１の実施形態においては、４つの値をとりうる“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータを含む。第２の実施形態においては、使用されるＱｏＳパラメータは、サービスタイプに関連付けられ、３つの値をとりうる“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”パラメータをさらに含む。これにより、Ｉｎｔｅｒａｃｔｉｖｅタイプ（つまり、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータが値“Ｉｎｔｅｒａｃｔｉｖｅ”をとる）のサービスを優先付けまたは優先レベルにより順位付けすることができる。
【００７４】
このように、ＱｏＳパラメータ“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”およびコアネットワークのＱｏＳパラメータ“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”を使用することにより、様々なＲＡＢ間で“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータに対して最大で１２の値、つまり、１２段階の優先レベルを規定することができる。
【００７５】
さらに、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータと、コアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータと、“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”パラメータを使用することにより、様々なＲＡＢ間で“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータに対して最大で１８の値、つまり、１８段階の優先レベルを規定することができる。
【００７６】
各ＲＡＢに関連付けられたサービス／加入者の組合せに対する優先レベルの、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータを使用した第１の規定例を表１に示す。これは、アクセスネットワーク内のリソースの割り当て／保持を管理するために使用される。
【００７７】
【表１】
【００７８】
“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ”に割り当てられる値Ｙは、関連付けられたＲＡＢが他のＲＡＢのリソースを優先的に占有することができることを示しており、値Ｎはその逆である。同様に“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”に割り当てられる値Ｙは、関連するＲＡＢがリソースを他のＲＡＢによってプリエンプトされるかもしれないことを示しており、値Ｎはその逆である。
【００７９】
上述の例から、次に示すように、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータを使用したリソースの割り当て／保持のための様々なＲＡＢ間での優先順位の規定が得られる。“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータは、一方ではコアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータの値をＲＡＢ毎に考慮して決定され、他方では“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータの値を考慮して決定される。
【００８０】
すなわち、
“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝１であるＲＡＢ ＞ “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝２であるＲＡＢ ＞ ・・・ ＞ “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝１１であるＲＡＢ ＞ “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝１２であるＲＡＢ、
というように決定される。 よって、本発明に係る優先レベルが５であるＲＡＢは、本発明に係る優先レベルが６〜１２であるＲＡＢに割り当てられているリソースを優先的に占有できる。
【００８１】
各ＲＡＢに関連付けられたサービス／加入者の組合せに対する優先レベルの、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータを使用した第２の規定例を表２に示す。これは、アクセスネットワーク内のリソースの割り当て／保持を管理するために使用される。各ＲＡＢに対する“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータの値は、今回は、コアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータの値と、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”ＱｏＳパラメータの値とに加えて、“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”サービスタイプに関連付けられたＱｏＳパラメータの値を考慮して決められる。この例は、このタイプのサービス（“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”および“Ｓｔｒｅａｍｉｎｇ”）に対して、“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”サブパラメータに割り当てられている値Ｎに示すように、リアルタイムサービスが自身のリソースをプリエンプトされないネットワーク構成に関する。
【００８２】
【表２】
【００８３】
ここでされた優先レベルは、いくつかのＲＡＢが同じリソースを獲得するために競合したときにリソースへのアクセスを優先順位づけするために、リソース管理アルゴリズムによって使用される。さらに、上記優先レベルは、割り当てるのに必要なリソースが不十分である、または、使用できない場合、どのＲＡＢのリソースをどのＲＡＢが優先的に占有するかを決めるために、プリエンプション手続を実行するアルゴリズムによって使用される。
【００８４】
特に、プリエンプション手続は、アクセス制御ステップ、つまり、ＲＮＣが新たなＲＡＢ要求を受信したときに、使用される。新たなＲＡＢ要求は、アクセスネットワークでの新たなＲＡＢの確立により生じるか、または、アクセスネットワーク内にすでに入っているＲＡＢに対するモビリティー（mobilite）手続により生じる。
【００８５】
この場合、図３に示すように、システムの負荷レベルが領域２または３、つまり、使用可能なリソースが存在するが新たな要求に対して応答するのに不十分であるときか、または、使用できるリソースがないときに、新たなＲＡＢの優先レベルとシステム内でアクティブなＲＡＢの優先レベルとによって必要とされるリソースを補うために、リソース管理アルゴリズムによってプリエンプション手続が利用される。
【００８６】
さらにプリエンプション手続は、要求を満たすネットワーク内のリソースが使用可能ではないか、または、不十分であるときに、追加のリソースを要求した結果として、ネットワーク内ですでにアクティブなＲＡＢのトラフィックの変化に応じたトラフィック制御の呼び出し中に使用されるために設けられる。これには個々の制御オペレーションが含まれる。プリエンプション手続によって、低優先レベルのＲＡＢに割り当てられているリソースが減少し、リソースの要求をした高優先レベルのＲＡＢにリソースが再割り当てされる。
【００８７】
ネットワークの負荷レベルが領域１であって、そのためリソースに制約が無い場合であっても、上記ネットワークはすでにアクティブなＲＡＢの様々なスループットに対応できなければならない。その結果として、利用者に割り当てられているリソースが必要に応じて動的に調整されることとなる。よって、２またはそれ以上の利用者が同時に追加リソースの要求をした場合は、リソース管理アルゴリズムが各ＲＡＢに関連付けられた優先レベルに基づいてリソース割り当てを優先順位付けするため、高優先レベルのＲＡＢが優先的に使用される。
【００８８】
逆に、ネットワーク上にリソースの制約が無く、２またはそれ以上の利用者が最適に割り当てられたリソースを使用しない場合、関連する各ＲＡＢに関連付けられた優先レベルがトラフィック制御の枠組み内で使用され、割り付けられたリソースが減少する。この場合、まず低優先レベルのＲＡＢがリソースを減らされ、次により高い優先度のＲＡＢがリソースを減らされ、最後に関連するＲＡＢの中で最も高優先レベルのＲＡＢがリソースを減らされる。
【００８９】
領域２および３において、領域１と同様に、いくつかの利用者がリソースを最適に使用していない場合、関係する各ＲＡＢに関連付けられた優先レベルはトラフィック制御の枠組みで使用され、割り当てられたリソースは減少する。この場合、割り当てられたリソースを減少させる順番は本発明によって規定される各ＲＡＢの優先レベルによって規定される。
【００９０】
最後に、プリエンプション手続はまた、グローバルなトラフィック制御の枠組み内で、システムの負荷の変化に応じた呼び出し中に実行されうる。特に、ネットワークの負荷レベルが領域３のとき、リソースの使用レベルをより安定した値に戻す必要がある。この場合、トラフィック制御の枠組みで実行されるプリエンプション手続はシステム内の負荷レベルを減少させることを目指す。これを達成するために、プリエンプション手続は、各ＲＡＢに関連付けられた優先レベルを使用することによって、割り当てられたリソースを減少させることができる、アクティブなＲＡＢ間の順序を確立する。最も低い優先レベルのＲＡＢは最初にリソースを減らされ、次により高い優先レベルのものがリソースを減らされ、そして、もしネットワークの負荷が許容レベルに戻らなければ、最後に最も高い優先レベルのものがリソースを減らされる。
【００９１】
〔用語解説〕
この用語解説では、本特許出願書類で使用される英文字の頭文字語を一覧で示す。
これらの頭文字語は３ＧＰＰテレコミュニケーション標準規格の枠組み内で定義されている。
３ＧＰＰ 第３世代移動体通信システム標準化プロジェクト（Third-Generation Partnership Project（of ETSI））
ＥＴＳＩ 欧州電気通信標準化協会（European Telecommunications Standards Institute）
ＧＳＭ グローバルシステムフォーモバイルコミュニケーション（Global System for Mobile Communication）
ＵＭＴＳ ユニバーサル移動電話システム（Universal Mobile Telephone System）
ＩＰ インターネットプロトコル（Internet Protocol）
ＢＴＳ 無線基地局装置（Base Transceiver Station）
ＢＳＣ 基地局制御装置（Base Station Controller）
ＨＬＲ ホームロケーションレジスタ（Home Location Register）
ＳＧＳＮ サービングＧＰＲＳサポートノード（Serving GPRS Support Node）
ＧＧＳＮ ゲートウェイＧＰＲＳサポートノード（Gateway GPRS Support Node）
ＵＴＲＡＮ ＵＭＴＳターミナル・地上無線接続網（UMTS Terrestrial Radio Access Network）
ＲＮＣ 無線ネットワーク制御装置（Radio Network Controller）
ＱｏＳ サービスの質（Quality of Service）
ＡＲＰ 割り当て／保持優先度（Allocation Retention Priority）
ＰＤＰ パケットデータプロトコル（Packet Data Protocol）
ＴＨＰ トラフィックハンドリング優先度（Traffic Handling Priority）
ＩＭＳＩ 国際移動加入者識別子（International Mobile Subscriber Identity）
ＲＡＢ 無線アクセスベアラ（Radio Access Bearer）
【図面の簡単な説明】
【００９２】
【図１】ＵＴＭＳネットワークのアーキテクチャを示す図である。
【図２】パケットシステムに対してＰＤＰコンテキストをアクティベーションするための手続きを示す図である。
【図３】ＵＴＲＡＮにおけるリソースの様々な使用レベルを示す概略図である。
【発明の詳細な説明】
【０００１】
本発明は、広く通信分野に関するものであり、特に、パケットモードおよび回線モードにおいて、ＵＭＴＳモバイル通信ネットワークにおけるアクセスネットワークのレベルで無線リソースを管理する方法に関するものである。
【０００２】
つまり、本発明に係る方法は、３ＧＰＰ標準規格の枠組みで標準化されたＵＭＴＳ技術を用いたモバイルネットワーク向けのアプリケーションを対象とする。記載が過多にならないようにするため、使用する全ての頭文字語の定義から成る用語解説を、読み手が有効に参照できるよう、本願明細書の末尾に提供している。
【０００３】
ＵＭＴＳ標準規格は新しいモバイルアクセスネットワークであるＵＴＲＡＮを明確化するものであり、ＵＴＲＡＮによって、携帯電話事業者の加入者に対してＩＰに基づくサービス（電子メッセージ、ファイルのダウンロード、ｗｅｂまたはＷＡＰサイトのコンサルテーション（consultation））または回線サービス（電話、テレビ電話）を提供することが可能となる。現時点では、ＵＭＴＳは導入段階であり、英語で「releases（リリース）」と呼ばれる様々なバージョンが存在する。特にリリース９９と呼ばれるバージョンについては、詳細に後述する。
【０００４】
アーキテクチャに関して言及すれば、ＵＭＴＳネットワークは、図１に示すように、コアネットワークＣＮと、ＵＴＲＡＮと称される無線アクセスネットワークとの、２つのサブネットワークに分割できる。
【０００５】
アクセスネットワークは、ＲＮＣ制御装置によって割り当てられる無線リソースを用いることにより無線インタフェースを通して利用者端末ＵＥに通信を提供する無線基地局ＮｏｄｅＢを多数備える。ある構成要素がいくつかの下位層の構成要素を制御するような階層的構造は、ＧＳＭ無線アクセスネットワークと同じである。ＲＮＣ無線ネットワーク制御装置は、ＧＳＭの基地局コントローラ（ＢＳＣ）の位置を保持している。しかし、情報転送に用いている無線技術は異なるものである。
【０００６】
ＵＭＴＳのコアネットワークＣＮは、電話に関する全てのサービスを含む回線システムＣＳと、パケット交換に関する全てのサービスを含むパケットシステムＰＳとの２つの別々のシステムを含んでいる。
【０００７】
コアネットワーク層には、上記両システムに共通なデータベースであるＨＬＲがある。ＨＬＲは、ネットワーク事業者の各加入者に関する情報（加入情報のみならず加入者の電話番号およびモバイルの識別子も含む）を格納している。ＨＬＲは、また、他の事項に加えて、加入者とサービスとに関する、サービスの質の情報を含んでいる。このサービスの質の情報に関しては、後に詳細に定義する。すなわち、上記データベースにより、ネットワーク内のモバイル加入者は管理される。
【０００８】
また、コアネットワークは、ＭＳＣ回線スイッチとＳＧＳＮパケットスイッチとを備える。コアネットワークのこれらサービスノードは、アクセスネットワーク内の通信リンクを管理する。これらのサービスノードは、ＨＬＲから送られて来る加入者プロファイルを格納しており、加入者により要求されたネットワークリソースを監視する。
【０００９】
パケットシステム層では、ＳＧＳＮは、他のサービスノードＧＧＳＮと接続されている。このＧＧＳＮは、パケット交換ネットワークの外側（例えば、インターネットなど）へのゲートウェイとして特に動作するものである。パケットシステムに関して言えば、ＵＭＴＳのコアネットワークは、ゲートウェイであるＧＧＳＮサービスノードを介して外部と接続されている。このゲートウェイは、セキュリティを保証すると同時に、モバイル電話が外部ネットワーク、特に、インターネットとの通信を可能とするためのルーティング情報を含むものである。モバイル電話に情報を送信できるようにするため、ＧＧＳＮは他のサービスノードであるＳＧＳＮを使用する。ＳＧＳＮは、コアネットワーク層のモビリティー（mobilite）、認証、および、暗号化を管理するものである。これらのネットワーク構成要素はＩＰルータの機能を統合し、ＩＰ系ネットワークを構成する。
【００１０】
回線システム層では、パケットシステムでの説明と同様に、ＭＳＣが他のサービスノードＧＭＳＣと関連している。ＧＭＳＣは、ＲＮＣタイプやＲＮＩＳタイプなどの定常（fixe）ネットワークへのゲートウェイとしての役目を果たすものである。
【００１１】
リリース９９では、全てのＵＭＴＳサービスは、次に示す４つの標準化されたトラフィッククラスによってサポートされている。すなわち、“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”（会話）、“Ｓｔｒｅａｍｉｎｇ”（ストリーミング）、“Ｉｎｔｅｒａｃｔｉｖｅ”（インタラクティブ）、“Ｂａｃｋｇｒｏｕｎｄ”（バックグラウンド）である。
【００１２】
“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”および“Ｓｔｒｅａｍｉｎｇ”クラスは、音声あるいは映像などのリアルタイムストリームを主に転送するために備えられるものである。しかしながら、利用者がリアルタイム映像（または音声）を観る（または聴く）場合に使用されるタイプに相当する“Ｓｔｒｅａｍｉｎｇ”クラスは、データ転送の時間的制約が“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”クラスよりも少ない。
【００１３】
“Ｉｎｔｅｒａｃｔｉｖｅ”および“Ｂａｃｋｇｒｏｕｎｄ”クラスは、非リアルタイムサービスに対応し、ナビゲーション、電子メール、ＦＴＰアプリケーションなどの従来のインターネットアプリケーションの枠組み内で使用されるために提供されるものである。非リアルタイムであることから、これらのクラスは再転送およびエンコード方式によってより低いエラー率を提供している。
【００１４】
本発明は、リソース、特に、アクセスネットワーク内における無線リソースの分配の管理に関する。このような管理には、サービス要求に関連付けられた、サービスの質（ＱｏＳ）のパラメータを考慮することが必要とされる。
【００１５】
ＵＭＴＳベアラサービスのＱｏＳパラメータは、ベアラサービスの利用者に対してＵＭＴＳネットワークにより提供されるサービスを記述する。ＱｏＳパラメータ一式から成るＱｏＳプロファイルが、このサービスを記述する。すなわちこれらは、特にスループット、トラフィックのタイプ、優先度などのネットワーク上のデータストリームの主な特性を規定することができる標準化されたパラメータである。このデータはＨＬＲ内の加入者プロファイルに格納されており、様々な手段によってＳＧＳＮおよびＭＳＣに転送される。
【００１６】
パケットシステムの加入者のＱｏＳプロファイルは、実際には、加入者によって要求される特定の値に関する許容上限に相当する。また、ＱｏＳプロファイルは事業者によって設定される初期プロファイルにも相当しうる。
【００１７】
ＱｏＳプロファイルに記述される主なＱｏＳパラメータは以下のとおりである。
【００１８】
・“Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”（ＡＲＰ）：このＱｏＳにより、ＵＭＴＳベアラサービスの割り当ておよび保持に関して、いくつかの加入者間のトラフィックを優先付けることができる。このタイプのパラメータは、パケットシステムと回線システムとのそれぞれについて個別に記述される。
【００１９】
・“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”（トラフィッククラス）：このＱｏＳパラメータは、サービスタイプに関連付けられた優先度を表すものである。リリース９９にみられるように、全てのサービスは４つのトラフィッククラスによりサポートされている。そこで、このＱｏＳパラメータは、“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”（リアルタイムな要求は非常に重要であるため、高優先レベルに相当）、“Ｓｔｒｅａｍｉｎｇ”、“Ｉｎｔｅｒａｃｔｉｖｅ”、“Ｂａｃｋｇｒｏｕｎｄ”（低優先）の値をとることができる。
【００２０】
・“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”（ＴＨＰ）（トラフィックハンドリング優先度）：このＱｏＳパラメータにより、“Ｉｎｔｅｒａｃｔｉｖｅ”トラフィッククラス向けの優先レベルを記述することができる。このパラメータは３つの値をとることができ、それにより、互いに関連する“Ｉｎｔｅｒａｃｔｉｖｅ”タイプのプロファイルを優先付けすることができる。
【００２１】
上記のパラメータに加えて以下のパラメータについても記述するが、本発明の枠組みでは使用しないので、情報提供の目的として記載する。
【００２２】
・“Ｔｒａｎｓｆｅｒ Ｄｅｌａｙ”（転送遅延）：このＱｏＳパラメータは、パケットの最大転送遅延を提供する。このＱｏＳパラメータはリアルタイムサービスでのみ使用される。
【００２３】
・“Ｇｕａｒａｎｔｅｅｄ ｂｉｔ ｒａｔｅ”（保証されたビットレート）：このＱｏＳパラメータはパケット転送の保証されたスループットを表す。このＱｏＳパラメータはリアルタイムサービスでのみ使用される。
【００２４】
・“Ｍａｘｉｍｕｍ ｂｉｔ ｒａｔｅ”（最大ビットレート）：このＱｏＳパラメータは最大スループットを表す。
【００２５】
上記すべてのＱｏＳパラメータは３ＧＰＰテレコミュニケーション標準規格の枠組み内で規定されているものである。しかし、これらの使用方法は標準化されていない。
【００２６】
ＵＭＴＳリリース９９において、ＨＬＲのレベルで、標準規格は、パケットおよび回線サービス向けに加入者データの中に優先レベルを持たせる可能性を見越している。“Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”（ＡＲＰ）が上記目的に使用されている。このパラメータは、パケットシステムでは登録されたＰＤＰコンテキスト毎に、または、回線システムでは加入者毎に、コアネットワークのＨＬＲレベルで通知される。
【００２７】
ＡＲＰパラメータによって、加入者間での無線リソースの割り当て／保持の優先度を決めることができる。ＡＲＰパラメータは、ＭＳＣ、ＳＧＳＮ、ＧＧＳＮで使用されており、コアネットワークでは次の３つの値をとることができる。すなわち、優先度１、優先度２、そして優先度３である。優先度３が最も低い値である。
【００２８】
ＡＲＰパラメータは、加入者からのサービス要求に対応する通信に優先レベルを関連付けるため、４つのサブパラメータの形式でＵＴＲＡＮのＲＮＣに送信される。そして、このパラメータは、ＵＴＲＡＮのＲＮＣに送信するためにコアネットワーク層で次の４つのサブパラメータに変換される。すなわち、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”（優先レベル）、“Ｐｒｅ-ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ”（プリエンプション能力）、“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”（プリエンプションの受けやすさ）、“Ｑｕｅｕｉｎｇ Ａｌｌｏｗｅｄ”（許容されるキューイング）である。これらの値は、コアネットワークのＡＲＰパラメータから得られる。これら４つのサブパラメータは３ＧＰＰ標準規格のＴＳ２５．４１３においてより詳細に定義されている。
【００２９】
ＵＴＲＡＮは、コアネットワークＣＮから送信される優先パラメータを使用して、システムの様々な利用者間で全てのリソース（例えば、無線リソース、転送リソース、処理容量）を割り当てる能力がなければならない。
【００３０】
ＰＤＰコンテキストのアクティベーション手続きを、図２を参照して記載する。モバイルＭＳ端末は、ＳＧＳＮおよびＧＧＳＮに格納されているＰＤＰコンテキストを要求することができ、また、加入者が望むサービスを実行するためのコアネットワークにおけるリソースを確保することができる。ＰＤＰコンテキストのアクティベーションの間、要求されたＰＤＰコンテキストおよび加入者の契約情報、特にＡＲＰパラメータで定義されるトラフィッククラスおよび加入者の優先度に関連付けられたサービスの質の情報をＵＴＭＳネットワークの様々なノードが受信する。
【００３１】
加入者の優先度に相当する情報、つまり、加入者が登録するＰＤＰコンテキストを定義するデータに含まれるＡＲＰパラメータは、加入者の場所が特定されたときにＳＧＳＮへ転送される。そして、この情報はＰＤＰコンテキストが加入者によってアクティベーションされたときにＧＧＳＮへ転送され、そして上述した４つのサブパラメータの形式でＲＮＣに転送される。
【００３２】
ＰＤＰコンテキストをアクティベーションする手続きは、加入者が、加入しているサービスを実行するためにネットワーク上にデータを送信または受信したいときに発生するものであり、モバイル加入者の最初の操作段階において実行されるものである。その結果、加入者によって要求された外部ネットワークとの相互接続要求を実行するＧＧＳＮサービスノードに端末を知らしめることができる。ＰＤＰコンテキストをアクティベーションする手続きの後、対応するサービスの質のプロファイルがネットワーク上の様々なノード間で交換され、そして、ＵＭＴＳネットワークと加入者が要求したサービスに対応する外部ネットワークとの間でデータ転送が開始される。
【００３３】
第１ステップでは、所望のＱｏＳを記述することにより、モバイルＭＳ端末が、親であるＳＧＳＮからのＰＤＰコンテキストのアクティベーションを要求する。ＳＧＳＮは、加入者データおよび他のパラメータに従って、要求されたＱｏＳを修正してもよい。
【００３４】
第２、第３ステップでは、ＳＧＳＮが、修正したＱｏＳパラメータとともに上記要求をＧＧＳＮに中継する。そして、これはネゴシエートされたＱｏＳに関する質問となる。そしてＧＧＳＮはＱｏＳを再修正し、それをＳＧＳＮに返送する。
【００３５】
第４、第５ステップでは、ＳＧＳＮは、無線アクセスベアラサービスに対する要求の形式でネゴシエートされたＱｏＳを記述することにより、要求された無線リソースをＲＮＳが割り当てることを要求する。無線アクセスベアラサービスは、特にコアネットワークのＡＲＰパラメータから得られるトラフィッククラスおよび４つのサブパラメータを含むＲＡＢパラメータの組で構成される。ＲＡＢパラメータは３ＧＰＰ標準規格ＴＳ２５．４１３のｖ４．０．０の９．２．１．３節に定義されている。
【００３６】
ＲＮＣは、上記要求を考慮するとともに、ＲＡＢパラメータを使って、サービス要求に対応するために必要な無線リソースを算出する。ＲＮＣは、要求されたリソースが使用可能であるかを検証し、使用可能でない場合は、すでに呼び出されているサービスのパラメータと新たな要求のパラメータとに基づいて、リソース不足を管理しなければならない。そしてＲＮＣは、要求された無線アクセスベアラサービスを許容または拒否する。
【００３７】
第６ステップでは、ＳＧＳＮが、ネットワーク上で得られたサービスの質を送信することによりモバイル電話からの要求を受けつける。
【００３８】
回線システムの層では、ビデオ電話タイプの発呼要求を例にあげる。第１ステップでは、モバイル電話がコアネットワークにサービス要求を送信する。要求されたＱｏＳの特性は、ベアラネットワークの容量（ベアラ伝送能力）に関連するフィールドに含まれている。スループット、望ましい接続形式については後述する。第２ステップでは、要求はＲＮＩＳタイプの定常（fixe）ネットワークに中継される。
【００３９】
最後に、コアネットワークが、ＲＡＢパラメータの形式でサービス要求を指定することにより、対応する無線リソース割り当て要求を送信する。ＲＮＣはこのサービス要求を持続するために必要なリソースの算出を実行する。ＲＮＣはこれらリソースが使用可能であるかを検証し、使用可能でなければ、すでに呼び出されているサービスのパラメータと新たな要求のパラメータとに基づいてリソース不足を管理しなければならない。そしてＲＮＣは要求されたＲＡＢを許容または拒否する。
【００４０】
考慮しなければならない重要な制約の一つとして、ＵＴＲＡＮはＣＮによって送信される優先度パラメータを使用するシステムの様々な利用者間で全てのリソース（無線リソース、転送リソース、処理能力）を分配することができなければならない。これを達成するために、標準規格に規定されているプリエンプション手続きを実行することができる。これにより、要求されたＱｏＳに返答するために使用可能なリソースがないときに、優先権を有しているとネットワーク事業者に見なされる利用者またはサービスがリソースを容易に獲得することができる。
【００４１】
ＣＮによって送信される優先度パラメータはＲＡＢパラメータの一部であり、以下のとおりである。すなわち、
− Ｔｒａｆｆｉｃ Ｃｌａｓｓ
− Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ
− Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ
である。
【００４２】
Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙは、次の４つのサブパラメータから構成される。すなわち、
− Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ
− Ｐｒｅ−ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ
− Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ
− Ｑｕｅｕｉｎｇ Ａｌｌｏｗｅｄ
である。
【００４３】
これらのパラメータにより、コアネットワークからのサービス要求に相当する各種無線アクセスベアラサービスのＲＡＢ間でリソースを割り当てるための優先レベルを規定することができる。さらに、新たなサービス要求の応答に必要なリソースが不十分である、または、使用可能でない場合には、標準規格に規定されているプリエンプション手続きがこの優先レベルに基づいて実行されてもよい。
【００４４】
実際には、プリエンプション手続きは、優先度の高い要求に対する応答に十分なリソースを当てられるように、利用者にすでに割り当てたリソースを減少させることが可能なアルゴリズムを使用している。
【００４５】
この点について、図３に、ＵＴＲＡＮリソースＣの様々な使用レベルを示す。これは、時間ｔの経過に応じたネットワークの様々な負荷のシナリオを示している。これら様々なシナリオにより、プリエンプション手続きを使用する場合を規定することができる。閾値Ｓは、過負荷であると考えられる領域を区切るものである。ここからわかることは、あるタイプのリソースに関しては、この閾値を超えることはない（物理的に全てのリソースが使用されており、そのような場合、追加可能なリソースが参照される）。逆に、他のタイプのリソース、非可算リソースに関しては、ある期間は閾値Ｓを超えてもよい。
【００４６】
領域１は、正常領域ともいうが、リソースの使用になんら制限がない。実際のところ、リソースを割り当てる新たな要求に応答するための十分なリソースがあり、プリエンプション手続きを使用する必要はない。換言すれば、ネットワーク上で現在使用されているリソースＣと、リソース割り当ての新たな要求を要求されたサービスの質で満たすのに必要なリソースＲとの合計は、過負荷領域を区切る閾値Ｓより小さい。よって、ここで検証することは、Ｃ＋Ｒ＜Ｓである。
【００４７】
領域２は、過負荷に近い領域であり、依然として使用可能なリソースは存在するが、これら使用可能なリソースだけでは新たなリソース割り当て要求に対する応答には不十分である。つまり、ネットワーク上のリソースＣの使用レベルが過負荷領域を区切る閾値Ｓより低いが、新たなリソース割り当て要求を満足するために必要なリソースＲが、要求されたサービスの質とともに、使用される全てのリソースの一部として見なされた場合、過負荷領域である領域３へ入るものが生じる。つまり、Ｃ＋Ｒ＞ＳかつＣ＜Ｓである。
【００４８】
このような状況においては、ネットワーク上でリソース割り当ての新たな要求に応答するためのいくつかの方策が前もって立てられる。
− 率直にかつ簡単に要求を拒否する。
− または、要求は受けつけるが、過負荷領域に入らないように、割り当てるリソースの量を要求された量よりも少なくする。
− もしくは、サービスの質に従って要求を受けつけ、要求に対して十分な応答をするために必要なリソースを補うために、プリエンプション手続きが引き起こされる。
【００４９】
過負荷領域３では、リソースの使用レベルは、過負荷領域を区切る閾値と等しいか、またはそれよりも大きい。この状況では、Ｃ＞＝Ｓという関係を検証する。
【００５０】
換言すると、この領域では、その瞬間に使用されているリソースのレベルに相当するネットワークの実際の負荷は、過負荷領域を区切る閾値よりも大きいかまたはそれと等しい。そして、ネットワークは過負荷または飽和状態である。この領域３においては、新たなＲＡＢの構築または、ネットワーク内にすでに受け入れられているＲＡＢのトラフィックにおける変化、あるいはＲＡＢのモビリティー（mobilite）に応答するためのＲＡＢの再構成要求といった、いかなる新たなリソース割り当て要求も、負荷レベルが過負荷閾値を下回るまで拒否される。
【００５１】
このように、ある状況下では、ＵＴＲＡＮリソースの一般的な使用レベルであっても、要求されたサービスの質を伴う新たなリソース割り当て要求に対する応答が問題になることが知られている。要求されたサービスの質に従った新たな要求に対する応答のために必要なリソースを正確に補う目的でプリエンプション手続きを引き起こすことは、優先権を有すると事業者に見なされた利用者がリソースを容易に利用するために必要不可欠である。
【００５２】
上記の理由で、３ＧＰＰ標準規格に準ずるＵＴＲＡＮにおけるリソースを優先的に割り当てるための手続きに対する照会は、極端に簡潔なもので、それにより基本的に規則の簡単な設定が行われる。その規則に従って、優先度の昇順に、低い優先度を有するＲＡＢをプリエンプトすることができる機構をＵＴＲＡＮ単独で実現する。しかしながら、他のＲＡＢとの関係でＲＡＢに優先レベルを割り当てる基準については、標準規格に記述されていない。それゆえ、ＵＴＲＡＮレベルで無線リソースへのアクセスが優先順位付けされる方法は、プリエンプション手続きを使用する様々なケースと同様に、実現されていない。それは、ＵＭＴＳ事業者にとって非常に重要な概念を含んでいる。なぜならば、それらは、例えば、加入者の様々なクラスに対してアクセスネットワークの無線リソースを共有および割り当てるための戦略を定義する主要な役割を果たすからである。
【００５３】
従って、本発明の目的は、無線アクセスネットワークレベルでサービスと加入者間の無線リソースを優先付けることによって、ＵＭＴＳアクセスネットワークのリソースを共有および割り当てる戦略を最適化できるようにするため、ＣＮから送られてくるサービス要求に相当する様々なＲＡＢの間で、ＵＴＲＡＮ内で優先度の異なる多数のレベルを規定することである。
【００５４】
本発明のもう一つの目的は、確立された優先順序を使って、ＵＭＴＳアクセスネットワークレベルで無線リソースを優先的に占有するための手続きを使用する様々なケースを規定することである。
【００５５】
それゆえ、本発明は、ＵＭＴＳタイプのモバイル通信ネットワークにおける無線リソースを管理する方法に関するものである。上記無線リソースは、利用者端末によってＵＭＴＳネットワークのコアネットワークへ送信される多数のサービス要求をサポートするために、ＵＴＭＳネットワークの無線アクセスネットワークの無線アクセス制御装置によって割り当てられるものである。上記サービスのそれぞれは、コアネットワークの構成要素の内部に記録されているサービスの質のパラメータの組によって指定されるものである。上記サービス要求のそれぞれは、対応する無線リソース割り当て要求をコアネットワークが上記無線ネットワーク制御装置に送信することにより処理され、上記無線リソース割り当て要求は、無線アクセスに対するベアラサービス要求を含み、当該ベアラサービス要求は、コアネットワークにおける対応するサービスの質のパラメータをマッピングすることによりその値が規定されるＲＡＢパラメータの集合の形式で、要求されたサービスの質を記述するものである。上記無線ネットワーク制御装置は、様々なサービス要求に対応する様々な無線アクセスベアラサービスの間でアクセスネットワークの無線リソースを分配するため、および、上記各ベアラサービスに関連付けられた優先レベルに従って上記ベアラサービスに対するリソース割り当てを調整する目的で上記リソースを優先的に割り当てるプリエンプション手続を行うために備えられるものであって、それにより、上記ベアラサービスの優先レベルに基づいて、上記ベアラサービスに対して要求されたサービスの質を満たすものである。上記優先レベルは、ＲＡＢパラメータである「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」のサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」によって各ベアラサービスに対して規定され、上記優先レベルの値は、一方では、コアネットワークのサービスの質のパラメータである上記「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」の値を考慮することにより決定され、他方では、サービスタイプに関連付けられた、サービスの質のパラメータの少なくとも１つの値を考慮することにより決定される。
【００５６】
本発明のある実施形態によれば、サービスの質のパラメータは、対応するベアラサービスに対して優先レベルを規定する“ｐｒｉｏｒｉｔｙ ｌｅｖｅｌ”サブパラメータに割り当てられる値を決めるために使用されるサービスタイプに関連し、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータを含むものである。
【００５７】
他の実施形態によれば、サービスの質のパラメータは、対応するベアラサービスに対して優先レベルを規定する“ｐｒｉｏｒｉｔｙ ｌｅｖｅｌ”サブパラメータに割り当てられる値を決めるために使用されるサービスタイプに関連し、互いに関連するｉｎｔｅｒａｃｔｉｖｅタイプのサービスを優先付けすることができる“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”パラメータをさらに含むものである。
【００５８】
ある特徴によれば、アクセスネットワークレベルでリソースを優先的に占有するための手続きは、無線アクセスに対する新たなベアラサービス要求を無線ネットワーク制御装置が少なくとも一つ受信する場合、使用可能な無線リソースがないか、または、新たな要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、実行されるものである。
【００５９】
別の特徴によれば、アクセスネットワークレベルでリソースを優先的に占有するための手続きは、上記ネットワークで既にアクティブな少なくとも一つのベアラサービスによってもたらされる上記ネットワーク上のトラフィックにおける変化に応答するための追加リソース要求を無線ネットワーク制御装置が少なくとも一つ受信する場合、使用可能な無線リソースがないか、または、新たな要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、実行されるものである。
【００６０】
好ましくは、ネットワーク内で既にアクティブである少なくとも２以上のベアラサービスがそれぞれ追加リソースの要求をしており、上記要求を満たすために必要なリソースは使用可能である場合、上記各ベアラサービスに関連付けられた優先レベルに基づいて、どの上記ベアラサービスに追加リソースが優先的に割り当てられるかを決定するために、リソースを割り当てるための優先順位付けステップが実行される。
【００６１】
好ましくは、ネットワーク内で既にアクティブである少なくとも２以上のベアラサービスが、最適な方法で割り当てられているリソースを使用しない場合、上記ベアラサービスに割り当てられているリソースを、上記各ベアラサービスに関連付けられた優先レベルによって定まる順に減少させるために、優先順位付けステップが上記ベアラサービス間で実行されることである。
【００６２】
例示であって限定されない目的で与えられる、後述する望ましい典型的な一実施形態における記載を読めば、本発明をより理解でき、他の詳細および利点がわかるであろう。後述の記載は以下の添付図面を参照する。
【００６３】
図１は、ＵＴＭＳネットワークのアーキテクチャを示しており、既に説明したとおりである。
【００６４】
図２は、パケットシステムに対してＰＤＰコンテキストをアクティベーションするための手続きを示しており、既に説明したとおりである。
【００６５】
図３は、ＵＴＲＡＮにおけるリソースの様々な使用レベルを示す概略図であり、既に説明したとおりである。
【００６６】
従って、すでに説明したように、ＵＴＲＡＮはシステムの様々な利用者間で全てのリソースを分配することができなければならない。これを達成するために、ネットワーク事業者に優先権があると見なされる無線アクセスベアラサービスあるいはＲＡＢに対するリソースを容易に利用する目的で、ＵＴＲＡＮ無線ネットワーク制御装置のレベルでプリエンプション手続きを実行する必要がある。
【００６７】
上記を達成するために、本発明では、ＵＴＲＡＮ内のＲＡＢに対するリソースに優先付きでアクセスするのに用いられる、様々なＲＡＢ間で多数の優先レベルを規定し、リソース割り当てにおいてリソースが不十分である、または使用できない時に、他のＲＡＢよりも優先されるＲＡＢを選択可能とすることを提案する。
【００６８】
これら様々な優先レベルの値は、リソース管理アルゴリズム、特に、リソースを優先的に占有する手続きを要求するアルゴリズムによって使用されるために備えられる。これにより、いくつかのＲＡＢが同じリソースを獲得するために競合したときに、無線アクセスネットワークのレベルで各ＲＡＢに割り当てられるリソースの割り当てを決めることができる。発明に係る優先レベルの値は、ＲＡＢからの要求を満たすために必要なリソースが使用できないかまたは、アクセスネットワークにおける負荷レベルを持ちこたえるという点で不十分であるときに、プリエンプション手続きによって使用される。それゆえ、要求したＲＡＢがアクセスネットワークレベルでリソースを優先的に占有するための権利を有しているかどうか、そしてこの場合、どのＲＡＢがプリエンプトされるリソースを有しているかを決定する目的で、プリエンプション手続きは、各ＲＡＢに関連付けられた、本発明に係るこれらの優先レベルの値を使用するために設けられる。
【００６９】
本発明に係る重要な特徴の一つに、アクセスネットワークレベルで無線リソースを割り当てるための様々なＲＡＢに関連付けられた様々な優先レベルは、コアネットワーク、特に、コアネットワークのＳＧＳＮおよび／またはＭＳＣサービスノードからＲＮＣに送信されるＲＡＢパラメータに基づいて事業者が構成できなければならない。様々なＲＡＢパラメータは、実際のところ、コアネットワークからアクセスネットワークへ送られてくるサービスの質のパラメータを用いてマッピングすることにより得られる。
【００７０】
従って、ＲＡＢパラメータには、以下のパラメータがある。すなわち、
− （１）“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”
− （２）“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”
− （３）“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”
である。
上記（１）および（２）のＲＡＢパラメータはそれぞれ、コアネットワークから送信され、サービスタイプに関連付けられた、対応するＱｏＳパラメータである“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”および“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”、および、加入者の優先レベルに関連付けられたＲＡＢパラメータを用いて直接マッピングすることにより得られる。
【００７１】
上記（３）は、コアネットワークのＱｏＳパラメータである“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”から導き出される以下の４つのサブパラメータから構成される。すなわち、
− “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”
− “Ｐｒｅ-ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ”
− “Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”
− “Ｑｕｅｕｉｎｇ Ａｌｌｏｗｅｄ”
である。
【００７２】
つまり本発明は、コアネットワークからアクセスネットワークに向けたサービスの質のパラメータの新たなマッピングを前もって実行し、その結果として、ＡＲＰパラメータに統合される４つのＲＡＢサブパラメータを決定する際に、コアネットワークのＡＲＰパラメータの値だけでなく、サービスタイプに関連付けられたＱｏＳパラメータの値をも考慮する。
【００７３】
より正確には、リソース割り当てを管理するための、発明に係る優先レベルは、ＲＡＢパラメータである“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”の“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータによってＲＡＢ毎に決定される。その値は、コアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータの値と、サービスタイプに関連付けられた少なくともひとつのＱｏＳパラメータの値とを考慮して決定される。サービスタイプに関連付けられたＱｏＳパラメータは、本発明に係る優先レベルを規定するための“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”サブパラメータに割り当てられる値を決めるために使用され、第１の実施形態においては、４つの値をとりうる“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータを含む。第２の実施形態においては、使用されるＱｏＳパラメータは、サービスタイプに関連付けられ、３つの値をとりうる“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”パラメータをさらに含む。これにより、Ｉｎｔｅｒａｃｔｉｖｅタイプ（つまり、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータが値“Ｉｎｔｅｒａｃｔｉｖｅ”をとる）のサービスを優先付けまたは優先レベルにより順位付けすることができる。
【００７４】
このように、ＱｏＳパラメータ“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”およびコアネットワークのＱｏＳパラメータ“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”を使用することにより、様々なＲＡＢ間で“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータに対して最大で１２の値、つまり、１２段階の優先レベルを規定することができる。
【００７５】
さらに、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータと、コアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータと、“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”パラメータを使用することにより、様々なＲＡＢ間で“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータに対して最大で１８の値、つまり、１８段階の優先レベルを規定することができる。
【００７６】
各ＲＡＢに関連付けられたサービス／加入者の組合せに対する優先レベルの、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータを使用した第１の規定例を表１に示す。これは、アクセスネットワーク内のリソースの割り当て／保持を管理するために使用される。
【００７７】
【表１】
【００７８】
“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ”に割り当てられる値Ｙは、関連付けられたＲＡＢが他のＲＡＢのリソースを優先的に占有することができることを示しており、値Ｎはその逆である。同様に“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”に割り当てられる値Ｙは、関連するＲＡＢがリソースを他のＲＡＢによってプリエンプトされるかもしれないことを示しており、値Ｎはその逆である。
【００７９】
上述の例から、次に示すように、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータを使用したリソースの割り当て／保持のための様々なＲＡＢ間での優先順位の規定が得られる。“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータは、一方ではコアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータの値をＲＡＢ毎に考慮して決定され、他方では“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”パラメータの値を考慮して決定される。
【００８０】
すなわち、
“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝１であるＲＡＢ ＞ “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝２であるＲＡＢ ＞ ・・・ ＞ “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝１１であるＲＡＢ ＞ “Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”＝１２であるＲＡＢ、
というように決定される。 よって、本発明に係る優先レベルが５であるＲＡＢは、本発明に係る優先レベルが６〜１２であるＲＡＢに割り当てられているリソースを優先的に占有できる。
【００８１】
各ＲＡＢに関連付けられたサービス／加入者の組合せに対する優先レベルの、“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータを使用した第２の規定例を表２に示す。これは、アクセスネットワーク内のリソースの割り当て／保持を管理するために使用される。各ＲＡＢに対する“Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ”パラメータの値は、今回は、コアネットワークの“Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ”パラメータの値と、“Ｔｒａｆｆｉｃ Ｃｌａｓｓ”ＱｏＳパラメータの値とに加えて、“Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ”サービスタイプに関連付けられたＱｏＳパラメータの値を考慮して決められる。この例は、このタイプのサービス（“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”および“Ｓｔｒｅａｍｉｎｇ”）に対して、“Ｐｒｅ−ｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ”サブパラメータに割り当てられている値Ｎに示すように、リアルタイムサービスが自身のリソースをプリエンプトされないネットワーク構成に関する。
【００８２】
【表２】
【００８３】
ここでされた優先レベルは、いくつかのＲＡＢが同じリソースを獲得するために競合したときにリソースへのアクセスを優先順位づけするために、リソース管理アルゴリズムによって使用される。さらに、上記優先レベルは、割り当てるのに必要なリソースが不十分である、または、使用できない場合、どのＲＡＢのリソースをどのＲＡＢが優先的に占有するかを決めるために、プリエンプション手続を実行するアルゴリズムによって使用される。
【００８４】
特に、プリエンプション手続は、アクセス制御ステップ、つまり、ＲＮＣが新たなＲＡＢ要求を受信したときに、使用される。新たなＲＡＢ要求は、アクセスネットワークでの新たなＲＡＢの確立により生じるか、または、アクセスネットワーク内にすでに入っているＲＡＢに対するモビリティー（mobilite）手続により生じる。
【００８５】
この場合、図３に示すように、システムの負荷レベルが領域２または３、つまり、使用可能なリソースが存在するが新たな要求に対して応答するのに不十分であるときか、または、使用できるリソースがないときに、新たなＲＡＢの優先レベルとシステム内でアクティブなＲＡＢの優先レベルとによって必要とされるリソースを補うために、リソース管理アルゴリズムによってプリエンプション手続が利用される。
【００８６】
さらにプリエンプション手続は、要求を満たすネットワーク内のリソースが使用可能ではないか、または、不十分であるときに、追加のリソースを要求した結果として、ネットワーク内ですでにアクティブなＲＡＢのトラフィックの変化に応じたトラフィック制御の呼び出し中に使用されるために設けられる。これには個々の制御オペレーションが含まれる。プリエンプション手続によって、低優先レベルのＲＡＢに割り当てられているリソースが減少し、リソースの要求をした高優先レベルのＲＡＢにリソースが再割り当てされる。
【００８７】
ネットワークの負荷レベルが領域１であって、そのためリソースに制約が無い場合であっても、上記ネットワークはすでにアクティブなＲＡＢの様々なスループットに対応できなければならない。その結果として、利用者に割り当てられているリソースが必要に応じて動的に調整されることとなる。よって、２またはそれ以上の利用者が同時に追加リソースの要求をした場合は、リソース管理アルゴリズムが各ＲＡＢに関連付けられた優先レベルに基づいてリソース割り当てを優先順位付けするため、高優先レベルのＲＡＢが優先的に使用される。
【００８８】
逆に、ネットワーク上にリソースの制約が無く、２またはそれ以上の利用者が最適に割り当てられたリソースを使用しない場合、関連する各ＲＡＢに関連付けられた優先レベルがトラフィック制御の枠組み内で使用され、割り付けられたリソースが減少する。この場合、まず低優先レベルのＲＡＢがリソースを減らされ、次により高い優先度のＲＡＢがリソースを減らされ、最後に関連するＲＡＢの中で最も高優先レベルのＲＡＢがリソースを減らされる。
【００８９】
領域２および３において、領域１と同様に、いくつかの利用者がリソースを最適に使用していない場合、関係する各ＲＡＢに関連付けられた優先レベルはトラフィック制御の枠組みで使用され、割り当てられたリソースは減少する。この場合、割り当てられたリソースを減少させる順番は本発明によって規定される各ＲＡＢの優先レベルによって規定される。
【００９０】
最後に、プリエンプション手続はまた、グローバルなトラフィック制御の枠組み内で、システムの負荷の変化に応じた呼び出し中に実行されうる。特に、ネットワークの負荷レベルが領域３のとき、リソースの使用レベルをより安定した値に戻す必要がある。この場合、トラフィック制御の枠組みで実行されるプリエンプション手続はシステム内の負荷レベルを減少させることを目指す。これを達成するために、プリエンプション手続は、各ＲＡＢに関連付けられた優先レベルを使用することによって、割り当てられたリソースを減少させることができる、アクティブなＲＡＢ間の順序を確立する。最も低い優先レベルのＲＡＢは最初にリソースを減らされ、次により高い優先レベルのものがリソースを減らされ、そして、もしネットワークの負荷が許容レベルに戻らなければ、最後に最も高い優先レベルのものがリソースを減らされる。
【００９１】
〔用語解説〕
この用語解説では、本特許出願書類で使用される英文字の頭文字語を一覧で示す。
これらの頭文字語は３ＧＰＰテレコミュニケーション標準規格の枠組み内で定義されている。
３ＧＰＰ 第３世代移動体通信システム標準化プロジェクト（Third-Generation Partnership Project（of ETSI））
ＥＴＳＩ 欧州電気通信標準化協会（European Telecommunications Standards Institute）
ＧＳＭ グローバルシステムフォーモバイルコミュニケーション（Global System for Mobile Communication）
ＵＭＴＳ ユニバーサル移動電話システム（Universal Mobile Telephone System）
ＩＰ インターネットプロトコル（Internet Protocol）
ＢＴＳ 無線基地局装置（Base Transceiver Station）
ＢＳＣ 基地局制御装置（Base Station Controller）
ＨＬＲ ホームロケーションレジスタ（Home Location Register）
ＳＧＳＮ サービングＧＰＲＳサポートノード（Serving GPRS Support Node）
ＧＧＳＮ ゲートウェイＧＰＲＳサポートノード（Gateway GPRS Support Node）
ＵＴＲＡＮ ＵＭＴＳターミナル・地上無線接続網（UMTS Terrestrial Radio Access Network）
ＲＮＣ 無線ネットワーク制御装置（Radio Network Controller）
ＱｏＳ サービスの質（Quality of Service）
ＡＲＰ 割り当て／保持優先度（Allocation Retention Priority）
ＰＤＰ パケットデータプロトコル（Packet Data Protocol）
ＴＨＰ トラフィックハンドリング優先度（Traffic Handling Priority）
ＩＭＳＩ 国際移動加入者識別子（International Mobile Subscriber Identity）
ＲＡＢ 無線アクセスベアラ（Radio Access Bearer）
【図面の簡単な説明】
【００９２】
【図１】ＵＴＭＳネットワークのアーキテクチャを示す図である。
【図２】パケットシステムに対してＰＤＰコンテキストをアクティベーションするための手続きを示す図である。
【図３】ＵＴＲＡＮにおけるリソースの様々な使用レベルを示す概略図である。
【特許請求の範囲】
【請求項１】
ＵＴＭＳタイプのモバイル通信ネットワークにおける無線リソースを管理する無線リソース管理方法であって、
上記無線リソースは、利用者端末（ＵＥ）によってＵＭＴＳネットワークのコアネットワーク（ＣＮ）へ送信される多数のサービス要求をサポートするために、ＵＴＭＳネットワークの無線アクセスネットワーク（ＵＴＲＡＮ）の無線アクセス制御装置（ＲＮＣ）によって割り当てられるものであり、
上記サービスのそれぞれは、コアネットワークの構成要素（ＨＬＲ）の内部に記録されているサービスの質のパラメータの組によって指定されるものであり、
上記サービス要求のそれぞれは、対応する無線リソース割り当て要求をコアネットワークが上記無線ネットワーク制御装置（ＲＮＣ）に送信することにより処理され、
上記無線リソース割り当て要求は、無線アクセスに対するベアラサービス要求を含み、当該ベアラサービス要求は、コアネットワークにおける対応するサービスの質のパラメータをマッピングすることによりその値が規定されるＲＡＢパラメータの集合の形式で、要求されたサービスの質を記述するものであり、
上記無線ネットワーク制御装置（ＲＮＣ）は、様々なサービス要求に対応する様々な無線アクセスベアラサービスの間でアクセスネットワーク（ＵＴＲＡＮ）の無線リソースを分配するため、および、上記各ベアラサービスに関連付けられた優先レベルに従って上記ベアラサービスに対するリソース割り当てを調整する目的で上記リソースを優先的に割り当てるプリエンプション手続を行うために備えられるものであって、それにより、上記ベアラサービスの優先レベルに基づいて、上記ベアラサービスに対して要求されたサービスの質を満たすものであり、
上記優先レベルは、ＲＡＢパラメータである「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」のサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」によって各ベアラサービスに対して規定され、
上記優先レベルの値は、一方では、コアネットワークのサービスの質のパラメータである上記「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」の値を考慮することにより決定され、他方では、サービスタイプに関連付けられた、サービスの質のパラメータの少なくとも１つの値を考慮することにより決定されることを特徴とする方法。
【請求項２】
対応するベアラサービスに対して優先レベルを規定するサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」に割り当てられる値を決定するために使用され、サービスタイプに関連付けられた、サービスの質のパラメータは、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータを含むことを特徴とする請求項１に記載の方法。
【請求項３】
対応するベアラサービスに対して優先レベルを規定するサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」に割り当てられる値を決定するために使用される、サービスタイプに関連付けられたサービスの質のパラメータは、互いに関連するＩｎｔｅｒａｃｔｉｖｅタイプのサービスを優先順位付けすることができる「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
無線アクセスに対する新たなベアラサービス要求の少なくとも１つを無線ネットワーク制御装置（ＲＮＣ）が受信したときに、使用可能な無線リソースが無い場合、または、無線アクセスに対する新たなベアラサービス要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、アクセスネットワークレベル（ＵＴＲＡＮ）でリソースを優先的に割り当てるプリエンプション手続きが実行されることを特徴とする請求項１〜３のいずれか１項に記載の方法。
【請求項５】
上記ネットワーク内ですでにアクティブなベアラサービスの少なくとも１つによって引き起こされる、アクセスネットワーク上のトラフィックの変化に応答するために、リソースを追加する要求の少なくとも１つを無線ネットワーク制御装置（ＲＮＣ）が受信したときに、使用可能な無線リソースが無い場合、または、無線アクセスに対する新たなベアラサービス要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、アクセスネットワークレベル（ＵＴＲＡＮ）でリソースを優先的に割り当てるプリエンプション手続きが実行されることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項６】
上記ネットワーク内ですでにアクティブなベアラサービスのうちの少なくとも２つがそれぞれリソースを追加する要求を行っており、かつ、上記要求を満たすために必要なリソースが使用可能である場合に、リソースを割り当てるための優先順位付けステップを実行することにより、上記各ベアラサービスに関連付けられた優先レベルに基づいて、いずれのベアラサービスに優先的に追加リソースを割り当てるかを決定することを特徴とする請求項１〜５のいずれか１項に記載の方法。
【請求項７】
上記ネットワーク内ですでにアクティブなベアラサービスのうちの少なくとも２つが最適な様式で割り当てられたリソースを活用していない場合に、上記ベアラサービス間において優先順位付けステップを実行することにより、上記各ベアラサービスに関連付けられた優先レベルにより規定される順序で、上記ベアラサービスに割り当てられているリソースを減少させることを特徴とする請求項１〜６のいずれか１項に記載の方法。
【請求項１】
ＵＴＭＳタイプのモバイル通信ネットワークにおける無線リソースを管理する無線リソース管理方法であって、
上記無線リソースは、利用者端末（ＵＥ）によってＵＭＴＳネットワークのコアネットワーク（ＣＮ）へ送信される多数のサービス要求をサポートするために、ＵＴＭＳネットワークの無線アクセスネットワーク（ＵＴＲＡＮ）の無線アクセス制御装置（ＲＮＣ）によって割り当てられるものであり、
上記サービスのそれぞれは、コアネットワークの構成要素（ＨＬＲ）の内部に記録されているサービスの質のパラメータの組によって指定されるものであり、
上記サービス要求のそれぞれは、対応する無線リソース割り当て要求をコアネットワークが上記無線ネットワーク制御装置（ＲＮＣ）に送信することにより処理され、
上記無線リソース割り当て要求は、無線アクセスに対するベアラサービス要求を含み、当該ベアラサービス要求は、コアネットワークにおける対応するサービスの質のパラメータをマッピングすることによりその値が規定されるＲＡＢパラメータの集合の形式で、要求されたサービスの質を記述するものであり、
上記無線ネットワーク制御装置（ＲＮＣ）は、様々なサービス要求に対応する様々な無線アクセスベアラサービスの間でアクセスネットワーク（ＵＴＲＡＮ）の無線リソースを分配するため、および、上記各ベアラサービスに関連付けられた優先レベルに従って上記ベアラサービスに対するリソース割り当てを調整する目的で上記リソースを優先的に割り当てるプリエンプション手続を行うために備えられるものであって、それにより、上記ベアラサービスの優先レベルに基づいて、上記ベアラサービスに対して要求されたサービスの質を満たすものであり、
上記優先レベルは、ＲＡＢパラメータである「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」のサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」によって各ベアラサービスに対して規定され、
上記優先レベルの値は、一方では、コアネットワークのサービスの質のパラメータである上記「Ａｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」の値を考慮することにより決定され、他方では、サービスタイプに関連付けられた、サービスの質のパラメータの少なくとも１つの値を考慮することにより決定されることを特徴とする方法。
【請求項２】
対応するベアラサービスに対して優先レベルを規定するサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」に割り当てられる値を決定するために使用され、サービスタイプに関連付けられた、サービスの質のパラメータは、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータを含むことを特徴とする請求項１に記載の方法。
【請求項３】
対応するベアラサービスに対して優先レベルを規定するサブパラメータである「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」に割り当てられる値を決定するために使用される、サービスタイプに関連付けられたサービスの質のパラメータは、互いに関連するＩｎｔｅｒａｃｔｉｖｅタイプのサービスを優先順位付けすることができる「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
無線アクセスに対する新たなベアラサービス要求の少なくとも１つを無線ネットワーク制御装置（ＲＮＣ）が受信したときに、使用可能な無線リソースが無い場合、または、無線アクセスに対する新たなベアラサービス要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、アクセスネットワークレベル（ＵＴＲＡＮ）でリソースを優先的に割り当てるプリエンプション手続きが実行されることを特徴とする請求項１〜３のいずれか１項に記載の方法。
【請求項５】
上記ネットワーク内ですでにアクティブなベアラサービスの少なくとも１つによって引き起こされる、アクセスネットワーク上のトラフィックの変化に応答するために、リソースを追加する要求の少なくとも１つを無線ネットワーク制御装置（ＲＮＣ）が受信したときに、使用可能な無線リソースが無い場合、または、無線アクセスに対する新たなベアラサービス要求に関連付けられたサービスの質を満たすために必要な無線リソースが不十分である場合に、アクセスネットワークレベル（ＵＴＲＡＮ）でリソースを優先的に割り当てるプリエンプション手続きが実行されることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項６】
上記ネットワーク内ですでにアクティブなベアラサービスのうちの少なくとも２つがそれぞれリソースを追加する要求を行っており、かつ、上記要求を満たすために必要なリソースが使用可能である場合に、リソースを割り当てるための優先順位付けステップを実行することにより、上記各ベアラサービスに関連付けられた優先レベルに基づいて、いずれのベアラサービスに優先的に追加リソースを割り当てるかを決定することを特徴とする請求項１〜５のいずれか１項に記載の方法。
【請求項７】
上記ネットワーク内ですでにアクティブなベアラサービスのうちの少なくとも２つが最適な様式で割り当てられたリソースを活用していない場合に、上記ベアラサービス間において優先順位付けステップを実行することにより、上記各ベアラサービスに関連付けられた優先レベルにより規定される順序で、上記ベアラサービスに割り当てられているリソースを減少させることを特徴とする請求項１〜６のいずれか１項に記載の方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００７−５２０１３１（Ｐ２００７−５２０１３１Ａ）
【公表日】平成１９年７月１９日（２００７．７．１９）
【国際特許分類】
【出願番号】特願２００６−５５０２３５（Ｐ２００６−５５０２３５）
【出願日】平成１７年１月２０日（２００５．１．２０）
【国際出願番号】ＰＣＴ／ＦＲ２００５／０００１３０
【国際公開番号】ＷＯ２００５／０８４０６１
【国際公開日】平成１７年９月９日（２００５．９．９）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
【公表日】平成１９年７月１９日（２００７．７．１９）
【国際特許分類】
【出願日】平成１７年１月２０日（２００５．１．２０）
【国際出願番号】ＰＣＴ／ＦＲ２００５／０００１３０
【国際公開番号】ＷＯ２００５／０８４０６１
【国際公開日】平成１７年９月９日（２００５．９．９）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
[ Back to top ]