特許 7054737 通信システムにおいてパッシブラウンドトリップタイム（ＲＴＴ）遅延を判定する方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-04-06

(45)【発行日】2022-04-14

(54)【発明の名称】通信システムにおいてパッシブラウンドトリップタイム（ＲＴＴ）遅延を判定する方法

(51)【国際特許分類】

   H04L 47/283 20220101AFI20220407BHJP

【ＦＩ】

H04L47/283

【請求項の数】 15

(21)【出願番号】P 2020544443

(86)(22)【出願日】2018-03-28

(65)【公表番号】

(43)【公表日】2021-07-01

(86)【国際出願番号】 EP2018057884

(87)【国際公開番号】W WO2019166108

(87)【国際公開日】2019-09-06

【審査請求日】2020-10-16

(31)【優先権主張番号】18382122.2

(32)【優先日】2018-02-28

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】100109726

【弁理士】

【氏名又は名称】園田 吉隆

(74)【代理人】

【識別番号】100161470

【弁理士】

【氏名又は名称】冨樫 義孝

(74)【代理人】

【識別番号】100194294

【弁理士】

【氏名又は名称】石岡 利康

(74)【代理人】

【識別番号】100194320

【弁理士】

【氏名又は名称】藤井 亮

(72)【発明者】

【氏名】ゴッチ ガルシア， イボン

(72)【発明者】

【氏名】ムニョース キルシュベルク， ハビエル

【審査官】宮島 郁美

(56)【参考文献】

【文献】国際公開第２０１３／０５７７７３（ＷＯ，Ａ１）

【文献】特開２００３－１６３６８５（ＪＰ，Ａ）

【文献】米国特許第０７６３６３２１（ＵＳ，Ｂ１）

【文献】国際公開第２０１７／１３１５６５（ＷＯ，Ａ１）

【文献】特開２００９－２９０５２４（ＪＰ，Ａ）

【文献】特開２００５－１１７５８７（ＪＰ，Ａ）

【文献】特開２０１７－０１７５８７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ１２／００－１３／１８，４１／００－６９／４０

(57)【特許請求の範囲】

【請求項1】

通信システム（１）に動作可能に接続された第１のデバイス（４）と第２のデバイス（６）との間でデータ伝送プロトコルに従ってデータパケット（２ａ～２ｄ）を交換するための前記通信システム（１）においてパッシブラウンドトリップタイム（ＲＴＴ）遅延を判定する方法であって、前記第１のデバイス（４）が、第１のデバイス識別によって識別され、前記第２のデバイス（６）が、第２のデバイス識別によって識別され、前記データパケット（２ａ～２ｄ）が、ソースアドレス（３ｂ）および宛先アドレス（３ａ）を含むアドレス部分（３）を含み、前記方法が、
ａ．前記通信システム（１）内のノード（５）によって、前記第１のデバイス（４）に由来し、かつ、前記第２のデバイス（６）に向けられたデータパケット（２ａ）を受信するステップであって、前記データパケット（２ａ）の前記アドレス部分（３）の前記ソースアドレスが前記第１のデバイス識別であり、前記データパケット（２ａ）の前記アドレス部分（３）の前記宛先アドレスが前記第２のデバイス識別である、データパケット（２ａ）を受信するステップと、
ｂ．前記受信されたデータパケット（２ａ）の前記ソースアドレスである前記第１のデバイス識別を、前記ノード（５）によって、修正するステップと、
ｃ．修正されたデータパケット（２ｂ）を提供するように、前記ソースアドレスである前記修正された第１のデバイス識別および前記宛先アドレスである前記第２のデバイス識別を含むアドレス部分を有する前記受信されたデータパケット（２ａ）を、前記ノード（５）によって、修正するステップと、
ｄ．前記データパケット（２ａ）の前記アドレス部分（３）の少なくとも前記ソースアドレスを前記修正されたデータパケット（２ｂ）の前記アドレス部分の前記ソースアドレスである前記修正された第１のデバイス識別にリンクさせることによって、アドレス変換テーブル（７）において、前記ノード（５）によって、前記受信されたデータパケット（２ａ）の前記アドレス部分を前記修正されたデータパケット（２ｂ）の前記アドレス部分とリンクさせるステップと、
ｅ．前記修正されたデータパケット（２ｂ）を前記第２のデバイス（６）に、前記ノード（５）によって、第１の時点において、送信するステップと、
ｆ．前記ノード（５）によって、第２の時点において、前記第２のデバイス（６）から、さらなるデータパケット（２ｃ）を受信するステップであって、前記さらなるデータパケット（２ｃ）の前記アドレス部分の前記宛先アドレスが、前記修正された第１のデバイス識別であり、前記さらなるデータパケット（２ｃ）の前記アドレス部分の前記ソースアドレスが、前記第２のデバイス識別であり、前記さらなるデータパケット（２ｃ）が、前記修正されたデータパケット（２ｂ）に応答している、さらなるデータパケット（２ｃ）を受信するステップと、
ｇ．修正されたさらなるデータパケット（２ｄ）を提供するように、前記アドレス変換テーブル（７）を使用する、前記宛先アドレスである前記第１のデバイス識別および前記ソースアドレスである前記第２のデバイス識別を含むアドレス部分を有する前記受信されたさらなるデータパケット（２ｃ）を、前記ノード（５）によって、修正するステップと、
ｈ．前記修正されたさらなるデータパケット（２ｄ）を前記第１のデバイス（４）に、前記ノード（５）によって、送信するステップと、
ｉ．前記第１のおよび第２の時点から前記ＲＴＴ遅延を、前記ノード（５）によって、判定するステップと
を含み、前記ノード（５）は、前記通信システム（１）のアクセスネットワーク内に位置する、方法。

【請求項2】

前記第１のデバイス（４）が、前記通信システム（１）のアクセスネットワークに接続するユーザ機器（ＵＥ）（５１）であり、前記第２のデバイス（６）が、前記通信システム（１）のサーバ（５３）であり、前記ＲＴＴが、アップリンク通信方向でのラウンドトリップタイムクライアント（ＲＴＴｃ）遅延について測定される、請求項１に記載の方法。

【請求項3】

前記第１のデバイス（４）が、前記通信システム（１）のサーバ（５３）であり、前記第２のデバイス（６）が、前記通信システム（１）のアクセスネットワークに接続するユーザ機器（ＵＥ）（５１）であり、前記ＲＴＴが、ダウンリンク通信方向におけるラウンドトリップタイムサーバ（ＲＴＴｓ）遅延について測定される、請求項１に記載の方法。

【請求項4】

前記データ伝送プロトコルが、インターネットプロトコル（ＩＰ）タイプデータ伝送プロトコルであり、データパケット（２ａ～２ｄ）の前記アドレス部分（３）が、前記第１のデバイス（４）のソースＩＰアドレスおよびポート番号、前記第２のデバイス（６）の宛先ＩＰアドレスおよびポート番号、および前記データ伝送プロトコルを識別するプロトコル識別を含む５－ｔｕｐｌｅ情報を含み、前記ノード（５）が、前記受信されたデータパケット（２ａ）の前記アドレス部分を修正する前に、前記アドレス部分（３）に含まれる前記プロトコル識別をチェックし、ステップｂ～ｉが、前記プロトコル識別に応じて実行される、請求項１から３のいずれか一項に記載の方法。

【請求項5】

前記プロトコル識別が、クイックユーザデータグラムプロトコル（ＵＤＰ）インターネット接続（ＱＵＩＣ）プロトコルを指すとき、ステップｂ～ｉが、実行される、請求項４に記載の方法。

【請求項6】

前記第１のデバイス識別を修正するステップが、前記ソースＩＰアドレスおよびポート番号のうちの１つまたは両方を修正することを含む、請求項５に記載の方法。

【請求項7】

前記ソースポート番号を修正することが、
－ 前記ソースポート番号を１だけインクリメントすること、
－ 前記ソースポート番号を１だけデクリメントすること、
－ 前記ソースポート番号を任意の整数値だけインクリメントすること、
－ 前記ソースポート番号を任意の整数値だけデクリメントすること
のうちの１つを含む、請求項６に記載の方法。

【請求項8】

前記ソースＩＰアドレスが、ホスト部分およびネットワーク部分を含み、前記ソースＩＰアドレスを修正することが、
－ 前記ソースＩＰアドレスを１だけインクリメントすること、
－ 前記ソースＩＰアドレスを１だけデクリメントすること、
－ 前記ソースＩＰアドレスを任意の整数値だけインクリメントすること、
－ 前記ソースＩＰアドレスを任意の整数値だけデクリメントすること
のうちの１つによって前記ホスト部分を修正することを含む、請求項５または６に記載の方法。

【請求項9】

前記さらなるデータパケット（２ｃ）を受信するステップが、前記宛先アドレスである前記修正された第１のデバイス識別および前記ソースアドレスである前記第２のデバイス識別を含むアドレス部分を有する第１のさらなるデータパケットを受信するまで、前記第２のデバイス（６）から受信されたデータパケット（２ｃ）の前記アドレス部分（３）を、前記ノード（５）によって、検査することを含む、請求項１から８のいずれか一項に記載の方法。

【請求項10】

前記第１のデバイス（４）から受信された前記データパケット（２ａ）を修正するステップが、前記第１のデバイス（４）から受信された同じデータストリームのすべての後続のデータパケットに、前記ノード（５）によって、適用される、請求項１から９のいずれか一項に記載の方法。

【請求項11】

前記第２のデバイス（６）から受信された前記さらなるデータパケット（２ｃ）を修正するステップが、前記第２のデバイス（６）から受信された同じデータストリームのすべての後続のさらなるデータパケットに、前記ノード（５）によって、適用される、請求項１から１０のいずれか一項に記載の方法。

【請求項12】

前記第１の時点および前記第２の時点が、前記ノード（５）に記憶された前記アドレス変換テーブル（７）に第１のタイムスタンプおよび第２のタイムスタンプとして記憶される、請求項１から１１のいずれか一項に記載の方法。

【請求項13】

前記ノード（５）が、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（Ｐ－ＧＷ）（５２）および前記通信システム（１）の前記アクセスネットワーク内に配置されたポリシ制御および施行ポイント（ＰＣＥＰ）のうちの１つである、請求項１から１２のいずれか一項に記載の方法。

【請求項14】

通信システム（１）に動作可能に接続された第１のデバイス（４）と第２のデバイス（６）との間でデータ伝送プロトコルに従ってデータパケット（２ａ～２ｄ）を交換するためのパッシブラウンドトリップタイム（ＲＴＴ）遅延を判定するための、前記通信システム内で動作するように配置された、ノード（５）であって、前記ノード（５）が、前記データパケット（２ａ～２ｄ）を交換するためのトランシーバデバイス（８）、アドレス変換テーブル（７）を記憶するための記憶デバイス（９）、およびコンピュータ制御されたＲＴＴ測定デバイス（１０）を備え、前記ＲＴＴ測定デバイス（１０）が、請求項１から１３のいずれか一項に記載の方法を実行するために前記トランシーバデバイス（８）および前記記憶デバイス（９）を制御するように配置された、ノード（５）。

【請求項15】

プログラムコードを備える、コンピュータプログラムであって、前記プログラムコードが、通信システム（１）に動作可能に接続された第１のデバイス（４）と第２のデバイス（６）との間でデータ伝送プロトコルに従ってデータパケット（２ａ～２ｄ）を交換するために前記通信システム（１）内に配置されたノード（５）のコンピュータによって前記プログラムコードが実行されたときに、請求項１から１３のいずれか一項に記載の方法を実行するためのコンピュータ命令を含む、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、概して電気通信に関し、より詳細には、通信システムに動作可能に接続されたデバイスの間のデータ伝送プロトコルに従ったデータパケットの交換のための通信システムに関する。本開示はさらに、方法を運用するためのゲートウェイ機能性を提供するための１つまたは複数のサーバを設定するためのコンピュータプログラムコード命令を含むコンピュータ可読記憶媒体に関する。

【背景技術】

【0002】

ラウンドトリップタイム（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）は、第１のまたはクライアントデバイス、たとえば、通信システム内のサーバまたはノード、が要求を第２のデバイス、たとえば、通信システム内の別のサーバまたは別のノード、に送るときからのおよび第１のデバイスが第２のデバイスからの応答を受信するときの、一般にミリ秒で測定される、持続期間である。ＲＴＴは、たとえば、ネットワークロードおよびネットワークレイテンシの通信システムにおける極めて重要な性能測定基準である。ＲＴＴは、一般に、フローまたは５－ｔｕｐｌｅごとに測定され、高次アグリゲーションが可能である（ユーザ機器（ＵＥ）とネットワークノードとの間のＲＴＴなど）。

【0003】

通信システムを目的としておよびその適用例について、クライアントとサーバとの間の双方向通信において、ＲＴＴは、一般に、通信システムからクライアントに向けて、ＲＴＴｃと呼ばれる、および通信システムからサーバに向けて、ＲＴＴｓと呼ばれる、およびフローまたは５－ｔｕｐｌｅごとに、指向的に計算される。ＲＴＴはまた、２つのサーバの間または２つのクライアントの間など、同等の能力を有するピアの間で測定され得る。

【0004】

クライアントがアクセスネットワーク、たとえば、無線アクセスネットワーク（ＲＡＮ）、を介して通信システムにアクセスする、通信システムにおけるクライアントとサーバとの間の通信の場合、ＲＴＴｃは、ダウンリンクにおいてクライアントに向けてサーバによって送信されるセグメントまたはデータパケットがアクセスネットワーク内のモニタリングポイント、たとえば、ノード、を横断してから、サーバに向けた肯定応答がアップリンク内の同じモニタリングポイントを横断するまでの時間として計算することができる。

【0005】

そのような通信において、ＲＴＴは、アップリンクにおけるサーバに向けたセグメントまたはデータパケットノードがアクセスネットワーク内のモニタリングポイントを横断してから、クライアントに向けた肯定応答がダウンリンク内の同じモニタリングポイントを横断するまでの時間として計算することができる。

【0006】

ＲＴＴ測定を使用する適用例および使用事例は、以下を含み得る：
ａ．体感の質の測定および分析論：たとえば、モバイル通信システムのような通信システムにおいて、ＲＴＴｃは、アクセスネットワーク、たとえば、ＲＡＮ、を含むクライアントまでの距離を表す。高いＲＴＴｃ値は、クライアントへの情報の送信における問題、たとえば、データパケットの過度のバッファリング、誤った経路指定の結果としての過多な伝送ホップ、低データレート伝送線など、を示し得る。同様に、高いＲＴＴｓ値はまた、過度のバッファリングおよび遅い伝送線を指摘し得るが、コンテンツを供給する問題を示し得る遠隔のまたは高負荷の（応答の遅延が存在する）サーバにクライアントがアクセスしていることもまた示し得る。
ｂ．トラフィック最適化：制御された遅延アプローチリレーに基づく－ＣｏＤｅｌアルゴリズムなどのいくつかのアクティブキュー管理（ＡＱＭ：Ａｃｔｉｖｅ Ｑｕｅｕｅ Ｍａｎａｇｅｍｅｎｔ）技法のトラフィック最適化実装形態－クライアントおよびサーバの両方に向けた５－ｔｕｐｌｅまたはフローごとのＲＴＴ測定は、ＲＴＴ知識を必要とする。

【0007】

フローまたは５－ｔｕｐｌｅごとのＲＴＴ測定を使用する通信システムにおけるいくつかの他の適用例および使用事例がある。

【0008】

通信システムからのＲＴＴ計算は、アクティブにおこなうことができ、通信システムは、データパケットまたはメッセージをノードに送り、応答を待ち、経過時間を測定する、あるいはパッシブに、通信システムによって既に運ばれている加入者トラフィックを使用する。

【0009】

アクティブＲＴＴ測定は、インターネット制御メッセージプロトコル（ＩＣＭＰ：Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）メッセージ（通常は「ピング」の送信と呼ばれる）を含む。パッシブＲＴＴ測定は、データパケットの受信器がその受信を確認するために要する時間を測定することによって、伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のようなある種のトランスポートプロトコルで利用可能である。そのような技法は、先行技術に包含される。

【0010】

アクティブＲＴＴ測定は、通信システムが追加のトラフィックを送ることを必要とし、パケットまたはメッセージの受信器がその処理をサポートすることおよびそれに答えることを必要とする。したがって、それは、すべてのネットワーク要素によってサポートされない協調的手続きである。また、それは、明らかな手続きであり－実装されるとき、通信システムが測定を実行していることが明確であり－情報漏洩につながる可能性があり、改ざんに弱くなり得る。

【0011】

通信システムは、既存のトラフィックを再使用してＲＴＴを計算し、すべてのエンドポイントはパッシブＲＴＴ測定をサポートするので、パッシブＲＴＴ測定は、エンドポイントからのサポートを必要としない。パッシブＲＴＴ測定はまた、「サイレント」である－通信システムがある特定のフローでＲＴＴ測定を実行しているかどうかを告げることは不可能である。パッシブＲＴＴ測定はまた、追加のトラフィックを生み出さず、必要とされるメッセージを転送するために中間要素に依存しない。

【0012】

パッシブ先行技術ＲＴＴ測定は、ある特定のプロトコルでのみ機能し得る。通信システムは、透過的に測定を実施することができるように、ＲＴＴの測定を可能にするための基本的トラフィックを運ぶプロトコルを必要とする。

【0013】

ＴＣＰは、パッシブ先行技術ＲＴＴ測定を可能にするそのようなプロトコルのうちの１つである。通信システムは、たとえば、ディープパケットインスペクション（ＤＰＩ：Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ）技法を使用して－ある特定のＴＣＰノードのシーケンス番号を検査し、後で肯定応答をそれらのノードに相互に関連付けることができるので、パッシブＲＴＴ測定は、加入者ＴＣＰトラフィックを有する通信システムにおいて可能である。

【0014】

ＴＣＰは、シーケンス番号および肯定応答を含むので、クライアントまたはサーバがある特定のシーケンス番号の受信を確認するのに要する時間としてＲＴＴを測定することは比較的容易である（そして、よく知られている）。ＴＣＰは、双方向であり、したがって、ＲＴＴｃおよびＲＴＴｓの計算を可能にする。

【0015】

検査されるノードは相手側で肯定応答を生成すると想定し、肯定応答を生み出すために相手側のＴＣＰスタックが要する時間を無視して、時間の差はその方向でのＲＴＴであると想定することができる。送信時間は、一般に、処理時間の数桁大きいので、これは事実である。

【0016】

他の主要なトランスポートレベルプロトコルは、たとえば、ユーザデータグラムプロトコル（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）およびクイックＵＤＰインターネット接続（ＱＵＩＣ：Ｑｕｉｃｋ ＵＤＰ Ｉｎｔｅｒｎｅｔ Ｃｏｎｎｅｃｔｉｏｎｓ）プロトコルである。

【0017】

ＱＵＩＣは、ユーザデータグラムプロトコル（ＵＤＰ）の最上部で実行する「半トランスポート」プロトコルである。ＵＤＰおよびＱＵＩＣの追加は、正常な配信、再送信、輻輳制御および終端間暗号化を含むトランスポートプロトコルのすべての特徴および機能性を届ける。

【0018】

ＱＵＩＣは、アクセスネットワークに関する変化に対して回復性がある。内部識別子が、同じ概念的ＱＵＩＣ（トランスポートレベル）フロー内への異なるソースＩＰアドレスおよびポートからの２つの５－ｔｕｐｌｅ ＵＤＰフローをサーバがリンクさせることを可能にするＱＵＩＣにおいて規定される。

【0019】

この回復力の使用事例は、通信システム変更を横断してＱＵＩＣフロー（および状況）を保持することである－加入者が、通信システムの接続を切り、異なる通信システムに再び加わるとき、ＱＵＩＣフローは回復することが可能であり、再交渉は必要とされず、暗号化コンテキストが取得および再使用され、そして、アプリケーションデータ交換は、影響を受けないままであり続けることが可能である。

【0020】

ＱＵＩＣは、同じＱＵＩＣフローに２つの５－ｔｕｐｌｅ ＵＤＰフロー（異なるソースＩＰアドレスおよびポートを有する）をリンクさせることによって、この回復機能を実装することができる。

【0021】

ＵＤＰおよびＱＵＩＣは、たとえば、シーケンス番号または肯定応答番号を含まないプロトコルの例であり、そして、含まれるとき、ＵＤＰまたはＱＵＩＣを介する先行技術のパッシブＲＴＴ測定を不可能にする、ＱＵＩＣの場合のように、それらは暗号化される。これは、先行技術のパッシブＲＴＴ測定を使用する、前述の使用事例、たとえば、体感の質（ＱｏＥ：Ｑｕａｌｉｔｙ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）測定またはいくつかのトラフィック最適化、のうちのいくつかはＱＵＩＣトラフィックに適用することができないことを意味する。

【0022】

米国特許出願第２００３／１０６０６７（Ａ１）号は、ネットワークアドレス変換（ＮＡＴ）ファイアウォール、プロキシなどのゲートウェイサービスのケーブルモデムおよび／またはセットトップボックスなどのＲＦケーブルデバイスへの統合を開示する。

【0023】

米国特許第７６３６３２１（Ｂ１）号は、単一測定ポイントを使用する通信ネットワークにおける送信器と受信器との接続のＲＴＴを計算するための方法およびシステムに関する。本方法は、測定ポイントを通過する第１のパケットのタイムスタンプ処理、および前記測定を通過する第２のパケットのタイムスタンプ処理を含む。

【発明の概要】

【0024】

通信システムにおいて２つのデバイスの間でデータパケットが交換されることによって体感されるＲＴＴｓをパッシブに測定することが、本明細書の実施形態の目的である。

【0025】

本開示の第１の態様では、通信システムに動作可能に接続された第１のデバイスと第２のデバイスとの間でデータ伝送プロトコルに従いデータパケットを交換するための通信システムにおいてパッシブラウンドトリップタイム（ＲＴＴ）遅延を判定する方法が提示され、第１のデバイスは、第１のデバイス識別によって識別され、第２のデバイスは、第２のデバイス識別によって識別され、データパケットは、ソースアドレスおよび宛先アドレスを含むアドレス部分を含む。

【0026】

本方法は、以下のステップを含む：
ａ．通信システム内のノードによって、第１のデバイスに由来するおよびし、かつ、第２のデバイスに向けられたデータパケットを受信するステップであって、データパケットのアドレス部分のソースアドレスは第１のデバイス識別であり、データパケットのアドレス部分の宛先アドレスは宛先アドレスとしての第２のデバイス識別である、データパケットを受信するステップと、
ｂ．受信されたデータパケットのソースアドレスである第１のデバイス識別を、ノードによって、修正するステップと、
ｃ．修正されたデータパケットを提供するように、ソースアドレスである修正された第１のデバイス識別および宛先アドレスである第２のデバイス識別を含むアドレス部分を有する受信されたデータパケットを、ノードによって、修正するステップと、
ｄ．データパケットのアドレス部分の少なくともソースアドレスを修正されたデータパケットのアドレス部分のソースアドレスである修正された第１のデバイス識別にリンクさせることによって、アドレス変換テーブルにおいて、ノードによって、受信されたデータパケットのアドレス部分を修正されたデータパケットのアドレス部分とリンクさせるステップと、
ｅ．第１の時点において、ノードによって、修正されたデータパケットを第２のデバイスに送信するステップと、
ｆ．第２の時点において、第２のデバイスから、ノードによって、さらなるデータパケットを受信するステップであって、さらなるデータパケットのアドレス部分の宛先アドレスは、修正された第１のデバイス識別であり、さらなるデータパケットのアドレス部分のソースアドレスは、ソースアドレスとしての第２のデバイス識別である、さらなるデータパケットを受信するステップと、
ｇ．修正されたさらなるデータパケットを提供するように、アドレス変換テーブルを使用する、宛先アドレスである第１のデバイス識別およびソースアドレスである第２のデバイス識別を含むアドレス部分を有する受信されたさらなるデータパケットを、ノードによって、修正するステップと、
ｈ．修正されたさらなるデータパケットを第１のデバイスに、ノードによって、送信するステップと、
ｉ．第１のおよび第２の時点からＲＴＴ遅延を、ノードによって、判定するステップ、
そこで、ノードは、通信システムのアクセスネットワーク内に位置する。

【0027】

本開示による方法は、たとえば、データパケットの配信のために利用可能なアドレス部分以外の、識別子が暗号化され得る、データパケットにおける、シーケンス番号または識別子、肯定応答番号または識別子、へのアクセスに依存しない。

【0028】

さらなるデータパケット内の修正された第１のデバイス識別を検出および識別することは、本開示によるＲＴＴ計算を可能にする。したがって、本開示による方法は、一般に、通信システムにおいて適用される様々なデータ伝送プロトコルに適用可能である。本開示によりＲＴＴをパッシブに測定することによって、通信ネットワークにおける追加のシグナリングが、効果的に回避される。

【0029】

アドレス変換テーブルを使用する受信されたさらなるデータパケットをノードによって修正することと、修正されたさらなるデータパケットを第１のデバイスに送信することとによって、第１のデバイスは、本開示によるＲＴＴ計算または測定を目的としてデータパケットにおこなわれる修正を通知しないことになる。

【0030】

本開示および請求項で使用されるアドレス部分という用語は、データパケットの起点またはソースまたは宛先に関するそれぞれのネットワークまたはデータ伝送プロトコルレベルの任意のレベルでのデータパケットの任意の部分を参照するものとして解釈されるものとする。前述のように、ＲＴＴは、しばしば、指向的に測定される、すなわち、ＲＴＴｃおよびＲＴＴｓ。一実施形態によれば、第１のデバイスは、通信システムのアクセスネットワークに接続するユーザ機器（ＵＥ）であり、第２のデバイスは、通信システムのサーバであり、ＲＴＴは、アップリンク通信方向でのラウンドトリップタイムクライアント（ＲＴＴｃ）遅延について測定される。

【0031】

別の実施形態によれば、第１のデバイスは、通信システムのサーバであり、第２のデバイスは、通信システムのアクセスネットワークに接続するユーザ機器（ＵＥ）であり、ＲＴＴは、ダウンリンク通信方向におけるラウンドトリップタイムサーバ（ＲＴＴｓ）遅延について測定される。

【0032】

さらなる実施形態において、データ伝送プロトコルは、インターネットプロトコル（ＩＰ）タイプデータ伝送プロトコルであり、データパケットのアドレス部分は、第１のデバイスのＩＰアドレスおよびポート番号と、第２のデバイスのＩＰアドレスおよびポート番号と、データ伝送プロトコルを識別するプロトコル識別とを含む、５－ｔｕｐｌｅ情報を含み、受信されたデータパケットのアドレス部分を修正する前にノードは、アドレス部分に含まれるプロトコル識別をチェックし、ステップｂ～ｉが、プロトコル識別に応じて実行される。すなわち、適用される修正は、特定の識別されたプロトコルに依存し得る。

【0033】

ＲＴＴは、フローごとにまたは５－ｔｕｐｌｅごとに測定され得る。５－ｔｕｐｌｅは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）接続を含む５つの異なる値のセットを指す。それは、ソースＩＰアドレス／ポート番号、宛先ＩＰアドレス／ポート番号および使用中のプロトコルを含む。別法として、ＱＵＩＣプロトコルもまた、使用され得る。

【0034】

本開示の一実施形態において、プロトコル識別が、クイックＵＤＰインターネット接続（ＱＵＩＣ）プロトコルを指すとき、ステップｂ～ｉが、実行され得る。

【0035】

本開示による方法の一実施形態において、第１のデバイス識別を修正することは、ソースＩＰアドレスおよびポート番号のうちの１つまたは両方を修正することを含む。ソースＩＰアドレスは、使用されていないまたは通信システムのそれぞれのノードによる通信において使用されていない範囲からＩＰアドレスを選択することによって、修正され得る。しかしながら、ＩＰアドレスはまた、予約された範囲からまたは他の方法で一意的に選択され得る。

【0036】

本開示の一実施形態によれば、ソースポート番号を修正することは、以下のうちの１つを含む：
－ ソースポート番号を１だけインクリメントすること、
－ ソースポート番号を１だけデクリメントすること、
－ ソースポート番号を任意の整数値だけインクリメントすること、
－ ソースポート番号を任意の整数値だけデクリメントすること。

【0037】

本方法の別の実施形態によれば、ソースＩＰアドレスは、ホスト部分およびネットワーク部分を含み、ソースＩＰアドレスを修正することは、以下のうちの１つによってホスト部分を修正することを含む：
－ ソースＩＰアドレスを１だけインクリメントすること、
－ ソースＩＰアドレスを１だけデクリメントすること、
－ ソースＩＰアドレスを任意の整数値だけインクリメントすること、
－ ソースＩＰアドレスを任意の整数値だけデクリメントすること。

【0038】

ＩＰアドレスを修正するとき、たとえば、一時的にまたは恒久的に、修正されたＩＰアドレスが固有である、すなわちノードの通信で使用されていない、かどうかがチェックされ得る。

【0039】

本開示の一実施形態によれば、さらなるデータパケットを受信することは、宛先アドレスとしての修正された第１のデバイス識別およびソースアドレスとしての第２のデバイス識別を含むアドレス部分を有する第１のさらなるデータパケットを受信するまで、第２のデバイスから受信されたデータパケットのアドレス部分を、ノードによって、検査することを含む。

【0040】

単一データパケットで動作するのではなくて、本開示の一実施形態では、第１のデバイスから受信されたデータパケットを修正することが、第１のデバイスからおよび／または第２のデバイスから受信された同じデータストリームのすべての後続のデータパケットに、ノードによって、適用される。

【0041】

本開示による方法の一実施形態において、第１の時点および第２の時点は、ノードに記憶されたアドレス変換テーブル内の第１のタイムスタンプおよび第２のタイムスタンプとして記憶される。

【0042】

ノードは、パケットデータネットワーク（ＰＤＮ：Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）ゲートウェイ（Ｐ－ＧＷ）および通信システムのアクセスネットワーク内に配置されたポリシ制御および施行ポイント（ＰＣＥＰ：Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ ａｎｄ Ｅｎｆｏｒｃｅｍｅｎｔ Ｐｏｉｎｔ）のうちの１つでもよい。

【0043】

本開示の第２の態様において、通信システムに動作可能に接続された第１のデバイスと第２のデバイスとの間でデータ伝送プロトコルに従いデータパケットを交換するためのパッシブラウンドトリップタイム（ＲＴＴ）遅延を判定するための、通信システム内で動作するように配置された、ノードが提示され、そのノードは、データパケットを交換するためのトランシーバデバイス、アドレス変換テーブルを記憶するための記憶デバイス、およびコンピュータ制御されたＲＴＴ測定デバイスを備え、ＲＴＴ測定デバイスは、前の請求のいずれかによる方法を実行するためにトランシーバデバイスおよび記憶デバイスを制御するために配置される。

【0044】

本開示の第３の態様において、コンピュータ可読媒体に記憶されたプログラムコードを含む、コンピュータプログラム製品が提示され、プログラムコードは、通信システムに動作可能に接続された第１のデバイスと第２のデバイスとの間でデータ伝送プロトコルに従ってデータパケットを交換するための通信システム内に配置されたノードのコンピュータによってプログラムコードが実行されたとき、本開示の第１の態様で提示された実施形態のいずれかに従って方法を実行するためのコンピュータ命令を含む。

【0045】

本開示の前述のおよび他の態様が、使用中のパケットデータトランスポートまたはデータトラフィックプロトコルとしてクイックユーザデータグラムプロトコル（ＵＤＰ）インターネット接続（ＱＵＩＣ）プロトコルを想定して、後述の例を参照して明らかになるおよび説明されることになる。しかしながら、本開示はＱＵＩＣプロトコルに限定されるものとして解釈されるべきではないことにはっきりと留意されたい。

【図面の簡単な説明】

【0046】

【図1】パッシブＲＴＴ測定のためのデータパケットを交換するための通信システムを概略的に示す。

【図2】本開示による方法の一般的ステップを流れ図タイプの図に示す。

【図3】ＵＤＰレベルマーキング（ＵＤＰポート）を介するＱＵＩＣトラフィックのＲＴＴｓ計算を図表で表す。

【図4】ＵＤＰレベルマーキング（ＵＤＰポート）を介するＱＵＩＣトラフィックのＲＴＴｃ計算を図表で表す。

【図5】ＵＤＰレベルマーキング（ＩＰアドレス）を介するＱＵＩＣトラフィックのＲＴＴｓ計算を図表で表す。

【図6】ＵＤＰレベルマーキング（ＩＰアドレス）を介するＱＵＩＣトラフィックのＲＴＴｃ計算を図表で表す。

【発明を実施するための形態】

【0047】

図１で、参照数字１は、たとえば、無線アクセスネットワーク（ＲＡＮ）などのアクセスネットワークの中間ノード５によって、通信システム１に動作可能に接続された第１のデバイス４と第２のデバイス６との間でデータ伝送プロトコルに従ってデータパケット２ａ～２ｄを交換するための通信システム１を指す。第１のデバイス４は、第１のデバイス識別によって識別され、第２のデバイス６は、第２のデバイス６識別によって識別される。たとえば、送信を目的とするコンテンツ部分、プリアンブルおよび／または他の部分の中の、データパケット２ａ～２ｄは、宛先アドレス３ａおよびソースアドレス３ｂを含むアドレス部分３をそれぞれ含む。本開示および請求項で使用されるとき、アドレス部分という用語は、データパケットの起点またはソースまたは宛先に関するそれぞれのネットワークまたはデータ伝送プロトコルレベルの任意のレベルでのデータパケットの任意の部分を指すと解釈されるものとする。

【0048】

第１のデバイス４から第２のデバイス６に送信されるデータパケットの場合、このデータパケットのソースアドレス３ｂは第１のデバイス識別を指し、宛先アドレス３ａは第２のデバイス識別を指す。第２のデバイス６から第１のデバイス４に送信されるデータパケットの場合、このデータパケットのソースアドレス３ｂは第２のデバイス識別を指し、宛先アドレス３ａは第１のデバイス識別を指す。

【0049】

ノード５は、第１のデバイス４と第２のデバイス６との間で通信システム１においてデータパケット２ａ～２ｄを交換するために配置されたトランシーバ機器８を備える。第１のデバイス４から第２のデバイス６に送信される、データパケット２ａが、ノード５によって受信されるとき、ノード５は、データパケットを第２のデバイス６に送信する前にデータパケット２ａのソースアドレス部分３ｂを修正する。修正されたソースアドレス部分３ｂを有する、修正されたデータパケット２ｂは、次いで、ノード５によって第２のデバイス６に送信される。ノード５において、データパケット２ａの少なくともソースアドレス部分３ｂをデータパケット２ｂの修正されたアドレス部分３にリンクさせるアドレス変換テーブル７が保持される。データパケット２ｂを第２のデバイス６に送信する、第１の時点、前に、ノードは、データパケット２ｂがノード５によって送信された第１の時点を識別するための第１のタイムスタンプを保持する。

【0050】

第２の時点において、第１の時点の後に、第２のデバイス６は、受信されたデータパケット２ｂに応答して、さらなるデータパケット２ｃを送信する。このさらなるデータパケット２ｃの宛先アドレス部分３ａは、データパケット２ｂの修正されたソースアドレス部分３ｂを含み、このさらなるデータパケット２ｃのソースアドレス部分３ｂは、第２のデバイス識別を指す。ノード５でのこのさらなるデータパケット２ｃの受信時に、ノード５は、さらなるデータパケット２ｃを第１のデバイス４に送信する前に、アドレス変換テーブル７に記憶されたアドレス部分３との一致についてさらなるデータパケット２ｃのアドレス部分３を検査する。さらなるデータパケット２ｃのアドレス部分３は、データパケット２ｂのアドレス部分３のエントリに基づく、アドレス変換テーブル７にそのコンテンツが記憶された、データパケット２ｂのアドレス部分３のコンテンツを含むので、ノード５は、アドレス変換テーブル７に保持されたデータパケット２ａのソースアドレス部分によってこのさらなるデータパケット２ｃの宛先アドレス部分３ａを置き換えることによって、さらなるデータパケット２ｃのアドレス部分３を修正する。これは、データパケット２ｄが第１のデバイス４にノード５によって送信される結果をもたらす。ノード５においてさらなるデータパケット２ｃを受信する第２の時点、ノード５は、データパケット２ｃがノード５によって受信された時間を識別するために、第２のタイムスタンプを保持する。

【0051】

たとえば、２つのタイムスタンプの差から、またはノード５における処理時間を他の方法で考慮して、ノード５は、次いで、ノード５および第２のデバイス６を接続する通信システム１の部分においてデータパケット２ｂおよび２ｃの送信に関するそれぞれのＲＴＴを判定する。

【0052】

上記で開示された方法は、第１のデバイス４とノード５との間の、通信システム１の部分におけるＲＴＴを測定するために、ノード５と第１のデバイス４との間のデータパケット交換のために、類似の方式で、適用され得ることが理解されよう。

【0053】

図２は、流れ図タイプの図式２０において、上記で開示されたステップを示し、時間は、図の最上部から最下部に流れると想定される。

【0054】

ブロック２１、「データパケットを受信すること」、は、ノード５におけるデータパケット２ａの受信を指す。ブロック２２、「ソースアドレスを修正すること」、は、第１のデバイス識別の、受信されたデータパケット２ａのソースアドレス３ａの、ノード５による、修正を指す。ブロック２３、「修正されたデータパケットを提供すること」、は、ソースアドレス３ｂとしての修正された第１のデバイス識別と宛先アドレス３ａとしての第２のデバイス識別とを含むアドレス部分を有する修正されたデータパケット２ｂを提供するように、受信されたデータパケット２ａの、ノード５による、修正を示す。ブロック２４、「アドレス部分をリンクさせること」、は、修正されたデータパケット２ｂのアドレス部分３との受信されたデータパケット２ａのアドレス部分３の、アドレス変換テーブル７における、ノード５による、リンクを指す。

【0055】

ブロック２５、「修正されたデータパケットを送信」、は、修正されたデータパケット２ｂを、第１の時点において、ノード５によって、第２のデバイス６に、送信することを指す。ブロック２６、「さらなるデータパケットを受信すること」、は、宛先アドレス３ａとしての修正された第１のデバイス識別およびソースアドレス３ｂとしての第２のデバイス識別を含むアドレス部分３を有するさらなるデータパケット２ｃの、ノード５における、第１の時点より後の第２の時点における、受信を示す。ブロック２７、「修正されたさらなるデータパケットを提供すること」、は、宛先アドレス３ａとしての第１のデバイス識別およびソースアドレス３ｂとしての第２のデバイス識別を含むアドレス部分３を有する、修正されたさらなるデータパケット２ｄを提供するように、アドレス変換テーブル７を使用する受信されたさらなるデータパケット２ｃの、ノード５による、修正を指す。

【0056】

ブロック２８、「修正されたさらなるデータパケットを送信すること」、は、第１のデバイス４への修正されたさらなるデータパケット２ｄの、ノード５による、送信を示す。ブロック２９、「ＲＴＴ遅延を判定すること」、は、第１のおよび第２の時点からのＲＴＴ遅延の、ノード５による、計算を指す。

【0057】

本方法は、任意の２つのピアの間のまたは異なる階層レベル－たとえばＵＥおよびサーバ－に位置する２つのデバイスの間のＲＴＴを判定するために使用され得ることが、当業者には理解されよう。アップリンク方向について、第１のデバイス４またはクライアントは、通信システム１のアクセスネットワークに接続するユーザ機器（ＵＥ）、たとえば、ＲＡＮに接続するモバイルＵＥ、でもよい。アップリンク通信方向でのラウンドトリップタイムクライアント（ＲＴＴｃ）遅延について、第２のデバイス６は、通信システム１のサーバでもよい。ダウンリンク通信方向におけるラウンドトリップタイムサーバ（ＲＴＴｓ）遅延を測定するために、第１のデバイス４は、通信システム１のサーバであり、第２のデバイス６は、ユーザ機器（ＵＥ）である。

【0058】

修正されたデータパケット２ｂが、ノード５によって送信された後は、さらなるデータパケット２ｃをノード５において受信することは、宛先アドレスとしての第１のデバイス４の修正されたソースアドレスおよび第２のデバイス６を指すソースアドレスを含むアドレス部分３を有する第１のさらなるデータパケット２ｃを受信するまで、第２のデバイス６から受信された各データパケットのアドレス部分３を、ノード５によって、検査することを含む。

【0059】

データパケットのアドレス部分３の修正は、アドレス部分が指すそれぞれのデバイス識別の修正を含み得る。

【0060】

インターネットプロトコル（ＩＰ）タイプデータ伝送プロトコルでは、データパケットのアドレス部分３は、第１のデバイス識別としての第１のデバイス４のＩＰアドレスおよびポート番号と、第２のデバイス識別としての第２のデバイス６のＩＰアドレスおよびポート番号と、データ伝送プロトコルを識別するプロトコル識別とを含む、５－ｔｕｐｌｅ情報を含む。ノード５は、受信されたデータパケット２ｂのアドレス部分３を修正する前に、アドレス部分３に含まれるプロトコル識別をチェックすることができる。完全性を目的として、ポート番号は、トランスポートレベル、すなわちレベル４、を指し、ＩＰアドレスは、概念的７レイヤオープンシステム相互接続（ＯＳＩ：Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）通信モデルのネットワークレベル、すなわちレベル３、を指すことに留意されたい。

【0061】

したがって、ＩＰデータタイプ伝送プロトコルでは、ソースＩＰアドレスおよびポート番号のうちの１つまたは両方を修正することによってデバイス識別を修正することが可能である。ソースポート番号を修正することは、以下のうちの１つを含み得る：
－ ソースポート番号を１だけインクリメントすること、
－ ソースポート番号を１だけデクリメントすること、
－ ソースポート番号を任意の整数値だけインクリメントすること、
－ ソースポート番号を任意の整数値だけデクリメントすること。

【0062】

ソースＩＰアドレスは、ホスト部分およびネットワーク部分を含み、ソースＩＰアドレスを修正することは、以下のうちの１つによってホスト部分を修正することを含む：
－ ソースＩＰアドレスを１だけインクリメントすること、
－ ソースＩＰアドレスを１だけデクリメントすること、
－ ソースＩＰアドレスを任意の整数値だけインクリメントすること、
－ ソースＩＰアドレスを任意の整数値だけデクリメントすること。

【0063】

ＩＰアドレスを修正するとき、修正されたＩＰアドレスは、たとえば、一時的にまたは恒久的に、固有であるか、すなわち、ノードの通信において使用されていないか、あるいは修正されたＩＰアドレスは予約された範囲の部分であるかまたは他の方法で一意的であるかがチェックされ得る。ノード５による、第２のデバイス６から受信されたさらなるデータパケット２ｃのアドレス部分の修正が、第２のデバイス６から受信された同じデータストリームのすべての後続のさらなるデータパケット２ｃに適用されるように、第１のデバイス４から受信されたデータパケット２ａのアドレス部分を修正することは、第１のデバイス４から受信された同じデータストリームのすべての後続のデータパケット２ａに、ノード５によって、適用され得る。

【0064】

第１の時点および第２の時点は、ノード５において記憶された、アドレス変換テーブル７に第１のタイムスタンプおよび第２のタイムスタンプとして記憶され得る。ノード５は、たとえば、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（Ｐ－ＧＷ）あるいは通信システム１のアクセスネットワーク内に配置されたポリシ制御および施行ポイント（ＰＣＥＰ）でもよい。

【0065】

本開示によるパッシブラウンドトリップタイム（ＲＴＴ）遅延を判定するための、通信システム１内で動作するためのノード５は、アドレス変換テーブル７を記憶するための記憶デバイス９、および、図１に参照数字１０によって図式的に示された、コンピュータ制御されたＲＴＴ測定デバイスを有して配置されることになり、ＲＴＴ測定デバイス１０は、パッシブラウンドトリップタイム計算を実行するためにトランシーバ機器８および記憶デバイス９を制御するために配置される。

【0066】

本発明で説明される技法および機構は、任意のクラウド実装形態に適用可能である。

【0067】

この技法は、クライアントに向けたおよびサーバに向けたＲＴＴのパッシブ計算のための透過的マーキング機構をもたらす。

【0068】

本技法は、すべてのシナリオにおいて、２つのエンドポイントのうちの１つに向けて完全に透過的である。その他のエンドポイントに向けて、パッシブモニタリングは、アクセスネットワークの変更（割り当てられたＩＰアドレスまたはポートにおいて変更された）と類似の効果をもたらし得る。本解決法は、フローごとの複数のＲＴＴ測定を可能にする。本解決法は、アクセスネットワーク変更に対する回復機能を可能にするクイックＵＤＰインターネット接続（ＱＵＩＣ）プロトコルデータトラフィックおよびＵＤＰを介する他の半トランスポートプロトコルを実現する。ＲＴＴのパッシブ計算は、ＱｏＥ測定の実装、分析論使用事例およびトラフィックの最適化を可能にする。

【0069】

以下の例は、ＱＵＩＣプロトコルの場合のＲＴＴの計算を、図３を参照して、説明することになる。

【0070】

この例は、パケットゲートウェイ（Ｐ－ＧＷ）５２またはポリシ制御および施行ポイント関数（ＰＣＥＦ：Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ ａｎｄ Ｅｎｆｏｒｃｅｍｅｎｔ Ｐｏｉｎｔ Ｆｕｎｃｔｉｏｎ）５２において必要とされる機能性での実装形態を想定し、これは、図１による、通信システム１内にあるようなモバイルアクセスネットワークのノード５である。

【0071】

この例では、以下のステップは、データパケット２のアドレス部分３を使用するＲＴＴｓの計算のために従われるべきであり、具体的には、この例では、ポート値はアドレス部分３であり、第１のデバイス４はソースであり、第２のデバイス６はサーバである。図３～６を参照する特定の例において、デバイス５１は、ＵＥまたはＱＵＩＣクライアントであり、そして、デバイス５３は、ＵＥ５１が通信するＱＵＩＣサーバである。

【0072】

Ｐ－ＧＷ５２での実装形態は、以下の５－ｔｕｐｌｅ情報２ａでＱＵＩＣフローを識別する５５。新しいパッシブＲＴＴｓ測定が必要とされるとき、Ｐ－ＧＷ５２は、選択されたＱＵＩＣフローのアップリンクで新しいデータパケット２ａを待つことになる。データパケットがＰ－ＧＷ５２で受信される５７とき、ソースポート３は、１だけインクリメントされる５８。別法として、ソースポート３は、任意の他の値だけインクリメントまたはデクリメントされ得る。

【0073】

Ｐ－ＧＷ５２は、ＵＥ５１からの「古いソースポート」、「新しいソースポート」およびＵＤＰ ５－ｔｕｐｌｅの残りの値を記憶することによって、テーブルにこの修正５８を記憶することになる。データパケットは、次いで、新しいソースポート３を有するサーバ５３に送られる５９。Ｐ－ＧＷ５２は、このイベント５９、すなわち、アップリンクデータパケット２ｂの修正および転送、のタイムスタンプを記憶する。

【0074】

このＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のアップリンク上のすべての後続のデータパケット２ｂについて、値「古いソースポート」を有するソースポート３は、「新しいソースポート」値に置き換えられるべきである。Ｐ－ＧＷ５２は、５－ｔｕｐｌｅ３の４つの最初のパラメータとマッチするダウンリンクトラフィック６１を検査する。具体的には：プロトコルＵＤＰ、ソースＩＰアドレスｓｒｖＩＰ、ソースポートｓｒｖＰｏｒｔおよび宛先ＩＰアドレスｕｅＩＰ ＩＰアドレスおよびポートが、アップリンクからミラーリングされる。

【0075】

ダウンリンクのデータパケット２ｃが、このフィルタとマッチするとき、宛先ポートをチェックする。宛先ポートが、「古いソースポート」とマッチする場合、データパケット２ｄが転送され、このデータパケット２ｄは修正されたアップリンクデータパケット２ｃのための肯定応答ではないと想定される。

【0076】

「新しいソースポート」とマッチする宛先ポートを有する、前のフィルタとマッチする第１のデータパケット６１について、新しいタイムスタンプが、修正されたアップリンクデータパケット２ｃの第１の肯定応答をシグナリングするＰ－ＧＷ５２に記憶される。ＲＴＴｓが、記録された２つのタイムスタンプの差として、計算される６２。したがって、ＲＴＴｓは、修正されたデータパケットを送信する５９ときに取得される第１のタイムスタンプとフィルタとマッチする第１のデータパケットが受信される６１ときに取得される第２のタイムスタンプとの時間差として測定される。

【0077】

このデータパケット２ｃ以降－およびこのＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のダウンリンクで受信されるすべてのデータパケット２ｃについて－値「新しいソースポート」を含む宛先ポートは、最初の値「古いソースポート」に置き換えられるべきである６３。この機構は、ＲＴＴｓ測定ごとに、アップリンクでの１つだけのポート変更（サーバによって検出される）を導入し、すべての後続のデータパケット２ｃのダウンリンクで変更がなされていないとき、ダウンリンクでは変更はない（クライアントによって検出可能な変更なし）。

【0078】

あるＲＴＴｓ測定が完了した後は、別のＲＴＴｓ測定が、ソースポート３の付加的インクリメント（またはデクリメント）を導入することによって、同じフローで実行され得る。導入されるソースポート３変更は、クライアント／ＵＥ５１のアクセスネットワーク変更またはクライアント／ＵＥ５１に影響を及ぼすキャリアグレードネットワークアドレス変換（ＣＧＮＡＴ：Ｃａｒｒｉｅｒ Ｇｒａｄｅ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）変更をシミュレーションする。そのような変更は、クライアント／ＵＥポートのみに影響を及ぼし、ＩＰアドレスには影響しないことが可能であるので、これはより典型的である。

【0079】

類似のステップが、図４を参照して説明される、ポートマーキングを使用するＲＴＴｃの計算のために従われるべきである。この例１００では、Ｐ－ＧＷ５２は、アクセスネットワーク５であり、第１のデバイス４は、ＱＵＩＣサーバ５３であり、第２のデバイス６は、クライアント／ＵＥ５１０であり、アドレスデータパケット３の修正された情報は、ポート値である。

【0080】

Ｐ－ＧＷ５２での実装形態は、以下の５－ｔｕｐｌｅ情報でＱＵＩＣフロー５５を識別する：トランスポートプロトコルとしてのＵＤＰと、クライアントＩＰアドレスおよびポートがｕｅＩＰおよびｕｅＰｏｒｔであることと、サーバＩＰアドレスおよびポートがｓｒｖＩＰおよびｓｒｖＰｏｒｔであること。

【0081】

新しいパッシブＲＴＴｃ測定が必要とされるとき、Ｐ－ＧＷ５２は、選択されたＱＵＩＣフロー５６のダウンリンクで新しいデータパケット１０１を待つことになる。データパケットが受信される１０１とき、ソースポートは、１だけインクリメントされる１０２。別法として、ソースポートは、任意の他の値だけインクリメントまたはデクリメントされ得る。Ｐ－ＧＷ５２は、サーバからの「古いソースポート」、「新しいソースポート」およびＵＤＰ ５－ｔｕｐｌｅの残りの値を記憶することによって、テーブルにこの修正を記憶することになる。

【0082】

データパケット２ｂは、次いで、新しいソースポートを有するＵＥ５１に送られる１０３。Ｐ－ＧＷ５２は、このイベント（ダウンリンクデータパケット２ｂの修正および転送）のタイムスタンプを記憶する。このＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のダウンリンクのすべての後続のデータパケット２ｂについて、値「古いソースポート」を有するソースポートは、「新しいソースポート」値に置き換えられるべきである。Ｐ－ＧＷ５２は、５－ｔｕｐｌｅの４つの最初のパラメータとマッチするアップリンクトラフィック２ｃを検査する。具体的には：プロトコルＵＤＰ、ソースＩＰアドレスｕｅＩＰ、ソースポートｕｅＰｏｒｔおよび宛先ＩＰアドレスｓｒｖＩＰ（ＩＰアドレスおよびポートは、ダウンリンクからミラーリングされる）。

【0083】

アップリンクのデータパケット１０５が、このフィルタとマッチするとき、宛先ポートをチェックする。宛先ポートが「古いソースポート」とマッチする場合、データパケット２ｄが転送され、このデータパケット２ｄは修正されたダウンリンクデータパケット２ｃのための肯定応答ではないと想定される。「新しいソースポート」とマッチする宛先ポートを有する前のフィルタとマッチする第１のデータパケット１０５について、新しいタイムスタンプが、修正されたダウンリンクデータパケット２ｃの第１の肯定応答をシグナリングするＰ－ＧＷ５２に記憶される。

【0084】

ＲＴＴｓが、記録された２つのタイムスタンプの差として、計算される６２。このデータパケット１０５以降－およびこのＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のアップリンクで受信されたすべてのデータパケット２ｃについて－値「新しいソースポート」を含む宛先ポートは、最初の値「古いソースポート」に置き換えられるべきである。すべての後続のデータパケット２ｃについてアップリンク上で変更がなされていないとき、この機構は、ＲＴＴｓ測定ごとに、ダウンリンク上の１つだけのポート変更（クライアントによって検出される）を導入し、アップリンクでは変更はない（サーバによって検出可能な変更なし）。

【0085】

ＲＴＴｓ測定６２が完了した後は、別のＲＴＴｓ測定が、ソースポートの付加的インクリメント（またはデクリメント）を導入することによって、同じフローで実行され得る。そのような変更は、サーバ５３ポートのみに影響を及ぼし得、ＩＰアドレスには影響しないことが可能なので、導入されたソースポート変更は、サーバ５３のアクセスネットワーク５変更またはサーバ５３に影響を及ぼすＣＧＮＡＴ変更をシミュレーションする－より典型的。どのような場合にも、これらの変更は、クライアント／ＵＥ５１（ＲＴＴｓを測定する）の場合よりもサーバ５３（ＲＴＴｃを測定する）の場合に稀である。サーバ５３が、モバイルアクセスネットワーク１内に位置する場合、次いで、クライアント／ＵＥ５１およびサーバ５３の役割は、逆にすることができ、ＲＴＴｓおよびＲＴＴｃの計算は、対称になる。

【0086】

ＩＰ修正例

【0087】

同技法は、ＩＰアドレス上のおよびポート上ではないマーキングを使用して、実装することができる。本技法はさらに、図５および６を使用して詳しく述べられる。この例１５０は、Ｐ－ＧＷ５２で必要とされる機能性またはＰＣＥＦ機能での実装形態が、図１による、通信システム１内にあるようなモバイルアクセスネットワークのノード５であると想定する。

【0088】

この例では、以下のステップが、データパケット２のアドレス部分３を使用するＲＴＴｓの計算のために従われるべきであり、具体的には、この例では、ＩＰ値はアドレス部分３であり、第１のデバイス４はＵＥ５１であり、第２のデバイス６はサーバ５３である。

【0089】

Ｐ－ＧＷ５２での実装形態は、以下の５－ｔｕｐｌｅ情報でＱＵＩＣフロー１５５を識別する：トランスポートプロトコルとしてのＵＤＰと、クライアントＩＰアドレスおよびポートがｕｅＩＰおよびｕｅＰｏｒｔであることと、サーバＩＰアドレスおよびポートがｓｒｖＩＰおよびｓｒｖＰｏｒｔであること。新しいパッシブＲＴＴｓ測定が必要とされるとき、Ｐ－ＧＷ５２は、選択されたＱＵＩＣフローのアップリンクで新しいデータパケット２ａを待つことになる。パケット２ａが受信される１５２とき、ソースＩＰアドレスは、１だけインクリメントされる１５８。別法として、ソースＩＰアドレスは、任意の他の値だけインクリメントまたはデクリメントされ得る。

【0090】

Ｐ－ＧＷ５２は、ＵＥからの「古いソースＩＰアドレス」、「新しいソースＩＰアドレス」およびＵＤＰ ５－ｔｕｐｌｅの残りの値を記憶することによって、この修正をテーブルに記憶することになる。データパケット２ｂは、新しいソースＩＰアドレスを有するサーバ５３に送られる１５９。Ｐ－ＧＷ５２は、このイベント－アップリンクパケットの修正および転送－のタイムスタンプを記憶する。

【0091】

このＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のアップリンク上のすべての後続のデータパケット２ｂについて、値「古いソースＩＰアドレス」を有するソースＩＰアドレスは、「新しいソースＩＰアドレス」値に置き換えられるべきである。Ｐ－ＧＷ５２は、５－ｔｕｐｌｅの４つの最初のパラメータとマッチするダウンリンクトラフィックを検査する。具体的には：プロトコルＵＤＰ、ソースＩＰアドレスｓｒｖＩＰ、ソースポートｓｒｖＰｏｒｔおよび宛先ポートｕｅＰｏｒｔ（ＩＰアドレスおよびポートは、アップリンクからミラーリングされる）。

【0092】

ダウンリンクのデータパケット２ｃが、このフィルタ１６１とマッチするとき、宛先ＩＰアドレスをチェックする。宛先ＩＰアドレスが、「古いソースＩＰアドレス」とマッチする場合、データパケット２ｄが転送され、このデータパケット２ｄは修正されたアップリンクデータパケット２ｃのための肯定応答ではないと想定される。「新しいソースＩＰアドレス」とマッチする宛先ＩＰアドレスを有する前のフィルタ１６１とマッチする第１のデータパケット２ｃについて、新しいタイムスタンプが、修正されたアップリンクデータパケット２ｃの第１の肯定応答をシグナリングするＰ－ＧＷ５２に記憶される。

【0093】

ＲＴＴｓは、記録された２つのタイムスタンプの差として計算される１６２。このデータパケット２ｃ以降－およびこのＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のダウンリンクで受信されるすべてのデータパケット２ｃについて－値「新しいソースＩＰアドレス」を含む宛先ＩＰアドレスは、最初の値「古いソースＩＰアドレス」に置き換えられるべきである。変更が、すべての後続のデータパケット２ｃのダウンリンクでなされていないとき、この機構は、ＲＴＴｓ測定ごとに、アップリンクで１つだけのＩＰアドレス変更（サーバによって検出される）を導入し、ダウンリンクでの変更はない（クライアントによって検出可能な変更なし）。

【0094】

ＲＴＴｓ測定１６２が完了した後は、別のＲＴＴｓ測定が、ソースＩＰアドレスの付加的インクリメント（またはデクリメント）を導入することによって、同フローで実行され得る。導入されたソースＩＰアドレス変更は、クライアント／ＵＥ４のアクセスネットワーク５変更またはクライアント／ＵＥ４に影響を及ぼすＣＧＮＡＴ変更をシミュレーションする。

【0095】

類似のステップが、ＩＰマーキングを使用するＲＴＴｃの計算のために従われるべきである。この例は、Ｐ－ＧＷ５２またはＰＣＥＦで必要とされる機能性に関する実装形態を通信システム１としてのモバイルアクセスネットワークのノード５であると想定する。

【0096】

図６のこの例２００では、以下のステップが、データパケット２のアドレス部分３を使用するＲＴＴｓの計算のために従われるべきであり、具体的には、この例では、ＩＰ値はアドレス部分３であり、第１のデバイス６はＵＥ５１であり、第２のデバイス４はサーバ５３である。

【0097】

Ｐ－ＧＷ５２での実装形態は、以下の５－ｔｕｐｌｅ情報でＱＵＩＣフロー２０２を識別する：トランスポートプロトコルとしてのＵＤＰと、クライアントＩＰアドレスおよびポートが、それぞれ、ｕｅＩＰおよびｕｅＰｏｒｔであることと、サーバＩＰアドレスおよびポートが、それぞれ、ｓｒｖＩＰおよびｓｒｖＰｏｒｔであること。

【0098】

新しいパッシブＲＴＴｃ測定が必要とされるとき、Ｐ－ＧＷ５２は、選択されたＱＵＩＣフローのダウンリンクで新しいデータパケット２ａを待つことになる。データパケット２ａが受信される２０４とき、ソースＩＰアドレスは、１だけインクリメントされる２０５。別法として、ソースＩＰアドレスは、任意の他の値だけインクリメントまたはデクリメントされ得る。Ｐ－ＧＷ５２は、サーバからの「古いソースＩＰアドレス」、「新しいソースＩＰアドレス」およびＵＤＰ ５－ｔｕｐｌｅの残りの値を記憶することによって、テーブルにこの修正を記憶することになる。

【0099】

データパケット２ｂが、新しいソースＩＰアドレスを有するＵＥ５１に送られる２０６。Ｐ－ＧＷ５２は、このイベント－ダウンリンクパケットの修正および転送－のタイムスタンプを記憶する。このＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のダウンリンク上のすべての後続のデータパケット２ｂについて、値「古いソースＩＰアドレス」を有するソースＩＰアドレスは、「新しいソースＩＰアドレス」値に置き換えられるべきである。

【0100】

Ｐ－ＧＷ５２は、５－ｔｕｐｌｅの４つの最初のパラメータとマッチするアップリンクトラフィックを検査する。具体的には：プロトコルＵＤＰ、ソースＩＰアドレスｕｅＩＰ、ソースポートｕｅＰｏｒｔおよび宛先ＩＰポートｓｒｖＰｏｒｔ、ＩＰアドレスおよびポートは、ダウンリンクからミラーリングされる。アップリンクのデータパケット２ｃ以降がこのフィルタとマッチするとき、宛先ＩＰアドレスをチェックする。宛先ＩＰアドレスが、「古いソースＩＰアドレス」とマッチする場合、データパケット２ｄが転送され、このデータパケット２ｄは修正されたダウンリンクデータパケット２ｃのための肯定応答ではないと想定される。

【0101】

「新しいソースＩＰアドレス」とマッチする宛先ＩＰアドレスを有する前のフィルタとマッチする２０８第１のデータパケット２ｃについて、新しいタイムスタンプが、修正されたダウンリンクデータパケット２ｃの第１の肯定応答をシグナリングするＰ－ＧＷ５２に記憶される。ＲＴＴｓは、記録された２つのタイムスタンプの差として計算される２０９。

【0102】

このデータパケット２ｃ以降－およびこのＱＵＩＣフロー（ＵＤＰ ５－ｔｕｐｌｅ）のアップリンクで受信されたすべてのデータパケット２ｃについて－値「新しいソースＩＰアドレス」を含む宛先ＩＰアドレスは、最初の値「古いソースＩＰアドレス」に置き換えられるべきである。すべての後続のデータパケット２ｃについてアップリンクで変更がなされていないとき、この機構は、ＲＴＴｓ測定ごとに、ダウンリンクで１つだけのＩＰアドレス変更（クライアントによって検出される）を導入し、アップリンクでは変更はない（サーバによって検出可能な変更なし）。

【0103】

ＲＴＴｓ測定が完了した後は、別のＲＴＴｓ測定が、ソースＩＰアドレスの付加的インクリメント（またはデクリメント）を導入することによって、同フローで実行され得る。導入されたソースＩＰアドレス変更は、サーバ４のアクセスネットワーク５変更またはサーバに影響を及ぼすＣＧＮＡＴ変更をシミュレーションする。どのような場合にも、これらの変更は、クライアント／ＵＥ（ＲＴＴｓを測定する）よりもサーバ（ＲＴＴｃを測定する）の場合に稀である。サーバが、モバイルアクセスネットワーク内に位置する場合、次いで、クライアント／ＵＥおよびサーバの役割は、逆にすることができ、ＲＴＴｓおよびＲＴＴｃの計算は、対称になる。

【0104】

前述の例は、ＩＰアドレスまたはポートのいずれかを変更する。しかしながら、付加的な他の実装形態は、容易に、ＩＰアドレスまたはポートの両方を変更し得る。これらのシナリオは、前述の例の自然進化であり、当業者には容易に理解される。したがって、そのようなシナリオの明示的記述は、避けられている。

【0105】

記載された使用事例は、ＱＵＩＣのＲＴＴｓおよびＲＴＴｃを計算する。示されたように、ＱＵＩＣの要件は、ネットワークアクセス変更をサポートすること以外には存在しない。アクセスネットワーク変更に対する回復力のための類似の技法を実装するＵＤＰで実行する任意の他のプロトコルもまた、ＲＴＴの測定のためにサポートされ得る－たとえば、Ｐ２Ｐプロトコルのように。

【0106】

機能手段またはモジュールは、デジタルロジックおよび／または１つまたは複数のマイクロコントローラ、マイクロプロセッサ、または他のデジタルハードウェアを使用して実装され得ることが、通信設計に精通している者には容易に理解されよう。いくつかの実施形態において、様々な機能のうちのいくつかまたはすべては、たとえば、単一の特定用途向け集積回路（ＡＳＩＣ）において、あるいはそれらの間に適切なハードウェアおよび／またはソフトウェアインターフェースを有する２つ以上の別個のデバイスにおいて、一緒に実装され得る。それらの機能のうちのいくつかは、たとえば、無線端末またはネットワークノードの他の機能的構成要素と共用されるプロセッサで実装され得る。

【0107】

別法として、論じられた処理手段の機能的要素のうちのいくつかは、専用ハードウェアの使用を介して提供され得るが、他は、適切なソフトウェアまたはファームウェアと関連して、ソフトウェアを実行するためのハードウェアで提供される。したがって、本明細書では「プロセッサ」または「コントローラ」という用語は、ソフトウェアを実行する能力を有するハードウェアだけを指すのではなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ソフトウェアを記憶するための読取り専用メモリ（ＲＯＭ）、ソフトウェアおよび／またはプログラムまたはアプリケーションデータを記憶するためのランダムアクセスメモリ、および不揮発性メモリを黙示的に含み得、これらに限定されない。他のハードウェア、従来型および／またはカスタム、もまた、含まれ得る。

【0108】

開示された実施形態の修正形態および他の実施形態が、前述の説明および関連図面で提示された教示の利益を有して、当業者には思い浮かぶことになろう。したがって、実施形態は開示された特定の実施形態に制限されないことと、修正形態および他の実施形態が本開示の範囲に含まれることが意図されていることとを理解されたい。特定の用語が本明細書では使用され得るが、それらは、包括的な、説明的意味でのみ使用されており、制限を目的としていない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】