ホーム > 特許ランキング > ソニーグループ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023164085
(43)【公開日】2023-11-10
(54)【発明の名称】情報処理装置、情報処理方法、端末装置及びシステム
(51)【国際特許分類】
H04W 8/24 20090101AFI20231102BHJP
H04W 88/18 20090101ALI20231102BHJP
H04W 4/021 20180101ALI20231102BHJP
H04W 4/70 20180101ALI20231102BHJP
【ＦＩ】
H04W8/24
H04W88/18
H04W4/021
H04W4/70
【審査請求】未請求
【請求項の数】16
【出願形態】ＯＬ
(21)【出願番号】P 2022075413
(22)【出願日】2022-04-28
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】高野 裕昭
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067DD57
5K067EE02
5K067EE10
5K067EE16
5K067JJ52
(57)【要約】
【課題】より適切に端末装置と通信をすることができる仕組みを提供する。
【解決手段】本開示の情報処理装置は、制御部を有する。制御部は、コアネットワークからＳＢＩ（Service based interface）経由で端末装置に関する第１の情報を取得する。制御部は、第１の情報に基づいて計測した計測情報、及び、端末装置から直接又はＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得する。制御部は、第２の情報から、又は、第１の情報と第２の情報とを対応付けて端末装置を特定する。制御部は、第１の情報及び第２の情報の少なくとも一方を、特定した端末装置と対応付けてクライアント装置に通知する。
【選択図】図１
【解決手段】本開示の情報処理装置は、制御部を有する。制御部は、コアネットワークからＳＢＩ（Service based interface）経由で端末装置に関する第１の情報を取得する。制御部は、第１の情報に基づいて計測した計測情報、及び、端末装置から直接又はＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得する。制御部は、第２の情報から、又は、第１の情報と第２の情報とを対応付けて端末装置を特定する。制御部は、第１の情報及び第２の情報の少なくとも一方を、特定した端末装置と対応付けてクライアント装置に通知する。
【選択図】図１
【特許請求の範囲】
【請求項1】
コアネットワークからＳＢＩ（Service Based Interface）経由で端末装置に関する第１の情報を取得し、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備える情報処理装置。
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備える情報処理装置。
【請求項2】
前記端末関連情報は、前記端末装置のアプリケーションレイヤーが有する情報を含む、請求項１に記載の情報処理装置。
【請求項3】
前記端末関連情報は、Registrationのスケジュールに関するスケジュール情報、前記端末装置の消費電力に関する電力情報、及び、前記端末装置の位置に関する位置情報の少なくとも１つを含む、請求項１に記載の情報処理装置。
【請求項4】
前記位置情報は、前記端末装置に搭載される機器を用いて測定される、請求項３に記載の情報処理装置。
【請求項5】
前記位置情報は、現在の位置情報、過去の位置情報、及び、未来の位置情報の少なくとも１つを含む、請求項３に記載の情報処理装置。
【請求項6】
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記クライアント装置は、前記電力情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
請求項３に記載の情報処理装置。
前記クライアント装置は、前記電力情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
請求項３に記載の情報処理装置。
【請求項7】
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記クライアント装置は、前記位置情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
請求項３に記載の情報処理装置。
前記クライアント装置は、前記位置情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
請求項３に記載の情報処理装置。
【請求項8】
前記制御部は、前記クライアント装置が指定する条件を満たす前記端末装置に関する情報を少なくとも１つ含むグループ情報を前記クライアント装置に通知する、請求項１に記載の情報処理装置。
【請求項9】
前記条件は、前記端末装置のRegistrationの状態を指定するRegistration条件、前記端末装置の消費電力の状態を指定する電力条件、及び、前記端末装置の位置を指定する位置条件の少なくとも１つを含む、請求項８に記載の情報処理装置。
【請求項10】
前記位置条件は、前記端末装置の現在の位置、過去の位置、及び、未来の位置の少なくとも１つを指定する条件を含む、請求項９に記載の情報処理装置。
【請求項11】
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記計測情報は、前記Registration情報に基づいて算出される前記端末装置のRegistrationの遷移間隔に関する情報を含む、
請求項１に記載の情報処理装置。
前記計測情報は、前記Registration情報に基づいて算出される前記端末装置のRegistrationの遷移間隔に関する情報を含む、
請求項１に記載の情報処理装置。
【請求項12】
前記計測情報は、前記端末装置がIdle状態に遷移するまでのIdle遷移時間に関する情報を含む、請求項１１に記載の情報処理装置。
【請求項13】
前記クライアント装置は、前記計測情報に基づき、前記端末装置がIdle状態に遷移するタイミング以前に、前記端末装置と通信を行う、請求項１２に記載の情報処理装置。
【請求項14】
コアネットワークからＳＢＩ（Service Based Interface）経由で端末装置に関する第１の情報を取得することと、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得することと、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定することと、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知することと、
を含む情報処理方法。
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得することと、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定することと、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知することと、
を含む情報処理方法。
【請求項15】
情報処理装置に直接、又は、ＳＢＩ（Service Based Interface）経由で端末関連情報を通知する、制御部、
を備える端末装置であって、
前記情報処理装置は、
コアネットワークからＳＢＩ経由で前記端末装置に関する第１の情報を取得し、
前記端末関連情報から、又は、前記第１の情報と前記端末関連情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記端末関連情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、
端末装置。
を備える端末装置であって、
前記情報処理装置は、
コアネットワークからＳＢＩ経由で前記端末装置に関する第１の情報を取得し、
前記端末関連情報から、又は、前記第１の情報と前記端末関連情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記端末関連情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、
端末装置。
【請求項16】
第１の情報処理装置と、コアネットワークのネットワークファンクションとして機能する第２の情報処理装置と、端末装置と、を備えるシステムであって、
前記第１の情報処理装置は、
前記第２の情報処理装置からＳＢＩ（Service Based Interface）経由で前記端末装置に関する第１の情報を取得し、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備えるシステム。
前記第１の情報処理装置は、
前記第２の情報処理装置からＳＢＩ（Service Based Interface）経由で前記端末装置に関する第１の情報を取得し、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備えるシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理装置、情報処理方法、端末装置及びシステムに関する。
【背景技術】
【0002】
近年、セルラー方式の無線通信では、通信サービスの多様化に対応するため、新たな技術が導入されている。例えば、モバイルネットワークが、端末との間の通信状況をサードパーティーのアプリケーションファンクション（ＡＦ）に開示することで、ＡＦは、ネットワークケイパビリティにあわせてＰＤＵセッションを確立する技術が知られている。
【0003】
また、端末装置（ＵＥ：User Equipment）がエリア制限関連情報に基づいてＰＤＵセッション関連シグナリングを送信するか否かを判定する技術が知られている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特表２０２１－５１３２６９号公報
【特許文献2】特表２０２１－５３２６７５号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上述した技術では、ＡＦは、モバイルネットワークの各ＮＦ（Network Function）からデータを取得する。しかしながら、ＡＦは、端末装置に関するデータを十分に取得することができているとは言い難かった。
【0006】
例えば、端末装置がＩｏＴ（Internet of Things）端末である場合、端末装置とやり取りを行うクライアント（ＡＦの一例）は、端末装置に関するデータを用いることで、より適切に端末装置と通信を行うことができる。このように、クライアントが、端末装置に関するデータを取得することで、より適切に端末装置と通信をすることが望まれる。
【0007】
そこで、本開示では、より適切に端末装置と通信をすることができる仕組みを提供する。
【0008】
なお、上記課題又は目的は、本明細書に開示される複数の実施形態が解決し得、又は達成し得る複数の課題又は目的の１つに過ぎない。
【課題を解決するための手段】
【0009】
本開示の情報処理装置は、制御部を有する。制御部は、コアネットワークからＳＢＩ（Service Based Interface）経由で端末装置に関する第１の情報を取得する。制御部は、前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得する。制御部は、前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定する。制御部は、前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する。
【図面の簡単な説明】
【0010】
【図1】本開示の実施形態に係る情報処理システムの概要を説明するための図である。
【図2】本開示の実施形態に係る情報処理装置の構成例を示す図である。
【図3】本開示の実施形態に係る基地局の構成例を示す図である。
【図4】本開示の実施形態に係る端末装置の構成例を示す図である。
【図5】５Ｇのアーキテクチャの一例を示す図である。
【図6】本開示の実施形態に係るPrivate 5G Networkの構成例について説明するための図である。
【図7】本開示の実施形態に係るＡＰＩを説明するための図である。
【図8】本開示の実施形態に係る情報処理システムの一例を示す図である。
【図9】基地局によるIdle遷移時間の設定例を示すシーケンス図である。
【図10】本開示の第１の実施形態に係る第１の情報処理の流れの一例を示すシーケンス図である。
【図11】本開示の第１の実施形態に係る確認処理の流れの一例を示すフローチャートである。
【図12】本開示の第１の実施形態に係るＲＡＭＮＦによるＵＥ状態のスケジューリングの一例について説明するための図である。
【図13】本開示の第２の実施形態に係る情報処理システムの一例を示す図である。
【図14】本開示の第２の実施形態に係る登録スケジュール情報の提供処理の流れの一例を示すシーケンス図である。
【図15】本開示の第２の実施形態に係る登録スケジュールの一例を示す図である。
【図16】本開示の第２の実施形態に係るRegistrationに関するスケジュールの一例を示す図である。
【図17】本開示の第２の実施形態に係る電力情報の提供処理の流れの一例を示すシーケンス図である。
【図18】本開示の第２の実施形態に係る接続スケジュールの一例を示す図である。
【図19】本開示の第２の実施形態に係る電力情報を示す図表である。
【図20】本開示の第２の実施形態に係る端末位置情報の一例を示す図表である。
【図21】本開示の第２の実施形態に係る現在の端末位置情報の提供処理の流れの一例を示すシーケンス図である。
【図22】本開示の第２の実施形態に係る過去の端末位置情報の提供処理の流れの一例を示すシーケンス図である。
【図23】本開示の第２の実施形態に係る未来の端末位置情報の提供処理の流れの一例を示すシーケンス図である。
【図24】本開示の第２の実施形態に係るＲＡＭＮＦによる情報の統合の一例を説明するための図である。
【図25】本開示の第３の実施形態に係るRegistration条件に応じた提供処理の流れの一例を示すシーケンス図である。
【図26】本開示の第３の実施形態に係るグループ情報の一例を示す図表である。
【図27】本開示の第３の実施形態に係るRegistration条件に応じた提供処理の流れの他の例を示すシーケンス図である。
【図28】本開示の第３の実施形態に係る位置条件に応じた提供処理の流れの一例を示すシーケンス図である。
【図29】本開示の第３の実施形態に係る電力条件に応じた提供処理の流れの一例を示すシーケンス図である。
【図30】本開示の第１の適用例に係る情報処理システムの一例を示す図である。
【図31】本開示の第２の適用例に係る情報処理システムの一例を示す図である。
【発明を実施するための形態】
【0011】
以下に添付図面を参照しながら、本開示の実施形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0012】
また、本明細書及び図面において、実施形態の類似する構成要素については、同一の符号の後に異なるアルファベット又は数字を付して区別する場合がある。ただし、類似する構成要素の各々を特に区別する必要がない場合、同一符号のみを付する。
【0013】
以下に説明される１又は複数の実施形態（実施例、変形例、適用例を含む）は、各々が独立に実施されることが可能である。一方で、以下に説明される複数の実施形態は少なくとも一部が他の実施形態の少なくとも一部と適宜組み合わせて実施されてもよい。これら複数の実施形態は、互いに異なる新規な特徴を含み得る。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し得、互いに異なる効果を奏し得る。
【0014】
＜＜１．はじめに＞＞
＜１．１．課題＞
近年、５Ｇのネットワークを使用するサービスに関する技術が注目されている。５Ｇのネットワークと５Ｇのネットワークを使用するサービスとは、基本的には独立に動作している。そのため、サービス側がネットワーク側の情報を十分に利用しているとはいいがたかった。
＜１．１．課題＞
近年、５Ｇのネットワークを使用するサービスに関する技術が注目されている。５Ｇのネットワークと５Ｇのネットワークを使用するサービスとは、基本的には独立に動作している。そのため、サービス側がネットワーク側の情報を十分に利用しているとはいいがたかった。
【0015】
サービス側は、５Ｇ ＡＰＩを使用することで、一部のネットワーク側の情報を得ることができるが、それでも、十分な情報を取得できているとは言えなかった。また、サービス側も、ネットワーク側に取得したい情報のリクエストを十分に通知できているとは言えなかった。
【0016】
例えば、サービス側が、ネットワークを介してやり取りを行う端末装置に関する情報を取得することで、端末装置とのやり取りをより適切に行うことができるようになる。例えば、サービス側は、端末装置の電力状態やより詳細な位置情報などを取得することで、電力残量が所定以上の端末装置や特定のエリアに位置する端末装置など、サービスに応じて端末装置を選択してやり取りすることができるようになる。
【0017】
このように、サービス側で端末装置との通信をより適切に行うことができる仕組みが求められる。
【0018】
＜１．２．提案技術の概要＞
図１は、本開示の実施形態に係る情報処理システム１の概要を説明するための図である。図１に示す情報処理システム１は、情報処理装置１０Ａ～１０Ｃと、基地局２０と、端末装置４０と、を有する。
図１は、本開示の実施形態に係る情報処理システム１の概要を説明するための図である。図１に示す情報処理システム１は、情報処理装置１０Ａ～１０Ｃと、基地局２０と、端末装置４０と、を有する。
【0019】
情報処理装置１０Ａは、例えば、コアネットワークＣＮ（ネットワークの一例）の機能を実現するサーバ装置である。ここでは１つの情報処理装置１０ＡがコアネットワークＣＮの機能を実現するとしたが、複数の情報処理装置１０が協調してコアネットワークＣＮの機能を実現するようにしてもよい。
【0020】
情報処理装置１０Ｂは、例えば、ＲＡＭＮＦ（Reachability Management Network Function）１００の機能を実現するサーバ装置である。ＲＡＭＮＦ１００は、サービス側のクライアント２００に対してコアネットワークＣＮの情報を通知するプラットフォームである。なお、図１では、ＲＡＭＮＦ１００が、コアネットワークＣＮとは異なるＮＦ（ＡＦ）である場合について示しているが、ＲＡＭＮＦ１００は、コアネットワークＣＮ内のＮＦとして実現されてもよい。
【0021】
情報処理装置１０Ｃは、例えば、サーバ側のクライアント２００の機能を実現するサーバ装置（クライアント装置）である。クライアント２００は、例えば、端末装置４０とやり取りを行ったり、端末装置４０を制御したりすることで、ユーザに対して所定のサービスを提供する。
【0022】
基地局２０は、端末装置４０と無線通信する無線通信装置である。基地局２０は、通信装置の一種である。また、基地局２０は、情報処理装置の一種である。
【0023】
端末装置４０は、基地局２０と無線通信する無線通信装置である。端末装置４０は、例えば、携帯電話、スマートデバイス（スマートフォン、又はタブレット）、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータである。また、端末装置４０は、Ｍ２Ｍ（Machine to Machine）デバイス、又はＩｏＴデバイスであってもよい。また、端末装置４０は、ヘッドマウントディスプレイ（Head Mounted Display）やＶＲゴーグル等であってもよい。また、端末装置４０は、車両（自動車）やドローン等のモビリティであってもよい。
【0024】
例えば、端末装置４０が携帯電話である場合、クライアント２００は、端末装置４０を使用するユーザに対して、所定のサービスを提供する。また、端末装置４０が、Ｍ２ＭデバイスやＩｏＴデバイス等である場合、クライアント２００は、端末装置４０からデータを取得したり、端末装置４０を制御したりすることで、ユーザに対して所定のサービスを提供する。
【0025】
図１に示すように、ＲＡＭＮＦ１００は、コアネットワークＣＮからＳＢＩ（Service Based Interface）経由で端末装置４０に関する第１の情報を取得する（ステップＳ１）。第１の情報は、例えば、端末装置４０のRegistrationに関するRegistration情報（例えば、registered／De-registeredやConnected／Idleなど）を含む。
【0026】
ＲＡＭＮＦ１００は、端末装置４０から直接又はＳＢＩ経由で取得した端末関連情報を取得する（ステップＳ２）。ＲＡＭＮＦ１００は、第１の情報に基づいて計測した計測情報を取得する（ステップＳ３）。なお、ＲＡＭＮＦ１００は、端末関連情報及び計測情報の少なくとも一方を取得してもよい。以下、計測情報及び／又は端末関連情報をまとめて第２の情報とも記載する。
【0027】
計測情報は、Registration情報に基づいて算出される端末装置４０のRegistrationの遷移間隔に関する情報を含む。端末関連情報は、例えば、端末装置４０のアプリケーションレイヤーが有する情報を含む。より具体的には、端末関連情報は、例えば、Registrationのスケジュールに関するスケジュール情報、端末装置４０の消費電力に関する電力情報、及び、端末装置４０の位置に関する位置情報の少なくとも１つを含む。
【0028】
ＲＡＭＮＦ１００は、第２の情報から、又は、第１の情報と第２の情報とを対応付けて端末装置４０を特定する（ステップＳ４）。ＲＡＭＮＦ１００は、例えば、第２の情報、及び／又は、第１の情報に含まれる端末装置４０を特定する情報（例えば、ＩＭＳＩやＳＵＰＩなどのUE ID）を用いて端末装置４０を特定する。ＲＡＭＮＦ１００は、第１の情報及び第２の情報の少なくとも一方を、特定した端末装置４０と対応付けてクライアント２００に通知する（ステップＳ５）。
【0029】
これにより、クライアント２００は、端末装置４０のより詳細な情報を取得することができ、端末装置４０との通信をより適切に行うことができる。例えば、クライアント２００は、所定のエリアに位置する端末装置４０を選択して通信を行ったり、消費電力に余裕がある端末装置４０を選択して通信を行ったりすることができる。
【0030】
＜＜２．通信システムの構成＞＞
＜２．１．情報処理装置の構成例＞
情報処理装置１０は、ネットワークＮ（図１参照）に接続する情報処理装置（コンピュータ）である。例えば、情報処理装置１０は、コアネットワークＣＮの機能の少なくとも一部を実現する情報処理装置である。例えば、情報処理装置１０は、ＲＡＭＮＦ１００の機能の少なくとも一部を実現する情報処理装置である。例えば、情報処理装置１０は、クライアント２００の機能の少なくとも一部を実現する情報処理装置である。
＜２．１．情報処理装置の構成例＞
情報処理装置１０は、ネットワークＮ（図１参照）に接続する情報処理装置（コンピュータ）である。例えば、情報処理装置１０は、コアネットワークＣＮの機能の少なくとも一部を実現する情報処理装置である。例えば、情報処理装置１０は、ＲＡＭＮＦ１００の機能の少なくとも一部を実現する情報処理装置である。例えば、情報処理装置１０は、クライアント２００の機能の少なくとも一部を実現する情報処理装置である。
【0031】
図２は、本開示の実施形態に係る情報処理装置１０の構成例を示す図である。情報処理装置１０は、通信部１１と、記憶部１２と、制御部１３と、を備える。なお、図２に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、情報処理装置１０の機能は、複数の物理的に分離された構成に静的、或いは、動的に分散して実装されてもよい。例えば、情報処理装置１０は、複数のサーバ装置により構成されていてもよい。
【0032】
通信部１１は、他の装置と通信するための通信インタフェースである。通信部１１は、ネットワークインタフェースであってもよいし、機器接続インタフェースであってもよい。例えば、通信部１１は、ＮＩＣ（Network Interface Card）等のＬＡＮ（Local Area Network）インタフェースであってもよいし、ＵＳＢ（Universal Serial Bus）ホストコントローラ、ＵＳＢポート等により構成されるＵＳＢインタフェースであってもよい。また、通信部１１は、有線インタフェースであってもよいし、無線インタフェースであってもよい。通信部１１は、情報処理装置１０の通信手段として機能する。通信部１１は、制御部１３の制御に従って、他の情報処理装置１０や基地局２０等と通信する。
【0033】
記憶部１２は、ＤＲＡＭ（Dynamic Random Access Memory）、ＳＲＡＭ（Static Random Access Memory）、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部１２は、情報処理装置１０の記憶手段として機能する。
【0034】
制御部１３は、情報処理装置１０の各部を制御するコントローラ（controller）である。制御部１３は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）等のプロセッサにより実現される。例えば、制御部１３は、情報処理装置１０内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ（Random Access Memory）等を作業領域として実行することにより実現される。なお、制御部１３は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。
【0035】
＜２．２．基地局の構成例＞
基地局２０は、セルを運用し、セルのカバレッジの内部に位置する１つ以上の端末装置４０へ無線通信サービスを提供する通信装置である。セルは、例えばＬＴＥ又はＮＲ等の任意の無線通信方式に従って運用される。基地局２０は、コアネットワークＣＮに接続される。コアネットワークＣＮは、ゲートウェイ装置を介してパケットデータネットワークに接続される。
基地局２０は、セルを運用し、セルのカバレッジの内部に位置する１つ以上の端末装置４０へ無線通信サービスを提供する通信装置である。セルは、例えばＬＴＥ又はＮＲ等の任意の無線通信方式に従って運用される。基地局２０は、コアネットワークＣＮに接続される。コアネットワークＣＮは、ゲートウェイ装置を介してパケットデータネットワークに接続される。
【0036】
なお、基地局２０は、複数の物理的又は論理的装置の集合で構成されていてもよい。例えば、本開示の実施形態において基地局２０は、ＢＢＵ（Baseband Unit）及びＲＵ（Radio Unit）の複数の装置に区別され、これら複数の装置の集合体として解釈されてもよい。さらに又はこれに代えて、本開示の実施形態において基地局２０は、ＢＢＵ及びＲＵのうちいずれか又は両方であってもよい。ＢＢＵとＲＵとは所定のインタフェース（例えば、ｅＣＰＲＩ）で接続されていてもよい。さらに又はこれに代えて、ＲＵはRemote Radio Unit（ＲＲＵ）又はRadio DoT（ＲＤ）と称されていてもよい。さらに又はこれに代えて、ＲＵは後述するgNB-DUに対応していてもよい。さらに又はこれに代えてＢＢＵは、後述するgNB-CUに対応していてもよい。これに代えて、ＲＵは後述するgNB-DUに接続していてもよい。さらに、ＢＢＵは、後述するgNB-CU及びgNB-DUの組合せに対応していてもよい。さらに又はこれに代えて、ＲＵはアンテナと一体的に形成された装置であってもよい。基地局２０が有するアンテナ（例えば、ＲＵと一体的に形成されたアンテナ）はAdvanced Antenna Systemを採用し、ＭＩＭＯ（例えば、FD-MIMO）やビームフォーミングをサポートしていてもよい。Advanced Antenna Systemは、基地局２０が有するアンテナ（例えば、ＲＵと一体的に形成されたアンテナ）は、例えば、６４個の送信用アンテナポート及び６４個の受信用アンテナポートを備えていてもよい。
【0037】
また、基地局２０は、複数が互いに接続されていてもよい。１つ又は複数の基地局２０は無線アクセスネットワーク（Radio Access Network：ＲＡＮ）に含まれていてもよい。すなわち、基地局２０は単にＲＡＮ、ＲＡＮノード、ＡＮ（Access Network）、ＡＮノードと称されてもよい。ＬＴＥにおけるＲＡＮはＥＵＴＲＡＮ（Enhanced Universal Terrestrial RAN）と呼ばれる。ＮＲにおけるＲＡＮはＮＧＲＡＮと呼ばれる。Ｗ－ＣＤＭＡ（ＵＭＴＳ）におけるＲＡＮはＵＴＲＡＮと呼ばれる。ＬＴＥの基地局２０は、ｅＮｏｄｅＢ（Evolved Node B）又はｅＮＢと称される。すなわち、ＥＵＴＲＡＮは１又は複数のｅＮｏｄｅＢ（ｅＮＢ）を含む。また、ＮＲの基地局２０は、ｇＮｏｄｅＢ又はｇＮＢと称される。すなわち、ＮＧＲＡＮは１又は複数のｇＮＢを含む。さらに、ＥＵＴＲＡＮは、ＬＴＥの通信システム（ＥＰＳ）におけるコアネットワーク（ＥＰＣ）に接続されたｇＮＢ（ng-eNB）を含んでいてもよい。同様にＮＧＲＡＮは５Ｇ通信システム（５ＧＳ）におけるコアネットワーク５ＧＣに接続されたgNBを含んでいてもよい。さらに又はこれに代えて、基地局２０がｅＮＢ、ｇＮＢなどである場合、3GPP Accessと称されてもよい。さらに又はこれに代えて、基地局２０が無線アクセスポイント（Access Point）（e.g., ＷｉＦｉ（登録商標）のアクセスポイント）である場合、Non-3GPP Accessと称されてもよい。さらに又はこれに代えて、基地局２０は、ＲＲＨ（Remote Radio Head）と呼ばれる光張り出し装置であってもよい。さらに又はこれに代えて、基地局２０がｇＮＢである場合、基地局２０は前述したgNB CU（Central Unit）とgNB DU（Distributed Unit）の組み合わせ又はこれらのうちいずれかと称されてもよい。gNB CU（Central Unit）は、ＵＥとの通信のために、Access Stratumのうち、複数の上位レイヤ（例えば、ＲＲＣ、ＳＤＡＰ、ＰＤＣＰ）をホストする。一方、gNB-DUは、Access Stratumのうち、複数の下位レイヤ（例えば、ＲＬＣ、ＭＡＣ、ＰＨＹ）をホストする。すなわち、後述されるメッセージ・情報のうち、RRC signalling（例えば、ＭＩＢ、ＳＩＢ１を含む各種ＳＩＢ、RRCSetup message、RRCReconfiguration message）はgNB CUで生成され、一方で後述されるＤＣＩや各種Physical Channel（例えば、ＰＤＣＣＨ、ＰＢＣＨ）はgNB-DUは生成されてもよい。又はこれに代えて、RRC signallingのうち、例えばIE：cellGroupConfigなど一部のconfiguration（設定情報）についてはgNB-DUで生成され、残りのconfigurationはgNB-CUで生成されてもよい。これらのconfiguration（設定情報）は、後述されるＦ１インタフェースで送受信されてもよい。基地局２０は、他の基地局２０と通信可能に構成されていてもよい。例えば、複数の基地局２０がｅＮＢ同士又はｅＮＢとgn-eNBの組み合わせである場合、当該基地局２０間はＸ２インタフェースで接続されてもよい。さらに又はこれに代えて、複数の基地局２０がｇＮＢ同士又はgn-eNBとｇＮＢの組み合わせである場合、当該装置間はＸｎインタフェースで接続されてもよい。さらに又はこれに代えて、複数の基地局２０がgNB CU（Central Unit）とgNB DU（Distributed Unit）の組み合わせである場合、当該装置間は前述したＦ１インタフェースで接続されてもよい。後述されるメッセージ・情報（RRC signalling又はＤＣＩの情報、Physical Channel）は複数の基地局２０間で（例えばＸ２、Ｘｎ、Ｆ１インタフェースを介して）通信されてもよい。
【0038】
さらに、前述の通り、基地局２０は、複数のセルを管理するように構成されていてもよい。基地局２０により提供されるセルはServing cellと呼ばれる。Serving cellはPCell（Primary Cell）及びSCell（Secondary Cell）を含む。Dual Connectivity （例えば、EUTRA-EUTRA Dual Connectivity、EUTRA-NR Dual Connectivity（ENDC）、EUTRA-NR Dual Connectivity with 5GC、NR-EUTRA Dual Connectivity（NEDC）、NR-NR Dual Connectivity）がＵＥ（例えば、端末装置４０）に提供される場合、ＭＮ（Master Node）によって提供されるPCell及びゼロ又は1以上のSCell（s）はMaster Cell Groupと呼ばれる。さらに、Serving cellはPSCell（Primary Secondary Cell又はPrimary SCG Cell）を含んでもよい。すなわち、Dual ConnectivityがＵＥに提供される場合、ＳＮ（Secondary Node）によって提供されるPSCell及びゼロ又は1以上のSCell（s）はSecondary Cell Group（SCG）と呼ばれる。特別な設定（例えば、PUCCH on SCell）がされていない限り、物理上りリンク制御チャネル（ＰＵＣＣＨ）はPCell及びPSCellで送信されるが、SCellでは送信されない。また、Radio Link FailureもPCell及びPSCellでは検出されるが、SCellでは検出されない（検出しなくてよい）。このようにPCell及びPSCellは、Serving Cell（s）の中で特別な役割を持つため、Special Cell（SpCell）とも呼ばれる。１つのセルには、１つのDownlink Component Carrierと１つのUplink Component Carrierが対応付けられてもよい。また、１つのセルに対応するシステム帯域幅は、複数の帯域幅部分（Bandwidth Part）に分割されてもよい。この場合、１又は複数のBandwidth Part（ＢＷＰ）がＵＥに設定され、１つのBandwidth PartがActive BWPとして、ＵＥに使用されてもよい。また、セル毎、コンポーネントキャリア毎又はＢＷＰごとに、端末装置４０が使用できる無線資源（例えば、周波数帯域、ヌメロロジー（サブキャリアスペーシング）、スロットフォーマット（Slot configuration））が異なっていてもよい。
【0039】
図３は、本開示の実施形態に係る基地局２０の構成例を示す図である。基地局２０は、端末装置４０と無線通信する通信装置（無線システム）である。基地局２０は、情報処理装置の一種である。
【0040】
基地局２０は、信号処理部２１と、記憶部２２と、ネットワーク通信部２３と、制御部２４と、を備える。なお、図３に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、基地局２０の機能は、複数の物理的に分離された装置に分散して実装されてもよい。
【0041】
信号処理部２１は、他の通信装置（例えば、端末装置４０及び他の基地局２０）と無線通信する無線通信インタフェースである。信号処理部２１は、制御部２４の制御にしたがって動作する無線トランシーバである。信号処理部２１は複数の無線アクセス方式に対応してもよい。例えば、信号処理部２１は、ＮＲ及びＬＴＥの双方に対応してもよい。信号処理部２１は、Ｗ－ＣＤＭＡやｃｄｍａ２０００等の他のセルラー通信方式に対応してもよい。また、信号処理部２１は、セルラー通信方式に加えて、無線ＬＡＮ通信方式に対応してもよい。勿論、信号処理部２１は、１つの無線アクセス方式に対応するだけであってもよい。
【0042】
信号処理部２１は、受信処理部２１１と、送信処理部２１２と、アンテナ４１３と、を備える。信号処理部２１は、受信処理部２１１、送信処理部２１２、及びアンテナ４１３をそれぞれ複数備えていてもよい。なお、信号処理部２１が複数の無線アクセス方式に対応する場合、信号処理部２１の各部は、無線アクセス方式毎に個別に構成されうる。例えば、基地局２０がＮＲとＬＴＥとに対応しているのであれば、受信処理部２１１及び送信処理部２１２は、ＮＲとＬＴＥとで個別に構成されてもよい。
【0043】
受信処理部２１１は、アンテナ４１３を介して受信された上りリンク信号の処理を行う。受信処理部２１１は、無線受信部２１１ａと、多重分離部２１１ｂと、復調部２１１ｃと、復号部２１１ｄと、を備える。
【0044】
無線受信部２１１ａは、上りリンク信号に対して、ダウンコンバート、不要な周波数成分の除去、増幅レベルの制御、直交復調、デジタル信号への変換、ガードインターバルの除去、高速フーリエ変換による周波数領域信号の抽出等を行う。例えば、基地局２０の無線アクセス方式が、ＬＴＥ等のセルラー通信方式であるとする。このとき、多重分離部２１１ｂは、無線受信部２１１ａから出力された信号から、ＰＵＳＣＨ（Physical Uplink Shared Channel）、ＰＵＣＣＨ（Physical Uplink Control Channel）等の上りリンクチャネル及び上りリンク参照信号を分離する。復調部２１１ｃは、上りリンクチャネルの変調シンボルに対して、ＢＰＳＫ（Binary Phase Shift Keying）、ＱＰＳＫ（Quadrature Phase Shift Keying）等の変調方式を使って受信信号の復調を行う。復調部２１１ｃが使用する変調方式は、１６ＱＡＭ（Quadrature Amplitude Modulation）、６４ＱＡＭ、又は２５６ＱＡＭ等の多値ＱＡＭであってもよい。復号部２１１ｄは、復調された上りリンクチャネルの符号化ビットに対して、復号処理を行う。復号された上りリンクデータ及び上りリンク制御情報は制御部２４へ出力される。
【0045】
送信処理部２１２は、下りリンク制御情報及び下りリンクデータの送信処理を行う。送信処理部２１２は、符号化部２１２ａと、変調部２１２ｂと、多重部２１２ｃと、無線送信部２１２ｄと、を備える。
【0046】
符号化部２１２ａは、制御部２４から入力された下りリンク制御情報及び下りリンクデータを、ブロック符号化、畳み込み符号化、ターボ符号化等の符号化方式を用いて符号化を行う。変調部２１２ｂは、符号化部２１２ａから出力された符号化ビットをＢＰＳＫ、ＱＰＳＫ、１６ＱＡＭ、６４ＱＡＭ、２５６ＱＡＭ等の所定の変調方式で変調する。多重部２１２ｃは、各チャネルの変調シンボルと下りリンク参照信号とを多重化し、所定のリソースエレメントに配置する。無線送信部２１２ｄは、多重部２１２ｃからの信号に対して、各種信号処理を行う。例えば、無線送信部２１２ｄは、高速フーリエ変換による時間領域への変換、ガードインターバルの付加、ベースバンドのデジタル信号の生成、アナログ信号への変換、直交変調、アップコンバート、余分な周波数成分の除去、電力の増幅等の処理を行う。送信処理部２１２で生成された信号は、アンテナ４１３から送信される。
【0047】
記憶部２２は、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部２２は、基地局２０の記憶手段として機能する。
【0048】
ネットワーク通信部２３は、他の装置（例えば、他の基地局２０）と通信するための通信インタフェースである。例えば、ネットワーク通信部２３は、ＮＩＣ（Network Interface Card）等のＬＡＮ（Local Area Network）インタフェースである。ネットワーク通信部２３は、ＵＳＢ（Universal Serial Bus）ホストコントローラ、ＵＳＢポート等により構成されるＵＳＢインタフェースであってもよい。また、ネットワーク通信部２３は、有線インタフェースであってもよいし、無線インタフェースであってもよい。ネットワーク通信部２３は、基地局２０のネットワーク通信手段として機能する。ネットワーク通信部２３は、制御部２４の制御にしたがって、他の装置と通信する。
【0049】
制御部２４は、基地局２０の各部を制御するコントローラ（Controller）である。制御部２４は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサにより実現される。例えば、制御部２４は、基地局２０内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ（Random Access Memory）等を作業領域として実行することにより実現される。なお、制御部２４は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。
【0050】
＜２．３．端末装置の構成例＞
端末装置４０は、基地局２０による制御に基づいて基地局２０と無線通信する通信装置である。
端末装置４０は、基地局２０による制御に基づいて基地局２０と無線通信する通信装置である。
【0051】
端末装置４０は、他の装置と無線通信する無線通信装置である。端末装置４０は、例えば、通信機能を有するセンサーやカメラデバイス、携帯電話、スマートデバイス（スマートフォン、又はタブレット）、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータである。端末装置４０は、無線を介してデータを送受信する機能を有するヘッドマウントディスプレイ（Head Mounted Display）やＶＲゴーグル等であってもよい。端末装置４０は、自動車やドローンなどの移動体であってもよい。
【0052】
例えば、端末装置４０は、基地局２０による制御に基づいて、又は自律的に、他の端末装置４０と無線通信する。その場合、端末装置４０は、ＰＣ５リンクにおいて、他の端末装置４０にサイドリンク信号を送信して、他の端末装置４０からサイドリンク信号を受信する。端末装置４０によるサイドリンク信号の送信及び受信をまとめてサイドリンク通信と記載する。端末装置４０は、サイドリンク通信を行う際、ＨＡＲＱ（Hybrid Automatic Repeat reQuest）等の自動再送技術を使用可能であってもよい。
【0053】
端末装置４０は、基地局２０とＮＯＭＡ（Non Orthogonal Multiple Access）通信が可能であってもよい。なお、端末装置４０は、他の端末装置４０との通信（サイドリンク）においてもＮＯＭＡ通信が可能であってもよい。また、端末装置４０は、他の通信装置（例えば、基地局２０、及び他の端末装置４０）とＬＰＷＡ（Low Power Wide Area）通信が可能であってもよい。その他、端末装置４０が使用する無線通信は、ミリ波又はテラヘルツ波を使った無線通信であってもよい。なお、端末装置４０が使用する無線通信（サイドリンク通信を含む）は、電波を使った無線通信であってもよいし、赤外線や可視光を使った無線通信（光無線）であってもよい。
【0054】
図４は、本開示の実施形態に係る端末装置４０の構成例を示す図である。端末装置４０は、基地局２０と無線通信する通信装置（無線システム）である。端末装置４０は、情報処理装置の一種である。
【0055】
端末装置４０は、信号処理部４１と、記憶部４２と、入出力部４４と、制御部４５と、を備える。なお、図４に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、端末装置４０の機能は、複数の物理的に分離された構成に分散して実装されてもよい。
【0056】
信号処理部４１は、他の通信装置（例えば、基地局２０及び他の端末装置４０）と無線通信する無線通信インタフェースである。信号処理部４１は、制御部４５の制御にしたがって動作する無線トランシーバである。信号処理部４１は１又は複数の無線アクセス方式に対応する。例えば、信号処理部４１は、ＮＲ及びＬＴＥの双方に対応する。信号処理部４１は、Ｗ－ＣＤＭＡやｃｄｍａ２０００等、他の無線アクセス方式に対応していてもよい。
【0057】
信号処理部４１は、受信処理部４１１と、送信処理部４１２と、アンテナ４１３と、を備える。信号処理部４１は、受信処理部４１１、送信処理部４１２、及びアンテナ４１３をそれぞれ複数備えていてもよい。なお、信号処理部４１が複数の無線アクセス方式に対応する場合、信号処理部４１の各部は、無線アクセス方式毎に個別に構成されうる。例えば、受信処理部４１１及び送信処理部４１２は、ＬＴＥとＮＲとで個別に構成されてもよい。受信処理部４１１、及び送信処理部４１２の構成は、基地局２０の受信処理部２１１、及び送信処理部２１２と同様である。
【0058】
記憶部４２は、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部４２は、端末装置４０の記憶手段として機能する。
【0059】
入出力部４４は、ユーザと情報をやりとりするためのユーザインタフェースである。例えば、入出力部４４は、キーボード、マウス、操作キー、タッチパネル等、ユーザが各種操作を行うための操作装置である。又は、入出力部４４は、液晶ディスプレイ（Liquid Crystal Display）、有機ＥＬディスプレイ（Organic Electroluminescence Display）等の表示装置である。入出力部４４は、スピーカー、ブザー等の音響装置であってもよい。また、入出力部４４は、ＬＥＤ（Light Emitting Diode）ランプ等の点灯装置であってもよい。入出力部４４は、端末装置４０の入出力手段（入力手段、出力手段、操作手段又は通知手段）として機能する。
【0060】
制御部４５は、端末装置４０の各部を制御するコントローラである。制御部４５は、例えば、ＣＰＵ、ＭＰＵ等のプロセッサにより実現される。例えば、制御部４５は、端末装置４０内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ等を作業領域として実行することにより実現される。なお、制御部４５は、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。
【0061】
＜＜３．ネットワークアーキテクチャ＞＞
以上、情報処理システム１の構成について説明したが、次に、本実施形態の情報処理システム１で適用され得るネットワークアーキテクチャについて説明する。以下、情報処理システム１のコアネットワークＣＮの一例として、第５世代移動体通信システム（５Ｇ）のアーキテクチャについて説明する。ここで説明する５Ｇのアーキテクチャは、例えば、3GPP TS23.501に記載されている。
以上、情報処理システム１の構成について説明したが、次に、本実施形態の情報処理システム１で適用され得るネットワークアーキテクチャについて説明する。以下、情報処理システム１のコアネットワークＣＮの一例として、第５世代移動体通信システム（５Ｇ）のアーキテクチャについて説明する。ここで説明する５Ｇのアーキテクチャは、例えば、3GPP TS23.501に記載されている。
【0062】
図５は、５Ｇのアーキテクチャの一例を示す図である。５ＧのコアネットワークＣＮは、５ＧＣ（5G Core）／ＮＧＣ（Next Generation Core）とも呼ばれる。以下、５ＧのコアネットワークＣＮを５ＧＣ／ＮＧＣとも称する。コアネットワークＣＮは、（Ｒ）ＡＮ２０を介してＵＥ（User Equipment）４０と接続する。ＵＥ４０は、例えば、端末装置４０である。
【0063】
（Ｒ）ＡＮ２０は、ＲＡＮ（Radio Access Network）との接続、およびＲＡＮ以外のＡＮ（Access Network）との接続を可能にする機能を有する。（Ｒ）ＡＮ２０は、ｇＮＢ、或いは、ｎｇ－ｅＮＢと呼ばれる基地局２０を含む。
【0064】
コアネットワークＣＮは、主にＵＥ４がネットワークへ接続する際の接続許可やセッション管理を行う。コアネットワークＣＮは、ユーザプレーン機能群４２０およびコントロールプレーン機能群４４０を含んで構成され得る。
【0065】
ユーザプレーン機能群４２０は、ＵＰＦ（User Plane Function）４２１およびＤＮ（Data Network）４２２を含む。ＵＰＦ４２１は、ユーザプレーン処理の機能を有する。ＵＰＦ４２１は、ユーザプレーンで扱われるデータのルーティング／転送機能を含む。ＤＮ４２２は、例えば、ＭＮＯ（Mobile Network Operator）等、オペレータ独自のサービスへの接続を提供するエンティティ、インターネット接続を提供する、あるいは、サードパーティーのサービスへの接続を提供する機能を有する。このように、ユーザプレーン機能群４２０は、コアネットワークＣＮとインターネットとの境界になるＧａｔｅｗａｙの役割を果たしている。
【0066】
コントロールプレーン機能群４４０は、ＡＭＦ（Access Management Function）４４１、ＳＭＦ（Session Management Function）４４２、ＡＵＳＦ（Authentication Server Function）４４３、ＮＳＳＦ（Network Slice Selection Function）４４４、ＮＥＦ（Network Exposure Function）４４５、ＮＲＦ（Network Repository Function）４４６、ＰＣＦ（Policy Control Function）４４７、ＵＤＭ（Unified Data Management）４４８、および、ＡＦ（Application Function）４４９を含む。
【0067】
ＡＭＦ４４１は、ＵＥ３０のレジストレーション処理や接続管理、モビリティ管理等の機能を有する。ＳＭＦ４４２は、セッション管理、ＵＥ４０のＩＰ割り当てと管理等の機能を有する。ＡＵＳＦ４４３は、認証機能を有する。ＮＳＳＦ４４４は、ネットワークスライスの選択にかかる機能を有する。ＮＥＦ４４５は、サードパーティー、ＡＦ４４９やエッジ・コンピューティング機能に対してネットワーク機能のケイパビリティやイベントを提供する機能を有する。
【0068】
ＮＲＦ４４６は、ネットワーク機能の発見やネットワーク機能のプロファイルを保持する機能を有する。ＰＣＦ４４７は、ポリシー制御の機能を有する。ＵＤＭ４４８は３ＧＰＰ ＡＫＡ認証情報の生成、ユーザＩＤの処理の機能を有する。ＡＦ４４９は、コアネットワークＣＮと相互に作用してサービスを提供する機能を有する。
【0069】
例えば、コントロールプレーン機能群４４０は、ＵＥ４０の加入者情報が格納されているＵＤＭ４４８から情報を取得して、当該ＵＥ４０がネットワークに接続してもよいか否かを判定する。コントロールプレーン機能群４４０は、かかる判定にＵＤＭ４４８から取得した情報に含まれるＵＥ４０の契約情報や暗号化のための鍵を使用する。また、コントロールプレーン機能群４４０は、暗号化のための鍵の生成等を行う。
【0070】
つまり、コントロールプレーン機能群４４０は、例えば、ＩＭＳＩ（International Mobile Subscriber Identity）と呼ばれる加入者番号に紐付いたＵＥ３０の情報がＵＤＭ４４８に格納されているか否かに応じてネットワークの接続可否を判定する。なお、ＩＭＳＩは、例えば、ＵＥ３０の中にあるＳＩＭ（Subscriber Identity Module）カードに格納される。
【0071】
ここで、Ｎａｍｆは、ＡＭＦ４４１が提供するサービスベースドインタフェース（Service-based interface）、Ｎｓｍｆは、ＳＭＦ４４２が提供するサービスベースドインタフェースである。また、Ｎｎｅｆは、ＮＥＦ４４５が提供するサービスベースドインタフェース、Ｎｐｃｆは、ＰＣＦ４４７が提供するサービスベースドインタフェースである。Ｎｕｄｍは、ＵＤＭ４４８が提供するサービスベースドインタフェース、Ｎａｆは、ＡＦ４４９が提供するサービスベースドインタフェースである。Ｎｎｒｆは、ＮＲＦ４４６が提供するサービスベースドインタフェース、Ｎｎｓｓｆは、ＮＳＳＦ４４４が提供するサービスベースドインタフェースである。Ｎａｕｓｆは、ＡＵＳＦ４４３が提供するサービスベースドインタフェースである。これらの各ＮＦ（Network Function）は、各サービスベースドインタフェースを介して他のＮＦと情報の交換を行う。
【0072】
また、図５に示すＮ１は、ＵＥ４０とＡＭＦ４４１間のリファレンスポイント（Reference Point）、Ｎ２は、ＲＡＮ／ＡＮ４３０とＡＭＦ４４１間のリファレンスポイントである。Ｎ４は、ＳＭＦ４４２とＵＰＦ４２１間のリファレンスポイントであり、これらの各ＮＦ（Network Function）間で相互に情報の交換が行われる。
【0073】
上述したように、コアネットワークＣＮでは、サービスベースドインタフェース（ＳＢＩ）と称するアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application Programming Interface）経由で情報の伝達、機能の制御を行うインタフェースが用意されている。
【0074】
ＡＰＩは、リソースを指定して、そのリソースに対して、ＧＥＴ（リソースの取得）、ＰＯＳＴ（リソースの作成、データの追加）、ＰＵＴ（リソースの作成、リソースの更新）、ＤＥＬＥＴＥ（リソースの削除）などを可能とする。かかる機能は、例えばＷｅｂに関する技術分野で一般的に使用される。
【0075】
例えば、図５に示すＡＭＦ４４１、ＳＭＦ４４２及びＵＤＭ４４８は、通信のセッションを確立する場合に、ＡＰＩを用いて互いに情報をやり取りする。従来、かかるＡＰＩをアプリケーション（例えば、ＡＦ４４９）が使用することは想定されていない。しかしながら、かかるＡＰＩをＡＦ４４９が使用することで、ＡＦ４４９が５Ｇセルラーネットワークの情報を使用することができ、アプリケーションの機能をより進化させることができると考えられる。
【0076】
なお、パブリックネットワークにおいて、ＡＭＦ４４１、ＳＭＦ４４２及びＵＤＭ４４８が使用するＡＰＩを、ＡＦ２８９が使用することは難しい。しかしながら、Non PublicなPrivate 5G Networkであれば、かかるＡＰＩをＡＦ２８９が使用できるように、例えばコアネットワークＣＮのＡＰＩの変更を含めてシステムを構成することが可能であると考える。
【0077】
（Private 5G）
ここで、Non PublicなPrivate 5G Networkの一例について説明する。図６は、本開示の実施形態に係るPrivate 5G Networkの構成例について説明するための図である。
ここで、Non PublicなPrivate 5G Networkの一例について説明する。図６は、本開示の実施形態に係るPrivate 5G Networkの構成例について説明するための図である。
【0078】
現在、多くのオフィスやホームでは、ＬＡＮ（Local Area Network）が配置されている。ＬＡＮは、例えば、イーサネットケーブルやルータなどで構成される。ＬＡＮは、ＩＳＰ（Internet Service Provider）のサービスを使ってインターネットと接続する。ＬＡＮとCloudとは、例えばVirtual Private Network（ＶＰＮ）を介して接続される。（ＶＰＮ）では、基本的にPrivate IP Addressでパケットがルーティングされる。ＶＰＮ外にパケットが送信される場合、当該パケットは、図示しないGateway routerを介してＶＰＮ外に送信される。
【0079】
このＬＡＮにセルラーの基地局２０を置いて運用するのがPrivate 5Gである。すなわち、Private 5Gでは、複数の基地局２０＿１～２０＿Ｍ（Ｍは自然数）及び複数のＵＥ４０＿１～４０＿Ｎ（Ｎは自然数）と、コアネットワークＣＮの一部の機能と、がＬＡＮに配置される。また、残りのコアネットワークＣＮの機能が、例えばインターネット回線のCloudのデータセンター内に配置される。
【0080】
図６の例では、ＵＰＦ４２１＿１～４２１＿ｐ（ｐはｐ≦Ｐである自然数）が、ＬＡＮに配置される。ＵＰＦ４２１＿ｐ＋１～４２１＿Ｐ（Ｐは自然数）が、インターネット回線のCloud上に配置される。なお、ここでは、ＵＰＦ４２１がＬＡＮ又は／及びCloud上に配置されるとしたが、これに代えて、ユーザプレーン機能群４２０がＬＡＮ又は／及びCloud上に配置されてもよい。
【0081】
また、コントロールプレーン機能群４４０（以下、ＣＰＦ４４０とも記載する）がインターネット回線のCloud上に配置される。
【0082】
このように、Private 5Gでは、基地局２０及びＵＥ４０は、ＬＡＮが配置されるオフィスや工場、個人宅内に配置される。一方、基地局２０を制御するコアネットワークＣＮは、ＬＡＮに配置されてもよく、インターネットの中のCloudのデータセンターに配置されてもよい。なお、図６は一例であり、ＣＰＦ４４０の少なくとも一部の機能がＬＡＮに配置されてもよい。また、ＵＰＦ４２１が全てＬＡＮに配置されてもよく、又は、全てCloudに配置されてもよい。
【0083】
基地局２０及びコアネットワークＣＮは、Private IP Addressが付与される。基地局２０及びコアネットワークＣＮは、互いに通信可能な環境に配置される。例えば、ＶＰＮなどの技術を使用することで、基地局２０及びコアネットワークＣＮは、互いがPrivate IP Addressを使用して通信が使用できるようになる。
【0084】
すなわち、基地局２０及びコアネットワークＣＮをつなぐネットワークは、Privateなネットワークとして扱うことができる。
【0085】
なお、ＬＡＮに配置されるＵＰＦ４２１＿１～４２１＿ｐは、ＣＰＦ４４０の立ち上げ時、又は、コアネットワークＣＮの運用開始時にＬＡＮに存在する。一方、Cloud上に配置されるＵＰＦ４２１＿ｐ＋１～４２１＿Ｐは、ＣＰＦ４４０の立ち上げ時、又は、コアネットワークＣＮの運用開始時にCloud上には存在しない。ＵＰＦ４２１＿ｐ＋１～４２１＿Ｐは、例えば、ＣＰＦ４４０の立ち上げ後、又は、コアネットワークＣＮの運用開始後に立ち上げる機能である。
【0086】
まとめると、Private 5Gは、Non PublicなNetworkであればよい。なお、実際には、ＵＥ４０、基地局２０、コアネットワークＣＮ、及び、クライアント機能を有するアプリケーションがＶＰＮの内側に配置される可能性が高い。ＵＥ４０及び基地局２０は、ＬＡＮに配置される。コアネットワークＣＮ及びアプリケーションは、ＬＡＮ及びインターネットのCloudのどちらに配置してもよい。
【0087】
（ＡＰＩ）
ここで、ＡＰＩの一例について説明する。図７は、本開示の実施形態に係るＡＰＩを説明するための図である。ここで説明するＡＰＩ（１）～ＡＰＩ（４）は、3GPP TS23.502に記載されている。
ここで、ＡＰＩの一例について説明する。図７は、本開示の実施形態に係るＡＰＩを説明するための図である。ここで説明するＡＰＩ（１）～ＡＰＩ（４）は、3GPP TS23.502に記載されている。
【0088】
上述したように、ＵＥ４０、基地局２０及びコアネットワークＣＮは、virtual LAN（ＶＰＮ５００）の中に配置される。基地局２０及びコアネットワークＣＮはＶＰＮ外のネットワーク（例えば、インターネット）とはGateway router（ルータ）５１０を介して通信を行う。
【0089】
ＡＰＩ（１）
ＡＰＩ（１）は、あらかじめ登録しておいたＵＥ４０が電源Ｏｆｆの状態から電源Ｏｎの状態に遷移してネットワークにａｔｔａｃｈしたこと、及び、そのときに取得したＩＰアドレスをＳＭＦ４４２が通知するＡＰＩである。
ＡＰＩ（１）は、あらかじめ登録しておいたＵＥ４０が電源Ｏｆｆの状態から電源Ｏｎの状態に遷移してネットワークにａｔｔａｃｈしたこと、及び、そのときに取得したＩＰアドレスをＳＭＦ４４２が通知するＡＰＩである。
【0090】
ＳＭＦ４４２は、ＡＰＩ（１）を使用して、登録しておいたＩＭＳＩのＵＥ４０がＩＰアドレスを取得したら、ＮＦに通知する。
【0091】
ＡＰＩ（２）
ＵＥ４０は、通信をしていない場合にIdleモードとなり、通信する場合にConnectedモードに遷移する。ＡＰＩ（２）は、ＵＥ３０がIdleモードであるかConnectedモードであるかをＡＭＦ４４１が通知するＡＰＩである。
ＵＥ４０は、通信をしていない場合にIdleモードとなり、通信する場合にConnectedモードに遷移する。ＡＰＩ（２）は、ＵＥ３０がIdleモードであるかConnectedモードであるかをＡＭＦ４４１が通知するＡＰＩである。
【0092】
ＡＰＩ（３）
ＡＰＩ（３）は、ＵＥ４０に対してIdleモードからConnectedモードに遷移するよう指示を出すためのメッセージ（Paging message）を基地局２０からブロードキャストするためのＡＰＩである。ＡＰＩ（３）は、例えば、IdleモードであるＵＥ４０宛てのパケットがＵＰＦ４２１に到着した時に使用され得る。
ＡＰＩ（３）は、ＵＥ４０に対してIdleモードからConnectedモードに遷移するよう指示を出すためのメッセージ（Paging message）を基地局２０からブロードキャストするためのＡＰＩである。ＡＰＩ（３）は、例えば、IdleモードであるＵＥ４０宛てのパケットがＵＰＦ４２１に到着した時に使用され得る。
【0093】
ＡＰＩ（４）
ＡＰＩ（４）は、ＵＥ４０の位置情報をＡＭＦ４４１が提供するＡＰＩである。ＡＭＦ４４１は、ＡＰＩ（４）を使用して、ＵＥ４０がどのTracking Areaにいるのか、どのCellに所属しているのか、また、特定の地域に入った時にそのことを知らせ得る。
ＡＰＩ（４）は、ＵＥ４０の位置情報をＡＭＦ４４１が提供するＡＰＩである。ＡＭＦ４４１は、ＡＰＩ（４）を使用して、ＵＥ４０がどのTracking Areaにいるのか、どのCellに所属しているのか、また、特定の地域に入った時にそのことを知らせ得る。
【0094】
なお、ＡＰＩ（４）を使用して得られる位置情報は、例えば、ＧＰＳ（Global Positioning System）によって得られる位置情報より精度が粗い情報である。例えば、ＧＰＳによって得られる位置情報は、経度緯度単位の情報であるのに対し、ＡＰＩ（４）を使用して得られる位置情報は、例えば、基地局２０のCell単位の情報である。
【0095】
例えば、ＧＰＳによって得られる位置情報は、当該ＧＰＳが搭載されるＵＥ４０のアプリケーションレイヤーの位置情報である。一方、ＡＰＩ（４）によって得られる位置情報は、ＡＭＦ４４１によって３ＧＰＰ ＲＡＮ１が提供する位置情報である。３ＧＰＰ ＲＡＮ１の位置情報を取得するためのＡＰＩ（ＡＰＩ（４））がＡＭＦ４４１に備えられている。
【0096】
なお、図５のＵＥ４０の一例は、本実施形態の端末装置４０である。ＲＡＮ／ＡＮ２０の一例は、本実施形態の基地局２０である。また、図２に示す情報処理装置１０が、例えばコアネットワークＣＮの各機能を有する装置の一例である。
【0097】
＜＜４．技術的特徴＞＞
＜４．１．ＲＡＭＮＦ＞
＜４．１．１．ＲＡＭＮＦの概要＞
ここで、従来の５Ｇでは、コアネットワークＣＮのＮＦ（Network Function）が5G Service Based InterfaceのＡＰＩを使用していた。本実施形態では、ＲＡＭＮＦ１００というプラットフォームを設けることで、サービスやアプリケーション、すなわちクライアント２００や端末装置４０が、コアネットワークＣＮの情報をより容易に得ることができるようにする。これにより、クライアント２００が提供するサービスがより進化することができるようになる。
＜４．１．ＲＡＭＮＦ＞
＜４．１．１．ＲＡＭＮＦの概要＞
ここで、従来の５Ｇでは、コアネットワークＣＮのＮＦ（Network Function）が5G Service Based InterfaceのＡＰＩを使用していた。本実施形態では、ＲＡＭＮＦ１００というプラットフォームを設けることで、サービスやアプリケーション、すなわちクライアント２００や端末装置４０が、コアネットワークＣＮの情報をより容易に得ることができるようにする。これにより、クライアント２００が提供するサービスがより進化することができるようになる。
【0098】
図８は、本開示の実施形態に係る情報処理システム１の一例を示す図である。図８に示すように、サービスのためのクライアント２００は、ＲＡＭＮＦ１００を介して、又は、直接ＵＰＦ４２１とユーザデータをやり取りする。また、クライアント２００は、ＲＡＭＮＦ１００を介してＣＰＦ４４０とやり取りする。ＲＡＭＮＦ１００は、ＳＢＩ ＡＰＩを介して、ＡＭＦ４４１及びＳＭＦ４４２とやり取りを行う。
【0099】
例えば、サービス側のクライアント２００は、ターゲットとする（すなわち通信を行う）端末装置４０と通信を行う前に、当該端末装置４０の状態をＲＡＭＮＦ１００に対して、問い合わせる。
【0100】
問い合わせの結果、端末装置４０がDe-registered（IP Addressが付与されていない状態）である場合、クライアント２００は、当該端末装置４０との通信を行わないようにする。これにより、クライアント２００は、不要なパケットの送信を差し控えることができる。
【0101】
また、クライアント２００は、端末装置４０がregistered（IP Addressが付与されている状態）であっても、端末装置４０がIdle状態の場合には、当該端末装置４０との通信を行わないようにし得る。
【0102】
Idle状態の端末装置４０にパケットが送信されると、当該端末装置４０に自動的にページングが送信され、端末装置４０が起きる（Connected状態に遷移する）ことになる。例えば、端末装置４０が低消費電力型の装置である場合、クライアント２００は、Idle状態の端末装置４０へのパケットの送信を差し控え、Connected状態の端末装置４０にパケットを送信するようにし得る。これにより、クライアント２００は、端末装置４０を不要に起動させないようにすることができ、端末装置４０の電力消費をより低減することができる。
【0103】
また、低消費電力型でない端末装置４０に対しては、クライアント２００は、Idle状態の端末装置４０にパケットを送信し得る。このとき、例えば、クライアント２００は、パケットを送る前に、ＲＡＭＮＦ１００を介して、予めＡＭＦ４４１のＡＰＩを使用して端末装置４０にページングメッセージを送っておくものとする。
【0104】
例えば、通常のセルラーシステムでは、端末装置４０をConnected状態に遷移させず、Idle状態のままでクライアント２００がパケットを送信する。この場合、当該パケットがＵＰＦ４２１に到着してから、端末装置４０をConnected状態に遷移させるためのページングメッセージが送信される。そのため、通常のセルラーシステムでは、Idle状態の端末装置４０にパケットを送る際、大きな遅延が発生していた。
【0105】
一方、本実施形態に係るクライアント２００は、上述したように、ＲＡＭＮＦ１００を使用することで、実際にパケットを端末装置４０に送信する前に、端末装置４０の状態をConnected状態に遷移させておくことができる。これにより、クライアント２００は、パケットの遅延時間をより低減させることができる。
【0106】
＜４．１．２．ＲＡＭＮＦの課題＞
サービスを提供するクライアント２００が、ネットワーク（例えば、コアネットワークＣＮ）のことをもっと詳しく知りたいという要求がさらに高まると考えられる。ネットワークとサービスとが協調（協力）することで、従来にないサービス品質（例えば、低遅延、低消費電力）が期待されるからである。
サービスを提供するクライアント２００が、ネットワーク（例えば、コアネットワークＣＮ）のことをもっと詳しく知りたいという要求がさらに高まると考えられる。ネットワークとサービスとが協調（協力）することで、従来にないサービス品質（例えば、低遅延、低消費電力）が期待されるからである。
【0107】
このように、ＲＡＭＮＦ１００がクライアント２００に対してネットワークの情報をより詳しく伝えるためには、ＲＡＭＮＦ１００に対してネットワークの情報をより詳しく収集することが求められる。
【0108】
ここで、ネットワークとは、例えば、以下の状態の少なくとも１つを含むものとする。
・基地局２０の状態
・コアネットワークＣＮの状態
・端末装置４０の状態
・トラフィックの状態
・基地局２０、コアネットワークＣＮ、及び、端末装置４０の少なくとも１つの能力の状態
・基地局２０の状態
・コアネットワークＣＮの状態
・端末装置４０の状態
・トラフィックの状態
・基地局２０、コアネットワークＣＮ、及び、端末装置４０の少なくとも１つの能力の状態
【0109】
これらの状態に関する情報をより詳しく収集するための仕組みが求められる。
【0110】
次に、ＲＡＭＮＦ１００は、クライアント２００へネットワークに関する情報を伝える伝え方をより効率的に行えるようにすることが求められ得る。例えば、ＲＡＭＮＦ１００が、複数の端末装置４０に関する情報をグループとしてクライアント２００に伝えることで、クライアント２００が、ネットワークの情報をより適切に把握できる場合がある。
【0111】
最後に、クライアント２００は、ネットワークの状態をより詳しく制御したい場合が考えられる。これは、ネットワークが、クライアント２００の望むように動作する方が、サービスにより有益な場合があると考えられるからである。
【0112】
上述したように、ＲＡＭＮＦ１００は、以下の機能をさらに有することが望まれる。
（１）ネットワークの情報をより詳しく収集する機能
（２）ネットワークの情報をよりわかりやすい形でクライアント２００に提供する機能 （３）クライアント２００がより詳しくネットワークを制御するための機能
（１）ネットワークの情報をより詳しく収集する機能
（２）ネットワークの情報をよりわかりやすい形でクライアント２００に提供する機能 （３）クライアント２００がより詳しくネットワークを制御するための機能
【0113】
以下では、これらの機能を実現するためのより詳細な課題及び解決手段について説明する。なお、（１）及び（２）は一体として動作し得るため、（１）及び（２）の課題及び解決手段は、同時に説明され得る。
【0114】
＜４．２．第１の実施形態＞
＜４．２．１．第１の課題＞
端末装置４０がConnectedモード（状態）からどれくらいの時間、通信がないとIdleモード（状態）に遷移するかクライアント２００が知ることができるようにすることが望まれる。すなわち、クライアント２００は、ネットワークの情報をきちんと把握できているとは言えなかった。換言すると、ＲＡＭＮＦ１００が、端末装置４０のRegistrationに関するRegistration情報をより詳細に収集できるようにすることが望まれる。
＜４．２．１．第１の課題＞
端末装置４０がConnectedモード（状態）からどれくらいの時間、通信がないとIdleモード（状態）に遷移するかクライアント２００が知ることができるようにすることが望まれる。すなわち、クライアント２００は、ネットワークの情報をきちんと把握できているとは言えなかった。換言すると、ＲＡＭＮＦ１００が、端末装置４０のRegistrationに関するRegistration情報をより詳細に収集できるようにすることが望まれる。
【0115】
５Ｇ ＳＢＩのＡＰＩ、例えばＡＭＦ４４１のページング（Idleモードの端末装置４０を呼び出す機能）のＡＰＩを使用することで、ＲＡＭＮＦ１００は、Idleモードの端末装置４０に対してConnectedモードに遷移するよう指示を出し得る。
【0116】
ここで、Idleモードとは、RRC Idle状態のことを意味し、端末装置４０の基地局２０との間の無線区間が切れている状態を意味する。また、Connectedモードとは、RRC Connected状態のことを意味し、端末装置４０の基地局２０との間の無線区間がつながっている状態を意味する。
【0117】
ＲＡＭＮＦ１００は、クライアント２００からの要求に応じてＡＭＦ４４１のＡＰＩを叩くことで、端末装置４０をConnectedモードに遷移させ得る。これにより、ＲＡＭＮＦ１００は、クライアント２００が通信したい相手の端末装置４０を、クライアント２００が通信を開始するタイミングでConnectedモードに予め遷移させておくことが可能である。
【0118】
端末装置４０が一度Connectedモードに遷移した後、どれくらいの時間が経つとIdleモードに遷移するか、ＲＡＭＮＦ１００が知ることができるようにすることが望まれる。すなわち、端末装置４０がConnectedモードからIdleモードに遷移するまでの時間を示すIdle遷移時間情報をＲＡＭＮＦ１００が知ることができるようにすることが望まれる。
【0119】
例えば、Idle遷移時間情報をＲＡＭＮＦ１００が知ることができない場合、ＲＡＭＮＦ１００は、クライアント２００がパケットを送る前に、端末装置４０のRegistrationに関するRegistration情報をＡＭＦ４４１のＡＰＩを用いて取得する必要がある。ここでRegistration情報は、端末装置４０の状態（例えば、ConnectedモードであるかIdleモードであるか）を示す情報を含む。
【0120】
端末装置４０がIdleモードである場合、ＲＡＭＮＦ１００は、ＡＭＦ４４１のＡＰＩを使用してページングの制御を行い、端末装置４０をConnectedモードに遷移させる必要がある。
【0121】
Idle遷移時間は、端末装置４０ごとに異なる。例えば、１秒程度でIdleモードに遷移する端末装置４０もあれば、６秒程度でIdleモードに遷移する端末装置４０もある。このようなIdle遷移時間が不確定な状態では、ＲＡＭＮＦ１００がクライアント２００に適切なネットワークの情報を伝えているとは言えない。
【0122】
このIdle遷移時間（Idle復帰時間）は、端末装置４０の能力に応じて、基地局２０が設定する。図９は、基地局２０によるIdle遷移時間の設定例を示すシーケンス図である。図９に示すシーケンスは、例えば、3GPP TS38.321のSection 5.19やTS38.331のSection 5.3.9に記載されている。
【0123】
図９に示すように、基地局２０は、端末装置４０の能力に応じて、端末装置４０がIdleモードに遷移する時間（Data inactivity timer）を設定する。このことから、Idle遷移時間は、端末装置４０及び基地局２０の両方に応じて設定される値と考えられる。しかしながら、ＲＡＭＮＦ１００が、基地局２０が行う設定に関する情報（例えば、Data inactivity timerに関する情報）を、全ての基地局２０から取得することは難しく、Idle遷移時間情報を取得することは容易なことではなかった。
【0124】
【0125】
図１０に示すように、ネットワーク側のＣＰＦ４４０（例えばＡＭＦ４４１）は、ＵＥ４０（端末装置４０）に対して、data inactive timer valueを設定する（ステップＳ１０１）。
【0126】
ＡＭＦ４４１は、ＵＥ４０のスペックや基地局２０のスペックを勘案した値（data inactive timer value）を設定する。data inactive timer valueは、例えば、１秒や６秒といった値である。
【0127】
この値の期間、ＵＥ４０と基地局２０との間で、アップリンク（ＵＬ）又は／及びダウンリンク（ＤＬ）のデータの送受信がない場合、ＵＥ４０は、ConnectedモードからIdleモードに遷移する。
【0128】
なお、ここでは、ＡＭＦ４４１がdata inactive timer valueの設定を行うとしたが、基地局２０が行うようにしてもよい。
【0129】
次に、ＲＡＭＮＦ１００は、ＡＭＦ４４１からＵＥ４０の状態（UE status）をＲＡＭＮＦ１００に通知するためのUE status登録をＡＭＦ４４１に対して行う（ステップＳ１０２）。
【0130】
ＲＡＭＮＦ１００は、ＡＭＦ４４１に対して、ＵＥ４０が、ConnectedモードからIdleモードに遷移した場合、あるいは、IdleモードからConnectedモードに遷移した場合など、ＵＥ４０の状態に変化があったときに知らせるよう、ＵＥ４０を登録しておく。この登録には、例えば、ＵＥ４０のＩＤ（例えば、ＳＵＰＩ（Subscription Permanent Identifier））が使用され得る。
【0131】
もし、ＵＥ４０がIdleモードである場合、ＲＡＭＮＦ１００は、ＡＭＦ４４１に、ページングリクエストを要求する（ステップＳ１０３）。ＲＡＭＮＦ１００は、ＡＭＦ４４１のＳＢＩのＡＰＩを使用することで、ＵＥ４０に対してページングを送信するようＡＭＦ４４１に要求する。
【0132】
ＣＰＦ４４０のＡＭＦ４４１とＵＥ４０との間でPaging procedureが実行される（ステップＳ１０４）。これにより、ＵＥ４０は、Connectedになる（ステップＳ１０５）。
【0133】
ＣＰＦ４４０のＡＭＦ４４１は、ＵＥ４０の状態（UE status）をＲＡＭＮＦ１００に通知する（ステップＳ１０５）。ここでは、ＡＭＦ４４１は、ＵＥ４０の状態がConnectedである旨の通知を行う。ステップＳ１０２で、ＲＡＭＮＦ１００がＡＭＦ４４１に対してUE status登録を行っているため、ＡＭＦ４４１は、ＲＡＭＮＦ１００にＵＥ４０の状態の変化（ここではIdleモードからConnectedモードへの遷移）を通知する。
【0134】
通知を受けたＲＡＭＮＦ１００は、タイマーを開始する（ステップＳ１０７）。すなわちＲＡＭＮＦ１００は、タイマーによる時刻の計測を開始する。
【0135】
図１０に示すように、ＵＬ／ＤＬデータの送信がないまま、data inactive timerの期限が切れる（expireする）と（ステップＳ１０８）、ＵＥ４０は、ConnectedモードからIdleモードに遷移する。
【0136】
Data inactive timerは、ＵＥ４０及びＡＭＦ４４１の両方が持っているため、ＡＭＦ４４１は、ＵＥ４０がIdleモードに遷移したことを知る。この場合、ＡＭＦ４４１は、ＵＥ４０の状態をＲＡＭＮＦ１００に通知する（ステップＳ１０９）。
【0137】
ここでは、ＡＭＦ４４１は、ＵＥ４０の状態がIdleである旨の通知を行う。ステップＳ１０２で、ＲＡＭＮＦ１００がＡＭＦ４４１に対してUE status登録を行っているため、ＡＭＦ４４１は、ＲＡＭＮＦ１００にＵＥ４０の状態の変化（ここではIdleモードからConnectedモードへの遷移）を通知する。
【0138】
通知を受けたＲＡＭＮＦ１００は、ステップＳ１０７で開始したタイマーを停止し、タイマーの計測時間に基づき、推定されたdata inactive timerを算出する（ステップＳ１１０）。ＲＡＭＮＦ１００は、例えば、タイマーの計測時間をＵＥ４０がIdle状態に遷移するまでのIdle遷移時間として推定する。
【0139】
このように、ＲＡＭＮＦ１００は、第１の情報（ここでは、ＵＥ４０のRegistration（例えばUE status）に関するRegistration情報）を取得する。ＲＡＭＮＦ１００は、取得した第１の情報に基づいてRegistrationの遷移間隔に関する情報（計測時間の一例、ここではIdle遷移時間情報）を算出する。
【0140】
なお、ここでは、ＡＭＦ４４１が、ＲＡＭＮＦ１００によるUE status登録に基づいてUE statusの通知を行うとしたが、ＲＡＭＮＦ１００がUE statusを取得する方法はこれに限定されない。
【0141】
例えば、ＲＡＭＮＦ１００が、定期的（例えば０．５秒おき）にＵＥ４０の状態を知るためのリクエストをＡＭＦ４４１に送信するようにしてもよい。この場合、ＲＡＭＮＦ１００は、ＡＭＦ４４１からの応答に含まれるＵＥ４０の状態の変化に基づき、Idle遷移時間情報を算出する。
【0142】
ＲＡＭＮＦ１００は、data inactive timerをクライアント２００に知らせる（ステップＳ１１１）。ＲＡＭＮＦ１００は、例えば、ステップＳ１１０で算出したIdle遷移時間をdata inactive timerとしてクライアント２００に通知する。
【0143】
クライアント２００は、ＵＥ４０がIdleに入ることを避けるための適切なアクセス間隔を知ることができる（ステップＳ１１２）。すなわち、継続してＵＥ４０にデータを送信する場合、クライアント２００は、Idle遷移時間より短い間隔でデータを送信すれば、ＵＥ４０がIdleモードに遷移する前のConnectedモードのうちにデータを送信することができる。
【0144】
ＵＥ４０がIdleモードに入ってしまうと、クライアント２００は、例えばページングを送信してＵＥ４０をIdleモードからConnectedモードに遷移させてから、データを送信する必要がある。そのため、ＵＥ４０がIdleモードに入ってしまうと、クライアント２００がデータを送信するまでに数１００ｍｓの遅延が発生する恐れがある。
【0145】
上述したように、Idle遷移時間を知ることで、クライアント２００は、ＵＥ４０がIdleモードに入る前にデータを送信することができ、データ送信に発生する遅延をより低減することができる。
【0146】
なお、図１０では、ＲＡＭＮＦ１００が、１回の動作（タイマーの計測を開始してから終了するまでの動作）でData inactive timerを計測しているが、動作の回数は２回以上であってもよい。すなわち、ＲＡＭＮＦ１００は、ステップＳ１０３からステップＳ１１０までの動作を（例えば１０回）繰り返し行ってIdle遷移時間（例えば、平均値）を算出するようにしてもよい。
【0147】
例えば、ＵＥ４０では、様々なアプリケーションが動作しており、当該アプリケーションで送受信が必要になった場合は、ＵＥ４０側からネットワークの無線区間の復帰（Connectedモードへの遷移）を行う。そこで、ＲＡＭＮＦ１００は、複数回の動作を繰り返し行って計測した時間に基づいてIdle遷移時間を算出することで、より正確なIdle遷移時間を算出することができる。
【0148】
ここで、特別なケースについて補足する。基地局２０の中には、ページングのＡＰＩによりＵＥ４０を起こすことができない基地局２０が存在することが考えられる。例えば、Private networkに使用される小型の基地局２０及び小型のコアネットワークＣＮは、その能力が簡略化される場合がある。この場合、ＡＭＦ４４１のページングのＡＰＩをＲＡＭＮＦ１００が叩いても、ＵＥ４０がIdleモードからConnectedモードに遷移しないことも考えられる。そこで、ＲＡＭＮＦ１００が、ページングによってＵＥ４０の状態が遷移するか否かを確認する確認処理を実行するようにする。
【0149】
【0150】
図１１に示すように、ＲＡＭＮＦ１００は、paging requestをＡＭＦ４４１に送信する（ステップＳ２０１）。ＲＡＭＮＦ１００は、例えば、ＵＥ４０がIdleモードである場合に、ＡＭＦ４４１にpaging requestを送信する。
【0151】
その後、ＲＡＭＮＦ１００は、ＵＥ４０の状態がIdleモードからConnectedモードに遷移したか否かを判定する（ステップＳ２０２）。ＲＡＭＮＦ１００は、ＡＭＦ４４１からの通知に基づき、ＵＥ４０の状態を判定する。
【0152】
ＵＥ４０の状態がIdleモードからConnectedモードに遷移した場合（ステップＳ２０２；Ｙｅｓ）、ＲＡＭＮＦ１００は、ＡＭＦ４４１のPaging用ＡＰＩは、ＲＡＭＮＦ１００から制御可能であるとし（ステップＳ２０３）、処理を終了する。
【0153】
一方、ＵＥ４０の状態がIdleモードからConnectedモードに遷移しなかった場合（ステップＳ２０２；Ｎｏ）、ＲＡＭＮＦ１００は、ＡＭＦ４４１のPaging用ＡＰＩは、ＲＡＭＮＦ１００から制御不可能であるとし（ステップＳ２０４）、処理を終了する。
【0154】
ＲＡＭＮＦ１００は、確認処理の結果、すなわち、ＡＭＦ４４１のPaging用ＡＰＩがＲＡＭＮＦ１００から制御可能であるか否かをクライアント２００に公開し得る。
【0155】
ここで、図１２は、本開示の第１の実施形態に係るＲＡＭＮＦ１００によるＵＥ４０状態のスケジューリングの一例について説明するための図である。上述したように、ＲＡＭＮＦ１００はIdle遷移時間を算出する。図１２では、ＲＡＭＮＦ１００は、時間ＴをIdle遷移時間（Data inactive time value）として算出（取得）する。
【0156】
ＲＡＭＮＦ１００は、Data inactive timerがexpireする前に、ＵＥ４０がIdleモードに入ることを避けるためにＵＥ４０に所定データ（Something data）を送信する。これにより、ＲＡＭＮＦ１００は、ＵＥ４０の状態を制御することができる。図１２の例では、ＲＡＭＮＦ１００は、所定の間隔でＵＥ４０がIdleモード及びConnectedモードを繰り返すようＵＥ４０の状態をスケジュールする。ＲＡＭＮＦ１００は、ＵＥ４０の状態のスケジュールをクライアント２００に通知する。
【0157】
このように、ＲＡＭＮＦ１００は、Idle遷移時間（計測情報の一例）に基づき、ＵＥ４０がIdle状態に遷移するタイミング以前に、ＵＥ４０と通信を行う。これにより、ＲＡＭＮＦ１００は、計画的にＵＥ４０がIdleモードである時間、及び、Connectedモードである時間を制御する。また、ＲＡＭＮＦ１００は、ＵＥ４０のRegistration（Idle／Connected）のスケジュール（計画）をクライアント２００に通知する。
【0158】
クライアント２００は、ＲＡＭＮＦ１００から通知されるスケジュールを用いることで、ＵＥ４０がConnectedモードである場合にＵＥ４０にアクセスすることができるようになる。これにより、クライアント２００は、より低遅延でＵＥ４０にアクセスすることができるようになる。
【0159】
このように、ＲＡＭＮＦ１００は、ＵＥ４０がIdleモードに遷移する前に、ネットワーク側から信号を送ることで、ＵＥ４０がIdleモードに遷移することを避けることができ、ＵＥ４０のRegistration状態を制御することができる。なお、このときネットワーク側から送られる信号はどんな信号でもよく、データ量が小さな信号であってもよい。このように、ネットワーク側が小さな信号を送信することで、ネットワークのトラフィックの増加を抑制することができる。
【0160】
なお、ＲＡＭＮＦ１００は、コアネットワークＣＮの新しいNetwork Function（ＮＦ）として定義されてもよく、ＲＡＭＮＦ１００の機能が既存のＡＭＦ４４１やＳＭＦ４４２、ＬＭＦ（Location Management Function）の中の新しい一機能として実現されてもよい。
【0161】
以上のように、ＲＡＭＮＦ１００は、ネットワークの情報であるＵＥ４０のIdle遷移時間を取得することができ、当該Idle遷移時間をクライアント２００に提供することができる。
【0162】
これにより、クライアント２００は、どれくらいの時間連続して信号をＵＥ４０に送信すれば、ＵＥ４０がIdleモードに遷移せずに、通信を継続することができるかを知ることができる。クライアント２００は、ＵＥ４０がIdleモードに遷移しないように、信号を送信し続けることができ、これにより、より低遅延の通信を実現することができる。
【0163】
ＲＡＭＮＦ１００は、クライアント２００に対して、ＵＥ４０のIdle／Connectedのスケジュールを伝える。このとき、ＲＡＭＮＦ１００は、Idle遷移時間を取得することで、スケジュールを守るために必要となるページング制御や、データを送信してＵＥ４０を起こす回数を減らすことができる。すなわち、ＲＡＭＮＦ１００は、Idle遷移時間に基づき、最小限のページング制御やデータの送信によって、ＵＥ４０のIdle／Connectedのスケジュールを守ることができる。
【0164】
これにより、ＲＡＭＮＦ１００は、ＵＥ４０及びコアネットワークＣＮの通信リソース及び計算機リソースを節約することができる。ＲＡＭＮＦ１００は、特に、ＵＥ４０の消費電力を抑えることができる。このように、ＲＡＭＮＦ１００は、ＵＥ４０のRegistration（Idle／Connected）のスケジュール管理を効率的に行うことができる。
【0165】
＜４．３．第２の実施形態＞
＜４．３．１．第２の課題＞
ＲＡＭＮＦ１００が、ＵＥ４０のネットワークの状況に関わる情報のうち、ＵＥ４０のアプリケーションレイヤーが把握する情報を正しくクライアント２００に提供できるようにすることが望まれる。また、ＲＡＭＮＦ１００が、これを他のネットワーク情報（例えば、ＳＢＩ経由で得られる第１の情報）と協調してクライアント２００に提供できるようにすることが望まれる。
＜４．３．１．第２の課題＞
ＲＡＭＮＦ１００が、ＵＥ４０のネットワークの状況に関わる情報のうち、ＵＥ４０のアプリケーションレイヤーが把握する情報を正しくクライアント２００に提供できるようにすることが望まれる。また、ＲＡＭＮＦ１００が、これを他のネットワーク情報（例えば、ＳＢＩ経由で得られる第１の情報）と協調してクライアント２００に提供できるようにすることが望まれる。
【0166】
上述したように、ＲＡＭＮＦ１００は、ＵＥ４０のネットワークに関する情報を、コアネットワークＣＮのＡＭＦ４４１やＳＭＦ４４２のＳＢＩのＡＰＩ経由で、ある程度取得することができる。
【0167】
このようにして取得されるＵＥ４０のネットワークに関する情報（第１の情報）には、例えば、ＵＥ４０がIdleモードであるかConnectedモードであるかを示す情報や、ＵＥ４０がregisteredであるかDe-registeredであるかを示す情報などが含まれる。
【0168】
ＲＡＭＮＦ１００が、ＵＥ４０のアプリケーションレイヤーでないと知ることができない振る舞いに関する情報（以下、端末関連情報とも記載する）を取得できるようにすることが望まれる。
【0169】
端末関連情報には、例えば、Registration（registered／De-registered）のスケジュールに関するスケジュール情報、ＵＥ４０の消費電力に関する電力情報、及び、ＵＥ４０の位置に関する位置情報の少なくとも１つが含まれる。なお、ここでの位置情報は、5Gのreference signalから推定したＵＥ４０の位置情報でなく、ＧＰＳや無線ＬＡＮ、Bluetooth（登録商標）の無線情報を用いた高精度の位置情報である。
【0170】
また、ＲＡＭＮＦ１００が、取得した端末関連情報をクライアント２００に提供できるようにすることが望まれる。このとき、さらに、ＲＡＭＮＦ１００が、ＡＭＦ４４１やＳＭＦ４４２経由で取得した第１の情報（ネットワーク情報）と、アプリケーションレイヤーが知る端末関連情報と、を融合し、１つの情報としてクライアント２００に提供できるようにすることが望まれる。
【0171】
ＲＡＭＮＦ１００が第１の情報及び端末関連情報を融合し、１つの情報としてクライアント２００に提供することで、サービスとネットワークとの融合が進み、価値ある新しいサービスを提供することができるようになる。そのため、このような第１の情報及び端末関連情報を融合した情報の提供が求められる。
【0172】
＜４．３．２．第２の課題の解決手段例＞
図１３は、本開示の第２の実施形態に係る情報処理システム１の一例を示す図である。図１３に示す情報処理システム１は、ＲＡＭＮＦ１００とＵＥ４０との間で端末関連情報のやり取りが行われる点を除き、図８に示す情報処理システム１と同じである。
図１３は、本開示の第２の実施形態に係る情報処理システム１の一例を示す図である。図１３に示す情報処理システム１は、ＲＡＭＮＦ１００とＵＥ４０との間で端末関連情報のやり取りが行われる点を除き、図８に示す情報処理システム１と同じである。
【0173】
図１３に示す情報処理システム１では、ＵＥ４０のアプリケーションレイヤーで保存される情報（端末関連情報）がＲＡＭＮＦ１００に通知され、同様の情報がＲＡＭＮＦ１００でも保存される。
【0174】
端末関連情報として、例えば、Registrationのスケジュールに関するスケジュール情報、ＵＥ４０の消費電力に関する電力情報、及び、ＵＥ４０の位置に関する位置情報の少なくとも１つが挙げられる。以下、端末関連情報の一例の詳細について説明する。
【0175】
［Registration（registered／De-registered）のスケジュール情報］
ＵＥ４０がネットワークから完全に離れることをdetachといい、その時には、ＵＥ４０にコアネットワークＣＮのＳＭＦ４４２が付与したIP Addressは無効になる。一方、ＵＥ４０がネットワークにattachすると、ＵＥ４０は、ＳＭＦ４４２からIP Addressを付与される。
ＵＥ４０がネットワークから完全に離れることをdetachといい、その時には、ＵＥ４０にコアネットワークＣＮのＳＭＦ４４２が付与したIP Addressは無効になる。一方、ＵＥ４０がネットワークにattachすると、ＵＥ４０は、ＳＭＦ４４２からIP Addressを付与される。
【0176】
その上で、ＵＥ４０がIdleモードからConnectedモードに遷移すると、無線区間がつながり、ＵＥ４０は通信が可能となる。つまり、ＵＥ４０がConnectedになるためには、registeredしていいることが前提となる。
【0177】
ＵＥ４０がRegisteredでIdleである場合、IP AddressはＵＥ４０がに付与されているが、ＵＥ４０は通信できないという状態である。ＵＥ４０がDe-registeredになった場合、ＵＥ４０にはIP Addressが付与されていないので、ＵＥ４０は、通信が完全にできない状態になっている。
【0178】
ここで、ＵＥ４０がＩｏＴ装置である場合など、ＵＥ４０が低消費電力装置である場合、バッテリー節約のためにＵＥ４０が必要な時だけregistered状態になることが考えられる。すなわち、ＵＥ４０が、一定周期でregistered状態とDe-registered状態とを繰り返すような計画（スケジュール）を、アプリケーションレイヤーで実施することが考えられる。この場合、ＵＥ４０は、スケジュールに従って、attach及びdetachつまり、registeredの状態とDe-registeredの状態を繰り返す。
【0179】
ＲＡＭＮＦ１００は、その周期をスケジュール情報として把握することで、クライアント２００に当該スケジュール情報を提供することができる。
【0180】
従来、クライアントサーバー（クライアント２００）に搭載されるアプリケーションと、ＵＥ４０に搭載されるアプリケーションとの間で、スケジュール情報のようなアプリケーションレベルの情報をやり取りすることは想定されていなかった。
【0181】
ＲＡＭＮＦ１００は、上述したように、ネットワークとサービスとの間を取り持つようなプラットフォームである。本実施形態では、ＲＡＭＮＦ１００を介してアプリケーションレベルの情報がクライアント２００に提供される。ＲＡＭＮＦ１００は、その他のネットワークの情報もあわせてアプリケーションレベルの情報をクライアント２００に提供することができる。
【0182】
［電力情報］
ＲＡＭＮＦ１００は、ＵＥ４０の端末関連情報（端末アプリケーション情報）として、スケジュール情報以外に、ＵＥ４０のバッテリーに関する電力情報をクライアント２００に提供し得る。ＵＥ４０の電力情報は、ＵＥ４０のConnected／Idleのスケジュール情報や、registered／De-registeredの情報（例えば、スケジュール情報）に影響を与えるからである。
ＲＡＭＮＦ１００は、ＵＥ４０の端末関連情報（端末アプリケーション情報）として、スケジュール情報以外に、ＵＥ４０のバッテリーに関する電力情報をクライアント２００に提供し得る。ＵＥ４０の電力情報は、ＵＥ４０のConnected／Idleのスケジュール情報や、registered／De-registeredの情報（例えば、スケジュール情報）に影響を与えるからである。
【0183】
なお、以下、Connected／Idleのスケジュール情報は、接続スケジュール情報とも記載される。また、registered／De-registeredのスケジュール情報は、登録スケジュール情報とも記載される。接続スケジュール情報及び登録スケジュール情報を区別しない場合は、単にスケジュール情報（Registrationのスケジュールに関するスケジュール情報）と記載する。
【0184】
上述したように、ＵＥ４０のRegistrationに関するスケジュールは、ＵＥ４０の電力消費に影響を与える。ＲＡＭＮＦ１００は、ＵＥ４０から電力情報の提供を受けるだけでなく、当該電力情報に基づいた登録スケジュールのリクエストを出し得る。このように、ＲＡＭＮＦ１００が登録スケジュールのリクエストを出すことで、ＲＡＭＮＦ１００（又はクライアント２００）は、ＵＥ４０の消費電力に対するケアーをよりきめ細やかに考慮してＵＥ４０にアクセスすることができるようになる。このように、電力情報は、ＵＥ４０に対するスケジュールの制御やアクセス時に役立てることができる。
【0185】
［位置情報］
端末関連情報に含まれる他の情報として、ＵＥ４０の位置に関する位置情報が挙げられる。ＵＥ４０は、位置情報をＲＡＭＮＦ１００経由でクライアント２００等に提供し得る。
端末関連情報に含まれる他の情報として、ＵＥ４０の位置に関する位置情報が挙げられる。ＵＥ４０は、位置情報をＲＡＭＮＦ１００経由でクライアント２００等に提供し得る。
【0186】
５Ｇでは、ＡＭＦ４４１がＵＥ４０の場所に関する情報を取得可能である。ＡＭＦ４４１は、取得した情報をＡＰＩで他のＮＦ等に提供可能である。しかしながら、このＡＭＦ４４１が取り扱うＵＥ４０の位置情報は、３ＧＰＰ（登録商標）のPositioningの技術を使用した位置情報である。当該位置情報は、例えば、基地局２０からの電波の到着時間や電波の到来方向推定などの情報に基づいて推定される情報である。
【0187】
このように、ＡＭＦ４４１が提供可能な位置情報は、３ＧＰＰの技術によって得られる位置情報である。
【0188】
一方、ＲＡＭＮＦ１００がＵＥ４０から取得する位置情報は、ＵＥ４０のアプリケーションレイヤーのＧＰＳが計測した位置情報や、Bluetooth（登録商標）やＷｉ-Ｆｉ（登録商標）の電波を使用した位置情報である。すなわち、当該位置情報は、ＵＥ４０に搭載される機器を用いて測定される情報である。当該位置情報は、ＡＭＦ４４１では収集されない位置情報である。ＡＭＦ４４１が把握しない当該位置情報は、ＡＭＦ４４１が収集する位置情報と比較して精度がよい場合がある。
【0189】
なお、以下、ＡＭＦ４４１が提供可能な位置情報をセルラー位置情報と記載し、ＲＡＭＮＦ１００がＵＥ４０から取得する位置情報を端末位置情報と記載して、これらの位置情報を区別する場合がある。
【0190】
以上のように、ＲＡＭＮＦ１００はＵＥ４０から種々の精度の高い端末関連情報を取得する。この端末関連情報は、ＲＡＭＮＦ１００が従来のＳＢＩ経由で収集した第１の情報と関連のあるものがある。例えば、端末関連情報に含まれる端末位置情報と、ＡＭＦ４４１から得られるregistered／De-registeredの状態に関する情報である。
【0191】
ＵＥ４０がある位置に到達したときにDe-registeredの状態からRegisteredの状態になる場合がある。例えば、工場の中で動いている自動搬送ロボットが、部品を所定の場所に運んでいて、所定の位置に到着したとする。例えば、自動搬送ロボットは、所定の位置に到着すると、ネットワークにattachしてregisteredの状態になり、通信ができるようになる。
【0192】
クライアント２００は、所定の位置に到着したときに自動搬送ロボットがregisteredの状態になるという情報を予め知っていることで、例えば、特定の場所に自動搬送ロボットが位置するときに通信が可能となることを前提にシステムを組むことができるようになる。
【0193】
なお、端末関連情報は、上述した登録スケジュール情報、電力情報及び位置情報に限定されない。端末関連情報として、例えば、以下の情報などが含まれ得る。
・監視カメラにデータが存在しているか否か
・工場で、故障を検出したかどうか
・工場の搬送ロボットが特定のエリアに入ったかどうか
・ドローンが特定のエリアに入ったかどうか
・ドローンの移動速度や、速度が一定値に達したか、速度が一定値以下になったか
・ドローンが他のドローンを検出したか
・自動搬送ロボットが、衝突回避のために停止したか
・地震、火事の検出
・特定のApplicationのセッションがスタートしたか否か
・applicationの予想する継続時間
・監視カメラにデータが存在しているか否か
・工場で、故障を検出したかどうか
・工場の搬送ロボットが特定のエリアに入ったかどうか
・ドローンが特定のエリアに入ったかどうか
・ドローンの移動速度や、速度が一定値に達したか、速度が一定値以下になったか
・ドローンが他のドローンを検出したか
・自動搬送ロボットが、衝突回避のために停止したか
・地震、火事の検出
・特定のApplicationのセッションがスタートしたか否か
・applicationの予想する継続時間
【0194】
このような、種々のアプリケーションに関する端末関連情報もＲＡＭＮＦ１００が収集し得る。ＲＡＭＮＦ１００は、これらの端末関連情報を収集し、ＲＡＭＮＦ１００が持つ第１の情報と組み合わせてクライアント２００に通知し得る。
【0195】
上述したように、本実施形態に係るＲＡＭＮＦ１００は、通常のコアネットワークＣＮが把握しない情報（端末関連情報）をＵＥ４０から取得し、ＳＢＩ経由で取得する第１の情報とあわせてクライアント２００に情報提供を行う。
【0196】
以下、端末関連情報ごとに、ＲＡＭＮＦ１００が行う情報提供処理の一例について説明する。
【0197】
［登録スケジュール情報の提供処理］
図１４は、本開示の第２の実施形態に係る登録スケジュール情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
図１４は、本開示の第２の実施形態に係る登録スケジュール情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
【0198】
図１４に示すように、ＲＡＭＮＦ１００は、registration schedule（登録スケジュール情報）のレポートの設定をＵＥ４０に通知する（ステップＳ３０１）。
【0199】
ＵＥ４０は、ＵＥ４０のregistrationに関するスケジュールを決定し（ステップＳ３０２）、registrationに関するスケジュールをＲＡＭＮＦ１００に知らせる（ステップＳ３０３）。
【0200】
ここで、図１５は、本開示の第２の実施形態に係る登録スケジュールの一例を示す図である。図１５に示すように、ＵＥ４０は、De-registered期間（秒）及びregistered期間（秒）を含む登録スケジュール情報をＲＡＭＮＦ１００に通知する。
【0201】
なお、図１５では、一定のDe-registered期間（秒）及び一定のregistered期間（秒）を交互に繰り返す登録スケジュールを示しているが、登録スケジュールはこれに限定されない。例えば、毎回De-registered期間（秒）及び／又はregistered期間（秒）が異なる登録スケジュールがＲＡＭＮＦ１００に通知されてもよい。
【0202】
図１４に戻る。ＲＡＭＮＦ１００は、クライアント２００にスケジュールを知らせる（ステップＳ３０４）。このスケジュールは、例えばＲＡＭＮＦ１００がステップＳ３０３でＵＥ４０から取得した登録スケジュールであり得る。
【0203】
また、ＲＡＭＮＦ１００は、Connected／IdleといったＵＥ４０の状態情報を含むスケジュールをクライアント２００に知らせる（ステップＳ３０５）。このスケジュールは、ＵＥ４０のregistered／De-registeredの状態、及び、Connected／Idleの状態を含むRegistrationに関するスケジュール情報であり得る。
【0204】
ここで、図１６は、本開示の第２の実施形態に係るRegistrationに関するスケジュールの一例を示す図である。図１６に示すように、ＲＡＭＮＦ１００は、De-registered期間（秒）及びregistered期間（秒）を含むスケジュール情報をＲＡＭＮＦ１００に通知する。このとき、ＲＡＭＮＦ１００は、registeredのうち、Connected期間（秒）及びIdle期間（秒）に関する情報を含めてスケジュール情報を通知する。
【0205】
このように、ＲＡＭＮＦ１００は、登録スケジュール情報と、接続スケジュール情報と、を統合し、１つのスケジュール情報として、クライアント２００に通知する。
【0206】
上述したように、ＵＥ４０が、ＲＡＭＮＦ１００にアクセスすることで、ＵＥ４０のアプリケーションとＲＡＭＮＦ１００のアプリケーションとの間で、ＵＥ４０の登録スケジュール情報が伝達（共有）される。
【0207】
ＲＡＭＮＦ１００は、コアネットワークＣＮのＮＦの一員として、ＵＥ４０のアプリケーションに関する端末関連情報と、ネットワークの状態に関する第１の情報と、を合わせて、クライアント２００に情報提供を行う。
【0208】
ＵＥ４０は、登録スケジュールに変更があった場合、ＲＡＭＮＦ１００にアクセスし、変更があったことを通知する。
【0209】
ここで、ＵＥ４０の登録スケジュール情報は、ＵＥ４０のアプリケーションが知る（管理する）端末関連情報である。ＵＥ４０の接続スケジュール情報は、ＲＡＭＮＦ１００が制御し得る情報、すなわち、ＲＡＭＮＦ１００が作成し得る情報である。ＲＡＭＮＦ１００は、ＵＥ４０の登録スケジュール情報を取得することで、登録スケジュール情報及び接続スケジュール情報を合わせてクライアント２００に情報提供を行い得る。
【0210】
つまり、クライアント２００は、どの時間でＵＥ４０がregisteredになっているか、さらにそのregisteredになっている期間で、どの時間がConnectedになっているかを把握することができる。従って、クライアント２００は、ＵＥ４０がConnectedになっている時間にアクセスすることが可能となる。
【0211】
クライアント２００が不用意にＵＥ４０にアクセスすると、ＵＥ４０がDe-registeredでIP Addressが付与されていない恐れがある。あるいは、ＵＥ４０がIdleの時にクライアント２００がアクセスすると、ＵＥ４０にpagingメッセージが送られてしまい、ＵＥ４０の消費電力が増大してしまう恐れがある。
【0212】
クライアント２００が、スケジュール情報に基づき、予め決まっているＵＥ４０のConnectedの時間に、ＵＥ４０にアクセスすることで、ＵＥ４０の電力消費を抑制することができる。
【0213】
なお、ＲＡＭＮＦ１００は、登録スケジュール情報の提供処理として、ＵＥ４０がRRC Connectedである時間（接続スケジュール情報）単独でクライアント２００に通知してもよい。例えば、ＲＡＭＮＦ１００が、接続スケジュール情報と、登録スケジュール情報と、をそれぞれクライアント２００に通知するようにしてもよい。この場合も、接続スケジュール情報及び登録スケジュール情報を対応付けて通知することで、クライアント２００は、ＵＥ４０から情報提供を受けた登録スケジュール情報と接続スケジュール情報とを統合したスケジュール情報として利用し得る。
【0214】
このように、ＲＡＭＮＦ１００が、接続スケジュール情報及び登録スケジュール情報をそれぞれに通知する場合も、接続スケジュール情報及び登録スケジュール情報を対応付けて通知することで、これらの情報を統合（融合）して通知しているものと言える。
【0215】
以上のように、ＲＡＭＮＦ１００は、接続スケジュール情報及び登録スケジュール情報を融合し、クライアント２００に統合したＵＥ４０のスケジュール情報として提供する。これにより、クライアント２００は、どの時間にＵＥ４０にアクセスすると、当該ＵＥ４０と通信することができるかを、前もって知ることができる。
【0216】
ＵＥ４０がＩｏＴ装置である場合、クライアント２００がアクセスするＵＥ４０の数が多くなることが考えられる。また、１つのＵＥ４０に多くのサービスのクライアント２００がアクセスすることが考えられる。このように、クライアント２００とＵＥ４０との通信が多く発生する可能性がある場合であっても、クライアント２００がConnectedであるＵＥ４０にアクセスできるようになることで、ＵＥ４０との間の無駄な通信を減らすことができる。これにより、ネットワーク及び／又はＵＥ４０の低消費電力化が図られる。
【0217】
なお、本開示の第２の実施形態において、ＵＥ４０とＲＡＭＮＦ１００との間の通信は、基地局２０を介してＵＥ４０とＲＡＭＮＦ１００とが直接通信を行い得る。あるいは、ＲＡＭＮＦ１００が、ＡＭＦ４４１等コアネットワークの他のＮＦを介してＳＢＩ経由でＵＥ４０と通信を行ってもよい。このように、ＲＡＭＮＦ１００及びＵＥ４０の通信経路は、特に限定されない。これは、他の実施形態においても同様である。
【0218】
［電力情報の提供処理］
図１７は、本開示の第２の実施形態に係る電力情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
図１７は、本開示の第２の実施形態に係る電力情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
【0219】
図１７に示すように、ＲＡＭＮＦ１００は、ＵＥ電力関連情報（電力情報）のレポートの設定をＵＥ４０に通知する（ステップＳ４０１）。ＵＥ４０は、ＵＥ４０のＵＥ電力関連情報をＲＡＭＮＦ１００に知らせる（ステップＳ４０２）。
【0220】
ＲＡＭＮＦ１００は、ＵＥ電力関連情報に応じてＵＥ４０のConnected／Idle率を決定する（ステップＳ４０３）。ＲＡＭＮＦ１００は、例えば、決定したConnected／Idle率に基づき、アクセス禁止期間ｉを含むUE statusをクライアント２００に知らせる（ステップＳ４０４）。
【0221】
ここで、図１８は、本開示の第２の実施形態に係る接続スケジュールの一例を示す図である。図１８に示すように、ＵＥ４０は、Connected期間（秒）及びIdle期間（秒）を含む接続スケジュール情報（A schedule UE state）をＲＡＭＮＦ１００に通知する。
【0222】
このように、ＲＡＭＮＦ１００は、例えば、UE statusとして、図１８に示す接続スケジュール情報を通知する。この場合、Idle期間では、クライアント２００は、ＵＥ４０へのアクセスが禁止される。すなわち、Idle期間が、アクセス禁止期間ｉに相当する。
【0223】
以上のように、電力情報の提供処理では、ＵＥ４０からＲＡＭＮＦ１００にアクセスすることで、ＵＥ４０のアプリケーション及びＲＡＭＮＦ１００のアプリケーションの間でＵＥ４０の電力情報が伝達（共有）される。
【0224】
【0225】
バッテリーのクリティカル度は、バッテリーの容量がどの程度であるかを示す情報である。例えば、バッテリー容量が小さいと、バッテリーのクリティカル度が「大」となり、バッテリー容量が大きいと、「中」となる。また、ＵＥ４０が電源につながっている場合は、バッテリー容量によらず、バッテリーのクリティカル度は「小」となる。
【0226】
バッテリーの残量は、バッテリーの残量がどの程度であるかを示す情報である。充電期待値は、次にいつ充電が見込めるかを示す情報であり、例えば、Ｘ時間後など充電が行われる時間などで表され得る。充電期待値は、例えば、前回の充電時間や、充電周期などに基づいてＵＥ４０によって決定され得る。
【0227】
なお、ここでは、バッテリーのクリティカル度、バッテリー残量が「大」、「中」、「小」の３段階で表されるとしたが、バッテリーのクリティカル度、バッテリー残量の表し方はこれに限定されない。例えば、バッテリーのクリティカル度、バッテリー残量が「大」、「小」の２段階で表されてもよく、４段階以上に分けて表されてもよい。また、バッテリーのクリティカル度、バッテリー残量がパーセンテージなど数値や割合で表されてもよい。
【0228】
例えば、このような電力情報を取得したＲＡＭＮＦ１００は、コアネットワークＣＮのＮＦの一員として、ＵＥ４０の端末関連情報（例えば電力情報）と、ネットワークの状態に関する第１の情報（例えばRegistration情報）を合わせて、クライアント２００に情報提供を行う。
【0229】
ＵＥ４０は、バッテリー残量に大きな変化があったときなど、電力情報に変化があった場合、ＲＡＭＮＦ１００にアクセスして最新の電力情報を通知する。
【0230】
以上のように、電力情報といった、ＵＥ４０のアプリケーションレイヤーが管理する情報をＲＡＭＮＦ１００が取得する。これにより、ＲＡＭＮＦ１００は、電力情報に応じてConnected／Idleの比率を決定することができる。また、ＲＡＭＮＦ１００は、決定した比率に基づき、ＵＥ４０のアクセス禁止期間を決定し、当該アクセス禁止期間を含む接続スケジュール情報をクライアント２００に提供することができる。
【0231】
クライアント２００は、アクセス禁止期間（例えば、Idle期間）を避けてＵＥ４０にアクセスすることができ、ＵＥ４０の低消費電力化を実現することができる。例えば、クライアントは、ＵＥ４０の端末関連情報（例えば電力情報）と、ネットワークの状態に関する第１の情報（例えばRegistration情報）に基づき、アクセスするＵＥ４０を決定する。これにより、クライアント２００は、例えば、バッテリー残量が少ないＵＥ４０を避けてアクセスすることができる。
【0232】
［端末位置情報の提供処理］
ＲＡＭＮＦ１００は、ＵＥ４０の端末位置情報を収集する。このとき、ＲＡＭＮＦ１００は、現在の端末位置情報、過去の端末関連情報、及び、未来の端末位置情報の少なくとも１つを収集し得る。
ＲＡＭＮＦ１００は、ＵＥ４０の端末位置情報を収集する。このとき、ＲＡＭＮＦ１００は、現在の端末位置情報、過去の端末関連情報、及び、未来の端末位置情報の少なくとも１つを収集し得る。
【0233】
【0234】
現在の端末位置情報は、今現在の端末位置情報である。ＲＡＭＮＦ１００は、現在の端末位置情報を収集し、クライアント２００に通知する。
【0235】
過去の端末位置情報は、過去の一定時間以内にＵＥ４０が通った位置を示す情報である。ＲＡＭＮＦ１００は、過去の端末位置情報を収集し、クライアント２００に通知する。このとき、ＲＡＭＮＦ１００は、過去の端末位置情報をグループ情報として通知し得る。グループ情報は、第３の実施形態で詳細が記載される。
【0236】
例えば、クライアント２００が、ある場所の情報を取得したいとする。このとき、現在時点において当該場所に位置するＵＥ４０がいない時に、クライアント２００は、過去に当該場所をとったＵＥ４０にアクセスすることで、当該場所の情報を取得し得る。このように、クライアント２００が過去に特定の場所を通ったＵＥ４０にアクセスしたい場合、過去の端末位置情報を使用する。
【0237】
未来の端末位置情報は、その場所ならば、ＵＥ４０が行くことが可能であるという場所を示す情報である。ＲＡＭＮＦ１００は、未来の端末位置情報を収集し、クライアント２００に通知する。
【0238】
未来の端末位置情報は、クライアント２００がその場所（例えば、特定の場所）に行けるＵＥ４０を探してアクセスするときに有用な情報である。
【0239】
このように、本実施形態に係るＲＡＭＮＦ１００は、過去、現在、及び、未来に分けて端末位置情報を収集し、クライアント２００に通知する。以下、過去、現在、及び、未来の端末位置情報ごとに提供処理の一例を説明する。
【0240】
（現在の端末位置情報の提供処理）
図２１は、本開示の第２の実施形態に係る現在の端末位置情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
図２１は、本開示の第２の実施形態に係る現在の端末位置情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
【0241】
ＵＥ４０は、例えばロケーションＩＤなどで表される端末位置情報（Location information）を更新する（ステップＳ５０１）。ＵＥ４０は、今現在の端末位置情報をＲＡＭＮＦ１００に通知することで、端末位置情報を更新する。
【0242】
ＲＡＭＮＦ１００は、ＵＥ４０のＩＤ（例えば、ＳＵＰＩ、ＩＭＳＩ（International Mobile Subscriber Identity））と、当該ＵＥ４０の位置を記憶する（ステップＳ５０２）。ＲＡＭＮＦ１００は、ＵＥ４０のＩＤと、ステップＳ５０１で取得した端末位置情報とを対応付けて記憶する。
【0243】
次に、ＲＡＭＮＦ１００は、クライアント２００からロケーションＩＤを含むリクエストを受け取ると（ステップＳ５０３）、ＵＥ４０のＩＤ（例えば、ＳＵＰＩ）と、当該ＵＥ４０のUE statusと、をクライアント２００に応答する（ステップＳ５０４）。すなわち、ＲＡＭＮＦ１００は、ロケーションＩＤに対応するエリアに位置するＵＥ４０のＩＤと、当該ＵＥ４０の状態と、を対応付けてクライアント２００に応答する。UE statusには、例えば、ＵＥ４０がregistered/deregisteredであるか、connected/idleであるかを示す情報や、UE statusスケジュール情報が含まれる。
【0244】
クライアント２００は、上述した情報（ＵＥ４０のＩＤと状態とが対応付けられた情報）に応じて、例えば、ＵＥ４０にアクセスするなど、自身の動作を決定する（ステップＳ５０５）。
【0245】
このように、現在の端末位置情報は、特定の場所にいるＵＥ４０にアクセスしたいクライアント２００にとって有用である。ＲＡＭＮＦ１００は、例えばクライアント２００が指定する特定のエリアに位置するＵＥ４０で、かつ、registeredされているＵＥ４０をクライアント２００に通知する。
【0246】
このように、ＲＡＭＮＦ１００は、現在の端末位置情報とネットワークに関する第１の情報とを融合してクライアント２００に情報提供し得る。クライアント２００は、特定のエリアにいるＵＥ４０にアクセス可能であるか否かを知ることができる。すなわち、クライアント２００は、ある特定のエリアにいるアクセス可能なＵＥ４０に関する情報を取得することができる。
【0247】
この特定のエリアは、例えば１０ｍ四方のようにメッシュ状のエリアである。このように、エリアのレゾル-ションは予め決められているものとする。
【0248】
ＵＥ４０は、場所を移動すると、registeredに遷移し、Connectedに選して、当該場所に移動したことをＲＡＭＮＦ１００に通知（更新）する。通知後、ＵＥ４０は、Idleに遷移するようにしてもよい。
【0249】
このように、ＵＥ４０は、ＲＡＭＮＦ１００に現在の端末位置情報を登録する。
【0250】
ここでの端末位置情報の登録は、ＵＥ４０のアプリケーションレイヤーの端末位置情報に基づいてアップデートされる点で、従来のTracking updateと異なる。従来のTracking updateで対象とするエリアは、複数の基地局２０で束ねられたエリアで、端末位置情報で対象とするエリアと比較して非常に広大なエリアである。また、従来のTracking updateは、５Ｇの無線技術を用いて行われる。
【0251】
一方、本実施形態に係る端末位置情報の登録は、上述したようにＵＥ４０のアプリケーションレイヤーの端末位置情報に基づいてアップデートされる。当該端末位置情報は、上述したように、例えば１０ｍ四方といった狭いエリアを対象とする情報である。
【0252】
また、本実施形態では、ＲＡＭＮＦ１００が直接、又は、ＳＢＩを経由して、ＵＥ４０から端末位置情報を取得する。この点において、コアネットワークＣＮから位置情報を取得するTracking updateとは異なる。
【0253】
上述したように、クライアント２００は、ＲＡＭＮＦ１００に対して特定の場所（エリア）にいるＵＥ４０について問い合わせを行う。このとき、クライアント２００は、ロケーションＩＤを用いて特定の場所を指定し得る。
【0254】
ＲＡＭＮＦ１００は、ロケーションＩＤに対応するエリアにいるＵＥ４０のＩＤ（ＩＭＳＩやＳＵＰＩなど）とUE status（例えば、ＵＥ４０がregisteredであるか否か）とを対応付けてクライアント２００に応答し得る。このとき、ＲＡＭＮＦ１００は、第１の実施形態で述べた接続スケジュール情報や登録スケジュール情報を含めてクライアント２００に応答するようにしてもよい。
【0255】
また、ロケーションＩＤに対応するエリアに複数のＵＥ４０が存在する場合、ＲＡＭＮＦ１００は、複数のＵＥ４０をグループ情報としてクライアント２００に応答するようにしてもよい。グループ情報は、第３の実施形態で詳細が記載される。
【0256】
（過去の端末位置情報の提供処理）
図２２は、本開示の第２の実施形態に係る過去の端末位置情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
図２２は、本開示の第２の実施形態に係る過去の端末位置情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
【0257】
ＵＥ４０は、例えばロケーションＩＤなどで表される過去の端末位置情報（Location information）を一定周期で更新する（ステップＳ６０１）。ＵＥ４０は、過去の端末位置情報を期間とあわせてＲＡＭＮＦ１００に通知することで、過去の端末位置情報を更新する。
【0258】
ＲＡＭＮＦ１００は、ＵＥ４０のＩＤ（例えば、ＳＵＰＩ、ＩＭＳＩ（International Mobile Subscriber Identity））と、当該ＵＥ４０の過去の位置情報を記憶する（ステップＳ６０２）。ＲＡＭＮＦ１００は、ＵＥ４０のＩＤと、ステップＳ５０１で取得した過去の端末位置情報とを対応付けて記憶する。
【0259】
次に、ＲＡＭＮＦ１００は、クライアント２００からロケーションＩＤを含むリクエストを受け取る（ステップＳ６０３）。ＲＡＭＮＦ１００は、ＵＥ４０のＩＤ（例えば、ＳＵＰＩ）と、当該ＵＥ４０のUE statusと、をクライアント２００に応答する、あるいは、ＵＥ４０がregisteredである場合、当該ＵＥ４０のＩＤ（例えば、ＳＵＰＩ）をクライアント２００に応答する（ステップＳ６０４）。
【0260】
すなわち、ＲＡＭＮＦ１００は、ロケーションＩＤに対応するエリアに過去に滞在していたＵＥ４０のＩＤと、当該ＵＥ４０の状態（UE status）と、を対応付けてクライアント２００に応答する。あるいは、ＲＡＭＮＦ１００は、registeredであるＵＥ４０のうち、ロケーションＩＤに対応するエリアに過去の所定期間滞在していたＵＥ４０のＩＤをクライアント２００に応答する。UE statusには、例えば、ＵＥ４０がregistered/deregisteredであるか、connected/idleであるかを示す情報や、UE statusスケジュール情報が含まれる。
【0261】
クライアント２００は、上述した情報（ＵＥ４０のＩＤと状態とが対応付けられた情報）に応じて、例えば、ＵＥ４０にアクセスするなど、自身の動作を決定する（ステップＳ６０５）。
【0262】
このように、過去の端末位置情報は、過去に特定の場所にいたＵＥ４０にアクセスしたいクライアント２００にとって有用である。特定の場所は、複数であっても、軌跡であってもよい。
【0263】
例えば、ＵＥ４０は、特定の場所に滞在（あるいは移動）している間に、当該場所（エリア）の温度や湿度など、当該場所に依存するエリア情報を蓄積しているものとする。過去の端末位置情報は、例えば、当該エリア情報を取得したいクライアント２００にとって有用である。
【0264】
このように、ＲＡＭＮＦ１００は、過去の端末位置情報とネットワークに関する第１の情報とを融合してクライアント２００に情報提供し得る。クライアント２００は、過去、特定のエリアにいたＵＥ４０にアクセス可能（registered又は／及びConnected）であるか否かを知ることができる。すなわち、クライアント２００は、ある特定のエリアにいたアクセス可能（registered又は／及びConnected）なＵＥ４０に関する情報を取得することができる。
【0265】
例えば、ＵＥ４０は、一定周期、例えば、１日毎や数時間ごとに、ＵＥ４０が滞在した（通ってきた）場所に関する情報を、過去の端末位置情報としてＲＡＭＮＦ１００に通知する。ＲＡＭＮＦ１００は、ＵＥ４０のＩＤとともに、その過去の端末位置情報を蓄積する。
【0266】
クライアント２００は、ＲＡＭＮＦ１００に対して、特定の場所を通過したことがあるＵＥ４０の情報について、ＲＡＭＮＦ１００に問い合わせをする。
【0267】
ＲＡＭＮＦ１００は、例えば、特定の場所を通過したことがあるＵＥ４０を特定する情報（ＵＥ４０のＩＤ）と、当該ＵＥ４０の状態（UE status）と、を対応付けて返信する。
【0268】
あるいは、例えば、ＲＡＭＮＦ１００が、特定の場所を通ったことがあるＵＥ４０の中から、今registeredであるＵＥ４０の情報をクライアント２００に返信するようにしてもよい。これにより、クライアント２００は、特定の場所に通ったことがあるＵＥ４０にアクセスし、エリア情報を取得することができる。
【0269】
あるいは、クライアント２００が、特定の場所を通過したＵＥ４０が、registeredになったら、当該ＵＥ４０に関する情報を通知（notify）してもらうように、ＲＡＭＮＦ１００に登録（register）しておくようにしてもよい。
【0270】
この場合、ＲＡＭＮＦ１００は、特定の場所を通ったことがあるＵＥ４０がregisteredになったことを検知すると、当該ＵＥ４０に関する情報をクライアント２００に通知する。あるいは、ＲＡＭＮＦ１００は、特定の場所を通ったことがあるＵＥ４０がregistered、かつ、Connectedになった場合に、クライアント２００に通知するようにしてもよい。
【0271】
なお、過去の端末位置情報のエリアは、現在の端末位置情報と同じエリアであっても異なっていてもよい。過去の端末位置情報の対象とするエリアが、ネットワーク側から取得可能な位置情報のエリアよりも狭い（精度が高い）エリアであればよい。
【0272】
（未来の端末位置情報の提供処理）
図２３は、本開示の第２の実施形態に係る未来の端末位置情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
図２３は、本開示の第２の実施形態に係る未来の端末位置情報の提供処理の流れの一例を示すシーケンス図である。なお、提供処理の一部を実行するＵＥ４０は、ＵＥ４０のアプリケーションであってもよい。
【0273】
図２３に示すように、クライアント２００は、ＵＥ４０がある場所に移動した場合に、その旨を通知するようＲＡＭＮＦ１００にリクエストする（ステップＳ７０１）。
【0274】
ＲＡＭＮＦ１００は、ＵＥ４０がある場所に移動した場合に、その旨を通知するようＵＥ４０にリクエストする（ステップＳ７０２）。
【0275】
リクエストで指定された場所にＵＥ４０が移動した場合、ＵＥ４０は、registered、かつ、RRC Connectedに遷移し、ロケーションＩＤ及びUE ID（例えばＳＵＰＩ）をＲＡＭＮＦ１００に送信する（ステップＳ７０３）。
【0276】
ＲＡＭＮＦ１００は、ＵＥ４０のＩＤ（例えば、ＳＵＰＩ、ＩＭＳＩ（International Mobile Subscriber Identity））と、当該ＵＥ４０の位置情報を記憶する（ステップＳ７０４）。
【0277】
ＲＡＭＮＦ１００は、ＵＥ４０のＩＤ（例えば、ＳＵＰＩ）と、当該ＵＥ４０のUE statusと、をクライアント２００に通知する（ステップＳ７０５）。UE statusには、例えば、ＵＥ４０がregistered/deregisteredであるか、connected/idleであるかを示す情報や、UE statusスケジュール情報が含まれる。
【0278】
クライアント２００は、上述した情報（ＵＥ４０のＩＤと状態とが対応付けられた情報）に応じて、例えば、ＵＥ４０にアクセスするなど、自身の動作を決定する（ステップＳ７０６）。
【0279】
また、リクエストで指定された場所から移動した場合、ＵＥ４０は、自身の状態をregisteredからDe-registeredに変更し得る（ステップＳ７０７）。
【0280】
このように、未来の端末位置情報は、ＵＥ４０が特定の場所に将来移動する可能性があることを示す情報である。クライアント２００は、当該場所にＵＥ４０が到着したときにＵＥ４０がregisteredになるように、ＵＥ４０に対してＲＡＭＮＦ１００経由でリクエストする。
【0281】
また、クライアント２００は、ＲＡＭＮＦ１００に対して、当該ＵＥ４０が特定の場所に移動した場合に通知するよう、登録（register）しておく。
【0282】
ＵＥ４０は、指定された特定の場所に移動した場合、registeredに遷移する。また、ＵＥ４０は、Connectedに遷移して、ＲＡＭＮＦ１００に当該場所に到着したことを通知する。なお、ＵＥ４０は、通知後、一定期間経過後にIdleに遷移し得る。
【0283】
ＲＡＭＮＦ１００は、ＵＥ４０からの通知を受けると、クライアント２００にＵＥ４０が指定の場所に到着したことを通知する。ＵＥ４０は、指定の場所に到着するとregisteredに遷移している。そのため、クライアント２００は、指定の場所に到着したＵＥ４０にアクセスしてエリア情報などの情報を取得することができる。例えば、クライアント２００は、ＵＥ４０に指定の場所の温度を送信してもらうなどの動作を行うことができる。
【0284】
ＵＥ４０は、指定の場所から移動した場合、registeredからDe-registeredに遷移する。ＲＡＭＮＦ１００は、ＵＥ４０がDe-registeredに遷移したことを検知することで、ＵＥ４０が指定の場所から移動したことを知り得る。ＲＡＭＮＦ１００は、ＵＥ４０が指定の場所から立ち去ったことをクライアント２００に通知するようにしてもよい。
【0285】
以上のように、本実施形態に係るＲＡＭＮＦ１００は、過去、現在及び未来の端末位置情報を収集する。ＡＭＦ４４１が提供するセルラー位置情報は、精度が粗く、過去や未来の情報が含まれない現在の位置情報である。この点で、本実施形態に係る端末位置情報は、セルラー位置情報と異なる。
【0286】
また、ＲＡＭＮＦ１００は、ネットワークに関する第１の情報（例えば、Registration情報）と、端末位置情報と、を融合してクライアント２００に提供する。これにより、クライアント２００は、ＵＥ４０の過去又は／及び現在の位置を知ることができ、さらに、ＵＥ４０にアクセス可能であるか否かを知ることができる。また、クライアント２００は、将来、特定の位置に来たＵＥ４０にアクセスすることができる。これにより、クライアント２００は、適切な時間にＵＥ４０にアクセスすることができるようになる。
【0287】
上述したように、ＲＡＭＮＦ１００は、ＵＥ４０のアプリケーションレイヤーレベルの端末関連情報と、ＳＢＩ ＡＰＩ経由のUE statusの情報（第１の情報の一例）と、を統合してクライアント２００に情報提供し得る。
【0288】
図２４は、本開示の第２の実施形態に係るＲＡＭＮＦ１００による情報の統合の一例を説明するための図である。
【0289】
ＲＡＭＮＦ１００は、ＵＥ４０から直接又はＳＢＩ経由で端末関連情報を取得する。また、ＲＡＭＮＦ１００は、ＳＢＩ ＡＰＩ経由でコアネットワークＣＮのＣＰＦ４４０からUE statusの情報を取得する。ＲＡＭＮＦ１００は、端末関連情報及びUE statusの情報を統合した情報をクライアント２００に知らせる。
【0290】
ＲＡＭＮＦ１００は、端末関連情報及びUE statusの情報を取得することで、例えば、ＵＥ４０の電力情報などに基づき、UE statusのスケジュールの計画などを変更することができる。また、ＲＡＭＮＦ１００は、端末関連情報及びUE statusの情報を取得することで、ＵＥ４０の端末位置情報やUE statusの情報から、ＵＥ４０にアクセスする時間などを最適化することができる。
【0291】
このように、ＲＡＭＮＦ１００は、ＵＥ４０のアプリケーションレイヤーの情報、及び、コアネットワークＣＮのネットワークに関する情報という、異なるレイヤーの情報を統合（融合）してクライアント２００に提供する。これにより、Serviceとnetworkの融合が進み、クライアント２００は、価値ある新しいサービスを提供することができるようになる。
【0292】
＜４．４．第３の実施形態＞
＜４．４．１．第３の課題＞
上述したように、ＲＡＭＮＦ１００は、ネットワークの情報、例えば、ＵＥ４０のネットワーク情報であるUE statusをクライアント２００に提供する。UE statusには、ＵＥ４０がregisteredであるかDe-registeredであるかを示す情報や、ConnectedであるかIdleであるかを示す情報が含まれる。
＜４．４．１．第３の課題＞
上述したように、ＲＡＭＮＦ１００は、ネットワークの情報、例えば、ＵＥ４０のネットワーク情報であるUE statusをクライアント２００に提供する。UE statusには、ＵＥ４０がregisteredであるかDe-registeredであるかを示す情報や、ConnectedであるかIdleであるかを示す情報が含まれる。
【0293】
ここで、上述した各実施形態では、クライアント２００は、ＲＡＭＮＦ１００に対して、１つのＵＥ４０ごとに問い合わせを行い、ＵＥ４０ごとにUE statusを取得していた。
【0294】
例えば、クライアント２００がターゲットとするＵＥ４０の数が多いと、クライアント２００とＲＡＭＮＦ１００との間のやり取りが増えてしまう。特に、クライアント２００がＩｏＴサービスを提供する場合、やり取りを行うＵＥ４０の数が多くなることが想定される。
【0295】
また、例えば、クライアント２００がターゲットとするＵＥ４０が明確に決まっていない場合、クライアント２００はＲＡＭＮＦ１００に問い合わせすることが難しい。これは、上述した各実施形態では、クライアント２００がＲＡＭＮＦ１００に問い合わせる時に、ＵＥ４０を特定するＩＤ（例えば、ＩＭＳＩやＳＵＰＩなど）が使用されるためである。なお、ＵＥ４０を特定するＩＤは、ＵＥ４０が特定できる情報であればよく、ＩＭＳＩやＳＵＰＩに限定されない。
【0296】
＜４．４．２．第３の課題の解決手段例＞
そこで、本実施形態では、ＲＡＭＮＦ１００は、クライアント２００が指定する条件に合致するＵＥ４０に関する情報を少なくとも１つ含むグループ情報（Group based network information）をクライアント２００に通知する。
そこで、本実施形態では、ＲＡＭＮＦ１００は、クライアント２００が指定する条件に合致するＵＥ４０に関する情報を少なくとも１つ含むグループ情報（Group based network information）をクライアント２００に通知する。
【0297】
クライアント２００が指定する条件には、ＵＥ４０のRegistrationの状態を指定するRegistration条件、ＵＥ４０の消費電力の状態を指定する電力条件、及び、ＵＥ４０の位置を指定する位置条件の少なくとも１つが含まれる。
【0298】
［Registration条件に応じた提供処理］
図２５は、本開示の第３の実施形態に係るRegistration条件に応じた提供処理の流れの一例を示すシーケンス図である。ここでは、ＲＡＭＮＦ１００は、クライアント２００からの指示に応じて、registered状態であるＵＥ４０のグループ情報を取得する。すなわち、ここでは、クライアント２００が指定するRegistration条件がregistered状態であるものとする。
図２５は、本開示の第３の実施形態に係るRegistration条件に応じた提供処理の流れの一例を示すシーケンス図である。ここでは、ＲＡＭＮＦ１００は、クライアント２００からの指示に応じて、registered状態であるＵＥ４０のグループ情報を取得する。すなわち、ここでは、クライアント２００が指定するRegistration条件がregistered状態であるものとする。
【0299】
図２５に示すように、ＵＥ４０は、ＣＰＦ４４０との間でAttach（registered）／Detach procedureを実行する（ステップＳ８０１）。なお、ここでは、１つのＵＥ４０によるAttach（registered）／Detach（De-registered） procedureについて示しているが、ＣＰＦ４４０は、複数のＵＥ４０とAttach（registered）／Detach procedureを実行し得る。
【0300】
ＲＡＭＮＦ１００は、ＣＰＦ４４０に対して、いくつかのＵＥ４０関してregistered／De-registeredのようなUE statusを問い合わせし（ステップＳ８０２）、ＣＰＦ４４０から応答を得る（ステップＳ８０３）。
【0301】
クライアント２００は、ＲＡＭＮＦ１００に対してregistered状態であるＵＥ４０のグループを問い合わせる（ステップＳ８０４）。
【0302】
ＲＡＭＮＦ１００は、クライアント２００に対してregistered状態であるＵＥ４０のグループの情報を返信する（ステップＳ８０５）。
【0303】
【0304】
図２６に示すように、グループ情報には、ＩＤと、UE IDと、が含まれる。UE IDは、例えばＳＵＰＩである。あるいは、UE IDは、ＩＭＳＩなどＵＥ４０を特定する情報であればよく、特に限定されない。
【0305】
ＲＡＭＮＦ１００は、registered状態である少なくとも１つのＵＥ４０に関する情報をグループ情報としてクライアント２００に知らせる。
【0306】
このように、ＲＡＭＮＦ１００は、クライアント２００からregisteredになっているＵＥ４０のＩＤのリクエストを受ける。
【0307】
ＲＡＭＮＦ１００は、registeredになっているＵＥ４０のUE IDをグループ情報としてクライアント２００に通知する。ＲＡＭＮＦ１００は、把握している全ての情報の中から、クライアント２００が指定するRegistration条件（ここでは、registered状態のＵＥ４０）に該当するＵＥ４０のグループを検出してグループ情報を作成する。
【0308】
なお、ＲＡＭＮＦ１００は、１つのPrivate Networkに少なくとも１つ配置され得る。ＲＡＭＮＦ１００は、１つのPrivate Networkに属する全てのＵＥ４０を母数とし、その中から条件に該当するＵＥ４０を見つけてクライアント２００に情報提供する。
【0309】
なお、Registration条件は、registeredであるかDe-registeredであるか否かに限定されない。例えば、クライアント２００は、Registration条件として、IdleであるかConnectedであるかを指定してグループ情報をＲＡＭＮＦ１００にリクエストし得る。
【0310】
図２７は、本開示の第３の実施形態に係るRegistration条件に応じた提供処理の流れの他の例を示すシーケンス図である。ここでは、ＲＡＭＮＦ１００は、クライアント２００からの指示に応じて、registered状態かつConnected状態であるＵＥ４０のグループ情報を取得する。すなわち、ここでは、クライアント２００が指定するRegistration条件がregistered状態かつConnected状態であるものとする。
【0311】
図２７に示すように、ＵＥ４０は、ＣＰＦ４４０との間でAttach（registered）／Detach procedureを実行する（ステップＳ９０１）。なお、ここでは、１つのＵＥ４０によるAttach（registered）／Detach（De-registered） procedureについて示しているが、ＣＰＦ４４０は、複数のＵＥ４０とAttach（registered）／Detach procedureを実行し得る。
【0312】
ＵＥ４０は、ＣＰＦ４４０との間でIdle／Connected procedureを実行する（ステップＳ９０２）。Idle／Connected procedureは、ＵＥ４０がＵＬ／ＤＬ通信を行ったり、スリープ状態に移行したりするための処理である。なお、ここでは、１つのＵＥ４０によるIdle／Connected procedureについて示しているが、ＣＰＦ４４０は、複数のＵＥ４０とIdle／Connected procedureを実行し得る。
【0313】
ＲＡＭＮＦ１００は、ＣＰＦ４４０に対して、いくつかのＵＥ４０関してregistered／De-registered及びIdle／ConnectedのようなUE statusを問い合わせし（ステップＳ９０３）、ＣＰＦ４４０から応答を得る（ステップＳ９０４）。
【0314】
クライアント２００は、ＲＡＭＮＦ１００に対してregistered状態であり、かつ、Connected状態であるＵＥ４０のグループを問い合わせる（ステップＳ９０５）。
【0315】
ＲＡＭＮＦ１００は、クライアント２００に対してregistered状態であり、かつ、Connected状態であるＵＥ４０のグループの情報を返信する（ステップＳ９０６）。
【0316】
このように、ＲＡＭＮＦ１００は、クライアント２００からregistered状態かつConnected状態になっているＵＥ４０のＩＤのリクエストを受ける。
【0317】
ＲＡＭＮＦ１００は、registered状態かつConnected状態になっているＵＥ４０のUE IDをグループ情報としてクライアント２００に通知する。ＲＡＭＮＦ１００は、把握している全ての情報の中から、クライアント２００が指定するRegistration条件（ここでは、registered状態かつConnected状態のＵＥ４０）に該当するＵＥ４０のグループを検出してグループ情報を作成する。
【0318】
なお、ＲＡＭＮＦ１００は、１つのPrivate Networkに少なくとも１つ配置され得る。ＲＡＭＮＦ１００は、１つのPrivate Networkに属する全てのＵＥ４０を母数とし、その中から条件に該当するＵＥ４０を見つけてクライアント２００に情報提供する。
【0319】
なお、Registration条件は、Connected状態であるＵＥ４０に限定されない。例えば、クライアント２００は、Idle状態のＵＥ４０を指定してグループ情報をＲＡＭＮＦ１００にリクエストし得る。
【0320】
［位置条件に応じた提供処理］
図２８は、本開示の第３の実施形態に係る位置条件に応じた提供処理の流れの一例を示すシーケンス図である。ここでは、ＲＡＭＮＦ１００は、クライアント２００からの指示に応じて、指定のエリアにいて、registered状態かつConnected状態であるＵＥ４０のグループ情報を取得する。すなわち、ここでは、クライアント２００が指定するRegistration条件がregistered状態かつConnected状態であり、位置条件が現在のセルラー位置情報であるものとする。
図２８は、本開示の第３の実施形態に係る位置条件に応じた提供処理の流れの一例を示すシーケンス図である。ここでは、ＲＡＭＮＦ１００は、クライアント２００からの指示に応じて、指定のエリアにいて、registered状態かつConnected状態であるＵＥ４０のグループ情報を取得する。すなわち、ここでは、クライアント２００が指定するRegistration条件がregistered状態かつConnected状態であり、位置条件が現在のセルラー位置情報であるものとする。
【0321】
図２８に示すように、ＵＥ４０は、ＣＰＦ４４０との間でAttach（registered）／Detach procedureを実行する（ステップＳ１００１）。なお、ここでは、１つのＵＥ４０によるAttach（registered）／Detach（De-registered） procedureについて示しているが、ＣＰＦ４４０は、複数のＵＥ４０とAttach（registered）／Detach procedureを実行し得る。
【0322】
ＵＥ４０は、ＣＰＦ４４０との間でIdle／Connected procedureを実行する（ステップＳ１００２）。Idle／Connected procedureは、ＵＥ４０がＵＬ／ＤＬ通信を行ったり、スリープ状態に移行したりするための処理である。なお、ここでは、１つのＵＥ４０によるIdle／Connected procedureについて示しているが、ＣＰＦ４４０は、複数のＵＥ４０とIdle／Connected procedureを実行し得る。
【0323】
ＵＥ４０は、ＣＰＦ４４０に対して、ＵＥ４０の位置に関連する情報（例えば、セルラー位置情報）の更新を行う（ステップＳ１００３）。なお、ここでは、１つのＵＥ４０による位置情報の更新について示しているが、ＣＰＦ４４０は、複数のＵＥ４０と位置情報の更新を実行し得る。
【0324】
ＲＡＭＮＦ１００は、ＣＰＦ４４０に対して、いくつかのＵＥ４０関してregistered／De-registered及びIdle／ConnectedのようなUE status、及び、ＵＥ４０の位置情報を問い合わせする（ステップＳ１００４）。ＲＡＭＮＦ１００は、ＣＰＦ４４０から応答を得る（ステップＳ１００５）。
【0325】
クライアント２００は、ＲＡＭＮＦ１００に対してregistered状態であり、かつ、Connected状態であり、特定の場所にいるＵＥ４０のグループを問い合わせる（ステップＳ１００６）。
【0326】
ＲＡＭＮＦ１００は、クライアント２００に対してregistered状態であり、かつ、Connected状態であり、特定の場所にいるＵＥ４０のグループの情報を返信する（ステップＳ１００７）。
【0327】
このように、ＲＡＭＮＦ１００は、クライアント２００から、特定のエリアにいて、registered状態かつConnected状態になっているＵＥ４０のＩＤのリクエストを受ける。
【0328】
ＲＡＭＮＦ１００は、特定のエリアにいて、registered状態かつConnected状態になっているＵＥ４０のUE IDをグループ情報としてクライアント２００に通知する。ＲＡＭＮＦ１００は、把握している全ての情報の中から、クライアント２００が指定するRegistration条件（ここでは、特定のエリアにいて、registered状態かつConnected状態のＵＥ４０）に該当するＵＥ４０のグループを検出してグループ情報を作成する。
【0329】
なお、ＲＡＭＮＦ１００は、１つのPrivate Networkに少なくとも１つ配置され得る。ＲＡＭＮＦ１００は、１つのPrivate Networkに属する全てのＵＥ４０を母数とし、その中から条件に該当するＵＥ４０を見つけてクライアント２００に情報提供する。
【0330】
なお、位置条件は、ＣＰＦ４４０が収集するセルラー位置情報を指定する条件に限定されない。例えば、クライアント２００は、ＲＡＭＮＦ１００が収集する端末位置情報を位置条件として指定してグループ情報をＲＡＭＮＦ１００にリクエストし得る。
【0331】
また、クライアント２００は、現在の位置情報だけでなく、例えば、過去や未来の端末位置情報を位置条件として指定してグループ情報をＲＡＭＮＦ１００にリクエストし得る。
【0332】
例えば、クライアント２００は、特定のＵＥ４０が特定の場所に入ったときに通知するようＲＡＭＮＦ１００に登録を行い得る。さらに、本実施形態では、クライアント２００は、ＵＥ４０を特定せずに、特定の場所にＵＥ４０が入ったことを条件として、特定の場所に入ったＵＥ４０に関する情報（例えば、UE ID）を通知するようＲＡＭＮＦ１００に登録を行い得る。
【0333】
［電力条件に応じた提供処理］
図２９は、本開示の第３の実施形態に係る電力条件に応じた提供処理の流れの一例を示すシーケンス図である。ここでは、ＲＡＭＮＦ１００は、クライアント２００からの指示に応じて、電池の残量が一定以上であり、指定のエリアにいて、registered状態かつConnected状態であるＵＥ４０のグループ情報を取得する。すなわち、ここでは、クライアント２００が指定するRegistration条件がregistered状態かつConnected状態であるとする。位置条件が現在のセルラー位置情報であるものとする。電力条件が、電池残量が一定以上であるものとする。
図２９は、本開示の第３の実施形態に係る電力条件に応じた提供処理の流れの一例を示すシーケンス図である。ここでは、ＲＡＭＮＦ１００は、クライアント２００からの指示に応じて、電池の残量が一定以上であり、指定のエリアにいて、registered状態かつConnected状態であるＵＥ４０のグループ情報を取得する。すなわち、ここでは、クライアント２００が指定するRegistration条件がregistered状態かつConnected状態であるとする。位置条件が現在のセルラー位置情報であるものとする。電力条件が、電池残量が一定以上であるものとする。
【0334】
図２９に示すように、ＵＥ４０は、ＣＰＦ４４０との間でAttach（registered）／Detach procedureを実行する（ステップＳ１１０１）。なお、ここでは、１つのＵＥ４０によるAttach（registered）／Detach（De-registered） procedureについて示しているが、ＣＰＦ４４０は、複数のＵＥ４０とAttach（registered）／Detach procedureを実行し得る。
【0335】
ＵＥ４０は、ＣＰＦ４４０との間でIdle／Connected procedureを実行する（ステップＳ１１０２）。Idle／Connected procedureは、ＵＥ４０がＵＬ／ＤＬ通信を行ったり、スリープ状態に移行したりするための処理である。なお、ここでは、１つのＵＥ４０によるIdle／Connected procedureについて示しているが、ＣＰＦ４４０は、複数のＵＥ４０とIdle／Connected procedureを実行し得る。
【0336】
ＵＥ４０は、ＣＰＦ４４０に対して、ＵＥ４０の位置に関連する情報（例えば、セルラー位置情報）の更新を行う（ステップＳ１１０３）。なお、ここでは、１つのＵＥ４０による位置情報の更新について示しているが、ＣＰＦ４４０は、複数のＵＥ４０と位置情報の更新を実行し得る。
【0337】
ＵＥ４０は、ＣＰＦ４４０に対して、ＵＥ４０の電力に関連するＵＥ４０の情報（例えば、電力情報）を通知する（ステップＳ１１０４）。なお、ここでは、１つのＵＥ４０による電力情報の通知について示しているが、ＣＰＦ４４０は、複数のＵＥ４０から電力情報の通知を受け付け得る。
【0338】
ＲＡＭＮＦ１００は、ＣＰＦ４４０に対して、いくつかのＵＥ４０関してregistered／De-registered及びIdle／ConnectedのようなUE status、ＵＥ４０の位置情報、及び、電力情報を問い合わせする（ステップＳ１１０５）。ＲＡＭＮＦ１００は、ＣＰＦ４４０から応答を得る（ステップＳ１１０６）。
【0339】
クライアント２００は、ＲＡＭＮＦ１００に対してregistered状態であり、かつ、Connected状態であり、特定の場所にいて、所定の電力情報であるＵＥ４０のグループを問い合わせる（ステップＳ１１０７）。例えば、クライアント２００は、ＲＡＭＮＦ１００に対してregistered状態であり、かつ、Connected状態であり、特定の場所にいて、電池残量が一定値以上であるＵＥ４０のグループを問い合わせる。
【0340】
ＲＡＭＮＦ１００は、クライアント２００に対してregistered状態であり、かつ、Connected状態であり、特定の場所にいて、所定の電力情報であるＵＥ４０のグループの情報を返信する（ステップＳ１１０８）。例えば、クライアント２００は、ＲＡＭＮＦ１００に対してregistered状態であり、かつ、Connected状態であり、特定の場所にいて、電池残量が一定値以上であるＵＥ４０のグループ情報を返信する。
【0341】
このように、ＲＡＭＮＦ１００は、クライアント２００から、特定の電力状態（例えば、電池残量が一定以上）であり、特定のエリアにいて、registered状態かつConnected状態になっているＵＥ４０のＩＤのリクエストを受ける。
【0342】
ＲＡＭＮＦ１００は、特定の電力状態であり、特定のエリアにいて、registered状態かつConnected状態になっているＵＥ４０のUE IDをグループ情報としてクライアント２００に通知する。ＲＡＭＮＦ１００は、把握している全ての情報の中から、クライアント２００が指定するRegistration条件（ここでは、特定のエリアにいて、特定の電力状態であり、registered状態かつConnected状態のＵＥ４０）に該当するＵＥ４０のグループを検出してグループ情報を作成する。
【0343】
なお、ＲＡＭＮＦ１００は、１つのPrivate Networkに少なくとも１つ配置され得る。ＲＡＭＮＦ１００は、１つのPrivate Networkに属する全てのＵＥ４０を母数とし、その中から条件に該当するＵＥ４０を見つけてクライアント２００に情報提供する。
【0344】
以上のように、本実施形態に係るＲＡＭＮＦ１００は、クライアント２００が指定する条件を満足する少なくとも１つのＵＥ４０をグループ情報としてクライアント２００に提供する。これにより、クライアント２００は、条件を満足するＵＥ４０の候補を、少なくとも１つ以上受け取ることができる。クライアント２００は、グループ情報に含まれるＵＥ４０全てにアクセスしてもよく、その中からＵＥ４０を選択してアクセスしてもよい。
【0345】
クライアント２００は、グループとして、ネットワーク情報（第１の情報）の１つであるＵＥ４０の状態に関する情報（例えば、Registration情報）を取得することができる。これにより、ＵＥ４０を指定して情報を取得する場合と比較して、クライアント２００及びＲＡＭＮＦ１００の間のシグナリングがグループ情報に含まれるＵＥ４０の数に応じて低減される。
これにより、クライアント２００の動作が簡略化されるとともに、クライアント２００は、ネットワークの輻湊状態を回避することができる。
これにより、クライアント２００の動作が簡略化されるとともに、クライアント２００は、ネットワークの輻湊状態を回避することができる。
【0346】
＜＜５．適用例＞＞
次に、実施形態に係る情報処理システム１が適用される事例について説明する。なお、以下では、第３の実施形態に係る情報処理システム１の適用例について説明するが、第１、第２の実施形態も同様に各事例に適用され得る。
次に、実施形態に係る情報処理システム１が適用される事例について説明する。なお、以下では、第３の実施形態に係る情報処理システム１の適用例について説明するが、第１、第２の実施形態も同様に各事例に適用され得る。
【0347】
＜５．１．第１の適用例＞
図３０は、本開示の第１の適用例に係る情報処理システム１の一例を示す図である。図３０では、情報処理システム１が工場に適用される場合について示している。ここでは、ＵＥ４０は、工場内に配置されるカメラである。
図３０は、本開示の第１の適用例に係る情報処理システム１の一例を示す図である。図３０では、情報処理システム１が工場に適用される場合について示している。ここでは、ＵＥ４０は、工場内に配置されるカメラである。
【0348】
図３０では、カメラ４０Ａ１～４０Ａ３の３台のカメラが配置される場合について示しているが、カメラの台数は３台に限定されず、２台以下であっても、４台以上であってもよい。
【0349】
例えば、工場の管理サービスを提供するクライアント２００は、工場内の特定のエリアに配置され（位置条件）、かつ、registered状態である（Registration条件）カメラのグループ情報を知るために、ＲＡＭＮＦ１００に問い合わせを行う。
【0350】
ＲＡＭＮＦ１００は、例えば、カメラ４０Ａ１及び４０Ａ２が、クライアント２００が指定する条件を満足するＵＥ４０であるとする。ＲＡＭＮＦ１００は、当該カメラ４０Ａ１及び４０Ａ２を特定するＩＤ（例えば、UE ID）を含むグループ情報をクライアント２００に応答する。
【0351】
グループ情報を受け取ったクライアント２００は、例えば、カメラ４０Ａ２にアクセスし、カメラ４０Ａ２が撮影した情報（又は、現在、撮影している画像）をアップロードするようカメラ４０Ａ２に依頼する。
【0352】
このように、クライアント２００は、条件を指定することで、ＲＡＭＮＦ１００から当該条件を満たすＵＥ４０に関するグループ情報を取得することができる。
【0353】
＜５．２．第２の適用例＞
図３１は、本開示の第２の適用例に係る情報処理システム１の一例を示す図である。図３１では、情報処理システム１がドローンシステムに適用される場合について示している。ここでは、ＵＥ４０は、ドローンである。
図３１は、本開示の第２の適用例に係る情報処理システム１の一例を示す図である。図３１では、情報処理システム１がドローンシステムに適用される場合について示している。ここでは、ＵＥ４０は、ドローンである。
【0354】
図３１では、ドローン４０Ｂ１～４０Ｂ４の４台のドローンが飛行している場合について示しているが、ドローンの台数は４台に限定されず、３台以下であっても、５台以上であってもよい。例えば、ドローンの台数は、数百台であってもよい。
【0355】
例えば、ドローンの管理サービスを提供するクライアント２００は、特定のエリアを通過して撮影を行ったドローンのグループ情報を知るために、ＲＡＭＮＦ１００に問い合わせを行う。このとき、クライアント２００は、ドローンにすぐアクセスするために、現在registered状態であるドローンを指定してグループ情報の問い合わせを行う。すなわち、クライアント２００は、過去の端末位置情報（過去に特定のエリアを通過したこと）を位置条件とし、現在registered状態であることをRegistration条件として、ＲＡＭＮＦ１００に問い合わせを行う。
【0356】
ＲＡＭＮＦ１００は、例えば、ドローン４０Ｂ２及び４０Ｂ４が、クライアント２００が指定する条件を満足するＵＥ４０であるとする。ＲＡＭＮＦ１００は、当該ドローン４０Ｂ２及び４０Ｂ４を特定するＩＤ（例えば、UE ID）を含むグループ情報をクライアント２００に応答する。
【0357】
グループ情報を受け取ったクライアント２００は、例えば、ドローン４０Ｂ２にアクセスし、ドローン４０Ｂ２が特定のエリアで撮影した情報をアップロードするようドローン４０Ｂ２に依頼する。
【0358】
このように、クライアント２００は、条件を指定することで、ＲＡＭＮＦ１００から当該条件を満たすＵＥ４０に関するグループ情報を取得することができる。このとき、クライアント２００は、過去の端末位置情報を指定して、グループ情報を取得することができる。
【0359】
＜５．３．第３の適用例＞
情報処理システム１が温度測定システムに適用される場合について示している。ここでは、ＵＥ４０は、地域に配置される温度センサーである。温度センサーは、地域に多数配置され得る。また、温度センサーが配置される地域が複数あり得る。このような温度センサーは、電池交換が難しい場合も多く、なるべく電力消費を抑えることが望まれる。
情報処理システム１が温度測定システムに適用される場合について示している。ここでは、ＵＥ４０は、地域に配置される温度センサーである。温度センサーは、地域に多数配置され得る。また、温度センサーが配置される地域が複数あり得る。このような温度センサーは、電池交換が難しい場合も多く、なるべく電力消費を抑えることが望まれる。
【0360】
そこで、温度センサーの管理を行うクライアント２００は、RRC Connected状態である温度センサーのグループ情報を知るために、ＲＡＭＮＦ１００に問い合わせを行う。このとき、クライアント２００は、地域を指定して問い合わせを行ってもよい。
【0361】
ＲＡＭＮＦ１００は、条件を満たす（RRC Connected状態である）温度センサーを特定するＩＤ（例えば、UE ID）を含むグループ情報をクライアント２００に応答する。
【0362】
グループ情報を受け取ったクライアント２００は、グループ情報に含まれる温度センサーのうち、例えば、位置が分散するように、所定個（例えば、５個）の温度センサーを選択する。クライアント２００は、選択した温度センサーにアクセスし、温度情報を取得する。
【0363】
これにより、クライアント２００は、RRC Connected状態である温度センサーにアクセスすることができるようになり、わざわざRRC Idle状態である温度センサーを起こさなくてもよくなる。また、クライアント２００は、RRC Connected状態である温度センサーのうち、所望の位置の温度センサーにアクセスすることができ、所望の温度情報を取得することができる。
【0364】
＜＜６．その他の実施形態＞＞
上述の各実施形態及び各適用例は一例を示したものであり、種々の変更及び応用が可能である。
上述の各実施形態及び各適用例は一例を示したものであり、種々の変更及び応用が可能である。
【0365】
例えば、上述の実施形態の情報処理装置１０、基地局２０及び端末装置４０を制御する制御装置は、専用のコンピュータシステムにより実現してもよいし、汎用のコンピュータシステムによって実現してもよい。
【0366】
例えば、上述の動作を実行するための通信プログラムを、光ディスク、半導体メモリ、磁気テープ、フレキシブルディスク等のコンピュータ読み取り可能な記録媒体に格納して配布する。そして、例えば、該プログラムをコンピュータにインストールし、上述の処理を実行することによって制御装置を構成する。このとき、制御装置は、情報処理装置１０、基地局２０及び端末装置４０の外部の装置（例えば、パーソナルコンピュータ）であってもよい。また、制御装置は、情報処理装置１０、基地局２０及び端末装置４０の内部の装置（例えば、制御部１３、２４、４５）であってもよい。
【0367】
また、上記通信プログラムをインターネット等のネットワーク上のサーバ装置が備えるディスク装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。また、上述の機能を、ＯＳ（Operating System）とアプリケーションソフトとの協働により実現してもよい。この場合には、ＯＳ以外の部分を媒体に格納して配布してもよいし、ＯＳ以外の部分をサーバ装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。
【0368】
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【0369】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。なお、この分散・統合による構成は動的に行われてもよい。
【0370】
また、上述の実施形態は、処理内容を矛盾させない領域で適宜組み合わせることが可能である。また、上述の実施形態のシーケンス図に示された各ステップは、適宜順序を変更することが可能である。
【0371】
また、例えば、本実施形態は、装置又はシステムを構成するあらゆる構成、例えば、システムＬＳＩ（Large Scale Integration）等としてのプロセッサ、複数のプロセッサ等を用いるモジュール、複数のモジュール等を用いるユニット、ユニットにさらにその他の機能を付加したセット等（すなわち、装置の一部の構成）として実施することもできる。
【0372】
なお、本実施形態において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【0373】
また、例えば、本実施形態は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【0374】
＜＜７．むすび＞＞
以上、本開示の実施形態について説明したが、本開示の技術的範囲は、上述の各実施形態そのままに限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、異なる実施形態及び変形例にわたる構成要素を適宜組み合わせてもよい。
以上、本開示の実施形態について説明したが、本開示の技術的範囲は、上述の各実施形態そのままに限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、異なる実施形態及び変形例にわたる構成要素を適宜組み合わせてもよい。
【0375】
また、本明細書に記載された各実施形態における効果はあくまで例示であって限定されるものでは無く、他の効果があってもよい。
【0376】
なお、本技術は以下のような構成も取ることができる。
（１）
コアネットワークからＳＢＩ（Service Based Interface）経由で端末装置に関する第１の情報を取得し、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備える情報処理装置。
（２）
前記端末関連情報は、前記端末装置のアプリケーションレイヤーが有する情報を含む、（１）に記載の情報処理装置。
（３）
前記端末関連情報は、Registrationのスケジュールに関するスケジュール情報、前記端末装置の消費電力に関する電力情報、及び、前記端末装置の位置に関する位置情報の少なくとも１つを含む、（１）又は（２）に記載の情報処理装置。
（４）
前記位置情報は、前記端末装置に搭載される機器を用いて測定される、（３）に記載の情報処理装置。
（５）
前記位置情報は、現在の位置情報、過去の位置情報、及び、未来の位置情報の少なくとも１つを含む、（３）又は（４）に記載の情報処理装置。
（６）
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記クライアント装置は、前記電力情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
（３）～（５）のいずれか１つに記載の情報処理装置。
（７）
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記クライアント装置は、前記位置情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
（３）～（６）のいずれか１つに記載の情報処理装置。
（８）
前記制御部は、前記クライアント装置が指定する条件を満たす前記端末装置に関する情報を少なくとも１つ含むグループ情報を前記クライアント装置に通知する、（１）～（７）のいずれか１つに記載の情報処理装置。
（９）
前記条件は、前記端末装置のRegistrationの状態を指定するRegistration条件、前記端末装置の消費電力の状態を指定する電力条件、及び、前記端末装置の位置を指定する位置条件の少なくとも１つを含む、（８）に記載の情報処理装置。
（１０）
前記位置条件は、前記端末装置の現在の位置、過去の位置、及び、未来の位置の少なくとも１つを指定する条件を含む、（９）に記載の情報処理装置。
（１１）
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記計測情報は、前記Registration情報に基づいて算出される前記端末装置のRegistrationの遷移間隔に関する情報を含む、
（１）～（１０）のいずれか１つに記載の情報処理装置。
（１２）
前記計測情報は、前記端末装置がIdle状態に遷移するまでのIdle遷移時間に関する情報を含む、（１１）に記載の情報処理装置。
（１３）
前記クライアント装置は、前記計測情報に基づき、前記端末装置がIdle状態に遷移するタイミング以前に、前記端末装置と通信を行う、（１２）に記載の情報処理装置。
（１４）
コアネットワークからＳＢＩ（Service based interface）経由で端末装置に関する第１の情報を取得することと、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得することと、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定することと、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知することと、
を含む情報処理方法。
（１５）
情報処理装置に直接、又は、ＳＢＩ（Service Based Interface）経由で端末関連情報を通知する、制御部、
を備える端末装置であって、
前記情報処理装置は、
コアネットワークからＳＢＩ経由で前記端末装置に関する第１の情報を取得し、
前記端末関連情報から、又は、前記第１の情報と前記端末関連情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記端末関連情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、
端末装置。
（１６）
第１の情報処理装置と、コアネットワークのネットワークファンクションとして機能する第２の情報処理装置と、端末装置と、を備えるシステムであって、
前記第１の情報処理装置は、
前記第２の情報処理装置からＳＢＩ（Service Based Interface）経由で前記端末装置に関する第１の情報を取得し、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備えるシステム。
（１）
コアネットワークからＳＢＩ（Service Based Interface）経由で端末装置に関する第１の情報を取得し、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備える情報処理装置。
（２）
前記端末関連情報は、前記端末装置のアプリケーションレイヤーが有する情報を含む、（１）に記載の情報処理装置。
（３）
前記端末関連情報は、Registrationのスケジュールに関するスケジュール情報、前記端末装置の消費電力に関する電力情報、及び、前記端末装置の位置に関する位置情報の少なくとも１つを含む、（１）又は（２）に記載の情報処理装置。
（４）
前記位置情報は、前記端末装置に搭載される機器を用いて測定される、（３）に記載の情報処理装置。
（５）
前記位置情報は、現在の位置情報、過去の位置情報、及び、未来の位置情報の少なくとも１つを含む、（３）又は（４）に記載の情報処理装置。
（６）
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記クライアント装置は、前記電力情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
（３）～（５）のいずれか１つに記載の情報処理装置。
（７）
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記クライアント装置は、前記位置情報、及び、前記Registration情報に基づき、アクセスする前記端末装置を決定する、
（３）～（６）のいずれか１つに記載の情報処理装置。
（８）
前記制御部は、前記クライアント装置が指定する条件を満たす前記端末装置に関する情報を少なくとも１つ含むグループ情報を前記クライアント装置に通知する、（１）～（７）のいずれか１つに記載の情報処理装置。
（９）
前記条件は、前記端末装置のRegistrationの状態を指定するRegistration条件、前記端末装置の消費電力の状態を指定する電力条件、及び、前記端末装置の位置を指定する位置条件の少なくとも１つを含む、（８）に記載の情報処理装置。
（１０）
前記位置条件は、前記端末装置の現在の位置、過去の位置、及び、未来の位置の少なくとも１つを指定する条件を含む、（９）に記載の情報処理装置。
（１１）
前記第１の情報は、前記端末装置のRegistrationに関するRegistration情報を含み、
前記計測情報は、前記Registration情報に基づいて算出される前記端末装置のRegistrationの遷移間隔に関する情報を含む、
（１）～（１０）のいずれか１つに記載の情報処理装置。
（１２）
前記計測情報は、前記端末装置がIdle状態に遷移するまでのIdle遷移時間に関する情報を含む、（１１）に記載の情報処理装置。
（１３）
前記クライアント装置は、前記計測情報に基づき、前記端末装置がIdle状態に遷移するタイミング以前に、前記端末装置と通信を行う、（１２）に記載の情報処理装置。
（１４）
コアネットワークからＳＢＩ（Service based interface）経由で端末装置に関する第１の情報を取得することと、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得することと、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定することと、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知することと、
を含む情報処理方法。
（１５）
情報処理装置に直接、又は、ＳＢＩ（Service Based Interface）経由で端末関連情報を通知する、制御部、
を備える端末装置であって、
前記情報処理装置は、
コアネットワークからＳＢＩ経由で前記端末装置に関する第１の情報を取得し、
前記端末関連情報から、又は、前記第１の情報と前記端末関連情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記端末関連情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、
端末装置。
（１６）
第１の情報処理装置と、コアネットワークのネットワークファンクションとして機能する第２の情報処理装置と、端末装置と、を備えるシステムであって、
前記第１の情報処理装置は、
前記第２の情報処理装置からＳＢＩ（Service Based Interface）経由で前記端末装置に関する第１の情報を取得し、
前記第１の情報に基づいて計測した計測情報、及び、前記端末装置から直接又は前記ＳＢＩ経由で取得した端末関連情報の少なくとも一方を含む第２の情報を取得し、
前記第２の情報から、又は、前記第１の情報と前記第２の情報とを対応付けて前記端末装置を特定し、
前記第１の情報及び前記第２の情報の少なくとも一方を、特定した前記端末装置と対応付けてクライアント装置に通知する、制御部、
を備えるシステム。
【符号の説明】
【0377】
１ 情報処理システム
１０ 情報処理装置
１１ 通信部
１２，２２，４２ 記憶部
１３，２４，４５ 制御部
２０ 基地局
２１，４１ 信号処理部
２３ ネットワーク通信部
４０ 端末装置
４４ 入出力部
１０ 情報処理装置
１１ 通信部
１２，２２，４２ 記憶部
１３，２４，４５ 制御部
２０ 基地局
２１，４１ 信号処理部
２３ ネットワーク通信部
４０ 端末装置
４４ 入出力部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】