WO2022044722A1 - 情報処理装置、基地局装置、通信方法及び通信システム - Google Patents

Abstract

情報処理装置（２６０）は、制御部（２６３）を備える。制御部（２６３）は、端末装置（４００）にアプリケーション機能を提供する装置（１００）から情報を取得する。制御部（２６３）は、前記情報に基づき、前記端末装置（４００）の間欠受信に関する設定情報を、前記端末装置（４００）と通信を行う基地局装置（３００）にアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて通知する。

Description

情報処理装置、基地局装置、通信方法及び通信システム

　本開示は、情報処理装置、基地局装置、通信方法及び通信システムに関する。

　地域ニーズや個別ニーズに応じて様々な主体が利用可能な次世代移動通信システムの検討が進んでいる。次世代移動通信システムには、例えば、携帯電話事業者による全国向け５Ｇサービスとは別に、地域の企業や自治体等の様々な主体が自らの建物や敷地内でスポット的に柔軟にネットワークを構築し利用可能とする仕組み等がある。

特開２０１９－５７９２９号公報

　スポット的にネットワークを構築すると、複数のネットワークが同時に存在することになり、アプリケーション機能を端末装置に提供するサーバが、異なるネットワークに接続する端末装置と同時に通信を行う可能性がある。例えば、異なるネットワークに接続する端末装置が、同時にゲームをプレイする場合、同じゲームサーバと同時に通信を行う。

　複数の端末装置が、ネットワークゲームを行う場合など、同期して１つのサーバと接続する場合、サーバとの間の通信に発生する遅延量が端末装置ごとに異なる恐れがある。このとき、例えば各端末装置の遅延量が一定であれば、サーバ側で予め遅延を考慮することで、複数の端末装置が同期してサーバと通信を行うことができる。しかしながら、遅延が揺らいでしまうと遅延量が定まらず、複数の端末装置が同期してサーバと通信を行うことが難しくなる恐れがある。

　このように、複数の端末装置が同期してサーバと通信を行う場合に、遅延の揺らぎを抑制したいという要望があった。

　そこで、本開示では、遅延の揺らぎをより抑制することができる仕組みを提供する。

　本開示によれば、情報処理装置が提供される。情報処理装置は、制御部を備える。制御部は、端末装置にアプリケーション機能を提供する装置から情報を取得する。制御部は、前記情報に基づき、前記端末装置の間欠受信に関する設定情報を、前記端末装置と通信を行う基地局装置にアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて通知する。

本開示の実施形態に係る通信システム１の概略について説明するための図である。 ５Ｇのアーキテクチャの一例を示す図である。 ４Ｇのアーキテクチャの一例を示す図である。 本開示の実施形態に係るPrivate　５Ｇの構成例について説明するための図である。 本開示の実施形態に係る情報処理装置の構成例を示すブロック図である。 本開示の実施形態に係る基地局装置の構成例を示すブロック図である。 本開示の実施形態に係る端末装置の構成例を示すブロック図である。 本開示の第１の実施形態に係る通信システムにおける遅延について説明するための図である。 ＤＲＸの概要について説明するための図である。 ＣＤＲＸによって発生する遅延の揺らぎについて説明するための図である。 ＣＤＲＸによって発生する遅延の揺らぎについて説明するための図である。 本開示の第１の実施形態に係る通信システムで実行されるＣＤＲＸ設定処理の一例を説明するための図である。 本開示の第１の実施形態に係るＣＤＲＸ設定処理の流れを説明するためのシーケンス図である。 本開示の実施形態に係るＣＤＲＸ設定要求処理の流れの一例を示すシーケンス図である。 本開示の第２の実施形態に係る遅延の揺らぎについて説明するための図である。 本開示の第２の実施形態に係る端末装置による映像データの受信タイミングを説明するための図である。 本開示の第２の実施形態に係る基地局装置が通知するデータの到着タイミングについて説明するための図である。 本開示の第２の実施形態に係る到着タイミングの通知処理の流れの一例を説明するためのシーケンス図である。 本開示の第２の実施形態に係る到着タイミングの通知処理の流れの他の例を説明するためのシーケンス図である。 ＣＤＲＸの開始タイミングについて説明するための図である。 本開示の第３の実施形態に係るＣＤＲＸ同期処理の流れの一例を説明するための図である。 本開示の第３の実施形態に係るＣＤＲＸ同期処理の流れの一例を説明するための図である。 本開示の第４の実施形態に係る切り替え処理の流れの一例を説明するための図である。

　以下に添付図面を参照しながら、本開示の実施形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

　また、本明細書及び図面において、実施形態の類似する構成要素については、同一の符号の後に異なるアルファベットを付して区別する場合がある。ただし、類似する構成要素の各々を特に区別する必要がない場合、同一符号のみを付する。

　以下に説明される１又は複数の実施形態（実施例、変形例を含む）は、各々が独立に実施されることが可能である。一方で、以下に説明される複数の実施形態は少なくとも一部が他の実施形態の少なくとも一部と適宜組み合わせて実施されてもよい。これら複数の実施形態は、互いに異なる新規な特徴を含み得る。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し得、互いに異なる効果を奏し得る。

　なお、説明は以下の順序で行うものとする。
　　１．概要
　　　１．１．システムの概略的な構成
　　　１．２．提案技術の概要
　　２．通信システムの構成例
　　　２．１．ネットワークアーキテクチャの構成例
　　　２．２．Private　５Ｇ
　　　２．３．情報処理装置
　　　２．４．基地局装置
　　　２．５．端末装置
　　３．第１の実施形態
　　４．第２の実施形態
　　５．第３の実施形態
　　６．第４の実施形態
　　７．変形例

　＜＜１．概要＞＞
　＜１．１．システムの概略的な構成＞
　まず、図１を参照して、本開示の実施形態に係る通信システム１の概要について説明する。図１は、本開示の実施形態に係る通信システム１の概略について説明するための図である。

　図１に示す例では、通信システム１は、情報処理装置１００と、コアネットワーク２００Ａ、２００Ｂと、基地局装置３００Ａ、３００Ｂと、端末装置４００Ａ、４００Ｂと、を含む。

　情報処理装置１００は、端末装置４００にアプリケーション機能を提供するサーバ（装置）である。以下、情報処理装置１００を、アプリケーションサーバ１００と称する。

　アプリケーションサーバ１００は、複数の端末装置４００と同期して通信を行う。例えば、アプリケーションサーバ１００は、複数の端末装置４００にネットワークゲームを提供するゲームサーバである。この場合、アプリケーションサーバ１００は、例えばゲームデータであるAugmented　Reality　（AR）／Virtual　Reality（VR）データを複数の端末装置４００に対して同期して配信する。

　また、アプリケーションサーバ１００は、例えばＩｏＴ（Internet　of　Things）制御用サーバであり得る。例えば、アプリケーションサーバ１００は、複数の自動車（端末装置４００の一例）を整列して走行させる制御サーバであってもよい。この場合、アプリケーションサーバ１００は、例えば、タイミングを同期して複数の自動車を制御する。アプリケーションサーバ１００は、例えば、ＩｏＴ制御情報（例えば自動車の制御情報）を複数の端末装置４００に対して同期して配信する。

　コアネットワーク２００は、例えばローカル５Ｇやローカル４Ｇのような、ローカル・セルラーネットワークである。コアネットワーク２００は、例えばＡＦ（Application　Function）ノードの機能を有する情報処理装置２６０を含む。

　情報処理装置２６０は、アプリケーションサーバ１００が送信する送信データを端末装置４００に送信する。例えば、情報処理装置２６０は、送信データをＰｕｓｈ通知で端末装置４００に送信するPush　Notificationサーバであってもよい。

　基地局装置３００は、端末装置４００と無線通信する無線通信装置である。基地局装置３００は、通信装置の一種である。また、基地局装置３００は、情報処理装置の一種である。

　端末装置４００は、基地局装置３００と無線通信する無線通信装置である。端末装置４００は、端末装置４００は、例えば、携帯電話、スマートデバイス（スマートフォン、又はタブレット）、ＰＤＡ（Personal　Digital　Assistant）、パーソナルコンピュータである。また、端末装置４００は、Ｍ２Ｍ（Machine　to　Machine）デバイス、又はＩｏＴ（Internet　of　Things）デバイスであってもよい。また、端末装置４００は、ヘッドマウントディスプレイ（Head　Mounted　Display）やＶＲゴーグル等であってもよい。

　端末装置４００は、基地局装置３００を介してコアネットワーク２００に接続する。

　＜１．２．提案技術の概要＞
　図１に示す通信システム１において、アプリケーションサーバ１００と端末装置４００とが通信を行うと、アプリケーションサーバ１００と端末装置４００との間で通信遅延が発生する。このとき、複数の端末装置４００Ａ、４００Ｂが、図１に示すように、それぞれ異なるコアネットワーク２００Ａ、２００Ｂと接続していると、通信遅延量が端末装置４００Ａ、４００Ｂで異なる場合がある。

　例えば、端末装置４００Ａ、４００Ｂで通信遅延量が一定の場合、アプリケーションサーバ１００が遅延量を考慮してデータ送信を調整することで、端末装置４００Ａ、４００Ｂで同期してデータを配信することができる。

　ところが、端末装置４００Ａ、４００Ｂの通信遅延量が揺らぐ場合、アプリケーションサーバ１００側でのデータ送信の調整が難しくなり、端末装置４００Ａ、４００Ｂで同期したデータの配信が難しくなってしまう。

　かかる通信遅延量の揺らぎは、例えば、端末装置４００Ａ、４００Ｂが間欠受信（例えばConnected　ＤＲＸ（Discontinuous　Transmission））を行う場合に発生しやすくなる。間欠受信を行っている端末装置４００Ａ、４００Ｂの受信タイミングがそれぞれ異なると、端末装置４００Ａ、４００Ｂが同期してデータを受信できなくなり、通信遅延量の揺らぎが発生する恐れがある。なお、かかる通信遅延量の揺らぎの詳細については後述する。

　特に、従来の端末装置４００Ａ、４００Ｂでは、接続するコアネットワーク２００が異なると、間欠受信の受信タイミングを同期させることが難しかった。

　そこで、本開示の実施形態に係る情報処理装置２６０は、アプリケーションサーバ１００から情報を受信する。情報処理装置２６０は、受信した情報に基づき、端末装置４００の間欠受信に関する設定情報を、端末装置４００と通信を行う基地局装置３００に通知する。

　なお、情報処理装置２６０がアプリケーションサーバ１００から受信する情報には、例えば同期させる端末装置４００を特定する情報や、データを送信するタイミングに関する情報が含まれ得る。

　また、情報処理装置２６０は、例えば、図示しないＡＭＦ（Access　Management　Function）ノードを介して基地局装置３００に設定情報を通知する。あるいは、情報処理装置２６０がＡＭＦの機能を有し、直接基地局装置３００に設定情報を通知してもよい。

　これにより、情報処理装置２６０は、端末装置４００の間欠受信のタイミングを揃えることができ、通信遅延量の揺らぎを抑制することができる。

　＜＜２．通信システムの構成例＞＞
　＜２．１．ネットワークアーキテクチャの構成例＞
　次に、図２を参照して通信システム１のコアネットワーク２００の一例として、第５世代移動体通信システム（５Ｇ）のアーキテクチャについて説明する。図２は、５Ｇのアーキテクチャの一例を示す図である。５Ｇのコアネットワーク２００は、５ＧＣ（5G　Core）／ＮＧＣ（Next　Generation　Core）とも呼ばれる。以下、５Ｇのコアネットワーク２００を５ＧＣ／ＮＧＣ２００とも称する。５ＧＣ／ＮＧＣ２００は、（Ｒ）ＡＮ３０１を介してＵＥ（User　Equipment）４０１と接続する。

　（Ｒ）ＡＮ３０１は、ＲＡＮ（Radio　Access　Network）との接続、およびＲＡＮ以外のＡＮ（Access　Network）との接続を可能にする機能を有する。（Ｒ）ＡＮ３０１は、ｇＮＢ、或いは、ｎｇ－ｅＮＢと呼ばれる基地局装置を含む。

　５ＧＣ／ＮＧＣ２００は、主にＵＥ４０１がネットワークへ接続する際の接続許可やセッション管理を行う。５ＧＣ／ＮＧＣ２００は、ユーザプレーン機能群２２０およびコントロールプレーン機能群２４０を含んで構成され得る。

　ユーザプレーン機能群２２０は、ＵＰＦ（User　Plane　Function）２２１およびＤＮ（Data　Network）２２２を含む。ＵＰＦ２２１は、ユーザプレーン処理の機能を有する。ＵＰＦ２２１は、ユーザプレーンで扱われるデータのルーティング／転送機能を含む。ＤＮ２２２は、例えば、ＭＮＯ(Mobile　Network　Operator)等、オペレータ独自のサービスへの接続を提供するエンティティ、インターネット接続を提供する、あるいは、サードパーティーのサービスへの接続を提供する機能を有する。このように、ユーザプレーン機能群２２０は、５ＧＣ／ＮＧＣ２００とインターネットとの境界になるＧａｔｅｗａｙの役割を果たしている。

　コントロールプレーン機能群２４０は、ＡＭＦ（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）２４９を含む。

　ＡＭＦ２４１は、ＵＥ４０１のレジストレーション処理や接続管理、モビリティ管理等の機能を有する。ＳＭＦ２４２は、セッション管理、ＵＥ４０１のＩＰ割り当てと管理等の機能を有する。ＡＵＳＦ２４３は、認証機能を有する。ＮＳＳＦ２４４は、ネットワークスライスの選択にかかる機能を有する。ＮＥＦ２４５は、サードパーティー、ＡＦ２４９やエッジ・コンピューティング機能に対してネットワーク機能のケイパビリティやイベントを提供する機能を有する。

　ＮＲＦ２４６は、ネットワーク機能の発見やネットワーク機能のプロファイルを保持する機能を有する。ＰＣＦ２４７は、ポリシー制御の機能を有する。ＵＤＭ２４８は３ＧＰＰ　ＡＫＡ認証情報の生成、ユーザＩＤの処理の機能を有する。ＡＦ２４９は、コアネットワークと相互に作用してサービスを提供する機能を有する。

　例えば、コントロールプレーン機能群２４０は、ＵＥ４０１の加入者情報が格納されているＵＤＭ２４８から情報を取得して、当該ＵＥ４０１がネットワークに接続してもよいか否かを判定する。コントロールプレーン機能群２４０は、かかる判定にＵＤＭ２４８から取得した情報に含まれるＵＥ４０１の契約情報や暗号化のための鍵を使用する。また、コントロールプレーン機能群２４０は、暗号化のための鍵の生成等を行う。

　つまり、コントロールプレーン機能群２４０は、例えば、ＩＭＳＩ（International　Mobile　Subscriber　Identity）と呼ばれる加入者番号に紐付いたＵＥ４０１の情報がＵＤＭ２４８に格納されているか否かに応じてネットワークの接続可否を判定する。なお、ＩＭＳＩは、例えば、ＵＥ４０１の中にあるＳＩＭ（Subscriber　Identity　Module）カードに格納される。

　ここで、Ｎａｍｆは、ＡＭＦ２４１が提供するサービスベースドインタフェース（Service-based　interface）、Ｎｓｍｆは、ＳＭＦ２４２が提供するサービスベースドインタフェースである。また、Ｎｎｅｆは、ＮＥＦ２４５が提供するサービスベースドインタフェース、Ｎｐｃｆは、ＰＣＦ２４７が提供するサービスベースドインタフェースである。Ｎｕｄｍは、ＵＤＭ２４８が提供するサービスベースドインタフェース、Ｎａｆは、ＡＦ２４９が提供するサービスベースドインタフェースである。Ｎｎｒｆは、ＮＲＦ２４６が提供するサービスベースドインタフェース、Ｎｎｓｓｆは、ＮＳＳＦ２４４が提供するサービスベースドインタフェースである。Ｎａｕｓｆは、ＡＵＳＦ２４３が提供するサービスベースドインタフェースである。これらの各ＮＦ（Network　Function）は、各サービスベースドインタフェースを介して他のＮＦと情報の交換を行う。

　また、図１に示すＮ１は、ＵＥ４０１とＡＭＦ２４１間のリファレンスポイント（Reference　Point）、Ｎ２は、ＲＡＮ／ＡＮ３０１とＡＭＦ２４１間のリファレンスポイントである。Ｎ４は、ＳＭＦ２４２とＵＰＦ２２１間のリファレンスポイントであり、これらの各ＮＦ（Network　Function）間で相互に情報の交換が行われる。

　上述したように、５ＧＣ／ＮＧＣ２００では、サービスベースドインタフェースと称するＡＰＩ（Application　Programming　Interface）経由で情報の伝達、機能の制御を行うインタフェースが用意されている。

　ＡＰＩは、リソースを指定して、そのリソースに対して、ＧＥＴ（リソースの取得）、ＰＯＳＴ（リソースの作成、データの追加）、ＰＵＴ（リソースの作成、リソースの更新）、ＤＥＬＥＴＥ（リソースの削除）などを可能とする。かかる機能は、例えばＷｅｂに関する技術分野で一般的に使用される。

　例えば、図２に示すＡＭＦ２４１、ＳＭＦ２４２及びＵＤＭ２４８は、通信のセッションを確立する場合に、ＡＰＩを用いて互いに情報をやり取りする。従来、かかるＡＰＩをアプリケーション（例えば、ＡＦ２４９）が使用することは想定されていない。しかしながら、かかるＡＰＩをＡＦ２４９が使用することで、ＡＦ２４９が５Ｇセルラーネットワークの情報を使用することができ、アプリケーションの機能をより進化させることができると考えられる。

　なお、Public　Networkにおいて、ＡＭＦ２４１、ＳＭＦ２４２及びＵＤＭ２４８が使用するＡＰＩを、ＡＦ２８９が使用することは難しい。しかしながら、Non　PublicなPrivate　5G　Networkであれば、かかるＡＰＩをＡＦ２８９が使用できるように、例えば５ＧＣ／ＮＧＣ２００のＡＰＩの変更を含めてシステムを構成することが可能であると考える。

　ここで、ＡＰＩの一例について説明する。ここで説明するＡＰＩ（１）～ＡＰＩ（４）は、3GPP　TS23.502に記載されている。

　［ＡＰＩ（１）］
　ＡＰＩ（１）は、あらかじめ登録しておいたＵＥ４０１が電源Ｏｆｆの状態から電源Ｏｎの状態に遷移してネットワークにａｔｔａｃｈしたこと、及び、そのときに取得したＩＰ　ＡｄｄｒｅｓｓをＳＭＦ２４２が通知するＡＰＩである。

　ＳＭＦ２４２は、ＡＰＩ（１）を使用して、登録しておいたＩＭＳＩのＵＥ４０１がＩＰ　Ａｄｄｒｅｓｓを取得したら、ＮＦに通知する。

　［ＡＰＩ（２）］
　ＵＥ４０１は、通信をしていない場合にIdle　modeとなり、通信する場合にConnected　modeに遷移する。ＡＰＩ（２）は、ＵＥ４０１がIdle　modeであるかConnected　modeであるかをＡＭＦ２４１が通知するＡＰＩである。

　［ＡＰＩ（３）］
　ＡＰＩ（３）は、ＵＥ４０１に対してIdle　modeからConnected　modeに遷移するよう指示を出すためのmessage（Paging　message）を基地局からブロードキャストするためのＡＰＩである。

　［ＡＰＩ（４）］
　ＡＰＩ（４）は、ＵＥ４０１の位置情報をＡＭＦ２４１が提供するＡＰＩである。ＡＭＦ２４１は、ＡＰＩ（４）を使用して、ＵＥ４０１がどのTracking　Areaにいるのか、どのＣｅｌｌに所属しているのか、また、特定の地域に入った時にそのことを知らせ得る。

　なお、図２のＵＥ４０１の一例は、本実施形態の端末装置４００である。ＲＡＮ／ＡＮ３０１の一例が、本実施形態の基地局装置３００である。

　また、図１に示す情報処理装置２６０は、例えばＡＦ２４９又はＡＭＦ２４１の機能を有する装置の一例である。アプリケーションサーバ１００は、インターネットを介してコアネットワーク２００に接続され、図２では図示を省略している。

　図３を参照して通信システム１のコアネットワーク２００の一例として、第４世代移動体通信システム（４Ｇ）のアーキテクチャについて説明する。図３は、４Ｇのアーキテクチャの一例を示す図である。

　図３に示すように、コアネットワーク２００は、ｅＮＢ３０２、ＭＭＥ（Mobility　Management　Entity）２５２、Ｓ－ＧＷ（Serving　Gateway）２５３、Ｐ－ＧＷ（Packet　Data　Network　Gateway）２５４、ＨＳＳ（Home　Subscriber　Server）２５５を含む。

　ｅＮＢ３０２は４Ｇの基地局として機能する。ＭＭＥ２５２は、制御プレーン（コントロールプレーン）の信号を取り扱う制御ノードであり、ＵＥ４０１の移動状態を管理する。ＵＥ４０１は、セルラーシステムにattachするために、ＭＭＥ２５２にAttach　requestを送信する。

　Ｓ－ＧＷ２５３は、ユーザプレーンの信号を取り扱う制御ノードであり、ユーザデータの転送経路を切り替えるゲートウェイ装置である。Ｐ－ＧＷ２５４は、ユーザプレーンの信号を取り扱う制御ノードであり、コアネットワーク２００とインターネットとの接続点となるゲートウェイ装置である。ＨＳＳ２５５は、加入者データを取り扱い、サービス制御を行う制御ノードである。

　ＭＭＥ２５２は、５ＧネットワークにおけるＡＭＦ２４１及びＳＭＦ２４２の機能に相当する。また、ＨＳＳ２５５は、ＵＤＭ２４８の機能に相当する。

　図３に示すように、ｅＮＢ３０２は、ＭＭＥ２５２とＳ１－ＭＭＥインタフェースを介して接続され、Ｓ－ＧＷ２５３とＳ１－Ｕインタフェースを介して接続される。Ｓ－ＧＷ２５３は、ＭＭＥ２５２とＳ１１インタフェースを介して接続され、ＭＭＥ２５２は、ＨＳＳ２５５とＳ６ａインタフェースを介して接続される。Ｐ－ＧＷ２５４は、Ｓ－ＧＷ２５３とＳ５／Ｓ８インタフェースを介して接続される。

　＜２．２．Private　５Ｇ＞
　本開示の実施形態に係る通信システム１の一部は、Private　５Ｇ又はPrivate　４Ｇを採用し得る。現在、ＬＡＮ（Local　Area　Network）では、802.11の規格に準拠した無線ＬＡＮが使用されている。Private　５Ｇ又はPrivate　４Ｇは、このＬＡＮに、セルラーシステムの基地局装置３００（例えば、図２のＲＡＮ／ＡＮ３０１や図３のｅＮＢ３０２）を設置して運用するセルラーシステムである。３ＧＰＰでは、Private　５Ｇ又はPrivate　４ＧをNon　Public　Networkと称する。なお、以下では、通信システム１の一部がPrivate　５Ｇを採用しているものとして説明する。

　図４を用いて、本開示の実施形態に係る通信システム１のうちセルラーシステム（基地局装置３００及びコアネットワーク２００で構成されるシステム）としてPrivate　５Ｇを採用する場合について説明する。図４は、本開示の実施形態に係るPrivate　５Ｇの構成例について説明するための図である。

　Private　５Ｇでは、基地局装置３００及び端末装置４００とコアネットワーク２００の一部の機能を有する情報処理装置２６０Ａ、２６０Ｂがローカルエリアネットワーク（ＬＡＮ）に配置される。また、残りのコアネットワーク２００の機能を有する情報処理装置２６０Ｃ～２６０Ｆが、例えばインターネット回線のCloudのデータセンター内に配置される。

　図４の例では、ＵＰＦ２２１Ａ、２２１Ｂの機能を有する情報処理装置２６０Ａ、２６０Ｂが、ローカルエリアネットワーク（ＬＡＮ）に配置される。ＵＰＦ２２１Ｃ、２２１Ｄの機能を有する情報処理装置２６０Ｃ、２６０Ｄが、インターネット回線のCloud上に配置される。また、コントロールプレーン機能群２４０として機能する情報処理装置２６０Ｅがインターネット回線のCloud上に配置される。また、ＡＦ２４９の機能を有する情報処理装置２６０Ｆ（例えば図１の情報処理装置２６０に相当）が、コントロールプレーン機能群２４０として機能する情報処理装置２６０Ｅとは別に、Cloud上に配置されてもよい。

　なお、ローカルエリアネットワークに配置されるＵＰＦ２２１Ａ、２２１Ｂは、コントロールプレーン機能群２４０の立ち上げ時、又は、コアネットワーク２００の運用開始時にローカルエリアネットワークに存在する。一方、Cloud上に配置されるＵＰＦ２２１Ｃ、２２１Ｄは、コントロールプレーン機能群２４０の立ち上げ時、又は、コアネットワーク２００の運用開始時にCloud上には存在しない。ＵＰＦ２２１Ｃ、２２１Ｄは、例えば、コントロールプレーン機能群２４０の立ち上げ後、又は、コアネットワーク２００の運用開始後に立ち上げる機能である。

　図４のローカルエリアネットワーク（ＬＡＮ）は、例えば、オフィスや向上、個人宅内に配置される。ローカルエリアネットワーク（ＬＡＮ）は、インターネット回線と例えばネットワークＮを介して接続される。

　基地局装置３００及びコアネットワーク２００には、Private　IP　Addressが付与される。基地局装置３００及びコアネットワーク２００は、Private　IP　Addressを用いて互いに通信する。例えば、Virtual　Private　Network等の技術を利用することで、基地局装置３００及びコアネットワーク２００は、互いにPrivate　IP　Addressを使用して通信し得る。つまり、基地局装置３００及びコアネットワーク２００を接続するネットワークは、Privateなネットワーク（閉域網）と捉えることができる。

　なお、図４では、基地局装置３００、端末装置４００及びＵＰＦ２２１の一部（ＵＰＦ２２１Ａ、２２１Ｂ）がローカルエリアネットワークに配置されるとした。また、コントロールプレーン機能群２４０及びＵＰＦ２２１の一部（ＵＰＦ２２１Ｃ、２２１Ｄ）がCloud上に配置するとしたが、これに限定されない。基地局装置３００及び端末装置４００をローカルエリアネットワークに配置すればよく、ＵＰＦ２２１Ａ、２２１Ｂの機能がCloud上で実現されてもよい。また、コントロールプレーン機能群２４０の少なくとも一部の機能をローカルエリアネットワーク上に実現するようにしてもよい。

　このように、本開示の実施形態に係る通信システム１は、それぞれ異なるPrivate　５Ｇを使用する複数の端末装置４００に対して、ネットワーク側のアプリケーションがデータを送信するシステムである。本開示の実施形態では、例えば、アプリケーションサーバ１００（図１参照）が、機器を制御する制御情報やゲームの映像情報等を、複数の端末装置４００に同時に配信するユースケースが想定される。

　より具体的に、Private　５Ｇ外に配置されるアプリケーションサーバ１００は、Private　５Ｇ内に配置される情報処理装置２６０Ｆを介してデータを端末装置４００に通知する。そのため、情報処理装置２６０Ｆは、Private　５Ｇに配置されたPush　Notificationサーバであるとも言える。なお、Push　Notificationは、ネットワークが起点になってメッセージ（データの一例）を端末装置４００に送信する技術である。

　＜２．３．情報処理装置＞
　次に、図５を用いて、本開示の実施形態に係る情報処理装置２６０の構成例について説明する。図５は、本開示の実施形態に係る情報処理装置２６０の構成例を示すブロック図である。

　情報処理装置２６０は、コアネットワーク２００のＮＦ又はＡＦの機能を実現する装置である。情報処理装置２６０は、例えばサーバ装置である。情報処理装置２６０は、クラウドサーバ（Cloud　Server）、エッジサーバ（Edge　Server）と総称される装置であってもよい。

　図５に示すように情報処理装置２６０は、通信部２６１と、記憶部２６２と、制御部２６３と、を備える。なお、図５に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、情報処理装置２６０の機能は、複数の物理的に分離された構成に分散して実装されてもよい。例えば、情報処理装置２６０は、複数のサーバ装置により構成されていてもよい。

　通信部２６１は、他の装置と通信するための通信インタフェースである。通信部２６１は、ネットワークインタフェースであってもよいし、機器接続インタフェースであってもよい。例えば、通信部２６１は、ＮＩＣ（Network　Interface　Card）等のＬＡＮ（Local　Area　Network）インタフェースであってもよいし、ＵＳＢ（Universal　Serial　Bus）ホストコントローラ、ＵＳＢポート等により構成されるＵＳＢインタフェースであってもよい。また、通信部２６１は、有線インタフェースであってもよいし、無線インタフェースであってもよい。通信部２６１は、情報処理装置２６０の通信手段として機能する。通信部２６１は、制御部２６３の制御に従って基地局装置３００や他のＮＦノード、ＡＮノードと通信する。

　記憶部２６２は、ＤＲＡＭ（Dynamic　Random　Access　Memory）、ＳＲＡＭ（Static　Random　Access　Memory）、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部２６２は、情報処理装置２６０の記憶手段として機能する。

　制御部２６３は、情報処理装置２６０の各部を制御するコントローラ（controller）である。制御部２６３は、例えば、ＣＰＵ（Central　Processing　Unit）、ＭＰＵ（Micro　Processing　Unit）、ＧＰＵ（Graphics　Processing　Unit）等のプロセッサにより実現される。例えば、制御部２６３は、情報処理装置２６０内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ（Random　Access　Memory）等を作業領域として実行することにより実現される。なお、制御部２６３は、ＡＳＩＣ（Application　Specific　Integrated　Circuit）やＦＰＧＡ（Field　Programmable　Gate　Array）等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。

　＜２．４．基地局装置＞
　次に、図６を用いて、本開示の実施形態に係る基地局装置３００の構成例について説明する。図６は、本開示の実施形態に係る基地局装置３００の構成例を示すブロック図である。

　基地局装置３００は、端末装置４００と無線通信する無線通信装置である。基地局装置３００は通信装置の一種である。また、基地局装置３００は情報処理装置の一種である。

　基地局装置３００は、複数の物理的又は論理的装置の集合で構成されていてもよい。例えば、本開示の実施形態において基地局装置３００は、ＢＢＵ（Baseband　Unit）及びＲＵ（Radio　Unit）の複数の装置に区別され、これら複数の装置の集合体として解釈されてもよい。さらに又はこれに代えて、本開示の実施形態において基地局装置３００は、ＢＢＵ及びＲＵのうちいずれか又は両方であってもよい。ＢＢＵとＲＵとは所定のインタフェース（例えば、ｅＣＰＲＩ）で接続されていてもよい。さらに又はこれに代えて、ＲＵはRemote　Radio　Unit（ＲＲＵ）又はRadio　DoT（ＲＤ）と称されていてもよい。さらに又はこれに代えて、ＲＵは後述するgNB-DUに対応していてもよい。さらに又はこれに代えてＢＢＵは、後述するgNB-CUに対応していてもよい。さらに又はこれに代えて、ＲＵはアンテナと一体的に形成された装置であってもよい。基地局装置３００が有するアンテナ（例えば、ＲＵと一体的に形成されたアンテナ）はAdvanced　Antenna　Systemを採用し、ＭＩＭＯ（例えば、FD-MIMO）やビームフォーミングをサポートしていてもよい。Advanced　Antenna　Systemは、基地局装置３００が有するアンテナ（例えば、ＲＵと一体的に形成されたアンテナ）は、例えば、６４個の送信用アンテナポート及び６４個の受信用アンテナポートを備えていてもよい。また、ＲＵに搭載されるアンテナは、１つ以上のアンテナ素子から構成されるアンテナパネルであってもよく、ＲＵは、１つ以上のアンテナパネルを搭載してもよい。例えば、ＲＵは、水平偏波のアンテナパネルと垂直偏波のアンテナパネルの２種類のアンテナパネル、或いは、右旋円偏波のアンテナパネルと左旋円偏波のアンテナパネルの２種類のアンテナパネルを搭載してもよい。また、ＲＵは、アンテナパネル毎に独立したビームを形成し、制御してもよい。

　また、基地局装置３００は、複数が互いに接続されていてもよい。１つ又は複数の基地局装置３００は無線アクセスネットワーク（Radio　Access　Network：ＲＡＮ）に含まれていてもよい。すなわち、基地局装置３００は単にＲＡＮ、ＲＡＮノード、ＡＮ（Access　Network）、ＡＮノードと称されてもよい。ＬＴＥにおけるＲＡＮはＥＵＴＲＡＮ（Enhanced　Universal　Terrestrial　RAN）と呼ばれる。ＮＲにおけるＲＡＮはＮＧＲＡＮと呼ばれる。Ｗ－ＣＤＭＡ（ＵＭＴＳ）におけるＲＡＮはＵＴＲＡＮと呼ばれる。ＬＴＥの基地局装置３００は、ｅＮｏｄｅＢ（Evolved　Node　B）又はｅＮＢと称される。すなわち、ＥＵＴＲＡＮは１又は複数のｅＮｏｄｅＢ（ｅＮＢ）を含む。また、ＮＲの基地局装置３００は、ｇＮｏｄｅＢ又はｇＮＢと称される。すなわち、ＮＧＲＡＮは１又は複数のｇＮＢを含む。さらに、ＥＵＴＲＡＮは、ＬＴＥの通信システム（ＥＰＳ）におけるコアネットワーク（ＥＰＣ）に接続されたｇＮＢ（en-gNB）を含んでいてもよい。同様にＮＧＲＡＮは５Ｇ通信システム（５ＧＳ）におけるコアネットワーク５ＧＣに接続されたng-eNBを含んでいてもよい。さらに又はこれに代えて、基地局装置３００がｅＮＢ、ｇＮＢなどである場合、3GPP　Accessと称されてもよい。さらに又はこれに代えて、基地局装置３００が無線アクセスポイント（Access　Point）である場合、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は、後述されるＦ１インタフェースで送受信されてもよい。基地局装置３００は、他の基地局装置３００と通信可能に構成されていてもよい。例えば、複数の基地局装置３００がｅＮＢ同士又はｅＮＢとen-gNBの組み合わせである場合、当該基地局装置３００間はＸ２インタフェースで接続されてもよい。さらに又はこれに代えて、複数の基地局装置３００がｇＮＢ同士又はgn-eNBとｇＮＢの組み合わせである場合、当該装置間はＸｎインタフェースで接続されてもよい。さらに又はこれに代えて、複数の基地局装置３００がgNB　CU（Central　Unit）とgNB　DU（Distributed　Unit）の組み合わせである場合、当該装置間は前述したＦ１インタフェースで接続されてもよい。後述されるメッセージ・情報（RRC　signalling又はＤＣＩに含まれる情報）は複数基地局装置３００間で（例えばＸ２、Ｘｎ、Ｆ１インタフェースを介して）通信されてもよい。

　さらに、前述の通り、基地局装置３００は、複数のセルを管理するように構成されていてもよい。基地局装置３００により提供されるセルは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））が異なっていてもよい。

　図６に示す基地局装置３００は、通信部３１０と、記憶部３２０と、ネットワーク通信部３３０と、制御部３４０と、を備える。なお、図６に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、基地局装置３００の機能は、複数の物理的に分離された構成に分散して実装されてもよい。

　通信部３１０は、他の無線通信装置（例えば、端末装置４００及び他の基地局装置３００）と無線通信するための信号処理部である。通信部３１０は、制御部３４０の制御に従って動作する。他の無線通信装置が端末装置４００の場合、通信部３１０は１又は複数の無線アクセス方式に対応する無線トランシーバであってもよい。例えば、通信部３１０は、ＮＲ及びＬＴＥの双方に対応する。通信部３１０は、ＮＲやＬＴＥに加えて、Ｗ－ＣＤＭＡやｃｄｍａ２０００に対応していてもよい。また、通信部３１０は、ＮＯＭＡを使った通信に対応していてもよい。他の無線通信装置が他の基地局装置３００である場合、通信部３１０はＸ２インタフェース、Ｘｎインタフェース、又は、Ｆ１インタフェースであってもよい。

　通信部３１０は、受信処理部３１１と、送信処理部３１２と、アンテナ３１３と、を備える。通信部３１０は、受信処理部３１１、送信処理部３１２、及びアンテナ３１３をそれぞれ複数備えていてもよい。なお、通信部３１０が複数の無線アクセス方式に対応する場合、通信部３１０の各部は、無線アクセス方式毎に個別に構成されうる。例えば、受信処理部３１１及び送信処理部３１２は、ＬＴＥとＮＲとで個別に構成されてもよい。

　受信処理部３１１は、アンテナ３１３を介して受信された上りリンク信号の処理を行う。受信処理部３１１は、受信信号を受信する受信部として動作する。受信処理部３１１は、無線受信部３１１ａと、多重分離部３１１ｂと、復調部３１１ｃと、復号部３１１ｄと、を備える。

　無線受信部３１１ａは、上りリンク信号に対して、ダウンコンバート、不要な周波数成分の除去、増幅レベルの制御、直交復調、デジタル信号への変換、ガードインターバル（サイクリックプレフィックス）の除去、高速フーリエ変換による周波数領域信号の抽出等を行う。多重分離部３１１ｂは、無線受信部３１１ａから出力された信号から、ＰＵＳＣＨ（Physical　Uplink　Shared　Channel）、ＰＵＣＣＨ（Physical　Uplink　Control　Channel）等の上りリンクチャネル及び上りリンク参照信号を分離する。

　復調部３１１ｃは、上りリンクチャネルの変調シンボルに対して、ＢＰＳＫ（Binary　Phase　Shift　Keying）、ＱＰＳＫ（Quadrature　Phase　shift　Keying）等の変調方式を使って受信信号の復調を行う。復調部３１１ｃが使用する変調方式は、１６ＱＡＭ（Quadrature　Amplitude　Modulation）、６４ＱＡＭ、又は２５６ＱＡＭであってもよい。この場合、コンスタレーション上の信号点は必ずしも等距離である必要はない。コンスタレーションは、不均一コンスタレーション（NUC：Non　Uniform　Constellation）であってもよい。

　復号部３１１ｄは、復調された上りリンクチャネルの符号化ビットに対して、復号処理を行う。復号された上りリンクデータ及び上りリンク制御情報は制御部３４０へ出力される。

　送信処理部３１２は、下りリンク制御情報及び下りリンクデータの送信処理を行う。このように、送信処理部３１２は、制御部３４０から例えば、下りリンク制御情報や下りリンクデータ等のビット系列を取得する取得部である。送信処理部３１２は、符号化部３１２ａと、変調部３１２ｂと、多重部３１２ｃと、無線送信部３１２ｄと、を備える。

　符号化部３１２ａは、制御部３４０から入力された下りリンク制御情報及び下りリンクデータを、ブロック符号化、畳み込み符号化、ターボ符号化等の符号化方式を用いて符号化を行う。なお、符号化部３１２ａは、ポーラ符号（Polar　code）による符号化、ＬＤＰＣ符号（Low　Density　Parity　Check　Code）による符号化を行ってもよい。

　変調部３１２ｂは、符号化部３１２ａから出力された符号化ビットをＢＰＳＫ、ＱＰＳＫ、１６ＱＡＭ、６４ＱＡＭ、２５６ＱＡＭ等の所定の変調方式で変調する。この場合、コンスタレーション上の信号点は必ずしも等距離である必要はない。コンスタレーションは、不均一コンスタレーションであってもよい。

　多重部３１２ｃは、各チャネルの変調シンボルと下りリンク参照信号とを多重化し、所定のリソースエレメントに配置する。無線送信部３１２ｄは、多重部３１２ｃからの信号に対して、各種信号処理を行う。例えば、無線送信部３１２ｄは、高速フーリエ変換による時間領域から周波数領域への変換、ガードインターバル（サイクリックプレフィックス）の付加、ベースバンドのデジタル信号の生成、アナログ信号への変換、直交変調、アップコンバート、余分な周波数成分の除去、電力の増幅等の処理を行う。送信処理部３１２で生成された信号は、アンテナ３１３から送信される。

　記憶部３２０は、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部３２０は、基地局装置３００の記憶手段として機能する。

　ネットワーク通信部３３０は、ネットワーク上で上位に位置するノード（例えば、情報処理装置２６０）と通信するための通信インタフェースである。例えば、ネットワーク通信部３３０は、ＮＩＣ等のＬＡＮインタフェースであってもよい。さらに又はこれに代えて、ネットワーク通信部３３０は、コアネットワークノードと接続するためのＳ１インタフェース又はＮＧインタフェースであってもよい。ネットワーク通信部３３０は、有線インタフェースであってもよいし、無線インタフェースであってもよい。ネットワーク通信部３３０は、基地局装置３００のネットワーク通信手段として機能する。

　制御部３４０は、基地局装置３００の各部を制御するコントローラ（controller）である。制御部３４０は、例えば、ＣＰＵ（Central　Processing　Unit）、ＭＰＵ（Micro　Processing　Unit）等のプロセッサ（ハードウェアプロセッサ）により実現される。例えば、制御部３４０は、基地局装置３００内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ（Random　Access　Memory）等を作業領域として実行することにより実現される。なお、制御部３４０は、ＡＳＩＣ（Application　Specific　Integrated　Circuit）やＦＰＧＡ（Field　Programmable　Gate　Array）等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。

　＜２．５．端末装置＞
　次に、図７を用いて、本開示の実施形態に係る端末装置４００の構成例について説明する。図７は、本開示の実施形態に係る端末装置４００の構成例を示すブロック図である。

　端末装置４００は、基地局装置３００と無線通信する無線通信装置である。端末装置４００は、例えば、携帯電話、スマートデバイス（スマートフォン、又はタブレット）、ＰＤＡ（Personal　Digital　Assistant）、パーソナルコンピュータである。端末装置４００は、無線を介してデータを送受信する機能を有するヘッドマウントディスプレイ（Head　Mounted　Display）やＶＲゴーグル等であってもよい。

　また、端末装置４００は、他の端末装置４００とサイドリンク通信が可能であってもよい。端末装置４００は、サイドリンク通信を行う際、ＨＡＲＱ（Hybrid　Automatic　Repeat　reQuest）等の自動再送技術を使用可能であってもよい。端末装置４００は、基地局装置３００とＮＯＭＡ（Non　Orthogonal　Multiple　Access）通信が可能であってもよい。なお、端末装置４００は、他の端末装置４００との通信（サイドリンク）においてもＮＯＭＡ通信が可能であってもよい。また、端末装置４００は、他の通信装置（例えば、基地局装置３００、及び他の端末装置４００）とＬＰＷＡ（Low　Power　Wide　Area）通信が可能であってもよい。その他、端末装置４００が使用する無線通信は、ミリ波を使った無線通信であってもよい。なお、端末装置４００が使用する無線通信（サイドリンク通信を含む。）は、電波を使った無線通信であってもよいし、赤外線や可視光を使った無線通信（光無線）であってもよい。

　端末装置４００は、同時に複数の基地局装置または複数のセルと接続して通信を実施してもよい。例えば、１つの基地局装置が複数のセルを提供できる場合、端末装置４００は、あるセルをｐＣｅｌｌとして使用し、他のセルをｓＣｅｌｌとして使用することでキャリアアグリゲーションを実行することができる。また、複数の基地局装置３００がそれぞれ１又は複数のセルを提供できる場合、端末装置４００は、一方の基地局装置（ＭＮ（例えば、MeNB又はMgNB））が管理する１又は複数のセルをｐＣｅｌｌ、又はｐＣｅｌｌとｓＣｅｌｌ（s）として使用し、他方の基地局装置（ＳＮ（例えば、SeNB又はSgNB））が管理する１又は複数のセルをｐＣｅｌｌ（PSCell）、又はｐＣｅｌｌ（PSCell）とｓＣｅｌｌ（s）として使用することでＤＣ（Dual　Connectivity）を実現することができる。ＤＣはＭＣ（Multi　Connectivity）と称されてもよい。

　なお、異なる基地局装置３００のセル（異なるセル識別子又は同一セル識別子を持つ複数セル）を介して通信エリアをサポートしている場合に、キャリアアグリゲーション（CA：Carrier　Aggregation）技術やデュアルコネクティビティ（DC：Dual　Connectivity）技術、マルチコネクティビティ（MC：Multi-Connectivity）技術によって、それら複数のセルを束ねて基地局装置３００と端末装置４００とで通信することが可能である。或いは、異なる基地局装置３００のセルを介して、協調送受信（CoMP：Coordinated　Multi-Point　Transmission　and　Reception）技術によって、端末装置４００とそれら複数の基地局装置３００が通信することも可能である。

　端末装置４００は、通信部４１０と、記憶部４２０と、ネットワーク通信部４３０と、入出力部４４００と、制御部４５０とを備える。なお、図７に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、端末装置４００の機能は、複数の物理的に分離された構成に分散して実装されてもよい。

　通信部４１０は、他の無線通信装置（例えば、基地局装置３００及び他の端末装置４００）と無線通信するための信号処理部である。通信部４１０は、制御１１５の制御に従って動作する。通信部４１０は１又は複数の無線アクセス方式に対応する無線トランシーバであってもよい。例えば、通信部４１は、ＮＲ及びＬＴＥの双方に対応する。通信部４１０は、ＮＲやＬＴＥに加えて、Ｗ－ＣＤＭＡやｃｄｍａ２０００に対応していてもよい。また、通信部４１０は、ＮＯＭＡを使った通信に対応していてもよい。

　通信部４１０は、受信処理部４１１と、送信処理部４１２と、アンテナ４１３と、を備える。通信部４１０は、受信処理部４１１、送信処理部４１２、及びアンテナ４１３をそれぞれ複数備えていてもよい。通信部４１０、受信処理部４１１、送信処理部４１２、及びアンテナ４１４の構成は、基地局装置３００の通信部３１０、受信処理部３１１、送信処理部３１２、及びアンテナ３１４と同様である。

　記憶部４２０は、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部４２０は、端末装置４００の記憶手段として機能する。

　ネットワーク通信部４３０は、ネットワークを介して接続する他の装置と通信するための通信インタフェースである。例えば、ネットワーク通信部４３０は、ＮＩＣ等のＬＡＮインタフェースである。ネットワーク通信部４３０は、有線インタフェースであってもよいし、無線インタフェースであってもよい。ネットワーク通信部４３０は、端末装置４００のネットワーク通信手段として機能する。ネットワーク通信部４３０は、制御部４５０の制御に従って、他の装置と通信する。

　入出力部４４０は、ユーザと情報をやりとりするためのユーザインタフェースである。例えば、入出力部４４０は、キーボード、マウス、操作キー、タッチパネル等、ユーザが各種操作を行うための操作装置である。又は、入出力部４４０は、液晶ディスプレイ（Liquid　Crystal　Display）、有機ＥＬディスプレイ(Organic　Electroluminescence　Display)等の表示装置である。入出力部４４０は、スピーカー、ブザー等の音響装置であってもよい。また、入出力部４４０は、ＬＥＤ（Light　Emitting　Diode）ランプ等の点灯装置であってもよい。入出力部４４０は、端末装置４００の入出力手段（入力手段、出力手段、操作手段又は通知手段）として機能する。

　制御部４５０は、端末装置４００の各部を制御するコントローラである。制御部４５０は、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵ等のプロセッサにより実現される。例えば、制御部４５０は、端末装置４００内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ等を作業領域として実行することにより実現される。なお、制御部４５０は、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＳＩＣ、およびＦＰＧＡは何れもコントローラとみなすことができる。

　＜＜３．第１の実施形態＞＞
　上述したように、複数の端末装置４００がそれぞれ異なるPrivate　Networkに属する場合、アプリケーションサーバ１００が送信するデータは、それぞれ異なる遅延量で各端末装置４００に到達する。かかる点について、図８を用いて説明する。

　図８は、本開示の第１の実施形態に係る通信システム１における遅延について説明するための図である。

　図８では、東京に設置されたアプリケーションサーバ１００が、香港に設置されたPrivate　Networkに接続する端末装置４００Ａ及び大阪に設置されたPrivate　Networkに接続する端末装置４００Ｂに対して同時にデータを送信する場合について示している。ここでは、アプリケーションサーバ１００は、データとしてＶＲゲームの映像情報（VR　game　video）を所定の間隔で送信（Push）するものとする。

　アプリケーションサーバ１００が映像情報を送信すると、まず端末装置４００Ｂに映像情報を受信する（ステップＳ１１）。これは、アプリケーションサーバ１００が位置する東京と端末装置４００Ｂが位置する大阪との間の距離が、東京と端末装置４００Ａが位置する香港との間の距離より短いためである。

　端末装置４００Ｂは、映像情報を受信すると、当該映像情報に対応した応答情報をアプリケーションサーバ１００に送信する（ステップＳ１２）。応答情報は、例えばゲームのコマンド操作などの制御情報が含まれる。

　一方、端末装置４００Ａは、端末装置４００Ｂより遅れて映像情報を受信する（ステップＳ１３）と、当該映像情報に対応した応答情報をアプリケーションサーバ１００に送信する（ステップＳ１４）。図８の例では、端末装置４００Ａが送信した応答情報は、端末装置４００Ｂが送信した応答情報からＤ１だけ遅れてアプリケーションサーバ１００に到達している。

　このように、異なるPrivate　Networkに属する端末装置４００と、アプリケーションサーバ１００との間に存在する通信遅延の遅延量は、Private　Networkごとに異なる。

　ここで、図８のステップＳ１５～Ｓ１８に示すように、アプリケーションサーバ１００と端末装置４００Ａとの間の遅延量及びアプリケーションサーバ１００と端末装置４００Ｂとの間の遅延量が一定であるとする。なお、ステップＳ１５～Ｓ１８の処理は、ステップＳ１１～Ｓ１４と同じ処理であるため、説明を省略する。

　このように、端末装置４００Ａの遅延量及び端末装置４００Ｂの遅延量が一定の場合、アプリケーションサーバ１００が受信する応答情報の遅延差も一定のＤ１となる。複数の端末装置４００Ａ間の遅延差が一定の場合、アプリケーションサーバ１００が遅延差を考慮することで、端末装置４００との間の遅延の影響を小さくすることができる。

　例えば、端末装置４００Ａ、４００Ｂのどちらが先にコマンド操作を行ったか、アプリケーションサーバ１００が判定するとする。この場合、アプリケーションサーバ１００は、あらかじめ端末装置４００Ｂからの応答情報の受信タイミングに遅延差Ｄ１を加算しておいて判定を行う。これにより、端末装置４００の遅延量が異なる場合であっても、アプリケーションサーバ１００は、端末装置４００Ａ、４００Ｂのどちらが先にコマンド操作を行ったか正しく判定することができる。

　このように、端末装置４００とアプリケーションサーバ１００との間の信号遅延量が一定の場合は、アプリケーションサーバ１００によって遅延の影響を小さくすることができる。これにより、アプリケーションサーバ１００は、端末装置４００に提供するサービスの公平性を担保することができる。例えば、端末装置４００Ａ、４００Ｂのどちらが先に旗を取ったかを競うようなゲームであっても、異なるPrivate　Networkに接続する端末装置４００Ａ、４００Ｂが同時にゲームを行うことができる。

　しかしながら、端末装置４００Ａの遅延量及び端末装置４００Ｂの遅延量が揺らぐと、アプリケーションサーバ１００による遅延量の補正が難しくなる。

　例えば、図８に示すように、端末装置４００Ａがデータを受信した場合の遅延量がステップＳ１３、Ｓ１８より大きい（ステップＳ２２）と、アプリケーションサーバ１００が端末装置４００Ａから応答を受信するタイミングが遅くなる（ステップＳ２３）。これにより、端末装置４００Ａ、４００Ｂの遅延差が、Ｄ１より大きいＤ２になる。

　また、端末装置４００Ａがデータを受信した場合の遅延量がステップＳ１３、Ｓ１８より小さい（ステップＳ２６）と、アプリケーションサーバ１００が端末装置４００Ａから応答を受信するタイミングが早くなる（ステップＳ２７）。これにより、端末装置４００Ａ、４００Ｂの遅延差が、Ｄ１より小さいＤ３になる。

　このように、遅延量が揺らぐと、補正量（遅延差）が一定でなくなるため、アプリケーションサーバ１００による補正が難しくなる。例えば、端末装置４００Ａ、４００Ｂが同時にコマンド操作を行ったにもかかわらず、アプリケーションサーバ１００が、端末装置４００Ａ、４００Ｂのどちらか一方が早く操作したと誤判定してしまい、サービスの公平性を担保できない恐れがある。

　このような揺らぎは、種々の要因によって発生する。要因の一つとして、例えば、Private　Networkを含む通信システム１のネットワークにあるスイッチバッファでの待ち合わせが挙げられる。ネットワークには多くのトラフィックが流れており、スイッチのバッファに多くのパケット（データ）が停滞する場合がある。停滞するパケットの量が変動することが、遅延量が揺らぐ要因の一つとなり得る。

　この場合、例えばＱｏＳ（Quality　of　Service）制御によりパケットに優先度を設け、優先度の高いパケットを優先してスイッチの出力に送ることで、パケットの遅延を小さくし、遅延の揺らぎを抑えることができる。

　遅延の揺らぎが発生する別の要因として、ＤＲＸ（Discontinuous　Reception）動作が挙げられる。ここで、図９を用いて、ＤＲＸの概要について説明する。図９は、ＤＲＸの概要について説明するための図である。ＤＲＸとは、ＲＡＮ（Radio　Access　Network）において、端末装置４００の消費電力を抑えるために行われる間欠受信のことである。

　図９に示すように、ＤＲＸを行う端末装置４００は、on　durationの期間で受信動作を行い、それ以外の期間では受信動作を行わない。これを、DRX　Cycleで繰り返し行うことで、端末装置４００は、間欠受信を行う。端末装置４００は、on　duration以外の期間、受信部の電力を切っておくことで、消費電力を抑えることができる。

　ＤＲＸは、Rel15　TS36.321　Section　5.7（LTE）、Rel15　TS38.321　Section5.7（NR）に開示されている。ＤＲＸは、ＬＴＥおよびＮＲで同じように動作する。端末装置４００は、ＤＲＸを行っていない場合、基本的に全てのサブフレームにおいて制御信号であるPDCCHをモニタする。PDCCHに自装置宛てのPDSCHの存在が示されている場合、端末装置４００は、PDCCHに示されていたPDSCHを受信する。自装置宛てのPDSCHがない場合にPDCCHを受信することは、端末装置４００の消費電力の増加につながる。また、受信動作を行っている場合、端末装置４００は、定期的にアップリンクでchannelのmeasurement結果などを基地局装置３００に報告する。そのため、データの送受信を行わない端末装置４００が受信動作を行っていると、端末装置４００に加え基地局装置３００にとって処理負荷や消費電力が増加する。

　そこで、ＮＲ及びＬＴＥでは、端末装置４００がRRC　Connectedの状態で間欠受信を行う仕組みがある。この間欠受信（ＤＲＸ）では、一定周期（DRX　Cycle）で端末装置４００がPDCCHをモニタする区間（on　duration）を設け、その区間以外では端末装置４００がPDCCHをモニタしなくてもよいという仕組みである。

　このＤＲＸは、RRC　Idle、RRC　Connectedのどちらの場合でも行われるが、端末装置４００がアプリケーションサーバ１００からサービスの提供を受けている場合に遅延量が揺らぐ要因としては、上述したRRC　Connected時のＤＲＸ（ＣＤＲＸ：Connected　DRX）が関係する。

　ＣＤＲＸには、様々なパラメータがあり、端末装置４００は、パラメータの組み合わせに応じて様々な間欠受信を行う。ここでは、説明を簡略化するために、端末装置４００が最も基本的な間欠受信を行うものとして説明する。

　ＣＤＲＸには、Long　DRX及びShort　DRXがある。Long　DRXでは、端末装置４００は、図９に示すように、on　durationの期間でPDCCHを受信する。Short　DRXでは、端末装置４００は、Short　drx　on　timeの期間（図示省略）でPDCCHを受信する。

　on　duration又はShort　drx　on　timeに受信したPDCCHによって、自装置宛てのPDSCH（ユーザデータ）があることがわかった場合、端末装置４００は、PDCCHに続きPDSCHを受信する。

　端末装置４００は、on　duration又はShort　drx　on　timeでのPDCCHの受信を、DRX　cycle又はshort　drx　cycleの周期で行う。従って、DRX　cycleまたは、short　drx　cycleの周期で端末装置４００がPDCCHを受信するタイミングがくる。

　このLong　DRX及びShort　DRXの決定や、受信期間（on　duration又はShort　drx　on　time）、周期（DRX　cycle又はshort　drx　cycle）は、基地局装置３００によって決定され、端末装置４００に通知される。これにより、端末装置４００は、所定の期間及び周期で間欠受信を行うことができる。

　なお、以下の説明では、特に断りのない限りLong　DRXについて説明するが、Short　DRXの場合も同様に適用し得る。

　次に、図１０及び図１１を用いて、ＣＤＲＸによって発生する遅延の揺らぎについて説明する。図１０及び図１１は、ＣＤＲＸによって発生する遅延の揺らぎについて説明するための図である。

　図１０（ａ）では、アプリケーションサーバ１００が送信するデータ（例えば、AR/VR　video）の送信タイミングを示している。ここでは、アプリケーションサーバ１００が、期間Ｔ１の周期でデータを送信するものとする。なお、例えば、アプリケーションサーバ１００が、ゲーム画面を１秒間に６０フレーム更新する場合、Ｔ１＝１秒／６０＝１６．６ｍｓになる。

　図１０（ｂ）では、端末装置４００の間欠受信のタイミングと、PDCCHの受信タイミングを示している。ここでは、端末装置４００のDRX　Cycleが、例えば、アプリケーションサーバ１００がデータを送信する周期Ｔ１と同じ（DRX　Cycle＝Ｔ１＝１６．６ｍｓ）であるものとする。

　この場合、端末装置４００は、on　durationの期間で、自装置宛てのデータがあることを示すPDCCHと、自装置宛てのデータを含むPDSCHを受信することができる。on　durationの長さが例えば１ｍｓである場合、端末装置４００は、１５．６ｍｓは受信しないモードに入ることができる。

　一方、端末装置４００のDRX　Cycleが、例えば、アプリケーションサーバ１００がデータを送信する周期Ｔ１と異なる場合を図１１に示す。

　図１１（ａ）では、図１０（ａ）と同様にアプリケーションサーバ１００が送信するデータ（例えば、AR/VR　video）の送信タイミングを示している。

　図１１（ｂ）では、端末装置４００のDRX　Cycleが、例えば、アプリケーションサーバ１００がデータを送信する周期Ｔ１よりも長い場合について示している。

　図１１の例では、端末装置４００が最初のOn　durationの期間でPDCCHとPDSCHを受信した後、次のOn　durationとなるまでの間に、アプリケーションサーバ１００がデータを送信している。しかしながら、このデータの送信時には端末装置４００は受信動作を行っていない。そのため、端末装置４００は、次のOn　durationの期間において、受信しないモード時に送信されたデータに対応するPDCCH及びPDSCHと、On　durationの期間に送信されたデータに対応するPDCCH及びPDSCHと、の２つのPDCCH及びPDSCHを受信する。

　これにより、端末装置４００が受信するPDCCH及びPDSCHの受信タイミングが一定周期にならず、端末装置４００から見ると大きく揺らいで見える。そのため、かかるデータに対する応答を端末装置４００がアップリンクで返すタイミングも揺らぐことになる。このことがアプリケーションサーバ１００と端末装置４００との間の遅延量が一定にならず揺らいでしまう原因となる。

　特に、上述したＣＤＲＸは、１つの基地局装置３００内での設定である。そのため、従来、複数のPrivate　Networkにそれぞれ属する複数の基地局装置３００が提供するＣＤＲＸは、基地局装置３００ごとに独立して設定される。また、従来のＣＤＲＸの設定値は、基地局装置３００内で閉じており、ＡＰＩで公開されるものではなかった。例えば従来のコアネットワークのＡＰＩにも、ＣＤＲＸの設定値を制御するＡＰＩは存在しなかった。

　そこで、本開示の第１の実施形態に係る通信システム１では、アプリケーションサーバ１００から同時にサービスの提供を受ける複数の端末装置４００間で、ＣＤＲＸの周期が、アプリケーションサーバ１００がデータを送信（Push）する周期Ｔ１と一致するようにする。例えば、同じゲームに参加する複数の端末装置４００間で、ゲームのAR/VR　video映像をPushする周期と、ＣＤＲＸの周期とが一致するようにする。

　なお、端末装置４００は、アプリケーションサーバ１００が提供するサービス（以下、単に提供サービスとも記載する。例えばゲーム）以外にも、複数の通信を同時に行っている場合がある。そのため、基地局装置３００は、提供サービスのデータを受信するためだけにＣＤＲＸ周期を決定することはできないが、基地局装置３００がアプリケーションサーバ１００から到着するデータのタイミングに応じて、適切な値のＤＲＸ周期を設定することは実装上可能であると考え得る。しかしながら、基地局装置３００が適切なＤＲＸ周期を設定できるようになるためには、ある程度の学習時間が必要になってしまうため、実装によって適切なＤＲＸ周期を設定できない場合が多いと考え得る。

　そこで、本開示の第１の実施形態では、ＡＦ４２９が、アプリケーションサーバ１００からの情報に基づき、サービス提供のための適切なＤＲＸ周期を含むＣＤＲＸの設定を基地局装置３００に通知するＣＤＲＸの設定処理を行う。これにより、基地局装置３００は、サービスの提供を受ける端末装置４００に対して適切なＣＤＲＸを設定することができる。

　また、本開示の第１の実施形態では、例えば、ＡＭＦ２４１のＡＰＩを用いてＡＦ２４９がＣＤＲＸの設定を行うようにする。これにより、Private　Network内にあるＮＦ又はＡＦ２４９によってＣＤＲＸの設定を行うことができるようになる。

　かかるＣＤＲＸの設定処理について、図１２を用いて説明する。図１２は、本開示の第１の実施形態に係る通信システム１で実行されるＣＤＲＸ設定処理の一例を説明するための図である。

　図１２に示すように、アプリケーションサーバ１００は、ＡＦ２４９Ａを介して、ＡＭＦ２４１Ａに、ＡＭＦ２４１のＡＰＩを利用してＣＤＲＸの設定をリクエストする（ステップＳ３１）。ＡＭＦ２４１Ａは、受信したリクエストを基地局装置３００Ａに送信する（ステップＳ３２）。

　基地局装置３００ＡによってＣＤＲＸの設定が行われると、アプリケーションサーバ１００は、ＵＰＦ２２１Ａを介して端末装置４００Ａとデータの送受信を行う（ステップＳ３３）。

　アプリケーションサーバ１００は、同様に、ＡＦ２４９Ｂを介して、ＡＭＦ２４１Ｂに、ＡＰＩを利用してＣＤＲＸの設定をリクエストする（ステップＳ３４）。ＡＭＦ２４１Ｂは、受信したリクエストを基地局装置３００Ｂに送信する（ステップＳ３５）。

　基地局装置３００ＢによってＣＤＲＸの設定が行われると、アプリケーションサーバ１００は、ＵＰＦ２２１Ｂを介して端末装置４００Ｂと、端末装置４００Ａと同期させたデータの送受信を行う（ステップＳ３６）。

　このように、アプリケーションサーバ１００は、ＡＦ２４９、ＡＭＦ２４１を介して基地局装置３００にＣＤＲＸ設定を通知することで、端末装置４００に対してデータ送信のタイミングに応じたＣＤＲＸを設定することができる。これにより、アプリケーションサーバ１００は、複数の端末装置４００Ａ、４００Ｂに対して同期してデータを送信することができる。

　なお、ここでは、アプリケーションサーバ１００が、ＣＤＲＸの設定をリクエストするとしたが、これに限定されない。ＡＦ２４９がアプリケーションサーバ１００に代わり、ＣＤＲＸの設定をリクエストしてもよい。

　この場合、ＡＦ２４９は、アプリケーションサーバ１００から情報を受け取り、この情報に基づいてＣＤＲＸの設定をリクエストする。この情報には、例えば、データ送信の周期とＣＤＲＸの周期を同期させる端末装置４００を特定する情報や、データ送信の周期に関する情報（例えばフレームレート）等が含まれる。ＡＦ２４９は、情報を受信すると、この情報に応じてあらかじめ設定されたＣＤＲＸ設定をＡＭＦ２４１のＡＰＩを用いて通知する。

　ＡＦ２４９は、ＣＤＲＸ設定に加えて、アプリケーションサーバ１００からのデータをPushする機能を有していてもよい。換言すると、ＡＦ２４９が、Push　Notification　Serverであってもよい。

　一般的にPush　Notification　Serverは、Private　Networkを構成するＶＰＮ（virtual　Private　Network）外に設けられるが、本実施形態のように、Push　Notification　ServerがＣＤＲＸの設定を行う場合、Push　Notification　ServerはＶＰＮ内に配置することが望ましい。これは、Push　Notification　ServerがＡＭＦ２４１のＡＰＩを用いてＣＤＲＸ設定を行うためには、ＶＰＮ内に配置されることが望ましいためである。

　このように、ＡＦ２４９がＣＤＲＸ設定を行う場合、アプリケーションサーバ１００は、ＶＰＮ内に配置されてもよく、ＶＰＮ外に配置されてもよい。ＡＦ２４９がＣＤＲＸ設定を行うことで、アプリケーションサーバ１００は、ＣＤＲＸのことを意識せずに端末装置４００にサービスを提供することができる。

　また、図１２では、端末装置４００Ａ、４００Ｂがそれぞれ異なるPrivate　Networkに接続される場合について示したが、これに限定されない。端末装置４００Ａ、４００Ｂが同じPrivate　Networkに接続していてもよい。この場合、端末装置４００Ａ、４００Ｂは同じ基地局装置３００に属していてもよく、それぞれ別の基地局装置３００に属していてもよい。

　また、図１２では、ＣＤＲＸ設定のリクエストを受け付けるＡＰＩをＡＭＦ２４１に新たに設ける場合について示したが、これに限定されない。例えば、このＡＰＩを基地局装置３００に設けるようにしてもよい。この場合、ＡＦ２４９は、ＡＭＦ２４１を介さず基地局装置３００に対してＡＰＩを用いてＣＤＲＸ設定のリクエストを送信する。

　ここで、図１３を用いてＣＤＲＸ設定処理の詳細について説明する。図１３は、本開示の第１の実施形態に係るＣＤＲＸ設定処理の流れを説明するためのシーケンス図である。図１３では、複数の端末装置４００のうちの１つに対してＣＤＲＸ設定を設定する場合について示している。

　図１３では、まず、端末装置４００が無線ネットワークおよびコアネットワーク２００に接続される（ステップＳ１０１）。この際、ＳＭＦ２４２（図２参照）からＩＰアドレスが割り当てられる。

　次に、端末装置４００がＡＦ２４９に自身のＩＤを登録する（ステップＳ１０２）。この際、端末装置４００のＩＭＳＩもＡＦ２４９に登録される。次に、ＡＦ２４９がこのＩＤの登録の応答としてトークンを端末装置４００に送信する（ステップＳ１０３）。

　次に、端末装置４００は、トークンおよび自身のＩＤをアプリケーションサーバ１１０に送信する（ステップＳ１０４）。アプリケーションサーバ１１０は、端末装置４００のトークンおよびＩＤの登録を行う。

　ＡＦ２４９は、アプリケーションサーバ１１０との間において、ＴＣＰコネクションを確立する（ステップＳ１０５）。

　ＴＣＰ接続が確立すると、アプリケーションサーバ１００は、ＡＦ２４９に対してＣＤＲＸ設定要求を送信する（ステップＳ１０６）。なお、上述したように、ＡＦ２４９がアプリケーションサーバ１００に代わりＣＤＲＸ設定要求をＡＭＦ２４１に通知してもよい。この場合、アプリケーションサーバ１００は、ＣＤＲＸ設定要求の代わりに、ＣＤＲＸ設定要求に必要な情報をＡＦ２４９に通知することで、ＣＤＲＸ設定要求の送信をＡＦ２４９に要求する。

　ＡＦ２４９は、ＡＭＦ２４１に対して、ＡＭＦ２４１のＡＰＩを使用して、ＣＤＲＸ設定要求を通知する（ステップＳ１０７）。要求を受けたＡＭＦ２４１は、基地局装置３００に対して、ＣＤＲＸ設定要求を通知する（ステップＳ１０８）。

　要求を受けた基地局装置３００は、ＣＤＲＸ設定要求に従って、ＣＤＲＸの設定を行い、端末装置４００に対してＣＤＲＸを開始させる（ステップＳ１０９）。

　アプリケーションサーバ１００は、例えばAR/VR　videoである送信データをＡＦ２４９に送信する（ステップＳ１１０）。ＡＦ２４９は、受け取った送信データ（AR/VRコンテンツ）をＵＰＦ２２１にプッシュする（ステップＳ１１１）。ＵＰＦ２２１は、送信データ（AR/VRコンテンツ）を端末装置４００にプッシュする（ステップＳ１１２）。

　以降、アプリケーションサーバ１００は、同様にして、所定の周期（例えば、フレームレート）で送信データを端末装置４００にプッシュする。

　次に、図１４を用いて、ＡＦ２４９によるＣＤＲＸ設定要求処理の一例について説明する。図１４は、本開示の実施形態に係るＣＤＲＸ設定要求処理の流れの一例を示すシーケンス図である。

　ＡＦ２４９は、端末装置４００のＩＤを含めてＣＤＲＸ設定の要求をＡＭＦ２４１に通知する（ステップＳ２０１）。端末装置４００のＩＤとして、例えばＩＭＳＩ（）やＳＵＰＩが挙げられる。

　ＣＤＲＸ設定要求を受信したＡＭＦ２４１は、受信確認（acknowledge）をＡＦ２４９に応答する（ステップＳ２０２）。

　このように、ＡＦ２４９が、アプリケーションサーバ１００からの要求に応じてＣＤＲＸの設定を行うことで、アプリケーションサーバ１００から端末装置４００に送信するデータ（パケット）の遅延の揺らぎを小さくすることができる。

　＜＜４．第２の実施形態＞＞
　上記第１の実施形態のＣＤＲＸ設定処理で、アプリケーションサーバ１００が送信するデータの周期Ｔ１と、基地局装置３００が設定するＣＤＲＸの周期を合わせたとしても、遅延の揺らぎが発生する場合がある。この場合に発生する揺らぎを抑制する方法について第２の実施形態として説明する。まず、図１５を用いてこの場合に発生する遅延の揺らぎについて説明する。図１５は、本開示の第２の実施形態に係る遅延の揺らぎについて説明するための図である。

　図１５（ａ）では、アプリケーションサーバ１００が送信した映像データが基地局装置３００に到着するタイミングを示している。

　アプリケーションサーバ１００は、所定周期Ｔ１で例えば映像データを送信するが、上述したスイッチバッファ等の影響により、基地局装置３００に到達する映像データにはわずかに遅延の揺らぎが発生する場合がある。例えば、図１５（ａ）に示すように、基地局装置３００に映像データが到達してから次の映像データが到達するまでに周期Ｔ１より長い期間Ｔ２かかる場合がある。

　このスイッチバッファ等による遅延の揺らぎはわずかではあるが、端末装置４００によるデータの受信タイミングによっては、この遅延の揺らぎが大きくなってしまう場合がある。

　例えば、図１５（ｂ）に示すように、基地局装置３００が送信する映像データをOn　duration期間の終わり近くに受信する場合がある。この場合、映像データの到着タイミングの揺らぎにより、端末装置４００が映像データを受信するタイミングが次のOn　duration期間にずれてしまうことがある。なお、図１５（ｂ）では、端末装置４００によるＣＤＲＸタイミング及びPDCCH及びPDSCHの受信タイミングについて示している。

　このように、端末装置４００が間欠受信を行うタイミングと、基地局装置３００が映像データを端末装置４００に送信するタイミング（換言すると、映像データが基地局装置３００に到達するタイミング）によっては、遅延の揺らぎが大きくなる場合がある。より具体的には、端末装置４００が受信を行う期間（On　duration）のうち終わりの期間で映像データを受信すると、到達タイミングの揺らぎによって、遅延の揺らぎが大きくなる場合がある。

　そこで、図１６に示すように、本開示の第２の実施形態に係る通信システム１では、端末装置４００がOn　durationの終わりの期間を除く期間、換言すると所定期間より以前で映像データを受信するようにする。例えば、端末装置４００がOn　durationの中央あたりで映像データを受信すれば、到達タイミングが揺らいでも、端末装置４００は、On　durationの間に映像データを受信することができる。

　なお、図１６は、本開示の第２の実施形態に係る端末装置４００による映像データの受信タイミングを説明するための図である。図１６（ａ）では、アプリケーションサーバ１００が送信した映像データが基地局装置３００に到着するタイミングを示しており、図１６（ｂ）では、端末装置４００によるＣＤＲＸタイミング及びPDCCH及びPDSCHの受信タイミングについて示している。

　このように、端末装置４００がOn　durationのうちの所定期間より以前で映像データを受信する方法として、基地局装置３００が到着する映像データに応じて実装にてＣＤＲＸの設定を調整する方法が考えられる。

　しかしながら、基地局装置３００に到着するデータは、映像データだけでなく、他のトラフィックのデータも到着する。上述したように実装にてＣＤＲＸ設定を調整する方法では、基地局装置３００が到着するデータがアプリケーションサーバ１００からの映像データであるか否かを判定する必要があり、実現することは困難であると考えられる。

　そこで、本開示の第２の実施形態に係る通信システム１では、基地局装置３００が、例えばＡＦ２４９からの要求に応じて、ＣＤＲＸでの受信期間（On　duration）と、データの到着タイミングと、の関係をＡＦ２４９に通知する。

　図１７は、本開示の第２の実施形態に係る基地局装置３００が通知するデータの到着タイミングについて説明するための図である。

　図１７（ａ）は、基地局装置３００が送信するデータが端末装置４００に到着するタイミングを示している。図１７（ｂ）は、端末装置４００のＣＤＲＸについて示している。なお、図１７（ｂ）では、端末装置４００のDRX　CycleがOn　durationの３倍である場合について示している。

　図１７に示すように、基地局装置３００は、DRX　Cycleの先頭を０％、次のDRX　Cycleの先頭を３００％とし、０％からDRX　Cycleの末尾の２９９％のどの位置でデータが到達するか到達タイミングをＡＭＦ２４１に通知する。図１７の場合、０％から１００％までは、データがOn　durationの区間内に到達していることを示している。また、１０１％から２９９％までは、データがOn　durationの区間外に到達する、換言するとOn　durationの区間内に到達しないことを示している。

　基地局装置３００は、データの到達タイミング及び端末装置４００のＣＤＲＸ設定に基づき、何％の位置でデータが端末装置４００に到着するか算出し、算出結果をＡＭＦ２４１に通知する。

　この通知を基地局装置３００がＡＭＦ２４１に送信するためには、到着タイミングを判定するためのデータを基地局装置３００が特定する必要がある。基地局装置３００は、データをＩＰアドレス等で特定することはできないが、ＧＴＰ－トンネルのＩＤでデータを特定することはできる。

　そこで、ＡＭＦ２４１は、ＧＴＰ－トンネルのＩＤを指定して基地局装置３００にデータ到着タイミングの通知を要求する。より具体的には、ＡＭＦ２４１に対して、ＡＦ２４９は、データの宛先ＩＰアドレス（Destination　IP　Address）及びデータの送り元ＩＰアドレス（Source　IP　Address）を指定してデータ到着タイミングの通知を要求する。宛先ＩＰアドレスは、例えば端末装置４００のＩＰアドレスである。また、送り元ＩＰアドレスは、例えばＡＦ２４９のＩＰアドレスである。ＡＭＦ２４１は、これらＩＰアドレスに対応するＧＴＰ－トンネルのＩＤを特定し、当該ＧＴＰ－トンネルのＩＤを含むデータ到達タイミングの通知を基地局装置３００に要求する。

　基地局装置３００は、指定されたＧＴＰ－トンネルのＩＤで到達したデータの到着タイミングをＡＭＦ２４１に報告する。

　図１８は、本開示の第２の実施形態に係る到着タイミングの通知処理の流れの一例を説明するためのシーケンス図である。なお、図１３のシーケンス図と同じ処理については同じ符号を適用し、説明を省略する。

　ステップＳ１０５において、アプリケーションサーバ１００との間でＴＣＰ接続が確立したＡＦ２４９は、データの到達タイミングを測定するためのテストデータをＵＰＦ２２１経由で基地局装置３００に送信する（ステップＳ３０１）。

　また、基地局装置３００は、端末装置４００に対して、ＣＤＲＸの開始を指示する（ステップＳ３０２）。

　テストデータを送信したＡＦ２４９は、宛先である端末装置４００のＩＰアドレスと送り元である自装置のＩＰアドレスとを含むデータ到達タイミング要求をＡＭＦ２４１に送信する（ステップＳ３０３）。

　データ到達タイミング要求を受け取ったＡＭＦ２４１は、当該要求に含まれるＩＰアドレスからＧＴＰ－トンネルのＩＤを特定し、特定したＧＴＰ－トンネルのＩＤを含むデータ到達タイミング要求を基地局装置３００に送信する（ステップＳ３０４）。

　基地局装置３００は、ＣＤＲＸ設定と、テストデータの到達タイミングと、に基づき、DRX　Cycleのうちテストデータが到着する位置（パーセント）を含むデータ到着タイミング報告をＡＭＦ２４１に送信する（ステップＳ３０５）。ＡＭＦ２４１は、データ到着タイミング報告に基づき、データ到着タイミングの測定結果をＡＦ２４９に通知する（ステップＳ３０６）。

　ＡＦ２４９は、測定結果に基づき、アプリケーションサーバ１００から受信するユーザデータ（例えば、ＡＲ／ＶＲ映像データ）の到着タイミングを、On　durationの所望位置（例えば、所定期間より以前の区間）で端末装置４００に到達するよう調整する。ＡＦ２４９は、調整後のタイミングで、ユーザデータを、ＵＰＦ２２１及び基地局装置３００を介して端末装置４００に送信する（ステップＳ３０７）。

　なお、ＡＦ２４９は、例えば、DRX　Cycleの１０％から５０％の間でユーザデータが到達するように送信タイミングを調整することが望ましい（図１７参照）。ＡＦ２４９が、このように送信タイミングを調整することで、ユーザデータの到達タイミングに揺らぎが生じても端末装置４００は、所望のOn　duration区間でユーザデータを受信することができ、遅延の揺らぎをより抑制することができる。

　また、送信タイミングの調整は、周期的に送信されるパケット群（ユーザデータ）に対して１回行われるものとする。換言すると、図１８で例示した通知処理は、アプリケーションサーバ１００からユーザデータを送信するに先立って実行されるものとする。

　そのため、図１８において、ＣＤＲＸ設定は、テストデータ及びユーザデータ送信時とで変更されず、同じ設定が維持されたままとなる。あるいは、ＣＤＲＸ設定が変更になる度に、図１８に示す送信タイミングの調整が行われる。

　なお、ここでは、ＡＦ２４９がユーザデータの送信タイミングを調整するとしたが、これに限定されない。ユーザデータが所望のタイミングで端末装置４００に到着するように、基地局装置３００がＣＤＲＸ設定を調整するようにしてもよい。

　図１９は、本開示の第２の実施形態に係る到着タイミングの通知処理の流れの他の例を説明するためのシーケンス図である。なお、図１８のシーケンス図と同じ処理については同じ符号を適用し、説明を省略する。

　ステップＳ３０４において、データ到着タイミング要求を受信した基地局装置３００は、テストデータが到着したタイミングに応じてＣＤＲＸの設定を調整する（ステップＳ４０１）。

　調整が完了した基地局装置３００は、その旨を示すＡＣＫをＡＭＦ２４１に通知する（ステップＳ４０２）。ＡＣＫを受けたＡＭＦ２４１は、ＣＤＲＸ設定の調整が完了した旨を示すＡＣＫをＡＦ２４９に通知する（ステップＳ４０３）。

　その後、ＡＦ２４９は、アプリケーションサーバ１００から受け取ったユーザデータ（例えば、ＡＲ／ＶＲ映像データ）をＵＰＦ２２１及び基地局装置３００を介して端末装置４００に送信する（ステップＳ４０４）。

　このように、基地局装置３００がＣＤＲＸ設定を調整することでも、遅延の揺らぎをより抑制することができる。

　なお、ＣＤＲＸ設定の調整は、周期的に送信されるパケット群（ユーザデータ）に対して１回行われるものとする。換言すると、図１９で例示した通知処理は、アプリケーションサーバ１００からユーザデータを送信するに先立って実行されるものとする。

　そのため、図１９において、テストデータ及びユーザデータは、同じ周期を保って送信されるものとする。あるいは、データの送信周期が変更になる度に、ＣＤＲＸ設定の調整が行われる。また、テストデータは、周期的に複数回送信されるものとする。

　従来は、ＡＦ２４９は、基地局装置３００のＣＤＲＸ設定に関する情報を取得する手段が明確に定義されておらず、ＡＦ２４９は、ＣＤＲＸのどのタイミングでデータが到達するか知ることが難しかった。

　そこで、本開示の第２の実施形態では、コアネットワーク２００のＡＰＩ経由で、ＣＤＲＸ設定とデータの到着タイミングとの関係を報告するよう、ＡＦ２４９が基地局装置３００に要求することができるようにした。これにより、アプリケーション側が複数の端末装置４００間の遅延をより正確に調整することができるようになる。

　また、従来は、基地局装置３００は、ＡＦ２４９から送信されたデータを、ＩＰアドレスを用いて判別することが難しかったため、基地局装置３００は、どのタイミングでデータがＡＦ２４９から到着したか知ることが難しかった。

　そこで、本開示の第２の実施形態では、ＡＭＦ２４１が、ＧＴＰ－トンネルのＩＤを用いてＡＦ２４９が送信するデータを基地局装置３００が特定できるようにした。これにより、基地局装置３００は、ＡＦ２４９から送信されるデータの到着タイミングを知ることができ、到着タイミングに合わせてＣＤＲＸ設定を調整することができる。そのため、端末装置４００の遅延の揺らぎをより抑制することができる。

　＜＜５．第３の実施形態＞＞
　上記第１の実施形態のＣＤＲＸ設定処理では、複数の端末装置４００間でＣＤＲＸ設定（周期）を揃えることができるが、複数の端末装置４００がＣＤＲＸを開始するタイミングについては考慮されていなかった。そのため、複数の端末装置４００間でＣＤＲＸを開始するタイミングがずれる恐れがあった。

　ここで、図２０を用いて、ＣＤＲＸを開始するタイミングについて説明する。図２０は、ＣＤＲＸの開始タイミングについて説明するための図である。

　図２０に示す期間Ｔ１１において、端末装置４００は、サブフレーム（Sub　frame）単位でPDCCHをモニタする。一定期間（一定のサブフレーム数）、自装置宛ての送受信データがない場合、端末装置４００は、ＣＤＲＸを開始する。

　より具体的には、端末装置４００は、サブフレームのPDCCHをモニタして、自装置宛てのPDSCHが存在しなくなったタイミングからdrx-InactivityTimerをスタートし、自装置宛てのPDSCHが存在しない期間（サブフレーム数）を計測する。あるいは、端末装置４００は、サブフレームのPDCCHをモニタして、PDSCHがスケジューリングされなくなってから計測を開始してもよい。端末装置４００は、計測期間が所定期間を超えた場合に、間欠受信モードに移行し、ＣＤＲＸを開始する。

　図２０の例では、端末装置４００は、期間Ｔ１１でモニタした３つのサブフレームに自装置宛てのPDSCHが存在しなかった場合、次の期間Ｔ１２でＣＤＲＸを行う。図２０では、端末装置４００は、２つのサブフレームごとにPDCCHの受信と受信停止とを交互に繰り返し、On　durationの区間でPDCCHを受信して自装置宛てのPDSCHがないか確認を行う。

　ここで、端末装置４００は、複数のアプリケーションを実行している。そのため、端末装置４００とコアネットワーク２００との間には複数のセッションが確立され、アプリケーションサーバ１００以外の装置との間でトラフィックが発生する場合がある。

　したがって、同じアプリケーションサーバ１００から同じサービスの提供を受ける複数の端末装置４００が同じタイミングでＣＤＲＸを開始するとは限らない。例えば、図２０の期間Ｔ１１でアプリケーションサーバ１００以外の装置からのデータを受信した端末装置４００は、期間Ｔ１２からＣＤＲＸを開始しない。このように、従来の通信システムでは、ＣＤＲＸの開始タイミングを複数の端末装置４００で揃えることは困難であった。

　ＣＤＲＸの開始タイミングが異なると、例えば、一方の端末装置４００はＣＤＲＸを行っているのに対し、他方の端末装置４００はＣＤＲＸを行っていない状態があり得る。この場合、ＣＤＲＸを行っている端末装置４００と、行っていない端末装置４００と、でパケットの受信タイミングのばらつき具合が異なる可能性がある。

　例えば、ＣＤＲＸを行わず連続してPDCCH、PDSCHを受信する端末装置４００では、パケットの受信タイミングのばらつきが少ない。一方、ＣＤＲＸを実施し間欠受信を行っている端末装置４００では、パケットの受信タイミングのばらつきが大きい。

　上述したように、ＣＤＲＸの周期を設定することで、複数の端末装置４００のＣＤＲＸ周期を揃えることができる。しかしながら、ＣＤＲＸを開始するタイミングが複数の端末装置４００で異なると、先にＣＤＲＸを開始した端末装置４００と、後からＣＤＲＸを開始した端末装置４００との間で遅延の揺らぎ具合が大きく異なる場合がある。

　例えば、図２０において、時刻Ｔ１０でＣＤＲＸを開始した端末装置４００は、時刻Ｔ１０で自装置宛てのパケットがあっても次にon　durationになるまでパケットを受信できない。一方、時刻Ｔ１０ではＣＤＲＸを開始しなかった端末装置４００は、時刻Ｔ１０の次のサブフレームで自装置宛てのパケットを受信することができる。

　このように、ＣＤＲＸを開始するタイミングが異なると、ＣＤＲＸの周期が同じであっても、複数の端末装置４００がパケットを受信するタイミングがそれぞれ異なる恐れがあり、遅延の揺らぎの影響が大きくなる可能性がある。

　このように、端末装置４００が複数のアプリケーションを実行している場合、遅延の揺らぎの影響を受けるアプリケーション（アプリケーションサーバ１００が提供するアプリケーション）と、その他のアプリケーションを分離する。アプリケーションを分離することで、特定のアプリケーションからデータを受信する複数の端末装置４００のＣＤＲＸ開始タイミングを揃える。

　例えば、４Ｇや５ＧのＬＴＥでは、１台の端末装置４００が複数のComponent　Carrier（ＣＣ）を使用することができる。また、５Ｇでは、１つのComponent　Carrierの中で複数のＢＷＰ（Band　width　Part）を使用することができる。そこで、端末装置４００が、アプリケーションごとにそれぞれ異なるＣＣあるいはＢＷＰを使用するようにする。

　これにより、特定のＣＣ又はＢＷＰのＣＤＲＸは、実際のトラフィック発生タイミングに応じて開始されるのではなく、基地局装置３００の指示に基づいて開始させることができる。すなわち、基地局装置３００は、アプリケーションサーバ１００との通信に使用するＣＣ又はＢＰＷを決定し、当該ＣＣ又はＢＰＷでは、ＣＤＲＸの開始又は終了タイミングを含めてＣＤＲＸ設定を行うものとする。なお、ＣＤＲＸ設定は、例えばアプリケーションサーバ１００又はＡＦ２４９からの指示に基づいて行われる。アプリケーションサーバ１００又はＡＦ２４９は、ＡＰＩを用いて、ＡＭＦ２４１を介して基地局装置３００に指示する。

　例えば、ＡＦ２４９またはアプリケーションサーバ１００は、サービス提供の開始において、サービスを同時に受ける複数の端末装置４００に対して、同じタイミングでＣＤＲＸが開始されるように、ＣＤＲＸ開始を基地局装置３００に要求する。この要求は、複数の端末装置４００が接続する複数のコアネットワーク２００に対してそれぞれ行われる。

　より具体的には、コアネットワーク２００のＡＭＦ２４１に新しいＡＰＩを用意し、ＡＦ２４９は、このＡＰＩを使用してＣＤＲＸ開始を要求する。

　なお、ここでは、複数の端末装置４００が接続する複数のコアネットワーク２００は、互いにフレーム同期が取れているものとする。すなわち、同じPrivate　Networkに属する複数の基地局装置３００間でフレーム同期が取れていることはもちろん、それぞれ異なるPrivate　Networkに属する基地局装置３００間でもフレーム同期が取れているものとする。

　セルラーネットワークでは、通常１０ｍｓのフレームで構成されている。このフレームにはSystem　Frame　Numberという番号が付与される。System　Frame　Numberは、最大１０２４で、System　Frame　Numberが１０２４のフレームの次のフレームには１のSystem　Frame　Numberが付与される。

　フレーム同期が取れている場合、複数の基地局装置３００は、同じタイミングで同じSystem　Frame　Numberが付与されたフレームを使用して通信を行う。そのため、複数の基地局間でフレーム同期が取れていれば、ＡＦ２４９が、どのサブフレームからＣＤＲＸを開始するか指定することで、複数の基地局装置３００は、同じタイミングでＣＤＲＸを開始するようにＣＤＲＸを設定することができる。

　一般的に、異なるPrivate　Networkに属する基地局装置３００間でフレーム同期を取ることはないが、既存の技術を使用することで、実装上、異なるPrivate　Networkに属する基地局装置３００間でもフレーム同期は取り得る。

　図２１及び図２２を用いて、ＡＦ２４９がＣＤＲＸの開始タイミングを指示する処理（以下、ＣＤＲＸ同期処理とも称する）の一例について説明する。図２１及び図２２は、本開示の第３の実施形態に係るＣＤＲＸ同期処理の流れの一例を説明するための図である。

　図２１に示すように、アプリケーションサーバ１００からサービス提供（例えばゲーム）開始の通知を受けたＡＦ２４９Ａは、ＡＭＦ２４１Ａに対してＡＰＩを用いてＣＤＲＸの開始を要求する（ステップＳ４１）。また、ＡＭＦ２４１Ａは、例えば、アプリケーションサーバ１００が通知するゲーム開始タイミングからあらかじめ決められた手順でＣＤＲＸの開始タイミングを算出し、ＣＤＲＸの開始を要求する。ＡＦ２４９Ａは、ＣＤＲＸの開始タイミングに合わせてＣＤＲＸ開始要求をＡＭＦ２４１Ａに通知してもよく、あるいは、ＣＤＲＸの開始タイミングを含めてＣＤＲＸ開始要求を通知してもよい。

　ＣＤＲＸ開始要求を受信したＡＭＦ２４１Ａは、ＣＤＲＸ開始タイミングでＣＤＲＸを開始するよう基地局装置３００Ａに通知する（ステップＳ４２）。これを受けた基地局装置３００Ａは、端末装置４００Ａに対してＣＤＲＸ開始タイミングからＣＤＲＸを開始するよう設定する。

　以降、アプリケーションサーバ１００と端末装置４００Ａとの間で、ＡＦ２４９Ａ、ＵＰＦ２２１Ａ及び基地局装置３００Ａを介し、ＣＤＲＸでの通信が行われる（ステップＳ４３）。

　また、同様にして、アプリケーションサーバ１００からサービス提供（例えばゲーム）開始の通知を受けたＡＦ２４９Ｂは、ＡＭＦ２４１Ｂに対してＡＰＩを用いてＣＤＲＸの開始を要求する（ステップＳ４４）。また、ＡＭＦ２４１Ｂは、例えば、アプリケーションサーバ１００が通知するゲーム開始タイミングからあらかじめ決められた手順でＣＤＲＸの開始タイミングを算出し、ＣＤＲＸの開始を要求する。ＡＦ２４９Ｂは、ＣＤＲＸの開始タイミングに合わせてＣＤＲＸ開始要求をＡＭＦ２４１Ｂに通知してもよく、あるいは、ＣＤＲＸの開始タイミングを含めてＣＤＲＸ開始要求を通知してもよい。

　ＣＤＲＸ開始要求を受信したＡＭＦ２４１Ｂは、ＣＤＲＸ開始タイミングでＣＤＲＸを開始するよう基地局装置３００Ｂに通知する（ステップＳ４５）。これを受けた基地局装置３００Ｂは、端末装置４００Ｂに対してＣＤＲＸ開始タイミングからＣＤＲＸを開始するよう設定する。

　以降、アプリケーションサーバ１００と端末装置４００Ｂとの間で、ＡＦ２４９Ｂ、ＵＰＦ２２１Ｂ及び基地局装置３００Ｂを介し、ＣＤＲＸでの通信が行われる（ステップＳ４６）。

　基地局装置３００Ａが属するPrivate　Networkと、基地局装置３００Ｂが属するPrivate　Networkとの間で、フレーム同期が取れている。従って、ＡＦ２４９Ａ、２４９Ｂは、同じＣＤＲＸ開始タイミングでＣＤＲＸを開始するようにＡＭＦ２４１を介して基地局装置３００に指示することができる。

　なお、ＡＦ２４９は、ＣＤＲＸ開始要求に、上述したＣＤＲＸ周期に関する設定を含めてもよい。すなわち、ＡＦ２４９がＣＤＲＸ開始タイミング及びＣＤＲＸ周期の両方を設定するようにＡＭＦ２４１を介して基地局装置３００に要求するようにしてもよい。

　次に、図２２を用いてＡＦ２４９がＣＤＲＸを終了するタイミングを設定する場合について説明する。

　図２２に示すように、アプリケーションサーバ１００からサービス提供（例えばゲーム）終了の通知を受けたＡＦ２４９Ａは、ＡＭＦ２４１Ａに対してＡＰＩを用いてＣＤＲＸの終了を要求する（ステップＳ４７）。

　ＣＤＲＸ終了要求を受信したＡＭＦ２４１Ｂは、ＣＤＲＸ終了タイミングでＣＤＲＸを終了するよう基地局装置３００Ｂに通知する（ステップＳ４８）。これを受けた基地局装置３００Ａは、端末装置４００Ｂに対してＣＤＲＸ終了タイミングでＣＤＲＸを終了するよう設定する。

　また、同様にして、アプリケーションサーバ１００からサービス提供（例えばゲーム）終了の通知を受けたＡＦ２４９Ｂは、ＡＭＦ２４１Ｂに対してＡＰＩを用いてＣＤＲＸの終了を要求する（ステップＳ４９）。

　ＣＤＲＸ終了要求を受信したＡＭＦ２４１Ｂは、ＣＤＲＸ終了タイミングでＣＤＲＸを終了するよう基地局装置３００Ｂに通知する（ステップＳ４５）。これを受けた基地局装置３００Ｂは、端末装置４００Ｂに対してＣＤＲＸ終了タイミングでＣＤＲＸを終了するよう設定する。

　これにより、端末装置４００Ａ、４００Ｂが同じＣＤＲＸ終了タイミングで、ＣＤＲＸを終了することができる。

　このように、ＣＤＲＸを開始するタイミングをＡＦ２４９が決定した場合は、ＡＦ２４９がＣＤＲＸを終了するタイミングも指示する。これにより、基地局装置３００は、アプリケーションサーバ１００によるサービス提供が終了した場合に、通常の通信に戻ることができる。

　以上の様に、ＡＦ２４９が、ＣＤＲＸの開始タイミング及び終了タイミングを、ＡＰＩを用いて制御することができる。これにより、アプリケーションサーバ１００は、異なるPrivate　Networkに属する複数の端末装置４００に対して、遅延の揺らぎを抑えてデータ（例えばＡＲ／ＶＲ映像データ）を届けることができる。

　また、Uplinkにおいても、異なるPrivate　Networkに属する複数の端末装置４００からアプリケーションサーバ１００に届くデータの遅延の揺らぎをより抑制することができるようになる。

　これにより、異なるPrivate　Networkに属する複数の端末装置４００を連携して動作させることもできるようになる。

　＜＜６．第４の実施形態＞＞
　上記第１～第３の実施形態では、主にLong　DRXの場合を例に、ＡＦ２４９がＣＤＲＸの設定を行う方法について説明したが、ＣＤＲＸには、Long　DRXとShort　DRXの２つが含まれる。Short　DRXは、Long　DRXと比較して、PDCCHを間欠的にモニタする周期（ＣＤＲＸ周期）が短い。端末装置４００は、ＣＤＲＸを開始する場合、まずShort　DRXを行い、所定期間自装置宛ての送受信パケットがない場合にShort　DRXからLong　DRXに移行する。

　上述したように、ＣＤＲＸを複数の端末装置４００で揃えるには、ＣＤＲＸ開始タイミングだけでなく、Short　DRX、Long　DRXのタイミング、換言するとShort　DRXからLong　DRXに切り替わるタイミングを揃える必要がある。

　そこで、本開示の第４の実施形態では、ＡＦ２４９が指示したＣＤＲＸ開始タイミングでＣＤＲＸが開始された後、ＡＦ２４９は、Short　DRX及びLong　DRXの切り替えを、ＡＰＩを用いて行う。

　図２３を用いて、ＡＦ２４９がＣＤＲＸの切り替えを指示する処理（以下、切り替え処理とも称する）の一例について説明する。図２３は、本開示の第４の実施形態に係る切り替え処理の流れの一例を説明するための図である。

　図２３に示すように、アプリケーションサーバ１００からの通知に基づき、ＡＦ２４９Ａは、ＡＭＦ２４１Ａに対してＡＰＩを用いて切り替えタイミングでShort　DRXからLong　DRXへ切り替えるように要求する（ステップＳ５１）。アプリケーションサーバ１００からの通知には、例えば、一定期間データの送信を中断する旨の通知や、フレームレートを下げる通知が含まれる。

　切り替え要求を受信したＡＭＦ２４１Ａは、切り替えタイミングでＣＤＲＸをShort　DRXからLong　DRXへ切り替えるように基地局装置３００Ａに通知する（ステップＳ５２）。これを受けた基地局装置３００Ａは、端末装置４００Ａに対して切り替えタイミングでShort　DRXからLong　DRXへ切り替えるように設定する。

　また、同様にして、アプリケーションサーバ１００からの指示に基づき、ＡＦ２４９Ｂは、ＡＭＦ２４１Ｂに対してＡＰＩを用いて切り替えタイミングでShort　DRXからLong　DRXへ切り替えるように要求する（ステップＳ５３）。アプリケーションサーバ１００からの通知には、例えば、一定期間データの送信を中断する旨の通知や、フレームレートを下げる通知が含まれる。

　切り替え要求を受信したＡＭＦ２４１Ｂは、切り替えタイミングでＣＤＲＸをShort　DRXからLong　DRXへ切り替えるように基地局装置３００Ｂに通知する（ステップＳ５３）。これを受けた基地局装置３００Ｂは、端末装置４００Ｂに対して切り替えタイミングでShort　DRXからLong　DRXへ切り替えるように設定する。

　以上の様に、ＡＦ２４９が、Short　DRX及びLong　DRXの切り替えタイミングを、ＡＰＩを用いて制御することができる。これにより、アプリケーションサーバ１００は、異なるPrivate　Networkに属する複数の端末装置４００に対して、遅延の揺らぎを抑えてデータ（例えばＡＲ／ＶＲ映像データ）を届けることができる。

　また、Uplinkにおいても、異なるPrivate　Networkに属する複数の端末装置４００からアプリケーションサーバ１００に届くデータの遅延の揺らぎをより抑制することができるようになる。

　これにより、異なるPrivate　Networkに属する複数の端末装置４００を連携して動作させることもできるようになる。

　なお、ここでは、アプリケーションサーバ１００からの通知にしたがい、ＡＦ２４９がShort　DRX及びLong　DRXの切り替え制御を行うとしたが、これに限定されない。例えば、ＡＦ２４９が端末装置４００宛てのデータをモニタし、一定期間端末装置４００宛てのデータがなければ切り替え制御を行うようにしてもよい。

　＜＜７．変形例＞＞
　上述した各実施形態に係る処理は、上記各実施形態にも種々の異なる形態（変形例）にて実施されてよい。

　上記実施形態では、ＡＦ２４９がＣＤＲＸに関する制御（例えばＣＤＲＸ周期の設定等）を行うとしたが、これに限定されない。例えば、Private　Networkの外側に配置されるエンティティがＣＤＲＸに関する制御を行うようにしてもよい。このエンティティは、アプリケーションサーバ１００であってもよく、アプリケーションサーバ１００とは異なるエンティティであってもよい。

　ＡＦ２４９は、Private　Networkの内側に配置されるため、同じPrivate　Networkに属するＡＭＦ２４１のＡＰＩに直接アクセスし得る。しかしながら、Private　Networkの外側に配置されるエンティティがＣＤＲＸに関する指示をＡＭＦ２４１に行う場合、直接ＡＭＦ２４１のＡＰＩに接続できない。そこで、この場合は、Private　Networkの外側に配置されるエンティティが、例えばＮＥＦ２４５のＡＰＩのGatewayを介してＡＭＦ２４１のＡＰＩに接続するようにしてもよい。

　また、本実施形態の端末装置４００、基地局装置３００、又は、情報処理装置２６０を制御する制御装置は、専用のコンピュータシステムで実現してもよいし、汎用のコンピュータシステムで実現してもよい。

　例えば、上述の動作を実行するためのプログラムを、光ディスク、半導体メモリ、磁気テープ、フレキシブルディスク等のコンピュータ読み取り可能な記録媒体に格納して配布する。そして、例えば、該プログラムをコンピュータにインストールし、上述の処理を実行することによって制御装置を構成する。このとき、制御装置は、端末装置４００、基地局装置３００、又は、情報処理装置２６０の外部の装置（例えば、パーソナルコンピュータ）であってもよい。また、制御装置は、端末装置４００、基地局装置３００、又は、情報処理装置２６０の内部の装置（例えば、制御部４５０、制御部３４０、又は制御部２６３）であってもよい。

　また、上記通信プログラムをインターネット等のネットワーク上のサーバ装置が備えるディスク装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。また、上述の機能を、ＯＳ（Operating　System）とアプリケーションソフトとの協働により実現してもよい。この場合には、ＯＳ以外の部分を媒体に格納して配布してもよいし、ＯＳ以外の部分をサーバ装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。

　また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

　また、上記してきた実施形態は、処理内容を矛盾させない領域で適宜組み合わせることが可能である。また、本実施形態のシーケンス図或いはフローチャートに示された各ステップは、適宜順序を変更することが可能である。

　また、例えば、本実施形態は、装置またはシステムを構成するあらゆる構成、例えば、システムＬＳＩ（Large　Scale　Integration）等としてのプロセッサ、複数のプロセッサ等を用いるモジュール、複数のモジュール等を用いるユニット、ユニットにさらにその他の機能を付加したセット等（すなわち、装置の一部の構成）として実施することもできる。

　なお、本実施形態において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。例えば、別個の筐体に収納され、ネットワーク等を介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。

　また、例えば、本実施形態は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

　（効果）
　本開示の情報処理装置２６０（ＡＦ２４９、ＡＭＦ２４１）は、制御部２６３を備える。制御部２６３は、端末装置４００にアプリケーション機能を提供する装置（アプリケーションサーバ１００）から情報を取得する。制御部２６３は、取得した情報に基づき、端末装置４００の間欠受信に関する設定情報を、端末装置４００と通信を行う基地局装置３００にＡＰＩを用いて通知する。

　これにより、遅延の揺らぎをより抑制することができる。

　また、制御部２６３は、基地局装置３００が接続するコアネットワーク２００に属し、ＮＦの機能を有する装置（ＡＭＦ２４１）を介して設定情報を基地局装置３００に通知してもよい。

　これにより、ＡＦ２４９によって遅延の揺らぎを抑制することができる。

　また、情報処理装置２６０は、アクセス制御に関する機能を有してもよい。

　これにより、ＡＭＦ２４１によって遅延の揺らぎを抑制することができる。

　また、設定情報は、間欠受信の受信周期に関する周期情報を含んでいてよい。

　これにより、情報処理装置２６０が間欠受信の受信周期を設定することができる。

　また、設定情報は、間欠受信を開始するタイミングに関する開始タイミング情報を含んでいてよい。

　これにより、情報処理装置２６０が間欠受信の開始タイミングを設定することができる。

　また、設定情報は、間欠受信を終了するタイミングに関する終了タイミング情報を含んでいてよい。

　これにより、情報処理装置２６０が間欠受信の終了タイミングを設定することができる。

　また、設定情報は、間欠受信の受信周期（Short　DRX／Long　DRX）を切り替えるタイミングに関する切り替えタイミングを含んでいてよい。

　これにより、情報処理装置２６０が間欠受信の受信周期を切り替えるタイミングを設定することができる。

　また、制御部２６３は、間欠受信の受信期間において、装置（アプリケーションサーバ１００）が送信するデータを端末装置４００が受信する受信タイミングに関する受信タイミング情報を基地局装置３００から受信してもよい。

　これにより、端末装置４００が所望の受信タイミングでデータを受信するようデータの送信タイミングを調整することができる。

　また、制御部２６３は、受信タイミングを測定するためのテストデータを基地局装置３００に送信してもよい。

　これにより、テストデータに基づいて受信タイミングを測定することができる。

　また、制御部２６３は、受信タイミング情報に基づき、端末装置４００が受信期間において所定期間より前でデータを受信するように、送信タイミングを調整して、当該データを送信してもよい。

　これにより、端末装置４００は、所望のタイミングでデータを受信することができる。

　また、制御部２６３は、装置（アプリケーションサーバ１００）が送信するデータの端末装置４００での受信タイミングが、間欠受信の受信期間において所定期間より前になるように受信期間の調整を基地局装置３００に要求し、受信期間の調整を行うためのテストデータを送信してもよい。

　これにより、基地局装置３００は、テストデータを用いて間欠受信の受信期間の調整を行うことができる。

　また、装置（アプリケーションサーバ１００）から取得する情報は、それぞれ異なるコアネットワークに接続する複数の端末装置４００に関する情報を含んでよく、制御部２６３は、複数の端末装置４００のうち、自装置が属するコアネットワーク２００と接続する端末装置４００の設定情報を当該端末装置４００と通信を行う基地局装置３００に通知してもよい。

　これにより、異なるコアネットワーク２００に属する複数の端末装置４００を連携して動作させることができる。

　また、本開示の情報処理装置（アプリケーションサーバ１００）は、制御部を備える。制御部は、アプリケーション機能を提供する端末装置４００に関する情報を、端末装置４００が接続するコアネットワーク２００に属するエンティティ（ＡＦ２４９、ＡＭＦ２４１）に通知する。当該情報は、エンティティ（ＡＦ２４９、ＡＭＦ２４１）による端末装置４００の間欠受信の設定に使用される。

　これにより、遅延の揺らぎを抑制することができる。

　また、本開示の基地局装置３００は、制御部３４０を備える。制御部３４０は、端末装置４００にアプリケーション機能を提供する装置（アプリケーションサーバ１００）からの情報に基づいてコアネットワーク２００に属するエンティティ（ＡＦ２４９、ＡＭＦ２４１）から送信される設定情報であって、端末装置の間欠受信に関する設定情報を受信する。制御部３４０は、設定情報に基づき、端末装置４００に対して間欠受信の設定を行う。

　これにより、遅延の揺らぎを抑制することができる。

　また、本開示の通信方法は、端末装置４００にアプリケーション機能を提供する装置（アプリケーションサーバ１００）から情報を取得し、当該情報に基づき、端末装置４００の間欠受信に関する設定情報を、端末装置４００と通信を行う基地局装置３００にＡＰＩを用いて通知する。

　これにより、遅延の揺らぎを抑制することができる。

　また、本開示の通信システム１は、端末装置４００と通信を行う基地局装置３００と、情報処理装置２６０（ＡＦ２４９、ＡＭＦ２４１）と、アプリケーション機能を提供する装置（アプリケーションサーバ１００）と、を備える通信システムであって、情報処理装置２６０は、アプリケーション機能を提供する装置から情報を取得し、当該情報に基づき、端末装置４００の間欠受信に関する設定情報を、基地局装置３００にＡＰＩを用いて通知する制御部を備える。

　これにより、遅延の揺らぎを抑制することができる。

　以上、本開示の各実施形態について説明したが、本開示の技術的範囲は、上述の各実施形態そのままに限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、異なる実施形態及び変形例にわたる構成要素を適宜組み合わせてもよい。

　また、本明細書に記載された効果はあくまで例示であって限定されるものでは無く、他の効果があってもよい。

　なお、本技術は以下のような構成も取ることができる。
（１）
　端末装置にアプリケーション機能を提供する装置から情報を取得し、
　前記情報に基づき、前記端末装置の間欠受信に関する設定情報を、アプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて前記端末装置と通信を行う基地局装置に通知する、制御部
　を備える情報処理装置。
（２）
　前記制御部は、前記基地局装置が接続するコアネットワークに属し、ネットワーク・ファンクション（ＮＦ：Network　Function）に記載の機能を有する装置を介して前記設定情報を基地局装置に通知する、（１）に記載の情報処理装置。
（３）
　前記情報処理装置は、アクセス制御に関する機能を有する、（１）に記載の情報処理装置。
（４）
　前記設定情報は、前記間欠受信の受信周期に関する周期情報を含む、（１）～（３）のいずれか１つに記載の情報処理装置。
（５）
　前記設定情報は、前記間欠受信を開始するタイミングに関する開始タイミング情報を含む、（１）～（４）のいずれか１つに記載の情報処理装置。
（６）
　前記設定情報は、前記間欠受信を終了するタイミングに関する終了タイミング情報を含む、（１）～（５）のいずれか１つに記載の情報処理装置。
（７）
　前記設定情報は、前記間欠受信の受信周期を切り替えるタイミングに関する切り替えタイミング情報を含む、（１）～（６）のいずれか１つに記載の情報処理装置。
（８）
　前記制御部は、前記間欠受信の受信期間において、前記装置が送信するデータの受信タイミングに関する受信タイミング情報を前記基地局装置から受信する、（１）～（７）のいずれか１つに記載の情報処理装置。
（９）
　前記制御部は、前記受信タイミングを測定するためのテストデータを前記基地局装置に送信する、（８）に記載の情報処理装置。
（１０）
　前記制御部は、前記受信タイミング情報に基づき、前記端末装置が前記受信期間において所定期間より前で前記データを受信するように、送信タイミングを調整して、当該データを送信する、（８）又は（９）に記載の情報処理装置。
（１１）
　前記制御部は、
　前記装置が送信するデータの端末装置での受信タイミングが、前記間欠受信の受信期間において所定期間より前になるように前記受信期間の調整を前記基地局装置に要求し、
　前記受信期間の前記調整を行うためのテストデータを送信する、
　（１）～（７）のいずれか１つに記載の情報処理装置。
（１２）
　前記情報は、それぞれ異なるコアネットワークに接続する複数の端末装置に関する情報を含み、
　前記制御部は、前記複数の端末装置のうち、自装置が属する前記コアネットワークと接続する前記端末装置の前記設定情報を当該端末装置と通信を行う前記基地局装置に通知する、
　（１）～（１１）のいずれか１つに記載の情報処理装置。
（１３）
　アプリケーション機能を提供する端末装置に関する情報を、前記端末装置が接続するコアネットワークに属するエンティティに通知する、制御部、
　を備え、
　前記情報は、前記エンティティによる前記端末装置の間欠受信の設定に使用される、
　情報処理装置。
（１４）
　端末装置にアプリケーション機能を提供する装置からの情報に基づいてコアネットワークに属するエンティティから送信され、前記端末装置の間欠受信に関する設定情報を受信し、
　前記設定情報に基づき、前記端末装置に対して前記間欠受信の設定を行う、制御部、
　を備える基地局装置。
（１５）
　端末装置にアプリケーション機能を提供する装置から情報を取得し、
　前記情報に基づき、前記端末装置の間欠受信に関する設定情報を、アプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて前記端末装置と通信を行う基地局装置に通知する、
　通信方法。
（１６）
　端末装置と通信を行う基地局装置と、情報処理装置と、アプリケーション機能を提供する装置と、を備える通信システムであって、
　前記情報処理装置は、
　前記アプリケーション機能を提供する装置から情報を取得し、
　前記情報に基づき、前記端末装置の間欠受信に関する設定情報を、前記基地局装置にアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて通知する、制御部、
　を備える通信システム。

　　　１　通信システム
　１００　アプリケーションサーバ（情報処理装置）
　２００、２００Ａ、２００Ｂ　コアネットワーク
　２４１　ＡＭＦ
　２４９　ＡＦ
　３００、３００Ａ、３００Ｂ　基地局装置
　４００、４００Ａ、４００Ｂ　端末装置

Claims (16)

1. 　端末装置にアプリケーション機能を提供する装置から情報を取得し、
   　前記情報に基づき、前記端末装置の間欠受信に関する設定情報を、前記端末装置と通信を行う基地局装置にアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて通知する、制御部、
   　を備える情報処理装置。
2. 　前記制御部は、前記基地局装置が接続するコアネットワークに属し、ネットワーク・ファンクション（ＮＦ：Network　Function）の機能を有する装置を介して前記設定情報を基地局装置に通知する、請求項１に記載の情報処理装置。
3. 　前記情報処理装置は、アクセス制御に関する機能を有する、請求項１に記載の情報処理装置。
4. 　前記設定情報は、前記間欠受信の受信周期に関する周期情報を含む、請求項１に記載の情報処理装置。
5. 　前記設定情報は、前記間欠受信を開始するタイミングに関する開始タイミング情報を含む、請求項１に記載の情報処理装置。
6. 　前記設定情報は、前記間欠受信を終了するタイミングに関する終了タイミング情報を含む、請求項１に記載の情報処理装置。
7. 　前記設定情報は、前記間欠受信の受信周期を切り替えるタイミングに関する切り替えタイミング情報を含む、請求項１に記載の情報処理装置。
8. 　前記制御部は、前記間欠受信の受信期間において、前記装置が送信するデータを前記端末装置が受信する受信タイミングに関する受信タイミング情報を前記基地局装置から受信する、請求項１に記載の情報処理装置。
9. 　前記制御部は、前記受信タイミングを測定するためのテストデータを前記基地局装置に送信する、請求項８に記載の情報処理装置。
10. 　前記制御部は、前記受信タイミング情報に基づき、前記端末装置が前記受信期間において所定期間より前で前記データを受信するように、送信タイミングを調整して、当該データを送信する、請求項８に記載の情報処理装置。
11. 　前記制御部は、
    　前記装置が送信するデータの端末装置での受信タイミングが、前記間欠受信の受信期間において所定期間より前になるように前記受信期間の調整を前記基地局装置に要求し、
    　前記受信期間の前記調整を行うためのテストデータを送信する、
    　請求項１に記載の情報処理装置。
12. 　前記情報は、それぞれ異なるコアネットワークに接続する複数の端末装置に関する情報を含み、
    　前記制御部は、前記複数の端末装置のうち、自装置が属する前記コアネットワークと接続する前記端末装置の前記設定情報を当該端末装置と通信を行う前記基地局装置に通知する、
    　請求項１に記載の情報処理装置。
13. 　アプリケーション機能を提供する端末装置に関する情報を、前記端末装置が接続するコアネットワークに属するエンティティに通知する、制御部、
    　を備え、
    　前記情報は、前記エンティティによる前記端末装置の間欠受信の設定に使用される、
    　情報処理装置。
14. 　端末装置にアプリケーション機能を提供する装置からの情報に基づいてコアネットワークに属するエンティティから送信される設定情報であって、前記端末装置の間欠受信に関する前記設定情報を受信し、
    　前記設定情報に基づき、前記端末装置に対して前記間欠受信の設定を行う、制御部、
    　を備える基地局装置。
15. 　端末装置にアプリケーション機能を提供する装置から情報を取得し、
    　前記情報に基づき、前記端末装置の間欠受信に関する設定情報を、前記端末装置と通信を行う基地局装置にアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて通知する、
    　通信方法。
16. 　端末装置と通信を行う基地局装置と、情報処理装置と、アプリケーション機能を提供する装置と、を備える通信システムであって、
    　前記情報処理装置は、
    　前記アプリケーション機能を提供する装置から情報を取得し、
    　前記情報に基づき、前記端末装置の間欠受信に関する設定情報を、前記基地局装置にアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application　Programming　Interface）を用いて通知する、制御部、
    　を備える通信システム。

Images