JP2012506167A - セルラ陸上移動システムにおいて過負荷の場合に解放されるべきリソースを選択するための方法 - Google Patents

Abstract

過負荷の場合に、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、より高い優先度のアプリケーションに利用できるようにすることができ、かつ、複数のアプリケーションによって同時にリソースを使用可能にすることができるセルラ陸上移動ネットワークを操作するための方法および陸上移動システムであって、解放されるべきリソースの選択を行い、考慮対象のすべてのリソースに関して効率係数を求め、最小の効率係数を有するリソースを解放する方法および陸上移動システム。

Description

本発明は、過負荷の場合に、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、より高い優先度のアプリケーションに利用できるようにし、かつ、複数のアプリケーションによって同時にリソースを使用可能にすることができるセルラ陸上移動ネットワークを操作するための方法に関する。

すなわち、本発明は、例えばＧＥＲＡＮ、ＵＴＲＡＮ、Ｅ−ＵＴＲＡＮ、ｃｄｍａ２０００、ＵＭＢ、ＷｉＭＡＸなどの規格に従ったセルラ陸上移動システムにおいて、より高い優先度のコールを使用可能にするために解放しなければならない、占有されているネットワークリソースを選択するための方法に関する。これらのシナリオは、通常は過負荷の状況で生じる。

利用可能な空きネットワークリソースが、より高い優先度の新規のコールを使用可能にするのにもはや十分でないとき、占有されているネットワークリソースを常に解放しなければならない。より高い優先度のコールは、例えばボイスコールまたはストリーミングコールであり、これらは通常、リアルタイムアプリケーションまたはリアルタイムサービスと呼ばれる。リアルタイムサービスとは対照的に、より低い優先度のコールは、非リアルタイムサービスと呼ばれる。非リアルタイムサービスには、特に、インターネット閲覧または電子メールの送受信などのアプリケーションが含まれる。

解放されるべきリソースを選択するための従来技術は、一人のユーザによって占有されているリソースのみを考慮するものである。しかし、現在の陸上移動システムでは、リソースは、複数のアプリケーションまたはユーザによって同時にも使用される（いわゆる共有リソース）。共有リソースの顕著な例は、ＨＳＤＰＡチャネルに使用されるノードＢのベースバンドリソースである。ノードＢベースバンドでのＨＳＤＰＡは、最大ＨＳＤＰＡ帯域幅に従って特定のリソースを占有する。帯域幅を共有しているユーザの数は、占有されるリソースよって決まる。

本発明の目的は、前述した欠点を克服する冒頭に述べた種類の方法を開発すること、および特に、共有リソースも考慮する、解放されるべきリソースを選択するための選択アルゴリズムを定義することである。

本発明で特許請求されるように、この目的は、請求項１に記載の方法および請求項５に記載の陸上移動システムによって実現される。本発明の有利な発展形態は、従属請求項に記載される。

過負荷の場合に、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、より高い優先度のアプリケーションに利用できるようにしなければならず、かつ、複数のアプリケーションによって同時にリソースを使用可能にすることができるセルラ陸上移動ネットワークを操作するための、本発明における特許請求される方法では、考慮対象のすべてのリソースに関して効率係数を求め、最小の効率係数を有するリソースを解放することによって、解放されるべきリソースの選択を行うことが有利である。

過負荷の場合に、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、より高い優先度のアプリケーションに利用できるようにすることができ、かつ、複数のアプリケーションによって同時にリソースを使用可能にすることができるセルラ陸上移動ネットワークを備える、本発明で特許請求される陸上移動システムでは、陸上移動システムが制御ユニットを有し、制御ユニットが、考慮対象のすべてのリソースに関して効率係数を求め、最小の効率係数を有するリソースを解放することによって、解放されるべきリソースを選択するように設定されることが特に有利である。

概念「リソース」は、例えば送信局ベースバンド処理容量、空気インターフェース容量、ライン容量など、陸上移動ネットワークにおける考えられる任意のリソースに関するものであることがある。したがって、概念「リソース」は、陸上移動ネットワークまたは陸上移動システムのいかなるネットワークインフラストラクチャまたは容量をも包含する。

本発明における特許請求される方法では、ネットワークインフラストラクチャの幾つかの部分（或る部分）またはリソースを解放して、それらをより高い優先度のアプリケーションおよび／またはコールに利用できるようにするにし、パラメータを使用してあらかじめ求められた効率係数に応じてリソースの解放を行うことによって、知覚できる介入または知覚できる解放の結果を最小限にする。

したがって、本発明の基本的な着想は、影響を受けるアプリケーションまたは加入者の数を最小にすると同時に解放されるべきリソースのサイズを最大にして、リソースを解放することである。

影響を受けるアプリケーションまたは加入者の数を減少させることによって、顧客に対する影響が低減される。リソースサイズを最大にすることによって、リソースの解放の数が減少される。これは、解放プロセスによって空きリソースを最大にし、それにより空きリソースを将来の新規のコールセットアップに利用できるようにすることによって実現される。

複数のユーザが同時にリソースを使用することができるセルラ陸上移動システムにおいて過負荷の場合に解放されるべきリソースを選択するための本発明で特許請求される方法では、リソースが一人の加入者によって使用されているか複数の加入者によって使用されているかに関わらず、考慮対象のすべてのリソースに関して効率係数が計算され、最小の効率係数を有するリソースが解放される。

概念「解放」は、特に、例えば陸上移動ネットワークの送信手段への既存のワイヤレス接続を中断および終了することによって現在のアプリケーションを終了することを意味し、それにより、リソース、したがって例えば任意のタイプのワイヤレスチャネルまたはネットワークインフラストラクチャを、より高い優先度を有する別のアプリケーションおよびより高い格付けのアプリケーションに利用できるようになり、接続は、前に解放されたネットワークインフラストラクチャを使用して設定することができる。

したがって、解放は、接続解除、切断、クリア、中断、すなわち接続のクリア、切り離しなどを意味し、すなわち選択されたリソースを他のアプリケーションや通信リンクなどに使用できるようになることを意味する。

本発明で特許請求される方法およびシステムでは、特に以下の要件が満たされると特に有利である。
−負荷状況の場合に、より高い優先度のコールまたはアプリケーションが、実行中のより低い優先度のコールまたはアプリケーションを解放させる。
−選択アルゴリズムが、共有リソースおよび非共有リソースを考慮する。
−選択アルゴリズムが、トランスポートチャネルのタイプ（例えばＨＳＤＰＡ、ＨＳＵＰＡなど）を考慮しない。
−占有されているリソースの解放は、現在のアプリケーションに、したがって顧客に影響を及ぼすことを意味する。したがって、選択アルゴリズムは、アプリケーションおよび顧客に対する影響を低減するように設計される。
−リソースの解放は、時間制約が厳しいので複雑なプロセスである。したがって、選択アルゴリズムは、リソース解放の数を最小にすべきである。
−選択アルゴリズムは、すべてタイプのより高い優先度のコールおよび／またはアプリケーション（例えばボイスコールまたはストリーミングアプリケーション）に適用可能であるように意図される。

本明細書で特許請求される選択アルゴリズムは、特に以下の入力基準を使用する。
−コール優先度
この基準は、最も優先度の低いコールが最初に解放のターゲットとして選択されることを保証する。
−解放の対象となり得るリソースを現在使用している、影響を受ける加入者の数
この基準は、顧客に対する影響を最小限にすることを保証する。
−解放されるべきリソースのサイズ
この基準は、解放の数を最小にすることを保証する。

好ましくは、アプリケーションの絶対数が最大になるように、ネットワークリソースの効率係数が、リソースを現在使用しているアプリケーションの数に依存して、特にアプリケーションの数をリソースの容量で割った商として計算される。

これは、アプリケーション、すなわちユーザに関してシステム容量が最大になるように、解放されることになるユーザまたはアプリケーションの数とこれらのユーザまたはアプリケーションによって占有されているリソースとに基づく効率係数が計算されることを意味する。

１つの代替構成では、絶対データ転送率が最大になるように、効率係数が、リソースを現在使用しているアプリケーションのデータ転送率に依存して、特にアプリケーションのデータ転送率をリソースの容量で割った商として計算される。

これは、データ転送率に関してシステム容量が最大になるように、解放されることになるアプリケーションまたはユーザの現在のデータ転送率とこれらのアプリケーションまたはユーザによって占有されているリソースとに基づく効率係数が計算されることを意味する。

１つの好ましい構成では、リソースを現在使用しているアプリケーションの優先度が考慮され、特に、現在使用中のアプリケーションが最も優先度の低いアプリケーションであるリソースについてのみ、効率係数の計算が行われ、任意選択で解放が行われる。すなわち、特に追加の情報として、解放されることになるアプリケーションまたは加入者の優先度が考慮され、最も優先度の低いアプリケーションまたは加入者に関してのみ効率係数が計算される。

提案されるアルゴリズムは、詳細には以下のようなものである。過負荷時の新規のコールを、空きリソースが不十分であるためにセットアップできない場合、新規のコールを実施するのに十分な、現在占有されている各候補のリソースに関して、効率係数が計算される。さらに、現在最も優先度の低い瞬時コールが割り当てられているリソースのみが考慮される。最小の効率係数を有するリソースが選択されて解放される。

送信局ベースバンド処理容量の例を用いると、効率係数は、以下のように定義される。ここで、ＣＥ（チャネル要素）は、送信局ベースバンド処理容量の尺度である。

ｉは、解放することができるリソースブロックの番号である。したがって、リソース「ｉ」の効率係数は、それぞれのリソース「ｉ」をその瞬間に使用しているアプリケーションまたはユーザの数を、リソース「ｉ」で利用可能な容量をそれぞれＣＥ（チャネル要素）単位で表した量で割った商に等しい。

送信局ベースバンド処理容量の例に関して、ＡＭＲコールに関するリソース効率は１である。１人の加入者が１ＣＥのみを使用する。例えばＨＳＤＰＡなどの共有リソースに関しては、複数の加入者が１つのリソースブロックを使用している（例えば３人の加入者が３０ＣＥを使用している→リソース効率＝１０％；または１人の加入者が３０ＣＥを使用している→リソース効率＝３．３％）。

選択アルゴリズムは、アプリケーションまたは加入者が使用しているリソースのすべてのリソース効率係数を最小リソースのために比較し、最小値を有するリソースを、解放のためのターゲットとして選択する。

リソース効率係数の計算例を示す。 プロセスステップＡ〜Ｆを有する選択アルゴリズムの一実施形態の流れ図および概略を示す

リソース効率係数は、新たなコールのために使用することができるすべてのリソースブロックに関して計算される。新たなコールが例えば１０ＣＥの容量を必要とする場合、効率係数は、１０ＣＥのすべてのリソースブロックに関して計算される。あるいは、空きリソースが既に利用可能である場合、効率係数は、さらに必要なリソースに関して計算される。

そのような一例が図１に示される。１０ＣＥのワイヤレスチャネル要素容量を必要とする優先度の高いコールを設定するものとする。図１は、現在のノードＢのリソース占有を概略的に示す。

リソース効率［１］、［２］、および［３］のみを計算すればよい。なぜなら、これらのリソースブロックのみが、１０ＣＥを必要とする新たなコールに十分なリソースを利用可能にするからである。

上述したアルゴリズムの１つの起こり得る欠点は、１つのステップで解放される、影響を受けるアプリケーションまたは加入者の数が最小でないことである。しかし、解放の数が最小にされるので、その後の解放は回避され、したがって、影響を受けるアプリケーションおよび顧客の数は最小になる。

図２は、プロセスステップＡ〜Ｆを有する選択アルゴリズムの一実施形態の流れ図および概略を示す。

第１のステップＡでは、より高い優先度のアプリケーションに現在必要とされるリソースが求められ、必要なリソースから現在の空きリソースの量または容量を引くことによって、解放されるべきリソースの質または容量がそこから計算される。

第２のステップＢで、現在占有されているリソースが、それらの優先度に従ってグループ化される。

第３のステップＣで、最も優先度の低いリソースが、解放のためのターゲットとして選択される。最も優先度の低いリソースが、現在必要とされるリソースの量を提供するには十分でない場合、その次に低い優先度のリソースが、解放のターゲットとしてさらに選択される。

第４のステップＤで、ステップＣで決定された解放することができるリソースのリストから、より高い優先度のアプリケーションに必要なリソースの量に届く可能なグループが形成される。

ステップＥで、ステップＣで決定された各リソースグループごとに、それぞれの効率係数の形態での個々の効率が計算される。

最後のプロセスステップＦにおいて、最小の効率係数を有するリソースが選択される。それに従って、このリソースが、解放のために選択される。

上述したアルゴリズムは、瞬時のアプリケーションまたはユーザの数に関して、リソース効率を最大にする。すなわち、システム内でのユーザの数が最大になる。アプリケーション／ユーザの数ではなくアルゴリズムの適合によってシステム容量を最大にすることもできる。この用例に関しては、アプリケーションまたはユーザの数ではなく、ユーザデータ転送率が考慮される。

或るリソースを使用しているユーザが生み出すデータ転送率が、占有されているリソースと関連づけられる。

この方法では、リソース「ｉ」の効率は、データ転送率に依存し、すなわち、リソースｉを瞬時に使用しているすべてのｎ個のアプリケーションのデータスループットの和を、割り当てられるまたは使用されるワイヤレスネットワーク要素と要素当たりの容量との積で割った商に対応する。

実施例１
送信局が空き容量を有さず、すなわち空きＣＥがない。
１ＣＥを有するＡＭＲコールを新たにセットアップするものとする。
既存のコール：
［１］ｌｘｌ６ｋｂｐｓ Ｒｅ１９９（１ＣＥ）
［２］ｌｘ３８４ Ｒｅ１９９（１２ＣＥ）
［３］１ ＨＳＵＰＡ加入者（３０ＣＥ）

１ＣＥを空けなければならない。１ＣＥに関するリソース効率を計算しなければならない。
リソース効率［１］１６ｋｂｐｓ Ｒ９９＝１
リソース効率［２］３８４ｋｂｐｓ Ｒ９９＝１／１２＝８．３％
リソース効率［３］ＨＳＵＰＡ＝１／３０＝３．３３％
→リソース［３］ＨＳＵＰＡのリソースが解放される。

実施例２
ノードＢに空きＣＥが２だけある。
４ＣＥを有するストリーミングコールをセットアップするものとする。
既存のコール：
［１］１×１６ｋｂｐｓ Ｒｅ１９９（４ＣＥ）
［２］１×３８４ Ｒｅ１９９（１２ＣＥ）
［３］１ ＨＳＵＰＡ加入者（３０ＣＥ）

２ＣＥを解放しなければならない。２ＣＥに関するリソース効率を計算しなければならない。
リソース効率［１］２×１６ｋｂｐｓ＝２／２＝１
リソース効率［２］３８４ｋｂｐｓ＝１／１２＝８．３％
リソース効率［３］ＨＳＵＰＡ＝３／３０＝１０％
→リソース［２］３８４が解放される。

Claims (5)

1. 過負荷の場合に、より高い優先度のアプリケーションに利用できるようにするために、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、かつ、複数のアプリケーションによって同時にリソースを使用可能にすることができるセルラ陸上移動ネットワークを操作するための方法において、解放されるべきリソースの選択を行い、考慮対象のすべてのリソースに関して効率係数が計算され、最小の効率係数を有するリソースが解放されることを特徴とする方法。
2. アプリケーションの絶対数が最大になるように、前記効率係数が、リソースを現在使用しているアプリケーションの数に依存して、特にアプリケーションの数をリソースの容量で割った商として計算される、請求項１に記載の方法。
3. 絶対データ転送率が最大になるように、前記効率係数が、リソースを現在使用しているアプリケーションのデータ転送率に依存して、特にアプリケーションのデータ転送率をリソースの容量で割った商として計算される、請求項１に記載の方法。
4. リソースを現在使用しているアプリケーションの優先度が考慮され、特に、現在使用中のアプリケーションが最も優先度の低いアプリケーションであるリソースについてのみ、効率係数の計算が行われ、任意選択で解放が行われる、請求項１〜３のいずれか一項に記載の方法。
5. 過負荷の場合に、より高い優先度のアプリケーションに利用できるようにするために、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、かつ、複数のアプリケーションによって同時にリソースを使用可能にすることができるセルラ陸上移動ネットワークを備える陸上移動システムにおいて、制御ユニットを有し、前記制御ユニットが、考慮対象のすべてのリソースに関して効率係数を求め、最小の効率係数を有するリソースを解放することによって、解放されるべきリソースを選択するように設定されることを特徴とする陸上移動システム。

Images