JP2012529808A - パケット交換網における遅延の監視 - Google Patents

Abstract

通信ネットワークを介した第１のネットワークノードと第２のネットワークノードとの間の音声または映像データなどのマルチメディアデータの送信であって、データが、エンコードされたデータからなる少なくとも１つのフレームを含むデータユニットにカプセル化される送信について、往復遅延を割り出すための方法が提案される。この方法は、前記第１のネットワークノードが、データユニットの構造の設定変更の要求を第２のノードへ送信するステップと、第１のノードが、設定変更の要求に対応する構造を有するデータの少なくとも１つのデータユニットを含む第２のノードからの設定変更の応答を検出するステップとを含む。第１のノードは、次いで、設定変更の要求の送信と設定変更の応答の検出との間の経過時間を測定し、前記測定された時間を使用して往復遅延の値を割り出す。第１の実施形態によれば、設定変更の要求は、マルチメディアデータのエンコーディングモードの変更の要求である。この往復遅延を測定するように構成されたノードも提案される。

Description

本発明は、パケット交換網における音声または映像トラフィックなどのマルチメディアトラフィックの伝送遅延の監視に関する。本発明は、インターネットプロトコル上での音声通信の用途に特に関する。

電話、インターネットＴＶ、および映像サービスなどのマルチメディアトラフィックの伝送にパケット交換網を使用することが、ますます広まってきている。しかしながら、これらのサービスが遅延の影響をきわめて受けやすいことが、よく知られている。音声電話の場合において、過度の往復遅延（ｒｏｕｎｄ−ｔｒｉｐ ｄｅｌａｙ）は、ユーザを当惑させ、通話品質の低下につながる。本明細書において、往復遅延は、データ、スピーチ、または他のマルチメディアトラフィックが第１のユーザから伝送媒体を介して第２のユーザへと送信され、応答が第２のユーザから第１のユーザへと送り返される総時間を指すものとする。ユーザが遅延をどの程度煩わしいものとして感じるかは、使用される用語、当事者の気分、および会話の種類など、いくつかの異なる因子によって決まる。一般的な基準を発見しようとする試みにおいて、国際電気通信連合（ＩＴＵ）が、ＩＴＵ−Ｔ Ｇ．１１４において１５０ｍｓという一方向（マウス・トゥ・イヤ（ｍｏｕｔｈ−ｔｏ−ｅａｒ））の遅延のしきい値（これを超えると、遅延が品質に影響を及ぼすと考えられる）を提案している。

パケット交換網およびサービス（特には、ＩＰネットワーク）において、遅延は、種々の時点および場所において大小の遅延の変化を引き起こす多数の因子に左右されるであろう。それらの因子のなかでも、ネットワークトポロジおよび使用される構成要素が、或る端末相互間ＩＰ音声通話と別の端末相互間ＩＰ音声通話とで大きく異なる可能性があり、通常は端末が該当のネットワークについての知識を有していない。ネットワーク負荷も、遅延および遅延ジッタに影響を及ぼす大きな因子である。ネットワークの負荷が大きいと、ルータにおける待ちが長くなり、遅延の増加につながる。また、無線リンクを介して伝送されるＩＰネットワークは、無線の状態に影響されやすく、状態が良好でない場合、伝送時間に影響が及び、結果として全体としての遅延が長くなる。さらなる因子は、パケット化に要する時間である。より長いスピーチフレームが使用され、あるいはパケット当たりに含まれるスピーチフレームの数が多くされると、遅延も大きくなるようになる。

パケット交換網における伝送遅延は、おそらくは種々の経路ごとに異なるが、それでもなお、特定のリンクについて遅延を知ることは、特にＶｏＩＰサービスにおいて有利である。この有利さは、クライアントノードの振舞いを予想される遅延に合わせることができる点にある。例えば、受信ノードにおけるジッタバッファの機能を、遅延が長くなると予想される場合に、さらなる遅延を最少にするために、より多くの遅れ損失を容認するように変更することができる。遅れ損失は、一定の遅延よりも後に到着した場合に受信側において破棄されるパケットに与えられた用語である。反対に、ネットワークの遅延が短い場合には、ジッタバッファがより長い時間にわたってフレームをバッファすることで、遅れ損失を低減することができる。

特にはパケット交換マルチメディアトラフィックをサポートする無線アクセスネットワークにおいて、ネットワークにおける遅延を監視することの難しさは、トラフィックが、典型的には、優先度に従って待ち行列に分類されるようになり、各待ち行列が、複数のユーザによって共有され、場合によっては異なる種類のトラフィック（すなわち、同じユーザのための音声、データ、映像）によって共有される点にある。そのようなネットワークは、理論上、自身が運んでいるサービスを意識していない。結果として、個々のストリームの性能の監視は、ネットワークレベルにおいてはきわめて問題となる。

回路交換システムにおいては、遅延がシステムの設計パラメータである。さらに、遅延が、音声通話に合わせて設定されているため、ネットワークにおいて変化することがない。グローバル・システム・フォー・モバイル・コミュニケーション（ＧＳＭ）においては、マウス・トゥ・イヤ遅延が、約２００ｍｓになるように設計されている。広帯域符号分割多重アクセス（ＷＣＤＭＡ）においては、マウス・トゥ・イヤ遅延が、約２２５ｍｓになるように設計されている。しかしながら、２つの終端ノードの間の特定のリンクに含まれるネットワークの数に応じて、実際の遅延がこれらの標準からきわめて異なる場合が、依然として存在する。そのような場合、実際の遅延を知ることが有用となりうる。

本発明の目的は、パケット交換または回路交換ネットワークにおけるマルチメディア・トラフィック・ストリームの往復遅延の少なくとも推定値を確かめるための方法および機構を提供することである。

この目的およびさらなる目的が、本発明に従って、通信ネットワークを介した第１のネットワークノードと第２のネットワークノードとの間の音声データまたは映像データなどのマルチメディアデータの送信についての往復遅延を割り出すための方法において達成され、データが、エンコードされたデータからなる少なくとも１つのフレームを含むデータユニットにカプセル化される。このエンコードされたデータは、スピーチまたは映像データなど、符号化されたマルチメディアで構成されても、例えば送信すべきマルチメディアデータが入手できない場合の無音など、マルチメディアデータの不在を表わすデータであってもよい。この方法においては、第１のネットワークノードが、データユニットの構造の設定変更の要求を第２のノードへ送信し、第２のノードから設定変更の応答を受信する。設定変更の応答は、前記設定変更の要求に対応する構造を有する少なくとも１つのデータユニットを含む。次いで、第１のノードが、設定変更の要求の送信と設定変更の応答の受信との間の経過時間を測定し、この測定された時間を使用して往復遅延の値を割り出す。

本発明のさらなる態様によれば、上述の目的が、通信ネットワークを介して少なくとも１つの第２のノードとマルチメディアトラフィックの送受信を行う通信システムのノードにおいて達成される。ノードは、前記ネットワークを介した前記少なくとも１つの第２のノードへの送信に先立って、データをデータユニットへとエンコードするとともに、前記通信ネットワークを介して前記第２のノードから受信されるデータユニットに含まれるエンコード済みのデータをデコードするように構成されている。データユニットは、エンコード済みのデータからなる少なくとも１つのフレームを含む。このノードが、データユニットの生成および受信を制御するように構成されたコントローラを備える。コントローラは、データユニットの構造の設定変更の要求を第２のノードへ送信し、設定変更の要求に応答する第２のノードからの設定変更の応答を検出するようにさらに構成されており、この設定変更の応答は、設定変更の要求に対応する構造を有する少なくとも１つのデータユニットを含む。またさらに、コントローラは、設定変更の要求の送信と設定変更の応答の受信との間の経過時間を測定し、この測定された時間を使用して、前記第２のノードへのデータの送信および前記第２のノードからのデータの送信についての往復遅延の値を割り出すように構成される。

この方法および機構によれば、パケット交換網または回路交換ネットワークの個々のノードが、特定のリンクにおける遅延の測定を、妥当に正確な値まで、全体としてのネットワークをほとんどまたはまったく乱すことなく実施することができる。さらに、設定変更の応答が、異なる構造を呈するように設定変更されたマルチメディアデータの通常のデータユニットであるため、好ましくは従来からのやり方でこの特定のリンクの終端ノードをほとんどまたはまったく変更する必要がない。設定変更後の少なくとも１つのデータユニットの異なる構造は、例えば、異なる全体サイズまたは全長、データユニットの特定の構成要素のみの異なるサイズまたは長さ、あるいはデータユニットの特定の（１つまたは複数の）フィールドにおける異なる情報の存在であってもよい。あるいは、異なる構造が、例えばエンコードされたデータのフレームの冗長性または再送信に関係する場合に、２つ以上の受信データユニットに関係してもよい。この方法および構成によって得られる遅延情報は、ノードが、知覚される品質を向上させ、ネットワークリソースの使用を最適化し、電池の持ちをよくするためにリソースの使用において最大の効率を達成するようなやり方で、自身の動作を変更することを可能にする。設定変更の要求を、トラフィック・データ・ユニットとは別に、すなわちトラフィックデータとは別の論理チャネルにて送信してもよいが、本発明によれば、要求をインバンドで、すなわちトラフィックデータと同じ論理チャネルにて送信することが好ましく、要求が通常のデータユニットまたはフレームの一部を形成することが好ましい。

本発明の第１の実施形態によれば、設定変更の要求が、（１つまたは複数の）フレームのデータをエンコードするために使用されるエンコーディングモードを変更するための要求である。したがって、設定変更の応答は、第２のノードから受信されるデータユニットが、エンコーディングモードの変更の要求にて指示されたエンコーディングモードに従ってエンコードされたデータの少なくとも１つのフレームを含む場合に検出される。この実施形態は、第２のノードの通常の動作にいかなる変更も必要でなく、単にこのノードがエンコーディングモードの変更要求（適応マルチレート（ＡＭＲ）コーデックにおいて使用されるコーディングモード要求（ＣＭＲ）など）に通常のやり方で応答するだけでよいため、特に実現が簡単である。この実施形態は、データユニットがエンコードされたマルチメディアデータのフレームである回路交換ネットワーク、および各データユニットがエンコードされたデータの少なくとも１つのフレームをカプセル化してなるパケットであるパケット交換網の両方に適用可能である。

本発明の第２の実施形態によれば、各データユニットが、エンコードされたデータの少なくとも１つのフレームをカプセル化してなるパケットである。この実施形態によれば、データユニットの構造の設定変更の要求が、パケットに含まれるエンコードされたデータのフレームの数を変更する要求であり、すなわちフレームの集合を変更する要求である。このやり方でフレームの集合を変更することで、特定のリンクにおいてトラフィックデータのコーディングモードが何らかの理由で制限され、あるいは単に望ましくない状況において、遅延の推定を行うことができる。さらに、この要求をエンコーディングモードの変更要求と組み合わせることによって、要求への応答に或る種の柔軟性がもたらされる。すなわち、要求元のモードが、どちらかの要求に応答して変更されたデータユニットに基づいて遅延を割り出すことができる。

各データユニットがやはりエンコードされたデータの少なくとも１つのフレームをカプセル化してなるパケットである本発明の第３の実施形態によれば、上記データユニットの構造の設定変更の要求が、エンコードされたデータの少なくとも１つのフレームが異なるパケットで送信される回数を変更する要求である、すなわちフレームの冗長性のレベルを変更する要求である。遅延の測定を開始するために冗長性の変更の要求を可能にすることで、さらなる柔軟性がもたらされる。この点に関して、少なくとも１つのエンコードされたフレームの再送信の回数は、パケットに含まれるエンコードされたデータのすべてのフレームが少なくとも１回は再送信される場合、すなわち１００％以上の冗長性の場合、および例えば５０％の冗長性など、一部のフレームだけが再送信される場合の両方に当てはまる。

上述の３つの実施形態を、単独または任意の組み合わせにて使用することができる。例えば、設定変更の要求が、冗長性の変更と、コーディングモードの変更およびフレームの集合の変更の一方または両方との両方に関するものであってもよい。他の組み合わせも同様に可能である。したがって、設定変更の応答を、パケットユニットが要求された変更のうちの少なくとも１つに従って設定変更された場合に検出することができる。

本発明のさらなる実施形態は、特許請求の範囲に記載される。

本発明のさらなる目的および利点が、添付の図面に関連してあくまでも例として提示される好ましい実施形態についての以下の説明から明らかになるであろう。

パケット交換網を介してエンコードされたスピーチを送信することができる２つのノードを概略的に示す。 ＲＴＰパケットのＡＭＲペイロードの構造を概略的に示す。 本発明の第１の実施形態に従って往復遅延を割り出すためのノード間のシグナリングを示す。 本発明の第２の実施形態に従って往復遅延を割り出すためのノード間のシグナリングを示す。 本発明の第３および第４の実施形態に従って、エンコードされたスピーチおよび伝送遅延を割り出すためのインバンドでのシグナリングを運ぶＲＴＰパケットの構造を示す。 本発明の第３の実施形態に従って往復遅延を割り出すためのノード間のシグナリングを示す。

以下の説明においては、本発明を、インターネットプロトコル上での音声通信（ＶｏＩＰ）データを運ぶパケット交換網における端末相互間のリンクに関して説明する。しかしながら、本発明の原理が、オーディオサービスおよび映像サービスなどの他のマルチメディアトラフィックを運ぶパケット交換網リンクにも容易に適用可能であることを理解すべきである。さらに、本発明を、回路交換ネットワークを介して接続された２つのノードの間のエンコードされたスピーチデータの伝送または音響遅延を測定するためにも使用することができる。後者の場合には、スピーチデータを、エンコードされたスピーチフレームで構成されるデータのユニットまたはデータユニットにて搬送することができ、あるいはＡＴＭフレームなどのパケット構造で搬送することができる。パケット交換網においてエンコードされたスピーチを運ぶデータユニットは、エンコードされたスピーチデータの１つまたは複数のフレームを含むパケット（通常は、ＲＴＰパケット）で構成される。

図１が、本発明の第１の実施形態に従って動作する、パケット交換網における２つの終端ノードを示している。ノードは、パケット交換網を介して音声またはマルチメディアトラフィックを送信および受信することができる任意のノードを代表する。例えば、第１のノード１０が、無線電話機などの移動局であってもよい一方で、第２のノード２０は、さらなる端末またはマルチメディアゲートウェイであってもよい。第１のノード１０および第２のノード２０が、パケット交換網３０へと接続され、このパケット交換網を介して互いに通信する。パケット交換網３０は、好ましくはＩＰネットワークであり、例えば企業の環境あるいは空港または駅などの公共区域における有線ローカル・エリア・ネットワークまたは無線のローカル・エリア・ネットワーク（ＷＬＡＮ）であってもよい。この例では、分かりやすくするために、ＩＰネットワーク３０が、第１のノード１０および第２のノード２０の間に配置されたただ１つのネットワークとして示されている。しかしながら、ネットワーク３０が、いずれも２つのノード１０および２０によって知られない種々のアクセス方法を使用する多数の種々の物理ネットワークで構成されてもよいことを理解することができるであろう。さらには、第１のノード１０および第２のノード２０の間で交換されるトラフィックの経路を、ネットワーク３０の一部を形成する多数の他のノードの間の複数のリンクで構成することができる。

図示の実施例によれば、スピーチが、インターネットプロトコル（ＩＰ）におけるユーザ・データグラム・プロトコル（ＵＤＰ）におけるリアルタイム・トランスポート・プロトコル（ＲＴＰ）を使用して、ネットワーク３０を介して伝送される。実際、スピーチデータが、ＲＴＰパケットのペイロードを形成する。さらに、スピーチデータは、送信端のエンコーダ１４０によってエンコードされ、受信端のデコーダ２２０によってデコードされる。そのようなエンコーダ／デコーダを、コーデックと称する。

使用されるコーデックは、好ましくは複数の動作モードを有している。そのようなコーデックの例として、４．７５から１２．２ｋｂｐｓまでのビットレートを有する８つの異なるモードのいずれかで動作できるマルチモードコーデックであるＧＭＳの仕様書０６．９０に定められる適応マルチレート（ＡＭＲ）スピーチコーデックを含む。さらなるマルチモードコーデックは、ＡＭＲに類似しており、６．６から２３．８５ｋｂｐｓまでの範囲のビットレートを有する９つの広帯域スピーチ・コーディング・モードをサポートする適応マルチレート広帯域（ＡＭＲ−ＷＢ）スピーチコーデックである。これらは、元々は回路交換移動無線システムのために設計されているが、パケット交換網を介した他のリアルタイムスピーチ通信サービスにも適している。ＩＰネットワークにおけるＡＭＲおよびＡＭＲ−ＷＢの使用を可能にするＡＭＲおよびＡＭＲ−ＷＢコーデックのためのリアルタイム・トランスポート（ＲＴＰ）ペイロードのフォーマットが、ＩＥＴＦ ＲＦＣ ４８６７に指定されている。マルチモード・スピーチ・コーデックのさらなる例は、ＩＴＵ−Ｔ勧告Ｇ．７２９．１に記載のＧ．７２９．１オーディオコーデックである。Ｇ．７２９コーデックのためのリアルタイム・トランスポート（ＲＴＰ）ペイロードのフォーマットは、ＩＥＴＦ ＲＦＣ ４７４９に記載されている。

図１に示されているように、ノード１０および２０は、さらに詳しく後述されるいくつかの構成要素を備える。ノード１０および２０は、当然ながら、図示はされていないが当業者にとってよく知られているさらなる構成要素も備える。しかしながら、それらのさらなる構成要素は、本発明に特段の関係がないため、ここでは説明を省略する。

図１に示されるとおり、それぞれのノード１０および２０は、到着するＲＴＰパケットにおけるパケット遅延の変化を最少にするために、ジッタバッファ１１０および２１０を備える。好ましくは、ジッタバッファ１１０および２１０が適応的である、すなわち換言すると、変化するネットワークのジッタ特性に応じてバッファ遅延を変更することが可能である。ジッタバッファ１１０および２１０は、受信したままのＲＴＰパケット全体を保存することができる。しかしながら、好ましくは、コントローラ１３０および２３０のバッファアルゴリズムによって、ＲＴＰパケットが最初にアンパック（ｕｎｐａｃｋ）され、ＲＴＰペイロードに含まれるエンコード済みのスピーチデータのフレームだけが、現時点においてバッファに存在する他のフレームに対して正しい順序でジッタバッファ１１０および２１０に保存される。到着が遅すぎたフレームは、破棄される。パケットのまたはフレームの順序を、パケットの続き番号や、パケットまたはフレームの時刻スタンプを使用して判断することができる。フレームが、ジッタバッファ１１０および２１０によってスピーチデコーダ１２０および２２０へと放出され、スピーチデコーダ１２０および２２０が、デコード済みのスピーチを出力する。さらに、コントローラ１３０および２３０が、ＲＴＰパケットに含まれる制御情報を読み出す、すなわちパケット交換網３０を介して受信されるインバンド制御情報を読み出す。

本発明によれば、一方のノード（本実施例では、第１のノード１０）が、リンクを介して他のノードへの往復遅延を割り出すことができる。本実施例では、これが、第１のノード１０から第２のノード２０へのデータの送信と、第１のノード１０におけるこの第２のノード２０からの応答の受信との間の遅延である。これが、第１のノード１０が第２のノード２０へとスピーチデータを運ぶデータユニットの設定変更の要求を送信することによって達成される。この要求を受信するとすぐに、第２のノード２０は、要求に対応するように第１のノード１０へと送信されるデータユニットの設定を変更することによって、応答すべきである。第１のノード１０は、ひとたび設定変更されたデータユニットを検出すると、要求の送信と変更されたデータユニットの検出との間の経過時間を割り出すことができる。次いで、この値を、２つのノード間の伝送遅延または音響遅延を判断または推定するために使用することができる。伝送遅延は、第１のノードによるデータユニットの送信と、第２のノードによるこのデータユニットの受信との間の時間である、すなわちスピーチフレームがジッタバッファ２１０に入力されるまでの時間である。音響遅延は、スピーチの受信の遅延であり、したがってジッタバッファ遅延およびエンコード済みのデータをデコードするために要する時間を含む。

好ましくは、設定変更の要求が、２つのノードの間のリンクの通常の動作の際に変更されるパラメータに関する。そのようにすることで、第２のノード２０の動作を変更する必要がない。要求を、スピーチデータを運ぶデータユニットとは別の制御データとして送信することができる。しかしながら、好ましくは、要求が、スピーチデータを運ぶデータユニットに埋め込まれた制御データとしてインバンドで送信される。

本発明の第１の実施形態によれば、設定変更の要求が、スピーチデータのエンコードに使用されるコーデックのエンコーディングおよびデコーディングのモード（すなわち、コーデックモード）を変更する要求である。

上述した形式のマルチモードコーデックにおいて、コーデックモードの変更を、モード要求を送信することによって要求することができる。この要求を、エンコードされたスピーチデータを含むＲＴＰペイロードの一部としてインバンドで送信することができる。例えば、ＡＭＲコーデックにおいては、モード要求が、コーデックモード要求またはＣＭＲと呼ばれ、ＲＴＰパケットペイロードを構成するヘッダの一部として提供される。ＡＭＲオーディオコーデックのためのＲＴＰペイロード（以下では、ＡＭＲペイロードと称する）の構造が、図２に概略的に示されている。この構造は、基本的に３つの部分に分けられる。ＡＭＲペイロードのヘッダを形成している第１の部分は、４ビットのコーデックモード要求（ＣＭＲ）フィールドである。第２の部分は、いわゆる目次（ＴｏＣ）であって、やはりヘッダの一部と考えることができるが、ＡＭＲペイロード（すなわち、単一のＲＴＰパケット）に含まれる各スピーチフレームについてのエントリのリストである。図２に示されるＴｏＣは、１つのスピーチフレームについてのエントリだけを有している。これは、現在のフレームにさらなるフレームが後続するか否かを示す１ビットのフラグ（Ｆ）と、コンフォート・ノイズ・モードを含むスピーチフレームのエンコードに使用されたコーデックモードを示す４ビットのフレームタイプ（ＦＴ）フィールドと、１ビットのフレーム品質インジケータ（Ｑ）フラグとで構成される。最後に、ＡＭＲペイロードの第３の部分が、フレームにエンコードされたスピーチデータを含む。ＲＴＰペイロードに２つ以上のスピーチフレームが含まれる場合には、ＴｏＣが、各スピーチフレームについてのエントリのリストを続けて含み、その後ろにスピーチフレームが続く。

この原理を、Ｇ．７２９．１コーデックなどの他のコーデックおよび他のシステムにも適用できることを、理解することができるであろう。例えば、Ｗ−ＣＤＭＡにおいて、同様の要求は、Ｉｕ／Ｎｂレート制御メッセージであると考えられる。映像および他のマルチメディアにおいて、エンコードされたフォーマットを変更する要求は、他の形態をとるであろう。さらには、要求を、例えばＲＴＰ制御プロトコル（ＲＴＣＰ）メッセージを使用することによってアウトオブバンドで送信することも可能である。

要約すると、往復遅延を割り出すための機構は、以下のとおりである。第１のノード１０が、コーデックモードの変更の要求を送信する。第２のノード２０は、この要求を受信するとすぐに、続くパケットにおいてスピーチをエンコードするために使用されるコーデックモードを変更することによって要求に応答する。このようにして、第１のノード１０は、新しいコーデックモードを用いてエンコードされたスピーチデータを受信するとすぐに、コーデックモードの変更要求の送信と応答の受信との間の遅延を割り出すことができる。これが、ノード間の往復遅延の推定値である。図３が、このプロセスに関係するシグナリングおよび他の段階を概略的に示している。イベント１０００において、第１のノード１０が、第２のノード（２０）に宛てたＲＴＰパケットにおいてインバンドでコーデックモード要求（ＣＭＲ）を送信することによって、コーデックモードまたはレートの変更を要求する。この第１のノード１０のコントローラ１３０が、ＣＭＲを含むフレームの送信時刻ｔ_０を記録する。第２のノード２０において、ＣＭＲが１１００においてコントローラ２３０によって認識され、受信されたＣＭＲに従って次のスピーチフレームにおいて使用されるコーデックモードを変更するようにスピーチエンコーダ２４０を制御する。イベント１２００において、新たなモードに従ってエンコードされたスピーチデータを含むパケットが、第２のノード２０から第１のノード１０へと送信される。これが、図２に示されたＡＭＲヘッダに含まれるフレーム・タイプ・インジケータによって識別される。第１のノード１０は、新たなモードでエンコードされたスピーチを含むフレームを受信し、このモードの変更をフレーム・タイプ・フィールドにて検出するとすぐに、イベント１３００において、受信時刻ｔ_１およびＣＭＲの送信とこのフレームの受信との間の遅延（ｔ_１−ｔ_０）を割り出す。これが、結果として、往復遅延である。代案として、第１のノード１０が、ＣＭＲの送信時にタイマを開始させ、イベント１３００においてフレームが受信されたときに停止させてもよい。

当然ながら、遅延の測定は、往復遅延が比較的短い時間のうちに複数回測定され、遅延の変動として得られる最も小さい値がジッタに起因する可能性が高い場合、実際の遅延のより正確な反映となるであろう。

第１のノード１０は、データがスピーチエンコーダ１４０から出発するときに時間の測定を開始する。したがって、いかなるコーディング遅延もカウントされない。しかしながら、測定される時間は、第１のノード１０から第２のノードまで、および第２のノードから第１のノードまでの伝送遅延（ジッタを含む）、ならびに第２のノード２０のスピーチエンコーダ２４０によって生じる遅延と、おそらくは第２のノード２０のジッタバッファ２１０、第２のノードのスピーチデコーダ２２０、第１のノード１０のジッタバッファ１１０、および第１のノードのスピーチデコーダ１２０によって生じる遅延とを含む。エンコーダ１４０およびデコーダ２２０および１２０によって引き起こされる遅延は、固定された値として推定することができる。ジッタバッファ２１０および１１０によって引き起こされる遅延も、推定可能であるが、動的な値である。しかしながら、遅延の測定の精度は、第２のノード２０がＣＭＲをどのように取り扱うかに依存する。例えば、第２のノードが、スピーチデータのジッタバッファからの読み出しと同時にＣＭＲを抽出する場合、遅延の計算は、音響遅延（すなわち、スピーチに課せられ、ユーザによって知覚される遅延）のより正確な反映をもたらすであろう。好ましくは、第２のノードは、ＣＭＲに速やかに応答し、スピーチデータがジッタバッファにバッファされる前にＣＭＲを抽出すべきであり、そのようにすることで、固定の部分と動的な部分とを別々に推定することが可能になり、より正確な値がもたらされる。同様の考えが、要求がパケットまたはデータユニットの一部でなく、制御メッセージとしてアウトオブバンドで送信される場合にも当てはまる。

測定の精度に影響を及ぼすさらなる因子は、リンクのうちの１つが不連続送信（ＤＴＸ）を使用しているかどうかである。不連続送信は、音声入力が存在しないときに送信側がエンコードされたスピーチフレームの送信を停止するやり方である。スピーチコーダが、オーディオフレームが無音であるか、あるいは実際の音声を含むかを判断するための音声活動検出（ＶＡＤ）アルゴリズムを備える。無音期間において、コーダは、無音挿入記述子（ＳＩＤ）と呼ばれる小さなフレームを送信することによって、送信されるビットレートを大きく減らし、次いで送信を停止することができる。さらに、コーダは、ＳＩＤフレームの送信の頻度を、通常のスピーチフレームの送信よりも少なくすることができる。ＡＭＲにおいて、スピーチフレームが２０ｍｓごとに送信される一方で、ＳＩＤフレームは１６０ｍｓごとに送信される。受信側のデコーダが、ＳＩＤに含まれるパラメータに従ってコンフォートノイズ（ＣＮＧ）を生成する。これが、携帯デバイスの送信側の増幅器において電池の電力を節約するとともに部品の作業負荷を軽減するために使用されるが、干渉の低減および容量の増加にも使用される。リンクがＤＴＸを使用している場合、上述の遅延の測定が、リンクの遅延を表わさないであろう。これを克服するために、いくつかの可能性が存在する。第１の可能性は、単純に、スピーチフレームではなくてＳＩＤフレームが送信される場合に追加の遅延を補償することである。受信ノード１０が、受信したパケットがエンコードされたスピーチフレームではなくてＳＩＤフレームを含むことを見分け、送信ノード２０が使用した送信間隔を知る。これにより、第１のノード１０は、測定された値から遅延を割り出すときに、この追加の間隔を補償することができる。さらなる実施例では、出て行くストリームをスピーチモードに強制することができる一方で、コントローラ１３０が、到着するストリームがＤＴＸでない場合に限って測定を承認する。ＳＩＤフレームは、受信側のデコーダによって容易に見分けることができるため、ＤＴＸをコントローラ１３０によって容易に特定することができる。またさらなる技術的解決策においては、ＤＴＸが許可されるが、ＣＭＲが複数回送信され、コントローラ１３０が、測定される最小および最大の遅延を監視する。平均値、中央値、または何らかの百分位数（７５％または９０％など）など、遅延の他の数的指標も考えられる。次いで、他の測定値とは明らかに異なる遅延を破棄することができる。またさらなる方法によれば、出て行くストリームがＤＴＸであるときに測定が実行される。すなわち換言すると、第１のモードが、スピーチフレームと同じパケット構造を有する、すなわちパケットのペイロードにＣＭＲを含むこととなるＳＩＤフレームを送信する。受信ノード２０の速やかな応答を確実にするために、このノードのエンコーダ２４０を、少なくとも一時的にスピーチモードに強制することが可能である。これを、受信されたパケットにおいてＣＭＲが検出されるとエンコーダ２４０のＶＡＤフラグを「１」に強制する（したがって、スピーチ・エンコード・モードに強制する）デコーダ２２０またはコントローラ２３０によって行うことができる。これを、所定の時間または所定の数のパケットについて維持することができ、その後に強制が取り止められ、受信ノード２０がスピーチ・エンコード・データまたはＳＩＤに通常のやり方で応答する。あるいは、ＡＭＲの場合のように、ＳＩＤフレームがペイロード内に追加のフレーム・タイプ・フィールドを含むコーデックにおいては、第２のノードのエンコーダ２４０を、追加のＳＩＤフレームを送信するように強制することができる。このやり方で、不連続送信（ＤＴＸ）の最中でもコーデックモードの変更を指示することができる。

本発明の第２および第３の実施形態によれば、設定変更の要求が、スピーチデータを運ぶパケットの構造に関する。これは、２つの形態をとることができる。第１には、フレームの集合の変更、すなわち各ＲＴＰパケットにおいて送信される非冗長スピーチフレームの数の変更であり、第２には、ＲＴＰパケットにおける冗長性、すなわちフレームが別のＲＴＰパケットにて再送信される回数である。やはり、要求を、例えばＲＴＣＰを使用し、制御メッセージとしてアウトオブバンドで送信することができる。あるいは、要求を、スピーチフレームを含むパケットの一部としてインバンドで送信することができる。

図５に、パケット構造制御データを含むＲＴＰパケットの構造が示されている。ＲＴＰパケットが、従来からのヘッダ部と、エンコードされたスピーチデータを含むペイロード部（図示の実施例では、ＡＭＲペイロードと称されている）とで構成され、さらに本発明に従って、従来からのヘッダとペイロードとの間に挿入された、パケットの設定に関するデータを含むパケット設定フィールド（Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．）で構成される。ＲＴＰヘッダの構造は、当業者にとってよく知られており、プロトコルのバージョンを示している第１のフィールドＶと、ＲＴＰパケットの終わりに埋め草ビットが存在するか否かを示すために使用されるフィールドＰと、拡張ヘッダが存在するか否かを示すために使用されるフィールドＸと、固定ヘッダに続く寄与送信元識別子の数を含むフィールドＣＣと、アプリケーションレベルで使用されるフィールドＭと、ペイロードのフォーマットを示すＰＴフィールドと、続き番号と、時刻スタンプと、ストリームのソースを特定する同期ソース識別子ＳＳＣＲと、ストリームへの寄与送信元（存在する場合）を列挙する寄与送信元識別子フィールドＣＳＲＣとで構成される。Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．と示されている追加のフィールドが、２つの異なるパケット構造の要求および特定のためのデータを収容する。好ましくは、Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドの第１の部分が、このフィールドの識別を含む一方で、第２の部分が、具体的な設定を指示する。

本発明の第２の実施形態によれば、このフィールドが、特定のフレームの集合を指示または要求する、すなわちパケット当たりのスピーチフレームの数を指示または要求するデータを収容する。好ましくは、具体的な設定を示すために使用されるパケット設定フィールドの第２の部分が、値「００００」によるパケット当たり１フレームから、値「１１１１」によるパケット当たり１５フレームまでを指定する。あるいは、パケット設定フィールドが、フレームの集合の増加または減少の要求を単に表わす制御データを含むことができる。これは、例えばフレームの総数に制限が存在する場合に、第２のノード２０の応答におけるさらなる柔軟性を可能にする。

本発明の第３の実施形態によれば、Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドが、パケットの冗長性のレベルを示すデータを含み、おそらくはオフセット冗長性も示すデータを含む。これは、スピーチフレームが後続のパケットにおいて再送信される回数である。なし得る可能な１つの構成においては、具体的な設定を指示するパケット設定フィールドの第２の部分が、好ましくは一連のビットで構成され、それらビットが「１」に設定された場合、特定の「期間」のスピーチフレームをＲＴＰペイロードの一部として送信すべきであることを示している。例えば、最初のビットは、期間が２０ｍｓであるフレームを表わしている。ＡＭＲにおいてはスピーチフレームが２０ｍｓごとに送信されるため、この第１のビットは、直前のフレームを指している。このビットが設定された場合、それは、直前のフレームを再送信すべきであることを示している。以後のビットは、期間が４０ｍｓ、６０ｍｓ、８０ｍｓ、・・・のフレームを表わしている。したがって、「０、０、０、０、０、１、０、０、０、１、０、１」という値を有する１２ビットのフィールドは、２０ｍｓ、６０ｍｓ、および１４０ｍｓのフレームだけをＲＴＰペイロードに含めるべきであることを示している。この構造は、冗長性のレベルおよびオフセットの両方を１つのフィールドに示すことを可能にする。しかしながら、別のコーデックに適した他のフィールド構造を、当業者であれば容易に想像することができるであろう。例えば、第２のパケット設定フィールドを、冗長性のレベルおよびオフセットを別々に示すために２つの部分に分割することができる。最初の部分が、「００」という値による冗長性無しから、「１１」という値による３００％の冗長性のレベルまでを、１００％刻みで示す第１のインジケータを含むことができる。第２の部分は、オフセット冗長性についての第２のインジケータを含むことができ、例えば「００」が次のパケットでの冗長データを意味し、「０１」が冗長データが２パケット後であることを意味し、「１０」が冗長データが３パケット後であることを意味し、「１１」が冗長データが４パケット後であることを意味する。

第１のノード１０による設定変更の応答の検出は、第２および第３の実施形態において異なる。より具体的には、第２のノードがフレーム集合の変更の要求に応答した場合、この変更が、好ましくは、図５に示したとおりのＲＴＰヘッダの目次フィールドのエントリのリストの数を割り出すことによって第１のノードにおいて検出される。エンコードされた各スピーチフレームに目次のエントリが組み合わせられているため、これがフレーム集合を割り出す最も簡単な方法である。パケットの全長に基づいてフレームの数を割り出すことも可能であるが、これは、使用されるコーデックモードに応じて変化する可能性がある。

設定変更の要求が、第３の実施形態に従い、冗長性の変更に関する場合、第１のノード１０は、第１のパケットにおいて送信されたフレームがその後に何回再送信されたかを割り出すことによってのみ、この要求が満たされたことを確認することができる。これは、第１のノード１０のコントローラ１３０によって、受信フレームの時刻スタンプを割り出し、フレームが以前に送信されたものであるか否かを判断すべく時刻スタンプを比較することによって達成される。フレームの最初の送信の受信により、測定期間の終了が引き起こされるが、これは、このフレームの正しい冗長性のレベルが明らかにされている場合にのみ確認される。

第２および第３の両方の実施形態におけるさらなる可能性は、現在のフレームの集合または冗長性あるいは両方を示す情報を含むように使用することができるリンクを介して送信されるパケットのパケット設定フィールドの使用を課すことである。このやり方で、第１のノード１０は、この情報から、パケットまたは後続のパケットをさらに調べる必要なく、現在のパケット構造を特定することができる。

図４は、本発明の第２の実施形態に従ってパケット内のＰａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドを使用する遅延の測定に関係するシグナリングおよび他の段階を概略的に示している。ステップ２０００において、第１のノードが、Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドを含むＲＴＰパケットを送信し、Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドは、パケットのフレーム集合の変更の要求を示す情報を含む。同時に、第１のノードは、このパケットの送信時刻ｔ_０を記録する。第２のノードが、このパケットを受信するとすぐに、Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドに示されている要求を検出し、ステップ２１００においてフレーム集合を変更することによって要求された構造を実現し、この構造に合致するパケットを第１のノードへと送り返す。第１のノードが、ステップ２２００においてパケットを受信し、目次フィールドに含まれる情報を使用して新たなパケット構造に含まれるスピーチフレームの数を検出し、ｔ_０におけるパケットの送信からの経過時間を割り出す。次いで、この時間を、第１の実施形態に関して説明したとおりに遅延を割り出すために使用することができる。

図６は、本発明の第３の実施形態に従ってパケット内のＰａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドを使用する遅延の測定に関係するシグナリングおよび他の段階を概略的に示している。ステップ３０００において、第１のノードが、Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドを含むＲＴＰパケットを送信し、このＰａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドは、冗長性のレベルの変更の要求を示す情報を含む。同時に、第１のノードは、このパケットの送信時刻ｔ_０を記録する。このステップに先立ち、第１のノード１０は、比較用としてスピーチフレームまたはスピーチフレームの時刻スタンプを記憶する。第２のノードは、このパケットを受信するとすぐに、Ｐａｃｋｅｔ Ｃｏｎｆｉｇ．フィールドに示されている要求を検出し、ステップ３１００において要求された構造を実現し、この構造に合致するパケットを第１のノードへと送り返す。第１のノードが、ステップ３２００において第１のパケットを受信し、第２の時刻ｔ_１を記録する。次いで、このパケットに含まれる各フレームの時刻スタンプが割り出され、先に受信されたパケットの時刻スタンプと比較される。要求した冗長性が実現されている場合、経過時間ｔ_１−ｔ_０が割り出され、この時間が、第１の実施形態に関して説明したとおりに遅延を割り出すために使用される。好ましくは、設定変更の要求が、オフセット冗長性ではなく、冗長性のレベルだけに関する。しかしながら、設定変更の要求がオフセット冗長性に関する場合には、さらなる受信パケットを監視して、要求した冗長性が実現されているか否かが判断される。

遅延を求めるための基礎として信頼できる測定を得るために、第１の実施形態に関して説明した各ノードによるパケットの取り扱いに関する考慮事項と同じ考慮事項が、これらの実施形態にも等しく当てはまるが、どちらの場合も第２のノードが不連続送信（ＤＴＸ）にて動作している場合に信頼できる測定が実現できないことを、理解できるであろう。さらには、３つの実施形態を別々に説明したが、第１のノード１０によって送信される設定変更の要求が、これらの実施形態のうちの２つ以上の組み合わせで構成されてもよいことを完全に理解することができるであろう。例えば、第１のノード１０が、コーデックモードの変更の要求を、冗長性のレベルの変更の要求と組み合わせて送信することができる。第２のノードが、おそらくは他の変更を妨げる制限が存在するという理由で、これらの要求のうちの１つまたはいくつかのパケット構造を変更することによって応答する場合、これを第１のノードによって有効な応答であると見なされ、遅延を割り出すために使用することができる。

ひとたびノードが特定のリンクにおける端末間の遅延を割り出すと、これを、例えばジッタバッファまたはエンコーダなど、ノードの種々の構成要素の動作を変更するために使用することができる。さらに、この情報をネットワークの他の構成要素へ送信し、マルチメディア遅延に合わせたより全体的なネットワークの調節を可能にすることもできる。

個々のリンクについて端末間の遅延を知ることは、通信サービスにとってきわめて有利である。例えば、遅延が知られた場合、これを知覚されるマルチメディア品質を向上させるために使用することができる。例えば、端末間の遅延が少ないことが明らかになった場合に、ノードのジッタバッファを、遅れ損失の数を少なくし、遅延をわずかに増加させるようなやり方で動作させることができる。このやり方で、会話の品質を維持しながら、マルチメディア品質を高めることができる。また、遅延が少ないことが明らかになった場合、マルチメディアエンコーダが、より長いウインドウ（「先読み（ｌｏｏｋ−ａｈｅａｄ）」）を使用することができる。これにより、コーディング効率、したがってマルチメディア品質が向上する。他方で、遅延が長い場合、ジッタバッファを、より多数の遅れ損失を許容するように動作させ、マルチメディア品質を犠牲にして会話の品質を改善することができる。これは、パケットのうちの少数のパケットに過度のジッタが存在する場合に、特に効果的である。

遅延を知ることで、ネットワークリソースの使用の最適化も可能になる。遅延が短く、かつ観測される損失割合も低い場合、パケット化を、送信されるビットレートおよび／またはパケットレートを下げるように変更することができる。これは、ネットワークの負荷を減らし、知覚される品質に影響を及ぼすことなく他のユーザまたはサービスのために処理能力を解放できると考えられる。

クライアントが動作している端末において、端末相互間の遅延を知ることのさらなる利点は、電池またはＣＰＵなどといったリソースの使用を最適化できる点にある。例えば、端末相互間の遅延が少ない場合、より多くの遅延を持ち込むと考えられるあまり複雑でないジッタバッファを使用することによって、リソースを節約することができる。これにより、電池の持ちをよくすることができ、あるいは処理能力を他の用途に使用することができる。さらには、送信のグループ化によって、ネットワークおよび無線通信部分の動作頻度を下げることができる。例えば、パケットを一度に２つ送信し、送信頻度を半分にすることができる。

Claims (26)

1. 通信ネットワークを介した第１のネットワークノードと第２のネットワークノードとの間の音声または映像データなどのマルチメディアデータの送信のために、往復遅延を割り出す方法であって、データが、エンコードされたデータからなる少なくとも１つのフレームを含むデータユニットにカプセル化されており、
   前記方法が、
   前記第１のネットワークノードが、前記第２のノードへ前記データユニットの構造の設定変更の要求を送信するステップと、
   前記第１のノードが、前記第２のノードから前記設定変更の要求に対応する構造を有するデータの少なくとも１つのデータユニットを含む設定変更の応答を検出するステップと、
   前記第１のノードが、前記設定変更の要求の送信と前記設定変更の応答の検出との間の経過時間を測定し、前記測定された時間を使用して往復遅延の値を割り出すステップと
   を含む方法。
2. 前記データユニットの構造の設定変更の要求を送信する前記ステップが、前記少なくとも１つのフレームにおけるデータのエンコーディングを変更するためのエンコーディングモード変更要求を送信するステップを含み、
   設定変更の応答を検出する前記ステップが、前記エンコーディングモード変更要求において指示されたエンコーディングモードに従ってエンコードされたデータの少なくとも１つのフレームを有するデータユニットを検出するステップを含む、
   請求項１に記載の方法。
3. 設定変更の要求を送信する前記ステップが、前記データユニットに含まれる少なくとも１つのデータフィールドに要求の情報を含ませることによって、データユニットの一部としてインバンドで前記設定変更の要求を送信するステップを含む、請求項２に記載の方法。
4. 設定変更の応答を検出する前記ステップが、前記第２のノードから受信されるデータの前記少なくとも１つのユニットにおいて前記エンコーディングモード変更要求にて指示されたエンコーディングモードに対応するエンコーディングモードを表わす情報を検出するステップを含む、請求項２または請求項３に記載の方法。
5. 各データユニットが、エンコードされたデータからなる少なくとも１つのフレームをパケットペイロードとしてカプセル化しているパケットで構成される、請求項２〜４のいずれか一項に記載の方法。
6. 各データユニットが、エンコードされたデータからなる少なくとも１つのフレームをカプセル化しているパケットであり、
   前記データユニットの構造の設定変更の要求を送信する前記ステップが、パケットに含まれるエンコードされたデータからなるフレームの数を変更する要求を送信するステップを含む、
   請求項１〜４のいずれか一項に記載の方法。
7. 前記設定変更の要求を送信する前記ステップが、第１のパケットを前記第２のノードへ送信するステップを含み、前記第１のパケットが、第１の情報を有する第１のデータフィールドを含み、前記第１の情報が、単一のパケットに含まれるエンコードされたデータからなるフレームの前記数を示す、請求項６に記載の方法。
8. 前記第２のノードから設定変更の応答を検出する前記ステップが、前記第２のノードから第２のパケットを受信して、前記第２のパケットの第２のデータフィールドの情報を検出するステップを含み、前記情報が、前記第２のパケットに含まれるエンコードされたデータからなるフレームの前記数を示す、請求項７に記載の方法。
9. 前記第２のノードから設定変更の応答を検出する前記ステップが、前記第２のノードから第２のパケットを受信するステップと、前記第２のパケットの長さを検出するステップと、前記長さに基づいて前記第２のパケットに含まれるエンコードされたデータからなるフレームの前記数を割り出すステップとを含む、請求項７に記載の方法。
10. 各データユニットが、少なくとも１つのエンコードされたフレームをカプセル化しているパケットであり、
    前記データユニットの構造の設定変更の要求を送信する前記ステップが、エンコードされたフレームを異なるパケットにおいて送信する回数を変更する要求を送信するステップを含む、
    請求項１〜４および請求項６〜９のいずれか一項に記載の方法。
11. 前記設定変更の要求を送信する前記ステップが、パケットの一部を形成するデータフィールドに第１の情報を設定するステップを含み、前記第１の情報が、エンコードされたデータからなる少なくとも１つのフレームを、少なくとも１つの後続のパケットにおいて再送信する要求を表わす、請求項１０に記載の方法。
12. 前記第２のノードから設定変更の応答を検出する前記ステップが、エンコードされたデータからなる少なくとも１つのフレームが前記第２のノードから受信される異なるパケットにおいて検出される前記回数を割り出すステップを含み、
    前記回数が、エンコードされたデータからなる少なくとも１つのフレームの前記再送信の要求に一致する場合に、前記第２のノードへのデータの送信および前記第２のノードからのデータの送信における往復遅延の値を、前記設定変更の要求の送信と前記再送信されたフレームの最初の受信との間に測定された前記経過時間を使用して割り出す、
    請求項１０または１１に記載の方法。
13. 前記通信ネットワークが回路交換ネットワークである、請求項１〜１２のいずれか一項に記載の方法。
14. 前記通信ネットワークがパケット交換網である、請求項１〜１２のいずれか一項に記載の方法。
15. 通信ネットワーク（３０）を介して少なくとも１つの第２のノード（２０）とマルチメディアトラフィックの送受信を行う通信システムのノード（１０）であって、
    前記ネットワーク（３０）を介した前記少なくとも１つの第２のノードへの送信に先立って、データを、エンコード済みのデータからなる少なくとも１つのフレームを含むデータユニットへとエンコードするとともに、前記通信ネットワーク（３０）を介して前記第２のノードから受信されるデータユニットに含まれるエンコード済みのデータをデコードするように構成され、
    前記データユニットの生成および受信を制御するように構成されたコントローラ（１３０）を備え、前記コントローラ（１３０）が、
    前記データユニットの構造の設定変更の要求を、前記第２のノードへ送信し、
    前記設定変更の要求に対応する構造を有する少なくとも１つのデータユニットを含む設定変更の応答であって、前記第２のノードからの前記設定変更の要求に対する設定変更の応答を検出し、
    前記設定変更の要求の送信と前記設定変更の応答の検出との間の前記経過時間を測定し、
    前記測定された時間を使用して、前記第２のノードへのデータの送信および前記第２のノードからのデータの送信についての往復遅延の値を割り出す
    ようにさらに構成されている、ノード（１０）。
16. 前記コントローラが、
    前記データユニットの構造の設定変更の要求として、前記少なくとも１つのフレームにおける前記データのエンコーディングを変更するためのエンコーディングモード変更要求を前記第２のノードへ送信し、
    前記設定変更の応答として、前記エンコーディングモード変更要求にて指示されたエンコーディングモードに従った前記データのエンコーディングを、前記第２のノードから受信される前記データユニットに含まれるデータのフレームにおいて検出する
    ようにさらに構成されている、請求項１５に記載のノード。
17. 前記コントローラが、前記データユニットに含まれる少なくとも１つのデータフィールドに要求の情報を含ませることによって、データユニットの一部としてインバンドで設定変更の前記要求を送信するようにさらに構成されている、請求項１６に記載のノード。
18. 前記ノードが、前記第２のノードからの設定変更の応答を、前記第２のノードから受信されるデータの前記少なくとも１つのユニットにおいて、前記設定変更の要求に対応するデータユニットの構造を表わす情報を検出することによって検出するようにさらに構成されている、請求項１６または請求項１７に記載のノード。
19. 各データユニットが、エンコード済みのデータからなる少なくとも１つのフレームをカプセル化しているパケットであり、
    前記コントローラが、前記データユニットの構造の設定変更の前記要求として、パケットに含まれるエンコード済みのデータからなるフレームの前記数を変更する要求を送信するようにさらに構成されている、
    請求項１５〜１８のいずれか一項に記載のノード。
20. 前記コントローラが、
    第１のパケットの第１のデータフィールドに、単一のパケットに特定の数のエンコード済みのデータのフレームを含むようにする要求を表わす第１の情報を挿入し、
    前記第１のパケットを、前記設定変更の要求として前記第２のノードへ送信する
    ようにさらに構成されている、請求項１９に記載のノード。
21. 前記コントローラが、
    前記第２のノードから第２のパケットを受信し、
    前記第２のパケットの第２のデータフィールドにおいて、前記第２のパケットに含まれるエンコード済みのデータのフレームの前記数を示す第２の情報を検出する
    ようにさらに構成されている、請求項２０に記載のノード。
22. 各データユニットが、少なくとも１つのエンコード済みのフレームをカプセル化しているパケットであり、
    前記コントローラが、前記データユニットの構造の設定変更の要求として、異なるパケットにおいてエンコード済みのデータの少なくとも１つのフレームを送信する前記回数を変更する要求を送信するように構成されている、
    請求項１５〜２１のいずれか一項に記載のノード。
23. 前記コントローラが、第１のパケットのデータフィールドに、エンコード済みのデータの少なくとも１つのフレームを少なくとも１つの別のパケットにおいて再送信する要求を表わす第１の情報を挿入するようにさらに構成されている、請求項２２に記載のノード。
24. 前記コントローラが、
    受信された各フレームについてフレームの再送信回数を割り出し、
    前記回数が、エンコード済みのデータの少なくとも１つのフレームの再送信の要求に対応する場合に、前記第２のノードへのデータの送信および前記第２のノードからのデータの送信における往復遅延の値を、前記設定変更の要求の送信と前記再送信されたフレームの前記最初の受信との間の経過時間を使用して割り出す
    ようにさらに構成されている、請求項２２または請求項２３に記載のノード。
25. 前記通信ネットワークが回路交換ネットワークである、請求項１５〜２４のいずれか一項に記載のノード。
26. 前記通信ネットワークがパケット交換網であり、前記データユニットのそれぞれが、エンコード済みのデータの少なくとも１つのフレームをカプセル化しているパケットで構成されている、請求項１５〜２４のいずれか一項に記載のノード。

Images