JP3694451B2 - ゲートウェイおよびデータ転送方法 - Google Patents
ゲートウェイおよびデータ転送方法 Download PDFInfo
- Publication number
- JP3694451B2 JP3694451B2 JP2000285900A JP2000285900A JP3694451B2 JP 3694451 B2 JP3694451 B2 JP 3694451B2 JP 2000285900 A JP2000285900 A JP 2000285900A JP 2000285900 A JP2000285900 A JP 2000285900A JP 3694451 B2 JP3694451 B2 JP 3694451B2
- Authority
- JP
- Japan
- Prior art keywords
- time
- network
- unit
- data unit
- data
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、データ伝送における遅延ジッタが存在するネットワークと、他のネットワークとを接続するゲートウェイおよびそのためのデータ転送方法に関する。
【０００２】
【従来の技術】
プロトコルおよびネットワーク特性の異なる異種ネットワークに接続された各端末間でのマルチメディア通信を行うために、ゲートウェイは不可欠な部材である。このゲートウェイは、送信元端末が属するネットワークのプロトコルに従ったデータを受信し、送信先端末が属するネットワークのプロトコルに従ってこのデータを送信する。これにより、送信元端末から送信されたデータは、その送信元端末が属するネットワーク、ゲートウェイ、および送信先端末の属するネットワークを通過することになる。
【０００３】
マルチメディアのために、インターネットのようなパケット交換網ではＩＴＵ−Ｔ勧告Ｈ．３２３に準拠した端末が用いられており、ＰＳＴＮ（public switched telephone network）のような回線交換網ではＩＴＵ−Ｔ勧告Ｈ．３２４に準拠した端末が用いられている。勧告Ｈ．３２３とＨ．３２４では、使用されている通信プロトコルが異なるため（勧告Ｈ．３２３ではＲＴＰ／ＵＤＰ、勧告Ｈ．３２４では勧告Ｈ．２２３で規定する多重送信プロトコル）、相互接続にはゲートウェイにおいてプロトコルの変換が必要になる。さらにまた、高品質のマルチメディア通信を実現するには、遅延、遅延ジッタおよびエラー特性のようなネットワーク特性の相違を補償することが必要である。
【０００４】
【発明が解決しようとする課題】
ネットワークでは、様々な要因によってデータ伝送に関する遅延が生じ、各データユニットの遅延が異なる場合がある。このような伝送遅延のゆらぎを遅延ジッタという。遅延ジッタの発生要因としては、例えば、パケット交換網での蓄積交換、経路上のノードにおける待ち合わせ、あるいは、各データユニットが異なる経路を経てゲートウェイに到着する事実がある。
【０００５】
回線交換網においても、異なる形式のデータを同時に伝送することにより遅延ジッタが生ずる。例えば、テレビ電話のようなマルチメディア端末は、一つのビットストリームに画像、音声および／またはアプリケーションデータを多重する。このような場合においては、すぐに送信されるデータもあれば、現在送信中のデータの送信完了まで送信されないデータもある。この種の遅延ジッタは端末でもゲートウェイでも起こり、送信速度が低いほど大きくなる。
【０００６】
遅延ジッタが発生すると、送信元端末でのデータユニットの時間間隔が、送信先端末においては保たれない。例えば音声のような精確な同期の必要性が高いデータを送信する際には、このような遅延ジッタを解消できることが望ましい。
遅延ジッタを解消するために、通信端末にはある程度の遅延ジッタを吸収するものがある。例えば、ある通信端末は、様々な遅延時間で受信したデータユニットをいったん記憶し、一連のデータユニットが蓄積されてからそれらを連続して出力する。しかしながら、ネットワークによって遅延ジッタの発生要因や特性が異なるので、送信先となりうる通信端末に受信されるデータの遅延ジッタが、どの程度大きいのかをあらかじめ知ることは困難である。従って、送信先の端末で許容される遅延ジッタは、その端末の属するネットワークにおいて発生しうる最大の遅延ジッタに基づいている場合が多い。このため、エンド・トゥ・エンドの遅延が増加することになり、この遅延はリアルタイム通信では深刻な問題となりうる。
【０００７】
本発明は、ジッタを削減することにより、遅延の増加を最小限にすることのできるゲートウェイおよびデータ転送方法を提供する。
【０００８】
【課題を解決するための手段】
本発明の一つの態様によれば、二つのネットワークを接続するゲートウェイが、
少なくとも一つの形式の複数のデータユニットを第１のネットワークから受信する受信部と、
前記受信部で受信した前記データユニットを一時的に記憶し、送信先端末の遅延ジッタ削減能力に基づいてある時間を決定し、前記受信部において先頭のデータユニットを受信した時刻からその決定した時間が経過した後に前記先頭のデータユニットを出力し、その後、前記第１のネットワークにおける送信サイクルと同じサイクルで後続のデータユニットを順次出力する制御部と、
前記制御部で出力されたデータユニットに対応するデータユニットを前記送信先端末に届けるために第２のネットワークに送信する送信部とを備える。
本発明において、ゲートウェイには第１および第２のネットワークが接続されている。送信先端末は、第２のネットワークに直接的に奉仕されてもよい。あるいは、送信先端末は、第２のネットワークに間接的に奉仕されてもよい。つまり、送信先端末と第２のネットワークとの間に、一つまたは複数のネットワークと、これらの隣合うネットワーク相互を接続する他のゲートウェイが介在していてもよい。
好ましくは、このゲートウェイは、前記送信先端末の遅延ジッタ削減能力に関する情報を獲得するジッタ削減能力獲得部をさらに備えるとよい。
【００１０】
好ましくは、前記受信部は、異なる形式のデータユニットを受信することが可能であり、異なる形式のデータユニットが同時に未送信である時に、前記制御部は、前記第１のネットワークにおいて前記データユニットが伝送される際に生じた遅延時間に応じて前記送信部における優先度を決定してもよい。この場合、前記送信部は、前記制御部から出力された異なる形式のデータユニットを、前記優先度に従って多重化して前記第２のネットワークを通じて前記送信先端末に送信するようにしてもよい。
【００１１】
好ましくは、前記制御部は、各形式における最初のデータユニットが前記制御部から出力された最初出力時刻を検出する出力時刻検出部と、前記最初出力時刻に基づいて、各形式における最初のデータユニットに対する各データユニットの前記遅延時間を算出する遅延時間算出部とを備えてもよい。この場合、前記制御部は、算出された前記遅延時間が長いと判定されたデータユニットについては、他のデータユニットに優先して送信するように前記送信部を制御するようにしてもよい。
【００１２】
前記制御部は、前記第１のネットワークにおいて前記データユニットが伝送される際に生じうる最大遅延時間を、前記送信先端末において許容される遅延ジッタに応じて短縮して前記時間を求めるようにしてもよい。
【００１３】
本発明の他の一つの態様によれば、データ転送方法が、少なくとも一つの形式の複数のデータユニットを第１のネットワークから受信することと、前記データユニットを一時的に記憶することと、あらかじめ獲得した送信先端末のジッタ削減能力に基づいてある時間を決定することと、先頭のデータユニットを受信した時刻からその決定した時間が経過した後に前記先頭のデータユニットを出力することと、前記第１のネットワークにおける送信サイクルと同じサイクルで後続のデータユニットを順次出力すること、前記データユニットに対応するデータユニットを前記送信先端末に届けるために第２のネットワークに送信することとを備える。
【００１４】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明に係る一つの実施の形態について説明する。
図１に示すように、本発明に係る実施形態では、ゲートウェイ１０が網２０と網３０とを相互接続しており、これにより網２０に奉仕される送信元端末からデータが網３０に奉仕される送信先端末に送信され、逆に、網３０に奉仕される送信元端末からデータが網２０に奉仕される送信先端末に送信される。網２０、３０はそれぞれ多数の端末に奉仕するが、図１では、便宜上、網２０に奉仕される端末２１と、網３０に奉仕される端末３１のみが描かれている。両方の網１０および２０においては、少なくとも一つの形式のデータユニットが交換される。
【００１５】
この実施形態では、網２０は、データユニットがパケットに含められて送受信されるパケット交換網であり、網３０はフレームとしてデータユニットが送受信される回線交換網である。フレームには、例えば音声データフレームや画像データフレームが含まれる。ただし、本発明をこれに限定する意図ではなく、変更・修正が可能である。網２０または３０は、移動網であってもよいし、固定網であってもよい。
【００１６】
ゲートウェイ１０は、網２０のための網インターフェイス１２と、網３０のための網インターフェイス１３と、網２０から網３０へデータを伝送する伝送系列ＡＢと、網３０から網２０へデータを伝送する伝送系列ＢＡを備えている。
伝送系列ＡＢは、受信部１４Ａ、プロトコル・エンティティ１５Ａ、メディア変換符号化部１６、プロトコル・エンティティ１７Ｂ、送信部１８Ｂ、および制御部１００を備えており、伝送系列ＢＡは、受信部１４Ｂ、プロトコル・エンティティ１５Ｂ、メディア変換符号化部１６、プロトコル・エンティティ１７Ａ、送信部１８Ａ、および制御部１００を備えている。
【００１７】
受信部１４Ａは、網２０から網インターフェイス１２を介してビットストリームを受信する。このビットストリームには、網２０に奉仕される送信元端末（例えば端末２１）で作成された少なくとも一つの形式の複数のデータユニット（パケット）が含まれうる。一方、受信部１４Ｂは、網３０から網インターフェイス１３を介してビットストリームを受信する。このビットストリームには、網３０に奉仕される送信元端末（例えば端末３１）で作成された少なくとも一つの形式の複数のデータユニット（フレーム）が含まれうる。
【００１８】
プロトコル・エンティティ１５Ａは、網２０において使用されるプロトコルにとって終端であり、各パケットからペイロード情報やその関連情報を取り出す。ＲＴＰ／ＵＤＰが通信プロトコルとして使われるのであれば、関連情報には、データタイプ、タイムスタンプ（送信時間）、シーケンスナンバーその他が含まれる。同様に、プロトコル・エンティティ１５Ｂは網３０において使用されるプロトコルにとって終端である。
【００１９】
メディア変換符号化部１６は、必要に応じて、音声や画像の符号変換を行うものであり、例えば、網２０と網３０で用いられている音声もしくは画像符号体系が異なる場合に符号変換を行う。
【００２０】
制御部１００は、バッファ１１０を備えており、バッファはプロトコル・エンティティ１５Ａまたは１５Ｂから入力されるデータユニットをバッファリングする。制御部１００は、予め獲得している送信先端末（例えば端末３１）が備えるジッタ削減能力（具体的には、許容遅延ジッタ）に応じて、バッファ１１０からデータユニットを読み出して、送信先に対応する網（例えば網３０）へ送信するためにデータユニットをプロトコル・エンティティ（例えば１７Ｂ）に出力する。
【００２１】
送信先端末のジッタ削減能力については、例えばＩＴＵ−Ｔ勧告Ｈ．２４５に記載された能力交換手段を用いて獲得することができる。ＩＴＵ−Ｔ勧告Ｈ．２４５は、マルチメディア通信で用いられる様々な制御プロトコルを規定するものであり、ＩＴＵ−Ｔ勧告Ｈ．３２４やＨ．３２３やその他の勧告に準拠したマルチメディア端末がこれに準拠している。ＩＴＵ−Ｔ勧告Ｈ．２４５で規定される制御プロトコルの中には、端末の能力交換手順が含まれており、この手順を用いることで、通信を行っているノード同士の通信能力を交換することができる。この能力交換は、ＩＴＵ−Ｔ勧告Ｈ．２４５で規定されている様々な制御メッセージを互いに送信することにより実現される。この実施形態においては、伝送系列ＡＢと伝送系列ＢＡとが共同して、送信先端末のジッタ削減能力情報を獲得し、対応する制御部１００がその情報を記憶する。
【００２２】
ゲートウェイ１０が、網（例えば網２０）から音声や画像などマルチメディアに係る複数の形式のデータを受信する場合には、後述するように、バッファ１１０は、一つの形式のデータユニットを、他の形式のデータユニットから独立した位置に格納する。また、制御部１００は、一つの形式のデータユニットを、他の形式のデータユニットとは区別しながら、バッファから読み出して、プロトコル・エンティティ（例えば１７Ｂ）に出力し網（例えば３０）へ送信する。
【００２３】
各制御部１００はさらに優先度決定部１２０を備えている。優先度決定部１２０は、後に詳述するように、マルチメディアに係る複数の形式のデータ通信で有効に利用される。
【００２４】
プロトコル・エンティティ１７Ａおよび１７Ｂの各々は、バッファ１１０から読み出されたデータユニットから、送信先端末に接続された網のプロトコルに適合したパケットまたはフレームを生成する。送信部１８Ａまたは１８Ｂの各々は、そのパケットまたはフレームを送信先端末に奉仕する網へ送信する。
【００２５】
上記の構成の下、網２０に奉仕される送信元端末から、網３０に奉仕される送信先端末に送信されるべきデータユニットは、網２０を経てゲートウェイ１０に到着する。ゲートウェイ１０は、網２０において発生した遅延ジッタを削減しながら、データユニットを網３０に送信する。網３０に奉仕される送信元端末から、網２０に奉仕される送信先端末に送信されるべきデータユニットについても、同様にして網３０で発生した遅延ジッタが削減される。
【００２６】
以下、送信元端末を端末２１、送信先端末を端末３１と仮定する。端末２１から送信された各パケットは、網２０を通過することにより、異なる遅延時間を伴ってゲートウェイ１０で受信される。ゲートウェイ１０は、このような遅延ジッタを制御部１００において削減した後、網３０が従うプロトコルに従って送信する。
【００２７】
図２を参照しながら、制御部１００における受信した単一形式のデータユニットのバッファリングについて説明する。
本実施形態では、バッファ１１０は、連続した所定数（図２では９）のバッファレジスタ＃１〜＃９を備えている。バッファ１１０の各バッファレジスタは、１パケットの長さにほぼ相当する容量を有しており、１パケット内の中身を記憶する。一定の時間間隔をおいて、バッファレジスタ内のデータは制御部１００に順次読み出されて出力されるようになっている。その時間間隔の長さをINTとする。図２に示す時刻ｔｎ（ｔ１、ｔ２、ｔ３……）は時間間隔INTおきに離れている。
【００２８】
図２に示すバッファ１１０では、時刻ｔ１ではバッファレジスタ＃９に記憶されていたデータが出力される。時刻ｔ２ではバッファレジスタ＃１に記憶されていたデータが出力される。時刻ｔ３ではバッファレジスタ＃２に記憶されていたデータが出力される。時刻ｔ４ではバッファレジスタ＃３に記憶されていたデータが出力される。このように、隣接するバッファレジスタに記憶されているデータユニットは一定の時間間隔をおいて順次出力される。ただし、バッファレジスタに記憶されたデータがなければ何も出力されない。
【００２９】
このバッファ１１０において、図２に示すように、時刻ｔ１においてバッファレジスタ＃２にパケットＰ１のデータユニットが記憶されると仮定する。上述の方式に従って、バッファレジスタ＃２に記憶されたパケットＰ１のデータユニットは時刻ｔ３において出力される。従って、パケットＰ１のデータユニットはバッファ１１０に記憶されてから、時間２×INT後に出力されることになる。
【００３０】
図２とは異なり、時刻ｔ１において、バッファレジスタ＃１にパケットＰ１のデータユニットが記憶されると仮定する。バッファレジスタ＃１に記憶されたパケットＰ１のデータユニットは、上述の方式に従って、バッファ１１０に記憶されてから時間１×INT後の時刻ｔ２において出力される。
【００３１】
上記より理解できるように、バッファ１１０においては、パケットＰ１のデータユニットをバッファレジスタ＃２に記憶することによって、バッファレジスタ＃１に記憶するのに比べて、出力時間がバッファレジスタ１個分に相当する時間INTだけ遅延されることになる。
【００３２】
本実施形態では、網２０から受信した一つの形式のパケット中の先頭のパケットのデータユニットを記憶すべきバッファレジスタを制御部１００が決定することにより、先頭のパケットのデータユニットが記憶されてから出力されるまでの時間を調節し、網２０において発生する遅延ジッタを吸収する。より具体的には、先頭パケットのデータユニットが記憶されてから出力されるまでの時間が、吸収すべき遅延ジッタの幅分となるバッファレジスタを、制御部１００は先頭パケットのデータユニットのための初期書込位置として選択する（図２のステップＳ１，Ｓ２で示すように）。
【００３３】
制御部１００は、２番目以降のパケットのデータユニットについては、その時点であいているバッファレジスタの中で直後に読み出しの対象となるバッファレジスタに記憶する（図２のステップＳ３で示すように）。さらにまた、制御部１００は、受信部１４Ａにおけるパケットの受信順序が遅延ジッタにより、送信元端末での送信順序に一致していない時には、パケットのヘッダを参照して、その順序をそろえた後に、バッファ１１０に記憶する。
【００３４】
図２に戻り、時刻ｔ１において受信した先頭のパケットＰ１のデータユニットは初期書込位置であるバッファレジスタ＃２に記憶される。時刻ｔ２においてパケットが受信されず、時刻ｔ３において２番目のパケットＰ２が受信されたと仮定する。もしパケットＰ１，Ｐ２が送信元から続けて送信されたのであれば、パケットＰ１の遅延とパケットＰ２の遅延は、網２０のために、時間INTだけ異なったと考えられる。時刻ｔ３においては、パケットＰ２のデータユニットは、先に説明した方式に従って、その時点であいているバッファレジスタの中で直後に読み出しの対象となるバッファレジスタ＃３に記憶される。同時に、時刻ｔ３では、バッファレジスタ＃２に記憶されたパケットＰ１のデータユニットがバッファ１１０から読み出される。時刻ｔ３から時間INT後の時刻ｔ４においては、バッファレジスタ＃３に記憶されたパケットＰ２のデータユニットが、バッファ１１０から読み出される。
【００３５】
このように、パケットＰ２が、パケットＰ１の遅延よりも時間INTだけ長く遅延してゲートウェイ１０に到着した場合であっても、先頭のパケットＰ１のデータユニットの出力タイミングを時間INTだけ遅延させているので、パケットＰ１とＰ２のデータユニットは連続したタイミングで出力され、遅延ジッタが吸収される。上述の通り、パケットの順序は、制御部１００でそろえられるので、パケットＰ１とＰ２の送信時刻関係をそろえれば後のデータユニットについても同様に遅延ジッタが吸収される。
【００３６】
上述のバッファリングは、送信先の属する網３０では許容遅延ジッタがゼロという仮定に基づいている。しかし、送信先端末３１は網３０において発生すると想定された最大の遅延ジッタに相当する遅延ジッタを吸収できると仮定しよう。この場合、ゲートウェイ１０は、網２０で発生した遅延ジッタの全部を吸収する必要はないかもしれない。しかし、別の網２０で発生する遅延ジッタが網３０のそれより大きければ、端末３１は別の網２０において発生する遅延ジッタの全部を吸収できるとは限らない。そこで、ゲートウェイ１０のコントローラ１００は、予め獲得した端末３１のジッタ削減能力である許容遅延ジッタに応じて、実在の遅延ジッタのうちどれだけ吸収するか決定する。この場合のゲートウェイ１０の動作を後に詳述する。
【００３７】
また、図２では、網２０での遅延ジッタが１×INTであるが、実在の網では遅延ジッタは、もっと大きいかもしれない。例えば、図９は、遅延発生を示すグラフを示しており、上のグラフは送信元端末２１における送信時の遅延発生を示し、下のグラフは網２０を通過後ゲートウェイ１０における受信時のパケット遅延発生を示す。図９の上のグラフの直線Ｄ０に示すように、端末２１からの送信時においては、当然、すべてのパケットは遅延を持たず、この段階での遅延ジッタは存在しない。しかし、網２０を通過することにより、各パケットは、様々な遅延時間でゲートウェイ１０に到着する。図９の下のグラフの曲線Ｄ１に示すように、最大遅延時間＝４×INT、最小遅延時間＝０、遅延ジッタ＝最大遅延時間＝４×INTである。
【００３８】
図９で示すような、網２０で発生する４×INTの遅延ジッタの全てをバッファ１１０で吸収するには、図５に示すように、バッファレジスタ＃５が初期書込位置になる。
【００３９】
しかし、本実施形態では、上記のように、バッファ１１０において吸収すべき遅延ジッタの幅（バッファ吸収幅）は、網２０で発生する遅延ジッタと、あらかじめ獲得した網３０において許容される遅延ジッタとに基づいて、制御部１００が決定する。網３０における許容遅延ジッタが３×INTであれば、バッファ１１０では１×INT分の遅延ジッタを吸収すればよい。図４に示すように、この場合の初期書込位置はバッファレジスタ＃２でよい。
【００４０】
以下、網２０で発生する遅延ジッタの一部をバッファ１１０で吸収する動作を、全部を吸収する動作と比較しながら説明する。
図３に示すように、端末２１から送信された先頭のパケットＰ１が最小遅延時間（０）でゲートウェイ１０に受信され、次のパケットＰ２が最大遅延時間（４×INT）でゲートウェイ１０に受信されると仮定する。すなわち、図３に示すように、先頭のパケットＰ１が時刻ｔ１において端末２１から送信され、２番目のパケットＰ２が時刻ｔ２において端末２１から送信される。先頭のパケットＰ１は、最小遅延時間０ｓで網２０を通過してゲートウェイ１０に時刻ｔ１に到着し、２番目のパケットＰ２は、最大遅延時間４ｓで網２０を通過してゲートウェイ１０に時刻ｔ６に到着している。
【００４１】
上述の通り、図４に示すように、送信先の属する網３０で許容遅延ジッタが３INTである場合には、時刻ｔ１においてパケットＰ１のデータユニットはバッファレジスタ＃２に記憶される。従って、パケットＰ１のデータユニットはｔ１から２×INT後の時刻ｔ３においてバッファ１１０から出力される
【００４２】
これに対して、網２０で発生する遅延ジッタの全てをバッファ１１０で吸収する比較例では、上述の通り、パケットＰ１のデータユニットは図５に示すようにバッファレジスタ＃５に記憶すべきである。よって比較例では、パケットＰ１のデータユニットはｔ１から５×INT後の時刻ｔ６においてバッファ１１０から出力されるだろう。
【００４３】
最大遅延時間４ｓ遅延した時刻ｔ６においてゲートウェイ１０に到着する２番目のパケットＰ２のデータユニットは、図４および図５に示すように、あいているバッファレジスタの中で記憶の直後に制御部１００に読み出されるバッファレジスタ＃６に記憶され、時刻ｔ７において出力される。
【００４４】
送信先の属する網３０で許容遅延ジッタが３INTである場合には、図４に示すように、パケットＰ２のデータユニットはパケットＰ１のデータユニットが出力されてから４INT後に出力されるので、網２０において生じた遅延ジッタ４INTの一部である１INTがバッファ１１０において吸収され、３INTの遅延ジッタが残留したことになる。残留遅延ジッタは送信先端末３１で吸収される。この場合、図３に示すように、パケットＰ１が端末２１より送信された時刻からバッファ１１０からそのデータユニットが出力された時刻までの遅延時間＝２INTとなり、パケットＰ２が端末２１より送信された時刻からバッファ１１０からそのデータユニットが出力された時刻までの遅延時間＝５INTとなる。
【００４５】
これに対して、網２０で発生する遅延ジッタの全てをバッファ１１０で吸収する比較例では、図５に示すように、パケットＰ２のデータユニットはパケットＰ１のデータユニットが出力されてから１INT後に出力されるので、網２０において生じた遅延ジッタ４INTはバッファ１１０において全部吸収されたことになる。この場合、図３に示すように、パケットＰ１が端末２１より送信された時刻からバッファ１１０からそのデータユニットが出力された時刻までの遅延時間＝５INTとなり、パケットＰ２が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間＝５INTとなる。
【００４６】
次に、先頭のパケットが最大遅延時間で到着する場合のゲートウェイ１０のバッファリング動作について、図６ないし図８を参照しながら説明する。
図６に示すように、先頭のパケットＰ１が時刻ｔ１において端末２１から送信され、２番目のパケットＰ２が時刻ｔ２において端末２１から送信されると仮定する。先頭のパケットＰ１は、網２０において生じうる最大遅延時間４INTで時刻ｔ５にゲートウェイ１０に到着し、２番目のパケットＰ２は、最大遅延時間４INTで時刻ｔ６にゲートウェイ１０に到着する。仮に到着の順序が乱されても、制御部１００が順序を再度そろえるので、後のパケットが先のパケットより先に処理されることはない。
【００４７】
送信先の属する網３０で許容遅延ジッタが３INTである場合には、図７に示すように、時刻ｔ５においてパケットＰ１のデータユニットはバッファレジスタ＃２に記憶され、ｔ５から２INT後の時刻ｔ７においてバッファ１１０から出力される。そして、送信時刻ｔ２から最大遅延時間４INT遅延した時刻ｔ６においてゲートウェイ１０に到着する２番目のパケットＰ２のデータユニットは、その時点であいているバッファレジスタの中で最もはやく出力されるバッファレジスタ＃３に記憶され、２INT後の時刻ｔ８において出力される。図６に示すように、両方のパケットＰ１およびＰ２について、端末２１より送信された時刻からデータユニットがバッファ１１０から出力された時刻までの遅延時間＝６INTである。
【００４８】
これに対して、網２０で発生する遅延ジッタの全てをバッファ１１０で吸収する比較例では、図８に示すように、時刻ｔ５においてパケットＰ１のデータユニットはバッファレジスタ＃５に記憶され、パケットＰ１のデータユニットはｔ５から５INT後の時刻ｔ１０においてバッファ１１０から出力される。送信時刻ｔ２から最大遅延時間４INT遅延した時刻ｔ６においてゲートウェイ１０に到着する２番目のパケットＰ２のデータユニットは、その時点であいているバッファレジスタの中で最もはやく出力されるバッファレジスタ＃６に記憶され、５INT後の時刻ｔ１１において出力される。図６に示すように、両方のパケットＰ１およびＰ２について、端末２１より送信された時刻からそののデータユニットがバッファ１１０から出力された時刻までの遅延時間＝９INTである。
【００４９】
以上より理解できるように、ネットワークを接続するゲートウェイ１０に設けられたバッファ１１０を利用して、先頭のパケットのデータユニットについては受信してからある時間後に出力し、以降のデータユニットについては順次出力するようにすることにより、網２０で発生した遅延ジッタの全てまたは一部を吸収することができる。
【００５０】
以上のように、バッファ１１０により網２０で起こった遅延ジッタの全てを吸収する場合は、先頭のパケットが最小遅延で到着した場合でも、各パケットが端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間＝５INTとなる（図３参照）。先頭のパケットが最大遅延である場合には遅延時間＝９INTにもなる（図６参照）。端末２１〜端末３１間の総遅延時間は、パケットＰ１が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間および網３０において発生する最大遅延時間の累計である。従って、パケットＰ１が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間の増大により、総遅延時間が増大してしまう。
【００５１】
これに対して遅延ジッタを一部吸収した場合は、先頭のパケットが最小遅延である場合には、パケットＰ１が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間＝２INTとなり、先頭のパケットが最大遅延である場合には遅延時間＝６INTになる（図３および図６参照）。このように、網３０において許容される遅延ジッタに基づいて、バッファ１１０で吸収すべき遅延を調整することにより、端末２１〜端末３１間の総遅延時間をより少なくすることができる。図３、図４および図７を参照しながら説明したように、遅延ジッタを一部だけ吸収した場合は、網２０において発生した遅延ジッタが部分的に残留する。しかし、この残留遅延ジッタは送信先端末３１で吸収される。
【００５２】
次に、マルチメディアに関わる複数形式のデータ通信へのこの実施形態の応用を説明する。
マルチメディア通信においては、プロトコル・エンティティ１５Ａまたは１５Ｂ（図１参照）は、対応する受信部１４Ａまたは１４Ｂで受信された複数形式のデータのうちの一つの形式のデータユニットと、他の形式のデータユニットから区別する。
【００５３】
また、各コントローラ１００の優先度決定部１２０は、データユニットの優先度を決定する。具体的には、優先度決定部１２０は、網３０へデータユニットを送信する順序を各データユニットの遅延ジッタに応じて決定する。
【００５４】
対応するプロトコル・エンティティ１７Ａまたは１７Ｂは、優先度決定部１２０から出力される優先度情報に基づいてバッファ１１０からの出力信号を多重送信のためにチャンネルにマップする。対応する送信部１８Ａまたは１８Ｂは、プロトコル・エンティティのマッピングに従ってデータユニットを網３０へ多重送信する。
【００５５】
図１０は、各制御部１００の内部機能エンティティを詳細に示す。以下の説明中、図１０で示すように、プロトコル・エンティティ１５Ａまたは１５Ｂはプロトコル・エンティティ１５と呼び、プロトコル・エンティティ１７Ａまたは１７Ｂはプロトコル・エンティティ１７と呼ぶ。
【００５６】
図１０に示すように、バッファ１１０は音声バッファ１１１および画像バッファ１１２を備える。
【００５７】
音声バッファ１１１は、プロトコル・エンティティ１５から出力された音声データパケットのデータユニットを記憶し、画像バッファ１１２は、プロトコル・エンティティ１５から出力された画像データパケットのデータユニットを記憶する。各バッファから読み出されたデータユニットは別々にプロトコル・エンティティ１７に供給される。
【００５８】
また、バッファ１１１または１１２の各々から出力されたデータユニットは優先度決定部１２０にも供給されるようになっている。優先度決定部１２０は、出力時刻検出部１２２と、遅延時間算出部１２３と、判定部１２４とを有する。
出力時刻検出部１２２は、ゲートウェイ１０の内部クロックに基づいてバッファ１１０からの最初の音声データユニットの出力時と最初の画像データユニットの出力時を検出し、これを遅延時間算出部１２３に出力する。音声バッファ１１１から出力された最初の音声データユニットの出力時刻をＢｓ（Ａ）、画像バッファ１１１から出力された最初の画像データユニットの出力時刻をＢｓ（Ｖ）と呼ぶ。
【００５９】
遅延時間算出部１２３は、プロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ(A)を算出する。標準出力時刻Ｓｓ(A)は、遅延がなければ、その音声データユニットがバッファ１１０から出力されているべき時刻であり、最初の音声データユニットの音声バッファ出力時刻Ｂｓ(A)を起算点とする。さらに、現在時刻Ｃｔとプロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ（Ａ）の時間差を音声遅延時間Ｄ（Ａ）として算出して判定部１２４に出力する。また、遅延時間算出部１２３は、プロトコル・エンティティ１７から未送信の画像データユニットの標準出力時刻Ｓｓ(Ｖ)を算出する。標準出力時刻Ｓｓ(Ｖ) は、遅延がなければ、その画像データユニットがバッファ１１０から出力されているべき時刻であり、最初の画像データユニットの画像バッファ出力時刻Ｂｓ(Ｖ)を起算点とする。さらに、現在時刻Ｃｔとプロトコル・エンティティ１７から未送信の画像データユニットの標準出力時刻Ｓｓ（Ｖ）の時間差を画像遅延時間Ｄ（Ｖ）として算出して判定部１２４に出力する。音声遅延時間Ｄ（Ａ）および画像遅延時間Ｄ（Ｖ）は、最初の音声または画像データユニットに対する各データユニットの遅延時間を比較するには十分な指標である。
【００６０】
例えば、音声バッファ１１１と画像バッファ１１２から音声データユニットと画像データユニットが同時に読み出された場合など、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合、判定部１２４は、音声遅延時間Ｄ（Ａ）および画像遅延時間Ｄ（Ｖ）を比較し、その比較に基づいて、プロトコル・エンティティ１７における送信の優先度を制御するための送信制御指令を作成し、これをプロトコル・エンティティ１７に出力する。
【００６１】
図１１に示すフローチャートを参照しながら、優先度決定部１２０における優先度決定処理を説明する。この図示した処理は、１INTおきに繰り返される。
まず、ステップＳ１１で、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合、遅延時間算出部１２３は、最初の音声データユニットの音声バッファ出力時刻Ｂｓ(Ａ)に基づいて、プロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ(A)を式（１）に従い算出する。
Ss(A) ＝ Bs(A) + (N(A) − 1) × Cy(A)・・・・・（１）
ここで、N(A)は音声データユニットの順序を示す番号であり、Cy(A)は端末２１による音声パケットの送信サイクルを示す。
【００６２】
また、ステップＳ１１で、遅延時間算出部１２３は、最初の画像データユニットの画像バッファ出力時刻Ｂｓ(Ｖ)に基づいて、プロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ(Ｖ)を式（２）に従い算出する。
Ss(V) ＝ Bs(V) + (N(V) − 1) × Cy(V)・・・・・（２）
ここで、N(V)は画像データユニットの順序を示す番号であり、Cy(V)は端末２１による画像パケットの送信サイクルを示す。
【００６３】
ステップＳ１２で、遅延時間算出部１２３は、画像データユニットの標準出力時刻Ｓｓ(V)と現在時刻Ｃｔに基づいて式（３）に従い、そのデータユニットの遅延時間Ｄ（Ｖ）を算出する。
D(V) = Ct − Ss(V)・・・・・（３）
【００６４】
ステップＳ１３で、遅延時間算出部１２３は、音声データユニットの標準出力時刻Ｓｓ(V)と現在時刻Ｃｔに基づいて式（４）に従い、そのデータユニットの遅延時間Ｄ（Ａ）を算出する。
D(A) = Ct − Ss(A)・・・・・（４）
【００６５】
次に判定部１２４は、ステップＳ１４で、音声遅延時間Ｄ（Ａ）が画像遅延時間Ｄ（Ｖ）よりも大きいか否かを判定する。ステップＳ１４の判定が肯定的であれば、ステップＳ１５で、判定部１２４はその音声データユニットを優先して送信することを指示する送信制御指令を判定部１７に供給する。一方、ステップＳ１４の判定が否定的であれば、ステップＳ１６で、判定部１２４はその画像データユニットを優先して送信することを指示する送信制御指令を判定部１７に供給する。このようにして処理は終了し、その後繰り返される。
【００６６】
次に、図１２および図１３に示すタイムチャートを参照しながら、マルチメディア通信におけるパケットの処理を具体的に説明する。図１２および図１３において、文字A,Vはそれぞれ音声パケット、画像パケットに対応するデータユニットを示し、添え字は端末２１からの送信順序を示す。
【００６７】
まず、端末２１からの各パケットの送信の態様およびバッファ１１０からの各パケットの出力の態様は、図１２および図１３に示すようなものであると仮定する。すなわち、端末２１からの各形式のパケットにかかるデータユニットは、上述したように網２０で発生した遅延ジッタの一部だけをバッファ１１１または１１２で吸収するやり方で、ゲートウェイ１０でバッファリングされてバッファ１１０から出力される。このため、図１２および図１３に示すように、音声パケットＡの送信サイクルが３INTであるのに、パケットＡ１から４INTの後にパケットＡ２のデータユニットがバッファから出力され、画像パケットＶの送信サイクルが５INTであるのに、パケットＶ１から６INTの後にパケットＶ２のデータユニットがバッファから出力される。
【００６８】
音声バッファ１１１、画像バッファ１１２において、音声と画像データユニットの遅延ジッタが全部吸収された場合には、全ての音声データユニット、画像データユニットは送信元端末２１から網２０への送信サイクルと同じサイクルで出力されるはずである。従って、遅延ジッタの一部だけをバッファで吸収したがゆえに、２番目以後の音声データ群には１INTの遅延ジッタ、２番目以後の画像データ群には１INTの遅延ジッタが残留していることが図１２および図１３から理解できよう。
【００６９】
さらに、プロトコル・エンティティ１７により音声と画像のデータユニットを単一チャネルに多重して網３０に送信するために、この多重によっても遅延が生ずる。従って、上述したバッファ１１０からの出力時の残留した遅延ジッタに、多重による遅延ジッタが重畳されて、プロトコル・エンティティ１７からの出力データユニットの遅延ジッタが広がる場合がある。
【００７０】
プロトコル・エンティティ１７による多重における遅延ジッタは、異なる種類に属するデータユニットの送信順序に大きく影響を受ける。より具体的には、図１２および図１３に示すように、音声パケットは同一のデータ長であって等間隔３INTで端末２１から送信されるのに対して、画像パケットはそれぞれ長さが異なっており、しかもそれらの長さが音声パケットの長さに比較して大きく、等間隔５INTで送信される。このような場合は、ゲートウェイ１０では、長い画像データユニットの送信中では音声データユニットを出力するのが好ましい時でも、音声データユニットを送信できない。従って、多重の方式に工夫を加えないと、音声データユニットに多重による遅延が生じうる。そして、残留している音声データユニットの遅延ジッタと多重の際の遅延によって、さらに遅延ジッタが広がることがありうる。
【００７１】
多重の方式には、様々なものが考えられる。例えば、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合に、多重の際に画像データユニットを常に音声データユニットよりも優先することが考えられうる。逆に、そのような場合に、多重の際に音声データユニットを常に画像データユニットよりも優先することも考えられうる。これらの方式には以下に述べるように欠点がある。
【００７２】
図１２において、時刻ｔ１３では、音声パケットＡ４のデータユニットが音声バッファ１１１から出力され、画像パケットＶ３のデータユニットが画像バッファ１１２から出力される。また、この時には、以前の音声パケットＡ３のデータユニットがすでに音声バッファ１１１から出力されているのに、プロトコル・エンティティ１７から送信されていない。別の時刻ｔ１８では、画像パケットＶ４のデータユニットが画像バッファ１１２から出力され、未送信の音声パケットＡ５のデータユニットが存在する。
【００７３】
音声パケットを常に優先する方式では、図１２および図１３に示すように、プロトコル・エンティティ１７からは、時刻ｔ１３において音声パケットＡ３のデータユニットが送信され、時刻ｔ１４において音声パケットＡ４のデータユニットが送信されて、時刻ｔ１５に至ってやっと画像パケットＶ３のデータユニットが出力される。従って、画像パケットＶ３のデータユニットは端末２１から送信された時刻ｔ１１から４INT遅延して網３０に送信されることになる。同様に、時刻ｔ１８では音声パケットＡ５のデータユニットが優先され、時刻ｔ１９では新音声パケットＡ６のデータユニットが優先されるので、画像パケットＶ４のデータユニットは端末２１から送信された時刻ｔ１６から４INT遅延して時刻ｔ２０に網３０に送信される。しかし、最初の画像パケットＶ１のデータユニットは、図１２に示すように、端末２１から送信された時刻ｔ１から１INTだけ遅延して時刻ｔ２に網３０に出力される。
【００７４】
画像データユニットを常に優先する方式では、図１２および図１３に示すように、時刻ｔ１３においてプロトコル・エンティティ１７からは、画像パケットＶ３のデータユニットの送信が開始され、時刻ｔ１４、ｔ１５では画像パケットＶ３のデータユニットの送信を継続する。時刻ｔ１０において音声バッファ１１１から出力される音声パケットＡ３のデータユニット、時刻ｔ１３において音声バッファ１１１から出力される音声パケットＡ４のデータユニットは、画像パケットＶ３のデータユニットの送信が終了した後に、送信される。従って、音声パケットＡ３のデータユニットは端末２１から送信された時刻ｔ７から９INTも遅延して時刻ｔ１６に網３０に送信され、音声パケットＡ４のデータユニットは端末２１から送信された時刻ｔ１０から７INT遅延して時刻ｔ１７に網３０に送信されることになる。同様に、時刻ｔ１８では画像パケットＶ４のデータユニットが優先されるので、音声パケットＡ５のデータユニットは端末２１から送信された時刻ｔ１３から９INTも遅延して時刻ｔ２２に網３０に送信され、音声パケットＡ６のデータユニットは端末２１から送信された時刻ｔ１６から７INT遅延して時刻ｔ２３に網３０に送信される。しかし、最初の音声パケットＡ１のデータユニットは、端末２１から送信された時刻ｔ１から５INTだけ遅延して時刻ｔ６に網３０に出力される。
【００７５】
以上のように、いずれか一方の群のデータユニットを常に優先させた場合は、網２０で発生した遅延ジッタに対して、さらにプロトコル・エンティティ１７における多重による遅延ジッタが重畳されて、網３０への送信の際に遅延ジッタが広がってしまう。
【００７６】
図１４は、マルチメディア通信における遅延の発生を示す。曲線Ｄ１は網２０を通過することに生ずる遅延ジッタを示しており、図９の下のグラフの曲線Ｄ１と等価である。曲線Ｄ３は、バッファ１１０で一部が吸収された残りの遅延ジッタを示しており、この残りの遅延ジッタはバッファでの吸収分だけ曲線Ｄ１の網２０通過後の遅延ジッタより小さい。曲線Ｄ２１は、いずれか一方の群のデータ形式を常に優先させた場合の網３０への多重送信の際の遅延ジッタを表す。曲線Ｄ２１により明らかなように、せっかくバッファ１１０で遅延ジッタの一部が吸収されても、多重による遅延ジッタが重畳されて、網３０への送信の際に遅延ジッタが広がってしまうことがわかる。
【００７７】
本実施形態では、パケットの遅延ジッタをより少なくするために、多重送信における各データユニットの優先度を遅延時間に応じて決定する。より具体的には、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合には、その時点で最初の同種データユニットに対する遅延時間が大きいデータユニットを優先する。この実施形態の処理を次に具体的に説明する。
【００７８】
図１２および図１３において、時刻ｔ１３では、未送信の音声パケットのデータユニットＡ３の遅延時間Ｄ（Ａ３）＝４INTであり、未送信の画像パケットのデータユニットＶ３の遅延時間Ｄ（Ｖ３）＝１INTである。図１２および図１３中の遅延時間Ｄ（Ａ），Ｄ（Ｖ）については、上述の式（１）ないし（４）で算出される。本実施形態では、時刻ｔ１３で、優先度決定部１２０は遅延時間の大きな音声パケットＡ３のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。
【００７９】
時刻ｔ１４においては、未送信の音声パケットＡ４のデータユニットの遅延時間Ｄ（Ａ４）＝２INTであり、画像パケットＶ３のデータユニットの遅延時間Ｄ（Ｖ３）＝２INTで同じである。本実施形態では、図１１のステップＳ１４で表される規則に従って、優先度決定部１２０は音声パケットＡ４のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。従って、時刻ｔ１３で音声パケットＡ３のデータユニット、時刻ｔ１４で音声パケットＡ４のデータユニット、時刻ｔ１５で画像パケットＶ３のデータユニットが送信される。この様子は音声データユニットを常に優先させる方式と同じである。しかし、時刻ｔ１３〜ｔ１７の間の時間においては、画像データユニットを優先させる方式よりも音声パケットＡ３，Ａ４のデータユニットに関して遅延ジッタの増加は少ない。
【００８０】
時刻ｔ１８では、未送信の音声パケットＡ５のデータユニットの遅延時間Ｄ（Ａ５）＝３INTであり、画像パケットＶ４のデータユニットの遅延時間Ｄ（Ｖ４）＝１INTである。よって、本実施形態では、優先度決定部１２０は遅延時間の大きな音声パケットＡ５のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。
【００８１】
時刻ｔ１９では、未送信の音声パケットＡ６のデータユニットの遅延時間Ｄ（Ａ６）＝１INTであり、画像パケットＶ４のデータユニットの遅延時間Ｄ（Ｖ４）＝２INTである。よって、本実施形態では、優先度決定部１２０は遅延時間の大きな画像パケットＶ４のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。そして、時刻ｔ２３で、音声パケットＡ６のデータユニットが送信される。
【００８２】
従って、音声パケットＡ５のデータユニットは端末２１から送信された時刻ｔ１３から５INT遅延して時刻ｔ１８に網３０に送信され、画像パケットＶ４のデータユニットは端末２１から送信された時刻ｔ１６から３INT遅延して時刻ｔ１９に網３０に送信され、音声パケットＡ６のデータユニットは端末２１から送信された時刻ｔ１６から７INT遅延して時刻ｔ２３に網３０に送信される。従って、音声データユニットを優先させる方式よりも画像パケットＶ４のデータユニットに関して遅延ジッタの増加は少ない。
【００８３】
図１４の曲線Ｄ２２は、本実施形態に従って、遅延時間に応じてパケットの優先度を決定した場合の網３０への多重送信の際の遅延ジッタを表す。曲線Ｄ２１とＤ２２とを比較すると明らかなように、本実施形態では、遅延ジッタの増加をより抑制することができ、網３０への多重送信の際の遅延ジッタが残留遅延ジッタ（曲線Ｄ３の幅）に近づく。
【００８４】
この多重送信の際の遅延ジッタは、送信先の端末３１が吸収可能な許容遅延ジッタ以下であるのが好ましい。よって、マルチメディア通信において多重の前に送信先の許容遅延ジッタに基づいて決定されるバッファで吸収する遅延ジッタの量は、単一形式のデータを転送する場合の遅延ジッタの量よりも多くするのが効果的である。
【００８５】
以上、好適な実施形態を参照しながら本発明を説明したが、特許請求の範囲で定められる本発明の範囲から逸脱せずに、形式および細部の様々な変更ができることは当業者には理解できよう。かかる変更形態、代替形態および修正形態も、均等物として特許請求の範囲に含まれる。かかる均等物の例を次に説明する。
【００８６】
パケット交換網である網２０に関しては、ネットワーク遅延のために、マルチメディア通信における異なる形式のパケット相互の順序の乱れが起こりやすいが、回線交換網である網３０に関しては、ネットワーク遅延が起こりにくく、異なる形式のフレーム相互の順序の乱れは生じにくい。従って、図１の実施形態とは異なり、上述の利点を有する回線交換網３０から転送されたフレームを取り扱う伝送系列ＢＡには優先度決定部１２０を設けないことも可能である。
【００８７】
遅延ジッタを吸収するための要素は、バッファ１１０に限定されない。送信先端末の許容遅延ジッタに応じた時間だけ先頭のデータユニットを保留し、後続のデータユニットを正規の順序に従って順次出力できる他の要素を使用することができる。
【００８８】
上記実施形態においては、マルチメディア通信においては、単に、遅延時間の大きいデータユニットに高い優先度を与える。しかし、３つ以上の形式のデータを送信する場合には、一つまたはそれより多い形式のデータに高い優先度をあらかじめ与え、他の形式のデータに関しては、遅延時間の大きいデータユニットに次に高い優先度を与えてもよい。
【００８９】
遅延時間の代わりに、データユニットの長さに基づいて、優先度を与えるデータユニットを決定できるようにしてもよい。
長いデータユニットを送信中に、遅延時間の大きな短いデータユニットの出力タイミングになった場合は、割り込み送信できるようにしても構わない。場合によっては、このような割り込み送信は、さらに遅延ジッタを小さくすることができるかもしれない。この目的のため、例えば、ＩＴＵ−Ｔ勧告Ｈ．２２３に記載されているように、長いデータユニットをセグメント化するとよい。これによれば、長い画像データユニットの送信を中断し、短い音声データユニットを送信した後も、残りのセグメントを支障なく送ることができる。
【００９０】
上述の実施形態では、網２０はパケット交換網であり、網３０は回線交換網であるが。ただし、本発明をこれに限定する意図ではなく、変更・修正が可能である。遅延のジッタが生じる原因には、ネットワークの諸要因と、端末やゲートウェイにおける多重化がある。パケット交換網では、ネットワークの諸要因により遅延ジッタが生じうる。一方、回線交換網では、ネットワークの諸要因による遅延ジッタは生じにくいが、端末やゲートウェイにおける多重化により遅延ジッタが残ったままフレームが交換される。パケット交換網における遅延ジッタは、端末やゲートウェイにおける多重化により生じる遅延ジッタよりも一般的には大きい。一般的には、各網に奉仕される端末は、送信先となったときに、その網で生じうる最大遅延ジッタを吸収できるようになっている。
【００９１】
図１５に示すように、網２０および網３００がいずれもパケット交換網で、パケット交換網２０で生じうる最大遅延ジッタがパケット交換網３００で生じうる最大遅延ジッタよりも大きい変更形態を想定する。網２０に奉仕される端末が送信元で、網３００に奉仕される端末が送信先である場合には、上記実施形態と同様に、送信先の端末３１のジッタ削減能力に応じてゲートウェイ１０が送信元側の網２０で生じた遅延ジッタのうちの一部を吸収するのが有効である。
【００９２】
ただし、起こりうる遅延ジッタが小さい網３００に奉仕される端末が送信元で、起こりうる遅延ジッタが大きい網２０に奉仕される端末が送信先であって、送信先端末のジッタ削減能力が高い場合には、送信元側の網３００で生じた遅延ジッタをゲートウェイ１０で吸収する必要は少ないかもしれない。そのような場合には、網３００から網２０へデータを転送する伝送系列ＢＡにはデジッタ用の要素を設けなくてもよい。
【００９３】
上記実施形態を参照して説明したように、送信元側の網２０がパケット交換網であり、送信先側の網３０が回線交換網である場合には、送信先の端末３１のジッタ削減能力に応じてゲートウェイ１０が送信元側の網２０で生じた遅延ジッタのうちの一部を吸収するのが有効である。ただし、起こりうる遅延ジッタが小さい回線交換網３０に奉仕される端末が送信元で、起こりうる遅延ジッタが大きいパケット交換網２０に奉仕される端末が送信先であって、送信先端末のジッタ削減能力が高い場合には、送信元側の網３０で生じた遅延ジッタをゲートウェイ１０で吸収する必要は少ないかもしれない。そのような場合には、伝送系列ＢＡにはやはりデジッタ用の要素を設けなくてもよい。
【００９４】
上述の通り、回線交換網では、ネットワークの諸要因による遅延ジッタは生じにくいが、端末やゲートウェイにおける多重化により遅延ジッタが残ったままフレームが交換される。従って、回線交換網に属する送信先端末で許容され、バッファでの吸収量を定めるためのパラメータとなる遅延ジッタは、その網で多重化により起こりうる最大遅延時間と等しくしてもよい。
【００９５】
上記の実施形態では、送信先端末は、ゲートウェイ１０に接続された第２の網３０に直接的に奉仕される。しかし、送信先端末は、網３０に間接的に奉仕されてもよい。つまり、送信先端末と網３０との間に、一つまたは複数の網と、隣合う網の相互を接続する他のゲートウェイが介在していてもよい。
【００９６】
【発明の効果】
以上説明したように、本発明によれば、ジッタを削減することにより、遅延の増加を最小限にすることができる。
【図面の簡単な説明】
【図１】 本発明の実施形態に係るゲートウェイを示すブロック図である。
【図２】 図１のゲートウェイ内のバッファの動作を示す図である。
【図３】 先頭のパケットが最小遅延時間で到着した場合の、図１のゲートウェイにおけるデータユニットの処理を示すタイムチャートである。
【図４】 先頭のパケットが最小遅延時間で到着した場合の上記バッファにおけるデータユニットの処理を示す図である。
【図５】 先頭のパケットが最小遅延時間で到着した場合の上記バッファにおけるデータユニットの別の処理を示す図である。
【図６】 先頭のパケットが最大遅延時間で到着した場合の、図１のゲートウェイにおけるデータユニットの処理を示すタイムチャートである。
【図７】 先頭のパケットが最大遅延時間で到着した場合の上記バッファにおけるデータユニットの処理を示す図である。
【図８】 先頭のパケットが最大遅延時間で到着した場合の上記バッファにおけるデータユニットの別の処理を示す図である。
【図９】 ネットワーク遅延の発生を示すグラフを有する。
【図１０】 図１に示す各制御部の内部機能エンティティを示すブロック図である。
【図１１】 マルチメディア通信における上記制御部の中の優先度決定部の処理を示すフローチャートである。
【図１２】 マルチメディア通信における、図１のゲートウェイの中のデータユニットの処理を示すタイムチャートの一部である。
【図１３】 図１２と共同で上記タイムチャートを構成する。
【図１４】 上記実施形態のマルチメディア通信への応用の効果を説明するための図である。
【図１５】 本発明の変更形態を示す図である。
【符号の説明】
１０…ゲートウェイ、１４Ａ，１４Ｂ…受信部、１８Ａ，１８Ｂ…送信部、２０，３０…網（ネットワーク）、１００…制御部、１２２…出力時刻検出部、１２２…遅延時間算出部、ＡＢ，ＢＡ…伝送系列（獲得部）
【発明の属する技術分野】
この発明は、データ伝送における遅延ジッタが存在するネットワークと、他のネットワークとを接続するゲートウェイおよびそのためのデータ転送方法に関する。
【０００２】
【従来の技術】
プロトコルおよびネットワーク特性の異なる異種ネットワークに接続された各端末間でのマルチメディア通信を行うために、ゲートウェイは不可欠な部材である。このゲートウェイは、送信元端末が属するネットワークのプロトコルに従ったデータを受信し、送信先端末が属するネットワークのプロトコルに従ってこのデータを送信する。これにより、送信元端末から送信されたデータは、その送信元端末が属するネットワーク、ゲートウェイ、および送信先端末の属するネットワークを通過することになる。
【０００３】
マルチメディアのために、インターネットのようなパケット交換網ではＩＴＵ−Ｔ勧告Ｈ．３２３に準拠した端末が用いられており、ＰＳＴＮ（public switched telephone network）のような回線交換網ではＩＴＵ−Ｔ勧告Ｈ．３２４に準拠した端末が用いられている。勧告Ｈ．３２３とＨ．３２４では、使用されている通信プロトコルが異なるため（勧告Ｈ．３２３ではＲＴＰ／ＵＤＰ、勧告Ｈ．３２４では勧告Ｈ．２２３で規定する多重送信プロトコル）、相互接続にはゲートウェイにおいてプロトコルの変換が必要になる。さらにまた、高品質のマルチメディア通信を実現するには、遅延、遅延ジッタおよびエラー特性のようなネットワーク特性の相違を補償することが必要である。
【０００４】
【発明が解決しようとする課題】
ネットワークでは、様々な要因によってデータ伝送に関する遅延が生じ、各データユニットの遅延が異なる場合がある。このような伝送遅延のゆらぎを遅延ジッタという。遅延ジッタの発生要因としては、例えば、パケット交換網での蓄積交換、経路上のノードにおける待ち合わせ、あるいは、各データユニットが異なる経路を経てゲートウェイに到着する事実がある。
【０００５】
回線交換網においても、異なる形式のデータを同時に伝送することにより遅延ジッタが生ずる。例えば、テレビ電話のようなマルチメディア端末は、一つのビットストリームに画像、音声および／またはアプリケーションデータを多重する。このような場合においては、すぐに送信されるデータもあれば、現在送信中のデータの送信完了まで送信されないデータもある。この種の遅延ジッタは端末でもゲートウェイでも起こり、送信速度が低いほど大きくなる。
【０００６】
遅延ジッタが発生すると、送信元端末でのデータユニットの時間間隔が、送信先端末においては保たれない。例えば音声のような精確な同期の必要性が高いデータを送信する際には、このような遅延ジッタを解消できることが望ましい。
遅延ジッタを解消するために、通信端末にはある程度の遅延ジッタを吸収するものがある。例えば、ある通信端末は、様々な遅延時間で受信したデータユニットをいったん記憶し、一連のデータユニットが蓄積されてからそれらを連続して出力する。しかしながら、ネットワークによって遅延ジッタの発生要因や特性が異なるので、送信先となりうる通信端末に受信されるデータの遅延ジッタが、どの程度大きいのかをあらかじめ知ることは困難である。従って、送信先の端末で許容される遅延ジッタは、その端末の属するネットワークにおいて発生しうる最大の遅延ジッタに基づいている場合が多い。このため、エンド・トゥ・エンドの遅延が増加することになり、この遅延はリアルタイム通信では深刻な問題となりうる。
【０００７】
本発明は、ジッタを削減することにより、遅延の増加を最小限にすることのできるゲートウェイおよびデータ転送方法を提供する。
【０００８】
【課題を解決するための手段】
本発明の一つの態様によれば、二つのネットワークを接続するゲートウェイが、
少なくとも一つの形式の複数のデータユニットを第１のネットワークから受信する受信部と、
前記受信部で受信した前記データユニットを一時的に記憶し、送信先端末の遅延ジッタ削減能力に基づいてある時間を決定し、前記受信部において先頭のデータユニットを受信した時刻からその決定した時間が経過した後に前記先頭のデータユニットを出力し、その後、前記第１のネットワークにおける送信サイクルと同じサイクルで後続のデータユニットを順次出力する制御部と、
前記制御部で出力されたデータユニットに対応するデータユニットを前記送信先端末に届けるために第２のネットワークに送信する送信部とを備える。
本発明において、ゲートウェイには第１および第２のネットワークが接続されている。送信先端末は、第２のネットワークに直接的に奉仕されてもよい。あるいは、送信先端末は、第２のネットワークに間接的に奉仕されてもよい。つまり、送信先端末と第２のネットワークとの間に、一つまたは複数のネットワークと、これらの隣合うネットワーク相互を接続する他のゲートウェイが介在していてもよい。
好ましくは、このゲートウェイは、前記送信先端末の遅延ジッタ削減能力に関する情報を獲得するジッタ削減能力獲得部をさらに備えるとよい。
【００１０】
好ましくは、前記受信部は、異なる形式のデータユニットを受信することが可能であり、異なる形式のデータユニットが同時に未送信である時に、前記制御部は、前記第１のネットワークにおいて前記データユニットが伝送される際に生じた遅延時間に応じて前記送信部における優先度を決定してもよい。この場合、前記送信部は、前記制御部から出力された異なる形式のデータユニットを、前記優先度に従って多重化して前記第２のネットワークを通じて前記送信先端末に送信するようにしてもよい。
【００１１】
好ましくは、前記制御部は、各形式における最初のデータユニットが前記制御部から出力された最初出力時刻を検出する出力時刻検出部と、前記最初出力時刻に基づいて、各形式における最初のデータユニットに対する各データユニットの前記遅延時間を算出する遅延時間算出部とを備えてもよい。この場合、前記制御部は、算出された前記遅延時間が長いと判定されたデータユニットについては、他のデータユニットに優先して送信するように前記送信部を制御するようにしてもよい。
【００１２】
前記制御部は、前記第１のネットワークにおいて前記データユニットが伝送される際に生じうる最大遅延時間を、前記送信先端末において許容される遅延ジッタに応じて短縮して前記時間を求めるようにしてもよい。
【００１３】
本発明の他の一つの態様によれば、データ転送方法が、少なくとも一つの形式の複数のデータユニットを第１のネットワークから受信することと、前記データユニットを一時的に記憶することと、あらかじめ獲得した送信先端末のジッタ削減能力に基づいてある時間を決定することと、先頭のデータユニットを受信した時刻からその決定した時間が経過した後に前記先頭のデータユニットを出力することと、前記第１のネットワークにおける送信サイクルと同じサイクルで後続のデータユニットを順次出力すること、前記データユニットに対応するデータユニットを前記送信先端末に届けるために第２のネットワークに送信することとを備える。
【００１４】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明に係る一つの実施の形態について説明する。
図１に示すように、本発明に係る実施形態では、ゲートウェイ１０が網２０と網３０とを相互接続しており、これにより網２０に奉仕される送信元端末からデータが網３０に奉仕される送信先端末に送信され、逆に、網３０に奉仕される送信元端末からデータが網２０に奉仕される送信先端末に送信される。網２０、３０はそれぞれ多数の端末に奉仕するが、図１では、便宜上、網２０に奉仕される端末２１と、網３０に奉仕される端末３１のみが描かれている。両方の網１０および２０においては、少なくとも一つの形式のデータユニットが交換される。
【００１５】
この実施形態では、網２０は、データユニットがパケットに含められて送受信されるパケット交換網であり、網３０はフレームとしてデータユニットが送受信される回線交換網である。フレームには、例えば音声データフレームや画像データフレームが含まれる。ただし、本発明をこれに限定する意図ではなく、変更・修正が可能である。網２０または３０は、移動網であってもよいし、固定網であってもよい。
【００１６】
ゲートウェイ１０は、網２０のための網インターフェイス１２と、網３０のための網インターフェイス１３と、網２０から網３０へデータを伝送する伝送系列ＡＢと、網３０から網２０へデータを伝送する伝送系列ＢＡを備えている。
伝送系列ＡＢは、受信部１４Ａ、プロトコル・エンティティ１５Ａ、メディア変換符号化部１６、プロトコル・エンティティ１７Ｂ、送信部１８Ｂ、および制御部１００を備えており、伝送系列ＢＡは、受信部１４Ｂ、プロトコル・エンティティ１５Ｂ、メディア変換符号化部１６、プロトコル・エンティティ１７Ａ、送信部１８Ａ、および制御部１００を備えている。
【００１７】
受信部１４Ａは、網２０から網インターフェイス１２を介してビットストリームを受信する。このビットストリームには、網２０に奉仕される送信元端末（例えば端末２１）で作成された少なくとも一つの形式の複数のデータユニット（パケット）が含まれうる。一方、受信部１４Ｂは、網３０から網インターフェイス１３を介してビットストリームを受信する。このビットストリームには、網３０に奉仕される送信元端末（例えば端末３１）で作成された少なくとも一つの形式の複数のデータユニット（フレーム）が含まれうる。
【００１８】
プロトコル・エンティティ１５Ａは、網２０において使用されるプロトコルにとって終端であり、各パケットからペイロード情報やその関連情報を取り出す。ＲＴＰ／ＵＤＰが通信プロトコルとして使われるのであれば、関連情報には、データタイプ、タイムスタンプ（送信時間）、シーケンスナンバーその他が含まれる。同様に、プロトコル・エンティティ１５Ｂは網３０において使用されるプロトコルにとって終端である。
【００１９】
メディア変換符号化部１６は、必要に応じて、音声や画像の符号変換を行うものであり、例えば、網２０と網３０で用いられている音声もしくは画像符号体系が異なる場合に符号変換を行う。
【００２０】
制御部１００は、バッファ１１０を備えており、バッファはプロトコル・エンティティ１５Ａまたは１５Ｂから入力されるデータユニットをバッファリングする。制御部１００は、予め獲得している送信先端末（例えば端末３１）が備えるジッタ削減能力（具体的には、許容遅延ジッタ）に応じて、バッファ１１０からデータユニットを読み出して、送信先に対応する網（例えば網３０）へ送信するためにデータユニットをプロトコル・エンティティ（例えば１７Ｂ）に出力する。
【００２１】
送信先端末のジッタ削減能力については、例えばＩＴＵ−Ｔ勧告Ｈ．２４５に記載された能力交換手段を用いて獲得することができる。ＩＴＵ−Ｔ勧告Ｈ．２４５は、マルチメディア通信で用いられる様々な制御プロトコルを規定するものであり、ＩＴＵ−Ｔ勧告Ｈ．３２４やＨ．３２３やその他の勧告に準拠したマルチメディア端末がこれに準拠している。ＩＴＵ−Ｔ勧告Ｈ．２４５で規定される制御プロトコルの中には、端末の能力交換手順が含まれており、この手順を用いることで、通信を行っているノード同士の通信能力を交換することができる。この能力交換は、ＩＴＵ−Ｔ勧告Ｈ．２４５で規定されている様々な制御メッセージを互いに送信することにより実現される。この実施形態においては、伝送系列ＡＢと伝送系列ＢＡとが共同して、送信先端末のジッタ削減能力情報を獲得し、対応する制御部１００がその情報を記憶する。
【００２２】
ゲートウェイ１０が、網（例えば網２０）から音声や画像などマルチメディアに係る複数の形式のデータを受信する場合には、後述するように、バッファ１１０は、一つの形式のデータユニットを、他の形式のデータユニットから独立した位置に格納する。また、制御部１００は、一つの形式のデータユニットを、他の形式のデータユニットとは区別しながら、バッファから読み出して、プロトコル・エンティティ（例えば１７Ｂ）に出力し網（例えば３０）へ送信する。
【００２３】
各制御部１００はさらに優先度決定部１２０を備えている。優先度決定部１２０は、後に詳述するように、マルチメディアに係る複数の形式のデータ通信で有効に利用される。
【００２４】
プロトコル・エンティティ１７Ａおよび１７Ｂの各々は、バッファ１１０から読み出されたデータユニットから、送信先端末に接続された網のプロトコルに適合したパケットまたはフレームを生成する。送信部１８Ａまたは１８Ｂの各々は、そのパケットまたはフレームを送信先端末に奉仕する網へ送信する。
【００２５】
上記の構成の下、網２０に奉仕される送信元端末から、網３０に奉仕される送信先端末に送信されるべきデータユニットは、網２０を経てゲートウェイ１０に到着する。ゲートウェイ１０は、網２０において発生した遅延ジッタを削減しながら、データユニットを網３０に送信する。網３０に奉仕される送信元端末から、網２０に奉仕される送信先端末に送信されるべきデータユニットについても、同様にして網３０で発生した遅延ジッタが削減される。
【００２６】
以下、送信元端末を端末２１、送信先端末を端末３１と仮定する。端末２１から送信された各パケットは、網２０を通過することにより、異なる遅延時間を伴ってゲートウェイ１０で受信される。ゲートウェイ１０は、このような遅延ジッタを制御部１００において削減した後、網３０が従うプロトコルに従って送信する。
【００２７】
図２を参照しながら、制御部１００における受信した単一形式のデータユニットのバッファリングについて説明する。
本実施形態では、バッファ１１０は、連続した所定数（図２では９）のバッファレジスタ＃１〜＃９を備えている。バッファ１１０の各バッファレジスタは、１パケットの長さにほぼ相当する容量を有しており、１パケット内の中身を記憶する。一定の時間間隔をおいて、バッファレジスタ内のデータは制御部１００に順次読み出されて出力されるようになっている。その時間間隔の長さをINTとする。図２に示す時刻ｔｎ（ｔ１、ｔ２、ｔ３……）は時間間隔INTおきに離れている。
【００２８】
図２に示すバッファ１１０では、時刻ｔ１ではバッファレジスタ＃９に記憶されていたデータが出力される。時刻ｔ２ではバッファレジスタ＃１に記憶されていたデータが出力される。時刻ｔ３ではバッファレジスタ＃２に記憶されていたデータが出力される。時刻ｔ４ではバッファレジスタ＃３に記憶されていたデータが出力される。このように、隣接するバッファレジスタに記憶されているデータユニットは一定の時間間隔をおいて順次出力される。ただし、バッファレジスタに記憶されたデータがなければ何も出力されない。
【００２９】
このバッファ１１０において、図２に示すように、時刻ｔ１においてバッファレジスタ＃２にパケットＰ１のデータユニットが記憶されると仮定する。上述の方式に従って、バッファレジスタ＃２に記憶されたパケットＰ１のデータユニットは時刻ｔ３において出力される。従って、パケットＰ１のデータユニットはバッファ１１０に記憶されてから、時間２×INT後に出力されることになる。
【００３０】
図２とは異なり、時刻ｔ１において、バッファレジスタ＃１にパケットＰ１のデータユニットが記憶されると仮定する。バッファレジスタ＃１に記憶されたパケットＰ１のデータユニットは、上述の方式に従って、バッファ１１０に記憶されてから時間１×INT後の時刻ｔ２において出力される。
【００３１】
上記より理解できるように、バッファ１１０においては、パケットＰ１のデータユニットをバッファレジスタ＃２に記憶することによって、バッファレジスタ＃１に記憶するのに比べて、出力時間がバッファレジスタ１個分に相当する時間INTだけ遅延されることになる。
【００３２】
本実施形態では、網２０から受信した一つの形式のパケット中の先頭のパケットのデータユニットを記憶すべきバッファレジスタを制御部１００が決定することにより、先頭のパケットのデータユニットが記憶されてから出力されるまでの時間を調節し、網２０において発生する遅延ジッタを吸収する。より具体的には、先頭パケットのデータユニットが記憶されてから出力されるまでの時間が、吸収すべき遅延ジッタの幅分となるバッファレジスタを、制御部１００は先頭パケットのデータユニットのための初期書込位置として選択する（図２のステップＳ１，Ｓ２で示すように）。
【００３３】
制御部１００は、２番目以降のパケットのデータユニットについては、その時点であいているバッファレジスタの中で直後に読み出しの対象となるバッファレジスタに記憶する（図２のステップＳ３で示すように）。さらにまた、制御部１００は、受信部１４Ａにおけるパケットの受信順序が遅延ジッタにより、送信元端末での送信順序に一致していない時には、パケットのヘッダを参照して、その順序をそろえた後に、バッファ１１０に記憶する。
【００３４】
図２に戻り、時刻ｔ１において受信した先頭のパケットＰ１のデータユニットは初期書込位置であるバッファレジスタ＃２に記憶される。時刻ｔ２においてパケットが受信されず、時刻ｔ３において２番目のパケットＰ２が受信されたと仮定する。もしパケットＰ１，Ｐ２が送信元から続けて送信されたのであれば、パケットＰ１の遅延とパケットＰ２の遅延は、網２０のために、時間INTだけ異なったと考えられる。時刻ｔ３においては、パケットＰ２のデータユニットは、先に説明した方式に従って、その時点であいているバッファレジスタの中で直後に読み出しの対象となるバッファレジスタ＃３に記憶される。同時に、時刻ｔ３では、バッファレジスタ＃２に記憶されたパケットＰ１のデータユニットがバッファ１１０から読み出される。時刻ｔ３から時間INT後の時刻ｔ４においては、バッファレジスタ＃３に記憶されたパケットＰ２のデータユニットが、バッファ１１０から読み出される。
【００３５】
このように、パケットＰ２が、パケットＰ１の遅延よりも時間INTだけ長く遅延してゲートウェイ１０に到着した場合であっても、先頭のパケットＰ１のデータユニットの出力タイミングを時間INTだけ遅延させているので、パケットＰ１とＰ２のデータユニットは連続したタイミングで出力され、遅延ジッタが吸収される。上述の通り、パケットの順序は、制御部１００でそろえられるので、パケットＰ１とＰ２の送信時刻関係をそろえれば後のデータユニットについても同様に遅延ジッタが吸収される。
【００３６】
上述のバッファリングは、送信先の属する網３０では許容遅延ジッタがゼロという仮定に基づいている。しかし、送信先端末３１は網３０において発生すると想定された最大の遅延ジッタに相当する遅延ジッタを吸収できると仮定しよう。この場合、ゲートウェイ１０は、網２０で発生した遅延ジッタの全部を吸収する必要はないかもしれない。しかし、別の網２０で発生する遅延ジッタが網３０のそれより大きければ、端末３１は別の網２０において発生する遅延ジッタの全部を吸収できるとは限らない。そこで、ゲートウェイ１０のコントローラ１００は、予め獲得した端末３１のジッタ削減能力である許容遅延ジッタに応じて、実在の遅延ジッタのうちどれだけ吸収するか決定する。この場合のゲートウェイ１０の動作を後に詳述する。
【００３７】
また、図２では、網２０での遅延ジッタが１×INTであるが、実在の網では遅延ジッタは、もっと大きいかもしれない。例えば、図９は、遅延発生を示すグラフを示しており、上のグラフは送信元端末２１における送信時の遅延発生を示し、下のグラフは網２０を通過後ゲートウェイ１０における受信時のパケット遅延発生を示す。図９の上のグラフの直線Ｄ０に示すように、端末２１からの送信時においては、当然、すべてのパケットは遅延を持たず、この段階での遅延ジッタは存在しない。しかし、網２０を通過することにより、各パケットは、様々な遅延時間でゲートウェイ１０に到着する。図９の下のグラフの曲線Ｄ１に示すように、最大遅延時間＝４×INT、最小遅延時間＝０、遅延ジッタ＝最大遅延時間＝４×INTである。
【００３８】
図９で示すような、網２０で発生する４×INTの遅延ジッタの全てをバッファ１１０で吸収するには、図５に示すように、バッファレジスタ＃５が初期書込位置になる。
【００３９】
しかし、本実施形態では、上記のように、バッファ１１０において吸収すべき遅延ジッタの幅（バッファ吸収幅）は、網２０で発生する遅延ジッタと、あらかじめ獲得した網３０において許容される遅延ジッタとに基づいて、制御部１００が決定する。網３０における許容遅延ジッタが３×INTであれば、バッファ１１０では１×INT分の遅延ジッタを吸収すればよい。図４に示すように、この場合の初期書込位置はバッファレジスタ＃２でよい。
【００４０】
以下、網２０で発生する遅延ジッタの一部をバッファ１１０で吸収する動作を、全部を吸収する動作と比較しながら説明する。
図３に示すように、端末２１から送信された先頭のパケットＰ１が最小遅延時間（０）でゲートウェイ１０に受信され、次のパケットＰ２が最大遅延時間（４×INT）でゲートウェイ１０に受信されると仮定する。すなわち、図３に示すように、先頭のパケットＰ１が時刻ｔ１において端末２１から送信され、２番目のパケットＰ２が時刻ｔ２において端末２１から送信される。先頭のパケットＰ１は、最小遅延時間０ｓで網２０を通過してゲートウェイ１０に時刻ｔ１に到着し、２番目のパケットＰ２は、最大遅延時間４ｓで網２０を通過してゲートウェイ１０に時刻ｔ６に到着している。
【００４１】
上述の通り、図４に示すように、送信先の属する網３０で許容遅延ジッタが３INTである場合には、時刻ｔ１においてパケットＰ１のデータユニットはバッファレジスタ＃２に記憶される。従って、パケットＰ１のデータユニットはｔ１から２×INT後の時刻ｔ３においてバッファ１１０から出力される
【００４２】
これに対して、網２０で発生する遅延ジッタの全てをバッファ１１０で吸収する比較例では、上述の通り、パケットＰ１のデータユニットは図５に示すようにバッファレジスタ＃５に記憶すべきである。よって比較例では、パケットＰ１のデータユニットはｔ１から５×INT後の時刻ｔ６においてバッファ１１０から出力されるだろう。
【００４３】
最大遅延時間４ｓ遅延した時刻ｔ６においてゲートウェイ１０に到着する２番目のパケットＰ２のデータユニットは、図４および図５に示すように、あいているバッファレジスタの中で記憶の直後に制御部１００に読み出されるバッファレジスタ＃６に記憶され、時刻ｔ７において出力される。
【００４４】
送信先の属する網３０で許容遅延ジッタが３INTである場合には、図４に示すように、パケットＰ２のデータユニットはパケットＰ１のデータユニットが出力されてから４INT後に出力されるので、網２０において生じた遅延ジッタ４INTの一部である１INTがバッファ１１０において吸収され、３INTの遅延ジッタが残留したことになる。残留遅延ジッタは送信先端末３１で吸収される。この場合、図３に示すように、パケットＰ１が端末２１より送信された時刻からバッファ１１０からそのデータユニットが出力された時刻までの遅延時間＝２INTとなり、パケットＰ２が端末２１より送信された時刻からバッファ１１０からそのデータユニットが出力された時刻までの遅延時間＝５INTとなる。
【００４５】
これに対して、網２０で発生する遅延ジッタの全てをバッファ１１０で吸収する比較例では、図５に示すように、パケットＰ２のデータユニットはパケットＰ１のデータユニットが出力されてから１INT後に出力されるので、網２０において生じた遅延ジッタ４INTはバッファ１１０において全部吸収されたことになる。この場合、図３に示すように、パケットＰ１が端末２１より送信された時刻からバッファ１１０からそのデータユニットが出力された時刻までの遅延時間＝５INTとなり、パケットＰ２が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間＝５INTとなる。
【００４６】
次に、先頭のパケットが最大遅延時間で到着する場合のゲートウェイ１０のバッファリング動作について、図６ないし図８を参照しながら説明する。
図６に示すように、先頭のパケットＰ１が時刻ｔ１において端末２１から送信され、２番目のパケットＰ２が時刻ｔ２において端末２１から送信されると仮定する。先頭のパケットＰ１は、網２０において生じうる最大遅延時間４INTで時刻ｔ５にゲートウェイ１０に到着し、２番目のパケットＰ２は、最大遅延時間４INTで時刻ｔ６にゲートウェイ１０に到着する。仮に到着の順序が乱されても、制御部１００が順序を再度そろえるので、後のパケットが先のパケットより先に処理されることはない。
【００４７】
送信先の属する網３０で許容遅延ジッタが３INTである場合には、図７に示すように、時刻ｔ５においてパケットＰ１のデータユニットはバッファレジスタ＃２に記憶され、ｔ５から２INT後の時刻ｔ７においてバッファ１１０から出力される。そして、送信時刻ｔ２から最大遅延時間４INT遅延した時刻ｔ６においてゲートウェイ１０に到着する２番目のパケットＰ２のデータユニットは、その時点であいているバッファレジスタの中で最もはやく出力されるバッファレジスタ＃３に記憶され、２INT後の時刻ｔ８において出力される。図６に示すように、両方のパケットＰ１およびＰ２について、端末２１より送信された時刻からデータユニットがバッファ１１０から出力された時刻までの遅延時間＝６INTである。
【００４８】
これに対して、網２０で発生する遅延ジッタの全てをバッファ１１０で吸収する比較例では、図８に示すように、時刻ｔ５においてパケットＰ１のデータユニットはバッファレジスタ＃５に記憶され、パケットＰ１のデータユニットはｔ５から５INT後の時刻ｔ１０においてバッファ１１０から出力される。送信時刻ｔ２から最大遅延時間４INT遅延した時刻ｔ６においてゲートウェイ１０に到着する２番目のパケットＰ２のデータユニットは、その時点であいているバッファレジスタの中で最もはやく出力されるバッファレジスタ＃６に記憶され、５INT後の時刻ｔ１１において出力される。図６に示すように、両方のパケットＰ１およびＰ２について、端末２１より送信された時刻からそののデータユニットがバッファ１１０から出力された時刻までの遅延時間＝９INTである。
【００４９】
以上より理解できるように、ネットワークを接続するゲートウェイ１０に設けられたバッファ１１０を利用して、先頭のパケットのデータユニットについては受信してからある時間後に出力し、以降のデータユニットについては順次出力するようにすることにより、網２０で発生した遅延ジッタの全てまたは一部を吸収することができる。
【００５０】
以上のように、バッファ１１０により網２０で起こった遅延ジッタの全てを吸収する場合は、先頭のパケットが最小遅延で到着した場合でも、各パケットが端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間＝５INTとなる（図３参照）。先頭のパケットが最大遅延である場合には遅延時間＝９INTにもなる（図６参照）。端末２１〜端末３１間の総遅延時間は、パケットＰ１が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間および網３０において発生する最大遅延時間の累計である。従って、パケットＰ１が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間の増大により、総遅延時間が増大してしまう。
【００５１】
これに対して遅延ジッタを一部吸収した場合は、先頭のパケットが最小遅延である場合には、パケットＰ１が端末２１より送信された時刻からそのデータユニットがバッファ１１０から出力された時刻までの遅延時間＝２INTとなり、先頭のパケットが最大遅延である場合には遅延時間＝６INTになる（図３および図６参照）。このように、網３０において許容される遅延ジッタに基づいて、バッファ１１０で吸収すべき遅延を調整することにより、端末２１〜端末３１間の総遅延時間をより少なくすることができる。図３、図４および図７を参照しながら説明したように、遅延ジッタを一部だけ吸収した場合は、網２０において発生した遅延ジッタが部分的に残留する。しかし、この残留遅延ジッタは送信先端末３１で吸収される。
【００５２】
次に、マルチメディアに関わる複数形式のデータ通信へのこの実施形態の応用を説明する。
マルチメディア通信においては、プロトコル・エンティティ１５Ａまたは１５Ｂ（図１参照）は、対応する受信部１４Ａまたは１４Ｂで受信された複数形式のデータのうちの一つの形式のデータユニットと、他の形式のデータユニットから区別する。
【００５３】
また、各コントローラ１００の優先度決定部１２０は、データユニットの優先度を決定する。具体的には、優先度決定部１２０は、網３０へデータユニットを送信する順序を各データユニットの遅延ジッタに応じて決定する。
【００５４】
対応するプロトコル・エンティティ１７Ａまたは１７Ｂは、優先度決定部１２０から出力される優先度情報に基づいてバッファ１１０からの出力信号を多重送信のためにチャンネルにマップする。対応する送信部１８Ａまたは１８Ｂは、プロトコル・エンティティのマッピングに従ってデータユニットを網３０へ多重送信する。
【００５５】
図１０は、各制御部１００の内部機能エンティティを詳細に示す。以下の説明中、図１０で示すように、プロトコル・エンティティ１５Ａまたは１５Ｂはプロトコル・エンティティ１５と呼び、プロトコル・エンティティ１７Ａまたは１７Ｂはプロトコル・エンティティ１７と呼ぶ。
【００５６】
図１０に示すように、バッファ１１０は音声バッファ１１１および画像バッファ１１２を備える。
【００５７】
音声バッファ１１１は、プロトコル・エンティティ１５から出力された音声データパケットのデータユニットを記憶し、画像バッファ１１２は、プロトコル・エンティティ１５から出力された画像データパケットのデータユニットを記憶する。各バッファから読み出されたデータユニットは別々にプロトコル・エンティティ１７に供給される。
【００５８】
また、バッファ１１１または１１２の各々から出力されたデータユニットは優先度決定部１２０にも供給されるようになっている。優先度決定部１２０は、出力時刻検出部１２２と、遅延時間算出部１２３と、判定部１２４とを有する。
出力時刻検出部１２２は、ゲートウェイ１０の内部クロックに基づいてバッファ１１０からの最初の音声データユニットの出力時と最初の画像データユニットの出力時を検出し、これを遅延時間算出部１２３に出力する。音声バッファ１１１から出力された最初の音声データユニットの出力時刻をＢｓ（Ａ）、画像バッファ１１１から出力された最初の画像データユニットの出力時刻をＢｓ（Ｖ）と呼ぶ。
【００５９】
遅延時間算出部１２３は、プロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ(A)を算出する。標準出力時刻Ｓｓ(A)は、遅延がなければ、その音声データユニットがバッファ１１０から出力されているべき時刻であり、最初の音声データユニットの音声バッファ出力時刻Ｂｓ(A)を起算点とする。さらに、現在時刻Ｃｔとプロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ（Ａ）の時間差を音声遅延時間Ｄ（Ａ）として算出して判定部１２４に出力する。また、遅延時間算出部１２３は、プロトコル・エンティティ１７から未送信の画像データユニットの標準出力時刻Ｓｓ(Ｖ)を算出する。標準出力時刻Ｓｓ(Ｖ) は、遅延がなければ、その画像データユニットがバッファ１１０から出力されているべき時刻であり、最初の画像データユニットの画像バッファ出力時刻Ｂｓ(Ｖ)を起算点とする。さらに、現在時刻Ｃｔとプロトコル・エンティティ１７から未送信の画像データユニットの標準出力時刻Ｓｓ（Ｖ）の時間差を画像遅延時間Ｄ（Ｖ）として算出して判定部１２４に出力する。音声遅延時間Ｄ（Ａ）および画像遅延時間Ｄ（Ｖ）は、最初の音声または画像データユニットに対する各データユニットの遅延時間を比較するには十分な指標である。
【００６０】
例えば、音声バッファ１１１と画像バッファ１１２から音声データユニットと画像データユニットが同時に読み出された場合など、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合、判定部１２４は、音声遅延時間Ｄ（Ａ）および画像遅延時間Ｄ（Ｖ）を比較し、その比較に基づいて、プロトコル・エンティティ１７における送信の優先度を制御するための送信制御指令を作成し、これをプロトコル・エンティティ１７に出力する。
【００６１】
図１１に示すフローチャートを参照しながら、優先度決定部１２０における優先度決定処理を説明する。この図示した処理は、１INTおきに繰り返される。
まず、ステップＳ１１で、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合、遅延時間算出部１２３は、最初の音声データユニットの音声バッファ出力時刻Ｂｓ(Ａ)に基づいて、プロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ(A)を式（１）に従い算出する。
Ss(A) ＝ Bs(A) + (N(A) − 1) × Cy(A)・・・・・（１）
ここで、N(A)は音声データユニットの順序を示す番号であり、Cy(A)は端末２１による音声パケットの送信サイクルを示す。
【００６２】
また、ステップＳ１１で、遅延時間算出部１２３は、最初の画像データユニットの画像バッファ出力時刻Ｂｓ(Ｖ)に基づいて、プロトコル・エンティティ１７から未送信の音声データユニットの標準出力時刻Ｓｓ(Ｖ)を式（２）に従い算出する。
Ss(V) ＝ Bs(V) + (N(V) − 1) × Cy(V)・・・・・（２）
ここで、N(V)は画像データユニットの順序を示す番号であり、Cy(V)は端末２１による画像パケットの送信サイクルを示す。
【００６３】
ステップＳ１２で、遅延時間算出部１２３は、画像データユニットの標準出力時刻Ｓｓ(V)と現在時刻Ｃｔに基づいて式（３）に従い、そのデータユニットの遅延時間Ｄ（Ｖ）を算出する。
D(V) = Ct − Ss(V)・・・・・（３）
【００６４】
ステップＳ１３で、遅延時間算出部１２３は、音声データユニットの標準出力時刻Ｓｓ(V)と現在時刻Ｃｔに基づいて式（４）に従い、そのデータユニットの遅延時間Ｄ（Ａ）を算出する。
D(A) = Ct − Ss(A)・・・・・（４）
【００６５】
次に判定部１２４は、ステップＳ１４で、音声遅延時間Ｄ（Ａ）が画像遅延時間Ｄ（Ｖ）よりも大きいか否かを判定する。ステップＳ１４の判定が肯定的であれば、ステップＳ１５で、判定部１２４はその音声データユニットを優先して送信することを指示する送信制御指令を判定部１７に供給する。一方、ステップＳ１４の判定が否定的であれば、ステップＳ１６で、判定部１２４はその画像データユニットを優先して送信することを指示する送信制御指令を判定部１７に供給する。このようにして処理は終了し、その後繰り返される。
【００６６】
次に、図１２および図１３に示すタイムチャートを参照しながら、マルチメディア通信におけるパケットの処理を具体的に説明する。図１２および図１３において、文字A,Vはそれぞれ音声パケット、画像パケットに対応するデータユニットを示し、添え字は端末２１からの送信順序を示す。
【００６７】
まず、端末２１からの各パケットの送信の態様およびバッファ１１０からの各パケットの出力の態様は、図１２および図１３に示すようなものであると仮定する。すなわち、端末２１からの各形式のパケットにかかるデータユニットは、上述したように網２０で発生した遅延ジッタの一部だけをバッファ１１１または１１２で吸収するやり方で、ゲートウェイ１０でバッファリングされてバッファ１１０から出力される。このため、図１２および図１３に示すように、音声パケットＡの送信サイクルが３INTであるのに、パケットＡ１から４INTの後にパケットＡ２のデータユニットがバッファから出力され、画像パケットＶの送信サイクルが５INTであるのに、パケットＶ１から６INTの後にパケットＶ２のデータユニットがバッファから出力される。
【００６８】
音声バッファ１１１、画像バッファ１１２において、音声と画像データユニットの遅延ジッタが全部吸収された場合には、全ての音声データユニット、画像データユニットは送信元端末２１から網２０への送信サイクルと同じサイクルで出力されるはずである。従って、遅延ジッタの一部だけをバッファで吸収したがゆえに、２番目以後の音声データ群には１INTの遅延ジッタ、２番目以後の画像データ群には１INTの遅延ジッタが残留していることが図１２および図１３から理解できよう。
【００６９】
さらに、プロトコル・エンティティ１７により音声と画像のデータユニットを単一チャネルに多重して網３０に送信するために、この多重によっても遅延が生ずる。従って、上述したバッファ１１０からの出力時の残留した遅延ジッタに、多重による遅延ジッタが重畳されて、プロトコル・エンティティ１７からの出力データユニットの遅延ジッタが広がる場合がある。
【００７０】
プロトコル・エンティティ１７による多重における遅延ジッタは、異なる種類に属するデータユニットの送信順序に大きく影響を受ける。より具体的には、図１２および図１３に示すように、音声パケットは同一のデータ長であって等間隔３INTで端末２１から送信されるのに対して、画像パケットはそれぞれ長さが異なっており、しかもそれらの長さが音声パケットの長さに比較して大きく、等間隔５INTで送信される。このような場合は、ゲートウェイ１０では、長い画像データユニットの送信中では音声データユニットを出力するのが好ましい時でも、音声データユニットを送信できない。従って、多重の方式に工夫を加えないと、音声データユニットに多重による遅延が生じうる。そして、残留している音声データユニットの遅延ジッタと多重の際の遅延によって、さらに遅延ジッタが広がることがありうる。
【００７１】
多重の方式には、様々なものが考えられる。例えば、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合に、多重の際に画像データユニットを常に音声データユニットよりも優先することが考えられうる。逆に、そのような場合に、多重の際に音声データユニットを常に画像データユニットよりも優先することも考えられうる。これらの方式には以下に述べるように欠点がある。
【００７２】
図１２において、時刻ｔ１３では、音声パケットＡ４のデータユニットが音声バッファ１１１から出力され、画像パケットＶ３のデータユニットが画像バッファ１１２から出力される。また、この時には、以前の音声パケットＡ３のデータユニットがすでに音声バッファ１１１から出力されているのに、プロトコル・エンティティ１７から送信されていない。別の時刻ｔ１８では、画像パケットＶ４のデータユニットが画像バッファ１１２から出力され、未送信の音声パケットＡ５のデータユニットが存在する。
【００７３】
音声パケットを常に優先する方式では、図１２および図１３に示すように、プロトコル・エンティティ１７からは、時刻ｔ１３において音声パケットＡ３のデータユニットが送信され、時刻ｔ１４において音声パケットＡ４のデータユニットが送信されて、時刻ｔ１５に至ってやっと画像パケットＶ３のデータユニットが出力される。従って、画像パケットＶ３のデータユニットは端末２１から送信された時刻ｔ１１から４INT遅延して網３０に送信されることになる。同様に、時刻ｔ１８では音声パケットＡ５のデータユニットが優先され、時刻ｔ１９では新音声パケットＡ６のデータユニットが優先されるので、画像パケットＶ４のデータユニットは端末２１から送信された時刻ｔ１６から４INT遅延して時刻ｔ２０に網３０に送信される。しかし、最初の画像パケットＶ１のデータユニットは、図１２に示すように、端末２１から送信された時刻ｔ１から１INTだけ遅延して時刻ｔ２に網３０に出力される。
【００７４】
画像データユニットを常に優先する方式では、図１２および図１３に示すように、時刻ｔ１３においてプロトコル・エンティティ１７からは、画像パケットＶ３のデータユニットの送信が開始され、時刻ｔ１４、ｔ１５では画像パケットＶ３のデータユニットの送信を継続する。時刻ｔ１０において音声バッファ１１１から出力される音声パケットＡ３のデータユニット、時刻ｔ１３において音声バッファ１１１から出力される音声パケットＡ４のデータユニットは、画像パケットＶ３のデータユニットの送信が終了した後に、送信される。従って、音声パケットＡ３のデータユニットは端末２１から送信された時刻ｔ７から９INTも遅延して時刻ｔ１６に網３０に送信され、音声パケットＡ４のデータユニットは端末２１から送信された時刻ｔ１０から７INT遅延して時刻ｔ１７に網３０に送信されることになる。同様に、時刻ｔ１８では画像パケットＶ４のデータユニットが優先されるので、音声パケットＡ５のデータユニットは端末２１から送信された時刻ｔ１３から９INTも遅延して時刻ｔ２２に網３０に送信され、音声パケットＡ６のデータユニットは端末２１から送信された時刻ｔ１６から７INT遅延して時刻ｔ２３に網３０に送信される。しかし、最初の音声パケットＡ１のデータユニットは、端末２１から送信された時刻ｔ１から５INTだけ遅延して時刻ｔ６に網３０に出力される。
【００７５】
以上のように、いずれか一方の群のデータユニットを常に優先させた場合は、網２０で発生した遅延ジッタに対して、さらにプロトコル・エンティティ１７における多重による遅延ジッタが重畳されて、網３０への送信の際に遅延ジッタが広がってしまう。
【００７６】
図１４は、マルチメディア通信における遅延の発生を示す。曲線Ｄ１は網２０を通過することに生ずる遅延ジッタを示しており、図９の下のグラフの曲線Ｄ１と等価である。曲線Ｄ３は、バッファ１１０で一部が吸収された残りの遅延ジッタを示しており、この残りの遅延ジッタはバッファでの吸収分だけ曲線Ｄ１の網２０通過後の遅延ジッタより小さい。曲線Ｄ２１は、いずれか一方の群のデータ形式を常に優先させた場合の網３０への多重送信の際の遅延ジッタを表す。曲線Ｄ２１により明らかなように、せっかくバッファ１１０で遅延ジッタの一部が吸収されても、多重による遅延ジッタが重畳されて、網３０への送信の際に遅延ジッタが広がってしまうことがわかる。
【００７７】
本実施形態では、パケットの遅延ジッタをより少なくするために、多重送信における各データユニットの優先度を遅延時間に応じて決定する。より具体的には、バッファ１１０から出力されたがプロトコル・エンティティ１７から未送信の音声データユニットと画像データユニットが同時に存在する場合には、その時点で最初の同種データユニットに対する遅延時間が大きいデータユニットを優先する。この実施形態の処理を次に具体的に説明する。
【００７８】
図１２および図１３において、時刻ｔ１３では、未送信の音声パケットのデータユニットＡ３の遅延時間Ｄ（Ａ３）＝４INTであり、未送信の画像パケットのデータユニットＶ３の遅延時間Ｄ（Ｖ３）＝１INTである。図１２および図１３中の遅延時間Ｄ（Ａ），Ｄ（Ｖ）については、上述の式（１）ないし（４）で算出される。本実施形態では、時刻ｔ１３で、優先度決定部１２０は遅延時間の大きな音声パケットＡ３のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。
【００７９】
時刻ｔ１４においては、未送信の音声パケットＡ４のデータユニットの遅延時間Ｄ（Ａ４）＝２INTであり、画像パケットＶ３のデータユニットの遅延時間Ｄ（Ｖ３）＝２INTで同じである。本実施形態では、図１１のステップＳ１４で表される規則に従って、優先度決定部１２０は音声パケットＡ４のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。従って、時刻ｔ１３で音声パケットＡ３のデータユニット、時刻ｔ１４で音声パケットＡ４のデータユニット、時刻ｔ１５で画像パケットＶ３のデータユニットが送信される。この様子は音声データユニットを常に優先させる方式と同じである。しかし、時刻ｔ１３〜ｔ１７の間の時間においては、画像データユニットを優先させる方式よりも音声パケットＡ３，Ａ４のデータユニットに関して遅延ジッタの増加は少ない。
【００８０】
時刻ｔ１８では、未送信の音声パケットＡ５のデータユニットの遅延時間Ｄ（Ａ５）＝３INTであり、画像パケットＶ４のデータユニットの遅延時間Ｄ（Ｖ４）＝１INTである。よって、本実施形態では、優先度決定部１２０は遅延時間の大きな音声パケットＡ５のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。
【００８１】
時刻ｔ１９では、未送信の音声パケットＡ６のデータユニットの遅延時間Ｄ（Ａ６）＝１INTであり、画像パケットＶ４のデータユニットの遅延時間Ｄ（Ｖ４）＝２INTである。よって、本実施形態では、優先度決定部１２０は遅延時間の大きな画像パケットＶ４のデータユニットの優先度が高いことを示す送信制御信号をプロトコル・エンティティ１７に出力する。そして、時刻ｔ２３で、音声パケットＡ６のデータユニットが送信される。
【００８２】
従って、音声パケットＡ５のデータユニットは端末２１から送信された時刻ｔ１３から５INT遅延して時刻ｔ１８に網３０に送信され、画像パケットＶ４のデータユニットは端末２１から送信された時刻ｔ１６から３INT遅延して時刻ｔ１９に網３０に送信され、音声パケットＡ６のデータユニットは端末２１から送信された時刻ｔ１６から７INT遅延して時刻ｔ２３に網３０に送信される。従って、音声データユニットを優先させる方式よりも画像パケットＶ４のデータユニットに関して遅延ジッタの増加は少ない。
【００８３】
図１４の曲線Ｄ２２は、本実施形態に従って、遅延時間に応じてパケットの優先度を決定した場合の網３０への多重送信の際の遅延ジッタを表す。曲線Ｄ２１とＤ２２とを比較すると明らかなように、本実施形態では、遅延ジッタの増加をより抑制することができ、網３０への多重送信の際の遅延ジッタが残留遅延ジッタ（曲線Ｄ３の幅）に近づく。
【００８４】
この多重送信の際の遅延ジッタは、送信先の端末３１が吸収可能な許容遅延ジッタ以下であるのが好ましい。よって、マルチメディア通信において多重の前に送信先の許容遅延ジッタに基づいて決定されるバッファで吸収する遅延ジッタの量は、単一形式のデータを転送する場合の遅延ジッタの量よりも多くするのが効果的である。
【００８５】
以上、好適な実施形態を参照しながら本発明を説明したが、特許請求の範囲で定められる本発明の範囲から逸脱せずに、形式および細部の様々な変更ができることは当業者には理解できよう。かかる変更形態、代替形態および修正形態も、均等物として特許請求の範囲に含まれる。かかる均等物の例を次に説明する。
【００８６】
パケット交換網である網２０に関しては、ネットワーク遅延のために、マルチメディア通信における異なる形式のパケット相互の順序の乱れが起こりやすいが、回線交換網である網３０に関しては、ネットワーク遅延が起こりにくく、異なる形式のフレーム相互の順序の乱れは生じにくい。従って、図１の実施形態とは異なり、上述の利点を有する回線交換網３０から転送されたフレームを取り扱う伝送系列ＢＡには優先度決定部１２０を設けないことも可能である。
【００８７】
遅延ジッタを吸収するための要素は、バッファ１１０に限定されない。送信先端末の許容遅延ジッタに応じた時間だけ先頭のデータユニットを保留し、後続のデータユニットを正規の順序に従って順次出力できる他の要素を使用することができる。
【００８８】
上記実施形態においては、マルチメディア通信においては、単に、遅延時間の大きいデータユニットに高い優先度を与える。しかし、３つ以上の形式のデータを送信する場合には、一つまたはそれより多い形式のデータに高い優先度をあらかじめ与え、他の形式のデータに関しては、遅延時間の大きいデータユニットに次に高い優先度を与えてもよい。
【００８９】
遅延時間の代わりに、データユニットの長さに基づいて、優先度を与えるデータユニットを決定できるようにしてもよい。
長いデータユニットを送信中に、遅延時間の大きな短いデータユニットの出力タイミングになった場合は、割り込み送信できるようにしても構わない。場合によっては、このような割り込み送信は、さらに遅延ジッタを小さくすることができるかもしれない。この目的のため、例えば、ＩＴＵ−Ｔ勧告Ｈ．２２３に記載されているように、長いデータユニットをセグメント化するとよい。これによれば、長い画像データユニットの送信を中断し、短い音声データユニットを送信した後も、残りのセグメントを支障なく送ることができる。
【００９０】
上述の実施形態では、網２０はパケット交換網であり、網３０は回線交換網であるが。ただし、本発明をこれに限定する意図ではなく、変更・修正が可能である。遅延のジッタが生じる原因には、ネットワークの諸要因と、端末やゲートウェイにおける多重化がある。パケット交換網では、ネットワークの諸要因により遅延ジッタが生じうる。一方、回線交換網では、ネットワークの諸要因による遅延ジッタは生じにくいが、端末やゲートウェイにおける多重化により遅延ジッタが残ったままフレームが交換される。パケット交換網における遅延ジッタは、端末やゲートウェイにおける多重化により生じる遅延ジッタよりも一般的には大きい。一般的には、各網に奉仕される端末は、送信先となったときに、その網で生じうる最大遅延ジッタを吸収できるようになっている。
【００９１】
図１５に示すように、網２０および網３００がいずれもパケット交換網で、パケット交換網２０で生じうる最大遅延ジッタがパケット交換網３００で生じうる最大遅延ジッタよりも大きい変更形態を想定する。網２０に奉仕される端末が送信元で、網３００に奉仕される端末が送信先である場合には、上記実施形態と同様に、送信先の端末３１のジッタ削減能力に応じてゲートウェイ１０が送信元側の網２０で生じた遅延ジッタのうちの一部を吸収するのが有効である。
【００９２】
ただし、起こりうる遅延ジッタが小さい網３００に奉仕される端末が送信元で、起こりうる遅延ジッタが大きい網２０に奉仕される端末が送信先であって、送信先端末のジッタ削減能力が高い場合には、送信元側の網３００で生じた遅延ジッタをゲートウェイ１０で吸収する必要は少ないかもしれない。そのような場合には、網３００から網２０へデータを転送する伝送系列ＢＡにはデジッタ用の要素を設けなくてもよい。
【００９３】
上記実施形態を参照して説明したように、送信元側の網２０がパケット交換網であり、送信先側の網３０が回線交換網である場合には、送信先の端末３１のジッタ削減能力に応じてゲートウェイ１０が送信元側の網２０で生じた遅延ジッタのうちの一部を吸収するのが有効である。ただし、起こりうる遅延ジッタが小さい回線交換網３０に奉仕される端末が送信元で、起こりうる遅延ジッタが大きいパケット交換網２０に奉仕される端末が送信先であって、送信先端末のジッタ削減能力が高い場合には、送信元側の網３０で生じた遅延ジッタをゲートウェイ１０で吸収する必要は少ないかもしれない。そのような場合には、伝送系列ＢＡにはやはりデジッタ用の要素を設けなくてもよい。
【００９４】
上述の通り、回線交換網では、ネットワークの諸要因による遅延ジッタは生じにくいが、端末やゲートウェイにおける多重化により遅延ジッタが残ったままフレームが交換される。従って、回線交換網に属する送信先端末で許容され、バッファでの吸収量を定めるためのパラメータとなる遅延ジッタは、その網で多重化により起こりうる最大遅延時間と等しくしてもよい。
【００９５】
上記の実施形態では、送信先端末は、ゲートウェイ１０に接続された第２の網３０に直接的に奉仕される。しかし、送信先端末は、網３０に間接的に奉仕されてもよい。つまり、送信先端末と網３０との間に、一つまたは複数の網と、隣合う網の相互を接続する他のゲートウェイが介在していてもよい。
【００９６】
【発明の効果】
以上説明したように、本発明によれば、ジッタを削減することにより、遅延の増加を最小限にすることができる。
【図面の簡単な説明】
【図１】 本発明の実施形態に係るゲートウェイを示すブロック図である。
【図２】 図１のゲートウェイ内のバッファの動作を示す図である。
【図３】 先頭のパケットが最小遅延時間で到着した場合の、図１のゲートウェイにおけるデータユニットの処理を示すタイムチャートである。
【図４】 先頭のパケットが最小遅延時間で到着した場合の上記バッファにおけるデータユニットの処理を示す図である。
【図５】 先頭のパケットが最小遅延時間で到着した場合の上記バッファにおけるデータユニットの別の処理を示す図である。
【図６】 先頭のパケットが最大遅延時間で到着した場合の、図１のゲートウェイにおけるデータユニットの処理を示すタイムチャートである。
【図７】 先頭のパケットが最大遅延時間で到着した場合の上記バッファにおけるデータユニットの処理を示す図である。
【図８】 先頭のパケットが最大遅延時間で到着した場合の上記バッファにおけるデータユニットの別の処理を示す図である。
【図９】 ネットワーク遅延の発生を示すグラフを有する。
【図１０】 図１に示す各制御部の内部機能エンティティを示すブロック図である。
【図１１】 マルチメディア通信における上記制御部の中の優先度決定部の処理を示すフローチャートである。
【図１２】 マルチメディア通信における、図１のゲートウェイの中のデータユニットの処理を示すタイムチャートの一部である。
【図１３】 図１２と共同で上記タイムチャートを構成する。
【図１４】 上記実施形態のマルチメディア通信への応用の効果を説明するための図である。
【図１５】 本発明の変更形態を示す図である。
【符号の説明】
１０…ゲートウェイ、１４Ａ，１４Ｂ…受信部、１８Ａ，１８Ｂ…送信部、２０，３０…網（ネットワーク）、１００…制御部、１２２…出力時刻検出部、１２２…遅延時間算出部、ＡＢ，ＢＡ…伝送系列（獲得部）
Claims (7)
- 二つのネットワークを接続するゲートウェイであって、
少なくとも一つの形式の複数のデータユニットを第１のネットワークから受信する受信部と、
前記受信部で受信した前記データユニットを一時的に記憶し、送信先端末の遅延ジッタ削減能力に基づいてある時間を決定し、前記受信部において先頭のデータユニットを受信した時刻からその決定した時間が経過した後に前記先頭のデータユニットを出力し、その後、前記第１のネットワークにおける送信サイクルと同じサイクルで後続のデータユニットを順次出力する制御部と、
前記制御部で出力されたデータユニットに対応するデータユニットを前記送信先端末に届けるために第２のネットワークに送信する送信部と
を備えるゲートウェイ。 - 請求項１記載のゲートウェイであって、
前記送信先端末の前記遅延ジッタ削減能力に関する情報を獲得する獲得部をさらに備えるゲートウェイ。 - 請求項１または２記載のゲートウェイであって、
前記受信部は、異なる形式のデータユニットを受信することが可能であり、
異なる形式のデータユニットが同時に未送信である時に、前記制御部は、前記第１のネットワークにおいて前記データユニットが伝送される際に生じた遅延時間に応じて前記送信部における優先度を決定し、
前記送信部は、前記制御部から出力された形式の異なるデータユニットを、前記優先度に従って多重化して前記第２のネットワークを通じて前記送信先端末に送信する、ゲートウェイ。 - 請求項３記載のゲートウェイであって、
前記制御部は、
各形式における最初のデータユニットが前記制御部から出力された最初出力時刻を検出する出力時刻検出部と、
前記最初出力時刻に基づいた各データユニットの前記遅延時間を算出する遅延時間算出部とを備え、
前記制御部は、算出された前記遅延時間が長いと判定されたデータユニットについては、他のデータユニットに優先して送信するように前記優先度を決定する、ゲートウェイ。 - 請求項１に記載のゲートウェイであって、
前記制御部は、前記第１のネットワークにおいて前記データユニットが伝送される際に生じうる最大遅延時間を、前記送信先端末において許容される遅延ジッタに応じて短縮して前記時間を求めることを特徴とするゲートウェイ。 - 少なくとも一つの形式の複数のデータユニットを第１のネットワークから受信することと、
前記データユニットを一時的に記憶することと、
あらかじめ獲得した送信先端末のジッタ削減能力に基づいてある時間を決定することと、
先頭のデータユニットを受信した時刻からその決定した時間が経過した後に前記先頭のデータユニットを出力することと、
前記第１のネットワークにおける送信サイクルと同じサイクルで後続のデータユニットを順次出力すること
前記データユニットに対応するデータユニットを前記送信先端末に届けるために第２のネットワークに送信すること
とを備えるデータ転送方法。 - 請求項６に記載の方法であって、
前記受信は、異なる形式のデータユニットを受信することを備えており、
この方法は、さらに、
異なる形式のデータユニットが同時に未送信である時に、前記制御部は、前記第１のネットワークにおいて前記データユニットが伝送される際に生じた遅延時間に応じて前記送信部における優先度を決定することを備え、
前記第１のネットワークにおいて発生した遅延時間が長い程、対応するデータユニットが優先的に第２のネットワークに送信されるようにした、方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000285900A JP3694451B2 (ja) | 1999-09-22 | 2000-09-20 | ゲートウェイおよびデータ転送方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11-268533 | 1999-09-22 | ||
| JP26853399 | 1999-09-22 | ||
| JP2000285900A JP3694451B2 (ja) | 1999-09-22 | 2000-09-20 | ゲートウェイおよびデータ転送方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001160830A JP2001160830A (ja) | 2001-06-12 |
| JP3694451B2 true JP3694451B2 (ja) | 2005-09-14 |
Family
ID=26548355
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000285900A Expired - Fee Related JP3694451B2 (ja) | 1999-09-22 | 2000-09-20 | ゲートウェイおよびデータ転送方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3694451B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4454338B2 (ja) | 2004-02-17 | 2010-04-21 | 富士通株式会社 | パケット整形装置及びパケット整形方法 |
| JP4539264B2 (ja) * | 2004-09-27 | 2010-09-08 | ソニー株式会社 | 情報処理装置および方法、並びにプログラム |
| JP6229985B2 (ja) | 2013-03-12 | 2017-11-15 | パナソニックＩｐマネジメント株式会社 | バスシステムおよびコンピュータプログラム |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2984910B2 (ja) * | 1995-11-17 | 1999-11-29 | 株式会社超高速ネットワーク・コンピュータ技術研究所 | データフロー制御方法 |
| JP3213697B2 (ja) * | 1997-01-14 | 2001-10-02 | 株式会社ディジタル・ビジョン・ラボラトリーズ | 中継ノードシステム及び同システムにおける中継制御方法 |
| JPH1117739A (ja) * | 1997-06-19 | 1999-01-22 | Mitsubishi Electric Corp | フレームリレールータおよびフレームリレー通信装置 |
| JP3305242B2 (ja) * | 1997-11-06 | 2002-07-22 | キヤノン株式会社 | 通信装置 |
| JP3506960B2 (ja) * | 1999-08-03 | 2004-03-15 | シャープ株式会社 | パケット処理装置及びパケット処理プログラムを記録した記憶媒体 |
-
2000
- 2000-09-20 JP JP2000285900A patent/JP3694451B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001160830A (ja) | 2001-06-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0446956B1 (en) | An ATM transmission system with a variable transmission rate | |
| US6085252A (en) | Device, system and method for real-time multimedia streaming | |
| JP3882187B2 (ja) | フロー制御システムおよび方法 | |
| US5534937A (en) | Minimum-delay jitter smoothing device and method for packet video communications | |
| EP1087579B1 (en) | Gateway for reducing delay jitter and method for data transfer therein | |
| EP1845691B1 (en) | Media stream relay device and method | |
| US9288008B2 (en) | Systems and methods for equalizing retransmission delays for data retransmission over bonded modems | |
| US8503325B2 (en) | Packet transfer device and packet transfer method | |
| JP2004519124A (ja) | 受動的同軸分配などの共用伝送媒体における電話方式、レイテンシ敏感データ、ベスト・エフォート型データ及びビデオ・ストリームのための優先パケット伝送システム | |
| JP3694451B2 (ja) | ゲートウェイおよびデータ転送方法 | |
| JP2002077245A (ja) | Ｉｐゲートウェイ装置 | |
| JP4342585B2 (ja) | パケット中継装置及びパケット中継方法 | |
| US7321557B1 (en) | Dynamic latency assignment methodology for bandwidth optimization of packet flows | |
| WO2011026508A1 (en) | Method for distributing data traffic over radio links | |
| JP2000307637A (ja) | マルチメディア端末装置及び網間接続装置 | |
| US7330461B2 (en) | Method to control data conversion in the transfer of a connection between a packet-switched and a line-switched communications network | |
| US20070136494A1 (en) | Method for connection between communication networks of different types and gateway apparatus | |
| US6741656B1 (en) | Image communication apparatus | |
| US7088738B1 (en) | Dynamic fragmentation of information | |
| US8379675B2 (en) | Jitter buffering control for controlling storage locations of a jitter buffer, and a method therefor | |
| US6931029B1 (en) | System and method for synchronizing with data received over an unreliable asynchronous medium | |
| US7843946B2 (en) | Method and system for providing via a data network information data for recovering a clock frequency | |
| JP2004282584A (ja) | ネットワークを経由した動画データ通信システム | |
| JP2005519541A (ja) | 第１データストリームを第２データストリームに変換する方法及び装置 | |
| JP2004023514A (ja) | ファクシミリ中継伝送装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050413 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050419 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050531 |
|
| 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: 20050621 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050624 |
|
| 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: 20080701 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090701 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090701 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100701 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110701 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |