JP2022028934A

JP2022028934A - 制御装置及びその方法

Info

Publication number: JP2022028934A
Application number: JP2021198235A
Authority: JP
Inventors: 孝法岩井; Takanori Iwai; 暢彦伊藤; Nobuhiko Ito
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2017-03-08
Filing date: 2021-12-07
Publication date: 2022-02-16
Anticipated expiration: 2037-12-15
Also published as: US11653255B2; JP7251604B2; JP6996549B2; US11388620B2; JPWO2018163557A1; US20220312259A1; WO2018163557A1; US20210136619A1

Abstract

【課題】トラフィックフローにより要求されるＱｏＳ性能を保証するための制御を、無視できない量の制御遅延が存在する場合であっても安定化することに寄与する。【解決手段】制御装置（４０）は、通信ネットワークを介して転送されるトラフィックフローに関するＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ（ＱｏＳ）性能の計測値を取得し、当該計測値をQoS性能の目標値と比較し、当該目標値を達成するように、前記通信ネットワーク内のノード（６０４）に供給される制御値を生成する。制御装置（４０）は、トラフィックフローに関するトラフィック関連パラメータの変化傾向および制御装置（４０）とノード（６０４）との間の制御遅延に基づいて制御値を補正する。【選択図】図７

Description

本開示は、通信ネットワークの制御に関し、特に通信ネットワークを介して転送されるトラフィックフローにより要求される目標値（setpoint）を達成するための当該通信ネットワーク内のノードに対する制御に関する。

無線通信ネットワークを介した超低遅延（ultra-low latency）サービスの提供が検討されている。超低遅延サービスは、ミッション・クリティカル通信（mission critical communication）を含んでもよい。例えば、Third Generation Partnership Project（3GPP）は、2020年移行の導入に向けた第5世代移動通信システム（5G）の標準化作業を3GPP Release 14として2016年に開始している。5Gシステムのアーキテクチャに対する要件は、ミッション・クリティカル通信のサポートを含む。

超低遅延サービス又はミッション・クリティカル通信は、例えば、高度交通システム（intelligent transport systems）、産業オートメーション、ロボティクス、触覚（haptic or tactile）インターネット、仮想現実（virtual reality）及び拡張現実（augmented reality）を含む。超低遅延サービス又はミッション・クリティカル通信は、ミリ秒レベルのエンドツーエンド・レイテンシ（end-to-end latency）を必要とする。例えば、非特許文献１は、触覚インターネット・アプリケーションにおいて１ミリ秒エンドツーエンド・レイテンシ（1-millisecond end-to-end latency）が必要であることを記載している。

なお、超低遅延サービス及びミッション・クリティカル通信は、信頼性（reliability）も必要とする。ここで、信頼性は、所定の（defined）エンドツーエンド・レイテンシ（i.e., 遅延バジェット、e.g., 1ミリ秒）内でのメッセージ送信を保証する能力（capability）を意味する。

特開２０１４－１９７３９１号公報特開２００８－１２４７４８号公報国際公開第２０１６／１５７７５３号

ITU-T Technology Watch Report (August 2014) - The Tactile Internet, [retrieved on 2017-02-27], <URL: http://www.itu.int/oth/T2301000023/en>

発明者等は、通信ネットワークを介して転送されるトラフィックフローにより要求されるQuality of Service（QoS）性能の目標値（setpoint）（e.g.,エンドツーエンド・レイテンシ）を達成するための通信ネットワークの制御に関して検討した。幾つかの実装において、制御装置は、以下に示すフィードバック制御を行う。制御装置は、通信ネットワークを介して転送されるトラフィックフローに関するQoS性能の計測値を取得し、当該計測値をQoS性能の目標値（setpoint）と比較する。そして、制御装置は、当該目標値を達成するように、当該通信ネットワーク内のノードに供給されるための制御値を決定する。

しかしながら、このようなフィードバック制御は、当該トラフィックフローに関するトラフィック関連パラメータの変化の影響を受けることに留意しなければならない。ここで、トラフィック関連パラメータは、目標値を達成するための制御値の決定に影響を与えるパラメータである。

一例として、２つのエンドノード（例えば、センサとアクチュエータ）の間の通信経路（以下、エンドツーエンドパスと呼ぶ）上で転送されるトラフィックフローにより要求されるエンドツーエンド・レイテンシを保証するための制御を考える。この制御では、フィードバック制御の目標値は、例えば、エンドツーエンド・レイテンシ、エンドツーエンド・スループット、又は通信ネットワークに対する許容遅延であってもよい。フィードバック制御の制御値は、トラフィックフローに対する保証QoSであってもよく、より具体的には、優先度、保証遅延、及び保証ビットレートのうち少なくとも１つであってもよい。トラフィック関連パラメータは、例えば、エンドツーエンド・レイテンシが保証される１回の通信イベントで送られるデータサイズであってもよい。さらに又はこれに代えて、トラフィック関連パラメータは、通信イベント当たりのデータレート及び通信間隔のうち少なくとも一方を含んでもよい。トラフィック関連パラメータは、トラフィックフローのパターンに関係し、エンドノード間の送信データサイズ又はデータレートと共に変化するその他のパラメータであってもよい。

一例として、画像データ又は映像データがエンドノード間で送信される場合、画像解像度又はフレームレートの変化に応じて通信イベント当たりのデータサイズ及びデータレートが変化する。あるいは、エンドノード間で送信されるデータが画像から抽出された複数の特徴点（局所特徴）に関する特徴ベクトルの集合（set of feature vectors）である場合、画像から抽出される特徴点の数の変化に応じて通信イベント当たりのデータサイズ及びデータレートが変化する。制御装置は、トラフィック関連パラメータ（e.g., 通信イベント当たりのデータサイズ）が変化した場合にも所定のエンドツーエンド・レイテンシを保証できることが望ましい。

さらに、このようなフィードバック制御は、制御遅延の影響を受けることに留意しなければならない。制御装置とノードの間の制御遅延が増加するほど、フィードバック制御が難しくなる。特に、制御遅延がトラフィック関連パラメータの変化の発生間隔よりも大きい場合、トラフィックフローにより要求されるQoS性能を保証する制御を安定化することが難しい。

ところで、特許文献１は、無線通信ネットワークを介してプロセスを制御するフィードバック制御について開示している。特許文献２は、ネットワーク（e.g., Internet Protocol（IP）ネットワーク）を介したノードの制御を開示している。具体的には、特許文献２では、制御装置は、ネットワークの遅延を考慮して現在のプロセス値を推定し、推定されたプロセス値に基づいて制御出力を生成する。特許文献３は、Service Capability Exposure Function（SCEF）がアプリケーション・レイヤ・エンティティから通信パターン情報を受信し当該通信パターン情報から導出されたネットワークパラメータをネットワークエンティティに送ることを開示している。しかしながら、特許文献１、特許文献２、及び特許文献３はいずれも、上述したようなトラフィック関連パラメータの変化を制御遅延が存在する場合にどのように補償するのかについて明示していない。

本明細書に開示される実施形態が達成しようとする目的の１つは、通信ネットワークを介して転送されるトラフィックフローにより要求されるQoS性能を保証するための制御を、無視できない量の制御遅延が存在する場合であっても安定化することに寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、制御装置は、メモリと、前記メモリに結合されるとともに複数のモジュールを実行するよう構成された少なくとも１つのプロセッサとを含む。前記複数のモジュールは、制御モジュール、監視モジュール、取得モジュール、及び補正モジュールを含む。前記制御モジュールは、通信ネットワークを介して転送されるトラフィックフローにより要求されるQuality of Service（QoS）性能の目標値（setpoint）を達成するように、前記通信ネットワーク内のノードに供給されるための制御値を決定するよう構成される。ここで、前記制御値は、前記トラフィックフローへのネットワークリソース割り当てを調整することを前記ノードに引き起こす。前記監視モジュールは、前記トラフィックフローに関するトラフィック関連パラメータを監視するよう構成される。前記取得モジュールは、前記制御装置と前記ノードの間の制御遅延を取得するよう構成される。前記補正モジュールは、前記トラフィック関連パラメータの変化傾向及び前記制御遅延に基づいて、前記制御値を補正するよう構成される。

第２の態様では、制御装置により行われる方法は、以下を含む：
（ａ）通信ネットワークを介して転送されるトラフィックフローにより要求されるQuality of Service（QoS）性能の目標値（setpoint）を達成するように、前記通信ネットワーク内のノードに供給されるための制御値を決定すること、ここで、前記制御値は、前記トラフィックフローへのネットワークリソース割り当てを調整することを前記ノードに引き起こす；
（ｂ）前記トラフィックフローに関するトラフィック関連パラメータを監視すること；
（ｃ）前記制御装置と前記ノードの間の制御遅延を取得すること；及び
（ｄ）前記トラフィック関連パラメータの変化傾向及び前記制御遅延に基づいて、前記制御値を補正すること。

第３の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第２の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

上述の態様によれば、通信ネットワークを介して転送されるトラフィックフローにより要求されるQoS性能を保証するための制御を、無視できない量の制御遅延が存在する場合であっても安定化することに寄与する装置、方法、及びプログラムを提供できる。

第１の実施形態に係る通信ネットワークの構成例を示す図である。エンドツーエンドパスの一例を示す図である。エンドツーエンドパスの一例を示す図である。エンドツーエンドパスの一例を示す図である。エンドツーエンドパスの一例を示す図である。第１の実施形態に係る制御装置による制御の一例を示すブロック図である。第１の実施形態に係る制御装置の動作の一例を示すフローチャートである。制御装置の構成例を示すブロック図である。

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜第１の実施形態＞
図１は、本実施形態を含む幾つかの実施形態に係る通信ネットワークの構成例を示している。図１の例では、通信ネットワークは、エンドノード１０、中間ノード２０Ａ及び２０Ｂ、並びにエンドノード３０を含む。エンドツーエンドパス１００は、エンドノード１０からエンドノード３０までの通信パスである。エンドノード１０は送信者（sender）エンドノードと呼ばれてもよく、エンドノード３０は受信者（receiver）エンドノードと呼ばれてもよい。

触覚インターネット及び産業オートメーションの例では、エンドノード１０はセンサに実装されたコンピュータであり、エンドノード３０はアクチュエータに実装されたコンピュータであってもよい。高度交通システム（ITS）の例では、エンドノード１０及びエンドノード３０は、共に自動車に実装されたコンピュータであってもよい。あるいは、エンドノード１０及びエンドノード３０のうち一方は自動車に実装されたコンピュータであり、他方はITSアプリケーションサーバであってもよい。

エンドツーエンドパス１００は、２又はそれ以上のパスセグメント１１０から成る。したがって、エンドツーエンドパス１００は、少なくとも１つの中間ノード２０を含む。図１の例では、エンドツーエンドパス１００は、３つのパスセグメント１１０Ａ、１１０Ｂ、及び１１０Ｃに分割されている。パスセグメント１１０Ａは、（sender）エンドノード１０から中間ノード２０Ａまでの通信パスである。パスセグメント１１０Ｂは、中間ノード２０Ａから中間ノード２０Ｂまでの通信パスである。パスセグメント１１０Ｃは、中間ノード２０Ｂから（receiver）エンドノード３０までの通信パスである。

エンドツーエンドパス１００は、アプリケーションレイヤの通信パスであり、アプリケーションレイヤ・メッセージを転送する。言い換えると、エンドツーエンドパス１００は、アプリケーションレイヤ・トラフィックフローを転送する。したがって、エンドノード１０及び３０は、共にアプリケーションレイヤ・プロトコルをサポートし、アプリケーションレイヤ・メッセージを処理する。トラフィックフローは、パケットフロー又はデータフローと呼ぶこともできる。

さらに、少なくとも１つの中間ノード２０も、アプリケーションレイヤ・プロトコルをサポートし、アプリケーションレイヤ・メッセージを処理してもよい。すなわち、エンドツーエンドパス１００で行われる通信イベント（又は通信トランザクション）は、２又はそれ以上のアプリケーションレイヤ通信を含んでもよい。

例えば、上述の触覚インターネット及び産業オートメーションの例では、少なくとも１つの中間ノード２０は、センサ（i.e., エンドノード１０）から受信したセンシングデータに基づいてアクチュエータ（i.e., エンドノード３０）を制御する制御・ステアリング（control/steering）サーバであってもよい。高度交通システム（ITS）の例では、少なくとも１つの中間ノード２０は、自動車（i.e., エンドノード１０）から受信したメッセージ又はデータに基づいて当該自動車又は他の自動車（i.e., エンドノード３０）を制御するITSサーバであってもよい。

さらに又はこれに代えて、１又はそれ以上の中間ノード２０の一部又は全ては、ネットワークレイヤ（i.e., レイヤ３、e.g., Internet Protocol（IP）レイヤ）をサポートし、アプリケーションレイヤ・メッセージを包含するパケットをエンドノード１０及び３０の間で転送してもよい。例えば、各中間ノード２０は、IPルータ又はゲートウェイであってもよい。

さらに又はこれに代えて、少なくとも１つの中間ノード２０は、エンドノード１０又は３０とエアインタフェースを介して通信するRANノード（e.g., 基地局、eNodeB、Radio Network Controller（RNC））であってもよい。

図２～図５は、エンドツーエンドパス１００のいくつかの具体例を示している。図２～図５の例では、エンドツーエンドパス１００は、無線通信ネットワーク（無線アクセスネットワーク（Radio Access Network（RAN））、又はRAN及びコアネットワーク）を含む。図２の例では、エンドツーエンドパス１００は、無線端末（User Equipment（UE））２１０からアプリケーションサーバ２７０までの通信パスである。したがって、UE２１０は（sender）エンドノード１０に対応し、アプリケーションサーバ２７０は（receiver）エンドノード３０に対応する。

図２に示されたエンドツーエンドパス１００は、RANノード２３０によって２つのパスセグメント１１０Ａ及び１１０Ｂに分割される。RANノード２３０は、中間ノード２０に相当する。図２のパスセグメント１１０Ａは、UE２１０からRANノード２３０までのRAN２２０（i.e., アップリンク・エアインタフェース）経由の通信パスである。図２のパスセグメント１１０Ｂは、RANノード２３０からアプリケーションサーバ２７０までの通信パスである。図２のパスセグメント１１０Ｂは、コアネットワーク２４０、コアネットワーク（CN）ゲートウェイ２５０、及びPacket Data Network（PDN）２６０を経由する。例えば、コアネットワーク２４０は、Evolved Packet Core（EPC）又はUniversal Mobile Telecommunications System（UMTS）パケットコアであり、CNゲートウェイ２５０は、PDN Gateway（PGW）又はGateway GPRS Support Node（GGSN）である。

図３の例では、エンドツーエンドパス１００は、UE３１０から出発してアプリケーションサーバ３７０を経由してUE３１０に戻るラウンドトリップ（round-trip）パスである。したがって、UE３１０は（sender）エンドノード１０及び（receiver）エンドノード３０に対応する。

図３に示されたエンドツーエンドパス１００は、RANノード３３０及びアプリケーションサーバ３７０によって４つのパスセグメント１１０Ａ、１１０Ｂ、１１０Ｃ、及び１１０Ｄに分割される。図３のパスセグメント１１０Ａは、UE３１０からRANノード３３０へのRAN３２０（i.e., アップリンク・エアインタフェース）を経由する通信パスである。図３のパスセグメント１１０Ｂは、RANノード３３０からアプリケーションサーバ３７０までの通信パスである。図３のパスセグメント１１０Ｃは、アプリケーションサーバ３７０からRANノード３３０までの通信パスである。図３のパスセグメント１１０Ｂ及び１１０Ｃは、コアネットワーク３４０、CNゲートウェイ３５０、及びPDN３６０を経由する。図３のパスセグメント１１０Ｄは、RANノード３３０からUE３１０へのRAN３２０（i.e., ダウンリンク・エアインタフェース）を経由する通信パスである。

図４の例は、図３の例の変形である。すなわち、図４の例では、エンドツーエンドパス１００は、UE３１０から出発してアプリケーションサーバ３７０を経由してUE４９０に到達する。したがって、UE３１０は（sender）エンドノード１０に対応し、UE４９０が（receiver）エンドノード３０に対応する。図４のパスセグメント１１０Ｃは、アプリケーションサーバ３７０からRANノード４８０までの通信パスである。図４のパスセグメント１１０Ｄは、RANノード４８０からUE４９０へのRAN３２０を経由する通信パス（i.e., ダウンリンク・エアインタフェース）ある。RANノード４８０は、RANノード３３０と同一であってもよい。

図５の例は、Mobile Edge Computing（MEC）に関する。MECは、アプリケーション開発者（application developers）及びコンテンツプロバイダに対して、モバイル加入者（mobile subscribers）に近接したRAN内でのクラウド・コンピューティング能力（capabilities）及びinformation technology（IT）サービス環境を提供する。この環境は、超低遅延（ultra-low latency）及び広帯域幅（high bandwidth）に加えて、アプリケーション及びサービスによって活用される（leveraged）ことができる無線ネットワーク情報（加入者位置、セル負荷など）への直接アクセスを提供する。MECは、Network Function Virtualization（NFV）と同様に、仮想化された（virtualized）プラットフォームに基づく。NFVはネットワーク機能に重点を置いているのに対して、MECは、ネットワークのエッジでのアプリケーションの実行を可能とする。

モバイルエッジ・クラウド５４０は、コンピューティング・リソース、ストレージ容量（capacity）、及びRANとのインタフェースをアプリケーションサーバ５５０に提供する。より具体的には、モバイルエッジ・クラウド５４０は、Infrastructure as a Service（IaaS）又はPlatform as a Service（PaaS）機能（facility）を提供することによって、アプリケーションのためのホスティング環境を提供する。すなわち、アプリケーションサーバ５５０は、モバイルエッジ・クラウド５４０内のサーバ（以下、MECサーバと呼ぶ）にホストされたアプリケーション（以下、MECアプリケーションと呼ぶ）であってもよい。モバイルエッジ・クラウド５４０（又はMECサーバ）は、Internet of Things（IoT）サービス・イネーブラと呼ぶこともできる。

図５に示されたエンドツーエンドパス１００は、RANノード５３０及びアプリケーションサーバ５５０によって４つのパスセグメント１１０Ａ、１１０Ｂ、１１０Ｃ、及び１１０Ｄに分割される。図５のパスセグメント１１０Ａは、UE５１０からRANノード５３０へのRAN５２０（i.e., アップリンク・エアインタフェース）を経由する通信パスである。図５のパスセグメント１１０Ｂは、RANノード５３０からMEC環境内のアプリケーションサーバ５５０までの通信パスである。図５のパスセグメント１１０Ｃは、アプリケーションサーバ５５からRANノード５３０までの通信パスである。図５のパスセグメント１１０Ｂ及び１１０Ｃは、モバイルエッジ・クラウド５４０を経由する。図５のパスセグメント１１０Ｄは、RANノード５３０からUE５１０へのRAN５２０（i.e., ダウンリンク・エアインタフェース）を経由する通信パスである。

再び図１を参照して説明する。図１に示されたコントローラ４０は、通信ネットワークを介して転送されるトラフィックフローにより要求されるQOS性能の目標値（setpoint）を達成するための当該通信ネットワーク内のノードに対する制御を行うよう構成された制御装置である。コントローラ４０は、各パスセグメント１１０を制御するために、各パスセグメント１１０に含まれる少なくとも１つのノード又は各パスセグメント１１０を制御するエンティティと通信する。例えば、コントローラ４０は、図２のパスセグメント１１０Ａ（i.e., RANセグメント）を制御するためにRANノード２３０と通信してもよい。コントローラ４０は、図２のパスセグメント１１０Ｂ（i.e., 有線ネットワーク・セグメント）を制御するためにRANノード２３０、CNゲートウェイ２５０、及びアプリケーションサーバ２７０のうち少なくとも１つと通信してもよい。さらに又はこれに代えて、コントローラ４０は、図２のパスセグメント１１０Ｂを制御するために、コアネットワーク２４０内の制御エンティティ（e.g., Service Capability Exposure Function（SCEF）又はPolicy and Charging Rules Function（PCRF））と通信してもよい。すなわち、図１ではコントローラ４０とエンドツーエンドパス１００に含まれる４つのノード１０、２０Ａ、２０Ｂ、及び３０との間の接続関係が示されているが、コントローラ４０は、これら４つのノードの一部のみと通信してもよい。

コントローラ４０は、１つのコンピュータシステムであってもよく、（分散された）複数のコンピュータシステムであってもよい。幾つかの実装において、コントローラ４０は、コアネットワーク（e.g.,コアネットワーク２４０又は３４０）に配置されてもよいし、PDN（e.g., PDN２６０又は３６０）に配置されてもよい。例えば、コントローラ４０は、コアネットワーク内の制御ノード（e.g., SCEF）に配置されてもよい。幾つかの実装において、コントローラ４０は、図５に示されたモバイルエッジ・クラウド５４０（e.g., MECサーバ、IoTサービス・イネーブラ）に配置されてもよい。幾つかの実装において、コントローラ４０は、エンドツーエンドパス１００に含まれるいずれかのノード（e.g., エンドノード１０、いずれかの中間ノード２０、又はエンドノード３０）に配置されてもよい。

コントローラ４０は、通信ネットワークを介して転送されるトラフィックフローにより要求されるQoS性能の目標値（setpoint）を達成するように、当該通信ネットワーク内のノード（e.g., エンドノード１０、いずれかの中間ノード２０、又はエンドノード３０）に供給されるための制御値を決定する。

QoS性能の目標値は、例えば、トラフィックフローの送信（sender）エンドノード１０及び受信（receiver）エンドノード３０の間のエンドツーエンド・レイテンシ、トラフィックフローの目標スループット、又は通信ネットワークに対する許容遅延であってもよい。

制御値は、トラフィックフローへのネットワークリソース割り当てを調整することをノードに引き起こす。制御値は、例えば、トラフィックフローに対する保証QoSであってもよく、より具体的には、優先度、保証遅延、及び保証ビットレートのうち少なくとも１つであってもよい。制御値は、ネットワーク制御ポリシと呼ぶこともできる。

幾つかの実装において、コントローラ４０は、以下に示すフィードバック制御を行ってもよい。すなわち、コントローラ４０は、通信ネットワークを介して転送されるトラフィックフローに関するQoS性能の計測値を取得し、当該計測値をQoS性能の目標値と比較する。そして、コントローラ４０は、当該目標値を達成するように、当該通信ネットワーク内のノードに供給されるための制御値を決定する。

さらに、コントローラ４０は、トラフィックフローに関するトラフィック関連パラメータを監視する。トラフィック関連パラメータは、QoS性能の目標値を達成するための制御値の決定に影響を与える。トラフィック関連パラメータは、例えば、エンドツーエンド・レイテンシが保証される１回の通信イベントで送られるデータサイズであってもよい。さらに又はこれに代えて、トラフィック関連パラメータは、通信イベント当たりのデータレート及び通信間隔のうち少なくとも一方を含んでもよい。トラフィック関連パラメータは、トラフィックフローのパターンに関係し、通信イベント当たりの送信データサイズ又はデータレートと共に変化するその他のパラメータであってもよい。

幾つかの実装において、コントローラ４０は、エンドノード１０又はエンドノード３０からトラフィック関連パラメータの設定値又は計測値を取得してもよい。さらに又はこれに代えて、コントローラ４０は、トラフィックフローの転送に関与する少なくとも１つの中間ノード２０からトラフィック関連パラメータの計測値を取得してもよい。さらに又はこれに代えて、コントローラ４０は、他の制御エンティティからトラフィック関連パラメータの設定値又は計測値を取得してもよい。

さらに、コントローラ４０は、コントローラ４０とノードの間の制御遅延を取得する。幾つかの実装において、当該制御遅延は、予め定められた一定値であってもよい。この場合、コントローラ４０は、メモリに格納された制御遅延の値を読み出して使用してもよいし、他のノードから受信してもよい。しかしながら、当該制御遅延は、コントローラ４０の負荷、若しくはコントローラ４０からの制御値に従って動作するノードの負荷、又はこれら両方に依存して変動するかもしれない。さらにまた、当該制御遅延は、コントローラ４０とノードとの間のネットワーク内の転送遅延の変動に依存して変動するかもしれない。また当該制御遅延は、ノードに接続している端末の数に依存して変動するかもしれない。したがって、幾つかの実装において、コントローラ４０は、制御遅延を計測してもよい。例えば、コントローラ４０は送信時のタイムスタンプを記述したパケットをノードに送信し、ノードは当該パケットの受信時のタイムスタンプを取得するとともに、これら２つのタイムスタンプの差から片道遅延時間を推定してもよい。コントローラ４０は、推定された片道遅延時間をノードから受信してもよい。

さらにまた、コントローラ４０は、トラフィック関連パラメータの変化傾向及び制御遅延に基づいて、ノードに供給される制御値を補正する。具体的には、コントローラ４０は、ノードが制御値に基づいて動作する将来の時点におけるトラフィック関連パラメータの推定値に当該制御値を適合させるように当該制御値を補正してもよい。言い換えると、コントローラ４０は、フロー関連パラメータ（e.g., 通信イベントあたりのデータサイズ）の変化（又は変動）と制御遅延とを、フィードバック制御に対する外乱（disturbances）として取扱ってもよい。コントローラ４０は、フロー関連パラメータの変化及び制御遅延をフィードフォワード制御により補償してもよい。

幾つかの実装において、コントローラ４０は、トラフィック関連パラメータの変化の傾向をその計測値（時系列）から推定し、ノードが制御値に基づいて動作する将来の時点におけるトラフィック関連パラメータの将来値を推定（予測）してもよい。そして、コントローラ４０は、推定されたトラフィック関連パラメータの将来値に当該制御値を適合させるように当該制御値を補正してもよい。

以下では、図６及び図７を参照してコントローラ４０の動作をより詳細に説明する。図６は、コントローラ４０により行われるQoS目標達成のための制御の一例を示すブロック図である。図７は、コントローラ４０の動作の一例（処理７００）を示すフローチャートである。

図６の例では、コントローラ４０は、制御部６０１、第１補正部６０２、及び第２補正部６０３を含む。制御部６０１は、QoS性能の計測値Y(t)をQoS性能の目標値SPと比較し、目標値SPを達成するように制御値C0(t)を生成する。なお、例えば目標値SP（e.g., エンドツーエンド・レイテンシ）から制御値C0(t)を導出するために、トラフィック関連パラメータ（e.g., 通信イベント当たりの送信データサイズ）の初期値TRP_0を考慮してもよい。図７のステップ７０１は、制御部６０１における処理に対応する。

第１補正部６０２は、トラフィック関連パラメータの最新値RP(t)を受信し、当該トラフィック関連パラメータの時間変化を補償するように制御値C0(t)を補正し、これによって第１の補正された制御値C1(t)を生成する。第１補正部６０２は、トラフィック関連パラメータの検出値TRP(t)と初期値（基準値）TRP_0との差分に基づいて制御値C0(t)を補正してもよい。図７のステップ７０２は、第１補正部６０２における処理に対応する。

第２補正部６０３は、制御遅延の最新値CD(t)を補償するように第１の補正された制御値C1(t)をさらに補正し、これによって第２の補正された制御値C2(t)を生成する。なお、既に説明したように、制御遅延は一定値であってもよい。図７のステップ７０３は、第２補正部６０３における処理に対応する。

ノード６０４は、第２の補正された制御値C2(t)をコントローラ４０から受信し、対象のトラフィックフローへのネットワークリソースの割り当てを当該制御値に従って調整する。ネットワークリソースの割り当て制御は、例えば、RANノード（e.g., eNB、RNC）による無線リソーススケジューリングであってもよい。例えば、RANノードは、制御値としての許容遅延を受信し、許容遅延を満足するように無線リソーススケジューリングを行ってもよい。

なお第１補正部６０２は、トラフィック関連パラメータを複数回受信してもよい。また第１補正部６０２および第２補正部６０３は、その回数に基づいて第１の補正された制御値C1(t)および第２の補正された制御値C2(t)を生成してもよい。第１補正部６０２および第２補正部６０３は、入力遅延と出力遅延のいずれに関する制御値を生成してもよい。

例えば、RANノードは、パケットスケジューリング（i.e., Medium Access Control（MAC）スケジューリング）を行うMACスケジューラを有する。幾つかの実装において、MACスケジューラは、Earliest Deadline First（EDF）アプローチに基づくスケジューリング・メトリック（i.e., EDFメトリック）を用いる。EDFメトリックは、遅延閾値（delay threshold）とhead of line delayとの差分の逆数に比例する。head of line delayは、ユーザの送信待ちの先頭パケットの遅延を意味する。RANノードは、制御値としての許容遅延を受信し、当該許容遅延を達成するように、当該トラフィックフローに関するパケットフロー又は他のパケットフローのEDFメトリックの計算に使用される遅延閾値（delay threshold）を変更してもよい。

さらに又はこれに代えて、ネットワークリソースの割り当て制御は、RANノード（e.g., eNB、RNC）、ゲートウェイ（e.g., PGW、SGSN）、又はトラフィックフローの転送に関与するその他のユーザプレーンノードによる通信帯域の制御であってもよい。

ゲートウェイ（e.g., PGW、SGSN）及びIPルータは、制御値（e.g.,保証ビットレート）を達成するように、当該トラフィックフローに関するパケットフロー又は他のパケットフローの分類（classification）若しくはスケジューリング又は両方における取り扱い（treatment）（e.g., 優先度）を制御してもよい。幾つかの実装において、ゲートウェイ及びIPルータは、当該トラフィックフローに関するパケットフローの優先度を上げるために当該フローの分類（class）を変更してもよい。さらに又はこれに代えて、ゲートウェイ及びIPルータは、当該トラフィックフローに関するパケットフローが格納されるキューに適用されるWeight Fair Queuing（WFQ）ウエイトを変更してもよい。

上述の説明から理解されるように、本実施形態に係るコントローラ４０は、トラフィック関連パラメータの変化傾向及び制御遅延に基づいて、ノードに供給される制御値を補正するよう構成されている。したがって、本実施形態に係るコントローラ４０は、通信ネットワークを介して転送されるトラフィックフローにより要求されるQoS性能を保証するための制御を、無視できない量の制御遅延が存在する場合であっても安定化することに寄与できる。

＜第２の実施形態＞
本実施形態は、第１の実施形態で説明されたコントローラ４０により行われる制御の変形例を説明する。本実施形態に係る通信ネットワークの構成例は、図１～図５に示された構成例と同様である。

本実施形態に係るコントローラ４０は、制御遅延に基づく第２の補正（i.e., 第２補正部６０３、図７のステップ７０３）を以下のように実行する。すなわち、コントローラ４０は、制御遅延の変化を監視し、制御遅延の変化を考慮して、第２の補正された制御値C2(t)を生成する。既に説明したように、制御遅延は、コントローラ４０の負荷、若しくはコントローラ４０からの制御値に従って動作するノードの負荷、又はこれら両方に依存して変動するかもしれない。さらにまた、制御遅延は、コントローラ４０とノードとの間のネットワーク内の転送遅延の変動に依存して変動するかもしれない。また当該制御遅延は、ノードに接続している端末の数に依存して変動するかもしれない。本実施形態に係るコントローラ４０は、制御遅延の変動を補償することができる。したがって、本実施形態に係るコントローラ４０は、通信ネットワークを介して転送されるトラフィックフローにより要求されるQoS性能を保証するための制御を、制御遅延の変動が存在する場合であっても安定化することに寄与できる。

最後に、上述の実施形態に係るコントローラ４０の構成例について説明する。図８は、コントローラ４０の構成例を示すブロック図である。図８を参照すると、コントローラ４０は、ネットワークインターフェース８０１、プロセッサ８０２、及びメモリ８０３を含む。ネットワークインターフェース８０１は、ネットワークエンティティ（e.g., エンドノード、中間ノード、UE、RANノード、CNノード、アプリケーションサーバ）と通信するために使用される。ネットワークインターフェース８０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。

プロセッサ８０２は、メモリ８０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態において説明されたコントローラ４０の処理を行う。プロセッサ８０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ８０２は、複数のプロセッサを含んでもよい。

メモリ８０３は、揮発性メモリ及び不揮発性メモリによって構成される。メモリ８０３は、プロセッサ８０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ８０２は、図示されていないI/Oインタフェースを介してメモリ８０３にアクセスしてもよい。

図８の例では、メモリ８０３は、制御（control）モジュール８０４、監視（monitor）モジュール８０５、取得（acquisition）モジュール８０６、及び補正（correction）モジュール８０７を含むソフトウェアモジュールを格納するために使用される。プロセッサ８０２は、これらのソフトウェアモジュールをメモリ８０３から読み出して実行することで、上述の実施形態において説明されたコントローラ４０の処理を行うことができる。

プロセッサ８０２は、制御モジュール８０４を読み出して実行することで、例えば、図６の制御部６０１の処理（又は図７のステップ７０１の処理）を行うことができる。プロセッサ８０２は、監視モジュール８０５を読み出して実行することで、トラフィック関連パラメータを監視し、トラフィック関連パラメータの変化を検出することができる。プロセッサ８０２は、補正モジュール８０７を読み出して実行することで、例えば、図６の第１補正部６０２及び第２補正部６０３の処理（又は図７のステップ７０２及び７０３の処理）を行うことができる。

図８を用いて説明したように、上述の実施形態に係るコントローラ４０が有するプロセッサは、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行するよう構成されてもよい。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、このプログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
上述の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。

さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）
制御装置であって、
メモリと、
前記メモリに結合され、複数のモジュールを実行するよう構成された少なくとも１つのプロセッサと、
を備え、
前記複数のモジュールは、
通信ネットワークを介して転送されるトラフィックフローにより要求されるQuality of Service（QoS）性能の目標値（setpoint）を達成するように、前記通信ネットワーク内のノードに供給されるための制御値を決定するよう構成された制御モジュールと、ここで、前記制御値は、前記トラフィックフローへのネットワークリソース割り当てを調整することを前記ノードに引き起こす；
前記トラフィックフローに関するトラフィック関連パラメータを監視するよう構成された監視モジュールと；
前記制御装置と前記ノードの間の制御遅延を取得するよう構成された取得モジュールと；
前記トラフィック関連パラメータの変化傾向及び前記制御遅延に基づいて、前記制御値を補正するよう構成された補正モジュールと、
を備える、制御装置。

（付記２）
前記補正モジュールは、前記ノードが前記制御値に基づいて動作する将来の時点における前記トラフィック関連パラメータの推定値に前記制御値を適合させるように前記制御値を補正するよう構成されている、
付記１に記載の制御装置。

（付記３）
前記補正モジュールは、
前記トラフィック関連パラメータの最新値に基づいて前記制御値を補正することによって、第１の補正された制御値を生成する第１の補正モジュールと、
前記制御遅延に基づいて前記第１の補正された制御値を補正することによって、第２の補正された制御値を生成する第２の補正モジュールと、
を備える、
付記１又は２に記載の制御装置。

（付記４）
前記第２の補正された制御値は、前記ノードが前記制御値に基づいて動作する将来の時点における前記トラフィック関連パラメータの推定値に対応する、
付記３に記載の制御装置。

（付記５）
前記取得モジュールは、前記制御遅延の変化を監視するよう構成され、
前記補正モジュールは、前記制御遅延の前記変化を考慮して、前記第２の補正された制御値を生成するよう構成されている、
付記３又は４に記載の制御装置。

（付記６）
前記トラフィック関連パラメータは、前記目標値を達成するための前記制御値の決定に影響を与えるパラメータである、
付記１～５のいずれか１項に記載の制御装置。

（付記７）
前記トラフィック関連パラメータは、通信イベント当たりのデータサイズ、通信イベントのデータレート、及び通信イベントの通信間隔のうち少なくとも１つに関する、
付記１～６のいずれか１項に記載の制御装置。

（付記８）
前記目標値は、前記トラフィックフローの送信エンドノード及び受信エンドノードの間のエンドツーエンド・レイテンシ、前記トラフィックフローの目標スループット、又は前記通信ネットワークに対する許容遅延である、
付記１～７のいずれか１項に記載の制御装置。

（付記９）
前記制御値は、前記トラフィックフローに対する保証Quality of service（QoS）である、
付記１～８のいずれか１項に記載の制御装置。

（付記１０）
前記保証QoSは、優先度、保証遅延、及び保証ビットレートのうち少なくとも１つを含む、
付記９に記載の制御装置。

（付記１１）
前記ノードは、前記通信ネットワーク内の無線アクセスネットワーク・ノード及び前記通信ネットワーク内のコアネットワーク・ノードのうち少なくとも１つを含む、
付記１～１０のいずれか１項に記載の制御装置。

（付記１２）
制御装置により行われる方法であって、
通信ネットワークを介して転送されるトラフィックフローにより要求されるQuality of Service（QoS）性能の目標値（setpoint）を達成するように、前記通信ネットワーク内のノードに供給されるための制御値を決定すること、ここで、前記制御値は、前記トラフィックフローへのネットワークリソース割り当てを調整することを前記ノードに引き起こす；
前記トラフィックフローに関するトラフィック関連パラメータを監視すること；
前記制御装置と前記ノードの間の制御遅延を取得すること；及び
前記トラフィック関連パラメータの変化傾向及び前記制御遅延に基づいて、前記制御値を補正すること、
を備える方法。

（付記１３）
前記補正することは、前記ノードが前記制御値に基づいて動作する将来の時点における前記トラフィック関連パラメータの推定値に前記制御値を適合させるように前記制御値を補正することを備える、
付記１２に記載の方法。

（付記１４）
前記補正することは、
前記トラフィック関連パラメータの最新値に基づいて前記制御値を補正することによって、第１の補正された制御値を生成すること、及び
前記制御遅延に基づいて前記第１の補正された制御値を補正することによって、第２の補正された制御値を生成すること、
を備える、
付記１２又は１３に記載の方法。

（付記１５）
前記第２の補正された制御値は、前記ノードが前記制御値に基づいて動作する将来の時点における前記トラフィック関連パラメータの推定値に対応する、
付記１４に記載の方法。

（付記１６）
前記取得することは、前記制御遅延の変化を監視することを備え、
前記第２の補正された制御値を前記生成することは、前記制御遅延の前記変化を考慮して、前記第２の補正された制御値を決定することを備える、
付記１４又は１５に記載の方法。

（付記１７）
前記トラフィック関連パラメータは、前記目標値を達成するための前記制御値の決定に影響を与えるパラメータである、
付記１２～１６のいずれか１項に記載の方法。

（付記１８）
前記トラフィック関連パラメータは、通信イベント当たりのデータサイズ、通信イベントのデータレート、及び通信イベント内での通信間隔のうち少なくとも１つに関する、
付記１２～１７のいずれか１項に記載の方法。

（付記１９）
前記目標値は、前記トラフィックフローの送信エンドノード及び受信エンドノードの間のエンドツーエンド・レイテンシ、前記トラフィックフローの目標スループット、又は前記通信ネットワークに対する許容遅延である、
付記１２～１８のいずれか１項に記載の方法。

（付記２０）
前記制御値は、前記トラフィックフローに対する保証Quality of service（QoS）である、
付記１２～１９のいずれか１項に記載の方法。

（付記２１）
前記保証QoSは、優先度、保証遅延、及び保証ビットレートのうち少なくとも１つを含む、
付記２０に記載の方法。

（付記２２）
前記ノードは、前記通信ネットワーク内の無線アクセスネットワーク・ノード及び前記通信ネットワーク内のコアネットワーク・ノードのうち少なくとも１つを含む、
付記１２～２１のいずれか１項に記載の方法。

（付記２３）
制御装置により行われる方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
通信ネットワークを介して転送されるトラフィックフローにより要求されるQuality of Service（QoS）性能の目標値（setpoint）を達成するように、前記通信ネットワーク内のノードに供給されるための制御値を決定すること、ここで、前記制御値は、前記トラフィックフローへのネットワークリソース割り当てを調整することを前記ノードに引き起こす；
前記トラフィックフローに関するトラフィック関連パラメータを監視すること；
前記制御装置と前記ノードの間の制御遅延を取得すること；及び
前記トラフィック関連パラメータの変化傾向及び前記制御遅延に基づいて、前記制御値を補正すること、
を備える、プログラム。

この出願は、２０１７年３月８日に出願された日本出願特願２０１７－０４４３２３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１０エンドノード
２０中間ノード
３０エンドノード
４０コントローラ
８０２プロセッサ
８０３メモリ
８０４制御モジュール
８０５監視モジュール
８０６取得モジュール
８０７補正モジュール

Claims

制御装置であって、
通信ネットワークを介して転送されるトラフィックフローに関するQuality of Service （QoS）性能の計測値を取得する手段と、
当該計測値をQoS性能の目標値と比較し、当該目標値を達成するように、前記通信ネットワーク内のノードに供給される制御値を生成する手段と、
前記トラフィックフローに関するトラフィック関連パラメータの変化傾向および当該制御装置と前記ノードとの間の制御遅延に基づいて、前記制御値を補正する手段と、
を備える、制御装置。
前記変化傾向は、時間変化を含む、請求項１に記載の制御装置。
前記制御装置は、サーバに配置される、請求項１または２に記載の制御装置。
前記制御装置は、Mobile Edge Computing（MEC）に配置される、請求項１～３のいずれかに記載の制御装置。
制御装置で行われる方法であって、
通信ネットワークを介して転送されるトラフィックフローに関するQuality of Service （QoS）性能の計測値を取得し、
当該計測値をQoS性能の目標値と比較し、当該目標値を達成するように、前記通信ネットワーク内のノードに供給される制御値を生成し、
前記トラフィックフローに関するトラフィック関連パラメータの変化傾向および当該制御装置と前記ノードとの間の制御遅延に基づいて、前記制御値を補正する、方法。
前記変化傾向は、時間変化を含む、請求項５に記載の方法。
前記制御装置は、サーバに配置される、請求項５または６に記載の方法。
前記制御装置は、Mobile Edge Computing（MEC）に配置される、請求項５～７のいずれかに記載の方法。