JP5500174B2 - 移動通信システム、基地局装置、及び移動局装置 - Google Patents

Description

本発明は、移動通信システムに関し、特に、移動局のコネクション切替の制御に関する。

利用者宅内、オフィス内などに設置可能な小型基地局の開発が進められている。この小型基地局は、小型基地局を所有するユーザによって宅内や小規模オフィス等に設置され、ADSL（Asymmetric Digital Subscriber Line）や光ファイバ回線を用いてコアネットワーク側の上位装置と接続される。このような小型基地局は、一般的に、フェムト基地局、フェムトセル基地局、又はホーム基地局と呼ばれている。また、小型基地局が形成するセルのサイズ（カバーエリア）は、従来のマクロセルに比べて極めて小さい。このため、小型基地局が形成するセルは、フェムトセル又はホームセル等と呼ばれている。3GPP （Third Generation Partnership Project）は、このような小型基地局を Home Node B（HNB）及び Home evolved Node B（HeNB）と定義して標準化作業を進めている。HNBはUTRAN （UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network）向けの小型基地局であり、HeNBはLTE（Long Term Evolution）/ E-UTRAN (Evolved UTRAN) 向けの小型基地局である。

本明細書では、このような小型基地局をホーム基地局と呼び、ホーム基地局によって生成されるセルを"フェムトセル"と呼ぶ。なお、3GPPで検討されているUTRAN、E-UTRAN向けのホーム基地局を指す場合には、3GPPでの呼称にならって、HNB若しくはHeNB、又はこれらを総称してH(e)NBと呼ぶ。

現在、3GPP では、Release 9の検討作業が行われている。Release 9では、HNBへのInbound Mobilityが検討対象とされており、RAN ワーキンググループ２（RAN WG2）及びワーキンググループ３（RAN WG3）において活発に検討されている。ここで、Inbound Mobilityとは、マクロ基地局（Node B）によって形成されるマクロセルからフェムトセルへの移動局のセル間移動、又はフェムトセル間での移動局のセル間移動を意味する。移動局のセル間移動は、移動先セルとのコネクション（RRC connection 等）を確立し、移動元セルとのコネクションを解放する動作（以下、コネクション切替と呼ぶ）である。

Inbound Mobilityのうち特に検討の対象となっているのは、通信中のコネクション切替、つまり"ハンドオーバ"である。ハンドオーバでは、通信中の移動局のコネクション切り替えがネットワーク（UTRAN、E-UTRAN等）主導で行われる。ここで、通信中とは、WCDMA（Wideband CDMA）/UTRANであれば、基地局または基地局制御局（RNC：Radio network Controller）と移動局の間に個別チャネル（DCH：Dedicated Channel）が確立された状態（CELL_DCH状態）を意味する。また、LTE (Long Term Evolution)/E-UTRANでは、ダウンリンク及びアップリンクのシェアードチャネル（PDSCH及びPUSCH）を用いて基地局と移動局の間でデータ送受信が行われるRRC_CONNECTED状態が、"通信中"に相当する。

また、Inbound Mobilityのコネクション切替は、SRNS（Serving Radio Network Subsystem）リロケーションを伴うのが一般的である。移動前セル（ソースセル）と移動先セル（ターゲットセル）の間で無線リソース管理主体が変化するためである。UTRANのマクロセルの無線リソース管理は基地局制御局（RNC：Radio network Controller）によって行われるのに対して、UTRANのフェムトセルの無線リソース管理機能は各HNBに割り当てられている。

WCDMA/UTRANでは、CELL_DCH状態にある移動局のコネクション切替、すなわちハンドオーバ／SRNSリロケーションは、ネットワーク主導で開始される。具体的には、移動元セル（以下、ソースセルと呼ぶ）の無線リソース管理を行うRNCがハンドオーバ／SRNSリロケーションの開始を決定する。なお、HNBを使用する場合、マクロセルにおけるRNCに配置されていた無線リソース管理機能がHNBに配置されている。このため、ソースセルを生成するHNB（HNBに配置された制御装置）がハンドオーバ／SRNSリロケーションの開始を決定する。LTE/E-UTRAにおいても、RRC_CONNECTED状態にある移動局のコネクション切替は、ネットワーク主導（具体的には移動元の基地局（eNode B：evolved Node B）主導）で開始される。

3GPP RAN WG2の第66 bis回会合で提示された寄書R2-093952（非特許文献１）およびRAN WG3の第63 bis 回会合で提示された寄書R3-090802（非特許文献２）は、マクロセルからフェムトセルへのInbound Mobilityに関する提案を含んでいる。これらの寄書による提案内容は標準化の有力案として検討されている。

以下では、図５５〜５８を参照して、寄書R2-093952及びR3-090802で提案されているInbound Mobility動作について説明する。図５５及び５８は、Inbound Mobility動作の説明に使用するネットワーク構成図である。図５５は、マクロ基地局（Node B）によって生成されるマクロセル９０７からHNB９０４によって生成されるフェムトセル９０８に移動局（UE：User Equipment）９０６がコネクション切替を行う様子を示している。RNC９０２は、マクロNode B９０１とコアネットワーク（CN：Core Network）９０３との間に配置されており、マクロセル９０７の無線リソース管理、ハンドオーバ制御を含むコネクション切替の制御などを行う。

CN９０３は、回線交換局（MSC：Mobile Switching Center）、パケット交換局（SGSN：Serving GPRS Support Node）、ロケーションレジスタなどを有し、UE９０６の位置登録、UE９０６の呼び出し（ページング）、UE９０６の発信及び着信の制御、UE９０６の送信データおよび受信データの経路設定および転送処理などを行う。

HNBゲートウェイ（HNBGW）９０５は、CN９０３とHNB９０４の間に配置され、CN９０３とHNB９０４の間でユーザデータ及び制御データを中継する。

一方、図５６は、HNB９０４Ａによって生成されるフェムトセル９０８AからHNB９０４Ｂによって生成されるフェムトセル９０８ＢにUE９０６がコネクション切替を行う様子を示している。図５６の例では、HNB９０４Ａ及び９０４Ｂは、同一のHNBGW９０５に接続されている。

図５７は、図５５に示したUE９０６のInbound Mobility動作の成功例を示すシーケンス図である。図５７において、Source RANは、UEがHNBへ移動する前に接続していた移動元の無線ネットワークを意味する。つまり、ソースセルがマクロセル９０７である図５５の場合、マクロNode B９０１を管理するRNC９０２がSource RANに相当する。また、Target HNBとは、ターゲットセルを生成しているHNBを意味しており、図５５の場合、HNB９０４がTarget HNBに相当する。

ステップＳ９０１では、ソースセル（マクロセル９０７）を管理するRNC９０２とUE９０６の間にRRC（Radio Resource Control）コネクションが確立される。ステップＳ９０２では、UE９０６がターゲットセル（フェムトセル９０８）にブロードキャストされているSystem Information（具体的にはSystem Information Block type 3）を受信し、System Informationからターゲットセルのセル識別情報を取得する。ここで、セル識別情報は、CGI (Cell Global Identity)またはCI（Cell Identity）である。なお、CGIは、通信事業者の識別子であるPLMN IDとCIの組み合わせである。

ステップＳ９０３では、UE９０６は、ターゲットセル（フェムトセル９０８）のセル識別情報が付加された測定レポート（RRC Measurement Report）をSource RAN（RNC９０２）に報告する。RRC Measurement Reportは、ターゲットセルからの無線信号（P-CPICH：Primary Common Pilot Channel）の受信品質の測定結果を含む。

Source RAN（RNC９０２）は、UE９０６から受信したMeasurement Reportに基づいて、フェムトセル９０８へのハンドオーバ／SRNSリロケーションを決定し、ハンドーバ／SRNSリロケーションのためのシグナリングを開始する。具体的には、ステップＳ９０４において、RNC９０２は、RANAP: Relocation RequiredメッセージをCN９０３へ送信する。Relocation Requiredメッセージは、ターゲットセル（フェムトセル９０８）のセル識別情報とUE９０６の情報を含む。

ステップＳ９０５では、HNB９０４を管理するHNBGW９０５は、RANAP: Relocation RequestメッセージをCN９０３から受信する。Relocation Requestメッセージはターゲットセル（フェムトセル９０８）のセル識別情報とUE９０６の情報を含む。

ステップＳ９０６では、HNBGW９０５は、Relocation Requestメッセージに含まれるセル識別情報及びＵＥ情報に基づいて、UE Registration 手順を実行する。UE Registrationでは、HNB及びHNBGW間のインタフェース（Iuhインターフェース）で使用されるHNBAPメッセージを送受信可能とするために、HNB９０４とHNBGW９０５の間のRUA Connection確立に必要なContext IDが決定される。

ステップＳ９０７では、HNBGW９０５は、RUA: Connectメッセージを使用して、RANAP: Relocation RequestをHNB９０４に送信する。ステップＳ９０８では、HNB９０４は、RUA: Direct Transferメッセージを使用して、RANAP: Relocation Request AcknowledgeをHNBGW９０５に送信する。ステップＳ９０９では、HNBGW９０５は、RANAP: Relocation Request AcknowledgeメッセージをCN９０３に送信する。ステップＳ９１０では、CN９０３は、RANAP: Relocation CommitメッセージをSource RAN（RNC９０２）に送信する。最後に、ステップＳ９１１において、残りのSRNSリロケーション手順が行われる。

図５７に示したInbound Mobilityは、Release 9に準拠したUE及びRelease 9に準拠したHNB及びRNCにより達成される。具体的には、Release 8までのUEは、ターゲットセルのセル識別情報を含むRRC: Measurement Reportを送信する機能をサポートしていない。また、Release 8までのHNBは、RANAP, HNBAP, RUAプロトコルを使用してUEのコネクション切り替えをネットワーク（E-UTRAN）主導で行う手順（つまりハンドオーバ手順およびSRNSリロケーション手順）をサポートしていない。

図５８は、図５６に示したUE９０６のInbound Mobility動作の成功例を示すシーケンス図である。図５８のSource RANはHNB９０４Ａに相当し、Target HNBはHNB９０４Ｂに相当する。ここでは、図５８が図５７と相違する部分を主に説明する。図５８のステップＳ９２１〜Ｓ９２３は、Source RANはHNB９０４Ａである点を除いて、図５７のステップＳ９０１〜Ｓ９０３と同じである。

ステップＳ９２４では、Source RAN（HNB９０４Ａ）は、RANAP: Relocation Requiredを含むRUA: Direct TransferメッセージをHNBGW９０５に送信する。RANAP: Relocation Requiredには、ターゲットセル（フェムトセル９０８Ｂ）のセル識別情報とUE９０６の情報が含まれる。

ステップＳ９２５では、HNBGW９０５は、RANAP: Relocation Requiredメッセージに含まれるセル識別情報及びＵＥ情報に基づいて、UE Registration 手順を実行する。UE Registrationにより、Target HNB９０４ＢとHNBGW９０５の間のRUA Connectionが確立され、Context IDが決定される。

ステップＳ９２６及びＳ９２７は、図５７のステップＳ９０７及びＳ９０８と同様である。ステップＳ９２８では、HNBGW９０５は、RANAP: Relocation Commandメッセージを含むRUA: Direct TransferメッセージをSource RAN（HNB９０４Ａ）に送信する。最後に、ステップＳ９２９において、残りのSRNSリロケーション手順が行われる。

R2-093952 "Inbound mobility to CSG cell from UMTS cell"、[online]、3GPP、[平成21年7月18日検索]、インターネット＜URL：ftp://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_66bis/Docs/R2-093952.zip＞ R3-090802 "Discussion on Inbound Mobility from 3G Marco Cell to HNB"、[online]、3GPP、[平成21年7月18日検索]、インターネット＜URL：ftp://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_63bis/Docs/R3-090802.zip＞

上述したように、3GPP Release 9では、HNBにより生成されるフェムトセルへのInbound Mobilityがサポートされる予定である。しかし、既に市場には、3GPP Release 9よりも前のUEやHNBが存在している。これらの機器のファームウェア（制御プログラム）が3GPP Release 9対応にアップグレードされるか否かは、これらの機器を所有するユーザ次第である。特にHNBは、UEと同様に、ユーザ所有の装置（Customer Premise Equipment）である。このため、マクロNode B、RNC、及びHNBGW等の通信事業者所有の装置群がRelease 9にアップグレードされた場合にも、ユーザ所有のHNBはRelease 8のまま、言い換えるとInbound Mobilityに対応できないまま、フィールドに存在し続けることが予想される。なお、HNBは、マクロNode B、RNC、及びHNBGW等の通信事業者所有の装置群と事前調整のうえ運用されるCoordinated Methodではなく、Un-coordinated Methodによって商用展開されることが3GPPでは一般的な運用方針となっている。

本願の発明者等は、Release 9の機器とRelease 9より前（Release 8等）の機器が混在するフィールドにおいては、ソースセルにおけるコネクション切替の制御主体である制御装置（RNC、HNB等）が、成功する可能性のないコネクション切替手順、つまりハンドオーバ／SRNSリロケーション手順を開始することに伴う無駄なシグナリングが発生する問題があることを見出した。具体的に問題となるのは、UE及びソースセルのコネクション切替制御主体（RNC又はHNB）がInbound Mobilityをサポートしているにも関わらず、ターゲットセルのHNBがInbound Mobilityをサポートしていない場合である。この場合、ソースセルのコネクション切替制御主体がRANAP: Relocation Requiredメッセージをコアネットワークに送信することによってハンドオーバ／SRNSリロケーション手順を開始しても、ターゲットセルへのハンドオーバ／SRNSリロケーションは必ず失敗に終わってしまう。

図５９及び５８は、フェムトセルへのハンドオーバ／SRNSリロケーションに関して、本願の発明者等が予測した失敗例を示すシーケンス図である。図５９は、上述した図５５に対応しており、マクロセル９０７からフェムトセル９０８へのUE９０６のハンドオーバ／SRNSリロケーションに関する。Target HNB（HNB９０４）がInbound Mobilityに対応していない場合、図５９のステップＳ９４６に示すように、HNBGW９０５のUE Registrationは失敗に終わる。HNB９０４が、HNBAP: UE Registrationメッセージに対応できないためである。この結果、HNBGW９０５は、ハンドオーバ／SRNSリロケーションの失敗を示すRANAP: Relocation FailureメッセージをCN９０３に送信する。そして、Source RAN（RNC９０２）は、RANAP: Relocation Preparation Failure を受信して、ターゲットセルへのハンドオーバ／SRNSリロケーションが失敗に終わる。

図６０は、上述した図５６に対応しており、フェムトセル９０８Aからフェムトセル９０８ＢへのUE９０６のハンドオーバ／SRNSリロケーションに関する。Target HNB（HNB９０４Ｂ）がInbound Mobilityに対応していない場合、図６０のステップＳ９６５に示すように、HNBGW９０５のUE Registrationは失敗に終わる。この結果、HNBGW９０５は、ハンドオーバ／SRNSリロケーションの失敗を示すRANAP: Relocation Preparation Failureメッセージを含むRUA: Direct Transfer メッセージをSource RAN（HNB９０４Ａ）に送信する。そして、HNB９０４Ａは、RANAP: Relocation Preparation Failure を受信して、ターゲットセルへのハンドオーバ／SRNSリロケーションが失敗に終わる。

本発明は、発明者等による上述した考察に基づいてなされたものであって、成功しないコネクション切替手順を開始することに伴う無駄なシグナリングを抑制することに寄与可能な移動通信システム、基地局装置、移動局装置、制御装置、ターゲット制御装置、プログラム、プログラムが格納された非一時的なコンピュータ可読媒体、及びコネクション切替の制御方法を提供することを目的とする。

本発明の第１の態様にかかる移動通信システムは、第１及び第２の基地局、移動局、及び制御装置を有する。前記第１の基地局は、第１のセルを生成する。前記第２の基地局は、第２のセルを生成する。前記移動局は、前記第１及び第２の基地局と通信可能である。前記制御装置は、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を制御する。前記第１の基地局、前記移動局、及び前記制御装置のうち少なくとも１つは、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替に前記第２の基地局が対応できるか否かを認識できるよう構成されている。さらに、当該移動通信システムでは、前記第２の基地局のコネクション切替対応可否の認識結果に基づいて、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を前記制御装置が開始するか否かが定まる。

本発明の第２の態様にかかる基地局は、自セルを識別するセル識別情報、および前記自セルへの移動局のコネクション切替が可能か否かを示す第１の情報を含む報知情報を送信する送信部を有する。

本発明の第３の態様にかかる移動局は、無線通信部および制御部を有する。前記無線通信部は、基地局との間で無線通信を行う。前記制御部は、隣接セルからの無線信号の受信品質に関する測定レポートを前記基地局又は前記基地局を管理する制御局に対して送信するか否かを、前記隣接セル内で報知され、前記隣接セルがコネクション切替に対応できるか否かを判定可能な第１の情報の解読結果に応じて決定する。

本発明の第４の態様にかかる移動局は、基地局のセルを識別するセル識別情報、および前記基地局へのコネクション切替が可能か否かを示す第１の情報を含む報知情報を受信する受信部を有する。

本発明の第５の態様は、第１セルから第２のセルへの移動局のコネクション切替を制御する制御装置である。当該制御装置は、前記第１セルを生成する第１の基地局を経由して共に前記移動局から受信される（ａ）前記第２のセルからの無線信号の受信品質に関する測定レポート、及び（ｂ）前記第２のセルがコネクション切替に対応できるか否かを判定可能な第１の情報に基づいて、前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定するよう構成されている。

本発明の第６の態様は、第１セルから第２のセルへの移動局のコネクション切替を制御する制御装置である。当該制御装置は、前記第２のセルのコネクション切替対応可否に関する情報を記録可能な記録装置にアクセスすることによって、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定するよう構成されている。

本発明の第７の態様は、第１セルから第２のセルへの移動局のコネクション切替を制御する制御装置におけるコネクション切替の制御方法であり、以下の（ａ）〜（ｃ）を含む。
（ａ）前記第２のセルからの無線信号の受信品質に関する測定レポートを前記移動局から受信すること；
（ｂ）前記第２のセルがコネクション切替に対応できるか否かを認識すること；及び
（ｃ）前記測定レポート及前記認識の結果に基づいて、前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定すること。

本発明の第８の態様は、以下の（ａ）及び（ｂ）を含む制御処理をコンピュータに実行させるプログラムである。当該プログラムは、非一時的なコンピュータ可読媒体に格納されてもよい。
（ａ）隣接セル内で報知され、前記隣接セルがコネクション切替に対応できるか否かを判定可能な第１の情報を解読すること；及び
（ｂ）前記隣接セルからの無線信号の受信品質に関する測定レポートを基地局又は前記基地局を管理する制御局に対して送信するか否かを、前記解読の結果に基づいて決定すること。

本発明の第９の態様は、基地局との間で無線通信を行う無線通信部を有する移動局に関する制御処理をコンピュータに実行させるプログラムである。当該プログラムは、非一時的なコンピュータ可読媒体に格納されてもよい。前記制御処理は、隣接セルからの無線信号の受信品質に関する測定レポートと、前記隣接セルがコネクション切替に対応できるか否かを判定可能な第１の情報とを、前記基地局又は前記基地局を管理する制御局に対して送信するよう前記無線通信部を制御すること、を含む。

本発明の第１０の態様は、第１セルから第２のセルへの移動局のコネクション切替を制御する処理をコンピュータに実行させるプログラムである。当該プログラムは、非一時的なコンピュータ可読媒体に格納されてもよい。前記処理は、以下の（ａ）〜（ｃ）を含む。
（ａ）前記移動局から受信された前記第２のセルからの無線信号の受信品質に関する測定レポートを取得すること；
（ｂ）前記第２のセルがコネクション切替に対応できるか否かを認識すること；及び
（ｃ）前記測定レポート及前記認識の結果に基づいて、前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定すること。

本発明の第１１の態様にかかる移動通信システムは、第１及び第２の基地局、制御装置、及び上位装置を有する。前記第１の基地局は、第１のセルを生成する。前記第２の基地局は、第２のセルを生成する。前記移動局は、前記第１及び第２の基地局と通信可能である。前記上位装置は、前記第２の基地局と前記制御装置の間のネットワークに配置される。前記制御装置は、前記第１セルから前記第２のセルへの移動局のコネクション切替を制御する。また、前記制御装置は、前記第２の基地局を含む複数の基地局のコネクション切替への対応可否に関する情報を記録可能な記録装置にアクセスすることによって、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定できるよう構成されている。さらに、前記制御装置は、前記第２の基地局または前記上位装置によって生成される前記第２の基地局のコネクション切替への対応可否を示すメッセージの受信結果に基づいて前記記録装置に保持される前記情報を更新するよう構成されている。

本発明の第１２の態様にかかるソース制御装置は、第１セルから第２のセルへの移動局のコネクション切替を制御する。当該ソース制御装置は、前記第２のセルを含む複数のセルのコネクション切替への対応可否に関する情報を記録可能な記録装置にアクセスすることによって、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定するコネクション切替制御部を含む。さらに、前記コネクション切替制御部は、前記第２の基地局または前記第２の基地局と前記制御装置の間のネットワークに配置された上位装置によって生成される前記第２の基地局のコネクション切替への対応可否を示すメッセージの受信結果に基づいて前記記録装置に保持される前記情報を更新する。

本発明の第１３の態様にかかるターゲット制御装置は、第１の基地局から第２の基地局への移動局のコネクション切替を要求する要求メッセージに対する応答メッセージを生成する制御部を含む。ここで、前記応答メッセージは、前記第２の基地局の周辺に配置された周辺基地局のコネクション切替への対応可否を示す情報を含む。

本発明の第１４の態様は、以下の（ａ）及び（ｂ）を含む制御処理をコンピュータに実行させるプログラムである。当該プログラムは、非一時的なコンピュータ可読媒体に格納されてもよい。
（ａ）前記第２のセルを含む複数のセルのコネクション切替への対応可否に関する情報を記録可能な記録装置にアクセスすることによって、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定すること；及び
（ｂ）前記第２の基地局または前記第２の基地局と前記制御装置の間のネットワークに配置された上位装置によって生成される前記第２の基地局のコネクション切替への対応可否を示すメッセージの受信結果に基づいて前記記録装置に保持される前記情報を更新すること。

本発明の第１５の態様にかかるプログラムは、第１の基地局から第２の基地局への移動局のコネクション切替を要求する要求メッセージに対する応答メッセージを生成すること、をコンピュータに実行させる。ここで、前記応答メッセージは、前記第２の基地局の周辺に配置された周辺基地局のコネクション切替への対応可否を示す情報を含む。当該プログラムは、非一時的なコンピュータ可読媒体に格納されてもよい。

本発明の第１６の態様は、第１セルから第２のセルへの移動局のコネクション切替を制御する制御装置におけるコネクション切替の制御方法であって、以下の（ａ）及び（ｂ）を含む。
（ａ）前記第２のセルを含む複数のセルのコネクション切替への対応可否に関する情報を記録可能な記録装置にアクセスすることによって、前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を開始するか否かを決定すること；及び
（ｂ）前記第２の基地局または前記第２の基地局と前記制御装置の間のネットワークに配置された上位装置によって生成される前記第２の基地局のコネクション切替への対応可否を示すメッセージの受信結果に基づいて前記記録装置に保持される前記情報を更新すること。

本発明の第１７の態様は、動通信システムで使用される制御装置の制御方法である。当該方法は、第１の基地局から第２の基地局への移動局のコネクション切替を要求する要求メッセージに対する応答メッセージを生成することを含む。ここで、前記応答メッセージは、前記第２の基地局の周辺に配置された周辺基地局のコネクション切替への対応可否を示す情報を含む。

上述した本発明の各態様によれば、成功しないコネクション切替手順を開始することに伴う無駄なシグナリングを抑制することに寄与可能な移動通信システム、基地局装置、移動局装置、制御装置、ターゲット制御装置、プログラム、プログラムが格納された非一時的なコンピュータ可読媒体、及びコネクション切替の制御方法を提供できる。

発明の実施の形態１にかかる移動通信システムのネットワーク構成例を示す図である。 発明の実施の形態１にかかる移動通信システムのネットワーク構成例（ソースセル１３がマクロセルである場合）を示す図である。 発明の実施の形態１にかかる移動通信システムのネットワーク構成例（ソースセル１３がフェムトセルである場合）を示す図である。 発明の実施の形態１にかかる移動通信システムにおける移動局（UE）の送受信動作を示す図である。 発明の実施の形態１にかかる移動通信システムにおけるハンドオーバ手順の具体例を示すシーケンス図である。 発明の実施の形態１にかかる移動通信システムにおける移動局の判定手順の具体例を示すフローチャートである。 発明の実施の形態１におけるサポート情報の第１の定義例を示す図である。 発明の実施の形態１におけるサポート情報の第２の定義例を示す図である。 発明の実施の形態１において、移動局（UE）がサポート情報を受信した際の動作の定義例を示す図である。 発明の実施の形態１におけるサポート情報の第３の定義例を示す図である。 発明の実施の形態１におけるサポート情報の第４の定義例を示す図である。 発明の実施の形態１において、移動局（UE）がサポート情報を受信した際の動作の他の定義例を示す図である。 発明の実施の形態１にかかる移動通信システムにおけるホーム基地局（HNB）の構成例を示す図である。 発明の実施の形態１にかかる移動通信システムにおける移動局（UE）構成例を示す図である。 発明の実施の形態２にかかる移動通信システムのネットワーク構成例及び移動局（UE）の送受信動作を示す図である。 発明の実施の形態２にかかる移動通信システムにおけるSRNSリロケーションによってハンドオーバが開始されるシーケンス図である。 発明の実施の形態２にかかる移動通信システムにおける移動局の判定手順の具体例を示すフローチャートである。 発明の実施の形態２において、無線回線解放に伴うセル再選択手順が開始される場合を示すシーケンス図である。 発明の実施の形態２において、リダイレクション指示に伴うセル再選択手順が開始される場合を示すシーケンス図である。 発明の実施の形態２において、移動局（UE）が測定レポートで報告すべき内容の定義例を示す図である。 発明の実施の形態２において、測定レポートの内容を指定する情報要素（ＩＥ：Information Element）を移動局（UE）が受信した際の動作の定義例を示す図である。 発明の実施の形態２において、移動局（UE）が測定レポートで送信する内容の一例を示す図である。 発明の実施の形態２にかかる移動通信システムにおける制御装置の構成例を示す図である。 発明の実施の形態３にかかる移動通信システムのネットワーク構成例を示す図である。 発明の実施の形態３にかかる移動通信システムにおけるハンドオーバ／SRNSリロケーション手順を示すシーケンス図である。 発明の実施の形態３にかかる移動通信システムにおける制御装置の判定手順の具体例を示すフローチャートである。 発明の実施の形態４にかかる移動通信システムのネットワーク構成例を示す図である。 発明の実施の形態４にかかる移動通信システムにおけるデータベースの保持情報の具体例を示す図である。 発明の実施の形態４にかかる移動通信システムにおけるハンドオーバ／SRNSリロケーション手順を示すシーケンス図である。 発明の実施の形態４にかかる移動通信システムにおけるデータベースの更新手順の一例を示すシーケンス図である。 発明の実施の形態４にかかる移動通信システムにおけるデータベースの更新手順の他の例を示すシーケンス図である。 発明の実施の形態５にかかる移動通信システムにおけるデータベースの更新手順の一例を示すシーケンス図である。 発明の実施の形態５にかかる移動通信システムにおけるデータベースの更新手順の他の例を示すシーケンス図である。 発明の実施の形態５にかかる移動通信システムにおけるデータベース保持情報の無効化手順の一例を示すシーケンス図である。 発明の実施の形態５にかかる移動通信システムにおけるデータベース保持情報の無効化手順の他の例を示すシーケンス図である。 発明の実施の形態６にかかる移動通信システムにおけるデータベースの更新手順の一例を示すシーケンス図である。 発明の実施の形態７にかかる移動通信システムにおけるハンドオーバ／SRNSリロケーション手順を示すシーケンス図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第１の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第２の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第３の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第４の定義例を示す図である。 発明の実施の形態８に関する対応リストの第１の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第５の定義例を示す図である。 発明の実施の形態８に関する対応リストの第２の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第６の定義例を示す図である。 発明の実施の形態８に関する対応リストの第３の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第７の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第８の定義例を示す図である。 発明の実施の形態８に関する対応リストを転送するために拡張されたメッセージの第９の定義例を示す図である。 発明の実施の形態８に関する対応リストの第４の定義例を示す図である。 発明の実施の形態８にかかる移動通信システムに関し、マクロセルからフェムトセルへのUEのハンドオーバ／SRNSリロケーションの成功時におけるデータベース更新手順の一例を示すシーケンス図である。 発明の実施の形態８にかかる移動通信システムに関し、マクロセルからフェムトセルへのUEのハンドオーバ／SRNSリロケーションの失敗時におけるデータベース更新手順の一例を示すシーケンス図である。 発明の実施の形態８にかかる移動通信システムに関し、フェムトセル間でのUEのハンドオーバ／SRNSリロケーションの成功時におけるデータベース更新手順の一例を示すシーケンス図である。 発明の実施の形態８にかかる移動通信システムに関し、フェムトセル間でのUEのハンドオーバ／SRNSリロケーションの失敗時におけるデータベース更新手順の一例を示すシーケンス図である。 マクロセルからフェムトセルへのUEのハンドオーバに関するネットワーク構成図である。 フェムトセル間でのUEのハンドオーバに関するネットワーク構成図である。 マクロセルからフェムトセルへのハンドオーバ／SRNSリロケーションの成功例を示すシーケンス図である。 フェムトセル間でのハンドオーバ／SRNSリロケーションの成功例を示すシーケンス図である。 マクロセルからフェムトセルへのハンドオーバ／SRNSリロケーションの失敗例を示すシーケンス図である。 フェムトセル間でのハンドオーバ／SRNSリロケーションの失敗例を示すシーケンス図である。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜発明の実施の形態１＞
図１は、本実施の形態にかかる移動通信システム１のネットワーク構成例を示す図である。図１は、UE１０がソースセル１３からターゲットセル１４に移動する様子を示している。

図１において、ソース制御装置１１は、ソースセル１３から隣接セルへのUE１０のハンドオーバ／SRNSリロケーションを含むコネクション切替を制御する。上述したように、ソースセル１３がマクロセルである場合、マクロセルの無線リソース管理を行うRNCが制御装置１１に相当する。また、ソースセル１３がフェムトセルである場合、フェムトセルの無線リソース管理を行うHNBが制御装置１１に相当する。なお、UE１０のコネクション切替（具体的には、ハンドオーバ、セル再選択）を含む無線リソース管理機能の配置は、ネットワークアーキテクチャの設計思想に応じて適宜決定されるものである。したがって、制御装置１１をどこに配置するかは適宜選択し得る事項である。制御装置１１は、例えば、ソースセル１３を形成する基地局（マクロNode B又はHNB）と一体的に配置されても良いし、RNCやHNBGWとして配置されてもよい。

ターゲットHNB１２は、フェムトセルであるターゲットセル１４を生成する。上位ネットワーク１５は、ソース制御装置１１及びターゲットHNB１２が接続されたネットワークである。上位ネットワーク１５は、交換機を含むコアネットワークおよびHNBGWを含む。

ソースセル１３がマクロセルである場合における移動通信システム１のネットワーク構成の具体例を図２に示す。図２では、ソースRNC１１Ａがソース制御装置１１に相当する。また、上位ネットワーク１５は、コアネットワーク１５１およびHNBGW１５２を含む。一方、図３は、ソースセル１３がフェムトセルである場合における移動通信システム１のネットワーク構成の具体例を示している。図３では、ソースHNB１１Ｂがソース制御装置１１に相当する。

本実施の形態では、ソースセル１３からターゲットセル１４へのInbound Mobility、つまりUE１０のハンドオーバ／SRNSリロケーションにターゲットHNB１２が対応可能であるか否かを、UE１０又は制御装置１１が認識する。そして、制御装置１１は、ターゲットHNB１２のInbound Mobility対応可否の認識結果に基づいて、ターゲットセル１４へのUE１０のハンドオーバ／SRNSリロケーションを開始するか否かを決定する。具体的には、ターゲットHNB１２がInbound Mobility対応不可であると認識された場合、制御装置１１は、ターゲットセル１４へのUE１０のハンドオーバ／SRNSリロケーション手順を開始しない。これにより、移動通信システム１は、成功する可能性の無いハンドオーバ／SRNSリロケーション手順を開始することがないため、無駄なシグナリングを抑制することができる。

続いて以下では、ターゲットHNB１２がInbound Mobilityに対応できるか否かを認識するための手法の具体例について説明する。ここでは、ターゲットHNB１２が「サポート情報」を含む無線信号をターゲットセル１４内に報知する例について説明する。サポート情報は、ターゲットセル１４へのInbound Mobilityに対するHNB１２の対応可否を判定可能な情報である。具体的には、フェムトセルへのInbound Mobilityをサポートしていない3GPP Release 8までのHNBによっては送信されていない新たな情報要素（IE：Information Element）を定義すればよい。そして、フェムトセルへのInbound Mobilityをサポートする3GPP Release 9以降のHNBには、新IEを報知チャネル（BCH：Broadcast channel）等でターゲットセル１４内に送信させればよい。このようにすれば、ターゲットHNB１２によって報知される情報に新IEが含まれているか否かによって、ターゲットHNB１２のInbound Mobility対応可否を認識できる。つまり、この場合、新IEがサポート情報に相当する。

無駄なシグナリングを抑制するためには、ターゲットHNB１２の報知情報に新IEが含まれるか否かに応じて、ターゲットセル１４へのUE１０のハンドオーバ／SRNSリロケーションの開始を制御すればよい。なお、新IEの存否に基づいてハンドオーバ／SRNSリロケーション開始を決定する具体的な手法は、複数通り存在する。以下では、具体的な手法の一例として、ターゲットHNB１２の報知情報に新IEが含まれていない場合に、UE１０から制御装置１１への測定レポートの送信を抑止することによって、制御装置１１によるターゲットセル１４へのハンドオーバ／SRNSリロケーション手順が開始されないようにする例を詳細に説明する。

図４は、UE１０による報知情報の受信動作、及び制御装置１１への測定レポートの送信動作を示す図である。UE１０は、ターゲットセル１４のカバレッジエリアに近づくと、ターゲットHNB１２から報知情報を受信する。ターゲットHNB１２がInbound Mobilityに対応している場合、当該報知情報には、セル識別情報だけでなくサポート情報（新IE）が含まれている。

UE１０は、報知情報にサポート情報が含まれていることを条件として、ターゲットセル１４に関する測定レポートをセル識別情報とともに制御装置１１に送信する。これとは逆に、報知情報にサポート情報が含まれていない場合、UE１０は、ターゲットセル１４を測定レポート対象から除外する。つまり、UE１０は、ターゲットセル１４に関する測定レポートを制御装置１１に送信しない。制御装置１１は、ターゲットセル１４に関するセル識別情報及び測定レポートをUE１０から受信していなければ、ターゲットセル１４をUE１０のハンドオーバ先に決定することはない。これにより、成功する可能性の無いハンドオーバ／SRNSリロケーション手順が開始されず、無駄なシグナリングが抑制される。

図５は、直前に述べた具体的な制御手法に関するシーケンス図である。ステップＳ１０１では、制御装置１１とUE１０の間にRRC（Radio Resource Control）コネクションが確立される。ステップＳ１０２では、ターゲットセル１４のカバレッジエリアに近づいたUE１０が、ターゲットHNB１２からセル識別情報およびサポート情報（新IE）を受信する。なお、図５は、ターゲットHNB１２がInbound Mobilityをサポートしている場合に対応する。新IEは、図５に示すように、セル識別情報とともにSystem Information（具体的にはSystem Information Block type 3またはMaster Information Block）に含めるようにしてもよい。

ステップＳ１０３では、UE１０は、ターゲットセル１４に関する測定レポートを制御装置１１に送信するか否かの判定処理を行う。図６は、ステップＳ１０３の判定処理の具体例を示すフローチャートである。図６のステップＳ１０３１では、UE１０は、ターゲットセル１４からの報知情報にサポート情報（新IE）が含まれているか否かを判定する。サポート情報が含まれていた場合（Ｓ１０３１でＹＥＳ）、UE１０は、ターゲットセル１４に関するセル識別情報を含む測定レポートをソース制御装置１１に送信することを決定する（Ｓ１０３２）。一方、サポート情報が含まれていなかった場合（Ｓ１０３１でＮＯ）、UE１０は、ターゲットセル１４を測定レポート対象から除外する（Ｓ１０３３）。つまり、UE１０は、ターゲットセル１４に関する測定レポートを制御装置１１に送信しないことを決定する。

図５に戻り説明を続ける。ステップＳ１０３での判定結果に応じて、ステップＳ１０４において、UE１０は、ターゲットセル１４に関するセル識別情報を含む測定レポートを制御装置１１に送信する。最後に、ステップＳ１０５では、制御装置１１は、UE１０から受信した測定レポートに基づいてターゲットセル１４へのハンドオーバ／SRNSリロケーションを決定し、ハンドオーバ／SRNSリロケーション手順を開始する。

続いて、図７〜１２を参照して、サポート情報の具体例を説明する。図７は、3GPP TS 25.331における"System Information Block type 3"の定義中に、サポート情報として使用可能な新IE"Support of Inbound Mobility"を追加する修正例を示している（図７の下線部）。"Support of Inbound Mobility"は、文字通り、送信元のHNBがInbound Mobilityをサポートするか否かを表すパラメータである。
3GPP Release 9において標準化されるInbound MobilityをサポートするHNBは、"Support of Inbound Mobility"をSystem Informationに含めて送信するようにすればよい。これにより、HNBから受信したSystem Information に"Support of Inbound Mobility"が存在するか否かに応じて、送信元のセル及びHNBのInbound Mobilityのサポート可否を認識できる。なお、System Information Block type 3の詳細については、3GPP TS 25.331 "Radio Resource Control (RRC)" v8.7.0 (2009-06) のSection 10.2.48.8.6 を参照されたい。

図８は、Master Information Blockの中に、サポート情報として使用可能な新IE"Support of Inbound Mobility"を定義する例を示している（図８の下線部）。Master Information Blockの詳細については、3GPP TS 25.331 "Radio Resource Control (RRC)" v8.7.0 (2009-06) のSection 10.2.48.8.1を参照されたい。

図９は、新IEとしての"Support of Inbound Mobility"を受信したUE１０の動作の定義の一例を示している。図９の表記は、3GPP TS 25.331の表記に従ったものである。つまり、UE１０は、"Support of Inbound Mobility"を受信した場合、当該セルのセル識別情報を含む測定レポート（RRC：Measurement Report）を送信する。一方、"Support of Inbound Mobility"を受信しなかった場合、当該セルを測定レポート対象から除外する。つまり、UE１０は、当該セルに関する測定レポートを送信しない。なお、図９に示す動作定義の全体については、 3GPP TS 25.331 "Radio Resource Control (RRC)" v8.7.0 (2009-06) のSection 8.6.7.7を参照されたい。

図１０は、3GPP TS 25.331における"System Information Block type 3"の定義中に、サポート情報として使用可能な新IE"Access Stratum Release Indicator"を追加する修正例を示している（図１０の下線部）。"Access Stratum Release Indicator"は、送信元のHNBが対応しているシステムバージョン、つまり3GPP Release番号を示すパラメータである。
これにより、HNBから受信した"Access Stratum Release Indicator"の内容によって、送信元HNBが対応するシステムバージョンを判定でき、Inbound Mobilityのサポート可否も判定できる。なお、図１１に示すように、"Access Stratum Release Indicator"は、Master Information Blockに追加してもよい（図１１の下線部）。

図１２は、新IEとしての"Access Stratum Release Indicator"を受信したUEの動作の定義の一例を示している。図１２の表記は、3GPP TS 25.331の表記に従ったものである。つまり、UEは、HNBから受信したSystem Information に"Access Stratum Release Indicator"が設定されていた場合、当該セルのセル識別情報を含む測定レポート（RRC：Measurement Report）を送信する。一方、"Access Stratum Release Indicator"が設定されていなかった場合、当該セルを測定レポート対象から除外する。つまり、UE１０は、当該セルに関して測定レポートを送信しない。

また、 "Access Stratum Release Indicator"を参照することによって、送信元のNode Bが準拠しているリリース番号を判別可能となる。よって、"Access Stratum Release Indicator"が3GPP Release 9より前のバージョンを示している場合に、当該セルを測定レポート対象から除外してもよい。
また、 "Access Stratum Release Indicator"をサポート情報として利用することで、Release 9以降のさらなる機能拡張（Release 10、Release 11など）にも容易に対応することができる。このため、"Access Stratum Release Indicator"は、Inbound Mobilityのサポート可否だけでなく、リリースが進むについて追加されるその他の拡張機能のサポート可否の判別にも応用可能である。

続いて以下では、本実施の形態にかかるHNB１２及びUE１０の構成例について説明する。なお、ソース制御装置１１および上位ネットワーク１５の構成及び動作については、図５５〜５８を用いて説明したRNC９０２、HNB904A、コアネットワーク９０３、HNBGW９０５等と同様とすればよい。このため、これらの装置に関する説明は省略する。

図１３は、HNB１２の構成例を示すブロック図である。図１３において、無線通信部１２０は、ＲＦ（Radio Frequency）部１２１及び通信データ処理部１２２を含む。ＲＦ部１２１は、通信データ処理部１２２から供給されるベースバンド帯域のダウンリンク信号をRF（Radio Frequency）帯域へアップコンバートし、信号増幅を行った後にアンテナへ供給する。また、ＲＦ部１２１は、アンテナによって受信されたアップリンク信号の信号増幅、ベースバンド帯域への周波数ダウンコンバートを行って得られるベースバンド帯域のアップリンク信号を通信データ処理部１２２に供給する。

通信データ処理部１２２は、レイヤ１処理およびレイヤ２（MAC（Medium Access Control）/RLC（Radio Link Control））処理機能を有する。通信データ処理部１２２は、ダウンリンクに送信すべきパケットデータをHNBGW152から伝送路インタフェース１２３を介して受信する。通信データ処理部１２２は、受信したパケットデータの分割・統合、RLC再送制御などのRLCレイヤの送信処理、MAC再送制御、ARQ（Automatic Repeat reQuest）制御、トランスポートフォーマット選択、チャネル符号化、シンボルマッピング、変調を行って、ベースバンド帯域のダウンリンク信号を生成する。

また、通信データ処理部１２２は、ＲＦ部１２１から受信したアップリンク信号に対して、復調、誤り訂正復号、MAC再送制御、およびRLCレイヤの受信処理を行うことで、UE１０から送信されたデータ列を復元する。復元された受信データ列は、伝送路インタフェース１２３を介してHNBGW１５２に転送される。

移動制御部１２４は、UE１０及びHNBGW１５２との間でシグナリングを行って、UE１０のコネクション切替を制御する。コネクション切替には、通信中のハンドオーバ及び非通信中のセル再選択が含まれる。さらに、移動制御部１２４は、ターゲットセル（フェムトセル）１４へのInbound Mobilityをサポートしていることを報知するため、上述した"Support of Inbound Mobility"又は"Access Stratum Release Indicator"等のサポート情報を、無線通信部１２０から送信されるダウンリンク信号に含めて送信する。

図１４は、UE１０の構成例を示すブロック図である。図１４において、無線通信部１００は、ＲＦ部１０１、受信データ処理部１０２、及び送信データ処理部１０４を含む。ＲＦ部１０１は、アンテナを介してダウンリンク信号を受信する。受信データ処理部１０２は受信されたダウンリンク信号から受信データを復元し、これをバッファ部１０３に送る。バッファ部１０３に格納された受信データは読み出され、その目的に応じて利用される。また、送信データ処理部１０４及びＲＦ部１０１は、バッファ部１０３に格納された送信データを用いてアップリンク信号を生成し、ソースセル１３を生成する基地局、ソース制御装置１１、又はターゲットHNB１２に向けて送信する。

移動制御部１０５は、UE１０のハンドオーバ／SRNSリロケーション及びセル再選択を制御する。具体的には、周辺の基地局からの受信信号の測定レポートを生成してソース制御装置１１に送信し、制御装置１１からの指示に応じてハンドオーバ／SRNSリロケーションを実行する。また、非通信中には、移動制御部１０５は、周辺セルからの無線信号の受信品質に基づいて自律的なセルの再選択を行う。また、移動制御部１０５は、ネットワーク側からの要求に応じてセル再選択を開始してもよい。

本実施の形態で述べた移動通信システム１の具体例によれば以下に述べる利点が得られる。第１に、UE１０は、ターゲットセル１４がInbound Mobilityをサポートしていることを条件として、ターゲットセル１４に関する測定レポートをソース制御装置１１に送信する。制御装置１１は、ターゲットセル１４に関するセル識別情報を含む測定レポートをUE１０から受信していなければ、ターゲットセル１４をUE１０のハンドオーバ先に決定することはない。よって、既に述べたように、成功する可能性の無いコネクション切替手順（ハンドオーバ／SRNSリロケーション手順）が開始されず、無駄なシグナリングが抑制される。

第２に、Inbound Mobilityに対応していないターゲットセル１４をソース制御装置１１に通知していないので、これを通知した場合に発生する無駄な無線シグナリングを減らすことができる。

第３に、ソース制御装置１１には変更が不要である。ターゲットセル１４のInbound Mobilityサポート可否の判定をUE１０が行っているためである。

第４に、Inbound Mobilityに対応していない古いHNBには変更が不要である。Inbound Mobilityに対応しているHNB１２のみが"Support of Inbound Mobility"等のサポート情報を送信すればよいためである。

第５に、フェムトセルのセル識別情報を含めてRRC: Measurement Reportを送信する事ができないUE（古いUE）には変更が不要である。フェムトセルのセル識別情報を含めて測定レポート（RRC: Measurement Report）を送信できるUE（3GPP Release 9をサポートするUE等）のみが、パラメータ「Support of Inbound Mobility」の判定を行えばよいためである。

第６に、Inbound Mobilityに対応しているHNBとInbound Mobilityに対応していないHNBとが1つのネットワーク内に混在する事が可能である。第４及び第５の利点として述べたように、古いHNB及び古いUEの機能変更が不要であるためである。
特に、HNBはユーザ所有の装置（CPE：Customer Premise Equipment）となるため、全ネットワークがInbound Mobilityに対応するまでは、フェムトセルへのハンドオーバ／SRNSリロケーションを全く起動させないというオペレーションは実現が困難である。このため、古いHNBの混在を許容するという利点は、HNBのサービス展開を促進するために非常に有効である。

ところで、ターゲットHNB１２のInbound Mobilityのサポート可否の認識に関連してターゲットHNB１２及びUE１０によって行われる処理は、ＡＳＩＣ（Application Specific Integrated Circuit）、ＤＳＰ（Digital Signal Processor）、ＭＰＵ（Micro Processing Unit）若しくはＣＰＵ（Central Processing Unit）又はこれらの組み合わせを含むコンピュータ・システムを用いて実現することができる。具体的には、図５のシーケンス図及び図６のフローチャートを用いて説明したターゲットHNB１２又はUE１０の処理手順に関する命令群を含むプログラムをコンピュータ・システムに実行させればよい。

これらのプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜発明の実施の形態２＞
本実施の形態は、上述した発明の実施の形態１の変形である。図１５は、本実施の形態にかかる移動通信システム２のブロック図である。発明の実施の形態１では、ターゲットセル１４のInbound Mobilityサポート可否の判定をUE（UE１０）が行う具体例について説明した。これに対して本実施の形態では、ターゲットセル１４のInbound Mobilityサポート可否の判定をソース制御装置２１が行う。具体的には、UE２０は、ターゲットHNB１２から受信したサポート情報をソース制御装置２１に送信する。そして、ソース制御装置２１は、UE２０から受信したサポート情報に基づいて、ターゲットセル１４及びターゲットHNB１２のInbound Mobilityサポート可否を判定する。

図１６は、本実施の形態におけるハンドオーバ／SRNSリロケーション手順の具体例を示すシーケンス図である。ステップＳ２０１では、制御装置２１とUE２０の間にRRC（Radio Resource Control）コネクションが確立される。ステップＳ２０２では、ターゲットセル１４のカバレッジエリアに近づいたUE２０が、ターゲットHNB１２からセル識別情報およびサポート情報（新IE）を受信する。なお、図１６は、ターゲットHNB１２がInbound Mobilityをサポートしている場合に対応する。新IEは、図１６に示すように、セル識別情報とともにSystem Information（具体的にはSystem Information Block type 3またはMaster Information Block）に含めるようにしてもよい。

ステップＳ２０３では、UE２０は、ターゲットセル１４からサポート情報を受信しているか否かを判定する。図１７は、ステップＳ２０３の判定処理の具体例を示すフローチャートである。図１７のステップＳ２０３１では、UE２０は、ターゲットセル１４からの報知情報にサポート情報（新IE）が含まれているか否かを判定する。サポート情報が含まれていた場合（Ｓ２０３１でＹＥＳ）、UE２０は、ターゲットセル１４に関するセル識別情報に加えてサポート情報をも含む測定レポートをソース制御装置２１に送信することを決定する（Ｓ２０３２）。一方、サポート情報が含まれていなかった場合（Ｓ２０３１でＮＯ）、UE２０は、ターゲットセル１４に関するセル識別情報を含みサポート情報を含まない測定レポートをソース制御装置２１に送信することを決定する（Ｓ２０３３）。

なお、UE２０は、ターゲットセル１４からサポート情報を受信した場合に、これをソース制御装置２１に送信するか否かを、測定レポートの報告に関してソース制御装置２１から行われる指示に基づいて決定してもよい。

図１６に戻り説明を続ける。ステップＳ２０３での判定結果に従って、ステップＳ２０４において、UE２０は、ターゲットセル１４に関するセル識別情報及びサポート情報を含む測定レポートを制御装置２１に送信する。最後に、ステップＳ２０５では、制御装置２１は、UE２０から受信したサポート情報を含む測定レポートに基づいて、ターゲットセル１４へのハンドオーバ／SRNSリロケーションを決定し、ハンドオーバ／SRNSリロケーション手順を開始する。

次に、ターゲットHNB１２がInbound Mobilityをサポートしていない場合について説明する。図１８は、ターゲットHNB１２がInbound Mobilityを未サポートである場合に関する処理例を示すシーケンス図である。なお、図１８に示す処理のうち、図１６で説明したのと同一の処理については図１６と同一の符号を付している。

ステップＳ２１２では、ターゲットセル１４のカバレッジエリアに近づいたUE２０が、ターゲットHNB１２からセル識別情報を受信する。ここでは、HNB１２の報知情報にサポート情報は含まれていない。よって、UE２０は、ターゲットセル１４からサポート情報を受信していないと判定し（ステップＳ２１３）、セル識別情報を含みサポート情報を含まない測定レポートをソース制御装置２１に送信する。

ソース制御装置２１は、UE２０からの報告にサポート情報が含まれるか否かによって、ターゲットセル１４のInbound Mobility対応可否を認識できる。これにより、ソース制御装置２１は、Inbound Mobilityのためのハンドオーバ／SRNSリロケーション手順を実行するか、UE２０の自律的なセル再選択によるRRCコネクションの再確立を行うかを決定できる。図１８のケースでは、ソース制御装置２１は、Inbound Mobility未サポートであるターゲットセル１４へのハンドオーバ／SRNSリロケーションを開始せずに、UE２０との通信（RRCコネクション）を切断する（ステップＳ２１５）。これにより、ＵＥ２０は、自律的なセル再選択動作を行って、通信品質の良いセル（図１８ではターゲットセル１４）との間でRRC Connection を確立する（ステップＳ２１６）。

なお、ターゲットセル１４（ターゲットHNB１２）がInbound Mobility未サポートであることを知った場合に、ソース制御装置２１がRRCコネクション切断を行うことは一例に過ぎない。例えば、図１９に示すように、ソース制御装置２１は、ターゲットセル１４へのRedirectionを促すメッセージをUE２０に送信してもよい（ステップＳ２２５）。

続いて、図２０〜２２を参照して、UE２０に対するサポート情報の送信設定の具体例について説明する。図２０は、測定レポートによる報告内容に関してソース制御装置２１がUE２０に対して行う設定指示（RRC：Measurement Control）の定義例を示している。なお、図２０は、3GPP TS 25.331において、測定レポート内容に関する設定指示内容を定義している部分の修正例を示している（図２０の下線部）。 "Support of Inbound Mobility Reporting Indicator"がTRUE設定されている場合、UE２０は、サポート情報としての新IE""Support of Inbound Mobility"の受信内容をソース制御装置２１に報告すればよい。UE２０が測定レポートにより報告すべき内容の詳細については、 3GPP TS 25.331 "Radio Resource Control (RRC)" v8.7.0 (2009-06) のSection 10.3.7.5を参照されたい。

図２１は、新IEとしての"Support of Inbound Mobility"を受信したUE２０の動作の定義の一例を示している。図２１の表記は、3GPP TS 25.331の表記に従ったものである。つまり、UE２０は、（i）ソース制御装置２１から受信したRRC: Measurement Controlにおいて"Support of Inbound Mobility Reporting Indicator"がTRUE設定されている場合、かつ、（ii）ターゲットセル１４から受信したSystem Informationに新IE"Support of Inbound Mobility"が含まれている場合に、"Support of Inbound Mobility"を含む測定レポート（RRC Measurement Report）を送信する。なお、図２１に示す動作定義の全体については、 3GPP TS 25.331 "Radio Resource Control (RRC)" v8.7.0 (2009-06) のSection 8.6.7.7を参照されたい。

図２２は、3GPP TS 25.331において、UE２０の測定レポートに含まれるCell Measured Resultsの定義を示した部分の修正例を示している（図２２の下線部）。図２２の例では、サポート情報としての"Support of Inbound Mobility"がCell Measured Resultsに追加されている。Cell Measured Resultsの詳細については、 3GPP TS 25.331 "Radio Resource Control (RRC)" v8.7.0 (2009-06) のSection 10.7.7.3を参照されたい。

続いて以下では、本実施の形態にかかるソース制御装置２１の構成例について説明する。図２３は、制御装置２１の構成例を示すブロック図である。なお、図２３は、制御装置２１がRNCである場合について示している。

図２３において、通信部２１０は、マクロNode B１７から送信された信号を受信する。通信データ処理部２１１は、マクロNode B１７から受信したデータを、通信部２１２を経由してコアネットワーク（ＣＮ）１８に転送する。また、通信データ処理部２１１は、UE２０およびマクロNode B１７に向けて送信される送信データを通信部２１２から取得し、通信部２１０に送る。

移動制御部２１３は、UE２０、マクロNode B１７および上位ネットワーク１５との間でシグナリングを行うことにより、UE２０のハンドオーバ／SRNSリロケーションを制御する。移動制御部２１３における処理は、ＡＳＩＣ（Application Specific Integrated Circuit）、ＤＳＰ（Digital Signal Processor）、ＭＰＵ（Micro Processing Unit）若しくはＣＰＵ（Central Processing Unit）又はこれらの組み合わせを含むコンピュータ・システムを用いて実現することができる。具体的には、図１６、１８及び１９のシーケンス図を用いて説明したハンドオーバ／SRNSリロケーション手順に関する命令群を含むプログラムをコンピュータ・システムに実行させればよい。

本実施の形態によれば、上述した発明の実施の形態１の利点に代えて、又は実施の形態１の利点に加えて、以下に述べる利点が得られる。第１に、Inbound Mobilityによるハンドオーバを実施するかどうかを判定する決定権をソース制御装置２１に与えることができる。UE２０からソース制御装置２１にサポート情報が通知されるためである。

第２に、ソース制御装置２１は、Inbound Mobility未サポートのターゲットセル１４にUE２０が近づいた場合に、ハンドオーバ／SRNSリロケーション手順以外の他の手順によるコネクション切替を実施できる。これは、本実施の形態にかかるソース制御装置２１が、Inbound Mobility未サポートのターゲットセル１４にUE２０が近づいた事を認識できるためである。例えば、図１８及び１９で説明したように、ソース制御装置２１は、セル再選択動作の実行をUE２０に促すことができる。

第３に、ソース制御装置２１は、近隣のHNBがInbound Mobilityに対応しているかどうか、または近隣のHNBのサポートしている3GPP Releaseを取得する事ができるため、Source RANは、近隣に存在するHNBをデータベース化し、Self Optimizing Network(SON)の構築に利用する事ができる。

＜発明の実施の形態３＞
本実施の形態は、上述した発明の実施の形態２の変形である。図２４は、本実施の形態にかかる移動通信システム３のブロック図である。発明の実施の形態２では、ターゲットHNB１２から報知されるサポート情報をUE２０が受信した後に、UE２０がサポート情報をソース制御装置２１に送信する例について説明した。これに対して本実施の形態では、ソース制御装置３１又はソース制御装置３１が管理する基地局にネットワークリスニング機能に持たせる。ネットワークリスニング機能とは、隣接セルからの無線信号を受信する機能である。これにより、ソース制御装置３１は、ターゲットHNB１２から報知されるサポート情報をUE３０を経由せずに直接的に受信できる。また、UE３０は、サポート情報を受信して制御装置３１に送信する機能を持たなくてもよい。

図２５は、本実施の形態におけるハンドオーバ／SRNSリロケーション開始手順の具体例を示すシーケンス図である。なお、図２５は、ターゲットHNB１２がInbound Mobilityをサポートしており、サポート情報を送信している場合に対応する。ステップＳ３０１では、制御装置３１とUE３０の間にRRCコネクションが確立される。これは、図１６のＳ２０１と同様である。

ステップＳ３０２では、UE３０が、ターゲットHNB１２から無線信号を受信し、セル識別情報を取得する。なお、UE３０は、サポート情報を取得しなくてもよい。

ステップＳ３０３では、ソース制御装置３１が、ターゲットHNB１２からセル識別情報およびサポート情報を受信する。なお、上述したように、ソース制御装置３１は、配下の基地局がターゲットHNB１２から受信したサポート情報を受け取っても良い。

ステップＳ３０４では、UE３０は、ターゲットセル１４に関する測定レポート及びセル識別情報を制御装置３１に送信する。なお、UE３０は、サポート情報を制御装置３１に送信しなくてもよい。

ステップＳ３０５では、ソース制御装置３１は、ＵＥ３０による測定レポートによって報告されたターゲットセル１４がInbound Mobilityをサポートしているか否かを判定する。当該判定は、ソース制御装置３１又は配下の基地局によって受信されたサポート情報を用いて行われる。

ターゲットセル１４がInbound Mobilityをサポートしている場合、ソース制御装置３１は、ハンドオーバ／SRNSリロケーション手順を開始する。一方、ターゲットセル１４がInbound Mobilityをサポートしていない場合、ソース制御装置３１は、ハンドオーバ手順を開始せずに、UE３０にセル再選択を促す（ステップＳ３０６）。

図２６は、ステップＳ３０５における判定処理の具体例を示すフローチャートである。ステップＳ３０５１では、ソース制御装置３１は、UE３０から受信した測定レポート中のセル識別情報によって特定されるターゲットセル１４がInbound Mobilityをサポートしているかを、サポート情報に基づいて判定する。このサポート情報は、ソース制御装置３１又は配下の基地局によって受信されたものである。ターゲットセル１４がInbound Mobilityをサポートしている場合、ソース制御装置３１は、ハンドオーバ／SRNSリロケーション手順の開始を決定する（ステップＳ３０５２）。これに対して未サポートの場合、ソース制御装置３１は、ハンドオーバ／SRNSリロケーション手順に替わる他の手順、例えば、UE３０にセル再選択を促す手順の開始を決定する（ステップＳ３０５３）。

本実施の形態によれば、上述した発明の実施の形態２の利点に加えて、以下に述べる利点が得られる。すなわち、本実施の形態では、ソース制御装置３１がUE３０を介さずにサポート情報を取得できるので、サポート情報の転送機能をUE３０に持たせる必要がないという利点がある。つまり、UE３０は、図５５〜５８を用いて説明したUE９０６と同等の機能を有していればよい。

＜発明の実施の形態４＞
上述した実施の形態１〜３では、ターゲットHNB（１２）から送信されるサポート情報に基づいて、UE（１０、２０、３０）又はソース制御装置（１１、２１、３１）がターゲットHNB１２のInbound Mobilityのサポート状況を認識する例を説明した。これに対して、本実施の形態では、ターゲットHNBにサポート情報を送信させることなく、ターゲットHNBのInbound Mobilityのサポート状況をソース制御装置において認識でるようにした例について説明する。

図２７は、本実施の形態にかかる移動通信システム４の構成例を示す図である。UE４０及びターゲットHNB４２は、図５５〜５８を用いて説明したUE９０６及びHNB９０４と同等でよい。つまり、ターゲットHNB４２は、サポート情報を送信する必要はない。また、UE４０は、ターゲットセル１４に関するセル識別情報を含む測定レポートをソース制御装置４１に送信すればよく、サポート情報を送信する必要はない。

ソース制御装置４１は、記録装置４６に保持されたデータベースを参照することによって、UE４０から測定レポートによって報告されたセル識別情報に対応するターゲットHNB４２がInbound Mobilityをサポートしているか否かを判定する。

記録装置４６に保持されたデータベースは、ソースセル１３に隣接して配置されているターゲットセル１４がInbound Mobilityをサポートしているかの情報を保持するデータベースである。図２８は、記録装置４６に保持されるデータベース４６１の具体例を示す図である。図２８のデータベース４６１は、Inbound Mobilityに対応していないフェムトセル及びHNBに関するセル識別情報（CGI又はCI）のリストを保持している。

なお、データベースの配置は適宜変更することができる。例えば、図２７に示すように、データベース（記録装置４６）はソース制御装置４１ごとにローカルに配置してもよい。また、データベースは、複数のソース制御装置によって共用されてもよく、この場合、上位ネットワーク１５にデータベース（記録装置４６）を配置してもよい。

次に、記録装置４６に保持されたデータベースの参照結果に基づいて、ハンドオーバ／SRNSリロケーション手順を開始する動作の具体例について、図２９のシーケンス図を参照して説明する。ステップＳ４０１〜Ｓ４０３は、図５７のステップＳ９０１〜Ｓ９０３と同様である。すなわち、ステップＳ４０１では、制御装置４１とUE４０の間にRRCコネクションが確立される。ステップＳ４０２では、UE４０が、ターゲットHNB４２から無線信号を受信し、セル識別情報を取得する。ステップＳ４０３では、UE４０は、ターゲットセル１４に関するセル識別情報を含む測定レポートを制御装置４１に送信する。

ステップＳ４０４では、ソース制御装置４１は、UE４０から報告されたセル識別情報をデータベースに保持された識別情報と比較し、ターゲットHNB４２がInbound Mobilityをサポートしているか否かを判定する。ターゲットHNB４２がInbound Mobilityをサポートしている場合、ソース制御装置４１は、ハンドオーバ／SRNSリロケーション手順を開始する。一方、ターゲットHNB４２がInbound Mobilityをサポートしていない場合、ソース制御装置４１は、ハンドオーバ／SRNSリロケーション手順に代えて他の手順を開始する（ステップＳ４０５）。例えば、ソース制御装置４１は、UE４０にセル再選択を促すべく、RRCコネクションの解放（切断）、又はUE４０に対するredirection指示を行えばよい。

続いて、記録装置４６に保持されるデータベースに対するエントリ登録・更新方法の一例について説明する。例えば、データベースへのエントリ登録・更新は、通信事業者のオペレータが行えばよい。図３０は、オペレータによるエントリ登録・更新手順の具体例を示すシーケンス図である。図３０において、HNB EMS（Element Management System）４７は、HNBGW152の配下に接続されたHNB４２の監視・制御を行うためのシステムである。Source RAN EMS/NMS（Network Management System）４８は、Source RANの装置群（マクロNode B、RNC等）の監視・制御を行うためのシステムである。

図３０のステップＳ４１１では、ターゲットHNB４２において電源ONまたはファームウェア更新が行われる。ステップＳ４１２では、電源ON、ファームウェア更新等の所定のイベント発生を契機として、HNB４２は、メッセージ（OAM UPDATINGメッセージ）をEMS４７に送信する。当該メッセージは、HNB４２のInbound Mobilityサポート状況を判定可能なファームウェアバージョン情報などを含む。EMS４７は、受信したメッセージをEMS/NMS４８に転送する（ステップＳ４１３）。

EMS/NMS４８又はこれを操作するオペレータは、EMS４７からの受信メッセージに基づいてHNB４２のInbound Mobilityサポート可否を判定する。そして、この判定に応じて、EMS/NMS４８は、データベースを更新するためのメッセージをソース制御装置４１に送信する（ステップＳ４１４）。最後に、ステップＳ４１５では、ソース制御装置４１は、記録装置４６に保持されたデータベースを更新する。

図３１は、オペレータによるエントリ登録・更新手順の他の例を示すシーケンス図である。図３１は、ソース制御装置４１がHNBであって、ターゲットHNB４２と同じEMS４７により監視されている場合を示している。図３１の例では、電源ON、ファームウェア更新等の所定のイベント発生が発生したことに応じて（ステップＳ４１１）、ターゲットHNB４２からメッセージが送信される。そして、このメッセージがEMS４７により受信された場合（ステップＳ４１２）、データベースを更新するためのメッセージがEMS４７からソース制御装置４１に送信される（ステップＳ４２４）。なお、EMS４７からソース制御装置４１へのデータベース更新メッセージの送信は、EMS４７によって自動的に行われてもよいし、ターゲットHNB４２からの受信メッセージを確認したオペレータの操作に応じて行われてもよい。

本実施の形態によれば、上述した発明の実施の形態２と同様に、Inbound Mobilityによるハンドオーバを実施するかどうかを判定する決定権をソース制御装置４１に与えることができる。ソース制御装置４１が、ターゲットセル１４のInbound Mobilityサポート状況に関する情報を保持しているためである。

さらに、本実施の形態によれば、発明の実施の形態１〜３の利点に代えて、又は実施の形態１〜３の利点に加えて、以下に述べる利点が得られる。すなわち、本実施の形態では、ターゲットセル１４のInbound Mobilityサポート可否をソース制御装置４１が自律的に判定できるため、UE４０及びHNB４２に追加機能を持たせる必要がない。したがって、UE４０及びHNB４２は、図５５〜５８を用いて説明したUE９０６及びHNB９０４と同等の機能を有していればよい。

＜発明の実施の形態５＞
本実施の形態では、上述した発明の実施の形態４の変形例について説明する。上述した発明の実施の形態４では、記録装置４６に保持されるデータベースへのエントリ登録・更新を、OAMインタフェースを利用して行う例を説明した。本実施の形態では、このデータベースへのエントリ登録・更新を、ターゲットセル１４へのコネクション切替の失敗履歴に基づいて行う例について説明する。

具体的には、ターゲットセル１４へのUE４０のハンドオーバ／SRNSリロケーションをソース制御装置４１が開始した後に、ターゲット側の何らかの事情によってハンドオーバ／SRNSリロケーションが失敗する場合がある。このとき、図５９のステップＳ９４８及び図６０のステップＳ９６６に示したように、ターゲットセル１４（又はターゲットHNB４２）がInbound Mobilityに対応していないことを原因とする失敗通知がソース制御装置４１に到着する場合がある。ソース制御装置４１は、ターゲットセル１４のInbound Mobility未サポートを原因とするこのような失敗通知を受信した場合に、記録装置４６のデータベースに、Inbound Mobility未サポートのHNBの１つとしてターゲットHNB４２を登録する。

図３２は、記録装置４６のデータベースを更新する手順の具体例を示すシーケンス図である。図３２は、ソース制御装置４１がRNCである場合を示している。図３２のステップＳ５０１〜Ｓ５０８は、図５９に示したステップＳ９０１〜９０５、Ｓ９４６〜Ｓ９４８と同様である。図３２のステップＳ５０９では、ソース制御装置４１は、ステップＳ５０８で受信した失敗通知（RANAP: Relocation Failure）に付与されている失敗原因を参照する。そして、失敗原因がターゲットセル１４のInbound Mobility未サポートを示す場合、ソース制御装置４１は、ターゲットセル１４に対応するHNB４２をデータベースに登録する。

失敗原因がターゲットセル１４のInbound Mobility未サポートであるか否かは、例えば、RANAP: Relocation Failure に含まれるCause IEによって判定可能である。ターゲットセル１４がInbound Mobility未サポートであった場合、Cause IEには、「Relocation not supported in Target RNC or Target system (44)」が設定される。Cause IEの詳細については、3GPP TS 25.413 "UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling" V8.3.0 (2009-06) のセクション8.6.3 "Unsuccessful Operation" 及びセクション9.2.1.4 "Cause" を参照されたい。

図３３もまた、記録装置４６のデータベースを更新する手順の具体例を示すシーケンス図である。図３３は、ソース制御装置４１がHNBである場合を示している。図３３のステップＳ５１１〜Ｓ５１６は、図６０に示したステップＳ９２１〜９２４、Ｓ９６５〜Ｓ９６６と同様である。図３３のステップＳ５１７では、ソース制御装置４１は、ステップＳ５１６で受信した失敗通知（RANAP: Relocation Failure）に付与されている失敗原因を参照する。そして、失敗原因がターゲットセル１４のInbound Mobility未サポートを示す場合、ソース制御装置４１は、ターゲットセル１４に対応するHNB４２をデータベースに登録する。

本実施の形態で説明したように、データベースへのエントリ登録を、ソース制御装置４１が過去にハンドオーバ／SRNSリロケーション手順を試行して失敗したことに応じて行うことによって、記録装置４６に保持されるデータベースの信頼性を向上できる。また、実施の形態４で述べたOAMによりデータベースを更新する方法と比較すると、OAMインタフェースに変更を加える必要がないという利点もある。

ところで、HNB４２がInbound Mobilityに対応していない状況は恒久的なものではなく、HNB４２はファームウェアのバージョンアップによってInbound Mobilityに対応可能となる。しかしながら、HNB４２はユーザ所有の機器である。このため、HNB４２のファームウェアバージョンアップは、ネットワーク側から一斉に強制的に行われるのではなく、ユーザの主導によりユーザの都合の良い時に適宜行われることが予想される。このようなHNB４２の使用状況を考慮すると、過去に一度ターゲットセル１４へのハンドオーバ／SRNSリロケーションに失敗したことを契機としてHNB４２がInbound Mobilityに対応していないとのデータベース登録を恒久的に行ったのでは、その後のファームウェア更新を反映できず不都合である。したがって、データベースの登録情報を無効化する仕組みを設けるとよい。以下では、データベースの登録情報を無効化する仕組み具体例１〜３を説明する。

＜具体例１：タイマー処理による無効化＞
図３４は、タイマー処理による無効化の具体例を示すシーケンス図である。ステップＳ５２１では、ソース制御装置４１は、Inbound Mobilityに未対応のターゲットセル１４に関するセル識別情報をデータベースに登録する。ステップＳ５２２では、データベース登録からの経過時間を計測するためのタイマーを作動させる。ステップＳ５２３では、タイマーの満了、すなわち、予め定められた時間が経過したことを判定する。ステップＳ５２４では、タイマーの満了に応じて、ソース制御装置４１は、対応するセル識別情報を無効化する。具体的には、データベースから削除すればよい。

つまり、HNB４２がInbound Mobility未サポートであることを示す情報は、タイマーが有効である期間に限り、有効なエントリとしてデータベースに存在する。したがって、タイマー満了に伴って削除されたエントリに対応するHNB４２に対しては、再度ハンドオーバ／SRNSリロケーション手順が試行されることになる。このとき、HNB４２がInbound Mobility非対応のままである場合には、再度のRelocation Failureを契機としてデータベースへのエントリ登録が改めて実行される。

これにより、ソース制御装置４１２は、ユーザによって行われるHNB４２のバージョンアップをデータベースに反映することができる。また、この手法によれば、制御装置４１のOAMインタフェースに対して、データベースエントリの無効化を行うために変更を加える必要がない。

＜具体例２：ハンドオーバ／SRNSリロケーション試行回数による無効化＞
図３５は、ハンドオーバ／SRNSリロケーション試行回数による無効化の具体例を示すシーケンス図である。ステップＳ５３１では、ソース制御装置４１は、Inbound Mobilityに未対応のターゲットセル１４に関するセル識別情報をデータベースに登録する。ステップＳ５３２−１〜Ｓ５３２−Ｎでは、データベースの登録情報に基づいてターゲットセル１４へのハンドオーバ／SRNSリロケーションを抑止した回数をカウントする。ステップＳ５３３では、ハンドオーバ／SRNSリロケーション抑止のカウント回数が予め定められた回数Ｎに到達したことに応じて、ソース制御装置４１は、対応するセル識別情報をデータベースから削除することにより無効化する。

この手法によっても、具体例１と同様に、ユーザによって行われるHNB４２のバージョンアップをデータベースに反映することができる。また、制御装置４１のOAMインタフェースに対して、データベースエントリの無効化を行うために変更を加える必要がない。

＜具体例３：OAMによる無効化＞
データベースエントリの無効化は、図３０及び３１を用いて説明したのと同様に、OAMインタフェースを使用して行ってもよい。この手法によれば、タイマー満了や所定のハンドオーバ／SRNSリロケーション試行回数の経過を待つ必要がない。このため、HNB４２がファームウェアバージョンアップによってInbound Mobilityに対応したことを、いち早くデータベースに反映し易いという利点がある。

＜発明の実施の形態６＞
本実施の形態では、上述した発明の実施の形態４の更なる変形例について説明する。上述した発明の実施の形態４では、記録装置４６に保持されるデータベースへのエントリ登録・更新を、OAMインタフェースを利用して行う例を説明した。本実施の形態では、このデータベースへのエントリ登録・更新を、RNC-HNB間インタフェース又はHNB-HNB間インタフェースにてメッセージを送受信することで行う例について説明する。

図３６は、ネットワーク構成の変更を契機としてメッセージを送受信し、データベースエントリを更新する例を示すシーケンス図である。図３６の例では、電源ON、ファームウェア更新等の所定のイベント発生が発生したことを契機として（ステップＳ６０１）、RNC-HNB間又はHNB-HNB間インタフェースを介して、ターゲットHNB４２からソース制御装置４１にメッセージが送信される（ステップＳ６０２）。このメッセージを受信した場合、ソース制御装置４１は、データベースエントリを更新する（ステップＳ６０３）。

さらに、ソース制御装置４１がRNCである場合には以下の手順を追加してもよい。すなわち、新たにマクロNode Bが設置されたときに、ソース制御装置４１であるRNCは、そのマクロNode Bの近隣に位置するHNBとの間でRNC-HNB間インタフェースにより通信を行い、Inbound Mobility対応可否情報を収集してもよい。

このようなデータベースエントリの更新手法によれば、ソース制御装置４１は、HNB４２のInbound Mobility対応可否の最新状況を予め取得しておくことができる。

＜発明の実施の形態７＞
本実施の形態では、RNC-HNB間インタフェース又はHNB-HNB間インタフェースにてメッセージを送受信することでターゲットHNB４２のInbound Mobility対応可否を確認する例について説明する。上述した実施の形態６では、データベースエントリの更新を目的として、ネットワークの構成変更を契機とするメッセージ送受信を行う例を示した。本実施の形態では、UE４０のコネクション切替に関する制御手順の開始時にメッセージを送受信することでInbound Mobility対応可否を確認する手順について説明する。

図３７は、本実施の形態の処理手順を示すフローチャートである。図３７のステップＳ４０１〜Ｓ４０３、及びＳ４０５は、発明の実施の形態４に関する図３２に示した同一符号のステップと同様である。

図３７のステップＳ７０４では、UE４０からの測定レポート（RRC: Measurement Report）の受信を契機として、ソース制御装置４１は、Inbound Mobility対応可否要求メッセージをターゲットHNB４２に送信する。当該メッセージの送信は、ソース制御装置４１がRNCである場合にはRNC-HNB間インタフェースを用いて行われ、ソース制御装置４１がHNBである場合にはHNB-HNB間インタフェースを用いて行われる。

ステップＳ７０５では、要求メッセージに対する応答メッセージがターゲットHNB４２からソース制御装置４１に送られる。応答メッセージは、ターゲットHNB４２のInbound Mobility対応可否を示す情報を含む。ステップＳ７０６では、応答メッセージの内容に基づいて、ソース制御装置４１は、ターゲットHNB４２へのハンドオーバ／SRNSリロケーション手順および代替手順（セル再選択を促す手順）のうちいずれを開始するか決定する。

応答メッセージの内容におけるターゲットHNBのInbound Mobility対応可否については、TS25.423 Version 8.5.0 (2009-06版)の9.2.2.D章Cell Capability Container FDDのIEの1つのBitによって示すこととしてもよい。この場合、当該BitのTRUE/FALSE指定によって、Inbound Mobility対応可否を表せばよい。

本実施の形態によれば、UE４０のハンドオーバ／SRNSリロケーションに関する制御手順の開始時に、ターゲットHNB４２のInbound Mobility対応可否の確認をタイムリーに行うことができる。よって、制御装置４１は、記録装置４６のデータベースを参照する必要がない。よって、予めデータベースを構築しておく必要がない。

なお、本実施の形態においても、制御装置４１がデータベースを参照するようにしてもよい。この場合、ターゲットHNB４２に関するエントリがデータベースに存在しない場合にのみ、RNC-HNB間インタフェース又はHNB-HNB間インタフェースによるメッセージ送受信を行うとよい。これにより、メッセージ送受信の多発を抑制できる。

＜発明の実施の形態８＞
本実施の形態では、上述した発明の実施の形態４〜６の更なる変形例について説明する。本実施の形態では、Inbound Mobility対応可否を記録するデータベースへのエントリ登録・更新を、コアネットワーク１５１およびHNBGW１５２を含む上位ネットワーク１５を介したメッセージ送受信に基づいて行う例について説明する。なお、本実施の形態にかかる移動通信システムの全体的なネットワーク構成は、図２７に示した実施の形態４の構成と同様とすればよい。

上位ネットワーク１５を介したメッセージとしては、UE４０のコネクション切替（すなわちハンドオーバ／SRNSリロケーション）の要求メッセージ（RANAP: Relocation required及びRANAP: Relocation request等）とこれに対する応答メッセージ（RANAP: Relocation Request Acknowledge、 RANAP: Relocation Command、 RANAP: Relocation Failure、及びRANAP: Relocation Preparation Failure等）を利用できる。この点において、本実施の形態は、上述した発明の実施の形態５と類似する。しかしながら、本実施の形態では、コネクション切替要求に応答してソース制御装置４１に送られる応答メッセージに、対応リストを含める。対応リストは、コネクション切替要求で指定されたターゲットHNB４２の周辺に配置された周辺HNB（不図示）のInbound Mobility対応可否情報を含む。ソース制御装置４１は、コネクション切替要求に対する応答メッセージに含まれる対応リストを用いて、記録装置４６に保持されるデータベースを更新する。

対応リストは、ターゲットHNB４２の周辺基地局の識別情報と、各周辺基地局のInbound Mobility対応可否情報を含む。なお、対応リストは、Inbound Mobilityに対応可能な周辺基地局のみの情報を含んでもよい。また、これとは逆に、対応リストは、Inbound Mobilityに対応不可能な周辺基地局のみの情報を含んでもよい。周辺基地局の識別情報としては、CGI (Cell Global Identity)またはCI（Cell Identity）を使用すればよい。

また、対応リストは、ターゲットHNB４２自身のInbound Mobility対応可否情報を含んでもよい。しかしながら、発明の実施の形態５等で説明したように、応答メッセージ（RANAP: Relocation Command及びRANAP: Relocation Preparation Failure等）がターゲットHNB４２自身のInbound Mobility対応可否を示す場合、対応リストはターゲットHNB４２自身の情報を含まなくてもよい。

HNBGW１５２又はコアネットワーク１５１を介して、ターゲットHNB４２とソース制御装置４１との間で対応リストを送受信するためには、既存のメッセージを拡張して使用すればよい。例えば、以下のメッセージを利用することができる。
（１）RANAP（Radio Access Network Application Part）プロトコル
・RANAP: Relocation Request Acknowledge
・RANAP: Relocation Command
・RANAP: Relocation Preparation Failure
・RANAP: Relocation Failure
・RANAP: Direct Transfer
・RANAP: Information Transfer Indication/Confirmation
・RANAP: Direct Information Transfer
・RANAP: Uplink Information Exchange Request/Response
（２）RUA（RANAP User Adaption）プロトコル
・RUA: Direct Transfer
・RUA: Connection Less Transfer
（３）HNBAP（Home Node B (HNB) Application Part）プロトコル
・HNBAP: HNB Register Accept
・HNBAP: UE Register Accept
・HNBAP: UE De-register

また、ターゲットHNB４２が周辺HNBの対応リストを保持する場合には、ターゲットHNB４２が送信するRANAP: Relocation Request Acknowledge メッセージ内に含まれるRRC Container（SRNS relocation info.）に対応リストを含めてもよい。

ターゲットHNB４２又はHNBGW１５２は、以下のようにして周辺HNBのInbound Mobility対応可否情報を収集すればよい。ターゲットHNB４２が対応リストを保持する場合、発明の実施の形態３で述べたように、ターゲットHNB４２にネットワークリスニング機能を持たせればよい。そして、ターゲットHNB４２は、周辺HNBが報知するサポート情報を受信することで、周辺HNBのInbound Mobility対応可否を認識すればよい。また、ターゲットHNB４２は、発明の実施の形態２で述べたように、Inbound Mobility対応可否を判別可能な情報を含む測定レポートをUEから受信してもよい。また、ターゲットHNB４２は、HNB間インタフェースによって周辺HNBとのシグナリングを行い、周辺HNBのInbound Mobility対応可否情報を収集してもよい。

HNBGW１５２が対応リストを保持する場合、HNBGW１５２と配下のHNBとの間で行われるHNBの認証・登録手順の中で、Inbound Mobility対応可否情報を収集すればよい。

以下では、図３８〜５０を参照して、対応リストを送信するために拡張されたメッセージの具体例と、対応リストの具体例について説明する。図３８〜４２は、ソースセル１３がマクロセルであり、ソース制御装置４１がRNCである場合に利用可能な例である。
図３８は、RNCとコアネットワークとの間のIuインタフェースにおけるRANAP シグナリングを規定する3GPP TS 25.413 のセクション9.1.11に記載された "Relocation Request Acknowledge" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図３８の下線部）。

図３９は、3GPP TS 25.413 のセクション9.1.12に記載された "Relocation Command" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図３９の下線部）。

図４０は、3GPP TS 25.413 のセクション9.1.15に記載された "Relocation Preparation Failure" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図４０の下線部）。

図４１は、3GPP TS 25.413 のセクション9.1.16に記載された "Relocation Failure" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図４１の下線部）。

図４２は、図３８〜４１に示したRANAPメッセージで転送される対応リスト（CGI List of Inbound Mobility Capability）の定義例を示している。図４２の例では、対応リストは、Inbound Mobilityの対応可否を示す「Inbound Mobility Capability」、リストに含まれる周辺基地局の識別情報の数「List of CGI」、周辺基地局の識別情報「CGI」を含む。図４２の例では、CGIは、PLMN-id、LAC（Location Area Code）及びCIを必須要素として含み、RAI（Routing Area Code）をオプション要素として含む。図４２の対応リストの定義は、3GPP TS 25.413 のセクション9.2 "Information Element Definitions"に加えればよい。

図４３〜４４は、ソースセル１３がフェムトセルであり、ソース制御装置４１がHNBである場合に利用可能な例である。また、ターゲットHNB４２が対応リストを管理している場合に、ターゲットHNB４２とHNBGW１５２との間で利用可能な例でもある。
図４３は、HNBとHNBGWの間のIuhインタフェースにおけるRUA（RANAP User Adaption） シグナリングを規定する3GPP TS 25.468 のセクション9.1.4に記載された "Direct Transfer" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図４３の下線部）。

図４４は、図４３に示したRUAメッセージで転送される対応リスト（CGI List of Inbound Mobility Capability）の定義例を示している。図４４に示す対応リストの構造は、図４２に示したものと同様である。図４４の対応リストの定義は、3GPP TS 25.468 のセクション9.2 "Information Element Definitions"に加えればよい。

図４５及び４６は、RRC Container（SRNS relocation info）に対応リストを含めて送信する場合の具体例を示している。上述したように、図４５及び４６は、ターゲットHNB４２が対応リストを保持する場合に利用できる。
図４５は、RNCプロトコルを規定する3GPP TS 25.331 のセクション14.12.4.2に記載された "SRNS relocation info." の定義中に、対応リストとして使用可能な新IE "Cell List of Inbound Mobility Capability"を追加する修正例を示している（図４５の下線部）。

図４６は、図４５に示したRRC Containerで転送される対応リスト（Cell List of Inbound Mobility Capability）の定義例を示している。図４６の例では、対応リストは、Inbound Mobilityの対応可否を示す「Inbound Mobility Capability」、リストに含まれる周辺基地局の識別情報の数「Cell List」、周辺基地局の識別情報「CI (Cell Identity)」を含む。図４６の対応リストの定義は、3GPP TS 25.331 のセクション10.3.2 "UTRAN mobility Information elements"に加えればよい。

図４７〜５０は、ターゲットHNB４２とHNBGW１５２の間、およびソース制御装置４１がHNBである場合のソース制御装置４１とHNBGW１５２の間、における対応リストの転送に利用可能な例である。
図４７は、HNBとHNBGWの間のIuhインタフェースにおけるHNBAP（Home Node B Application Part）シグナリングを規定する3GPP TS 25.469 のセクション9.1.4に記載された "HNB REGISTER ACCEPT" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図４７の下線部）。

図４８は、3GPP TS 25.469のセクション9.1.7に記載された "UE REGISTER ACCEPT" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図４８の下線部）。

図４９は、3GPP TS 25.469のセクション9.1.10に記載された "UE DE-REGISTER" の定義中に、対応リストとして使用可能な新IE "CGI List of Inbound Mobility Capability"を追加する修正例を示している（図４９の下線部）。

図５０は、図４７〜４９に示したHNBAPメッセージで転送される対応リスト（CGI List of Inbound Mobility Capability）の定義例を示している。図５０に示す対応リストの構造は、図４２に示したものと同様である。図５０の対応リストの定義は、3GPP TS 25.469 のセクション9.2 "Information Element Definitions"に加えればよい。

続いて以下では、本実施の形態におけるデータベース更新手順のいくつかの具体例をシーケンス図に従って説明する。図５１のシーケンス図は、ソースセル１３がマクロセルであって、ターゲットセル１４（ターゲットHNB４２）がInbound Mobilityをサポートしている場合を示している。図５１のステップＳ８０１〜Ｓ８０４は、図２９のステップＳ４０１〜４０４と同様である。ステップＳ８０４では、ソース制御装置４１は、UE４０から報告されたセル識別情報をデータベースに保持された識別情報と比較し、ターゲットHNB４２がInbound Mobilityをサポートしているか否かを判定する。

図５１の例では、ターゲットHNB４２がInbound Mobilityをサポートすることがデータベースに記述されているか、ターゲットHNB４２に関する情報がデータベースに記載されていない場合を想定している。したがって、ソース制御装置４１は、ハンドオーバ／SRNSリロケーション手順を開始するため、コネクション切替要求としての、リロケーション要求（RANAP: Relocation Required）を送信する（ステップＳ８０５）。ステップＳ８０５以降のうち、ステップＳ８０５〜８０８及びＳ８１３は、図５７に示したステップＳ９０４〜Ｓ９０７及びＳ９１１と同様である。

図５１のステップＳ８０９〜Ｓ８１１は、メッセージ内に対応リストが含まれる点を除いて図５７のステップＳ９０８〜Ｓ９１０と同様である。なお、HNBGW１５２が配下のHNBに関する対応リストを保持している場合、ステップＳ８０９でターゲットHNB４２から送信されるRANAP: Relocation Request Acknowledgeメッセージを含むRUA: Direct Transfer メッセージは、対応リストを含んでいなくてもよい。

ステップＳ８１２では、ソース制御装置４１は、コアネットワーク１５１を介して受信した承認通知（RANAP: Relocation Command）及びこれに含まれる対応リストを参照し、ターゲットHNB４２及びその周辺HNBに関する情報を記述すべく、記録装置４６に保持されたデータベースを更新する。

図５２のシーケンス図は、ソースセル１３がマクロセルであって、ターゲットセル１４（ターゲットHNB４２）がInbound Mobilityをサポートしていない場合を示している。図５２のステップＳ８０１〜Ｓ８０６は、図５１に示したステップＳ８０１〜Ｓ８０６と同様である。だたし、図５２は、ターゲットセル１４（ターゲットHNB４２）がInbound Mobilityをサポートしていない場合を想定している。このため、ターゲット制御装置４１は、例えば、ターゲットHNB４２関する情報がデータベースに記載されていない場合に、リロケーション要求（RANAP: Relocation Required）を送信する（ステップＳ８０５）。また、ターゲット制御装置４１は、以下の場合にもターゲットHNB４２対するリロケーション要求を送信してもよい。第１に、データベースに記述されたターゲットHNB４２に関する情報が間違いで、ターゲットHNB４２がデータベースにおいてInbound Mobilityをサポートすることが記述されている場合である。第２に、ターゲットHNB４２がデータベースにおいてInbound Mobilityをサポートしない事が記述されているが、ターゲットHNB４２の周辺HNB（不図示）に関する情報が少ない場合である。この場合、ターゲット制御装置４１は、リロケーション手順に失敗する事を前提としながらも、ターゲットHNB４２の周辺HNBに関する情報を取得する事を目的としてリロケーション手順を実施してもよい。

ステップＳ８２７では、図５９のステップＳ９４６と同様に、HNBGW１５２がUE REGISTRATION に失敗する。図５２のステップＳ８２８〜Ｓ８２９は、メッセージ内に対応リストが含まれる点を除いて図５９のステップＳ９４７〜Ｓ９４８と同様である。ステップＳ８３０では、ソース制御装置４１は、コアネットワーク１５１を介して受信した失敗通知（RANAP: Relocation Preparation Failure）及びこれに含まれる対応リストを参照し、ターゲットHNB４２及びその周辺HNBに関する情報を記述すべく、記録装置４６に保持されたデータベースを更新する。

図５３のシーケンス図は、ソースセル１３がフェムトセルであって、ターゲットセル１４（ターゲットHNB４２）がInbound Mobilityをサポートしている場合を示している。図５３のステップＳ８３１〜Ｓ８３４は、図５１に示したステップＳ８０１〜８０４と同様である。また、ステップＳ８３５〜Ｓ８３７及びＳ８４１は、図５８に示したステップＳ９２１〜Ｓ９２６及びＳ９２９と同様である。

図５３のステップＳ８３８〜Ｓ８３９は、メッセージ内に対応リストが含まれる点を除いて図５８のステップＳ９２７〜Ｓ９２８と同様である。なお、HNBGW１５２が配下のHNBに関する対応リストを保持している場合、ステップＳ８３８でターゲットHNB４２から送信されるRANAP: Relocation Request Acknowledgeメッセージを含むRUA: Direct Transfer メッセージは、対応リストを含んでいなくてもよい。ステップＳ８４０では、ソース制御装置４１は、コアネットワーク１５１を介して受信した対応リストを参照し、記録装置４６に保持されたデータベースを更新する。

図５４のシーケンス図は、ソースセル１３がフェムトセルであって、ターゲットセル１４（ターゲットHNB４２）がInbound Mobilityをサポートしていない場合を示している。図５４のステップＳ８３１〜Ｓ８３５は、図５３に示したステップＳ８３１〜Ｓ８３５と同様である。だたし、図５４は、ターゲットセル１４（ターゲットHNB４２）がInbound Mobilityをサポートしていない場合を想定している。このため、ターゲット制御装置４１は、ターゲットHNB４２関する情報がデータベースに記載されていない場合に、リロケーション要求（RANAP: Relocation Required）を送信する（ステップＳ８３５）。

ステップＳ８５６では、図６０のステップＳ９６５と同様に、HNBGW１５２がUE REGISTRATION に失敗する。図５４のステップＳ８５７は、メッセージ内に対応リストが含まれる点を除いて図６０のステップＳ９６６と同様である。ステップＳ８５８では、ソース制御装置４１は、HNBGW１５２から受信した失敗通知（RANAP: Relocation Preparation Failure）及びこれに含まれる対応リストを参照し、ターゲットHNB４２及びその周辺HNBに関する情報を記述すべく、記録装置４６に保持されたデータベースを更新する。

上述したように、本実施の形態では、ターゲットHNB４２へのコネクション切替要求メッセージに対してターゲット側から送信される応答メッセージを用いて、ターゲットHNB４２の周辺に配置された基地局のInbound Mobility対応可否を示す対応リストを送信することとした。これにより、ソース制御装置４１は、将来的にUE４０が移動する可能性の高いターゲットHNB４２の周辺に配置された基地局のInbound Mobility対応可否情報を少ないシグナリングで取得することができる。

なお、上述した発明の実施の形態１〜８では、本発明をUTRANシステムに適用する場合について説明したが、本発明は、UTRANシステムに限られず他の移動通信システムにも適用可能である。また、異システム間でのUEのコネクション切替にも適用できる。例えば、ソースセル１３を生成する基地局は、3GPPで規定されるE-UTRAN、GERAN（GSM/EDGE Radio Access Network）、又はGSM（Global System for Mobile Communications）のマクロ基地局又はホーム基地局であってもよい。また、ターゲットセル１４を生成する基地局は、GERAN又はGSMのマクロ基地局又はホーム基地局であってもよい。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

この出願は、２００９年８月７日に出願された日本出願特願２００９−１８５１４９を基礎とする優先権、及び２００９年９月７日に出願された日本出願特願２００９−２０５７１１を基礎とする優先権を主張し、これらの開示の全てをここに取り込む。

１、２、３、４ 移動通信システム
１０、２０、３０、４０ 移動局（UE）
１１、２１、３１、４１ ソース制御装置
１１Ａ ソースRNC
１１Ｂ ソースHNB
１２、４２ ターゲットHNB
１３ ソースセル（マクロセル又はフェムトセル）
１４ ターゲットセル（フェムトセル）
１５ 上位ネットワーク
１７ マクロNode B
４６ 記録装置
１００ 無線通信部
１０３ バッファ部
１０５ 移動制御部
１２０ 無線通信部
１２３ 伝送路IF
１２４ 移動制御部
１５１ コアネットワーク（CN）
１５２ HNB ゲートウェイ（HNBGW）
２１３ 移動制御部

Claims (5)

1. 第１のセルを生成する第１の基地局と、
   第２のセルを生成する第２の基地局と、
   前記第１及び第２の基地局と通信可能な移動局と、
   前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を制御する制御装置と、
   を備え、
   前記第２の基地局は、前記第２のセルへのコネクション切替に対する対応可否を判定可能な第１の情報を含む無線信号を前記第２のセル内に送信するよう構成され、
   前記制御装置は、前記第２のセルからの無線信号の受信品質に関する測定レポートを前記第１の基地局を介して前記移動局から受信するとともに、前記測定レポートに基づいて前記第２のセルへのコネクション切替の開始を決定するよう構成され、
   前記移動局は、前記第１の情報を受信し、前記第２の基地局がコネクション切替対応不可であることを前記第１の情報に基づいて判定した場合に、前記制御装置への前記測定レポートの送信を抑止するよう構成されている、
   移動通信システム。
2. 第１のセルを生成する第１の基地局と、
   第２のセルを生成する第２の基地局と、
   前記第１及び第２の基地局と通信可能な移動局と、
   前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を制御する制御装置と、
   を備え、
   前記第２の基地局は、前記第２のセルへのコネクション切替に対する対応可否を判定可能な第１の情報を含む無線信号を前記第２のセル内に送信するよう構成され、
   前記移動局は、前記第１の情報を受信できるように構成され、
   前記制御装置は、前記第１の情報の受信結果の報告を前記移動局から受けるとともに、前記報告に基づいて前記第２の基地局がコネクション切替に対応できるか否かを認識するよう構成され、
   前記制御装置は、前記報告の要否を前記移動局に通知し、
   前記移動局は、前記制御装置からの要求に応じて、前記報告を行うか否かを決定する、移動通信システム。
3. 第１のセルを生成する第１の基地局と、
   第２のセルを生成する第２の基地局と、
   前記第１及び第２の基地局と通信可能な移動局と、
   前記第１のセルから前記第２のセルへの前記移動局のコネクション切替を制御する制御装置と、
   を備え、
   前記第２の基地局は、前記第２のセルへのコネクション切替に対する対応可否を判定可能な第１の情報を含む無線信号を前記第２のセル内に送信するよう構成され、
   前記第１の基地局、前記移動局、及び前記制御装置のうち少なくとも１つは、前記第１の情報の受信結果に基づいて、前記第２の基地局がコネクション切替に対応できるか否かを認識するよう構成され、
   前記第１の情報は、前記第２の基地局が準拠するシステムバージョンを表すバージョン情報を含む、移動通信システム。
4. 基地局装置であって、
   自セルを識別するセル識別情報、および前記自セルへの移動局のコネクション切替が可能か否かを示す第１の情報を含む報知情報を送信する送信手段を備え、
   前記第１の情報は、前記基地局装置が準拠するシステムバージョンを表すバージョン情報を含む、基地局装置。
5. 基地局との間で無線通信を行う無線通信手段と、
   隣接セルからの無線信号の受信品質に関する測定レポートを前記基地局又は前記基地局を管理する制御局に対して送信するか否かを、前記隣接セル内で報知され、前記隣接セルがコネクション切替に対応できるか否かを判定可能な第１の情報の解読結果に応じて決定する制御手段と、
   を備える移動局装置。

Images