JP2002026964A - 音声パケット送信装置、音声パケット受信装置、及びパケット通信システム - Google Patents

Abstract

(57)【要約】 【課題】 音質低下を最小限度内に抑制する。 【解決手段】 音声パケット送信装置から送信された音
声パケットを、所定のネットワークを介して受信する音
声パケット受信装置において、前記ネットワーク上のト
ラフィックに対応して変動する音声パケットの受信状況
を検出する受信状況検出手段と、当該受信状況検出手段
が検出した受信状況に応じた受信状況情報を、前記音声
パケット送信装置に送達するため、前記ネットワークに
送信する受信状況情報送信手段とを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はパケット通信システ
ムに関し、例えば、インターネットなどのパケット通信
網を使って音声通信を行う場合に適用し得るものであ
る。

【０００２】また、本発明は、かかるパケット通信シス
テムの構成要素としての音声パケット受信装置に関する
ものである。

【０００３】さらに本発明は、かかるパケット通信シス
テムの構成要素としての音声パケット送信装置に関する
ものである。

【０００４】

【従来の技術】現在、インターネットなどのパケット通
信網を使って音声通信をおこなう方法（いわゆるインタ
ーネット電話等）が盛んである。

【０００５】

【発明が解決しようとする課題】ところが、このような
パケット通信において良好な音質を確保するためには、
ビットレートと音質の関係が重要な問題となっている。

【０００６】ビットレートを上げれば符号化歪みは減り
音質が向上するが、ネットワーク上のトラフィックが増
加するため、パケット到着時間が不安定になり、バッフ
ァリング遅延やパケット損失（パケットロス）を許容せ
ざるを得ず、結果的に音質は低下する。一方ビットレー
トを下げれば、トラフィック面の問題は緩和されるが符
号化歪みが増大し、やはり音質は低下する。

【０００７】この問題に対する解決方法の一つとして、
無音圧縮方法が使われている。無音圧縮方法は音声の無
音期間中における伝送ビットを低減するために使用され
る方法で、送信側で１フレーム毎にそのフレームが有音
か無音かを判定（以下、「有音判定」）し、無音フレー
ムであれば有音フレームと比べて少ない情報量に符号化
して、ネットワークに送出する方法である。人間同士の
会話において、片方の話者につき一般に５０％〜６０％
は無音だといわれており、無音圧縮方法は、平均ビット
レートを下げるために、極めて効果の高い符号化方法で
ある。

【０００８】しかし、具体的な通信装置のなかで有音判
定をどのように実行するかについては、技術的に非常に
困難な面があり、有音判定レベルを厳しく（すなわち、
高く）設定し過ぎると本来発声区間であるはずのフレー
ムを無音と判定してしまったり、逆に有音判定レベルを
甘く（すなわち、低く）設定し過ぎると何も発声してい
ない区間のフレームでも有音と判定してしまったりする
場合があり、この判定誤りが音質劣化につながってい
る。よってネットワーク上のトラフィック量の観点から
ゆるされるのであれば、無音圧縮を極力おこなわないほ
うが、音質的に好ましい。

【０００９】図２に無音圧縮レベルＴｈｒｅｓｈ（有音
判定レベル）を変化させた場合の、平均ビットレートと
音質の関係を示す。横軸は無音圧縮無しのとき（すなわ
ち、Ｔｈｒｅｓｈ＝０のとき）の平均ビットレートを１
００％として、平均ビットレートを示しており、縦軸
は、ＭＯＳテスト（５段階評価で数値が高いほど音質が
高いことを示す）による音質評価を示している。

【００１０】Ｔｈｒｅｓｈをあげていくとビットレート
は下がり音質も下がるのがわかる。したがって音質を確
保するためには送信時のネットワークに問題が生じない
範囲で、低いＴｈｒｅｓｈを使うことが好ましいことが
わかる。ネットワーク上のトラフィックは時間とともに
変わるので、Ｔｈｒｅｓｈも、当該トラフィックの変動
に対して動的に適応して変更していくのが好ましい。

【００１１】有音判定レベルを動的に変更する方法とし
て、ノイズレベルに逐次適応していくＶＡＤ（有声検
出）アルゴリズムが知られている。

【００１２】当該ＶＡＤアルゴリズムを記載した文献と
しては、次の文献１がある。

【００１３】文献１：ＩＴＵ−Ｔ勧告 Ｇ．７２３．１
ＡｎｎｅｘＡただしこの文献１の方法は、時間的に変
化する背景雑音に有音判定レベルを適応させることが目
的であって、ネットワーク上のトラフィック量とは無関
係である。

【００１４】また、ネットワーク上のトラフィック量に
あわせて送信データレートを適応させる方法を記載した
文献としては、次の文献２がある。

【００１５】文献２：特開平１１−１７７６２３号公報
ただしこの文献２の方法は、マルチレートオーディオエ
ンコーダを使って指示した正確な値にビットレートを適
応させるものであり、有音判定レベルを指定するもので
はない。

【００１６】結局、これらの文献１、文献２に記載され
た方法よっても、なお、ネットワーク上のトラフィック
量に負担をかけない範囲で、有音検出レベルを一定時間
単位で変化させ、音質劣化を最小に押さえるパケット音
声通信を提供するという課題は、達成されていない。

【００１７】

【課題を解決するための手段】かかる課題を解決するた
めに、第１の発明では、音声パケット送信装置から送信
された音声パケットを、所定のネットワークを介して受
信する音声パケット受信装置において、前記ネットワー
ク上のトラフィックに対応して変動する音声パケットの
受信状況を検出する受信状況検出手段と、当該受信状況
検出手段が検出した受信状況に応じた受信状況情報を、
前記音声パケット送信装置に送達するため、前記ネット
ワークに送信する受信状況情報送信手段とを備えたこと
を特徴とする。

【００１８】また、第２の発明では、所定のネットワー
クを介して音声パケット受信装置に音声パケットを送信
する音声パケット送信装置において、（１）送信しよう
とする音声フレームが有音であるか無音であるかを、判
定レベルに応じて判定する判定手段と、（２）当該判定
手段が無音と判定した無音フレームは、有音と判定した
有音フレームよりも少ない情報量となるように符号化す
る音声符号化手段と、（３）前記ネットワーク上のトラ
フィックに対応して変動する前記音声パケットの受信状
況に応じて、前記音声パケット受信装置が送信した受信
状況情報を、前記ネットワークを介して受信する受信状
況情報受信手段と、（４）当該受信状況情報受信手段が
受信した受信状況情報に応じて、前記判定レベルを変更
する判定レベル変更手段とを備えることを特徴とする。

【００１９】さらに、第３の発明にかかるパケット通信
システムでは、請求項１の音声パケット受信装置と、請
求項２の音声パケット送信装置とを備えることを特徴と
する。

【００２０】

【発明の実施の形態】（Ａ）実施形態 以下、本発明の音声パケット送信装置、音声パケット受
信装置、及びパケット通信システムの実施形態について
説明する。

【００２１】（Ａ−１）第１の実施形態の構成 本実施形態の通信システム１０の全体構成を図１に示
す。

【００２２】図１において、当該通信システム１０は、
音声送信端末１１と、ＩＰ（インターネットプロトコ
ル）ネットワーク１２と、音声受信端末１３とを備えて
いる。

【００２３】このうち音声送信端末１１は、音声入力部
２０と、音声符号化部２１と、音声パケット送信部２２
と、受信状態情報受信部２３と、有音判定レベル計算部
２４とを備えている。

【００２４】音声入力部２０は、例えばマイクロホンな
どによって外部から入力される音声を取り込み、当該音
声を１フレーム長ごとに音声データＡＤに変換して出力
する部分である。

【００２５】音声入力部２０から当該音声データＡＤを
受け取る音声符号化部２１は、当該音声データＡＤを固
定時間長（一例として、３０ｍｓ）ごとに、音声フレー
ム（すなわち音声フレーム符号化データ）ＣＦに変換し
て出力する部分である。この音声符号化部２１は、無音
圧縮を実行する部分であるため、出力される音声フレー
ムＣＦは、無音フレーム（無音フレーム符号化データ）
ＣＦ２（図３参照）または有音フレーム（有音フレーム
符号化データ）ＣＦ１のいずれかである。

【００２６】すなわち、音声符号化部２１は図３に示す
ような内部構成を持ち、有音判定部２１Ａと、有音フレ
ーム符号化部２１Ｂと、無音フレーム符号化部２１Ｃと
を備えている。

【００２７】有音判定部２１Ａは、後述する有音判定レ
ベル計算部２４から供給される有音判定レベル（有音検
出レベル）ＬＴＨに応じて前記有音判定を実行し、１フ
レーム分の音声データＡＤごとに、有音と判定した音声
データＡＤは有音フレーム符号化部２１Ｂに供給し、無
音と判定した音声データＡＤは無音フレーム符号化部２
１Ｃに供給する部分である。

【００２８】有音判定にあたり、有音判定部２１Ａは、
１フレーム分の音声データＡＤの分散を計算し、その値
が前記有音判定レベルＬＴＨ以上の場合には有音、以下
の場合は無音と判定する。

【００２９】有音フレーム符号化部２１Ｂは有音フレー
ムのために符号化データサイズが比較的多くなる符号化
を実行して前記有音フレームＣＦ１を出力し、無音フレ
ーム符号化部２１Ｃは無音フレームのために符号化デー
タサイズが少なくなる符号化を実行して、前記無音フレ
ームＣＦ２を出力する部分である。例えば、有音フレー
ム符号化部２１Ｂは１６ビットＰＣＭ（Pulse Code M
odulation）方式で符号化を行い、無音フレーム符号化
２１Ｃは４ビットＰＣＭ方式で符号化を行うものであっ
てよい。

【００３０】そして、図１に示した前記音声パケット送
信部２２は、当該音声フレームＣＦをもとに音声パケッ
トＡＰを形成してネットワーク１２へ送出する部分であ
る。１つの音声パケットＡＰには、１または複数の音声
フレームＣＦが収容されていてよいが、通常は、複数フ
レーム（例えば５フレーム）が、１つの音声パケットＡ
Ｐに収容される。

【００３１】また、当該音声パケット送信部２２は、時
系列に送信される各音声パケットＡＰのパケットヘッダ
に、音声パケット系列の連続状態を示す連続情報を付与
する連続情報付与部２２Ａを備えている。本実施形態で
はこの連続情報を、送信順にしたがって１つずつインク
リメントされるパケット番号（ｐＩＤ）であるものとす
る。

【００３２】また、前記受信状態情報受信部２３は、ネ
ットワーク１２から受信状態情報ＳＩを受信する部分で
ある。ネットワーク１２はパケット通信網なので、当該
受信状態情報ＳＩも、パケットＲＰに収容されて伝送さ
れてくる。受信状態情報受信部２３は、このパケットＲ
Ｐのなかから受信状態情報ＳＩを抽出して有音判定レベ
ル計算部２４に出力する。

【００３３】有音判定レベル計算部２４は、当該受信状
態情報ＳＩに応じて、前記有音判定レベルＬＴＨを変更
する部分である。

【００３４】有音判定レベルＬＴＨは、前記無音圧縮レ
ベルＴｈｒｅｓｈに対応する閾値である。したがって上
述したように、有音判定レベルＬＴＨを高く設定し過ぎ
ると本来発声区間であるはずのフレームの音声データＡ
Ｄを無音と判定してしまったり、逆に有音判定レベルＬ
ＴＨを低く設定し過ぎると何も発声していない区間のフ
レームの音声データＡＤを有音と判定してしまったりす
る場合があり、音質劣化につながる。

【００３５】有音判定レベル計算部２４は、有音判定レ
ベルＬＴＨを受信状態情報ＳＩに適応させることによ
り、このような音質劣化を最小限度に抑制する。

【００３６】一方、ネットワーク１２を介して前記音声
パケットＡＰを受信するとともに、前記パケットＲＰの
送信元でもある音声受信端末１３は、音声パケット受信
部３０と、音声復号部３１と、音声出力部３２と、受信
状態情報作成部３３と、受信状態情報送信部３４とを備
えている。

【００３７】このうち音声パケット受信部３０は、前記
音声送信端末１１内の音声パケット送信部２２が送信し
た音声パケットＡＰを、ネットワーク１２から受信する
部分である。当該音声パケット受信部３０は、受信した
音声パケットＡＰから抽出した音声フレームＣＦは音声
復号部３１に供給し、前記パケット番号ｐＩＤは受信状
態を示す受信状態データＳＤとして受信状態情報作成部
３３に供給する。

【００３８】音声フレームＣＦを受け取った音声復号部
３１は、当該音声フレームＣＦを音声データＡＤに変換
して音声出力部３２に出力する。

【００３９】音声出力部３２は、例えばスピーカなどに
よって、当該音声データＡＤに対応した音声出力を行う
部分である。

【００４０】また、前記受信状態情報作成部３３は、前
記受信状態データＳＤをもとに後述する処理を行って受
信状態情報ＳＩを作成し、受信状態情報送信部３４へ出
力する部分である。

【００４１】受信状態情報送信部３４は、当該受信状態
情報ＳＩを収容したパケットＲＰを作成してネットワー
ク１２へ送出する。当該パケットＲＰは、宛先として前
記音声送信端末１１を指定するルーティング情報を付与
される。

【００４２】なお、前記音声送信端末１１および音声受
信端末１３は、一例として、ＩＰネットワークインタフ
ェース手段とサウンド入出力手段を備えたＰＣ（パーソ
ナルコンピュータ）等で実現することができる。

【００４３】以下、上記のような構成を有する本実施形
態の動作について説明する。

【００４４】（Ａ−２）第１の実施形態の動作外部から
入力した音声信号は、音声入力部２０で１フレーム単位
の音声データＡＤに変換され、音声符号化部２１に供給
される。

【００４５】音声符号化部２１による符号化、音声パケ
ット送信部２２によるパケット化を経て、前記音声パケ
ットＡＰがネットワーク１２に送出される。

【００４６】当該音声パケットＡＰには音声受信端末１
３を指定するルーティング情報が付与されているので、
ＩＰネットワーク１２によって音声受信端末１３まで転
送される。

【００４７】音声送信端末１１が次々と時系列に音声パ
ケットＡＰを送出すると、前記連続情報付与部２２Ａ
は、パケット番号ｐＩＤとして、第１番目の音声パケッ
トＡＰ（１）には「１」（１０進数表示）を付与する。

【００４８】同様に、第２番目の音声パケットＡＰ
（２）にはパケット番号ｐＩＤとして「２」が、第３番
目の音声パケットＡＰ（３）にはパケット番号ｐＩＤと
して「３」が、第４番目の音声パケットＡＰ（４）には
パケット番号ｐＩＤとして「４」が、…、第Ｎ番目の音
声パケットＡＰ（Ｎ）にはパケット番号ｐＩＤとして
「Ｎ」が、それぞれ付与される。

【００４９】したがって、ネットワーク１２のトラフィ
ックが通常範囲内にあり輻輳度が通常程度であれば、音
声受信端末１３における受信状態も正常となり、前記音
声パケットＡＰ（１）〜ＡＰ（Ｎ）が、１パケットも抜
け落ちることなくこの順番に受信される。このとき、音
声受信端末１３内において音声パケット受信部３０が出
力する受信状態データＳＤは、１ずつインクリメントさ
れた抜けのない連続した「１」〜「Ｎ」のパケット番号
ｐＩＤとなる。

【００５０】ところが、ネットワーク１２のトラフィッ
クが通常範囲を超えて輻輳度が通常よりも高まると、ネ
ットワーク１２中でパケット損失が発生して前記音声パ
ケットＡＰ（１）〜ＡＰ（Ｎ）のなかに受信できないも
のが生じる。

【００５１】このときは、前記音声パケット受信部３０
が出力する受信状態データＳＤに抜けが発生する。

【００５２】受信状態データＳＤが例えば、１，２，
３，４，…，Ｍ−１、Ｍ＋１，…，Ｎとなる場合は、Ｍ
番目の音声パケットＡＰ（Ｍ）がパケット損失によって
失われたケースである。

【００５３】このような受信状態データＳＤ（受信され
たパケット番号ｐＩＤ）を、受信状態情報ＳＩに変換す
るのは、図４に示した通りの、受信状態情報作成部３３
の処理による。

【００５４】図４のフローチャートは、Ｓ１０〜Ｓ１７
の各ステップから構成されている。図４では、受信状態
情報ＳＩとして、１００パケット当たりのパケット損失
数（すなわちパケット損失率）を算出して出力する。

【００５５】図４において、受信状態情報作成部３３の
処理がスタートすると、初期値として変数Ｎｕｍ、変数
Ｌｏｓｓ、変数Ｌａｓｔ＿ｐＩＤにはすべて、「０」が
代入される（Ｓ１０）。ここで、変数（パケットカウン
タ）Ｎｕｍは、受信された音声パケットＡＰの数を示
し、変数（パケットロスカウンタ）Ｌｏｓｓはパケット
損失によって失われた音声パケットＡＰの数を示し、変
数Ｌａｓｔ＿ｐＩＤは、これから図４のフローチャート
を用いて処理しようとしている音声パケットＡＰ（Ｘ）
の直前に受信された音声パケットＡＰ（Ｘ−１）が持っ
ていたｐＩＤを示す。

【００５６】なお、変数とは、ハードウエア的には、そ
の目的のためにメモリ上に確保された領域を意味する。
以下においても同じである。

【００５７】次に、関数Ｇｅｔ＿ｐＩＤが受信状態デー
タＳＤとして音声パケット受信部３０から供給された音
声パケットＡＰ（Ｘ）のｐＩＤの値を取得し、その値を
変数ｐＩＤに代入する（Ｓ１１）。この関数Ｇｅｔ＿ｐ
ＩＤは、新たなパケット番号ｐＩＤが音声パケット受信
部３０から供給されるたびに同じ処理を行う。

【００５８】そしてステップＳ１２では、変数Ｎｕｍの
値が「１００」（１０進数表示）に等しいかどうかが検
査され、等しい場合にはＹｅｓ側に分岐し、等しくない
場合にはＮｏ側に分岐する。

【００５９】最初、変数Ｎｕｍには前記「０」が代入さ
れているので、この分岐はＮｏ側が選択される。もっと
も早い場合でも、ステップＳ１２がＹｅｓ側に分岐する
のは、１０１番目の音声パケットＡＰ（１０１）が受信
されたときである。パケット損失があるとこの１０１
が、当該パケット損失数だけ大きくなり、ステップＳ１
２のＹｅｓ側の分岐が選択されるタイミングが遅くな
る。

【００６０】Ｘ（１≦Ｘ≦１０１。ただしＸは自然数）
番目のパケットである音声パケットＡＰ（Ｘ）を処理す
るときには、それまでにパケット損失がなければ、当該
変数Ｎｕｍの値は、Ｘ−１である。

【００６１】ステップＳ１２がＮｏ側に分岐するとステ
ップＳ１３の処理が行われる。

【００６２】ステップＳ１３では、当該音声パケットＡ
Ｐ（Ｘ）の変数ｐＩＤの値が、前記Ｌａｓｔ＿ｐＩＤに
「１」を加えた値に等しいかどうかが検査される。すな
わち、前記受信状態データＳＤとして音声パケット受信
部３０から供給されるｐＩＤが１つずつインクリメント
されていて抜けがないかどうかが調べられる。抜けがな
ければ、ステップＳ１３はＹｅｓ側に分岐して、処理は
ステップＳ１７に進み、抜けがあればＮｏ側に分岐して
ステップＳ１６に進む。

【００６３】例えば、Ｌａｓｔ＿ｐＩＤの初期値は前記
「０」なので、最初に音声送信端末１１から送信された
音声パケットＡＰ（１）がネットワーク１２で失われる
ことなく、最初に音声受信端末１３に受信されたなら
ば、音声パケットＡＰ（１）のｐＩＤの「１」と、Ｌａ
ｓｔ＿ｐＩＤ＋１の値は等しくなる。

【００６４】Ｘ番目の音声パケットＡＰ（Ｘ）を処理す
るときには、音声パケットＡＰ（Ｘ）またはＡＰ（Ｘ−
１）の双方ともがパケット損失によって失われていない
場合にだけ、ステップＳ１３のＹｅｓ側が選択される。

【００６５】当該ステップＳ１３につづいて行われるス
テップＳ１７では、Ｌａｓｔ＿ｐＩＤ＋＋およびＮｕｍ
＋＋が行われる。すなわち、変数Ｌａｓｔ＿ｐＩＤと変
数Ｎｕｍがインクリメントされる。当該ステップＳ１７
の次には前記ステップＳ１１が実行される。

【００６６】一方、ステップＳ１３につづいて行われる
ステップＳ１６では、変数Ｌａｓｔ＿ｐＩＤおよびＮｕ
ｍに加えて、変数Ｌｏｓｓもインクリメントされて、処
理は、前記ステップＳ１２へ戻る。

【００６７】また、前記ステップＳ１２がＹｅｓ側に分
岐すると、ステップＳ１４において、Ｓｅｎｄ（Ｌｏｓ
ｓ）の処理が行われる。すなわち送信関数Ｓｅｎｄ（）
により、変数Ｌｏｓｓの値が、前記受信状態情報ＳＩと
して、受信状態情報送信部３４に出力される。

【００６８】ステップＳ１４の次にはステップＳ１５に
おいて、変数Ｌｏｓｓと変数Ｎｕｍに初期値「０」が代
入されて、処理はステップＳ１３に進む。なお、このと
き変数Ｌａｓｔ＿ｐＩＤは初期化されないので、ステッ
プＳ１３における変数ｐＩＤとＬａｓｔ＿ｐＩＤの関係
はその前の関係が維持される。すなわち、パケット番号
ｐＩＤとしては、１０１以上の連続番号を使用すること
ができる。

【００６９】音声送信端末１１と音声受信端末１３のあ
いだで、パケット損失のない正常な通信が維持されるか
ぎり、ステップＳ１１、Ｓ１２、Ｓ１３、Ｓ１７によっ
て構成されるループが繰り返され、当該ループの１０１
回目の繰り返しごと（１００パケット期間ごと）にステ
ップＳ１４とＳ１５の処理が行われる。この場合、パケ
ット損失数は「０」なので、関数Ｓｅｎｄ（Ｌｏｓｓ）
によって出力される受信状態情報ＳＩは「０」である。

【００７０】ただし、パケット損失があると、その損失
数だけ、前記ステップＳ１２、Ｓ１３、Ｓ１６によって
構成されるループが繰り返されることになる。

【００７１】前記ステップＳ１４によって、受信状態情
報ＳＩとして前記変数Ｌｏｓｓの値を受け取った受信状
態情報送信部３４は、その値をパケットＲＰのなかに収
容し、音声送信端末１１に宛ててネットワーク１２へ送
出する。

【００７２】ネットワーク１２から当該パケットＲＰを
受信した音声送信端末１１の内部では、受信状態情報受
信部２３が当該パケットＲＰから受信状態情報ＳＩとし
て前記変数Ｌｏｓｓの値を抽出し、有音判定レベル計算
部２４に出力する。

【００７３】この有音判定レベル計算部２４が、当該変
数Ｌｏｓｓの値をもとに有音判定レベルＬＴＨとして、
音声符号化部２１にＴｈｒｅｓｈを設定する処理を、図
５のフローチャートに示す。

【００７４】図５のフローチャートは、Ｓ２０〜Ｓ２７
の各ステップから構成されている。

【００７５】図５において、有音判定レベル計算部２４
の処理がスタートする（Ｓ２０）と、関数Ｇｅｔ＿Ｌｏ
ｓｓが、受信状態情報ＳＩとして受信状態情報受信部２
３から供給された前記変数Ｌｏｓｓの値を取得して、有
音判定レベル計算部２４側の変数Ｌｏｓｓに代入する
（Ｓ２１）。関数Ｇｅｔ＿Ｌｏｓｓは、新たな受信状態
情報ＳＩが供給されるたびに同じ動作を繰り返す。

【００７６】なお、図５のフローチャートにおいて、変
数Ｌｏｓｓは、この有音判定レベル計算部２４側の変数
Ｌｏｓｓを意味するものとする。この変数Ｌｏｓｓも、
前記受信状態情報作成部３３側の変数Ｌｏｓｓも、パケ
ット損失数を格納している点では同じであるが、前記受
信状態情報作成部３３側の変数Ｌｏｓｓが１つの１００
パケット期間中にインクリメントされてその値が変化し
得るパケットロスカウンタであったのに対し、この変数
Ｌｏｓｓの値は、１つの１００パケット期間中は一定不
変である。

【００７７】次にステップＳ２２では、関数Ｇｅｔ＿Ｔ
ｈｒｅｓｈが直前の１００パケット期間に音声符号化部
２１で使用した有音判定レベルＬＴＨ（現在、音声符号
化部２１で使用している有音判定レベルＬＴＨ等であっ
てもよい）の値としてＴｈｒｅｓｈの値を取得し、変数
Ｔｈｒｅｓｈ０に代入する。関数Ｇｅｔ＿Ｔｈｒｅｓｈ
も、新たな受信状態情報ＳＩが供給されるたびに同じ動
作を繰り返す。

【００７８】ここで、変数Ｔｈｒｅｓｈ０は、直前の１
００パケット期間に音声符号化部２１で使用した有音判
定レベルＴＬＨの値を格納するための変数である。

【００７９】また、Ｔｈｒｅｓｈの値とは、有音判定部
２１Ａによって１フレーム分の音声データＡＤの分散と
比較される値である。その値が大きいほど有音判定レベ
ルＬＴＨが高くなって、前記有音判定部２１Ａにより、
音声データＡＤが無音フレームであるとの判定結果が出
される傾向が高まり、反対にその値が小さいほど有音判
定レベルＬＴＨが低くなって、音声データＡＤが有音フ
レームであるとの判定結果が出される傾向が高まる。

【００８０】ステップＳ２２につづくステップＳ２３で
は、変数Ｌｏｓｓの値が「０」であるかどうかが検査さ
れ、「０」の場合にはＹｅｓ側に分岐して処理はステッ
プＳ２４に進み、「０」でない場合にはＮｏ側に分岐し
てステップＳ２７へ進む。

【００８１】ステップＳ２４では、前記変数Ｔｈｒｅｓ
ｈ０の値から予め定めた変化幅α（α＞０）を減算して
得られる値を、変数Ｔｈｒｅｓｈに代入する。ここで、
変数Ｔｈｒｅｓｈは、基本的に、次の１００パケット期
間に音声符号化部２１で使用する有音判定レベルＬＴＨ
を格納するための変数である。

【００８２】この処理は、直前の１００パケット期間中
におけるパケット損失数が「０」であれば、現状でもビ
ットレートは十分に低くトラフィック面の問題はないと
して、ビットレートを上げて符号化歪みを減少させる方
向に制御していることになる。

【００８３】ステップＳ２４の次に実行されるステップ
Ｓ２５では、関数Ｌｉｍｉｔａｔｉｏｎによって、当該
関数Ｔｈｒｅｓｈの値が予め定められた最大値以下ない
し最小値以上の有効範囲内に限定される。すなわち、変
数Ｔｈｒｅｓｈの値が当該有効範囲内にある場合にはそ
の値がそのまま使用され、（有効範囲よりも大きい場合
には関数Ｌｉｍｉｔａｔｉｏｎによって規定される最大
値が変数Ｔｈｒｅｓｈの値とされ、）有効範囲よりも小
さい場合には関数Ｌｉｍｉｔａｔｉｏｎによって規定さ
れる最小値が変数Ｔｈｒｅｓｈの値とされる。

【００８４】次にステップＳ２６では、当該変数Ｔｈｒ
ｅｓｈの値が、関数ＳｅｔＥｎｃによって音声符号化部
２１の有音判定レベルＬＴＨとして設定され、処理は、
前記ステップＳ２１に戻る。

【００８５】一方、前記ステップＳ２３においてＮｏ側
の分岐が選択された場合に実行されるステップＳ２７で
は、変数Ｔｈｒｅｓｈ０の値にＬｏｓｓ＊βを加算して
得られる値を、前記変数Ｔｈｒｅｓｈに代入する。ここ
で、「＊」は乗算を意味する演算子で、Ｌｏｓｓ＊β
は、変数Ｌｏｓｓの値にβ（＞０）を乗算して得られる
値を意味する。

【００８６】この処理は、直前の１００パケット期間中
におけるパケット損失数が「０」でなければ、現状でも
ビットレートは高すぎてトラフィック面の問題が大きい
として、たとえ符号化歪みが増大するとしてもビットレ
ートを下げる方向に制御することを意味する。

【００８７】なお、βの値は、前記αと等しくてもよく
異なってもよい。

【００８８】このステップＳ２７の次にも前記ステップ
Ｓ２５とＳ２６が実行される。

【００８９】そして、音声符号化部２１は、ステップＳ
２６で有音判定レベルＬＴＨとして設定された変数Ｔｈ
ｒｅｓｈの値に基いて、次の１００パケット期間の有音
判定を行う。

【００９０】以上の手順を繰り返すことで、直前１００
パケットの受信状態を反映した有音判定レベルＬＴＨで
音声通信を行うことができる。

【００９１】図５において、ネットワーク１２のトラフ
ィックが安定している場合、ステップＳ２３のＹｅｓ側
とＮｏ側がほぼ均等な頻度で選択されて、有音判定レベ
ルＬＴＨは一定値（最適値）をはさんで小さな振幅で変
動する状態を維持することになる。

【００９２】そして、ネットワーク１２のトラフィック
が変動すればそれに応じて、ステップＳ２３のＹｅｓ側
とＮｏ側の選択頻度が不均等となり、前記最適値の変動
に追従する。

【００９３】要するに、本実施形態では、音声パケット
ＡＰの受信状態を計算し、音声パケットＡＰの受信状態
が悪いときには有音判定レベルＬＴＨを上げ、受信状態
にゆとりがあるときには有音判定レベルＬＴＨを下げる
ことができる。

【００９４】これにより、ネットワーク１２上のトラフ
ィックが混雑しているときは音声パケットＡＰの平均ビ
ットレートを下げパケット損失やジッタ増加による音質
劣化を抑制し、前記トラフィックにゆとりがある場合に
は、無音圧縮による音質劣化を抑制することができ、平
均ビットレートをネットワークの混雑状況に自動適応さ
せることができる。

【００９５】なお、図４のフローチャート（特にステッ
プＳ１１、Ｓ１２、Ｓ１３、Ｓ１７によって構成される
ループ、またはステップＳ１１、Ｓ１２、Ｓ１３、Ｓ１
６によって構成されるループ）は、通常、１００パケッ
ト期間に１００回繰り返されるが、図５のフローチャー
トは、１００パケット期間、または１００パケット期間
と１００パケット期間のあいだの期間などにステップＳ
２１、Ｓ２２、Ｓ２３、Ｓ２４、Ｓ２５、Ｓ２６によっ
て構成されるループまたはステップＳ２１、Ｓ２２、Ｓ
２３、Ｓ２７、Ｓ２５、Ｓ２６によって構成されるルー
プが１回だけ実行されればよい。

【００９６】（Ａ−３）第１の実施形態の効果 以上説明したように、本実施形態によれば、ネットワー
ク（１２）の混雑状態に対応した適切な平均ビットレー
トを設定することで、高すぎるビットレートによっても
たらされるパケット損失を防止するとともに、低すぎる
ビットレートによってもたらされる符号化歪みに起因す
る音質低下も可及的に低減して、音質低下を最小限度内
に抑制し、高品質で信頼性の高い音声通信を実現するこ
とができる。

【００９７】また、パケット損失が発生するような通信
状態ではパケット損失にともなってジッタも増加する可
能性が高いが、本実施形態でパケット損失を防止すれ
ば、当該ジッタによる音質低下も低減することが可能で
ある。

【００９８】(Ｂ）第２の実施形態 以下では、本実施形態が第１の実施形態と相違する点に
ついてのみ説明する。

【００９９】本実施形態では、音声符号化部の内部で有
音判定レベルＬＴＨが音声データＡＤの内容に応じて動
的に変化する無音圧縮方式を適用する。

【０１００】本実施形態は、有音判定レベル計算部によ
って算出される変数Ｓｃａｌｅに関連する部分に特徴が
ある。

【０１０１】また、本実施形態は、前記文献１に記載さ
れた音声符号化方式を実現することができる。

【０１０２】（Ｂ−１）第２の実施形態の構成および動
作 本実施形態の通信システム４０の全体構成は、図１に示
した第１の実施形態の通信システム１０と同じである。
したがって、第１の実施形態と同じ符号２０、２２、２
３、３０〜３４を付した各部の機能は、第１の実施形態
と同じである。

【０１０３】ただし本実施形態の有音判定レベル計算部
４４は、前記有音判定レベル計算部２４と異なり、受信
状態情報ＳＩ（Ｌｏｓｓ）を受け取って、有音判定レベ
ルＬＴＨ（Ｔｈｒｅｓｈ）ではなく有音判定スケールＳ
ｃａｌｅを計算する部分である。有音判定レベル計算部
４４が、受信状態情報ＳＩをもとに有音判定スケールＳ
ｃａｌｅを求める処理は、後述する図７に示した通りで
ある。

【０１０４】また、音声符号化部４１の内部構成も、図
６に示すように、第１の実施形態の音声符号化部２１と
相違する。本実施形態の音声符号化部４１は、ＶＡＤ方
式による有音判定方法を組み込んだＡＣＥＬＰ（Algebr
aic Code Exited LinerPrediction）方式による符号
化を実行する。

【０１０５】ＶＡＤ方式を組み込んだＡＣＥＬＰ方式の
原理は、前記文献１に詳細に述べられている通りのもの
であるが、文献１に記載されたような通常のＶＡＤ方式
では、ＬＰＣ（Linear Predictive Coding）分析によ
る平均残差パワーＥｒｒとノイズレベルＮｌｅｖに基く
有音判定レベルＴｈｒｅｓｈ（Ｎｌｅｖ）を閾値として
決定するのに対し、本実施形態では、当該Ｔｈｒｅｓｈ
の値に有音判定Ｓｃａｌｅ蓄積部４５から読み出したＳ
ｃａｌｅの値（初期値は１．００）を乗じたＳｃａｌｅ
＊Ｔｈｒｅｓｈ（Ｎｌｅｖ）を閾値ＳＣとする。

【０１０６】したがって、文献１の方式では、パケット
損失率（前記受信状態ＳＩ）を閾値に反映させることが
不可能であるが、本実施形態ではそれが可能となる。

【０１０７】また、第１の実施形態と比べた場合、第１
の実施形態のＴｈｒｅｓｈ（有音判定レベルＬＴＨ）が
図５のフローチャートによって生成されたものであるの
に対し、本実施形態の当該Ｔｈｒｅｓｈは、前記平均残
差パワーＥｒｒとノイズレベルＮｌｅｖに基いて生成さ
れたＴｈｒｅｓｈ（Ｎｌｅｖ）である点で相違する。

【０１０８】図６において、当該音声符号化部４１は、
有音フレーム符号化部４１Ｂと、無音フレーム符号化部
４１Ｃと、音声分析部４２と、有音判定部４３と、有音
判定Ｓｃａｌｅ蓄積部４５とを備えている。

【０１０９】このうち有音フレーム符号化部４１Ｂは前
記有音フレーム符号化部２１Ｂに対応し、無音フレーム
符号化部４１Ｃは前記無音フレーム符号化部２１Ｃに対
応し、有音判定部４３は前記有音判定部２１Ａに対応す
る。

【０１１０】ただし有音判定部４３は、有音判定を行う
点では、前記有音判定部２１Ａと同じであるが、有音フ
レーム符号化部４１Ｂまたは無音フレーム符号化部４１
Ｃに音声データＡＤを供給する機能は音声分析部４２が
装備している等、その他の点でも、後述する種々の相違
を有する。

【０１１１】音声入力部２０から１フレーム分の音声デ
ータＡＤを受け取る音声分析部４２は、当該音声データ
ＡＤに対して音声分析を実行して、その分析結果を有音
判定部４３に供給する。

【０１１２】本実施形態では、当該音声分析として、Ｌ
ＰＣ分析を行い、その分析結果や、音声データＡＤから
抽出することのできる付帯情報（例えば、パワー計算結
果やゼロクロス回数など）を、前記Ｔｈｒｅｓｈ（Ｎｌ
ｅｖ）を生成するために用いる基礎情報ＢＩとして有音
判定部４３に供給する。

【０１１３】有音判定部４３は、当該基礎情報ＢＩに基
づいて、Ｔｈｒｅｓｈ（Ｎｌｅｖ）を生成する機能を装
備している。

【０１１４】なお、基礎情報ＢＩは、Ｔｈｒｅｓｈ（Ｎ
ｌｅｖ）を生成するために用いられるほか、有音判定の
対象とするためにも使用される。

【０１１５】一方、有音判定Ｓｃａｌｅ蓄積部４５は、
有音判定レベル計算部４４から有音判定スケールＳｃａ
ｌｅを受け取って蓄積し、有音判定部４３に供給する。

【０１１６】前記有音判定部４３は、前記Ｔｈｒｅｓｈ
（Ｎｌｅｖ）とこの有音判定スケールＳｃａｌｅを乗算
して、判定用閾値ＳＣ（＝Ｓｃａｌｅ＊Ｔｈｒｅｓｈ
（Ｎｌｅｖ））を得る。この判定用閾値ＳＣが、有音判
定部４３における有音判定に使用される有音判定レベル
となる。

【０１１７】当該有音判定部４３による有音判定の判定
結果ＪＡが音声分析部４２に供給されると、音声分析部
４２は、当該判定結果ＪＡに応じて１フレーム分の音声
データＡＤを、有音フレーム符号化部４１Ｂまたは無音
フレーム符号化部４１Ｃのいずれかに供給する。

【０１１８】次に、前記有音判定スケール蓄積部４４に
有音判定スケールＳｃａｌｅを供給する有音判定レベル
計算部４４の処理について説明する。この処理は、図７
のフローチャートに示すように、受信状態情報ＳＩ（Ｌ
ｏｓｓ）を有音判定スケールＳｃａｌｅに変換する処理
である。

【０１１９】図７のフローチャートは、Ｓ３０〜Ｓ３５
の各ステップから構成されている。

【０１２０】図７において、処理がスタートすると（Ｓ
３０）、実数型変数Ｓｃａｌｅには初期値として実数
１．００が格納される。

【０１２１】次に、関数Ｇｅｔ＿Ｌｏｓｓが、受信状態
情報ＳＩとして受信状態情報受信部２３から供給された
前記変数Ｌｏｓｓの値を取得して、有音判定レベル計算
部２４側の変数Ｌｏｓｓに代入する（Ｓ３１）。

【０１２２】このステップＳ３１は、前記ステップＳ２
１とまったく同じ処理である。したがってステップＳ３
１でも、関数Ｇｅｔ＿Ｌｏｓｓは、新たな受信状態情報
ＳＩが供給されるたびに同じ動作を繰り返すことにな
る。

【０１２３】そして、当該変数Ｌｏｓｓに格納された値
が「０」であれば、処理はステップＳ３３に進み、
「０」でなければステップＳ３５に進む。

【０１２４】ステップＳ３３では、直前の変数Ｓｃａｌ
ｅの値（初回は前記初期値１．００）にαを乗じて得ら
れる値（Ｓｃａｌｅ＊α）が、変数Ｓｃａｌｅに代入さ
れる。ここで、αは、０＜α＜１の実数定数である。

【０１２５】ステップＳ３３につづくステップＳ３４で
は、当該変数Ｓｃａｌｅの値が、関数ＳｅｔＥｎｃによ
って有音判定部４３の判定用閾値ＳＣとして設定され、
処理は、前記ステップＳ３１に戻る。

【０１２６】一方、前記ステップＳ３５では、直前の変
数Ｓｃａｌｅの値に変数Ｌｏｓｓの値と定数βの値を乗
算した結果を、変数Ｓｃａｌｅに代入する。ここで、定
数βは、１＜βの実数（または整数）である。

【０１２７】当該ステップＳ３５の次には、前記ステッ
プＳ３４が行われ、変数Ｓｃａｌｅの値が、関数Ｓｅｔ
Ｅｎｃによって有音判定部４３に供給され、処理は、前
記ステップＳ３１に戻る。

【０１２８】このような図７のフローチャートによれ
ば、パケット損失のない状態がつづくと定数αが累乗さ
れて変数Ｓｃａｌｅの値が低下するので判定用閾値ＳＣ
も低下して行き、反対に、パケット損失のある状態がつ
づくと定数βが累乗されて判定用閾値ＳＣが上昇して行
く。

【０１２９】ネットワーク１２のトラフィックが安定
し、音声データＡＤの内容も安定している場合、ステッ
プＳ３２のＹｅｓ側とＮｏ側がほぼ均等な頻度で選択さ
れて、判定用閾値ＳＣは一定値（最適値）をはさんで小
さな振幅で変動する状態を維持することになる。

【０１３０】そして、ネットワーク１２のトラフィック
または音声データＡＤの内容が変動すればそれに応じ
て、ステップＳ３２のＹｅｓ側とＮｏ側の選択頻度が不
均等となり、前記最適値の変動に追従する。

【０１３１】第１の実施形態では、ネットワーク１２の
トラフィックが変動し、受信状態情報ＳＩが変化した場
合にだけ有音判定レベルＬＴＨが変化したが、本実施形
態では、ネットワーク１２のトラフィックがほぼ一定で
あっても、音声データＡＤの内容が変化すると、その変
化に応じて判定用閾値ＳＣが変化し得る。

【０１３２】（Ｂ−２）第２の実施形態の効果 本実施形態によれば、第１の実施形態の効果と同等な効
果を得ることができる。

【０１３３】加えて、本実施形態では、判定用閾値（Ｓ
Ｃ）が、音声入力部（２０）から供給される音声データ
（ＡＤ）の内容に応じても動的に変動するため、より適
切で精密なビットレートの制御が可能である。

【０１３４】(Ｃ）他の実施形態 なお、上記第１および第２の実施形態では、２台の端末
１２、１３間で音声パケットＡＰを送受する場合につい
て説明したが、図８に示すように、同一のネットワーク
１２に多数の端末５１〜５６を接続して複数組の端末間
で音声パケット送受を行うシステム構成としてもよい。
図８の場合、前記端末１１と１３のように相互に通信す
る端末は、本発明に対応したものでなければならない
が、システム中に、本発明に対応していない端末が混在
してもかまわない。

【０１３５】また、第１および第２の実施形態では、前
記音声送信端末１１および音声受信端末１３の実現例と
して、ＩＰネットワークインタフェース手段とサウンド
入出力手段を備えたＰＣ（パーソナルコンピュータ）を
示したが、この各ＰＣを、図９に示すように複数の装置
を組合せたもので置換することもできる。

【０１３６】たとえば、電話機６４とＰＢＸ（構内交換
機）６３と電話−パケット変換装置６２とを組み合わせ
たものや、ＩＰプロトコルに対応した電話−パケット変
換装置６０と電話機６１を組み合わせたもの等で、前記
各ＰＣを置換してもよい。変換装置としては、例えばＶ
ｏＩＰ（voice over IP）ゲートウェイ装置である沖
電気製ＢＳ−１２００などを用いることができる。

【０１３７】また、上記第１および第２の実施形態で
は、前記連続情報として、パケット番号ｐＩＤを使用し
たが、当該パケット番号ｐＩＤの替わりとして、例えば
タイムスタンプ情報などを使用することもできる。タイ
ムスタンプ情報とは、音声パケットＡＰが送信された時
刻や音声パケットＡＰが生成された時刻を示す情報であ
る。

【０１３８】連続情報としてタイムスタンプを使う場合
の処理の概略を、図１を参照しながら説明すると、次の
ようになる。

【０１３９】まず、音声パケット送信部２２内の連続情
報付与部２２Ａは、各音声パケットＡＰを送出する際に
タイムスタンプを当該音声パケットＡＰに付加する。

【０１４０】次に、音声パケット受信部３０は、受取っ
た各音声パケットＡＰのタイムスタンプと、現在の時刻
を比較し、この音声パケットＡＰの転送に要した時間
（パケット転送時間）を算出する。

【０１４１】そして、受信状態情報作成部３３は、あら
かじめ定めた平均パケット転送時間と、各音声パケット
ＡＰのパケット転送時間を比較することでパケット揺ら
ぎ時間（ジッタ）を得、１００パケット毎にジッタ分散
を計算し、これを受信状態情報ＳＩとする。

【０１４２】なお、前記パケット番号ｐＩＤやこのタイ
ムスタンプ情報等の連続情報を音声パケットＡＰに付加
する方法は、任意の方法で良く、ＲＴＰ（ＲｅａｌＴｉ
ｍｅＴｒａｎｓｐｏｒｔ Ｐｒｏｔｃｏｌ）などの既存
のプロトコルを使っても良い。

【０１４３】また、前記受信状態情報の送付間隔、すな
わちパケットＲＰの送信間隔は任意であるが、あまり頻
繁に行うと、パケットＲＰの伝送自体がネットワーク
（１２）のトラフィックに対する負荷となるので、注意
が必要である。

【０１４４】さらに、前記符号化方法としては、ＰＣＭ
の１６ビットと、４ビットを使って説明したが、１フレ
ームあたりの音声符号化データ量が有音フレームより無
音フレームのほうが少なくなる組み合わせであれば、ど
のような方法を使用してもよい。例えばＩＴＵ−Ｔ勧告
Ｇ．７２９ ＡｎｎｅｘＢに示されるＧ．７２９のた
めの無音圧縮スキームを使っても良い。

【０１４５】なお、上記第１および第２の実施形態で
は、有音判定レベルＬＴＨを動的に制御する方法をしめ
したが、無音圧縮機能をＯＮ・ＯＦＦする２値制御で行
っても良い。この場合は、このようなＯＮ・ＯＦＦスイ
ッチを持っている音声符号化部に全く変更を加えること
なく、本発明を実現することが可能である。

【０１４６】また、上記第１および第２の実施形態で
は、音声パケットＡＰに関しては、音声送信端末１１は
送信機能のみを備え、前記音声受信端末１３は受信機能
のみを備えていたが、端末１１，１３ともに、音声パケ
ットの送信機能と受信機能の両機能を装備して双方向に
音声パケット通信ができる構成としてもよい。

【０１４７】その場合、前記受信状態情報ＳＩは、独立
したパケットＲＰに収容するのではなく、端末１３から
端末１１に宛てて送信する音声パケットの一部に収容す
るようにすることも可能である。

【０１４８】また、この場合には、図１０に示すよう
に、有音判定レベル計算部８１を、受信端末（送受信端
末）７１内に設けても良い。

【０１４９】さらに、図４のステップＳ１２では、音声
パケットＡＰの１００パケット当たりのパケット損失数
を検査するために、変数Ｎｕｍの値が「１００」と等し
いかどうかを調べたが、当該「１００」は１００以外の
任意の定数に変更し、任意のパケット数ごとのパケット
損失数を検査することができる。

【０１５０】なお、受信状況情報としては、前記受信状
態情報ＳＩの替わりに、損失率の他の特徴量（例えばジ
ッタの程度や遅延時間の程度）を検査するようにしても
よい。すなわち受信状態情報としては、ネットワーク
（１２）上のトラフィック量に関わる音声パケットＡＰ
の受信状態を表す変数であれば何を使っても良い。

【０１５１】また、図５のフローチャートでは、有音判
定レベルＬＴＨを変更するために定数α、βを使った
が、パケット受信状態が悪いと判断した場合に有音判定
レベルＬＴＨを上げ、パケット受信状態にゆとりがある
と判断した場合には、有音判定レベルＬＴＨを下げるこ
とができる方法であれば、その他の方法でも使用可能で
ある。

【０１５２】例えば、過去数期間の受信状態を記憶して
おきそれを反映させた形で有音判定レベルのレベル変更
を行っても良い。一例として、１０期間連続でＬｏｓｓ
＝０の場合にはじめて有音判定レベルＬＴＨをαだけ上
げる方法などを使っても良い。

【０１５３】また、図５のフローチャートでは、変数Ｌ
ｏｓｓの値が「０」であるか否かに応じて２通りのルー
プを実行するようにしたが、「０」でないケースでも変
数Ｌｏｓｓの数値範囲には１〜１００の幅があり得るの
で、例えば「１」の場合と「１０」の場合とで異なるル
ープを実行するようにしてもよい。

【０１５４】さらに、図４のフローチャートは上述した
ように非常に繰り返し回数が多いので、このフローチャ
ートの処理が、システム全体の動作速度向上のボトルネ
ックとなる可能性がある。したがって、図４のフローチ
ャートをもっと効率的に構成すると、システム全体を高
速化できるなど、利点が大きい。

【０１５５】例えば、ネットワーク（１２）の輻輳度な
どの条件によっては、図４のフローチャートのように前
記パケットカウンタＮｕｍの値に応じて分岐するのでは
なく、パケットロスカウンタＬｏｓｓの値に応じて分岐
するフローチャートを構成したほうが効率的となる可能
性もある。一例としては、パケットロスカウンタＬｏｓ
ｓの値が５になったらそのときのパケット損失率を計算
し、当該パケット損失率を前記受信状態情報ＳＩとして
用いるようにしてもよい。

【０１５６】また、上記第１および第２の実施形態で
は、ＩＰプロトコルに対応したＩＰネットワーク１２を
使用したが、本発明で用いるネットワークは、ＩＰネッ
トワークに限らない。

【０１５７】なお、図４、図５、図７のフローチャート
の機能は、どのようなプログラミング言語を用いて記述
してもよく、論理回路を利用してハードウエア的に実現
することも可能である。

【０１５８】

【発明の効果】以上に説明したように、本発明によれ
ば、音質低下を、ネットワークのトラフィックに対応し
た最小限度内に抑制し、高品質で信頼性の高い音声通信
を実現することができる。

【図面の簡単な説明】

【図１】第１の実施形態に係る通信システムの全体構成
を示す概略図である。

【図２】平均ビットレートと音質の関係を示す概略図で
ある。

【図３】第１の実施形態の主要部の概略構成を示すブロ
ック図である。

【図４】第１の実施形態の動作説明図である。

【図５】第１の実施形態の動作説明図である。

【図６】第２の実施形態の主要部の概略構成を示すブロ
ック図である。

【図７】第２の実施形態の動作説明図である。

【図８】他の実施形態にかかる通信システムの全体構成
を示す概略図である。

【図９】他の実施形態にかかる通信システムの全体構成
を示す概略図である。

【図１０】他の実施形態にかかる通信システムの全体構
成を示す概略図である。

【符号の説明】

１０，４０…通信システム、１１…音声送信端末、１２
…ネットワーク、１３…音声受信端末、２０…音声入力
部、２１、４１…音声符号化部、２１Ａ、４３…有音判
定部、２１Ｂ、４１Ｂ…有音フレーム符号化部、２１
Ｃ、４１Ｃ…無音フレーム符号化部、２２…音声パケッ
ト送信部、２３…受信状態情報受信部、２４、４４…有
音判定レベル計算部、３０…音声パケット受信部、３１
…音声復号部、３２…音声出力部、３３…受信状態情報
作成部、３４…受信状態情報送信部、４２…音声分析
部、４５…音声判定Ｓｃａｌｅ蓄積部。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 音声パケット送信装置から送信された音
   声パケットを、所定のネットワークを介して受信する音
   声パケット受信装置において、 前記ネットワーク上のトラフィックに対応して変動する
   音声パケットの受信状況を検出する受信状況検出手段
   と、 当該受信状況検出手段が検出した受信状況に応じた受信
   状況情報を、前記音声パケット送信装置に送達するた
   め、前記ネットワークに送信する受信状況情報送信手段
   とを備えたことを特徴とする音声パケット受信装置。
2. 【請求項２】 所定のネットワークを介して音声パケッ
   ト受信装置に音声パケットを送信する音声パケット送信
   装置において、 送信しようとする音声フレームが有音であるか無音であ
   るかを、判定レベルに応じて判定する判定手段と、 当該判定手段が無音と判定した無音フレームは、有音と
   判定した有音フレームよりも少ない情報量となるように
   符号化する音声符号化手段と、 前記ネットワーク上のトラフィックに対応して変動する
   前記音声パケットの受信状況に応じて、前記音声パケッ
   ト受信装置が送信した受信状況情報を、前記ネットワー
   クを介して受信する受信状況情報受信手段と、 当該受信状況情報受信手段が受信した受信状況情報に応
   じて、前記判定レベルを変更する判定レベル変更手段と
   を備えることを特徴とする音声パケット送信装置。
3. 【請求項３】 請求項１の音声パケット受信装置と、 請求項２の音声パケット送信装置とを備えることを特徴
   とするパケット通信システム。