特開 2024-162536 基地局装置、通信装置、制御方法、プログラム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024162536

(43)【公開日】2024-11-21

(54)【発明の名称】基地局装置、通信装置、制御方法、プログラム

(51)【国際特許分類】

   H04W 76/18 20180101AFI20241114BHJP

   H04W 16/26 20090101ALI20241114BHJP

   H04W 48/02 20090101ALI20241114BHJP

【ＦＩ】

H04W76/18

H04W16/26

H04W48/02

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2023078127

(22)【出願日】2023-05-10

(71)【出願人】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】110002871

【氏名又は名称】弁理士法人坂本国際特許商標事務所

(72)【発明者】

【氏名】青▲柳▼ 瑞穂

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA22

5K067DD11

5K067EE02

5K067EE06

5K067EE10

5K067JJ39

(57)【要約】

【課題】モバイルＩＡＢを含みうるＩＡＢネットワーク環境でマルチホップ構成を制限する仕組みを提供する。
【解決手段】通信サービスの提供に関連する基地局装置であって、一のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードに対する外部装置からの接続要求を取得する取得手段と、少なくとも、一のＩＡＢノードがモバイルＩＡＢノードであり、かつ、外部装置が他のＩＡＢノードである場合、前記接続要求を拒否する処理を行う処理手段と、を備えることを特徴とする、基地局装置が開示される。
【選択図】図１

【特許請求の範囲】

【請求項1】

通信サービスの提供に関連する基地局装置であって、
一のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードに対する外部装置からの接続要求を取得する取得手段と、
少なくとも、前記一のＩＡＢノードがモバイルＩＡＢノードであり、前記外部装置が他のＩＡＢノードである場合、前記接続要求を拒否する処理を行う処理手段と、
を備えることを特徴とする、基地局装置。

【請求項2】

前記処理手段は、前記外部装置がＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）である場合、前記接続要求を受け入れることを特徴とする、請求項１に記載の基地局装置。

【請求項3】

前記接続要求は、前記外部装置がＩＡＢノードであるか否かの種別情報を含むことを特徴とする、請求項２に記載の基地局装置。

【請求項4】

前記処理手段は、更に、特定の設定が前記基地局装置になされている場合であって、前記外部装置がモバイルＩＡＢノードである場合に、前記接続要求を拒否する一方、前記特定の設定が前記基地局装置になされている場合であっても、前記外部装置がＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又は固定のＩＡＢノードである場合、前記接続要求を受け入れることを特徴とする、請求項１に記載の基地局装置。

【請求項5】

前記接続要求は、前記外部装置がモバイルＩＡＢノードであるか否かの識別情報を含む、ことを特徴とする請求項４に記載の基地局装置。

【請求項6】

前記処理手段は、更に、前記外部装置が他のＩＡＢノードである場合であって、前記接続要求を受け入れた場合に前記他のＩＡＢノードまでのホップ数が閾値を超える場合に、前記接続要求を拒否することを特徴とする、請求項１から５のうちのいずれか１項に記載の基地局装置。

【請求項7】

移動体に搭載され、又は、移動体の形態であり、ＩＡＢネットワークを構成可能な通信装置であって、
一のＩＡＢノードに対して接続要求を行う要求手段と、
前記接続要求が受け入れられた場合に、前記一のＩＡＢノードを介して通信サービスを配下のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）に提供する処理手段とを備え、
前記要求手段は、モバイルＩＡＢノードであることを示す識別情報を前記接続要求に含めることを特徴とする、通信装置。

【請求項8】

通信を制御する制御方法であって、
一のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードに対する外部装置からの接続要求を取得する取得工程と、
少なくとも、前記一のＩＡＢノードがモバイルＩＡＢノードであり、前記外部装置が他のＩＡＢノードである場合、前記接続要求を拒否する処理を行う処理工程と、
を有することを特徴とする制御方法。

【請求項9】

コンピュータに、
一のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードに対する外部装置からの接続要求を取得する工程と、
少なくとも、前記一のＩＡＢノードがモバイルＩＡＢノードであり、前記外部装置が他のＩＡＢノードである場合、前記接続要求を拒否する処理を行う工程と、
を実行させるためのプログラム。

【請求項10】

通信装置の制御方法であって、
一のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードに対して、モバイルＩＡＢノードであることを示す識別情報を含む接続要求を送信する工程と、
前記接続要求が受け入れられた場合に、前記一のＩＡＢノードを介して配下のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）に無線接続を提供する工程と、
を有することを特徴とする、制御方法。

【請求項11】

通信装置のコンピュータに、
一のＩＡＢノードに対して、モバイルＩＡＢノードであることを示す識別情報を含む接続要求を送信する工程と、
前記接続要求が受け入れられた場合に、前記一のＩＡＢノードを介して配下のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）に無線接続を提供する工程と、
を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、基地局装置、通信装置、制御方法、及びプログラムに関する。

【背景技術】

【0002】

３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）（登録商標）において、バックホール用の通信技術としてＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）の規格化が進んでいる。

【0003】

ＩＡＢ技術は、基地局とユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）との間のアクセス通信に用いられる２８ＧＨｚ帯等のミリ波無線通信を、バックホール通信として利用する技術である（特許文献１）。

【0004】

ＩＡＢ技術を用いたバックホール通信網（以降、ＩＡＢネットワーク）において、ＩＡＢノードと呼ばれる中継機器は、従来の基地局に相当するＩＡＢドナーからの通信を宛先のＵＥまで中継（基地局リレー）する。ＩＡＢノードは、ＵＥからの接続を受け入れる基地局相当の機能を有する。

【0005】

３ＧＰＰでは次期Ｒｅｌｅａｓｅ－１８において、５Ｇセルラーカバレッジと接続性の改善に対する需要に対し、Ｖｅｈｉｃｌｅ－Ｍｏｕｎｔｅｄ Ｒｅｌａｙを実現するモバイルＩＡＢの仕様策定を予定している。Ｖｅｈｉｃｌｅ－Ｍｏｕｎｔｅｄ Ｒｅｌａｙは、車両に搭載されたＩＡＢノードが基地局リレーを行う技術に関する。

【0006】

当該仕様策定の議論においては、従来仕様では満たさないＩＡＢノードとＵＥが互いに移動するモビリティシナリオならではの要件が発生することが考えられている。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】特表２０１９－５３４６２５号公報

【発明の概要】

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

【0008】

例えば、モバイルＩＡＢがマルチホップ構成を許容する場合、モバイルＩＡＢノードを含むＩＡＢネットワークが形成された状態でモバイルＩＡＢノード配下にＩＡＢノードが接続されうる。この状態で上位のモバイルＩＡＢノードが車両共々移動されるとＩＡＢネットワークの維持が困難になりうる。その結果、配下のＩＡＢノード及びＵＥの通信サービスを継続することができなくなりうる。また、他にもＩＡＢネットワークの構成によっては、配下にＩＡＢノードを接続することが好ましくないケースが想定されうる。この点、現行の規格においてもモバイルＩＡＢを含みうるＩＡＢネットワーク環境でマルチホップ構成を制限する仕組みは提案されていない。

【0009】

本発明は、上述の課題の少なくとも１つを鑑みなされたものである。本発明の１つの側面としては、モバイルＩＡＢを含みうるＩＡＢネットワーク環境でマルチホップ構成を制限する仕組みの提供を目的とする。

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

【0010】

本発明の１つの側面としての基地局装置は、通信サービスの提供に関連する基地局装置であって、
一のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードに対する外部装置からの接続要求を取得する取得手段と、
少なくとも、前記一のＩＡＢノードがモバイルＩＡＢノードであり、前記外部装置が他のＩＡＢノードである場合、前記接続要求を拒否する処理を行う処理手段と、
を備えることを特徴とする。

【発明の効果】

【0011】

本発明の１つの側面によれば、モバイルＩＡＢを含みうるＩＡＢネットワーク環境でマルチホップ構成を制限する仕組みを提供することが可能となる。

【図面の簡単な説明】

【0012】

【図1】本実施形態における移動通信システムの一例を示す図である。

【図1A】図１の移動通信システムにおける他の状況を示す説明図である。

【図2】本実施形態におけるモバイルＩＡＢノードのハードウェア機能ブロック図である。

【図3A】本実施形態におけるモバイルＩＡＢノードのソフトウェア機能ブロック図である。

【図3B】本実施形態におけるＩＡＢドナーのソフトウェア機能ブロック図である。

【図4】実施形態１におけるモバイルＩＡＢノード及びＩＡＢノードの接続制御処理シーケンス図である。

【図5】実施形態１における外部装置からの接続要求に対するＩＡＢドナーの処理フローであるである。

【図6】実施形態２におけるモバイルＩＡＢノード及びＩＡＢノードの接続制御処理シーケンス図である。

【図6A】実施形態２における外部装置からの接続要求に対するＩＡＢドナーの処理フローである。

【図7】実施形態３におけるモバイルＩＡＢノード及びＩＡＢノードの接続制御処理フローである。

【図7A】実施形態３における外部装置からの接続要求に対するＩＡＢドナーの処理フローである。

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

【0013】

以下、添付図面を参照しながら各実施形態について詳細に説明する。

【0014】

［実施形態１］
図１は本実施形態における移動通信システムの一例を示す図である。

【0015】

図１に示す例では、公衆網通信サービスをセルカバレッジ１０１、１０２に対し提供しているネットワークにおいて、ＣＮ１００への接続を提供するＩＡＢドナー１０３、１０４が存在する。

【0016】

セルカバレッジ１０１内においてＩＡＢドナー１０３にはＩＡＢノード１０５～１０７及びモバイルＩＡＢノード１０８が無線接続しＩＡＢネットワークを形成している。図１において、ＣＮはＣｏｒｅ Ｎｅｔｗｏｒｋの略であり、端末であるＵＥ１０９～１１４の認証等の様々な処理を担う。

【0017】

ＩＡＢドナー１０３は、各ＩＡＢノード１０５～１０７及びモバイルＩＡＢノード１０８を統括的に制御し、自局のカバーするセルカバレッジ１０１を形成する。ＩＡＢドナー１０４も同様に、自局のカバーするセルカバレッジ１０２を形成する。

【0018】

ＩＡＢネットワーク内では、通信パケットとしてＢＡＰデータＰＤＵのフォーマットに従った通信パケット（以降、ＢＡＰデータパケット）が使用される。ＰＤＵはＰｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔの略である。

【0019】

例えば、ＣＮ１００からＵＥ１０９を宛先とするＩＰパケットは、ＩＡＢドナー１０３において、ＢＡＰデータパケットへとカプセル化され、ＩＡＢノード１０５に転送される。また、転送されたＢＡＰデータパケットは、ＩＡＢノード１０５で再度ＩＰパケットに戻され、宛先ＵＥ１０９へ届けられる。

【0020】

同様に、ＵＥ１０９からのＩＰパケットについてもＩＡＢノード１０５でＢＡＰデータパケットへとカプセル化される。そして、ＩＡＢドナー１０３で再度ＩＰパケットに戻され、ＣＮ１００へ転送される。なお、ＩＰはＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌの略である。

【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】

Ｓ６０６では、モバイルＩＡＢノード１０８はＩＡＢノード１０５への接続要求を行う。この時モバイルＩＡＢノード１０８は接続要求信号として発するＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔに自身の識別情報を付加する。ここで付加する情報は実施形態１で定義したものとする。

【0080】

具体的には、モバイルＩＡＢノード１０８は、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔをＩＡＢノード１０５に送信する。そして、ＩＡＢノード１０５は、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔを含むＩＮＩＴＩＡＬ ＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＳＦＥＲ ＭＥＳＳＡＧＥをＩＡＢドナー１０３に送信する（Ｓ６０６、Ｓ６０７）。

【0081】

Ｓ６０８では、ＩＡＢドナー１０３は、ＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＳＦＥＲ ＭＥＳＳＡＧＥを受信すると、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔを取り出す。そして、ＩＡＢドナー１０３は、取り出したＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔの付加フィールド内の識別情報に基づいて、接続種別識別情報を蓄積する。

【0082】

Ｓ６０９では、ＩＡＢドナー１０３は、Ｓ６０８で得た識別情報に基づいて、ＩＡＢノードからの接続要求であることを確認する。すなわち、Ｓ６０９では、ＩＡＢドナー１０３は、Ｓ６０８で得た種別情報に基づいて、接続要求を試みている外部装置がモバイルＩＡＢノード（モバイルＩＡＢノード１０８）であることを確認する。その結果、Ｓ６１０では、ＩＡＢドナー１０３は、モバイルＩＡＢノード１０８によるＩＡＢノード１０５への接続要求に対して拒否を決定する。そして、Ｓ６１１では、ＩＡＢドナー１０３は、モバイルＩＡＢノード１０８に対しＲＲＣＲｅｊｅｃｔを用いて接続拒否を行う（Ｓ６１２、Ｓ６１３）。

【0083】

図６Ａは、実施形態２における外部装置からの接続要求に対するＩＡＢドナー１０３の処理フローである。

【0084】

図６Ａに示す処理は、実施形態１に関連して図５に示した処理に対して、Ｓ５０１がＳ５０１Ａで置換された点が異なる。

【0085】

Ｓ５０１Ａでは、ＩＡＢドナー１０３は、Ｓ５００で取得した識別情報に基づいて、接続要求を試みている外部装置がモバイルＩＡＢノード１０８であるかどうかを判断する。接続要求を行う外部装置がモバイルＩＡＢノード１０８である場合、ＩＡＢドナー１０３は外部装置がモバイルＩＡＢノード１０８であることを識別し接続を拒否する（Ｓ５０２）。他方、接続要求を行う外部装置がＩＡＢノード（固定された通信ノード）である場合、ＩＡＢドナー１０３は今回の接続要求を許可する（Ｓ５０３）。

【0086】

ところで、本実施形態とは異なる比較例として、ＩＡＢノード１０５へのモバイルＩＡＢノード１０８からの接続要求を許可した場合、以下のとおり不都合が生じうる。すなわち、ＩＡＢノード１０５を含むＩＡＢネットワークが形成された状態でモバイルＩＡＢノード１０８が接続されることになる。この状態でモバイルＩＡＢノード１０８が移動すると、ＩＡＢネットワークの維持が困難になりうる。

【0087】

これに対して、本実施形態によれば、このような比較例で生じうる不都合を低減できる。すなわち、ＩＡＢノードへのモバイルＩＡＢノード１０８からの接続要求を拒否することで、このような比較例で生じうる不都合を低減できる。

【0088】

このようにして、実施形態２によれば、上述した実施形態１と同様に、モバイルＩＡＢノード１０８を含むＩＡＢネットワーク環境でマルチホップ構成を適切に制限する仕組みを成立させることができる。また、実施形態２によれば、事前に設定されたルール（具体的には、ＩＡＢネットワークとしてモバイルＩＡＢノード１０８の接続を許可しないというルール）に基づいて、マルチホップ構成を適切に制限できる。なお、実施形態２では接続要求の一例であるＲＲＣ ＳｅｔｕｐＲｅｑｕｅｓｔに対しｉａｂ－ＴｙｐｅＩｎｄｉｃａｔｉｏｎを含め、接続要求の一例であるＲＲＣ ＳｅｔｕｐＣｏｍｐｌｅｔｅに対しｉａｂ－ＮｏｄｅＩｎｄｉｃａｔｉｏｎを含める場合を例示した。しかしながらこれに限定されず、ｉａｂ－ＴｙｐｅＩｎｄｉｃａｔｉｏｎとｉａｂ－ＮｏｄｅＩｎｄｉｃａｔｉｏｎの両方をＲＲＣ ＳｅｔｕｐＲｅｑｕｅｓｔに含めるように構成することもできる。
また、ｉａｂ－ＴｙｐｅＩｎｄｉｃａｔｉｏｎとｉａｂ－ＮｏｄｅＩｎｄｉｃａｔｉｏｎの両方をＲＲＣ ＳｅｔｕｐＣｏｍｐｌｅｔｅに含めるように構成することもできる。前者を採用した場合、接続の早い段階で接続可否を判断することができ、演算コストを削減することができる。後者を採用した場合、現行の通信規格を大きく改変することなく接続可否を判断できるようになる。言い換えると、すでにｉａｂ－ＮｏｄｅＩｎｄｉｃａｔｉｏｎフォーマットを含めることが定義済みのＲＲＣ ＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに対して、ｉａｂ－ＴｙｐｅＩｎｄｉｃａｔｉｏｎを追加するだけで接続可否のための情報を伝達できるようになる。

【0089】

なお、本実施形態２は、上述した実施形態１と有効に組み合わせることができる。この場合、接続要求に係る要求元がモバイルＩＡＢノード１０８でありかつ要求先がモバイルＩＡＢノード１０８である場合に、接続要求が拒否されてもよい。なお、本実施形態では、ＩＡＢドナー１０３が接続要求の拒否を行う場合を例示したが下位ノードで拒否の判断を行うように構成することもできる。この場合、モバイルＩＡＢノードの接続を許可しないというルールが事前共有されているＩＡＢノード１０５は、ＩＡＢノード１０８から受信した接続要求（ＲＲＣ ＳｅｔｕｐＲｅｑｕｅｓｔ）の内容を参照する。続けて、ＩＡＢノード１０５は、接続要求に含まれるｉａｂ－ＴｙｐｅＩｎｄｉｃａｔｉｏｎがモバイルＩＡＢノードを示す値（例えば「１」）である場合に、接続要求を拒否すると判断する。接続要求を拒否すると判断した場合、ＩＡＢノード１０５は、モバイルＩＡＢノード１０８に対する応答メッセージであるＲＲＣ ｒｅｊｅｃｔメッセージを送信することで接続要求を拒否する。一方、ＩＡＢノード１０５は、接続要求に含まれるｉａｂ－ＴｙｐｅＩｎｄｉｃａｔｉｏｎがモバイルＩＡＢノードを示す値（例えば「１」）でない場合に、接続要求を上位のＩＡＢノードであるＩＡＢドナー１０５に転送する。以降の接続処理は上述の実施形態で説明した接続処理を行うようにすればよい。この実施形態２の変形例によれば、下流のＩＡＢノードにおいて、事前に共有されたルール（具体的には、ＩＡＢネットワークとしてモバイルＩＡＢノード１０８の接続を許可しないというルール）に基づいて、マルチホップ構成を適切に制限できる。

【0090】

［実施形態３］
図１ＡにおいてＩＡＢドナー１０３、ＩＡＢノード１０５から１０７によってＩＡＢネットワークが形成されている状態でモバイルＩＡＢノード１０８がＩＡＢネットワークへの参加を試みＩＡＢノード１０７への接続を試みる場合の処理について述べる。

【0091】

本実施形態において形成されるＩＡＢネットワークではＩＡＢノードの構成ホップ数Ｎが定義されている。構成ホップ数Ｎの“Ｎ”は、２以上の自然数であり、Ｎ段以降のＩＡＢノードへのモバイルＩＡＢノード１０８の接続は許可されないことを意味する。

【0092】

実施形態３においてはＩＡＢノード構成ホップ数Ｎ＝２（閾値の一例）とする。

【0093】

図７は実施形態３におけるモバイルＩＡＢノード１０８及びＩＡＢノード１０７の接続制御処理シーケンス図である。

【0094】

Ｓ７００～Ｓ７０３では、ＩＡＢドナー１０３、ＩＡＢノード１０７、及びモバイルＩＡＢノード１０８は、実施形態１と同様に報知信号を送受信する。

【0095】

Ｓ７０４では、ＩＡＢノード１０７はＩＡＢドナー１０３に自局のＩＡＢネットワークにおけるＩＡＢ構成ホップ数を通知する。

【0096】

この時自身のホップ数を把握する手段としては、ＴＳ３８．４０１ ８．１２に定義されるＩＡＢ－ｎｏｄｅ Ｉｎｔｅｇｒａｔｉｏｎ ＰｒｏｃｅｄｕｒｅのＰｈａｓｅ２－２：Ｒｏｕｔｉｎｇ ｕｐｄａｔｅを利用できる。すなわち、Ｐｈａｓｅ２－２：Ｒｏｕｔｉｎｇ ｕｐｄａｔｅにおいて、ＩＰアドレスを取得する際に例えばＴｒａｃｅｒｏｕｔｅを実行することで自身のＩＡＢネットワークにおけるホップ数を把握することができる。

【0097】

この情報はＢＡＰを通じてＩＡＢドナー１０３へ通知することができる。

【0098】

Ｓ７０５ではＩＡＢネットワークとしてＩＡＢノード構成ホップ数Ｎ＝２と定義し、ＩＡＢネットワークを構成するＩＡＢノード１０５～１０７へ通知する。

【0099】

ついで、モバイルＩＡＢノード１０８は、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔをＩＡＢノード１０７に送信する。そして、ＩＡＢノード１０７は、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔを含むＩＮＩＴＩＡＬ ＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＳＦＥＲ ＭＥＳＳＡＧＥをＩＡＢドナー１０３に送信する（Ｓ７０６、Ｓ７０７）。

【0100】

Ｓ７０８では、ＩＡＢドナー１０３は、ＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＳＦＥＲ ＭＥＳＳＡＧＥを受信すると、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔを取り出す。

【0101】

Ｓ７０９では、ＩＡＢドナー１０３は、ＩＡＢノード１０７のホップ数を把握し、接続要求を試みているモバイルＩＡＢノード１０８の識別情報から接続拒否を判断する。例えば、ＩＡＢドナー１０３は、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔを含むＩＮＩＴＩＡＬ ＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＳＦＥＲ ＭＥＳＳＡＧＥをＩＡＢノード１０７から受信した場合、次のとおりであってよい。まず、ＩＡＢドナー１０３は、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔを送信したＩＡＢノードのホップ数は、ＩＡＢノード１０７のホップ数＋１（つまり、図７の例では２）であると判断してもよい。そして、現在のホップ数が構成ホップ数Ｎである場合、ＩＡＢドナー１０３は、モバイルＩＡＢノード１０８によるＩＡＢノード１０７への接続要求に対して拒否を決定する。その結果、Ｓ７１０では、ＩＡＢドナー１０３は、モバイルＩＡＢノード１０８によるＩＡＢノード１０７への接続要求に対して拒否を決定する。そして、Ｓ７１１では、ＩＡＢドナー１０３は、モバイルＩＡＢノード１０８に対しＲＲＣＲｅｊｅｃｔを用いて接続拒否を行う（Ｓ７１２、Ｓ７１３）。なお、接続要求を試みている外部装置がモバイルＩＡＢノード１０８でなく、ＵＥである場合は、ＩＡＢドナー１０３は、接続要求を受け入れることとしてもよい。

【0102】

図７Ａは、実施形態３における外部装置からの接続要求に対するＩＡＢドナー１０３の処理フローである。

【0103】

図７Ａに示す処理は、実施形態１に関連して図５に示した処理に対して、Ｓ５０１の判定結果が“ＹＥＳ”である場合に、Ｓ５０２に代えて、Ｓ７００に進む点が異なる。

【0104】

Ｓ７００では、ＩＡＢドナー１０３は、現在のホップ数が構成ホップ数Ｎであるかどうかを判断する。そして、現在のホップ数が構成ホップ数Ｎである場合、ＩＡＢドナー１０３は、今回の接続要求を拒否する（Ｓ５０２）。他方、現在のホップ数が構成ホップ数Ｎよりも小さい場合、ＩＡＢドナー１０３は今回の接続要求を許可する（Ｓ５０３）。

【0105】

なお、図７Ａでは、Ｓ５０１の判定処理は、実施形態１に関連して図５に示した処理と同じであるが、異なってもよい。例えば、図７Ａにおいては、Ｓ５０１に代わる処理として、ＩＡＢドナー１０３は、Ｓ５００で取得した種別情報に基づいて、接続要求を試みている外部装置がＩＡＢノードであるかどうかを判断するだけでもよい。すなわち、図７Ａにおいては、接続要求に係る接続先がモバイルＩＡＢノード１０８であるか否かは判定されなくてもよい。

【0106】

ところで、本実施形態とは異なる比較例として、ホップ数を考慮しない条件に基づいて接続要求を許可した場合、以下のとおり不都合が生じうる。すなわち、ホップ数が過大となるＩＡＢネットワークが形成されうり、かかる状態では、ネットワーク維持の複雑性が増し、安定したＩＡＢネットワークの維持が困難になりうる。

【0107】

これに対して、本実施形態によれば、このような比較例で生じうる不都合を低減できる。すなわち、ホップ数が構成ホップ数Ｎを超えるような接続要求を拒否することで、このような比較例で生じうる不都合を低減できる。

【0108】

このようにして、実施形態３によれば、上述した実施形態１と同様に、モバイルＩＡＢノード１０８を含むＩＡＢネットワーク環境でマルチホップ構成を適切に制限する仕組みを成立させることができる。また、実施形態３によれば、事前に設定されたルール（具体的には、ホップ数が構成ホップ数Ｎを超えるようなＩＡＢノードの接続を許可しないというルール）に基づいて、マルチホップ構成を適切に制限できる。

【0109】

なお、本実施形態３は、上述した実施形態２と有効に組み合わせることができる。例えば、本実施形態３と実施形態２と有効に組み合わせる場合、接続要求に係る要求元がモバイルＩＡＢノード１０８でありかつ現在のホップ数が構成ホップ数Ｎである場合に、接続要求が拒否されてもよい。

【0110】

［その他の実施形態］
上述の実施形態にて説明したように、識別情報の送受信はＲＲＣでの識別信号の付加による識別処理を想定している。すなわち、ＴＳ３８．４０１ ８．１２にて定義される３ＧＰＰ規格によるＩＡＢノードの接続シーケンスＩＡＢ－ｎｏｄｅ Ｉｎｔｅｇｒａｔｉｏｎ ＰｒｏｃｅｄｕｒｅにおけるＰｈａｓｅ１：ＩＡＢ－ＭＴ ｓｅｔｕｐに相当する処理方法として記載した。しかしながら、Ｐｈａｓｅ２－１：ＢＨ ＲＬＣ ｃｈａｎｎｅｌ ｅｓｔａｂｌｉｓｈｍｅｎｔや、Ｐｈａｓｅ２－２：Ｒｏｕｔｉｎｇ ｕｐｄａｔｅ、Ｐｈａｓｅ３：ＩＡＢ－ＤＵ ｓｅｔｕｐの各Ｐｈａｓｅ等にて識別を実施してもよい。

【0111】

また、上述した実施形態では、公衆網通信サービスに関するが、ローカル５Ｇ又はその類に適用されてもよい。

【0112】

以上の実施形態に関して、更に以下の付記を開示する。

【0113】

［付記１］
通信サービスの提供に関連する基地局装置であって、
一のＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードに対する外部装置からの接続要求を取得する取得手段と、
少なくとも、前記一のＩＡＢノードがモバイルＩＡＢノードであり、かつ、前記外部装置が他のＩＡＢノードである場合、前記接続要求を拒否する処理を行う処理手段と、
を備えることを特徴とする、基地局装置。

【0114】

［付記２］
前記処理手段は、前記外部装置がＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）である場合、前記接続要求を受け入れることを特徴とする、付記１に記載の基地局装置。

【0115】

［付記３］
前記接続要求は、前記外部装置がＩＡＢノードであるか否かの種別情報を含むことを特徴とする付記１又は２に記載の基地局装置。

【0116】

［付記４］
前記処理手段は、更に、特定の設定が前記基地局装置になされている場合であって、前記外部装置がモバイルＩＡＢノードである場合に、前記接続要求を拒否する一方、前記特定の設定が前記基地局装置になされている場合であっても、前記外部装置がＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又は固定のＩＡＢノードである場合、前記接続要求を受け入れることを特徴とする付記１から３のうちのいずれか１項に記載の基地局装置。

【0117】

［付記５］
前記接続要求は、前記外部装置がモバイルＩＡＢノードであるか否かの識別情報を含む、ことを特徴とする付記１から４のうちのいずれか１項に記載の基地局装置。

【0118】

［付記６］
前記処理手段は、更に、前記外部装置が他のＩＡＢノードである場合であって、前記接続要求を受け入れた場合に前記他のＩＡＢノードまでのホップ数が閾値を超える場合に、前記接続要求を拒否することを特徴とする、付記１から５のうちのいずれか１項に記載の基地局装置。

【符号の説明】

【0119】

１０１ セルカバレッジ
１０２ セルカバレッジ
１０３ ＩＡＢドナー（基地局装置の一例）
１０４ ＩＡＢドナー
１０５ ＩＡＢノード（通信装置の一例）
１０６ ＩＡＢノード（通信装置の一例）
１０７ ＩＡＢノード（通信装置の一例）
１０８ モバイルＩＡＢノード（通信装置の一例）
１０９～１１４ ＵＥ
２０１ 制御部（処理手段及び要求手段の一例）
２０２ 記憶部
２０３ 無線通信部（取得手段の一例）
２０４ アンテナ制御部
３０１ ソフトウェア機能ブロック
３０２ 信号送信部
３０３ 信号受信部
３０４ データ記憶部
３０５ 接続制御部
３０８ 信号生成部
４０１ ソフトウェア機能ブロック
４０２ 信号送信部
４０３ 信号受信部
４０４ データ記憶部
４０５ 接続制御部
４０６ ネットワーク構成情報管理部

【図1】

【図1A】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図6A】

【図7】

【図7A】