JP7766512B2 - 制御装置、制御方法、およびプログラム - Google Patents

Description

本発明は、制御装置、制御方法、およびプログラムに関する。

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

ＩＡＢ技術を用いたバックホール通信において、基地局に相当するＩＡＢドナーと、中継局に相当するＩＡＢノードとの間の無線環境の悪化や障害の発生に備え、通信パスの切り替えによって通信状況を復旧、改善することが検討されている（特許文献２）。特許文献２では、すでに確立している通信パスの通信環境が悪化した場合に、ネットワークスライスをサポートするＩＡＢノードを選択して通信パスを切り替えることが開示されている。

特表２０１９－５３４６２５号公報 国際公開２０２０／０３１２６９号

ここで、特許文献２では、ＩＡＢドナーはＵＥから要求されたスライス種別のみに基づいてパスを選択する。このような場合、ネットワークトポロジーの更新によるホップ数の増加や、ＩＡＢノードの処理負荷の上昇や接続端末数の変化などによって要求されたスライス種別をサポートできなくなる場合がある。

本発明は、このような課題に鑑み、接続可能なＩＡＢノードの通信状況に応じて通信パスを制御することを目的とする。

上記の課題を解決するため、本発明における制御装置は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ネットワークの制御装置であって、
前記ＩＡＢネットワークのＩＡＢドナーと所定のＩＡＢノードとの間の接続を中継するためのＩＡＢノードであって、前記所定のＩＡＢノードと接続可能なＩＡＢノードの通信状況を示す動的情報を取得する取得手段と、
前記取得手段で取得した前記動的情報に含まれ、前記所定のＩＡＢノードがサポートすべきスライス種別に対応する、少なくとも１つの種類の情報を選択し、選択した前記情報に応じて前記所定のＩＡＢノードと前記ＩＡＢドナーとの間の通信パスを制御するパス制御手段と、
前記所定のＩＡＢノードから通信パスの再確立の要求、無線リンク障害の通知、およびフロー制御フィードバックを含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）信号を受信する第１受信手段と、
を備え、
前記第１受信手段が、所定の期間内に複数のＩＡＢノードから前記ＲＲＣ信号を受信した場合に、前記パス制御手段は、接続するユーザ装置の数が多いＩＡＢノードの通信パスを優先して制御する。

本発明によれば、接続可能なＩＡＢノードの通信状況に応じて通信パスを制御することができる。

本実施形態に係るバックホール通信システムの一例を示す図 本実施形態に係るＩＡＢドナー１０１のハードウェア機能ブロック図 本実施形態に係るＩＡＢドナー１０１のソフトウェア機能ブロック図 本実施形態に係る新規接続先の決定判断方法を示すフローチャート 実施形態１に係るＵＲＬＬＣのスライス要求時の新規接続先の決定方法を示すフローチャート 実施形態１に係るＩＡＢノード１０５における接続候補リストの一例を示す図 本実施形態に係るＩＡＢドナー１０１及び、各ＩＡＢノード１０２～１０６のＮＳＳＡＩリストの一例を示す図 本実施形態に係るＩＡＢドナー１０１が管理する動的情報リストの一例を示す図 実施形態１に係る接続先パスの接続確立を示すシーケンス図 実施形態１に係る新規通信パス接続後のトポロジを示す図 実施形態２に係るｅＭＢＢのスライス要求時の新規接続先の決定方法を示すフローチャート 実施形態２に係る新規通信パス接続後のトポロジを示す図 実施形態３に係るＭＩｏｔのスライス要求時の新規接続先の決定方法を示したフローチャート 実施形態３に係る新規通信パス接続後のトポロジを示す図

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものではなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

ＩＡＢ技術を用いたバックホール通信においては、ＩＡＢノードと呼ばれる中継機器が従来の基地局に相当するＩＡＢドナーからの通信を中継する。ＩＡＢノードは、他の複数のＩＡＢノードとの間で通信リンクを形成し、ＩＡＢドナーを始点としたネットワークツリーを形成することで、ＩＡＢドナーがネットワークアクセスを提供可能なエリアを拡大することが可能である。

ＩＡＢ技術において、ＩＡＢドナーとＩＡＢノード、ＩＡＢノード間はＢＡＰ（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を介して制御される。ＢＡＰは、主に複数のＩＡＢノード間でデータをルーティングするためのプロトコルとして規定されている。

また、ＩＡＢ技術においては、接続するユーザ装置（ＵＥ）からのスライス要求信号の受信に応じて、異なる条件に対応するネットワークスライスを共通ネットワーク上に仮想的に提供する、ネットワークスライシングという概念の導入検討が進んでいる。

ネットワークスライスの種別としては、高速大容量（ｅＭＢＢ）、低遅延（ＵＲＬＬＣ）、同時多重接続（ＭＩｏｔ）が既に規定されている。例えば、基地局が提供するネットワークスライスを報知し、ＵＥが目的に応じて選択、もしくは、ＵＥがネットワークスライスを要求し、基地局が応答することで利用できる仕組みの検討が進められている。ここで、ｅＭＢＢはｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ ＢｒｏａｄＢａｎｄの略である。また、ＵＲＬＬＣはＵｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、ＭＩｏＴはＭａｓｓｉｖｅ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓの略である。

例えば、ｅＭＢＢでは、高スループットの通信が要求されるため、ｅＭＢＢをサポートするＩＡＢノードはアップリンクまたはダウンリンクのデータバッファの確保が要求されうる。また、例えばＵＲＬＬＣでは、低遅延の通信が要求されるため、ＵＲＬＬＣを要求するＩＡＢノードはＩＡＢドナーまでのホップ数を少なくすることが要求されうる。また、例えばＭＩｏＴでは、多数のＵＥを接続する必要があるため、通信パスにおける合計ＵＥ数の閾値を超えないようにする必要がある場合がある。

ここで、ＩＡＢ技術を用いたバックホール通信において、上位接続されたＩＡＢドナーやＩＡＢノードの能力不足、もしくは、通信状況が悪化したためにスライス要件を満たせないＩＡＢノードが発生する場合がある。この問題に対して、要求されたスライス種別に対応する機能を持たないＩＡＢノードを特定し、要求されたスライス種別を満たすＩＡＢノードを移行先に選択することで、適切なパス切り替えやマルチパス接続を行う技術が提案されている。

しかしながら、通信パスを形成するＩＡＢノードがＵＥから要求されるスライス種別を満たす場合であっても、動的に変化する通信状況に従い、上述したスライス要件を満たさない場合がある。

以下の実施形態では、動的に変化する通信状況に関する動的情報を取得し、要求されたスライス種別に基づいて動的情報の中から情報を選択し、通信パスを制御することでスライス種別をサポート可能な通信パスを設定する通信システムについて説明する。

＜実施形態１＞
図１は本実施形態に係る無線通信システム１００の一例を示す図である。無線通信システム１００は、ＣＮ（Ｃｏｒｅ Ｎｅｔｗｏｒｋ）１３０への接続を提供するＩＡＢドナー１０１と、ＩＡＢノード１０２～１０６とを含むバックホールネットワーク（ＩＡＢネットワーク）を含む。ここで、ＣＮは端末であるＵＥ１１０～１２０の認証やパケットの転送制御、通信経路の確立等の様々な処理を担う。

ＩＡＢドナー１０１は、各ＩＡＢノード１０２～１０６を統括的に制御し、自局のカバーするエリアを形成する。また、ＩＡＢドナー１０１により各ＩＡＢノード１０２～１０６に対して、各々がサポート可能なネットワークスライスの種別が決定、割り当てられているものとする。すなわち、ＩＡＢドナー１０１は各ＩＡＢノード１０２～１０６のサポートするネットワークスライスの種別に関する情報を管理する。本実施形態では、ＩＡＢドナー１０１は、各ＩＡＢノード１０２～１０６がサポートしているスライス情報をＮＳＳＡＩ（Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）のリストとして管理しているものとする。また、ＩＡＢノード１０２～１０６においてサポート可能なスライスに変化がある場合には、ＢＡＰ制御メッセージによりＩＡＢドナー１０１へ通知されるものとする。

ＢＡＰ制御メッセージとは、ＢＡＰ制御ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）のフォーマットに従い、やり取りされるメッセージである 。また、制御情報としてＰＤＵタイプフィールドを利用して通知しても良いし、ＢＡＰ制御メッセージの他の予約済み（Ｒｅｓｅｒｖｅｄ）フィールドを使用してもよい。

ＵＥ１１０～１２０は、各ＩＡＢノード１０２～１０６の提供する所望のスライスを利用したアプリケーションを実行しているものとする。例えば、ＵＥ１１８はｅＭＢＢのスライスを要求するアプリケーションを実行し、ＵＥ１１９は、ＵＲＬＬＣを要求するアプリケーションを実行している。例えば、ｅＭＢＢはＵＲＬＬＣと比較して高スループット（大容量）の通信経路を必要とし、ＵＲＬＬＣはｅＭＢＢと比較して低い通信遅延や低いパケットロス率の通信経路を必要とするなど、スライスごとに異なる要件（スライス要件）を有する。

ここで、無線通信システム１００において、ＩＡＢノード１０４とＩＡＢノード１０５間の無線区間で無線品質が低下し、リンク障害が発生したものとする。この場合、ＩＡＢノード１０５では、特定のスライスとしてｅＭＢＢのみが要件を満たさなくなり、ＩＡＢノード１０５に接続するＵＥのうち、ＵＥ１１８が実行するアプリケーションにエラーが発生する場合がある。

このような場合、ＩＡＢノード１０５は、自局がｅＭＢＢのスライス要件を満たさなくなったこと（スライス要件未達）を検知し、ＩＡＢドナー１０１へＮＳＳＡＩの変更をＢＡＰ制御メッセージにより通知する。ここで、ＩＡＢノード１０５におけるスライス要件未達は、ＩＡＢドナー１０１またはＩＡＢノード１０５がＵＥ１１８からｅＭＢＢのスライス要求を示す制御メッセージを受信することで検知してもよい。あるいは、スライス要件未達は、ＲＲＭ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ）により定期的に測定されるＩＡＢノード１０４からの信号品質によりＩＡＢドナー１０１またはＩＡＢノード１０５が判断してもよい。

ＩＡＢノード１０４はリンク障害が発生したＩＡＢノード１０５との通信を復旧するため、ＩＡＢノード１０４からＩＡＢノード１０３を経由してＩＡＢノード１０５までの新規通信パスを構築し、通信を継続しうる。このような場合、ＩＡＢノード１０５は、ＵＥ１１８からのｅＭＢＢのスライス要求を継続して満たすことができる場合がある。しかしながら、通信パスの切り替えによってホップ数が増加したため、ＵＥ１１９の要求するＵＲＬＬＣのスライスに対しては低遅延の機能を実行できないなど、スライス要件を満たせなくなる場合が生じる。

このような場合において、ＵＥから要求されたスライス要件を満たせなくなったＩＡＢノードを救済するために、ＩＡＢドナー１０１は新たな通信パスを形成するためにＩＡＢノードの接続先を決定し、該当するＩＡＢノードに通知する。

図２は本実施形態に係るＩＡＢドナー１０１のハードウェア機能ブロック図である。ＩＡＢドナー１０１は制御部２０１、記憶部２０２、無線通信部２０３及び、アンテナ制御部２０４を含む。ここでは、ＩＡＢドナー１０１であるものとしてハードウェアの説明を行うが、ＩＡＢノード１０２～１０６も同様の構成であるものとする。

制御部２０１は、記憶部２０２に記憶される制御プログラムを実行することによりＩＡＢドナー１０１全体を制御する。制御部２０１は、プロセッサ及びメモリを含む。記憶部２０２は、制御部２０１が実行する制御プログラムや、ＩＡＢドナー１０１が提供するセルの識別子（セルＩＤ）やＩＡＢドナー１０１またはＩＡＢノードに接続するＵＥに関する情報、ＩＡＢノードのルーティング情報等の各種情報を記憶する。後述する各種動作は、記憶部２０２に記憶された制御プログラムを制御部２０１が実行することにより行われる。

無線通信部２０３は、３ＧＰＰ規格に準拠するＬＴＥ、５Ｇ等のセルラー網通信を行うための無線通信回路を備える通信部である。また、無線通信部２０３は、各ＩＡＢノード１０２～１０６及び、ＵＥ１１０～１２０との通信状況をＲＲＭに従い、測定可能であり、ＲＲＣにより、ＩＡＢドナー１０１、ＩＡＢノード１０２～１０６へ通知可能であるものとする。なお、ＲＲＣはＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌの略である。ＲＲＣは、ＩＡＢノード１０２～１０６やＵＥ１１０～１２０におけるコネクション確立、アドミッションコントロール、ＲＲＣ状態管理、周辺セル情報やアクセス規制の報知などの機能を備える。また、ＲＲＣの機能であるＲＲＭで測定可能な通信状況としては隣接セルの基準信号受信電力や基準信号受信品質等が取得できるものとする。

アンテナ制御部２０４では、無線通信部２０３において実行される無線通信に使用するアンテナを制御する。

図３は本実施形態に係るＩＡＢドナー１０１のソフトウェア機能ブロック図である。図３に示すソフトウェア機能ブロックは、記憶部２０２に格納され、制御部２０１において実行されることで実現される。ソフトウェア機能ブロックは、信号送信部３０１、信号受信部３０２、データ記憶部３０３、接続制御部３０４、動的情報更新検出部３０５、接続候補リスト収集部３０６、スライス管理部３０７、通信パス選択部３０８、動的情報管理部３０９から構成される。

信号送信部３０１及び、信号受信部３０２は、制御部２０１を介して無線通信部２０３を制御し、ＩＡＢノード１０２～１０６及び、ＵＥ１１０～１２０との間で３ＧＰＰ規格に準拠したＬＴＥ、５Ｇ等のセルラー網通信を実行する。

データ記憶部３０３は、実体である記憶部２０２の制御、管理を行い、ソフトウェアそのものおよび、ＩＡＢノード１０２～１０６のルーティング情報や、ＵＥ１１０～１２０に関する情報等を記憶保持する。また、接続制御部３０４は、無線通信時に制御部２０１を介してアンテナ制御部２０４を制御する。

動的情報更新検出部３０５は、ＩＡＢノード１０２～１０６から通知される通信パスの再確立の要求、接続パスの変更、無線リンク障害の通知、フロー制御フィードバック、ハンドオーバー完了通知を含むＲＲＣ信号を受信し、通信パス選択部３０８へ通知する。また、動的情報更新検出部３０５は、動的情報管理部３０９で管理するＩＡＢノードの動的情報を更新するパス制御部である。

接続候補リスト収集部３０６は、各ＩＡＢノード１０２～１０６における接続候補リストを収集、管理する。スライス管理部３０７は各ＩＡＢノード１０２～１０６からＢＡＰ制御メッセージを介して取得した、各ＩＡＢノードがサポートするＮＳＳＡＩリストを記憶、管理する。

通信パス選択部３０８は、動的情報更新検出部３０５の通知により、ＩＡＢノード１０５の接続候補リストと自局及び、各ＩＡＢノード１０２～１０４のスライス情報、動的情報管理部３０９を参照し、ＩＡＢノード１０５を救済可能な新たな接続先を決定する。ここで、ＩＡＢノード１０５を救済可能であるということは、ＩＡＢノード１０５に直接接続するＵＥが要求するスライス要件を達成することができるパスを設定すできることを示す。また、決定した新たな接続先をＩＡＢノード１０５へＲＲＣ制御メッセージにより通知する。ここでＲＲＣ制御メッセージとは、ＲＲＣで規定されるＰＤＵフォーマットに従うメッセージであり、ＲＲＣが備える機能を示すいずれかのフィールドを用いて実現されるものとする。ＩＡＢノード１０５へのＲＲＣ制御メッセージによる通知は、新たな接続先のみのＮＣＬ（Ｎｅｉｇｈｂｏｒ Ｃｅｌｌ Ｌｉｓｔ）で通知しても良い。

ＩＡＢノード１０５における動的情報の更新は、ＵＥ１１９からのＵＲＬＬＣのスライス要求信号を受信することで検出しても良いし、ＲＲＭにより定期的に測定されるＩＡＢノード１０２からの信号品質により自局で判定してもよい。

動的情報管理部３０９は、動的情報として、ＩＡＢドナー１０１が各ＩＡＢノード１０２～１０６におけるホップ数、空きバッファ容量、パスの合計ＵＥ数を管理している。すなわち、動的情報は、各ＩＡＢノードの通信状況に応じて変化する複数の種類の情報を含み、ＩＡＢドナー１０１によって各ＩＡＢノードの通信状況を判断するために使用される情報である。また、動的情報は、後述するように、ＩＡＢノードの処理遅延時間、ＩＡＢノードに接続しているＵＥ数、最大サブフレームサイズ、ＴＤＤパターンのアップリンク（ＵＬ）伝送の割合、所定の時間内の電波強度の最小値を含んでもよい。この場合、動的情報管理部３０９は、各ＩＡＢノードから受信した上述した情報に基づいて、通信パス上のＩＡＢドナーから所定のＩＡＢノードまでの通信パス上の処理遅延時間の合計、接続ＵＥ数の合計を所定のＩＡＢノードの動的情報としてもよい。あるいは、動的情報管理部３０９は、上述した情報に基づいて、通信パス上の各ＩＡＢノードの最大サブフレームサイズの最小値、ＵＬ伝送の割合の最小値、最小電波強度の最小値など、所定の統計量を当該所定のＩＡＢノードの動的情報としてもよい。

ここでは、ＩＡＢドナー１０１を想定したソフトウェアの説明を行った。しかしながら、動的情報更新検出部３０５、接続候補リスト収集部３０６、スライス管理部３０７及び、通信パス選択部３０８、動的情報管理部３０９を除く他の構成は、ＩＡＢノード１０２～１０６も同様の構成であるものとする。

図４は本実施形態に係る、新規パスの決定処理の一例を示すフローチャートである。図４に示すフローチャートは、ＩＡＢドナー１０１における動的情報更新検出部３０５において実行される。

Ｓ４００において、ＩＡＢドナー１０１は、ネットワークトポロジーを決定するＲＲＣの制御メッセージによる通知を受けた後、各ＩＡＢノードのホップ数、合計ＵＥ数を計算する。また、データメッセージを受信したタイミングまたは、親ノードのポーリングなどをトリガーにして各ＩＡＢノードが通知するＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）を受信することで、ＩＡＢドナー１０１は空きバッファ容量を記憶、管理する。

Ｓ４０１ではＩＡＢドナー１０１はホップ数の更新されたＩＡＢノードの有無を確認する。更新されたＩＡＢノードがある場合（Ｓ４０１でＹｅｓ）、ＩＡＢドナー１０１は処理をＳ４０５に進め、要求されたスライスがＵＲＬＬＣであるか確認する。要求されたスライスがＵＲＬＬＣの場合は、ＩＡＢドナー１０１は処理をＳ４０８に進め、動的情報の中からホップ数を参照することに決定し、パスの更新を行うＳ４１１に処理を進める。要求されたスライスがＵＲＬＬＣでない場合、ＩＡＢドナー１０１は処理をＳ４１２に進め、要求されたスライスがＵＲＬＬＣを満たせないことをＵＥに通知する。

Ｓ４０１でホップ数の更新されたＩＡＢノードがない場合（Ｓ４０１でＮｏ）、ＩＡＢドナー１０１はＳ４０２で各ＩＡＢノードからのフロー制御フィードバックによる輻輳の通知有無を確認する。Ｓ４０２で輻輳発生の通知がある場合（Ｓ４０２でＹｅｓ）、ＩＡＢドナー１０１は輻輳発生したＩＡＢノードで要求されたスライスがｅＭＢＢであるか否かを判定する。要求されたスライスがｅＭＢＢである場合（Ｓ４０６でＹｅｓ）、ＩＡＢドナー１０１は処理をＳ４０９に進め、動的情報の中から空きバッファ容量を参照することに決定し、パスの更新を決定する（Ｓ４１１）。要求されたスライスがｅＭＢＢでない場合（Ｓ４０６でＮｏ）、ＩＡＢドナー１０１は処理をＳ４１２に進め、要求されたスライスがｅＭＢＢを満たせないことをＵＥに通知する。

輻輳通知のＩＡＢノードを検出しなかった場合（Ｓ４０２でＮｏ）、ＩＡＢドナー１０１は処理をＳ４０３に進め、ＩＡＢノードごとに接続しているＵＥ数が最大値（基地局あたり２５６ＵＥ）のＩＡＢノードの検出を行う。Ｓ４０３でＵＥ数が最大値のＩＡＢノードがある場合、要求されたスライスがＭＩｏｔであるか確認する（Ｓ４０７）。要求されたスライスがＭＩｏｔの場合（Ｓ４０７でＹｅｓ）は、ＩＡＢドナー１０１は処理をＳ４１０に進め、動的情報の中から合計ＵＥ数を参照することに決定し、パスの更新を行う（Ｓ４１１）。要求されたスライスがＭＩｏｔでない場合（Ｓ４０７でＮｏ）、ＩＡＢドナー１０１は処理をＳ４１２に進め、要求されたスライスがＭＩｏｔを満たせないことをＵＥに通知する。なお、ネットワークスライスの種別としては、高速大容量（ｅＭＢＢ）、低遅延（ＵＲＬＬＣ）、同時多重接続（ＭＩｏｔ）以外に規定されているＣ－Ｖ２Ｘ（Cellular-Vehicle to Everything）や、その他のスライス種別が設定されてもよい。

図５は実施形態１におけるＵＲＬＬＣのスライス要求時の新規接続先パスの決定方法を示したフローチャートである。図５に示すフローチャートは、ＩＡＢドナー１０１における通信パス選択部３０８において実行される。

Ｓ５００では、ネットワークトポロジーの更新や混雑度からＩＡＢノード１０５でのＵＲＬＬＣの動的情報となるホップ数が更新したことを動的情報更新検出部３０５が検出し、通信パス選択部３０８はこれを受信する。

Ｓ５０１では、接続候補リスト収集部３０６によりＩＡＢノード１０５から接続可能な接続候補ＩＡＢノードのリスト（接続候補リスト）をＲＲＣ制御メッセージにより収集する。Ｓ５０２では、処理開始時にＩＡＢノード１０５の親ノードである（親ノードであった）ＩＡＢノード１０４を暫定接続先のＩＡＢノードとして設定する。親ノードとは、通信パス上で所定のノードに対して上流に位置するノードである。

Ｓ５０３～Ｓ５０８及びＳ５１１～Ｓ５１３間の処理は、動的情報の更新が検出されたＩＡＢノード１０５の接続候補リストにおけるすべてのＩＡＢノード１０２～１０３、および１０６について繰り返される。

Ｓ５０４では、スライス管理部３０７で管理される接続候補のＩＡＢノードｎのＮＳＳＡＩリストを参照し、接続候補ＩＡＢノードｎがＵＲＬＬＣスライス要件を満たすかどうかを判断する。要件を満たす場合（Ｓ５０４でＹｅｓ）にはＳ５０５の動的情報からホップ数に関する情報を選択する。要件を満たさない場合（Ｓ５０４でＮｏ）には処理をＳ５１３に進め、当該ＩＡＢノードについては現状維持となり、次の接続候補ＩＡＢノードｎについて繰り返し実行する。ここで、現状維持とは、接続候補ＩＡＢノードｎには通信パスの変更を行わない、すなわち暫定接続先ＩＡＢノードを変更しないことを意味する。

Ｓ５０６では暫定接続先のＩＡＢノードと接続候補ＩＡＢノードとで、ＩＡＢドナー１０１までのホップ数の比較を行う。暫定接続先ＩＡＢノードのホップ数が接続候補ＩＡＢノードのホップ数と比較して多い場合（Ｓ５０６でＹｅｓ）、ＩＡＢドナー１０１は処理をＳ５０７に進め、ホップ数の少ない接続候補ＩＡＢノードを暫定接続先ＩＡＢノードに決定する。Ｓ５０６で暫定接続先ノードのホップ数が接続候補ノードのホップ数以下の場合（Ｓ５０６でＮｏ）、ＩＡＢドナー１０１は処理をＳ５１１に進め、暫定接続先ノードのホップ数と接続候補ノードのホップ数が等しいか否かを判定する。暫定接続先ノードのホップ数と接続候補ノードのホップ数とが等しい場合（Ｓ５１１でＹｅｓ）、ＩＡＢドナー１０１は動的情報から遅延時間Ｔを比較する。ここでＴの値は、暫定候補と接続候補のノードが持つホップ数が同じ値である場合に、どちらがより通信遅延を低減できるかに基づいてパスを決定するために使用される通信パスのパラメータである。Ｔの値としては以下の値を参照して決定してもよい。

（１）ノード処理遅延時間 （パス上の全ＩＡＢノードの合計）
（２）合計ＵＥ数 （パス上の全ＩＡＢノードの合計）
（３）サブフレームサイズ（パス上の各ＩＡＢノードでの最大値）
（４）ＴＤＤパターンのＵＬ割合 （パス上の各ＩＡＢノードで最小値）
（５）電波強度 （パス上の各ＩＡＢノードの最小値）
Ｓ５１１で暫定接続先ノードのホップ数が接続候補ＩＡＢノードのホップ数と比較して少ない場合はＩＡＢドナー１０１は処理をＳ５１３に進め、当該ＩＡＢノードについては現状維持となる。Ｓ５１４でＩＡＢドナー１０１は次のＩＡＢノードを参照する。

全ての接続候補ＩＡＢノードｎについて繰り返した後、Ｓ５０９で暫定接続先ＩＡＢノードを接続先のＩＡＢノードに決定し、接続先ＩＡＢノードに接続するように示すＲＲＣ制御メッセージをＩＡＢノード１０５へ送信する。

ＩＡＢドナー１０１から最小ホップ数の接続先ＩＡＢノード１０３の通知を受信したＩＡＢノード１０５は新たな接続先のＩＡＢノード１０３へ接続する。これによて、最小ホップ数のパスを使用した通信を行うことができる。

図６に実施形態１のＩＡＢノード１０５における接続候補リストの一例を示す。接続候補リスト６０１は、ＩＡＢノード１０５のＲＲＭの測定結果にもとづいて各ＩＡＢノード１０２～１０３、１０６が隣接セル情報としてＲＲＣ制御メッセージを介して送信され、ＩＡＢドナー１０１の接続候補リスト収集部３０６で収集、管理されてもよい。

その他の方法としてＩＡＢドナー１０１が、各ＩＡＢノード１０２～１０５におけるＲＲＭの測定結果をＲＲＣ制御メッセージにより収集し、例えば電波強度の高い順にリスト化することで生成しても良い。また、ＩＡＢドナー１０１が各ＩＡＢノード１０２～１０６の接続候補リストとしてＮＣＬを収集して使用してもよい。

接続候補リスト６０１において、ＩＡＢノード１０５の接続先としてはＩＡＢノード１０４が最大の電波強度のＩＡＢノードであったが、電波障害により接続断となった場合、ＩＡＢノード１０４の次に電波強度が高いＩＡＢノードはＩＡＢノード１０３である。なお、図６に示す接続候補リストにおいて、電波強度は不可、可、良などのクラス分けがされているものとして示しているが、電波強度を示す数値であってもよい。

次に図７を参照して各ＩＡＢノード１０２～１０６のＮＳＳＡＩリストの一例を示し、ＩＡＢドナー１０１がＳ４０５～Ｓ４０７での処理においてＩＡＢノード１０３がスライス要件を満たすか否かを判定する処理について説明する。

図７に実施形態１におけるＩＡＢドナー１０１及び、各ＩＡＢノード１０２～１０６のＮＳＳＡＩリストの一例を示す。

ＮＳＳＡＩリスト７０１～７０５は、スライス管理部３０７において管理されるＩＡＢノード１０２～１０６のスライス対応情報の一例である。ここで、７０４は、Ｓ４０１において、ホップ数の更新が検出されたＩＡＢノード１０５におけるリストである。

ＮＳＳＡＩに記載される値は、サポート可能なスライス種別であるＳＳＴ（Ｓｌｉｃｅ Ｓｅｒｖｉｃｅ Ｔｙｐｅ）を示しており、ｅＭＢＢは"１"、ＵＲＬＬＣは"２"、ＭＩｏｔは"３"に関連付けられる。ＮＳＳＡＩリスト７００～７０５において、ＩＡＢドナー１０１はｅＭＢＢ、ＵＲＬＬＣ、ＭＩｏｔの全てのスライス種別をサポートする。また、ＩＡＢノード１０２～１０４はｅＭＢＢ、ＵＲＬＬＣのＳＳＴをサポートし、ＩＡＢノード１０５は通信リンク障害の影響を受け、ｅＭＢＢが提供不可となり、ＵＲＬＬＣのＳＳＴのみをサポートする。ＩＡＢノード１０６はＵＲＬＬＣ、ＭＩｏｔのＳＳＴをサポートする。

なお、図５の例では、接続候補ＩＡＢノードのうち、ＩＡＢドナー１０１からのホップ数が最も小さいＩＡＢノードに接続するものとして説明を行った。しかしながら、ホップ数が所定の閾値（第一の閾値）以下であるＩＡＢノードについて、上述した遅延時間Ｔで比較を行ってもよい。これによって、ホップ数以外の要素が通信遅延に与える影響が大きい場合にもより通信遅延が小さい通信パスを選択することができる。

図８は本実施形態に係るＩＡＢドナー１０１が管理する各ＩＡＢノード１０２～１０６の動的情報リストの一例を示す。図８に示す動的情報リストは、ＩＡＢドナー１０１において、各ＩＡＢノード１０２～１０６からのパス切り替え、ＢＳＲなどの通知を受信した場合に更新され、動的情報管理部３０９で管理する。

図１においてＩＡＢノード１０４とＩＡＢノード１０５との間の通信リンク障害の影響を受け、ＩＡＢノード１０４からＩＡＢノード１０３を介してＩＡＢノード１０５に接続することで新規パスを形成する。このネットワークトポロジー更新により図８のＩＡＢノード１０５の動的情報となるホップ数は３から４に更新され、この更新が図４のＳ４０１で検出される。

ここで、接続先候補ノードであるＩＡＢノード１０３は、Ｓ５０９においてＵＲＬＬＣのスライス要求をサポートできる最小ホップ数のＩＡＢノードとなるため、ＩＡＢノード１０５との新たな通信パスを形成する接続先に選出される。ＩＡＢノード１０５において、通信リンク障害によるパス切り替えのためにＮＳＳＡＩ上はＵＲＬＬＣをサポートできるように見えるが、ホップ数の増加による遅延時間の増大によってＵＲＬＬＣの機能を実行できない場合がある。このような場合、本実施形態にかかるＩＡＢドナー１０１は救済すべき、すなわち要求されたサポートを満たせないＩＡＢノード１０５への新たな通信パスの接続確立を行う。

ここで、ＩＡＢドナー１０１は、図８に示すＩＡＢノード１０３のホップ数情報から、ＩＡＢノード１０３のホップ数が１であることを検出する。すると、現在のＩＡＢドナー１０１からＩＡＢノード１０３を介してＩＡＢノード１０５に接続する経路が最もホップ数が小さいため、ＩＡＢドナー１０１は、この通信パスを使用するようＩＡＢノード１０３および１０５を制御して通信パスを設定する。これによって、ＩＡＢノード１０５に接続するＵＥに要求されたスライス種別の要件を満たす通信パスを設定することができる。

図９は本実施形態に係る接続確立を示すシーケンス図である。ＩＡＢノード１０５への新たな通信パスでの接続確立を行う動作を説明する。

Ｓ９００では、ＩＡＢドナー１０１から配下の各ＩＡＢノード１０２～１０６にＩＰアドレスの付与などによりパス接続を確立し初期ネットワークトポロジーを形成する。Ｓ９０１からＳ９０２でＵＥ１１９がＩＡＢノード１０５にＵｕアクセス接続した後、Ｓ９０３でＵＥ１１９がＵＲＬＬＣのスライスを要求した場合に、Ｓ９０４でＩＡＢドナー１０１がＵＥ１１９にスライスを付与する。

Ｓ９０５では無線リンク障害によりＩＡＢノード１０４とＩＡＢノード１０５との間の接続断によって、Ｓ９０６においてＩＡＢノード１０５がＩＡＢノード１０３を経由して通信を行う新規パスに切り替わる。Ｓ９０７でＩＡＢノード１０３～ＩＡＢノード１０５がＲＲＣメッセージを使用してＩＡＢドナー１０１に通信パスの切り替えを通知する。

Ｓ９０８で各ＩＡＢノードからの通知を受信したＩＡＢドナー１０１は、動的情報更新検出部Ｓ３０６で動的情報が更新されたか否かを判定する。本実施形態では各ＩＡＢノードからパス切り替えをＲＲＣメッセージを使用して通知している。一例では、ＢＡＰによるフロー制御フィードバックでの輻輳通知や、ＵＥ数の通知（ＲＲＣによるハンドオーバー通知や、ＢＡＰ通知を使用した自局にアクセスするＵＥ数の通知）を含む別のメッセージによって通信パスの切り替えを通知してもよい。

Ｓ９０９ではＩＡＢドナー１０１は各ＩＡＢノードから受信したＲＲＣ、ＢＡＰメッセージ通知を参照して動的情報の更新を検出し、どのスライスに対応する動的情報であるかを判別する。実施形態１においてはＳ４０１でＩＡＢノード１０５のホップ数が３から４に更新されたため、Ｓ４０５でスライス種別がＵＲＬＬＣであることを判別し、Ｓ４０８において動的情報のホップ数を参照して、Ｓ４１１からＩＡＢノード１０５のパス更新を決定する。

Ｓ９１０では、ＩＡＢドナー１０１がパス更新を決定したＩＡＢノード１０５に対して接続候補リストをＲＲＣメッセージにより要求する。Ｓ９１１でＩＡＢノード１０５は、ＲＲＭ測定結果により生成した接続候補リストをＲＲＣメッセージによりＩＡＢドナー１０１へ送信する。

Ｓ９１２では、図５に示すフローチャートに従い、ＩＡＢノード１０５の接続先候補リスト（Ｓ５０３）を取得する。続いて、スライス管理部３０７において管理されるＮＳＳＡＩリストと、動的情報管理部３０９で管理される動的情報よりホップ数を示す情報を選択し（Ｓ５０５）、ホップ数が最小となるＩＡＢノード１０３を接続先ノードに選出する（Ｓ５０９）。Ｓ９１３では、ＩＡＢドナー１０１は、ＩＡＢノード１０５へＩＡＢノード１０３との通信パスの変更をＲＲＣ制御メッセージにより通知する。

Ｓ９１４ではＩＡＢノード１０５は、ＩＡＢノード１０３を経由したＩＡＢドナー１０１との新規パスを確立する。ＩＡＢドナー１０１はＩＡＢノード１０５との新規Ｆ１―Ｃ接続を指示する。ここでは、各々の制御メッセージはＢＡＰ及び、ＲＲＣでやり取りされるものとして説明を行ったがこの限りではなく例えばアプリケーションレイヤのメッセージでのやり取りにより通信パスを指示してもよい。Ｓ９１５でＩＡＢノード１０５はパス更新が完了したことをＩＡＢドナー１０１に通知する。

これによって、通信障害が発生して通信パスの切り替えが必要になったＩＡＢノード１０５に、当該ノードに接続するＵＥが要求するスライス要件を満たす通信パスに切り替えることができる。

図１０は実施形態１における新規パス接続後のトポロジを示す図である。無線通信システム１００において、図９のシーケンスが実行された後にＩＡＢノード１０５は、ＩＡＢノード１０３とパス１０００の接続を確立することでＵＥ１１９へＵＲＬＬＣのスライスを供給可能となる。

以上のように、無線リンク障害によるパス切り替えでＩＡＢノード１０２～１０５において要件未達となった特定のスライスに対して、新たな接続先との通信パスを形成することで、要件未達のスライスをサポートすることが可能となる。

＜実施形態２＞
実施形態１では、無線通信システム１００において、ＵＥからＵＲＬＬＣが要求されるＩＡＢノード１０５とその親ノードであるＩＡＢノード１０４間でリンク障害が発生し、通信パスの切り替えによってホップ数が変動する場合について説明した。実施形態２では、ＩＡＢノード１０５の親ノードとなるＩＡＢノード１０４でバッファ溢れによる輻輳が発生した場合についてＵＥ１１８の要求するスライスｅＭＢＢをサポート可能な新たな接続先を決定する方法について説明を行う。

なお、実施形態１と同様の構成、機能、および処理については同一の参照符号を使用し、詳細な説明を省略する。

図１１は、本実施形態に係るｅＭＢＢスライス要求時の新規通信パス決定のフローチャートである。実施形態１で説明した図４以外の図２から図９に示す構成、機能、処理については同様である。また、実施形態２ではＩＡＢノード１０４とＩＡＢノード１０５との間で無線リンク障害は発生していないものとする。また、各ＩＡＢノードの動的情報は図８の８０２に示すものであるものとする。

Ｓ１１００ではＩＡＢドナー１０１が輻輳状態のＩＡＢノード１０４からフロー制御フィードバック通知を受信した後、通信パス上でＩＡＢノード１０４の下流に位置するＩＡＢノード１０５の接続候補リストを収集する。

Ｓ１１０１では輻輳状態のＩＡＢノード１０４を暫定接続先ＩＡＢノードとして設定する。Ｓ１１０２からＳ１１０７は接続候補のＩＡＢノード数ｎだけ（Ｓ１１０８）を繰り返し実施される。Ｓ１１０３ではＵＥの要求するスライスがｅＭＢＢであるか否かを判定し、要求するスライスがｅＭＢＢである場合（Ｓ１１０３でＹｅｓ）は処理をＳ１１０４に進め、Ｓ８０１の動的情報から空きバッファ容量を示す情報（バッファ情報）を選択する。

Ｓ１１０５では、接続候補ＩＡＢノードの空きバッファ容量が暫定接続先ＩＡＢノードの空きバッファ容量と比較して多い場合、Ｓ１１０６に進んで空きバッファ容量の多い接続候補ＩＡＢノードを暫定接続先ＩＡＢノードに決定する。接続候補ＩＡＢノードの空きバッファ容量が暫定接続先ＩＡＢノードの空きバッファ容量以下の場合、Ｓ１１０７に進んで他の接続候補ＩＡＢノードについて空きバッファ容量の判定を実行する。

Ｓ１１０８で全ての接続候補ＩＡＢノードｎについて繰り返した後、Ｓ１１０９で暫定接続先ＩＡＢノードを接続先のＩＡＢノードに決定する。そして、接続候補ＩＡＢノードの中から空きバッファ容量が最大のＩＡＢノードに接続するようＲＲＣメッセージでＩＡＢノード１０５へ指示する。本実施形態では図８のＳ８０１に示す動的情報において、空きバッファ容量が一番大きいＩＡＢノード１０６が空きバッファ容量が最大のＩＡＢノードとして選択される。

ＩＡＢドナー１０１から最大空きバッファ容量を有する接続先のＩＡＢノード１０６の通知を受信したＩＡＢノード１０５は、新たな接続先のＩＡＢノード１０６へ接続し、最大空きバッファ容量の通信パスの提供を受けることができる。

なお、ＩＡＢノード１０５はＩＡＢノード１０４との通信パスを維持した状態で、ＩＡＢノード１０６と新規の通信パスを確立してマルチパス接続を形成してもよい。

図１２は本実施形態に係る新規通信パス接続後のトポロジを示す。無線通信システム１００において、図９に示すフローチャートによりＩＡＢノード１０４に対してＩＡＢドナー１０１とマルチパス１２００の接続を確立することでＵＥ１１９へｅＭＢＢのスライスをサポートする通信パスを供給可能となる。

なお、本実施形態では、空きバッファ容量が最大のＩＡＢノードに接続するものとして説明を行った。しかしながら、空きバッファ容量が所定の閾値（第２の閾値）以上であるＩＡＢノードであれば接続可能であるものとしてもよい。この場合、空きバッファ容量が所定の閾値以上であるＩＡＢノードが複数存在する場合には、ＩＡＢノード１０５が当該複数のＩＡＢノードのいずれに接続するかをＵＬ伝送の割合などの他の動的情報に基づいて決定してもよい。

＜実施形態３＞
実施形態３では、ＩＡＢノード１０５で接続するＵＥ数が所定の閾値を上回った場合に、ＵＥ１１８の要求するスライスＭＩｏＴをサポート可能な新たな接続先を決定する処理について説明を行う。

図１３に、本実施形態に係るＭＩｏｔスライス要求時の新規通信パス決定のフローチャートを示す。ここで前提条件として、実施形態１で説明した図４以外の図２から図９までは同じ図で示すことができ、ＩＡＢノード１０４とＩＡＢノード１０５間で無線リンク障害は未発生とする。各ＩＡＢノードの動的情報は図８の８０３に示すものであるとする。なお、本実施形態では、ＭＩｏＴをサポートする通信パスごとに、合計２５６台のＵＥに通信を提供可能であるものとする。

Ｓ１３００ではＩＡＢドナー１０１が接続しているＵＥ数が閾値を超過したことを通知するＩＡＢノード１０５からのＲＲＣ信号、またはＢＡＰ通知を受信した後、ＩＡＢノード１０５の接続候補リストを収集する。Ｓ１３０１では接続しているＵＥ数のＩＡＢノード１０５の親ノードとなるＩＡＢノード１０４を暫定接続先ＩＡＢノードとして設定する。

Ｓ１３０２からＳ１３０７の処理は接続候補ノードｎ分（Ｓ１３０９）、繰り返し実行される。Ｓ１３０３では接続候補ＩＡＢノードの要求するスライスがＭＩｏｔであるか否かを判定し、ＭＩｏｔであればＳ１３０４に進み、Ｓ８０１の動的情報から合計ＵＥ数を示す情報（ユーザ数情報）を選択する。

Ｓ１３０５では、接続候補ＩＡＢノードの合計ＵＥ数が暫定接続先ＩＡＢノードの合計ＵＥ数と比較して少ない場合、Ｓ１３０６に進んで合計ＵＥ数が少ない接続候補ＩＡＢノードを暫定接続先ＩＡＢノードに決定する。接続候補ＩＡＢノードの合計ＵＥ数が暫定接続先ＩＡＢノードの合計ＵＥ数以上の場合、Ｓ１３０７に進んで別の接続候補ＩＡＢノードの判定を実行する。

Ｓ１３０９で全ての接続候補ＩＡＢノードｎについて繰り返した後、Ｓ１３０８で暫定接続先ＩＡＢノードを接続先のＩＡＢノードに決定し、合計ＵＥ数が最小のＩＡＢノードを選択することをＲＲＣ制御メッセージによりＩＡＢノード１０５へ通知する。Ｓ８０１の合計ＵＥ数よりＩＡＢノード１０６が最小となる。

ＩＡＢドナー１０１から最小合計ＵＥ数の接続先ＩＡＢノード１０６の通知を受信したＩＡＢノード１０５は新たな接続先のＩＡＢノード１０６へ接続し、最小合計ＵＥ数のパス提供を受ける。

図１４は実施形態３における新規通信パス接続後のトポロジである。ＩＡＢノード１０４および通信パス上でその上流に位置するＩＡＢノードですでに１０６台のＵＥが接続している場合、通信パス上でＩＡＢノード１０４の下流に位置するＩＡＢノード１０５は、追加で１５０台のＵＥしか接続することができない。この場合、無線通信システム１００において、図９のフローチャートによりＩＡＢノード１０４に対してＩＡＢドナー１０１とマルチパス１４００の接続を確立することができる。これによって、ＩＡＢノード１０５に接続するＵＥ１５５２をＩＡＢノード１０６を介したＭＩｏｔのスライスをサポートする通信パスに割り当てることでＵＥ１５５２にＭＩｏＴをサポートする通信を提供可能となる。

なお、一例では、ＩＡＢドナー１０１は、所定のＩＡＢノードに対して接続可能なＵＥ数に基づいて通信パスの切り替えを行ってもよい。例えば、図１４の例で、ＩＡＢノード１０４より上流で１００台のＵＥが接続しており、ＩＡＢノード１０６の上流では２台のＵＥが接続している。このような場合、ＩＡＢドナー１０１は、接続しているＵＥ数が閾値を超えたＩＡＢノード１０５について、接続候補のＩＡＢノードのうち、接続候補のＩＡＢノードおよびその上流のＩＡＢノードに接続しているＵＥ数の合計に基づいて接続先を判定してもよい。これによって、通信パス全体で接続可能なＵＥ数が決まっている場合に、下流に位置するＩＡＢノードの接続先を切り替えることで、新たに接続するＵＥにＭＩｏＴのスライス種別をサポートする通信を提供することができる。

なお、本実施形態では、接続している合計ＵＥ数が最小、または接続可能なＵＥ数が最大のＩＡＢノードに接続するものとして説明を行った。しかしながら、合計ＵＥ数が所定の閾値（第３の閾値）以下、または接続可能なＵＥ数が所定の閾値以上であるＩＡＢノードであれば接続可能であるものとしてもよい。この場合、合計ＵＥ数が所定の閾値以下であるＩＡＢノードが複数存在する場合には、ＩＡＢノード１０５が当該複数のＩＡＢノードのいずれに接続するかを他の動的情報に基づいて決定してもよい。

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

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

実施形態１から実施形態３ではパス切り替えについて説明を行った。しかし、通信品質の低下ではなくＢＡＰ制御メッセージとしてＲＬＦ（Ｒｅｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ）が通知される場合には新たに決定した接続先と元の通信パスを継続することでマルチパス接続としてもよい。

また、実施形態１から実施形態３ではＩＡＢノード１０２～１０６において単一のスライスを救済したが、要件が満たせないスライスが所定の期間内に複数発生した場合には要求するＵＥ数が最も多いスライスを優先して救済するように動作してもよい。さらに要求するＵＥ数が最も多いスライスを救済できない場合には、次に要求するＵＥ数の多いスライスを救済するように新たな通信パスを選択してもよい。

本実施形態では、ＵＲＬＬＣではＩＡＢドナーまでのホップ数に基づいて前提接続先ノードを設定し、ホップ数が同じ場合には遅延時間で比較するものとして説明を行った。一例では、ＩＡＢドナーは、スライス種別ごとに、選択する動的情報の種類と、その優先度とを対応付けて記憶部２０２に記憶してもよい。この場合、Ｓ５０５の処理では、このようなスライス種別に基づいて所定の種類の動的情報を選択し、優先度の順に比較を行ってもよい。

また、本実施形態では、図３の接続制御部３０４～動的情報管理部３０９はＩＡＢドナー１０１が備えるものとして説明をおこなった。しかしながら一例ではコアネットワーク側のネットワークノードに設けられてもよいし、無線通信ネットワーク１００内の

１００ 無線通信システム、１０１ ＩＡＢドナー、１０２～１０６ ＩＡＢノード、１１０～１２０ ＵＥ、２０１ 制御部、２０２ 記憶部、２０３ 無線通信部、２０４ アンテナ制御部、３０１ 信号送信部、３０２ 信号受信部、３０３ データ記憶部、３０４ 接続制御部、３０５ 動的情報更新検出部、３０６ 接続候補リスト収集部、３０７ スライス管理部、３０８ 通信パス選択部、３０９ 動的情報管理部

Claims (15)

1. ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ネットワークの制御装置であって、
   前記ＩＡＢネットワークのＩＡＢドナーと所定のＩＡＢノードとの間の接続を中継するためのＩＡＢノードであって、前記所定のＩＡＢノードと接続可能なＩＡＢノードの通信状況を示す複数の種類の動的情報を取得する取得手段と、
   前記取得手段で取得した前記複数の種類の動的情報の中から、前記所定のＩＡＢノードがサポートすべきスライス種別に基づいて少なくとも１つの種類の動的情報を選択する選択手段と、
   前記選択手段で選択した前記少なくとも１つの種類の動的情報に応じて前記所定のＩＡＢノードと前記ＩＡＢドナーとの間の通信パスを制御するパス制御手段と、
   前記所定のＩＡＢノードから通信パスの再確立の要求、無線リンク障害の通知、およびフロー制御フィードバックを含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）信号を受信する第１受信手段と、
   を備え、
   前記第１受信手段が、所定の期間内に複数のＩＡＢノードから前記ＲＲＣ信号を受信した場合に、前記パス制御手段は、接続するユーザ装置の数が多いＩＡＢノードの通信パスを優先して制御することを特徴とする制御装置。
2. 前記複数の種類の動的情報は、前記ＩＡＢドナーから前記接続可能なＩＡＢノードまでのホップ数を示すホップ数情報を含み、
   前記スライス種別がＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）である場合、
   前記選択手段は、前記少なくとも１つの種類の動的情報として前記ホップ数情報を選択し、
   前記パス制御手段は、前記接続可能なＩＡＢノードのうち、前記ＩＡＢドナーからのホップ数が最も小さいＩＡＢノードに接続するよう前記通信パスを切り替えることを特徴とする請求項１に記載の制御装置。
3. 前記複数の種類の動的情報は、前記ＩＡＢドナーから前記接続可能なＩＡＢノードまでのホップ数を示すホップ数情報を含み、
   前記スライス種別がＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）である場合、
   前記選択手段は、前記少なくとも１つの種類の動的情報として前記ホップ数情報を選択し、
   前記パス制御手段は、前記ホップ数情報によって示される前記ホップ数が第１の閾値以下である前記接続可能なＩＡＢノードに前記所定のＩＡＢノードが接続するよう前記通信パスを設定することを特徴とする請求項１に記載の制御装置。
4. 前記複数の種類の動的情報は、前記接続可能なＩＡＢノードの空きバッファ容量を示すバッファ情報を含み、
   前記スライス種別がｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ ＢｒｏａｄＢａｎｄ）である場合、
   前記選択手段は、前記少なくとも１つの種類の動的情報として前記バッファ情報を選択し、
   前記パス制御手段は、前記接続可能なＩＡＢノードのうち、空きバッファ容量が最も大きいＩＡＢノードに前記所定のＩＡＢノードが接続するよう前記通信パスを切り替えることを特徴とする請求項１から３の何れか１項に記載の制御装置。
5. 前記複数の種類の動的情報は、前記接続可能なＩＡＢノードの空きバッファ容量を示すバッファ情報を含み、
   前記スライス種別がｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ ＢｒｏａｄＢａｎｄ）である場合、
   前記選択手段は、前記少なくとも１つの種類の動的情報として前記バッファ情報を選択し、
   前記パス制御手段は、前記バッファ情報によって示される前記空きバッファ容量が第２の閾値以上である前記接続可能なＩＡＢノードに前記所定のＩＡＢノードが接続するよう通信パスを設定することを特徴とする請求項１から３のいずれか１項に記載の制御装置。
6. 前記複数の種類の動的情報は、前記接続可能なＩＡＢノードに接続するユーザ装置の数を示すユーザ数情報を含み、
   前記スライス種別がＭＩｏＴ（Ｍａｓｓｉｖｅ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）である場合、
   前記選択手段は、前記少なくとも１つの種類の動的情報として前記ユーザ数情報を選択し、
   前記パス制御手段は、前記接続可能なＩＡＢノードのうち、接続するＵＥ数が最も小さいＩＡＢノードに接続するよう前記通信パスを切り替えることを特徴とする請求項１から５の何れか１項に記載の制御装置。
7. 前記複数の種類の動的情報は、前記接続可能なＩＡＢノードに接続するユーザ装置の数を示すユーザ数情報を含み、
   前記スライス種別がＭＩｏＴ（Ｍａｓｓｉｖｅ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）である場合、
   前記選択手段は、前記少なくとも１つの種類の動的情報として前記ユーザ数情報を選択し、
   前記パス制御手段は、前記ユーザ数情報によって示される前記ユーザ装置の数が第３の閾値以下である前記接続可能なＩＡＢノードに前記所定のＩＡＢノードが接続するよう通信パスを設定することを特徴とする請求項１から５のいずれか１項に記載の制御装置。
8. 前記接続可能なＩＡＢノードは、前記スライス種別をサポートするＩＡＢノードであることを特徴とする請求項１から７のいずれか１項に記載の制御装置。
9. 前記所定のＩＡＢノードに接続するユーザ装置からスライス種別をサポートする通信パスを要求するスライス要求信号を受信する第２受信手段をさらに有し、
   前記第２受信手段で前記スライス要求信号を受信した場合に、前記パス制御手段は前記所定のＩＡＢノードが接続するＩＡＢノードを指示することを特徴とする請求項１から８のいずれか１項に記載の制御装置。
10. 前記第２受信手段で前記スライス要求信号を受信した場合であって、前記パス制御手段が前記スライス要求信号で要求された前記スライス種別をサポートする通信パスがないと判断した場合に、前記スライス要求信号を送信した前記ユーザ装置に前記スライス種別をサポートできないことを通知する通知手段をさらに有することを特徴とする請求項９に記載の制御装置。
11. 前記第１受信手段で前記ＲＲＣ信号を受信した場合に、前記取得手段が前記動的情報を取得し、前記パス制御手段が前記所定のＩＡＢノードがサポート可能なスライス種別をサポートするように前記ＩＡＢドナーと前記所定のＩＡＢノードの間の通信パスを制御することを特徴とする請求項１から１０のいずれか１項に記載の制御装置。
12. 前記選択手段は、前記所定のＩＡＢノードがサポートすべき前記スライス種別に基づいて前記複数の種類の動的情報の中から複数の種類の動的情報を選択し、
    前記パス制御手段は、前記選択手段で選択した前記複数の種類の動的情報に基づいて前記通信パスを制御することを特徴とする請求項１から１１の何れか１項に記載の制御装置。
13. 前記スライス種別と、前記複数の種類の動的情報の種類ごとに、通信パスの判断における優先度とが対応付けられた情報を記憶する記憶手段をさらに有し、
    前記パス制御手段は、前記選択手段で選択した複数の種類の動的情報から、選択した前記複数の種類の動的情報のうち、前記優先度の高い順に動的情報を選択して前記通信パスを制御することを特徴とする請求項１２に記載の制御装置。
14. ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ネットワークの制御装置が実行する制御方法であって、
    前記ＩＡＢネットワークのＩＡＢドナーと所定のＩＡＢノードとの間の接続を中継するためのＩＡＢノードであって、前記所定のＩＡＢノードと接続可能なＩＡＢノードの通信状況を示す複数の種類の動的情報を取得することと、
    取得した前記複数の種類の動的情報の中から、前記所定のＩＡＢノードがサポートすべきスライス種別に基づいて少なくとも１つの種類の動的情報を選択することと、
    選択した前記少なくとも１つの種類の動的情報に応じて前記所定のＩＡＢノードと前記ＩＡＢドナーとの間の通信パスを制御することと、
    前記所定のＩＡＢノードから通信パスの再確立の要求、無線リンク障害の通知、およびフロー制御フィードバックを含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）信号を受信することと、
    を含み、
    所定の期間内に複数のＩＡＢノードから前記ＲＲＣ信号を受信した場合に、接続するユーザ装置の数が多いＩＡＢノードの通信パスを優先して制御することを特徴とする制御方法。
15. ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ネットワークの制御装置のコンピュータに、
    前記ＩＡＢネットワークのＩＡＢドナーと所定のＩＡＢノードとの間の接続を中継するためのＩＡＢノードであって、前記所定のＩＡＢノードと接続可能なＩＡＢノードの通信状況を示す複数の種類の動的情報を取得する取得工程と、
    前記取得工程において取得した前記複数の種類の動的情報の中から、前記所定のＩＡＢノードがサポートすべきスライス種別に基づいて少なくとも１つの種類の動的情報を選択する選択工程と、
    前記取得工程において選択した前記少なくとも１つの種類の動的情報に応じて前記所定のＩＡＢノードと前記ＩＡＢドナーとの間の通信パスを制御するパス制御工程と、
    前記所定のＩＡＢノードから通信パスの再確立の要求、無線リンク障害の通知、およびフロー制御フィードバックを含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）信号を受信する受信工程と、
    を実行させ、
    前記受信工程において、所定の期間内に複数のＩＡＢノードから前記ＲＲＣ信号を受信した場合に、前記パス制御工程において、接続するユーザ装置の数が多いＩＡＢノードの通信パスを優先して制御することを特徴とするプログラム。