JP6856521B2 - 通信装置、通信システム及びプログラム - Google Patents

通信装置、通信システム及びプログラム Download PDF

Info

Publication number
JP6856521B2
JP6856521B2 JP2017252392A JP2017252392A JP6856521B2 JP 6856521 B2 JP6856521 B2 JP 6856521B2 JP 2017252392 A JP2017252392 A JP 2017252392A JP 2017252392 A JP2017252392 A JP 2017252392A JP 6856521 B2 JP6856521 B2 JP 6856521B2
Authority
JP
Japan
Prior art keywords
communication
delay
packet
token
function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017252392A
Other languages
English (en)
Other versions
JP2019118072A (ja
Inventor
達也 福井
達也 福井
康夫 小倉
康夫 小倉
康隆 木村
康隆 木村
勝也 南
勝也 南
裕透 古川
裕透 古川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2017252392A priority Critical patent/JP6856521B2/ja
Publication of JP2019118072A publication Critical patent/JP2019118072A/ja
Application granted granted Critical
Publication of JP6856521B2 publication Critical patent/JP6856521B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本開示は、2拠点間のパケット転送を行う際に、最短通信遅延と保証したい通信遅延に基づきシェーピング帯域を変化させる遅延保証シェーピング機能を安価に実現する手段を提供することで、通信ネットワーク(NW;NetWork)負荷を抑えながら通信遅延の保証をユーザに提供する通信装置、通信システム及びプログラムに関するものである。
近年、IPデータ通信だけではなくIoT(Internet of Things)/M2M(Machine to Machine)、4K/8K高精細映像配信サービス、オンラインゲーム等、多種多様なアプリケーションやサービスが急速に普及してきた。特にコンピュータなどの情報/通信機器だけでなく、世の中に存在する様々な「モノ」に通信機能を持たせ、相互に通信を行うことにより、自動認識、自動制御、遠隔計測などを行うIoTの普及は急速に進んでいる。
IoTの一例として、遠隔値で所定の物理量(電流、電圧、気圧、気温、水量、及び湿度等)を取得し、これらのデータをセンタ側で収集してビッグデータ解析を行い、解析結果に基づき機械の動作を自動的に制御するという通信シーンが考えられている。データ収集と遠隔制御を正確に行うためには、決められた時間内に正しく通信が完了することが非常に重要となる。例えば、データ収集とそれに基づく遠隔制御を50ms以内に実施するようなシステムを考えると、長くとも片道の通信遅延を25ms以内に抑える必要がある。
一方で、現在のベストエフォート通信サービスにおける2拠点間の通信遅延には大きな揺らぎが発生している。具体的には、通信環境が良好なときは2拠点間のパケット転送で発生する通信遅延が通信経路長や装置のスイッチング処理等で発生する最短通信遅延(輻輳等の変動的な要因による遅延を含まない遅延時間の理想値)とほぼ等しくなっているが、通信環境が劣悪なときは数100msレベルの非常に大きな通信遅延が発生したり、時にはパケットロスが発生してしまう。また、通信経路の変更などにより、最短通信遅延が変動する場合もある。このような通信サービスは、前述のIoTにおける通信シーンに適しているとはいえない。したがって、2拠点間のパケット転送で発生する通信遅延を一定時間以内にする通信遅延保証サービスを安価に実現することが求められている。
高信頼かつ低遅延な通信を提供するサービスの一つとして、非特許文献1に示すような帯域制御と優先制御を利用した帯域優先サービスがある。非特許文献1では、ある決められた帯域のパケットに優先クラス情報を付与し、通信NW内を他のベストエフォート通信よりも優先的に転送させることで、2拠点間のパケット転送で発生する通信遅延を、通信経路長や装置のスイッチング処理、パケット合流等で発生する最短通信遅延のみにすることができる。
帯域優先サービスの拡張として、特許文献1に示すような優先的に利用する帯域を動的に変更する動的優先帯域制御がある。特許文献1では、優先クラスで輻輳が発生してもバッファのキュー長がしきい値を超えた場合に利用できる帯域を拡大することで、2拠点間のパケット転送の低遅延性を維持できる。
特開2002−344509号公報
フレッツ光ネクストプライオサービス内容(https://flets.com/next/bs/prio/)、2017年2月27日検索
安価な通信サービスを実現するためには、利用ユーザあたりの通信NWへの負荷を小さくすればよい。しかし、先行技術文献の方法では、通信遅延を一定時間以内にしながら、通信NWへの負荷を小さくすることができない。
具体的には、非特許文献1のサービスの場合、優先的に利用できる帯域が制限されているため、通信遅延を一定時間以内にできない可能性がある。たとえば、20KBのデータを1Mbpsの帯域にシェーピングして転送しようとすると、最短通信遅延に加えて、160msもの遅延が新たに発生してしまう。バースト転送を許容し、帯域制限をポリシングで行えば通信遅延を最短通信遅延とほぼ等しくすることが可能となるが、その場合にはバーストトラヒックによる通信NWへの負荷が高まってしまう。
また、特許文献1の機能を利用した場合、優先的に利用する帯域を拡大することができるので通信遅延の増加を抑えることが可能になるが、最短通信遅延に関する考慮がないため、保証したい遅延時間を適切に守る方法がない。例えば、最短通信遅延が1msで保証したい通信遅延が15msであるような通信シーンの場合、14msの通信遅延の発生までは許容されているが、輻輳が発生しなければ最短通信遅延で転送するため、本来の要求条件よりもオーバースペックな通信サービスを提供することになってしまい、結果的に通信NWへの負荷が大きなものとなってしまう。
上記の課題を解決するために最短通信遅延と保証したい通信遅延に基づきシェーピング帯域を動的に変化させる動的シェーピング機能を具備することで、通信NW負荷を抑えながら通信遅延の保証をユーザに提供する方法(例えば、特願2017−042969)も考えられる。しかし、このような動的シェーピング機能は一般的なシェーピング部とは全く異なる動作となることから、当該機能を始めから作り込む必要がある。このため、動的シェーピング機能には、通信遅延保証サービスユーザ専用に当該機能を作り込んだ場合、コストが高価となり、通信遅延保証サービスを安価に実現することができなくなるという第1の課題がある。
また、動的シェーピング機能を採用した場合でも、予め設定した通信遅延に基づき制御を行ってしまうと、通信経路の変更などにより、最短通信遅延が変動する場合、通信遅延保証が実現できなくなるという第2の課題もある。
さらに、動的シェーピング機能は、遅延時間の上限を保証できるものの、遅延時間の下限を保証することはできない。ユーザによってはある程度の通信遅延が前提となっている場合があり、このようなユーザーに対して通信遅延が前提より短いと不具合が発生することがある。すなわち、動的シェーピング機能には、ある程度の通信遅延が前提であるユーザへの対応がなされていないという第3の課題もある。
そこで、本発明は、上記課題を解決するために、通信経路が変動する環境において2拠点間のパケット転送で発生する通信遅延をある一定の時間範囲以内にする遅延保証通信サービスを、一般的なシェーピング部の機能を流用して実現することができる通信装置、通信システム及びプログラムを提供することを目的とする。
上記目的を達成するために、本発明に係る通信装置は、入力トラヒック量、通信ネットワークの遅延時間及び要求遅延時間(通信フローが保証する通信遅延時間)に基づいて、トークンアルゴリズムで実装されたシェーピング部に供給するトークンの供給量をトークン供給関数を用いて動的に制御することとした。
具体的には、本発明に係る通信装置は、ユーザ装置から入力されたパケットをトークンバケットアルゴリズムで通信ネットワークへ転送するシェーピング機能と、前記シェーピング機能に供給されるトークンの量を通信フロー毎のトークン供給関数に従って動的に変化させるトークン供給量制御機能と、を備える。
例えば、本発明に係る通信装置の前記トークン供給量制御機能は、所定期間毎に、前記入力されたパケットの量、前記入力されたパケットの転送先までの前記通信ネットワークの遅延時間、及び前記入力されたパケットの通信フローが保証する通信遅延時間に基づきトークンの量と供給期間を計算し、トークン供給関数の更新を行うことを特徴とする。
本通信装置は、従来のシェーピング機能を利用し、状況に応じてトークンの量を動的に変動させて通信遅延を調整することができる。つまり、本通信装置は、新たに上述したような動的シェーピング機能を造り込む必要が無く、通信遅延保証サービスを安価に実現することができる。従って、本通信装置は、上記第1の課題を解決できる。
本発明に係る通信装置は、入力されるパケット量の変動に対して、次のように対応する。
前記トークン供給量制御機能は、前記トークン供給関数の更新において、
1の所定期間における前記入力されたパケットの量で計算したトークンの1の供給期間と、前記1の所定期間の後の所定期間における前記入力されたパケットの量で計算したトークンの後の供給期間とが重複する場合、前記1の供給期間と前記後の供給期間が重複する期間において、前記1の所定期間における前記入力されたパケットの量で計算したトークンの量に前記後の所定期間における前記入力されたパケットの量で計算したトークンの量を加算することを特徴とする。
なお、本発明に係る通信装置は、設定されている前記通信ネットワークの遅延時間と前記入力されたパケットの通信フローが保証する通信遅延時間の少なくとも一方をパケット転送中に更新する設定値更新機能をさらに備えてもよい。
本発明に係る通信装置は、最短通信遅延の変動に対して、次のように対応する。本通信装置は、遅延測定パケットを前記通信ネットワークへ送出し、前記遅延測定パケットに対する応答から前記通信ネットワークの遅延時間を更新する通信遅延測定機能をさらに備える。そして、前記トークン供給量制御機能は、前記通信遅延測定機能が前記通信ネットワークの遅延時間を更新することで、前記入力されたパケットのうち通信フローが保証する通信遅延時間内に転送できないパケットが存在する場合、前記転送できないパケットに相当するトークンの量を算出し、前記トークン供給関数に加算することを特徴とする。本通信装置は、通信経路の遅延をモニタし、モニタ結果に応じてトークン量を変動させる。従って、本通信装置は、上記第2の課題を解決できる。
本発明に係る通信装置は、ある程度の通信遅延が前提であるユーザに対して、次のように対応する。前記通信遅延時間に上限値と下限値が設定されており、前記下限値が前記通信ネットワークの遅延時間、前記所定期間及び前記トークン供給関数の更新の反映時間の合計より大きい場合、前記トークン供給量制御機能は、
前記1の供給期間及び前記後の供給期間を前記上限値と前記下限値の差分とするとともに、前記下限値と前記通信ネットワークの遅延時間から待ち時間を決定し、前記待ち時間だけ前記シェーピング機能へのトークンの供給を遅らせる。
本通信装置は、ネットワークの遅延時間が要求遅延時間の下限より短い場合、要求遅延時間の上限を超えない範囲で遅延を発生させるようにトークン量を調整する。従って、本通信装置は、上記第3の課題を解決できる。
本発明に係るプログラムは、コンピュータを前記通信装置として機能させるためのプログラムである。本発明に係る通信装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
なお、上記各発明は、可能な限り組み合わせることができる。
本発明は、通信経路が変動する環境において2拠点間のパケット転送で発生する通信遅延をある一定の時間範囲以内にする遅延保証通信サービスを、一般的なシェーピング部の機能を流用して実現することができる通信装置、通信システム及びプログラムを提供することができる。
本発明に係る通信システム及び通信装置を説明する図である。 本発明に係る通信装置が有するフロー情報テーブルを説明する図である。 本発明に係る通信装置が有するトークン供給動作設定テーブルを説明する図である。 本発明に係る通信装置が有する遅延情報テーブルを説明する図である。 本発明に係る通信装置が行う設定処理フローを説明する図である。 本発明に係る通信装置が行う静的動作設定処理フローを説明する図である。 本発明に係る通信装置のトークン供給関数計算部が行う通信フロー毎トークン供給関数更新処理フローを説明する図である。 本発明に係る通信装置のトークン供給部が行う通信フロー毎トークン供給処理フローを説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信システム及び通信装置を説明する図である。 本発明に係る通信装置が有する遅延測定動作設定テーブルを説明する図である。 本発明に係る通信装置が行う設定処理フローを説明する図である。 本発明に係る通信装置が行う静的動作設定処理フローを説明する図である。 本発明に係る通信装置が行う測定対象装置毎遅延測定パケット送信処理フローを説明する図である。 本発明に係る通信装置が行う遅延測定パケット受信処理フローを説明する図である。 本発明に係る通信装置が行う測定区間毎遅延測定結果書換処理フローを説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信装置が有する遅延情報テーブルを説明する図である。 本発明に係る通信装置が行う通信フロー毎トークン供給関数補正処理フローを説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信装置が有するフロー情報テーブルを説明する図である。 本発明に係る通信装置のトークン供給関数計算部が行う通信フロー毎トークン供給関数更新処理フローを説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信装置の動作を説明する図である。 本発明に係る通信装置のトークン供給関数計算部が計算するトークン供給関数を説明するイメージ図である。 本発明に係る通信装置のトークン供給関数計算部が計算するトークン供給関数を説明するイメージ図である。
添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
(実施形態1)
図1は、本実施形態の通信システム301を説明する構成図である。通信システム301は、通信NW3に接続された通信装置(ユーザ収容装置1)と、前記通信装置を介して、通信NW3へ送信パケットを送信し、他のユーザ装置2(b、c、d)が送信した送信パケットを通信NW3から受信するユーザ装置2(a)と、を備え、送信パケットのフロー毎にトークンバケットアルゴリズムで実装されたシェーピング部に供給されるトークン量が動的に変動する通信システムである。
通信システム301は、一般的な通信装置に具備されているシェーピング機能、トークン供給機能、メータリング機能、及びトークン供給量制御機能のうち、トークン供給量制御機能に動的制御性を持たせることと、トークン供給機能にトークン供給量制御機能の制御に従ってトークンを供給する機能を持たせることの2点の機能追加で実現できる。従って、通信システム301は、一般的な通信装置を利用して遅延保証通信サービスを安価に実現することができる。
通信システム301は、ユーザ装置2がユーザ収容装置1によって通信NW3に接続されることによって実現される通信システムである。このような通信システムにおいて、それぞれのユーザ装置2は、ユーザ収容装置1と通信NW3を介して互いに通信を行うことが可能となっている。図中の実線矢印はパケット転送の流れ、破線矢印は制御情報の流れを示している。
ユーザ収容装置1は、通信装置であって、
ユーザ装置2から入力されたパケットをトークンバケットアルゴリズムで通信ネットワーク3へ転送するシェーピング機能と、
前記シェーピング機能に供給されるトークンの量を通信フロー毎のトークン供給関数Ts(t)に従って動的に変化させるトークン供給量制御機能と、
を備える。
前記トークン供給量制御機能は、
所定期間毎に、前記入力されたパケットの量、前記入力されたパケットの転送先までの通信ネットワーク3の遅延時間、及び前記入力されたパケットの通信フローが保証する通信遅延時間に基づきトークンの量と供給期間を計算し、トークン供給関数Ts(t)の更新を行う。具体的には、トークン供給関数計算部108が、予め与えられた通信経路の遅延情報に基づき前記送信パケットの転送先までの最短通信遅延を計算し、前記送信パケットのデータ量のメータリング結果と前記最短通信遅延と保証したい通信遅延時間に基づき、トークンバケットアルゴリズムで実装されたシェーピング部105に供給されるトークン量を制御するためのトークン供給関数Ts(t)を生成する。そして、トークン供給部109が当該トークン供給関数Ts(t)に従いシェーピング部105にトークンを供給する。
ユーザ収容装置1は、ユーザ装置2から送信された送信パケットを通信NW3に送信する送信部100と、通信NW3から転送される受信パケットをユーザ装置2に送信する受信部200と、を備える。ここで、ユーザ収容装置1はOLT(Optical Line Terminal)のような局内終端装置でもよいし、ユーザを収容するスイッチやルータのような通信装置でもよい。
送信部100は、
ユーザ装置2から送信された送信パケットを受信するユーザ側受信部101と、
送信パケットが通信NW3で優先的に転送されるように優先クラス情報を付与する優先情報付与部102と、
フロー情報テーブル110の情報に基づき送信パケットを通信フロー毎にシェーピング部105に振り分けるフロー分離部103と、
シェーピング部105に振り分けられたパケットをバイト量としてカウントしてトークン供給関数計算部108に通知するメータリング部104と、
トークンバケットアルゴリズムで実装されておりトークン供給部109から供給されるトークン量に基づきシェーピングを行いスケジューラ106にパケットを送信するシェーピング部105と、
シェーピング部105から送信されたパケットをフロー情報テーブル110の情報に基づき、Strict Priorityのようなスケジューリング規範でパケットを合流・スケジューリングするスケジューラ106と、
送信パケットを通信NW3に転送するNW側送信部107と、
トークン供給部109がシェーピング部105に供給するトークン量を示すトークン供給量関数Ts(t)を更新してトークン供給部109に設定するトークン供給関数計算部108と、
設定されたTs(t)に従いシェーピング部105にトークン供給を行うトークン供給部109と、
フロー毎の通信情報が記載されたフロー情報テーブル110と、
トークン供給関数計算部108とトークン供給部109の動作設定が記載されたトークン供給動作設定テーブル111と、
通信システム全体の遅延情報が記載された遅延情報テーブル112と、
を備える。
受信部200は、
通信NW3から転送される受信パケットを受信するNW側受信部201と、
受信パケットに付与されている優先クラス情報を削除する優先情報削除部202と、
受信パケットをユーザ装置2に送信するユーザ側送信部203と、
を備える。
ユーザ装置2は、ユーザが所有する装置であり、発生した送信したいデータを送信パケットとしてユーザ収容装置1に送信し、他方のユーザ装置2から送信された送信パケットをユーザ収容装置1から受信パケットとして受信する機能を有する。ここで、ユーザ装置2はサーバのような端末装置でもよいし、ユーザ宅内におかれるブロードバンドルータや、ONU(Optical Network Unit)のような終端装置でもよい。
通信NW3は、ユーザ収容装置1から送信された送信パケットに優先クラス情報が付与されている場合には、付与されているクラス情報に従って優先転送することにより、NWの輻輳による遅延増加を発生させずに他方のユーザ収容装置1に送信する機能を有する。
図2は、通信装置1が有するフロー情報テーブル110の内容を示したものである。フロー情報テーブル110は、通信フローの通番を示す通信フロー番号と、通信フローを識別するためのパケット情報を示す通信フロー識別子と、当該通信フローがどのユーザ収容装置に転送されるのかを示す転送先収容装置と、当該フローのNW内優先度と、通信フロー毎の要求遅延時間(通信フローが保証する通信遅延時間)と、で成り立っている。
図3は、通信装置1が有するトークン供給動作設定テーブル111の内容を示したものである。トークン供給動作設定テーブル111は、トークン供給周期とトークン供給関数更新周期とトークン供給関数反映周期という3つのパラメータで成り立っている。
図4は、通信装置1が有する遅延情報テーブル112の内容を示したものである。遅延情報テーブル112は、区間種類を示す区間種別と、具体的な区間箇所を示す区間名と、区間名に示す箇所において通信経路長や装置のスイッチング処理、パケット合流等で発生する最短通信遅延を意味する区間遅延情報と、で成り立っている。
図5は、通信装置1における設定処理フロー(S100)を示したものである。予めユーザから受領したフロー情報をフロー情報テーブル110に登録する(ステップS101)。予め装置の計算能力や搭載チップ性能などから設計したトークン供給周期とトークン供給関数更新周期とトークン供給関数反映周期をトークン供給動作設定テーブル111に登録する(ステップS102)。予め測定または仕様や物理的距離から設計した通信NW3内の区間別の遅延情報を遅延情報テーブル112に登録する(ステップS103)。本設定処理フローは、ユーザ収容装置1に対して、コンソール接続などを行って直接入力してもよいし、通信NW3を介してオペレーションシステムやコントローラ等から遠隔設定しても構わない。
図6は、通信装置1における静的動作設定処理フロー(S110)を示したものである。フロー情報テーブル110の情報に基づき、優先情報付与部102におけるパケットへの優先情報の付与動作を設定する(ステップS111)。S111の具体的な動作としては、通信フロー識別子に記載されている識別子を有するパケットに対して、パケットのCoS(Class of Service)領域やToS(Type of Service)領域の値を設定することを一例として想定している。フロー情報テーブル110の情報に基づき、フロー分離部103におけるフロー分離動作を設定する(ステップS112)。S112の具体的な動作としては、通信フロー識別子に記載されている識別子を有するパケットをどのシェーピング部105に振り分けるかを設定することを想定している。トークン供給動作設定テーブル111の情報に基づき、トークン供給関数計算部108におけるトークン供給関数更新周期を設定する(ステップS113)。トークン供給動作設定テーブル111の情報に基づき、トークン供給部109におけるトークン供給周期を設定する(ステップS114)。
図7は、通信装置1のトークン供給関数計算部108が実行する通信フロー毎トークン供給関数Ts(t)更新処理フロー(S120)を示したものである。通信装置2の前記トークン供給量制御機能は、
前記トークン供給関数の更新において、
1の所定期間における前記入力されたパケットの量で計算したトークンの1の供給期間と、前記1の所定期間の後の所定期間における前記入力されたパケットの量で計算したトークンの後の供給期間とが重複する場合、前記1の供給期間と前記後の供給期間が重複する期間において、前記1の所定期間における前記入力されたパケットの量で計算したトークンの量に前記後の所定期間における前記入力されたパケットの量で計算したトークンの量を加算する。
本更新処理は、トークン供給動作設定テーブル111に設定されているトークン供給関数更新周期毎に実行する。今回処理実行時刻をt_now、現在のトークン供給関数をnow_Ts(t)、前回処理実行時から今回処理実行時までにメータリング部104から通知されたバイト量の合計をBm、トークン供給動作設定テーブル111に記載されているトークン供給周期をTc、トークン供給関数更新周期をTu、トークン供給関数反映周期をTr、フロー情報テーブル110に記載されている対象通信フローの要求遅延時間をDd、遅延情報テーブル112を用いて計算された対象通信フローの通信経路の遅延時間をDrとする(ステップS121)。
要求遅延を満足しながら追加できる遅延時間であるDaを次の式で計算する(ステップS122)。
Da=Dd−Dr−Tu−Tr
今回の処理実行で追加するトークン供給関数add_Ts(t)を次の式で計算する(ステップS123)。
(1)tがt_now+Tr<t≦t_now+Tr+Daの場合
add_Ts(t)=(Bm/Da)×Tc
(2)上記以外のtの場合
add_Ts(t)=0
add_Ts(t)が小数となっている場合には、add_Ts(t)の合計値がBmと等しくなるように切り上げ又は切り捨てなどの正規化を行う(ステップS124)。今回の処理実行でTs(t)として更新するトークン供給関数new_Ts(t)を次の式で計算する(ステップS125)。
new_Ts(t)=now_Ts(t)+add_Ts(t)
new_Ts(t)をt=t_now+Tr以降の新たなTs(t)としてトークン供給部109に設定する(ステップS126)。
図8は、通信装置1のトークン供給部109が実行する通信フロー毎トークン供給処理フロー(S130)を示したものである。本更新処理は、トークン供給動作設定テーブル111に設定されているトークン供給周期毎に実行する。処理実行時刻をt_nowとする(ステップS131)。t=t_nowにおけるTs(t)の値の量のトークンを当該通信フローのシェーピング部105に供給する(ステップS132)。
図9から図10は、通信装置1の動作例を示したものである。各テーブルの設定は図2から図4のものを利用しており、ここでは図2の保証したい要求遅延=10[ms]である通信フロー番号1の通信を例として説明する。なお、通信フロー番号1のパケットは、t=0〜0.5[ms]の間に、パケット群Paとして1000bytesのパケット4つと500bytesのパケット8つが到来し、t=1.0〜1.5の間に、パケット群Pbとして1500bytesと1000bytesのパケットの組が4つ到来するとする。
まず、t=0〜0.5の間に到来したパケット群Paは、シェーピング部105に送信され、シェーピング部105が有するバッファに格納される。また、送信されると同時にパケット量がメータリング部104でカウントされ、8000[bytes]がトークン供給関数計算部108に通知される。t=0.5[ms]において、最初の通信フロー毎トークン供給関数Ts(t)更新処理が実行され、図7のフローS120の通りに実行されてTs(t)が次のように更新される。
Ts(t)=200[bytes] {1.0<t≦5.0の場合}
続いて、t=1.0[ms]においてTs(t)が反映され、t=1.1からは200[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。また、t=1.0[ms]において、通信フロー毎トークン供給関数Ts(t)更新処理が実行されるが、Bm=0のため、Ts(t)は変更されない。
t=1.0〜1.5の間に到来したパケット群Pbは、シェーピング部105に送信され、シェーピング部が有するバッファに格納される。また、送信されると同時にパケット量がメータリング部104でカウントされ、10000[bytes]がトークン供給関数計算部108に通知される。t=1.5[ms]において、通信フロー毎トークン供給関数Ts(t)更新処理S120の通りに実行されてTs(t)が次のように更新される。
Ts(t)=200[bytes] {1.0<t≦2.0の場合}
=450[bytes] {2.0<t≦5.0の場合}
=250[bytes] {5.0<t≦6.0の場合}
t=1.5[ms]では、シェーピング部に溜まったトークン量が1000[bytes]となるので、シェーピング部から1000[bytes]のパケットが1つ送出され、溜まったトークン量が0となる。当該パケットは、シェーピング部での待ち時間1.5[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計5[ms]の合算値である6.5[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。以降、トークンが溜まる毎にシェーピング部からはパケットが順次送信される。
t=2.0[ms]において、Ts(t)が反映され、t=2.1[ms]からは450[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。以降、パケットが到来しないので、Ts(t)の更新は行われない。
t=3.4[ms]では、パケット群Paの送信がすべて完了する。パケット群Paの最後のパケットは、シェーピング部での待ち時間3.4[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計5[ms]の合算値である8.4[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
t=5.1[ms]からは250[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=6.0[ms]では、パケット群Pbの送信がすべて完了する。パケット群Pbの最後のパケットは、シェーピング部での待ち時間5.0[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計5[ms]の合算値である10.0[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
図28は、上記例においてトークン供給関数計算部108が計算したトークン供給関数Ts(t)を説明するイメージ図である。トークン供給関数計算部108はトークン供給部109に対して、1.0<t≦2.0ではパケット群Paに対するトークンのみをシェーピング部105へ供給するよう、2.0<t≦5.0ではパケット群Paに対するトークンとパケット群Pbに対するトークンの合計をシェーピング部105へ供給するよう、5.0<t≦6.0ではパケット群Pbに対するトークンのみをシェーピング部105へ供給するようなトークン供給関数Ts(t)を生成する。
以上のように、トークン供給関数計算部108が計算したトークン供給関数Ts(t)を用いることで、通信装置1は要求遅延に対する遅延保証を実現できていることがわかる。
本実施形態では、設定処理S100のステップS101において、フロー情報テーブルの要求遅延時間の値を運用前に一度だけ設定する例を説明したが、ユーザ収容装置にフロー情報テーブル書換API(Application Programming Interface)を設け、API経由でフロー情報テーブルの要求遅延時間の値を運用中に書き換える動作を行うことも可能である。
また、設定処理S100のステップS103において、通信NW3内の区間別の遅延情報を運用前に遅延情報テーブルに登録する例を説明したが、後述するように通信遅延測定機能を利用して通信NW3内の区間別の遅延情報を取得し、遅延情報テーブルの遅延情報を運用中に書き換える動作を行ってもよい。
(実施形態2)
図11は、本実施形態の通信システム302を説明する構成図である。通信システム302は、通信NW3に接続された通信装置(ユーザ収容装置1)と、前記通信装置を介して、通信NW3へ送信パケットを送信し、他のユーザ装置2(b、c、d)が送信した送信パケットを通信NW3から受信するユーザ装置2(a)と、を備え、送信パケットのフロー毎にトークンバケットアルゴリズムで実装されたシェーピング部に供給されるトークン量が動的に変動する通信システムである。通信システム302は、通信システム301に加えて、ユーザ収容装置間の遅延時間の変動を検知する機能を設け、検知した遅延時間変動を反映した上でトークン供給量を動的に制御する。従って、通信システム302は、通信経路が変動する環境下においても遅延保証通信サービスを提供する通信装置を安価に実現することができる。
通信システム302は、ユーザ装置2がユーザ収容装置1によって通信NW3に接続されることによって実現される通信システムである。このような通信システムにおいて、それぞれのユーザ装置2は、ユーザ収容装置1と通信NW3を介して互いに通信を行うことが可能となっている。図中の実線矢印はパケット転送の流れ、破線矢印は制御情報の流れ、太い波線矢印はユーザ収容装置内の遅延測定パケット転送の流れを示している。
ユーザ収容装置1は、通信装置であって、図1のユーザ収容装置1に対し、遅延測定パケットを前記通信ネットワークへ送出し、前記遅延測定パケットに対する応答から前記通信ネットワークの遅延時間を更新する通信遅延測定機能をさらに備える。
以下、実施形態1からの変更部分に絞って説明する。
送信部100は、実施形態1に加えて
(a)他ユーザ収容装置に対して遅延測定パケットを送信する機能、
(b)他ユーザ収容装置から送信された遅延測定パケットを受信して遅延測定パケットの応答を送信する機能、
(c)自ユーザ収容装置が送信して他ユーザ収容装置が応答した遅延測定パケットの応答を抽出してその情報からユーザ収容装置間の通信遅延を測定する機能、及び
(d)測定した通信遅延に基づき遅延情報テーブル112を書き換える機能
を有する遅延測定部113と、
遅延測定部113の動作設定が記載されている遅延測定動作設定テーブル114と、
を具備している。
受信部200は、実施形態1に加えて
他ユーザ収容装置から送信された遅延測定パケットと自ユーザ収容装置が送信して他ユーザ収容装置が応答する遅延測定パケットの応答を遅延測定部113に送信する遅延測定パケット抽出部204を具備している。
図12は、通信装置1(ユーザ収容装置#A)における遅延測定動作設定テーブル114の内容を示したものである。遅延測定動作設定テーブル114は、ユーザ収容装置#Aの遅延測定部113が遅延時間を測定する対象装置を示す測定対象装置名と、遅延測定部113が送信する遅延測定パケットの遅延測定パケット送信周期と、遅延測定部113が遅延測定結果をトークン供給関数計算部108に通知する際の通知内容を示す測定結果集約方法と、遅延測定部113が遅延測定結果を遅延情報テーブル112に書き換える周期である測定結果書換周期と、測定パケットの内容を示す測定パケット内容と、で成り立っている。測定結果集約方法は、図12に記載のように前回通知時からの最大値を通知してもよいし、前回通知時からの平均値を通知するなどすればよい。
本実施形態でのフロー情報テーブル110、トークン供給動作設定テーブル111、及び遅延情報テーブル112の内容は、それぞれ図2、図3及び図4と同様である。
図13は、通信装置1における設定処理フロー(S200)を示したものである。ステップS201〜203は図5のステップS101〜103と同様である。予め設計した遅延測定パケット送信周期と遅延測定結果集約方法と遅延測定結果書換周期と遅延測定パケット内容を遅延測定動作設定テーブル114に登録する(ステップS204)。本設定処理フローは、ユーザ収容装置1に対して、コンソール接続などを行って直接入力してもよいし、通信NW3を介してオペレーションシステムやコントローラ等から遠隔設定しても構わない。
図14は、通信装置1における静的動作設定処理フロー(S210)を示している。ステップS211〜214は図6のステップS111〜114と同様である。遅延測定動作設定テーブル114の情報に基づき、遅延測定部113における測定区間と測定パケット周期と測定結果集約方法と測定結果書換周期と測定パケット内容を設定する(ステップS215)。
図15は、通信装置1の遅延測定部113が実行する測定対象装置毎遅延測定パケット送信処理フロー(S220)を示している。本処理は、遅延測定動作設定テーブル114に設定されている遅延測定パケット送信周期毎に実行する。遅延測定動作設定テーブル114の記載に基づき、測定対象装置名に記載された対象装置を宛先として、測定パケット内容に記載された内容の遅延測定パケットを生成してスケジューラ106に挿入する(ステップS221)。遅延測定パケットの形式はRFC792に記載されているICMP(Internet Control Message Protocol)や、ITU−T Y.1731に記載されているETH−OAM(Operation、Administration、Maintenance)を想定している。
図16は、通信装置1の遅延測定パケット抽出部204と遅延測定部113が実行する遅延測定パケット受信処理フロー(S230)を示している。本処理は、遅延測定パケットを遅延測定パケット抽出部204で受信した際に実行される。遅延測定パケット抽出部204は、遅延測定部113に当該パケットを送信する(ステップS231)。遅延測定部113は、当該パケットは自ユーザ収容装置が送信した遅延測定パケットの応答かどうかを判断する(ステップS232)。もし自ユーザ収容装置が送信した遅延測定パケットの応答であった場合には、遅延測定パケットの応答を利用してユーザ収容装置間の片道遅延を算出する(ステップS233)。一例として、Ping応答が返ってきたときに往復遅延がわかるので、それを2で除算することにより片道遅延を算出することができる。ステップS232においてもし自ユーザ収容装置が送信した遅延測定パケットの応答でなかった場合には、受信した遅延測定パケットの応答パケットを生成してスケジューラ106に送信する(ステップS234)。
図17は、通信装置1の遅延測定部113が実行する測定区間毎遅延測定結果書換処理フロー(S240)を示している。遅延測定パケット受信処理で算出したユーザ収容装置1間の片道遅延を、遅延測定結果集約方法に記載された規範に基づきマージし、遅延情報テーブル112に通知する(ステップS241)。
本実施形態でのトークン供給関数計算部108が実行する通信フロー毎トークン供給関数Ts(t)更新処理フローは図7で示したフローS120と同一である。
図18から図19は、通信装置1の動作例を示したものである。各テーブルの設定は図2から図4、図12及び図13のものを利用しており、ここでは図2の保証したい要求遅延=10[ms]である通信フロー番号1の通信を例として説明する。なお、通信フロー番号1のパケットは、t=0〜0.5[ms]の間にパケット群Paとして1000bytesのパケット4つと500bytesのパケット8つが到来し、t=1.0〜1.5の間にパケット群Pcとして1500bytesのパケットが6つ到来するとする。また、ユーザ収容装置1間の通信NW3の遅延時間は、設定値上は3[ms]であるものの、実際にはt=0.0[ms]以前に4.0[ms]に変化しているものとし、t=1.7[ms]と1.8[ms]の間に遅延測定部113がユーザ収容装置1間の通信NW3の遅延時間変化を検知した場合を想定している。
まず、t=0〜0.5の間に到来したパケット群Paは、シェーピング部105に送信され、シェーピング部105が有するバッファに格納される。また、送信されると同時にパケット量がメータリング部104でカウントされ、8000[bytes]がトークン供給関数計算部108に通知される。t=0.5[ms]において、測定区間毎遅延測定結果書換処理S240が実施され、遅延測定部113からユーザ収容装置#A〜ユーザ収容装置#B間の通信遅延が3.0[ms]であることが遅延情報テーブル112に通知されるが、同じ値であるため書換えが発生してもテーブルの値は変わらない。さらに同時刻において、最初の通信フロー毎トークン供給関数Ts(t)更新処理が実行され、フローS120の通りに実行されてTs(t)が次のように更新される。
Ts(t)=200[bytes] {1.0<t≦5.0の場合}
続いて、t=1.0[ms]においてTs(t)が反映され、t=1.1からは200[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。また、t=1.0[ms]において、遅延測定部113からの通信遅延通知と通信フロー毎トークン供給関数Ts(t)更新処理S120が実行されるが、Bm=0のため、Ts(t)は変更されない。また、t=1.0[ms]において、測定区間毎遅延測定結果書換処理S240が実施され、遅延測定部113からユーザ収容装置#A〜ユーザ収容装置#B間の通信遅延が3.0[ms]であることが遅延情報テーブル112に通知されるが、同じ値であるため書換えが発生してもテーブルの値は変わらない。
t=1.5[ms]において、シェーピング部に溜まったトークン量が1000[bytes]となるので、シェーピング部から1000[bytes]のパケットが1つ送出され、溜まったトークン量が0となる。当該パケットは、シェーピング部での待ち時間1.5[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計6[ms]の合算値である7.5[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。以降、トークンが溜まる毎にシェーピング部からはパケットが順次送信される。
また、t=1.5[ms]において、通信フロー毎トークン供給関数Ts(t)更新処理と測定区間毎遅延測定結果書換処理が発生するが、状況の変化が無いため説明は割愛する。
t=1.5〜2.0[ms]の間に到来したパケット群Pcは、シェーピング部105に送信され、シェーピング部105が有するバッファに格納される。また、送信されると同時にパケット量がメータリング部でカウントされ、9000[bytes]がトークン供給関数計算部108に通知される。
t=1.7〜1.8[ms]の間には、遅延測定部113がユーザ収容装置1間の通信NW3の遅延時間が3.0[ms]から4.0[ms]に変化したことを、遅延測定パケット受信処理によって検知する。
t=2.0[ms]において、測定区間毎遅延測定結果書換処理S240が実施され、遅延測定部113からユーザ収容装置#Aからユーザ収容装置#B間の通信遅延が4.0[ms]であることが遅延情報テーブル112に通知されて、テーブルの内容が書き換わる。書き換わった後の遅延情報テーブル112を図20に示す。
次に、t=2.0[ms]において、通信フロー毎トークン供給関数Ts(t)更新処理S120が実行され、Ts(t)が次のように更新される。
Ts(t)=200[bytes] {1.0<t≦2.5の場合}
=500[bytes] {2.5<t≦5.0の場合}
=300[bytes] {5.0<t≦6.0の場合}
t=2.1[ms]以降では、パケットの到来および遅延時間変化の検知がされないので、測定区間毎遅延測定結果書換処理と通信フロー毎トークン供給関数Ts(t)更新処理が発生してもトークン供給関数Ts(t)は変わらない。
t=2.6[ms]からは、500[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=3.5[ms]では、パケット群Paの送信がすべて完了する。パケット群Paの最後のパケットは、シェーピング部での待ち時間3.5[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計6[ms]の合算値である9.5[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
t=5.1[ms]からは300[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=5.5[ms]では、パケット群Pcの送信がすべて完了する。パケット群Pcの最後のパケットは、シェーピング部での待ち時間4.0[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計6[ms]の合算値である10.0[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
以上の通り、本実施形態の通信システム302によって、遅延時間が変化する場合においても、要求遅延に対する遅延保証を実現できていることがわかる。
本実施形態では、ユーザ収容装置間の遅延時間変動を遅延測定機能で測定し、遅延情報テーブルを書き換える方法を採ったが、遅延時間変動を検知する対象区間や検知方法については限定していない。たとえば、アクセス区間の遅延時間変動をも検知する形態としても構わない。また、遅延測定機能を外部に設置し、ユーザ収容装置に遅延情報テーブル書換APIを設け、API経由で遅延情報テーブルの値を書き換えることにより遅延時間変動を検知する形態を採っても構わない。さらに、遅延情報テーブルの値のみならず、ユーザ収容装置にフロー情報テーブル書換APIを設け、API経由でフロー情報テーブルの要求遅延時間の値を運用中に書き換える動作を組み合わせることも可能である。
(実施形態3)
本実施形態の通信システム303の構成は、図11と同じ構成である。通信システム303は、通信システム302に加えて、検知した遅延時間変動を反映した上で既に決定済みのトークン供給量を動的に補正する。従って、通信システム303は、通信経路が変動する環境下においても遅延保証通信サービスを提供する通信装置を安価に実現することが可能となる。
通信装置1の前記トークン供給量制御機能は、
前記通信遅延測定機能が前記通信ネットワークの遅延時間を更新することで、前記入力されたパケットのうち通信フローが保証する通信遅延時間内に転送できないパケットが存在する場合、前記転送できないパケットに相当するトークンの量を算出し、前記トークン供給関数に加算する。
以下、実施形態2との差分に絞って説明する。
図21は、本実施形態における通信フロー毎トークン供給関数Ts(t)補正処理S300の内容を示したものである。本補正処理は、トークン供給動作設定テーブル111に設定されているトークン供給関数更新周期毎に、通信フロー毎トークン供給関数Ts(t)更新処理S120の直前に実行する。
現在の時刻をt_now、トークン供給動作設定テーブルに記載されているトークン供給周期をTc、トークン供給関数更新周期をTu、トークン供給関数反映周期をTr、今回処理実行時のトークン供給関数をnow_Ts(t)、now_Ts(t)の値が0でない最も大きい時刻tをt_last、前回処理実行時の対象通信フローの通信経路の遅延時間をDr_before、今回処理実行時の対象通信フローの通信経路の遅延時間をDr_now、とする(ステップS301)。
Dr_beforeとDr_nowを比較し、Dr_nowの方が大きければステップS303に進み、Dr_beforeの方が大きいかまたはDr_beforeとDr_nowが一致していればフローS300を終了する(ステップS302)。
遅延時間の変化により要求遅延以内に転送できなくなるパケットのトークン量の合計sum_Tsを以下の式で計算する(ステップS303)。
sum_Ts=ΣTs(t)
{t_last−(Dr_now−Dr_before)<t≦t_lastの範囲}
t_now+Tr<t≦t_last−(Dr_now−Dr_before)の範囲におけるトークン供給周期の到来回数Ts_numを以下の式で計算する(ステップS304)。
Ts_num=INT((t_last−(Dr_now−Dr_before))−(t_now+Tr)/Tu)
ただし、INT(x)はxの小数点以下を切り捨てて整数を返す関数とする。
今回の処理実行で補正のために追加するトークン供給関数add_Ts(t)を次の式で計算する(ステップS305)。
add_Ts(t)
=(sum_Ts/Ts_num)×Tc {t_now+Tr<t≦t_last−(Dr_now−Dr_before)の場合}
=0 {上記以外のtの場合}
add_Ts(t)が小数である場合には、add_Ts(t)の合計値がsum_Tsと等しくなるように切り上げ又は切り捨てなどの正規化を行う。
今回の処理実行でTs(t)として補正するトークン供給関数correct_Ts(t)を次の式で計算する(ステップS306)。
correct_Ts(t)
=now_Ts(t)+add_Ts(t) {t_now+Tr<t≦t_last−(Dr_now−Dr_before)の場合}
=0 {t_last−(Dr_now−Dr_before)<tの場合}
correct_Ts(t)を本処理終了後のTs(t)としてトークン供給関数計算部に記録する(ステップS307)。上記Ts(t)は、本処理の直後に実施される通信フロー毎トークン供給関数Ts(t)更新処理S120のステップS121において、now_Ts(t)として用いられることとなる。
図22から図23は、通信装置1の動作例を示したものである。各テーブルの設定は図2から図4、図12及び図13のものを利用しており、ここでは図2の保証したい要求遅延=10[ms]である通信フロー番号1の通信を例として説明する。なお、通信フロー番号1のパケットは、t=0〜0.5[ms]の間にパケット群Paとして1000bytesのパケット4つと500bytesのパケット8つが到来し、t=1.0〜1.5の間にパケット群Pcとして1500bytesのパケットが6つ到来するとする。また、ユーザ収容装置1間の通信NW3の遅延時間は、設定値上は3[ms]であるものの、実際にはt=0.0[ms]以前に4.0[ms]に変化しているものとし、t=2.1[ms]と2.3[ms]の間に遅延測定部113がユーザ収容装置1間の通信NW3の遅延時間変化を検知した場合を想定している。
t=0.0〜1.5[ms]の動作については図18及び図19と同じ動作であり、通信フロー毎トークン供給関数Ts(t)補正処理S300はステップS302の判定が否となり有効とならないため割愛する。
t=1.5〜2.0[ms]の間に到来したパケット群Pcは、シェーピング部105に送信され、シェーピング部が有するバッファに格納される。また、送信されると同時にパケット量がメータリング部でカウントされ、9000[bytes]がトークン供給関数計算部108に通知される。
t=2.0[ms]において、通信フロー毎トークン供給関数Ts(t)補正処理S300が実行されるが、ステップS302の判定が否となり有効とならない。
t=2.0[ms]において、通信フロー毎トークン供給関数Ts(t)更新処理S120が実行され、Ts(t)が次のように更新される。
Ts(t)=200[bytes] {1.0<t≦2.5の場合}
=425[bytes] {2.5<t≦5.0の場合}
=225[bytes] {5.0<t≦6.5の場合}
t=2.1〜2.2[ms]の間には、遅延測定部113がユーザ収容装置1間の通信NW3の遅延時間が3.0[ms]から4.0[ms]に変化したことを、遅延測定パケット受信処理によって検知する。
t=2.5[ms]において、測定区間毎遅延測定結果書換処理S240が実施され、遅延測定部113からユーザ収容装置#A〜ユーザ収容装置#B間の通信遅延が4.0[ms]であることが遅延情報テーブル112に通知され、テーブルの内容が書き換わる。書き換わった後の遅延情報テーブル112は図20と同様である。
t=2.5[ms]において、通信フロー毎トークン供給関数Ts(t)補正処理S300が実行される。Dr_before=5.0[ms]、Dr_now=6.0[ms]となり、ステップS302の判定が真となるため処理が進む。t_last=6.5[ms]、Dr_now−Dr_before=1.0[ms]であるため、sum_Tsは5.5<t≦6.5の区間におけるTs(t)の合計となり、2250[bytes]となる。次にTs_numは、t_now=2.5、Tr=0.5、Tu=0.1であるため、((6.5−1.0)−(2.5+0.5))/0.1=25となる。したがって、add_Ts(t)は以下のように求められる。
add_Ts(t)=90[bytes] {3.0<t≦5.5の場合}
よって、correct_Ts(t)は以下のように求められる。
correct_Ts(t)=515[bytes] {3.0<t≦5.0の場合}
=315[bytes] {5.0<t≦5.5の場合}
直後に通信フロー毎トークン供給関数Ts(t)更新処理が実行され、上記のcorrect_Ts(t)がTs(t)として更新される。
以降は、パケットの到来および遅延時間変化の検知がされないので、測定区間毎遅延測定結果書換処理と通信フロー毎トークン供給関数Ts(t)補正処理と通信フロー毎トークン供給関数Ts(t)更新処理が発生してもトークン供給関数Ts(t)は変わらない。
t=2.6[ms]からは425[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=3.1[ms]からは515[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=3.6[ms]では、パケット群Paの送信がすべて完了する。パケット群Paの最後のパケットは、シェーピング部での待ち時間3.6[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計6[ms]の合算値である9.6[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
t=5.1[ms]からは315[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=5.5[ms]では、パケット群Pcの送信がすべて完了する。パケット群Pcの最後のパケットは、シェーピング部での待ち時間4.0[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計6[ms]の合算値である10.0[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
以上の通り、本実施形態の通信システム303によって、トークン供給関数Ts(t)を決定した後に遅延時間が変化する場合においても、要求遅延に対する遅延保証を実現できていることがわかる。
(実施形態4)
本実施形態の通信システム304の構成は、図1と同じ構成である。本通信システムでは、通信システム301に加えて、トークン供給開始タイミングをあえて遅らせる機能を具備することにより、要求遅延の下限と上限の間の遅延時間で通信が転送されることを保証する遅延保証通信サービスを提供する通信装置を安価に実現することが可能となる。
通信装置1は、前記通信遅延時間に上限値と下限値が設定されており、前記下限値が前記通信ネットワークの遅延時間、前記所定期間及び前記トークン供給関数の更新の反映時間の合計より大きい場合、
前記トークン供給量制御機能は、
前記1の供給期間及び前記後の供給期間を前記上限値と前記下限値との差分とするとともに、前記下限値と前記通信ネットワークの遅延時間から待ち時間を決定し、前記待ち時間だけ前記シェーピング機能へのトークンの供給を遅らせる。
以下、実施形態1との変更点に絞って説明する。
図24は、本実施形態のフロー情報テーブル110の内容を示したものである。フロー情報テーブル110は、通信フローの通番を示す通信フロー番号と、通信フローを識別するためのパケット情報を示す通信フロー識別子と、当該通信フローがどのユーザ収容装置に転送されるのかを示す転送先収容装置と、当該フローのNW内優先度と、当該フローの要求遅延時間の上限と、当該フローの要求遅延の下限で成り立っている。
図25は、通信装置1のトークン供給関数計算部108が実行する通信フロー毎トークン供給関数Ts(t)更新処理フロー(S400)を示したものである。本更新処理は、トークン供給動作設定テーブル111に設定されているトークン供給関数更新周期毎に実行する。
今回処理実行時刻をt_now、現在のトークン供給関数をnow_Ts(t)、前回処理実行時から今回処理実行時までにメータリング部104から通知されたバイト量の合計をBm、トークン供給動作設定テーブル111に記載されているトークン供給周期をTc、トークン供給関数更新周期をTu、トークン供給関数反映周期をTr、フロー情報テーブル110に記載されている対象通信フローの要求遅延時間の上限をDd、フロー情報テーブル110に記載されている対象通信フローの要求遅延時間の下限をDm、遅延情報テーブル112を用いて計算された対象通信フローの通信経路の遅延時間をDrとする(ステップS401)。
以下の式を判定し、正しいならばステップS403、否ならばステップS407に進む(ステップS402)。
Dm>Dr+Tu+Tr
要求遅延の上限と下限の差から、トークン供給時間Da1を次の式で計算する(ステップS403)。
Da1=Dd−Dm
要求遅延の下限と最短遅延の差から、トークン供給待ち時間Da2を次の式で計算する(ステップS404)。
Da2=Dm−(Dr+Tu+Tr)
今回の処理実行で追加するトークン供給関数add_Ts(t)を次の式で計算する(ステップS405)。
add_Ts(t)
=(Bm/Da1)×Tc {tがt_now+Tr+Da2<t≦t_now+Tr+Da2+Da1の場合}
=0 {上記以外のtの場合}
add_Ts(t)が小数となっている場合には、add_Ts(t)の合計値がBmと等しくなるように切り上げ又は切り捨てなどの正規化を行う(ステップS406)。
一方、ステップS407〜S411は通信フロー毎トークン供給関数Ts(t)更新処理S120のステップS122〜126と同一である。
図26から図27は、本実施形態の通信システム304の動作例を示したものである。各テーブルの設定は図3、図4、及び図24のものを利用しており、ここでは図24の保証したい要求遅延の上限=10[ms]、要求遅延の下限=8[ms]である通信フロー番号1の通信を例として説明する。なお、通信フロー番号1のパケットは、t=0〜0.5[ms]の間にパケット群Paとして1000bytesのパケット4つと500bytesのパケット8つが到来し、t=1.0〜1.5の間にパケット群Pbとして1500bytesと1000bytesのパケットの組が4つ到来するとする。
まず、t=0〜0.5の間に到来したパケット群Paは、シェーピング部105に送信され、シェーピング部105が有するバッファに格納される。また、送信されると同時にパケット量がメータリング部104でカウントされ、8000[bytes]がトークン供給関数計算部108に通知される。t=0.5[ms]において、最初の通信フロー毎トークン供給関数Ts(t)更新処理がフローS400の通りに実行されてTs(t)が次のように更新される。
Ts(t)=400[bytes] {3.0<t≦5.0の場合}
続いて、t=1.0[ms]においてTs(t)が反映されるが、トークンの供給はt=3.0[ms]より後に実施される。また、t=1.0[ms]において、通信フロー毎トークン供給関数Ts(t)更新処理が実行されるが、Bm=0のため、Ts(t)は変更されない。
t=1.0〜1.5の間に到来したパケット群Pbは、シェーピング部105に送信され、シェーピング部105が有するバッファに格納される。また、送信されると同時にパケット量がメータリング部108でカウントされ、10000[bytes]がトークン供給関数計算部108に通知される。t=1.5[ms]において、通信フロー毎トークン供給関数Ts(t)更新処理がフローS400の通りに実行されてTs(t)が次のように更新される。
Ts(t)=400[bytes] {3.0<t≦4.0の場合}
=900[bytes] {4.0<t≦5.0の場合}
=500[bytes] {5.0<t≦6.0の場合}
t=2.0[ms]において、Ts(t)が反映されるが、トークンの供給はt=3.0[ms]より後に実施される。以降、パケットが到来しないので、Ts(t)の更新は行われない。
t=3.1[ms]からは、400[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=3.3[ms]では、パケット群Paのパケットが初めてシェーピング部105から送出される。当該パケットは、シェーピング部105での待ち時間3.3[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計5[ms]の合算値である8.4[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
t=4.1[ms]からは、900[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=4.5[ms]では、パケット群Paの送信がすべて完了する。パケット群Paの最後のパケットは、シェーピング部での待ち時間4.5[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計5[ms]の合算値である9.5[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
t=4.7[ms]では、パケット群Pbのパケットが初めてシェーピング部から送出される。当該パケットは、シェーピング部での待ち時間3.7[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計5[ms]の合算値である8.7[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
t=5.1[ms]からは、500[bytes]のトークンがトークン供給部109からシェーピング部105に供給される。
t=6.0[ms]では、パケット群Pbの送信がすべて完了する。
パケット群Pbの最後のパケットは、シェーピング部での待ち時間5.0[ms]とアクセス区間遅延とユーザ収容装置間遅延の合計5[ms]の合算値である10.0[ms]の遅延を伴って、ユーザ装置2aからユーザ装置2bに送信されることとなる。
図29は、上記例においてトークン供給関数計算部108が計算したトークン供給関数Ts(t)を説明するイメージ図である。トークン供給関数計算部108はトークン供給部109に対して、3.0<t≦4.0ではパケット群Paに対するトークンのみをシェーピング部105へ供給するよう、4.0<t≦5.0ではパケット群Paに対するトークンとパケット群Pbに対するトークンの合計をシェーピング部105へ供給するよう、5.0<t≦6.0ではパケット群Pbに対するトークンのみをシェーピング部105へ供給するようなトークン供給関数Ts(t)を生成する。
以上の通り、本実施形態の通信システム304によって、要求遅延の下限と上限の間の遅延時間で通信が転送されることを保証する遅延保証を実現できていることがわかる。
1:通信装置(ユーザ収容装置#A、#B、#C、#D)
2:ユーザ装置(ユーザ装置a、b、c、d)
3:通信ネットワーク
100:送信部
101:ユーザ側受信部
102:優先情報付与部
103:フロー分離部
104:メータリング部
105:シェーピング部
106:スケジューラ
107:NW側送信部
108:トークン供給関数計算部
109:トークン供給部
110:フロー情報テーブル
111:トークン供給動作設定テーブル
112:遅延情報テーブル
113:遅延測定部
114:遅延測定動作設定テーブル
200:受信部
201:NW側受信部
202:優先情報削除部
203:ユーザ側送信部
204:遅延測定パケット抽出部
301、302:通信システム

Claims (7)

  1. ユーザ装置から入力されたパケットをトークンバケットアルゴリズムで通信ネットワークへ転送するシェーピング機能と、
    前記シェーピング機能に供給されるトークンの量を通信フロー毎のトークン供給関数に従って動的に変化させるトークン供給量制御機能と、
    を備え
    前記トークン供給量制御機能は、
    所定期間毎に、前記入力されたパケットの量、前記入力されたパケットの転送先までの前記通信ネットワークの遅延時間、及び前記入力されたパケットの通信フローが保証する通信遅延時間に基づきトークンの量と供給期間を計算し、トークン供給関数の更新を行うことを特徴とする通信装置。
  2. 前記トークン供給量制御機能は、
    前記トークン供給関数の更新において、
    1の所定期間における前記入力されたパケットの量で計算したトークンの1の供給期間と、前記1の所定期間の後の所定期間における前記入力されたパケットの量で計算したトークンの後の供給期間とが重複する場合、前記1の供給期間と前記後の供給期間が重複する期間において、前記1の所定期間における前記入力されたパケットの量で計算したトークンの量に前記後の所定期間における前記入力されたパケットの量で計算したトークンの量を加算することを特徴とする請求項に記載の通信装置。
  3. 設定されている前記通信ネットワークの遅延時間と前記入力されたパケットの通信フローが保証する通信遅延時間の少なくとも一方をパケット転送中に更新する設定値更新機能をさらに備えることを特徴とする請求項又はに記載の通信装置。
  4. 遅延測定パケットを前記通信ネットワークへ送出し、前記遅延測定パケットに対する応答から前記通信ネットワークの遅延時間を更新する通信遅延測定機能をさらに備えることを特徴とする請求項からのいずれかに記載の通信装置。
  5. 前記トークン供給量制御機能は、
    前記設定値更新機能又は前記通信遅延測定機能が前記通信ネットワークの遅延時間を更新することで、前記入力されたパケットのうち通信フローが保証する通信遅延時間内に転送できないパケットが存在する場合、前記転送できないパケットに相当するトークンの量を算出し、前記トークン供給関数に加算することを特徴とする請求項又はに記載の通信装置。
  6. 前記通信遅延時間に上限値と下限値が設定されており、前記下限値が前記通信ネットワークの遅延時間、前記所定期間及び前記トークン供給関数の更新の反映時間の合計より大きい場合、
    前記トークン供給量制御機能は、
    前記1の供給期間及び前記後の供給期間を前記上限値と前記下限値との差分とするとともに、前記下限値と前記通信ネットワークの遅延時間から待ち時間を決定し、前記待ち時間だけ前記シェーピング機能へのトークンの供給を遅らせる
    ことを特徴とする請求項に記載の通信装置。
  7. コンピュータを請求項1からのいずれかに記載の通信装置として機能させるためのプログラム。
JP2017252392A 2017-12-27 2017-12-27 通信装置、通信システム及びプログラム Active JP6856521B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017252392A JP6856521B2 (ja) 2017-12-27 2017-12-27 通信装置、通信システム及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017252392A JP6856521B2 (ja) 2017-12-27 2017-12-27 通信装置、通信システム及びプログラム

Publications (2)

Publication Number Publication Date
JP2019118072A JP2019118072A (ja) 2019-07-18
JP6856521B2 true JP6856521B2 (ja) 2021-04-07

Family

ID=67304658

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017252392A Active JP6856521B2 (ja) 2017-12-27 2017-12-27 通信装置、通信システム及びプログラム

Country Status (1)

Country Link
JP (1) JP6856521B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021176670A1 (ja) * 2020-03-05 2021-09-10 日本電信電話株式会社 ネットワーク管理システム、エッジ装置、ネットワーク管理装置、及びプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7289447B2 (en) * 2003-10-21 2007-10-30 Comcast Cable Holdings, Llc Method and packet-level device for traffic regulation in a data network
JP2005236669A (ja) * 2004-02-19 2005-09-02 Furukawa Electric Co Ltd:The 通信品質制御方法およびその通信品質制御装置
JP2009147874A (ja) * 2007-12-18 2009-07-02 Kddi Corp トラヒック制御装置、トラヒック制御方法、及びトラヒック制御プログラム
JP6200870B2 (ja) * 2014-09-02 2017-09-20 日本電信電話株式会社 データ転送制御装置、方法及びプログラム

Also Published As

Publication number Publication date
JP2019118072A (ja) 2019-07-18

Similar Documents

Publication Publication Date Title
US7460509B2 (en) Method and apparatus for isochronous datagram delivery over contention-based data link
JP4017867B2 (ja) スケジューリング装置
EP3286966B1 (en) Resource reallocation
CN110875915B (zh) 数据传输方法及装置
Wang et al. Implementation of multipath network virtualization with SDN and NFV
JP4128198B2 (ja) 帯域制御装置
WO2005088903A9 (en) Method and apparatus for isochronous datagram delivery over contention-based data link
WO2019179157A1 (zh) 一种数据流量处理方法及相关网络设备
TWI531186B (zh) 多重介面網路裝置與網路封包傳送選擇方法
WO2016105010A1 (ko) 이동 통신 시스템에서 전송 차별화를 제공하는 방법 및 장치
US20150288609A1 (en) Deadline-aware network protocol
WO2021147354A1 (zh) 服务等级配置方法以及装置
US20200252337A1 (en) Data transmission method, device, and computer storage medium
US20120102162A1 (en) Dynamic bandwidth adjustment for multiple service support
JP6856521B2 (ja) 通信装置、通信システム及びプログラム
JP6836423B2 (ja) 通信装置、通信システム及びプログラム
US8391285B2 (en) Communication apparatus, communication system, and communication method
US7746782B2 (en) Traffic control in an internet protocol network
CN110572851A (zh) 一种数据上传方法、系统、装置及计算机可读存储介质
CN109039791A (zh) 一种带宽管理方法、装置及计算机设备
KR102128015B1 (ko) 네트워크 스위칭 장치 및 이를 이용한 마킹 수행 방법
CN114024917B (zh) 互联网业务带宽保障的方法、装置、设备及存储介质
KR100547621B1 (ko) 파일전송 관리 시스템 및 방법과 그 프로그램을 기록한기록매체
KR101641689B1 (ko) 데이터 가속 전송 방법, 서버 및 그를 구현하기 위한 프로그램이 기록된 기록매체
Liu et al. Achieving high throughput and low delay in mobile data networks by accurately predicting queue lengths

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191211

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200923

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200929

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201125

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210316

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210318

R150 Certificate of patent or registration of utility model

Ref document number: 6856521

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150