通信端末装置

トップ :: H 電気 :: H04 電気通信技術

【発明の名称】	通信端末装置
【発明者】	【氏名】大木公裕【氏名】福光勝【氏名】山田秀昭【氏名】有木博信【氏名】山元祐樹【氏名】新藤晃浩
【要約】	【課題】ハンドオーバーを行う際にハンドオーバーの状態に応じてパケットを適切に処理する。【構成】通信端末装置１は、ハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を生成、または当該通信端末装置がパケット通信を行っている相手方通信端末装置からイベント情報を受信して、そのイベント情報に基づき音声パケット送信部１２におけるパケットの送信間隔や、順序入替補償部１５ａにおける受信パケットの順序入れ替え用バッファのバッファ長や、音声符号化部１３における送信する音声データの符号化処理の内容や、パケットロス補償制御部１８におけるパケットロス補償の処理内容を制御する。

【特許請求の範囲】
【請求項１】
パケット網に接続してパケット通信を行う通信端末装置において、
当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段を備え、
前記生成されたイベント情報に基づいて前記パケット網に送信するパケットの送信間隔を制御する
ことを特徴とする通信端末装置。
【請求項２】
パケット網に接続してパケット通信を行う通信端末装置において、
パケットの受信順序が正順となっていない場合にそれらのパケットの順序を入れ替える順序入替補償用バッファと、
当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段とを備え、
前記生成されたイベント情報に基づいて前記順序入替補償用バッファのバッファ長を制御する
ことを特徴とする通信端末装置。
【請求項３】
パケット網に接続してパケット通信を行う通信端末装置において、
送信する音声データを符号化する手段と、
当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段とを備え、
前記生成されたイベント情報に基づいて前記符号化の処理における符号化レートまたは符号化アルゴリズムの少なくとも一方を制御する
ことを特徴とする通信端末装置。
【請求項４】
パケット網に接続してパケット通信を行う通信端末装置において、
受信したパケットを一時的に蓄積するジッタバッファと、
前記ジッタバッファの枯渇によるパケットのロスを補償する手段と、
当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段とを備え、
前記生成されたイベント情報に基づいて前記パケットロス補償の処理における補償強度または補償アルゴリズムの少なくとも一方を制御する
ことを特徴とする通信端末装置。
【請求項５】
パケット網に接続してパケット通信を行う通信端末装置において、
当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段を備え、
前記受信したイベント情報に基づいて前記パケット網に送信するパケットの送信間隔を制御する
ことを特徴とする通信端末装置。
【請求項６】
パケット網に接続してパケット通信を行う通信端末装置において、
パケットの受信順序が正順となっていない場合にそれらのパケットの順序を入れ替える順序入替補償用バッファと、
当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段とを備え、
前記受信したイベント情報に基づいて前記順序入替補償用バッファのバッファ長を制御する
ことを特徴とする通信端末装置。
【請求項７】
パケット網に接続してパケット通信を行う通信端末装置において、
送信する音声データを符号化する手段と、
当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段とを備え、
前記受信したイベント情報に基づいて前記符号化の処理における符号化レートまたは符号化アルゴリズムの少なくとも一方を制御する
ことを特徴とする通信端末装置。
【請求項８】
パケット網に接続してパケット通信を行う通信端末装置において、
受信したパケットを一時的に蓄積するジッタバッファと、
前記ジッタバッファの枯渇によるパケットのロスを補償する手段と、
当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段とを備え、
前記受信したイベント情報に基づいて前記パケットロス補償の処理における補償強度または補償アルゴリズムの少なくとも一方を制御する
ことを特徴とする通信端末装置。

【発明の詳細な説明】【技術分野】
【０００１】
本発明は通信端末装置に係り、特にパケット通信網においてハンドオーバーを行う通信端末装置に関する。
【背景技術】
【０００２】
携帯電話や無線ＬＡＮ（Local Area Network）などのアクセスメディアシステムを使う通信において、異なるシステム間ではルータやスイッチ等のネットワーク構成あるいは装置の処理速度の違いによって、パケット伝送における遅延時間の変動量が異なるため、システムを切り替えるハンドオーバーの前後で送信端末から受信端末にパケットが到着するまでに掛かる時間が大きく揺らぐ。このようなパケット通信でのパケット到着時間の揺らぎ（ジッタ）は、通信品質を劣化させる一要因となる。
【０００３】
また、同じ通信品質を持つアクセスメディアシステム間のハンドオーバーにおいても、ハンドオーバーの処理時間中にアクセスメディアシステム内でバッファリングされたパケットについては、送信端末から受信端末にパケットが到着するまでに掛かる時間が大きく揺らぐ。このようなジッタによっても、通信品質の劣化が生じる。
【０００４】
従来、こうしたジッタへの対策として、受信端末にジッタを吸収させるためのバッファ（以下、ジッタバッファと言う）を設けることが行われている。受信端末は、過去の一定期間に受信したパケットから当該期間におけるジッタ量を算出し、このジッタ量に基づいてジッタバッファからのパケット出力速度を制御することにより、ジッタバッファのパケット蓄積量を調整する。ジッタバッファから一定周期で読み出された受信パケットは、音声アプリケーションなどに渡されて、再生が行われる（例えば、特許文献１参照）。
【特許文献１】特開２００６－５０４８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来のジッタ対策にかかる技術では、単一のアクセスメディアシステムにおける連続したジッタの変化に基づいて調整が行われるだけである。そのため、現在利用しているアクセスメディアシステムと通信品質が大きく異なるアクセスメディアシステムへハンドオーバーが行われた場合や、同じ通信品質を持つアクセスメディアシステム間でのハンドオーバーであっても、アクセスメディアシステム内でバッファリングが発生する場合には、ジッタバッファでジッタを吸収しきれず、アプリケーションの実行に影響を及ぼしてしまうという問題がある。
【０００６】
例えば、ジッタの少ない良好な通信品質のアクセスメディアシステムを利用した通信では、過去の一定期間に受信したパケットから算出したジッタ量は非常に少なく、これに応じてジッタバッファの蓄積量も非常に少なくなっている。この状態で予告無くジッタの多いアクセスメディアシステムへハンドオーバーを行うと、受信端末へのパケットの到達時間が遅くなるため、ジッタバッファ内のパケットが枯渇してしまう場合がある。そしてその結果、音声通信では再生音の途切れが発生することになる。
【０００７】
また同様に、ハンドオーバーにおいて予告無くアクセスメディアシステム内でパケットのバッファリングが行われると、受信端末へのパケットの到達時間が遅くなることによって、ジッタバッファ内のパケットが枯渇してしまう場合がある。そしてその結果、音声通信では再生音の途切れが発生することになる。
【０００８】
本発明は上記の点に鑑みてなされたものであり、その目的は、ハンドオーバーを行う際にハンドオーバーの状態に応じてパケットを適切に処理することが可能な通信端末装置を提供することにある。
【課題を解決するための手段】
【０００９】
本発明は、上記の課題を解決するためになされたものであり、パケット網に接続してパケット通信を行う通信端末装置において、当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段を備え、前記生成されたイベント情報に基づいて前記パケット網に送信するパケットの送信間隔を制御することを特徴とする。
【００１０】
また、本発明は、パケット網に接続してパケット通信を行う通信端末装置において、パケットの受信順序が正順となっていない場合にそれらのパケットの順序を入れ替える順序入替補償用バッファと、当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段とを備え、前記生成されたイベント情報に基づいて前記順序入替補償用バッファのバッファ長を制御することを特徴とする。
【００１１】
また、本発明は、パケット網に接続してパケット通信を行う通信端末装置において、送信する音声データを符号化する手段と、当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段とを備え、前記生成されたイベント情報に基づいて前記符号化の処理における符号化レートまたは符号化アルゴリズムの少なくとも一方を制御することを特徴とする。
【００１２】
また、本発明は、パケット網に接続してパケット通信を行う通信端末装置において、受信したパケットを一時的に蓄積するジッタバッファと、前記ジッタバッファの枯渇によるパケットのロスを補償する手段と、当該通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際に該ハンドオーバーの状態に関するイベント情報を生成する手段とを備え、前記生成されたイベント情報に基づいて前記パケットロス補償の処理における補償強度または補償アルゴリズムの少なくとも一方を制御することを特徴とする。
【００１３】
また、本発明は、パケット網に接続してパケット通信を行う通信端末装置において、当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段を備え、前記受信したイベント情報に基づいて前記パケット網に送信するパケットの送信間隔を制御することを特徴とする。
【００１４】
また、本発明は、パケット網に接続してパケット通信を行う通信端末装置において、パケットの受信順序が正順となっていない場合にそれらのパケットの順序を入れ替える順序入替補償用バッファと、当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段とを備え、前記受信したイベント情報に基づいて前記順序入替補償用バッファのバッファ長を制御することを特徴とする。
【００１５】
また、本発明は、パケット網に接続してパケット通信を行う通信端末装置において、送信する音声データを符号化する手段と、当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段とを備え、前記受信したイベント情報に基づいて前記符号化の処理における符号化レートまたは符号化アルゴリズムの少なくとも一方を制御することを特徴とする。
【００１６】
また、本発明は、パケット網に接続してパケット通信を行う通信端末装置において、受信したパケットを一時的に蓄積するジッタバッファと、前記ジッタバッファの枯渇によるパケットのロスを補償する手段と、当該通信端末装置がパケット通信を行っている相手方通信端末装置が接続先のパケット網を切り替えるハンドオーバーの際、該ハンドオーバーの状態に関するイベント情報を前記相手方通信端末装置から受信する手段とを備え、前記受信したイベント情報に基づいて前記パケットロス補償の処理における補償強度または補償アルゴリズムの少なくとも一方を制御することを特徴とする。
【発明の効果】
【００１７】
本発明によれば、イベント情報に基づいてパケットの送信間隔や、受信したパケットの順序入れ替え用のバッファのバッファ長や、送信する音声データの符号化処理の内容や、パケットロス補償の処理内容を制御しているので、ハンドオーバーの状態に応じた適切なパケット処理を行うことが可能である。そしてその結果、接続するアクセスメディアシステムの通信品質に応じた良好な通信を実現することができる。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照しながら本発明の実施形態について詳しく説明する。ここでは、音声パケットを用いたパケット通信を行う音声会話通信システムを取り上げる。但し、本発明は音声パケットに限らず、画像パケットなどの各種のパケット通信にも適用可能である。本発明は、特にリアルタイム通信に用いて好適であり、例えばテレビ会議システムなどにも適用することができる。
【００１９】
図１は、本発明の一実施形態による通信端末装置が利用される音声会話通信システムのネットワーク構成を概略的に示したものである。同図において、通信端末装置１ａおよび１ｂはユーザが音声通話をするための端末であり、通信アプリケーション部２とＯＳ／デバイスドライバ部３とを有している。ＯＳ／デバイスドライバ部３は、パケット通信の通信制御を担うものであり、例えば携帯電話や無線ＬＡＮなど各種の通信方式に対応させることができる。通信端末装置１ａは、移動パケット網１００を構成する各移動パケット網＃１～＃Ｎと無線のアクセスメディアにより接続可能である。移動パケット網＃１～＃Ｎは、それぞれ固有の特性（通信品質）を持っており、それらは互いに異なっていても同一でもよい。通信端末装置１ｂは、固定パケット網２００に接続されている。なお、固定パケット網２００に代えて移動パケット網であってもよい。
【００２０】
通信端末装置１ａと１ｂは、移動パケット網１００および固定パケット網２００を介して相互に音声パケットを送受する。音声パケットには、音声データが格納されている。この音声パケットを用いたパケット通信により、通信端末装置１ａと１ｂ間において音声通話が可能となっている。
【００２１】
図２は、通信端末装置１（以下、１ａと１ｂを特に区別しないときはこのように記載する）の構成を示す機能ブロック図である。同図において、通信端末装置１は、音声パケット送信部１２、音声符号化部１３、音声パケット受信部１４、順序入替補償部１５ａ、順序入替補償バッファ１５ｂ、ジッタバッファ１６、音声復号部１７、パケットロス補償制御部１８、メディア再生速度制御部１９、イベント管理部２０、バッファ閾値設定部２１、ジッタバッファ制御部２２（以上、通信アプリケーション部２に相当する）、移動パケット網１００または固定パケット網２００と接続するインタフェース機能を有する網接続インタフェース部１１（ＯＳ／デバイスドライバ部３に相当する）、マイク２３、スピーカ２４を備えている。
【００２２】
音声パケットの送信において、マイク２３への入力音声は、アナログの音声信号として音声符号化部１３に入力される。音声符号化部１３は、イベント管理部２０から通知されるイベント情報（詳細は後述する）およびバッファ閾値設定部２１から通知されるジッタ量に従って、入力音声信号にデジタル化および符号化を施して音声パケット送信部１２へと出力する。音声パケット送信部１２は、イベント管理部２０から通知されるイベント情報に従って、この符号化音声データをパケット化して網接続インタフェース部１１へ出力する。そして、音声パケットが網接続インタフェース部１１から移動パケット網１００または固定パケット網２００へと送信される。
【００２３】
また、音声パケットの受信において、網接続インタフェース部１１により受信された移動パケット網１００または固定パケット網２００からの音声パケットは、音声パケット受信部１４に入力される。音声パケット受信部１４は、受け取った音声パケットを順序入替補償部１５ａ経由でジッタバッファ１６に格納する。順序入替補償部１５ａでは、音声パケットの受信シーケンス番号が正順となっていない場合に、それらの音声パケットを順序入替補償バッファ１５ｂ（バッファ長はイベント管理部２０から通知されるイベント情報に従う）に一旦格納することで、ハンドオーバーによって順序反転を起こしたデータの正順化処理が行われる。その結果、ジッタバッファ１６には正順化後の音声パケットが格納されることになる。
【００２４】
そして、音声復号部１７は、ジッタバッファ１６から出力される音声パケットに含まれる符号化音声データを復号し、さらにアナログ化してパケットロス補償制御部１８へ出力する。パケットロス補償制御部１８は、イベント管理部２０から通知されるイベント情報およびバッファ閾値設定部２１から通知されるジッタ量に従って、ジッタバッファの枯渇によるパケットのロスに対して補償を施した上で、補償されたデータをメディア再生速度制御部１９へ出力する。メディア再生速度制御部１９は、ジッタバッファ制御部２２からの指示に基づいて、データ（音声データ）の再生速度を制御する。そして、スピーカ２４によって音声信号が再生される。
【００２５】
次に、ジッタバッファ１６に設定される、音声パケットの蓄積量の閾値（ジッタバッファ閾値）について説明する。音声パケット受信部１４では、音声パケットの受信時刻と当該音声パケットの受信シーケンス番号が逐次監視されており、これらの情報は音声パケット受信部１４からバッファ閾値設定部２１へ通知される。バッファ閾値設定部２１は、通知されたこれらの情報（音声パケットの受信時刻と受信シーケンス番号）から通信端末装置１に到着するパケットに関するジッタの標準偏差（ジッタ量）を算出し、そのジッタ量に基づいてジッタバッファ閾値を決定する。
【００２６】
ジッタバッファ閾値は、メディア再生速度制御部１９における音声データの再生速度と、ジッタバッファ１６のパケット出力速度（ジッタバッファ１６からパケットを取り出す速度）を規定するためのものである。ジッタバッファ制御部２２は、決定したジッタバッファ閾値をジッタバッファ１６に設定するとともに、ジッタバッファ１６に蓄積されるパケットの量を監視する。そして、パケットの蓄積量とジッタバッファ閾値との大小関係に応じて、メディア再生速度制御部１９に対して音声データの再生速度を指示する。また、ジッタバッファ１６のパケット出力速度も制御する。
【００２７】
図３は、ジッタバッファ１６に設定されたジッタバッファ閾値（再生開始閾値、高速再生閾値、低速再生閾値、最大バッファ閾値、再生停止閾値の５種類）を示した図である。但し、これらの閾値には次式の関係が成り立っているものとする。
最大バッファ閾値≧高速再生閾値≧再生開始閾値≧低速再生閾値≧再生停止閾値
【００２８】
再生開始閾値は、音声データの再生停止の状態から再生開始（通常再生速度）の状態に遷移する時における、ジッタバッファ１６のパケット蓄積量の閾値を定めている。すなわち、パケットの蓄積量がこの再生開始閾値を超えると、通常の再生速度で音声データの再生が開始される。
【００２９】
高速再生閾値は、通常の再生速度の状態から高速再生の状態に遷移する時における、ジッタバッファ１６のパケット蓄積量の閾値を定めている。すなわち、パケットの蓄積量がこの高速再生閾値を超えると、音声データの高速再生が開始される。高速再生の状態は、パケットの蓄積量が上記の再生開始閾値以下になるまで継続する。
【００３０】
低速再生閾値は、通常の再生速度の状態から低速再生の状態に遷移する時における、ジッタバッファ１６のパケット蓄積量の閾値を定めている。すなわち、パケットの蓄積量がこの低速再生閾値を下回ると、音声データの低速再生が開始される。低速再生の状態は、パケットの蓄積量が上記の再生開始閾値以上になるまで継続する。
【００３１】
最大バッファ閾値は、ジッタバッファ１６に格納可能な最大のパケット量を定めたものである。パケットの蓄積量が最大バッファ閾値に達すると、ジッタバッファ１６内のデータは破棄され、ジッタバッファ１６が空の状態から再度パケットの蓄積が開始される。
【００３２】
再生停止閾値は、通常再生の状態から再生停止の状態に遷移する時における、ジッタバッファ１６のパケット蓄積量の閾値を定めている。すなわち、パケットの蓄積量がこの再生停止閾値を下回ると、音声データの再生が停止される。
【００３３】
図４は、上記の各閾値に基づくメディア再生速度制御部１９による制御の状態遷移を示したものである。
まず、ジッタバッファ１６への音声パケットの蓄積が開始され、パケットの蓄積量が再生開始閾値に達するまでは、ジッタバッファ１６はパケットを出力することなく蓄積を継続する。また、メディア再生速度制御部１９は、再生停止の制御を行う（状態１）。
【００３４】
上記再生停止の状態１において、パケットの蓄積量が再生開始閾値に達したことがジッタバッファ制御部２２により検知されると、ジッタバッファ制御部２２はジッタバッファ１６にパケットの出力を開始させる。また、メディア再生速度制御部１９は、ジッタバッファ制御部２２から指示を受け、音声データの再生速度を通常再生速度に制御する（状態１→状態２）。これにより、音声の再生が開始され通常速度で再生が行われる。なお、ジッタバッファ１６のパケット出力速度は、音声の再生速度と同期するようにする（以下に述べるステップも同様）。
【００３５】
通常再生の状態２において、パケットの蓄積量が高速再生閾値にまで増加したことを検知すると、ジッタバッファ制御部２２は、ジッタバッファ１６のパケット出力速度を増加させ、またメディア再生速度制御部１９に音声データの再生速度を高速再生速度に変更させる（状態２→状態３）。これにより、音声の高速再生が行われて、ジッタバッファ１６のパケット蓄積量がどんどん増え続けるという状況が回避される。
【００３６】
高速再生の状態３において、パケットの蓄積量が高速再生閾値を下回ったことが検知されると、ジッタバッファ制御部２２は、ジッタバッファ１６のパケット出力速度を元に戻し、またメディア再生速度制御部１９に音声データの再生速度を通常再生速度に変更させる（状態３→状態２）。
【００３７】
また、通常再生の状態２において、パケットの蓄積量が低速再生閾値にまで減少したことを検知すると、ジッタバッファ制御部２２は、ジッタバッファ１６のパケット出力速度を低下させ、またメディア再生速度制御部１９に音声データの再生速度を低速再生速度に変更させる（状態２→状態４）。これにより、音声の低速再生が行われる。そして、ジッタバッファ１６のパケット蓄積量が減り続けることによりパケットが枯渇してしまい、再生音声が途切れてしまうという状況が回避される。
【００３８】
低速再生の状態４において、パケットの蓄積量が低速再生閾値を上回ったことが検知されると、ジッタバッファ制御部２２は、ジッタバッファ１６のパケット出力速度を元に戻し、またメディア再生速度制御部１９に音声データの再生速度を通常再生速度に変更させる（状態４→状態２）。
【００３９】
また、低速再生の状態４において、パケットの蓄積量がさらに減少して再生停止閾値にまで達したことが検知されると、ジッタバッファ制御部２２はジッタバッファ１６にパケットの出力を停止させる。また、メディア再生速度制御部１９は、ジッタバッファ制御部２２から指示を受け、音声データの再生停止の制御を行う（状態４→状態１）。
【００４０】
図５～図７は、メディア再生速度制御部１９によって制御される音声データの再生速度の設定例を示している。
【００４１】
図５の例において、パケット蓄積量が高速再生閾値を超えた場合に適用される高速再生速度は、蓄積量によらず一定値に設定される。また、パケット蓄積量が低速再生閾値を下回った場合に適用される低速再生速度は、蓄積量によらず一定値に設定される。この設定例では、再生速度ｈは（１）式により表される。但し、ｎは通常再生での再生速度、ｋは定数（高速再生では正の値、低速再生では負の値）である。
ｈ＝ｎ＋ｋ・・・（１）
【００４２】
図６の例において、パケット蓄積量が高速再生閾値を超えた場合に適用される高速再生速度は、蓄積量の増加分に比例して再生速度も増加する。また、パケット蓄積量が低速再生閾値を下回った場合に適用される低速再生速度は、蓄積量の減少分に比例して再生速度も減少する。この設定例では、再生速度ｈは（２）式により表される。但し、ｄは各閾値からのパケット蓄積量の変化量（絶対値）、ａは速度変更係数（高速再生では正の値、低速再生では負の値）である。
ｈ＝ｎ＋ａｄ・・・（２）
【００４３】
図７の例において、パケット蓄積量が高速再生閾値を超えた場合に適用される高速再生速度は、蓄積量の増加分の２乗に比例して再生速度も増加する。また、パケット蓄積量が低速再生閾値を下回った場合に適用される低速再生速度は、蓄積量の減少分の２乗に比例して再生速度も減少する。この設定例では、再生速度ｈは（３）式により表される。
ｈ＝ｎ＋ａｄ^２・・・（３）
【００４４】
なお、上記の設定例に従って音声データの再生速度を変更する際は、単純に再生速度だけを変更する方法でもよいし、再生される音声のピッチ（音程）が一定に保たれるようにして再生速度を変更する方法でもよい。
【００４５】
次に、イベント管理部２０によって管理されるイベント情報とそのイベント情報に基づく通信端末装置１の制御について説明する。
網接続インタフェース部１１（ＯＳ／デバイスドライバ部３）は、通信端末装置１ａや１ｂのハンドオーバーの状態に関係する情報であるイベント情報をイベント管理部２０に通知する機能を備えている。通信端末装置１は、このイベント情報を利用して、音声データの送信や受信、再生などの処理の制御を可能としている。
【００４６】
ここで、イベント情報として具体的には、例えば通信端末装置１が現在利用しているアクセスメディアシステム（移動パケット網＃１～＃Ｎなど）を示す情報や、ハンドオーバーの候補先のアクセスメディアにハンドオーバーを開始することを示す情報や、ネットワーク内の所定のサーバで認証等が成功したことを示す情報や、ハンドオーバーの候補先のアクセスメディアにハンドオーバーが完了したことを示す情報や、ハンドオーバー元のアクセスメディアシステムの設備リソースを開放したことを示す情報や、ハンドオーバーの処理が何らかの理由で中止されたことを示す情報などがある。
【００４７】
イベント情報は、次の２つの場合に網接続インタフェース部１１からイベント管理部２０へ通知される。まず、自端末（通信端末装置１ａとする）のハンドオーバーにかかる処理、動作によってＯＳ／デバイスドライバ部３がイベント情報を生成した場合である。また、通信相手方の端末（通信端末装置１ｂとする）がハンドオーバーを行い、当該端末内で生成されたイベント情報が所定の方法で自端末へ送信されてこれを取得した場合にも、自端末のイベント管理部２０へ通知が行われる。後者の場合、相手方端末から自端末へのイベント情報の送信は、例えば相手方端末においてＲＴＰ（Real-time Transport Protocol）等のパケットのヘッダ部に所定のイベント情報を記述して、このパケットが自端末へ送信されることによって実現される。
【００４８】
イベント管理部２０は、網接続インタフェース部１１からイベント情報の通知を受けると、そのイベント情報の種別を識別した上で、音声パケット送信部１２と、順序入替補償部１５ａと、音声符号化部１３と、パケットロス補償制御部１８と、バッファ閾値設定部２１に対して受信時刻順にイベント情報を出力する。上記各部は、このイベント情報を取得して、以下に示すような制御を実行する。
【００４９】
音声パケット送信部１２では、イベント情報が入力されると、当該イベント情報に基づいて、パケットを送信する際の送信間隔を制御する。図８に送信間隔の制御例を示す。この図に示す情報は、図２には表示していない所定のメモリ部に記憶されており、音声パケット送信部１２によって制御の際に参照される。同図において、例えばイベント情報が「網１への切り替え試行（網２無し）」であった場合は、音声パケット送信部１２は送信間隔を「送信間隔１」に設定する。具体的に送信間隔１～６としては、例えば転送速度が速い網から遅い網への切り替え試行イベントの場合は送信間隔が大きくなるような値、逆に転送速度が遅い網から速い網への切り替え試行イベントの場合は送信間隔が小さくなるような値となっている。但し、値が同じの送信間隔が含まれていてもよい。なお、ここで「網」とは図１における移動パケット網＃１～＃Ｎのいずれかを指すものとする。
【００５０】
音声パケット送信部１２はまた、符号化音声データのパケット化処理において、自端末が現在接続しているアクセスメディアシステムの情報等を、相手方端末へ通知するためのイベント情報としてＲＴＰヘッダなどに付与する。これにより構成されたパケットは相手方端末へ送信されて、当該パケットに含まれるイベント情報が相手方端末のイベント管理部２０により利用されることになる。なお、イベント情報を付与する対象としては、ＲＴＰヘッダのほか、ＵＤＰ（User Datagram Protocol）やＴＣＰ（Transmission Control Protocol）のペイロード等も用いることができる。
【００５１】
順序入替補償部１５ａでは、イベント情報が入力されると、当該イベント情報に基づいて、順序入替補償バッファ１５ｂのバッファ長を制御する。図９にバッファ長の制御例を示す。この図に示す情報は、図２には表示していない所定のメモリ部に記憶されており、順序入替補償部１５ａによって制御の際に参照される。同図において、例えばイベント情報が「網１への切り替え試行（網２無し）」であった場合は、順序入替補償部１５ａはバッファ長を「バッファ長１」に設定する。具体的にバッファ長１～６としては、例えば転送速度が速い網から遅い網への切り替え試行イベントの場合はバッファ長が大きくなるような値、逆に転送速度が遅い網から速い網への切り替え試行イベントの場合はバッファ長が小さくなるような値となっている。但し、値が同じのバッファ長が含まれていてもよい。
【００５２】
音声符号化部１３には、イベント管理部２０からのイベント情報に加えて、バッファ閾値設定部２１から前述したジッタの標準偏差（ジッタ量）の情報が入力される。音声符号化部１３は、これらの情報に基づいて、音声符号化の処理における音声符号化レートと音声符号化アルゴリズムを制御する。なお、音声符号化レートと音声符号化アルゴリズムのどちらか一方だけを制御するようにしてもよい。
【００５３】
図１０に音声符号化の制御例を示す。この図に示す情報は、図２には表示していない所定のメモリ部に記憶されており、音声符号化部１３によって制御の際に参照される。同図において、例えばイベント情報が「網１への切り替え試行（網２無し）」でありかつジッタの情報が「ジッタ標準偏差１」であった場合は、「符号化レート１」および「アルゴリズム１」に設定される。具体的には、例えば転送速度が速い網から遅い網への切り替え試行イベントであってジッタ標準偏差が大きい場合は、音声符号化レートは値が小さいものが選ばれ、また音声符号化アルゴリズムは転送レートの小さくなるものが選ばれる。逆に、転送速度が遅い網から速い網への切り替え試行イベントであってジッタ標準偏差が小さい場合は、音声符号化レートは値が大きいものが選ばれ、また音声符号化アルゴリズムは転送レートの大きくなるものが選ばれる。但し、図９には値が同じの符号化レートや同一の符号化アルゴリズムが含まれていてもよい。
【００５４】
パケットロス補償制御部１８には、イベント管理部２０からのイベント情報に加えて、バッファ閾値設定部２１から前述したジッタの標準偏差（ジッタ量）の情報が入力される。パケットロス補償制御部１８は、これらの情報に基づいて、ロスしたパケットに対する補償処理における補償強度とロス補償アルゴリズムを制御する。ここで、ロス補償の強度とは、補償処理の対象とする同時ロスパケット数である。また、ロス補償アルゴリズムとはロスしたパケットを補償するアルゴリズムであり、例えば、過去に受信した音声パケットの情報のみから音声特徴量を抽出して、ロス区間（ロスしたパケット）の補完を行う、受信装置側で単独で処理を実行するアルゴリズムや、ロスの検出と補完を行うための音声データ以外の情報を予め送信装置側でパケットに付与する、送信装置と受信装置の機能を用いるアルゴリズムなどが含まれる。なお、ロス補償強度とロス補償アルゴリズムのどちらか一方だけを制御するようにしてもよい。
【００５５】
図１１にパケットロス補償の制御例を示す。この図に示す情報は、図２には表示していない所定のメモリ部に記憶されており、パケットロス補償制御部１８によって制御の際に参照される。同図において、例えばイベント情報が「網１への切り替え試行（網２無し）」でありかつジッタの情報が「ジッタ標準偏差１」であった場合は、「ロス補償強度１」および「アルゴリズム１」に設定される。具体的には、例えば転送速度が速い網から遅い網への切り替え試行イベントであってジッタ標準偏差が大きい場合は、ロス補償強度は強度が高いものが選ばれ、またロス補償アルゴリズムはロス耐性の高いものが選ばれる。逆に、転送速度が遅い網から速い網への切り替え試行イベントであってジッタ標準偏差が小さい場合は、ロス補償強度は強度が低いものが選ばれ、またロス補償アルゴリズムはロス耐性の低いものが選ばれる。但し、図１０には値が同じのロス補償強度や同一のロス補償アルゴリズムが含まれていてもよい。
【００５６】
バッファ閾値設定部２１では、イベント情報が入力されると、当該イベント情報に基づいて、前述したジッタバッファ閾値（但し、前述した５つの閾値のうち再生開始閾値、高速再生閾値、低速再生閾値、再生停止閾値の４つのみとする）の補正を行う。補正は、ハンドオーバーの切り替え候補が通知されると開始され、ハンドオーバー処理がキャンセルまたはハンドオーバーが完了するまで継続して実行される。閾値の補正量は、例えばイベント情報の種別や、ハンドオーバーの遷移状態（開始、途中、完了等）や、切り替え先あるいは切り替え元のアクセスメディアシステムの種類や、他の切り替え先候補の有無や、補正対象の閾値（上記４つ）などに応じて適宜設定される（図１２参照）。なお、自端末で生成されたイベント情報に基づきジッタバッファ閾値の補正を実行している間に、相手方端末からもイベント情報が通知された場合は、さらにジッタバッファ閾値を当該通知されたイベント情報に従って補正する（補正が加算される）。
【００５７】
ここで、上記閾値の補正には、補正量がゼロ、すなわちイベント情報が入力された時にジッタバッファ閾値を予め設定された固定値に一定時間維持する場合が含まれるものとする。このような制御を行った場合には、ハンドオーバーの際に非常に大きくパケットの到着時間が遅れたとしても、それをジッタと認識してジッタバッファ閾値を必要以上に（ハンドオーバー前後のアクセスメディアの特性から想定される以上に）大きな値に保持してしまうことが生じなくなる。その結果、メディア再生速度制御部１９における再生遅延が予期せず増大してしまうことを防止することができる。
【００５８】
図１２は、ジッタバッファ閾値の補正例を示したものである。この図に示す情報は、図２には表示していない所定のメモリ部に記憶されており、バッファ閾値設定部２１によって補正の際に参照される。同図において、例えば設定値「パラメータ１」は、イベント情報が「網１への切り替え試行（網２無し）」である場合に設定される補正量である。但し、図１２には同じ値の補正量が含まれていてもよい。
【００５９】
図１３は、上記補正されたジッタバッファ閾値に基づく、メディア再生速度制御部１９による再生速度の補正の例（図５等に対応する図）を示したものである。具体的には、例えば転送速度が速い網から遅い網への切り替え試行イベントの場合の補正として、正の値の補正量を設定して各ジッタバッファ閾値を変更した様子を示している。同図の再生速度制御において、各ジッタバッファ閾値が補正により増加することになるので、ハンドオーバー後（遅い網）では、例えば停止状態におけるジッタバッファ１６へのパケット蓄積量がハンドオーバー前（速い網）よりも大きくならないと再生が開始されない。また、再生状態において、ジッタバッファ１６のパケット蓄積量が減少しつつあるとき、ジッタバッファ閾値が増加しているので低速再生や再生停止への切り替えがハンドオーバー後ではハンドオーバー前よりも早く行われるようになる。こうした制御によって、ジッタバッファ１６でパケットの枯渇が起きにくくなっている。なお、補正量は各ジッタバッファ閾値でそれぞれ異なっていてもよいし、全ての閾値を一律に変更してもよい。
【００６０】
図１４は、ジッタバッファ閾値の他の補正例を示したものである。ここでは、補正量ではなく、補正後のジッタバッファ閾値の値そのものを「値１」～「値３０」として示している。補正するジッタバッファ閾値は、ａ）再生開始閾値、ｂ）高速再生閾値、ｃ）低速再生閾値、ｄ）最大バッファ閾値、ｅ）再生停止閾値である。同図において、例えばアクセスメディア「網１」については、ジッタ量ＧがＧ＜ジッタ量１の場合、再生開始閾値は「値１」に設定される。また、Ｇ≧ジッタ量１の場合は、「値２」とジッタ量Ｇとから所定の計算式を用いて算出した値を再生開始閾値に設定する。計算式の一例として、例えば次式を適用する。
再生開始閾値＝値２ × ジッタ量Ｇ／２０
この計算式によれば、ジッタ量が大きいほど再生開始閾値は大きくなり、ジッタバッファ１６の枯渇を効果的に回避することが可能である。
【００６１】
次に、図１５に示すフローチャートを参照して、通信端末装置１における、音声パケット受信部１４によるパケットの受信から音声復号部１７による復号までの処理について説明する。
順序入替補償部１５ａは、ジッタバッファ１６へ出力した最終データのＲＴＰシーケンス番号（以下、最終出力番号という）を管理しており、フローの最初の実行時に最終出力番号を「０」とする初期化を行う（ステップＳ１→ステップＳ２）。パケットの処理の途中すなわち２回目以降の実行の際は、初期化を行うことなくステップＳ３へ進む。順序入替補償部１５ａは、音声パケット受信部１４から受信データを受け取ると、当該受信データのＲＴＰシーケンス番号（以下、受信番号という）と最終出力番号との比較を行う（ステップＳ３）。
【００６２】
この比較において、
受信番号＝最終出力番号＋１
である場合は、受信データは正順で受信されていることになるので、順序入替補償部１５ａは当該受信データを直ちにジッタバッファ１６に出力し、最終出力番号を更新（インクリメント）する（ステップＳ６）。また、
受信番号 ≦ 最終出力番号
である場合は、その受信データはすでに受信済みのデータであるので、順序入替補償部１５ａは当該受信データを破棄する（ステップＳ９）。
【００６３】
また、
受信番号＞最終出力番号＋１
である場合は、当該受信データより前に再生されるべきデータがまだ受信されていないことになるので、そのデータの到着を待つため、当該受信データを順序入替補償バッファ１５ｂに一時的に格納する（ステップＳ４）。この時、順序入替補償バッファ１５ｂには先頭から受信番号が小さい順にデータが格納される。ここで、順序入替補償バッファ１５ｂには、イベント管理部２０から通知されるイベント情報に基づいて、蓄積可能な最大バッファ数が動的に設定されている。順序入替補償部１５ａは、現在のバッファ数と最大バッファ数とを比較する（ステップＳ５）。
【００６４】
そして、バッファ数が最大バッファ数に達していなければ、当該受信データについての処理は終了する。その後、次の受信データを受け取ったら、当該次の受信データについて再び図１５のフローを実行する。一方、バッファ数が最大バッファ数に達している場合には、順序入替補償部１５ａは順序入替補償バッファ１５ｂに正しい順序で格納された先頭のデータをジッタバッファ１６に出力して、最終出力番号を更新する（ステップＳ７）。
【００６５】
ステップＳ６で受信データをジッタバッファ１６に出力し、またはステップＳ７で順序入替補償バッファ１５ｂの先頭のデータをジッタバッファ１６に出力した後、さらに順序入替補償部１５ａは、順序入替補償バッファ１５ｂの先頭データ（ステップＳ７実行後の場合はジッタバッファ１６へ出力した後の先頭データ）のシーケンス番号（バッファ先頭番号）と最終出力番号との比較を行う（ステップＳ８）。そして、
バッファ先頭番号＝最終出力番号＋１
である場合は、順序入替補償バッファ１５ｂの当該先頭データは次に再生すべきデータであるため、再びステップＳ７を実行して、当該先頭データを出力し最終出力番号を更新する。以下、ステップＳ７とステップＳ８を繰り返す。
【００６６】
以上説明したように本実施形態によれば、イベント情報に基づいてパケットの送信間隔や、受信したパケットの順序入れ替え用のバッファのバッファ長や、送信する音声データの符号化処理の内容や、パケットロス補償の処理内容を制御することによって、ハンドオーバーの状態に応じた適切なパケット処理を行っている。これにより、ジッタバッファだけを備えた場合に比べて、ハンドオーバーの際にアプリケーションをより安定して実行させることができる。
【００６７】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
【図面の簡単な説明】
【００６８】
【図１】本発明の一実施形態による通信端末装置が利用される音声会話通信システムのネットワーク構成を概略的に示した図である。
【図２】図１の通信端末装置の構成を示す機能ブロック図である。
【図３】ジッタバッファに設定されたジッタバッファ閾値を示した図である。
【図４】図３の各閾値に基づいてメディア再生速度制御部が行う制御の状態遷移図である。
【図５】メディア再生速度制御部によって制御される音声データの再生速度の設定例である。
【図６】メディア再生速度制御部によって制御される音声データの再生速度の設定例である。
【図７】メディア再生速度制御部によって制御される音声データの再生速度の設定例である。
【図８】音声パケット送信部による送信間隔の制御例である。
【図９】順序入替補償部によるバッファ長の制御例である。
【図１０】音声符号化部による音声符号化の制御例である。
【図１１】パケットロス補償制御部によるパケットロス補償の制御例である。
【図１２】ジッタバッファ閾値の補正例である。
【図１３】補正されたジッタバッファ閾値に基づくメディア再生速度制御部による再生速度の補正の例である。
【図１４】ジッタバッファ閾値の他の補正例である。
【図１５】パケットの受信から復号までの処理について説明するフローチャートである。
【符号の説明】
【００６９】
１（１ａ、１ｂ）…通信端末装置２…通信アプリケーション部３…ＯＳ／デバイスドライバ部１１…網接続インタフェース部１２…音声パケット送信部１３…音声符号化部１４…音声パケット受信部１５ａ…順序入替補償部１５ｂ…順序入替補償バッファ１６…ジッタバッファ１７…音声復号部１８…パケットロス補償制御部１９…メディア再生速度制御部２０…イベント管理部２１…バッファ閾値設定部２２…ジッタバッファ制御部２３…マイク２４…スピーカ１００…移動パケット網２００…固定パケット網

【出願人】	【識別番号】０００２０８８９１【氏名又は名称】ＫＤＤＩ株式会社
【出願日】	平成１８年６月２６日（２００６．６．２６）
【代理人】	【識別番号】１００１０６９０９【弁理士】【氏名又は名称】棚井澄雄【識別番号】１０００６４９０８【弁理士】【氏名又は名称】志賀正武【識別番号】１０００８９０３７【弁理士】【氏名又は名称】渡邊隆
【公開番号】	特開２００８－５３９４（Ｐ２００８－５３９４Ａ）
【公開日】	平成２０年１月１０日（２００８．１．１０）
【出願番号】	特願２００６－１７５１５８（Ｐ２００６－１７５１５８）