(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-11
(45)【発行日】2024-11-19
(54)【発明の名称】通信システム、通信制御方法、及びプログラム
(51)【国際特許分類】
H04W 72/12 20230101AFI20241112BHJP
H04W 28/02 20090101ALI20241112BHJP
H04W 24/08 20090101ALI20241112BHJP
【ＦＩ】
H04W72/12
H04W28/02
H04W24/08
【請求項の数】
7
(21)【出願番号】P 2021048477
(22)【出願日】2021-03-23
(65)【公開番号】P2022147296
(43)【公開日】2022-10-06
【審査請求日】2023-12-28
【国等の委託研究の成果に係る記載事項】（出願人による申告）令和２年度、総務省、「ＩｏＴ機器増大に対応した有無線最適制御型電波有効利用基盤技術の研究開発」委託研究、産業技術力強化法第１７条の適用を受ける特許出願
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001678
【氏名又は名称】藤央弁理士法人
(72)【発明者】
【氏名】桑原 幹夫
【審査官】山中 実
(56)【参考文献】
【文献】特開２０１９－１３５５７８（ＪＰ，Ａ）
【文献】特表２０１８－５２４８８２（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｗ ７２／１２
Ｈ０４Ｗ ２８／０２
Ｈ０４Ｗ ２４／０８
(57)【特許請求の範囲】
【請求項1】
通信システムであって、１以上のＩｏＴ端末と、
前記ＩｏＴ端末が接続する基地局装置と、
前記基地局装置が送受信するユーザプレーンのパケットを選択的に受信するエッジサーバと、
前記基地局装置又は前記エッジサーバが送受信するユーザプレーンのパケットを選択的に受信するクラウドサーバと、を備え、
前記ＩｏＴ端末、前記エッジサーバ又は前記クラウドサーバの少なくとも一つにはソフトウェアで構成される第１のミドルウェアが配置されており、
前記エッジサーバにはソフトウェアで構成される第２のミドルウェア及び第３のミドルウェアが配置されており、
前記第３のミドルウェアは、前記ＩｏＴ端末、前記エッジサーバ及び前記クラウドサーバの少なくとも一つから伝送されるパケットを捕捉し、前記捕捉されたパケットからトラヒックを分析し、前記分析の結果を前記第２のミドルウェアに提供し、
前記第２のミドルウェアは、前記通信システムで伝送されるパケットの分析の結果に基づいて、ユーザが設定するポリシーに従って、パケットの送信タイミングに関する制御ポリシーを作成し、前記作成された制御ポリシーを前記第１のミドルウェアに指示し、
前記第１のミドルウェアは、
前記ポリシーの指示を前記第２のミドルウェアから受け、
前記クラウドサーバで動作するアプリケーションから送信されるパケットの送信指示を代理で受信し、
前記指示されたポリシーに従ってパケットの送信タイミングを調整し、
前記エッジサーバの通信モジュールへ、前記調整された送信タイミングで前記パケットを送信する送信指示を中継することを特徴とする通信システム。
【請求項2】
請求項１に記載の通信システムであって、
前記基地局装置と接続され、前記パケットを選択的に分離して前記エッジサーバに伝送する第一の分離装置と、
前記第一の分離装置と接続され、前記パケットを選択的に分離して前記クラウドサーバに伝送する第二の分離装置と、を備えることを特徴とする通信システム。
【請求項3】
請求項１に記載の通信システムであって、
前記ＩｏＴ端末に配置される第１のミドルウェアは、
前記ＩｏＴ端末が受信する前記基地局装置の電波の強度又は位置情報を検知し、
前記検知された電波の強度又は位置情報を前記第２のミドルウェアに報告し、
前記第２のミドルウェアは、前記報告された電波の強度又は位置情報に基づいて、前記制御ポリシーを作成することを特徴とする通信システム。
【請求項4】
請求項１に記載の通信システムであって、
前記アプリケーションを構成するモジュールが格納され、前記ＩｏＴ端末、前記エッジサーバ又は前記クラウドサーバに前記モジュールをデプロイするリポジトリを備え、
前記第２のミドルウェアは、前記リポジトリからデプロイされるモジュールによって構成される前記アプリケーションに関連した個別の設定に応じて前記制御ポリシーを作成することを特徴とする通信システム。
【請求項5】
請求項１に記載の通信システムであって、
前記第２のミドルウェアは、前記第３のミドルウェアによる分析の結果の予測値、前記ＩｏＴ端末の位置情報、又は、前記ＩｏＴ端末の電波強度に基づいて、前記制御ポリシーを作成することを特徴とする通信システム。
【請求項6】
通信システムにおける通信制御方法であって、
前記通信システムは、１以上のＩｏＴ端末と、前記ＩｏＴ端末が接続する基地局装置と、前記基地局装置が送受信するユーザプレーンのパケットを選択的に受信するエッジサーバと、前記基地局装置又は前記エッジサーバが送受信するユーザプレーンのパケットを選択的に受信するクラウドサーバと、を有し、
前記ＩｏＴ端末、前記エッジサーバ又は前記クラウドサーバの少なくとも一つにはソフトウェアで構成される第１のミドルウェア及びリソース制御機能が配置されており、
前記エッジサーバにはソフトウェアで構成される第２のミドルウェア及び第３のミドルウェアが配置されており、
前記通信制御方法は、
前記第３のミドルウェアが、前記ＩｏＴ端末、前記エッジサーバ及び前記クラウドサーバの少なくとも一つから伝送されるパケットを捕捉し、
前記第３のミドルウェアが、前記捕捉されたパケットからトラヒックを分析し、
前記第３のミドルウェアが、前記分析の結果を前記第２のミドルウェアに提供し、
前記第２のミドルウェアが、前記通信システムで伝送されるパケットの分析の結果に基づいて、ユーザが設定するポリシーに従って、パケットの送信タイミングに関する制御ポリシーを作成し、
前記第２のミドルウェアが、前記作成された制御ポリシーを前記第１のミドルウェアに指示し、
前記第１のミドルウェアが、前記通信システムで伝送されるに関するトラヒックの分析の結果に基づいて定められたポリシーの指示を前記リソース制御機能から受け、
前記第１のミドルウェアが、前記クラウドサーバで動作するアプリケーションから送信されるパケットの送信指示を代理で受信し、
前記第１のミドルウェアが、前記指示されたポリシーに従ってパケットの送信タイミングを調整し、
前記第１のミドルウェアが、前記エッジサーバの通信モジュールへ、前記調整された送信タイミングで前記パケットを送信する送信指示を中継することを特徴とする通信制御方法。
【請求項7】
通信システムにおける通信を制御するためのプログラムであって、
前記通信システムは、１以上のＩｏＴ端末と、前記ＩｏＴ端末が接続する基地局装置と、前記基地局装置が送受信するユーザプレーンのパケットを選択的に受信するエッジサーバと、前記基地局装置又は前記エッジサーバが送受信するユーザプレーンのパケットを選択的に受信するクラウドサーバと、を有し、
前記クラウドサーバにはアプリケーションが配置されており、
前記プログラムは、
前記ＩｏＴ端末、及び前記クラウドサーバの少なくとも一つから伝送されるパケットを捕捉し、
前記捕捉されたパケットからトラヒックを分析する手順と、
前記伝送されるパケットの分析の結果に基づいて、ユーザが設定するポリシーに従って、パケットの送信タイミングに関する制御ポリシーを作成する手順と、
前記通信システムで伝送されるパケットに関するトラヒックの分析の結果に基づいて定められたポリシーの指示を作成する手順と、
前記アプリケーションから送信されるパケットの送信指示を代理で受信する手順と、
前記作成されたポリシーに従ってパケットの送信タイミングを調整する手順と、
前記エッジサーバの通信モジュールへ、前記調整された送信タイミングで前記パケットを送信する送信指示を中継する手順とを前記エッジサーバに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信システムにおける通信制御方法に関する。
【背景技術】
【0002】
ＩｏＴシステム、モノのインターネット接続は、今後、ますますの発展が期待されている。ＩｏＴシステムにおいては、センサなどのモノが情報の発信源となり、機械から機械への通信（Ｍ２Ｍ）が急激に増加すると予測される。このようなモノから送信される情報は、空間内の様々な位置から発生する。例えば、大規模な工場やプラントなどでは、広大な敷地にモノが離散して配置されており、それらのモノからの情報が大量に収集される。
【0003】
このような広域からの情報収集においては、無線を利用する形態がネットワーク敷設コストを削減するために有効である。無線通信では標準化団体である３ｇｐｐにおいて５Ｇ方式が策定され、低遅延で大容量な通信インフラ環境が整いつつある。
【0004】
５Ｇでは、物理的には統合された一つの無線ネットワークを利用し、複数のアプリケーションが、それぞれに定めたサービスレベルアグリーメント（ＳＬＡ）に応じて、仮想的なネットワークスライス（ＮＷスライス）を策定して、統合された物理ネットワークを分割して利用できる。
【0005】
また、デバイス技術の発展によって、低価格なデバイスにおいてもグラフィック処理装置（ＧＰＵ）を搭載した形態も可能となっており、５Ｇを用いた低遅延で大容量な通信によって、映像などの大容量のコンテンツ情報を現場に近いエッジサーバに提供し、高度な判断を伴う機械学習を用いてリアルタイム処理も可能となっている。
【0006】
そのため、これまで利用されてきたクラウドに加えて、より現場に近いロケーションであるデバイスやエッジにおいて演算処理を行うマルチロケーション型の計算処理が可能となり、アプリケーションの形も変わりつつある。マルチロケーション型の計算環境において、アプリケーションは一つのモノリシックなソフトウェアのパッケージとして構成されるのではなく、汎用性が高い部分は多用途に使用可能な共通モジュールとして作成し、各アプリケーションに固有の特徴的な部分を新たに作り上げて完成する形態とし、状況に応じて頻繁な更新にも対応できるマイクロサービス型のアプリケーションに遷移し始めている。
【0007】
従来の端末とクラウドサーバで構築される構成では、クラウドサーバ上にアプリケーションをのせて、端末からの情報を全てクラウドに収集してクラウドで処理する形であった。新しいマルチロケーション型の計算環境では、アプリケーションは、モジュールに分割され、端末、エッジ、クラウドに適切に配置され、より高い応答性が求められる処理は、５Ｇなどの高速かつ低遅延な通信を介して現場（端末）に近い場所でリアルタイムに処理されるようになると考えられる。
【0008】
そして、アプリケーションを構成するモジュールは、センタ（又はクラウド）に設けられたリポジトリから配信されてデプロイされるが、クラウドと異なり、エッジの計算機リソースや、端末とエッジの間の通信は、有限のネットワークリソースを使って、又はＮＷスライスなどの技術によって分割して実現されるので、デプロイの際に、アプリケーションの特徴だけでなく、どのようにネットワークを利用するか及びどのように機能を分散配置するかという環境設定パラメータを考慮して、ネットワークを設定することが重要である。さらには、移動体であれば、移動する場所に応じた対応も必要になる。しかし、アプリケーションそのものは迅速に配置したり、環境依存性を排除して設計されるべきであり、ネットワークの状態を把握し、アプリケーションが期待するネットワークの利用方法を提供する中間層を提供する必要がある。
【0009】
ＮＷスライスを構築する際に、限られたネットワークリソースが枯渇する場合の対処が重要である。特許文献１には、複数のＮＷスライスの構成で、各スライスの通信品質（ＱｏＳ）に応じて優先順位を定めて通信を行う技術が開示されている。
【0010】
従来技術の課題を整理するために、具体的に二つのユースケースを考える。
【0011】
第一のユースケースでは、工場や物流倉庫などで利用されている自動物品搬送車両（ＡＧＶ）を考える。ＡＧＶは、無線通信を用いて管理システムと接続して、管理システムに管理されている。ＡＧＶの動作は四つのフェーズに大別される。第一に倉庫から物品を取り出すフェーズ、第二に取り出した物品を運搬するフェーズ、第三に取り出した材料を必要な作業者に受け渡すフェーズ、第四に倉庫に戻るフェーズである。それぞれのフェーズにおいて実施する作業が異なる。フェーズ毎に、通信内容や要求される通信品質が変わるため、ネットワーク全体からみても、フェーズに応じて優先順位を変更すべきである。
【0012】
第二のユースケースでは、工場における生産ライン上でのソフトウェアを更新する。ラインを流れる半製品にソフトウェアが搭載され、工程ごとに必要な試験などに応じてソフトウェアを更新する場合がある。無線通信のエリアは、工場のライン全体をカバーするように設計されていても、ソフトウェアの更新は、ラインの特定の工程（すなわち場所）において実施されるべきである。もしそうでなければ、後工程の環境や試験内容においてミスマッチが発生し、後工程の作業が困難となる。
【0013】
この二つの事例のように、通信の優先順位は工程や場所に依存しており、従来技術のように、単純にアプリケーションに定められたＳＬＡに応じて、仮想的なＮＷスライスを策定して、統合された物理ネットワークを分割して利用するだけでは不十分であり、アプリケーションの状況や場所などの環境とも連携させて適切に管理する必要がある。アプリケーションは、既に説明しているように、共通部分を活かしながら、アプリケーションが実現しようとする機能とネットワークの管理は分離されるべきである。アプリケーションとネットワーク管理の中間において、ネットワークとアプリケーションを仲介する仕掛けが必要である。その意味で、特許文献１で開示されるような、予め定められた各スライスの通信品質だけで優先順位を定めることは、これらのユースケースにおいては不十分である。
【0014】
次に、ＩｏＴを想定したネットワークの使い方を考える。間欠的で準定期的なトラヒックが流れる事例についての対処も重要である。特許文献２では、無線ネットワークにおける半永久的スケジューリングを行う技術が開示されている。
【0015】
従来技術の課題を整理するために、さらに一つの具体的なユースケースを考える。
【0016】
第三のユースケースでは、工場の生産ラインにおいて、各工程に配置されたセンサから情報を収集して製造工程を流れる半製品の品質情報を収集する。検査は工程ごとに何段も設けられている。ライン上に製品が一定間隔で流れることによって、各センサから間欠的に数値データがセンタに送信されるが、センサの数が膨大になると、検査データが大量に集約されるため、バースト的なトラヒックが発生することとなり、ネットワーク及び受信側において、処理の一時的な集中が発生し、ネットワーク又は計算リソースに一時的な枯渇が発生する要因となる。このような周期トラヒックを管理するためには、予めスロットを割り当てて、時間的な通信の被り（あるいは衝突）の発生を抑制する試みが有効とされてきた。
【0017】
しかし、バースト的なトラヒックの管理は、トラヒックの集中を把握する分析機能を介して分析し、それに応じてトラヒックの集中を自動的に回避する仕組みが必要である。しかるに、従来技術では、ネットワーク側において、予め定めたスロットを提供するのみであり、センサの配置やラインの周期などの様々な要因で変化すると考えられる間欠動作に対応できず、対応として不十分である。また、他の従来技術においては、ネットワークの分析手段を持つことが記載されているが、この様なユースケースにおいて、送信タイミングを調停する従来技術はなく、対応が不十分と考えられる。
【0018】
分析を利用する類似したトラヒック調停機能のユースケースとして、さらに２例を考える。
【0019】
第四のユースケースでは、トラヒックの混雑を把握して、大きなデータを閑散期に送信する。第四のユースケースでは、アプリケーションは、送信を仲介するミドルウェアへの書込依頼によって送信処理を完了する。ミドルウェアは、ネットワークの状況を把握してトラヒックの閑散期を推定し、閑散期にデータを送信する。
【0020】
第五のユースケースも同様に、端末の電波状況を把握して、電波状況が良好な時を狙って大きなデータの送信を行うケースである。第五のユースケースでは、アプリケーションは、送信を仲介するミドルウェアへの書込依頼によって送信処理を完了する。ミドルウェアは、端末の電波状況を把握して端末の電波状態を推定し、良好なタイミングにデータを送信する。
【0021】
この二つの事例のように、分析機能によって不急の通信おいてネットワークの利用効率を向上できるが、アプリケーションは、ネットワークの管理や端末の電波状況などの管理とは分離されるべきであり、各ユースケースで説明した通り、アプリケーションとネットワーク管理の中間において、ネットワークとアプリケーションを仲介する仕掛けが必要である。その意味で、特許文献３で開示されるような、分析機能だけでは、これらのユースケースにおいては不十分である。
【0022】
特許文献４では、送信のグラントなしに上りの送信ができる仕組みについて開示があるが、この方法を用いても、これまで紹介してきたユースケースの解決には至らない。
【0023】
図１は、従来例の５Ｇネットワークシステムの構成を示す図であり、５Ｇネットワーク、端末、エッジサーバ、クラウドサーバからなるネットワークシステムの構成と、ネットワークスライスを示す。
【0024】
図１において、端末１－１、１－２は、無線を介して基地局装置１０と接続している。また、基地局装置１０は、ＵＰＦ（User Plane Function）２０に接続している。ＵＰＦ２０には、端末との接続監視やハンドオーバーなどの移動制御を行うための制御用の信号を伝送するコントロールプレーンの信号と、ユーザのデータを伝送するユーザプレーンの信号が流れる。ＵＰＦ２０は、所定のルールに基づいて、ユーザプレーンの信号をルーティングし、エッジサーバ３０に転送するものを選択し、振り分ける役割を持つ。この機能によって、特定の通信をエッジサーバ３０に振り分けて、エッジサーバ３０で処理できるようになる。
【0025】
図１の下方に、ＵＰＦ２０の機能によって構築されるネットワークスライス１００が、土管のイメージ（横向きの円筒）で描かれている。ＵＰＦ２０で振り分けられたパケットは、エッジサーバ３０に到達し、エッジサーバ３０内のソフトウェアモジュールによって処理が行われ、アプリケーションの一部の動作が実施される。また、同様に端末１－１、１－２を含む別のネットワークスライス１０１の構築も可能であり、先程とは異なるアプリケーションが動作する仮想環境を提供できる。
【0026】
エッジサーバ３０で処理された結果は、ネットワークスライス１０１を通じて端末１－１、１－２に結果をフィードバックできる。その場合には、エッジサーバ３０で折り返されたパケットは、ＵＰＦ２０を介して基地局装置１０に戻され、各端末１－１、１－２にフィードバックが伝達される。ＵＰＦ２０で、センタ側に送られた情報は、センタ側のＵＰＦ２１に入力され、コントロールプレーンとユーザプレーンに分割されて、それぞれのプレーンの目的とする装置に伝達される。すなわち、コントロールプレーンの信号は５Ｇコア装置５０へ伝達され、ユーザプレーンの信号はクラウドサーバ４０へ伝達される。
【0027】
クラウドサーバ４０では、アプリケーションの一部となる別のソフトウェアモジュールが動作しており、伝達された情報を基づいて、ユーザデータに関する処理が実行される。また、コントロールプレーンの信号は５Ｇコア装置５０でネットワーク管理に利用される。５Ｇコア装置は複数の機能の集合体から構成される。図１のＡＦ（Application Function）、ＮＥＦ（Network Exposure Function）、ＰＣＦ（Policy Control Function）、ＡＭＦ（Access and Mobility management Function）、ＳＭＦ（Session Management Function）などはその一部を表している。
【0028】
また、図１の下方には端末１－１、１－２を含むネットワークスライス１０２が描かれているが、このネットワークスライス１０２は端末１－１、１－２を含み、且つクラウドサーバ４０までのネットワークを含んでいる。
【0029】
図２は、従来例のネットワークシステムにおいて、アプリケーションを端末、エッジ及びクラウドにデプロイするリポジトリの構成を示す図である。
【0030】
図１に対して新たに加えられたコンポーネントであるリポジトリから破線で伸びる矢印は、端末１－１、１－２、エッジサーバ３０、及びクラウドサーバ４０に配置されるアプリケーションの一部となるモジュールのデプロイを表している。リポジトリ６０はアプリケーションを構成するモジュールのソフトウェアを格納している倉庫である。クラウドサーバ４０だけにモジュールを展開するのであれば、クラウドサーバ４０内のネットワークを構成するリソースは十分に存在するため、リソースの管理を気にする必要はないが、エッジサーバ３０や端末１－１、１－２までを対象としてモジュールをデプロイする場合、端末１－１、１－２とエッジサーバ３０を結ぶ５Ｇの無線通信や、現場のＵＰＦ２０とセンタのＵＰＦ２１を結ぶ有線ネットワークのリソースが有限であることを考慮し、環境や他のアプリケーションが利用する状況によってはリソースが不足する可能性がある。よってより適切な管理が必要となる。
【0031】
図３は、従来技術において、リポジトリ６０からアプリケーションが端末１とエッジサーバ３０にデプロイされ、その後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。
【0032】
デプロイのためのメッセージ及びソフトウェアダウンロード（１０００）によって、それぞれのノードにデプロイを指示するメッセージ及びソフトウェア本体が、リポジトリ６０から伝送される。例えば、端末１は、端末用のアプリケーションデプロイメントを実施し（２０００－２）、エッジサーバ３０は、エッジサーバ用のアプリケーションデプロイメントが実施する（２０００－１）。その後、エッジサーバ３０は、ネットワークコンフィグ作業を実施し（２００１）、アプリケーションが必要とするネットワークの要件を分析し、５Ｇコア装置５０に要求メッセージを送信する（１００１）。その結果は、設定メッセージとして、ＳＭＦ経由でＵＰＦ２０、２１に送信される（１００２、１００３）。また、設定メッセージは、ＡＭＦ経由で基地局装置１０及び端末１にも送信される（１００４、１００５）。その上で、５Ｇコア装置５０からエッジサーバ３０に応答メッセージが返答され（１００６）、ネットワークのコンフィグの設定が完了する。
【0033】
以上のシーケンスによって、端末とエッジサーバの間でネットワークスライスが構築され、通信１５００が確立する。
【先行技術文献】
【特許文献】
【0034】
【文献】特開２０１８－０５６８６７号公報
【文献】特開２０２０－５２０５８９号公報
【文献】特開２０２０－５３０７０３号公報
【文献】特開２０２０－５０４５１９号公報
【発明の概要】
【発明が解決しようとする課題】
【0035】
大量のセンサやデバイスが空間的に配置され、複数のアプリケーションがそれぞれの目的で動作する環境において、５Ｇなどの物理的に統合された一つの無線ネットワークを利用し、複数のアプリケーションが、それぞれに定めたＳＬＡに応じて、仮想的なＮＷスライスに分割して利用する場合において、アプリケーションは、ネットワークなどの環境への依存を排除したデータの伝送が望ましい。一方で、アプリケーションによっては、デバイスの位置、ネットワーク全体のトラヒック、又はデバイスの電波状況などの状況に基づいて伝送を行うと、ネットワーク利用として効率的な運用が可能となる。しかし、ネットワークの状況を各アプリケーションで管理することは、アプリケーションの開発の迅速化の必要性から困難である。
【0036】
従来技術では、ＮＷスライスに関連付けられた優先順位を予め定めたり、間欠送信するためのスロットを予め割り当てる方法が開示されている。しかし、ＮＷスライス内で使いきれない一時的なリソースの余剰を管理してスライス間での調停は困難である。そのため、スライスのＳＬＡの制約下でのリソースの利用しかできない。限られたエッジサーバ３０の計算機リソースや、端末１とエッジサーバ３０の間を繋ぐ有限のネットワークリソースに利用されない無駄の有効な利用が困難である。
【課題を解決するための手段】
【0037】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、通信システムであって、１以上のＩｏＴ端末と、前記ＩｏＴ端末が接続する基地局装置と、前記基地局装置が送受信するユーザプレーンのパケットを選択的に受信するエッジサーバと、前記基地局装置又は前記エッジサーバが送受信するユーザプレーンのパケットを選択的に受信するクラウドサーバと、を備え、前記ＩｏＴ端末、前記エッジサーバ又は前記クラウドサーバの少なくとも一つにはソフトウェアで構成される第１のミドルウェアが配置されており、前記エッジサーバにはソフトウェアで構成される第２のミドルウェア及び第３のミドルウェアが配置されており、前記第３のミドルウェアは、前記ＩｏＴ端末、前記エッジサーバ及び前記クラウドサーバの少なくとも一つから伝送されるパケットを捕捉し、前記捕捉されたパケットからトラヒックを分析し、前記分析の結果を前記第２のミドルウェアに提供し、前記第２のミドルウェアは、前記通信システムで伝送されるパケットの分析の結果に基づいて、ユーザが設定するポリシーに従って、パケットの送信タイミングに関する制御ポリシーを作成し、前記作成された制御ポリシーを前記第１のミドルウェアに指示し、前記第１のミドルウェアは、前記ポリシーの指示を前記第２のミドルウェアから受け、前記クラウドサーバで動作するアプリケーションから送信されるパケットの送信指示を代理で受信し、前記指示されたポリシーに従ってパケットの送信タイミングを調整し、前記エッジサーバの通信モジュールへ、前記調整された送信タイミングで前記パケットを送信する送信指示を中継することを特徴とする。
【発明の効果】
【0038】
本発明の一態様によれば、ＮＷスライスを効率的に提供できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。
【図面の簡単な説明】
【0039】
【図1】従来例の５Ｇネットワークシステムの構成を示す図である。
【図2】従来例のネットワークシステムにおけるリポジトリからのデプロイを示す図である。
【図3】従来例において、アプリケーションのデプロイ後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。
【図4】第一の実施例のネットワークシステムの構成を示す図である。
【図5】従来例において、ネットワークスライスに流れるパケットを示す模式図である。
【図6】第一の実施例において、ネットワークスライスに流れるパケットを示す模式図である。
【図7】第一の実施例において、アプリケーションのデプロイ後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。
【図8】第一の実施例において、アプリケーションのデプロイ後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。
【図9】第一の実施例において、アプリケーションのデプロイ後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。
【図10】第一の実施例のリソース制御機能が実行する処理のフローチャートである。
【図11】第一の実施例の第一のユースケースを示す図である。
【図12】第一の実施例の第二のユースケースを示す図である。
【図13】第一の実施例の第三のユースケースを示す図である。
【図14】第一の実施例の第四のユースケースを示す図である。
【図15】第一の実施例の第五のユースケースを示す図である。
【図16】第二の実施例において、アプリケーションのデプロイ後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。
【図17】第二の実施例のリソース制御機能が実行する処理のフローチャートである。
【図18】第二の実施例のリポジトリが実行するデータベース更新処理のフローチャートである。
【図19】第二の実施例のリポジトリが実行するデータベース情報要求への応答処理のフローチャートである。
【図20】一つのサービスが、分割されたモジュールによって構成される場合のモジュールのつながりを示す図である。
【図21】二つのサービスがあり、その優先順位を定める場合の模式図である。
【図22】二つのサービスがあり、その優先順位を定める場合の模式図である。
【発明を実施するための形態】
【0040】
＜実施例１＞
本発明の第一の実施例について説明する。
本発明の第一の実施例について説明する。
【0041】
図４は、本発明の第一の実施例のネットワークシステムの構成を示す図であり、５Ｇのネットワークと端末、エッジサーバ、クラウドサーバを含むネットワークシステムの構成と、ネットワークスライスのイメージを示す。
【0042】
図４において、端末１－１、１－２は、無線を介して基地局装置１０と接続している。また、基地局装置１０は、ＵＰＦ（User Plane Function）２０に接続している。ＵＰＦ２０には、端末との接続監視やハンドオーバーなどの移動制御を行うための制御用の信号を伝送するコントロールプレーンの信号と、ユーザのデータを伝送するユーザプレーンの信号が流れる。ＵＰＦ２０は、所定のルールに基づいて、ユーザプレーンの信号をルーティングし、エッジサーバ３０に転送するものを選択し、振り分ける役割を持つ。この機能によって、特定の通信をエッジサーバ３０に振り分けて、エッジサーバ３０で処理できるようになる。
【0043】
図４の下方に、ＵＰＦ２０の機能によって構築されるネットワークスライス１００が、土管のイメージ（横向きの円筒）で描かれている。ＵＰＦ２０で選択的に振り分けられたパケットは、エッジサーバ３０に到達し、エッジサーバ３０内のソフトウェアモジュールによって処理が行われ、アプリケーションの一部の動作が実施される。また、同様に端末１－１、１－２を含む別のネットワークスライス１０１の構築も可能であり、先程とは異なるアプリケーションが動作する仮想環境を提供できる。
【0044】
エッジサーバ３０で処理された結果は、ネットワークスライス１０１を通じて端末１－１、１－２に結果をフィードバックできる。その場合には、エッジサーバ３０で折り返されたパケットは、ＵＰＦ２０を介して基地局装置１０に戻され、各端末１－１、１－２にフィードバックが伝達される。ＵＰＦ２０で、センタ側に送られた情報は、センタ側のＵＰＦ２１に入力され、コントロールプレーンとユーザプレーンに分割されて、それぞれのプレーンの目的とする装置に伝達される。すなわち、コントロールプレーンの信号は５Ｇコア装置５０へ伝達され、ユーザプレーンの信号はクラウドサーバ４０へ伝達される。
【0045】
クラウドサーバ４０では、アプリケーションの一部となる別のソフトウェアモジュールが動作しており、伝達された情報に基づいて、ユーザデータに関する処理が実行される。また、コントロールプレーンの信号は５Ｇコア装置５０でネットワーク管理に利用される。５Ｇコア装置５０は複数の機能の集合体から構成される。
【0046】
また、図４の下方には端末１－１、１－２を含むネットワークスライス１０２が描かれているが、このネットワークスライス１０２は端末１－１、１－２を含み、且つクラウドサーバ４０までのネットワークを含んでいる。
【0047】
図５を参照して、複数のスライスに流れるパケットの総合的な管理が有効である例を模式的に説明する。図５では、二つのネットワークスライス１００、１０１にパケットが流れている様子を描いている。ネットワークスライスは仮想的なものであるから、実体の物理的なネットワーク１１０には、二つのネットワークスライス１００、１０１に流れるパケットが重畳されて流れる。図で分かるように、各ネットワークスライスは独立であるとすると、同時に流れるパケットは時間軸上で重なり合う。特に時間に同期して報告を上げるＭ２Ｍを基本とするＩｏＴのユースケースでは、所定の時刻（例えば、０時０分）に複数のセンサから同時にパケットが流れる事象によって、バーストが発生する。
【0048】
図６には、ネットワークスライス１０１の送信タイミングをずらせた様子が描かれている。図６に示す場合では、二つのネットワークスライス１００、１０１に流れるパケットは重畳されるものの、時間的にはずれているので、実体の物理的なネットワーク１１１においてバーストが発生しない。このように、本来ならば、各ネットワークスライスのＳＬＡにおいて規定される帯域を保証するためには、複数のネットワークスライスを跨がって、全体としての制御が必要となる。ネットワーク全体の制御はネットワークレイヤで行われており、特許文献１には異なるネットワークスライス間でＱｏＳにより優先順位を定める方法が開示されている。
【0049】
しかしながら、ネットワークにおいてタイミングを管理すると、例えばＴＣＰ／ＩＰのように応答を期待するプロトコルでは、タイミング調整によりレスポンス遅れが発生すると、帯域を絞るなどの別の影響が生じる。そのため、アプリケーションにより近いレイヤでの操作が望ましい。一方、ネットワークの管理を行うアプリケーションは煩雑になり、アプリケーションの開発に影響するため、その中間層において管理を行う仕組みが望まれる。
【0050】
送信タイミングを制御するミドルウェアは、様々な位置に配置できる。図４において、端末１に配置されるミドルウェア９０－１、９０－２、エッジサーバ３０に配置されるミドルウェア９１、クラウドサーバ４０に配置されるミドルウェア９２を表している。全てのパケットが通過する現場側のＵＰＦ２０はパケットをミラーリングして、エッジサーバ３０に配信する。エッジサーバ３０の他のミドルウェア８１は、ＵＰＦ２０がミラーリングしたパケットをキャプチャして分析し、分析結果をリソース制御機能８０に提供する。その結果と連携し、且つ送信タイミング制御を行うミドルウェア９０、９１、９２と連携して、送信タイミングを調停するリソース制御機能８０がミドルウェアとして実装される。具体的には、リソース制御機能８０は、パケット分析ミドルウェア８１による分析結果に基づいて、ユーザが設定するポリシーに従って、パケットの送信タイミングに関する制御ポリシーを作成し、作成された制御ポリシーを送信タイミング制御ミドルウェア９０、９１、９２に指示する。送信タイミング制御ミドルウェア９０、９１、９２は、各装置（端末１、エッジサーバ３０、クラウドサーバ４０）のアプリケーションからのパケットの送信指示を代理で受信し、リソース制御機能８０に指示されたポリシーに従ってパケットの送信タイミングを調整し、通信モジュールへの送信指示を中継する。
【0051】
図７は、アプリケーションがリポジトリ６０から端末１及びエッジサーバ３０にデプロイされ、その後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。図７に示す実施例は、端末１に内蔵される送信制御ミドルウェア９０がリソース制御機能８０とメッセージを交換し、送信制御を行うことを特徴とする。
【0052】
デプロイのためのメッセージ及びソフトウェアダウンロード（１０００）によって、それぞれのノードにデプロイを指示するメッセージ及びソフトウェア本体が、リポジトリ６０から伝送される。例えば、端末１は、端末用のアプリケーションデプロイメントを実施し（２０００－２）、エッジサーバ３０は、エッジサーバ用のアプリケーションデプロイメントを実施する（２０００－１）。その後、エッジサーバ３０は、ネットワークコンフィグ作業を実施し（２００１）、アプリケーションが必要とするネットワークの要件を分析し、５Ｇコア装置５０に要求メッセージを送信する（１００１）。その結果は、設定メッセージとして、ＳＭＦ経由でＵＰＦ２０、２１に送信される（１００２、１００３）。また、設定メッセージは、ＡＭＦ経由で基地局装置１０及び端末１にも送信される（１００４、１００５）。その上で、５Ｇコア装置５０からエッジサーバ３０に応答メッセージが返答され（１００６）、ネットワークコンフィグの設定が完了する。
【0053】
その後、エッジサーバ３０は、デプロイしたアプリケーションの情報及び端末の接続情報を含むメッセージによって、リソース制御機能８０に送信タイミングを調整するための指示を送信する（１１０７）。リソース制御機能８０は、当該指示に応答メッセージを返信する（１１０８）。この応答メッセージは、分析ミドルウェア８１に対するテレメトリリクエストを含む。エッジサーバに搭載された分析ミドルウェア８１は、スライスに流れるパケットを分析するタスクを起動する。通信時に、端末１は、通信に関する情報を含むメッセージをリソース制御機能８０に送信する（１１０９）。リソース制御機能８０は、スケジューリングに関する情報を含むメッセージを端末１に送信する（１１１０）。
【0054】
以上のシーケンスによって、端末とエッジサーバの間でネットワークスライスが構築され、通信１５００が確立する。通信１５００では、端末１は、リソース制御機能８０から配信されたスケジューリングに関するルールに基づいてパケットを送信する。また、通信１５００の分析が分析ミドルウェア８１において実施され、その結果であるテレメトリ１５０１がリソース制御機能８０に提供される。リソース制御機能８０は、テレメトリの情報を利用して、必要に応じて、スケジューリングに関する情報を含むメッセージを端末１に送信し、スケジューリングを更新する（１１１０）。
【0055】
図８は、アプリケーションがリポジトリ６０から端末１及びエッジサーバ３０にデプロイされ、その後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。図８に示す実施例は、エッジサーバ３０に内蔵される送信制御ミドルウェア９１は、リソース制御機能８０とメッセージを交換し、送信制御を行うことを特徴とする。
【0056】
デプロイのためのメッセージ及びソフトウェアダウンロード（１０００）によって、それぞれのノードにデプロイを指示するメッセージ及びソフトウェア本体が、リポジトリ６０から伝送される。例えば、端末１は、端末用のアプリケーションデプロイメントを実施し（２０００－２）、エッジサーバ３０は、エッジサーバ用のアプリケーションデプロイメントを実施する（２０００－１）。その後、エッジサーバ３０は、ネットワークコンフィグ作業を実施し（２００１）、アプリケーションが必要とするネットワークの要件を分析し、５Ｇコア装置５０に要求メッセージを送信する（１００１）。その結果は、設定メッセージとして、ＳＭＦ経由でＵＰＦ２０、２１に送信される（１００２、１００３）。また、設定メッセージは、ＡＭＦ経由で基地局装置１０及び端末１にも送信される（１００４、１００５）。その上で、５Ｇコア装置５０からエッジサーバ３０に応答メッセージが返答され（１００６）、ネットワークコンフィグの設定が完了する。
【0057】
その後、エッジサーバ３０は、デプロイしたアプリケーションの情報及び端末の接続情報を含むメッセージによって、リソース制御機能８０に送信タイミングを調整するための指示を送信する（１１０７）。このメッセージは、分析ミドルウェア８１に対するテレメトリリクエストを含む。このメッセージによって、エッジサーバに搭載された分析ミドルウェア８１が、スライスに流れるパケットを分析するタスクを起動する。リソース制御機能８０は、応答メッセージを返信する（１１０８）。
【0058】
通信時に、エッジサーバ３０は、通信に関する情報を含むメッセージをリソース制御機能８０に送信する（１１１１）。リソース制御機能８０は、スケジューリングに関する情報を含むメッセージをエッジサーバ３０に送信する（１１１２）。
【0059】
以上のシーケンスによって、端末とエッジサーバの間でネットワークスライスが構築され、通信１５００が確立する。通信１５００では、エッジサーバ３０は、リソース制御機能８０から配信されたスケジューリングに関するルールに基づいてパケットを送信する。また、通信１５００の分析が分析ミドルウェア８１において実施され、その結果であるテレメトリ１５０１がリソース制御機能８０に提供される。リソース制御機能８０は、テレメトリの情報を利用して、必要に応じて、スケジューリングに関する情報を含むメッセージをエッジサーバ３０に送信し、スケジューリングを更新する（１１１２）。
【0060】
図９は、アプリケーションがリポジトリ６０から端末１、エッジサーバ３０及びクラウドサーバ４０にデプロイされ、その後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。図９に示す実施例は、クラウドサーバ４０に内蔵される送信制御ミドルウェア（９２）は、リソース制御機能８０とメッセージの交換を行い、送信制御を行うことを特徴とする。
【0061】
デプロイのためのメッセージ及びソフトウェアダウンロード（１０００）によって、それぞれのノードにデプロイを指示するメッセージ及びソフトウェア本体が、リポジトリ６０から伝送される。例えば、端末１は、端末用のアプリケーションデプロイメントを実施し（２０００－２）、エッジサーバ３０は、エッジサーバ用のアプリケーションデプロイメントを実施する（２０００－１）。その後、エッジサーバ３０は、ネットワークコンフィグ作業を実施し（２００１）、アプリケーションが必要とするネットワークの要件を分析し、５Ｇコア装置５０に要求メッセージを送信する（１００１）。その結果は、設定メッセージとして、ＳＭＦ経由でＵＰＦ２０、２１に送信される（１００２、１００３）。また、設定メッセージは、ＡＭＦ経由で基地局装置１０及び端末１にも送信される（１００４、１００５）。その上で、５Ｇコア装置５０からエッジサーバ３０に応答メッセージが返答され（１００６）、ネットワークのコンフィグの設定が完了する。
【0062】
その後、エッジサーバ３０は、デプロイしたアプリケーションの情報及び端末の接続情報を含むメッセージによって、リソース制御機能８０に送信タイミングを調整するための指示を送信する（１１０７）。このメッセージは、分析ミドルウェア８１に対するテレメトリリクエストを含む。このメッセージによって、エッジサーバに搭載された分析ミドルウェア８１が、スライスに流れるパケットを分析するタスクを起動する。リソース制御機能８０は、応答メッセージを返信する（１１０８）。
【0063】
通信時にクラウドサーバ４０からリソース制御機能８０に、通信に関する情報を含むメッセージを送信する（１１１３）。リソース制御機能８０は、クラウドサーバ４０にスケジューリングに関する情報を含むメッセージを送信する（１１１４）。また、リソース制御機能８０は、状況を報告するメッセージを端末１に送信する（１１１５）。例えば、端末１の位置や電波強度などの情報についてのテレメトリ１５０３がエッジサーバ３０に報告される。端末・クラウドサーバ間でネットワークスライスが構築され、通信１５０２が確立する。通信１５０２では、クラウドサーバ４０は、リソース制御機能８０から配信されたスケジューリングに関するルールに基づいてパケットを送信する。また、通信１５０２の分析及び端末１からのテレメトリ１５０３の分析が分析ミドルウェア８１において実施され、その結果であるテレメトリ１５０１がリソース制御機能８０に提供される。リソース制御機能８０では、テレメトリの情報を利用して、必要に応じて、スケジューリングに関する情報を含むメッセージをクラウドサーバ４０に送信し、スケジューリングを更新する（１１１４）。
【0064】
図１０は、第一の実施例のリソース制御機能８０が実行する処理のフローチャートである。
【0065】
まず、リソース制御機能８０は、エッジサーバ３０からデプロイしたアプリケーションの情報及び端末の接続情報を含むメッセージ（１１０７）によって、送信タイミングを調整するための指示を受け取る（４０２）。そして、リソース制御機能８０は、指示に対する応答と共に、テレメトリのリクエスト（１１０８）を分析ミドルウェア８１に送信する（４０３）。リソース制御機能８０は、通信時に、通信に関する情報として、端末の状況報告及び送信リクエストの情報（１１０９）を端末１から受領する（４０４）。リソース制御機能８０は、テレメトリ１５０１を受領し（４０５）、ステップ４０２で受領した指示で設定されているポリシーに応じて送信スケジュール（１１１０）を配信する（４０６）。テレメトリ１５０１は継続されるため、リソース制御機能８０は、アプリケーションエバリュエーションのデータを収集し、アプリケーションによるネットワークの使い方を評価する（４０７）。
【0066】
【0067】
図１１は、第一の実施例の第一のユースケースを示す図である。図１１に示すユースケースでは、工場や物流倉庫などで利用される自動物品搬送車両（ＡＧＶ）５００の通信を制御する。ＡＧＶ５００は、無線通信を用いて管理システムと接続して、管理システムに管理されている。ＡＧＶ５００の動作は四つのフェーズに大別される。第一に倉庫から物品を取り出すフェーズ６０３、第二に取り出した物品を運搬するフェーズ６００、第三に取り出した材料を必要な作業者に受け渡すフェーズ６０２、第四に倉庫に戻るフェーズ６０１である。それぞれのフェーズにおいて実施する作業が異なる。フェーズ毎に、通信内容や要求される通信品質が変わるため、ネットワーク全体からみても、フェーズに応じて優先順位を変更すべきである。
【0068】
本実施例では、図７でデプロイされたアプリケーションに応じてポリシーを設定できる（１１０７）。設定されるポリシーでは、端末の位置に基づいた管理が必要であり、通信１５００に位置情報を含めた報告を端末側に送り、エッジサーバ３０は、テレメトリ１５０１を経由して位置の情報をリソース制御機能８０に報告する。位置とフェーズを対応付けると、フェーズの切り替えによってポリシーを変更できる。例えば、移動中となる第二及び第四のフェーズでは優先順位を上げてリアルタイムでの通信制御を行う。一方、第一及び第三のフェーズでは優先順位を下げて他の通信を優先してもよい。よって、課題は解決される。
【0069】
図１２は、本実施例の第二のユースケースを示す図である。図１２に示すユースケースでは、工場における生産ライン上でのソフトウェアを更新する。ラインを流れる半製品５１０にソフトウェアが搭載され、工程ごとに必要な試験などに応じてソフトウェアを更新する場合がある。無線通信のエリア６１０は、工場のライン全体をカバーするように設計されていても、ソフトウェアの更新は、ラインの特定の工程（すなわち場所６１１）において実施されるべきである。もしそうでなければ、後工程の環境や試験内容においてミスマッチが発生し、後工程の作業が困難となる。
【0070】
本実施例では、図９でデプロイされたアプリケーションに応じてポリシーを設定できる（１１０７）。このため、第一のユースケースと同様に、端末１から位置に関する情報を収集し（１５０３）、リソース制御機能８０において位置と送信可否を対応付けると、特定場所にマッチングして起動する送信タスクを定義でき、特定場所において送信を開始できる。よって課題は解決される。
【0071】
図１３は、本実施例の第三のユースケースを示す図である。図１３に示すユースケースでは、工場の生産ラインにおいて、各工程に配置されたセンサから情報を収集して製造工程を流れる半製品の品質情報を収集する。検査は工程ごとに何段も設けられている。ライン上に製品が一定間隔で流れることによって、各センサから間欠的に数値データがセンタに送信されるが（５３０）、センサの数が膨大になると、検査データが大量に集約されるため、バースト的なトラヒックが発生することとなり、ネットワーク及び受信側において、処理の一時的な集中が発生し、ネットワーク又は計算リソースに一時的な枯渇が発生する要因となる。このような周期トラヒックを管理するためには、予めスロットを割り当てて、時間的な通信の被り（あるいは衝突）の発生を抑制する試みが有効とされてきた。
【0072】
しかし、バースト的なトラヒックの管理は、トラヒックの集中を把握する分析機能を介して分析し、それに応じてトラヒックの集中を自動的に回避する仕組みが必要である。しかるに、従来技術では、ネットワーク側において、予め定めたスロットを提供するのみであり、センサの配置やラインの周期などの様々な要因で変化すると考えられる間欠動作に対応できず、対応として不十分である。また、他の従来技術においては、ネットワークの分析手段を持つことが記載されているが、この様なユースケースにおいて、送信タイミングを調停する従来技術はなく、対応が不十分と考えられる。
【0073】
本実施例では、図７でデプロイされたアプリケーション５２０に応じてポリシーを設定できる（１１０７）。設定されるポリシーでは、ネットワークを監視し、分析するミドルウェア８１によって、ネットワークの状況を把握して（５４０）、空きを探しながら自動的にタイミングを調整する（５５０）。ミドルウェア８１による分析結果に従って、新たな周期的な接続要求（１１０９）があった際に、適切なオフセットを含めたスケジューリング情報を含むメッセージを送信して（１１１０）、人手を煩わせずにトラヒックの集中を回避できる。また、リソース制御機能８０は、テレメトリ１５０１を使って状況を把握しているので、部分的なバーストの発生を検知して、その都度修正のためのスケジューリング情報を更新して、端末１の送信タイミングを送信制御ミドルウェア９０にフィードバックできるため、特定のトラヒックの偏りを自動的に修正できる。よって、課題は解決される。
【0074】
図１４は、本実施例の第四のユースケースを示す図である。図１４に示すユースケースでは、トラヒックの混雑を把握して、大きなデータを閑散期に送信する。第四のユースケースでは、アプリケーションは、送信を仲介するミドルウェアへの書込依頼によって送信処理を完了する。ミドルウェアは、ネットワークの状況を把握してトラヒックの閑散期を推定し、閑散期にデータを送信する。
【0075】
本実施例では、図７でデプロイされたアプリケーション５２１に応じてポリシーを設定できる（１１０７）。設定されるポリシーでは、ネットワークを監視し、分析するミドルウェア８１によって、ネットワークの状況を把握して、時間的にまとまった空きを予測する。具体的には、従来からある手法、例えば、ＳＡＲＩＭＡ法を用いて、閑散期を予測し、閑散期の予測結果に基づいてデータ送信タイミングを自動的に調整する。そして、適切なタイミングが到来したときにスケジューリング情報を含むメッセージを送信する（１１１０）。これによって、人手を煩わせずに自動的に閑散期を推定できる。よって、課題は解決される。
【0076】
図１５は、本実施例の第五のユースケースを示す図である。図１５に示すユースケースでは、端末１の電波状況を把握して、電波状況が良好な時を狙って大きなデータの送信を行うケースである。第五のユースケースでは、アプリケーションは、送信を仲介するミドルウェアへの書込依頼によって送信処理を完了する。ミドルウェアは、端末の電波状況を把握して端末の電波状態を推定し、良好なタイミングにデータを送信する。
【0077】
先に第二のユースケースで述べた通り、図９のシーケンスにおいて、端末１への電波状態のテレメトリ指示（１１１５）に基づいて、端末１からは電波の状況を定期的に報告するテレメトリ１５０３が指示される。リソース制御機能８０は、この情報に基づいて、適切なタイミングを知ることができる。電波の状態が閾値より高い状態が続く場合では、クラウドサーバ４０から容易にファイルを更新できる。よって、課題は解決される。
【0078】
以上に説明したように、実施例１によれば、スライス内で使いきれない一時的なリソースの余剰を管理してスライス間で調停できる。そして、スライスのＳＬＡのオーバーコミットを許容し、限られたエッジサーバ３０の計算機リソースや、端末１とエッジサーバ３０の間を接続する有限のネットワークリソースに利用されない余剰が発生する場合でも、ＮＷスライスを効率的に提供できる。
【0079】
＜実施例２＞
本発明の第二の実施例を説明する。第二の実施例は、リソース制御機能８０がリポジトリ６０とやり取りするメッセージが追加される点で第一の実施例と異なる。第二の実施例では第一の実施例との相違点を主に説明し、第一の実施例と同じ構成や機能の説明は省略する。
本発明の第二の実施例を説明する。第二の実施例は、リソース制御機能８０がリポジトリ６０とやり取りするメッセージが追加される点で第一の実施例と異なる。第二の実施例では第一の実施例との相違点を主に説明し、第一の実施例と同じ構成や機能の説明は省略する。
【0080】
図１６は、本発明の第二の実施例において、アプリケーションがリポジトリ６０から端末１及びエッジサーバ３０にデプロイされ、その後にネットワークのコンフィグが設定されるシグナリングのシーケンス図である。
【0081】
デプロイのためのメッセージ及びソフトウェアダウンロード（１０００）によって、それぞれのノードにデプロイを指示するメッセージ及びソフトウェア本体が、リポジトリ６０から伝送される。例えば、端末１は、端末用のアプリケーションデプロイメントを実施し（２０００－２）、エッジサーバ３０は、エッジサーバ用のアプリケーションデプロイメントを実施する（２０００－１）。その後、エッジサーバ３０は、ネットワークコンフィグ作業を実施し（２００１）、アプリケーションが必要とするネットワークの要件を分析し、５Ｇコア装置５０に要求メッセージを送信する（１００１）。その結果は、設定メッセージとして、ＳＭＦ経由でＵＰＦ２０、２１に送信される（１００２、１００３）。また、設定メッセージは、ＡＭＦ経由で基地局装置１０及び端末１にも送信される（１００４、１００５）。その上で、５Ｇコア装置５０からエッジサーバ３０に応答メッセージが返答され（１００６）、ネットワークコンフィグの設定が完了する。
【0082】
その後、リソース制御機能８０は、デプロイしたアプリケーションの情報及び端末の接続情報を含むメッセージによって、エッジサーバ３０から送信タイミングを調整するための指示を受け取る（１１０７）。これに先立ち、リポジトリ６０との定常的な交信によって、アプリケーション毎のポリシーの情報をリポジトリ６０から受け取る（１２００、１２０１）。例えば、リソース制御機能８０がテーブルの更新情報をリポジトリ６０に要求し、リポジトリ６０は更新情報をリソース制御機能８０に返信する。また、リソース制御機能８０は、分析ミドルウェア８１の分析結果を受け取り（１５０１）、その結果をリポジトリ６０に報告し（１２０２）、応答を受け取る（１２０３）。これら一連の手順によって、リソース制御機能８０は、同じアプリケーションが使われている複数の拠点間の動向に基づいて、ポリシーを変更できる。
【0083】
図１７は、第二の実施例のリソース制御機能８０が実行する処理のフローチャートである。
【0084】
まず、リソース制御機能８０は、定期的にリポジトリ６０と交信することで、データベースに蓄積されたアプリケーション特有のコンフィグを受領する（４０１）。次に、リソース制御機能８０は、エッジサーバ３０からデプロイしたアプリケーションの情報及び端末の接続情報を含むメッセージ（１１０７）によって、送信タイミングを調整するための指示を受け取る（４０２）。そして、リソース制御機能８０は、指示に対する応答と共に、テレメトリのリクエスト（１１０８）を分析ミドルウェア８１に送信する（４０３）。リソース制御機能８０は、通信時に、通信に関する情報として、端末の状況報告及び送信リクエストの情報（１１０９）を端末１から受領する（４０４）。リソース制御機能８０は、テレメトリ１５０１を受領し（４０５）、ステップ４０２で受領した指示で設定されているポリシーに応じて送信スケジュール（１１１０）を配信する（４０６）。テレメトリ１５０１は継続されるため、リソース制御機能８０は、アプリケーションエバリュエーションのデータを収集し、アプリケーションによるネットワークの使い方を評価する（４０７）。リソース制御機能８０は、定期交信しているリポジトリ６０に評価結果をフィードバックする（４０８）。
【0085】
図１８は、第二の実施例のリポジトリ６０が実行するデータベース更新処理のフローチャートである。
【0086】
リポジトリ６０は、複数の拠点に個別に配置されたリソース制御機能８０からのエバリュエーション結果を受領し（４２１）、その結果をデータベースに蓄積する（４２２）。所定の期間の後、リポジトリ６０は、データベースを解析する。例えば、優先順位のレーティング、スケジューリングにおけるパラメータの調整ができ、アプリケーションの結び付けの変化に対する対応を総括できる。具体的には、環境個別の対応ではなく、例えばアプリケーションの更新によって、データ送信量が増加した場合などの変化に対応して、データベースの解析結果を関連する拠点全体に反映できる。よって、課題は解決される。
【0087】
図１９は、第二の実施例のリポジトリ６０が実行するデータベース情報要求への応答処理のフローチャートである。
【0088】
図示するように、リポジトリ６０は、各拠点からのデータ分析要求に対してデータベースから関連するアプリケーションの情報を読み出し、要求された拠点のリソース制御機能８０に応答する手順を繰り返す。
【0089】
＜実施例３＞
本発明の第三の実施例では、予めポリシーを設定することで、ルールに基づいて自動的に通信を優先順位付けする。
本発明の第三の実施例では、予めポリシーを設定することで、ルールに基づいて自動的に通信を優先順位付けする。
【0090】
図２０は、一つのサービスが、分割された複数のモジュール２００～２０８によって構成される場合のモジュールの関係を示す図である。
【0091】
モジュール２０３から次のモジュール２０６及びモジュール２０４への通信が無線通信である。無線通信のリソースは有限であり、且つ他の通信経路より回線の帯域が細い。モジュール２０３からモジュール２０６への通信とモジュール２０３からモジュール２０４への通信を比較すると、モジュール２０４を経由する経路の方がモジュールが多い。モジュール２０７では、モジュール２０６からの経路とモジュール２０４からの経路の両方からデータが到着しないと最終モジュール２０８へ処理結果を伝送できないとすると、モジュール２０３からモジュール２０４へのパスを優先してデータを伝送し、全体としての遅延を抑制すべきである。このような判断も、ネットワークの分析ミドルウェア８１が、モジュールのトポロジーを把握することで、トポロジーに基づいた優先順位を決定できる。よって、課題は解決される。
【0092】
図２１、図２２は二つのサービスがあり、その優先順位を定める場合の模式図である。図２１に示す場合、モジュール２１０からモジュール２１１への通信が無線通信である。但し、モジュール２１１で処理した結果は、複数のモジュール２１２、２１３に伝送される。図２２に示す場合、モジュール２１４からモジュール２１５への通信が無線通信である。この二つを比べた場合、図２１の構成は、無線を介して伝送されたデータが複数の用途に利用されることから、影響力が大きなアプリケーションだと理解できる。このような判断も、ネットワークの分析ミドルウェア８１において、モジュールのトポロジーを把握することで、トポロジーに基づいた優先順位を決定できる。よって、課題は解決される。
【0093】
このように、複雑なマイクロサービスを構成する場合でも、単純なルールの付与による優先順位の決定を行うことができる。
【0094】
なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
【0095】
また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。
【0096】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
【0097】
また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。
【符号の説明】
【0098】
１・・・端末
１０・・・基地局装置
２０・・・第一ＵＰＦ
２１・・・第二ＵＰＦ
３０・・・エッジサーバ
４０・・・クラウドサーバ
５０・・・５Ｇコア装置
６０・・・リポジトリ
８０・・・リソース制御機能
８１・・・分析ミドルウェア
９０・・・端末側送信制御ミドルウェア
９１・・・エッジサーバ側送信制御ミドルウェア
９２・・・クラウドサーバ側送信制御ミドルウェア
１００、１０１、１０２・・・ネットワークスライス
１０・・・基地局装置
２０・・・第一ＵＰＦ
２１・・・第二ＵＰＦ
３０・・・エッジサーバ
４０・・・クラウドサーバ
５０・・・５Ｇコア装置
６０・・・リポジトリ
８０・・・リソース制御機能
８１・・・分析ミドルウェア
９０・・・端末側送信制御ミドルウェア
９１・・・エッジサーバ側送信制御ミドルウェア
９２・・・クラウドサーバ側送信制御ミドルウェア
１００、１０１、１０２・・・ネットワークスライス
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】