JP2023172293A - 通信装置、移動通信システム、制御方法、ならびにプログラム - Google Patents

Abstract

【課題】バックアップＩＡＢノードを用いた効率的な通信を行う。【解決手段】移動通信システムにおいて第１のＩＡＢノードと通信するＩＡＢドナーとして動作する通信装置は、第１のＩＡＢノードと異なる第２のＩＡＢノードを検出する検出手段と、検出手段によって第２のＩＡＢノードが検出されたことに応じて、第１のＩＡＢノードに接続しているユーザ機器が第２のＩＡＢノードへハンドオーバーするためのハンドオーバー要求を送信する送信手段と、を備える。【選択図】図５

Description

本発明は、移動通信システムにおける通信の負荷分散処理に関するものである。

３ＧＰＰ（登録商標）（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、バックホール用の通信技術としてＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）の規格化が進んでいる。ＩＡＢは、基地局とユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）との間のアクセス通信を、バックホール通信として同時に利用する技術である（特許文献１）。ＩＡＢには、例えば、２８ＧＨｚ帯等のミリ波無線通信が利用される。

ＩＡＢの技術を用いたバックホール通信においては、ＩＡＢノードと呼ばれる中継機器が、ＩＡＢドナーと呼ばれる基地局からの通信をミリ波通信により中継する。ＩＡＢを用いることで、従来の光ファイバーなどによる有線通信と比較して低コストでエリアのカバレッジを広げることができる。

また、通信システムにおいて、ＵＥが無線リンク状況を監視し問題が生じた場合に基地局へ障害通知を行い、通知を受けた基地局が必要に応じてＵＥへハンドオーバー要求を行う技術が提案されている（特許文献２）。

ＩＡＢを用いた場合、バックホール通信においてＵＥは定期的に周辺環境情報（周辺に存在するＩＡＢノード間の電波強度情報など）を基地局へ通知する。ＵＥからの周辺環境情報を受けた基地局は、当該ユーザ機器に対して、他のＩＡＢノードへのハンドオーバー要求を必要に応じて行う。

特表２０１９－５３４６２５号公報 特開２０１８－１２１３４５号公報

ところで、多数のＵＥが密集している状況（スタジアムでのイベント、大規模オフラインイベント、災害現場など）においては、当該多数のＵＥが接続する周辺のＩＡＢノードが高負荷になる場合がある。また、災害により中継局が機能しなくなることにより相対的に健在の中継局が高負荷となる場合がある。

このような場合、ＩＡＢノードの負荷を減らすため、車などに搭載され臨時中継局として利用可能なＩＡＢノード（以下「バックアップＩＡＢノード」と呼ぶ）を設置することがある。その際、高負荷となっているＩＡＢノードとバックアップＩＡＢノードとで適切な負荷分散を図る必要がある。

しかしながら、従来のハンドオーバー技術では、基本的にＵＥが現在接続しているＩＡＢノードとの接続が切断されるか、ＵＥから収集した周辺環境情報に従って基地局が必要だと認めた場合にのみハンドオーバーが実施される。前述の状況下では、ＵＥとＩＡＢノードの間の電波強度が低下しているわけではないため切断判定はされない。また、混雑によりＵＥから基地局への周辺環境情報の通知が大幅に遅延することなどが考えられる。そのため、バックアップＩＡＢノードを利用した速やかな負荷分散を行うことが難しいという課題があった。

本発明は、このような問題に鑑みてなされたものであり、より効率的な通信を可能とする技術を提供することを目的としている。

上述の問題点を解決するため、本発明に係る通信装置は以下の構成を備える。すなわち、移動通信システムにおいて第１のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと通信するＩＡＢドナーとして動作する通信装置は、
前記第１のＩＡＢノードと異なる第２のＩＡＢノードを検出する検出手段と、
前記検出手段によって前記第２のＩＡＢノードが検出されたことに応じて、前記第１のＩＡＢノードに接続しているユーザ機器が前記第２のＩＡＢノードへハンドオーバーするためのハンドオーバー要求を送信する送信手段と、
を備える。

本発明によれば、より効率的な通信を行うことのできる技術を提供することができる。

通信装置のハードウェア構成を示すブロック図である。 通信装置の機能構成を示すブロック図である。 負荷分散前のシステム構成を示す図である。 負荷分散後のシステム構成を示す図である。 一般的なハンドオーバーのシーケンスを示した図である。 第１実施形態におけるハンドオーバーのシーケンスを示した図である。 報知情報の受信に係るＩＡＢドナーの一般的な動作フローチャートを示す。 周辺環境情報通知の受信に係るＩＡＢドナーの一般的な動作フローチャートを示す。 第１実施形態におけるＩＡＢドナーの動作フローチャートである。 第２実施形態におけるハンドオーバーのシーケンスを示した図である。 第２実施形態におけるＩＡＢドナーの動作フローチャートである。 第２実施形態におけるＵＥの動作フローチャートである。 変形例におけるハンドオーバーのシーケンスを示した図である。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

（第１実施形態）
本発明に係る通信装置の第１実施形態として、移動通信システムにおける基地局かつＩＡＢドナーとして動作する通信装置を例に挙げて以下に説明する。移動通信システムは、例えば、第５世代（５Ｇ）移動通信システムであり、ＩＡＢドナーには、１以上のＩＡＢノードが接続され、ＵＥは中継ノードであるＩＡＢノードを介してＩＡＢドナーと通信を行う。ＩＡＢノードは、ＮＲ（Ｎｅｗ Ｒａｄｉｏ）アクセスリンクと、ＮＲバックホールリンクの両方をサポートするＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）ノードであり得る。

＜装置構成＞
図１は、ＩＡＢドナーまたはＩＡＢノードとして機能する通信装置のハードウェア構成の一例を示すブロック図である。通信装置１０１は、制御部１０２、記憶部１０３、無線通信部１０４、アンテナ制御部１０５を含む。制御部１０２は、記憶部１０３に記憶される制御プログラムを実行することにより装置全体を制御する。記憶部１０３は、制御部１０２が実行する制御プログラムと、制御に使用される各種情報（セル情報や接続端末情報、ＩＡＢのルーティング情報等）と、を記憶する。後述する各種動作は、記憶部１０３に記憶された制御プログラムを制御部１０２が実行することにより実現される。無線通信部１０４は、３ＧＰＰ規格に準拠するＬＴＥ、５Ｇ等のセルラー網通信を行う。アンテナ制御部１０５は、無線通信部１０４にて行われる無線通信用のアンテナを制御する。

図２は、ＩＡＢドナーまたはＩＡＢノードとして機能する通信装置のソフトウェア機能構成の一例を示すブロック図である。通信装置機能２０１は、信号送信部２０２、信号受信部２０３、データ記憶部２０４、接続制御部２０５、報知情報検出部２０６、ハンドオーバー要求部２０７、報知情報生成部２０８を含む。信号送信部２０２および信号受信部２０３は、他装置（ＵＥなど）との間で３ＧＰＰ規格に準拠したＬＴＥ、５Ｇ等のセルラー網通信を実施する。データ記憶部２０４は、ソフトウェアプログラムおよび、ＩＡＢのルーティング情報や接続中端末に関する情報などを記憶保持している。

接続制御部２０５は、無線通信部１０４にて行われる無線通信を制御する。検出部２０６は、周辺に存在するＩＡＢノードからの報知情報を検出する。ハンドオーバー要求部２０７は、ＵＥに無線リソース制御（ＲＲＣ）メッセージを送信してハンドオーバー要求を行う。報知情報生成部２０８は、自装置（ＩＡＢノードである通信装置１０１）が存在する旨の信号を報知する。

＜システム構成および概略動作＞
図３Ａおよび図３Ｂはシステム構成を示す図であり、特に、後述する負荷分散処理に伴うＵＥのハンドオーバーが発生する前後の状態を例示的に示している。

ＩＡＢドナー３１１は配下にＩＡＢノード３０１～３０６を有し、ドナーおよび複数のノード間で経路３２０に示される通信経路を確立するよう構成されている。

大規模なイベント会場３３０においては、多数のＵＥ４００が密集しておりＵＥ群３３１を形成している。ＵＥ群３３１に含まれる多数のＵＥ４００は、基本的に最も近い（最も電波状況が良好な）通常ＩＡＢノードであるＩＡＢノード３０６へ接続している。そのため、ＩＡＢノード３０６は、極めて高負荷な状態となっている。このような場合、図３Ｂに示されるように、イベント会場３３０における通信の容量増大や負荷分散を目的として、バックアップＩＡＢノードである（例えば車載の）ＩＡＢノード３０７が設置されることがある。

このような状況においては、高負荷となっているＩＡＢノード３０６からバックアップＩＡＢノード３０７へ速やかに負荷分散を図りたいという要望がある。しかし、現状の３ＧＰＰ規格では、各ＵＥが接続しているＩＡＢノードとの接続が切断されるか、ＵＥから収集した周辺環境情報に従ってＩＡＢドナーが必要だと認めた場合にのみハンドオーバーが実施される。

ＩＡＢドナーが主導するハンドオーバーである後者では、具体的には、各ＵＥが周辺環境情報を収集しＩＡＢドナー３１１へ周辺環境情報通知を行い、通知された周辺環境情報をＩＡＢドナー３１１が分析する。そして、ＩＡＢドナー３１１は、ＵＥを他のＩＡＢノードにハンドオーバーさせたほうが良いと判断した場合、当該ＵＥに対してＲＲＣ接続の再構築要求（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）の通知を行う。ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージのフォーマットは、３ＧＰＰ ＴＲ ３８．３３１ ６．２．２に規定されている。このような処理を経て、ＵＥの他のＩＡＢノードへのハンドオーバーが開始されることになる。

このように、現状の３ＧＰＰ規格ではバックアップＩＡＢノードを投入しても、速やかにＵＥをハンドオーバーさせることは出来ない。すなわち、ＵＥの切断やＩＡＢドナーによる判断を待機する必要がある。また、ＩＡＢドナーは、ＩＡＢノードを経由して各ＵＥからの周辺環境情報の通知を受信するため、経由するＩＡＢノードが高負荷となっている場合には各ＵＥからの周辺環境情報の通知に遅延が生じる可能性が高い。

そこで、本実施形態では、ＩＡＢドナーが、ＵＥからの周辺環境情報の通知の受信有無に関わらず（受信完了を待機することなく）、高負荷ＩＡＢノードからバックアップＩＡＢノードへＵＥをハンドオーバーさせる形態について説明する。特に、ＵＥ４００がＩＡＢノード３０６を経由してＩＡＢドナー３１１との通信経路を構築している状況（図３Ａ）において、バックアップＩＡＢノード３０７をイベント会場３３０内に新たに設置する場合（図３Ｂ）のシステムの動作について説明する。

以下では、まず、図４、図６Ａ、図６Ｂを参照して３ＧＰＰ規格によるＩＡＢドナーが主導するハンドオーバーの一般的な動作について説明する。続けて、図５、図７を参照して第１実施形態におけるＩＡＢドナーが主導するハンドオーバーの動作について説明する。

＜３ＧＰＰ規格による一般的なハンドオーバー動作＞
図４は、ＩＡＢドナーが主導するハンドオーバーの一般的なシーケンスを示した図である。具体的には、ＵＥから通知された周辺環境情報に基づいて、ＵＥのハンドオーバーの必要有無を判定し、ＵＥにハンドオーバーさせる場合の処理である。

Ｓ４０１では、ＵＥ４００は、自身の周辺環境情報をＩＡＢドナー３１１へ通知すべく、周辺環境情報をＩＡＢノード３０６に送信する。周辺環境情報には、例えばＵＥ周辺に存在するＩＡＢノード間のＲＳＳＩ情報などが含まれる。Ｓ４０２では、ＩＡＢノード３０６は、受信した周辺環境情報をＩＡＢドナー３１１へ送信（転送）する。

Ｓ４０３では、ＩＡＢドナー３１１は、ＵＥ４００から通知された周辺環境情報をもとに、必要に応じて通知元のＵＥ４００に対してハンドオーバー通知を通知すべく、ハンドオーバー通知をＩＡＢノード３０６に送信する。本通知には３ＧＰＰ規格で定義されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いる。Ｓ４０４では、ＩＡＢノード３０６は、受信したハンドオーバー通知をＵＥ４００へ送信（転送）する。

Ｓ４０５では、ハンドオーバー通知を受けたＵＥ４００は、ＩＡＢノード３０７との間で同期確立処理並びにＲＡＣＨ処理を実施しＩＡＢノード３０７に接続する。同期確立処理並びにＲＡＣＨ処理は３ＧＰＰ規格で定義されており、ＵＥがＩＡＢノードへ初回接続する際に実施される。具体的には、ＵＥとＩＡＢノードとの間の同期およびＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）の周波数決定処理等を実施し、ＵＥとＩＡＢノードとの間のリンク同期を確立する処理である。

Ｓ４０６では、ＵＥ４００は、ハンドオーバー完了通知をＩＡＢドナー３１１へ通知すべく、ハンドオーバー完了通知をＩＡＢノード３０６に送信する。本通知には３ＧＰＰ規格で定義されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅメッセージを用いる。Ｓ４０７では、ＩＡＢノード３０６は、受信したハンドオーバー完了通知をＩＡＢドナー３１１へ送信（転送）する。

図６Ａは、報知情報の受信に係るＩＡＢドナーの一般的な動作フローチャートを示す。また、図６Ｂは、周辺環境情報通知の受信に係るＩＡＢドナーの一般的な動作フローチャートを示す。これらの待ち受け処理に順次性はなく、受信内容に応じて逐次対応した処理を実施する。通常、ＩＡＢドナーは、自ネットワークに接続してくるＩＡＢノードからの報知情報の検出や、ネットワーク配下のＵＥから通知される周辺環境情報の受信待ちを行っている（Ｆ６００）。

Ｆ６０１では、ＩＡＢドナーは、ＩＡＢノードからの報知情報を検出したか否かを判定する。検出した場合はＦ６０２に進み、検出しなかった場合はＦ６００に戻る。

Ｆ６０２では、ＩＡＢドナーは、検出した報知情報を送信したＩＡＢノードを自ネットワークで利用可能とするために、パス情報の再構築などの自ネットワークへの組み込み処理を実施する。その後Ｆ６００に戻るが、例えば受信待ち終了の指示があった場合は処理を終了する。

Ｆ６０３では、ＩＡＢドナーは、ＵＥからの周辺環境情報通知を（ＩＡＢノードを介して）受信したか否かを判定する。受信した場合はＦ６０４に進み、受信しなかった場合はＦ６００に戻る。

Ｆ６０４では、ＩＡＢドナーは、周辺環境情報通知の内容をチェックし、当該周辺環境情報通知を送信したＵＥのハンドオーバーが必要か否かを判断する。ハンドオーバーが必要だと判断した場合はＦ６０５に進み、ハンドオーバーが必要でないと判断した場合はＦ６００に戻る。

Ｆ６０５では、ＩＡＢドナーは、ハンドオーバー通知を（ＩＡＢノードを介して）ＵＥに対して送信する。

＜第１実施形態におけるハンドオーバー動作＞
図５は、第１実施形態におけるＩＡＢドナーが主導するハンドオーバーのシーケンスを示した図である。本シーケンスでは、ＩＡＢノード３０８を高負荷ＩＡＢノード（ＩＡＢノード３０６に対応）、ＩＡＢノード３０９をバックアップＩＡＢノード（ＩＡＢノード３０７に対応）として定義する。

ＵＥ４００は、ＩＡＢノード３０８経由でＩＡＢドナー３１１との通信経路を構築している。ＩＡＢノード３０８の負荷分散を図るためＩＡＢノード３０９が新たに設置される。

Ｓ５０１では、ＩＡＢノード３０９は、自身の存在を報知するためにＢｅａｃｏｎや専用のメッセージ等により報知情報を送信する。この時、報知情報に、「自身がバックアップとして設置されたＩＡＢノードである」または「自身がＩＡＢノード３０８のバックアップとして設置されたＩＡＢノードである」を含めてもよい。

報知情報は、３ＧＰＰ規格（３ＧＰＰ ＴＳ ３８．４１３の９．３．１項）に従って、特に報知情報フォーマットとしてＲａｄｉｏＮｅｔｗｏｒｋＬａｙｅｒで定義される報知情報フォーマットに従って報知される。このフォーマットは最大で２５６種別の情報を含めて報知することが可能なフォーマットとなっており、現行の規格で予約領域または空き領域となっている部分に上述の報知情報を付加して報知を実施する。

Ｓ５０２では、ＩＡＢノード３０９からの報知情報を検出したＩＡＢドナー３１１は、ＩＡＢノードチェック処理を行う。本チェック処理は、検出したＩＡＢノードがＩＡＢノード３０８のバックアップＩＡＢノードとして利用可能かどうかを判定する。

例えば、ＩＡＢノード３０８とＩＡＢノード３０９の位置情報を利用して、２つのＩＡＢノードの位置関係からバックアップＩＡＢノードとして利用可能な位置に存在しているかを判定する。また、報知情報に「自身がバックアップとして設置されたＩＡＢノードである」や「自身がＩＡＢノード３０８のバックアップとして設置されたＩＡＢノードである」という情報が含まれているかどうかを判定してもよい。

Ｓ５０３では、ＩＡＢドナー３１１は、ハンドオーバーを実行する対象とする１以上のＵＥの決定処理を実施する。つまり、高負荷ＩＡＢノードに接続されているＵＥの中から、バックアップＩＡＢノードへハンドオーバーさせる１以上のＵＥを選択するための処理である。この決定処理は、前述の判定処理によって高負荷ＩＡＢノードに接続されるＵＥをバックアップＩＡＢノードに負荷分散させてもよいと判断された場合に実施される。

例えば、「高負荷ＩＡＢノードに接続されているＵＥ数（例えば別途定めた閾値を超えているかどうか）」や「ハンドオーバー対象ＵＥの使用帯域量による重みづけ」を判定に用い、効果的に負荷分散を図れる１以上のＵＥをハンドオーバー対象として設定する。例えば、閾値を超えた個数のＵＥをランダムに選択しハンドオーバー対象として決定する。また、各ＵＥの使用帯域量（高負荷ＩＡＢノードにおける各ＵＥに関する負荷割合）の情報に基づいて、例えば、使用帯域量の多い順または少ない順に１以上のＵＥを選択してもよい。

Ｓ５０４では、ＩＡＢドナー３１１は、ハンドオーバー対象として設定されたＵＥに対してハンドオーバー通知を通知すべく、ハンドオーバー通知をＩＡＢノード３０８に送信する。本通知には３ＧＰＰ規格で定義されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いる。具体的には定義されるフォーマットのｄｅｄｉｃａｔｅｄＳＩＢ１－Ｄｅｌｉｖｅｒｙメッセージを用い、再接続先となるＩＡＢノード３０９のＩＤを指定する。または、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージフィールドに本通知専用の新規定義を追加してもよい。Ｓ５０５では、ＩＡＢノード３０８は、受信したハンドオーバー通知をＵＥ４００へ送信（転送）する。

ハンドオーバー通知を受けたＵＥ４００は、指定されたＩＡＢノード３０９へのハンドオーバーを実施する。以降の処理（Ｓ５０６～Ｓ５０８）は、３ＧＰＰ規格による一般的なハンドオーバー動作（Ｓ４０５～Ｓ４０７）と同様である。

図７は、第１実施形態におけるＩＡＢドナーの動作フローチャートを示す。ここでは、ＩＡＢドナーは、自ネットワークに接続してくるＩＡＢノードから報知情報の検出の受信待ちを行っている。

Ｆ７０１では、ＩＡＢドナーは、ＩＡＢノードからの報知情報を検出する。以下の説明は、報知情報を検出した前提で記載している。

Ｆ７０２では、ＩＡＢドナーは、検出した報知情報を送信したＩＡＢノードを自ネットワークへの組み込む処理を実施する（この処理はＦ６０２と同様である）。

Ｆ７０３では、ＩＡＢドナーは、ネットワーク上（ＩＡＢドナーの配下にある１以上のＩＡＢノードの中）に高負荷となっているＩＡＢノードが存在するか否かの負荷判定を実施する。存在すると判定した場合はＦ７０４に進み、存在しないと判定した場合は処理を終了する。

判定基準として、例えば、処理負荷やトラフィックの輻輳率の閾値を用い、高負荷状態や輻輳が頻繁に発生しているＩＡＢノードを高負荷ＩＡＢノードとして検出する。

Ｆ７０４では、ＩＡＢドナーは、Ｆ７０１で検出した報知情報を送信したＩＡＢノードは高負荷ＩＡＢノードのバックアップＩＡＢノードとして利用可能かどうかの判定を実施する。バックアップＩＡＢノードとして利用可能と判定した場合はＦ７０５に進み、利用不可能と判定した場合は処理を終了する。

例えば、高負荷ＩＡＢノードの位置情報と検出したＩＡＢノードの位置情報を利用して、２つのＩＡＢノードの位置関係からバックアップＩＡＢノードとして利用可能な位置に存在しているかを判定する。また、Ｆ７０１で検出した報知情報に「自身がバックアップとして設置されたＩＡＢノードである」や「自身が特定の高負荷ＩＡＢノードのバックアップとして設置されたＩＡＢノードである」という情報が含まれているかどうかを判定してもよい。

Ｆ７０５では、ＩＡＢドナーは、ハンドオーバーの対象とするＵＥの決定処理を行う。つまり、高負荷ＩＡＢノードに接続されているＵＥに対して、どのＵＥをハンドオーバー実施対象とするかの判定を実施する。

本判定処理は、高負荷ＩＡＢノードに接続されているＵＥを適切にバックアップＩＡＢノードへハンドオーバーさせるために実施するものである。例えば、「高負荷ＩＡＢノードに接続されているＵＥ数（例えば別途定めた閾値を超えているかどうか）」や「ハンドオーバー対象ＵＥの使用帯域量による重みづけ」を判定に用い、効果的に負荷分散を図れる１以上のＵＥをハンドオーバー対象として設定する。

Ｆ７０６では、ＩＡＢドナーは、Ｆ７０５で決定した１以上のＵＥへのハンドオーバー通知を行う。本通知には３ＧＰＰ規格で定義されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いる。具体的には定義されるフォーマットのｄｅｄｉｃａｔｅｄＳＩＢ１－Ｄｅｌｉｖｅｒｙメッセージを用い、再接続先となるバックアップＩＡＢノードのＩＤを指定する。または、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージフィールドに本通知専用の新規定義を追加してもよい。

なお、Ｆ７０１～Ｆ７０６の順序は上述のものに限定されない。例えば、Ｆ７０３とＦ７０４の処理順を変えても構わない。また、Ｆ７０１において検出した報知情報に「自身が特定の高負荷ＩＡＢノードのバックアップとして設置されたＩＡＢノードである」という情報が含まれていた場合、当該ＩＡＢノードは意図的に設置されているとみなしてもよい。すなわち、高負荷ＩＡＢノードの負荷分散に限定されないバックアップＩＡＢノードとして設置されているとみなしてもよい。この場合、Ｆ７０３においてネットワーク上に高負荷ＩＡＢノードを検出できなかった場合であっても、ＵＥに対するハンドオーバー通知（Ｆ７０５、Ｆ７０６）を実施してもよい。

以上説明したとおり第１実施形態によれば、新規のＩＡＢノードが検出されかつ所定の条件を満たす場合に、ＩＡＢドナーが主導するハンドオーバーを実施する。ここでは、所定の条件は、既存の１以上のＩＡＢノードの中に高負荷となっているものが存在し、かつ、新規のＩＡＢノードが高負荷のＩＡＢノードのバックアップとして利用可能であることである。すなわち、ＵＥの切断検知やＵＥからの周辺環境情報通知を待たずに、１以上のＵＥを、高負荷ＩＡＢノードからバックアップＩＡＢノードへハンドオーバーさせる。

この制御により、多数のＵＥが密集している状況において新規のＩＡＢノードを設置した際に、速やかにＵＥをハンドオーバーさせることが可能となり、効果的な通信の負荷分散が可能となる。

（第２実施形態）
第２実施形態では、第１実施形態における動作に加え、ＩＡＢドナーからのハンドオーバー通知を受けたＵＥが、ハンドオーバー可否のチェックを行う形態について説明する。この形態は、例えば、バックアップＩＡＢノードに接続可能なＵＥをイベント参加者が使用しているＵＥに限定したい場合などを想定している。なお、装置構成、システム構成、ＩＡＢドナーおよびＩＡＢノードの動作については第１実施形態（図１～図３Ｂ、図５、図７）と同様であるため説明は省略する。

＜第２実施形態におけるハンドオーバー動作＞
図８は、第２実施形態におけるＩＡＢドナーが主導するハンドオーバーのシーケンスを示した図である。本シーケンスでは、第１実施形態と同様に、ＩＡＢノード３０８を高負荷ＩＡＢノード（ＩＡＢノード３０６に対応）、ＩＡＢノード３０９をバックアップＩＡＢノード（ＩＡＢノード３０７に対応）として定義する。

ＵＥ４００は、ＩＡＢノード３０８経由でＩＡＢドナー３１１との通信経路を構築している。ＩＡＢノード３０８の負荷分散を図るためＩＡＢノード３０９が新たに設置される。Ｓ８０１～Ｓ８０３の処理は第１実施形態（Ｓ５０１～Ｓ５０３）の処理と同様であるため説明は省略する。

Ｓ８０４では、ＩＡＢドナー３１１は、ハンドオーバー対象として設定されたＵＥ４００に対してハンドオーバー通知を通知すべく、ハンドオーバー通知をＩＡＢノード３０８に送信する。Ｓ８０５では、ＩＡＢノード３０８は、受信したハンドオーバー通知をＵＥ４００へ送信（転送）する。

本通知には３ＧＰＰ規格で定義されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いる。具体的には定義されるフォーマットのｄｅｄｉｃａｔｅｄＳＩＢ１－Ｄｅｌｉｖｅｒｙメッセージを用い、再接続先となるＩＡＢノード３０９のＩＤを指定する。または、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージフィールドに本通知専用の新規定義を追加してもよい。例えば、新規定義の情報として「バックアップノードへのハンドオーバー」である旨の情報を追加する。本情報を付与することにより、ハンドオーバー通知を受けたＵＥは、本ハンドオーバーがバックアップＩＡＢノードへのハンドオーバーであることを知ることができる。

Ｓ８０６では、ハンドオーバー通知を受けたＵＥ４００は、指定されたバックアップＩＡＢノード（ここではＩＡＢノード３０９）へのハンドオーバー可否のチェックを実施する。

Ｓ８０６でハンドオーバー不可と判定された場合（チェックＮＧ）は、Ｓ８０７、Ｓ８０８において、ＵＥ４００は、ＩＡＢノード３０８を介してハンドオーバー不可通知をＩＡＢドナー３１１へ通知する。本メッセージをＩＡＢドナーへ通知する方法はいくつか考えられるが、例えばＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅメッセージ内にハンドオーバー不可情報を含めて通知する方法がある。また、本メッセージ用にＲＲＣメッセージを新設する方法を利用することも可能である。

Ｓ８０６でハンドオーバー可能と判定された場合（チェックＯＫ）は、ＵＥ４００は、指定されたＩＡＢノード３０９へのハンドオーバーを実施する。この場合の処理（Ｓ８０９～Ｓ８１１）は、３ＧＰＰ規格による一般的なハンドオーバー動作（Ｓ４０５～Ｓ４０７）と同様である。

図９は、第２実施形態におけるＩＡＢドナーの動作フローチャートを示す。なお、Ｆ９０６以外の処理は第１実施形態（Ｆ７０１～Ｆ７０５）と同様であるため説明は省略する。

Ｆ９０６では、ＩＡＢドナーは、Ｆ９０５で決定した１以上のＵＥへのハンドオーバー通知を行う。本通知には３ＧＰＰ規格で定義されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いる。ここでは、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージフィールドに「バックアップノードへのハンドオーバー」である旨を示す新規定義を追加するものとする。

なお、Ｆ９０１～Ｆ９０６の順序は上述のものに限定されない。例えば、Ｆ９０３とＦ９０４の処理順を変えても構わない。

図１０は、第２実施形態におけるＵＥの動作フローチャートを示す。本フローチャートは、ＵＥがハンドオーバー通知を受信した前提で記載している。

Ｆ１００１では、ＵＥは、ＩＡＢドナーからのハンドオーバー通知を受信する。

Ｆ１００２では、ＵＥは、ハンドオーバー通知内に「バックアップノードへのハンドオーバー」である旨の情報が含まれているかの判定を実施する。含まれている場合はＦ１００３に進み、含まれていない場合はＦ１００４に進む。なお、ＩＡＢドナーが図６Ｂに示す一般的な（３ＧＰＰ規格に従った）ハンドオーバー通知を行っていた場合、通知内に「バックアップノードへのハンドオーバー」である旨は含まれないことになる。

Ｆ１００３では、ＵＥは、受信したハンドオーバー通知がバックアップＩＡＢノードへのハンドオーバー通知だとみなす。そして、指定されたバックアップＩＡＢノードへハンドオーバー可能か否かを判定する。ハンドオーバー可能と判定した場合はＦ１００４に進み、ハンドオーバー不可と判定した場合はＦ１００５に進む。

判定方法として、例えば、ＵＥが特定の認証（ＭＡＣアドレス認証や８０２．１Ｘ認証など）を事前に通過しているかどうかをチェックする方法が考えられる。例えば、ＵＥが事業者が用意している認証サイトへ事前にアクセスするようにしておき、認証に成功していた場合は認証が成功している旨の情報をシステム情報へ保存する。この時、バックアップＩＡＢノードを事業者が用意しているのであれば、バックアップＩＡＢノードを識別可能な情報を含めて保存してもよい。ＵＥは、Ｓ８０６のチェック処置時に当該システム情報を参照し、現在の認証状態によってハンドオーバー可否を決定する。

また、他の例としては、ハンドオーバー対象のＵＥの接続範囲内にバックアップＩＡＢノードが本当に存在しているかどうかチェックする方法が考えられる。すなわち、従来のＩＡＢドナーが主導するハンドオーバーはＵＥからの周辺環境情報通知に従ったものであった。すなわち、当該ＵＥの周辺環境情報通知がＩＡＢドナーへ届いており、ＵＥの接続範囲内にバックアップＩＡＢノードが存在していることが担保できた。しかし、第２実施形態ではその担保がないため、このようなチェックすることを想定している。

具体的なチェック方法としては、例えば、ＵＥが周辺環境のスキャンを実施し生成するＩＡＢノードリスト内に、指定されたバックアップＩＡＢノードが存在するかどうかチェックする方法がある。また、ハンドオーバー要求を受信したタイミングでＵＥが周辺環境のスキャンを実施して、指定されたバックアップＩＡＢノードが存在するかどうかチェックする方法がある。

Ｆ１００４では、ＵＥは、通常の（３ＧＰＰ規格に従った）ハンドオーバー処理を実施する。一方、Ｆ１００５では、ＵＥは、ＩＡＢドナーへハンドオーバー不可通知を行う。本メッセージをＩＡＢドナーへ通知する方法はいくつか考えられる。例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅメッセージ内にハンドオーバー不可情報を含めて通知する方法や、本メッセージ用にＲＲＣメッセージを新設する方法などが考えられる。

以上説明したとおり第２実施形態によれば、ハンドオーバー通知を受けたＵＥは、ハンドオーバー可否のチェックを行う。例えば、バックアップＩＡＢノードに接続可能なＵＥをイベント参加者が使用しているＵＥに限定したい場合には、ＵＥが特定の認証を事前に通過しているかどうかをチェックしハンドオーバー可否の判定を行う。また、ＵＥの接続範囲内にバックアップＩＡＢノードが存在していることが担保されない状況においても、適切に負荷分散を制御することが可能となる。

（変形例）
第１実施形態や第２実施形態においては、ハンドオーバー対象のＵＥの決定処理をＩＡＢドナーが行うものとして説明したが、既存の（高負荷の）ＩＡＢノードが行うよう構成してもよい。

＜変形例におけるハンドオーバー動作＞
図１１は、変形例におけるＩＡＢドナーが主導するハンドオーバーのシーケンスを示した図である。本シーケンスでは、第１実施形態と同様に、ＩＡＢノード３０８を高負荷ＩＡＢノード（ＩＡＢノード３０６に対応）、ＩＡＢノード３０９をバックアップＩＡＢノード（ＩＡＢノード３０７に対応）として定義する。

ＵＥ４００は、ＩＡＢノード３０８経由でＩＡＢドナー３１１との通信経路を構築している。ＩＡＢノード３０８の負荷分散を図るためＩＡＢノード３０９が新たに設置される。Ｓ１１０１～Ｓ１１０２およびＳ１１０６～Ｓ１１０８の処理は第１実施形態（Ｓ５０１～Ｓ５０２およびＳ５０６～Ｓ５０８）の処理と同様であるため説明は省略する。

Ｓ１１０３では、ＩＡＢドナー３１１は、ＵＥのハンドオーバーに関する開始要求を通知すべく、ハンドオーバー通知をＩＡＢノード３０８に送信する。本通知には３ＧＰＰ規格で定義されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いる。ただし、この時点では、ハンドオーバーの開始要求が含まれているものの、具体的にどのＵＥがハンドオーバー対象であるかは指定されていない。そのため、メッセージフィールド内にハンドオーバー開始要求を示す新規定義を追加してもよい。

Ｓ１１０４では、ＩＡＢノード３０８は、ハンドオーバーの対象とする１以上のＵＥの決定処理を実施する。本決定処理は、第１および第２実施形態においてＩＡＢドナーが実施していた処理（Ｓ５０３、Ｓ８０３）と同様の処理となる。

Ｓ１１０５では、ＩＡＢノード３０８は、Ｓ１１０４で決定した１以上のＵＥに対して、Ｓ１１０３で受信したハンドオーバー通知を送信（転送）する。

なお、Ｓ１１０４において、ＩＡＢノード３０８は、接続されているＵＥが特定の認証を通過しているかどうかを判定に用いてもよい。この場合、ＩＡＢノード３０８が、各ＵＥが特定の認証を通過しているかどうかの情報をＩＡＢドナー３１１から取得するよう構成してもよい。

例えば、ＵＥが事業者が用意している認証サイトへ事前にアクセスするようにしておき、認証に成功していた場合は認証が成功している旨の情報をシステム情報へ保存する。ＵＥはＩＡＢドナーへの環境情報通知処理において当該情報を含めて通知しておく。この時、バックアップＩＡＢノードを事業者が用意しているのであれば、バックアップＩＡＢノードを識別可能な情報を含めて保存してもよい。例えば、ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔメッセージ内のＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔ－ＩＥｓフィールド内に本情報用の領域を新設して通知を行うことが出来る。

これにより、混雑前に取得していたＵＥの周辺環境情報からＩＡＢドナーがイベント参加者のＵＥを特定することが可能となる。そのため、イベント参加者ではないＵＥへのハンドオーバー通知を抑制することができ、システム全体のメッセージ数を削減することが可能となる。

本明細書の開示は、以下の通信装置およびプログラムを含む。また、移動通信システムおよび制御方法も含む。
（項目１）
移動通信システムにおいて第１のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと通信するＩＡＢドナーとして動作する通信装置であって、
前記第１のＩＡＢノードと異なる第２のＩＡＢノードを検出する検出手段と、
前記検出手段によって前記第２のＩＡＢノードが検出されたことに応じて、前記第１のＩＡＢノードに接続しているユーザ機器が前記第２のＩＡＢノードへハンドオーバーするためのハンドオーバー要求を送信する送信手段と、
を備えることを特徴とする通信装置。
（項目２）
前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるかを判定する判定手段を更に備え、
前記送信手段は、前記判定手段により前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であると判定された場合に、前記ハンドオーバー要求を送信することを特徴とする項目１に記載の通信装置。
（項目３）
前記第１のＩＡＢノードが所定の閾値より高負荷の状態にあるか否かを判定する負荷判定手段をさらに備え、
前記判定手段は、前記負荷判定手段により高負荷の状態にあると判定された前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるか否かを判定する
ことを特徴とする項目２に記載の通信装置。
（項目４）
前記移動通信システムは、第５世代（５Ｇ）移動通信システムであり、
前記第１のＩＡＢノードおよび前記第２のＩＡＢノードはバックホールリンクとアクセスリンクとの両方をサポートする
ことを特徴とする項目１から３の何れか１項目に記載の通信装置。
（項目５）
前記送信手段は、無線リソース制御（ＲＲＣ）メッセージを用いて前記ハンドオーバー要求を送信する
ことを特徴とする項目１から４の何れか１項目に記載の通信装置。
（項目６）
前記送信手段は、前記第１のＩＡＢノードに接続しているユーザ機器からの周辺環境情報の通知の受信有無に関わらず、前記ハンドオーバー要求を送信する
ことを特徴とする項目１から５の何れか１項目に記載の通信装置。
（項目７）
前記検出手段は、前記第２のＩＡＢノードの存在を示す報知情報を受信することにより前記第２のＩＡＢノードを検出し、
前記報知情報は、前記第２のＩＡＢノードが前記第１のＩＡＢノードのバックアップノードとして設置されたＩＡＢノードであることを示す第１の情報を含む
ことを特徴とする項目１から６の何れか１項目に記載の通信装置。
（項目８）
前記送信手段は、前記報知情報に前記第１の情報が含まれる場合、バックアップノードへのハンドオーバーである旨の情報を前記ハンドオーバー要求に含める
ことを特徴とする請項目７に記載の通信装置。
（項目９）
前記判定手段は、前記第１のＩＡＢノードの位置情報と前記第２のＩＡＢノードの位置情報とに基づいて、前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるか否かを判定する
ことを特徴とする項目２に記載の通信装置。
（項目１０）
前記検出手段は、前記第２のＩＡＢノードの存在を示す報知情報を受信することにより前記第２のＩＡＢノードを検出し、
前記判定手段は、前記報知情報に、前記第２のＩＡＢノードが前記第１のＩＡＢノードのバックアップとして設置されたＩＡＢノードであることを示す第１の情報が含まれるか否かに基づいて、前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるか否かを判定する
ことを特徴とする項目２に記載の通信装置。
（項目１１）
前記ハンドオーバー要求におけるハンドオーバーの対象となる１以上のユーザ機器を決定する決定手段を更に備え、
前記送信手段は、前記決定手段により決定された前記１以上のユーザ機器に対して、前記ハンドオーバー要求を送信する
ことを特徴とする項目１から１０の何れか１項目に記載の通信装置。
（項目１２）
前記決定手段は、前記第１のＩＡＢノードに接続しているユーザ機器の個数が閾値を超えている場合、該閾値を超えた個数のユーザ機器をハンドオーバーの対象となる１以上のユーザ機器として決定する
ことを特徴とする項目１１に記載の通信装置。
（項目１３）
前記決定手段は、前記第１のＩＡＢノードに接続しているユーザ機器それぞれの使用帯域量の情報に基づいて、ハンドオーバーの対象となる１以上のユーザ機器を決定する
ことを特徴とする項目１１に記載の通信装置。
（項目１４）
前記決定手段は、前記第１のＩＡＢノードに接続しているユーザ機器それぞれの所定の認証サイトにおける認証状態に基づいて、ハンドオーバーの対象となる１以上のユーザ機器を決定する
ことを特徴とする項目１１に記載の通信装置。
（項目１５）
通信部を有するコンピュータを、項目１から１４のいずれか１項目に記載の通信装置として動作させるためのプログラム。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１０１ 通信装置； １０２ 制御部； １０３ 記憶部； １０４ 無線通信部； １０５ アンテナ制御部； ２０１ 通信装置機能； ２０２ 信号送信部； ２０３ 信号受信部； ２０４ データ記憶部； ２０５ 接続制御部； ２０６ 報知情報検出部； ２０７ ハンドオーバー要求部； ２０８ 報知情報生成部

Claims (18)

1. 移動通信システムにおいて第１のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと通信するＩＡＢドナーとして動作する通信装置であって、
   前記第１のＩＡＢノードと異なる第２のＩＡＢノードを検出する検出手段と、
   前記検出手段によって前記第２のＩＡＢノードが検出されたことに応じて、前記第１のＩＡＢノードに接続しているユーザ機器が前記第２のＩＡＢノードへハンドオーバーするためのハンドオーバー要求を送信する送信手段と、
   を備えることを特徴とする通信装置。
2. 前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるかを判定する判定手段を更に備え、
   前記送信手段は、前記判定手段により前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であると判定された場合に、前記ハンドオーバー要求を送信することを特徴とする請求項１に記載の通信装置。
3. 前記第１のＩＡＢノードが所定の閾値より高負荷の状態にあるか否かを判定する負荷判定手段をさらに備え、
   前記判定手段は、前記負荷判定手段により高負荷の状態にあると判定された前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるか否かを判定する
   ことを特徴とする請求項２に記載の通信装置。
4. 前記移動通信システムは、第５世代（５Ｇ）移動通信システムであり、
   前記第１のＩＡＢノードおよび前記第２のＩＡＢノードはバックホールリンクとアクセスリンクとの両方をサポートする
   ことを特徴とする請求項１に記載の通信装置。
5. 前記送信手段は、無線リソース制御（ＲＲＣ）メッセージを用いて前記ハンドオーバー要求を送信する
   ことを特徴とする請求項１に記載の通信装置。
6. 前記送信手段は、前記第１のＩＡＢノードに接続しているユーザ機器からの周辺環境情報の通知の受信有無に関わらず、前記ハンドオーバー要求を送信する
   ことを特徴とする請求項１に記載の通信装置。
7. 前記検出手段は、前記第２のＩＡＢノードの存在を示す報知情報を受信することにより前記第２のＩＡＢノードを検出し、
   前記報知情報は、前記第２のＩＡＢノードが前記第１のＩＡＢノードのバックアップノードとして設置されたＩＡＢノードであることを示す第１の情報を含む
   ことを特徴とする請求項１に記載の通信装置。
8. 前記送信手段は、前記報知情報に前記第１の情報が含まれる場合、バックアップノードへのハンドオーバーである旨の情報を前記ハンドオーバー要求に含める
   ことを特徴とする請求項７に記載の通信装置。
9. 前記判定手段は、前記第１のＩＡＢノードの位置情報と前記第２のＩＡＢノードの位置情報とに基づいて、前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるか否かを判定する
   ことを特徴とする請求項２に記載の通信装置。
10. 前記検出手段は、前記第２のＩＡＢノードの存在を示す報知情報を受信することにより前記第２のＩＡＢノードを検出し、
    前記判定手段は、前記報知情報に、前記第２のＩＡＢノードが前記第１のＩＡＢノードのバックアップとして設置されたＩＡＢノードであることを示す第１の情報が含まれるか否かに基づいて、前記第１のＩＡＢノードの負荷分散に前記第２のＩＡＢノードが利用可能であるか否かを判定する
    ことを特徴とする請求項２に記載の通信装置。
11. 前記ハンドオーバー要求におけるハンドオーバーの対象となる１以上のユーザ機器を決定する決定手段を更に備え、
    前記送信手段は、前記決定手段により決定された前記１以上のユーザ機器に対して、前記ハンドオーバー要求を送信する
    ことを特徴とする請求項１に記載の通信装置。
12. 前記決定手段は、前記第１のＩＡＢノードに接続しているユーザ機器の個数が閾値を超えている場合、該閾値を超えた個数のユーザ機器をハンドオーバーの対象となる１以上のユーザ機器として決定する
    ことを特徴とする請求項１１に記載の通信装置。
13. 前記決定手段は、前記第１のＩＡＢノードに接続しているユーザ機器それぞれの使用帯域量の情報に基づいて、ハンドオーバーの対象となる１以上のユーザ機器を決定する
    ことを特徴とする請求項１１に記載の通信装置。
14. 前記決定手段は、前記第１のＩＡＢノードに接続しているユーザ機器それぞれの所定の認証サイトにおける認証状態に基づいて、ハンドオーバーの対象となる１以上のユーザ機器を決定する
    ことを特徴とする請求項１１に記載の通信装置。
15. 基地局と、第１の中継ノードと、該第１の中継ノードを介して前記基地局と通信するユーザ機器と、を有する移動通信システムであって、
    前記基地局は、
    前記第１の中継ノードと異なる第２の中継ノードを検出する検出手段と、
    前記検出手段によって前記第２の中継ノードが検出されたことに応じて、前記第１の中継ノードに接続しているユーザ機器が前記第２の中継ノードへハンドオーバーするためのハンドオーバー要求を送信する送信手段と、
    を備え、
    前記ユーザ機器は、
    前記基地局からの前記ハンドオーバー要求を受信する受信手段と、
    前記ハンドオーバー要求が示す前記第２の中継ノードへのハンドオーバーが可能であるか否かを判定する第２の判定手段と、
    前記第２の判定手段により前記第２の中継ノードへのハンドオーバーが不可能であると判定された場合、前記基地局にその旨を通知する通知手段と、
    を備える
    ことを特徴とする移動通信システム。
16. 基地局と、第１の中継ノードと、該第１の中継ノードを介して前記基地局と通信するユーザ機器と、を有する移動通信システムであって、
    前記基地局は、
    前記第１の中継ノードと異なる第２の中継ノードを検出する検出手段と、
    前記検出手段によって前記第２の中継ノードが検出されたことに応じて、前記第１の中継ノードに接続しているユーザ機器が前記第２の中継ノードへハンドオーバーするための第１のハンドオーバー要求を前記第１の中継ノードへ送信する第１の送信手段と、
    を備え、
    前記第１の中継ノードは、
    前記基地局からの前記第１のハンドオーバー要求を受信する受信手段と、
    前記第１のハンドオーバー要求に基づくハンドオーバーの対象となる１以上のユーザ機器を決定する決定手段と、
    前記決定手段により決定された前記１以上のユーザ機器に対して、前記第２の中継ノードへのハンドオーバーを指示する第２のハンドオーバー要求を送信する第２の送信手段と、
    を備える
    ことを特徴とする移動通信システム。
17. 移動通信システムにおいて第１のＩＡＢノードと通信するＩＡＢドナーとして動作する通信装置の制御方法であって、
    前記第１のＩＡＢノードと異なる第２のＩＡＢノードを検出する検出工程と、
    前記検出工程によって前記第２のＩＡＢノードが検出されたことに応じて、前記第１のＩＡＢノードに接続しているユーザ機器が前記第２のＩＡＢノードへハンドオーバーするためのハンドオーバー要求を送信する送信工程と、
    を含むことを特徴とする制御方法。
18. 通信部を有するコンピュータを、請求項１から１４のいずれか１項に記載の通信装置として動作させるためのプログラム。

Images