(57)【特許請求の範囲】
【請求項１】
チャネルプロキシユニットと、複数のユーザーイクイップメント（ＵＥ）プロキシユニットとを備えるリソース割当て装置であって、
前記複数のＵＥプロキシユニットは、複数のＵＥについて、申請されるリソースセットをそれぞれ決定し、前記チャネルプロキシユニットに、決定された前記申請されるリソースセットの承認を申請するように構成され、
前記チャネルプロキシユニットは、前記複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するように構成され、前記承認リソース情報は、前記承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを含み、
各ＵＥプロキシユニットは更に、該ＵＥプロキシユニットが受信した前記承認リソース情報によって示される前記承認されたリソースからリソースを選択し、対応するＵＥに前記リソースを割り当てるように構成される、
装置。
【請求項２】
前記チャネルプロキシユニットには競合解決ポリシーが予め設定され、前記チャネルプロキシユニットは、具体的には、
前記複数のＵＥプロキシユニットによって決定された前記申請されるリソースセットの中に競合リソースが存在する場合、前記予め設定された競合解決ポリシーに従って、前記競合リソースの承認を決定するように構成され、前記競合リソースは、前記複数のＵＥプロキシユニットによって決定された前記申請されるリソースセットのうち任意の２以上のリソースセットに存在するリソースである、
請求項１に記載の装置。
【請求項３】
前記競合解決ポリシーは、
優先度が最も高いＵＥに対して前記競合リソースを承認することと、
前記競合リソースを均等に分割することと、
のポリシーのうち１つ又はそれらの組合わせを含む、
請求項２に記載の装置。
【請求項４】
各ＵＥプロキシユニットは更に、前記申請されるリソースセットの各リソース上の前記対応するＵＥの優先度を決定し、決定された前記優先度についての情報を前記チャネルプロキシユニットに送信するように構成される、
請求項３に記載の装置。
【請求項５】
前記複数のＵＥのどれにも新しいリソースが割り当てられず、且つ空きリソースが第１の閾値を超える場合、前記複数のＵＥプロキシユニットの中に不満足なＵＥプロキシユニットが存在するか否かを決定し、不満足なＵＥプロキシユニットが存在する場合、前記不満足なＵＥプロキシユニットに割り当てられたリソースを解放するように構成されるリソース最適化ユニット、
を更に備える、請求項１に記載の装置。
【請求項６】
前記不満足なＵＥプロキシユニットは、
取得された承認されたリソースが要件を満たさないＵＥプロキシユニット、及び／又は、
取得された承認されたリソースが第２の閾値に満たないＵＥプロキシユニット、
を含む、請求項５に記載の装置。
【請求項７】
前記承認リソース情報は承認リソースセットであり、前記承認リソースセットは、前記承認リソースセットを受信するＵＥプロキシユニットによって決定される申請されるリソースセットのサブセットである、
請求項１乃至６のいずれか一項に記載の装置。
【請求項８】
各ＵＥプロキシユニットは更に、リソース利用状況を前記チャネルプロキシユニットにフィードバックするように構成される、
請求項１乃至７のいずれか一項に記載の装置。
【請求項９】
リソース割当て装置が複数のユーザーイクイップメント（ＵＥ）にリソースを割り当てるために用いるリソース割当て方法であって、前記リソース割当て装置はチャネルプロキシユニットと、複数のＵＥプロキシユニットとを備え、当該方法は、
前記複数のＵＥプロキシユニットが、前記複数のＵＥについて、申請されるリソースセットをそれぞれ決定し、前記チャネルプロキシユニットに、決定された前記申請されるリソースセットの承認を申請するステップと、
前記チャネルプロキシユニットが、前記複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するステップであって、前記承認リソース情報は、前記承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを示す、ステップと、
各ＵＥプロキシユニットが、該ＵＥプロキシユニットが受信した前記承認リソース情報によって示される前記承認されたリソースからリソースを選択し、前記リソースを対応するＵＥに割り当てるステップと、
を含む、方法。
【請求項１０】
前記チャネルプロキシユニットが前記複数のＵＥプロキシユニットの承認申請を調整し調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信する前記ステップは、
前記複数のＵＥプロキシユニットによって決定された前記申請されるリソースセットの中に競合リソースが存在する場合、前記チャネルプロキシユニットが、予め設定された競合解決ポリシーに従って、前記競合リソースの承認を決定するステップであって、前記競合リソースは、前記複数のＵＥプロキシユニットによって決定された前記申請されるリソースセットのうち任意の２以上のリソースセットに存在するリソースである、ステップ、
を含む、請求項９に記載の方法。
【請求項１１】
前記競合解決ポリシーは、
優先度が最も高いＵＥに対して前記競合リソースを承認することと、
前記競合リソースを均等に分割することと、
のポリシーのうち１つ又はそれらの組合わせを含む、
請求項１０に記載の方法。
【請求項１２】
前記チャネルプロキシユニットが前記複数のＵＥプロキシユニットの承認申請を調整し調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信する前記ステップの前に、
各ＵＥプロキシユニットが、前記申請されるリソースセットの各リソース上の前記対応するＵＥの優先度を決定し、決定された前記優先度についての情報を前記チャネルプロキシユニットに送信するステップ、
を更に含む、請求項１１に記載の方法。
【請求項１３】
前記複数のＵＥのどれにも新しいリソースが割り当てられず、且つ空きリソースが第１の閾値を超える場合、前記複数のＵＥプロキシユニットの中に不満足なＵＥプロキシユニットが存在するか否かを決定し、不満足なＵＥプロキシユニットが存在する場合、前記不満足なＵＥプロキシユニットに割り当てられたリソースを解放するステップ、
を更に含む、請求項９に記載の方法。
【請求項１４】
前記不満足なＵＥプロキシユニットは、
取得された承認されたリソースが要件を満たさないＵＥプロキシユニット、及び／又は、
取得された承認されたリソースが第２の閾値に満たないＵＥプロキシユニット、
を含む、請求項１３に記載の方法。
【請求項１５】
前記承認リソース情報は承認リソースセットであり、前記承認リソースセットは、前記承認リソースセットを受信するＵＥプロキシユニットによって決定される申請されるリソースセットのサブセットである、
請求項９乃至１４のいずれか一項に記載の方法。
【請求項１６】
各ＵＥプロキシユニットが該ＵＥプロキシユニットが受信した前記承認リソース情報によって示される前記承認されたリソースからリソースを選択し且つ前記リソースを対応するＵＥに割り当てる前記ステップは、
各ＵＥプロキシユニットが、リソース利用状況を前記チャネルプロキシユニットにフィードバックするステップ、
を更に含む、請求項９乃至１５のいずれか一項に記載の方法。
【請求項１７】
請求項９乃至１６のいずれか一項に記載の方法の実行に用いられるプログラムコード群を有するコンピュータープログラムを備えるコンピューター可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信技術分野に関し、詳細には、リソース割当て方法、装置及びシステムに関する。
【背景技術】
【０００２】
無線通信技術の分野では周波数リソースが制限されるので、制限された周波数リソースをどのようにして効果的に利用するかが特に重要である。従来技術では、複数のリソース割当て方法とポリシーが提案されてきた。しかしながら、通信技術の発展とプロトコルの進化に伴い、異なる通信規格又はプロトコルバージョンではリソース割当ての要件が異なる。このような既存のリソース割当て方法とポリシーは柔軟性を欠き、拡張して異なる通信規格又はプロトコルバージョンのリソース割当ての要件を満足することが困難である。
【発明の概要】
【０００３】
本発明の実施形態は、拡張して異なる通信規格又はプロトコルバージョンのリソース割当ての要件を満たすのが容易なリソース割当て方法、装置及びシステムを提供する。
【０００４】
第１の態様によれば、本発明の実施形態はリソース割当て装置を提供する。リソース割当て装置は、チャネルプロキシユニットと、複数のユーザーイクイップメント（ＵＥ）プロキシユニットとを備え、
複数のＵＥプロキシユニットは、複数のＵＥについて、申請されるリソースセットをそれぞれ決定し、チャネルプロキシユニットに、決定された申請されるリソースセットの承認を申請するように構成され、
チャネルプロキシユニットは、複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するように構成され、承認リソース情報は、承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを示し、
各ＵＥプロキシユニットは更に、該ＵＥプロキシユニットが受信した承認リソース情報によって示される承認されたリソースからリソースを選択し、対応するＵＥにリソースを割り当てるように構成される。
【０００５】
第１の態様の第１の可能な実施方式では、チャネルプロキシユニットには競合解決ポリシーが予め設定され、チャネルプロキシユニットは、具体的には、
複数のＵＥプロキシユニットによって決定された申請されるリソースセットの中に競合リソースが存在する場合、予め設定された競合解決ポリシーに従って、競合リソースの承認を決定するように構成され、競合リソースは、複数のＵＥプロキシユニットによって決定された申請されるリソースセットのうち任意の２以上のリソースセットに存在するリソースである。
【０００６】
第１の態様の第１の可能な実施方式に関して、第２の可能な実施方式では、競合解決ポリシーは、
優先度が最も高いＵＥに対して競合リソースを承認することと、
競合リソースを均等に分割することと、
のポリシーのうち１つ又はそれらの組合わせを含む。
【０００７】
第１の態様の第２の可能な実施方式に関して、第３の可能な実施方式では、各ＵＥプロキシユニットは更に、申請されるリソースセットの各リソース上の対応するＵＥの優先度を決定し、決定された優先度についての情報をチャネルプロキシユニットに送信するように構成される。
【０００８】
第１の態様に関して、第４の可能な実施方式では、リソース割当て装置は更に、
複数のＵＥのどれにも新しいリソースが割り当てられず、且つ空きリソースが第１の閾値を超える場合、複数のＵＥプロキシユニットの中に不満足なＵＥプロキシユニットが存在するか否かを決定し、不満足なＵＥプロキシユニットが存在する場合、不満足なＵＥプロキシユニットに割り当てられたリソースを解放するように構成されるリソース最適化ユニット、
を備える。
【０００９】
第１の態様の第４の可能な実施方式に関して、第５の可能な実施方式では、不満足なＵＥプロキシユニットは、
取得された承認されたリソースが要件を満たさないＵＥプロキシユニット、及び／又は、
取得された承認されたリソースが第２の閾値に満たないＵＥプロキシユニット、
を含む。
【００１０】
第１の態様又は第１の態様の第１〜第５の可能な実施方式のいずれか１つに関して、第６の可能な実施方式では、承認リソース情報は承認リソースセットであり、承認リソースセットは、承認リソースセットを受信するＵＥプロキシユニットによって決定される申請されるリソースセットのサブセットである。
【００１１】
第１の態様又は第１の態様の第１〜第６の可能な実施方式のいずれか１つに関して、第７の可能な実施方式では、各ＵＥプロキシユニットは更に、リソース利用状況をチャネルプロキシユニットにフィードバックするように構成される。
【００１２】
第２の態様によれば、本発明の実施形態は、リソース割当て装置が複数のユーザーイクイップメント（ＵＥ）にリソースを割り当てるために用いるリソース割当て方法を提供する。リソース割当て装置は、チャネルプロキシユニットと、複数のＵＥプロキシユニットとを備える。本方法は、
複数のＵＥプロキシユニットが、複数のＵＥについて、申請されるリソースセットをそれぞれ決定し、チャネルプロキシユニットに、決定された申請されるリソースセットの承認を申請するステップと、
チャネルプロキシユニットが、複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するステップであって、承認リソース情報は、承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを示す、ステップと、
各ＵＥプロキシユニットが、該ＵＥプロキシユニットが受信した承認リソース情報によって示される承認されたリソースからリソースを選択し、該リソースを対応するＵＥに割り当てるステップと、
を含む。
【００１３】
第２の態様の第１の可能な実施方式では、チャネルプロキシユニットが複数のＵＥプロキシユニットの承認申請を調整し調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するステップは、
複数のＵＥプロキシユニットによって決定された申請されるリソースセットの中に競合リソースが存在する場合、チャネルプロキシユニットが、予め設定された競合解決ポリシーに従って、競合リソースの承認を決定するステップであって、競合リソースは、複数のＵＥプロキシユニットによって決定された申請されるリソースセットのうち任意の２以上のリソースセットに存在するリソースである、ステップ、
を含む。
【００１４】
第２の態様の第１の可能な実施方式に関して、第２の可能な実施方式では、競合解決ポリシーは、
優先度が最も高いＵＥに対して競合リソースを承認することと、
競合リソースを均等に分割することと、
のポリシーのうち１つ又はそれらの組合わせを含む。
【００１５】
第２の態様の第２の可能な実施方式に関して、第３の可能な実施方式では、チャネルプロキシユニットが複数のＵＥプロキシユニットの承認申請を調整し調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するステップの前に、本方法は、
各ＵＥプロキシユニットが、申請されるリソースセットの各リソース上の対応するＵＥの優先度を決定し、決定された優先度についての情報をチャネルプロキシユニットに送信するステップ、
を更に含む。
【００１６】
第２の態様に関して、第４の可能な実施方式では、本リソース割当て方法は、
複数のＵＥのどれにも新しいリソースが割り当てられず、且つ空きリソースが第１の閾値を超える場合、複数のＵＥプロキシユニットの中に不満足なＵＥプロキシユニットが存在するか否かを決定し、不満足なＵＥプロキシユニットが存在する場合、不満足なＵＥプロキシユニットに割り当てられたリソースを解放するステップ、
を更に含む。
【００１７】
第２の態様の第４の可能な実施方式に関して、第５の可能な実施方式では、不満足なＵＥプロキシユニットは、
取得された承認されたリソースが要件を満たさないＵＥプロキシユニット、及び／又は、
取得された承認されたリソースが第２の閾値に満たないＵＥプロキシユニット、
を含む。
【００１８】
第２の態様又は第２の態様の第１〜第５の可能な実施方式のいずれか１つに関して、第６の可能な実施方式では、承認リソース情報は承認リソースセットであり、承認リソースセットは、承認リソースセットを受信するＵＥプロキシユニットによって決定される申請されるリソースセットのサブセットである。
【００１９】
第２の態様又は第２の態様の第１〜第６の可能な実施方式のいずれか１つに関して、第７の可能な実施方式では、各ＵＥプロキシユニットが該ＵＥプロキシユニットが受信した承認リソース情報によって示される承認されたリソースからリソースを選択し該リソースを対応するＵＥに割り当てるステップは、
各ＵＥプロキシユニットが、リソース利用状況をチャネルプロキシユニットにフィードバックするステップ、
を更に含む。
【００２０】
第３の態様によれば、本発明の実施形態はリソース割当てシステムを提供する。リソース割当てシステムは、
複数のユーザーイクイップメント（ＵＥ）と、
複数のＵＥにリソースを割り当てるように構成される、本発明の第１の態様又は第１の態様の可能な実施方式のうちいずれか１つに係るリソース割当て装置と、
を備える。
【００２１】
第４の態様によれば、本発明の実施形態は、コンピューター可読媒体を備えるコンピュータープログラムを提供する。コンピューター可読媒体は、本発明の第２の態様又は第２の態様の可能な実施方式のいずれか１つに係る方法の実行に用いられるプログラムコード群を有する。
【００２２】
本発明の実施形態において提供されるリソース割当て方法、装置及びシステムによれば、複数のＵＥプロキシユニットが互いに独立して、複数のＵＥへのリソース割当てを処理する。それによって、リソース割当ての効率が改善され、リアルタイムのリソース割当ての要求がより良好に満足される。更に、複数のＵＥプロキシユニット間の競合を調整するために、チャネルプロキシユニットが配置される。このように、各ＵＥプロキシユニットは、対応するＵＥが利用可能なリソースの承認を、リソースセットの形式でチャネルプロキシユニットに申請する必要がある。チャネルプロキシユニットはこれらの承認申請を調整し、調整結果に従って承認情報を送り、ＵＥプロキシユニットによって申請されたリソースセットのどのリソースの利用が承認されたかを各ＵＥプロキシユニットに通知する。このように、各ＵＥプロキシユニットは、承認されたリソースからリソースを選択し、該リソースをＵＥに割り当てることができる。上述のアーキテクチャでは、ＵＥプロキシユニット及びチャネルプロキシユニットは柔軟に拡張され、異なる通信規格又はプロトコルバージョンのリソース割当ての要件をサポートすることができる。更に、シミュレーションにより、そのようなアーキテクチャを用いてリソース割当てを実行した後は周波数選択性向上が大幅に改善することが分かる。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施形態に係るリソース割当て装置の構造の概略図である。
【図２】本発明の実施形態に係る、競合リソースが存在するシナリオの概略図である。
【図３】本発明の実施形態に係る、別のリソース割当て装置の構造の概略図である。
【図４】本発明の実施形態に係るリソース割当て方法のフローチャートである。
【図５】本発明の実施形態に係る、別のリソース割当て方法のフローチャートである。
【図６】２つのＵＥの周波数選択性スケジューリングの優先度の概略図である。
【図７】本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。
【図８】本発明の実施形態に係る、更に別のリソース割当て装置の構造の概略図である。
【図９】本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。
【図１０】本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。
【図１１】本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。
【図１２】本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。
【図１３】本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。
【図１４】本発明の実施形態に係る、更に別のリソース割当て方法のシグナリングフローチャートである。
【図１５】本発明の実施形態１に係るＵＥプロキシユニットの構造の概略図である。
【図１６】本発明の実施形態２に係るＵＥプロキシユニットの構造の概略図である。
【図１７】本発明の実施形態１に係るチャネルプロキシユニットの構造の概略図である。
【図１８】本発明の実施形態１に係るリソース割当て装置の構造の概略図である。
【図１９】本発明の実施形態に係るリソース割当てシステムの構造の概略図である。
【発明を実施するための形態】
【００２４】
発明の実施形態の目的、技術的解決策及び利点をより明確にするために、以下、本発明の実施形態において添付の図面を参照しながら、本発明の実施形態における技術的解決策を明確且つ完全に説明する。当然ながら、説明される実施形態は、本発明の実施形態の一部であって全部ではない。当業者が本発明の実施形態に基づいて創意工夫なく得る他の実施形態は全て、本発明の保護範囲に包含されるものとする。
【００２５】
既存のリソース割当て解決策に存在する課題を考慮し、本願は、競合メカニズムに基づいてリソース割当てが実行される新しいリソース割当てアーキテクチャを提案する。該アーキテクチャでは、複数の機能ユニットが互いに独立して設けられ、互いに独立して、複数のユーザーイクイップメント（User  Equipment、略称ＵＥ）のリソース申請を処理するように構成され、また、１つの機能ユニットが単独で設けられ、複数のＵＥのリソース申請間の競合を処理するように構成される。該アーキテクチャでは、各機能ユニットのポリシーは要件に従って変更又は拡張されてよく、それによって複数の無線技術を柔軟にサポートし、異なるプロトコルバージョンの要求を満たす。
【００２６】
本願では、ＵＥのリソース申請を処理するように構成される機能ユニットはＵＥプロキシユニット又はＵＥプロキシエンティティと称され、複数のＵＥのリソース申請間の競合を処理するように構成される機能ユニットはチャネルプロキシユニット又はチャネルプロキシエンティティと称される。しかしながら、本願では、該名称はそのような機能ユニットを限定するために用いられるものではない。当業者であれば他の名称を採用することができ、それらは全て本発明の保護範囲に包含される。
【００２７】
加えて、本発明の実施形態におけるユニット、サブユニット又はエンティティとは、機能エンティティ又は論理エンティティのことである。ユニット、サブユニット又はエンティティはソフトウェアの形式であってよく、プロセッサがプログラムコードを実行して、ユニット、サブユニット又はエンティティの機能を実現する。また、ユニット、サブユニット又はエンティティはハードウェアの形式であってよく、本発明のいかなる方式においても限定されない。
【００２８】
上述のアーキテクチャの具体的な実施を、添付の図面を参照しながら以下に詳述する。
【００２９】
図１を参照する。図１は、本発明の実施形態に係るリソース割当て装置の構造の概略図である。図１に示されるように、装置１００は、チャネルプロキシユニット１１０と、複数のＵＥプロキシユニット１２１〜１２ｎとを有する。
【００３０】
複数のＵＥプロキシユニット１２１〜１２ｎは、複数のＵＥについて、申請されるリソースセットをそれぞれ決定し、チャネルプロキシユニット１１０に、決定された申請されるリソースセットの承認を申請するように構成される。チャネルプロキシユニット１１０は、複数のＵＥプロキシユニット１２１〜１２ｎの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するように構成される。承認リソース情報は、承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを示す。各ＵＥプロキシユニットは更に、該ＵＥプロキシユニットが受信した承認リソース情報によって示される承認されたリソースからリソースを選択し、対応するＵＥにリソースを割り当てるように構成される。
【００３１】
上述の実施形態では、複数のＵＥプロキシユニットは互いに独立して、複数のＵＥに対するリソース割当てを処理することができることが分かる。それによって、リソース割当ての効率が改善され、リアルタイムのリソース割当ての要求がより良好に満足される。しかしながら、複数のＵＥに対するリソース割当てでは競合が存在する場合がある。すなわち、２以上のＵＥに同じリソースが割り当てられる場合がある。したがって、複数のＵＥプロキシユニット間の競合を調整するために、チャネルプロキシユニットが配置される。このように、各ＵＥプロキシユニットは、対応するＵＥが利用可能なリソースの承認を、リソースセットの形式でチャネルプロキシユニットに申請する必要がある。チャネルプロキシユニットはこれらの承認申請を調整し、すなわち、これらの承認申請のリソース競合を調整し、調整結果に従って承認情報を送り、ＵＥプロキシユニットによって申請されたリソースセットのどのリソースの利用が承認されたかを各ＵＥプロキシユニットに通知する。このように、各ＵＥプロキシユニットは、承認されたリソースからリソースを選択し、該リソースをＵＥに割り当てることができる。
【００３２】
上述のアーキテクチャでは、ＵＥプロキシユニット及びチャネルプロキシユニットは柔軟に拡張され、異なる通信規格又はプロトコルバージョンのリソース割当ての要件をサポートすることができる。更に、シミュレーションにより、そのようなアーキテクチャを用いてリソース割当てを実行した後は周波数選択性向上が大幅に改善することが分かる。シミュレーションデータは以下の実施形態で提供され、ここでは詳細の説明を省略する。
【００３３】
留意すべきこととして、ＵＥプロキシユニットが承認を申請し、チャネルプロキシユニットが承認を与え、ＵＥプロキシユニットがリソースの利用を確認するという上述のプロセスは、反復プロセスと称することができる。ＵＥにリソースを割り当てるプロセスでは、各ＵＥプロキシユニットは、以下の状況まで、複数の反復を実行してよい。
ａ）全てのリソースが割り当てられた。又は、
ｂ）リソースを申請するＵＥプロキシがない。又は、
ｃ）現在の反復では新しいリソースが割り当てられない。又は、
ｄ）反復回数が全体の反復回数を超えている。
【００３４】
本実施形態のリソース割当て装置はアクセスネットワーク側に位置してよく、例えば、基地局、基地局コントローラ（Base  Station  Controller、略称ＢＳＣ）又は無線ネットワークコントローラ（Radio  Network  Controller、略称ＲＮＣ）に配置されてよい。基地局は、様々な通信規格の基地局であってよく、例えば、ＬＴＥの拡張ノードＢ（e-Node  B、略称ｅＮＢ）、グローバル・システム・フォー・モバイル・コミュニケーションズ（Global  System  for  Mobile  Communications、略称ＧＳＭ）等の２Ｇネットワークの基地局（Base  Station、略称ＢＳ）、ユニバーサル・モバイル・テレコミュニケーション・システム（Universal  Mobile  Telecommunications  System、略称ＵＭＴＳ）等の３ＧネットワークのノードＢ（Ｎｏｄｅ  Ｂ）、又はＷｉＭＡＸ（Worldwide  Interoperability  for  Microwave  Access）の無線アクセスポイント（Access  Point、略称ＡＰ）であってよい。
【００３５】
上述の承認リソース情報は承認リソースセットであってよい。承認リソースセットは、承認リソースセットを受信するＵＥプロキシユニットによって決定される申請されるリソースセットのサブセットであり、或いは、承認情報を受信するＵＥプロキシユニットによって決定された申請されるリソースセットの中のどのリソースが承認されたのかを示す指示情報であってよく、本願のいかなる方式においても限定されない。
【００３６】
加えて、任意の実施方式では、各ＵＥプロキシユニットは更に、リソース利用状況をチャネルプロキシユニット１１０にフィードバックしてよい。すなわち、各ＵＥプロキシユニットは、リソース利用状況をチャネルプロキシユニット１１０にフィードバックするように構成される。リソース利用状況は、例えば、どのリソースがＵＥプロキシユニットによって選択され対応するＵＥに割り当てられるのかである。それによって、チャネルプロキシユニットは、ＵＥプロキシユニットに対して承認されたリソースの使用状況を把握することができる。チャネルプロキシユニットはリソースセットを更新し、リソースは申請可能である。
【００３７】
上述の説明から分かるように、チャネルプロキシユニット１１０は主に、ＵＥプロキシユニット１２１〜１２ｎ間のリソース申請競合の処理を担当する。したがって、競合解決ポリシーはチャネルプロキシユニット１１０において予め設定されてよい。それによって、チャネルプロキシユニット１１０は、予め設定された競合解決ポリシーに従って、ＵＥプロキシユニット間のリソース申請競合を解決することができる。当然ながら、ＵＥプロキシユニットのリソース申請に競合が存在しない場合、チャネルプロキシユニット１１０は、各ＵＥプロキシユニットが申請する全てのリソースを承認してよい。
【００３８】
すなわち、複数のＵＥプロキシユニットによって決定された申請されるリソースセット１２１〜１２ｎに競合リソースが存在しない場合、チャネルプロキシユニット１１０は、各ＵＥプロキシユニットによって決定された全ての申請されるリソースセットを承認する。すなわち、承認リソース情報を受信するＵＥプロキシユニットによって決定された申請されるリソースセットのうち、チャネルプロキシユニット１１０によって送信された承認リソース情報によって示されるリソースが、全て承認される。この場合、承認情報は指示情報の１ピースであってよく、例えば指示ビットであってよい。指示ビットが特定の値（例えば０又は１）であるとき、指示情報を受信するＵＥプロキシユニットによって決定された申請されるリソースセットのリソースが全て承認されることを表す。
【００３９】
複数のＵＥプロキシユニット１２１〜１２ｎによって決定された申請されるリソースセットの中に競合リソースが存在する場合、チャネルプロキシユニット１１０は、予め設定された競合解決ポリシーに従って、競合リソースの承認を決定する。競合リソースは、複数のＵＥプロキシユニットによって決定された申請されるリソースセットのうち任意の２以上のリソースセットに存在するリソースである。
【００４０】
上述の競合解決ポリシーは、
優先度が最も高いＵＥに対して競合リソースを承認することと、
競合リソースを均等に分割することと、
のポリシーのうち１つ又はそれらの組合わせを含んでよい。
【００４１】
競合解決ポリシーが、優先度が最も高いＵＥに対して競合リソースを承認することを含む場合、各ＵＥプロキシユニットは更に、申請されるリソースセットの各リソース上の対応するＵＥの優先度を決定し、決定された優先度についての情報をチャネルプロキシユニット１１０に送信するように構成される。
【００４２】
以下、競合リソースが存在するいくつかのシナリオと、対応する採用可能な競合解決ポリシーとを提供する。当然ながら、これらは例に過ぎず、本発明の限定に用いられるものではない。当業者であれば、要件に従って、ポリシーの調製を行うことができる。
【００４３】
競合リソースの第１のシナリオを図２に示す。図２は、競合リソースが存在するシナリオの概略図である。２つのＵＥプロキシユニットはそれぞれ第１のＵＥと第２のＵＥに対応する。図２では、Ａで表記されるリソースは第１のＵＥが取得したリソースであり、略してリソースＡと称される。Ｂで表記されるリソースは第２のＵＥが取得したリソースであり、略してリソースＢと称される。２つのＵＥプロキシユニットは、リソースＡとリソースＢの間のリソースを同時に申請し、図２ではリソースはＲで表記され、略してリソースＲと称される。この場合、可能な実施方式では、チャネルプロキシユニットは、全てのリソースＲを均等に分割し、リソースＲのうちリソースＡに近い一部のリソースを第１のＵＥに割り当て、リソースＲのうちリソースＢに近い一部のリソースを第２のＵＥに割り当ててよい。別の可能な実施方式では、チャネルプロキシユニットは、第１のＵＥ及び第２のＵＥの各リソースＲ上での優先度に従って、第１のＵＥと第２のＵＥとのうち優先度の高い方にリソースＲを割り当てる。
【００４４】
競合リソースの第２のシナリオでは、第１のＵＥが一部のリソースを取得した一方、第２のＵＥはリソースを取得しておらず、２つのＵＥプロキシユニットが同時に、第１のＵＥが取得したリソースに近いリソースを申請する。この場合、競合解決ポリシーは、優先度が最も高いＵＥに対して競合リソースを承認することであってよい。
【００４５】
競合リソースの第３のシナリオは、第１のＵＥと第２のＵＥのどちらもリソースを取得しておらず、２つのＵＥプロキシユニットが同時に１つのリソースを申請する。この場合、競合解決ポリシーは、優先度が最も高いＵＥに対して競合リソースを承認することであってよい。
【００４６】
ＵＥに割り当てられたリソースについて、ロールバックは通常発生しない。ＵＥがリソースの使用を確認した後、該リソースはＵＥに属する。しかしながら、周波数選択性スケジューリングでは、多くのリソースフラグメントが出現する可能性がある。フラグメントの悪化を回避するために、任意の実施方式では、以下の方式を採用してリソース割当てにおけるフラグメントを低減することができる。
【００４７】
図３は、本発明の実施形態に係る、別のリソース割当て装置の構造の概略図である。図３に示されるように、図１に示される装置に基づいて、本実施形態のリソース割当て装置は更に、リソース最適化ユニット１３０を有してよい。リソース最適化ユニット１３０は、複数のＵＥのどれにも新しいリソースが割り当てられず、且つ空きリソースが第１の閾値を超える場合、ＵＥプロキシユニット１２１〜１２ｎの中に不満足なＵＥプロキシユニットが存在するか否かを決定し、不満足なＵＥプロキシユニットが存在する場合、該不満足なＵＥプロキシユニットに割り当てられたリソースを解放するように構成される。
【００４８】
留意すべきこととして、ＵＥプロキシユニット１２１〜１２ｎが承認を申請し、チャネルプロキシユニット１１０が承認を与え、ＵＥプロキシユニット１２１〜１２ｎがリソースの使用を確認する上述のプロセスは、反復プロセスと称することができる。新しいリソースが複数のＵＥのどれにも割り当てられない上述のケースとは、１回の反復で新しいリソースが割り当てられないケースのことである。反復で新しいリソースが割り当てられない場合、反復が収束したことを示し、もう１回の反復は同じ結果をもたらすのみである。この場合、まだ十分な空きリソースが存在する場合、比較的大量のリソースフラグメントが存在することを示す。したがって、一部の不満足なＵＥプロキシユニットに割り当てられたリソースを解放することができ、それによって、これらのＵＥプロキシユニットは次の反復で再びリソース競合に参加する。このように、これらのＵＥプロキシに対応するＵＥは、次の反復プロセスでより良いリソースを取得できる可能性がある。複数のＵＥのどれにも新しいリソースが割り当てられない上述のケースには、通常２つのケースがある。例えば、一方のケースでは、ＵＥプロキシユニットは新しく承認されたリソースを取得しない。他方のケースでは、ＵＥプロキシユニットによって取得された承認されたリソースはＵＥによって使用不可であり、ＵＥに割り当てられず、すなわち、承認されたリソースはＵＥによって使用されない。
【００４９】
更に、不満足なＵＥプロキシユニットは、
取得された承認されたリソースが要件を満たさないＵＥプロキシユニット、及び／又は取得された承認されたリソースが第２の閾値に満たないＵＥプロキシユニットを含む。ここでは、取得された承認されたリソースとは、現在の反復及び現在の反復の前に取得された全ての承認されたリソースのことである。承認されたリソースが要求を満たさない場合、ＵＥプロキシユニットが承認されたリソースを十分に取得していないことを示す。例えば、ＵＥプロキシユニットによって取得された承認されたリソースは、ＵＥがアクセスを完成させるのには不十分であり、ＵＥが１回のコールを完成させるのには不十分であり、或いはそのようなものである。承認されたリソースが要求を満たさない場合、実際のシナリオに従って調整が行われてよく、本発明の本実施形態では限定されない。承認されたリソースが第２の閾値以内である場合、ＵＥプロキシユニットが少量の承認されたリソースを取得したことを示す。第２の閾値は、承認されたリソースが占めるシステム帯域幅の百分率であってよく、或いは承認されたリソースが占める空きリソースの百分率であってよく、本発明の本実施形態では限定されない。
【００５０】
図４は、本発明の実施形態に係るリソース割当て方法のフローチャートである。本実施形態の本方法は、リソース割当て装置が複数のＵＥにリソースを割り当てるために用いられる。リソース割当て装置は、チャネルプロキシユニットと、複数のＵＥプロキシユニットを有する。図４に示されるように、本実施形態のリソース割当て方法は、以下の要素を含んでよい。
【００５１】
ステップ４０１：複数のＵＥプロキシユニットが、複数のＵＥについて、申請されるリソースセットを決定し、チャネルプロキシユニットに、決定された申請されるリソースセットの承認を申請する。
【００５２】
ステップ４０２：チャネルプロキシユニットが、複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信する。承認リソース情報は、承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを示す。
【００５３】
ステップ４０３：各ＵＥプロキシユニットが、該ＵＥプロキシユニットが受信した承認リソース情報によって示される承認されたリソースからリソースを選択し、該リソースを対応するＵＥに割り当てる。
【００５４】
上述の実施形態では、複数のＵＥプロキシユニットは互いに独立して、複数のＵＥに対するリソース割当てを処理することができることが分かる。それによって、リソース割当ての効率が改善され、リアルタイムのリソース割当ての要求がより良好に満足される。しかしながら、複数のＵＥに対するリソース割当てでは競合が存在する場合がある。すなわち、２以上のＵＥに同じリソースが割り当てられる場合がある。したがって、複数のＵＥプロキシユニット間の競合を調整するために、チャネルプロキシユニットが配置される。このように、各ＵＥプロキシユニットは、対応するＵＥが利用可能なリソースの承認を、リソースセットの形式でチャネルプロキシユニットに申請する必要がある。チャネルプロキシユニットはこれらの承認申請を調整し、すなわち、これらの承認申請のリソース競合を調整し、調整結果に従って承認情報を送り、ＵＥプロキシユニットによって申請されたリソースセットのどのリソースの利用が承認されたかを各ＵＥプロキシユニットに通知する。このように、各ＵＥプロキシユニットは、承認されたリソースからリソースを選択し、該リソースをＵＥに割り当てることができる。
【００５５】
上述のアーキテクチャでは、ＵＥプロキシユニット及びチャネルプロキシユニットは柔軟に拡張され、異なる通信規格又はプロトコルバージョンのリソース割当ての要件をサポートすることができる。更に、シミュレーションにより、そのようなアーキテクチャを用いてリソース割当てを実行した後は周波数選択性向上が大幅に改善することが分かる。シミュレーションデータは以下の実施形態で提供され、ここでは詳細の説明を省略する。
【００５６】
留意すべきこととして、ＵＥプロキシユニットが承認を申請し、チャネルプロキシユニットが承認を与え、ＵＥプロキシユニットがリソースの利用を確認するという上述のプロセスは、反復プロセスと称することができる。ＵＥにリソースを割り当てるプロセスでは、各ＵＥプロキシユニットは、以下の状況まで、複数の反復を実行してよい。
ａ）全てのリソースが割り当てられた。又は、
ｂ）リソースを申請するＵＥプロキシがない。又は、
ｃ）現在の反復では新しいリソースが割り当てられない。又は、
ｄ）反復回数が全体の反復回数を超えている。
【００５７】
上述の承認リソース情報は承認リソースセットであってよい。承認リソースセットは、承認リソースセットを受信するＵＥプロキシユニットによって決定される申請されるリソースセットのサブセットであり、或いは、承認情報を受信するＵＥプロキシユニットによって決定された申請されるリソースセットの中のどのリソースが承認されたのかを示す指示情報であってよく、本願のいかなる方式においても限定されない。
【００５８】
加えて、任意の実施方式では、各ＵＥプロキシユニットは更に、リソース利用状況をチャネルプロキシユニット１１０にフィードバックしてよい。すなわち、各ＵＥプロキシユニットは、リソース利用状況をチャネルプロキシユニット１１０にフィードバックするように構成される。リソース利用状況は、例えば、どのリソースがＵＥプロキシユニットによって選択され対応するＵＥに割り当てられるのかである。それによって、チャネルプロキシユニットは、ＵＥプロキシユニットに対して承認されたリソースの使用状況を把握することができる。チャネルプロキシユニットはリソースセットを更新し、リソースは申請可能である。
【００５９】
上述の実施形態では、更に、ステップ４０２は具体的に、
複数のＵＥプロキシユニットによって決定された申請されるリソースセットの中に競合リソースが存在する場合、チャネルプロキシユニットが、予め設定された競合解決ポリシーに従って、競合リソースの承認を決定するステップであって、競合リソースは、複数のＵＥプロキシユニットによって決定された申請されるリソースセットのうち任意の２以上のリソースセットに存在するリソースである、ステップ、
を含んでよい。
【００６０】
競合解決ポリシーは、
優先度が最も高いＵＥに対して競合リソースを承認することと、
競合リソースを均等に分割することと、
のポリシーのうち１つ又はそれらの組合わせを含んでよい。
【００６１】
ＵＥに割り当てられたリソースについて、ロールバックは通常発生しない。ＵＥがリソースの使用を確認した後、該リソースはＵＥに属する。しかしながら、周波数選択性スケジューリングでは、多くのリソースフラグメントが出現する可能性がある。フラグメントの悪化を回避するために、任意の実施方式では、以下の手続きを採用してリソース割当てにおけるフラグメントを低減することができる。
【００６２】
更に、図５は、本発明の実施形態に係る、別のリソース割当て方法のフローチャートである。本実施形態の方法では、図４に示される方法に基づいて、ＵＥプロキシユニットがチャネルプロキシユニットに優先度情報を送信するステップと、リソースフラグメントを最適化する関連ステップとが追加される。図５に示されるように、本実施形態の方法は以下の要素を含んでよい。
【００６３】
ステップ５０１：複数のＵＥプロキシユニットが、複数のＵＥについて、申請されるリソースセットをそれぞれ決定し、チャネルプロキシユニットに、決定された申請されるリソースセットの承認をそれぞれ申請する。
【００６４】
ステップ５０２：各ＵＥプロキシユニットが、申請されるリソースセットの各リソース上の対応するＵＥの優先度を決定し、決定された優先度についての情報をチャネルプロキシユニットに送信する。
【００６５】
ステップ５０１及びステップ５０２は、厳密な時間順序に依存しない。各ＵＥプロキシユニットは、対応するＵＥの各リソース上での優先度を決定してから、申請されるリソースセットを決定し、それからリソースセットのリソースの優先度をチャネルプロキシユニットに送信してよい。優先度レベルは単独で送信されてよく、或いは申請されるリソースセットと共に送信されてよい。各ＵＥプロキシユニットは、申請されるリソースセットを決定してから、対応するＵＥの該セットの各リソース上での優先度を決定し、それからリソースセットのリソースの優先度をチャネルプロキシユニットに送信してよい。優先度は単独で送信されてよく、或いは申請されるリソースセットと共に送信されてよい。加えて、ＵＥプロキシユニットは、優先度情報を承認申請のメッセージに追加し、該メッセージをチャネルプロキシユニットに送信してよい。具体的には、各ＵＥプロキシユニットは、対応するＵＥの全てのリソース上での優先度を決定してから、リソースセットを決定し、それからリソースセットの各リソースの優先度をチャネルプロキシユニットに報告する。
【００６６】
ステップ５０３：チャネルプロキシユニットが、複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信する。承認リソース情報は、承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを示す。
【００６７】
ステップ５０４：各ＵＥプロキシユニットが、該ＵＥプロキシユニットが受信した承認リソース情報によって示される承認されたリソースからリソースを選択し、該リソースを対応するＵＥに割り当てる。
【００６８】
ステップ５０５：複数のＵＥのどれにも新しいリソースが割り当てられず、且つ空きリソースが第１の閾値を超える場合、複数のＵＥプロキシユニットの中に不満足なＵＥプロキシユニットが存在するか否かを決定し、不満足なＵＥプロキシユニットが存在する場合、不満足なＵＥプロキシユニットに割り当てられたリソースを解放する。
【００６９】
不満足なＵＥプロキシユニットは、取得された承認されたリソースが要件を満たさないＵＥプロキシユニット、及び／又は取得された承認されたリソースが第２の閾値に満たないＵＥプロキシユニットを含む。ここでは、取得された承認されたリソースとは、現在の反復及び現在の反復の前に取得された全ての承認されたリソースのことである。
【００７０】
承認されたリソースが要求を満たさない場合、ＵＥプロキシユニットが承認されたリソースを十分に取得していないことを示す。例えば、ＵＥプロキシユニットによって取得された承認されたリソースは、ＵＥがアクセスを完成させるのには不十分であり、ＵＥが１回のコールを完成させるのには不十分であり、或いはそのようなものである。承認されたリソースが要求を満たさない場合、実際のシナリオに従って調整が行われてよく、本発明の本実施形態では限定されない。承認されたリソースが第２の閾値以内である場合、ＵＥプロキシユニットが少量の承認されたリソースを取得したことを示す。第２の閾値は、承認されたリソースが占めるシステム帯域幅の百分率であってよく、或いは承認されたリソースが占める空きリソースの百分率であってよく、本発明の本実施形態では限定されない。
【００７１】
上述の実施形態で提供されるリソース割当て方法及び装置は、アップリンクリソースの割当てに用いることができるだけでなく、ダウンリンクリソースの割当てに用いることもでき、更に、様々な通信規格、例えば、ロング・ターム・エボリューション（Long-Term  Evolution、略称ＬＴＥ）、ＷｉＭＡＸ（World  Interoperability  for  Microwave  Access）及びユニバーサル・モバイル・テレコミュニケーション・システム（Universal  Mobile  Telecommunications  System、略称ＵＭＴＳ）で用いることができる。
【００７２】
ＬＴＥのアップリンクリソースを割り当てるアルゴリズムでは、以下の制約条件を考慮する必要がある。
【００７３】
１）アップリンクリソースの割当ては非常に短い時間内に完了されなければならないので（ＬＴＥの処理時間は１ミリ秒である）、アップリンクリソースを割り当てるアルゴリズムはリアルタイム要件を保証しなければならない。
【００７４】
２）リソース割当てアルゴリズムでユーザーに割り当てられるリソースブロック（Resource  Block、略称ＲＢ）の最大数は、アップリンクユーザーの最大送信電力に依存する。
【００７５】
３ａ）ＬＴＥ  Ｒ８プロトコルではシングルキャリア周波数分割多元接続（Single-carrier  frequency  division  multiple  access、略称ＳＣ−ＦＤＭＡ）技術が採用され、ユーザーに割り当てられるリソースはＳＣ−ＦＤＭＡ技術の制限を満たさなければならない。すなわち、ユーザーに割り当てられるＲＢは連続でなければならない。ユーザーに割り当てられるＲＢの数ＮがＮ＝２ｊ×３ｋ×５ｌと表すことができることが要求される。
【００７６】
３ｂ）ＬＴＥ  Ｒ１０プロトコルではキャリアアグリゲーション（Carrier  Aggregation、ＣＡ）技術が採用され、ユーザーに割り当てられるリソースはＣＡの要件を満たす必要がある。すなわち、連続するリソースの２つのセグメントがユーザーに割り当てられ、リソースブロックグループ（Resource  Block  Group、略称ＲＢＧ）が、連続するリソースの各セグメントにおいて粒度として用いられる。ユーザーに割り当てられるＲＢの総数ＮがＮ＝２ｊ×３ｋ×５ｌと表すことができることが要求される。
【００７７】
以下、ＬＴＥ  Ｒ８におけるアップリンクリソース１つのセグメントの割当てと、ＬＴＥ  Ｒ１０におけるリソースの２つのセグメントの割当ての例を用いて、上述の解決策を紹介する。
【００７８】
本発明のリソース割当て方法の実施形態１では、各ユーザーが連続するアップリンクリソースの１つのセグメントを取得できるというＬＴＥ  Ｒ８プロトコルでの制約に従って、リソース割当てが実行される。図４に示されるリソース割当て方法を参照して、本方法の具体的な実施プロセスは以下のとおりである。
【００７９】
シナリオ１：ＵＥが現在承認されたリソースを取得していない場合、ステップ４０１では、ＵＥプロキシユニットは任意の空きリソースを申請してよく、すなわち、任意の数のＲＢ又はＲＢＧを申請されるリソースセットとして決定してよい。ステップ４０３では、ＵＥプロキシユニットによって選択されＵＥに割り当てられるリソースセットは、ＲＢリソースの１つのセグメント又はＲＢＧリソースの１つのセグメントである。
【００８０】
シナリオ２：ＵＥが現在ＲＢリソースの１つのセグメントを取得しており、申請中のリソースセットが取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧであるとＵＥプロキシユニットが決定した場合、取得されたリソースの両側に位置し且つ取得されたリソースと連結して連続するセグメントとなることのできるＲＢリソース又はＲＢＧが申請されてよい。ステップ４０３では、ＵＥプロキシユニットは、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースを選択する、すなわち、取得されたリソースの両側のＲＢ又はＲＢＧリソースの２つのセグメントがそれぞれ選択されてよく、或いは、片側のＲＢ又はＲＢＧリソースの１つのセグメントが選択されてよい。それによって、新しく選択されたＲＢ又はＲＢＧリソースと取得されたリソースとが接続され、連続するＲＢリソースの１つのセグメントになる。
【００８１】
本発明のリソース割当て方法の実施形態２では、各ユーザーが連続するＲＢリソースの１つのセグメント又はそれぞれ連続するＲＢＧリソースの２つのセグメントを取得できるというＬＴＥ  Ｒ１０プロトコルでの制約に従って、リソース割当てが実行される。図４に示されるリソース割当て方法を参照して、本方法の具体的な実施プロセスは以下のとおりである。
【００８２】
シナリオ１：ＵＥが現在承認されたリソースを取得していない場合、ステップ４０１では、ＵＥプロキシユニットは任意の空きリソースを申請してよく、すなわち、任意の数のＲＢ又はＲＢＧを申請されるリソースセットとして決定してよい。ステップ４０３では、ＵＥプロキシユニットによって選択されＵＥに割り当てられるリソースセットは、ＲＢリソースの１つのセグメント又はＲＢＧリソースの１つ若しくは２つのセグメントである。
【００８３】
シナリオ２：ＵＥが現在ＲＢリソースの１つのセグメントを取得している場合、ＵＥプロキシユニットは、申請中のリソースセットが、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースであると決定する。ＵＥプロキシユニットによって選択されＵＥに割り当てられるリソースセットは、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースである。
【００８４】
シナリオ３：ＵＥが現在ＲＢＧリソースの２つのセグメントを取得している場合、ＵＥプロキシユニットは、申請中のリソースセットが、取得されたＲＢＧリソースの２つのセグメントのうち任意のＲＢＧリソースの１つのセグメントと連続するＲＢＧリソースであると決定する。ＵＥプロキシユニットによって選択されＵＥに割り当てられるリソースセットは、取得されたＲＢＧリソースの２つのセグメントのうち任意のＲＢＧリソースの１つのセグメントと連続するＲＢＧリソースである。
【００８５】
シナリオ４：ＵＥが現在ＲＢＧリソースの１つのセグメントを取得している場合、ＵＥプロキシユニットは、申請中のリソースセットが少なくとも１つのＲＢＧリソースであるか、又は申請中のリソースセットが取得されたＲＢＧリソースと連続するＲＢリソースであると決定する。ＵＥプロキシユニットによって選択されＵＥに割り当てられるリソースセットはＲＢＧリソースの１つのセグメントであり、又は取得されたＲＢＧリソースと連続するＲＢリソースである。
【００８６】
既存の比較的単純なリソース割当て方法は、以下のとおりである。
【００８７】
ユーザーイクイップメント（user  equipment、ＵＥ）の優先度は、ＵＥのフルバンドチャネル品質インジケータ（channel  quality  indicator、略称ＣＱＩ）に従って計算される。したがって、優先度が最大であるＵＥが選択され、該ＵＥにリソースが割り当てられる。割当てが失敗した場合、ＵＥはスキップされる。リソース割当てのプロセスでは、ＵＥに割り当てられる必要のあるリソースブロック（ＲＢ）の最大数Ｎは、選択されたＵＥのフルバンドＣＱＩ、サービス品質（quality  of  service、略称ＱｏＳ）、バッファ状態報告（buffer  status  report、略称ＢＳＲ）及び電力ヘッドルーム（power  headroom）等の情報に従って計算される。最大ＲＢ数がＮである最良のサブバンドが選ばれたＵＥに対して残りの帯域から見つけられ、ＵＥのＲＢリソース及び変調符号化方式(modulation  and  coding  scheme、略称ＭＣＳ）が決定される。リソースが割り当てられる全てのＵＥがスケジュールされるまで、又はリソース割当てが完了するまで、上述のプロセスを繰り返して次のＵＥを選択する。
【００８８】
従来技術の上述の方法では、各ユーザーがそれぞれ連続するＲＢＧリソースの２つのセグメントを取得できるというＬＴＥ  Ｒ１０プロトコルでの制約に従って、ＲＢＧリソースの２つのセグメントをＵＥに割り当てることができないことが分かる。したがって、ＬＴＥ  Ｒ１０ネットワークでの性能向上の利点を達成することができない。加えて、従来技術の上述の方法では、ユーザーの全帯域（略称フルバンド）上での平均優先度は、フルバンドＣＱＩに従って計算され、周波数リソースはユーザーの平均優先度に従ってユーザーに割り当てられ、ユーザーの周波数選択性向上は比較的低い。例えば、セル内の２人のユーザーすなわちユーザーＡ及びユーザーＢについて、図６は、２つのＵＥの周波数選択性スケジューリングの優先度の概略図である。図６に示されるように、ユーザーＡの平均優先度は高めであり、ユーザーＢの平均優先度は低めである。しかしながら、周波数選択性特性を理由に、ユーザーＢのリソースセグメント上での優先度はユーザーＡよりも高い。電力の観点から、ユーザーＡは５０個のＲＢの割当てをサポートすることができる。ユーザーＢはエッジユーザーであり、１０個のＲＢしか使用できない。従来技術の上述のアルゴリズムによれば、最初にユーザーＡが選択され、スケジューリングアルゴリズムを用いて、５０個のＲＢが全てユーザーＡに割り当てられる。一方、ユーザーＢはどのリソースも取得できない。このようなリソース割当ての方式により、ユーザーＡ及びユーザーＢの周波数選択性向上が同時に低減される。
【００８９】
同じシナリオについて、本発明のリソース割当て方法を採用する。一態様では、実施形態２に示されるように、ＲＢＧリソースの２つのセグメントをＵＥに割り当てることができる。したがって、ＬＴＥ  Ｒ１０ネットワークでの性能向上の利点を達成することができる。別の態様では、ＵＥプロキシユニットが対応するＵＥの申請されるリソースセットの各リソース上での優先度を決定し、決定された優先度についての情報をチャネルプロキシユニットに送信するので、チャネルプロキシユニットは各リソース上でのユーザー優先度に従って割当てを実行する。これにより、ユーザーの周波数選択性向上を改善することができる。
【００９０】
以下、本発明のリソース割当て方法が実施された後のユーザーの周波数選択性向上をシミュレーションして、本発明の技術的効果を示す。シミュレーションのパラメータを以下の表に示す。
【表１】
0006271019.tif 000002
【００９１】
上述のパラメータ構成に基づくシミュレーション結果を以下の表に示す。
【表２】
0006271019.tif 000003
【００９２】
本発明のリソース割当て方法がＬＴＥ  Ｒ８ネットワークに適用されるとき、ベースラインに比べて性能が明らかに改善されることが分かる。また、本発明のリソース割当て方法がＬＴＥ  Ｒ１０ネットワークに適用されるとき、ベースラインに比べて性能はより明らかに改善される。
【００９３】
図７は、本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。本実施形態の本方法は、リソース割当て装置がダウンリンクリソースを複数のＵＥに割り当てるために用いられる。リソース割当て装置は、チャネルプロキシユニットと、複数のＵＥプロキシユニットとを有する。図７に示されるように、本実施形態のリソース割当て方法は以下の要素を含んでよい。
【００９４】
ステップ７０１：複数のＵＥプロキシユニットが、複数のＵＥについて、申請されるダウンリンクリソースセットをそれぞれ決定し、チャネルプロキシユニットに、決定された申請されるダウンリンクリソースセットの承認をそれぞれ申請する。
【００９５】
ステップ７０２：チャネルプロキシユニットが、複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信する。承認リソース情報は、承認リソース情報を受信するＵＥプロキシユニットの、該ＵＥプロキシユニットが決定した申請されるリソースセットのうち承認されたリソースを示す。
【００９６】
ステップ７０３：各ＵＥプロキシユニットが、該ＵＥプロキシユニットが受信した承認リソース情報によって示される承認されたダウンリンクリソースからダウンリンクリソースを選択し、該ダウンリンクリソースを対応するＵＥに割り当てる。
【００９７】
上述の実施形態では、複数のＵＥプロキシユニットは互いに独立して、複数のＵＥに対するダウンリンクリソース割当てを処理することができることが分かる。それによって、ダウンリンクリソース割当ての効率が改善され、リアルタイムのリソース割当ての要求がより良好に満足される。しかしながら、複数のＵＥに対するリソース割当てでは競合が存在する場合がある。すなわち、２以上のＵＥに同じダウンリンクリソースが割り当てられる場合がある。したがって、複数のＵＥプロキシユニット間の競合を調整するために、チャネルプロキシユニットが配置される。このように、各ＵＥプロキシユニットは、対応するＵＥが利用可能なリソースの承認を、リソースセットの形式でチャネルプロキシユニットに申請する必要がある。チャネルプロキシユニットはこれらの承認申請を調整し、すなわち、これらの承認申請のリソース競合を調整し、調整結果に従って承認情報を送り、ＵＥプロキシユニットによって申請されたリソースセットのどのリソースの利用が承認されたかを各ＵＥプロキシユニットに通知する。このように、各ＵＥプロキシユニットは、承認されたリソースからリソースを選択し、該リソースをＵＥに割り当てることができる。
【００９８】
上述のアーキテクチャでは、ＵＥプロキシユニット及びチャネルプロキシユニットは柔軟に拡張され、異なる通信規格又はプロトコルバージョンのリソース割当ての要件をサポートすることができる。更に、シミュレーションにより、そのようなアーキテクチャを用いてリソース割当てを実行した後は周波数選択性向上が大幅に改善することが分かる。
【００９９】
留意すべきこととして、ダウンリンクリソースを割り当てる方法は、アップリンクリソースを割り当てる方法に類似する。すなわち、本発明の本実施形態で提供されるリソース割当て方法は、アップリンクリソースの割当てに用いることができ、ダウンリンクリソースの割当てに用いることもできる。
【０１００】
本発明の本実施形態で提供されるリソース割当て方法がアップリンクリソースの割当てに用いられるとき、チャネルプロキシユニットに対応するチャネルは、物理アップリンク共有チャネル（Physical  Uplink  Shared  Channel、略称ＰＵＳＣＨ）であってよい。
【０１０１】
留意すべきこととして、上述の実施形態における各ＵＥプロキシユニットは、単独で設けられるプロセッサであってよく、或いは、基地局のプロセッサへの統合により実現されてよく、或いは、プログラムコードの形式で基地局のメモリに格納されてよい。基地局のプロセッサは、上述のＵＥプロキシユニットの機能を呼び出し実行する。チャネルプロキシユニット及びリソース最適化ユニットの実施はＵＥプロキシユニットの実施と同様であり、ここでは詳細の説明を省略する。ここでは、プロセッサは、中央演算処理装置（Central  Processing  Unit、ＣＰＵ）又は特定用途向け集積回路（Application  Specific  Integrated  Circuit、ＡＳＩＣ）であってよく、或いは、本発明の本実施形態を実現する１以上の集積回路として構成されてよい。
【０１０２】
加えて、留意すべきこととして、ＵＥプロキシユニット及びチャネルプロキシユニットは異なるプロセッサを用いて実現されてよく、ＵＥプロキシユユニットとチャネルプロキシユニットとのインタラクションは、プロセッサ間のインタラクションによって実現される。或いは、同じプロセッサを用いて実現されてよく、ＵＥプロキシユユニットとチャネルプロキシユニットとのインタラクションは、プロセッサの異なるプロセス間のインタラクションによって実現される。加えて、各ＵＥプロキシユニットは同じプロセッサを用いて実現されてよく、或いは異なるプロセッサを用いて実現されてよく、本発明の本実施形態のいかなる方式においても限定されない。
【０１０３】
図８を参照されたい。図８は、本発明の実施形態に係る、更に別のリソース割当て装置の構造の概略図である。図８に示されるように、リソース割当て装置は、プロセッサ８０１及びインターフェース回路８０２を有する。該図面は更にメモリ８０３及びバス８０４を示す。プロセッサ８０１、インターフェース回路８０２及びメモリ８０３はバス８０４を用いて接続され、相互通信を完成する。
【０１０４】
バス８０４は、インダストリ・スタンダード・アーキテクチャ（Industry  Standard  Architecture、略称ＩＳＡ）バス、ペリフェラル・コンポーネント・インターコネクト（Peripheral  Component  Interconnect、略称ＰＣＩ）バス、拡張インダストリ・スタンダード・アーキテクチャ（Extended  Industry  Standard  Architecture、略称ＥＩＳＡ）バス等であってよい。バス８０４は、アドレスバス、データバス、コントロールバス等に分類されてよい。表記の便宜上、図８では１本の太線のみを用いて表すが、１本のバス又は１種類のバスのみが存在することを表すものではない。
【０１０５】
メモリ８０３は、実行プログラムコードを格納するように構成される。プログラムコードはコンピューター操作命令を含む。メモリ８０３は高速ＲＡＭメモリを含んでよく、或いは更に、不揮発性メモリ（non-volatile  memory）、例えば少なくとも１つの磁気ディスクメモリを有してよい。
【０１０６】
プロセッサ８０１は、中央演算処理装置（Central  Processing  Unit、略称ＣＰＵ）又は特定用途向け集積回路（Application  Specific  Integrated  Circuit、略称ＡＳＩＣ）であってよく、或いは、本発明の本実施形態を実現する１以上の集積回路として構成されてよい。
【０１０７】
プロセッサ８０１は、
複数のＵＥについて、申請されるリソースセットをそれぞれ決定し、決定された申請されるリソースセットの承認をそれぞれ申請するように構成され、
複数のＵＥプロキシユニットの承認申請を調整し、調整結果に従って承認リソース情報を各ＵＥプロキシユニットに送信するように構成され、承認リソース情報は、ＵＥプロキシユニットによって決定された申請されるリソースセットのうち承認されたリソースを示し、且つ、
承認リソース情報によって示される承認されたリソースからリソースを選択し、対応するＵＥにリソースを割り当てるように構成される。
【０１０８】
プロセッサ８０１は、具体的には、複数のＵＥの申請されるリソースセットに競合リソースが存在するとき、予め設定された競合解決ポリシーに従って競合リソースの承認を決定するように構成される。競合リソースは、複数のＵＥの申請されるリソースセットのうち任意の２以上のリソースセットに存在するリソースである。
【０１０９】
具体的には、競合解決ポリシーは、
優先度が最も高いＵＥに対して競合リソースを承認することと、
競合リソースを均等に分割することと、
のポリシーのうち１つ又はそれらの組合わせを含む。
【０１１０】
プロセッサ８０１は更に、複数のＵＥの承認申請が調整される前に、申請されるリソースセットの各リソース上のＵＥの優先度を決定するように構成される。
【０１１１】
プロセッサ８０１は更に、複数のＵＥのどれも承認されたリソースを取得せず、且つ空きリソースが第１の閾値を超える場合、複数のＵＥのうち少なくとも１つのＵＥによって取得された承認されたリソースを解放するように構成される。
【０１１２】
承認されたリソースが開放されるＵＥは、承認されたリソースが要件を満たさないＵＥ及び／又は承認されたリソースが第２の閾値に満たないＵＥを含む。
【０１１３】
承認リソース情報は承認リソースセットである。承認リソースセットは、ＵＥプロキシユニットによって決定された申請されるリソースセットのサブセットである。
【０１１４】
リソースが承認されたリソースから選択され対応するＵＥに割り当てられた後、プロセッサ８０１は更に、リソース利用状況を決定するように構成される。
【０１１５】
留意すべきこととして、プロセッサ８０１とは複数のプロセッサのことであってよい。ＵＥプロキシユニットとチャネルプロキシユニットとのインタラクションは、プロセッサ間のインタラクションによって実現される。或いは、１つのプロセッサであってよく、ＵＥプロキシユニットとチャネルプロキシユニットとのインタラクションは、プロセッサの異なるプロセス間のインタラクションによって実現される。
【０１１６】
図９は、本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。本実施形態における実行主体はＵＥプロキシユニットである。図９に示されるように、本実施形態のリソース割当て方法は以下の要素を含んでよい。
【０１１７】
ステップ９０１：ＵＥプロキシユニットが、リソース割当てリクエストをチャネルプロキシユニットに送信する。リソース割当てリクエストは申請中のリソースセットを含み、リソースセットは少なくとも１つのリソースを含む。
【０１１８】
具体的には、リソースはＲＢであってよく、或いはＲＢＧであってよい。
【０１１９】
申請中のリソースセットは複数の形式を用いて表されてよい。例えば、リソースマークの形式が採用されてよく、すなわち、全ての割り当てられるリソースを含むリストが採用されてよい。リスト中、申請されるリソースは、申請される必要のあるリソースとしてマークされ、例えば１とマークされる。申請されない別のリソースは申請されないリソースとしてマークされ、例えば、０とマークされる。代替として、申請される必要のあるリソースのみを含むリストが採用されてもよい。
【０１２０】
具体的には、ＵＥプロキシユニットに対応するＵＥが以前にリソースを取得していない場合、ＵＥプロキシユニットは、全ての利用可能なリソースを申請してよく、すなわち、任意の割り当てられていないＲＢ又はＲＢＧを申請してよい。ＵＥプロキシユニットに対応するＵＥが以前にリソースのセグメントを取得している場合、ＵＥプロキシユニットは、ＬＴＥ  Ｒ８プロトコルでの制約に従って、取得されたリソースと連続するリソースを申請してよく、すなわち、取得されたリソースの両側に位置し且つ取得されたリソースと連結して連続するリソースの１つのセグメントとなることのできるＲＢ又はＲＢＧを申請してよい。ＬＴＥ  Ｒ１０プロトコルの制約に従って、各ＵＥは、連続するＲＢリソースの１つのセグメントを取得してよく、或いは、それぞれ連続するＲＢＧリソースの２つのセグメントを取得してよい。したがって、ＵＥプロキシユニットはより柔軟な方式でリソースを申請してよい。取得されたリソースと連続するリソースが申請されてよく、それによって、ＵＥは連続するＲＢリソースの１つのセグメントを取得する。或いは、取得されたリソースと連続するリソースが申請されてよく、それによって、該リソースと取得されたリソースとが連続するＲＢＧリソースの１つのセグメントとなり、同時に、他の場所の割り当てられていないＲＢＧリソースが申請される。ＵＥプロキシユニットに対応するＵＥが以前にＲＢＧリソースの２つのセグメントを取得している場合、ＵＥプロキシユニットは、取得されたＲＢＧリソースの２つのセグメントのうち任意のＲＢＧリソースの１つのセグメントと連続するＲＢＧリソースを申請してよい。
【０１２１】
申請中のリソースセットを決定するとき、ＵＥプロキシユニットは更に、干渉調整アルゴリズム等の別のアルゴリズムの要件に従って、申請されるリソースを選択してよい。例えば、一部のリソースのサブセット上のみでリソースを申請するために選択されてよい。
【０１２２】
更に、ＵＥプロキシユニットがチャネルプロキシユニットに送信するリソース割当てリクエストは更に、ＵＥプロキシユニットがリソースのサブバンドＣＱＩに従って計算した、申請される各リソース上でのユーザー優先度を搬送してよい。それによって、チャネルプロキシユニットは、各リソース上でのユーザー優先度に従ってリソースを割り当てる。従来技術では、ユーザーのフルバンド上での平均優先度がフルバンドＣＱＩに従って通常計算され、ユーザーの平均優先度に従って、周波数リソースがユーザーに割り当てられる。したがって、本発明の本実施形態で提供されるリソース割当て方法により、ユーザーはより高い周波数選択性向上を得ることができる。
【０１２３】
ステップ９０２：ＵＥプロキシユニットが、チャネルプロキシユニットによって送信されたリソース利用許可を受信する。リソース利用許可は、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報を搬送する。
【０１２４】
具体的には、ＵＥプロキシユニットによって送信されたリソース割当てリクエストを受信した後、前記チャネルプロキシユニットは、リソース割当てリクエストで申請されるリソースセットに従って割当てを実行する。複数のＵＥプロキシユニットが同時にリソースを申請するとき、チャネルプロキシユニットは、ＵＥプロキシユニット間のリソース申請競合の処理を担当する。具体的には、リソース申請競合を処理する方式では、各リソース上でのユーザー優先度に従って、優先度の比較的高いＵＥプロキシユニットにリソースが割り当てられてよい。
【０１２５】
リソース割当ての完了後、チャネルプロキシユニットは、リソース利用許可をＵＥプロキシユニットに送信してよい。リソース利用許可は、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報を搬送してよい。
【０１２６】
ステップ９０３：ＵＥプロキシユニットが、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、リソースの少なくとも１つのセグメントを選択する。リソースの各セグメントは、１つのリソース又は複数の連続したリソースを含む。
【０１２７】
リソース利用許可に含まれる、ＵＥプロキシユニットに割り当てられるリソースは、通常、ＵＥプロキシユニットによって申請されるリソースセットのサブセットであり、連続しないＲＢ又はＲＢＧの複数のセグメントであってよく、そこからＵＥプロキシユニットは少なくとも１つの必要なリソースのセグメントを選択してよい。
【０１２８】
ステップ９０４：ＵＥプロキシユニットが、リソース利用結果フィードバック情報をチャネルプロキシユニットに送信する。フィードバック情報は、ＵＥプロキシユニットがリソース情報に従って利用するリソースの少なくとも１つのセグメントを搬送する。
【０１２９】
具体的には、ステップ９０４においてフィードバック情報で搬送され、ＵＥプロキシユニットによって用いられるリソースの少なくとも１つのセグメントは、ステップ９０３で選択されるリソースの少なくとも１つのセグメントである。
【０１３０】
留意すべきこととして、上述のプロセスが完了した後、ＵＥプロキシユニットは更に更なるリソースを必要とする場合がある。この場合、ＵＥプロキシユニットはステップ９０１〜ステップ９０４を再実行して、再びリソースを申請してよい。リソース割当てを実行するための循環反復の上述のプロセスは、全てのリソースが割り当てられた場合と、ＵＥプロキシユニットのどれもこれ以上リソースを申請しない場合と、リソース割当てのプロセスの実行回数が所定の値を超えた場合と、リソース割当ての現在のプロセスが任意のリソースの割当ての実施に失敗した場合とのうちいずれか１つが発生したとき、終了されてよい。
【０１３１】
本実施形態では、ＵＥプロキシユニットは、申請されるリソースセットを決定し、申請されるリソースセットをリソース割当てリクエストに追加し、リソース割当てリクエストをチャネルプロキシユニットに送信し、チャネルプロキシユニットによって送信され割り当てられたリソース情報を含むリソース利用許可を受信し、割り当てられたリソースからリソースの少なくとも１つのセグメントを選択する。それによって、ＵＥプロキシユニットに対応するＵＥは、ＬＴＥ  Ｒ８又はＬＴＥ  Ｒ１０の制約条件を満たすリソースを取得し、それからリソース利用結果フィードバック情報をチャネルプロキシユニットに送信して、リソース割当てを実現する。ＵＥプロキシユニットによって受信され割り当てられたリソース情報を含むリソース利用許可は、各リソース上のユーザー優先度に従ってチャネルプロキシユニットによって割り当てられるので、ユーザーの周波数選択性向上を改善することができる。
【０１３２】
以下、図９に示される方法実施形態の技術的解決策を、いくつかの具体的な実施形態を用いて詳述する。
【０１３３】
図１０は、本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。図１に示される実施形態に基づいて、本実施形態の方法では、ＵＥプロキシユニットがリソース割当てリクエストをチャネルプロキシユニットに送信する前に、ＵＥプロキシユニットが申請中の各リソース上のユーザー優先度を計算するプロセスが追加され、リソース割当てが完了された後に最適化ステップが更に追加され、それにより、多すぎるリソースフラグメントを回避する。本実施形態における実行主体はＵＥプロキシユニットである。図１０に示されるように、本実施形態の方法は以下の要素を含んでよい。
【０１３４】
ステップ１００１：ＵＥプロキシユニットが、リソースのサブバンドＣＱＩに従って、申請中の各リソース上のユーザー優先度を計算し、申請中の各リソース上のユーザー優先度についての情報をリソース割当てリクエストに追加する。
【０１３５】
ステップ１００２：ＵＥプロキシユニットが、リソース割当てリクエストをチャネルプロキシユニットに送信する。リソース割当てリクエストは申請中のリソースセットを含み、リソースセットは少なくとも１つのリソースを含む。
【０１３６】
ステップ１００３：ＵＥプロキシユニットが、チャネルプロキシユニットによって送信されたリソース利用許可を受信する。リソース利用許可は、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報を搬送する。
【０１３７】
ステップ１００４：ＵＥプロキシユニットが、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、リソースの少なくとも１つのセグメントを選択する。リソースの各セグメントは、１つのリソース又は複数の連続したリソースを含む。
【０１３８】
具体的には、チャネルプロキシユニットによって送信されたリソース利用許可を取得した後、ＵＥプロキシユニットは、リソース利用許可の範囲内で、最良のリソースを見つけて使用してよい。例えば、チャネルプロキシユニットによって送信されたリソース利用許可に対応するリソースは、ＵＥプロキシユニットに対応するＵＥの需要に対して過剰である場合がある。この場合、ＵＥプロキシユニットは、対応するアルゴリズムに従って最適なリソースを決定し、最適なリソースを選択してよい。シングルキャリア周波数分割多元接続（Single-Carrier  Frequency  Division  Multiple  Access、略称ＳＣ−ＦＤＭＡ）技術が採用されるＵＥについて、ＵＥはリソースの１つのセグメントのみを使用することができる。一方、チャネルプロキシユニットはリソースの複数のセグメントをユーザーに送ってよく、ユーザープロキシは、リソースの複数のセグメントからリソースの１つの最良のセグメントを見つけて使用する。
【０１３９】
具体的な実現の間、ステップ１００４は以下の２つの方式を含んでよい。
【０１４０】
方式１：ＵＥプロキシユニットが、必要なＲＢリソースの数に従って、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソースから、ＲＢリソースの少なくとも１つのセグメントを選択する。それによって、ＵＥプロキシユニットはＲＢリソースのセグメントを取得する。ＲＢリソースのセグメントは、１つのＲＢリソース又は複数の連続したＲＢリソースを含む。
【０１４１】
ＵＥプロキシユニットに対応するＵＥが現在リソースを取得していない場合、ＵＥプロキシユニットはＲＢリソースの１つのセグメントを選択してよい。ＵＥプロキシユニットに対応するＵＥが以前にリソースの１つのセグメントを取得している場合、ＵＥプロキシユニットは、取得されたリソースの両側のＲＢリソースの２つのセグメントをそれぞれ選択してよく、或いは、片側のＲＢリソースの１つのセグメントを選択してよい。それによって、新しく選択されたＲＢリソースと取得されたリソースとが接続され、連続するＲＢリソースの１つのセグメントとなる。このような方式は、ＬＴＥ  Ｒ８及びＬＴＥ  Ｒ１０の通信システムに適する。
【０１４２】
方式２：ＵＥプロキシユニットが、必要なＲＢＧリソースの数に従って、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソースから、ＲＢＧリソースの少なくとも１つのセグメントを選択する。それによって、ＵＥプロキシユニットは、ＲＢＧリソースの１つ又は２つのセグメントを取得する。ＲＢＧリソースのセグメントは、１つのＲＢＧリソース又は複数の連続したＲＢＧリソースを含む。
【０１４３】
ＬＴＥ  Ｒ８の通信システムについて、ＵＥプロキシユニットに対応するＵＥが現在リソースを取得していない場合、ステップ１００４において、ＵＥプロキシユニットはＲＢＧリソースの１つ又は２つのセグメントを選択してよい。ＵＥプロキシユニットに対応するＵＥが現在ＲＢＧリソースの１つのセグメントを取得している場合、ＵＥプロキシユニットは、取得されたリソースの両側のＲＢＧリソースの２つのセグメントをそれぞれ選択するか、又は、片側のＲＢＧリソースの１つのセグメントを選択してよい。それによって、新しく選択されたＲＢＧリソースと取得されたリソースとが接続されて、連続するＲＢＧリソースの１つのセグメントとなる。同時に、ＲＢＧリソースの１つのセグメントは更に、任意の位置で選択されてよい。ＵＥプロキシユニットに対応するＵＥが現在ＲＢＧリソースの２つのセグメントを取得している場合、ＵＥプロキシユニットは、取得されたＲＢＧリソースのいずれか１つのセグメントの両側のＲＢＧリソースを選択してよい。それによって、ＵＥプロキシユニットに対応するＵＥは、連続するＲＢＧリソースの２つのセグメントを取得する。
【０１４４】
ステップ１００５：ＵＥプロキシユニットが、リソース利用結果フィードバック情報をチャネルプロキシユニットに送信する。フィードバック情報は、ＵＥプロキシユニットがリソース情報に従って利用するリソースの少なくとも１つのセグメントを搬送する。
【０１４５】
リソース割当ての現在のプロセスにおいてチャネルプロキシユニットから十分なリソースを取得することに失敗したＵＥプロキシユニットについて、再びリソースを申請するためにステップ１００１が再実行されてよい。
【０１４６】
一般に、リソース割当てのプロセスではロールバックは発生しない。すなわち、ＵＥプロキシユニットに割り当てられたリソースは、ＵＥプロキシユニットに対応するＵＥに属する。しかしながら、リソース割当てのプロセスではリソースフラグメントが出現する可能性があるので、多すぎるリソースフラグメントを回避するために、更に、本実施形態のリソース割当て方法は更に、以下の要素を含んでよい。
【０１４７】
ステップ１００６：ＵＥプロキシユニットに割り当てられたリソースの数が所定の値より小さい場合、ＵＥプロキシユニットが、割り当てられたリソースを解放する。
【０１４８】
多すぎるリソースフラグメントを回避するための上述の最適化ステップのトリガ条件は、ステップ１００５の実行が終了したとき、ＵＥプロキシユニットが十分なリソースを取得していないこと、すなわち、リソース割当ての現在のプロセスでＵＥプロキシユニットが取得したリソースの数がＵＥプロキシユニットの期待値よりも小さいこと、更に、ＵＥプロキシユニットが取得したリソースが第１の所定の値より小さいことであってよい。加えて、利用可能なリソースの数が第２の所定の値よりも大きく、すなわち、比較的大量の割り当てられるリソースが更に存在する。第１の所定の値及び第２の所定の値は、ネットワーク側で予め構成されてよい。
【０１４９】
割り当てられたリソースを解放した後、ＵＥプロキシユニットは、リソース割当ての次のプロセスで全ての利用可能なリソースを申請してよい。それによって、ＵＥプロキシユニットは、リソース割当ての次のプロセスでより良好なリソースを取得することができる。
【０１５０】
本実施形態では、ＵＥプロキシユニットは、リソースのサブバンドＣＱＩに従って、申請中の各リソース上のユーザー優先度を計算し、申請中の各リソース上のユーザー優先度についての情報をリソース割当てリクエストに追加する。それによって、競合リソース申請を処理するとき、チャネルプロキシユニットは、リソースのユーザー優先度が比較的高いＵＥプロキシユニットに競合リソースを割り当て、結果として、リソース割当てがより合理的になり、ユーザーが得る周波数選択性向上がより高くなる。その数が所定の値よりも小さい割り当てられたリソースをＵＥプロキシユニットが解放するリソース最適化ポリシーにより、多すぎるリソースフラグメントが回避され、リソース割当ての効率が改善される。
【０１５１】
図１１は、本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。本実施形態では、ＬＴＥ  Ｒ８の通信システムについてリソース割当ての手続きが紹介される。本実施形態における実行主体はＵＥプロキシユニットである。図９に示される実施形態のステップ９０１又は図１０に示される実施形態のステップ１００２の前に、本実施形態の方法は更に、以下の要素を有してよい。
【０１５２】
ステップ１１０１：ＵＥプロキシユニットが現在のリソース割当て状態を決定する。リソース割当て状態は、リソースが割り当てられていないこと、又はＲＢリソースの１つのＲＢリソースが取得されたことを含む。
【０１５３】
ステップ１１０２：ＵＥプロキシユニットが、現在のリソース割当て状態に従って、申請中のリソースセットを決定する。
【０１５４】
更に、ステップ１１０２は、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、ＵＥプロキシユニットが、申請中のリソースセットが少なくとも１つのＲＢリソース又は少なくとも１つのＲＢＧリソースであると決定するか、又は、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、ＵＥプロキシユニットが、申請中のリソースセットが、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースであると決定するステップ、
を含んでよい。
【０１５５】
これに対応して、本実施形態では、ＵＥプロキシユニットが、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、リソースの少なくとも１つのセグメントを選択するステップは、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、ＵＥプロキシユニットが、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、ＲＢリソースの１つのセグメント又はＲＢＧリソースの１つ若しくは２つのセグメントを選択するか、又は、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、ＵＥプロキシユニットが、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースを選択するステップ、
を含んでよい。
【０１５６】
本実施形態の他のステップは、図９に示される実施形態又は図１０に示される実施形態の対応するステップと同じであってよい。
【０１５７】
本実施形態では、リソース割当てリクエストをチャネルプロキシユニットに送信する前に、ＵＥプロキシユニットは、まず、ＵＥプロキシユニットに対応するＵＥの現在のリソース割当て状態を決定し、現在のリソース割当て状態に従って申請中のリソースセットを決定し、現在のリソース割当て状態に従って、使用されているリソースを決定する。結果として、ＬＴＥ  Ｒ８の通信システムのリソース割当てに関する要件が満たされる。
【０１５８】
図１２は、本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。本実施形態では、ＬＴＥ  Ｒ１０の通信システムについてリソース割当ての手続きが紹介される。本実施形態における実行主体はＵＥプロキシユニットである。図９に示される実施形態のステップ９０１又は図１０に示される実施形態のステップ１００２の前に、本実施形態の方法は更に、以下の要素を有してよい。
【０１５９】
ステップ１２０１：ＵＥプロキシユニットが現在のリソース割当て状態を決定する。リソース割当て状態は、リソースが割り当てられていないこと、ＲＢリソースの１つのＲＢリソースが取得されたこと、ＲＢＧリソースの２つのＲＢリソースが取得されたこと、又はＲＢＧリソースの１つのセグメントが取得されたことを含む。
【０１６０】
ステップ１２０２：ＵＥプロキシユニットが、現在のリソース割当て状態に従って、申請中のリソースセットを決定する。
【０１６１】
更に、ステップ１２０２は、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、ＵＥプロキシユニットが、申請中のリソースセットが少なくとも１つのＲＢリソース又は少なくとも１つのＲＢＧリソースであると決定するか、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、ＵＥプロキシユニットが、申請中のリソースセットが、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースであると決定するか、
現在のリソース割当て状態がＲＢＧリソースの２つのＲＢリソースが取得されたことである場合、ＵＥプロキシユニットが、申請中のリソースセットが、取得されたＲＢＧリソースの２つのセグメントのうち任意のＲＢＧリソースの１つのセグメントと連続するＲＢＧリソースであると決定するか、又は、
現在のリソース割当て状態がＲＢＧリソースの１つのセグメントが取得されたことである場合、ＵＥプロキシユニットが、申請中のリソースセットが少なくとも１つのＲＢＧリソースであると決定するか、若しくは申請中のリソースセットが取得されたＲＢＧリソースと連続するＲＢリソースであると決定するステップ、
を含んでよい。
【０１６２】
これに対応して、本実施形態では、ＵＥプロキシユニットが、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、リソースの少なくとも１つのセグメントを選択するステップは、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、ＵＥプロキシユニットが、申請中のリソースセットが、ＲＢリソースの１つのセグメント又はＲＢＧリソースの１つ若しくは２つのセグメントであると決定するか、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、ＵＥプロキシユニットが、申請中のリソースセットが、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースであると決定するか、
現在のリソース割当て状態がＲＢＧリソースの２つのＲＢリソースが取得されたことである場合、ＵＥプロキシユニットが、申請中のリソースセットが、取得されたＲＢＧリソースの２つのセグメントのうち任意のＲＢＧリソースの１つのセグメントと連続するＲＢＧリソースであると決定するか、又は、
現在のリソース割当て状態がＲＢＧリソースの１つのセグメントが取得されたことである場合、ＵＥプロキシユニットが、申請中のリソースセットがＲＢＧリソースの１つのセグメントであると決定するか、又は申請中のリソースセットが取得されたＲＢＧリソースと連続するＲＢリソースであると決定するステップ、
を含んでよい。
【０１６３】
本実施形態の他のステップは、図９に示される実施形態又は図１０に示される実施形態の対応するステップと同じであってよい。
【０１６４】
本実施形態では、リソース割当てリクエストをチャネルプロキシユニットに送信する前に、ＵＥプロキシユニットは、まず、ＵＥプロキシユニットに対応するＵＥの現在のリソース割当て状態を決定し、現在のリソース割当て状態に従って申請中のリソースセットを決定し、現在のリソース割当て状態に従って、使用されているリソースを決定する。結果として、ＬＴＥ  Ｒ１０の通信システムのリソース割当てに関する要件が満たされる。
【０１６５】
図１３は、本発明の実施形態に係る、更に別のリソース割当て方法のフローチャートである。本実施形態における実行主体はチャネルプロキシユニットである。本実施形態では、チャネルプロキシユニットがＵＥプロキシユニットにリソースを割り当てる方法が紹介される。図１３に示されるように、本実施形態のリソース割当て方法は以下の要素を含んでよい。
【０１６６】
ステップ１３０１：チャネルプロキシユニットが、少なくとも２つのＵＥプロキシユニットによって送信されたリソース割当てリクエストを受信する。リソース割当てリクエストは申請中のリソースセットを含み、リソースセットは少なくとも１つのリソースを含む。
【０１６７】
リソースは、リソースブロック（ＲＢ）又はＲＢグループ（ＲＢＧ）である。
【０１６８】
更に、リソース割当てリクエストは更に、申請されてよい各リソース上でのＵＥプロキシユニットのユーザー優先度についての情報を搬送してよい。各リソース上でのユーザー優先度についての情報は、リソースのサブバンドＣＱＩに従うＵＥプロキシユニットによる計算により、取得されてよい。
【０１６９】
ステップ１３０２：少なくとも２つのＵＥプロキシユニットが申請するリソースセットの中に少なくとも１つの競合リソースが存在する場合、チャネルプロキシユニットが、各競合リソースについてリソース競合解決ポリシーを用いて、リソース割当てを実行する。
【０１７０】
リソース競合解決ポリシーは、リソースについて競合するＵＥのうちユーザー優先度が比較的高いＵＥに競合リソースを割り当てることであってよく、或いは、リソースについて競合するＵＥのうち、リソース接続性の原則に従って、取得されたリソースが競合リソースと接続してセグメントとなることのできるＵＥに競合リソースを割り当てることであってよい。
【０１７１】
ステップ１３０３：チャネルプロキシユニットが、リソース利用許可をＵＥプロキシユニットに送信する。リソース利用許可は、ＵＥプロキシユニットに割り当てられたリソース情報を搬送する。
【０１７２】
具体的には、チャネルプロキシユニットは、全ての競合リソースの競合が解決された後に、リソース利用許可をＵＥプロキシに送信してよい。リソース利用許可には複数の形式が採用されてよい。例えば、リソースマークの形式が採用されてよく、すなわち、全ての割り当てられるリソースを含むリストが採用されてよい。リスト中、ＵＥプロキシユニットが使用を許可されたリソースは利用可能とマークされ、例えば１とマークされる。ＵＥプロキシユニットに割り当てられない別のリソースは利用不可とマークされ、例えば０とマークされる。
【０１７３】
ステップ１３０４：チャネルプロキシユニットが、ＵＥプロキシユニットによって送信されたリソース利用結果フィードバック情報を受信する。フィードバック情報は、ＵＥプロキシユニットがリソース情報に従って利用するリソースの少なくとも１つのセグメントを搬送する。リソースの少なくとも１つのセグメントは、１つのリソース又は複数の連続したリソースを含む。
【０１７４】
チャネルプロキシユニットがＵＥプロキシユニットに送信するリソース利用許可はＵＥプロキシユニットの需要に対して過剰なリソースを含んでよく、ＵＥプロキシユニットは該リソースから必要なリソースの少なくとも１つのセグメントを選択してよいので、選択後、ユーザープロキシは、リソース利用結果フィードバック情報をチャネルプロキシユニットに送信する必要がある。
【０１７５】
本実施形態では、チャネルプロキシユニットが、少なくとも２つのＵＥプロキシユニットによって送信されたリソース割当てリクエストを受信し、各競合リソースについてリソース競合解決ポリシーを用いてリソース割当てを実行し、それによりリソース割当てを実現し、それからリソース利用許可を対応するＵＥプロキシユニットに送信し、ＵＥプロキシユニットによって送信されるリソース利用結果フィードバック情報を受信し、それによりリソース割当てを完了する。チャネルプロキシユニットは各競合リソースについて競合解決ポリシーを用いて割当てを行うので、各競合リソース上でのユーザー優先度を考慮することができ、ユーザーの周波数選択性向上が改善される。
【０１７６】
更に、上述の実施形態では、ステップ１３０２においてチャネルプロキシユニットが各競合リソースについて競合解決ポリシーを用いてリソース割当てを行うことは、
任意の１つの競合リソースについて、チャネルプロキシユニットが、ユーザー優先度の最も高いＵＥプロキシユニットにリソースを割り当てるか、又は、
任意の１つの競合リソースについて、チャネルプロキシユニットが、リソースを申請する少なくとも２つのＵＥプロキシユニットのうち、割り当てられたリソースが競合リソースと連続するＵＥプロキシユニットにリソースを割り当てるステップ、
を含んでよい。
【０１７７】
更に具体的には、競合リソースが出現し得る特別なシナリオについて、可能な実施方式では、ステップ１３０２においてチャネルプロキシユニットが各競合リソースについて競合解決ポリシーを用いてリソース割当てを行うことは、更に、
任意の１つの競合リソースについて、リソースに割り当てられた第１のＵＥプロキシユニットのユーザー優先度が第２のＵＥプロキシユニットのユーザー優先度よりも高く、第１のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続せず、第２のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続する場合、チャネルプロキシユニットが、第２のＵＥプロキシユニットにリソースを割り当てるステップ、
を含んでよい。
【０１７８】
別の可能な実施方式では、ステップ１３０２においてチャネルプロキシユニットが各競合リソースについて競合解決ポリシーを用いてリソース割当てを行うことは、更に、
任意の１つの競合リソースについて、リソースに割り当てられた第１のＵＥプロキシユニットのユーザー優先度が第２のＵＥプロキシユニットのユーザー優先度よりも高い場合、第１のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続し、第２のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続する場合、チャネルプロキシユニットが、第１のＵＥプロキシユニットにリソースを割り当てるステップ、
を含んでよい。
【０１７９】
上述の２つの可能な実施方式では、競合リソースについて以下のシナリオが出現し得る。すなわち、第１のＵＥプロキシユニットと第２のＵＥプロキシユニットの両方が同じリソースを申請し、該リソースは第２のＵＥプロキシユニットの割り当てられたリソースと連続し、且つ第１のＵＥプロキシユニットの割り当てられたリソースと連続せず、第１のＵＥプロキシユニットのユーザー優先度が第２のＵＥプロキシユニットのユーザー優先度よりも高い。このようなシナリオでは、第１の可能な実施方式によれば、チャネルプロキシユニットのリソース競合解決ポリシーは、例えばリソースの接続性がより重要であることである。したがって、リソースは第２のＵＥプロキシユニットに割り当てられる。第２の可能な実施方式によれば、チャネルプロキシユニットのリソース競合解決ポリシーは、例えばリソース上のユーザー優先度がより重要であることである。したがって、リソースは第１のＵＥプロキシユニットに割り当てられる。どちらの方式が具体的に採用されるかは、通信ネットワークの実際の要求に従って決定されてよい。
【０１８０】
具体的な実現時には、競合リソースについて以下の特別なシナリオも存在し得る。図２は、競合リソースの特別なシナリオの概略図である。図２に示されるように、特別なシナリオでは、第１のＵＥプロキシユニットに対応するＵＥはユーザーＡであり、第２のＵＥプロキシユニットに対応するＵＥはユーザーＢである。図２では、Ａで表記されるリソースは、ユーザーＡによって取得されたリソースであり、略してリソースＡと称される。Ｂで表記されるリソースは、ユーザーＢによって取得されたリソースであり、略してリソースＢと称される。第１のＵＥプロキシユニット及び第２のＵＥプロキシユニットは同時にリソースＡとリソースＢの間のリソースを申請し、該リソースは図中Ｒで表記され、略してリソースＲと称される。この場合、可能な実施方式では、チャネルプロキシユニットは全てのリソースＲを均等に分割し、リソースＲのうちリソースＡに近い一部のリソースを第１のユーザープロキシに割り当て、リソースＲのうちリソースＢに近い一部のリソースを第２のユーザープロキシに割り当ててよい。
【０１８１】
図１４は、本発明の実施形態に係る、更に別のリソース割当て方法のシグナリングフローチャートである。本実施形態では、ＵＥプロキシユニットとチャネルプロキシユニットがインタラクションを実行してリソース割当てを完了する方法が紹介される。図１４に示されるように、本実施形態の方法は以下の要素を含んでよい。
【０１８２】
ステップ１４０１：ＵＥプロキシユニットが、リソースのサブバンドＣＱＩに従って、申請中の各リソース上のユーザー優先度を計算し、申請中の各リソース上のユーザー優先度についての情報をリソース割当てリクエストに追加する。
【０１８３】
ステップ１４０２：ＵＥプロキシユニットが、現在のリソース割当て状態を決定する。
【０１８４】
ステップ１４０３：ＵＥプロキシユニットが、現在のリソース割当て状態に従って、申請中のリソースセットを決定する。
【０１８５】
ステップ１４０２及びステップ１４０３はステップ１４０１の前に実行されてもよく、或いは、ステップ１４０１、ステップ１４０２及びステップ１４０３は順番どおりに実行されてよい。
【０１８６】
ステップ１４０２における具体的なリソース割当て状態と、ステップ１４０３における具体的な操作については、上記の実施形態３及び実施形態４の説明を参照することができる。
【０１８７】
ステップ１４０４：ＵＥプロキシユニットが、リソース割当てリクエストをチャネルプロキシユニットに送信する。リソース割当てリクエストは申請中のリソースセットを含み、リソースセットは少なくとも１つのリソースを含む。
【０１８８】
ステップ１４０５：少なくとも２つのＵＥプロキシユニットが申請するリソースセットの中に少なくとも１つの競合リソースが存在する場合、チャネルプロキシユニットが、各競合リソースについてリソース競合解決ポリシーを用いて、リソース割当てを実行する。
【０１８９】
ステップ１４０６：チャネルプロキシユニットが、リソース利用許可をＵＥプロキシユニットに送信する。リソース利用許可は、ＵＥプロキシユニットに割り当てられたリソース情報を搬送する。
【０１９０】
ステップ１４０７：ＵＥプロキシユニットが、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、リソースの少なくとも１つのセグメントを選択する。リソースの各セグメントは、１つのリソース又は複数の連続したリソースを含む。
【０１９１】
ステップ１４０８：ＵＥプロキシユニットが、リソース利用結果フィードバック情報をチャネルプロキシユニットに送信する。フィードバック情報は、ＵＥプロキシユニットがリソース情報に従って利用するリソースの少なくとも１つのセグメントを搬送する。
【０１９２】
ステップ１４０９：ＵＥプロキシユニットに割り当てられたリソースの数が所定の値より小さい場合、ＵＥプロキシユニットが、割り当てられたリソースを解放する。
【０１９３】
ステップ１４０９は、多すぎるリソースフラグメントを回避するために設定される任意のステップである。
【０１９４】
本実施形態では、ＵＥプロキシユニットは、リソースのサブバンドＣＱＩに従って、申請中の各リソース上のユーザー優先度を計算し、申請中の各リソース上のユーザー優先度についての情報をリソース割当てリクエストに追加する。それによって、競合リソース申請を処理するとき、チャネルプロキシユニットは各競合リソースについて競合解決ポリシーを用いて割当てを行い、各競合リソースのユーザー優先度を考慮することができる。結果として、リソース割当てをより合理的にすることができ、ユーザーによって取得される周波数選択性向上がより高くなる。その数が所定の値よりも小さい割り当てられたリソースをＵＥプロキシユニットが解放するリソース最適化ポリシーにより、多すぎるリソースフラグメントが回避され、リソース割当ての効率が改善される。リソース割当て方法を実行するために、ＵＥプロキシユニットとチャネルプロキシユニットが互いに協働する方式が採用される。リソースを申請する前に、ＵＥプロキシユニットは最初にユーザーの現在のリソース割当て状態を決定し、異なる状況に従って異なる申請中のリソースセットを決定し、使用される異なるリソースを決定する。それによって、リソース割当て方法はＬＴＥ  Ｒ８及びＬＴＥ  Ｒ１０のリソース割当てに関する要件に同時に適合し、通信プロトコルの他のバージョンの他の要件に従って容易に拡張可能である。
【０１９５】
図１５は、本発明の実施形態１に係るＵＥプロキシユニットの構造の概略図である。図１５に示されるように、本実施形態の装置１５００は、リクエストモジュール１１、許可受信モジュール１２、リソース選択モジュール１３及びフィードバックモジュール１４を有してよい。
【０１９６】
リクエストモジュール１１は、リソース割当てリクエストをチャネルプロキシユニットに送信するように構成されてよい。リソース割当てリクエストは申請中のリソースセットを含み、リソースセットは少なくとも１つのリソースを含む。
【０１９７】
許可受信モジュール１２は、チャネルプロキシユニットによって送信されたリソース利用許可を受信するように構成されてよい。リソース利用許可は、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報を搬送する。
【０１９８】
リソース選択モジュール１３は、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、リソースの少なくとも１つのセグメントを選択するように構成されてよい。リソースの各セグメントは、１つのリソース又は複数の連続したリソースを含む。
【０１９９】
フィードバックモジュール１４は、リソース利用結果フィードバック情報をチャネルプロキシユニットに送信するように構成されてよい。フィードバック情報は、ＵＥプロキシユニットがリソース情報に従って利用するリソースの少なくとも１つのセグメントを搬送する。
【０２００】
本実施形態の装置は、図１に示される方法実施形態に記載の技術的解決策を実行するように構成されてよく、対応する機能モジュールを有する。機能モジュールの実施原理は同様であり、ここでは説明を省略する。本実施形態の装置では、リクエストモジュールはリソース割当てリクエストをチャネルプロキシユニットに送信し、許可受信モジュールは、チャネルプロキシユニットによって送信され割り当てられたリソース情報を含むリソース利用許可を受信し、リソース選択モジュールは、割り当てられたリソースからリソースの少なくとも１つのセグメントを選択する。それによって、ＵＥプロキシユニットに対応するＵＥは、ＬＴＥ  Ｒ８又はＬＴＥ  Ｒ１０の制約条件を満たすリソースを取得し、フィードバックモジュールはリソース利用結果フィードバック情報をチャネルプロキシユニットに送信して、リソース割当てを実現する。許可受信モジュールによって受信されるリソース利用許可は、各リソース上でのユーザー優先度に従ってチャネルプロキシユニットによって割り当てられるので、ユーザーの周波数選択性向上を改善することができる。
【０２０１】
図１６は、本発明の実施形態２に係るＵＥプロキシユニットの構造の概略図である。図１６に示されるように、図１５に示される装置に基づいて、本実施形態の装置１６００は更に、優先度計算モジュール１５を有してよい。優先度計算モジュール１５は、リソース割当てリクエストがチャネルプロキシユニットに送信される前に、リソースのサブバンドＣＱＩに従って、申請中の各リソース上のユーザー優先度を計算し、申請中の各リソース上のユーザー優先度についての情報をリソース割当てリクエストに追加するように構成されてよい。
【０２０２】
更に、リソースはＲＢ又はＲＢＧであってよい。
【０２０３】
更に、リソース選択モジュール１３は、具体的には、
必要なＲＢリソースの数に従って、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソースから、ＲＢリソースの少なくとも１つのセグメントを選択するように構成されてよい。それによって、ＵＥプロキシユニットはＲＢリソースのセグメントを取得する。ＲＢリソースのセグメントは、１つのＲＢリソース又は複数の連続したＲＢリソースを含む。又は、
必要なＲＢＧリソースの数に従って、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソースから、ＲＢＧリソースの少なくとも１つのセグメントを選択するように構成されてよい。それによって、ＵＥプロキシユニットはＲＢＧリソースの１つ又は２つのセグメントを取得する。ＲＢＧリソースのセグメントは、１つのＲＢＧリソース又は複数の連続したＲＢＧリソースを含む。
【０２０４】
更に、本実施形態の装置は更に、リソース解放モジュール１６を有してよい。
【０２０５】
リソース解放モジュール１６は、リソース利用結果フィードバック情報がチャネルプロキシユニットに送信された後、割り当てられたリソースの数が所定の値より小さい場合、割り当てられたリソースを解放するように構成されてよい。
【０２０６】
更に、本実施形態の装置は更に、第１の状態決定モジュール１７及び第１の申請リソース決定モジュール１８を有してよい。
【０２０７】
第１の状態決定モジュール１７は、リソース割当てリクエストがチャネルプロキシユニットに送信される前に、現在のリソース割当て状態を決定するように構成されてよい。リソース割当て状態は、リソースが割り当てられていないこと、又はＲＢリソースの１つのＲＢリソースが取得されたことを含む。
【０２０８】
第１の申請リソース決定モジュール１８は、現在のリソース割当て状態に従って、申請中のリソースセットを決定するように構成されてよい。
【０２０９】
更に、第１の申請リソース決定モジュール１８は、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、申請中のリソースセットが少なくとも１つのＲＢリソース又は少なくとも１つのＲＢＧリソースであると決定するか、又は、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、申請中のリソースセットが、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースであることを決定するように構成されてよい。
【０２１０】
これに応じて、リソース選択モジュール１３は第１の選択ユニット１３１を有してよい。第１の選択ユニット１３１は、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、ＲＢリソースの１つのセグメント又はＲＢＧリソースの１つ又は２つのセグメントを選択するか、又は、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、チャネルプロキシユニットがＵＥプロキシユニットに割り当てたリソース情報に従って、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースを選択するように構成されてよい。
【０２１１】
第１の状態決定モジュール１７、第１の申請リソース決定モジュール１８、及び第１の選択ユニット１３１を有するリソース選択モジュール１３の上述の設置により、本実施形態のユーザープロキシモジュールをＬＴＥ  Ｒ８の通信システムに適したものにすることができる。
【０２１２】
更に、本実施形態の装置は更に、第２の状態決定モジュール１９及び第２の申請リソース決定モジュール１０１０を有してよい。
【０２１３】
第２の状態決定モジュール１９は、リソース割当てリクエストがチャネルプロキシユニットに送信される前に、現在のリソース割当て状態を決定するように構成されてよい。リソース割当て状態は、リソースが割り当てられていないこと、ＲＢリソースの１つのＲＢリソースが取得されたこと、ＲＢＧリソースの２つのＲＢリソースが取得されたこと、又はＲＢＧリソースの１つのセグメントが取得されたことを含む。
【０２１４】
第２の申請リソース決定モジュール１０１０は、現在のリソース割当て状態に従って、申請中のリソースセットを決定するように構成されてよい。
【０２１５】
更に、第２の申請リソース決定モジュール１０１０は、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、申請中のリソースセットが少なくとも１つのＲＢリソース又は少なくとも１つのＲＢＧリソースであると決定するか、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、申請中のリソースセットが、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースであると決定するか、
現在のリソース割当て状態がＲＢＧリソースの２つのＲＢリソースが取得されたことである場合、申請中のリソースセットが、取得されたＲＢＧリソースの２つのセグメントのうち任意のＲＢＧリソースの１つのセグメントと連続するＲＢＧリソースであると決定するか、又は、
現在のリソース割当て状態がＲＢＧリソースの１つのセグメントが取得されたことである場合、申請中のリソースセットが少なくとも１つのＲＢＧリソースであるか、若しくは申請中のリソースセットが取得されたＲＢＧリソースと連続するＲＢリソースであると決定するように構成されてよい。
【０２１６】
これに対応して、リソース選択モジュール１３は第２の選択ユニット１３２を有してよい。第２の選択ユニット１３２は、具体的には、
現在のリソース割当て状態がリソースが割り当てられていないことである場合、申請中のリソースセットが、ＲＢリソースの１つのセグメント又はＲＢＧリソースの１つ若しくは２つのセグメントであると決定するか、
現在のリソース割当て状態がＲＢリソースの１つのＲＢリソースが取得されたことである場合、申請中のリソースセットが、取得されたＲＢリソースと連続するＲＢリソース又はＲＢＧリソースであると決定するか、
現在のリソース割当て状態がＲＢＧリソースの２つのＲＢリソースが取得されたことである場合、申請中のリソースセットが、取得されたＲＢＧリソースの２つのセグメントのうち任意のＲＢＧリソースの１つのセグメントと連続するＲＢＧリソースと決定するか、又は、
現在のリソース割当て状態がＲＢＧリソースの１つのセグメントが取得されたことである場合、申請中のリソースセットがＲＢＧリソースの１つのセグメントであるか、若しくは申請中のリソースセットが取得されたＲＢＧリソースと連続するＲＢリソースであると決定するように構成されてよい。
【０２１７】
第２の状態決定モジュール１９、第２の申請リソース決定モジュール１０１０及び第２の選択ユニット１３２を有するリソース選択モジュール１３の上述の設置により、本実施形態のユーザープロキシモジュールをＬＴＥ  Ｒ１０の通信システムに適したものにすることができる。
【０２１８】
本実施形態のＵＥプロキシユニットは、図１０〜図１２のいずれか１つの方法実施形態に記載の技術的解決策と、対応して図１４のＵＥプロキシユニットによって実行される技術的解決策とを実行するように構成されてよく、実施原理及び技術的効果は類似するので、ここでは説明を省略する。
【０２１９】
図１７は、本発明の実施形態１に係るチャネルプロキシユニットの構造の概略図である。図１７に示されるように、本実施形態の装置１７００は、リクエスト受信モジュール２１、リソース割当てモジュール２２、許可送信モジュール２３及びフィードバック受信モジュール２４を有してよい。
【０２２０】
リクエスト受信モジュール２１は、少なくとも２つのＵＥプロキシユニットによって送信されるリソース割当てリクエストを受信するように構成されてよい。リソース割当てリクエストは申請中のリソースセットを含み、リソースセットは少なくとも１つのリソースを含む。
【０２２１】
リソース割当てモジュール２２は、少なくとも２つのＵＥプロキシユニットが申請するリソースセットの中に少なくとも１つの競合リソースが存在する場合、各競合リソースについてリソース競合解決ポリシーを用いて、リソース割当てを実行するように構成されてよい。
【０２２２】
許可送信モジュール２３は、リソース利用許可をＵＥプロキシユニットに送信するように構成されてよい。リソース利用許可は、ＵＥプロキシユニットに割り当てられたリソース情報を搬送する。
【０２２３】
フィードバック受信モジュール２４は、ＵＥプロキシユニットによって送信されたリソース利用結果フィードバック情報を受信するように構成されてよい。フィードバック情報は、ＵＥプロキシユニットがリソース情報に従って利用するリソースの少なくとも１つのセグメントを搬送する。リソースの少なくとも１つのセグメントは、１つのリソース又は複数の連続したリソースを含む。
【０２２４】
更に、リソースはＲＢ又はＲＢＧであってよい。
【０２２５】
本実施形態のチャネルプロキシユニットは、図１３に示される方法実施形態に記載の技術的解決策と、対応して図１４のチャネルプロキシユニットによって実行される技術的解決策とを実行するように構成されてよく、対応する機能モジュールを有し、その実施原理及び技術的効果は類似するので、ここでは説明を省略する。本実施形態の装置では、リクエスト受信モジュールが少なくとも２つのＵＥプロキシユニットによって送信されるリソース割当てリクエストを受信し、リソース割当てモジュールが各競合リソースについてリソース競合解決ポリシーを用いてリソース割当てを行って、リソース割当てを実現し、許可送信モジュールがリソース利用許可を対応するＵＥプロキシユニットに送信し、フィードバック受信モジュールがＵＥプロキシユニットによって送信されるリソース利用結果フィードバック情報を受信して、リソース割当てを完了する。リソース割当てモジュールは各競合リソースについて競合解決ポリシーを用いて割当てを行うので、各競合リソース上でのユーザー優先度を考慮することができ、ユーザーの周波数選択性向上を改善することができる。
【０２２６】
更に、上述の実施形態では、少なくとも２つのＵＥプロキシユニットによって送信されリクエスト受信モジュール２１によって受信されるリソース割当てリクエストは、更に、ＵＥプロキシユニットの申請されている各リソース上でのユーザー優先度についての情報を搬送してよい。
【０２２７】
更に、リソース割当てモジュール２２は、具体的には、
任意の１つの競合リソースについて、ユーザー優先度の最も高いＵＥプロキシユニットにリソースを割り当てるように構成されてよく、又は、
任意の１つの競合リソースについて、リソースを申請した少なくとも２つのＵＥプロキシユニットのうち、割り当てられたリソースが競合リソースと連続するＵＥプロキシユニットにリソースを割り当てるように構成されてよい。
【０２２８】
更に、リソース割当てモジュール２２は更に、
任意の１つの競合リソースについて、リソースに割り当てられた第１のＵＥプロキシユニットのユーザー優先度が第２のＵＥプロキシユニットのユーザー優先度よりも高く、第１のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続せず、第２のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続する場合、第２のＵＥプロキシユニットにリソースを割り当てるように構成されてよい。
【０２２９】
代替として、リソース割当てモジュール２２は更に、
任意の１つの競合リソースについて、リソースに割り当てられた第１のＵＥプロキシユニットのユーザー優先度が第２のＵＥプロキシユニットのユーザー優先度よりも高く、第１のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続し、第２のＵＥプロキシユニットの割り当てられたリソースが競合リソースと連続する場合、第１のＵＥプロキシユニットにリソースを割り当てるように構成されてよい。
【０２３０】
図１８は、本発明の実施形態１に係るリソース割当て装置の構造の概略図である。リソース割当て装置は基地局に設けられてよく、或いは基地局自体であってよい。図１８に示されるように、本実施形態のリソース割当て装置１８００は、本発明の任意の実施形態に係るＵＥプロキシユニットと、本発明の任意の実施形態に係るチャネルプロキシユニットとを有してよい。
【０２３１】
図１９は、本発明の実施形態に係るリソース割当てシステムの構造の概略図である。図１９に示されるように、本実施形態のシステムは、複数のＵＥと、複数のＵＥにリソースを割り当てるように構成される、本発明の任意の実施形態に示されるリソース割当て装置とを備える。
【０２３２】
当業者であれば、方法実施形態のステップの全部又は一部がプログラム命令関連ハードウェアによって実現されてよいことが理解できるであろう。上述のプログラムはコンピューター可読記憶媒体に格納されてよい。プログラムの実行時、方法実施形態のステップが実行される。上述の記憶媒体は、ＲＯＭ、ＲＡＭ、磁気ディスク、光学ディスク等の、プログラムコードを格納可能な任意の媒体を含む。
【０２３３】
最後に、留意すべきこととして、上述の実施形態は、本発明の技術的解決策を説明することを意図するものに過ぎず、本発明の限定を意図するものではない。上述の実施形態を参照して本発明を詳細に説明したが、当業者であれば、本発明の実施形態の技術的解決策の範囲から逸脱することなく、上述の実施形態に記載の技術的解決策に対して更に変更を行えること、或いは、それらの技術的特徴の一部又は全部に対して均等な置換を行えることが理解できるはずである。
【図１】
0006271019.tif 000004
【図２】
0006271019.tif 000005
【図３】
0006271019.tif 000006
【図４】
0006271019.tif 000007
【図５】
0006271019.tif 000008
【図６】
0006271019.tif 000009
【図７】
0006271019.tif 000010
【図８】
0006271019.tif 000011
【図９】
0006271019.tif 000012
【図１０】
0006271019.tif 000013
【図１１】
0006271019.tif 000014
【図１２】
0006271019.tif 000015
【図１３】
0006271019.tif 000016
【図１４】
0006271019.tif 000017
【図１５】
0006271019.tif 000018
【図１６】
0006271019.tif 000019
【図１７】
0006271019.tif 000020
【図１８】
0006271019.tif 000021
【図１９】
0006271019.tif 000022