JP3891755B2 - パケット受信装置 - Google Patents
パケット受信装置 Download PDFInfo
- Publication number
- JP3891755B2 JP3891755B2 JP2000085744A JP2000085744A JP3891755B2 JP 3891755 B2 JP3891755 B2 JP 3891755B2 JP 2000085744 A JP2000085744 A JP 2000085744A JP 2000085744 A JP2000085744 A JP 2000085744A JP 3891755 B2 JP3891755 B2 JP 3891755B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- time
- received
- unit
- buffer
- 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
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0823—Errors, e.g. transmission errors
- H04L43/0829—Packet loss
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
- H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
-
- 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/22—Traffic shaping
-
- 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/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【発明の属する技術分野】
本発明はパケット受信装置に関し、例えば、符号化した音声信号をパケット化して伝送し、伝送されてきたパケットを受信、復号して音声信号を出力する場合などに適用し得るものである。
【0002】
【従来の技術】
まず、パケットによる音声送受信システムの一例を、図2を用いて説明する。
【0003】
図2において、送信装置21の端子1から入力された音声信号は、入力バッファ2に格納された後、符号化部3で音声符号化される。この符号化音声は、フレームという単位で処理され、生成される。当該符号化音声フレームは、パケット通信網11を伝送するためにパケット化する必要がある。
【0004】
通常、1つのパケット内には複数の(符号化音声)フレームが収容されるため、パケット化できる量になるまで、符号化音声は送信バッファ4に蓄えられる。パケット化に十分な量が送信バッファ4に蓄積されたところで、蓄積された複数のフレームに必要なヘッダ情報を付加してパケット化が実行される。
【0005】
このパケット化によって生成されたパケットは、端子5から送出パケットとしてパケット通信網11に送出され、パケット通信網11を伝送されたのち、受信パケットとして受信装置21に受信される。
【0006】
受信パケットは、受信装置21の受信端子6で受信され、受信バッファ部7に一時的に蓄えられた後、復号部8で復号される。この復号音声は出力バッファ9に送られ、出力端子10から音声出力される。受信バッファ部7は、受信したパケットを一時的に蓄積するためのFIFO(先入れ先出しタイプのメモリ)を主体とするデバイスである。
【0007】
理想的なパケット通信網11の場合、図4(A)に示すように、前記送信装置20から時系列に送出されたパケット(フレーム)P1〜P8は欠落することなく、常に等間隔で受信バッファ部7に到着する。図4(A)では、t0とt1の間隔、t1とt2の間隔、t2とt3の間隔、…、t8とt9の間隔はすべて、一定時間Tであり、時系列な受信パケットP1、P2、P3、…、P8は当該間隔Tを置いて受信バッファ部7に到着する。
【0008】
このような理想的なケースでは、各受信パケットP1〜P8は、受信バッファ部7に入ると直ちに読み出されて復号され、端子10からは、図4(B)に示すような理想的な音声出力が得られる。すなわち図4(B)の音声出力には、途切れ(音声出力に間欠的に発生する空白状態)も、音飛び(音声出力の意味的な連続性の喪失状態)も発生しない。
【0009】
【発明が解決しようとする課題】
しかしながら一般的には、パケット通信網11は多くの利用者が同時に使用するため、ある送出パケットがパケット通信網11に入ってから出てくるまでの時間は、時々刻々と変動するパケット通信網11の混雑具合に依存し、上述した理想的なケースは、極めてまれにしか起こり得ない。
【0010】
すなわち、現実のパケット通信網11では、通常、パケット通信網11の混雑の程度が比較的軽微な場合は受信パケットの到着が等間隔Tに近い時間となるが、パケット通信網11の混雑の程度が高い場合には、各受信パケットの到着時刻変動が大きくなる。その様子は、例えば図3(A)および(B)に示したようなものである。
【0011】
図3(A)では、時系列な受信パケットP1〜P8のうち、3番目の受信パケットP3が遅れて到着し、更に通信網11内で6番目の受信パケットP6を紛失した場合である。
【0012】
図3(A)において、受信パケットP1とP2は、それぞれ定刻(ジッタが無い場合の各パケットの到着時刻)t1、t2に受信バッファ部7に到着したため、受信バッファ部7に入ると同時に読み出されて復号され、音声出力される。ここで、ジッタ(遅延揺らぎ)とは、前記時系列に受信される受信パケットP1〜P8のうち、隣接するパケット間(例えば受信パケットP2とP3のあいだ)の相対的な受信時間間隔が(前記Tから)変動する現象である。
【0013】
ところで、前記受信パケットP2につづいて受信されるパケットP3はジッタのために定刻t3よりも遅れて到着したから、時刻t3には受信バッファ部7が空になり、復号部8に渡すデータ(パケット、フレーム)がない。このため、端子10からの出力音声を示した図3(B)では、P2に対応する音声出力を行ったあと一時的に音声が途切れて再生音が切断された状態となる。復号部8に渡すデータがない場合、直前フレームのデータを模倣したエラーフレームを作成して、これを復号部8に渡すことで再生音が切断されないようにすることも考えられるが、この部分での再生音の劣化は防げない。
【0014】
この後、遅刻して到着した受信パケットP3は、時刻t4に定刻で到着した受信パケットP4と共に受信バッファ部7に蓄積され、先に到着した受信パケットP3が時刻t4に読み出されて、復号、再生される。
【0015】
本来、受信パケットP3は時刻t3に再生されるべきデータのため、この時点で再生遅延(t4−t3)が発生する。ここで、遅延とは、ある受信パケット(フレーム)に関する受信や再生の時刻が、その受信パケットに対応付けて設定された絶対的な受信時刻や再生時刻から遅れる現象である。
【0016】
図3(A)および(B)において、受信バッファ部7の状態に着目すると、受信バッファ部7に蓄積されているデータが存在しないバッファ空状態が発生するたびに、遅延が積算されていくということができる。
【0017】
ただし、遅延が積算されるためには、単にバッファ空状態が発生しただけでは足りず、復号部7が受信バッファ部7に対してデータの読み出しを要求した時点にバッファ空状態が維持されていることを要する。それによってはじめて、再生時刻に遅延が生じるからである。上述した図4(A)の理想的なケースでも、例えば時刻t3に復号部8がデータP3の読み出しを要求すると、データP3は直ちに受信バッファ部7から読み出されるが、次のデータP4は少なくとも次の読み出し要求時刻t4までに受信バッファ部7に蓄積されていればよいから、最大で、ほぼ時間Tのあいだ、受信バッファ部7は空状態であってもよいことになる。したがって、このような単なるバッファ空状態と区別するために、前記遅延が積算され得るバッファ空状態を要求時バッファ空状態と呼ぶことにする。
【0018】
結局、この要求時バッファ空状態の発生は、音声の切断(途切れ)と遅延増加という、2つのデメリットをともなうことになる。
【0019】
このあと図3(B)では、当該時刻t4につづく時刻t5までに、受信パケットP4とP5がこの順番で受信バッファ部7に蓄積される。そして受信パケットP4は時刻t5に、受信パケットP5は時刻t6に、それぞれ読み出されて復号、再生されるが、パケットP6を通信網11内で紛失したため、時刻t7には受信パケットP7が受信バッファ部7に到着し、同時に読み出されて復号、再生されている。
【0020】
この様に、受信パケットP5の後に(受信パケットP6ではなく)受信パケットP7が再生されると、受信パケットP6のデータが欠落し、再生音には前記音飛びが発生してしまうが、その一方で、受信パケットP6の紛失は、これまでの遅延を解消して、受信パケットP7を定刻のt7に再生させるという利点ももたらす。
【0021】
より一般的には、受信パケットの紛失は、それまで積算されてきた遅延を減少させる利点と同時に、音飛びの発生という不利益をともなうということができる。
【0022】
図3(A)、(B)に示したようなジッタの影響を排除するための方法が、特開平7−306697号公報(文献1)、特開平7−334191号公報(文献2)、に示されている。
【0023】
更に、上述した受信パケットの紛失は“パケットロス”あるいは、“パケット損失”とも呼ばれ、ジッタ対策とパケットロス対策が、特開平10−285213号公報(文献3)に示されている。
【0024】
ところが、文献1に記載されたジッタ対策では、受信バッファ部7と復号部8の間に新たな手段を設け、本来廃棄されるべき受信パケットのなかから再生可能なフレームのみを抽出する。このため、原理的には、再生が終了したフレーム数やフレーム番号を、パケット通信が終了するまで連続カウントしなければならないが、長時間のパケット通信を行った場合、このカウント数は膨大になる。フレーム数のカウントには、専用の演算器が必要なだけでなく、前述した膨大な数値を記憶する装置が必須となるため、コストが著しく増加する可能性が高い。
【0025】
また、文献2では、復号部8と出力バッファ9との間に新たな処理部を設ける。受信パケットの遅刻によって生じた遅延を相殺するために、受信パケットを復号した後、時間軸圧縮という新たな手段を用いて受信パケット内の無音部を、先の遅延時間分、圧縮して出力する。この方法では、言うまでもなく時間軸圧縮手段を実現するための演算部が新たに必要となるが、時間軸圧縮の演算量が膨大なため、この演算部には非常に高い演算性能が要求される。これにより、装置コストが著しく増大する可能性が高い。
【0026】
同時にこの方法は、受信パケットの遅刻により受信バッファ部7が空になった場合のみを対象にしており、受信バッファ部7が空になって発生した遅延を記憶し、後に到着する受信パケットの再生音を圧縮して遅延分の時間を短縮しなければならない。したがってこの遅延を記憶する手段の新設、各再生音に対する圧縮割合の割り当て計算など、コストや演算量が更に増加する。
【0027】
最後に、文献3に記載されたジッタ対策とパケットロス対策では、有音部のみを符号化、送信する装置において、受信パケットの遅刻やパケットロスによって受信バッファ部7にデータが無くなった場合、従来のように、ダミーの1フレームを復号部に渡しつつ、次パケットの到着を待つのではなく、復号部にはダミーの1パケットを渡す。そしてこのダミーパケットを復号中に本来のパケットが到着しても、これを廃棄することで遅延の発生を防ぐ。
【0028】
この方法の場合、受信バッファの容量によって、ダミーパケットの挿入率が大幅に変動する。例えば、初期遅延の減少を目的に受信バッファを小さく設定すると、遅刻する受信パケットが増大してダミーパケットの挿入率が著しく増加し、激しい音質劣化をまねく。さらにこの文献3には、これほど重要な受信バッファの容量設定方法は一切記述されておらず、この方法による効果を得るには膨大な量の試行錯誤が必要となり、ただちに、期待通りの効果を実現することは困難であると考えられる。
【0029】
なお、文献1〜文献3に記載された技術に共通する特徴は、受信バッファに蓄積されている復号用データが無くなり、受信バッファが空状態になって初めて、ジッタ対策やパケットロス対策を開始する点にある。
【0030】
【課題を解決するための手段】
かかる課題を解決するために、第1の発明では、送信側から送信され、音声データを収容している通信パケットを、ネットワークを介して受信するパケット受信装置において、(1)受信した前記通信パケットを含むパケットを一時的に蓄積して待ち行列を形成する先入れ先出し形式のパケット蓄積手段と、(2)前記待ち行列の長さに関して読み出し開始用閾値の設定を受ける読み出し開始用閾値設定手段と、(3)前記待ち行列の長さが伸長して当該読み出し開始用閾値に達すると、前記パケット蓄積手段からパケットの読み出しを開始する第1の蓄積制御手段と、(4)前記待ち行列の長さに関して廃棄開始用閾値の設定を受ける廃棄開始用閾値設定手段と、(5)前記待ち行列の長さに関して廃棄終了用閾値の設定を受ける廃棄終了用閾値設定手段と、(6)前記待ち行列の長さが伸長して前記廃棄開始用閾値に達するたびに、当該待ち行列の長さを短縮し、短縮後の前記待ち行列の長さが前記廃棄終了用閾値に達するまで、当該待ち行列中で先頭から順番に、1または複数のパケットに廃棄処理を施す第2の蓄積制御手段とを備え、(7)前記読み出し開始用閾値を最も小さく設定し、前記廃棄開始用閾値を最も大きく設定し、前記廃棄終了用閾値を前記読み出し開始用閾値及び前記廃棄開始用閾値の中間値に設定することを特徴とする。
【0032】
【発明の実施の形態】
(A)実施形態
以下、本発明のパケット受信装置の実施形態について説明する。
【0033】
第1〜第3の実施形態に共通する特徴は、要求時バッファ空状態が発生する前にジッタ対策や遅延対策を実行する点にある。
【0034】
(A−1)第1の実施形態の構成
図14に本実施形態のパケット受信装置30の構成を示す。この受信装置30は、上述した図2中の受信装置21と同様に、送信装置20から送信され、パケット通信網11を伝送されてきた受信パケットを、時系列に受信する装置である。
【0035】
図14において、受信装置30は、受信端子6と、受信バッファ部7と、復号部8と、出力バッファ9と、出力端子10とを備えている。
【0036】
このうち構成要素6〜10の機能は、基本的に、対応する符号を付した図2の各部と同じである。
【0037】
ただし、本実施形態の受信バッファ部7は、図14に示すように、バッファ71と、バッファ制御部40と、間引き制御部72とを備えている。
【0038】
このうちバッファ71は、受信端子6でパケット通信網11から受信した受信パケットを一時的に蓄積するためのFIFOメモリであるが、少なくとも、符号化されて送信されたデータを記憶できればよく、例えば半導体メモリ、フラッシュメモリなどの記憶装置が使用できる。
【0039】
また、バッファ制御部40は、図1に示すような内部構成を備えている。
【0040】
(A−1−1)バッファ制御部の内部構成
図1において、バッファ制御部40は、キュー(待ち行列)長検出部41と、復号開始点設定部42と、比較部43と、読み出し制御部44とを備えている。
【0041】
キュー長検出部41は、バッファ71に蓄積されているパケット(このパケットは、本実施形態ではすべて受信パケットであるが、第2、第3の実施形態では受信パケット以外のパケットも混入され得る)によって形成されたキューの長さをリアルタイムで検出するための部分で、その検出結果としてのキュー長信号QLを、間引き制御部72内の判定部723と、比較部43に供給する。
【0042】
キューの長さは、通信開始時点ではゼロであるが、受信装置30が通信網11から受信した受信パケットを逐次、バッファ71に書き込むことによって、徐々に伸長する。
【0043】
また、復号開始点設定部42は復号開始点711の設定を受けて、当該復号開始点711の値(前記キュー上の位置)に応じた復号開始点信号DPを、比較部43に供給する部分である。
【0044】
比較部43は、キュー長信号QLと復号開始点信号DPを比較して、QLの値がDPの値を初めて上回ったときに、読み出し指示信号CRを読み出し制御部44に供給する部分である。
【0045】
この読み出し制御部44はバッファ71からのパケットの読み出しを制御する部分である。前記読み出し指示信号CRの供給を受けると、当該読み出し制御部44がバッファ71からのパケットの読み出しを開始し、以降は、復号部8から読み出し要求信号RRが供給されるたびに、1つずつパケットを読み出して行く。
【0046】
復号部8は直前に受け取ったパケットの復号処理が終了して次のパケットの復号処理を行うことができる状態になると読み出し要求信号RRを出力するから、各受信パケットの長さをほぼ一定とすると、定常的な通信状態においては、ほぼ一定の時間間隔で読み出し要求信号RRが出力され、一定の時間間隔でバッファ71からパケットが読み出されることになる。
【0047】
ただし読み出し制御部44は、間引き制御部72内の判定部723から廃棄候補読み出し指示信号DRを受け取ると、CRやRRの状態と無関係にバッファ71からパケットを読み出すことができる。DRによる読み出しは、後述する間引き開始点712との関係で、間引き、すなわち廃棄処理の対象となるパケットを選択するために行われるので、読み出し要求信号RRによる読み出しが1回実行される期間内に、複数回実行され得る。複数回実行されることにより、遅延の減少が可能になる。
【0048】
前記復号開始点711の役割は前記ジッタの影響を排除することにあるので、その値は、通信網11の混雑状態に依存して設定されることになる。
【0049】
例えば、通信網11が非常に空いている場合、各受信パケットは、およそ等間隔で受信されるため、復号開始点711はバッファ71の先頭から1パケット〜2パケット程度の浅い位置(すなわち小さな値)に設定すれば十分であり(バッファ71の先頭に近い位置を“浅い位置”、遠い位置を“深い位置”と表現する)、通信網11が完全に理想的な状態でジッタ無しの場合には、0パケット(バッファ71の先頭位置)としてもよい。
【0050】
つまり、パケットの到着間隔の変動(ジッタ)が1パケット〜2パケット分ならば、先頭から1パケット〜2パケット程度の浅い位置に復号開始点711を設定しても、バッファ71が空になることはないと言い換えることができる。バッファ71が空にならなければ、上述した要求時バッファ空状態が発生することもなく、音声の切断(途切れ)や遅延増加が生じない。
【0051】
また、パケット数は時間の尺度に換算することができるから、復号開始点711の位置も時間で表現することが可能である。例えば、1パケットが5フレームで構成され、1フレームのデータ長が0.01秒に相当する場合、1パケットに相当する時間は0.05秒(=0.01秒×5フレーム×1パケット)となり、2パケット分の時間は0.1秒(=0.01秒×5フレーム×2パケット)となる。したがって、前記復号開始点711を1パケット〜2パケット分に設定するということは、時間で表現すると、0.05秒〜0.1秒の時間位置に復号開始点711を設定することを意味する。
【0052】
同時にまた、復号開始点711をこの0.05秒〜0.1秒の時間位置に設定するということは、通信開始後、受信装置30が通信網11から受信パケットを受信してから、0.05秒〜0.1秒間は、音声出力が得られないことをも意味する。ただしここでは、復号部8や出力バッファ9などにおける処理に要する時間を無視している。
【0053】
逆に、通信網11が非常に混雑している場合には、各受信パケットのジッタが大きいため、復号開始点711を1パケット〜2パケット分に設定したのでは、すぐにバッファ71が空になり、要求時バッファ空状態が発生して音途切れ(切断)を招き、再生音質が劣化する。
【0054】
よって、この様な場合は、復号開始点711をバッファ71の先頭から5パケット、あるいは、10パケット程度の深い位置に設定する必要がある。
【0055】
しかし、復号開始点711の位置を深くするほど、通信開始から復号が始まって音声出力が得られるまでに長い時間を必要とするから、復号開始点711を例えば、バッファ71の先頭から5パケット、あるいは、10パケット程度の深い位置に設定した場合、通信開始から、前記0.05秒〜0.1秒よりも5倍から10倍も長い時間、音声出力が得られない。
【0056】
この通信開始時の遅延を初期遅延と呼ぶ。
【0057】
初期遅延も前記遅延の一種であり、通信評価を低下させる要因となるから、復号開始点711は、可能な限り浅い位置に設定するのが望ましい。
【0058】
このような特質を有する復号開始点711の設定に関して、本発明者は、通信網11のジッタ分布の幅に基づいて復号開始点711を設定するのがよいことを見出した。
【0059】
さらに、ジッタ分布の標準偏差をσとすると、復号開始点位置は、σ×3〜4の範囲内の位置に設定するのが、特に望ましいことも見出した。
【0060】
(A−1−2)σ×3〜4について
ジッタ分布に関する標準偏差σの係数の値としてこの3〜4が特に好ましいことは、図13によって裏付けられる。
【0061】
図13に示すように、受信バッファ71の枯渇率(前記バッファ空状態が発生する率)は、係数が3よりも大きいときには0に近いが、係数が3の近傍より小さくなると急激に上昇している。
【0062】
また、再生遅延(上述した遅延に対応する)は、係数が4よりも小さいときにはほぼ一定値を維持して十分に小さいが、係数が4の近傍より大きくなると上昇しはじめる。
【0063】
受信バッファ71の枯渇率が高いことも、再生遅延が大きいことも、出力端子10から出力される音声の品質を劣化させる要因であるため、枯渇率も再生遅延も十分に小さい係数値の範囲、すなわち係数が3〜4の範囲が、最も好ましいといえる。
【0064】
具体的には、通信網11のσが0.08秒の場合、復号開始点711は、0.24〜0.32秒の時間位置に設定するとよい。これにより、受信バッファ71に符号化データ(フレーム)が0.24〜0.32秒分蓄積するまで、バッファ制御部40は受信パケットの読み出しを行わず、復号部8にも、データは供給されない。
【0065】
一方、前記バッファ71には、前記復号開始点711のほかに、間引き開始点712が設定され、必要に応じて間引き終了点713も設定される。
【0066】
間引き開始点712は、前記復号開始点711と同様なキュー上の点であるが、上述した図3(A)、(B)で受信パケットP6が紛失したケースと同様な状態を意図的につくりだして、遅延を減少し解消することを目的としている。
【0067】
この間引き開始点712に関連した機能を持っているのが、前記間引き制御部72である。
【0068】
間引き制御部72は図14に示すように、判定部723と、切替えスイッチ721と、廃棄処理部722とを備えている。
【0069】
このうち判定部723は、前記バッファ制御部40内のキュー長検出部41から供給されるキュー長信号QLと、間引き開始点712の値を示す間引き開始点信号DSと間引き終了点713の値を示す間引き終了点信号DEとをもとに、切替えスイッチ721を制御する部分である。
【0070】
判定部723が切替えスイッチ721の廃棄処理部722側の接点721Aを選択した場合には、バッファ71から読み出されて判定部723に供給された受信パケットは、廃棄処理部722によって廃棄され、反対に復号部8側の接点721Bを選択した場合には、復号部8によって復号される。
【0071】
ただし判定部723は、この選択を行う際には、QL、DS、DEのほかに、バッファ71から読み出したパケットの符号化音声データ示す音声的な内容も参照して、そのパケットを廃棄してもよいかどうかを判定する。すなわち、後述するように、出力端子10から出力される音声の聴覚特性上、廃棄すると音質に与える影響が大きい受信パケットは廃棄せず、影響が小さい受信パケットは廃棄するものと判定する。
【0072】
これにより、パケットを廃棄しても上述した図3(A)、(B)でパケットP6が紛失したケースのように、再生音に音飛びが発生することがない。
【0073】
なお、この判定部723と、切替えスイッチ721、廃棄処理部722は、ソフトウエアや電気回路で構成することができる。
【0074】
また、前記間引き終了点713とは、間引き開始点712と同様なキュー上の点であって、間引き開始点712からはじまる間引き操作の終了位置を規定する点である。
【0075】
前記復号開始点711、間引き開始点712、および間引き終了点713は、バッファ71内に回路的に設けることもできるし、ソフトウエア上に条件式として設けることもできる。
【0076】
また、一般的に、復号開始点711と、間引き開始点712と、この間引き終了点713の値の大小関係は、次の式(1)のようになる。
【0077】
バッファ71の先頭位置≦復号開始点711≦間引き終了点713≦間引き開始点712 …(1)
この式(1)からも、間引き開始点712の位置は、復号開始点711と同じか、深い位置に設定する必要があることがわかる。ただし、間引き開始点712を必要以上に深い位置に設定すると、受信バッファ71のデータ蓄積量(キュー長)が間引き開始点712に、ほとんど達しないため、遅延減少という効果を得られなくなる可能性がある。
【0078】
また、間引き終了位置713は、間引き開始点712と同一にしたり、復号開始点711と同一にしたり、復号開始点711と間引き開始点712の間にしたりすることが可能で、式(1)には反するが、必要に応じて、復号開始点711より浅い位置に間引き終了点713を設定することも可能である。
【0079】
ただし、キュー長が間引き開始点712に達していったん間引き操作が開始されると、必ず間引き終了点713まで受信バッファ71のデータ蓄積量が減少するため、浅い位置に間引き終了点713を設定すると、比較的大きな遅延を短時間で解消することができる利点がある反面、受信バッファ71が空になる可能性が高くなる。受信バッファ71が空になった時に復号部8からデータを要求されると、前述した要求時バッファ空状態となり、音途切れが発生するため好ましくない。
【0080】
もしも、浅い位置に間引き終了点713を設定した状態で、前記音飛びを防止しようとすると、判定部723における判定の結果、廃棄することができないと認められたパケットを蓄積しておくためのバッファを、間引き制御部72内などに設ける必要が生じると考えられハードウエア量が増加してしまう。あるパケットに対する判定部723による前記判定(廃棄することができない旨の判定)が完結したとき、復号部8ではまだ、直前に読み出したパケットの復号を終了していない可能性があるからである。
【0081】
また、間引き終了点713を設定しない場合でも、判定部723に間引き操作によって対応しようとしている遅延の大きさに関する情報を供給することで、間引き操作が現実に発生している遅延の大きさを超えて行われることを防止することはできる。
【0082】
したがって間引き終了点713の設定は必ずしも必須ではないが、本実施形態では、間引き終了点713は設定するものとし、しかも間引き開始点712と同じ値に設定するものとした。
【0083】
間引き終了点713を間引き開始点712と同じ値にするということは、間引き開始点712からはじまって間引き終了点713で終わるまでの一度の間引き操作で減少することができる遅延の時間幅はほぼ1パケット分の時間幅に限定することを示す。通信網11による遅延が通常範囲であればこれでも十分に対応可能であると考えられる。
【0084】
また本実施形態では、上述したように間引き開始点712と間引き終了点713とを同じにするだけでなく、前記復号開始点711もこれらと一致させるものとする。すなわち、復号開始点711、間引き開始点712、間引き終了点713の3点の位置は全て同一点とする。しかも、これら3点に共通の位置CPは、上述したσ×3〜4の範囲に設定する。これは、例えば、σ×3.5の位置であってよい。これにより受信バッファ71が空になる可能性が非常に低く、かつ、遅延を、最低限にすることが可能となる。
【0085】
ところで、このように3点を一致させた場合、キュー長が3点の共通位置CPを上回ると、バッファ71から1パケット読み出され、その受信パケットがたまたま、廃棄すると音質に与える影響が大きいパケットであった場合には、その回の間引き操作では遅延を減少することができないが、同様な間引き操作を繰り返すことによって、定常的には遅延が低減または解消された状態を維持することができる。その回の間引き操作で遅延を減少できない場合、次回に受信した受信パケットが蓄積されると、キュー長は再び間引き開始点CPを超えて、再度、間引き操作を行うことができる可能性が高いからである。
【0086】
なお、判定部723は、受信パケットを構成する複数のフレームの各々について、廃棄すると音質に与える影響が大きいかどうかを判定することが可能なので、一度の間引き操作は1パケット分の複数フレームを対象とし、フレーム単位で廃棄するかどうかを判定して、フレーム単位で遅延を減少することも可能である。
【0087】
この場合、廃棄も復号も、パケット単位ではなくフレーム単位で行われることになる。
【0088】
また、切替えスイッチ721を介してこの判定部723に接続された前記復号部8は、受信した符号化音声データを復号して通常の音声データに変換する部分である。
【0089】
音声の符号化、復号方式は、例えば、線形PCM、ITU−T勧告のG.711(μ則PCM)、G.726(ADPCM)、G.723.1、G.729(CS−ACELP)といった方式や、CELP(Code Excited Linear Prediction:符号励振線形予測)符号化方式、リニアPCM方式などが利用でき、特に限定するものではない。
【0090】
ここで、符号化時の1フレームの時間は、符号化方式に依存している。例えば、上記のG.729方式では、1フレームが10ms(0.01秒)であり、G.723.1方式では、1フレームが30ms(0.03秒)である。また、1パケットに含まれるフレーム数(パケットサイズ、パケット長と呼ぶ)も様々あり、こちらは使用する装置によって任意に決定することができる。ただし、通常、符号化音声データを複数フレーム繁げたものに、通信方式固有の情報(ヘッダと呼ぶ)が付属して1つのパケットを構成するため、パケットサイズを小さくすると、遅延時間が少なくなるかわりに、より高速な通信速度を要求される。逆に、パケットサイズを大きくすると通信速度は低減できるが、パケットロス時の影響や、遅延時間が増加する傾向となる。
【0091】
また、前記出力バッファ9は、バッファ71と同様な記憶部で、復号部8から受け取った音声データを出力部10に出力する機能を持つ。
【0092】
以下、上記のような構成を有する本実施形態の動作について説明する。
【0093】
(A−2)第1の実施形態の動作
本実施形態の受信装置30の動作を、図5の動作フローに示す。図5の動作フローは、S1〜S10の各ステップから構成されている。ただし、この動作フローは、前記式(1)の等号が成立せず、復号開始点711と間引き終了点713と間引き開始点712がそれぞれ別個な点である場合や、これらが前記共通位置CPで一致したとしても、各受信パケットの長さが必ずしも一定でなく、廃棄や復号を、フレーム単位で行うかパケット単位で行うかを限定しないケースに広く対応可能な、普遍性のあるフローチャートとなっている。
【0094】
図5において、通信が開始されると受信バッファ71はパケットを順次受信(S1)し、蓄積する(S2)。このデータ蓄積量が復号開始点711を超えたところで、バッファ制御部40内の読み出し制御部44は、パケットの読み出しを開始し、受信バッファ71から、フレームのデータを順次取り出して復号処理していく。
【0095】
この様子を時間経過とともに示した図6(A)および(B)において、時刻t1には受信パケットP1だけがバッファ71内に蓄積されていて、キュー長(データ蓄積量)が復号開始点711に達していないため、バッファ71から当該受信パケットP1は読み出されない。
【0096】
時刻t1の次の時刻t2には、本来、遅くともt2までに蓄積されるはずのパケットP2が遅刻してまだ蓄積されていない。このため、キュー長は時刻t1と同じで、バッファ71からの受信パケットの読み出しは行われない。
【0097】
つづく時刻t3には、遅刻していた前記受信パケットP2が蓄積されてキュー長が伸長したが、それでもまだ、復号開始点711には達していない。そのため、バッファ71から受信パケットの読み出しは行われない。なお、本来、時刻t3までに蓄積されるはずの受信パケットP3は遅刻していてまだ蓄積されていない。
【0098】
一方で、t1〜t3の期間中、復号部8からの読み出し要求RRは読み出し制御部44に供給されつづけているが、キュー長が復号開始点711に達していないために、読み出し制御部44は、受信パケット(P1など)の読み出しを行うことができない状態にある。すなわちこの期間中、ステップS3の分岐は「待ち」側の選択を繰り返してステップS1〜S3のループが繰り返される。
【0099】
時刻t4には、遅刻していた受信パケットP3と後続の受信パケットP4がこの順番に蓄積される。このときの受信パケットP3の蓄積により、キュー長が復号開始点711を上回ったことが比較部43によって検出されて、読み出し制御部44ははじめて、当該読み出し要求RRに応えることができるようになり、ステップS3の「開始」側の分岐を選択する。これにより、最も先に蓄積されている前記受信パケットP1が読み出され、以降は、すでに蓄積されている受信パケットP2〜P3やこれから蓄積される受信パケット(図示せず)が順次、前記間隔Tごとに読み出される。
【0100】
ステップS3の「開始」側の分岐が選択されたことにより、処理は、ステップS6に進む。この手順は、普遍性に対応したものである。
【0101】
ステップS6に進んだあとも、通信網11の混雑状態などに応じて変動するペースでバッファ71中に受信パケットが蓄積されて行き、当該蓄積によってキュー長が伸長する。ステップS6以降のステップS4〜S10は、間引き制御部72によって実行される。
【0102】
間引き制御部72中の判定部723は、当該キュー長をバッファ制御部40内のキュー長検出部41から供給されるキュー長信号QLに基づいて認識し、間引き(パケット(フレーム)の廃棄)を行わない場合にはステップS6の「待ち」側の分岐を選択し、行う場合には「開始」側の分岐を選択する。
【0103】
「待ち」側の分岐が選択された場合、バッファ71から読み出されたパケットには復号処理が施される(S7)。
【0104】
通信網11の混雑状態が通常範囲で、キュー長の伸長速度も通常範囲である場合、このあとは、ステップS6、S7、S4、S5から構成されるループの実行が繰り返される。
【0105】
図6(A)および(B)はこのケースに該当し、時刻t4以降は、パケットP1〜P5の読み出しおよびその復号が繰り返されている。
【0106】
一方、通信網11の混雑状態が通常範囲でない場合には、キュー長の伸長速度も大きく変動し、キュー長が急速に伸長するときに、キュー長が間引き開始点信号DSによって指定される間引き開始点712を超えることがある。
【0107】
その場合、ステップS6は「開始」側に分岐して、読み出したばかりの受信パケットが、廃棄(間引き)することができるパケットであるかどうか調べられ、パケット(フレーム)の選択が行われる(S8)。当該受信パケットは、前記廃棄候補読み出し指示信号DRによって、廃棄候補として読み出されたものである。
【0108】
このステップS8では、上述したように、聴覚特性上、廃棄すると音質に与える影響が大きい受信パケット(あるいは1フレームデータ)は廃棄せず、影響が小さい受信パケットは廃棄することによって、廃棄候補のなかから、実際に廃棄する受信パケットが選択される。
【0109】
例えば、先のG.723.1やG.729の符号化方式で、無音圧縮機能を用いて作成したデータの場合、そのフレームデータ内に、このフレームが有音か、無音か、その中間かの情報が含まれている。この情報を用いて、無音とされたフレームを廃棄することで、発生していた遅延を違和感なく低減することができる。この方法では、フレームデータ自体に判定基準が挿入されているため、無音フレームが連続で6フレーム存在した場合、これら6フレーム全てを廃棄することも可能となる。
【0110】
また、この様な情報がフレームに含まれていない場合でも、例えば、直前に復号したフレームの音圧レベルを算出しておき、それが既定値以下ならば直前フレームを無音と判定して、次フレームを廃棄、その次のフレームを復号処理してもよい。一般的に、無音から有音への音圧レベル変化は劇的でないため、直前フレームが無音ならば、次フレームも無音と考えて差し支えない。この場合は、現フレームの廃棄判定に、直前のフレームが関与するため、無音フレームが連続して6フレーム存在した場合でも、廃棄できるのは1フレーム置きの3フレームとなる。
【0111】
このようなステップS8で廃棄可能と判定された廃棄候補は、廃棄処理部722によって廃棄処理され(S9)、廃棄不可と判定された廃棄候補は復号処理される(S7)。
【0112】
廃棄処理が行われた場合、当該廃棄処理によって、キュー長が間引き終了点713まで達したかどうかが調べられる(S10)。達していない場合には前記DRによる廃棄候補の読み出しが行われて、読み出されたフレームに対してステップS8、S9またはS7が繰り返される。
【0113】
廃棄処理によってキュー長が間引き終了点713に達した場合には、ステップS4、S5、S6、S7から構成されるループが繰り返されるようになり、バッファ71から間隔Tごとに1受信パケット(フレーム)を読み出して復号処理を行う状態に復帰する。そしてこのときには、キュー長は間引き終了点713より短くなっており、発生していた遅延は短縮されている。
【0114】
結局、復号開始点711を設定したことにより、パケット到着時刻にジッタが発生しても、音声は全く途切れることなく再生され、間引き操作によって、図7(A)、(B)に示すように、受信バッファ71の蓄積データ最後尾位置(すなわちキュー長)が浅いところ(短い状態)で安定している。これは受信したパケットが復号されるまでの待ち時間が減少したことを表わしており、言い換えれば遅延が減少したことになる。
【0115】
図7(A)および(B)は、縦軸にバッファ最後尾位置(キュー長)に対応するフレーム数を、横軸に通信開始からの経過時間を示している。図7(A)は間引き操作を行わない従来例に対応するもので、図7(B)は間引き操作を行う本実施形態に対応するものである。
【0116】
図7(B)では、間引き開始点と間引き終了点をともに28フレームの位置(前記共通位置CPに該当)に設定したケースである。この28フレームは、時間的には、上述したσ×3〜4に相当する値である。
【0117】
この図7(B)を同図(A)に比較すれば明らかなように、本実施形態のほうが、キュー長が短い位置で安定するように推移している。キュー長がゼロフレームとなるバッファ空状態の発生頻度は図7(B)のほうが多いが、バッファ空状態は必ずしも前記要求時バッファ空状態ではない。ここで重要な点は、間引き操作の内容(間引き開始点の位置や間引き終了点の位置など)に応じて、キュー長の変動をコントロールすることができることである。
【0118】
なお、復号開始後、パケットロスなどの影響により受信バッファ71が空になって要求時バッファ空状態の発生が予測される場合には、直前に復号したフレームの情報を模倣して作成したエラーフレームを復号部8に渡すようにするとよい。これにより、再生音声の途切れが緩和され、音質が改善される。
【0119】
(A−3)第1の実施形態の効果
本実施形態によれば、復号開始点の機能によってパケット到着時刻のジッタを吸収でき、途切れのない音声再生が可能となる。
【0120】
また、本実施形態では、間引き操作によって遅延を減少することができるとともに、パケット選択処理(S8)によって、本来、間引き操作で発生するはずの音飛びの発生を防止することもできるから、遅延を減少しながら音質も維持することが可能である。
【0121】
さらに、本実施形態の受信バッファ(図14の構成要素7)は、概ねソフトウエアで管理できるため、復号開始点や間引き開始点の設定はソフトウエアの追加で対処でき、その量は非常に少ない。したがって、復号開始点や間引き開始点などの導入が演算量や演算速度、あるいは、装置コストに与える影響は、最小限にとどめることができる。
【0122】
更に、復号開始判定(S3)や、間引き操作も、全てソフトウエア上の単純な比較演算のみで構成できるため、こちらも演算量の増加やコストの増加はほとんど発生せず、遅延時間の把握や、遅延短縮のための割り振り操作なども一切行うこと無く実現することも可能である。
【0123】
(B)第2の実施形態
以下では、本実施形態が第1の実施形態と相違する点についてのみ説明する。
【0124】
第1の実施形態では復号開始点を採用したことで、図6に示したように、通信開始から復号を始めるまで(すなわち時刻t0からt4まで)は、復号部8にデータを渡さないようにしたから、ジッタは吸収できるものの通信網の混雑状態に応じて通信開始時(受信パケットP1に対応する音声出力が行われる時点)の遅延、すなわち前記初期遅延が発生してしまうという問題がある。
【0125】
本実施形態は、この初期遅延の影響を低減することを目的とする。
【0126】
(B−1)第2の実施形態の構成および動作
図8に本実施形態のパケット受信装置50の構成を示す。この受信装置50は、第1の実施形態の受信装置30に対応する装置である。
【0127】
図8において、受信装置50は、受信端子6と、受信バッファ部7と、復号部8と、出力バッファ9と、出力端子10とを備えている。
【0128】
このうち構成要素6〜10の機能は、基本的に、対応する符号を付した図14の各部と同じである。
【0129】
また、受信バッファ部7内の構成要素71,711〜713、72、721〜723の機能も、対応する符号を付した図14の各部と同じである。
【0130】
したがって、本実施形態の受信装置50は、第1の実施形態の受信装置30に対して受信バッファ部7内に設けられた微少雑音データ生成部73を付加した構成を備えている。
【0131】
微少雑音データ生成部73は、電源投入直後、または、通信終了後に、バッファ71の先頭から復号開始点711まで微少雑音データ(ダミーフレームと呼ぶ)を蓄積する機能を備えている。
【0132】
この微少雑音データ生成部73の動作によって、本実施形態では、受信パケットとダミーフレームから、前記キューが形成されることになる。
【0133】
本実施形態の受信装置50の動作は、図9(A)および(B)に示す。
【0134】
微少雑音データ生成部73は、当該受信装置50の電源投入直後、または、前回の通信終了後にダミーデータDMを生成し復号開始点711までバッファ71に蓄積するので、今回の通信開始時(例えば時刻t0など)には、すでに3つのダミーフレームDM1〜DM3が蓄積されていることになる。DM1〜DM3が収容している音声データは、まったく同じ内容の微少雑音データであってよい。
【0135】
通信開始により、復号部8から読み出し要求RRが読み出し制御部44に供給されると、ただちに、キューの先頭に位置するダミーデータDM1が読み出されて復号され、当該t1以降は、DM2、DM3が順次に読み出されて復号されて行く。この期間、出力端子10からの音声出力は、微少雑音である。
【0136】
通信網11の混雑状態を、図6や図3と同じであるものとすると、通信網11から受信した受信パケットP1がバッファ71内で(ダミーデータDM3の上に)蓄積されるのは、時刻t1であるから、当該P1が読み出されて復号されるのは、時刻t4である。
【0137】
ただし、第1の実施形態では、通信網11の混雑状態によって受信パケットP2、P3などの後続の受信パケットの受信、蓄積が遅れた場合、受信パケットP1に対応した音声出力が開始される時点は前記時刻t4よりも遅れ得るが、本実施形態の場合には、受信パケットP1が時刻t1〜t4の期間内に受信されるかぎり当該受信パケットP1に対応する音声出力は、常に時刻t4に行うことができる。
【0138】
この時刻t4の時間位置は復号開始点711の位置に対応しているので、復号開始点711の位置を変更することによって、変更可能である。
【0139】
また、受信パケットP1が時刻t1〜t4の期間内に受信されないような通信網11の混雑状態が著しく劣悪なケースであっても、同じ混雑状態を前提とすれば、本実施形態の受信装置50の初期遅延は、第1の実施形態の受信装置30の初期遅延よりも、小さい。
【0140】
すなわち、第1の実施形態では通信網11の状態に応じて初期遅延が通信ごとに変化し得るが、本実施形態の初期遅延は、安定していて、なおかつ小さい。
【0141】
また、本実施形態では、通信開始直後(時刻t1)に出力端子10から微少雑音を出力することができ、受信装置50が動作を開始したことをユーザが音声出力をもとに確認することが可能なので、当該期間にまったく音声の出力が行われない第1の実施形態に比べると、ユーザに不安感を与えない点でも優れている。
【0142】
(B−2)第2の実施形態の効果
本実施形態によれば、第1の実施形態の効果と同等な効果を得ることができる。
【0143】
加えて、本実施形態によれば、より安定的で、より小さな初期遅延を得ることができる。
【0144】
(C)第3の実施形態
以下では、本実施形態が第1、第2の実施形態と相違する点についてのみ説明する。
【0145】
本実施形態は、時系列に受信される各受信パケットの受信時刻について、タイムアウト監視機能や順番監視機能を設けたことを特徴とする。
【0146】
(C−1)第3の実施形態の構成および動作
図10に本実施形態のパケット受信装置60の構成を示す。この受信装置60は、第1の実施形態の受信装置30に対応する装置である。
【0147】
当該受信装置60と受信装置30との関係は、第2の実施形態の受信装置50と受信装置30との関係とほぼ同じである。
【0148】
したがって本実施形態の受信装置60も、構成要素6〜10、および構成要素71,711〜713、72、721〜723を備えており、これら構成要素の機能は、対応する符号を付した第1の実施形態の構成要素の機能と基本的に同じである。
【0149】
すなわち、本実施形態の受信装置60が、第1の実施形態の受信装置30にパケット監視部80を付加した構成を備えている。
【0150】
受信端子6とバッファ71の入力端子のあいだに配置されたこのパケット監視部80は、図15に示す内部構成を備えている。
【0151】
(C−1−1)パケット監視部の内部構成
図15において、パケット監視部80は、タイムアウト監視部61と、順番監視部62と、エラーパケット生成部63と、受信パケット廃棄部64とを備えている。
【0152】
このうちタイムアウト監視部61は少なくとも時計機能を備えていて、タイムアウト時刻を算出し、各受信パケットが該当するタイムアウト時刻まえに受信されたかどうかを検出する部分である。時計機能とは通信開始からの経過時間を算出する機能であり、タイムアウト時刻とは、ジッタが無い場合の各受信パケットの到着時刻、すなわち前記定刻から、所定時間だけ遅れた時刻である。
【0153】
当該タイムアウト監視部61は、タイムアウト時刻までに受信されない受信パケットを検出すると、タイムアウトエラー信号TEを、受信パケット廃棄部64と、エラーパケット生成部63に供給する。ある受信パケットが該当するタイムアウト時刻までに受信されないケースには、パケットロスが発生した場合などが含まれ得る。
【0154】
このタイムアウト時刻を求めるために必要な定刻は、次の式(2)で記述することができる。
【0155】
Sn=nft[秒] …(2)
ここで、Snはn番目パケットのタイムアウト時刻、fはパケットサイズ、tは1フレームの時間である。
【0156】
また、前記順番監視部62は、通信網11から受信された受信パケットの順番が本来の順番通りでないことを検出する部分で、順番通りに受信されない受信パケットを検出すると、順番エラー信号SEを、受信パケット廃棄部64と、エラーパケット生成部63に供給する。順番監視部62も、必要に応じて、前記時計機能を装備する。
【0157】
受信パケットの順番が本来の順番通りでないケースには、受信パケットの順番が通信網11における伝送中に逆転した場合やパケットロスが発生した場合なども含まれ得る。
【0158】
タイムアウトエラー信号TEや順番エラー信号SEを受け取ると、エラーパケット生成部63は、所定のエラーパケットの生成と挿入を行う部分であり、受信パケット廃棄部64は、すでに生成され挿入されたエラーパケットに対応するパケットが、通信網11から受信された場合、当該受信パケットを廃棄する部分である。ここで、エラーパケットとは、前記ダミーフレーム(ダミーデータ)DMと同じ微少雑音の音声データを収容したフレームを1パケット分まとめたものである。
【0159】
エラーパケット生成部63の動作によって、本実施形態では、受信パケットとエラーパケットから、前記キューが形成されることになる。
【0160】
タイムアウト監視部61も順番監視部62も、受信パケットの受信状況が正常でない状態(受信異常状態)を検出する部分である点で同じであるが、ある受信パケットに関する受信異常状態は、タイムアウト監視部61と順番監視部62の双方で検出されることもあり得るし、どちらか一方だけで検出されることもあり得る。
【0161】
例えばある受信パケットのパケットロスが発生した場合、当該受信パケットは当然、タイムアウト時刻までに受信されないのでタイムアウト監視部61がタイムアウトエラー信号TEを出力するが、それとともに順番監視部62も、当該受信パケットより先に、本来は当該受信パケットの次に受信されるはずの受信パケットが受信されたことに基づいて、当該パケットロスを検出して順番エラー信号SEを出力することもあり得る。
【0162】
したがって、同一の受信パケットに対するタイムアウトエラー信号TEと順番エラー信号SEの双方が出力された場合、エラーパケット生成部63は、先に出力された信号だけに基づいて動作し、あとに出力された信号は無視するようにするとよい。
【0163】
また、この例からも明らかなように、タイムアウト監視部61、順番監視部62、受信パケット廃棄部64やエラーパケット生成部63が正常に動作するためには、通信網11から受信した受信パケットを識別することが必要となる。この識別には、受信パケットの持つパケット識別情報を用いることができる。
【0164】
パケット識別情報とは、送信側(例えば図2の送信装置20)が受信パケットに付け加えたもので、例えば、受信パケットのシーケンス番号(パケット番号)、受信パケットが送信された時刻や受信パケットが生成された時刻を示すタイムスタンプ情報などがある。
【0165】
パケット監視部80で監視するパケット番号やタイムアウト時間(時刻)、タイムスタンプ情報は受信パケットの欠落や、受信パケットの到着順の逆転を監視するのが目的であり、これらが検知できるものならば、いずれも利用できる。例えば、通信プロトコルの一種である、TCP/IP(TransmissionControl Protocol/Internet Protocol)のシーケンス番号情報や、UDP/IP(User Datagram Protocol/Internet Protocol)のRTP(Realtime Transport Protocol)におけるシーケンス番号やタイムスタンプ情報などが利用できる。
【0166】
具体的には、順番監視部62が、受信パケットのシーケンス番号を監視し、今回到着した受信パケットのシーケンス番号が、前回到着した受信パケットのシーケンス番号をインクリメントした値(すなわち、前回到着した受信パケットのシーケンス番号+1)でない場合は、パケットロス、あるいは、パケット到着順の逆転が発生したものと判定すること等が考えられる。
【0167】
また、前回到着した受信パケットのタイムスタンプが16時52分、今回到着した受信パケットのタイムスタンプが16時40分のような場合、今回パケットの方が前回パケットより先に送出されたにも関わらず、今回パケットの方が後に到着しているので、パケット到着順の逆転が発生したと判定することが可能である。
【0168】
上述した方法は、あくまで一例であり、これに限らず、独自の検知情報を各受信パケットに付加するようにしてもよいことは言うまでもない。
【0169】
本実施形態では、パケット監視部80が持つ機能を1つのユニットにまとめたが、全て、あるいは、部分的に機能を分けて複数のユニットとして構成してもよい。
【0170】
このような本実施形態の受信装置60の動作は、図12に示すようになる。
【0171】
図12において、通信開始と同時に、パケット監視部80の時計が動作を開始し、時刻t4のまえには、定刻がt3である受信パケットP3が(例えばパケットロスによる)順番エラーに該当することを検出する。この場合、受信パケットP2の次に受信パケットP4が受信されたことから、順番監視部62が受信パケットP3のパケットロスを検出したものである。
【0172】
この検出に応じて、当該定刻t4よりもまえに、順番監視部62から順番エラー信号SEが出力されると、エラーパケット生成部63はエラーパケットD3をバッファ71内に蓄積する。このときバッファ71内にはすでに定刻がt2の受信パケットP2が蓄積されているので、当該エラーパケットD3は、P2の上に蓄積されてキューの最後尾を形成する。
【0173】
図12(A)に示した時刻t0〜t9はバッファ71上の時刻であるので、バッファ71よりもパケット監視部80が速く動作することによって、当該パケット監視部80が、バッファ71上の時刻t4にバッファ71に到着した受信パケットP4をもとに受信パケットP3のパケットロスを検出して、バッファ71上の時刻t3にエラーパケットD3の蓄積を行うことは可能である。
【0174】
なお、当該エラーパケットD3の蓄積は、第2の実施形態のダミーフレーム(ダミーデータ)DMの蓄積と異なり、蓄積まえのキュー長と無関係に実行される。
【0175】
時刻t3にエラーパケットD3が蓄積されなければ、時刻t3に受信パケットP2が読み出されることによって、要求時バッファ空状態が発生し得るが、当該蓄積を行うことで、要求時バッファ空状態の発生を防止している。
【0176】
以降は、このエラーパケットD3に対応する復号および音声出力は、時刻t4に行われ、時刻t5には受信パケットP5のパケットロスに対応する動作でエラーパケット生成部63がエラーパケットD5を挿入し、受信パケットP6は遅刻して定刻t6には間に合わず、時刻t7に後続の受信パケットP7とともに蓄積されている。
【0177】
ただしこの受信パケットP6は、パケットロスではなく、(タイムアウト時刻まえの)単なる遅刻なので、P6に対応するエラーパケットの挿入は行われていない。
【0178】
結局、この期間の音声出力は図12(B)に示すように、パケットロスで紛失した受信パケットP3、P5に対応する時刻t4、t6のに部分で、エラーパケットD3、D5が挿入されているから、パケットロスが発生したにもかかわらず、音飛びも音切れもほとんどユーザに感得されず、音質は維持されている。
【0179】
図11(A)、(B)は、この図12(A)、(B)に対応する第1の実施形態の動作を示した図であり、まったく同じ通信状態、すなわち、受信パケットP3とP5がパケットロスによって紛失し、受信パケットP6が遅刻したときの動作を示している。
【0180】
第1の実施形態の音声出力では、図11(B)から明らかなように、時刻t4で明確な音飛びが発生し、時刻t5〜t7にわたる大きな音切れが発生している。
【0181】
したがって、同じ混雑状態の通信網11を前提とすると、本実施形態の受信装置60の音質のほうが、第1の実施形態の受信装置30の音質よりも良好となる。
【0182】
これは、本実施形態のほうが第1の実施形態よりも、要求時バッファ空状態の発生頻度が低いことと対応している。
【0183】
(C−2)第3の実施形態の効果
本実施形態によれば、第1の実施形態の効果と同等な効果を得ることができる。
【0184】
加えて、本実施形態では、音飛びや音切れの影響を低減することができるから、同じ通信状態における出力音声の品質は第1の実施形態よりも高い。
【0185】
(D)他の実施形態
なお、第3の実施形態では、パケット監視部80を、第1の実施形態の受信装置に装備したが、第2の実施形態の受信装置に装備することもできる。その場合、受信装置は、微少雑音データ生成部73の機能と、パケット監視部80の機能の双方を装備することになる。
【0186】
また、第3の実施形態では、パケット監視部80は、タイムアウト監視部61と順番監視部62の双方を装備していたが、どちらか一方だけを装備するようにしてもよい。
【0187】
さらに、第2の実施形態では、ダミーデータDMに微少雑音の音声データを収容するようにしたが、ダミーデータDMを蓄積する主たる目的は、初期遅延を安定化し、小さくすることであるから、微少雑音以外の音声データをダミーデータに収容するようにしてもよい。
【0188】
第1〜第3の実施形態で示した構成図や動作フローは、本発明の一実施形態を示しているにすぎない。よって、本発明は、図示した構成、図示した動作フロー以外にも広く適用することができる。
【0189】
図示した構成や動作フロー以外でも、前述した機能を有した要素が含まれていれば、それ以外の機能を持つ要素を含んでいても同様な効果が得られる。
【0190】
例えば、図5の動作フローは、図示のもの以外にも変形や改良が可能である。
【0191】
図5のステップS4〜S7によって構成されたループは、バッファ71に新たなパケットが蓄積されるたびに繰り返され、非常に繰り返し回数の多いループであるから、そのループ内部の処理数を削減したり、ループを展開してループの繰り返し回数を低減することは、プログラムの処理量の低減、実行速度の向上に大きく寄与すると考えられる。
【0192】
図5のフローチャートの普遍性を排除して、例えば、式(1)の等号が成立する場合に対応して共通位置CPを装備し、なおかつパケット単位の処理と各受信パケットの長さがほぼ一定であることを前提とするなら、当該フローチャートを極めて簡略化することが可能である。
【0193】
簡略化したフローチャートは、例えば、図5のフローチャートからステップS1〜S3を削除するとともに、ステップS6の処理をキュー長が共通位置CPに達したかどうかを調べるテストに置換し、ステップS4からスタートする構造になる。
【0194】
簡略化した場合でも、キュー長が共通位置CPを超えた直後に読み出された受信パケットは、廃棄するか復号するかを決めるために、必ず、ステップS8のテストを受けることになるが、1受信パケットを廃棄できればキュー長が前記共通位置CPを下回ることは明らかなので、ステップS10のテストは省略することが可能である。
【0195】
すなわち、キュー長が共通位置CPに達したら、必ず1受信パケットを読み出し、当該1受信パケットだけをステップS8のテスト結果に応じて復号または廃棄すれば、簡略化したフローチャート内の処理が一巡したことになる。ただし当該1受信パケットの読み出しは前記DRによって行われたものなので、当該1受信パケットを廃棄した場合には、当該間隔T内にもう一度、前記RRによる読み出しを実行することができる。
【0196】
このような簡略化したフローチャートを用いた場合、バッファ71のキュー長の制御精度は低下する可能性があるが、プログラムの実行速度は向上し、処理能力にかかる負荷は軽減できる。
【0197】
また、第1の実施形態では、復号開始点711と間引き開始点712の双方を搭載したが、本発明は、復号開始点711または間引き開始点712のいずれか一方だけを搭載するようにしてもよい。
【0198】
さらに、第1の実施形態では、判定部723は、QL、DS、DEのほかに、バッファ71から読み出したパケットの符号化音声データ示す音声的な内容も参照して、そのパケットを廃棄してもよいかどうかを判定するものとしたが、本発明では、当該音声的な内容の参照は必須ではない。
【0199】
音声的な内容を参照しない場合でも、ジッタの影響を減少することは可能だからである。
【0200】
【発明の効果】
以上に説明したように、第1の発明では、待ち行列の長さが読み出し開始用閾値に達したときに、パケット蓄積手段からパケットの読み出しを開始するようにしたので、通信パケットのジッタの影響を低減することが可能である。
【図面の簡単な説明】
【図1】第1の実施形態に係るパケット受信装置の主要部の概略構成を示すブロック図である。
【図2】従来および第1〜第3の実施形態の音声送受信システムの全体構成を示す概略図である。
【図3】従来のパケット受信装置の動作説明図である。
【図4】従来のパケット受信装置の動作説明図である。
【図5】第1〜第3の実施形態のパケット受信装置の動作説明図である。
【図6】第1の実施形態のパケット受信装置の動作説明図である。
【図7】第1の実施形態の動作説明図である。
【図8】第2の実施形態のパケット受信装置の構成を示す概略図である。
【図9】第2の実施形態の動作説明図である。
【図10】第3の実施形態のパケット受信装置の構成を示す概略図である。
【図11】第3の実施形態と比較するための、第1の実施形態の動作説明図である。
【図12】第3の実施形態の動作説明図である。
【図13】数値範囲σ×3〜4が特に好ましいことを裏付ける概略図である。
【図14】第1の実施形態のパケット受信装置の構成を示す概略図である。
【図15】第3の実施形態に係るパケット受信装置の主要部の概略構成を示すブロック図である。
【符号の説明】
7…受信バッファ部、11…パケット通信網、20…パケット送信装置、21,30,50,60…パケット受信装置、40…バッファ制御部、41…キュー長検出部、42…復号開始点設定部、43…比較部、44…読み出し制御部、71…バッファ、72…間引き制御部、80…パケット監視部、711…復号開始点、712…間引き開始点、723…間引き終了点、721…切替えスイッチ、722…廃棄処理部、723…判定部。
Claims (4)
- 送信側から送信され、音声データを収容している通信パケットを、ネットワークを介して受信するパケット受信装置において、
受信した前記通信パケットを含むパケットを一時的に蓄積して待ち行列を形成する先入れ先出し形式のパケット蓄積手段と、
前記待ち行列の長さに関して読み出し開始用閾値の設定を受ける読み出し開始用閾値設定手段と、
前記待ち行列の長さが伸長して当該読み出し開始用閾値に達すると、前記パケット蓄積手段からパケットの読み出しを開始する第1の蓄積制御手段と、
前記待ち行列の長さに関して廃棄開始用閾値の設定を受ける廃棄開始用閾値設定手段と、
前記待ち行列の長さに関して廃棄終了用閾値の設定を受ける廃棄終了用閾値設定手段と、
前記待ち行列の長さが伸長して前記廃棄開始用閾値に達するたびに、当該待ち行列の長さを短縮し、短縮後の前記待ち行列の長さが前記廃棄終了用閾値に達するまで、当該待ち行列中で先頭から順番に、1または複数のパケットに廃棄処理を施す第2の蓄積制御手段とを備え、
前記読み出し開始用閾値を最も小さく設定し、前記廃棄開始用閾値を最も大きく設定し、前記廃棄終了用閾値を前記読み出し開始用閾値及び前記廃棄開始用閾値の中間値に設定すると共に、前記読み出し開始用閾値を、前記通信パケットの受信時刻のジッタに関する標準偏差の3倍から4倍の範囲に相当する待ち行列の長さに設定する
ことを特徴とするパケット受信装置。 - 請求項1のパケット受信装置において、
前記第2の蓄積制御手段の廃棄処理に際して、前記通信パケットについては収容している音声データの内容に応じて廃棄処理を施すか否かを決定する廃棄パケット選択手段を備えることを特徴とするパケット受信装置。 - 請求項1のパケット受信装置において、
前記通信パケットが受信される前に、前記パケット蓄積手段に対して、微少雑音の音声データを収容したダミーパケットを蓄積しておくダミーパケット生成手段を備えたことを特徴とするパケット受信装置。 - 請求項1〜3のいずれかのパケット受信装置において、
時系列に受信される前記各通信パケットについて、受信スケジュールの遅延限界を示す受信限界時刻を設定する受信限界時刻設定手段と、
前記各通信パケットが対応する当該受信限界時刻までに受信されなかった場合、所定のエラーパケットを前記パケット蓄積手段に蓄積するエラーパケット生成手段と、
対応する受信限界時刻以降に受信された通信パケットを廃棄する遅延パケット廃棄手段とを備えたことを特徴とするパケット受信装置。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000085744A JP3891755B2 (ja) | 2000-03-27 | 2000-03-27 | パケット受信装置 |
US09/703,792 US7349330B1 (en) | 2000-03-27 | 2000-11-02 | Packet receiver with the influence of jitter and packet losses reduced before a buffer becomes idle due to data delays and packet receiving method using the same |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000085744A JP3891755B2 (ja) | 2000-03-27 | 2000-03-27 | パケット受信装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2001274829A JP2001274829A (ja) | 2001-10-05 |
JP3891755B2 true JP3891755B2 (ja) | 2007-03-14 |
Family
ID=18602023
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000085744A Expired - Fee Related JP3891755B2 (ja) | 2000-03-27 | 2000-03-27 | パケット受信装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US7349330B1 (ja) |
JP (1) | JP3891755B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11435735B2 (en) * | 2017-03-30 | 2022-09-06 | Toshiba Mitsubishi-Electric Industrial Systems Corporation | Playback simulation test system |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3825007B2 (ja) | 2003-03-11 | 2006-09-20 | 沖電気工業株式会社 | ジッタバッファの制御方法 |
JP4272033B2 (ja) * | 2003-10-30 | 2009-06-03 | 富士通株式会社 | データ再生装置 |
US20070223660A1 (en) * | 2004-04-09 | 2007-09-27 | Hiroaki Dei | Audio Communication Method And Device |
JP4318651B2 (ja) | 2005-02-25 | 2009-08-26 | 富士通株式会社 | 出力方法、出力装置及び通信システム |
WO2007051495A1 (en) * | 2005-11-07 | 2007-05-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement in a mobile telecommunication network |
JP4842075B2 (ja) * | 2006-09-28 | 2011-12-21 | 京セラ株式会社 | 音声伝送装置 |
JP5112447B2 (ja) * | 2006-12-08 | 2013-01-09 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 通信ネットワーク環境におけるアナウンスメディアの処理 |
US7733785B2 (en) * | 2007-01-31 | 2010-06-08 | International Business Machines Corporation | Method and system for dynamically adjusting packet size to decrease delays of streaming data transmissions on noisy transmission lines |
EP2159976A4 (en) | 2007-05-21 | 2014-03-12 | Fujitsu Ltd | RELAY DEVICE AND RELAY METHOD |
JP2010232706A (ja) * | 2007-07-26 | 2010-10-14 | Media Global Links:Kk | 再送パラメータ自動計算アルゴリズム、およびそのシステム |
JP5092877B2 (ja) * | 2008-04-30 | 2012-12-05 | ブラザー工業株式会社 | ツリー型放送システム、パケット送信方法、ノード装置、及びノード処理プログラム |
JP2009290297A (ja) * | 2008-05-27 | 2009-12-10 | Fujitsu Ltd | 通信装置および通信装置の制御方法 |
JP4675409B2 (ja) * | 2008-12-08 | 2011-04-20 | 富士通株式会社 | 出力装置及び通信システム |
US7953004B2 (en) * | 2009-01-06 | 2011-05-31 | Alcatel Lucent | Minimizing effects of packet delay variation in time-division multiplexing pseudowire services |
US9386128B2 (en) * | 2012-03-23 | 2016-07-05 | Qualcomm Incorporated | Delay based active queue management for uplink traffic in user equipment |
KR20140070896A (ko) * | 2012-11-29 | 2014-06-11 | 삼성전자주식회사 | 비디오 스트리밍 방법 및 그 전자 장치 |
WO2014191966A1 (en) | 2013-05-31 | 2014-12-04 | Stmicroelectronics S.R.L. | Communication interface for interfacing a transmission circuit with an interconnection network, and corresponding system and integrated circuit |
US20150256613A1 (en) * | 2014-03-10 | 2015-09-10 | JamKazam, Inc. | Distributed Metronome For Interactive Music Systems |
CN111711650B (zh) * | 2020-04-17 | 2022-07-12 | 北京奇艺世纪科技有限公司 | 网络请求的调度方法、装置、设备及存储介质 |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3475152D1 (en) * | 1984-05-23 | 1988-12-15 | Ibm | Buffer device used in a voice transmission network |
GB2166320B (en) * | 1984-10-25 | 1988-10-12 | Stc Plc | Packet switching system |
JPS62232691A (ja) * | 1986-04-03 | 1987-10-13 | 株式会社リコー | 音声認識装置 |
JPS6429141A (en) | 1987-07-24 | 1989-01-31 | Nec Corp | Packet exchange system |
EP0308565B1 (en) * | 1987-09-23 | 1993-02-10 | International Business Machines Corporation | Improvement to digital packet switching networks |
JPH01175432A (ja) | 1987-12-29 | 1989-07-11 | Nec Corp | パケット交換の遅延差吸収方式 |
JP2692104B2 (ja) * | 1988-02-12 | 1997-12-17 | 株式会社日立製作所 | 音声多重化システム |
US5231633A (en) | 1990-07-11 | 1993-07-27 | Codex Corporation | Method for prioritizing, selectively discarding, and multiplexing differing traffic type fast packets |
JP3240824B2 (ja) | 1994-05-12 | 2001-12-25 | 日本電信電話株式会社 | 欠落音声補間方法 |
JP3240832B2 (ja) | 1994-06-06 | 2001-12-25 | 日本電信電話株式会社 | パケット音声復号方法 |
US5813025A (en) * | 1994-08-10 | 1998-09-22 | Unisys Corporation | System and method for providing variable sector-format operation to a disk access system |
US5659541A (en) * | 1995-07-12 | 1997-08-19 | Lucent Technologies Inc. | Reducing delay in packetized voice |
JP3315588B2 (ja) * | 1996-05-16 | 2002-08-19 | 株式会社日立製作所 | トラヒック流量制御を行うatm交換機 |
GB9614985D0 (en) * | 1996-07-17 | 1996-09-04 | Newbridge Networks Corp | Variation fluctuation smoothing for ATM circuit emulation |
JPH10285213A (ja) | 1997-04-07 | 1998-10-23 | Nippon Telegr & Teleph Corp <Ntt> | 無音圧縮音声パケット送受信装置 |
JPH1132055A (ja) * | 1997-07-14 | 1999-02-02 | Fujitsu Ltd | バッファ制御装置及びバッファ制御方法 |
US6253207B1 (en) * | 1997-09-25 | 2001-06-26 | Lucent Technologies Inc. | Method and apparatus for transporting multimedia information over heterogeneous wide area networks |
US6091709A (en) * | 1997-11-25 | 2000-07-18 | International Business Machines Corporation | Quality of service management for packet switched networks |
JP3075246B2 (ja) | 1998-01-26 | 2000-08-14 | 日本電気株式会社 | 音声パケット送受信方法および装置 |
US6219339B1 (en) * | 1998-02-20 | 2001-04-17 | Lucent Technologies Inc. | Method and apparatus for selectively discarding packets |
US6389032B1 (en) * | 1999-02-11 | 2002-05-14 | International Business Machines Corporation | Internet voice transmission |
GB9909436D0 (en) * | 1999-04-23 | 1999-06-23 | Pact | Routing device |
US6658027B1 (en) * | 1999-08-16 | 2003-12-02 | Nortel Networks Limited | Jitter buffer management |
-
2000
- 2000-03-27 JP JP2000085744A patent/JP3891755B2/ja not_active Expired - Fee Related
- 2000-11-02 US US09/703,792 patent/US7349330B1/en not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11435735B2 (en) * | 2017-03-30 | 2022-09-06 | Toshiba Mitsubishi-Electric Industrial Systems Corporation | Playback simulation test system |
Also Published As
Publication number | Publication date |
---|---|
JP2001274829A (ja) | 2001-10-05 |
US7349330B1 (en) | 2008-03-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3891755B2 (ja) | パケット受信装置 | |
JP4146489B2 (ja) | 音声パケット再生方法、音声パケット再生装置、音声パケット再生プログラム、記録媒体 | |
US20020026310A1 (en) | Real-time information receiving apparatus | |
EP2936770B1 (en) | Apparatus and methods for controlling jitter buffer | |
US7450601B2 (en) | Method and communication apparatus for controlling a jitter buffer | |
CN107534589B (zh) | 去抖动缓冲器更新 | |
JP2005269632A (ja) | 通信端末装置、電話データ受信方法、通信システムおよびゲートウェイ | |
EP1694029A1 (en) | Method and apparatus for handling network jitter in a voice-over IP communication network using a virtual jittter buffer and time scale modification | |
JP4661373B2 (ja) | 特定メディアデータの破棄を制御する送信装置及び送信プログラム | |
US6885659B2 (en) | Voice packet communications system with communications quality evaluation function | |
KR20070058170A (ko) | 음성/데이터 통합 시스템의 패킷 처리 방법 및 그 장치 | |
KR101516113B1 (ko) | 음성 복호 장치 | |
JP3075246B2 (ja) | 音声パケット送受信方法および装置 | |
EP1826959A1 (en) | Apparatus for absorbing fluctuations in the packet transmission rate of a communications network | |
JP2004214755A (ja) | 動的符号化レート変更方法及びその装置 | |
JP4454255B2 (ja) | 音声/fax通信システム、音声/fax受信装置および揺らぎ吸収バッファ量制御方法 | |
US7903688B2 (en) | VoIP encoded packet prioritization done per packet in an IP communications network | |
JP4457033B2 (ja) | ファクシミリ信号伝送装置 | |
JP4376681B2 (ja) | 音声データ受信装置および音声データ送信装置 | |
JP4983054B2 (ja) | サーバ装置及び同装置におけるバッファ制御方法 | |
JP4093174B2 (ja) | 受信装置および方法 | |
JP4457841B2 (ja) | 符号化レートを制御する送信装置、送信プログラム及び送信方法 | |
JP3172774B2 (ja) | 音声の無音抑圧可変制御装置 | |
JPS63257367A (ja) | 音声パケツト通信方法 | |
JP2008311887A (ja) | 音声信号受信装置、音声信号通信装置および音声信号受信方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041122 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060522 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060530 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060725 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060905 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061106 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20061109 |
|
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: 20061205 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061205 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091215 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101215 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101215 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111215 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111215 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121215 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131215 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |