特許 7605306 通信スケジュール割当装置、通信スケジュール割当方法及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-12-16

(45)【発行日】2024-12-24

(54)【発明の名称】通信スケジュール割当装置、通信スケジュール割当方法及びプログラム

(51)【国際特許分類】

   H04L 47/78 20220101AFI20241217BHJP

   H04J 14/02 20060101ALI20241217BHJP

【ＦＩ】

H04L47/78

H04J14/02

【請求項の数】 6

(21)【出願番号】P 2023526688

(86)(22)【出願日】2021-06-08

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

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

(87)【国際公開日】2022-12-15

【審査請求日】2023-12-01

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】東 信博

(72)【発明者】

【氏名】木津 貴秀

(72)【発明者】

【氏名】岩澤 宏紀

(72)【発明者】

【氏名】益谷 仁士

(72)【発明者】

【氏名】桑原 健

【審査官】漆原 孝治

(56)【参考文献】

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

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

Ｈ０４Ｌ ４７／７８

Ｈ０４Ｊ １４／０２

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

【請求項1】

複数のテナントと光ネットワークを介した光波長多重通信を行う１以上のノードを制御する通信スケジュール割当装置であって、
前記テナントごとに異なる波長を割り当てるための制御を行う制御部と、
或るテナントに対応するアプリケーションによるデータの送信周期及び各送信タイミングに必要な送信時間から構成される通信スケジュールを、当該テナントに対する１以上の波長のうち当該通信スケジュールを割り当て可能な波長に対して割り当てる割当部と、
を有し、
前記割当部は、波長ごとに管理されている、当該波長に対して割り当て済みの通信スケジュールを示す情報に基づいて、前記アプリケーションによる通信スケジュールを割り当て可能な波長を判定する、
ことを特徴とする通信スケジュール割当装置。

【請求項2】

前記割当部は、前記アプリケーションのデプロイ時に、当該アプリケーションに係る前記テナントに対して波長が割り当てられていなければ、既に割り当て済みの波長とは異なる波長を当該テナントに対して割り当てる、
ことを特徴とする請求項１記載の通信スケジュール割当装置。

【請求項3】

前記割当部は、前記アプリケーションのデプロイ時に、当該アプリケーションに係る前記テナントに対して波長が割り当てられている場合に、当該波長に対して割り当てられている通信スケジュールに、当該アプリケーションが要求する通信スケジュールを割り当てる空きが無い場合には、既に割り当て済みの波長とは異なる波長を当該テナントに対して割り当てる、
ことを特徴とする請求項２記載の通信スケジュール割当装置。

【請求項4】

前記割当部は、前記アプリケーションのデプロイ時に、当該アプリケーションに係る前記テナントに対して波長が割り当てられている場合に、前記ノードのうち、前記アプリケーションが要求する計算機リソースを満足することができるノードを前記アプリケーションのデプロイ先のノードとして選択する、
ことを特徴とする請求項２又は３記載の通信スケジュール割当装置。

【請求項5】

複数のテナントと光ネットワークを介した光波長多重通信を行う１以上のノードを制御する通信スケジュール割当装置が、
前記テナントごとに異なる波長を割り当てるための制御を行う制御部手順と、
或るテナントに対応するアプリケーションによるデータの送信周期及び各送信タイミングに必要な送信時間から構成される通信スケジュールを、当該テナントに対する１以上の波長のうち当該通信スケジュールを割り当て可能な波長に対して割り当てる割当手順と、
を実行し、
前記割当手順は、波長ごとに管理されている、当該波長に対して割り当て済みの通信スケジュールを示す情報に基づいて、前記アプリケーションによる通信スケジュールを割り当て可能な波長を判定する、
ことを特徴とする通信スケジュール割当方法。

【請求項6】

請求項１乃至４いずれか一項記載の通信スケジュール割当装置としてコンピュータを機能させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信スケジュール割当装置、通信スケジュール割当方法及びプログラムに関する。

【背景技術】

【0002】

産業用インターネットで用いられる技術の一つにＴＳＮ（Time-SensitiveNetworking）がある。ＴＳＮは、リアルタイム性の求められる工場内産業機械等の制御をＥｔｈｅｒｎｅｔ（登録商標）上で実現するため、制御通信のリアルタイム性、すなわち、低遅延・低ｊｉｔｔｅｒ、かつ、定められた最悪通信時間よりも前に通信が受信側に到達することを保証するための各種規格の総称である。

【0003】

ＴＳＮの代表的な実現例として、ノード間の厳密な（ナノ秒オーダの）時刻同期を実現するＩＥＥＥ８０２．１ＡＳと、Ｅｔｈｅｒｎｅｔ（登録商標）フレームの送信可能タイミングをマイクロ秒オーダの粒度で制御するＩＥＥＥ８０２．１Ｑｂｖの組み合わせが挙げられる。

【0004】

ＩＥＥＥ８０２．１Ｑｂｖでは、Ｅｔｈｅｒｎｅｔ（登録商標）ドメインを構成するすべてのスイッチがＧＣＬ（Gate Control List）とよばれる送信スケジュールを共有し、ＧＣＬに基づき厳格な送信タイミング制御を実施する。具体的には、図１に示すように、各スイッチは、それぞれのゲートに対応する送信キューを用意し、フレームを優先度別に異なるキューに追加する。ＩＥＥＥ８０２．１Ｑｂｖでは特定のタイミングでどのゲートを開放するか、すなわち、どのキューからフレームを送信するかを制御することで、他に優先度の低いフレームが混在する状況においても、優先度の高いフレームの確実な送信を実現する。

【0005】

それぞれのスイッチは、ＩＥＥＥ８０２．１ＡＳにより厳密に同期された時刻をベースに、このゲート開閉制御を実施することで、Ｅｔｈｅｒｎｅｔ（登録商標）ドメインにおける優先フレームの確実な送信を実現する。これにより、フレームが宛先に到着するまでの最悪通信時間を確定することができる。このようなタイミング制御が行われない場合、優先フレームの送信タイミングは他の低優先フレームの送信待ち等の要因で揺らぐ可能性がある。これは最悪通信時間よりも前のフレーム到着を保証できないことを意味する。

【0006】

これらの方式により、ＴＳＮは、工場などの産業用途においてリアルタイム性が求められる産業機械等のＯＴ（Operational Technology）ドメインとＰＣ等一般のＩＴ（Information Technology）ドメインの同一ネットワーク内での共存・統合を実現する。

【0007】

また、近年の５Ｇ等に代表される情報通信技術の進展に伴い、低遅延性の求められるアプリケーションを（端末と同じ場所ではなく）クラウド側のデータセンタ（Data Center；以下「ＤＣ」という。）で収容するアプローチが検討されている。クラウド側でアプリケーションを収容する利点として、スケーラビリティ、簡易な構築・更新が可能、管理が容易であること、利用量に応じた課金、クラウドが提供する部品の活用、他システムとの連携の容易性、などが挙げられる。その中でも特に低遅延性が求められるアプリケーションについては、伝送距離に起因する遅延を最小化する、あるいはセキュリティ上の要請（インターネット経由は避けたい）等の理由から、通信キャリアネットワーク内の端末近傍に構築されたＤＣ（以下、「エッジＤＣ」という。）へ収容する、エッジコンピューティングが検討されている。

【0008】

ＤＣにおけるアプリケーション収容の一般的な形態として、Ｋｕｂｅｒｎｅｔｅｓ等のコンテナオーケストレーションプラットフォーム上でコンテナ化したアプリケーションを実行することが挙げられる。このように同一ＤＣ内で複数のユーザ（テナント）が各種サーバ・ＮＷリソースを共有するマルチテナントな形態をとることで、リソース共用による設備コストの削減、利用料金低減などのメリットが得られる。ＴＳＮアプリケーションをエッジＤＣで収容するイメージを図２に示す。図２では、複数の異なるテナントのアプリケーションが同一データセンタ内に収容され、それぞれのテナントが有するローカルネットワーク内の端末と通信を行う。

【0009】

工場における産業機械制御等のリアルタイム性が求められる制御アプリケーションをエッジＤＣで収容するためには、これまでのように近傍（工場内等）に閉じられていたＴＳＮドメインを広域に拡張し、端末－エッジＤＣにわたる全ての区間に対してＴＳＮを適用する必要がある。さらに複数のテナントのアプリケーションを収容することも求められる。

【先行技術文献】

【非特許文献】

【0010】

【文献】IETF101, "DetNet WG Overview"、［online］、＜ＵＲＬ：https://datatracker.ietf.org/meeting/101/materials/slides-101-rtgarea-deterministic-networking-detnet-00＞

【文献】"Kubernetes Topology Manager Moves to Beta - Align Up! - Kubernetes"、［online］、＜ＵＲＬ：https://kubernetes.io/blog/2020/04/01/kubernetes-1-18-feature-topoloy-manager-beta/＞

【発明の概要】

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

【0011】

従来のＴＳＮは、あくまでも工場内などの地理的に閉じたＥｔｈｅｒｎｅｔ（登録商標）ネットワークに対しての適用を想定したものであり、上記で述べたようなエッジＤＣでのアプリケーション収容を実現するためには、ＴＳＮドメインの広域化、マルチテナント対応、コンテナ対応等の課題を解決する必要がある。

【0012】

１つ目の広域化について、ｓｔｒａｉｇｈｔｆｏｒｗａｒｄな方式としては、Ｅｔｈｅｒｎｅｔ（登録商標）ドメインを端末が所属するローカルネットワークとエッジＤＣの間まで拡張し、全てを一つのＬ２ネットワークとしてＴＳＮ化することが考えられるが、これはスケーラビリティ、コスト、セキュリティ等の観点から現実的ではない。

【0013】

リアルタイム性が求められるアプリケーションに対する広域なネットワークパスの提供を目的として、ＩＥＴＦ（Internet Engineering Task Force）のＤｅｔＮｅｔ ＷＧ（Deterministic Networking Working Group）において関連技術の標準化が進められている（非特許文献１）。ＤｅｔＮｅｔは、Ｌａｙｅｒ２のＢｒｉｄｇｅ並びにＬａｙｅｒ３のＲｏｕｔｉｎｇセグメントも含め、遅延、ｊｉｔｔｅｒ、パケットロス等の上限値が規定されたパス（「ｄｅｔｅｒｍｉｎｉｓｔｉｃ ｐａｔｈ」と呼称）の実現を目指しており、特に、Ｌａｙｅｒ３の観点で、ｄｅｔｅｒｍｉｎｉｓｔｉｃなネットワークを必要とするアプリケーションをどのようにサポートするかについて検討している。ＤｅｔＮｅｔでは、ＴＳＮ等のＬａｙｅｒ２技術との連携を前提としており、例えば、時刻同期はＴＳＮと同様にＩＥＥＥ８０２．１ＡＳを利用することが想定されている。また、最悪応答時間を保証するためのＬａｙｅｒ３の新たな技術は特段規定されておらず、ＴＳＮのＩＥＥＥ８０２．１Ｑｂｖ等の既存Ｌａｙｅｒ２技術を適切に利用することとしている。

【0014】

つまり、ＤｅｔＮｅｔにおけるネットワークパスの広域化のためには、経由する全てのネットワークに、ＴＳＮのような遅延保証の仕組みが具備されている必要がある。これはネットワークにとって大きな負担となる。

【0015】

２つ目のマルチテナント対応のためには、複数の異なるテナントが所望する送信スケジュールをすべて満足する送信制御を行う必要がある。これを実現するためには、送信スケジュールの送信スロットがバッティングしないよう、各テナントのアプリケーションの送信スロットを確保する必要がある。送信スケジュールに設定可能な送信スロット数には上限があり、これらがすべて使用されてしまった時点でそれ以上の追加は不可能となる。

【0016】

送信スロットを一つのアプリケーションで専有するのではなく、共有可能な送信スロットを設け、複数のテナント、アプリケーションでこれを共用することで、送信スロットの消費量を低減することも考えられるが、この場合、適切な制御が行われない限り、当該スロットでの確実な送信は担保できない。

【0017】

これは、リアルタイム性が求められるアプリケーションにおいては許容し難い。

【0018】

送信スケジュールの上限を増やすためには、送信スケジュールの分だけ、Ｌ２ドメインを物理的に分割する必要がある（ＶＬＡＮ等の論理的な分割では、物理レイヤで電気信号が衝突し、ｊｉｔｔｅｒが発生するため不十分である）。物理的な分割のためにはケーブルを分け、ローカルネットワーク側まで配線する必要がある。これは非常に煩雑である。

【0019】

３つ目のコンテナ化されたアプリケーションへのＴＳＮの適用については、コンテナをどの物理ノードに配置するかのスケジューリング、ＴＳＮのスロット割当、コンテナへの送信タイムスロット割当が課題となる。

【0020】

一般に、コンテナオーケストレータは、運用者あるいは開発者より入力されるコンテナ構成・設定情報（例えば、Ｋｕｂｅｒｎｅｔｅｓではｍａｎｉｆｅｓｔファイルと呼ばれる）をもとに、コンテナを配置すべき物理ノードを決定する。これをスケジューリングと呼ぶ。コンテナ構成・設定情報にはアプリケーションの実行に必要となるＣＰＵやメモリなどのコンピューティングリソース情報を記載することができ、コンテナオーケストレータはこの内容をもとに、リソース割当が可能なノードに対してコンテナを割り当てる。コンテナ構成・設定情報の記述内容に応じて、オーケストレータはアプリケーションに割り当てる優先度クラスを分けることができる。オーケストレータの設定によっては高優先度クラスのアプリケーションに対して、ＣＰＵを専有割り当てすることも可能である。更には、単純にＣＰＵを割り当てるのではなく、コンピュータ内部のトポロジを意識して、アクセス時間が最短化されるよう、同一のＮＵＭＡ（Non-Uni.ed Memory Access）ｎｏｄｅ上のＣＰＵやＮＩＣ等を割り当てることも可能となっている（非特許文献２）。

【0021】

しかし、ＴＳＮアプリケーションのようなリアルタイム性の求められるアプリケーションを収容する場合は、上記のコンピューティングレイヤにおけるリソースの専有割当に加えて、ＴＳＮ送信スロット割当などの手法により実現される、ネットワークレイヤにおける外乱要素の排除もあわせて必要となる。

【0022】

このようなネットワークレイヤの送信タイミングのスケジューリングは、一般的にはオーケストレータで取り扱われておらず、オーケストレータとは別の手段により事前設定される必要がある。コンピューティングリソースの設定とネットワーク送信リソースの設定を毎回別々に実施するのはアプリケーション開発者・運用者にとって大きな負担であり、一気通貫に実施できることが望ましい。

【0023】

本発明は、上記の点に鑑みてなされたものであって、リアルタイム性が求められるアプリケーションのマルチテナント化及び広域化を実現可能とすることを目的とする。

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

【0024】

そこで上記課題を解決するため、複数のテナントと光ネットワークを介した光波長多重通信を行う１以上のノードを制御する通信スケジュール割当装置であって、前記テナントごとに異なる波長を割り当てるための制御を行う制御部と、或るテナントに対応するアプリケーションによるデータの送信周期及び各送信タイミングに必要な送信時間から構成される通信スケジュールを、当該テナントに対する１以上の波長のうち当該通信スケジュールを割り当て可能な波長に対して割り当てる割当部と、を有し、前記割当部は、波長ごとに管理されている、当該波長に対して割り当て済みの通信スケジュールを示す情報に基づいて、前記アプリケーションによる通信スケジュールを割り当て可能な波長を判定する。

【発明の効果】

【0025】

リアルタイム性が求められるアプリケーションのマルチテナント化及び広域化を実現可能とすることができる。

【図面の簡単な説明】

【0026】

【図1】ＴＳＮにおけるＴｉｍｅ－Ａｗａｒｅ Ｓｈａｐｉｎｇの例を示す図である。

【図2】エッジＤＣにおけるＴＳＮアプリケーションの収容イメージを示す図である。

【図3】本実施の形態の機能構成例を示す図である。

【図4】フレーム送受信機能部２２及び光変換機能部２３のポートマッピング例を示す図である。

【図5】ノード情報登録処理の処理手順の一例を説明するためのシーケンス図である。

【図6】光パス確立処理の処理手順の一例を説明するためのシーケンス図である。

【図7】デプロイ先ノードの選択処理の処理手順の一例を説明するためのフローチャートである。

【図8】アプリケーションのデプロイ処理の処理手順の一例を説明するためのシーケンス図である。

【図9】接続構成による分類を説明するための図である。

【図10】ＮＵＭＡトポロジを意識したポート切り替えを示す図である。

【図11】ＰＯＮ方式における送信スケジュール割当例を示す図である。

【図12】波長・テナント・アプリの組み合わせによる分類

【図13】実施例４における機能構成例を示す図である。

【図14】実施例４におけるノード情報登録処理の処理手順の一例を説明するためのシーケンス図である。

【図15】実施例４における光パス確立処理の処理手順の一例を説明するためのシーケンス図である。

【図16】実施例４におけるアプリケーションのデプロイ処理の処理手順の一例を説明するためのシーケンス図である。

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

【0027】

本実施の形態では、テナント毎に異なるＴＳＮ送信スケジュール（通信スケジュール）を設け、それぞれを別々の波長の波にマッピングさせ、アプリケーションを収容するデータセンタ（Data Center；以下「ＤＣ」という。）とテナントのローカルゲートウェイ（ローカルＧＷ）の間を光伝送する。光を用いることで、最小限の遅延・ゆらぎで長距離伝送を行う。テナントごとに波長分離することで、他のテナントの通信の影響を排除する。また、光波長多重（Wavelength Division Multiplexing：ＷＤＭ）を利用することで、複数のＴＳＮ送信スケジュールの伝送に必要なケーブル数を削減する。更に、波（＝送信スケジュール）とテナント情報をマッピングし、送信スロットの利用状況とあわせて管理することで、コンテナオーケストレータによる適切なノード割当並びにネットワークレイヤでの設定実施も実現する。

【0028】

以下、図面に基づいて本発明の実施の形態を説明する。図３は、本実施の形態の機能構成例を示す図である。図３に示されるように、ＤＣ内には、クラスタを構成する各ノード２０として機能する複数のコンピュータと（図３にはそのうちの一つが図示されている）と、オーケストレータ１０として機能するコンピュータとを含む。各ノード２０とオーケストレータ１０とは、ＤＣ内のローカルネットワークを介して接続される。各ノード２０は、ＴＳＮアプリケーションを収容する。ＴＳＮアプリケーションとは、ＴＳＮ（Time-SensitiveNetworking）による確定時間通信が求められる、リアルタイムアプリケーションをいう。ＴＳＮアプリケーションの一例として、ロボットアームの制御アプリケーション等が挙げられる。以下、特段の断りが無い限り、ＴＳＮアプリケーションを、単に「アプリケーション」という。

【0029】

一方、ＤＣを利用するテナントは、１以上のＴＳＮ端末４０とローカルＧＷ３０とがテナント内のローカルネットワークを介して接続される。ＴＳＮ端末４０は、アプリケーションの対向先となる端末であり、ＴＳＮにより優先制御された通信をネットワークＮ１及びローカルＧＷ３０を経由して受信する。例えば、アプリケーションがロボットアームの制御アプリケーションであれば、ＴＳＮ端末４０の一例は、ロボットアームである。

【0030】

ＤＣ内の各ノード２０と各テナントのローカルＧＷ３０とは、光ネットワークＮ１を介して接続される。すなわち、光ネットワークＮ１は、複数のテナントとの通信に共用される。光ネットワークＮ１は、光スイッチ等の任意にパスを切り替え可能な装置により構成される光の伝送ネットワークである。ノード２０と光ネットワークＮ１の間（より具体的には、例えば、ノード２０の光波長多重機能部２４と光ネットワークＮ１内の光スイッチとの間）は光ファイバで物理的に接続されており、光ネットワークＮ１側の設定（パス構成、波長設定）により、いつでもこの光ネットワークＮ１を利用可能であることを前提とする。なお、動的な光パス設定が不要な場合は、ノード２０とローカルＧＷ３０の間のパスを固定設定、又は直結（いわゆるＳｉｎｇｌｅ Ｓｔａｒ構成）してもよい。

【0031】

光ネットワークＮ１は、ネットワーク制御機能部５０として機能する装置（コンピュータ）を含む。ネットワーク制御機能部５０は、アプリケーションを収容するクラスタとローカルネットワークの間における光パスの動的な確立の役割を担う（事前の手動設定などで静的に確立する場合は不要）。クラスタ制御機能部１１の指示、又は手動での指示により、光パスが確立される。具体的には、ネットワーク制御機能部５０は、光パスの確立に必要な情報としてノード識別子及びテナント識別子を受け取り、利用可能な波長を用いてノード２０、テナント間で光パスの確立を光ネットワークＮ１に指示する。確立後、確立した光パスの情報（利用する波長も含む）を返却する。

【0032】

図３において、ノード２０は、アプリケーション収容機能部２１、フレーム送受信機能部２２、光変換機能部２３、光波長多重機能部２４、ノード制御機能部２５及び時刻同期機能部２６を含む。これらのうち、フレーム送受信機能部２２、光変換機能部２３、光波長多重機能部２４は、ハードウェアである。例えば、フレーム送受信機能部２２は、ＮＩＣ（Network Interface Card）であり、光変換機能部２３は、電気・光変換装置であり、光波長多重機能部２４は、ＷＤＭ（Wavelength Division Multiplexing）装置である。一方、アプリケーション収容機能部２１、ノード制御機能部２５及び時刻同期機能部２６は、ノード２０にインストールされた１以上のプログラムがノード２０のＣＰＵに実行させる処理により実現される。

【0033】

オーケストレータ１０は、クラスタ制御機能部１１を有する。クラスタ制御機能部１１は、オーケストレータ１０にインストールされた１以上のプログラムがオーケストレータ１０のＣＰＵに実行させる処理により実現される。オーケストレータ１０は、また、光パス情報管理機能部１１１及び送信スケジュール情報管理機能部１１２を有する。これら各管理機能部は、例えば、オーケストレータ１０の補助記憶装置を用いて情報を記憶及び管理するデータベースである。

【0034】

ローカルＧＷ３０は、フレーム送受信機能部３１、光変換機能部３２、光波長多重機能部３３及び時刻同期機能部３４を有する。これらのうち、フレーム送受信機能部３１、光変換機能部３２、及び光波長多重機能部３３は、ノード２０における同名の各機能部と同様のハードウェアである。一方、時刻同期機能部３４は。ローカルＧＷ３０にインストールされた１以上のプログラムがローカルＧＷ３０のＣＰＵに実行させる処理により実現される。

【0035】

各機能部の詳細について説明する。

【0036】

［アプリケーション収容機能部２１］
アプリケーション収容機能部２１は、複数のテナントのそれぞれに対応する複数のアプリケーションを収容する。

【0037】

［フレーム送受信機能部２２］
フレーム送受信機能部２２は、同一テナントに属するアプリケーションの通信を集約し、テナントごとに独立した送信スケジュールに従いフレームの送信制御を実施する。フレーム送受信機能部２２は、複数の物理的な送受信用ポートを具備しており、それぞれが独立に光変換機能部２３と接続されている（詳細は図４参照）。異なるテナント（＝異なるＴＳＮ送信スケジュール）に紐づくそれぞれのアプリケーションの通信は、別々のポートを利用して、物理的に分離された状態で光変換機能部２３に送信される。

【0038】

図４は、フレーム送受信機能部２２及び光変換機能部２３のポートマッピング例を示す図である。図４では、フレーム送受信機能部２２から光変換機能部２３に対して電気信号線が接続されているが、フレーム送受信機能部２２が直接光信号を送出する場合も考えられる（この場合、フレーム送受信機能部２２と光変換機能部２３が一体化される）。

【0039】

［光変換機能部２３］
光変換機能部２３は、フレーム送受信機能部２２から入力されるフレームを光信号に変換する部分である。光変換機能部２３は、ノード制御機能部２５から通知されるテナント情報（フレーム変換機能部のポート識別子と波長）をもとに、フレーム送受信機能部２２のポートと利用する波長のマッピングを行う。

【0040】

［光波長多重機能部２４］
光波長多重機能部２４は、それぞれのテナントの送信スケジュールに紐づく波長の波について光波長多重通信を行う。

【0041】

［ローカルＧＷ３０］
ローカルＧＷ３０は、テナント側のローカルネットワークのゲートウェイとして機能し、アプリケーションからの通信を仲介し、送信スケジュールに従いローカルネットワーク側にフレームを送出する。

【0042】

なお、図３では、ローカルＧＷ３０が光変換機能部３２及び光波長多重機能部３３を含む構成が例示されているが、ローカルＧＷ３０の外側にこれらの機能部を配置し、ローカルＧＷ３０は通常のＴＳＮブリッジとされてもよい。

【0043】

［時刻同期機能部２６］
時刻同期機能部２６は、時刻同期機能部３４との間で、ＩＥＥＥ８０２．１ＡＳ等による精緻な時刻同期を実施する。ここで同期された時刻をもとに、フレーム送受信機能部２２は厳密なゲート開閉制御を実施する。

【0044】

［ノード制御機能部２５］
ノード制御機能部２５は、アプリケーション収容機能部２１に対してアプリケーションのデプロイを指示する。また、フレーム送受信機能部２２のポートに対してアプリケーションの送信スケジュールを割り当てる。ノード制御機能部２５は、また、光変換機能部２３に対してフレーム送受信機能部２２のポート情報に対応する波長情報を通知する。

【0045】

［光パス情報管理機能部１１１］
光パス情報管理機能部１１１は各ノード２０におけるポート、波長、テナントのマッピング情報（表１）を管理する。

【0046】

【表1】

表１の各行が、一つの送信スケジュールに対応する（但し、送信スケジュール情報それ自体は、次に示す送信スケジュール管理機能部で管理される）。

【0047】

なお、ここで、ローカルＧＷ３０側までの伝搬距離が既知である場合はその情報を、光パス情報管理機能部１１１又は次に述べる送信スケジュール情報管理機能部１１２に保存しても良い。光の伝搬遅延は、１［ｋｍ］あたりおよそ５［μｓ］と言われており、長距離伝送時にはＤＣ側の送信タイムスケジュールと、ローカルＧＷ３０側の送信タイムスケジュールの間にずれが生じる。そのため、例えば、１０［ｋｍ］離れている場合は、ＤＣ側の送信タイムスケジュールを１０［ｋｍ］×５［μ／ｋｍ］＝５０［μｓ］分前倒しすることで、伝搬遅延による発側・着側の送信スケジュールのずれを補正することが有効である。

【0048】

［送信スケジュール情報管理機能部１１２］
送信スケジュール情報管理機能部１１２は、送信スケジュールごとに（表１の行ごとに）、表２に示すような送信スロット割当状況（割り当てられた送信スロットとアプリとの対応付け）を保持する。すなわち、表１の１行に対して１つの表２が対応する。

【0049】

【表2】

アプリ識別子はその送信スロットにおいて送信可能なアプリの識別子が記載される。アプリ識別子は複数指定可能である。また、他のノード２０やローカル側で専有されるため利用不可となるものや、逆に、全てのアプリで利用可能なスロット（＝ベストエフォートなスロット）を指定することもできる。なお、送信スロットとは、図１に示されているように、或る時間区間を示す。ＴＳＮを構成する標準仕様の一つであるＩＥＥＥ８０２．１Ｑｂｖにおいては、周期的に、或る区切られた時間ごとに、どの送信ゲートを開けるかを制御している。この、"或る区切られた時間"のことを送信スロットという。

【0050】

表２の例では、通信の周期のうち、最初の１００μｓの間（送信スロット）は利用できず、１００μｓ－１２０μｓの間（送信スロット）は、アプリ識別子がａｐｐ２であるアプリケーションが使用でき、１８０μｓ－２００μｓの間（送信スロット）は、アプリ識別子がａｐｐ３であるアプリケーションが使用できること等を示す。

【0051】

送信スケジュール情報管理機能部１１２は、また、上記の情報の他に、送信スケジュールの開始時刻（ｂａｓｅ ｔｉｍｅと呼ばれる）を格納する。これらの情報を利用することで、アプリケーションは次に自身がフレームを送出すべき時刻を知ることが出来る。

【0052】

［クラスタ制御機能部１１］
クラスタ制御機能部１１は、複数のノード２０で構成されるクラスタ全体の各種制御を行う（Ｋｕｂｅｒｎｅｔｅｓにおけるｍａｓｔｅｒ ｎｏｄｅに相当）。本実施の形態において、クラスタ制御機能部１１は、特に、アプリケーションのデプロイ時に提供される各種情報（要求リソース情報、送信周期情報）に基づき、アプリケーションのデプロイ先となるノード２０を選択する役割を担う。

【0053】

要求リソース情報の例として、アプリケーションが必要とするＣＰＵコア及びメモリ量（例：ＣＰＵ２コア、メモリ２ＧＢ）等が挙げられる。

【0054】

送信周期情報は、アプリケーションの通信のスケジュールを示す情報の一例であり、例えば、送信周期１［ｍｓ］，送信時間５０［μｓ］等のように、アプリケーションがどの程度の頻度で、それぞれどの程度の時間においてフレームを送信するかを示す。

【0055】

クラスタ制御機能部１１は、上記の要求リソース情報、送信周期情報を満足するノード２０を選択する。選択されたノード２０のノード制御機能部２５によってアプリケーションのデプロイ及びＴＳＮ設定が行われる。

【0056】

次に、基本的な実施手順について述べる。実施手順は、事前準備フェーズにおけるノード情報登録、光パス確立、並びに運用フェーズにおけるアプリケーションデプロイ時のノード２０の選択及びＴＳＮ設定実施手順から構成される。

【0057】

一般的なアプリケーション（ＴＳＮアプリケーションに該当しないアプリケーション）のデプロイにおける基本的なデプロイ先ノードの選定基準は、アプリケーションが必要とする計算機リソースを提供可能であることである。ＴＳＮアプリケーションではこれに加え、ＴＳＮアプリケーションとして必要な送信スケジュールを提供可能であることが求められる。つまり、計算機リソース及び光ネットワークＮ１リソースの両方を満たすようなノード２０にアプリケーションをデプロイできるよう、後述する手順の通り、これら両方のリソースを考慮したノード２０の選択を行う必要がある。

【0058】

なお、前提として、ネットワーク制御機能部５０は、ローカルネットワーク及びテナントについての情報（テナント識別子等）を保持している、又はこれらの情報は光ネットワークＮ１側で問い合わせ／解決可能であるものとする。

【0059】

［ノード情報登録］
図５は、ノード情報登録処理の処理手順の一例を説明するためのシーケンス図である。

【0060】

クラスタを構成する各ノード２０のノード制御機能部２５又は運用者は、当該ノード２０が保持するフレーム送受信機能部２２／光変換機能部２３のポートの情報（ノード識別子及びポート識別子）をクラスタ制御機能部１１に登録する（Ｓ１０１）。クラスタ制御機能部１１は、当該ポート情報を光パス情報管理機能部１１１へ保存する（Ｓ１０２）。光パス情報管理機能部１１１に保存されるポート情報の構成は、表１に示すようなイメージであるが、現時点（＝光パス確立前）では、波長、テナント識別子の欄は空欄となる。なお、図５の処理手順は、各ノード２０のポートごとに実行されてもよいし、ノード２０ごとに実行されてもよい。後者の場合、当該ノード２０に属する全てのポートのポート識別子がステップＳ１０１において指定され、ステップＳ１０２において光パス情報管理機能部１１１へ保存される。

【0061】

［光パス確立］
光パスの確立は、事前準備の際、又は後述するアプリケーションデプロイ時に動的に実施される。どちらの場合も、ローカルＧＷ３０の光変換機能部３２とノード２０の光変換機能部２３との間で、光パスを自動又は手動で設定する（このとき、他と重複しない、未利用の波長の波が選択される。）。

【0062】

アプリケーションデプロイ時にパス確立先として選定されるノード２０は、少なくとも以下の条件を満たす必要がある。
（１）ポートに空きがあること。
（２）アプリケーションに必要な、十分な計算機リソース（ＣＰＵ／メモリ等）を提供可能なこと。

【0063】

アプリケーションのデプロイをトリガとしたノード２０の選択時には、アプリケーションが要求する以上のノード２０リソースを提供可能なノード２０を選定する必要がある。同条件のノード２０が複数ある場合は、その中から任意の選択基準（ランダム／最もリソースに余裕があるノード２０が優先、等）により選択する。

【0064】

一方、事前準備の際において、デプロイされるアプリケーションは未知である（デプロイされるアプリケーションは特定されている必要は無い）ため、上記（１）及び（２）の条件は無視される。事前準備の際にはいずれかのノード２０にパスだけ先に張っておき、後段のアプリデプロイ時に、もし、当該ノード２０に十分な計算機リソースが十分空いていればそれのパスを使用し、空いていなければ追加で動的にパスを確立する。これは、事前準備のタイミングにおいては、まだ、アプリケーションが全くデプロイされていないため、計算機リソースは潤沢に利用可能であることから、計算機リソースが足りなくなることは無いだろう、という実運用上の想定に基づく。

【0065】

図６は、光パス確立処理の処理手順の一例を説明するためのシーケンス図である。

【0066】

ステップＳ２０１において、クラスタ制御機能部１１は、ネットワーク制御機能部５０に対して光パス確立を指示することで、テナントごとに異なる波長を割り当てるための制御を行う。この際、当該光パスで接続されるノード２０（以下、「対象ノード２０」という。）とテナント（以下、「対象テナント」という。）とのそれぞれの識別子のペアである、ノード識別子（以下、「対象ノード識別子」という。）及びテナント識別子（以下、「対象テナント識別子」という。）のペアが通知される。ネットワーク制御機能部５０は、未利用の（まだ割り当てられていない）波長を選択し（Ｓ２０２）、通知された情報に基づいて光ネットワークＮ１と対象テナントのローカルＧＷ３０との間の光パスを確立する（Ｓ２０３、Ｓ２０４）。なお、未利用の波長は、光パス情報管理機能部１１１（表１）を参照して特定可能である。未利用の波長が選択されることで、少なくともテナントごとに異なった波長が選択されることになる（但し、一つのテナントに対して複数の波長が割り当てられる場合は有る）。したがって、ステップＳ２０１におけるクラスタ制御機能部１１による指示は、テナントごとに異なる波長を割り当てるための制御に相当する。

【0067】

光パス確立後、ネットワーク制御機能部５０は、選択した波長を示す波長情報（以下、「対象波長情報」という。）をリクエスト元であるクラスタ制御機能部１１に返却する（Ｓ２０５）。

【0068】

クラスタ制御機能部１１は、対象波長情報を、光パス確立を行ったノード２０（対象ノード２０）のノード制御機能部２５に対して通知する（Ｓ２０６）。

【0069】

続いて、ノード制御機能部２５は、利用する空きポート（以下、「対象ポート」という。）を光パス情報管理機能部１１１（表１）を参照して選択する（Ｓ２０７）。具体的には、ノード制御機能部２５は、光パス情報管理機能部１１１（表１）において対象ノード識別子を含む行のうち、波長及びテナント識別子が未登録のいずれかの行のポート識別子（以下、「対象ポート識別子」という。）に係るポートを対象ポートとして選択する。すなわち、空きポートとは、波長が割り当てられていないポートをいう。但し、クラスタ制御機能部１１が、どのポートに波長を割り当てるかを決めても良い。

【0070】

続いて、ノード制御機能部２５は、対象ポートに対する対象波長情報に係る波長の割り当てを光波長多重機能部２４及び光変換機能部２３に指示することで、光波長多重機能部２４及び光変換機能部２３の対象ポートに対して当該波長を割り当てる（Ｓ２０８～Ｓ２１１）。光波長多重機能部２４及び光変換機能部２３は、対象ポート及び当該波長を用いて光パスを確立する（Ｓ２１２）。一般に電気・光変換を行う際に、変換される光の波長は一意に定まるため、変換時に用いる波長は、電気・光変換を担う光変換機能部２３で設定する必要があるが、波長設定については、光変換機能部２３ではなく、光波長多重機能部２４に波長変換機能を具備し、こちらで波長を設定する形態が採用されてもよい。

【0071】

パス確立（＝波長／ポート設定完了）後（Ｓ２１３）、ノード制御機能部２５は、対象ポート識別子及び対象波長情報とともにパス設定完了をクラスタ制御機能部１１に通知する（Ｓ２１４）。当該通知に応じ、クラスタ制御機能部１１は、光パス情報管理機能部１１１（表示１）の対象ノード識別子及び対象ポート識別子の行に対象波長情報及び対象テナント識別子を追記する（Ｓ２１５）。

【0072】

このとき、テナント側のローカルネットワークにおいて既にＴＳＮ環境がセットアップされており、送信スケジュールが既に存在している場合は、その送信スケジュール情報を送信スケジュール情報管理機能部１１２（表２）へ投入することも可能である。これにより、ローカルネットワークで利用済みの送信スロットの重複利用を回避する。

【0073】

また、この光パスまたは他の経路を用いて、ノード２０の時刻同期機能部２６とローカルＧＷ３０の時刻同期機能部３４により、時刻同期が実施される。これはノード２０とローカルＧＷ３０が、送信スケジュールに従った厳密な送信制御を行うために必要なものである。

【0074】

［アプリケーションデプロイ：ノード２０の選択］
アプリケーションデプロイ時には、クラスタ制御機能部１１に対してアプリケーションのデプロイが要求される。このとき、アプリケーションデプロイの要求の実施者は、デプロイに必要となるアプリケーション情報、必要なＣＰＵ／メモリなどの計算機リソース要求情報に加え、ＴＳＮ設定に必要となる、アプリケーションに紐づくテナント識別子（以下、「対象テナント識別子」という。）、及びアプリケーションが要求する送信周期情報（以下、「要求送信周期情報」という。）をクラスタ制御機能部１１に通知する。送信周期情報は、データの送信周期及び各送信タイミングに必要な送信時間（例えば、周期１［ｍｓ］，送信時間１００［μｓ］）から構成される。また、アプリケーション情報とは、デプロイするアプリケーションに関する情報であり、例えば、ｋｕｂｅｒｎｅｔｅｓにおけるｍａｎｉｆｅｓｔファイルである。ｍａｎｉｆｅｓｔファイルには、アプリケーション名や、利用するコンテナのイメージ、実行するコマンドなどの情報が記載されている。なお、アプリケーション情報には、他のアプリケーションとの送信スロットの共用が可能な場合、その旨を合わせて記載することもできる。記載の方式としては、全てのアプリケーションとの共用を許可する、アプリケーション名を指定して特定のアプリケーションとの共用のみ許可する、又はＫｕｂｅｒｎｅｔｅｓにおけるラベル(https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/labels/) の概念用いた指定(例えば、location: factoryA というラベルを持つアプリの共用を許可する)等が考えられる。例えば、表２において、送信スロットが「９００μｓ－９２０μｓ」の行には、２つのアプリ識別子（ａｐｐ１，ａｐｐ２）が登録されている例が示されているが、これら２つのアプリ識別子に係るアプリケーションは、それぞれ送信スロットの共用が可能であるアプリケーションの例である。

【0075】

図７は、デプロイ先ノードの選択処理の処理手順の一例を説明するためのフローチャートである。

【0076】

アプリケーション情報、送信周期情報、リソース要求情報及び対象テナント識別子等を受領したクラスタ制御機能部１１は、まず、対象テナント識別子に対応する行（以下、「対象行」という。）が光パス情報管理機能部１１１（表１）に有るか否かを判定する（Ｓ３０１）。対象行が有る場合（Ｓ３０１でＹ）、クラスタ制御機能部１１は、対象テナント識別子に紐づくノード識別子及び光波長情報（これらの情報を以下「光パス情報」という。）が対象行に含まれているか否かを判定する（Ｓ３０２）。

【0077】

光パス情報が有る場合（Ｓ３０２でＹ）、クラスタ制御機能部１１は、当該光パス情報に係る光パスのＴＳＮ送信スケジュール（表２）と要求送信周期情報に係る送信周期（以下、「要求送信周期」という。）とを比較することで、要求送信周期をＴＳＮ送信スケジュールに割り当て（組み込み）可能であるか否かを判定する（Ｓ３０３）。具体的には、一つの光パスは、一つのＴＳＮ送信スケジュール（表２）に対応する。そして、ＴＳＮ送信スケジュール（表２）は複数の送信スロットから構成される。この送信スロットをアプリに対して割り当てようとする（ＴＳＮ送信スケジュールの空いている枠から、アプリが送信したい時間分、送信スロットとして割り当てていくイメージ）。ここで、アプリが利用したい時間分の枠を、ＴＳＮ送信スケジュールから確保できれば割り当て可能と判定され、確保できなければ割り当て不可と判定される。但し、送信スロットの共有が可能である場合、既に他のアプリケーションに割り当てられている送信スロットも割り当て候補となる。なお、対象テナント識別子に紐づく光パス情報が複数有る場合には、いずれかの対象光パス情報に対応するＴＳＮ送信スケジュールに対して要求送信周期を割り当て可能であればよい。

【0078】

要求送信周期での送信が可能な光パス（以下、「対象光パス」という。）が１以上有る場合（Ｓ３０３でＹ）、クラスタ制御機能部１１は、いずれかの対象光パス対応するノード２０の中でリソース要求情報が示すリソース（以下、「要求リソース」という。）を満たすことのできる計算機リソースの空きを有するノード２０の有無を判定する（Ｓ３０４）。該当するノード２０が１以上有る場合（Ｓ３０４でＹ）、クラスタ制御機能部１１は、該当するノード２０のうちのいずれかをデプロイ先として決定（選択）する（Ｓ３０５）。該当するノード２０が複数ある場合、クラスタ制御機能部１１は、計算機リソースが最も潤沢な１つのノード２０を選択してもよいし、ランダムにいずれか１つのノード２０を選択してもよい。

【0079】

一方、光パス情報が無い場合（Ｓ３０２でＮ）、要求送信周期での送信が不可能な場合（Ｓ３０３でＮ）、又はいずれかの対象光パスに対応するノード２０の中に要求リソースを満足できるノード２０が無い場合（Ｓ３０４でＮ）、クラスタ制御機能部１１は、要求リソースを満足できるノード２０を対象光パスとは無関係なノード２０の中から選択し、当該ノード２０に係る新たな光パスを確立する（Ｓ３０６）。光パスの確立手順については、図６において説明した通りである。この際、図６のステップＳ２０１では、対象テナント識別子と、当該ノード２０のノード識別子とが指定される。光パスの確立に成功すると（Ｓ３０７でＹ）、ステップＳ３０１以降が繰り返される。光パスの確立に失敗すると（Ｓ３０７でＮ）、図７の処理は異常終了する。なお、ステップＳ３０３とステップＳ３０４との判定は、いずれが先に実行されてもよい。

【0080】

［アプリケーションのデプロイ：ＴＳＮ設定の実施］
図８は、アプリケーションのデプロイ処理の処理手順の一例を説明するためのシーケンス図である。

【0081】

アプリケーションの要求するリソースを提供可能、かつ、ＴＳＮ送信スケジュールを満足できるノード２０が有る場合、クラスタ制御機能部１１は、当該ノード２０のノード制御機能部２５にアプリケーションのデプロイを指示する（Ｓ４０１）。斯かる指示は、アプリケーション情報、要求送信周期情報、リソース要求情報及びポート識別子等を含む。当該ポート識別子は、図７の説明における対象光パスに対応するポート識別子である。

【0082】

ノード制御機能部２５は、当該指示に応じ、アプリケーションを実行するための設定を実施する。まず、ノード制御機能部２５は、当該アプリケーション情報に係るアプリケーションのデプロイをアプリケーション収容機能部２１に指示する（Ｓ４０２）。アプリケーション収容機能部２１は、当該アプリケーションをデプロイする（配置し、実行可能な状態とする）（Ｓ４０３）。

【0083】

続いて、ノード制御機能部２５は、当該アプリケーションと当該ポート識別子に係るポートとの接続と、要求送信周期情報の設定とをフレーム送受信機能部２２へ指示する（Ｓ４０４）。フレーム送受信機能部２２は、当該指示に応じ、フレーム送受信機能部２２の当該ポートと当該アプリケーションとを接続し、当該ポートに対して要求周期情報を設定する（Ｓ４０５）。

【0084】

続いて、ノード制御機能部２５は、デプロイの完了をクラスタ制御機能部１１へ通知する（Ｓ４０６）。クラスタ制御機能部１１は、当該通知に応じ、図７のステップＳ３０２において存在が特定された光パス情報に対応する光パス情報管理機能部１１１（表２）に１行を追加し、当該行に対して、要求送信周期情報に対応する送信スロットとデプロイされたアプリケーションのアプリ識別子とを登録する（Ｓ４０７）。

【0085】

これにより、特定のテナントに紐づくアプリケーションについての通信は、設定されたスケジュールに基づきフレーム送受信機能部２２から送出され、光変換機能部２３にてテナントに対応する波長の光信号に変換される。更に、光波長多重機能部２４において複数の波長の光信号とともに１本の光ファイバ内に重畳され、光ネットワークＮ１を経由して伝送される。伝送先のローカルＧＷ３０において電気信号に再度変換され、ローカルネットワーク側に送出される。

【0086】

なお、ノード制御機能部２５は、デプロイされたアプリケーションに対して、割り当てられた送信スケジュール情報（ｂａｓｅＴｉｍｅ，送信周期，送信オフセット，送信時間等）を通知する。通知するための手段として、例えば、ＫｕｂｅｒｎｅｔｅｓにおけるＣｏｎ．ｇＭａｐの利用などが考えられる。当該アプリケーションは、通知されたスケジュール情報に従いパケット送出を実施する。

【0087】

［実施例］
続いて、実施例について述べる。はじめに、接続構成による実施例を述べ、次に、波長の利用形態による実施例について述べ、最後にそれ以外の実施例について述べる。

【0088】

［実施例１：接続構成による分類］
接続構成による分類を図９に示す。

【0089】

［実施例１－１：ノード筐体から光信号を直接出力］
本実施例では、光信号を生成する光変換機能部２３及び波長多重を行う光波長多重機能部２４をノード２０内に内蔵するパターンである。複数のテナント（ＴＳＮスケジュール）に属するアプリケーションを収容する場合、ノード２０から直接、波長の異なる光信号を複数（送信スケジュール分だけ）生成し、それを波長多重して一本の光ファイバケーブルで伝送し、光ネットワークＮ１側に接続するようにすることで、ＤＣ内の配線の煩雑さを低減することができるメリットがある。

【0090】

なお、光波長多重機能部２４とポート（どちらのＮＵＭＡ ｎｏｄｅに属する）のマッピングを切り替えることも可能である（図１０）。もし、現在ポートが接続されているＮＵＭＡ ｎｏｄｅに利用可能なコンピューティングリソースが十分残っていない場合で、もう片方のＮＵＭＡ ｎｏｄｅのコンピューティングリソースに空きがある場合は、波長とポートの対応関係の切り替え（切替方式１）、又はフレーム送受信機能部２２のポートと光変換機能部２３のポートの対応関係の切り替え（切替方式２）を行うことで、より効率良くコンピューティングリソースと光ネットワークＮ１のリソースを利用することができる。

【0091】

［実施例１－２：電気／光変換（Ｅ／Ｏ変換）をノード外で実施］
本実施例は、実施例１－１で実施していた光信号変換及び波長多重をノード２０の外側の変換装置で行うパターンである。実施例１－２は、現在のＥｔｈｅｒｎｅｔ（登録商標）（例えば、１０００ＢＡＳＥ－Ｔ，１０ＧＢＡＳＥ－ＳＲ，１０ＧＢＡＳＥ－ＬＲ等）ベースで接続されているサーバを容易に活用できるメリットがある。また、実施例１－２は、実施例１－１と比べると物理装置が増えてしまうデメリットはあるものの、複数のノード２０を変換装置に接続して、複数ノード２０分の波長をまとめることで、必要な光ファイバの配線本数は削減できる可能性がある（変換装置の収容可能ポート数などにも依存する。）。

【0092】

［実施例１－３：ＰＯＮによる接続］
実施例１－２のようにノード外でＥ／Ｏ変換を行う場合のバリエーションの一つとして、ＰＯＮ（Passive Optical Network）との統合について述べる。ＰＯＮは、複数の加入者宅を収容するための技術であり、ＩＥＥＥ８０２．３ａｈ等で規定されている（「IEEE, "IEEE Standard for Information technology- Local and metropolitan area networks- Part 3:CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access ControlParameters, Physical Layers, and Management Parameters for Subscriber Access Networks," IEEE.doi:10.1109/IEEESTD.2004.94617，http://ieeexplore.ieee.org/document/1337489/」（以下、「参考文献１」という。））。現在のＦＴＴＨ（Fiber to the Home）サービスにおいて広く利用されている。

【0093】

ＰＯＮでは、下り方向の通信の場合、時分割多重方式（ＴＤＭ：Time Division Multiplexing）を用いる。それぞれのフレームには宛先情報が付与されており、各ローカルＧＷ３０に相当するＯＬＴは，これを見て自身のデータを取得する。このときの送信タイミングは、ＯＬＴにおけるＭｕｌｔｉ－Ｐｏｉｎｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ機能部により決定される。具体的には、送信ポートに対応するＭｕｌｔｉ－ｐｏｉｎｔ ＭＡＣ Ｃｏｎｔｒｏｌ ｉｎｓｔａｎｃｅに対してｔｒａｎｓｍｉｔＥｎａｂｌｅメッセージを送ることで、送信が許可される。複数のｉｎｓｔａｎｃｅが同時に送信要求を上げた場合のスケジューリングアルゴリズムについては、実装依存とされている（「The scheduling algorithm is implementation dependent, and is not specified for the case where multiple transmitrequests happen at the same time."（参考文献１の64.2.1 Principles of Multi-point MAC Control）」より引用）。

【0094】

ここで、スケジューリングアルゴリズムとして、周期的な送信許可を固定的に与えることで、その周期内のある期間においては、必ず或る収容先への通信を行うことが可能となる。その期間を利用可能な波長及びスケジュール情報として登録することで、ＰＯＮにおいてもＴＳＮによる厳密な遅延通信を実現することが可能となる（時刻同期が行われていることが前提）。送信許可をどのように与えるかは任意であり、例えば、全ての収容先に均等に割り当てることもできる一方、より細かな周期での割当も行うことが可能である（図１１）。

【0095】

例えば、図１１の左図の場合、クラスタに登録される情報は表３に示すような形式となる。

【0096】

【表3】

［実施例１－４：ＮＧ－ＰＯＮ２による実現方式］
実施例１－３と類似の形態として、ＩＴＵ－Ｔ Ｇ．９８９．１として規定されるＮＧ－ＰＯＮ２（「ITU-T, Recommendation ITU-T G.989.3: 40-Gigabit-Capable Passive Optical Networks (NG-PON2): Transmission Convergence Layer Speci.cation. Oct. 2015、https://www.itu.int/rec/T-REC-G.989.3-201510-I/en」）を利用する例について示す。ＮＧ－ＰＯＮ２の特徴として、ＰｔＰ ＷＤＭ（Point-to-Point WDM）と呼ばれる、特定のＯＮＵとの間で専用の波長を利用し、他のＯＮＵの通信とは排他に通信を行うことができる方式が規定されていることが挙げられる。これを用いることで、ＰＯＮによる複数ユーザの時分割多重による収容を行いつつ、特定の対象に対して波長（＝ＴＳＮスケジュール）を専有的に割り当てることが可能となる。ＰｔＰ ＷＤＭの場合は、専有割当された対象については、Ｓｉｎｇｌｅ Ｓｔａｒ構成と同様に、波長を独占的に利用することが可能となる。

【0097】

［実施例２：波長の使い方による実施例の分類］
波長・テナント・アプリの組み合わせによる分類を図１２に示す。

【0098】

［実施例２－１：１つの波を１テナントで共有］
１つのテナントが一つの波長の波を専有する、最もシンプルな実施例である。各テナントのアプリケーションは、潤沢に割り当てられたＴＳＮスケジュールをすべて利用することが可能となる。なお、ＣＰＵ／メモリなどのコンピューティングリソースが不足している場合は、同じ波長の波を用いた光パスを別のノード２０で作成することで、収容可能領域を拡張することが可能である（→実施例２－３）。

【0099】

［実施例２－２：１つの波を複数テナントで共用］
波長数及びポート数に制限がある場合は、複数のテナントで１つの波（＝ＴＳＮスケジュール）を共有することも考えられる。ＴＳＮの送信スケジュール情報管理機能部１１２で管理される送信スケジュール情報を、複数のテナントで共有し、送信スロットの割当を可能とする。光パスは、ノード２０から複数のテナントに対して確立される（複数経路への同時伝送は、光スイッチや分波器等により実現される）。このような場合、他のテナントの通信が受信可能となるため、Ｌ２以上のレイヤで暗号化するなど、セキュリティ観点での考慮が必要となる。

【0100】

［実施例２－３：複数の波を１テナントで専有］
ＴＳＮスケジュールのスロット数が不足する場合は、新たに波長を作成してＴＳＮスケジュール数を拡張することが可能である。この場合、ローカルＧＷ３０側のポートも複数具備する必要がある。また、ＴＳＮトラヒックとベストエフォートのトラフィックを波長レベルで完全分離することも原理的には可能である。あるいは、ＴＳＮトラヒック、ベストエフォートトラヒック、ｎｏｎ－ＩＰ（ＲＤＭＡ／ＲｏＣＥ等）のトラヒックをそれぞれ別々に伝送することも考えられる。

【0101】

［実施例２－４：１つの波を１テナントで専有（複数拠点）］
テナントの拠点は複数存在することが考えられる。その場合、実施例２－２と同様に多拠点の光パスを確立することで、複数拠点との通信が可能となる。

【0102】

［実施例２－５：複数経路を用いた冗長化］
冗長化のため、同一波長の波を複数経路で伝送可能とすることが考えられる。ＤＣの直後で分波し、テナント拠点付近で複数経路からの通信を合波するような形態である。このとき、合波時に伝搬時間ずれを吸収する機能を具備する（顕著な伝搬ずれがある場合）。また、経路状態を監視し、経路断を検知してＳｔａｎｄＢｙ側に切り替えるなどの対応を実施することで、片方の経路が寸断された場合でも通信を継続することが可能となる。

【0103】

［実施例３：上り方向通信］
光変換機能部２３に受光機を具備する。光パス情報管理機能部１１１において上り方向波長も管理し、パス確立時に光波長多重機能部２４側で受信した波長をどのポートに流すかを設定することで、上り方向の通信に関しても正しく受信することが可能となる。

【0104】

［実施例４：ＴＳＮ制御、コンピューティング制御機能を分離したパターン］
図１３は、実施例４における機能構成例を示す図である。図１３中、図３と同一部分又は対応する部分には同一符号を付し、その説明は適宜省略する。

【0105】

図１３において、ＤＣは、更に、制御サーバ６０を含む。制御サーバ６０は、ＤＣ内のローカルネットワークを介してオーケストレータ１０及び各ノード２０に接続される。制御サーバ６０は、コンピュート制御機能部６１、ＴＳＮ制御機能部６２及び光パス制御機能部６３を有する。これら各機能部は、制御サーバ６０にインストールされた１以上のプログラムが制御サーバ６０のＣＰＵに実行させる処理により実現される。制御サーバ６０は、また、コンピュートリソース情報管理機能部６１１、ＴＳＮ情報管理機能部６１２、光パス情報管理機能部６１３を有する。これら各管理機能部は、例えば、オーケストレータ１０の補助記憶装置を用いて情報を記憶及び管理するデータベースである。

【0106】

一方、オーケストレータ１０は、オーケストレーション制御機能部１２を有する。オーケストレーション制御機能部１２は、オーケストレータ１０にインストールされた１以上のプログラムがオーケストレータ１０のＣＰＵに実行させる処理により実現される。

【0107】

なお、実施例４は、上記において主にクラスタ制御機能部１１が担っていた役割を、コンピュート制御機能部６１、ＴＳＮ制御機能部６２、光パス制御機能部６３及びオーケストレーション制御機能部１２の４つの制御機能部に分解した例である。

【0108】

コンピュートリソース情報管理機能部６１１は、ノード２０のＣＰＵやメモリなどのコンピュートリソースの利用状況を管理する。

【0109】

ＴＳＮ情報管理機能部６１２は、表４に示すような、ＴＳＮの送信スケジュール、対応するテナント並びにノード２０、ポートについての情報を管理する。

【0110】

【表4】

これらのスケジュール情報のエントリは、後述の光パス確立手順において作成される。

【0111】

光パス情報管理機能部６１３は、表５に示すような、各ノード２０及び各ポートからどのような波長を出力するかについての情報や、光パス構成に必要な宛先テナント情報をはじめとする各種情報を管理する。

【0112】

【表5】

こちらの光パス情報のエントリについては、後述のノード情報登録処理の実行時に作成される。

【0113】

コンピュート制御機能部６１は、アプリケーションへのリソース割当／デプロイ制御を行う。コンピュート制御機能部６１は、ノード２０のリソース利用状況をコンピュートリソース情報管理機能部６１１から取得し、リソースを割り当て可能な場合はコンピューティングリソースの確保及びアプリケーションのデプロイをアプリケーション収容機能部２１に対して指示する。

【0114】

ＴＳＮ制御機能部６２は、ノード２０及びポートの毎に紐づくＴＳＮ送信スケジュールをＴＳＮ情報管理機能部６１２から取得し、送信スロットの空き状況の問い合わせに対して対応すると共に、ＴＳＮ送信スケジュールのポートへの適用をフレーム送受信機能部２２に対して指示する。

【0115】

光パス制御機能部６３は、ノード２０とテナントの間での光パス確立の役割を担う。

【0116】

オーケストレーション制御機能部１２は、コンピュート制御機能部６１、ＴＳＮ制御機能部６２、光パス制御機能部６３等のコンポーネントと連携して、アプリケーションのデプロイを実施する。

【0117】

なお、図１３は、各制御機能部から直接的にノード２０内の機能部に対して指示を行う例に対応するが、各ノード２０においてノード制御機能部２５が存在し、それらが代表して指示を受け取ってもよい。代表して指示を受け取る機能部は、ノード２０単位にとどまらず、クラスタ単位で存在することも考えられる。また、ここでは、オーケストレーション制御機能部１２が各機能部への指示を行っているが、オーケストレーション制御機能部１２無しで各機能部が直接やり取りする形態も考えられる。更に、この例では、ローカルＧＷ３０の機能部に対しても設定が行われているが、これは各テナントの管理者が手動で実施することも考えられる。

【0118】

次に、実施例４における処理手順について説明する。

【0119】

図１４は、実施例４におけるノード情報登録処理の処理手順の一例を説明するためのシーケンス図である。

【0120】

ノード２０の追加時、当該ノード２０のノード制御機能部２５又は運用者は、光パス制御機能部６３に対してポート情報（ノード識別子及びポート識別子）を登録する（Ｓ５０１）。光パス情報制御機能部は、当該ポート情報を光パス情報管理機能部６１３へ保存する（Ｓ５０２）。光パス情報管理機能部６１３に保存されるポート情報の構成は、表５に示すようなイメージであるが、現時点（＝光パス確立前）では、波長及びテナント識別子の欄は、表５の４番目の行のように空欄となる。

【0121】

図１５は、実施例４における光パス確立処理の処理手順の一例を説明するためのシーケンス図である。

【0122】

運用者による手動投入による光パス確立指示、又はアプリケーションのデプロイ時の自動実行による光パスの確立指示をトリガとして、オーケストレーション制御機能部１２は、光パス制御機能部６３に対して光パスの確立を要求する（Ｓ６０１）。この際、当該光パスで接続されるノード２０（以下、「対象ノード２０」という。）とテナント（以下、「対象テナント」という。）とのそれぞれの識別子のペアである、ノード識別子（以下、「対象ノード識別子」という。）及びテナント識別子（以下、「対象テナント識別子」という。）のペアが通知される。

【0123】

光パス制御機能部６３は、利用可能なポート及び波長を光パス情報管理機能部６１３（表５）から検索し（Ｓ６０２、Ｓ６０３）、新たに利用するポート（以下、「対象ポート」という。）及び波長（以下、「対象波長」という。）を選択する（Ｓ６０４）。具体的には、光パス情報管理機能部６１３（表５）において、波長情報及びテナント識別子が割り当てられていないずれかの行のポート識別子に係るポートが対象ポートとして選択される。また、光パス情報管理機能部６１３（表５）のいずれの行にも割り当てられていない波長情報に係る波長が対象波長として選択される。

【0124】

続いて、光パス制御機能部６３は、光ネットワークＮ１、対象ノード識別子に係るノード２０、及び対象テナント識別子に係るローカルＧＷ３０に対して対象ポート及び対象波長に係る光パス設定を指示することで（Ｓ６０５、Ｓ６０６）、ノード２０－ローカルＧＷ３０間でパスを確立する（Ｓ６０７）。パスの確立後（Ｓ６０８）、光パス制御機能部６３は、光パス情報管理機能部６１３（表５）を更新する（Ｓ６０９）。具体的には、光パス情報管理機能部６１３（表５）において、対象ノード識別子及び対象ポート識別子を含む行に対して対象波長を示す波長情報及び対象テナント識別子がと登録される。

【0125】

続いて、光パス制御機能部６３は、オーケストレーション制御機能部１２に対して、対象ポートのポート識別子（以下、「対象ポート識別子」という。）と共に光パス確立完了を通知する（Ｓ６１０）。

【0126】

続いて、オーケストレーション制御機能部１２は、ＴＳＮ制御機能部６２に対して送信スケジュール情報の新規作成を指示する（Ｓ６１１）。この指示の際に与えられる情報は、対象テナント識別子、対象ノード識別子及び対象ポート識別子である。

【0127】

ＴＳＮ制御機能部６２は、ＴＳＮ情報管理機能部６１２（表４）に新規のスケジュール情報の作成する（Ｓ６１２）。すなわち、対象テナント識別子、対象ノード識別子、対象ポート識別子を含み、スケジュール識別子が新たに割り当てられた行がＴＳＮ情報管理機能部６１２（表４）に追加される。この際、送信スケジュール情報の欄は空欄とされる。続いて、ＴＳＮ制御機能部６２は、新規のスケジュール情報の作成完了をオーケストレーション制御機能部１２へ通知する（Ｓ６１３）。オーケストレーション制御機能部１２は、光パスの確立完了を通知する（Ｓ６１４）。

【0128】

図１６は、実施例４におけるアプリケーションのデプロイ処理の処理手順の一例を説明するためのシーケンス図である。

【0129】

アプリケーション開発者又は運用者からオーケストレーション制御機能部１２に対して、アプリケーション（以下、「対象アプリ」という。）のデプロイ要求が与えられる（Ｓ７０１）。続いて、オーケストレーション制御機能部１２は、デプロイ要求に含まれるテナント識別子（以下、「対象テナント識別子」という。）に対応するスケジュール情報をＴＳＮ制御機能部６２に対して問い合わせる（Ｓ７０２）。ＴＳＮ制御機能部６２は、対象テナント識別子に対応するスケジュール情報（ノード識別子（以下、「対象ノード識別子」という。）、ポート識別子（以下、「対象ポート識別子」という。）、送信スケジュール情報等）をＴＳＮ情報管理機能部６１２（表４）から取得し（Ｓ７０３、Ｓ７０４）、当該スケジュール情報（以下、「対象スケジュール情報」という。）をオーケストレーション制御機能部１２に返却する（Ｓ７０５）。

【0130】

続いて、オーケストレーション制御機能部１２は、対象スケジュール情報（表２）に基づいて、対象アプリが必要とする送信周期情報を満足する空き送信スロットがあるかどうかを判定し、送信スロットに空きが存在しない場合、新規に光パスを確立する（Ｓ７０６）。すなわち、図１５において説明した処理手順が実行される。この場合、新規に確立された光パスに係るノード識別子又はポート識別子が、対象ノード識別子又は対象ポート識別子となる。

【0131】

送信スロットに空きが有る場合、オーケストレーション制御機能部１２は、利用する送信スロット（以下、「対象送信スロット」という。）を決定する（Ｓ７０６）。但し、ステップＳ７０２において、要求する送信周期情報もＴＳＮ制御機能部６２に通知され、当該送信周期情報を満足する空き送信スロットの有無の判定及び利用する送信スロットの決定をＴＳＮ制御機能部６２が実施するようにしてもよい。

【0132】

続いて、オーケストレーション制御機能部１２は、対象ノード識別子に係るノード２０（以下、「対象ノード２０」という。）のリソースの利用状況をコンピュート制御機能部６１に問い合わせる（Ｓ７０８）。コンピュート制御機能部６１は、対象ノード２０のリソース情報をコンピュートリソース情報管理機能部６１１から取得し（Ｓ７０９、Ｓ７１０）、当該リソース情報（以下、「対象リソース情報」という。）をオーケストレーション制御機能部１２へ返却する（Ｓ７１１）。オーケストレーション制御機能部１２は、前述の空きスロットの確認と同様に、対象リソース情報に基づいて、対象アプリが必要とするコンピュートリソースの有無を確認し（Ｓ７１２）、十分なリソースがあればステップＳ７１４へ進む。十分なリソースが無ければ別のノード２０で光パスを新規に確立する（Ｓ７１３）。この場合、新規に確立された光パスに係るノード識別子又はポート識別子が、対象ノード識別子又は対象ポート識別子となる。

【0133】

これまでの手順で、対象アプリが要求する送信スロット（対象送信スロット）、コンピュートリソースの両方を確保可能なノード２０の選択が完了した。なお、コンピュートリソースの有無が先に判定されてもよい。

【0134】

続いて、実際に、ＴＳＮの送信スケジュール設定が行われる。具体的には、オーケストレーション制御機能部１２は、ＴＳＮ設定をＴＳＮ制御機能部６２に指示する（Ｓ７１４）。当該指示において、対象ノード識別子、対象ポート識別子及び対象スケジュール情報がＴＳＮ制御機能部６２へ通知される。

【0135】

ＴＳＮ制御機能部６２は、当該指示に応じ、対象ノード識別子に係る対象ノード２０の対象ポート識別子に係るポート（フレーム送受信機能部２２）に対して送信スケジュールの設定を実施する（Ｓ７１５～Ｓ７１７）。続いて、ＴＳＮ制御機能部６２は、ＴＳＮ情報管理機能部６１２（表４）における対象スケジュール情報を更新する（Ｓ７１８）。具体的には、ＴＳＮ情報管理機能部６１２（表４）において、対象テナント識別子、対象ノード識別子及び対象ポート識別子を含む行の送信スケジュール情報（表２）に対して、対象送信スロット及び対象アプリのアプリ識別子を含む行が追加される。

【0136】

続いて、ＴＳＮ制御機能部６２は、ＴＳＮの送信スケジュール設定の完了をオーケストレーション制御機能部１２へ通知する（Ｓ７１９）。

【0137】

続いて、オーケストレーション制御機能部１２は、コンピュート制御機能部６１に対して対象アプリのデプロイを指示する（Ｓ７２０）。続いて、コンピュート制御機能部６１は、対象ノード２０のアプリケーション収容機能部２１に対して対象アプリのデプロイを指示する（Ｓ７２１）。この指示を受けたアプリケーション収容機能部２１は、対象アプリをデプロイすると共に、対象アプリと対象スケジュール情報に係るポートとの接続を行い（Ｓ７２２）、デプロイの完了をコンピュート制御機能部６１へ通知する（Ｓ７２３）。

【0138】

続いて、コンピュート制御機能部６１は、リソース情報を更新する（Ｓ７２４）。具体的には、対象アプリに割り当てられたリソース分の減少がリソース情報に反映される。続いて、コンピュート制御機能部６１は、対象アプリのデプロイの完了をオーケストレーション制御機能部１２へ通知する（Ｓ７２５）。続いて、オーケストレーション制御機能部１２は、対象アプリ開発者又は運用者に対して対象アプリのデプロイの完了を通知する（Ｓ７２６）
上述したように、本実施の形態によれば、リアルタイム性が求められるアプリケーションのマルチテナント化及び広域化を実現可能とすることができる。

【0139】

具体的には、ＴＳＮの通信を光ファイバを用いて伝送することで、リアルタイム性を実現する上で問題となるゆらぎ（ｊｉｔｔｅｒ）の発生を最小限に抑えつつ、ＤＣとローカルＧＷ３０までの長距離区間でのＴＳＮ通信（ＴＳＮ通信の広域化）を実現することができる。

【0140】

また、このとき、ＤＣに収容されるアプリケーションの通信について、テナントごとに送信スケジュールを分離し、別々の波長の波に載せて伝送することで、
・他のテナントのＴＳＮ通信の影響を原理的に排除することができる。
・光波長多重（ＷＤＭ）を適用することで、配線コストを圧倒的に削減できる（１本の光ファイバにまとめられる）。
・通信に利用できる送信スロットを潤沢に利用できる。
・動的な光パス追加を可能とすることで、送信スケジュールの追加を可能とすることができる。
等のメリットを享受することができる（マルチテナント対応）。

【0141】

加えて、コンテナオーケストレータとの統合・連携により、光パス／送信スロットの管理もコンテナオーケストレータで実現可能とすることで、いわゆるクラウドネイティブなアプリケーションのデプロイと同じ要領で、アプリケーション開発者／運用者にとっても容易にアプリケーションのデプロイが可能となる（コンテナ対応）。これは、アプリケーション開発・運用の間口を、現在のクラウドアプリケーション開発者をはじめとしたより幅広い層に広げていく観点で重要である。なお、図３の構成においては、クラスタ制御機能部１１（＋クラスタリソース情報管理機能部）、ノード制御機能部２５及びアプリケーション収容機能部２１がコンテナオーケストレータに相当する。図１３の構成においては、コンピュート制御機能部６１（＋コンピュートリソース情報管理機能部６１１）及びアプリケーション収容機能部２１がコンテナオーケストレータに相当する。

【0142】

また、コンテナオーケストレータが一般的に実施する、必要なＣＰＵ／メモリなどのリソースの有無やそれら（ＣＰＵ／メモリ／ＮＩＣ）がノード２０内のトポロジ的に近傍にあるかだけではなく、通信に利用できる光パスの有無及び送信スケジュールの空き状況も加味してデプロイ先のノード２０を選択し、その上でＣＰＵ／メモリなどのコンピューティングリソースの専有設定、ＴＳＮスロット割当によるネットワークリソースの専有設定の両方を実施可能とする。これらの手法、すなわち、
・ＣＰＵ／メモリリソースの専有によるノード２０における計算機リソースの外乱抑制
・ノード２０内トポロジを意識したスケジューリングによるノード２０内のやりとり及びノード２０の中から外（ネットワーク）に出るまでの経路最短化
・光伝送／他テナント通信の波長分離によるネットワーク部分におけるゆらぎ最小化
を組み合わせることで、アプリケーション収容に求められるリアルタイム性の担保を、コンピュートノードからネットワークまで一気通貫で実現することができる。

【0143】

なお、本実施の形態において、オーケストレータ１０又は制御サーバ６０は、通信スケジュール割当装置の一例である。クラスタ制御機能部１１又は光パス制御機能部６３は、制御部の一例である。クラスタ制御機能部１１又はＴＳＮ制御機能部６２は、割当部の一例である。

【0144】

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0145】

１０ オーケストレータ
１１ クラスタ制御機能部
１２ オーケストレーション制御機能部
２０ ノード
２１ アプリケーション収容機能部
２２ フレーム送受信機能部
２３ 光変換機能部
２４ 光波長多重機能部
２５ ノード制御機能部
２６ 時刻同期機能部
３０ ローカルＧＷ
３１ フレーム送受信機能部
３２ 光変換機能部
３３ 光波長多重機能部
３４ 時刻同期機能部
４０ ＴＳＮ端末
５０ ネットワーク制御機能部
６０ 制御サーバ
６１ コンピュート制御機能部
６２ ＴＳＮ制御機能部
６３ 光パス制御機能部
１１１ 光パス情報管理機能部
１１２ 送信スケジュール情報管理機能部
６１１ コンピュートリソース情報管理機能部
６１２ ＴＳＮ情報管理機能部
６１３ 光パス情報管理機能部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】