JP3874112B2 - 揺らぎ吸収バッファの制御方法および制御装置 - Google Patents
揺らぎ吸収バッファの制御方法および制御装置 Download PDFInfo
- Publication number
- JP3874112B2 JP3874112B2 JP2003111166A JP2003111166A JP3874112B2 JP 3874112 B2 JP3874112 B2 JP 3874112B2 JP 2003111166 A JP2003111166 A JP 2003111166A JP 2003111166 A JP2003111166 A JP 2003111166A JP 3874112 B2 JP3874112 B2 JP 3874112B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- fluctuation
- packets
- amount
- accumulation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/29—Flow control; Congestion control using a combination of thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
- H04M2207/20—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place hybrid systems
- H04M2207/203—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place hybrid systems composed of PSTN and data network, e.g. the Internet
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
- Telephone Function (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、例えば、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話システムにおける音声パケットの授受の際に適用して好適な揺らぎ吸収バッファの制御方法および制御装置に関する。
【０００２】
【従来の技術】
インターネットやイントラネットのようなＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを利用して音声信号を送る技術であるＶｏＩＰを用いて電話通信を行うようにするＶｏＩＰ電話システムが提供されている。このＶｏＩＰ電話システムは、例えば、一般のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）用の規格であるＩＴＵ‐Ｔ勧告Ｈ.３２３が用いられて構成される。
【０００３】
この場合、通話音声信号は所定時間長分毎にパケット化されてＬＡＮ上を順次に伝送されるもので、そのためのトランスポート層のプロトコルとしてはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が用いられる。このＲＴＰにおいては、送信側では、ＲＴＰヘッダの中にパケットの順序番号（シーケンス番号）やタイムスタンプ（時刻情報）を付けてパケットを送信し、受信側では、前記順序番号やタイムスタンプを基に、再生の同期をとることにより、実時間動作をすることができる。
【０００４】
ところで、ＶｏＩＰ端末間での通話品質劣化の要因として、ＬＡＮからの受信ＲＴＰパケット到着時間間隔の遅延、すなわち、揺らぎが挙げられる。この揺らぎの問題については、従来から対策が施されており、通常、受信開始時に、一定数のパケットを揺らぎ吸収バッファに蓄積して、音声の再生を遅れさせることにより、揺らぎの吸収を行っている。
【０００５】
揺らぎ吸収バッファのバッファサイズは、開始蓄積パケット数と、最大蓄積パケット数とにより決定される。開始蓄積パケット数は、ＲＴＰパケット受信開始時に、揺らぎ吸収バッファからのパケットの読み出しを遅らせて、音声再生開始を待たせる受信パケット数である。
【０００６】
すなわち、ＲＴＰパケット受信開始時には、揺らぎ吸収バッファに、開始蓄積パケット数の受信パケットが蓄積されるまで、揺らぎ吸収バッファからパケットデータは読み出さず、揺らぎ吸収バッファに開始蓄積パケット数の受信パケットが蓄積されたときには、次の受信パケットの到来のときに、蓄積している受信パケットの先頭のパケットを読み出すようにする。
【０００７】
最大蓄積パケット数は、揺らぎ吸収バッファに蓄積可能な最大パケット数であり、音声再生の遅延の最大値に対応する。揺らぎ吸収バッファの蓄積パケット数が、この最大蓄積パケット数を越えた場合には、開始蓄積パケット数分のパケットをバッファ内に残して、それ以外の蓄積パケットを破棄するようにする。これにより、音声再生の遅延を最大蓄積パケット数の範囲内に押さえるようにしている。
【０００８】
従来、開始蓄積パケット数と最大蓄積パケット数の値、したがって、揺らぎ吸収バッファのバッファサイズは、使用環境に応じて設定された固定値とされていた。
【０００９】
【発明が解決しようとする課題】
ところで、揺らぎ吸収バッファのバッファサイズを決定するに当たって、開始蓄積パケット数は、揺らぎ収束状態における揺らぎ量より大きい値に設定されることが望ましく、また、最大蓄積パケット数は、最大の揺らぎ量より大きい値であるように設定されることが望ましい。これらの値が適切に設定されると、揺らぎ吸収バッファにより、揺らぎが確実に吸収されて、良好な通話品質が得られる。
【００１０】
しかしながら、端末の実装環境毎に発生する前記揺らぎの量は、パケット伝達経路のトラフィック状況により随時変化するため、事前にそれを的確に把握して、開始蓄積パケット数や最大蓄積パケット数を適切に設定することは、一般に、非常に難しく、実際の揺らぎよりも揺らぎ吸収バッファのバッファサイズが小さすぎたり、大きすぎたりすることが多々ある。
【００１１】
発生する揺らぎに対して、揺らぎ吸収バッファのサイズが小さい場合には、揺らぎによりパケット受信間隔が遅延している間に、揺らぎ吸収バッファに蓄積されていたパケット分の音声データを再生しきってしまうため、再生音声の音切れの問題が発生する。
【００１２】
一方、発生する揺らぎに対して、揺らぎ吸収バッファのサイズが大きすぎる場合には、必要以上に音声再生が遅延してしまう問題がある。
【００１３】
以上は、音声データの場合であるが、音声データに限らず、リアルタイム再生が必要なデータを伝送する場合には、同様の問題が生じる。
【００１４】
この発明は、パケット伝達経路のトラフィック状況により随時変化する揺らぎの量に対応することができる揺らぎ吸収バッファの制御方法および装置を提供することを目的とする。
【００１５】
【課題を解決するための手段】
上記課題を解決するために、この発明による揺らぎ吸収バッファの制御方法は、
リアルタイムで再生されるべき情報が所定時間長分毎にパケット化されて順次に伝送されてくるパケットデータを、揺らぎ吸収バッファを通じて受信し、伝送系において発生する前記パケットデータの到着タイミングの揺らぎを、前記揺らぎ吸収バッファにより制御する方法であって、
受信開始時に、前記揺らぎ吸収バッファに、開始蓄積パケット数の受信パケットが蓄積されてから、前記揺らぎ吸収バッファからの前記受信パケットの読み出しを開始し、前記揺らぎ吸収バッファに蓄積される受信パケット数が最大蓄積パケット数を越えた時には、所定数の受信パケットを破棄するようにする揺らぎ吸収バッファの制御方法において、
前記受信したパケットについて、前記開始蓄積パケット数よりも大きな前記揺らぎが発生した場合に、前記開始蓄積パケット数および前記最大蓄積パケット数を増加変更する開始蓄積量増加工程と、
前記揺らぎ量が、そのときの前記開始蓄積パケット数より低い値で安定している場合に、前記開始蓄積パケット数および前記最大蓄積パケット数を、そのときの値よりも少ない値に変更する開始蓄積量減少工程と、
を備えることを特徴とする。
【００１６】
【作用】
上述の構成のこの発明によれば、開始蓄積量増加工程において、開始蓄積パケット数よりも大きな揺らぎが発生した場合には、開始蓄積パケット数および最大蓄積パケット数が増加変更される。
【００１７】
そして、開始蓄積パケット数および最大蓄積パケット数が増加変更された後、揺らぎ量が、前記変更された開始蓄積パケット数より低い値で安定するようになった場合には、開始蓄積量減少工程において、そのときの開始蓄積パケット数および最大蓄積パケット数が、より少ない値に変更される。
【００１８】
したがって、この発明によれば、パケット伝達経路のトラフィック状況により随時変化する揺らぎの量に、揺らぎ吸収バッファのバッファサイズを動的に対応することができ、例えばパケットデータが音声データである場合に、音切れの問題を軽減することができる。また、必要以上に音声再生が遅延してしまう問題をも、回避することができる。
【００１９】
【発明の実施の形態】
以下、この発明による揺らぎ吸収バッファの制御方法の実施形態を、ＶｏＩＰ電話システムにおける音声パケットの伝送に適用した場合を例にとって、図を参照しながら説明する。
【００２０】
図１は、この実施形態におけるＶｏＩＰ電話システムの全体の概要を示すブロック図である。この例のＶｏＩＰ電話システムは、ゲートキーパー１と、電話端末（Ｈ．３２３端末）２の複数個と、ＬＡＮ３と、ＶｏＩＰゲートウエイ４とによって構成される。
【００２１】
電話端末２は、コンピュータの機能を備えると共に、ハンドセット２Ｈを備えている。そして、複数個の電話端末２のそれぞれは、ＩＰネットワークを構成するＬＡＮ３に接続され、このＬＡＮ３を通じてゲートキーパー１に接続されている。
【００２２】
ＶｏＩＰゲートウエイ４は、複数回線分の電話回線６を介して、電話網５と接続されると共に、ＬＡＮ３に接続される。電話回線６は、例えばＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）回線、専用回線などを含む。このゲートウエイ４は、電話網５とＩＰネットワークとを接続するための機能を備える中継管理装置の役割を果たすもので、連続音声信号とＩＰ音声パケットの相互変換や、ＩＰ音声パケットのゲートキーパー１とのやり取り、さらに、電話番号とＩＰアドレスとの相互変換を行う。
【００２３】
この場合、ＬＡＮ３は、ＩＴＵ−Ｔ勧告Ｈ．３２３の規格によるＩＰネットワークの構成とされている。
【００２４】
ゲートキーパー１は、ＩＴＵ−Ｔ勧告Ｈ．３２３のシステム構成の中で中心的な管理機能を担当するもので、例えばパーソナルコンピュータで構成される。複数の電話端末２のそれぞれは、ＬＡＮ３に接続されたときに、ゲートキーパー１に登録される。
【００２５】
ゲートキーパー１は、システム内のゲートウエイ４や複数の電話端末２の交換管理、帯域幅の割り当て、電話番号とＩＰアドレスの対応付けなどを行い、これに登録された複数個の電話端末による複数の電話回線６を利用した電話通信を管理する機能を有する交換管理装置の役割を果たす。
【００２６】
［ゲートキーパー１のハードウエア構成例］
この実施の形態のシステムにおけるゲートキーパー１のハードウエア構成例を図２に示す。この実施の形態のゲートキーパー１は、例えばパーソナルコンピュータにより構成されるもので、ＣＰＵ１１０に対して、システムバス１１１を介してＲＯＭ１１２と、ＲＡＭ１１３と、ＬＡＮインターフェイス１１４と、パケット処理部１１５と、ネットワーク管理メモリ１１６とが接続されている。
【００２７】
ＲＯＭ１１２には、電話番号情報とＩＰアドレスとの変換の処理プログラムなど、ゲートキーパー１が実行する処理プログラムが記憶されている。
【００２８】
ＲＡＭ１１３は、主としてＲＯＭ１１２のプログラムがＣＰＵ１１０によって実行される際にワークエリアとして使用される。
【００２９】
また、ＬＡＮインターフェイス１１４は、ＬＡＮ３を通じて送られてくるパケット化データを取り込み、また、ＬＡＮ３にパケット化データを送出するための機能を備える。
【００３０】
パケット処理部１１５は、ＬＡＮインターフェイス１１４により取り込んだパケットが、制御データのパケットであった場合には、その制御データを解読するために、受信したパケットを分解し、また、送信する制御データのパケット化データを生成する機能を有する。
【００３１】
なお、音声データのパケットの場合には、一般的には、ゲートキーパー１を介さずに、ゲートウエイ４と電話端末２との間でやり取りする。ただし、ゲートキーパー１を介して音声データのパケットの転送を行う場合もあり、その場合には、ゲートキーパー１は、ゲートウエイ４からのパケットは電話端末２に宛てて、電話端末２からのパケットはゲートウエイ４または他の電話端末２に宛てて、その音声パケットを転送するようにする。
【００３２】
そして、パケット処理部１１５は、パケット化データを分解／生成したり、転送処理のために一時保存したりするためのバッファメモリを備える。
【００３３】
ネットワーク管理メモリ１１６は、ネットワーク内に存在するゲートウエイ４や複数の電話端末２の登録情報やそれらのＩＰアドレスおよび、電話端末２のＩＰアドレスと電話番号との対応などの情報を記憶している。ＣＰＵ１１０は、それらの情報を用いて、パケットの行き先のＩＰアドレスを決定したり、受信先のＩＰアドレスを判別したりする。
【００３４】
［電話端末２のハードウエア構成例］
この実施形態のシステムにおける電話端末２は、図３に示すようなハードウエア構成例を示すものである。この実施形態の電話端末２は、端末本体２００と、ハンドセット２Ｈとからなる。ハンドセット２Ｈは、図示を省略したが、送話器を構成するマイクロホンと、送話アンプと、受話器を構成するスピーカと、受話アンプとを備えている。
【００３５】
端末本体２００は、コンピュータにより構成されており、ＣＰＵ２１０に対して、システムバス２１１を介してＲＯＭ２１２と、ＲＡＭ２１３と、ディスプレイコントローラ２１４と、操作入力インターフェイス（図ではインターフェイスはＩ／Ｆと記載する。以下同じ）２１６と、ＬＡＮインターフェイス２１８と、パケット分解／生成部２１９と、音声データ入出力インターフェイス２２０と、揺らぎ吸収バッファを構成するＲＴＰ受信バッファ２２１と、ＲＴＰ送信バッファ２２２とが接続されている。
【００３６】
ディスプレイコントローラ２１４には、ディスプレイ２１５が接続されており、このディスプレイ２１５の表示画面には、ＣＰＵ２１０の制御にしたがった表示が行われる。
【００３７】
また、操作入力インターフェイス２１６には、テンキー、カーソルキー、その他の操作キーを含む操作入力部２１７が接続されている。ＣＰＵ２１０は、操作入力インターフェイス２１６を介して操作入力部２１７を通じて使用者がいずれの入力キーを操作したかを認識し、その認識結果に基づいて、キー入力操作に応じた処理をＲＯＭ２１２のプログラムに従って実行する。
【００３８】
ＲＯＭ２１２には、電話端末２をゲートキーパー１に登録する際の処理シーケンスを実行するためのプログラムや揺らぎ吸収バッファを構成するＲＴＰ受信バッファ２２１のバッファサイズを、ＬＡＮ３上で実際に発生する揺らぎに動的に対応して制御するためのプログラムなどが記憶されている。
【００３９】
ＲＡＭ２１３は、主としてＲＯＭ２１２のプログラムがＣＰＵ２１０によって実行される際にワークエリアとして使用される。
【００４０】
ＬＡＮインターフェイス２１８は、ＬＡＮ３を通じて送られてくるパケット化データを取り込んでＲＴＰ受信バッファ２２１に順次に蓄積し、また、ＲＴＰ送信バッファ２２２に蓄積されている音声データの送信パケットを、ＬＡＮ３の空きを確認しながら、ＬＡＮ３に順次に送出する機能を備える。
【００４１】
パケット分解／生成部２１９は、ＬＡＮインターフェイス２１８により取り込まれ、ＲＴＰ受信バッファ２２１から読み出されたパケット化データを分解して、制御データや音声データを得る機能と、送信する制御データや所定時間分毎の音声データをパケット化したパケット化データを生成し、ＲＴＰ送信バッファ２２２に転送する機能を有する。このパケット分解／生成部２１９は、パケット化データを分解したり、生成したりするためのバッファメモリを備える。
【００４２】
なお、このパケット分解／生成部２１９のパケット分解処理機能や生成処理機能は、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）により構成されるが、ＣＰＵ２１０と、ＲＯＭ２１２とにより、ソフトウエアとして実現することもできる。
【００４３】
音声データ入出力インターフェイス２２０は、パケット分解されて得られた音声データをアナログ音声信号に変換してハンドセット２Ｈに供給し、また、ハンドセット２Ｈから入力されるアナログ音声信号をデジタル信号に変換して取り込む機能を備える。
【００４４】
［ゲートウエイ４のハードウエア構成例］
この実施の形態のシステムにおけるゲートウエイ４のハードウエア構成例を図４に示す。この実施の形態のゲートウエイ４は、例えばパーソナルコンピュータにより構成されるもので、ＣＰＵ４１０に対して、システムバス４１１を介してＲＯＭ４１２と、ＲＡＭ４１３と、ＬＡＮインターフェイス４１４と、パケット処理部４１５と、揺らぎ吸収バッファを構成するＲＴＰ受信バッファ４１７と、ＲＴＰ送信バッファ４１８とが接続されている。
【００４５】
ＲＴＰ受信バッファ４１７とＲＴＰ送信バッファ４１８とは、図４では、一つずつ示したが、実際には、複数本の電話回線６のそれぞれの電話回線に対して、一つずつ設けられるものである。
【００４６】
ＲＯＭ４１２には、電話端末２からの音声パケットのデータを、ＲＴＰ受信バッファ４１７を介して受け取り、電話回線６を通じて電話網５に送出するデータに変換するためのプログラム、また、逆に電話網５から取得したデータをＬＡＮ３を通じて電話端末２に送出するパケット化データに変換するためのプログラムや、揺らぎ吸収バッファを構成するＲＴＰ受信バッファ４１７のバッファサイズを、ＬＡＮ３上で実際に発生する揺らぎに動的に対応して制御するためのプログラムなどが記憶されている。
【００４７】
ＲＡＭ４１３は、主としてＲＯＭ４１２のプログラムがＣＰＵ４１０によって実行される際にワークエリアとして使用される。
【００４８】
また、ＬＡＮインターフェイス４１４は、ＬＡＮ３を通じて送られてくるパケット化データを取り込み、また、ＬＡＮ３にパケット化データを送出するための機能を備える。
【００４９】
パケット処理部４１５は、ＬＡＮインターフェイス４１４により取り込んだパケットを分解して、電話網５を伝送する形式のデータに変換し、また、電話網５から受信したデータをパケット化して、ＬＡＮインターフェイス４１４を通じてＬＡＮ３に送出するパケット化データを生成する機能を有する。
【００５０】
［揺らぎ吸収バッファの制御方法の実施形態の説明］
この実施形態の揺らぎ吸収バッファの制御方法は、電話端末のＲＴＰ受信バッファ２２１、また、ゲートウエイ４のＲＴＰ受信バッファ４１７の、いずれの制御にも適用される。この実施の形態においては、揺らぎ吸収バッファとしてのＲＴＰ受信バッファ２２１または４１７のバッファサイズを、ＬＡＮ３において実際に発生する揺らぎに応じて動的（ダイナミック）に変更制御するものである。
【００５１】
この実施形態のバッファサイズの制御方法を説明する前に、揺らぎ吸収バッファのバッファサイズを決定するためのパラメータの定義を、図５を参照して説明する。この図５は、揺らぎ吸収バッファとしてのＲＴＰ受信バッファ２２１または４１７のバッファサイズを決定するためのイメージを説明するためのものである。
【００５２】
初期再生パケット数は、ＲＴＰ受信バッファから読み出すパケット数であり、固定値であって、この例では、初期再生パケット数＝１とされている。
【００５３】
開始蓄積パケット数は、前述したように、パケット受信開始時に、ＲＴＰ受信バッファからのパケットの読み出しを遅らせて、音声再生開始を待たせる受信パケット数である。前述したように、この開始蓄積パケット数は従来は固定値であったが、この実施形態では、後述するようにＬＡＮ３に発生する揺らぎ量に応じて動的に変化する。以下に説明する例では、開始蓄積パケット数の初期値は、開始蓄積パケット数の初期値＝４とされている。
【００５４】
次に、最大蓄積パケット数は、前述したように、揺らぎ吸収バッファであるＲＴＰ受信バッファに蓄積可能な最大パケット数であり、ＲＴＰ受信バッファに最大蓄積パケット数以上のパケットが蓄積されたときには、前述したように、開始蓄積パケット数分のパケットをＲＴＰ受信バッファ内に残して、それ以外の蓄積パケットを破棄する。このときに破棄するパケット数を、溢れバッファ破棄数と呼び、この例では、溢れバッファ破棄数＝２とされる。
【００５５】
この最大蓄積パケット数は、
最大蓄積パケット数＝開始蓄積パケット数＋溢れバッファ破棄数
と定義できるもので、音声再生の遅延の最大値に対応する。この実施形態では、上記の定義から、開始蓄積パケット数が動的変化値であるので、これも動的変化値である。
【００５６】
次に、最大開始蓄積パケット数は、動的変化値である開始蓄積パケット数の最大値（上限）であり、固定値である。
【００５７】
ＲＴＰ受信バッファは、図５に示すように、最大開始蓄積パケット数以上のメモリセル（１つのパケットの蓄積メモリ部をこの明細書ではセルと呼ぶ）を備え、メモリアクセス上、最後のメモリセルの次には最初のメモリセルに戻るようにされたリング状のバッファ構成とされている。
【００５８】
そして、ＲＴＰ受信バッファから読み出すパケット位置（メモリセル）は参照インデックスにより指定される。参照インデックスのメモリセルにパケットが蓄積されていないとき、または、ＲＴＰ受信バッファに開始蓄積パケット数が蓄積されていないときには、パケットは読み出さずに、無音再生を行う。このときは、参照インデックスはインクリメントしない。
【００５９】
そして、開始蓄積パケット数分のパケットがＲＴＰ受信バッファに蓄積されていて、参照インデックスのセルのパケットの読み出しをしたときには、参照インデックスをインクリメントする。
【００６０】
また、ＣＰＵ２１０またはＣＰＵ４１０は、ＲＴＰ受信バッファ２２１または４１７の各メモリセルに蓄積されているパケットのシーケンス番号を保持して管理している。シーケンス番号は、パケットのＲＴＰヘッダに含まれており、パケットの受信時にＲＴＰヘッダを解析して取得する。
【００６１】
そして、検索開始インデックスが、
検索開始インデックス＝参照インデックス＋初期再生パケット数
として定義されている。ＣＰＵ２１０またはＣＰＵ４１０は、パケットを受信したとき、受信したパケットのＲＴＰヘッダからシーケンス番号を抽出して検知し、検索開始インデックスのメモリセルから、各メモリセルに格納されているパケットのシーケンス番号を検索し、受信パケットを格納するメモリセルを決定する。
【００６２】
図６は、揺らぎ吸収バッファの制御装置５００の機能ブロック図である。この図６の揺らぎ吸収バッファの制御装置５００は、電話端末２およびゲートウエイ４のいずれにも適用されるものであり、図３に示した電話端末２の端末本体２００のハードウエアおよび図４に示したゲートウエイ４のハードウエアから、揺らぎ吸収バッファとしてのＲＴＰ受信バッファ２２１，４１７の制御に関する部分を抽出したものに相当する。
【００６３】
ＬＡＮ３を通じて自分宛に送られてくるＲＴＰパケットは、データ受信部５０１（ＬＡＮインターフェイス２１８，４１４に対応）で受信され、揺らぎ吸収バッファ５０２（ＲＴＰ受信バッファ２２１または４１７に対応）に蓄積される。データ受信部５０１で受信されたＲＴＰパケットは、揺らぎ検出部５０３に供給されて、ＬＡＮ３において発生しているＲＴＰパケットについての揺らぎ量（単位は時間）が検出される。
【００６４】
ここで、揺らぎ量は、順次に受信される２つの受信ＲＴＰパケットの到着時間差と、パケットのＲＴＰヘッダに含まれるタイムスタンプの差よりパケット受信毎に算出される。
【００６５】
すなわち、シーケンス番号がｉのパケットＳｉのタイムスタンプをＴｉ、パケットＳｉの到着時間をＡｉ、パケットＳｉの受信時の揺らぎ量をＤｉとしたとき、
Ｄｉ＝（Ａｉ−Ａｉ−１）−（Ｔｉ−Ｔｉ−１） ・・・（式１）
により、揺らぎ量Ｄｉが算出される。
【００６６】
揺らぎ検出部５０３で検出された揺らぎ量Ｄｉは、バッファ制御部５０４に供給される。バッファ制御部５０４は、揺らぎ検出部５０３で検出された揺らぎ量Ｄｉに基づいて、後述するようにＲＴＰ受信バッファのバッファサイズの制御を行い、揺らぎ吸収処理を行いながら、揺らぎ吸収バッファ５０２から受信パケットを読み出し、データデコード処理部５０５に供給する。
【００６７】
データデコード処理部５０５は、受け取ったパケットを分解して音声データをデコードする。そして、データ送信部５０６に供給する。データ送信部５０６は、電話端末２の場合であれば、音声データをアナログ音声信号に変換してハンドセット２Ｈに送る。また、データ送信部５０６は、ゲートウエイ４の場合であれば、音声データを空き回線を通じて電話網５に送出する。
【００６８】
なお、揺らぎ検出部５０３およびバッファ制御部５０４の動作は、ＣＰＵ２１０または４１０により実行される。また、データデコード処理部５０５は、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）により構成される。データ送信部５０６は、音声データ入出力インターフェイス２２０または回線インターフェイス４１６により構成される。
【００６９】
［バッファ制御部５０４における開始蓄積量の制御動作］
この実施形態では、ＲＴＰ受信バッファの開始蓄積量（開始蓄積パケット数に対応）は、ＬＡＮ３上で発生する揺らぎ量に応じて動的に制御するが、この開始蓄積量の動的制御には、開始蓄積量の増加制御と、開始蓄積量の減少制御とがある。なお、この明細書において、蓄積量等における「量」は、時間の単位の値を示しており、蓄積パケット数等における「パケット数」は、前記「量」としての時間を、１パケット当たりの時間で割った値となるものである。
【００７０】
〔開始蓄積量の増加手順〕
まず、開始蓄積量の増加制御手順について説明する。
この実施の形態においては、開始蓄積量より大きな揺らぎが、連続して、または周期的に、ＬＡＮ３上に発生した場合、開始蓄積量を増やして、受信パケットを再蓄積するようにする。以下、その増加手順を説明する。
【００７１】
（１）増加目標蓄積量の算出
パケットを受信する毎に、揺らぎ量を検出し、検出した揺らぎ量の増減から、増加目標蓄積量を算出する。増加目標蓄積量は、開始蓄積量を増加させるときの目標値である。すなわち、増加目標蓄積量をＩＢｉとし、その初期値をＩＢｏ、揺らぎ量をＤｉとしたとき、以下のようにして、増加目標蓄積量ＩＢｉを求める。なお、サフィックスｉは、パケットのシーケンス番号に相当する。
【００７２】
ＩＢｏ＝開始蓄積量
ＩＢｉ＝ＩＢｉ−１＋ｆａ（Ｄｉ，ＩＢｉ−１）／ＣＩ ・・・（式２）
ただし、
Ｄｉ＞ＩＢｉ−１の場合
ｆａ（Ｄｉ，ＩＢｉ−１）＝Ｄｉ−ＩＢｉ−１
Ｄｉ≦ＩＢｉ−１の場合
ｆａ（Ｄｉ，ＩＢｉ−１）＝０
・・・（式３）
ここで、ＣＩは収束速度定数であり、ＣＩ≧１である。この収束速度定数ＣＩにより、局所的に発生した揺らぎの影響を抑え、連続的に発生する揺らぎ量を得ることができる。
【００７３】
（２）開始蓄積量の更新
揺らぎ遅延によりＲＴＰ受信バッファが空になったときに、開始蓄積量＝増加目標蓄積量として、開始蓄積量を増加目標蓄積量に置き換えて増加させる。そして、更新された開始蓄積量になるまで、ＲＴＰ受信バッファからのパケットの読み出しを停止して、ＲＴＰ受信バッファに受信パケットを再蓄積する。なお、増加目標蓄積量＞最大開始蓄積量のときには、増加目標蓄積量＝最大開始蓄積量とされて制限される。
【００７４】
以上のようにして、この実施の形態においては、揺らぎが連続的または周期的に発生する期間が十分に長ければ、揺らぎに対する蓄積量の不足分が増加目標蓄積量に累積されてゆき、増加目標蓄積量は適切な揺らぎ量（ＩＢｉ＞Ｄｉ）で収束してゆくので、その収束した増加目標蓄積量に開始蓄積量を置き換えることにより、発生する揺らぎ量に対応した揺らぎ吸収を行うことができる。
【００７５】
〔開始蓄積量の減少手順〕
次に、開始蓄積量の減少制御手順について説明する。
上述のようにして開始蓄積量を増加させた後、揺らぎがより小さい値に収束することがあるが、そのように揺らぎ量が小さくなった場合にも、開始蓄積量を、増加したままの値に保持していた場合には、ＲＴＰ受信バッファでの遅延（通話遅延）が大きくなる問題がある。
【００７６】
この実施形態では、揺らぎ量が、そのときの開始蓄積量よりも低い値で安定している場合には、通話遅延を減少させるために、適切な開始蓄積量にまで減少させるようにする。この実施の形態では、以下の手順で揺らぎが安定しているかどうかを判定し、適切な開始蓄積量の算出を行う。
【００７７】
（１）減少目標蓄積量の算出
パケットを受信する毎に、揺らぎ量を検出し、検出した揺らぎ量の増減から、開始蓄積量を減少させるときの目標値を求めるための減少目標蓄積量を算出する。すなわち、減少目標蓄積量をＤＢｉとし、その初期値をＤＢｏ、揺らぎ量をＤｉとし、増加目標蓄積量をＩＢｉとし、収束速度定数をＣＤとしたとき、以下のようにして、減少目標蓄積量ＤＢｉを求める。
【００７８】
ＤＢｏ＝０
Ｄｉ＞ＩＢｉ−１の場合
ＤＢｉ＝０
Ｄｉ≦ＩＢｉ−１の場合
ＤＢｉ＝ＤＢｉ−１＋ｆｂ（Ｄｉ，ＤＢｉ−１）／ＣＤ
・・・（式４）
ただし、
Ｄｉ＞ＤＢｉ−１の場合
ｆｂ（Ｄｉ，ＤＢｉ−１）＝Ｄｉ−ＤＢｉ−１
Ｄｉ≦ＤＢｉ−１の場合
ｆｂ（Ｄｉ，ＤＢｉ−１）＝０
・・・（式５）
ここで、収束速度定数ＣＤは、ＣＤ≧１である。
【００７９】
なお、式４において、減少目標蓄積量ＤＢｉの更新判定に、増加目標蓄積量ＩＢｉを用いるのは、前述の（式２），（式３）との同期のためである。
【００８０】
（２）揺らぎ安定の判定
揺らぎが安定したかどうかは、減少目標蓄積量が変化しない期間の長さ（パケット受信回数）で判定する。この実施形態では、収束期間カウント値ＣＮＴを、以下の手順で更新し、揺らぎ安定判定を行う。
【００８１】
すなわち、
Ｄｉ＞ＤＢｉ−１の場合
ＣＮＴ＝０
Ｄｉ≦ＤＢｉ−１の場合
ＣＮＴｉ＝ＣＮＴｉ−１＋１
・・・（式６）
とする。
【００８２】
そして、収束期間カウント値ＣＮＴが、予め定めた揺らぎ安定と認められるような収束期間カウント値である収束期間定数ＣＮＴ−ｔｈよりも大きくなったかどうかを検査し、収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなったときには、揺らぎが安定したと判定する。
【００８３】
なお、収束期間定数ＣＮＴ−ｔｈは、固定値でもよいし、また、受信パケットサイズにより変更するようにしてもよい。
【００８４】
（３）バッファ更新判定およびバッファ更新処理
収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したと判定したときには、ＲＴＰ受信バッファのバッファサイズを変更するかどうかのバッファ更新判定を行う。バッファ更新判定は、開始蓄積量と減少目標蓄積量との差が、予め定めた最小減少量よりも大きいかどうかにより行う。最小減少量は、例えば１パケット分の時間とされる。
【００８５】
バッファ更新判定の結果、開始蓄積量と減少目標蓄積量との差が、予め定めた最小減少量よりも小さい場合には、ＲＴＰ受信バッファサイズは、減少処理する必要がないとして、収束期間カウント値ＣＮＴや減少目標蓄積量はゼロリセットされる。
【００８６】
バッファ更新判定の結果、開始蓄積量と減少目標蓄積量との差が、予め定めた最小減少量よりも大きい場合には、バッファ更新処理を実行して、開始蓄積量＝減少目標蓄積量とし、開始蓄積量を減少目標蓄積量まで減少させる。ただし、１度のバッファ更新手順で減少させる開始蓄積量は、予めパラメータとして設定された最大減少量により制限する。そして、収束期間カウント値ＣＮＴや減少目標蓄積量はゼロリセットすると共に、減少した分のバッファ内パケットを破棄するようにする。
【００８７】
図７のフローチャートを参照して、以上のバッファ更新判定およびバッファ更新処理のルーチンを、さらに説明する。この図７の処理は、パケットを受信する毎に、電話端末２では、ＣＰＵ２１０により、ゲートウエイ４では、ＣＰＵ４１０により実行されるものである。
【００８８】
まず、収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したかどうかを判定する（ステップＳ１）。揺らぎが安定していないと判定したときには、このルーチンを抜けて他の処理ステップに進む。
【００８９】
また、揺らぎが安定したと判定したときには、その時点における開始蓄積量から減少目標蓄積量を減算して、その減算結果ΔＳを求める（ステップＳ２）。そして、その減算結果ΔＳが、予め設定された最小減少量よりも大きいかどうか判定する（ステップＳ３）。
【００９０】
ステップＳ３で、減算結果ΔＳが、予め設定された最小減少量よりも小さいと判定された場合には、収束期間カウント値ＣＮＴを「０」にし（ステップＳ４）、また、減少目標蓄積量を「０」にする（ステップＳ５）。
【００９１】
ステップＳ３で、減算結果ΔＳが、予め設定された最小減少量よりも大きいと判定されたときには、当該減算結果ΔＳは、予め設定された最大減少量以下であるか否か判別する（ステップＳ６）。
【００９２】
このステップＳ６において、減算結果ΔＳは、予め設定された最大減少量以下であると判別したときには、開始蓄積量＝減少目標蓄積量として、開始蓄積量を減少させる（ステップＳ７）。また、ステップＳ６において、減算結果ΔＳは、予め設定された最大減少量よりも大きいと判別したときには、開始蓄積量＝そのときの開始蓄積量−最大減少量として、開始蓄積量を、最大減少量分だけ減少させる（ステップＳ８）。
【００９３】
ステップＳ７およびステップＳ８の後は、ステップＳ９に進んで、増加目標蓄積量を、更新された開始蓄積量に置き換える。つまり、この時点から、増加目標蓄積量の初期値は、更新された開始蓄積量になる。
【００９４】
次に、収束期間カウント値ＣＮＴを「０」にし（ステップＳ１０）、また、減少目標蓄積量を「０」にする（ステップＳ１１）。さらに、開始蓄積量を減少させたことにより溢れる分のパケットデータを、ＲＴＰ受信バッファから破棄する（ステップ１２）。この場合の開始蓄積量の減少により破棄するパケット数は、最大蓄積パケット数を越えて溢れたときに破棄する溢れバッファ破棄数のような固定値ではなく、動的なものとなる。以上で、バッファ更新処理は終了となる。
【００９５】
［揺らぎ吸収バッファ制御の処理ルーチン］
次に、揺らぎ吸収バッファのバッファサイズの制御および読み出し処理動作の全体を、図８および図９のフローチャートを参照しながら説明する。
【００９６】
ＲＴＰパケットを受信すると、電話端末２では、ＣＰＵ２１０に、ゲートウエイ４ではＣＰＵ４１０に割り込みが発生して、図８および図９のフローチャートの処理ルーチンを開始し、まず、ＲＴＰヘッダを解析する（ステップＳ２１）。次に、既にパケットの受信を開始しているかどうか判別する（ステップＳ２２）。
【００９７】
ステップＳ２２で、未だ、パケット受信開始状態になっておらず、受信したパケットが受信開始のパケットであると判別したときには、パケットサイズ、つまり、音声データサイズを、予め決定されているパラメータに基づいて取得する（ステップＳ２３）。
【００９８】
すなわち、この例においては、送信側は、音声信号を所定時間長分毎にパケット化して、ＬＡＮ３に送出するが、この場合のパケット化の際の所定時間長（音声データのサイズ）は、例えば１０ｍｓｅｃ、２０ｍｓｅｃ、３０ｍｓｅｃなどのいくつかのサイズの中から、選択することができる。そして、どのサイズでパケット化されているかの情報（パラメータ）は、音声データの送受信の前に制御信号をやり取りすることにより決定されており、その情報（パラメータ）により、音声データサイズを取得する。
【００９９】
音声データサイズを取得したら、初期再生パケット数、開始蓄積パケット数の初期値、バッファ破棄数、最大開始蓄積パケット数等のバッファサイズ制御パラメータを算出する（ステップＳ２４）。この例では、開始蓄積量の初期値、バッファ破棄量、最大開始蓄積量は、時間単位で定められており、１パケット当たりの時間長である音声データサイズから、前記パラメータをパケット数単位に変換する。
【０１００】
例えば、開始蓄積量の初期値が３０ｍｓｅｃ、バッファ破棄量が２０ｍｓｅｃ、最大開始蓄積量が１０００ｍｓｅｃに設定されており、音声データサイズが、１０ｍｓｅｃ／パケットであったときには、開始蓄積パケット数の初期値は「３」、バッファ破棄数は「２」、最大開始蓄積パケット数は「１００」となる。
【０１０１】
以上のパラメータの算出が終了したら、ＲＴＰ受信バッファを受信開始状態にし、ステップＳ２３で取得した音声データサイズに合わせて、図６のデータデコード処理部５０５の制御側からの受信割り込み周期を設定する（ステップＳ２５）。そして、前記受信割り込み周期は、データデコード処理部５０５が制御側から受信する割り込みに関するものであり、この割り込みは、ＬＡＮ３側の音声データの受信で発生するものではない。
【０１０２】
電話端末２あるいはゲートウエイ４は、この受信割り込み周期で、ＲＴＰ受信バッファからパケットの取り出しを行って、後述する音声送出処理を行う。
【０１０３】
次に、受信開始状態にしたら、到着したパケットについての揺らぎ量の算出を行う。また、ステップＳ２２で既に受信開始状態であると判別したときには、即座に、到着したパケットについての揺らぎ量の算出を行う（ステップＳ２６）。
このステップＳ２６における揺らぎ量の算出は、前述した（式１）によって行われる。
【０１０４】
次に、算出した揺らぎ量に基づき、前述の（式２）、（式３）に基づき増加目標蓄積量ＩＢｉの算出を行うと共に、前述の（式４）、（式５）に基づき減少目標蓄積量ＤＢｉの算出を行う（ステップＳ２７）。
【０１０５】
次に、ＲＴＰ受信バッファ内の蓄積パケット数が、初期再生パケット数より小さいかどうか判定する（ステップＳ２８）。
【０１０６】
ＲＴＰ受信バッファ内の蓄積パケット数が、初期再生パケット数より小さいときには、再生するパケットがバッファ内にないため、ＲＴＰ受信バッファからのパケットの読み出し時に用いるバッファ参照フラグを「ＦＡＬＳＥ」にして、バッファ参照を禁止させ、無音生成を指示する（ステップＳ２９）。
【０１０７】
次に、開始蓄積量を、そのときの増加目標蓄積量とする（ステップＳ３０）。
ただし、増加目標蓄積量が最大開始蓄積量よりも大きいとき（増加目標蓄積量＞最大開始蓄積量）には、開始蓄積量＝最大開始蓄積量に制限される。前述したように、増加目標蓄積量の初期値は、開始蓄積量の初期値である。
【０１０８】
このステップＳ３０においては、パケットの受信を開始したときには、前回のパケット受信時における揺らぎ量に応じたＲＴＰ受信バッファサイズとなるように、開始蓄積量が設定される。また、パケットの受信を開始している状態においては、ＲＴＰ受信バッファ内の蓄積パケット数が、初期再生パケット数より小さいということは、揺らぎによる遅延のために、ＲＴＰ受信バッファ内のパケットが空になったことを意味するため、開始蓄積量がそのときの増加目標蓄積量に増加変更される。
【０１０９】
次に、ＲＴＰ受信バッファサイズを、
ＲＴＰ受信バッファサイズ＝開始蓄積パケット数
として算出する（ステップＳ３１）。また、最大蓄積パケット数を、
最大蓄積パケット数＝ＲＴＰ受信バッファサイズ＋溢れ時のバッファ破棄数
として算出する（ステップＳ３２）。次に、次回受信したときに、受信パケットをＲＴＰ受信バッファのいずれのメモリセルに蓄積するかを検索する際の開始インデックス（インデックスは、ＲＴＰ受信バッファのメモリセルを指し示す指標である）である検索開始インデックスを、ＲＴＰ受信バッファの先頭にセットする（ステップＳ３３）。その後、ＲＴＰ受信バッファへの受信パケット蓄積処理に進む（ステップＳ３５）。
【０１１０】
また、ステップ２８で、蓄積パケット数が初期再生パケット数以上であると判別したときには、検索開始インデックスを、
検索開始インデックス＝参照インデックス＋初期再生パケット数
とする（ステップ３４）。その後、ステップＳ３５の受信パケット蓄積処理に進む。
【０１１１】
ステップ３５の受信パケット蓄積処理においては、前述したように、検索開始インデックスで指し示されるメモリセルから順に、ＲＴＰ受信バッファの各メモリセルに蓄積されているパケットのシーケンス番号を検索して、今回受信したパケットを格納すべきセルを検出し、検出されたセルに、受信パケットを格納する。
【０１１２】
以上のようにして、ＲＴＰ受信バッファ内に受信パケットを蓄積したら、蓄積パケット数を１だけインクリメントする（図９のステップＳ４１）。
【０１１３】
次に、揺らぎが、収束したか否か判別する（ステップＳ４２）。そして、揺らぎが収束したと判別したときには、前述した開始蓄積量の減少手順を実行する（ステップＳ４３）。ステップＳ４２の処理は、図７のステップＳ１の処理に対応し、また、ステップＳ４３の処理は、図７のステップＳ２〜ステップＳ１２に処理に対応する。
【０１１４】
ステップＳ４３での開始蓄積量の減少手順が終了した後と、ステップＳ４２で、減少目標蓄積量が収束していないと判別したときには、ＲＴＰ受信バッファの蓄積パケット数が、最大蓄積パケット数以上であるか否か判別する（ステップ４４）。そして、蓄積パケット数が最大蓄積パケット数以上であると判別したときには、ＲＴＰ受信バッファの先頭から、ステップＳ２４で定められた溢れ時のバッファ破棄数分のパケットを、ＲＴＰ受信バッファから破棄する（ステップＳ４５）。
【０１１５】
ステップＳ４４で、蓄積パケット数が最大蓄積パケット数よりも少ないと判別されたとき、また、ステップ４５でのパケットの破棄処理が終了した後には、蓄積パケット数が、ＲＴＰ受信バッファサイズ以上であるか否か判別する（ステップＳ４６）。
【０１１６】
ステップＳ４６で、蓄積パケット数が、ＲＴＰ受信バッファサイズ以上であると判別したときには、参照インデックスを、ＲＴＰ受信バッファの先頭のセル番号とし（ステップＳ４７）、検索開始インデックスは、
検索開始インデックス＝参照インデックス＋初期再生パケット数
とした後（ステップＳ４８）、バッファ参照フラグを「ＴＲＵＥ」として、音声データ送出処理手順において、バッファ参照を許可し、音声データ再生開始を指示する（ステップＳ４９）。
【０１１７】
その後、このパケット受信時の処理ルーチンを終了する。また、ステップＳ４６で、蓄積パケット数が、ＲＴＰ受信バッファサイズ以上ではないと判別したときにも、このパケット受信時の処理ルーチンを終了する。
【０１１８】
［音声データ送出処理］
次に、図８および図９の受信処理に併せて行われる音声データ送出処理を、図１０のフローチャートを参照しながら説明する。これは、ゲートウエイ４の場合であり、前述の図６の機能ブロック図におけるＤＳＰで構成されたデータデコード処理部５０５における処理である。この図６のデータデコード処理部５０５における処理は、前述したようにして設定された割り込み周期で起動される。前述したように、この例では、この割り込み周期は、音声パケットサイズに合わせたものとされている。なお、割り込み周期は、音声パケットサイズと一致させなくても勿論よい。
【０１１９】
まず、出力する音声チャンネルを選択する（ステップＳ５１）。例えば、音声チャンネル１は、ＩＳＤＮ回線、音声チャンネル２は、アナログ回線とされる。電話端末２の場合であれば、このステップＳ５１の処理は不要である。
【０１２０】
次に、ＲＴＰ受信バッファを検索する（ステップＳ５２）。そして、バッファ参照フラグが「ＴＲＵＥ」であるか「ＦＡＬＳＥ」であるか判別する（ステップＳ５３）。バッファ参照フラグが「ＦＡＬＳＥ」であった場合には、再生すべき音声データがないとして、無音再生処理を行う（ステップＳ５４）。
【０１２１】
バッファ参照フラグが「ＴＲＵＥ」であった場合には、参照インデックスで示されるＲＴＰ受信バッファのセルから音声パケットを読み出すようにし（ステップＳ５５）、音声データが存在するか否か判別する（ステップＳ５６）。
【０１２２】
ステップＳ５６で、音声データがあると判別したときには、音声データを再生し（ステップＳ５７）、ＲＴＰ受信バッファの蓄積パケット数をデクリメントする（ステップＳ５８）。そして、参照インデックスをインクリメントして（ステップＳ５９）、この音声データ送出処理ルーチンを終了する。
【０１２３】
ステップＳ５６で、音声データがないと判別したときには、蓄積パケットがＲＴＰ受信バッファ内にあるか否か判別し（ステップＳ６０）、蓄積パケットがあると判別されたときには、参照インデックスをインクリメントし（ステップＳ６１）、その後、再生音声データなしとして無音再生する（ステップ６２）。また、ステップＳ６０で、蓄積パケットがないと判別したときには、即座にステップＳ６２に進み、無音再生する。
【０１２４】
［ＲＴＰ受信バッファ内のパケット数の変化の具体例］
次に、図１１〜図１３を参照して、パケット到着時のＲＴＰ受信バッファ内のパケット数の変化の具体例について説明する。図１１〜図１３の各図において、ＢＦはＲＴＰ受信バッファを模式的に示し、網掛けを付して示したメモリセルは、パケットが蓄積されていることを示しており、当該蓄積パケットの中に示した数字はシーケンス番号を示している。また、白抜き部分のセルは、空きを示している。
【０１２５】
以下に説明する例では、初期再生パケット数＝１、開始蓄積量の初期パケット数＝３、最大蓄積パケット数の初期値＝５、最大開始蓄積パケット数＝１０とした場合である。開始蓄積パケット数と、最大蓄積パケット数は動的に変化する。
【０１２６】
なお、図１１〜図１３の各図において、Ａ〜Ｄは、Ａ＝開始蓄積量の初期パケット数、Ｂ＝開始蓄積パケット数（動的変化）、Ｃ＝最大蓄積パケット数（動的変化）、Ｄ＝最大開始蓄積パケット数であり、各図において、上方に示したこれらＡ〜Ｄのうち、ＢおよびＣの値は、その初期値を示している。また、図１１〜図１３において、網掛けを付して示したものは、蓄積パケットを示しており、当該蓄積パケットの中に示した数字はシーケンス番号を示している。
【０１２７】
図１１は、パケットの受信開始からの処理と、揺らぎ発生による開始蓄積量および最大蓄積パケット数の変更および揺らぎ吸収処理を示すものである。この図１１では、発生した揺らぎは、パケットを破棄しなければならないほど大きいものではなかった場合である。
【０１２８】
最初のパケットを受信すると、前述したように、音声データサイズ（パケットサイズ）が認識され、バッファサイズ制御パラメータの算出がなされて、受信開始状態とされ、以後、音声データサイズ（パケットサイズ）に基づいて設定された受信割り込み周期で、後述するような音声データ送出処理がなされる。そして、到着したパケットがＲＴＰ受信バッファＢＦに蓄積される。
【０１２９】
そして、パケット受信開始から、ＲＴＰ受信バッファＢＦに３個のパケットが蓄積されるまでは、ＲＴＰ受信バッファＢＦからパケットは読み出されず、無音再生が行われる。
【０１３０】
４個目のパケットが到着すると、それが蓄積されると共に、前述した受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦの先頭のパケットが読み出されて、音声データの送出がなされる。以後は、受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦに蓄積されているパケットは、先頭から順次読み出されて音声データ送出される。したがって、揺らぎが発生しなければ、図１１の例においては、ＲＴＰ受信バッファＢＦには、常に３個のパケットが蓄積される状態になる。
【０１３１】
ここで、遅延揺らぎが発生すると、受信パケットが到着しないにも関わらず、受信割り込み周期のタイミングで、ＲＴＰ受信バッファに蓄積されているパケットは、先頭から順次、読み出されるので、新パケットが到着しない限り、ＲＴＰ受信バッファＢＦ内の蓄積パケット数は、徐々に減ってゆく。
【０１３２】
そして、ＲＴＰ受信バッファＢＦ内の蓄積パケット数がゼロになると、前述したように、開始蓄積パケット数Ｂは、増加目標蓄積パケット数に増加変更される。これに伴い、最大蓄積パケット数Ｃも増加変更される。図１０の例では、開始蓄積パケット数は「５」に、最大蓄積パケット数は「７」にそれぞれ変更される。
【０１３３】
その後、揺らぎの発生により遅れた３周期分と合わせて４個のパケットが到着すると、それがＲＴＰ受信バッファＢＦに蓄積される。この時点では、変更された開始蓄積パケット数「５」には満たないので、ＲＴＰ受信バッファＢＦからパケットは読み出されず、無音再生が行われる。そして、次にパケットが到着してＲＴＰ受信バッファＢＦの蓄積パケット数が５になるまで、ＲＴＰ受信バッファＢＦからパケットは読み出されず、無音再生が行われる。
【０１３４】
そして、ＲＴＰ受信バッファＢＦの蓄積パケット数が５になると、受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦに蓄積されているパケットは、先頭から順次読み出されて音声データの送出がなされる。こうして、発生した揺らぎの量に合わせて、開始蓄積パケット数が変更されるので、パケットが破棄されることによる音切れが防止される。
【０１３５】
次に、大きな揺らぎが発生した場合におけるＲＴＰ受信バッファのバッファサイズの変更制御（増加制御）について、図１２を参照して説明する。図１２の例は、開始蓄積パケット数が３、最大蓄積パケット数が５である場合において、大きな揺らぎが発生した場合である。
【０１３６】
図１２において、揺らぎが発生するまでは、受信割り込み周期のタイミングで、順次、ＲＴＰ受信バッファＢＦの蓄積パケットの先頭のパケットが読み出されると共に、受信パケットが蓄積される。
【０１３７】
この状態で揺らぎが発生すると、前述と同様にして、受信パケットが到着しないにも関わらず、受信割り込み周期のタイミングで、ＲＴＰ受信バッファに蓄積されているパケットは、先頭から順次、読み出されるので、ＲＴＰ受信バッファＢＦ内の蓄積パケット数は、徐々に減ってゆく。
【０１３８】
そして、ＲＴＰ受信バッファＢＦ内の蓄積パケット数がゼロになると、前述と同様に、開始蓄積パケット数Ｂは、増加目標蓄積パケット数に増加変更される。これに伴い、最大蓄積パケット数Ｃも増加変更される。図１２の例では、開始蓄積パケット数は「４」に、最大蓄積パケット数は「６」にそれぞれ変更される。
【０１３９】
この図１２の例では、このように開始蓄積パケット数の増加変更を行った後においても、揺らぎ量が大きいため、さらにパケットの到着が遅れる。そして、到着が遅れていた複数個のパケットと共に、図１２に示すように、最大蓄積パケット数を越える新たなパケットがまとめて到着する。
【０１４０】
すると、前述したように、予め定められている溢れバッファ破棄数のパケット、この例では、２パケットが、ＲＴＰ受信バッファＢＦの先頭から順次破棄される。すると、蓄積パケット数は５になるので、最大蓄積パケット数「６」以内に収まる。そして、受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦに蓄積されているパケットは、先頭から読み出されて再生される。
【０１４１】
図１２の例では、以上の処理により、ＲＴＰ受信バッファＢＦ内の蓄積パケット数は、開始蓄積パケット数になるので、その後は、揺らぎがなければ、先頭からのパケットの読み出しと、到着パケットの蓄積が行われる。
【０１４２】
次に、揺らぎが停止してゆくときのＲＴＰ受信バッファのバッファサイズの変更制御（増加制御）について、図１３を参照して説明する。図１３の例は、開始蓄積パケット数Ｂが５に増加していて、このため、最大蓄積パケット数Ｃが７である場合において、揺らぎが収束して停止してゆく場合である。
【０１４３】
すなわち、図１３に示すように、揺らぎが発生している間は、開始蓄積パケット数Ｂは「５」とされて、揺らぎ吸収処理が行われるが、揺らぎが停止して収束してゆくと、前述した収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したと判定する。このときには、前述したように、開始蓄積パケット数Ｂを減少目的蓄積量に減少変更し、減少させたパケット数分をＲＴＰ受信バッファＢＦの先頭から破棄する。
【０１４４】
さらに、揺らぎが収束してゆくと、収束期間カウント値ＣＮＴが、再び、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したと判定する。そして、開始蓄積パケット数Ｂを減少目的蓄積量に減少変更し、減少させたパケット数分をＲＴＰ受信バッファＢＦの先頭から破棄する。
【０１４５】
以上の処理を繰り返すことにより、揺らぎがなくなる方向に収束するにつれて、開始蓄積パケット数Ｂは、初期値にまで減少させられる。
【０１４６】
以上のようにして、この実施形態によれば、揺らぎの発生に合わせて、ＲＴＰ受信バッファの開始蓄積パケット数を増加し、揺らぎが停止して減少収束するにつれて、開始蓄積パケット数を減少させるようにするので、ＲＴＰ受信バッファサイズは揺らぎ量に合わせて動的に制御され、音切れが軽減されると共に、音の遅延も最小限に抑えられるものである。
【０１４７】
なお、上述の実施形態においては、ＲＴＰ受信バッファが空になったら、開始蓄積パケット数を増加目標蓄積量に変更するようにしたが、空ではなく、ＲＴＰ受信バッファの蓄積パケット数が所定数以下、例えば１個以下になったときに、開始蓄積パケット数を増加目標蓄積量に変更するようにしてもよい。
【０１４８】
なお、この発明は、ＬＡＮを通じてリアルタイム再生が必要なデータを伝送する際において、ＬＡＮ上で発生する揺らぎについて適用可能であるので、上述の実施形態で説明したＶｏＩＰ電話システムにのみ適用される場合のみに、この発明が限られるものではないことは言うまでもない。
【０１４９】
また、この発明が適用されるリアルタイム伝送が必要なデータは、音声データに限られるものではなく、映像データ、その他のデータであってもよい。
【０１５０】
【発明の効果】
以上説明したように、この発明によれば、ＬＡＮ上で発生する揺らぎ量に動的にバッファサイズを変更制御することができるので、良品質のリアルタイムデータ伝送が可能になる。伝送データが、例えば音声の場合であれば、音切れや、音声遅延を軽減することができる。
【図面の簡単な説明】
【図１】この発明の適用例としてのＶｏＩＰ電話システムの構成例を示す図である。
【図２】図１の例のＶｏＩＰ電話システムを構成するゲートキーパーの構成例を示すブロック図である。
【図３】図１の例のＶＯＩＰ電話システムを構成する電話端末の構成例を示すブロック図である。
【図４】図１の例のＶＯＩＰ電話システムを構成するゲートウエイの構成例を示すブロック図である。
【図５】この発明の実施の形態における揺らぎ吸収バッファの構成を説明するための図である。
【図６】この発明の実施の形態における揺らぎ吸収バッファの制御装置の構成を説明するためのブロック図である。
【図７】この発明の実施の形態における揺らぎ吸収バッファの制御方法の一部を説明するためのフローチャートである。
【図８】この発明の実施の形態における揺らぎ吸収バッファの制御方法を説明するためのフローチャートの一部である。
【図９】この発明の実施の形態における揺らぎ吸収バッファの制御方法を説明するためのフローチャートの一部である。
【図１０】この発明の実施の形態における揺らぎ吸収バッファからのデータ送出処理を説明するためのフローチャートである。
【図１１】この発明の実施の形態が適用された揺らぎ吸収バッファにおける蓄積パケットの変化およびバッファサイズの変更制御を説明するための図である。
【図１２】この発明の実施の形態が適用された揺らぎ吸収バッファにおける蓄積パケットの変化およびバッファサイズの変更制御を説明するための図である。
【図１３】この発明の実施の形態が適用された揺らぎ吸収バッファにおける蓄積パケットの変化およびバッファサイズの変更制御を説明するための図である。
【符号の説明】
１ ゲートキーパー
２ 電話端末
３ ＩＰネットワークを構成するＬＡＮ
４ ゲートウエイ
２１０，４１０ ＣＰＵ
２２１、４１７ 揺らぎ吸収バッファを構成するＲＴＰ受信バッファ
【発明の属する技術分野】
この発明は、例えば、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話システムにおける音声パケットの授受の際に適用して好適な揺らぎ吸収バッファの制御方法および制御装置に関する。
【０００２】
【従来の技術】
インターネットやイントラネットのようなＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを利用して音声信号を送る技術であるＶｏＩＰを用いて電話通信を行うようにするＶｏＩＰ電話システムが提供されている。このＶｏＩＰ電話システムは、例えば、一般のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）用の規格であるＩＴＵ‐Ｔ勧告Ｈ.３２３が用いられて構成される。
【０００３】
この場合、通話音声信号は所定時間長分毎にパケット化されてＬＡＮ上を順次に伝送されるもので、そのためのトランスポート層のプロトコルとしてはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が用いられる。このＲＴＰにおいては、送信側では、ＲＴＰヘッダの中にパケットの順序番号（シーケンス番号）やタイムスタンプ（時刻情報）を付けてパケットを送信し、受信側では、前記順序番号やタイムスタンプを基に、再生の同期をとることにより、実時間動作をすることができる。
【０００４】
ところで、ＶｏＩＰ端末間での通話品質劣化の要因として、ＬＡＮからの受信ＲＴＰパケット到着時間間隔の遅延、すなわち、揺らぎが挙げられる。この揺らぎの問題については、従来から対策が施されており、通常、受信開始時に、一定数のパケットを揺らぎ吸収バッファに蓄積して、音声の再生を遅れさせることにより、揺らぎの吸収を行っている。
【０００５】
揺らぎ吸収バッファのバッファサイズは、開始蓄積パケット数と、最大蓄積パケット数とにより決定される。開始蓄積パケット数は、ＲＴＰパケット受信開始時に、揺らぎ吸収バッファからのパケットの読み出しを遅らせて、音声再生開始を待たせる受信パケット数である。
【０００６】
すなわち、ＲＴＰパケット受信開始時には、揺らぎ吸収バッファに、開始蓄積パケット数の受信パケットが蓄積されるまで、揺らぎ吸収バッファからパケットデータは読み出さず、揺らぎ吸収バッファに開始蓄積パケット数の受信パケットが蓄積されたときには、次の受信パケットの到来のときに、蓄積している受信パケットの先頭のパケットを読み出すようにする。
【０００７】
最大蓄積パケット数は、揺らぎ吸収バッファに蓄積可能な最大パケット数であり、音声再生の遅延の最大値に対応する。揺らぎ吸収バッファの蓄積パケット数が、この最大蓄積パケット数を越えた場合には、開始蓄積パケット数分のパケットをバッファ内に残して、それ以外の蓄積パケットを破棄するようにする。これにより、音声再生の遅延を最大蓄積パケット数の範囲内に押さえるようにしている。
【０００８】
従来、開始蓄積パケット数と最大蓄積パケット数の値、したがって、揺らぎ吸収バッファのバッファサイズは、使用環境に応じて設定された固定値とされていた。
【０００９】
【発明が解決しようとする課題】
ところで、揺らぎ吸収バッファのバッファサイズを決定するに当たって、開始蓄積パケット数は、揺らぎ収束状態における揺らぎ量より大きい値に設定されることが望ましく、また、最大蓄積パケット数は、最大の揺らぎ量より大きい値であるように設定されることが望ましい。これらの値が適切に設定されると、揺らぎ吸収バッファにより、揺らぎが確実に吸収されて、良好な通話品質が得られる。
【００１０】
しかしながら、端末の実装環境毎に発生する前記揺らぎの量は、パケット伝達経路のトラフィック状況により随時変化するため、事前にそれを的確に把握して、開始蓄積パケット数や最大蓄積パケット数を適切に設定することは、一般に、非常に難しく、実際の揺らぎよりも揺らぎ吸収バッファのバッファサイズが小さすぎたり、大きすぎたりすることが多々ある。
【００１１】
発生する揺らぎに対して、揺らぎ吸収バッファのサイズが小さい場合には、揺らぎによりパケット受信間隔が遅延している間に、揺らぎ吸収バッファに蓄積されていたパケット分の音声データを再生しきってしまうため、再生音声の音切れの問題が発生する。
【００１２】
一方、発生する揺らぎに対して、揺らぎ吸収バッファのサイズが大きすぎる場合には、必要以上に音声再生が遅延してしまう問題がある。
【００１３】
以上は、音声データの場合であるが、音声データに限らず、リアルタイム再生が必要なデータを伝送する場合には、同様の問題が生じる。
【００１４】
この発明は、パケット伝達経路のトラフィック状況により随時変化する揺らぎの量に対応することができる揺らぎ吸収バッファの制御方法および装置を提供することを目的とする。
【００１５】
【課題を解決するための手段】
上記課題を解決するために、この発明による揺らぎ吸収バッファの制御方法は、
リアルタイムで再生されるべき情報が所定時間長分毎にパケット化されて順次に伝送されてくるパケットデータを、揺らぎ吸収バッファを通じて受信し、伝送系において発生する前記パケットデータの到着タイミングの揺らぎを、前記揺らぎ吸収バッファにより制御する方法であって、
受信開始時に、前記揺らぎ吸収バッファに、開始蓄積パケット数の受信パケットが蓄積されてから、前記揺らぎ吸収バッファからの前記受信パケットの読み出しを開始し、前記揺らぎ吸収バッファに蓄積される受信パケット数が最大蓄積パケット数を越えた時には、所定数の受信パケットを破棄するようにする揺らぎ吸収バッファの制御方法において、
前記受信したパケットについて、前記開始蓄積パケット数よりも大きな前記揺らぎが発生した場合に、前記開始蓄積パケット数および前記最大蓄積パケット数を増加変更する開始蓄積量増加工程と、
前記揺らぎ量が、そのときの前記開始蓄積パケット数より低い値で安定している場合に、前記開始蓄積パケット数および前記最大蓄積パケット数を、そのときの値よりも少ない値に変更する開始蓄積量減少工程と、
を備えることを特徴とする。
【００１６】
【作用】
上述の構成のこの発明によれば、開始蓄積量増加工程において、開始蓄積パケット数よりも大きな揺らぎが発生した場合には、開始蓄積パケット数および最大蓄積パケット数が増加変更される。
【００１７】
そして、開始蓄積パケット数および最大蓄積パケット数が増加変更された後、揺らぎ量が、前記変更された開始蓄積パケット数より低い値で安定するようになった場合には、開始蓄積量減少工程において、そのときの開始蓄積パケット数および最大蓄積パケット数が、より少ない値に変更される。
【００１８】
したがって、この発明によれば、パケット伝達経路のトラフィック状況により随時変化する揺らぎの量に、揺らぎ吸収バッファのバッファサイズを動的に対応することができ、例えばパケットデータが音声データである場合に、音切れの問題を軽減することができる。また、必要以上に音声再生が遅延してしまう問題をも、回避することができる。
【００１９】
【発明の実施の形態】
以下、この発明による揺らぎ吸収バッファの制御方法の実施形態を、ＶｏＩＰ電話システムにおける音声パケットの伝送に適用した場合を例にとって、図を参照しながら説明する。
【００２０】
図１は、この実施形態におけるＶｏＩＰ電話システムの全体の概要を示すブロック図である。この例のＶｏＩＰ電話システムは、ゲートキーパー１と、電話端末（Ｈ．３２３端末）２の複数個と、ＬＡＮ３と、ＶｏＩＰゲートウエイ４とによって構成される。
【００２１】
電話端末２は、コンピュータの機能を備えると共に、ハンドセット２Ｈを備えている。そして、複数個の電話端末２のそれぞれは、ＩＰネットワークを構成するＬＡＮ３に接続され、このＬＡＮ３を通じてゲートキーパー１に接続されている。
【００２２】
ＶｏＩＰゲートウエイ４は、複数回線分の電話回線６を介して、電話網５と接続されると共に、ＬＡＮ３に接続される。電話回線６は、例えばＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）回線、専用回線などを含む。このゲートウエイ４は、電話網５とＩＰネットワークとを接続するための機能を備える中継管理装置の役割を果たすもので、連続音声信号とＩＰ音声パケットの相互変換や、ＩＰ音声パケットのゲートキーパー１とのやり取り、さらに、電話番号とＩＰアドレスとの相互変換を行う。
【００２３】
この場合、ＬＡＮ３は、ＩＴＵ−Ｔ勧告Ｈ．３２３の規格によるＩＰネットワークの構成とされている。
【００２４】
ゲートキーパー１は、ＩＴＵ−Ｔ勧告Ｈ．３２３のシステム構成の中で中心的な管理機能を担当するもので、例えばパーソナルコンピュータで構成される。複数の電話端末２のそれぞれは、ＬＡＮ３に接続されたときに、ゲートキーパー１に登録される。
【００２５】
ゲートキーパー１は、システム内のゲートウエイ４や複数の電話端末２の交換管理、帯域幅の割り当て、電話番号とＩＰアドレスの対応付けなどを行い、これに登録された複数個の電話端末による複数の電話回線６を利用した電話通信を管理する機能を有する交換管理装置の役割を果たす。
【００２６】
［ゲートキーパー１のハードウエア構成例］
この実施の形態のシステムにおけるゲートキーパー１のハードウエア構成例を図２に示す。この実施の形態のゲートキーパー１は、例えばパーソナルコンピュータにより構成されるもので、ＣＰＵ１１０に対して、システムバス１１１を介してＲＯＭ１１２と、ＲＡＭ１１３と、ＬＡＮインターフェイス１１４と、パケット処理部１１５と、ネットワーク管理メモリ１１６とが接続されている。
【００２７】
ＲＯＭ１１２には、電話番号情報とＩＰアドレスとの変換の処理プログラムなど、ゲートキーパー１が実行する処理プログラムが記憶されている。
【００２８】
ＲＡＭ１１３は、主としてＲＯＭ１１２のプログラムがＣＰＵ１１０によって実行される際にワークエリアとして使用される。
【００２９】
また、ＬＡＮインターフェイス１１４は、ＬＡＮ３を通じて送られてくるパケット化データを取り込み、また、ＬＡＮ３にパケット化データを送出するための機能を備える。
【００３０】
パケット処理部１１５は、ＬＡＮインターフェイス１１４により取り込んだパケットが、制御データのパケットであった場合には、その制御データを解読するために、受信したパケットを分解し、また、送信する制御データのパケット化データを生成する機能を有する。
【００３１】
なお、音声データのパケットの場合には、一般的には、ゲートキーパー１を介さずに、ゲートウエイ４と電話端末２との間でやり取りする。ただし、ゲートキーパー１を介して音声データのパケットの転送を行う場合もあり、その場合には、ゲートキーパー１は、ゲートウエイ４からのパケットは電話端末２に宛てて、電話端末２からのパケットはゲートウエイ４または他の電話端末２に宛てて、その音声パケットを転送するようにする。
【００３２】
そして、パケット処理部１１５は、パケット化データを分解／生成したり、転送処理のために一時保存したりするためのバッファメモリを備える。
【００３３】
ネットワーク管理メモリ１１６は、ネットワーク内に存在するゲートウエイ４や複数の電話端末２の登録情報やそれらのＩＰアドレスおよび、電話端末２のＩＰアドレスと電話番号との対応などの情報を記憶している。ＣＰＵ１１０は、それらの情報を用いて、パケットの行き先のＩＰアドレスを決定したり、受信先のＩＰアドレスを判別したりする。
【００３４】
［電話端末２のハードウエア構成例］
この実施形態のシステムにおける電話端末２は、図３に示すようなハードウエア構成例を示すものである。この実施形態の電話端末２は、端末本体２００と、ハンドセット２Ｈとからなる。ハンドセット２Ｈは、図示を省略したが、送話器を構成するマイクロホンと、送話アンプと、受話器を構成するスピーカと、受話アンプとを備えている。
【００３５】
端末本体２００は、コンピュータにより構成されており、ＣＰＵ２１０に対して、システムバス２１１を介してＲＯＭ２１２と、ＲＡＭ２１３と、ディスプレイコントローラ２１４と、操作入力インターフェイス（図ではインターフェイスはＩ／Ｆと記載する。以下同じ）２１６と、ＬＡＮインターフェイス２１８と、パケット分解／生成部２１９と、音声データ入出力インターフェイス２２０と、揺らぎ吸収バッファを構成するＲＴＰ受信バッファ２２１と、ＲＴＰ送信バッファ２２２とが接続されている。
【００３６】
ディスプレイコントローラ２１４には、ディスプレイ２１５が接続されており、このディスプレイ２１５の表示画面には、ＣＰＵ２１０の制御にしたがった表示が行われる。
【００３７】
また、操作入力インターフェイス２１６には、テンキー、カーソルキー、その他の操作キーを含む操作入力部２１７が接続されている。ＣＰＵ２１０は、操作入力インターフェイス２１６を介して操作入力部２１７を通じて使用者がいずれの入力キーを操作したかを認識し、その認識結果に基づいて、キー入力操作に応じた処理をＲＯＭ２１２のプログラムに従って実行する。
【００３８】
ＲＯＭ２１２には、電話端末２をゲートキーパー１に登録する際の処理シーケンスを実行するためのプログラムや揺らぎ吸収バッファを構成するＲＴＰ受信バッファ２２１のバッファサイズを、ＬＡＮ３上で実際に発生する揺らぎに動的に対応して制御するためのプログラムなどが記憶されている。
【００３９】
ＲＡＭ２１３は、主としてＲＯＭ２１２のプログラムがＣＰＵ２１０によって実行される際にワークエリアとして使用される。
【００４０】
ＬＡＮインターフェイス２１８は、ＬＡＮ３を通じて送られてくるパケット化データを取り込んでＲＴＰ受信バッファ２２１に順次に蓄積し、また、ＲＴＰ送信バッファ２２２に蓄積されている音声データの送信パケットを、ＬＡＮ３の空きを確認しながら、ＬＡＮ３に順次に送出する機能を備える。
【００４１】
パケット分解／生成部２１９は、ＬＡＮインターフェイス２１８により取り込まれ、ＲＴＰ受信バッファ２２１から読み出されたパケット化データを分解して、制御データや音声データを得る機能と、送信する制御データや所定時間分毎の音声データをパケット化したパケット化データを生成し、ＲＴＰ送信バッファ２２２に転送する機能を有する。このパケット分解／生成部２１９は、パケット化データを分解したり、生成したりするためのバッファメモリを備える。
【００４２】
なお、このパケット分解／生成部２１９のパケット分解処理機能や生成処理機能は、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）により構成されるが、ＣＰＵ２１０と、ＲＯＭ２１２とにより、ソフトウエアとして実現することもできる。
【００４３】
音声データ入出力インターフェイス２２０は、パケット分解されて得られた音声データをアナログ音声信号に変換してハンドセット２Ｈに供給し、また、ハンドセット２Ｈから入力されるアナログ音声信号をデジタル信号に変換して取り込む機能を備える。
【００４４】
［ゲートウエイ４のハードウエア構成例］
この実施の形態のシステムにおけるゲートウエイ４のハードウエア構成例を図４に示す。この実施の形態のゲートウエイ４は、例えばパーソナルコンピュータにより構成されるもので、ＣＰＵ４１０に対して、システムバス４１１を介してＲＯＭ４１２と、ＲＡＭ４１３と、ＬＡＮインターフェイス４１４と、パケット処理部４１５と、揺らぎ吸収バッファを構成するＲＴＰ受信バッファ４１７と、ＲＴＰ送信バッファ４１８とが接続されている。
【００４５】
ＲＴＰ受信バッファ４１７とＲＴＰ送信バッファ４１８とは、図４では、一つずつ示したが、実際には、複数本の電話回線６のそれぞれの電話回線に対して、一つずつ設けられるものである。
【００４６】
ＲＯＭ４１２には、電話端末２からの音声パケットのデータを、ＲＴＰ受信バッファ４１７を介して受け取り、電話回線６を通じて電話網５に送出するデータに変換するためのプログラム、また、逆に電話網５から取得したデータをＬＡＮ３を通じて電話端末２に送出するパケット化データに変換するためのプログラムや、揺らぎ吸収バッファを構成するＲＴＰ受信バッファ４１７のバッファサイズを、ＬＡＮ３上で実際に発生する揺らぎに動的に対応して制御するためのプログラムなどが記憶されている。
【００４７】
ＲＡＭ４１３は、主としてＲＯＭ４１２のプログラムがＣＰＵ４１０によって実行される際にワークエリアとして使用される。
【００４８】
また、ＬＡＮインターフェイス４１４は、ＬＡＮ３を通じて送られてくるパケット化データを取り込み、また、ＬＡＮ３にパケット化データを送出するための機能を備える。
【００４９】
パケット処理部４１５は、ＬＡＮインターフェイス４１４により取り込んだパケットを分解して、電話網５を伝送する形式のデータに変換し、また、電話網５から受信したデータをパケット化して、ＬＡＮインターフェイス４１４を通じてＬＡＮ３に送出するパケット化データを生成する機能を有する。
【００５０】
［揺らぎ吸収バッファの制御方法の実施形態の説明］
この実施形態の揺らぎ吸収バッファの制御方法は、電話端末のＲＴＰ受信バッファ２２１、また、ゲートウエイ４のＲＴＰ受信バッファ４１７の、いずれの制御にも適用される。この実施の形態においては、揺らぎ吸収バッファとしてのＲＴＰ受信バッファ２２１または４１７のバッファサイズを、ＬＡＮ３において実際に発生する揺らぎに応じて動的（ダイナミック）に変更制御するものである。
【００５１】
この実施形態のバッファサイズの制御方法を説明する前に、揺らぎ吸収バッファのバッファサイズを決定するためのパラメータの定義を、図５を参照して説明する。この図５は、揺らぎ吸収バッファとしてのＲＴＰ受信バッファ２２１または４１７のバッファサイズを決定するためのイメージを説明するためのものである。
【００５２】
初期再生パケット数は、ＲＴＰ受信バッファから読み出すパケット数であり、固定値であって、この例では、初期再生パケット数＝１とされている。
【００５３】
開始蓄積パケット数は、前述したように、パケット受信開始時に、ＲＴＰ受信バッファからのパケットの読み出しを遅らせて、音声再生開始を待たせる受信パケット数である。前述したように、この開始蓄積パケット数は従来は固定値であったが、この実施形態では、後述するようにＬＡＮ３に発生する揺らぎ量に応じて動的に変化する。以下に説明する例では、開始蓄積パケット数の初期値は、開始蓄積パケット数の初期値＝４とされている。
【００５４】
次に、最大蓄積パケット数は、前述したように、揺らぎ吸収バッファであるＲＴＰ受信バッファに蓄積可能な最大パケット数であり、ＲＴＰ受信バッファに最大蓄積パケット数以上のパケットが蓄積されたときには、前述したように、開始蓄積パケット数分のパケットをＲＴＰ受信バッファ内に残して、それ以外の蓄積パケットを破棄する。このときに破棄するパケット数を、溢れバッファ破棄数と呼び、この例では、溢れバッファ破棄数＝２とされる。
【００５５】
この最大蓄積パケット数は、
最大蓄積パケット数＝開始蓄積パケット数＋溢れバッファ破棄数
と定義できるもので、音声再生の遅延の最大値に対応する。この実施形態では、上記の定義から、開始蓄積パケット数が動的変化値であるので、これも動的変化値である。
【００５６】
次に、最大開始蓄積パケット数は、動的変化値である開始蓄積パケット数の最大値（上限）であり、固定値である。
【００５７】
ＲＴＰ受信バッファは、図５に示すように、最大開始蓄積パケット数以上のメモリセル（１つのパケットの蓄積メモリ部をこの明細書ではセルと呼ぶ）を備え、メモリアクセス上、最後のメモリセルの次には最初のメモリセルに戻るようにされたリング状のバッファ構成とされている。
【００５８】
そして、ＲＴＰ受信バッファから読み出すパケット位置（メモリセル）は参照インデックスにより指定される。参照インデックスのメモリセルにパケットが蓄積されていないとき、または、ＲＴＰ受信バッファに開始蓄積パケット数が蓄積されていないときには、パケットは読み出さずに、無音再生を行う。このときは、参照インデックスはインクリメントしない。
【００５９】
そして、開始蓄積パケット数分のパケットがＲＴＰ受信バッファに蓄積されていて、参照インデックスのセルのパケットの読み出しをしたときには、参照インデックスをインクリメントする。
【００６０】
また、ＣＰＵ２１０またはＣＰＵ４１０は、ＲＴＰ受信バッファ２２１または４１７の各メモリセルに蓄積されているパケットのシーケンス番号を保持して管理している。シーケンス番号は、パケットのＲＴＰヘッダに含まれており、パケットの受信時にＲＴＰヘッダを解析して取得する。
【００６１】
そして、検索開始インデックスが、
検索開始インデックス＝参照インデックス＋初期再生パケット数
として定義されている。ＣＰＵ２１０またはＣＰＵ４１０は、パケットを受信したとき、受信したパケットのＲＴＰヘッダからシーケンス番号を抽出して検知し、検索開始インデックスのメモリセルから、各メモリセルに格納されているパケットのシーケンス番号を検索し、受信パケットを格納するメモリセルを決定する。
【００６２】
図６は、揺らぎ吸収バッファの制御装置５００の機能ブロック図である。この図６の揺らぎ吸収バッファの制御装置５００は、電話端末２およびゲートウエイ４のいずれにも適用されるものであり、図３に示した電話端末２の端末本体２００のハードウエアおよび図４に示したゲートウエイ４のハードウエアから、揺らぎ吸収バッファとしてのＲＴＰ受信バッファ２２１，４１７の制御に関する部分を抽出したものに相当する。
【００６３】
ＬＡＮ３を通じて自分宛に送られてくるＲＴＰパケットは、データ受信部５０１（ＬＡＮインターフェイス２１８，４１４に対応）で受信され、揺らぎ吸収バッファ５０２（ＲＴＰ受信バッファ２２１または４１７に対応）に蓄積される。データ受信部５０１で受信されたＲＴＰパケットは、揺らぎ検出部５０３に供給されて、ＬＡＮ３において発生しているＲＴＰパケットについての揺らぎ量（単位は時間）が検出される。
【００６４】
ここで、揺らぎ量は、順次に受信される２つの受信ＲＴＰパケットの到着時間差と、パケットのＲＴＰヘッダに含まれるタイムスタンプの差よりパケット受信毎に算出される。
【００６５】
すなわち、シーケンス番号がｉのパケットＳｉのタイムスタンプをＴｉ、パケットＳｉの到着時間をＡｉ、パケットＳｉの受信時の揺らぎ量をＤｉとしたとき、
Ｄｉ＝（Ａｉ−Ａｉ−１）−（Ｔｉ−Ｔｉ−１） ・・・（式１）
により、揺らぎ量Ｄｉが算出される。
【００６６】
揺らぎ検出部５０３で検出された揺らぎ量Ｄｉは、バッファ制御部５０４に供給される。バッファ制御部５０４は、揺らぎ検出部５０３で検出された揺らぎ量Ｄｉに基づいて、後述するようにＲＴＰ受信バッファのバッファサイズの制御を行い、揺らぎ吸収処理を行いながら、揺らぎ吸収バッファ５０２から受信パケットを読み出し、データデコード処理部５０５に供給する。
【００６７】
データデコード処理部５０５は、受け取ったパケットを分解して音声データをデコードする。そして、データ送信部５０６に供給する。データ送信部５０６は、電話端末２の場合であれば、音声データをアナログ音声信号に変換してハンドセット２Ｈに送る。また、データ送信部５０６は、ゲートウエイ４の場合であれば、音声データを空き回線を通じて電話網５に送出する。
【００６８】
なお、揺らぎ検出部５０３およびバッファ制御部５０４の動作は、ＣＰＵ２１０または４１０により実行される。また、データデコード処理部５０５は、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）により構成される。データ送信部５０６は、音声データ入出力インターフェイス２２０または回線インターフェイス４１６により構成される。
【００６９】
［バッファ制御部５０４における開始蓄積量の制御動作］
この実施形態では、ＲＴＰ受信バッファの開始蓄積量（開始蓄積パケット数に対応）は、ＬＡＮ３上で発生する揺らぎ量に応じて動的に制御するが、この開始蓄積量の動的制御には、開始蓄積量の増加制御と、開始蓄積量の減少制御とがある。なお、この明細書において、蓄積量等における「量」は、時間の単位の値を示しており、蓄積パケット数等における「パケット数」は、前記「量」としての時間を、１パケット当たりの時間で割った値となるものである。
【００７０】
〔開始蓄積量の増加手順〕
まず、開始蓄積量の増加制御手順について説明する。
この実施の形態においては、開始蓄積量より大きな揺らぎが、連続して、または周期的に、ＬＡＮ３上に発生した場合、開始蓄積量を増やして、受信パケットを再蓄積するようにする。以下、その増加手順を説明する。
【００７１】
（１）増加目標蓄積量の算出
パケットを受信する毎に、揺らぎ量を検出し、検出した揺らぎ量の増減から、増加目標蓄積量を算出する。増加目標蓄積量は、開始蓄積量を増加させるときの目標値である。すなわち、増加目標蓄積量をＩＢｉとし、その初期値をＩＢｏ、揺らぎ量をＤｉとしたとき、以下のようにして、増加目標蓄積量ＩＢｉを求める。なお、サフィックスｉは、パケットのシーケンス番号に相当する。
【００７２】
ＩＢｏ＝開始蓄積量
ＩＢｉ＝ＩＢｉ−１＋ｆａ（Ｄｉ，ＩＢｉ−１）／ＣＩ ・・・（式２）
ただし、
Ｄｉ＞ＩＢｉ−１の場合
ｆａ（Ｄｉ，ＩＢｉ−１）＝Ｄｉ−ＩＢｉ−１
Ｄｉ≦ＩＢｉ−１の場合
ｆａ（Ｄｉ，ＩＢｉ−１）＝０
・・・（式３）
ここで、ＣＩは収束速度定数であり、ＣＩ≧１である。この収束速度定数ＣＩにより、局所的に発生した揺らぎの影響を抑え、連続的に発生する揺らぎ量を得ることができる。
【００７３】
（２）開始蓄積量の更新
揺らぎ遅延によりＲＴＰ受信バッファが空になったときに、開始蓄積量＝増加目標蓄積量として、開始蓄積量を増加目標蓄積量に置き換えて増加させる。そして、更新された開始蓄積量になるまで、ＲＴＰ受信バッファからのパケットの読み出しを停止して、ＲＴＰ受信バッファに受信パケットを再蓄積する。なお、増加目標蓄積量＞最大開始蓄積量のときには、増加目標蓄積量＝最大開始蓄積量とされて制限される。
【００７４】
以上のようにして、この実施の形態においては、揺らぎが連続的または周期的に発生する期間が十分に長ければ、揺らぎに対する蓄積量の不足分が増加目標蓄積量に累積されてゆき、増加目標蓄積量は適切な揺らぎ量（ＩＢｉ＞Ｄｉ）で収束してゆくので、その収束した増加目標蓄積量に開始蓄積量を置き換えることにより、発生する揺らぎ量に対応した揺らぎ吸収を行うことができる。
【００７５】
〔開始蓄積量の減少手順〕
次に、開始蓄積量の減少制御手順について説明する。
上述のようにして開始蓄積量を増加させた後、揺らぎがより小さい値に収束することがあるが、そのように揺らぎ量が小さくなった場合にも、開始蓄積量を、増加したままの値に保持していた場合には、ＲＴＰ受信バッファでの遅延（通話遅延）が大きくなる問題がある。
【００７６】
この実施形態では、揺らぎ量が、そのときの開始蓄積量よりも低い値で安定している場合には、通話遅延を減少させるために、適切な開始蓄積量にまで減少させるようにする。この実施の形態では、以下の手順で揺らぎが安定しているかどうかを判定し、適切な開始蓄積量の算出を行う。
【００７７】
（１）減少目標蓄積量の算出
パケットを受信する毎に、揺らぎ量を検出し、検出した揺らぎ量の増減から、開始蓄積量を減少させるときの目標値を求めるための減少目標蓄積量を算出する。すなわち、減少目標蓄積量をＤＢｉとし、その初期値をＤＢｏ、揺らぎ量をＤｉとし、増加目標蓄積量をＩＢｉとし、収束速度定数をＣＤとしたとき、以下のようにして、減少目標蓄積量ＤＢｉを求める。
【００７８】
ＤＢｏ＝０
Ｄｉ＞ＩＢｉ−１の場合
ＤＢｉ＝０
Ｄｉ≦ＩＢｉ−１の場合
ＤＢｉ＝ＤＢｉ−１＋ｆｂ（Ｄｉ，ＤＢｉ−１）／ＣＤ
・・・（式４）
ただし、
Ｄｉ＞ＤＢｉ−１の場合
ｆｂ（Ｄｉ，ＤＢｉ−１）＝Ｄｉ−ＤＢｉ−１
Ｄｉ≦ＤＢｉ−１の場合
ｆｂ（Ｄｉ，ＤＢｉ−１）＝０
・・・（式５）
ここで、収束速度定数ＣＤは、ＣＤ≧１である。
【００７９】
なお、式４において、減少目標蓄積量ＤＢｉの更新判定に、増加目標蓄積量ＩＢｉを用いるのは、前述の（式２），（式３）との同期のためである。
【００８０】
（２）揺らぎ安定の判定
揺らぎが安定したかどうかは、減少目標蓄積量が変化しない期間の長さ（パケット受信回数）で判定する。この実施形態では、収束期間カウント値ＣＮＴを、以下の手順で更新し、揺らぎ安定判定を行う。
【００８１】
すなわち、
Ｄｉ＞ＤＢｉ−１の場合
ＣＮＴ＝０
Ｄｉ≦ＤＢｉ−１の場合
ＣＮＴｉ＝ＣＮＴｉ−１＋１
・・・（式６）
とする。
【００８２】
そして、収束期間カウント値ＣＮＴが、予め定めた揺らぎ安定と認められるような収束期間カウント値である収束期間定数ＣＮＴ−ｔｈよりも大きくなったかどうかを検査し、収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなったときには、揺らぎが安定したと判定する。
【００８３】
なお、収束期間定数ＣＮＴ−ｔｈは、固定値でもよいし、また、受信パケットサイズにより変更するようにしてもよい。
【００８４】
（３）バッファ更新判定およびバッファ更新処理
収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したと判定したときには、ＲＴＰ受信バッファのバッファサイズを変更するかどうかのバッファ更新判定を行う。バッファ更新判定は、開始蓄積量と減少目標蓄積量との差が、予め定めた最小減少量よりも大きいかどうかにより行う。最小減少量は、例えば１パケット分の時間とされる。
【００８５】
バッファ更新判定の結果、開始蓄積量と減少目標蓄積量との差が、予め定めた最小減少量よりも小さい場合には、ＲＴＰ受信バッファサイズは、減少処理する必要がないとして、収束期間カウント値ＣＮＴや減少目標蓄積量はゼロリセットされる。
【００８６】
バッファ更新判定の結果、開始蓄積量と減少目標蓄積量との差が、予め定めた最小減少量よりも大きい場合には、バッファ更新処理を実行して、開始蓄積量＝減少目標蓄積量とし、開始蓄積量を減少目標蓄積量まで減少させる。ただし、１度のバッファ更新手順で減少させる開始蓄積量は、予めパラメータとして設定された最大減少量により制限する。そして、収束期間カウント値ＣＮＴや減少目標蓄積量はゼロリセットすると共に、減少した分のバッファ内パケットを破棄するようにする。
【００８７】
図７のフローチャートを参照して、以上のバッファ更新判定およびバッファ更新処理のルーチンを、さらに説明する。この図７の処理は、パケットを受信する毎に、電話端末２では、ＣＰＵ２１０により、ゲートウエイ４では、ＣＰＵ４１０により実行されるものである。
【００８８】
まず、収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したかどうかを判定する（ステップＳ１）。揺らぎが安定していないと判定したときには、このルーチンを抜けて他の処理ステップに進む。
【００８９】
また、揺らぎが安定したと判定したときには、その時点における開始蓄積量から減少目標蓄積量を減算して、その減算結果ΔＳを求める（ステップＳ２）。そして、その減算結果ΔＳが、予め設定された最小減少量よりも大きいかどうか判定する（ステップＳ３）。
【００９０】
ステップＳ３で、減算結果ΔＳが、予め設定された最小減少量よりも小さいと判定された場合には、収束期間カウント値ＣＮＴを「０」にし（ステップＳ４）、また、減少目標蓄積量を「０」にする（ステップＳ５）。
【００９１】
ステップＳ３で、減算結果ΔＳが、予め設定された最小減少量よりも大きいと判定されたときには、当該減算結果ΔＳは、予め設定された最大減少量以下であるか否か判別する（ステップＳ６）。
【００９２】
このステップＳ６において、減算結果ΔＳは、予め設定された最大減少量以下であると判別したときには、開始蓄積量＝減少目標蓄積量として、開始蓄積量を減少させる（ステップＳ７）。また、ステップＳ６において、減算結果ΔＳは、予め設定された最大減少量よりも大きいと判別したときには、開始蓄積量＝そのときの開始蓄積量−最大減少量として、開始蓄積量を、最大減少量分だけ減少させる（ステップＳ８）。
【００９３】
ステップＳ７およびステップＳ８の後は、ステップＳ９に進んで、増加目標蓄積量を、更新された開始蓄積量に置き換える。つまり、この時点から、増加目標蓄積量の初期値は、更新された開始蓄積量になる。
【００９４】
次に、収束期間カウント値ＣＮＴを「０」にし（ステップＳ１０）、また、減少目標蓄積量を「０」にする（ステップＳ１１）。さらに、開始蓄積量を減少させたことにより溢れる分のパケットデータを、ＲＴＰ受信バッファから破棄する（ステップ１２）。この場合の開始蓄積量の減少により破棄するパケット数は、最大蓄積パケット数を越えて溢れたときに破棄する溢れバッファ破棄数のような固定値ではなく、動的なものとなる。以上で、バッファ更新処理は終了となる。
【００９５】
［揺らぎ吸収バッファ制御の処理ルーチン］
次に、揺らぎ吸収バッファのバッファサイズの制御および読み出し処理動作の全体を、図８および図９のフローチャートを参照しながら説明する。
【００９６】
ＲＴＰパケットを受信すると、電話端末２では、ＣＰＵ２１０に、ゲートウエイ４ではＣＰＵ４１０に割り込みが発生して、図８および図９のフローチャートの処理ルーチンを開始し、まず、ＲＴＰヘッダを解析する（ステップＳ２１）。次に、既にパケットの受信を開始しているかどうか判別する（ステップＳ２２）。
【００９７】
ステップＳ２２で、未だ、パケット受信開始状態になっておらず、受信したパケットが受信開始のパケットであると判別したときには、パケットサイズ、つまり、音声データサイズを、予め決定されているパラメータに基づいて取得する（ステップＳ２３）。
【００９８】
すなわち、この例においては、送信側は、音声信号を所定時間長分毎にパケット化して、ＬＡＮ３に送出するが、この場合のパケット化の際の所定時間長（音声データのサイズ）は、例えば１０ｍｓｅｃ、２０ｍｓｅｃ、３０ｍｓｅｃなどのいくつかのサイズの中から、選択することができる。そして、どのサイズでパケット化されているかの情報（パラメータ）は、音声データの送受信の前に制御信号をやり取りすることにより決定されており、その情報（パラメータ）により、音声データサイズを取得する。
【００９９】
音声データサイズを取得したら、初期再生パケット数、開始蓄積パケット数の初期値、バッファ破棄数、最大開始蓄積パケット数等のバッファサイズ制御パラメータを算出する（ステップＳ２４）。この例では、開始蓄積量の初期値、バッファ破棄量、最大開始蓄積量は、時間単位で定められており、１パケット当たりの時間長である音声データサイズから、前記パラメータをパケット数単位に変換する。
【０１００】
例えば、開始蓄積量の初期値が３０ｍｓｅｃ、バッファ破棄量が２０ｍｓｅｃ、最大開始蓄積量が１０００ｍｓｅｃに設定されており、音声データサイズが、１０ｍｓｅｃ／パケットであったときには、開始蓄積パケット数の初期値は「３」、バッファ破棄数は「２」、最大開始蓄積パケット数は「１００」となる。
【０１０１】
以上のパラメータの算出が終了したら、ＲＴＰ受信バッファを受信開始状態にし、ステップＳ２３で取得した音声データサイズに合わせて、図６のデータデコード処理部５０５の制御側からの受信割り込み周期を設定する（ステップＳ２５）。そして、前記受信割り込み周期は、データデコード処理部５０５が制御側から受信する割り込みに関するものであり、この割り込みは、ＬＡＮ３側の音声データの受信で発生するものではない。
【０１０２】
電話端末２あるいはゲートウエイ４は、この受信割り込み周期で、ＲＴＰ受信バッファからパケットの取り出しを行って、後述する音声送出処理を行う。
【０１０３】
次に、受信開始状態にしたら、到着したパケットについての揺らぎ量の算出を行う。また、ステップＳ２２で既に受信開始状態であると判別したときには、即座に、到着したパケットについての揺らぎ量の算出を行う（ステップＳ２６）。
このステップＳ２６における揺らぎ量の算出は、前述した（式１）によって行われる。
【０１０４】
次に、算出した揺らぎ量に基づき、前述の（式２）、（式３）に基づき増加目標蓄積量ＩＢｉの算出を行うと共に、前述の（式４）、（式５）に基づき減少目標蓄積量ＤＢｉの算出を行う（ステップＳ２７）。
【０１０５】
次に、ＲＴＰ受信バッファ内の蓄積パケット数が、初期再生パケット数より小さいかどうか判定する（ステップＳ２８）。
【０１０６】
ＲＴＰ受信バッファ内の蓄積パケット数が、初期再生パケット数より小さいときには、再生するパケットがバッファ内にないため、ＲＴＰ受信バッファからのパケットの読み出し時に用いるバッファ参照フラグを「ＦＡＬＳＥ」にして、バッファ参照を禁止させ、無音生成を指示する（ステップＳ２９）。
【０１０７】
次に、開始蓄積量を、そのときの増加目標蓄積量とする（ステップＳ３０）。
ただし、増加目標蓄積量が最大開始蓄積量よりも大きいとき（増加目標蓄積量＞最大開始蓄積量）には、開始蓄積量＝最大開始蓄積量に制限される。前述したように、増加目標蓄積量の初期値は、開始蓄積量の初期値である。
【０１０８】
このステップＳ３０においては、パケットの受信を開始したときには、前回のパケット受信時における揺らぎ量に応じたＲＴＰ受信バッファサイズとなるように、開始蓄積量が設定される。また、パケットの受信を開始している状態においては、ＲＴＰ受信バッファ内の蓄積パケット数が、初期再生パケット数より小さいということは、揺らぎによる遅延のために、ＲＴＰ受信バッファ内のパケットが空になったことを意味するため、開始蓄積量がそのときの増加目標蓄積量に増加変更される。
【０１０９】
次に、ＲＴＰ受信バッファサイズを、
ＲＴＰ受信バッファサイズ＝開始蓄積パケット数
として算出する（ステップＳ３１）。また、最大蓄積パケット数を、
最大蓄積パケット数＝ＲＴＰ受信バッファサイズ＋溢れ時のバッファ破棄数
として算出する（ステップＳ３２）。次に、次回受信したときに、受信パケットをＲＴＰ受信バッファのいずれのメモリセルに蓄積するかを検索する際の開始インデックス（インデックスは、ＲＴＰ受信バッファのメモリセルを指し示す指標である）である検索開始インデックスを、ＲＴＰ受信バッファの先頭にセットする（ステップＳ３３）。その後、ＲＴＰ受信バッファへの受信パケット蓄積処理に進む（ステップＳ３５）。
【０１１０】
また、ステップ２８で、蓄積パケット数が初期再生パケット数以上であると判別したときには、検索開始インデックスを、
検索開始インデックス＝参照インデックス＋初期再生パケット数
とする（ステップ３４）。その後、ステップＳ３５の受信パケット蓄積処理に進む。
【０１１１】
ステップ３５の受信パケット蓄積処理においては、前述したように、検索開始インデックスで指し示されるメモリセルから順に、ＲＴＰ受信バッファの各メモリセルに蓄積されているパケットのシーケンス番号を検索して、今回受信したパケットを格納すべきセルを検出し、検出されたセルに、受信パケットを格納する。
【０１１２】
以上のようにして、ＲＴＰ受信バッファ内に受信パケットを蓄積したら、蓄積パケット数を１だけインクリメントする（図９のステップＳ４１）。
【０１１３】
次に、揺らぎが、収束したか否か判別する（ステップＳ４２）。そして、揺らぎが収束したと判別したときには、前述した開始蓄積量の減少手順を実行する（ステップＳ４３）。ステップＳ４２の処理は、図７のステップＳ１の処理に対応し、また、ステップＳ４３の処理は、図７のステップＳ２〜ステップＳ１２に処理に対応する。
【０１１４】
ステップＳ４３での開始蓄積量の減少手順が終了した後と、ステップＳ４２で、減少目標蓄積量が収束していないと判別したときには、ＲＴＰ受信バッファの蓄積パケット数が、最大蓄積パケット数以上であるか否か判別する（ステップ４４）。そして、蓄積パケット数が最大蓄積パケット数以上であると判別したときには、ＲＴＰ受信バッファの先頭から、ステップＳ２４で定められた溢れ時のバッファ破棄数分のパケットを、ＲＴＰ受信バッファから破棄する（ステップＳ４５）。
【０１１５】
ステップＳ４４で、蓄積パケット数が最大蓄積パケット数よりも少ないと判別されたとき、また、ステップ４５でのパケットの破棄処理が終了した後には、蓄積パケット数が、ＲＴＰ受信バッファサイズ以上であるか否か判別する（ステップＳ４６）。
【０１１６】
ステップＳ４６で、蓄積パケット数が、ＲＴＰ受信バッファサイズ以上であると判別したときには、参照インデックスを、ＲＴＰ受信バッファの先頭のセル番号とし（ステップＳ４７）、検索開始インデックスは、
検索開始インデックス＝参照インデックス＋初期再生パケット数
とした後（ステップＳ４８）、バッファ参照フラグを「ＴＲＵＥ」として、音声データ送出処理手順において、バッファ参照を許可し、音声データ再生開始を指示する（ステップＳ４９）。
【０１１７】
その後、このパケット受信時の処理ルーチンを終了する。また、ステップＳ４６で、蓄積パケット数が、ＲＴＰ受信バッファサイズ以上ではないと判別したときにも、このパケット受信時の処理ルーチンを終了する。
【０１１８】
［音声データ送出処理］
次に、図８および図９の受信処理に併せて行われる音声データ送出処理を、図１０のフローチャートを参照しながら説明する。これは、ゲートウエイ４の場合であり、前述の図６の機能ブロック図におけるＤＳＰで構成されたデータデコード処理部５０５における処理である。この図６のデータデコード処理部５０５における処理は、前述したようにして設定された割り込み周期で起動される。前述したように、この例では、この割り込み周期は、音声パケットサイズに合わせたものとされている。なお、割り込み周期は、音声パケットサイズと一致させなくても勿論よい。
【０１１９】
まず、出力する音声チャンネルを選択する（ステップＳ５１）。例えば、音声チャンネル１は、ＩＳＤＮ回線、音声チャンネル２は、アナログ回線とされる。電話端末２の場合であれば、このステップＳ５１の処理は不要である。
【０１２０】
次に、ＲＴＰ受信バッファを検索する（ステップＳ５２）。そして、バッファ参照フラグが「ＴＲＵＥ」であるか「ＦＡＬＳＥ」であるか判別する（ステップＳ５３）。バッファ参照フラグが「ＦＡＬＳＥ」であった場合には、再生すべき音声データがないとして、無音再生処理を行う（ステップＳ５４）。
【０１２１】
バッファ参照フラグが「ＴＲＵＥ」であった場合には、参照インデックスで示されるＲＴＰ受信バッファのセルから音声パケットを読み出すようにし（ステップＳ５５）、音声データが存在するか否か判別する（ステップＳ５６）。
【０１２２】
ステップＳ５６で、音声データがあると判別したときには、音声データを再生し（ステップＳ５７）、ＲＴＰ受信バッファの蓄積パケット数をデクリメントする（ステップＳ５８）。そして、参照インデックスをインクリメントして（ステップＳ５９）、この音声データ送出処理ルーチンを終了する。
【０１２３】
ステップＳ５６で、音声データがないと判別したときには、蓄積パケットがＲＴＰ受信バッファ内にあるか否か判別し（ステップＳ６０）、蓄積パケットがあると判別されたときには、参照インデックスをインクリメントし（ステップＳ６１）、その後、再生音声データなしとして無音再生する（ステップ６２）。また、ステップＳ６０で、蓄積パケットがないと判別したときには、即座にステップＳ６２に進み、無音再生する。
【０１２４】
［ＲＴＰ受信バッファ内のパケット数の変化の具体例］
次に、図１１〜図１３を参照して、パケット到着時のＲＴＰ受信バッファ内のパケット数の変化の具体例について説明する。図１１〜図１３の各図において、ＢＦはＲＴＰ受信バッファを模式的に示し、網掛けを付して示したメモリセルは、パケットが蓄積されていることを示しており、当該蓄積パケットの中に示した数字はシーケンス番号を示している。また、白抜き部分のセルは、空きを示している。
【０１２５】
以下に説明する例では、初期再生パケット数＝１、開始蓄積量の初期パケット数＝３、最大蓄積パケット数の初期値＝５、最大開始蓄積パケット数＝１０とした場合である。開始蓄積パケット数と、最大蓄積パケット数は動的に変化する。
【０１２６】
なお、図１１〜図１３の各図において、Ａ〜Ｄは、Ａ＝開始蓄積量の初期パケット数、Ｂ＝開始蓄積パケット数（動的変化）、Ｃ＝最大蓄積パケット数（動的変化）、Ｄ＝最大開始蓄積パケット数であり、各図において、上方に示したこれらＡ〜Ｄのうち、ＢおよびＣの値は、その初期値を示している。また、図１１〜図１３において、網掛けを付して示したものは、蓄積パケットを示しており、当該蓄積パケットの中に示した数字はシーケンス番号を示している。
【０１２７】
図１１は、パケットの受信開始からの処理と、揺らぎ発生による開始蓄積量および最大蓄積パケット数の変更および揺らぎ吸収処理を示すものである。この図１１では、発生した揺らぎは、パケットを破棄しなければならないほど大きいものではなかった場合である。
【０１２８】
最初のパケットを受信すると、前述したように、音声データサイズ（パケットサイズ）が認識され、バッファサイズ制御パラメータの算出がなされて、受信開始状態とされ、以後、音声データサイズ（パケットサイズ）に基づいて設定された受信割り込み周期で、後述するような音声データ送出処理がなされる。そして、到着したパケットがＲＴＰ受信バッファＢＦに蓄積される。
【０１２９】
そして、パケット受信開始から、ＲＴＰ受信バッファＢＦに３個のパケットが蓄積されるまでは、ＲＴＰ受信バッファＢＦからパケットは読み出されず、無音再生が行われる。
【０１３０】
４個目のパケットが到着すると、それが蓄積されると共に、前述した受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦの先頭のパケットが読み出されて、音声データの送出がなされる。以後は、受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦに蓄積されているパケットは、先頭から順次読み出されて音声データ送出される。したがって、揺らぎが発生しなければ、図１１の例においては、ＲＴＰ受信バッファＢＦには、常に３個のパケットが蓄積される状態になる。
【０１３１】
ここで、遅延揺らぎが発生すると、受信パケットが到着しないにも関わらず、受信割り込み周期のタイミングで、ＲＴＰ受信バッファに蓄積されているパケットは、先頭から順次、読み出されるので、新パケットが到着しない限り、ＲＴＰ受信バッファＢＦ内の蓄積パケット数は、徐々に減ってゆく。
【０１３２】
そして、ＲＴＰ受信バッファＢＦ内の蓄積パケット数がゼロになると、前述したように、開始蓄積パケット数Ｂは、増加目標蓄積パケット数に増加変更される。これに伴い、最大蓄積パケット数Ｃも増加変更される。図１０の例では、開始蓄積パケット数は「５」に、最大蓄積パケット数は「７」にそれぞれ変更される。
【０１３３】
その後、揺らぎの発生により遅れた３周期分と合わせて４個のパケットが到着すると、それがＲＴＰ受信バッファＢＦに蓄積される。この時点では、変更された開始蓄積パケット数「５」には満たないので、ＲＴＰ受信バッファＢＦからパケットは読み出されず、無音再生が行われる。そして、次にパケットが到着してＲＴＰ受信バッファＢＦの蓄積パケット数が５になるまで、ＲＴＰ受信バッファＢＦからパケットは読み出されず、無音再生が行われる。
【０１３４】
そして、ＲＴＰ受信バッファＢＦの蓄積パケット数が５になると、受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦに蓄積されているパケットは、先頭から順次読み出されて音声データの送出がなされる。こうして、発生した揺らぎの量に合わせて、開始蓄積パケット数が変更されるので、パケットが破棄されることによる音切れが防止される。
【０１３５】
次に、大きな揺らぎが発生した場合におけるＲＴＰ受信バッファのバッファサイズの変更制御（増加制御）について、図１２を参照して説明する。図１２の例は、開始蓄積パケット数が３、最大蓄積パケット数が５である場合において、大きな揺らぎが発生した場合である。
【０１３６】
図１２において、揺らぎが発生するまでは、受信割り込み周期のタイミングで、順次、ＲＴＰ受信バッファＢＦの蓄積パケットの先頭のパケットが読み出されると共に、受信パケットが蓄積される。
【０１３７】
この状態で揺らぎが発生すると、前述と同様にして、受信パケットが到着しないにも関わらず、受信割り込み周期のタイミングで、ＲＴＰ受信バッファに蓄積されているパケットは、先頭から順次、読み出されるので、ＲＴＰ受信バッファＢＦ内の蓄積パケット数は、徐々に減ってゆく。
【０１３８】
そして、ＲＴＰ受信バッファＢＦ内の蓄積パケット数がゼロになると、前述と同様に、開始蓄積パケット数Ｂは、増加目標蓄積パケット数に増加変更される。これに伴い、最大蓄積パケット数Ｃも増加変更される。図１２の例では、開始蓄積パケット数は「４」に、最大蓄積パケット数は「６」にそれぞれ変更される。
【０１３９】
この図１２の例では、このように開始蓄積パケット数の増加変更を行った後においても、揺らぎ量が大きいため、さらにパケットの到着が遅れる。そして、到着が遅れていた複数個のパケットと共に、図１２に示すように、最大蓄積パケット数を越える新たなパケットがまとめて到着する。
【０１４０】
すると、前述したように、予め定められている溢れバッファ破棄数のパケット、この例では、２パケットが、ＲＴＰ受信バッファＢＦの先頭から順次破棄される。すると、蓄積パケット数は５になるので、最大蓄積パケット数「６」以内に収まる。そして、受信割り込み周期のタイミングで、ＲＴＰ受信バッファＢＦに蓄積されているパケットは、先頭から読み出されて再生される。
【０１４１】
図１２の例では、以上の処理により、ＲＴＰ受信バッファＢＦ内の蓄積パケット数は、開始蓄積パケット数になるので、その後は、揺らぎがなければ、先頭からのパケットの読み出しと、到着パケットの蓄積が行われる。
【０１４２】
次に、揺らぎが停止してゆくときのＲＴＰ受信バッファのバッファサイズの変更制御（増加制御）について、図１３を参照して説明する。図１３の例は、開始蓄積パケット数Ｂが５に増加していて、このため、最大蓄積パケット数Ｃが７である場合において、揺らぎが収束して停止してゆく場合である。
【０１４３】
すなわち、図１３に示すように、揺らぎが発生している間は、開始蓄積パケット数Ｂは「５」とされて、揺らぎ吸収処理が行われるが、揺らぎが停止して収束してゆくと、前述した収束期間カウント値ＣＮＴが、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したと判定する。このときには、前述したように、開始蓄積パケット数Ｂを減少目的蓄積量に減少変更し、減少させたパケット数分をＲＴＰ受信バッファＢＦの先頭から破棄する。
【０１４４】
さらに、揺らぎが収束してゆくと、収束期間カウント値ＣＮＴが、再び、収束期間定数ＣＮＴ−ｔｈよりも大きくなって、揺らぎが安定したと判定する。そして、開始蓄積パケット数Ｂを減少目的蓄積量に減少変更し、減少させたパケット数分をＲＴＰ受信バッファＢＦの先頭から破棄する。
【０１４５】
以上の処理を繰り返すことにより、揺らぎがなくなる方向に収束するにつれて、開始蓄積パケット数Ｂは、初期値にまで減少させられる。
【０１４６】
以上のようにして、この実施形態によれば、揺らぎの発生に合わせて、ＲＴＰ受信バッファの開始蓄積パケット数を増加し、揺らぎが停止して減少収束するにつれて、開始蓄積パケット数を減少させるようにするので、ＲＴＰ受信バッファサイズは揺らぎ量に合わせて動的に制御され、音切れが軽減されると共に、音の遅延も最小限に抑えられるものである。
【０１４７】
なお、上述の実施形態においては、ＲＴＰ受信バッファが空になったら、開始蓄積パケット数を増加目標蓄積量に変更するようにしたが、空ではなく、ＲＴＰ受信バッファの蓄積パケット数が所定数以下、例えば１個以下になったときに、開始蓄積パケット数を増加目標蓄積量に変更するようにしてもよい。
【０１４８】
なお、この発明は、ＬＡＮを通じてリアルタイム再生が必要なデータを伝送する際において、ＬＡＮ上で発生する揺らぎについて適用可能であるので、上述の実施形態で説明したＶｏＩＰ電話システムにのみ適用される場合のみに、この発明が限られるものではないことは言うまでもない。
【０１４９】
また、この発明が適用されるリアルタイム伝送が必要なデータは、音声データに限られるものではなく、映像データ、その他のデータであってもよい。
【０１５０】
【発明の効果】
以上説明したように、この発明によれば、ＬＡＮ上で発生する揺らぎ量に動的にバッファサイズを変更制御することができるので、良品質のリアルタイムデータ伝送が可能になる。伝送データが、例えば音声の場合であれば、音切れや、音声遅延を軽減することができる。
【図面の簡単な説明】
【図１】この発明の適用例としてのＶｏＩＰ電話システムの構成例を示す図である。
【図２】図１の例のＶｏＩＰ電話システムを構成するゲートキーパーの構成例を示すブロック図である。
【図３】図１の例のＶＯＩＰ電話システムを構成する電話端末の構成例を示すブロック図である。
【図４】図１の例のＶＯＩＰ電話システムを構成するゲートウエイの構成例を示すブロック図である。
【図５】この発明の実施の形態における揺らぎ吸収バッファの構成を説明するための図である。
【図６】この発明の実施の形態における揺らぎ吸収バッファの制御装置の構成を説明するためのブロック図である。
【図７】この発明の実施の形態における揺らぎ吸収バッファの制御方法の一部を説明するためのフローチャートである。
【図８】この発明の実施の形態における揺らぎ吸収バッファの制御方法を説明するためのフローチャートの一部である。
【図９】この発明の実施の形態における揺らぎ吸収バッファの制御方法を説明するためのフローチャートの一部である。
【図１０】この発明の実施の形態における揺らぎ吸収バッファからのデータ送出処理を説明するためのフローチャートである。
【図１１】この発明の実施の形態が適用された揺らぎ吸収バッファにおける蓄積パケットの変化およびバッファサイズの変更制御を説明するための図である。
【図１２】この発明の実施の形態が適用された揺らぎ吸収バッファにおける蓄積パケットの変化およびバッファサイズの変更制御を説明するための図である。
【図１３】この発明の実施の形態が適用された揺らぎ吸収バッファにおける蓄積パケットの変化およびバッファサイズの変更制御を説明するための図である。
【符号の説明】
１ ゲートキーパー
２ 電話端末
３ ＩＰネットワークを構成するＬＡＮ
４ ゲートウエイ
２１０，４１０ ＣＰＵ
２２１、４１７ 揺らぎ吸収バッファを構成するＲＴＰ受信バッファ
Claims (9)
- リアルタイムで再生されるべき情報が所定時間長分毎にパケット化されて順次に伝送されてくるパケットデータを、揺らぎ吸収バッファを通じて受信し、伝送系において発生する前記パケットデータの到着タイミングの揺らぎを、前記揺らぎ吸収バッファにより制御する方法であって、
受信開始時に、前記揺らぎ吸収バッファに、開始蓄積パケット数の受信パケットが蓄積されてから、前記揺らぎ吸収バッファからの前記受信パケットの読み出しを開始し、前記揺らぎ吸収バッファに蓄積される受信パケット数が最大蓄積パケット数を越えた時には、所定数の受信パケットを破棄するようにする揺らぎ吸収バッファの制御方法において、
前記受信したパケットについて、前記開始蓄積パケット数よりも大きな前記揺らぎが発生した場合に、前記開始蓄積パケット数および前記最大蓄積パケット数を増加変更する開始蓄積量増加工程と、
前記揺らぎ量が、そのときの前記開始蓄積パケット数より低い値で安定している場合に、前記開始蓄積パケット数および前記最大蓄積パケット数を、そのときの値よりも少ない値に変更する開始蓄積量減少工程と、
を備えることを特徴とする揺らぎ吸収バッファの制御方法。 - 請求項１に記載の吸収バッファの制御方法において、
前記パケットを受信する毎に、揺らぎ量を算出する揺らぎ算出工程を備えると共に、
前記開始蓄積量増加工程は、
前記揺らぎ吸収バッファに蓄積されているパケット数が、そのときの前記開始蓄積パケット数よりも少ない予め定められたパケット数以下になるまで、前記揺らぎ算出工程で算出したパケット受信毎の揺らぎ量の増減に基づき、そのときの前記開始蓄積パケット数を初期値とした増加目標蓄積量を累積演算する工程と、
前記揺らぎ吸収バッファに蓄積されているパケット数が、前記開始蓄積パケット数よりも少ない予め定められたパケット数以下になったとき、前記開始蓄積パケット数を前記累積演算した前記増加目標蓄積量に変更すると共に、前記揺らぎ吸収バッファからの読み出しを停止して、前記揺らぎ吸収バッファに受信パケットを再蓄積するようにする工程と
を備えることを特徴とする揺らぎ吸収バッファの制御方法。 - 請求項２に記載の揺らぎ吸収バッファの制御方法において、
前記増加目標蓄積量が、予め定められている最大開始蓄積パケット数よりも大きいときには、前記開始蓄積パケット数は、前記増加目標蓄積量に代えて前記最大開始パケット数に変更する
ことを特徴とする揺らぎ吸収バッファの制御方法。 - 請求項１に記載の吸収バッファの制御方法において、
前記パケットを受信する毎に、揺らぎ量を算出する揺らぎ算出工程を備えると共に、
前記開始蓄積量減少工程は、
前記算出工程で算出したパケット受信毎の揺らぎ量の増減に基づき、ゼロを初期値とした減少目標蓄積量を累積演算する工程と、
前記揺らぎ量が安定していると判定され、かつ、そのときの前記開始蓄積パケット数から前記減少目標蓄積量を減算した値が、予め設定された最小減少量よりも大きいときに、前記開始蓄積パケット数を、前記減少目標蓄積量に変更すると共に、前記揺らぎ吸収バッファに蓄積されている変更後の前記開始蓄積パケット数よりも余分のパケットを破棄するようにする工程と
を備えることを特徴とする揺らぎ吸収バッファの制御方法。 - 請求項４に記載の吸収バッファの制御方法において、
前記そのときの前記開始蓄積パケット数から前記減少目標蓄積量を減算した値が、前記最小減少量よりも大きく、かつ、予め定められた最大減少量よりも大きいときには、前記開始蓄積パケット数を、前記減少目標蓄積量に代えて前記最大減少量に変更する
ことを特徴する揺らぎ吸収バッファの制御方法。 - リアルタイムで再生されるべき情報が所定時間長分毎にパケット化されて順次に伝送されてくるパケットデータを、揺らぎ吸収バッファを通じて受信し、伝送系において発生する前記パケットデータの到着タイミングの揺らぎを、前記揺らぎ吸収バッファにより制御する装置であって、
受信開始時に、前記揺らぎ吸収バッファに、開始蓄積パケット数の受信パケットが蓄積されてから、前記揺らぎ吸収バッファからの前記受信パケットの読み出しを開始し、前記揺らぎ吸収バッファに蓄積される受信パケット数が最大蓄積パケット数を越えた時には、所定数の受信パケットを破棄するようにする揺らぎ吸収バッファの制御装置において、
前記パケットを受信する毎に、揺らぎ量を算出する揺らぎ算出手段と、
前記揺らぎ吸収バッファに蓄積されているパケット数が、前記開始蓄積パケット数よりも少ない予め定められたパケット数以下になるまで、前記揺らぎ算出手段で算出したパケット受信毎の揺らぎ量の増減に基づき、前記開始蓄積パケット数を初期値とした増加目標蓄積量を累積演算する手段と、
前記揺らぎ吸収バッファに蓄積されているパケット数が、前記開始蓄積パケット数よりも少ない予め定められたパケット数以下になったとき、前記開始蓄積パケット数を前記累積演算した前記増加目標蓄積量に変更すると共に、前記揺らぎ吸収バッファからの読み出しを停止して、前記揺らぎ吸収バッファに受信パケットを再蓄積するようにする手段と、
を備えることを特徴とする揺らぎ吸収バッファの制御装置。 - 請求項６に記載の揺らぎ吸収バッファの制御装置において、
前記増加目標蓄積量が、予め定められている最大開始蓄積パケット数よりも大きいときには、前記開始蓄積パケット数は、前記増加目標蓄積量に代えて前記最大開始パケット数に変更する
ことを特徴とする揺らぎ吸収バッファの制御装置。 - 請求項６に記載の吸収バッファの制御装置において、
前記揺らぎ算出手段で算出したパケット受信毎の揺らぎ量の増減に基づき、ゼロを初期値とした減少目標蓄積量を累積演算する手段と、
前記揺らぎ量が、そのときの開始蓄積パケット数よりも低い値で安定していると判定され、かつ、そのときの前記開始蓄積パケット数から前記減少目標蓄積量を減算した値が、予め設定された最小減少量よりも大きいときに、前記開始蓄積パケット数を、前記減少目標蓄積量に変更すると共に、前記揺らぎ吸収バッファに蓄積されている変更後の前記開始蓄積パケット数よりも余分のパケットを破棄するようにする手段と
を備えることを特徴とする揺らぎ吸収バッファの制御装置。 - 請求項８に記載の吸収バッファの制御装置において、
前記そのときの前記開始蓄積パケット数から前記減少目標蓄積量を減算した値が、前記最小減少量よりも大きく、かつ、予め定められた最大減少量よりも大きいときには、前記開始蓄積パケット数を、前記減少目標蓄積量に代えて前記最大減少量に変更する
ことを特徴する揺らぎ吸収バッファの制御装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003111166A JP3874112B2 (ja) | 2002-05-13 | 2003-04-16 | 揺らぎ吸収バッファの制御方法および制御装置 |
| US10/428,986 US20030210681A1 (en) | 2002-05-13 | 2003-05-05 | Method and apparatus for controlling delay fluctuation absorption buffer |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002136835 | 2002-05-13 | ||
| JP2003111166A JP3874112B2 (ja) | 2002-05-13 | 2003-04-16 | 揺らぎ吸収バッファの制御方法および制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004048680A JP2004048680A (ja) | 2004-02-12 |
| JP3874112B2 true JP3874112B2 (ja) | 2007-01-31 |
Family
ID=29405333
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003111166A Expired - Fee Related JP3874112B2 (ja) | 2002-05-13 | 2003-04-16 | 揺らぎ吸収バッファの制御方法および制御装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20030210681A1 (ja) |
| JP (1) | JP3874112B2 (ja) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1320805C (zh) * | 2003-09-17 | 2007-06-06 | 上海贝尔阿尔卡特股份有限公司 | 一种分组交换网络自适应抖动缓冲区调整方法 |
| JP4667811B2 (ja) * | 2004-09-28 | 2011-04-13 | 京セラ株式会社 | 音声通信装置、音声通信方法 |
| DE102005012664A1 (de) * | 2005-03-18 | 2006-09-21 | Siemens Ag | Verfahren und Anordnung zur Übertragung von Datenpaketen |
| US7489702B2 (en) * | 2005-03-31 | 2009-02-10 | Alcatel-Lucent Usa Inc. | Method and apparatus for increasing radio frequency efficiency for mixed voice over internet protocol and data traffic |
| US7593393B2 (en) * | 2006-01-20 | 2009-09-22 | Sbc Knowledge Ventures, L.P. | Voice over internet protocol multi-routing with packet interleaving |
| JP2007323345A (ja) * | 2006-05-31 | 2007-12-13 | Toshiba Corp | 入出力処理装置及び同入出力処理装置を有するコンピュータシステム |
| KR100864824B1 (ko) * | 2006-09-22 | 2008-10-23 | 한국전자통신연구원 | ＮＰＳＳ（Ｎｕｍｂｅｒ ＰｏｒｔａｂｉｌｉｔｙＳｕｐｐｏｒｔｉｎｇ Ｓｙｓｔｅｍ）를 갖춘 동종 또는이종 전화망 간 번호 이동성 호 처리 장치 및 그 구현 방법 |
| JP4758334B2 (ja) * | 2006-12-26 | 2011-08-24 | 株式会社富士通エフサス | 通信端末装置及び通信制御方法 |
| JP4684247B2 (ja) * | 2007-01-29 | 2011-05-18 | 京セラ株式会社 | 音声通信方法、音声通信装置 |
| US8339944B2 (en) * | 2007-11-05 | 2012-12-25 | Qualcomm Incorporated | SDU discard mechanisms for wireless communication systems |
| JP4629126B2 (ja) * | 2008-05-08 | 2011-02-09 | 三菱電機株式会社 | メッセージ中継装置 |
| DE102011082741A1 (de) * | 2011-09-15 | 2013-03-21 | Rohde & Schwarz Gmbh & Co Kg | Verschlüsselung basierend auf Netzwerkinformationen |
| US8689233B2 (en) * | 2012-01-25 | 2014-04-01 | International Business Machines Corporation | Distributed function execution for hybrid systems |
| US8902777B1 (en) * | 2012-06-29 | 2014-12-02 | Juniper Networks, Inc. | Methods and apparatus for self-tuning aggregation of data units |
| JP2014192710A (ja) * | 2013-03-27 | 2014-10-06 | Oki Electric Ind Co Ltd | 音声通信品質測定システム、音声通信品質測定方法、音声通信品質測定装置、音声通信品質測定プログラム、音声通信品質要求装置及び音声通信品質要求プログラム |
| JP5517381B1 (ja) * | 2013-09-30 | 2014-06-11 | レゾネッツ合同会社 | 揺らぎ吸収装置、通信装置、及び制御プログラム |
| US9961022B1 (en) * | 2015-12-28 | 2018-05-01 | Amazon Technologies, Inc. | Burst absorption for processing network packets |
| JP7000988B2 (ja) * | 2018-05-21 | 2022-01-19 | 富士通株式会社 | パケット転送装置及びパケット転送方法 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| IT1230235B (it) * | 1989-06-07 | 1991-10-18 | Telettra Spa | Strutturazione e trasmissione a pacchetti dell'informazione generata da codificatore per segnali video. |
| JP3362695B2 (ja) * | 1999-03-31 | 2003-01-07 | 日本電気株式会社 | 遅延揺らぎ吸収装置及び吸収方法 |
| JP4510251B2 (ja) * | 2000-08-10 | 2010-07-21 | 富士通株式会社 | パケットゆらぎ吸収方法及びその装置 |
-
2003
- 2003-04-16 JP JP2003111166A patent/JP3874112B2/ja not_active Expired - Fee Related
- 2003-05-05 US US10/428,986 patent/US20030210681A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20030210681A1 (en) | 2003-11-13 |
| JP2004048680A (ja) | 2004-02-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3874112B2 (ja) | 揺らぎ吸収バッファの制御方法および制御装置 | |
| KR100501324B1 (ko) | 음성 품질 예측값을 이용한 보이스 오버 인터넷프로토콜에서의 콜 라우팅 방법 | |
| US6977942B2 (en) | Method and a device for timing the processing of data packets | |
| US8842534B2 (en) | Method and system for managing time-sensitive packetized data streams at a receiver | |
| JP5174182B2 (ja) | 再生遅延推定 | |
| US8160030B2 (en) | Data rate controller | |
| JP2005269632A (ja) | 通信端末装置、電話データ受信方法、通信システムおよびゲートウェイ | |
| US20050180405A1 (en) | Sub-packet insertion for packet loss compensation in voice over IP networks | |
| JP4744444B2 (ja) | ストリームデータ受信再生装置、通信システムおよびストリームデータ受信再生方法 | |
| US6456967B1 (en) | Method for assembling a voice data frame | |
| US7346005B1 (en) | Adaptive playout of digital packet audio with packet format independent jitter removal | |
| US7058568B1 (en) | Voice quality improvement for voip connections on low loss network | |
| JP2002077245A (ja) | Ｉｐゲートウェイ装置 | |
| US7295547B2 (en) | Audio gateway device | |
| US7542465B2 (en) | Optimization of decoder instance memory consumed by the jitter control module | |
| JP4232030B2 (ja) | 音声パケットの揺らぎ吸収制御方法 | |
| US20050169245A1 (en) | Arrangement and a method for handling an audio signal | |
| JP2005080036A (ja) | ストリーミング情報の送信装置および送信方法 | |
| JP2005252429A (ja) | Ｉｐパケット化装置 | |
| JP2005269134A (ja) | 構内交換機 | |
| JP2005266411A (ja) | 音声圧縮方法および電話器 | |
| US7839893B2 (en) | Voice data transmitting and receiving system | |
| US6526108B1 (en) | Method for buffering the jitter processing of vocoder | |
| GB2356537A (en) | Silence suppression/insertion buffer management | |
| JP2008167223A (ja) | 通信品質制御方法及びパケット通信システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20040621 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20040621 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041001 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060407 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060707 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060901 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061004 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061017 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3874112 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101102 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111102 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121102 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131102 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |