JP2014135724A - サービスとしてのネットワーク品質 - Google Patents

サービスとしてのネットワーク品質 Download PDF

Info

Publication number
JP2014135724A
JP2014135724A JP2014002097A JP2014002097A JP2014135724A JP 2014135724 A JP2014135724 A JP 2014135724A JP 2014002097 A JP2014002097 A JP 2014002097A JP 2014002097 A JP2014002097 A JP 2014002097A JP 2014135724 A JP2014135724 A JP 2014135724A
Authority
JP
Japan
Prior art keywords
server
network
encoded
loss rate
loss
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.)
Pending
Application number
JP2014002097A
Other languages
English (en)
Inventor
Matthew R Williams
マシュー・アール・ウィリアムズ
K Vemulapali Mohan
モハン・ケイ・ヴェムラパリ
Martin W Home
マーティン・ダブリュー・ホーン
R Mcmillan James
ジェームズ・アール・マクミラン
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.)
LiveQoS Inc
Original Assignee
LiveQoS Inc
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
Priority claimed from US13/738,006 external-priority patent/US9189307B2/en
Application filed by LiveQoS Inc filed Critical LiveQoS Inc
Publication of JP2014135724A publication Critical patent/JP2014135724A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0071Use of interleaving

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】ユーザデバイスをアプリケーションサーバに結合するためのアクセスネットワークの性能改善するためのシステムが実現される。
【解決手段】システムは、アクセスネットワークを介して中間サーバに結合されたユーザデバイスを備える。ユーザデバイスは、ネットワーク性能増強コーディング(NPEC)を使用してデータを符号化し、符号化されたデータをアクセスネットワークを介して中間サーバに送信するように適合されたプロセッサを有する。中間サーバは符号化データを受信するように適合され、NPECを使用して符号化データを復号化し、復号化データをアプリケーションサーバに送信するように適合されたプロセッサを有する。
【選択図】図1

Description

[0001]本発明は、通信データネットワークに関するものである。より具体的には、本発明は、ネットワークのエッジから見たときにネットワークを通るデータ伝送のスループットを高めるためのシステムおよび方法に関するものである。
[0002]パケットベースのネットワークでは、送信元エンドステーションまたはネットワークから送信先エンドステーションまたはネットワークへのデータ通信を可能にするために、データストリームをより小さなデータパケットに分割する。これらのパケットがネットワークを横断するときに、輻輳または他のネットワーク制限のせいでこれらのパケットの一部の損失が生じることがある。このパケット損失は、送信元エンドステーションと送信先エンドステーションとの間の通信チャネルを利用するアプリケーションに甚大な影響を及ぼしうる。理想的には、ネットワークは、多くのアプリケーションの観点から、決定論的パケット遅延を有し、パケット損失がない、完全な性能を備えていなければならない。しかし、完全なネットワーク性能を達成するための資本コストと運用コストは、ほとんどのサービスプロバイダおよびエンタープライズネットワークプロバイダにとって実際的ではない。
[0003]したがって、アプリケーションに高いネットワーク性能をもたらすために低コストのネットワークで使用できるシステムおよび方法が必要である。一アプローチでは、損失および遅延へのレスポンスを改善するためにエンドステーション側にインストールされる新しい符号化プロトコルスタックを作成する。しかし、このアプローチは、送信元ネットワークおよび送信先ネットワーク内のすべてのエンドステーションが新しい符号化プロトコルスタックを使用するためにアップグレードされなければならないため自明なアプローチとは言えない。
[0004]別のアプローチでは、標準プロトコルをインターセプトするネットワークデバイス、およびインターセプトネットワークデバイス(intercepting network devices)間の符号化プロトコルを使用して、ネットワーク損失から復旧する。これらのデバイスは、常駐するアプリケーションがネットワークそれ自体において一般的に利用可能であるものに比べてよいネットワーク性能を必要とするネットワークの領域内に展開される。このようなデバイスは、米国特許第7,742,501号の一部継続出願である、米国特許第8,009,696号の一部継続出願である、米国特許第7,953,114号において説明されている。
[0005]符号化プロトコルは、損失を低減することを目的としている。この目標を達成するために、符号化プロトコルではネットワーク内で必要な全帯域幅を増大させる。帯域幅が増大すると実際には結果として、ネットワーク制約により代わりに損失が増大しうる。インターセプトネットワークデバイスは、この問題を検知し、通信するエンドステーションが望むアプリケーション性能を確実に達成するよう反応する必要がある。
[0006]既存のアクセスネットワークの品質は、一般的に、悪く、信頼性がない。一般に、その結果の性能は信頼できず、品質は予測不可能である。他方、バックボーンネットワークは、高速リンクでアップグレードされており、一般的に、十分な容量を有し、エンジニアリングはより信頼性が高い。
[0007]コンテンツに到達するために低品質のネットワーク上に留まらなくてすむように、キャッシングの実装が広範になされている。キャッシングは、データがアプリケーションにより近くなるように複数のロケーションでデータを複製することによって性能を改善する一解決手段であり、これにより、ホップが長いことによるネットワークの品質問題がある程度軽減される。
[0008]しかし、すべてのコンテンツをキャッシュできるわけではなく(例えば、リアルタイムアプリケーション、ユーザ生成コンテンツ)、キャッシングのコストはひどく高くつく可能性がある。最後に、キャッシュのロケーションがなおも送信元から遠く離れすぎていて、そのため結果としていぜんとして性能が低下するおそれもある。
[0009]キャッシュできない、またはキャッシングに対応できない、または近接性が達成されえないアプリケーションの性能を改善する必要がある。
米国特許第7,953,114号 米国特許第8,009,696号 米国特許第7,742,501号 米国特許出願第12/193,345号 米国特許第7,706,365号 米国特許公開第2011/0149087号
[0010]一実施形態によれば、ユーザデバイスをアプリケーションサーバに結合するためのアクセスネットワークの性能改善するためのシステムが実現される。システムは、アクセスネットワークを介して結合されたユーザデバイスおよび中間サーバ(intermediate server)を備える。ユーザデバイスは、ネットワーク性能増強コーディング(network performance enhancing coding)(NPEC)を使用してデータを符号化し、符号化されたデータをアクセスネットワークを介して中間サーバに送信するように適合されたプロセッサを有する。中間サーバは、符号化されたデータを受信するように適合され、符号化されたデータをNPECを使用して復号化し、復号化されたデータをアプリケーションサーバに送信するように適合されたプロセッサを有する。好ましい実装では、中間サーバは、プロキシサーバ、Traversal Using Relays−Around−Network−Address−Translator(TURN)サーバ、または仮想プライベートネットワーク(VPN)サーバである。これらの中間サーバはどれも、アプリケーションサーバと同一の場所に配置できる。
[0011]中間サーバ内のプロセッサは、好ましくは、アプリケーションサーバからアプリケーションデータを受信し、NPECを使用してアプリケーションデータを符号化し、符号化されたアプリケーションデータをユーザデバイスに送信するようにさらに適合され、ユーザデバイス内のプロセッサは、好ましくは、NPECを使用して符号化されたアプリケーションデータを復号化するようにさらに適合される。
[0012]次に、本発明の実施形態について、添付されている図を参照しつつ、例としてのみ説明する。
本発明を実施することができる環境のブロック図である。 図1で使用されているインターセプトネットワークデバイス内のコンポーネントを例示するブロック図である。 標準パケットの例示的なセグメント化および符号化を示す図である。 損失を評価する第1のアルゴリズム例を示す図である。 平均損失を考慮する例示的な一実施形態を示す図である。 符号化レベルバックオフの一例を示す図である。 損失の著しい増加が検知され、符号化レベルバックオフが有効化されたときに実行されるステップを示す流れ図である。 符号化レベルバックオフが有効化された後に損失率安定化を検知するため実行されるステップを示す流れ図である。 損失の著しい増加が検知され、符号化レベルバックオフが有効化されたときに実行される代替的アルゴリズムを示す流れ図である。 バースト損失による符号化レベルを制限する一例の流れ図である。 符号化チャネルが開いたままでいる残り時間の間に制限された符号化レベルを処理する一例の流れ図である。 期間dの間に制限された符号化レベルを処理する一例の流れ図である。 制限された符号化レベルを処理する一例の流れ図である。この場合、符号化レベルは、制限された符号化レベルと一致するように一定期間にわたって増大される。 本発明の一実施形態によるインタリーブモードの一例の流れ図である。 本発明の一実施形態によるマルチレベルインタリーブモードの一例の流れ図である。 インターセプトネットワークデバイスがバースト損失を処理しているときに実行されるステップを示す流れ図である。 インターセプトネットワークデバイスがバースト損失を処理していて、インタリーブモードが有効化されているときに実行されるステップを示す流れ図である。 インターセプトネットワークデバイスがインタリーブモードを出て、ランダムモードが有効化されているときに実行されるステップを示す流れ図である。 インターセプトネットワークデバイスがインタリーブモードを出て、ランダムモードが有効化されているときに実行される代替的アルゴリズムを示す流れ図である。 インターセプトネットワークデバイスがインタリーブモードを出て、ランダムモードが有効化されているときに実行される別の代替的アルゴリズムを示す流れ図である。 インターセプトネットワークデバイスがインタリーブモードを出て、ランダムモードが有効化されているときに実行される別の代替的アルゴリズムを示す流れ図である。 インターセプトネットワークデバイスがインタリーブモードおよび符号化レベルバックオフを使用してバースト損失を処理しているときに実行されるステップを示す流れ図である。 バースト損失を処理するときに符号化レベルバックオフが必要かどうかを判定するために実行されるステップを示す流れ図である。 性能増強のない既存のネットワークを示す表現図である。 性能増強を実現するプロキシサーバの一例を示す図である。 性能増強を加えたTURNサーバの一例を示す図である。
[0039]本発明は、いくつかの好ましい実施形態に関して説明されるけれども、本発明はそれらの特定の実施形態に制限されないことは理解されるであろう。それどころか、本発明は、付属の請求項によって定められるような本発明の精神と範囲のうちにあるものとしてよいようなすべての代替形態、修正形態、および等価配置構成を対象とすることが意図されている。
[0040]図1は、送信元エンドステーション10および送信先エンドステーション30が標準プロトコル(例えば、パケットベースのプロトコル)を使用して通信するアプリケーションを有するネットワーク環境を例示している。このプロトコルは、例えば、インターネットまたは他の何らかの通信ネットワークとすることができるネットワーク20を通して伝送される。エンドステーション10および30は、モデム、ローカルもしくはワイドエリアネットワーク、またはネットワーク20にアクセスできる他のデバイスもしくはシステムを通じて接続されているパーソナルコンピュータなどの端末とすることができる。エンドステーション10および30上に常駐するいくつかのアプリケーションについては、さらによいネットワーク性能が必要となり、これらのアプリケーションに関係するパケットは、ネットワークデバイス40および50によってインターセプトされる。「インターセプト」ネットワークデバイスと言う場合、これは、ネットワークデバイス40および50がネットワーク性能を高める符号化プロトコルを使用して標準パケットを符号化することである。このネットワークの動作の仕方を例示するために、標準パケットフローは、送信元エンドステーション10から送信先エンドステーション30(すなわち、図1において左から右)であると仮定される。インターセプトネットワークデバイス40は、送信元エンドステーション10からの標準パケットを符号化し、それらの符号化されたパケットをネットワーク20を通じてインターセプトネットワークデバイス50に転送する。インターセプトネットワークデバイス50は、パケットを復号化し、再構成された標準パケットを送信先エンドステーション30に転送する。逆方向では、送信先エンドステーション30から送信元エンドステーション10へ流れるパケットは、インターセプトネットワークデバイス50によって符号化され、ネットワーク20越しにインターセプトネットワークデバイス50に転送される。インターセプトネットワークデバイス40は、これらのパケットを復号化し、再構成された標準パケットは、送信元エンドステーション10に転送される。
[0041]図2は、ネットワーク性能を改善するために符号化プロトコルを実装するのに必要なモジュールを備えるインターセプトネットワークデバイス40の例示的な一実施形態を示している。これらのモジュールは、単一のデバイス内にあるか、または複数のデバイス間に分散させることができる。図2の例示的な実施形態では、インターセプトネットワークデバイス40は、ネイティブインターフェース60、符号化インターフェース70、復号器80、および符号器90を備える。ネイティブインターフェース60は、送信元エンドステーション10との間で標準パケットの送受信を行い、符号化インターフェース70は、ネットワーク20との間で符号化パケットの送受信を行う。
[0042]符号器80は、ネイティブインターフェース60から標準パケットを受信し、パケットを1つまたは複数のセグメントに分割することによって符号化パケットを生成し、この後、これらのセグメントは符号化インターフェース70を使ってネットワーク20に送信できる状態にある。復号器90は、符号化インターフェース70から符号化パケットを受信し、ネイティブインターフェース60を使って送信元エンドステーション10に送信するため標準パケットを生成する。
[0043]符号化パケットから標準パケットを作成し直す作業を補助するために、符号器90は、付加的符号化パケットも作成することができる。これらの付加的符号化パケットは、標準パケットおよび符号化パケットから導出される。付加的符号化パケットは、1つまたは複数の符号化パケットがネットワーク20を通しての送信中に失われた場合に送信先のインターセプトネットワークデバイス50内の復号器が元の標準パケットを作成し直すか、または組み立て直すのを補助する。
[0044]一実施形態による標準パケットの符号化が図3に例示されている。説明を簡単にするため、元の標準パケットおよび符号化パケットからヘッダを省いてある。符号器において受信された標準パケット400は、lバイト分のパケットペイロードを有しており、n個のセグメント402にセグメント分割される。nがlの整数係数として選択された場合、n個のセグメントのそれぞれは、図示されているようにl/nバイトを有する。それに加えて、m個の付加的符号化パケットが作成される。図3に示されている例では、m=1および追加すなわち付加的セグメント404は、論理関数(例えば、XOR関数)をn個のセグメントのすべてに適用することによって作成されるパリティセグメントである。
[0045]符号器がセグメントおよび付加的符号化セグメントを作成するプロセスを完了した後、パケットにヘッダが追加され、符号化パケットおよび付加的符号化パケットを作成する。ヘッダでは、ネットワーク内に専用操作機能が期待されないように標準プロトコルを使用する。したがって、符号化パケットおよび付加的符号化パケットは、ネットワークを通して復号化インターセプトネットワーク要素に伝送される。符号器では、パケットのサイズを考慮し、標準プロトコルヘッダが符号化パケットに追加されるとネットワークの最大転送単位(MTU)を超えることになるサイズの符号化パケットを送信するのを回避するためnを自動的に増分することができる。この機能は、ジャンボフレームを取り扱えないネットワークに入る前にジャンボフレームを分割するのにも有用な場合がある。
[0046]復号器が符号化パケットおよび付加的符号化パケットから標準パケットを組み立て直すときに、復号器は符号化パケットの損失を処理することができる。十分な情報が付加的符号化パケットに含まれる場合、失われた符号化パケットによって引き起こされた欠落セグメントが作成し直される。損失が大きすぎる場合には、符号器はオプションを有する。標準パケットが制限された寿命を有する場合(ビデオパケットなど)、影響を受ける標準パケットは破棄される。アプリケーションがネイティブ機能としてパケット損失に対する回復性を備える場合、ここでもまた、標準パケットは破棄されうる。標準パケットが妥当な寿命を有し、アプリケーションがネイティブ機能として回復性を備えていない場合、復号器は、符号器に欠落セグメントの再送を要求することができる。これは、符号器は、ネットワークの他端で復号化に成功するまで標準パケットをバッファリングすると仮定する。
[0047]通信するアプリケーションに対するより高いネットワーク性能を可能にするために、インターセプトネットワークデバイス間で符号化チャネルが確立される。これらのチャネルの作成例は、米国特許出願第12/193,345号において説明されている。本出願の目的に関して、インターセプトネットワークデバイス40と50との間の符号化チャネルは、ネゴシエーションに成功すると仮定される。符号化チャネルは、データと制御情報の両方を搬送するために使用され、符号化パケットおよび付加的符号化パケットは、インターセプトネットワークデバイス間で送受信することができる。
[0048]上記のネットワーク内のエンドステーション上に常駐するアプリケーションは、通信ネットワーク内の異なるレベルのパケット損失を許容することができる。インターセプトネットワークデバイスは、標準プロトコル信号伝達要素に基づきこれらのアプリケーションを区別することができる。FTPを使用するファイル転送の信号伝達にはTCPポートが使用される。これは、64000の範囲内のTCPポートを開いて、エンドステーション間でファイルをトランスポートする。TCPは、ネットワーク内の損失および遅延時間の変動に対する回復性を有する。転送の重要な目標は、ファイルが損なわれることなく、ネットワークに可能な適切なタイミングで届くことを確実にすることである。このアプリケーションは、テレビ会議アプリケーションとは対照的なものである。これらは、UDPポート5060上のセッション開始プロトコルを使用して信号伝達を行うことができ、また会議に関連するビデオ、音声、およびデータセッションに対する情報を含む。ビデオセッションは、損失に対する許容度が低く、アイフレーム(画面の完全な画像)の損失は、ビデオ圧縮アルゴリズムを大きく損なう可能性がある。ビデオストリームに必要な帯域幅が大きければ大きいほど、損失に対する許容度は低いが、それは、それぞれの標準パケットがビデオストリームに関係するより多くの情報を搬送しているからである。音声セッションは、人間の話言葉の予測的な性質のせいで損失に対して比較的高い許容度を有する。音声コーデックは、連続する音声ストリームを保証するためギャップを埋めることができる。いずれの場合も、ビデオおよび音声セッションは、ビデオブロッキングまたは音声クリッピングを回避するために1%未満の標準パケット損失を有する必要があり、ほとんどのプロバイダが、標準パケット損失を0.5%未満に抑えようとしている。
[0049]与えられているセッションに関する文脈内で、異なるストリームは、異なる損失目標で処理されうる。ディープパケットインスペクション(DPI)は、アプリケーションの種類(ビデオ/音声/データ)を検知し、アプリケーションのその種類に対する構成済みネットワークポリシーに従って損失目標を設定するため、インターセプトネットワークデバイス内で使用されうる。最終的に、それぞれの標準パケットは、必要な保護レベルを識別するヘッダ内に用意された情報に基づきそれ専用の損失目標を有することができる(例えば、SVC(スケーラブルビデオコーデック))。この損失目標は、ターゲット損失率(Target Loss Ratio)(TLR)として定義される。
[0050]TLRは、nとmの両方によって決定される符号化率を決定するために使用されうる。符号化率は、与えられたインターセプトネットワークデバイスに関連する符号化コンポーネントで終端する1つまたはすべての符号化チャネルに対して観察された、および/または報告されたネットワーク性能に基づき調整されうる。目標は、符号化チャネルがセッションに対するTLRを達成するように、またはそれ以上に、符号化レベルを設定することである。
[0051]図4を参照すると、観察された損失率の決定は、インターセプトネットワークデバイスA1106とインターセプトネットワークデバイスB1107との間の符号化チャネルに関して、特に、インターセプトネットワークデバイスAからインターセプトネットワークデバイスBへの方向でチャネルを見て、説明されることがわかる。「無損失」、または許容可能な損失の状態の下で、符号化は、必要ないときにネットワーク内の付加的帯域幅を使用することを回避するためにn=1およびm=0に設定されうる。インターセプトネットワークデバイスB1107の復号器1109は、図4に例示されているサブルーチンを使用して、受信したパケットの数PおよびW時間単位の間隔(例えば、W=8秒)で損失したパケットの数LPをカウントする。この時間間隔は、特定の数のパケットの受信として定義することもできる。あるいは、LPxは、再送要求の数を表すことができ、回復に成功した損失は、損失率の一部としてはカウントされない。それぞれの間隔の終わりは、ステップ1100で検知され、損失率Lは、例えば、
Figure 2014135724
を使用して、ステップ1101で計算される。
[0052]式1の中のPは、期間Wで送信された標準パケットの数とすることができる。この場合、LPは、失われた標準パケットの数である。これは、SPLと称される。Pに対する別のオプションは、期間Wで標準パケットを組み立て直すために復号器に届いているべきである符号化セグメントおよび付加的符号化セグメントの数をカウントすることである。次いで、LPは、期間Wでネットワーク内の失われたセグメントおよび付加的セグメントの数である。これは、EPLと称される。一般に、SPLは、符号化スキームが復号器による損失からの回復を助けるという事実によりEPLより低く、そのため、標準パケットに関係する符号化パケットが失われたとしても標準パケットを再現することができる。その観点から、EPLは、ネットワークの性能のより正確な指標である。
[0053]現在の損失率(L)は、標準パケットの測定結果から計算される損失を指すものとしてよい(SPL)。これは、符号化および付加的符号化セグメントから計算された現在の損失を指すものとしてよい(EPL)。これは、SPLとEPLとの組み合わせから計算された現在の損失率を指すものとしてもよい。この組み合わせの一例は、
Figure 2014135724
であるが、ただし式中、ωは標準パケットの損失に付与された重みであり、ωは、符号化セグメントの損失に付与された重みである。
[0054]偶発的に発生する事象への反応を回避するために、ステップ1102では、最近のZ回の損失測定結果にわたって平均損失を計算する。最近のネットワークステータスを考慮するために、例えば、式
Figure 2014135724
を使用して、加重平均をとり、最近の現在の損失率の測定に重み付けすることができるが、ただし式中、WLは、間隔xに対する最近の損失の測定結果の加重平均を表す。重みは、i<j≦xに対してω<ωとなるような重みである。
[0055]多数の損失測定の経過を追うのを回避するために、例えば、式
Figure 2014135724
を使用し、前の加重損失を使用して、新しい加重損失を評価することもできるが、ただし式中、ωoldおよびωnewは、一般にωold<ωnewとなるように設定された重みである。
[0056]適宜、加重損失率をステップ1103で正規化し、整数のみを使用してルックアップを簡素化することができる。正規化損失NLは、式
Figure 2014135724
を使用して計算することができるが、ただし式中、Nは、正規化係数である(例えば、N=10000)。
[0057]次いで、現在の符号化レベルを抽出するためステップ1104でNLを使用して符号化レベルテーブルのインデックスを作成する。符号化レベルテーブルの一例が以下に示されているが、これは8つのレベルを構成するが、ただし表中、INT_maxは、最大整数または大きな値(例えば、10000)である。
Figure 2014135724
[0058]次いで、インターセプトネットワークデバイスB1107の符号器1111は、抽出された符号化レベル1105をインターセプトネットワークデバイスA1106にそのセッションのために送信されたそれぞれの符号化パケットのヘッダ内に挿入する。インターセプトネットワークデバイスA1106内の復号器1112は、受信したパケットから符号化レベルを読み取る。次いで、IおよびMax_nの値を得るために符号化レベルで新しいパラメータテーブルのインデックスを作成するが、この値は現在の符号化レベルが与えられた場合にnが設定されるべき最大値である。複数の新しいパラメータテーブルを使用して、アプリケーション要件および許容可能なオーバーヘッドに基づき異なるTLRを達成することができる。8個の損失率を使用するこのような新しいパラメータテーブルの一例を以下に示す。
Figure 2014135724
ただし表中、INT_maxは、最大整数(無限大)であるものとしてよい。
[0059]インターセプトネットワークデバイスA1106の符号器1108がサイズsのパケットを符号化する前に、Rec_nを得るために、sで事前構成されたパケットサイズテーブルのインデックスを作成するが、この値はパケットサイズが与えられた場合にnの推奨値を表す。パケットサイズテーブルの一例を以下に示す。
Figure 2014135724
[0060]このテーブルを使用すると、サイズs<88バイトのパケットは、Rec_n=1を返すことがわかる。s>528バイトであれば、Rec_n=4である。次いで、パケットを符号化するために使用されるnの値が、n=min(Rec_n,Max_n)で決定される。
[0061]別の実施形態では、復号器1109は、上記の式(3)または(4)を使用して加重損失率WLを計算する。式(5)を使用し、適宜正規化してNLを計算する。正確な損失値(WLまたはNL)が、セッションに対する符号化チャネル内に挿入された制御メッセージにより規則正しい間隔で(例えば、1秒おきに)復号器1112に送られる。復号器1112は、制御メッセージから正確な損失値を抽出する。符号器1108は、正確な損失値を使用して、新しいパラメータテーブルのインデックスを作成し、Max_nおよびmを求める。
Figure 2014135724
[0062]nの値は、n=min(Rec_n,Max_n)として導出される。異なるターゲット損失率を反映するように複数の新しいパラメータテーブルを構成することができ、符号器1108は、アプリケーションのターゲット損失率に基づき適切なテーブルを使用する。現在の損失率の代わりに実際の損失率を送信することで、符号化側でパラメータテーブルを構成することができ、したがって、構成が簡素化される。
[0063]前の式は、個別のストリームに対する損失率の計算の仕方を示している。例として図5を取りあげると、インターセプトネットワークデバイスD1203は、インターセプトネットワークデバイスA1202、B1207、およびC1208をそれぞれ発信元とする3つのフロー1204、1205、および1206の損失率を計算することがわかる。フローについて測定された損失率を返すことに加えて、受信側インターセプトネットワークデバイスは、間隔xで送られる3つのフローから、加重損失率ALの平均を計算することができる。
[0064]間隔期間は、単一のフローに対する損失率を計算するために使用される間隔期間と同じであってよい。平均損失率は、例えば、
Figure 2014135724
で計算することができるが、ただし式中、WLは上記の式(3)または(4)を使用して計算できる。次いで、上記の式(5)を使用してALを正規化し、正規化された平均損失率NALを求めることができる。次いで、符号化レベルテーブル内でNALをインデックス付けして、遠端における平均損失率(ALFE)を得る。符号化レベルテーブルは、上に例示されているか、または異なる数で事前構成されているものと同じであってよい。ALFNが、上で説明されているように計算されたフロー毎の現在の損失率とともにインターセプトネットワークデバイスD1203の復号器によって各インターセプトネットワークデバイス1202、1207、および1208に送信される符号化パケットのパケットヘッダに加えられる。
[0065]集約情報がパケットヘッダ内に含まれる場合、インターセプトネットワークデバイス1202、1207、または1208は、その情報を使用してその符号化レベルを変更するかどうかを決定することができる。インターセプトネットワークデバイスA1202の復号器は、測定期間xにおいてアクティブであるg個の符号化されたセッション1211、1212、および1204から符号化チャネルで受信された現在の損失率の平均である近端における平均損失(ALNE)も
Figure 2014135724
で計算する。
[0066]図5の例において、インターセプトネットワークデバイスA1202で計算されたALNEは、インターセプトネットワークデバイスD1203、E1209、およびF1210から受信された現在の損失率の平均を表す。
[0067]セッションに対する現在の損失率とALFEとの差が所定の閾値より低い場合、上で説明されているように、現在の損失率を使用して符号化レベルを設定する。この場合、現在の損失率が計算されたALNEよりもよいか、またはわずかに悪いので、セッションは上流ネットワークを輻輳させていることはありえなと想定される。
[0068]現在の損失率とALFEとの差が所定の閾値以上であり、かつ現在の損失率−ALNEが所定の閾値以上である場合、その現在の損失率は無視され、符号化レベルは、パケットサイズテーブルにのみ従って設定され、与えられたパケットに対する最も帯域幅効率の高い符号化方法を選択することによって帯域幅の使用度を最小限度に抑える。所定の閾値は異なっていることもあり、またネットワークポリシーおよびトポロジに従って設定することが可能である。
[0069]nがどのように決定されようと(現在の損失または平均損失)、nの値の増加は、オーバーヘッドの増分が大きくならないように徐々に行われうる。テーブルによってnのより大きな値が推奨される場合、これはその後の標準パケットの部分集合にのみ適用することができ、次に到来するw個の標準パケットのうちのv個の標準パケットのみがnの増加された値を使用し、他のw−v個のパケットはnに対して前の低い値を使用する。vおよびwの値は、測定された損失率が増加し続ける場合、または測定された損失率が次のレベルに近づくときにも変化しうる。
[0070]例えば、測定された損失(加重または正規化)が0%の場合、n=1、m=0、およびv=w=1である。したがって、すべてのパケットは、n=1、m=0で符号化される。測定された損失が0%より大きく、0.05%より小さい値まで増加する場合、n=4、m=1であるが、v=1およびw=3であり、3つのパケットのうちの1つのみがn=4で符号化され、他は、前の符号化レベルn=1、m=0を使用する。測定された損失が0.05%を超えるが、0.1%未満である場合、v=1およびw=2に変化し、2つおきのパケットがn=4で符号化され、他は、前の符号化レベルn=1、m=0を使用する。測定された損失が0.1%を超えるが、0.2%以下である場合、v=1およびw=1を使用し、すべてのパケットがn=4で符号化される。vおよびwの異なる値は、異なる所定の損失率でオーバーヘッドの増加を平滑化するように構成されうる。これができると、異なる損失率の間の伝達関数が著しく平滑化されうる。
[0071]インターセプトネットワークデバイスは、符号化レベルが上がるにつれネットワーク損失が減少するという理論に基づき動作する。しかし、nおよび/またはmが増加するにつれ、インターセプトネットワークデバイスによって生成され、ネットワークを横断する、パケットの数が増加する。この結果、アプリケーション通信を達成するために必要な帯域幅が増大する。
[0072]帯域幅の増大は、場合によっては、損失の増大につながりうる。経路内の1つまたは複数のリンクが制約された帯域幅である場合、追加されるパケットは、実際にこの時点で輻輳を増大させる。送信用のリンクにパケットが到来しても、すぐに送信される場合も送信できない場合もある。パケットが送信できない場合のために、ほとんどのデバイスにおいて後で送信できるようにパケットをバッファリングするキューが実装される。いくつかのデバイスでは、このリンクに関連付けられているキューが特定のレベルまで大きくなると、ネットワーク輻輳制御機構(例えば、RED、WREDなど)が呼び出され、このリンク上の輻輳を処理することができる。このリンクに到来するパケットの数が増えると、符号化パケットの1つが破棄される可能性が高まる。この確率は、符号化チャネルによって加えられる追加のオーバーヘッドによっても高まる。追加のオーバーヘッドは、キューの深さをたちまち大きくし、したがって、パケットが破棄される確率も高まる。
[0073]輻輳の別の原因として、コンテキストのスイッチングがある。送信元エンドステーションと送信先エンドステーションとの間の経路内のネットワークデバイスは、期間毎に限られた数のパケットを転送することしかできない。したがって、符号化パケットをトランスポートするのに十分なリンク帯域幅が利用可能であっても、ネットワークデバイスはすべてのフレームを転送できるわけではなく、そのため損失が生じる。
[0074]したがって、経路内のパケットの数を増やす符号化レベル、およびオーバーヘッドの量を大きくすることによって、損失率が高まりうる。インターセプトネットワークデバイスは、この状況に対応するためのアルゴリズムを必要とする。最初に、インターセプトデバイスが、符号化チャネル上の損失率の著しい増加を検知する必要がある。これは、例えば、一定期間にわたる損失率の結果を追跡することによって、行える。これは、式(1)または(2)によって計算された現在の損失率、式(3)または(4)によって計算された加重損失率、式(5)によって計算された正規化された損失率、または損失を求める任意の他の方法によるものであってよい。
[0075]著しい増加を検知する方法の1つは、損失率の瞬間的変化を使用するものである。これは、現在の損失率と前の損失率との差を見るものである。
ΔCLR=CLR−CLRx−1 (8)
この差がSITとして定義される著しい増加の閾値を超える場合、損失率の著しい増加が検知される。著しい増加が生じたと誤って宣言するのを回避するため、送信元インターセプトネットワークデバイスと送信先インターセプトネットワークデバイスとの間で送信される符号化パケットの数は、統計的に関連性を有していなければならない。これは、以下の式の場合に取り込まれる。
Figure 2014135724
[0076]瞬間的損失率を使用する代わりに、前の式において平均損失率を使用することができる(式(3)および(4)のように)。変化は、式(10)を使用して計算することができる。
ΔWL=WL−WLx−1 (10)
次いで、著しい増加を以下のように決定することができる。
Figure 2014135724
[0077]別のアプローチでは、増加が符号化レベルであって有効化されている場合に損失率を記録する。損失率の変化(CLRoriginal)が記録され、現在の瞬間的な損失率との比較の基準として使用される。現在の損失率が、例えば元の損失率の10倍である場合、損失の著しい増加が検知されている。
Figure 2014135724
[0078]損失率の著しい増加が検知された後、インターセプトネットワークデバイスは、符号化レベルバックオフスキームを使用して反応する。この場合、インターセプトネットワークデバイスは、符号化レベルを増加させる代わりに減少させることによって損失に反応する。図6は、損失率の著しい増加の検出に応答して符号化レベルを減少させる一技術の流れ図である。最初に、ステップ1300において、損失率の増加を停止する符号化レベルを見つけようとする。このレベルが達成された後、ステップ1301において、損失率が安定していることを確認してからインターセプトネットワークデバイスを損失率の通常処理に戻す。
[0079]図7は、図6のステップ1300の一実装を示している。このアルゴリズムは、損失率の増加を停止する符号化レベルを見つけるステップを定義する。このアルゴリズムは、ステップ1400で現在の損失率を記録することから開始し、次いで、チャネルの符号化レベルが、ステップ1401で下げられる。符号化レベルの低下は、いくつかの方法で実行できる。例えば、符号化レベルは、アルゴリズムの反復毎に直線的に低下させるか、または指数関数的に減少させることができる。一実装では、両方の方法をサポートし、符号化チャネルが確立されるときにこれらの方法のうちの1つを選択することができる。別の例では、符号化チャネルが作成される前に設定されている構成ポリシーを使用する。
[0080]ステップ1401で符号化レベルが低減された後、ステップ1402において、符号化レベルが0より大きいかどうかを判定する。ステップ1402で否定的な答えであれば、現在の損失率は開始時の損失率よりいぜんとして高く、符号化バックオフアルゴリズムが動作していないことを示し、そのため、アルゴリズムはステップ1403で打ち切られる。次いで、符号化チャネルは、通常の損失率処理に戻るか、またはn=1およびm=0に戻り、ユーザおよび/またはシステムに通知する。
[0081]ステップ1402での答えが肯定的である場合、システムはステップ1404に進み、そこで、インターセプトネットワークデバイスは一定期間dの間待ってから、ステップ1405で現在の損失率を再びサンプリングする。次いで、ステップ1406は、現在の損失率がステップ1406の開始時の損失率より高い、すなわち、損失率が所定のある量だけ変わらず増加しているかどうかを判定し、アルゴリズムは、ステップ1406からステップ1401および1402に戻り、チャネルに対する符号化レベルを再び下げる。ステップ1406での答えが否定的である場合、システムはステップ1407に進み、現在の符号化レベルの結果損失率が安定しているかどうかを判定する。
[0082]図8は、図6のステップ1301の一実装を示している。このアルゴリズムは、現在の符号化レベルの結果安定した損失率をもたらしているかどうかを判定するステップを定義する。このアルゴリズムは、ステップ1500で初期化されたループ内で実行される。次いで、インターセプトネットワークデバイスは、ステップ1501で一定期間dの間待ってから、ステップ1502で現在の損失率を再びサンプリングする。現在の損失率が開始時の損失率より著しく高い場合、ステップ1503でアルゴリズムは終了し、符号化レベルのバックオフに戻る。ステップ1503において、現在の損失率が開始時の損失率より低いままであるかどうかを判定し(ステップ1503)、次いで、アルゴリズムがループカウンタをインクリメントし(ステップ1504)、最大反復回数に達するまで現在の損失率のサンプリングを続ける(ステップ1505)。この時点で、損失率の著しい増加が処理されたため、アルゴリズムは終了する。
[0083]図6のアルゴリズムの他の実装がある。例えば、図9は、符号化レベルバックオフスキームの代替的実装を示している。この場合、アルゴリズムは、ステップ1600で開始時の損失率を現在の損失率の値に設定し、次いで、ステップ1601において、最初に、損失率が下げられるかどうかを判定するため符号化レベルを上げる。ステップ1604で、損失率の低下を検知した場合、アルゴリズムは終了して、損失率が安定していることを確認するステップに進み、その後、通常の損失率処理に戻る。ステップ1604で、損失率の低下が検知されない場合、アルゴリズムはステップ1605および1606に進み、符号化レベルを2レベル下げ、次いで、ステップ1602に進み、一定期間待ってから現在の損失率を再びチェックする。これが成功した場合(ステップ1603および1604)、アルゴリズムは、損失率が安定していることを確認してから通常の損失率処理に戻る。ステップ1604において、現在の損失率が開始時の損失率よりいぜんとして高いと判定し、ステップ1605において、これが最初の反復でないと判定した場合、アルゴリズムは図7のアルゴリズムを使用して符号化レベルのバックオフを続ける。
[0084]損失率の著しい増加を処理する別のアプローチ(図6のステップ1300における)では、図10のアルゴリズムを使用して、著しい増加を引き起こしている符号化レベルを制限する。ステップ1700において、現在の符号化レベルは制限された符号化レベルとして記録され、次いで、現在の符号化レベルが、ステップ1701で下げられる。次いで、ステップ1702において、現在の符号化レベルが制限された符号化レベル未満に留まることを確認する。
[0085]図6のステップ1301において、符号化レベルの制限が損失率を安定化させるかどうかを判定する方法が多数ある。図11に示されている方法の1つは、符号化チャネルがアクティブである間に符号化レベルが再度使用されることのないようにアルゴリズムを単に終了するというものである。図12は、ステップ1801で符号化チャネルに対する符号化レベルを再有効化する前にステップ1800で一定期間dだけ遅延する代替的技術を示している。図13は、符号化レベルがゆっくりと調整されて制限された符号化レベルに戻る別の代替的形態を示している。これが行われる期間は、ステップ1900で設定された遅延期間d、およびステップ1902で符号化レベルを増加させるために使用される増分に依存する。ステップ1901は、現在の符号化レベルを制限された符号化レベルと比較して、現在の符号化レベルが制限された符号化レベルより小さいかどうかを判定する。答えが肯定的である限りにおいて、システムはステップ1902に進み、符号化レベルを上げる。制限されたレベルが達成された後、アルゴリズムはステップ1903で終了する。
[0086]高レベルのネットワーク損失を処理するための別の戦略は、インタリーブ方式(「インタリーブモード」と称される)で符号化パケットを送信するように符号器を構成することであり、これにより、異なる標準パケットにまたがって複数の符号化パケットを失うリスクを分散させ、符号化パケットを組み立て直しできる確率を高めることができる。したがって、符号化パケットのグループをそれぞれのグループが単一の標準パケットに対応するように順次送信する代わりに、異なる標準パケットからの符号化パケット同士をインタリーブする。図14は、インタリーブモードの一例を示す。この例では、標準パケットA、B、およびCがそれぞれ符号化パケットA1、A2とB1、B2、B3とC1、C2、C3、C4とにセグメント化されると仮定している。符号化パケットA2、B3、およびC4は、付加的符号化パケットである。各標準パケットに従ってグループ化されたこれらの符号化パケットを送信する代わりに、これらは、k個の標準パケットのグループによってインタリーブされる。図14の例では、k=3である。符号器は、k個の標準パケットに対応する符号化パケットをバッファ1303内に格納する。あるいは、符号器は、所定の期間に、または時間依存の情報が検知されるまで(例えば、ディープパケットインスペクションを介して)、到来する多数のパケットを格納する。並べ替えを回避するために、符号化パケットの集合を、それぞれの標準パケットの最後の2番目のデータがテールにあり、最後に送信され、それぞれの標準パケットの第1の符号化パケットがヘッドにあり、最初に送信されるように左に揃えられる。符号器は、物理的インターフェース1304上で、ヘッドにあるデータ単位を上から下への順序により、または同じ標準パケットからの2つの連続する符号化パケットの送信を最小にする順序により、送信する。図14の例では、符号化パケットは、C1、B1、C2、A1、B2、C3、A2、B3、およびC4の順序で送信されうる。すべての付加的符号化パケットを最後に送信することで遅延を最小にすることができる。このインタリーブは、ランダムに実行することもできる。インタリーブするパケットのグループは、インターフェースから送信されるすべての符号化パケットを含みうるか、またはインタリーブするグループは、同じアプリケーション(例えば、テレビ会議の同じチャネル)、同じ送信先、または事前構成されたグルーピングの符号化パケットを含みうる。
[0087]図15では、インタリーブされた符号化パケットの異なるインタリーブされたグループ1401、1402、1403の符号化パケットをインタリーブすることによって別のレベルのインタリーブが達成される。このようなインタリーブによって、データ単位の大きな損失の影響を最小限度に抑えることができ、採用されている符号化および戦略に応じて、この種類の損失は回復可能であるものとしてよい。
[0088]「インタリーブモード」は、バースト損失に対処する場合にも使用することができる。バースト損失は、現在の損失率(すなわち、式(1)、(2)、(3)、または(4)の結果)が所定の量(例えば、2倍)だけターゲット損失率を超えている場合に検知することができる。バースト損失を処理する一技術は、図16に例示されている。バースト損失が最初に検知されると、損失率の跳ね返りが抑制される。バースト損失が持続すると仮定すると、インタリーブモードへの遷移がステップ2000で実行される。インタリーブモードが有効化されている場合、ステップ2001でランダムモードに戻る条件がチェックされ、検証される。
[0089]インタリーブモードへの遷移の一例は、図17に示されている。アルゴリズムは、インタリーブモードを有効化する前に問題が持続していることを確認するために現在の損失率の跳ね返りを抑制する。この実装では、ステップ2100で初期化されるループを使用し、次いで、ステップ2101で一定期間dの間遅延する。現在の損失率は、ステップ2102で取り出され、ステップ2103でチェックされて、現在の損失率が、この標準的なプロトコルタイプに対して許容可能である、ターゲット損失率の2倍を超えているかどうかを判定する。ステップ2103で答えが肯定的である場合、ステップ2104でループカウンタがインクリメントされ、次いでステップ2105で、ループカウントが最大反復回数に達したかどうかを判定する。答えが否定的である場合、システムはステップ2101に戻り、ステップ2102および2103を繰り返す。ステップ2103で答えが否定的であれば、ルーチンは終了し、ステップ2105で答えが肯定的であれば、ステップ2106でインタリーブモードが有効化される。
[0090]したがって、遅延期間d×最大反復回数において損失率が維持されると仮定すると、キューはインタリーブモードに設定され、アルゴリズムはランダムモードへの復帰を処理するに続く。損失率が引き続きアプリケーションに対するTLRの2倍を超えていなければ、アルゴリズムは終了し、インタリーブモードが無効化される。
[0091]ランダムモードへの復帰は、図18〜21に例示されているいくつかの異なる方法のうちのどれかによって実行されうる。符号化チャネルに実際に使用される方法は、いくつかの方法で選択されうる。インターセプトネットワークデバイスは、すべての符号化チャネルに使用する方法で構成されうる。また、インターセプトネットワークデバイスは、符号化される標準プロトコルに適合するポリシーを有するものとしてよい。あるいは、インターセプトネットワークデバイスは、符号化チャネルが確立されるときに使用する方法をネゴシエートすることができる。
[0092]図18は、ランダムモードに復帰するための最も直接的方法を例示している。この場合、符号化チャネルがインタリーブモードに入っているときにステップ2200でタイマーが起動される。タイマーがタイムアウトになると、ステップ2201でチャネルがランダムモードに戻る。
[0093]図19において、アルゴリズムは、キューがランダムモードに戻る前にインタリーブモードが現在の損失率に影響を及ぼすことを確実にする。現在の損失率は、ランダムモードが有効化される前に期間d×最大反復回数の間にターゲット損失率の2倍より低くなければならない。これを完全にするために、ループを使用して現在の損失率をサンプリングする。ループは、ステップ2300で初期化され、次いで、ステップ2301で一定遅延期間dの間待つ。現在の損失率は、ステップ2302で取り出され、ステップ2303でチェックされて、現在の損失率が、ターゲット損失率の2倍を超えているかどうかを判定する。ステップ2303で答えが肯定的である場合、ステップ2304でループカウンタがインクリメントされ、次いでステップ2305で、ループカウントが最大反復回数に達したかどうかを判定する。答えが否定的である場合、システムはステップ2301に戻り、ステップ2302および2303を繰り返す。ステップ2305で答えが肯定的であれば、ステップ2306でランダムモードが有効化される。
[0094]図20は、現在の損失率を使用する代わりに、平均損失率が使用されることを除き、図19に類似している。ループは、ループカウンタを0に設定し、開始時の平均損失を現在の平均損失に設定することによってステップ2400で初期化され、次いで、システムが、ステップ2401で一定遅延期間dの間待つ。現在の平均損失率は、ステップ2402で取り出され、ステップ2403でチェックされて、現在の平均損失率が、開始時の平均損失を超えているかどうかを判定する。ステップ2403で答えが肯定的である場合、ステップ2404でループカウンタがインクリメントされ、次いでステップ2405で、ループカウントが最大反復回数に達したかどうかを判定する。答えが否定的である場合、システムはステップ2401に戻り、ステップ2402および2403を繰り返す。ステップ2405で答えが肯定的であれば、ステップ2406でランダムモードが有効化される。
[0095]図21は、符号化レベルを変更することも許されていることを除き、図20に類似している。ループは、ループカウンタを0に設定し、開始時の平均損失を現在の平均損失に設定することによってステップ2500で初期化され、次いで、システムが、ステップ2501で一定期間dの間待つ。現在の平均損失率は、ステップ2502で取り出され、ステップ2503でチェックされて、現在の平均損失率が、開始時の平均損失を超えているかどうかを判定する。ステップ2503で答えが否定的であれば、ステップ25607で現在の平均損失率を処理するように符号化レベルが調整され、ステップ2500に戻る。ステップ2503で答えが肯定的である場合、ステップ2504でループカウンタがインクリメントされ、次いでステップ2505で、ループカウントが最大反復回数に達したかどうかを判定する。答えが否定的である場合、システムはステップ2501に戻り、ステップ2501〜2503を繰り返す。ステップ2505で答えが肯定的であれば、ステップ2506でランダムモードが有効化される。
[0096]図22は、TLRの2倍を超える現在の損失率またはバースト損失の両方の著しい変化を処理することを組み合わせたアルゴリズムを示している。この実施形態では、アルゴリズムは、符号化チャネルがインタリーブモードに遷移することを必要としているかどうかを判定することによってステップ300から開始する。これが必要であると仮定して、アルゴリズムは、ステップ3001で符号器レベルバックオフが必要かどうかをチェックして確認する。バックオフが必要かどうかに関係なく、アルゴリズムは、ステップ3002で符号化チャネルがランダムモードにいつ戻るかを決定する。
[0097]ステップ3000でインタリーブモードへの遷移を処理することは、図18と同じようにして行える。ステップ3002で、図18〜21に例示されているアルゴリズムのうちのどれかを使用して、ランダムモードに戻る遷移を見る。
[0098]ステップ3002でバックオフが必要かどうかを判定することは図23に例示されている。このアルゴリズムは、ランダムモードからインタリーブモードへの遷移の効果の跳ね返りを抑制する。この測定は、符号化レベルの増加の後に実行すべきである。これは、一定遅延期間d×最大反復回数の間ループして、現在の損失率をチェックする。ループは、ステップ3100で初期化され、ステップ3101で一定遅延期間dを有する。この遅延期間が終了すると、現在の損失率がステップ3102でサンプリングされ、ステップ3103でTLRの2倍と比較される。現在の損失率がTLRの2倍より大きい場合、超過カウンタがステップ3104でインクリメントされる。そうでない場合、ループカウンタは、ステップ3105でインクリメントされる。このプロセスは、ループカウンタがステップ2506で最大反復回数に達するまで続く。この時点で、超過カウンタがステップ2507でチェックされ、それが最大反復回数に等しければ、ステップ3508で符号化レベルバックオフは有効化される。そうでない場合、アルゴリズムは、ランダムモードへの復帰の処理に進む。
[0099]図24において、デバイス2401、2402は、信頼できないネットワーク性能を有するネイティブの、品質の悪い、ネットワーク接続2404を使用して、アプリケーションサーバ2403(例えば、Youtube(商標)サーバ)にアクセスする。
[00100]いくつかのネットワーク性能増強コーティング技術(NPEC)が存在する。NPECは、一方のロケーションにある符号器および第2のロケーションにある復号器を使用するネットワーク符号化技術を備え、符号器と復号器との間に配置されているセグメント内のネットワークの性能が改善される。NPECは、例えば、上で説明されているNPEC、さらには、米国特許第7,706,365号および米国特許公開第2011/0149087号で説明されているもの、または他の類似の方法を含む。NPECは、一般的に、双方向接続を処理するため一端の符号器/復号器の対および他端の復号器/符号器の対がある必要があることを意味するブックエンディングを必要とするが、それは、これらの技術が一般的に標準プロトコルを修正し、パケットは他方の側に適合する復号器がないと回復可能でないからである。
[00101]図25は、アプリケーションサーバ端にNPECを置くことが可能でない一実施形態を示している。プロキシサーバ2501が、ネットワークに追加され、1つまたは複数のNPEC機構の符号化/復号化を実行する。トラヒックは、プロキシサーバを介してルーティングされ、デバイス2401、2402とプロキシサーバ2501の間のネットワークセグメント2502(通常はアクセスネットワーク)は、プロキシサーバ2404内に実装されている選択されたNPEC仕様に基づき符号化/復号化される。その結果、ネットワークセグメントは、性能および信頼性を高めている。
[00102]プロキシサーバ201は、さらなる性能低下が最小となるようにアプリケーションサーバ2403と同一の場所に置くことができる。別の実施形態では、NPECサーバは、プロキシサーバと同一の場所に展開される。
[00103]プロキシサーバ内で上述のNPECを使用することで、バックアップアプリケーションは、バックアップ時間を80%短縮することができる。障害回復は、5倍改善され、大きなファイルの転送は、6倍短縮されうる。
[00104]Traversal Using Relays around NAT(TURN)は、ネットワークアドレス変換器(NAT)またはファイアウォールの背後にある要素がTCPまたはUDP接続を介して入ってくるデータを受信することを可能にするプロトコルである。図26は、TURNサーバ2601がNPECサービスを実装し、かつクライアント2602、2603のうちの一方または両方がNPECで保護されているネットワークセグメント2604内の増強された/信頼できる品質を利用することができる一例を示している。
[00105]性能依存のアプリケーションは、NPECの符号化/復号化を実装し、次いでプロキシサーバまたはTURNサーバを通じてNPECサービスにアクセスするように設計されうる。あるいは、デバイスは、すでに、1つまたは複数のNPEC対応ドライバを備えている場合がある。
[00106]サービスとして品質を提供する別の実施形態は、VPNサーバを使用するものである。1つまたは複数のNPEC符号化/復号化機構は、VPNサーバ内に、およびVPNクライアント内に実装することができ、これにより、クライアントとVPNサーバとの間の少なくとも一部が品質を高める。
[00107]プロキシサーバ実施形態は、NPEC管理セグメントの性能が適切であることを保証するため適宜測定結果を集め、ネットワークエンジニアリングが適切であることを保証するため測定結果に基づき性能解析を実行することができる。
[00108]以下の説明では、説明を目的として、本発明を完全に理解できるようにする多数の詳細を述べている。しかし、当業者には、本発明の実施形態を実施するためにこれらの具体的詳細事項は必要ないということは明白であろう。他の場合には、本発明をわかりにくくしないために、よく知られている電気的構造および回路はブロック図形式で示されている。例えば、本明細書で説明されている発明の実施形態がソフトウェアルーチン、ハードウェア回路、ファームウェア、またはこれらの組み合わせとして実装されるかどうかに関して、具体的詳細を述べていない。
[00109]本発明の実施形態は、サーバまたは他のコンピューティングデバイスなどのエンドポイント、および関連する符号化コンポーネントを有するネットワーク内に実装されうる。符号化コンポーネントおよび説明されている方法は、ハードウェア、ソフトウェア、またはこれらの組み合わせで実装することができる。ソフトウェアで実装される部分は、機械可読媒体(コンピュータ可読媒体、プロセッサ可読媒体、またはコンピュータ可読プログラムコードが中に具現化されているコンピュータ使用可能媒体とも称される)内に格納されているソフトウェア製品として表現することができる。機械可読媒体は、ディスケット、コンパクトディスク読出し専用メモリ(CD−ROM)、メモリデバイス(揮発性または不揮発性)、または類似の記憶装置機構を含む磁気記憶媒体、光記憶媒体、または電気的記憶媒体を含む好適な有形の媒体とすることができる。機械可読媒体は、実行されたときに方法の中のステップをプロセッサに実行させる、さまざまな命令セット、コード列、構成情報、または他のデータを収めることができる。当業者であれば、説明されている実施形態を実装するために必要な他の命令および演算も機械可読媒体に格納できることを理解するであろう。機械可読媒体から実行しているソフトウェアは、記述されているタスクを実行する回路とインターフェースすることができる。
[00110]本発明の特定の実施形態およびアプリケーションが図示され説明されているが、本発明が本明細書に開示されている正確な構造および構成に限定されないこと、および付属の請求項で定められている発明の精神および範囲から逸脱することなくさまざまな修正、変更、および改変は前記の説明から明らかであることは理解されるであろう。
10 送信元エンドステーション
20 ネットワーク
30 送信先エンドステーション
40 ネットワークデバイス
50 ネットワークデバイス
60 ネイティブインターフェース
70 符号化インターフェース
80 復号器
90 符号器
400 標準パケット
402 セグメント
404 追加セグメント
1106 インターセプトネットワークデバイス
1107 インターセプトネットワークデバイス
1108 符号器
1109 復号器
1202 インターセプトネットワークデバイス
1203 インターセプトネットワークデバイス
1204 フロー
1205 フロー
1206 フロー
1207 インターセプトネットワークデバイス
1208 インターセプトネットワークデバイス
1209 インターセプトネットワークデバイス
1210 インターセプトネットワークデバイス
1211 セッション
1212 セッション
1303 バッファ
1304 物理的インターフェース

Claims (14)

  1. ユーザデバイスをアプリケーションサーバに結合するためのアクセスネットワークの性能を改善する方法であって、
    ネットワーク性能増強コーディング(NPEC)を使用してユーザデバイスにおいてデータを符号化するステップと、
    符号化された前記データを前記アプリケーションサーバに結合されている中間サーバに送信するステップと、
    前記NPECを使用して前記中間サーバにおいて符号化された前記データを復号化し、復号化された前記データを前記アプリケーションサーバに送信するステップと
    を含む方法。
  2. 請求項1に記載の方法であって、前記中間サーバは、プロキシサーバである、方法。
  3. 請求項2に記載の方法であって、前記プロキシサーバは、前記アプリケーションサーバと同一の場所に置かれる、方法。
  4. 請求項1に記載の方法であって、前記中間サーバは、プロキシサーバ、Traversal Using Relays−Around−Network−Address−Translator(TURN)サーバ、および仮想プライベートネットワーク(VPN)サーバからなる群から選択される、方法。
  5. 請求項1に記載の方法であって、前記中間サーバは、1つまたは複数のNPECを使用して符号化および復号化を行うことができる、方法。
  6. 請求項1に記載の方法であって、
    前記中間サーバにおいて前記アプリケーションサーバからアプリケーションデータを受信するステップと、
    前記NPECを使用して前記アプリケーションサーバにおいて前記アプリケーションデータを符号化するステップと、
    符号化された前記アプリケーションデータを前記ユーザデバイスに送信するステップと、
    前記NPECを使用して、前記ユーザデバイスにおいて、符号化された前記アプリケーションデータを復号化するステップと
    をさらに含む方法。
  7. 請求項1に記載の方法であって、前記中間サーバは、プロキシサーバと同一の場所に置かれているNPECサーバを含む、方法。
  8. 請求項1に記載の方法であって、前記中間サーバは、プロキシサーバ、Traversal Using Relays−Around−Network−Address−Translator(TURN)サーバ、および仮想プライベートネットワーク(VPN)サーバからなる群から選択される、方法。
  9. ユーザデバイスをアプリケーションサーバに結合するためのアクセスネットワークの性能を改善するためのシステムであって、
    前記アクセスネットワークを介して結合されたユーザデバイスおよび中間サーバを備え、
    前記ユーザデバイスは、ネットワーク性能増強コーディング(NPEC)を使用してデータを符号化し、符号化された前記データを前記アクセスネットワークを介して前記中間サーバに送信するように構成されたプロセッサを有し、
    前記中間サーバは符号化された前記データを受信するように構成され、前記NPECを使用して符号化された前記データを復号化し、複合化された前記データを前記アプリケーションサーバに送信するように構成されたプロセッサを有する、
    システム。
  10. 請求項9に記載のシステムであって、前記中間サーバは、プロキシサーバである、システム。
  11. 請求項10に記載のシステムであって、前記プロキシサーバは、前記アプリケーションサーバと同一の場所に置かれる、システム。
  12. 請求項9に記載のシステムであって、前記中間サーバは、プロキシサーバ、Traversal Using Relays−Around−Network−Address−Translator(TURN)サーバ、および仮想プライベートネットワーク(VPN)サーバからなる群から選択される、システム。
  13. 請求項9に記載のシステムであって、前記中間サーバは、1つまたは複数のNPECを使用して符号化および復号化を行うことができる、システム。
  14. 請求項9に記載のシステムであって、
    前記中間サーバの前記プロセッサは、前記アプリケーションサーバからアプリケーションデータを受信し、前記NPECを使用して前記アプリケーションデータを符号化し、符号化された前記アプリケーションデータを前記ユーザデバイスに送信するようにさらに構成され、
    前記ユーザデバイスの前記プロセッサは、前記NPECを使用して符号化された前記アプリケーションデータを復号化するようにさらに構成された、
    システム。
JP2014002097A 2013-01-10 2014-01-09 サービスとしてのネットワーク品質 Pending JP2014135724A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/738,006 US9189307B2 (en) 2004-08-06 2013-01-10 Method of improving the performance of an access network for coupling user devices to an application server
US13/738,006 2013-01-10

Publications (1)

Publication Number Publication Date
JP2014135724A true JP2014135724A (ja) 2014-07-24

Family

ID=49955900

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014002097A Pending JP2014135724A (ja) 2013-01-10 2014-01-09 サービスとしてのネットワーク品質

Country Status (3)

Country Link
EP (1) EP2755342A1 (ja)
JP (1) JP2014135724A (ja)
CN (1) CN103929270A (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113342526B (zh) * 2021-06-09 2023-07-07 河南工业职业技术学院 云计算移动网络资源动态管控方法、系统、终端及介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7706365B2 (en) 2003-11-25 2010-04-27 California Institute Of Technology Randomized distributed network coding
US7953114B2 (en) 2004-08-06 2011-05-31 Ipeak Networks Incorporated System and method for achieving accelerated throughput
US8437370B2 (en) * 2011-02-04 2013-05-07 LiveQoS Inc. Methods for achieving target loss ratio
US7742501B2 (en) * 2004-08-06 2010-06-22 Ipeak Networks Incorporated System and method for higher throughput through a transportation network
US8009696B2 (en) 2004-08-06 2011-08-30 Ipeak Networks Incorporated System and method for achieving accelerated throughput
US20100023842A1 (en) * 2008-07-25 2010-01-28 Nortel Networks Limited Multisegment loss protection
US8638851B2 (en) 2009-12-23 2014-01-28 Apple Inc. Joint bandwidth detection algorithm for real-time communication

Also Published As

Publication number Publication date
EP2755342A1 (en) 2014-07-16
CN103929270A (zh) 2014-07-16

Similar Documents

Publication Publication Date Title
US20210112148A1 (en) System and method for achieving accelerated throughput
US20240205151A1 (en) Systems, Apparatuses and Methods for Network Packet Management
US10574742B2 (en) Network quality as a service
JP2015505183A (ja) ターゲット損失率を達成するための方法
US8437370B2 (en) Methods for achieving target loss ratio
US9893836B2 (en) System and method for achieving accelerated throughput
US9189307B2 (en) Method of improving the performance of an access network for coupling user devices to an application server
CN109923809B (zh) 利用前向纠错的编码和解码方法、以及编码和解码系统
US9537611B2 (en) Method and apparatus for improving the performance of TCP and other network protocols in a communications network using proxy servers
KR20210134787A (ko) 데이터 스트림에 대한 전송 방법 및 디바이스
Liang et al. TCP-RTM: Using TCP for real time multimedia applications
JP3934073B2 (ja) リアルタイム情報の伝達システム、リアルタイム情報の送信装置、リアルタイム情報の伝達方法及びプログラム
JP2014135724A (ja) サービスとしてのネットワーク品質
Forsberg Packet Loss Recovery with Forward Error Correction (FEC)