特許 6259077 リソース状態取得方法、装置及びシステム並びにコンピュータ記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6259077

(24)【登録日】2017年12月15日

(45)【発行日】2018年1月10日

(54)【発明の名称】リソース状態取得方法、装置及びシステム並びにコンピュータ記憶媒体

(51)【国際特許分類】

   H04W 16/02 20090101AFI20171227BHJP

   H04W 92/20 20090101ALI20171227BHJP

   H04W 24/02 20090101ALI20171227BHJP

【ＦＩ】

   H04W16/02

   H04W92/20

   H04W24/02

【請求項の数】11

【全頁数】15

(21)【出願番号】特願2016-522806(P2016-522806)

(86)(22)【出願日】2014年5月8日

(65)【公表番号】特表2016-539543(P2016-539543A)

(43)【公表日】2016年12月15日

(86)【国際出願番号】CN2014077065

(87)【国際公開番号】WO2014180330

(87)【国際公開日】20141113

【審査請求日】2016年6月1日

(31)【優先権主張番号】201310495205.7

(32)【優先日】2013年10月18日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】511207729

【氏名又は名称】ゼットティーイー コーポレイション

(74)【代理人】

【識別番号】110001427

【氏名又は名称】特許業務法人前田特許事務所

(72)【発明者】

【氏名】ゲン ティエン

【審査官】 横田 有光

(56)【参考文献】

【文献】 米国特許出願公開第２０１１／０２４９６４２（ＵＳ，Ａ１）

【文献】 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (R-UTRAN); X2 application protocol (X2AP) (Release 10)，3GPP TS 36.423 V10.7.0（2013-09），２０１３年 ９月１９日，pp.24-26,39-42

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

リソース状態取得方法であって、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを、第１の基地局、又は前記第１の基地局のリソース状態レポート要求メッセージを取得した中継又は制御設備から受信するステップと、
前記ベーシックリソース情報に基づいて前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定し、前記第２の基地局が前記ベーシックリソースを提供できない場合、リソース状態失敗メッセージを、前記第１の基地局、又は前記第１の基地局に情報を送信できる中継又は制御設備に
送信するステップと、を含む、前記リソース状態取得方法。

【請求項2】

前記リソース状態レポート要求メッセージは、前記第２の基地局による提供が必要な要求リソースを表示するための要求リソースのタイプ情報を更に含み、
前記ベーシックリソース情報は、各前記要求リソースが前記ベーシックリソースであるか否かをマークする指示情報である
請求項１に記載のリソース状態取得方法。

【請求項3】

前記要求リソースのタイプ情報は第１のビットマップであり、
ベーシックリソース指示情報は、第１のビットマップと同じビット数を持つ第２のビットマップであり、
前記第２のビットマップは、前記第１のビットマップとの所定のマッピング関係に基づいて、前記ベーシックリソースに対応するビットにマークをつける
請求項２に記載のリソース状態取得方法。

【請求項4】

前記ベーシックリソースは、物理的リソース、トランスポートネットワーク層ロードリソース、ハードウェアロードリソース、ブランクサブフレーム及び複合利用可能なリソースのうちのいずれか１種または複数種である
請求項１乃至３のいずれか一項に記載のリソース状態取得方法。

【請求項5】

リソース状態取得方法であって、
第１の基地局が、第２の基地局に、前記第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを送信するステップと、
前記第２の基地局が、前記第１の基地局により送信された前記リソース状態レポート要求メッセージを受信するステップと、
前記第２の基地局が、前記リソース状態レポート要求メッセージに基づいて前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定するステップと、
前記第２の基地局が、前記ベーシックリソースを提供できない場合、前記第１の基地局にリソース状態失敗メッセージを送信するステップと、を含む、前記リソース状態取得方法。

【請求項6】

リソース状態取得装置であって、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを、第１の基地局、又は前記第１の基地局のリソース状態レポート要求メッセージを取得した中継又は制御設備から受信するように構成される受信ユニットと、
前記ベーシックリソース情報に基づいて第２の基地局が前記ベーシックリソースを提供できるか否かを判定するように構成される判定ユニットと、
第２の基地局が前記ベーシックリソースを提供できない場合、リソース状態失敗メッセージを、前記第１の基地局、又は前記第１の基地局に情報を送信できる中継又は制御設備に送信するように構成される送信ユニットと、を備える、前記リソース状態取得装置。

【請求項7】

前記リソース状態レポート要求メッセージは、第２の基地局による提供が必要な要求リソースを表示するための要求リソースのタイプ情報を更に含み、
前記ベーシックリソース情報は、各前記要求リソースが前記ベーシックリソースであるか否かをマークする指示情報である
請求項６に記載のリソース状態取得装置。

【請求項8】

前記要求リソースのタイプ情報は第１のビットマップであり、
ベーシックリソース指示情報は、第１のビットマップと同じビット数を持つ第２のビットマップであり、
前記第２のビットマップは、前記第１のビットマップとの所定のマッピング関係に基づいて、前記ベーシックリソースに対応するビットにマークをつける
請求項７に記載のリソース状態取得装置。

【請求項9】

前記ベーシックリソースは、物理リソースブロック物理的リソース、トランスポートネットワーク層ロードリソース、ハードウェアロードリソース、ブランクサブフレーム及び複合利用可能なリソースのうちのいずれか１種または複数種である
請求項６乃至８のいずれか一項に記載のリソース状態取得装置。

【請求項10】

リソース状態取得システムであって、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを送信するように構成される第１の基地局と、
前記リソース状態レポート要求メッセージを受信し、前記ベーシックリソースを提供できるか否かを判定し、前記ベーシックリソースを提供できない場合、前記第１の基地局にリソース状態失敗メッセージを送信するように構成される第２の基地局とを備える、前記リソース状態取得システム。

【請求項11】

コンピュータ記憶媒体であって、
請求項１乃至５のいずれか一項に記載の方法を実行するためのコンピュータ実行可能な命令を記憶している、前記コンピュータ記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は移動通信分野における情報取得技術に関し、特にリソース状態取得方法、装置及びシステム並びにコンピュータ記憶媒体に関する。

【背景技術】

【0002】

長期進化型（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）通信技術において、進化型基地局（ｅＮＢ：ｅｎｖｏｌｖｅｄ Ｎｏｄｅ Ｂａｓｅ）間の負荷バランスを実現するために、リソース状態レポートを導入している。具体的には、リソース状態レポートの導入を通じて、隣接するｅＮＢの間で各自の負荷状況を交流させることで、負荷が比較的高いｅＮＢを負荷バランスのソース基地局とし、負荷が比較的低いｅＮＢを負荷転移のターゲット基地局とし、ソース基地局における転移に適した負荷をソースｅＮＢからターゲットｅＮＢに移動させることによって、負荷バランスを実現する。

【0003】

従来技術では、リソース状態レポート取得の過程において、要求リソースの一部又は全部が利用可能な場合、応答側ｅＮＢから要求側ｅＮＢにリソース状態応答情報を送信し、要求側ｅＮＢは応答メッセージに基づいて後続の負荷バランスの決定を行う。

【0004】

負荷バランスを実現させる過程において、要求側ｅＮＢが要求したリソースには、負荷バランスを行う際に使用しなければならないベーシックリソースもあれば、選択可能なリソースもある。応答側のｅＮＢにベーシックリソースが不足している場合、要求側ｅＮＢから応答側ｅＮＢへの負荷バランスの効果が非常に悪い、またはまったくバランスを実現できないような状況が生じる。

【0005】

従来技術では、応答側ｅＮＢがベーシックリソースの一部又は全部を提供できず、選択可能なリソースの一部を提供できる場合、応答側ｅＮＢは依然として要求側ｅＮＢにリソース状態応答情報を回答する。こうすると、要求側ｅＮＢが引き続き負荷バランスの決定を行い、要求側ｅＮＢの負荷がさらに重くなる。

【発明の概要】

【発明が解決しようとする課題】

【0006】

これを鑑みて、本発明の目的は、応答側ｅＮＢがベーシックリソースを提供できない場合に、更なる要求側ｅＮＢの負荷増大を回避できるリソース状態取得方法、装置、システム並びにコンピュータ記憶媒体を提供することにある。

【課題を解決するための手段】

【0007】

上記目的を達するために、本発明の実施例は、以下のような技術案により実現される。

【0008】

本発明の実施例は、リソース状態取得方法を提供し、前記方法は、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを受信するステップと、
前記ベーシックリソース情報に基づいて前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定し、前記第２の基地局が前記ベーシックリソースを提供できない場合、リソース状態失敗メッセージを送信するステップと、を含む。

【0009】

好ましくは、前記リソース状態レポート要求メッセージは、第２の基地局による提供が必要な要求リソースを表示するための要求リソースのタイプ情報を更に含み、
前記ベーシックリソース情報は、各前記要求リソースがベーシックリソースであるか否かを示すための指示情報である。

【0010】

好ましくは、前記要求リソースのタイプ情報は第１のビットマップであり、
前記ベーシックリソース指示情報は、第１のビットマップと同じビット数を持つ第２のビットマップであり、
前記第２のビットマップは、前記第１のビットマップとの所定のマッピング関係に基づいて、前記ベーシックリソースに対応するビットにマークをつける。

【0011】

好ましくは、前記ベーシックリソースは、物理的リソース、トランスポートネットワーク層ロードリソース、ハードウェアロードリソース、ブランクサブフレーム及び複合利用可能なリソースのうちのいずれか１種または複数種である。

【0012】

本発明の実施例は、リソース状態取得方法を提供し、前記方法は、
第１の基地局が、第２の基地局に、前記第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを送信するステップと、
第２の基地局が、前記第１の基地局により送信された前記リソース状態レポート要求メッセージを受信するステップと、
前記第２の基地局が、前記リソース状態レポート要求メッセージに基づいて前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定するステップと、
前記第２の基地局が、前記ベーシックリソースを提供できない場合、前記第１の基地局にリソース状態失敗メッセージを送信するステップと、を含む。

【0013】

本発明の実施例は、リソース状態取得装置を提供し、前記装置は、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを受信するように構成される受信ユニットと、
前記ベーシックリソース情報に基づいて第２の基地局が前記ベーシックリソースを提供できる否かを判定するように構成される判定ユニットと、
第２の基地局が前記ベーシックリソースを提供できない場合、リソース状態失敗メッセージを送信するように構成される送信ユニットと、を備える。

【0014】

好ましくは、前記リソース状態レポート要求メッセージは、第２の基地局による提供が必要な要求リソースを表示するための要求リソースのタイプ情報を更に含み、
前記ベーシックリソース情報は、各前記要求リソースがベーシックリソースであるか否かを示すための指示情報である。

【0015】

好ましくは、前記要求リソースのタイプ情報は第１のビットマップであり、
前記ベーシックリソース指示情報は、第 １ のビットマップと同じビット数を持つ第２のビットマップであり、
前記第２のビットマップは、前記第１のビットマップとの所定のマッピング関係に基づいて、前記ベーシックリソースに対応するビットにマークをつける。

【0016】

好ましくは、前記ベーシックリソースは、物理リソースブロック物理的リソース、トランスポートネットワーク層ロードリソース、ハードウェアロードリソース、ブランクサブフレーム及び複合利用可能なリソースのうちのいずれか１種または複数種である。

【0017】

本発明の実施例は、リソース状態取得システムを提供し、前記システムは、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを送信するように構成される第１の基地局と、
前記リソース状態レポート要求メッセージを受信し、前記ベーシックリソースを提供できるか否かを判定し、前記ベーシックリソースを提供できない場合、前記第１の基地局にリソース状態失敗メッセージを送信するように構成される第２の基地局と、を含む。

【0018】

本発明の実施例は、コンピュータ記憶媒体を更に提供し、前記コンピュータ記憶媒体は、上記任意の技術案に記載のリソース状態取得方法を実行するためのコンピュータ実行可能な命令を記憶している。

【0019】

本発明の実施例に記載のリソース状態取得方法、装置、システム並びにコンピュータ記憶媒体によれば、以下のような有益な効果が得られる。即ち、
本発明の実施例に記載のリソース状態取得方法、装置、システム並びにコンピュータ記憶媒体は、要求側ｅＮＢとしての第１の基地局がリソース状態レポート要求メッセージにベーシックリソース情報を加え、応答側ｅＮＢとしての第２の基地局が、要求メッセージを受信した後、まず第１の基地局が所要のベーシックリソースを提供できるか否かの判定を行い、ベーシックリソースを提供できない場合、第２の基地局が直接リソース状態失敗メッセージを送信し、後続のステップを行わない。従来方法と比べて、本発明の実施例に記載の方法によれば、第２の基地局がベーシックリソースを提供できない場合、依然として第１の基地局にリソース状態応答情報を送信し、第１の基地局の負荷バランスが予期効果に達することができないとともに、リソース状態の取得及び負荷バランスの作業による負荷が一層重くなる問題を回避するとともに、第２の基地局がリソース状態の取得を行う際の無意味な操作を回避することできる。

【図面の簡単な説明】

【0020】

【図1】図１は、本発明の実施例一に係るリソース状態取得方法のフローチャートである。

【図2a】図２ａは、本発明の実施例二に係る要求リソースのタイプ情報に対応する第１のビットマップである。

【図2b】図２ｂは、本発明の実施例二に係るベーシックリソース情報に対応する第２のビットマップである。

【図3】図３は、本発明の実施例三に係るリソース状態取得方法のフローチャートである。

【図4】図４は、本発明の実施例四に係るリソース状態取得方法のフローチャートである。

【図5】図５は、本発明の実施例五に係るリソース状態取得装置の構成を示す図である。

【図6】図６は、本発明の実施例六に係るリソース状態取得システムの構成を示す図である。

【発明を実施するための形態】

【0021】

以下、図面と結合して本発明の最適的な実施例について詳しく説明し、以下で説明された最適的な実施例は、本発明への説明と解釈のみに用いられ、本発明を限定するものではないことを理解しなければならない。

【0022】

実施例一：
図１に示すように、本実施例に記載のリソース状態取得方法は、以下のステップを含む。即ち、
Ｓ１１０：第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを受信する。

【0023】

Ｓ１２０：前記ベーシックリソース情報に基づいて前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定し、前記第２の基地局が前記ベーシックリソースを提供できない場合、第２の基地局リソース状態失敗メッセージを送信する。

【0024】

ステップＳ１１０において、前記リソース状態レポート要求メッセージは、第１の基地局により送信されたものであってもよく、第１の基地局リソース状態レポート要求メッセージを取得した管理または中継設備（例えば、ネットワークの管理設備）により送信されたものであってもよい。

【0025】

前記ステップＳ１２０において、前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定する実行主体は、第２の基地局自身であってもよく、前記第２の基地局を管理するネットワークの管理設備であってもよく、例えば、具体的な判定方法は、従来方法のいずれか１つであってもよい。例えば、第２の基地局が第２の基地局の現在使用リソース量を統計し、全部のリソースと現在使用リソース量との差または事前に設定した関数関係に基づいて提供可能なリソースを計算し、ベーシックリソースの所要量を満たすか否かを判定することで、対応するベーシックリソースを提供できるか否かの判定を実現できる。

【0026】

前記ステップＳ１２０において、前記リソース状態失敗メッセージは、事前に記憶されるものであってもよく、動的に生成されたものであってもよい。前記第２の基地局が、前記リソース状態失敗メッセージを直接要求側としての第１の基地局に送信してもよく、第１の基地局に情報を送信できる中継又は制御設備に送信して、中継又は制御設備が第１の基地局に送信してもよい。前記中継又は制御設備は、例えば、ネットワークの管理設備である。

【0027】

本実施例に記載の前記的リソース状態取得方法は、従来方法と比べて、まず応答側としての第２の基地局が、要求側としての第１の基地局に今回のリソース状態取得方法に使用しなければならないベーシックリソースを提供できるか否かを判定し、提供できない場合、第２の基地局が無線インターフェースを通じて第１の基地局に直接リソース状態失敗メッセージを送信することができる。これによって、第２の基地局がベーシックリソースを提供できない場合、依然としてリソース状態応答情報を送信するため、要求側の第１の基地局が負荷バランスを行う決定を実行し続くのを防止することで、第１の基地局の負荷を減少させる。同時に、第２の基地局がベーシックリソースも提供できない状態で、第２の基地局が依然として全ての要求リソースに対して提供できるか否かの判定を行うことを回避でき、これによって、リソース状態取得方法を同期に最適化した。

【0028】

なお、前記ステップＳ１２０において、第２の基地局が、第１の基地局が所要の全てのベーシックリソースを提供できると判定した場合、従来方法のリソース状態取得方法におけるステップを利用して続行することで、更に第２の基地局に対するリソース状態の取得を完了する。

【0029】

本実施例において、前記的ベーシックリソースは、物理的リソース、トランスポートネットワーク層ロードリソース、ハードウェアロードリソース、ブランクサブフレーム及び複合利用可能なリソースのうちのいずれか１種または複数種であってもよい。前記ベーシックリソースが上記リソースのうちのどの一種であるかは、具体的に第１の基地局が第２の基地局に対してバランスを行う負荷のタイプによって決められる。

【0030】

実施例二：
本実施例に係るリソース状態取得方法は、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを受信するステップと、
前記ベーシックリソース情報に基づいて前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定し、前記第２の基地局が前記ベーシックリソースを提供できない場合、リソース状態失敗メッセージを送信するステップと、を含む。

【0031】

具体的な実施過程において、前記リソース状態レポート要求メッセージに追加された前記ベーシックリソース情報は、各種形態のデータ構造で説明することができる。本実施例において、従来技術とのよりよく互換性をために、できるだけ前記ベーシックリソース情報の表示を簡略化し、以下の方式を採用する。即ち、
前記リソース状態レポート要求メッセージは、第２の基地局による提供が必要な要求リソースを表示するための要求リソースのタイプ情報を更に含み、前記ベーシックリソース情報は、各前記要求リソースがベーシックリソースであるか否かをマークする指示情報である。

【0032】

要求リソースのタイプ情報とベーシックリソース情報の実現方式は、いずれも複数種である。本実施例において、従来技術における要求リソースのタイプ情報と結合して、指示情報で要求リソースがベーシックリソースであるか否かを示すことで、リソース状態レポート要求メッセージを簡略化し、前記リソース状態レポート要求メッセージには同じ要求リソースを示す情報が２回以上出現することを回避し、それによって、リソース状態レポート要求メッセージのデータ量を減らすとともに、現在のリソース状態レポート要求メッセージのデータ構造に対する変更が少なく、簡単な操作を実現できる。

【0033】

本実施例において、要求リソースメッセージとベーシックリソース情報との結合表示方法に関し、その具体的な実現方式は複数種がある。本実施例において、更に要求リソースメッセージとベーシックリソース情報との好ましい結合表示方法を提出し、具体的には、以下の通りである。即ち、
前記要求リソースのタイプ情報は第１のビットマップであり、
前記ベーシックリソース指示情報は、第１のビットマップと同じビット数を持つ第２のビットマップであり、
前記第２のビットマップは、前記第１のビットマップとの所定のマッピング関係に基づいて、前記ベーシックリソースに対応するビットにマークをつける。

【0034】

具体的には、図２ａは、要求リソースのタイプ情報に対応する第１のビットマップ１１０を示しており、前記第１のビットマップは、いくつかのビットを含み、具体的には３２ビット又は６４ビットであり、第１のビットマップにおける１ビット又は複数組ビットは、リソースが要求リソースであるか否かを示す。

【0035】

本実施例において、第１ビット１１１は、物理的リソースが要求リソースであるか否かを示すためのものであり、第２ビット１１２は、トランスポートネットワーク層ロードリソースが要求リソースであるか否かを示すためのものであり、第三ビット１１３は、ハードウェアロードリソースが要求リソースであるか否かを示すためのものであり、第四ビット１１４は、複合利用可能なリソースが要求リソースであるか否かを示すためのものであり、第五ビット１１５は、ブランクサブフレームが要求リソースであるか否かを示すためのものである。１１６は、残されたビットであり、他のリソースが要求リソースであるか否かを示すためのものである。

【0036】

ビット１１１から１１６のいずれか１ビットを１と記す場合、当該ビットに対応するリソースが要求リソースであることを示し、そうでない場合は、当該ビットに対応するリソースは非要求リソースであり、または、対応するビットを０と記す場合、当該ビットに対応するリソースが要求リソースであることを示し、そうでない場合は、当該ビットに対応するリソースは非要求リソースである。具体的に上記２種のうちのどの指示方法を採用するかは、ニーズに応じて設定することができる。

【0037】

図２ｂは、具体的にベーシックリソース情報に対応する第２のビットマップ１２０を示しており、前記第２のビットマップ１２０と前記第１のビットマップ１１０は、同じビット数を含むビットマップである。第１のビットマップ１１０において、１ビット又は複数組ビットは、リソースが要求リソースであるか否かを示すが、第２のビットマップにおいて、１ビット又は複数組ビットは、要求リソースがベーシックリソースであるか否かを示すためのものである。本実施例において、第１ビット１２１は、物理的リソースがベーシックリソースであるか否かを示すためのものであり、第２ビット１２２は、トランスポートネットワーク層ロードリソースがベーシックリソースであるか否かを示すためのものであり、第三ビット１２３は、ハードウェアロードリソースがベーシックリソースであるか否かを示すためのものであり、第四ビット１２４は、複合利用可能なリソースがベーシックリソースであるか否かを示すためのものであり、第五ビット１２５は、示ブランクサブフレームがベーシックリソースであるか否かを示すためのものである。１２６は、残されたビットであり、他のリソースが要求リソースであるか否かを示すためのものである。

【0038】

ビット１２１から１２６のいずれか１ビットが１である場合、当該ビットに対応する要求リソースベーシックリソースであることを示し、そうでない場合は、当該ビットに対応するリソースは非要求リソースであり、または、対応するビットが０である場合、当該ビットに対応する要求リソースがベーシックリソースであることを示し、そうでない場合は、当該ビットに対応するリソースは非ベーシックリソースである。具体的に上記２種のうちのどの指示方法を採用するかは、ニーズに応じて設定することができる。

【0039】

本実施例において、前記第１のビットマップ１１０と前記第２のビットマップ１２０との間で採用した所定のマッピング関係は、同じ位置のビットの１対１の関係であり、具体的な実現過程において、他の関数関係（例えば、ハッシュ関数）を採用してマッピング関係を表す。本実施例において、前記マッピング関係が簡単且つ明瞭であり、従来技術に対する変更が小さいため、簡単に実現できる。

【0040】

実施例三：
図３に示すように、本実施例リソース状態取得方法は、以下のステップを含む。即ち、
Ｓ２１０：第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを受信する。

【0041】

ステップＳ２２０：前記ベーシックリソース情報に基づいて前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定し、Ｙｅｓの場合は、ステップＳ２３０に入り、Ｎｏの場合は、ステップＳ２５０に入る。

【0042】

前記ステップＳ２３０：前記第２の基地局が前記リソース状態レポート要求メッセージにおいて要求している要求リソースの全てを提供できるか否かを判定し、Ｎｏの場合は、ステップＳ２４０に入り、Ｙｅｓの場合は、ステップＳ２６０に入る。

【0043】

前記ステップＳ２４０：前記第２の基地局がベーシックリソース以外の前記要求リソースの一部を提供できるか否かを判定し、Ｙｅｓの場合は、ステップＳ２６０に入り、Ｎｏの場合は、ステップＳ２５０に入る。具体的な実現過程において、ステップＳ２４０を実行する前に、前記リソース状態レポート要求メッセージには「測定対象の一部が取得に成功することを許可する指示」が含まれているか否かを判定することを更に含み、前記測定対象は、前記要求リソースに対応する。上記「測定対象の一部が取得に成功することを許可する指示」が含まれ、且つ指示が許可される場合にのみ、前記ステップＳ２４０に入ることができ、そうでない場合は、流れを完了させるか、または他の対応する流れに移る。

【0044】

ステップＳ２５０：前記第２の基地局にリソース状態失敗メッセージを送信する。

【0045】

ステップＳ２６０：前記第２の基地局にリソース状態応答情報を送信する。

【0046】

前記ステップＳ２１０が受信したリソース状態レポート要求メッセージは、要求側の第１の基地局から送信されてもよい。

【0047】

前記ステップＳ２５０及び前記ステップＳ２６０の実行主体は、いずれも応答側としての第２の基地局であってもよく、前記リソース状態失敗メッセージ及び前記リソース状態応答情報は、要求側としての第１の基地局に直接送信されてもよい。

【0048】

本実施例において、ステップＳ２２０において、まず第２の基地局がベーシックリソースを提供できるか否かを判定して、提供できる場合は、後続のステップＳ２３０及びステップＳ２４０を実行し、提供できない場合は、直接ステップＳ２５０に入る。こうすることで、直接要求リソースの一部を提供できるか否かを判定し、更に、第１の基地局にリソース状態応答情報を送信するため、第１の基地局が負荷バランスを実現できない状況で、負荷が一層重くなる問題を有効的に回避することができる。

【0049】

実施例一から実施例三において、前記方法は、さらに前記第１の基地局が第２の基地局により送信されたリソース状態メッセージを受信した後、リソース状態の取得の流れを完了し、または、他の失敗処理ステップに移り、または、他の処理ステップに移ることを含む。上記実施例一から実施例三に記載のリソース状態取得方法をまとめると、従来方法と比べて、応答側基地局がベーシックリソースを提供できるか否かの判定することを増加して、応答側基地局がベーシックリソースを提供できない場合、直ちにリソース状態の取得の流れを完了させることができ、リソース状態の取得の方法を最適化した。さらに重要なことは、要求側基地局は、応答側基地局がベーシックリソースを提供できない場合に、依然として負荷バランスを行う決定を実行し続き、要求側基地局の負荷が一層重くなる問題を回避する。

【0050】

実施例四：
図４に示すように、本実施例は、リソース状態取得方法を提供し、前記方法は以下のステップを含む。即ち、
ステップＳ３１０：第１の基地局が、第２の基地局に、前記第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを送信する。

【0051】

ステップＳ３２０：第２の基地局が、前記第１の基地局により送信された前記リソース状態レポート要求メッセージを受信する。

【0052】

ステップＳ３３０：前記第２の基地局が前記リソース状態レポート要求メッセージに基づいて、前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定する。

【0053】

ステップＳ３４０：前記ステップＳ３３０において、第２の基地局が前記ベーシックリソースを提供できないと判定した場合（つまり、判定結果がＮｏである場合）、前記第２の基地局が前記第１の基地局にリソース状態失敗メッセージを送信する。

【0054】

本実施例において、前記ベーシックリソースは、負荷バランスに用いられる任意のリソースであってもよく、具体的には、物理的リソース、トランスポートネットワーク層ロードリソース、ハードウェアロードリソース、ブランクサブフレーム及び複合利用可能なリソースのうちのいずれか１種または複数種であってもよい。

【0055】

なお、前記ステップＳ３３０において、第２の基地局が第１の基地局にベーシックリソースを提供できると判定した場合、従来方法のリソース状態取得方法におけるステップを採用して続行することで、更に第２の基地局に対するリソース状態の取得を完成する。

【0056】

従来技術におけるリソース状態レポート要求メッセージと比べて、本実施例におけるリソース状態取得方法は、前記リソース状態レポート要求メッセージにベーシックリソース情報を追加し設定した。前記ベーシックリソース情報を追加し設定する方法は複種であり、以下では１つの例を提供する。

【0057】

前記例は、ニーズに応じてバランスを取る必要のある負荷のタイプであり、各負荷のタイプが使用しなければならないリソースは、事前にベーシックリソースに定義してもよい。それゆえ、リソース状態レポート要求メッセージを生成する際に、負荷のタイプに基づいて対応する記憶媒体から前記ベーシックリソース情報を読み取ればよい。

【0058】

ベーシックリソース情報を追加し設定することで、第２の基地局で後続の要求リソースを提供できるか否かの判定を行う際に、まず応答側基地局がベーシックリソースを提供できるか否かの判定を行うことで、第２の基地局がベーシックリソースを提供できない状況で、第２の基地局が依然として第１の基地局にリソース状態応答情報を送信し、第１の基地局が前記応答メッセージに基づいて負荷バランスを行う決定を実行し続くことを回避できる。第１の基地局が、上記場合に、負荷バランスを行う決定を実行すると、負荷バランスが予期効果に達することができないか、または、完全に実現できなくなり、こうなると、第１の基地局の負荷が重くなり、リソース状態の取得を通じて負荷バランスを実現するとともに第１の基地局の負荷を減らす初志を裏切ることになる。

【0059】

実施例五：
図５に示すように、本実施例は、リソース状態取得装置を提供し、前記装置は、
第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソースを含むリソース状態レポート要求メッセージを受信するように構成される受信ユニット２１０と、
前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定するように構成される判定ユニット２２０と、
前記第２の基地局が前記ベーシックリソースを提供できない場合、リソース状態失敗メッセージを送信するように構成される送信ユニット２３０と、を備える。

【0060】

前記受信ユニット２１０は、無線インターフェースを含んでもよい。前記リソース状態レポート要求メッセージは、要求側の第１の基地局により送信されたものであってもよい。

【0061】

前記判定ユニット２２０の具体的な構成は、電子部品、例えば、コンパレータ、コンパレータと増幅器等の信号処理部品の組み合わせであってもよく、相応機能を実現するソフトウェアを実行するプロセッサであってもよい。前記プロセッサは、ワンチップマイクロコンピュータ、数字信号プロセッサであてもよく、プログラマブルアレイまたは中央処理装置等であってもよい。

【0062】

前記送信ユニット２３０は、有線又は無線送信装置であってもよく、例えば、送信アンテナなどである。前記リソース状態失敗メッセージは、事前に設定されたメッセージであってもよく、動的に生成されたメッセージであってもよい。前記リソース状態失敗メッセージが単に失敗を示したメッセージである場合、事前に設定して記憶してもよい。前記リソース状態失敗メッセージが、第２の基地局が対応する要求リソースを提供できない原因解析メッセージをさらに含む場合、動的に生成されてもよい。前記リソース状態失敗メッセージを事前に記憶する場合、前記リソース状態取得装置は、記憶媒体を更に含むか、または外から前記リソース状態失敗メッセージを読み取るデータインターフェースを設けることができる。前記リソース状態失敗メッセージを動的に生成する場合、前記リソース状態取得装置は、リソース状態失敗メッセージ生成ユニットを更に含むことができる。

【0063】

本実施例において、前記リソース状態取得装置は、第２の基地局における装置に集積され、第２の基地局の一部に構成されてもよく、前記第２の基地局の装置に依存せず、有線または無線の接続方法で前記第２の基地局へ接続してもよく、具体的な構成は、ニーズに応じて設定することができる。本実施例において、前記第２の基地局に集積されることが好ましい。

【0064】

リソース状態レポート要求メッセージを簡略化し、同じ要求リソースを示すメッセージが複数出現することを回避するために、上記状況に対し、本実施例において改善を行い、前記リソース状態レポート要求メッセージは、第２の基地局による提供が必要な要求リソースを表示するための要求リソースのタイプ情報を更に含み、前記ベーシックリソース情報は、それぞれの前記要求リソースがベーシックリソースであるか否かの指示情報である。

【0065】

本実施例において、ベーシックリソース情報は、各要求リソースに対応する指示情報であり、簡単に実現でき、従来技術に対する変更が少ない。

【0066】

更に、上記構成に基づいて、リソース状態レポート要求メッセージを簡略化する具体的な実現方式を提供したが、以下の実現方式に限らない
前記要求リソースのタイプ情報は第１のビットマップであり、
前記ベーシックリソース指示情報は、第１のビットマップと同じビット数を持つ第２のビットマップであり、
前記第２のビットマップは、前記第１のビットマップ所定のマッピング関係に基づいて、前記ベーシックリソースに対応するビットにマークをつける。

【0067】

前記所定のマッピング関係は、同じ位置のビットの順番に対応してもよく、関数関係を採用して交互に対応してもよく、具体的な実現過程において、第１のビットマップと第２のビットマップのシーケンシャルマッピングを採用する。シーケンシャルマッピングを採用すると、マッピング関係が簡単且つ明瞭であり、簡単に実現できる。

【0068】

本実施例において、前記ベーシックリソースは、全ての要求リソースの中のいずれか１種であり、具体的に、前記ベーシックリソースは、物理リソースブロック物理リソース、トランスポートネットワーク層ロードリソース、ハードウェアロードリソース、ブランクサブフレーム及び複合利用可能なリソースのうちのいずれか１種または複数種の組み合わせである。

【0069】

本実施例において、前記リソース状態取得装置は、負荷バランスのリソース状態レポートの取得に用いられ、第２の基地局が、自身が第１の基地局が要求したベーシックリソースが不足している状況で、第１の基地局にリソース状態応答情報を送信することを効果的に回避できる。こうすると、第１の基地局が、第２の基地局が所要のベーシックリソースを提供できない状況で負荷バランスを行う決定を実行し、第１の基地局が第２の基地局に負荷の移動できないとともに、第１の基地局がリソース状態の取得と負荷バランスによる負荷が更に重くなる問題を回避できる。

【0070】

実施例六：
図６に示すように、本実施例は、リソース状態取得システムを提供し、前記システムは、第１の基地局３１０と第２の基地局３２０とを含む。

【0071】

前記第１の基地局３１０は、第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを送信するように構成される。

【0072】

第２の基地局３２０は、前記リソース状態レポート要求メッセージを受信し、前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定し、前記第２の基地局が前記ベーシックリソースを提供できない場合、前記第１の基地局にリソース状態失敗メッセージを送信するように構成される。

【0073】

前記第１の基地局と第２の基地局との間は、無線ネットワークを通じて接続し、受信アンテナを通じてデータ伝送をすることができる。

【0074】

具体的には、前記第１の基地局３１０は、第１送信ユニット３１１を備え、前記第２の基地局３２０は、受信ユニット３２１、判定ユニット３２２及び第２送信ユニット３２３を備える。

【0075】

前記第１送信ユニット３１１は、前記受信ユニット３２１に、前記第２の基地局による提供を必須とするベーシックリソースを指示するためのベーシックリソース情報を含むリソース状態レポート要求メッセージを送信するように構成され、
前記受信ユニット３２１は、前記第１送信ユニット３１１により送信されたリソース状態レポート要求メッセージを受信するように構成され、
前記判定ユニット３２２は、前記第２の基地局が前記ベーシックリソースを提供できるか否かを判定するように構成され、
前記第２送信ユニット３２３は、前記第２の基地局が前記ベーシックリソースを提供できない場合、前記第１の基地局にリソース状態失敗メッセージを送信するように構成される。

【0076】

前記リソース状態失敗メッセージは事前に記憶されたものである場合、前記第２の基地局は、更に記憶ユニットを備えてもよい。前記リソース状態失敗メッセージは動的に生成されたものである場合、前記基地局は、更にリソース状態失敗メッセージ生成ユニットを備えてもよい。

【0077】

本実施例において、前記的リソース状態取得システムにおいて、第１の基地局３１０の第１送信ユニット３１１が送信したリソース状態レポート要求メッセージにはベーシックリソース情報が含まれ、第２の基地局３２０に、第２の基地局３２０がベーシックリソース情報に所要のベーシックリソースを提供できるか否かを判定するように構成される判定ユニットを追加し設定し、これによって、リソース状態の取得を行う際に、負荷転移失敗の処理による第１の基地局３１０の負荷が一層重くなる問題を回避できる。

【0078】

本発明の実施例は、コンピュータ記憶媒体を更に提供し、前記コンピュータ記憶媒体にはコンピュータ実行可能な命令が記憶され、前記コンピュー実行可能な命令は、実施例一乃至実施例四のうちのいずれか一つの技術案における前記リソース状態取得方法を実行することに用いられる。前記コンピュータ記憶媒体は、具体的にＵＳＢフラッシュドライブ、光ディスク又はＤＶＤ等の不揮発性の記憶媒体であってもよい。

【0079】

以上は、本発明の最適的な実施例に過ぎなく、本発明の保護範囲を限定するためのものではない。本発明の原理に基づいて行われたすべての改修が、本発明の保護範囲以内に含まれるべきである。

【図1】

【図2a】

【図2b】

【図3】

【図4】

【図5】

【図6】