JP2004535115A - Ip電話技術のための動的待ち時間管理 - Google Patents

Ip電話技術のための動的待ち時間管理 Download PDF

Info

Publication number
JP2004535115A
JP2004535115A JP2003504614A JP2003504614A JP2004535115A JP 2004535115 A JP2004535115 A JP 2004535115A JP 2003504614 A JP2003504614 A JP 2003504614A JP 2003504614 A JP2003504614 A JP 2003504614A JP 2004535115 A JP2004535115 A JP 2004535115A
Authority
JP
Japan
Prior art keywords
samples
queue
data block
variability
remaining
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.)
Pending
Application number
JP2003504614A
Other languages
English (en)
Inventor
カール エル デニンホッフ
Original Assignee
テレシム インコーポレイテッド
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by テレシム インコーポレイテッド filed Critical テレシム インコーポレイテッド
Publication of JP2004535115A publication Critical patent/JP2004535115A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416Real-time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1083In-session procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28Timers or timing mechanisms used in protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer

Abstract

【課題】ボイス・オーバー・インターネット・プロトコル(VoIP)電話技術における待ち時間を低減するための管理技術の方法を提供する。
【解決手段】「リアルタイムプロトコル」とは独立に通信ネットワーク上の待ち時間を動的に低減する方法。本方法は、次のデータブロックの処理の完了を判断して、次のデータブロックの消費装置(210)の待ち行列に残っているサンプル数を判断する段階を含む。システム(200)の待ち時間を知ることなく、消費装置(210)の待ち行列に残っているサンプル数に基づいて変動性の判断が行われる。次に、この変動性に基づいて、消費装置(210)の待ち行列の残りのサンプル数を低減することができるか否かに関して判断が行われ、できる場合には消費装置(210)の待ち行列が低減される。
【選択図】図2

Description

【技術分野】
【0001】
本発明は、ボイス・オーバー・インターネット・プロトコル(VoIP)電話技術の待ち時間(Latency)に関し、更に詳しくは、「VoIP」電話技術における待ち時間を低減するための管理技術の方法に関する。
【背景技術】
【0002】
サウンドを電気信号に変え、それらを送信し、次にそれらをサウンドに変換して戻す科学を電話技術(すなわち、電話の科学)という。この用語は、多くの場合、従来的に電話機器によって行われた機能を実行するコンピュータハードウエア及びソフトウエアを示すために使用される。
インターネット電話技術とは、一般的に、公衆交換電話網(PSTN)ではなく、インターネットを通じて搬送される音声、ファックス、及び/又は、音声メッセージアプリケーションなどの通信サービスを意味する。インターネット電話通話の開始に関わる基本的な段階は、デジタルフォーマットへのアナログ音声信号の変換及びインターネット上の送信のためのインターネットプロトコル(IP)パケットへの信号の圧縮/変形である。この処理は、従来技術の図1に示すように、受信側でこの逆が行われる。
【0003】
「リアルタイム搬送プロトコル(RTP)」は、インターネット上の音声及び映像を対象とした搬送プロトコルとして広く受け入れられている。「RTP」により、タイムスタンプ、シーケンス付番、及びペイロード識別などのサービスが行われる。それはまた、とりわけ、ルースセッション制御、「QoS」報告、及びメディア同期化に使用される制御コンポーネントである「リアルタイム制御プロトコル(RTCP)」を含む。
【0004】
「RTP」自体は、データのリアルタイム配信を保証するものではないが、ストリーミングデータをサポートするための送受信用途のための機構となっている。一般的に、「RTP」は、ユーザ・データグラム・プロトコル(UDP)上で実行されるが、その仕様は、他の搬送プロトコルをサポートするほど一般的なものである。「RTP」は、送信者によって搬送された全ての情報にタイムスタンプでラベル付けをする。タイムスタンプを検査することにより、受信者は、パケットを元の順番に分類し、リアルタイムストリームを同期化し、及び/又は、音声又は映像データにおけるジッターを補正することができる。
【0005】
「RTCP」は、アプリケーションにネットワークの品質に関するステータスを与えるように考案されたものである。この情報で、データの送信に影響を及ぼすパラメータ、例えば、ジッター・バッファ・サイズを最適化することができる。「RTP」ヘッダは、16バイトを全オーバーヘッドに追加し、ヘッダ情報の「UDP」の追加の8バイトによって接頭辞が付けられる。
「IP」ヘッダは、サイズは20バイトであるが、データグラムを形成するように、従って、20バイトの音声又は映像を所要の64バイトデータグラムとして送信するように接頭辞が付される。データグラムは、データブロック、セグメント、チャンク、データパケット、又は、音声、映像、又は音声/映像のパケットであるように形成される。
【0006】
「RTP」ヘッダの不要なビットには、32ビットのタイムスタンプがある。このタイムスタンプは、特に、音パケットがシーケンス化されているために不要であり、また、特定数の音サンプルに変換されることから、本来の(ジッターがなかった場合の)到着までの時間を正確に計算することが可能である。タイムスタンプは、一部の実施例では、サンプルカウントと直接的に相関付けることが可能であり、そのように使用された場合、パケットが固定ペイロードを担持した場合にはパケットのシーケンス番号から直接計算可能であるから、この場合の値は、全く冗長なものである可能性がある。
【0007】
待ち時間は、データグラムを送信者から受信者に搬送する際の遅延であるが、変換速度に影響を及ぼすものである。人間は、感知できる影響を受けるまでに、約250ミリ秒(ms)の待ち時間に耐えることができる。
デジタルネットワーク上でネイティブアナログ形式で音声をサポートするために、アナログ信号は、WAN、LAN、インターネット、又は通信ネットワークに入るように生成された後、ある時点でデジタル形式に符号化(すなわち、変換)されなければならない。受信側では、デジタル信号は、人間の耳で理解できるようにアナログ形式に復号化(すなわち、再変換)されなければならず、従って、タイミングが極めて重要である。ネットワークは、全ての音声バイトを125ms毎に受理、切り替え、搬送、及び配信することができるべきである。それは、待ち時間(すなわち、遅延)が最小限のものでなければならず、また、ジッター(遅延における変動性)が実質的にゼロでなければならないことを意味する。
【0008】
リアルタイム音声会話は、遅延に敏感である。一方向の遅延が1秒の1/4である250ミリ秒(ms)を超えた状態で、会話の当事者は、一方の人が話し終えた時を判断するのが比較的困難になる。これにより、当事者が同時に話す確率が高くなる。
音声通話は、発信地のPBXから、ゲートウェイ、LAN、及びその場所のルータを通じて、「IP」ネットワークを通じて目的地のPBXに接続された電話へルーティングルーティングされる。音声を搬送するデータグラムに遅延が生じる可能性がある区域がいくつかある。アナログ音声通話は、PBXを通じて音声ゲートウェイにルーティングルーティングされているので、ゲートウェイによって使用される音声符号化アルゴリズムによってある程度の待ち時間が加わる。実際の遅延量は、使用された音声符号化装置の種類に基づく。小さな音声サンプルが符号化された状態で、それは、離れたゲートウェイまで送信されるようにデータグラム内にカプセル化されるべきである。このカプセル化処理には、データグラム、及びゲートウェイからLANを介したルータまでのデータグラムの流れを形成するために、適用可能な「UDP」及び「IP」ヘッダを追加する段階が含まれる。
これらの作業による全遅延は、発信地での処理間の時間、及び目的地での処理間の遅延を表す。
【0009】
データグラムが「IP」ネットワークに到着すると、それは、1つ又はそれ以上のルータを通じてネットワーク出口点にルーティングルーティングされることになる。このルーティングルーティングはまた、変動遅延を付加する。変動遅延の原因には、入口点から出口点までの経路におけるルータ数、各ルータの処理能力、及び各ルータに提供されるトラヒック負荷が含まれる。 これらの遅延は、音声搬送データグラムがローカルネットワークを通る時に発生し、広域「IP」ネットワークを通る時にデータグラムが遭遇する遅延の一因となっている。
【0010】
しかし、ストリーム内の送信パケット数が比較的少ない(ほとんどは「RTP」パケット)「RTCP」(リアルタイム制御プロトコル)は、「RTP」のタイムスタンプとリアルタイムクロックスタンプとの間の周期的相関を提供する。これにより、実際の待ち時間などの計算が可能になるが、送信者と受信者のリアルタイムクロックが同期化されていることを条件とするものである。リアルタイムクロックのこの同期化は、「ネットワーク時間プロトコル(NTP)」という別のプロトコルを通じた「RTP」仕様で想定されている。代替的に、一方向の待ち時間は、何らかの情報の往復時間の半分として判断される。それにも拘わらず、待ち時間が2つのネットワークノード間で極めて非対称である可能性があることから、これらのいずれも、一方向の待ち時間を効果的に確立するものにはなっていない。
【0011】
「RTP」情報のいずれもシステム内の待ち時間を効果的に低減するのに必要ないことから、待ち時間を最も効果的に最適化するためには、待ち時間が何であるかを実際に知る必要はない。ミリ秒、ホップ、又はマイルによる終点までの経路の長さは、待ち時間を最小限に抑えるという目的には無関係である。必要なことは、専らジッターバッファの長さを観察することによって得られた統計データに基づいて、受信側でのジッターバッファの長さを最小限に抑えることである。ジッターバッファの長さは、音の各データブロックの準備が整ってジッターバッファに挿入されるように準備された時に観察され、これには、受信側での音の解凍及びフォーマット化を含む待ち時間に寄与するものの全てが考慮される。
【発明の開示】
【発明が解決しようとする課題】
【0012】
必要とされるものは、「リアルタイムプロトコル」に依存しない待ち時間を低減する方法である。
更に必要とされるものは、データパケット送信時の一般管理費を低減する方法である。
更に必要とされるものは、データブロックの消費装置のバイアスを是正する方法である。
更に必要とされるものは、システムの実際の待ち時間を最小化する際のタイムクロックの不正確さ及び差異の影響を排除する方法である。
【課題を解決するための手段】
【0013】
本発明は、上述の状況を鑑みて為されたものであり、本発明の態様として、通信ネットワーク上の待ち時間を動的に低減する方法を有する。
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムである。
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができる。
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのソフトウエア製品として特徴付けることができる。
本発明の更なる態様は、通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる音声及び映像消費装置である。
本発明の別の態様は、音声/映像消費装置におけるバイアスを判断する方法として特徴付けることができる。
本発明の更なる態様及び利点は、一部は以下の説明で述べられ、一部はその説明から明白であり、又は、本発明の実行によって習得することができる。本発明の態様及び利点は、特に特許請求の範囲で指摘される要素及び組合せによって実現及び達成されることになる。
【0014】
上記及び他の利点を達成するために、及び、本発明の目的に従って、本発明は、それを具体化して広い意味で説明すると、1つの態様によれば、通信ネットワーク上の待ち時間を動的に低減する方法として特徴付けることができ、本方法は、次のデータブロックの処理の完了を判断する段階と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する段階とを含む。本方法は、消費装置の待ち行列に残っているサンプル数の変動性を判断する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合にはこの待ち行列を低減する段階とを更に含む。
【0015】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、次のデータブロックの処理の完了を判断する手段と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する手段とを含む。本システムは、消費装置の待ち行列に残っているサンプル数の変動性を判断する手段と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減する手段とを更に含む。
【0016】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、いつデータブロックが消費装置の待ち行列に追加される準備ができるかを識別する段階と、消費装置をポーリングして消費装置の前回のポーリングから消費装置によって消費されたサンプル数を計算する段階とを含む。本システムは、消費装置によって消費されたサンプル数の変動性を計算する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合は待ち行列を低減する段階とを更に含む。
【0017】
本発明の更なる態様は、次のデータブロックの処理の完了を判断し、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断するための命令を実行するようにプロセッサに指示することができ、コンピュータ読取可能媒体上にある、通信ネットワーク上の待ち時間を動的に低減するためのソフトウエア製品として特徴付けることができる。このソフトウエア製品は、更に、消費装置の待ち行列に残っているサンプル数の変動性を判断し、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減するようにプロセッサに指示する。
【0018】
本発明は、通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる、プロセッサを含む音声及び映像消費装置であって、このプロセッサは、プロセッサと通信し、かつプロセッサに制御されるメモリ及び周辺装置を含む。本装置は、データブロックの送信、受信、及び消費の少なくとも1つが可能である。本装置はまた、a)次のデータブロックの処理の完了を判断し、b)次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断し、c)消費装置の待ち行列に残っているサンプル数の変動性を判断し、d)変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断するための命令を実行するようにプロセッサに指示することができるソフトウエア製品を含む。
本発明の別の態様は、音声/映像消費装置におけるバイアスを判断する方法として特徴付けることができ、本方法は、複数の時間間隔の間に消費されたサンプル数を得るために消費装置をポーリングする段階と、消費されたサンプル数を消費装置の設定消費速度に基づいて複数の時間間隔の間に消費されたはずの計算サンプル数と比較する段階とを含む。
【0019】
待ち時間は、従来的にも電気通信分野で克服すべき困難な課題であった。待ち時間は、ネットワークシステム、及び、近リアルタイム結果を達成することが非常に重要であるボイス・オーバー・IP(VoIP)のような他の広帯域技術に有害な影響を与えかねない。本発明は、従来技術の解決策の以上列記した欠点を克服する「IP」電話技術の待ち時間を動的に管理するための解決策を提供する。
上述の一般的説明及び以下の詳細説明は、共に単に例示的かつ説明的であり、特許請求の範囲に示すような本発明を制限するものではないことは理解されるものとする。
本明細書に組み込まれ、かつその一部を成す添付図面は、本発明の幾つかの実施形態を示し、本説明と共に本発明の原理を説明する役目をするものである。
【発明を実施するための最良の形態】
【0020】
ここで、実施例が添付図面に示されている本発明の実施形態を詳細に参照する。同じ又は類似の部分(要素)を示すために、可能な限り、図面を通して同じ参照番号を使用する。
本発明によれば、本発明は、通信ネットワーク上の待ち時間を動的に低減する方法として特徴付けることができ、本方法は、次のデータブロックの処理の完了を判断する段階と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する段階とを含む。本方法は、消費装置の待ち行列に残っているサンプル数の変動性を判断する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合にはこの待ち行列を低減する段階とを更に含む。
【0021】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、次のデータブロックの処理の完了を判断する手段と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する手段とを含む。本システムは、消費装置の待ち行列に残っているサンプル数の変動性を判断する手段と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減する手段とを更に含む。
【0022】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、いつデータブロックが消費装置の待ち行列に追加される準備ができるかを識別する段階と、消費装置をポーリングして消費装置の前回のポーリングから消費装置によって消費されたサンプル数を計算する段階とを含む。本システムは、消費装置によって消費されたサンプル数の変動性を計算する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減する段階とを更に含む。
【0023】
本発明の更なる態様は、次のデータブロックの処理の完了を判断し、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断するための命令を実行するようにプロセッサに指示することができ、コンピュータ読取可能媒体上にある、通信ネットワークでの待ち時間を動的に低減するためのソフトウエア製品として特徴付けることができる。ソフトウエア製品は、更に、消費装置の待ち行列に残っているサンプル数の変動性を判断し、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減するようにプロセッサに指示する。
【0024】
本発明の別の態様は、通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる、プロセッサを含む音声及び映像消費装置として特徴付けることができ、このプロセッサは、プロセッサと通信し、かつプロセッサに制御されるメモリ及び周辺装置を含む。本装置は、データブロックの送信、受信、及び消費の少なくとも1つが可能である。本装置はまた、a)次のデータブロックの処理の完了を判断し、b)次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断し、c)消費装置の待ち行列に残っているサンプル数の変動性を判断し、d)変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断するための命令を実行するようにプロセッサに指示することができるソフトウエア製品を含む。
本発明の別の態様は、音声/映像消費装置におけるバイアスを判断する方法として特徴付けることができ、本方法は、複数の時間間隔の間に消費されたサンプル数を得るために消費装置をポーリングする段階と、消費されたサンプル数を消費装置の設定消費速度に基づいて複数の時間間隔の間に消費されたはずの計算サンプル数と比較する段階とを含む。
【0025】
図2は、有線及び無線「IP」電話技術に関する一般的なシステムアーキテクチャ200を示す。この環境は、音声又は映像を処理する様々な構成要素を備えた複数の個人用通信装置(PCD)210から成る。「PCD」210は、名目上はLAN「メディアアクセスカード(MAC)」である「IP」通信手段225と、名目上はIEEE802.11、「Bluetooth」、IR、又は類似の準拠規格である無線通信手段230と通信するメモリを有するCPU215を含む。通信手段には、LAN、インターネット、及び他の無線装置を挙げることができる。
【0026】
「PCD」210は、全てがCPU215と通信してCPU215によって制御される、音声又は映像インポート及びエクスポート用I/Oポート235、音声ジャック240、及び任意選択的に内部スピーカ及び/又はマイク245を更に含む。また、「PCD」210は、外部スピーカ及びマイク255を含むことができる。
対話式サウンド通信は、1つの「PCD」210のマイクから別の「PCD」210のスピーカまで、及びその逆の経路で行われる。各構成要素は、待ち時間に寄与する可能性がある。図1及び図2に示す物理的な構成要素に加えて、音声コーデック(符号器及び復号器)のような待ち時間の一因となり得るソフトウエア成分がある場合がある。
【0027】
一般的な作動において、「PCD」210は、「イーサネット」スイッチ又はハブ、又は類似の種類のネットワーク装置のようなLANスイッチングネットワーク260を通じて接続される。LAN260は、通常、標準的な「IP」自立型ルータ又はPC、又はルーティングルーティング用に構成された類似の装置のような「IP」ルーティングルーティング手段265に接続されている。「IP」ルーティングルーティング手段265は、「IP」ルーティングルーティング手段275と更に通信しているインターネット又は他の通信ネットワークのような通信スイッチングネットワーク手段と通信している。図2に示すように、「PCD」210は、プログラムがハードウエアに組み込まれている状態であるか、又は、RF接続を通じてLAN280又は無線アクセスポイント285及び290と接続することができる。
【0028】
「IP」電話技術においては幾つかの待ち時間発生源がある。発生源は、完全に終点装置内にあるものもあれば、終点装置の外部にあるものもある。本発明の1つの態様は、直接に終点装置の管理下にある発生源からの待ち時間の寄与を最小限に抑えるため、かつ、待ち時間の全ての他の原因を効果的に管理するためのものである。待ち時間の発生源を識別することは、全く簡単なことであるが(その生成からその消費まで、サウンド又はサウンドデータを処理する全ての装置及びコードピースがそうである)、これらの装置の一部からの寄与は、他のものに比較すると非常に小さいものである。待ち時間を効果的に制御又は最小限に抑えるためには、待ち時間を生み出す機構と、待ち時間に対する人間の知覚の性質とを理解することが重要である。
【0029】
以下の詳細説明は、「IP」電話技術に関するものであるが、説明する技術及び方法は、デジタル映像ストリーム、音声/映像データストリーム、データストリーム、又は、最終装置がデータを映像又は音声として消費するために受信するいかなるシステムにも同等に適用可能であることに注意すべきであり、また、当業者は、容易にそれを認めるはずである。
以下の説明において、「サンプル」という用語は、音声データブロックに言及する時は音声サンプルを、また、映像データブロックに言及する時はフレームを意味するように定義される。
【0030】
「IP」上でのサウンド及び映像通信の一部の共通の特性は、待ち時間の重要な一因となる全てのものに適用される。そのような待ち時間に寄与するものを理解することにより、待ち時間を更に解析するためのモデルを作成することができる。説明すべき基本的な特性は、以下のものである。
1)音声及び映像は、データグラム、チャンク、データブロック、「IP」パケット、又はセグメントで送信される。
2)音声及び映像データブロックでは、任意の有線又は無線接続で送信するための時間が必要である。
3)音声及び映像データブロックは、一般的に、完全に受信されて検証された後に限り、1つの装置から別の装置に送信されるか、又は他の方法で搬送される。
4)音声及び映像データブロックは、ほとんどの装置において、送信又は転送のために待ち行列化される。
5)音声及び映像データブロックは、送信中に失われる可能性がある。
6)音声及び映像データブロックは、音声データブロックが短い(すなわち、オーバーヘッドと比較して小さい)時に、全送信費の大部分となる可能性があるかなりのオーバーヘッドを有する。
7)音声及び映像の圧縮は、大きなデータブロック内で行われた時に最も効率的である。
【0031】
上述の通り、本発明は、待ち時間が問題になる任意の設定での映像データブロック、又は、音声及び映像の組合せを考慮しており、同じように良好に機能するものである。映像又は音声データブロックだけに言及した場合は、特に断らない限り、言及されていないものも対象となっていることを意図する。
「IP」音声又は映像通信の第1の基本的な特性は、音声がデータブロック、セグメント、データパケット、又はデータチャンクで送信されるということである。データブロックは、一般的に、多くの様々な圧縮アルゴリズム及びルーチンを通じて圧縮される。データブロックは、大きさが変動することができ、実際に変動する。データブロックの大きさは、一般的にバイトで測定され、もしある場合には使用された圧縮アルゴリズム、データブロック内に含まれた情報量(一部のデータブロックは、他のデータブロックよりも多くの情報を含み、従って、圧縮可能性が低い)、サウンドデータブロックの持続時間(一般的に、ミリ秒又は特定のサンプル速度でのサンプル数で測定される)、及び、音声、映像、又は音声/映像環境で達成される再生の忠実度によって異なる。その作成からその消費に至るまで、データブロック送信の経路における装置の待ち時間の寄与は、データブロックの特性(すなわち、使用された圧縮アルゴリズム、データブロックの大きさ、オーバーヘッドなど)の関数である。
【0032】
「IP」音声又は映像通信の第2の基本的な特性は、データブロックは、発生源から目的地まで伝わる時に、1つの装置から別の装置に送信されるのに特定量の時間を必要とするということである。発生源から目的地までの経路における全ての物理的リンクが同等に高速であるわけではなく、従って、待ち時間の一因になるにしても同等にはならない。例えば、最も遅いリンクは、一般的に家庭用コンピュータシステムとのモデムによるリンクであり、勿論、全待ち時間の最大量を占める。
【0033】
「IP」音声又は映像通信の第3の基本的な特性は、アドレス可能な装置(「IP」アドレスを有し、かつ、ルーティング装置として経路内に位置する装置)及び多くの他の装置(ルーティング装置として位置する可能性はないスイッチ類を含む)は、データブロック全体が最初に受信されて普通に検証されるまで次の目的地までのデータブロックの送信を開始しないということである。例えば、インターネットでは、20個のこのようなアドレス可能な装置が、ルートリストには見られないが同じようにこれらと同じ特性を示す幾つかの付加的なアドレス指定不能スイッチ又はハブと共に、経路上に位置することは珍しいことではない。
【0034】
「IP」音声又は映像通信の第4の基本的な特性は、インターネット上の遅延は、たとえ装置が正常に作動し、一切のパケット又はデータブロックが損失していなくても、任意に大きい可能性があるということである。装置の待ち行列は、データブロックが何らかの統計的分布に従って不規則に到着したとしても装置が十分な処理能力を達成することができるように、容量の過渡的又は瞬間的な過負荷を平滑化することを意図している。その結果、データブロックの不必要な脱落を回避するために負荷を平滑化する必要がある。
【0035】
また、待ち行列又はデータバッファは、終点装置を出入りする「IP」送信用の送信待ち行列と同様に、音声又は映像カード内、又は、音声又は映像カードドライバ内のような終点コンピュータ機器の構成要素である。これらの待ち行列の長さは、CPU及びメモリバススケジューリング、及び送信ライン上の負荷の影響を受ける可能性がある。待ち行列は、待ち時間の重大な一因となるものであり、長さは非常に変動する可能性がある。
【0036】
「IP」音声又は映像通信の第5の基本的な特性は、データブロックが失われる可能性があるということである。待ち行列が特定装置において長すぎた時、一般的に待ち行列からデータブロックを落とし、回復されないブロックは姿を消すだけである。これは、待ち時間が所定の最大値を超えた時、通常は250msを超えた時に一般的に起こる。250ms又はそれ以上の待ち時間レベルについては、リアルタイム又は近リアルタイム変換におけるユーザは、遅延に気付く。音声設定においては、通信は、携帯用無線電話機の感じを呈し始める。待ち時間は、一旦存在するとそれは持続することになり、通常は200ms未満の待ち時間である設計パラメータ内に再度なるように、消費装置(すなわち、音声、映像、又は音声/映像プレーヤ)の待ち行列か、又は最終装置に送信されてまだ消費装置の待ち行列内にないデータブロックから十分なデータブロックを削除する(すなわち、データブロックを落とす)のような何らかの措置を講じることによってはじめて克服することができる。消費装置は複数のバッファを有することができることに注意するべきである。消費装置に割り当てられた全てのバッファは、消費装置の待ち行列の一部とみなされる。割り当てられたメモリ量は、装置作動中に変更することができる。
【0037】
また、データブロックは、送信中に崩壊して失われる場合がある。損失は、損失のない送信の要件がある場合には、失われたデータブロックの送信を要求及び受信するのに必要とされる時間は勿論待ち時間に追加されるので、待ち時間に寄与する。これによって引き起こされる待ち時間は、一般的に容認できないものと考えられる。従って、「IP」電話技術及び標準的電話技術の場合、このような損失を受け入れて、受信機器は、行方不明となっているデータブロックに対処すべきである。冗長的に情報を送ることによってこのような行方不明となっているデータブロックの発生を低減することができるが、これにより、送信及び付随する待ち時間の帯域幅経費が増える。
本発明において、及び電話技術のほとんどの目的のためには、冗長送信の技術は、最も望ましいとは考えられていない。それにも拘わらず、本発明の一実施形態には、このような冗長技術及び機構の使用が考慮されており、このようなシステムは、本発明の教示内容から恩典を得ることになる。
【0038】
上述の第2及び第3の特性の間の相互作用は、待ち時間の大きな一因になる。各ノードにおいて、着信リンク上の送信時間は、第3の特性にはデータブロック全体が受信されるまで送信が行われないことが必要なので、待ち時間に追加される。例えば、遅いモデムリンクがそのようなリンクであり、また、サウンドデータブロック内で提供された帯域幅を担持する事がかろうじて可能であると仮定する。サウンドデータブロックが1秒のサウンドを含む場合、それが完全に送信されるにはほとんど1秒が必要であることになる。従って、これにより、そのリンクから1秒が待ち時間に追加されることになる。次のリンクのほうが恐らくははるかに高速であり、これによって対応する送信時間が待ち時間に寄与する。この処理は、データブロックが目的地で受信されるまで、インターネット又は通信ネットワーク上の各スイッチ及びルーティング装置において繰り返される。従って、全体的な遅延又は待ち時間は、かなりのものになる可能性がある。
【0039】
本発明は、この影響を最小限に抑えるものである。その一般的な機構は、合理的にできるだけ小さいパケットを送ることである。よく知られているように、各データブロック、データセグメント、又はパケットは、パケットを送信するオーバーヘッドの一部であるヘッダを含む。小さいパケットのヘッダは、大きなパケットのヘッダと同じサイズであり、従って、送信費は、小さいパケットを利用することによって上がり,同時に待ち時間が低減する。パケットサイズの低減は、基本的特性6の影響を制限する。
【0040】
幸いにもインターネットインフラストラクチャは、経時的に常に高速化される送信メディアで構築されており、現在では、超高速光ファイバリンクから成り、この特定の待ち時間の寄与が経時的に小さくなりつつあり、些細なものであることが多く、一般的には待ち行列化時の待ち時間だけを検討すればよい。最も遅いリンクに遭遇するネットワークの周辺装置では、この寄与は、依然として顕著なままである。各データブロックは、一般的に、その目的地に至る途中で2つの比較的遅い「最終マイル」リンクを通過することになる。
【0041】
更に詳細な説明においては、中継点は、1つの地点から別の地点にデータブロックを搬送するために利用される任意の接続又は装置であると定義される。中継点は、以下に限定されるものではないが、ハブ、ルータ、リピータ、スイッチ、「PBX」、コーデック、モデム、又は最終装置の1つとすることができる。データブロックを記憶し、待ち行列に入れ、互いに転送し合う中継点は、最終中継点(すなわち、最終装置)に達するまでWAN、LAN、インターネット、無線接続、又は通信ネットワークを通じて接続される。中継点は、一部の中継点が装置の最終ノード内の構成要素であることから、ネットワーク通信ノード又は装置だけに限定されないことに注意すべきである。これらの専用中継点は、データブロックを伝える以外の機能を実行する。例えば、音声又は映像I/Oカード、又はそのドライバは、符号器/復号器である中継点として有利にモデル化される。
【0042】
各中継点は、最小長さ及び最大長さを有するデータブロックの待ち行列を有する。所定の最大値を超えた場合、データブロックは、一般的に落とされるか、又は、長さをその最大閾値を下回る状態に保持するように何らの方法で処理される。最小長さは、中継点が「FIFO」待ち行列のヘッドでデータブロックを送信する前に超えるべき長さである。送信されているデータブロックは、待ち行列内にあるとはみなされない。従って中継点は、0という最大待ち行列長さを有することができるが、実際的な最大待ち行列長さの最小値は1である。明らかに、最大値は、最小値又はそれ以上でなければならない。
【0043】
n個の接続部Cnを有する特定の通信経路については、n個の目的地中継点Wnがある。接続部は、有線、光ファイバ、又は無線とすることができ、接続部Ciは、中継点Wi-1を中継点Wiに接続する。最初の接続部は、ソース中継点を有しておらず、すなわち、音声又は映像のソースと考えることができる。各接続部Ciについては、特徴的な送信速度tiがあり、tiは、本発明の実施形態においてはビット/秒で示される。中継点は、以下の固定された定量的特性を有する。
【0044】
iは、中継点Wiの第1の受信記憶データブロックが次の中継点に送信されるか又は伝えられる前の中継点Wi内の待ち行列の最小長さとして定義される。
iは、中継点Wi内のデータブロック内の待ち行列の最大長さとして定義される。
中継点は、データブロック内の待ち時間qiの長さである動的特性(すなわち、時間依存)を有する。接続部Ciで伝えられた特定の送信データブロックは、表現される音声又は映像の時間に関して、ミリ秒で測定されてdiによって表される固定の長さを有する。データブロックに必要とされる全ビット数は、biによって表される。値diは、スピーカ、モニタ、及び「PDA」などのような再生用及び消費用装置によって受信側で再生される時の音声又は映像データブロックの持続時間である。中継点が圧縮符号器/復号器(コーデック)である時には、着信ビットサイズは、表されるサウンドのミリ秒は同じであろうが発信ビットサイズと異なることが可能である。また、特定の中継点は、それが送信するサウンド以外にミリ秒長さで入力部にサウンドを収集することも可能である。例えば、ドライバと組み合わされた一部の音声カードは、要求されたサイズが50ミリ秒よりはるかに小さくても関係なく、受信側に送信する前に50秒程度の音声を収集する。従って、10ミリ秒データブロックが要求された場合は、50ミリ秒毎に素早く連続的に5種類の音声バッファ(データブロック)を配信することができる。
【0045】
簡素化のために、サウンド圧縮率は固定である、すなわち、設定された数のミリ秒の音声又は映像のデータブロックは、圧縮される音声又は映像の特性に関係なく、圧縮形態で表現するのに同数のビットをいつも必要とすることになると仮定する。この仮定を用いて、着信接続部に関連してiが1よりも大きい中継点iの固定又は非動的寄与は、式(1)によって以下のように示される。
ii+(bi/ti) (1)
【0046】
最初の中継点との最初の接続については、待ち時間に対する寄与は、消費速度がまさしくサウンド生成率であることから、単にd0である。従って、サウンドを次の中継点(恐らくはコーデック)に伝える前にサウンド装置が収集する大きさは、待ち時間に対する直接的な寄与である。固定の待ち時間は、次に式(2)によって以下のように定義される。
【0047】
Figure 2004535115
【0048】
待ち時間の動的寄与は、最小長さを超える待ち行列の長さに基づく。従って、動的な待ち時間は、式(3)によって以下のように定義される。
【0049】
Figure 2004535115
【0050】
ほとんどの中継点については、待ち行列の最小長さはゼロである。経路上の過渡的状態は、動的待ち時間に大きく影響し、待ち時間は、一般的にかなり変動性がある。動的待ち行列長さ(qi−li)は、独立して配信されるのではなく、独立した不規則なイベントに影響を受ける不規則な変数と考えることができる。待ち行列長さは、経路内の全ての装置の挙動に左右されるので独立して配信されるのではない。例えば、別の装置にデータブロックを送る装置は、目的地装置内の待ち行列長さに影響を与える。
【0051】
本発明の態様は、通信経路に亘る待ち行列長さの変動性全体を処理するのに十分であるがその通信経路よりも長くない、最終目的地における待ち行列長さを判断することである。あまりにも短く選択された待ち行列長さは、必要もないのに強制的にデータブロックを落とすことになり、一方、必要以上に長い待ち行列長さにより待ち時間が長くなる。更に、再生されるか又は最終装置によって消費される音声又は映像の不足による長い待ち時間又は劣った音声又は映像品質を知覚するユーザ側の機会を最小限に抑えるために、待ち行列長さの履歴に基づいて最終待ち行列の最大長さを動的に調節することが望ましい。
【0052】
上述の通り、インターネット又は通信ネットワークにおける経路上の待ち時間は、1つのコンピュータとLANで接続された別のコンピュータとの間でさえも極度に変動する。変動性の大部分は、過渡的な状態によって引き起こされる。従って、待ち行列長さは経路に沿って成長し、かつ動的に縮まり、最終待ち行列は、一般的にその緩みを有する。装置が待ち行列内のデータを消費したために最終待ち行列長さがゼロになった場合、待ち時間は、最終ユーザに対して消費又は再生するデータがない時間の量だけ成長する。
【0053】
変動性は、当業者であれば容易に認めるように、多くの方法で計算することができる。本発明は、任意の変動性計算方法を通じて待ち時間を動的に低減することを教示し、かつ考慮する。これには、以下に限定されるものではないが、統計的分散、又は変動性を計算する確率論的モデルが含まれる。変動性には、更に、重み付け平均値が含まれ、計算された変動性の目安は、変動性の目安の分数又は乗数であることができる。更に、変動性は、通信の履歴又は所定のウィンドウに亘って計算する、つまり、最近のイベントを更に考慮するために重み付けすることができる。従来技術による変動性は、ジッターとも呼ばれることがあり、最終ネットワーク目的地におけるパケット間の到着までの時間の差異の目安である。変動性は、データブロックが十分に処理されたか又はそうでない場合は最終ネットワーク目的地の構成要素である消費装置によって消費される準備ができた時の、消費装置の待ち行列長さの差異又は差異の目安として単に定義される。
【0054】
パケットが失われず、また、「RTP」がそうであるように音声生成クロックがサウンド再生クロックと正確に適合する(すなわち、入力部のサンプリング速度が、出力部のサンプリング速度と正確に一致する)と仮定した場合、待ち時間は、音声又は映像が発生源において最初に補足され始めた時から、音声又は映像が目的地で再生されていなかった期間の正に合計となる。この処理は、長い待ち行列を引き起こす条件は性質的には過渡的なものであるから、最終出力装置で更に長い待ち行列をもたらす。
【0055】
本発明は、最終中継点(出力装置)での待ち行列の長さを短縮することによって短い待ち時間をもたらす方法を提供する。本発明の実施形態は、待ち行列長さの成長、及び、不安定な過渡的状態中のより長い期間に対するその待ち行列サイズでの保守の増加に対して準備する。過渡的な状態が和らいだ時に待ち行列の短縮化を行う時は速すぎてはならず、速すぎると、装置が再びサウンド不足になってしまうことに注意すべきである。待ち行列の短縮化は、一般的に、何回も観察を行い、かなりの時間に亘って待ち時間の短縮をサポートすることができることが認められた後にはじめて行われるべきである。
【0056】
本発明においては、システム内の待ち時間の短縮化を行うための、動的に計算及び調節する同一又は類似の手段は、定常状態時のデータブロックの到着時間の統計的変動として狭義に定義されることがあるジッターについても調節する。ジッターは、その最終装置による消費よりも遅い又は速い音声又は映像生成に関連した問題も含むと定義されることがある。これは、消費が生成装置のクロックから独立したクロックで実行されることから不回避である。
【0057】
仮にジッターが唯一の現象であったとしたら、統計的に維持される待ち行列に対して有効な長さを単に見つけるだけで十分である。待ち行列がその選択された長さを超えた場合に、それは短縮されることになる。任意選択的に、それが短くなった場合は、何らかのデジタル信号処理手段によって長くすることができる。そうでない場合は、そのまま実行させておくことができるであろう。しかし、これは当てはまらない。本発明は、ジッターに対処して、しかし非常に変動する待ち時間、特に待ち時間の過渡的な増加をもたらす経路に亘る状態変化にも対処する方法を提供するが、この状態変化は、過渡的状態時に調節され、その後に過渡的状態が緩和されたらすぐに再調節することができる。これは、上述のように、本実施形態においては、待ち時間に寄与するものの全てが集計された後の動的な待ち行列管理を通じて達成される。
【0058】
待ち行列長さは、上述のように多少なりとも経路内の装置において独立しているので、待ち行列長さの管理は、主として最終の可能な地点で、又は、待ち時間の一因と考えられる任意のものを通過した後で行われることが好ましい。これは、待ち行列のオーバーフローを防止するためにデータブロックを落さなければならない例外的な状態の時を除き、中間地点での待ち行列長さの管理よりもかなり優れたものである。上述の解析に基づく単一の統計的又は確率論的モデルにより、複数の位置で待ち行列長さを管理しようとすれば待ち時間が恐らくは大きくなり、確かに待ち時間を効果的に低減することはできないことがわかっている。特に、通信プロトコル内の終点においてさえも、復号化及び符号化の段階が待ち時間に寄与する前の管理は賢明ではない。
【0059】
出力装置における出力待ち行列長さは、ほとんどの音声及び映像再生機器においてソフトウエアから判断することができる。これは、一般的に、出力開始からの出力装置内の再生されたサウンドサンプル数を識別する関数呼出しから戻されるパラメータから構成される。出力装置は、経時的にバイアスを時々発生させ、関数呼出し時の実際の位置の後ろにある位置を報告する。これにより、実際の長さを大幅に超える可能性がある待ち行列長さが知覚されることになる。この現象は、機器又は機器を管理するソフトウエアの欠陥として考えることができるが、広範囲な一般向けの音声及び映像I/O機器上で発生する。本発明は、バイアスを正確に推定することによってこの欠陥の影響を最小限に抑える方法を含む。
【0060】
バイアスは、装置に左右されるが、全ての装置において固定ではなく、従って待ち行列長さを知る場合には、報告された待ち行列長さは、真の待ち行列長さを得るために報告装置のバイアスに対して調節されなければならない。この調節は、音声又は映像データブロックを送信装置から受信する際の予想される間隔に対応する間隔でデータブロックを出力装置に伝える時に、装置の定常状態作動に基づいて行うべきである。
【0061】
図3は、本発明の態様によるバイアス係数判断を示す流れ図である。サウンドサンプルの待ち行列長さのバイアスを得るために、サウンド装置は、定常状態のバイアスの幾つかサンプルを得るために繰り返し厳密に調査される。バイアスは、出力装置に掛かる負荷を含む、本質的にサウンド装置及びドライバが作動するのと同じ環境で観察すべきである。換言すると、装置に対してサウンドを処理する時に10ミリ秒のデータブロックが供給される場合、プローブは、10ミリ秒のデータブロックを装置に送ることになる。データブロックの送信のタイミングを正確に測ることにより、待ち行列長さ(バイアスを示す差異)はほぼゼロであると判断することができる。プローブは、密な連続で発生することが好ましく、第1のプローブから得られる値は、一般的には使用されず、その結果、装置及びドライバは落ち着くことができる。幾つかの結果が平均化されて標準偏差が得られ、その後、調節バイアス値を得るために平均値が標準偏差の2倍に追加される。
【0062】
図3に示すように、段階305において、出力装置は、開放されて音声又は映像、又は、音声及び映像の両方が初期化され、サンプル位置カウンタが通常はゼロに設定される。段階310で、再生又は消費されると予想されるサウンドデータブロックに対応するサンプル数nに関して判断が行われる。更に、この段階では、装置再生速度で音声又は映像を再生するのに必要とされる変数mに保持されたミリ秒に対して判断が行われる。数値変数は、所定の数に設定され、この実施形態では、変数D及びVは、0に設定される。変数Dは、非再生サウンド観察値の合計を累積する。そのような各観察値は、0であるべきであったことに注意すべきである。変数Vは、そのような各観察値の平方を累積する。変数D及びVは、観察されたオフセットにおける平均値及び標準偏差を計算するために使用される。位相カウンタPは、この実施形態では2に設定され、書き込まれるサンプル総数Wは、0に設定される。変数名及び数字は、バイアス計算の基本的な手段及び原理が保持される限り、望ましい任意のものに設定することができることに注意すべきである。
【0063】
段階315で、ループカウンタLは10に設定され、段階320で、データブロックカウンタCは、この例においては5に設定される。制御は段階325に移り、長さnの空白(不可聴又は黒画面)音声/映像サンプルの書き込みが行われる。この段階で、カウンタCは1つ下げられ、書き込みサンプル数Wにnが追加される。段階330で、現在のスレッドは、ほぼm/2ミリ秒眠らされる(すなわち、遅延される)。これは、この作動に関連したスレッドがCPU時間を独占するのを防止するものであり、また、装置の実際の使用法をより綿密にシミュレートするためである。
【0064】
段階335で、最終書き込みからの全待機をmミリ秒に正確に等しくする(プログラム的にはほぼ可能)ために更なる遅延を現在のスレッドに更なるm/2ミリ秒分組み込む密接な使用中待機ループが入力される。使用中待機は、時間切れとなるまで繰り返しタイマを照会することによって実行することができる。段階340で、カウンタCが0に等しいか否かについて判断が行われる。等しくない場合は、処理は段階325に戻り、上述のように、その地点から続行される。判断結果がカウンタCは10に等しい場合、処理は、制御を段階345に移し、位相カウンタPが1に等しいか否かが判断される。
【0065】
段階345で、Pは1に等しいという判断結果であった場合、処理は段階350に進み、再生サンプル数pに関してシステムに要求が行われる。W−p=d((書き込みサンプル数)−(再生サンプル数))が計算される。その後、制御は段階355に移り、差異dがDに追加され、d*が変数Vに追加される。その後、制御は段階360に移り、そこから以下で説明するように続行される。
段階345で、位相カウンタPが1に等しくなかった場合、制御は、段階360に移り、ループLが1つ減じられる。段階365で、ループLが0に等しいか否かについて判断が行われる。結果が否定的な場合、制御は段階320に移り、上述のように、そこから続行される。段階365での判断結果が肯定的な場合には、位相カウンタPが1つ減じられる。制御は段階370に移り、Pが0に等しいか否かに関して判断が行われる。Pが0に等しくない場合、制御は段階315に移り、処理は、上述のようにその地点から進行する。Pが0に等しい場合、制御は段階380に移り、平均バイアスが計算される。
【0066】
段階380では、平均バイアスBは、(ループ数又は取られたデータポイント、この例では10)をDで割り、{(V/10)−B*B}の平方根を取ることによってバイアスBの標準偏差Sを計算することにより計算される。また、バイアス係数変数<biasFactor>は、この実施形態ではB+2Sとして計算される。バイアス係数は、推定バイアスに、バイアスを推定するために使用されたサンプル内での標準偏差の2倍を加えたものである。当業者が上記のバイアス係数の計算を修正して実質的に類似の結果を達成することができ、それらが依然として本発明の範囲及び教示内容に該当することに注意すべきである
【0067】
バイアスは、出力装置の音声及び映像処理ソフトウエア又はハードウエアにおける欠陥と見ることができるが、広範囲なものであるので対処する必要がある。従来技術では、この条件は無視されており、従って、装置の待ち行列のサイズ決定の不正確さが促進されている。音声及び/又は映像I/Oに使用することができる一部の装置は、このバイアスを有していない場合がある点に注意すべきである。本発明の態様は、バイアスを推定し、このようなバイアスがない場合にバイアス値をほぼゼロと見積るものであるが、この場合、バイアス成分は、実質的に計算結果に影響を与えることなく、待ち行列サイズ及び長さの推定結果及び計算結果から除外することができる。
【0068】
図4は、サウンド出力待ち行列の初期化を示しており、この時点で説明する。図4は、幾つかの定数を定義するものであり、本発明の実行を通じた特定の変数の使用を説明する。
「サウンド出力待ち行列リセット」400のための段階は、以下の通りである。段階410で、消費装置R(すなわち、出力装置又は映像/音声プレーヤ)にまだ書き込まれていない待ち行列サンプル数が0に設定される。この実施形態において、マニフェスト定数<MULT>は、128に設定され、マニフェスト定数<ROUND>及び<SCALER>は、以下のように計算される。
<ROUND>=<MULT>/2(これは64である)、及び
<SCALER>=<MULT>−1(これは127である)
【0069】
送信中の単一のデータブロック内で表されるサウンドのサンプル数に変数<buf_samples>を設定する。この値は、変数とすることができるが、この実施形態においては、固定値であることに注意すべきである。この変数は、サンプリング速度及びデータブロック内のサウンドミリ秒に左右され、本実施形態においては、2の累乗である。例えば、サンプリング速度が11,025/秒である場合、値は256、つまりほぼ23ミリ秒のサンプルである。変数<microSecData block>を、データブロック、データグラム、チャンク、又はパケットでのサウンドのミリ秒数であるとする。また、変数<CurrMicroseconds>は、システムが実行中であるミリ秒数であり、変数<CurrMicroseconds>がアルゴリズム内で使用される度に発生又は判断されるものとする。
段階420で、「サウンド(又はビデオ)アウト待ち行列」のリセットが図5に示すように実行されるが、これについては詳細に後述する。その後、処理は段階430に進み、バイアス係数、つまり、変数<biasFactor>が、図3に示しかつ上述したように判断される。その後、制御は段階440に移り、「サウンド・アウト・キュー」は、もう一度リセットされる。
【0070】
図5は、「サウンド・アウト・キュー」420のリセット(初期化中に2度行われるべきである)を示す。この処理は、特定のエラー条件から復帰するために、及び、待ち行列の一般的な初期化を促進するために使用される。
段階510で、待ち行列サンプル変数<queued>の数をRに設定するが、ただし、Rは、出力装置にまだ書き込まれていない待ち行列サンプル数である。初期化されると、変数<queued>は、Rがゼロであることから0に設定される。段階520で、サウンド出力の装置待ち行列は空にされ、通常、これは、サウンド出力装置を識別するシステムライブラリ呼出しによって行われる。段階530で、再生される累計サンプル数であるシステムで維持された値、変数<position>をシステムライブラリ呼出しによってゼロに設定する。尚、変数<position>は、恐らく低い精度で、アプリケーションによって維持することができ、例えば、バッファのサイズに出力装置待ち行列に現在ある(アプリケーションにシステムによってまだ戻されていない)バッファ数を掛けたものとして維持される。
【0071】
一部のシステム上では、本発明の特定の実施形態がサポートされない場合があるので、後者の手法は、変数<position>の値を維持するのに有益に使用することができる。後者の方法又はその均等方法が使用された場合、値Pはゼロに設定することができる。一部のシステムでは、変数<position>を計算することができる検索可能な値がある可能性がある。待ち行列の長さは、一部のシステムで直接アクセス可能であり、このようなシステムでは、その値は、明らかに有益に使用することができる。
段階540で、変数<total_queued>を0に設定し、段階550で、変数<microsecLastDropped>が0に設定される。「microsecLastDropped」は、最終データブロックが再生のために待ち行列から落とされた時にシステムが実行していたミリ秒数であると定義される。それは、データブロックの実際の落としが行われるまでゼロに設定される。
【0072】
図6は、データブロックが再生されるか、出力のための待ち行列化されるか、又は無視されるべきか否かを判断するための処理を示す。
段階610で、物理的に再生されていない、再生のために待ち行列化されたサンプル数が判断され、変数<queued>に記憶される。このオペレーションには、任意の時間に待ち行列化され、現在再生されている総数である変数<position>を得るシステム呼出しから判断される、全体のサンプル数である変数<total_queued>を知ることが名目上必要である。変数<queued>は、変数<queued>=変数<total_queued>−変数<position>として計算される。段階620で、変数<queued>≧0であるか否かが判断され、それがエラー条件である0未満である場合、制御は段階420に進み、サウンド・アウト・キューがリセットされ、その後、制御は、 上述のように段階610に進み、0以上である場合は、制御は段階630に進み、変数<sum>及び変数<sumsquared>が以下のように計算される。
変数<sum>=((変数<sum>*<SCALER>)+(変数<queued>*<MULT>)+<ROUND>)/<MULT>
変数<sumsquared>=((変数<sumsquared>*<SCALER>)+(変数<queued>*変数<queued>*<MULT>)+<ROUND>)/<MULT>
<MULT>による割り算及び掛け算は、<MULT>が2の累乗である場合にシフトオペレーションによって有益に達成することができることに注意すべきである。
【0073】
段階640で、重み付け平均待ち行列長さ変数<wavgqueue>、及び待ち行列長さの重み付け分散の変数<wvarqueue>が、以下の式によって計算される。
変数<wavgqueue>=(変数<sum>+<ROUND>)/<MULT>
変数<wvarqueue>=(変数<sumsquared>−((変数<sum>*変数<sum>+<ROUND>)/<MULT>)+<ROUND>)/<MULT>
【0074】
段階650で、中間値変数<overage>が、現在の重み付け平均待ち行列長さから、サンプル内のデータブロックのバイアス係数及び長さを引いたものとして以下のように計算される。
変数<overage>=変数<wavgqueue>−変数<biasFactor>−変数<buf_samples>
段階660で、変数<overage>が0以上であるか否かについて判断が行われる。否定的である場合、制御は段階670に移り、変数<overage_squared>が0に設定され、もし肯定的である場合、制御は段階680に移り、変数<overage_squared>は、<overage*overage>に設定される。その後、制御は段階690に移り、ブール値変数<dodrop>が、以下の式によって計算される。
変数<dodrop>=((9*変数<wvarqueue>)変数<変数<overage_squared>)
AND((変数<microSecData block>/4)=(変数<CurrMicroseconds>−変数<microSecData block>))
【0075】
幾つかの代数計算を通じて、<dodrop>に対する上式は、この場合3に設定される、重み付け平均待ち行列長さ−重み付け標準偏差が、サンプル内の単一データブロックの長さよりも大きいか否かを判断する式であることを示すことができる。そうである場合、待ち行列がサウンド不足になるという懸念なしに、待ち行列長さを1データブロックだけ安全に減じることができる。この式の第2の部分は、データブロックが、約4つに1つよりも速くは取り除かれないことを保証するが、この数字は、アプリケーションにより2つに1つから3つ又はそれ以上に1つまで変る可能性がある。
【0076】
図7は、着信データブロック、又は、発生源から目的地への送信を構成するデータブロックセットの処理を示す。この作業は、サウンドを含む送信が受信される時は常に行われることが好ましい。
段階710で、送信は、経路内の最終の物理的装置で受信される(名目上、この装置とアナログ再生ハードウエアとの間には、これ以上のLAN又は無線送信リンクはない)。これは、制御を段階720に移す外部的に駆動されるイベントであり、データブロックがこの送信において多重に(恐らくは冗長に)表されている場合、それらは分離され、この処理は、各データブロックが以前の冗長な送信からまだ処理されていない第1のデータブロックから始まる順番で続行される。冗長な送信は、ほとんどの環境に対しては好ましくないが、それに遭遇した場合は、冗長な送信は、この段階で取り除かれる。
【0077】
段階730で、データブロックは、再生又は消費されるように復号化されるか、又は他の方法で処理される。一般的に、必要とされるいかなる解凍及び/又は復号化も処理のこの時点で行われる。段階740で、ブール値変数<dodrop>は、図6に説明するように計算される。段階750で、<dodrop>の様々な条件が満たされたか否かが判断され、満たされた場合は、制御は段階760に移り、変数<buf_samples>をパスした値として使用することにより、落とされたデータブロックに対して統計的履歴が調節される。段階750で、変数<microsecLastDropped>が、以下のように設定される。
変数<microsecLastDropped>=変数<CurrMicroseconds>
変数<dodrop>の条件が満たされなかった場合、制御は段階770に移り、準備されたデータブロックは、再生されるように消費装置の出力待ち行列に追加される。
【0078】
図8は、データブロックの配置を判断するために行われる統計的履歴の調節を示す。大雑把に言えば、このアルゴリズムは、正しく受信されたデータブロックがそれにもかかわらず再生されていないその後の履歴を正しく表すように統計を調節する。データブロックが再生されなかった場合、それは、次のデータブロックが到着した時により短い待ち行列をもたらし、従って、過去においてずっと待ち行列がより短ければ取得されたであろう統計的履歴が生成される。
【0079】
段階810で、変数<adjust_samples>が、このアルゴリズムに通される。統計的履歴は、2つの変数、つまり、変数<sumsquared>及び変数<sum>で保持される。このアルゴリズムはこれらを調節し、それによって、次のデータブロックが正確に時間通りに到着し、再生(サウンド出力)装置がその間隔で予想サウンド量を正確に再生した場合、履歴は、待ち行列がサンプリングされた毎回の履歴における長さが変数<adjust_samples>だけ短かった場合に取得されたであろう新しい変数<sum>及び変数<sumsquared>を反映することになる。これは、幾つかのデータブロックを連続的に取り除く必要がある時に、待ち行列の短縮化を適度に早く進行させる。動的待ち行列管理アルゴリズムは、従って、非常に長い待ち行列を作り出す過渡的条件をより迅速に調節する。
【0080】
段階820で、変数<sum>は、以下の式によって調節される。
変数<sum>=変数<sum>−(変数<adjust_samples>*<MULT>)
変数<sum>が0未満である場合、変数<sum>を0に設定する。
段階830で、変数<sumsquared>は、以下の式で調節される。
変数<sumsquared>=変数<sumsquared>−(((2*変数<adjust_samples>*変数<sum>)−(変数<adjust_samples>*変数<adjust_samples>)+<ROUND>)/<MULT>)
変数<sumsquared>が0未満である場合、変数<sumsquared>を0に設定する。
【0081】
ここで、本発明の上記のシステム及び方法の概要について説明する。待ち行列の初期化は、図4に示すように、一般的にIP電話技術による接続が作り出された時に行われる第1の作業である。これは、一般的に、その後のアルゴリズム実行によって使用される定数を設定して特定の変数を初期化する。それは、待ち行列制御機構を設定するために1度呼び出されることが好ましい。
図5で説明するサウンド・アウト・キューのリセットは、全ての待ち行列化されたサンプルの出力装置を空にすることから成る。これは、通常、何らかのエラーが発生したために行われる。例えば、出力の位置が装置に書き出されたサンプル数よりも前に報告された場合、出力装置ドライバに既に与えられたサウンドデータブロックは破棄され、装置位置がリセットされる。また、この同じルーチンは、バイアス係数のプローブが作られる前に1度、その後、受信データブロックが最初に装置に書き出される前にもう1度、すなわち、初期化時に2度発生することが好ましい。
【0082】
初期化時の1つの変数の設定は、特に関連がある。図3及びその添付の説明文で示されているように幾つかのプローブを作ることによって発生されるのは、サウンド出力装置のバイアス係数である。このバイアス係数は、推定待ち行列長さを調節するために使用され、出力装置がまさに接続のためにサウンドを再生することになる時の作動モードである間に取得されるべきである。バイアス係数は、出力装置の幾つかのプローブから、待ち行列長さの標準偏差及び平均値の計算を用いて計算される。バイアスは、待ち行列長さがほぼゼロであることが保証されている会話中に取得されるであろう正確なタイミングを複写することによって注意深く作り出される。
【0083】
しかし、一般的に、報告された位置は遅延しており、従って、その長さは、何百ものサンプルとして計算される場合がある。一連のプローブは、出力装置ドライバのような影響を受ける要素を定常状態に安定させるために実行される。その後、第2の一連のプローブが実行され、測定が行われた後に合計されて、各プローブに対する待ち行列の長さ及び待ち行列の長さの平方根が得られる。その後、平均値及び標準偏差が計算され、バイアス係数が平均値+標準偏差の2倍に設定される。
【0084】
図8及びそれに添付の説明文に示すように、統計値は、各データブロックが到着した時に維持される。統計的履歴は、指数関数的に重み付けされた統計的モーメントとして維持される。重み付け合計及び値の平方の重み付け合計が保持される。その後、それらの値から重み付け平均及び重み付け分散が計算される。本発明において、これらの計算は、割り算ではなくシフトオペレータを使用して効果的に行われる。更に、平方根ルートを取る必要はない。その代わりに、判断はバイナリであるから、この分散を用いて比較を発生させるために代数計算が実行される。その結果、3個の標準偏差が9個の分散と比較される。
【0085】
この導出は、以下のように行われることが好ましい。「Avg」が平均重み付き待ち行列長さを示し、「Sig」が標準偏差であり、「Bufflen」がサンプル内のバッファの長さであるとすると、平均値−3標準偏差が単一データブロックよりも長さが大きいか否かを判断することが望ましい場合があり、この場合、データブロック全体は、以下の式(4)で定義されるように安全に落とすことができる。
Avg−3*Sig>Bufflen
*Sig<Avg−Bufflen (4)
*Sig*Sig<(Avg−Bufflen)*(Avg−Bufflen)
式(4)において、Sig*Sigは、分散(すなわち、変動性)であり、従って、上式の比較により平方根は回避されるが、この比較は、重み付け平均値−3標準偏差がバッファの長さよりも大きいか否かを判断することと全く同じである。結果が真の場合、待ち行列をサンプルの1データブロックだけ短縮することは安全であると判断される。
【0086】
また、待ち行列長さのシーケンスの平均値及び分散を推定するために、カルマンフィルタという公知の一般的再帰デジタルフィルタリング技術を有利に使用することができることに注意すべきである。これを全般的に実行しても好ましい実施形態ほどは計算上効率的ではないであろうが、パラメータが適当に選択されれば、類似の結果を得ることができる。しかし、それは、カルマンフィルタが履歴を再帰的にも同様に維持するので、独立して各データブロックに対する平均値及び分散を計算するよりもかなり効率的であろう。
【0087】
図7に戻ると、1つよりも多いデータブロックが通信中である場合の着信データブロック又は一組のデータブロックの一般的な処理が示されている。大雑把には、データブロックについて行われる第1の判断は、それを復号化及び/又は暗号解読することであり、それは、これが待ち時間及び分散を待ち行列に追加する可能性があるためである。このオペレーションは、データブロックを落とすべきか否かを判断する前に行われることが好ましく、それは、その計算を実行するために必要な時間が、データブロックが実際に再生される上で利用可能である時に待ち行列長さを短くすることになるからである。図7に示すデータブロックを再生することになるか否かに関する判断は、データブロックが実際に再生されることになるか否かを判断するために実行することができる。
【0088】
より多くのCPU時間を必要とする代替実施形態においては、次の4つのデータブロック又はデータブロックの何らかの他の部分集合に対するサンプル数を減らすために、当業技術で公知の技術を用いてサウンドを再採取する。この再採取処理は、再生時のサウンド周波数を維持するため、及び、サンプル数を減らすために使用される。また、素早い連続的なデータブロック落としの繰返しのためのデータブロック落とし解決策の使用、及び、落とす必要があるサンプル数が少ない時に待ち行列化されたサンプル数を減らすための再採取の使用が可能である。このような処理は、CPU時間がより高価になるが、状況によっては優れた出力が得られる。
【0089】
待ち行列の短縮が次のデータブロックの到着で予想される場合、例えば、そのデータブロックが出力に対して待ち行列化されていない場合、統計値は、図8に示すアルゴリズムの呼出しによって適当に修正される。図8及びその添付の説明文に示すように、履歴が調節され、それによって履歴、すなわち、合計の値及び平方の合計に、待ち行列が特定のサンプル数によって履歴全体を通じて短縮された場合に取得されたであろう値を反映させる。これは、調節が行われなかった場合に得られるであろう新しい平均値で履歴が安定であると見なされることを可能にし、それによって、別の待ち行列の短縮が為される場合に、それを素早く行うことができる。別に言い方をすれば、待ち行列を直接短縮しても、送信媒体の不安定性の知覚は増えないはずである。この調節は、その発生を回避する。
【0090】
本発明の「IP電話技術のための動的待ち時間管理」において、また本発明の作製において、本発明の範囲又は意図から逸脱することなく様々な修正及び変形を行うことができることが当業者には明らかであろう。
また、本明細書の検討及びそこに開示した本発明の実施から、本発明の他の実施形態が当業者には明らかであろう。本明細書及び実施例は単に例示的であるとみなされ、本発明の真の範囲及び精神は、特許請求の範囲によって示されるように意図されている。
【図面の簡単な説明】
【0091】
【図1】「IP」電話技術送信システムの従来技術によるシステムを示す図である。
【図2】有線及び無線「IP」電話技術をサポートするための一般的な物理的環境を示すデータブロック図である。
【図3】本発明の態様によるバイアス係数判断を示す流れ図である。
【図4】本発明によりサウンド・アウト・キューを初期化するための処理の流れを示すデータブロック図である。
【図5】本発明によりサウンド・アウト・キューをリセットするための処理の流れを示すデータブロック図である。
【図6】本発明の態様によるデータブロック配置判断を示す流れ図である。
【図7】本発明によるデータの着信データブロックの処理を示す流れ図である。
【図8】本発明により統計的履歴を調節するための処理の流れを示すデータブロック図である。
【符号の説明】
【0092】
200 一般的システムアーキテクチャ
210 消費装置
215 CPU
225 「IP」通信手段
230 無線通信手段
235 I/Oポート
255 外部スピーカ及びマイク
260 LANスイッチングネットワーク
265、275 「IP」ルーティング手段
285、290 無線アクセスポイント

Claims (51)

  1. 通信ネットワーク上の待ち時間を動的に低減する方法であって、
    a)次のデータブロックの処理の完了を判断する段階と、
    b)該次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する段階と、
    c)該消費装置の該待ち行列に残っている該サンプル数の変動性を判断する段階と、
    d)該変動性に基づいて該消費装置の該待ち行列におけるサンプルの残数を低減することができるか否かを判断する段階と、を含むことを特徴とする方法。
  2. 前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項1に記載の待ち時間を動的に低減する方法。
  3. 前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項1に記載の待ち時間を動的に低減する方法。
  4. 前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項1に記載の待ち時間を動的に低減する方法。
  5. 前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項1に記載の待ち時間を動的に低減する方法。
  6. データブロックのサンプルは、前記待ち行列に残っているサンプル数が、データブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  7. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  8. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも1つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  9. 前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項1に記載の待ち時間を動的に低減する方法。
  10. 前記変動性は、重み付けされることを特徴とする請求項6に記載の待ち時間を動的に低減する方法。
  11. 前記変動性は、重み付けされることを特徴とする請求項1に記載の待ち時間を動的に低減する方法。
  12. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と、前記変動性と、バイアスとの合計よりも大きい場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  13. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  14. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも1つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  15. 前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項13に記載の待ち時間を動的に低減する方法。
  16. 前記変動性は、重み付けされることを特徴とする請求項12に記載の待ち時間を動的に低減する方法。
  17. 前記変動性は、重み付けされることを特徴とする請求項15に記載の待ち時間を動的に低減する方法。
  18. 全データブロックの少なくとも一部分に対して、段階a)からd)を繰り返す段階を更に含むことを特徴とする請求項1に記載の待ち時間を動的に低減する方法。
  19. 前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項18に記載の待ち時間を動的に低減する方法。
  20. 前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項18に記載の待ち時間を動的に低減する方法。
  21. 前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項18に記載の待ち時間を動的に低減する方法。
  22. 前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項18に記載の待ち時間を動的に低減する方法。
  23. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項22に記載の待ち時間を動的に低減する方法。
  24. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項22に記載の待ち時間を動的に低減する方法。
  25. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも1つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  26. 前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項24に記載の待ち時間を動的に低減する方法。
  27. 前記変動性は、重み付けされることを特徴とする請求項23に記載の待ち時間を動的に低減する方法。
  28. 通信ネットワーク上の待ち時間を動的に低減する方法であって、
    a)いつデータブロックが消費装置の待ち行列に追加される準備ができるかを識別する段階と、
    b)該消費装置をポーリングして、該消費装置の前回のポーリングから該消費装置によって消費されたサンプル数を計算する段階と、
    c)該消費装置によって消費された該サンプル数の変動性を計算する段階と、
    d)該変動性に基づいて、該消費装置の前記待ち行列におけるサンプルの残数を低減することができるか否かを判断する段階と、を含むことを特徴とする方法。
  29. 通信ネットワーク上の待ち時間を動的に低減するためのシステムであって、
    a)次のデータブロックの処理の完了を判断する手段と、
    b)該次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する手段と、
    c)該消費装置の該待ち行列に残っているサンプル数の変動性を判断する手段と、
    d)該変動性に基づいて該消費装置の該待ち行列における該サンプルの残数を低減することができるか否かを判断し、可能である場合に該待ち行列を低減する手段と、を含むことを特徴とするシステム。
  30. 前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項29に記載の待ち時間を動的に低減するシステム。
  31. 前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項29に記載の待ち時間を動的に低減するシステム。
  32. 前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項29に記載の待ち時間を動的に低減するシステム。
  33. 前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項29に記載の待ち時間を動的に低減するシステム。
  34. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項33に記載の待ち時間を動的に低減するシステム。
  35. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項33に記載の待ち時間を動的に低減するシステム。
  36. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも1つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項5に記載の待ち時間を動的に低減する方法。
  37. 前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項31に記載の待ち時間を動的に低減するシステム。
  38. 前記変動性は、重み付けされることを特徴とする請求項34に記載の待ち時間を動的に低減するシステム。
  39. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と、前記変動性と、バイアスとの合計よりも大きい場合に破棄されることを特徴とする請求項33に記載の待ち時間を動的に低減するシステム。
  40. 様々なデータブロックに対して段階a)からd)を繰り返す段階を更に含むことを特徴とする請求項29に記載の待ち時間を動的に低減するシステム。
  41. 通信ネットワーク上の待ち時間を動的に低減するためのソフトウエア製品であって、
    コンピュータ読取可能な媒体上にあり、
    a)次のデータブロックの処理の完了を判断し、
    b)該次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断し、
    c)該消費装置の該待ち行列に残っているサンプル数の変動性を判断し、
    d)該変動性に基づいて該消費装置の該待ち行列における該サンプルの残数を低減することができるか否かを判断し、可能である場合に該待ち行列を低減する、ための命令を実行するようにプロセッサに指示することができる、ことを特徴とするソフトウエア製品。
  42. 前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項41に記載の待ち時間を動的に低減するためのソフトウエア製品。
  43. 前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項41に記載の待ち時間を動的に低減するためのソフトウエア製品。
  44. 前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項41に記載の待ち時間を動的に低減するためのソフトウエア製品。
  45. 前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項41に記載の待ち時間を動的に低減するためのソフトウエア製品。
  46. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項45に記載の待ち時間を動的に低減するためのソフトウエア製品。
  47. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項45に記載の待ち時間を動的に低減するためのソフトウエア製品。
  48. データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも1つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項45に記載の待ち時間を動的に低減するためのソフトウエア製品。
  49. 前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項41に記載の待ち時間を動的に低減するためのソフトウエア製品。
  50. 音声/映像消費装置におけるバイアスを判断する方法であって、
    時間間隔の間に消費されたサンプル数に関して消費装置をポーリングする段階と、
    消費されたサンプル数を、消費装置設定消費速度に基づいて計算された複数の時間間隔の間に消費されたはずのサンプル数と比較する段階と、を含むことを特徴とする方法。
  51. 通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる音声及び映像消費装置であって、
    メモリを含むプロセッサと、
    データブロックの送信、受信、及び消費の少なくとも1つが可能であり、該プロセッサと通信して該プロセッサより制御された周辺装置と、
    ソフトウエア製品と、を含み、
    該ソフトウエア製品は、
    次のデータブロックの処理の完了を判断し、
    該次のデータブロックの消費装置の待ち時間に残っているサンプル数を判断し、
    消費装置の該待ち時間に残っている該サンプル数の変動性を判断し、
    該変動性に基づいて消費装置の該待ち行列における該サンプルの残数を低減することができるか否かを判断する、ための命令を実行するように前記プロセッサに指示することができる、ことを特徴とする装置。
JP2003504614A 2001-06-09 2002-06-10 Ip電話技術のための動的待ち時間管理 Pending JP2004535115A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US29711901P 2001-06-09 2001-06-09
PCT/US2002/018401 WO2002102004A1 (en) 2001-06-09 2002-06-10 Dynamic latency management for ip telephony

Publications (1)

Publication Number Publication Date
JP2004535115A true JP2004535115A (ja) 2004-11-18

Family

ID=23144935

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003504614A Pending JP2004535115A (ja) 2001-06-09 2002-06-10 Ip電話技術のための動的待ち時間管理

Country Status (8)

Country Link
US (1) US7283548B2 (ja)
EP (1) EP1396124A4 (ja)
JP (1) JP2004535115A (ja)
KR (1) KR100677179B1 (ja)
CN (1) CN100359892C (ja)
AU (1) AU2002310383B2 (ja)
CA (1) CA2450011A1 (ja)
WO (1) WO2002102004A1 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10222156A1 (de) 2002-05-17 2003-11-27 Siemens Ag Verfahren zur übertragungseffizienten Aufbereitung von Multimedianachrichten
US20040125754A1 (en) * 2002-08-01 2004-07-01 General Instrument Corporation Method and apparatus for integrating non-IP and IP traffic on a home network
JP3825007B2 (ja) * 2003-03-11 2006-09-20 沖電気工業株式会社 ジッタバッファの制御方法
US20040202119A1 (en) * 2003-04-10 2004-10-14 Edge Stephen William Base station synchronization in a wireless network
DE102004018200A1 (de) * 2004-04-15 2005-11-10 Deutsche Thomson-Brandt Gmbh Verfahren zum Verarbeiten einer Folge von Datenpaketen in einer Empfängervorrichtung sowie Empfängervorrichtung
AU2006346226B8 (en) * 2005-07-20 2010-03-25 Vidyo, Inc. System and method for a conference server architecture for low delay and distributed conferencing applications
US20080049635A1 (en) * 2006-08-25 2008-02-28 Sbc Knowledge Ventures, Lp Method and system for determining one-way packet travel time using RTCP
US7940655B2 (en) * 2007-10-31 2011-05-10 Futurewei Technologies, Inc. Cross-layer optimization of VoIP services in advanced wireless networks
US8077628B2 (en) * 2008-02-12 2011-12-13 International Business Machines Corporation Mobile device peer volume polling
US8462681B2 (en) * 2009-01-15 2013-06-11 The Trustees Of Stevens Institute Of Technology Method and apparatus for adaptive transmission of sensor data with latency controls
US8433283B2 (en) 2009-01-27 2013-04-30 Ymax Communications Corp. Computer-related devices and techniques for facilitating an emergency call via a cellular or data network using remote communication device identifying information
US8731030B1 (en) 2012-03-20 2014-05-20 Remec Broadband Wireless Llc Transmission system of digital radio information using repeaters while minimizing data transfer latency
CN104662826B (zh) * 2012-08-10 2018-03-13 Abb研究有限公司 分站网络中的等待时间确定
JP5769748B2 (ja) * 2013-03-26 2015-08-26 京セラドキュメントソリューションズ株式会社 ネットワーク通信装置、ファクシミリ装置
US10313416B2 (en) * 2017-07-21 2019-06-04 Nxp B.V. Dynamic latency control

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS57159192A (en) * 1981-03-27 1982-10-01 Hitachi Ltd Audio packet exchange system
DE9412925U1 (de) * 1994-08-11 1995-12-14 Dolmar Gmbh Mähfaden für Freischneidegeräte
JPH08223180A (ja) 1995-02-17 1996-08-30 Nec Corp Atm交換機のトラフィック制御方法
CA2222151C (en) * 1995-06-07 2001-08-14 U.S. Robotics Corporation Communication access system with distributed processing
US6304574B1 (en) * 1995-06-07 2001-10-16 3Com Corporation Distributed processing of high level protocols, in a network access server
FR2762735B1 (fr) * 1997-04-23 1999-06-11 France Telecom Procede d'ordonnancement de paquets a pertes equitables
US6301258B1 (en) * 1997-12-04 2001-10-09 At&T Corp. Low-latency buffering for packet telephony
ATE359647T1 (de) * 1998-06-11 2007-05-15 Synchrodyne Networks Inc Paketvermittlung mit gemeinsamer referenzzeit
US6272131B1 (en) * 1998-06-11 2001-08-07 Synchrodyne Networks, Inc. Integrated data packet network using a common time reference
US6259677B1 (en) * 1998-09-30 2001-07-10 Cisco Technology, Inc. Clock synchronization and dynamic jitter management for voice over IP and real-time data
US6665728B1 (en) * 1998-12-30 2003-12-16 Intel Corporation Establishing optimal latency in streaming data applications that use data packets
US6785230B1 (en) * 1999-05-25 2004-08-31 Matsushita Electric Industrial Co., Ltd. Audio transmission apparatus
US6735192B1 (en) * 1999-09-29 2004-05-11 Lucent Technologies Inc. Method and apparatus for dynamically varying a packet delay in a packet network based on a log-normal delay distribution
US6859460B1 (en) * 1999-10-22 2005-02-22 Cisco Technology, Inc. System and method for providing multimedia jitter buffer adjustment for packet-switched networks
US6363065B1 (en) * 1999-11-10 2002-03-26 Quintum Technologies, Inc. okApparatus for a voice over IP (voIP) telephony gateway and methods for use therein
JP2002077233A (ja) * 2000-08-25 2002-03-15 Matsushita Electric Ind Co Ltd リアルタイム情報受信装置

Also Published As

Publication number Publication date
KR20040017228A (ko) 2004-02-26
EP1396124A4 (en) 2011-08-17
AU2002310383B2 (en) 2006-12-14
US7283548B2 (en) 2007-10-16
WO2002102004A1 (en) 2002-12-19
CA2450011A1 (en) 2002-12-19
KR100677179B1 (ko) 2007-02-05
EP1396124A1 (en) 2004-03-10
CN1541471A (zh) 2004-10-27
CN100359892C (zh) 2008-01-02
US20030021285A1 (en) 2003-01-30

Similar Documents

Publication Publication Date Title
US7359979B2 (en) Packet prioritization and associated bandwidth and buffer management techniques for audio over IP
US7058048B2 (en) Per-call quality of service monitor for multimedia communications system
KR100501324B1 (ko) 음성 품질 예측값을 이용한 보이스 오버 인터넷프로토콜에서의 콜 라우팅 방법
US8160030B2 (en) Data rate controller
US6684273B2 (en) Auto-adaptive jitter buffer method for data stream involves comparing delay of packet with predefined value and using comparison result to set buffer size
US7920492B1 (en) Devices, softwares and methods for redundantly encoding a data stream for network transmission with adjustable redundant-coding delay
US6996626B1 (en) Continuous bandwidth assessment and feedback for voice-over-internet-protocol (VoIP) comparing packet's voice duration and arrival rate
JP5632486B2 (ja) 通信ネットワークにおいて伝送をスケジューリングする方法、対応する通信ノード及びコンピュータプログラム製品
US8081614B2 (en) Voice transmission apparatus
EP0921666A2 (en) Speech reception via a packet transmission facility
JP2005269632A (ja) 通信端末装置、電話データ受信方法、通信システムおよびゲートウェイ
JP2004535115A (ja) Ip電話技術のための動的待ち時間管理
EP3466001B1 (en) Media buffering
AU2002310383A1 (en) Dynamic latency management for IP telephony
US8649277B2 (en) Communication apparatus and method
Chuah Providing End-to-End QoS for IP based Latency sensitive Applications
JP4218456B2 (ja) 通話装置、通話方法及び通話システム
JP2005252429A (ja) Ipパケット化装置
Ramos Robust and reliable multimedia transmission over the Internet

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20051109

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20051219

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060320

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20060328

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20060814