特許 6731407 制御方法及び制御装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6731407

(24)【登録日】2020年7月8日

(45)【発行日】2020年7月29日

(54)【発明の名称】制御方法及び制御装置

(51)【国際特許分類】

   G06F 9/50 20060101AFI20200716BHJP

   G06F 9/455 20060101ALI20200716BHJP

【ＦＩ】

   G06F9/50 150Z

   G06F9/50 150D

   G06F9/455 150

【請求項の数】8

【全頁数】25

(21)【出願番号】特願2017-526323(P2017-526323)

(86)(22)【出願日】2016年6月24日

(86)【国際出願番号】JP2016068854

(87)【国際公開番号】WO2017002729

(87)【国際公開日】20170105

【審査請求日】2017年10月26日

【審判番号】不服2019-3834(P2019-3834/J1)

【審判請求日】2019年3月22日

(31)【優先権主張番号】特願2015-130477(P2015-130477)

(32)【優先日】2015年6月29日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】392026693

【氏名又は名称】株式会社ＮＴＴドコモ

(74)【代理人】

【識別番号】100088155

【弁理士】

【氏名又は名称】長谷川 芳樹

(74)【代理人】

【識別番号】100113435

【弁理士】

【氏名又は名称】黒木 義樹

(74)【代理人】

【識別番号】100121980

【弁理士】

【氏名又は名称】沖山 隆

(74)【代理人】

【識別番号】100128107

【弁理士】

【氏名又は名称】深石 賢治

(72)【発明者】

【氏名】山▲崎▼ 健生

(72)【発明者】

【氏名】田村 基

(72)【発明者】

【氏名】岩科 滋

(72)【発明者】

【氏名】陳 嵐

【合議体】

【審判長】 田中 秀人

【審判官】 仲間 晃

【審判官】 ▲はま▼中 信行

(56)【参考文献】

【文献】 特開２０１４−２４１１１９（ＪＰ，Ａ）

【文献】 特開２０１３−１１７７５７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06F 9/50

G06F 9/455

(57)【特許請求の範囲】

【請求項1】

ユーザの通信端末とアクセスするためのエリアネットワークごとに配置される第１ノード、および前記第１ノードより前記通信端末から遠いネットワークに配置される第２ノードに対する通信制御を行う制御装置の制御方法において、
前記第１ノードおよび前記第２ノードは、前記通信端末からの要求処理を実行して得た情報を前記通信端末に提供するためのサービスを行うノードであって、
前記第１ノードに対して、前記通信端末からの要求処理に対する所定のサービス提供基準を定めておき、
前記第１ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行う課金額の上限を超えた場合に、前記通信端末からの要求処理を実行するノードを、前記第１ノードから前記第２ノードに変更し、前記第２ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行う課金額の課金限界に達していない場合に、前記通信端末からの要求を実行するノードを、前記第２ノードから前記第１ノードに変更し、
前記サービス提供基準は、前記通信端末が前記第１ノードからのサービス提供を受けるごとに課される課金情報を含む、
制御方法。

【請求項2】

前記第２ノードは、
前記エリアネットワークと階層が異なるネットワークからアクセス可能に配置されており、
複数のエリアネットワークごとに配置されている第１ノードが行うサービス提供処理を集約して実行する、請求項１に記載の制御方法。

【請求項3】

前記通信端末と第１ノードとの間の通信遅延と、前記通信端末と第２ノードとの間の通信遅延とが異なる、請求項１または２に記載の制御方法。

【請求項4】

前記第１ノードと、前記第２ノードとの間で、前記通信端末からの要求処理を実行するノードを変更するとは、
前記通信端末からの要求処理を実行する仮想マシンがあるノードを変更することである、請求項１〜３のいずれか一項に記載の制御方法。

【請求項5】

前記第１ノードは、仮想マシンを起動し、前記第１ノードで実行するためのアプリケーションを実行できる状態にして、前記通信端末からの要求処理を実行し、
前記通信端末からの要求処理を実行するノードを変更するとは、前記第１ノードの仮想マシンを、前記第２ノードへ移動させ、
当該アプリケーションを前記第２ノードの仮想マシンで実行させる、
請求項４に記載の制御方法。

【請求項6】

ユーザの通信端末とアクセスするためのエリアネットワークごとに配置される第１ノード、および前記第１ノードより前記通信端末から遠いネットワークに配置される第２ノードに対する通信制御を行う制御装置において、
前記第１ノードおよび前記第２ノードは、前記通信端末からの要求処理を実行して得た情報を前記通信端末に提供するためのサービスを行うノードであって、
前記第１ノードに対して、前記通信端末からの要求処理に対する所定のサービス提供基準を定めておき、
前記第１ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行う課金額の上限を超えた場合に、前記通信端末からの要求処理を実行するノードを、第１ノードから第２ノードに変更し、前記第２ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行う課金額の課金限界に達していない場合に、前記通信端末からの要求を実行するノードを、第２ノードから第１ノードに変更し、
前記サービス提供基準は、前記通信端末が前記第１ノードからのサービス提供を受けるごとに課される課金情報を含む、
制御装置。

【請求項7】

前記第２ノードは、
前記エリアネットワークと階層が異なるネットワークからアクセス可能に配置されており、
複数のエリアネットワークごとに配置されている第１ノードが行うサービス提供処理を集約して実行する、請求項６に記載の制御装置。

【請求項8】

前記第１ノードと、前記第２ノードとの間で、前記通信端末からの要求処理を実行するノードを変更するとは、
前記通信端末からの要求処理を実行する仮想マシンがあるノードを変更することである、請求項６または７に記載の制御装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御方法及び制御装置に関する。

【背景技術】

【0002】

従来から、ネットワーク上においてスマートフォンなど端末の近くにあるエッジサーバに処理を分散させることで、地球規模で集中的配備されたクラウドコンピューティングの環境と比べて通信遅延を短縮するエッジコンピューティングという技術が考えられている（非特許文献１）。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】“エッジコンピューティング構想”、［ｏｎｌｉｎｅ］、ＮＴＴ持株会社ニュースリリース、［平成２７年６月１８日検索］、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｎｔｔ．ｃｏ．ｊｐ／ｎｅｗｓ２０１４／１４０１／１４０１２３ａ．ｈｔｍｌ＞

【発明の概要】

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

【0004】

上述のように、エッジサーバが、端末の近くで処理をすることを想定しているので、より多くの場所にエッジサーバを設置する必要がある。よって、使用状態によらずにエッジサーバで実行するサービス（アプリケーション）のためのリソースを確保してしまうと、当該リソースが無駄になってしまう可能性がある。一方、集中的に配備されたクラウドネットワーク上のデータサーバで処理をすると、低遅延で処理を実現することが困難になる。

【0005】

そこで、本発明は、上記問題点を解決するために、端末からの要求処理を実行するネットワーク上の装置を適切に変更することができる制御方法及び制御装置を提供することを目的とする。

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

【0006】

上記目的を達成するために、本発明の一実施形態に係る制御方法は、ユーザの通信端末とアクセスするためのエリアネットワークごとに配置される第１ノード、および前記第１ノードより前記通信端末から遠いネットワークに配置される第２ノードに対する通信制御を行う制御装置の制御方法において、前記第１ノードおよび前記第２ノードは、前記通信端末からの要求処理を実行して得た情報を前記通信端末に提供するためのサービスを行うノードであって、前記第１ノードに対して、前記通信端末からの要求処理に対する所定のサービス提供基準を定めておき、前記第１ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行う課金額の上限を超えた場合に、前記通信端末からの要求処理を実行するノードを、前記第１ノードから前記第２ノードに変更し、前記第２ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行うか金額の課金限界に達している場合に、前記通信端末からの要求を実行するノードを、前記第２ノードから前記第１ノードに変更し、前記サービス提供基準は、前記通信端末が前記第１ノードからのサービス提供を受けるごとに課される課金情報を含む。

【0007】

また、本発明の一実施形態に係る制御装置は、ユーザの通信端末とアクセスするためのエリアネットワークごとに配置される第１ノード、および前記第１ノードより前記通信端末から遠いネットワークに配置される第２ノードに対する通信制御を行う制御装置において、前記第１ノードおよび前記第２ノードは、前記通信端末からの要求処理を実行して得た情報を前記通信端末に提供するためのサービスを行うノードであって、前記第１ノードに対して、前記通信端末からの要求処理に対する所定のサービス提供基準を定めておき、前記第１ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行う課金額の上限を超えた場合に、前記通信端末からの要求処理を実行するノードを、第１ノードから第２ノードに変更し、前記第２ノードが前記通信端末にサービスを提供している場合であって、前記サービス提供基準に基づいて、前記第１ノードからサービス提供を行うか金額の課金限界に達している場合に、前記通信端末からの要求を実行するノードを、第２ノードから第１ノードに変更し、前記サービス提供基準は、前記通信端末が前記第１ノードからのサービス提供を受けるごとに課される課金情報を含む。

【0008】

上記の発明によれば、通信端末による要求処理を実行する第１ノードに対して設定されたサービス提供基準に基づいて、通信端末の要求処理を実行するノードを変更するので、コストと速度とのバランスを取ることができる。

【0009】

また、上記の制御方法は、通信端末と第１ノードとの間の通信遅延と、通信端末と第２ノードとの間の通信遅延とが異なってもよい。このように、使用状態に応じて、遅延時間が異なるネットワークのノードで通信端末からの要求処理を実行することにより、コストと速度とのバランスを取ることができる。

【0010】

また、上記の制御方法及び制御装置では、第１ノードと、第２ノードとの間で、通信端末からの要求処理を実行するノードを変更するとは、通信端末からの要求処理を実行する仮想マシンがあるノードを変更することとしてもよい。この場合、仮想化ネットワークにおいて、コストと速度とのバランスを取ることができる。

【0011】

また、上記の制御方法は、第１ノードは、仮想マシンを起動し、第１ノードで実行するためのアプリケーションを実行できる状態にして、通信端末からの要求処理を実行し、通信端末からの要求処理を実行するノードを変更するとは、第１ノードの仮想マシンを、第２ノードへ移動させ、当該アプリケーションを第２ノードの仮想マシンで実行させることとしてもよい。このように、第１ノードの仮想マシンを、第２ノードへ移動させ、当該アプリケーションを第２ノードの仮想マシンで実行させることにより、コストと速度とのバランスを取ることができる。

【発明の効果】

【0014】

本発明の一実施形態によれば、端末からの要求処理を実行するネットワーク上の装置を適切に変更することができる。

【図面の簡単な説明】

【0015】

【図1】本発明の実施形態に係るシステムの構成を示す図である。

【図2】本発明の実施形態に係るノード変更装置を示すブロック図である。

【図3】ノード変更装置のハードウェア構成図である。

【図4】サービスポリシーテーブルを示す図である。

【図5】実行場所管理テーブルを示す図である。

【図6】課金管理テーブルを示す図である。

【図7】トラヒック情報テーブルを示す図である。

【図8】アプリケーションの実行例を示すシーケンス図である。

【図9】エッジ起動処理を示すシーケンス図である。

【図10】エッジからデータセンタへ処理装置を変更するシーケンス図である。

【図11】課金に基づいて実行装置を変更する処理を示すフローチャートである。

【図12】データセンタからエッジへ処理装置を変更するシーケンス図である。

【図13】帯域利用に基づいて実行装置を変更する処理を示すフローチャートである。

【図14】実行装置の変更に基づいてトラヒック情報を変更する例を示す図である。

【図15】変形例におけるエッジ起動処理を示すシーケンス図である。

【図16】処理負荷状況テーブルを示す図である。

【図17】変形例におけるエッジからデータセンタへ処理装置を変更するシーケンス図である。

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

【0016】

以下、図面と共に本発明の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

【0017】

図１に本実施形態に係るノード変更装置１０（通信制御装置）を含む通信システム１の構成を示す。通信システム１は、ＵＥ９０の使用状況に基づいて処理をする装置をＲＡＮ（Regional Area Network）等の自己ネットワークに接続されているエッジ４０からコアネットワークに接続されている装置に移動したり、処理をする装置をデータセンタ７０からエッジ４０に移動したりするシステムである。ここで自己ネットワークとは、一つの通信事業者により運用され、ＵＥ９０が在圏するネットワークである。

【0018】

図１に示すように通信システム１は、ノード変更装置１０と、ＯＳＳ／ＢＳＳ（Operations Support System／Business Support System）２０と、ＭＡＮＯ（Management & Orchestration）３０と、エッジ４０と、ＭＭＥ５０と、ＳＰＧＷ６０と、データセンタ７０と、ｅＮｏｄｅ８０と、ＵＥ９０とを含んで構成されている。

【0019】

このうち、ＯＳＳ／ＢＳＳ（Operations Support System／Business Support System）２０と、ＭＡＮＯ（Management & Orchestration）３０と、エッジ４０の一部と、ＭＭＥ５０とは、通信システム１のコアネットワークを構成するものである。ｅＮｏｄｅ８０とエッジ４０との一部がＲＡＮを構成するものである。データセンタ７０は、ＷＡＮ（Wide Area Network）を構成する。また、データセンタ７０は、ＷＡＮのような外部ネットワーク（上記自己ネットワークとは異なるネットワーク）を介して接続することができる。互いに情報の送受信が必要な構成要素間は、有線・無線により接続されており情報の送受信が可能となっている。

【0020】

ＵＥ９０は、スマートフォン、タブレット端末を含む端末であり、この通信システム１と通信接続することにより通信を行うことができる。ＵＥ９０から通信システム１へサービス処理要求をすると、ＲＡＮに接続されているエッジ４０、コアネットワークに接続されているエッジ４０、及びデータセンタ７０の何れかの装置（ノード）により当該サービスの処理（アプリケーションの処理）がなされる。

【0021】

ＲＡＮに接続されているエッジ４０、コアネットワークに接続されているエッジ４０、外部ネットワークに接続しているデータセンタ７０の順にＵＥ９０からの距離が短い。よって、距離が短いＲＡＮに接続されているエッジ４０は、上記３つの装置の中で通信遅延が最も小さい。ここで通信遅延とは、ＵＥ９０からの処理要求に応じて処理をする装置（ＲＡＮに接続されているエッジ４０、コアネットワークに接続されているエッジ４０、データセンタ７０）と、ＵＥ９０との間における通信時間により定められるものである。このように、通信システム１は、ＵＥ９０までの距離が互いに異なる複数のネットワークでＵＥ９０からの要求処理を実行するノードを有する。ＲＡＮに接続されているエッジ４０、コアネットワークに接続されているエッジ４０、及びデータセンタ７０は、それぞれ分散データベース（分散ＤＢ）を有しており、サービス実行時のユーザデータ（ユーザ設定等のデータ）を共有して保存している。所定期間毎に互いにユーザデータの差分データを複製する。

【0022】

また、ＲＡＮに接続されているエッジ４０、コアネットワークに接続されているエッジ４０、及びＷＡＮ（外部ネットワーク）に接続されているデータセンタ７０は、互いに異なる階層（種類）のネットワークに接続されている。ＲＡＮのエッジ４０は、ＵＥ９０の近くの位置で処理を実行するので、広範囲に多数分散している。一方、データセンタ７０は、外部ネットワークからアクセスされるので、統括して処理をするため、それほど分散していない。よって、エッジ４０が、上記のサービスを全て実行すると、ＵＥ９０へ即時に処理結果を提供できるが、多数分散しているため、設置コスト・リソースコストがかかってしまう。一方、データセンタ７０は、それほど分散していないため、データセンタ７０が、上記サービスを集約して実行すれば、設置コスト・リソースコストを抑えることができる。しかし、ＵＥ９０との距離があるため、エッジ４０がサービスを実行する場合より処理時間がかかる。

【0023】

ノード変更装置１０は、ＵＥ９０からのサービス要求に対する処理をする装置の状況を確認し、当該状況に基づいて実行している装置の変更を行う。詳細は後述する。

【0024】

ＯＳＳ／ＢＳＳ２０は、通信システム１におけるサービス管理を行い、通信システム１での通信機能に係る指示を行うノードである。例えば、ＯＳＳ／ＢＳＳ２０は、ＭＡＮＯ３０に対して、新たな通信機能（通信サービス）を追加するように指示を行う。また、ＯＳＳ／ＢＳＳ２０は、通信システム１に係る通信事業者によって操作され得る。

【0025】

ＭＡＮＯ３０は、ＮＦＶＯ(Network Functions Virtualisation Orchestrator)と、ＶＮＦＭ(Virtual Network Function Manager)と、ＶＩＭ(Virtualised Infrastructure Management: 仮想化基盤管理)とを含んで構成されている。ＮＦＶＯは、物理資源上に構築された仮想ネットワーク全体の管理を行う全体管理ノード（機能エンティティ）である。ＶＮＦＭは、物理資源（ノード）に対して、サービスに係る機能を追加する仮想通信機能管理ノード（機能エンティティ）である。物理資源（ノード）各々を管理する物理資源管理ノード（機能エンティティ）である。具体的には、資源の割当・更新・回収の管理、物理資源と仮想化ネットワークとの関連付け、ハードウェア資源とＳＷ資源（ハイパーバイザー）一覧の管理を行う。

【0026】

なお、ＮＦＶＯ、ＶＮＦＭ及びＶＩＭは、物理的なサーバ装置上でプログラムが実行されることにより実現される（但し仮想化上で実現されることを制限するものでは無く、管理系統を分離した上で、仮想化上で実現してもよい）。ＮＦＶＯ、ＶＮＦＭ及びＶＩＭは、それぞれ別々の物理的なサーバ装置で実現されていてもよいし、同じサーバ装置で実現されていてもよい。ＮＦＶＯ、ＶＮＦＭ及びＶＩＭ（を実現するためのプログラム）は、別々のベンダから提供されていてもよい。

【0027】

ＳＰＧＷ６０は、ＳＧＷ又はＰＧＷである。ＳＧＷ（Serving Gate Way）は、ＬＴＥを収容する在圏パケット交換機で、ＰＧＷ（Packet data network Gate Way）との間でユーザデータの送受信を行う。ＰＧＷは、外部ネットワークと接続するゲートウェイであり、ＵＥ９０へのＩＰアドレス払出しなどを行う。

【0028】

ＭＭＥ５０は、ＬＴＥネットワークに在圏するＵＥ９０の位置管理、認証制御、及びユーザデータの通信経路の設定処理を行う部分である。

【0029】

エッジ４０は、ＵＥ９０からのサービス要求に応じて、処理をするサーバ装置である。

【0030】

データセンタ７０は、ＵＥ９０からのサービス要求に応じて処理をするサーバ装置である。また、各種データを記憶する。

【0031】

引き続いて、ノード変更装置１０について、本実施形態に係る機能を、図２を用いて説明する。図２に示すようにノード変更装置１０は、配置情報記憶部１１と、シーケンス監視部１２（使用情報取得手段）と、トラヒック監視部１３（使用情報取得手段）と、配置計算部１４（変更手段）と、配置指示部１５（変更手段）と、を有する。

【0032】

ここで、図３に本実施形態に係るノード変更装置１０を構成するサーバ装置のハードウェア構成を示す。図３に示すように当該ノード変更装置１０は、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述するノード変更装置１０の機能が発揮される。なお、ノード変更装置１０は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。

【0033】

配置情報記憶部１１は、配置変更するための判断情報等、ＵＥ９０からの処理を実行する装置の配置に関する情報を記憶する部分である。配置情報記憶部１１は、複数種類のテーブルの情報を記憶している。具体的には、配置情報記憶部１１は、実行するノードの変更条件を示す情報を有するテーブルであるサービスポリシーテーブル、処理を実行する場所の情報を有する実行場所管理テーブル、各ユーザの課金状況を示す情報を有する課金管理テーブル、外部ネットワーク側からの使用状況と、内部ネットワーク側（自己ネットワーク側）の使用状況とを示す情報を有するトラヒック情報テーブルとを記憶する。

【0034】

図４にサービスポリシーテーブルの例を示す。図４に示すように、サービスポリシーテーブルは、サーバアプリアドレスと、サービス名と、ポリシーとを有する情報を記憶するためのテーブルである。サーバアプリアドレスとは、ポリシーを送信したデータセンタ７０のアドレスである。サービス名は、サービス識別するための名称である（例えば、動画配信サービス、ＩＴＳサービス等を示す名称）。ポリシーは、実行するノードの変更条件を示す情報である。

【0035】

サービス名がサービス１であるポリシーは、１ユーザが１月で３００円までは、エッジでＵＥ９０からの処理を実行し、３００円を超えるとエッジ以外の装置で実行することを示している。また、サービス名がサービス５であるポリシーは、処理負荷状況が８０％を超えた場合は、エッジ利用を規制し、７０％を下回った場合、エッジ利用規制を解除することを示している。また、サービス名がサービス６であるポリシーは、端末からのサービス要求が１０分間無い場合は、サービス処理をエッジ処理からデータセンタへ移し、再度要求時に、データセンタからエッジへ戻すことを示している。

【0036】

図５に実行場所管理テーブルの例を示す。図５に示すように、実行場所管理テーブルは、サービス名と、場所と、ユーザＩＤとを有する情報を記憶するためのテーブルである。サービス名は、サービスを識別するための名称である。場所は、当該サービスを実行するノードを示す情報である。ユーザＩＤは、ユーザを識別する情報である。図５に示すように、サービス１については、ユーザＩＤがユーザ１、ユーザ２、ユーザ３であるユーザのＵＥ９０から処理要求がなされた場合、エッジ１で処理を行う。また、同じサービス１でも、ユーザＩＤがユーザ４、ユーザ５であるユーザのＵＥから処理要求がなされた場合、データセンタ１で処理を行う。このように、同一のサービスでもユーザによって実行するノードが異なる。

【0037】

続いて、図６に課金管理テーブルの例を示す。図６に示すように、課金管理テーブルは、ユーザＩＤと、サービス名と、課金の状態とを有する情報を記憶するためのテーブルである。

【0038】

ユーザＩＤは、ユーザを識別する情報である。サービス名は、サービスを識別するための情報である。課金の状態は、課金が上限に達したか否かを示す情報である。例えば、サービス１については、ユーザ１が上限に達しており、ユーザ２は、まだ上限に達していないことを示す。

【0039】

続いて、図７にトラヒック情報テーブルの例を示す。図７に示すように、トラヒック情報テーブルは、サービス名と、実行装置と、対象ユーザと、ＵＥ側のトラヒック（遅延、利用帯域幅）、ＷＡＮ側のトラヒック（遅延、利用帯域幅）とを有する情報を記憶するためのテーブルである。

【0040】

サービス名は、サービスを特定するための情報である。実行装置は、処理を実行する装置を示す情報である。対象ユーザは、対象ユーザを特定するための情報である。ここには、特定のユーザを示すユーザＩＤや、全ユーザを示す情報が入力される。ＵＥ側のトラヒックは、内部ネットワークからのアクセスがあったトラヒックの情報（通信遅延の平均値、１秒あたりの通信量）を示す。ＷＡＮ側のトラヒックは、外部ネットワークからのアクセスがあったトラヒックの情報を示す。

【0041】

シーケンス監視部１２は、ＭＭＥ５０等にシーケンスの監視要求をして、当該ＭＭＥ５０等からシーケンスの監視結果を取得する部分である。具体的に、シーケンス監視部１２は、課金に関する監視要求、接続する回線種別（例えば、４Ｇ、５Ｇ）に関する監視要求をする。シーケンス監視部１２は、配置指示部１５から監視指示を受け付けると、監視対象となる装置（例えば、ＭＭＥ５０）に対して監視指示（監視対象となるユーザＩＤ、サービスＩＤ、監視対象のポリシーを示す情報）を送出する。

【0042】

シーケンス監視部１２は、シーケンス監視指示した装置から所定のタイミングで監視結果を受信する。このように、シーケンス監視部１２は、ユーザの使用状況の情報として、監視結果を受信する。シーケンス監視部１２は、当該監視結果を、配置計算部１４へ送出する。

【0043】

トラヒック監視部１３は、ルータ・スイッチ等にトラヒックの監視要求をして、当該ルータ・スイッチ等からトラヒックの監視結果を取得する部分である。トラヒック監視部１３は、配置指示部１５から監視指示を受け付けると、監視対象となる装置（例えば、ＳＰＧＷ）に対して監視指示（監視対象となるユーザＩＤ、サービスＩＤ、ポリシーを示す情報）を送出する。

【0044】

トラヒック監視部１３は、トラヒック監視指示した装置から所定のタイミングで監視結果を受信する。このように、トラヒック監視部１３は、ユーザの使用状況の情報として、監視結果を受信し、当該監視結果を配置計算部１４へ送出する。

【0045】

配置計算部１４は、ＵＥ９０からのサービス要求に対する処理を行う装置を決定する部分である。配置計算部１４は、ＵＥ９０からサービス要求を新たに取得した場合、ポリシーに基づいて実行する装置を決定する。

【0046】

具体的に、配置計算部１４は、ポリシーに基づいてサービスを実行する装置（データセンタ、コアネットワークのエッジ、ＲＡＮのエッジ）を決定する。すなわち、配置計算部１４は、サービスを実行する位置を決定する。配置計算部１４は、ＲＡＮに接続されているエッジで実行することを決定した場合、ＵＥ９０の位置に基づいて、ＵＥ９０から最も近いエッジを実行対象の装置に決定する。

【0047】

また、配置計算部１４は、シーケンス監視部１２又はトラヒック監視部１３から監視結果を受信すると、当該監視結果がサービスポリシーテーブルのポリシーに基づいて、実行する装置の変更条件を満たす場合、実行対象の装置を変更する旨、決定する。このように、配置計算部１４は、シーケンス監視部１２又はトラヒック監視部１３によって取得された監視結果に基づいて、通信端末からの要求処理を実行するノードを変更する。

【0048】

例えば、配置計算部１４は、上記監視結果に基づき、課金の上限値を超えた場合（すなわち、監視結果に基づいた使用度が予め定められた条件を上回る場合）、処理対象の装置（ノード）をエッジ４０から、コアノードのエッジ４０又はデータセンタ７０に変更する旨、決定する。すなわち、配置計算部１４は、要求処理をしているノードのネットワークと比較して、ＵＥ９０からの距離が長いネットワークのノードに変更する旨、決定する。配置計算部１４は、実行する装置を決定すると、処理対象の装置を配置指示部１５へ通知する。

【0049】

配置指示部１５は、配置計算部１４から処理対象の装置を受け付けて、当該装置への配置変更指示をＭＡＮＯ３０に対して行う。ＭＡＮＯ３０は、これに応じて、対象装置へＵＥ９０のサービス要求処理を実行する旨指示する。

【0050】

続いて、図８から図１４を用いて、上記システムにおける処理を説明する。まず図８を用いて、サービスとして、車載端末で実行される運行状態に関するアプリケーションを実行する場合の処理を説明する。具体的には、運行状態に関するアプリケーションには、複数のユーザにより撮像された車外の画像を合成する機能と、経路探索の機能が含まれる。

【0051】

また、車載端末で実行される運行状態に関するアプリケーションとして、エッジで実行するためのアプリケーション（エッジアプリ）と、データセンタで実行するためのアプリケーション（サーバサイドアプリ）との２種類のアプリケーションが含まれるものとする。

【0052】

具体的には、エッジアプリ（エッジアプリケーション）では、運行状況を示す画像（例えば、車両前方の画像）を解析した結果と上記画像とを合成した画像を表示出力する処理を行う。サーバサイドアプリ（サーバサイド）は、経路探索依頼に基づき、経路探索をする。

【0053】

ＵＥ９０Ｂは、ログイン要求をデータセンタ７０へ送信すると、エッジ４０へログイン要求を通知する（ステップＳ１）。エッジ４０は、これに応じて仮想マシンであるＶＭ（Virtual Machine）を起動し、エッジアプリを実行できる状態にする（ステップＳ２）。

【0054】

エッジ４０は、ＶＭ起動後、データセンタ７０へＶＭを起動した旨を通知するし、データセンタ７０は、ＵＥ９０ＢへＶＭ起動した旨を通知する（ステップＳ３）。

【0055】

ＵＥ９０Ａは、ログイン要求をデータセンタ７０へ行い、データセンタ７０は、ログインを受け付けた旨と接続先のアドレスをＵＥ９０Ｂへ通知する（ステップＳ４）。

【0056】

ＵＥ９０Ａ及びＵＥ９０Ｂが、自端末で撮影した画像をエッジ４０へ送信すると（ステップＳ５）、エッジ４０は、それぞれの画像を解析・合成する（ステップＳ６）。

【0057】

エッジ４０は、合成した画像をＵＥ９０Ａ及びＵＥ９０Ｂへ送信する（ステップＳ７）。ＵＥ９０Ａ及びＵＥ９０Ｂは、受信した画像をＡＲ（拡張現実）表示をする（ステップＳ８及びステップＳ９）。

【0058】

また、ＵＥ９０Ｂは、ルート探索依頼をデータセンタ７０へ要求し（ステップＳ１０）、データセンタ７０は、これに応じてルートを作成する（ステップＳ１１）。データセンタ７０は、このルートをＵＥ９０Ｂへ送信する（ステップＳ１２）。ＵＥ９０Ｂは、このルートを表示出力する（ステップＳ１３）。

【0059】

このように、撮影画像の表示のように、即時性を問われる機能は、遅延量が少ないエッジ４０が処理をして、経路探索のように即時性が問われない機能は、データセンタ７０が処理をする。

【0060】

続いて、図９に示すシーケンス図を用いてポリシーの登録及びＶＭ生成の処理手順を説明する。

【0061】

まず、データセンタ７０においてポリシ−の入力操作がなされると、データセンタ７０は、ポリシーの対象となるサービス名とポリシーの内容と共にポリシーの登録要求をＯＳＳ／ＢＳＳ２０へ行う（ステップＳ２１）。ＯＳＳ／ＢＳＳ２０は、これに応じて、ノード変更装置１０へポリシーの設定要求を行う（ステップＳ２２）。ノード変更装置１０は、上記ポリシーの対象となるサービス名、ポリシーの内容をサービスポリシーテーブルへ登録する。ノード変更装置１０は、登録完了した旨をＯＳＳ／ＢＳＳ２０へ通知する（ステップＳ２３）。ＯＳＳ／ＢＳＳ２０は、当該通知をデータセンタ７０へ通知する（ステップＳ２４）。ステップＳ２１〜ステップＳ２４の処理により、ノード変更装置１０のサービスポリシーテーブルにポリシーが登録されることになる。

【0062】

ＵＥ９０からデータセンタ７０へエッジ接続依頼（原則エッジで実行されるサービスの実行要求）がなされると（ステップＳ２５）、データセンタ７０からＯＳＳ／ＢＳＳ２０へサービス名、ＵＥ９０のアドレスを通知すると共に、エッジ作成要求を行う（ステップＳ２６）。ＯＳＳ／ＢＳＳ２０は、ノード変更装置１０に対して、エッジ作成依頼を行う（ステップＳ２７）。

【0063】

ノード変更装置１０は、サービス名に対応するサービスポリシーテーブルを参照する（ステップＳ２８、ステップＳ２９）。配置計算部１４は、上記サービスポリシーテーブルの内容に基づいて、実行対象の装置を決定する(ステップＳ３０)。また、配置計算部１４は、監視内容を示す監視対象も決定する（例えば、サービスとユーザＩＤと課金状況等）。

【0064】

ノード変更装置１０の配置計算部１４は、実行対象の装置と、サービス要求したＵＥ９０のユーザＩＤとを対応付けた情報を実行場所管理テーブルに登録する（ステップＳ３１及びステップＳ３２）。

【0065】

ノード変更装置１０の配置計算部１４は、監視要求及び配置要求を配置指示部１５へ通知する（ステップＳ３３）。配置指示部１５は、配置要求に応じて、ＭＡＮＯ３０へサービス名及びエッジのアドレスを通知すると共に、ＶＭ作成要求をする。

【0066】

ＭＡＮＯ３０は、当該ＶＭ作成要求に応じて、要求対象の装置のエッジ４０へサービス名を通知するともに、ＶＭ作成依頼をする（ステップＳ３５）。

【0067】

エッジ４０は、ＶＭ起動準備をすると共に、ＶＭ上で動作するエッジアプリを起動する（ステップＳ３６）。エッジ４０は、エッジアプリ起動完了通知をＭＡＮＯ３０へ行う（ステップＳ３７）。ＭＡＮＯ３０は、これに応じて、エッジアプリ起動完了通知をノード変更装置１０へ行う（ステップＳ３８）。

【0068】

配置指示部１５は、監視指示をトラヒック監視部１３へ行う（ステップＳ３９）。トラヒック監視部１３は、これに応じて対象となる装置へ監視指示を行い、監視指示を行った結果を配置指示部１５へ行う（ステップＳ４０）。

【0069】

配置計算部１４は、監視指示をシーケンス監視部１２へ行う（ステップＳ４１）。シーケンス監視部１２は、これに応じて対象となる装置へ監視指示を行い、監視指示を行った結果を配置指示部１５へ行う（ステップＳ４２）。

【0070】

配置指示部１５は、配置計算部１４へ配置完了通知をする（ステップＳ４３）。配置計算部１４は、これに応じて、接続情報（接続先のアドレス）をデータセンタ７０へ送信する（ステップＳ４４）。データセンタ７０は、ＵＥ９０へ接続情報を通知し（ステップＳ４５）、ＵＥ９０は、当該接続情報に基づいてエッジ４０へ接続する（ステップＳ４６）。

【0071】

続いて、図１０のシーケンス図を用いて、実行する装置を変更する処理を説明する。ＵＥ９０は、コアネットワーク内のルータ・スイッチを通じてエッジ接続要求をすると、（ステップＳ５１）、ルータ・スイッチは、エッジ４０へ通信内容を転送する(ステップＳ５２)。

【0072】

ＯＳＳ／ＢＳＳ２０は、課金状況を判断して、課金限界に達している場合、ノード変更装置１０へ課金限界通知をする（ステップＳ５３）。シーケンス監視部１２は、当該課金限界通知を配置計算部１４へ通知する（ステップＳ５４）。

【0073】

ノード変更装置１０は、サービスポリシーテーブル、実行場所管理テーブル、及び課金管理テーブルを参照する（ステップＳ５５、ステップＳ５６）。

【0074】

配置計算部１４は、上記サービスポリシーテーブルの内容に基づいて、実行対象の装置を決定する(ステップＳ５７)。また、配置計算部１４は、監視対象も決定する（例えば、サービスとユーザＩＤと課金状況等）。

【0075】

ノード変更装置１０の配置計算部１４は、実行対象の装置と、サービス要求したＵＥ９０のユーザＩＤとを対応付けた情報を実行場所管理テーブルに登録し、課金管理テーブルを更新する（ステップＳ５８及びステップＳ５９）。

【0076】

ノード変更装置１０の配置計算部１４は、監視要求及び配置要求を配置指示部１５へ通知する（ステップＳ６０）。配置指示部１５は、配置要求に応じて、ＭＡＮＯ３０へサービス名及び変更先の装置のアドレスを通知すると共に、ＶＭ作成要求をする（ステップＳ６１）。ＭＡＮＯ３０は、分散ＤＢレプリケーション先を変更先の装置であるデータセンタ７０に設定し、ユーザ情報の登録要求をする（ステップＳ６２）。また、ＭＡＮＯ３０は、変更元装置の分散ＤＢへ以後の更新を禁止する。データセンタ７０は、ユーザ情報の登録を完了すると、その旨をＭＡＮＯ３０へ通知する（ステップＳ６３）。

【0077】

ＭＡＮＯ３０は、処理対象変更の旨の通知（ＶＭ集約）をエッジ４０に対して行い（ステップＳ６４）、エッジ４０は、これに応じて終了処理（エッジアプリ起動終了）をする（ステップＳ６５）。処理を終了すると、その旨をＭＡＮＯ３０へ通知する（ステップＳ６６）。

【0078】

ＭＡＮＯ３０は、ＳＰＧＷ６０に対して、フロー切替を指示し（ステップＳ６７）、ＳＰＧＷ６０は、これに応じてフロー切替処理をして、処理完了の旨をＭＡＮＯ３０へ通知する（ステップＳ６８）。また、ＭＡＮＯ３０からルータ・スイッチへフロー切替指示をする（ステップＳ６９）。ルータ・スイッチは、切替終了すると、ＭＡＮＯ３０へ通知する（ステップＳ７０）。このように、ＭＡＮＯ３０は、ＵＥ９０からの処理要求に応じて、データセンタ７０が当該処理を行うように、通信経路を設定する。

【0079】

ＭＡＮＯ３０は、配置指示部１５へ集約完了通知をする（ステップＳ７１）。配置指示部１５は、シーケンス監視部１２へ監視終了指示をして（ステップＳ７２）、シーケンス監視部１２から完了通知を受領する（ステップＳ７３）。

【0080】

配置指示部１５は、トラヒック監視部１３へ監視終了指示をして（ステップＳ７４）、トラヒック監視部１３から完了通知を受領する（ステップＳ７５）。この後、配置指示部１５から配置計算部１４へ再配置完了の旨を通知する(ステップＳ７６)。

【0081】

これにより、ＵＥ９０は、ルータ・スイッチを介してサーバアプリ通信要求をすると（ステップＳ７７）、ルータ・スイッチは、ＳＰＧＷへ通知し、これに応じて、ＳＰＧＷは、ルータ・スイッチを介してデータセンタ７０へ通知する（ステップＳ７９、ステップＳ８０）。データセンタ７０は、エッジ４０の分散ＤＢへユーザデータの読出し要求をして（ステップＳ８１）、エッジ４０からユーザデータを取得する。データセンタ７０は、このユーザデータを用いて、ＵＥ９０からの処理要求に応じた処理を行う。

【0082】

続いて、図１１に示すフローチャートを用いて、配置計算部１４が移動判定をする処理（図１０に示すステップＳ５７）を説明する。

【0083】

配置計算部１４は、常時移動変更イベントの待ち受けをする（ステップＳ９１）。何らかのイベントの通知を受信した場合、ステップＳ９２以降の処理を行う。シーケンス監視部１２が課金限界通知を受信する等、課金イベントが発生した場合（ステップＳ９２；ＹＥＳ）、課金管理テーブルの更新処理をする（ステップＳ９３）。処理をしている装置がエッジ４０かデータセンタ７０かを判断する（ステップＳ９４）。処理をしている装置がエッジ４０である場合、課金イベントが発生しており、且つ課金限界通知を受けている場合（ステップＳ９５；ＹＥＳ）、ステップＳ９７へ移動する。

【0084】

課金限界通知を受けていない場合、３Ｇ、４Ｇに遷移していない場合（ステップＳ９６；ＮＯ）、処理装置を変更することなく、ステップＳ９１へ進む。課金限界通知を受けていない場合、回線種別が３Ｇ、４Ｇに遷移した場合（ステップＳ９６；ＹＥＳ）、ステップＳ９７へ移動する。ステップＳ９７では、配置計算部１４は、データセンタ７０へ移動させる旨、決定する（ステップＳ９７）。

【0085】

現在処理している装置がデータセンタ７０である場合、ステップＳ９８へ移動し、５Ｇへ遷移している場合でなければ(ステップＳ９８；ＮＯ)、ステップＳ９１へ移動する。５Ｇに遷移した場合（ステップＳ９８；ＹＥＳ）、課金限界なっている場合（ステップＳ９９；ＮＯ）は、処理装置を変更せずにステップＳ９１へ移動し、課金限界になっていない場合（ステップＳ９９；ＹＥＳ）、エッジ４０へ移動させる旨、決定する（ステップＳ１００）。

【0086】

続いて、図１２のシーケンス図を用いて、トラヒックに基づいて、処理装置を変更する処理を説明する。

【0087】

内部端末（自己ネットワークにおける端末）であるＵＥ９０Ａが、ルータ・スイッチに対してエッジ４０への処理要求をすると（ステップＳ１１１）、ルータ・スイッチは、エッジ４０へ接続する（ステップＳ１１２）。ルータ・スイッチは、当該エッジ４０に対する通信のトラヒックをトラヒック監視部１３へ通知する（ステップＳ１１３）。

【0088】

トラヒック監視部１３は、当該通知に基づいて、トラヒック情報を更新要求、更新完了通知を受領する（ステップＳ１１４、ステップＳ１１５）。

【0089】

外部端末（外部ネットワークを介して接続する端末）であるＵＥ９０Ｂ（端末ＷＡＮ）が、データセンタ７０を介してルータ・スイッチへエッジ４０への処理要求をする（ステップＳ１１６）。ルータ・スイッチは、これに応じて、エッジ４０へ接続する（ステップＳ１１７）。ルータ・スイッチは、当該エッジ４０に対する通信のトラヒックをトラヒック監視部１３へ通知する（ステップＳ１１８）。

【0090】

トラヒック監視部１３は、当該通知に基づいて、トラヒック情報を更新要求、更新完了通知を受領する（ステップＳ１１９、ステップＳ１２０）。

【0091】

トラヒック監視部１３は、定期的にステップＳ１１３で取得したＵＥ側のトラフィックと、ステップＳ１１８で取得したＷＡＮ側のトラフィックとを比較をして、予め定められた閾値以上に差がある場合等の条件を満たした場合、配置計算部１４へ通知する（ステップＳ１２１）。配置計算部１４は、配置情報記憶部１１へサービスポリシーテーブルとトラヒック情報テーブルの取得要求をして（ステップＳ１２２）、配置情報記憶部１１からサービスポリシーテーブル及びトラヒック情報テーブルを取得する（ステップＳ１２３）。

【0092】

配置計算部１４は、上述のＵＥ側のトラヒックとＷＡＮ側のトラヒックとを比較した結果に基づいて処理装置を変更する（ステップＳ１２４）。配置計算部１４は、実行場所管理テーブル及びトラヒック情報テーブルの更新要求をして（ステップＳ１２５）、当該更新結果を受け取ると（ステップＳ１２６）、再配置・監視先・変更通知を配置指示部１５へ行う（ステップＳ１２７）。ステップＳ１２８〜ステップＳ１４５の処理は、ＭＡＮＯ３０とＳＰＧＷ間におけるフロー切替指示の処理（図１０のステップＳ６７及びステップＳ６８）が、図１２のシーケンスには含まれないこと以外、図１０のステップＳ６１〜ステップＳ８２と同様のため、説明を省略する。

【0093】

図１３に示すフローチャートを用いて、配置計算部１４が移動判定をする処理（図１２に示すステップＳ１２４）を説明する。

【0094】

配置計算部１４は、常時移動変更イベントの待ち受けをする（ステップＳ１５１）。トラヒック監視部１３からの通知を受信した場合、どちらの方が帯域利用（すなわち、１秒あたりの通信量）が多いかを確認する（ステップＳ１５２）。この結果、ＷＡＮ側の方が多い場合、遅延要求を満たす範囲でＤＣ（データセンタ７０）側に変更する（ステップＳ１５３）。ＵＥ側の方が多い場合、遅延要求を満たす範囲でＵＥ側に変更する（ステップＳ１５４）。ここで、ＤＣ側への変更とは、ＲＡＮのエッジ４０からコアネットワークのエッジ４０又はデータセンタ７０への変更や、コアネットワークのエッジ４０からデータセンタ７０への変更をいう。また、ＵＥ側への変更とは、データセンタ７０からコアネットワークのエッジ４０又はＲＡＮのエッジ４０への変更や、コアネットワークのエッジ４０からＲＡＮのエッジ４０への変更をいう。また、配置計算部１４は、予め設定されている遅延時間の閾値に基づいて、遅延要求を満たす範囲で変更先を決める。配置計算部１４は、トラヒック情報テーブルにおける、変更先となるエッジのＵＥ側の遅延時間が、上記閾値以下であるか否かを判断して、遅延要求を満たすか否かを判断する。

【0095】

ここで、図１４に、エッジ４０で実施していたときにデータセンタ７０へ移動する例を示す。エッジ４０で処理を実施していた結果、図１４（Ａ）に示すように、サービス１のエッジ２について、利用帯域がＷＡＮ側の方が多くなる。これに応じて、図１４（Ｂ）に示すようにエッジ４０からデータセンタ７０へ変更する。

【0096】

続いて、図１５〜図１７を用いて変形例の説明をする。この変形例は、エッジ４０の処理負荷状況が規制条件を満たしている場合に、当該処理負荷状況が規制解除の条件を満たすまでデータセンタ７０で処理をさせる処理である。

【0097】

図１５に示したシーケンス図は、図９に示すシーケンス図と共通している部分を多く含むので、図９に示すシーケンス図と異なる部分を中心に説明する。

【0098】

ＯＳＳ／ＢＳＳ２０が、ポリシー登録の完了通知をデータセンタ７０へ通知した後に、データセンタ７０及びエッジ４０は、ＯＳＳ／ＢＳＳ２０へデータセンタ７０及びエッジ４０の処理負荷状況を示す情報を通知する（ステップＳ２４Ａ及びステップＳ２４Ｂ）。ＯＳＳ／ＢＳＳ２０は、データセンタ７０及びエッジ４０から処理負荷状況を示す情報を受信すると、図１６に示すような、処理負荷状況テーブルへ当該処理負荷状況を示す情報を装置（場所）毎に記憶する。図１６に示すように、ＯＳＳ／ＢＳＳ２０は、場所と処理負荷状況とを対応付けた処理負荷状況テーブルを記憶している。ここで、処理負荷状況とは、リソースの使用率を示す情報である。エッジ１は、処理負荷状況が３０％であるので、新たにＵＥ９０からの処理要求を受け付けることができる余裕があるが、エッジ２は、処理負荷状況が９０％であるので、新たにＵＥ９０からの処理要求を受け付けることができる余裕がない。

【0099】

ステップＳ３０Ａにおいて、配置計算部１４は、上記サービスポリシーテーブルの内容に基づいて、実行対象の装置（エッジ４０）を決定し、サービスポリシーテーブルのサービス５のポリシーが有効である場合、ＯＳＳ／ＢＳＳ２０に対して、当該エッジ４０の処理負荷状況を問合せる。配置計算部１４は、当該処理負荷状況が上記ポリシーの条件に基づき、規制対象となる場合、データセンタ７０で実行する旨、決定する。例えば、上記問合せ対象のエッジ４０が、図１６に示す例のエッジ２である場合、処理負荷状況が９０％であるので、規制対象となる。また、配置計算部１４は、当初決定していたエッジ４０を監視対象とする。

【0100】

ステップＳ３３Ａにおいて、配置計算部１４は、実行対象の装置（データセンタ７０）及び監視対象を配置指示部１５へ通知する。これに応じて、配置指示部１５は、ＭＡＮＯ３０へＶＭ作成依頼をする（ステップＳ３４）。また、配置指示部１５は、ＭＡＮＯ３０を介してＯＳＳ／ＢＳＳ２０に対して上記監視対象のエッジ４０を監視させる。ＭＡＮＯ３０は、データセンタ７０へＶＭ作成依頼をし（ステップＳ３５Ａ）、データセンタ７０は、ＶＭ起動・エッジアプリを起動する（ステップＳ３６Ａ）。データセンタ７０は、エッジアプリ起動完了すると、その旨をＭＡＮＯ３０へ通知する（ステップＳ３７Ａ）。なお、データセンタ７０は、予めＶＭ及びエッジアプリを起動していてもよい。上記のように、配置指示部１５は、ＵＥ９０からの要求処理をデータセンタ７０に処理させるので、ＵＥ９０が接続要求をすると（ステップＳ４６Ａ）、ＳＰＧＷを介してデータセンタ７０と接続する。

【0101】

続いて、図１７を用いて、データセンタ７０からエッジ４０へＶＭを移動する処理（ＵＥ９０からの処理要求を実行するＶＭをデータセンタ７０からエッジ４０へ変更する処理）の例を説明する。図１７に示す処理は、図１０の処理とは異なる部分を中心に説明する。

【0102】

ＵＥ９０から処理要求がなされると（ステップＳ５１）、ルータ・スイッチを通じてＳＰＧＷを経由し、データセンタ７０へ接続する（ステップＳ５２Ａ）。図１５で説明したように、エッジ４０が監視対象であるので、当該エッジ４０は、定期的にＯＳＳ／ＢＳＳ２０へ処理負荷状況を示す情報を通知する（ステップＳ５２Ｂ）。ＯＳＳ／ＢＳＳ２０は、エッジ４０の処理負荷状況が７０％を下回った場合、シーケンス監視部１２へ、その旨を通知する（ステップＳ５３Ａ）。そして、シーケンス監視部１２は、処理負荷状況が７０％を下回った旨を配置計算部１４へ通知する（ステップＳ５４Ａ）。

【0103】

ＭＡＮＯ３０は、エッジ４０へＤＢレプリケーション先設定要求する（ステップＳ６２Ａ）。エッジ４０は、ＭＡＮＯ３０へＤＢレプリケーション設定完了通知し（ステップＳ６３Ａ）、さらにエッジ４０は、ＶＭ及びエッジアプリを起動する（ステップＳ６５Ａ）。そして、フロー切替がなされた後（ステップＳ６７〜ステップＳ７０）、ＵＥ９０が、接続要求するとエッジ４０へ接続する（ステップＳ７７Ａ、ステップＳ８０）。

【0104】

このように、ＵＥ９０からの要求処理を実行している装置（上述の例ではデータセンタ７０）以外の装置（上述の例では、エッジ４０）の使用状況を監視して、当該使用状況に応じて、ＶＭをデータセンタ７０からエッジ４０へ移動してもよい。

【0105】

上述では記載していないが、ＵＥ９０が、一定期間データの送受信をしていない場合、サービス６のポリシーに基づいて、エッジ４０からデータセンタ７０へＶＭを移動するようにしてもよい。例えば、エッジ４０がＵＥ９０からの要求処理を実行する旨決定された後、ＯＳＳ／ＢＳＳ２０が、ＵＥ９０からの処理要求を監視した結果、ＵＥ９０からエッジ４０へデータの送受信が一定期間無い場合、エッジ４０からデータセンタ７０へＶＭを移動する。この後で、ＵＥ９０から処理要求がなされたことをＯＳＳ／ＢＳＳ２０が検知すると、ＯＳＳ／ＢＳＳ２０がノード変更装置１０の配置計算部１４へ通知する。配置計算部１４は、当該通知を受信すると、データセンタ７０からエッジ４０へ変更する。また、データ通信中／データの通信の無い状態など通信端末のデータ通信状態に関する情報以外に、通信端末のデータ通信頻度（単位時間当たりの通信量・回数）に関わる情報、通信端末で利用しているサービスに求められるデータ通信の遅延要求が厳しい／緩い状態などに基づいて、ＶＭの変更を判断してもよい。このように、ＵＥ９０のサービス利用状態（ＵＥ９０からエッジ４０への要求処理状態）に基づいて、エッジ４０からデータセンタ７０へＶＭを変更するようにしてもよいし、データセンタ７０からエッジ４０へＶＭを変更するようにしてもよい。

【0106】

上述の実施形態では、課金限界通知に基づいて、ＲＡＮのエッジ４０からデータセンタ７０へＶＭを移動させる場合について述べたが、ＲＡＮのエッジ４０からコアネットワークのエッジ４０へ移動させるようにしてもよい。

【0107】

上述の実施形態では、ノード変更装置１０が１台のサーバ装置により実現する場合について述べたが、当該ノード変更装置１０が有する機能を複数のサーバ装置により実現するようにしてもよい。

【0108】

上述の実施形態では、特に述べてなかったが、ノード変更装置１０が移動先のノードに移動可能か否かを判断するようにしてもよい。当該判断の例として、ノード変更装置１０が、移動先ノードのＣＰＵ数、メモリ量、ディスク量（ディスク容量）、移動先ノードに接続される通信端末数／セッション数及びＮＷ帯域の情報をＭＡＮＯ３０から取得し、取得した情報と、予め設定されている閾値とを比較して移動先のノードへ移動可能か否かを判断する。また、上記判断の別の例として、ノード変更装置１０が、移動先のノードが処理を行なうために必要となるノード（例えば、ＳＰＧＷ６０、ローカルゲートウェイ（ＬＧＷ）、ＤＰＩ（Deep Packet Inspection）、ＤＮＳ（Domain Name Server）等）の負荷量を示す情報をＭＡＮＯ３０から取得して、取得した情報と、予め設定されている閾値とを比較して移動先のノードへ移動可能か否かを判断してもよい。なお、上記の移動先のノードが処理を行なうために必要となるノードが仮想化されてない装置である場合、各移動先のノードで上記負荷量を管理したり、モバイルエッジコンピュータ専用の管理システム（ＭＡＮＯ３０とは別のシステム）で上記負荷量を管理したりしてもよい。また、上記判断の別の例として、ノード変更装置１０が、移動先のノードにおける無線設備の容量（無線のリソースブロックの使用率、基地局装置のＣＰＵ使用率等）の情報を基地局装置又はＭＡＮＯ３０（基地局装置が仮想化基盤で管理されている場合）から取得して、取得した情報と、予め設定されている閾値とを比較して移動先のノードへ移動可能か否か判断してもよい。

【0109】

ノード変更装置１０が移動先のノードに移動可能か否かを判断した結果、移動不可と判断した場合、移動先のノードに割り当てられている優先度の低いアプリケーションを別のノードに移動させてから再度移動させる。また、ノード変更装置１０が移動先のノードに移動可能か否かを判断した結果、移動不可と判断した場合、ＳＰＧＷ６０やＤＮＳ等、スケールアウトやスケールアップ等によって設備増強可能である場合には、増強後に移動させる。

【0110】

次に、本実施形態におけるノード変更装置１０の作用効果について説明する。本実施形態のノード変更装置１０において、シーケンス監視部１２が、ＵＥ９０による第１ノード（例えば、ＲＡＮに接続しているエッジ４０）の使用状態を示す情報（例えば、課金上限通知）を取得する。配置計算部１４は、上記課金上限通知に基づいて、ＵＥ９０からの要求処理を実行するノードを、ＲＡＮに接続しているエッジ４０からデータセンタ７０（ネットワーク階層が異なる第２ノード）へ変更する。具体的には、エッジ４０は、ＶＭ・エッジアプリを起動することにより、ＵＥ９０からの要求処理を実行しており、配置計算部１４及び配置指示部１５は、ＶＭをデータセンタ７０へ移動させ、エッジアプリをデータセンタ７０で実行させる。これにより、使用情報に基づいて、ＵＥ９０の要求処理を実行するノードを別ネットワークのノードに処理を変更するので、使用状態に応じて、コストと速度とのバランスを取ることができる。

【0111】

変更前のノードであるエッジ４０と、変更後のノードであるデータセンタ７０とは、接続されているネットワークの種類が互いに異なる。エッジ４０は、ＲＡＮに接続しており、データセンタ７０は、ＷＡＮに接続している。ＲＡＮに接続しているエッジ４０は、ＷＡＮに接続しているデータセンタ７０と比較して、ＵＥ９０までの距離が近いので、データセンタ７０よりエッジ４０の方が、通信遅延が小さい。よって、使用状態に応じて、ＵＥ９０からの要求処理を実行する装置を変えることにより、コストと速度とのバランスを取ることができる。

【0112】

配置計算部１４は、上記のように課金状態が条件（課金上限）を上回る場合（使用状態が予め定められた条件を満たす場合）、要求処理をしているノードのネットワーク（ＲＡＮ）と比較して、ＵＥ９０からの距離が長いネットワーク（ＷＡＮ）に接続されているデータセンタ７０に変更する。このように、使用状態に基づいて階層が異なるネットワークのノードに変更するので、処理負荷やネットワークの利用帯域量を分散させることができる。

【0113】

また、トラヒック監視部１３は、外部ネットワークを用いたＵＥ９０の使用状態を示す使用情報と、ＲＡＮによるＵＥ９０の使用状態を示す使用情報とを取得する。配置計算部１４は、ＷＡＮを介したＵＥ９０の使用状態を示す使用情報と、ＲＡＮによるＵＥ９０の使用状態を示す使用情報とを比較した結果に基づいて、ＵＥ９０からの要求処理を実行するノードを他のネットワークのノードに切り替える。これにより、外部ネットワークと自己ネットワークの使用状態を比較して、処理ノードを移動させるので、外部ネットワークからの通信端末と、自己ネットワークからの通信端末とのそれぞれの処理速度を調整することができる。

【0114】

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

【0115】

また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。

【0116】

本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

【0117】

なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ）は、キャリア周波数、セルなどと呼ばれてもよい。

【0118】

本明細書で使用する「システム」および「ネットワーク」という用語は、互換的に使用される。

【0119】

また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。

【0120】

上述したパラメータに使用する名称はいかなる点においても限定的なものではない。さらに、これらのパラメータを使用する数式等は、本明細書で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素（例えば、ＴＰＣなど）は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的なものではない。

【0121】

基地局は、１つまたは複数（例えば、３つ）の（セクタとも呼ばれる）セルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）によって通信サービスを提供することもできる。「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、および／または基地局サブシステムのカバレッジエリアの一部または全体を指す。さらに、「基地局」「ｅＮＢ」、「セル」、および「セクタ」という用語は、本明細書では互換的に使用され得る。基地局は、固定局（fixed station）、ＮｏｄｅＢ、ｅＮｏｄｅＢ（ｅＮＢ）、アクセスポイント（access point）、フェムトセル、スモールセルなどの用語で呼ばれる場合もある。

【0122】

移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

【0123】

また、本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)（例えば、情報を送信すること）、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。

【0124】

「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。本明細書で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及び／又はプリント電気接続を使用することにより、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどの電磁エネルギーを使用することにより、互いに「接続」又は「結合」されると考えることができる。

【0125】

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

【0126】

本明細書で使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１および第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

【0127】

また、上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。

【0128】

「含む(ｉｎｃｌｕｄｉｎｇ)」、「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。

【0129】

なお、情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、報知情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。

【0130】

また、本明細書で説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future Radio Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。

【0131】

また、本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

【0132】

また、本明細書において基地局によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。基地局を有する１つまたは複数のネットワークノード（network nodes）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局および／または基地局以外の他のネットワークノード(例えば、MMEまたはS-GWなどが考えられるが、これらに限られない)によって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ(例えば、MMEおよびS-GW)であってもよい。

【0133】

上記の情報等は、上位レイヤ（または下位レイヤ）から下位レイヤ（または上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。

【0134】

入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

【0135】

判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値(Boolean：trueまたはfalse)によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

【0136】

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

【0137】

本開示の全体において、明らかに単数であることを示しているものではない限り、単数および複数の両方のものを含むものとする。

【0138】

以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

【符号の説明】

【0139】

１…通信システム、１０…ノード変更装置、１１…配置情報記憶部、１２…シーケンス監視部、１３…トラヒック監視部、１４…配置計算部、１５…配置指示部、２０…ＯＳＳ／ＢＳＳ、３０…ＭＡＮＯ、４０…エッジ、５０…ＭＭＥ、６０…ＳＰＧＷ、７０…データセンタ、８０…ｅＮｏｄｅＢ、９０…ＵＥ、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】