JP7078850B2 - ネットワーク制御装置及びネットワーク制御方法 - Google Patents

ネットワーク制御装置及びネットワーク制御方法 Download PDF

Info

Publication number
JP7078850B2
JP7078850B2 JP2018137993A JP2018137993A JP7078850B2 JP 7078850 B2 JP7078850 B2 JP 7078850B2 JP 2018137993 A JP2018137993 A JP 2018137993A JP 2018137993 A JP2018137993 A JP 2018137993A JP 7078850 B2 JP7078850 B2 JP 7078850B2
Authority
JP
Japan
Prior art keywords
observation data
packet
communication device
traffic amount
shaping
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
JP2018137993A
Other languages
English (en)
Other versions
JP2020017806A (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 JP2018137993A priority Critical patent/JP7078850B2/ja
Priority to US17/257,720 priority patent/US11451481B2/en
Priority to PCT/JP2019/028440 priority patent/WO2020022209A1/ja
Publication of JP2020017806A publication Critical patent/JP2020017806A/ja
Application granted granted Critical
Publication of JP7078850B2 publication Critical patent/JP7078850B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H04L47/225—Determination of shaping rate, e.g. using a moving window
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ネットワーク制御装置及びネットワーク制御方法に関する。
近年、増加するモバイルトラヒックを効率的に収容するため、Centralized Radio Access Network（Ｃ－ＲＡＮ）構成が検討されている（例えば、非特許文献１参照）。Ｃ－ＲＡＮでは、多数のRadio Equipment（ＲＥ）が高密度で配置され、集約配置されたRadio Equipment Controls（ＲＥＣｓ）に接続される。また、ＩＥＥＥ ８０２．１ＣＭにおいて、フロントホールのトラヒックをレイヤ２（以下、Ｌ２と記載）ネットワークに収容する検討が進められている（例えば、非特許文献２参照）。一方で、Internet of Things（ＩｏＴ）の一部に代表される、遅延を許容するトラヒック（遅延許容トラヒック）をアクセスネットワークに収容する検討も進められている。これらを鑑みて、フロントホール、バックホールに加え、遅延許容トラヒックを同一のＬ２ネットワーク（Ｌ２ＮＷ）に収容したマルチサービス収容アクセスネットワークを検討した報告がなされている（例えば、非特許文献３参照）。
Ｌ２ＮＷを流れるサービスのフローの中には、多数の端末からネットワーク上のアプリケーションサーバに同時に接続するものがある。これら同時接続により、接続先サーバが、端末からバースト的に到着するパケットを処理できなくなることがある。バースト的に到着するパケットの一例として端末からのセッション要求パケットが考えられるため、以降は、バースト的に到着するパケットがセッション要求パケットである場合を例に記載する。一般に図２１に示すように、各Ｌ２スイッチ（Ｌ２ＳＷ）では、ネットワーク上のサーバが処理能力を超える数のセッション要求パケットを受け付けないように、Ｌ２ＳＷを流れるフローのシェーピングにより、各宛先へのトラヒックは平滑化されている。
"ドコモ5Gホワイトペーパー"，［online］，2014年9月，株式会社ＮＴＴドコモ，［平成30年6月29日検索］，インターネット〈https://www.nttdocomo.co.jp/corporate/technology/whitepaper_5g/〉 Craig Gunther，"What's New in the World of IEEE 802.1 TSN"，Standards News，IEEE Communications Magazine，Communications Standards Supplement，2016年9月，p.12-15 久保 尊広，外6名，"マルチサービスを収容したL２ネットワークにおける遅延の評価"，2016年電子情報通信学会通信ソサイエティ大会，2016年9月，B-8-25，p.155
図２２に示すように、サーバの処理能力が一時的に枯渇している場合には、図２１に示す通常時よりも、サーバにおける処理可能パケット数の閾値が低下する。そのため、サーバへのセッション要求パケットのフローが正常なレートであっても、サーバは、受信したパケットを、処理能力の枯渇前よりも多く廃棄する可能性がある。このような状況では、サーバにおいてパケット処理が行えずにパケットの廃棄が発生しているにもかかわらず、Ｌ２ＮＷにおいて処理要求パケットを分散させることができないという問題があった。
上記事情に鑑み、本発明は、中継ネットワークにおいて、接続先の通信装置へバースト的に到着する処理要求パケットを分散させることができるネットワーク制御装置及びネットワーク制御方法を提供することを目的としている。
本発明の一態様は、１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集部と、前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御部と、を備えるネットワーク制御装置である。
本発明の一態様は、上述のネットワーク制御装置であって、前記トラヒック量は、前記中継装置への入力データレート、入力データ量又は入力パケット数である。
本発明の一態様は、上述のネットワーク制御装置であって、前記制御部は、前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生又は終了を検出し、発生を検出したときには前記シェーピングレートを減少させ、終了を検出したときには前記シェーピングレートを増加させるよう制御する。
本発明の一態様は、上述のネットワーク制御装置であって、前記制御部は、前記上り観測データが示す前記トラヒック量と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量との比較に基づいて、又は、前記上り観測データから得られる前記トラヒック量の増分と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量の増分との比較に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生を検出する。
本発明の一態様は、上述のネットワーク制御装置であって、前記制御部は、シェーピングレートの変更が可能である旨の通知を受信するまで、前記中継ネットワークを構成する前記中継装置のうち前記第二通信装置に近い前記中継装置から順に前記シェーピングレートの変更依頼を送信する。
本発明の一態様は、上述のネットワーク制御装置であって、前記中継ネットワークは、レイヤ２ネットワークであり、前記中継装置は、レイヤ２スイッチである。
本発明の一態様は、上述のネットワーク制御装置であって、前記処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、前記応答パケットは、前記セッション要求パケットへの応答を示すセッション応答パケットである。
本発明の一態様は、１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集ステップと、前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御ステップと、を有するネットワーク制御方法である。
本発明により、中継ネットワークにおいて、接続先の通信装置へバースト的に到着する処理要求パケットを分散させることが可能となる。
本発明の第１の実施形態によるネットワークシステムの構成を示す図である。 同実施形態によるＬ２ＮＷの構成を示す図である。 同実施形態によるネットワークシステムの他の構成を示す図である。 同実施形態によるＬ２ＳＷの構成例を示すブロック図である。 同実施形態によるＮＷコントローラの構成を示すブロック図である。 同実施形態によるホップ数データを示す図である。 同実施形態による上り観測データを示す図である。 同実施形態による下り観測データを示す図である。 同実施形態によるＬ２ＮＷにおけるセッション要求パケットとセッション応答パケットの流れを示す図である。 同実施形態によるセッション要求パケットの入力データレートとの比較に用いられるセッション応答パケットの入力データレートのタイミングを示す図である。 同実施形態によるＮＷコントローラがＬ２ＳＷにシェーピング設定を行うシーケンス図である。 同実施形態によるネットワークシステムのシェーピング開始処理を示すフロー図である。 同実施形態によるネットワークシステムのシェーピング終了処理を示すフロー図である。 第２の実施形態による前周期上り観測データを示す図である。 同実施形態による上り増分データを示す図である。 同実施形態による前周期下り観測データを示す図である。 同実施形態による下り増分データを示す図である。 同実施形態によるセッション要求パケットの入力データレート増分との比較に用いられるセッション応答パケットの入力データレート増分のタイミングを示す図である。 第３の実施形態による処理能力データを示す図である。 同実施形態によるネットワークシステムのシェーピング開始処理を示すフロー図である。 従来技術によるパケットのシェーピングを示す図である。 従来技術によるＬ２ＮＷにおけるバーストトラヒック発生を示す図である。
以下、図面を参照しながら本発明の実施形態を詳細に説明する。本実施形態は、Ｌ２のネットワークの技術に関する。具体的には、本実施形態は、１以上のサービスが収容されるＬ２ＮＷと接続されるアプリケーションサーバ負荷検出に関する。
本実施形態では、端末と、アプリケーションサーバとが、Ｌ２ＮＷを介して通信する。Ｌ２ＮＷは、Ｌ２ＳＷにより構成される。端末からアプリケーションサーバの方向を上り、アプリケーションサーバから端末の方向を下りと記載する。ネットワークコントローラ（ＮＷコントローラ）は、端末からアプリケーションサーバ宛の処理要求パケットのトラヒックデータとアプリケーションサーバからの応答パケットのトラヒックデータとを、Ｌ２ＳＷから周期的に収集する。処理要求パケットは、アプリケーションサーバへ処理を要求するパケットであり、応答パケットは、処理要求パケットに対する応答として送信される。本実施形態では、処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、応答パケットは、セッション要求パケットに対する応答を示すセッション応答パケットである場合を例に説明する。ＮＷコントローラは、収集したトラヒックデータを用いて、アプリケーションサーバにおける処理能力の枯渇又はバーストトラヒックの発生を検出する。具体的には、ＮＷコントローラは、Ｌ２ＳＷにおけるセッション要求パケットとセッション応答パケットとの間の入力データレートの比、入力データ量の比、入力パケット数の比、又は、入力データレート増分の比に基づいて検出を行う。あるいは、ＮＷコントローラは、セッション要求パケットの入力データレート、入力データ量、又は、入力データレート増分と、アプリケーションサーバが処理可能なそれらの上限値との比較に基づいて検出を行う。
ＮＷコントローラは、Ｌ２ＮＷを構成するＬ２ＳＷのうち、処理能力の枯渇又はバーストトラヒックの発生が検出されたアプリケーションサーバになるべく近いＬ２ＳＷに対して、そのアプリケーションサーバ宛ての全てのパケット又はセッション要求パケットのフロー（トラヒックの流れ）の送信レートを減少させるようシェーピングレートを設定する。シェーピングレートは、Ｌ２ＳＷにおいて入力したパケットを通過させる速さである。これにより、アプリケーションサーバに同時に到着するセッション要求パケットを抑制する。そして、ＮＷコントローラは、収集したトラヒックデータを用いて、アプリケーションサーバにおける処理能力が枯渇から回復した、又は、バーストトラヒックの発生が終了したと判断した場合、シェーピングレートを増加させ、元に戻す。
従来は、各Ｌ２ＳＷにおいてパケットの輻輳を把握し、輻輳を把握したＬ２ＳＷが自装置におけるシェーピングレートを低減していた。そのため、アプリケーションサーバが処理可能なセッション要求パケットのトラヒック量となるようにＬ２ＮＷ全体のパケットのフローを制御することは困難な場合があった。本実施形態によれば、ＮＷコントローラは、アプリケーションサーバと直接通信することなく、アプリケーションサーバのセッション要求パケットの処理能力の状態やバーストトラヒックの発生を把握し、Ｌ２ＮＷ全体におけるセッション要求パケットのフローを低減させるように、Ｌ２ＳＷにおけるシェーピングレートの変更が可能となる。従って、アプリケーションサーバへのセッション要求パケットの到着を分散させ、アプリケーションサーバにおけるパケット廃棄や遅延許容トラヒックの再送を防ぎ、ネットワーク利用効率を向上させることが可能となる。以下、詳細な実施形態を説明する。
（第１の実施形態）
図１は、本発明の第１の実施形態によるネットワークシステム１の構成を示す図である。ネットワークシステム１は、アプリケーションサーバ２と、端末３と、Ｌ２ＮＷ４と、Ｌ３ＮＷ（レイヤ３ネットワーク）７とを有する。ネットワークシステム１が複数のアプリケーションサーバ２を備える場合、各アプリケーションサーバ２はそれぞれ、異なるサービスを提供し得る。ネットワークシステム１が備えるＪ台（Ｊは１以上の整数）のアプリケーションサーバ２のうちｊ台目（ｊは１以上Ｊ以下の整数）のアプリケーションサーバ２を、アプリケーションサーバ２－ｊ又はアプリサーバ＃ｊとも記載する。同図では、ネットワークシステム１は、２台（Ｊ＝２）のアプリケーションサーバ２－１及び２－２を備えている。アプリケーションサーバ２－１はサービスＡを提供し、アプリケーションサーバ２－２はサービスＢを提供する。また、Ｌ２ＮＷ４と接続される複数の端末３には、サービスＡを利用する端末３、サービスＢを利用する端末３、その他のサービスを利用する端末３がある。
アプリケーションサーバ２と端末３とは、Ｌ２ＮＷ４及びＬ３ＮＷ（レイヤ３ネットワーク）７を介して接続されている。Ｌ２ＮＷ４は、１台以上のＬ２ＳＷ５から構成される。Ｌ２ＮＷ４を構成するＮ台のＬ２ＳＷ５のうちｎ台目（ｎは１以上Ｎ以下の整数）のＬ２ＳＷ５を、Ｌ２ＳＷ＃ｎとも記載する。なお、アプリケーションサーバ２と端末３とは、Ｌ３ネットワークを介さずに直接Ｌ２ＮＷ４と接続されていてもよい。Ｌ２ＮＷ４は、さらに、ＮＷコントローラ６を備える。ＮＷコントローラ６は、各Ｌ２ＳＷ５と接続される。ＮＷコントローラ６とＬ２ＳＷ５とを統合した装置としてもよい。例えば、ＮＷコントローラ６は、Ｌ２ＳＷ５と同じ筐体に納められてもよい。ＮＷコントローラ６がＬ２ＳＷ５と同じ筐体に収められており、かつ、高速な処理が必要な場合は、各Ｌ２ＳＷ５にハードウェアとしてＮＷコントローラ６が実装される構成が考えられる。また、ＮＷコントローラ６は、Ｌ２ＮＷ４の外部の装置でもよい。また、Ｌ２ＮＷ４は、図２に示すＬ２ＮＷ４ａのような構成でもよい。
図２は、Ｌ２ＮＷ４ａの構成を示す図である。同図に示すように、Ｌ２ＮＷ４ａは、幹線リングＲ１と、支線リングＲ２－１、Ｒ２－２との階層構造になっている。幹線リングＲ１、支線リングＲ２－１、Ｒ２－２はそれぞれ、リング状に接続される複数台のＬ２ＳＷ５からなる。幹線リングＲ１と支線リングＲ２－１とは１台のＬ２ＳＷ５で接続され、幹線リングＲ１と支線リングＲ２－２とは他の１台のＬ２ＳＷ５で接続される。幹線リングＲ１を構成するＬ２ＳＷ５は１台目のＮＷコントローラ６であるＮＷコントローラ＃１と接続され、支線リングＲ２－１を構成するＬ２ＳＷ５は２台目のＮＷコントローラ６であるＮＷコントローラ＃２と接続され、支線リングＲ２－２を構成するＬ２ＳＷ５は３台目のＮＷコントローラ６であるＮＷコントローラ＃３と接続される。このように、幹線と支線のそれぞれ配置された複数のＮＷコントローラ６が制御を行う形態も可能である。
図３は、ネットワークシステム１ｂの構成を示す図である。図１に示すネットワークシステム１に代えて、同図に示すネットワークシステム１ｂを用いてもよい。同図に示すネットワークシステム１ｂが、図１に示すネットワークシステム１と異なる点は、Ｌ２ＮＷ４に代えてＬ２ＮＷ４ｂを備える点である。ＮＷコントローラ６は、Ｌ２ＮＷ４ｂを構成するＬ２ＳＷ５のうち、一部のＬ２ＳＷ５と接続される。ＮＷコントローラ６と接続されないＬ２ＳＷ５として、従来のＬ２ＳＷを用いることができる。このように、ＮＷコントローラ６が通信及び制御を行うことができないＬ２ＳＷ５があってもよい。
図４は、Ｌ２ＳＷ５の構成例を示すブロック図である。Ｌ２ＳＷ５は、第１ポート５１、マッチング部５２、カウンタ部５３、キュー５４、シェーパー５５、第２ポート５６、通知部５７及び制御部５８を備える。マッチング部５２、カウンタ部５３、キュー５４、シェーパー５５については、上りパケットに関してのみ記載している。
Ｌ２ＳＷ５は、第１ポート５１を１以上備える。第１ポート５１は、端末３、又は、下流の他のＬ２ＳＷ５から上りのパケットを入力する。マッチング部５２は、入力した上りのパケットの分別を行う。具体的には、マッチング部５２は、パケットに設定されている例えばヘッダのデータを参照し、パケットの宛先と、パケットの種類を判定する。パケットの種類は、セッション要求パケットであるか否かを示す。
カウンタ部５３は、マッチング部５２によるパケットの分別ごとにパケットのビット数をカウントする。これにより、カウンタ部５３は、宛先のアプリケーションサーバ２及びパケットの種別ごとに、各観測周期における上りパケットのトラヒック量を計測する。観測周期は、バーストトラヒックの立ち上がりが判断できる時間間隔に設定する。トラヒック量は、入力データレートにより表される。入力データレートとは、１観測周期において入力したパケットのビット数を、１観測周期に相当する時間により除算した値である。カウンタ部５３は、トラヒック量としてさらに観測周期ごとの入力データ量や入力パケット数を計数してもよい。入力データ量とは、入力したパケットのビット数、バイト数などである。
Ｌ２ＳＷ５は、キュー５４を１以上備える。例えば、Ｌ２ＳＷ５は、優先度別の複数のキュー５４を備えてもよい。キュー５４は、第１ポート５１から入力した上りパケットを一時的にストア（バッファリング）する。セッション要求パケットをストアするキュー５４と、データパケットをストアするキュー５４とは同一でもよく、異なっていてもよい。シェーパー５５は、キュー５４がストアしている上りパケットを、設定されたシェーピングレートに従って例えば優先度に応じて読み出し、第２ポート５６へ出力する。
Ｌ２ＳＷ５は、第２ポート５６を１以上備える。第２ポート５６は、上流の他のＬ２ＳＷ５又はアプリケーションサーバ２に、キュー５４から読み出した上りパケットを出力する。
Ｌ２ＮＷ４は、アプリケーションサーバ２から端末３宛ての下りパケットを転送するため、下り方向についてマッチング部５２、カウンタ部５３、キュー５４及びシェーパー５５と同様の構成を有する（図示せず）。下り方向用のマッチング部５２（図示せず）は、第２ポート５６からが受信した下りパケットに設定されている例えばヘッダのデータを参照し、送信元のアプリケーションサーバ２と、パケットの種類を判定する。パケットの種類は、セッション応答パケットであるか否かを示す。下り方向用のカウンタ部５３（図示せず）は、下り方向用のマッチング部５２がマッチングした送信元のアプリケーションサーバ２及びパケットの種別ごとに下りパケットのトラヒック量を計測する。下り方向用のキュー５４（図示せず）は、下りパケットを一時的にストアする。下り方向用のシェーパー５５（図示せず）は、下り方向用のキュー５４（図示せず）がストアしている下りパケットを優先度に応じて読み出し、第１ポート５１を介して下流のＬ２ＳＷ５又は端末３へ出力する。
通知部５７は、上りパケット観測データ及び下りパケット観測データを設定した観測データを、ＮＷコントローラ６に定期的に通知する。上りパケット観測データは、１観測周期に観測された宛先のアプリケーションサーバ２及びパケットの種別ごとの上りパケットのトラヒック量を示す。下りパケット観測データは、１観測周期に観測された送信元のアプリケーションサーバ２及びパケットの種別ごとの下りパケットのトラヒック量を示す。制御部５８は、各機能部を制御する。制御部５８は、シェーパー５５におけるシェーピングを制御する。
図５は、ＮＷコントローラ６の構成を示すブロック図である。ＮＷコントローラ６は、記憶部６１と、データ収集部６２と、制御部６３とを備える。記憶部６１は、ホップ数データと、各Ｌ２ＳＷ５における観測データを記憶する。ホップ数データは、各アプリケーションサーバ２と各Ｌ２ＳＷ５との間のホップ数を示す。データ収集部６２は、各Ｌ２ＳＷ５から定期的に観測データを収集し、記憶部６１に保存する。
制御部６３は、シェーピング開始制御部６３１と、シェーピング終了制御部６３２とを備える。シェーピング開始制御部６３１は、観測データを参照して、アプリケーションサーバ２毎に、セッション要求パケットの入力データレートと、セッション応答パケットの入力データレートとの比を算出する。シェーピング開始制御部６３１は、算出した比に基づいて、アプリケーションサーバ２における処理能力の一時的な枯渇又はアプリケーションサーバ２宛てのバーストトラヒックの発生を検出する。シェーピング開始制御部６３１は、検出されたアプリケーションサーバ２宛ての上りパケットのトラヒック量を低減するようにシェーピングレートの変更をＬ２ＳＷ５に指示する。このとき、シェーピング開始制御部６３１は、ホップ数データを参照し、アプリケーションサーバ２との間のホップ数が少ないＬ２ＳＷ５を優先して指示対象とする。
シェーピング終了制御部６３２は、観測データを参照して、アプリケーションサーバ２毎に、セッション要求パケットの入力データレートと、セッション応答パケットの入力データレートとの比を算出する。シェーピング終了制御部６３２は、算出した比に基づいて、アプリケーションサーバ２における処理能力の一時的な枯渇からの回復又はアプリケーションサーバ２宛てのバーストトラヒックの終了を検出する。シェーピング終了制御部６３２は、検出されたアプリケーションサーバ２宛ての上りパケットのトラヒック量を増加させるようにシェーピングレートの変更をＬ２ＳＷ５に指示する。
図６は、ホップ数データの例を示す図である。ホップ数データは、アプリケーションサーバ２の識別情報と、当該アプリケーションサーバ２から各Ｌ２ＳＷまでのホップ数とを示す。アプリケーションサーバ２の識別情報として、アプリケーションサーバ２のInternet Protocol（ＩＰ）アドレスを用いることができる。
図７は、上り観測データの例を示す図である。同図に示す上り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、１観測周期においてＬ２ＳＷ５が観測（計測）した上りパケットの入力データレート及び入力データ量を示す。パケット種別は、セッション要求パケットであるか否かにより表される。セッション要求パケットである場合は「１」、セッション要求パケット以外の場合は「０」が設定される。
図８は、下り観測データの例を示す図である。同図に示す下り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、１観測周期においてＬ２ＳＷ５が観測（計測）した下りパケットの入力データレート及び入力データ量を示す。パケット種別は、セッション応答パケットであるか否かにより表される。セッション応答パケットである場合は「１」、セッション応答パケット以外の場合は「０」が設定される。
図９は、Ｌ２ＮＷ４におけるセッション要求パケットとセッション応答パケットの流れを示す図である。同図に示すように、Ｌ２ＳＷ５は、中継したセッション要求パケットに対するアプリケーションサーバ２からのセッション応答パケットを、Ｔ＿ＲＴＴ経過後に受信する。Ｔ＿ＲＴＴは、Ｌ２ＳＷ５からアプリケーションサーバ２までの往復伝搬遅延と、Ｌ２ＳＷ５における処理遅延と、アプリケーションサーバ２における処理遅延とを足し合わせた時間に相当する。
図１０は、セッション要求パケットの入力データレートとの比較に用いられるセッション応答パケットの入力データレートのタイミングを示す図である。同図では、観測周期を単位とした離散時間１ｃから５ｃにおいて、セッション要求パケットの入力データレートが得られている。セッション応答パケットの入力データレートは、一定時間Ｔ＿ＲＴＴを経過した後に、セッション要求パケットの入力データレートと同様の変化を起こす。よって、ＮＷコントローラ６の制御部６３は、セッション要求パケットの入力データレートと、Ｔ＿ＲＴＴだけタイミングが後ろにずれたセッション応答パケットの入力データレートを比較する。
同図に示す例では、Ｔ＿ＲＴＴ＝４ｃである。ＮＷコントローラ６の制御部６３は、離散時間３ｃにおけるセッション応答パケットの入力データレートと、離散時間７ｃ（＝３ｃ＋４ｃ）におけるセッション要求パケットの入力データレートとを比較する。
図１１は、ＮＷコントローラ６がＬ２ＳＷ５へのシェーピング設定を行うシーケンス図である。ここでは、Ｌ２ＮＷ４を構成し、かつ、ＮＷコントローラ６から制御可能なＬ２ＳＷ５の中で、処理能力の一時的な枯渇又はバーストトラヒックが発生しているアプリケーションサーバ２にＬ２ＳＷ＃４が最も近く、次にＬ２ＳＷ＃３が近いとする。
まず、ＮＷコントローラ６のシェーピング開始制御部６３１は、Ｌ２ＳＷ＃４に対してシェーピング依頼を送信する（ステップＳ１０５）。Ｌ２ＳＷ＃４は、シェーピング依頼を受信すると、自身の空きキューおよびシェーピングリソースを確認する（ステップＳ１１０）。Ｌ２ＳＷ＃４は、確認の結果、シェーピング不可能であると判断すると、ＮＷコントローラ６にシェーピング不可通知を送信する（ステップＳ１１５）。
ＮＷコントローラ６のシェーピング開始制御部６３１は、Ｌ２ＳＷ＃４からシェーピング不可通知を受信すると、次にＬ２ＳＷ＃３に対してシェーピング依頼を送信する（ステップＳ１２０）。Ｌ２ＳＷ＃３は、ＮＷコントローラ６からのシェーピング依頼を受信すると、自身の空きキューおよびシェーピングリソースを確認する（ステップＳ１２５）。Ｌ２ＳＷ＃３は、確認の結果、シェーピング可能であると判断すると、シェーピング設定を実行し（ステップＳ１３０）、ＮＷコントローラ６に対して、シェーピング設定完了通知を送信する（ステップＳ１３５）。
図１２は、ネットワークシステム１のシェーピング開始処理を示すフロー図である。同図では、アプリケーションサーバ２における処理能力の一時的な枯渇又はバーストトラヒックの検知からシェーピング設定変更までの流れを示している。ＮＷコントローラ６のデータ収集部６２は、各Ｌ２ＳＷ５から定期的に観測周期毎に得られた観測データを受信し、記憶部６１に登録している。ネットワークシステム１は、同図に示す処理を、観測周期と同じ長さの処理周期毎に行う。
まず、ＮＷコントローラ６のシェーピング開始制御部６３１は、変数ｊを１に初期化する。シェーピング開始制御部６３１は、ｊ番目のアプリケーションサーバ２であるアプリサーバ＃ｊについて以下のステップＳ２０５からステップＳ２４０のループ処理Ａを行う。
まず、シェーピング開始制御部６３１は、直近の観測周期の上り観測データからアプリサーバ＃ｊのセッション要求パケットの入力データレートを取得する。シェーピング開始制御部６３１は、取得した入力データレートが閾値αより大きいか否かを判断する（ステップＳ２０５）。例えば、シェーピング開始制御部６３１は、Ｌ２ＮＷ４を構成する全ての又は一部のＬ２ＳＷ５の上り観測データそれぞれから得られる入力データレートについて判断を行ってもよく、全て又は複数のＬ２ＳＷ５の上り観測データから得られる入力データレートの合計について判断を行ってもよい。例えば、シェーピング開始制御部６３１は、１又は複数台のＬ２ＳＷ５の上り観測データに基づいて、アプリサーバ＃ｊへの合計の入力データレートを取得し、判断に用いてもよい。一例として、シェーピング開始制御部６３１は、アプリサーバ＃ｊから１ホップだけ離れたＬ２ＳＷ５の上り観測データの合計から得られる入力データレートを用いる。なお、Ｌ２ＮＷ４それぞれの入力データレートを用いて判断を行う場合、入力データレートの取得元となる上り観測データを生成したＬ２ＳＷ５のアプリケーションサーバ２からのホップ数や、下流のＬ２ＳＷ５や端末３の台数等に応じて、閾値αを異なる値としてもよい。
シェーピング開始制御部６３１は、アプリサーバ＃ｊのセッション要求パケットの入力データレートが閾値α以下であると判断した場合（ステップＳ２０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ２０５からの処理を行う。一方、シェーピング開始制御部６３１、アプリサーバ＃ｊのセッション要求パケットの入力データレートが閾値αよりも大きいと判断した場合（ステップＳ２０５：ＹＥＳ）、ステップＳ２１０の処理を行う。なお、シェーピング開始制御部６３１は、Ｌ２ＮＷ４それぞれの入力データレートについて判断を行う場合、それら全ての入力データレートが閾値α以下である場合にステップＳ２０５においてＮＯと判断し、いずれかの入力データレートが閾値αを超えている場合、ステップＳ２０５においてＹＥＳと判断する。
シェーピング開始制御部６３１は、アプリサーバ＃ｊからのセッション応答パケットの入力データレートを、直近の観測周期の下り観測データから取得する。さらに、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートを、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り観測データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データレートと、セッション要求パケットの入力データレートの比である入力データレート比を計算し、閾値βより大きいか否かを判断する（ステップＳ２１０）。閾値βは、アプリケーションサーバ２が、セッション要求パケットに応じて正常にセッション応答パケットを送信したときの入力データレートの比よりも十分小さな（乖離した）値である。
このとき、シェーピング開始制御部６３１は、Ｌ２ＮＷ４を構成する全ての又は一部のＬ２ＳＷ５のそれぞれについて算出した入力データレート比について判断を行ってもよく、全て又は複数のＬ２ＳＷ５についてまとめて算出した入力データレート比について判断を行ってもよい。例えば、シェーピング開始制御部６３１は、１又は複数台のＬ２ＳＷ５の観測データに基づいて、Ｌ２ＮＷ４全体におけるアプリサーバ＃ｊへの入力データレート比を算出し、判断に用いてもよい。一例として、シェーピング開始制御部６３１は、アプリサーバ＃ｊから１ホップだけ離れたＬ２ＳＷ５の観測データの合計から得られる入力データレート比を用いる。シェーピング開始制御部６３１は、Ｌ２ＳＷ５それぞれについて算出した入力データレート比について判断を行う場合、全てのＬ２ＳＷ５について入力データレート比が閾値βより大きい場合にステップＳ２１０においてＹＥＳと判断し、いずれかのＬ２ＳＷ５の入力データレート比が閾値β以下である場合に、ステップＳ２１０においてＮＯと判断する。なお、入力データレート比が得られたＬ２ＳＷ５のアプリケーションサーバ２からのホップ数や、下流のＬ２ＳＷ５や端末３の台数等に応じて、閾値βを異なる値としてもよい。
シェーピング開始制御部６３１は、入力データレート比が閾値βより大きい判断した場合（ステップＳ２１０：ＹＥＳ）、変数ｊの値に１を加算して、再びステップＳ２０５からの処理を行う。一方、シェーピング開始制御部６３１は、入力データレート比が閾値β以下であると判断した場合（ステップＳ２１０：ＮＯ）、アプリサーバ＃ｊ宛てに送信したセッション要求パケットに対して、正常にセッション応答パケットが送信されておらず、アプリサーバ＃ｊにおいて処理能力の一時的な枯渇又はバーストトラヒックが発生したと判断する（ステップＳ２１５）。処理能力の一時的な枯渇又はバーストトラヒックが発生したと推測される時点は、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期である。
シェーピング開始制御部６３１は、図６に示すホップ数データを参照し、ＮＷコントローラ６から制御可能なＬ２ＳＷ５に対して、アプリサーバ＃ｊからのホップ数が小さい順に番号ｉを付与する。シェーピング開始制御部６３１は、変数ｉを１に初期化し、ステップＳ２２０～ステップＳ２３０のループ処理Ｂを行う。
シェーピング開始制御部６３１は、ｉ番目のＬ２ＳＷ５であるＬ２ＳＷ＃ｉにシェーピング依頼通知を送信する（ステップＳ２２０）。例えば、シェーピング対象は、アプリサーバ＃ｊ宛てのセッション要求パケットでもよく、アプリサーバ＃ｊ宛ての全てのパケットでもよい。また、シェーピング後のデータレートが、予め取得しておいたアプリサーバ＃ｊが処理可能なデータレートとなるようなシェーピングレートをシェーピング依頼通知で指示してもよい。アプリサーバ＃ｊが処理可能なデータレートは、例えば、全てのＬ２ＳＷ５に共通でもよく、Ｌ２ＳＷ５ごとに決められてもよい。Ｌ２ＳＷ５ごとに処理可能なデータレートが決められる場合、アプリケーションサーバ２からＬ２ＳＷ５までのホップ数や、Ｌ２ＳＷ５の配下のＬ２ＮＷ４又は端末３の台数に応じて決められてもよい。
シェーピング依頼通知を受信したＬ２ＳＷ＃ｉの制御部５８は、シェーピングの設定が可能か否かを判断する（ステップＳ２２５）。Ｌ２ＳＷ＃ｉの制御部５８は、シェーピングの設定が不可と判断した場合（ステップＳ２２５：ＮＯ）、ＮＷコントローラ６にシェーピング不可通知を返送する（ステップＳ２３０）。シェーピング開始制御部６３１は、シェーピング不可通知を受信すると、現在のｉの値に１を加算し、ステップＳ２２０からのループ処理Ｂを繰り返す。
Ｌ２ＳＷ＃ｉの制御部５８は、シェーピングの設定が可能と判断した場合（ステップＳ２２５：ＹＥＳ）、シェーパー５５に対してシェーピングを行うよう制御を行う（ステップＳ２３５）。Ｌ２ＳＷ＃ｉの制御部５８は、シェーピング設定完了通知をＮＷコントローラ６に返送する（ステップＳ２４０）。
ＮＷコントローラ６のシェーピング開始制御部６３１は、Ｌ２ＳＷ＃ｉからシェーピング設定完了通知を受信してループ処理Ｂを終了した後、あるいは、変数ｉの値がＬ２ＳＷ５の台数（又はＮＷコントローラ６から制御可能なＬ２ＳＷ５の台数）であるときのループ処理Ｂを実行した後、現在の変数ｊの値に１を加算してループ処理Ａを繰り返す。シェーピング開始制御部６３１は、変数ｊの値がアプリケーションサーバ２の台数であるときのループ処理Ａを実行した後、図１２の処理を終了する。
なお、上記のステップＳ２１０において、シェーピング開始制御部６３１は、セッション応答パケットの入力データレートと、セッション要求パケットの入力データレートの比を用いて、バーストトラヒックの発生を判断しているが、入力データレートに代えて入力データ量又は入力パケット数を用いることができる。ステップＳ２１０において、シェーピング開始制御部６３１は、観測データから、セッション応答パケットの入力データ量と、セッション要求パケットの入力データ量とを取得し、それらの比と閾値とを比較する。あるいは、シェーピング開始制御部６３１は、観測データから、セッション応答パケットの入力パケット数と、セッション要求パケットの入力パケット数とを取得し、それらの比と閾値とを比較する。なお、入力パケット数を用いる場合、通知部５７は、各観測周期の上り観測データに宛先のアプリケーションサーバ２及びパケットの種類ごとの入力パケット数を設定し、各観測周期の下り観測データに、送信元のアプリケーションサーバ２及びパケットの種別ごとの入力パケット数を設定する。
次に、上記のステップＳ２３５において設定したシェーピングの終了制御について説明する。ＮＷコントローラ６のシェーピング終了制御部６３２は、Ｌ２ＳＷ５が生成した観測データを参照し、アプリサーバ＃ｊ（ｊ＝１，２，…）において処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定された時点からのアプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートの積算値と、アプリサーバ＃ｊからのセッション応答パケットの入力データレートの積算値とを取得する。シェーピング終了制御部６３２は、これらの積算値の比較に基づいて、バーストトラヒックの終了を推定する。シェーピング終了制御部６３２は、観測データに基づいてバーストトラヒックが終了したと推定した場合に、アプリサーバ＃ｊ宛ての上りパケットのシェーピングの終了をＬ２ＳＷ５に依頼する。
なお、図９及び図１０に示したように、セッション要求パケットがＬ２ＳＷ＃ｉを通過してアプリサーバ＃ｊに到着し、処理され、セッション応答パケットとして同一のＬ２ＳＷ＃ｉスイッチに戻るまでには一定の時間Ｔ＿ＲＴＴを要する。そこで、シェーピング終了制御部６３２は、セッション応答パケットの積算開始タイミングを、セッション要求パケットの積算開始タイミングよりもＴ＿ＲＴＴだけ経過した時点とする。図１０では、Ｔ＿ＲＴＴ＝４ｃであるため、セッション要求パケットの積算開始タイミングが離散時間３ｃであるときには、セッション要求パケットの積算開始タイミングを離散時間７ｃ（＝３ｃ＋４ｃ）とする。
図１３は、各観測周期におけるネットワークシステム１のシェーピング終了処理を示すフロー図である。同図では、バーストトラヒック終了の検知し、Ｌ２ＳＷ５に設定されているシェーピングレートの設定解除までの流れを示している。ネットワークシステム１は、同図に示す処理を観測周期と同じ長さの処理周期毎に行う。
ＮＷコントローラ６のシェーピング終了制御部６３２は、変数ｉを１に初期化する。さらに、シェーピング終了制御部６３２は、変数ｊの値を１に初期化する。シェーピング終了制御部６３２は、記憶部６１に記憶される観測データから、ｉ番目のＬ２ＳＷ５であるＬ２ＳＷ＃ｉにおけるアプリサーバ＃ｊの観測要求データレート及び観測応答データレートを算出する。観測要求データレートは、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点以降にＬ２ＳＷ＃ｉにおいて観測されたアプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートの積算値である。観測応答データレートは、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点からＴ＿ＲＴＴが経過した以降にＬ２ＳＷ＃ｉにおいて観測されたアプリサーバ＃ｊからのセッション応答パケットの入力データレートの積算値である。シェーピング終了制御部６３２は、観測応答データレートを観測要求データレートにより除算してレートＲを算出する（ステップＳ３０５）。
シェーピング終了制御部６３２は、算出したレートＲが閾値ＴＲよりも大きいか否かを判断する（ステップＳ３１０）。セッション要求パケットとセッション応答パケットのパケットサイズが等しい場合、閾値ＴＲとして１に十分近く１よりも小さい値、例えば、て０．７５を用いる。セッション要求パケットとセッション応答パケットのサイズ比が異なる場合は、サイズ比に合わせて閾値ＴＲを変更する。例えば、セッション要求パケットのサイズ：セッション応答パケットのサイズ＝１０：９の場合は、Ｒ＝０．９のときに２種類のパケットの入力レートは等しい。この場合、閾値ＴＲを０．９に十分近く、０．９よりも小さい値とする。
シェーピング終了制御部６３２は、レートＲが閾値ＴＲ以下であると判断した場合（ステップＳ３１０：ＮＯ）、ｊの値に１を加算してステップＳ３０５からの処理を繰り返す。シェーピング終了制御部６３２は、レートＲが閾値ＴＲを超えると判断した場合（ステップＳ３０５：ＹＥＳ）、アプリサーバ＃ｊにおける処理能力の一時的な枯渇又はバーストトラヒックが終了したと判断する（ステップＳ３１５）。シェーピング終了制御部６３２は、処理能力の一時的な枯渇又はバーストトラヒックが発生する前のシェーピングレートを設定するためのシェーピングレート変更指示を全てのＬ２ＳＷ５、又は、Ｌ２ＳＷ＃ｉに送信する（ステップＳ３２０）。シェーピングレート変更指示を受信したＬ２ＳＷ５の制御部５８は、シェーピングレートの変更をシェーパー５５に設定する。シェーピング終了制御部６３２は、ｊの値に１を加算してステップＳ３０５からの処理を繰り返す。なお、シェーピングレートを段階的に増加させ、元に戻してもよい。
シェーピング終了制御部６３２は、変数ｉの値がＮＷコントローラ６から制御可能なＬ２ＳＷ５の台数であるときのステップＳ３０５～ステップＳ３２０までの処理を終えると、現在の変数ｊの値に１を加算した後、変数ｉを初期値から順に１ずつ増加させ、各ｉの値についてステップＳ３０５～ステップＳ３２０の処理を繰り返す。シェーピング開始制御部６３１は、変数ｊの値がアプリケーションサーバ２の台数に達すると、処理を終了する。
なお、入力データレートに代えて入力データ量又は入力パケット数を用いて上記のステップＳ３０５及びステップＳ３１０の処理を行ってもよい。入力データ量データを用いる場合、上記におけるレートＲに代えて、以下の指標Ｒ’を用いて、閾値と比較する。
Ｒ’＝セッション応答パケットデータ量積算値／セッション要求パケットデータ量積算値
上記におけるセッション要求パケットデータ量積算値は、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点以降のセッション要求パケットの入力データ量の積算値である。また、セッション応答パケットデータ量積算値は、その推定される時点からＴ＿ＲＴＴ経過した以降のセッション応答パケットの入力データ量の積算値である。
また、入力パケット数を用いる場合、上記におけるレートＲに代えて、以下の指標Ｒ”を用いて、閾値と比較する。
Ｒ”＝セッション応答パケット数積算値／セッション要求パケット数積算値
上記におけるセッション要求パケット数積算値は、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点以降のセッション要求パケットの入力パケット数の積算値である。また、セッション応答パケット数積算値は、その推定される時点からＴ＿ＲＴＴ経過した以降のセッション応答パケットの入力パケット数の積算値である。
本実施形態によれば、アプリケーションサーバ２における処理能力が一時的に枯渇した、又は、バーストトラヒックが発生したことを検出し、Ｌ２ＮＷ４全体におけるセッション応答パケットのトラヒックを低減することができる。また、アプリケーションサーバ２に問い合わせることなく、アプリケーションサーバ２における処理能力が回復した、又は、バーストトラヒックの発生が終了したことを検出し、Ｌ２ＳＷ５において行っていたシェーピングを終了させることができる。
（第２の実施形態）
第１の実施形態においては、Ｌ２ＳＷ５におけるセッション応答パケットとセッション要求パケットの入力データレートの比、入力データ量の比、または、入力パケット数の比に基づいてバーストトラヒックの発生又はアプリケーションサーバ２における処理能力の一時的な枯渇を判断していた。本実施形態では、第１の実施形態の入力データレート、入力データ量、または、入力パケット数に代えて、過去の観測周期からの入力データレートの増分、入力データ量の増分、入力パケット数の増分を用いる。以下では、入力データレートの増分を用いる場合を例として、第１の実施形態との差分を中心に説明する。
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。
ＮＷコントローラ６のデータ収集部６２は、第１の実施形態と同様に、各Ｌ２ＮＷ４から図７に示す上り観測データ及び図８に示す下り観測データを含む観測周期毎の観測データを周期的に受信し、記憶部６１に書き込む。さらに、データ収集部６２は、収集した観測データと、その観測データよりも１観測周期前の観測データとを用いて、各Ｌ２ＮＷ４におけるアプリケーションサーバ２及びパケット種別ごとの上りパケット及び下りパケットの入力データレート増分を算出し、記憶部６１に登録する。
図１４は、前周期上り観測データの例を示す図である。前周期上り観測データは、図７に示す上り観測データと同じＬ２ＮＷ４における１観測周期前の上り観測データから得られる。同図に示す前周期上り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、Ｌ２ＳＷ５が観測（計測）した上りパケットの前回入力データレート及び前回入力データ量を示す。前回入力データレートは、１観測周期前の上りパケットの入力データレートであり、前回入力データ量は、１観測周期前の入力データ量である。パケット種別は、セッション要求パケットであるか否かにより表される。
図１５は、上り増分データの例を示す図である。上り増分データは、アプリケーションサーバ２及びパケット種別毎の上りパケットの入力データレートの増分を示す。入力データレートの増分は、図７に示す上り観測データが示す入力データレートから、図１４に示す前回上り観測データが示す前回入力データレートを減算して得られる。
図１６は、前周期下り観測データの例を示す図である。前周期下り観測データは、図８に示す下り観測データと同じＬ２ＮＷ４における１観測周期前の下り観測データから得られる。同図に示す前周期下り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、Ｌ２ＳＷ５が観測（計測）した下りパケットの前回入力データレートを示す。前回入力データレートは、１観測周期前の下りパケットの入力データレートである。パケット種別は、セッション応答パケットであるか否かにより表される。
図１７は、下り増分データの例を示す図である。下り増分データは、アプリケーションサーバ２及びパケット種別毎の下りパケットの入力データレートの増分を示す。入力データレートの増分は、図８に示す下り観測データが示す入力データレートから、図１６に示す前回下り観測データが示す前回入力データレートを減算して得られる。
図１８は、セッション要求パケットの入力データレート増分との比較に用いられるセッション応答パケットの入力データレート増分のタイミングを示す図である。同図では、観測周期を単位とした離散時間１ｃから５ｃにおいて、セッション要求パケットの入力データレート増分が得られている。セッション応答パケットの入力データレートは、図１０と同様に、一定時間Ｔ＿ＲＴＴを経過した後に、セッション要求パケットの入力データレートと同様の変化を起こす。そこで、ＮＷコントローラ６のシェーピング開始制御部６３１は、セッション要求パケットの入力データレート増分と、Ｔ＿ＲＴＴだけタイミングが後にずれたセッション応答パケットの入力データレート増分とを比較する。
同図に示す例では、Ｔ＿ＲＴＴ＝４ｃである。ＮＷコントローラ６のシェーピング開始制御部６３１は、離散時間１ｃにおけるセッション応答パケットの入力データレート増分と、離散時間５ｃ（＝１ｃ＋４ｃ）におけるセッション要求パケットの入力データレート増分とを比較する。
本実施形態によるネットワークシステム１のシェーピング開始処理は、ステップＳ２１０の処理を除き、図１２に示す第１の実施形態と同様である。すなわち、ステップＳ２１０において、シェーピング開始制御部６３１は、アプリサーバ＃ｊからのセッション応答パケットの入力データレート増分を、現在の処理周期の直近の観測周期の下り増分データから取得する。さらに、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレート増分を、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り増分データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データレート増分と、セッション要求パケットの入力データレート増分の比である入力データレート増分比を計算し、閾値よりも大きいか否かを判断する。閾値は、１よりも十分小さい値を用いる。シェーピング開始制御部６３１は、入力データレート増分比が閾値よりも大きいと判断した場合（ステップＳ２１０：ＹＥＳ）、変数ｊの値に１を加算して、再びステップＳ２０５からの処理を行う。一方、シェーピング開始制御部６３１は、入力データレート増分比が閾値以下であると判断した場合（ステップＳ２１０：ＮＯ）、アプリサーバ＃ｊにおいて処理能力の一時的な枯渇又はバーストトラヒックが発生したと判断する（ステップＳ２１５）。
なお、入力データレートの増分に代えて、入力データ量の増分又は入力パケット数の増分を用いることができる。この場合、上り増分データは、アプリケーションサーバ２及びパケット種別毎の上りパケットの入力データ量の増分又は入力パケット数の増分を示す。上りパケットの入力データ量の増分又は入力パケット数の増分は、上り観測データが示す入力データ量又は入力パケット数から、当該上り観測データよりも１観測周期前の上り観測データが示す入力データ量又は入力パケット数を減算して得られる。また、下り増分データは、アプリケーションサーバ２及びパケット種別毎の下りパケットの入力データ量の増分又は入力パケット数の増分を示す。下りパケットの入力データ量の増分又は入力パケット数の増分は、下り観測データが示す入力データ量又は入力パケット数から、当該下り観測データよりも１観測周期前の下り観測データが示す入力データ量又は入力パケット数を減算して得られる。
そして、ステップＳ２１０において、シェーピング開始制御部６３１は、アプリサーバ＃ｊからのセッション応答パケットの入力データ量の増分又は入力パケット数の増分を、現在の処理周期の直近の観測周期の下り増分データから取得する。さらに、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データ量の増分又は入力パケット数の増分を、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り増分データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データ量の増分又は入力パケット数の増分と、セッション要求パケットの入力データ量の増分又は入力パケット数の増分の比を計算し、閾値よりも大きいか否かを判断する。
本実施形態によるネットワークシステム１のシェーピング終了処理は、ステップＳ３０５及びステップＳ３１０の処理を除き、図１３に示す第１の実施形態と同様である。すなわち、シェーピング終了制御部６３２は、Ｌ２ＳＷ＃ｉにおけるアプリサーバ＃ｊからのセッション応答パケットの入力データレート増分を、現在の処理周期の直近の観測周期の下り増分データから取得する。さらに、シェーピング開始制御部６３１は、Ｌ２ＳＷ＃ｉにおけるアプリサーバ＃ｊ宛てのセッション要求パケットの入力データレート増分を、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り増分データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データレート増分と、セッション要求パケットの入力データレート増分の比である入力データレート増分比を計算する（ステップＳ３０５）。シェーピング終了制御部６３２は、算出した入力データレート増分比が閾値よりも大きいか否かを判定する（ステップＳ３１０）。閾値には、１に十分近く１よりも小さい値、例えば、０．７５を用いる。シェーピング終了制御部６３２は、入力データレート増分比が閾値以下であると判断した場合（ステップＳ３１０：ＮＯ）、ｉの値に１を加算してステップＳ３０５からの処理を繰り返し、入力データレート増分比が閾値よりも大きいと判断した場合（ステップＳ３１０：ＹＥＳ）、ステップＳ３１５の処理を行う。
本実施形態によれば、第１の実施形態と同様に、アプリケーションサーバ２における処理能力が一時的に枯渇した、又は、バーストトラヒックが発生したことを検出し、Ｌ２ＮＷ４全体におけるセッション応答パケットのトラヒックを低減することができる。
（第３の実施形態）
本実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データレートが、アプリケーションサーバ２において処理可能な入力データレートを超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。以下では、第１の実施形態との差分を中心に説明する。
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。ただし、ＮＷコントローラ６の６１は、各アプリケーションサーバ２の処理能力データをさらに記憶する。
図１９は、処理能力データの例を示す図である。同図に示す処理能力データは、各アプリケーションサーバ２の識別情報及びパケット種別ごとに、アプリケーションサーバ２が処理可能なデータ量、データレート及びデータレート増分を示す。パケット種別は、セッション要求パケットであるか否かにより示される。なお、本実施形態においては、アプリケーションサーバ２が処理可能なデータレート及びデータレート増分が設定されていなくてもよい。
図２０は、本実施形態のネットワークシステム１におけるシェーピング開始処理を示すフロー図である。同図において、図１２に示す第１の実施形態のフロー図と同一の処理には同一の符号を付し、説明を省略する。
まず、シェーピング開始制御部６３１は、変数ｊを１に初期化する。シェーピング開始制御部６３１は、ｊ番目のアプリケーションサーバ２であるアプリサーバ＃ｊについてス以下のステップＳ４０５からステップＳ２４０のループ処理Ａ’を行う。
シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートを、直近の観測周期の上り観測データから取得し、観測要求データレートとする。さらに、シェーピング開始制御部６３１は、処理能力データから、アプリサーバ＃ｊが処理可能なセッション要求パケットのデータ量を取得し、登録要求データレートとする。シェーピング開始制御部６３１は、観測要求データレートが、登録要求データレート×ｋ（ｋは係数）を超えているか否かを判定する（ステップＳ４０５）。
このとき、シェーピング開始制御部６３１は、Ｌ２ＮＷ４を構成する全ての又は一部のＬ２ＳＷ５のそれぞれについて取得した観測要求データレートについて判断を行ってもよく、全て又は複数のＬ２ＳＷ５についてまとめて算出した観測要求データレートについて判断を行ってもよい。例えば、シェーピング開始制御部６３１は、１又は複数台のＬ２ＳＷ５の観測データに基づいて、Ｌ２ＮＷ４全体におけるアプリサーバ＃ｊへの観測要求データレートを算出し、判断に用いてもよい。一例として、シェーピング開始制御部６３１は、アプリサーバ＃ｊから１ホップだけ離れたＬ２ＳＷ５についてまとめて算出した観測要求データレートを用いてもよい。なお、シェーピング開始制御部６３１は、Ｌ２ＳＷ５のそれぞれについて算出した観測要求データレートについて判断を行う場合、全てのＬ２ＳＷ５について登録要求データレート×ｋ以下である場合にステップＳ４０５においてＮＯと判断し、いずれかのＬ２ＳＷ５の観測要求データレートが登録要求データレート×ｋを超えている場合に、ステップＳ４０５においてＹＥＳと判断する。係数ｋの値は、Ｌ２ＳＷ５で共通であってもよく、アプリケーションサーバ２からのホップ数や下流のＬ２ＳＷ５又は端末３の台数等に応じてＬ２ＳＷ５ごとに異なっていてもよい。また、ホップ数や下流のＬ２ＳＷ５又は端末３の台数等に応じた処理能力データを記憶部６１に保持しておき、観測要求データレートが得られたＬ２ＳＷ５に対応した処理能力データから登録要求データレートを読み出してもよい。
シェーピング開始制御部６３１は、観測要求データレートが、登録要求データレート×ｋ以下であると判断した場合（ステップＳ４０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ４０５からの処理を行う。一方、シェーピング開始制御部６３１は、観測要求データレートが登録要求データレート×ｋよりも大きいと判断した場合（ステップＳ４０５：ＹＥＳ）、アプリサーバ＃ｊ宛てのバーストトラヒックが発生したと判断し（ステップＳ４１０）、第１の実施形態と同様にループ処理Ｂを行う。これにより、アプリサーバ＃ｊになるべく近いＬ２ＮＷ４にシェーピングを設定してバーストトラヒックが起きたフローのシェーピングレートを減少させ、アプリサーバ＃ｊに同時に到着するセッション要求パケットを抑制する。
例えば、シェーピング開始制御部６３１は、Ｌ２ＳＷ５におけるアプリサーバ＃ｊ宛てのセッション要求パケット又は全パケットのデータレートを、アプリサーバ＃ｊが処理可能な入力データレートまで削減するようＬ２ＳＷ５に指示する。アプリサーバ＃ｊが処理可能な入力データレートは、例えば、全てのＬ２ＳＷ５に共通でもよく、Ｌ２ＳＷ５ごとに決められてもよい。また、処理可能な入力データレートは、アプリサーバ＃ｊの登録要求データレートでもよく、登録要求データレートに対して、アプリケーションサーバ２からＬ２ＳＷ５までのホップ数や、Ｌ２ＳＷ５の配下のＬ２ＮＷ４又は端末３に応じた係数を乗算した値でもよい。
本実施形態によれば、予めアプリケーションサーバ２から処理可能なデータレートを取得しておくことで、アプリケーションサーバ２宛てのバーストトラヒックの発生を判断し、トラヒック量を低減することが可能である。
（第４の実施形態）
第３の実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データレートが、アプリケーションサーバ２において処理可能なデータレートを超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。本実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データ量が、アプリケーションサーバ２において処理可能なデータ量を超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。以下では、第３の実施形態との差分を中心に説明する。
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。ＮＷコントローラ６の記憶部６１は、図１９に示す処理能力データを記憶する。ただし、処理能力データには、アプリケーションサーバ２が処理可能なデータレート及びデータレート増分が設定されていなくてもよい。
本実施形態によるネットワークシステム１のシェーピング開始処理は、ステップＳ４０５の処理を除き、図２０に示す第３の実施形態と同様である。すなわち、ステップＳ４０５において、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データ量を、直近の観測周期の上り観測データから取得し、観測要求データ量とする。さらに、シェーピング開始制御部６３１は、処理能力データから、アプリサーバ＃ｊが処理可能なセッション要求パケットのデータ量を取得し、登録要求データ量とする。シェーピング開始制御部６３１は、観測要求データ量が、登録要求データ量×ｋ（ｋは係数）を超えているか否かを判定する。シェーピング開始制御部６３１は、観測要求データ量が、登録要求データ量×ｋ以下であると判断した場合（ステップＳ４０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ４０５からの処理を行う。一方、シェーピング開始制御部６３１は、観測要求データ量が登録要求データ量×ｋよりも大きいと判断した場合（ステップＳ４０５：ＹＥＳ）、アプリサーバ＃ｊ宛てのバーストトラヒックが発生したと判断し（ステップＳ４１０）、第１の実施形態と同様にループ処理Ｂを行う。
（第５の実施形態）
第５の実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データレートの増分が、アプリケーションサーバ２において処理可能なデータレートの増分を超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。以下では、第３の実施形態との差分を中心に説明する。
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。
ＮＷコントローラ６のデータ収集部６２は、第１の実施形態と同様に、各Ｌ２ＮＷ４から図７に示す上り観測データ及び図８に示す下り観測データを含む観測周期毎の観測データを周期的に受信し、記憶部６１に書き込む。さらに、データ収集部６２は、収集した上り観測データと、その観測データよりも１観測周期前の上り観測データとを用いて、各Ｌ２ＮＷ４におけるアプリケーションサーバ２及びパケット種別ごとの上りパケットの入力データレート増分を算出し、記憶部６１に登録する。すなわち、データ収集部６２は、観測データを記憶部６１に記憶すると、１観測周期前の上り観測データを図１４に示す前周期上り観測データとして記憶部６１に書き込み、上り観測データ及び前周期上り観測データを用いて、図１５に示す上り増分データを生成して記憶部６１に書き込む。
本実施形態によるネットワークシステム１のシェーピング開始処理は、ステップＳ４０５の処理を除き、図２０に示す第３の実施形態と同様である。すなわち、ステップＳ４０５において、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレート増分を、直近の観測周期の上り増分データから取得し、観測増分データとする。さらに、シェーピング開始制御部６３１は、処理能力データから、アプリサーバ＃ｊが処理可能なセッション要求パケットのレート増分を取得し、登録増分データとする。シェーピング開始制御部６３１は、観測増分データが、登録増分データ×ｋ（ｋは係数）を超えているか否かを判定する。シェーピング開始制御部６３１は、観測増分データが、登録増分データ×ｋ以下であると判断した場合（ステップＳ４０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ４０５からの処理を行う。一方、シェーピング開始制御部６３１は、観測増分データが登録増分データ×ｋよりも大きいと判断した場合（ステップＳ４０５：ＹＥＳ）、アプリサーバ＃ｊ宛てのバーストトラヒックが発生したと判断し（ステップＳ４１０）、第１の実施形態と同様にループ処理Ｂを行う。
本実施形態によるネットワークシステム１のシェーピング終了処理は、第２の実施形態と同様であるが、第１の実施形態と同様であってもよい。
なお、ＮＷコントローラ６は、バスで接続されたCentral Processing Unit（ＣＰＵ）やメモリや補助記憶装置などを備え、プログラムを実行することによって上記の機能を実現するようにしてもよい。なお、ＮＷコントローラ６の各機能の全て又は一部は、Application Specific Integrated Circuit（ＡＳＩＣ）やProgrammable Logic Device（ＰＬＤ）やField Programmable Gate Array（ＦＰＧＡ）等のハードウェアを用いて実現されても良い。プログラムは、コンピュータ読み取り可能な記録媒体に記録されても良い。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。プログラムは、電気通信回線を介して送信されても良い。
以上説明した実施形態によれば、ネットワークシステムは、１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継する。例えば、中継装置はＬ２ＳＷ５であり、中継ネットワークはＬ２ＮＷ４であり、第一通信装置は端末３であり、第二通信装置はアプリケーションサーバ２である。ネットワーク制御装置は、データ収集部と、制御部とを備える。例えば、ネットワーク制御装置は、ＮＷコントローラ６である。
データ収集部は、中継装置から、当該中継装置へ入力されたパケットを観測して得られた、第一通信装置から第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、第二通信装置が処理要求パケットに対応して第一通信装置宛てに送信した応答パケットのトラヒック量を示す下り観測データとを収集する。例えば、処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、応答パケットは、セッション要求パケットへの応答を示すセッション応答パケットである。また、例えば、トラヒック量は、中継装置への入力データレート、入力データ量又は入力パケット数である。
制御部は、上り観測データが示すトラヒック量と下り観測データが示すトラヒック量との比、又は、上り観測データから得られるトラヒック量の増分と下り観測データから得られるトラヒック量の増分との比に基づいて、中継ネットワークを構成する中継装置に対して第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する。例えば、制御部は、上記の比に基づいて、第二通信装置宛ての処理要求パケットのバーストトラヒックの発生又は終了を検出し、発生を検出したときにはシェーピングレートを減少させ、終了を検出したときにはシェーピングレートを増加させるよう制御する。例えば、制御部は、バーストトラヒックの終了を検出したときには、バーストトラヒックが発生する前に設定してあったシェーピングレートに戻すように制御する。
また、制御部は、上り観測データが示すトラヒック量と、第二通信装置が処理可能な処理要求パケットのトラヒック量との比較に基づいて、又は、上り観測データから得られるトラヒック量の増分と、第二通信装置が処理可能な処理要求パケットのトラヒック量の増分との比較に基づいて、第二通信装置宛ての処理要求パケットのバーストトラヒックの発生を検出してもよい。
また、制御部は、シェーピングレートの変更が可能である旨の通知を受信するまで、中継ネットワークを構成する中継装置のうち第二通信装置に近い中継装置から順にシェーピングレートの変更依頼を送信してもよい。
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
１、１ｂ…ネットワークシステム， ２－１，２－２…アプリケーションサーバ， ３…端末， ４、４ａ、４ｂ…Ｌ２ＮＷ， ５…Ｌ２ＳＷ， ６…ＮＷコントローラ， ７…Ｌ３ネットワーク， ５１…第１ポート， ５２…マッチング部， ５３…カウンタ部， ５４…キュー， ５５…シェーパー， ５６…第２ポート， ５７…通知部， ５８…制御部， ６１…記憶部， ６２…データ収集部， ６３…制御部， ６３１…シェーピング開始制御部， ６３２…シェーピング終了制御部

Claims (8)

  1. １以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集部と、
    前記上り観測データが示す前記トラヒック量と前記上り観測データが得られた期間よりも所定時間後の期間における前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記上り観測データが得られた期間よりも所定時間後の期間における前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御部と、
    を備え、
    前記所定時間は、前記トラヒック量を観測した前記中継装置から前記第二通信装置までの往復伝搬遅延と、前記第二通信装置における処理遅延とを足し合わせた時間である、
    ネットワーク制御装置。
  2. 前記トラヒック量は、前記中継装置への入力データレート、入力データ量又は入力パケット数である、
    請求項１に記載のネットワーク制御装置。
  3. 前記制御部は、前記上り観測データが示す前記トラヒック量と前記上り観測データが得られた期間よりも前記所定時間後の期間における前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記上り観測データが得られた期間よりも前記所定時間後の期間における前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生又は終了を検出し、発生を検出したときには前記シェーピングレートを減少させ、終了を検出したときには前記シェーピングレートを増加させるよう制御する、
    請求項１又は請求項２に記載のネットワーク制御装置。
  4. 前記制御部は、前記上り観測データが示す前記トラヒック量と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量との比較に基づいて、又は、前記上り観測データから得られる前記トラヒック量の増分と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量の増分との比較に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生を検出する、
    請求項３に記載のネットワーク制御装置。
  5. 前記制御部は、シェーピングレートの変更が可能である旨の通知を受信するまで、前記中継ネットワークを構成する前記中継装置のうち前記第二通信装置に近い前記中継装置から順に前記シェーピングレートの変更依頼を送信する、
    請求項１から請求項４のいずれか一項に記載のネットワーク制御装置。
  6. 前記中継ネットワークは、レイヤ２ネットワークであり、
    前記中継装置は、レイヤ２スイッチである、
    請求項１から請求項５のいずれか一項に記載のネットワーク制御装置。
  7. 前記処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、
    前記応答パケットは、前記セッション要求パケットへの応答を示すセッション応答パケットである、
    請求項１から請求項６のいずれか一項に記載のネットワーク制御装置。
  8. １以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集ステップと、
    前記上り観測データが示す前記トラヒック量と前記上り観測データが得られた期間よりも所定時間後の期間における前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記上り観測データが得られた期間よりも所定時間後の期間における前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御ステップと、
    を有し、
    前記所定時間は、前記トラヒック量を観測した前記中継装置から前記第二通信装置までの往復伝搬遅延と、前記第二通信装置における処理遅延とを足し合わせた時間である、
    ネットワーク制御方法。
JP2018137993A 2018-07-23 2018-07-23 ネットワーク制御装置及びネットワーク制御方法 Active JP7078850B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018137993A JP7078850B2 (ja) 2018-07-23 2018-07-23 ネットワーク制御装置及びネットワーク制御方法
US17/257,720 US11451481B2 (en) 2018-07-23 2019-07-19 Network control apparatus and network control method
PCT/JP2019/028440 WO2020022209A1 (ja) 2018-07-23 2019-07-19 ネットワーク制御装置及びネットワーク制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018137993A JP7078850B2 (ja) 2018-07-23 2018-07-23 ネットワーク制御装置及びネットワーク制御方法

Publications (2)

Publication Number Publication Date
JP2020017806A JP2020017806A (ja) 2020-01-30
JP7078850B2 true JP7078850B2 (ja) 2022-06-01

Family

ID=69180443

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018137993A Active JP7078850B2 (ja) 2018-07-23 2018-07-23 ネットワーク制御装置及びネットワーク制御方法

Country Status (3)

Country Link
US (1) US11451481B2 (ja)
JP (1) JP7078850B2 (ja)
WO (1) WO2020022209A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11411925B2 (en) 2019-12-31 2022-08-09 Oracle International Corporation Methods, systems, and computer readable media for implementing indirect general packet radio service (GPRS) tunneling protocol (GTP) firewall filtering using diameter agent and signal transfer point (STP)
US11553342B2 (en) 2020-07-14 2023-01-10 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming security attacks using security edge protection proxy (SEPP)
US11751056B2 (en) 2020-08-31 2023-09-05 Oracle International Corporation Methods, systems, and computer readable media for 5G user equipment (UE) historical mobility tracking and security screening using mobility patterns
US11825310B2 (en) 2020-09-25 2023-11-21 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming spoofing attacks
US11832172B2 (en) 2020-09-25 2023-11-28 Oracle International Corporation Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface
US11622255B2 (en) 2020-10-21 2023-04-04 Oracle International Corporation Methods, systems, and computer readable media for validating a session management function (SMF) registration request
US11528251B2 (en) * 2020-11-06 2022-12-13 Oracle International Corporation Methods, systems, and computer readable media for ingress message rate limiting
US11770694B2 (en) 2020-11-16 2023-09-26 Oracle International Corporation Methods, systems, and computer readable media for validating location update messages
US11818570B2 (en) 2020-12-15 2023-11-14 Oracle International Corporation Methods, systems, and computer readable media for message validation in fifth generation (5G) communications networks
US11812271B2 (en) 2020-12-17 2023-11-07 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming attacks for internet of things (IoT) devices based on expected user equipment (UE) behavior patterns
US11700510B2 (en) 2021-02-12 2023-07-11 Oracle International Corporation Methods, systems, and computer readable media for short message delivery status report validation
US11516671B2 (en) 2021-02-25 2022-11-29 Oracle International Corporation Methods, systems, and computer readable media for mitigating location tracking and denial of service (DoS) attacks that utilize access and mobility management function (AMF) location service
US11689912B2 (en) 2021-05-12 2023-06-27 Oracle International Corporation Methods, systems, and computer readable media for conducting a velocity check for outbound subscribers roaming to neighboring countries

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003224607A (ja) 2002-01-30 2003-08-08 Toshiba Corp サーバ計算機保護装置および同装置のデータ転送制御方法
JP2004164553A (ja) 2002-09-26 2004-06-10 Toshiba Corp サーバ計算機保護装置、サーバ計算機保護方法、サーバ計算機保護プログラム及びサーバ計算機
JP2014158079A (ja) 2013-02-14 2014-08-28 Nippon Telegr & Teleph Corp <Ntt> 輻輳制御システム及び輻輳制御方法
JP2015023364A (ja) 2013-07-17 2015-02-02 Kddi株式会社 通信制御装置、通信制御システム及び通信制御方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1739993A1 (en) * 2005-07-01 2007-01-03 Siemens S.p.A. Method for controlling the access to a TDMA wireless channel from nodes of a network of either linear or tree topology
JP2015050759A (ja) * 2013-09-05 2015-03-16 株式会社日立製作所 トラヒック制御方法およびトラヒック制御装置
CN109328469B (zh) * 2016-06-20 2022-03-15 日本电气株式会社 通信网络设备、通信网络系统及通信网络设备的方法
KR20180007794A (ko) * 2016-07-14 2018-01-24 삼성전자주식회사 무선 통신 시스템에서 데이터의 전송 속도 제어 방법 및 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003224607A (ja) 2002-01-30 2003-08-08 Toshiba Corp サーバ計算機保護装置および同装置のデータ転送制御方法
JP2004164553A (ja) 2002-09-26 2004-06-10 Toshiba Corp サーバ計算機保護装置、サーバ計算機保護方法、サーバ計算機保護プログラム及びサーバ計算機
JP2014158079A (ja) 2013-02-14 2014-08-28 Nippon Telegr & Teleph Corp <Ntt> 輻輳制御システム及び輻輳制御方法
JP2015023364A (ja) 2013-07-17 2015-02-02 Kddi株式会社 通信制御装置、通信制御システム及び通信制御方法

Also Published As

Publication number Publication date
US20210176177A1 (en) 2021-06-10
US11451481B2 (en) 2022-09-20
JP2020017806A (ja) 2020-01-30
WO2020022209A1 (ja) 2020-01-30

Similar Documents

Publication Publication Date Title
JP7078850B2 (ja) ネットワーク制御装置及びネットワーク制御方法
Kliazovich et al. Cross-layer congestion control in ad hoc wireless networks
Pokhrel et al. Improving multipath TCP performance over WiFi and cellular networks: An analytical approach
US7525923B2 (en) Catprobe
US9426080B2 (en) Data communication apparatus, data transmission method, and computer system
EP1344359B1 (en) Method of enhancing the efficiency of data flow in communication systems
JP2015106880A (ja) 通信ノード
CN107682434B (zh) 一种水下传感器网络架构及其实现方法
CN105743760B (zh) 一种流量切换方法和装置
JP6777650B2 (ja) Ｔｃｐトンネル及びネイティブｔｃｐ情報に基づくバンドリングシナリオにおけるパケットのスケジューリングのための方法及びシステム
CN111526089B (zh) 一种基于变长粒度的数据融合传输与调度的装置
US20170027016A1 (en) Communication device, wireless communication device, and communication method
Bui et al. A markovian approach to multipath data transfer in overlay networks
JP2009218626A (ja) 経路多重化通信システム、通信ノード及び通信方法
KR101983088B1 (ko) 다중 경로 환경에서의 udp 패킷 처리 방법
JP2006197473A (ja) ノード
Halim et al. Congestion control mechanism for Internet-of-Things (IOT) paradigm
JP2010130329A (ja) 通信装置および中継装置
Lafta et al. Performance evaluation of heterogeneous network based on RED and WRED
Ou et al. Out-of-order transmission enabled congestion and scheduling control for multipath TCP
Zhong et al. Research and Implementation of AOMDV Multipath Routing Protocol
Nácher et al. Comparing tcp and udp performance in MANETS using multipath enhanced versions of dsr and dymo
CN111147386A (zh) 用于处理数据传输拥塞的方法、电子设备和计算机程序产品
Wang et al. DSTP-end to end based approach to optimize data transmission for satellite communications
US7006515B1 (en) Isochronous queue and buffer management

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200722

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210921

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211116

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: 20220419

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220502

R150 Certificate of patent or registration of utility model

Ref document number: 7078850

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150