移動体通信網で無線リソースをプリエンプティブに管理する方法
本発明は、新しいチャネル要求を受け入れる時にリソースの欠如がある場合に、
ａ− プリエンプトできるチャネルを識別し（３０、３５）、それらの間で、関連する優先順位レベルを使用して最低優先順位のチャネルを選択し（４０）、
ｂ− これを少なくとも部分的に再構成することによって得られるリソースの増加を評価し（５０、５５）、前記チャネルおよび前記増加を記憶し、
ｃ− 記憶されたチャネルによって達成される増加が前記新しい要求をサポートするのに十分であるかどうかを検査し（７０）、
ｄ− ステップａからｃを、
− 得られる利益が十分になるまで繰り返し、この場合に、記憶された通信チャネルが再構成され、新しい要求が受け入れられ（８０）、または、
− プリエンプトできるすべてのチャネルが、十分な増加を得ることなく評価されるまで繰り返し、この場合に、新しい要求が拒否される（９０）
ことからなる、移動体通信網内で要求されたＱｏＳパラメータにそれぞれが関連する通信チャネルに割り振られる無線リソースの管理に関する。
ａ− プリエンプトできるチャネルを識別し（３０、３５）、それらの間で、関連する優先順位レベルを使用して最低優先順位のチャネルを選択し（４０）、
ｂ− これを少なくとも部分的に再構成することによって得られるリソースの増加を評価し（５０、５５）、前記チャネルおよび前記増加を記憶し、
ｃ− 記憶されたチャネルによって達成される増加が前記新しい要求をサポートするのに十分であるかどうかを検査し（７０）、
ｄ− ステップａからｃを、
− 得られる利益が十分になるまで繰り返し、この場合に、記憶された通信チャネルが再構成され、新しい要求が受け入れられ（８０）、または、
− プリエンプトできるすべてのチャネルが、十分な増加を得ることなく評価されるまで繰り返し、この場合に、新しい要求が拒否される（９０）
ことからなる、移動体通信網内で要求されたＱｏＳパラメータにそれぞれが関連する通信チャネルに割り振られる無線リソースの管理に関する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的には遠距離通信の領域に関し、より具体的には、パケット・モードの移動体通信網内のアクセス網において、無線リソースを管理する方法に関するものである。
【背景技術】
【０００２】
本発明による方法は、３ＧＰＰ標準規格に準拠するＧＰＲＳテクノロジまたはＵＭＴＳテクノロジを使用する携帯電話ネットワークに適用されるように設計される。説明を過度に複雑にしないようにするために、この説明の終りに、使用されるすべての頭字語の定義を含む用語集欄を設けるので参照されたい。
【０００３】
ＵＭＴＳ標準規格は、パケット・モードでの新しいデータ伝送サービスを指定し、モバイル・オペレータへの加入者に、ＩＰに基づくサービス（電子メッセージング、ファイルのダウンロード、ウェブ・サイトまたはＷＡＰサイトの閲覧）へのアクセスを含む様々な特徴を提供することができる。したがって、データ（ＩＰパッケージで伝送される）を、ＵＭＴＳ網の外部の網、通常はインターネット・ネットワークに属するサーバと、携帯電話機との間で交換することができる。現在、ＵＭＴＳは、リリースとも呼ばれる異なるバージョン、特にＲｅｌｅａｓｅ ９９で段階的に実行され、このＲｅｌｅａｓｅ ９９には、次の説明が具体的に適用可能である。
【０００４】
アーキテクチャに関して、ＵＭＴＳ網は、図１に示されているように、２つのサブネットワーク、すなわち、コア・ネットワークＣＮと、ＵＴＲＡＮとも呼ばれる無線アクセス網とに分割することができる。
【０００５】
アクセス網には、無線ネットワーク制御装置ＲＮＣノードによって割り振られた無線リソースを使用して無線インターフェースを介してユーザ機器ＵＥと通信するように設計された複数のＮｏｄｅ Ｂ無線基地局が含まれる。１つの実体が複数の下位実体を制御する階層アーキテクチャは、ＧＳＭ無線アクセス網と同一である。無線ネットワーク制御装置ＲＮＣは、ＧＳＭ基地局制御装置（ＢＳＣ）として働く。しかし、情報を転送するのに使用される無線テクノロジは異なる。
【０００６】
ＵＭＴＳコア・ネットワークＣＮには、２つの別個のドメイン、すなわち、テレフォニに関するすべてのサービスを含む回線ドメイン（ｃｉｒｃｕｉｔ ｄｏｍａｉｎ）ＣＳと、パケット交換に関するすべてのサービスを含むパケット・ドメイン（ｐａｃｋｅｔ ｄｏｍａｉｎ）ＰＳとが含まれる。
【０００７】
コア・ネットワークには、この２つのドメインに共通するデータベースであるＨＬＲが含まれ、このＨＬＲには、ネットワーク・オペレータの加入者のすべてに関する情報すなわち、加入者電話番号、携帯電話機の識別、および加入契約に関する情報が保管される。ＨＬＲには、本説明で後で定義される加入者およびサービスに関係するサービス品質情報も含まれる。したがって、このデータベースは、網内のモバイル加入者の管理に使用される。
【０００８】
コア・ネットワークは、ＭＳＣ回線交換機およびＳＧＳＮパケット交換機もホストする。コア・ネットワーク内のこれらのサポート・ノードは、アクセス網との通信リンクを制御するのに使用される。これらの交換機は、ＨＬＲから入手された加入者のプロファイルを保管し、加入者によって要求されたネットワーク・リソースを制御する。
【０００９】
パケット・ドメインでは、ＳＧＳＮは、もう１つのサポート・ノード、すなわちＧＧＳＮに関連し、このＧＧＳＮは、より具体的には、外部パケット交換網（インターネットなど）へのゲートウェイとして働く。したがって、パケット・ドメインについて、ＵＭＴＳコア・ネットワークは、ゲートウェイ、すなわち、サポート・ノードＧＧＳＮを介して外部と相互接続され、このＧＧＳＮには、セキュリティを維持しながら、携帯電話機が外部網、具体的にはインターネット・ネットワークと通信するのに使用するルーティング情報が含まれる。次に、ＧＧＳＮは、コア・ネットワーク内のモビリティ、認証、および暗号化を制御する他方のサポート・ノード、すなわちＳＧＳＮを使用して、携帯電話機に情報を送信する。これらの網要素は、ＩＰルータ機能を含み、ＩＰタイプ・ネットワークを形成する。
【００１０】
回線ドメインでは、パケット・ドメインを参照して説明したように、ＭＳＣが、固定ＲＮＣ、ＩＳＤＮタイプ・ネットワークなどへのゲートウェイとして働くもう１つのサポート・ノード、すなわち、ＧＭＳＣに関連する。
【００１１】
Ｒｅｌｅａｓｅ ９９では、すべてのＵＭＴＳサービスが、４つの標準トラフィック・クラス、すなわち、「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」、「Ｓｔｒｅａｍｉｎｇ」、「Ｉｎｔｅｒａｃｔｉｖｅ」、および「Ｂａｃｋｇｒｏｕｎｄ」によってサポートされる。
【００１２】
「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」クラスおよび「Ｓｔｒｅａｍｉｎｇ」クラスは、主に音声またはビデオなどのリアルタイム・フローを搬送するために設計された。しかし、ユーザがリアルタイムでビデオ・ストリームを見る（またはオーディオ・ストリームを聞いている）使用に対応する「Ｓｔｒｅａｍｉｎｇ」クラスについて、データ転送時間に対する制約は、「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」クラスほど厳しくはない。
【００１３】
「Ｉｎｔｅｒａｃｔｉｖｅ」クラスおよび「Ｂａｃｋｇｒｏｕｎｄ」クラスは、非リアルタイム・サービスに対応し、ナビゲーション・アプリケーション、電子メール・アプリケーション、ＦＴＰアプリケーションなどの伝統的なインターネット・アプリケーションの枠組での使用のために提供される。この後者のクラスは、非リアルタイムであり、再送信方法およびコーディング方法に起因して、エラー率においてよりよい性能を提供する。
【００１４】
これらのクラスの間の主な区別要因は、実際には、遅延に対する感度である。「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」トラフィック・クラスは、遅延に非常に敏感であるが、「Ｂａｃｋｇｒｏｕｎｄ」トラフィック・クラスは、全く敏感ではない。
【００１５】
アクセス網内のリソース、より具体的には無線リソースの配分は、サービス要求に関連するサービス品質（ＱｏＳ）パラメータを利用して制御される。
【００１６】
したがって、ＵＭＴＳ伝送サービスのＱｏＳパラメータは、ＵＭＴＳ網を介してＵＭＴＳ伝送サービスのユーザに与えられるサービスを記述する。ＱｏＳパラメータの組によって形成されるＱｏＳプロファイルが、このサービスを指定する。したがって、これらは、特にスループット、トラフィック・タイプ、優先順位などに関して、網上のデータ・ストリームの主要な特性を定義するのに使用される標準パラメータである。これらのデータは、ＨＬＲ内の加入者のプロファイルに保管され、種々の手順によって次の実体（ＳＧＳＮおよびＭＳＣ）に伝送される。
【００１７】
ＵＭＴＳ加入者のＱｏＳプロファイルは、実際には、その加入者が要求できる最高のＱｏＳに対応する。ＱｏＳプロファイルは、オペレータによって構成されるデフォルト・プロファイルとすることもできる。
【００１８】
ＱｏＳプロファイルで指定されるＱｏＳパラメータは、主に次の通りである。
− 「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」（ＡＲＰ）：このＱｏＳパラメータは、ＵＭＴＳ伝達サービスの割り振りおよびプリエンプションに関して、複数の加入者間のトラフィック優先順位を識別するのに使用される。このタイプのパラメータは、ドメインごとに、すなわち、パケット・ドメインおよび回線ドメインについて指定される。
− 「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」：このＱｏＳパラメータは、サービス・タイプに関連する優先順位を示す。上述したように、Ｒｅｌｅａｓｅ ９９では、すべてのサービスが、４つのトラフィック・クラスによってサポートされる。したがって、このＱｏＳパラメータは、「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」（リアルタイム要件が非常に重要なので、高優先順位に対応する）値、「Ｓｔｒｅａｍｉｎｇ」値、「Ｉｎｔｅｒａｃｔｉｖｅ」値、および「Ｂａｃｋｇｒｏｕｎｄ」（低優先順位）値と等しくなるようにセットすることができる。
− 「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」（ＴＨＰ）：このＱｏＳパラメータは、「Ｉｎｔｅｒａｃｔｉｖｅ」トラフィック・クラスの優先順位レベルを指定する。このパラメータは、３つの値のうちの１つと等しくすることができ、したがって、お互いに関する「Ｉｎｔｅｒａｃｔｉｖｅ」タイプ・プロファイルの優先順位を定義することができる。
【００１９】
これらのパラメータには、次のものが含まれるが、これらは本発明の枠組の中では使用されないので、参照のみの目的で記載しておく。
− 「Ｔｒａｎｓｆｅｒ ｄｅｌａｙ」：このＱｏＳパラメータは、パケットの転送中に最大遅延を与える。このＱｏＳパラメータは、リアルタイム・サービスのみに使用される。
− 「Ｇｕａｒａｎｔｅｅｄ ｂｉｔ ｒａｔｅ」：このＱｏＳパラメータは、パケットの転送中の保証されたスループットを示す。このＱｏＳパラメータは、リアルタイム・サービスのみに使用される。
− 「Ｍａｘｉｍｕｍ ｂｉｔ ｒａｔｅ」：このＱｏＳパラメータは、最大スループットを示す。
【００２０】
上述したＱｏＳパラメータのすべてが、３ＧＰＰ遠距離通信標準規格の枠組の中で定義される。しかし、その使用は、標準化されてはいない。
【００２１】
ＵＭＴＳ Ｒｅｌｅａｓｅ ９９では、この標準規格は、ＨＬＲで、パケット・サービスおよび回線サービスに関する加入者データ内に、優先順位レベルを有する可能性を提供する。「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」（ＡＲＰ）パラメータは、この目的に使用される。このパラメータは、パケット・ドメインについては、要求されたＰＤＰコンテキストごとにコア・ネットワーク内のＨＬＲで定義され、回線ドメインについては加入者によって定義される。
【００２２】
したがって、ＡＲＰパラメータは、無線リソースの割り振り／保存に関して加入者間で優先順位を定義することができる。ＡＲＰパラメータは、加入者サービス要求に優先順位を与えるのにＭＳＣ内、ＳＧＳＮ内、ＧＧＳＮ内、およびＵＴＲＡＮ内で使用され、コア・ネットワーク内では３つの値、すなわち、優先順位１、優先順位２、および優先順位３のうちの１つとすることができ、優先順位３が最低の優先順位である。
【００２３】
ＡＲＰパラメータは、４つのサブパラメータの形でＵＴＲＡＮ ＲＮＣに送信されて、加入者サービス要求に対応する通信に優先順位レベルを関連付ける。したがって、このパラメータは、コア・ネットワークで、ＵＴＲＡＮ ＲＮＣに送信するために４つのサブパラメータ、すなわち、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」、「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」、「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」、および「Ｑｕｅｕｉｎｇ ａｌｌｏｗｅｄ」に変換され、この４つのサブパラメータの値は、コア・ネットワークのＡＲＰパラメータから導出される。この４つのサブパラメータは、３ＧＰＰ標準規格のパートＴＳ ２５．４１３でより正確に定義されている。
【００２４】
コア・ネットワークＣＮによって送信される優先順位パラメータから開始して、ＵＴＲＡＮは、そのリソースのすべて（すなわち、無線リソース、転送リソース、および処理能力）を、異なるシステム・ユーザの間で分配できなければならない。
【００２５】
ＰＤＰコンテキスト・アクティブ化手順を、図２を参照して説明する。この手順は、移動端局ＭＳが、ＰＤＰコンテキストをＳＧＳＮまたはＧＧＳＮ内で記憶する必要があることを要求し、それにより、加入者によって要求されたサービスの実行のためにコア・ネットワーク内でリソースを予約することを可能にする。ＰＤＰコンテキストがアクティブ化されると、ＵＭＴＳ網内の異なるノードは、要求されたＰＤＰコンテキストおよび加入者の加入契約に関連するサービス品質情報、特にＡＲＰパラメータによって定義される加入者のトラフィック・クラスおよび優先順位を受信する。
【００２６】
加入者の優先順位に対応する情報、言い換えれば、その加入者が要求したＰＤＰコンテキストを定義するデータに含まれるＡＲＰパラメータが、加入者の位置を更新するとＳＧＳＮに送信される。次に、この情報は、加入者によるＰＤＰコンテキストのアクティブ化中にＧＧＳＮに送信され、次に、上で定義した４つのサブパラメータの形でＲＮＣに送信される。
【００２７】
したがって、ＰＤＰコンテキストをアクティブ化する手順は、加入者が要求したサービスを実行するためにその加入者が網でデータを送信または受信することを望む時に行われ、モバイル加入者のイニシアティブによってトリガされ、かくして当該端末が、その加入者によって要求された外部網との相互接続を行うＧＧＳＮサポート・ノードに知られることを可能にする。したがって、ＰＤＰコンテキストをアクティブ化するこの手順の終りに、対応するサービス品質プロファイルが、異なるネットワーク・ノードの間で交換され、その後、加入者によって要求されたサービスに対応するＵＭＴＳ網と外部網との間のデータ伝送を、開始することができる。
【００２８】
ステップ１では、移動端局ＭＳが、ＰＤＰコンテキストをアクティブ化するように、そのホームＳＧＳＮに要求し、所要のＱｏＳを指定する。このＳＧＳＮは、加入契約データおよび他のパラメータに応じて、所要のＱｏＳを変更することができる。
【００２９】
ステップ２および３では、ＳＧＳＮが、おそらくはＱｏＳパラメータを変更して、要求をＧＧＳＮに転送する。その後、用語「ネゴシエートされたＱｏＳ（ｎｅｇｏｔｉａｔｅｄ ＱｏＳ）」が使用される。次に、ＧＧＳＮは、もう一度ＱｏＳを変更し、ＳＧＳＮに送り返すことができる。
【００３０】
ステップ４および５では、ＳＧＳＮは、ネゴシエートされたＱｏＳをいわゆるＲａｄｉｏ Ａｃｃｅｓｓ Ｂｅａｒｅｒ ＲＡＢサービス要求の形で記述するとによって、通信チャネルに必要な無線リソースを割り振るようにＲＮＣに要求し、このＲＡＢサービス要求は、標準規格でＲＡＢパラメータと呼ばれるサービス品質パラメータの組を含み、具体的には、トラフィック・クラスおよびコア・ネットワークのＡＲＰパラメータからの４つのサブパラメータ出力を含む。ＲＡＢパラメータは、標準規格３ＧＰＰ ＴＳ ２５．４１３ ｖ４．０．０のセクション９．２．１．３で定義されている。
【００３１】
ＲＮＣは、この要求を受け入れ、ＲＡＢ属性から、このサービス要求をサポートするために提供される通信チャネルに必要な無線リソースの大きさを決定し、割り振ることを開始する。ＲＮＣは、必要なリソースが使用可能であるかどうかを検査し、そうでない場合には、あらかじめアクティブな通信チャネルに関連するサービス品質パラメータと新しい要求のパラメータとの関数としてリソースの不足を管理しなければならない。次に、ＲＮＣは、要求された通信チャネルを受け入れるか、または拒否することができる。
【００３２】
ステップ６で、ＳＧＳＮは、携帯電話機からの要求を受け入れ、網上で入手したサービス品質をその携帯電話機に送信する。
【００３３】
回線ドメインでは、テレビ電話タイプの発呼要求の例を検討する。第１ステップで、携帯電話機は、要求されたサービス品質を有する通信チャネルを入手することを目指して、コア・ネットワークにサービス要求を送信する。要求されたＱｏＳ特性は、伝送網機能（Ｂｅａｒｅｒ Ｃａｐａｂｉｌｉｔｙ）を含むフィールドに含まれる。これは、スループット、要求された接続タイプなどを指定する。この要求は、第２ステップで、ＩＳＤＮタイプの固定網に転送される。
【００３４】
最後に、コア・ネットワークは、上述したＲＡＢパラメータの形でサービス要求を記述する、対応する無線リソース割り振り要求を送信する。ＲＮＣは、このサービス要求をサポートするために通信チャネルに割り振らなければならない必要な無線リソースを計算する。ＲＮＣは、これらのリソースが使用可能であるかどうかを検証し、そうでない場合には、あらかじめアクティブな通信チャネルに関連するサービス品質パラメータと新しい要求のパラメータとの関数としてリソースの不足を管理しなければならない。次に、ＲＮＣは、要求された通信チャネルを受け入れるか、または拒否することができる。
【００３５】
考慮に入れなければならない重要な制約は、ＵＴＲＡＮが、ＣＮによって送信されたサービス品質パラメータから始めて、システムの異なるユーザの間で、（例えば、無線リソース（Ｕｕインターフェース）、転送リソース（Ｉｕインターフェース、Ｉｕｂインターフェース、およびＩｕｒインターフェース）、および処理能力として記述することができる）そのリソースのすべてを分配することができなければならないことである。標準規格で指定されたプリエンプション手順は、要求されたＱｏＳを満たすためのリソースが使用可能でない時に優先されるものとして、オペレータによって考慮されるユーザまたはサービスのリソースへのアクセスを容易にするために、これを行うのに使用することができる。
【００３６】
リソース割り振り要求が行われる時には、必ず、要求されたリソースが部分的にまたは完全に使用不能であるリスクがある。ＵＴＲＡＮに置かれた許可（ａｄｍｉｓｓｉｏｎ）検査は、アクセス網によって管理されるリソースの欠如を検出することができる。例えば、これらのリソースは、
− 上り方向および下り方向の出力と、
− 主に下り方向のコードと、
− アクセス網を構成する異なる機器内の物理リソースに対応する処理能力と、
− 転送網上の伝送能力、言い換えれば、アクセス網を形成する異なる機器を接続する異なる物理接続で割り振られたリソースと
によって特徴付けられる。
【００３７】
システムは、ＵＴＲＡＮのリソースが、オペレータが申し出るサービスにアクセスする権利を有するすべての加入者の間で最適に割り振られ／使用されることを保証しなければならない。標準規格は、加入者が、プリエンプション手順に基づいて、ネットワーク・オペレータとの間で結ばれた加入契約のタイプによって定義される彼らの優先順位に応じて別々に扱われなければならないと明示している。
【００３８】
具体的に言うと、プリエンプション手順には、所与のサービスに割り振られるリソースを減らすアルゴリズムと、優先されるものと考えられる要求を満たすのに十分なリソースを入手するアルゴリズムとの使用が含まれる。
【００３９】
しかし、３ＧＰＰ標準規格で与えられるＵＴＲＡＮでのリソース・プリエンプション手順への言及は極端に簡潔で、本質的に、ＵＴＲＡＮが、それに従って、優先順位の昇順で、より低い優先順位を有するＲＡＢのリソースをプリエンプトする機構を使用できるにすぎない、従うべきルールを単純に定義している。しかし、リソースにアクセスするために、別のＲＡＢではなく、あるＲＡＢに優先順位レベルを割り当てるための判断基準は、この標準規格には記載されていない。
【００４０】
したがって、ＵＴＲＡＮ内のリソースへのアクセス優先順位を定義する方法と、ＣＮによって送信され、ＲＡＢパラメータに含まれる優先順位パラメータ（言い換えると、「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」グループのパラメータ）の使用とは、網構築者によって選択された実施態様に依存する。
【００４１】
それでも、プリエンプション概念は、ＵＭＴＳオペレータにとって非常に重要である。なぜなら、このプリエンプション概念が、加入者クラスの管理を制御し、無線リソースへのアクセス手順を定義するからである。さらに、プリエンプションが網上で可能になる瞬間から始まって、どのリソースがどのユーザからどれほどの量だけプリエンプトされるかを定義するための、標準規格に記載されたメカニズムはない。
【非特許文献１】３ＧＰＰ標準規格のパートＴＳ ２５．４１３
【発明の開示】
【発明が解決しようとする課題】
【００４２】
従って、本発明の目的は、リソースをどのようにプリエンプトするか、および、どれほどの量のリソースをプリエンプトするかを選択するのに異なる判断基準を使用する、無線リソースのプリエンプション用の複数判断基準メカニズムを提案し、それにより、ネットワーク・オペレータが網アクセス・リソースの共用、および、割り振りのより柔軟な手順を定義できるようにすることによって、上述した弱点を克服することである。
【課題を解決するための手段】
【００４３】
上記課題を解決するための本発明に係る方法は、移動体通信網内での無線リソースの管理の方法であって、前記リソースが、要求されたサービス品質パラメータの組にそれぞれが関連する複数の通信チャネルに割り振られ、前記方法が、要求されたサービス品質パラメータの組に関連する通信チャネルに関する新しい要求の受入れに続き、前記新しい要求をサポートするのに必要なリソースの欠如の検出に続く、リソース・プリエンプション手順の使用を含み、リソース・プリエンプション手順が、異なる通信チャネル間の順序関係をセットアップするために、予めアクティブな通信チャネルのそれぞれに関連する優先順位レベルの関数として、予めアクティブな通信チャネルへのリソースの割り振りを変調するように設計され、前記プリエンプション手順が、
ａ− プリエンプトできる、網上のアクティブ通信チャネルを識別し、それらの間で、事前定義の選択判断基準に従って最低優先順位の通信チャネルを選択するステップと、
ｂ− 選択された通信チャネルの少なくとも部分的再構成によって得られる無線リソースの増加を評価するステップであって、前記選択された通信チャネルおよび前記関連する増加が、再構成リストに記憶されるステップと、
ｃ− リストに含まれるすべての通信チャネルによって達成される増加が前記新しい要求をサポートするのに十分であるかどうかを検査するステップと、
ｄ− ステップａからｃを、
− 得られる利益が十分になるまで繰り返し、この場合に、リストに含まれる通
信チャネルが再構成され、新しい要求が受け入れられ、または、
− プリエンプトできるすべての通信チャネルが、十分な利益を得ることなく評
価されるまで繰り返し、この場合に、新しい要求が拒否される
ステップと
を含むことを特徴とする方法である。
【００４４】
プリエンプトできる通信チャネルを識別するステップは、関連する優先順位レベルが新しい要求に関連する優先順位レベルより低い伝送サービスを判定することからなることが好ましい。
【００４５】
好ましくは、プリエンプトできる通信チャネルは、少なくとも関連するサービス品質パラメータから記述されるサービス品質が、所定の最低サービス品質よりよい、という条件をも満たす。
【００４６】
最低サービス品質は、最小バイナリ・スループット値に対応し、プリエンプトできる通信チャネルは、スループットに関する関連するサービス品質パラメータが、前記最小の事前定義のスループット値より大きい値を含む、という条件を満たすことが好ましい。
【００４７】
一実施形態によれば、選択された通信チャネルの再構成は、前記通信チャネルに割り振られたすべてのリソースをプリエンプトすることからなる。
【００４８】
別の実施形態によれば、選択された通信チャネルの再構成は、少なくとも関連するサービス品質パラメータから始まる記述されたサービス品質が所定の最低サービス品質に達するように、前記チャネルに割り振られたリソースの一部をプリエンプトすることからなる。
【００４９】
好ましくは、選択された通信チャネルは、その再構成によって得られる増加が構成可能な再構成閾値以上であることをチェックした後に、再構成リストに記憶される。
【００５０】
プリエンプトできる通信チャネルの中の最低優先順位の通信チャネルは、少なくとも、前記通信チャネルのそれぞれに関連する優先順位レベルとスループット・サービス品質パラメータとを考慮に入れて選択されることが好ましい。
【００５１】
好ましくは、プリエンプトできる通信チャネルの中の最低優先順位の通信チャネルは、前記通信チャネルのそれぞれに関連するサービス・タイプに関連する少なくとも１つのサービス品質パラメータも考慮に入れて選択される。
【００５２】
一実施形態によれば、通信チャネルに関連する優先順位レベルは、第１に「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」サービス品質パラメータの値を、第２にサービス・タイプに関連する少なくとも１つのサービス品質パラメータの値を考慮に入れて決定される「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値によって定義される。
【００５３】
対応する通信チャネルの優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値を決定するのに使用されるサービスのタイプに関連するサービス品質パラメータは、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータを含むことが好ましい。
【００５４】
対応する通信チャネルの優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータに割り当てられる値を決定するのに使用されるサービスのタイプに関連するサービス品質パラメータは、対話タイプ・サービスの互いに関する優先順位を定義する「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータも含むことが好ましい。
【００５５】
本発明は、サービス品質パラメータの組にそれぞれが関連する複数の通信チャネルにリソースを割り振る手段を含む移動体通信網内の無線リソース管理デバイスであって、本発明の方法を実施する手段を含むことを特徴とする無線リソース管理デバイスにも関する。
【００５６】
本発明は、データ媒体に保管されたコンピュータ・プログラムであって、本発明の方法の実行を制御するためにソフトウェア命令を含むことを特徴とするコンピュータ・プログラムにも関する。
【００５７】
本発明の他の特性および利点は、添付図面を参照して例示的かつ非限定的な例として与えられる以下の説明を読むことにより明瞭になるであろう。
【発明を実施するための最良の形態】
【００５８】
図３は、ＵＴＲＡＮでの無線リソースの割り振りを管理するプリエンプション手順の使用に関する特定の実施形態を示す。
【００５９】
ＵＭＴＳ網での新しいサービス要求の受入れ（図３では符号１０）時に、コア・ネットワークは、対応する無線リソース割り振り要求を、サービス品質パラメータの組の形でＵＴＲＡＮに送信する。ＵＴＲＡＮ、具体的には無線ネットワーク制御装置ＲＮＣデバイスは、このサービス要求をサポートするのに使用される通信チャネルに必要なリソースを計算することによって、受入れをチェックする。プリエンプション手順は、アクセス網によって管理されるリソースが、このサービス要求をサポートするのに十分でないことをＵＴＲＡＮに置かれた受入れチェック手段によって検出された（ステップ２０）場合に使用される。要求されたリソースが、部分的にまたは完全に使用不能である場合がある。
【００６０】
例えば、リソースの欠如の検出は、下り方向の出力の欠如の検出に基づくものとすることができる。リソースの欠如は、コードの欠如、すなわち、処理能力の欠如を特徴とすることもできる。どの場合でも、リソースの欠如の特徴付けは、網アーキテクチャ、および、機器製造業者に依存する。
【００６１】
「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」パラメータを使用して、プリエンプション手順を実施することができ、このパラメータの値は、関連する通信チャネルが他のあらかじめアクティブな通信チャネルのリソースをプリエンプトできるか否かを示し、「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」パラメータを使用することもでき、このパラメータの値は、関連する通信チャネルのリソースが他の通信チャネルによってプリエンプトされ得るかどうかを示す。
【００６２】
したがって、例えば、プリエンプション手順を使用するためには、それに関する受入れがリソース問題を生じるチャネルの「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」パラメータの値が、対応するチャネルが他の通信チャネルをプリエンプトできることを示さなければならない。その場合に、プリエンプト手順をトリガして、優先順位の関数として予めアクティブな通信チャネルへの無線リソースの割り振りを減らすことにより、新しいチャネル要求を受け入れることができることになる。
【００６３】
これを達成するために、ステップ３０を使用して、プリエンプトできる、網上でアクティブな通信チャネルを識別する。この例によれば、この識別ステップは、第１に、関連する「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」パラメータがプリエンプションに対する脆弱性を示し、第２に、関連する優先順位レベルが、その受入れがリソース問題を生じるチャネルに関連する優先順位レベルより低い、アクティブ通信チャネルを判定することからなるものとすることができる。
【００６４】
しかし、「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」パラメータおよび「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」パラメータを使用することは、この方法を使用する上で、任意に選択し得ることであることに留意されたい。
【００６５】
本明細書で言及する、各チャネル要求に関連する優先順位レベルは、異なる通信チャネル間の順序関係をセット・アップすることを可能にするが、例えば、サービス・タイプに関連する少なくとも１つのサービス品質パラメータ、すなわち、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータおよび「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータの値、または標準の「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値によって定義することができる。
【００６６】
１つの変形で、通信チャネルごとに優先順位レベルを定義するのに使用される「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータの「Ｐｒｉｏｒｉｔｙ ｌｅｖｅｌ」パラメータの値は、第１にコア・ネットワークの「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータの値、第２にサービス・タイプに関連する少なくとも１つのパラメータの値を考慮に入れることによって決定することができる。第１実施形態では、サービス・タイプに関連する、各通信チャネルに関連する優先順位レベルを定義するために「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」サブパラメータに割り当てられる値を決定するのに使用されるサービス品質パラメータに、４つの値のうちの１つと等しいものとすることができる「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータが含まれる。第２実施形態では、使用されるサービス・タイプに関連するサービス品質パラメータに、３つの値のうちの１つと等しいものとすることができ、優先順位をセットするのに使用できる、言い換えれば、対話タイプ・サービス（言い換えれば、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータの値が「Ｉｎｔｅｒａｃｔｉｖｅ」と等しいサービス）を優先順位レベルによる順序にするのに使用できる、「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータも含まれる。
【００６７】
この方法で、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの１２個までの値、したがって１２個までの優先順位レベルを、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」サービス品質パラメータおよびコア・ネットワークの「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」サービス品質パラメータを使用して、異なる通信チャネルについて定義することができる。
【００６８】
さらに、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの１８個までの値、したがって１８個までの優先順位レベルを、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータ、コア・ネットワークの「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータ、および「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータを使用して、異なる通信チャネルについて定義することができる。
【００６９】
１つの好ましい実施形態によれば、本発明の使用されるプリエンプション手順は、リソースをプリエンプトされる加入者が、最低サービス品質を維持することを保証するであろう。この最低サービス品質は、サービス品質プロファイルのすべてまたは一部を含む、所与の通信チャネル要求に固有のＵＴＲＡＮの既知のパラメータから定義される。
【００７０】
また、この好ましい実施形態によれば、プリエンプトできる、網上のアクティブ通信チャネルを識別する（ステップ３０）ために、これらのチャネルが、少なくとも１つの関連するサービス品質パラメータを使用して記述されたサービス品質が、最低の要求されたサービス品質よりよいことをチェックすることも必要である。したがって、最低サービス品質を定義することによって、オペレータが一部のサービス品質パラメータを他のサービス品質パラメータより優先することを可能にすることができる。
【００７１】
一例によれば、最低サービス品質は、ダウンリンク上の最小バイナリ・スループット値に対応する。したがって、所与の通信チャネルに関連するサービス品質は、割り振られたダウンリンク上のバイナリ・スループットに関して理解され、そのダウンリンク上の最小スループットと比較される。これは、接続がセットアップされる時に要求される「Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｄｏｗｎｌｉｎｋ」パラメータを使用して行われる。したがって、プリエンプトできるアクティブ通信チャネルは、それに関連するサービス品質パラメータ「Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｄｏｗｎｌｉｎｋ」値が、要求されたサービス品質値より大きいことを検証する必要がある。
【００７２】
要求されたサービス品質値は、「Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｕｐｌｉｎｋ」スループット・サービス品質パラメータ、「Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｆｏｒ Ｄｏｗｎｌｉｎｋ」スループット・サービス品質パラメータ、および「Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｕｐｌｉｎｋ」スループット・サービス品質パラメータを使用して記述することもできる。
【００７３】
ステップ３０においてプリエンプトできる少なくとも１つの通信チャネルが識別された場合に、ステップ４０が使用される。このステップ４０は、事前に定義された選択判断基準に従って、プリエンプト可能であると識別された通信チャネルの中で、最低優先順位の通信チャネルを選択することからなる。
【００７４】
例えば、第１ステップは、標準の「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値の昇順で通信チャネルを選択することである。同一優先順位レベルを有する通信チャネルから構成されるサブグループ内で実行される第１ステップは、トラフィック・クラスが「Ｂａｃｋｇｒｏｕｎｄ」タイプである通信チャネルを選択し、次に、トラフィック・クラスが「Ｉｎｔｅｒａｃｔｉｖｅ」タイプである通信チャネルを選択することである。
【００７５】
各通信チャネルの優先順位レベルを定義するのに使用される「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータが、第１にコア・ネットワークによって送信された「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータの値、第２にサービス・タイプに関連する少なくとも１つのサービス品質パラメータの値を考慮に入れて決定される、上述した変形例によれば、プリエンプト可能であると識別された通信チャネルの中で最低優先順位の通信チャネルは、単純に、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値の昇順で通信チャネルを選択することによって選択される。
【００７６】
次に、同一優先順位レベルを有する通信チャネルによって形成されるサブグループ内で、通信チャネルを、例えば、最低サービス品質を保証するための所定の最小バイナリ・スループットに対する、割り振られたダウンリンク上のバイナリ・スループットの比の昇順で選択することができる。
【００７７】
プリエンプト可能であると識別された通信チャネルの中で最低優先順位の通信チャネルを選択した後に、ステップ５０が、この通信チャネルを再構成する場合に得られるリソースの増加を評価するために適用される。このステップ５０は、この通信チャネルに割り振られたリソースが、最低の所定のサービス品質、すなわち、この例では、固定ダウンリンク上の最小バイナリ・スループットに達するようにプリエンプトされた場合に得られるであろう増加を推定することからなる。
【００７８】
上記得られるリソースの増加は、ステップ６０で、パラメータによって定義される再構成可能閾値と比較されることが好ましい。それ未満では得られる増加が十分ではないと考えられる構成可能閾値を定義することができる。その場合に、リソースは、この通信チャネル上ではプリエンプトされない。そのような閾値を定義することの目的は、通信チャネル再構成の回数を制限することである。
【００７９】
１つの例の実施形態では、例えば下り方向の総出力の増加を特徴とする、得られるリソースの増加が、新しいサービス要求に対応する新しい通信チャネルを受け入れるために必要な出力の１０％の構成可能閾値未満である場合に、選択された通信チャネルは、プリエンプト不可能であると見なされ、この手順は、ステップ３０に戻って再開される。そうでない場合には、選択された通信チャネルは、プリエンプト可能であると考えられ、再構成される通信チャネルを含む再構成リストに、この通信チャネルに関連する評価された増加と共に含められる。
【００８０】
次に、ステップ７０は、プリエンプションに関する再構成リストに含まれるすべての通信チャネルから得られる増加が、要求された通信チャネルのリソース要求にサービスするのに十分なリソースを解放するか否かを検証することからなる。
【００８１】
ステップ３０から７０は、得られる増加が十分になるまで繰り返され、得られる増加が十分になる場合に、ステップ８０が実施され、このステップ８０では、再構成リストに含まれる通信チャネルが、新しい通信チャネルを受け入れるのに必要なリソースを効果的に回復するために再構成され、その後、この手順は終了する。
【００８２】
もう１つの事例が発生する可能性があり、この事例では、ステップ３０から７０が、プリエンプト可能であると識別されたすべての通信チャネルが最低ＱｏＳを有するリソースの増加に関して評価されるまで繰り返されるが、リソースの必要な増加が得られない。
【００８３】
最低サービス品質未満のランクを有するすべての通信チャネルを再構成した後に得られる増加が十分でない場合に、この手順には、プリエンプトできるすべての通信チャネルのすべてのリソースをプリエンプトする手段が含まれる。
【００８４】
したがって、より低いランクを有するすべての識別された通信チャネルが、十分な増加を得ることなく最低サービス品質で評価された時に、最低サービス品質を尊重する条件をまったく伴わずに、プリエンプトできるすべての通信チャネルを識別することからなるステップ３５が、実施される。したがって、これには、第１に、関連する「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」ＲＡＢパラメータがプリエンプションに対する脆弱性を示し、第２に、関連する優先順位レベルが新しいチャネル要求に関連する優先順位レベルより低い、通信チャネルが含まれる。
【００８５】
上でステップ３０から７０を参照して説明したループが、ステップ５０がステップ５５に置換されることを除いて、ステップ３５でプリエンプト可能であると識別された通信チャネル上でもう一度使用され、ステップ５５は、ある選択された通信チャネルに割り振られたリソースが完全にプリエンプトされた場合に、その通信チャネルについて得られるリソースの増加を推定することからなる。同様に、この手順は、再構成リストに含まれるすべての通信チャネルから得られる増加が十分になるまでループする。
【００８６】
しかし、プリエンプトできるすべての識別された通信チャネルが、この第２ループで完全プリエンプションで評価され、得られる増加が、新しいサービス要求をサポートするのに依然として十分でない場合には、このサービス要求は、ステップ９０に示されているように拒否され、この手順は終了する。
【００８７】
このプリエンプト手順を、おそらくはプリエンプションの対象であると識別された通信チャネルに基づいて使用し、尊重されるべき最低サービス品質を用いる第１フェーズを実行せずに、完全プリエンプションを用いて直接に評価することもできる。
【００８８】
ＵＴＲＡＮは、ＲＮＣ無線ネットワーク・コントローラ・デバイス内で本発明による方法の異なるステップを実行するように配置されたデータ処理手段を含まなければならない。より正確には、上述した方法のステップは、ソフトウェア命令の制御の下で、データ処理デバイス、実際には無線ネットワーク・コントローラ・デバイスによって実行される。その結果、本発明は、コンピュータ・デバイスによるこの方法の実行を制御するためにソフトウェア命令を含むデータ媒体に保管できるか、またはこのデータ媒体によって伝送できるコンピュータ・プログラムにも関する。このデータ媒体は、ハードウェア記憶媒体、例えばＣＤ−ＲＯＭ、磁気ディスケット、またはハード・ディスクとするか、あるいは電気信号、光信号、または無線信号などの伝送可能媒体とすることができる。
【００８９】
上に説明した実施形態は、ＵＭＴＳ網に関するものであるが、本発明は、ＧＰＲＳ網およびすべての類似するタイプの移動体通信網に適用可能であることは明らかである。
【００９０】
＜用語集＞
この用語集は、本特許出願で使用される頭字語のリストである。これらの頭字語のほとんどは、３ＧＰＰ遠距離通信標準規格の枠組で定義されている。
３ＧＰＰ： Ｔｈｉｒｄ−Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏ
ｊｅｃｔ（ＥＴＳＩの）
ＧＳＭ： Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉ
ｃａｔｉｏｎｓ
ＵＭＴＳ： Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉ
ｏｎｓ Ｓｙｓｔｅｍ
ＩＰ： Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ
ＢＳＣ： Ｂａｓｅ Ｓｔａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ
ＨＬＲ： Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ
ＳＧＳＮ： Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ
ＧＧＳＮ： Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ
ＵＴＲＡＮ： ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅ
ｔｗｏｒｋ
ＲＮＣ： Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ
ＱｏＳ： Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ
ＦＴＰ： Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ
ＡＲＰ： Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ
ＰＤＰ： Ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ
ＴＨＰ： Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ
ＲＡＢ： Ｒａｄｉｏ Ａｃｃｅｓｓ Ｂｅａｒｅｒ
【図面の簡単な説明】
【００９１】
【図１】ＵＭＴＳタイプ網のアーキテクチャを示す図である。
【図２】パケット・ドメインのＰＤＰコンテキストをアクティブ化する手順を示す図である。
【図３】本発明の方法の使用に関する特定の実施形態を示す流れ図である。
【技術分野】
【０００１】
本発明は、全般的には遠距離通信の領域に関し、より具体的には、パケット・モードの移動体通信網内のアクセス網において、無線リソースを管理する方法に関するものである。
【背景技術】
【０００２】
本発明による方法は、３ＧＰＰ標準規格に準拠するＧＰＲＳテクノロジまたはＵＭＴＳテクノロジを使用する携帯電話ネットワークに適用されるように設計される。説明を過度に複雑にしないようにするために、この説明の終りに、使用されるすべての頭字語の定義を含む用語集欄を設けるので参照されたい。
【０００３】
ＵＭＴＳ標準規格は、パケット・モードでの新しいデータ伝送サービスを指定し、モバイル・オペレータへの加入者に、ＩＰに基づくサービス（電子メッセージング、ファイルのダウンロード、ウェブ・サイトまたはＷＡＰサイトの閲覧）へのアクセスを含む様々な特徴を提供することができる。したがって、データ（ＩＰパッケージで伝送される）を、ＵＭＴＳ網の外部の網、通常はインターネット・ネットワークに属するサーバと、携帯電話機との間で交換することができる。現在、ＵＭＴＳは、リリースとも呼ばれる異なるバージョン、特にＲｅｌｅａｓｅ ９９で段階的に実行され、このＲｅｌｅａｓｅ ９９には、次の説明が具体的に適用可能である。
【０００４】
アーキテクチャに関して、ＵＭＴＳ網は、図１に示されているように、２つのサブネットワーク、すなわち、コア・ネットワークＣＮと、ＵＴＲＡＮとも呼ばれる無線アクセス網とに分割することができる。
【０００５】
アクセス網には、無線ネットワーク制御装置ＲＮＣノードによって割り振られた無線リソースを使用して無線インターフェースを介してユーザ機器ＵＥと通信するように設計された複数のＮｏｄｅ Ｂ無線基地局が含まれる。１つの実体が複数の下位実体を制御する階層アーキテクチャは、ＧＳＭ無線アクセス網と同一である。無線ネットワーク制御装置ＲＮＣは、ＧＳＭ基地局制御装置（ＢＳＣ）として働く。しかし、情報を転送するのに使用される無線テクノロジは異なる。
【０００６】
ＵＭＴＳコア・ネットワークＣＮには、２つの別個のドメイン、すなわち、テレフォニに関するすべてのサービスを含む回線ドメイン（ｃｉｒｃｕｉｔ ｄｏｍａｉｎ）ＣＳと、パケット交換に関するすべてのサービスを含むパケット・ドメイン（ｐａｃｋｅｔ ｄｏｍａｉｎ）ＰＳとが含まれる。
【０００７】
コア・ネットワークには、この２つのドメインに共通するデータベースであるＨＬＲが含まれ、このＨＬＲには、ネットワーク・オペレータの加入者のすべてに関する情報すなわち、加入者電話番号、携帯電話機の識別、および加入契約に関する情報が保管される。ＨＬＲには、本説明で後で定義される加入者およびサービスに関係するサービス品質情報も含まれる。したがって、このデータベースは、網内のモバイル加入者の管理に使用される。
【０００８】
コア・ネットワークは、ＭＳＣ回線交換機およびＳＧＳＮパケット交換機もホストする。コア・ネットワーク内のこれらのサポート・ノードは、アクセス網との通信リンクを制御するのに使用される。これらの交換機は、ＨＬＲから入手された加入者のプロファイルを保管し、加入者によって要求されたネットワーク・リソースを制御する。
【０００９】
パケット・ドメインでは、ＳＧＳＮは、もう１つのサポート・ノード、すなわちＧＧＳＮに関連し、このＧＧＳＮは、より具体的には、外部パケット交換網（インターネットなど）へのゲートウェイとして働く。したがって、パケット・ドメインについて、ＵＭＴＳコア・ネットワークは、ゲートウェイ、すなわち、サポート・ノードＧＧＳＮを介して外部と相互接続され、このＧＧＳＮには、セキュリティを維持しながら、携帯電話機が外部網、具体的にはインターネット・ネットワークと通信するのに使用するルーティング情報が含まれる。次に、ＧＧＳＮは、コア・ネットワーク内のモビリティ、認証、および暗号化を制御する他方のサポート・ノード、すなわちＳＧＳＮを使用して、携帯電話機に情報を送信する。これらの網要素は、ＩＰルータ機能を含み、ＩＰタイプ・ネットワークを形成する。
【００１０】
回線ドメインでは、パケット・ドメインを参照して説明したように、ＭＳＣが、固定ＲＮＣ、ＩＳＤＮタイプ・ネットワークなどへのゲートウェイとして働くもう１つのサポート・ノード、すなわち、ＧＭＳＣに関連する。
【００１１】
Ｒｅｌｅａｓｅ ９９では、すべてのＵＭＴＳサービスが、４つの標準トラフィック・クラス、すなわち、「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」、「Ｓｔｒｅａｍｉｎｇ」、「Ｉｎｔｅｒａｃｔｉｖｅ」、および「Ｂａｃｋｇｒｏｕｎｄ」によってサポートされる。
【００１２】
「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」クラスおよび「Ｓｔｒｅａｍｉｎｇ」クラスは、主に音声またはビデオなどのリアルタイム・フローを搬送するために設計された。しかし、ユーザがリアルタイムでビデオ・ストリームを見る（またはオーディオ・ストリームを聞いている）使用に対応する「Ｓｔｒｅａｍｉｎｇ」クラスについて、データ転送時間に対する制約は、「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」クラスほど厳しくはない。
【００１３】
「Ｉｎｔｅｒａｃｔｉｖｅ」クラスおよび「Ｂａｃｋｇｒｏｕｎｄ」クラスは、非リアルタイム・サービスに対応し、ナビゲーション・アプリケーション、電子メール・アプリケーション、ＦＴＰアプリケーションなどの伝統的なインターネット・アプリケーションの枠組での使用のために提供される。この後者のクラスは、非リアルタイムであり、再送信方法およびコーディング方法に起因して、エラー率においてよりよい性能を提供する。
【００１４】
これらのクラスの間の主な区別要因は、実際には、遅延に対する感度である。「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」トラフィック・クラスは、遅延に非常に敏感であるが、「Ｂａｃｋｇｒｏｕｎｄ」トラフィック・クラスは、全く敏感ではない。
【００１５】
アクセス網内のリソース、より具体的には無線リソースの配分は、サービス要求に関連するサービス品質（ＱｏＳ）パラメータを利用して制御される。
【００１６】
したがって、ＵＭＴＳ伝送サービスのＱｏＳパラメータは、ＵＭＴＳ網を介してＵＭＴＳ伝送サービスのユーザに与えられるサービスを記述する。ＱｏＳパラメータの組によって形成されるＱｏＳプロファイルが、このサービスを指定する。したがって、これらは、特にスループット、トラフィック・タイプ、優先順位などに関して、網上のデータ・ストリームの主要な特性を定義するのに使用される標準パラメータである。これらのデータは、ＨＬＲ内の加入者のプロファイルに保管され、種々の手順によって次の実体（ＳＧＳＮおよびＭＳＣ）に伝送される。
【００１７】
ＵＭＴＳ加入者のＱｏＳプロファイルは、実際には、その加入者が要求できる最高のＱｏＳに対応する。ＱｏＳプロファイルは、オペレータによって構成されるデフォルト・プロファイルとすることもできる。
【００１８】
ＱｏＳプロファイルで指定されるＱｏＳパラメータは、主に次の通りである。
− 「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」（ＡＲＰ）：このＱｏＳパラメータは、ＵＭＴＳ伝達サービスの割り振りおよびプリエンプションに関して、複数の加入者間のトラフィック優先順位を識別するのに使用される。このタイプのパラメータは、ドメインごとに、すなわち、パケット・ドメインおよび回線ドメインについて指定される。
− 「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」：このＱｏＳパラメータは、サービス・タイプに関連する優先順位を示す。上述したように、Ｒｅｌｅａｓｅ ９９では、すべてのサービスが、４つのトラフィック・クラスによってサポートされる。したがって、このＱｏＳパラメータは、「Ｃｏｎｖｅｒｓａｔｉｏｎａｌ」（リアルタイム要件が非常に重要なので、高優先順位に対応する）値、「Ｓｔｒｅａｍｉｎｇ」値、「Ｉｎｔｅｒａｃｔｉｖｅ」値、および「Ｂａｃｋｇｒｏｕｎｄ」（低優先順位）値と等しくなるようにセットすることができる。
− 「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」（ＴＨＰ）：このＱｏＳパラメータは、「Ｉｎｔｅｒａｃｔｉｖｅ」トラフィック・クラスの優先順位レベルを指定する。このパラメータは、３つの値のうちの１つと等しくすることができ、したがって、お互いに関する「Ｉｎｔｅｒａｃｔｉｖｅ」タイプ・プロファイルの優先順位を定義することができる。
【００１９】
これらのパラメータには、次のものが含まれるが、これらは本発明の枠組の中では使用されないので、参照のみの目的で記載しておく。
− 「Ｔｒａｎｓｆｅｒ ｄｅｌａｙ」：このＱｏＳパラメータは、パケットの転送中に最大遅延を与える。このＱｏＳパラメータは、リアルタイム・サービスのみに使用される。
− 「Ｇｕａｒａｎｔｅｅｄ ｂｉｔ ｒａｔｅ」：このＱｏＳパラメータは、パケットの転送中の保証されたスループットを示す。このＱｏＳパラメータは、リアルタイム・サービスのみに使用される。
− 「Ｍａｘｉｍｕｍ ｂｉｔ ｒａｔｅ」：このＱｏＳパラメータは、最大スループットを示す。
【００２０】
上述したＱｏＳパラメータのすべてが、３ＧＰＰ遠距離通信標準規格の枠組の中で定義される。しかし、その使用は、標準化されてはいない。
【００２１】
ＵＭＴＳ Ｒｅｌｅａｓｅ ９９では、この標準規格は、ＨＬＲで、パケット・サービスおよび回線サービスに関する加入者データ内に、優先順位レベルを有する可能性を提供する。「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」（ＡＲＰ）パラメータは、この目的に使用される。このパラメータは、パケット・ドメインについては、要求されたＰＤＰコンテキストごとにコア・ネットワーク内のＨＬＲで定義され、回線ドメインについては加入者によって定義される。
【００２２】
したがって、ＡＲＰパラメータは、無線リソースの割り振り／保存に関して加入者間で優先順位を定義することができる。ＡＲＰパラメータは、加入者サービス要求に優先順位を与えるのにＭＳＣ内、ＳＧＳＮ内、ＧＧＳＮ内、およびＵＴＲＡＮ内で使用され、コア・ネットワーク内では３つの値、すなわち、優先順位１、優先順位２、および優先順位３のうちの１つとすることができ、優先順位３が最低の優先順位である。
【００２３】
ＡＲＰパラメータは、４つのサブパラメータの形でＵＴＲＡＮ ＲＮＣに送信されて、加入者サービス要求に対応する通信に優先順位レベルを関連付ける。したがって、このパラメータは、コア・ネットワークで、ＵＴＲＡＮ ＲＮＣに送信するために４つのサブパラメータ、すなわち、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」、「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」、「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」、および「Ｑｕｅｕｉｎｇ ａｌｌｏｗｅｄ」に変換され、この４つのサブパラメータの値は、コア・ネットワークのＡＲＰパラメータから導出される。この４つのサブパラメータは、３ＧＰＰ標準規格のパートＴＳ ２５．４１３でより正確に定義されている。
【００２４】
コア・ネットワークＣＮによって送信される優先順位パラメータから開始して、ＵＴＲＡＮは、そのリソースのすべて（すなわち、無線リソース、転送リソース、および処理能力）を、異なるシステム・ユーザの間で分配できなければならない。
【００２５】
ＰＤＰコンテキスト・アクティブ化手順を、図２を参照して説明する。この手順は、移動端局ＭＳが、ＰＤＰコンテキストをＳＧＳＮまたはＧＧＳＮ内で記憶する必要があることを要求し、それにより、加入者によって要求されたサービスの実行のためにコア・ネットワーク内でリソースを予約することを可能にする。ＰＤＰコンテキストがアクティブ化されると、ＵＭＴＳ網内の異なるノードは、要求されたＰＤＰコンテキストおよび加入者の加入契約に関連するサービス品質情報、特にＡＲＰパラメータによって定義される加入者のトラフィック・クラスおよび優先順位を受信する。
【００２６】
加入者の優先順位に対応する情報、言い換えれば、その加入者が要求したＰＤＰコンテキストを定義するデータに含まれるＡＲＰパラメータが、加入者の位置を更新するとＳＧＳＮに送信される。次に、この情報は、加入者によるＰＤＰコンテキストのアクティブ化中にＧＧＳＮに送信され、次に、上で定義した４つのサブパラメータの形でＲＮＣに送信される。
【００２７】
したがって、ＰＤＰコンテキストをアクティブ化する手順は、加入者が要求したサービスを実行するためにその加入者が網でデータを送信または受信することを望む時に行われ、モバイル加入者のイニシアティブによってトリガされ、かくして当該端末が、その加入者によって要求された外部網との相互接続を行うＧＧＳＮサポート・ノードに知られることを可能にする。したがって、ＰＤＰコンテキストをアクティブ化するこの手順の終りに、対応するサービス品質プロファイルが、異なるネットワーク・ノードの間で交換され、その後、加入者によって要求されたサービスに対応するＵＭＴＳ網と外部網との間のデータ伝送を、開始することができる。
【００２８】
ステップ１では、移動端局ＭＳが、ＰＤＰコンテキストをアクティブ化するように、そのホームＳＧＳＮに要求し、所要のＱｏＳを指定する。このＳＧＳＮは、加入契約データおよび他のパラメータに応じて、所要のＱｏＳを変更することができる。
【００２９】
ステップ２および３では、ＳＧＳＮが、おそらくはＱｏＳパラメータを変更して、要求をＧＧＳＮに転送する。その後、用語「ネゴシエートされたＱｏＳ（ｎｅｇｏｔｉａｔｅｄ ＱｏＳ）」が使用される。次に、ＧＧＳＮは、もう一度ＱｏＳを変更し、ＳＧＳＮに送り返すことができる。
【００３０】
ステップ４および５では、ＳＧＳＮは、ネゴシエートされたＱｏＳをいわゆるＲａｄｉｏ Ａｃｃｅｓｓ Ｂｅａｒｅｒ ＲＡＢサービス要求の形で記述するとによって、通信チャネルに必要な無線リソースを割り振るようにＲＮＣに要求し、このＲＡＢサービス要求は、標準規格でＲＡＢパラメータと呼ばれるサービス品質パラメータの組を含み、具体的には、トラフィック・クラスおよびコア・ネットワークのＡＲＰパラメータからの４つのサブパラメータ出力を含む。ＲＡＢパラメータは、標準規格３ＧＰＰ ＴＳ ２５．４１３ ｖ４．０．０のセクション９．２．１．３で定義されている。
【００３１】
ＲＮＣは、この要求を受け入れ、ＲＡＢ属性から、このサービス要求をサポートするために提供される通信チャネルに必要な無線リソースの大きさを決定し、割り振ることを開始する。ＲＮＣは、必要なリソースが使用可能であるかどうかを検査し、そうでない場合には、あらかじめアクティブな通信チャネルに関連するサービス品質パラメータと新しい要求のパラメータとの関数としてリソースの不足を管理しなければならない。次に、ＲＮＣは、要求された通信チャネルを受け入れるか、または拒否することができる。
【００３２】
ステップ６で、ＳＧＳＮは、携帯電話機からの要求を受け入れ、網上で入手したサービス品質をその携帯電話機に送信する。
【００３３】
回線ドメインでは、テレビ電話タイプの発呼要求の例を検討する。第１ステップで、携帯電話機は、要求されたサービス品質を有する通信チャネルを入手することを目指して、コア・ネットワークにサービス要求を送信する。要求されたＱｏＳ特性は、伝送網機能（Ｂｅａｒｅｒ Ｃａｐａｂｉｌｉｔｙ）を含むフィールドに含まれる。これは、スループット、要求された接続タイプなどを指定する。この要求は、第２ステップで、ＩＳＤＮタイプの固定網に転送される。
【００３４】
最後に、コア・ネットワークは、上述したＲＡＢパラメータの形でサービス要求を記述する、対応する無線リソース割り振り要求を送信する。ＲＮＣは、このサービス要求をサポートするために通信チャネルに割り振らなければならない必要な無線リソースを計算する。ＲＮＣは、これらのリソースが使用可能であるかどうかを検証し、そうでない場合には、あらかじめアクティブな通信チャネルに関連するサービス品質パラメータと新しい要求のパラメータとの関数としてリソースの不足を管理しなければならない。次に、ＲＮＣは、要求された通信チャネルを受け入れるか、または拒否することができる。
【００３５】
考慮に入れなければならない重要な制約は、ＵＴＲＡＮが、ＣＮによって送信されたサービス品質パラメータから始めて、システムの異なるユーザの間で、（例えば、無線リソース（Ｕｕインターフェース）、転送リソース（Ｉｕインターフェース、Ｉｕｂインターフェース、およびＩｕｒインターフェース）、および処理能力として記述することができる）そのリソースのすべてを分配することができなければならないことである。標準規格で指定されたプリエンプション手順は、要求されたＱｏＳを満たすためのリソースが使用可能でない時に優先されるものとして、オペレータによって考慮されるユーザまたはサービスのリソースへのアクセスを容易にするために、これを行うのに使用することができる。
【００３６】
リソース割り振り要求が行われる時には、必ず、要求されたリソースが部分的にまたは完全に使用不能であるリスクがある。ＵＴＲＡＮに置かれた許可（ａｄｍｉｓｓｉｏｎ）検査は、アクセス網によって管理されるリソースの欠如を検出することができる。例えば、これらのリソースは、
− 上り方向および下り方向の出力と、
− 主に下り方向のコードと、
− アクセス網を構成する異なる機器内の物理リソースに対応する処理能力と、
− 転送網上の伝送能力、言い換えれば、アクセス網を形成する異なる機器を接続する異なる物理接続で割り振られたリソースと
によって特徴付けられる。
【００３７】
システムは、ＵＴＲＡＮのリソースが、オペレータが申し出るサービスにアクセスする権利を有するすべての加入者の間で最適に割り振られ／使用されることを保証しなければならない。標準規格は、加入者が、プリエンプション手順に基づいて、ネットワーク・オペレータとの間で結ばれた加入契約のタイプによって定義される彼らの優先順位に応じて別々に扱われなければならないと明示している。
【００３８】
具体的に言うと、プリエンプション手順には、所与のサービスに割り振られるリソースを減らすアルゴリズムと、優先されるものと考えられる要求を満たすのに十分なリソースを入手するアルゴリズムとの使用が含まれる。
【００３９】
しかし、３ＧＰＰ標準規格で与えられるＵＴＲＡＮでのリソース・プリエンプション手順への言及は極端に簡潔で、本質的に、ＵＴＲＡＮが、それに従って、優先順位の昇順で、より低い優先順位を有するＲＡＢのリソースをプリエンプトする機構を使用できるにすぎない、従うべきルールを単純に定義している。しかし、リソースにアクセスするために、別のＲＡＢではなく、あるＲＡＢに優先順位レベルを割り当てるための判断基準は、この標準規格には記載されていない。
【００４０】
したがって、ＵＴＲＡＮ内のリソースへのアクセス優先順位を定義する方法と、ＣＮによって送信され、ＲＡＢパラメータに含まれる優先順位パラメータ（言い換えると、「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」グループのパラメータ）の使用とは、網構築者によって選択された実施態様に依存する。
【００４１】
それでも、プリエンプション概念は、ＵＭＴＳオペレータにとって非常に重要である。なぜなら、このプリエンプション概念が、加入者クラスの管理を制御し、無線リソースへのアクセス手順を定義するからである。さらに、プリエンプションが網上で可能になる瞬間から始まって、どのリソースがどのユーザからどれほどの量だけプリエンプトされるかを定義するための、標準規格に記載されたメカニズムはない。
【非特許文献１】３ＧＰＰ標準規格のパートＴＳ ２５．４１３
【発明の開示】
【発明が解決しようとする課題】
【００４２】
従って、本発明の目的は、リソースをどのようにプリエンプトするか、および、どれほどの量のリソースをプリエンプトするかを選択するのに異なる判断基準を使用する、無線リソースのプリエンプション用の複数判断基準メカニズムを提案し、それにより、ネットワーク・オペレータが網アクセス・リソースの共用、および、割り振りのより柔軟な手順を定義できるようにすることによって、上述した弱点を克服することである。
【課題を解決するための手段】
【００４３】
上記課題を解決するための本発明に係る方法は、移動体通信網内での無線リソースの管理の方法であって、前記リソースが、要求されたサービス品質パラメータの組にそれぞれが関連する複数の通信チャネルに割り振られ、前記方法が、要求されたサービス品質パラメータの組に関連する通信チャネルに関する新しい要求の受入れに続き、前記新しい要求をサポートするのに必要なリソースの欠如の検出に続く、リソース・プリエンプション手順の使用を含み、リソース・プリエンプション手順が、異なる通信チャネル間の順序関係をセットアップするために、予めアクティブな通信チャネルのそれぞれに関連する優先順位レベルの関数として、予めアクティブな通信チャネルへのリソースの割り振りを変調するように設計され、前記プリエンプション手順が、
ａ− プリエンプトできる、網上のアクティブ通信チャネルを識別し、それらの間で、事前定義の選択判断基準に従って最低優先順位の通信チャネルを選択するステップと、
ｂ− 選択された通信チャネルの少なくとも部分的再構成によって得られる無線リソースの増加を評価するステップであって、前記選択された通信チャネルおよび前記関連する増加が、再構成リストに記憶されるステップと、
ｃ− リストに含まれるすべての通信チャネルによって達成される増加が前記新しい要求をサポートするのに十分であるかどうかを検査するステップと、
ｄ− ステップａからｃを、
− 得られる利益が十分になるまで繰り返し、この場合に、リストに含まれる通
信チャネルが再構成され、新しい要求が受け入れられ、または、
− プリエンプトできるすべての通信チャネルが、十分な利益を得ることなく評
価されるまで繰り返し、この場合に、新しい要求が拒否される
ステップと
を含むことを特徴とする方法である。
【００４４】
プリエンプトできる通信チャネルを識別するステップは、関連する優先順位レベルが新しい要求に関連する優先順位レベルより低い伝送サービスを判定することからなることが好ましい。
【００４５】
好ましくは、プリエンプトできる通信チャネルは、少なくとも関連するサービス品質パラメータから記述されるサービス品質が、所定の最低サービス品質よりよい、という条件をも満たす。
【００４６】
最低サービス品質は、最小バイナリ・スループット値に対応し、プリエンプトできる通信チャネルは、スループットに関する関連するサービス品質パラメータが、前記最小の事前定義のスループット値より大きい値を含む、という条件を満たすことが好ましい。
【００４７】
一実施形態によれば、選択された通信チャネルの再構成は、前記通信チャネルに割り振られたすべてのリソースをプリエンプトすることからなる。
【００４８】
別の実施形態によれば、選択された通信チャネルの再構成は、少なくとも関連するサービス品質パラメータから始まる記述されたサービス品質が所定の最低サービス品質に達するように、前記チャネルに割り振られたリソースの一部をプリエンプトすることからなる。
【００４９】
好ましくは、選択された通信チャネルは、その再構成によって得られる増加が構成可能な再構成閾値以上であることをチェックした後に、再構成リストに記憶される。
【００５０】
プリエンプトできる通信チャネルの中の最低優先順位の通信チャネルは、少なくとも、前記通信チャネルのそれぞれに関連する優先順位レベルとスループット・サービス品質パラメータとを考慮に入れて選択されることが好ましい。
【００５１】
好ましくは、プリエンプトできる通信チャネルの中の最低優先順位の通信チャネルは、前記通信チャネルのそれぞれに関連するサービス・タイプに関連する少なくとも１つのサービス品質パラメータも考慮に入れて選択される。
【００５２】
一実施形態によれば、通信チャネルに関連する優先順位レベルは、第１に「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」サービス品質パラメータの値を、第２にサービス・タイプに関連する少なくとも１つのサービス品質パラメータの値を考慮に入れて決定される「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値によって定義される。
【００５３】
対応する通信チャネルの優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値を決定するのに使用されるサービスのタイプに関連するサービス品質パラメータは、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータを含むことが好ましい。
【００５４】
対応する通信チャネルの優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータに割り当てられる値を決定するのに使用されるサービスのタイプに関連するサービス品質パラメータは、対話タイプ・サービスの互いに関する優先順位を定義する「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータも含むことが好ましい。
【００５５】
本発明は、サービス品質パラメータの組にそれぞれが関連する複数の通信チャネルにリソースを割り振る手段を含む移動体通信網内の無線リソース管理デバイスであって、本発明の方法を実施する手段を含むことを特徴とする無線リソース管理デバイスにも関する。
【００５６】
本発明は、データ媒体に保管されたコンピュータ・プログラムであって、本発明の方法の実行を制御するためにソフトウェア命令を含むことを特徴とするコンピュータ・プログラムにも関する。
【００５７】
本発明の他の特性および利点は、添付図面を参照して例示的かつ非限定的な例として与えられる以下の説明を読むことにより明瞭になるであろう。
【発明を実施するための最良の形態】
【００５８】
図３は、ＵＴＲＡＮでの無線リソースの割り振りを管理するプリエンプション手順の使用に関する特定の実施形態を示す。
【００５９】
ＵＭＴＳ網での新しいサービス要求の受入れ（図３では符号１０）時に、コア・ネットワークは、対応する無線リソース割り振り要求を、サービス品質パラメータの組の形でＵＴＲＡＮに送信する。ＵＴＲＡＮ、具体的には無線ネットワーク制御装置ＲＮＣデバイスは、このサービス要求をサポートするのに使用される通信チャネルに必要なリソースを計算することによって、受入れをチェックする。プリエンプション手順は、アクセス網によって管理されるリソースが、このサービス要求をサポートするのに十分でないことをＵＴＲＡＮに置かれた受入れチェック手段によって検出された（ステップ２０）場合に使用される。要求されたリソースが、部分的にまたは完全に使用不能である場合がある。
【００６０】
例えば、リソースの欠如の検出は、下り方向の出力の欠如の検出に基づくものとすることができる。リソースの欠如は、コードの欠如、すなわち、処理能力の欠如を特徴とすることもできる。どの場合でも、リソースの欠如の特徴付けは、網アーキテクチャ、および、機器製造業者に依存する。
【００６１】
「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」パラメータを使用して、プリエンプション手順を実施することができ、このパラメータの値は、関連する通信チャネルが他のあらかじめアクティブな通信チャネルのリソースをプリエンプトできるか否かを示し、「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」パラメータを使用することもでき、このパラメータの値は、関連する通信チャネルのリソースが他の通信チャネルによってプリエンプトされ得るかどうかを示す。
【００６２】
したがって、例えば、プリエンプション手順を使用するためには、それに関する受入れがリソース問題を生じるチャネルの「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」パラメータの値が、対応するチャネルが他の通信チャネルをプリエンプトできることを示さなければならない。その場合に、プリエンプト手順をトリガして、優先順位の関数として予めアクティブな通信チャネルへの無線リソースの割り振りを減らすことにより、新しいチャネル要求を受け入れることができることになる。
【００６３】
これを達成するために、ステップ３０を使用して、プリエンプトできる、網上でアクティブな通信チャネルを識別する。この例によれば、この識別ステップは、第１に、関連する「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」パラメータがプリエンプションに対する脆弱性を示し、第２に、関連する優先順位レベルが、その受入れがリソース問題を生じるチャネルに関連する優先順位レベルより低い、アクティブ通信チャネルを判定することからなるものとすることができる。
【００６４】
しかし、「Ｐｒｅｅｍｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ」パラメータおよび「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」パラメータを使用することは、この方法を使用する上で、任意に選択し得ることであることに留意されたい。
【００６５】
本明細書で言及する、各チャネル要求に関連する優先順位レベルは、異なる通信チャネル間の順序関係をセット・アップすることを可能にするが、例えば、サービス・タイプに関連する少なくとも１つのサービス品質パラメータ、すなわち、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータおよび「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータの値、または標準の「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値によって定義することができる。
【００６６】
１つの変形で、通信チャネルごとに優先順位レベルを定義するのに使用される「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータの「Ｐｒｉｏｒｉｔｙ ｌｅｖｅｌ」パラメータの値は、第１にコア・ネットワークの「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータの値、第２にサービス・タイプに関連する少なくとも１つのパラメータの値を考慮に入れることによって決定することができる。第１実施形態では、サービス・タイプに関連する、各通信チャネルに関連する優先順位レベルを定義するために「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」サブパラメータに割り当てられる値を決定するのに使用されるサービス品質パラメータに、４つの値のうちの１つと等しいものとすることができる「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータが含まれる。第２実施形態では、使用されるサービス・タイプに関連するサービス品質パラメータに、３つの値のうちの１つと等しいものとすることができ、優先順位をセットするのに使用できる、言い換えれば、対話タイプ・サービス（言い換えれば、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータの値が「Ｉｎｔｅｒａｃｔｉｖｅ」と等しいサービス）を優先順位レベルによる順序にするのに使用できる、「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータも含まれる。
【００６７】
この方法で、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの１２個までの値、したがって１２個までの優先順位レベルを、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」サービス品質パラメータおよびコア・ネットワークの「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」サービス品質パラメータを使用して、異なる通信チャネルについて定義することができる。
【００６８】
さらに、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの１８個までの値、したがって１８個までの優先順位レベルを、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータ、コア・ネットワークの「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータ、および「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータを使用して、異なる通信チャネルについて定義することができる。
【００６９】
１つの好ましい実施形態によれば、本発明の使用されるプリエンプション手順は、リソースをプリエンプトされる加入者が、最低サービス品質を維持することを保証するであろう。この最低サービス品質は、サービス品質プロファイルのすべてまたは一部を含む、所与の通信チャネル要求に固有のＵＴＲＡＮの既知のパラメータから定義される。
【００７０】
また、この好ましい実施形態によれば、プリエンプトできる、網上のアクティブ通信チャネルを識別する（ステップ３０）ために、これらのチャネルが、少なくとも１つの関連するサービス品質パラメータを使用して記述されたサービス品質が、最低の要求されたサービス品質よりよいことをチェックすることも必要である。したがって、最低サービス品質を定義することによって、オペレータが一部のサービス品質パラメータを他のサービス品質パラメータより優先することを可能にすることができる。
【００７１】
一例によれば、最低サービス品質は、ダウンリンク上の最小バイナリ・スループット値に対応する。したがって、所与の通信チャネルに関連するサービス品質は、割り振られたダウンリンク上のバイナリ・スループットに関して理解され、そのダウンリンク上の最小スループットと比較される。これは、接続がセットアップされる時に要求される「Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｄｏｗｎｌｉｎｋ」パラメータを使用して行われる。したがって、プリエンプトできるアクティブ通信チャネルは、それに関連するサービス品質パラメータ「Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｄｏｗｎｌｉｎｋ」値が、要求されたサービス品質値より大きいことを検証する必要がある。
【００７２】
要求されたサービス品質値は、「Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｕｐｌｉｎｋ」スループット・サービス品質パラメータ、「Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｆｏｒ Ｄｏｗｎｌｉｎｋ」スループット・サービス品質パラメータ、および「Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ Ｆｏｒ Ｕｐｌｉｎｋ」スループット・サービス品質パラメータを使用して記述することもできる。
【００７３】
ステップ３０においてプリエンプトできる少なくとも１つの通信チャネルが識別された場合に、ステップ４０が使用される。このステップ４０は、事前に定義された選択判断基準に従って、プリエンプト可能であると識別された通信チャネルの中で、最低優先順位の通信チャネルを選択することからなる。
【００７４】
例えば、第１ステップは、標準の「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値の昇順で通信チャネルを選択することである。同一優先順位レベルを有する通信チャネルから構成されるサブグループ内で実行される第１ステップは、トラフィック・クラスが「Ｂａｃｋｇｒｏｕｎｄ」タイプである通信チャネルを選択し、次に、トラフィック・クラスが「Ｉｎｔｅｒａｃｔｉｖｅ」タイプである通信チャネルを選択することである。
【００７５】
各通信チャネルの優先順位レベルを定義するのに使用される「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータが、第１にコア・ネットワークによって送信された「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」パラメータの値、第２にサービス・タイプに関連する少なくとも１つのサービス品質パラメータの値を考慮に入れて決定される、上述した変形例によれば、プリエンプト可能であると識別された通信チャネルの中で最低優先順位の通信チャネルは、単純に、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値の昇順で通信チャネルを選択することによって選択される。
【００７６】
次に、同一優先順位レベルを有する通信チャネルによって形成されるサブグループ内で、通信チャネルを、例えば、最低サービス品質を保証するための所定の最小バイナリ・スループットに対する、割り振られたダウンリンク上のバイナリ・スループットの比の昇順で選択することができる。
【００７７】
プリエンプト可能であると識別された通信チャネルの中で最低優先順位の通信チャネルを選択した後に、ステップ５０が、この通信チャネルを再構成する場合に得られるリソースの増加を評価するために適用される。このステップ５０は、この通信チャネルに割り振られたリソースが、最低の所定のサービス品質、すなわち、この例では、固定ダウンリンク上の最小バイナリ・スループットに達するようにプリエンプトされた場合に得られるであろう増加を推定することからなる。
【００７８】
上記得られるリソースの増加は、ステップ６０で、パラメータによって定義される再構成可能閾値と比較されることが好ましい。それ未満では得られる増加が十分ではないと考えられる構成可能閾値を定義することができる。その場合に、リソースは、この通信チャネル上ではプリエンプトされない。そのような閾値を定義することの目的は、通信チャネル再構成の回数を制限することである。
【００７９】
１つの例の実施形態では、例えば下り方向の総出力の増加を特徴とする、得られるリソースの増加が、新しいサービス要求に対応する新しい通信チャネルを受け入れるために必要な出力の１０％の構成可能閾値未満である場合に、選択された通信チャネルは、プリエンプト不可能であると見なされ、この手順は、ステップ３０に戻って再開される。そうでない場合には、選択された通信チャネルは、プリエンプト可能であると考えられ、再構成される通信チャネルを含む再構成リストに、この通信チャネルに関連する評価された増加と共に含められる。
【００８０】
次に、ステップ７０は、プリエンプションに関する再構成リストに含まれるすべての通信チャネルから得られる増加が、要求された通信チャネルのリソース要求にサービスするのに十分なリソースを解放するか否かを検証することからなる。
【００８１】
ステップ３０から７０は、得られる増加が十分になるまで繰り返され、得られる増加が十分になる場合に、ステップ８０が実施され、このステップ８０では、再構成リストに含まれる通信チャネルが、新しい通信チャネルを受け入れるのに必要なリソースを効果的に回復するために再構成され、その後、この手順は終了する。
【００８２】
もう１つの事例が発生する可能性があり、この事例では、ステップ３０から７０が、プリエンプト可能であると識別されたすべての通信チャネルが最低ＱｏＳを有するリソースの増加に関して評価されるまで繰り返されるが、リソースの必要な増加が得られない。
【００８３】
最低サービス品質未満のランクを有するすべての通信チャネルを再構成した後に得られる増加が十分でない場合に、この手順には、プリエンプトできるすべての通信チャネルのすべてのリソースをプリエンプトする手段が含まれる。
【００８４】
したがって、より低いランクを有するすべての識別された通信チャネルが、十分な増加を得ることなく最低サービス品質で評価された時に、最低サービス品質を尊重する条件をまったく伴わずに、プリエンプトできるすべての通信チャネルを識別することからなるステップ３５が、実施される。したがって、これには、第１に、関連する「Ｐｒｅｅｍｐｔｉｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ」ＲＡＢパラメータがプリエンプションに対する脆弱性を示し、第２に、関連する優先順位レベルが新しいチャネル要求に関連する優先順位レベルより低い、通信チャネルが含まれる。
【００８５】
上でステップ３０から７０を参照して説明したループが、ステップ５０がステップ５５に置換されることを除いて、ステップ３５でプリエンプト可能であると識別された通信チャネル上でもう一度使用され、ステップ５５は、ある選択された通信チャネルに割り振られたリソースが完全にプリエンプトされた場合に、その通信チャネルについて得られるリソースの増加を推定することからなる。同様に、この手順は、再構成リストに含まれるすべての通信チャネルから得られる増加が十分になるまでループする。
【００８６】
しかし、プリエンプトできるすべての識別された通信チャネルが、この第２ループで完全プリエンプションで評価され、得られる増加が、新しいサービス要求をサポートするのに依然として十分でない場合には、このサービス要求は、ステップ９０に示されているように拒否され、この手順は終了する。
【００８７】
このプリエンプト手順を、おそらくはプリエンプションの対象であると識別された通信チャネルに基づいて使用し、尊重されるべき最低サービス品質を用いる第１フェーズを実行せずに、完全プリエンプションを用いて直接に評価することもできる。
【００８８】
ＵＴＲＡＮは、ＲＮＣ無線ネットワーク・コントローラ・デバイス内で本発明による方法の異なるステップを実行するように配置されたデータ処理手段を含まなければならない。より正確には、上述した方法のステップは、ソフトウェア命令の制御の下で、データ処理デバイス、実際には無線ネットワーク・コントローラ・デバイスによって実行される。その結果、本発明は、コンピュータ・デバイスによるこの方法の実行を制御するためにソフトウェア命令を含むデータ媒体に保管できるか、またはこのデータ媒体によって伝送できるコンピュータ・プログラムにも関する。このデータ媒体は、ハードウェア記憶媒体、例えばＣＤ−ＲＯＭ、磁気ディスケット、またはハード・ディスクとするか、あるいは電気信号、光信号、または無線信号などの伝送可能媒体とすることができる。
【００８９】
上に説明した実施形態は、ＵＭＴＳ網に関するものであるが、本発明は、ＧＰＲＳ網およびすべての類似するタイプの移動体通信網に適用可能であることは明らかである。
【００９０】
＜用語集＞
この用語集は、本特許出願で使用される頭字語のリストである。これらの頭字語のほとんどは、３ＧＰＰ遠距離通信標準規格の枠組で定義されている。
３ＧＰＰ： Ｔｈｉｒｄ−Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏ
ｊｅｃｔ（ＥＴＳＩの）
ＧＳＭ： Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉ
ｃａｔｉｏｎｓ
ＵＭＴＳ： Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉ
ｏｎｓ Ｓｙｓｔｅｍ
ＩＰ： Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ
ＢＳＣ： Ｂａｓｅ Ｓｔａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ
ＨＬＲ： Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ
ＳＧＳＮ： Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ
ＧＧＳＮ： Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ
ＵＴＲＡＮ： ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅ
ｔｗｏｒｋ
ＲＮＣ： Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ
ＱｏＳ： Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ
ＦＴＰ： Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ
ＡＲＰ： Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ
ＰＤＰ： Ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ
ＴＨＰ： Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ
ＲＡＢ： Ｒａｄｉｏ Ａｃｃｅｓｓ Ｂｅａｒｅｒ
【図面の簡単な説明】
【００９１】
【図１】ＵＭＴＳタイプ網のアーキテクチャを示す図である。
【図２】パケット・ドメインのＰＤＰコンテキストをアクティブ化する手順を示す図である。
【図３】本発明の方法の使用に関する特定の実施形態を示す流れ図である。
【特許請求の範囲】
【請求項１】
移動体通信網内で無線リソースを管理する方法であって、前記リソースは、要求されたサービス品質パラメータの組にそれぞれが関連する複数の通信チャネルに割り振られ、前記方法は、要求されたサービス品質パラメータの組に関連する通信チャネルに関する新しい要求の受入れ（１０）に続き、前記新しい要求をサポートするのに必要なリソースの欠如の検出（２０）に続く、リソース・プリエンプション手順の使用を含み、前記リソース・プリエンプション手順は、異なる通信チャネル間の順序関係をセット・アップするために、予めアクティブな通信チャネルのそれぞれに関連する優先順位レベルの関数として前記予めアクティブな通信チャネルへのリソースの割り振りを変調するように設計され、前記プリエンプション手順は、
ａ− プリエンプトできる、前記網上のアクティブ通信チャネルを識別し、それらの間で、事前に定義された選択判断基準に従って最低優先順位の通信チャネルを選択するステップ（３０、３５）と、
ｂ− 前記選択された通信チャネルの少なくとも部分的再構成によって得られる無線リソースの増加を評価するステップ（５０、５５）であって、前記選択された通信チャネルおよび前記関連する増加が、再構成リストに記憶されるステップ（５０、５５）と、
ｃ− 前記リストに含まれるすべての通信チャネルによって達成される前記増加が前記新しい要求をサポートするのに十分であるかどうかを検査するステップ（７０）と、
ｄ− ステップａからｃを、
− 前記得られる利益が十分になるまで繰り返し、この場合に、前記リストに含
まれる前記通信チャネルが再構成され、前記新しい要求が受け入れられ（８
０）、または、
− プリエンプトできるすべての通信チャネルが、十分な利益を得ることなく評
価されるまで繰り返し、この場合に、前記新しい要求が拒否される（９０）
ステップと
を含むことを特徴とする方法。
【請求項２】
プリエンプトできる通信チャネルを識別する前記ステップは、前記関連する優先順位レベルが前記新しい要求に関連する優先順位レベルより低い伝送サービスを判定することからなることを特徴とする、請求項１に記載の方法。
【請求項３】
プリエンプトできる前記通信チャネルは、少なくとも関連するサービス品質パラメータから記述されるサービス品質が、所定の最低サービス品質よりよい、という条件も満たすことを特徴とする、請求項２に記載の方法。
【請求項４】
前記最低サービス品質は、最小バイナリ・スループット値に対応し、プリエンプトできる前記通信チャネルは、スループットに関する関連するサービス品質パラメータが、前記最小の事前に定義されたスループット値より大きい値を含む、という条件を満たすことを特徴とする、請求項３に記載の方法。
【請求項５】
前記選択された通信チャネルの再構成は、前記通信チャネルに割り振られたすべてのリソースをプリエンプトすることからなることを特徴とする、請求項１または２に記載の方法。
【請求項６】
前記選択された通信チャネルの再構成は、少なくとも前記関連するサービス品質パラメータから記述されたサービス品質が前記所定の最低サービス品質に達するように、前記チャネルに割り振られた前記リソースの一部をプリエンプトすることからなることを特徴とする、請求項３または４に記載の方法。
【請求項７】
前記選択された通信チャネルは、その再構成によって得られる前記増加が構成可能な再構成閾値以上であることをチェック（６０）した後に、前記再構成リストに記憶されることを特徴とする、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
プリエンプトできる前記通信チャネルの中の前記最低優先順位の通信チャネルは、少なくとも、前記通信チャネルのそれぞれに関連する前記優先順位レベルとスループット・サービス品質パラメータとを考慮に入れて選択されることを特徴とする、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
プリエンプトできる前記通信チャネルの中の前記最低優先順位の通信チャネルは、前記通信チャネルのそれぞれに関連するサービス・タイプに関連する少なくとも１つのサービス品質パラメータをも考慮に入れて選択されることを特徴とする、請求項８に記載の方法。
【請求項１０】
通信チャネルに関連する前記優先順位レベルは、第１に「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」サービス品質パラメータの値を、第２にサービス・タイプに関連する少なくとも１つのサービス品質パラメータの値を考慮に入れて決定される、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値によって定義されることを特徴とする、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
対応する通信チャネルの前記優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの前記値を決定するのに使用されるサービスのタイプに関連する前記サービス品質パラメータは、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータを含むことを特徴とする、請求項１０に記載の方法。
【請求項１２】
対応する通信チャネルの前記優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータに割り当てられる前記値を決定するのに使用されるサービスのタイプに関連する前記サービス品質パラメータは、対話タイプ・サービスの互いに関する優先順位を定義する「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータをも含むことを特徴とする、請求項１１に記載の方法。
【請求項１３】
サービス品質パラメータの組にそれぞれが関連する複数の通信チャネルにリソースを割り振る手段を含む移動体通信網内の無線リソース管理デバイスであって、請求項１乃至１２のいずれか一項に記載の方法を実施する手段を含むことを特徴とする、無線リソース管理デバイス。
【請求項１４】
データ媒体に保管されたコンピュータ・プログラムであって、請求項１乃至１２のいずれか一項に記載の方法の実行を制御するためにソフトウェア命令を含むことを特徴とするコンピュータ・プログラム。
【請求項１】
移動体通信網内で無線リソースを管理する方法であって、前記リソースは、要求されたサービス品質パラメータの組にそれぞれが関連する複数の通信チャネルに割り振られ、前記方法は、要求されたサービス品質パラメータの組に関連する通信チャネルに関する新しい要求の受入れ（１０）に続き、前記新しい要求をサポートするのに必要なリソースの欠如の検出（２０）に続く、リソース・プリエンプション手順の使用を含み、前記リソース・プリエンプション手順は、異なる通信チャネル間の順序関係をセット・アップするために、予めアクティブな通信チャネルのそれぞれに関連する優先順位レベルの関数として前記予めアクティブな通信チャネルへのリソースの割り振りを変調するように設計され、前記プリエンプション手順は、
ａ− プリエンプトできる、前記網上のアクティブ通信チャネルを識別し、それらの間で、事前に定義された選択判断基準に従って最低優先順位の通信チャネルを選択するステップ（３０、３５）と、
ｂ− 前記選択された通信チャネルの少なくとも部分的再構成によって得られる無線リソースの増加を評価するステップ（５０、５５）であって、前記選択された通信チャネルおよび前記関連する増加が、再構成リストに記憶されるステップ（５０、５５）と、
ｃ− 前記リストに含まれるすべての通信チャネルによって達成される前記増加が前記新しい要求をサポートするのに十分であるかどうかを検査するステップ（７０）と、
ｄ− ステップａからｃを、
− 前記得られる利益が十分になるまで繰り返し、この場合に、前記リストに含
まれる前記通信チャネルが再構成され、前記新しい要求が受け入れられ（８
０）、または、
− プリエンプトできるすべての通信チャネルが、十分な利益を得ることなく評
価されるまで繰り返し、この場合に、前記新しい要求が拒否される（９０）
ステップと
を含むことを特徴とする方法。
【請求項２】
プリエンプトできる通信チャネルを識別する前記ステップは、前記関連する優先順位レベルが前記新しい要求に関連する優先順位レベルより低い伝送サービスを判定することからなることを特徴とする、請求項１に記載の方法。
【請求項３】
プリエンプトできる前記通信チャネルは、少なくとも関連するサービス品質パラメータから記述されるサービス品質が、所定の最低サービス品質よりよい、という条件も満たすことを特徴とする、請求項２に記載の方法。
【請求項４】
前記最低サービス品質は、最小バイナリ・スループット値に対応し、プリエンプトできる前記通信チャネルは、スループットに関する関連するサービス品質パラメータが、前記最小の事前に定義されたスループット値より大きい値を含む、という条件を満たすことを特徴とする、請求項３に記載の方法。
【請求項５】
前記選択された通信チャネルの再構成は、前記通信チャネルに割り振られたすべてのリソースをプリエンプトすることからなることを特徴とする、請求項１または２に記載の方法。
【請求項６】
前記選択された通信チャネルの再構成は、少なくとも前記関連するサービス品質パラメータから記述されたサービス品質が前記所定の最低サービス品質に達するように、前記チャネルに割り振られた前記リソースの一部をプリエンプトすることからなることを特徴とする、請求項３または４に記載の方法。
【請求項７】
前記選択された通信チャネルは、その再構成によって得られる前記増加が構成可能な再構成閾値以上であることをチェック（６０）した後に、前記再構成リストに記憶されることを特徴とする、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
プリエンプトできる前記通信チャネルの中の前記最低優先順位の通信チャネルは、少なくとも、前記通信チャネルのそれぞれに関連する前記優先順位レベルとスループット・サービス品質パラメータとを考慮に入れて選択されることを特徴とする、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
プリエンプトできる前記通信チャネルの中の前記最低優先順位の通信チャネルは、前記通信チャネルのそれぞれに関連するサービス・タイプに関連する少なくとも１つのサービス品質パラメータをも考慮に入れて選択されることを特徴とする、請求項８に記載の方法。
【請求項１０】
通信チャネルに関連する前記優先順位レベルは、第１に「Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ」サービス品質パラメータの値を、第２にサービス・タイプに関連する少なくとも１つのサービス品質パラメータの値を考慮に入れて決定される、「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの値によって定義されることを特徴とする、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
対応する通信チャネルの前記優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータの前記値を決定するのに使用されるサービスのタイプに関連する前記サービス品質パラメータは、「Ｔｒａｆｆｉｃ Ｃｌａｓｓ」パラメータを含むことを特徴とする、請求項１０に記載の方法。
【請求項１２】
対応する通信チャネルの前記優先順位レベルを定義する「Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ」パラメータに割り当てられる前記値を決定するのに使用されるサービスのタイプに関連する前記サービス品質パラメータは、対話タイプ・サービスの互いに関する優先順位を定義する「Ｔｒａｆｆｉｃ Ｈａｎｄｌｉｎｇ Ｐｒｉｏｒｉｔｙ」パラメータをも含むことを特徴とする、請求項１１に記載の方法。
【請求項１３】
サービス品質パラメータの組にそれぞれが関連する複数の通信チャネルにリソースを割り振る手段を含む移動体通信網内の無線リソース管理デバイスであって、請求項１乃至１２のいずれか一項に記載の方法を実施する手段を含むことを特徴とする、無線リソース管理デバイス。
【請求項１４】
データ媒体に保管されたコンピュータ・プログラムであって、請求項１乃至１２のいずれか一項に記載の方法の実行を制御するためにソフトウェア命令を含むことを特徴とするコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００８−５１４０７４（Ｐ２００８−５１４０７４Ａ）
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願番号】特願２００７−５３１７９２（Ｐ２００７−５３１７９２）
【出願日】平成１７年９月１２日（２００５．９．１２）
【国際出願番号】ＰＣＴ／ＦＲ２００５／００２２５７
【国際公開番号】ＷＯ２００６／０３２７４９
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願日】平成１７年９月１２日（２００５．９．１２）
【国際出願番号】ＰＣＴ／ＦＲ２００５／００２２５７
【国際公開番号】ＷＯ２００６／０３２７４９
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
[ Back to top ]