1. 株式会社PALTEK
  2. TECHブログ
  3. 技術情報
  4. クロックドリフトがVoIPの音声品質に与える影響と対策

TECHブログ

クロックドリフトがVoIPの音声品質に与える影響と対策

クロックドリフトがVoIPの音声品質に与える影響と対策

VoIP(Voice over IP)は、インターネットプロトコルを使用して音声通信を行う技術として広く普及しています。この技術により、従来の電話網に比べて低コストで柔軟な音声通信が実現可能となりました。しかし、IPネットワークを介した音声通信には、いくつかの技術的な課題が存在します。

その中でも本ブログでは、クロックドリフトと呼ばれる現象に着目します。これは、通信の送信側と受信側の端末で使用されるPCM(Pulse Code Modulation)クロックの精度差によって生じる現象です。一見些細に思えるこの差異が、実際の通話品質にどのような影響を及ぼすのか、また、その対策にはどのような方法があるのかについて解説していきます。

VoIPシステムの設計や運用に携わる技術者にとって、クロックドリフトの理解は音声品質を維持する上で重要な要素となります。本ブログを通じて、この課題への理解を深めていただければ幸いです。

目次

クロックドリフトとは

携帯電話やGPSによる時刻補正機能付き時計と、一般的な壁掛け型時計や腕時計の時刻が異なり、時間が経つにつれてその差が広がっていく経験をされたことはないでしょうか。

この現象は、「クロックドリフト」と呼ばれ、各装置が持つクロックの精度の違いによって発生します。

クロックの精度は「ppm(Parts Per Million)」という単位で表されます。理想的なクロックは0ppmですが、現実の機器ではさまざまな要因により完璧な精度を実現することは困難です。例えば、100ppmのクロックは理想値(0ppm)と比較して0.01%の誤差を持っており、これは1万回に1回の割合で位相がずれることを意味します。

図1. クロックドリフトの例

VoIPにおけるクロックドリフトで発生する問題

VoIP通信では、送信側と受信側の両端末にそれぞれPCMクロックが供給されています。送信側の端末からネットワークへのパケット送信タイミングは、その端末のPCMクロックソースに基づいて決定されます。受信側も同様です。各端末のPCMクロックソースは独立しているため、精度に差が生じ、その差は時間とともに蓄積されていきます。

以前掲載したブログ G.711音声コーデックについて では、以下のように述べています。

通常のパケットサイズ 20ms(160Byte)
サンプリング 8000Hz、8bit
周波数偏差の許容範囲 ±50ppm

この仕様のもとで、クロックドリフトがどのように影響するか具体例で見てみましょう。

最も極端なケースとして、送信側のクロックが+50ppm、受信側のクロックが-50ppmの場合を考えます。

  1. クロックの差は100ppmとなり、0.01%の誤差が生じます
  2. サンプリングは1秒間に8000回行われるため、1.25秒(1万回のサンプリング)で1クロック分(0.125ms)のドリフトが発生します
  3. 1パケット(20ms)は160クロック分に相当するため、1パケット分のずれが生じるには
    • 63パケット × 160 = 約10,080パケットの受信が必要
    • 時間に換算すると約3分20秒(10,080パケット × 20ms)

つまり約3分20秒の通話で送受信間のパケット数に相違が生じ、その結果として音声品質に影響が出ることになります。これがVoIPにおけるクロックドリフトの具体的な問題です。

図2. VoIPネットワークにおける端末間のPCMクロックの構成図

VoIPにおけるクロックドリフトの影響を回避するには

クロックドリフトを回避する方法として、常に時刻補正機能を持たせる、0ppmの精度に近いクロックソースを使用するなどが考えられます。しかし、このようなソリューションは高価なものとなり、商品コストが増加します。

VoIPにおけるクロックドリフトへの別のソリューションとして、受信側の端末で補正機能を設けることが考えられます。

RTPパケットのヘッダーにはTimestampが含まれており、RTPパケットのペイロードの先頭バイトの送信時刻が記録されています。このTimestampはG.711の20msパケット周期の場合、160毎の増加となっており、受信側でのこのTimestampだけでは送信側の時刻との同期調整はできません。

RTCPのSR(Sender Report)パケットヘッダーには、RTPの場合と同じ単位のTimestampが含まれており、更にNTP Timestampが含まれています。下図は、実際の音声通話時のパケットキャプチャで、IPアドレス 192.168.0.30 から 192.168.0.20 に送出されているRTP/RTCPを抽出したものです。

図3. VoIP通信におけるRTP/RTCPパケットのキャプチャ例

パケット#730のRTPのTimestampは21760で、パケット#728のRTCP(SR)ヘッダーに、RTP Timestamp 21760と記録されています。(端末の時刻を設定していないため、NTP TimestampはFeb 7 2036と未来の時刻になっています。)
NTP Timestampも含まれていることが確認できます。これらの情報を参照しながら、受信側と送信側の同期をとりながら送受信すれば、送受側のパケットと受信側のパケットが整合します。

さらに別のソリューションとして、クロックドリフトが起こった場合、その量に応じてパケットを追加または破棄して補正する方法があります。
受信側のPCMクロック8000Hzでのサイクルカウンターで期待する受信側パケット数を算出し、実際に受信したパケット数と比較し差が1以上あった場合、クロックドリフトによるパケットの相違とみなしパケットを追加または破棄します。

以前掲載したブログ 安定した通話を実現するVoIPの音声品質とジッタバッファ で遅延や揺らぎについて記載しましたが、パケットの遅延によって、期待するパケット数と実際に受信したパケット数に違いがあることも考えられます。ジッタバッファの状態を参照し、クロックドリフトによるパケットの相違と、遅延によるパケットの相違の区別をどのように判断するかがポイントとなります。

おわりに

本ブログでは、VoIP通信におけるクロックドリフトの問題について説明しました。送信側と受信側の端末間で発生するPCMクロックの精度差は、長時間の通話では無視できない影響を及ぼします。具体的な数値例で示したように、最大許容偏差(±50ppm)の条件下では、約3分20秒の通話でパケットの不整合が発生する可能性があります。

この問題に対する解決策として、高精度なハードウェアの採用、RTP/RTCPを活用した同期制御、そしてパケットの動的な制御という3つのアプローチについて紹介しました。特に、コスト面を考慮すると、ソフトウェアによる制御方式が現実的な選択肢となります。

今後のVoIP技術の発展においても、クロックドリフトへの対応は音声品質を維持する上で重要な課題の一つとして位置づけられています。

本ブログが、VoIPシステムの設計・開発に携わる方々の参考になれば幸いです。

VoIP関連のDSP、システム・オン・チップ(SoC)などに関する情報は以下よりご確認ください。

VoIP関連のDSP、SoCなどに関する
情報はこちらから

関連ブログ(VoIP)

関連ブログ(クロック)