JP2016534656A - リアルタイムビデオアプリケーションのためのルータのためのユーザ体感品質に基づくキュー管理 - Google Patents

リアルタイムビデオアプリケーションのためのルータのためのユーザ体感品質に基づくキュー管理 Download PDF

Info

Publication number
JP2016534656A
JP2016534656A JP2016540438A JP2016540438A JP2016534656A JP 2016534656 A JP2016534656 A JP 2016534656A JP 2016540438 A JP2016540438 A JP 2016540438A JP 2016540438 A JP2016540438 A JP 2016540438A JP 2016534656 A JP2016534656 A JP 2016534656A
Authority
JP
Japan
Prior art keywords
packet
real
node
traffic flow
time video
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.)
Granted
Application number
JP2016540438A
Other languages
English (en)
Other versions
JP6307615B2 (ja
Inventor
リエンピン マー
リエンピン マー
カランパチス ディミトリス
カランパチス ディミトリス
エス．スタンバーグ グレゴリー
エス．スタンバーグ グレゴリー
カール サミアン
カール サミアン
ペルティエ ギレーン
ペルティエ ギレーン
バラスブラマニアン アナンサラマン
バラスブラマニアン アナンサラマン
リウ　ウェイミン
ウェイミン リウ
エー．ディファジオ ロバート
エー．ディファジオ ロバート
ネフ ラルフ
ネフ ラルフ
ケロフスキー ルイス
ケロフスキー ルイス
Original Assignee
ヴィド スケール インコーポレイテッド
ヴィド スケール インコーポレイテッド
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 ヴィド スケール インコーポレイテッド, ヴィド スケール インコーポレイテッド filed Critical ヴィド スケール インコーポレイテッド
Publication of JP2016534656A publication Critical patent/JP2016534656A/ja
Application granted granted Critical
Publication of JP6307615B2 publication Critical patent/JP6307615B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • 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/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/6215—Individual queue per QOS, rate or priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

リアルタイムトラフィックビデオフローを管理するシステム、方法、および手段が開示される。ノードは、第１のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられ得、およびノードにおいて第２のリアルタイムビデオトラフィックフローに関連付けられ得る。第１のリアルタイムビデオトラフィックフローは、複数のパケットを備え得、および各パケットは、消失パケットインジケータを備え得る。ノードは、第１のリアルタイムビデオトラフィックフロー内の第１のパケットを廃棄し、廃棄したパケットを示すように、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新し、および廃棄したパケットに基づいて、第１のリアルタイムビデオトラフィックフロー内の第２のパケットに対する消失パケットインジケータを更新するように構成され得る。

Description

本発明は、リアルタイムビデオアプリケーションのためのルータのためのユーザ体感品質に基づくキュー管理に関する。
本出願は、２０１３年９月６日に出願した米国特許仮出願第６１／８７４，７１２号、２０１３年９月２０日に出願した米国特許仮出願第６１／８８０，８０６号、２０１４年４月４日に出願した米国特許仮出願第６１／９７５，４９９号、および２０１４年７月２５日に出願した米国特許仮出願第６２／０２９，２３９号の利益を主張するものであり、これらの内容は各々、その全体が参照により本明細書に組み込まれる。
ビデオテレフォニーは、ワイヤレスネットワークを経由して搬送されるトラフィックの増大しつつあるセグメントである。さまざまなビデオテレフォニーアプリケーション（例えば、テレビ会議アプリケーション）によって生成されるデータパケットのフローは、さまざまなキュー管理技法を使用して制御され得る。キュー管理の設計は、サービス品質（ＱｏＳ）の性能を考慮してよい。
リアルタイムトラフィックビデオフローを管理するシステム、方法、および手段が開示される。ノードは、第１のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられ得る。第１のリアルタイムビデオトラフィックフローは、複数のパケットを備え得る。各パケットは、消失パケットインジケータを備え得る。ノードは、第２のリアルタイムビデオトラフィックフローを受信するように構成され得る。状態変数は、ノードにおいて第２のリアルタイムビデオトラフィックフローに関連付けられ得る。第２のリアルタイムビデオトラフィックフローは複数のパケットを備え得、各パケットは、消失パケットインジケータを備え得る。ノードは、第１のリアルタイムビデオトラフィックフロー内の第１のパケットを廃棄するように構成され得る。ノードは、廃棄されるパケットを示すように、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように構成され得る。ノードは、廃棄されたパケットに基づいて、第１のリアルタイムビデオトラフィックフロー内の第２のパケットのための消失パケットインジケータを更新するように構成され得る。
ノードは、第１のリアルタイムビデオトラフィックフローの状態変数を第２のリアルタイムビデオトラフィックフローの状態変数と比較するように構成されたプロセッサを備え得る。第２のリアルタイムビデオトラフィックフローの状態変数は、廃棄されるパケットを示さないことがある。ノードは、第１のリアルタイムビデオトラフィックフローの状態変数が廃棄されるパケットを示すことに基づいて、第１のリアルタイムトラフィックフローのパケットを廃棄すると決定する（例えば、第２のリアルタイムトラフィックフローのパケットを廃棄することとは反対に）ように構成され得る。
ノードは、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定したことに基づいてノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定したことに基づいて第１のリアルタイムビデオトラフィックフローの第３のパケットのための消失パケットインジケータを更新するように構成されたプロセッサを備え得る。ノードは、第３のパケットのパケットヘッダ内のビットは、第３のパケットがリフレッシュフレームを備えることを示すと決定し、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備える、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備え得る。リフレッシュフレームは、部分的リフレッシュフレームを備え得る。第３のパケットは、Ｉフレームを備え得る。
ノードは、第１のリアルタイムビデオトラフィックフローの第２のパケットを第２のノードに送るように構成されたプロセッサを備え得る。消失パケットインジケータは、第２のノードに、第２のノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように指示する。
ノードは、状態変数を使用して、パケットロスを、劣化させられたパケットストリームに集中させるように構成され得る。フロー優先度インジケータ（ＦＰＩ）は、消失パケットインジケータを備え得る。
ノードは、第２のパケットはリフレッシュフレームを備えないと決定することを含む、廃棄されるパケットに基づいてリアルタイムビデオトラフィックフロー内の第２のパケットのための消失パケットインジケータを更新することを構成されたプロセッサを備え得る。ノードは、廃棄されるパケットと、第２のパケットがリフレッシュフレームを備えないという決定とに基づいて、リアルタイムビデオトラフィックフロー内の第２のパケットのための消失パケットインジケータを更新するように構成されたプロセッサを備え得る。消失パケットインジケータは、パケットのパケットヘッダ内のビットを含み得る。
ノードは、事前構成された条件のセットに基づいて状態変数を更新するように構成されたプロセッサを備え得る。ノードは、事前構成された条件のセットから条件を選択し、選択された条件を事前構成された閾値と比較し、選択された条件が事前構成された閾値を超えるかどうかを決定し、選択された条件が事前構成された閾値を超えると決定すると、状態変数を更新するように構成されたプロセッサを備え得る。ノードは、事前構成された規則のセットにより第１のリアルタイムビデオトラフィックフローの第１のパケットを廃棄すると決定するように構成されたプロセッサを備え得る。
ノードは、ルータ、無線送受信ユニット（ＷＴＲＵ）、またはｅｖｏｌｖｅｄノードＢ（ｅＮＢ）であってよい。
ノードは、第１のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられ得る。状態変数は、パケットロスを示し得る。ノードは、第２のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得、状態変数は、ノードにおいて第２のリアルタイムビデオトラフィックフローに関連付けられ、状態変数はパケットロスを示さない。ノードは、第１のリアルタイムビデオトラフィックフローのパケットまたは第２のリアルタイムビデオトラフィックフローのパケットを廃棄すると決定するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの状態変数を第２のリアルタイムビデオトラフィックフローの状態変数と比較するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの状態変数がパケットロスを示すことに基づいて第１のリアルタイムトラフィックフローのパケットを廃棄すると決定するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフロー内の廃棄されるパケットに続く１または複数のパケットを、パケットが廃棄されたことを示すようにマーキングするように構成されたプロセッサを備え得る。
ノードは、複数のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいて各リアルタイムビデオトラフィックフローに関連付けられ得る。各リアルタイムビデオトラフィックフローは、複数のパケットを備え得る。各パケットは、消失パケットインジケータを備え得る。ノードは、複数のリアルタイムビデオトラフィックフローのうちのリアルタイムビデオトラフィックフローの第１のパケットの消失パケットインジケータがパケットロスを示すと決定するように構成されたプロセッサを備え得る。ノードは、第１のパケットの消失パケットインジケータに基づいてノードにおいてリアルタイムビデオトラフィックフローに関連付けられた状態変数を、パケットロスを示すように更新するように構成されたプロセッサを備え得る。ノードは、リアルタイムビデオトラフィックフローに関連付けられた状態変数がパケットロスを示すことに基づいて後続のパケットロスをリアルタイムビデオトラフィックフローに向けるように構成されたプロセッサを備え得る。ノードは、第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備え得る。ノードは、第３のパケットがリフレッシュフレームを備えると決定したことに基づいて状態変数を更新するように構成されたプロセッサを備え得る。ノードは、第２のパケットの消失パケットインジケータがパケットロスを示さないと決定するように構成されたプロセッサを備え得る。
ノードは、複数のＲＴＰパケットを備えるリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいてリアルタイムビデオトラフィックフローに関連付けられ得る。ノードは、リアルタイムビデオトラフィックフローの第１のＲＴＰパケットのシーケンス番号を決定するように構成されたプロセッサを備え得る。ノードは、リアルタイムビデオトラフィックフローの第２のＲＴＰパケットのシーケンス番号を決定するように構成されたプロセッサを備え得る。ノードは、第１のＲＴＰパケットと第２のＲＴＰパケットとの間でシーケンス番号のギャップ（gap）を検出するように構成されたプロセッサを備え得る。ノードは、ギャップの検出に基づいてリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように構成されたプロセッサを備え得る。ノードは、リアルタイムビデオトラフィックフローの送信機に報告を送るように構成されたプロセッサを備え得る。この報告は、リアルタイムビデオトラフィックフローの第１のＲＴＰパケットと第２のＲＴＰパケットとの間でのシーケンス番号のギャップを示し得る。
ノードは、リアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいてリアルタイムビデオトラフィックフローに関連付けられ得る。状態変数は、ノードにおけるリアルタイムビデオトラフィックフローのためのロス状態を示し得る。ノードは、リアルタイムビデオトラフィックフローのラウンドトリップタイム（ＲＴＴ）を決定するように構成されたプロセッサを備え得る。ノードは、ＲＴＴに基づいてロス状態がないことを示すようにリアルタイムビデオトラフィックフローに関連付けられた状態変数を変更するように構成されたプロセッサを備え得る。ＲＴＴは、所定の値であってよい。ＲＴＴは、リアルタイムビデオトラフィックフローの発信元と送信先との間の伝送制御プロトコル（ＴＣＰ）接続に基づいて推定され得る。ＲＴＴは、キューイング遅延を使用してＲＴＴの下限を構築することによって決定され得る。
１または複数の開示される実施形態が実施され得る例示的な通信システムのシステム図である。 図１Ａに示される通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａに示される通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ａに示される通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 図１Ａに示される通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 ＱｏＥリソース割り振りのための例示的なダウンリンク使用事例を示す図である。 ＱｏＥリソース割り振りのための例示的なアップリンク使用事例を示す図である。 ユーザプレーン内のプロトコルスタック内のＧＴＰ−Ｕの例示的なロケーションを示す図である。 ダウンリンクビデオＱｏＥアウェアな（QoE aware）リソース割り振りの例を示す流れ図である。 ＧＴＰ−Ｕトンネリングのための例示的なパケットフォーマットを示す図である。 スタンドアロンＴＤＦを有するダウンリンクビデオＱｏＥアウェアなリソース割り振りの一例を示す流れ図である。 ビデオアプリケーションのためのアップリンクＱｏＥアウェアなリソース割り振りの例を示す図である。 例示的なビデオ会議システムを示す図である。 例示的なビデオ会議ネットワークを示す図である。 ロス集中に基づくパケット廃棄方式の例を示す図である。 パケットがランダムに廃棄される例を示す図である。 ロス集中に基づくキュー管理の例示的な呼フローを示す図である。 後続のビデオフレームのチャネルひずみに対する、ビデオフレームを消失することの例示的な影響を示すグラフである。 例示的なシーケンスのためのピーク信号対雑音比（ＰＳＮＲ）の例示的な累積分布関数（ＣＤＦ）を示すグラフである。 別の例示的なシーケンスのためのピーク信号対雑音比（ＰＳＮＲ）の例示的な累積分布関数（ＣＤＦ）を示すグラフである。 アクティブキュー管理アルゴリズムにロス集中を追加することを示す例示的な流れ図である。 通信ネットワーク内の送信機および受信機に送信され得る明示的輻輳通知（ＥＣＮ）フィードバック報告の例示的なフォーマットの図である。 ＬＣ−Ｃｏｄｅｌデキューイング動作の例の流れ図である。 ＬＣ−Ｃｏｄｅｌエンキューイング動作の例の流れ図である。 単一輻輳されたルータと二重輻輳されたルータ（single and double congested routers）の両方を含む、ビデオトラフィックおよびバックグラウンドＴＣＰトラフィックを有するダンベルネットワークトポロジにおいて用いられるＬＣ−Ｃｏｄｅｌの例の図である。 連続フレームフリーズの長さに関する条件付き分布の例の図である。 ネットワークシミュレータにおいてＬＣ−Ｃｏｄｅｌを用いるリアルタイムビデオトラフィックの例の図である。 後方廃棄（ＤＴ）アルゴリズムを使用してロス集中の特徴付けを近似するように構成されたキューの例の図である。 ＤＴのピーク信号対雑音比（ＰＳＮＲ）のＣＤＦの例のグラフである。 ビット（例えば、ビットａ、ｂ、ｃ）を搬送するように構成された例示的なＭＰＬＳラベルの図である。 ダウンストリームルータによる開ループシナリオの例示的な検出の図である。
次に、例示的な実施形態の詳細な説明が、さまざまな図を参照しながら説明される。本説明は、可能な実装形態の詳細な例を提供するが、詳細は例示的であり、適用の範囲を決して限定しないことを意図することに留意されたい。
図１Ａは、１または複数の開示される実施形態が実施され得る例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する多元接続システムであってよい。通信システム１００は、ワイヤレス帯域幅を含むシステムリソースの共有によって、複数のワイヤレスユーザがそのようなコンテンツにアクセスすることを可能にし得る。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの１または複数のチャネルアクセス方法を用い得る。
図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（全体的にすなわち総称して、ＷＴＲＵ１０２と呼ばれることがある）と、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５と、コアネットワーク１０６／１０７／１０９と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含み得るが、開示される実施形態は任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、ワイヤレス環境において動作および／または通信するように構成された任意のタイプのデバイスであってよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、移動局、固定された加入者ユニットまたはモバイル加入者ユニット、ページャ、セルラー式電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家電などを含み得る。
通信システム１００は、基地局１１４ａと、基地局１１４ｂも含み得る。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの１または複数の通信ネットワークへのアクセスを容易にするためにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスでインターフェイス接続するように構成された任意のタイプのデバイスであってよい。例として、基地局１１４ａ、１１４ｂは、基地送受信局（ＢＴＳ）、ノードＢ、ｅＮｏｄｅＢ、ホームノードＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであってよい。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは任意の数の相互接続された基地局および／またはネットワーク要素を含んでよいことが理解されるであろう。
基地局１１４ａはＲＡＮ１０３／１０４／１０５の一部であってよく、ＲＡＮ１０３／１０４／１０５は、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなどの他の基地局および／またはネットワーク要素（図示せず）も含んでよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内のワイヤレス信号を送信および／または受信するように構成されてよく、この特定の地理的領域はセル（図示せず）と呼ばれることがある。セルは、セルセクタにさらに分割され得る。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバ、すなわち、セルのセクタごとに１つのトランシーバを含み得る。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を用いてよく、したがって、セルのセクタごとに複数のトランシーバを利用してよい。
基地局１１４ａ、１１４ｂは、エアインターフェイス１１５／１１６／１１７を経由してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数と通信し得、エアインターフェイス１１５／１１６／１１７は、任意の適切なワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であってよい。エアインターフェイス１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立し得る。
より具体的には、前述のように、通信システム１００は多元接続システムであってよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１または複数のチャネルアクセス方式を用い得る。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施してよく、これは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェイス１１５／１１６／１１７を確立し得る。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／またはＥｖｏｌｖｅｄ ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含み得る。
別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、Ｅｖｏｌｖｅｄ ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施してよく、無線技術は、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を使用してエアインターフェイス１１５／１１６／１１７を確立し得る。
他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施し得る。
図１Ａの基地局１１４ｂは、例えば、ワイヤレスルータ、ホームノードＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってよく、事業所、家庭、乗り物、キャンパスなどの局所化されたエリア内のワイヤレス接続性を容易にするために任意の適切なＲＡＴを利用してよい。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立し得る。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立し得る。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラーに基づいたＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立し得る。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を持ち得る。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスするよう要求されないことがある。
ＲＡＮ１０３／１０４／１０５はコアネットワーク１０６／１０７／１０９と通信してよく、コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、および／またはｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数に提供するように構成された任意のタイプのネットワークであってよい。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、支払い請求サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続性、ビデオ配給などを提供し、および／またはユーザ認証などのハイレベルセキュリティ機能を実行し得る。図１Ａには示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを用いる他のＲＡＮと直接または間接的に通信し得ることが理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用し得るＲＡＮ１０３／１０４／１０５に接続されることに加えて、コアネットワーク１０６／１０７／１０９は、ＧＳＭ無線技術を用いる別のＲＡＮ（図示せず）とも通信し得る。
コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするゲートウェイとして働くことがある。ＰＳＴＮ１０８は、加入電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの一般的な通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含み得る。ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される有線通信ネットワークまたはワイヤレス通信ネットワークを含み得る。例えば、ネットワーク１１２は、１または複数のＲＡＮに接続された別のコアネットワークを含んでよく、このＲＡＮは、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを用いてよい。
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたはすべては、マルチモード能力を含んでよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なるワイヤレスリンクを経由して異なるワイヤレスネットワークと通信するための複数のトランシーバを含み得る。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラーに基づいた無線技術を用い得る基地局１１４ａと、ＩＥＥＥ８０２無線技術を用い得る基地局１１４ｂと通信するように構成され得る。
図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、トランシーバ１２０と、送信／受信要素１２２と、スピーカ／マイクロホン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、ノンリムーバブルメモリ１３０と、リムーバブルメモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含み得る。ＷＴＲＵ１０２は、一実施形態と一致したままでありながら、前述の要素の任意の副組み合わせを含み得ることが理解されるであろう。また、実施形態は、基地局１１４ａおよび１１４ｂ、ならびに／またはとりわけ、限定するものではないが、送受信局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、ｅｖｏｌｖｅｄホームノードＢ（ｅＮｏｄｅＢ）、ホームｅｖｏｌｖｅｄノードＢ（ＨｅＮＢまたはＨｅＮｏｄｅＢ）、ホームｅｖｏｌｖｅｄノードＢゲートウェイ、およびプロキシノードなどの、基地局１１４ａおよび１１４ｂが表し得るノードが、図１Ｂに示され本明細書で説明される要素のいくつかまたはすべてを含み得ることを企図する。
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、ステートマシンなどであってよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２がワイヤレス環境内で動作することを可能にする他の任意の機能を実行し得る。プロセッサ１１８はトランシーバ１２０に結合されてよく、トランシーバ１２０は送信／受信要素１２２に結合されてよい。図１Ｂは、プロセッサ１１８およびトランシーバ１２０を別個の構成要素として示しているが、プロセッサ１１８およびトランシーバ１２０は、一緒に電子パッケージまたはチップに一体化され得ることが理解されるであろう。
送信／受信要素１２２は、エアインターフェイス１１５／１１６／１１７を経由して基地局（例えば、基地局１１４ａ）に信号を送信する、またはこれから信号を受信するように構成され得る。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってよい。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されたエミッタ／検出器であってよい。さらに別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送信／受信要素１２２は、ワイヤレス信号の任意の組み合わせを送信および／または受信するように構成され得ることが理解されるであろう。
さらに、送信／受信要素１２２は、図１Ｂでは単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を用いてよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェイス１１５／１１６／１１７を経由してワイヤレス信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含み得る。
トランシーバ１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成され得る。前述のように、ＷＴＲＵ１０２は、マルチモード能力を持ち得る。したがって、トランシーバ１２０は、例えば、ＷＴＲＵ１０２がＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数のトランシーバを含み得る。
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてよく、これからユーザ入力データを受信してよい。プロセッサ１１８はまた、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力し得る。さらに、プロセッサ１１８は、ノンリムーバブルメモリ１３０および／またはリムーバブルメモリ１３２などの任意のタイプの適切なメモリからの情報にアクセスし、これらにデータを記憶し得る。ノンリムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリストレージデバイスを含み得る。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上などの、ＷＴＲＵ１０２上に物理的に設置されていないメモリからの情報にアクセスし、これにデータを記憶し得る。
プロセッサ１１８は、電源１３４から電力を受信してよく、ＷＴＲＵ１０２内の他の構成要素に電力を分散させるおよび／または制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスであってよい。例えば、電源１３４は、１または複数の乾電池バッテリ（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−イオン）など）、太陽電池、燃料電池などを含み得る。
プロセッサ１１８はＧＰＳチップセット１３６にも結合され得、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在のロケーションに関するロケーション情報（例えば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェイス１１５／１１６／１１７を経由してロケーション情報を受信するおよび／または２つ以上の近くの基地局から信号が受信されるタイミングに基づいてそのロケーションを決定し得る。ＷＴＲＵ１０２は、一実施形態と一致したままでありながら、任意の適切なロケーション決定実装形態によってロケーション情報を獲得し得ることが理解されるであろう。
プロセッサ１１８は他の周辺機器１３８にさらに結合されてよく、周辺機器１３８は、追加の特徴、機能、および／または有線接続性もしくはワイヤレス接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含み得る。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオのための）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤー、メディアプレーヤー、ビデオゲームプレーヤーモジュール、インターネットブラウザなどを含み得る。
図１Ｃは、一実施形態によるＲＡＮ１０３およびコアネットワーク１０６のシステム図である。前述のように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を用いて、エアインターフェイス１１５を経由してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信し得る。ＲＡＮ１０３は、コアネットワーク１０６とも通信し得る。図１Ｃに示されるように、ＲＡＮ１０３はノードＢ１４０ａ、１４０ｂ、１４０ｃを含んでよく、ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々、エアインターフェイス１１５を経由してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数のトランシーバを含み得る。ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられ得る。ＲＡＮ１０３は、ＲＮＣ１４２ａ、１４２ｂも含み得る。ＲＡＮ１０３は、一実施形態と一致したままでありながら、任意の数のノードＢとＲＮＣとを含んでよいことが理解されるであろう。
図１Ｃに示されるように、ノードＢ１４０ａ、１４０ｂはＲＮＣ１４２ａと通信し得る。さらに、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信し得る。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、ｌｕｂインターフェイスを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信し得る。ＲＮＣ１４２ａ、１４２ｂは、ｌｕｒインターフェイスを介して互いと通信し得る。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されたそれぞれのノードＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成され得る。さらに、ＲＮＣ１４２ａ、１４２ｂの各々は、アウターループ電力制御、負荷制御、受付制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化などの他の機能を行うまたはサポートするように構成され得る。
図１Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含み得る。前述の要素の各々はコアネットワーク１０６の一部として示されているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または動作されてよいことが理解されるであろう。
ＲＡＮ１０３内のＲＮＣ１４２ａは、ｌｕＣＳインターフェイスを介してコアネットワーク１０６内のＭＳＣ１４６に接続され得る。ＭＳＣ１４６はＭＧＷ１４４に接続され得る。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換網へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。
ＲＡＮ１０３内のＲＮＣ１４２ａは、ｌｕＰＳインターフェイスを介してコアネットワーク１０６内のＳＧＳＮ１４８にも接続され得る。ＳＧＳＮ１４８はＧＧＳＮ１５０に接続され得る。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換網へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。
前述のように、コアネットワーク１０６はネットワーク１１２にも接続されてよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される、他の有線ネットワークまたはワイヤレスネットワークを含み得る。
図１Ｄは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０７のシステム図である。前述のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を用いて、エアインターフェイス１１６を経由してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信し得る。ＲＡＮ１０４は、コアネットワーク１０７とも通信し得る。
ＲＡＮ１０４はｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃを含み得るが、ＲＡＮ１０４は、一実施形態と一致したままでありながら、任意の数のｅＮｏｄｅ−Ｂを含んでよいことが理解されるであろう。ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは各々、エアインターフェイス１１６を経由してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数のトランシーバを含み得る。一実施形態では、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実施し得る。したがって、ｅＮｏｄｅＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、ＷＴＲＵ１０２ａからワイヤレス信号を受信し得る。
ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）に関連付けられてよく、アップリンクおよび／またはダウンリンクなどにおける無線リソース管理判定、ハンドオーバ判定、ユーザのスケジューリングを処理するように構成され得る。図１Ｄに示されるように、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェイスを経由して互いと通信し得る。
図１Ｄに示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２と、サービングゲートウェイ１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６とを含み得る。前述の要素の各々はコアネットワーク１０７の一部として示されているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または動作されてよいことが理解されるであろう。
ＭＭＥ１６２は、Ｓ１インターフェイスを介してＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてよく、制御ノードとして働き得る。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中に特定のサービングゲートウェイを選択することなどを担当し得る。ＭＭＥ１６２はまた、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を用いる他のＲＡＮ（図示せず）とを切り換えるための制御プレーン機能を提供し得る。
サービングゲートウェイ１６４は、Ｓ１インターフェイスを介してＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。サービングゲートウェイ１６４は一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／からユーザデータパケットをルーティングおよびフォワーディングし得る。サービングゲートウェイ１６４は、ｅＮｏｄｅＢ間ハンドオーバ中にユーザプレーンをアンカリングすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどの他の機能も実行し得る。
サービングゲートウェイ１６４はＰＤＮゲートウェイ１６６にも接続されてよく、ＰＤＮゲートウェイ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換網へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。
コアネットワーク１０７は、他のネットワークとの通信を容易にし得る。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換網へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のインターフェイスとして働くＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよいし、またはこれと通信してもよい。さらに、コアネットワーク１０７は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される、他の有線ネットワークまたはワイヤレスネットワークを含み得る。
図１Ｅは、一実施形態によるＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を用いてエアインターフェイス１１７を経由してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するアクセスサービスネットワーク（ＡＳＮ）であってよい。以下でさらに論じられるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの異なる機能エンティティと、ＲＡＮ１０５と、コアネットワーク１０９との間の通信リンクは、基準点として定義され得る。
図１Ｅに示されるように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃと、ＡＳＮゲートウェイ１８２とを含み得るが、ＲＡＮ１０５は、一実施形態と一致したままでありながら、任意の数の基地局とＡＳＮゲートウェイとを含んでよいことが理解されるであろう。基地局１８０ａ、１８０ｂ、１８０ｃは各々、ＲＡＮ１０５内の特定のセル（図示せず）に関連付けられてよく、各々、エアインターフェイス１１７を経由してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数のトランシーバを含み得る。一実施形態では、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実施し得る。したがって、基地局１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、ＷＴＲＵ１０２ａからワイヤレス信号を受信し得る。基地局１８０ａ、１８０ｂ、１８０ｃは、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、サービス品質（ＱｏＳ）ポリシー強制（enforcement）などのモビリティ管理機能も提供し得る。ＡＳＮゲートウェイ１８２は、トラフィックアグリゲーション点として働いてよく、ページング、加入者プロファイルのキャッシング、コアネットワーク１０９へのルーティングなどを担当し得る。
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５との間のエアインターフェイス１１７は、ＩＥＥＥ８０２．１６規格を実施するＲ１基準点として定義され得る。さらに、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０９との論理インターフェイス（図示せず）を確立し得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インターフェイスはＲ２基準点として定義されてよく、Ｒ２基準点は、認証、許可、ＩＰホスト構成管理、および／またはモビリティ管理に使用され得る。
基地局１８０ａ、１８０ｂ、１８０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間のデータの転送を容易にするためのプロトコルを含むＲ８基準点として定義され得る。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６基準点として定義され得る。Ｒ６基準点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連付けられたモビリティイベントに基づくモビリティ管理を容易にするためのプロトコルを含み得る。
図１Ｅに示されるように、ＲＡＮ１０５はコアネットワーク１０９に接続され得る。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を容易にするためのプロトコルを含むＲ３基準点として定義され得る。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４と、認証、許可、アカウンティング（ＡＡＡ）サーバ１８６と、ゲートウェイ１８８とを含み得る。前述の要素の各々はコアネットワーク１０９の一部として示されているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または動作されてよいことが理解されるであろう。
ＭＩＰ−ＨＡは、ＩＰアドレス管理を担当してよく、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、異なるＡＳＮおよび／または異なるコアネットワーク間でローミングすることを可能にし得る。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換網へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。ＡＡＡサーバ１８６は、ユーザ認証と、ユーザサービスをサポートすることとを担当し得る。ゲートウェイ１８８は、他のネットワークとのインターワーキングを容易にし得る。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換網へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。さらに、ゲートウェイ１８８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される、他の有線ネットワークまたはワイヤレスネットワークを含み得る。
図１Ｅには示されていないが、ＲＡＮ１０５は他のＡＳＮに接続されてよく、コアネットワーク１０９は他のコアネットワークに接続されてよいことが理解されるであろう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクはＲ４基準点として定義されてよく、Ｒ４基準点は、ＲＡＮ１０５と他のＡＳＮとの間でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを協調させるためのプロトコルを含み得る。コアネットワーク１０９と他のコアネットワークとの間の通信リンクはＲ５基準として定義されてよく、Ｒ５基準は、ホームコアネットワークと訪問先コアネットワークとの間のインターワーキングを容易にするためのプロトコルを含み得る。
ルータに関して説明されているが、本明細書で説明される実施形態は、限定するものではないが、基地局、ＷＴＲＵ、ネットワークエンティティノード、Ｗｉ−Ｆｉネットワーク内のアクセスポイント（ＡＰ）などの任意のノードへの適用例であってよい。Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）技術に関して説明されているが、本明細書で説明される実施形態は、他のワイヤレス通信技術（例えば、ＨＳＰＡ）に適用可能であり得る。ＩＰフローおよびＩＰパケットに関して説明されているが、本明細書で説明される実施形態は、データの１または複数のパケットを備える任意のデータフローに適用可能であり得る。非エンドポイントノードは、例えば、ルータ、基地局、Ｗｉ−Ｆｉネットワーク内のアクセスポイント（ＡＰ）、またはネットワークエンティティノードであってよい。
リアルタイムビデオトラフィックは、ネットワーク輻輳の場合などにビデオのユーザ体感品質（ＱｏＥ）を最適化するために利用され得る。リアルタイムビデオトラフィックは、セルラーアップリンク／ダウンリンクに対するビデオアウェアな（video-aware）リソース割り振りを介してビデオのＱｏＥを最適化するために利用され得る。ＱｏＥ最適化は、セルラーネットワークとインターネット上のルータとの間の協調のための機構を使用し得る。ノードは、セルラーネットワークとインターネット上のルータとの間の協調のためのＱｏＥ最適化機構を利用し得る。ｅＮＢにおけるアップリンク輻輳が推測され得る。例えば、ノードは、ｅＮＢにおけるアップリンク輻輳を推測し得る。ＷＴＲＵなどのノードは、アップリンク輻輳を処理するためにｅＮＢにシグナリングし得る。パケットは、重要と示されるビデオフレームを搬送し得る。ビデオフレームは、優先度インジケータ（例えば、フロー優先度インジケータ）の使用を介して重要と示され得る。ノードは、ビデオアウェアなリソース割り振りのためにＰＤＣＰ、ＲＬＣ、および／またはＭＡＣ副層に輻輳情報および／またはパケット重要度情報を送るように構成され得る。セルラーネットワークを経由したリアルタイムビデオアプリケーショントラフィックの配信は、リアルタイムビデオトラフィックの特性を活用することによって容易にされ得る。
ネットワーク（例えば、セルラーネットワーク）は、ネットワーク輻輳を識別し得る。ネットワーク輻輳が発生し、および／またはワイヤレスアップリンク、ワイヤレスダウンリンク、ルータなどに影響を与えることがある。ネットワーク（例えば、セルラーネットワーク）は、重要なビデオフレームを搬送するパケットを識別し得る。ネットワークは、リソース割り振りエンティティ（例えば、ｅＮＢ、ＰＤＮ、ＧＷ、など）に、ネットワーク輻輳および／またはパケットが重要なビデオフレームを搬送することを通知し得る。リソース割り振りエンティティに通知するネットワークは、リソース割り振りエンティティがビデオアウェアであることを可能にし得る。ビデオアウェアなリソース割り振りエンティティは、リアルタイムビデオアプリケーションのＱｏＥを改善し得る。例えば、ネットワークまたはビデオアウェアなリソース割り振りエンティティは、パケットロス（例えば、ネットワーク層、ＭＡＣ層などにおける）をリアルタイムビデオトラフィックフローのごく一部に集中し得る。
リアルタイムビデオアプリケーションとは、ビデオテレフォニーアプリケーション（例えば、ビデオ会議）、ビデオゲーム（例えば、クラウドなどを介した２人のゲーマー間の直接通信）などを指し得る。図２は、ＱｏＥリソース割り振りのための例示的なダウンリンク使用事例を示す図である。図２では、ビデオ送信機２０８、２０９、２１０は、信号をインターネット２０７に送り得る。インターネット２０７は、信号をＰ−ＧＷ２０６に送り得る。Ｐ−ＧＷ２０６は、信号をＥｖｏｌｖｅｄパケットコア（ＥＰＣ）２０５に送り得る。ＥＰＣ２０５は、信号をｅＮＢ２０４に送り得る。Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｙｓｔｅｍ（ＧＰＲＳ）Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ Ｕｓｅｒ Ｐｌａｎｅ（ＧＴＰ−Ｕ）は、ｅＮＢ２０４、ＥＰＣ２０５、および／またはＰ−ＧＷ２０６を備え得る。ｅＮＢ２０４は、信号をビデオ受信機２０１、２０２、２０３に送り得る。
図３は、ＱｏＥリソース割り振りのための例示的なアップリンク使用事例を示す図である。図３では、ビデオ送信機３０１、３０２、３０３は、信号をｅＮＢ３０４に送り得る。ｅＮＢ３０４は、信号をＥＰＣ３０５に送り得る。ＥＰＣ３０５は、信号をＰ−ＧＷ３０６に送り得る。Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｙｓｔｅｍ（ＧＰＲＳ）Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ Ｕｓｅｒ Ｐｌａｎｅ（ＧＴＰ−Ｕ）は、ｅＮＢ３０４、ＥＰＣ３０５、および／またはＰ−ＧＷ３０６を備え得る。Ｐ−ＧＷ３０６は、信号をインターネット３０７に送り得る。インターネット３０７は、信号をビデオ受信機３０８、３０９、３１０に送り得る。
図２などにおける、ダウンリンクでは、輻輳は、インターネット内で、Ｅｖｏｌｖｅｄパケットコア（ＥＰＣ）内で、および／またはワイヤレスダウンリンクにおいて、発生し得る。輻輳がインターネット内で発生する場合、ビデオ送信機および／またはインターネット内にあるルータは、例えば本明細書で説明されるようなＱｏＥリソース割り振りを提供し得る。輻輳は、ＥＰＣコアネットワーク内で、ＲＡＮ内で、および／またはワイヤレスリンクにおいて、発生し得る。
ネットワーク輻輳は、パケットロスを引き起こし得る。ネットワーク輻輳は、ＳＧＷおよび／またはＰ−ＧＷ内の輻輳を備え得る。ＲＡＮ輻輳が、パケットロスを引き起こし得る。ＲＡＮ輻輳は、ｅＮＢにおける輻輳であることがある。チャネル誤りが、パケットロスを引き起こし得る。チャネル誤りは、ワイヤレスチャネルの不信頼性によることがある。ＬＴＥ／ＬＴＥ−Ａシステムは、適応変調コーディング方式（ＭＣＳ）選択を用い得る。チャネル誤りは、例えば、チャネル状態情報に関係なく、目標値に維持され得る。ＲＬＣ、ＬＬＣ、および／またはＰＤＣＰにおける機構は、チャネル誤りが適度に低く保たれることを確実にするために使用され得る。パケットロスは、輻輳を誘発し得る。
図４は、ユーザプレーン内のプロトコルスタック内のＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ Ｕｓｅｒ ｐｌａｎｅ（ＧＴＰ−Ｕ）の例示的なロケーションを示す。ＥＰＣでは、ポリシー制御規則機能（ＰＣＲＦ）が規則をＰ−ＧＷ４０８に送り得、Ｐ−ＧＷ４０８は、例えば、ＩＰパケットヘッダマーキングをＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ Ｕｓｅｒ ｐｌａｎｅ（ＧＴＰ−Ｕ）パケットヘッダマーキング４１０にマッピングし得る。ＧＴＰ−Ｕパケットヘッダマーキング４１０は、優先度インジケータ（例えば、ＦＰＩ）を拡張する形をとってよい。優先度インジケータは、ＩＰフローごとにあってよい。例えば、同じＩＰフローに属するパケットは、優先度インジケータフィールドに同じ値を持ち得る。優先度インジケータ値は、同じＩＰフローまたは類似のＩＰフローに属するパケットの間で異なってよい。優先度インジケータ値は、例えば、ネットワーク内で起こったイベントおよび／またはビデオ送信機によって講じられた措置に基づいて、動的に割り当てられおよび／または更新され得る。ＧＴＰ−Ｕパケットヘッダ内のマーキング４１０は、例えば、パケットがｅＮＢ４０４に到着したとき、ｅＮＢ４０４によってアクセス可能であってよい。ｅＮＢ４０４は、対応するフローの状態を更新し得る。ｅＮＢ４０４は、パケットが瞬時デコーダリフレッシュ（ＩＤＲ）フレームまたはワイヤレスリンクのためのプロトコルスタックに対するビデオ品質のより高い重要度によって特徴付けられたフレームおよび／もしくはパケットを搬送するかどうかを示す情報を送り得る。ビデオ品質のより高い重要度によって特徴付けられたフレームまたはパケットは、ＩＤＲフレームの一部分、より重要なＰフレーム、より重要なＰフレームの一部分、イントラ符号化されたビデオフレームなどであってよい。例えば、ＩＰフローは、ビデオフロー、リアルタイムビデオフロー、ファイル転送プロトコル（ＦＴＰ）データを搬送するパケットのシーケンスなどの、２つ以上のＩＰパケットを含むビットストリームであってよい。ビデオ品質重要度は、ＩＰフローの他のフレームの予測のためのフレームの使用状況に関連し得る。
図５は、ビデオアプリケーションのための例示的なダウンリンクＱｏＥアウェアなリソース割り振りを示す流れ図である。５１０では、デフォルトＥＰＳベアラが確立され得る。５１０では、ビデオ送信機５０８および／またはビデオ受信機５０１は、例えば、ＳＩＰ／ＳＤＰまたはＨ．３２３などのプロトコルを介して、ビデオセッションのためのパラメータを決定し得る。ポリシー制御規則機能（ＰＣＲＦ）５０３は、続くデータトラフィックフローについての情報を、Ｒｘインターフェイスを介して受信し得る。例えば、情報は、ＩＰ５タプル、データトラフィックフローがビデオストリーミング、ビデオテレフォニー、ビデオゲームであるかどうかなどを含み得る。
５２０では、ＰＣＲＦ５０３は、ユーザのための加入情報を取得するために、加入プロファイルリポジトリ（ＳＰＲ）５０４に要求を送り得る。
５３０では、ＳＰＲ５０４は、ユーザの加入情報をＰＣＲＦ５０３に送り得る。例えば、情報は、ユーザの加入レベルを含み得る。ＰＣＲＦ５０３は、情報を使用して、ＰＣＣ規則を生成し得る。
５４０では、ＰＣＲＦ５０３は、ＰＣＣ規則をＰ−ＧＷ５０５に送り得る。ＰＣＣ規則は、ＩＰパケットヘッダマーキング（例えば、インターネット５０７から受信された）をＧＴＰ−Ｕパケットヘッダマーキングにどのようにマッピングするかを決定するために使用され得る。ＧＴＰ−Ｕパケットヘッダマーキングは、優先度インジケータ（例えば、ＦＰＩ）の形をとってよい。ＩＰパケットは、内部ＩＰパケットと呼ばれることがある。例えば、ＩＰパケットは、ＧＴＰ−Ｕパケット（例えば、図７に示される）のペイロードとしてカプセル化され得る。内部ＩＰパケットヘッダ内のマーキングは、トラフィックフローの状態に関する情報を含み得る。
５５０では、ビデオ送信機は、ビデオトラフィックを送り得る。インターネット５０７内の１または複数のルータは、ビデオ送信機５０８と協調し得る。複数のビット（例えば、３つのビットａ、ｂ、およびｃ）が、ルータ協調のために使用され得る。ルータは、リアルタイムビデオトラフィックフローのための状態変数を維持し得る。５５５では、ルータは、パケット到着時、パケットの廃棄時などに、フローの状態を更新し得る。５５５では、ルータは、ネットワーク輻輳および／またはリアルタイムビデオトラフィックフローの状態に基づいてキュー管理を実行し得る。ＩＰパケットヘッダは、複数のビット（例えば、ビットａ、ビットｂ、およびビットｃ）を含み得る。ルータは、ビット（例えば、ビットａ）を使用して、パケットロスがフローに対して発生したことをダウンストリームルータに示し得る。例えば、パケットロスがフローに対して発生したことをダウンストリームルータに示すために使用されるビット（例えば、ビットａ）は、消失パケットインジケータと呼ばれることがある。ルータは、ビット（例えば、ビットｂ）を使用して、誤り伝播が停止されたことをダウンストリームルータに示し得る。例えば、ルータは、ビット（例えば、ビットｂ）を使用して、例えばマルチパスルーティングにおいてＩＰフローが通る１または複数のルータ内のＩＰフローの状態をリセットし得る。ビデオトラフィックフローは、例えば、負荷分散がネットワーク内で利用されるとき、複数のルートを通過し得る。ルータは、ビット（例えば、ビットｃ）を使用して、パケットがイントラ符号化されたビデオフレームを搬送するかどうかを示し得る。
複数のビット（例えば、３つのビット）は、ルータ協調のために使用され得る。ビット（例えば、ビットａ）は輻輳インジケータであってよい。ルータはビットａを制御し得る。ビットａは、ＩＰフローがパケットロスを経験したかどうかに関連する情報を伝え得る。ビットａは、ＩＰフローがパケットロスを経験したことを示すために、１に設定され得る。ビットａは、ＩＰフローがパケットロスを経験していない（例えば、最近パケットロスを経験していない、または最新のリフレッシュフレーム以降パケットロスを経験していない）ことを示すために、０に設定され得る。ビットａは、ＩＰフロー固有情報を搬送するために使用され得る。
ルータは、ビット（例えば、ビットｂ）を使用して、ビデオ符号化適応が実行されたかどうかを決定し得る。ビットｂは、ビデオ符号化適応が実行されたことを示すために、１に設定され得る。ビットｂは、ビデオ符号化適応が実行されていない（例えば、最近実行されていない、またはパケットロス後、実行されていない）ことを示すために、０に設定され得る。ビデオ符号化適応は、ＩＤＲフレームの生成、基準画像選択（ＲＰＳ）などを備え得る。
ルータは、ビット（例えば、ビットｃ）を使用して、パケットが重要なフレームを搬送しているかどうかを決定し得る。重要なフレームは、ＩＤＲフレーム、誤り伝播に対する著しい影響を有するＰフレームなどを備え得る。ビットｃは、パケットが重要なフレームを搬送していることを示すために、１に設定され得る。ビットｃは、パケットが重要なフレームを搬送していないことを示すために、０に設定され得る。ビットｃは、ＩＰパケット固有情報を搬送するために使用され得る。
ルータは、１または複数のＩＰフローのための状態変数を維持し得る。例えば、状態変数Ｓｔａｔｅ＿ｋは、ＩＰフローｋのために使用され得る。ルータは、ＩＰフローのための１または複数のビット（例えば、ビットａ、ビットｂ、およびビットｃ）を設定し得る。ビットは、例えば、別のルータにおいて、状態変数（例えば、Ｓｔａｔｅ＿ｋ）を更新するために使用され得る。ルータは、パケットを正常にルーティングしないことがある。どのパケットを廃棄するかを決定するために、ノードは、ビデオトラフィックフロー（例えば、優先度の低いビデオトラフィックフロー）を選択するように構成され得る。ノードは、選択されたビデオトラフィックフロー内の優先度の低いパケットを選択して、廃棄し得る（例えば、イントラ符号化されたビデオフレームなどの重要なビデオフレームを搬送しないことがあるパケット）。例えば、重要なビデオフレームを搬送しないことがあるパケットは、ビットｃが０に等しいパケットであってよい。例えば、ルータは、１または複数のビット（例えば、ビットａ、ビットｂ、およびビットｃ）を備えるＩＰフローのパケットを受信したとき、以下を実行し得る。
ルータにおいて、次のとおりである。
ルータは、パケットロスを１または複数の劣化させられたトラフィックフローに集中させ得る。状態変数Ｓｔａｔｅ＿ｋ＝ｌｏｓｓの場合、ルータは、ＩＰフローｋをキュー管理における低い優先度に設定し得る。例えば、ルータは、パケットロスをフローｋに集中させ得る。例えば、ビデオ送信機において状態変数を設定することは、本明細書で提供される例示的なアルゴリズムにより実行され得る。
ビデオ送信機において、次のとおりである。
ビデオ受信機は、本明細書で提供される例示的なアルゴリズムにより以下を実行し得る。
ビデオ受信機において、次のとおりである。
それが、ＲＴＰシーケンス番号のギャップを検出した場合
ＲＴＣＰパケットロス報告をビデオ送信機に送り返す
終了
ルータは、トラフィックフローがネットワーク内の複数のパスを通る場合、ビットａ、ビットｂ、および／またはビットｃを利用し得る。ビットｃは、ＩＤＲフレームを搬送するＩＰパケットに関連付けられ得る。ルータは、例えばマルチパスルーティングにおいて、ビットｃを使用して、パスの枝上の１または複数のルータの状態をリセットし得る。ルータは、他の枝上のルータをリセットするために、ビットｃを使用しないことがある。ルータは、シグナリングビット（例えば、ビットｂ）を搬送する非ＩＤＲフレームを、例えば、ビットｃを受信しない枝上のルータに送る。ルータは、ルータがＩＰパケットを廃棄するとき、ビットｃを使用し得る。１を伝えるビットｃを有するＩＰパケットは、より高い優先度が与えられ得る。ルータは、状態変数を更新し得る。ルータは、１または複数のビット（例えば、ビットａ）により状態変数をどのように更新するかを決定し得る。例えば、ルータは、本明細書で説明される１または複数のアルゴリズムに基づいて状態変数をどのように更新するかを決定し得る。
パケットが、リアルタイムビデオトラフィックフロー内で失われることがある。リアルタイムビデオトラフィックフローは、ＩＰＰＰ構造または階層型Ｐビデオコーディング構造の時間層０などの連続した時間的予測ビデオコーディング構造を持ってよい。パケットがリアルタイムビデオトラフィックフロー内で失われるとき、（例えば、連続した時間的予測ビデオコーディング構造内の）追加パケットロスによる性能劣化は、第１のパケットロスによるものよりも低いことがある。複数のリアルタイムビデオトラフィックフローの全体的ＱｏＥは、例えば、パケットがリアルタイムビデオトラフィックフロー内で失われるとき、最適化され得る。ネットワークエンティティ（例えば、ルータ、ｅＮＢなど）は、例えばネットワーク輻輳の場合、パケットロスをリアルタイムビデオアプリケーショントラフィックフローのごく一部に集中し得る。ネットワークエンティティは、パケットを失わなかった可能性のあるリアルタイムビデオアプリケーションのＱｏＥを維持し得る。ネットワークエンティティは、例えば、パケットロスをリアルタイムビデオアプリケーションのごく一部に集中させることによって、すでにパケットを消失したリアルタイムビデオアプリケーションのＱｏＥを最小限に劣化させ得る。例えば、ネットワークエンティティは、追加ビット（例えば、ビットａ、ビットｂ、および／またはビットｃ）を使用し得る。追加ビットは、例えば、リアルタイムビデオトラフィックフローのパス上に複数のルータがあるとき、および／またはビデオ送信機とビデオ受信機との間に複数のパスが存在する場合、ロス集中タイプのリソース割り振りを可能にし得る。
ルータは、ルータのキュー内の１または複数のフローに関連付けられた、より多くの特性のうちの１つを決定するように構成され得る。特性は、トラフィックのタイプ、関連付けられたアプリケーション、ＱｏＳのタイプ、および／またはピーク、移動平均、瞬間（instant）、バッファ占有量の総量などのレートなどを含み得る。ルータは、送信機および／または受信機に関連する、より多くの特性のうちの１つを決定するように構成され得る。例えば、ルータは、ルータのキュー内の１もしくは複数のフローに関連付けられた、より多くの特性の、または１もしくは複数のパケットがそのキューのうちの１つから最初に廃棄され得るとルータが決定するとき、送信機および／または受信機に関連する特性のうちの１つを決定するように構成され得る。ルータは、ルータのキュー内の１または複数のフローに関連付けられたより多くの特性の、またはネットワーク輻輳の場合の送信機および／もしくは受信機に関連する特性のうちの１つを決定するように構成され得る。ネットワーク輻輳は、キューレベル、キュー占有率が一定の閾値に到達したことなどの結果であり得る。
ルータは、それから１または複数のパケットを廃棄する１または複数のフローを選択し得る。１または複数のパケットを廃棄するルータは、例えばＥＣＮマーキングを使用して、輻輳のために１または複数のパケットをマーキングするルータを備え得る。例えば、ルータは、パケットロスを経験していないリアルタイムビデオトラフィックフローを選択し得る。ルータは、フローを選択して、ランダムに、および／または１または複数の規則に従うことにより、パケットを廃棄し得る。この規則は、一定の公平性基準を強制するように設計され得る。例えば、ルータは、過度に高いデータ転送速度でビデオトラフィックフローのパケットを廃棄し得る。規則は、ユーザ加入情報に基づいてよい。例えば、ルータが、下位加入サービスのユーザのフローからパケットを廃棄した後、ルータは、高度な（premium）加入サービスを有するユーザのフローからパケットを廃棄し得る。ハイブリッド手法が利用されてよい。例えば、より高いデータ転送速度閾値が、高度な加入サービスのユーザに対して設定され得る。高度な加入サービスのユーザのデータ転送速度がその閾値を超える場合、ルータが、下位加入サービスを有するユーザからのパケットを廃棄する前に、ルータは、高度な加入サービスのユーザからのパケットを廃棄し得る。輻輳の状態が存続する場合、ルータは、後続のパケット廃棄を、選択されたフローに集中させ得る。
５６０では、Ｐ−ＧＷ５０５がインターネット５０７からＩＰパケットを受信するとき、Ｐ−ＧＷ５０５は、ＩＰパケットヘッダ内のマーキング（例えば、平文であってよい）を検査し得る。５６０では、Ｐ−ＧＷ５０５は、マーキングをＧＴＰ−Ｕパケットヘッダにマッピングし得る。ＴＤＦは、Ｐ−ＧＷ５０５と一緒に置かれ得る。ＧＴＰ−Ｕパケット内のマーキングはビット（例えば、ビットｃ）に対応してよく、例えば、ＧＴＰ−ＵパケットがＩＤＲビデオフレームのすべてまたは一部を搬送するかどうかを示し得る。このＩＰパケットは、例えば、図６を参照しながら本明細書で説明されるように、内部ＩＰパケットと呼ばれることがある。５６５では、Ｐ−ＧＷ５０５は、例えば、潜在的キュー管理のためのディープパケットインスペクションなしで、ＥＰＣ内のルータがビット（例えば、図６を参照しながら説明されるビットａ、ビットｂ、および／またはビットｃ）に直接アクセスするように、内部ＩＰパケットヘッダマーキングを外部ＩＰパケットヘッダのマーキングに変換し得る。スタンドアロンＴＤＦは、フロー検出を実行し得る。図７、スタンドアロンＴＤＦを有するダウンリンクＱｏＥビデオリソース割り振りの例を示す流れ図。
Ｐ−ＧＷは、内部ＩＰパケットヘッダマーキングをＧＴＰ−Ｕパケットヘッダ内のＦＰＩ値にマッピングし得る。Ｐ−ＧＷは、ＧＴＰ−Ｕパケットヘッダ内のＦＰＩ値を、外部ＴＰパケットヘッダマーキングにマッピングし得る。ＩＰパケットヘッダマーキングは、ＩＰフロー固有情報および／またはパケット固有情報を搬送し得る。ＦＰＩは、ＩＰフロー固有情報および／またはパケット固有情報を備え得る。例えば、ＩＰフロー固有情報は、消失パケットインジケータ（例えば、本明細書で説明されるビットａ）を備え得る。例えば、パケット固有情報は、本明細書で説明されるビットｃを備え得る。例えば、ＦＰＩは、本明細書で説明されるビットｂを備え得る。
５７０では、ＥＰＣネットワーク内のルータは、ＧＴＰ−Ｕパケットを搬送する外部ＩＰパケットをルーティングし得る。ＧＴＰ−Ｕパケットは、内部ＩＰパケットを含み得る。５７５において、ルータは、外部ＩＰパケットを検査し得る。外部ＩＰパケットヘッダ内のマーキングは、インテリジェントネットワークリソース割り振りのために使用され得る。例えば、内部ＩＰパケットヘッダ内のビットｃ＝１（例えば、図６を参照しながら説明される）に対応するマーキングを有する外部ＩＰパケットは、ネットワーク輻輳の場合、より高い優先度を与えられ得る。サービス加入レベルは、どのフローからパケットを廃棄するかを選択する際に使用され得る。例えば、サービス加入レベルは、トラフィックフローに関連付けられたＱＣＩ値に基づいてよい。５７５において、ルータは状態変数を更新し得る。５７５において、ルータはキュー管理を実行し得る。
５８０において、ｅＮＢ５０２は、ＥＰＣネットワークから外部ＩＰパケットを受信し得る。５８０において、ｅＮＢは、外部ＩＰパケットマーキングを記録し、トラフィックフローの状態を更新し、および／またはネットワーク層でキュー管理を実行し得る。５８２において、ｅＮＢ５０２は、ＧＴＰ−Ｕパケットを抽出し、および／またはＧＴＰ−Ｕパケットマーキングを回復させ得る。ＧＴＰ−Ｕパケットマーキングは、このＧＴＰ−ＵパケットにどのようにサービスするかをｅＮＢ５０２に示し得る。例えば、ＧＴＰ−Ｕパケット内のＦＰＩフィールドが、このＧＴＰ−ＵパケットがＩＤＲトラフィックを搬送することを示す場合、ｅＮＢ５０２は、リソース割り振りにおいて、このＧＴＰ−Ｕパケットに、より高い優先度を与え得る。５８４において、ｅＮＢ５０２は、ＧＴＰ−Ｕパケットマーキングを、ｅＮＢのＲＡＮ部分におけるＰＤＣＰ、ＲＬＣ、および／またはＭＡＣ層に送り得る。ｅＮＢ５０２がＧＴＰ−Ｕパケットマーキングを送ることは、ＰＤＣＰ、ＲＬＣ、および／またはＭＡＣ層におけるパケット優先度付けを可能にし得る。ＭＡＣ層における優先度付けは、ＭＡＣパケットスケジューリングの一部であってよい。例えば、ｅＮＢ５０２は、テーブルルックアップを使用してパケットセグメント化およびアグリゲーションを追跡することによって、ＩＤＲフレームを搬送するパケットの識別を実行し得る。例えば、ｅＮＢ５０２はパケットを廃棄し得る最後のノードであることがあるので、ｅＮＢ５０２が発信パケットをマーキングしないことがある。ＷＴＲＵ５０１は、ＷＴＲＵ５０１がひとたびパケットを受信すると、パケットを廃棄すると予想されないことがある。
５９０において、ｅＮＢ５０２はビデオトラフィックを送信し得る。ＷＴＲＵ５０１は、ＲＴＣＰパケットロスフィードバックを送り得る。
ＭＡＣパケットスケジューラは、例えば、優先度インジケーションなどの特徴を（例えば、ＦＰＩを介して）サポートするように調整され得る。パケットスケジューリングは、論理チャネルごとにあってよい。ＥＰＳベアラと論理チャネルとの間の１対１マッピングが利用され得る。優先度インジケーション情報が送られてもよいし、および／または副論理チャネルがＭＡＣ層で作製されてもよい。例えば、論理チャネルは、複数の副論理チャネルに分割され得る。異なる副論理チャネルは、異なるように優先度が付けられることになるトラフィックを搬送し得る。副論理チャネルに対する全リソース割り振りは、全体として、同じままであってよい。
図６は、ＧＴＰ−Ｕトンネリングのための例示的なパケットフォーマットを示す図である。ＩＰパケットは、内部ＩＰパケット６０１と呼ばれることがある。ＩＰパケットは、ＧＴＰ−Ｕパケットのペイロードとしてカプセル化され得る。内部ＩＰパケットヘッダ６０２内のマーキングは、トラフィックフローの状態に関する情報を含み得る。Ｐ−ＧＷは、例えば、ＥＰＣ内のルータがビット（例えば、ビットａ、ビットｂ、および／またはビットｃ）に直接アクセスし得るように、内部ＩＰパケットヘッダ６０２マーキングを外部ＩＰパケットヘッダ６０５のマーキングに変換し得る。
図７は、スタンドアロンＴＤＦを有するダウンリンクＱｏＥビデオリソース割り振りの一例を示す流れ図である。スタンドアロンＴＤＦを有するダウンリンクＱｏＥビデオリソース割り振りは、ＴＤＦがＰＣＥＦで一緒に置かれる場合などのビデオアプリケーションのための例示的なダウンリンクＱｏＥアウェアなリソース割り振りである図５に類似してよい。７１０では、デフォルトＥＰＳベアラが確立され得る。７１０では、ビデオ送信機７０９および／またはビデオ受信機７０１は、例えば、ＳＩＰ／ＳＤＰまたはＨ．３２３などのプロトコルを介して、ビデオセッションのためのパラメータを決定し得る。ポリシー制御規則機能（ＰＣＲＦ）７０３は、続くデータトラフィックフローについての情報を、Ｒｘインターフェイスを介して受信し得る。例えば、情報は、ＩＰ５タプル、データトラフィックフローがビデオストリーミング、ビデオテレフォニー、ビデオゲームであるかどうかなどを含み得る。
７２０では、ＰＣＲＦ７０３は、ユーザのための加入情報を取得するために、加入プロファイルリポジトリ（ＳＰＲ）７０４に問い合わせ得る。
７３０では、ＳＰＲ７０４は、ユーザの加入情報を用いてＰＣＲＦ７０３に応答し得る。例えば、情報は、ユーザの加入レベルを含み得る。
７４０では、ＰＣＲＦ７０３は、アプリケーション検出規則を送り得る。比較すると、図５の５４０において、ＰＣＲＦ５０３はＰＣＣ規則を送り得る。ＰＣＣ規則は、アプリケーション検出規則よりも汎用的であってよい。７５０では、ビデオ送信機７０９は、ビデオトラフィックをＴＤＦ７０７に送り得る。７５２において、ルータは、ＩＰパケットヘッダを検査し得る。７５２では、状態変数が、ＴＤＦ７０７および／またはＰ−ＧＷ７０５において更新され得る。７５２では、キュー管理は、ＴＤＦ７０７および／またはＰ−ＧＷ７０５において実行され得る。７５４では、ＴＤＦ７０７は、トラフィック検出結果を報告し得る。７４０および７５４は、Ｓｄインターフェイス上で実行され得る。
７６０では、Ｐ−ＧＷ７０５がインターネット７０８からＩＰパケットを受信するとき、Ｐ−ＧＷ７０５は、ＩＰパケットヘッダ内のマーキング（例えば、平文であってよい）を検査し得る。７６０では、Ｐ−ＧＷは、マーキングをＧＴＰ−Ｕパケットヘッダにマッピングし得る。ＧＴＰ−Ｕパケット内のマーキングはビット（例えば、ビットｃ）に対応してよく、このビットは、例えば、ＧＴＰ−ＵパケットがＩＤＲビデオフレームのすべてまたは一部を搬送するかどうかを示し得る。このＩＰパケットは、例えば、図６を参照しながら本明細書で説明されるように、内部ＩＰパケットと呼ばれることがある。７６２では、Ｐ−ＧＷ７０５は、例えば、潜在的キュー管理のためのディープパケットインスペクションなしで、ＥＰＣ内のルータがビット（例えば、図６を参照しながら説明されるビットａ、ビットｂ、および／またはビットｃ）に直接アクセスするように、内部ＩＰパケットヘッダマーキングを外部ＩＰパケットヘッダのマーキングに変換し得る。
７７０では、ＥＰＣネットワーク内のルータは、ＧＴＰ−Ｕパケットを搬送する外部ＩＰパケットをルーティングし得る。ＧＴＰ−Ｕパケットは、内部ＩＰパケットを含み得る。７７２において、ルータは、外部ＩＰパケットを検査し得る。外部ＩＰパケットヘッダ内のマーキングは、インテリジェントネットワークリソース割り振りのために使用され得る。例えば、内部ＩＰパケットヘッダ内のビットｃ＝１（例えば、図６を参照しながら説明される）に対応するマーキングを有する外部ＩＰパケットは、ネットワーク輻輳の場合、より高い優先度を与えられ得る。サービス加入レベルは、どのフローからパケットを廃棄するかを選択する際に使用され得る。例えば、これは、トラフィックフローに関連付けられたＱＣＩ値に基づいてよい。７７２において、ルータは状態変数を更新し得る。７７２において、ルータはキュー管理を実行し得る。
７８０において、ｅＮＢ７０２は、ＥＰＣネットワークから外部ＩＰパケットを受信し得る。７８０において、ｅＮＢは、外部ＩＰパケットマーキングを記録し、トラフィックフローの状態を更新し、および／またはネットワーク層でキュー管理を実行し得る。７８２において、ｅＮＢ７０２は、ＧＴＰ−Ｕパケットを抽出し、および／またはＧＴＰ−Ｕパケットマーキングを回復させ得る。ＧＴＰ−Ｕパケットマーキングは、このＧＴＰ−ＵパケットにどのようにサービスするかをｅＮＢ７０２に示し得る。例えば、ＧＴＰ−Ｕパケット内のＦＰＩフィールドが、このＧＴＰ−ＵパケットがＩＤＲトラフィックを搬送することを示す場合、ｅＮＢ７０２は、リソース割り振りにおいて、このＧＴＰ−Ｕパケットに、より高い優先度を与え得る。７８４において、ｅＮＢ７０２は、ＧＴＰ−Ｕパケットマーキングを、ｅＮＢのＲＡＮ部分におけるＰＤＣＰ、ＲＬＣ、および／またはＭＡＣ層に送り得る。ｅＮＢ７０２がＧＴＰ−Ｕパケットマーキングを送ることは、ＰＤＣＰ、ＲＬＣ、および／またはＭＡＣ層におけるパケット優先度付けを可能にし得る。ＭＡＣ層における優先度付けは、ＭＡＣパケットスケジューリングの一部であってよい。例えば、ｅＮＢ７０２は、テーブルルックアップを使用してパケットセグメント化およびアグリゲーションを追跡することによって、ＩＤＲフレームを搬送するパケットの識別を実行し得る。例えば、ｅＮＢ７０２はパケットを廃棄し得る最後のノードであることがあるので、ｅＮＢ７０２が発信パケットをマーキングしないことがある。ＷＴＲＵ７０１は、ＷＴＲＵ７０１がひとたびパケットを受信すると、パケットを廃棄すると予想されないことがある。
７９０において、ｅＮＢ７０２はビデオトラフィックを送信し得る。ＷＴＲＵ７０２は、ＲＴＣＰパケットロスフィードバックを送り得る。
図８は、ビデオアプリケーションのためのアップリンクＱｏＥアウェアなリソース割り振りのための例を示す図である。輻輳は、ワイヤレスリンク内で、ＥＰＣ内で、および／またはインターネット内、例えば、アップリンク内で、発生し得る。アップリンクビデオアウェアなリソース割り振りは、ダウンリンクビデオアウェアなリソース割り振りに類似してよい。
８１０では、デフォルトＥＰＳベアラが確立され得る。８１０では、ビデオ送信機８０１および／またはビデオ受信機８０７は、例えば、ＳＩＰ／ＳＤＰまたはＨ．３２３などのプロトコルを介して、ビデオセッションのためのパラメータを決定し得る。ポリシー制御規則機能（ＰＣＲＦ）８０３は、続くデータトラフィックフローについての情報を、Ｒｘインターフェイスを介して受信し得る。例えば、情報は、ＩＰ５タプル、データトラフィックフローがビデオストリーミング、ビデオテレフォニー、ビデオゲームであるかどうかなどを含み得る。
８２０では、ＰＣＲＦ８０３は、ユーザのための加入情報を取得するために、加入プロファイルリポジトリ（ＳＰＲ）８０４に問い合わせ得る。
８３０では、ＳＰＲ８０４は、ユーザの加入情報を用いてＰＣＲＦ８０３に応答し得る。例えば、情報は、ユーザの加入レベルを含み得る。ＰＣＲＦ８０３は、情報を使用して、ＰＣＣ規則を生成し得る。
８４０では、ＰＣＲＦ８０３は、ＰＣＣ規則をＰ−ＧＷ８０５に提供し得る。ＰＣＣ規則は、ＩＰパケットヘッダマーキング（例えば、インターネット８０７から受信された）を、例えばＦＰＩの形をとり得るＧＴＰ−Ｕパケットヘッダマーキングにどのようにマッピングするかを決定するために使用され得る。ＩＰパケットは、内部ＩＰパケットと呼ばれることがある。例えば、ＩＰパケットは、ＧＴＰ−Ｕパケット（例えば、図７に示される）のペイロードとしてカプセル化され得る。内部ＩＰパケットヘッダ内のマーキングは、トラフィックフローの状態に関する情報を含み得る。
８５０では、Ｐ−ＧＷ８０５は、ＰＣＣ規則をｅＮＢ８０２に送り得る。８６０では、ＷＴＲＵビデオ送信機８０１は、ビデオトラフィックをｅＮＢに送信し得る。８７０では、ＷＴＲＵ８０１は輻輳を処理し得る。
８８０では、ｅＮＢ８０２がＷＴＲＵ８０１からＩＰパケットを受信するとき、ｅＮＢ８０２は、ＩＰパケットヘッダ内のマーキング（例えば、平文であってよい）を検査し得る。８８０では、ｅＮＢは、マーキングをＧＴＰ−Ｕパケットヘッダにマッピングし得る。ＧＴＰ−Ｕパケット内のマーキングはビット（例えば、ビットｃ）に対応してよく、このビットは、例えば、ＧＴＰ−ＵパケットがＩＤＲビデオフレームのすべてまたは一部を搬送するかどうかを示し得る。このＩＰパケットは、例えば、図６を参照しながら本明細書で説明されるように、内部ＩＰパケットと呼ばれることがある。８８２では、ｅＮＢ８０２は、例えば、潜在的キュー管理のためのディープパケットインスペクションなしで、ＥＰＣ内のルータがビット（例えば、図６を参照しながら説明されるビットａ、ビットｂ、および／またはビットｃ）に直接アクセスするように、内部ＩＰパケットヘッダマーキングを外部ＩＰパケットヘッダのマーキングに変換し得る。８８４において、ｅＮＢ８０２は状態変数を更新し得る。８８４において、ｅＮＢ８０２はキュー管理を実行し得る。８８６では、ｅＮＢ８０２はアップリンク輻輳を検出し得る。８８６において、ｅＮＢは、アップリンクＭＡＣスケジューラを調整し得る。
８９０では、ｅＮＢ８０２は、ＧＴＰ−Ｕパケットを搬送する外部ＩＰパケットをルーティングし得る。ＧＴＰ−Ｕパケットは、内部ＩＰパケットを含み得る。ｅＮＢ８０２は、パケットをマーキングし得る。８９２において、ルータ（例えば、ＰＧＷ）は、外部ＩＰパケットを検査し得る。外部ＩＰパケットヘッダ内のマーキングは、インテリジェントネットワークリソース割り振りのために使用され得る。例えば、内部ＩＰパケットヘッダ内のビットｃ＝１（例えば、図６を参照しながら説明される）に対応するマーキングを有する外部ＩＰパケットは、ネットワーク輻輳の場合、より高い優先度を与えられ得る。サービス加入レベルは、どのフローからパケットを廃棄するかを選択する際に使用され得る。例えば、これは、トラフィックフローに関連付けられたＱＣＩ値に基づいてよい。８９２において、ルータは状態変数を更新し得る。１または複数のルータがｅＮＢとＰ−ＧＷとの間に存在してよい。ｅＮＢからＰ−ＧＷへのパスに沿ったすべてのルータは、状態変数を更新し得る。ｅＮＢ８０２は状態変数を更新し得る。８９２において、ルータはキュー管理を実行し得る。
８９４において、Ｐ−ＧＷ８０５は、ビデオトラフィックをビデオ受信機８０７にルーティングし得る。例えば、Ｐ−ＧＷ８０５は、ビデオトラフィックを、１または複数のルータを通してビデオ受信機８０７にルーティングしてよい。例えば、Ｐ−ＧＷ８０５は、ビデオトラフィックをビデオ受信機８０７に直接ルーティングしてもよい。８９６において、ルータ（例えば、Ｐ−ＧＷ、またはＰ−ＧＷとビデオ受信機との間のルータ）は、内部ＩＰパケットヘッダを検査し得る。８９６において、ルータはフロー統計を更新し得る。８９８において、ルータはキュー管理を実行し得る。
ＧＴＰ−Ｕパケットヘッダマーキングは、アップリンクビデオアウェアなリソース割り振りにおいてｅＮＢ８０２によって実行され得る。ＦＰＩは、ダウンリンクビデオアウェアなリソース割り振りおよび／またはアップリンクビデオアウェアなリソース割り振りのために使用され得る。例えば、アップリンクビデオアウェアなリソース割り振りでは、Ｐ−ＧＷ８０５は、ＰＣＣ規則をｅＮＢ８０２に送り得る。あるいは、ｅＮＢ８０２は、ＰＣＣ規則を用いて事前構成されてよい。ＰＣＣ規則は、短時間では変更されないことがある。例えば、オペレータがアップリンクビデオアウェアなリソース割り振りのためのＦＰＩポリシーを用いてｅＮＢ８０２を構成（例えば、動的に構成）し得る場合、基準点が、コアネットワークとＲＡＮとの間で（例えば、ＰＣＲＦからｅＮＢ、ＰＣＥＦからｅＮＢ、ＭＭＥからｅＮＢなど）定義され得る。
ＷＴＲＵ８０１は、例えば、ワイヤレスリンクで、輻輳８７０を処理し得る。輻輳は、例えば、ＭＡＣキュー内のオーバフローに気づくことによって、検出され得る。輻輳を検出すると、ＷＴＲＵ８０１は、ＩＤＲフレームをビデオビットストリームに挿入し得る。輻輳を検出すると、ＷＴＲＵ８０１は、輻輳を回避するために、廃棄されるビデオパケットをより低い解像度（例えば、より低いビットレート）で符号化し得る。ＷＴＲＵ８０１は、本明細書で説明されるダウンリンク内のＲＴＣＰパケットロスフィードバックに基づく手法などと同様に、ＩＤＲフレームをビデオビットストリームに挿入するように構成され得る。アップリンク内のフィードバック遅延は、ダウンリンクの場合における約１ＲＴＴの遅延と比較して無視でき得る。
ｅＮＢ８０２は、アップリンク輻輳を観測しないことがある。ｅＮＢ８０２は、例えば、ＰＤＣＰシーケンス番号を分析することによって、アップリンク輻輳を推測し得る。ｅＮＢ８０２は、変化するチャネル条件に適応するように、例えば、ＭＡＣ、ＲＬＣ、および／またはＰＤＣＰ層において目標パケットロス率を達成するように、ＭＣＳを選択（例えば、動的に選択）し得る。
ｅＮＢ８０２は、ＰＤＣＰ ＰＤＵシーケンス番号の使用を介してアップリンク輻輳の発生を推測し得る。ｅＮＢ８０２は、ＰＤＣＰ ＰＤＵシーケンス番号を検査することによって、アップリンク輻輳を決定し得る。例えば、ｅＮＢ８０２は、欠落しているＰＤＣＰ ＰＤＵの数が全ＰＤＣＰ ＰＤＵのあるパーセンテージである場合、および／または欠落しているＰＤＣＰ ＰＤＵの数が閾値を越えた場合、アップリンク輻輳を決定し得る。例えば、閾値は、目標ＭＣＳに対応するパーセンテージよりもわずかに大きくてよい。ｅＮＢ８０２は、例えば、輻輳を経験したユーザにアップリンクリソースのより小さな共有を与えることによって、将来のアップリンクスケジューリングのために、アップリンク輻輳に関する情報を使用し得る。
ＷＴＲＵ８０１において、１２ビット長ＰＤＣＰシーケンス番号（例えば、Ｎｅｘｔ＿ＰＤＣＰ＿ＴＸ＿ＳＮ）がＰＤＣＰ ＳＤＵに割り当てられ得る。この１２ビット長ＰＤＣＰシーケンス番号（例えば、Ｎｅｘｔ＿ＰＤＣＰ＿ＴＸ＿ＳＮ）は、例えば上位層から来ることがある、次のＰＤＣＰ ＳＤＵに対して１増加され得る。ｄｉｓｃａｒｄＴｉｍｅｒは、受信されたＰＤＣＰ ＳＤＵに関連付けられ得る。ＷＴＲＵ８０１は、ｄｉｓｃａｒｄＴｉｍｅｒを受信されたＰＤＣＰ ＳＤＵと関連付けるように構成され得る。ｄｉｓｃａｒｄＴｉｍｅｒが満了した場合、関連付けられたＰＤＣＰ ＳＤＵおよび／またはＰＤＣＰ ＰＤＵは廃棄されてよい。例えば、ＰＤＣＰ ＰＤＵが下位層に提示された場合、ＷＴＲＵ８０１は、廃棄信号を下位層に送ってよい。ｄｉｓｃａｒｄＴｉｍｅｒは、不良なチャネル品質（例えば、ランダムチャネルの特定の不良な実現）および／または輻輳により満了し得る。
例えば、アップリンクのためのＭＣＳが目標パケットロス率Ｔを満たすように構成される場合、ｅＮＢ８０２は、アップリンク輻輳が発生したと決定し得る。例えば、観測されたパケットロス率が目標値よりも高い場合、ｅＮＢ８０２は、アップリンク輻輳が発生したと決定し得る。ｅＮＢ８０２は、ＰＤＣＰシーケンス番号（例えば、ＷＴＲＵ８０１によって設定され得る）を検査し得る。ｅＮＢ８０２は、シーケンス番号のギャップを記録し得る。ｅＮＢ８０２は、欠落しているＰＤＣＰ ＰＤＵの数を、全ＰＤＣＰ ＰＤＵのパーセンテージとして計算し得る。全ＰＤＣＰ ＰＤＵのパーセンテージとしての欠落しているＰＤＣＰ ＰＤＵの数は、ｐと呼ばれることがある。例えば、ｐ≧ｍｉｎ（Ｔ÷ｄ、１）の場合、ｅＮＢ８０２は、アップリンク輻輳が発生したと決定し得、上式で、例えば、ｄ≧０は、２つのオペランドの最小値を得る演算のための差（margin）および／または最小基準（min standard）であってよい。ｅＮＢ８０２は、複数のＷＴＲＵ８０１に対してＰＤＣＰシーケンス番号を分析し得る。ｅＮＢ８０２は、アップリンク輻輳結果を組み合わせて（例えば、多数決を使用することによって）、アップリンク輻輳に関する信頼性のより高い推測を形成し得る。ｅＮＢ８０２は、最適化されたアップリンクスケジューリングなどのために、アップリンク輻輳の検出をｅＮＢ８０２のＭＡＣ層に送り得る。
ＷＴＲＵ８０１は、例えば、ＰＤＣＰが、所与のベアラに関連付けられたＩＰパケットにＰＤＣＰ ＳＮを割り振り得るように、ネットワークからの制御シグナリングによって構成され得る。ＷＴＲＵ８０１構成は、ＰＤＣＰインスタンスに適用され得る。ＰＤＣＰインスタンスは、トラフィックを搬送し得るベアラに関連付けられてよい。トラフィックを搬送し得るベアラは、ＷＴＲＵ８０１による廃棄されるパケットのｅＮＢ８０２内での検出から利益を得てよい。例えば、廃棄イベント（例えば、廃棄されるパケット）は、輻輳イベントから生じることがある。ＷＴＲＵ８０１は、ＰＤＣＰシーケンス番号付けにおいてギャップを作製する。廃棄イベントが発生するとき、ＷＴＲＵ８０１は、ＰＤＣＰシーケンス番号付けにおいてギャップを作製する。ＰＤＣＰシーケンシング番号付けは、そうでなければ送信のためのリソースがひとたび利用可能になる（例えば、付与される、構成されるなど）とＰＤＣＰ ＳＤＵにコンバートされ得るＰＤＣＰ ＰＤＵにＰＤＣＰ ＳＮを割り振るであろう廃棄されるパケットを含み得る。
ｅＮＢ８０２は、ＷＴＲＵ８０１とｅＮＢ８０２との間のシグナリングを利用することによって、ネットワーク輻輳を決定し得る。例えば、アップリンクに宛てられたビデオパケット（例えば、リアルタイムビデオパケット）がＷＴＲＵ８０１でローカルに失われるときなど、ＷＴＲＵ８０１は、層間相互作用によってアプリケーション層におけるパケットロスを取り扱うことがある。ＷＴＲＵ８０１は、ｅＮＢ８０２に、ビデオトラフィック（例えば、リアルタイムビデオトラフィック）を搬送する論理チャネルを通知し得る。ＷＴＲＵ８０１は、ｅＮＢ８０２が、リアルタイムビデオ性能の性能を最適化するアップリンクリソースを割り振ることを可能にするために、ｅＮＢ８０２に、ビデオトラフィック（例えば、リアルタイムビデオトラフィック）を搬送する論理チャネルを通知し得る。ＷＴＲＵ８０１は、そのビデオトラフィックフローのうちの１つがアップリンク輻輳による初期パケットロスのために損害を受けた可能性があるかどうかをｅＮＢ８０２に通知する。ＷＴＲＵ８０１は、そのビデオトラフィックフローのうちの１つが近い将来に、例えば一定の時間量内に、パケットロスのために損害を受け得るかどうかをｅＮＢ８０２に通知し得る。ＷＴＲＵ８０１は、データ無線ベアラ（ＤＲＢ）に固有であり得る通知を送り得る。この通知は、ＷＴＲＵのバッファ内に輻輳のインジケーションを備え得る。ＷＴＲＵのバッファ内の輻輳は、経験された遅延などの逗留の時間に基づくことがある。通知は、キューのヘッドパケットに対して廃棄が発生し得る前の残り時間のインジケーションを備え得る。キューパケットのヘッドは、当該ＤＲＢのためのＷＴＲＵのバッファ内で最も古いパケットであってよい。通知は、一定の閾値（例えば、構成可能な閾値）に到達したというインジケーションを備え得る。通知は、可能な廃棄のインジケーションを備え得る。通知は、廃棄イベントのインジケーションを備え得る。通知は、キューのヘッド遅延の報告のインジケーションを備え得る。通知は、キューのヘッドパケット（例えば、関連付けられたＳＤＵ廃棄タイマーの値）に対して廃棄が発生するであろう前の残り時間の報告のインジケーションを備え得る。当該ＤＲＢのためのＰＢＲが、例えば時間の期間内に満たされないとき、通知がトリガされ得る。当該ＤＲＢのためのＰＢＲが、例えば時間の期間内に満たされないとき、ＷＴＲＵ８０１は、通知をトリガさせるように構成され得る。ＷＴＲＵ８０１は、ロスイベント以降の送信において、例えばロスイベントに続く第１の送信において、通知を含み得る。通知は、ＭＡＣ通知、例えば、ＭＡＣ ＣＥに含まれる情報を備え得る。例えば、ＭＡＣ ＣＥは、ＭＡＣバッファステータス報告の拡張であってよい。通知は、禁止機構に供され得る。この禁止機構は、タイマーに基づいてもよいし、および／またはデータ無線ベアラ（ＤＲＢ）に固有であってもよい。例えば、ＷＴＲＵ８０１は、例えば、当該ＤＲＢのための、ＷＴＲＵの構成態様として通知を使用し得る。ＷＴＲＵ８０１は、例えば当該ＤＲＢのための、ＷＴＲＵの構成態様として、禁止機構を使用し得る。
ｅＮＢ８０２は、サービングＷＴＲＵから情報を収集し得る。ｅＮＢ８０２は、ＷＴＲＵにアップリンクグラントを割り振る際にＷＴＲＵにどのように優先度を付けるかを決め得る。ビデオトラフィックフロー（例えば、リアルタイムビデオトラフィックフロー）に初期パケットロスが発生したことを報告し得るＷＴＲＵは、他のＷＴＲＵよりも低い優先度が与えられるように構成され得る。例えば、初期パケットロスを有するそのビデオトラフィックフローへの追加パケットロスは、無視できる性能劣化を引き起こし得るので、ＷＴＲＵは、より低い優先度が与えられるように構成され得る。ｅＮＢ８０２は、グラントをＷＴＲＵ８０１に送り得る。このグラントは、論理チャネルがグラントをどの程度使用し得るかについての情報を含み得る。優先度付けは、リアルタイムビデオトラフィックに影響を与えることがあり、ＷＴＲＵによって搬送される他のトラフィックに影響を与えないことがある。ＷＴＲＵ８０１は、優先度付けがリアルタイムビデオトラフィックに影響を与え得ることを確実にするように構成され得る。ＷＴＲＵ８０１は、優先度付けが、ＷＴＲＵ８０１によって搬送される他のトラフィックに影響を与え得ないことを確実にするように構成され得る。ｅＮＢ８０２は、優先度付けがリアルタイムビデオトラフィックに影響を与え得ることを確実にするように構成され得る。ｅＮＢ８０２は、優先度付けが、ｅＮＢ８０２によって搬送される他のトラフィックに影響を与え得ないことを確実にするように構成され得る。ＷＴＲＵ８０１は、ＷＴＲＵ８０１がグラントを受信したときなどに、ビデオトラフィック（例えば、リアルタイムビデオトラフィック）を搬送する論理チャネル内のトランスポートブロックの間でグラントを割り振り得る。トランスポートブロックは、ＩＤＲフレームなどのより重要なパケットを搬送してよい。
ＷＴＲＵ８０１は、それが例えば時間期間にわたって、パケットを廃棄し、および／または論理チャネルを論理チャネル優先度付け（ＬＣＰ）から排除することをＷＴＲＵ８０１に示す制御シグナリングを受信し得る。制御シグナリングは、ＭＡＣ ＣＥを含み得る。ＷＴＲＵ８０１は、例えば、制御シグナリングによって提供され得る情報を利用することによって、どのパケットを廃棄するかを決定し得る。例えば、情報は、ＤＲＢ識別情報を含み得る。情報は、類似の分類を使用する、例えばＦＰＩビットを使用する、パケットのタイプを含み得る。例えば、ＷＴＲＵ８０１は、ＷＴＲＵ８０１が制御情報（例えば、ＤＲＢ識別情報を含む）を受信したときなどに、当該ＤＲＢのためのＷＴＲＵのバッファ内のキューのヘッドパケット（例えば、最も古いパケット）を廃棄し得る。例えば、ＷＴＲＵ８０１は、ＷＴＲＵのバッファ内の、および／または適用可能なＤＲＢのための、最も古いパケットを廃棄し得る。ＷＴＲＵは、ＷＴＲＵが制御情報を受信したとき、特定のタイプの符号化されたデータに対応し得るパケットを廃棄し得る。制御情報は、タイプインジケーションを含み得る。例えば、ＷＴＲＵ８０１は、それが制御情報を受信したとき、特定のタイプの符号化されたデータに対応する、当該ＤＲＢのための、ＷＴＲＵのバッファ内の最も古いパケットを廃棄し得る。制御情報は、タイプインジケーションおよび／またはＤＲＢ識別情報を含み得る。
ＷＴＲＵ８０１は、ＩＰパケットヘッダをマーキングして、パケットがＩＤＲフレームを搬送するかどうか、またはパケットがＩＤＲフレームを搬送しないかどうかを示し得る。ＷＴＲＵ８０１は、ＷＴＲＵのＭＡＣ層においてマーキングを使用して、ＩＤＲフレームトラフィックに優先度を付け得る。ｅＮＢ８０２は、ＷＴＲＵ８０１が割り振られるアップリンクリソースの総量を制御し得る。例えば、ｅＮＢ８０２が、ＷＴＲＵが割り振られるアップリンクリソースの総量を制御するので、ＷＴＲＵ８０１は、アップリンクスケジューリングでより多くのリソースを得ようとして、パケットをＩＤＲフレームであると過大にマーキングしないことがある。
ＩＤＲフレームは、ＩＰフロー内のパケットのペイロードとして含まれ得る。ＩＤＲフレームを搬送するまたはＩＤＲフレームの後に来るパケットは、ＩＰフローに関連付けられた優先度インジケータ値（例えば、ＦＰＩ値）をデフォルト値にリセットさせ得るインジケータを搬送し得る。デフォルト値は、ネットワーク輻輳が決定される前のＩＰフローの元の優先度インジケータ値であってよい。ノードは、ＩＤＲフレームのインジケータを使用して、優先度インジケータ値をデフォルト値にリセットするように構成され得る。例えば、ノードは、ＩＤＲフレームの後に配置されるＩＰパケットの優先度インジケータ値を（例えば、デフォルト値または元の優先度インジケータ値に）リセットするためにＩＤＲフレームによってトリガされ得る。ビデオ送信機は、ＩＰパケットヘッダ内の一定のフィールドを設定することによって、ＩＤＲフレーム（例えば、または他の重要なビデオフレーム）をネットワークに示し得る。ノードは、ＩＰヘッダ内の一定のフィールドを設定するように構成され得る。ネットワークは、設定をプロトコルスタックの他の層、例えばパケットが優先度インジケータ値を搬送し得るＧＴＰ−Ｕ層、のパケットに変換し得る。
ノードは、例えば、ネットワーク輻輳が決定される（例えば、推測される）場合、ＩＰフローの１または複数のＩＰパケットの優先度インジケータ値を調整し得る。ノードは、ＩＤＲフレームの前に配置され得るＩＰパケットのための優先度インジケータ値を調整し得る。ＩＤＲフレームの後に配置され得る１または複数のＩＰパケットは、異なる優先度インジケータ値を持ってよい。例えば、ＩＤＲフレームの前に配置され得るＩＰパケットの優先度インジケータ値は、ＩＤＲフレームの後に配置されるＩＰパケットよりも低い優先度を示し得る。
ＩＤＲフレームと優先度インジケータ値との間の相関は、他のビデオコーデックに拡張され得る。例えば、ＭＰＥＧ−２、ＭＰＥＧ−４などにおけるイントラフレーム（intra-frame）は、ＩＤＲフレームに類似したやり方で使用され得る。
例えば、ＷＴＲＵがＢＳＲメッセージを介してバッファステータスを報告するとき、ＷＴＲＵは、アップリンクバッファ内にパケットのための優先度インジケータ情報を含み得る。優先度インジケータ情報は、優先度インジケータ値のためのパケットのうちどれくらい多くが存在するかを含み得る。ＷＴＲＵは、例えば、ＷＴＲＵのバッファが閾値のまたはそれを下回るデータを含む場合、閾値を下回る優先度に関連付けられたデータのためのＢＳＲ報告をトリガしないことがある。例えば、ＷＴＲＵは、１または複数のパケットを廃棄し得る。ＷＴＲＵは、後続の送信にＢＳＲを含み得る。例えば、ＷＴＲＵは、ＳＲを実行せずに正常なＢＳＲをトリガしてよく、および／またはＷＴＲＵはパディングＢＳＲを含んでよい。例えば、バッファ内で待機しているパケットが低優先度パケットであるときなど、輻輳が発生した場合、ｅＮＢは、リソースをＷＴＲＵに割り振らないことがある。
ビデオ送信機は、ビデオ重要度情報を提供し得る。ビデオ重要度情報は、例えば、ビデオ重要度情報がルータによってアクセス可能であるように、ＩＰパケットヘッダに含まれ得る。ＤＳＣＰフィールドおよび／またはＩＰパケット拡張フィールドが使用されてよい（例えば、ＩＰｖ４の場合）。
トラフィッククラスフィールドの１または複数のビット（例えば、最初の６つのビット）は、ＤＳＣＰインジケータとして働き得る（例えば、ＩＰｖ６の場合）。拡張ヘッダは、ビデオ重要度情報を搬送し得る（例えば、ＩＰｖ６の場合）。
パケットマッピングは、テーブルルックアップによって実行され得る。例えば、ＷＴＲＵは、ＩＰパケットをトランスポートブロックにマッピングするテーブルを構築し得る。
ノードは、リアルタイムビデオアプリケーションおよび／またはビデオ会議などのビデオテレフォニーにユーザ体感品質（ＱｏＥ）を利用するように構成され得る。ユーザ体感品質（ＱｏＥ）は、リアルタイムビデオアプリケーションおよび／またはビデオ会議などのビデオテレフォニーのために設計および／または最適化され得る。パケットロスは、リアルタイムビデオトラフィックフローの一部（例えば、ネットワーク輻輳の場合、トラフィックフローのごく一部）に集中され得る。例えば、パケットロスは、ネットワーク輻輳の場合、リアルタイムビデオトラフィックフローのトラフィックフローのごく一部に集中され得る。例えば連続した時間的予測ビデオコーディング構造を有する、リアルタイムビデオトラフィックフロー内でパケットが失われるとき、（例えば、連続した時間的予測ビデオコーディング構造内の）追加パケットロスによる性能劣化は、第１のパケットロスによるものよりも著しく小さくなり得る。連続した時間的予測ビデオコーディング構造は、ＩΡΡΡ構造、または階層型Ｐ内の時間層０などの階層型Ｐビデオコーディング構造などであってよい。パケットが、連続した時間的予測ビデオコーディング構造を有するリアルタイムビデオトラフィックフロー内で失われるとき、例えば、追加パケットロスの性能劣化が第１のパケットロスによるものよりも著しく少ないことによる、複数のリアルタイムビデオトラフィックフローの全体的ＱｏＥは最適化され得る。
複数のリアルタイムビデオトラフィックフローの全体的ＱｏＥを最適化することは、バッファ膨張（buffer-bloat）に対処し得る。バッファ膨張は、安価なメモリの入手しやすさによるバッファの急増およびバッファサイズの暴騰ならびに／または増加しつつあるビデオテレフォニートラフィックなどのインターネットトラフィックの増加によって特徴付けられ得る。バッファ膨張では、バッファオーバフローにより誘発されるパケットロスはまれであり、バッファ占有量は、インターネットトラフィックの爆発的増加により永続的に大きいほど、バッファ空間は非常に大きくてよい。永続的にいっぱいのバッファの発生は、ワイヤレスネットワークを経由して送信されるデータパケットによって経験される増加されたキューイング遅延につながることがある。
アクティブキュー管理（ＡＱＭ）は、バッファ膨張に対処するために使用され得る。例えば、ＡＱＭアルゴリズムは、キュー内での伝送制御プロトコル（ＴＣＰ）データパケット滞在時間を算出するために利用され得る。ノードは、キューにおけるコンピュータ伝送制御プロトコルデータパケット滞在時間に基づいてデータパケットを保持するのかそれとも廃棄するかを決めるように構成され得る。ＡＱＭアルゴリズムは、ビデオテレフォニーアプリケーション（例えば、Ｓｋｙｐｅ、ＦａｃｅＴｉｍｅ、Ｇｏｏｇｌｅ＋ Ｈａｎｇｏｕｔなどのビデオ会議アプリケーションなど）によって生成されるユーザデータグラムプロトコル（ＵＤＰ）データパケットフローに不適切に対処することがある。ＡＱＭアルゴリズムは、例えば、ＡＱＭアルゴリズムを用いているにもかかわらず発生したパケットロスを検出したときのフレームのフリーズにより、十分なユーザ体感品質（ＱｏＥ）をビデオ会議アプリケーションのユーザに不適切に提供することがある。
リアルタイムビデオトラフィックフローのパス上に複数のルータが存在し得るとき、ロス集中タイプのキュー管理が誘発され得る。リアルタイムビデオトラフィックフローの発信元と送信先との間に複数のパスが存在し得るときにも、ロス集中タイプのキュー管理が誘発され得る。例えば、ＩＰパケットヘッダ内で、第１のビットは、フローがパケットロスを経験したことをダウンストリームルータに示すために使用され得る。第２のビットは、例えば、ビデオ誤り伝播がＩフレームの挿入または基準画像選択（ＲＰＳ）によって停止されたことをダウンストリームルータに示すために使用され得る。第２のビットは、例えば、ルータがパケットロスに関するフィードバックを受信したのでビデオエンコーダが誤り伝播を停止する措置を講じたことをダウンストリームルータに示すために使用され得る。第３のビットは、ＱｏＥに影響を与え得るイントラ符号化されたビデオフレームまたはＰフレームをパケットが搬送するかどうかを示すために使用され得る。ＩＰヘッダ以外のパケットヘッダ、拡張されたパケットヘッダ、ラベル、および情報要素（ＩＥ）が、ロス集中を実現するために利用され得る。
ロス集中は、ルータがＩＰオプションフィールドの使用をサポートしない可能性があり、他のシグナリングがロス集中を可能にし得る場合などに、部分的に実行され得る。個々のルータは、ルータで実行された保護（preservation）および／または測定に基づいてロス集中を実施するように構成され得る。そのような技法は、（例えば、ＩＰヘッダまたは他のパケットヘッダ内に）他のルータおよび／またはビデオ符号化デバイスから受信されたロス輻輳シグナリングのない場合ですら、個々のルータがロス集中を自律的に実行することを可能にし得る。
ノードは、ロス集中制御された遅延（ＬＣ−Ｃｏｄｅｌ）を利用して、ビデオ会議アプリケーションの最大数のユーザに許容できるユーザ体感品質（ＱｏＥ）を提供し得る。例えば、ノードは、ロス集中制御された遅延（ＬＣ−Ｃｏｄｅｌ）を利用して、ロスをユーザのビデオストリームのサブセットに集中させることによって、ビデオ会議アプリケーションの最大数のユーザに許容できるユーザ体感品質（ＱｏＥ）を提供し得る。ＬＣ−Ｃｏｄｅｌは、ＴＣＰとリアルタイムビデオフローの混合物を処理する機能を提供し得る。例えば、ＬＣ−Ｃｏｄｅｌを利用するノードは、ビデオフローと異なるようにＴＣＰフローを扱い得る。ＬＣ−Ｃｏｄｅｌを利用するノードは、ＴＣＰフローの場合など、パケットを廃棄するかどうかを決定する際に、デキューイングされたパケットの滞在時間を考慮し得る。ＬＣ−Ｃｏｄｅｌを利用するノードは、ビデオフローの場合など、ロス集中を強制し得る。ＬＣ−Ｃｏｄｅｌを利用するノードは、例えば、ビデオパケットが属するフローの優先度を考慮することによって、ロス集中を強制し得る。ＬＣ−Ｃｏｄｅｌを利用するノードは、例えば、パケットを廃棄する際にビデオフローにより作成されるキューイング遅延を考慮することによって、ロス集中を強制し得る。ＬＣ−Ｃｏｄｅｌを利用するノードは、エンキューイングの前に廃棄され得るそのビデオパケットを提供し得る。ＬＣ−Ｃｏｄｅｌを利用するノードは、デキューイングの後に廃棄され得るそのビデオパケットを提供し得る。
パケットロスは、パケットロスを引き起こしたルータ以外のルータで検出され得る。このパケットロス検出は、本明細書では、開ループ解決策と呼ばれることがある。
本明細書で説明される１または複数の実施形態は、パケット交換デバイスに適用可能であってよく、限定するものではないが、パケット交換デバイスは、限定するものではないが、無線送受信ユニット（ＷＴＲＵ）、基地局（例えば、ｅＮＢ、リモートラジオヘッド、中継局、フェムトｅＮＢ、ピコｅＮＢなど）、Ｓ−ＧＷ、および／またはＰ−ＧＷなどの汎用ルータおよび特殊ルータ、ならびにビデオコーデックを含む。
ルータは、リアルタイムビデオトラフィックフローを搬送するように構成され得る。ルータは、協働する、および／またはリアルタイムビデオトラフィックフローの全体的なユーザ体感品質（ＱｏＥ）を最適化するように構成され得る。
図９は、例示的なビデオ会議システム９００を示す。ビデオ会議システム９００は、リアルタイムビデオトラフィックを通信し得る。リアルタイムビデオトラフィックは、ＩＰＰＰ構造または階層型Ｐビデオコーディング構造（例えば、時間層０）などの連続した時間的予測ビデオコーディング構造を採用し得る。
説明の明快さおよび容易さのために、図９には、単一のビデオテレビ会議セッションが示されている。ビデオ会議システム９００は、同時に発生し得る複数のビデオテレビ会議セッションをサポートし得る。
図９に示されるビデオテレビ会議セッションは、複数のパス９０２、９０４、９０６を利用し得る。各パスは、１または複数のルータ９０８、９１０、９１２、９１４を備え得る。１または複数のルータ９０８、９１０、９１２、９１４は、インターネットなどのネットワーク９１６を介して互いに接続され得る。ＷＴＲＵ９１８およびコンピュータ９２０などのクライアントデバイスも、ネットワーク９１６に接続され得る。
図１０は、特定のルータ１００２の観点からビデオ会議システム１０００がどのように見え得るかの一例を示す。ビデオ会議システム１０００は、図１０に示されていない追加ルータを備えてよい。ルータ１００２は、そのような追加ルータに接続されてよい。ルータ１００２は、ＷＴＲＵ１００４、１００６、１００８、１０１０、１０１２、およびコンピュータ１０１４、１０１６、１０１８、１０２０、１０２２などのクライアントデバイスに接続され得る。ルータ１００２は、インターネットなどのネットワーク１０２４を介してクライアントデバイスに接続され得る。
パケットを消失することが、回復されるビデオの品質に及ぼす影響は、パケット、何が前のパケットに起こったのか、および／または何が将来のパケットに起こり得るかに依存することがある。トラフィックフローのＱｏＥを最適化するなどのために、状態変数が、複数のリアルタイムトラフィックフローのトラフィックフローに対して維持され得る。例えば、状態変数は、各トラフィックフローに対して維持され得る。ビデオエンコーダは、例えば、パケットロス適応において、ビデオフレーム（例えば、特殊化されたビデオフレーム）を送り得る。ビデオエンコーダは、ビデオフレームおよび／または特殊化されたビデオフレームを送るとき、フレームの優先度を付けられた扱いのためにルータに示すように構成され得る。
ルータは、各ビデオトラフィックフローに対して１または複数の状態変数を維持するように構成され得る。特定のビデオトラフィックフローのための状態変数は、そのビデオトラフィックフローに対して発生した可能性のあるネットワークイベントを示し得る。ネットワークイベントは、パケットロス、過度の遅延などを含み得る。ルータは、他のルータとの間で情報を交換するように構成され得る。ルータは、他のルータとの間で情報を交換して、関与させられたルータ間で状態情報を一致するように保つように構成され得る。ビデオ送信機は、適切な措置を講じることによってネットワークイベントに反応し得る。例えば、ビデオ送信機は、パケットロスの場合などに、イントラ符号化されたフレームを生成し得る。ビデオ送信機は、基準画像選択（ＲＰＳ）を実行し得る。ビデオエンコーダは、ネットワークイベントに応答して適切な措置を講じたというイベントを伝えるキーパケットを示し得る。
例えば、リアルタイムビデオ品質に対するパケットロスの影響が活用され得るときなど、パケットがリアルタイムビデオトラフィックフロー内で失われるとき、追加パケットロスによる性能劣化が、第１のパケットロスによる性能劣化よりも著しく低いことがある。例えば、追加パケットロスによる性能劣化が、第１のパケットロスによる性能劣化よりも著しく低くなり得るとき、複数のリアルタイムビデオトラフィックフローの全体的ＱｏＥは最適化され得る。例えば、ビデオトラフィックフローがパケットロスにより損害を受けるとき、ルータは、将来のパケットロスをフローに制限しようとして、ロス集中に基づくキュー管理方式を用いるように構成され得る。ルータは、将来のパケットロスをそのフローに制限し得る。ルータは、他のフローのＱｏＥを劣化させることを回避し、他のフローに対する高いＱｏＥをもたらし得る。
ルータは、ネットワーク輻輳の場合などに、パケットロスを経験していないリアルタイムビデオトラフィックフローを選択して、パケットを廃棄し得る。ルータは、ビデオトラフィックフローをランダムに選択して、パケットを廃棄し得る。ルータは、１または複数の規則またはポリシーによりパケットを廃棄するためにビデオトラフィックフローを選択し得る。この規則またはポリシーは、一定の公平性基準を強制するように設計され得る。例えば、ルータは、過度に高いデータ転送速度でリアルタイムビデオトラフィックフローのパケットを廃棄し得る。
ルータは、劣化させられていないビデオストリームの前にパケットを廃棄するために、劣化させられたビデオストリームを選択するように構成され得る。劣化させられたパケットストリームは、廃棄されるパケットを備えるリアルタイムビデオトラフィックフローを指すことがある。例えば、劣化させられたパケットストリームは、リフレッシュパケットに先行する廃棄されるパケットを備えるリアルタイムトラフィックフローであってよく、この廃棄されるパケットはＰフレームを備え、リフレッシュパケットはＩフレームを備える。ルータは、劣化されていないビデオストリームの前にパケットを廃棄するために劣化させられたビデオストリームを選択するなど、パケットを廃棄するためにすでにパケットロスを経験したビデオトラフィックフローを選択することに重点を置くように構成され得る。優先度付けを使用するルータは、初期パケットロス後の追加パケットロスによる潜在的により低いＱｏＥ劣化を活用するように構成され得る。
図１１Ａは、ロス集中に基づくパケット廃棄方式の例を示す図である。図１１Ｂは、パケットがランダムに廃棄される例を示す図である。図１１Ａと図１１Ｂの両方において、誤り伝播を経験し得るフレーム（例えば、フレーム範囲）は、参照番号１１０２によって示される。瞬時デコーダリフレッシュ（ＩＤＲ）フレーム１１０４は、誤り伝播を停止するために使用され得る。廃棄されるパケットの数は、ロス集中に基づくパケット廃棄方式およびランダムパケット廃棄方式と同じである。ロス集中に基づくパケット廃棄方式では、ユーザ間での誤り伝播の時間の全体（total fraction）が著しく減少され得る。
ロス集中に基づくキューパケット廃棄は、システムに対するトラフィック負荷の減少を引き起こし得る。例えば、ルータは、ＩＤＲフレームを使用して誤り伝播を停止し得、より少ないＩＤＲフレームが生成され得る。
ルータは、ロス集中に基づくキュー管理などにおいて、リアルタイムビデオトラフィックフローを識別し得る。例えば、ルータは、ＩＰ５タプルの使用を介して、リアルタイムビデオトラフィックフローを識別し得る。ＩＰ５タプルは、ＩＰ発信元アドレス、ＩＰ宛先アドレス、ＩＰ発信元ポート番号、ＩＰ送信先番号、および／またはプロトコルタイプを備え得る。
いくつかのビット（例えば、ビットａ、ビットｂ、およびビットｃなどの３つのビット）が、ＩＰパケットヘッダ内で定義され得る。例えば、ビットは、ＩＰパケットヘッダの拡張フィールド内で定義され得る。ビットは、ＩＰパケットヘッダ内のＥＣＮフィールドまたはＤＳＣＰフィールドにマッピングされ得る。ビットの数は、他のタイプのパケットヘッダ、パケットヘッダの拡張フィールド、ラベル、または情報要素（ＩＥ）内で定義され得る。ビットの数は、利用可能なビット空間に応じて変化してよい。
第１のビットａは、輻輳インジケータとして定義され得る。ルータは第１のビットａを制御し得る。第１のビットａは、トラフィックフローがパケットロスを経験したかどうかを備える情報を伝え得る。したがって、ビットａは、消失パケットインジケータの例となり得る。例えば、ビットａは、トラフィックフローがパケットロスを経験したことを示し得る１の値を伝え得る。ビットａは、トラフィックフローがパケットロスを経験していないことを示し得る０の値を伝え得る。ビットａは、ビットｂの最後の設定以降にフローがパケットロスを経験したかどうかに関する情報を伝え得る。ビットａは、フローが最初に確立された以降にフローがパケットロスを経験したかどうかに関する情報を伝え得る。
ビットｂは、ビデオ符号化適応が実行されたかどうかを備える情報を伝え得る。ビデオ符号化適応は、ＩＤＲフレームまたはフレームのスライスの生成、基準画像選択（ＲＰＳ）などを備え得る。例えば、ビットｂは、ビデオ符号化適応が実行されたことを示し得る１の値を伝え得る。ビットｂは、ビデオ符号化適応が実行されていないことを示し得る０の値を伝え得る。ビットｂは、誤り伝播軽減が実行されたかどうかに関する情報を伝え得る。誤り伝播軽減は、フレームのイントラ符号化されたスライスの生成および／または周期的イントラリフレッシュ（intra-refresh）における一連のイントラ符号化されたマクロブロックの生成を備え得る。
ビットｃは、パケットが重要なフレームまたはフレームの重要な部分を搬送するかどうかに関する情報を伝え得る。重要なフレームまたはフレームの重要な部分は、ＩＤＲフレーム、誤り伝播に対する著しい影響を有するＰフレーム、ユーザ体感品質（ＱｏＥ）に著しく影響を与える可能性を有するＰフレーム、フレームのイントラ符号化されたスライス、および／または周期的イントラリフレッシュにおける一連のイントラ符号化されたマクロブロックを備え得る。例えば、ビットｃは、パケットが重要なフレームまたはフレームの重要な部分を搬送することを示し得る１の値を伝え得る。ビットｃは、パケットが重要なフレームまたはフレームの重要な部分を搬送しないことを示し得る０の値を伝え得る。
ルータ（例えば、各ルータ）は、各フローｋのための状態変数Ｓｔａｔｅ＿ｋを維持するように構成され得る。ルータは、ビットを設定および／または読み取るように構成され得る。ルータは、そのルータによって維持されるローカル状態変数Ｓｔａｔｅ＿ｋなどの、状態変数Ｓｔａｔｅ＿ｋを更新するように構成され得る。ルータは、インターネット上のルータ、セルラーネットワーク内の基地局、ＷｉＦｉアクセスポイント、ならびに／またはＬＴＥ／ＥＰＣネットワーク内のＳ−ＧＷおよび／もしくはＰ−ＧＷなどを備え得る。ルータは、いくつかの措置のうちの１または複数を実行し得る。ルータは、パケットに関連付けられた消失パケットインジケータに基づいてパケット（例えば、パケットｎ）を廃棄するかどうかを決めるように構成され得る。例えば、ルータは、ビットａが、フローｋに属する着信パケットｎに対する値０（例えば、おそらくトラフィックフローがパケットロスを経験していないことを示す）を伝える場合、パケットｎを廃棄するかどうかを決めるように構成され得る。ルータが、パケットｎを廃棄すると決めた場合、ルータは、状態変数Ｓｔａｔｅ＿ｋをＬＯＳＳの値に設定するように構成され得る。
ルータは、ビデオ符号化適応がトラフィックフロー上で実行されたかどうかを決定するように構成され得る。例えば、ビットｂが、ビデオ符号化適応が実行されたことを示す場合、ルータは、状態変数Ｓｔａｔｅ＿ｋをＮＯ＿ＬＯＳＳの値に設定するように構成され得、ルータは、パケットｎをルーティングし得る。状態変数Ｓｔａｔｅ＿ｋがＬＯＳＳの値を持つ場合、ルータは、トラフィックフローがパケットロスを経験したことを示すなどのために、ビットａの値を１に設定するように構成され得、ルータは、パケットｎをルーティングするように構成され得る。タイマーは、設定された値以上の間、状態変数Ｓｔａｔｅ＿ｋが確実にＬＯＳＳに設定されないようにするように設定され得る。ルータは、タイマーを設定するように構成され得る。着信パケットｎに対するビットａの値が１の場合、ルータは、状態変数Ｓｔａｔｅ＿ｋをＬＯＳＳの値に設定するように構成され得、ルータは、パケットｎをルーティングし得る。
例えば、次のとおりである。
ルータは、失われる可能性のあるビットｂ＝１を搬送するアップストリームパケットを処理するように構成され得る。ルータは、いくつかの措置のうちの１または複数を実行し得る。ルータは、タイマーが満了すると状態変数Ｓｔａｔｅ＿ｋをＮＯ＿ＬＯＳＳの値に設定するように構成され得る。例えば、次のとおりである。
パケットロスフィードバックが用いられる場合、Ｔ＿ｌｏｓｓ＿ｆｂ＿ｋの値は、パケットロスフィードバック遅延よりもわずかに大きくてよい。パケットロスフィードバック遅延は、ＲＴＴの遅延、例えばフローｋのためのＲＴＴ＋ビデオ受信機における処理遅延＋ビデオ送信機における処理遅延などであってよい。ビデオ受信機における処理遅延は、ＲＴＣＰパケットロス報告を生成し、その報告を送信するためであってよい。ビデオ送信機における処理遅延は、ＩＤＲフレームを生成し、ビットｂ＝１を搬送するパケットを送るためであってよい。ＲＴＴ＿ｋを推定するために、ルータは、特定のパケットにタイムスタンプを付加してよい。ルータは、ＲＴＴ＿ｋを推測し得る。例えば、ルータは、ＳＩＰ ＩＮＶＩＴＥメッセージにタイムスタンプを付加し、タイムスタンプｔk1を生じ得る。例えば、第１のデータパケットがルータを通過するとき、ルータは別のタイムスタンプｔk2を生成し得る。時間差ｔk2−ｔk1は、ＲＴＴ＿ｋ＋処理遅延の推定値として使用され得る。Ｔ＿ｌｏｓｓ＿ｆｂ＿ｋは、２＊（ｔk2−ｔk1）に等しく設定され得る。
通信ネットワーク内のルータは、ＲＴＣＰパケットが反対方向に向かうのと並行して、ディープパケットインスペクションを行い得る。通信ネットワーク内のルータは、ＲＴＣＰパケットが反対方向に向かうのと並行して、ディープパケットインスペクションを行い得る。通信ネットワーク内のルータのグループは、ＲＴＣＰパケットが反対方向に向かうのと並行して、ディープパケットインスペクションを行い得る。ルータは、例えば、フローｋのためのＲＴＣＰパケットが検出される場合、ディープパケットインスペクションを使用して、ビデオ符号化適応をトリガするように構成され得る。ルータが、ビデオ符号化適応のためのトリガを検出した場合、ルータは、タイマーを用いるように構成され得る。例えば、次のとおりである。
ルータは、Ｔ＿ｌｏｓｓ＿ａｄａｐｔ＿ｋのための値が、フローｋのためのＲＴＣＰパケットを検出するイベントとビデオ適応の結果としてフローｋに関連する第１のビデオフレームがダウンストリームルータに到着するイベントとの時間差に等しいように構成され得る。この時間差は、最小遅延と１つのＲＴＴ＿ｋとの間の任意の場所であってよい。時間差は、メディアパスビデオフローｋ上でのルータの相対的ロケーションに依存し得る。ルータは、ＲＴＴ＿ｋの値をＴ＿ｌｏｓｓ＿ａｄａｐｔ＿ｋに使用し得る。ルータは、一定の遅延をＴ＿ｌｏｓｓ＿ａｄａｐｔ＿ｋに使用し得る（例えば、３００ｍｓよりも大きいまたは小さい値）。
ルータは、例えば、ビデオ符号化適応または誤り伝播軽減が発生した（例えば、着信パケットにおいてビットｂ＝１）場合、タイマーＴ＿ｌｏｓｓ＿ｆｂ＿ｋをキャンセルするように構成され得る。ルータは、例えば、フィードバック遅延の前に重要なフレームまたはフレームの重要な部分を搬送するパケットが到着した（例えば、着信パケットにおいてビットｃ＝１）場合、タイマーＴ＿ｌｏｓｓ＿ｆｂ＿ｋをキャンセルするように構成され得る。
ルータは、ディープパケットインスペクションを使用して、アップストリームルータが、特定のビデオフローまたは複数のビデオフローに対してパケットロスが発生したかどうか知ることが可能であるように構成され得る。
ルータは、キュー管理においてフローｋを低い優先度にし得る。ルータは、例えば、状態変数Ｓｔａｔｅ＿ｋがＬＯＳＳの値を持つ場合、キュー管理においてフローｋを低い優先度にし得る。例えば、ルータは、パケットロスをフローｋに集中させ得る。
ルータは、どのビデオトラフィックフローがパケットを廃棄させた可能性があるかを決める際にさまざまな設計基準を使用するように構成され得る。例えば、ルータは、例えば、ビデオトラフィックフローに公平性を与えるために、パケットロスを集中させた可能性のあるフローに対する最大持続時間Ｔmaxを設定し得る。Ｔmaxの値は、Ｔ＿ｌｏｓｓ＿ｆｂ＿ｋよりも大きくてよい。ルータは、パケットロスを被ったフローｋのための状態変数Ｔloss_kを維持することによって最大持続時間を設定し得る。Ｔloss_kがＴmaxよりも大きいかそれに等しい場合、ルータは、パケットロスをフローｋに集中させることを停止してよく、ルータは、集中させられたパケットロスを受信するための異なるフローｊを選択してよい。ルータは、ラウンドロビンで、フローｋと異なり得るフローｊを選択し得る。
ビデオ送信機の一例は、インターネットに接続されたＷＴＲＵであってよい。ビデオ送信機は、発信パケットに対するビットａを０の値に設定するなどの、いくつかの措置を実行し得る。ビデオ送信機が、前のパケットロスのインジケーションを受信した場合、ビデオ送信機はビデオ符号化適応をトリガし得る。ビデオ符号化適応は、例えば、ＩＤＲフレームを生成すること、基準画像選択更新、および／または符号化されたビデオのビットレートを減少させることを含み得る。ビデオ送信機は、タイマーを起動させるように構成され得る。ビデオ送信機は、タイマーが満了する前にビデオ送信機が送信し得る次のパケットに対してビットｂを１の値に設定し得る。ビデオ送信機は、ＩＤＲフレームを搬送し得るパケットに対してビットｃを１の値に設定し得る。タイマーが満了すると、ビデオ送信機は、後続のパケットに対してビットｂを０の値に設定し得る。ビデオ送信機は、パケットロスのインジケーションを受信するように構成され得る。ビデオ送信機は、反対方向に対するパケットロス率を観測し得る。反対方向は、パケットロス報告の同じ方向であってよい。反対方向に対して観測される低いパケットロス率が低いことは、ネットワーク容量がビデオ送信レートよりも高いことを示し得る。ビデオ送信機が、延長された時間期間にわたってパケットロスのインジケーションを受信しておらず、反対方向に対して観測されるパケットロス率が低い場合、ビデオ送信機はビデオ符号化適応を実行し得る。例えば、ビデオ送信機は、符号化されたビデオのビットレートを増加し得る。
ビデオ送信機は、ビデオ符号化適応を行い得る。例えば、ビデオ送信機は、以下を実行し得る。
ビデオ送信機は、誤り伝播軽減を実行するように構成され得る。誤り伝播軽減は、フレームのイントラ符号化されたスライスの生成または一連のイントラ符号化されたマクロブロックｍ周期的イントラリフレッシュの生成を備え得る。例えば、ビデオ送信機は、以下を実行し得る。
Ｔgoodは、ビデオ送信機から受信機までのパスの容量が十分である時間期間であってよい。反対方向のパケットロス率が低い場合、ビデオ送信機は、反対方向のロス報告を送り得る。ロス報告は、パケットがビデオ送信機に向かう途中で廃棄される可能性が低いことを示し得る。
例えば、ＲＴＰシーケンス番号のギャップが検出された場合、ビデオ受信機は、ＲＴＣＰパケットロス報告をビデオ送信機に送り得る。ＲＴＣＰパケットロス報告は、例えば、ピクチャロスインジケーション（ＰＬＩ）パケットまたはスライスロスインジケーション（ＳＬＩ）パケットであってよい。例えば、次のとおりである。
ＲＴＰシーケンス番号のギャップが検出された場合
ＲＴＣＰパケットロス報告をビデオ送信機に送り返す
終了
例えば、ＲＴＣＰトラフィックの量が通信ネットワーク内のトラフィックの総量の所定の割合を超えない場合、ビデオ受信機は、ＲＴＣＰパケットをビデオ送信機に送り返し得る。
図１２は、ビデオテレビ会議などのリアルタイムビデオアプリケーションのためのロス集中に基づくキュー管理を実施する、ビデオ送信機、ルータ、およびビデオ受信機などの、ノードのための例示的な呼フローを示す図である。ノードは、第１のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられ得る。第１のリアルタイムビデオトラフィックフローは、複数のパケットを備え得る。各パケットは、消失パケットインジケータ（例えば、ビットａ）を備え得る。例えば、１２１０において、ビデオ送信機１２０２はフローｋのパケットｎをルータ１２０４に送り得、ａビット、ｂビット、およびｃビットは０の値を持ち得る。
ノードは、第１のリアルタイムビデオトラフィックフロー内の第１のパケットを廃棄するように構成され得る。ノードは、廃棄されるパケットを示すように、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように構成され得る。例えば、１２１２において、ルータ１２０４はパケットｎを廃棄し得る。ノードは、廃棄されたパケットに基づいて、第１のリアルタイムビデオトラフィックフロー内の第２のパケットのための消失パケットインジケータを更新するように構成され得る。例えば、ルータ１２０４は、１２１４においてフローｋに対する状態を更新し得、したがって、Ｓｔａｔｅ＿ｋはＬＯＳＳの値を持ち得る。１２１６において、ビデオ送信機１２０２は、フローｋのパケットｎ＋１をルータ１２０４に送り得る。ａビット、ｂビット、およびｃビットは、０の値を持ち得る。ビデオ送信機１２０２は、パケットｎが廃棄されたことに気づかないことがある。１２１８において、ルータ１２０４は、１２１２でパケットｎが廃棄されたことを示すために、ａビットの値を１に変更し得る。
ノードは、第２のリアルタイムビデオトラフィックフローを受信するように構成され得る。状態変数は、ノードにおいて第２のリアルタイムビデオトラフィックフローに関連付けられ得る。第２のリアルタイムビデオトラフィックフローは複数のパケットを備え得、各パケットは、消失パケットインジケータを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの状態変数を第２のリアルタイムビデオトラフィックフローの状態変数と比較するように構成されたプロセッサを備え得る。第２のリアルタイムビデオトラフィックフローの状態変数は、廃棄されるパケットを示さないことがある。ノードは、第１のリアルタイムビデオトラフィックフローの状態変数が廃棄されるパケットを示すことに基づいて、第１のリアルタイムトラフィックフローのパケットを廃棄すると決定する（例えば、第２のリアルタイムトラフィックフローのパケットを廃棄することとは反対に）ように構成され得る。
ノードは、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定したことに基づいてノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定したことに基づいて第１のリアルタイムビデオトラフィックフローの第３のパケットのための消失パケットインジケータを更新するように構成されたプロセッサを備え得る。ノードは、第３のパケットのパケットヘッダ内のビットは、第３のパケットがリフレッシュフレームを備えることを示すと決定し、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備える、第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備え得る。リフレッシュフレームは、部分的リフレッシュフレームを備え得る。第３のパケットは、Ｉフレームを備え得る。
ノードは、第１のリアルタイムビデオトラフィックフローの第２のパケットを第２のノードに送るように構成されたプロセッサを備え得る。例えば、１２２０において、パケットｎ＋１がルータ１２０４からルータ１２０６に送られるとき、ｂビットおよびｃビットは０の値を持ち得、ａビットは１の値を持ち得る。ルータ１２０６は、１２２２においてフローｋに対する状態を更新し得、したがって、Ｓｔａｔｅ＿ｋはＬＯＳＳの値を持ち得る。
ノードは、状態変数を使用して、パケットロスを、劣化させられたパケットストリームに集中させるように構成され得る。ＦＰＩは、消失パケットインジケータを備え得る。
第１のリアルタイムビデオトラフィックスローの第１のパケットは、Ｐフレームを備え得る。第１のリアルタイムビデオトラフィックスローの第２のパケットは、Ｐフレームを備え得る。
ノードは、廃棄されるパケットと、第２のパケットがリフレッシュフレームを備えないという決定とに基づいて、リアルタイムビデオトラフィックフロー内の第２のパケットのための消失パケットインジケータを更新するように構成されたプロセッサを備え得る。消失パケットインジケータは、パケットのパケットヘッダ内にビットを備え得る。例えば、消失パケットインジケータは、第２のノードに、第２のノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように命令する。例えば、１２２４において、ルータ１２０６は、フローｋのパケットｎ＋１をビデオ受信機１２０８に送り得る。ｂビットおよびｃビットは０の値を持ち得、ａビットは１の値を持ち得る。ビデオ受信機１２０８は、１２２６において、ＲＴＰ制御プロトコル（ＲＴＣＰ）ロスフィードバックをルータ１２０６に送り得る。ＲＴＣＰロスフィードバックは、１２２８においてルータ１２０４に、さらに１２３０においてビデオ送信機１２０２に送られ得る。ビデオ受信機１２０８は、例えば、１２２６においてＲＴＣＰロスフィードバックを組み立てるとき、着信パケットｎ＋１の輻輳インジケータビット（例えば、ａ＝１）を考慮し得る。輻輳インジケータビットは、ビデオ受信機１２０８が、以前のパケットはネットワーク内で遅延させられたのではなく廃棄されたと推論することを可能にし得る。ビデオ受信機１２０８が、以前のパケットはネットワーク内で遅延させられたのではなく廃棄されたと推論するとき、ビデオ受信機１２０８は、ビデオ受信機１２０８が、ａ＝１を有する着信パケットを受信したことに応答して、１２２６においてＲＴＣＰロスフィードバックを生成し得る。ビデオ受信機１２０８が、以前のパケットはネットワーク内で遅延させられたのではなく廃棄されたと推論するとき、ビデオ受信機１２０８は、１２２６においてＲＴＣＰロスフィードバックを生成し得、ビデオ受信機１２０８は、以前のパケットに関連付けられたタイムアウトを待機せず、以前のパケットが消失したと決定し得る。
１２３２において、ビデオ送信機１２０２は、１または複数のビデオ符号化適応を実行し得る。例えば、ビデオ送信機１２０２は、ＩＤＲを生成し得る。ビデオ送信機１２０２はＲＰＳを更新し得る。ビデオ送信機１２０２はタイマーＴを起動させ得る。
１２３４では、ビデオ送信機１２０２は、フローｋのパケットｎ＋ｍをルータ１２０４に送り得る。ａビットは０の値にリセットされ得、ｂビットおよびｃビットは、ビデオ符号化適応が実行され、パケットが例えばＩＤＲフレームを含むことを示すために、１の値に設定され得る。
ルータ１２０４は、ａビットの新しい値、例えば０に基づいて、１２３６においてフローｋに対する状態を更新し得、したがって、Ｓｔａｔｅ＿ｋはＮＯ＿ＬＯＳＳの値を持ち得る。１２３８において、ルータ１２０４は、フローｋのパケットｎ＋ｍをルータ１２０６に送り得る。１２３８においてパケットｎ＋ｍがルータ１２０４からルータ１２０６に送られるとき、ｂビットおよびｃビットは１の値を持ち得、ａビットは０の値を持ち得る。
１２４０において、ビデオ送信機１２０２は、フローｋのパケットｎ＋ｍ＋１をルータ１２０４に送り得る。ａビットは、０の値を持ち得る。ｂビットは、ビデオ符号化適応が実行されたことを示すために、１の値を持ち得る。ビデオ符号化適応は、ＩＤＲ挿入またはＲＰＳ選択であってよい。ｃビットは、パケットｎ＋ｍ＋１がＩＤＲフレームまたはＱｏＥに著しく影響を与え得るフレームを含まないことがあることを示すために、０の値を持ち得る。
１２４２において、ルータ１２０６は、ａビットの値に基づいてフローｋに対する状態を更新し得、したがって、Ｓｔａｔｅ＿ｋはＮＯ＿ＬＯＳＳの値を持ち得る。１２４４において、ルータ１２０６は、フローｋのパケットｎ＋ｍをビデオ受信機１２０８に送り得る。ａビットは、０の値を持ち得る。ｂビットは、ビデオ符号化適応が実行されたことを示すために、１の値を持ち得る。ｃビットは、パケットｎ＋ｍ＋１がＩＤＲフレームを含まないことがあることを示すために、０の値を持ち得る。
１２４６において、ビデオ送信機１２０２は、フローｋのパケットｎ＋ｍ＋Ｔをルータ１２０４に送り得る。パケットｎ＋ｍ＋１と同様に、ａビットおよびｃビットは、０の値を持ち得る。ビデオ符号化適応がパケットｎ＋ｍ＋Ｔに対して実行されていない可能性がある（例えば、ビデオ符号化適応が最近実行されていない可能性がある）ので、ｂビットも０の値を持ち得る。ｃビットは、重要なＰフレームを示すために使用され得る。
ノードは、事前構成された条件のセットに基づいて状態変数を更新するように構成されたプロセッサを備え得る。ノードは、事前構成された条件のセットから条件を選択し、選択された条件を事前構成された閾値と比較し、選択された条件が事前構成された閾値を超えるかどうかを決定し、選択された条件が事前構成された閾値を超えると決定すると、状態変数を更新するように構成されたプロセッサを備え得る。ノードは、事前構成された規則のセットにより第１のリアルタイムビデオトラフィックフローの第１のパケットを廃棄すると決定するように構成されたプロセッサを備え得る。
ノードは、ルータ、ＷＴＲＵ、および／またはｅＮＢであってよい。
図１３は、例示的なＩＰＰＰビデオ符号化構造のための後続のビデオフレームのチャネルひずみに対する、ビデオフレームを消失することの例示的な影響を示すグラフである。後続のビデオフレームのチャネルひずみに対するビデオフレームを消失することの影響は、初期チャネルひずみと、減衰の率すなわち時定数に依存し得る。初期チャネルひずみは、消失フレーム自体に対するものである。後続のビデオフレームのチャネルひずみに対するビデオフレームを消失することの影響が一定の閾値を超える場合、ルータ（例えば、ｅＮＢ、Ｗｉ−Ｆｉネットワークのアクセスポイント、コアインターネット内のルータ）は、１の値を持つようにｃビットを設定し得る。そうでない場合、ルータは、０の値を持つようにｃビットを設定し得る。
図１０に示される例示的なルータ構成がシミュレートされた。ルータは、例えば輻輳により、ある瞬間にｎパケットを廃棄し得る。ルータは、パケットロスをＰフレームのＲＴＣＰ遅延内のユーザまたはフローに限定してもよいし、パケットロスをユーザまたはフローに分散させてもよい。
図１４および図１５は、図１０のシミュレーションが実行された２つの例示的なビデオシーケンスに対するピーク信号対雑音比（ＰＳＮＲ）の例示的な累積分布関数（ＣＤＦ）を示す。
図１４および図１５に示されるように、ルータは、ある瞬間にｎ＝５のパケットを廃棄し、Ｎ＝５のフローが存在した。曲線１４０２および１４０２は、Ｐ＝３０フレームのＲＴＣＰ遅延内のユーザまたはフローにパケットロスを限定する例示的なシミュレートされた結果を示す。曲線１４０４および１４０４は、ユーザまたはフローにパケットロスを分散させた例示的なシミュレートされた結果を示す。
図１４および図１５に示されるように、パケットロスをＰフレームのＲＴＣＰ遅延内のユーザまたはフローに限定することは、パケットロスをユーザまたはフローに分散させることよりも優れた性能をもたらし得る。例えば、提案された方式に対する平均ＰＳＮＲ改善は、例えば図１４に示されるように、ビデオシーケンスに対して５ｄＢであり得るが、それは、例えば図１５に示されるように、ビデオシーケンスに対して２．３ｄＢであり得る。
本明細書で説明されるプロセスおよび手段は、任意の組み合わせで適用されてよく、他のワイヤレス技術に、および他のサービスに対して適用されてよい（例えば、近接サービスに制限されない）。
ノードは、第１のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいて第１のリアルタイムビデオトラフィックフローに関連付けられ得る。状態変数は、パケットロスを示し得る。ノードは、第２のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得、状態変数は、ノードにおいて第２のリアルタイムビデオトラフィックフローに関連付けられ、状態変数はパケットロスを示さない。ノードは、第１のリアルタイムビデオトラフィックフローのパケットまたは第２のリアルタイムビデオトラフィックフローのパケットを廃棄すると決定するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの状態変数を第２のリアルタイムビデオトラフィックフローの状態変数と比較するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの状態変数がパケットロスを示すことに基づいて第１のリアルタイムトラフィックフローのパケットを廃棄すると決定するように構成されたプロセッサを備え得る。ノードは、第１のリアルタイムビデオトラフィックフローの廃棄されたパケットをマーキングして、そのパケットが廃棄されたことを示すように構成されたプロセッサを備え得る。ノードは、ＷＴＲＵ、ルータ、ｅＮＢ、ネットワークエンティティ、またはユーザ機器を備え得る。
ＷＴＲＵは、例えば、物理デバイスの識別情報を参照するように構成され得る。ＷＴＲＵは、ユーザの識別情報を参照するように構成され得る。ユーザの識別情報は、ＭＳＩＳＤＮ、ＳＩＰ ＵＲＩなどの、加入に関連した識別情報を備え得る。ＷＴＲＵは、アプリケーションに基づいた識別情報を参照するように構成され得る。アプリケーションに基づいた識別情報は、アプリケーションごとに使用され得るユーザ名を備え得る。
ＷＴＲＵは、アクティブキュー管理（ＡＱＭ）アルゴリズムにロス集中を追加するように構成され得る。ＷＴＲＵは、ＡＱＭアルゴリズムの出力および／または判定を生じさせるように構成され得る。ＡＱＭアルゴリズムの出力および／または判定は、ロス集中の目的に対して評価され得る。ＷＴＲＵは、ロス集中の目的に対してＡＱＭの出力および／または判定を評価するように構成され得る。評価は、例えば、データパケットがいつバッファから廃棄され得るかに関する査定を含み得る。ＷＴＲＵは、データパケットがいつバッファから廃棄され得るかを査定するように構成され得る。
図１６は、アクティブキュー管理アルゴリズムにロス集中を追加することを示す例示的な流れ図である。図１６では、キュー１６１０は、複数のより小さなキュー（例えば、キュー１…キューＮ）からなり得る。各キューは、例えば、一定のサービス品質（ＱｏＳ）要件を有する特定のタイプのパケットをサービスし得る。例えば、キュー１６１０は、ワイヤレスネットワーク全体にわたって分散された１または複数のルータ内で実施され得る複数のキューを備える。アクティブキュー管理（ＡＱＭ）アルゴリズム１６２０は、キューの出力に結合され得る。ノードは、ＡＱＭをキューの出力に結合するように構成され得る。ノードは、ロス集中を、ＡＱＭアルゴリズム１６２０、キュー１６１０の出力、および／または１６３０／１６４０／１６５０／１６６０／１６７０／１６８０／１６９０の出力に結合するように構成され得る。ロス集中は、パケットｋが、優先度が下げられた（de-prioritized）ビデオフローに由来するかどうかを決定すること１６３０、キューメトリクスが所定の基準を超える（例えば、事前に設定された閾値を超える）かどうかを決定すること１６４０、状態変数を更新すること１６５０、発信パケットをマーキングすること１６６０、欠損値を増加／増分させること１６７０、欠損状況が所定の条件（例えば、あまりに長時間にわたるあまりにも大きい欠損）を満たすかどうかを決定すること１６８０、および／または将来の優先度が下げられるビデオフローからのパケットを廃棄すること１６９０のうちの１または複数の組み合わせを含み得る。
図１６では、ノードは、キューメトリクスをＡＱＭアルゴリズム１６２０に与えるように構成され得る。キューメトリクスは、キュー長、キューイング遅延などを備え得る。ＡＱＭアルゴリズム１６２０は、キューメトリクスを受信し得る。１６２０において、ノードは、ＡＱＭアルゴリズムを利用して、パケットｋを廃棄すると決めるように構成され得る。パケットｋが廃棄される場合、ノードは、１６３０において、パケットｋが、優先度が下げられたビデオフローから生じたかどうかを決定するように構成され得る。ノードが、パケットｋは、優先度が下げられたビデオフローから生じたと決定した場合、ノードは、パケットｋを廃棄するように構成され得る。ノードが、パケットｋは、優先度が下げられたビデオフローから生じなかったと決定した場合、ノードは、１６４０において、キューメトリクスがあまりにも不良であるかどうかを決定するように構成され得る。キューメトリクスが、事前設定された閾値に違反する場合、キューメトリクスは、あまりにも不良であることがある。１６４０において、ノードが、キューメトリクスがあまりにも不良であると決定した場合、ノードは、パケットｋを廃棄するように構成され得る。１６４０において、ノードが、キューメトリクスがあまりにも不良であると決定した場合、ノードは、１６５０において、状態変数を更新し得る。ノードが、１６４０において、キューメトリクスがあまりにも不良であると決定し、ノードが、１６５０において、状態変数を更新した場合、ノードは、１６６０において、発信パケットをマーキングし得る。１６４０において、ノードが、キューメトリクスがあまり不良でないと決定した場合、ノードは、１６７０において、欠損を増加させるように構成され得る。
ノードが欠損を増加させる場合、ノードは、１６８０において、欠損状況は事前設定された条件を満たすかどうかを決定するように構成され得る。事前設定された条件は、あまりに長時間にわたるあまりにも大きい欠損を含み得る。ノードが、欠損状況は事前設定された条件を満たすと決定した１６８０場合、ノードは、パケットｋを廃棄するように構成され得る。ノードが、欠損状況は事前設定された条件を満たすと決定した１６８０場合、ノードは、１６５０において、状態変数を更新し得る。ノードが、欠損状況は事前設定された条件を満たすと決定し１６８０、ノードが、１６５０において、状態変数を更新した場合、ノードは、１６６０において、発信パケットをマーキングし得る。ノードが、欠損状況は事前設定された条件を満たすと決定した１６８０場合、ノードは、規則のセットによりパケットを廃棄するように構成され得る。例えば、規則は、フローが優先度が下げられたかどうかに関係なく、キューに入るリアルタイムビデオパケットを廃棄するようにセットアップされ得る。ノードが、１６８０において、欠損状況が、事前設定された条件を満たさないと決定した場合、ノードは、１６９０において、将来の優先度が下げられるビデオフローからのパケットを廃棄するように構成され得る。欠損状況が所定の条件を満たさず、ノードが、優先度が下げられたリアルタイムビデオフローからの将来のパケットを廃棄することを決めた場合、欠損は、ゼロに近付けられ得る。
キュー１６１０は、１６５２において、新しいパケット到着をキューに与え得る。ノードは、１６５０において、キューへの新しいパケット到着のフロー変数を更新するように構成され得る。例えば、ノードは、ビット、すなわち新しく到着したパケット内で搬送されるビットａ、ビットｂ、ビットｃの値によってフロー変数を更新するように構成され得る。ノードは、１６６０において、キューへの新しいパケット到着の発信パケットをマーキングするように構成され得る。例えば、発信パケットは、フローは優先度が下げられたかどうかをダウンストリームルータに示すようにマーキングされ得る。ａビットは、フローは優先度が下げられたことをダウンストリームルータに示すために、１に設定され得る。
ノードは、複数のリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいて各リアルタイムビデオトラフィックフローに関連付けられ得る。各リアルタイムビデオトラフィックフローは、複数のパケットを備え得る。各パケットは、消失パケットインジケータを備え得る。ノードは、複数のリアルタイムビデオトラフィックフローのうちのリアルタイムビデオトラフィックフローの第１のパケットの消失パケットインジケータがパケットロスを示すと決定するように構成されたプロセッサを備え得る。ノードは、第１のパケットの消失パケットインジケータに基づいてノードにおいてリアルタイムビデオトラフィックフローに関連付けられた状態変数を、パケットロスを示すように更新するように構成されたプロセッサを備え得る。ノードは、リアルタイムビデオトラフィックフローに関連付けられた状態変数がパケットロスを示すことに基づいて後続のパケットロスをリアルタイムビデオトラフィックフローに向けるように構成されたプロセッサを備え得る。ノードは、第３のパケットがリフレッシュフレームを備えると決定するように構成されたプロセッサを備え得る。ノードは、第３のパケットがリフレッシュフレームを備えると決定したことに基づいて状態変数を更新するように構成されたプロセッサを備え得る。ノードは、第２のパケットの消失パケットインジケータがパケットロスを示さないと決定するように構成されたプロセッサを備え得る。
短期ロス集中および輻輳制御は、不公平性を処理するために利用され得る。短期ロス集中および輻輳制御を利用するように構成されたノードは、明示的輻輳通知（ＥＣＮ）によりリアルタイムビデオパケットまたはフローをマーキングすることによって、エンドツーエンド輻輳において公平性を提供し得る。そのようなＥＣＮ内の送信機は、符号化されたメディアストリームを搬送するＲＴＰパケットの送信機であってよい。送信機は、メディア送信がどのように実行され得るかを変更することが可能であり得る。例えば、送信機は、メディアコーディングまたはパケット化を変えることによって、メディア送信がどのように実行され得るかを変更することが可能であり得る。送信機は、ＥＣＮ制御ループの１つのエンドポイントであってよい。ＥＣＮ受信機は、メディアストリームを消費する意図を有するＲＴＰパケットの受信機と定義され得る。ＥＣＮ受信機は、受信されたストリーム上でＲＴＣＰフィードバックを送り得る。受信機は、ＥＣＮ制御ループの他のエンドポイントであってよい。パケットの送信機および受信機は、例えば、特定のルータ、ルータのグループ、１または複数の通信ネットワーク内に配設されたルータ、ノードなどであってよい。
ノードは、複数のＲＴＰパケットを備えるリアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいてリアルタイムビデオトラフィックフローに関連付けられ得る。ノードは、リアルタイムビデオトラフィックフローの第１のＲＴＰパケットのシーケンス番号を決定するように構成されたプロセッサを備え得る。ノードは、リアルタイムビデオトラフィックフローの第２のＲＴＰパケットのシーケンス番号を決定するように構成されたプロセッサを備え得る。ノードは、第１のＲＴＰパケットと第２のＲＴＰパケットとの間でシーケンス番号のギャップを検出するように構成されたプロセッサを備え得る。ノードは、ギャップの検出に基づいてリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように構成されたプロセッサを備え得る。ノードは、リアルタイムビデオトラフィックフローの送信機に報告を送るように構成されたプロセッサを備え得る。この報告は、リアルタイムビデオトラフィックフローの第１のＲＴＰパケットと第２のＲＴＰパケットとの間でのシーケンス番号のギャップを示し得る。
ノードは、パケットをマーキングするように構成され得る。ノードは、輻輳を緩和する目的で特定のデータフローの送信レートを減少または増加させることをパケットの送信機および受信機に通知するためにパケットをマーキングするように構成され得る。パケットの送信機および受信機は、特定のルータ、ルータのグループ、または通信ネットワーク内に設置されたルータ、ノードなどであってよい。ノードは、輻輳を緩和する目的で特定のデータフローの送信レートを一時的に減少または増加させるように送信機および／または受信機に命令を提供するためにパケットをマーキングするように構成され得る。ノードは、所定の時間範囲にわたって輻輳を緩和する目的で特定のデータフローの送信レートを減少または増加させるように送信機および／または受信機に命令を提供するためにパケットをマーキングするように構成され得る。
ルータが輻輳に遭遇すると、ルータは、１または複数のリアルタイムビデオフローからのパケットを廃棄し始めるように構成され得る。ルータは、他のリアルタイムビデオフローのＥＣＮビットをマーキングし得る。例えば、ルータは、パケットヘッダ内に明示的なインジケーション（例えば、ＩＰパケットヘッダのＤｉｆｆＳｅｒｖフィールドの最下位２ビットを１ １の値に）を設定し得る。受信側ルータは、ＥＣＮビットがマーキングされたことを示す展開されたインジケーションを有するパケット（例えば、ＤｉｆｆＳｅｒｖフィールドに１ １の値を有するＩＰパケット）を受信すると、ＥＣＮビットがマーキングされたことを示す明示的なインジケーションを有するパケットの送信機に応答し得る。例えば、受信側ルータは、ＥＣＮフィードバックパケットなどのリアルタイムトランスポートプロトコル（ＲＴＰ）制御プロトコル（ＲＴＣＰ）パケットを送信機に送信することによって送信機に応答するように構成され得る。ルータは、ＥＣＮフィードバック報告を作成するように構成され得る。ルータは、ＲＴＣＰパケットまたはＲＴＰ内の明示的なインジケーションに応答するなど、フィードバック遅延を減少させるようにフィードバックパケットを早期に送信するためにＥＣＮフィードバック報告を作成し得る。ルータは、ＲＴＣＰフィードバック（ＡＶＰＦ）トランスポートＥＣＮフィードバックパケットのための拡張されたオーディオビデオプロファイルなどに、フィードバック遅延を減少させるようにフィードバックパケットを早期に送信するために、ＥＣＮフィードバック報告を作成し得る。ＲＴＣＰフィードバック（ＡＶＰＦ）トランスポート層ＥＣＮフィードバックパケットは、フィードバック制御情報（ＦＣＩ）がＥＣＮフィードバック報告を含むことを示す８などの値の、フォーマット（ＦＭＴ）フィールド内のインジケーションであってよい。ルータは、送信機または受信機内でＥＣＮフィードバック報告を作成するコンピュータプログラム命令により、ＥＣＮフィードバック報告を作成し得る。コンピュータプログラム命令は、ルータの読み出し専用メモリまたはランダムアクセスメモリ内に有形に記憶されたプログラム命令を含み得る。ルータは、１または複数のトリガリングイベント時にコンピュータプログラム命令によりＥＣＮフィードバック報告を作成し得る。１または複数のトリガは、廃棄されるリアルタイムビデオフローの設定された閾値数を超えること、または具体的に識別された発信元から生じる具体的に識別されたビデオフローの廃棄を備え得る。
図１７は、通信ネットワーク内の送信機および受信機に送信され得る明示的輻輳通知（ＥＣＮ）フィードバック報告の例示的なフォーマットの図である。図１７に示されるように、ＥＣＮフィードバック報告フォーマットは、拡張された最高シーケンス番号（ＥＨＳＮ）フィールドと、ＥＣＮ対応トランスポート（ＥＣＴ） （０）カウンタフィールドと、ＥＣＴ （１）カウンタフィールドと、ＥＣＮ輻輳経験マーク（ＥＣＮ−ＣＥ）カウンタフィールドと、非ＥＣＴカウンタフィールドと、消失パケットカウンタフィールドと、重複カウンタフィールドとを備え得る。ＥＣＴは、送信機と受信機の両方がＥＣＮ対応ホストであるトランスポートフローであってよい。例えば、パケットは、送信時にＥＣＴ （０）またはＥＣＴ （１）とマーキングされたＥＣＮ対応トランスポートによって送られ得る。非ＥＣＴパケットは、ＥＣＮ対応トランスポートによって送られないことがあるパケットであってよい。非ＥＣＴパケットは、ＥＣＮ−ＣＥマーキングされないことがある。
ＥＨＳＮフィールドは、例えば、ルータによって受信される３２ビットの拡張された最高シーケンス番号であってよい（例えば、ＲＦＣ３５５５０によって定義される）。ＥＨＳＮは、報告が関連する最高ＲＴＰシーケンス番号を示し得る。
ＥＣＴ （０）カウンタフィールドは、例えば、同期元（ＳＳＲＣ）から受信されたＥＣＴ （０）を有するＲＴＰパケットの３２ビット累積番号であってよい。ＳＳＲＣは、ＲＴＰヘッダ内で搬送される３２ビット数値的ＳＳＲＣ識別子によって識別され得るＲＴＰパケットのストリームの発信元であってよい。ＳＳＲＣは、ネットワークアドレスに依存しない場合がある。ＥＣＴ （１）カウンタフィールドは、例えば、ＳＳＲＣからのＥＣＴ （１）を有するＲＴＰパケットの３２ビット累積番号であってよい。
ＥＣＮ−ＣＥカウンタフィールドは、例えば、ＥＣＮ−ＣＥマーキングされたＲＴＰセッションに受信機が参加した以降の、ＳＳＲＣから受信されたＲＴＰパケットの累積番号であってよい。ＥＣＮ−ＣＥカウンタフィールドは、任意の重複パケット内にＥＣＮ−ＣＥマークを含んでよい。例えば、受信機は、少なくとも３２ビットであるローカル表現を使用してカウンタフィールドを受信したＲＴＰパケットの累積番号値を追跡し得る。このローカル表現は、最小桁を有する１６ビットを含み得る。６５，５３５を超えるＥＣＮ−ＣＥマーキングされたパケットが受信された場合、ＥＣＮ−ＣＥカウンタフィールドは折り返してよい。
非ＥＣＴカウンタフィールドは、例えば、受信機がＲＴＰセッションに参加した以降の、非ＥＣＴのＥＣＮフィールド値を持った、ＳＳＲＣから受信されたＲＴＰパケットの累積番号であってよい。受信機は、ローカル表現を使用して受信したＲＴＰパケットの累積番号の値を追跡し得る。ローカル表現は少なくとも３２ビットであってよい。このローカル表現は、最小桁を有する１６ビットを含み得る。６５，５３５を超える非ＥＣＴパケットが受信された場合、非ＥＣＴカウンタフィールドは折り返してよい。
消失パケットカウンタフィールドは、受信機が受信すると予想したＲＴＰパケットの累積番号−受信機がＲＴＰセッションに参加した以降にこのＳＳＲＣからすでに受信したパケットの重複ではない、それが実際に受信したパケットの数であってよい。遅れて到着するパケットは、消失したとカウントされなくてよい。例えば、受信機は、少なくとも３２ビットであり、最小桁を有する１６ビットを含み得るローカル表現を使用して、この値を追跡し得、言い換えれば、消失パケットカウントフィールドは、６５，５３５を超えるパケットが消失した場合、折り返してよい。
重複カウンタフィールドは、ＳＳＲＣからすでに受信されたパケットの重複であり得る、受信されたＲＴＰパケットの累積番号であってよい。重複カウンタフィールドは、受信機がＲＴＰセッションに参加した以降にＳＳＲＣからすでに受信されたパケットの重複であり得る、受信されたＲＴＰパケットの累積番号であってよい。例えば、受信機は、ローカル表現を使用して重複カウンタフィールドの値を追跡し得る。ローカル表現は少なくとも３２ビットであってよい。このローカル表現は、最小桁を有する１６ビットを含み得る。６５，５３５を超える重複パケットが受信された場合、重複カウンタフィールドは折り返してよい。
ＥＣＮフィードバック報告内のＥＨＳＮフィールド、ＥＣＴ （０）カウンタフィールド、ＥＣＴ （１）カウンタフィールド、ＥＣＮ−ＣＥカウンタフィールド、非ＥＣＴカウンタフィールド、消失パケットカウンタフィールド、および重複カウンタフィールドは、ネットワークバイト順の符号なし整数であってよい。各ＥＣＮフィードバック報告は、単一のＲＴＰ発信元（例えば、ＳＳＲＣ）に対応し得る。ノードは、複合ＲＴＣＰパケット内に複数のＥＣＮフィードバック報告パケットを含めることによって複数の発信元を報告するように構成され得る。
カウンタは、後続の受信されたＳＳＲＣごとに０に始動される。カウンタは、特定の参加者からの初期報告時に、ＥＣＮ−ＣＥマーク、またはパケットロスの検出を可能にするように０に始動される。
ノードは、どのようにしてロス集中がＡＱＭアルゴリズムに追加され得るかの例であり得る、ロス集中に基づく制御された遅延（ＬＣ−Ｃｏｄｅｌ）を利用し得る。ルータは、例えば、ルータで遭遇される伝送制御プロトコル（ＴＣＰ）とリアルタイムビデオフローの混合物が存在するとき、ＬＣ−Ｃｏｄｅｌを利用するように構成され得る。ルータは、ＬＣ−Ｃｏｄｅｌを使用して、リアルタイムビデオフローと異なるようにＴＣＰフローを扱い得る。ＴＣＰフローの場合、ルータは、ＬＣ−Ｃｏｄｅｌを使用して、パケットを廃棄するかどうかを決定する際にデキューイングされるパケットの滞在時間を考慮し得る。ビデオフローの場合、ルータは、ＬＣ−Ｃｏｄｅｌを使用して、ビデオパケットに関連付けられたフローの優先度を考慮することなどによってロス集中を強制し得る。ビデオフローの場合、ルータは、ＬＣ−Ｃｏｄｅｌを使用して、パケットを廃棄する際にビデオフローにより作成されるキューイング遅延を考慮することなどによってロス集中を強制し得る。
ルータは、リアルタイム（ＲＴ）ビデオパケットを廃棄し得る。ルータは、エンキューイングの前および／またはデキューイングの後に、ＲＴビデオパケットを廃棄し得る。本明細書で説明される実施形態は、エンキューイングの前にビデオパケットが廃棄されるとき対処する例（例えば、例示的なアルゴリズム）を示し得る。本明細書で説明される実施形態（例えば、およびアルゴリズム）は、デキューイングの後でビデオパケットが廃棄されることになるとき対処するように拡張されてよい。
ルータは、ＬＣ−Ｃｏｄｅｌを使用して、単一のルータにおいて発生するおよび／または複数のルータにおいて発生する輻輳に対処し得る。ルータは、ＬＣ−Ｃｏｄｅｌを使用して、どのようにロスが特定のフローに限定されるかを処理して、ロス集中を強制し得る。ルータは、ＬＣ−Ｃｏｄｅｌを使用して、どのようにパケットが廃棄されるかを処理して、キューイング遅延を制御し得る。
ルータは、例えば、ルータが輻輳を経験するとき、フローまたはフローのサブセットの優先度を下げ得る。ルータは、優先度が下げられたフローからのパケットを廃棄し得る。ルータは、イントラフレームリフレッシュ（例えば、または他のビデオリフレッシュフレーム）を含むパケットが受信されるまで、優先度が下げられたフローからのパケットを廃棄し得る。ルータが、イントラフレームを含むパケットを受信するとき、ルータは、フローの優先度を下げるのを停止するように構成され得る。ルータは、フローの優先度が下げられるかどうかを決定するように構成され得る。ルータは、受信されたインターネットプロトコル（ＩＰ）パケットがイントラリフレッシュフレームを含むかどうかを決定するように構成され得る。
ルータは、例えば、フローの優先度が下げられるかどうかを決定するために、ビデオフローのための状態変数を維持し得る。ルータは、ルータを通過するビデオフローのための状態変数を維持し得る。例えば、ルータ状態［ｊ］∈｛優先度が下げられる、優先度が下げられない｝は、ビデオフローｊのための状態を示し得る。送信機および／またはビデオエンコーダは、例えば、受信されたインターネットプロトコル（ＩＰ）パケットがイントラリフレッシュフレームを含むかどうかを決定するために、ＩＰパケット内のビットを設定することによって状態変数情報を示し得る。ビットは、送信機およびルータによって相互に一致され得る。例えば、ビット（例えば、ビットｂ）は、ＩＰオプションフィールドの一部であってよい。例えば、ルータは、誤り伝播を停止するためにイントラフレームリフレッシュを含むパケットによってトリガされ得るので、ルータは、イントラフレームリフレッシュを備えるパケットを廃棄しないように構成され得る。
ルータは、いかなる瞬間においても１または複数のビデオフローの優先度が下げられ得る。いかなる瞬間においても１つのフローのみの優先度が下げられる場合、ルータは、ＬＣ−Ｃｏｄｅｌを利用するように構成され得る。例えば、ビデオフローが、優先度が下げられた状態であることがある。ルータがパケットを廃棄すると決める場合、および現在優先度が下げられたフローが存在しない場合、ルータは、優先度が下げられていない状態であるビデオフローからのパケットを廃棄するように構成され得る。ルータは、このパケットが属するフローの優先度を下げるように構成され得る。ルータが、より多くのパケットが廃棄されるべきであると決定する場合、ルータが、イントラフレームリフレッシュの一部であるパケットに遭遇するまで、ルータはフローからパケットを廃棄し得る。ルータは、ルータが、イントラフレームリフレッシュの一部であるパケットに遭遇すると、フローを優先度が下げられた状態に戻すように構成され得る。いかなる瞬間においてもフローのサブセットの優先度が下げられ得るとき、ルータは、同様にフローに優先度を付け、優先度を下げ得る。ルータは、標準的なＩＰ５タプルを使用して、受信されたＩＰビデオパケットの、フローとの関連付けを決定し得る。標準的なＩＰ５タプルは、発信元アドレスと、宛先アドレスと、発信元ポート番号と、送信先ポート番号と、プロトコル番号とを備え得る。
ルータは、ＬＣ−Ｃｏｄｅｌを利用して、キューイング遅延を制御し得る。リアルタイムビデオなどのビデオとＴＣＰフローの混合物が存在する場合、ルータは、ＬＣ−Ｃｏｄｅｌを利用して、キューイングを制御し得る。例えば、ルータは、ＬＣ−Ｃｏｄｅｌを利用して、デキューイングの後でＴＣＰパケットを廃棄し得る。ルータは、ＬＣ−Ｃｏｄｅｌを利用して、エンキューイングの前に１または複数のビデオパケットを廃棄し得る。ルータは、ＬＣ−Ｃｏｄｅｌを利用して、廃棄されると決定されたビデオパケットの数に関する「欠損」を増分し得る。ルータは、エンキューイングの前に「欠損」値に等しい、優先度が下げられたビデオフローに属するいくつかの着信パケットを廃棄するように構成され得る。欠損を使用してエンキューイングの前にパケットを廃棄することは、デキューイングの後にビデオパケットを廃棄することに適用され得る。
図１８は、ＬＣ−Ｃｏｄｅｌのデキューイング動作の例示的な流れ図である。図１８では、ルータは、１８０２において、ＬＣ−Ｃｏｄｅｌのデキューイングを利用し、欠損カウンタセットを初期値０に初期化するように構成される。ルータは、１８０４において、デキューイングされることになる次のパケットを受信するように構成され得る。ルータは、１８０６において、ＬＣ−Ｃｏｄｅｌを利用して、キュー内のパケット滞在時間（例えば、ＴＣＰデータパケット滞在時間）を算出するように構成され得る。この１８０６から算出された値に基づいて、ルータは、１８０８においてデータパケットを保持するのかそれとも廃棄するのかを決め得る。ルータがパケットを保持すると決定した場合、１８１０において、ルータはパケットを送信し得る。ビデオパケットに関しては、ルータは、パケットを廃棄するのではなく、パケットのための欠損カウントを増分するように構成され得る。欠損の量は、キューイング遅延を維持するように、パケットがバッファにエンキューイングされる前にビデオフローから廃棄され得るビデオパケットのバックログを示し得る。１８１２において、ルータが１８０８でパケットを廃棄すると決定した場合、ルータは、ＬＣ−Ｃｏｄｅｌを利用して、ビデオパケットがビデオフローに関連付けられるかどうかを決定し得る。パケットがビデオフローに関連付けられない場合、ルータは、１８１６においてパケットを廃棄してよい。パケットがビデオフローに関連付けられる場合、ルータは、１８１４において、パケットは廃棄されなくてよいと決定し得る。ルータが、パケットを廃棄しないと決定する場合、ルータは、１８１８において、欠損を１増分し得る。ルータは、１８２０において、パケットを送信し得る。
ルータは、差別化されたサービスコードポイント（ＤＳＣＰ）フィールドを検査することによって、ＩＰパケットがビデオフローに関連付けられるかどうかを決定するように構成され得る。ルータは、ディープパケットインスペクションによってＩＰパケットがビデオフローに関連付けられるかどうかを決定するように構成され得る。
図１９は、ＬＣ−Ｃｏｄｅｌのエンキューイング動作の例示的な流れ図である。図１９に示されるように、ルータは、１９０２において、優先度減少タイマー（ｄｐｔ＝０）および優先度減少持続時間（ｄｐ＿ｄｕｒａｔｉｏｎ＝ｘ、ここで、ｘは、例えば、５０ミリ秒よりも大きいもしくは小さい値および／または３００ミリ秒よりも大きいもしくは小さい値であってよい）開始値を用いてＬＣ−Ｃｏｄｅｌエンキューイングを初期化する。優先度減少持続時間は、新しいビデオフローの優先度を下げる間の持続時間を示す。優先度減少タイマーは、優先度減少持続時間に基づいて新しいビデオフローの優先度が下げられ得る瞬間を追跡し得る。優先度減少持続時間は、例えば、十分な時間が経過した後で欠損がゼロにならない場合、指数関数的に減少させ得る。
１９０４では、ルータは、次のパケットを受信し得る。ルータは、エンキューイング動作を使用して新しいパケットを調査し得る。エンキューイング動作は、１９０６において、パケットがビデオフローに関連付けられるかどうかを決定し得る。パケットがビデオフローに関連付けられないと決定したことに応答して、エンキューイング動作は、１９０８において、パケットをエンキューイングし得る。パケットがビデオフローに関連付けられる場合、１９１０において、パケットの欠損値が、０などの所定の値と比較される。検出された欠損値が所定の値よりも大きくない場合、エンキューイング動作は、１９１２において、パケットをエンキューイングする。検出された欠損値が所定の欠損値よりも大きい場合、エンキューイング動作は、１９１４において、優先度減少タイマーが経過したかどうかを決定する。
優先度減少タイマーが経過した場合、１９１６において、優先度減少タイマーが現在時刻値に設定されて、優先度減少持続時間値に追加され、１９１８において、現在時刻が優先度減少タイマーよりも小さいまたはそれに等しいかどうかを決定するために比較がなされる。現在時刻が優先度減少タイマーよりも大きいかそれに等しい場合、１９２０において、パケットが廃棄される。１９２０においてパケットが廃棄される場合、欠損＝欠損−１である。パケットが、優先度が下げられないフローに属すると決定された場合、フローの優先度が下げられ、１９２０において、優先度減少持続時間値が、以前に設定された優先度減少持続時間値が乗算される値（例えば、０．９＊ｄｐ＿ｄｕｒａｔｉｏｎ）に設定される。優先度減少タイマー値は、優先度減少タイマー値と優先度減少持続時間値の両方を含む値（例えば、ｄｐｔ＝：ｄｐｔ＋ｄｐ＿ｄｕｒａｔｉｏｎ）である。１９２８において、エンキューイング動作は、欠損がゼロに等しいかどうかを決定するために確認し得る。欠損値がゼロであると決定したことに応答して、１９３０において、優先度減少タイマーおよび優先度減少持続時間値がリセットされる。
現在時刻が優先度減少タイマーよりも小さい場合、エンキューイング動作は、１９２２において、パケットが、優先度が下げられるフローに関連付けられるかどうかを決定する。パケットが、優先度が下げられるフローに関連付けられない場合、１９２４において、パケットはエンキューイングされる。パケットが、優先度が下げられるフローに関連付けられる場合、１９２６において、パケットは廃棄され、欠損は欠損−１に等しいように設定される。１９２８において、エンキューイング動作は、欠損がゼロに等しいかどうかを決定するために確認し得る。欠損値がゼロであると決定したことに応答して、１９３０において、優先度減少タイマーおよび優先度減少持続時間値がリセットされる。
ビデオパケットは、輻輳サイクル中に欠損をヌルアウトするように、優先度が下げられたフローから廃棄され得る。デキューイング動作中に欠損が作成される可能性がある。ルータは、例えば、事前設定された持続時間が経過し、欠損がまだヌルアウトされていないとき、ますます積極的にビデオフローの優先度を下げるようにエンキューイング動作を構成し得る。例えば、ルータは、１つのビデオフローの優先度を下げて開始し得る。事前設定された持続時間欠損が依然として非ゼロである場合、ルータは、第２の新しいビデオフローの優先度を下げ、優先度が下げられるビデオフローの総数を２に等しくし得る。欠損が、延長された時間期間にわたってゼロよりも大きいままである場合、ルータは、追加ビデオフローの優先度が下げられ得る（例えば、より積極的な優先度減少）。ルータは、より多くのビデオフローの優先度を下げることによって、より迅速に欠損をゼロにするように構成され得る。より多くのビデオフローの優先度を下げることは、ビデオ品質に悪影響を与え得る。ルータは、輻輳制御（例えば、より多くのビデオフローの優先度を下げる）とビデオ品質のトレードオフをするようにエンキューイング動作を構成し得る。
図２０は、単一輻輳されたルータと二重輻輳されたルータの両方を含む、ビデオトラフィックおよびバックグラウンドＴＣＰトラフィックを有するダンベルネットワークトポロジにおいて用いられるＬＣ−Ｃｏｄｅｌの例の図である。ダンベルネットワークトポロジのネットワークシミュレータにおいてシミュレーションが実行され、結果が図２０に表示されている。図２０は、ＬＣ−Ｃｏｄｅｌの例示的な実施形態の性能を示す。
図２０には、５つのビデオ送信機（ビデオ送信機i、i=1,2,…5）２００２、２００４、２００６、２００８、２０１０がある。ビデオ送信機２００２、２００４、２００６、２００８、２０１０は、２つのルータ（ルータ1およびルータ2）２０２６、２０２８を通ってそれらのそれぞれの受信機（ビデオ受信機i、i=1,2,…5）２０１２、２０１４、２０１６、２０１８、２０２０まで至るビデオテレフォニートラフィックを送信するように構成され得る。２つのバックグラウンドＴＣＰフロー（クライアントi−サーバi、i=1,2,…5）２０３０から２０２０および２０３２から２０２４があり、１つが各ルータ２０２６、２０２８を越える。バックグラウンドＴＣＰフローは、ファイル転送プロトコル（ＦＴＰ）アップロードおよびダウンロードアプリケーションを実行し得る。図２０に示されるトポロジ内で接続されたリンクは、１４８．８１Ｍｂｐｓの容量を有するポイントツーポイントプロトコル（ＰＰＰ） ＳＯＮＥＴ ＯＣ３であってよい。ＴＣＰリンク（クライアントi−ルータi２０３０から２０２２、およびルータi−サーバi、i=1,2２０３２から２０２４）のためのリンク遅延は５ｍｓであり得、ルータ間リンク遅延（ルータ1−ルータ2）は５ｍｓであり得、（ビデオ送信機i−ルータ1、i=1,2,…5）および（ルータ2−ビデオ受信機j j=1,2,…5）およびリンクは１０ｍｓの遅延を持ち得る。パラメータ「ｘ」（例えば、「ｄｐ＿ｄｕｒａｔｉｏｎ」の初期化）は、１００ｍｓに設定され得る。パケット廃棄確率および遅延パラメータなどの残りのパラメータは、所定の値に設定されてよい。
ビデオ送信機は、３０ｆｐｓのレートでＩＰＰＰフォーマットとして符号化された１０秒持続時間のビデオシーケンスを送信し得る。ルータ1２０２６における単一のボトルネックシナリオでは、シミュレーション設定は、ルータ1２０２６およびルータ2２０２８のパケット処理レートはそれぞれ６×１０3パケット／秒および１０5パケット／秒であり、ルータ1２０２６を越える（クライアント1−サーバ1２０３０から２０２２）バックグラウンドＦＴＰアプリケーションは、４秒の持続時間にわたって、平均３３ｍｓで指数関数的に分布された要求間時間を用いて、平均５×１０5バイトの指数関数的に分布されたファイルサイズを有するファイルをアップロードおよびダウンロードし、ルータ2２０２８を越える（クライアント2−サーバ2２０３２から２０２４）ＦＴＰアプリケーションは、４秒の持続時間にわたって、平均３．４ｍｓで指数関数的に分布された要求間時間を用いて、平均２．５×１０3バイトの指数関数的に分布されたファイルサイズを有するファイルをダウンロードするように構成され得る。２回輻輳されたルータの場合、シミュレーション設定は、両方のルータのパケット処理レートは６×１０3パケット／秒であり、ルータ1およびルータ2を越えるバックグラウンドＦＴＰアプリケーションは、４秒の持続時間にわたって、平均３３ｍｓで指数関数的に分布された要求間時間を用いて、平均３．５×１０5バイトの指数関数的に分布されたファイルサイズでファイルをアップロードおよびダウンロードするように設定され得る。
ビデオフローの場合、ルータは、性能メトリックが現代のビデオテレフォニーシステムの挙動と一致するようにフリーズ時間のパーセンテージを選定し得るが、ルータは、ＴＣＰフローのためのスループットを選定し得る。ビデオ受信機におけるパケット配信の適時性は考慮に入れられてよい。ルータは、一定の再生遅延モデルを利用してよく、この再生遅延モデルは、時刻（ｔk＋ｈ）で表示のために受信機においてで利用可能なビデオフレーム＿ｋを規定し得、ここで、ｔkは、フレーム＿ｋの最後のパケットがビデオ送信機において送信された時刻を表し、ｈは再生遅延を表す。フレーム＿ｋのパケットは、フレームフリーズを回避するために、時刻（ｔk＋ｈ）の前に受信機に到着し得る。フレーム＿ｋに属するパケットが、（ｔk＋ｈ）の後、時刻
（ここで、ｄはビデオフレームレートの逆数である）の前に到着した場合、１つのフレームフリーズが発生し得る。パケットが、フレーム＿ｋを表示するために有用でないことがあるとき、１つのフリーズフレームが発生し得る。例えば、将来のフレームのパケットが時間とおりに到着するならば、パケットは、将来のフレームを復号するために有用であり得、パケットは、失われると考慮されなくてよい。フレーム＿ｋに属するパケットが、時刻
の後に到着する場合、パケットは失われると考慮されてよい。再生遅延ｈは、２６７ｍｓに設定され得る。
表１および表２はそれぞれ、単一輻輳されたルータの場合と二重輻輳されたルータの場合に、非常に輻輳したバックグラウンドＴＣＰトラフィックの存在下でビデオ送信機が「競走馬」ビデオシーケンスを送信するときの、ＬＣ−Ｃｏｄｅｌの例を含む差分キュー管理方式の性能の例を示す。ルータは、ＬＣ−Ｃｏｄｅｌを利用して、フリーズ持続時間のより短いパーセンテージを提供する点で、ビデオフローに向上された教育品質（ＱｏＥ）を提供し得、ＴＣＰフローに対して無視できるほどの影響を有する。
表１および表２に示されるように、遅延に結びつけられた違反により、後方廃棄方式においてパケットロスが発生し得る。パケットロスがルータで発生しないことがあり、これは、今日インターネットで観測される典型的な「バッファ膨張」シナリオであり得る。高いネットワーク負荷の下、後方廃棄は、結びつけられた時間内でかなりの割合のパケットを配信し損ねることがある。ＣｏｄｅｌおよびＬＣ−Ｃｏｄｅｌを利用するルータは、低いキューイング遅延を維持し、適時にパケットの配信を可能にするように、ルータにおけるパケットロスを経験し得る。Ｃｏｄｅｌと比較したＬＣ−Ｃｏｄｅｌの利益は、ＬＣ−Ｃｏｄｅｌはパケットロスを集中させることが可能であるが、Ｃｏｄｅｌはフローにパケットをランダムに廃棄させ、より多くのフリーズ発生を招くことによるものである。後方廃棄のパケットロス率は、Ｃｏｄｅｌよりもはるかに高いことがあるが、後方廃棄のフリーズ持続時間は、Ｃｏｄｅｌと悪い方に匹敵しないことがある。後方廃棄はパケットをバースト的に廃棄し得、これは、フリーズ持続時間を減少させる。後方廃棄とＬＣ−Ｃｏｄｅｌの差は、後方廃棄は、高遅延レジーム（regime）でバースト的パケット廃棄をするが、ＬＣ−Ｃｏｄｅｌは、主にビデオテレフォニーアプリケーションにとって興味のあるレジームである低遅延レジームでパケットロスを集中させることである。
図２１は、連続フレームフリーズの長さに関する条件付き分布の例の図である。フレームのパケットが（ｔk＋ｈ）の後、
の前に到着するとき、連続フレームの単一フレームフリーズが発生することがある。連続フレームの単一フレームフリーズが、より長い持続時間のフレームフリーズにつながることがある。連続フレームの単一フレームフリーズが、より長い持続時間のフレームフリーズにつながるパケットロス影響に類似していることがある。図２１は、単一フレームフリーズイベントの発生に関して条件付けされ得る後方廃棄のための表１の単一ルータ輻輳シナリオに関する連続フレームフリーズの長さに関する条件付き分布を示す。
表１および表２に示されるＬＣ−Ｃｏｄｅｌ結果は、高い輻輳に焦点を当てることがある。ＬＣ−Ｃｏｄｅｌは、他の輻輳レジームにおいてアクティブキュー管理を実行するように構成され得る。輻輳が減少するにつれて、輻輳の後方廃棄処理は、ワイヤレスネットワーク内でのトラフィックを改善し得る。輻輳の後方廃棄処理は、遅延に誘発されるパケットロスを減少させ、負荷を減少させ得る。表３および表４は、（ルータ１における）単一輻輳されたルータシナリオの場合のＬＣ−Ｃｏｄｅｌの性能の例を示し、表３の輻輳レベルは表４よりも高い。表３および表４のシミュレーション設定は、次のとおりである。ルータ1およびルータ2のパケット処理レートはそれぞれ、６×１０3パケット／秒および１０5パケット／秒であり、ルータ1を越える（クライアント1−サーバ1）バックグラウンドＦＴＰアプリケーションは、４秒の持続時間にわたって、平均３３ｍｓで指数関数的に分布された要求間時間を用いて、表３では平均３．５×１０3バイト（表４では２．７５×１０5バイト）の指数関数的に分布されたファイルサイズを有するファイルをアップロードおよびダウンロードし、ルータ2を越える（クライアント2−サーバ2）ＦＴＰアプリケーションは、４秒の持続時間にわたって、平均３．４ｍｓで指数関数的に分布された要求間時間を用いて、平均２．５×１０3バイトの指数関数的に分布されたファイルサイズを有するファイルをダウンロードする。
システムパラメータは、表１から表４において考慮に入れられ得る。システムパラメータは、目標遅延および／またはリアルタイムでビデオフレームを表示する際に受信機が許容できる最大遅延を示すために使用され得る再生遅延を備え得る。目標遅延は、キューイング遅延が値を超えた場合にパケットをマーキングするために使用され得る。再生遅延は、リアルタイムでビデオフレームを表示する際に受信機が許容できる最大遅延を示すために使用され得る。目標遅延は、再生遅延よりも小さくてよい。例えば、キューイング遅延が目標遅延よりも小さいとき、パケットロスが発生しないことがある。
ルータは、後方廃棄を利用するとき、Ｃｏｄｅｌ／ＬＣ−Ｃｏｄｅｌを利用するルータが経験するであろうパケットロスよりも大きな、遅延により誘発されたパケットロスを経験し得る。ルータは、後方廃棄を利用するとき、例えば、延長された期間にわたってキューイング遅延が再生遅延よりも大きいとき、より大きな、遅延により誘発されたパケットロスを経験し得る。ＬＣ−Ｃｏｄｅｌの性能は、他のものよりも著しく優れている場合がある。
例えば、キューイング遅延が目標遅延よりも大きく、キューイング遅延が再生遅延よりも小さいとき、Ｃｏｄｅｌ／ＬＣ−Ｃｏｄｅｌを利用するルータは、パケットロス（例えば、非ゼロフリーズ持続時間）を経験することがある。例えば、キューイング遅延が目標遅延よりも大きく、キューイング遅延が再生遅延よりも小さいとき、後方廃棄を利用するルータは、消失パケットを経験しないことがある。
ルータは、ＬＣ−Ｃｏｄｅｌを利用して、ロス集中を実施し得る。例えば、ルータは、命令を使用して、フローの優先度が下げられたかどうかを示す状態変数を維持し得る。例えば、ルータは、パケットロスを検出すると優先度を下げるよう状態を変更するように構成され得る。ルータは、ビデオフレームリフレッシュパケットがフローのためにルーティングされたというインジケーションを受信すると、状態変数を、優先度が下げられていない状態に戻すように構成され得る。ビデオフレームリフレッシュパケットは、ＩＰＰＰ構造、または階層型Ｐ内の時間層０などの階層型Ｐビデオコーディング構造を備え得る。例えば、ルータは、次のようにＬＣ−Ｃｏｄｅｌを実施し得る。
ルータ状態［ｉ］∈｛ＴＲＵＥ，ＦＡＬＳＥ｝は、ルータがフローｉのために維持する状態を示し得る。ビットＡ＝１は、パケットがＩフレームの一部であることを示すためにビデオ送信機によって設定されるビットを示し得る。
ルータは、複数のルータと通信するとき、ＬＣ−Ｃｏｄｅｌを利用し得る。例えば、ＬＣ−Ｃｏｄｅｌを使用するルータは、以下のアルゴリズムを使用して、他のルータに、フローの優先度が下げられたことを知らせ得る。
ビットＢは、パケットは優先度が下げられたフローに属することを示すようにルータによって設定されるビットを示し得、したがって、ダウンストリームルータは情報を認識させられ得、ルータ状態［ｉ］∈｛ＴＲＵＥ，ＦＡＬＳＥ｝は、ルータがフローｉのために維持する状態を示し得る。
ルータのＬＣ−Ｃｏｄｅｌの利用は、典型的なワイヤレスネットワーク内でのリアルタイムビデオトラフィックの処理を観測するために、ＯＰＮＥＴなどのネットワークシミュレータにおいてシミュレートされ得る。シミュレータは、リアルタイムビデオ送信をシミュレートするために使用され得る。ビデオシーケンスは、ＩＰＰＰＰ構造を有してよい。ビデオシーケンスが他のビデオフォーマットに対して実施されることを可能にする他の構成も可能である。
ビデオ送信機は、フレーム０から始まってシーケンスの終了までパケットを順次送信し得る。ビデオ受信機は、（例えば、消失パケットに関する）リアルタイムトランスポートプロトコル制御プロトコル（ＲＴＣＰ）フィードバックをビデオ送信機に送り得る。受信機からＲＴＣＰフィードバックを受信すると、ビデオ送信機は、その送信シーケンス内の次のフレームから瞬時デコーダリフレッシュ（ＩＤＲ）を挿入し、その送信を継続し得る。
図２２は、ＬＣ−Ｃｏｄｅｌを利用するネットワークシミュレータにおけるリアルタイムビデオの例の図である。図２２では、Ｆｘは、フレームｘから始まりシーケンスの終了まで符号化され得るビデオを示し得る。例えば、Ｆ０ ２２０２は、Ｉフレームであるフレーム０から始まる完全なビデオシーケンスのために符号化されたビデオを示し得、残りのフレームはＰフレームを備える。Ｆ １０ ２２０６は、フレーム１０から始まりシーケンスの終了まで符号化されたビデオシーケンスを示し得、フレーム１０はＩフレームであり、残りのフレームはＰフレームを備える。Ｆｘ値は、事前に符号化されてもよいし、単一の操作において前もって算出されてもよい。フレームおよび／またはパケットのサイズは、さまざまな所定の時間間隔で分析されてよい。
図２２では、ビデオシーケンスＦ０が送信され得る。ビデオシーケンスのフレーム９において、Ｆ０ ＲＴＣＰが受信され得る。ビデオシーケンスＦ０は、フレーム９まで送信を終えないことがある。フレーム１０以降、ビデオシーケンスＦ１０ ２２０６に対して切り換えがなされ得る。Ｆ１０ ２２０６内の第１のフレーム（例えば、フレーム＃１０）はＩフレームであってよく、残りのフレームはＰフレームであってよい。ビデオシーケンスＦ０からビデオシーケンスＦ１０への切り換えは、ビデオ送信機がＲＴＣＰを受信したとき、Ｉフレームの挿入を引き起こし得る。複雑さ（例えば、事前に符号化されたビデオシーケンスの格納、所望の事前に符号化されたビデオシーケンスの調査）は、フレームの数に対して線形であり得る。パケットおよび可能なフレームシーケンス（図２２のＦｎ、ｎ∈Ｎ）のサイズのメモリ内での格納は可能であり得る。ＲＴＣＰフィードバックが受信されたとき、シーケンスは切り替えられ得る。
ルータは、制御された遅延アクティブキュー管理（Ｃｏｄｅｌ）アルゴリズムを用いて、ロス集中を実現し得る。ルータは、Ｃｏｄｅｌアルゴリズムを利用して、１または複数のＡＱＭアルゴリズムにおける「パラメータチューニング」を処理し得る。ルータは、Ｃｏｄｅｌアルゴリズムを利用して、ビデオパケット廃棄を制御する可能性が、ロス集中を実現することを可能にし得る。後方廃棄（ＤＴ）アルゴリズムおよびランダム初期検出（ＲＥＤ）アルゴリズムなどのいくつかのＡＱＭアルゴリズムは、ロス集中の実現に関してＣｏｄｅｌほど良好でないことがある。ルータは、ＲＥＤアルゴリズムのパラメータを構成するのに困難を経験することがある。ルータは、ＤＴアルゴリズムを利用するとき、例えば、ルータに無制限サイズバッファが与えられるとき、キューイング遅延を制御するのに困難を経験することがある。ルータは、ＤＴを利用するとき、輻輳が発生すると、フローの１または複数のサブセットからパケットを廃棄するのに苦労することがある。
図２３は、後方廃棄（ＤＴ）アルゴリズムを使用してロス集中の特徴付けを近似するように構成された例示的なキューの図である。図２３に示されるように、ルータバッファは、１または複数の閾値、例えばロス集中閾値（ＬＴ）および仮想後方廃棄閾値（ＶＴ）を持ち得る。ＶＴは、所定の仮想閾値（例えば、実際のバッファサイズの９５％または何らかの他の所定のパーセンテージ）を表してよい。ＬＴ（例えば、実際のバッファサイズの９０％または何らかの他の所定のパーセンテージ）は、ロス集中をトリガする所定の閾値を示し得る。図２３に示されるように、着信パケット２３０２は、バッファ内にエンキューイングされるように置かれ得る。Ｑ２３０４はキュー長を表すことができ、このキュー長は、例えば、じきにエンキューイングされることになっている着信パケットを考慮に入れてよい。
ＤＴを利用してロス集中を強制するルータは、例えば、Ｑ＞ＬＴならば、それが、優先度が下げられたビデオフローに属する場合、ルータが着信パケットを廃棄し得ることを提供するように構成され得る。ＤＴを利用してロス集中を強制するルータは、例えば、Ｑ＞ＬＴならば、着信パケットが非ビデオフローまたは優先度が下げられていないビデオフローに属する場合、ルータが着信パケットを廃棄しなくてよいことを提供するように構成され得る。ルータは、キュー長が仮想閾値に到達する前に優先度が下げられたビデオフローからのパケットを廃棄し始めることによって、ロス集中がトリガされるように構成され得る。
ＤＴを利用してロス集中を強制するルータは、例えば、Ｑ＞ＶＴならば、それが非ビデオフローに属する場合または着信パケットが、優先度が下げられたビデオフローに属する場合、ルータが着信パケットを廃棄し得ることを提供するように構成され得る。ＤＴを利用してロス集中を強制するルータは、例えば、Ｑ＞ＶＴならば、着信パケットが、優先度が下げられていないビデオフローに属する場合、または着信パケットがＲＴＣＰパケットである場合、ルータが廃棄しなくてよいことを提供するように構成され得る。ルータは、優先度が下げられたビデオフローからのパケットを廃棄し、優先度が下げられていないビデオフローからのパケットを廃棄しないことによって、ロス集中が強制されるように構成され得る。ルータは、通常のやり方で非ビデオパケットを扱うように構成され得る。ルータは、ビデオ送信機がロス情報を得ることを確実にするために、ＲＴＣＰパケットを廃棄しないように構成され得る。
ＤＴを用いるルータは、Ｑ＞ＬＴなどのとき、ルータが非ビデオパケットを廃棄し得るよりも早く、優先度が下げられたフローに属するビデオパケットを廃棄し得る。Ｑ＞ＶＴのとき、ルータは、優先度が下げられていないビデオフローに対して奨励（incentivize）し得る。
図２４は、ＤＴのピーク信号対雑音比（ＰＳＮＲ）のＣＤＦの例のグラフである。図２４では、ＤＴは、Ｑ＞ＶＴならばパケットが廃棄され、ロス集中が強制される仮想ＤＴ（例えば、後方廃棄）であってよい。図２４では、平均ＰＳＮＲ利得は０．８ｄＢであってよい。
ルータ、ルータのグループ、またはインターネットなどのルータのネットワークは、ロス集中の部分的実装を利用してよい。例えば、リアルタイムビデオアプリケーションのパス上のルータ（例えば、すべてのルータ）にロス集中を新しい特徴として追加することが可能でない場合がある。例えば、いくつかのルータは、ビット（例えば、ビットａ、ｂ、ｃ）を搬送するために使用されるＩＰオプションフィールドの使用をサポートしないことがあり、ＩＰオプションフィールドを使用するパケットを廃棄することがある。ビットを使用するように構成されない１または複数のルータは、ワイヤレスネットワーク内のルータの間での協調をより困難なものにすることがある。
例えば、１または複数のルータは、協調なしで（例えば、ａ、ｂ、ｃなどのビットを使用しない）ロス集中を個々に強制することがある。ルータ間での協調の欠如は、より少ない性能利得につながることがある。ビットを使用するように構成されない１または複数のルータは、図１６に示されるように、１６５２において新しいパケットが到着したときに状態変数を更新することに類似してよい。例えば、アップストリーム情報は、新しいパケットがビットａ、ｂ、およびｃなどのビットを搬送しないとき、図１６のルータ間で通信に追加されないことがある。ルータは、１６６０において発信パケットをマーキングするために状態変数を用いないことがある。
ノードは、リアルタイムビデオトラフィックフローを受信するように構成されたプロセッサを備え得る。状態変数は、ノードにおいてリアルタイムビデオトラフィックフローに関連付けられ得る。状態変数は、ノードにおけるリアルタイムビデオトラフィックフローのためのロス状態を示し得る。ノードは、リアルタイムビデオトラフィックフローのラウンドトリップタイム（ＲＴＴ）を決定するように構成されたプロセッサを備え得る。ノードは、ＲＴＴに基づいてロス状態がないことを示すようにリアルタイムビデオトラフィックフローに関連付けられた状態変数を変更するように構成されたプロセッサを備え得る。ＲＴＴは、所定の値であってよい。ＲＴＴは、リアルタイムビデオトラフィックフローの発信元と送信先との間の伝送制御プロトコル（ＴＣＰ）接続に基づいて推定され得る。ＲＴＴは、キューイング遅延を使用してＲＴＴの下限を作ることによって決定され得る。
ビデオ送信機および他のルータからの協調がない場合に、ルータは、フローのステータス（例えば、ａビット、ｂビット、および／またはｃビット）を示すルータ間で交換されるシグナリングの使用なしにロス集中を実施し得る。例えば、ルータは、ＩＰまたは他のヘッダ内で明示的シグナリングを受信することなくトラフィックフローの観測に基づいてロスからロスなしにフローの状態（例えば、Ｓｔａｔｅ＿ｋ）を遷移させるように構成され得る。例えば、ルータは、どのくらい長さのフローがロスの状態であるべきかを知らないことがある。ルータは、フローのラウンドトリップタイム（ＲＴＴ）を推定するように構成され得る。ルータがリアルタイムビデオフローの発信元と送信先との間のＴＣＰ接続を識別することができる場合、ルータは、ＴＣＰ ＲＴＴの受動的推測を利用して、リアルタイムトラフィックフローのＲＴＴを推定し得る。ルータは、ＲＴＴを使用して、所与のフローが所与の状態（例えば、優先される、優先度が下げられるなど）のままであってよい時間の量を決定し得る。例えば、ルータがＲＴＴを推測することができないとき、および／または現在の推測値が利用可能でない場合、ルータは、所定の一定値（例えば、１００ｍｓ）を用いるように構成されてよく、この一定値は、インターネット上で見られる平均ＲＴＴに近くてよい。
ルータは、ローカルに観測されるキューイング遅延を使用して、ＲＴＴの下限を作り得る。ルータは、この下限を使用して、ＲＴＴの正確な値を用いれば可能であろう利得の一部をもたらし得る。ルータは、記憶媒体内に有形に記憶されたコンピュータ命令を利用および実行して、ＲＴＴの値を推測し得る。
ルータは、トラフィック特性を分析することによってリアルタイムビデオトラフィックを推測するように構成され得る。ルータは、トラフィック特性の分析から得られた情報を使用するように構成され得る。ルータは、暗号化されていない利用可能な情報を使用するように構成され得る。例えば、暗号化が、セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）プロファイルなどのメディアペイロードに対して可能であり、ルータによって受信されたパケットの残りの部分に対しては可能でない場合、ルータは、メディアがリアルタイムビデオであるかどうかを容易に知り得る。ルータは、暗号化されたメディアがリアルタイムビデオであると決定し得る。例えば、ＳＲＴＰの場合、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットヘッダは暗号化されないので、ルータは、暗号化されたメディアがリアルタイムビデオであると決定し得る。同じパケット内で搬送されるペイロードタイプ（ＦＴ）フィールドは、どの種類のメディアがＲＴＰパケットによって搬送されるかを示し得る。ルータは、ＲＴＰパケットによって搬送されるメディアを決定するためにパケット内で搬送されるＰＴフィールドを読み取るように構成され得る。ルータは、例えば、それがリアルタイムビデオである可能性が高くなり得るので、メディアタイプがビデオを示す場合、ロス集中を適用するように構成され得る。
ルータは、例えば、トランスポート層セキュリティ（ＴＬＳ）を使用するなど、暗号化がＲＴＰパケット全体に対して行われる場合、暗号化されたＲＴＰパケットを調べて、パケットがリアルタイムビデオトラフィックを搬送するかどうかを決定することができない場合がある。ルータは、使用されているプロトコルについての情報を有するトラフィックパターンを分析し得る。例えば、ＵＤＰパケットがオーディオおよび／またはリアルタイムビデオを搬送する場合、ルータは、ＩＰパケットを識別するように構成され得、プロトコルフィールドはＵＤＰとして示され、ペイロードが暗号化される。プロトコルフィールドは、使用されているトランスポートプロトコルのタイプを示し得る。ＵＤＰパケット間で、ルータは、約２０ミリ秒間隔でパケットからなるフローを識別するように構成され得る。ルータは、フローはオーディオフローである可能性が最も高いと推測するように構成され得る。ルータは、残りのフローがリアルタイムフローである可能性が最も高いと推測するように構成され得る。ルータは、どのフローがオーディオフローであるか、およびどのフローがリアルタイムビデオフローであるかを識別し得る。ルータは、例えば、識別されたリアルタイムビデオフローに対してロス集中に基づくＡＱＭを適用するように構成され得る。ＵＤＰパケットは、リアルタイムゲーム、リモートプロシージャコール、ドメイン名サービストラフィックなどの他のタイプのトラフィックを搬送し得る。ルータを構成または適合させることは、例えば、リアルタイムゲーム、リモートプロシージャコール、ドメイン名サービスの特性などに起因するアプリケーション固有トラフィック特性を反映する追加パラメータを考慮に入れることがある。
ビットの数は、さまざまなパケットヘッダ、さまざまなパケットヘッダ内の拡張フィールド、ラベル、または情報要素（ＩＥ）内で画定され得る。定義されるビットの数は、さまざまなパケットヘッダ内、さまざまなパケットヘッダ内の拡張フィールド、ラベル、またはＩＥ内で利用可能なビット空間に依存し得る。ビット（例えば、ビットａ、ｂ、ｃ）は、ＩＰパケット以外のパケット内で搬送され得る。ビットａ、ｂ、ｃは、例えば、ＩＰパケットのオプションフィールドを使用することによって、ＩＰパケット内で搬送され得る。ルータは、オプションフィールドの使用をサポートしないことがある。ルータは、オプションフィールドを使用してＩＰパケットを廃棄し得る。ルータは、変更されたまたは拡張されたパケットＩＰヘッダ、別のタイプのパケットヘッダ、ラベル、またはＩＥ内でビットを読み出すように構成され得る。
例えば、１または複数のルータは、ＲＴＰパケットヘッダ拡張部を使用してＲＴＰパケットヘッダを読み出すように構成され得る。ＲＴＰパケットヘッダ拡張部を使用してＲＴＰパケットヘッダを読み出すように構成されたルータは、ＩＰパケットを廃棄しないことがある。ロス集中を可能にするために、リアルタイムビデオフローのパス上の１または複数の所定のルータが変更され得る。例えば、基地局またはノード（例えば、ｅｖｏｌｖｅｄノードＢ、リモートラジオヘッド、フェムトｅＮＢ、ピコｅＮＢ、中継局、またはＷｉＦｉもしくはＷｉＭａｘワイヤレス通信ネットワーク内のアクセスポイントなど）は、ＲＴＰパケットヘッダを調べてＲＴＰパケットヘッダ拡張部内で見つけられたビットを読み出す、得る、または変更するようにルータとして構成され得る。
ルータは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）パケットヘッダ（またはラベル）内で搬送されるビット（例えば、ビットａ、ｂ、ｃ）を読み出すように構成され得る。
図２５は、ビット（例えば、ビットａ、ｂ、ｃ）を搬送するように構成されたＭＰＬＳラベルの例の図である。図２５に示されるように、ビット２０ ２５０２、２１ ２５０４、および２２ ２５０６は、経験的とマーキングされ、ビットａ、ｂ、ｃなどの３つのビットを搬送するために使用され得る。
ルータは、初期パケットロスを引き起こしたパケットロス以外のパケットロスを検出し得る。ルータは、ビット（例えば、ビットａ）を使用して、パケットロスがリアルタイムビデオフローに対して発生し、例えば、次いで、ダウンストリームルータにおいて優先度が下げられ得ることをダウンストリームルータに知らせるように構成され得る。ダウンストリームルータは、ビットを有する明示的シグナリングを使用するように構成されないことがある。ダウンストリームルータは、アップストリームルータからの明示的シグナリング（例えば、ビットａ）に頼らずにフローがパケットロスを経験したと推論し得る。例えば、ダウンストリームルータは、ＲＴＰパケットのシーケンス番号を検査し得る。ルータがギャップを検出する（例えば、「開ループ」）場合、ルータは、ＲＴＰパケットが属するフローがパケットロスを被ったと結論し得る。ルータは、そのフローの優先度がまだ下げられていない場合、パケットロスを経験したフローの優先度を下げ得る。
図２６は、ダウンストリームルータによる開ループシナリオの検出の例の図である。図２６に示されるように、ルータＡ２６０２は、ロス集中に対応していないことがある。ルータＡ２６０２はパケット３ ２６１４を廃棄し、パケット３ ２６１４はビデオパケットフロー（例えば、パケット１ ２６１８、２ ２６１６、４ ２６１２、および５ ２６１０をさらに備えるビデオパケットフロー）の一部である。ダウンストリームルータであるルータＣ２６０６は、シーケンス番号のギャップを検出し得る。ルータＣ２６０６は、パケットロスがそのビデオパケットフローに対して発生したと決定し得る。ルータＣ２６０６は、何らかの時間、例えばＲＴＴの間、そのビデオパケットフローの優先度を下げることによってパケットロスに応答するように構成され得る。ルータＣ２６０６は、明示的シグナリング（例えば、ビットａ、ｂ、ｃを使用する）が可能であり得る。ルータＣ２６０６は明示的シグナリングが可能な場合、ルータＣ２６０６は、ビデオフローのシーケンス番号内でギャップを検出したことに応答して、ビデオフローの１または複数のパケット上の１または複数のシグナリングビットを設定し得る（例えば、「ａ＝１」を設定し得る）。ロス集中に対応していないルータ（例えば、ルータＡ２６０２）は、ロス集中対応であるルータ（例えば、ルータＣ２６０６）と優雅にインターワーキングしてよく、ロス集中対応ルータは、ロス集中関連パラメータの明示的シグナリングが可能であってもなくてもよい。
ルータは、ロス集中および輻輳制御を利用して、エンドツーエンド輻輳における過度の不公平性を短期的に処理し得る。ルータは、ロス集中および輻輳制御を利用して、パケットロスをフローのサブセットに集中させ得る。ロス集中は、（例えば、ラウンドトリップ遅延時間（ＲＴＤ）またはラウンドトリップタイム（ＲＴＴ）に対する影響に関して）長期的に公平と特徴付けられ得るが、その影響は、短期的にエンドツーエンド輻輳における不公平性をもたらすことがある。例えば、ルータは、パケットロスを観測することによって送信機がネットワーク輻輳を推測し得るいくつかのリアルタイムビデオアプリケーション（例えば、ＷｅｂＲＴＣ）において、エンドツーエンド輻輳制御を実施し得る。その結果、パケットが廃棄されるユーザは、彼らの送信レートを減少させ続けるが、パケットが廃棄されない他のユーザは、彼らの送信レートを減少させず、輻輳制御を実行する際に短期的に過度の不公平性をもたらすであろう。
上記で説明されたプロセスは、コンピュータおよび／またはプロセッサによる実行のためにコンピュータ可読媒体内に組み込まれたコンピュータプログラム、ソフトウェア、および／またはファームウェアにおいて実施されてよい。コンピュータ可読媒体の例は、限定するものではないが、電子信号（有線接続および／またはワイヤレス接続を経由して送信される）および／またはコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、限定するものではないが、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、限定するものではないが内部ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびに／またはＣＤ−ＲＯＭディスクおよび／もしくはデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ソフトウェアと関連するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、および／または任意のホストコンピュータにおいて使用する無線周波数トランシーバを実行するために使用されてよい。

Claims (28)

  1. プロセッサを備えたノードであって、前記プロセッサは、
    第１のリアルタイムビデオトラフィックフローを受信し、状態変数は前記ノードにおいて前記第１のリアルタイムビデオトラフィックフローに関連付けられ、および前記第１のリアルタイムビデオトラフィックフローは複数のパケットを含み、および各パケットは消失パケットインジケータを含み、
    第２のリアルタイムビデオトラフィックフローを受信し、状態変数は前記ノードにおいて前記第２のリアルタイムビデオトラフィックフローに関連付けられ、および前記第２のリアルタイムビデオトラフィックフローは複数のパケットを含み、および各パケットは消失パケットインジケータを含み、
    前記第１のリアルタイムビデオトラフィックフロー内の第１のパケットを廃棄し、
    前記廃棄したパケットを示すために、前記ノードにおいて前記第１のリアルタイムビデオトラフィックフローに関連付けられた前記状態変数を更新し、
    前記状態変数に基づいて、前記第１のリアルタイムビデオトラフィックフロー内の第２のパケットに対する前記消失パケットインジケータを更新する
    ように少なくとも一部において構成されたことを特徴とするノード。
  2. 前記プロセッサは、
    前記第１のリアルタイムビデオトラフィックフローの前記状態変数を、前記第２のリアルタイムビデオトラフィックフローの前記状態変数と比較し、前記第２のリアルタイムビデオトラフィックフローの前記状態変数は、廃棄したパケットを示さず、
    前記廃棄したパケットを示している前記第１のリアルタイムビデオトラフィックフローの前記状態変数に基づいて、前記第１のリアルタイムビデオトラフィックフローのパケットを廃棄することを決定する
    ように構成されたことを特徴とする請求項１に記載のノード。
  3. 前記プロセッサは、
    前記第１のリアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを含むことを決定し、
    前記第１のリアルタイムビデオトラフィックフローの前記第３のパケットがリフレッシュフレームを含むという決定に基づいて、前記ノードにおいて前記第１のリアルタイムビデオトラフィックフローに関連付けられた前記状態変数を更新し、
    前記第１のリアルタイムビデオトラフィックフローの前記第３のパケットがリフレッシュフレームを含むという決定に基づいて、前記第１のリアルタイムビデオトラフィックフローの前記第３のパケットに対する前記消失パケットインジケータを更新する
    ように構成されたことを特徴とする請求項１に記載のノード。
  4. 前記第１のリアルタイムビデオトラフィックフローの前記第３のパケットがリフレッシュフレームを含むと決定するように構成された前記プロセッサは、
    前記第３のパケットのパケットヘッダ内のビットが、前記第３のパケットはリフレッシュフレームを含むということを示すと解釈し、および
    前記第１のリアルタイムビデオトラフィックフローの前記第３のパケットがリフレッシュフレームを含むことを決定する
    ように構成された前記プロセッサを含むことを特徴とする請求項３に記載のノード。
  5. 前記リフレッシュフレームは、部分的リフレッシュフレームを含むことを特徴とする請求項３に記載のノード。
  6. 前記第３のパケットはＩフレームを含むことを特徴とする請求項３に記載のノード。
  7. 前記プロセッサは、
    前記第１のリアルタイムビデオトラフィックフローの前記第２のパケットを第２のノードに送るように構成され、前記消失パケットインジケータは、前記第２のノードに、前記第２のノードにおいて前記第１のリアルタイムビデオトラフィックフローに関連付けられた状態変数を更新するように指示することを特徴とする請求項１に記載のノード。
  8. 前記状態変数は前記ノードによって使用され、パケットロスを、劣化したパケットストリーム上に集中させることを特徴とする請求項１に記載のノード。
  9. フロー優先度インジケータ（ＦＰＩ）は、前記消失パケットインジケータを含むことを特徴とする請求項１に記載のノード。
  10. 前記状態変数に基づいて、前記第１のリアルタイムビデオトラフィックフロー内の第２のパケットに対する前記消失パケットインジケータを更新することは、
    前記第２のパケットはリフレッシュフレームを含まないことを決定し、ならびに
    前記状態変数、および前記第２のパケットがリフレッシュフレームを含まないという決定に基づいて、前記第１のリアルタイムビデオトラフィックフロー内の前記第２のパケットに対する前記消失パケットインジケータを更新する
    ことを含むことを特徴とする請求項１に記載のノード。
  11. 前記消失パケットインジケータは、前記パケットのパケットヘッダ内のビットを含むことを特徴とする請求項１に記載のノード。
  12. 前記プロセッサは、事前構成した条件のセットに基づいて前記状態変数を更新するように構成したことを特徴とする請求項１に記載のノード。
  13. 前記プロセッサは、
    前記事前構成した条件のセットから条件を選択し、
    前記選択した条件を事前構成した閾値と比較し、
    前記選択した条件が前記事前構成した閾値を超えるかどうかを決定し、および
    前記選択した条件が前記事前構成した閾値を超えると決定すると、前記状態変数を更新する
    ように構成されたことを特徴とする請求項１２に記載のノード。
  14. 前記ノードは、ルータ、無線送受信ユニット（ＷＴＲＵ）、またはｅｖｏｌｖｅｄノードＢ（ｅＮＢ）であることを特徴とする請求項１に記載のノード。
  15. 前記プロセッサは、事前構成した規則のセットにしたがって、前記第１のリアルタイムビデオトラフィックフローの前記第２のパケットを廃棄することを決定するように構成されたことを特徴とする請求項１に記載のノード。
  16. プロセッサを備えたノードであって、前記プロセッサは、
    第１のリアルタイムビデオトラフィックフローを受信し、状態変数は前記ノードにおいて前記第１のリアルタイムビデオトラフィックフローに関連付けられ、前記状態変数はパケットロスを示し、
    第２のリアルタイムビデオトラフィックフローを受信し、状態変数は前記ノードにおいて前記第２のリアルタイムビデオトラフィックフローに関連付けられ、前記状態変数はパケットロスがないことを示し、
    前記第１のリアルタイムビデオトラフィックフローの前記状態変数を、前記第２のリアルタイムビデオトラフィックフローの前記状態変数と比較し、
    パケットロスを示している前記第１のリアルタイムビデオトラフィックフローの前記状態変数に基づいて、前記第１のリアルタイムビデオトラフィックフローのパケットを廃棄することを決定する
    ように少なくとも一部において構成されたことを特徴とするノード。
  17. 前記プロセッサは、リアルタイムビデオトラフィックフローのパケットを廃棄すると決定すると、前記第１のリアルタイムビデオトラフィックフローの前記状態変数を、前記第２のリアルタイムビデオトラフィックフローの前記状態変数と比較するように構成されたことを特徴とする請求項１６に記載のノード。
  18. 前記プロセッサは、前記第１のリアルタイムビデオトラフィックフロー内の前記廃棄したパケットに続くパケットを、前記パケットが廃棄されたことを示すようにマーキングするように構成されたことを特徴とする請求項１６に記載のノード。
  19. プロセッサを備えたノードであって、前記プロセッサは、
    複数のリアルタイムビデオトラフィックフローを受信し、状態変数は、ノードにおいて各リアルタイムビデオトラフィックフローに関連付けられ、および各リアルタイムビデオトラフィックフローは、複数のパケットを含み、および各パケットは、消失パケットインジケータを含み、
    前記複数のリアルタイムビデオトラフィックフローのうちのリアルタイムビデオトラフィックフローの第１のパケットの消失パケットインジケータがパケットロスを示すと決定し、
    前記第１のパケットの前記消失パケットインジケータに基づいて前記ノードにおいて前記リアルタイムビデオトラフィックフローに関連付けられた前記状態変数を、パケットロスを示すように更新し、
    パケットロスを示している前記リアルタイムビデオトラフィックフローに関連付けられた前記状態変数に基づいて後続のパケットロスを前記リアルタイムビデオトラフィックフローに向ける
    ように少なくとも一部において構成されたことを特徴とするノード。
  20. 前記プロセッサは、
    前記リアルタイムビデオトラフィックフローの第３のパケットがリフレッシュフレームを含むと決定し、
    前記第３のパケットがリフレッシュフレームを含むという決定に基づいて前記状態変数を更新する
    ように構成されたことを特徴とする請求項１９に記載のノード。
  21. 前記プロセッサは、前記リアルタイムビデオトラフィックフローの第２のパケットの前記消失パケットインジケータがパケットロスを示さないと決定するように構成され、前記第２のパケットは、前記第１のパケットの後、および第３のパケットの前に到着することを特徴とする請求項１９に記載のノード。
  22. プロセッサを備えたノードであって、前記プロセッサは、
    複数のＲＴＰパケットを含んでいるリアルタイムビデオトラフィックフローを受信し、状態変数は、前記ノードにおいて前記リアルタイムビデオトラフィックフローに関連付けられ、
    前記リアルタイムビデオトラフィックフローの第１のＲＴＰパケットのシーケンス番号を決定し、
    前記リアルタイムビデオトラフィックフローの第２のＲＴＰパケットのシーケンス番号を決定し、
    前記第１のＲＴＰパケットと前記第２のＲＴＰパケットとの間でシーケンス番号におけるギャップを検出し、
    前記ギャップの検出に基づいて前記リアルタイムビデオトラフィックフローに関連付けられた前記状態変数を更新する
    ように構成されたことを特徴とするノード。
  23. 前記プロセッサは、
    前記リアルタイムビデオトラフィックフローの送信機に報告を送るように構成され、前記報告は、前記リアルタイムビデオトラフィックフローの前記第１のＲＴＰパケットと前記第２のＲＴＰパケットとの間でのシーケンス番号におけるギャップを示すことを特徴とする請求項２２に記載のノード。
  24. プロセッサを備えたノードであって、前記プロセッサは、
    リアルタイムビデオトラフィックフローを受信し、前記ノードにおいて前記リアルタイムビデオトラフィックフローに関連付けられた状態変数は、ロス状態を示し、
    前記リアルタイムビデオトラフィックフローのラウンドトリップタイム（ＲＴＴ）を決定し、
    前記ＲＴＴに基づいてロス状態がないことを示すように前記リアルタイムビデオトラフィックフローに関連付けられた前記状態変数を変更する
    ように少なくとも一部において構成されたことを特徴とするノード。
  25. ＲＴＴは、事前決定した値であることを特徴とする請求項２４に記載のノード。
  26. 前記ＲＴＴは、前記リアルタイムビデオトラフィックフローの発信元と送信先との間の伝送制御プロトコル（ＴＣＰ）接続に基づいて推定されることを特徴とする請求項２４に記載のノード。
  27. 前記ＲＴＴは、キューイング遅延を使用して前記ＲＴＴの下限を構築することによって決定されることを特徴とする請求項２４に記載のノード。
  28. 前記プロセッサは、
    前記ＲＴＴに基づいてタイマーを設定し、
    前記タイマーの満了を決定し、
    前記タイマーの前記満了に基づいてロス状態がないことを示すように前記リアルタイムビデオトラフィックフローに関連付けられた前記状態変数を変更する
    ように構成されたことを特徴とする請求項２４に記載のノード。
JP2016540438A 2013-09-06 2014-09-05 リアルタイムビデオアプリケーションのためのルータのためのユーザ体感品質に基づくキュー管理 Expired - Fee Related JP6307615B2 (ja)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201361874712P 2013-09-06 2013-09-06
US61/874,712 2013-09-06
US201361880806P 2013-09-20 2013-09-20
US61/880,806 2013-09-20
US201461975499P 2014-04-04 2014-04-04
US61/975,499 2014-04-04
US201462029239P 2014-07-25 2014-07-25
US62/029,239 2014-07-25
PCT/US2014/054385 WO2015035232A2 (en) 2013-09-06 2014-09-05 Quality of experience based queue management for routers for real-time video applications

Publications (2)

Publication Number Publication Date
JP2016534656A true JP2016534656A (ja) 2016-11-04
JP6307615B2 JP6307615B2 (ja) 2018-04-04

Family

ID=51570909

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016540438A Expired - Fee Related JP6307615B2 (ja) 2013-09-06 2014-09-05 リアルタイムビデオアプリケーションのためのルータのためのユーザ体感品質に基づくキュー管理

Country Status (6)

Country Link
US (1) US10116712B2 (ja)
EP (1) EP3042486B1 (ja)
JP (1) JP6307615B2 (ja)
KR (1) KR101831082B1 (ja)
CN (1) CN105706415B (ja)
WO (1) WO2015035232A2 (ja)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3042486B1 (en) 2013-09-06 2019-08-21 VID SCALE, Inc. Quality of experience based queue management for routers for real-time video applications
US9755932B1 (en) * 2014-09-26 2017-09-05 Juniper Networks, Inc. Monitoring packet residence time and correlating packet residence time to input sources
US9923836B1 (en) * 2014-11-21 2018-03-20 Sprint Spectrum L.P. Systems and methods for configuring a delay based scheduler for an access node
JP6532159B2 (ja) * 2015-05-13 2019-06-19 Kddi株式会社 リアルタイム映像通信の品質評価方法およびシステム
KR101701623B1 (ko) * 2015-07-09 2017-02-13 라인 가부시키가이샤 VoIP 통화음성 대역폭 감소를 은닉하는 시스템 및 방법
US10085029B2 (en) 2015-07-21 2018-09-25 Qualcomm Incorporated Switching display devices in video telephony
US10172136B1 (en) * 2015-09-02 2019-01-01 Cisco Technology, Inc. Method and apparatus for stabilizing wireless WAN interface
US10911413B2 (en) * 2015-09-16 2021-02-02 Oracle International Corporation Encapsulating and tunneling WebRTC traffic
BR112018069143A2 (pt) 2016-05-25 2019-01-22 Huawei Tech Co Ltd método de controle de serviço de dados e dispositivo relacionado
US10009282B2 (en) * 2016-06-06 2018-06-26 128 Technology, Inc. Self-protecting computer network router with queue resource manager
US11445223B2 (en) 2016-09-09 2022-09-13 Microsoft Technology Licensing, Llc Loss detection for encoded video transmission
CN106454201B (zh) * 2016-09-13 2020-04-24 国网天津市电力公司 一种基于ims网络的视频会议接入服务质量保证方法
US10650621B1 (en) 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network
CN110149718B (zh) * 2018-02-14 2022-03-29 华为技术有限公司 数据发送的方法和通信设备
US11159428B2 (en) * 2018-06-12 2021-10-26 Verizon Patent And Licensing Inc. Communication of congestion information to end devices
US11297632B2 (en) * 2018-07-06 2022-04-05 Huawei Technologies Co., Ltd. Methods and apparatus for ultra-reliable low latency communication (URLLC) during measurement gap
CN111052842B (zh) * 2018-08-13 2023-08-29 Lg电子株式会社 无线通信系统中用于在流量类和pppp之间映射的方法和设备
US10999088B2 (en) * 2018-11-20 2021-05-04 Dell Products, L.P. Proximity and context-based telepresence in collaborative environments
US11044618B2 (en) * 2019-04-18 2021-06-22 At&T Intellectual Property I, L.P. Facilitating automatic latency discovery and dynamic network selection using data analytics in advanced networks
US11757706B2 (en) * 2019-07-19 2023-09-12 Razberi Secure Technologies, Llc Switch monitoring system and method of use
US11039149B2 (en) * 2019-08-01 2021-06-15 Qualcomm Incorporated Dynamic video insertion based on feedback information
CN110730142B (zh) * 2019-10-14 2022-04-26 安徽工业大学 一种信息不可知情况下的数据中心流自适应调度方法
US11831933B2 (en) 2020-04-09 2023-11-28 Qualcomm Incorporated Video aware transmission and processing
US11575910B2 (en) 2020-04-09 2023-02-07 Qualcomm Incorporated Video aware transmission and multiple input multiple output layer processing
US11245741B2 (en) * 2020-04-09 2022-02-08 Qualcomm Incorporated Video aware multiplexing for wireless communication
US11349771B2 (en) * 2020-04-30 2022-05-31 Hewlett Packard Enterprise Development Lp Method and system for enhanced queue management in a switch
US11671976B2 (en) 2020-10-08 2023-06-06 Qualcomm Incorporated Early notification for transmission of encoded video data
EP3996352A1 (en) * 2020-11-04 2022-05-11 Sandvine Corporation System and method for congestion management in computer networks
KR102391804B1 (ko) 2020-11-23 2022-04-28 엘아이지넥스원 주식회사 FQ-CoDel 알고리즘의 매개변수 최적화 방법
WO2022154725A1 (en) * 2021-01-14 2022-07-21 Telefonaktiebolaget Lm Ericsson (Publ) Packet tunneling in a wireless communication network
WO2023023414A2 (en) * 2022-01-27 2023-02-23 Futurewei Technologies, Inc. Packet signature based quality of service (qos) classification
WO2023144589A1 (en) * 2022-01-29 2023-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Quality of experience directed network resource handling
US20230291816A1 (en) * 2022-03-10 2023-09-14 Qualcomm Incorporated Protocol overhead reduction for packet data convergence protocol
US20230319125A1 (en) * 2022-03-29 2023-10-05 Nokia Technologies Oy Two-way delay budget for interactive services

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001345847A (ja) * 2000-06-01 2001-12-14 Hitachi Ltd パケットデータ転送方法及びパケットデータ転送装置
JP2004236316A (ja) * 2003-01-27 2004-08-19 Microsoft Corp 帯域制御プログラム、方法およびエンド・システム
JP2009049530A (ja) * 2007-08-14 2009-03-05 Canon Inc データ送信装置、データ中継装置及びデータ受信装置
JP2013153474A (ja) * 2007-06-13 2013-08-08 Qualcomm Inc サービス情報品質設定

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6862622B2 (en) 1998-07-10 2005-03-01 Van Drebbel Mariner Llc Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture
BR0012332A (pt) 1999-07-09 2002-07-02 Malibu Networks Inc Arquitetura de sistema de transmissão sem fio de pacote de tcp/ip central
US8840475B2 (en) * 2002-12-10 2014-09-23 Ol2, Inc. Method for user session transitioning among streaming interactive video servers
DE602004025490D1 (de) 2003-08-21 2010-03-25 Vidiator Entpr Inc Metriken für die qualität der erfahrung (qoe) für drahtlose kommunikationsnetze
KR20070021098A (ko) 2003-08-21 2007-02-22 비디에이터 엔터프라이즈 인크 사용자 체감 품질(ｑｏｅ) 방법 및 무선통신 네트워크용 장치
KR101094628B1 (ko) 2008-12-23 2011-12-15 주식회사 케이티 타임스탬프를 이용한 실시간 서비스 모니터링 네트워크 장치 및 그 방법
US20110058554A1 (en) * 2009-09-08 2011-03-10 Praval Jain Method and system for improving the quality of real-time data streaming
US8738795B2 (en) * 2010-08-23 2014-05-27 Cisco Technology, Inc. Media-aware and TCP-compatible bandwidth sharing for video streaming
WO2013120074A1 (en) 2012-02-11 2013-08-15 Vid Scale, Inc. Method and apparatus for video aware hybrid automatic repeat request
EP3042486B1 (en) 2013-09-06 2019-08-21 VID SCALE, Inc. Quality of experience based queue management for routers for real-time video applications

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001345847A (ja) * 2000-06-01 2001-12-14 Hitachi Ltd パケットデータ転送方法及びパケットデータ転送装置
JP2004236316A (ja) * 2003-01-27 2004-08-19 Microsoft Corp 帯域制御プログラム、方法およびエンド・システム
JP2013153474A (ja) * 2007-06-13 2013-08-08 Qualcomm Inc サービス情報品質設定
JP2009049530A (ja) * 2007-08-14 2009-03-05 Canon Inc データ送信装置、データ中継装置及びデータ受信装置

Also Published As

Publication number Publication date
US20160219088A1 (en) 2016-07-28
CN105706415A (zh) 2016-06-22
JP6307615B2 (ja) 2018-04-04
WO2015035232A3 (en) 2015-06-25
KR101831082B1 (ko) 2018-02-21
US10116712B2 (en) 2018-10-30
WO2015035232A2 (en) 2015-03-12
EP3042486A2 (en) 2016-07-13
CN105706415B (zh) 2020-06-09
KR20160052689A (ko) 2016-05-12
EP3042486B1 (en) 2019-08-21

Similar Documents

Publication Publication Date Title
JP6307615B2 (ja) リアルタイムビデオアプリケーションのためのルータのためのユーザ体感品質に基づくキュー管理
US11824664B2 (en) Early packet loss detection and feedback
JP6286588B2 (ja) ビデオアウェアの（ｖｉｄｅｏ ａｗａｒｅ）ハイブリッド自動再送要求のための方法および装置
US10015716B2 (en) Systems and methods for preserving application identification information on handover in a communication network
US20180309664A1 (en) Enhancing performance of multi-path communications
US20140126502A1 (en) Qoe-aware traffic delivery in cellular networks
CN114142967A (zh) 使通信参数适配链路条件、业务类型和/或优先级
KR20140104961A (ko) 정체로 유도된 비디오 스케일링
EP2859768B1 (en) Cooperative applications in communication systems
WO2014078744A2 (en) Systems and methods for implementing model-based qoe scheduling
Abbasloo et al. Bounding queue delay in cellular networks to support ultra-low latency applications
Rene et al. Multipath TCP architecture for infotainment multimedia applications in vehicular networks
Liu et al. QoS-driven and fair downlink scheduling for video streaming over LTE networks with deadline and hard hand-off
Ling et al. Cross-Layer Signaling for Enhanced Wireless QoE
Hermanns et al. A framework and evaluation of rate adaptive video telephony in 4G LTE
Saleh Al-Majeed et al. DCCP video streaming over multiple connections in the wireless internet
Al-Majeed et al. Seamless Transport for Wireless IPTV Video Streaming

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170328

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170330

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170628

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170922

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180312

R150 Certificate of patent or registration of utility model

Ref document number: 6307615

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees