(57)【特許請求の範囲】
【請求項１】
無線ネットワーク内のネットワーク輻輳管理を可能にするための、第１のネットワークノードが実行する方法であって、
ユーザパケットをカプセル化してトンネルで第２のネットワークノードに送信するステップと、ここで前記カプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記トンネルについての輻輳量情報を前記第２のネットワークノードから受信するステップと、を有し、
さらに、
前記受信した前記トンネルについての輻輳量情報に基づいて、前記トンネルについてのネットワーク輻輳ポリシングを適用するステップ、もしくは
前記受信した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記受信した前記トンネルについての輻輳量情報を第３のネットワークノードに転送するステップ、
の１つを有する、方法。
【請求項２】
前記トンネルについてのネットワーク輻輳ポリシングを適用する前記ステップが、前記第２のネットワークノード宛てのカプセル化されたユーザパケットが破棄される破棄確率にさらに基づく、請求項１に記載の方法。
【請求項３】
前記受信した前記トンネルについての輻輳量情報が、前記輻輳量情報が前記第２のネットワークノードから出発した時刻の可能な範囲で最良の近似値として規定される出口タイムスタンプを有し、前記破棄確率が前記出口タイムスタンプに基づく、請求項２に記載の方法。
【請求項４】
無線ネットワーク内のネットワーク輻輳管理を可能にするための、第２のネットワークノードが実行する方法であって、
第１のネットワークノードから、カプセル化されたユーザパケットをトンネルで受信するステップと、ここで前記受信するカプセル化されたユーザパケットのそれぞれは、前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記トンネルについてのバイト損失量を検出するための前記情報に基づいて、前記トンネルについての輻輳量情報を決定するステップと、ここで、前記トンネルについてのバイト損失量は、先行するカプセル化されたユーザパケットのバイトシーケンス番号に、前記先行するカプセル化されたユーザパケットのユーザペイロードサイズを加えたものよりも、受信したバイトシーケンス番号が大きい場合に検出され、
前記決定した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能にするために、前記決定した前記トンネルについての輻輳量情報を前記第１のネットワークノードに送信するステップと、を有する、方法。
【請求項５】
前記受信するカプセル化されたユーザパケットのそれぞれは、前記トンネルについてのバイト輻輳量に関する情報をさらに有し、前記トンネルについての前記輻輳量情報が、前記トンネルについてのバイト輻輳量に関する前記情報にさらに基づく、請求項４に記載の方法。
【請求項６】
前記トンネルについてのバイト輻輳量に関する前記情報は、前記トンネルについてのネットワーク輻輳を示す、インターネットプロトコル(IP)ヘッダ内に提供される明示的輻輳通知(ECN)マーキングをさらに有する受信ユーザパケットを有する、請求項５に記載の方法。
【請求項７】
無線ネットワーク内のネットワーク輻輳管理を可能にするように構成された第１のネットワークノードであって、前記第１のネットワークノードはユーザパケットをカプセル化してトンネルで第２のネットワークノードへ送信するように構成され、前記カプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、また前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記第１のネットワークノードは、前記トンネルについての輻輳量情報を前記第２のネットワークノードから受信するように構成され、
前記第１のネットワークノードは、
前記受信した前記トンネルについての輻輳量情報に基づいて、前記トンネルについてのネットワーク輻輳ポリシングを適用するように、もしくは
前記受信した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記受信した前記トンネルについての輻輳量情報を第３のネットワークノードに転送するように、構成される、第１のネットワークノード。
【請求項８】
前記第１のネットワークノードは、前記第２のネットワークノード宛てのカプセル化されたユーザパケットが破棄される破棄確率に基づいて、前記トンネルについてのネットワーク輻輳ポリシングを適用するようにさらに構成される、請求項７に記載の第１のネットワークノード。
【請求項９】
前記受信した前記トンネルについての輻輳量情報が、前記輻輳量情報が前記第２のネットワークノードから出発した時刻の可能な範囲で最良の近似値として規定される出口タイムスタンプを有し、前記第１のネットワークノードが、前記出口タイムスタンプに基づいて前記破棄確率を決定するように構成される、請求項８に記載の第１のネットワークノード。
【請求項１０】
前記第１のネットワークノードが、
エヴォルブドNode B(eNodeB)、
Node B、
アクセスポイント(AP)、
在圏ゲートウェイ(SGW)、
無線ネットワークコントローラ(RNC)、
アクセスコントローラ(AC)、
トンネル対応ルータ、
仮想化ネットワーク機能(VNF)、
のうちの１つである、請求項７から請求項９のいずれか１項に記載の第１のネットワークノード。
【請求項１１】
前記第１のネットワークノードが、プロセッサとメモリとを有し、前記メモリは前記プロセッサによって実行可能な命令を有し、前記命令によって前記プロセッサが、
トンネルで第２のネットワークノードに送信するためにユーザパケットをカプセル化し、ここで前記カプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記第２のネットワークノードから受信する、前記トンネルについての輻輳量情報を読み取り、さらに、
前記受信した前記トンネルについての輻輳量情報に基づいて、前記トンネルについてのネットワーク輻輳ポリシングを適用する、もしくは
前記受信した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記受信した前記トンネルについての輻輳量情報を第３のネットワークノードに転送するために用意する、
ように動作する、請求項７から請求項１０のいずれか１項に記載の第１のネットワークノード。
【請求項１２】
前記第１のネットワークノードは通信回路を有し、前記通信回路は、カプセル化されたユーザパケットをトンネルで第２のネットワークノードに送信し、ここで前記カプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、前記トンネルについての輻輳量情報を前記第２のネットワークノードから受信し、さらに、必要に応じて、前記受信した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能にするため、前記受信した前記トンネルについての輻輳量情報を第３のネットワークノードに転送する、ように構成される、請求項７から請求項１１のいずれか１項に記載の第１のネットワークノード。
【請求項１３】
無線ネットワーク内のネットワーク輻輳管理を可能にするための、第１のネットワークノードであって、
ユーザパケットをトンネルで第２のネットワークノードに送信するためにカプセル化するためのカプセル化／送信モジュールと、ここで前記カプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記第２のネットワークノードから受信した前記トンネルについての輻輳量情報を読み取るための受信モジュールと、を有し、
さらに、
前記受信した前記トンネルについての輻輳量情報に基づいて、前記トンネルについてのネットワーク輻輳ポリシングを適用するためのポリシングモジュールと、
前記受信した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記受信した前記トンネルについての輻輳量情報を第３のネットワークノードに転送するために用意するための転送モジュールと、の少なくとも一方と、を有する第１のネットワークノード。
【請求項１４】
無線ネットワーク内のネットワーク輻輳管理を可能にするように構成された第２のネットワークノードであって、前記第２のネットワークノードはカプセル化されたユーザパケットをトンネルで第１のネットワークノードから受信するように構成され、前記受信するカプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記第２のネットワークノードは、前記トンネルについてのバイト損失量を検出するための前記情報に基づいて、前記トンネルについての輻輳量情報を決定するように構成され、
前記第２のネットワークノードは、前記決定した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能にするために、前記決定した前記トンネルについての輻輳量情報を前記第１のネットワークノードに送信するように構成され、前記第２のネットワークノードは、先行するカプセル化されたユーザパケットのバイトシーケンス番号に、前記先行するカプセル化されたユーザパケットのユーザペイロードサイズを加えたものよりも、受信したバイトシーケンス番号が大きい場合に前記トンネルについてのバイト損失量を検出するように構成される、第２のネットワークノード。
【請求項１５】
前記受信したカプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト輻輳量に関する情報をさらに有し、前記第２のネットワークノードは、前記トンネルについての前記輻輳量情報を、前記トンネルについてのバイト輻輳量に関する前記情報にさらに基づいて決定するように構成される、請求項１４に記載の第２のネットワークノード。
【請求項１６】
前記トンネルについてのバイト輻輳量に関する前記情報は、前記トンネルについてのネットワーク輻輳を示す、インターネットプロトコル(IP)ヘッダ内に提供される明示的輻輳通知(ECN)マーキングをさらに有する受信ユーザパケットを有する、請求項１５に記載の第２のネットワークノード。
【請求項１７】
前記第２のネットワークノードが、
エヴォルブドNode B(eNodeB)、
NodeB、
アクセスポイント(AP)、
在圏ゲートウェイ(SGW)、
無線ネットワークコントローラ(RNC)、
アクセスコントローラ(AC)、
トンネル対応ルータ、
仮想化ネットワーク機能(VNF)、
の１つである、請求項１４から請求項１６のいずれか１項に記載の第２のネットワークノード。
【請求項１８】
前記第２のネットワークノードが、プロセッサとメモリとを有し、前記メモリは前記プロセッサによって実行可能な命令を有し、前記命令によって前記プロセッサが、
第１のネットワークノードからトンネルで受信されたカプセル化されたユーザパケットを読み取り、ここで前記受信されたカプセル化されたユーザパケットのそれぞれは、前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記トンネルについてのバイト損失量を検出するための前記情報に基づいて、前記トンネルについての輻輳量情報を決定し、前記トンネルについてのバイト損失量は、先行するカプセル化されたユーザパケットのバイトシーケンス番号に、前記先行するカプセル化されたユーザパケットのユーザペイロードサイズを加えたものよりも、受信したバイトシーケンス番号が大きい場合に検出され、
前記決定された前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記決定された前記トンネルについての輻輳量情報を前記第１のネットワークノードに送信するために用意する、ように動作する、請求項１４から請求項１７のいずれか１項に記載の第２のネットワークノード。
【請求項１９】
前記第２のネットワークノードは通信回路を有し、前記通信回路は、カプセル化されたユーザパケットをトンネルで第１のネットワークノードから受信し、ここで前記カプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、前記決定された前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能にするために前記トンネルについての輻輳量情報を前記第１のネットワークノードに送信する、ように構成され、ここで前記トンネルについての前記輻輳量情報は前記トンネルについてのバイト損失量を検出するための前記情報に基づいて決定され、ここで、前記トンネルについてのバイト損失量は、先行するカプセル化されたユーザパケットのバイトシーケンス番号に、前記先行するカプセル化されたユーザパケットのユーザペイロードサイズを加えたものよりも、受信したバイトシーケンス番号が大きい場合に検出される、請求項１４から請求項１８のいずれか１項に記載の第２のネットワークノード。
【請求項２０】
無線ネットワーク内のネットワーク輻輳管理を可能にするための、第２のネットワークノードであって、
第１のネットワークノードからトンネルで受信されたカプセル化されたユーザパケットを読み取るための受信モジュールと、ここで前記受信されたカプセル化されたユーザパケットのそれぞれは、前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記トンネルについてのバイト損失量を検出するための前記情報に基づいて、前記トンネルについての輻輳量情報を決定するための決定モジュールと、ここで、前記トンネルについてのバイト損失量は、先行するカプセル化されたユーザパケットのバイトシーケンス番号に、前記先行するカプセル化されたユーザパケットのユーザペイロードサイズを加えたものよりも、受信したバイトシーケンス番号が大きい場合に検出され、
前記決定された前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記決定された前記トンネルについての輻輳量情報を前記第１のネットワークノードに送信するために用意するための送信モジュールと、を有する、第２のネットワークノード。
【請求項２１】
前記受信したカプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト輻輳量に関する情報をさらに有し、前記決定モジュールは、前記トンネルについての前記輻輳量情報を、前記トンネルについてのバイト輻輳量に関する前記情報にさらに基づいて決定する、請求項２０に記載の第２のネットワークノード。
【請求項２２】
命令を有するコンピュータプログラムであって、前記命令は少なくとも１つのプロセッサによって実行される際、１つ以上のプロセッサに、
トンネルで第１のネットワークノードから第２のネットワークノードに送信するためにユーザパケットをカプセル化し、ここで前記カプセル化されたユーザパケットのそれぞれは前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記第１のネットワークノードで受信される、前記トンネルについての輻輳量情報を読み取り、さらに、
前記受信した前記トンネルについての輻輳量情報に基づいて、前記トンネルについてのネットワーク輻輳ポリシングを適用する、もしくは、
前記受信した前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記受信した前記トンネルについての輻輳量情報を第３のネットワークノードに転送するために用意する、ように動作させる、コンピュータプログラム。
【請求項２３】
命令を有するコンピュータプログラムであって、前記命令は少なくとも１つのプロセッサによって実行される際、１つ以上のプロセッサに、
第１のネットワークノードからトンネルで送信され、第２のネットワークノードで受信された、カプセル化されたユーザパケットを読み取り、ここで前記受信されたカプセル化されたユーザパケットのそれぞれは、前記トンネルについてのバイト損失量を検出するための情報を有し、前記トンネルについてのバイト損失量を検出するための前記情報は、前記トンネルについての、前記カプセル化されたユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号を有し、
前記トンネルについてのバイト損失量を検出するための前記情報に基づいて、前記トンネルについての輻輳量情報を決定し、ここで、前記トンネルについてのバイト損失量は、先行するカプセル化されたユーザパケットのバイトシーケンス番号に、前記先行するカプセル化されたユーザパケットのユーザペイロードサイズを加えたものよりも、受信したバイトシーケンス番号が大きい場合に検出され、
前記決定された前記トンネルについての輻輳量情報に基づく前記トンネルについてのネットワーク輻輳ポリシングを可能とするために、前記決定された前記トンネルについての輻輳量情報を前記第２のネットワークノードから前記第１のネットワークノードに送信するために用意する、ように動作させる、コンピュータプログラム。
【請求項２４】
前記受信されたカプセル化されたユーザパケットのそれぞれは、前記トンネルについてのバイト輻輳量に関する情報をさらに有し、前記トンネルについての前記輻輳量情報が、前記トンネルについてのバイト輻輳量に関する前記情報にさらに基づく、請求項２３に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
提案される技術は概してトランスポートネットワークに関し、特にはネットワーク輻輳管理に関する。
【背景技術】
【０００２】
トランスポートネットワークはリソースが限られており、帯域幅の使用を予測および管理することは困難である。ネットワークが収容可能な量よりも多くのパケットまたはデータが送信されると、ネットワーク輻輳が発生しうる。ネットワークは固定帯域幅または固定パケット送信レートといった固定容量を有するのが一般的である。従来、そのような輻輳が生じているネットワークは単純にパケットを廃棄することができる。しかし、パケットの廃棄は、例えば廃棄されたパケットの再送信の原因になるといった、ネットワーク輻輳をさらに悪化させたり長引かせたりしうるいくつかの短所を有しうる。
【０００３】
Ｗｉ−Ｆｉおよび４Ｇ無線アクセスネットワークの配備により、（バックホールネットワークとしても知られる）モバイルトランスポートネットワークが、移動加入者およびサービスエンドポイント（例えばインターネット）との間の完全パスに沿った最低帯域幅として規定される帯域幅ボトルネック(BB)になってきている。モバイルネットワーク内のボトルネック帯域幅はロングタームエヴォリューション(LTE)eNodeB(eNB)のラストホップまたはWi-Fiアクセスポイント(AP)、あるいはその近傍に位置することが多い。
【０００４】
インターネットトラフィックは、現在および将来にわたって、モバイルネットワークを通じて搬送されるトラフィックの大半を占め続けるであろう。そのようなトラフィックは、非保証ビットレート(GBR)汎用パケット無線サービス(GPRS)トンネリングプロトコルユーザ(GTP-U)［文献１］トンネル、無線アクセスポイントのＷｉ−Ｆｉ制御およびプロビジョニング(CAPWAP)［文献２］、または汎用ルーティングカプセル化(GRE)［文献３］トンネルとして知られるデフォルトベアラで、通常は優先度の低いクラスで搬送される。無線接続性は３００Ｍｂｐｓを超えようとしており、従って無線アクセスノードとモバイルコアネットワークとの間で利用可能なトランスポートネットワークリソースの大部分または全てを一人の加入者が消費することが可能になる。
【０００５】
今日、パケット損失、遅延、または平均利用率が所定の閾値を超えた場合、一部のモバイルオペレータはトラフィックの管理を必ずしも試みることなくより多くの容量を購入している。他のオペレータはレートエンフォースメントを用いるとともにピーク時間でのヘビーユーザ数を制限することを好むが、それでも結局は利用率が高まるとより多くの容量を購入している。場合により、バックホール容量は必要以上の大きさになり得、インターネットトラフィックを搬送するのに必要なコストより多くのコストを発生させる。
【０００６】
現在の無線アクセス技術（Wi-Fiおよび4G）はモバイルトランスポートネットワークの利用可能容量を動的に考慮せず、また利用可能なバックホール容量がどのようにユーザ間で共有されているかを知らない。従って、ネットワーク輻輳を回避するため、ネットワーク容量を管理するためのより効率的な手順に対する一般的な必要性が存在する。
【発明の概要】
【０００７】
無線通信ネットワーク内のネットワーク輻輳管理のための方法および無線ネットワークノードを提供することを目的とする。
【０００８】
この目的および他の目的は、提案される技術の実施形態によって達成される。
【０００９】
実施形態の一態様は、無線ネットワーク内のネットワーク輻輳管理を可能にするための、第１のネットワークノードによって実行される方法に関する。方法は、ユーザパケットをカプセル化してトンネルで第２のネットワークノードへ送信するステップを有し、ユーザパケットのそれぞれはそのトンネルについてのバイト損失量に関する情報を有する。方法はさらに、トンネルについての輻輳量情報を第２のネットワークノードから受信するステップを有する。方法はまた、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するステップか、受信した、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングの適用を可能とするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードへ転送するステップ、のいずれかを有する。
【００１０】
実施形態の別の態様は、無線ネットワーク内のネットワーク輻輳管理を可能にするために第２のネットワークノードによって実行される方法に関する。方法は、カプセル化されたユーザパケットを第１のネットワークノードからトンネルで受信するステップを有し、受信するユーザパケットのそれぞれは、トンネルについてのバイト損失量に関する情報を有する。方法はさらに、トンネルについての輻輳量情報を、トンネルについてのバイト損失量に関する情報に基づいて決定するステップを有する。方法はまた、決定した、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを可能にするために、決定した、トンネルについての輻輳量情報を第１のネットワークノードに送信するステップを有する。
【００１１】
実施形態のさらに別の態様は、無線ネットワーク内のネットワーク輻輳を管理するために第３のネットワークノードによって実行される方法に関する。方法は、トンネルについての輻輳量情報を第１のネットワークノードから受信するステップを有し、受信する輻輳量情報は、第２のネットワークノードによって決定され、第１のネットワークノードによって転送されている。方法はさらに、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するステップを有する。
【００１２】
実施形態のさらに別の態様は、無線ネットワーク内のネットワーク輻輳管理を可能にするように構成された第１のネットワークノードに関する。第１のネットワークノードはユーザパケットをカプセル化してトンネルで第２のネットワークノードへ送信するように構成され、ユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有する。第１のネットワークノードはさらに、トンネルについての輻輳量情報を第２のネットワークノードから受信するように構成される。第１のネットワークノードはまた、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するか、あるいは、受信した、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを可能にするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードに転送するように構成される。
【００１３】
実施形態のさらに別の態様は、無線ネットワーク内のネットワーク輻輳管理を可能にするための第１のネットワークノードに関する。第１のネットワークノードは、ユーザパケットをトンネルで第２のネットワークノードに送信するためにカプセル化するためのカプセル化／送信モジュールを有し、ユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有する。第１のネットワークノードはさらに、第２のネットワークノードから受信した、トンネルについての輻輳量情報を読み取るための受信モジュールを有する。第１のネットワークノードはまた、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するポリシングモジュール、および／または、受信した、トンネルついての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを可能にするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードに転送するために用意するための転送モジュールを有することができる。
【００１４】
実施形態のさらに別の態様は、無線ネットワーク内のネットワーク輻輳管理を可能にするための第２のネットワークノードに関する。第２のネットワークノードは、カプセル化されたユーザパケットをトンネルで第１のネットワークノードから受信するように構成される。第２のネットワークノードはさらに、トンネルについてのバイト損失量に関する情報に基づいて、トンネルについての輻輳量情報を決定するように構成される。第２のネットワークノードはまた、決定した、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを可能にするために、決定した、トンネルについての輻輳量情報を第１のネットワークノードに送信するように構成される。
【００１５】
実施形態のさらに別の態様は、無線ネットワーク内のネットワーク輻輳管理を可能にするための第２のネットワークノードに関する。第２のネットワークノードは、第１のネットワークノードからトンネルで受信した、カプセル化されたユーザパケットを読み取るように構成された受信モジュールを有し、受信したユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有している。第２のネットワークノードはさらに、トンネルについてのバイト損失量に関する情報に基づいてトンネルについての輻輳量情報を決定するための決定モジュールを有する。第２のネットワークノードはまた、決定された、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを可能にするために、決定された、トンネルについての輻輳量情報を第１のネットワークノードに送信するために準備するための送信モジュールを有する。
【００１６】
実施形態のさらに別の態様は、無線ネットワーク内のネットワーク輻輳を管理するように構成された第３のネットワークノードに関する。第３のネットワークノードは、トンネルについての輻輳量情報を第１のネットワークノードから受信するように構成され、受信する輻輳量情報は第２のネットワークノードによって決定され、第１のネットワークノードによって転送されている。第３のネットワークノードはさらに、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するように構成される。
【００１７】
実施形態のさらに別の態様は、無線ネットワーク内のネットワーク輻輳を管理するための第３のネットワークノードに関する。第３のネットワークノードは、第１のネットワークノードから受信した、トンネルについての輻輳量情報を読み取るための受信モジュールを有し、受信した輻輳量情報は第２のネットワークノードによって決定され、第１のネットワークノードによって転送されている。第３のネットワークノードはさらに、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するためのポリシングモジュールを有する。
【００１８】
実施形態のさらに別の態様は、命令を有するコンピュータプログラムに関し、命令は、少なくとも１つのプロセッサによって実行された際に、１つ以上のプロセッサに、トンネルで第１のネットワークノードから第２のネットワークノードへ送信するためにユーザパケットをカプセル化し、ここでユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有し、第１のネットワークノードで受信された、トンネルについての輻輳量情報を読み出し、さらに、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するか、その代わりに、受信した、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを可能にするために第３のネットワークノードに転送するために、受信した、トンネルについての輻輳量情報を準備する、ようにさせる。
【００１９】
実施形態のさらに別の態様は、命令を有するコンピュータプログラムに関し、命令は、少なくとも１つのプロセッサによって実行された際に、１つ以上のプロセッサに、トンネルで第１のネットワークノードから送信され、第２のネットワークノードで受信された、カプセル化されたユーザパケットを読み取り、ここで各ユーザパケットはトンネルについてのバイト損失量に関する情報を有し、トンネルについてのバイト損失量情報に基づいて、トンネルについての輻輳量情報を決定し、決定した、トンネルについての輻輳量情報に基づく、トンネルについてのネットワーク輻輳ポリシングを可能にするために、決定した、トンネルについての輻輳量情報を、第２のネットワークノードから第１のネットワークノードに転送するために準備する、ようにさせる。
【００２０】
実施形態のさらに別の態様は、命令を有するコンピュータプログラムに関し、命令は、少なくとも１つのプロセッサによって実行された際に、１つ以上のプロセッサに、第１のネットワークノードから受信した、トンネルについての輻輳量情報を読み出し、ここで、受信した輻輳量情報は第２のネットワークノードで決定され、第１のネットワークノードによって転送されており、さらに、受信した、トンネルについての輻輳量情報に基づいてトンネルについてのネットワーク輻輳ポリシングを適用する、ようにさせる。
【００２１】
実施形態のさらに別の態様は、上述したコンピュータプログラムのいずれかを有するキャリアに関し、キャリアは、電子信号、光信号、電磁気信号、磁気信号、電気信号、無線信号、マイクロ波信号、またはコンピュータ読み取り可能な記憶媒体の１つである。
【００２２】
提案する方法の利点の一部は以下の通りである。
・  UE端末およびインターネットエンドポイントまたは他のトランスポートプロトコル(例えばTCP)の実装とは独立した輻輳管理手法であること。
・  モバイルネットワークの性能に負のインパクトを与えることなく、既存のノードで実施される簡単な機能であること。
・  短いフィードバックを用いて、輻輳により迅速に対応すること。
・  無線アクセス技術および／またはサービスミックスに依存してモバイルオペレータによって制御される、一貫性のある輻輳量ポリシであること。
【００２３】
他の利点は詳細な説明を読みことによって理解されるであろう。
【００２４】
実施形態と、そのさらなる目的および利点は、以下の説明を添付図面とともに参照することによって最もよく理解されるであろう。
【図面の簡単な説明】
【００２５】
【図１ａ】いくつかの無線ネットワーク内のネットワークノードと接続とを模式的に示す図である。
【図１ｂ】いくつかの無線ネットワーク内のネットワークノードと接続とを、トンネル輻輳量ポリシングに関する情報の交換とともに模式的に示す図である。
【図１ｃ】実施形態に係る、無線ネットワーク内のネットワークノードと接続とを模式的に示す図である。
【図２】実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするために第１のネットワークノードで実行される方法の例を示す模式的なフローチャートである。
【図３】実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするために第２のネットワークノードで実行される方法の例を示す模式的なフローチャートである。
【図４】実施形態に係る、無線ネットワーク内のネットワーク輻輳を管理するために第３のネットワークノードで実行される方法の例を示す模式的なフローチャートである。
【図５ａ】実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするように構成された第１のネットワークノードの例を示す模式図である。
【図５ｂ】実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするように構成された第２のネットワークノードの例を示す模式図である。
【図５ｃ】実施形態に係る、無線ネットワーク内のネットワーク輻輳を管理するように構成された第３のネットワークノードの例を示す模式図である。
【図６ａ】代替実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするように動作可能な第１のネットワークノードの例を示す模式図である。
【図６ｂ】代替実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするように動作可能な第２のネットワークノードの例を示す模式図である。
【図６ｃ】代替実施形態に係る、無線ネットワーク内のネットワーク輻輳を管理するように動作可能な第３のネットワークノードの例を示す模式図である。
【図７ａ】代替実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするための第１のネットワークノードの例を示す模式的なブロック図である。
【図７ｂ】代替実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするための第２のネットワークノードの例を示す模式的なブロック図である。
【図７ｃ】代替実施形態に係る、無線ネットワーク内のネットワーク輻輳を管理するための第３のネットワークノードの例を示す模式的なブロック図である。
【図８】従来技術に係るGTP−Uヘッダを示す図である。
【図９】実施形態に係る、BSN情報を搬送するための新規なGTP−Uヘッダを示す図である。
【図１０】別の実施形態に係る、BSN情報を搬送するための新規なGTP−Uヘッダを示す図である。
【図１１】従来技術に係る、現CAPWAPヘッダを示す図である。
【図１２】実施形態に係る、BSN情報を搬送するための新規なCAPWAPヘッダを示す図である。
【図１３】従来技術に係る、現GREヘッダを示す図である。
【図１４】実施形態に係る、BSN情報を搬送するための新規なGREヘッダを示す図である。
【図１５】実施形態に係る、BSNおよび輻輳量情報の両方を搬送するための完全なGTP−Uヘッダを示す図である。
【図１６】実施形態に係る、BSNおよび輻輳量情報の両方を搬送するための新規なCAPWAPヘッダを示す図である。
【図１７】実施形態に係る、BSNおよび輻輳量情報の両方を搬送するための新規なGREヘッダを示す図である。
【図１８】実施形態に係るポリサーを示す図である。
【図１９】別の実施形態に係るポリサーを示す図である。
【図２０】実施形態に係る輻輳ビットレート推定器に関するフローチャートである。
【図２１】実施形態に係るPdrop値の算出に関するフローチャートである。
【図２２】別の実施形態に係るPdrop値の算出に関するフローチャートである。
【図２３】実施形態に係るパケット廃棄に関するフローチャートである。
【発明を実施するための形態】
【００２６】
図面を通じて、同一の参照数字は、類似あるいは対応する要素について用いられている。
【００２７】
背景技術の欄で説明したように、現在の無縁アクセス技術（Wi-Fiおよび4G）は、モバイルトランスポートネットワークの利用可能容量を動的に考慮せず、また利用可能なバックホール容量がユーザ間でどのように共有されているかを知らない。従って、ネットワーク輻輳を回避するためにネットワーク容量を管理するためのより効率的な手順に対する一般的な需要が存在する。
【００２８】
トラフィックポリシングは、トラフィック契約の遵守のためにネットワークトラフィックを監視し、契約を実施するための手段を講じる。トラフィック契約を承知しているトラフィックソースは、自身の出力が契約の範囲内にとどまること、すなわち廃棄されないことを確保するために、トラフィックシェイピングを適用できる。トラフィック契約を超えるトラフィックは、管理ポリシおよび超過トラフィックの特性に応じて、違反とされて直ちに廃棄されるかもしれないし、そのまま放置されるかもしれない。
【００２９】
監視されているトラフィックの受信者は、入来トラフィックが契約を超過すると、期間全体に分散したパケット損失を観測するであろう。（例えばフィードバック機構を通じて）ソースが自身の送信レートを制限しなければ、この状況は継続し、受信者にはリンクエラーもしくは他の何らかの故障がランダムなパケット損失を招いているように見えるかもしれない。
【００３０】
ユーザデータグラムプロトコル(UDP)とは対照的に、トランスミッション制御プロトコル(TCP)のような信頼できるプロトコルを用いることによって、破棄されたパケットは受信者によって確認されないため、出力側(emitter)によって再送され、より多くのトラフィックが生成される。
【００３１】
（途中でポリシングを受けている）受信したトラフィックは、ポリサーのネットワーク下流で要素によってジッタが導入されているかもしれないが、契約に従っているのが一般的であろう。
【００３２】
フィードバックに基づく輻輳制御メカニズム（例えばTCP）を用いるソースは、ポリシングされた平均レート(sustained rate)をわずかに下回るレートに収束しながら、静的ポリシングに急速に適応していくのが一般的である。
【００３３】
第３世代パートナシッププロジェクト(3GPP)は、個々のユーザ端末(UE)およびアクセスポイント名(APN)についてのユーザデータトラフィックビットレート施行[Ref.4]またはポリシングを規定している。例えば、LTEネットワークにおいて、UE総計最大ビットレート(AMBR)は、UEの全ての非GBRベアラにわたって提供されることが予期できる総計ビットレートを制限する、ホーム加入者サーバ(HSS)にUEごとに保存される加入パラメータである。LTEネットワーク内のeNBは、UE-AMBRに基づくアップリンク(UL)およびダウンリンク(DL)レート施行の責を負う。APN-AMBRはHSSでAPNごとに保存される第２の加入者パラメータである。これは、同一のAPN(例えばインターネットAPN)の全ての非GBRベアラにわたって、および全てのパケットデータネットワーク(PDN)接続にわたって予期できる総計ビットレートを制限する。例えば他の加入者がいずれもインターネットトラフィックを搬送しない場合、これら非GBRベアラの各々はそのインターネットAPNに割り当てられた容量の全体を用いる可能性がある。PDNゲートウェイ(PGW)は、APN-AMBRに基づくULおよびDLレート施行について責を負う。レート施行またはビットレートポリシングは、例えばトークンバケットアルゴリズムを用いてデフォルトベアラについての各UEスループットを制限するために、PGWに設定されてもよい。
【００３４】
ビットレートポリシングに付随する問題には例えば以下のようなものがある。
・  ビットレートポリシングは、パス全体についての最低帯域幅として規定されるボトルネック帯域幅よりもポリシングレートがずっと低くないかぎり、輻輳を防がないこと。
・  モバイルネットワークは一層ヘテロジニアスになっており、アウトドアまたはインドアセルサイトの各々が異なるバックホール容量とともに配備されていること。
・  ビットレートポリシングは、最適な統計的多重化ゲインや総利用可能リソースの活用を考慮しないこと。
・  ヘビーユーザが依然として不釣り合いな輻輳の原因となり得ること。
【００３５】
インターネットエンジニアリングタスクフォース(IETF)は、破棄されたパケットまたは明示的輻輳通知(ECN)マーキングでマークされたパケットに基づく輻輳表示を規定している（文献５）。IETFはさらに、輻輳露出(ConEx)を用いる輻輳ビットレートポリシングを規定している（文献６）。ConExは輻輳量および輻輳ポリサーを以下の様に導入する。
【００３６】
・  輻輳量：トラフィックの任意の粒度（パケット、フロー、アグリゲート、リンク、など）について、所定時間内に破棄またはECNでマークされたバイト量。概念的には、その量の各パケットが受けた輻輳を乗じたデータ量である。これは通常バイト（またはキロバイト、メガバイトなどの）単位で表記される。
・  輻輳ビットレート：時間単位あたりの、損失またはECN被輻輳(CE)マークされたビット量。これは通常ビット／秒(bps)またはkbps単位で表記される。
・  輻輳ポリサー：ネットワークオペレータが各ユーザの輻輳量を監視し、また輻輳量制限を施行することを可能にする論理エンティティ。
【００３７】
ConExに付随する問題には例えば以下のようなものがある。
・  ConExは、インターネットプロトコルバージョン４(IPv4)および、依然としてIPv4を用いている多数のモバイルネットワークを除外していること。
・  現状、ConExはトランスミッションコントロールプロトコル(TCP)トラフィックだけに適用可能であること。概念を他のプロトコルにも拡張可能ではあるが、一般的にそれにはオペレーティングシステム(OS)ネットワーキングスタックの変更が必要になること。一例として、ユーザデータグラムプロトコル(UDP)ソケットのためのＢＳＤ(Berkeley Software Distribution)スタイルインタフェースは、インターネットプロトコル(IP)ヘッダ内の検査や変更を許可しない。
・  ConExはConEx宛先オプション(CDO)（文献７）をサポートするようにＴＣＰセンダを変更することを必要とすること。
・  ConExはECN（文献５）の仕様を推奨するが、投資を正当化するのに見合った利益が証明されていないため、ECNのデプロイメントはモバイルバックホールネットワークに限定されること。さらに困難なのは、エンドポイントとネットワークの両方に変更を必要とするという点において、ECNはジレンマ(catch 22)問題の影響を受けることである。
・  ConExはTCPレシーバを最適なConExパフォーマンスのために変更することを推奨すること（文献８）（文献５）。
・  ConExは動作モードおよびバリエーション(variances)が多すぎて、最初のデプロイメントが複雑すぎること。
・  多くの場合、LTEおよび場合によってはWi-Fiトラフィックはインターネットプロトコル(IP)セキュリティ(IPsec)トンネルモードで保護されるが、ConExのIPsecトンネルモードとの互換性が疑わしいこと。IPsecは内部パケットから外部ヘッダにいかなる拡張ヘッダもコピーしないし、IPsecは外部ヘッダ内にオプションを構築することもない。
【００３８】
米国特許出願公開第2012/0051216号明細書は、PGWとeNBとの間のGTP-Uパス上で稼働する、より単純なConEx様の手法を規定する発明において、ローカライズド輻輳露出を提案している（文献１０）。この文献では、eNBがアップリンク(UL)GTP-Uパフォーマンスレポートを用いてPGWにダウンリンク(DL)ECNマーキングをフィードバックできるように、ECNがデプロイされ、かつバックホールネットワークで効果的に機能することを前提としている。
【００３９】
効果的であるためには、輻輳ビットレートポリシングがパケットボリュームではなくフローまたはベアラごとに実施されなければならない。これは、任意のタイミングかつ任意の方向においてパケットサイズが変化しうるからである。バイト対パケットの問題は、IETFでも議論されている（文献１１）。
【００４０】
図２は実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするために第１のネットワークノードで実行される方法の例を示す模式的なフローチャートである。方法は、ユーザパケットをカプセル化してトンネルで第２のネットワークノードへ送信するステップＳ１を有し、ユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有する。方法はさらに、トンネルについての輻輳量情報を第２のネットワークノードから受信するステップＳ２を有する。方法はまた、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するステップＳ４か、受信した、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを適用することを可能とするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードへ転送するステップＳ３を有する。換言すれば、第１のネットワークノードはネットワーク輻輳ポリシングを自身で適用してもよいし、輻輳量情報をさらに別のネットワークノードに転送してもよく、後者の場合、別のネットワークノードが輻輳量情報に基づいてネットワーク輻輳ポリシングを適用する。従って、第１のネットワークノードはステップＳ２のあと、ステップＳ３とＳ４の両方を同時に行うのではなく、ステップＳ３とステップＳ４のいずれかを実行する。これは、図２において点線によって示されている。
【００４１】
第１のネットワークノードがユーザパケットを送信する際、バイト損失がまだ存在していないことは言うまでもない。バイト損失の有無を判定するのは第２のネットワークノードであり、判定はユーザパケットの受信時に行われる。一例として、第１のネットワークノードはあるバイト量（損失なし）を送信することができ、第２のネットワークノードはあるバイト量を受信してバイト損失量を判定することができる。であるから、第１のネットワークノードは実際のバイト損失量を送信しない。第１のネットワークノードは、バイト損失量に関する情報を送信し、第２のネットワークノードが実際のバイト損失量を判定することを可能にする。
【００４２】
ある例示的な実施形態において、トンネルについてのバイト損失量に関する情報は、トンネルについてのユーザパケットそれぞれのデータの最初のバイトとして規定されるバイトシーケンス番号(BSN)を有する。ある特定の実施形態において、バイトシーケンス番号はユーザパケット用のトンネルヘッダで提供される。
【００４３】
別の実施形態において、トンネルについてのバイト損失量に関する情報は、トンネルについてのパケットシーケンス番号を有する。ある特定の実施形態において、パケットシーケンス番号はユーザパケット用のトンネルヘッダで提供される。
【００４４】
ネットワーク輻輳ポリシングは様々な方法で実施可能である。可能性のある１つは、ポリシングを、ユーザパケットに関する破棄確率、すなわち入来ユーザパケットが輻輳を原因として破棄される確率に基づかせることである。そのため、ある特定の実施形態では、トンネルについてのネットワーク輻輳ポリシングを適用するステップＳ４が、第２のネットワークノード宛てのユーザパケットが破棄される破棄確率にさらに基づく。ある特定の実施形態において、破棄確率は、受信される輻輳量情報に含まれ、かつ第２のネットワークノードから輻輳量情報が出発した時刻の、可能な範囲で最良の推定時刻として規定される出口タイムスタンプに基づく。
【００４５】
ネットワーク輻輳ポリシング方法については、以下でより詳細に説明する。
【００４６】
図３は、無線ネットワーク内のネットワーク輻輳管理を可能にするために第２のネットワークノードで実行される方法の例を示す模式的なフローチャートである。方法は、カプセル化されたユーザパケットをトンネルで第１のネットワークノードから受信するステップＳ１０を有し、受信する各ユーザパケットは、トンネルについてのバイト損失量に関する情報を有する。方法はさらに、トンネルについての輻輳量情報を、トンネルについてのバイト損失量に関する情報に基づいて決定するステップＳ２０を有する。方法はまた、決定した、トンネルについての輻輳量情報に基づくトンネルについてのネットワーク輻輳ポリシングを可能にするため、決定した、トンネルについての輻輳量情報を第１のネットワークノードに送信するステップＳ３０を有する。
【００４７】
上述したように、一実施形態において、トンネルについてのバイト損失量に関する情報は、そのトンネルについてのバイトシーケンス番号を有する。そのような実施形態において、トンネルについてのバイト損失量は、予期されるものよりも受信したバイトシーケンス番号が大きい場合、つまり、先行するユーザパケットのバイトシーケンス番号に、先行するユーザパケットのユーザペイロードサイズを加えたものよりも受信したバイトシーケンス番号が大きい場合に検出されてよい。
【００４８】
上述したように、一実施形態において、トンネルについてのバイト損失量に関する情報は、そのトンネルについてのパケットシーケンス番号を有することができる。そのような実施形態において、トンネルについてのバイト損失量は、予期されるものよりも受信したパケットシーケンス番号が大きい場合、つまり、先行するユーザパケットのパケットシーケンス番号に１を加えたものよりも受信したパケットシーケンス番号が大きい場合に検出されてよい。
【００４９】
一実施形態において、トンネルについての輻輳量情報は、そのトンネルについてのバイト輻輳量に関する情報にも基づく。なお、そのような、トンネルについてのバイト輻輳量に関する情報は、受信されるユーザパケット内に含まれてよい。ある特定の実施形態では、トンネルについてのバイト輻輳量に関する情報は、そのトンネルについてのネットワーク輻輳を示す、IPヘッダ内に提供される明示的輻輳通知(ECN)マーキングが付与された受信ユーザパケットを有する。そのような実施形態において、第１のネットワークノードから送信されるユーザパケットは、第１のネットワークノードがそのトンネルについてECNをサポートしていることを示すECNマーキングを有する必要があることは言うまでもない。
【００５０】
図４は、無線ネットワーク内のネットワーク輻輳を管理するために第３のネットワークノードで実行される方法の例を示す模式的なフローチャートである。方法は、トンネルについての輻輳量情報を第１のネットワークノードから受信するステップＳ１００を有する。受信された輻輳量情報は、第２のネットワークノードによって決定され、第１のネットワークノードによって転送されている。方法はさらに、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するステップＳ２００を有する。
【００５１】
上述したように、ネットワーク輻輳ポリシングは様々な方法で実施することができる。可能性のある１つは、ポリシングをユーザパケットの破棄確率、すなわち入来ユーザパケットが輻輳を原因として破棄される確率に基づかせることである。そのため、ある特定の実施形態では、トンネルについてのネットワーク輻輳ポリシングを適用するステップＳ２００が、第１のネットワークノード宛てのユーザパケットが破棄される破棄確率にさらに基づく。ある特定の実施形態において、破棄確率は、受信される輻輳量情報に含まれ、かつ第２のネットワークノードから輻輳量情報が出発した時刻の、可能な範囲で最良の推定時刻として規定される出口タイムスタンプに基づく。
【００５２】
例示的な実装において、ネットワークノードはＵＥについてのトンネルまたは接続を取り扱い、ＵＥあたり伝送方向あたり１つ（一方向の）トンネルか、ＵＥあたり１つの（双方向）ＵＥ接続（双方向トンネル）である。この場合、第１、第２、および第３のネットワークノードは、所与の伝送方向における所与のトンネルについてのトンネル送信器またはトンネル受信器として振る舞う。さらに、第１および第２のネットワークノードはトンネルピアノードであり、また、第１および第３のネットワークノードはトンネルピアノードである。図１ｃに関して、基本的な図は以下の様に記述することができるであろう。
UE (40) --- 第２のネットワークノード (20) --- トンネル --- 第１のネットワークノード (10) --- トンネル --- 第３のネットワークノード (30) --- インターネット
【００５３】
２つのエンドポイント（ノード）間のパスは、２つの方向（アップリンクおよびダウンリンク）を有する。理論上、輻輳はいずれかの方向で、あるいは両方向で「同時に」発生しうる。
【００５４】
例示的な実装においてネットワークノードは、トンネル受信器として振る舞うピアノードに、ユーザデータとともにトンネルレイヤでバイトシーケンス番号(BSN)を送信するため、伝送方向に関するトンネル送信器として振る舞っている。そして、ピアノードは、逆方向に進むユーザデータとともに、もしくは専用のシグナリング／制御メッセージとともに（ユーザデータなしで）、トンネルレイヤでバイト単位(byte-wise)輻輳量をトンネル送信器にフィードバックする。最終的に、輻輳ポリシングはトンネル送信器として振る舞うネットワークノードで実行される。
【００５５】
一部の例示的な実施形態において、第１のネットワークノード１０および第２のネットワークノード２０はeNodeB (エヴォルブドNode B)、eNodeB、アクセスコントローラ(AC)、トンネル対応ルータ、または仮想化ネットワーク機能(VNF)であってよい。一部の実施形態において、第３のネットワークノードはパケットゲートウェイ(PGW)、在圏GPRSサポートノード(SGSN)、ゲートウェイGPRSサポートノード(GGSN)、トンネル対応ルータ、または仮想化ネットワーク機能(VNF)であってよい（図１ａおよび１ｂも参照されたい）。
【００５６】
標準のConEXとの重要な差異は、本実施形態がバイトシーケンス番号の送信と、トンネルエンドポイント間でTCPエンドポイントを用いない輻輳量情報の返送を実施することである。
【００５７】
以下では、説明に役立つ実施形態の非限定的な例をいくつか説明する。
【００５８】
トンネル輻輳量を追跡するための方法
ここで提案する実施形態は、トンネル送信器とトンネル受信器との間で損失した、もしくは破棄されたバイト量を、トンネル受信器が監視することを可能にする。実施形態はまた、同じ方法を用いるトンネル送信器とトンネル受信器との間でECN-CEコードポイントによってマークされたバイト量を、トンネル受信器が別個に監視することを可能にする。これら２つのトラフィック量の合計は、輻輳量として知られている。オペレータは、特定のトンネルまたは特定のUEのダウンリンク方向における輻輳量を監視するように決定してもよい。同様に、オペレータは、両方向について同時に、あるいはUL方向について監視するように決定してもよい。文章を簡単にするため、ボトルネック帯域幅がDL方向に存在するものとする。
【００５９】
トンネル送信器は、GTP-U、CAPWAP、またはGREトンネル（あるいは他の任意のトンネリングプロトコル）へのユーザパケットの転送ならびにカプセル化に関して責を負う。トンネル受信器は、トンネル化されたパケットの受信、ユーザパケットのカプセル化解除、およびUEへのユーザパケットの転送もしくは次のトンネルへのユーザパケットの転送に関して責を負う。LTEネットワークのDL方向において、S1-Uインタフェースを挟んだトンネル送信器および受信器はそれおれSGWおよびeNBである。3GPPモバイルコアネットワークに接続されたWi-Fiネットワーク(EPC)のDL方向において、CAPWAPインタフェースを挟んだトンネル送信器および受信器はそれぞれアクセスコントローラおよびアクセスポイントである。インターネットに接続されたWi-Fiネットワーク（ローカルブレイクアウトとしても知られている）のDL方向において、GREインタフェースを挟んだトンネル送信器および受信器はそれぞれWi-Fiゲートウェイおよびアクセスポイントである。図１ａおよび１ｂを参照されたい。
【００６０】
提案する解決方法は、トンネルヘッダに、トンネル送信器からトンネル受信器へのデータフロー内のバイトを特定する、バイトシーケンス番号(BSN)と呼ばれる新たなフィールドを定義する。より具体的には、バイトシーケンス番号は各トンネルパケット内のデータの最初のバイトを表す。BSNは、輻輳についてポリシングされている各ＵＥベアラまたはＵＥ接続について、トンネル送信器が変数として維持している。
【００６１】
提案する解決方法はまた、トンネル受信器によってインクリメントされる２つのカウンタを定義する。このカウンタペアは、輻輳についてポリシングされている各ＵＥベアラまたはＵＥ接続について適用可能である。カウンタは以下の通りである。
・  LostOctetTotalCount
・  CeOctetTotalCount
【００６２】
LostOctetTotalCountは、輻輳監視処理がその接続について（再）初期化されてからの、入力パケットの総計（累積）オクテット数である。オクテット数は、ユーザイーサネット（登録商標）ヘッダおよびQ−タグ（適用可能な場合。例えばWi-Fi）およびユーザIPヘッダおよびペイロードを含む、トンネルペイロード内の全データを含んでいる。一実施形態において、このカウンタには３２ビットを割り当てることが提案される。
【００６３】
CeOctetTotalCountは、輻輳監視処理がその接続について（再）初期化されてからの、輻輳経験(CE)マーキング（すなわち、ECNコードポイント=11）によってマークされた入力パケットの総計（累積）オクテット数である。オクテット数は、ユーザイーサネット（登録商標）ヘッダおよびQ−タグ（適用可能な場合）およびユーザIPヘッダおよびペイロードを含む、トンネルペイロード内の全データを含んでいる。一実施形態において、このカウンタには３２ビットを割り当てることが提案される。
【００６４】
トンネル受信器はさらに、輻輳についてポリシングされている各ＵＥベアラまたはＵＥ接続について、変数NextExpByteを実装する。NextExpByteは、データストリームにおいて、次に予期されるバイトシーケンス番号である。通常の状況下で、NextExpByteは、直前のトンネリングされたパケットのBSNとユーザペイロードのサイズの合計である。入力されたトンネリングされたパケットが、予期されるものより大きなバイトシーケンス番号とともに到来した際にバイトシーケンスの不連続性が検出される。見つからないバイトは損失したか、遅延（リオーダー）されている。簡単化のために、輻輳量の目的に関して、シーケンス不連続性をトリガする全てのバイトを「損失した」ものと見なすことができる。あるいは、トンネル受信器は見つからないバイトの小さなリストを維持し、許容可能なタイムフレーム内でそれらが到着した場合にはそれらをLostOctetTotalCountまたはCeOctetTotalLostカウンタから除外することができる。
【００６５】
例えば、トンネリングされたパケットを受信すると、トンネル受信器はパケット損失および／またはパケットECN-マーキングが発生しているかどうか判定する。受信パケットがECN-CEコードポイントでマークされていれば、CeOctetTotalCountが、ユーザペイロードのサイズでインクリメントされる。受信パケットがバイトシーケンス不連続性をトリガしている場合、LostOctetTotalCountカウンタが、受信パケットからのBSN値からトンネル受信器メモリ内に保存されているNextExtByteを減じた値でインクリメントされる。
【００６６】
BSN搬送のためのGTP-Uプロトコルへの変更
現在の3GPP仕様において、GTP-Uトンネル送信器は各GTP-Uトンネルについて個別のシーケンス番号を維持することが可能である。そのようなシーケンス番号は、カプセル化された最初のユーザパケットをGTP-Uトンネルに送信する際に初期値ゼロに設定される。その後、トンネル上でのGTP-Uパケット送信ごとにシーケンス番号は１インクリメントされる。現在の3GPP仕様で規定されるシーケンス番号は、順番通りの配信が必要な場合に、リモートピアで順序通りでないパケットの並び替えをトリガすることを意図したものである。図８は、１に設定されたシーケンス番号フラグ(S)を有する、現在のGTP-Uヘッダを示している。シーケンス番号(SN)フィールドは、符号なし１６ビット整数を格納する。
【００６７】
一実施形態において、バイトシーケンス番号(BSN)と呼ばれる新たなGTP-Uヘッダフィールドが提案される。そのフィールドは、GTP-Uトンネル送信器からGTP-Uトンネル受信器へのデータフロー内のバイトを特定する。より具体的には、そのフィールドは、特定のUEベアラに関して送信されるGTP-Uパケットの最初のバイトまたはトンネルエンドポイント識別子(TEID)を表す。GTP-Uトンネル送信器は、GTP-Uトンネルに最初のパケットを送信する際、シーケンス番号を初期値１に設定する。シーケンス番号は、そのトンネル上での引き続くGTP-Uパケット送信のそれぞれについて、直前に送信されたユーザパケットペイロード（IPヘッダを含む）からのバイト数でインクリメントされる。新たなGTP-Uシーケンス番号はGTP-Uオーバヘッドを含まず、かつGTP-Uシグナリングメッセージに関するバイト量を含まない。
【００６８】
この解決手法は、BSNを搬送するための、少なくとも２つの方法を提案する。他のオプションも可能である。第１の実施形態において、方法は、既存のGTP-Uヘッダの構造を維持しつつ、直前のSNフィールドが、パケット数ではなくバイト数を追跡するために用いられていることを示す、新たなGTP-Uバージョン番号を規定する。図９は、２に設定されたバージョンフィールドと、１に設定されたＢフラグ（Ｓフラグを置換している）と、１６ビットBSNフィールドとを示している。
【００６９】
第２の実施形態においては、連続するパケット損失が重要であり、かつシーケンス番号があまりに早く一巡してしまう可能性がある、極端なケースを処理するために、より長い３２ビットBSNフィールドが提案される。図１０は、２に設定されたバージョンフィールドと、１に設定されたＢフラグと、３２ビットBSNフィールドとを有するGTP-Uヘッダを示している。
【００７０】
BSN搬送のためのCAPWAPプロトコルへの変更
現在のIETF仕様において、CAPWAPトンネル送信器は各CAPWAPトンネルについて個別のシーケンス番号を維持しない。図１１は、０に設定されたバージョンフィールドを有する現在のCAPWAPヘッダを示している。
【００７１】
一実施形態において、バイトシーケンス番号(BSN)と呼ばれる新たなCAPWAPヘッダフィールドが提案される。そのフィールドは、CAPWAPトンネル送信器からCAPWAPトンネル受信器への、特定のUEについてのデータフロー内のバイトを特定する。より具体的には、そのフィールドは、ある特定のUE接続（例えばUE MACアドレス）に関して送信されるCAPWAPデータパケットのデータの最初のバイトを表す。CAPWAPトンネル送信器は、そのUEへ向かう最初のパケットを送信する際、シーケンス番号を初期値１に設定する。シーケンス番号は、そのトンネル上での引き続くCAPWAPデータパケット送信のそれぞれについて、直前に送信されたユーザパケットペイロード（イーサネットおよびIPヘッダを含む）からのバイト数でインクリメントされる。新たなCAPWAPシーケンス番号はCAPWAPオーバヘッドを含まず、かつCAPWAPデータチャネルキープアライブメッセージに関するバイト量を含まない。図１２は、一実施形態に係る、１に設定されたバージョンフィールドと、１に設定されたＢフラグと、３２ビットBSNフィールドとを有する新たなCAPWAPヘッダの例を示す。なお、トンネル内の個々のUE接続を特定するために、GREヘッダに似たKeyフィールド（次のセクションを参照されたい）を、必要に応じて新たなCAPWAPヘッダに追加することができる。
【００７２】
BSN搬送のためのGREプロトコルへの変更
現在のIETF仕様において、GREトンネル送信器は各GREトンネルについて個別のキーおよびシーケンス番号を維持することができる。そのようなフィールドは、RFC(Request For Comments) 2890［文献１３］に規定されている。GTP-Uシーケンス番号と同様に、GREシーケンス番号はオプションであり、順序付けられたGREパケットが送信されていることを示す。キーフィールドはオプションであり、トンネル内の個々のトラフィックフローを特定することを意図したものである。例えば、キーフィールドは、APとWi-Fiゲートウェイ(GW)との間の個々のUE接続を特定するために用いることができる。あるいは、ユーザデータペイロード内のUEメディアアクセス制御(MAC)アドレスを、UE接続を特定するために用いることができる。図１３は、オプションであるキーおよびSNフィールドと、ゼロに設定されたバージョンフィールドと、ゼロに設定されたチェックサム存在ビット（すなわち、チェックサムフィールドが存在しない）とを有する現在のGREヘッダを示している。GREバージョン１は、ポイントツーポイントトンネリングプロトコル(PPTP)［文献１２］によって用いられる。
【００７３】
一実施形態において、バイトシーケンス番号(BSN)と呼ばれる新たなGREヘッダフィールドが提案される。そのフィールドは、GREトンネル送信器からGREトンネル受信器への、特定のUEについてのデータフロー内のバイトを特定する。より具体的には、そのフィールドは、ある特定のUE MACアドレスに関して送信されるGREデータパケットのデータの最初のバイトを表す。GREトンネル送信器は、そのUEへ向かう最初のパケットを送信する際、シーケンス番号を初期値１に設定する。シーケンス番号は、そのトンネル上での引き続くGREデータパケット送信のそれぞれについて、直前に送信されたユーザパケットペイロード（イーサネットおよびIPヘッダを含む）からのバイト数でインクリメントされる。新たなGREシーケンス番号はGREオーバヘッドを含まない。図１４は、一実施形態に係る、新たな３２ビットBSNフィールドがヘッダ内に存在するか否かを示す新たなＢフラグを有する新たなGREヘッダの例を示す。バージョンフィールドはゼロに設定可能であり、またプロコトルタイプについての固有値を規定することにより、新たなフラグおよびBSNフィールドを認識可能である。例えば、エリクソン社がリザーブしている値0x8936は、それが輻輳量GREパケットであることを示すことができる。あるいは、バージョンフィールドを３に設定することができる。
【００７４】
トンネル輻輳量を報告するための方法
現在提案している実施形態は、新たに提案するGTP-U、CAPWAP、およびGREトンネリングプロトコルの拡張を用いて、トンネルエンドポイントが輻輳量（LostOctetTotalCountおよびCeOctetTotalCountカウンタ）をトンネルピア（例えばSGW、Wi-Fiアクセスコントローラ、またはWi-Fiゲートウェイ）にリアルタイムで報告することを可能にする。必要に応じて出口タイムスタンプがさらに含まれる。
【００７５】
一実施形態において、タイムスタンプはトンネルエンドポイント(eNB、AP)によって挿入される。タイムスタンプにより、上流のトンネルノード（例えばSWG、Wi-Fiアクセスコントローラ、Wi-Fiゲートウェイ、またはPGW）での輻輳ビットレートの計算精度が向上する。ネットワーク内で、または送信エンティティによって、輻輳報告が遅延しうる可能性があり、それによって輻輳報告がポリサーに到着した際にタイムスタンプを設定することの精度を低下させうることが動機となって、タイムスタンプフィールドが用いられる。輻輳報告についてのバックホール遅延が一定であり、かつ輻輳報告が直ちに送信されるという理想的なケースでは、ポリサーが輻輳報告を受信した際にポリサーが輻輳報告にタイムスタンプを付加するに任せれば十分であろう。しかしながら、輻輳報告はネットワークジッタに起因して、ネットワークでさまざまな遅延を受けうる。さらに、輻輳報告はネットワークオーバヘッドおよびシグナリング負荷の両方を節約するために、バンドルされる可能性がある。この予測不能な遅延は大きくないかもしれないが、報告がポリサーに到着した際に設定されるタイムスタンプの精度を低下させるには依然として十分大きく、従って輻輳ビットレート(CBR)の精度に影響を与える。
【００７６】
一実施形態において、輻輳量および関連するタイムスタンプの送信は、UEベアラまたは接続の逆方向で動作している１対のトンネル送信器およびトンネル受信器を関与させることによって行われてよい。
【００７７】
提案する解決方法は、輻輳量情報を報告するための少なくとも２つの方法を提案する。
１）  UEベアラまたは接続について逆方向に移動する、トンネリングされたユーザパケットに、カウンタ値をピギーバックする。
２）  カウンタ値を別個の制御パケットまたはユーザプレーンシグナリングメッセージで送信する。
【００７８】
輻輳量報告に関するオーバヘッドを削減しつつ、実装を単純化するので、最初の方法が好ましい。この実施形態は、輻輳量カウンタをGTP-U、CAPWAP、およびGREプロトコルで搬送するための新たなヘッダフラグ（および対応するヘッダフィールド）および、新たな拡張ヘッダを規定する。
【００７９】
最初の方法により、輻輳情報は必要なときだけ、反対方向で上流ノードに送信される次のGTP-Uパケットにピギーバック並びに付加される。輻輳量に変化がない場合または大幅に増加していない場合、輻輳量情報は送信されない。
【００８０】
BSNおよび輻輳量搬送のためのGTP-Uプロトコルへの変更
提案する解決方法は、一実施形態において新たなGTP-U拡張ヘッダを規定する。GTP-U拡張ヘッダの汎用フォーマットはGTPv1-U［文献１］で既に規定されている。GTP-U拡張ヘッダは、G-PDU（GTP-Uパケット）のヘッダまたはGTP-Uシグナリングメッセージのヘッダで追加データを搬送するために用いられる。新たなGTP-U拡張ヘッダは輻輳量インジケータと呼ばれ、固有の８ビット拡張ヘッダ値（例えば0xFFFF）が割り当てられる。輻輳量インジケータは、UEベアラについて逆方向に移動するGTP-Uパケット（GTP-Uメッセージタイプ＝２５５を有する）に追加される。
【００８１】
輻輳量インジケータは以下の情報要素を含んでいる。
・  逆方向での損失バイト数（すなわち、LostOctetTotalCount）
・  逆方向でのECN-CEを有するバイト数（すなわち、CeOctetTotalCount）
・  タイムスタンプ
【００８２】
タイムスタンプは、RFC 5905［文献１４］に従った、３２ビットNTPショートフォーマットを用いる３２ビットフィールドである。（注：短縮された１ビットタイムスタンプで十分だが、他のプロトコルに対する実装との一貫性を保つためにここでは３２ビット値を用いている。）タイムスタンプは、可能な範囲で最良の、パケット出発時刻の近似値である。
【００８３】
一実施形態において輻輳量インジケータは、ポリシングノードが対応するトンネルを見つけやすくするために、以下の追加情報を含んでもよい。
・  トンネルエンドポイント識別子データＩ
・  GTP-Uピアアドレス
【００８４】
トンネルエンドポイント識別子データＩは、GTPv1-U［１］で既に規定されている。輻輳量表示(indication)拡張ヘッダの場合、トンネルエンドポイント識別子データＩは、輻輳についてポリシングされているGTP-UトンネルからのTEIDである。例えば、輻輳がS1-Uインタフェースを跨がるダウンリングである場合、トンネルエンドポイント識別子データＩはDL TEIDである。
【００８５】
GTP-UピアアドレスはGTPv1-U［１］で既に規定されている。輻輳量表示拡張ヘッダの場合、GTP-Uピアアドレスは輻輳についてポリシングされているGTP-Uトンネルからの相手先IPアドレスである。例えば、輻輳がダウンリンクであり、輻輳がS1-Uインタフェースを跨がるダウンリングである場合、GTP-UピアアドレスはeNB IPアドレスである。
【００８６】
図１５は、実施形態に係る、グレーにハイライトされた輻輳量表示拡張ヘッダを有する完全なGTP-Uヘッダを示す図である。図では、トンネルエンドポイント識別子データＩおよびGTP-Uピアアドレスが不要な場合を想定している。
【００８７】
各ユニキャストGTP-Uベアラが、DDLトンネル送信器およびトンネル受信器対を有する１つのDLトンネルと、ULトンネル送信器およびトンネル受信器対を有する１つのULトンネルとの、２つのトンネルからなることについて言及しておくことは重要である。従って、所与のノード上のDLトンネル受信器が輻輳量を上流ノードに報告する必要がある場合、同一ノード上の対応するULトンネル送信器が、輻輳の反対方向を移動する輻輳量情報を送信する責を負う。DLトンネル受信器の各々はULトンネル送信器に関連付けられ、DLトンネル送信器の各々はULトンネル受信器に関連づけられる。
【００８８】
BSNおよび輻輳量搬送のためのCAPWAPプロトコルへの変更
一実施形態において、提案する解決方法は、先に規定した２つの追加フラグおよび対応するフィールドをCAPWAPバージョン１に追加する。追加フラグビットは：
・  Vビット（Vは量を意味する）
・  Cビット（Cはクロックを意味する）
【００８９】
Vビットが１に設定されると、それは逆方向での損失バイト数フィールドおよび逆方向でのECN-CEを有するバイト数フィールドの両方が存在することを示す。一実施形態において、ヘッダに個別フラグビットを規定することもできる。
【００９０】
Cビットが１に設定されると、それはタイムスタンプフィールドが存在することを示す。
【００９１】
図１６は、実施形態に係る、１に設定されたバージョンフィールドと、UE接続について反対方向での輻輳量を報告するための新規なフラグおよびフィールドとを有するCAPWAPヘッダを示している。
【００９２】
BSNおよび輻輳量搬送のためのGREプロトコルへの変更
提案する解決方法は、一実施形態において２つの追加フラグをGREヘッダに追加する。追加フラグビットは：
・  Vビット（Vは量を意味する）
・  Cビット（Cはクロックを意味する）
【００９３】
Vビットが１に設定されると、それは逆方向での損失バイト数フィールドおよび逆方向でのECN-CEを有するバイト数フィールドの両方が存在することを示す。一実施形態において、ヘッダに個別フラグビットを規定することもできる。
【００９４】
Cビットが１に設定されると、それはタイムスタンプフィールドが存在することを示す。
【００９５】
図１７は、実施形態に係る、UE接続について反対方向での輻輳量を報告するための新規なフラグおよびフィールドを有するGREヘッダを示している。バージョンフィールドはゼロに設定可能であり、またプロコトルタイプについての固有値を規定することにより、新たなフラグおよび輻輳量フィールドを認識可能である。例えば、エリクソン社がリザーブしている値0x8936は、それが輻輳量GREパケットであることを示すことができる。あるいは、一実施形態において、バージョンフィールドを３に設定することができる。
【００９６】
トンネル輻輳量をポリシングするための方法
輻輳報告は、例えばPGW、SGW、アクセスコントローラ(AC)、またはWi-Fi GWに配置されるポリサーにより、以下の説明に従って用いられる。図１ａおよび１ｂを参照されたい。報告間隔は主に、報告を受信するポリサーの能力に依存する。一実施形態において、報告は、システム規定パラメータによって与えられる一定間隔で送信される。別の実施形態において、報告は、損失した、もしくはECNでマーク付けされたパケットが検出された場合だけ、すなわち、損失した、もしくはECNでマーク付けされたパケットが増加した場合だけ、送信される２番目の実施形態の変形構成は、報告の送信を正当化するほど重大になるために、損失した、および／またはECN-CEでマーク付けされたバイト量がどの程度増加しなければならないかを規定する閾値を導入することである。これは、閾値に達しなくても、報告が送信されると満了するタイマと組み合わせることができる。この変形構成は、シグナリングオーバヘッドを節約するために多数のベアラに関する報告をまとめることを可能にする。
【００９７】
UEベアラまたはUE接続ごとに１つのポリサーが実装される。ポリサーの主な機能は、輻輳の原因であるUEベアラおよび接続に関するパケットを破棄することである。しかし、ここで総計最大輻輳ビットレート(AMCR)と表現している、輻輳許容量以下のUEベアラおよび接続については、追加のパケット破棄は行われない。しかし、AMCRを超えるベアラおよび接続はポリサーで追加のパケット破棄を受ける。これにより、ユーザ間の公平性の確保と、バックホールネットワークでの過負荷に対する保護の提供との両方を実現する。
【００９８】
ポリシングは様々な方法で実施することができる。一実施形態では図１８に示すトークンバケットが用いられる。損失バイトについての報告を取り扱う１つと、ECN-CEでマーク付けされたバイトを取り扱う１つとの、２つのバケットが実装される。各バケットは、輻輳許容量AMCRに等しいレートで一定時間ごとに満杯になる。バケットレベルは輻輳報告を受信すると減少し、減少分は輻輳バイト（LostOctetTotalCountまたはCeOctetTotalCount）の増加分に等しい。２つのバケットのいずれかが空になるとパケットが破棄される。一般に、バケットの最大深さは輻輳許容量が長く保存されすぎないように実装される。
【００９９】
別の代替実施形態は、算出されたCBRおよび、CBRとAMCRによって与えられる輻輳許容量との関係とに基づく破棄確率の算出である。CBRは、１秒あたりの、損失した、もしくはECN-CEでマーク付けされたビット数として算出される。この代替構成の高レベル機能性を図１９に示す。輻輳報告は、LostOctetTotalCountによって与えられる損失パケットに起因するCBRであるCBRLostと、CeOctetTotalCountによって与えられるECN-CEでマーク付けされたパケットに起因するCBRであるCBRCeとを算出する輻輳ビットレート推定器によって処理される。CBRは、１秒あたりのビット数(bps)で表される。損失パケットおよびENCでマーク付けされたパケットは、ECNデプロイメントが、AQMがパケットを破棄しうる程度よりも高い密度でパケットにECN-CEでマーク付けしうることを考慮し、コンセプトが将来に渡って利用できるように別個に取り扱われる。この理由により、２つの別個のAMCR値、すなわちAMCRLostおよびAMCRCeが維持される。
【０１００】
輻輳ビットレート値は、入来パケットが破棄される確率を増加または減少させる破棄確率アダプタによって用いられる。CBRLostに応じた１つと、CBRCeに応じた１つとの、２つのパケット破棄確率(Pdrop)値が算出される。
【０１０１】
CBRの算出ならびにPdropの調整は、報告間隔および輻輳ポリシングの所望の応答時間といった要因に依存する。例えばPdropの速い変化は、例えば悪意のあるフローに対してポリサーをより素早く反応させるが、その反面、不安定リスクが増加しうるという欠点があり、これは例えば規則的に変動するリンク利用にはっきりと現れうる。
【０１０２】
輻輳ビットレート推定器の一例についてのフローチャートを図２０に示す。この図のフローは、TS（タイムスタンプ）、LostOctetTotalCount、およびCeOctetTotalCountの相対的な増加量に基づいて、受信した輻輳報告の各々についての輻輳ビットレートCBRLostおよびCBRCeがどのように算出されるかを説明している。このフローは、新たに受信した輻輳報告のそれぞれについて実行される。各報告は要素Ts、LostOctetTotalCount、およびCeOctetTotalCountを含んでいる。[N]は直近に受信した輻輳報告を、[N-1]は２つ前の輻輳報告を表す、以下同様である。（出口）タイムスタンプが輻輳報告で利用可能であれば、その値が用いられるが、そうでなければ輻輳報告がいつポリサーに到着したかに基づいて（到着）タイムスタンプ値が決定される。先に述べたように、後者の選択肢は、輻輳報告が何らかの理由により、ネットワーク内で、あるいは送信エンティティによって遅延されている場合には精度が落ちるかもしれない。
【０１０３】
最終的なCBRLostおよびCBRCe値は、直近のＫ回に受信した輻輳報告についての重み付け平均値として算出される。重みおよび値Ｋは、輻輳報告の間隔といった要因に依存する。
【０１０４】
Pdropを算出するための方法は変更することができる。図２１は、CBRとAMCRとの関係に応じてPdrop値を調整する簡単な方法の例を示している。この図に記載されているフローは、タイマによって与えられる規則的なタイミングで実行される。損失したパケットおよびECN-CEでマーク付けされたパケットの報告は別個に取り扱われる。つまり、Pdropについて２つの異なる値が算出される。PdropLostは損失したパケットに基づいて算出され、PdropCeはECN-CEでマーク付けされたパケットに基づいて算出される。
【０１０５】
別の、より発展した例は、PID (Proportional Integral Derivative)コントローラの実装である。PD ((Proportional Derivative)の例を図２２に示す。この図に記載されているフローは、タイマによって与えられる規則的なタイミングで実行される。損失したパケットおよびECN-CEでマーク付けされたパケットは別個に取り扱われる（PdropLostは損失したパケットに基づいて算出され、PdropCeはECN-CEでマーク付けされたパケットに基づいて算出される）。Nは現在のイベント（受信した報告）を表す。N-1は直前のイベントを表す。F(dT)は、直近に受信した報告以降の時間の関数であり、範囲[0..1]に出力値が制限されている。
【０１０６】
alphaおよびbata値は、報告の間隔といった様々な状況だけでなくPdrop値自身にも依存する。alpha値が、輻輳ビットレートとAMCRとの差に基づいてPdropをどの程度変化させるべきかを制御する一方、bata値は輻輳ビットレートを変化させる応答性を制御する。
【０１０７】
追加の関数は、直近に受信した輻輳報告以降の時間に応じてPdrop値をスケーリングするためのものである。直近に受信した輻輳報告以降の時間が長くなると、Pdrop値は０に向かって減少する。これにより、バイトが実際に損失したり、ECN-CEでマーク付けされた場合にだけ輻輳報告を送信することが可能になり、シグナリングオーバヘッドを節約することが可能になる。
【０１０８】
ドロッパーは、PdropLostおよびPdropCe値の組み合わせに基づいて、最終的に入来パケットを破棄する。例えば、図２３に示す実施形態を参照のこと。この図に記載されているフローは、新たな入来パケットそれぞれについて実行される。高いPdrop値は、入来パケットが破棄される可能性を増加させる。先の説明ならびに図面から、輻輳許容量未満の輻輳の原因であるベアラまたは接続はポリサーによっていかなる追加のパケット破棄も受けないが、その一方で、輻輳許容量を超えるベアラは、許容量をどの程度超えているかに応じて、ポリサーで追加のパケット破棄を受けることが明らかであろう。
【０１０９】
つまり、提案している実施形態のいくつかは、以下の機能を有する。
・  新たに提案される、GTP-U、CAPWAP、およびGREトンネリングプロトコルへの拡張を用いて、各トンネルについてのバイトシーケンス番号(BSN)を送信するための、トンネル送信器における方法と、トンネル（ユーザベアラまたは接続）ごとの、バイト単位のトラフィック損失およびECN-CEコードポイントでマークされたトラフィック（輻輳量情報として知られる）を追跡するための、トンネル受信器における方法。
・  新たに提案される、GTP-U、CAPWAP、およびGREトンネリングプロトコルへの拡張を用いて、輻輳量情報をトンネルピア（例えば在圏ゲートウェイ(SGW)、Wi-Fiアクセスコントローラ、またはWi-Fiゲートウェイ）に報告するための、トンネルエンドポイントにおける方法。
・  報告された輻輳量情報に基づいてトンネル輻輳ポリシングを適用するための、もしくは輻輳ポリシングを適用する、次のトンネル上流ノード(PGW)に輻輳量を中継するための、トンネルピア（例えばSGW、Wi-Fiアクセスコントローラ、Wi-Fiゲートウェイ、またはPGW）における方法。
・  輻輳レベルおよび輻輳報告間隔に基づいて、ポリサーでの輻輳ビットレート算出およびパケット破棄確率を調整するための、トンネルピアにおける方法。さらに、直近の輻輳報告からの経過時間が所与の閾値を超える場合、パケット破棄確率をゼロに向かって徐々に削減するための方法。
【０１１０】
提案した実施形態の利点のいくつかを以下に列挙する。
・  UE端末およびインターネットエンドポイント、または他のトランスポートプロトコル（例えばTCP）の実装とは独立した輻輳管理ソリューションであること。
・  モバイルネットワークの性能に負のインパクトを与えることなく、既存のノードで実施される簡単な機能であること。
・  短いフィードバックを用いて、輻輳により迅速に対応すること。
・  無線アクセス技術および／またはサービスミックスに応じてモバイルオペレータによって制御される、一貫性を有する輻輳量ポリシであること。
【０１１１】
実装の一例において、ここで説明したステップ、機能、手順、モジュール、および／またはブロックの少なくとも一部は、１つ以上のプロセッサを含む処理回路によって実行されるためにメモリに読み込まれるコンピュータプログラムに実装される。１つ以上のプロセッサおよびメモリは通常のソフトウェア実行を可能にするために相互接続される。１つ以上の入力パラメータおよび／または結果として得られる１つ以上の出力パラメータのような関連データの入力および／または出力を可能とするために、１つ以上のプロセッサおよび／またはメモリにさらに任意の入力／出力デバイスが相互接続されてもよい。
【０１１２】
ここで説明した実施形態は、従って、図５ａ〜５ｃおよび図６ａ〜６ｃに示したネットワークノード内のプロセッサのような１つ以上のプロセッサと、ここで説明した実施形態の機能よび動作を実行するための対応するプログラムコードとを通じて実施されてよい。
【０１１３】
第１のネットワークノード
一実施形態によれば、第１のネットワークノードは無線ネットワーク内のネットワーク輻輳管理を可能にするように構成される。第１のネットワークノードはユーザパケットをカプセル化してトンネルで第２のネットワークノードへ送信するように構成され、ユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有する。第１のネットワークノードは、そのトンネルについての輻輳量情報を第２のネットワークノードから受信するようにさらに構成される。第１のネットワークノードはまた、受信した、トンネルについての輻輳量情報に基づいてネットワーク輻輳ポリシングを適用するか、受信した、トンネルについての輻輳量情報に基づくネットワーク輻輳ポリシングを可能にするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードに転送するように構成される。
【０１１４】
一実施形態において、トンネルについてのバイト損失量に関する情報は、そのトンネルについての各ユーザパケット内のデータの最初のバイトとして規定されるバイトシーケンス番号(BSN)を有する。ある特定の実施形態において、バイトシーケンス番号はユーザパケット用のトンネルヘッダで提供される。
【０１１５】
別の実施形態において、トンネルについてのバイト損失量に関する情報は、トンネルについてのパケットシーケンス番号を有する。ある特定の実施形態において、パケットシーケンス番号はユーザパケット用のトンネルヘッダで提供される。
【０１１６】
ある特定の実施形態において、第１のネットワークノードは、第２のネットワークノード宛てのユーザパケットが破棄される破棄確率に基づいてトンネルについてのネットワーク輻輳ポリシングを適用するようにさらに構成される。ある特定の実施形態において、第１のネットワークノードは、受信する輻輳量情報に含まれ、かつ第２のネットワークノードから輻輳量情報が出発した時刻の、可能な範囲で最良の推定時刻として規定される出口タイムスタンプに基づいて、破棄確率を決定するように構成される。
【０１１７】
一部の例示的な実施形態において、第１のネットワークノードはeNodeB (Evolved Node B)、NodeB、アクセスポイント(AP)、在圏ゲートウェイ(SGW)、無線ネットワークコントローラ(RNC)、アクセスコントローラ(AC)、トンネル対応ルータ、または仮想化ネットワーク機能(VNF)であってよい。
【０１１８】
図５ａは実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするように動作する第１のネットワークノード１０の例を示す模式図である。この例において、第１のネットワークノード１０は基本的にプロセッサ１１、付随するメモリ１２、およびオプションの通信回路１３とを有する。オプションの通信回路１３は、１つ以上の他のノードとの、情報の送信および／または受信を含む無線および／または有線通信のために構成されている。
【０１１９】
図５ａの特定の例に示されるように、第１のネットワークノード１０はプロセッサ１１とメモリ１２とを有し、メモリ１２は第１のネットワークノード１０の動作を実行するためにプロセッサ１１によって実行可能な命令を有している。そのため、この例示的な実施形態において、プロセッサ１１はトンネルで第２のネットワークノードに送信するためのユーザパケットをカプセル化するように動作し、各ユーザパケットはトンネルについてのバイト損失量に関する情報を有する。プロセッサ１１はさらに、第２のネットワークノードから受信される、トンネルについての輻輳量情報を読み取るように動作する。プロセッサ１１はまた、受信した、トンネルについての輻輳量情報に基づいてそのトンネルについてのネットワーク輻輳ポリシングを適用するか、受信した、トンネルについての輻輳量情報に基づくそのトンネルについてのネットワーク輻輳ポリシングを可能にするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードに転送するように動作する。
【０１２０】
図５ａに示すように、第１のネットワークノード１０は、情報の送信および／または受信を含む通信を１つ以上の他のノードと行うための通信回路１３をさらに含んでもよい。従って、ある特定の実施形態において第１のネットワークノード１０は、カプセル化されたユーザパケットをトンネルで第２のネットワークノードに送信するように構成された通信回路１３を有し、各ユーザパケットはトンネルについてのバイト損失量に関する情報を有する。通信回路１３は、トンネルについての輻輳量情報を第２のネットワークノードから受信するようにさらに構成される。通信回路１３は、受信した、トンネルについての輻輳量情報に基づく、トンネルについてのネットワーク輻輳ポリシングを可能とするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードに転送するように必要に応じて構成されてもよい。
【０１２１】
第２のネットワークノード
一実施形態によれば、第２のネットワークノードは無線ネットワーク内のネットワーク輻輳管理を可能にするように構成される。第２のネットワークノードは、カプセル化されたユーザパケットをトンネルで第１のネットワークノードから受信するように構成され、受信される各ユーザパケットは、そのトンネルについてのバイト損失量に関する情報を有する。第２のネットワークノードはさらに、トンネルについてのバイト損失量に関する情報に基づいて、トンネルについての輻輳量情報を決定するように構成される。第２のネットワークノードはまた、決定した、トンネルについての輻輳量情報に基づく、トンネルについてのネットワーク輻輳ポリシングを可能にするために、決定した、トンネルについての輻輳量情報を第１のネットワークノードに送信するように構成される。
【０１２２】
上述したように、一実施形態において、トンネルについてのバイト損失量に関する情報は、そのトンネルについてのバイトシーケンス番号を有することができる。この実施形態において、第２のネットワークノードは、受信したバイトシーケンス番号が予期されるものよりも大きい場合、すなわち、先行するユーザパケットのバイトシーケンス番号に、先行するユーザパケットのユーザペイロードサイズを加えたものよりも大きい場合に、トンネルについてのバイト損失量を検出するように構成される。
【０１２３】
上述したように、一実施形態において、トンネルについてのバイト損失量に関する情報は、そのトンネルについてのパケットシーケンス番号を有する。この実施形態において、第２のネットワークノードは、受信したパケットシーケンス番号が予期されるものより大きい場合、すなわち、先行するユーザパケットのパケットシーケンス番号に１を加えたものよりも大きい場合に、トンネルについてのバイト損失量を検出するように構成される。
【０１２４】
一実施形態において、第２のネットワークノードは、トンネルについての輻輳量情報を、そのトンネルについてのバイト輻輳量に関する情報にも基づいて決定するように構成される。なお、そのような、トンネルについてのバイト輻輳量に関する情報は、受信されるユーザパケット内に含まれてよい。ある特定の実施形態において、トンネルについてのバイト輻輳量に関する情報は、トンネルについてのネットワーク輻輳を示す、IPヘッダ内で提供される明示的輻輳通知(ECN)のマーキングを有する受信ユーザパケットを有する。そのような実施形態において、第１のネットワークノードから送信されるユーザパケットが、第１のネットワークノードがトンネルについてECNに対応していることを示すECNマーキングを有する必要があることはいうまでもない。
【０１２５】
一部の例示的な実施形態において、第２のネットワークノードはeNodeB (エヴォルブドNode B)、NodeB、アクセスポイント(AP)、在圏ゲートウェイ(SGW)、無線ネットワークコントローラ(RNC)、アクセスコントローラ(AC)、トンネル対応ルータ、または仮想化ネットワーク機能(VNF)であってよい。
【０１２６】
図５ｂは実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするように動作する第２のネットワークノード２０の例を示す模式図である。この例において、第２のネットワークノード２０は基本的にプロセッサ２１、付随するメモリ２２、およびオプションの通信回路２３とを有する。オプションの通信回路２３は、１つ以上の他のノードとの、情報の送信および／または受信を含む無線および／または有線通信のために構成されている。
【０１２７】
図５ｂの特定の例に示されるように、第２のネットワークノード２０はプロセッサ２１とメモリ２２とを有し、メモリ２２は第２のネットワークノード２０の動作を実行するためにプロセッサ２１によって実行可能な命令を有している。そのため、この例示的な実施形態においてプロセッサ２１は、トンネルで第１のネットワークノードから受信される、カプセル化されたユーザパケットを受信するように動作し、受信されるユーザパケットのそれぞれはそのトンネルについてのバイト損失量に関する情報を有する。プロセッサ２１はさらに、トンネルについてのバイト損失量に関する情報に基づいてトンネルについての輻輳量情報を決定するように動作する。プロセッサ２１はまた、決定された、トンネルについての輻輳量情報に基づく、そのトンネルについてのネットワーク輻輳ポリシングを可能とするために、決定された、トンネルについての輻輳量情報を第１のネットワークノードに送信するために用意するように動作する。
【０１２８】
図５ｂに示すように、第２のネットワークノード２０は、１つ以上の他のノードと、情報の送信および／または受信を含む通信を行うための通信回路２３をさらに含んでもよい。従って、ある特定の実施形態において第２のネットワークノード２０は、カプセル化されたユーザパケットをトンネルで第１のネットワークノードから受信するように構成された通信回路２３を有し、受信されるユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有する。通信回路２３はさらに、決定された輻輳量情報に基づくネットワーク輻輳ポリシングを可能とするために、トンネルについての輻輳量情報を第１のネットワークノードに送信するように構成され、トンネルについての輻輳量情報は、トンネルについてのバイト輻輳量に関する情報に基づいて決定される。
【０１２９】
第３のネットワークノード
一実施形態によれば、第３のネットワークノードは、無線ネットワーク内のネットワーク輻輳を管理するように構成される。第３のネットワークノードはトンネルについての輻輳量情報を第１のネットワークノードから受信するように構成され、受信する輻輳量情報は第２のネットワークノードによって決定されて第１のネットワークノードによって転送されており、第３のネットワークノードはさらに、受信した、トンネルについてのネットワーク輻輳量情報に基づいてそのトンネルについてのネットワーク輻輳ポリシングを適用するように構成される。
【０１３０】
ある特定の実施形態において、第３のネットワークノードは、第１のネットワークノード宛てのユーザパケットが破棄される破棄確率に基づいてトンネルについてのネットワーク輻輳ポリシングを適用するようにさらに構成される。ある特定の実施形態において、第３のネットワークノードは、受信する輻輳量情報に含まれ、かつ第２のネットワークノードから輻輳量情報が出発した時刻の、可能な範囲で最良の推定時刻として規定される出口タイムスタンプに基づいて、破棄確率を決定するように構成される。
【０１３１】
一部の実施形態において、第３のネットワークノードはパケットゲートウェイ(PGW)、在圏GPRSサポートノード(SGSN)、ゲートウェイGPRSサポートノード(GGSN)、トンネル対応ルータ、または仮想化ネットワーク機能(VNF)であってよい。
【０１３２】
図５ｃは実施形態に係る、無線ネットワーク内のネットワーク輻輳を管理するように動作する第３のネットワークノード３０の例を示す模式図である。この例において、第３のネットワークノード３０は基本的にプロセッサ３１、付随するメモリ３２、およびオプションの通信回路３３とを有する。オプションの通信回路３３は、１つ以上の他のノードとの、情報の送信および／または受信を含む無線および／または有線通信のために構成されている。
【０１３３】
図５ｃの特定の例に示されるように、第３のネットワークノード３０はプロセッサ３１とメモリ３２とを有し、メモリ３２は第３のネットワークノード３０の動作を実行するためにプロセッサ３１によって実行可能な命令を有している。そのため、この例示的な実施形態においてプロセッサ３１は、第１のネットワークノードから受信される、トンネルについての輻輳量情報を読み取るように動作し、受信される輻輳量情報は第２のネットワークノードによって決定され、第１のネットワークノードによって転送されている。プロセッサ３１はさらに、受信した、トンネルについての輻輳量情報に基づいて、そのトンネルについてのネットワーク輻輳ポリシングを適用するように動作する。
【０１３４】
図５ｃに示すように、第３のネットワークノード３０は、情報の送信および／または受信を含む通信を１つ以上の他のノードと行うための通信回路３３をさらに含んでもよい。従って、ある特定の実施形態において第３のネットワークノード３０は、トンネルについての輻輳量情報を第１のネットワークノードから受信するように構成された通信回路３３を有し、受信する輻輳量情報は第２のネットワークノードによって決定され、第１のネットワークノードによって転送されている。
【０１３５】
上述の通り、上述したステップ、機能、手順、モジュール、および／またはブロックの少なくとも一部は、１つ以上のプロセッサを含む適切な処理回路による実行のためのコンピュータプログラムのようなソフトウェアに実装されてよい。そのような実装の例を、図６ａ〜ｃに模式的に示す。
【０１３６】
図６ａに模式的に示す一実施形態によれば、コンピュータプログラム１４は命令を有し、命令は少なくとも１つのプロセッサ１１によって実行された際に、１つ以上のプロセッサに、第１のネットワークノードから第２のネットワークノードへトンネルで送信するためにユーザパケットをカプセル化し、ここで各ユーザパケットはそのトンネルについてのバイト損失量に関する情報を有し、第１のネットワークノードで受信された、トンネルについての輻輳量情報を読み出し、さらに、受信した、トンネルについての輻輳量情報に基づいてトンネルについてのネットワーク輻輳ポリシングを適用するか、受信した、トンネルについての輻輳量情報に基づく、トンネルについてのネットワーク輻輳ポリシングを可能にするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードに転送するために準備する、ようにさせる。
【０１３７】
図６ｂに模式的に示す別の実施形態によれば、コンピュータプログラム２４は命令を有し、命令は、少なくとも１つのプロセッサ２１によって実行された際に、１つ以上のプロセッサに、トンネルで第１のネットワークノードから送信され、第２のネットワークノードで受信された、カプセル化されたユーザパケットを読み取り、ここで、受信されたユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有し、トンネルについてのバイト損失量情報に基づいて、トンネルについての輻輳量情報を決定し、さらに、決定した、トンネルについての輻輳量情報に基づく、トンネルについてのネットワーク輻輳ポリシングを可能にするために、決定した、トンネルについての輻輳量情報を、第２のネットワークノードから第１のネットワークノードに転送するために準備する、ようにさせる。
【０１３８】
図６ｂのコンピュータプログラム２４の特定の実施形態によれば、受信したユーザパケットのそれぞれは、トンネルについてのバイト輻輳量に関する情報をさらに有し、トンネルについての輻輳量情報が、トンネルについてのバイト輻輳量に関する情報にさらに基づく。特定の実施形態において、トンネルについてのバイト輻輳量に関する情報は、IPヘッダで提供され、トンネルについてのネットワーク輻輳を示す明示的輻輳通知(ECN)マーキングを有する受信ユーザパケットを有する。そのような実施形態において、第１のネットワークノードから送信されるユーザパケットが、第１のネットワークノードがトンネルについてECNに対応していることを示すECNマーキングを有する必要があることは言うまでもない。
【０１３９】
さらに別の実施形態によれば、コンピュータプログラム３４は命令を有し、命令は、少なくとも１つのプロセッサ３１によって実行された際に、１つ以上のプロセッサに、第１のネットワークノードから受信した、トンネルについての輻輳量情報を読み出し、ここで、受信した輻輳量情報は第２のネットワークノードで決定され、第１のネットワークノードによって転送され、さらに、受信した、トンネルについての輻輳量情報に基づいてトンネルについてのネットワーク輻輳ポリシングを適用する、ようにさせる。
【０１４０】
一例として、ソフトウェアまたはコンピュータプログラムは、通常、コンピュータ可読媒体、特には不揮発性媒体に記憶または保存されるコンピュータプログラム製品として実現されてよい。コンピュータ可読媒体は、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、コンパクトディスク(CD)、DVD (Digital Versatile Disc)、ブルーレイディスク、USB (Universal Serial Bus)メモリ、ハードディスクドライブ(HDD)記憶装置、フラッシュメモリ（登録商標）、磁気テープ、または他の一般的な記憶装置のいずれかを非限定的な例として含む、リムーバブルまたは非リムーバブル記憶装置の１つ以上を含むことができる。従ってコンピュータプログラムは、コンピュータまたは同等の処理装置の処理回路による実行のために、コンピュータまたは同等の処理装置のオペレーティングメモリに読み込まれてよい。
【０１４１】
提案する技術はさらに、図６ａ〜ｃに図示し、かつ上述したコンピュータプログラム１４、２４、３４の１つ以上を有するキャリア１５、２５、３５を提供し、キャリアは電子信号、光信号、電磁気信号、磁気信号、電気信号、無線信号、マイクロ波信号、またはコンピュータ可読記憶媒体の１つである。
【０１４２】
先に提示した１つ以上のフロー図は、１つ以上のプロセッサによって実行される場合、１つ以上のコンピュータフロー図と見なすことができる。対応するネットワークノードは機能モジュール群として規定することができ、プロセッサによって実行される各ステップが１つの機能モジュールに対応する。この場合、機能モジュールはプロセッサ上で稼働するコンピュータプログラムとして実装される。従って、ネットワークノードは代わりに機能モジュール群として規定されても良く、機能モジュールは少なくとも１つのプロセッサ上で稼働するコンピュータプログラムとして実装される。
【０１４３】
従って、メモリに存在するコンピュータプログラムは、プロセッサによって実行された際に、ここで説明したステップおよび／またはタスクの少なくとも一部を実行するように構成された適切な機能モジュールとして編成されてよい。そのような機能モジュールの例を図７ａ〜ｃに示す。
【０１４４】
図７ａは一実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするための第１のネットワークノードの例を示す模式的なブロック図である。この例において第１のネットワークノード１０は、ユーザパケットをトンネルで第２のネットワークノードに送信するためにカプセル化するためのカプセル化／送信モジュール１００を有し、各ユーザパケットはトンネルについてのバイト損失量に関する情報を有する。第１のネットワークノード１０はさらに、第２のネットワークノードから受信した、トンネルについての輻輳量情報を読み取るための受信モジュール３００を有する。第１のネットワークノード１０はまた、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するポリシングモジュール２００、および／または、受信した、トンネルついての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを可能にするために、受信した、トンネルについての輻輳量情報を第３のネットワークノードに転送するために用意するための転送モジュール４００を有することができる。第１のネットワークノード１０は、ポリシングモジュール２００または転送モジュール４００の一方、あるいは両方を有することができる。これは、図７ａにおいて点線で示されている。
【０１４５】
図７ｂは一実施形態に係る、無線ネットワーク内のネットワーク輻輳管理を可能にするための第２のネットワークノード２０の例を示す模式的なブロック図である。この例において、第２のネットワークノード２０は、第１のネットワークノードからトンネルで受信された、カプセル化されたユーザパケットを読み取るための受信モジュール１１０を有し、受信されたユーザパケットのそれぞれはトンネルについてのバイト損失量に関する情報を有している。第２のネットワークノード２０はさらに、トンネルについてのバイト損失量に関する情報に基づいてトンネルについての輻輳量情報を決定するための決定モジュール１２０を有する。第２のネットワークノード２０はまた、決定された、トンネルについての輻輳量情報に基づく、トンネルについてのネットワーク輻輳ポリシングを可能にするために、決定された、トンネルについての輻輳量情報を第１のネットワークノードに送信するために準備するための送信モジュール１３０を有する。
【０１４６】
ある特定の実施形態において、決定モジュール１２０は、トンネルについての輻輳量情報を、そのトンネルについてのバイト輻輳量に関する情報にも基づいて決定し、そのような、トンネルについてのバイト輻輳量に関する情報は、受信されるユーザパケット内に含まれてよい。ある特定の実施形態において、トンネルについてのバイト輻輳量に関する情報は、IPヘッダで提供され、トンネルについてのネットワーク輻輳を示す明示的輻輳通知(ECN)マーキングを有する受信ユーザパケットを有する。そのような実施形態において、第１のネットワークノードから送信されるユーザパケットは、第１のネットワークノードがトンネルについてECNに対応していることを示すECNマーキングを有する必要があることは言うまでもない。
【０１４７】
図７ｃは一実施形態に係る、無線ネットワーク内のネットワーク輻輳を管理するための第３のネットワークノード３０の例を示す模式的なブロック図である。この例において、第３のネットワークノード３０は、第１のネットワークノードから受信した、トンネルについての輻輳量情報を読み取るための受信モジュール６００を有し、受信した輻輳量情報は第２のネットワークノードによって決定され、第１のネットワークノードによって転送されている。第３のネットワークノード３０はさらに、受信した、トンネルについての輻輳量情報に基づいて、トンネルについてのネットワーク輻輳ポリシングを適用するためのポリシングモジュール５００を有する。
【０１４８】
「有する」または「有している」という単語が用いられる場合、それは非限定的に、すなわち「少なくとも有する」を意味するものとして解釈されるべきである。
【０１４９】
ここで用いられる場合、非限定的な用語「ユーザ端末」および「無線機器」は、携帯電話機、セルラーフォン、無線通信能力を備える携帯情報端末(PDA)、スマートフォン、内蔵もしくは外付けモバイルブロードバンドモデムを備えるラップトップまたはパーソナルコンピュータ(PC)、無線通信能力を有するタブレットPC、ターゲットデバイス、デバイスツーデバイスUE、マシンタイプUEまたはマシンツーマシン通信可能なUE、iPad、加入者宅内機器(CPE)、ラップトップ内蔵機器(LEE)、ラップトップ取り付け機器(LME)、USBドングル、携帯電子無線通信機器、無線通信能力を備えるセンサ機器などを意味しうる。特に、用語「UE」および用語「無線機器」は、セルラーもしくはモバイル通信システム内の無線ネットワークノードを通信する任意のタイプの無線機器、またはセルラーもしくはモバイル通信システムの中での通信のための任意の関連規格に従った無線通信のための無線回路を備える任意の機器を含む、非限定的な用語として解釈されるべきである。
【０１５０】
ここで用いられる場合、非限定的な用語「ネットワークノード」は、基地局、ネットワークコントローラ、無線ネットワークコントローラ、基地局コントローラなどのネットワーク制御ノード、および上で例示したような無線機器を意味しうる。特に、用語「基地局」は、Node BもしくはeNodeB (evolved Node B)のような規格化された基地局に加え、マクロ／マイクロ／ピコ無線基地局、フェムト基地局としても知られるホーム基地局、中継ノード、リピータ、無線アクセスポイント、基地送受信局(BTS)、さらには、１つ以上のリモート無線ユニット(RRU)を制御する無線制御ノードなどを含む、様々なタイプの無線基地局を包含しうる。
【０１５１】
ここに記載した方法および装置は、様々な方法で組み合わせたり再構成することが可能であることが理解されるであろう。
【０１５２】
例えば、実施形態はハードウェア、適切な処理回路によって実行するためのソフトウェア、またはそれらの組み合わせで実施することができる。
【０１５３】
ここに記載したステップ、機能、手順、モジュール、および／またはブロックは、汎用電子器回路および用途に特化した回路の両方を含む、ディスクリート回路または集積回路技術のような任意の従来技術を用いるハードウェアで実施することができる。
【０１５４】
具体的な例には、１つ以上の適切に構成されたデジタルシグナルプロセッサおよび他の既知の電子回路、例えば特化した機能を実行するための相互接続されたディスクリート論理ゲート、または特定用途向け集積回路(ASIC)が含まれる。
【０１５５】
処理回路の例には、１つ以上のマイクロプロセッサ、１つ以上のデジタルシグナルプロセッサ(DSP)、１つ以上の中央処理ユニット(CPU)、ビデオアクセラレーションハードウェア、および／または、１つ以上のフィールドプログラマブルゲートアレイ(FPGA)または１つ以上のプログラマブルロジックコントローラ(PLC)のような任意の好適なプログラマブルロジック回路が含まれるが、これらに限定されない。
【０１５６】
提案した技術が実装されている任意の従来機器またはユニットの汎用処理能力を再利用することも可能でありうることもまた理解すべきである。例えば既存のソフトウェアを再プログラミングしたり、新たなソフトウェアコンポーネントを追加したりすることにより、既存のソフトウェアを再利用することもまた可能であろう。
【０１５７】
用語「プロセッサ」は、特定の処理、判断、または計算タスクを実行するためにプログラムコードまたはコンピュータプログラム命令を実行可能な任意のシステムまたは機器として、一般的な意味で解釈されるべきである。
【０１５８】
従って、１つ以上のプロセッサを含む処理回路は、コンピュータプログラムを実行する際、上述したような十分に定義された処理タスクを実行するように構成される。
【０１５９】
処理回路は上述したステップ、機能、手順、および／またはブロックだけを実行することに特化される必要は無く、他のタスクも実行してよい。
【０１６０】
上述した実施形態は単に例として提供されたものであって、提案した技術はそれらに限定されないことを理解すべきである。添付の特許請求の範囲によって規定される範囲内で実施形態に様々な修正、組み合わせ、および変更を行いうることは、本技術分野に属する当業者に理解されるであろう。特に、異なる実施形態における異なる部分の解決方法を、技術的に可能な他の構成に組み合わせることができる。
【０１６１】
略語集
略語  説明
AMBR  総計最大ビットレート(Aggregate Maximum Bit Rate)
AMCR  総計最大輻輳ビットレート(Aggregate Maximum Congestion bitrate)
AP  アクセスポイント(Access Point)
APN  アクセスポイント名(Access Point Name)
AC  アクセスコントローラ(Access Controller)
BB  帯域幅ボトルネック(Bandwidth Bottleneck)
BPS  ビット／秒(Bits Per Second)
CAPWAP  無線アクセスポイントの制御及びプロビジョニング(Control and Provisioning of Wireless Access Points)
CDO  ConEx宛先オプション(ConEx Destination Option)
CE  輻輳体験(Congestion Experienced)
CBR  輻輳ビットレート(Congestion Bitrate)
CONEX  輻輳露出(Congestion Exposure)
DL  ダウンリンク(Downlink)
DSCP  Diffservコードポイント(Diffserv Codepoint)
ECN  明示的輻輳通知(Explicit Congestion Notification)
EPC  エヴォルブドパケットコア(Evolved Packet Core)
E-UTRAN  エヴォルブドUMTS地上無線アクセスネットワーク(Evolved UMTS Terrestrial Radio Access Network)
eNB  E-UTRANノードB(E-UTRAN NodeB)
GBR  保証ビットレート(Guaranteed Bit Rate)
GRE  総称ルーティングカプセル化(Generic Routing Encapsulation)
GTP  GPRAトンネリングプロトコル(GPRS Tunneling Protocol)
GTP-U  GTPユーザ(GTP User)
IP  インターネットプロトコル(Internet Protocol)
IPsec  IPセキュリティ(IP Security)
IE  情報要素(Information Element)
Kb  キロバイト(Kilo Bytes)
LAN  ローカルエリアネットワーク(Local Area Network)
LTE  ロングタームエヴォリューション(Long Term Evolution)
MME  移動性管理エンティティ(Mobility Management Entity)
MB  メガバイト(Mega Bytes)
NMS  ネットワーク管理システム(Network Management System)
NTP  ネットワークタイムプロトコル(Network Time Protocol)
OAM  運用、管理、および保守(Operations, Administration and Management)
PID  比例積分微分(Proportional Integral Derivative)
PD  比例微分(Proportional Derivative)
PDN  パケットデータネットワーク(Packet Data Network)
PGW  PDNゲートウェイ(PDN Gateway)
RTT  往復(Round-trip)
SACK  選択的確認応答(Selective Acknowledgement)
SGW  在圏ゲートウェイ(Serving Gateway)
SN  シーケンス番号(Sequence Number)
TCP  トランスミッションコントロールプロトコル(Transmission Control Protocol)
TEID  トンネルエンドポイント識別子(Tunnel Endpoint Identifier)
UDP  ユーザデータグラムプロトコル(User Datagram Protocol)
UE  ユーザ端末(User Equipment)
Uu  eNBとUEとの間のインタフェース(Interface between the eNB and UE)
WLAN  無線ローカルエリアネットワーク(Wireless Local Area Network)
【０１６２】
参考文献
[1] GPRS トンネリングプロトコルユーザプレーン (GTPv1-U), 3GPP TS 29.281
[2] 無線アクセスポイントの制御およびプロビジョニング (CAPWAP), IETF,RFC 5415
[3] 総称ルーティングカプセル化, IETF, RFC 2784
[4] E-UTRAN アクセス, 3GPP TS 23.401
[5] IPへの明示的輻輳通知(ECN)の追加, IETF, RFC 3168
[6] 輻輳露出コンセプトおよびユースケース, IETF, RFC 6789
[7] ConExのためのIPv6 宛先オプション, draft-ietf-conex-destopt-06
[8] TCP 選択的確認応答オプション, IETF, RFC 2018
[9] インターネットプロトコルのためのセキュリティアーキテクチャ, IETF, RFC 4301
[10] Zhang et al、ローカライズされた輻輳露出：米国特許出願公開第2012/0051216号明細書
[11] バイトおよびパケット輻輳通知, IETF, draft-briscoe-tsvwg-byte-pkt-mark-02
[12] ポイントツーポイントトンネリングプロトコル, IETF, RFC 2637
[13] GREに対するキーおよびシーケンス番号拡張, IETF, RFC 2890
[14] ネットワークタイムプロコトルバージョン４: プロトコルおよびアルゴリズム仕様, RFC 5905
【図１ａ】
0006363201.tif 000002
【図１ｂ】
0006363201.tif 000003
【図１ｃ】
0006363201.tif 000004
【図２】
0006363201.tif 000005
【図３】
0006363201.tif 000006
【図４】
0006363201.tif 000007
【図５ａ】
0006363201.tif 000008
【図５ｂ】
0006363201.tif 000009
【図５ｃ】
0006363201.tif 000010
【図６ａ】
0006363201.tif 000011
【図６ｂ】
0006363201.tif 000012
【図６ｃ】
0006363201.tif 000013
【図７ａ】
0006363201.tif 000014
【図７ｂ】
0006363201.tif 000015
【図７ｃ】
0006363201.tif 000016
【図８】
0006363201.tif 000017
【図９】
0006363201.tif 000018
【図１０】
0006363201.tif 000019
【図１１】
0006363201.tif 000020
【図１２】
0006363201.tif 000021
【図１３】
0006363201.tif 000022
【図１４】
0006363201.tif 000023
【図１５】
0006363201.tif 000024
【図１６】
0006363201.tif 000025
【図１７】
0006363201.tif 000026
【図１８】
0006363201.tif 000027
【図１９】
0006363201.tif 000028
【図２０】
0006363201.tif 000029
【図２１】
0006363201.tif 000030
【図２２】
0006363201.tif 000031
【図２３】
0006363201.tif 000032