(57)【要約】  パケットの送信方法である。該送信方法は、コンテキスト情報を含むパケットが欠落したことを示すフィードバックに要する時間を測定する段階と、測定したフィードバックに要する時間に基づき、周期的にコンテキスト情報を含むパケットを送信する第１のモードと、コンテキスト情報を含むパケットが欠落したことを示すフィードバックに応答してコンテキスト情報を含むパケットを送信する第２のモードとを切り替える段階とを含む。
2010032318.tif 000002
【特許請求の範囲】
【請求項１】
パケットの送信方法であって、
コンテキスト情報を含むパケットが欠落したことを示すフィードバックに要する時間を測定する段階と、
測定した前記フィードバックに要する時間に基づき、周期的にコンテキスト情報を含むパケットを送信する第１のモードと、コンテキスト情報を含むパケットが欠落したことを示すフィードバックに応答してコンテキスト情報を含むパケットを送信する第２のモードとを切り替える段階とを含む送信方法。
【請求項２】
前記フィードバックに要する時間を測定する段階は、
受信ノードが送信ノードに測定要求を送信する段階と、
送信ノードが受信ノードに前記測定要求受信後の経過時間を示す測定応答を送信する段階とを含む、請求項１に記載の送信方法。
【請求項３】
前記第１のモードと第２のモードとを切り替える段階は、受信ノードが、
欠落したパケットを監視する段階と、
測定した前記フィードバックに要する時間と、欠落したパケットの数に応じた閾値とを比較する段階を含む、請求項１に記載の送信方法。
【請求項４】
前記第１のモードはＲＯＨＣのＵｎｉｄｉｒｅｃｔｉｏｎａｌ Ｍｏｄｅであり、
前記第２のモードはＲＯＨＣのＢｉｄｉｒｅｃｔｉｏｎａｌ Ｏｐｔｉｍｉｓｔｉｃ Ｍｏｄｅである、請求項１に記載の送信方法。
【請求項５】
前記フィードバックはＲＯＨＣのコンテキスト要求であり、
前記フィードバックに要する時間はラウンドトリップタイムである、請求項１に記載の送信方法。
【請求項６】
周期的にコンテキスト情報を含むパケットを送信する第１のモードと、コンテキスト情報を含むパケットが欠落したことを示す受信ノードからのフィードバックに応答してコンテキスト情報を含むパケットを送信する第２のモードとを有する送信ノードに対して、前記フィードバックに要する時間を測定して、測定した前記フィードバックに要する時間に基づき、前記送信ノードの第１のモードと第２のモードとを切り替える制御部を有する受信ノード。
【請求項７】
前記制御部に時刻情報を供給する時刻情報管理部をさらに有し、
前記制御部は、前記時刻情報を用いて、前記第２のモードにおける前記フィードバックに要する時間を測定する測定要求を送信し、その測定要求に対して前記送信ノードから受信した測定応答に基づき、前記フィードバックに要する時間を測定する、請求項６に記載の受信ノード。
【請求項８】
欠落したパケットを監視する受信処理部をさらに有し、
前記制御部は、測定した前記フィードバックに要する時間と、欠落したパケットの数に応じた閾値とを比較して前記送信ノードの第１のモードと第２のモードとを切り替える、請求項６に記載の受信ノード。
【請求項９】
受信ノードからの、コンテキスト情報を含むパケットが欠落したことを示す受信ノードからのフィードバックに要する時間を測定する測定要求を受信し、前記測定要求受信後の経過時間を示す測定応答を送信する測定処理部を有する送信ノード。
【請求項１０】
前記測定処理部に時刻情報を供給する時刻情報管理部をさらに有し、
前記測定処理部は、前記時刻情報を用いて、前記測定要求受信後の経過時間を示す測定応答を送信する、請求項９に記載の送信ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信の技術分野に関し、特にパケットの送信方法及びノードに関する。
【背景技術】
【０００２】
現在、第３世代携帯電話の標準化団体である３ＧＰＰにおいて、ＬＴＥ（Long Term Evolution）の国際標準化が進められている。ＬＴＥは３Ｇシステムの飛躍的な性能向上を目指して、モバイル通信において高速伝送を実現し、高速映像配信など高度なサービス環境を提供しようとするものである。また、効率的な周波数利用が図れるシステムとして期待されている。また、３Ｇシステムにおいては、音声とデータ通信が別のインフラで提供されているが、ＬＴＥにおいては、携帯電話の通信インフラの全てをＩＰベースに統合する。これにより、従来の回線交換型インフラを含むモバイルシステムから、ＬＴＥシステムにより完全なＩＰ化がなされたモバイルシステムが実現される見込みである。【０００３】
図１は、ＬＴＥネットワークの構成例を示す図である。図１に示したＬＴＥネットワークは、ユーザ端末（ＵＴ）と基地局（ｅＮｏｄｅＢ、ｅＮＢ）が無線接続され、基地局はａＧＷ（E-UTRAN Access Gateway）にそれぞれ接続されている。さらにａＧＷは、アクセスシステムのアンカー装置であるＩＡＳＡ（Inter AS Anchor）に接続されている。ＩＡＳＡは、外部ネットワークとのアンカー装置ＳＡＥ−Ａ（SAE Anchor）と３ＧＰＰで規定されたネットワークとのアンカー装置３ＧＰＰ−Ａ（3GPP Anchor）とが含まれている。また、ａＧＷとＩＡＳＡは、ＨＳＳ（Home Subscriber Server）に接続されている。さらに、ＩＡＳＡは、ＰＣＲＦ（Policy & Charging Rule Function）を介して他ネットワークと接続されている。【０００４】
モバイルシステムにおけるリアルタイムデータ（音声呼、ビデオストリーミング等）のＩＰ化は、図２や図３に示すプロトコルスタックによる実現が見込まれている。図２は、音声呼プロトコルスタックの構成例（対ＰＳＴＮ）を示す図である。また、図３は、音声呼プロトコルスタックの構成例（自ＡＳ内）を示す図である。すなわち、図２はＬＴＥシステムと既存の回線交換型システムとの接続を示し、図３はＬＴＥシステム同士の接続を示している。【０００５】
音声呼に代表されるリアルタイムデータは、一般的な有線ＩＰネットワークにおいて使用されるＶｏＩＰと同様にＲＴＰ／ＵＤＰ／ＩＰで伝送される。データには各プロトコルのヘッダが付与されるのでオーバヘッドが大きくなる。このため、無線区間では帯域幅が限られているため、同区間の利用効率を向上するため、ヘッダを圧縮することが望ましい。このヘッダを圧縮する機能は、ＬＴＥシステムにおいては、基地局装置（ｅＮｏｄｅＢ）とユーザ端末との間で終端されるＰＤＣＰプロトコル（Packet Data Convergence Protocol: TS36.323）の機能に含まれるＲＯＨＣ（RObust Header Compression: RFC3095）により行われる見込みである。【０００６】
基地局（ｅＮＢ）からユーザ端末（ＵＥ）に向かう下り方向の音声呼を例とする。図２に示したように、音声データ（ＡＭＲデータ）は、ネットワーク側（すなわちＩＭＳ側）からＲＴＰ／ＵＤＰ／ＩＰで送信され、基地局（ｅＮＢ）においてＰＤＣＰプロトコルのＲＯＨＣ（Robust Header Compression）機能によって、ＲＴＰ／ＵＤＰ／ＩＰのヘッダが圧縮される。ヘッダが圧縮された音声データは、ユーザ端末（ＵＥ）まで伝送され、ユーザ端末（ＵＥ）においてＰＤＣＰプロトコルのＲＯＨＣ機能によってヘッダが伸張され、元の音声データに復元される。【０００７】
図４は、音声疎通状態（片方向モード）を示す図である。ＲＴＰ／ＵＤＰ／ＩＰで伝送される音声データは、基地局（送信ノード）とユーザ端末（受信ノード）との間で、例えば２０ｍｓｅｃ周期のフレームとして伝送される。送信ノードは、ＰＤＣＰレイヤにおいて、疎通の開始時と、それ以降の例えばタイマ満了時とに、ヘッダを圧縮していないヘッダ非圧縮フレーム４１Ａを受信ノードに送信するが、他の期間にはヘッダを圧縮したヘッダ圧縮フレーム４２Ａを受信ノードに送信する。受信ノードは、これに対応して、ヘッダ非圧縮フレーム４１Ｂと、ヘッダ圧縮フレーム４２Ｂとを受信する。【０００８】
ＲＯＨＣは、圧縮されたヘッダを伸張（復元）する際、それ以前に受信したヘッダに含まれる情報（コンテキスト）を利用するため、このコンテキストが失われたり破損したりすると、それ以降、圧縮されたヘッダの伸張を行うことが出来なくなる。特に、非圧縮ヘッダを含むフレームが無線区間のエラー等により欠落した場合、後続の圧縮ヘッダを含むフレームは、例えそのフレーム自体は相手に届いたとしても、そのヘッダを復元することができなくなる。結果としてこれらの圧縮ヘッダを持ったフレームはＰＤＣＰレイヤで破棄されてしまう。この状態は、その次に非圧縮ヘッダを含むフレームを受信し、コンテキストが回復されるまで継続する。この様子を図５に示した。図５は、パケット欠落がある音声疎通状態（片方向モード）を示す図である。このようなフレームの破棄が生じると、その結果として音声の品質が劣化してしまう。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
一方、非圧縮ヘッダを含むフレームのサイズは、圧縮ヘッダを含むフレームのサイズの３倍程度となる場合があり、伝送経路の利用効率の観点からは、なるべく非圧縮ヘッダを含むフレームの送信頻度を少なくすることが望ましい。
【課題を解決するための手段】
【００１０】
一実施形態によるパケットの送信方法は、コンテキスト情報を含むパケットが欠落したことを示すフィードバックに要する時間を測定する段階と、測定した前記フィードバックに要する時間に基づき、周期的にコンテキスト情報を含むパケットを送信する第１のモードと、コンテキスト情報を含むパケットが欠落したことを示すフィードバックに応答してコンテキスト情報を含むパケットを送信する第２のモードとを切り替える段階とを含む。【００１１】
上記送信方法において、前記フィードバックに要する時間を測定する段階は、受信ノードが送信ノードに測定要求を送信する段階と、送信ノードが受信ノードに前記測定要求受信後の経過時間を示す測定応答を送信する段階とを含んでいてもよい。【００１２】
また、上記送信方法において、前記第１のモードと第２のモードとを切り替える段階は、受信ノードが、欠落したパケットを監視する段階と、測定した前記フィードバックに要する時間と、欠落したパケットの数に応じた閾値とを比較する段階を含んでいてもよい。【００１３】
他の実施形態による受信ノードは、周期的にコンテキスト情報を含むパケットを送信する第１のモードと、コンテキスト情報を含むパケットが欠落したことを示す受信ノードからのフィードバックに応答してコンテキスト情報を含むパケットを送信する第２のモードとを有する送信ノードに対して、前記フィードバックに要する時間を測定して、測定した前記フィードバックに要する時間に基づき、前記送信ノードの第１のモードと第２のモードとを切り替える制御部を有する。【００１４】
さらに、他の実施形態による送信ノードは、受信ノードからの、コンテキスト情報を含むパケットが欠落したことを示す受信ノードからのフィードバックに要する時間を測定する測定要求を受信し、前記測定要求受信後の経過時間を示す測定応答を送信する測定処理部を有する。
【発明の効果】
【００１５】
コンテキスト情報を含むパケットが欠落したときに、コンテキスト情報を含むパケットを短い時間で送信することができる。
【図面の簡単な説明】
【００１６】
【図１】ネットワークの構成例を示す図である。
【図２】音声呼プロトコルスタックの構成例（対ＰＳＴＮ）を示す図である。
【図３】音声呼プロトコルスタックの構成例（自ＡＳ内）を示す図である。
【図４】音声疎通状態（片方向モード）を示す図である。
【図５】パケット欠落がある音声疎通状態（片方向モード）を示す図である。
【図６】音声疎通状態（双方向モード）を示す図である。
【図７】パケット欠落がある音声疎通状態（双方向モード）を示す図である。
【図８】パケット欠落がある音声疎通状態（双方向モード）を示す別の図である。
【図９】ＰＤＣＰフレームフォーマットを示す図である。
【図１０】一実施形態によるＲＯＨＣ動作モード切替方法を示す図である
【図１１Ａ】ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１１Ｂ】ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１１Ｃ】ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１１Ｄ】ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１２】ＲＴＴの測定方法を示す図である。
【図１３】ＲＴＴ測定要求及び応答のフレームフォーマットを示す図である。
【図１４Ａ】他の実施形態によるＲＯＨＣ動作モード切替方法における、ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１４Ｂ】他の実施形態によるＲＯＨＣ動作モード切替方法における、ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１４Ｃ】他の実施形態によるＲＯＨＣ動作モード切替方法における、ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１４Ｄ】他の実施形態によるＲＯＨＣ動作モード切替方法における、ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。
【図１５】一実施形態による送信ノードの構成を示す図である。
【図１６】一実施形態による受信ノードの構成を示す図である。
【図１７】他の実施形態による受信ノードの構成を示す図である。
【図１８】ＲＴＴ測定の実施例を示す図である。
【符号の説明】
【００１７】
１５０  送信ノード
１５１０  Ｌ２レイヤ終端部
１５２０  ＰＤＣＰ（ＲＯＨＣ）終端部
１５２１  デコンプレッサ
１５２２  コンプレッサ
１５２３  ＲＴＴ測定処理部
１５２４  時刻情報管理部
１５２５  受信処理部
１５２６  送信処理部
１６０  受信ノード
１６１０  Ｌ２レイヤ終端部
１６２０  ＰＤＣＰ（ＲＯＨＣ）終端部
１６２１  デコンプレッサ
１６２２  コンプレッサ
１６２３  ＲＯＨＣ制御部
１６２４  時刻情報管理部
１６２５  受信処理部
１６２６  送信処理部
１６３０  ＲＴＰ／ＵＤＰ／ＩＰ終端部
１６４０  ＡＭＲ終端部
１７０  受信ノード
１７２０  ＰＤＣＰ（ＲＯＨＣ）終端部
１７２３  ＲＯＨＣ制御部
１７２５  受信処理部
【発明を実施するための最良の形態】
【００１８】
図面を参照して実施形態を詳しく説明する。図面を通して同一または対応する構成要素には同一または対応する参照符号を付した。【００１９】
以下の説明では、基地局（送信ノード）からユーザ端末（受信ノード）に音声データ等のリアルタイムデータを送信するものと仮定する。当業者には明らかなように、他の実施形態では、ユーザ端末から基地局に音声データ等のリアルタイムデータを送信してもよい。【００２０】
また、音声データ等のリアルタイムデータのフレームのヘッダは、ＰＤＣＰプロトコルのＲＯＨＣ機能により圧縮されるものと仮定する。他の実施形態では、ヘッダの圧縮はその他のプロトコルで圧縮されてもよい。【００２１】
ＰＤＣＰ（Packet Data Convergence Protocol: TS36.323）プロトコルのＲＯＨＣ（Robust Header Compression: RFC3095）の動作モードには、Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  ｍｏｄｅと、Ｂｉｄｉｒｅｃｔｉｏｎａｌ  Ｍｏｄｅとが規定され、Ｂｉｄｉｒｅｃｔｉｏｎａｌ  Ｍｏｄｅには、Ｏｐｔｉｍｉｓｔｉｃ  Ｍｏｄｅと、Ｒｅｌｉａｂｌｅ  Ｍｏｄｅとが規定されている。以下、片方向モードはＵｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｍｏｄｅを指し、双方向モードはＢｉｄｉｒｅｃｔｉｏｎａｌ  Ｏｐｔｉｍｉｓｔｉｃ  Ｍｏｄｅを指す。各モードを以下に説明する。【００２２】
片方向モード（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｍｏｄｅ）は、受信ノードからのフィードバックを行わず、送信ノードが一定周期でコンテキストを送信することにより通信の品質保証を行う。フィードバックを行わないため逆方向の帯域を圧迫しない。コンテキスト喪失時のデータロス時間は、コンテキスト送信周期に依存する。図４及び図５は片方向モードの場合を示している。【００２３】
双方向モード（Ｂｉｄｉｒｅｃｔｉｏｎａｌ  Ｏｐｔｉｍｉｓｔｉｃ  Ｍｏｄｅ）は、受信ノードからのフィードバックを行うことにより通信の品質保証を行う。コンテキストは必要な時のみ送信されるため、圧縮ヘッダを含むフレームの送信頻度が高くなる。コンテキスト喪失時のデータロス時間はフィードバック時間に依存する。【００２４】
図６は、双方向モードにおける音声疎通状態を示す図である。図６に示したように、送信ノードは、非圧縮ヘッダを含むフレーム６１Ａを送信すると、その後は受信ノードからのフィードバックが無い限り、圧縮ヘッダを含むフレーム６２Ａを送信する。これに対応して、受信ノードは、非圧縮ヘッダを含むフレーム６１Ｂと、圧縮ヘッダを含むフレーム６２Ｂとを受信する。図４に示した片方向モードの場合と比較して、非圧縮ヘッダを含むフレーム６１Ａが周期的に送信されないため、非圧縮ヘッダを含むフレームの送信頻度が低いことが分かる。【００２５】
図７は、双方向モードにおいて、パケット欠落がある音声疎通状態を示す図である。図７に示したように、送信ノードは、非圧縮ヘッダを含むフレーム７１Ａを送信するが、このフレーム７１Ａは何らかの原因で欠落し、受信ノードには到達しなかったものと仮定する。すなわち、受信ノードは、フレーム７１Ａに対応する非圧縮ヘッダを含むフレーム７１Ｂが欠落し、受信していないものと仮定する。【００２６】
送信ノードは、フレーム７１Ａに続けて圧縮ヘッダを含むフレーム７２Ａを受信ノードに送信する。このフレーム７２Ａは欠落せず、受信ノードに到達する（フレーム７２Ｂ）。しかし、受信ノードは、フレーム７１Ｂが欠落しそのコンテキストが利用できないため、フレーム７２Ｂを正しく復元できない。それを知った受信ノードは、送信ノードにエラー回復要求（フィードバック）を送信する。【００２７】
送信ノードは、受信ノードからのエラー回復要求（フィードバック）を受信する前に、圧縮ヘッダを含むフレーム７３Ａを送信している。このフレーム７３Ａも欠落せず、受信ノードに到達する（フレーム７３Ｂ）。しかし、受信ノードは、フレーム７１Ｂが欠落しそのコンテキストが利用できないため、フレーム７３Ｂも正しく復元できない。【００２８】
送信ノードは、受信ノードからのエラー回復要求を受信すると、非圧縮ヘッダを含むフレーム７４Ａを送信する。このフレーム７４Ａは欠落せず、受信ノードに到達する（フレーム７４Ｂ）。【００２９】
一方、図８は、双方向モードにおいて、パケット欠落がある音声疎通状態を示す別の図である。図８に示したように、送信ノードは、非圧縮ヘッダを含むフレーム８１Ａを送信するが、このフレーム８１Ａは何らかの原因で欠落し、受信ノードには到達しなかったものと仮定する。すなわち、受信ノードは、フレーム８１Ａに対応する非圧縮ヘッダを含むフレーム８１Ｂが欠落し、受信していないものと仮定する。【００３０】
送信ノードは、フレーム８１Ａに続けて圧縮ヘッダを含むフレーム８２Ａを受信ノードに送信する。このフレーム８２Ａは欠落せず、受信ノードに到達する（フレーム８２Ｂ）。しかし、受信ノードは、フレーム８１Ｂが欠落しそのコンテキストが利用できないため、フレーム８２Ｂを正しく復元できない。それを知った受信ノードは、送信ノードにエラー回復要求（フィードバック）を送信する。【００３１】
送信ノードは、受信ノードからのエラー回復要求（フィードバック）を受信する前に、圧縮ヘッダを含むフレーム８３Ａを送信している。このフレーム８３Ａも欠落せず、受信ノードに到達する（フレーム８３Ｂ）。しかし、受信ノードは、フレーム８１Ｂが欠落しそのコンテキストが利用できないため、フレーム８３Ｂも正しく復元できない。【００３２】
送信ノードは、受信ノードからのエラー回復要求を受信すると、非圧縮ヘッダを含むフレーム８４Ａを送信する。このフレーム８４Ａは欠落せず、受信ノードに到達する（フレーム８４Ｂ）。【００３３】
図７と図８は、非圧縮ヘッダを含むフレーム７１Ａ、８１Ａ（受信ノード側のフレーム７１Ｂ、８１Ｂ）が欠落したためその後に送信された圧縮ヘッダを含むフレーム７２Ａ、７３Ａ、８２Ａ、８３Ａ（受信ノード側のフレーム７２Ｂ、７３Ｂ、８２Ｂ、８３Ｂ）が正しく復元できない点で同じである。しかし、図７と図８は、送信ノードが圧縮ヘッダを含むフレーム７２Ａ、８２Ａを送信してから、受信ノードからのエラー回復要求を受信して次の非圧縮ヘッダを含むフレーム７４Ａ、８４Ａ（受信ノード側のフレーム７４Ｂ、８４Ｂ）を送信するまでの時間（ラウンドトリップタイムＲＴＴ）が異なる。図７では、ラウンドトリップタイムＲＴＴが短いため、欠落または正しく復元できないフレームは７１Ａ〜７３Ａ（受信ノード側のフレーム７１Ｂ〜７３Ｂ）の３フレームだけであるが、図８では、ラウンドトリップタイムＲＴＴが長いため、欠落または正しく復元できないフレームは８１Ａ〜８３Ａ（受信ノード側のフレーム８１Ｂ〜８３Ｂ）の１４フレームとなってしまう。受信ノードにてフレームを復元できない期間を復元不可期間と呼ぶ。【００３４】
一方、ＲＦＣ３０９５で規定されているように、ＲＯＨＣの動作モードは、片方向モードと双方向モードとの間で切り替えることが可能である。この切り替えは、受信ノードから送信ノードにＰＤＣＰフレームを送信することにより行われる。【００３５】
次に、ＰＤＣＰのヘッダについて説明する。図９は、ＰＤＣＰのフレームフォーマットを示す図である。図９において、９１はＰＤＣＰデータＰＤＵフォーマットを示し、９２はＰＤＣＰコントロールＰＤＵフォーマットを示す。各フォーマットに含まれるパラメータは表１の通りである。【００３６】
【表１】
2010032318.tif 000003
非圧縮ヘッダを含むフレームが伝送経路上で欠落し、コンテキストが喪失した場合の復元不可期間は、片方向モードの場合、図５に示したように、受信ノードが非圧縮ヘッダを含むフレーム５１Ｂを受信してから次の非圧縮ヘッダを含むフレームを受信するまでの期間である。一方、双方向モードの場合、図７と図８に示したように、ラウンドトリップタイムＲＴＴにより決まってくる。【００３７】
ラウンドトリップタイムＲＴＴは、ユーザ端末（ＵＥ）の移動にともない、ユーザ端末と基地局（ｅＮＢ）との間の距離やパス（経路）が変化することにより変化する。また、無線品質の変動によっても変化する。無線品質が悪化すると、ＰＤＣＰレイヤの下位にあるＲＬＣレイヤ及びＭＡＣレイヤで実行するＡＲＱ／ＨＡＲＱにより再送頻度が高まり、その結果としてＰＤＣＰレイヤにおけるラウンドトリップタイムＲＴＴが大きくなる。【００３８】
したがって、ラウンドトリップタイムＲＴＴに応じて片方向モードと双方向モードとを動的かつ適切に切り替えることにより、復元不可期間を短縮することが可能である。これにより、ユーザに提供する音声の品質劣化を軽減することができる。【００３９】
図１０は、一実施形態によるＲＯＨＣ動作モード切替方法を示す図である。受信ノードは、まず、ステップＳ１０１において、ラウンドトリップタイムＲＴＴ（ＴＲＴＴ）を測定する。具体的測定方法については、図１２を参照して詳しく説明する。【００４０】
次に、ステップＳ１０３において、測定したラウンドトリップタイムＲＴＴ（ＴＲＴＴ）と、所定の閾値ＴＴＨＲとを比較する。この閾値ＴＴＨＲは、例えば、片方向モードにおいて、非圧縮ヘッダを含むフレームの直後の圧縮ヘッダを含むフレームから、次の非圧縮ヘッダを含むフレームまでの時間である。すなわち、片方向モードにおいて、非圧縮ヘッダを含むフレームの送信周期（ＴＲＥＦ）（以下、リフレッシュ周期とも呼ぶ）からフレーム転送周期（ＴＸ）を引いたものである。式で表すと次式（１）の通りである。【００４１】
ＴＴＨＲ＝ＴＲＥＦ−ＴＸ        （１）
ステップＳ１０３における比較の結果、ＴＲＴＴがＴＴＨＲ以下であれば、ステップＳ１０５に進み、以降のＲＯＨＣ動作モードを双方向モード（Ｂｉｄｉｒｅｃｔｉｏｎａｌｏ  Ｏｐｔｉｍｉｓｔｉｃ  ｍｏｄｅ）に設定して処理を終了する。【００４２】
一方、ステップＳ１０３における比較の結果、ＴＲＴＴがＴＴＨＲより大きければ、ステップＳ１０７に進み、以降のＲＯＨＣ動作モードを片方向モード（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  ｍｏｄｅ）に設定して処理を終了する。【００４３】
図１１Ａ乃至図１１Ｄは、ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。フレーム転送周期ＴＸは２０ｍｓ、片方向モードにおけるリフレッシュ周期ＴＲＥＦは１２０ｍｓであると仮定した。この場合、所定の閾値ＴＴＨＲは、式（１）によりＴＴＨＲ＝１２０−２０＝１００ｍｓとなる。【００４４】
片方向モードにおいては、図１１Ａに示したように、送信ノードは、非圧縮ヘッダを含むフレーム１１１Ａを送信するが、このフレーム１１１Ａは何らかの原因で欠落し、受信ノードには到達しなかったものと仮定する。すなわち、受信ノードは、フレーム１１１Ａに対応する非圧縮ヘッダを含むフレーム１１１Ｂが欠落し、受信していないものと仮定する。【００４５】
送信ノードは、フレーム１１１Ａに続けて圧縮ヘッダを含むフレーム１１２Ａ、１１３Ａを受信ノードに送信する。このフレーム１１２Ａ、１１３Ａは欠落せず、受信ノードに到達する（フレーム１１２Ｂ、１１３Ｂ）。しかし、受信ノードは、フレーム１１１Ｂが欠落しそのコンテキストが利用できないため、フレーム１１２Ｂ、１１３Ｂを正しく復元できない。結局、受信ノードは、送信ノードから次の非圧縮ヘッダを含むフレーム１１４Ａを受信（フレーム１１４Ｂ）するまで、受信したフレームを復元できない。結果として、受信ノードにおける復元不可期間は１２０ｍｓとなる。【００４６】
一方、双方向モードにおいては、図１１Ｂ乃至図１１Ｄに示したように、送信ノードは、非圧縮ヘッダを含むフレーム１１１Ａを送信するが、このフレーム１１１Ａは何らかの原因で欠落し、受信ノードには到達しなかったものと仮定する。すなわち、受信ノードは、フレーム１１１Ａに対応する非圧縮ヘッダを含むフレーム１１１Ｂが欠落し、受信していないものと仮定する。【００４７】
送信ノードは、フレーム１１１Ａに続けて圧縮ヘッダを含むフレーム１１２Ａを受信ノードに送信する。このフレーム１１２Ａは欠落せず、受信ノードに到達する（フレーム１１２Ｂ）。しかし、受信ノードは、フレーム１１１Ｂが欠落しそのコンテキストが利用できないため、フレーム１１２Ｂを正しく復元できない。それを知った受信ノードは、送信ノードにコンテキスト要求（フィードバック）を送信する。【００４８】
送信ノードは、受信ノードからのコンテキスト要求（フィードバック）を受信する前に、圧縮ヘッダを含むフレーム１１３Ａを送信している。このフレーム１１３Ａも欠落せず、受信ノードに到達する（フレーム１１３Ｂ）。しかし、受信ノードは、フレーム１１１Ｂが欠落しそのコンテキストが利用できないため、フレーム１１３Ｂも正しく復元できない。【００４９】
送信ノードは、受信ノードからのエラー回復要求を受信すると、非圧縮ヘッダを含むフレーム１１４Ａを送信する。このフレーム１１４Ａは欠落せず、受信ノードに到達する（フレーム１１４Ｂ）。【００５０】
図１１Ｂに示したように、ラウンドトリップタイムＲＴＴ（ＴＲＴＴ）と閾値（ＴＴＨＲ）とを比較した結果、ＴＲＴＴ＜ＴＴＨＲとなる場合（図１１ＢではＴＲＴＴ＝８０ｍｓ）は、図１０に示したフローチャートに従って、ＲＯＨＣの動作モードとして双方向モードを選択する。双方向モードが選択されることにより、非圧縮ヘッダを含むフレームが伝送経路上で欠落した際の受信ノードにおける復元不可期間は、片方向モードにおける復元不可期間（１２０ｍｓ）よりも小さくなる（図１１Ｂでは１００ｍｓ）。結果としてユーザに提供される音声品質の劣化が軽減される。【００５１】
また、図１１Ｃに示したように、ラウンドトリップタイムＲＴＴ（ＴＲＴＴ）と閾値（ＴＴＨＲ）とを比較した結果、ＴＲＴＴ＝ＴＴＨＲとなる場合（図１１ＣではＴＲＴＴ＝１００ｍｓ）は、図１０に示したフローチャートに従って、ＲＯＨＣの動作モードとして双方向モードを選択する。双方向モードが選択されることにより、非圧縮ヘッダを持つフレームが伝送経路上で欠落した際の受信ノードにおける復元不可期間は、片方向モードにおける復元不可期間（１２０ｍｓ）と同等になる（図１１Ｃでは１２０ｍｓ）。結果としてユーザに提供される音声品質の劣化の点でも片方向モードと同等になる。この場合、伝送経路の利用効率の観点から、ＲＯＨＣの動作モードとして、必要な時のみコンテキストが送信される双方向モードを選択することが好ましい。しかし、他の実施形態では、片方向モードを選択してもよい。【００５２】
なお、図１１Ｄに示したように、ラウンドトリップタイムＲＴＴ（ＴＲＴＴ）と閾値（ＴＴＨＲ）を比較した結果、ＴＲＴＴ＞ＴＴＨＲとなる場合（図１１ＤではＴＲＴＴ＝１２０ｍｓ）は、図１０に示したフローチャートに従って、ＲＯＨＣの動作モードとして片方向モードを選択する。もし双方向モードを選択すると、非圧縮ヘッダを持つフレームが伝送経路上で欠落した際の受信ノードにおける復元不可期間は、片方向モードにおける復元不可期間（１２０ｍｓ）よりも大きくなる（図１１Ｄでは１４０ｍｓ）。よって、この場合は、片方向モードを選択する方が、双方向モードを選択するよりも、結果としてユーザに提供される音声品質の劣化を軽減するものとなる。【００５３】
さて、片方向モードではコンテキスト要求は実施されず、双方向モードにおいてもコンテキスト要求は必要時にのみ実施される。このため、動作モードの切替のためにラウンドトリップタイムＲＴＴを必要としても、必要な時にラウンドトリップタイムＲＴＴを測定することができない。しかし、ＬＴＥシステムにおいて標準となるプロトコルであるＰＤＣＰの機能のみによりラウンドトリップタイムＲＴＴの測定を実現できることが好ましい。【００５４】
そこで、図１０に示したラウンドトリップタイムＲＴＴの測定（ステップＳ１０１）において、ＰＤＣＰレイヤのコントロールＰＤＵ（control PDU）を用いてＲＴＴを測定する。【００５５】
具体的には、図１２に示したように、まず受信ノードが送信ノードにＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定要求）を送信する。送信ノードは、受信ノードからＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定要求）を受信すると、ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定応答）を返信する。ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定応答）には、送信ノードにおけるＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定要求）受信後の経過時間が格納されている。受信ノードは、ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定応答）を受信すると、ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定要求）の送信時刻と、ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定応答）の受信時刻と、ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定応答）に格納された情報とから、伝送経路の往復時間を求めることができる。この往復時間に、受信ノードが復元不可フレームを受信してからコンテキスト要求（Feedback）を送信するまでの内部処理時間（既知とする）を加えることで、送信ノードが受信ノードにて復元不可となるフレームを送信してから受信ノードからFeedbackを受信するまでの時間、すなわちラウンドトリップタイムＲＴＴを知ることができる。【００５６】
かかるラウンドトリップタイムＲＴＴの測定方法を実現するために、ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵのＰＤＵタイプに、ＲＴＴ測定要求とＲＴＴ測定応答とを新たに付け加える。図１３は、ＲＴＴ測定要求及び応答のフレームフォーマットを示す図である。図１３に示した１３１はＲＴＴ測定要求を示し、１３２はＲＴＴ測定応答を示す。各フレームフォーマットはＴＳ３６．３２３に規定されている他のＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵに倣うものとする。各パラメータの内容を示す表２に示す。【００５７】
【表２】
2010032318.tif 000004
表２に示したように、Ｃｏｎｔｒｏｌ  ＰＤＵとして、ＲＴＴ測定要求（RTT Measurement Request）とＲＴＴ測定応答（RTT Measurement Response）とが追加され、これらが利用するパラメータＭＵＩとＤＲＭＲとが新たに追加されている。【００５８】
ＲＴＴ測定要求送信時刻（ＴＴＸ）と、ＲＴＴ測定応答受信時刻（ＴＲＸ）と、ＲＴＴ測定応答に格納されたＤＲＭＲ（ＴＤＲＭＲ）と、受信ノードが復元不可フレーム受信からフィードバックを送信するまでの内部処理時間（ＴＩＮＳ）とから、ラウンドトリップタイムＲＴＴ（ＴＲＴＴ）を式（２）により求めることができる。【００５９】
ＴＲＴＴ＝ＴＲＸ−ＴＴＸ−ＴＤＲＭＲ＋ＴＩＮＳ      （２）
このように、ＬＴＥシステムにおいて標準となるプロトコルであるＰＤＣＰの機能のみによりラウンドトリップタイムＲＴＴの測定を実現できるので、既存のシステムに対する追加的な導入が容易になる。【００６０】
式（１）に示した閾値ＴＴＨＲ＝ＴＲＥＦ−ＴＸは、暗黙のうちに欠落フレームが１つだけ（すなわち、図１１Ｂ乃至図１１Ｄに示したフレーム１１１Ｂのみ）であると仮定している。しかし、それに続くフレーム１１２Ｂやフレーム１１３Ｂの一部も欠落する場合が考えられる。そこで、他の実施形態では、受信ノードにて、例えばＰＤＣＰレイヤのシーケンス番号（ＳＮ）を監視し、複数フレームが連続して欠落する場合には、ＲＴＴに対する閾値（ＴＴＨＲ）にそれを反映することができる。具体的には、受信ノードにおいてＰＤＣＰレイヤのシーケンス番号を監視し、監視開始後に確認された欠落フレームの数（すなわちシーケンス番号の飛び）の最悪値をｍ（≧２）とすると、ＲＴＴに対する閾値（ＴＴＨＲ）を式（３）に基づき算出する方がよい。
ＴＴＨＲ＝ＴＲＥＦ−（ＴＸ×ｍ）      （３）
式（３）を使用することにより、伝送経路上にて複数フレームが連続して欠落しうる状況においても、ＲＯＨＣの動作モードを適切に選択することができる。【００６１】
図１４Ａ乃至図１４Ｄは、この実施形態によるＲＯＨＣ動作モード切替方法における、ＲＯＨＣ動作モードごとの復元不可期間の例を示す図である。ここでは、非圧縮ヘッダを含むフレームを先頭に３フレームが連続して伝送経路上で欠落したものと仮定する。すなわち、受信ノードにいてＰＤＣＰレイヤのシーケンス番号を監視し、監視開始後に確認されたシーケンス番号の飛びの最悪値がｍ＝３であるとする。また、フレーム転送間隔は２０ｍｓ、片方向モードにおけるリフレッシュ周期は１２０ｍｓとする。【００６２】
片方向モードにおいては、図１４Ａに示したように、送信ノードは、非圧縮ヘッダを含むフレーム１４１Ａを送信するが、このフレーム１４１Ａは何らかの原因で欠落し、受信ノードには到達しなかったものと仮定する。すなわち、受信ノードは、フレーム１４１Ａに対応する非圧縮ヘッダを含むフレーム１４１Ｂが欠落し、受信していないものと仮定する。【００６３】
送信ノードは、フレーム１４１Ａに続けて圧縮ヘッダを含むフレーム１４２Ａを送信するが、これも欠落し、受信ノードには届かず、受信ノードはこれに対応する圧縮ヘッダを含むフレーム１４２Ｂを受信していないものと仮定する。送信ノードは、さらにフレーム１４３Ａ、１４４Ａを受信ノードに送信する。このフレーム１４３Ａ、１４４Ａは欠落せず、受信ノードに到達する（フレーム１４３Ｂ、１４４Ｂ）。しかし、受信ノードは、フレーム１４１Ｂが欠落しそのコンテキストが利用できないため、フレーム１４３Ｂ、１４４Ｂを正しく復元できない。結局、受信ノードは、送信ノードから次の非圧縮ヘッダを含むフレーム１４５Ａを受信（フレーム１４５Ｂ）するまで、受信したフレームを復元できない。結果として、受信ノードにおける復元不可期間は１２０ｍｓとなる。【００６４】
一方、双方向モードにおいては、図１４Ｂ乃至図１４Ｄに示したように、送信ノードは、非圧縮ヘッダを含むフレーム１４１Ａを送信するが、このフレーム１４１Ａは何らかの原因で欠落し、受信ノードには到達しなかったものと仮定する。すなわち、受信ノードは、フレーム１４１Ａに対応する非圧縮ヘッダを含むフレーム１４１Ｂが欠落し、受信していないものと仮定する。【００６５】
送信ノードは、フレーム１４１Ａに続けて圧縮ヘッダを含むフレーム１４２Ａを受信ノードに送信するが、このフレームも欠落した（受信ノードは対応するフレーム１４２Ｂを受信しない）ものと仮定する。さらに、送信ノードは、圧縮ヘッダを含むフレーム１４３Ａを送信するが、このフレーム１４３Ａは欠落せず、受信ノードに到達する（フレーム１４３Ｂ）。しかし、受信ノードは、フレーム１４１Ｂが欠落しそのコンテキストが利用できないため、フレーム１４３Ｂを正しく復元できない。それを知った受信ノードは、送信ノードにコンテキスト要求（フィードバック）を送信する。【００６６】
送信ノードは、受信ノードからのコンテキスト要求（フィードバック）を受信する前に、圧縮ヘッダを含むフレーム１４４Ａを送信している。このフレーム１４４Ａも欠落せず、受信ノードに到達する（フレーム１４４Ｂ）。しかし、受信ノードは、フレーム１４１Ｂが欠落しそのコンテキストが利用できないため、フレーム１４４Ｂも正しく復元できない。【００６７】
送信ノードは、受信ノードからのエラー回復要求を受信すると、非圧縮ヘッダを含むフレーム１４５Ａを送信する。このフレーム１４５Ａは欠落せず、受信ノードに到達する（フレーム１４５Ｂ）。【００６８】
図１４Ｂに示したように、ラウンドトリップタイムＲＴＴはＴＲＴＴ＝８０ｍｓであるが、これを前述の式（１）で算出したＲＴＴの閾値ＴＴＨＲ＝１００ｍｓと比較すると、ＴＲＴＴ＜ＴＴＨＲとなり、図１０に示したフローチャートに従ってＲＯＨＣの動作モードとして双方向モードを選択すべきことになる。しかし、復元不可期間は１４０ｍｓであり、片方向モードの場合より長くなってしまい、正しい選択ができていないことになる。【００６９】
一方、式（３）で算出したＲＴＴの閾値ＴＴＨＲ＝６０ｍｓと比較すると、ＴＲＴＴ＞ＴＴＨＲとなり、図１０に示したフローチャートに従ってＲＯＨＣの動作モードとして片方向モードを選択すべきことになる。【００７０】
同様に、図１４Ｃ及び図１４Ｄに示したように、ＴＴＨＲを前述の式（３）で算出した上で、ＴＲＴＴ≦ＴＴＨＲとなる場合には、図１０に示したフローチャートに従ってＲＯＨＣの動作モードとして双方向モードを選択すれば、非圧縮ヘッダを持つフレームを先頭に複数フレームが連続して欠落した場合においても、受信ノードにおける復元不可期間は、片方向モードにおけるそれと比較して同等以下とすることができる。【００７１】
次に、ここまで説明した送信方法を実施するための、送信ノードと受信ノードの構成を説明する。なお、ここでは、基地局（ｅＮＢ）を送信ノードとし、ユーザ端末（ＵＥ）を受信ノードとして説明するが、言うまでもなく、基地局（ｅＮＢ）が受信ノードとなり、ユーザ端末（ＵＥ）が送信ノードとなってもよい。【００７２】
図１５は、一実施形態による送信ノードの構成を示す図である。図１５に示す送信ノード１５０は、受信ノードとのデータ疎通を行うための基本的機能を提供する機能ブロックであるＬ２レイヤ終端部１５１０と、ＰＤＣＰ（ＲＯＨＣ）レイヤの機能を終端する機能ブロックであるＰＤＣＰ（ＲＯＨＣ）終端部１５２０とを有する。【００７３】
ＰＤＣＰ（ＲＯＨＣ）終端部１５２０は、次の構成要素を有する：
ＲＯＨＣのヘッダ伸張を実施する機能ブロックであるデコンプレッサ（Decompressor）１５２１；
ＲＯＨＣのヘッダ圧縮を実施する機能ブロックであるコンプレッサ（Compressor）１５２２；
ＰＤＣＰ  Ｃｏｎｔｒｏｌ  ＰＤＵ（ＲＴＴ測定要求/応答）を処理する機能ブロックであるＲＴＴ測定処理部１５２３；
時刻情報を管理し、ＲＴＴ測定処理部１５２３に提供する機能ブロックである時刻情報管理部１５２４；
受信したＰＤＣＰ ＰＤＵのヘッダ処理を実施し各機能ブロックへの振分け処理を実施する機能ブロックである受信処理部１５２５；及び
各機能ブロックから集約したＰＤＣＰ ＰＤＵへのヘッダ付与と送信タイミングのスケジューリングを実施する機能ブロックである送信処理部１５２６。【００７４】
送信ノード１５０は、従来の送信ノードと比較して、少なくともＰＤＣＰ（ＲＯＨＣ）終端部１５２０内にＲＴＴ測定処理部１５２３と時刻情報管理部１５２４とを有する点で相違する。【００７５】
図１６は、一実施形態による受信ノードの構成を示す図である。図１６に示した受信ノード１６０は、送信ノード（例えば図１５の送信ノード１５０）とのデータ疎通を行うための基本的機能を提供する機能ブロックであるＬ２レイヤ終端部１６１０と、ＰＤＣＰ（ＲＯＨＣ）レイヤの機能を終端する機能ブロックであるＰＤＣＰ（ＲＯＨＣ）終端部１６２０と、ＲＴＰ／ＵＤＰ／ＩＰレイヤの機能を終端する機能ブロックであるＲＴＰ／ＵＤＰ／ＩＰ終端部１６３０と、音声の符号化/復号化を行う機能ブロックであるＡＭＲ終端部１６４０とを含む。【００７６】
また、ＰＤＣＰ（ＲＯＨＣ）終端部１６２０は、次の構成要素を含む：
ＲＯＨＣのヘッダ伸張を実施する機能ブロックであるデコンプレッサ（Decompressor）１６２１；
ＲＯＨＣのヘッダ圧縮を実施する機能ブロックであるコンプレッサ（Compressor）１６２２；
ＰＤＣＰ Control ＰＤＵ（ＲＴＴ測定要求/応答）を用いてＲＴＴを測定しＲＯＨＣの動作モードを制御する機能ブロックであるＲＯＨＣ制御部１６２３；
時刻情報を管理しＲＯＨＣ制御部１６２３へ提供する機能ブロックである時刻情報管理部１６２４；
受信したＰＤＣＰ ＰＤＵのヘッダ処理を実施し各機能ブロックへの振分け処理を実施する機能ブロックである受信処理部１６２６；及び
各機能ブロックから集約したＰＤＣＰ ＰＤＵへのヘッダ付与と送信タイミングのスケジューリングを実施する機能ブロックである送信処理部１６２６。【００７７】
受信ノード１６０は、従来の受信ノードと比較して、少なくともＰＤＣＰ（ＲＯＨＣ）終端部１６２０内にＲＯＨＣ制御部１６２３と時刻情報管理部１６２４とを有する点で相違する。【００７８】
図１５と図１６を参照して、実施形態による送信ノード１５０と受信ノード１６０の構成を説明した。次に、これらのノードの動作を説明する。送信ノード１５０と受信ノード１６０とが協働して動作することを前提として説明する。しかし、言うまでもなく、送信ノード１５０は、受信ノード１６０と同様の機能を有する受信ノード１６０以外の受信ノードと協働することができるし、受信ノード１６０は、送信ノード１５０と同様の機能を有する送信ノード１５０以外の送信ノードと協働することができる。【００７９】
受信ノード１６０において、ＲＴＴ測定要求（図１２参照）を生成する。このとき、ＲＯＨＣ制御部１６２３がＲＴＴ測定要求を生成する。ＲＴＴ測定要求に含まれるパラメータＭＵＩ（図１３参照）はＲＴＴ測定要求の生成のたびにインクリメントして付与される。受信ノード１６０が生成したＲＴＴ測定要求を送信する。具体的には、ＲＴＴ測定要求は、ＲＯＨＣ制御部１６２３から送信処理部１６２６を介して送信ノード１５０に送信される。また、ＲＯＨＣ制御部１６２３は、時刻情報管理部１６２４から得られる時刻情報に基づき、ＲＴＴ測定要求に付与したパラメータＭＵＩと、ＲＴＴ測定要求送信時の時刻とを管理する。【００８０】
送信ノード１５０において、受信ノード１６０から送信されたＲＴＴ測定要求を受信する。このとき、受信処理部１５２６はＲＴＴ測定要求を受信すると、受信したＲＴＴ測定要求（ＰＤＵ）をＲＴＴ測定処理部１５２３に転送する。このとき、ＲＴＴ測定処理部１５２３は、時刻情報管理部１５２４から得られる時刻情報に基づき、ＲＴＴ測定要求受信時の時刻を管理する。【００８１】
次に、送信ノード１５０において、ＲＴＴ測定応答（図１２参照）を生成する。具体的には、ＲＴＴ測定処理部１５２３がＲＴＴ測定応答を生成する。ＲＴＴ測定応答に含まれるパラメータＭＵＩ（図１３参照）は、受信したＲＴＴ測定要求に付与されていた値と同値とする。パラメータＤＲＭＲ（図１３参照）には、ＲＴＴ測定要求受信時の時刻に基づき、ＲＴＴ測定応答送信時刻までの経過時間（図１２参照）が格納される。実際には、時刻情報管理部１５２４から得られる時刻情報に基づき、ＲＴＴ測定応答送信予定時刻を決定し、その時刻における経過時間を格納してもよい。送信ノード１５０は、ＲＴＴ測定応答を送信する。このとき、前手順にて決定したＲＴＴ測定応答送信予定時刻を待って、ＲＴＴ測定処理部１５２３から送信処理部１５２６を介して受信ノード１６０に、ＲＴＴ送信応答を送信する。【００８２】
受信ノード１６０において、送信ノード１５０が送信したＲＴＴ測定応答を受信する。具体的には、受信処理部１６２５は、ＲＴＴ測定応答を受信すると、受信したＲＴＴ測定応答（ＰＤＵ）をＲＯＨＣ制御部１６２３に転送する。この時、ＲＯＨＣ制御部１６２３は、時刻情報管理部１６２４から得られる時刻情報に基づき、ＲＴＴ測定応答受信時の時刻を管理する。【００８３】
次に、受信ノード１６０は、ラウンドトリップタイムＲＴＴを算出する。ＲＯＨＣ制御部１６２３にて、上記の式（２）に基づきラウンドトリップタイムＲＴＴ（ＴＲＴＴ）を算出する。そして、受信ノード１６０は、ＲＯＨＣ動作モードを決定する。このとき、ＲＯＨＣ制御部１６２３は、片方向モードのリフレッシュ周期（ＴＲＥＦ）とフレーム送信周期（ＴＸ）に基づき、ＲＴＴに対する閾値（ＴＴＨＲ）を求め、図１０に示したフローチャートに従って以降の動作モードを決定する。【００８４】
最後に、受信ノード１６０は、ＲＯＨＣ動作モードを変更する。現在のＲＯＨＣ動作モードと、図１０に示したフローチャートに従って決定した動作モードとを比較して、異なっていれば、図１０に示したフローチャートに従って決定した動作モードへの変更処理を起動する。動作モードの変更処理は、例えばＲＦＣ３０９５に規定されており、詳細はここでは省略する。現在の動作モードと決定した動作モードとを比較して、異なっていなければ、現在の動作モードを維持する。【００８５】
上記の一連の手順は、例えば、ＰＤＣＰ Ｄａｔａ ＰＤＵの疎通開始時、及びその後の一定周期ごとに実施できるが、これに限定されない。【００８６】
図１７は、他の実施形態による受信ノードの構成を示す図である。図１７に示した受信ノード１７０は、受信処理部１７２５が、受信したフレーム（ＰＤＣＰ Ｄａｔａ ＰＤＵ）のシーケンス番号（ＳＮ）を監視し、シーケンス番号（ＳＮ）がｍ（≧1）だけ飛んだことを検出すると、値ｍをＳＮ飛び情報としてＲＯＨＣ制御部１７２３に通知する点で、図１６に示した受信ノード１６０と異なる。この構成により、図１４Ｂ乃至図１４Ｄを参照して説明した、複数のフレームが欠落した場合のＲＯＨＣ動作モード切り替えが可能となる。【００８７】
ＰＤＣＰ Ｄａｔａ ＰＤＵのシーケンス番号（ＳＮ）を監視し、ＲＯＨＣ動作モードの制御に反映する際の手順を説明する。シーケンス番号（ＳＮ）は、受信ノード１７０が受信するＰＤＣＰ Ｄａｔａ ＰＤＵのシーケンス番号（ＳＮ）を意味する。【００８８】
受信ノード１７０において、ＰＤＣＰ Ｄａｔａ ＰＤＵ疎通開始を契機として、受信処理部１７２５がシーケンス番号（ＳＮ）の監視を開始する。受信処理部１７２５は、受信したＰＤＵのシーケンス番号（ＳＮｎ）と１つ前に受信したＰＤＵのシーケンス番号（ＳＮｎ−１））との差分ｍ（＝ＳＮｎ−ＳＮｎ−１）が2以上の場合、これをＳＮ飛びとして検出し、ＳＮ飛び情報としてｍをＲＯＨＣ制御部１７２３に通知する。【００８９】
ＲＯＨＣ制御部１７２３は、ＳＮ飛びの最悪値を管理し、受信処理部１７２５からＳＮ飛び情報が通知されると、通知されたｍをＳＮ飛びの最悪値と比較する。比較した結果、通知されたｍの方が大きければ、ＳＮ飛びの最悪値をｍに更新する。そして、ＳＮ飛びの最悪値ｍを基に、式（３）によりＲＴＴの閾値（ＴＴＨＲ）を算出し、ＲＯＨＣ動作モードの制御へ反映する。【００９０】
図１８は、ＲＴＴ測定の実施例を示す図である。これは、図１２を参照して説明したラウンドトリップタイムＲＴＴ（ＴＲＴＴ）測定の具体例である。ここで、時刻はＮＴＰタイムスタンプ（６４ｂｉｔで構成され、上位３２ｂｉｔで１９００年１月１日０時０分０秒からの秒数を表現し、下位３２ｂｉｔで秒の小数点以下を表現する）で管理され、時刻の比較には中央の３２ｂｉｔ（図中の太字部分）を用いるものとする。式（２）の各項の値を図中に示した。ただし、ＴＩＮＳは既知の値として与えられたものとした。【００９１】
以上、特定の実施形態により説明した。言うまでもなく、各実施形態は単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。具体的な数値例を用いて説明をしたが、特に断りのない限り、それらの数値は単なる一例に過ぎず、適切な如何なる値を使用してもよい。各実施形態または実施例の区分けは本質的ではなく、２以上の実施形態または実施例を必要に応じて組み合わせて使用してもよい。【００９２】
説明の便宜上、実施形態に係る装置を機能的なブロック図を用いて説明したが、かかる装置はハードウエアで、ソフトウエアで、またはこれらの組み合わせで実現してもよい。【００９３】
また、上記実施形態や実施例には限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等を包含するものである。
【図１】
2010032318.tif 000005
【図２】
2010032318.tif 000006
【図３】
2010032318.tif 000007
【図４】
2010032318.tif 000008
【図５】
2010032318.tif 000009
【図６】
2010032318.tif 000010
【図７】
2010032318.tif 000011
【図８】
2010032318.tif 000012
【図９】
2010032318.tif 000013
【図１０】
2010032318.tif 000014
【図１１Ａ】
2010032318.tif 000015
【図１１Ｂ】
2010032318.tif 000016
【図１１Ｃ】
2010032318.tif 000017
【図１１Ｄ】
2010032318.tif 000018
【図１２】
2010032318.tif 000019
【図１３】
2010032318.tif 000020
【図１４Ａ】
2010032318.tif 000021
【図１４Ｂ】
2010032318.tif 000022
【図１４Ｃ】
2010032318.tif 000023
【図１４Ｄ】
2010032318.tif 000024
【図１５】
2010032318.tif 000025
【図１６】
2010032318.tif 000026
【図１７】
2010032318.tif 000027
【図１８】
2010032318.tif 000028
【国際調査報告】
2010032318.tif 000029
2010032318.tif 000030
2010032318.tif 000031
2010032318.tif 000032
2010032318.tif 000033
2010032318.tif 000034
2010032318.tif 000035
2010032318.tif 000036