(57)【特許請求の範囲】
【請求項１】
電気通信システムに収容された少なくとも２つの通信装置間で情報データを送信する方法であって、情報データを通信装置の送信機から１つ以上の他の通信装置の受信機に対して、アナログ信号を所定のサンプリング周波数によりサンプリングして得られたデータ列から成るデジタル信号として送信し、当該デジタル信号を、受信機において、制御された方法で再生するに際して、
ａ）送信機において該送信機のサンプリング周波数を推定し、
ｂ）受信機に対して当該推定値を送信し、
ｃ）受信機において、受信データの再生における遅延を回避するために送信機で推定したサンプリング周波数を用いて受信データを再生する方法であって、
ステップａ）での、送信機のサンプリング周波数の推定を、２つのイベントの間の測定時間と２つのイベントの間にサンプリングされたサンプルの数に基づいて計算する情報データの送信方法。
【請求項２】
前記ステップｃ）において、受信機での、送信機で推定したサンプリング周波数を用いた受信データの再生制御は、受信機において、該受信機のサンプリング周波数を推定し、サンプリング周波数変換によって送受信機相互間における推定サンプリング周波数の相違を補償することを通じて行うことを特徴とする請求項１に記載の方法。
【請求項３】
前記時間の測定は、２つの時刻同期イベントの間に行われることを特徴とする請求項１または２のいずれかに記載の方法。
【請求項４】
前記時刻同期イベントにおいて、ホストクロックを外部クロックに同期させることを特徴とする請求項３に記載の方法。
【請求項５】
前記時間測定は、２つのパケットデータのフレーム配信の間に行われることを特徴とする請求項１または２のいずれかに記載の方法。
【請求項６】
２つのイベントの間の時間を測定するために中央演算装置（ＣＰＵ）のチッククロックを用いて、
２つの異なる時刻にＣＰＵクロックの値を読み、
２つの時刻の間のチックの数を推定し、
単位時間あたりのチックの数を用いてイベント間の実際の時間を計算することを特徴とする請求項１ないし５のいずれかに記載の方法。
【請求項７】
１秒あたりのチックの数を、長時間安定した時刻とＣＰＵクロックとを用いて推定することを特徴とする請求項６に記載の方法。
【請求項８】
前記長時間安定した参照時間は、同期したホストクロックであることを特徴とする請求項７に記載の方法。
【請求項９】
前記１秒あたりのチックの数を、特定のイベントに対する２つのＣＰＵクロックの値の相違と、同じイベントに対する２つの参照時刻の値の相違とに基づいて計算することを特徴とする請求項８に記載の方法。
【請求項１０】
前記１秒あたりのチックの数は、直前の数個の推定に関する移動平均によって計算することを特徴とする請求項９に記載の方法。
【請求項１１】
推定の前に、サウンドボードバッファの状態を連続的または特定のイベントに対応して読み出すことを特徴とする請求項１ないし１０のいずれかに記載の方法。
【請求項１２】
前記ステップａ）の推定は、２つの時間同期イベントの時間差と、同じイベントにおける２つの参照時間の差に基づいて行うことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ステップａ）の推定は、直前の数回の推定の移動平均によって行うことを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項１４】
前記推定課程を連続的に実施することを特徴とする請求項１ないし１３のいずれかに記載の方法。
【請求項１５】
少なくとも２つの通信装置間の相互通信において、第１の通信装置の送信機において該送信機のサンプリング周波数を推定し、第２の通信装置の受信機に前記推定値を送信し、第１の通信装置の送信機で推定したサンプリング周波数を用いて、第２の通信装置の受信機で、受信データの再生を制御し、第１の通信装置の送信機で得られたサンプリング周波数の推定値を第２の通信装置が第１の通信装置に対して両者間の通信におけるメッセージ送信に使用することを特徴とする請求項１ないし１４のいずれかに記載の方法。
【請求項１６】
前記推定は、標準制御パケットの通常のレポートに含められるか、あるいは当該パケットそのものの中の別のレポートとして送信されるか、あるいはその両方であることを特徴とする請求項１ないし１５のいずれかに記載の方法。
【請求項１７】
前記情報データはパケットデータフレームの形態で送信されることを特徴とする請求項１ないし１６のいずれかに記載の方法。
【請求項１８】
前記パケットデータフレームはオーディオフレームであることを特徴とする請求項１７に記載の方法。
【請求項１９】
情報データを通信装置の送信機から１つ以上の他の通信装置の受信機に、アナログ信号を所定のサンプリング周波数によりサンプリングして得られたデータ列から成るデジタル信号として送信し、受信機において制御の下で当該デジタル信号を再生する、少なくとも２つの通信装置を収容した電気通信システムにおいて、
ａ）システムに収容された通信装置の送信機において該送信機のサンプリング周波数を推定する手段と、
ｂ）システムに収容された他の通信装置の受信機に当該推定値を送信する手段と、
ｃ）受信データの再生における遅延を回避するために、送信機で推定されたサンプリング周波数を用いて、受信機で行う受信データの再生を制御する手段とを具備し、送信機でサンプリング周波数を推定する手段は、１秒あたりのチックの数を計算する計算ユニット（ＣＣＵ）と、サンプリング周波数推定ユニット（ＳＥＵ）を具備することを特徴とするシステム。
【請求項２０】
計算ユニット（ＣＣＵ）とサンプリング周波数推定ユニット（ＳＥＵ）とを具備する送信機のサンプリング周波数推定手段は、送信プロトコルとサンプリング周波数推定ユニット（ＳＥＵ）との間のインターフェースであるサンプリング周波数配信ユニット（ＳＤＵ）を含むことを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、通信システムに収容された少なくとも２つの通信装置相互間で情報を送信するための方法に関する。本発明の方法は、パケットを基本としたネットワークでのメッセージの転送に特に適する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
近年、パケットを基本としたネットワークによる音声の転送についての関心が高まっている。それは、ＩＰ−テレフォニーとして知られるものである。今日の、パケットを基本としたネットワークの殆んどは、インターネットプロトコル（ＩＰ）、及びそのサブプロトコル、つまり、伝送制御プロトコル（ＴＣＰ）及びユーザ・データグラム・プロトコル（ＵＤＰ）に準拠したものである。ＴＣＰによって、信頼性の高いデータ転送が担保され、また、何らかのフロー制御が可能となる。ＴＣＰプロトコルを使用した典型的なアプリケーションがファイル転送プトコル（ＦＴＰ）である。ファイル転送の間、データが受信ホストに到達することは非常に重要なので、確実に、パケットが到着し、適切な順序に並べ直されなくてはならない。ＵＤＰは、接続に関する保証を提供するわけではないが、接続が保証された接続が過剰な制御シグナリングを必要とする場合に使用される。
【０００３】
ＩＰ−テレフォニー等のリアルタイムアプリケーションには、ＵＤＰが使用される。このアプリケーションにとっては、失われたパケットが再転送されたとしても、いずれにせよ、受信機での合成には間に合わないので、再転送は無意味である。ＩＰテレフォニーには、リアルタイムプロトコル（ＲＴＰ）がＩＰ／ＵＤＰプロトコルとともに使用される。ＲＴＰヘッダーには、配列番号、パケット時間等の情報が含まれている。ＲＴＰは、例えば、オーデイオストリームとビデオストリームを合成するために使用される。リアルタイムストリームの転送に係る別の基本的な部分がリアルタイム制御プロトコル（ＲＴＣＰ）である。これは、ＲＴＰの制御に使用される。セッション参加者についての情報を伝送し、定期的にクオリティー情報を含む制御パケットを全てのセッション参加者に配信する。
【０００４】
ＩＰ−テレフォニーで発生する問題の１つがプレイアウトバッファでのアンダーラン又はオーバーランである。プレイアウトバッファは、音声サンプルがＤ／Ａ変換器によって再生されるまで蓄積される場所である。アンダーランが発生した場合、再生バッファは空の状態、つまり、出力での再生するべきサンプルが一切存在しなくなることになる。再生バッファがサンプルで満たされた場合は、オーバーランが発生する。その結果、サンプルが失われてしまう。
【０００５】
上述の問題の理由は、受信機と送信機間でのサンプリング率（つまり、サンプリング周波数）の同期が欠如しているためである。通信システムでの通信装置間の通信では、メッセージは、通信装置の送信機からデジタル信号の状態で他の通信装置の受信機へ送信される。送信機から転送された信号は、第１のサンプリング周波数を有する。受信機は、これらの信号を第２のサンプリング周波数で再生バッファにバッファするが、それらの再生を第２のサンプリング周波数で行う。当該信号を再生バッファにバッファするための第１の周波数が再生周波数である第２の周波数より高い場合、再生バッファがサンプルで満たされ、後続サンプルのための場所がなくなり、つまり、オーバーランの状態となる。第１の周波数が第２の周波数より低い場合は、再生バッファは、サンプルを有さない状態、つまり、アンダーランの状態に陥る可能性がある。
【０００６】
セルラシステムでは、ネットワークに接続された全ての端末のサンプリング周波数は、当該システムが提供する正確なタイミング参照によって制御される。サンプリング周波数を制御する当該正確なタイミング参照及びＰＬＬ（フェーズがロックされたループ）によれば、アンダーラン又はオーバーラン状態の発生は防止される。例えば、ＰＬＬ技術によって、サンプリング率を制御することができる。バッファが大きくなれば、その再生が早くなり、ここで、バッファ終了後、その初期値に戻る。サンプル率は、常に、バッファのサイズに応じて訂正される。
【０００７】
送信側と受信側の間のサンプリング率の差を補償するために、タイムストレッチングを使用して、受信側において刺激が有する継続時間を、同様の刺激が送信側において有していた継続時間と同じにする可能性がある。どの程度の信号をストレッチするかは、受信機と送信機のサンプリング周波数の次第である。タイムストレッチングとは、Ｎ個のサンプルの刺激がＭ個のサンプルの刺激に置換されることを意味する。このタイムストレッチングが適切になされれば、オーバーターン又はアンダーターンは防止される。
【０００８】
上記タイムストレッチングの実施方法は様々である。欧州特許出願番号０６８００３３には、音声信号を時間的にストレッチする解決方法が記載されている。第１の期間を有する音声刺激を取得し、当該音声刺激を第１の期間に変換する。当該第１の期間と第２の期間との間の変換係数を求める方法は与えられていない。
【０００９】
時間で信号をストレッチする別の方法がマーク・カールス及びカールハインツ・ブランデンベルグ著「デジタル信号処理のオーディオ及びアコースチックへの応用(Applications of Digital Signal Processing to Audio and Acoustics)」（ｐ２９１），「クルワーアカデミックパブリッシャーズ(Kluwer Academic Publishers)」出版、1998年、ロンドン、に記載されている。当該方法は、信号に依存していないが、Ｎ個のサンプルからなる恣意的信号を採用し、それをＭ個のサンプルからなる他の信号に変換する。タイムストレッチングを実施するためのこの方法も、変換係数を与えていない。
【００１０】
現在、ＩＰ−テレフォニー機器製造者は、送信機と受信機の間のサンプリング周波数の相違が様々であるかもしれない事実を考慮していない。よって、利用可能な解決方法が全くない。
【００１１】
ＩＰ−テレフォニーに係る他の関心分野が２つの端末間のエンド−ツー−エンド遅延を正確に測定することである。エンド−ツー−エンドの測定の正確な結果を得るために、クロックスキュー、つまり受信機と送信機のクロック周波数の相違を補償する必要がある。ムーン・Ｓ．，スケリー  Ｐ．，タウスリー  Ｄ，著(Moon S., Skelly P., Towsley D.)「ネットワーク遅延測定からのクロックスキューの測定と除去(Estimation and Removal of Clock Skew from Network Delay Measurements)」技術レポート９８−４３，コンピューターサイエンス学部、マサチューセッツ大学アムヘルスト校，１９９８年１０月，の論文には、送信コンピュータと受信コンピュータ間のクロック周波数の相違の測定のための様々な方法が記載されている。受信機で測定が実施され、全ての方法は、ＲＴＰ及びパケット到着時間の測定からのタイムスタンプを使用する。
【００１２】
クロック周波数における相違を抽出する他の方法は、上記に記載の方法に近いものであるが、日本電信電話株式会社によって日本特許出願１０−１４５３４５で保護されている。データ（又は音声）を伝送時間についての情報と共に送信機に送信し、受信機の受信時間を測定することによって、２つの端末間の度数比を計算することができる。
【００１３】
上記に記載の方法によって提案されている方法によると、クロックスキューを満足の行く程度に測定することができるが、その速さが充分でない。ＪＰ−１０１４５３４５に記載の方法では、度数比の測定を呼の間に行うことが想定されている。しかし、測定処理が遅く、この間に、結果として、可聴な影響を伴うオーバーラン／アンダーランの状態が既に発生しているおそれがある。
【００１４】
本発明の目的は、従って、より高速なクロックスキューの測定を可能にすることによって送信機から受信機への転送の遅延及び／又は中断を回避することである。
【００１５】
【課題を解決するための手段】
本発明の方法では、情報データは、通信システムにおける少なくとも２つの通信装置の間で送信される。情報データは、任意のサンプリング周波数を有するデジタル信号の状態で通信装置の送信機から、１又は複数の他の通信装置の受信機へ送信される。信号は、制御された方法で受信機によって再生される。当該方法は、主として、通信装置の送信機で送信機のサンプリング率を推定し、当該推定を他の通信装置の受信機に転送し、送信機で推定されたサンプリング率によって受信機での情報データ再生を制御し、以って、再生の遅延及び／又は中断を回避することを特徴とする。
【００１６】
本発明は、特に、情報データが通信システムにおいてオーディオフレーム等のパケットデータフレームの状態で通信装置間を送信されるパケットを基本とするネットワークに関して適している。通常、通信装置は、送信機と受信機の双方を有するが、本発明には、当然ながら、情報データが、送信機としてのみ機能する通信装置から送信され、情報データは、レシーバーとしてのみ機能する通信装置に受信されるような場合も含まれる。通信は、通常、双方向的な通信であるが、本発明は、例えば、一方向通信や、複数の通信装置を伴う通信においても利用することができる。
【００１７】
２方向の通信が関心事項である場合、推定の転送や通信でそれらがどのように使用されるのかに関しては、様々な実施態様がある。
【００１８】
ある実施態様では、少なくとも２つの通信装置の間で２方向通信が実施されている場合、上記方法は、
送信機のサンプリング周波数の推定が第１の通信装置の送信機で実施され、
当該推定は、第２の通信装置の受信機に転送され、
受信されたデータは、当該第１の通信装置の当該送信機で推定されたサンプリング率によって当該第２の通信装置に受信機で制御され、
当該第２の通信装置の送信機のサンプリング周波数の推定は、当該第２の通信装置の当該送信機で実施され、
当該第２の通信装置の当該送信機のサンプリング周波数の推定は、当該第１の通信装置の受信機に転送され、
受信されたデータの再生は、当該第２の通信装置の当該送信機で推定されたサンプリング率によって当該第１の通信装置の当該受信機で制御されるように実施される。
【００１９】
他の実施態様では、少なくとも２つの通信装置の間での通信は、
送信機のサンプリング周波数の推定が第１の通信装置の送信機で実施され、
当該推定は、第２の通信装置の受信機に転送され、
受信されたデータの再生は、当該第１の通信装置の当該送信機で推定されたサンプリング率によって当該第２の通信装置の当該受信機で制御されるように実施され、
当該第１の通信装置の当該送信機で推定されたサンプリング率の推定は、当該第２の通信装置からのメッセージを当該通信装置間の通信で当該第１の通信装置へ転送する際に使用されるように実施することができる。
【００２０】
本発明の好適な実施態様では、上記送信機で推定されたサンプリング率による、上記受信する側での受信データの再生制御は、上記受信機で受信機のサンプリング周波数を推定し、受信機と送信機における当該推定されたサンプリング周波数の相違をサンプル率変換方法によって補償することによって実施される。当該変換方法は、当該分野で周知の方法であってもよく、例えば、パケットフレームのサンプル数が変更される方法がある。この方法は、例えば、第２頁において先に参照した方法、つまり、マーク・カールス及びカールハインツ・ブランデンベルグ著「デジタル信号処理のオーディオ及びアコースチックへの応用」（ｐ２９１）に記載されている方法であってもよい。
【００２１】
本発明の他の実施態様では、上記送信機で推定されたサンプリング率による、上記の受信機での受信データの再生制御は、上記受信機で受信機のサンプリング率を送信機のサンプリング率に同期化することによって実施される。この方法では、通常、安定した参照周波数が必要となる。同期化は、当該分野でいくらか周知の方法によって実施されることができ、例えば、先に記載の、セルラシステムに使用されるＰＰＬ方法が挙げられる。
【００２２】
推定の上記転送は、呼の確立の間に実施することができ、又は、より好適な代替手段あるいは、代替手段としては、セッションの間に実施することができる。当該推定は、定期報告に取り込まれ、その場合、推定は、ＲＴＣＰプロトコルによって送信される報告に取り込まれるか、及び／又は、独自のパケットで別個の報告として転送されてもよい。
【００２３】
上記の方法は、再生バッファでのオーバーラン及び／又はアンダーランの補償を改善するためのサンプリング周波数推定に使用することを意図している。
【００２４】
本発明では、各端末は、それ自身のサンプリング周波数、〜Ｆｓを継続的に推定することができる。呼が開始された場合、又は、それが必要な場合はいつでも、この推定は、他の端末／複数の端末に転送される。そうすると、適切なサンプリング周波数が受信機では、呼の確立の段階で既に利用可能となり、再生バッファを制御するために直ちに使用することができる。つまり、推定が利用可能となるまでの初期遅延がない。
【００２５】
サンプリング率の推定は、２つのイベントの間で推定された時間と、それらの間でサンプルされたサンプル数に基づいた計算の形態で実施される。これらのイベントは、有利には、２つの時間同期イベントを有する。時間同時イベントとは、通信装置のホストクロックが例えば外部クロックに同期化した場合のイベントのようなものをいう。時間も、オーディオフレーム等のパケットデータの２つのフレームデリバー間が推定されてもよい。
【００２６】
時を刻む中央演算装置（ＣＰＵ）クロックは、２つのイベント間のチック数を計算することによって、これらのイベントの時間価値を推定するために使用することができる。１秒あたりのチックの名目上の数は、コンピュータプロセッサに設けられた周波数である名目上のクリスタル周波数に応じて、システムコンスタントを通じて与えられる。
【００２７】
１秒あたりの真のチック数は、長期間安定した時刻参照とコンピュータクロックによって推定される。長期間安定した時刻参照は、ホストクロックに同期化することができる。１秒あたりの真のチック数は、２つのコンピュータクロック値の間の時間差と、２つの参照時間値の時間差の関数として推定することができる。ある実施態様では、１秒あたりのチック数は、先の幾つかの推定の移動平均として計算することができる。
【００２８】
インプットバッファ（及び、任意であるが、アウトプットバッファ）の状態が推定前に調査された場合、継続的に、又は、特定のイベントに関連して、好適には、周波数推定は、２つの同期イベントの間の時間差と、同様のイベントの２つの参照時間値の間の時間差によって直接的に実施される。当該推定は、先の幾つかの推定の移動平均によっても実施することができる。
【００２９】
好適には、本発明の推定処理は、継続的に実施される。最高の可能性ある推定が常に利用可能となるからである。
【００３０】
通信システムにおいて少なくとも２つの通信装置を有する本発明の構成は、主として、通信装置の送信機で送信機のサンプリング周波数を推定する手段と、推定をもうひとつの通信装置の受信機に転送する手段と、当該送信機で推定されたサンプリング率によって、受信機での受信されたデータの再生を制御し、以って、プレゼンテーション（受信機での再生）中の遅延及び／又は中断を回避する手段を有することを特徴とする。
【００３１】
好適な実施態様では、受信されたデータの上記受信機での再生を制御する手段は、受信機のサンプリング周波数を推定する手段と、送信機と受信機での当該推定されたサンプリング周波数の相違をサンプル率変換方法によって補償する手段を備える。
【００３２】
送信機でのサンプリング率の推定手段は、好適には、１秒あたりのＣＰＵチック数を計算するための計算装置（ＣＣＵ）と、サンプリング周波数推定装置（ＳＥＵ）を有する。
【００３３】
上記推定を受信機へ転送する手段は、サンプリング周波数配信ユニット（ＳＤＵ）を有し、これは、転送プロトコルと上記推定装置（ＣＣＵ、ＳＥＵ）の間のインターフェースである。
【００３４】
本発明は、継続的に端末のサンプリング周波数を推定し、この情報を受信端末へ転送するために利用することが可能で、その結果、より改善されたバッファ管理アルゴリズムを展開することができる。従って、より高いオーディオ品質を得ることができる。更に、ホストでの１秒あたりの真のＣＰＵチック数の推定を他のアプリケーションに分配することもできる。そうすることによって、これらのアプリケーションは、当該推定された１秒あたりのＣＰＵチック数を通じて提供されたより正確なタイミング情報を入手することができる。
【００３５】
本発明は、特に、典型的には、オーディオやビデオ等の周期性を有するリアル−タイムのアプリケーションに有用である。これらのアプリケーションは、任意のインターバルを有する音声フレーム又は映像を取る。それらが双方向的アプリケーションであることから、送信での遅延は、低い程度に維持されなければならない。
【００３６】
以下の説明では、本発明は、範囲が特許請求の範囲によって画定されている本発明を制限する意図はない幾つかの好適な実施態様及び図面によって詳細に説明されている。本発明は、例えば、パケットモード転送に一般的に利用可能であって、実施態様において、オーディオフレームが参照されているとしてもそれは、適当な応用の一例である。更に、「を含む」とは、他の可能性ある部品や特性を除外しないように理解されなくてはならない。
【００３７】
詳細な説明
本発明を詳細に説明するに際して、以下に記載する用語を用いる。コンピュータに収容された端末では、異なる複数のクロックを使用することができる。
【００３８】
サンプルクロックｔｓは、音声が送信されたときにサウンドボードで作成されるクロックであり、このクロックはコンピュータ自身のクロックとは分離したものである。サウンドボードは、所定の時間刻みでサンプルを取得する信号受信装置である。サンプルクロックは離散的に増加していく時間に従って動作し、各ステップはサンプル時間間隔Ｔｓに対応する。サンプル時間間隔は、サンプリング周波数Ｆｓの逆数である。
【００３９】
中央演算装置（ＣＰＵ）のクロックｔｃはコンピュータ自身のクロックである。当該クロックは、離散値の増大に従って動作する。１つのステップは一般に「チック」と称し、本明細書ではＣＰＵクロックは「チック」クロックと称する。アプリケーションは、２つのイベントの間の時間を推定するためにＣＰＵクロックを使用することができる。２つのイベントにおける値ｔｃを読み取って、２つのイベントの間のチックの数を数えることができる。１秒あたりのチックの数がわかっていれば、２つのイベントの間の実際の時間を計算することができる。コンピュータでは、この値は、プロセッサのクォーツの平均振動数から計算されたシステム定数〜Ｔｃによって与えられる。しかし、実際の数はプロセッサの製造条件等に依存するので、１秒あたりの実際のチックの回数Ｔｃを得ることはできない。
【００４０】
ホストクロックｔｈは年、月、日、時間、分、秒およびマイクロ秒の単位で時刻を提供する。これは通常ＣＰＵクロックによって制御されているが、外部クロックと同期させることもできる。同期は、ネットワークタイムプロトコル（ＮＴＰ）に従って行われる。ＮＴＰは、コンピュータネットワークにおいて、ネットワーク内のコンピュータをユニバーサル時間座標の時刻（ＵＴＣ時刻）に同期させるために使用される。グリニッチ標準時間（ＧＭＴ）と同じＵＴＣ時刻、は原子クロックに基づいた時間の基準なので、安定度と正確性は高い。同期に使用することができる外部クロックの他の例としては、グローバル位置決定システム（ＧＰＳ）を挙げることができる。ＧＰＳ受信装置は、ワークステーション内に設置して、ＧＰＳによって提供される安定した時間ｔｈと同期させることができる。
【００４１】
ホストクロックが調整されていなければ、時間の経過とともに真の時間との偏差は大きくなる。ホストクロックが調整されていると、どの時間計測に関しても、調整されていないクロックよりも真の時間との偏差は小さくなる。しかし、測定に最適な時点は、ホストクロックを外部参照時刻に同期させた直後である。
【００４２】
「真」のクロックは、ＮＴＰまたはＧＰＳから提供された時刻である。
【００４３】
図１は本発明に基づく好ましい実施態様ａ、ｂとｃを示すものである。
【００４４】
１）図１では、本発明の第１の実施例を構成するステップを文字「ａ」で表す。
【００４５】
図１のステップ１に示したように、推定プロセスは、電気通信システムの通信装置の送信機で開始される。本発明の図示した３つの実施例を通じて、ステップ１は共通である。
【００４６】
サンプリング周波数は、たとえば、アプリケーションに対してサンプルをいくつ提供することができるかを検出するためにバッファの状態を読み出すことが可能であるか否かによって、複数の異なる方法で推定することができる。本発明の第１と第２の実施例では、バッファの状態を決定することはできないと仮定している。この第１と第２の実施例では、バッファがアプリケーションに対してパケットフレームを配信するイベントを、サンプリング周波数の推定に使用する。アプリケーションに対して例えば音声フレームを配信する場合、ブロックサイズは、例えば、スピーチコーディングユニットに入力すべきサンプル数に固定されている。
【００４７】
本発明に基づいて、送信機で行うことができる、たとえばサウンドボードのサンプリング周波数のようなサンプル周波数を推定するための正確かつ高速な方法は、同期されていない一連のイベントを３つ使用する方法である。第１のイベントは、時間とともに常に増加しているＣＰＵのチックカウンタである。第２のイベントは、図１においてステップ２で示した、外部参照時刻によるホストクロックの更新である。シリーズの第３のイベントは、たとえば、アプリケーションに対してサウンドボードがオーディオフレームを配信するときのデータパケットの受信である。
【００４８】
受信機でサンプル周波数の最善の推定を得るには、本発明の第１の実施例では以下に記載する方法を実施する。
【００４９】
データを受信したとき、最後のデータパケットが配信されて以降のＣＰＵチックの数を推定する。１秒あたりのＣＰＵチック〜Ｔｃの最善の推定値は、図１においてステップ２で示すように、ホストクロックが外部の参照時刻に対して同期させられたときである。１秒あたりのＣＰＵチックの数〜Ｔｃの推定もまた、端末のバックグラウンドジョブとして非常に長い時間にわたって実行することができる、つまり、１秒あたりのＣＰＵチックの数のカウントは、端末が起動されたときからずっと継続することができる（図示しない）。
【００５０】
このようにして、〜Ｔｃは以下の関数によって推定される、
ｔｈ０、つまり、推定プロセスを開始したときのホストクロックｔｈの時刻（図１におけるステップ１）、たとえば、コンピュータのスイッチを入れたときの時刻、
ｔｈｎ、つまり、図１のステップ２で示すように、ホストクロックｔｈを外部クロックに同期させたときのホストクロックの時刻（本発明の図に示した２つの実施例では、ステップ２は共通である）、例えば、時点ｎにおけるｎ番目のＮＴＰまたはＧＰＳの値、
ｔｃ０、つまり、図１でステップ１として示されている、推定プロセスを開始したときのＣＰＵクロックの時刻、
ｔｃｎ、つまり、図１においてステップ２で示されている、外部クロック対してホストクロックを同期させたときのＣＰＵの時刻である。
【００５１】
図１のステップ３に示すように、〜Ｔｃを計算するためには何種類かのアルゴリズムを使用することができる。アルゴリズムは一般的に以下のように示される。
【数１】
0004553537.tif 000002
ｔｃｍ＝時刻ｍにけるＣＰＵクロックの時刻
ｔｃｎ＝時刻ｎにおけるＣＰＵクロックの時刻
ｔｔｍ＝時刻ｍにおける真のクロックの時刻
ｔｔｎ＝時刻ｎにおける真のクロックの時刻
ｔｈはｔｔに同期しているので、上述の式においては、ｔｈに代えてｔｔを使用することができる。
【００５２】
次に、図１のステップ４ａに示すように、１秒あたりのＣＰＵチックＴｃを推定する。この関係は以下の関数で示される。
【数２】
0004553537.tif 000003
ここで、ｔｃｍ、ｔｃｎ、ｔｔｍ、ｔｔｎ、ｔｃ０とｔｔ０の定義は上述の通りである。下付き文字は時刻を表し、上付文字はクロックを表す。
【００５３】
他の関数を考えることも可能である。例えば、〜Ｔｃは、以下に示す関係を用いて最後のいくつかの推定値の移動平均とすることもできる。
【数３】
0004553537.tif 000004
ここで、ｋ（ｎ）はｎ番目の推定に対する重み係数である（推定をいつ行ったかによって測定に重み付けをするのが好ましい。通常は、後の測定の方が重み係数が大きくなる。重み係数の合計は１である）。
【００５４】
【数４】
0004553537.tif 000005
ここで、時刻ｎ−１は、時刻ｎにおけるイベントに先行するイベントの時刻であり、従って、
ｔｃｎ−ｔｃｎー１は、これらの時刻の間のコンピュータのクロックの差、
ｔｔｎ−ｔｔｎ−１は、上述の同じ時刻に関する同期したホストクロック（真の時刻）の差である。
【００５５】
外部参照時間によってホストクロックを調節したときにＴｃを更新した場合にのみ、推定に正確な時刻を使用することができる。任意の時刻を使用するとすれば、Ｔｃの推定精度は同じではない。推定プロセスは、コンピュータが起動されてから連続的に実行されるのが好ましい。呼の操作が起動されるまでには、正確なＴｃの推定が得られる。
【００５６】
ステップ５ａでは、パケットデータ中のサンプルの数を調べる。オーディオフレームの場合であれば、パケットは固定長なのでサンプル数は既知である。パケットサイズが変わるときは、各パケットがサンプルをいくつ収容しているかを示すデータを読んでこの値を考慮することでサンプル数を得ることができるが、変数が１つ増加する。推定値Ｔｃと１フレーム内のサンプル数が得られれば、下記の式を用いてステップ６ａに記載したようにサンプリング周波数を得ることができる。
【数５】
0004553537.tif 000006
ここで、ｍ≠で、Ｎはフレームサイズである。
ｍとｎは、離散時刻である。
ここでτｃｎは、ｎ番目のパケット配信の時点のＣＰＵクロック、τｃｍはｍ番目のパケット配信の時点のＣＰＵクロックである。
【００５７】
推定されたサンプリング周波数は、ステップ７で、例えばＲＴＣＰプロトコルを用いて別の通信装置の受信機に対して送信され、ここで、受信機に対して送信されるパケットはアプリケーションによって規定されたＲＴＣＰ（ＡＰＰ）パケット形式である。このパケット形式では、推定されたサンプリング周波数を含むことができるアプリケーションに依存するフィールドがあるが、レポートは、Ｈ．シュルツリン(Schulzrinne, H.)他の「ＲＴＰ：実時間アプリケーションのための送信プロトコル(ＲＴＰ: A transport Ｐrotocol for Real-Time Application)」ＲＦＣ１８８９、ＩＥＴＦ、１９９６年１月に記載の、プロファイルに固有の方式で延長する必要がある。
【００５８】
ステップ８では、同様の方法で受信機でも固有のサンプリング周波数を推定し、サンプルレート変換方法に基づいて、送信機と受信機で推定したサンプリング周波数の相違を補償する。この変換方法は、従来技術として知られているような、パケットフレーム内のサンプルの数を変更する方法であってもよい。このような方法は、例えば、２ページですでに参照した、マーク・カーとカールハインツ・ブランデンブルグ(Mark Kahrs and Karlheinz Brandenburg)による、「音声へのデジタル信号処理の適用(Applications of Digital Signal Processing to Audio and Acoustics)」（２９１ページ）に記載された方法であってもよい。
【００５９】
２）図１において、第２の実施例に属するステップを文字「ｃ」によって示す。
【００６０】
第２の実施例では、時間同期イベントを使用せずに推定を行う。本発明の第２の実施例でも、バッファ状態を読み出すことができないＯＳとサウンドボードの構成となっている前提なので、２つの異なるフレームイベントの時間差からサンプリング周波数の推定を行う。しかし、ホストの同期イベントの間の時間が、測定時間よりも大きければ、推定値はホストクロックが同期していない場合と同じ程度大きなものになる。
【００６１】
ステップ２ｃには、データ配信、つまりアプリケーションへのオーディオフレームの配信が示されている。２つのフレームイベントの間の時間がステップ３ｃで測定され、その後、サンプリング周波数Ｆｓが、例えば、以下に示す式に基づいてステップ４ｃに示すように推定される。
【数６】
0004553537.tif 000007
ここで、ｔｈｎ−ｔｈｍは、時刻ｎとｍとにおける２つのデータフレームの到着時刻（ホストクロックでの時刻）であり、
Ｎは、フレーム内のサンプル数、
ｎは、時刻ｎにおけるフレーム番号、
ｍは、時刻ｍにおけるフレーム番号である。
次に、第１の実施例に関してすでに説明したステップ７と８とを実施する。
【００６２】
３）本発明の第３の実施例は、オーディオバッファ状態の読み出しが可能であることが条件である。この実施例は、図１では文字「ｂ」で示した。
【００６３】
ステップ２で示した、時刻の同期イベントが行われると、ホストクロックｔｈに関しては最も正確な時刻を得ることができるようになる。ｔｈはｔｔに対して同期しているので、数式においてｔｈの代わりにｔｔを使用することができる。これらのイベントにおいては、ステップ４ｂでバッファの状態を読み出し、同期イベントの間の時間と、２つの同期イベントの間にサンプリングされたサンプルの数からサンプリング周波数を計算することができる。図５ｂに示したように、〜Ｆｓを計算するには種々のアルゴリズムを用いることができるが、好適なアルゴリズムはたとえば下記のようなものである。
【数７】
0004553537.tif 000008
ここで、ステップ６ｂで〜Ｆｓを推定するために使用する関数は、下記の通りである。
【数８】
0004553537.tif 000009
ここで、
ｔｓｎは、時刻ｎにおけるサンプルクロックが示す時刻
ｔｓ０は、例えば、推定を開始した時である０点におけるサンプルクロックが示す時刻
ｔｔｎは、時刻ｎにおける同期された時点のホストクロックの時刻（「真」の時刻）
ｔｔ０は、時刻０における同期された時点のホストクロックの時刻（「真」の時刻）
【００６４】
他の関数を使用することもできる。例えば、Ｆｓは以下の式を使用して移動平均をとることもできる。
【数９】
0004553537.tif 000010
ここで、
【数１０】
0004553537.tif 000011
であり、時刻の値は上述の通りであり、上付文字ｓはサンプルクロックを意味し、下付き文字ｔは真のクロックを意味し、下付き文字はすでに述べたように異なる時間を表し、ｋ（ｎ）はｎ番目の推定に対する重み係数である。
【００６５】
最善の推定を得るためには、計算をホストクロックの同期と同時におけなわなければならない。
次に、上述の第１の実施例に示したステップ８と９とを実施する。
【００６６】
４）本発明の第４の実施例（図示しない）は、ホストクロックを外部のクロックに同期させなくてもサンプリング周波数〜Ｆｓの推定を行うことができるもう１つの可能性を示すものである。
【００６７】
推定された〜Ｔｃとともに、真のクロックとホストクロックとの間のゆがみを計算することができる。これら２つのクロックの周波数の差を計算することで、この情報を、最後のホストクロックの修正以降に経過した時間に基づいてホストの読み出し時間の修正に使用することができる。修正されたホストクロックの時間に基づいて真のクロックとホストクロックの周波数の差を計算したら、サンプリング周波数を計算することができる。クロックのゆがみに関する情報に基づいて、フレームｎとｍとの間でホストクロックによって測定された時間を修正して真の時間を求めることができる。〜Ｔｃの指定と同様に、最善の推定を行うためには、このプロセスを継続的に行う必要がある。
【００６８】
サンプリング周波数を計算するためのアルゴリズムを以下に例示する。
【数１１】
0004553537.tif 000012
ここで、
Ｎはサンプルの数、
ｋは時間差が上述のように定義された状況における、真の時刻とホストクロックの時刻との修正係数である。
【００６９】
図２は、特許請求の範囲に記載した方法を実施するための装置を示すものである。
当該装置は、ＣＰＵチック計算ユニット（ＣＣＵ）を具備する。図２では、当該計算ユニットを符号１で示した。計算ユニット１は、外部のクロックから供給される安定した参照時刻、例えば、〜Ｔｃ、ＮＴＰまたはＧＰＳを用いて１秒当たりのＣＰＵチックの数を推定する。
【００７０】
計算ユニット（ＣＣＵ）への入力は、長期間安定な参照時刻ｔｃである、上述のようなＣＰＵクロックの値である。参照時刻は、例えば、上述のように、同期したホストクロックｔｈであってもよい。ｔｈをｔｔに同期させるためにＮＴＰやＧＰＳを使用すれば、ホストクロックが提供する時刻は長期間にわたって高い精度を有する。ＣＣＵからの出力が〜Ｔｃである。
【００７１】
推定されたＴｃはサンプリング周波数推定ユニット（ＳＥＵ）に送られ、そこで、サウンドボードのサンプリング周波数（＝サンプリング率）〜Ｆｓが推定される。ＳＥＵは、図１との関連においてすでに述べたように、サンプリング周波数の推定に〜Ｔｃ以外の値を使用してもよい。サンプリング周波数推定ユニットは、図２では符号２で示した。
【００７２】
サンプリング周波数の推定値は、図２では符号３で示すサンプリング周波数配信ユニット（ＳＤＵ）に送られる。サンプリング周波数配信ユニット３は、送信プロトコル４と推定ユニット２との間のインターフェースである。ユニットは、ＴＣＰ／ＩＰのような適切なプロトコルに、端末に固有のサンプリング周波数を供給し、受信装置５に対して配信するために、（図示しない）別の端末からサンプリング周波数を受信する。
【図面の簡単な説明】
【図１】  本発明に基づく好ましい実施例を示すフロー図である。
【図２】  本発明に基づくシステムを示す概念図である。
【図１】
0004553537.tif 000013
【図２】
0004553537.tif 000014