2024-162066 制御装置、通信装置、制御方法、プログラム

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

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

(11)【公開番号】P2024162066

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

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

(51)【国際特許分類】

   H04W 36/32 20090101AFI20241114BHJP

   H04W 48/16 20090101ALI20241114BHJP

   H04W 16/26 20090101ALI20241114BHJP

【ＦＩ】

H04W36/32

H04W48/16 134

H04W16/26

【審査請求】未請求

【請求項の数】22

【出願形態】ＯＬ

(21)【出願番号】P 2023077247

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

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

(71)【出願人】

【識別番号】000001007

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

(74)【代理人】

【識別番号】110002871

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

(72)【発明者】

【氏名】土橋 正和

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

5K067

【Ｆターム（参考）】

5K067AA21

5K067DD20

5K067EE02

5K067EE06

5K067EE10

5K067FF03

5K067JJ39

(57)【要約】

【課題】ユーザや通信事業者にとって利便性の高い態様でモバイルＩＡＢノードにおけるアクセス制限に係る切り替えを実現可能とする仕組みを提供する。
【解決手段】アクセス制限が設定されているモバイルＩＡＢノードに対して、前記アクセス制限を解除することを求める要求を送信する送信手段を備える、制御装置が開示される。好ましくは、送信手段は、所定条件を満たす場合に、要求を送信する。また、好ましくは、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）から接続可能な基地局がない旨を含む通知を受信する第１の受信手段を更に備え、所定条件は、通知を受信した場合に満たされる。
【選択図】図４

【特許請求の範囲】

【請求項1】

アクセス制限が設定されているモバイルＩＡＢノードに対して、前記アクセス制限を解除することを求める要求を送信する送信手段を備える、制御装置。

【請求項2】

前記送信手段は、所定条件を満たす場合に、前記要求を送信する、請求項１に記載の制御装置。

【請求項3】

ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）から接続可能な基地局がない旨を含む通知を受信する第１の受信手段を更に備え、
前記所定条件は、前記通知を受信した場合に満たされる、請求項２に記載の制御装置。

【請求項4】

前記受信手段は、ＲＲＣメッセージにより前記通知を受信する、請求項３に記載の制御装置。

【請求項5】

前記通知は、前記ＵＥの位置情報を含み、
前記送信手段は、前記位置情報に基づいて、前記アクセス制限の解除が適用される位置範囲に関する範囲情報を生成し、前記範囲情報を前記要求に含める、請求項３又は４に記載の制御装置。

【請求項6】

外部装置から所定指示を受信する第２の受信手段を更に備え、
前記所定条件は、前記所定指示を受信した場合に満たされる、請求項２に記載の制御装置。

【請求項7】

前記所定指示は、前記モバイルＩＡＢノードの管理者または所有者が前記アクセス制限の解除を許可した場合に生成される、請求項６に記載の制御装置。

【請求項8】

前記所定条件は、前記モバイルＩＡＢノードに係るＩＡＢネットワークのＩＡＢドナーの状態が所定状態である場合に満たされる、請求項２に記載の制御装置。

【請求項9】

前記要求は、前記アクセス制限の解除の開始時に関する情報、前記アクセス制限の解除を実行した場合の終了時に関する情報、及び、前記アクセス制限の解除が適用される位置範囲に関する範囲情報、のうちの少なくともいずれか１つを含む、請求項１に記載の制御装置。

【請求項10】

前記送信手段は、ＢＡＰ（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）、又はＦ１ＡＰ（Ｆ１ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用して前記要求を送信する、請求項１に記載の制御装置。

【請求項11】

前記送信手段は、周辺に位置する不特定の１つ以上のモバイルＩＡＢノードに対して、前記要求を繰り返し送信する、請求項１に記載の制御装置。

【請求項12】

前記モバイルＩＡＢノードに係るＩＡＢネットワークのＩＡＢドナーに設けられる、請求項１に記載の制御装置。

【請求項13】

前記制御装置は、前記モバイルＩＡＢノードに係るＩＡＢネットワークの外部に位置する制御装置であり、
前記制御装置の前記送信手段は、前記ＩＡＢネットワークのＩＡＢドナーを介して、前記要求を送信する、請求項１に記載の制御装置。

【請求項14】

接続可能な基地局がない旨の通知を、ＩＡＢネットワークのＩＡＢドナーに送信する、通信装置。

【請求項15】

アクセス制限に関する状態を、アクセス制限が設定されている第１状態と、アクセス制限が設定されていない又は前記第１状態よりも制限度合いが緩い第２状態との間で切り替える処理手段と、
前記第１状態において制限対象のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）からの接続要求を受け付けず、前記第２状態において制限対象のＵＥからの接続要求を受け付けるアクセス制御手段とを備え、
前記処理手段は、前記第１状態においてアクセス制限を解除することを求める第１の要求を受信した場合に、前記第１状態から前記第２状態への切り替えを実行する、通信装置。

【請求項16】

前記処理手段は、前記第１の要求を受信した場合、前記第１状態から前記第２状態への切替条件の成否を判断する、請求項１５に記載の通信装置。

【請求項17】

前記処理手段は、前記第２状態において前記アクセス制限の解除を停止することを求める第２の要求を受信した場合、前記第２状態から前記第１状態への切り替えを実行する、請求項１５に記載の通信装置。

【請求項18】

前記第１の要求は、前記アクセス制限の解除が適用される位置範囲に関する範囲情報を含み、
自局が前記位置範囲に位置するか否かを判定する判定手段を更に備え、
前記処理手段は、前記第１の要求を受信した場合に、前記判定手段の判定結果に基づいて、自局が前記位置範囲に位置する場合に、前記第１状態から前記第２状態への切り替えを実行する、請求項１５から１７のうちのいずれか１項に記載の通信装置。

【請求項19】

通信を制御する制御方法であって、
アクセス制限が設定されているモバイルＩＡＢノードに対して、前記アクセス制限を解除することを求める要求を送信する工程を含む、制御方法。

【請求項20】

コンピュータに、
アクセス制限が設定されているモバイルＩＡＢノードに対して、前記アクセス制限を解除することを求める要求を送信する工程、を実行させるためのプログラム。

【請求項21】

通信を制御する制御方法であって、
アクセス制限に関する状態を、アクセス制限が設定されている第１状態と、アクセス制限が設定されていない又は前記第１状態よりも制限度合いが緩い第２状態との間で切り替える切替工程と、
前記第１状態において制限対象のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）からの接続要求を受け付けず、前記第２状態において制限対象のＵＥからの接続要求を受け付ける工程とを有し、
前記切替工程では、前記第１状態においてアクセス制限を解除することを求める第１の要求を受信した場合に、前記第１状態から前記第２状態への切り替えが実行されること特徴とする制御方法。

【請求項22】

コンピュータに、
アクセス制限に関する状態を、アクセス制限が設定されている第１状態と、アクセス制限が設定されていない又は前記第１状態よりも制限度合いが緩い第２状態との間で切り替える切替工程と、
前記第１状態において制限対象のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）からの接続要求を受け付けず、前記第２状態において制限対象のＵＥからの接続要求を受け付ける工程と、を実行させるためのプログラムであって、
前記切替工程では、前記第１状態においてアクセス制限を解除することを求める第１の要求を受信した場合に、前記第１状態から前記第２状態への切り替えが実行されることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【0005】

ＩＡＢ技術において、ＩＡＢドナーとＩＡＢノード間、及びＩＡＢノード間はＢＡＰ（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を介して制御される。

【0006】

ＢＡＰは、主に複数のＩＡＢノード間でデータをルーティングするためのプロトコルとして規定されている。

【0007】

これまで３ＧＰＰのＩＡＢに関連する仕様検討において、Ｒｅｌｅａｓｅ－１７までは固定基地局（移動を伴わないＩＡＢノード）について仕様策定を実施してきた。

【0008】

現在、３ＧＰＰ（登録商標）ではＲｅｌｅａｓｅ－１８でユースケースとなる車載リレー（Ｖｅｈｉｃｌｅ Ｍｏｕｎｔｅｄ Ｒｅｌａｙ）と、そのユースケースを実現するための仕様策定が行われる予定である。

【先行技術文献】

【特許文献】

【0009】

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

【発明の概要】

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

【0010】

車載リレーは、ＩＡＢノード相当の機能を自動車や電車などの移動体に搭載することを想定している。移動するＩＡＢノードといった特性から車載リレーは、モバイルＩＡＢやモバイルＩＡＢノードとも呼称される。このようなモバイルＩＡＢノードを実際に動作させるためには、これまで議論されてきた固定基地局を想定した仕様だけでは満たせない様々な要件が必要となる。

【0011】

ところで、モバイルＩＡＢノードは、公衆網のカバレッジエリアを広げたり、公衆網の輻輳を緩和したりするための臨時ノードとして柔軟に公衆網を調整するといった役割を担うことが期待される。

【0012】

また、モバイルＩＡＢノードは、自動車等の所有者やその家族等、一部の関係者のＵＥに接続相手を限定するアクセス制限を行い、車載の個人向けブロードバンド回線として使用するといった役割を担うことも期待されている。

【0013】

モバイルＩＡＢノードに対して前者の役割を担わせるか、後者の役割を担わせるかの動作モードを切り替え可能にすることも１つのユースケースとして考えられる。具体例について説明する。例えば、アクセス制限をかけた個人向けブロードバンド回線として利用する役割で動作するモバイルＩＡＢノードについて、そのアクセス制限を一時的に解除し、公衆網として利用できるようにすると、柔軟に公衆網の輻輳を緩和できると考えられる。

【0014】

しかしながら、ユーザや通信事業者にとって利便性の高い態様でモバイルＩＡＢノードにおけるアクセス制限に係る切り替えを実現可能とする仕組みが考えられていないといった課題がある。

【0015】

本発明は、上述の課題の少なくとも１つを鑑みなされたものである。本発明の１つの側面としては、ユーザや通信事業者にとって利便性の高い切り替えの仕組みを提供することを課題とする。

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

【0016】

本発明の１つの側面としての制御装置は、アクセス制限が設定されているモバイルＩＡＢノードに対して、前記アクセス制限を解除することを求める要求を送信する送信手段を備える。

【発明の効果】

【0017】

本発明の１つの側面によれば、ユーザや通信事業者にとって利便性の高い態様でモバイルＩＡＢノードにおけるアクセス制限に係る切り替えを実現可能とする仕組みを提供することが可能となる。

【図面の簡単な説明】

【0018】

【図1】本発明におけるＩＡＢドナー及びモバイルＩＡＢノードのハードウェア機能ブロック図である。

【図2A】本発明におけるＩＡＢドナーのソフトウェア機能ブロック図である。

【図2B】本発明におけるモバイルＩＡＢノードのソフトウェア機能ブロック図である。

【図3】実施形態１におけるシステム構成図である。

【図4】実施形態１におけるシーケンス図である。

【図5】実施形態１におけるＵＥの動作を示すフロー図である。

【図6】実施形態１におけるＩＡＢドナーの動作を示すフロー図である。

【図7】本発明におけるモバイルＩＡＢノードの動作を示すフロー図である。

【図8】実施形態２におけるシステム構成図である。

【図9】実施形態２におけるシーケンス図である。

【図10】実施形態２におけるＩＡＢドナーの動作を示すフロー図である。

【図11】実施形態３におけるシーケンス図である。

【図12】実施形態４におけるシステム構成図である。

【図13】実施形態４におけるシーケンス図である。

【図14】実施形態４におけるＵＥの動作を示すフロー図である。

【図15】本実施形態におけるＩＡＢドナーの動作を示すフロー図である。

【図16】本実施形態におけるモバイルＩＡＢノードの動作を示すフロー図である。

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

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

図１６は、本実施形態におけるモバイルＩＡＢノードの動作を示すフロー図である。

【0120】

Ｓ７０１及びＳ７０１は、上述した実施形態１の図７と同様なため、説明は省略する。

【0121】

Ｓ７０２及びＳ７０２Ａにおいて、アクセス制限解除判断部２１７は、アクセス制限解除の条件を満たしているか否かを判定する。本実施形態ではモバイルＩＡＢノードの所有者により事前にアクセス制限解除の許可が設定されているか否か（Ｓ７０２）に加えて、受信した範囲情報に自身の現在位置が含まれているか否か（Ｓ７０２Ａ）を条件とする。範囲情報に自身の現在位置が含まれている場合、Ｓ７０３へ進みアクセス制限解除を開始する。範囲情報に自身の現在位置が含まれていない場合、次の処理周期でＳ７００からの処理に戻る。

【0122】

Ｓ７０３は、上述した実施形態１の図７と同様なため、説明は省略する。

【0123】

Ｓ７０４及びＳ７０４Ａにおいて、モバイルＩＡＢノードのアクセス制限解除判断部２１７は、アクセス制限の再開の条件を満たしているか否かを判定する。本実施形態では「アクセス制限解除要求」を最後に受信してから一定期間経過したか否か（Ｓ７０４）に加えて、最後に受信した範囲情報に自身の現在位置が含まれているか否か（Ｓ７０４Ａ）を条件とする。自身の現在位置が範囲情報に含まれていない場合（Ｓ７０４Ａで“ＮＯ”）、Ｓ７０５へ進み、そうでない場合、次の処理周期でＳ７００からの処理に戻る。

【0124】

Ｓ７０５は、上述した実施形態１の図７と同様なため、説明は省略する。

【0125】

実施形態４では、アクセス制限解除要求に範囲情報を含めることで、アクセス制限解除するモバイルＩＡＢの範囲を限定する手順について説明した。これにより、特定のエリアに存在するモバイルＩＡＢノードのアクセス制限を外部から解除させることが可能となる。本実施形態では、ＵＥの位置情報に基づいて範囲情報を設定したが、実施形態２で説明した外部装置からのアクセス制限解除要求の通知要求や、実施形態３で説明した外部装置からのアクセス制限解除要求のメッセージに範囲情報を含めることで、外部から範囲情報を直接的に指定（設定）することも可能である。

【0126】

なお、本実施形態において、範囲情報の示すエリアの大きさは、一定であってもよいし、可変とされてもよい。例えば、範囲情報の示すエリアは、ＵＥが比較的高い密度で位置する領域をカバーするように動的に変更されてもよい。また、範囲情報の示すエリアは、イベントの有無や、時間帯や季節等に応じて変化されてもよい。

【0127】

以上、各実施形態について詳述したが、特定の実施形態に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施形態の構成要素を全部又は複数を組み合わせることも可能である。

【0128】

例えば、上述した実施形態では、モバイルＩＡＢノードにおけるアクセス制限に係る状態は、制限が設定された状態と、制限が（完全に）解除された状態の２種類であるが、これに限られない。例えば、モバイルＩＡＢノードにおけるアクセス制限に係る状態は、制限が設定された状態と、制限が部分的に解除された状態と、制限が解除された状態の３種類を有してもよい。この場合、実施形態１（他の実施形態も同様）において、ＩＡＢドナー３０２は、対象のモバイルＩＡＢノードに対して、当該アクセス制限を部分的に解除することを求める要求を送信してもよい。あるいは、モバイルＩＡＢノードは、ＩＡＢドナー３０２からの要求に応えて、制限が部分的に解除された状態を形成してもよい。

【0129】

また、上述した実施形態において、アクセス制限解除要求を受け入れるモバイルＩＡＢノードに対してインセンティブを付与する仕組みを追加してもよい。例えば、アクセス制限解除要求を受け入れた回数や時間等に応じて、モバイルＩＡＢノードに係る所有者にインセンティブ（ポイント等）が付与されてもよい。この場合、アクセス制限解除要求を受け入れるモバイルＩＡＢノードの増加が期待でき、通信の効率化を図ることができる。

【0130】

第３の実施形態では、外部装置からＩＡＢドナーを経由する遠隔操作でＩＡＢノードのアクセス制限を変更する場合を例示した。これに加えて、モバイルＩＡＢノードの所有者が自身の所有するＵＥからモバイルＩＡＢノードに対する直接の無線通信でアクセス制限状態の変更を指示するように構成することもできる。この場合、ＢｌｕｅｔｏｏｔｈやＩＥＥＥ８０２．１１規格シリーズ等の無線通信方式でモバイルＩＡＢノードとＵＥを接続する。ＢｌｕｅｔｏｏｔｈやＩＥＥＥ８０２．１１規格シリーズ等の無線通信方式でモバイルＩＡＢノードと無線接続したＵＥは、図示省略の設定画面を介してアクセス制限状態の変更操作を受け付ける。変更操作を受け付けたことを検知したＵＥは、アクセス制限状態の変更指示をモバイルＩＡＢノードに送信する。当該変更指示を受信したモバイルＩＡＢノードは、変更指示に従って、他のＩＡＢノードやＩＡＢドナー等と協働してアクセス制限状態を変更する。

【0131】

なお、以上の実施形態に関し、さらに以下の付記を開示する。

【0132】

［付記１］
アクセス制限が設定されているモバイルＩＡＢノードに対して、前記アクセス制限を解除することを求める要求を送信する送信手段を備える、制御装置。

【0133】

［付記２］
前記送信手段は、所定条件を満たす場合に、前記要求を送信する、付記１に記載の制御装置。

【0134】

［付記３］
ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）から接続可能な基地局がない旨を含む通知を受信する第１の受信手段を更に備え、
前記所定条件は、前記通知を受信した場合に満たされる、付記２に記載の制御装置。

【0135】

［付記４］
前記受信手段は、ＲＲＣメッセージにより前記通知を受信する、付記３に記載の制御装置。

【0136】

［付記５］
前記通知は、前記ＵＥの位置情報を含み、
前記送信手段は、前記位置情報に基づいて、前記アクセス制限の解除が適用される位置範囲に関する範囲情報を生成し、前記範囲情報を前記要求に含める、付記３又は４に記載の制御装置。

【0137】

［付記６］
外部装置から所定指示を受信する第２の受信手段を更に備え、
前記所定条件は、前記所定指示を受信した場合に満たされる、付記２から５のうちのいずれか１項に記載の制御装置。

【0138】

［付記７］
前記所定指示は、前記モバイルＩＡＢノードの管理者または所有者が前記アクセス制限の解除を許可した場合に生成される、付記６に記載の制御装置。

【0139】

［付記８］
前記所定条件は、前記モバイルＩＡＢノードに係るＩＡＢネットワークのＩＡＢドナーの状態が所定状態である場合に満たされる、付記２から５のうちのいずれか１項に記載の制御装置。

【0140】

［付記９］
前記要求は、前記アクセス制限の解除の開始時に関する情報、前記アクセス制限の解除を実行した場合の終了時に関する情報、及び、前記アクセス制限の解除が適用される位置範囲に関する範囲情報、のうちの少なくともいずれか１つを含む、付記１から８のうちのいずれか１項に記載の制御装置。

【0141】

［付記１０］
前記送信手段は、ＢＡＰ（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）、又はＦ１ＡＰ（Ｆ１ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用して前記要求を送信する、付記１から９のうちのいずれか１項に記載の制御装置。

【0142】

［付記１１］
前記送信手段は、周辺に位置する不特定の１つ以上のモバイルＩＡＢノードに対して、前記要求を繰り返し送信する、付記１から１０のうちのいずれか１項に記載の制御装置。

【0143】

［付記１２］
前記モバイルＩＡＢノードに係るＩＡＢネットワークのＩＡＢドナーに設けられる、付記１から１１のうちのいずれか１項に記載の制御装置。

【0144】

［付記１３］
前記制御装置は、前記モバイルＩＡＢノードに係るＩＡＢネットワークの外部に位置する制御装置であり、
前記制御装置の前記送信手段は、前記ＩＡＢネットワークのＩＡＢドナーを介して、前記要求を送信する付記１から１２のいずれか１項に記載の制御装置。

【0145】

［付記１４］
接続可能な基地局がない旨の通知を、ＩＡＢネットワークのＩＡＢドナーに送信する、通信装置。

【0146】

［付記１５］
アクセス制限に関する状態を、アクセス制限が設定されている第１状態と、アクセス制限が設定されていない又は前記第１状態よりも制限度合いが緩い第２状態との間で切り替える処理手段と、
前記第１状態において制限対象のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）からの接続要求を受け付けず、前記第２状態において制限対象のＵＥからの接続要求を受け付けるアクセス制御手段とを備え、
前記処理手段は、前記第１状態においてアクセス制限を解除することを求める第１の要求を受信した場合に、前記第１状態から前記第２状態への切り替えを実行する、通信装置。

【0147】

［付記１６］
前記処理手段は、前記第１の要求を受信した場合、前記第１状態から前記第２状態への切替条件の成否を判断する、付記１５に記載の通信装置。

【0148】

［付記１７］
前記処理手段は、前記第２状態において前記アクセス制限の解除を停止することを求める第２の要求を受信した場合、前記第２状態から前記第１状態への切り替えを実行する、付記１５又は１６に記載の通信装置。

【0149】

［付記１８］
前記第１の要求は、前記アクセス制限の解除が適用される位置範囲に関する範囲情報を含み、
自局が前記位置範囲に位置するか否かを判定する判定手段を更に備え、
前記処理手段は、前記第１の要求を受信した場合に、前記判定手段の判定結果に基づいて、自局が前記位置範囲に位置する場合に、前記第１状態から前記第２状態への切り替えを実行する、付記１５から１７のうちのいずれか１項に記載の通信装置。

【符号の説明】

【0150】

１０１ ハードウェア機能ブロック
１０２ 制御部
１０３ 記憶部
１０４ 無線通信部
１０５ 無線アンテナ制御部
１０６ ＧＰＳ通信部
１０７ ＧＰＳアンテナ制御部
２０１ ＩＡＢドナーのソフトウェア機能ブロック
２０２ 信号送信部（送信手段の一例）
２０３ 信号受信部（第１、第２の受信手段の一例）
２０４ データ記憶部
２０５ 接続制御部（送信手段の一例）
２０６ アクセス制限解除要求通知判断部（送信手段の一例）
２０７ メッセージ生成部
２１１ モバイルＩＡＢノードのソフトウェア機能ブロック
２１２ 信号送信部（処理手段の一例）
２１３ 信号受信部（処理手段の一例）
２１４ データ記憶部
２１５ 接続制御部
２１６ アクセス制限制御部（処理手段、アクセス制御手段の一例）
２１７ アクセス制限解除判断部（処理手段、アクセス制御手段、判定手段の一例）
３０１ ＵＥ
３０２ ＩＡＢドナー（制御装置の一例）
３０３ モバイルＩＡＢノード
３０４ モバイルＩＡＢノード
８０１ 外部装置
８０２ 外部装置（制御装置の一例）
１２００ アクセス制限解除要求エリア

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】