JPWO2003017577A1 - 伝送装置および伝送方法 - Google Patents

Abstract

優先度の高いデータを安定して送受信する送信装置を提供する。本発明の伝送装置においては、優先して伝送、処理される優先パケットと非優先パケットの処理を独立して行う。送信側では、前記優先パケットの平均送信間隔を前記優先パケットの平均生成間隔より小さくして優先的に送信し、前記処理により生じた送信余裕期間に前記非優先パケットを送信する。受信側では、優先パケットおよび非優先パケットが処理されるレイヤよりも下位レイヤの受信フレームを処理するレイヤにおいて、当該受信フレームに格納されている受信パケットの通信プロトコルヘッダから優先パケットと非優先パケットを選別して、前記優先パケットの処理と前記非優先パケットの処理を独立とする。

Description

技術分野
本発明は優先的に送受信を行うパケット（優先パケット）とそれ以外の非優先のパケット（非優先パケット）を扱う伝送装置および伝送方法に関する。
背景技術
イーサネット等の通信網でビデオ信号等のリアルタイム性を有するデータの伝送を行うために、パーソナルコンピュータのＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスにビデオ信号処理用のボード（ビデオカード）及びネットワークインタフェースカードを装着し、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（以下「ＩＰ」と呼ぶ。）、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（以下「ＵＤＰ」と呼ぶ。）又はＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（以下「ＴＣＰ」と呼ぶ。）等のネットワークプロトコルに従ってパケットを伝送することが一般的に行われている。
図１１は、ビデオ信号をイーサネット伝送する従来例の伝送システムのブロック図である。図１１において、５００はイーサネット・ネットワークインタフェースカード（以下「ＮＩＣ」と呼ぶ。）５０１はビデオカード、５０２はＰＣＩバス、５０３はＣＰＵ、５０４はメモリである。
ＮＩＣ５００は、ＰＣＩインタフェース部（以下「ＰＣＩ Ｉ／Ｆ部」と呼ぶ。）５２０、イーサネット処理部５２１、物理層処理部５２２を有する。ビデオカード５０１は、ビデオ信号処理部５１０、ＰＣＩ Ｉ／Ｆ部５１１を有する。
入力ビデオ信号は、ビデオ信号処理部５１０で処理（例えば圧縮である。）され、ＰＣＩ Ｉ／Ｆ部５１１により、ＰＣＩバス５０２を介してメモり５０４に格納される。ＰＣＩバスでの伝送は、ビデオカード５０１がＣＰＵ５０３に対して割り込みをかけ、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｒｏｙ Ａｃｃｅｓｓ）転送で行われる。
次にストリーム伝送を行うためにまず、ＣＰＵ５０３でのソフトウェア処理により、メインメモリ５０４に格納されたビデオデータを所定長に区切り（「ビデオペイロード」と呼ぶ。）、さらにビデオペイロードの識別のために番号をつけて再びメインメモリ５０４に書き込む（「ビデオパケット」と呼ぶ。）。
ＣＰＵ５０３は、ソフトウェア処理により、メモリ５０４からビデオパケットを読み出し、ＵＤＰ／ＩＰの処理およびイーサネットフレームの処理を行い、生成されたイーサネットフレームを再びメモり５０４に書き込む。一般的にストリーム伝送にはＯＳＩモデルの第４層の処理としてＵＤＰを用い、第３層の処理としてＩＰを用いる（以下、第４層及び第３層をまとめて「ＵＤＰ／ＩＰ」と呼ぶ。）。ＵＤＰ／ＩＰのプロトコル処理および第２層のイーサネットフレームの処理を行ったイーサネットフレームはメモリ５０４に格納される。
ＯＳＩモデルは、物理層である第１層、データリンク層である第２層、ネットワーク層である第３層、トランスポート層である第４層、セション層である第５層、プレゼンテーション層である第６層、アプリケーション層である第７層からなる７層構造を有する。
次に、ＣＰＵ５０３はメモリ５０４内に伝送すべきイーサネットフレームがあることをＮＩＣ５００に通知する。ＮＩＣ５００はＣＰＵ５０３に対して割り込みをかけてＰＣＩインタフェース５２０のＤＭＡ転送によりＰＣＩバス５０２を介してイーサネットフレームを取り込む。イーサネット処理部５２１はイーサネットフレームの付加的な処理を行って、物理処理部５２２にイーサネットフレームを伝える。最終的なイーサネットフレームがイーサネット上に送出される。
受信時にはＮＩＣ５００は、物理層処理部５２２及びイーサネット処理部５２１を介してイーサネットフレームを受信すると、ＣＰＵ５０３に割り込みをかけて、ＰＣＩインタフェース５２０のＤＭＡ転送によりＰＣＩバス５０２を介してメモり５０４に受信したイーサネットフレームを書き込む。次にＣＰＵ５０３は、ソフトウェア処理によりメモリ５０４からイーサネットフレームが読み出し、イーサネットフレームの処理およびＵＤＰ／ＩＰの処理を行い、さらに送信時に付加したビデオペイロード識別のための番号を検出して順序性の保証を行った後に、生成されたビデオパケットを再びメモり５０４に格納する。
次にＣＰＵ５０３は格納されたビデオパケットがあることをビデオカード５０１に通知する。ビデオカード５０１のＰＣＩインタフェース５１１は、ＣＰＵ５０３に対して割り込みをかけてＤＭＡ転送によりＰＣＩバスを介してビデオパケットを取り込む。ビデオカード５０１は、ビデオデータの抽出後伸張等の処理を行ってビデオ出力する。
上記例は、ＵＤＰ／ＩＰのストリーム伝送である。ＴＣＰ／ＩＰによるファイル転送も同様なソフトウェア処理が必要である。ＴＣＰ／ＩＰの場合は上記に加えて、ＴＣＰのフローコントロール処理もソフトウェアで行う。
上記のように転送に関するプロトコル処理及びビデオ伝送等の処理の一部、さらにメモリコピーおよびＰＣＩバス転送のための割り込み処理は全てソフトウェアに依存している。以下、上記のソフトウェア処理による従来例を従来例１と呼ぶ。
さらに別の従来例として、特開２０００−５９４６３号公報に開示されている技術（従来例２と呼ぶ。）がある。
従来例２はリアルタイムデータのパケットを生成する専用の処理手段を備え（従来例２の図２、プロトコル専用処理手段２６）、動画等の大量の連続リアルタイムデータを伝送する場合に、高速送信を可能とするものである。また従来例２はリアルタイムデータの送信レートを制限する機能も有している（従来例２の図２、レート制御手段２３）。
さらに別の従来例として、ＩＥＥＥ１３９４がある（従来例３と称す）がある。従来例３では、送信時間を等時型データ伝送を行う時間帯域（以下、「アイソクロナス部」と呼ぶ。）と等時型データ以外のデータ伝送を行う時間帯域（以下、「非アイソクロナス部」と呼ぶ。）に分割している。アイソクロナス部の時間においてビデオ等のリアルタイム性を必要とするデータ（以下、「リアルタイムデータ」と呼ぶ。）の転送を行う。機器の制御又は設定等のリアルタイム性を必要としない通常データの転送は非アイソクロナス部で行う。これにより、リアルタイムデータと通常データの転送を可能とする。
さらに別の従来例として、特開２００２−１８５９４２号公報に開示されている技術（「従来例４」と呼ぶ。）がある。従来例４は、映像データの送信端末（サーバ）のみに関する。
従来例４の第１の特徴は、映像データのパケットの送出基準として、映像フレームのフレーム表示間隔を使用することである。ただし、具体的にフレーム表示間隔からどのように制御を行うかは開示されていない。
また、第２の特徴は、映像データからなるＵＤＰ／ＩＰパケットが非送出の時に限って、ＴＣＰ／ＩＰパケットの送出を行うということである。なお、このときＵＤＰ／ＩＰパケットはハードウエアで処理され、ＴＣＰ／ＩＰパケットはソフトウエアで処理されることが開示されている。
しかしながら上記従来の構成では以下のような問題点を有していた。
従来例１においては、イーサネットのフレーム処理、ＩＰ処理およびＵＤＰ処理のプロトコル処理を全てＣＰＵで行い、さらにビデオ信号処理の一部もＣＰＵによる処理を行っていた。そのため、高ビットレートのストリーム伝送では処理が間に合わないという問題があった。また、共有バスとしてＰＣＩバスを用いているので優先的に送受信すべきリアルタイム伝送のデータと優先度が低いデータが混在しているのでこの点からもリアルタイム処理が間に合わないと言う問題があった。
これらの問題は以下の２つの理由に起因している。本質的にビデオデータのストリーム伝送のデータレートが非常に高いためにＣＰＵの処理能力の限界を超えてしまう場合が発生することが１つの理由である。ＰＣＩバス上でのイーサネットフレームの転送とビデオパケットの転送においては、ソフトウエア的にはマルチスレッド（マルチプロセス）と呼ばれる見かけ上並列に処理される手法が用いられる。これらは実際にはＣＰＵをタイムシェアリングして行われる処理である。スレッド（あるいはタスク、プロセスと称されることもある）の切り替え時のオーバヘッドによりＣＰＵの処理能力が実質的に低下すること、および処理の際に何度もメモリコピーを行うのでその処理によりビデオ伝送に割り当てられるＣＰＵの処理能力が制限されることが他の１つの理由である。
上記スレッドの切り替えはオペレーティングシステム（以下、「ＯＳ」と呼ぶ。）のソフトウェアに依存し、ユーザが完全には処理の制御を行うことができるものではない。
具体的には従来例１においては、ＮＩＣの送信時に送信すべきデータ（上記の場合はビデオデータ）のデータレートに対して、ＣＰＵがイーサネットフレームを生成する速度が間に合わず、送信できないビデオパケットが発生し、ビデオ画像が破綻するという問題点があった。また、必要なデータレートでイーサネットフレームを生成できた場合でもメモリからＮＩＣへのイーサネットフレームの転送が間にあわないという問題があった。
さらに、ビデオパケットの送信を時間的に定期的タイミングで行うべきいわゆるシェイピング処理がＣＰＵ依存（処理タイミングのゆれを有するソフトウェア依存）となる故に、正確なシェイピングが行われないという問題があった。
また、ビデオ信号等の送信優先度の高いデータと管理情報等の優先度の低いデータの送信割合の決定もＣＰＵ依存（ソフトウェア依存）となる故に、優先度の高いデータが必ずしも優先的に伝送されるとは限らないという問題点があった。
また、ＮＩＣの受信時には、ＣＰＵが受信フレームの処理を行うスレッドへの切り替えが間に合わす、ＣＰＵが到着したイーサネットフレームをメモリに取り込む処理が遅れて、ＮＩＣ内でデータの取りこぼし（イーサネットフレーム廃棄）が発生する恐れがあった。あるいはメモリに取り込めた場合でもＣＰＵのプロトコル処理に時間がかかり、リアルタイム伝送できない恐れがあった。
また、タスクの管理がＯＳに依存しているため、ビデオ信号等の送信優先度の高いデータの処理を管理情報等の優先度の低いデータに対して必ずしも優先的に行うことができないという問題点があった。
使用するＣＰＵを高性能なものにすれば、処理能力を向上させることは可能となるが、本質的に問題を解決するものではない。また高性能なＣＰＵは消費電力が大きい。特にＣＰＵの組み込み機器において放熱が十分でなければ、機器が誤動作する恐れもあった。また、高性能ＣＰＵは高価であるという問題点も有していた。
これらの問題点は、ＣＰＵがビデオ伝送に加えて、管理情報等の付加的な情報の処理を行う場合にはさらに大きくなる。
上記のＣＰＵに関係する問題点の内ネットワーク処理に関する問題点は、一般的なオペレーティングシステムのネットワーク処理がＯＳＩ階層モデルの下位のレイヤで順に行われることに本質的に起因する。
第１層に物理層、第２層にイーサネット、第３層にインターネットプロトコル（ＩＰ）、第４層にＵＤＰを使用するＯＳＩモデル（７層構造）を例として、具体的に説明する。イーサネットの受信端末において、第１層の物理層がイーサネットフレームを受信して終端処理する。次にイーサネット（第２層）がイーサネットフレームの終端処理を行い、ＩＰパケットを抽出し、インターネットプロトコル（第３層）に渡す。インターネットプロトコル（第３層）がＩＰパケットを処理してＵＤＰパケットを抽出し、第４層に渡す。第４層において、ＵＤＰパケットの終端を行う。
このように階層順に処理を行うことが処理オーバーヘッドとなりＣＰＵ（ソフトウエア処理）の負担となっている。
なお、イーサネットの送信側においても上記問題点は同じである。
従来例２においては、リアルタイムデータ用のパケット生成は専用処理手段により行うことでプロセッサへの負担は軽減される。しかし、生成されたリアルタイム用のパケットとプロセッサで生成されたそれ以外のパケットとの制御方法が開示されていない。これらのパケットを従来と同様の方法で制御する場合、以下のような問題点を有していた。
第１の問題点として、リアルタイムデータ用のパケットが必ずしも優先的に送信されないという問題点を有していた。具体的には従来例２においてリアルタイムデータ以外のパケットが大量に発生した場合、リアルタイムデータのパケットの送信に制限が加わり、結果的にリアルタイム性を保証できないという問題点があった。
また、第２の問題点として、リアルタイムデータを優先的に送信しながら、リアルタイムデータ以外のデータも同時にシステムに障害が起こることなく送信できることを保証することができないと言う問題点を有していた。リアルタイムデータ以外のデータとしては、例えば以下に説明するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、システムの管理に使用するＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、あるいはアプリケーション同士の導通を確認するためのデータ等がある。この第２の問題点に関し、従来例２において、図２のレート制御手段２３において、リアルタイムデータのビットレートを絞ることはできる。しかし従来例２には、リアルタイムデータとその他のデータの送信制御方法は開示されていない。換言すると、従来例２は、その他のデータの送信を保証するためにはリアルタイムデータの品質を落とさなければならないという問題点を有していた。
また従来例２は、以下の第３の問題点を有する。イーサネット上でインターネットプロトコル（ＩＰ）使用した伝送を行う場合、送信先のＩＰアドレスを元に、送信すべきイーサネットのＭＡＣ（メディアアクセス制御）アドレスを取得するＡＲＰ処理を行う。ＡＲＰ処理は双方向の通信で行うのでプロセッサを用いて行うことが適切である。しかしながら従来例２において、図２のプロトコル汎用処理手段２５からパラメータ設定手段２９へＡＲＰ処理の結果を通知し、最終的にヘッダ生成手段２６２にＭＡＣアドレスを設定する方法がない。そのために従来例２は、あらかじめパラメータ設定手段２９に保持されている固定的なアドレスにしか、リアルタイムデータを通信できないという問題点を有していた。この理由により、ＡＲＰ処理に限らず例えば上位のＵＤＰプロトコルのポート番号を交渉する場合も、柔軟にポート番号を設定できないと言う問題点も同時に有する。
従来例３においては、リアルタイムデータの伝送帯域をあらかじめ時間割り当てで決定するのでアイソクロナス部で転送すべきリアルタイムデータが割り当てられた転送容量に対して少なく、一方、送信すべき通常データが多い場合は伝送帯域がムダになるという問題点を有していた。この問題点は、非アイソクロナス部に転送すべき通常データが少なく、アイソクロナス部に転送すべきリアルタイムデータが多い場合にも同様の問題が発生する。すなわち従来例３は、リアルタイムデータと通常データの割合を柔軟に変更できないと言う問題点を有していた。
また、従来例３は、転送すべきリアルタイムデータが非アイソクロナス部に割り当てられた時間に発生すれば、次のアイソクロナス部までデータ転送を待たなければならず伝送の遅延が発生するという別の問題点を有していた。多くのアプリケーションは、リアルタイムデータの遅延により重大な影響を受ける。これらのアプリケーションは低遅延でのリアルタイムデータの伝送を要求するので、この問題点は非常に大きな問題である。この遅延の問題は通常データの転送の場合も同様に起こる。転送すべき通常データがアイソクロナス部に発生すれば、次の非アイソクロナス部の時間までデータ転送を待たなければならず同様に遅延の問題が発生する。
従来例４においては、映像データのパケットの送出基準として、映像フレームのフレーム表示間隔を使用する。しかしながらこの場合、映像データの処理に要する時間が、映像フレームの時間間隔を少しでも超えると、例えばリアルタイム性が崩れる等の問題が発生し、映像は破綻する。したがって、映像フレームを基準として使用することは、本質的には非常に大まかな基準で制御することであり、以下のような問題点があった。
例えば、映像フレーム途中で送信に遅れが生じてその映像フレームの最終部分で残るデータをバースト的に送信することにより遅れの回復を図ったとする。しかし、バースト転送をはじめた時点では既に回復不可能な時間となっていれば、１フレームの送信がその映像フレーム期間（リアルタイム性を維持するために処理を完了させなければならない期間である。）内に完了せず、映像が破綻する。この問題は映像データと映像データ以外のデータを混在して送信する場合に特に生じやすい。
従来例４の伝送装置が映像データと映像データ以外のデータを混在して送信する場合に、映像データからなるＵＤＰ／ＩＰパケットが非送出の時に限って、映像以外のデータ（ＴＣＰ／ＩＰパケット）の送出を行う制御をが行われる。従来例４においては、例えば以下のような場合に問題が発生する。
例えば、ＵＤＰ／ＩＰパケットの非送出時に、非常に長いパケット長のＴＣＰ／ＩＰパケットの送信を開始したとする。この場合、このＴＣＰ／ＩＰパケットの送信完了までの間に、短いＵＤＰ／ＩＰパケットの送信準備ができた場合でもＴＣＰ／ＩＰパケットの送信終了までＵＤＰ／ＩＰパケットの送信は開始できない。その結果、ＵＤＰ／ＩＰパケットの送信が遅れ、映像データのリアルタイム性が破綻するという問題があった。
極端な例としてはＴＣＰ／ＩＰパケットの送信開始と同時にＵＤＰ／ＩＰパケットの送信準備が完了したならば、ＵＤＰ／ＩＰパケットはＴＣＰ／ＩＰパケットの送信に要する時間の全ての間、送信待ちの状態となる。
この問題は本質的に、従来例４の映像データの送出優先度が、その他のデータに対して十分には高くないことに起因する。その結果、状況によっては映像データの送信待ちが発生する。
さらに従来例４は、映像以外のパケット（ＴＣＰ／ＩＰパケット）にもタイムアウト時間が設定されるデータがある場合において、以下のような問題点を有していた。
例えば従来例４において、送信すべき映像データが大量にある場合は、映像データ（ＵＤＰ／ＩＰパケット）の非送出時間が発生せず、映像以外のデータ（ＴＣＰ／ＩＰパケット）の送信が極端に遅延する。そのため、このＴＣＰ／ＩＰパケットを送出しようとしたアプリケーションがタイムアウトし、システムの安定運用に障害が生じるという問題点があった。
上記問題点の本質は、ＵＤＰ／ＩＰパケットが非送出の時に限って、映像以外のデータ（ＴＣＰ／ＩＰパケット）の送出を行うという単純なアルゴリズムに起因している。
発明の開示
上記課題を解決するために、本願発明の１つの観点による伝送装置は、優先して送信される優先データから優先パケットを生成する優先パケット生成部と、前記優先パケットよりも送信優先度が低い非優先パケットを生成する非優先パケット処理部と、前記優先パケットと前記非優先パケットの送信タイミングを決定する送信パケット制御部と前記優先パケットと前記非優先パケットの送信処理を行う送信フレーム処理部とを備え、前記送信パケット制御部は前記優先パケットの送信余裕期間に前記非優先パケットの送信を許可することを特徴とする。
さらに好適には、前記非優先パケット処理部は、送信パケット選択部と、優先パケット用バッファと、非優先パケット用バッファを具備し、前記非優先パケット用バッファは送信すべき前記非優先パケットを保持している場合に、前記送信パケット選択部に非優先パケット送信要求信号を出力し、前記送信パケット選択部は前記優先パケットの送信余裕期間に前記非優先パケットの送信を許可することを特徴とする。
さらに好適には、前記送信パケット制御部は、前記優先データのリアルタイム性を損なわない時間を前記送信余裕期間とすることを特徴とする。
さらに好適には、前記送信パケット制御部は、前記優先パケットの送信間隔を前記優先パケットの平均送信間隔より小さくして送信し、前記処理によって生じた余剰時間を前記送信余裕期間とすることを特徴とする。
さらに好適には、前記送信パケット選択部は、前記優先パケット用バッファに送信すべき前記優先パケットがない場合に、前記非優先パケット用バッファに対して前記非優先パケットを送信することを許可することを特徴とする。
さらに好適には、前記送信パケット選択部は、前記優先パケット用バッファに送信すべき前記優先パケットがなく、かつ前記優先パケットを前記優先パケット用バッファに書き込み中でない場合に、前記非優先パケット用バッファに前記非優先パケットを送信することを許可することを特徴とする。
さらに好適には、前記送信パケット制御部は、非優先パケットの送信要求を受けてから所定時間内に前記非優先パケットの送信を許可することを特徴とする。
また、本願発明の他の観点による伝送方法は、優先して送信される優先パケットと前記優先パケットよりも送信優先度が低い非優先パケットとを判別し、前記優先パケットの送信余裕期間に前記非優先パケットを送信することを特徴とする。
さらに好適には、前記優先パケットのリアルタイム性を損なわない時間である送信余裕期間に前記非優先パケットを送信することを特徴とする。
さらに好適には、前記優先パケットの送信間隔を前記優先パケットの平均送信間隔より小さくすることにより生じた余剰時間を前記送信余裕期間とするとすることを特徴とする。
さらに好適には、送信すべき前記優先パケットがない時間を前記送信余裕期間とすることを特徴とする。
さらに好適には、送信すべき前記優先パケットがなく、かつ送信すべき優先パケットの準備中でない時間を前記送信余裕期間とすることを特徴とする。
さらに好適には、所定時間内に少なくともひとつの非優先パケットの送信を保証することを特徴とする。
本願発明の別の観点による伝送装置は、優先して送信される優先データから優先パケットを生成する優先パケット生成部と、前記優先パケットよりも送信優先度が低い非優先パケットの処理を行う非優先パケット処理部と、前記優先パケットと前記非優先パケットの送信タイミングを決定する送信パケット制御部と、前記優先パケットと前記非優先パケットの送信処理を行う送信フレーム処理部と、ネットワークから受信される受信フレームの受け入れ処理を行う受信フレーム処理部と、受信パケットを選別して前記非優先パケットを前記非優先パケット処理部に転送する受信パケット処理部と、を備え、前記非優先パケット処理部は、前記受信パケットから前記優先パケットのヘッダ情報を取得し、前記ヘッダ情報を前記優先パケット生成部に設定することを特徴とする。
さらに好適には、前記ヘッダ情報は、送信先アドレスに応じて変化する情報であることを特徴とする。
さらに好適には、前記ヘッダ情報取得の処理はＩＰアドレスからＥｔｈｅｒｎｅｔの物理アドレス（ＭＡＣアドレス）を求める処理である。
また本願発明の更に別の観点による伝送方法は、優先して送信される優先パケットの送信ステップと、前記優先パケットよりも送信優先度が低い非優先パケットの送信ステップ及び受信ステップとを有し、前記非優先パケットの送信ステップ及び受信ステップにより前記優先パケットのヘッダ情報を取得し、前記優先パケットの送信ステップにおいて、前記優先パケットのヘッダ情報を前記優先パケットに設定して送信することを特徴とする。
さらに好適には、前記ヘッダ情報は、送信先アドレスに応じて変化する情報である。
さらに好適には、前記ヘッダ情報取得はＩＰアドレスからＥｔｈｅｒｎｅｔの物理アドレス（ＭＡＣアドレス）を求める処理である。
本願発明の更に別の観点による伝送装置は、優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットを受信し、受信フレームの受け入れ処理を行う受信フレーム処理部と、前記受信フレーム処理部に格納された受信パケットを、前記受信パケットに格納されている通信プロトコルヘッダを検査することにより、前記優先パケットと前記非優先パケットに選別する受信パケット選別部と、を有することを特徴とする。
さらに好適には、前記受信パケット選別部は少なくとも前記受信パケットに格納されている通信プロトコル種別から前記優先パケットと前記非優先パケットを選別することを特徴とする。
さらに好適には、前記受信パケット選別部は少なくとも前記受信パケットに格納されているポート番号を検査することにより前記優先パケットと前記非優先パケットを選別することを特徴とする。
さらに好適には、前記受信パケット選別部は少なくとも前記受信パケットに格納されているフローラベルを検査することにより前記優先パケットと前記非優先パケットを選別することを特徴とする。
さらに好適には、前記受信パケット選別部は前記受信パケットを構成するプロトコルレイヤ（プロトコルレイヤ１）よりも上位のプロトコルレイヤ（プロトコルレイヤ２）の検査を行い、前記優先パケットは前記プロトコルレイヤ２の終端を行い、前記非優先パケットは前記プロトコルレイヤ１のまま前記非優先パケット処理部に転送することを特徴とする。
さらに好適には、前記受信パケット選別部は、異なるレイヤの通信プロトコルヘッダを同時に検査することを特徴とする。
また本願発明の更に別の観点による伝送方法は、優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットからなる受信パケットを受信する受信ステップと、前記受信パケットに格納されている通信プロトコルヘッダを検査することにより前記優先パケットと前記非優先パケットとを選別する選別ステップと、前記優先パケットと前記非優先パケットとをそれぞれ独立処理する処理ステップと、を有する。
さらに好適には、前記選別ステップにおいて、前記通信プロトコルヘッダの少なくとも通信プロトコル種別を検査することにより、前記優先パケットと前記非優先パケットを選別することを特徴とする。
さらに好適には、前記選別ステップにおいて、前記通信プロトコルヘッダの少なくともポート番号を検査することにより、前記優先パケットと前記非優先パケットを選別することを特徴とする。
さらに好適には、前記選別ステップにおいて、前記通信プロトコルヘッダの少なくともフローラベルを検査することにより前記優先パケットと前記非優先パケットを選別することを特徴とする。
さらに好適には、前記選別ステップにおいて、前記受信パケットを構成するプロトコルレイヤ（プロトコルレイヤ１）よりも上位のプロトコルレイヤ（プロトコルレイヤ２）の検査を行い、前記優先パケットは前記プロトコルレイヤ２の終端を行い、前記非優先パケットは前記プロトコルレイヤ１のまま後のステップに転送することを特徴とする。
さらに好適には、前記選別ステップにおいて、異なるレイヤの通信プロトコルヘッダを同時に検査することを特徴とする。
本願発明の更に別の観点による伝送装置は、優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットとを受信する受信フレーム処理部と、前記優先パケットのデフラグメント処理を行う第１のデフラグメント処理部と、前記非優先パケットのデフラグメント処理を行う第２のデフラグメント処理部とを含む複数のデフラグメント処理部と、を有することを特徴とする。
さらに好適には、受信フレーム処理部に格納された受信パケットを前記優先パケットと前記非優先パケットに選別する受信パケット選別部を更に有し、前記非優先パケットの処理を行う非優先パケット処理部が前記第２のデフラグメント処理部を含むことを特徴とする。
さらに好適には、前記受信パケット選別部は、前記受信パケットがフラグメントされていない場合は、前記受信パケットが前記優先パケットか前記非優先パケットかを判定すると共に分離して出力し、前記受信パケットがフラグメントされている場合において、前記受信パケットが前記非優先パケットであると判定可能な場合は、前記受信パケットを前記非優先パケット処理部に転送すると共に当該受信パケットの識別子を記憶し、前記受信パケットが前記優先パケットであると判定可能な場合は、前記受信パケットを前記第１のデフラグメント処理部に転送すると共に当該受信パケットの識別子を記憶し、前記受信パケットの情報だけでは前記優先パケットであるか前記非優先パケットであるかを判定不可能な場合は、前記識別子を使用して判定し、前記識別子を使用しても判定不可能な場合は、前記受信パケットを前記第１のデフラグメント処理部に転送し、前記第１のデフラグメント処理部は少なくとも前記優先パケットのデフラグメント処理を行うと共に、前記受信パケットが前記非優先パケットと判断された場合は、当該受信パケットに関連する全てのパケットを前記非優先パケット処理部に転送し、前記非優先パケット処理部は前記非優先パケットのデフラグメント処理を行う、ことを特徴とする。
本願発明の更に別の観点による伝送装置は、優先して送信される優先データに誤り訂正用符号を付加して前記優先データと共に優先パケットとして生成する優先パケット生成部と、前記優先パケットよりも送信優先度が低い非優先パケットを生成する非優先パケット処理部と、前記優先パケットと前記非優先パケットの送信タイミングを決定する送信パケット制御部と、前記優先パケットと前記非優先パケットの送信処理を行う送信フレーム処理部と、ネットワークから伝送障害を検知して前記送信フレーム処理部に通知する受信フレーム処理部とを備え、前記送信パケット制御部は前記伝送障害により前記優先パケットの送信が遅延した場合に、前記誤り訂正用符号が格納された前記優先パケットを間引いて送信することを特徴とする。
さらに好適には、前記伝送障害はネットワークからの送信停止要求である。
さらに好適には、前記送信パケット制御部は前記伝送障害検出時に所定期間パケットの送信を停止する。
さらに好適には、前記伝送障害はネットワークでのパケットの衝突検出である。
さらに好適には、前記送信パケット制御部は前記伝送障害検出時に障害の起こったパケットの再送を行う。
また本願発明の更に別の観点による伝送方法は、優先して送信される優先データに誤り訂正用符号を付加して前記優先データと共に優先パケットとして送信する優先パケット送信ステップと、前記優先パケットよりも送信優先度が低いパケットを非優先パケットとして送信する非優先パケット送信ステップと、を有し、伝送路に伝送障害が発生した場合は、前記優先パケット送信ステップにおいて、前記誤り訂正用符号が格納された前記優先パケットを間引いて送信することを特徴とする。
さらに好適には、前記伝送障害はネットワークからの送信停止要求である。
さらに好適には、前記伝送障害はネットワークでのパケットの衝突検出である。
本願発明の更に別の観点による伝送装置は、優先して処理される優先データを格納した優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットを受信し、受信フレームの受け入れ処理を行う受信フレーム処理部と、前記受信フレームに格納された受信パケットを前記優先パケットと前記非優先パケットに選別する受信パケット選別部と、少なくとも前記優先パケットのデフラグメント処理を行うデフラグメント処理部と、前記優先データの処理の完了の通知である優先データ処理完了通知を発行する優先データ処理監視部と、を備え、前記デフラグメント処理部は、前記優先データ処理完了通知を受けた時までに処理されるべきであった前記優先パケットのデフラグメント処理を終了させる。
さらに好適には、前記優先データ完了通知は通信プロトコルヘッダの識別情報を元に生成されることを特徴とする。
さらに好適には、前記受信フレーム処理部、前記受信パケット選別部又は前記デフラグメント処理部は、前記優先データ処理完了通知を受けた時までに処理されるべきであった前記優先パケットを受信した場合はその優先パケットを廃棄することを特徴とする。
また本願発明の更に別の観点による伝送方法は、優先して処理される優先データを格納した優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットを受信する受信ステップと、前記優先データの処理が終了した場合に、処理が終了した時までに処理されるべきであった前記優先パケットのデフラグメント処理を終了させるデフラグメント処理終了ステップと、を有することを特徴とする。
さらに好適には、処理が終了した時までに処理されるべきであった前記優先パケットを受信した場合はその優先パケットを廃棄する廃棄ステップを更に有する。
発明を実施するための最良の形態
まず最初に、本願発明の、システム全体における位置づけを説明する。
図２は本願発明を適応するシステム全体ブロック図である。図２において、優先して処理される優先データとしてビデオ入出力信号を例示している。２００はＮＩＣである。ＮＩＣ２００は、優先パケットと非優先パケットとを重畳し分離するパケット重畳・分離部２０１、ビデオ信号処理部２０２、イーサネットの物理層処理を行う物理層処理部２０３、ＰＣＩ Ｉ／Ｆ部２０４を有する。ＰＣＩバス５０２、メモリ５０４、ＣＰＵ５０３は図１１と同じである。
本実施例においては、ビデオ信号処理部２０２で画像圧縮等の処理を行われたビデオ入力信号が、優先データとしてパケット重畳・分離部２０１に入力される。
また、イーサネットを通じて受信されたイーサネットフレーム（ビデオパケット）が優先データとしてパケット重畳・分離部２０１からビデオ信号処理部２０２に入力される。以下、優先データから生成されたパケットを「優先パケット」と呼ぶ。
一方ＰＣＩバス５０２経由でも、ＣＰＵ５０３でソフトウェア処理されるイーサネットフレームが入出力される。ＰＣＩバス経由で入出力されるイーサネットフレームに格納されるデータとして、例えば機器の遠隔監視を行うＳＮＭＰのデータがある。これはＵＤＰ／ＩＰあるいはＴＣＰ／ＩＰを用いて伝送される。あるいはＴＣＰ／ＩＰを用いて送受信するアプリケーションレベルでの機器の設定データ又は種々の情報データがある。さらにはＡＲＰ処理を行うイーサネットフレームがある。これらのデータはビデオデータのようにリアルタイムに伝送を行う必要がないのでビデオデータよりも処理の優先度が低くてもよい。しかし一定時間内に送受信されなければタイムアウトとなり、システム障害を起こす可能性がある。以下、これらのデータから生成されたパケットを「非優先パケット」と呼ぶ。
パケット重畳・分離部２０１は送信時には優先パケットと非優先パケットの送出制御を行い、イーサネットフレームを出力する。物理層処理部２０３は物理層の処理を行い、イーサネットフレームをイーサネットに送出する。受信時には物理層処理部２０３で受信されたイーサネットフレームがパケット重畳・分離部２０１に入力されて優先パケットと非優先パケットに分離される。優先パケットはビデオ信号処理部２０２に、非優先パケットはＰＣＩインタフェース２０４に出力される。なお非優先パケットはパケット重畳・分離部２０１ではイーサネットフレームの終端処理を行わず、非優先パケットを含んだイーサネットフレームの形式のままＰＣＩ Ｉ／Ｆ部２０４に転送される。
優先パケットであるビデオデータはビデオ信号処理部２０２で伸張処理が施され出力される。一方非優先パケットはＰＣＩインターフェース２０４を介してＰＣＩバス５０２経由でメモリ５０４に転送され、ＣＰＵ５０３でソフトウェア処理される。実施例１から５において本願発明の主要部は、パケット重畳・分離部２０１、ＰＣＩ Ｉ／Ｆ部２０４、メモリ５０４およびＣＰＵ５０３で構成される部分である。また実施例６においては上記に加え、ビデオ信号処理部２０２の一部を主要部に含む。
本願発明の実施例ではイーサネットを用いる伝送装置及び伝送方法を例として説明する。パケット重畳・分離部２０１と物理層処理部２０３間のインターフェースにおいては、１０Ｍｂｐｓおよび１００ＭｂｐｓのイーサネットではＭＩＩ標準インタフェースが規定されており、ギガビットイーサネットではＧＭＩＩ標準インタフェースが規定されている（ＩＥＥＥ８０２．３）。
図１は本発明の実施例の伝送装置の構成を示すブロック図である。以下、図２を用いて説明した本願発明の伝送装置の詳細について図１を用いて説明を行う。
図１において１０００は優先パケット生成部、１００１は非優先パケット処理部、１００２は送信パケット制御部、１００３は送信フレーム処理部である。非優先パケット処理部１００１は図２のＣＰＵ５０３、メモリ５０４、およびＰＣＩ Ｉ／Ｆ部２０４で構成されている。１００４は受信フレーム処理部、１００５は受信パケット選別部、１００６はデフラグメント処理部、１００７はアプリケーションである。また、優先データ処理監視部１００８はビデオ信号処理部２０２の内部に実装される。アプリケーション１００７はＣＰＵ５０３により実行される。優先パケット生成部１０００、送信パケット制御部１００２、送信フレーム処理部１００３、受信フレーム処理部１００４、受信パケット選別部１００５及びデフラグメント処理部１００６は、ハードウエア処理を実行する（ＣＰＵを含まない）パケット重畳・分離部２０１に含まれる。
なお、図１は実施例１〜６の伝送装置の全ての構成要素を図示している。個々の実施例（実施例１〜６）は図１の構成要素の全部または一部を用い、それらの構成要素により各実施例の機能を実現する。本明細書では各々の実施例の説明時に図１のブロック図を参照して説明する。
図３は実施例における優先パケットのプロトコルスタックを示している。実施例の伝送装置は、ＵＤＰ／ＩＰのプロトコルスタックを使用している。アプリケーションであるビデオデータ３０００は優先データとして一定長のビデオペイロードに分割され、シーケンス番号（ＳＮ）を付与される（３００１）。このシーケンス番号は受信側でビデオデータの位置（当該パケットが属するフレーム及びフレーム内での順番）を特定するものである。シーケンス番号の付与の仕方はどのような方法でも良い。実施例におけるシーケンス番号の付与方法を説明する。
シーケンス番号は、ビデオフレームの番号を表す情報とビデオフレーム内での位置を表す情報に階層化し、ここではそれぞれ８ビットで０から２５５までで表す。以下ビデオフレーム番号Ａとビデオフレーム内での位置情報Ｂを（Ａ，Ｂ）と表す。
最初のフレームにはフレーム番号０を付与する。次のフレームではフレーム番号を１つずつ増加させる。フレーム番号が２５５の次は０に戻る。各フレーム内では０から９９までのパケットが生成されるとする。フレーム内では０から９９を繰り返す。ビデオパケットには、以下のようなシーケンス番号が付与される。
（０，０）（０，１）（０，２）・・・（０，９９）（１，０）（１，１）（１，２）・・・（１，９９）（２，０）（２，１）・・・
なお、ビデオデータ内にあらかじめ位置を特定する情報が含まれている場合はシーケンス番号は必須ではない。
また、誤り訂正のためにマトリックス構造で伝送する場合はＡをマトリックス番号、Ｂをマトリックス内での位置情報としてもよい。
シーケンス番号を付与されたデータ（ビデオパケット）は、下位層のＵＤＰのペイロードとなる。
ビデオパケットに対して、ＵＤＰ処理（第４層）では、ＵＤＰヘッダが付加される（３００２）。さらにＩＰ（第３層）では、ＩＰヘッダが付加される（３００３）。さらにイーサネットレイヤ（第２層）ではイーサネットヘッダが付加される（３００４）。
なお、本願発明における優先パケットはイーサネットレイヤにおけるパケットを意味し、実際にイーサネットでの伝送を行う場合は、プリアンブルや誤り検出用のコードを付加されたイーサネットフレームで伝送される。
図４は非優先パケットのプロトコルスタックを示している。非優先データ４０００は非優先データペイロードに分割され（４００１）、ＵＤＰレイヤにおいてＵＤＰヘッダを付加され（４００２）、ＩＰレイヤにおいてＩＰヘッダを付加され（４００３）、イーサネットレイヤにおいてイーサネットヘッダを付加されて非優先パケットとなる（４００４）。なお、非優先データが短いデータの場合は分割されないことは言うまでもない。
なお、ＵＤＰヘッダ、ＩＰヘッダ、イーサネットヘッダの詳細については後述する。
《実施例１》
実施例１の伝送装置及び伝送方法を説明する。実施例１の伝送装置は図１において、優先パケット生成部１０００、非優先パケット処理部１００１、送信パケット制御部１００２および送信フレーム処理部１００３を有する。実施例１においては、送信系を説明する。
本実施例では、図３に示したビデオデータを入力優先データ１１００（図２にも図示）として入力する。ビデオデータをリアルタイムでストリーム伝送するためにはリアルタイム性を必要としないデータよりも優先的に処理される必要がある。
実施例１においては、優先パケットの送信を管理することにより送信余裕期間を作り出している。「送信余裕期間」とは、非優先パケットの送信を行っても、優先パケットに格納された優先データのリアルタイム性を損なわない期間を言う。実施例１の制御方法は、優先パケットの送信を優先させつつ、送信余裕期間に非優先パケットをできるだけ伝送する。
優先パケット生成部１０００は、図３に示したように、ビデオデータ１１００を処理してイーサネットフレーム（優先パケット１１０１）を生成する。
一方、非優先パケット処理部１００１は、図４に示すようにＣＰＵを用いてソフトウェア処理により非優先パケット１１０２を生成して転送する。非優先パケットはリアルタイム性の必要のないデータである。非優先パケット１１０２の例としては、前述したＳＮＭＰ処理、ＡＲＰ処理等に使用するパケットがある。この中で、ＡＲＰ処理あるいはその他のアプリケーションにおいては送信パケットに対する応答パケットを待ち、所定時間応答がないとタイムアウトしてシステムに障害を与える場合があるので、非優先パケットの送信機会は出きる限り確保しなければならない。つまり、本願発明の要点は優先パケットのリアルタイム性を損なわないようにできるだけ非優先パケットの送信を可能とすることである。
なお、図１における非優先パケット１１０２および１１０３（実施例３において詳述する。実施例１には関係しない。）については、実際にはＰＣＩバス等の共有バスで非優先パケットの転送および非優先パケットの処理に関するコマンドの転送が行われることが一般的である。
図５は送信パケット制御部１００２の構成を示すブロック図である。図５において５０００は優先パケット用バッファ、５００１は非優先パケット用バッファ、５００２は送信パケット選択部である。
次に図２を用いて優先パケットおよび非優先パケットの送信決定方法を説明する。非優先パケットバッファ５００１は、送信すべき非優先パケットが生成されると、送信パケット選択部５００２に対して、非優先パケット送信要求信号５００７をアサートして送信要求を行う。送信パケット選択部５００２は優先パケットの送信を優先させつつ、優先パケットのリアルタイム性を損なわない範囲で非優先パケットの送信を許可する非優先パケット送信許可信号５００６をアサートして非優先パケットバッファ５００１からの送信を許可する。非優先パケットバッファ５００１は、非優先パケット５００５を送信パケット選択部５００２に転送する。送信パケット選択部５００２は、非優先パケットを送信フレーム処理部１００３を通じてイーサネットに出力する。
一方優先パケット用バッファ５０００は、送信パケット選択部５００２に対して優先パケット情報５００８を通知する。具体的には、優先パケット情報５００８は送信すべき優先パケットが優先パケット用バッファ５０００に存在するか否かを示す情報、および優先パケット１１０１が優先パケット用バッファ５０００に書き込み中であるか否かを示す情報である。
優先パケット用バッファ５０００に送信すべき優先パケットが格納されると（優先パケット情報５００８により知ることができる。）、送信パケット選択部５００２は優先パケットバッファ５０００に対して優先パケットの送信を許可する優先パケット送信許可信号５００４を通知する。この通知に従って、優先パケット５００３は優先パケット用バッファ５０００から送信パケット選択部５００２に転送される。
つまり送信パケット選択部５００２は、非優先パケット送信要求信号５００７と優先パケット情報５００８の情報を得て、優先パケットの送信を優先させつつ、送信余裕期間を創出することにより、システムに障害を与えることがないように非優先パケットの送信を実現する。以下、送信余裕期間を創出する方法に関して具体的に説明する。
図６は実施例１の伝送方法における送信タイミングチャートである。実施例１の伝送方法は、優先パケットと非優先パケットの送信制御方法の一例である。
図６において、４０１は送信パケット１１０４の送信開始タイミング、４０２は非優先パケット送信要求信号５００７、４０３は送信パケット１１０４を示す。４０１では優先パケット送信開始タイミングを上向き矢印で示し、非優先パケットを送信可能なタイミングを下向き矢印で示している。また送信パケット４０３では優先パケットを白抜き、非優先パケットを黒塗りで図示している。
本実施例では、一例として以下のような優先データを送信する場合を説明する。優先データは４８メガビット／秒（４８Ｍｂｐｓ）の一定レートでデータが発生するビデオ信号（ＣＢＲ：Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）、ビデオパケット内のビデオペイロード長（図３に図示）は１０００バイト、システムクロックは２７ＭＨｚとする。
優先データのデータレートは４８Ｍｂｐｓなのでバイトに換算すると、６メガバイト／秒（６Ｍｂｐｓ）である。したがって秒間の送信パケット数は、
６００００００／１０００＝６０００ パケット
である。
したがって、優先パケットのみを伝送する場合であれば、
２７００００００／６０００＝４５００ クロック
に一回パケットを送信すればよい。つまり４５００クロックが平均送信間隔である。
実施例１では、この平均送信間隔より短い間隔で優先パケットを送出することにより、非優先パケットを送信するタイミング余裕（送信余裕期間）を創出する。
具体的には、優先パケットの送出間隔を４０００クロックとする。そして、優先パケット９回毎に１回、非優先パケットの送信を許可可能な送信余裕期間を創出する。平均送信間隔４５００クロックで９個の優先パケットを送信するには、下記の式より４０５００クロックの期間を要する。
４５００＊９＝４０５００
本実施例では４５００クロックよりも短い４０００クロックで各優先パケットを送信するので、実際には３６０００クロック（下記の式）で９個の優先パケットを送信することができる。
４０００＊９＝３６０００
したがって４０５００クロックの期間毎に、４５００クロック（下記の式）の非優先パケットを送信する送信余裕期間を設けることができる。
４０５００−３６０００＝４５００
図４の４０１の優先パケットを送信する上向き矢印から次の矢印までの間隔は４０００クロックである。９回の優先パケット送信タイミングにつき１回、非優先パケットの送信タイミングが現れる（４１０、４１１，４１２）。非優先パケットの送信タイミングである下向き矢印から次の矢印までは４５００クロックである。
４０２は非優先パケット送信要求信号５００７である。非優先パケット送信要求信号５００７は非優先パケット用バッファ５００１に送信すべき非優先パケットが蓄積されると、非優先パケット用バッファ５００１によってアサートされる（図６においては４０２がＨｉｇｈになる）。
非優先パケット送信要求信号５００７（４０２）がタイミング４１３でＨｉｇｈになり、次に非優先パケットの送信が可能になったタイミング４０１で非優先パケット送信許可信号５００６がアサートされ（図４には図示せず）非優先パケット５００５（４１７）が送信される。非優先パケット用バッファ５００１にそれ以上送信すべき非優先パケットがない場合は、非優先パケットが送信開始されたタイミングで非優先パケット送信要求信号５００７（４０２）はデアサートされる（タイミング４１４）。
タイミング４１１では、送信すべき非優先パケットは非優先パケット用バッファ５００１には存在せず、非優先パケット送信要求信号５００７（４０２）がアサートされていない。４０３に示すように非優先パケットは送信されない。
つぎにタイミング４１５で非優先パケット送信要求信号５００７（４０２）が再びアサートされ、タイミング４１２で非優先パケット４１８が送信される。４０２は非優先パケット４１８が送信開始されると、非優先パケット送信要求信号５００７（４０２）はデアサートされる。
なお、送信側非優先パケット蓄積部５００１に複数の非優先パケットが蓄積されている場合は、一つの非優先パケットが送信されても、非優先パケット送信要求信号５００７（４０２）はデアサートされない。残りの非優先パケットは次の非優先パケット送信可能タイミング（４０１の下向き矢印）を待って、１パケットずつ送信される。このようにして優先パケットが優先的に送信されつつ非優先パケットの送信が保証される。
送信を許可された優先パケットおよび非優先パケットは送信パケット選択部５００２から送信パケット１１０４として出力される。
なお、非優先バッファ５００１において非優先パケットが送信完了状態になってから（即ち非優先パケットの全体が完全に非優先パケット用バッファ５００１に格納されてから）、非優先パケット送信要求信号５００７をアサートする。これにより、非優先パケット送信許可信号５００６をアサート直後から非優先パケットの送信が開始可能となる。非優先パケットの送信許可から実際に非優先パケットが送信されるまでのレイテンシがないので、実施例の伝送方法は伝送効率がよい。
上記に説明した方法ではあらかじめ非優先パケットを転送可能なタイミングを一定時間毎に割り当てている。しかし、これは一例であり、従来例３と異なり、アプリケーションに応じて、非優先パケットへの割り当て間隔やタイミングを自由に決定可能であり、クロック単位で柔軟な制御を行うことが可能となる。
本実施例では、あらかじめクロック単位で優先パケット及び非優先パケットの送信に割り当てる時間を決めた。しかし、この方法に限らず、例えば優先パケット用バッファ５０００に一定量の優先パケットを格納し、優先パケット生成部１０００での優先パケットの平均パケット生成量よりも短い時間間隔で優先的に送信を行い、優先パケット用バッファ５０００での優先パケットの格納量が所定値以下になったときに、非優先パケットの送信を許可してもよい。
次に、優先パケットと非優先パケットの送信制御方式の別の例を説明する。
送信パケット選択部５００２は優先パケット情報５００８により、優先パケット用バッファに送信すべき優先パケットがなく、かつ非優先パケット送信要求信号５００７がアサートされている時は非優先パケット送信許可信号５００６をアサートして非優先パケットを送信する。
優先パケットの優先度をさらに高めたい場合は、優先パケット情報５００８が優先パケットに送信すべき優先パケットがなく、かつ優先パケット１１０１が優先パケット用バッファ５０００に書き込み中ではなく、かつ非優先パケット送信要求信号５００７がアサートされている時は非優先パケット送信許可信号５００６をアサートして非優先パケットを送信すればよい。優先パケット用バッファ５０００に現在送信準備ができている優先パケットがない場合でも、優先パケット１００１が優先パケット用バッファ５０００に書き込み中である場合は、優先パケットの送信準備中ということであり、非優先パケットの送信を待たせることにより、さらに優先パケットの送信優先度がを高めることができる。この特徴は従来技術の問題点を解決するものであり、本願発明独自の効果である。
なお、この場合非優先パケット用バッファで送信準備ができている非優先パケットの長さ、すなわち非優先パケットの送信に要する時間と、現在優先パケット用バッファ５０００に書き込み中の優先パケットが送信準備できるまでの時間とを比較して、非優先パケットを送信終了しても優先パケットの書き込みが終了しない場合は非優先パケットの送信を許可するなどとしてもよい。
この方法によれば、送信すべき優先パケットがない場合あるいは準備中でない場合はいつでも非優先パケットを送信可能であり、伝送効率が非常によい。
次に、優先パケットを優先的に送信しつつ、非優先パケットの送信もある程度保証する例を説明する。
送信パケット選択部５００２の中にタイマを備え、非優先パケット送信要求信号５００７がアサートされてから所定時間経過しても、上記に説明したような非優先パケットの送信が許可される条件にならなかった場合、優先パケット送信許可信号５００４を止めて、非優先パケット送信許可信号５００６を例えば１バケット分だけ許可する。なお、非優先パケットを使用するアプリケーションに応じて上記の所定時間を柔軟に変更すればよい。なお、タイマはカウンタで容易に実現することができる。
この方法は、優先パケットの送信を優先させつつ、非優先パケットを使用するアプリケーションが一定時間応答がない場合タイムアウトしてしまうような場合に、優先パケットでリアルタイム性を保証しつつ、制御信号等の非優先パケットを使用するアプリケーションの品質も保証するという効果がある。
この特徴は従来技術の問題点を解決するものであり、優先パケットの送信を優先させつつ、非優先パケットの伝送品質も保証するという、本願発明独自の効果である。
以上のように、実施例１の伝送装置及び伝送方法はクロック単位で優先パケットと非優先パケットの送信の制御が可能であり、リアルタイム通信を保証して高品質な伝送を保証すると共に、非優先パケットの伝送も保証することが可能でありシステムの安定的な運用が可能となる。また、クロック単位で制御を行うので正確なシェイピングが行われる。
以上説明した様に、実施例１においては、送信時にリアルタイムデータと非リアルタイムデータの割合をクロック単位で柔軟に変更でき、更にリアルタイムデータをクロック単位で優先して送信できるので、データの伝送遅延が少ないという効果を有する。
なお、本実施例では、秒を大元の送信基準単位として、それより細かな単位で送信の基準信号（４０１）を生成し、クロック単位で送信制御を行った。しかし、大元の送信基準信号は秒に限らず、映像フレーム、映像フィールド等、映像データの基準信号（映像期間と称す）であればどのような信号でもよい。本願発明の本質は映像期間をさらに細かな単位に区切り送信制御を行うことにより、映像データを優先して送出してリアルタイム性を確保すると共に、映像データ以外のデータに関しても一定の伝送品質の保証を可能とするものである。したがって、どのような映像信号期間を基準としても、本願発明の範囲から排除するものではない。
本実施例ではビデオ等のリアルタイム伝送のパケットを優先パケットの例とした。リアルタイム伝送ではなく、特定のデータを大量かつ優先的に伝送する場合にも本願発明が有効であることは明らかである。本願発明は、その技術的範囲からこのような伝送を排除するものではない。
本実施例では優先パケットをハードウェア処理により生成し、非優先パケットを独立に（優先パケットと別個のブロックで）生成して、さらにハードウェアによりクロック単位で優先パケットを優先して送出する例を示した。しかし、本発明はこれに限られない。
プロセッサとソフトウェアを使用する本発明の他の実施例の伝送方法を以下に説明する。従来例では、ネットワーク処理を階層別に行うためプロセッサ（ＣＰＵ）の処理負担が大きかった。従来例では、送信パケットを階層別に処理してヘッダを付加した。本発明の他の実施例においては、階層別に処理に代えて、イーサネットヘッダ、ＩＰパケットヘッダおよびＵＤＰパケットヘッダをあらかじめ準備してソフトウェアで同時に付加する（図３の３００１の各ビデオパケットに対して上記の全てのヘッダを同時に付加する。）。これにより、プロセッサ処理の負荷を軽減する。非優先パケットについては、一般のオペレーティングシステムに実装されている処理と同様の階層別の処理を行う。
この方法では、優先パケットの処理および非優先パケットのソフトウェア処理をスレッドを分けて実行することにより処理を論理的に分離し、優先パケットの処理の優先度を非優先パケットの優先度に対して高くしている。
送信制御はハードウェアのタイマの代わりに、ソフトウェアタイマを使用すればよい。
なお、この方法は図１において、送信パケット制御部１００２が担う処理を、プロセッサで実行することで実現可能である。
この方法によれば、ハードウェアによる方法よりは送信制御の精度が悪いものの、プロセッサ処理の負荷が従来技術よりは大幅に軽減されるので、本願発明の効果を有する。したがってこのような構成を本願発明の範囲から排除するものではない。
《実施例２》
実施例２の伝送装置及び伝送方法を説明する。実施例２においては、送信系及び受信系を説明する。
ＩＰ伝送を行う際には、送信先ＩＰアドレスからイーサネットの物理アドレス（ＭＡＣアドレス）を求めるプロトコルであるＡＲＰが使用される。
図８は、本発明の実施例におけるＵＤＰ、ＩＰおよびイーサネットプロトコルヘッダの詳細を示す図である。ＩＰ伝送を行う時、実施例の伝送装置は図８の宛先ＩＰアドレス８０１１から送り先ＭＡＣアドレス８１００を解決して、図３の３００４のイーサネットヘッダに格納して、パケットを構成する。
このＡＲＰは双方向通信で行われる。一般的にはプロセッサを用いてアドレス解決が行われメモリに宛先ＩＰアドレスと宛先ＭＡＣアドレスの対応表が保持される。ＡＲＰはリアルタイム性を要求する処理ではないので、ＡＲＰに使用するパケットは非優先パケットとして処理する。以下、図１を用いて本発明の実施例２の伝送装置における処理を説明する。
実施例２の伝送装置は図１において、優先パケット生成部１０００、非優先パケット処理部１００１、送信パケット制御部１００２、送信フレーム処理部１００３、受信フレーム処理部１００４および受信パケット選別部１００５を有する。なお、図１にはＡＲＰのソフトウェア処理としてアプリケーション１００７を図示している。
優先パケットの宛先ＩＰアドレスから転送すべきＭＡＣアドレスを解決するために、アプリケーション１００７は非優先パケット処理部１００１にＡＲＰのためのパケットを生成させる（以下「ＡＲＰ要求パケット」と呼ぶ。）。ＡＲＰ要求パケットは、送信パケット制御部１００２および送信フレーム処理部１００３を介してイーサネットフレームに変換される。イーサネットフレームである送信フレーム１２８が送信される。
一方、ＡＲＰ要求パケットに対して、送信すべきＭＡＣアドレスを解決して当該アドレスを含んだ応答パケット（以下、「ＡＲＰ応答パケット」と呼ぶ。）が受信フレーム１３０として受信フレーム処理部１００４で受信される。ＡＲＰ応答パケットは、受信パケット選別部１００５で非優先パケットであると判定されて非優先パケット処理部１００１に転送される。非優先パケット処理部１００１は宛先ＩＰアドレスと宛先ＭＡＣアドレスとの対応テーブルを保持すると共に、ＭＡＣアドレスを優先パケット生成部１０００に通知する。
優先パケット生成部１０００では解決したＭＡＣアドレスを図８の８１００（図３のイーサネットヘッダ）に格納して優先パケットを生成して出力する。
一般的にＡＲＰのプロトコル処理はオペレーティングシステムに実装されている。したがってこれらの標準ソフトウェアとプロセッサを利用して簡易にＩＰアドレスとＭＡＣアドレスを対応付けることが可能となる。
宛先ＩＰアドレスが変更された場合でもソフトウェアで柔軟に優先パケットが必要とするヘッダ情報を取得し、優先パケット自身はハードウェアで高速に生成することによりデータ伝送のリアルタイム性を保証可能となる。
また、本発明は、ＡＲＰだけでなく、使用するＵＤＰのポート番号の交渉等、ソフトウェアとプロセッサ（ＣＰＵ）の組み合わせにより、送信先と通信を行って通信に必要なパラメータを相互に決定し、その値を優先パケットに反映させる場合の全てにおいて効果を有することは言うまでもない。
《実施例３》
実施例３の伝送装置及び伝送方法を説明する。実施例３においては、受信系を説明する。
実施例３の伝送装置は、図１において受信フレーム処理部１００４、受信パケット選別部１００５、非優先パケット処理部１００１を有する。
受信フレーム処理部１００４は図２の物理層処理部２０３から優先パケットと非優先パケットが混在した受信フレーム１３０を受信して、自身が受信すべき有効なイーサネットフレームのみの受信処理を行って、受信フレーム１１０７として出力する。
受信パケット選別部１００５は受信フレーム１１０７を入力し、優先パケット１１０８と非優先パケット１１０３に選別する。受信パケット選別部１００５におけるパケット選別の方法を以下に説明する。
本実施例では優先パケットの転送においてＵＤＰ／ＩＰが用いられている。図３に示した第２層のイーサネットヘッダの先頭から、ＩＰヘッダおよびＵＤＰヘッダの位置が確定する。したがって、これらのヘッダの情報を検査し、優先パケットと非優先パケットの選別を行う。
つまり、受信パケット選別部１００５は第２層のイーサネットレイヤ（プロトコルレイヤ１）のパケットの受信を行うが、優先パケットと非優先パケットの選別には第４層のＵＤＰレイヤ（プロトコルレイヤ２）の検査まで行う。
図８にイーサネットヘッダ（８２００）とＩＰヘッダ（８２０１）を図示している。
イーサネットヘッダ８２００中のフレームタイプ８１０２がＩＰプロトコルを示す０ｘ８０００（０ｘは１６進を表す）であれば、優先パケットと判定される。ＩＰヘッダ８２０１において、プロトコル番号８００８は優先パケットの使用プロトコルであるＵＤＰを示す１７、送り元ＩＰアドレスはあらかじめ決定されている送り元のＩＰアドレスを示さなければならない。また、ＵＤＰヘッダ８２０２の送り元ポート番号８０１２および宛先ポート番号８０１３があらかじめ決定されている番号でなければならない。ＵＤＰ以外のプロトコルを使用したパケットは必然的に非優先パケットとして処理されることは言うまでもない。なお、上記のあらかじめ送受信端末間で交渉されている値は、通信に先立ち、アプリケーション１００７で非優先パケット処理部１００１を用いて双方で（実施例の伝送装置及び通信相手の装置）交渉を行い決定し、受信パケット選別部１００５に設定してもよい。
優先パケットと判定されたパケットは優先パケット出力１１０８として出力される。この時、受信パケット選別部１００５ではＵＤＰ（第４層）、ＩＰ（第３層）およびイーサネット（第２層）処理の終端が行われ、ヘッダを外して優先データのみが転送されるので、上位のビデオ等のアプリケーションに処理の負担がかかることはない。
なお、上記の検査は一例であり、必要に応じて検査を増やしたり、省略してもよい。
上記検査で優先パケットと判定されたパケット以外は全て非優先パケット処理部１００１に転送される。この時、受信パケット選別部１００５ではＵＤＰ（第４層）、ＩＰ（第３層）およびイーサネット（第２層）処理の終端が行われることなく、受信したパケット（第２層のイーサネットフレーム）をそのまま非優先パケット処理部１００１に転送する。非優先パケット処理部１００１ではプロセッサを用いたソフトウェア処理により、非優先パケットのフラグメント再構成、ＵＤＰ／ＩＰ、ＴＣＰ／ＩＰ、さらには上位アプリケーション１００７の処理が行われる。
以上のように実施例３においては、受信パケット選別部１００５がイーサネットフレームレイヤ（第２層）でＩＰ（第３層）およびＵＤＰ（第４層）のヘッダを検査する。これにより、受信パケット選別部１００５が優先パケットと非優先パケットを選別する。選別された優先パケット及び非優先パケットは、それぞれ独立に（別個のブロックで）処理される。優先パケットは専用のハードウェアにより処理されるので、パケットの廃棄が発生せず高画質でリアルタイム性が保証される。なおこの時、図１及び２の１１０８に示すように優先パケットの転送に共有バスではなく専用バスを使用した場合は、優先パケット以外のパケットの転送の影響を受けないので、さらに本願発明の効果は大きくなる。ただし、専用バスを使用しない場合（共用バスのみ使用する場合）でも本願発明の効果を得ることができる。したがって共用バスのみ使用する構成を、本願発明の範囲から排除するものではない。
本実施例ではＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）を例として説明を行った。ＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）の場合はコネクション毎に、通信に使用するパケットにフローラベルがつけられるので、受信パケット選別部１００５でフローラベルを検査して優先パケットと非優先パケットを選別してもよい。
なお、本実施例ではビデオ等のリアルタイム伝送のパケットを優先パケットの例としたが、リアルタイム伝送ではなく、特定のデータを大量かつ優先的に伝送して受信する場合にも本願発明が有効であることは明らかである。このような場合を本願発明の範囲から排除するものではない。
優先パケットと非優先パケットを選別するフィルタ条件は、あらかじめ決定しておいても良い。あるいは、通信に先立ち送信端末と交渉して決定するアプリケーションソフトウエアにより決定しても良い。
また、本実施例では、優先パケットにＵＤＰ／ＩＰ、その下のレイヤにイーサネットを使用した。本発明は、これに限らず、優先パケットと非優先パケットが判別可能な他の任意のプロトコルを使用する伝送装置及び伝送方法に適用可能である。このような伝送装置及び伝送方法を本願発明の範囲から排除するものではない。
また、本実施例では、ハードウェアにより優先パケットと非優先パケットを分離して、優先パケットの分離後の処理をハードウェアにより非優先パケットとは独立して（別個のブロックで）行った。これにより、ネットワークで揺らぎが発生して受信端末で受信パケットがバースト的に到達した場合でも、受信端末でのパケット取りこぼしによるパケット廃棄が絶対に発生しない最高品質の通信を実現する例を示した。本発明はこれに限られない。プロセッサとソフトウェアにより、優先パケットと非優先パケットとを分離し、優先パケットの分離後の処理を非優先パケットとは独立して実行する他の実施例の伝送方法を以下に説明する。
従来技術では、ネットワーク処理を階層別に行っていたためプロセッサ（ＣＰＵ）の処理負担が大きかった。
他の実施例においては、優先パケットの選別（フィルタ）条件をあらかじめソフトウェアで設定しており、ソフトウェアでＩＰパケットヘッダおよびＵＤＰパケットヘッダの解析を同時に行い、優先パケットを判別する。受信パケットに対して階層別に優先パケットであるかどうかの解析を行わない。優先パケットと判定されたパケットは終端処理を行って優先データ専用の処理部に転送し、以降の処理を行う。なお、非優先パケットの処理は一般のオペレーティングシステムに実装されている階層別の処理により行われる。
この方法では、優先パケットの処理および非優先パケットのソフトウェア処理をスレッドを分けることにより論理的に分離し、優先パケットの処理の優先度を非優先パケットの優先度に対して高くする。
なお、この方法は図１において、受信パケット選別部１００５が担う処理を、プロセッサで実行することで実現可能である。
この方法によれば、受信パケット選別部１００５が担う処理をハードウェアで実行する方法よりは優先データの処理の優先度が弱いものの、従来技術にはない本願発明の効果を有することは言うまでもない。、したがってこのような構成を本願発明の範囲から排除するものではない。
《実施例４》
実施例４の伝送装置及び伝送方法を説明する。実施例４においては、受信系を説明する。本願発明はＩＰパケットの分割処理であるフラグメントと再構成処理であるデフラグメントに関する。まずフラグメントとデフラグメントの概要について説明する。
図７はフラグメントの模式図である。まず図７を用いてフラグメントの概要を説明する。図７において７０００はフラグメントされる前のパケットであり、７００１、７００２および７００３はフラグメントされたパケットである。受信端末では受信された各パケットのＩＰヘッダに格納されている情報を元にフラグメントを再構成する（デフラグメント）。
図８のＩＰヘッダ８２０１において、８０００は４ビットのバージョン情報、８００１は４ビットのヘッダ長、８００２はタイプオブサービス（ＴＯＳ）、８００３はＩＰパケットのトータル長、８００４は識別番号、８００５は３ビットのフラグメントに関するフラグ、８００６は１３ビットのフラグメントオフセット、８００７はＴｉｍｅ ｔｏ Ｌｉｖｅ（ＴＴＬ）、８００８はプロトコル番号、８００９はヘッダチェックサム、８０１０は送り元ＩＰアドレス、８０１１は宛先ＩＰアドレスである。図８に示したＩＰヘッダ部分の詳細は規格書や各種の書籍に詳しく説明されているので、以下実施例４に関する部分のみ説明する。
フラグメントを再構成するために必要な情報は、識別番号８００４、フラグ８００５およびフラグメントオフセット８００６である。
フラグ８００５はフラグメントの許可、不許可を示す１ビット（図７中にはＤで表示し、０がフラグメント許可、１が不許可）、最後のフラグメントパケットであるか途中のフラグメントパケットであるかを示す１ビット（図７中にはＭで示し、０が最後のフラグメントパケット、１は最後ではない）、およびその他の１ビットで構成されている。フラグメントは４バイト単位で行われ、そのオフセットをフラグメントオフセット８００６で４バイト単位で示す。
図７の例では、ＵＤＰヘッダとＵＤＰペイロードで構成される合計１２０８バイトが、７００１のＵＤＰヘッダとＵＤＰペイロード０の５１２バイト、７００２のＵＤＰペイロード１の５１２バイト、および７００３のＵＤＰペイロード３の４９２バイトにフラグメントされる。
７００１、７００２および７００３は、７０００からフラグメントされたＩＰパケットであるので、それらの識別番号８００４は７０００のＩＤと同一のＩＤ（図７では１２３４を例示）である。さらに７０００のフラグメントが許可されているのでそれらのフラグメント許可ビットＤは０である。フラグメント途中であるかどうかを示すＭは７００３のみが最終を示す０、７００１および７００２は１である。フラグメントオフセットは各ＩＰパケットに応じてＩＰヘッダ中に格納されている。
以上説明したようにフラグメントされたパケット７００１、７００２および７００３にはデフラグメントに必要な情報が全てＩＰヘッダ中に格納されているので受信端末でデフラグメントを行うことが可能となる。
なお、ＩＰパケットの順序性はネットワークでは保証されておらず、フラグメントされたパケットが順序通り受信されるとは限らない。具体的には図７において７００１、７００２、７００３の順に受信されることは保証されておらず、例えば７００３、７００１、７００２の順に受信される可能性もある。
一般的にはデフラグメント処理は、一旦コンピュータのメインメモリに受信された全てのＩＰパケットを格納し、汎用オペレーティングシステムに実装されているデフラグメント用のソフトウェアを用いて再構成される。しかしながら上記の方法では優先パケットと非優先パケットが混在して格納され、さらに非優先パケットのデフラグメント処理が優先パケットの処理を妨げる場合があるので、優先パケットの処理を優先させリアルタイム性を保証できない。
実施例４の伝送装置は、優先パケットのデフラグメント処理のための専用処理部であるデフラグメント処理部１００６を有する。これにより、非優先パケットのデフラグメント処理により優先パケットの処理が妨げられない。
実施例４の伝送装置は、図１において受信フレーム処理部１００４、受信パケット選別部１００５、デフラグメント処理部１００６および非優先パケット処理部１００１を有する。
受信フレーム処理部１００４は、図２の物理層処理部２０３から優先パケットと非優先パケットが混在した受信フレーム１３０を受信して、自身が受信すべき有効なイーサネットフレームのみの受信処理を行い、受信フレーム１１０７として受信パケット選別部１００５に出力する。
受信パケット選別部１００５は受信ＩＰパケット（受信フレーム１１０７）がフラグメントされていなければ、実施例３に説明した方法で、受信パケットが優先パケットか非優先パケットであるかを判定して、優先パケット１１０８または非優先パケット１１０３として出力する。
受信ＩＰパケットがフラグメントされている場合は、プロトコル番号８００８で使用されているプロトコルを判定する。使用プロトコルがＵＤＰ以外であれば非優先パケットであると判定し、非優先パケット処理部１００１に転送する。
使用プロトコルがＵＤＰである場合は、次に受信パケットがフラグメントされたパケットの先頭パケットであるか否かを判定する。受信フラグメントパケットが先頭パケットであればそのフラグメントオフセットは０である。又、受信フラグメントパケットが先頭パケットであれば、そのペイロードの先頭に必ずＵＤＰヘッダがあるので、受信フラグメントパケットが優先パケットであるか非優先パケットであるかを判定できる。
受信フラグメントパケットが優先パケットの先頭パケットであると判断された場合は、当該パケットをデフラグメント処理部１００６に転送する。一方受信フラグメントパケットが非優先パケットであると判定された場合は非優先パケット処理部１００１に転送する。この時受信パケット選別部１００５は各受信パケットの個別のＩＤとその受信パケットが優先パケットであったが非優先パケットであったかの情報とを受信パケット選別部１００５のメモリに記憶し（以下、「判定ＩＤ」と呼ぶ。）、後から受信される残りのフラグメントパケットが優先パケットであるか非優先パケットであるかの判定情報とする。
一方、受信フラグメントパケットが先頭パケットでない場合は、受信フラグメントパケットのＩＤ８００４を検索する。ＩＤ８００４中に情報があれば優先パケットであるか非優先パケットであるかが判定可能であり、デフラグメント処理部１００６に転送するか非優先パケット処理部１００１に転送するかが決定される。ＩＤ８００４に情報がない場合は、一旦デフラグメント処理部１００６に転送され、そのＩＤの先頭パケットの到着を待つ。そのＩＤの先頭パケットが到着し、受信パケット選別部１００５で優先パケットであると判定された場合は、デフラグメント処理部１００６で先頭パケット及び先に受信した受信パケットを含めて引き続きデフラグメント処理を行う。そのＩＤの先頭パケットが非優先パケットであると判定された場合は、受信パケットが非優先パケット処理部１００１に転送される。その判定情報が受信パケット選別部１００５からデフラグメント処理部１００６に通知される。デフラグメント処理部１００６は、それまでに格納されているそのＩＤの全ての非優先パケットを、受信パケット選別部１００５を介して、非優先パケット処理部１００１に転送する。この時、そのＩＤが非優先パケットであることは受信パケット選別部１００５に記憶される。それ故に、その後そのＩＤの残りのフラグメントパケットが受信された場合、それらの受信パケットは直接非優先パケット処理部１００１に転送される。なお、デフラグメント処理部１００６が、非優先パケットを直接非優先パケット処理部１００１に転送する手段を具備してもよい。
デフラグメント処理部１００６は優先パケットのデフラグメント処理を行う。各パケットのデフラグメント処理が完了すると、デフラグメント処理されたパケットは受信パケット選別部を介して優先パケット１１０８として転送される。この時受信パケット選別部１００５に記憶されている優先パケット判定用ＩＤのリストから当該ＩＤは削除される。
なお、デフラグメントが完了したパケットを受信パケット選別部１００５を介さずに直接優先パケットとして出力し、優先パケット判定用ＩＤのリストから当該ＩＤを削除する要求のみ受信パケット選別部１００５に通知してもよい。
非優先パケット処理部１００１では非優先パケットのデフラグメント処理を行う。この処理は汎用プロセッサと汎用オペレーティングシステムに実装されているデフラグメント処理ソフトウェアで行う。
タイマを設けて、受信パケット選別部１００５で保持される判定用ＩＤを一定時間後に自動的に削除するようにしても良い。これによりテーブルに要するメモリ量を削減することができる。
ネットワーク途中でのパケットの廃棄によりフラグメントされたパケットの全部あるいは一部が受信されず、デフラグメントが完了しない場合がある。タイマを設けて、デフラグメント処理部１００６に格納される個々のＩＰパケットは格納後一定時間が経過すると削除されるようにしても良い。なお、タイマはカウンタで簡易に構成可能である。
デフラグメント処理部の具体的な構成は、ＩＥＦＴ ＲＦＣ ８１５に開示されている。さらにソースコードが公開されているオペレーティングシステムにもその構成が開示されているので、当業者が容易にデフラグメント処理部を実現できる。
本実施例ではＵＤＰのパケットを優先パケットとした。別のプロトコルを使用するパケットを優先パケットとする構成も本願発明の範囲から排除するものではない。特有のプロトコルを使用するパケットのみを優先パケットとし、それ以外のプロトコルを使用するパケットを非優先パケットとする伝送装置においては、フラグメントされた全てのＩＰパケットに含まれるプロトコル番号８００８で受信パケットが優先パケットか非優先パケットかを判定できる。このような装置においては、優先パケット／非優先パケットの判定が容易となる。
ＵＤＰのパケットを優先パケットとし、それ以外のプロトコルのパケットを非優先パケットとする伝送装置及び伝送方法において、フラグメントされた全てのＩＰパケットに含まれるプロトコル番号８００８で受信パケットが優先パケットか非優先パケットかを判定できる。このような装置においては、優先パケット／非優先パケットの判定が容易となる。
また、優先パケットおよび非優先パケット共にＵＤＰを使用する場合でも、非優先パケットが必ず短いパケットであれば、フラグメントされる確率は非常に低い、あるいはフラグメントされないので受信パケット選別部１００５での判定は効率的となる。
なお、受信側で優先パケットのデフラグメント処理を行いたくない場合は、送信側において、あらかじめアプリケーションレベルの処理で、通信網においてフラグメントされない最大サイズ（ＭＴＵ）を検査し、それ以下のパケットサイズでパケットを伝送する。あるいは、ＲＦＣの規格では全ての端末は５７６バイトのサイズのＩＰパケットを扱えなければならないと規定されているので、ルータ等の多くのネットワーク機器はこれ以下のＩＰパケットを受信した場合はフラグメントしない。したがってＩＰパケットのサイズが５７６バイト以下となるように優先パケットを構成するようにすればよい。上記のように優先パケットにフラグメントが起こらない伝送システムにおいては、受信したパケットがフラグメントされていれば全て非優先パケットとして処理すればよい。なお、イーサネットのＩＰパケットの許容最大値を越えたパケットは送信端末でフラグメントしなければ送信できない。優先パケットのフラグメントを起こさせないためには、全ての送信パケットがＩＰパケットの許容最大値以下でなければならないことは言うまでもない。
また、通信網においてフラグメントが起こる確率が非常に低い場合は、送信側で優先パケットのＩＰパケットのＩＰヘッダにフラグメント禁止のフラグを立てて伝送することにより、途中でフラグメントされることを防止できる。ルータが受信パケットをフラグメントせざるを得ない状態ではＩＰパケットを廃棄させる。これにより、受信端末でのデフラグメント処理負荷を軽減できる。この場合、小数の優先パケットは損失となるが、受信側で誤り訂正あるいは誤り修整を行うことで通信品質を補償すればよい。
以上のように実施例４の伝送装置は、デフラグメントを行う処理部を優先パケット用と非優先パケット用に別個独立に複数個備えている。実施例４においては、フラグメントされたパケットが優先パケットであるか非優先パケットであるかを判定して、どちらのデフラグメント処理部で行うかを決定する。これにより、非優先パケットのデフラグメント処理により優先パケットの処理が妨げられることを防止できる。優先データのリアルタイム性の保証が可能となり、映像・音声等の高品質な伝送が可能となる。
《実施例５》
実施例５の伝送装置及び伝送方法を説明する。実施例５においては、送信系及び受信系を説明する。
実施例５の伝送装置は、図１において優先パケット生成部１０００、送信パケット制御部１００２、送信フレーム処理部１００３および受信フレーム処理部１００４を有する。
実施例５では、優先データに誤り訂正用のパリティを付加して、それらのデータを優先パケットとして伝送する場合において、ネットワークの混雑等により優先パケットの送信が一時停止された場合、あるいは優先パケットの送信が不成功となり、当該パケットを再送することにより優先パケットの送信スケジュールが遅延した場合に、誤り訂正用パケットの全部あるいは一部を送信しないことにより、優先データで構成される優先パケットの送信を保証する。
図９は誤り訂正マトリックスとそれから形成された優先パケットの模式図である。誤り訂正マトリックス９０００は行方向にデータを格納し、列方向に誤り訂正用パリティを計算してマトリックスを構成する。９００１に示すように誤り訂正マトリックスの各行が優先パケットのペイロードを構成する。伝送装置は、各行にＵＤＰ／ＩＰおよびイーサネットのヘッダを付加して伝送する。図９においては、優先データを格納する部分を白抜きで示し、誤り訂正用パリティを格納する部分をハッチングで示している。また、図９の例では列方向５０バイトのデータに対して４バイトのパリティをつける例を示している。しかし本発明の技術的範囲はこれに限定されるものではない。このような誤り訂正方式に関しては多数の従来技術が知られており、当業者はそれらを容易に理解することが可能である。この誤り訂正の処理は優先パケット生成部１０００で行われる。
図１０は実施例５のパケットの概念的な構成図である。図１０では優先データで構成されるパケットをＤ（以下、「優先データパケット」と呼ぶ。）、誤り訂正用パリティで構成されるパケットをＰ（以下、「誤り訂正パケット」と呼ぶ。）で示す。それらの記号の直後にマトリックス番号、その直後のハイフン（−）の後に、優先データおよび誤り訂正用パリティのそれぞれのパケットのマトリックス内での番号を示している。例えば、優先データのマトリックス番号０の６番目のパケットはＤ０−５（パケット番号は０から始まることに注意）で示す。
１９００は通常状態の伝送を示す。まず、優先データパケットがＤ０−０からＤ０−４９まで５０個送信される。それに続いて誤り訂正パケットがＰ０−０からＰ０−３まで４個送信される（１９０１）。
イーサネットでは、全二重で通信する場合、送信端末が多数のパケットを一度に送信し、送信端末が接続されているルータのバッファがオーバフローを発生する可能性がある時、ルータから送信端末に対して送信の一時停止を要求する信号（以下、「ＰＡＵＳＥ信号」と呼ぶ。）が送られる。このＰＡＵＳＥ信号は実際にはイーサネットフレームで構成され、そのイーサネットフレームの中には一時停止をどれだけの時間要求するかという情報が格納されている。この手順についてはＩＥＥＥ８０２．３に規定されている。
ＰＡＵＳＥ信号は受信フレーム処理部１００４で受信され、ルータから要求された送信一時停止時間が１１０６の経路で送信フレーム処理部１００３に通知される。送信フレーム処理部１００３は自身のバッファ内のパケットの送信を停止すると共に、経路１１０５で送信パケット制御部１００２に対して、送信停止中であることを通知して新規のパケットの転送を一時停止する。
また、半二重通信を行う場合は、各端末からの送信パケットの衝突（コリジョン）が検出されると、当該パケットは正常に送信されないので、再送しなければならない。コリジョンは受信フレーム処理部１００４で検出され、送信フレーム処理部１００３に通知された後に、送信パケット制御部１００２に通知される。そしてランダムに送信停止時間が決定される。その後コリジョンにより送信が不成功となったパケットを再送する。この手順についてはＩＥＥＥ８０２．３に規定されている。
１９１０において、１９１１がＰＡＵＳＥ信号による送信停止期間（以下、「ＰＡＵＳＥ期間」と呼ぶ。）である。ＰＡＵＳＥ期間に送信すべきであったＤ０−２およびＤ０−３はＰＡＵＳＥ期間終了後に送信される。したがって、優先データパケットの送信は通常より遅れて１９１３で終了する。その後誤り訂正パケットが送信される。この時、次のマトリックスのパケット送信開始時間（１９１４）までの期間（１９１５）が短いので、誤り訂正パケットを間引いて送信することで（１９１０ではＰ０−２、Ｐ０−３の送信を行わない。）、次のマトリックスの送信スケジュールに影響を与えないようにする。
１９２０において、１９２１および１９２２は半二重通信におけるコリジョンにより、パケットの送信が失敗に終わったことを示している。それぞれのコリジョンの直後に当該パケットは再送される。つまり１９２１で送信しようとしたＤ０−２、１９２２で送信しようとしたＤ０−３は、コリジョン検出後再送される。この再送により、ＰＡＵＳＥ信号による送信停止と同じように優先データパケットの送信は遅れて１９２４で終了する。１９２４の終了タイミングから次のマトリックスの送信開始時間１９２５までの時間が短いので期間１９２６では誤り訂正パケット間引いて送信することで（１９１０ではＰ０−２、Ｐ０−３の送信を行わない）、次のマトリックスの送信スケジュールに影響を与えないようにする。
実施例５の送信パケット制御部１００２は、送信したパケット個数をカウントするカウンタと時間を管理するタイマとを備えている。タイマはカウンタで容易に実現可能である。これを用いて、送信パケット制御部１００２はＰＡＵＳＥ信号およびコリジョンによる送信の遅れを検出する。送信スケジュールに遅れが生じた場合は、送信パケット制御部１００２は当該マトリックスに割り当てられた期間内の残された時間で送信可能な誤り訂正パケット数を計算して、経路１１０９で優先パケット生成部１０００に通知する。優先パケット生成部１０００は、送信する誤り訂正パケットを間引くことにより通知された個数の誤り訂正パケットのみを転送する。
一方、受信端末では送信された優先データパケットがパケット廃棄やビットエラーがなく正常に受信された場合は、全く問題なく高品質な優先データが通信完了となる。また、パケット廃棄やビットエラーが発生した場合でも、送信端末で間引かれて送信されなかった誤り訂正パケット数と、ネットワークで廃棄されたパケット廃棄数またはビットエラーパケット数との合計が、当該マトリックスでの誤り訂正能力（図９の例の場合は合計４パケット）を越えなければ、受信されたパケットにより消失訂正可能となるので、完全に優先データを再現可能である。
以上、本発明によれば、ＰＡＵＳＥ信号やコリジョンにより送信パケットの送信スケジュールが遅れた場合でも、優先データパケットの送信をとりやめることなく、送信スケジュールを正常に回復することが可能である。しかも受信端末である程度の誤り訂正を実行可能であるので、高品質なデータ通信が可能となるという効果を有する。
なお、本実施例では、マトリックスの処理に要する時間を基準に、誤り訂正パケットの送信を間引く個数を決定したが、これに限らず例えばビデオフレーム期間としてもよい。つまり、所定時間内に送信すべき優先パケットの送信スケジュールに遅れが生じた場合に、優先データパケットの送信をとりやめるのではなく誤り訂正パケットの送信を間引く。これにより上記の実施例と同様の効果が得られる。前記の所定期間は任意に設定可能であり、特定の時間単位に限定されるものではない。
図１０においては、各パケットの送信間隔（パケット送信の空き時間）がほとんどない場合を図示した。送信間隔が十分にある場合、送信スケジュールが遅れた時、パケットの送信間隔を短くすることにより、送信スケジュールの回復が可能である。しかし、ＰＡＵＳＥ期間が長い場合又はコリジョンが多発する場合は、送信スケジュールが遅れる場合が発生する。そのような場合、最終的に図１０に示した状態と同じになるので、本発明を適用でき、実施例５と同様の効果が得られる。送信間隔に余裕がある場合も、本願発明の範囲から排除するものではない。
また、非優先パケットの送信により送信スケジュールが遅れた場合にも本願発明が有効である。したがってそのような場合も本願発明の範囲から排除するものではないことはいうまでもない。
《実施例６》
実施例６の伝送装置及び伝送方法を説明する。実施例６においては、受信系を説明する。
実施例６の伝送装置は、図１において受信フレーム処理部１００４、受信パケット選別部１００５、デフラグメント処理部１００６を使用する。さらに実施例６では図１におけるビデオ信号処理部２０２中に優先データ処理監視部１００８を具備する。
実施例６の伝送装置の特徴は、デフラグメント処理中のパケットの内、既にアプリケーションで処理が終了し、それ以上デフラグメントを行っても使用する意味がないパケットのデフラグメント処理を途中で中止して廃棄することである。
本実施例では実施例５の図９で説明した誤り訂正マトリックスをアプリケーションの処理単位とする。しかし、処理単位はこの限りではない。
図９の９００１の優先パケットは図８に示すＵＤＰ／ＩＰ、イーサネットのヘッダを付加されたイーサネットフレームの状態で受信される。伝送装置（受信装置）はイーサネットフレームのＩＰパケットヘッダ８２０１（図８）を利用する。一般的に、送信側ではＩＤ８００４の値を連続的に付与して送信する。
一例として、ある誤り訂正マトリックスを構成するイーサネットフレームのＩＤ８００４が、１０００、１００１、１００２・・・１０５２、１０５３であるとする。
通常状態でのデフラグメントの処理は実施例４で説明した方法と同じである。
受信されたイーサネットフレームは受信フレーム処理部１００４で受信処理され、受信パケット選別部１００５に転送される。優先パケットがフラグメントされている場合は、受信パケット選別部１００５からデフラグメント処理部１００６に転送されてデフラグメント処理され、優先パケット９００１の状態に戻されて、優先データ出力１１０８としてビデオ信号処理部２０２に出力される。この時、本実施例では当該パケットに付与されていたＩＤ８００４が同時にビデオ信号処理部２０２に転送される。
図９に示した９０００の誤り訂正マトリックスの処理は、図２のビデオ信号処理部２０２で行われる。優先データ処理監視部１００８が、ビデオ信号処理部２０２で現在処理されている誤り訂正マトリックスのＩＤ８００４を監視する。
ビデオ信号処理部２０２が誤り訂正処理を終了した時、優先データ処理監視部１００８はその誤り訂正マトリックスを構成するパケットの内、最終パケット（９００２）のＩＤ８００４（以下、「最終ＩＤ」と呼ぶ。）を把握している。なお、もし最終パケットが廃棄された場合でも誤り訂正マトリックスを構成するパケット個数はあらかじめ決められているので、優先データ処理監視部１００８は最終パケットのＩＤ８００４を演算して求めることができる。
誤り訂正処理が終了すると、それ以降にデフラグメント処理が完了した当該誤り訂正マトリックスを構成するパケットは不要になる。そこで、ビデオ信号処理部２０２が誤り訂正処理を終了した時、デフラグメント処理部１００６は当該マトリックスに属する優先パケットのデフラグメント処理を終了する。デフラグメント処理を終了しても、ビデオ等のアプリケーションは動作上全く問題ない。デフラグメント処理部１００６が確保しているデフラグメント用メモリを開放できるので資源の有効活用となる。
同様に、受信パケット選別部１００５は、誤り訂正処理を終了した後に遅延して到着した当該誤り訂正処理マトリックスに属するパケットを、無用である故に廃棄する。
具体的な処理を説明する。優先データ処理監視部１００８は、最終ＩＤを優先データ処理完了通知１１１０として受信パケット選別部１００５に通知する。受信パケット選別部１００５はデフラグメント処理部１００６に、当該マトリックスに属するパケットを廃棄するように指示する。それと同時に、受信パケット選別部１００５は、最終ＩＤを記憶し、新規に受信された受信パケット１１０７のＩＤ８００４を検査し、受信パケット１１０７が既に誤り訂正処理が終了した誤り訂正マトリックスに属すると判断した場合は当該パケットを廃棄する。この結果、遅延して到着した優先パケットの無駄なデフラグメント処理及びデフラグメント以降の処理は行われない。
以上、説明したように本発明では、既に処理が終了したパケット群に属するパケット（本実施例では誤り訂正処理）のデフラグメント処理を中止して廃棄すると共に、遅延して受信されたそのパケット群に属するパケットを廃棄する。これにより、デフラグメント処理を効率的に行い、デフラグメント処理に要するメモリ等の資源を削減することが可能で、かつ消費電力が少ない安価で簡易な装置を実現できる。
なお、遅延パケット廃棄時にデフラグメントが発生していないパケットも同様に廃棄すればさらに効果は増大する。
なお、ＩＰパケットヘッダのＩＤは１６ビットで構成される。１６ビットが一周するのに要する時間（０から０ｘＦＦＦＦまで順次インクリメントし、オーバーフローして再び０に戻るまでの時間）はアプリケーションにとってはかなり長い時間であり、処理終了の時間基準として使用するのに十分である。
ひとつのマトリックスを構成するパケットの間に非優先パケットが転送された場合はＩＤをひとつ消費する。しかし、非優先パケットの割合は優先パケットに対して少数である。非優先パケットが誤り訂正マトリックスを構成する最後の優先パケットの直前に伝送され、かつ最後の優先パケットが誤り訂正処理に間に合わなかった場合のみ、処理が終了した誤り訂正マトリックスの最後のＩＤにずれが生じる。しかし、実質的にはこの発生確率は非常に小さい。この場合、影響を受けるのは誤り訂正マトリックスを構成する最後のパケットのみであるので実質的に影響はない。
また、本実施例ではアプリケーションの処理進行状況を把握する情報としてＩＰパケットのＩＤを使用した。しかしこれに限られるものではない。例えば、別のプロトコルの識別子を利用してもよい。また、アプリケーションが独自の識別子を付与しても良い。これらの方法によっても本発明を実施可能である。これらの方法を本発明の範囲から排除するものではない。
以上説明したように本発明を実施できる。
実施例１から６では、通信網プロトコルとしてイーサネットを例としたがこの限りではない。例えば衛星放送、地上波ディジタル放送等の放送電波あるいはＩＥＥＥ８０２．１１等の無線ＬＡＮ等でＩＰプロトコルを用いる場合等も本発明の範囲に含まれる。
実施例１から６では優先パケットは１種類であった。しかしこれに限られず、本発明は優先パケットが複数ある場合を含む。
実施例１及び３で説明したプロセッサによって処理する方法は、その他の発明でも実現可能であることは言うまでもない。
実施例の図１において、優先パケット生成部１０００での優先パケットの生成処理、及び受信パケット選別部１００５での受信パケットの分離処理は、プロトコル処理が階層別ではなく、同時に行われることは言うまでもない。
実施例において、ビデオ信号処理の例として、画像圧縮および伸張が行われるとした。しかしこれに限定されるものではなく、本発明は圧縮又は伸長を行わない伝送装置等を含む。また、あらかじめＭＰＥＧ等の方式で画像圧縮されたデータが入力される場合も本願発明の範囲に含まれる。
ビデオではなく、オーディオ等のリアルタイムデータあるいは優先的に送受信を行うものであればどのようなものでも本発明の技術的範囲に含まれる。大量のデータを優先的に送受信する場合に本願発明は特に有効である。
実施例１から５ではＣＢＲのビデオ信号を例とした。しかし、優先データはＣＢＲに限るものではない。
実施例においてはイーサネットを例とした。イーサネット以外の通信を使用する場合は、図１において、送信フレーム処理部１００３及び受信フレーム処理部１００４は不要であるか、又は他の送信処理部及び受信処理部に置き換えられる。
本願発明においては、優先パケットはハードウェア処理、非優先パケットはＣＰＵ処理とすれば最も大きな効果が得られる。しかしこれに限られるものではなく、優先パケットの処理スピードが間に合うのであれば、専用プロセッサ等で構成してもよい。
本願発明の受信側の処理において、優先パケットの長さがあらかじめわかっている場合は優先パケット／非優先パケットの判定基準にパケットの長さ情報を用いてもよい。例えばデフラグメント処理において、受信パケットが優先パケットの長さを越えると判断される場合は、非優先パケットと判定してもよい。
実施例１に示した本願発明によれば、クロック単位で優先パケットと非優先パケットの送信の制御が可能である。これにより、リアルタイム通信を保証して高品質な伝送を保証すると共に、非優先パケットの伝送品質も保証することが可能であり、システムの安定的な運用が可能となる。
ビデオ信号等のリアルタイム性を必要とするデータのプロトコル処理をＣＰＵに頼らずハードウェア処理を行うので処理が間に合わないことは発生しない。全てのパケットが完全に送信され、アルタイム性の保証された高品質の伝送が保証される。
優先パケットと非優先パケットの送信タイミング（送信割合）をソフトウェアではなくハードウェアで制御するので、クロック単位で完全に制御可能である。優先パケットが全て完全に送信され、リアルタイム性の保証された高品質の伝送が可能となる。また、シェイピングもハードウェア処理によりクロック単位で正確に行われるため、初段のルータでのパケット廃棄の発生確率が非常に少ない高品質な通信が可能となる。
転送割合と転送タイミングをクロック単位で柔軟に調整可能である故に時間帯域を有効に活用可能である。その結果として様々なアプリケーションに対応した低遅延の伝送が可能となり、ビデオ・音声等の低遅延しか許容しないアプリケーションの高品質な伝送が可能となる。特に音声は遅延に敏感なので大きな効果を有する。
リアルタイム伝送だけではなく、大量のデータを優先的に伝送する場合にも伝送品質が保証された信頼性の高い伝送が可能となる。
実施例２に示した本願発明によれば、上記の効果を有すると共に、優先パケットの生成に必要なヘッダ情報をプロセッサにより柔軟に取得し、取得したパラメータを優先パケットの処理側に設定する。これにより、多数の地点との通信を柔軟に行うことが可能となる。
実施例３に示した本願発明によれば、受信フレームを構成するプロトコルレイヤ（プロトコルレイヤ１）の処理において、プロトコルレイヤ１よりも上位のプロトコルレイヤ（プロトコルレイヤ２）の検査を行うことで優先パケットと非優先パケットを判定する。優先パケットは前記プロトコルレイヤ２の終端を行い、非優先パケットは前記プロトコルレイヤ１のまま前記非優先パケット処理部に転送する。優先パケットは専用処理を行うことにより受信パケットの廃棄が発生せず、かつ高速処理によりリアルタイム性の保証が可能となる。また大量のデータ伝送時にもパケット廃棄がなく高品質な伝送が可能となる。また非優先パケットもプロセッサにより優先パケットとは独立に処理されるので、伝送品質が保証されシステムの安定運用が可能となる。
実施例４に示した本願発明によれば、伝送装置は優先パケット用と非優先パケット用の複数個のデフラグメント処理部を有する。伝送装置はフラグメントされたパケットが優先パケットであるか非優先パケットであるかを判定して、どちらのデフラグメント処理部で行うかを判定し、それぞれのデフラグメント処理部でデフラグメントする。非優先パケットのデフラグメント処理により優先パケットの処理が妨げられることがない。優先パケットのデフラグメント処理を専用処理部で行うことにより、リアルタイム性の保証が可能となり、映像・音声等の高品質な伝送が可能となる。
一方、非優先パケットも優先パケットとは独立してデフラグメント処理が行われるので高品質な伝送が可能となる。システムの安定運用が可能となる。
実施例５に示した本願発明によれば、ＰＡＵＳＥ信号やコリジョンにより送信パケットの送信スケジュールが遅れた場合でも、優先データパケットの送信をとりやめることなく、送信スケジュールを正常に回復することが可能である。しかも受信端末である程度の誤り訂正を実行可能であるので、高品質なデータ通信が可能となるという効果を有する。
実施例６に示した本願発明によれば、既に処理（実施例では誤り訂正処理）が終了したパケット群に属するパケットのデフラグメント処理を中止して廃棄すると共に、終了後に遅延して受信されたパケットを廃棄する。これにより、デフラグメント処理を効率的に行い、デフラグメント処理に要するメモリ等の資源を削減することが可能で、かつ消費電力も少ない、安価で簡易な装置を実現できる。
本発明（全ての実施例）において、非優先パケットは従来通りＣＰＵを用いてソフトウェア処理を行うので、ソフトウェアの追加・変更によりシステムの変更あるいは管理情報等の伝送に柔軟に対応できる。この結果、送信端末と受信端末間、あるいは専用の制御端末と送受信端末間において、非優先パケットを用いて常に安定して状態監視を行うことが可能である。システムとしての安定性を保証することができる。
非優先パケットの伝送品質も保証されているので、各種パラメータや送受信の開始・停止の設定等も高速に処理される。それ故に、緊急時の変更等も素早く行うことが可能であり、この点でもシステム安定運用が保証されている。
非優先パケットのデータ量は優先パケットのデータ量に比べて非常に少ないので安価なＣＰＵで実現可能となり低コストなシステムとなる。
負荷が高くかつ伝送容量の高い優先パケットのプロトコル処理に高価なＣＰＵおよび大規模メモリを必要としないので、この点からも低コストとなる。
産業上の利用可能性
本発明は、例えば優先度の高いデータ（例えば等時性を必要とする映像データ又は音声データ等）と相対的に優先度が低いデータとを伝送する伝送装置及び伝送方法として有用である。
【図面の簡単な説明】
図１は、本発明の実施例の伝送装置の構成を示すブロック図である。
図２は、本発明の実施例の伝送システム全体ブロック図である。
図３は、本発明の実施例における優先パケットのプロトコルスタックを説明する図である。
図４は、本発明の実施例における非優先パケットのプロトコルスタックを説明する図である。
図５は、本発明の実施例の送信パケット制御部１００２の構成を示すブロック図である。
図６は、本発明の実施例の伝送方法における送信タイミングチャートである。
図７は、本発明の実施例におけるフラグメントの模式図である。
図８は、本発明の実施例におけるＵＤＰ、ＩＰおよびイーサネットプロトコルヘッダの詳細を示す図である。
図９は、本発明の実施例における誤り訂正マトリックスと優先パケットの模式図である。
図１０は、本発明の実施例５を説明するための概念図である。
図１１は、ビデオ信号をイーサネット伝送する従来例の伝送装置の構成を示すブロック図である。

Claims (47)

1. 優先して送信される優先データから優先パケットを生成する優先パケット生成部と、前記優先パケットよりも送信優先度が低い非優先パケットを生成する非優先パケット処理部と、前記優先パケットと前記非優先パケットの送信タイミングを決定する送信パケット制御部と、前記優先パケットと前記非優先パケットの送信処理を行う送信フレーム処理部と、を備え、前記送信パケット制御部は前記優先パケットの送信余裕期間に前記非優先パケットの送信を許可することを特徴とする伝送装置。
2. 前記送信パケット制御部は、送信パケット選択部と、優先パケット用バッファと、非優先パケット用バッファを具備し、前記非優先パケット用バッファが送信すべき前記非優先パケットを保持している場合に、前記送信パケット選択部に非優先パケット送信要求信号を出力し、前記送信パケット選択部は前記優先パケットの送信余裕期間に前記非優先パケットの送信を許可することを特徴とする請求項１に記載の伝送装置。
3. 前記送信パケット制御部は、前記優先データのリアルタイム性を損なわない時間を前記送信余裕期間とすることを特徴とする請求項１又は２に記載の伝送装置。
4. 前記送信パケット制御部は、前記優先パケットの送信間隔を前記優先パケットの平均送信間隔より小さくして送信し、前記処理によって生じた余剰時間を前記送信余裕期間とすることを特徴とする請求項１に記載の伝送装置。
5. 前記送信パケット選択部は、前記優先パケット用バッファに送信すべき前記優先パケットがない場合に、前記非優先パケット用バッファに対して前記非優先パケットを送信することを許可することを特徴とする請求項２に記載の伝送装置。
6. 前記送信パケット選択部は、前記優先パケット用バッファに送信すべき前記優先パケットがなく、かつ前記優先パケットを前記優先パケット用バッファに書き込み中でない場合に、前記非優先パケット用バッファに前記非優先パケットを送信することを許可することを特徴とする請求項２に記載の伝送装置。
7. 前記送信パケット制御部は、非優先パケットの送信要求を受けてから所定時間内に前記非優先パケットの送信を許可することを特徴とする、請求項１に記載の伝送装置。
8. 優先して送信される優先パケットと前記優先パケットよりも送信優先度が低い非優先パケットとを判別し、前記優先パケットの送信余裕期間に前記非優先パケットを送信することを特徴とする伝送方法。
9. 前記優先パケットのリアルタイム性を損なわない時間である送信余裕期間に前記非優先パケットを送信することを特徴とする請求項８に記載の伝送方法。
10. 前記優先パケットの送信間隔を前記優先パケットの平均送信間隔より小さくすることにより生じた余剰時間を前記送信余裕期間とすることを特徴とする請求項８に記載の伝送方法。
11. 送信すべき前記優先パケットがない時間を前記送信余裕期間とすることを特徴とする請求項８に記載の伝送方法。
12. 送信すべき前記優先パケットがなく、かつ送信すべき優先パケットの準備中でない時間を前記送信余裕期間とすることを特徴とする請求項８に記載の伝送方法。
13. 所定時間内に少なくともひとつの非優先パケットの送信を保証することを特徴とする、請求項８に記載の伝送方法。
14. 優先して送信される優先データから優先パケットを生成する優先パケット生成部と、前記優先パケットよりも送信優先度が低い非優先パケットの処理を行う非優先パケット処理部と、前記優先パケットと前記非優先パケットの送信タイミングを決定する送信パケット制御部と、前記優先パケットと前記非優先パケットの送信処理を行う送信フレーム処理部と、ネットワークから受信される受信フレームの受け入れ処理を行う受信フレーム処理部と、受信パケットを選別して前記非優先パケットを前記非優先パケット処理部に転送する受信パケット選別部と、を備え、
    前記非優先パケット処理部は、前記受信パケットから前記優先パケットのヘッダ情報を取得し、前記ヘッダ情報を前記優先パケット生成部に設定することを特徴とする伝送装置。
15. 前記ヘッダ情報は、送信先アドレスに応じて変化する情報である請求項１４に記載の伝送装置。
16. 前記非優先パケット処理部の前記ヘッダ情報取得の処理はＩＰアドレスからＥｔｈｅｒｎｅｔの物理アドレスであるＭＡＣアドレスを求める処理であることを特徴とする請求項１４に記載の伝送装置。
17. 優先して送信される優先パケットの送信ステップと、前記優先パケットよりも送信優先度が低い非優先パケットの送信ステップ及び受信ステップとを有し、
    前記非優先パケットの送信ステップ及び受信ステップにより前記優先パケットのヘッダ情報を取得し、
    前記優先パケットの送信ステップにおいて、前記優先パケットのヘッダ情報を前記優先パケットに設定して送信することを特徴とする伝送方法。
18. 前記ヘッダ情報は、送信先アドレスに応じて変化する情報であることを特徴とする請求項１７に記載の伝送装置。
19. 前記ヘッダ情報取得はＩＰアドレスからＥｔｈｅｒｎｅｔの物理アドレスであるＭＡＣアドレスを求める処理であることを特徴とする請求項１７に記載の伝送装置。
20. 優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットを受信し、受信フレームの受け入れ処理を行う受信フレーム処理部と、
    前記受信フレーム処理部に格納された受信パケットを、前記受信パケットに格納されている通信プロトコルヘッダを検査することにより、前記優先パケットと前記非優先パケットに選別する受信パケット選別部と、
    を有することを特徴とする伝送装置。
21. 前記受信パケット選別部は少なくとも前記受信パケットに格納されている通信プロトコル種別の情報から前記優先パケットと前記非優先パケットを選別することを特徴とする請求項２０に記載の伝送装置。
22. 前記受信パケット選別部は少なくとも前記受信パケットに格納されているポート番号を検査することにより前記優先パケットと前記非優先パケットを選別することを特徴とする請求項２０に記載の伝送装置。
23. 前記受信パケット選別部は少なくとも前記受信パケットに格納されているフローラベルを検査することにより前記優先パケットと前記非優先パケットを選別することを特徴とする請求項２０に記載の伝送装置。
24. 前記受信パケット選別部は前記受信パケットを構成するプロトコルレイヤ（プロトコルレイヤ１）よりも上位のプロトコルレイヤ（プロトコルレイヤ２）の検査を行い、前記優先パケットは前記プロトコルレイヤ２の終端を行い、前記非優先パケットは前記プロトコルレイヤ１のまま前記非優先パケット処理部に転送することを特徴とする請求項２０に記載の伝送装置。
25. 優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットからなる受信パケットを受信する受信ステップと、
    前記受信パケットに格納されている通信プロトコルヘッダを検査することにより前記優先パケットと前記非優先パケットとを選別する選別ステップと、
    前記優先パケットと前記非優先パケットとをそれぞれ独立処理する処理ステップと、
    を有することを特徴とする伝送方法。
26. 前記選別ステップにおいて、前記通信プロトコルヘッダの少なくとも通信プロトコル種別を検査することにより、前記優先パケットと前記非優先パケットを選別することを特徴とする請求項２５に記載の伝送方法。
27. 前記選別ステップにおいて、前記通信プロトコルヘッダの少なくともポート番号を検査することにより、前記優先パケットと前記非優先パケットを選別することを特徴とする請求項２５に記載の伝送方法。
28. 前記選別ステップにおいて、前記通信プロトコルヘッダの少なくともフローラベルを検査することにより前記優先パケットと前記非優先パケットを選別することを特徴とする請求項２５に記載の伝送方法。
29. 前記選別ステップにおいて、前記受信パケットを構成するプロトコルレイヤ（プロトコルレイヤ１）よりも上位のプロトコルレイヤ（プロトコルレイヤ２）の検査を行い、前記優先パケットは前記プロトコルレイヤ２の終端を行い、前記非優先パケットは前記プロトコルレイヤ１のまま後のステップに転送することを特徴とする請求項２５に記載の伝送方法。
30. 優先して処理される優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットとを受信する受信フレーム処理部と、
    前記優先パケットのデフラグメント処理を行う第１のデフラグメント処理部と、前記非優先パケットのデフラグメント処理を行う第２のデフラグメント処理部とを含む複数のデフラグメント処理部と、
    を有することを特徴とする伝送装置。
31. 受信フレーム処理部に格納された受信パケットを前記優先パケットと前記非優先パケットに選別する受信パケット選別部を更に有し、
    前記非優先パケットの処理を行う非優先パケット処理部が前記第２のデフラグメント処理部を含むことを特徴とする請求項３０に記載の伝送装置。
32. 前記受信パケット選別部は、前記受信パケットがフラグメントされていない場合は、前記受信パケットが前記優先パケットか前記非優先パケットかを判定すると共に分離して出力し、前記受信パケットがフラグメントされている場合において、前記受信パケットが前記非優先パケットであると判定可能な場合は、前記受信パケットを前記非優先パケット処理部に転送すると共に当該受信パケットの識別子を記憶し、前記受信パケットが前記優先パケットであると判定可能な場合は、前記受信パケットを前記第１のデフラグメント処理部に転送すると共に当該受信パケットの識別子を記憶し、前記受信パケットの情報だけでは前記優先パケットであるか前記非優先パケットであるかを判定不可能な場合は、前記識別子を使用して判定し、前記識別子を使用しても判定不可能な場合は、前記受信パケットを前記第１のデフラグメント処理部に転送し、
    前記第１のデフラグメント処理部は少なくとも前記優先パケットのデフラグメント処理を行うと共に、前記受信パケットが前記非優先パケットと判断された場合は、当該受信パケットに関連する全てのパケットを前記非優先パケット処理部に転送し、
    前記非優先パケット処理部は前記非優先パケットのデフラグメント処理を行う、
    ことを特徴とする請求項３１に記載の伝送装置。
33. 優先して送信される優先データに誤り訂正用符号を付加して前記優先データと共に優先パケットとして生成する優先パケット生成部と、前記優先パケットよりも送信優先度が低い非優先パケットを生成する非優先パケット処理部と、前記優先パケットと前記非優先パケットの送信タイミングを決定する送信パケット制御部と、前記優先パケットと前記非優先パケットの送信処理を行う送信フレーム処理部と、ネットワークから伝送障害を検知して前記送信フレーム処理部に通知する受信フレーム処理部とを備え、
    前記送信パケット制御部は前記伝送障害により前記優先パケットの送信が遅延した場合に、前記誤り訂正用符号が格納された前記優先パケットを間引いて送信することを特徴とする伝送装置。
34. 前記伝送障害はネットワークからの送信停止要求である請求項３３に記載の伝送装置。
35. 前記送信パケット制御部は前記伝送障害検出時に所定期間パケットの送信を停止する請求項３３に記載の伝送装置。
36. 前記伝送障害はネットワークでのパケットの衝突検出である請求項３３に記載の伝送装置。
37. 前記送信パケット制御部は前記伝送障害検出時に障害の起こったパケットの再送を行う請求項３３に記載の伝送装置。
38. 優先して送信される優先データに誤り訂正用符号を付加して前記優先データと共に優先パケットとして送信する優先パケット送信ステップと、
    前記優先パケットよりも送信優先度が低いパケットを非優先パケットとして送信する非優先パケット送信ステップと、を有し、
    伝送路に伝送障害が発生した場合は、前記優先パケット送信ステップにおいて、前記誤り訂正用符号が格納された前記優先パケットを間引いて送信することを特徴とする伝送方法。
39. 前記伝送障害はネットワークからの送信停止要求である請求項３８に記載の伝送方法。
40. 前記伝送障害はネットワークでのパケットの衝突検出である請求項３８に記載の伝送方法。
41. 優先して処理される優先データを格納した優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットを受信し、受信フレームの受け入れ処理を行う受信フレーム処理部と、
    前記受信フレームに格納された受信パケットを前記優先パケットと前記非優先パケットに選別する受信パケット選別部と、
    少なくとも前記優先パケットのデフラグメント処理を行うデフラグメント処理部と、
    前記優先データの処理の完了の通知である優先データ処理完了通知を発行する優先データ処理監視部と、
    を備え、
    前記デフラグメント処理部は、前記優先データ処理完了通知を受けた時までに処理されるべきであった前記優先パケットのデフラグメント処理を終了させることを特徴とする伝送装置。
42. 前記優先データ完了通知は通信プロトコルヘッダの識別情報を元に生成されることを特徴とする請求項４１に記載の伝送装置。
43. 前記受信フレーム処理部、前記受信パケット選別部又は前記デフラグメント処理部は、前記優先データ処理完了通知を受けた時までに処理されるべきであった前記優先パケットを受信した場合はその優先パケットを廃棄することを特徴とする請求項４１または４２に記載の伝送装置。
44. 優先して処理される優先データを格納した優先パケットと前記優先パケットよりも処理優先度が低い非優先パケットを受信する受信ステップと、
    前記優先データの処理が終了した場合に、処理が終了した時までに処理されるべきであった前記優先パケットのデフラグメント処理を終了させるデフラグメント処理終了ステップと、
    を有することを特徴とする伝送方法。
45. 処理が終了した時までに処理されるべきであった前記優先パケットを受信した場合はその優先パケットを廃棄する廃棄ステップを更に有することを特徴とする請求項４４に記載の伝送方法。
46. 前記受信パケット選別部は、異なるレイヤの通信プロトコルヘッダを同時に検査することを特徴とする請求項２０に記載の伝送装置。
47. 前記選別ステップにおいて、異なるレイヤの通信プロトコルヘッダを同時に検査することを特徴とする請求項２５に記載の伝送方法。

Images