特許 7758041 通信装置、通信方法、および通信システム

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

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

(11)【特許番号】

(24)【登録日】2025-10-14

(45)【発行日】2025-10-22

(54)【発明の名称】通信装置、通信方法、および通信システム

(51)【国際特許分類】

   G06N 3/04 20230101AFI20251015BHJP

   H04L 45/12 20220101ALI20251015BHJP

   H04L 45/00 20220101ALI20251015BHJP

【ＦＩ】

G06N3/04

H04L45/12

H04L45/00

【請求項の数】 23

(21)【出願番号】P 2023531450

(86)(22)【出願日】2022-03-29

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

(87)【国際公開番号】W WO2023276382

(87)【国際公開日】2023-01-05

【審査請求日】2025-02-10

(31)【優先権主張番号】P 2021110381

(32)【優先日】2021-07-01

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】100120031

【弁理士】

【氏名又は名称】宮嶋 学

(72)【発明者】

【氏名】内山 博允

(72)【発明者】

【氏名】松田 大輝

(72)【発明者】

【氏名】示沢 寿之

【審査官】宮司 卓佳

(56)【参考文献】

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

【文献】特開２０１９－１４８８７６（ＪＰ，Ａ）

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

【文献】TEERAPITTAYANON, S. et al.，Distributed Deep Neural Networks over the Cloud, the Edge and End Devices，arXiv.org [online], [text]，米国，Cornell University，2017年09月06日，[retrieved on 2025.09.04], Retrieved from <https://arxiv.org/pdf/1709.01921>，<DOI: 10.48550/arxiv.1709.01921>

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

Ｇ０６Ｎ ３／００－９９／００

Ｇ０６Ｆ １８／００－１８／４０

Ｈ０４Ｌ ４５／００－４５／１２８

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

【請求項1】

ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する情報処理装置であって、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行い、
前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第１範囲に続く第２範囲の計算担当である第２の通信装置に送信し、
前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信する、
情報処理装置。

【請求項2】

前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定されなかった場合には、前記第１範囲に含まれる計算の少なくとも一部を実行し、実行された計算の結果を、前記第２の通信装置に送信する前記計算の結果として用い、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合には、前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、実行された計算の結果を、前記第１の通信装置に送信するための前記計算に用いる、
請求項１に記載の情報処理装置。

【請求項3】

前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、
前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記判定の前に実行された前記計算の結果を前記第１の通信装置に送信するための前記計算に用いる、
請求項１に記載の情報処理装置。

【請求項4】

前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、
前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記判定の前に実行された前記計算の結果を前記第２の通信装置に送信する前記計算の結果として用いる、
請求項１に記載の情報処理装置。

【請求項5】

前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、
前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算を継続し、前記第１範囲の計算の結果を前記第２の通信装置に送信する前記計算の結果として用いる、
請求項１に記載の情報処理装置。

【請求項6】

前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、さらに、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第２の通信装置に送信する、
請求項１に記載の情報処理装置。

【請求項7】

前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算の全てが実行されなかったときは、実行された計算の結果とともに、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報を、前記第２の通信装置に送信する、
請求項６に記載の情報処理装置。

【請求項8】

前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記一連の計算の少なくとも一部を実行可能な第３の通信装置に送信する、
請求項１に記載の情報処理装置。

【請求項9】

前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算の所定位置までを実行し、実行された計算の結果を、前記第１の通信装置に送信するための前記計算に用いる、
請求項１に記載の情報処理装置。

【請求項10】

前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算のいずれの位置まで実行するかを決定し、前記第１範囲に含まれる計算を決定された位置まで実行し、実行された計算の結果と、決定された位置を示す情報と、を前記第２の通信装置に送信する、
請求項１に記載の情報処理装置。

【請求項11】

前記ディープニューラルネットワークの一連の計算のうちの少なくとも一部を担当する装置の計算余力に関する情報、前記ディープニューラルネットワークの一連の計算のうちの少なくとも一部を担当する装置におけるトラフィック量に関する情報、のうちの少なくとも１つに基づいて前記判定を行う、
請求項１に記載の情報処理装置。

【請求項12】

前記第１の通信装置との間の通信品質、前記第１の通信装置のモビリティ情報、のうちの少なくとも１つに基づいて前記判定を行う、
請求項１に記載の情報処理装置。

【請求項13】

前記一連の計算を途中終了することを指示する情報、前記一連の計算における途中の計算の結果を前記第１の通信装置に送信することを指示する情報、のうちの少なくとも１つに基づいて前記判定を行う、
請求項１に記載の情報処理装置。

【請求項14】

前記第１の通信装置から要求情報を取得し、前記要求情報に基づいて前記判定を行う、
請求項１に記載の情報処理装置。

【請求項15】

前記第１範囲の計算に必要な時間が与えられた許容時間よりも大きい場合に、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定する、
請求項１に記載の情報処理装置。

【請求項16】

ディープニューラルネットワークの一連の計算のうちの第１範囲に含まれる計算を途中終了するか否かの判定を行い、
前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第１範囲に続く第２範囲の計算担当である装置に送信する、
情報処理装置。

【請求項17】

前記第２範囲の計算担当である装置が前記第２範囲に含まれる計算を途中終了してもよいか否かを示す情報を、前記第２範囲の計算担当である装置にさらに送信する、
請求項１６に記載の情報処理装置。

【請求項18】

ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する情報処理装置において実行される情報処理方法であって、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行うステップと、
前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第１範囲に続く第２範囲の計算担当である第２の通信装置に送信するステップと、
前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を用いて前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信するステップと、
を備える情報処理方法。

【請求項19】

ディープニューラルネットワークの一連の計算のうちの第１範囲に含まれる計算を途中終了するか否かの判定を行うステップと、
前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第１範囲に続く第２範囲の計算担当である装置に送信するステップと、
を備える情報処理方法。

【請求項20】

ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する第１情報処理装置および第２情報処理装置を少なくとも備え、
前記第１情報処理装置は、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行い、
前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第２情報処理装置に送信し、
前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を用いて前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信し、
前記第２情報処理装置は、
前記一連の計算のうちの前記第１情報処理装置によって実行された計算以降の計算を前記第１情報処理装置によって実行された計算の結果に基づいて実行する、
情報処理システム。

【請求項21】

少なくとも、ディープニューラルネットワークの一連の計算のうちの第１範囲の計算を行う第１情報処理装置と、前記ディープニューラルネットワークの一連の計算のうちの前記第１範囲に続く第２範囲の計算を行う第２情報処理装置と、を備え、
前記第１情報処理装置は、
前記第１範囲に含まれる計算を途中終了するか否かの判定を行い、
前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第２情報処理装置に送信し、
前記第２情報処理装置は、
前記情報を受け取ったときは、前記一連の計算の前記第１情報処理装置によって実行された計算の続きを、前記第１情報処理装置によって実行された計算の結果に基づいて実行する、
情報処理システム。

【請求項22】

前記第１範囲を決定する第３情報処理装置
をさらに備える請求項２０に記載の情報処理システム。

【請求項23】

前記第１範囲に含まれる計算を途中終了するか否かの判定を行う第３情報処理装置
をさらに備え、
前記第３情報処理装置は、前記第１範囲に含まれる計算を途中終了する指示を前記第１情報処理装置に送信し、
前記第１情報処理装置は、前記指示を受け取った場合に、前記第１範囲に含まれる計算を途中終了すると判定する、
請求項２１に記載の情報処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、通信装置、通信方法、および通信システムに関する。

【背景技術】

【0002】

近年、人工知能、機械学習といった分野の研究が急速に進んでおり、これらに関するアプリケーションも急速に普及すると予想されている。そのため、当該アプリケーションを通信環境で快適に動作させるための検討が行われている。

【0003】

当該アプリケーションは、主に、機械学習によって内部パラメータが最適化された、複数のレイヤを有するニューラルネットワーク（ＤＮＮ：Deep Neural Network）に基づく計算を行う。当該計算は、他の一般的なアプリケーションよりも負荷が大きい。そのため、スマートフォンなどの汎用の無線通信端末で当該アプリケーションを実行すると、計算時間、消費電力などが増加するといった問題が生じる。一方、クラウドサーバーが当該計算を代行する方法も考えられる。しかし、当該方法では、無線通信端末は、当該計算に必要な情報をクラウドサーバーに送信し、クラウドサーバーから計算結果を受信することになるため、通信量が多くなる。さらに無線通信の場合では、通信品質が不安定なため、遅延が生じやすい。したがって、当該方法では、アプリケーションが許容できる遅延量を超えてしまう恐れがある。

【0004】

そこで、ＤＮＮの計算を、通信端末、クラウドサーバーなどに一極集中させる統合学習（Federated Learning）ではなく、ＤＮＮの計算を通信端末およびクラウドサーバーの両方に分散させる分散学習（Distributed Learning）が検討されている。つまり、通信端末がＤＮＮの計算の一部を担当し、クラウドサーバーがＤＮＮの計算の残りを担当することが検討されている。

【先行技術文献】

【非特許文献】

【0005】

【文献】3GPP(3rd Generation Partnership Project), "TR(Technical Report) 22.874, V0.1.0, Study on traffic characteristics and performance requirements for AI/ML model transfer"（5章 Split AI/ML operation between AI/ML endpoints）, URL:https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3721

【文献】"BranchyNet: Fast Inference via Early-exiting from Deep Neural Networks," Surat Teerapittayanon, et al., "http://bradmcdanel.com/files/2016-icpr-teerapittayanon-mcdanel-kung.pdf"

【文献】"Distributed Deep Neural Networks over the Cloud, the Edge and End Devices," Surat Teerapittayanon, et al.," https://arxiv.org/pdf/1709.01921.pdf"

【発明の概要】

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

【0006】

さらに、通信端末とクラウドサーバーとの通信を中継する通信ネットワークが、ＤＮＮの計算の一部を分担することも検討されている。つまり、通信ネットワークを構成する複数の通信ノードの少なくともいずれかがＤＮＮの入力層から出力層までの一連の計算の一部を担当し得る。しかし、ＤＮＮの計算を多数の装置に分散させることによって弊害も生じ得る。例えば、計算を担当する通信ノードの負荷、ネットワークの通信品質などは、常に安定しているとは限らない。ゆえに、状況によっては、想定よりも計算に時間がかかる場合もあり得る。

【0007】

そこで、本開示は、ＤＮＮに基づく計算を分散させつつ、計算結果を返信するまでに要する時間を短縮する情報処理装置などを提供する。具体的には、計算を担当する装置の動的変更や、当該計算を途中終了すること、当該計算の途中の結果をフィードバックすることにより、実現する。また、ここで示した課題は本発明が解決する課題の一部に過ぎず、本開示により解決されうるその他の課題のために本開示が用いられても良い。

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

【0008】

本開示による情報処理装置は、ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する情報処理装置であって、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行い、前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第１範囲に続く第２範囲の計算担当である第２の通信装置に送信し、前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信する。

【0009】

また、前記情報処理装置は、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定されなかった場合には、前記第１範囲に含まれる計算の少なくとも一部を実行し、実行された計算の結果を、前記第２の通信装置に送信する前記計算の結果として用いてもよいし、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合には、前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、実行された計算の結果を、前記第１の通信装置に送信するための前記計算に用いてもよい。

【0010】

また、前記情報処理装置は、前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記判定の前に実行された前記計算の結果を前記第１の通信装置に送信するための前記計算に用いてもよい。

【0011】

また、前記情報処理装置は、前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記判定の前に実行された前記計算の結果を前記第２の通信装置に送信する前記計算の結果として用いてもよい。

【0012】

また、前記情報処理装置は、前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算を継続し、前記第１範囲の計算の結果を前記第２の通信装置に送信する前記計算の結果として用いてもよい。

【0013】

また、前記情報処理装置は、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、さらに、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第２の通信装置に送信してもよい。

【0014】

また、前記情報処理装置は、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算の全てが実行されなかったときは、実行された計算の結果とともに、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報を、前記第２の通信装置に送信してもよい。

【0015】

また、前記情報処理装置は、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記一連の計算の少なくとも一部を実行可能な第３の通信装置に送信してもよい。

【0016】

また、前記情報処理装置は、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算の所定位置までを実行し、実行された計算の結果を、前記第１の通信装置に送信するための前記計算に用いてもよい。

【0017】

また、前記情報処理装置は、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算のいずれの位置まで実行するかを決定し、前記第１範囲に含まれる計算を決定された位置まで実行し、実行された計算の結果と、決定された位置を示す情報と、を前記第２の通信装置に送信してもよい。

【0018】

また、前記情報処理装置は、前記ディープニューラルネットワークの一連の計算のうちの少なくとも一部を担当する装置の計算余力に関する情報、前記ディープニューラルネットワークの一連の計算のうちの少なくとも一部を担当する装置におけるトラフィック量に関する情報、のうちの少なくとも１つに基づいて前記判定を行ってもよい。

【0019】

また、前記情報処理装置は、前記第１の通信装置との間の通信品質、前記第１の通信装置のモビリティ情報、のうちの少なくとも１つに基づいて前記判定を行ってもよい。

【0020】

また、前記情報処理装置は、前記一連の計算を途中終了することを指示する情報、前記一連の計算における途中の計算の結果を前記第１の通信装置に送信することを指示する情報、のうちの少なくとも１つに基づいて前記判定を行ってもよい。

【0021】

また、前記情報処理装置は、前記第１の通信装置から要求情報を取得し、前記要求情報に基づいて前記判定を行ってもよい。

【0022】

また、前記情報処理装置は、前記第１範囲の計算に必要な時間が与えられた許容時間よりも大きい場合に、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定してもよい。

【0023】

また、前記情報処理装置は、ディープニューラルネットワークの一連の計算のうちの第１範囲に含まれる計算を途中終了するか否かの判定を行い、前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第１範囲に続く第２範囲の計算担当である装置に送信してもよい。

【0024】

また、前記情報処理装置は、前記第２範囲の計算担当である装置が前記第２範囲に含まれる計算を途中終了してもよいか否かを示す情報を、前記第２範囲の計算担当である装置にさらに送信してもよい。

【0025】

本開示の他の一態様である情報処理方法は、ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する情報処理装置において実行される情報処理方法であって、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行うステップと、前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第１範囲に続く第２範囲の計算担当である第２の通信装置に送信するステップと、前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を用いて前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信するステップと、を備える。

【0026】

本開示の別の情報処理方法は、ディープニューラルネットワークの一連の計算のうちの第１範囲に含まれる計算を途中終了するか否かの判定を行うステップと、前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第１範囲に続く第２範囲の計算担当である装置に送信するステップと、を備える。

【0027】

本開示の他の一態様である情報処理システムは、ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する第１情報処理装置および第２情報処理装置を少なくとも備え、前記第１情報処理装置は、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行い、前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第２情報処理装置に送信し、前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を用いて前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信し、前記第２情報処理装置は、前記一連の計算のうちの前記第１情報処理装置によって実行された計算以降の計算を前記第１情報処理装置によって実行された計算の結果に基づいて実行する、情報処理システム。

【0028】

前記情報処理システムは、前記第１範囲を決定する第３情報処理装置をさらに備えてもよい。

【0029】

本開示の別の情報処理システムは、少なくとも、ディープニューラルネットワークの一連の計算のうちの第１範囲の計算を行う第１情報処理装置と、前記ディープニューラルネットワークの一連の計算のうちの前記第１範囲に続く第２範囲の計算を行う第２情報処理装置と、を備え、前記第１情報処理装置は、前記第１範囲に含まれる計算を途中終了するか否かの判定を行い、前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第２情報処理装置に送信し、前記第２情報処理装置は、前記情報を受け取ったときは、前記一連の計算の前記第１情報処理装置によって実行された計算の続きを、前記第１情報処理装置によって実行された計算の結果に基づいて実行する。

【0030】

前記別の情報処理システムは、前記第１範囲に含まれる計算を途中終了するか否かの判定を行う第３情報処理装置をさらに備え、前記第３情報処理装置は、前記第１範囲に含まれる計算を途中終了する指示を前記第１情報処理装置に送信し、前記第１情報処理装置は、前記指示を受け取った場合に、前記第１範囲に含まれる計算を途中終了すると判定してもよい。

【図面の簡単な説明】

【0031】

【図1】本開示の実施形態に係る情報処理システムの構成例を示す図。

【図2】ＤＮＮを説明する図。

【図3】ＤＮＮの計算の分散について説明する図。

【図4】Splitting pointに応じた遅延および出力データ量の相違について説明する図。

【図5】ＩＡＢネットワークのアーキテクチャの例を示す図。

【図6】ＤＮＮの計算の分散の効果を示す図。

【図7】シミュレーションに用いたＩＡＢネットワークにおけるネットワークトポロジーの図。

【図8】シミュレーシのための通信容量の変動を示す図。

【図9】通信ネットワークのリソースが実行遅延に与える影響を示す図。

【図10】本実施形態の全体処理の流れを示した概略シーケンス図。

【図11】Splitting modeを説明する図。

【図12】通信ルートごとに設定されたSplitting modeについて説明する図。

【図13】通信ルートごとのSplitting modeの例を示す図。

【図14】計算担当が切り替えられる前後のシーケンス図。

【図15】通信端末の担当範囲を決定するための条件の一例を示す図。

【図16】通信端末が自身の担当範囲を決定した場合に、通信端末から送信される計算結果の一例を示す図。

【図17】通信端末が自身の担当範囲を決定する場合の全体処理の流れを示した概略シーケンス図。

【図18】基地局装置の構成例を示す図。

【図19】通信端末の構成例を示す図。

【図20】コアネットワークを含む５ＧＳ（5G System）のネットワークアーキテクチャの構成例を示す図。

【図21】Early-exitingを行う場合の計算範囲の例を示す図。

【図22】Early-exitingに関する処理の流れの第１例を示した概略シーケンス図。

【図23】Early-exitingに関する処理の流れの第２例を示した概略シーケンス図。

【図24】Early-exitingに関する処理の流れの第３例を示した概略シーケンス図。

【図25】マルチフィードバックを説明する概念図。

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

【0032】

（第１実施形態）
以下に、本開示の実施形態について図面に基づいて詳細に説明する。図１は、本開示の第１実施形態に係る情報処理システムの構成例を示す図である。第１実施形態に係る情報処理システム１は、通信端末１１と、クラウドシステム（Cloud）１２と、通信ネットワーク１３と、を備える。なお、符号は、図１に示された１１Ａおよび１１Ｂのように、同じ種類の個体に対し同一の数字を振ることとし、各個体の区別はアルファベットによって行うものとする。また、本説明において、特に個体を区別する必要がない場合は、符号のアルファベットは記載しない。

【0033】

情報処理システム１は、機械学習（ＭＬ：Machine Learning）によって学習されたディープニューラルネットワーク（ＤＮＮ：Deep Neural Network）を利用したアプリケーションを動作させるためのシステムである。以降、当該アプリケーションを、ＭＬアプリケーションと記載する。

【0034】

通信端末１１は、ＭＬアプリケーションを起動することが可能な情報処理装置でもあり、スマートフォン、ラップトップなどが該当する。例えば、スマートフォンにＭＬアプリケーションがインストールされており、スマートフォンのユーザによってＭＬアプリケーションが起動されることが想定される。また、通信端末１１の形状は、特に限られるわけではない。例えば、眼鏡のようなウェアラブル端末でもよい。また、ＭＬアプリケーションによってその動作が制御されるロボットも通信端末１１に該当する。クラウドシステム１２は、クラウドサーバーと呼ばれる、通信端末１１よりも高性能な１台以上の情報処理装置を含み、通信端末１１によって利用可能なサービスを提供する。通信ネットワーク１３は、複数の通信ノードから構成され、通信端末１１とクラウドシステム１２との通信を中継する。なお、通信ノードは、通信基地局とも称される。

【0035】

なお、図１では、通信ネットワーク１３に無線通信ネットワークが含まれる例が示されている。図１の例では、第５世代移動通信システム（５Ｇ）の無線通信に用いられるＩＡＢ（Integrated Access and Backhaul）ネットワークを用いた例が示されており、通信端末１１は無線通信端末で示されており、通信ネットワーク１３は、通信端末１１と無線通信接続可能な無線通信ノード１３１と、１以上の無線通信ノード１３１の上位ノードであるドナーノード１３２と、ドナーノード１３２とクラウドシステム１２との有線通信を行うコア（Core）ネットワーク１３３と、から構成されている。図１のように、有線通信よりも通信品質が不安定な無線通信ネットワークが通信ネットワーク１３に含まれているほうが、後述する効果が従来よりも大きくなるため、好ましい。ただし、情報処理システム１の通信が全て有線通信であってもよいし、通信ネットワーク１３に含まれ得る無線通信ネットワークがＩＡＢネットワークに限られるわけでもない。

【0036】

図２は、ＤＮＮを説明する図である。図２の点線枠２に囲まれたネットワークがＤＮＮに相当する。ＤＮＮは、複数のノード２１と、ノード２１同士を接続するリンク２２と、から構成される。また、図２に示すように、複数のノード２１は、縦一列に並ぶノード群に分けられており、当該ノード群はレイヤ（階層）と称される。図２の例では、ＤＮＮは、七つのレイヤを有しているが、ＤＮＮが有するレイヤは三つ以上であればよい。

【0037】

ＤＮＮの計算は、ノード２１ごとに行われる。例えば、図２では、画像の情報が入力層と呼ばれる最初のレイヤの各ノード２１に入力されており、第１レイヤの各ノード２１において計算が行われる。これらの計算結果は、リンク２２を介して、第２レイヤの各ノード２１に送られ、第２レイヤの各ノード２１においても計算が行われる。このように、入力層のほうから計算が行われていき、出力層と呼ばれる最後のレイヤのノードから最終的な計算結果が出力される。そして、出力された計算結果に基づいて、入力画像に写されている物体が猫と判定されることになる。

【0038】

なお、図２では、画像認識の例を示したが、ＭＬアプリケーションの用途などは、特に限られるものではない。例えば、画像認識以外にも、ｘＲと総称される、ＡＲ（Augmented Reality）、ＶＲ（Virtual Realty）、ＭＲ（Mixed Realty）などでもよい。また、自動運転、ロボティクス、音声認識などが、ＤＮＮを利用して実現可能であり、ＭＬアプリケーションが、このような用途に関するものであってもよい。また、ＭＬアプリケーションの実施環境も特に限られるものではなく、デジタルツイン、Tactile internetといったシステムにおいて用いられてもよい。

【0039】

通信端末１１に該当するスマートフォンなどは、一般的に、クラウドサーバーに比べてスペックが低い。そのため、ＭＬアプリケーションの処理、特にＤＮＮの計算を、そのまま全て通信端末１１に行わせた場合（In device learning）、完了までの計算時間が長くなる。言い換えれば、大きな計算遅延が発生する。しかし、ＭＬアプリケーションの仕様上、ＭＬアプリケーションの実行に要する時間を所定の許容限度内に収めるように要求される場合もあり、通信端末１１にＤＮＮの計算を全て任せると、計算遅延が許容限度を超えてしまう恐れがある。

【0040】

一方、ＤＮＮの計算を、通信端末１１ではなく、クラウドシステム１２に実行させた場合（Cloud learning）では、通信に要する時間、言い換えれば、通信遅延が問題となる。例えば、撮影を行いながら災害の被害者を探索する救助ロボットなどでは、電力を過度に消費する計算をクラウドサーバーに実行させて、消費電力を抑えるといったことが行われている。しかし、ロボットからクラウドサーバーに必要なデータを送る必要があり、それによる通信遅延が増加することによって、通信遅延と計算遅延の和がＭＬアプリケーションの許容限度を超えてしまう恐れがある。また、このデータ送信によって帯域が圧迫され、その他の通信にも影響を及ぼす恐れもある。

【0041】

そこで、情報処理システム１は、通信端末１１と、クラウドシステム１２と、通信ネットワーク１３と、のうちから、複数の計算担当を決定し、複数の計算担当にＤＮＮに基づく一連の計算を分散して処理させる。このような処理は、分散学習（Distributed learning）とも称される。ここで、計算担当は、ＤＮＮの計算の少なくとも一部を担当するエンティティを指す。

【0042】

図３は、ＤＮＮの計算の分散について説明する図である。図３（Ａ）および（Ｂ）は分散学習ではない統合学習（Federated Learning）の例を示し、図３（Ｃ）は分散学習の例を示す。

【0043】

図３（Ａ）の例では、計算担当は通信端末１１だけであり、通信端末１１がＤＮＮの計算を行う（In device learning）。前述の通り、データが通信ネットワーク１３に送信されないため、通信遅延は生じないが、通信端末１１の計算能力の低さによる計算遅延が問題となる。一方、図３（Ｂ）の例では、クラウドシステム１２だけがＤＮＮの計算を行い（Cloud learning）、通信端末１１は、計算に必要な情報をクラウドシステム１２に送信し、計算結果をクラウドシステム１２から受信する。通信端末１１の計算能力はそこまで必要なく、クラウドシステム１２での計算遅延も小さい点が優れているが、通信端末１１とクラウドシステム１２との通信遅延が問題となる。

【0044】

それに対し、図３（Ｃ）の例では、通信端末１１、クラウドシステム１２、および通信ネットワーク１３がそれぞれ、ＤＮＮの計算の一部を担当する。言い換えれば、通信ネットワーク１３も、通信端末１１において実行されるＭＬアプリケーションに対して、計算パワーを提供する。クラウドシステム１２の計算能力の高いクラウドサーバーがＤＮＮの計算の一部を担当するため、通信端末１１だけがＤＮＮの計算を行う場合よりも、計算遅延は抑えられる。また、図３（Ｃ）の例では、通信端末１１からの送信データは、通信ネットワーク１３によって受信されて処理された上で、クラウドシステム１２に送信される。通信ネットワーク１３からクラウドシステム１２への送信データが、通信端末１１からの送信データよりも小さくすることができれば通信時間は小さくなるため、クラウドシステム１２だけが計算を行う図３（Ｂ）の場合よりも、通信遅延を減らすことが可能となる。ゆえに、各通信担当がＤＮＮの計算に要する時間である計算遅延と、各通信担当がＤＮＮの計算に必要な情報の通信に要する時間である通信遅延と、の総和が、図３（Ｂ）の場合よりも短くなる可能性がある。

【0045】

このように、本実施形態では、ＤＮＮの一連の計算を分散させて処理することにより、ＭＬアプリケーションの実行に要する時間、より具体的には、ＤＮＮに対する入力が行われてからＤＮＮからの出力が得られるまでの時間を所定の許容限度内に抑える。なお、以降、ＭＬアプリケーションの実行に要する時間を実行遅延と記載する。

【0046】

また、通信ネットワーク１３が計算担当と決定された場合は、さらに、通信ネットワーク１３内の１以上の通信ノードが計算担当と決定される。なお、前述の無線通信ノード１３１およびドナーノード１３２は、通信ノードに該当する。また、コアネットワーク１３３内にも通信ノードが存在し、コアネットワーク１３３の通信ノードも計算担当として選ばれ得る。

【0047】

例えば、図２のＤＮＮは、七つのレイヤを有しているが、第１および第２レイヤを通信端末１１が担当し、第３および第４レイヤを無線通信ノード１３１が担当し、第５から７レイヤをクラウドシステム１２が担当することが示されている。この場合、通信端末１１は、第２レイヤにおける計算結果を無線通信ノード１３１に送信し、無線通信ノード１３１は、第２レイヤにおける計算結果から第３レイヤおよび第４レイヤの計算を行って、第４レイヤの計算結果をクラウドシステム１２に送信し、クラウドシステム１２は、第４レイヤにおける計算結果から第５レイヤから第７レイヤの計算を行う。なお、クラウドシステム１２は、第７レイヤの計算結果を通信端末１１に返信し、通信端末１１が、第７レイヤの計算結果に基づいて、入力が画像猫という判定を行ってもよい。あるいは、クラウドシステム１２は、第７レイヤの計算結果に基づいて入力が画像猫という判定を行い、判定結果を通信端末１１に返信してもよい。

【0048】

なお、ＤＮＮには、畳み込みニューラルネットワーク（ＣＮＮ）などのように様々な種類があるが、ＭＬアプリケーションは、上記のように、レイヤごとに分担して計算が可能なＤＮＮを用いるものとする。

【0049】

なお、本実施形態において、ＤＮＮのパラメータは更新されてもよいし、更新されなくてもよい。すなわち、ＤＮＮは既に学習を完了しており、ＤＮＮのパラメータは更新されないとしてもよい。あるいは、ＭＬアプリケーションを介して、通信端末１１のユーザから正解を受け取り、当該正解に基づいて、学習が実行されてもよい。ただし、学習が実行されてＤＮＮが更新された場合、計算担当によって使用するＤＮＮが異なるという事態を防ぐために、更新された新たなＤＮＮが、計算担当に配布されるものとする。

【0050】

なお、通信ノードが計算担当と決定された場合、実際には、通信ノード内の通信を行うためのインフラストラクチャーに計算を実行させてもよい。あるいは、通信ノード内に計算を実行するサーバーを設けてもよい。なお、通信ノードのようなクラウドサービスよりも利用者に近い場所（エッジとも称される）からクラウドサービスの一部を代行する情報処理装置は、一般的にエッジサーバーと称される。

【0051】

なお、ＤＮＮの計算は、通信端末１１、クラウドシステム１２、および通信ネットワーク１３のそれぞれに分散されるとは限られない。アプリケーションによっては、クラウドシステム１２を利用せずに、通信ネットワーク１３内でＤＮＮの計算を完了させることも可能である。この場合、通信ルートの総距離が短くなるため、通信遅延をさらに低下させることできる。また、通信端末１１はＤＮＮの計算を行わず、クラウドシステム１２および通信ネットワーク１３にＤＮＮの計算が分散される場合もあり得る。あるいは、ＭＬアプリケーションを実行した通信端末１１とは別に、通信ネットワーク１３に接続されていて計算余力が大きい通信端末１１を発見した場合、発見された通信端末１１の承諾を得た上で、発見された通信端末１１にＤＮＮの計算の一部を担当さてもよい。また、通信端末１１とクラウドシステム１２との通信ルート間に存在する通信ノードのうちの少なくとも一つを計算担当にすると予め決めておいてもよい。

【0052】

なお、クラウドシステム１２が最後の計算担当とであるとは限らない。場合によっては、クラウドシステム１２が先に計算を行い、通信ネットワーク１３がクラウドシステム１２の計算を引き継ぐこともあり得る。

【0053】

ＤＮＮの一連の計算を分散させて処理する場合、計算担当に担当させる計算範囲、言い換えれば、担当範囲をどのように決めるかも重要である。さらに言い換えれば、ＤＮＮの一連の計算をどこで分離するかも重要である。ＤＮＮを分離させる場所をSplitting pointとも記載する。図２の例では、Splitting pointは、第２レイヤおよび第３レイヤの間と、第４レイヤおよび５レイヤの間と、に設定されており、ＤＮＮを三つの範囲に分離させている。

【0054】

図４は、Splitting pointに応じた遅延および出力データ量の相違について説明する図である。図４のドット柄の棒グラフは、入力層から当該棒グラフに対応する層までの計算を行った場合に、出力されるデータ量が示されている。図４によれば、各層から出力されるデータ量は均一ではなく、大きなデータ量を出力する層でＤＮＮを分離しないほうが、通信遅延が大きくならず、好ましいことが分かる。また、図４の白色の棒グラフは、当該棒グラフに対応する層における計算遅延が示されている。例えば、「fc６」と名付けられた層に対応する白色の棒グラフが高いので、fc６の層の計算には時間がかかることが分かる。ゆえに、fc６の層の計算は、計算能力の高い装置に担当させたほうが好ましいことが分かる。

【0055】

このように、担当範囲によって、計算遅延および通信遅延が変動する。ゆえに、計算担当の決定に際して、各計算担当の担当範囲も決定することが好ましい。

【0056】

しかし、ＤＮＮの計算を分担させてＭＬアプリケーションの遅延を抑えることに成功しても、情報処理システム１の状況の変化によって、当該遅延が増加することがあり得る。例えば、計算担当の計算余力は常に一定ではないため、計算遅延は変動する。また、通信ネットワーク１３内に無線通信ネットワークが含まれる場合、無線通信リンクの品質が頻繁に変動するため、通信遅延が変動しやすい。また、通信端末１１が持ち運び可能である場合、通信端末１１の移動によって通信ルートなども変更されてしまう。また、ネットワークトポロジーの変動もあり得る。このような状況の変化によって、アプリケーションの実行遅延が、当初は許容限度内だったにも関わらず、許容限度を超えてしまうこともあり得る。

【0057】

例えば、前述のＩＡＢネットワークは、バックホールリンクとアクセスリンクの統合を目的としており、アクセスリンクのみならず、バックホールリンクも無線回線である。そのため、通信リンクの状況が変化しやすい。ゆえに、ＩＡＢネットワークが本実施形態の通信ネットワーク１３に含まれる場合では、通信遅延が変動しやすく、当初の計算担当および担当範囲のままにしていると、ＤＮＮの計算の分散をしない場合よりも実行遅延が悪化する恐れがある。

【0058】

そこで、本実施形態は、情報処理システム１の状況に基づいて分散の動的変更を行う。より詳細には、計算担当となり得る計算担当候補の状況と、計算担当候補間の通信リンクの状況と、に基づいて、計算担当、担当範囲、計算担当間の通信ルートなどを変更する。

【0059】

なお、ＩＡＢネットワークでは、当該ネットワーク内の通信ノードがリレー通信を行う。これにより、ミリ波通信においても、通信可能な領域（カバレッジ）を担保することが可能となる。また、従来のＴＤＭ（Time Division Multiplexing）だけでなく、ＦＤＭ（Frequency Division Multiplexing）またはＳＤＭ（Space Division Multiplexing）を用いて物理レイヤレベルでバックホールリンクとアクセスリンクを直交させるため、レイヤ３などの比較的高い通信レイヤにおけるリレー通信と比較して、効率の良い通信を行うことができる。また、ＩＡＢネットワークでは、特に、ミリ波を用いた通信を想定しており、ミリ波通信におけるカバレッジ問題も、ＩＡＢネットワークのようなリレー通信を用いることで改善することができ、カバレッジの拡大も効率的に行えるようになる。ＩＡＢネットワークではマルチホップ通信も想定しており、将来的にはメッシュタイプへの展開も想定されている。

【0060】

なお、ＩＡＢネットワークは、ミリ波通信に限られない。例えば、車にＩＡＢノードを搭載したVehicle tethering、電車に搭載したMoving cell、ドローンに搭載したDrone cellなどにも適用することができる。その他にも、ＩｏＴ（Internet of things）向けの通信にも適用することが想定される。特にスマートフォンとウェアラブル機器を接続するウェアラブル向けテザリング通信などにも適用することが可能である。その他にも医療やファクトリーオートメーションといった領域にも適用することが可能となる。本実施形態にＩＡＢネットワークを適用する場合も同様である。

【0061】

なお、ＩＡＢネットワークのアーキテクチャは、公知のものを用いてよい。図５は、ＩＡＢネットワークのアーキテクチャの例を示す図である。図５（Ａ）に示すように、ドナーノード１３２に該当するIAB-donorはgNB（Next Generation Node B）のような通信ノードが想定されている。その配下に、無線通信ノード１３１に該当し、リレーノードであるIAB-nodeが存在し、これらが複数マルチホップを構成しながら無線にて接続されていく。各IAB-nodeは、通信端末１１に該当するＵＥ（User Equipment）をアクセスリンクで接続する。IAB-nodeはバックホールリンクの冗長性を向上させるために、複数のIAB-nodeと接続してもよい。IAB-nodeはＵＥとしての機能（ＭＴ）と、通信ノードとしての機能（ＤＵ）と、を含む。つまり、バックホールリンクを用いて、ダウンリンク（ＤＬ）の受信と、アップリンク（ＵＬ）の送信と、を行う際はＭＴとして動作し、ＤＬ送信およびＵＬ受信の際はＤＵとして動作する。ＵＥからはIAB-nodeは通常の基地局のように見えるため、ＵＥがレガシー端末であっても、図５（Ｂ）に示すようにＩＡＢネットワークに接続することが可能である。なお、ＭＴとＤＵの組み合わせに限らず、ＭＴとＭＴ同士の組み合わせなどを用いてもよい。

【0062】

ＤＮＮの計算の分散および動的変更の効果について説明する。図６は、ＤＮＮの計算の分散の効果を示す図である。（１）の棒グラフは、通信端末１１単体でＤＮＮの計算を実行した場合の実行遅延を示す。（２）の棒グラフは、通信端末１１と、クラウドシステム１２内のクラウドサーバーと、でＤＮＮの計算を実行した場合の実行遅延を示す。（３）の棒グラフは、通信端末１１と、通信ネットワーク１３内の通信ノードが有する、エッジサーバーの一種であるＭＥＣ（Multi－access Edge computing）サーバーと、でＤＮＮの計算を実行した場合の実行遅延を示す。（４）の棒グラフは、通信端末１１と、ＭＥＣサーバーと、クラウドサーバーと、でＤＮＮの計算を実行した場合の実行遅延を示す。また、棒グラフのドット柄の部分が計算遅延を表し、白色の部分が通信遅延を表す。

【0063】

なお、通信端末１１は市販のラップトップを使用し、ＭＥＣサーバーは、ＣＰＵ（Central Processing Unit）がRyzen（商標登録）の３８００Ｘでメモリが３２ＧＢ（Giga byte）のものを使用し、クラウドサーバーは、ＣＰＵがIntel（登録商標）のCore i９－９９００でメモリが１２８ＧＢのものを使用し、クラウドサーバーのほうがＭＥＣサーバーよりも計算遅延が少なくなるようにしている。また、通信端末１１とＭＥＣサーバーとの間の通信容量を１００Ｍｂｐｓ(Mega bit per second)とし、ＭＥＣサーバーとクラウドサーバーとの間の通信容量を３０Ｍｂｓと設定した。なお、ＤＮＮは、畳み込みニューラルネットワークの一種であるResNet（Residual Network）１８を使用した。

【0064】

図６に示すように、（１）の場合は、通信遅延がないものの、実行遅延が２１２ms（millisecond）と最も大きい。（２）の場合は、通信遅延が大きくなる。（３）の場合は、ＭＥＣサーバーが通信端末１１に近いため通信遅延が抑えられているが、ＭＥＣサーバーがクラウドサーバーよりも計算能力が低いために計算遅延が大きくなり、そのため、実行遅延が（２）の場合よりも大きくなっている。一方、（４）の場合は、クラウドサーバーがＤＮＮの計算の全てを実行する場合よりも計算遅延が大きく、ＭＥＣサーバーがＤＮＮの計算の全てを実行する場合よりも通信遅延が大きくなるが、ＭＥＣサーバーがＤＮＮの計算の全てを実行する場合よりも計算遅延が小さく、クラウドサーバーがＤＮＮの計算の全てを実行する場合よりも通信遅延が小さい。そして、（４）の場合は、実行遅延が５３msと最小である。

【0065】

このように、ＤＮＮの計算の分散に通信ネットワーク１３内の通信ノードも利用することにより、実行遅延を低減し得ることが分かる。なお、前述の図４で示した通り、計算遅延および通信遅延は担当範囲によって異なるため、図６のシミュレーション結果も、担当範囲によって変わり得る。つまり、担当範囲によっては、上記（４）の場合の実行遅延が、上記（１）から（３）の場合よりも大きくなるかもしれないが、担当範囲を適切に定めることにより、上記（４）の場合の実行遅延を、上記（１）から（３）の場合よりも小さくすることは可能である。

【0066】

また、ＤＮＮの計算の分散の動的変更の効果についても示す。図７は、シミュレーションに用いたＩＡＢネットワークにおけるネットワークトポロジーの図を示す。図７の例のネットワークは１０個のノードから構成されており、１０個のノードは、ＩＡＢネットワークの無線通信ノード１３１Ａから１３１Ｆと、ＩＡＢネットワークのドナーノード１３２と、コアネットワーク１３３の通信ノード１３３１Ａおよび１３３１Ｂと、クラウドサーバー１２１と、である。なお、無線通信ノード１３１Ａから１３１Fのスペックは、図６の例のＤＮＮの計算の分散の効果を示した際に用いたＭＥＣサーバーと同じであり、ドナーノード１３２と、通信ノード１３３１Ａおよび１３３１Ｂと、クラウドサーバー１２１と、のスペックは、上記のＤＮＮの計算の分散の効果を示した際に用いたクラウドサーバーと同じである。また、ＩＡＢネットワークのアクセスリンクおよびバックホールリンクは、４Ｇｂｐｓ(Giga bit per second)の通信容量を共有するものとする。ドナーノード１３２と通信ノード１３３１Ａとの間の通信リンクは１Ｇｂｐｓの有線リンクであり、通信ノード１３３１Ａおよび１３３１Ｂの間の通信リンクは４００Ｍｂｐｓの有線リンクであり、通信ノード１３３１Ｂとクラウドサーバー１２１との間の通信リンクは１００Ｍｂｐｓの有線リンクである。

【0067】

また、通信端末１１は、前述の市販のラップトップを使用し、図７の矢印のように移動したものとする。通信端末１１は、まず最寄りの無線通信ノード１３１Ｆに接続するが、移動に伴って接続される無線通信ノード１３１が切り替えられていく。そのため、クラウドサーバー１２１への通信ルートも切り替わる。ゆえに、通信ルートが切り替わるたびに、計算担当および担当範囲を決定して、ＤＮＮの計算を実行させる。

【0068】

また、無線通信リンクの変動を模擬するため、シミュレーションのための通信容量の変動を定義した。図８は、シミュレーシのための通信容量の変動を示す図である。図８（Ａ）が、図７の通信端末１１と無線通信ノード１３１と間のアクセスリンクの通信容量の変動を示す。図８（Ｂ）が、図７の無線通信ノード１３１間の通信容量の変動を示す。アクセスリンクの例では、時間経過とともに通信容量が２００Ｍｂｐｓから８００Ｍｂｐｓまで変動させている。このリンク変動を用いて、無線通信リンクの変動による遅延の影響をシミュレーションした。

【0069】

図９は、通信ネットワーク１３のリソースが実行遅延に与える影響を示す図である。図９（Ａ）は、通信端末１１とＩＡＢノードとの間の通信容量と実行遅延との関係を示す。図９（Ａ）の棒グラフは実行遅延を表し、無線通信リンクの通信容量の大きい左側の棒グラフのほうが小さくなっている。つまり、無線通信リンクの通信容量が上がるにつれて、実行遅延は改善される。逆に言うと、無線通信リンクの品質が劣化して通信容量が減少した場合、実行遅延も同時に増大してしまう。無線通信リンクの品質は変動しやすいことから、ＤＮＮの計算を分散する際は、無線通信リンクの品質を考慮して分散のための設定を変更する必要がある。また、図９（Ｂ）は計算担当となったＩＡＢノードの計算余力と実行遅延との関係を示している。図９（Ｂ）でも、計算余力の大きい左側の棒グラフのほうが小さくなっており、ＩＡＢノードの計算余力が上がれば上がるほど遅延量の削減が期待できる。また、図９で示したように、ＤＮＮの各レイヤにおける計算遅延もばらばらであるため、ＩＡＢノードの計算余力の変動に応じて、担当範囲を決定する必要がある。

【0070】

このように、通信リンクの品質、通信ノードの計算余力といった通信ネットワーク１３のリソースは実行遅延に影響を与えるが、これらは、ネットワークトポロジーの変化、アプリケーション要求の変化などによって、時間とともに変動し得るため、これらの変動に追従してＤＮＮの計算の分散を動的に変更する。つまり、通信リンクの品質、各計算担当の計算余力の状況を鑑みて、計算担当、担当範囲、通信ルートなどを動的に変更することが好ましい。

【0071】

ＤＮＮの計算の分散および動的変更を行うための一連の処理について説明する。まずは、ＤＮＮの分散を実施する際に必要となるＫＰＩ（Key Performance Indicator）、制御対象、使用する情報の例を以下に示す。

【0072】

ＫＰＩとしては、前述の通り、ＭＬアプリケーションの実行遅延である。ＭＬアプリケーションの実行遅延には、各計算担当における計算遅延と、各計算担当間の通信遅延と、が少なくとも含まれる。なお、一つ前の計算担当からの計算結果を受信してから、自分の担当範囲の計算を始めるまでに行われる処理による遅延は考慮せず、各計算遅延と各通信遅延との総和を、実行遅延とみなしてもよい。

【0073】

制御対象は、ルーティング、各通信ノードにおけるＤＬまたはＵＬの設定（ＤＬ／ＵＬ configuration）、ＤＮＮのSplitting pointなどが想定される。

【0074】

使用する情報は、各計算担当候補の処理の能力、各無線通信リンクの状況、ＭＬアプリケーションの要求仕様、通信ネットワーク１３の要求仕様、通信端末１１の移動状況（モビリティ）などが想定される。なお、計算担当候補は、通信端末１１、クラウドシステム１２、および通信ネットワーク１３内の通信ノードであるが、通信端末１１およびクラウドシステム１２については、予め計算担当とするかどうかが決まっていてもよく、その場合、計算担当候補から外してもよい。

【0075】

各計算担当候補の処理の能力としては、計算能力（Capacity）、現時点の計算余力などが想定される。例えば、最初は、通信ネットワーク１３に属する計算担当候補のうち、最も計算能力を有する計算担当候補に、計算担当を任命し、計算担当の計算余力が所定閾値以下に減少した場合に、計算余力を十分に有する別の計算担当候補に担当を変更するようにしてもよい。このように、計算担当の計算余力に基づいて、計算担当の変更が行われてもよい。

【0076】

通信リンクの状況としては、通信容量、通信品質などが考えられる。なお、ＩＡＢネットワークならば、バックホールリンクおよびアクセスリンクの状況を含む。

【0077】

ＭＬアプリケーションの要求仕様としては、ＭＬアプリケーションの実行遅延の許容限度、言い換えれば、ＭＬアプリケーションが許容する実行遅延の上限値が想定される。また、通信遅延および計算遅延にも個別に許容される上限値が定められていてもよい。

【0078】

通信の要求仕様としては、各リンクにおけるトラフィックの上限値が想定される。また、通信端末１１とクラウドシステム１２間に設定されたルート上におけるトラフィックの上限値が設定されてもよい。これらの上限値は、ＭＬアプリケーションの要求仕様と、ＤＮＮのSplitting pointと、に基づいて決定されてもよい。通信端末１１の移動状況は、移動速度、移動方向、移動パターンなどの移動に関する情報であればよい。

【0079】

次に、計算担当および担当範囲の決定を行う主体について説明する。計算担当および担当範囲の決定は、情報処理システム１に属するいずれかの装置が行えばよく、特に限定されるものではない。すなわち、計算担当および担当範囲の決定を行う主体は、適宜、定めることが可能である。なお、通信端末１１、通信ノード、クラウドサーバーなど、情報処理システム１に属する装置を区別しない場合は、これらをエンティティと記載し、計算担当および担当範囲の決定を行う主体を、論理エンティティと記載する。

【0080】

例えば、通信ネットワーク１３の通信ノードやクラウドシステム１２内に当該決定を行うサーバーなどを実装して論理エンティティにしてもよいし、通信ノード内の通信を行うためのインフラストラクチャーに、計算担当および担当範囲の決定を司るモジュールを実装して論理エンティティしてもよい。

【0081】

ただし、計算担当および担当範囲の決定のためには、情報処理システム１のリソースの状況を常時認識しているほうが好ましく、そのための通信に適した位置に存在する装置が論理エンティティとなることが好ましい。

【0082】

また、計算担当および担当範囲の両方を一つの論理エンティティが決定してもよいし、計算担当を決定する論理エンティティと、担当範囲を決定する論理エンティティと、に分かれていてもよい。

【0083】

情報処理システム１のリソースは、情報処理システム１に属する計算担当候補の計算余力、通信ネットワーク１３内の通信リンクの通信容量、通信品質などがある。

【0084】

通信環境の変動としては、例えば、通信リンクの品質、通信ノードの計算余力、ネットワークトポロジー、通信ルートなどの変動が想定される。

【0085】

本実施形態の処理の流れについて説明する。図１０は、本実施形態の全体処理の流れを示した概略シーケンス図である。なお、図１０では、説明の都合上、通信ノードとクラウドサーバーはセットにして表されている。

【0086】

また、情報処理システム１のエンティティは、図示されていないが、各処理を担当する構成要素から構成されるものとする。本説明では、論理エンティティは、受信部と、送信部と、決定部と、を備える。また、通信端末１１、通信ノード、クラウドサーバーといった計算担当候補は、受信部と、送信部と、取得部（測定部）と、設定部と、計算部と、を備える。図１０の各処理の主体は、上記の構成要素とする。

【0087】

論理エンティティの送信部が、計算担当などの決定に用いられる情報処理システム１のリソースなどの情報の取得および送信に関する設定を、通信端末１１、通信ノード、クラウドサーバーといった各エンティティに送信する（Ｔ１０１、Measurement configuration）。各エンティティの受信部は論理エンティティからの当該取得設定を受信し（Ｔ１０２）、各エンティティの取得部は当該設定に基づいてリソースに関する情報を取得し（Ｔ１０３）、各エンティティの送信部は当該設定に基づいて取得したリソースに関する情報を論理エンティティに送信する（Ｔ１０４）。

【0088】

論理エンティティの受信部は、各エンティティからのリソースに関する情報を受信し（Ｔ１０５）、論理エンティティの決定部は、ＭＬアプリケーションの実行遅延を許容限度内に収めるべく、各エンティティの制御内容を決定する（Ｔ１０６）。後述するが、計算担当として任命されるか否かは、本制御内容として決定される。さらに、論理エンティティの決定部は、決定された制御内容を実現するために、通信端末１１および通信ノードに設定されるパラメータの値、言い換えれば設定値を決定する（Ｔ１０７、Parameter configuration）。決定された設定値は、論理エンティティの送信部によって、通信端末１１および通信ノードに送信される（Ｔ１０８）。

【0089】

各エンティティの受信部は、論理エンティティからの設定値を受信し（Ｔ１０９）、各エンティティの設定部が、各エンティティが動作するためのパラメータが当該設定値に設定する（Ｔ１１０）。これにより、現在のリソース状況に適した、ＭＬアプリケーションの実行環境が整備されたことになる。

【0090】

その後、通信端末１１においてＭＬアプリケーションが実行される（Ｔ１１１）。なお、通信端末１１が計算担当と指定されている場合は、通信端末１１の計算部が担当の計算範囲の計算を行う。そして、通信端末１１の送信部が、ＤＮＮの計算に必要な情報を指定先に送信する（Ｔ１１２）。通信端末１１が計算担当と指定されている場合は、ＤＮＮの一連の計算の途中までの計算結果が当該情報に含まれ、通信端末１１が計算担当と指定されていない場合は、ＤＮＮへの入力が当該情報に含まれる。また、指定先は、次の計算担当である。

【0091】

次の計算担当の受信部はＤＮＮの計算に必要な情報を受信し（Ｔ１１３）、次の計算担当の計算部が自身の担当範囲の計算を行い（Ｔ１１４）、次の計算担当の送信部が計算結果をさらに次の計算担当に送信する（Ｔ１１５）。このＴ１１３からＴ１１５の処理が各計算担当により行われる。なお、計算担当に指定されなかったエンティティは、ＤＮＮの計算は行わない。また、最後の計算担当の送信部は、計算結果を通信端末１１に返信する。通信端末１１の受信部はＤＮＮの最終の計算結果を受信し（Ｔ１１６）、最終の計算結果に基づいてＭＬアプリケーションの処理が実行される（Ｔ１１７）。このようにして、ＭＬアプリケーションの処理が完了する。

【0092】

なお、ＭＬアプリケーションの処理が完了した後も、各エンティティは、取得設定に基づいてリソースの取得および送信を行い、論理エンティティは、リソースを受信する度に、実行遅延が許容上限値を超えるか否かを判定し、超えると判定された場合に、制御内容の変更を行ってもよい。このようにして、ＭＬアプリケーションが再度実行された場合に備えておいてもよい。なお、リソースの取得および送信を停止し、ＭＬアプリケーションの起動を検知した場合などに、リソースの取得および送信を再開するとしてもよい。

【0093】

上記シーケンスの各処理について補足する。まず、取得される情報について説明する。

【0094】

論理エンティティから取得するよう指示される情報は、計算パワーに関する情報であってもよい。計算パワーに関する情報としては、例えば、最大計算能力（Capability）、計算余力、計算負荷（計算量）、計算負荷から想定される計算遅延量などが上げられる。例えば、各エンティティが備えるＧＰＵ（Graphical Processor Unit）の数を最大計算能力としてもよい。また、現状の未使用であるＧＰＵの数を計算余力としてもよい。

【0095】

また、当該情報は、接続されている通信リンクの状況に関する情報であってもよい。例えば、Radio link failureなどの無線通信リンク接続に関する情報でもよいし、ＲＳＲＰ（Reference Signal Received Power）、ＲＳＲＱ(Reference Signal Received Quality)、ＲＳＳＩ(Reference Signal Strength Indication)などといった無線通信リンクの通信品質の情報でもよい。また通信リンクのスループットや遅延に関する情報を用いてもよい。

【0096】

また、当該情報は、ＭＬアプリケーションの要求仕様に関する情報であってもよい。例えば、ＭＬアプリケーションが許容する遅延の上限値などがある。なお、ＭＬアプリケーションの要求仕様は、通信端末１１ごとに異なっていてもよい。

【0097】

また、当該情報は、通信ネットワーク１３のトラフィックに関する情報であってもよい。例えば、トラフィックの上限値、トラフィックのバッファステータスなどが上げられる。なお、実際のトラフィックの測定値ではなく推定値が用いられてもよい。

【0098】

また、当該情報は、通信端末１１の移動（モビリティ）に関する情報であってもよい。ＭＬアプリケーションの実行中に、通信端末１１が移動することもあり得る。移動によって通信品質に影響を及ぼすため、例えば、移動速度、移動方向といった情報を取得してもよい。

【0099】

また、当該情報は、ＤＮＮの計算に関する情報であってもよい。例えば、各エンティティにＤＮＮのレイヤごとの計算遅延を推定させてもよい。また、予め複数の担当範囲候補を定めておき、論理エンティティは、各エンティティに各担当範囲候補の計算遅延をそれぞれ推定するように指示してもよい。また、ＤＮＮの計算による負荷（例えばＧＰＵ使用率など）を推定させてもよい。なお、計算遅延は、過去の計算履歴に基づいて算出されてもよいし、図４に示したデータサイズを現在の計算余力が続いたと仮定して計算した際の理論上の時間として算出されてもよい。

【0100】

なお、エンティティは、指示された情報を実際に計測し、その実測値を論理エンティティに送信してもよい。あるいは、実測値に基づいて算出された将来の推定値を論理エンティティに送信してもよい。例えば、ＭＬアプリケーションの実行予定時刻が１０秒後であれば、１０秒後の通信端末１１の予想位置を論理エンティティに送信してもよい。また、通信端末１１および通信ノードは、実測値を量子化してもよいし、実測値が予め定めた分類項目のいずれに該当するかを判定し、該当するとされた分類項目の情報を論理エンティティに送信してもよい。推定は、これまでの記録に基づいて行えばよい。

【0101】

リソースに関する情報の取得方法は、公知技術を用いてよい。例えば、計算能力、計算余力といったエンティティの性能に関する情報は、エンティティに搭載されたＯＳ（operating system）などが提供するツールなどの機能を利用して取得してもよい。また、通信リンクの品質に関する情報、例えば、ＲＳＲＱなどの通信品質は、公知技術を用いて確認されてよい。

【0102】

また、論理エンティティに送信される情報を収集して代表して論理エンティティに送信するといった代表者的な振る舞いをする通信ノードが存在していてもよい。その場合、例えば、各リンクのトラフィック、通信端末１１の移動などの情報は、複数の通信ノードからの情報が合算された上で、論理エンティティに送信されてもよい。

【0103】

また、情報の取得のタイミングなども指定されてよい。定期的な取得（Periodical measurement）が指示されてもよい。例えば、論理エンティティが、取得開始時間、取得終了時間、取得期間を決定して各エンティティに指示し、各エンティティが当該指示に従って取得を行ってもよい。また、取得回数、反復待機期間なども指示されてよい。また、動的な取得（Trigger based measurement）が行われてもよい。各エンティティが動的に取得を開始するためのトリガー条件は、適宜に定めてよい。例えば、無線通信リンクの異常（failure）を検知したときに、取得が開始されてもよい。あるいは、ノードの処理負荷、ＭＬアプリケーションの遅延、通信遅延などが、所定閾値を超えた場合に、取得が開始されてもよい。なお、これらの閾値は、論理エンティティにより調整されてもよい。あるいは、取得のリクエストを受信した際に取得が開始されてもよい。当該リクエストは論理エンティティから送信されてもよいし、論理エンティティとは別の上位ノードから送信されてもよい。

【0104】

例えば、バックホールリンクの品質を測定するために、例えば、１０msの期間におけるバックホールリンクのＲＳＲＱの測定を、例えば１００ms間隔といった定期的に実行するような指定が行われてもよい。

【0105】

これらの情報の論理エンティティに対する送信、言い換えればレポートは、適宜に行えばよく、送信タイミングも、送信されるデータの形式も特に限られるわけではない。例えば、情報を定期的に取得するよう指示された場合、当該送信も定期的に行うとしてもよい。あるいは、通信リンクのＲＳＲＱの値が所定閾値以下になったとき、ノードの処理負荷が所定の閾値以上になったとき、などの条件を満たした場合に行われてもよい。また、取得した直後に送信しても、取得からのオフセット時間が経過した後に送信してもよい。また、取得された値が条件を満たしたときに送信されるとしてもよい。例えば、計算担当、担当範囲などの変更が必要とされる程度の変動があった場合にレポートを行い、そうでない場合は、レポートを行わないとしてもよい。

【0106】

また、各エンティティは、取得した情報全てを論理エンティティに送信しなくともよい。例えば、情報を細かい粒度で取得し、取得された情報のうち、変動が大きいもの、閾値を超えたものなど、所定条件を満たした情報だけを、論理エンティティに送信してもよい。すなわち、論理エンティティは、取得させる情報と、報告させる情報と、を別々に指示してよい。また、論理エンティティへのレポートのために、取得された情報は、適宜、加工されてよい。

【0107】

また、当該設定はエンティティごとに異なっていてもよい。例えば、クラウドシステム１２に接続されている通信リンクは有線であって安定していることが想定されるため、クラウドシステム１２は通信リンクに関する情報を取得不要としてもよい。

【0108】

次に、制御内容の決定について説明する。決定される制御内容としては、通信リンク、無線通信パラメータに関するものがある。また、計算担当、担当範囲なども決定される。

【0109】

通信リンクに関する制御としては、例えば、通信ルートの決定がある。例えば、通信ネットワーク１３がＩＡＢネットワークなどのリレー方式のネットワークを含む場合、リレーのルートを決定する。なお、通信端末１１とクラウドシステム１２との通信ルート上の通信ノードから計算担当を選出しようとしても、当該通信ルート上に計算余力がある通信ノードがないと選出できない。そのため、論理エンティティは、通信リンクの品質のみならず、通信ノードの計算能力、計算余力なども用いて、通信ルートを決定してもよい。また、経由するＩＡＢノードの変更およびホップ数の変更も同様に行ってもよい。

【0110】

通信パラメータに関する制御としては、例えば、通信ルート上の通信リンクの品質の向上がある。これにより、通信遅延を抑えられる。例えば、論理エンティティは、通信ルート上の無線通信ノード１３１に対して、送信する無線電波の強度（送信電力）を上昇させるような設定値を送信することが考えられる。また、干渉が起きないように、当該無線通信ノード１３１に対し、通信ルート上ではない無線通信リンクの通信容量を削減させてもよい。このようにして、通信リンクの品質を向上する設定値を決定してもよい。

【0111】

また、無線通信パラメータに関する制御として、無線通信リンクにおけるダウンリンク（ＤＬ）およびアップリンク（ＵＬ）の対応関係を変更してもよい。無線通信リンクでは、ＤＬおよびＵＬの一方の通信帯域を増やし、他方を減らすといった調整が可能である。そのため、ＤＬとＵＬの対応関係を通信遅延が減るように調整してもよい。なお、通信遅延は、送信されるデータのサイズと、データが流れる通信リンクの通信容量と、から算出すればよい。通信品質による遅延も考慮してもよい。

【0112】

ただし、通信帯域を調整すると、干渉が起きやすくなる。例えば、ＩＡＢネットワークでは、ＩＡＢネットワークリンクとのCLI（Cross link interference）が起きやすくなる。そのため、通信帯域の調整には十分留意する必要がある。

【0113】

計算担当および担当範囲は、各無線通信ノード１３１の計算余力、各担当範囲において出力されるデータ量、通信ルート上の通信リンクの品質などを鑑みて決定される。少なくとも遅延のボトルネックとなるような無線通信ノード１３１が計算担当とならないようにする。

【0114】

ただし、計算担当と担当範囲の最適解の探索には負荷および時間がかかる。通信ルート、ＤＮＮのレイヤ数によって、計算担当候補の数が指数関数的に増えるためである。ゆえに、予め計算担当候補を絞り、準最適解を探索するほうが、処理が容易となる。例えば、事前に担当範囲の組み合わせを複数用意しておき、通信環境の状況に応じて、使用する組み合わせを変更してもよい。ここでは、事前に用意された担当範囲の組み合わせをSplitting modeとも記載する。

【0115】

図１１は、Splitting modeを説明する図である。図１１には、四つのSplitting modeが示されている。なお、図１１のような複数のSplitting modeを示す表を、Splitting mode tableとも記載する。図１１の例では、四つのSplitting modeから、ＭＬアプリケーションの実行遅延が最も小さくなるSplitting modeを選択することにより、各計算担当の担当範囲を決定する。なお、図１１の例では、通信端末１１と、通信ネットワーク１３内の通信ノードと、クラウドシステム１２と、が計算担当とされているが、計算担当が異なるSplitting modeが用意されていてもよい。また、例えば、ＭＬアプリケーションの実行開始当初は、特定のSplitting modeをデフォルトで選択し、その後に、別のSplitting modeに切り替えるとしてもよい。例えば、通信端末１１以外の計算担当の負荷が高いと判定された場合に、通信端末１１以外の計算担当の担当範囲が小さい、２行目のSplitting modeを選択して、通信端末１１に負荷を肩代わりしてもらうことが考えられる。このように、特定の計算担当に負荷があるような場合に、当該計算担当の担当範囲が小さいSplitting modeに切り替えることで、容易に改善を行うことができる。なお、Splitting modeを切り替えるかどうかの検討も、定期的に実行されてもよいし、動的に実行されてもよい。

【0116】

通常時に使用するSplitting modeと、通常時に使用するSplitting modeではＭＬアプリケーションの要求を満たせないと判定された場合に使用する臨時のSplitting modeと、の両方を決定しておいてもよい。そうすると、ＭＬアプリケーションの要求を満たせないと判定された場合に適切なSplitting modeを選択するという処理を行わずに、Splitting modeを迅速に切り替えることができる。

【0117】

このように、事前に担当範囲の候補を用意しておくことにより、分散の動的変更を容易にしてもよい。また、Splitting modeの内容、つまり、各計算担当の担当範囲は適宜論理エンティティによって更新されてよい。なお、各計算担当が更新前のSplitting modeに基づいて計算を行わないように、更新されたSplitting modeは、逐次、各エンティティに通知される。

【0118】

また、通信ルートごとに、Splitting modeを設定してもよい。図１２は、通信ルートごとに設定されたSplitting modeについて説明する図である。図１２には、Route_A、Route_B、Route_Cの三つの通信ルートが示されている。これらの三つの通信ルートそれぞれごとに、図１１に示したような複数のSplitting modeを設定する。

【0119】

例えば、通信ルートRoute_Aでは、通信ルートRoute_A上に存在する、クラウドシステム１２と、コアネットワーク１３３の通信ノードと、ドナーノード１３２と、無線通信ノード１３１Ｃと、無線通信ノード１３１Ａと、通信端末１１Ａとが、計算担当候補となる。これらの計算担当候補に対し、ＤＮＮのレイヤを割り当てて、Splitting mode tableを作成する。同様に、通信ルートRoute_BおよびRoute_Cに対しても、計算担当候補を選出して、Splitting mode tableを作成する。

【0120】

図１３は、通信ルートごとのSplitting modeの例を示す図である。図１３（Ａ）は通信ルートRoute_AのSplitting mode tableを示し、図１３（Ｂ）は通信ルートRoute_BのSplitting mode tableを示す。図１３の例では、ＤＮＮのレイヤ数を４０と想定しており、Splitting mode tableの各セルの数値は、対応する計算担当候補が担当するレイヤの数を示す。なお、セルに「０」が記載されている場合は、対応する計算担当候補が担当するレイヤがないことを意味する。つまり、計算担当とはならないことを意味する。

【0121】

なお、上記では、論理エンティティが担当範囲、つまり、Splitting modeを決定することを想定していたが、論理エンティティはSplitting mode tableを作成して計算担当にSplitting mode tableを送信し、計算担当がSplitting modeを選択するという方法もあり得る。例えば、通信端末１１がハンドオーバーを行って接続先の無線通信ノード１３１を変更した際に、通信端末１１が変更後の通信ルートのSplitting mode tableから、Splitting modeを選択し、選択したSplitting modeを各計算担当に通知することで、Splitting modeの再設定を行うことも可能である。

【0122】

なお、有線リンクを用いる計算担当の担当範囲は、固定としてもよい。例えば、クラウドシステム１２と、コアネットワーク１３３のエッジサーバーとは、無線通信を行わないため、通信リンクの状況変化が少ないと思われる。このように通信環境の変動があまりない場所に存在する計算担当の担当範囲を固定にすることで、Splitting modeのバリエーションを減らすことが可能となる。例えば、図１３（Ａ）に示した通信ルートRoute_AのSplitting modeは、七つの計算担当候補を含んでいるが、設定を行うことで、準最適なSplitting modeの割り当てを行うことが可能となる。クラウドシステム１２と、コアネットワーク１３３と、の割り当て値を固定にすることにより、Splitting modeのバリエーションの数を減らすことができる。

【0123】

また、論理エンティティは、アンカーポイントに基づいて、Splitting mode tableの変更を行ってもよい。アンカーポイントは、通信端末１１が想定移動エリア内にいる限り、通信端末１１に設定される通信ルート上に必ず存在する通信ノードである。通信端末１１の移動によって通信ルートは変更されるが、通信端末１１の想定移動エリア内において設定され得る全ての通信ルートに共通する通信ノードがアンカーポイントである。例えば、図１２の例において、通信端末１１が無線通信ノード１３１Ａから１３１Ｄまでのいずれかと無線接続するならば、クラウドシステム１２との通信ルート上に必ずドナーノード１３２が存在する。ゆえに、図１２の例では、ドナーノード１３２はアンカーポイントである。例えば、論理エンティティは、アンカーポイントが通信ルートからなくならない限り、Splitting mode tableのうちから、Splitting modeを決定し、アンカーポイントが通信ルートからなくなったことを検知した場合に、Splitting mode table自体の再設定を行ってもよい。このように、通信ルート上に所定の通信ノードが存在しなくなったときに、Splitting mode tableの再作成を行ってもよい。

【0124】

また、論理エンティティは、各計算担当の担当範囲をレイヤ単位で変更してもよい。例えば、通信端末１１の担当範囲がレイヤ１から４までと決定した後に、通信端末１１の負荷が少し上昇した場合に、通信端末１１の担当範囲をレイヤ１から３までに変更し、担当範囲外となったレイヤ４を次の計算担当に担当させるといった調整が行われてもよい。この場合は、Splitting modeレベルよりも細かい粒度での制御となり、論理エンティティの負荷が増えるが、ＭＬアプリケーションの要求を満たさなくなるリスクを減らすことができる。

【0125】

次に、パラメータの設定について説明する。通信端末１１および通信ノードは、論理エンティティによって決定された内容に従って、通信リンク、担当範囲などに関するパラメータの値を更新する。パラメータの設定の指示は、論理エンティティから、直接指示されてもよいし、複数の無線通信ノード１３１を束ねる代表者的な無線通信ノード１３１を介して、間接的に指示されてもよい。通知方法としては、特に限られるものではなく、アプリケーションレイヤにおけるシグナリング通知でもよいし、物理レイヤにおけるシグナリング通知でもよい。ＲＲＣ（Radio Resource control） signalingのような準静的通知でもよいし、ＤＣＩ（Downlink control information）またはＵＣＩ（Uplink control information）のような動的通知でもよい。

【0126】

さらに、計算担当が切り替えられるときのシーケンス図も例示する。図１４は、計算担当が切り替えられる前後のシーケンス図である。なお、説明の便宜上、図１４のブロックには、図１０で示した処理の符号が記載されている。

【0127】

図１４の例では、ドナーノード１３２に論理エンティティが実装された場合を示す。また、当初は、通信端末１１と、無線通信ノード１３１Ａ、無線通信ノード１３１Ｃ、およびクラウドシステム１２が計算担当であったが、無線通信ノード１３１Ａと無線通信ノード１３１Ｃとのバックホールリンクの品質が悪化し、担当範囲の切り替えが実行されるとする。なお、図１０に示したパラメータの設定（Ｔ１１０）までの処理は実行済みとし、Ｔ１１１の処理から示す。

【0128】

通信端末１１のＭＬアプリケーションが実行されて（Ｔ１１１）、通信端末１１が、ＤＮＮの計算に必要な情報を次の計算担当に送信する（Ｔ１１２）。次の計算担当である無線通信ノード１３１Ａが、当該情報を受信し（Ｔ１１３）、自身の担当範囲の計算を行い（Ｔ１１４）、計算結果を次の計算担当である無線通信ノード１３１Ｃに送信する（Ｔ１１５）。無線通信ノード１３１Ｃも同様に、Ｔ１１３からＴ１１５の処理を実行し、次の計算担当であるクラウドシステム１２に無線通信ノード１３１Ｃの計算結果が送信される。次の計算担当であるクラウドシステム１２も同様に、Ｔ１１３からＴ１１５の処理を実行し、クラウドシステム１２が最終の計算担当であるので、クラウドシステム１２からＤＮＮの最終の計算結果が通信端末１１に送信される。

【0129】

その後、各エンティティにおいて定期のリソースの取得（Ｔ１０３）が実行され、問題を検知した無線通信ノード１３１Ａが論理エンティティであるドナーノード１３２にレポートする（Ｔ１０４）。なお、図１４の例では、コアネットワーク１３３とクラウドシステム１２とは論理エンティティへのレポートはしない設定となっており、コアネットワーク１３３とクラウドシステム１２にはＴ１０４のブロックが示されていない。また、それら以外のエンティティも、悪化を検知しなかった場合には論理エンティティへのレポートはしない設定となっている。そのため、問題を検知した無線通信ノード１３１Ａ以外のエンティティはレポートを行っていないため、Ｔ１０４のブロックが示されていない。

【0130】

例えば、各エンティティがバックホールリンクに対する測定を行う。そして、無線通信ノード１３１Ａが無線通信ノード１３１ＣとのバックホールリンクのＲＳＲＱの値が所定値以下になったことを検知し、論理エンティティに送信するといったことが想定される。

【0131】

論理エンティティであるドナーノード１３２は、無線通信ノード１３１Ａのレポートを受信し、レポーティングの結果から問題のバックホールリンクの帯域を増強するだけでは不十分と判断し、計算担当の変更などの新たな設定を決定し、各エンティティに送信する（Ｔ１０５からＴ１０８）。なお、図１４の例では、論理エンティティは、新たな設定が必要なエンティティのみに設定を送信しているため、コアネットワーク１３３およびクラウドシステム１２には送信を示す矢印が示されていない。なお、新たな設定が必要ないエンティティに設定を送信してもよい。

【0132】

なお、論理エンティティは、追加のレポートを各エンティティに要求してもよい。例えば、バックホールリンクに問題があるとのレポートを無線通信ノード１３１Ａから受けたときに、当該バックホールリンクの帯域の増強で対応できるかを検討するために、無線通信ノード１３１Ａの周辺の通信ノードに対して、トラフィックバッファなどのレポートを送信するように要求してもよい。

【0133】

論理エンティティから新たな設定を受信した各エンティティは、新たな設定を受信してパラメータに設定する（Ｔ１０９、Ｔ１１０）。図１４の例では、無線通信ノード１３１Ａから無線通信ノード１３１Ｃへのバックホールリンクがなくなり、無線通信ノード１３１Ａから無線通信ノード１３１Ｄへのバックホールリンクが新設されたとする。これに伴い、通信ルートが変更され、通信ルート上にない無線通信ノード１３１Ｃが計算担当から外れ、無線通信ノード１３１Ｄが計算担当に追加されたとする。

【0134】

その後、再び、ＭＬアプリケーションが実行されて（Ｔ１１１）、通信端末１１が、ＤＮＮの計算に必要な情報を次の計算担当の無線通信ノード１３１Ａに送信する（Ｔ１１２）。無線通信ノード１３１Ａは、前回同様、当該情報を受信し（Ｔ１１３）、自身の担当範囲の計算を行うが（Ｔ１１４）、計算結果は、無線通信ノード１３１Ｃではなく、新たに次の計算担当になった無線通信ノード１３１Ｄに送信する（Ｔ１１５）。これにより、前回とは異なり、無線通信ノード１３１ＣではＴ１１３からＴ１１５の処理は実行されない。無線通信ノード１３１Ｄも同様に、Ｔ１１３からＴ１１５の処理を実行し、次の計算担当であるクラウドシステム１２に無線通信ノード１３１Ｄの計算結果が送信される。次の計算担当であるクラウドシステム１２も同様に、Ｔ１１３からＴ１１５の処理を実行し、クラウドシステム１２が最終の計算担当であるので、クラウドシステム１２からＤＮＮの最終の計算結果が通信端末１１に送信される。

【0135】

このように、計算担当が変更されることによって、問題のあるエンティティによる計算遅延と、問題のある通信リンクによる通信遅延と、を抑えることができ、ＭＬアプリケーションの実行遅延が許容上限値を超えてしまうことを防ぐことができる。

【0136】

なお、図１４の例では、バックホールリンクの帯域を増強するだけでは不十分と判断して、通信ルートの変更と計算担当の変更が行われたが、担当範囲の変更だけで対応可能と判定された場合は、計算担当の変更だけを行うとしてもよい。例えば、図１１で示したようなSplitting mode tableから、無線通信ノード１３１Ｃの担当範囲が小さくなるようなSplitting modeを選択してもよい。また、例えば、今までは、無線通信ノード１３１Ａの担当範囲がＤＮＮのレイヤ２０からレイヤ２５までであり、無線通信ノード１３１Ｃの担当範囲がＤＮＮのレイヤ２６からレイヤ４０までであったところ、無線通信ノード１３１Ａの担当範囲をＤＮＮのレイヤ２０からレイヤ２９までに増やし、無線通信ノード１３１Ｄの担当範囲をＤＮＮのレイヤ３０からレイヤ４０としてもよい。このようにして、無線通信ノード１３１Ｃに引き続き計算担当を任せるようにしてもよい。

【0137】

また、担当範囲の変更は、図１４の例のような計算担当が変更された場合においても行われてもよい。

【0138】

なお、本説明では、情報処理システム１に、通信端末１１と、通信ネットワーク１３と、クラウドシステム１２と、が含まれるとしたが、現実的には、これらの所有者は異なると想定される。また、ＩＡＢネットワークなどの通信端末１１のアクセスのためのネットワークと、コアネットワーク１３３と、も所有者が異なると想定される。そのため、論理エンティティが指示および設定可能な範囲は、情報処理システム１の一部であってもよい。例えば、論理エンティティがＩＡＢネットワーク内の通信ノードである場合、論理エンティティは、クラウドシステム１２の計算範囲などは変更できず、ＩＡＢネットワーク内の通信ノードに対する設定のみを行うとしてもよい。

【0139】

以上のように、本実施形態では、情報処理システム１のリソースの変動によって、ＭＬアプリケーションの実行に要する時間が上限値を超えてしまう場合に、計算担当、担当範囲、通信リンクの通信容量、通信ルートなどの設定変更を実行する。これにより、当該変動の影響を抑えて、ＭＬアプリケーションを快適に動作させることが可能となる。

【0140】

なお、ＤＮＮの全ての計算をクラウドサーバーなどの外部の装置に代行させる場合、ＤＮＮへの入力が通信端末１１から外部の装置に送信されることになる。例えば、ｍ個のノードが入力層に含まれる場合では、入力1,入力2,・・・,入力mといった値から構成された入力データが通信端末１１の外部に送信されることになる。しかし、このことがプライバシーや情報漏洩といった観点から問題であるとも指摘されている。ゆえに、通信端末１１がＤＮＮの一連の計算の最初から途中までの計算を少なくとも担当することによって、入力データそのものを外部に送信しないようにすれば、このような問題も軽減することができる。

【0141】

また、これまでの説明では、計算担当および担当範囲の決定を行う主体を、論理エンティティと記載し、論理エンティティを、通信ネットワーク１３の通信ノードやクラウドサーバーなどが担当することを想定した。例えば、情報処理システム１のリソースの状況に応じて計算担当および担当範囲を決定することができるよう、リソースの状況を把握するのに適した装置が論理エンティティとすればよいことが示されている。また、通信ルート上の無線通信ノード１３１に対して通信リンクの品質を向上するような指示を出すような装置が論理エンティティとされることが示されている。また、通信端末１１も論理エンティティになり得る。換言すると、通信端末１１が計算担当および担当範囲の決定を行ってもよい。

【0142】

また、図１０などに示したように、これまでの説明では、通信端末１１などの各エンティティは定期的にリソースを論理エンティティに送信し、論理エンティティは各エンティティのリソースに基づいて計算担当および担当範囲を決定し、各計算担当に通知していた。そのため、通信端末１１がＭＬアプリケーションを起動させた時点またはＭＬアプリケーションがＤＮＮの計算を実行する時点において、計算担当および担当範囲が決定済みであった。しかし、担当範囲を決めるための条件を論理エンティティなどから通信端末１１に予め通知することにより、通信端末１１が自分自身の担当範囲を自分自身で決定するといったことも可能である。なお、条件を通信端末１１に送信するエンティティが論理エンティティでなくてもよい。

【0143】

例えば、通信端末１１は、ＭＬアプリケーションの実行時において、自身の計算余力、クラウドシステム１２との通信品質などといった事項を確認し、ＤＮＮの計算をいずれの位置まで行うかを当該事項に応じて決定してもよい。なお、通信端末１１は、ＤＮＮのいずれかのレイヤまで計算を行うと決めてもよいし、あるレイヤ内のノードに設定された複数の計算の一部まで計算を行うと決めてもよい。あるいは、論理エンティティが、各計算担当を決定した後に、通信端末１１に対し最低限計算して欲しい担当範囲を通知し、通信端末１１が当該事項に応じて当該担当範囲を拡大してもよい。あるいは、論理エンティティが、各計算担当を決定した後に、通信端末１１に対し、実施してもよい担当範囲（言い換えれば、担当範囲の上限）を通知し、通信端末１１が当該事項に応じて論理エンティティから通知された担当範囲を縮小してもよい。

【0144】

通信端末１１の担当範囲を決定するための条件を通信端末１１が保持し、通信端末１１が動的に担当範囲を決定する場合には、通信端末１１がＭＬアプリケーションを起動させた時点またはＭＬアプリケーションがＤＮＮの計算を実行する時点のリソースに基づいて、担当範囲を決定することができる。ゆえに、通信端末１１の担当範囲を、通信端末１１の状態により応じたものとすることができる。また、この場合、通信端末１１から論理エンティティへのリソースの定期送信や論理エンティティから通信端末１１への担当範囲変更の通知の回数を抑えることができ、各エンティティの処理負荷や通信リソースの使用を軽減することができる。

【0145】

図１５は、通信端末１１の担当範囲を決定するための条件の一例を示す図である。図１５（Ａ）の例では、通信端末１１の計算余力に基づいてＤＮＮの計算範囲を決定する条件が示されている。例えば、図１５（Ａ）の例では、計算余力が９０％以上の場合には担当範囲がｎと示されているが、これは、ＤＮＮの第１レイヤから第ｎレイヤまでの計算を通信端末１１が担当することを示す。なお、図１５の例では、ｎは１０以上の整数であることを想定している。また、第ｎレイヤは、ＤＮＮの最終レイヤであってもよいし、論理エンティティから通知された担当範囲の最終レイヤであってもよい。また、計算余力が減少するにつれて担当範囲が減少されることが示されている。図１５（Ａ）の例では、計算余力が９０％未満で８０％以上の場合には担当範囲が第４ｎ／５レイヤまでと示されており、計算余力が９０％以上の場合よりも低下している。同様に、計算余力が８０％未満で６０％以上の場合には担当範囲が第３ｎ／５レイヤまでと示されており、計算余力が６０％未満で４０％以上の場合には担当範囲が第２ｎ／５レイヤまでと示されており、計算余力が４０％未満で２０％以上の場合には担当範囲が第ｎ／５レイヤまでと示されている。このようにして、通信端末１１の担当範囲を決定してもよい。また、計算余力がそれ以外、つまり、２０％未満の場合には、担当範囲が第１レイヤまでとされているが、これは、通信端末１１がＤＮＮの計算を実行しないことを意味する。すなわち、通信端末１１が計算担当に指定された場合であっても、通信端末１１が計算を拒否する場合もあり得る。このように通信端末１１の計算余力が小さい場合に担当範囲を減少させることにより、通信端末１１の計算余力が少ないがゆえに担当範囲の計算に時間がかかるといった事態を防いでもよい。ここで、計算余力として、相対量（％）に代えて絶対量であるＦＬＯＰＳ(クロック周波数とクロックあたりの演算数の積)を用いてもよいし、その他の計算余力を示しうる値を用いてもよい。

【0146】

図１５（Ｂ）の例は、図１５（Ａ）と同様に担当範囲が決められているが、当該条件が通信品質の一種である遅延時間に基づいている。なお、いずれの通信先との遅延時間かは、予め定めておけばよく、特に限られるものではない。次の計算担当でもよいし、論理エンティティでもよいし、通信端末１１が無線接続する無線通信ノードでもよい。あるいは、遅延時間の主な要因は各エンティティで行われる無線処理であるため、無線（電波）および有線における伝搬遅延を考慮せず無線処理に係る時間を遅延時間とみなしてもよい。図１５（Ｂ）の例では、遅延時間が５００ｍｓ以上の場合には、ＤＮＮの第１レイヤから第ｎレイヤまでの計算を通信端末１１が担当することを示す。そして、遅延時間が５００ｍｓ未満で２５０ｍｓ以上の場合には担当範囲が第４ｎ／５レイヤまでと示されており、遅延時間が２５０ｍｓ未満で１００ｍｓ以上の場合には担当範囲が第３ｎ／５レイヤまでと示されており、遅延時間が１００ｓ未満で５０ｍｓ以上の場合には担当範囲が第３ｎ／５レイヤまでと示されており、遅延時間が５０ｍｓ未満で１０ｍｓ以上の場合には担当範囲が第２ｎ／５レイヤまでと示されており、遅延時間がそれ以外、つまり、１０ｍｓ未満の場合には、通信端末１１がＤＮＮの計算を実行しないことが示されている。

【0147】

なお、図１５（Ｂ）の例では、遅延時間が増加するにつれて通信端末１１の担当範囲が一律に増加しているが、担当範囲を一律に増加させる必要はない。図４に示した通り、計算結果のデータサイズは、ＤＮＮの計算を進めるにつれて一様に減少するわけではない。そのため、図４のようなデータを参照して各レイヤにおける計算結果のデータサイズを考慮し、遅延時間と担当範囲との組み合わせを決定すればよい。

【0148】

また、このような条件は、実施形態の仕様に応じて適宜に設定すればよく、特に限られるものではない。例えば、ＭＬアプリケーションの種類ごとに条件を変えることができる。また、複数の条件を設けて全て満たす場合に変更するとしてもよいし、満たされた条件のうち所定の優先度が最も高い条件に合わせて変更するとしてもよい。

【0149】

また、ＭＬアプリケーションの種類ごとに秘匿度を予め定めておき、実行されたＭＬアプリケーションの秘匿度が所定閾値以上の場合は、通信端末１１の担当範囲を第１レイヤから第２レイヤ以上とするようにしてもよい。こうすることにより、通信端末１１は、ＤＮＮの入力データを、外部に送信しなくなる。これにより、秘匿度の高い情報が通信端末１１以外に漏洩するリスクを低減することができる。

【0150】

しかし、通信端末１１が自身の担当範囲を決定した場合、次の計算担当は、ＤＮＮのいずれのレイヤから計算を開始すべきかを認識できていない。ゆえに、例えば、論理エンティティから各計算担当に担当範囲が通知されていたが、通信端末１１が論理エンティティから通知された担当範囲を変更した場合、次の計算担当は、通信端末１１が担当範囲を変更したことを知らずに、予定されている自身の担当範囲の最初のレイヤの各ノードに通信端末１１からの計算結果を入力する恐れもある。そのため、通信端末１１が自身の担当範囲を決定または変更した場合、通信端末１１は、計算結果のみならず、次の計算担当が計算を開始する位置を認識するための情報を通知する必要がある。当該情報は、例えば、通信端末１１の担当範囲の最後のレイヤを示す情報でもよいし、次の計算担当の担当範囲の最初のレイヤを示す情報でもよいし、計算結果を出力したノードを示す情報でもよいし、計算結果を入力すべきノードを示す情報でもよい。なお、通信端末１１は、当該情報を、直接、次の計算担当に送信してもよいし、論理エンティティを介して次の計算担当に送信してもよい。

【0151】

図１６は、通信端末１１が自身の担当範囲を決定した場合に、通信端末１１から送信される計算結果の一例を示す図である。図１６の例では、計算結果である各ノードの出力値と、当該出力値を出力したノードを識別するための識別情報が含まれている。なお、図１６の例では、ノードの識別情報（識別子）が「node 3_4」のように記載されているが、末尾の数字はノードが含まれるレイヤの番号を示し、「node」の後ろにある数字が当該レイヤにおけるノードの番号を示す。すなわち、「node 3_4」は、第４レイヤに含まれる３番目のノードを示す。また、「node 3_4」と同じ行に記載された「out 3」が第４レイヤに含まれる３番目のノードによる出力値を示す。各ノードの出力がいずれのノードに入力されるかは、ＤＮＮの構造などから認識可能である。図１６のような情報を受け取った次の計算担当は、受信した出力値を入力すべきノードをＤＮＮの構造などから認識して、計算を開始すればよい。

【0152】

なお、これまでの説明では、計算担当は、担当範囲の各ノードに設定された計算を行い、担当範囲の最後のレイヤに属するノードの出力値を、次の計算担当に送信することを想定していた。しかし、一般的には、ＤＮＮのノードには、複数の計算が設定される。そのため、計算担当は、ノードに設定された複数の計算のうちの一部までを行い、その残りは次の計算担当が行うとしてもよい。ノード内の計算例としては、まず、ノードに入力された各入力データに、各入力データが通ってきたリンクに設定された重み係数が掛け合わされた上で加算される。さらに、当該加算値に各ノードに設定されたバイアス値が加算される。そして、加算値が所定の活性化関数に入力され、当該活性化関数からの出力がノードの出力値となる。ゆえに、例えば、加算値の算出までを計算担当が行い、次の計算担当が活性化関数の計算から始めるといったことを予め決めておき、そのように計算が分担されてもよい。なお、ノードに接続されたリンクはエッジとも称される。

【0153】

図１７は、通信端末１１が自身の担当範囲を決定する場合の全体処理の流れを示した概略シーケンス図である。なお、本シーケンス図の例では、ＭＬアプリケーションによって使用されるＤＮＮの構造、ＤＮＮの一連の計算の担当範囲を決めるための条件などは、クラウドシステム１２が管理していることを想定する。また、本シーケンス図の例では、ＤＮＮの計算担当は、通信端末１１とクラウドシステム１２にしているが、通信端末１１と通信ノードが計算担当であることもあり得る。ここで、コアネットワーク１３３の機能は、クラウドシステム１２内に実装することができる。つまり、コアネットワーク１３３が上述の条件を管理することもできる。

【0154】

クラウドシステム１２が、ＭＬアプリケーションによって使用されるＤＮＮ、当該ＤＮＮの設定、担当範囲を決めるための条件などの情報を送信する（Ｔ２０１）。当該情報は、通信ネットワーク１３の通信ノードを介して転送され、通信端末１１が当該情報を受信し（Ｔ２０２）、当該情報に基づき、使用するＤＮＮなどのＭＬアプリケーションの設定を行う。（Ｔ２０３）。

【0155】

なお、通信ノードは、通信端末１１の接続要求、例えばサービス要求（Service Request）やＰＤＵ（Protocol Data Unit）セッション確立要求（PDU Session Establishment Request）、に含まれる５ＱＩ（5G QoS Identifier）やＳ－ＮＳＳＡＩ（Single-Network Slice Selection Assistance Information）などに基づき、通信端末１１がＭＬアプリケーションを起動したことを検知することが可能である。そのため、通信ノードが通信端末１１においてＭＬアプリケーションの起動を検知し、検知したことをクラウドシステム１２に通知し、クラウドシステム１２が検知されたＭＬアプリケーションに使用させるＤＮＮを抽出してもよい。

【0156】

その後、通信端末１１は、ＭＬアプリケーションの実行を決定する（Ｔ２０４）。その際、通信端末１１は、通信端末１１自身の処理能力を確認し（Ｔ２０５）、ＤＮＮの計算の担当範囲を決めるための条件と処理能力とに基づき、通信端末１１の担当範囲を決定する（Ｔ２０６）。例えば、ＤＮＮの担当範囲を決めるための条件が図１５（Ａ）に示した例であって、ＤＮＮが１０個のレイヤから構成されている場合（ｎが１０の場合）に、計算余力が５０％だったとすると、通信端末１１はＤＮＮを分割するレイヤを第４レイヤと決定する。そして、通信端末１１は、ＭＬアプリケーションを実行し、通信端末１１の担当範囲を計算する（Ｔ２０７）。先ほどの例であれば、ＤＮＮの第１レイヤから第４レイヤまでの計算が行われる。

【0157】

なお、担当範囲の計算後に、再度、担当範囲の拡大が行われてもよい。例えば、担当範囲の計算終了後に所定の条件を満たしているか否かを確認し、確認結果に基づいて、次のレイヤにおける計算を引き続き行うか否かを判定してもよい。ここで、所定の条件を満たしているか否かは、計算余力や遅延時間、秘匿度等に基づき判定されてもよい。このように、担当範囲の決定が複数回行われてもよい。

【0158】

通信端末１１は、通信端末１１の担当範囲の計算後、図１６に示したような通信端末１１の担当範囲および計算結果が分かる情報を、通信ノードを介してクラウドシステム１２へ送信する（Ｔ２０８）。クラウドシステム１２は、当該情報を、通信ノードを介して受信する（Ｔ２０９）。

【0159】

クラウドシステム１２は、受信した各ノードの識別情報に基づいて、受信した出力値を入力するノード、つまり、通信端末１１の担当範囲の最後のレイヤの次のレイヤの各ノード、を識別し、クラウドシステム１２の担当範囲を計算する（Ｔ２１０）。そして計算終了後、クラウドシステム１２は、クラウドシステム１２の担当範囲の計算結果を通信端末１１に返信する（Ｔ２１１）。なお、クラウドシステム１２の担当範囲は、ＤＮＮの残り全ての計算を想定するが、ＤＮＮの残り全ての計算でなくともよい。例えば、通信端末１１が、クラウドシステム１２の計算結果を受信して、さらに残りのＤＮＮの計算を行うとしてもよい。

【0160】

通信端末１１は、クラウドシステム１２の計算結果を、通信ノードを介して受信する（Ｔ２１２）。そして、最終の計算結果に基づいてＭＬアプリケーションの処理が実行される（Ｔ２１３）。このようにして、ＭＬアプリケーションの処理が完了する。なお、ＭＬアプリケーションの処理結果まで、クラウドシステム１２など通信端末１１以外のエンティティが算出してもよい。

【0161】

以上のように、各エンティティ間でＤＮＮの分散学習が行われる場合に、ＤＮＮの担当範囲を決めるための条件を通信端末が保持し、通信端末が自身の担当範囲を決定することにより、通信端末の状況に即した分散をより適切に行うことができる。また、ＭＬアプリケーションの秘匿度などに応じて、通信端末が少なくとも第２レイヤまでＤＮＮの計算を行わせることにより、入力データの漏洩といった事態が生じることも防ぐことができる。

【0162】

なお、深層学習（Deep Learning）で使用される一般的なアルゴリズムとしては、畳み込みニューラルネットワーク（ＣＮＮ：Convolution Neural Network）、再帰型ニューラルネットワーク（ＲＮＮ：Recurrent Neural Network）、ＬＳＴＭ（Long Short-Term Memory）等がある。ＣＮＮでは、隠れ層は畳み込み層（Convolution Layer）とプーリング層（Pooling Layer）と呼ばれる各層から構成される。畳み込み層では、畳み込み演算によるフィルタリングを施し、特徴マップと呼ばれるデータを抽出する。プーリング層では、畳込み層から出力された特徴マップの情報を圧縮し、ダウンサンプリング（down sampling）を施す。ＲＮＮでは、隠れ層の値が再帰的に隠れ層に入力されるネットワーク構造を有し、例えば、短期間の時系列のデータが処理される。ＬＳＴＭでは、ＲＮＮの中間層出力に対して、メモリセルと呼ばれる中間層の状態を保持するパラメータを導入することにより、遠い過去の出力の影響を保持することができる。つまり、ＬＳＴＭは、ＲＮＮに比べてより長い期間の時系列のデータが処理される。深層学習が活用される代表的な技術領域として、画像認識、音声認識、自然言語処理、ロボットによる異常検知の４つの分野が挙げられる。画像認識は、ＳＮＳ（Social Network Service）の人のタグ付けや自動運転といった用途に利用されている。音声認識は、スマートスピーカー等に応用されている。自然言語処理は、ブラウザーによる検索や自動翻訳に応用されている。ロボットによる異常検知は、空港、鉄道、製造現場等で利用されている。

【0163】

通信ネットワーク１３の通信ノードについて補足する。前述の通り、通信ノードは、通信基地局（単に基地局とも）と称され、通信を行うためのインフラストラクチャーが含まれており、当該インフラストラクチャーは基地局装置とも称される。基地局装置は通信装置の一種であるし、情報処理装置とも言える。例えば、基地局装置は、無線基地局（Base Station、Node B、eNB、gNB、など）、無線アクセスポイント（Access Point）などとして通信ノードを機能させるための装置であってもよい。また、基地局装置は、ドナー局またはリレー局として通信ノードを機能させる装置であってもよい。また、基地局装置は、ＲＲＨ（Remote Radio Head）と呼ばれる光張り出し装置であってもよい。また、基地局装置は、通信ノードをＦＰＵ（Field Pickup Unit）等の受信局として機能させる装置であってもよい。また、基地局装置は、無線アクセス回線と無線バックホール回線を時分割多重、周波数分割多重、もしくは、空間分割多重で提供するＩＡＢ（Integrated Access and Backhaul）ドナーノード、または、ＩＡＢリレーノードとして通信ノードを機能させる装置であってもよい。また、基地局装置は、複数の装置から構成されていてもよく、例えば、ビル等の構造物に設置されたアンテナ及びそのアンテナに接続する信号処理装置の組み合わせであってもよい。

【0164】

なお、基地局装置が使用する無線アクセス技術は、セルラー通信技術であってもよいし、無線ＬＡＮ技術であってもよい。勿論、基地局装置が使用する無線アクセス技術は、これらに限定されず、他の無線アクセス技術であってもよい。例えば、基地局装置が使用する無線アクセス技術は、ＬＰＷＡ（Low Power Wide Area）通信技術であってもよい。勿論、基地局装置が使用する無線通信は、ミリ波を使った無線通信であってもよい。また、基地局装置が使用する無線通信は、電波を使った無線通信であってもよいし、赤外線や可視光を使った無線通信（光無線）であってもよい。

【0165】

基地局装置は、通信端末１１とＮＯＭＡ（Non-Orthogonal Multiple Access）通信が可能であってもよい。ここで、ＮＯＭＡ通信は、非直交リソースを使った通信（送信、受信、またはその双方）のことである。なお、基地局装置は、他の基地局装置とＮＯＭＡ通信可能であってもよい。

【0166】

なお、基地局装置は、基地局－コアネットワーク間インタフェース（例えば、S1 Interface等）を介してお互いに通信可能であってもよい。このインタフェースは、有線及び無線のいずれであってもよい。また、基地局装置は、基地局間インタフェース（例えば、X2 Interface、S1 Interface等）を介して互いに通信可能であってもよい。このインタフェースは、有線及び無線のいずれであってもよい。

【0167】

なお、基地局装置は、基地局－コアネットワーク間インタフェース（例えば、ＮＧ Interface、S1 Interface等）を介してお互いに通信可能であってもよい。このインタフェースは、有線及び無線のいずれであってもよい。また、基地局装置は、基地局間インタフェース（例えば、Xn Interface、X2 Interface等）を介して互いに通信可能であってもよい。このインタフェースは、有線及び無線のいずれであってもよい。

【0168】

また、基地局という用語が、基地局の機能を備えた構造物（Structure）を意味する場合もあり得る。当該構造物は、特に限られるものではない。例えば、高層ビル、家屋、鉄塔、駅施設、空港施設、港湾施設、オフィスビル、校舎、病院、工場、商業施設、スタジアム等の建物も当該構造物に含まれる。また、トンネル、橋梁、ダム、塀、鉄柱等の構築物（Non-building structure）や、クレーン、門、風車等の設備も、当該構造物に含まれる。また、当該構造物が設置される場所は特に限られるものではない。すなわち、陸上（狭義の地上）又は地中の構造物のみならず、桟橋、メガフロート等の水上の構造物や、海洋観測設備等の水中の構造物も、基地局の機能を備えた構造物となり得る。

【0169】

また、基地局は、前述のように、固定局であってもよいし、移動局であってもよい。基地局装置が移動体に設置されることにより、基地局が移動局となってもよい。あるいは、基地局装置が移動能力（Mobility）を有し、基地局装置自体が移動することによって基地局が移動局となってもよい。また、車両、ドローンに代表されるＵＡＶ（Unmanned Aerial Vehicle）といったもともと移動能力がある装置であって、基地局の機能（少なくとも基地局の機能の一部）を搭載した装置も、移動局とも移動局としての基地局装置とも言える。また、スマートフォンなどのように移動体に携帯されることによって移動する装置であって基地局の機能（少なくとも基地局の機能の一部）を搭載した装置も、移動局とも移動局の基地局装置とも言える。

【0170】

固定局および移動局が存在する場所は、特に限られるわけではない。ゆえに、移動局を構成する移動体は、陸上（狭義の地上）を移動する移動体（例えば、自動車、自転車、バス、トラック、自動二輪車、列車、リニアモーターカー等の車両）であってもよいし、地中（例えば、トンネル内）を移動する移動体（例えば、地下鉄）であってもよいし、水上を移動する移動体（例えば、旅客船、貨物船、ホバークラフト等の船舶）であってもよいし、水中を移動する移動体（例えば、潜水艇、潜水艦、無人潜水機等の潜水船）であってもよいし、大気圏内などの空中を移動する移動体（例えば、飛行機、飛行船、ドローン等の航空機）であってもよいし、大気圏外言い換えれば宇宙を浮遊可能な移動体（例えば、人工衛星、宇宙船、宇宙ステーション、探査機等の人工天体）であってもよい。なお、大気圏外を浮遊する基地局は衛星局とも称される。一方、大気圏外よりも地球側にある基地局は地上局とも称される。また、航空機等、大気圏内を浮遊する基地局は、航空機局とも称される。

【0171】

なお、衛星局となる衛星は、低軌道（LEO：Low Earth Orbiting）衛星、中軌道（MEO：Medium Earth Orbiting）衛星、静止（GEO：Geostationary Earth Orbiting）衛星、高楕円軌道（HEO：Highly Elliptical Orbiting）衛星の何れであってもよい。

【0172】

なお、飛行機、グライダー等の重航空機、気球、飛行船等の軽航空機、ヘリコプターやオートジャイロ等の回転翼機ドローン等の無人航空機も、航空機局となり得る。なお、航空機局となり得る無人航空機をどのように制御するかは特に限られるものではない。すなわち、無人航空機の制御システムには、無人航空システム（UAS：Unmanned Aircraft Systems）、tethered UAS、LTA（Lighter than Air UAS）、HTA（Heavier than Air UAS）HAPs（High Altitude UAS Platforms）といったものがあるが、これらの制御システムによって航空機局の飛行が制御されてよい。

【0173】

また、基地局装置のカバレッジの大きさは、特に限られるものではなく、マクロセルのような大きなものでも、ピコセルのような小さなものでも、フェムトセルのような極めて小さなものでもよい。また、基地局装置はビームフォーミングの能力を有していてもよい。この場合、基地局装置はビームごとにセルやサービスエリアが形成されてもよい。そのために、基地局装置は、複数のアンテナ素子から構成されるアンテナアレーを装備して、ＭＩＭＯ（Multiple Input Multiple Output）やビームフォーミングに代表されるＡｄｖａｎｃｅｄ Ａｎｔｅｎｎａ Ｔｅｃｈｎｏｌｏｇｙを提供するよう構成されていてもよい。

【0174】

図１８は、基地局装置の構成例を示す図である。図１８に示された基地局装置５０は、無線通信を行うことを想定しており、無線通信部５１と、記憶部５２と、制御部５３と、演算部５４と、ネットワーク通信部５５と、アンテナ５６と、を備える。なお、図１８に示した構成は、機能的な構成であり、ハードウェア構成とは異なっていてもよい。また、図１８の構成要素は、さらに分散されていてもよいし、他の構成要素と集約されていてもよい。また、図１８の構成要素が基地局装置５０とは別の装置として独立して存在し、複数の装置によって基地局装置５０の機能が実現されてもよい。

【0175】

無線通信部５１は、他の無線通信装置（例えば、通信端末１１）と無線通信するための信号処理を行う。無線通信部５１は、制御部５３の制御に従って動作する。無線通信部５１は１又は複数の無線アクセス方式に対応する。例えば、無線通信部５１は、ＮＲ（New Radio）及びＬＴＥ（Long Term Evolution）の双方に対応する。無線通信部５１は、ＮＲやＬＴＥに加えて、Ｗ－ＣＤＭＡ（Wideband Code Division Multiple Access）やＣＤＭＡ２０００（Code Division Multiple Access 2000）に対応していてもよい。また、無線通信部５１は、ＨＡＲＱ（Hybrid Automatic Repeat reQuest）等の自動再送技術に対応していてもよい。

【0176】

無線通信部５１は、送信処理部５１０および受信処理部５１５を備える。無線通信部５１は、送信処理部５１０および受信処理部５１５をそれぞれ複数備えていてもよい。なお、無線通信部５１が複数の無線アクセス方式に対応する場合、無線通信部５１の各構成要素は、無線アクセス方式毎に個別に構成されうる。例えば、送信処理部５１０及び受信処理部５１５は、ＬＴＥとＮＲとで個別に構成されてもよい。また、アンテナ５６は、１以上でよく、また、複数のアンテナ素子（例えば、複数のパッチアンテナ）で構成されていてもよい。この場合、無線通信部５１は、ビームフォーミングを可能にするように構成されていてもよい。無線通信部５１は、垂直偏波（Ｖ偏波）と水平偏波（Ｈ偏波）とを使用した偏波ビームフォーミングを可能にするように構成されていてもよい。

【0177】

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

【0178】

そして、送信処理部５１０の変調部５１２は、符号化ビットをＢＰＳＫ（Binary Phase Shift Keying）、ＱＰＳＫ（Quadrature Phase shift Keying）、１６ＱＡＭ（Quadrature Amplitude Modulation）、６４ＱＡＭ、２５６ＱＡＭ等の所定の変調方式で変調する。この場合、変調方式のコンステレーション上の信号点は必ずしも等距離である必要はない。コンステレーションは、不均一コンステレーション（NUC：Non Uniform Constellation）であってもよい。

【0179】

そして、送信処理部５１０の多重部５１３は、送信に用いられる各チャネルの変調シンボルと下りリンク参照信号とを多重化し、所定のリソースエレメントに配置する。

【0180】

そして、送信処理部５１０は、多重化した信号に対して、各種の信号処理を行う。例えば、送信処理部５１０の無線送信部５１４は、高速フーリエ変換による周波数領域への変換、ガードインターバル（サイクリックプレフィックス）の付加、ベースバンドのデジタル信号の生成、アナログ信号への変換、直交変調、アップコンバート、余分な周波数成分の除去、電力の増幅等の処理を行う。無線送信部５１４により生成された信号は、アンテナ５６から送信される。

【0181】

受信処理部５１５は、アンテナ５６を介して受信された上りリンク信号の処理を行う。例えば、受信処理部５１５の無線受信部５１６は、上りリンク信号に対して、ダウンコンバート、不要な周波数成分の除去、増幅レベルの制御、直交復調、デジタル信号への変換、ガードインターバル（サイクリックプレフィックス）の除去、高速フーリエ変換による周波数領域信号の抽出等を行う。

【0182】

そして、受信処理部５１５の多重分離部５１７は、無線受信部５１６の処理が行われた信号から、ＰＵＳＣＨ（Physical Uplink Shared Channel）、ＰＵＣＣＨ（Physical Uplink Control Channel）等の上りリンクチャネル及び上りリンク参照信号を分離する。

【0183】

また、受信処理部５１５の復調部５１８は、上りリンクチャネルの変調シンボルに対して、ＢＰＳＫ、ＱＰＳＫ等の変調方式を使って受信信号の復調を行う。復調に使用される変調方式は、１６ＱＡＭ、６４ＱＡＭ、又は２５６ＱＡＭであってもよい。この場合、コンステレーション上の信号点は必ずしも等距離である必要はない。コンステレーションは、不均一コンステレーション（NUC）であってもよい。

【0184】

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

【0185】

アンテナ５６は、電流と電波を相互に変換する。アンテナ５６は、１つのアンテナ素子（例えば、１つのパッチアンテナ）で構成されていてもよいし、複数のアンテナ素子（例えば、複数のパッチアンテナ）で構成されていてもよい。アンテナ５６が複数のアンテナ素子で構成される場合、無線通信部５１は、ビームフォーミングを可能にするように構成されていてもよい。例えば、無線通信部５１は、複数のアンテナ素子を使って無線信号の指向性を制御することで、指向性ビームを生成するよう構成されていてもよい。なお、アンテナ５６は、デュアル偏波アンテナであってもよい。アンテナ５６がデュアル偏波アンテナの場合、無線通信部５１は、無線信号の送信にあたり、垂直偏波（Ｖ偏波）と水平偏波（Ｈ偏波）とを使用してもよい。そして、無線通信部５１は、垂直偏波と水平偏波とを使って送信される無線信号の指向性を制御してもよい。

【0186】

記憶部５２は、基地局装置５０の記憶手段として、基地局装置５０の処理に必要な情報、処理結果などを記憶する。例えば、基地局装置５０の処理を行うための各種プログラムが記憶されていてもよい。

【0187】

制御部５３は、基地局装置５０の各部を制御する。例えば、制御部５３は、無線通信部５１またはネットワーク通信部５５を介して、論理エンティティなどから使用されるＤＮＮに係る情報、ＤＮＮの一連の計算の担当範囲を決めるための条件などを外部から取得するために必要な制御を行う。

【0188】

演算部５４は、制御部５３の指示に従って、基地局装置５０の処理に必要な演算を行う。例えば、送信処理部５１０や受信処理部５１５が行う処理の一部、例えば負荷の高い演算を、演算部５４が肩代わりしてもよい。また、例えば、基地局装置が計算担当である場合に、基地局装置の担当範囲の計算は、演算部５４によって行われてもよい。また、例えば、基地局装置５０が論理エンティティである場合は、論理エンティティが実行する処理、例えば、リソースに基づく計算担当の決定、担当範囲の決定などが、演算部５４によって行われてもよい。

【0189】

ネットワーク通信部５５は、他の通信装置（例えば、クラウドシステム１２）と有線通信するための信号処理を行う。例えば、例えば、ネットワーク通信部５５は、コアネットワークのＡＭＦ（Access and Mobility Management Function）やＵＰＦ（User Plane Function）と接続されて、情報やシグナリングを交換する。

【0190】

いくつかの実施形態において、基地局装置は、複数の物理的又は論理的装置によって構成されていてもよい。例えば、本実施形態において基地局装置は、ＢＢＵ（Baseband Unit）及びＲＵ（Radio Unit）等の複数の装置に区別されてもよい。そして、基地局装置は、これら複数の装置の集合体、言い換えれば基地局システム、として解釈されてもよい。また、基地局装置は、ＢＢＵ及びＲＵのうちのいずれかであってもよいし、両方であってもよい。ＢＢＵとＲＵは、ｅＣＰＲＩ（enhanced Common Public Radio Interface）などの所定のインタフェースで接続されていてもよい。なお、ＲＵはＲＲＵ（Remote Radio Unit )又はＲＤ（Radio DoT）と言い換えてもよい。また、ＲＵは後述するｇＮＢ－ＤＵ（gNB Distributed Unit）に対応していてもよい。さらにＢＢＵは、後述するｇＮＢ－ＣＵ（gNB Central Unit）に対応していてもよい。さらに、ＲＵはアンテナと一体的に形成された装置であってもよい。基地局装置が有するアンテナ（例えば、ＲＵと一体的に形成されたアンテナ）はAdvanced Antenna Systemを採用し、ＭＩＭＯ（例えば、ＦＤ－ＭＩＭＯ）やビームフォーミングをサポートしていてもよい。また、基地局が有するアンテナは、例えば、６４個の送信用アンテナポート及び６４個の受信用アンテナポートを備えていてもよい。

【0191】

また、ＲＵに取り付けられたアンテナは１以上であってもよく、当該アンテナは、１つ以上のアンテナ素子から構成されるアンテナパネルであってもよい。例えば、ＲＵは、水平偏波のアンテナパネルと垂直偏波のアンテナパネルの２種類を含むアンテナパネル、または、右旋円偏波のアンテナパネルと左旋円偏波のアンテナパネルの２種類を含むアンテナパネルを搭載してもよい。また、ＲＵは、アンテナパネル毎に独立したビームを形成し、制御してもよい。

【0192】

なお、無線アクセスネットワーク（ＲＡＮ：Radio Access Network）の基地局はＲＡＮノードと称され、ＡＮ（Access Network）の基地局はＡＮノードと称されることがある。なお、ＬＴＥにおけるＲＡＮはＥ－ＵＴＲＡＮ（Enhanced Universal Terrestrial RAN）と呼ばれることがある。また、ＮＲにおけるＲＡＮはＮＧ－ＲＡＮと呼ばれることがある。また、Ｗ－ＣＤＭＡ（ＵＭＴＳ）におけるＲＡＮはＵＴＲＡＮと呼ばれることがある。

【0193】

なお、ＬＴＥの基地局は、ｅＮｏｄｅＢ（Evolved Node B）又はｅＮＢとも称され、このとき、Ｅ－ＵＴＲＡＮは１又は複数のｅＮｏｄｅＢ（ｅＮＢ）を含むと言える。また、ＮＲの基地局は、ｇＮｏｄｅＢ又はｇＮＢとも称され、このとき、ＮＧ－ＲＡＮは１又は複数のｇＮＢを含むと言える。Ｅ－ＵＴＲＡＮは、ＬＴＥの通信システム（ＥＰＳ）におけるコアネットワーク（ＥＰＣ）に接続されたｇＮＢ（ｅｎ－ｇＮＢ）を含んでいてもよい。同様に、ＮＧ－ＲＡＮは５Ｇ通信システム（５ＧＳ）におけるコアネットワーク５ＧＣに接続されたｎｇ－ｅＮＢを含んでいてもよい。

【0194】

なお、基地局がｅＮＢ、ｇＮＢなどである場合、基地局は、３ＧＰＰアクセス（3GPP Access）と称されることがある。また、基地局が無線アクセスポイント（Access Point）である場合、基地局は、非３ＧＰＰアクセス（Non-3GPP Access）と称されることがある。また、基地局がｇＮＢである場合、基地局は、前述したｇＮＢ－ＣＵとｇＮＢ－ＤＵとを組み合わせたものであってもよいし、ｇＮＢ－ＣＵとｇＮＢ－ＤＵとのうちのいずれかであってもよい。

【0195】

ここで、ｇＮＢ－ＣＵは、ＵＥとの通信のために、アクセス層（Access Stratum）のうち、複数の上位レイヤ（例えば、ＲＲＣ、ＳＤＡＰ、ＰＤＣＰ）をホストする。一方、ｇＮＢ－ＤＵは、アクセス層（Access Stratum）のうち、複数の下位レイヤ（例えば、ＲＬＣ、ＭＡＣ、ＰＨＹ）をホストする。すなわち、ＲＲＣシグナリング、ＭＡＣ ＣＥ（MAC Control Element）、ＤＣＩといったメッセージまたは情報のうち、ＲＲＣシグナリング（準静的な通知）はｇＮＢ－ＣＵで生成され、一方でＭＡＣ ＣＥやＤＣＩ（動的な通知）はｇＮＢ－ＤＵで生成されてもよい。又は、ＲＲＣコンフィギュレーション（準静的な通知）のうち、例えばIE:cellGroupConfigなどの一部のコンフィギュレーション（configuration）についてはｇＮＢ－ＤＵで生成され、残りのコンフィギュレーションはｇＮＢ－ＣＵで生成されてもよい。これらのコンフィギュレーションは、後述されるＦ１インタフェースで送受信されてもよい。

【0196】

なお、基地局は、他の基地局と通信可能に構成されていてもよい。例えば、複数の基地局装置がｅＮＢ同士又はｅＮＢとｅｎ－ｇＮＢの組み合わせである場合、当該基地局間はＸ２インタフェースで接続されてもよい。また、複数の基地局がｇＮＢ同士又はｇｎ－ｅＮＢとｇＮＢの組み合わせである場合、当該装置間はＸｎインタフェースで接続されてもよい。また、複数の基地局がｇＮＢ－ＣＵとｇＮＢ－ＤＵの組み合わせである場合、当該装置間は前述したＦ１インタフェースで接続されてもよい。ＲＲＣシグナリング、ＭＡＣ ＣＥ、ＤＣＩといったメッセージまたは情報は、複数の基地局間で、例えばＸ２インタフェース、Ｘｎインタフェース、又はＦ１インタフェースを介して、送信されてもよい。

【0197】

基地局により提供されるセルはサービングセル（Serving cell）と呼ばれることがある。サービングセルという概念には、ＰＣｅｌｌ（Primary Cell）及びＳＣｅｌｌ（Secondary Cell）が含まれる。デュアルコネクティビティがＵＥに設定される場合、ＭＮ（Master Node）によって提供されるＰＣｅｌｌ、及びゼロ又は１以上のＳＣｅｌｌはマスターセルグループ（Master Cell Group）と呼ばれることがある。デュアルコネクティビティの例として、E-UTRA-E-UTRA Dual Connectivity、E-UTRA-NR Dual Connectivity（ENDC）、E-UTRA-NR Dual Connectivity with 5GC、NR-E-UTRA Dual Connectivity（NEDC）、NR-NR Dual Connectivityが挙げられる。

【0198】

なお、サービングセルはＰＳＣｅｌｌ（Primary Secondary Cell、又は、Primary SCG Cell）を含んでもよい。デュアルコネクティビティがＵＥに設定される場合、ＳＮ（Secondary Node）によって提供されるＰＳＣｅｌｌ、及びゼロ又は１以上のＳＣｅｌｌは、ＳＣＧ（Secondary Cell Group）と呼ばれることがある。特別な設定（例えば、PUCCH on SCell）がされていない限り、物理上りリンク制御チャネル（ＰＵＣＣＨ）はＰＣｅｌｌ及びＰＳＣｅｌｌで送信されるが、ＳＣｅｌｌでは送信されない。また、無線リンク障害（Radio Link Failure）もＰＣｅｌｌ及びＰＳＣｅｌｌでは検出されるが、ＳＣｅｌｌでは検出されない（検出しなくてよい）。このようにＰＣｅｌｌ及びＰＳＣｅｌｌは、サービングセルの中で特別な役割を持つため、ＳｐＣｅｌｌ（Special Cell）とも呼ばれる。

【0199】

１つのセルには、１つのダウンリンクコンポーネントキャリアと１つのアップリンクコンポーネントキャリアが対応付けられていてもよい。また、１つのセルに対応するシステム帯域幅は、複数のＢＷＰ（Bandwidth Part）に分割されてもよい。この場合、１又は複数のＢＷＰがＵＥに設定され、１つのＢＷＰ分がアクティブＢＷＰ（Active BWP）として、ＵＥに使用されてもよい。また、セル毎、コンポーネントキャリア毎又は ＢＷＰ毎に、ＵＥが使用できる無線資源（例えば、周波数帯域、ヌメロロジー（サブキャリアスペーシング）、スロットフォーマット（Slot configuration）が異なっていてもよい。

【0200】

通信端末１１について補足する。通信端末１１は、移動体に設置されることにより移動してもよいし、移動体そのものであってもよい。例えば、通信端末１１は、自動車、バス、トラック、自動二輪車等の道路上を移動する車両（Vehicle）、列車等の軌道に設置されたレール上を移動する車両、或いは、当該車両に搭載された無線通信装置であってもよい。なお、移動体は、モバイル端末であってもよいし、陸上（狭義の地上）、地中、水上、或いは、水中を移動する移動体であってもよい。また、移動体は、ドローン、ヘリコプター等の大気圏内を移動する移動体であってもよいし、人工衛星等の大気圏外を移動する移動体であってもよい。また、通信端末１１は、情報処理機能および通信機能が具備され、本開示の処理が実施可能な装置であれば、主要な用途は問わない。例えば、情報処理機能および通信機能が具備された業務用カメラといった機器であってもよいし、ＦＰＵ（Field Pickup Unit）等の通信機器であってもよい。また、通信端末１１は、Ｍ２Ｍ（Machine to Machine）デバイス、又はＩｏＴ（Internet of Things）デバイスであってもよい。

【0201】

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

【0202】

通信端末１１は、移動体に設置された通信装置であってもよいし、移動能力を有した通信装置であってもよい。例えば、通信端末１１を設置した移動体は、自動車、バス、トラック、自動二輪車等の道路上を移動する車両（Vehicle）でも、列車等の軌道に設置されたレール上を移動する車両でもよい。もよい。なお、移動体が移動する場所は特に限られるものではない。ゆえに、当該移動体は、陸上（狭義の地上）、地中、水上、または、水中を移動する移動体であってもよい。また、当該移動体は、ドローン、ヘリコプター等の大気圏内を移動する移動体であってもよいし、人工衛星等の大気圏外を移動する移動体であってもよい。

【0203】

通信端末１１は、同時に複数の基地局または複数のセルと接続して通信を実施してもよい。例えば、１つの基地局が複数のセル（例えば、ｐＣｅｌｌ、sＣｅｌｌ）を介して通信エリアをサポートしている場合に、キャリアアグリゲーション（CA：Carrier Aggregation）技術やデュアルコネクティビティ（DC：Dual Connectivity）技術、マルチコネクティビティ（MC：Multi-Connectivity）技術によって、それら複数のセルを束ねて基地局と通信端末１１とで通信することが可能である。或いは、異なる基地局のセルを介して、協調送受信（CoMP：Coordinated Multi-Point Transmission and Reception）技術によって、通信端末１１とそれら複数の基地局が通信することも可能である。

【0204】

図１９は、通信端末１１の構成例を示す図である。図１９は、無線通信を行う場合の構成例であり、通信端末１１が、無線通信部１１１と、記憶部１１２と、制御部１１３と、演算部１１４と、アンテナ１１５と、を備える。なお、図１９に示した構成は、機能的な構成であり、ハードウェア構成とは異なっていてもよい。また、通信端末１１の機能は、複数の物理的に分離された構成要素に分散して実装されてもよい。

【0205】

無線通信部１１１は、他の無線通信装置（例えば、基地局、中継局、無線通信ノード１３１、ドナーノード１３２、他の通信端末１１など）と無線通信するための信号処理を行う。無線通信部１１１は、制御部１１３の制御に従って動作する。無線通信部１１１は、送信処理部１１１０と、受信処理部１１１５と、を備える。通信端末１１の無線通信に係る構成要素は、基地局装置５０の無線通信に係る対応する構成要素と同様でよい。すなわち、無線通信部１１１及びその内部の構成要素、並びにアンテナ１１５の構成は、基地局装置５０の無線通信部５１及びその内部の構成要素、並びにアンテナ５６と、それぞれ同様であってもよい。また、無線通信部１１１は、基地局装置５０の無線通信部５１と同様に、ビームフォーミングを可能にするように構成されていてもよい。

【0206】

記憶部１１２は、通信端末１１の記憶手段として、通信端末１１の処理に必要な情報、処理結果などを記憶する。例えば、通信端末１１の処理を行うための各種プログラムが記憶されていてもよい。

【0207】

制御部１１３は、通信端末１１の各部を制御する。例えば、制御部１１３は、無線通信部１１１を介して、論理エンティティなどから使用されるＤＮＮに係る情報、ＤＮＮの一連の計算の担当範囲を決めるための条件などを外部から取得するために必要な制御を行う。

【0208】

演算部１１４は、制御部１１３の指示に従って、通信端末１１の処理に必要な演算を行う。例えば、送信処理部１１１０や受信処理部１１１５が行う処理の一部、例えば負荷の高い演算を、演算部１１４が肩代わりしてもよい。また、例えば、ＤＮＮの計算など、通信端末１１が実行するＭＬアプリケーションに必要な演算を行う。

【0209】

コアネットワークについて補足する。図２０は、コアネットワーク１３３を含む５ＧＳ（5G System）のネットワークアーキテクチャの構成例を示す図である。図２０の例では、５ＧＳは、通信端末１１（図２０にはＵＥと記載）、ＲＡＮ１３４、コアネットワーク１３３から構成されている。ＲＡＮ１３４は、図１の無線通信ノード１３１およびドナーノード１３２のように、ネットワーク機能（NF; Network Function）を提供する。５ＧＳにおけるコアネットワーク１３３は、ＮＧＣ（Next Generation Core）、５ＧＣ（5G Core）等と呼称される。

【0210】

図２０の例では、コアネットワーク１３３のコントロール・プレーンの機能群は、ＡＭＦ（Access and Mobility Management Function）６０１と、ＮＥＦ（Network Exposure Function）６０２と、ＮＲＦ（Network Repository Function）６０３と、ＮＳＳＦ（Network Slice Selection Function）６０４と、ＰＣＦ（Policy Control Function）６０５と、ＳＭＦ（Session Management Function）６０６と、ＵＤＭ（Unified Data Management）６０７と、ＡＦ（Application Function）６０８と、ＡＵＳＦ（Authentication Server Function）６０９と、ＵＣＭＦ（UE radio Capability Management Function）６１０と、いった複数のＮＦにより構成されている。

【0211】

ＵＤＭ６０７は、加入者情報の保持、管理、処理などを行う。なお、加入者情報の保持および管理の実行部はＵＤＲ（Unified Data Repository）とも称され加入者情報の処理の実行部であるＦＥ（Front End）とは分けられていてもよい。また、ＡＭＦ６０１は、モビリティ管理を行う。ＳＭＦ６０６は、セッション管理を行う。ＵＣＭＦ６１０は、ＰＬＭＮ（Public Land Mobile Network）における全てのＵＥ無線ケイパビリティＩＤ（UE Radio Capability ID）に対応するＵＥ無線ケイパビリティ情報（UE Radio Capability Information）を保持している。ＵＣＭＦ６１０は、各ＰＬＭＮ－割り当てＵＥ無線ケイパビリティＩＤ（PLMN-assigned UE Radio Capability ID）を割り当てる役割を担っている。

【0212】

図２０には、ＮＦのサービスベースドインターフェース（Service-based interface）が示されている。Namfは、ＡＭＦ６０１が提供するサービスベースドインターフェースであり、Nsmfは、ＳＭＦ606が提供するサービスベースドインターフェースであり、Nnefは、ＮＥＦ６０２が提供するサービスベースドインターフェースであり、Npcfは、ＰＣＦ６０５が提供するサービスベースドインターフェースであり、Nudmは、ＵＤＭ６０７が提供するサービスベースドインターフェースであり、Nafは、ＡＦ６０８が提供するサービスベースドインターフェースであり、Nnrfは、ＮＲＦ６０３が提供するサービスベースドインターフェースであり、Nnssfは、ＮＳＳＦ６０４が提供するサービスベースドインターフェースであり、Nausfは、ＡＵＳＦ６０９が提供するサービスベースドインターフェースである。各ＮＦは、各サービスベースドインターフェースを介して他のＮＦと情報の交換を行う。

【0213】

通信品質などの通信ネットワークに関する情報（ネットワークレイヤ側の情報）を、アプリケーションレイヤで稼働するアプリケーションが取得するためには、インタラクションが必要となることもあり得る。そのような場合、ＮＥＦ６０２のような規定を設けて置けばよい。当該規定により、通信レイヤの情報をアプリ側で詳細に把握できるようになるほか、外部アプリからＮＦの制御も可能になる。

【0214】

また、ＵＰＦ（User Plane Function）６３０は、ユーザ・プレーン処理を実行する。ＤＮ（Data Network）６４０は、ＭＮＯ(Mobile Network Operator)独自のサービス、インターネット、サードパーティーのサービスへの接続を可能にする。

【0215】

ＲＡＮ１３４は、コアネットワーク１３３、通信端末１１などとの通信接続を行う。なお、図示されていない他の通信ネットワーク、例えば、ＡＮ（Access Network）との通信接続も行ってよい。ＲＡＮ１３４は、ｇＮＢ、あるいは、ｎｇ－ｅＮＢと呼ばれる基地局を含む。ＲＡＮのことをＮＧ（Next Generation）－ＲＡＮと称する場合もある。

【0216】

ＵＥ１０とＡＭＦ６０１間では、リファレンスポイントＮ１を介して相互に情報の交換が行われる。ＲＡＮ１３４とＡＭＦ６０１間では、リファレンスポイントＮ２を介して相互に情報の交換が行われる。ＳＭＦ６０６とＵＰＦ６３０間では、リファレンスポイントＮ４を介して相互に情報の交換が行われる。

【0217】

なお、通信品質は、例えば、送受信における遅延時間、データレート、チャンネル占有率（Channel Occupancy Ratio）などで示されてもよい。チャンネル占有率は、ＣＢＲ（Channel Busy Ratio）、リソース使用率、または混雑度で示されてもよい。例えば、ＣＢＲは利用可能な全無線リソースに対する使用している無線リソースの割合で示されてもよい。また、混雑度は、基準信号（Reference Signal）の受信強度であるＲＳＲＰ（Reference Signal Received Power）に対する帯域内の全受信電力であるＲＲＳＩ（Received Signal Strength Indicator）の比で示されてもよい。また、混雑度は、基準信号の受信品質であるＲＳＲＱ（Reference Signal Received Quality）の逆数で示されてもよい。

【0218】

（第２実施形態）
第１実施形態において説明した通り、ＭＬアプリケーションは、ＤＮＮの一連の計算の結果に基づいて処理を行う。しかし、当該一連の計算の途中の計算結果に基づいてＭＬアプリケーションの処理を行ったとしても、ＭＬアプリケーションの処理結果に影響が少ない場合もあり得ることが、近年の研究により判明している。このように、ＤＮＮの一連の計算全てを行わずに計算途中でブレイクアウトさせることは、Early-exitingと称される（Early terminationとも称される）。

【0219】

Early-exitingを行うことによって、ＭＬアプリケーションの精度は下がり得るが、最後まで計算が行われないため、ＭＬアプリケーションの処理が完了するまでに要する時間は抑えられる。特に、第１実施形態のように、複数の通信装置が計算を分担し、通信ネットワークを介して計算結果を順に渡していく場合、計算余力、通信品質などの通信リソースの状況によっては、ＤＮＮの計算結果が想定以上に遅く返信されることもあり得る。ゆえに、第２実施形態の情報処理システムは、状況に応じてEarly-exitingを行い、ＤＮＮの一連の計算の途中の計算結果を通信端末１１に返信する。これにより、ＭＬアプリケーションの処理が完了するまでに要する時間を抑える。

【0220】

なお、第１実施形態では、論理エンティティが計算担当を決定していたが、Early-exitingを行う第２実施形態では、計算担当は予め定められていてもよい。また、第１実施形態では、状況に応じて、論理エンティティが計算担当を動的に変更することができたが、第２実施形態では、計算担当は固定で変更できないとしてもよい。また、遅延時間などのＭＬアプリケーションの要求を満たせないと判定された場合に、計算担当の動的変更とEarly-exitingのいずれを実行するかが決定されてもよい。

【0221】

なお、Early-exitingを行う場合、計算担当のいずれかがＤＮＮの一連の計算の途中の計算結果を通信端末１１に送信することになるが、当該計算担当は、論理エンティティから指定された担当範囲の計算を最後まで実行し、実行された計算結果を通信端末１１に送信する場合もあり得るし、担当範囲の途中で計算を終了して実行された計算結果を通信端末１１に送信する場合もあり得る。例えば、ある計算担当の担当範囲がＤＮＮの第３レイヤと第４レイヤであるときに、第３レイヤの計算までを行い、第３レイヤの計算結果を通信端末１１に送信することもあり得る。

【0222】

ただし、Early-exitingを行う場合、計算を終了する位置を考慮したほうが好ましい。図４に示したように、ＤＮＮの各レイヤにおけるデータサイズはまとまりがない。そのため、論理エンティティは、送信されるデータサイズが大きいために遅延が大きくなることがないよう、計算担当の担当範囲を決定していた。ゆえに、計算担当が担当範囲の計算を途中終了した場合、途中終了した位置によっては計算結果のデータサイズが大きくなり、通信に時間がかかり、Early-exitingを行ったにも関わらず遅延が大きくなるといった事態も起こり得る。また、論理エンティティは、計算担当間の通信帯域が大きい場合、計算結果のデータサイズが大きくても問題ないと判断し得るが、Early-exitingを行う場合、計算結果は次の計算担当ではなく通信端末１１に送信されるので、考慮すべき通信帯域が異なる。例えば、通信端末１１と、最初の計算担当である通信ノードＡと、が無線接続されており、通信ノードＡと、２番目の計算担当である通信ノードＢと、が有線接続されている場合もあり得る。このような場合、通信ノードＡから通信ノードＢへ送信される計算結果のデータサイズは、無線通信に対しては大きすぎることもあり得る。また、通信ノードＡの担当範囲を計算した場合の計算結果では、ＭＬアプリケーションの精度が低くなる恐れもある。このように、各計算担当に担当範囲に含まれる全ての計算を実行させることがEarly-exitingに適さない場合もあり得る。

【0223】

また、担当範囲の計算を途中終了する場合では、ＭＬアプリケーションの処理精度の改善などを目的として、追加の計算を実行する場合もあり得る。また、追加の計算は、計算を途中終了する位置などによって異なっていてもよい。例えば、担当範囲の計算を途中終了する場合の計算範囲を予め複数用意しておき、担当範囲の計算を途中終了する場合には、複数の計算範囲のうちからいずれか一つを選択してもよい。図２１は、Early-exitingを行う場合の計算範囲の例を示す図である。図２１の矢印で示された計算フロー７１は、担当範囲の計算を途中終了する場合の計算の流れ（計算範囲）を示す。計算フロー７２は、担当範囲の計算を途中終了する場合の計算の流れを示す。計算フロー７３は、担当範囲の計算を途中終了しない場合の計算の流れを示す。計算フロー７１と計算フロー７２の折れ曲がった後の畳み込み処理は、通常の担当範囲に含まれる計算とは別に追加された計算である。ここでは、途中終了した計算フローから、推論結果を出力するための計算を行う。換言すると、ディープニューラルネットワークの一連の計算における途中の計算の結果を送信するための計算を行う。計算フロー７３に示すように、Early-exitingを行わない場合、２番目の処理として５x５の畳み込み処理（Ｃｏｎｖ５x５）が行われるが、計算フロー７１上の２番目の処理は３x３の畳み込み処理（Ｃｏｎｖ３x３）となっている。計算フロー７１と計算フロー７２のいずれを実行するかは、計算結果のデータサイズ、要する時間などに応じて選択されればよい。あるいは、計算担当がEarly-exitingの実行指示を受けた時点において計算が進んでおり、計算フロー７１の通りに実行できない場合に、計算フロー７２が選択されるといったことが行われてもよい。第１から第３の計算フローに示したように、Early-exitingが行われる場合、計算担当は担当範囲の少なくとも一部の計算を実行するが、計算担当が実行した計算内容全体はそのときの状況に応じて異なり得る。なお、Early-exitingの判定実施は、担当範囲の計算の中で、開始から終了の間のいずれかの位置において判定が行われてもよい。換言すると、当該判定の前に計算を実行しても良いし、判定の前に計算を実行しなくても良いし、判定の後に計算を実行しても良いし、判定の後に計
算を実行しなくても良い。また、それらの処理の有無は判定の結果や本明細書に示すその他の情報に基づいて異なっても良い。

【0224】

Early-exitingの判定条件は、様々なものが考えられ、適宜に定めてよい。複数の条件を設けてもよいし、複数のパラメータに基づいた判定条件を用いてもよい。例えば、計算結果に関する条件をEarly-exitingの判定条件としてもよい。例えば、自身の計算範囲の最終計算結果または各レイヤにおける計算結果に基づいて判定を行ってもよい。また、計算結果にソフトマックス関数などの活性化関数をさらに適用した上で判定を行ってもよい。また、交差エントロピーの値を用いて判定してもよい。例えば、ソフトマックス関数の出力値が所定の閾値以上であったときに、そのレイヤでＤＮＮの処理を終了し、Early-exitingを行うとしてもよい。

【0225】

また、Early-exitingの判定条件として、計算担当に関する条件を設けてもよい。例えば、計算担当の計算余力を判定条件に用いてよい。

【0226】

また、Early-exitingの判定条件として、通信に関する条件を設けてもよい。例えば、ＲＡＲＰ、ＲＡＲＱ、ＲＳＳＩ、Ｌｉｎｋ ｆａｉｌｕｒｅといった通信ネットワークの通信品質を判定条件にしてもよい。例えば、次の計算担当への通信リンクの品質が悪い場合、パケットエラーによって遅延が大きくなり得る。そのため、通信品質が悪いほど、Early-exitingをなるべく行うような判定条件を設けてもよい。また、送信する計算結果のデータ量が小さければ、通信品質が悪くとも送信可能なこともあり得る。ゆえに、送信する計算結果のデータ量も判定条件に含めてよい。また、通信ネットワークのパス情報を判定条件としてもよい。例えば、端末同士間通信（ＰＣ５）では一般的に通信リンクの帯域が細いため、端末同士間通信（ＰＣ５）であった場合には、通信品質が悪いとみなし、Early-exitingを行うような判定条件を設けてもよい。また、ルート上に流れるトラフィック量の情報、各ノードで処理しているトラフィック量の情報といったトラフィックに基づく判定条件であってもよい。なお、トラフィックは、通信リソースの使用率などで表されてもよい。

【0227】

また、Early-exitingの判定条件として、通信端末１１の移動（モビリティ）に関する条件を設けてもよい。例えば、移動速度、移動方向、移動によって生じたリンク切り替えやハンドオーバーに関する情報を判定条件に用いてよい。通信端末１１のモビリティが高い場合、ＤＮＮの計算途中において、通信端末１１がハンドオーバーする恐れが高くなる。そのため、Early-exitingを行い、ハンドオーバーが起きる前に、ＤＮＮの途中の計算結果を通信端末１１に返信してしまうことが考えられる。

【0228】

また、ＭＬアプリケーションなどからの要求を満たすかどうかを判定条件としてもよい。例えば、ＤＮＮの計算結果が通信端末１１に返信されるまでの時間（遅延）、Early-exitingによって返信されるＤＮＮの途中の計算結果の確からしさ（精度）などを含む要求情報をＭＬアプリケーションから取得された場合に、これらの要求事項を満たすかどうかが、計算余力、通信品質、これまでの実績などに基づいて判定されてもよい。

【0229】

また、Early-exitingの実行指示を受け取ったか否か判定条件としてもよい。例えば、ＤＮＮの計算結果が通信端末１１に返信されるまでの時間（遅延）を所定時間内に収めたい場合に、通信端末１１がアプリケーションレイヤでタイムスタンプをつけ、返信を受け取るまでの時間をカウントし、当該時間が上限を過ぎた時点でEarly-exitingの実行指示を送信する。通信端末１１が計算担当を全て認識している場合は、通信端末１１が全ての計算担当に実行指示を送信してもよい。各計算担当を通信端末１１が認識していない場合などでは、通信端末１１から順に各計算担当に実行指示がリレーされてもよい。そして、計算中にEarly-exitingの通知を受け取った計算担当がEarly-exitingを行えばよい。なお、通信端末１１が所要時間をカウントするのではなく、各計算担当が、事前に設定した許容時間から計算に要した時間を減算して次の計算担当に通知し、許容時間を使い切った計算担当が計算結果を通信端末１１に送信することも考えられる。また、担当範囲の計算に必要な時間が許容時間よりも小さい場合に、担当範囲の計算を途中終了することも考えられる。なお、所要時間の上限値、遅延マージン値など、Early-exitingを行うか否かを判定するためのパラメータの値は、論理エンティティが決定してもよいし、ＭＬアプリケーションが決定してもよい。

【0230】

なお、Early-exitingの判定条件は、時間帯、ＭＬアプリケーションの種類、並行して実行される他のＭＬアプリケーションなどに応じて、変更されてもよい。例えば、精度が要求されるＭＬアプリケーションの場合ではEarly-exitingの判定条件を標準よりも厳しくし、所要時間を抑えることが要求されるＭＬアプリケーションの場合では、Early-exitingの判定条件を標準よりも緩やかにしてもよい。

【0231】

また、判定条件に用いられる情報は、ＮＥＦ（Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）などを介して、アプリケーションレイヤから通信レイヤへと通知されてもよい。

【0232】

Early-exitingを行う際の処理の流れについて説明する。図２２は、Early-exitingに関する処理の流れの第１例を示した概略シーケンス図である。なお、図の都合上、通信端末以外の計算担当はまとめて一つとして表している。

【0233】

論理エンティティが、Early-exitingの判定条件を計算担当に送信する（Ｔ３０１）。なお、計算担当が固定でない場合は、計算担当となり得るエンティティに当該判定条件を予め送信しておいてもよいし、あるいは、計算担当が変更された時点で計算担当が変更されたことを通知するとともに当該判定条件を送信してもよい。各計算担当は、論理エンティティからの判定条件を受信して設定する（Ｔ３０２）。

【0234】

その後、通信端末１１がＭＬアプリケーションを実行し（Ｔ３０３）、次の計算担当に対し、ＤＮＮの計算に必要な情報を送信する（Ｔ３０４）。通信端末１１が計算担当の場合は、通信端末１１が行ったＤＮＮの計算結果もＤＮＮの計算に必要な情報に含まれる。また、通信端末１１は、判定に用いられる情報を送信してもよい。例えば、計算結果が通信端末１１に返信されるまでに要する時間の上限値（許容時間）、計算結果の精度などを通信端末１１が各計算担当に送信し、各計算担当は当該情報を判定条件のパラメータの値として用いてもよい。

【0235】

次の計算担当は、ＤＮＮの計算に必要な情報を受け取り（Ｔ３０５）、Early-exitingの判定に必要な情報を収集し、収集された情報を用いてEarly-exitingの判定を行う（Ｔ３０６）。なお、当該情報を予め収集しておいてもよい場合は、事前に収集しておいてもよい。判定結果に基づいてＤＮＮの計算を実行する（Ｔ３０７）。前述の通り、Early-exitingの実行する場合と実行しない場合とでＤＮＮの計算範囲が異なっていてもよい。

【0236】

なお、ここでは、Early-exitingの判定を行ってからＤＮＮの計算を開始しているが、ＤＮＮの計算の途中でEarly-exitingの判定が行われてもよい。

【0237】

計算担当は、判定の結果に対応する相手に計算結果を送付する（Ｔ３０８）。Early-exitingを実行せず、かつ、次の計算担当が存在する場合、次の計算担当に計算結果を送付する。この場合、次の計算担当がＴ３０５からＴ３０８の処理を行う。なお、図２２のＴ３０８からＴ３０５に向かう矢印は、同じの計算担当がＴ３０５からＴ３０８の処理を再度行うことを示しているのではなく、別の計算担当がＴ３０５からＴ３０８の処理を行うことを意味する。次の計算担当が存在しない場合、言い換えれば、ＤＮＮの出力層まで計算が終了した場合と、Early-exitingを実行した場合と、は、計算担当は通信端末１１に計算結果を送付する。なお、計算結果以外に必要な情報を送信してもよい。例えば、計算担当が通信端末１１から判定に用いる情報を受信している場合は、当該情報を次の計算担当にも送信する。Early-exitingの判定に用いられる情報が、計算担当にバケツリレー方式で順番に送信されてもよい。

【0238】

通信端末１１は、ＤＮＮの計算結果を受信し（Ｔ３０９）、計算結果に基づくＭＬアプリケーションの処理を実行する（Ｔ３１０）。図２２の例のようにEarly-exitingを実行する場合では、ＤＮＮの一連の計算の終了を待たずに計算結果が通信端末１１に送信されるため、ＭＬアプリケーションの処理が遅延することを防ぐことができる。

【0239】

このように、Early-exitingの実施の有無によって、計算担当の計算結果の送付先が異なり、Early-exitingが行われた場合は、計算担当の計算結果が通信端末１１に送信される。ゆえに、Early-exitingの判定は、計算結果を通信端末１１に送信するか否かの判定とも言える。

【0240】

Early-exitingの別の例について説明する。Early-exitingに関するこれまでの説明では、ＤＮＮの一連の計算の途中の計算結果を通信端末１１に返信し、通信端末１１の待ち時間を減らすようにした。一方、計算担当の計算余力などが想定よりもなくなった場合には、担当範囲内の計算を切り上げ、残りの計算を次の計算担当に託すことも考えられる。次の計算担当のほうが高い計算余力を有する場合、そのようにすれば、最終的な通信端末１１の待ち時間を減らし得る。そこで、Early-exitingを行っても、計算結果が通信端末１１に送信されない場合を説明する。

【0241】

図２３は、Early-exitingに関する処理の流れの第２例を示した概略シーケンス図である。図２２の例では計算担当が担当範囲の全ての計算を実行する場合もEarly-exitingに含まれたが、図２３の例のEarly-exitingは、計算担当が担当範囲の全ての計算を実行する場合は含まれず、計算担当が担当範囲の計算を途中で終了することを意味する。

【0242】

なお、通信端末１１も担当範囲の計算を途中で終了することができる。そのため、図２３の例は、通信端末１１が第１計算担当である例を示している。また、図２３の例では、通信端末１１以外に、第２計算担当、第３計算担当、および最終計算担当（第４計算担当）がいる場合を示している。

【0243】

各計算担当は、論理エンティティからの判定条件を受信して設定する（Ｔ３０２）。その後、通信端末１１がＭＬアプリケーションを実行する（Ｔ３０３）。通信端末１１は、Early-exitingの判定に必要な情報を収集し、収集された情報を用いてEarly-exitingの判定を行う（Ｔ３０６）。そして判定結果に基づいてＤＮＮの計算を実行する（Ｔ３０７）。当該計算の範囲は、Early-exitingの実行する場合と実行しない場合とで異なり、判定結果や判定のタイミングによっては計算を実行しない場合があっても良い。換言するとT３０７の処理は必ずしも行われなくても良い。これは、本明細書におけるどの実施例においても同様である。通信端末１１は、Early-exitingの実行如何に関わらず、計算結果を次の計算担当である第２計算担当に送付する（Ｔ３０８）。なお、Early-exitingを行ったときに、次の計算担当が計算を開始する位置を認識するために当該位置を示す情報も次の計算担当に送信してもよい。当該情報は、例えば、通信端末１１の担当範囲の最後のレイヤを示す情報でもよいし、次の計算担当の担当範囲の最初のレイヤを示す情報でもよいし、計算結果を出力したノードを示す情報でもよいし、計算結果を入力すべきノードを示す情報でもよい。なお、途中終了する所定位置を次の計算担当が認識している場合は、当該位置まで計算を行い、計算結果を送信すれば、次の計算担当が計算を開始する位置を認識するための情報を送信する必要はない。

【0244】

第２計算担当は、通信端末１１の計算結果に関する情報の受信、Early-exitingの判定に必要な情報の収集、Early-exitingの判定、判定結果に基づくＤＮＮ計算の実行、次の計算担当である第３計算担当への送付を行う（Ｔ３０５からＴ３０８）。第３計算担当も同様にＴ３０５からＴ３０８の処理を行い、第３計算担当の計算結果が最終計算担当に送信される。

【0245】

最終計算担当も同様にＴ３０５からＴ３０７の処理を行うが、最終計算担当の次の計算担当が存在しないため、最終計算担当は、Early-exitingの実行如何に関わらず、計算結果を通信端末１１に送信する（Ｔ３１１）。通信端末１１は、図２２の例と同様、ＤＮＮの計算結果を受信し（Ｔ３０９）、計算結果に基づくＭＬアプリケーションの処理を実行する（Ｔ３１０）。このようにすれば、処理の遅延の要因となり得る計算担当の計算量を減らすことができ、図２２の例ほどではないが、通信端末１１の待ち時間を減らし得る。また、ＤＮＮの一連の計算が最終計算担当まで行われるため、例えば第２計算担当がＤＮＮの計算の途中終了の結果を送付した場合よりも、通信端末１１が受信する計算結果の精度は高くなり得る。

【0246】

また、Early-exitingの判定を各計算担当が行うのではなく、論理エンティティなどの特定のエンティティなどが決定する例の流れを説明する。図２４は、Early-exitingに関する処理の流れの第３例を示した概略シーケンス図である。図２４の例では、図２２の例に対し、論理エンティティがEarly-exitingの判定を行う点などが異なる。なお、計算担当を決定するエンティティと、Early-exitingの判定を行う決定するエンティティは異なっていてもよい。

【0247】

図２２の例と同様、論理エンティティがEarly-exitingの判定条件を計算担当に送信し（Ｔ３０１）、各計算担当が論理エンティティからの判定条件を受信して設定する（Ｔ３０２）が、当該判定条件は、図２４の例では、論理エンティティからEarly-exitingの実行指示を受信したか否かである。

【0248】

通信端末１１は、ＭＬアプリケーションを実行すると（Ｔ３０３）、ＤＮＮの計算を依頼することを論理エンティティに通知する（Ｔ３１２）。論理エンティティは、Early-exitingの判定に必要な情報を収集し、収集された情報を用いてEarly-exitingの判定を行う（Ｔ３０６）。論理エンティティの判定は定期的に繰り返される。例えば、論理エンティティが、計算余力、通信品質といった通信リソースを定期的に確認して、当該通信リソースに基づいて判定が行われてもよい。また、論理エンティティが、通信端末１１からの通知が行われてからの経過時間を計測し、通信端末１１から通知された上限値を超えているかを確認してもよい。また、通信端末１１は、図２２の例と同様、次の計算担当である第１計算担当に対し、ＤＮＮの計算に必要な情報を送信する（Ｔ３０４）。

【0249】

第１計算担当は、図２２の例と同様、Ｔ３０５からＴ３０８の処理を行う。図２４の例では、論理エンティティからEarly-exitingの実行指示を受信していないので、担当範囲の計算を実行し、計算結果を第２計算担当に送信する。

【0250】

図２４の例では、第１計算担当のＤＮＮの計算の間に、判定条件が満たされて、論理エンティティがEarly-exitingの実行を決定し、全ての計算担当に送信する（Ｔ３１４）。なお、図２４の例では、いずれの計算担当が計算中であるかを論理エンティティが認識していないため、全ての計算担当に送信するとしている。各計算担当が計算終了を論理エンティティに通知するなどによっていずれの計算担当が計算中であるかを論理エンティティが認識している場合は、次の計算担当だけに送信してもよい。

【0251】

第２計算担当は、第１計算担当の計算結果を受け取る前に、Early-exitingの実行通知を受信する（Ｔ３１５）。その後、第１計算担当の計算結果が送信されて、第２計算担当は、Ｔ３０５からＴ３０８の処理を行う。ゆえに、第２計算担当は、Early-exitingを行う場合の計算を実行し、実行された計算結果を通信端末１１に送信することになる。通信端末１１は、図２２の例同様、Ｔ３０９およびＴ３１０の処理を実行する。このように、論理エンティティがEarly-exitingの実行を判定し、論理エンティティからの実行通知を各計算担当のEarly-exitingの判定条件としてもよい。なお、Early-exitingの実行通知をＤＮＮの計算途中に受け取った場合、計算担当は、可能であれば、Early-exitingを行うとしてもよい。

【0252】

なお、Early-exitingを実行すると判定された場合、Early-exitingのための処理と並行して、Early-exitingを行わない場合の処理も継続して実行してもよい。すなわち、Early-exitingを実行した計算担当は、途中の計算結果を通信端末１１に送信するとともに、次の計算担当にも計算結果を送信してもよい。こうすると、通信端末１１は、ＤＮＮの途中までの計算結果を受信した後に、ＤＮＮの最終の計算結果も受信することができる。例えば、ＭＬアプリケーションの処理結果をＤＮＮ計算の途中結果から早く得られるようにし、その後、ＭＬアプリケーションの処理が正しかったかを、後から受信したＤＮＮの最終の計算結果に基づいて確認するといったことを行うことができる。その結果、計算精度の向上や計算時間の短縮に貢献しうる。以降、Early-exitingを行った場合でも、Early-exitingを行わなかった場合の計算も実行し、ＤＮＮの最終的な計算結果を通信端末１１に送信することをマルチフィードバックと記載する。

【0253】

なお、マルチフィードバックを行う場合に担当範囲の途中で計算を終了したときは、計算担当は、図２３の例で示したように、残りの計算を次の計算担当に依頼してもよいし、担当範囲の全ての計算を実行した上で、次の計算担当に計算結果を送信してもよい。

【0254】

マルチフィードバックを行うか否かは、通信端末１１から通知されてもよい。あるいは、Early-exitingを行った計算担当が論理エンティティにEarly-exitingを行ったことを通知し、論理エンティティは、当該通知を受けて、マルチフィードバックを行うか否かを、状況に応じて決定してもよい。マルチフィードバックの実行判定条件も、Early-exitingの実行判定条件と同様に、計算担当の計算余力、通リソース、ＭＬアプリケーションの要求仕様などに応じて、決定されてよい。

【0255】

また、Early-exitingを行った計算担当は、次の計算担当にEarly-exitingが行われたことを通知し、次の計算担当がEarly-exitingを行わないようにしてもよい。逆に、既にEarly-exitingが行われた場合であっても、次の計算担当もEarly-exitingを行ってもよい。ゆえに、通信端末１１は、複数のEarly-exitingによる計算結果と、ＤＮＮの最終の計算結果と、を受け取ることもあり得る。

【0256】

図２５は、マルチフィードバックを説明する概念図である。図２５の例では、通信端末と、第２から第４の計算担当がＤＮＮの計算を担当している。図２５の例では、第２計算担当がEarly-exitingを行っており、第２計算担当のEarly-exitingによる計算結果が通信端末１１に返信されていることが矢印で表されたフィードバックＦＤ１によって表されている。また、第２計算担当は、マルチフィードバックのために計算結果を第３計算担当に送信している。一方、第３計算担当もEarly-exitingを行っており、第３計算担当のEarly-exitingによる計算結果が通信端末１１に返信されていることがフィードバックＦＤ２によって表されている。また、第３計算担当も、マルチフィードバックのために計算結果を第４計算担当に送信している。図２５の例では、第４計算担当はＤＮＮの一連の計算の最後まで計算を行い、最終計算結果を通信端末１１に送信しいていることがフィードバックＦＤ３によって表されている。このように、通信端末１１は、複数のEarly-exitingによる計算結果（ＦＤ１とＦＤ２）と、ＤＮＮの最終の計算結果（ＦＤ３）と、を受け取ることがあり得る。

【0257】

なお、マルチフィードバックを行う場合は、Early-exitingが行われた後のＤＮＮの計算は、各計算担当が分担して計算を行うのではなく、特定のエンティティが計算を一局集中的に実行してもよい。例えば、図２５の例では、Early-exitingが行われた場合、第２計算担当および第３計算担当は計算を実行せず、第４通信担当が残りの計算を一括して行うとしてもよい。

【0258】

なお、Early-exitingが行われた場合、Early-exitingを行った計算担当、Early-exitingを行った理由、計算の終了位置など、Early-exitingの実行に関する情報が通信端末１１に送信されてもよい。また、マルチフィードバックを実行する場合は、論理エンティティなどが、実績、通信リソースなどに基づき、ＤＮＮの最終計算結果が通信端末１１に到達する時間を推定し、通信端末１１に通知してもよい。これにより、ＭＬアプリケーションは、Early-exitingの結果を受け取ったとしても、Early-exitingの結果を用いずに、ＤＮＮの最終計算結果を待つということもできる。

【0259】

また、Early-exitingを行った計算担当は、計算担当の変更を論理エンティティに要求してもよい。例えば、自身の計算余力に問題があるためにEarly-exitingを行った場合には、自身を計算担当から外すように要求してもよい。例えば、次の計算担当との通信品質に問題があるためにEarly-exitingを行った場合では、次の計算担当を変更するように要求してもよい。

【0260】

また、通信端末１１は、Early-exitingの実行可否の通知を論理エンティティ、各計算担当に行ってもよい。例えば、Early-exitingの実行を拒否する通知が通信端末１１から送信されている場合は、各計算担当はEarly-exitingの判定条件に従わずに、Early-exitingを行わないとしてもよい。また、マルチフィードバックの実行可否に関する通知を行ってもよい。また、マルチフィードバックを許可する場合、図２５で示したフィードバックの数の上限値などを指定してもよい。

【0261】

第２実施形態の各エンティティの内部構成は、第１実施形態同様でよいため省略する。Early-exitingを行わない場合の計算範囲と、Early-exitingを行う場合の計算範囲と、を各装置の記憶部（図１８の記憶部５２または図１９の記憶部１１２）に記憶しておき、各装置の制御部（図１８の制御部５３または図１９の制御部１１３）が用いる計算範囲を切り替え、各装置の演算部（図１８の演算部５４または図１９の演算部１１４）がＤＮＮの計算を実行すればよい。

【0262】

以上のように、本実施形態では、複数のエンティティがＤＮＮの一連の計算を分担して担当する分散学習を行う場合においてEarly-exitingを実行する。Early-exitingを実行することにより、通信遅延などが起きやすい通信ノードを用いた分散学習においても、ＤＮＮの計算結果が通信端末１１にフィードバックされる時間を所定時間内に抑えることが可能となる。また、計算担当の計算余力などが想定よりもなくなった場合には、担当範囲内の計算も途中で終了し、残りの計算を次の計算担当に託すこともできる。このようにして、ＤＮＮの一連の計算にかかる時間を抑えることもできる。

【0263】

なお、本開示の処理は、特定の規格に限定されるものではなく、例示された設定は、適宜に変更されてよい。なお、上述の実施形態は本開示を具現化するための一例を示したものであり、その他の様々な形態で本開示を実施することが可能である。例えば、本開示の要旨を逸脱しない範囲で、種々の変形、置換、省略またはこれらの組み合わせが可能である。そのような変形、置換、省略等を行った形態も、本開示の範囲に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

【0264】

また、本開示において説明された処理の手順は、これら一連の手順を有する方法として捉えてもよい。あるいは、これら一連の手順をコンピュータに実施させるためのプログラム、または、当該プログラムを記憶する記録媒体として捉えてもよい。また、上記で説明された論理エンティティおよび計算担当の処理は、コンピュータのＣＰＵ等のプロセッサによって実行される。また、記録媒体の種類は、本開示の実施形態に影響を及ぼすものではないため、特に限られるものではない。

【0265】

なお、本開示で示された、図１８から図２０で示された各構成要素は、ソフトウェアで実現されてもよいし、ハードウェアで実現されてもよい。例えば、各構成要素がマイクロプログラムなどのソフトウェアで実現されるソフトウェアモジュールであり、プロセッサが当該ソフトウェアモジュールを実行することにより、各構成要素が実現されてもよい。あるいは、各構成要素が、半導体チップ（ダイ）上の回路ブロック、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路によって実現されてもよい。また、構成要素の数と、構成要素を実現するハードウェアの数と、は一致していなくともよい。例えば、１つのプロセッサまたは回路が複数の構成要素を実現していてもよい。逆に、１つの構成要素が複数のプロセッサまたは回路により実現されていてもよい。

【0266】

なお、本開示で述べられたプロセッサは、その種類が限られるものではない。例えば、ＣＰＵ、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）などであってもよい。

【0267】

また、上記ではDNNにおける本開示の活用について記載したが、必ずしもこれに限定されない。例えばSNN（スパイキングニューラルネットワーク）等において同様の構成が用いられても良い。また、その際にDNNにおける活用とは違う課題を解決するために用いられても良い。上述したいずれかの情報の伝達にはスパイク信号を用いても良い。また、時系列データから因果関係を抽出し、その情報を基に上述したいずれかの判断を行っても良い。

【0268】

また、基地局装置５０の記憶部５２、通信端末１１の記憶部１１２など、データを記憶するための構成要素は、データ読み書き可能な装置によって実現されればよく、当該装置は適宜に選択されてよい。例えば、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスクなどであってよい。

【0269】

なお、本開示は以下のような構成を取ることもできる。
[１]
ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する情報処理装置であって、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行い、
前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第１範囲に続く第２範囲の計算担当である第２の通信装置に送信し、
前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信する、
情報処理装置。
[２]
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定されなかった場合には、前記第１範囲に含まれる計算の少なくとも一部を実行し、実行された計算の結果を、前記第２の通信装置に送信する前記計算の結果として用い、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合には、前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、実行された計算の結果を、前記第１の通信装置に送信するための前記計算に用いる、
[１]に記載の情報処理装置。
[３]
前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、
前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記判定の前に実行された前記計算の結果を前記第１の通信装置に送信するための前記計算に用いる、
[１]に記載の情報処理装置。
[４]
前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、
前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記判定の前に実行された前記計算の結果を前記第２の通信装置に送信する前記計算の結果として用いる、
[１]に記載の情報処理装置。
[５]
前記第１範囲に含まれる計算のうちの少なくとも一部を実行し、
前記判定が前記第１範囲に含まれる計算を実行している間に行われ、かつ、前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算を継続し、前記第１範囲の計算の結果を前記第２の通信装置に送信する前記計算の結果として用いる、
[１]ないし[４]のいずれか一項に記載の情報処理装置。
[６]
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、さらに、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第２の通信装置に送信する、
[１]ないし[５]のいずれか一項に記載の情報処理装置。
[７]
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算の全てが実行されなかったときは、実行された計算の結果とともに、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報を、前記第２の通信装置に送信する、
[６]に記載の情報処理装置。
[８]
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記一連の計算の少なくとも一部を実行可能な第３の通信装置に送信する、
[１]ないし[７]のいずれか一項に記載の情報処理装置。
[９]
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算の所定位置までを実行し、実行された計算の結果を、前記第１の通信装置に送信するための前記計算に用いる、
[１]ないし[７]のいずれか一項に記載の情報処理装置。
[１０]
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定された場合に、前記第１範囲に含まれる計算のいずれの位置まで実行するかを決定し、前記第１範囲に含まれる計算を決定された位置まで実行し、実行された計算の結果と、決定された位置を示す情報と、を前記第２の通信装置に送信する、
[１]ないし[７]のいずれか一項に記載の情報処理装置。
[１１]
前記ディープニューラルネットワークの一連の計算のうちの少なくとも一部を担当する装置の計算余力に関する情報、前記ディープニューラルネットワークの一連の計算のうちの少なくとも一部を担当する装置におけるトラフィック量に関する情報、のうちの少なくとも１つに基づいて前記判定を行う、
[１]ないし[１０]のいずれか一項に記載の情報処理装置。
[１２]
前記第１の通信装置との間の通信品質、前記第１の通信装置のモビリティ情報、のうちの少なくとも１つに基づいて前記判定を行う、
[１]ないし[１１]のいずれか一項に記載の情報処理装置。
[１３]
前記一連の計算を途中終了することを指示する情報、前記一連の計算における途中の計算の結果を前記第１の通信装置に送信することを指示する情報、のうちの少なくとも１つに基づいて前記判定を行う、
[１]ないし[１２]のいずれか一項に記載の情報処理装置。
[１４]
前記第１の通信装置から要求情報を取得し、前記要求情報に基づいて前記判定を行う、 [１]ないし[１３]のいずれか一項に記載の情報処理装置。
[１５]
前記第１範囲の計算に必要な時間が与えられた許容時間よりも大きい場合に、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を前記第１の通信装置に送信すると判定する、
[１]ないし[１４]のいずれか一項に記載の情報処理装置。
[１６]
ディープニューラルネットワークの一連の計算のうちの第１範囲に含まれる計算を途中終了するか否かの判定を行い、
前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第１範囲に続く第２範囲の計算担当である装置に送信する、
情報処理装置。
[１７]
前記第２範囲の計算担当である装置が前記第２範囲に含まれる計算を途中終了してもよいか否かを示す情報を、前記第２範囲の計算担当である装置にさらに送信する、
[１６]に記載の情報処理装置。
[１８]
ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する情報処理装置において実行される情報処理方法であって、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行うステップと、
前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第１範囲に続く第２範囲の計算担当である第２の通信装置に送信するステップと、
前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を用いて前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信するステップと、
を備える情報処理方法。
[１９]
ディープニューラルネットワークの一連の計算のうちの第１範囲に含まれる計算を途中終了するか否かの判定を行うステップと、
前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第１範囲に続く第２範囲の計算担当である装置に送信するステップと、
を備える情報処理方法。
[２０]
ディープニューラルネットワークの一連の計算のうちの一部の計算を担当する第１情報処理装置および第２情報処理装置を少なくとも備え、
前記第１情報処理装置は、
前記ディープニューラルネットワークの一連の計算における途中の計算の結果を、第１の通信装置に送信するか否かの判定を行い、
前記第１の通信装置に送信すると判定されなかった場合には、前記一連の計算のうちの第１範囲に含まれる計算の少なくとも一部の計算の結果を、前記第２情報処理装置に送信し、
前記第１の通信装置に送信すると判定された場合には、前記ディープニューラルネットワークの一連の計算における途中の計算の結果を用いて前記第１の通信装置に送信するための計算を実行し、実行された計算の結果を、前記第１の通信装置に送信し、
前記第２情報処理装置は、
前記一連の計算のうちの前記第１情報処理装置によって実行された計算以降の計算を前記第１情報処理装置によって実行された計算の結果に基づいて実行する、
情報処理システム。
[２１]
少なくとも、ディープニューラルネットワークの一連の計算のうちの第１範囲の計算を行う第１情報処理装置と、前記ディープニューラルネットワークの一連の計算のうちの前記第１範囲に続く第２範囲の計算を行う第２情報処理装置と、を備え、
前記第１情報処理装置は、
前記第１範囲に含まれる計算を途中終了するか否かの判定を行い、
前記第１範囲に含まれる計算を途中終了すると判定された場合に、前記第１範囲に含まれる計算の一部を実行し、実行された計算の結果と、実行された計算の結果が前記一連の計算のいずれの位置であるかを示す情報と、を、前記第２情報処理装置に送信し、
前記第２情報処理装置は、
前記情報を受け取ったときは、前記一連の計算の前記第１情報処理装置によって実行された計算の続きを、前記第１情報処理装置によって実行された計算の結果に基づいて実行する、
情報処理システム。
[２２]
前記第１範囲を決定する第３情報処理装置
をさらに備える[２０]に記載の情報処理システム。
[２３]
前記第１範囲に含まれる計算を途中終了するか否かの判定を行う第３情報処理装置
をさらに備え、
前記第３情報処理装置は、前記第１範囲に含まれる計算を途中終了する指示を前記第１情報処理装置に送信し、
前記第１情報処理装置は、前記指示を受け取った場合に、前記第１範囲に含まれる計算を途中終了すると判定する、
[２１]に記載の情報処理システム。

【符号の説明】

【0270】

１：情報処理システム、１１：通信端末、１１１：無線通信部、１１１０：送信処理部、１１１１：符号化部、１１１２：変調部、１１１３：多重部、１１１４：無線送信部、１１１５：受信処理部、１１１６：無線受信部、１１１７：多重分離部、１１１８：復調部、１１１９：復号部、１１２：記憶部、１１３：制御部、１１４：演算部、１１４１：条件設定部、１１４２：演算モデル設定部、１１４３：演算処理部、１１５：アンテナ、１２：クラウドシステム、１２１：クラウドサーバー、１３：通信ネットワーク、１３１：無線通信ノード、１３２：ドナーノード、１３３：コアネットワーク、１３３１：コアネットワークの通信ノード、１３４：ＲＡＮ、２：点線枠（ＤＮＮ）、２１：ＤＮＮのノード、２２：ＤＮＮのリンク、５０：基地局装置、５１：無線通信部、５１０：送信処理部、５１１：符号化部、５１２：変調部、５１３：多重部、５１４：無線送信部、５１５：受信処理部、５１６：無線受信部、５１７：多重分離部、５１８：復調部、５１９：復号部、５２：記憶部、５３：制御部、５４：演算部、５５：ネットワーク通信部、５６：アンテナ、６０１：ＡＭＦ、６０２：ＮＥＦ、６０３：ＮＲＦ、６０４：ＮＳＳＦ、６０５：ＰＣＦ、６０６：ＳＭＦ、６０７：ＵＤＭ、６０８：ＡＦ、６０９：ＡＵＳＦ、６１０：ＵＣＭＦ、６３０：ＵＰＦ、６４０：ＤＮ、７１・７２・７３：計算フロー、ＦＤ１・ＦＤ２・ＦＤ３：フィードバック、

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】