(57)【要約】  受信ノード（１００）は、音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信ノードである。受信ノード（１００）は、受信処理部（１３２）と、通話状態判定部（１３４）と、ＲＯＨＣ制御部（１３５）と、を備えている。受信処理部（１３２）は、ヘッダ圧縮を行う送信装置から送信される音声データを受信する。通話状態判定部（１３４）は、受信処理部（１３２）によって受信される音声データの通話状態を判定する。ＲＯＨＣ制御部（１３５）は、通話状態判定部（１３４）の判定結果に応じて動作モードを切り替える。
2010106663.tif 000002
【特許請求の範囲】
【請求項１】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信装置において、
前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信手段と、
前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする受信装置。
【請求項２】
前記判定手段は、前記受信手段によって受信された音声データを格納する受信バッファの滞留データ量に基づいて前記通話状態を判定することを特徴とする請求項１に記載の受信装置。
【請求項３】
前記受信手段は、前記送信装置の送信バッファに格納されている前記音声データの量を示すデータ量情報を前記送信装置から受信し、
前記判定手段は、前記受信手段によって受信されたデータ量情報に基づいて前記通話状態を判定することを特徴とする請求項１に記載の受信装置。
【請求項４】
前記受信手段は、前記送信装置によって判定された前記通話状態を示す通話状態情報を前記送信装置から受信し、
前記制御手段は、前記受信手段によって受信された通話状態情報に応じて前記動作モードを切り替えることを特徴とする請求項１に記載の受信装置。
【請求項５】
前記判定手段は、前記受信バッファの滞留データ量が閾値より大きい場合は前記通話状態を有音と判定し、前記音声データの量が前記閾値以下の場合は前記通話状態を無音と判定することを特徴とする請求項２に記載の受信装置。
【請求項６】
前記制御手段は、前記判定手段によって有音と判定された場合は、前記複数の動作モードのうちの前記ヘッダ圧縮の頻度が低い動作モードへ切り替え、前記判定手段によって無音と判定された場合は、前記複数の動作モードのうちの前記ヘッダ圧縮の頻度が高い動作モードへ切り替えることを特徴とする請求項５に記載の受信装置。
【請求項７】
前記判定手段は、前記受信バッファの滞留データ量が所定期間以上において前記閾値より大きい場合に前記通話状態を有音と判定することを特徴とする請求項５に記載の受信装置。
【請求項８】
前記判定手段は、前記受信バッファの滞留データ量が所定期間以上において前記閾値以下の場合に前記通話状態を無音と判定することを特徴とする請求項５に記載の受信装置。
【請求項９】
前記判定手段は、前記判定結果をメモリに書き込む演算手段であり、
前記制御手段は、前記判定手段によってメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じて前記動作モードを切り替える演算手段であることを特徴とする請求項１に記載の受信装置。
【請求項１０】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信装置において、
音声データのヘッダ圧縮を行う圧縮手段と、
前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
前記送信手段によって送信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする送信装置。
【請求項１１】
前記圧縮手段は、ヘッダ圧縮を行った音声データをメモリに書き込む演算手段であり、
前記送信手段は、前記圧縮手段によってメモリに書き込まれた音声データを読み出し、読み出した音声データを送信し、
前記判定手段は、前記判定結果をメモリに書き込む演算手段であり、
前記制御手段は、前記判定手段によってメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じて前記動作モードを切り替える演算手段であることを特徴とする請求項１０に記載の送信装置。
【請求項１２】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信方法において、
前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信工程と、
前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする受信方法。
【請求項１３】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信方法において、
音声データのヘッダ圧縮を行う圧縮工程と、
前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
前記送信工程によって送信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする送信方法。
【請求項１４】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおいて、
音声データのヘッダ圧縮を行う圧縮手段と、
前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
前記送信手段によって送信された音声データを受信する受信手段と、
前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする通信システム。
【請求項１５】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムの通信方法において、
音声データのヘッダ圧縮を行う圧縮工程と、
前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
前記送信工程によって送信された音声データを受信する受信工程と、
前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、音声通信を行う受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法に関する。
【背景技術】
【０００２】
ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムは、３Ｇセルラーシステムからの飛躍的な性能向上を目指し、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で国際標準化が進められている。ＬＴＥシステムは、モバイル通信で高速伝送を実現し、高速映像配信など高度なサービス環境を提供するとともに、効率的な周波数利用が図られるシステムとして期待されている。【０００３】
また、既存（３Ｇまで）システムにおいては、音声とデータ通信とはそれぞれ別の通信インフラで提供されていたが、ＬＴＥシステムにおいては音声とデータ通信とをＩＰベースに統合する「ａｌｌ  ＩＰ」への移行が意図されている。これにより、従来の回線交換型インフラを含むシステムから、ＬＴＥシステムによって、完全なＩＰ化がなされたシステムが実現されると見込まれている。【０００４】
ＬＴＥシステムにおけるリアルタイムデータの伝送は、一般的な有線ＩＰネットワークにおけるＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）と同様にＲＴＰ／ＵＤＰ／ＩＰの各プロトコルによって実現される。このため、ＬＴＥシステムにおけるリアルタイムデータは、各プロトコルのヘッダが付与されることによりオーバヘッドが大きくなる。【０００５】
帯域幅の限られる無線区間を含むネットワークにおいては、無線区間の帯域利用効率を向上させるために、オーバヘッドとなる各プロトコルのヘッダを圧縮する機能が求められる。このヘッダ圧縮機能は、ＬＴＥシステムにおいて実現される見込みである。【０００６】
具体的には、ｅＮＢ〜ＵＥ間で終端されるＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）の機能に含まれるＲＯＨＣ（ＲＯｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｎｇ）と呼ばれる技術がヘッダ圧縮機能として実現される見込みである。ＲＯＨＣには、ヘッダ圧縮の効率が異なる複数の動作モードが存在する（たとえば、下記特許文献１参照。）。【０００７】
【特許文献１】特開２００２−１３５３６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述した従来技術では、ヘッダ圧縮を頻繁に行うと、フレーム欠落などの場合に音声データを復元できずにデータロスとなり、音声データの音質が劣化するという問題がある。一方、ヘッダ圧縮の頻度を低くすると、データのオーバヘッドが大きくなるため、伝送経路の帯域利用効率が低下するという問題がある。【０００９】
開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法は、上述した問題点を解消するものであり、音声データの音質および帯域利用効率の向上を図ることを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するため、この受信装置は、音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信装置において、前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信手段と、前記受信手段によって受信される音声データの通話状態を判定する判定手段と、前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、を備える。【００１１】
上記構成によれば、通話状態を判定し、判定した通話状態に応じてヘッダ圧縮の頻度が異なる複数の動作モードを切り替えることができる。
【発明の効果】
【００１２】
開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法によれば、音声データの音質および帯域利用効率の向上を図ることができる。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施の形態１にかかる受信ノードの構成例を示すブロック図である。
【図２】図２は、実施の形態１にかかる送信ノードの構成例を示すブロック図である。
【図３】図３は、実施の形態１にかかる通信システムの構成例を示す図である。
【図４】図４は、図３に示した通信システムにおけるプロトコルスタックを示す図である。
【図５】図５は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その１）である。
【図６】図６は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その２）である。
【図７】図７は、ＲＯＨＣのＯ−ｍｏｄｅの動作を示す図である。
【図８】図８は、ＲＯＨＣのＲ−ｍｏｄｅの動作を示す図である。
【図９】図９は、通話状態の変化の一例を示す図である。
【図１０】図１０は、ＭＡＣ＿ＰＤＵの一例を示す図である。
【図１１】図１１は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔを示す図である。
【図１２】図１２は、図１１に示したＳｈｏｒｔ＿ＢＳＲを示す図である。
【図１３】図１３は、図１１に示したＬｏｎｇ＿ＢＳＲを示す図である。
【図１４】図１４は、バッファサイズのインデクスを示す図である。
【図１５】図１５は、データＰＤＵのフォーマットの一例を示す図である。
【図１６】図１６は、コントロールＰＤＵのフォーマットの一例を示す図である。
【図１７】図１７は、図１に示した受信ノードの動作の一例を示すフローチャートである。
【図１８】図１８は、図１７に示したステップＳ１７０１の具体例を示すフローチャートである。
【図１９】図１９は、ＲＯＨＣの動作モード切替の一例を示す図である。
【図２０】図２０は、実施の形態２にかかる受信ノードの構成例を示すブロック図である。
【図２１】図２１は、実施の形態２にかかる送信ノードの動作の一例を示すフローチャートである。
【図２２】図２２は、実施の形態３にかかる受信ノードの構成例を示すブロック図である。
【図２３】図２３は、実施の形態３にかかる送信ノードの構成例を示すブロック図である。
【図２４】図２４は、ＰＤＣＰフレームのフォーマットの一例を示す図である。
【図２５】図２５は、図２３に示した送信ノードの動作の一例を示すフローチャートである。
【図２６】図２６は、図２５に示したステップＳ２５０１の具体例を示すフローチャートである。
【図２７】図２７は、実施の形態４にかかる受信ノードの構成例を示すブロック図である。
【図２８】図２８は、実施の形態４にかかる送信ノードの構成例を示すブロック図である。
【図２９】図２９は、ＰＤＣＰフレームのフォーマットの一例を示す図である。
【図３０】図３０は、実施の形態５にかかる受信ノードの動作の一例を示すフローチャートである。
【図３１】図３１は、図３０に示した動作による通話状態判定の具体例を示す図である。
【図３２】図３２は、実施の形態６にかかる受信ノードの構成例を示すブロック図である。
【図３３】図３３は、実施の形態６にかかる送信ノードの構成例を示すブロック図である。
【図３４】図３４は、Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへの切替の具体例を示す図である。
【図３５】図３５は、Ｕ−ｍｏｄｅからＲ−ｍｏｄｅへの切替の具体例を示す図である。
【図３６】図３６は、Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへの切替の具体例を示す図である。
【符号の説明】
【００１４】
３００  通信システム
３１１，３１２  ＭＭＥ／Ｓ−ＧＷ
３２１〜３２３  ｅＮＢ
３３１，３３２  ＵＥ
４００  プロトコルスタック
５１１  非圧縮フレーム
５１２  圧縮フレーム
８０１，３５２２  Ａｃｋ
９１１，１９１１  ＡＭＲデータ
９１２，１９１２  ＳＩＤデータ
１０００  ＭＡＣ＿ＰＤＵ
１５００，１６００，２４００，２９００  ＰＤＣＰフレーム
３４１０  Ｃ＿ＭＯＤＥ
３４２０  Ｃ＿ＴＲＡＮＳ
３４３０  Ｄ＿ＭＯＤＥ
３４４０  Ｄ＿ＴＲＡＮＳ
３４５０，３５２１，３６２１  切替指示信号
Ｔ１〜Ｔ２３  監視周期
【発明を実施するための最良の形態】
【００１５】
以下に添付図面を参照して、この受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法の好適な実施の形態を詳細に説明する。【００１６】
（実施の形態１）
（受信ノードの構成例）
図１は、実施の形態１にかかる受信ノードの構成例を示すブロック図である。図１に示す受信ノード１００は、実施の形態にかかる受信装置をＬＴＥシステムにおけるＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ユーザ端末）に適用した例である。受信ノード１００は、ＭＡＣレイヤ終端部１１０と、ＲＬＣレイヤ終端部１２０と、ＰＤＣＰ終端部１３０と、ＲＴＰ／ＵＤＰ／ＩＰ終端部１４０と、ＡＭＲ終端部１５０と、を備えている。【００１７】
ＭＡＣレイヤ終端部１１０は、送信ノード（図２参照）との間の通信におけるＭＡＣレイヤの機能を終端する。たとえば、ＭＡＣレイヤ終端部１１０は、送信ノードから送信された音声データまたは制御データに対する誤り訂正や再送制御を行う。ＲＬＣレイヤ終端部１２０は、送信ノードとの間の通信におけるＲＬＣレイヤの機能を終端する。【００１８】
ＰＤＣＰ終端部１３０は、送信ノードとの間の通信におけるＰＤＣＰレイヤの機能を終端する。また、ＰＤＣＰ終端部１３０は、送信ノードとの間の通信におけるＲＯＨＣレイヤの機能を終端する。具体的には、ＰＤＣＰ終端部１３０は、受信バッファ１３１と、受信処理部１３２と、伸張部１３３と、通話状態判定部１３４と、ＲＯＨＣ制御部１３５と、送信処理部１３６と、を備えている。【００１９】
受信バッファ１３１は、ＭＡＣレイヤ終端部１１０およびＲＬＣレイヤ終端部１２０を介して受信したＰＤＣＰ＿ＰＤＵを一時格納する。受信処理部１３２（受信手段）は、受信バッファ１３１に格納されたＰＤＣＰ＿ＰＤＵを読み出してヘッダ処理を行い、ヘッダ処理を行ったデータを伸張部１３３へ出力する。受信処理部１３２によって読み出されたＰＤＣＰ＿ＰＤＵは受信バッファ１３１から消去される。【００２０】
伸張部１３３は、受信処理部１３２から出力されたデータのＲＯＨＣのヘッダ伸張を行う。そして、伸張部１３３は、ＲＯＨＣのヘッダ伸張を行ったデータをＲＴＰ／ＵＤＰ／ＩＰ終端部１４０へ出力する。また、伸張部１３３は、ＲＯＨＣ制御部１３５によって切り替えられる動作モードに応じてＲＯＨＣのヘッダ伸張を行う。【００２１】
通話状態判定部１３４（判定手段）は、受信ノード１００が送信ノードから受信した音声データの通話状態を判定し、判定結果をＲＯＨＣ制御部１３５へ通知する。通話状態判定部１３４が判定する通話状態は、たとえば、音声データが示す音声が「有音」であるか「無音」であるかに関する状態である。通話状態判定部１３４は、たとえば、受信バッファ１３１の滞留データ量に基づいて通話状態を判定する。【００２２】
具体的には、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、受信バッファ１３１の滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。音声データの量と比較する閾値は、たとえば、通話状態が「無音」である場合に送信ノードから送信されるＳＩＤデータ（Ｓｉｌｅｎｃｅ  Ｉｎｓｅｒｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ）のサイズに相当する値である。【００２３】
ＲＯＨＣ制御部１３５（制御手段）は、通話状態判定部１３４から出力された判定結果に応じて、受信ノード１００および送信ノードにおけるＲＯＨＣの動作モードを切り替える。たとえば、ＲＯＨＣ制御部１３５は、受信ノード１００および送信ノードにおけるＲＯＨＣの動作モードを、Ｕ−ｍｏｄｅ、Ｏ−ｍｏｄｅおよびＲ−ｍｏｄｅのいずれかに切り替える。これらのＲＯＨＣの各動作については後述する（図５〜図８参照）。【００２４】
ＲＯＨＣ制御部１３５は、ＲＯＨＣの動作モードを切り替えるために、切り替える動作モードを示す切替指示信号を生成する。そして、ＲＯＨＣ制御部１３５は、生成した切替指示信号を送信処理部１３６へ出力する。これにより、切替指示信号が送信ノードへ送信され、ＲＯＨＣの動作モードが切り替わる。【００２５】
送信処理部１３６は、ＰＤＣＰ＿ＰＤＵへのヘッダ付与を行う。たとえば、送信処理部１３６は、ＲＯＨＣ制御部１３５から出力された切替指示信号にヘッダを付与する。そして、送信処理部１３６は、ヘッダを付与した切替指示信号を、ＭＡＣレイヤ終端部１１０およびＲＬＣレイヤ終端部１２０を介して送信ノードへ送信する。【００２６】
ＲＴＰ／ＵＤＰ／ＩＰ終端部１４０は、送信ノードとの間の通信におけるＲＴＰ／ＵＤＰ／ＩＰレイヤの機能を終端する。ＡＭＲ終端部１５０は、送信ノードとの間の通信におけるＡＭＲレイヤの機能を終端する。たとえば、ＡＭＲ終端部１５０は、送信ノードから受信した音声データの復号を行う。【００２７】
図１においては、送信ノード（ｅＮＢ）から送信された音声データを受信ノード１００（ＵＥ）が受信するダウンリンクに関する機能について説明した。ただし、受信ノード１００は、受信ノード１００（ＵＥ）が送信ノード（ｅＮＢ）へ音声データを送信するアップリンクに関する機能を備えていてもよい。【００２８】
図１に示した通話状態判定部１３４は、通話状態の判定結果を受信ノード１００のメモリ（不図示）に書き込む。通話状態判定部１３４は、たとえばＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などの演算手段である。ＲＯＨＣ制御部１３５は、通話状態判定部１３４によって受信ノード１００のメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じてＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部１３５は、たとえばＣＰＵなどの演算手段である。【００２９】
（送信ノードの構成例）
図２は、実施の形態１にかかる送信ノードの構成例を示すブロック図である。図２に示す送信ノード２００は、実施の形態にかかる送信装置をＬＴＥシステムにおけるｅＮＢに適用した例である。送信ノード２００は、ＰＤＣＰ終端部２１０と、ＲＬＣレイヤ終端部２２０と、ＭＡＣレイヤ終端部２３０と、を備えている。【００３０】
ＰＤＣＰ終端部２１０は、受信ノード１００との間の通信におけるＰＤＣＰレイヤの機能を終端する。また、ＰＤＣＰ終端部２１０は、受信ノード１００との間の通信におけるＲＯＨＣレイヤの機能を終端する。具体的には、ＰＤＣＰ終端部２１０は、送信バッファ２１１と、圧縮部２１２と、送信処理部２１３と、受信処理部２１４と、を備えている。【００３１】
送信バッファ２１１は、送信ノード２００の上位のシステム（たとえばＳ−ＧＷ＿ＩＦ）から送信されたＰＤＣＰ＿ＳＤＵを一時格納する。圧縮部２１２は、送信バッファ２１１に格納されたＰＤＣＰ＿ＳＤＵを読み出してヘッダ圧縮を行い、ヘッダ圧縮を行ったＰＤＣＰ＿ＳＤＵを送信処理部２１３へ出力する。【００３２】
圧縮部２１２によって読み出されたＰＤＣＰ＿ＳＤＵは送信バッファ２１１から消去される。また、圧縮部２１２は、送信ノード２００において設定されているＲＯＨＣの動作モードによってヘッダ圧縮を行う。具体的には、圧縮部２１２は、受信ノード１００から受信したＲＯＨＣの動作モードの切替指示信号を受信処理部２１４から取得する。そして、圧縮部２１２は、取得した切替指示信号が示す動作モードによってヘッダ圧縮を行う。【００３３】
送信処理部２１３は、圧縮部２１２から出力されたＰＤＣＰ＿ＳＤＵにＰＤＣＰヘッダを付与しＰＤＣＰ＿ＰＤＵとして、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。受信処理部２１４は、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００から受信したＰＤＣＰ＿ＰＤＵのヘッダ処理を行う。【００３４】
たとえば、受信処理部２１４は、受信ノード１００から受信した切替指示信号のヘッダ処理を行って圧縮部２１２へ出力する。ＲＬＣレイヤ終端部２２０は、受信ノード１００との間の通信におけるＲＬＣレイヤの機能を終端する。ＭＡＣレイヤ終端部２３０は、受信ノード１００との間の通信におけるＭＡＣレイヤの機能を終端する。【００３５】
図２においては、送信ノード２００（ｅＮＢ）から送信された音声データを受信ノード１００（ＵＥ）が受信するダウンリンクに関する機能について説明した。ただし、送信ノード２００は、受信ノード１００（ＵＥ）が送信ノード２００（ｅＮＢ）へ音声データを送信するアップリンクに関する機能を備えていてもよい。【００３６】
（通信システムの構成例）
図３は、実施の形態１にかかる通信システムの構成例を示す図である。図３に示す通信システム３００は、実施の形態にかかる通信システムをＬＴＥシステムに適用した例である。通信システム３００は、ＭＭＥ／Ｓ−ＧＷ３１１，３１２と、ｅＮＢ３２１〜３２３と、ＵＥ３３１，３３２と、を含んでいる。【００３７】
ＭＭＥ／Ｓ−ＧＷ３１１，３１２のそれぞれは、ＬＴＥシステムにおけるＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）およびＳ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）の機能を備えている。ＭＭＥ／Ｓ−ＧＷ３１１，３１２のそれぞれは、ｅＮＢ３２１〜３２３のそれぞれとＳ１インターフェースによって接続されている。【００３８】
ｅＮＢ３２１〜３２３のそれぞれは、ＬＴＥシステムのＥ−ＵＴＲＡＮ＿ＮｏｄｅＢである。ｅＮＢ３２１〜３２３は、Ｘ２インターフェースによって互いに接続されている。また、ｅＮＢ３２１〜３２３のそれぞれは、無線通信によってＵＥ３３１，３３２との間で音声通信を行う。ＵＥ３３１，３３２のそれぞれは、携帯電話などの移動端末である。【００３９】
図１に示した受信ノード１００は、たとえばＵＥ３３１，３３２の少なくともいずれかに適用することができる。また、図２に示した送信ノード２００は、たとえばｅＮＢ３２１〜３２３の少なくともいずれかに適用することができる。【００４０】
また、図１に示した受信ノード１００を、ｅＮＢ３２１〜３２３の少なくともいずれかに適用し、図２に示した送信ノード２００をＵＥ３３１，３３２の少なくともいずれかに適用してもよい。この場合は、図１に示した受信ノード１００のＰＤＣＰ終端部１３０を上位のシステム（たとえばＳ−ＧＷ＿ＩＦ）に接続し、図２に示した送信ノード２００にＲＴＰ／ＵＤＰ／ＩＰ終端部１４０およびＡＭＲ終端部１５０（図１参照）を備える。【００４１】
図４は、図３に示した通信システムにおけるプロトコルスタックを示す図である。図３に示した通信システム３００において、たとえば図４に示すプロトコルスタック４００を適用する。図４に示すプロトコルスタック４００は、音声通信などのリアルタイムデータのＩＰ化に関してＬＴＥにおいて検討されているプロトコルスタックである。【００４２】
図４において、ＵＥ４１１は、図３に示したＵＥ３３１，３３２である。ｅＮＢ４１２は、図３に示したｅＮＢ３２１〜３２３である。Ｓ−ＧＷ４１３は、図３に示したＭＭＥ／Ｓ−ＧＷ３１１，３１２である。ＰＤＮ−ＧＷ４１４およびＩＰ網４１５は、図３に示したＭＭＥ／Ｓ−ＧＷ３１１，３１２に接続されている。【００４３】
プロトコルスタック４００において、「ＰＨＹ」および「Ｅｔｈｅｒ」は、それぞれ物理レイヤ（Ｐｈｙｓｉｃａｌ）およびイーサネット（登録商標）を示している。「ＰＨＹ」および「Ｅｔｈｅｒ」は、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：構内通信網）およびＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：広域通信網）の基本インターフェースとして規定されているものを使用する。【００４４】
「ＩＰ」（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）は、インターネットで使用するレイヤ３である。「ＩＰ」は、データのルーティング機能を提供する。「ＵＤＰ」（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）は、コネクションレス型の転送プロトコルである。「ＲＴＰ」（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）は、リアルタイムメディア転送のためのフレームワークを提供する。「ＲＴＰ」は、プロファイルやペイロードフォーマットをアプリケーションに合わせて使用する。【００４５】
「ＧＴＰ−Ｕ」（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）は、ＬＴＥ／ＳＡＥ網内においてユーザデータをトンネリングさせる。「ＭＡＣ」（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）は、スケジューリング、プライオリティ制御、ＨＡＲＱ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）によるエラー訂正およびトランスフォーマットの選択などを行う。【００４６】
「ＲＬＣ」（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）は、ＡＲＱ（Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）によるエラー訂正などを行う。「ＰＤＣＰ」（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）は、ヘッダ圧縮（ＲＯＨＣ）などを行う。【００４７】
ダウンリンク（ｅＮＢ→ＵＥ）を例にとると、ＩＰ網４１５側からＲＴＰ／ＵＤＰ／ＩＰを介して送信されてくる音声データ（ＡＭＲ）は、ｅＮＢ４１２において終端されるＰＤＣＰの機能であるＲＯＨＣによって、ＲＴＰ／ＵＤＰ／ＩＰのヘッダが圧縮される。ヘッダが圧縮されＵＥ４１１まで伝送された音声データは、ＵＥ４１１においてＰＤＣＰが終端される際にＲＯＨＣによってヘッダが伸張され、元の音声データに復元される。【００４８】
（ＲＯＨＣの各動作モード）
図５は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その１）である。図５において、横軸は時間を示している。ＲＴＰ／ＵＤＰ／ＩＰのレイヤにおいて、送信ノード２００が２０［ｍｓｅｃ］の周期のフレームによって音声データを受信ノード１００へ送信する場合について説明する。非圧縮フレーム５１１は、送信ノード２００がヘッダ圧縮を行わずに送信した（コンテキストを含む）音声データである。圧縮フレーム５１２は、送信ノード２００がヘッダ圧縮を行って送信した（コンテキストを含まない）音声データである。【００４９】
非圧縮フレーム５１１および圧縮フレーム５１２の横軸と直交する方向（図の縦方向）の長さは、各フレームのサイズを示している。圧縮フレーム５１２は、ヘッダ圧縮が行われているため、ヘッダ圧縮が行われていない非圧縮フレーム５１１よりもサイズが小さくなっている。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ−ｍｏｄｅ（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｍｏｄｅ）に設定されている。【００５０】
具体的には、送信ノード２００は、２０［ｍｓｅｃ］単位で各フレームを送信する。送信ノード２００は、送信する各フレームのうちの、１８０［ｍｓｅｃ］単位で送信するフレームは非圧縮フレーム５１１とし、それ以外のフレームは圧縮フレーム５１２とする。【００５１】
受信ノード１００は、圧縮フレーム５１２のヘッダを、以前に受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて伸張（復元）しながら各フレームを受信する。たとえば、受信ノード１００は、時期ｔ５２１において受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて、時期ｔ５２１の直後の期間Ｔ５２２において受信した各圧縮フレーム５１２のヘッダを伸張する。【００５２】
このように、ＲＯＨＣのＵ−ｍｏｄｅにおいては、送信ノードが一定周期でコンテキストを送信することにより通信の品質保証を行う。この場合は、受信ノード１００からコンテキスト（非圧縮フレーム５１１）を要求するフィードバックを行わない。このため、受信ノード１００から送信ノード２００へのリンクの帯域を圧迫しない。【００５３】
図６は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その２）である。図６において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ＲＯＨＣの動作モードがＵ−ｍｏｄｅである場合（図５参照）で、時期ｔ６１１において非圧縮フレーム５１１が正常に受信ノード１００に受信されなかったとする。【００５４】
この場合は、時期ｔ６１１の直後の期間Ｔ６１２において受信する各圧縮フレーム５１２については、ＰＤＣＰのレイヤで破棄され、ヘッダの伸張を正常に行うことができない。このため、期間Ｔ６１２において受信する各圧縮フレーム５１２はデータロスとなり、音声品質が劣化する。この場合は、たとえば、一時的に音声が不通になる。【００５５】
各圧縮フレーム５１２がデータロスとなる期間は、つぎに受信ノード１００が非圧縮フレーム５１１を受信してコンテキストが回復されるまで継続する。このため、各圧縮フレーム５１２がデータロスとなる期間は、送信ノード２００がコンテキスト（非圧縮フレーム５１１）を送信する周期（ここでは１８０［ｍｓｅｃ］）に依存する。【００５６】
図７は、ＲＯＨＣのＯ−ｍｏｄｅの動作を示す図である。図７において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＯ−ｍｏｄｅ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ  Ｏｐｔｉｍｉｓｔｉｃ  Ｍｏｄｅ）に設定されている。【００５７】
送信ノード２００は、２０［ｍｓｅｃ］単位で送信する各フレームのうちの、ヘッダの内容が前のフレームから変更になったフレームは非圧縮フレーム５１１とし、それ以外のフレームは圧縮フレーム５１２として送信する。受信ノード１００は、圧縮フレーム５１２のヘッダを、以前に受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて伸張（復元）しながら各フレームを受信する。【００５８】
また、受信ノード１００は、非圧縮フレーム５１１を正常に受信することができなかった場合に、送信ノード２００に対してＮａｃｋを送信する。たとえば、時期ｔ７１１において、受信ノード１００が非圧縮フレーム５１１を正常に受信できず、時期ｔ７１１の直後の時期ｔ７１２において送信ノード２００へＮａｃｋ７０１を送信したとする。【００５９】
送信ノード２００は、受信ノード１００からＮａｃｋ７０１を受信すると、非圧縮フレーム５１１を再送する。受信ノード１００は、時期ｔ７１２の後の時期ｔ７１３において、送信ノード２００から再送された非圧縮フレーム５１１を受信したとする。【００６０】
非圧縮フレーム５１１が受信できなかった時期ｔ７１１から非圧縮フレーム５１１を受信した時期ｔ７１３の間の期間Ｔ７２０において受信した各圧縮フレーム５１２については、ＰＤＣＰのレイヤで破棄され、ヘッダの伸張を正常に行うことができない。このため、期間Ｔ７２０において受信する各圧縮フレーム５１２はデータロスとなる。【００６１】
各圧縮フレーム５１２がデータロスとなる期間は、つぎに受信ノード１００が非圧縮フレーム５１１を受信してコンテキストが回復されるまで継続する。このため、各圧縮フレーム５１２がデータロスとなる期間は、受信ノード１００が送信ノード２００へＮａｃｋを送信し、送信ノード２００が受信ノード１００へ非圧縮フレーム５１１を再送するまでの期間に依存する。【００６２】
このように、ＲＯＨＣのＯ−ｍｏｄｅにおいては、受信ノード１００からのフィードバックを行うことにより通信の品質保証を行う。コンテキスト（非圧縮フレーム５１１）は、受信ノード１００がフレームを正常に受信できなかった場合に送信されるため、圧縮フレーム５１２の送信頻度が高く、ヘッダ圧縮効率が優れている。【００６３】
図８は、ＲＯＨＣのＲ−ｍｏｄｅの動作を示す図である。図８において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＲ−ｍｏｄｅ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ  Ｒｅｌｉａｂｌｅ  Ｍｏｄｅ）に設定されている。【００６４】
送信ノード２００は、２０［ｍｓｅｃ］単位で非圧縮フレーム５１１を送信する。そして、送信ノード２００は、非圧縮フレーム５１１に対するＡｃｋを受信ノード１００から受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。【００６５】
受信ノード１００は、非圧縮フレーム５１１を正常に受信した場合に、送信ノード２００に対してＡｃｋを送信する。たとえば、時期ｔ８１１において、受信ノード１００が非圧縮フレーム５１１を正常に受信して送信ノード２００へＡｃｋ８０１を送信したとする。送信ノード２００は、受信ノード１００からＡｃｋ８０１を受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。【００６６】
また、時期ｔ８１１の後の時期ｔ８１２において、受信ノード１００が非圧縮フレーム５１１を正常に受信できなかったとする。そして、時期ｔ８１２の直後の時期ｔ８１３において、受信ノード１００が非圧縮フレーム５１１を正常に受信して送信ノード２００へＡｃｋ８０２を送信したとする。送信ノード２００は、受信ノード１００からＡｃｋ８０２を受信するまでは非圧縮フレーム５１１を送信し、受信ノード１００からＡｃｋ８０２を受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。【００６７】
このように、ＲＯＨＣのＲ−ｍｏｄｅにおいては、送信ノード２００は、コンテキストが受信ノード１００へ正常に到達したことを示すＡｃｋを受信するとヘッダ圧縮を開始する。このため、ＲＯＨＣのＲ−ｍｏｄｅは、Ｕ−ｍｏｄｅやＯ−ｍｏｄｅに比べてヘッダ圧縮効率は劣る一方、コンテキスト維持の信頼性が優れている。また、コンテキスト喪失時の以降のヘッダ伸張不可に伴うデータロス時間は発生しない。【００６８】
図５〜図８に示したＲＯＨＣの各動作モード間の切替は、受信ノード１００から送信ノード２００へ切替指示信号を送信することによって行う。ＲＯＨＣの各動作モード間の切替の具体例については後述する（図３４〜図３６参照）。【００６９】
（通話状態の変化）
図９は、通話状態の変化の一例を示す図である。図９において、横軸は時間を示している。符号９１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。符号９２０は、受信ノード１００から送信ノード２００へ送信される音声データを示している。人物Ａは、送信ノード２００側のユーザを示している。人物Ｂは、受信ノード１００側のユーザを示している。【００７０】
ＡＭＲデータ９１１は、音声を伝送するときに送信される。ＳＩＤデータ９１２は、伝送する音声がない場合に送信される。ＡＭＲデータ９１１およびＳＩＤデータ９１２において、横軸に直交する方向（図の縦方向）の長さはデータのサイズを示している。図９に示すように、ＳＩＤデータ９１２はＡＭＲデータ９１１よりサイズが小さい。【００７１】
区間９３１〜９３４は、時間的に連続する時間区間である。送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）の通話状態は、区間９３１および区間９３３においては「有音」となっている。また、送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）の通話状態は、区間９３２および区間９３４においては「無音」となっている。【００７２】
一方、受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）の通話状態は、区間９３１および区間９３３においては「無音」となっている。また、受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）の通話状態は、区間９３２および区間９３４においては「有音」となっている。【００７３】
口論のようなケースを例外とすれば、一般的な通話においては人物Ａと人物Ｂとが交互に発言する。このため、送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）および受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）において、通話状態が「有音」の区間と「無音」の区間とが存在する。【００７４】
通話状態が「有音」の区間においては、ヘッダ伸張不可などによりＰＤＣＰでＡＭＲデータ９１１が破棄されると音声品質の劣化に繋がる。一方で、通話状態が「無音」の区間においては、ＳＩＤデータ９１２はユーザの音声を示すデータではないため、ＰＤＣＰにおいてＳＩＤデータ９１２が破棄されても通話に影響しない。【００７５】
このことを利用して、受信ノード１００および送信ノード２００は、音声データの通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替える。これにより、通話状態が「有音」のときは音質の向上を図り、通話状態が「無音」のときはヘッダ圧縮の効率化を図ることができる。【００７６】
（各データのフレームフォーマット）
図１０は、ＭＡＣ＿ＰＤＵの一例を示す図である。受信ノード１００と送信ノード２００との間で送受信される音声データのＭＡＣレイヤのフレームフォーマットは、たとえば図１０に示すＭＡＣ＿ＰＤＵ１０００のようにする。ＭＡＣ＿ＰＤＵ１０００は、ＬＴＥシステムにおいてＰＤＣＰの下位レイヤに位置するＭＡＣフレームフォーマットである。【００７７】
ＭＡＣ＿ＰＤＵ１０００には、ＭＡＣ＿Ｈｅａｄｅｒ１０１０と、ＭＡＣ＿Ｐａｙｌｏａｄ１０２０と、が含まれている。ＭＡＣ＿Ｐａｙｌｏａｄ１０２０には、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１（図１１参照）と、ＭＡＣ＿ＳＤＵ１０２２と、Ｐａｄｄｉｎｇ１０２３と、が含まれている。【００７８】
図１１は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔを示す図である。図１１に示すテーブル１１００は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の各種別を示している。【００７９】
送信ノード２００から受信ノード１００へ送信される音声データ（ｅＮＢ→ＵＥ）の場合は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の種別には、「ＵＥ  Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ  Ｉｄｅｎｔｉｔｙ」と、「Ｔｉｍｉｎｇ  Ａｄｖａｎｃｅ」と、「ＤＲＸ  Ｃｏｍｍａｎｄ」と、が含まれている。【００８０】
また、受信ノード１００から送信ノード２００へ送信される音声データ（ＵＥ→ｅＮＢ）の場合は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の種別には、「Ｐｏｗｅｒ  Ｈｅａｄｒｏｏｍ  Ｒｅｐｏｒｔ」と、「Ｃ−ＲＮＴＩ」と、「Ｓｈｏｒｔ＿ＢＳＲ」と、「Ｌｏｎｇ＿ＢＳＲ」と、が含まれている。【００８１】
「Ｓｈｏｒｔ＿ＢＳＲ」および「Ｌｏｎｇ＿ＢＳＲ」は、バッファに滞留したデータ量を示している。したがって、送信ノード２００は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１に含まれる「Ｓｈｏｒｔ＿ＢＳＲ」または「Ｌｏｎｇ＿ＢＳＲ」によって送信バッファ２１１の滞留データ量を受信ノード１００へ通知することができる。【００８２】
図１２は、図１１に示したＳｈｏｒｔ＿ＢＳＲを示す図である。図１１に示した「Ｓｈｏｒｔ＿ＢＳＲ」のフレームフォーマットは、たとえばＳｈｏｒｔ＿ＢＳＲ１２００のようにする。Ｓｈｏｒｔ＿ＢＳＲ１２００には、ＬＣＧ＿ＩＤ１２１０（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ  Ｇｒｏｕｐ）と、バッファサイズ１２２０と、が含まれている。【００８３】
ＬＣＧ＿ＩＤ１２１０は、各論理チャネルグループ（たとえば論理チャネルグループ＃１〜＃４）を示すＩＤである。バッファサイズ１２２０は、ＬＣＧ＿ＩＤ１２１０が示す各論理チャネルグループの全滞留データ量を示している。バッファサイズ１２２０の具体例については後述する（図１４参照）。【００８４】
図１３は、図１１に示したＬｏｎｇ＿ＢＳＲを示す図である。図１１に示した「Ｌｏｎｇ＿ＢＳＲ」のフレームフォーマットは、たとえばＬｏｎｇ＿ＢＳＲ１３００のようにする。Ｌｏｎｇ＿ＢＳＲ１３００には、各バッファサイズ＃１〜＃４が含まれている。各バッファサイズ＃１〜＃４は、各ＵＥに対する全滞留データ量を示している。各バッファサイズ＃１〜＃４の具体例については後述する（図１４参照）。【００８５】
図１４は、バッファサイズのインデクスを示す図である。図１２に示したバッファサイズ１２２０または図１３に示した各バッファサイズ＃１〜＃４は、たとえば図１４に示すテーブル１４００に基づくインデクスによって示される。たとえば、バッファサイズ（ＢＳ）０［Ｂｙｔｅｓ］は、インデクス「０」によって示される。【００８６】
また、０［Ｂｙｔｅｓ］より大きく１０［Ｂｙｔｅｓ］以下のバッファサイズはインデクス「１」によって示される。また、１０［Ｂｙｔｅｓ］より大きく１２［Ｂｙｔｅｓ］以下のバッファサイズはインデクス「２」によって示される。このように、上述したデータ量情報を示すバッファサイズをインデクスによって示すことで、データ量情報のサイズを小さくすることができる。【００８７】
図１５は、データＰＤＵのフォーマットの一例を示す図である。受信ノード１００と送信ノード２００との間で送受信されるデータＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図１５に示すＰＤＣＰフレーム１５００のようにする。ＰＤＣＰフレーム１５００には、Ｄ／Ｃ１５１０と、Ｒ１５２０（Ｒｅｓｅｒｖｅｄ）と、ＰＤＣＰシーケンスナンバ１５３０と、データ１５４０と、が含まれている。【００８８】
Ｄ／Ｃ１５１０は、ＰＤＣＰフレーム１５００がデータＰＤＵおよびコントロールＰＤＵのいずれであるかを示す値である。ＰＤＣＰフレーム１５００においては、Ｄ／Ｃ１５１０は、データＰＤＵを示す「１」となる。Ｒ１５２０はここでは使用しない。ＰＤＣＰシーケンスナンバ１５３０は、ＰＤＣＰフレーム１５００のシーケンスナンバである。データ１５４０は、たとえば上述したＡＭＲデータ９１１やＳＩＤデータ９１２である。【００８９】
図１６は、コントロールＰＤＵのフォーマットの一例を示す図である。図１６において、図１５に示した部分と同様の部分については同一の符号を付して説明を省略する。受信ノード１００と送信ノード２００との間で送受信されるコントロールＰＤＵのＰＤＣＰのヘッダは、たとえば図１６に示すＰＤＣＰフレーム１６００のようにする。【００９０】
ＰＤＣＰフレーム１６００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、Ｒ１５２０と、Ｉｎｔｅｒｓｐｅｒｓｅｄ＿ＲＯＨＣ＿ｆｅｅｄｂａｃｋ＿ｐａｃｋｅｔ１６２０と、が含まれている。ＰＤＣＰフレーム１６００においては、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。ＰＤＵタイプ１６１０は、コントロールＰＤＵの種別（ＰＤＣＰステータスレポートやヘッダ圧縮フィードバック情報）を示している。【００９１】
（受信ノードの動作）
図１７は、図１に示した受信ノードの動作の一例を示すフローチャートである。図１に示した受信ノード１００は、図１７に示す各ステップを行う。まず、受信ノード１００の通話状態判定部１３４が、受信ノード１００が送信ノード２００から受信する音声データの通話状態（「有音」または「無音」）を判定する（ステップＳ１７０１）。【００９２】
つぎに、通話状態判定部１３４が、ステップＳ１７０１によって判定された通話状態が、通話状態判定部１３４によって前回判定された通話状態から変化したか否かを判断する（ステップＳ１７０２）。通話状態が変化していない場合（ステップＳ１７０２：Ｎｏ）は、ステップＳ１７０１へ戻って処理を続行する。【００９３】
ステップＳ１７０２において、通話状態が変化した場合（ステップＳ１７０２：Ｙｅｓ）は、ＲＯＨＣ制御部１３５が、ステップＳ１７０１によって判定された通話状態に応じてＲＯＨＣの動作モードを切り替え（ステップＳ１７０３）、一連の動作を終了する。ステップＳ１７０３において、通話状態が「無音」である場合は、ＲＯＨＣ制御部１３５は、たとえばＲＯＨＣの動作モードをヘッダ圧縮の頻度が高いＵ−ｍｏｄｅに切り替える。【００９４】
ステップＳ１７０３において、通話状態が「有音」である場合は、ＲＯＨＣ制御部１３５は、たとえばＲＯＨＣの動作モードをヘッダ圧縮の頻度が低いＯ−ｍｏｄｅやＲ−ｍｏｄｅに切り替える。これにより、通話状態が「有音」のときは音質の向上を図り、通話状態が「無音」のときはヘッダ圧縮の効率化を図ることができる。【００９５】
図１８は、図１７に示したステップＳ１７０１の具体例を示すフローチャートである。図１７に示したステップＳ１７０１において、通話状態判定部１３４は、たとえば以下の各ステップを実行する。まず、この動作を開始してからの経過時間が監視周期（たとえば２０［ｍｓｅｃ］）以上になったか否かを判断し（ステップＳ１８０１）、経過時間が監視周期以上になるまで待つ（ステップＳ１８０１：Ｎｏのループ）。【００９６】
ステップＳ１８０１において、経過時間が監視周期以上になると（ステップＳ１８０１：Ｙｅｓ）、受信バッファ１３１の滞留データ量を測定する（ステップＳ１８０２）。つぎに、通話状態判定部１３４による前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ１８０３）。【００９７】
ステップＳ１８０３において、通話状態が「有音」である場合（ステップＳ１８０３：Ｙｅｓ）は、ステップＳ１８０２によって測定された滞留データ量が閾値以下か否かを判断する（ステップＳ１８０４）。滞留データ量が閾値以下でない場合（ステップＳ１８０４：Ｎｏ）は、一連の処理を終了する。【００９８】
ステップＳ１８０４において、ステップＳ１８０２によって測定された滞留データ量が閾値以下である場合（ステップＳ１８０４：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新し（ステップＳ１８０５）、一連の処理を終了する。【００９９】
ステップＳ１８０３において、通話状態が「有音」でない場合（ステップＳ１８０３：Ｎｏ）は、ステップＳ１８０２によって測定された滞留データ量が閾値より大きいか否かを判断する（ステップＳ１８０６）。滞留データ量が閾値より大きくない場合（ステップＳ１８０６：Ｎｏ）は、一連の処理を終了する。【０１００】
ステップＳ１８０６において、ステップＳ１８０２によって測定された滞留データ量が閾値より大きい場合（ステップＳ１８０６：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新し（ステップＳ１８０７）、一連の処理を終了する。ステップＳ１８０４およびステップＳ１８０６において比較に用いる閾値は、たとえば図９に示したＳＩＤデータ９１２のサイズに相当する閾値である。【０１０１】
（ＲＯＨＣの動作モード切替）
図１９は、ＲＯＨＣの動作モード切替の一例を示す図である。図１９において、横軸は時間を示している。符号１９１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。ＡＭＲデータ１９１１は、音声を伝送するとき（有音）に送信される。ＳＩＤデータ１９１２は、伝送する音声がないとき（無音）に送信される。【０１０２】
区間１９２１〜１９２４は、時間的に連続する時間区間である。区間１９２１および区間１９２３は、通話状態が「有音」となっており、ＡＭＲデータ１９１１が送信されている。区間１９２２および区間１９２４は、通話状態が「無音」となっており、ＳＩＤデータ１９１２が送信されている。【０１０３】
符号１９３０は、受信ノード１００によるＲＯＨＣの動作モードの切替を示している。符号１９３０に示すように、受信ノード１００は、区間１９２１および区間１９２３においては通話状態を「有音」と判定する。そして、受信ノード１００は、区間１９２１および区間１９２３においてはＲＯＨＣの動作モードをＲ−ｍｏｄｅ（たとえばＯ−ｍｏｄｅでもよい）に切り替える。また、受信ノード１００は、区間１９２２および区間１９２４においては通話状態を「無音」と判定する。そして、受信ノード１００は、区間１９２２および区間１９２４においてはＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える。【０１０４】
これにより、通話状態が「無音」である区間１９２２および区間１９２４においては、ＲＯＨＣの動作モードをヘッダ圧縮の頻度が高いＵ−ｍｏｄｅにし、無線帯域の利用効率を向上させることができる。一方、通話状態が「有音」である区間１９２１および区間１９２３においては、ＲＯＨＣの動作モードをヘッダ圧縮の頻度が低いＲ−ｍｏｄｅにすることで、音声品質を向上させることができる。【０１０５】
このように、実施の形態１にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。【０１０６】
また、受信バッファ１３１の滞留データ量を測定し、測定した滞留データ量に基づいて通話状態を判定することができる。たとえば、測定した滞留データ量を閾値と比較することによって通話状態（「有音」または「無音」）を容易に判定することができる。【０１０７】
（実施の形態２）
実施の形態２においては、ＬＴＥシステムにおいて送信ノード２００が受信ノード１００へ送信するＢＳＲを用いて通話状態の判定を行う。上述したように、送信ノード２００が受信ノード１００へ送信するＭＡＣ＿ＰＤＵ（図１０参照）のＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔには、送信ノード２００の送信バッファ２１１の滞留データ量を示すＢＳＲ（図１１〜図１３参照）が含まれている。【０１０８】
（受信ノードの構成例）
図２０は、実施の形態２にかかる受信ノードの構成例を示すブロック図である。図２０において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。図２０に示すように、実施の形態２にかかる受信ノード１００のＭＡＣレイヤ終端部１１０は、受信処理部２０１１と、ＭＣＥ終端部２０１２と、送信処理部２０１３と、を備えている。受信処理部２０１１は、ＭＡＣレイヤにおける受信処理を行う。【０１０９】
受信処理部２０１１は、受信処理を行った各データをＲＬＣレイヤ終端部１２０およびＭＣＥ終端部２０１２へ出力する。ＭＣＥ終端部２０１２は、ＭＣＥ（ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ）を終端する。たとえば、ＭＣＥ終端部２０１２は、受信処理部２０１１から出力されたデータに含まれるＢＳＲ（図１１〜図１３参照）を取得する。【０１１０】
ＢＳＲは、送信ノード２００における送信バッファ２１１の滞留データ量を示している。ＭＣＥ終端部２０１２は、取得したＢＳＲを滞留データ量としてＰＤＣＰ終端部１３０へ出力する。送信処理部２０１３は、ＭＡＣレイヤにおける送信処理を行う。送信処理部２０１３は、送信処理を行った各データを送信ノード２００へ送信する。【０１１１】
ＰＤＣＰ終端部１３０の通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量に基づいて通話状態を判定する。具体的には、通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量が閾値より大きい場合は通話状態を「有音」と判定する。また、通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。【０１１２】
（送信ノードの構成例）
図２１は、実施の形態２にかかる送信ノードの動作の一例を示すフローチャートである。図２０に示した受信ノード１００の基本的な動作については、図１７に示した動作と同様である。また、図２０に示した受信ノード１００の通話状態判定部１３４は、図１７に示したステップＳ１７０１において、以下の各ステップを行う。【０１１３】
まず、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ２１０１）、経過時間が監視周期以上になるまで待つ（ステップＳ２１０１：Ｎｏのループ）。経過時間が監視周期以上になると（ステップＳ２１０１：Ｙｅｓ）、送信ノード２００から送信されたデータ量情報（ＢＳＲ）を、ＭＣＥ終端部２０１２を介して受信する（ステップＳ２１０２）。ステップＳ２１０２において受信されるデータ量情報は、送信ノード２００の送信バッファ２１１の滞留データ量を示している。【０１１４】
つぎに、前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ２１０３）。通話状態が「有音」である場合（ステップＳ２１０３：Ｙｅｓ）は、ステップＳ２１０２によって受信されたデータ量情報が示す滞留データ量が閾値以下か否かを判断する（ステップＳ２１０４）。滞留データ量が閾値以下でない場合（ステップＳ２１０４：Ｎｏ）は、一連の処理を終了する。【０１１５】
ステップＳ２１０４において、受信されたデータ量情報が示す滞留データ量が閾値以下である場合（ステップＳ２１０４：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新し（ステップＳ２１０５）、一連の処理を終了する。【０１１６】
ステップＳ２１０３において、通話状態が「有音」でない場合（ステップＳ２１０３：Ｎｏ）は、ステップＳ２１０２によって受信されたデータ量情報が示す滞留データ量が閾値より大きいか否かを判断する（ステップＳ２１０６）。滞留データ量が閾値より大きくない場合（ステップＳ２１０６：Ｎｏ）は、一連の処理を終了する。【０１１７】
ステップＳ２１０６において、受信されたデータ量情報が示す滞留データ量が閾値より大きい場合（ステップＳ２１０６：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新し（ステップＳ２１０７）、一連の処理を終了する。なお、図１４に示したようにＢＳＲのバッファサイズがインデクス化されている場合は、ステップＳ２１０４およびステップＳ２１０６において比較に用いる閾値も図１４に示したインデクスを用いる。【０１１８】
このように、実施の形態２にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。【０１１９】
また、送信ノード２００において送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信したデータ量情報が示す滞留データ量に基づいて通話状態を判定することができる。送信ノード２００側のデータ滞留量を用いることにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。【０１２０】
また、送信ノード２００が受信ノード１００へ送信するＭＡＣ＿ＰＤＵ（図１０参照）のＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔに含まれるＢＳＲを用いてデータ量情報を送信する。これにより、送信ノード２００から受信ノード１００へ送信する制御信号を新たに追加しなくても、データ量情報を受信ノード１００へ送信することができる。【０１２１】
（実施の形態３）
（受信ノードの構成例）
図２２は、実施の形態３にかかる受信ノードの構成例を示すブロック図である。図２２において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態３にかかる受信ノード１００においては、図１に示した通話状態判定部１３４を省いた構成にしてもよい。【０１２２】
受信処理部１３２は、受信バッファ１３１から読み出したデータのうちの、送信ノード２００から送信された通話状態情報をＲＯＨＣ制御部１３５へ出力する。ＲＯＨＣ制御部１３５は、受信処理部１３２から出力された通話状態情報が示す通話状態の判定結果（「有音」または「無音」）に応じてＲＯＨＣの動作モードを切り替える。【０１２３】
（送信ノードの構成例）
図２３は、実施の形態３にかかる送信ノードの構成例を示すブロック図である。図２３において、図２に示した構成と同様の構成については同一の符号を付して説明を省略する。図２３に示すように、実施の形態３にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２に示した構成に加えて通話状態判定部２３１０を備えている。【０１２４】
通話状態判定部２３１０は、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を判定し、判定結果を示す通話状態情報を送信処理部２１３へ出力する。通話状態判定部２３１０が判定する通話状態は、たとえば、音声データが示す音声が「有音」であるか「無音」であるかに関する状態である。通話状態判定部２３１０は、たとえば、送信バッファ２１１の滞留データ量に基づいて通話状態を判定する。【０１２５】
具体的には、通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、送信バッファ２１１の滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。音声データの量と比較する閾値は、たとえば、通話状態が「無音」であり、送信ノード２００がＳＩＤデータを送信するときに送信バッファ２１１に滞留するＳＩＤデータの量に相当する値である。【０１２６】
送信処理部２１３は、通話状態判定部２３１０から出力された通話状態情報を、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。これにより、受信ノード１００へ通話状態情報を送信することができる。通話状態情報を送信するためのＰＤＣＰフレームについて、図２４によって説明する。【０１２７】
（データのフレームフォーマット）
図２４は、ＰＤＣＰフレームのフォーマットの一例を示す図である。図２４において、図１６に示した部分と同様の部分については同一の符号を付して説明を省略する。送信処理部２１３が受信ノード１００へ送信するコントロールＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図２４に示すＰＤＣＰフレーム２４００のようにする。【０１２８】
ＰＤＣＰフレーム２４００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、Ｒ１５２０と、ＴＳＦ２４１０（Ｔｅｌｅｐｈｏｎｅ  ｃａｌｌ  Ｓｔａｔｕｓ  Ｆｌａｇ）と、が含まれている。ＰＤＣＰフレーム２４００において、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。【０１２９】
ＴＳＦ２４１０は、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を示している。送信処理部２１３は、通話状態判定部２３１０から出力された通話状態情報を、ＰＤＣＰフレーム２４００のＴＳＦ２４１０に格納する。受信ノード１００の受信処理部１３２は、送信ノード２００から受信したＰＤＣＰフレーム２４００のＴＳＦ２４１０を通話状態情報としてＲＯＨＣ制御部１３５へ出力する。【０１３０】
（送信ノードの動作）
図２５は、図２３に示した送信ノードの動作の一例を示すフローチャートである。図２３に示した送信ノード２００は、図２５に示す各ステップを行う。まず、送信ノード２００の通話状態判定部２３１０が、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を判定する（ステップＳ２５０１）。【０１３１】
つぎに、通話状態判定部２３１０が、ステップＳ２５０１によって判定された通話状態が、通話状態判定部２３１０によって前回判定された通話状態から変化したか否かを判断する（ステップＳ２５０２）。通話状態が変化していない場合（ステップＳ２５０２：Ｎｏ）は、ステップＳ２５０１へ戻って処理を続行する。【０１３２】
ステップＳ２５０２において、通話状態が変化した場合（ステップＳ２５０２：Ｙｅｓ）は、送信処理部２１３が、ステップＳ２５０１によって判定された通話状態を示す通話状態情報を受信ノード１００へ送信し（ステップＳ２５０３）、一連の処理を終了する。ステップＳ２５０３によって送信された通話状態情報は受信ノード１００によって受信される。受信ノード１００は、受信した通話状態情報が示す通話状態に応じて送信ノード２００との間のＲＯＨＣの動作モードを切り替える。【０１３３】
図２６は、図２５に示したステップＳ２５０１の具体例を示すフローチャートである。図２５に示したステップＳ２５０１において、通話状態判定部２３１０は、たとえば以下の各ステップを実行する。まず、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ２６０１）、経過時間が監視周期以上になるまで待つ（ステップＳ２６０１：Ｎｏのループ）。【０１３４】
ステップＳ２６０１において、経過時間が監視周期以上になると（ステップＳ２６０１：Ｙｅｓ）、送信バッファ２１１の滞留データ量を測定する（ステップＳ２６０２）。図２６に示すステップＳ２６０３〜Ｓ２６０７は、図１８に示したステップＳ１８０３〜Ｓ１８０７と同様であるため説明を省略する。【０１３５】
このように、実施の形態３にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。【０１３６】
また、送信ノード２００において通話状態を判定し、判定結果を示す通話状態情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信した通話状態情報が示す通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。通話状態を送信ノード２００側で判定することにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。【０１３７】
また、通話状態を送信ノード２００側で判定することにより、受信ノード１００側の処理負担を軽減することができる。また、送信ノード２００が受信ノード１００へ送信するＰＤＣＰフレーム２４００にＴＳＦ２４１０を設け、ＴＳＦ２４１０を用いて通話状態情報を送信することにより、通話状態情報を受信ノード１００へ送信することができる。【０１３８】
（実施の形態４）
（受信ノードの構成例）
図２７は、実施の形態４にかかる受信ノードの構成例を示すブロック図である。図２７において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態４にかかる受信ノード１００の受信処理部１３２は、受信処理したデータのうちのデータ量情報を通話状態判定部１３４へ出力する。【０１３９】
通話状態判定部１３４へ出力されるデータ量情報は、送信ノード２００における送信バッファ２１１の滞留データ量を示している。通話状態判定部１３４は、受信処理部１３２から出力されたデータ量情報が示す滞留データ量に基づいて通話状態を判定する。具体的には、通話状態判定部１３４は、滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。【０１４０】
（送信ノードの構成例）
図２８は、実施の形態４にかかる送信ノードの構成例を示すブロック図である。図２８において、図２に示した構成と同様の構成については同一の符号を付して説明を省略する。図２８に示すように、実施の形態３にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２に示した構成に加えて滞留データ量測定部２８１０を備えている。【０１４１】
滞留データ量測定部２８１０は、送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を送信処理部２１３へ出力する。送信処理部２１３は、滞留データ量測定部２８１０から出力されたデータ量情報を、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。これにより、受信ノード１００へデータ量情報を送信することができる。データ量情報を送信するためのＰＤＣＰフレームについて、図２９において説明する。【０１４２】
（データのフレームフォーマット）
図２９は、ＰＤＣＰフレームのフォーマットの一例を示す図である。図２９において、図１６に示した部分と同様の部分については同一の符号を付して説明を省略する。送信ノード２００の送信処理部２１３が送信するコントロールＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図２９に示すＰＤＣＰフレーム２９００のようにする。【０１４３】
ＰＤＣＰフレーム２９００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、ＢＳＲ２９１０と、が含まれている。ＰＤＣＰフレーム２９００においては、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。【０１４４】
ＢＳＲ２９１０は、送信ノード２００の送信バッファ２１１の滞留データ量を示している。送信処理部２１３は、滞留データ量測定部２８１０から出力されたデータ量情報を、ＰＤＣＰフレーム２９００のＢＳＲ２９１０に格納して受信ノード１００へ送信する。受信ノード１００の受信処理部１３２は、送信ノード２００から受信したＰＤＣＰフレーム２９００のＢＳＲ２９１０を滞留データ量として通話状態判定部１３４へ出力する。【０１４５】
このように、実施の形態４にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。【０１４６】
また、送信ノード２００において送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信したデータ量情報が示す滞留データ量に基づいて通話状態を判定することができる。送信ノード２００側のデータ滞留量を用いることにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。【０１４７】
また、送信ノード２００が受信ノード１００へ送信するＰＤＣＰフレーム２９００にＢＳＲ２９１０を設け、ＢＳＲ２９１０を用いてデータ量情報を送信することにより、滞留データ量を送信ノード２００から受信ノード１００へ送信することができる。【０１４８】
（実施の形態５）
実施の形態５にかかる受信ノード１００の通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定する。また、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定する。受信ノード１００および送信ノード２００の構成は、たとえば図１および図２に示した構成と同様である。【０１４９】
（受信ノードの動作）
図３０は、実施の形態５にかかる受信ノードの動作の一例を示すフローチャートである。実施の形態５にかかる受信ノード１００の基本的な動作については、図１７に示した動作と同様である。また、実施の形態５にかかる受信ノード１００の通話状態判定部１３４は、図１７に示したステップＳ１７０１において、以下の各ステップを行う。【０１５０】
まず、カウンタｋを０に設定する（ステップＳ３００１）。つぎに、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ３００２）、経過時間が監視周期以上になるまで待つ（ステップＳ３００２：Ｎｏのループ）。【０１５１】
ステップＳ３００２において、経過時間が監視周期以上になると（ステップＳ３００２：Ｙｅｓ）、受信バッファ１３１の滞留データ量を測定する（ステップＳ３００３）。つぎに、前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ３００４）。【０１５２】
ステップＳ３００４において、通話状態が「有音」である場合（ステップＳ３００４：Ｙｅｓ）は、ステップＳ３００３によって測定された滞留データ量が閾値以下か否かを判断する（ステップＳ３００５）。滞留データ量が閾値以下でない場合（ステップＳ３００５：Ｎｏ）は、ステップＳ３００９へ移行して処理を続行する。【０１５３】
ステップＳ３００５において、ステップＳ３００３によって測定された滞留データ量が閾値以下である場合（ステップＳ３００５：Ｙｅｓ）は、カウンタｋをインクリメント（ｋ＝ｋ＋１）する（ステップＳ３００６）。つぎに、カウンタｋが保護段数より大きいか否かを判断する（ステップＳ３００７）。【０１５４】
ステップＳ３００７において、カウンタｋが保護段数より大きくない場合（ステップＳ３００７：Ｎｏ）は、ステップＳ３００２へ戻って処理を続行する。カウンタｋが保護段数より大きい場合（ステップＳ３００７：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新する（ステップＳ３００８）。つぎに、カウンタｋを０に設定し（ステップＳ３００９）、一連の処理を終了する。【０１５５】
ステップＳ３００４において、通話状態が「有音」でない場合（ステップＳ３００４：Ｎｏ）は、ステップＳ３００３によって測定された滞留データ量が閾値より大きいか否かを判断する（ステップＳ３０１０）。滞留データ量が閾値より大きくない場合（ステップＳ３０１０：Ｎｏ）は、ステップＳ３０１４へ進んで処理を続行する。【０１５６】
ステップＳ３０１０において、ステップＳ３００３によって測定された滞留データ量が閾値より大きい場合（ステップＳ３０１０：Ｙｅｓ）は、カウンタｋをインクリメント（ｋ＝ｋ＋１）する（ステップＳ３０１１）。つぎに、カウンタｋが保護段数より大きいか否かを判断する（ステップＳ３０１２）。【０１５７】
ステップＳ３０１２において、カウンタｋが保護段数より大きくない場合（ステップＳ３０１２：Ｎｏ）は、ステップＳ３００２へ戻って処理を続行する。カウンタｋが保護段数より大きい場合（ステップＳ３０１２：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新する（ステップＳ３０１３）。つぎに、カウンタｋを０に設定し（ステップＳ３０１４）、一連の処理を終了する。【０１５８】
このように、通話状態判定部１３４は、ステップＳ３００５において滞留データ量が閾値以下であっても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定することができる。【０１５９】
また、通話状態判定部１３４は、ステップＳ３０１０において滞留データ量が閾値より大きくても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定することができる。【０１６０】
図３１は、図３０に示した動作による通話状態判定の具体例を示す図である。図３１において、図１９に示した部分と同様の部分については同一の符号を付して説明を省略する。図３１において、横軸は時間を示している。符号３１１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。【０１６１】
ここでは、通話状態の初期値を「無音」とし、監視周期を２０［ｍｓ］とし、閾値（ＳＩＤデータ１９１２のサイズ相当）を１０［ｂｙｔｅ］とし、保護段数を３とする。受信ノード１００は、監視周期２０［ｍｓ］で受信バッファ１３１の滞留データ量を取得し、滞留データ量が閾値１０［ｂｙｔｅ］を超えるとカウンタｋをインクリメントする。監視周期Ｔ１〜Ｔ２３は、受信ノード１００における監視周期（２０［ｍｓ］）である。【０１６２】
監視周期Ｔ１〜Ｔ６において、受信ノード１００は、ＡＭＲデータ１９１１（サイズ３０［ｂｙｔｅ］）を連続して６回、２０［ｍｓ］周期で正常に受信したとする。受信ノード１００は、監視周期Ｔ１〜Ｔ３においては、メモリに記憶された通話状態が「無音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］より大きいため、カウンタｋをインクリメントする（ｋ＝１，２，３）。【０１６３】
監視周期Ｔ１〜Ｔ３において、受信ノード１００は、カウンタｋが保護段数３以下であるため、受信ノード１００は、通話状態を「無音」のままであると判定する。このため、監視周期Ｔ１〜Ｔ３においては通話状態が「無音」と判定される。【０１６４】
監視周期Ｔ４において、受信ノード１００は、通話状態が「無音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］を超えているため、カウンタｋをインクリメントする（ｋ＝４）。受信ノード１００は、監視周期Ｔ４においてはカウンタｋが保護段数３を超えるため、受信ノード１００は、通話状態が「有音」に変化したと判定する。また、カウンタｋは初期化されて０になる（ｋ＝０）。【０１６５】
監視周期Ｔ５〜Ｔ６において、受信ノード１００は、メモリに記憶された通話状態が「有音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下でないため、カウンタｋをインクリメントしない（ｋ＝０）。【０１６６】
監視周期Ｔ７において、受信ノード１００は、ＡＭＲデータ１９１１を正常に受信できなかったとする。受信ノード１００は、監視周期Ｔ７においてはメモリに記憶された通話状態が「有音」であり、滞留データ量が０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝１）。受信ノード１００は、監視周期Ｔ７においてはカウンタｋが保護段数３を超えていない（ｋ＝１）ため、受信ノード１００は、通話状態が「有音」のままであると判定する。【０１６７】
監視周期Ｔ８〜Ｔ１１において、受信ノード１００は、ＡＭＲデータ１９１１を連続して４回、正常に受信したとする。受信ノード１００は、監視周期Ｔ８〜Ｔ１１においてはメモリに記憶された通話状態が「有音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下でないため、カウンタｋをインクリメントしない（ｋ＝０）。【０１６８】
監視周期Ｔ１２以降、送信ノード２００から受信ノード１００へ送信する音声データの実際の通話状態が「無音」となったとする。監視周期Ｔ１２，Ｔ１６，Ｔ２０のそれぞれにおいて、受信ノード１００は、ＳＩＤデータ１９１２（サイズ１０［ｂｙｔｅ］）を正常に受信したとする。【０１６９】
監視周期Ｔ１２〜Ｔ１５において、受信ノード１００は、メモリに記憶された通話状態が「有音」であり滞留データ量が１０または０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝１，２，３）。受信ノード１００は、監視周期Ｔ１２〜Ｔ１５の間の期間においてはカウンタｋが保護段数３以下であるため、受信ノード１００は、通話状態を「有音」のままであると判定する。【０１７０】
監視周期Ｔ１６において、受信ノード１００は、通話状態が「有音」であり、滞留データ量が１０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝４）。受信ノード１００は、監視周期Ｔ１６においてはカウンタｋが保護段数３を超えるため、受信ノード１００は、通話状態が「無音」に変化したと判定する。また、カウンタｋは初期化されて０になる（ｋ＝０）。【０１７１】
監視周期Ｔ１７〜Ｔ２３において、受信ノード１００は、メモリに記憶された通話状態が「無音」であり、滞留データ量が１０［ｂｙｔｅ］または０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントしない（ｋ＝０）。【０１７２】
このように、通話状態判定部１３４は、時期Ｔ７において滞留データ量が閾値以下であっても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、受信ノード１００がＡＭＲデータ１９１１を正常に受信できなかった場合に通話状態が「無音」になったと誤判定されることを回避することができる。【０１７３】
このように、実施の形態５にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。【０１７４】
また、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定することで、瞬間的なトラヒックの増加によって通話状態が「有音」になったと誤判定することを回避することができる。【０１７５】
また、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定することで、フレーム欠落などによる瞬間的なトラヒックの減少によって通話状態が「有音」になったと誤判定することを回避することができる。【０１７６】
実施の形態５においては、受信ノード１００および送信ノード２００の構成が図１および図２に示した構成（実施の形態１）と同様である場合について説明した。ただし、受信ノード１００および送信ノード２００の構成を、実施の形態２〜４のいずれかと同様にしてもよい。一例として、受信ノード１００および送信ノード２００の構成を図２２および図２３に示した構成（実施の形態３）と同様にした場合について説明する。【０１７７】
この場合は、送信ノード２００の通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定する。また、通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定する。【０１７８】
（実施の形態６）
実施の形態１〜５においては、ＲＯＨＣ制御部１３５を受信ノード１００に設け、受信ノード１００によってＲＯＨＣの切替制御を行う構成について説明した。これに対して、実施の形態６は、ＲＯＨＣ制御部１３５に相当する機能を送信ノード２００に設け、送信ノード２００によってＲＯＨＣの切替制御を行う。【０１７９】
（受信ノードの構成例）
図３２は、実施の形態６にかかる受信ノードの構成例を示すブロック図である。図３２において、図２２に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態６にかかる受信ノード１００においては、図２２に示したＲＯＨＣ制御部１３５および送信処理部１３６を省いた構成にしてもよい。【０１８０】
（送信ノードの構成例）
図３３は、実施の形態６にかかる送信ノードの構成例を示すブロック図である。図３３において、図２３に示した構成と同様の構成については同一の符号を付して説明を省略する。図３３に示すように、実施の形態６にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２３に示した構成に加えてＲＯＨＣ制御部３３１０を備えている。【０１８１】
また、実施の形態６にかかる送信ノード２００においては、図２３に示した受信処理部２１４を省いた構成にしてもよい。通話状態判定部２３１０は、判定結果を示す通話状態情報をＲＯＨＣ制御部３３１０へ出力する。【０１８２】
ＲＯＨＣ制御部３３１０は、（制御手段）は、通話状態判定部２３１０から出力された判定結果に応じて、受信ノード１００および送信ノード２００におけるＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部３３１０は、ＲＯＨＣの動作モードを切り替えるために、切り替える動作モードを圧縮部２１２へ通知する。【０１８３】
また、ＲＯＨＣ制御部３３１０は、切り替える動作モードを示す切替指示信号を生成する。そして、ＲＯＨＣ制御部３３１０は、生成した切替指示信号を送信処理部２１３へ出力する。これにより、切替指示信号が受信ノード１００へ送信され、ＲＯＨＣの動作モードが切り替わる。ＲＯＨＣ制御部３３１０によるＲＯＨＣの動作モードの切替については、上述したＲＯＨＣ制御部１３５による切替と同様であるため説明を省略する。【０１８４】
図３３に示した圧縮部２１２は、ヘッダ圧縮を行った音声データを送信ノード２００のメモリ（不図示）に書き込む。圧縮部２１２は、たとえばＣＰＵなどの演算手段である。送信処理部２１３は、圧縮部２１２によって送信ノード２００のメモリに書き込まれた音声データを読み出し、読み出した音声データを送信する。【０１８５】
通話状態判定部２３１０は、通話状態の判定結果を送信ノード２００のメモリ（不図示）に書き込む。通話状態判定部２３１０は、たとえばＣＰＵなどの演算手段である。ＲＯＨＣ制御部３３１０は、通話状態判定部２３１０によって送信ノード２００のメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じてＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部３３１０は、たとえばＣＰＵなどの演算手段である。【０１８６】
このように、実施の形態６にかかる送信ノード２００（送信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。【０１８７】
また、送信ノード２００において通話状態を判定し、判定結果に基づいてＲＯＨＣの動作モードを切り替えることで、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。また、通話状態の判定およびＲＯＨＣの動作モードの切替を送信ノード２００側で行うことにより、受信ノード１００側の処理負担を軽減することができる。【０１８８】
（ＲＯＨＣの動作モード切替の具体例）
図３４は、Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへの切替の具体例を示す図である。図３４において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｃ＿ＭＯＤＥ３４１０は、送信ノード２００の圧縮部２１２に設定されるＲＯＨＣの動作モードを示している。【０１８９】
Ｃ＿ＭＯＤＥ３４１０は、「Ｕ−ｍｏｄｅ」、「Ｏ−ｍｏｄｅ」または「Ｒ−ｍｏｄｅ」の値をとる。Ｃ＿ＴＲＡＮＳ３４２０は、送信ノード２００の圧縮部２１２に設定される、ＲＯＨＣの動作モードの遷移経過状態である。Ｃ＿ＴＲＡＮＳ３４２０は、「Ｐｅｎｄｉｎｇ」または「Ｄｏｎｅ」の値をとる。【０１９０】
Ｄ＿ＭＯＤＥ３４３０は、受信ノード１００の伸張部１３３に設定されるＲＯＨＣの動作モードである。Ｄ＿ＭＯＤＥ３４３０は、「Ｕ−ｍｏｄｅ」、「Ｏ−ｍｏｄｅ」または「Ｒ−ｍｏｄｅ」の値をとる。Ｄ＿ＴＲＡＮＳ３４４０は、受信ノード１００の伸張部１３３に設定される、ＲＯＨＣの動作モードの遷移経過状態である。Ｄ＿ＴＲＡＮＳ３４４０は、「Ｉｎｉｔｉａｔｅｄ」、「Ｐｅｎｄｉｎｇ」または「Ｄｏｎｅ」の値をとる。【０１９１】
Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへ切替は、受信ノード１００から送信ノード２００へのフィードバックチャネルが利用可能であれば任意のタイミングで行うことができる。たとえば、時期ｔ３４１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ−ｍｏｄｅであったとする。【０１９２】
そして、受信ノード１００は、ＲＯＨＣの動作モードをＯ−ｍｏｄｅへ切り替える旨の切替指示信号３４５０を時期ｔ３４１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３４５０を受信すると、送信ノード２００におけるＲＯＨＣの動作モードをＯ−ｍｏｄｅに切り替える。【０１９３】
具体的には、送信ノード２００は、周期的な非圧縮フレーム５１１の送信を停止し、受信ノード１００からＮａｃｋを受信するまでは圧縮フレーム５１２を送信する。Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへの切替においては、受信ノード１００および送信ノード２００において任意のタイミングにおいて切替を行うことができるため、Ｃ＿ＴＲＡＮＳ３４２０およびＤ＿ＴＲＡＮＳ３４４０は「Ｄｏｎｅ」のまま切替を行うことができる。【０１９４】
図３５は、Ｕ−ｍｏｄｅからＲ−ｍｏｄｅへの切替の具体例を示す図である。図３５において、図３４に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｕ−ｍｏｄｅからＲ−ｍｏｄｅへ切替は、少なくとも１つの非圧縮フレーム５１１を正常に受信した後で行う。たとえば、時期ｔ３５１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ−ｍｏｄｅであったとする。【０１９５】
そして、受信ノード１００は、ＲＯＨＣの動作モードをＲ−ｍｏｄｅへ切り替える旨の切替指示信号３５２１を時期ｔ３５１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３５２１を受信すると、動作モードをＲ−ｍｏｄｅに切り替え、非圧縮フレーム５１１を連続して受信ノード１００へ送信する。【０１９６】
受信ノード１００は、送信ノード２００から送信された非圧縮フレーム５１１を受信すると、受信ノード１００におけるＲＯＨＣの動作モードをＲ−ｍｏｄｅに切り替える。受信ノード１００が切替指示信号３５２１を送信した時期ｔ３５１１から、送信ノード２００から送信された非圧縮フレーム５１１を受信ノード１００が受信した時期ｔ３５１２までの期間は、Ｄ＿ＴＲＡＮＳ３４４０は「Ｉｎｉｔｉａｔｅｄ」になる。【０１９７】
また、受信ノード１００は、時期ｔ３５１２において送信ノード２００から送信された非圧縮フレーム５１１を正常に受信すると、送信ノード２００へＡｃｋ３５２２を送信する。送信ノード２００は、Ａｃｋ３５２２を受信すると、受信ノード１００からＮａｃｋを受信するまでは連続して圧縮フレーム５１２を受信ノード１００へ送信する。【０１９８】
送信ノード２００がＲＯＨＣの動作モードをＲ−ｍｏｄｅに切り替えてから送信ノード２００がＡｃｋ３５２２を受信するまでの期間は、Ｃ＿ＴＲＡＮＳ３４２０は「Ｐｅｎｄｉｎｇ」になる。また、受信ノード１００がＡｃｋ３５２２を送信した時期ｔ３５１２から受信ノード１００が圧縮フレーム５１２を受信する時期ｔ３５１３までの期間のＤ＿ＴＲＡＮＳ３４４０は「Ｐｅｎｄｉｎｇ」になる。【０１９９】
図３６は、Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへの切替の具体例を示す図である。図３６において、図３４に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへ切替は、任意のタイミングで行うことができる。たとえば、時期ｔ３６１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＯ−ｍｏｄｅであったとする。【０２００】
そして、受信ノード１００は、ＲＯＨＣの動作モードをＵ−ｍｏｄｅへ切り替える旨の切替指示信号３６２１を時期ｔ３６１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３６２１を受信すると、送信ノード２００におけるＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える。【０２０１】
具体的には、送信ノード２００は、周期的な非圧縮フレーム５１１の送信を開始する。また、送信ノード２００は、ＲＯＨＣの動作モードのＵ−ｍｏｄｅへの切替時に、非圧縮フレーム５１１を３回連続して送信し、これらの非圧縮フレーム５１１に対するＡｃｋを受信ノード１００から受信するようにしてもよい。これにより、動作モードの切替が正常に行われていることを確認することができる（Ｔｈｒｅｅ−ｗａｙハンドシェイク）。【０２０２】
受信ノード１００は、切替指示信号３６２１を送信した後に送信ノード２００から非圧縮フレーム５１１を受信した時期ｔ３６１２において、ＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える。受信ノード１００が切替指示信号３６２１を送信した時期ｔ３６１１から、受信ノード１００が送信ノード２００から圧縮フレーム５１２を受信する時期ｔ３６１３までの期間のＤ＿ＴＲＡＮＳ３４４０は「Ｉｎｉｔｉａｔｅｄ」になる。Ｒ−ｍｏｄｅからＵ−ｍｏｄｅへの切替は、Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへの切替と同様であるため説明を省略する。【０２０３】
以上説明したように、開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。【０２０４】
なお、上述した各実施の形態においては、ＬＴＥシステムを例とする構成について説明したが、開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法は、ＷｉＭＡＸなどの他の通信システムに対しても適用可能である。【０２０５】
また、上述した各実施の形態においては、通話状態が「有音」の場合はＲＯＨＣの動作モードをＯ−ｍｏｄｅやＲ−ｍｏｄｅに切り替え、通話状態が「無音」の場合はＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える構成について説明した。これに対して通話状態が「有音」の場合はＲＯＨＣの動作モードをＲ−ｍｏｄｅに切り替え、通話状態が「無音」の場合はＲＯＨＣの動作モードをＯ−ｍｏｄｅに切り替える構成にしてもよい。【０２０６】
一般的に、Ｏ−ｍｏｄｅはＲ−ｍｏｄｅよりもヘッダ圧縮の頻度が高いため、ヘッダ圧縮の効率が優れている。このため、通話状態が「無音」の場合はＲＯＨＣの動作モードをＯ−ｍｏｄｅに切り替えることで、ヘッダ圧縮の効率化を図ることができる。その他、ヘッダ圧縮の動作モードについては、ＲＯＨＣのＵ−ｍｏｄｅ、Ｏ−ｍｏｄｅおよびＲ−ｍｏｄｅに限らず、ヘッダ圧縮の頻度が異なる種々の動作モードを用いることができる。
【図１】
2010106663.tif 000003
【図２】
2010106663.tif 000004
【図３】
2010106663.tif 000005
【図４】
2010106663.tif 000006
【図５】
2010106663.tif 000007
【図６】
2010106663.tif 000008
【図７】
2010106663.tif 000009
【図８】
2010106663.tif 000010
【図９】
2010106663.tif 000011
【図１０】
2010106663.tif 000012
【図１１】
2010106663.tif 000013
【図１２】
2010106663.tif 000014
【図１３】
2010106663.tif 000015
【図１４】
2010106663.tif 000016
【図１５】
2010106663.tif 000017
【図１６】
2010106663.tif 000018
【図１７】
2010106663.tif 000019
【図１８】
2010106663.tif 000020
【図１９】
2010106663.tif 000021
【図２０】
2010106663.tif 000022
【図２１】
2010106663.tif 000023
【図２２】
2010106663.tif 000024
【図２３】
2010106663.tif 000025
【図２４】
2010106663.tif 000026
【図２５】
2010106663.tif 000027
【図２６】
2010106663.tif 000028
【図２７】
2010106663.tif 000029
【図２８】
2010106663.tif 000030
【図２９】
2010106663.tif 000031
【図３０】
2010106663.tif 000032
【図３１】
2010106663.tif 000033
【図３２】
2010106663.tif 000034
【図３３】
2010106663.tif 000035
【図３４】
2010106663.tif 000036
【図３５】
2010106663.tif 000037
【図３６】
2010106663.tif 000038
【手続補正書】
【提出日】平成23年8月11日(2011.8.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信装置において、
前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信手段と、
前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする受信装置。
【請求項２】
前記判定手段は、前記受信手段によって受信された音声データを格納する受信バッファの滞留データ量に基づいて前記通話状態を判定することを特徴とする請求項１に記載の受信装置。
【請求項３】
前記受信手段は、前記送信装置の送信バッファに格納されている前記音声データの量を示すデータ量情報を前記送信装置から受信し、
前記判定手段は、前記受信手段によって受信されたデータ量情報に基づいて前記通話状態を判定することを特徴とする請求項１に記載の受信装置。
【請求項４】
前記受信手段は、前記送信装置によって判定された前記通話状態を示す通話状態情報を前記送信装置から受信し、
前記制御手段は、前記受信手段によって受信された通話状態情報に応じて前記動作モードを切り替えることを特徴とする請求項１に記載の受信装置。
【請求項５】
前記判定手段は、前記受信バッファの滞留データ量が閾値より大きい場合は前記通話状態を有音と判定し、前記音声データの量が前記閾値以下の場合は前記通話状態を無音と判定することを特徴とする請求項２に記載の受信装置。
【請求項６】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信装置において、
音声データのヘッダ圧縮を行う圧縮手段と、
前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
前記送信手段によって送信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする送信装置。
【請求項７】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信方法において、
前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信工程と、
前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする受信方法。
【請求項８】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信方法において、
音声データのヘッダ圧縮を行う圧縮工程と、
前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
前記送信工程によって送信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする送信方法。
【請求項９】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおいて、
音声データのヘッダ圧縮を行う圧縮手段と、
前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
前記送信手段によって送信された音声データを受信する受信手段と、
前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする通信システム。
【請求項１０】
音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムの通信方法において、
音声データのヘッダ圧縮を行う圧縮工程と、
前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
前記送信工程によって送信された音声データを受信する受信工程と、
前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする通信方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、音声通信を行う受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法に関する。
【背景技術】
【０００２】
ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムは、３Ｇセルラーシステムからの飛躍的な性能向上を目指し、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で国際標準化が進められている。ＬＴＥシステムは、モバイル通信で高速伝送を実現し、高速映像配信など高度なサービス環境を提供するとともに、効率的な周波数利用が図られるシステムとして期待されている。
【０００３】
また、既存（３Ｇまで）システムにおいては、音声とデータ通信とはそれぞれ別の通信インフラで提供されていたが、ＬＴＥシステムにおいては音声とデータ通信とをＩＰベースに統合する「ａｌｌ  ＩＰ」への移行が意図されている。これにより、従来の回線交換型インフラを含むシステムから、ＬＴＥシステムによって、完全なＩＰ化がなされたシステムが実現されると見込まれている。
【０００４】
ＬＴＥシステムにおけるリアルタイムデータの伝送は、一般的な有線ＩＰネットワークにおけるＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）と同様にＲＴＰ／ＵＤＰ／ＩＰの各プロトコルによって実現される。このため、ＬＴＥシステムにおけるリアルタイムデータは、各プロトコルのヘッダが付与されることによりオーバヘッドが大きくなる。
【０００５】
帯域幅の限られる無線区間を含むネットワークにおいては、無線区間の帯域利用効率を向上させるために、オーバヘッドとなる各プロトコルのヘッダを圧縮する機能が求められる。このヘッダ圧縮機能は、ＬＴＥシステムにおいて実現される見込みである。
【０００６】
具体的には、ｅＮＢ〜ＵＥ間で終端されるＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）の機能に含まれるＲＯＨＣ（ＲＯｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｎｇ）と呼ばれる技術がヘッダ圧縮機能として実現される見込みである。ＲＯＨＣには、ヘッダ圧縮の効率が異なる複数の動作モードが存在する（たとえば、下記特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００２−１３５３６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述した従来技術では、ヘッダ圧縮を頻繁に行うと、フレーム欠落などの場合に音声データを復元できずにデータロスとなり、音声データの音質が劣化するという問題がある。一方、ヘッダ圧縮の頻度を低くすると、データのオーバヘッドが大きくなるため、伝送経路の帯域利用効率が低下するという問題がある。
【０００９】
開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法は、上述した問題点を解消するものであり、音声データの音質および帯域利用効率の向上を図ることを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するため、この受信装置は、音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信装置において、前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信手段と、前記受信手段によって受信される音声データの通話状態を判定する判定手段と、前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、を備える。
【００１１】
上記構成によれば、通話状態を判定し、判定した通話状態に応じてヘッダ圧縮の頻度が異なる複数の動作モードを切り替えることができる。
【発明の効果】
【００１２】
開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法によれば、音声データの音質および帯域利用効率の向上を図ることができる。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施の形態１にかかる受信ノードの構成例を示すブロック図である。
【図２】図２は、実施の形態１にかかる送信ノードの構成例を示すブロック図である。
【図３】図３は、実施の形態１にかかる通信システムの構成例を示す図である。
【図４】図４は、図３に示した通信システムにおけるプロトコルスタックを示す図である。
【図５】図５は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その１）である。
【図６】図６は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その２）である。
【図７】図７は、ＲＯＨＣのＯ−ｍｏｄｅの動作を示す図である。
【図８】図８は、ＲＯＨＣのＲ−ｍｏｄｅの動作を示す図である。
【図９】図９は、通話状態の変化の一例を示す図である。
【図１０】図１０は、ＭＡＣ＿ＰＤＵの一例を示す図である。
【図１１】図１１は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔを示す図である。
【図１２】図１２は、図１１に示したＳｈｏｒｔ＿ＢＳＲを示す図である。
【図１３】図１３は、図１１に示したＬｏｎｇ＿ＢＳＲを示す図である。
【図１４】図１４は、バッファサイズのインデクスを示す図である。
【図１５】図１５は、データＰＤＵのフォーマットの一例を示す図である。
【図１６】図１６は、コントロールＰＤＵのフォーマットの一例を示す図である。
【図１７】図１７は、図１に示した受信ノードの動作の一例を示すフローチャートである。
【図１８】図１８は、図１７に示したステップＳ１７０１の具体例を示すフローチャートである。
【図１９】図１９は、ＲＯＨＣの動作モード切替の一例を示す図である。
【図２０】図２０は、実施の形態２にかかる受信ノードの構成例を示すブロック図である。
【図２１】図２１は、実施の形態２にかかる送信ノードの動作の一例を示すフローチャートである。
【図２２】図２２は、実施の形態３にかかる受信ノードの構成例を示すブロック図である。
【図２３】図２３は、実施の形態３にかかる送信ノードの構成例を示すブロック図である。
【図２４】図２４は、ＰＤＣＰフレームのフォーマットの一例を示す図である。
【図２５】図２５は、図２３に示した送信ノードの動作の一例を示すフローチャートである。
【図２６】図２６は、図２５に示したステップＳ２５０１の具体例を示すフローチャートである。
【図２７】図２７は、実施の形態４にかかる受信ノードの構成例を示すブロック図である。
【図２８】図２８は、実施の形態４にかかる送信ノードの構成例を示すブロック図である。
【図２９】図２９は、ＰＤＣＰフレームのフォーマットの一例を示す図である。
【図３０】図３０は、実施の形態５にかかる受信ノードの動作の一例を示すフローチャートである。
【図３１】図３１は、図３０に示した動作による通話状態判定の具体例を示す図である。
【図３２】図３２は、実施の形態６にかかる受信ノードの構成例を示すブロック図である。
【図３３】図３３は、実施の形態６にかかる送信ノードの構成例を示すブロック図である。
【図３４】図３４は、Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへの切替の具体例を示す図である。
【図３５】図３５は、Ｕ−ｍｏｄｅからＲ−ｍｏｄｅへの切替の具体例を示す図である。
【図３６】図３６は、Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへの切替の具体例を示す図である。
【発明を実施するための形態】
【００１４】
以下に添付図面を参照して、この受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法の好適な実施の形態を詳細に説明する。
【００１５】
（実施の形態１）
（受信ノードの構成例）
図１は、実施の形態１にかかる受信ノードの構成例を示すブロック図である。図１に示す受信ノード１００は、実施の形態にかかる受信装置をＬＴＥシステムにおけるＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ユーザ端末）に適用した例である。受信ノード１００は、ＭＡＣレイヤ終端部１１０と、ＲＬＣレイヤ終端部１２０と、ＰＤＣＰ終端部１３０と、ＲＴＰ／ＵＤＰ／ＩＰ終端部１４０と、ＡＭＲ終端部１５０と、を備えている。
【００１６】
ＭＡＣレイヤ終端部１１０は、送信ノード（図２参照）との間の通信におけるＭＡＣレイヤの機能を終端する。たとえば、ＭＡＣレイヤ終端部１１０は、送信ノードから送信された音声データまたは制御データに対する誤り訂正や再送制御を行う。ＲＬＣレイヤ終端部１２０は、送信ノードとの間の通信におけるＲＬＣレイヤの機能を終端する。
【００１７】
ＰＤＣＰ終端部１３０は、送信ノードとの間の通信におけるＰＤＣＰレイヤの機能を終端する。また、ＰＤＣＰ終端部１３０は、送信ノードとの間の通信におけるＲＯＨＣレイヤの機能を終端する。具体的には、ＰＤＣＰ終端部１３０は、受信バッファ１３１と、受信処理部１３２と、伸張部１３３と、通話状態判定部１３４と、ＲＯＨＣ制御部１３５と、送信処理部１３６と、を備えている。
【００１８】
受信バッファ１３１は、ＭＡＣレイヤ終端部１１０およびＲＬＣレイヤ終端部１２０を介して受信したＰＤＣＰ＿ＰＤＵを一時格納する。受信処理部１３２（受信手段）は、受信バッファ１３１に格納されたＰＤＣＰ＿ＰＤＵを読み出してヘッダ処理を行い、ヘッダ処理を行ったデータを伸張部１３３へ出力する。受信処理部１３２によって読み出されたＰＤＣＰ＿ＰＤＵは受信バッファ１３１から消去される。
【００１９】
伸張部１３３は、受信処理部１３２から出力されたデータのＲＯＨＣのヘッダ伸張を行う。そして、伸張部１３３は、ＲＯＨＣのヘッダ伸張を行ったデータをＲＴＰ／ＵＤＰ／ＩＰ終端部１４０へ出力する。また、伸張部１３３は、ＲＯＨＣ制御部１３５によって切り替えられる動作モードに応じてＲＯＨＣのヘッダ伸張を行う。
【００２０】
通話状態判定部１３４（判定手段）は、受信ノード１００が送信ノードから受信した音声データの通話状態を判定し、判定結果をＲＯＨＣ制御部１３５へ通知する。通話状態判定部１３４が判定する通話状態は、たとえば、音声データが示す音声が「有音」であるか「無音」であるかに関する状態である。通話状態判定部１３４は、たとえば、受信バッファ１３１の滞留データ量に基づいて通話状態を判定する。
【００２１】
具体的には、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、受信バッファ１３１の滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。音声データの量と比較する閾値は、たとえば、通話状態が「無音」である場合に送信ノードから送信されるＳＩＤデータ（Ｓｉｌｅｎｃｅ  Ｉｎｓｅｒｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ）のサイズに相当する値である。
【００２２】
ＲＯＨＣ制御部１３５（制御手段）は、通話状態判定部１３４から出力された判定結果に応じて、受信ノード１００および送信ノードにおけるＲＯＨＣの動作モードを切り替える。たとえば、ＲＯＨＣ制御部１３５は、受信ノード１００および送信ノードにおけるＲＯＨＣの動作モードを、Ｕ−ｍｏｄｅ、Ｏ−ｍｏｄｅおよびＲ−ｍｏｄｅのいずれかに切り替える。これらのＲＯＨＣの各動作については後述する（図５〜図８参照）。
【００２３】
ＲＯＨＣ制御部１３５は、ＲＯＨＣの動作モードを切り替えるために、切り替える動作モードを示す切替指示信号を生成する。そして、ＲＯＨＣ制御部１３５は、生成した切替指示信号を送信処理部１３６へ出力する。これにより、切替指示信号が送信ノードへ送信され、ＲＯＨＣの動作モードが切り替わる。
【００２４】
送信処理部１３６は、ＰＤＣＰ＿ＰＤＵへのヘッダ付与を行う。たとえば、送信処理部１３６は、ＲＯＨＣ制御部１３５から出力された切替指示信号にヘッダを付与する。そして、送信処理部１３６は、ヘッダを付与した切替指示信号を、ＭＡＣレイヤ終端部１１０およびＲＬＣレイヤ終端部１２０を介して送信ノードへ送信する。
【００２５】
ＲＴＰ／ＵＤＰ／ＩＰ終端部１４０は、送信ノードとの間の通信におけるＲＴＰ／ＵＤＰ／ＩＰレイヤの機能を終端する。ＡＭＲ終端部１５０は、送信ノードとの間の通信におけるＡＭＲレイヤの機能を終端する。たとえば、ＡＭＲ終端部１５０は、送信ノードから受信した音声データの復号を行う。
【００２６】
図１においては、送信ノード（ｅＮＢ）から送信された音声データを受信ノード１００（ＵＥ）が受信するダウンリンクに関する機能について説明した。ただし、受信ノード１００は、受信ノード１００（ＵＥ）が送信ノード（ｅＮＢ）へ音声データを送信するアップリンクに関する機能を備えていてもよい。
【００２７】
図１に示した通話状態判定部１３４は、通話状態の判定結果を受信ノード１００のメモリ（不図示）に書き込む。通話状態判定部１３４は、たとえばＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などの演算手段である。ＲＯＨＣ制御部１３５は、通話状態判定部１３４によって受信ノード１００のメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じてＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部１３５は、たとえばＣＰＵなどの演算手段である。
【００２８】
（送信ノードの構成例）
図２は、実施の形態１にかかる送信ノードの構成例を示すブロック図である。図２に示す送信ノード２００は、実施の形態にかかる送信装置をＬＴＥシステムにおけるｅＮＢに適用した例である。送信ノード２００は、ＰＤＣＰ終端部２１０と、ＲＬＣレイヤ終端部２２０と、ＭＡＣレイヤ終端部２３０と、を備えている。
【００２９】
ＰＤＣＰ終端部２１０は、受信ノード１００との間の通信におけるＰＤＣＰレイヤの機能を終端する。また、ＰＤＣＰ終端部２１０は、受信ノード１００との間の通信におけるＲＯＨＣレイヤの機能を終端する。具体的には、ＰＤＣＰ終端部２１０は、送信バッファ２１１と、圧縮部２１２と、送信処理部２１３と、受信処理部２１４と、を備えている。
【００３０】
送信バッファ２１１は、送信ノード２００の上位のシステム（たとえばＳ−ＧＷ＿ＩＦ）から送信されたＰＤＣＰ＿ＳＤＵを一時格納する。圧縮部２１２は、送信バッファ２１１に格納されたＰＤＣＰ＿ＳＤＵを読み出してヘッダ圧縮を行い、ヘッダ圧縮を行ったＰＤＣＰ＿ＳＤＵを送信処理部２１３へ出力する。
【００３１】
圧縮部２１２によって読み出されたＰＤＣＰ＿ＳＤＵは送信バッファ２１１から消去される。また、圧縮部２１２は、送信ノード２００において設定されているＲＯＨＣの動作モードによってヘッダ圧縮を行う。具体的には、圧縮部２１２は、受信ノード１００から受信したＲＯＨＣの動作モードの切替指示信号を受信処理部２１４から取得する。そして、圧縮部２１２は、取得した切替指示信号が示す動作モードによってヘッダ圧縮を行う。
【００３２】
送信処理部２１３は、圧縮部２１２から出力されたＰＤＣＰ＿ＳＤＵにＰＤＣＰヘッダを付与しＰＤＣＰ＿ＰＤＵとして、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。受信処理部２１４は、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００から受信したＰＤＣＰ＿ＰＤＵのヘッダ処理を行う。
【００３３】
たとえば、受信処理部２１４は、受信ノード１００から受信した切替指示信号のヘッダ処理を行って圧縮部２１２へ出力する。ＲＬＣレイヤ終端部２２０は、受信ノード１００との間の通信におけるＲＬＣレイヤの機能を終端する。ＭＡＣレイヤ終端部２３０は、受信ノード１００との間の通信におけるＭＡＣレイヤの機能を終端する。
【００３４】
図２においては、送信ノード２００（ｅＮＢ）から送信された音声データを受信ノード１００（ＵＥ）が受信するダウンリンクに関する機能について説明した。ただし、送信ノード２００は、受信ノード１００（ＵＥ）が送信ノード２００（ｅＮＢ）へ音声データを送信するアップリンクに関する機能を備えていてもよい。
【００３５】
（通信システムの構成例）
図３は、実施の形態１にかかる通信システムの構成例を示す図である。図３に示す通信システム３００は、実施の形態にかかる通信システムをＬＴＥシステムに適用した例である。通信システム３００は、ＭＭＥ／Ｓ−ＧＷ３１１，３１２と、ｅＮＢ３２１〜３２３と、ＵＥ３３１，３３２と、を含んでいる。
【００３６】
ＭＭＥ／Ｓ−ＧＷ３１１，３１２のそれぞれは、ＬＴＥシステムにおけるＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）およびＳ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）の機能を備えている。ＭＭＥ／Ｓ−ＧＷ３１１，３１２のそれぞれは、ｅＮＢ３２１〜３２３のそれぞれとＳ１インターフェースによって接続されている。
【００３７】
ｅＮＢ３２１〜３２３のそれぞれは、ＬＴＥシステムのＥ−ＵＴＲＡＮ＿ＮｏｄｅＢである。ｅＮＢ３２１〜３２３は、Ｘ２インターフェースによって互いに接続されている。また、ｅＮＢ３２１〜３２３のそれぞれは、無線通信によってＵＥ３３１，３３２との間で音声通信を行う。ＵＥ３３１，３３２のそれぞれは、携帯電話などの移動端末である。
【００３８】
図１に示した受信ノード１００は、たとえばＵＥ３３１，３３２の少なくともいずれかに適用することができる。また、図２に示した送信ノード２００は、たとえばｅＮＢ３２１〜３２３の少なくともいずれかに適用することができる。
【００３９】
また、図１に示した受信ノード１００を、ｅＮＢ３２１〜３２３の少なくともいずれかに適用し、図２に示した送信ノード２００をＵＥ３３１，３３２の少なくともいずれかに適用してもよい。この場合は、図１に示した受信ノード１００のＰＤＣＰ終端部１３０を上位のシステム（たとえばＳ−ＧＷ＿ＩＦ）に接続し、図２に示した送信ノード２００にＲＴＰ／ＵＤＰ／ＩＰ終端部１４０およびＡＭＲ終端部１５０（図１参照）を備える。
【００４０】
図４は、図３に示した通信システムにおけるプロトコルスタックを示す図である。図３に示した通信システム３００において、たとえば図４に示すプロトコルスタック４００を適用する。図４に示すプロトコルスタック４００は、音声通信などのリアルタイムデータのＩＰ化に関してＬＴＥにおいて検討されているプロトコルスタックである。
【００４１】
図４において、ＵＥ４１１は、図３に示したＵＥ３３１，３３２である。ｅＮＢ４１２は、図３に示したｅＮＢ３２１〜３２３である。Ｓ−ＧＷ４１３は、図３に示したＭＭＥ／Ｓ−ＧＷ３１１，３１２である。ＰＤＮ−ＧＷ４１４およびＩＰ網４１５は、図３に示したＭＭＥ／Ｓ−ＧＷ３１１，３１２に接続されている。
【００４２】
プロトコルスタック４００において、「ＰＨＹ」および「Ｅｔｈｅｒ」は、それぞれ物理レイヤ（Ｐｈｙｓｉｃａｌ）およびイーサネット（登録商標）を示している。「ＰＨＹ」および「Ｅｔｈｅｒ」は、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：構内通信網）およびＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：広域通信網）の基本インターフェースとして規定されているものを使用する。
【００４３】
「ＩＰ」（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）は、インターネットで使用するレイヤ３である。「ＩＰ」は、データのルーティング機能を提供する。「ＵＤＰ」（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）は、コネクションレス型の転送プロトコルである。「ＲＴＰ」（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）は、リアルタイムメディア転送のためのフレームワークを提供する。「ＲＴＰ」は、プロファイルやペイロードフォーマットをアプリケーションに合わせて使用する。
【００４４】
「ＧＴＰ−Ｕ」（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）は、ＬＴＥ／ＳＡＥ網内においてユーザデータをトンネリングさせる。「ＭＡＣ」（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）は、スケジューリング、プライオリティ制御、ＨＡＲＱ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）によるエラー訂正およびトランスフォーマットの選択などを行う。
【００４５】
「ＲＬＣ」（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）は、ＡＲＱ（Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）によるエラー訂正などを行う。「ＰＤＣＰ」（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）は、ヘッダ圧縮（ＲＯＨＣ）などを行う。
【００４６】
ダウンリンク（ｅＮＢ→ＵＥ）を例にとると、ＩＰ網４１５側からＲＴＰ／ＵＤＰ／ＩＰを介して送信されてくる音声データ（ＡＭＲ）は、ｅＮＢ４１２において終端されるＰＤＣＰの機能であるＲＯＨＣによって、ＲＴＰ／ＵＤＰ／ＩＰのヘッダが圧縮される。ヘッダが圧縮されＵＥ４１１まで伝送された音声データは、ＵＥ４１１においてＰＤＣＰが終端される際にＲＯＨＣによってヘッダが伸張され、元の音声データに復元される。
【００４７】
（ＲＯＨＣの各動作モード）
図５は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その１）である。図５において、横軸は時間を示している。ＲＴＰ／ＵＤＰ／ＩＰのレイヤにおいて、送信ノード２００が２０［ｍｓｅｃ］の周期のフレームによって音声データを受信ノード１００へ送信する場合について説明する。非圧縮フレーム５１１は、送信ノード２００がヘッダ圧縮を行わずに送信した（コンテキストを含む）音声データである。圧縮フレーム５１２は、送信ノード２００がヘッダ圧縮を行って送信した（コンテキストを含まない）音声データである。
【００４８】
非圧縮フレーム５１１および圧縮フレーム５１２の横軸と直交する方向（図の縦方向）の長さは、各フレームのサイズを示している。圧縮フレーム５１２は、ヘッダ圧縮が行われているため、ヘッダ圧縮が行われていない非圧縮フレーム５１１よりもサイズが小さくなっている。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ−ｍｏｄｅ（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｍｏｄｅ）に設定されている。
【００４９】
具体的には、送信ノード２００は、２０［ｍｓｅｃ］単位で各フレームを送信する。送信ノード２００は、送信する各フレームのうちの、１８０［ｍｓｅｃ］単位で送信するフレームは非圧縮フレーム５１１とし、それ以外のフレームは圧縮フレーム５１２とする。
【００５０】
受信ノード１００は、圧縮フレーム５１２のヘッダを、以前に受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて伸張（復元）しながら各フレームを受信する。たとえば、受信ノード１００は、時期ｔ５２１において受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて、時期ｔ５２１の直後の期間Ｔ５２２において受信した各圧縮フレーム５１２のヘッダを伸張する。
【００５１】
このように、ＲＯＨＣのＵ−ｍｏｄｅにおいては、送信ノードが一定周期でコンテキストを送信することにより通信の品質保証を行う。この場合は、受信ノード１００からコンテキスト（非圧縮フレーム５１１）を要求するフィードバックを行わない。このため、受信ノード１００から送信ノード２００へのリンクの帯域を圧迫しない。
【００５２】
図６は、ＲＯＨＣのＵ−ｍｏｄｅの動作を示す図（その２）である。図６において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ＲＯＨＣの動作モードがＵ−ｍｏｄｅである場合（図５参照）で、時期ｔ６１１において非圧縮フレーム５１１が正常に受信ノード１００に受信されなかったとする。
【００５３】
この場合は、時期ｔ６１１の直後の期間Ｔ６１２において受信する各圧縮フレーム５１２については、ＰＤＣＰのレイヤで破棄され、ヘッダの伸張を正常に行うことができない。このため、期間Ｔ６１２において受信する各圧縮フレーム５１２はデータロスとなり、音声品質が劣化する。この場合は、たとえば、一時的に音声が不通になる。
【００５４】
各圧縮フレーム５１２がデータロスとなる期間は、つぎに受信ノード１００が非圧縮フレーム５１１を受信してコンテキストが回復されるまで継続する。このため、各圧縮フレーム５１２がデータロスとなる期間は、送信ノード２００がコンテキスト（非圧縮フレーム５１１）を送信する周期（ここでは１８０［ｍｓｅｃ］）に依存する。
【００５５】
図７は、ＲＯＨＣのＯ−ｍｏｄｅの動作を示す図である。図７において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＯ−ｍｏｄｅ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ  Ｏｐｔｉｍｉｓｔｉｃ  Ｍｏｄｅ）に設定されている。
【００５６】
送信ノード２００は、２０［ｍｓｅｃ］単位で送信する各フレームのうちの、ヘッダの内容が前のフレームから変更になったフレームは非圧縮フレーム５１１とし、それ以外のフレームは圧縮フレーム５１２として送信する。受信ノード１００は、圧縮フレーム５１２のヘッダを、以前に受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて伸張（復元）しながら各フレームを受信する。
【００５７】
また、受信ノード１００は、非圧縮フレーム５１１を正常に受信することができなかった場合に、送信ノード２００に対してＮａｃｋを送信する。たとえば、時期ｔ７１１において、受信ノード１００が非圧縮フレーム５１１を正常に受信できず、時期ｔ７１１の直後の時期ｔ７１２において送信ノード２００へＮａｃｋ７０１を送信したとする。
【００５８】
送信ノード２００は、受信ノード１００からＮａｃｋ７０１を受信すると、非圧縮フレーム５１１を再送する。受信ノード１００は、時期ｔ７１２の後の時期ｔ７１３において、送信ノード２００から再送された非圧縮フレーム５１１を受信したとする。
【００５９】
非圧縮フレーム５１１が受信できなかった時期ｔ７１１から非圧縮フレーム５１１を受信した時期ｔ７１３の間の期間Ｔ７２０において受信した各圧縮フレーム５１２については、ＰＤＣＰのレイヤで破棄され、ヘッダの伸張を正常に行うことができない。このため、期間Ｔ７２０において受信する各圧縮フレーム５１２はデータロスとなる。
【００６０】
各圧縮フレーム５１２がデータロスとなる期間は、つぎに受信ノード１００が非圧縮フレーム５１１を受信してコンテキストが回復されるまで継続する。このため、各圧縮フレーム５１２がデータロスとなる期間は、受信ノード１００が送信ノード２００へＮａｃｋを送信し、送信ノード２００が受信ノード１００へ非圧縮フレーム５１１を再送するまでの期間に依存する。
【００６１】
このように、ＲＯＨＣのＯ−ｍｏｄｅにおいては、受信ノード１００からのフィードバックを行うことにより通信の品質保証を行う。コンテキスト（非圧縮フレーム５１１）は、受信ノード１００がフレームを正常に受信できなかった場合に送信されるため、圧縮フレーム５１２の送信頻度が高く、ヘッダ圧縮効率が優れている。
【００６２】
図８は、ＲＯＨＣのＲ−ｍｏｄｅの動作を示す図である。図８において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＲ−ｍｏｄｅ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ  Ｒｅｌｉａｂｌｅ  Ｍｏｄｅ）に設定されている。
【００６３】
送信ノード２００は、２０［ｍｓｅｃ］単位で非圧縮フレーム５１１を送信する。そして、送信ノード２００は、非圧縮フレーム５１１に対するＡｃｋを受信ノード１００から受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。
【００６４】
受信ノード１００は、非圧縮フレーム５１１を正常に受信した場合に、送信ノード２００に対してＡｃｋを送信する。たとえば、時期ｔ８１１において、受信ノード１００が非圧縮フレーム５１１を正常に受信して送信ノード２００へＡｃｋ８０１を送信したとする。送信ノード２００は、受信ノード１００からＡｃｋ８０１を受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。
【００６５】
また、時期ｔ８１１の後の時期ｔ８１２において、受信ノード１００が非圧縮フレーム５１１を正常に受信できなかったとする。そして、時期ｔ８１２の直後の時期ｔ８１３において、受信ノード１００が非圧縮フレーム５１１を正常に受信して送信ノード２００へＡｃｋ８０２を送信したとする。送信ノード２００は、受信ノード１００からＡｃｋ８０２を受信するまでは非圧縮フレーム５１１を送信し、受信ノード１００からＡｃｋ８０２を受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。
【００６６】
このように、ＲＯＨＣのＲ−ｍｏｄｅにおいては、送信ノード２００は、コンテキストが受信ノード１００へ正常に到達したことを示すＡｃｋを受信するとヘッダ圧縮を開始する。このため、ＲＯＨＣのＲ−ｍｏｄｅは、Ｕ−ｍｏｄｅやＯ−ｍｏｄｅに比べてヘッダ圧縮効率は劣る一方、コンテキスト維持の信頼性が優れている。また、コンテキスト喪失時の以降のヘッダ伸張不可に伴うデータロス時間は発生しない。
【００６７】
図５〜図８に示したＲＯＨＣの各動作モード間の切替は、受信ノード１００から送信ノード２００へ切替指示信号を送信することによって行う。ＲＯＨＣの各動作モード間の切替の具体例については後述する（図３４〜図３６参照）。
【００６８】
（通話状態の変化）
図９は、通話状態の変化の一例を示す図である。図９において、横軸は時間を示している。符号９１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。符号９２０は、受信ノード１００から送信ノード２００へ送信される音声データを示している。人物Ａは、送信ノード２００側のユーザを示している。人物Ｂは、受信ノード１００側のユーザを示している。
【００６９】
ＡＭＲデータ９１１は、音声を伝送するときに送信される。ＳＩＤデータ９１２は、伝送する音声がない場合に送信される。ＡＭＲデータ９１１およびＳＩＤデータ９１２において、横軸に直交する方向（図の縦方向）の長さはデータのサイズを示している。図９に示すように、ＳＩＤデータ９１２はＡＭＲデータ９１１よりサイズが小さい。
【００７０】
区間９３１〜９３４は、時間的に連続する時間区間である。送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）の通話状態は、区間９３１および区間９３３においては「有音」となっている。また、送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）の通話状態は、区間９３２および区間９３４においては「無音」となっている。
【００７１】
一方、受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）の通話状態は、区間９３１および区間９３３においては「無音」となっている。また、受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）の通話状態は、区間９３２および区間９３４においては「有音」となっている。
【００７２】
口論のようなケースを例外とすれば、一般的な通話においては人物Ａと人物Ｂとが交互に発言する。このため、送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）および受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）において、通話状態が「有音」の区間と「無音」の区間とが存在する。
【００７３】
通話状態が「有音」の区間においては、ヘッダ伸張不可などによりＰＤＣＰでＡＭＲデータ９１１が破棄されると音声品質の劣化に繋がる。一方で、通話状態が「無音」の区間においては、ＳＩＤデータ９１２はユーザの音声を示すデータではないため、ＰＤＣＰにおいてＳＩＤデータ９１２が破棄されても通話に影響しない。
【００７４】
このことを利用して、受信ノード１００および送信ノード２００は、音声データの通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替える。これにより、通話状態が「有音」のときは音質の向上を図り、通話状態が「無音」のときはヘッダ圧縮の効率化を図ることができる。
【００７５】
（各データのフレームフォーマット）
図１０は、ＭＡＣ＿ＰＤＵの一例を示す図である。受信ノード１００と送信ノード２００との間で送受信される音声データのＭＡＣレイヤのフレームフォーマットは、たとえば図１０に示すＭＡＣ＿ＰＤＵ１０００のようにする。ＭＡＣ＿ＰＤＵ１０００は、ＬＴＥシステムにおいてＰＤＣＰの下位レイヤに位置するＭＡＣフレームフォーマットである。
【００７６】
ＭＡＣ＿ＰＤＵ１０００には、ＭＡＣ＿Ｈｅａｄｅｒ１０１０と、ＭＡＣ＿Ｐａｙｌｏａｄ１０２０と、が含まれている。ＭＡＣ＿Ｐａｙｌｏａｄ１０２０には、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１（図１１参照）と、ＭＡＣ＿ＳＤＵ１０２２と、Ｐａｄｄｉｎｇ１０２３と、が含まれている。
【００７７】
図１１は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔを示す図である。図１１に示すテーブル１１００は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の各種別を示している。
【００７８】
送信ノード２００から受信ノード１００へ送信される音声データ（ｅＮＢ→ＵＥ）の場合は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の種別には、「ＵＥ  Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ  Ｉｄｅｎｔｉｔｙ」と、「Ｔｉｍｉｎｇ  Ａｄｖａｎｃｅ」と、「ＤＲＸ  Ｃｏｍｍａｎｄ」と、が含まれている。
【００７９】
また、受信ノード１００から送信ノード２００へ送信される音声データ（ＵＥ→ｅＮＢ）の場合は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の種別には、「Ｐｏｗｅｒ  Ｈｅａｄｒｏｏｍ  Ｒｅｐｏｒｔ」と、「Ｃ−ＲＮＴＩ」と、「Ｓｈｏｒｔ＿ＢＳＲ」と、「Ｌｏｎｇ＿ＢＳＲ」と、が含まれている。
【００８０】
「Ｓｈｏｒｔ＿ＢＳＲ」および「Ｌｏｎｇ＿ＢＳＲ」は、バッファに滞留したデータ量を示している。したがって、送信ノード２００は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１に含まれる「Ｓｈｏｒｔ＿ＢＳＲ」または「Ｌｏｎｇ＿ＢＳＲ」によって送信バッファ２１１の滞留データ量を受信ノード１００へ通知することができる。
【００８１】
図１２は、図１１に示したＳｈｏｒｔ＿ＢＳＲを示す図である。図１１に示した「Ｓｈｏｒｔ＿ＢＳＲ」のフレームフォーマットは、たとえばＳｈｏｒｔ＿ＢＳＲ１２００のようにする。Ｓｈｏｒｔ＿ＢＳＲ１２００には、ＬＣＧ＿ＩＤ１２１０（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ  Ｇｒｏｕｐ）と、バッファサイズ１２２０と、が含まれている。
【００８２】
ＬＣＧ＿ＩＤ１２１０は、各論理チャネルグループ（たとえば論理チャネルグループ＃１〜＃４）を示すＩＤである。バッファサイズ１２２０は、ＬＣＧ＿ＩＤ１２１０が示す各論理チャネルグループの全滞留データ量を示している。バッファサイズ１２２０の具体例については後述する（図１４参照）。
【００８３】
図１３は、図１１に示したＬｏｎｇ＿ＢＳＲを示す図である。図１１に示した「Ｌｏｎｇ＿ＢＳＲ」のフレームフォーマットは、たとえばＬｏｎｇ＿ＢＳＲ１３００のようにする。Ｌｏｎｇ＿ＢＳＲ１３００には、各バッファサイズ＃１〜＃４が含まれている。各バッファサイズ＃１〜＃４は、各ＵＥに対する全滞留データ量を示している。各バッファサイズ＃１〜＃４の具体例については後述する（図１４参照）。
【００８４】
図１４は、バッファサイズのインデクスを示す図である。図１２に示したバッファサイズ１２２０または図１３に示した各バッファサイズ＃１〜＃４は、たとえば図１４に示すテーブル１４００に基づくインデクスによって示される。たとえば、バッファサイズ（ＢＳ）０［Ｂｙｔｅｓ］は、インデクス「０」によって示される。
【００８５】
また、０［Ｂｙｔｅｓ］より大きく１０［Ｂｙｔｅｓ］以下のバッファサイズはインデクス「１」によって示される。また、１０［Ｂｙｔｅｓ］より大きく１２［Ｂｙｔｅｓ］以下のバッファサイズはインデクス「２」によって示される。このように、上述したデータ量情報を示すバッファサイズをインデクスによって示すことで、データ量情報のサイズを小さくすることができる。
【００８６】
図１５は、データＰＤＵのフォーマットの一例を示す図である。受信ノード１００と送信ノード２００との間で送受信されるデータＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図１５に示すＰＤＣＰフレーム１５００のようにする。ＰＤＣＰフレーム１５００には、Ｄ／Ｃ１５１０と、Ｒ１５２０（Ｒｅｓｅｒｖｅｄ）と、ＰＤＣＰシーケンスナンバ１５３０と、データ１５４０と、が含まれている。
【００８７】
Ｄ／Ｃ１５１０は、ＰＤＣＰフレーム１５００がデータＰＤＵおよびコントロールＰＤＵのいずれであるかを示す値である。ＰＤＣＰフレーム１５００においては、Ｄ／Ｃ１５１０は、データＰＤＵを示す「１」となる。Ｒ１５２０はここでは使用しない。ＰＤＣＰシーケンスナンバ１５３０は、ＰＤＣＰフレーム１５００のシーケンスナンバである。データ１５４０は、たとえば上述したＡＭＲデータ９１１やＳＩＤデータ９１２である。
【００８８】
図１６は、コントロールＰＤＵのフォーマットの一例を示す図である。図１６において、図１５に示した部分と同様の部分については同一の符号を付して説明を省略する。受信ノード１００と送信ノード２００との間で送受信されるコントロールＰＤＵのＰＤＣＰのヘッダは、たとえば図１６に示すＰＤＣＰフレーム１６００のようにする。
【００８９】
ＰＤＣＰフレーム１６００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、Ｒ１５２０と、Ｉｎｔｅｒｓｐｅｒｓｅｄ＿ＲＯＨＣ＿ｆｅｅｄｂａｃｋ＿ｐａｃｋｅｔ１６２０と、が含まれている。ＰＤＣＰフレーム１６００においては、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。ＰＤＵタイプ１６１０は、コントロールＰＤＵの種別（ＰＤＣＰステータスレポートやヘッダ圧縮フィードバック情報）を示している。
【００９０】
（受信ノードの動作）
図１７は、図１に示した受信ノードの動作の一例を示すフローチャートである。図１に示した受信ノード１００は、図１７に示す各ステップを行う。まず、受信ノード１００の通話状態判定部１３４が、受信ノード１００が送信ノード２００から受信する音声データの通話状態（「有音」または「無音」）を判定する（ステップＳ１７０１）。
【００９１】
つぎに、通話状態判定部１３４が、ステップＳ１７０１によって判定された通話状態が、通話状態判定部１３４によって前回判定された通話状態から変化したか否かを判断する（ステップＳ１７０２）。通話状態が変化していない場合（ステップＳ１７０２：Ｎｏ）は、ステップＳ１７０１へ戻って処理を続行する。
【００９２】
ステップＳ１７０２において、通話状態が変化した場合（ステップＳ１７０２：Ｙｅｓ）は、ＲＯＨＣ制御部１３５が、ステップＳ１７０１によって判定された通話状態に応じてＲＯＨＣの動作モードを切り替え（ステップＳ１７０３）、一連の動作を終了する。ステップＳ１７０３において、通話状態が「無音」である場合は、ＲＯＨＣ制御部１３５は、たとえばＲＯＨＣの動作モードをヘッダ圧縮の頻度が高いＵ−ｍｏｄｅに切り替える。
【００９３】
ステップＳ１７０３において、通話状態が「有音」である場合は、ＲＯＨＣ制御部１３５は、たとえばＲＯＨＣの動作モードをヘッダ圧縮の頻度が低いＯ−ｍｏｄｅやＲ−ｍｏｄｅに切り替える。これにより、通話状態が「有音」のときは音質の向上を図り、通話状態が「無音」のときはヘッダ圧縮の効率化を図ることができる。
【００９４】
図１８は、図１７に示したステップＳ１７０１の具体例を示すフローチャートである。図１７に示したステップＳ１７０１において、通話状態判定部１３４は、たとえば以下の各ステップを実行する。まず、この動作を開始してからの経過時間が監視周期（たとえば２０［ｍｓｅｃ］）以上になったか否かを判断し（ステップＳ１８０１）、経過時間が監視周期以上になるまで待つ（ステップＳ１８０１：Ｎｏのループ）。
【００９５】
ステップＳ１８０１において、経過時間が監視周期以上になると（ステップＳ１８０１：Ｙｅｓ）、受信バッファ１３１の滞留データ量を測定する（ステップＳ１８０２）。つぎに、通話状態判定部１３４による前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ１８０３）。
【００９６】
ステップＳ１８０３において、通話状態が「有音」である場合（ステップＳ１８０３：Ｙｅｓ）は、ステップＳ１８０２によって測定された滞留データ量が閾値以下か否かを判断する（ステップＳ１８０４）。滞留データ量が閾値以下でない場合（ステップＳ１８０４：Ｎｏ）は、一連の処理を終了する。
【００９７】
ステップＳ１８０４において、ステップＳ１８０２によって測定された滞留データ量が閾値以下である場合（ステップＳ１８０４：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新し（ステップＳ１８０５）、一連の処理を終了する。
【００９８】
ステップＳ１８０３において、通話状態が「有音」でない場合（ステップＳ１８０３：Ｎｏ）は、ステップＳ１８０２によって測定された滞留データ量が閾値より大きいか否かを判断する（ステップＳ１８０６）。滞留データ量が閾値より大きくない場合（ステップＳ１８０６：Ｎｏ）は、一連の処理を終了する。
【００９９】
ステップＳ１８０６において、ステップＳ１８０２によって測定された滞留データ量が閾値より大きい場合（ステップＳ１８０６：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新し（ステップＳ１８０７）、一連の処理を終了する。ステップＳ１８０４およびステップＳ１８０６において比較に用いる閾値は、たとえば図９に示したＳＩＤデータ９１２のサイズに相当する閾値である。
【０１００】
（ＲＯＨＣの動作モード切替）
図１９は、ＲＯＨＣの動作モード切替の一例を示す図である。図１９において、横軸は時間を示している。符号１９１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。ＡＭＲデータ１９１１は、音声を伝送するとき（有音）に送信される。ＳＩＤデータ１９１２は、伝送する音声がないとき（無音）に送信される。
【０１０１】
区間１９２１〜１９２４は、時間的に連続する時間区間である。区間１９２１および区間１９２３は、通話状態が「有音」となっており、ＡＭＲデータ１９１１が送信されている。区間１９２２および区間１９２４は、通話状態が「無音」となっており、ＳＩＤデータ１９１２が送信されている。
【０１０２】
符号１９３０は、受信ノード１００によるＲＯＨＣの動作モードの切替を示している。符号１９３０に示すように、受信ノード１００は、区間１９２１および区間１９２３においては通話状態を「有音」と判定する。そして、受信ノード１００は、区間１９２１および区間１９２３においてはＲＯＨＣの動作モードをＲ−ｍｏｄｅ（たとえばＯ−ｍｏｄｅでもよい）に切り替える。また、受信ノード１００は、区間１９２２および区間１９２４においては通話状態を「無音」と判定する。そして、受信ノード１００は、区間１９２２および区間１９２４においてはＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える。
【０１０３】
これにより、通話状態が「無音」である区間１９２２および区間１９２４においては、ＲＯＨＣの動作モードをヘッダ圧縮の頻度が高いＵ−ｍｏｄｅにし、無線帯域の利用効率を向上させることができる。一方、通話状態が「有音」である区間１９２１および区間１９２３においては、ＲＯＨＣの動作モードをヘッダ圧縮の頻度が低いＲ−ｍｏｄｅにすることで、音声品質を向上させることができる。
【０１０４】
このように、実施の形態１にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
【０１０５】
また、受信バッファ１３１の滞留データ量を測定し、測定した滞留データ量に基づいて通話状態を判定することができる。たとえば、測定した滞留データ量を閾値と比較することによって通話状態（「有音」または「無音」）を容易に判定することができる。
【０１０６】
（実施の形態２）
実施の形態２においては、ＬＴＥシステムにおいて送信ノード２００が受信ノード１００へ送信するＢＳＲを用いて通話状態の判定を行う。上述したように、送信ノード２００が受信ノード１００へ送信するＭＡＣ＿ＰＤＵ（図１０参照）のＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔには、送信ノード２００の送信バッファ２１１の滞留データ量を示すＢＳＲ（図１１〜図１３参照）が含まれている。
【０１０７】
（受信ノードの構成例）
図２０は、実施の形態２にかかる受信ノードの構成例を示すブロック図である。図２０において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。図２０に示すように、実施の形態２にかかる受信ノード１００のＭＡＣレイヤ終端部１１０は、受信処理部２０１１と、ＭＣＥ終端部２０１２と、送信処理部２０１３と、を備えている。受信処理部２０１１は、ＭＡＣレイヤにおける受信処理を行う。
【０１０８】
受信処理部２０１１は、受信処理を行った各データをＲＬＣレイヤ終端部１２０およびＭＣＥ終端部２０１２へ出力する。ＭＣＥ終端部２０１２は、ＭＣＥ（ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ）を終端する。たとえば、ＭＣＥ終端部２０１２は、受信処理部２０１１から出力されたデータに含まれるＢＳＲ（図１１〜図１３参照）を取得する。
【０１０９】
ＢＳＲは、送信ノード２００における送信バッファ２１１の滞留データ量を示している。ＭＣＥ終端部２０１２は、取得したＢＳＲを滞留データ量としてＰＤＣＰ終端部１３０へ出力する。送信処理部２０１３は、ＭＡＣレイヤにおける送信処理を行う。送信処理部２０１３は、送信処理を行った各データを送信ノード２００へ送信する。
【０１１０】
ＰＤＣＰ終端部１３０の通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量に基づいて通話状態を判定する。具体的には、通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量が閾値より大きい場合は通話状態を「有音」と判定する。また、通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。
【０１１１】
（送信ノードの構成例）
図２１は、実施の形態２にかかる送信ノードの動作の一例を示すフローチャートである。図２０に示した受信ノード１００の基本的な動作については、図１７に示した動作と同様である。また、図２０に示した受信ノード１００の通話状態判定部１３４は、図１７に示したステップＳ１７０１において、以下の各ステップを行う。
【０１１２】
まず、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ２１０１）、経過時間が監視周期以上になるまで待つ（ステップＳ２１０１：Ｎｏのループ）。経過時間が監視周期以上になると（ステップＳ２１０１：Ｙｅｓ）、送信ノード２００から送信されたデータ量情報（ＢＳＲ）を、ＭＣＥ終端部２０１２を介して受信する（ステップＳ２１０２）。ステップＳ２１０２において受信されるデータ量情報は、送信ノード２００の送信バッファ２１１の滞留データ量を示している。
【０１１３】
つぎに、前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ２１０３）。通話状態が「有音」である場合（ステップＳ２１０３：Ｙｅｓ）は、ステップＳ２１０２によって受信されたデータ量情報が示す滞留データ量が閾値以下か否かを判断する（ステップＳ２１０４）。滞留データ量が閾値以下でない場合（ステップＳ２１０４：Ｎｏ）は、一連の処理を終了する。
【０１１４】
ステップＳ２１０４において、受信されたデータ量情報が示す滞留データ量が閾値以下である場合（ステップＳ２１０４：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新し（ステップＳ２１０５）、一連の処理を終了する。
【０１１５】
ステップＳ２１０３において、通話状態が「有音」でない場合（ステップＳ２１０３：Ｎｏ）は、ステップＳ２１０２によって受信されたデータ量情報が示す滞留データ量が閾値より大きいか否かを判断する（ステップＳ２１０６）。滞留データ量が閾値より大きくない場合（ステップＳ２１０６：Ｎｏ）は、一連の処理を終了する。
【０１１６】
ステップＳ２１０６において、受信されたデータ量情報が示す滞留データ量が閾値より大きい場合（ステップＳ２１０６：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新し（ステップＳ２１０７）、一連の処理を終了する。なお、図１４に示したようにＢＳＲのバッファサイズがインデクス化されている場合は、ステップＳ２１０４およびステップＳ２１０６において比較に用いる閾値も図１４に示したインデクスを用いる。
【０１１７】
このように、実施の形態２にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
【０１１８】
また、送信ノード２００において送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信したデータ量情報が示す滞留データ量に基づいて通話状態を判定することができる。送信ノード２００側のデータ滞留量を用いることにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。
【０１１９】
また、送信ノード２００が受信ノード１００へ送信するＭＡＣ＿ＰＤＵ（図１０参照）のＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔに含まれるＢＳＲを用いてデータ量情報を送信する。これにより、送信ノード２００から受信ノード１００へ送信する制御信号を新たに追加しなくても、データ量情報を受信ノード１００へ送信することができる。
【０１２０】
（実施の形態３）
（受信ノードの構成例）
図２２は、実施の形態３にかかる受信ノードの構成例を示すブロック図である。図２２において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態３にかかる受信ノード１００においては、図１に示した通話状態判定部１３４を省いた構成にしてもよい。
【０１２１】
受信処理部１３２は、受信バッファ１３１から読み出したデータのうちの、送信ノード２００から送信された通話状態情報をＲＯＨＣ制御部１３５へ出力する。ＲＯＨＣ制御部１３５は、受信処理部１３２から出力された通話状態情報が示す通話状態の判定結果（「有音」または「無音」）に応じてＲＯＨＣの動作モードを切り替える。
【０１２２】
（送信ノードの構成例）
図２３は、実施の形態３にかかる送信ノードの構成例を示すブロック図である。図２３において、図２に示した構成と同様の構成については同一の符号を付して説明を省略する。図２３に示すように、実施の形態３にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２に示した構成に加えて通話状態判定部２３１０を備えている。
【０１２３】
通話状態判定部２３１０は、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を判定し、判定結果を示す通話状態情報を送信処理部２１３へ出力する。通話状態判定部２３１０が判定する通話状態は、たとえば、音声データが示す音声が「有音」であるか「無音」であるかに関する状態である。通話状態判定部２３１０は、たとえば、送信バッファ２１１の滞留データ量に基づいて通話状態を判定する。
【０１２４】
具体的には、通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、送信バッファ２１１の滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。音声データの量と比較する閾値は、たとえば、通話状態が「無音」であり、送信ノード２００がＳＩＤデータを送信するときに送信バッファ２１１に滞留するＳＩＤデータの量に相当する値である。
【０１２５】
送信処理部２１３は、通話状態判定部２３１０から出力された通話状態情報を、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。これにより、受信ノード１００へ通話状態情報を送信することができる。通話状態情報を送信するためのＰＤＣＰフレームについて、図２４によって説明する。
【０１２６】
（データのフレームフォーマット）
図２４は、ＰＤＣＰフレームのフォーマットの一例を示す図である。図２４において、図１６に示した部分と同様の部分については同一の符号を付して説明を省略する。送信処理部２１３が受信ノード１００へ送信するコントロールＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図２４に示すＰＤＣＰフレーム２４００のようにする。
【０１２７】
ＰＤＣＰフレーム２４００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、Ｒ１５２０と、ＴＳＦ２４１０（Ｔｅｌｅｐｈｏｎｅ  ｃａｌｌ  Ｓｔａｔｕｓ  Ｆｌａｇ）と、が含まれている。ＰＤＣＰフレーム２４００において、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。
【０１２８】
ＴＳＦ２４１０は、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を示している。送信処理部２１３は、通話状態判定部２３１０から出力された通話状態情報を、ＰＤＣＰフレーム２４００のＴＳＦ２４１０に格納する。受信ノード１００の受信処理部１３２は、送信ノード２００から受信したＰＤＣＰフレーム２４００のＴＳＦ２４１０を通話状態情報としてＲＯＨＣ制御部１３５へ出力する。
【０１２９】
（送信ノードの動作）
図２５は、図２３に示した送信ノードの動作の一例を示すフローチャートである。図２３に示した送信ノード２００は、図２５に示す各ステップを行う。まず、送信ノード２００の通話状態判定部２３１０が、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を判定する（ステップＳ２５０１）。
【０１３０】
つぎに、通話状態判定部２３１０が、ステップＳ２５０１によって判定された通話状態が、通話状態判定部２３１０によって前回判定された通話状態から変化したか否かを判断する（ステップＳ２５０２）。通話状態が変化していない場合（ステップＳ２５０２：Ｎｏ）は、ステップＳ２５０１へ戻って処理を続行する。
【０１３１】
ステップＳ２５０２において、通話状態が変化した場合（ステップＳ２５０２：Ｙｅｓ）は、送信処理部２１３が、ステップＳ２５０１によって判定された通話状態を示す通話状態情報を受信ノード１００へ送信し（ステップＳ２５０３）、一連の処理を終了する。ステップＳ２５０３によって送信された通話状態情報は受信ノード１００によって受信される。受信ノード１００は、受信した通話状態情報が示す通話状態に応じて送信ノード２００との間のＲＯＨＣの動作モードを切り替える。
【０１３２】
図２６は、図２５に示したステップＳ２５０１の具体例を示すフローチャートである。図２５に示したステップＳ２５０１において、通話状態判定部２３１０は、たとえば以下の各ステップを実行する。まず、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ２６０１）、経過時間が監視周期以上になるまで待つ（ステップＳ２６０１：Ｎｏのループ）。
【０１３３】
ステップＳ２６０１において、経過時間が監視周期以上になると（ステップＳ２６０１：Ｙｅｓ）、送信バッファ２１１の滞留データ量を測定する（ステップＳ２６０２）。図２６に示すステップＳ２６０３〜Ｓ２６０７は、図１８に示したステップＳ１８０３〜Ｓ１８０７と同様であるため説明を省略する。
【０１３４】
このように、実施の形態３にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
【０１３５】
また、送信ノード２００において通話状態を判定し、判定結果を示す通話状態情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信した通話状態情報が示す通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。通話状態を送信ノード２００側で判定することにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。
【０１３６】
また、通話状態を送信ノード２００側で判定することにより、受信ノード１００側の処理負担を軽減することができる。また、送信ノード２００が受信ノード１００へ送信するＰＤＣＰフレーム２４００にＴＳＦ２４１０を設け、ＴＳＦ２４１０を用いて通話状態情報を送信することにより、通話状態情報を受信ノード１００へ送信することができる。
【０１３７】
（実施の形態４）
（受信ノードの構成例）
図２７は、実施の形態４にかかる受信ノードの構成例を示すブロック図である。図２７において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態４にかかる受信ノード１００の受信処理部１３２は、受信処理したデータのうちのデータ量情報を通話状態判定部１３４へ出力する。
【０１３８】
通話状態判定部１３４へ出力されるデータ量情報は、送信ノード２００における送信バッファ２１１の滞留データ量を示している。通話状態判定部１３４は、受信処理部１３２から出力されたデータ量情報が示す滞留データ量に基づいて通話状態を判定する。具体的には、通話状態判定部１３４は、滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。
【０１３９】
（送信ノードの構成例）
図２８は、実施の形態４にかかる送信ノードの構成例を示すブロック図である。図２８において、図２に示した構成と同様の構成については同一の符号を付して説明を省略する。図２８に示すように、実施の形態３にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２に示した構成に加えて滞留データ量測定部２８１０を備えている。
【０１４０】
滞留データ量測定部２８１０は、送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を送信処理部２１３へ出力する。送信処理部２１３は、滞留データ量測定部２８１０から出力されたデータ量情報を、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。これにより、受信ノード１００へデータ量情報を送信することができる。データ量情報を送信するためのＰＤＣＰフレームについて、図２９において説明する。
【０１４１】
（データのフレームフォーマット）
図２９は、ＰＤＣＰフレームのフォーマットの一例を示す図である。図２９において、図１６に示した部分と同様の部分については同一の符号を付して説明を省略する。送信ノード２００の送信処理部２１３が送信するコントロールＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図２９に示すＰＤＣＰフレーム２９００のようにする。
【０１４２】
ＰＤＣＰフレーム２９００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、ＢＳＲ２９１０と、が含まれている。ＰＤＣＰフレーム２９００においては、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。
【０１４３】
ＢＳＲ２９１０は、送信ノード２００の送信バッファ２１１の滞留データ量を示している。送信処理部２１３は、滞留データ量測定部２８１０から出力されたデータ量情報を、ＰＤＣＰフレーム２９００のＢＳＲ２９１０に格納して受信ノード１００へ送信する。受信ノード１００の受信処理部１３２は、送信ノード２００から受信したＰＤＣＰフレーム２９００のＢＳＲ２９１０を滞留データ量として通話状態判定部１３４へ出力する。
【０１４４】
このように、実施の形態４にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。
【０１４５】
また、送信ノード２００において送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信したデータ量情報が示す滞留データ量に基づいて通話状態を判定することができる。送信ノード２００側のデータ滞留量を用いることにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。
【０１４６】
また、送信ノード２００が受信ノード１００へ送信するＰＤＣＰフレーム２９００にＢＳＲ２９１０を設け、ＢＳＲ２９１０を用いてデータ量情報を送信することにより、滞留データ量を送信ノード２００から受信ノード１００へ送信することができる。
【０１４７】
（実施の形態５）
実施の形態５にかかる受信ノード１００の通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定する。また、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定する。受信ノード１００および送信ノード２００の構成は、たとえば図１および図２に示した構成と同様である。
【０１４８】
（受信ノードの動作）
図３０は、実施の形態５にかかる受信ノードの動作の一例を示すフローチャートである。実施の形態５にかかる受信ノード１００の基本的な動作については、図１７に示した動作と同様である。また、実施の形態５にかかる受信ノード１００の通話状態判定部１３４は、図１７に示したステップＳ１７０１において、以下の各ステップを行う。
【０１４９】
まず、カウンタｋを０に設定する（ステップＳ３００１）。つぎに、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ３００２）、経過時間が監視周期以上になるまで待つ（ステップＳ３００２：Ｎｏのループ）。
【０１５０】
ステップＳ３００２において、経過時間が監視周期以上になると（ステップＳ３００２：Ｙｅｓ）、受信バッファ１３１の滞留データ量を測定する（ステップＳ３００３）。つぎに、前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ３００４）。
【０１５１】
ステップＳ３００４において、通話状態が「有音」である場合（ステップＳ３００４：Ｙｅｓ）は、ステップＳ３００３によって測定された滞留データ量が閾値以下か否かを判断する（ステップＳ３００５）。滞留データ量が閾値以下でない場合（ステップＳ３００５：Ｎｏ）は、ステップＳ３００９へ移行して処理を続行する。
【０１５２】
ステップＳ３００５において、ステップＳ３００３によって測定された滞留データ量が閾値以下である場合（ステップＳ３００５：Ｙｅｓ）は、カウンタｋをインクリメント（ｋ＝ｋ＋１）する（ステップＳ３００６）。つぎに、カウンタｋが保護段数より大きいか否かを判断する（ステップＳ３００７）。
【０１５３】
ステップＳ３００７において、カウンタｋが保護段数より大きくない場合（ステップＳ３００７：Ｎｏ）は、ステップＳ３００２へ戻って処理を続行する。カウンタｋが保護段数より大きい場合（ステップＳ３００７：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新する（ステップＳ３００８）。つぎに、カウンタｋを０に設定し（ステップＳ３００９）、一連の処理を終了する。
【０１５４】
ステップＳ３００４において、通話状態が「有音」でない場合（ステップＳ３００４：Ｎｏ）は、ステップＳ３００３によって測定された滞留データ量が閾値より大きいか否かを判断する（ステップＳ３０１０）。滞留データ量が閾値より大きくない場合（ステップＳ３０１０：Ｎｏ）は、ステップＳ３０１４へ進んで処理を続行する。
【０１５５】
ステップＳ３０１０において、ステップＳ３００３によって測定された滞留データ量が閾値より大きい場合（ステップＳ３０１０：Ｙｅｓ）は、カウンタｋをインクリメント（ｋ＝ｋ＋１）する（ステップＳ３０１１）。つぎに、カウンタｋが保護段数より大きいか否かを判断する（ステップＳ３０１２）。
【０１５６】
ステップＳ３０１２において、カウンタｋが保護段数より大きくない場合（ステップＳ３０１２：Ｎｏ）は、ステップＳ３００２へ戻って処理を続行する。カウンタｋが保護段数より大きい場合（ステップＳ３０１２：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新する（ステップＳ３０１３）。つぎに、カウンタｋを０に設定し（ステップＳ３０１４）、一連の処理を終了する。
【０１５７】
このように、通話状態判定部１３４は、ステップＳ３００５において滞留データ量が閾値以下であっても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定することができる。
【０１５８】
また、通話状態判定部１３４は、ステップＳ３０１０において滞留データ量が閾値より大きくても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定することができる。
【０１５９】
図３１は、図３０に示した動作による通話状態判定の具体例を示す図である。図３１において、図１９に示した部分と同様の部分については同一の符号を付して説明を省略する。図３１において、横軸は時間を示している。符号３１１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。
【０１６０】
ここでは、通話状態の初期値を「無音」とし、監視周期を２０［ｍｓ］とし、閾値（ＳＩＤデータ１９１２のサイズ相当）を１０［ｂｙｔｅ］とし、保護段数を３とする。受信ノード１００は、監視周期２０［ｍｓ］で受信バッファ１３１の滞留データ量を取得し、滞留データ量が閾値１０［ｂｙｔｅ］を超えるとカウンタｋをインクリメントする。監視周期Ｔ１〜Ｔ２３は、受信ノード１００における監視周期（２０［ｍｓ］）である。
【０１６１】
監視周期Ｔ１〜Ｔ６において、受信ノード１００は、ＡＭＲデータ１９１１（サイズ３０［ｂｙｔｅ］）を連続して６回、２０［ｍｓ］周期で正常に受信したとする。受信ノード１００は、監視周期Ｔ１〜Ｔ３においては、メモリに記憶された通話状態が「無音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］より大きいため、カウンタｋをインクリメントする（ｋ＝１，２，３）。
【０１６２】
監視周期Ｔ１〜Ｔ３において、受信ノード１００は、カウンタｋが保護段数３以下であるため、受信ノード１００は、通話状態を「無音」のままであると判定する。このため、監視周期Ｔ１〜Ｔ３においては通話状態が「無音」と判定される。
【０１６３】
監視周期Ｔ４において、受信ノード１００は、通話状態が「無音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］を超えているため、カウンタｋをインクリメントする（ｋ＝４）。受信ノード１００は、監視周期Ｔ４においてはカウンタｋが保護段数３を超えるため、受信ノード１００は、通話状態が「有音」に変化したと判定する。また、カウンタｋは初期化されて０になる（ｋ＝０）。
【０１６４】
監視周期Ｔ５〜Ｔ６において、受信ノード１００は、メモリに記憶された通話状態が「有音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下でないため、カウンタｋをインクリメントしない（ｋ＝０）。
【０１６５】
監視周期Ｔ７において、受信ノード１００は、ＡＭＲデータ１９１１を正常に受信できなかったとする。受信ノード１００は、監視周期Ｔ７においてはメモリに記憶された通話状態が「有音」であり、滞留データ量が０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝１）。受信ノード１００は、監視周期Ｔ７においてはカウンタｋが保護段数３を超えていない（ｋ＝１）ため、受信ノード１００は、通話状態が「有音」のままであると判定する。
【０１６６】
監視周期Ｔ８〜Ｔ１１において、受信ノード１００は、ＡＭＲデータ１９１１を連続して４回、正常に受信したとする。受信ノード１００は、監視周期Ｔ８〜Ｔ１１においてはメモリに記憶された通話状態が「有音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下でないため、カウンタｋをインクリメントしない（ｋ＝０）。
【０１６７】
監視周期Ｔ１２以降、送信ノード２００から受信ノード１００へ送信する音声データの実際の通話状態が「無音」となったとする。監視周期Ｔ１２，Ｔ１６，Ｔ２０のそれぞれにおいて、受信ノード１００は、ＳＩＤデータ１９１２（サイズ１０［ｂｙｔｅ］）を正常に受信したとする。
【０１６８】
監視周期Ｔ１２〜Ｔ１５において、受信ノード１００は、メモリに記憶された通話状態が「有音」であり滞留データ量が１０または０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝１，２，３）。受信ノード１００は、監視周期Ｔ１２〜Ｔ１５の間の期間においてはカウンタｋが保護段数３以下であるため、受信ノード１００は、通話状態を「有音」のままであると判定する。
【０１６９】
監視周期Ｔ１６において、受信ノード１００は、通話状態が「有音」であり、滞留データ量が１０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝４）。受信ノード１００は、監視周期Ｔ１６においてはカウンタｋが保護段数３を超えるため、受信ノード１００は、通話状態が「無音」に変化したと判定する。また、カウンタｋは初期化されて０になる（ｋ＝０）。
【０１７０】
監視周期Ｔ１７〜Ｔ２３において、受信ノード１００は、メモリに記憶された通話状態が「無音」であり、滞留データ量が１０［ｂｙｔｅ］または０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントしない（ｋ＝０）。
【０１７１】
このように、通話状態判定部１３４は、時期Ｔ７において滞留データ量が閾値以下であっても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、受信ノード１００がＡＭＲデータ１９１１を正常に受信できなかった場合に通話状態が「無音」になったと誤判定されることを回避することができる。
【０１７２】
このように、実施の形態５にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
【０１７３】
また、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定することで、瞬間的なトラヒックの増加によって通話状態が「有音」になったと誤判定することを回避することができる。
【０１７４】
また、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定することで、フレーム欠落などによる瞬間的なトラヒックの減少によって通話状態が「有音」になったと誤判定することを回避することができる。
【０１７５】
実施の形態５においては、受信ノード１００および送信ノード２００の構成が図１および図２に示した構成（実施の形態１）と同様である場合について説明した。ただし、受信ノード１００および送信ノード２００の構成を、実施の形態２〜４のいずれかと同様にしてもよい。一例として、受信ノード１００および送信ノード２００の構成を図２２および図２３に示した構成（実施の形態３）と同様にした場合について説明する。
【０１７６】
この場合は、送信ノード２００の通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定する。また、通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定する。
【０１７７】
（実施の形態６）
実施の形態１〜５においては、ＲＯＨＣ制御部１３５を受信ノード１００に設け、受信ノード１００によってＲＯＨＣの切替制御を行う構成について説明した。これに対して、実施の形態６は、ＲＯＨＣ制御部１３５に相当する機能を送信ノード２００に設け、送信ノード２００によってＲＯＨＣの切替制御を行う。
【０１７８】
（受信ノードの構成例）
図３２は、実施の形態６にかかる受信ノードの構成例を示すブロック図である。図３２において、図２２に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態６にかかる受信ノード１００においては、図２２に示したＲＯＨＣ制御部１３５および送信処理部１３６を省いた構成にしてもよい。
【０１７９】
（送信ノードの構成例）
図３３は、実施の形態６にかかる送信ノードの構成例を示すブロック図である。図３３において、図２３に示した構成と同様の構成については同一の符号を付して説明を省略する。図３３に示すように、実施の形態６にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２３に示した構成に加えてＲＯＨＣ制御部３３１０を備えている。
【０１８０】
また、実施の形態６にかかる送信ノード２００においては、図２３に示した受信処理部２１４を省いた構成にしてもよい。通話状態判定部２３１０は、判定結果を示す通話状態情報をＲＯＨＣ制御部３３１０へ出力する。
【０１８１】
ＲＯＨＣ制御部３３１０は、（制御手段）は、通話状態判定部２３１０から出力された判定結果に応じて、受信ノード１００および送信ノード２００におけるＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部３３１０は、ＲＯＨＣの動作モードを切り替えるために、切り替える動作モードを圧縮部２１２へ通知する。
【０１８２】
また、ＲＯＨＣ制御部３３１０は、切り替える動作モードを示す切替指示信号を生成する。そして、ＲＯＨＣ制御部３３１０は、生成した切替指示信号を送信処理部２１３へ出力する。これにより、切替指示信号が受信ノード１００へ送信され、ＲＯＨＣの動作モードが切り替わる。ＲＯＨＣ制御部３３１０によるＲＯＨＣの動作モードの切替については、上述したＲＯＨＣ制御部１３５による切替と同様であるため説明を省略する。
【０１８３】
図３３に示した圧縮部２１２は、ヘッダ圧縮を行った音声データを送信ノード２００のメモリ（不図示）に書き込む。圧縮部２１２は、たとえばＣＰＵなどの演算手段である。送信処理部２１３は、圧縮部２１２によって送信ノード２００のメモリに書き込まれた音声データを読み出し、読み出した音声データを送信する。
【０１８４】
通話状態判定部２３１０は、通話状態の判定結果を送信ノード２００のメモリ（不図示）に書き込む。通話状態判定部２３１０は、たとえばＣＰＵなどの演算手段である。ＲＯＨＣ制御部３３１０は、通話状態判定部２３１０によって送信ノード２００のメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じてＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部３３１０は、たとえばＣＰＵなどの演算手段である。
【０１８５】
このように、実施の形態６にかかる送信ノード２００（送信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
【０１８６】
また、送信ノード２００において通話状態を判定し、判定結果に基づいてＲＯＨＣの動作モードを切り替えることで、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。また、通話状態の判定およびＲＯＨＣの動作モードの切替を送信ノード２００側で行うことにより、受信ノード１００側の処理負担を軽減することができる。
【０１８７】
（ＲＯＨＣの動作モード切替の具体例）
図３４は、Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへの切替の具体例を示す図である。図３４において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｃ＿ＭＯＤＥ３４１０は、送信ノード２００の圧縮部２１２に設定されるＲＯＨＣの動作モードを示している。
【０１８８】
Ｃ＿ＭＯＤＥ３４１０は、「Ｕ−ｍｏｄｅ」、「Ｏ−ｍｏｄｅ」または「Ｒ−ｍｏｄｅ」の値をとる。Ｃ＿ＴＲＡＮＳ３４２０は、送信ノード２００の圧縮部２１２に設定される、ＲＯＨＣの動作モードの遷移経過状態である。Ｃ＿ＴＲＡＮＳ３４２０は、「Ｐｅｎｄｉｎｇ」または「Ｄｏｎｅ」の値をとる。
【０１８９】
Ｄ＿ＭＯＤＥ３４３０は、受信ノード１００の伸張部１３３に設定されるＲＯＨＣの動作モードである。Ｄ＿ＭＯＤＥ３４３０は、「Ｕ−ｍｏｄｅ」、「Ｏ−ｍｏｄｅ」または「Ｒ−ｍｏｄｅ」の値をとる。Ｄ＿ＴＲＡＮＳ３４４０は、受信ノード１００の伸張部１３３に設定される、ＲＯＨＣの動作モードの遷移経過状態である。Ｄ＿ＴＲＡＮＳ３４４０は、「Ｉｎｉｔｉａｔｅｄ」、「Ｐｅｎｄｉｎｇ」または「Ｄｏｎｅ」の値をとる。
【０１９０】
Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへ切替は、受信ノード１００から送信ノード２００へのフィードバックチャネルが利用可能であれば任意のタイミングで行うことができる。たとえば、時期ｔ３４１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ−ｍｏｄｅであったとする。
【０１９１】
そして、受信ノード１００は、ＲＯＨＣの動作モードをＯ−ｍｏｄｅへ切り替える旨の切替指示信号３４５０を時期ｔ３４１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３４５０を受信すると、送信ノード２００におけるＲＯＨＣの動作モードをＯ−ｍｏｄｅに切り替える。
【０１９２】
具体的には、送信ノード２００は、周期的な非圧縮フレーム５１１の送信を停止し、受信ノード１００からＮａｃｋを受信するまでは圧縮フレーム５１２を送信する。Ｕ−ｍｏｄｅからＯ−ｍｏｄｅへの切替においては、受信ノード１００および送信ノード２００において任意のタイミングにおいて切替を行うことができるため、Ｃ＿ＴＲＡＮＳ３４２０およびＤ＿ＴＲＡＮＳ３４４０は「Ｄｏｎｅ」のまま切替を行うことができる。
【０１９３】
図３５は、Ｕ−ｍｏｄｅからＲ−ｍｏｄｅへの切替の具体例を示す図である。図３５において、図３４に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｕ−ｍｏｄｅからＲ−ｍｏｄｅへ切替は、少なくとも１つの非圧縮フレーム５１１を正常に受信した後で行う。たとえば、時期ｔ３５１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ−ｍｏｄｅであったとする。
【０１９４】
そして、受信ノード１００は、ＲＯＨＣの動作モードをＲ−ｍｏｄｅへ切り替える旨の切替指示信号３５２１を時期ｔ３５１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３５２１を受信すると、動作モードをＲ−ｍｏｄｅに切り替え、非圧縮フレーム５１１を連続して受信ノード１００へ送信する。
【０１９５】
受信ノード１００は、送信ノード２００から送信された非圧縮フレーム５１１を受信すると、受信ノード１００におけるＲＯＨＣの動作モードをＲ−ｍｏｄｅに切り替える。受信ノード１００が切替指示信号３５２１を送信した時期ｔ３５１１から、送信ノード２００から送信された非圧縮フレーム５１１を受信ノード１００が受信した時期ｔ３５１２までの期間は、Ｄ＿ＴＲＡＮＳ３４４０は「Ｉｎｉｔｉａｔｅｄ」になる。
【０１９６】
また、受信ノード１００は、時期ｔ３５１２において送信ノード２００から送信された非圧縮フレーム５１１を正常に受信すると、送信ノード２００へＡｃｋ３５２２を送信する。送信ノード２００は、Ａｃｋ３５２２を受信すると、受信ノード１００からＮａｃｋを受信するまでは連続して圧縮フレーム５１２を受信ノード１００へ送信する。
【０１９７】
送信ノード２００がＲＯＨＣの動作モードをＲ−ｍｏｄｅに切り替えてから送信ノード２００がＡｃｋ３５２２を受信するまでの期間は、Ｃ＿ＴＲＡＮＳ３４２０は「Ｐｅｎｄｉｎｇ」になる。また、受信ノード１００がＡｃｋ３５２２を送信した時期ｔ３５１２から受信ノード１００が圧縮フレーム５１２を受信する時期ｔ３５１３までの期間のＤ＿ＴＲＡＮＳ３４４０は「Ｐｅｎｄｉｎｇ」になる。
【０１９８】
図３６は、Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへの切替の具体例を示す図である。図３６において、図３４に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへ切替は、任意のタイミングで行うことができる。たとえば、時期ｔ３６１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＯ−ｍｏｄｅであったとする。
【０１９９】
そして、受信ノード１００は、ＲＯＨＣの動作モードをＵ−ｍｏｄｅへ切り替える旨の切替指示信号３６２１を時期ｔ３６１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３６２１を受信すると、送信ノード２００におけるＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える。
【０２００】
具体的には、送信ノード２００は、周期的な非圧縮フレーム５１１の送信を開始する。また、送信ノード２００は、ＲＯＨＣの動作モードのＵ−ｍｏｄｅへの切替時に、非圧縮フレーム５１１を３回連続して送信し、これらの非圧縮フレーム５１１に対するＡｃｋを受信ノード１００から受信するようにしてもよい。これにより、動作モードの切替が正常に行われていることを確認することができる（Ｔｈｒｅｅ−ｗａｙハンドシェイク）。
【０２０１】
受信ノード１００は、切替指示信号３６２１を送信した後に送信ノード２００から非圧縮フレーム５１１を受信した時期ｔ３６１２において、ＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える。受信ノード１００が切替指示信号３６２１を送信した時期ｔ３６１１から、受信ノード１００が送信ノード２００から圧縮フレーム５１２を受信する時期ｔ３６１３までの期間のＤ＿ＴＲＡＮＳ３４４０は「Ｉｎｉｔｉａｔｅｄ」になる。Ｒ−ｍｏｄｅからＵ−ｍｏｄｅへの切替は、Ｏ−ｍｏｄｅからＵ−ｍｏｄｅへの切替と同様であるため説明を省略する。
【０２０２】
以上説明したように、開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
【０２０３】
なお、上述した各実施の形態においては、ＬＴＥシステムを例とする構成について説明したが、開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法は、ＷｉＭＡＸなどの他の通信システムに対しても適用可能である。
【０２０４】
また、上述した各実施の形態においては、通話状態が「有音」の場合はＲＯＨＣの動作モードをＯ−ｍｏｄｅやＲ−ｍｏｄｅに切り替え、通話状態が「無音」の場合はＲＯＨＣの動作モードをＵ−ｍｏｄｅに切り替える構成について説明した。これに対して通話状態が「有音」の場合はＲＯＨＣの動作モードをＲ−ｍｏｄｅに切り替え、通話状態が「無音」の場合はＲＯＨＣの動作モードをＯ−ｍｏｄｅに切り替える構成にしてもよい。
【０２０５】
一般的に、Ｏ−ｍｏｄｅはＲ−ｍｏｄｅよりもヘッダ圧縮の頻度が高いため、ヘッダ圧縮の効率が優れている。このため、通話状態が「無音」の場合はＲＯＨＣの動作モードをＯ−ｍｏｄｅに切り替えることで、ヘッダ圧縮の効率化を図ることができる。その他、ヘッダ圧縮の動作モードについては、ＲＯＨＣのＵ−ｍｏｄｅ、Ｏ−ｍｏｄｅおよびＲ−ｍｏｄｅに限らず、ヘッダ圧縮の頻度が異なる種々の動作モードを用いることができる。
【０２０６】
上述した実施の形態に関し、さらに以下の付記を開示する。
【０２０７】
（付記１）音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信装置において、
前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信手段と、
前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする受信装置。
【０２０８】
（付記２）前記判定手段は、前記受信手段によって受信された音声データを格納する受信バッファの滞留データ量に基づいて前記通話状態を判定することを特徴とする付記１に記載の受信装置。
【０２０９】
（付記３）前記受信手段は、前記送信装置の送信バッファに格納されている前記音声データの量を示すデータ量情報を前記送信装置から受信し、
前記判定手段は、前記受信手段によって受信されたデータ量情報に基づいて前記通話状態を判定することを特徴とする付記１に記載の受信装置。
【０２１０】
（付記４）前記受信手段は、前記送信装置によって判定された前記通話状態を示す通話状態情報を前記送信装置から受信し、
前記制御手段は、前記受信手段によって受信された通話状態情報に応じて前記動作モードを切り替えることを特徴とする付記１に記載の受信装置。
【０２１１】
（付記５）前記判定手段は、前記受信バッファの滞留データ量が閾値より大きい場合は前記通話状態を有音と判定し、前記音声データの量が前記閾値以下の場合は前記通話状態を無音と判定することを特徴とする付記２に記載の受信装置。
【０２１２】
（付記６）前記制御手段は、前記判定手段によって有音と判定された場合は、前記複数の動作モードのうちの前記ヘッダ圧縮の頻度が低い動作モードへ切り替え、前記判定手段によって無音と判定された場合は、前記複数の動作モードのうちの前記ヘッダ圧縮の頻度が高い動作モードへ切り替えることを特徴とする付記５に記載の受信装置。
【０２１３】
（付記７）前記判定手段は、前記受信バッファの滞留データ量が所定期間以上において前記閾値より大きい場合に前記通話状態を有音と判定することを特徴とする付記５に記載の受信装置。
【０２１４】
（付記８）前記判定手段は、前記受信バッファの滞留データ量が所定期間以上において前記閾値以下の場合に前記通話状態を無音と判定することを特徴とする付記５に記載の受信装置。
【０２１５】
（付記９）前記判定手段は、前記判定結果をメモリに書き込む演算手段であり、
前記制御手段は、前記判定手段によってメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じて前記動作モードを切り替える演算手段であることを特徴とする付記１に記載の受信装置。
【０２１６】
（付記１０）音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信装置において、
音声データのヘッダ圧縮を行う圧縮手段と、
前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
前記送信手段によって送信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする送信装置。
【０２１７】
（付記１１）前記圧縮手段は、ヘッダ圧縮を行った音声データをメモリに書き込む演算手段であり、
前記送信手段は、前記圧縮手段によってメモリに書き込まれた音声データを読み出し、読み出した音声データを送信し、
前記判定手段は、前記判定結果をメモリに書き込む演算手段であり、
前記制御手段は、前記判定手段によってメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じて前記動作モードを切り替える演算手段であることを特徴とする付記１０に記載の送信装置。
【０２１８】
（付記１２）音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信方法において、
前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信工程と、
前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする受信方法。
【０２１９】
（付記１３）音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信方法において、
音声データのヘッダ圧縮を行う圧縮工程と、
前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
前記送信工程によって送信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする送信方法。
【０２２０】
（付記１４）音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおいて、
音声データのヘッダ圧縮を行う圧縮手段と、
前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
前記送信手段によって送信された音声データを受信する受信手段と、
前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
を備えることを特徴とする通信システム。
【０２２１】
（付記１５）音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムの通信方法において、
音声データのヘッダ圧縮を行う圧縮工程と、
前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
前記送信工程によって送信された音声データを受信する受信工程と、
前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
を含むことを特徴とする通信方法。
【符号の説明】
【０２２２】
３００  通信システム
３１１，３１２  ＭＭＥ／Ｓ−ＧＷ
３２１〜３２３  ｅＮＢ
３３１，３３２  ＵＥ
４００  プロトコルスタック
５１１  非圧縮フレーム
５１２  圧縮フレーム
８０１，３５２２  Ａｃｋ
９１１，１９１１  ＡＭＲデータ
９１２，１９１２  ＳＩＤデータ
１０００  ＭＡＣ＿ＰＤＵ
１５００，１６００，２４００，２９００  ＰＤＣＰフレーム
３４１０  Ｃ＿ＭＯＤＥ
３４２０  Ｃ＿ＴＲＡＮＳ
３４３０  Ｄ＿ＭＯＤＥ
３４４０  Ｄ＿ＴＲＡＮＳ
３４５０，３５２１，３６２１  切替指示信号
Ｔ１〜Ｔ２３  監視周期
【国際調査報告】
2010106663.tif 000039
2010106663.tif 000040
2010106663.tif 000041
2010106663.tif 000042