(57)【特許請求の範囲】
【請求項１】
より優先度の高いアプリケーションまたはコールに利用できるようにするために、現在使用されているセルラ陸上移動ネットワークの幾つかのリソースを解放して、かつ、複数のアプリケーションによって同時に前記リソースを使用可能にすることができる、過負荷の場合にセルラ陸上移動ネットワークを操作するための方法であって、前記リソースの各々が１つのアプリケーションまたはコールのために、ベースバンド処理容量の大きさの形式で画定される特定の送信容量を与える、前記方法において、
より優先度の高いアプリケーションまたはコールに利用できるようにするために、現在使用されているセルラ陸上移動ネットワークの幾つかのリソースを解放して、かつ、複数のアプリケーションによって同時に前記リソースを使用可能にすることができる、過負荷の場合にセルラ陸上移動ネットワークを操作するための方法であって、前記リソースの各々が１つのアプリケーションまたはコールのために、ベースバンド処理容量の大きさの形式で画定される特定の送信容量を与える、前記方法において、
− 前記より優先度の高いアプリケーションまたはコールに必要なリソースを求めること、
− そこから、解放されるべきベースバンド処理容量の大きさを計算すべく、必要なリソースのベースバンド処理容量の大きさから現在空きのリソースのベースバンド処理容量の大きさを引くこと、
− 単独のアプリケーションまたはコールによって現在占有されている１つのリソースがより優先度の高いアプリケーションまたはコールに必要なベースバンド処理容量の大きさに届かない場合に、現在占有されているリソースを合わせてグループ化して、より優先度の高いアプリケーションまたはコールに必要なベースバンド処理容量の大きさにリソースグループを届かせること、
− リソースまたはリソースグループを現在使用しているアプリケーションとコールの数を、リソースまたはリソースグループによって占有されているベースバンド処理容量の大きさで割った商としての、このアプリケーションとコールの数と、リソースまたはリソースグループを現在使用しているアプリケーションとコールのデータ転送率を、リソースまたはリソースグループによって占有されているベースバンド処理容量の大きさで割った商としての、このアプリケーションとコールのデータ転送率とのいずれかに応じて、より優先度の高いアプリケーションまたはコールに必要なベースバンド処理容量の大きさを有するリソースすべてとリソースグループすべてとに関して効率係数を計算すること、および
− 最小の効率係数を有するリソースまたはリソースグループを解放すること、
の各ステップを行うことによって、解放されるべきリソースの１つの選択を行うことを特徴とする方法。
【請求項２】
リソースまたはリソースグループを現在使用しているアプリケーションとコールの優先度が考慮される、請求項１に記載の方法。
【請求項３】
現在使用中のアプリケーションまたはコールが最も優先度の低いリソースおよびリソースグループについてのみ、効率係数の計算が行われる、請求項４に記載の方法。
【請求項４】
現在使用中のアプリケーションまたはコールが最も優先度の低いリソースおよびリソースグループについてのみ、解放が行われる、請求項３に記載の方法。
【請求項５】
優先度にしたがってリソースがグループ化される、請求項２に記載の方法。
【請求項６】
最も優先度の低いグループ化されたリソースが現在必要なベースバンド処理容量の大きさを提供するのに十分でない場合に、その次に優先度の低いリソースが解放のターゲットとして追加的に選択され、グループに加えられる、請求項５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、過負荷の場合に、現在使用されているセルラ陸上移動ネットワークの幾つかのリソースを解放して、より優先度の高いアプリケーションまたはコールに利用できるようにし、かつ、複数のアプリケーションによって同時に前記リソースを使用可能にすることができるセルラ陸上移動ネットワークを操作するための方法に関する。
【０００２】
すなわち、本発明は、例えばＧＥＲＡＮ、ＵＴＲＡＮ、Ｅ−ＵＴＲＡＮ、ｃｄｍａ２０００、ＵＭＢ、ＷｉＭＡＸなどの規格に従ったセルラ陸上移動システムにおいて、より優先度の高いコールを使用可能にするために解放されなければならない、占有されているネットワークリソースを選択するための方法に関する。これらのシナリオは、通常は過負荷の状況で生じる。
【背景技術】
【０００３】
利用可能な空きネットワークリソースが、より優先度の高い新規のコールを使用可能にするのにもはや十分でないとき、占有されているネットワークリソースを常に解放しなければならない。より優先度の高いコールは、例えばボイスコールまたはストリーミングコールであり、これらは通常、リアルタイムアプリケーションまたはリアルタイムサービスと呼ばれる。リアルタイムサービスとは対照的に、より優先度の低いコールは、非リアルタイムサービスと呼ばれる。非リアルタイムサービスには、特に、インターネット閲覧または電子メールの送受信などのアプリケーションが含まれる。
【０００４】
解放されるべきリソースを選択するための従来技術は、個々のユーザによって占有されているリソースのみを考慮するものである。しかし、現在の陸上移動システムでは、リソースは、複数のアプリケーションまたはユーザによって同時に使用されもする（いわゆる共有リソース）。共有リソースの顕著な例は、ＨＳＤＰＡチャネルに使用されるノードＢのベースバンドリソースである。ノードＢベースバンドでのＨＳＤＰＡは、最大ＨＳＤＰＡ帯域幅に従って特定のリソースを占有する。帯域幅を共有しているユーザの数は、占有されるリソースよって決まる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、前述した欠点を克服する冒頭に述べた種類の方法を開発すること、および特に、共有リソースも考慮する、解放されるべきリソースを選択するための選択アルゴリズムを定義することである。
【課題を解決するための手段】
【０００６】
この目的は、請求項１に記載の方法によって実現される。本発明の有利な発展形態は、従属請求項に記載される。
【０００７】
過負荷の場合に、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、より優先度の高いアプリケーションに利用できるようにしなければならず、かつ、複数のアプリケーションによって同時にリソースを使用可能にすることができるセルラ陸上移動ネットワークを操作するための、特許請求される発明方法では、考慮対象のすべてのリソースに関して効率係数を求め、最小の効率係数を有するリソースを解放することによって、解放されるべきリソースの選択を行うことが有利である。
【０００８】
過負荷の場合に、現在使用されている陸上移動ネットワークの幾つかのリソースを解放して、より優先度の高いアプリケーションまたはコールに利用できるようにすることができ、かつ、複数のアプリケーションによって同時に前記リソースを使用可能にすることができるセルラ陸上移動ネットワークを備える、本発明に関係する陸上移動システムでは、陸上移動システムが制御ユニットを有し、制御ユニットが、考慮対象のすべてのリソースに関して効率係数を求め、最小の効率係数を有するリソースを解放することによって、解放されるべきリソースを選択するように設定されることが特に有利である。
【０００９】
概念「リソース」は、例えば送信局ベースバンド処理容量、エアインターフェース容量、ライン容量など、陸上移動ネットワークにおいて考え得る任意のリソースに関するものである。したがって、概念「リソース」は、陸上移動ネットワークまたは陸上移動システムのいかなるネットワークインフラストラクチャや容量をも包含する。
【００１０】
特許請求される発明方法では、ネットワークインフラストラクチャの幾つかの部分（或る部分）またはリソースを解放して、それらをより優先度の高いアプリケーションおよび／またはコールに利用できるようにし、パラメータを使用してあらかじめ求められた効率係数に応じてリソースの解放を行うことによって、知覚できる介入または知覚できる解放の結果を最小限にする。
【００１１】
したがって、本発明の基本的な着想は、影響を受けるアプリケーションまたは加入者の数を最小にすると同時に解放されるべきリソースのサイズを最大にして、リソースを解放することである。
【００１２】
影響を受けるアプリケーションまたは加入者の数を減少させることによって、顧客に対する影響が低減される。リソースサイズを最大にすることによって、リソースの解放の数が減少される。これは、解放プロセスによって空きリソースを最大にし、それにより空きリソースを将来の新規のコールセットアップに利用できるようにすることによって実現される。
【００１３】
複数のユーザが同時にリソースを使用することができるセルラ陸上移動システムにおいて過負荷の場合に解放されるべきリソースを選択するための特許請求される発明方法では、リソースが一人の加入者によって使用されているか複数の加入者によって使用されているかに関わらず、考慮対象のすべてのリソースに関して効率係数が計算され、最小の効率係数を有するリソースが解放される。
【００１４】
概念「解放」は、特に、例えば陸上移動ネットワークの送信手段への既存のワイヤレス接続を中断および終了することによって現在のアプリケーションを終了することを意味し、それにより、リソース、したがって例えば任意のタイプのワイヤレスチャネルまたはネットワークインフラストラクチャを、より高い優先度を有する別のアプリケーションおよびより高い格付けのアプリケーションに利用できるようになり、接続は、前に解放されたネットワークインフラストラクチャを使用して設定することができる。
【００１５】
したがって、解放は、接続解除、切断、クリア、中断、すなわち接続のクリア、切り離しなどを意味し、すなわち選択されたリソースを他のアプリケーションや通信リンクなどに使用できるようになることを意味する。
【００１６】
特許請求される発明方法では、特に以下の要件が満たされると特に有利である。
− 負荷状況の場合に、より優先度の高いコールまたはアプリケーションが、実行中のより優先度の低いコールまたはアプリケーションを解放させる。
− 選択アルゴリズムが、共有リソースおよび非共有リソースを考慮する。
− 選択アルゴリズムが、トランスポートチャネルのタイプ（例えばＨＳＤＰＡ、ＨＳＵＰＡなど）を考慮しない。
− 占有されているリソースの解放は、現在のアプリケーションに、したがって顧客に影響を及ぼすことを意味する。したがって、選択アルゴリズムは、アプリケーションおよび顧客に対する影響を低減するように設計される。
− リソースの解放は、時間制約が厳しいので複雑なプロセスである。したがって、選択アルゴリズムは、リソース解放の数を最小にすべきである。
− 選択アルゴリズムは、より優先度の高いコールおよび／またはアプリケーション（例えばボイスコールまたはストリーミングアプリケーション）のすべてのタイプに適用可能であるように意図される。
【００１７】
本明細書で特許請求される選択アルゴリズムは、特に以下の入力基準を使用する。
− コール優先度
この基準は、最も優先度の低いコールが最初に解放のターゲットとして選択されることを保証する。
− 解放の対象となり得るリソースを現在使用している、影響を受ける加入者の数
この基準は、顧客に対する影響を最小限にすることを保証する。
− 解放されるべきリソースのサイズ
この基準は、解放の数を最小にすることを保証する。
【００１８】
好ましくは、アプリケーションの絶対数が最大になるように、ネットワークリソースの効率係数が、リソースを現在使用しているアプリケーションの数に依存して、特にアプリケーションの数をリソースの容量で割った商として計算される。
【００１９】
これは、アプリケーション、すなわちユーザに関してシステム容量が最大になるように、解放されることになるユーザまたはアプリケーションの数とこれらのユーザまたはアプリケーションによって占有されているリソースとに基づく効率係数が計算されることを意味する。
【００２０】
１つの代替構成では、絶対データ転送が最大になるように、効率係数が、リソースを現在使用しているアプリケーションのデータ転送率に依存して、特にアプリケーションのデータ転送率をリソースの容量で割った商として計算される。
【００２１】
これは、データ転送率に関してシステム容量が最大になるように、解放されることになるアプリケーションまたはユーザの現在のデータ転送率とこれらのアプリケーションまたはユーザによって占有されているリソースとに基づく効率係数が計算されることを意味する。
【００２２】
１つの好ましい構成では、リソースを現在使用しているアプリケーションの優先度が考慮され、特に、現在使用中のアプリケーションが最も優先度の低いアプリケーションであるリソースについてのみ、効率係数の計算が行われ、任意選択で解放が行われる。すなわち、特に追加の情報として、解放されることになるアプリケーションまたは加入者の優先度が考慮され、最も優先度の低いアプリケーションまたは加入者に関してのみ効率係数が計算される。
【００２３】
提案されるアルゴリズムは、詳細には以下のようなものである。過負荷時の新規のコールを、空きリソースが不十分であるためにセットアップできない場合、新規のコールを実施するのに十分な、現在占有されている各候補のリソースに関して、効率係数が計算される。さらに、現在最も優先度の低い瞬時コールが割り当てられているリソースのみが考慮される。最小の効率係数を有するリソースが選択されて解放される。
【００２４】
送信局ベースバンド処理容量の例を用いると、効率係数は、以下のように定義される。ここで、ＣＥ（チャネル要素）は、送信局ベースバンド処理容量の尺度である。
【数１】
0005323192.tif 000002
ｉは、解放することができるリソースブロックの番号である。したがって、リソース「ｉ」の効率係数は、リソース「ｉ」をその瞬間に使用しているアプリケーションまたはユーザの数を、リソース「ｉ」で利用可能な容量をそれぞれＣＥ（チャネル要素）単位で表した量で割った商に等しい。
【００２５】
送信局ベースバンド処理容量の例に関して、ＡＭＲコールに関するリソース効率は１である。１人の加入者が１ＣＥのみを使用する。例えばＨＳＤＰＡなどの共有リソースに関しては、複数の加入者が１つのリソースブロックを使用している（例えば３人の加入者が３０ＣＥを使用している→リソース効率＝１０％；または１人の加入者が３０ＣＥを使用している→リソース効率＝３．３％）。
【００２６】
選択アルゴリズムは、アプリケーションまたは加入者が使用しているリソースのすべてのリソース効率係数を最小リソースのために比較し、最小値を有するリソースを、解放のためのターゲットとして選択する。
【図面の簡単な説明】
【００２７】
【図１】リソース効率係数の計算例を示す。
【図２】プロセスステップＡ〜Ｆを有する選択アルゴリズムの一実施形態の流れ図および概略を示す。
【発明を実施するための形態】
【００２８】
リソース効率係数は、新たなコールのために使用することができるすべてのリソースブロックに関して計算される。新たなコールが例えば１０ＣＥの容量を必要とする場合、効率係数は、１０ＣＥのすべてのリソースブロックに関して計算される。あるいは、空きリソースが既に利用可能である場合、効率係数は、さらに必要なリソースに関して計算される。
【００２９】
そのような一例が図１に示される。１０ＣＥのワイヤレスチャネル要素容量を必要とする優先度の高いコールを設定するものとする。図１は、現在のノードＢのリソース占有を概略的に示す。
【００３０】
リソース効率［１］、［２］、および［３］のみを計算すればよい。なぜなら、これらのリソースブロックのみが、１０ＣＥを必要とする新たなコールに十分なリソースを利用可能にするからである。
【００３１】
上述したアルゴリズムの１つの起こり得る欠点は、１つのステップで解放されて影響を受けるアプリケーションまたは加入者の数が最小でないことである。しかし、解放の数が最小にされるので、その後の解放は回避され、したがって、影響を受けるアプリケーションおよび顧客の数は最小になる。
【００３２】
図２は、プロセスステップＡ〜Ｆを有する選択アルゴリズムの一実施形態の流れ図および概略を示す。
【００３３】
第１のステップＡでは、より優先度の高いアプリケーションにとって現在必要とされるリソースが求められ、そこから、必要なリソースから現在の空きリソースの量または容量を引くことによって、解放されるべきリソースの質または容量が計算される。
【００３４】
第２のステップＢで、現在占有されているリソースが、それらの優先度に従ってグループ化される。
【００３５】
第３のステップＣで、最も優先度の低いリソースが、解放のためのターゲットとして選択される。最も優先度の低いリソースが、現在必要とされるリソースの量を提供するには十分でない場合、その次に優先度の低いリソースが、解放のターゲットとしてさらに選択される。
【００３６】
第４のステップＤで、ステップＣで決定された解放することができるリソースのリストから、より優先度の高いアプリケーションにとって必要なリソースの量に届く候補のグループが形成される。
【００３７】
ステップＥで、ステップＣで決定された各リソースグループごとに、それぞれの効率係数の形態での個々の効率が計算される。
【００３８】
最後のプロセスステップＦにおいて、最小の効率係数を有するリソースが選択される。それに従って、このリソースが、解放のために選択される。
【００３９】
上述したアルゴリズムは、瞬時のアプリケーションまたはユーザの数に関して、リソース効率を最大にする。すなわち、システム内でのユーザの数が最大になる。アプリケーション／ユーザの数ではなくアルゴリズムの適合によってシステム容量を最大にすることもできる。この用例に関しては、アプリケーションまたはユーザの数ではなく、ユーザデータ転送率が考慮される。
【数２】
0005323192.tif 000003
【００４０】
或るリソースを使用しているユーザが生み出すデータ転送率が、占有されているリソースと関連づけられる。
【００４１】
この方法では、リソース「ｉ」の効率は、データ転送率に依存し、すなわち、リソースｉを瞬時に使用しているｎ個のアプリケーションすべてのデータスループットの和を、割り当てられまたは使用されるワイヤレスネットワーク要素と要素当たりの容量との積で割った商に対応する。
【実施例】
【００４２】
実施例１
送信局が空き容量を有さず、すなわち空きＣＥがない。
１ＣＥを有するＡＭＲコールを新たにセットアップするものとする。
既存のコール：
［１］ｌｘｌ６ｋｂｐｓ  Ｒｅ１９９（１ＣＥ）
［２］ｌｘ３８４  Ｒｅ１９９（１２ＣＥ）
［３］１  ＨＳＵＰＡ加入者（３０ＣＥ）
【００４３】
１ＣＥを空けなければならない。１ＣＥに関するリソース効率を計算しなければならない。
リソース効率［１］１６ｋｂｐｓ  Ｒ９９＝１
リソース効率［２］３８４ｋｂｐｓ  Ｒ９９＝１／１２＝８．３％
リソース効率［３］ＨＳＵＰＡ＝１／３０＝３．３３％
→リソース［３］ＨＳＵＰＡのリソースが解放される。
【００４４】
実施例２
ノードＢに空きＣＥが２だけある。
４ＣＥを有するストリーミングコールをセットアップするものとする。
既存のコール：
［１］１×１６ｋｂｐｓ  Ｒｅ１９９（４ＣＥ）
［２］１×３８４  Ｒｅ１９９（１２ＣＥ）
［３］１  ＨＳＵＰＡ加入者（３０ＣＥ）
【００４５】
２ＣＥを解放しなければならない。２ＣＥに関するリソース効率を計算しなければならない。
リソース効率［１］２×１６ｋｂｐｓ＝２／２＝１
リソース効率［２］３８４ｋｂｐｓ＝１／１２＝８．３％
リソース効率［３］ＨＳＵＰＡ＝３／３０＝１０％
→リソース［２］３８４が解放される。
【図１】
0005323192.tif 000004
【図２】
0005323192.tif 000005