JP2012532516A - 複数のパケットにわたる制御情報の送信 - Google Patents

複数のパケットにわたる制御情報の送信 Download PDF

Info

Publication number
JP2012532516A
JP2012532516A JP2012517922A JP2012517922A JP2012532516A JP 2012532516 A JP2012532516 A JP 2012532516A JP 2012517922 A JP2012517922 A JP 2012517922A JP 2012517922 A JP2012517922 A JP 2012517922A JP 2012532516 A JP2012532516 A JP 2012532516A
Authority
JP
Japan
Prior art keywords
node
control information
packets
sending
congestion
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
JP2012517922A
Other languages
English (en)
Other versions
JP5738855B2 (ja
Inventor
ルン、ニコライ・コンラッド・ネポムセノ
ウルピナー、ファティ
ジアレッタ、ジェラルド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2012532516A publication Critical patent/JP2012532516A/ja
Application granted granted Critical
Publication of JP5738855B2 publication Critical patent/JP5738855B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00Arrangements for synchronising receiver with transmitter
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0078Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0079Formats for control data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/35Flow control; Congestion control by embedding flow control information in regular packets, e.g. piggybacking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used

Abstract

複数のパケットのヘッダ中で制御情報を送る技術を説明する。この技術により、パケット当たり少数のオーバーヘッドビットを使用して、より多くの制御情報を送ることが可能になる。1つの設計では、第1のノードは、第2のノードに送る制御情報を決定してもよい。第1のノードは、第2のノードに向けた複数のパケットのヘッダ中で制御情報を送ってもよい。1つの設計では、制御情報は、第1のノードにおけるトラフィック輻輳を示す輻輳情報を含んでいてもよい。IPパケットのヘッダ中の明示的輻輳通知(ECN)ビットを使用して、輻輳情報を送ってもよい。第1のノードは、すべてのパケットに対するまたは特定のデータフローに対する制御情報を、コーディングによりまたはコーディングすることなく送ってもよい。第1のノードはまた、制御情報を送る前に同期化シーケンスを送ってもよい。
【選択図】 図3

Description

米国特許法第119条の下での優先権の主張
本出願は、“複数のパケットにわたるコーディング輻輳情報”と題し、2009年7月2日に出願され、その譲受人に譲渡され、参照によりここに組み込まれている米国仮出願シリアル番号第61/222,590号に対する優先権を主張する。
背景
I.分野
本開示は、一般的に通信に関し、さらに詳細には、通信ネットワーク中で制御情報を送るための技術に関する。
II.背景
通信ネットワークは、音声、ビデオ、データ、メッセージング、ブロードキャスト等のようなさまざまな通信サービスを提供するように幅広く展開されている。通信ネットワークは、多数のユーザ機器(UE)に対する通信をサポートすることができる多数のネットワークエンティティを含んでいてもよい。通信ネットワークは、所定のUEからパケットを受信してもよく、サーバまたは遠端UEに向けてパケットを転送してもよい。パケットはまた、データパケット、データグラム、トランスポートブロック等としても呼ぶことがある。通信ネットワークはまた、サーバまたは遠端UEからパケットを受信してもよく、UEに向けてパケットを転送してもよい。送信エンドから受信エンドへの通信パス中の各エンティティは、ノードとして呼ぶことがある。ノードは、例えば、UEまたはネットワークエンティティであってもよく、例えば、基地局、ルータ、ゲートウェイ、サーバ等であってもよい。
通信ネットワーク中で、1つのノードから別のノードに制御情報を送ることが望ましいことがある。制御情報を運ぶための、適切なサイズのフィールドを持つパケットを規定してもよい。ノードは、その後、パケットの指定されたフィールド中で制御情報を送ってもよい。より大きなフィールドによって、より多くの制御情報を送ることが可能になることがあるが、結果としてパケット当たりのオーバーヘッドが大きくなることもあり、これは、制御情報が断続的に送られる場合には、無駄であるかもしれない。逆に、より小さいフィールドは、結果としてパケット当たりのオーバーヘッドが小さくなるが、送ることができる制御情報の量は制限されることがある。
それゆえ、通信ネットワーク中で効率的に制御情報を送るための技術に対する技術的な必要性がある。
概要
複数のパケットのヘッダ中で制御情報を送るための技術をここでは説明する。この技術により、パケット当たり少数のオーバーヘッドビットを使用して、より多くの制御情報を送ることが可能になる。
1つの設計では、第1のノード(例えば、基地局、ネットワーク制御装置、ルータ/ゲートウェイ等のようなネットワークエンティティ)は、第2のノード(例えば、UEまたは別のネットワークエンティティ)に送る制御情報を決定してもよい。第1のノードは、第2のノードに向けた複数のパケットのヘッダ中で制御情報を送ってもよい。1つの設計では、制御情報は、第1のノードにおけるトラフィック輻輳を示す輻輳情報を含んでいてもよい。1つの設計では、第1のノードは、インターネットプロトコル(IP)パケットのヘッダ中の明示的輻輳通知(ECN)ビットを使用して、輻輳情報を送ってもよい。
1つの設計では、第1のノードは、コーディングすることなく制御情報を送ってもよい。別の設計では、第1のノードは、コーディングにより、例えば、ブロックコード、ファウンテンコード、畳み込みコード等を使用して、制御情報を送ってもよい。1つの設計では、第1のノードは、第2のノードに送られるすべてのパケットに対する制御情報を送ってもよい。別の設計では、第1のノードは、第2のノードに対する特定のデータフローのための制御情報を決定してもよい。その後、第1のノードは、特定のデータフローに対するパケットのヘッダ中で制御情報を送ってもよい。1つの設計では、第1のノードは、いかなるときに制御情報を送ってもよい。別の設計では、第1のノードは、複数のパケット中で制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送ってもよい。第1のノードはまた、他の方法で制御情報を送ってもよい。
本開示のさまざまな態様および特徴を下記でさらに詳細に説明する。
図1は、ワイヤレス通信ネットワークを示している。 図2は、輻輳情報の送信を示している。 図3は、複数のパケットにわたる輻輳情報の送信を示している。 図4は、トランスポートレイヤおよびネットワークレイヤに対するデータユニットのカプセル化を示している。 図5は、データフローに対する輻輳情報の送信を示している。 図6は、コーディングによる輻輳情報の送信を示している。 図7は、輻輳情報の前の同期化シーケンスの送信を示している。 図8は、ワイヤレスネットワーク中での輻輳情報の例示的な送信を示している。 図9は、ワイヤレスネットワーク中での輻輳情報の例示的な送信を示している。 図10は、通信ネットワーク中でデータを転送するためのプロセスを示している。 図11は、通信ネットワーク中でデータを転送するための装置を示している。 図12は、通信ネットワーク中でデータを受信するためのプロセスを示している。 図13は、通信ネットワーク中でデータを受信するための装置を示している。 図14は、基地局、UE、および、ネットワークエンティティのブロックダイヤグラムを示している。
詳細な説明
ワイヤレス通信ネットワークおよびワイヤライン通信ネットワークを含むさまざまな通信ネットワークに対して、ここで説明する技術を使用してもよい。“ネットワーク”および“システム”という用語は、互換性があるように使用されることが多い。ワイヤレスネットワークは、ワイヤレスワイドエリアネットワーク(WWAN)、ワイヤレスメトロポリタンエリアネットワーク(WMAN)、ワイヤレスローカルエリアネットワーク(WLAN)等であってもよい。ワイヤラインネットワークは、ワイドエリアネットワーク(WAN)、メトロポリタンエリアネットワーク(MAN)、ローカルエリアネットワーク(LAN)、ケーブルネットワーク、コンピュータネットワーク等であってもよい。明確さのために、ワイヤレスネットワークに対して、技術のある態様を下記で説明する。
ここで説明する技術を使用して、さまざまなタイプの制御情報も送ってもよい。例えば、この技術を使用して、ノードにより観測したトラフィック輻輳を示す輻輳情報を送ってもよい。この技術を使用して、ルーティング情報、ノード能力情報等のような他の制御情報も送ってもよい。明確さのために、輻輳情報の送信に対して、技術のある態様を下記で説明する。
図1は、ここで説明する技術を利用することがあるワイヤレス通信ネットワーク100を示している。ワイヤレスネットワーク100は、多数の基地局と、多数の無線ネットワーク制御装置(RNC)と、コアネットワーク140とを含んでいてもよい。簡潔さのために、2つの基地局120aおよび120bと、2つのRNC130aおよび130bとだけが、図1中で示されている。基地局は、UEと通信するエンティティであってもよく、基地局はまた、ノードB、エボルブドノードB(eNB)、アクセスポイント等としても呼ぶことがある。各基地局は、特定の地理的エリアに対する通信カバレッジを提供してもよく、カバレッジエリア内に位置するUEに対する通信をサポートしてもよい。
RNCはまた、移動性スイッチングセンター(MSC)、サービングゲートウェイ(SGW)等としても呼ぶことがある。各RNCは、1組の基地局に結合していてもよく、基地局に対する調整および制御を提供してもよい。各RNCは、その基地局とコアネットワーク140との間のパケットをルーティングしてもよい。コアネットワーク140は、UEに対するさまざまな通信サービスをサポートすることがあるネットワークエンティティを含んでいてもよい。コアネットワーク140はまた、UEにパケットをルーティングするための/UEからのパケットをルーティングするための、ルータ/ゲートウェイを含んでいてもよい。
ワイヤレスネットワーク100は、コード分割多元接続(CDMA)ネットワーク、時分割多元接続(TDMA)ネットワーク、周波数分割多元接続(FDMA)ネットワーク、直交FDMA(OFDMA)ネットワーク、単一搬送波FDMA(SC−FDMA)ネットワーク等であってもよい。CDMAネットワークは、ユニバーサル地上無線アクセス(UTRA)、cdma2000等のような、無線技術を実現してもよい。UTRAは、ワイドバンドCDMA(WCDMA)と、CDMAの他の変形とを含んでいる。cdma2000は、IS−2000、IS−95、および、IS−856標準規格をカバーしている。TDMAネットワークは、グローバルシステムフォーモバイルコミュニケーション(GSM(登録商標))のような、無線技術を実現してもよい。OFDMAネットワークは、エボルブドUTRA(E−UTRA)や、ウルトラモバイルブロードバンド(UMB)や、IEEE802.11(WiFi(登録商標))や、IEEE802.16(WiMAX)や、IEEE802.20や、フラッシュOFDM(登録商標)等のような、無線技術を実現してもよい。UTRAおよびE−UTRAは、ユニバーサルモバイルテレコミュニケーションシステム(UMTS)の一部である。3GPPロングタームエボリューション(LTE)およびLTE−アドバンスト(LTE−A)は、E−UTRAを使用するUMTSの新しいリリースであり、ダウンリンク上ではOFDMAを用い、アップリンク上ではSC−FDMAを用いる。UTRA、E−UTRA、UMTS、LTE、LTE−A、およびGSMは、“第三世代パートナーシッププロジェクト”(3GPP)という名の組織による文書中に記述されている。cdma2000とUMBは、“第三世代パートナーシッププロジェクト2”(3GPP2)という名の組織による文書中に記述されている。上記で言及したワイヤレスネットワークおよび無線技術とともに、他のワイヤレスネットワークおよび無線技術に対して、ここで説明する技術を使用してもよい。
UEは、ワイヤレスネットワーク100全体に散らばっていてもよく、各UEは、静的なものまたは移動性のものであってもよい。簡潔さのために、図1中では、2つのUE110aおよび110bのみが示されている。UEはまた、移動局、端末、アクセス端末、加入者ユニット、局等として呼ぶことがある。UEは、セルラ電話機、パーソナルデジタルアシスタント(PDA)、ワイヤレスモデム、ワイヤレス通信デバイス、ハンドヘルドデバイス、ラップトップコンピュータ、コードレス電話機、ワイヤレスローカルループ(WLL)局、スマートフォン、ネットブック、スマートブック等であってもよい。UEは、ダウンリンクおよびアップリンクを介して基地局と通信してもよい。ダウンリンク(または、フォワードリンク)は、基地局からUEへの通信リンクのことを指し、アップリンク(または、リバースリンク)は、UEから基地局への通信リンクのことを指す。
図1中で示されている例では、UE110aは、UE110bとの通話を有している。UE110aは、第1の通信パスを介してUE110bにパケットを送ってもよい。第1の通信パスは、基地局120a、RNC130a、コアネットワーク140、RNC130b、および、基地局120bを含んでいてもよい。それに対応して、UE110bは、第2の通信パスを介してUE110aにパケットを送ってもよい。第2の通信パスは、基地局120b、RNC130b、コアネットワーク140、RNC130a、および、基地局120aを含んでいてもよい。
一般に、送信ノードは、任意の数の中間ノードを含む通信パスを介して、受信ノードにパケットを送ってもよい。各中間ノードは、(例えば、パケットを記憶し、処理するための)何らかの容量を有していてもよく、何らかの所定の瞬間において、何らかの負荷を観測することがある。各中間ノードは、許されている遅延内で、到来パケットを処理して、適切な受信ノードに送出パケットを送るべきである。中間ノードは輻輳することがあり、ノードにおける負荷が、ノードの容量を超えることがある。例えば、中間ノードが記憶および処理することができるより速く、到来パケットが到着することがある。輻輳が発生したときには、中間ノードは、処理および転送できないパケットを廃棄するかもしれない。
通信パスに沿った中間ノードが、それらの輻輳の状態を通信することが望ましいことがある。受信ノードは、中間ノードから輻輳情報を受信してもよく、この情報を使用して、(i)そのデータレートを変更する、および/または、(ii)受信ノードに向けたそのピア送信ノードのデータレートを変更してもよい。このレート適応は、任意の中間ノードにおける輻輳を取り扱うことができる。
図2は、輻輳情報の送信を示している。送信ノードは、通信パスを介して受信ノードにパケットを送ってもよい。図2中で示されている例では、通信パスは、3つの中間ノード1、2、および3を含んでいてもよい。各中間ノードは、アップストリームノードからパケットを受信してもよく、ダウンストリームノードにパケットを転送してもよい。ノード2は、輻輳を観測することがあり、受信ノードに向けて輻輳情報を送ってもよい。ノード2は、ダウンストリームノード3に輻輳情報を送ってもよく、ダウンストリームノード3は、受信ノードに輻輳情報を転送してもよい。受信ノードは、通信パス中の少なくとも1つの中間ノードが輻輳していることを輻輳情報に基づいて認識してもよい。受信ノードは、その後、中間ノードにおける輻輳を軽減するために、送信ノードのデータレートを減少させてもよい。
一般に、ノードは、アウトバンドシグナリングまたはインバンドシグナリングを使用して、輻輳情報を送ってもよい。ノードは、(i)アウトバンドシグナリングを使用して、パケットとは別に、輻輳情報を送ってもよく、または、(ii)インバンドシグナリングを使用して、パケット中で、輻輳情報を送ってもよい。受信ノードに向けて送られるパケット中で輻輳情報を送ることが、より効率的であるかもしれない。これは、余分なシグナリングに対する必要性を回避することができ、また、送信ノードから受信ノードにパケットをトランスポートするノードがすべて、必要な場合に確実に輻輳情報を提供できるようにする。
インターネットエンジニアリングタスクフォース(IETF)による、“IPに対する明示的輻輳通知(ECN)の追加”と題する、公然と入手可能であるコメント要求(RFC)3168中に記述されているように、インバンドシグナリングで輻輳情報を送る1つの方法は、IPパケットのヘッダ中の2つのECNビットを使用することである。2ビットのECNは、4つの可能性ある値のうちの1つにセットされてもよく、輻輳を示すために‘11’の値が使用される。ノードは、ノードが輻輳を検出した場合に、IPパケットのヘッダのECNビットを‘11’にセットしてもよい。受信ノードは、‘11’にセットされたECNビットを持つIPパケットを受信することがあり、送信ノードから受信ノードへの通信パス中の少なくとも1つの中間ノードが輻輳を観測したことを認識することができる。受信ノードは、その後、適切な訂正アクションを取ってもよい。
上記で説明した方法は、輻輳情報を伝えるのにIPパケット当たりの非常に小さいオーバーヘッド(2ビット)を使用する。しかしながら、この方法の主な制限は、小さい量の情報だけを通信できるということである。特に、所定の中間ノードは、ECNビットを使用して、“輻輳を経験している”または“輻輳を経験していない”ことだけを伝えることができる。IPパケットヘッダ中のより多くのビットを使用して、輻輳情報を送ってもよい。これは、より正確な輻輳情報の通信を可能にするだろう。しかしながら、輻輳情報を送るためには、IPパケット当たりより大きいオーバーヘッドとなるだろう。さらに、輻輳情報を伝えるために付加的なビットを使用することは、従来の方法で2ビットのECNをサポートしている通信ネットワークと後方互換性がないことがある。
ある態様では、複数のパケット中で制御情報を送ってもよく、これにより、パケット当たり少数のオーバーヘッドビットを使用して、より多い制御情報を送ることが可能になる。1つの設計では、各パケットのヘッダ中のECNビットを使用して、複数のパケット中で輻輳情報を送ってもよい。これにより、IPパケットオーバーヘッドを増加させることなく、より粒度の大きい輻輳情報を送ることが可能になる。
図3は、複数のIPパケット中で輻輳情報を送る設計を示している。中間ノードは、輻輳を観測することがあり、受信ノードに向けて送る輻輳情報を有していることがある。中間ノードは、輻輳情報をd1ないしdMのM個の部分に区分してもよく、ここで、Mは、1より大きい何らかの値であってもよい。一般に、各部分は、任意の数のビットの輻輳情報を含んでいてもよい。1つの設計では、各部分は、2ビットの輻輳情報を含んでいてもよく、2個のECNビットを使用して送ってもよい。別の設計では、各部分は、1ビットの輻輳情報を含んでいてもよく、2個のECNビットを使用して送ってもよい。例えば、‘00’のECNビットで、‘0’の情報ビットを送ってもよく、‘11’のECNビットで、‘1’の情報ビットを送ってもよい。いずれのケースでも、中間ノードは、各IPパケット中に、輻輳情報のうちの1個の部分があるように、M個のIPパケットのヘッダのECN中で、輻輳情報のM個の部分を送ってもよい。
一般に、任意の数のIPパケット中で、任意の数のビットの輻輳情報を送ってもよい。より多くのIPパケット中で輻輳情報を送ることにより、輻輳情報に対するより大きな粒度を達成してもよい。これにより、輻輳しているまたは輻輳していないという短期の決定ではなく、長期の統計的測定および傾向に基づいて、中間ノードが輻輳情報を送ることが可能になる。1つの設計では、中間ノードは、以下のもののうちの1つ以上を含む輻輳情報を送ってもよい:
・最大データレート−中間ノードによりサポートされる最大データレート、
・バッファスペース−中間ノードによりキューすることができるデータの平均量、
・キューイング遅延−中間ノードを通る平均キューイング遅延、
・中間ノードの輻輳状態を示す他の情報。
1つの設計では、1組のデータレートをサポートしてもよく、各データレートには一意的なインデックスが割り当てられている。輻輳情報は、中間ノードによりサポートされる最大データレートのインデックスを含んでいてもよい。輻輳情報に対するより多いビットで、より大きなデータレートをサポートすることができる。輻輳情報はまた、他の情報を伝えることができる。
中間ノードの長期の輻輳状態は、それほど頻繁に変化しない。IPパケットが送られているレートが、輻輳情報の変化のレートよりも十分に大きい場合には、長期の輻輳状態に関する輻輳情報を複数のIPパケット中で送ってもよい。
1つの設計では、受信ノードに転送されるすべてのIPパケットに対する輻輳情報を送ってもよい。別の設計では、受信ノードに対する特定のデータフローについての輻輳情報を送ってもよい。データフローは、IPフロー、トラフィックフロー、フロー等としても呼ぶことがある。受信ノードは、1つ以上のアプリケーションに対する多数のデータフローを有していてもよい。特定のアプリケーションに対する特定のデータフローについての輻輳情報を送ってもよい。これにより、受信ノードが、そのデータフローに対する輻輳情報に基づいて、特定のデータフローのデータレートを制御することが可能になる。
図4は、トランスポートレイヤおよびネットワークレイヤに対するデータユニットのフォーマットおよびカプセル化を示している。上位レイヤにおけるアプリケーションは、リアルタイムトランスポートプロトコル(RTP)等のような、さまざまなプロトコルを使用して、データを送ってもよい。RTPは、通常、音声、ビデオ、遠隔会議、および、遅延の影響を受けやすい他のアプリケーションに対して使用される。トランスポートレイヤに対してアプリケーションデータを提供してもよく、送信制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)等のような、さまざまなプロトコルを使用して、アプリケーションデータを送ってもよい。
TCPは、信頼性の高い、順序通りのデータの配信を提供することができ、ダウンロード、ウェブ閲覧等のような、信頼性の高いデータ配信を必要とするアプリケーションに対してTCPを使用してもよい。TCPに対しては、TCPセグメントとしてデータが送られ、各TCPセグメントは、TCPヘッダおよびTCPペイロードを含んでいる。TCPヘッダは、(i)データを送る送信ノードのための発信元ポート、(ii)データが送られる受信ノードのための宛先ポート、および、(iii)簡潔さのために図4中で示されていない他のフィールドを含んでいる。ポートは、ペイロード中のデータに関係付けられている論理チャネルであってもよい。
UDPは、(より小さいオーバーヘッドではあるが)信頼性の低いデータの配信を提供することができ、そして、遅延しているパケットを待つよりもパケットを脱落させるほうが好ましいことがある、遅延の影響を受けやすいアプリケーションに対して、UDPを使用してもよい。UDPに対しては、UDPデータグラムとしてデータが送られ、各UDPデータグラムは、UDPヘッダおよびUDPペイロードを含んでいる。UDPヘッダは、発信元ポート、宛先ポート、および、他のフィールドを含んでいる。
ネットワークレイヤに対してトランスポートレイヤデータを提供してもよく、IPを使用して、トランスポートレイヤデータを送ってもよい。IPに対しては、IPパケット(または、データグラム)としてデータが送られ、各IPパケットは、IPヘッダおよびIPペイロードを含んでいる。IPヘッダは、(i)IPパケットを送る発信元ノードのための発信元IPアドレス、(ii)IPパケットが送られる宛先ノードのための宛先IPアドレス、(iii)IPペイロード中で送られるデータに対して使用されるプロトコル(例えば、TCPまたはUDP)を示すプロトコルフィールド、(iv)ECNビット、および、(v)簡潔さのために図4中で示されていない他のフィールドを含んでいる。IPペイロードは、TCPセグメント、UDPデータグラム、または、他の何らかのデータを運んでもよい。
発信元IPアドレス、宛先IPアドレス、発信元ポート、宛先ポート、および、プロトコルの5タプルの組み合わせにより、データフローを一意的に識別してもよい。中間ノードは、IPヘッダ中の5個のフィールドと、各パケットのTCP/UDPヘッダとを調べることにより、特定のデータフローに属するパケットを識別してもよい。中間ノードは、データフローに対する輻輳情報を決定してもよく、この情報をデータフローに対するパケット中で送ってもよい。
図5は、データフローに対する輻輳情報を送る設計を示している。中間ノードは、データフローに対する輻輳情報を有していてもよく、これは、ヴォイスオーバーIP(VoIP)のような、リアルタイムサービスのためのものであってもよい。中間ノードは、輻輳情報をd1ないしdMのM個の部分に区分してもよく、ここで、Mは、1よりも大きい。中間ノードは、各IPパケット中に、輻輳情報のうちの1つの部分があるように、データフローに対するM個のIPパケットのヘッダのECN中で、輻輳情報のM個の部分を送ってもよい。たとえ、これらのIPパケットが同じ受信ノードに送られる場合であっても、中間ノードは、他のデータフローに対するIPパケット中で輻輳情報を送ることを回避することができる。
一般に、中間ノードは、任意の数のデータフローに対する輻輳情報を送ってもよい。中間ノードは、特定のデータフローの、または、(例えば、特定のアプリケーションに対する)データフローのグループの、または、受信ノードに対するすべてのデータフローの、輻輳状態を示す輻輳情報を送ってもよい。例えば、中間ノードは、VoIPフローに対して、IPパケット中で、輻輳を示す輻輳情報を送ってもよく、TCPフローに対して、IPパケット中で、輻輳を示す輻輳情報を送ってもよい等である。
上記で説明した1つの設計では、何らかのコーディングをすることなく、複数のIPパケットのヘッダ中で輻輳情報を送ってもよい。受信ノードは、輻輳情報を運ぶすべてのIPパケットを受信してもよく、これらのIPパケットから輻輳情報を復元してもよい。
別の設計では、複数のIPパケットのヘッダ中で送信する前に、順方向誤り訂正(FEC)で輻輳情報をエンコードしてもよい。この設計により、たとえ、IPパケットのうちの1つ以上が脱落したり、または、損なわれたり、または、順序通りでなく配信された場合であっても、受信ノードが、輻輳情報を復元することが可能になる。
図6は、複数のIPパケット中で、コーディングにより輻輳情報を送る設計を示している。中間ノードは、輻輳を観測することがあり、受信ノードに向けて送る輻輳情報を有していることがある。中間ノードは、FECエンコーダで輻輳情報をエンコードして、コード化したデータを発生させてもよく、これは、コードワードとして呼ぶこともある。中間ノードは、コード化したデータをc1ないしcNのN個の部分に区分してもよく、ここで、Nは、1よりも大きいことがある。中間ノードは、各IPパケット中に、コード化したデータのうちの1個の部分があるように、N個のIPパケットのヘッダのECN中で、コード化したデータのN個の部分を送ってもよい。
一般に、ブロックコード、ファウンテンコード、畳み込みコード、ターボコード等を含むさまざまなFECコードに基づいて、輻輳情報をエンコードしてもよい。ブロックコードは、第1のサイズの情報のブロックを受信し、情報をエンコードし、第2のサイズのコード化したデータのブロックを提供してもよい。第1のサイズおよび第2のサイズは、固定であってもよく、送る情報の量と、冗長性または誤り訂正能力の所望の量とに基づいて、選択してもよい。輻輳情報をエンコードするためにさまざまなタイプのブロックコードを使用してもよく、さまざまなタイプのブロックコードは、リード−ソロモンコード、リード−マラーコード、ハミングコード等を含んでいてもよい。(レートレスコードとして呼ぶこともある)ファウンテンコードは、情報のブロックを受信し、情報をエンコードし、固定量または可変量のコード化したデータを提供してもよい。受信ノードにより輻輳情報が正しく受信されるまで、漸進的に多くなるコード化したデータを中間ノードが送ることが可能になるように、可変レートのファウンテンコードを使用してもよい。受信ノードは、その後、受信ノードが輻輳情報を適切にデコードしたことを示すために肯定応答(ACK)を送ってもよい。受信ノードは、中間ノードに向けて送られるIPパケットのヘッダを介して、中間ノードにACKを送ってもよい。
受信ノードは、IPパケットのシーケンスを受信し、IPパケットのヘッダからコード化したデータを抽出し、コード化したデータを連結し、FECデコーディングを実行して、中間ノードにより送られた輻輳情報を復元してもよい。輻輳情報を送るのに使用されたFECコードにより、コード化したデータ中の誤りおよび消去を受信ノードが訂正することが可能になる。消去は、欠落しているコード化データの結果、起こることがあり、欠落しているコード化データは、脱落したIPパケットに起因するものであることがある。誤りは、(i)ノイズのあるチャネルに起因する損なわれたコード化データ、および/または、(ii)シーケンス通りでなく受信されたIPパケットに起因する順序通りでないコード化データの結果、起こることがある。FECコードの誤りおよび消去訂正能力が、受信ノードにより訂正することができる誤りおよび消去の量を決定してもよい。
1つの設計では、輻輳情報をエンコードするのに使用するために、十分な誤りおよび消去訂正能力を持つFECコードを選択してもよい。別の設計では、ある量の誤りおよび消去を訂正するための能力を持つFECコードを設計および使用して、輻輳情報をエンコードしてもよい。消去と、シーケンス通りでないIPパケットに起因する再順序付けとを処理するように、この“カスタム”FECコードを設計することもできる。例えば、カスタムFECコードは、輻輳情報を運んでいるIPパケットが受信されるかもしれない異なる可能性ある順序に対する1組のコードワードに、輻輳情報に対する所定のワードをマッピングしてもよい。
1つの設計では、受信ノードは、脱落したIPパケットに起因する消去を検出することがあり、検出した消去に基づいて、必要に応じてコード化したデータを再配置してもよい。受信ノードはまた、シーケンス通りでないIPパケットに起因する順序通りでないコード化データを検出することがあり、必要に応じてコード化したデータを再順序付けしてもよい。受信ノードは、IPパケットのペイロード中の関連情報を調べることにより、消去と、順序通りでないコード化データとを検出することがある。例えば、IPパケットは、RTP/UDPデータフローに対するリアルタイムマルチメディアデータを運んでもよく、連続するパケットに対するRTPシーケンス番号は、増加するはずである。欠落しているRTPシーケンス番号または順序通りでないRTPシーケンス番号を使用して、脱落しているコード化データまたは順序通りでないコード化データを識別してもよい。受信ノードは、欠落しているRTPシーケンス番号に対応する各IPパケットに対して消去を挿入してもよく、順序通りでないRTPシーケンス番号に対応するIPパケットに対するコード化データを再順序付けしてもよい。受信ノードは、その後、再配置したコードデータ上でFECデコーディングを実行してもよい。
一般に、受信ノードは、消去と、順序通りでないコード化データとを検出することがあり、上記のIPの何らかのプロトコルに対するシーケンス番号に基づいて、コード化データを再配置してもよい。中間ノードが、アップストリームノードから、脱落したIPパケットおよび/または再順序付けしたIPパケットを受信し、これらのIPパケット中で輻輳情報を送る場合に、受信ノードによる消去の挿入および再順序付けは、誤りを生じさせることがある。したがって、受信ノードは、(i)何らかの消去の挿入または再順序付けのない受信したコード化データ上と、(ii)消去の挿入および/または再順序付けのある再配置されたコード化データ上で、FECデコーディングを実行してもよい。
1つの設計では、中間ノードは、輻輳情報の前に同期化シーケンスを送ってもよい。同期化シーケンスは、受信ノードが、輻輳情報の開始を検出することを可能にし、これは、デコーディング性能を向上させる。
図7は、輻輳情報の前に同期化シーケンスを送る設計を示している。中間ノードは、受信ノードに向けて送る輻輳情報を有していてもよい。中間ノードは、FECエンコーダにより輻輳情報をエンコードして、コード化データを発生させてもよく、コード化データを、c1ないしcNのN個の部分に区分してもよく、ここで、Nは、1より大きくてもよい。中間ノードは、同期化シーケンスを、s1ないしsKのK個の部分に区分してもよく、ここで、Kは、1または1より大きくてもよい。中間ノードは、各IPパケット中に、同期化シーケンスのうちの1個の部分があるように、K個のIPパケットのヘッダのECN中で、同期化シーケンスのK個の部分を送ってもよい。中間ノードは、その後、各IPパケット中に、コード化データのうちの1個の部分があるように、N個のIPパケットのヘッダのECN中で、コード化データのN個の部分を送ってもよい。
受信ノードは、IPパケットを受信してもよく、受信したIPパケット中の同期化シーケンスを検出してもよい。同期化シーケンスを検出する際に、受信ノードは、後続するIPパケットからコード化データを取得してもよく、コード化データをデコードして、受信ノードに送られた輻輳情報を取得してもよい。同期化シーケンスの使用は、受信ノードが、輻輳情報のために送られたコードワードを正しくデコードする確率を向上させるかもしれない。
一般に、同期化シーケンスは、何らかの適切なビットのシーケンスを含んでいる。同期化シーケンスは、輻輳情報に対する有効なコードワードであるはずはないので、このコードワードを、同期化シーケンスとして、間違って検出しないだろう。同期化シーケンスは、何らかの適切な長さを有していてもよい。より短い同期化シーケンスは、オーバーヘッドを減少させ、輻輳情報が送られる頻度がより高い場合には、好ましいことがある。より長い同期化シーケンスは、より良好な検出の信頼性を提供することができ、輻輳情報が送られる頻度がより低い場合には、好ましいことがある。同期化シーケンスの長さは、輻輳情報に対するコードワードの長さに一致していてもよく、または、一致していなくてもよい。
図8は、図1中のワイヤレスネットワーク100における、データおよび輻輳情報の例示的な送信を示している。UE110aは、送信ノード/UEであってもよく、UE110bは、受信ノード/UEであってもよい。UE110aからUE110bへの通信パスは、基地局120aおよびRNC130aに対応するノード1と、コアネットワーク140中のルータ/ゲートウェイに対応するノード2と、基地局120bおよびRNC130bに対応するノード3とを含んでいてもよい。
図8中で示されている例では、ノード3は、受信UEに送る輻輳情報を有していてもよい。ワイヤレスネットワークに対しては、ノード3により観測した輻輳は、ダウンリンク上で受信UEにデータを送るために利用可能な帯域幅が制限されていることに起因するものであるかもしれない。ノード3は、その後、サポートされる最大データレートを含む輻輳情報を受信UEに送ってもよい。ノード3は、(コアネットワーク中の)アップストリームノード2からIPパケットを受信してもよく、複数のIPパケット中で、受信UEに輻輳情報を送ってもよい。
ノード3は、受信UEに対するダウンリンクおよびアップリンクに対して異なる輻輳状態(例えば、異なる最大レート)を有していることがある。1つの設計では、ノード3により送られる輻輳情報は、輻輳情報(例えば、最大レート)がダウンリンクまたはアップリンクに対して適用可能であるか否かを示すビットを含んでいてもよい。1つの設計では、ノード3は、ダウンリンクとアップリンクとに対して別々に輻輳情報を送ってもよく、例えば、最大データレートに対する1つのコードワードは、ダウンリンクに対するものであり、最大データレートに対する別のコードワードは、アップリンクに対するものである。別の設計では、ノード3は、ダウンリンクとアップリンクの双方に対する輻輳情報を含む単一のコードワード(例えば、各リンクに対して1つの最大データレート)を送ってもよい。ノード3はまた、他の方法で、受信UEに輻輳情報を送ってもよい。
図9は、図1中のワイヤレスネットワーク100における、データおよび輻輳情報の別の例示的な送信を示している。図9中で示されている例では、ノード1は、受信UEに送る輻輳情報を有していてもよく、受信UEに向けたIPパケット中で輻輳情報(例えば、最大データレート)を送ってもよい。ノード2は、ノード1がIPパケットにわたって輻輳情報を送っていることを認識してもよく、アップストリームノード3からの輻輳情報を検出してもよい。ノード2は、受信UEに対して、ノード1によりサポートされる最大データレートを取得してもよい。ノード2が、この最大データレートをサポートすることができる場合に、ノード2は、受信UEに向けて輻輳情報を単に転送してもよい。しかしながら、ノード2が、受信UEに対して、より低いデータレートのみをサポートすることができる場合には、ノード2は、アップストリームノード1から受信した輻輳情報を廃棄してもよく、ノード2がサポートすることができる最大データレートを含む新しい輻輳情報を送ってもよい。同様に、ノード3は、アップストリームノード2から輻輳情報を検出し、ノード1およびノード2の双方によりサポートされる最大データレートを取得してもよい。ノード3が、この最大データレートをサポートすることができる場合には、ノード3は、受信UEに向けて輻輳情報を単に転送してもよい。しかしながら、ノード3が、より低いデータレートのみをサポートすることができる場合には、ノード3は、ノード2から受信した輻輳情報を廃棄してもよく、ノード3がサポートすることができる最大データレートを含む新しい輻輳情報を送ってもよい。
一般に、送信UEから受信UEへの通信パス中の各中間ノードは、(i)中間ノードが、受信した輻輳情報により示されている最大データレートをサポートすることができる場合にアップストリームノードから受信した輻輳情報を転送するか、または、(ii)中間ノードによりサポートされる最大データレートを含む新しい輻輳情報を送るかのいずれかであってもよい。通信パス中の各中間ノードによるこの処理の結果として、(受信ノードを含む)各ノードにより受信される最大データレートは、すべてのアップストリームノードによりサポートされる最大データレートのうちの最低/最小のものである。
中間ノードは、受信したIPパケットをキューすることなく、アップストリームノードからの輻輳情報を検出してもよい。中間ノードは、アップストリームノードから受信した何らかの輻輳情報を転送してもよい。新しい輻輳情報を送ることを中間ノードが決めた場合には、中間ノードは、受信ノードに向けて送る次のIPパケットのシーケンス中で、この情報を送ってもよい。
通信パス中の中間ノードは、輻輳情報が複数のIPパケット中で送られていることを認識していないことがある。中間ノードは、単一のIPパケットのヘッダ中のECNビットを使用して、輻輳していることまたは輻輳していないことのいずれかを伝える方法をサポートしてもよい。中間ノードは、その輻輳状態に基づいて、いくつかのIPパケットのECNビットを変更してもよい。中間ノードによるこれらの変更は、結果として、ダウンストリームノードにより受信されるコード化データのうちのいくつかでは、誤りになるかもしれない。ダウンストリームノードは、誤りが存在するときでさえ、輻輳情報を送るのに使用されたFECコードに基づいて、輻輳情報を復元することができる。
受信UEは、複数のIPパケット中で輻輳情報を受信してもよく、通信パス中のすべての中間ノードによりサポートされる最大データレートを決定してもよい。受信UEは、輻輳情報から取得した最大データレートに基づいて、送信UEにおけるエンコーダを制御してもよい。受信UEは、RTPインバンドコーデックモード要求、RTP制御プロトコル(RTCP)メッセージ、ならびに/あるいは、他のメカニズムまたはプロトコルを使用して、送信UEにおけるエンコーダを制御してもよい。代替的にまたは付加的に、図9中の点線の矢印により示されているように、送信ノードに最も近いノード1は、送信UEに対して、ノード1によりサポートされるアップリンク上の最大データレートに基づいて、送信UEにおけるエンコーダを制御するために、送信UEに直接輻輳情報を送ってもよい。
複数のパケット中で輻輳情報を送るためのさまざまな設計を説明してきた。これらの設計を使用して、受信ノードに送られるすべてのパケットに対する、または、特定のデータフローに対する、または、データフローのグループに対する、輻輳情報等を送ってもよい。例えば、図6において示されているように、FECコーディングにより、すべてのパケットに対する輻輳情報を送ってもよい。特定のデータフローに対する輻輳情報はまた、このデータフローに対するパケットにわたって、FECコーディングにより送ってもよい。図7において示されているように、同期化シーケンスにより、すべてのパケットに対する輻輳情報を送ってもよい。特定のデータフローに対する輻輳情報はまた、このデータフローに対するパケットにわたって、同期化シーケンスにより送ってもよい。図9において示されているように、通信パス中の各ノードにより、すべてのパケットに対する輻輳情報を転送および/または置換してもよい。特定のデータフローに対する輻輳情報はまた、通信パス中の各ノードにより、このデータフローに対するパケット中で、転送および/または置換してもよい。複数のパケット中で輻輳情報を送る他の特徴はまた、特定のデータフローに対して適用してもよい。
明確さのために、複数のパケット中での輻輳情報の送信を上記で説明してきた。一般に、この技術を使用して、通信パス中の1つのノードから別のノードに向けて何らかの制御情報を送ってもよい。例えば、この技術を使用して、ルーティング情報、ノード能力情報等を送ってもよい。
図10は、通信ネットワーク中で、第1のノードから第2のノードに向けてデータを転送するためのプロセス1000の設計を示している。第1のノードは、通信パス中の中間ノードであってもよい。第2のノードは、受信ノードまたは別の中間ノードであってもよい。第1のノードは、基地局、ルータ/ゲートウェイ、サーバ等のような、ネットワークエンティティに対応していてもよい。第2のノードは、UEまたは別のネットワークエンティティに対応していてもよい。第1のノードにより、プロセス1000を実行してもよい。第1のノードは、第2のノードに向けて転送するパケットをアップストリームノードから受信してもよい。第1のノードは、第2のノードに送る制御情報を決定してもよい(ブロック1012)。第1のノードは、第2のノードに向けた複数のパケットのヘッダ中で制御情報を送ってもよい(ブロック1014)。
1つの設計では、制御情報は、第1のノードにおけるトラフィック輻輳を示す輻輳情報を含んでいてもよい。1つの設計では、輻輳情報は、例えば、第2のノードに対して、第1のノードによりサポートされる最大データレートを含んでいてもよい。他の設計では、輻輳情報は、第1のノードにおけるトラフィック輻輳を示す他の情報を含んでいてもよい。1つの設計では、第1のノードは、IPパケットのヘッダ中のECNビットを使用して、輻輳情報を送ってもよい。第1のノードはまた、ヘッダの他のビットまたは他のフィールドを使用して、輻輳情報を送ってもよい。
1つの設計では、第2のノードに送る輻輳情報は、第2のノードへの通信パス中のすべてのノードによりサポートされる最も低い最大データレートに対応していてもよい。第1のノードは、第1のノードに対してアップストリームである第3のノードから輻輳情報を受信してもよい。第1のノードに対して、第3のノードによりサポートされる最大データレートが、第2のノードに対して、第1のノードによりサポートされる最大データレートより大きいまたは等しい場合に、第1のノードは、第2のノードに送る輻輳情報として、受信した輻輳情報を提供してもよい。第2のノードに対して、第1のノードによりサポートされる最大データレートが、第1のノードに対して、第3のノードによりサポートされる最大データレートより小さい場合に、第1のノードは、第2のノードに送る輻輳情報として、新しい輻輳情報を提供してもよい。新しい輻輳情報は、第2のノードに対して、第1のノードによりサポートされる最大データレートを含んでいてもよい。
1つの設計では、第1のノードは、コーディングすることなく、制御情報を送ってもよい。第1のノードは、制御情報を、複数の部分に区分してもよい。第1のノードは、その後、例えば、図3において示されているように、複数のパケットのうちの1つのもののヘッダ中で、制御情報の複数の部分のそれぞれを送ってもよい。
別の設計では、第1のノードは、コーディングにより制御情報を送ってもよい。第1のノードは、(例えば、ブロックコード、ファウンテンコード、畳み込みコード、ターボコード、他の何らかのコード、または、それらの組み合わせに基づいて、)制御情報をエンコードして、コード化したデータを取得してもよい。第1のノードは、コード化データを、複数の部分に区分してもよい。第1のノードは、その後、例えば、図6において示されているように、複数のパケットのうちの1つのもののヘッダ中で、コード化データの複数の部分のそれぞれを送ってもよい。
1つの設計では、第1のノードは、第2のノードに送られているすべてのパケットに対する制御情報を送ってもよい。別の設計では、第1のノードは、第2のノードに対する特定のデータフローのための制御情報を決定してもよい。第1のノードは、その後、データフローに対するパケットのヘッダ中で、制御情報を送ってもよい。
1つの設計では、第1のノードは、任意の時間において、第2のノードに制御情報を送ってもよい。別の設計では、例えば、図7において示されているように、第1のノードは、複数のパケット中で制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送ってもよい。
1つの設計では、第1のノードは、ネットワークエンティティ(例えば、基地局)を含んでいてもよく、第2のノードは、ワイヤレスネットワーク中のUEを含んでいてもよい。別の設計では、第1のノードは、ルータ/ゲートウェイ、または、サーバを含んでいてもよく、第2のノードは、ワイヤレスネットワーク中のUEを含んでいてもよい。一般に、第1のノードおよび第2のノードは、ワイヤレスネットワーク中またはワイヤードネットワーク中の何らかの2つのネットワークエンティティであってもよい。第1のノードは、第2のノードに直接パケットを送るか、または、1つ以上の他のノードを介して、第2のノードに間接的にパケットを送ってもよい。
図11は、通信ネットワーク中でデータを転送するための装置1100の設計を示している。装置1100は、第1のノードから第2のノードに送る制御情報を決定するモジュール1112と、第2のノードに向けた複数のパケットのヘッダ中で制御情報を送るモジュール1114とを備えている。
図12は、通信ネットワーク中で、第1のノードにより第2のノードに対して送られるデータを受信するためのプロセス1200の設計を示している。第1のノードおよび第2のノードは、図10に対して上記で説明したようなものであってもよい。第2のノードにより、プロセス1200を実行してもよい。第2のノードは、第1のノードにより第2のノードに向けて送られる複数のパケットを受信してもよい(ブロック1212)。第2のノードは、複数のパケットを処理して、複数のパケットのヘッダ中で第1のノードにより送られた制御情報を取得してもよい(ブロック1214)。1つの設計では、制御情報は、第1のノードにおけるトラフィック輻輳を示す輻輳情報を含んでいてもよい。輻輳情報に応答して、第2のノードは、第2のノードにデータを送る第3のノードのデータレートを減少させるために、メッセージを送ってもよい。
1つの設計では、コーディングすることなく、第1のノードにより制御情報を送ってもよい。第2のノードは、複数のパケットのそれぞれのヘッダから、制御情報の一部分を取得してもよい。別の設計では、コーディングにより、第1のノードにより制御情報を送ってもよい。第2のノードは、複数のパケットのそれぞれのヘッダから、コード化データの一部分を取得してもよい。第2のノードは、その後、コード化データをデコードして、制御情報を取得してもよい。
1つの設計では、制御情報は、第1のノードにより第2のノードに向けて送られるすべてのパケットに対するものであってもよい。別の設計では、制御情報は、第2のノードに対するデータフローのためのものであってもよく、データフローに対するパケット中で、制御情報を送ってもよい。
1つの設計では、第2のノードは、制御情報を継続的に検出してもよい。別の設計では、第2のノードは、少なくとも1つのパケット中の同期化シーケンスを検出してもよい。同期化シーケンスを検出した後に、第2のノードは、複数のパケットを受信して処理し、制御情報を復元してもよい。
図13は、通信ネットワーク中でデータを受信するための装置1300の設計を示している。装置1300は、第1のノードにより第2のノードに向けて送られた複数のパケットを受信するモジュール1312と、第2のノードにおいて複数のパケットを処理して、複数のパケットのヘッダ中で第1のノードにより送られた制御情報を取得するモジュール1314とを備えている。
図11中および図13中のモジュールは、プロセッサ、電子デバイス、ハードウェアデバイス、電子コンポーネント、論理回路、メモリ、ソフトウェアコード、ファームウェアコード等、または、それらの何らかの組み合わせを含んでいてもよい。
図14は、基地局120およびUE110の設計のブロックダイヤグラムを示しており、これらは、図1中の基地局のうちの1つと、図1中のUEのうちの1つであってもよい。基地局120には、T本のアンテナ1434aないし1434tが装備されていてもよく、UE110には、R本のアンテナ1452aないし1452rが装備されていてもよく、ここで、一般に、T≧1かつR≧1である。
基地局120において、送信プロセッサ1420は、データソース1412からデータを受け取り、制御装置/プロセッサ1440から制御情報(例えば、輻輳情報)を受け取ってもよい。プロセッサ1420は、データおよび制御情報を処理して(例えば、エンコードして、および、変調して)、データシンボルと制御シンボルをそれぞれ取得してもよい。プロセッサ1420はまた、基準信号に対する基準シンボルを発生させてもよい。送信(TX)複数入力複数出力(MIMO)プロセッサ1430は、適用可能な場合には、データシンボル上、制御シンボル上、および/または、基準シンボル上で、空間処理(例えば、プリコーディング)を実行してもよく、T台の変調器(MOD)1432aないし1432tにT個の出力シンボルストリームを提供してもよい。各変調器1432は、(例えば、OFDM、CDMA等のために)それぞれの出力シンボルストリームを処理して、出力サンプルストリームを取得してもよい。各変調器1432は、出力サンプルストリームをさらに処理して(例えば、アナログにコンバートして、増幅して、フィルタリングして、および、アップコンバートして)、ダウンリンク信号を取得してもよい。T本のアンテナ1434aないし1434tを介して、変調器1432aないし1432tからのT個のダウンリンク信号をそれぞれ送信してもよい。
UE110において、アンテナ1452aないし1452rは、基地局120および他の基地局からダウンリンク信号を受信してもよく、復調器(DEMOD)1454aないし1454rに、それぞれ、受信した信号を提供してもよい。各復調器1454は、それぞれの受信した信号を調整して(例えば、フィルタリングして、増幅して、ダウンコンバートして、および、デジタル化して)、入力サンプルを取得してもよい。各復調器1454は、(例えば、OFDM、CDMA等のために)入力サンプルをさらに処理して、受信したシンボルを取得してもよい。MIMO検出器1456は、すべてのR台の復調器1454aないし1454rから、受信したシンボルを取得し、適用可能である場合には、受信したシンボル上でMIMO検出を実行し、検出したシンボルを提供してもよい。受信プロセッサ1458は、検出したシンボルを処理して(例えば、復調して、および、デコードして)、UE110に対するデコードしたデータをデータシンク1460に提供し、制御装置/プロセッサ1480に、デコードした制御情報を提供してもよい。
アップリンク上では、UE110において、送信プロセッサ1464は、データソース1462からデータを受け取ってもよく、制御装置/プロセッサ1480から制御情報を受け取ってもよい。制御情報は、送信ノードのデータレートを制御するためのメッセージを含んでいてもよい。プロセッサ1464は、データおよび制御情報を処理して(例えば、エンコードして、および、変調して)、データシンボルと制御シンボルをそれぞれ取得してもよい。プロセッサ1464はまた、基準シンボルを発生させてもよい。適用可能である場合には、TX MIMOプロセッサ1466により、送信プロセッサ1464からのシンボルをプリコーディングし、(例えば、SC−FDM、OFDM、CDMA等のために)変調器1454aないし1454rによりさらに処理して、基地局120と、場合によっては他の基地局に送信してもよい。基地局120において、UE110および他のUEからのアップリンク信号を、アンテナ1434により受信し、復調器1432により処理し、適用可能である場合には、MIMO検出器1436により検出し、受信プロセッサ1438によりさらに処理して、UE110および他のUEにより送られたデコードしたデータおよび制御情報を取得してもよい。プロセッサ1438は、データシンク1439にデコードしたデータを提供し、制御装置/プロセッサ1440にデコードした制御情報を提供してもよい。
制御装置/プロセッサ1440および1480は、基地局120における動作とUE110における動作とをそれぞれ命令してもよい。プロセッサ1440ならびに/あるいは基地局120における他のプロセッサおよびモジュールは、図10中のプロセス1000や、図12中のプロセス1200や、および/または、ここで説明する技術に対する他のプロセスを実行または命令してもよい。プロセッサ1480ならびに/あるいはUE110における他のプロセッサおよびモジュールは、図12中のプロセス1200や、および/または、ここで説明する技術に対する他のプロセスを実行または命令してもよい。メモリ1442およびメモリ1482は、基地局120とUE110とに対するデータおよびプログラムコードをそれぞれ記憶してもよい。通信(Comm)ユニット1444は、基地局120が、他のネットワークエンティティと通信することを可能にする。スケジューラ1446は、ダウンリンク上および/またはアップリンク上でのデータ送信のために、UEをスケジュールしてもよい。
図14はまた、ネットワークエンティティ150の設計を示しており、これは、RNC、ルータ/ゲートウェイ、または、他の何らかのエンティティであってもよい。ネットワークエンティティ150内では、制御装置/プロセッサ1490が、例えば、データのルーティングや、輻輳の検出や、輻輳情報の送信等のような、通信をサポートするためのさまざまな機能を実行してもよい。制御装置/プロセッサ1490は、図10中のプロセス1000や、図12中のプロセス1200や、および/または、ここで説明する技術に対する他のプロセスを実行してもよい。メモリ1492は、ネットワークエンティティ150に対するプログラムコードおよびデータを記憶してもよい。通信ユニット1494は、ネットワークエンティティ150が、他のネットワークエンティティと通信することを可能にする。
当業者は、さまざまな異なる技術および技法のうちの任意のものを使用して情報および信号を表してもよいことを理解するだろう。例えば、上の説明を通して参照された、データ、命令、コマンド、情報、信号、ビット、シンボルおよびチップは、電圧、電流、電磁波、磁界または磁気の粒子、光学界または光の粒子、あるいは、これらの何らかの組み合わせにより、表してもよい。
ここでの開示に関連して説明した、さまざまな例示的な論理ブロック、モジュール、回路およびアルゴリズムステップを、電子ハードウェア、コンピュータソフトウェア、あるいは、双方の組み合わせたものとして実現してもよいことを当業者はさらに正しく認識するであろう。ハードウェアおよびソフトウェアのこの交換可能性を明確に示すために、さまざまな例示的なコンポーネント、ブロック、モジュール、回路およびステップを、一般的にこれらの機能性に関して上記で説明した。このような機能性がハードウェアあるいはソフトウェアとして実現されるか否かは、特定の応用およびシステム全体に課せられた設計の制約に依存する。当業者は、それぞれの特定の応用に対して方法を変化させて、説明した機能性を実現してもよいが、このようなインプリメンテーション決定は、本開示の範囲からの逸脱を生じさせるものとして解釈すべきではない。
ここでの開示に関連して説明した、さまざまな例示的な論理ブロック、モジュール、および、回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここで説明した機能を実行するために設計されたこれらの組み合わせで、実現あるいは実行してもよい。汎用プロセッサはマイクロプロセッサであってもよいが、代替実施形態では、プロセッサは、何らかの従来のプロセッサ、制御装置、マイクロ制御装置、または、状態機械であってもよい。プロセッサはまた、コンピューティングデバイスの組み合わせとして、例えば、DSPとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、DSPコアを伴った1つ以上のマイクロプロセッサ、あるいは、このようなコンフィギュレーションの他の何らかのものとして実現してもよい。
ここでの開示に関連して説明した方法またはアルゴリズムのステップは、直接、ハードウェアで、プロセッサにより実行されるソフトウェアモジュールで、あるいは、2つの組み合わせで具現化してもよい。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーブバルディスク、CD−ROM、あるいは、技術的に知られている他の何らかの形態の記憶媒体に存在していてもよい。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるようにプロセッサに結合されている。代替実施形態では、記憶媒体はプロセッサと一体化していてもよい。プロセッサおよび記憶媒体は、ASICに存在していてもよい。ASICは、ユーザ端末に存在していてもよい。代替実施形態では、プロセッサおよび記憶媒体は、ユーザ端末中のディスクリートコンポーネントとして存在してもよい。
1つ以上の例示的な設計では、説明した機能は、ハードウェアで、ソフトウェアで、ファームウェアで、または、これらのものを組み合わせた任意のもので実現してもよい。ソフトウェアで実現した場合、機能は、1つ以上の命令またはコードとして、コンピュータ読取可能媒体上に記憶されてもよく、あるいは、1つ以上の命令またはコードとして、コンピュータ読取可能媒体上に送信されてもよい。コンピュータ読取可能媒体は、1つの場所から別の場所へのコンピュータプログラムの転送を促進する何らかの媒体を含むコンピュータ記憶媒体および通信媒体の双方を含む。記憶媒体は、汎用コンピュータまたは特殊目的コンピュータによりアクセスできる何らかの利用可能な媒体であってもよい。例として、これらに限定されないが、このようなコンピュータ読取可能媒体は、RAM、ROM、EEPROM、CD−ROMまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは、汎用コンピュータまたは特殊目的コンピュータにより、もしくは、汎用プロセッサまたは特殊目的プロセッサによりアクセスでき、命令またはデータ構造の形態で所望のプログラムコード手段を伝送または記憶するために使用できる他の何らかの媒体を含むことができる。また、あらゆる接続は、コンピュータ読取可能媒体と適切に呼ばれる。例えば、ソフトウェアが、同軸ケーブルや、光ファイバケーブルや、撚り対や、デジタル加入者線(DSL)や、あるいは、赤外線、無線、および、マイクロ波のようなワイヤレス技術を使用して、ウェブサイト、サーバ、または、他の遠隔ソースから送信される場合には、同軸ケーブル、光ファイバケーブル、撚り対、DSL、あるいは、赤外線、無線、および、マイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。ここで使用したようなディスク(diskおよびdisc)は、コンパクトディスク(CD)、レーザディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、および、ブルーレイ(登録商標)ディスクを含むが、一般的に、ディスク(disk)は、データを磁気的に再生する一方で、ディスク(disc)は、データをレーザによって光学的に再生する。先のものを組み合わせたものもまた、コンピュータ読取可能媒体の範囲内に含められるべきである。
開示のこれまでの説明は、当業者が開示を製作または使用できるように提供した。開示に対するさまざま改良は、当業者に容易に明らかとなり、ここに定義された一般的な原理は、開示の精神および範囲を逸脱することなく、他のバリエーションに適用されてもよい。したがって、開示は、ここで説明した例および設計に限定されることを意図しているものではなく、ここで開示されている原理および新規の特徴と一致した最も広い範囲に一致させるべきである。
図9は、図1中のワイヤレスネットワーク100における、データおよび輻輳情報の別の例示的な送信を示している。図9中で示されている例では、ノード1は、受信UEに送る輻輳情報を有していてもよく、受信UEに向けたIPパケット中で輻輳情報(例えば、最大データレート)を送ってもよい。ノード2は、ノード1がIPパケットにわたって輻輳情報を送っていることを認識してもよく、アップストリームノードからの輻輳情報を検出してもよい。ノード2は、受信UEに対して、ノード1によりサポートされる最大データレートを取得してもよい。ノード2が、この最大データレートをサポートすることができる場合に、ノード2は、受信UEに向けて輻輳情報を単に転送してもよい。しかしながら、ノード2が、受信UEに対して、より低いデータレートのみをサポートすることができる場合には、ノード2は、アップストリームノード1から受信した輻輳情報を廃棄してもよく、ノード2がサポートすることができる最大データレートを含む新しい輻輳情報を送ってもよい。同様に、ノード3は、アップストリームノード2から輻輳情報を検出し、ノード1およびノード2の双方によりサポートされる最大データレートを取得してもよい。ノード3が、この最大データレートをサポートすることができる場合には、ノード3は、受信UEに向けて輻輳情報を単に転送してもよい。しかしながら、ノード3が、より低いデータレートのみをサポートすることができる場合には、ノード3は、ノード2から受信した輻輳情報を廃棄してもよく、ノード3がサポートすることができる最大データレートを含む新しい輻輳情報を送ってもよい。
1つの設計では、第2のノードに送る輻輳情報は、第2のノードへの通信パス中のすべてのノードによりサポートされる最も低い最大データレートに対応していてもよい。第1のノードは、第1のノードに対してアップストリームである第3のノードから輻輳情報を受信してもよい。第のノードに対して、第のノードによりサポートされる最大データレートが、第のノードに対して、第のノードによりサポートされる最大データレートより大きいまたは等しい場合に、第1のノードは、第2のノードに送る輻輳情報として、受信した輻輳情報を提供してもよい。第2のノードに対して、第1のノードによりサポートされる最大データレートが、第1のノードに対して、第3のノードによりサポートされる最大データレートより小さい場合に、第1のノードは、第2のノードに送る輻輳情報として、新しい輻輳情報を提供してもよい。新しい輻輳情報は、第2のノードに対して、第1のノードによりサポートされる最大データレートを含んでいてもよい。
開示のこれまでの説明は、当業者が開示を製作または使用できるように提供した。開示に対するさまざま改良は、当業者に容易に明らかとなり、ここに定義された一般的な原理は、開示の精神および範囲を逸脱することなく、他のバリエーションに適用されてもよい。したがって、開示は、ここで説明した例および設計に限定されることを意図しているものではなく、ここで開示されている原理および新規の特徴と一致した最も広い範囲に一致させるべきである。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
[1]通信のための方法において、
第1のノードから第2のノードに送る制御情報を決定することと、
前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送ることとを含む方法。
[2]前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む[1]に記載の方法。
[3]前記輻輳情報は、前記第1のノードによりサポートされる最大データレートを含む[2]に記載の方法。
[4]前記送る制御情報を決定することは、
前記第1のノードに対してアップストリームである第3のノードから輻輳情報を受信することと、
前記第1のノードに対して、前記第3のノードによりサポートされる最大データレートが、前記第2のノードに対して、前記第1のノードによりサポートされる最大データレートより大きいまたは等しい場合に、前記第2のノードに送る輻輳情報として、前記受信した輻輳情報を提供することと、
前記第2のノードに対して、前記第1のノードによりサポートされる最大データレートが、前記第1のノードに対して、前記第3のノードによりサポートされる最大データレートより小さい場合に、前記第2のノードに送る輻輳情報として、新しい輻輳情報を提供することとを含む[2]に記載の方法。
[5]前記制御情報を送ることは、インターネットプロトコル(IP)に対する複数のパケットのヘッダ中の明示的輻輳通知(ECN)ビットを使用して、前記輻輳情報を送ることを含む[2]に記載の方法。
[6]前記制御情報を送ることは、
前記制御情報を複数の部分に区分することと、
前記複数のパケットのうちの1つのもののヘッダ中で、前記制御情報の複数の部分のそれぞれを送ることとを含む[1]に記載の方法。
[7]前記制御情報を送ることは、
前記制御情報をエンコードして、コード化したデータを取得することと、
前記コード化したデータを複数の部分に区分することと、
前記複数のパケットのうちの1つのもののヘッダ中で、前記コード化したデータの複数の部分のそれぞれを送ることとを含む[1]に記載の方法。
[8]前記制御情報をエンコードすることは、ブロックコード、または、ファウンテンコード、または、畳み込みコード、または、ターボコード、または、それらの組み合わせに基づいて、前記制御情報をエンコードすることを含む[7]に記載の方法。
[9]前記制御情報を決定することは、前記第2のノードに対するデータフローのための制御情報を決定することを含み、前記制御情報を送ることは、前記データフローに対する複数のパケットのヘッダ中で前記制御情報を送ることを含む[1]に記載の方法。
[10]前記複数のパケット中で前記制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送ることをさらに含む[1]に記載の方法。
[11]前記第1のノードはネットワークエンティティを含み、前記第2のノードは、ユーザ機器(UE)を含む[1]に記載の方法。
[12]通信のための装置において、
第1のノードから第2のノードに送る制御情報を決定する手段と、
前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送る手段とを具備する装置。
[13]前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む[12]に記載の装置。
[14]前記制御情報を送る手段は、
前記制御情報を複数の部分に区分する手段と、
前記複数のパケットのうちの1つのもののヘッダ中で、前記制御情報の複数の部分のそれぞれを送る手段とを備える[12]に記載の装置。
[15]前記制御情報を送る手段は、
前記制御情報をエンコードして、コード化したデータを取得する手段と、
前記コード化したデータを複数の部分に区分する手段と、
前記複数のパケットのうちの1つのもののヘッダ中で、前記コード化したデータの複数の部分のそれぞれを送る手段とを備える[12]に記載の装置。
[16]前記制御情報を決定する手段は、前記第2のノードに対するデータフローのための制御情報を決定する手段を備え、前記制御情報を送る手段は、前記データフローに対する複数のパケットのヘッダ中で前記制御情報を送る手段を備える[12]に記載の装置。
[17]前記複数のパケット中で前記制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送る手段をさらに具備する[12]に記載の装置。
[18]通信のための装置において、
第1のノードから第2のノードに送る制御情報を決定するようにと、
前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送るように構成されている少なくとも1つのプロセッサを具備する装置。
[19]前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む[18]に記載の装置。
[20]前記少なくとも1つのプロセッサは、
前記制御情報を複数の部分に区分するようにと、
前記複数のパケットのうちの1つのもののヘッダ中で、前記制御情報の複数の部分のそれぞれを送るように構成されている[18]に記載の装置。
[21]前記少なくとも1つのプロセッサは、
前記制御情報をエンコードして、コード化したデータを取得するようにと、
前記コード化したデータを複数の部分に区分するようにと、
前記複数のパケットのうちの1つのもののヘッダ中で、前記コード化したデータの複数の部分のそれぞれを送るように構成されている[18]に記載の装置。
[22]前記少なくとも1つのプロセッサは、前記第2のノードに対するデータフローのための制御情報を決定するようにと、前記データフローに対する複数のパケットのヘッダ中で前記制御情報を送るように構成されている[18]に記載の装置。
[23]前記少なくとも1つのプロセッサは、前記複数のパケット中で前記制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送るように構成されている[18]に記載の装置。
[24]コンピュータプログラムプロダクトにおいて、
少なくとも1つのコンピュータに、第1のノードから第2のノードに送る制御情報を決定させるためのコードと、
前記少なくとも1つのコンピュータに、前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送らせるためのコードとを含む一時的でないコンピュータ読取可能媒体を具備するコンピュータプログラムプロダクト。
[25]通信のための方法において、
第1のノードにより第2のノードに向けて送られた複数のパケットを受信することと、
前記第2のノードにおいて前記複数のパケットを処理して、前記複数のパケットのヘッダ中で前記第1のノードにより送られた制御情報を取得することとを含む方法。
[26]前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む[25]に記載の方法。
[27]前記輻輳情報に応答して、前記第2のノードにデータを送る第3のノードのデータレートを減少させるためにメッセージを送ることをさらに含む[26]に記載の方法。
[28]前記複数のパケットを処理することは、前記複数のパケットのそれぞれのヘッダから前記制御情報の一部分を取得することを含む[25]に記載の方法。
[29]前記複数のパケットを処理することは、
前記複数のパケットのそれぞれのヘッダから、コード化したデータの一部分を取得することと、
前記コード化したデータをデコードして、前記制御情報を取得することとを含む[25]に記載の方法。
[30]前記制御情報は、前記第2のノードに対するデータフローのためのものであり、前記データフローに対する複数のパケット中で送られる[25]に記載の方法。
[31]少なくとも1つのパケット中の同期化シーケンスを検出することをさらに含み、前記同期化シーケンスを検出した後に、前記複数のパケットを受信および処理して、前記制御情報を復元する[25]に記載の方法。
[32]通信のための装置において、
第1のノードにより第2のノードに向けて送られた複数のパケットを受信する手段と、
前記第2のノードにおいて前記複数のパケットを処理して、前記複数のパケットのヘッダ中で前記第1のノードにより送られた制御情報を取得する手段とを具備する装置。
[33]前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む[32]に記載の装置。
[34]前記複数のパケットを処理する手段は、前記複数のパケットのそれぞれのヘッダから前記制御情報の一部分を取得する手段を備える[32]に記載の装置。
[35]前記複数のパケットを処理する手段は、
前記複数のパケットのそれぞれのヘッダから、コード化したデータの一部分を取得する手段と、
前記コード化したデータをデコードして、前記制御情報を取得する手段とを備える[32]に記載の装置。
[36]前記制御情報は、前記第2のノードに対するデータフローのためのものであり、前記データフローに対する複数のパケット中で送られる[32]に記載の装置。
[37]少なくとも1つのパケット中の同期化シーケンスを検出する手段をさらに具備し、前記同期化シーケンスを検出した後に、前記複数のパケットを受信および処理して、前記制御情報を復元する[32]に記載の装置。

Claims (37)

  1. 通信のための方法において、
    第1のノードから第2のノードに送る制御情報を決定することと、
    前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送ることとを含む方法。
  2. 前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む請求項1記載の方法。
  3. 前記輻輳情報は、前記第1のノードによりサポートされる最大データレートを含む請求項2記載の方法。
  4. 前記送る制御情報を決定することは、
    前記第1のノードに対してアップストリームである第3のノードから輻輳情報を受信することと、
    前記第1のノードに対して、前記第3のノードによりサポートされる最大データレートが、前記第2のノードに対して、前記第1のノードによりサポートされる最大データレートより大きいまたは等しい場合に、前記第2のノードに送る輻輳情報として、前記受信した輻輳情報を提供することと、
    前記第2のノードに対して、前記第1のノードによりサポートされる最大データレートが、前記第1のノードに対して、前記第3のノードによりサポートされる最大データレートより小さい場合に、前記第2のノードに送る輻輳情報として、新しい輻輳情報を提供することとを含む請求項2記載の方法。
  5. 前記制御情報を送ることは、インターネットプロトコル(IP)に対する複数のパケットのヘッダ中の明示的輻輳通知(ECN)ビットを使用して、前記輻輳情報を送ることを含む請求項2記載の方法。
  6. 前記制御情報を送ることは、
    前記制御情報を複数の部分に区分することと、
    前記複数のパケットのうちの1つのもののヘッダ中で、前記制御情報の複数の部分のそれぞれを送ることとを含む請求項1記載の方法。
  7. 前記制御情報を送ることは、
    前記制御情報をエンコードして、コード化したデータを取得することと、
    前記コード化したデータを複数の部分に区分することと、
    前記複数のパケットのうちの1つのもののヘッダ中で、前記コード化したデータの複数の部分のそれぞれを送ることとを含む請求項1記載の方法。
  8. 前記制御情報をエンコードすることは、ブロックコード、または、ファウンテンコード、または、畳み込みコード、または、ターボコード、または、それらの組み合わせに基づいて、前記制御情報をエンコードすることを含む請求項7記載の方法。
  9. 前記制御情報を決定することは、前記第2のノードに対するデータフローのための制御情報を決定することを含み、前記制御情報を送ることは、前記データフローに対する複数のパケットのヘッダ中で前記制御情報を送ることを含む請求項1記載の方法。
  10. 前記複数のパケット中で前記制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送ることをさらに含む請求項1記載の方法。
  11. 前記第1のノードはネットワークエンティティを含み、前記第2のノードは、ユーザ機器(UE)を含む請求項1記載の方法。
  12. 通信のための装置において、
    第1のノードから第2のノードに送る制御情報を決定する手段と、
    前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送る手段とを具備する装置。
  13. 前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む請求項12記載の装置。
  14. 前記制御情報を送る手段は、
    前記制御情報を複数の部分に区分する手段と、
    前記複数のパケットのうちの1つのもののヘッダ中で、前記制御情報の複数の部分のそれぞれを送る手段とを備える請求項12記載の装置。
  15. 前記制御情報を送る手段は、
    前記制御情報をエンコードして、コード化したデータを取得する手段と、
    前記コード化したデータを複数の部分に区分する手段と、
    前記複数のパケットのうちの1つのもののヘッダ中で、前記コード化したデータの複数の部分のそれぞれを送る手段とを備える請求項12記載の装置。
  16. 前記制御情報を決定する手段は、前記第2のノードに対するデータフローのための制御情報を決定する手段を備え、前記制御情報を送る手段は、前記データフローに対する複数のパケットのヘッダ中で前記制御情報を送る手段を備える請求項12記載の装置。
  17. 前記複数のパケット中で前記制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送る手段をさらに具備する請求項12記載の装置。
  18. 通信のための装置において、
    第1のノードから第2のノードに送る制御情報を決定するようにと、
    前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送るように構成されている少なくとも1つのプロセッサを具備する装置。
  19. 前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む請求項18記載の装置。
  20. 前記少なくとも1つのプロセッサは、
    前記制御情報を複数の部分に区分するようにと、
    前記複数のパケットのうちの1つのもののヘッダ中で、前記制御情報の複数の部分のそれぞれを送るように構成されている請求項18記載の装置。
  21. 前記少なくとも1つのプロセッサは、
    前記制御情報をエンコードして、コード化したデータを取得するようにと、
    前記コード化したデータを複数の部分に区分するようにと、
    前記複数のパケットのうちの1つのもののヘッダ中で、前記コード化したデータの複数の部分のそれぞれを送るように構成されている請求項18記載の装置。
  22. 前記少なくとも1つのプロセッサは、前記第2のノードに対するデータフローのための制御情報を決定するようにと、前記データフローに対する複数のパケットのヘッダ中で前記制御情報を送るように構成されている請求項18記載の装置。
  23. 前記少なくとも1つのプロセッサは、前記複数のパケット中で前記制御情報を送る前に、少なくとも1つのパケット中で同期化シーケンスを送るように構成されている請求項18記載の装置。
  24. コンピュータプログラムプロダクトにおいて、
    少なくとも1つのコンピュータに、第1のノードから第2のノードに送る制御情報を決定させるためのコードと、
    前記少なくとも1つのコンピュータに、前記第2のノードに向けた複数のパケットのヘッダ中で前記制御情報を送らせるためのコードとを含む一時的でないコンピュータ読取可能媒体を具備するコンピュータプログラムプロダクト。
  25. 通信のための方法において、
    第1のノードにより第2のノードに向けて送られた複数のパケットを受信することと、
    前記第2のノードにおいて前記複数のパケットを処理して、前記複数のパケットのヘッダ中で前記第1のノードにより送られた制御情報を取得することとを含む方法。
  26. 前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む請求項25記載の方法。
  27. 前記輻輳情報に応答して、前記第2のノードにデータを送る第3のノードのデータレートを減少させるためにメッセージを送ることをさらに含む請求項26記載の方法。
  28. 前記複数のパケットを処理することは、前記複数のパケットのそれぞれのヘッダから前記制御情報の一部分を取得することを含む請求項25記載の方法。
  29. 前記複数のパケットを処理することは、
    前記複数のパケットのそれぞれのヘッダから、コード化したデータの一部分を取得することと、
    前記コード化したデータをデコードして、前記制御情報を取得することとを含む請求項25記載の方法。
  30. 前記制御情報は、前記第2のノードに対するデータフローのためのものであり、前記データフローに対する複数のパケット中で送られる請求項25記載の方法。
  31. 少なくとも1つのパケット中の同期化シーケンスを検出することをさらに含み、前記同期化シーケンスを検出した後に、前記複数のパケットを受信および処理して、前記制御情報を復元する請求項25記載の方法。
  32. 通信のための装置において、
    第1のノードにより第2のノードに向けて送られた複数のパケットを受信する手段と、
    前記第2のノードにおいて前記複数のパケットを処理して、前記複数のパケットのヘッダ中で前記第1のノードにより送られた制御情報を取得する手段とを具備する装置。
  33. 前記制御情報は、前記第1のノードにおけるトラフィック輻輳を示す輻輳情報を含む請求項32記載の装置。
  34. 前記複数のパケットを処理する手段は、前記複数のパケットのそれぞれのヘッダから前記制御情報の一部分を取得する手段を備える請求項32記載の装置。
  35. 前記複数のパケットを処理する手段は、
    前記複数のパケットのそれぞれのヘッダから、コード化したデータの一部分を取得する手段と、
    前記コード化したデータをデコードして、前記制御情報を取得する手段とを備える請求項32記載の装置。
  36. 前記制御情報は、前記第2のノードに対するデータフローのためのものであり、前記データフローに対する複数のパケット中で送られる請求項32記載の装置。
  37. 少なくとも1つのパケット中の同期化シーケンスを検出する手段をさらに具備し、前記同期化シーケンスを検出した後に、前記複数のパケットを受信および処理して、前記制御情報を復元する請求項32記載の装置。
JP2012517922A 2009-07-02 2010-07-02 複数のパケットにわたる制御情報の送信 Active JP5738855B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US22259009P 2009-07-02 2009-07-02
US61/222,590 2009-07-02
US12/829,168 US8605584B2 (en) 2009-07-02 2010-07-01 Transmission of control information across multiple packets
US12/829,168 2010-07-01
PCT/US2010/040953 WO2011003089A1 (en) 2009-07-02 2010-07-02 Transmission of control information across multiple packets

Publications (2)

Publication Number Publication Date
JP2012532516A true JP2012532516A (ja) 2012-12-13
JP5738855B2 JP5738855B2 (ja) 2015-06-24

Family

ID=42646471

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012517922A Active JP5738855B2 (ja) 2009-07-02 2010-07-02 複数のパケットにわたる制御情報の送信

Country Status (7)

Country Link
US (1) US8605584B2 (ja)
EP (1) EP2449736B1 (ja)
JP (1) JP5738855B2 (ja)
KR (1) KR101450276B1 (ja)
CN (1) CN102474452B (ja)
TW (1) TW201126969A (ja)
WO (1) WO2011003089A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014509476A (ja) * 2011-01-21 2014-04-17 クゥアルコム・インコーポレイテッド ワイヤレスディスプレイのためのユーザ入力バックチャネル
JP6084278B1 (ja) * 2015-11-27 2017-02-22 株式会社Pfu 情報処理装置、方法およびプログラム
US9723359B2 (en) 2011-02-04 2017-08-01 Qualcomm Incorporated Low latency wireless display for graphics
US10911498B2 (en) 2011-01-21 2021-02-02 Qualcomm Incorporated User input back channel for wireless displays

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
US9264248B2 (en) 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
WO2011052590A1 (ja) * 2009-10-28 2011-05-05 日本電気株式会社 リモート型携帯通信システム、方法及びプログラム
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
US8982694B2 (en) * 2010-09-01 2015-03-17 Telefonaktiebolaget L M Ericsson (Publ) Localized congestion exposure
EP2628354A4 (en) * 2010-10-12 2017-01-25 Samsung Electronics Co., Ltd Method and apparatus of communicating machine type communication data over an iu interface in a universal mobile telecommunications system
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US20130013318A1 (en) 2011-01-21 2013-01-10 Qualcomm Incorporated User input back channel for wireless displays
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US8724467B2 (en) * 2011-02-04 2014-05-13 Cisco Technology, Inc. System and method for managing congestion in a network environment
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
EP2745499B1 (en) * 2011-08-17 2019-03-27 Telefonaktiebolaget LM Ericsson (publ) Mechanism for dynamic signaling of encoder capabilities
US9509805B2 (en) 2011-12-01 2016-11-29 Telefonaktiebolaget Lm Ericsson (Publ) Reduction of packet header compression overhead due to high ECN rate
CN103152124B (zh) * 2011-12-07 2017-06-20 华为技术有限公司 一种单播通信方法、装置及系统
US9654399B2 (en) * 2011-12-28 2017-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices in an IP network for congestion control
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
CN102694791B (zh) * 2012-04-17 2014-10-29 清华大学 基于喷泉码的实时tcp传输方法
CN103580773A (zh) * 2012-07-18 2014-02-12 中兴通讯股份有限公司 数据帧的传输方法及装置
CN103532837A (zh) * 2012-09-26 2014-01-22 深圳市友讯达科技发展有限公司 节点信息收集方法及网络系统、节点
KR102066130B1 (ko) * 2013-01-18 2020-02-11 삼성전자주식회사 무선 통신 시스템에서 트래픽 제어 방법 및 장치
US10813043B2 (en) 2014-05-16 2020-10-20 Huawei Technologies Co., Ltd. System and method for communicating wireless transmissions spanning both licensed and un-licensed spectrum
US10873941B2 (en) * 2014-05-16 2020-12-22 Huawei Technologies Co., Ltd. System and method for joint transmission over licensed and unlicensed bands using fountain codes
US10548071B2 (en) 2014-05-16 2020-01-28 Huawei Technologies Co., Ltd. System and method for communicating traffic over licensed or un-licensed spectrums based on quality of service (QoS) constraints of the traffic
US10536386B2 (en) 2014-05-16 2020-01-14 Huawei Technologies Co., Ltd. System and method for dynamic resource allocation over licensed and unlicensed spectrums
JP6398728B2 (ja) * 2014-07-11 2018-10-03 ソニー株式会社 情報処理装置および情報処理方法
EP3192299B1 (en) * 2014-09-10 2020-01-15 Telefonaktiebolaget LM Ericsson (publ) Explicit congestion notification marking of user traffic
US10015207B2 (en) * 2014-10-22 2018-07-03 T-Mobile Usa, Inc. Dynamic rate adaptation during real-time LTE communication
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
CN106302266B (zh) * 2015-05-27 2019-10-15 华为技术有限公司 信息传输方法、信息获取方法、发送端设备及接收端设备
US10044374B2 (en) * 2015-07-30 2018-08-07 Quantum Corporation Adaptive erasure codes
CN106100697B (zh) * 2016-06-07 2021-07-06 中国电力科学研究院 低压电力线载波通信系统和方法
US11470502B2 (en) * 2017-12-22 2022-10-11 Telefonaktiebolaget Lm Ericsson (Publ) Congestion notification by data packet from intermediate node
KR102054998B1 (ko) * 2018-10-08 2020-01-22 에스케이 텔레콤주식회사 대역내 원격 모니터링을 지원하기 위한 방법 및 장치
CN111107016B (zh) * 2018-10-25 2023-04-07 深圳市中兴微电子技术有限公司 一种网络拥塞控制方法、装置、芯片及存储介质
EP3949290A4 (en) 2019-05-23 2023-05-31 Hewlett Packard Enterprise Development LP SYSTEMS AND METHODS FOR ADAPTIVE ROUTING IN THE PRESENCE OF PERSISTENT FLOW
CN113518037A (zh) * 2020-04-09 2021-10-19 华为技术有限公司 一种拥塞信息同步的方法以及相关装置
CN114979002A (zh) * 2021-02-23 2022-08-30 华为技术有限公司 一种流量控制方法和流量控制装置
CN114885440B (zh) * 2022-07-08 2022-11-08 荣耀终端有限公司 多个音频设备间语音通话的方法、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001168871A (ja) * 1999-12-06 2001-06-22 Nippon Telegr & Teleph Corp <Ntt> データ転送方式
JP2005064597A (ja) * 2003-08-14 2005-03-10 Ntt Docomo Inc 送信装置、中継装置およびプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0200310B1 (en) * 1985-05-01 1993-08-11 General Instrument Corporation Direct broadcast satellite signal transmission system
CA2237264A1 (en) 1998-05-08 1999-11-08 Northern Telecom Limited Receiver based congestion control
US6633585B1 (en) 1999-08-13 2003-10-14 International Business Machines Corporation Enhanced flow control in ATM edge switches
GB0407144D0 (en) * 2004-03-30 2004-05-05 British Telecomm Networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001168871A (ja) * 1999-12-06 2001-06-22 Nippon Telegr & Teleph Corp <Ntt> データ転送方式
JP2005064597A (ja) * 2003-08-14 2005-03-10 Ntt Docomo Inc 送信装置、中継装置およびプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6013026343; Xiaolong Li: 'Distributed ECN-Based Congestion Control' Communications, 2009. ICC '09. IEEE International Conference on , 20090614, 1-6頁, IEEE *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014509476A (ja) * 2011-01-21 2014-04-17 クゥアルコム・インコーポレイテッド ワイヤレスディスプレイのためのユーザ入力バックチャネル
US10911498B2 (en) 2011-01-21 2021-02-02 Qualcomm Incorporated User input back channel for wireless displays
US9723359B2 (en) 2011-02-04 2017-08-01 Qualcomm Incorporated Low latency wireless display for graphics
JP6084278B1 (ja) * 2015-11-27 2017-02-22 株式会社Pfu 情報処理装置、方法およびプログラム
US10263975B2 (en) 2015-11-27 2019-04-16 Pfu Limited Information processing device, method, and medium

Also Published As

Publication number Publication date
KR20120047929A (ko) 2012-05-14
CN102474452A (zh) 2012-05-23
EP2449736A1 (en) 2012-05-09
US8605584B2 (en) 2013-12-10
WO2011003089A1 (en) 2011-01-06
KR101450276B1 (ko) 2014-10-13
US20110158096A1 (en) 2011-06-30
JP5738855B2 (ja) 2015-06-24
EP2449736B1 (en) 2018-03-21
CN102474452B (zh) 2017-09-01
TW201126969A (en) 2011-08-01

Similar Documents

Publication Publication Date Title
JP5738855B2 (ja) 複数のパケットにわたる制御情報の送信
KR100989529B1 (ko) 무선 통신 시스템에서 향상된 업링크로 오버헤드 감소를 위한 방법 및 장치
US8437306B2 (en) Layer 2 tunneling of data during handover in a wireless communication system
CN107508655B (zh) 一种自适应端到端网络编码传输方法
JP5437216B2 (ja) 無線通信におけるリンク制御のための方法および装置
US9253608B2 (en) Wireless reliability architecture and methods using network coding
US7301928B2 (en) Wireless packet transfer apparatus and method
FI105734B (fi) Automaattinen uudelleenlähetys
JP5425397B2 (ja) 適応型前方誤り訂正を行う装置及び方法
US8276035B1 (en) High performance digital communications resiliency in a roamable virtual private network
US9049017B2 (en) Efficient TCP ACK prioritization in wireless networks
US8958375B2 (en) Framing for an improved radio link protocol including FEC
EP2266242B1 (en) Method and apparatus for link control in a wireless communication system
JP2010536264A (ja) 無線通信システムにおけるハンドオーバー中の順序正しいデータ配信
US20100058153A1 (en) Chained checksum error correction mechanism to improve tcp performance over network with wireless links
KR20040023568A (ko) 패킷 기반 통신 시스템을 위한 순방향 에러 보정 시스템및 방법
EP3643109A1 (en) Large media access control service data unit (msdu) delivery
JP2006245834A (ja) Ip網の通信装置
US9307441B1 (en) Systems and methods of transferring information to a wireless device
Sarwar et al. eCMT-SCTP: Improving performance of multipath SCTP with erasure coding over lossy links
WO2017200435A1 (en) Radio base station with tcp ack awareness
Huang et al. Principles of FECs with evaluating different types of FEC used in the Internet and wireless networks

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130527

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130604

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130731

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130807

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131203

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20140204

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140604

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20140624

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20140905

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150422

R150 Certificate of patent or registration of utility model

Ref document number: 5738855

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250