JP2004186882A

JP2004186882A - 通信装置および通信方法

Info

Publication number: JP2004186882A
Application number: JP2002349981A
Authority: JP
Inventors: Tomokazu Suda; 智一須田; Junichi Komagata; 淳一駒形; Hideki Yoshida; 英喜吉田
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2002-12-02
Filing date: 2002-12-02
Publication date: 2004-07-02

Abstract

【課題】ネットワーク上にパケットを等間隔で送出するときにバッファがオーバーフローすることを防止する。
【解決手段】ＭＰＥＧ２のＴＳパケットがＲＴＰ回路１によってＲＴＰプロトコルにしたがってパケット化され、次に、プロトコルスタックおよびルータ回路２によって、ＵＤＰでさらにパケット化される。プロトコルスタック部でＵＤＰヘッダ、ＩＰヘッダおよびＤＩＸヘッダが順に付加される。次に、ルータ部でＤＩＸヘッダがタグ付きＤＩＸヘッダへ変更される。ＴＳバッファ１３を有するトラフィックシェーパ３がパケット化されたデータをスケジューリングしてネットワークコントローラ４に対して出力する。信号路６を介してＴＳバッファ１３の使用状況の情報がＲＴＰ回路１に対して知らされ、ＲＴＰ回路１は、パケット化出力のタイミングを遅らせたり、一時的に停止し、ＴＳバッファ１３のオーバーフローを防止する。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
この発明は、例えばＡＶ（ＡｕｄｉｏＶｉｓｕａｌ）データ等のリアルタイムデータをネットワークに送出する場合に、均等且つ適切な間隔で順番にパケットを送出する機能を有する通信装置および通信方法に関する。
【０００２】
【従来の技術】
インターネットを介してＡＶストリームデータを家庭に配信し、家庭において、受け取ったＡＶストリームデータを家庭内のＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）を通じて端末装置に送信し、端末装置によってストリーミング再生するようなシステムが考えられている。ＬＡＮとしては、ＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）８０２．１１ａ，ＩＥＥＥ８０２．１１ｂ等のワイヤレスＬＡＮ、イーサネット（登録商標）等が使用されている。また、ＡＶストリームデータの送受信するためにＲＴＰ（Ｒｅａｌ−ＴｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ：リアルタイム転送プロトコル）というプロトコルが利用される。
【０００３】
ＡＶストリームデータを送受信する場合、パケット間隔が一定ではなく、バースト状になったり、バラバラの間隔になったりすることがある。このような状況では、受信端末側に設けられている受信バッファがオーバーフローまたはアンダーフローすることがあり、オーバーフローの結果、パケットの欠落が発生し、アンダーフローの結果、ＡＶデータの復号時に期限切れとなってＡＶデータが捨てられる。結果的に映像や音声が途切れ、高品位なＡＶストリームデータを伝送することができない問題が生じる。受信側に充分大きな容量の受信バッファを備えれば、オーバーフローまたはアンダーフローのおそれを少なくできるが、受信側装置の価格が高くなる問題が生じる。
【０００４】
このような問題が発生しないように、例えば送信側にトラフィックシェーパが設けられる。トラフィックシェーパは、送出されるパケットがバースト状に転送されたり、不均一な間隔でパケットが送出されるのを防ぐために、均等な間隔でパケットを送出する機能を有する。従来では、ＭＰＥＧエンコーダが圧縮した画像データをイーサネットに送出する場合に、ネットワーク上でパケットの衝突や消失が生じることによって、クライアント側での再生画像が乱れることを防止するための方法が下記の特許文献１に記載されている。
【０００５】
【特許文献１】
特開２００１−８６４９９号公報
【０００６】
この特許文献１では、ＭＰＥＧ圧縮回路のＦＩＦＯ（Ｆｉｒｓｔ−ＩｎＦｉｒｓｔ−Ｏｕｔ）メモリと、ＤＲＡＭ上に確保したメモリ領域と、イーサネット回路のメモリの内で、ＤＲＡＭ上に確保したメモリ領域と、イーサネット回路のメモリの使用量を減らし、全体のメモリ使用量をできるだけＭＰＥＧ圧縮回路のＦＩＦＯメモリに集約させ、ＦＩＦＯメモリの使用状況に応じてネットワークに送出するデータ量を調節することが開示されている。
【０００７】
【発明が解決しようとする課題】
上述した特許文献１に記載のものは、ＭＰＥＧ圧縮回路のＦＩＦＯメモリの使用状況を調べるもので、ＭＰＥＧ圧縮回路からのストリームデータを受け取って、送出されるパケットがバースト状に転送されたり、不均一な間隔でパケットが送出されるのを防ぐトラフィックシェーパの機能と異なるものである。トラフィックシェーパでは、ネットワークにおいて一時的にトラフィックが増大することによって送出できないパケットがトラフィックシェーパのバッファに蓄積され、バッファが一杯となる。この状態でさらにトラフィックシェーパにパケットが入力されると、バッファからデータがあふれ、パケットの消失や、バックプレッシャーによって他の送信フローまで止めてしまう問題があった。これらの問題を回避しようとすると、トラフィックシェーパに必要以上に大きなバッファを用意することになり、ハードウエアの回路規模の増大、消費電力の増大、コストの増加が生じる。
【０００８】
さらに、ＭＰＥＧエンコーダからトラフィックシェーパに対して送出されるデータレートとトラフィックシェーパから送出されるデータレートとが完全に一致していることがトラフィックシェーパの機能を発揮する前提である。若し、この前提がくずれると、トラフィックシェーパのバッファにおいてオーバーフローが生じる。
【０００９】
したがって、この発明の目的は、必要以上に大きな容量のバッファメモリを必要としないで、トラフィックシェーパの機能を発揮できる通信装置および通信方法を提供することにある。
【００１０】
また、この発明の他の目的は、エンコーダからの入力データレートと送出データレートのずれによってオーバーフローが発生することを防止できる通信装置および通信方法を提供することにある。
【００１１】
【課題を解決するための手段】
上述した課題を解決するために、請求項１の発明は、エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
符号化データを第１の記憶手段へ蓄積させた上で、蓄積された符号化データをネットワークのプロトコルにしたがってパケット化するネットワークプロトコル処理部と、
ネットワークプロトコル処理部のパケット化により生成されたパケットデータを第２の記憶手段に蓄積させ、蓄積されたパケットデータを等間隔で出力するトラフィックシェイピング部と、
トラフィックシェイピング部から出力されたデータをネットワークに対して送出するパケット送出部と、
トラフィックシェイピング部から第２の記憶手段の使用量を示すバッファ情報を受領することにより、使用量が所定値を超えたものと判断された場合には、ネットワークプロトコル処理部に対してパケットデータの出力を抑制させる制御部とを備えたことを特徴とする通信装置である。
【００１２】
請求項３の発明は、エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
符号化データをネットワークのプロトコルにしたがってパケット化し、記憶手段へ格納するネットワークプロトコル処理部と、
ネットワークプロトコル処理部に対して、記憶手段へ格納されたデータを等間隔で出力させるトラフィックシェイピング部と、
ネットワークプロトコル処理部から出力されたデータをネットワークへ送出する送出部とを備えたことを特徴とする通信装置である。
【００１３】
請求項４の発明は、エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
符号化データをネットワークのプロトコルにしたがってパケット化するネットワークプロトコル処理部と、
ネットワークプロトコル処理部のパケット化により生成されたパケットデータを等間隔で出力するトラフィックシェイピング部と、
トラフィックシェイピング部から出力されたパケットデータをネットワークに対して送出する送出部と、
ネットワークプロトコル処理部とトラフィックシェイピング部との間で共有され、ネットワークプロトコル処理部によりパケット化されたデータを格納すると共に、トラフィックシェイピング部からの要求に応じて格納されているパケットデータをトラフィックシェイピング部へ供給する記憶手段とを備えたことを特徴とする通信装置である。
【００１４】
請求項５の発明は、エンコーダから供給された符号化データをパケット化するステップと、ステップにおけるパケット化により生成されたパケットデータを記憶手段に保存し、保存されたパケットデータを等間隔でネットワークへ送出するステップとを有する通信方法において、
記憶手段に保存されたパケットデータの量に応じて、パケットデータの記憶手段への供給量を制限するステップを有することを特徴とする通信方法である。
【００１５】
請求項６の発明は、エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
符号化データをネットワークのプロトコルにしたがってパケット化するネットワークプロトコル処理部と、
ネットワークプロトコル処理部のパケット化により生成されたパケットデータを記憶する記憶手段と、
記憶手段に記憶されたパケットデータを等間隔で出力するトラフィックシェイピング部と、
記憶手段に記憶されているパケットデータのデータ量が所定値を超えたか否かを監視して、データ量が所定値を超えた場合にはトラフィックシェイピング部に対して記憶手段に記憶されているパケットデータを強制的に出力させる監視部と、
トラフィックシェイピング部から出力されたパケットデータをネットワークに対して送出する送出部とを備えたことを特徴とする通信装置である。
【００１６】
請求項８の発明は、二つのネットワーク間に配置され、いずれか一方のネットワークを介して受信したパケットデータを他方のネットワークに送出する通信装置において、
一方のネットワークを介して受信したパケットデータを記憶手段に記憶させ、記憶されたパケットデータを等間隔で他方のネットワークへ送出するトラフィックシェイピング部を備えたことを特徴とする通信装置である。
【００１７】
請求項９の発明は、二つのネットワーク間において、いずれか一方のネットワークを介して受信されたパケットデータを他方のネットワークに送出する通信方法であって、
一方のネットワークを介して受信したパケットデータ保存し、保存されたパケットデータを等間隔で他方のネットワークへ送出することを特徴とする通信方法である。
【００１８】
この発明では、トラフィックシェーパがバッファの状況を示すバッファ情報を出力する機能を有し、バッファ情報が前段のプロトコル処理回路にフィードバックされ、バッファがあふれそうまたは満杯であるという情報を前段のプロトコル処理が知ることを可能とし、それによってパケット化を遅らせたり、止めたりして、トラフィックシェーパに対する入力を制御している。それによって、パケットのロスが生じたり、他の全ての送信フローまで止めてしまう問題を回避することができる。
【００１９】
また、この発明では、前段のプロトコル処理回路のバッファの容量を大きくし、バッファがトラフィックシェーパのバッファを兼ねるようにしているので、別々にバッファを設けるのと比較してメモリの有効利用、メモリの周辺回路の簡略化が可能となる。
【００２０】
また、この発明では、前段のプロトコル処理回路のバッファと、トラフィックシェーパのバッファとを統合したバッファを設けるので、別々にバッファを設けるのと比較して、メモリの周辺回路（アドレスデコーダ、メモリコントローラ、アービトレーション、ＢＩＳＴ等が削減でき、チップサイズの縮小化と、消費電力の削減が可能となる。
【００２１】
さらに、この発明によれば、ＭＰＥＧエンコーダからの入力レートとシェイピングブロックの送出レートとのずれによってバッファがオーバーフローしそうになると、パケットを強制的に送出することによって、バッファのオーバーフローを防止することができる。さらに、バッファがオーバーフローするおそれがあることをホストＣＰＵに通知して、ホストＣＰＵによってエンコードレートおよびシェイピングレートを調整するので、これらのレートを最適な値に制御することができる。
【００２２】
よりさらに、この発明は、ブリッジがトラフィックシェイピングの機能を持つので、第１に、送信側システムから入ってきたパケットを均等な間隔で受信側システムに対して送出できるので、受信側システムのバッファの容量が少ない場合でも、パケットの欠落を防ぐことができ、高品位なデータ伝送ができる。第２に、トラフィックシェーパの機能をハードウエアで実現するため、ブリッジを制御するＣＰＵに対して負担がかからない。したがって、非力なＣＰＵによってブリッジを実現できる。また、ソフトウェアでトラフィックシェーパの機能を実現するのと比較して高スループットが実現できる。第３に、ブリッジ内にトラフィックシェーパの機能を搭載することによって、送信側システムにトラフィックシェーパの機能を備える必要がない。したがって、送信側および受信側にどのような機器でも接続することができ、汎用性を持つことができる。第４に、ネットワークの設定を変更する必要がないブリッジにおいてトラフィックシェーパの機能を実現しているので、ネットワークの上位層に負担をかけない利点がある。
【００２３】
【発明の実施の形態】
以下、この発明の第１の実施形態について説明する。図１は、第１の実施形態による通信装置の構成を示す。通信装置は、例えば１チップのＬＳＩ（ＬａｒｇｅＳｃａｌｅＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ：大規模集積回路）として実現される。第１の実施形態では、ＭＰＥＧ２（ＭｏｖｉｎｇＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐＰｈａｓｅ２）のＴＳ（ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ）パケットをＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ：リアルタイム転送プロトコル）を使用してＬＡＮに流すものである。参照符号１は、ＭＰＥＧ２エンコーダ（図示しない）から入力されたデータをＲＴＰプロトコルにしたがってパケット化するＲＴＰ回路を示す。ＲＴＰ回路１は、入力されたデータを蓄えるメモリを含むＲＴＰバッファ１１を備える。
【００２４】
図２Ａは、ＭＰＥＧ２エンコーダから入力されるＴＳパケットを示す。１パケットは、１８８バイトの長さである。なお、図２において、（）内の数字は、バイト数を表している。ＲＴＰ回路１は、ＲＴＰバッファ１１を備え、図２Ｂに示すように、７個のＴＳパケットをまとめ、７個のＴＳパケット（１３１６バイト）に対してＲＴＰヘッダ（２０バイト）を付加する。図３は、ＲＴＰヘッダの構成を示す。ＲＴＰヘッダには、シーケンスナンバー、タイムスタンプ、ＳＳＲＣ、ＣＳＲＣ等が含まれている。
【００２５】
参照符号２は、ＲＴＰ回路１でパケット化されたデータをネットワークプロトコルＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）でさらにパケット化するプロトコルスタックおよびルータ回路である。プロトコルスタックおよびルータ回路２のプロトコルスタック部では、図２Ｃに示すように、ＲＴＰヘッダの前にＵＤＰヘッダ（８バイト）が付加される。図４は、ＵＤＰヘッダの構成を示す。ＵＤＰヘッダには、ソース（送信元）ポートナンバーおよびディスティネーション（宛先）ポートナンバー、ＵＤＰレングス、ＵＤＰチェックサムが含まれる。
【００２６】
ＵＤＰヘッダが付加されると、次に、プロトコルスタック部では、図２Ｄに示すように、ＩＰヘッダ（２０バイト）が付加される。図５は、ＩＰヘッダの構成を示す。ＩＨＬは、インターネットヘッダ長を示し、ここで指定された値を４倍したバイト長がＩＰヘッダ長となる。バージョンは、インターネットプロトコルのバージョンを示す。さらに、ＴＯＳ（：サービスタイプ）、データを含めたＩＰパケットの全長を示すトータルレングス、ＩＤ、フラグ、フラグメントオフセットは、ＩＰパケットを分割して送る場合に使用される。ＴＴＬ（ＴｉｍｅＴｏＬｉｖｅ）は、通信可能なルータの残り個数を示す。ルータをデータを仲介する度にこのを減らす。プロトコルタイプは、データ部に含む上位プロトコル等の種別を示す。さらに、ＩＰヘッダが正しくやり取りされたか否かを検出するためのヘッダチェックサム、ソースアドレス、ディスティネーションアドレスがＩＰヘッダに含まれている。ソースアドレスは、送信元のＩＰアドレスである。ディスティネーションアドレスは、最終目的地の宛先ＩＰアドレスである。
【００２７】
次に、プロトコルスタック部では、図２Ｅに示すように、ＩＰヘッダの前にＤＩＸヘッダ（１４バイト）が付加される。図６は、ＤＩＸヘッダの構成を示す。ＤＩＸヘッダには、ディスティネーションＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）アドレス、ソースＭＡＣアドレスおよびタイプが含まれる。
【００２８】
次に、プロトコルスタックおよびルータ回路２のルータ部において、図２Ｆに示すように、ＤＩＸヘッダがタグ付きＤＩＸヘッダ（１８バイト）へ変更される。図７は、タグ付きＤＩＸヘッダの構成を示す。ＤＩＸヘッダに対して、プロトコル、ＶＬＡＮ、ＴＣＩが付加されている。
【００２９】
プロトコルスタックおよびルータ回路２からは、図２Ｆに示す構成のパケットが出力され、トラフィックシェーパ３に出力される。トラフィックシェーパ３は、パケット化されたデータをスケジューリングしてネットワークコントローラ４に対して出力する。トラフィックシェーパ３は、トラフィックシェーパバッファ（以下、適宜ＴＳバッファと略す）１３を有している。ネットワークコントローラ４は、トラフィックシェーパ３でスケジューリングされたパケットデータをネットワークに送出する。トラフィックシェーパ３では、パケットの内容が変更されない。ネットワークコントローラ４では、パケットの後に自動的にＦＣＳ（ＦｒａｍｅＣｈｅｃｋＳｅｑｕｅｎｃｅ）を追加する。
【００３０】
図１において、参照符号５は、ホストインターフェース回路を示す。ホストインターフェース回路５を介してネットワーク通信装置がホストＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）と接続される。ＲＴＰ回路１、プロトコルスタックおよびルータ２、トラフィックシェーパ３、ネットワークコントローラ４のそれぞれとホストインターフェース回路５とが接続され、ホストＣＰＵが各回路の設定、インタラプト等を制御することが可能とされている。ホストインターフェース回路５には、ホストＣＰＵが読み書きできるレジスタが備えられている。
【００３１】
第１の実施形態では、参照符号６で示す信号路を介してトラフィックシェーパ３からＴＳバッファ１３の使用状況の情報（ＴＳバッファ情報信号と称する）がＲＴＰ回路１に対して知らされる。ＲＴＰ回路１は、ＴＳバッファ情報に基づいてＲＴＰ回路１からのパケット化出力のタイミングを遅らせたり、一時的に停止する。
【００３２】
図８は、ＴＳバッファ情報をＲＴＰ回路１に供給しない構成（すなわち、従来の構成）の処理の流れを示すフローチャートである。ステップＳ１において、ＡＶデータ（ＴＳパケット（図２Ａ参照））が入力される。ＲＴＰ回路１のＲＴＰバッファ１１に入力ＡＶデータが蓄えられ、パケット化に必要な量例えば７個のＴＳパケットがＲＴＰバッファ１１に蓄積されると、ＲＴＰ回路１によってパケット化され、ＲＴＰバッファ１からパケット化データ（図２Ｂ参照）が出力される（ステップＳ２）。
【００３３】
ステップＳ３において、プロトコルスタックおよびルータ２において、図２Ｃ、図２Ｄ、図２Ｅ、図２Ｆを参照して説明したように、ネットワークプロトコルに合わせてさらにパケット化される。プロトコルスタックおよびルータ２からパケット化されたデータがトラフィックシェーパ３のＴＳバッファ１３に蓄積される。
【００３４】
ステップＳ６では、パケット長、転送レート等から計算された送出スケジュールにしたがってＴＳバッファ１３からパケットが読み出され、ネットワークコントローラ４に対して読み出されたパケットが供給される。ステップＳ７において、ネットワークコントローラ４がパケットをネットワークに送出できる形態に変換し、ステップＳ８において、送出可能な時にパケットを送出する。ホストインターフェース回路５は、これらの一連の動作状態を監視し、必要があれば、ホストＣＰＵから制御を行う。
【００３５】
若し、ネットワークのトラフィックが増大してステップＳ８においてパケットを送出できないと、ステップＳ６においてＴＳバッファの読み出しができない。その状態が続くと、ＴＳバッファ１３があふれてしまう。ステップＳ３において、パケット化されたデータをＴＳバッファ１３に蓄積する時に、ステップＳ４において、ＴＳバッファが満杯かどうかが判定される。
【００３６】
ステップＳ４において、ＴＳバッファ１３が満杯と判定されると、ステップＳ５において、到来したパケットの破棄またはバックプレッシャーの処理がなされる。バックプレッシャーは、トラフィックシェーパ３がパケットデータの受け取りを止めることである。データを破棄すれば、パケットのロスが生じ、バックプレッシャーは、他の全ての送信フローまで止めてしまう問題があった。
【００３７】
図９は、図１に示すように、信号路６を備えた第１の実施形態の処理の流れを示す。ステップＳ１１においてＡＶデータが入力され、ステップＳ１２において、ＲＴＰバッファ１１が満杯か否かが判定される。満杯でなければ、ステップＳ１４のＲＴＰバッファ１１への入力に処理が移る。満杯であれば、ステップＳ１３に処理が移り、ＡＶデータの受付の拒否をホストＣＰＵに対して通知する。
【００３８】
ＲＴＰバッファ１１が満杯でなければ、ステップＳ１４において、ＡＶデータがＲＴＰバッファ１１に入力される。ステップＳ１５では、信号路６を介してトラフィックシェーパ３から送られてくるＴＳバッファ情報信号に基づいて、ＴＳバッファ１３が満杯か否かが判定される。ＴＳバッファ情報信号は、満杯か否かに限らず、満杯になりそうなことを知らせるようにしても良い。
【００３９】
ＴＳバッファ１３が満杯でないと判定されると、ステップＳ１６において、ＲＴＰバッファ１１からＡＶデータが出力され、ＲＴＰヘッダが付加される。若し、ＴＳバッファ１３が満杯であるとステップＳ１５において判定されると、ステップＳ１６（ＲＴＰバッファ１１からの出力）へ処理が移らないで、ＴＳバッファ１３が満杯でないと判定されるまで待機する。
【００４０】
ステップＳ１６において、ＲＴＰバッファ１１からＡＶデータが出力され、ＲＴＰヘッダが付加される。ステップＳ１７において、プロトコルスタックおよびルータ２において、図２Ｃ、図２Ｄ、図２Ｅ、図２Ｆを参照して説明したように、ネットワークプロトコルに合わせてさらにパケット化される。プロトコルスタックおよびルータ２からパケット化されたデータがトラフィックシェーパ３のＴＳバッファ１３に蓄積される。
【００４１】
ステップＳ１８では、パケット長、転送レート等から計算された送出スケジュールにしたがってＴＳバッファ１３からパケットが読み出され、ネットワークコントローラ４に対して読み出されたパケットが供給される。ステップＳ１９において、ネットワークコントローラ４がパケットをネットワークに送出できる形態に変換し、ステップＳ２０において、送出可能な時にパケットを送出する。ホストインターフェース回路５は、これらの一連の動作状態を監視し、必要があれば、ホストＣＰＵから制御を行う。
【００４２】
上述したように、この発明の第１の実施形態では、トラフィックシェーパ３がＴＳバッファ１３の状況を示すＴＳバッファ情報を出力する機能を有し、ＴＳバッファ情報がＲＴＰ回路１にフィードバックされ、ＴＳバッファ１３があふれそうまたは満杯であるという情報をＲＴＰ回路１が知ることを可能とし、ＲＴＰ回路１がパケット化を遅らせたり、止めたりして、トラフィックシェーパ３に対する入力を制御している。それによって、パケットのロスが生じたり、他の全ての送信フローまで止めてしまう問題を回避することができる。
【００４３】
次に、この発明の第２の実施形態について、図１０および図１１を参照して説明する。第２の実施形態では、図１０に示すように、ＲＴＰバッファ１１ａの容量を大きくし、ＴＳバッファ３を無くしたものである。トラフィックシェーパ３ａは、スケジュール管理のみを行い、パケットの送出指示をＲＴＰ回路１に伝える。送出指示を受け取ったＲＴＰ回路１は、ＲＴＰバッファ１１ａからパケットを読み出し、図２Ａに示すように、ＲＴＰヘッダが付加され、ＲＴＰヘッダを有するパケットがプロトコルスタックおよびルータ２に供給される。トラフィックシェーパ３ａは、パケット長、転送レート等から計算された送出スケジュールにしたがってＲＴＰバッファ１１ａからデータを読み出すように、ＲＴＰ回路１を制御する。
【００４４】
ＲＴＰバッファ１１ａからの読み出しレートが書き込みレートより低いと、ＲＴＰバッファ１１ａがオーバーフローするおそれがある。ＲＴＰ回路１は、ＲＴＰバッファ１１ａの中でＴＳバッファの機能を有する部分が満杯であることを検出して、その場合では、ＲＴＰバッファ１１ａに対するＡＶデータの書き込み一時的に停止する。
【００４５】
図１１は、第２の実施形態の処理の流れを示す。ステップＳ３１においてＡＶデータが入力され、ステップＳ３２において、ＲＴＰバッファ１１ａが満杯か否かが判定される。満杯でなければ、ステップＳ３４のＲＴＰバッファ１１ａへの入力に処理が移る。満杯であれば、ステップＳ３３に処理が移り、ＡＶデータの受付の拒否をホストＣＰＵに対して通知する。
【００４６】
ＲＴＰバッファ１１ａが満杯でなければ、ステップＳ３４において、ＡＶデータがＲＴＰバッファ１１ａに入力される。ステップＳ３６は、ＲＴＰバッファ１１ａからのＡＶデータの出力である。ＲＴＰバッファ１１ａからのＡＶデータの出力は、ステップＳ３５において、トラフィックシェーパ３ａが発生した送出指示に基づいてなされる。
【００４７】
ステップＳ３６において、ＲＴＰバッファ１１ａからＡＶデータが出力され、ＲＴＰヘッダが付加される。ステップＳ３７において、プロトコルスタックおよびルータ２において、ネットワークプロトコルに合わせてさらにパケット化される。プロトコルスタックおよびルータ２からパケット化されたデータがネットワークコントローラ４に対して供給される。ステップＳ３８において、ネットワークコントローラ４がパケットをネットワークに送出できる形態に変換し、ステップＳ３９において、送出可能な時にパケットを送出する。ホストインターフェース回路５は、これらの一連の動作状態を監視し、必要があれば、ホストＣＰＵから制御を行う。
【００４８】
第２の実施形態では、ＲＴＰバッファ１１ａの容量を大きくし、ＲＴＰバッファ１１ａがＴＳバッファを兼ねるようにしているので、別々にバッファを設けるのと比較してメモリの有効利用、メモリの周辺回路の簡略化が可能となる。
【００４９】
次に、この発明の第３の実施形態について図１２および図１３を参照して説明する。第３の実施形態では、図１２に示すように、ＲＴＰバッファ、ＴＳバッファをまとめた統合バッファ１４を設ける。統合バッファ１４からＲＴＰ回路１に対して統合バッファ１４が満杯かどうかの情報が供給される。また、プロトコルスタックおよびルータ回路の機能をトラフィックシェーパ３ｂに統合する。トラフィックシェーパ３ｂがスケジュール管理と、統合バッファ１４からのデータの読み出しとパケット化を行う。
【００５０】
図１３は、第３の実施形態の処理の流れを示す。ステップＳ４１においてＡＶデータが入力され、ステップＳ４２において、統合バッファ１４が満杯か否かが判定される。満杯でなければ、ステップＳ４４の統合バッファ１４への入力に処理が移る。満杯であれば、ステップＳ４３に処理が移り、ＡＶデータの受付の拒否をホストＣＰＵに対して通知する。
【００５１】
統合バッファ１４が満杯でなければ、ステップＳ４４において、ＡＶデータがＲＴＰ回路１から統合バッファ１４へ入力される。統合バッファ１４に所定数のＴＳパケットが蓄えられると、所定数のＴＳパケットが読み出され、ＲＴＰ回路１においてＲＴＰヘッダが付加され、ＲＴＰヘッダが付加されたデータが統合バッファ１４に再び書き込まれる。
【００５２】
ステップＳ４５において、統合バッファ１４からＡＶデータが読み出され、トラフィックシェーパ３ｂに供給される。トラフィックシェーパ３ｂでは、プロトコルスタックおよびルータが行うパケット化がなされる。すなわち、図２Ｃ、図２Ｄ、図２Ｅおよび図２Ｆを参照して説明したようなＵＤＰヘッダの付加、ＩＰヘッダの付加、ＤＩＸヘッダの付加、タグ付きＤＩＸヘッダの生成の処理をトラフィックシェーパ３ｂが行う。これらの処理の過程で、統合バッファ１４に対してデータの書き込みおよび読み出しがなされる。
【００５３】
ステップＳ４６では、パケット長、転送レート等から計算された送出スケジュールにしたがって統合バッファ１４からパケットが読み出され、ネットワークコントローラ４に対して読み出されたパケットが供給される。ステップＳ４８において、ネットワークコントローラ４がパケットをネットワークに送出できる形態に変換し、ステップＳ４９において、送出可能な時にパケットを送出する。ホストインターフェース回路５は、これらの一連の動作状態を監視し、必要があれば、ホストＣＰＵから制御を行う。
【００５４】
第３の実施形態では、ＲＴＰバッファとＴＳバッファとを統合したバッファ１４を設けるので、別々にバッファを設けるのと比較して、メモリの周辺回路（アドレスデコーダ、メモリコントローラ、アービトレーション、ＢＩＳＴ（Ｂｕｒｓｔ−ｉｎｓｅｌｆ−ｔｅｓｔ：自己テスト等）が削減でき、チップサイズの縮小化と、消費電力の削減が可能となる。
【００５５】
次に、この発明の第４の実施形態について説明する。第４の実施形態は、前段に接続されるＭＰＥＧエンコーダからのデータレートとトラフィックシェーパにおけるシェイピングのレートとが一致してないために、トラフィックシェーパのバッファにおいて、オーバーフローが生じることを防止するものである。図１４を参照して第４の実施形態が適用可能な従来の送信装置について説明する。
【００５６】
図１４において、参照符号２１がＭＰＥＧエンコーダを示す。ＭＰＥＧエンコーダ２１の出力例えばＴＳパケットが通信装置２６に供給される。通信装置２６は、通信プロトコル処理部２２、シェイピングブロック２３、物理層処理ブロック２４およびパケットバッファ２５から構成されている。通信装置２６は、前述した第１、第２および第３の実施形態と同様に、ＭＰＥＧエンコーダ２１からのＡＶデータをネットワーク２９に対して送出する場合に、ＭＰＥＧエンコーダ２１から不均等の間隔例えばバースト的に発生したパケットを等間隔で送出する機能を有する。
【００５７】
通信プロトコル処理ブロック２２は、ＲＴＰ、ＵＤＰ等のプロトコルに適合したパケット構成とするためのブロックである。シェイピングブロック２３は、通信プロトコル処理ブロック２２からのパケットを一旦パケットバッファ２５に蓄積し、必要な送出レートに応じてパケットをバッファ２５から読み出し、読み出したパケットを物理層処理ブロック２４に供給する。物理層処理ブロック２４は、イーサネット、ワイヤレスＬＡＮ等のネットワーク２９の伝送に適した構成の送出データを形成するためのブロックである。
【００５８】
図１５は、上述した通信装置２６の処理を概略的に示すものである。ＭＰＥＧエンコーダ２１のエンコーダレートでもって、通信装置２６に対してデータが入力される。例えばＰ１，Ｐ２，Ｐ３と示すパケットがバースト的にＭＰＥＧエンコーダ２１から通信装置２６に入力される。入力データが一時的にパケットバッファ２５に蓄積され、設定した送出レートでもって等間隔でＰ１，Ｐ２，Ｐ３と１パケットづつが出力される。図１５では、ヘッダについては、省略されている。図１５に示すように、ＭＰＥＧエンコーダ２１の出力の１パケット当りのレートと、通信装置２６の１パケットを送出するレートとが完全に一致している、理想的な場合では、パケットバッファ２５がオーバーフローまたはアンダーフローすることがない。
【００５９】
図１６は、ＭＰＥＧエンコーダ２１からのデータのレートが通信装置２６で設定される送出レートに比して高い場合を示している。分かり易い例として、ＭＰＥＧエンコーダ２１からのデータのレートが送出レートの２倍近いものを示している。この場合では、パケットバッファ２５に対して未送出のパケットが次第にたまり、パケットバッファ２５がオーバーフローを起こす。その結果、パケットが破棄される。図１６において、パケットＰ８の後にパケットＰ９，Ｐ１０，Ｐ１１がバースト的に出力されているが、この動作は、後述するこの発明の第４の実施形態によってなされるものである。図示しないが、ＭＰＥＧエンコーダ２１の出力データのレートが通信装置２６で設定される送出レートに比して低い場合では、アンダーフローを生じる。
【００６０】
この発明の第４の実施形態は、このようなＭＰＥＧエンコーダの出力のデータレートとシェイピングしたデータの送出レートとの不整合の問題を解決するものである。図１７が第４の実施形態の構成を示す。図１７において破線が囲んで示す部分が従来の構成と異なる構成を表している。すなわち、参照符号２６ａで示す通信装置は、パケットバッファ２５に蓄えられたデータ量が上側しきい値ＴＨｕを超えたかどうかを監視するＴＨｕ監視部２７ａと下側しきい値ＴＨｌより減少したかを監視するＴＨｌ監視部２７ｂとを備えている。これらの監視部２７ａ，２７ｂのバッファ情報がシェイピングブロック２３ａに供給される。一例として、パケットバッファ２５は、ＦＩＦＯの構成とされている。
【００６１】
シェイピングブロック２３ａは、監視部２７ａ，２７ｂからのバッファ情報に応答してパケットバッファ２５がオーバーフローまたはアンダーフローしないように、パケットデータを送出するフロー制御機能を有する。また、パケットバッファ２５の状態が図示しないホストインターフェースを通じてホストＣＰＵ２８に通知され、ホストＣＰＵ２８がＭＰＥＧエンコーダ２１を制御し、エンコーダ２１から出力されるデータのレートが制御される。なお、ホストＣＰＵ２８自身がソフトウェア処理によってＭＰＥＧの符号化処理を行うことも可能である。また、ホストＣＰＵ２８と通信装置２６ａの間は、双方向の通信が可能とされ、ホストＣＰＵ２８によってシェイピングブロック２３ａのパケット送出間隔が制御可能とされている。
【００６２】
図１８は、第４の実施形態を概略的に示す。通信プロトコル処理ブロック２２からのパケットがパケットバッファ２５に対して入力される。例えばパケットバッファ２５は、最大１０個のパケットを蓄えることができる。シェイピングブロック２３ａが備えるインターバルカウンタ２３ｂにしたがって、均等な間隔でパケットがパケットバッファ２５から物理層処理ブロック２４に対して出力される。
【００６３】
上側しきい値ＴＨｕは、パケット数の７に設定され、下側しきい値ＴＨｌは、パケット数の３に設定される。ＴＨｕ監視部２７ａは、パケットバッファ２５に蓄積され、出力待ちの状態のパケット数が７以上で上側しきい値ＴＨｕを超えたものと判定する。ＴＨｌ監視部２７ｂは、パケットバッファ２５に蓄積され、出力待ちの状態のパケット数が３以下で下側しきい値ＴＨｌを超えたものと判定する。
【００６４】
図１９は、第４の実施形態の処理の流れを示すフローチャートである。ステップＳ５１でシェイピングブロック２３ａに対して１パケットが入力される。以下に述べるシェイピングブロック２３ａの処理は、１パケットが入力される毎になされる。ステップＳ５２において、インターバルカウンタ２３ｂで制御される間隔で、パケットがパケットバッファ２５から読み出され、シェイピングブロック２３ａを介して物理層処理部２４に出力される。ステップＳ５３において、ＴＨｌ監視部２７ｂからのバッファ情報に基づいて、パケットバッファ２５に蓄えられ、出力待ちのパケット数がＴＨｕ（例えばＴＨｕ＝７）以上かどうかが判定される。
【００６５】
ステップＳ５３において、出力待ちのパケット数がＴＨｕ以上でないと判定されると、ステップＳ５２のパケットの送出に処理が戻る。出力待ちのパケット数がＴＨｕ以上と判定されると、ステップＳ５４に処理が移る。ステップＳ５４では、パケットバッファ２５から強制的にパケットの送出が開始される。これと共に、パケット数がＴＨｕ以上であると判定されると、ステップＳ５６において、ホストＣＰＵ２８に対して割り込み通知が与えられる。ホストＣＰＵ２８の処理Ｓ６１については後述する。
【００６６】
ステップＳ５４において強制的に１パケットが送出されると、ステップＳ５５において、ＴＨｌ監視部２７ｂからのバッファ情報に基づいて、出力待ちのパケット数がＴＨｌ（例えばＴＨｌ＝３）以上かどうかが判定される。出力待ちのパケット数がＴＨｌ以上であれば、処理がステップＳ５４に戻り、次のパケットが強制的に送出される。このように、送出待ちのパケットの強制的な送出は、ステップＳ５５において、出力待ちのパケット数がＴＨｌより少ないと判定され、処理がステップＳ５２（シェイピングによる送出）に戻るまで、継続的になされる。
【００６７】
図１６の例では、パケットＰ８の送出が終了した時点で、パケットバッファ２５の送出待ちのパケット数が７となるので、パケットＰ９，Ｐ１０，Ｐ１１と強制的な送出がなされる。強制的な送出は、送出待ちのパケット数が２以下となるまで継続的にされる。このように、ＭＰＥＧエンコーダ２１のレートがシェイピングブロック２３ａの出力データのレートより高い場合に出力待ちのパケットが強制的に送出されるので、パケットバッファ２５がオーバーフローし、パケットが破棄されることを防止できる。
【００６８】
さらに、頻繁にパケットの強制的な送出がなされると、受信側のバッファがオーバーフローするおそれがあるので、その場合には、ホストＣＰＵ２８が出力データのレートを下げるように、ＭＰＥＧエンコーダ２１を制御する。ステップＳ５３において、出力待ちのパケット数がしきい値ＴＨｕ以上であると判定されると、ホストＣＰＵ２８に対して割り込み通知が与えられ（ステップＳ５６）、ホストＣＰＵ２８が処理Ｓ６１を行う。
【００６９】
最初に、ステップＳ６２において、エンコードレートを下げる。次に、インターフェースを通じて受け取ったＴＨｕ監視部２７ａのバッファ情報に基づいてステップＳ６３において、出力待ちのパケット数がＴＨｕを頻繁に超えているかどうかが判定される。ＴＨｕを頻繁に超えていると判定されると、ステップＳ６２に戻り、エンコードレートが下げられ、再びステップＳ６３の判定がなされる。頻繁かどうかは、予め設定されたしきい値に基づいて判定される。例えば所定時間当りで、ＴＨｕ以上となる回数がしきい値と比較され、比較結果に基づいて頻繁かどうかが判定される。
【００７０】
ステップＳ６３において、ＴＨｕを頻繁に超えていないと判定されると、ステップＳ６４において、出力待ちのパケット数がＴＨｕを超えているかどうかが判定される。出力待ちのパケット数がＴＨｕを超えていなければ、調整が終了する（ステップＳ６５）。ステップＳ６４において、出力待ちのパケット数がＴＨｕを超えていると判定されると、ステップＳ６６において、シェイピングブロック２３ａのシェイピングレートが高くされる。シェイピングレートが高くされると、シェイピングブロック２３ａから送出されるパケットの間隔が短くなる。そして、ステップＳ６３に戻り、出力待ちのパケット数がＴＨｕを超えているかどうかが判定される。
【００７１】
上述した第４の実施形態によれば、ＭＰＥＧエンコーダからの入力レートとシェイピングブロックの送出レートとのずれによってバッファがオーバーフローしそうになると、パケットを強制的に送出することによって、バッファのオーバーフローを防止することができる。さらに、バッファがオーバーフローするおそれがあることをホストＣＰＵに通知して、ホストＣＰＵによってエンコードレートおよびシェイピングレートを調整するので、これらのレートを最適な値に制御することができる。
【００７２】
次に、この発明の第５の実施形態について説明する。図２０を参照してこの発明を適用できる通信システムの一例および他の例について説明する。図２０Ａは、送信側システム４１とブリッジ４３とがワイヤレスＬＡＮ４２を介して接続され、ブリッジ４３と受信側システム４５とがイーサネット４４を介して接続されたシステムの例である。送信側システム４１は、例えばＡＶデータをパケット化し、ワイヤレスＬＡＮ４２を介してブリッジ４３へ送信する。ブリッジ４３は、受信したパケットをイーサネット４４を介して受信側システム４５へ送信する。受信側システム４５では、受信したパケットからＡＶデータを取り出して映像や音声として利用する。
【００７３】
図２０Ｂは、送信側システム４１とブリッジ４３とがイーサネット４６を介して接続され、ブリッジ４３と受信側システム４５とがワイヤレスＬＡＮ４７を介して接続されたシステムの例である。イーサネットとワイヤレスＬＡＮの位置が図２０Ａと逆になっているだけで、通信の手順は、図２０Ａの構成と同様である。
【００７４】
ブリッジ４３は、二つのネットワークを接続する装置である。ブリッジ４３は、ネットワーク上のパケットに含まれるディスティネーションアドレスを読み取り、ブリッジが保存しているアドレス一覧と比較する。宛先がブリッジの外側であれば、データパケットを送出し、内側のネットワーク（ＬＡＮ）上にあれば、無視する。このように、パケットのルーティングを行う。ブリッジは、ルータと異なり、ネットワークの設定を変更する必要がない。
【００７５】
具体的には、送信側システム４１がインターネットを介して受け取り、家庭内のＬＡＮにパケットを送信するシステムである。受信側システム４５がコンピュータ機能を有するテレビジョン受像機である。ワイヤレスＬＡＮ４７を使用する場合では、持ち運びできるテレビジョン受像機を受信側システム４５として使用できる。なお、ネットワークとしては、ワイヤレスＬＡＮとイーサネットとが混在するものに限らず、一方のみで構成されるものであっても良い。
【００７６】
従来の通信システムでは、ブリッジ４３が入力されたパケットをそのままイーサネット４４またはワイヤレスＬＡＮ４７に送出している。受信側システム４５の備えている受信バッファとして小容量のものを使用するためには、図２１Ａに示すように、パケットが等間隔にブリッジ４３から送出されることが望ましい。各パケットの先頭には、通常ヘッダが付加されている。
【００７７】
図２１Ｂに示すように、パケットがバースト的に送出されたり、またはバラバラの間隔で送出されると、受信バッファにオーバーフローが発生し、あふれたパケットが破棄されてしまう。パケットがバースト状になる原因としては、映像や音声をネットワーク上に伝送できるようにディジタル化し、連続したストリームデータに変換するエンコーダの仕様、ネットワーク上の他のパケットの影響等がある。
【００７８】
図２２は、受信バッファのあふれを模式的に説明するものである。受信側システム４５が備えている受信バッファ例えばＦＩＦＯを参照符号４５ａで示し、受信バッファ４５ａの容量を５パケットと仮定している。受信バッファ４５ａからのパケットの出力は、設定された一定の間隔とされている。
【００７９】
図２２Ａに示すように、空の受信バッファ４５ａにバースト状に９個のパケットが入力される。図２２Ｂ、図２２Ｃに示すように、４個のパケットが受信バッファ４５ａに対して順に格納される。次に、図２２Ｄに示すように、５個のパケットが受信バッファ４５ａに格納されて、受信バッファ４５ａが満杯となる。しかしながら、受信バッファ４５ａから最初に格納されたパケットの読み出しが起こるので、あふれることはない。図２２Ｅに示すように、６番目のパケットが受信バッファ４５ａに格納される場合も、２番目に格納されたパケットが受信バッファ４５ａから出力されるので、受信バッファ４５ａがあふれることはない。この状態でさらにパケットが到着すると、図２２Ｆに示すように、受信バッファ４５ａがあふれ、パケットが破棄されてしまう。
【００８０】
ＡＶデータの場合では、パケットが欠落すると、映像や音声が途切れることになる。ＡＶデータは、時間情報を有したり、リアルタイム性を有するので、リトライ等の再送を行うことができず、映像や音声の品質が低下する問題が生じる。受信側システム４５の受信バッファ４５ａの容量を大きくすることによって問題を生じないようにできるが、受信側システムのコストの増加を招く問題がある。受信バッファの容量は、受信側システムの機器、経路の途中に介在するスイッチやルータ等によって最適な容量が存在し、一律に容量を決めることができない問題がある。また、一定時間内に流れるパケット数、すなわち、単位時間当りのデータ量を減少させる方法が考えられる。しかしながら、この方法は、画質や、音質を低下させることを意味しており、高品位のＡＶデータを伝送する上では、好ましい方法ではない。
【００８１】
この発明の第５の実施形態では、ブリッジ４３がトラフィックシェイピング機能を持つようにしたものである。図２３は、トラフィックシェイピングの機能を説明するものである。バースト状または不均等な間隔でパケットが入力された場合でも、トラフィックシェイピングの機能によって、ブリッジが均等な間隔でパケットを出力する。その結果、受信側システム４５が備える受信バッファが小さな容量であっても、受信バッファのあふれを防止できる。
【００８２】
図２４は、図２０Ａに示す通信システムのブリッジ４３に対して適用されるこの発明の第５の実施形態を示す。第５の実施形態は、ワイヤレスＬＡＮと接続されるインターフェースと、イーサネットと接続されるインターフェースとを備えている。
【００８３】
図２４において、参照符号５１がワイヤレスＲＦ部を示す。ワイヤレスＲＦ部５１には、アンテナと接続されたＲＦ回路と、ＯＦＤＭ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘ）等の変調回路とが含まれる。ワイヤレスＲＦ部５１に対してＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）処理を行うワイヤレスＭＡＣ部５２が接続される。ワイヤレスＭＡＣ部５２は、どのような方法でデータをワイヤレスＬＡＮに送出するか等の制御を行う。参照符号５３は、イーサネット物理層処理ブロックを示す。イーサネット物理層処理ブロック５３に対してイーサネットＭＡＣ部５４が接続される。イーサネットＭＡＣ部５４は、どのような方法でデータをＬＡＮケーブルに送出するか等の制御を行う。
【００８４】
ワイヤレスＭＡＣ部５２の出力（端子またはポート）とイーサネットＭＡＣ部５４の出力の一方がセレクタ５５に接続される。セレクタ５５は、二つの出力の一方を選択的にアドレス変換部５６の入力に接続する。アドレス変換部５６は、ワイヤレスＬＡＮを経由したパケットをイーサネットに送出する場合、またはその逆にイーサネットを経由したパケットをワイヤレスＬＡＮに送出する場合にアドレスの変換を行う機能を有する。
【００８５】
アドレス変換部５６でアドレスが付け替えられたパケットがトラフィックシェーパ５７に供給される。トラフィックシェーパ５７は、図２３を参照して説明したように、バースト状または不均等の間隔で入力されたパケットを等間隔で出力する機能を有している。トラフィックシェーパ５７の出力がセレクタ５８に入力される。
【００８６】
セレクタ５８は、ワイヤレスＭＡＣ部５２とイーサネットＭＡＣ部５４との一方の入力（端子またはポート）に接続されている。トラフィックシェーパ５７から送出されたパケットがセレクタ５８によってワイヤレスＭＡＣ部５２とイーサネットＭＡＣ部５４との一方の入力に出力される。図２４において、破線が囲んで示すセレクタ５５、アドレス変換部５６、トラフィックシェーパ５７およびセレクタ５８は、１チップのＬＳＩとして実現されている。
【００８７】
セレクタ５８は、セレクタ５５が選択する側と異なる側を選択する。例えばセレクタ５５がワイヤレスＭＡＣ部５２の出力を選択する時には、セレクタ５８がイーサネットＭＡＣ部５４の入力を選択する。この場合では、ワイヤレスＬＡＮを介して受信されたパケットがアドレス変換およびトラフィックシェイピングの処理を受けてイーサネットに出力される。セレクタ５５および５８が逆の状態とされる場合には、イーサネットを介して受信されたパケットがアドレス変換およびトラフィックシェイピングの処理を受けてワイヤレスＬＡＮに出力される。一例として、パケットのヘッダに含まれているディストネーションアドレス、ソースアドレス、送信機アドレス、受信機アドレス等に基づいてセレクタ５５および５８が制御される。
【００８８】
上述したこの発明の第５の実施形態は、ブリッジがトラフィックシェイピングの機能を持つので、下記のような利点を有する。
【００８９】
第１に、送信側システムから入ってきたパケットを均等な間隔で受信側システムに対して送出できるので、受信側システムのバッファの容量が少ない場合でも、パケットの欠落を防ぐことができ、高品位なデータ伝送ができる。
【００９０】
第２に、トラフィックシェーパの機能をハードウエアで実現するため、ブリッジを制御するＣＰＵに対して負担がかからない。したがって、非力なＣＰＵによってブリッジを実現できる。また、ソフトウェアでトラフィックシェーパの機能を実現するのと比較して高スループットが実現できる。
【００９１】
第３に、ブリッジ内にトラフィックシェーパの機能を搭載することによって、送信側システムにトラフィックシェーパの機能を備える必要がない。したがって、送信側および受信側にどのような機器でも接続することができ、汎用性を持つことができる。
【００９２】
第４に、ネットワークの設定を変更する必要がないブリッジにおいてトラフィックシェーパの機能を実現しているので、ネットワークの上位層に負担をかけない利点がある。
【００９３】
この発明は、上述したこの発明の一実施形態等に限定されるものでは無く、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。例えば上述した実施形態では、ＭＰＥＧを例に説明したが、ＭＰＥＧ以外のＡＶデータの符号化方式に対してもこの発明を適用することができる。また、ＦＩＦＯ以外のメモリを利用してバッファメモリを構成するようにしても良い。
【００９４】
【発明の効果】
以上の説明から明らかなように、この発明の第１の実施形態では、トラフィックシェーパがバッファの状況を示すバッファ情報を出力する機能を有し、バッファ情報が前段のプロトコル処理回路にフィードバックされ、バッファがあふれそうまたは満杯であるという情報を前段のプロトコル処理が知ることを可能とし、それによってパケット化を遅らせたり、止めたりして、トラフィックシェーパに対する入力を制御している。それによって、パケットのロスが生じたり、他の全ての送信フローまで止めてしまう問題を回避することができる。
【００９５】
この発明の第２の実施形態では、前段のプロトコル処理回路のバッファの容量を大きくし、バッファがトラフィックシェーパのバッファを兼ねるようにしているので、別々にバッファを設けるのと比較してメモリの有効利用、メモリの周辺回路の簡略化が可能となる。
【００９６】
この発明の第３の実施形態では、前段のプロトコル処理回路のバッファと、トラフィックシェーパのバッファとを統合したバッファを設けるので、別々にバッファを設けるのと比較して、メモリの周辺回路（アドレスデコーダ、メモリコントローラ、アービトレーション、ＢＩＳＴ等が削減でき、チップサイズの縮小化と、消費電力の削減が可能となる。
【００９７】
この発明の第４の実施形態によれば、ＭＰＥＧエンコーダからの入力レートとシェイピングブロックの送出レートとのずれによってバッファがオーバーフローしそうになると、パケットを強制的に送出することによって、バッファのオーバーフローを防止することができる。さらに、バッファがオーバーフローするおそれがあることをホストＣＰＵに通知して、ホストＣＰＵによってエンコードレートおよびシェイピングレートを調整するので、これらのレートを最適な値に制御することができる。
【００９８】
この発明の第５の実施形態は、ブリッジがトラフィックシェイピングの機能を持つので、第１に、送信側システムから入ってきたパケットを均等な間隔で受信側システムに対して送出できるので、受信側システムのバッファの容量が少ない場合でも、パケットの欠落を防ぐことができ、高品位なデータ伝送ができる。
【００９９】
第２に、トラフィックシェーパの機能をハードウエアで実現するため、ブリッジを制御するＣＰＵに対して負担がかからない。したがって、非力なＣＰＵによってブリッジを実現できる。また、ソフトウェアでトラフィックシェーパの機能を実現するのと比較して高スループットが実現できる。
【０１００】
第３に、ブリッジ内にトラフィックシェーパの機能を搭載することによって、送信側システムにトラフィックシェーパの機能を備える必要がない。したがって、送信側および受信側にどのような機器でも接続することができ、汎用性を持つことができる。
【０１０１】
第４に、ネットワークの設定を変更する必要がないブリッジにおいてトラフィックシェーパの機能を実現しているので、ネットワークの上位層に負担をかけない利点がある。
【図面の簡単な説明】
【図１】この発明の第１の実施形態の構成を示すブロック図である。
【図２】パケット化の処理を説明するための略線図である。
【図３】ＲＴＰヘッダの一例のデータ構成を示す略線図である。
【図４】ＵＤＰヘッダの一例のデータ構成を示す略線図である。
【図５】ＩＰヘッダの一例のデータ構成を示す略線図である。
【図６】ＤＩＸヘッダの一例のデータ構成を示す略線図である。
【図７】タグ付きＤＩＸヘッダの一例のデータ構成を示す略線図である。
【図８】従来の処理の流れを示すフローチャートである。
【図９】この発明の第１の実施形態の処理の流れを示すフローチャートである。
【図１０】この発明の第２の実施形態の構成を示すブロック図である。
【図１１】この発明の第２の実施形態の処理の流れを示すフローチャートである。
【図１２】この発明の第３の実施形態の構成を示すブロック図である。
【図１３】この発明の第３の実施形態の処理の流れを示すフローチャートである。
【図１４】従来の通信装置の構成を示すブロック図である。
【図１５】トラフィックシェイピングの機能を説明するための略線図である。
【図１６】バッファのオーバーフローを説明するための略線図である。
【図１７】この発明の第４の実施形態の構成を示すブロック図である。
【図１８】この発明の第４の実施形態を説明するための略線図である。
【図１９】この発明の第４の実施形態の処理の流れを示すフローチャートである。
【図２０】この発明を適用できる通信システムの一例および他の例を示すブロック図である。
【図２１】入力パケットの到着時間の一例および他の例を示す略線図である。
【図２２】バッファのあふれを説明するための略線図である。
【図２３】トラフィックシェーパの機能を説明するための略線図である。
【図２４】この発明の第５の実施形態の構成を示すブロック図である。
【符号の説明】
１・・・ＲＴＰ回路、２・・・プロトコルスタックおよびルータ、３，３ａ・・・トラフィックシェーパ、４・・・ネットワークコントローラ、５・・・ホストインターフェース、１１，１１ａ・・・ＲＴＰバッファ、１３・・・ＴＳバッファ、１４・・・統合バッファ、２１・・・ＭＰＥＧエンコーダ、２３，２３ａ・・・シェイピングブロック、２３ｂ・・・インターバルカウンタ、２５・・・パケットバッファ、２６，２６ａ・・・通信装置、２７ａ・・・ＴＨｕ監視部、２７ｂ・・・ＴＨｌ監視部、２８・・・ホストＣＰＵ、４１・・・送信側システム、４３・・・ブリッジ、４５・・・受信側システム、４５ａ・・・受信バッファ、５５，５８・・・セレクタ、５６・・・アドレス変換部、５７・・・トラフィックシェーパ

Claims

エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
上記符号化データを第１の記憶手段へ蓄積させた上で、蓄積された上記符号化データを上記ネットワークのプロトコルにしたがってパケット化するネットワークプロトコル処理部と、
上記ネットワークプロトコル処理部のパケット化により生成されたパケットデータを第２の記憶手段に蓄積させ、蓄積された上記パケットデータを等間隔で出力するトラフィックシェイピング部と、
上記トラフィックシェイピング部から出力されたデータを上記ネットワークに対して送出するパケット送出部と、
上記トラフィックシェイピング部から上記第２の記憶手段の使用量を示すバッファ情報を受領することにより、上記使用量が所定値を超えたものと判断された場合には、上記ネットワークプロトコル処理部に対して上記パケットデータの出力を抑制させる制御部とを備えたことを特徴とする通信装置。
請求項１において、
上記制御部は、上記バッファ情報に応じ、上記ネットワークプロトコル処理部に対して上記トラフィックシェイピング部への上記パケットデータの供給を一時的に停止させる通信装置。
エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
上記符号化データを上記ネットワークのプロトコルにしたがってパケット化し、記憶手段へ格納するネットワークプロトコル処理部と、
上記ネットワークプロトコル処理部に対して、上記記憶手段へ格納されたデータを等間隔で出力させるトラフィックシェイピング部と、
上記ネットワークプロトコル処理部から出力されたデータを上記ネットワークへ送出する送出部とを備えたことを特徴とする通信装置。
エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
上記符号化データを上記ネットワークのプロトコルにしたがってパケット化するネットワークプロトコル処理部と、
上記ネットワークプロトコル処理部のパケット化により生成されたパケットデータを等間隔で出力するトラフィックシェイピング部と、
上記トラフィックシェイピング部から出力された上記パケットデータを上記ネットワークに対して送出する送出部と、
上記ネットワークプロトコル処理部と上記トラフィックシェイピング部との間で共有され、上記ネットワークプロトコル処理部によりパケット化されたデータを格納すると共に、上記トラフィックシェイピング部からの要求に応じて格納されている上記パケットデータを上記トラフィックシェイピング部へ供給する記憶手段とを備えたことを特徴とする通信装置。
エンコーダから供給された符号化データをパケット化するステップと、上記ステップにおけるパケット化により生成されたパケットデータを記憶手段に保存し、保存された上記パケットデータを等間隔で上記ネットワークへ送出するステップとを有する通信方法において、
上記記憶手段に保存された上記パケットデータの量に応じて、上記パケットデータの上記記憶手段への供給量を制限するステップを有することを特徴とする通信方法。
エンコーダから供給された符号化データをパケット化してネットワークへ送出する通信装置において、
上記符号化データを上記ネットワークのプロトコルにしたがってパケット化するネットワークプロトコル処理部と、
上記ネットワークプロトコル処理部のパケット化により生成されたパケットデータを記憶する記憶手段と、
上記記憶手段に記憶された上記パケットデータを等間隔で出力するトラフィックシェイピング部と、
上記記憶手段に記憶されている上記パケットデータのデータ量が所定値を超えたか否かを監視して、上記データ量が上記所定値を超えた場合には上記トラフィックシェイピング部に対して上記記憶手段に記憶されている上記パケットデータを強制的に出力させる監視部と、
上記トラフィックシェイピング部から出力された上記パケットデータを上記ネットワークに対して送出する送出部とを備えたことを特徴とする通信装置。
請求項６において、
上記監視部は、上記データ量が上記所定値を超えた場合には、さらに上記エンコーダにおけるエンコードレートを下げるための信号を外部出力する通信装置。
二つのネットワーク間に配置され、いずれか一方のネットワークを介して受信したパケットデータを他方のネットワークに送出する通信装置において、
上記一方のネットワークを介して受信したパケットデータを記憶手段に記憶させ、記憶された上記パケットデータを等間隔で上記他方のネットワークへ送出するトラフィックシェイピング部を備えたことを特徴とする通信装置。
二つのネットワーク間において、いずれか一方のネットワークを介して受信されたパケットデータを他方のネットワークに送出する通信方法であって、
上記一方のネットワークを介して受信したパケットデータ保存し、保存された上記パケットデータを等間隔で上記他方のネットワークへ送出することを特徴とする通信方法。