JP2005341107A - パケット送受信装置 - Google Patents

Abstract

【課題】バスの帯域に比べて符号化映像音声データのビットレートが高い場合には、符号化映像音声データによるバスの帯域消費が装置の正常動作を妨げる場合がある。
【解決手段】本発明のパケット送受信装置は、ネットワークインターフェースのパケット受信部にパケット解析部を設け、符号化映像音声パケットはバスを介さずに専用インターフェースからデコーダへ出力し、ＣＰＵで受信処理すべきパケットはバスを介してＣＰＵへ転送することで、バス帯域を全く圧迫しないパケット送受信装置を提供する。
【選択図】図１

Description

本発明は、通信網からパケット化された符号化映像音声データを送受信し再生する装置に関するものである。

従来、この種のパケット送受信装置としては、例えば、特許文献１に記載されているようなものがあった。図８は前記特許文献に記載された従来のパケット送受信装置を示している。図８において、ネットワークインターフェース１０５はバス１１を介してネットワークから受信したパケットをデュアルポートメモリ１０４に一旦格納し、映像音声用インターフェース１０６はデュアルポートメモリのバスとは異なる出力ポートから受信パケットを読み出して、前記パケットが映像音声データを伝送するパケットであるか否かを判定し、符号化映像音声パケットである場合はデコーダ１９へ渡す動作を行う。

前記構成によって、映像音声データによるバス１１の帯域圧迫を回避している。
特開２００４−１１２１９２号公報

しかしながら、前記従来の構成では、符号化映像音声データはバスを少なくとも１回は通過することになり、バスの帯域に比べて符号化映像音声データのビットレートが高い場合には、符号化映像音声データによるバスの帯域消費が装置の正常動作を妨げる場合がある。

本発明は、上記課題を解決するために、ネットワークインターフェース内に受信パケットを判定するパケット判定部を設け、符号化映像音声パケットの場合はバスを介することなくデコーダへ直接転送することでバス帯域圧迫を回避することができるパケット送受信装置を提供することを目的とする。

さらに本発明は、符号化映像音声データを伝送するパケットの受信再生動作に多くのＣＰＵ性能を必要とせず、廉価なＣＰＵでも受信再生を可能とするネットワークインターフェースを提供することを目的とする。

前記従来の課題を解決するため、本発明のパケット送受信装置は、ネットワークインターフェースのパケット受信部にパケット判定部を設け、符号化映像音声パケットはバスを介さずに専用インターフェースからデコーダへ出力する。その結果、バス帯域を全く圧迫しないパケット送受信装置を提供できる。

また、ＣＰＵで受信処理すべきパケットは、バスを介してＣＰＵへ転送する。その結果、ＣＰＵで実行されるソフトウェアは、本発明のネットワークインターフェースは一般的なネットワークインターフェースと同じように扱うことができる。

以上のように、本発明のパケット送受信装置によれば、バス帯域を全く圧迫することがなくなり、かつＣＰＵ性能を必要としないため、一般に廉価な性能が低いＣＰＵを用いて装置を構成することができる。また、ハイビジョン映像のようにビットレートが高い符号化映像音声データでも問題なく受信再生することができる。

また、ソフトウェアに対しては一般的なネットワークインターフェースと同じ動きをするために、プロトコル処理ソフトウェアに特殊な機能を必要としない利点がある。

以下に、本発明を実施するための最良の形態について、図面を参照しながら説明する。

（実施の形態１）
図１は本実施の形態１におけるパケット送受信装置の構成図である。図１において、図８と同じ構成要素については同じ符号を用い、説明を省略する。

ホストＣＰＵ１０、バス１１、バスインターフェース１２はＣＰＵ搭載装置において一般的な構成要素であり、ＰＨＹ制御部１３はネットワーク装置において一般的な構成要素であり、メモリ１８は汎用メモリであり、デコーダ１９はＭＰＥＧ２やＭＰＥＧ４やＨ．２６４などの一般の符号化映像音声デコーダであり、本発明に何ら関わるものではなく、説明を省略する。

本発明のパケット送受信装置は大きく分けて送信と受信の機能を有する。まず送信動作について説明する。

ホストＣＰＵ１０は作成したデータをバス１１を介してバスインターフェース１２、ＭＡＣ部１５、ＰＨＹ制御部１３の順に介して、データを外部ネットワーク１４へと送信する。本動作は一般的なネットワーク装置の送信動作と同じであり、本発明に何ら関わるものではない。

次に受信動作について説明する。

外部ネットワーク１４は本装置が接続される外部ネットワークであり、代表的なものとしてインターネットがある。

ＰＨＹ制御部１３は外部ネットワークとの物理層インターフェースであり、外部ネットワーク１４から受信したパケットをＭＡＣ部１５へ転送する。

ＭＡＣ部１５はパケット解析部１６またはバスインターフェース１２へ受信パケットを転送する。パケット解析部１６はＭＡＣ部１５から受けたパケットを解析し、映像音声データを伝送するパケットであると判断した場合はストリーム処理部１７へ転送し、ＣＰＵで処理すべきデータと判断した場合はＭＡＣ部１５へと戻す。ＭＡＣ部１５はパケット解析部１６から戻されたパケットをバスインターフェース１２へ転送する。

ストリーム処理部１７はパケット解析部１６から受けたパケットから映像音声データを抽出してメモリ１８に一旦蓄積し、メモリ１８から読み出した映像音声データをデコーダ１９へと転送する。

以下、前記構成要素の詳細について図面を参照しながら説明する。

図２はＭＡＣ部１５の内部構成図である。

受信処理部１５２は受信したパケットをパケット解析部１６と切替スイッチ１５４とへ渡し、切替スイッチ１５４はホストＣＰＵ１０からの設定にしたがって受信処理部１５２またはパケット解析部１６のいづれか一方を選択し、受信パケットを受信バッファ１５３へと渡す。受信バッファ１５３はバッファ内のデータをバスインターフェース１２へ渡す。

ＭＡＣ部１５のかかる構成によれば、切替スイッチ１５４を設けることにより、ネットワークインターフェース２０は、パケット解析部１６やストリーム処理部１７の影響を受けることなく、一般的なネットワークインターフェースとして動作することが可能となる。

図３はパケット解析部１６の内部構成図である。

ＭＡＣ部１５から受けたパケットに対して、ＭＡＣ解析部１６０はＭＡＣヘッダを解析し、ＩＰ解析部１６１はＩＰヘッダを解析し、ＵＤＰ解析部１６２はＵＤＰヘッダを解析し、ＲＴＰ解析部１６３はＲＴＰヘッダを解析して、受信パケットが映像音声データを伝送している可能性があるか否かを判定して、判定結果を判定部１６６へ渡す。判定部１６６は受信パケットが映像音声データを伝送しているか否かを判定し、受信パケットの出力先をＭＡＣ部１５かバッファ１６７のいづれか一方に決定する。

（ＭＡＣ〜ＲＴＰ解析動作・判定動作の説明）
ＭＡＣ解析部１６０は、ＭＡＣ部１５から受信パケットを受けてＭＡＣヘッダの解析を開始する。送信先ＭＡＣアドレスフィールドが自局のＭＡＣアドレスと一致し、かつ上位プロトコルフィールドがＩＰを示す場合に、判定部１６６とＩＰ解析部１６１にＭＡＣヒット信号を渡す。ヘッダ解析が終了した時点で判定部１６６とＩＰ解析部１６１にＭＡＣ終了信号を渡す。また、バイト単位のＭＡＣヘッダ長を算出し判定部１６６へ渡す。ＭＡＣヘッダにＶＬＡＮ（バーチャルＬＡＮ）タグフィールドが存在する場合は、ＶＬＡＮタグを読み飛ばす。

ＩＰ解析部１６１は、ＭＡＣ終了信号を受けて受信パケットのＩＰヘッダの解析を開始する。

ＩＰ解析部１６１のアルゴリズムを図４を参照しながら説明する。

ステップＳ１０００は送信先ＩＰアドレスフィールドが自局のＩＰアドレスに一致し、かつ送信元ＩＰアドレスが映像音声サーバアドレスに一致し、かつバージョン番号が４または６に一致した場合に、ステップＳ１００１を実行し、そうでない場合は終了する。

ステップＳ１００１は、フラグメントオフセットフィールドを検査し、受信パケットがＩＰフラグメントしているか否かを判定し、フラグメントしていないかまたはフラグメントしている先頭パケットである場合はステップＳ１００２を実行し、そうでない場合はステップＳ１００５を実行する。

ステップＳ１００５は、ＩＤフィールドが内部記憶領域に保持しているＩＤ保持値と一致する場合はステップＳ１００４を実行し、そうでない場合は終了する。

ステップＳ１００２は、上位プロトコルフィールドがＵＤＰを示す場合はステップＳ１００３を実行し、そうでない場合は終了する。

ステップＳ１００３は、上位プロトコルがＵＤＰであることを示すＵＤＰ検出信号をＵＤＰ解析部１６２へ出力し、ステップＳ１００４を実行する。ステップＳ１００４は、映像音声データの可能性があることを示すＩＰヒット信号を判定部１６６へ出力し、ステップＳ１００６を実行する。ステップＳ１００６は、パケット終端を受信した場合にステップＳ１００７を実行する。ステップＳ１００７は、ＵＤＰ検出信号とＩＰヒット信号の出力を停止し、終了する。

ステップＳ１００５で参照しているＩＤ保持値の更新動作について説明する。

ＩＰヘッダのＩＤフィールドを受信パケット毎に一時記憶領域に更新保持し、ＵＤＰ終了を受信した場合にＩＤ保持値を一時記憶領域に保持しているＩＤフィールド値で更新保持する。

なお、図４は出力信号を生成するための条件を示すためのフローチャートであり、ステップＳ１０００〜ステップＳ１００２とステップＳ１００５の判定処理は必ず全てを実行してもよいし、フローチャートで示す順序どおりに選択的に実行してもよい。

また、ＩＰ解析部１６１は、判定部１６６へＩＰ終了信号とＩＰヒット信号と、ＩＰヘッダから取り出したＩＰヘッダ長とトータル長とを渡す。なお、ＩＰヘッダ長フィールドとトータル長フィールドは４バイト単位の値であるので、バイト単位へ変換して出力する。

ＵＤＰ解析部１６２は、ＩＰ解析部１６１からＵＤＰ検出信号を受けて、受信パケットのＵＤＰヘッダの解析を開始する。判定部１６６へは、ＵＤＰヘッダの解析が終了したことを示すＵＤＰ終了信号と、ＵＤＰヘッダのヘッダ長と、ＵＤＰヘッダの送信先ポート番号フィールドが映像音声パケットを受信する自局のポート番号と一致し、かつ送信元ポート番号が映像音声サーバの映像音声パケットを送信するポート番号と一致する場合に、ＵＤＰヒット信号とを渡す。また、ＩＰ解析部１６１とＲＴＰ解析部１６３とへＵＤＰ終了信号を渡す。

ＲＴＰ解析部１６３は、ＵＤＰ終了信号を受けて受信パケットのＲＴＰヘッダの解析を開始する。ＣＳＲＣ ｃｏｕｎｔフィールドで示されるデータ量のＣＳＲＣフィールドと、ＳＳＲＣフィールドを読み飛ばす。ｅｘｔｅｎｓｉｏｎフィールドで拡張ヘッダの存在が示される場合は、拡張ヘッダ内のｌｅｎｇｔｈを読むことにより、拡張ヘッダを読み飛ばす。ＲＴＰヘッダの固定長フィールド分とＣＳＲＣ ｃｏｕｎｔと、拡張ヘッダが存在する場合はｌｅｎｇｔｈとから、拡張ヘッダを含むＲＴＰヘッダのヘッダ長を算出し判定部１６６へ渡す。また、ＲＴＰヘッダの解析が終了したことを示すＲＴＰ終了信号を判定部１６６へ渡す。なお、受信パケットがＲＴＰヘッダを含むか否かはホストＣＰＵ１０から通知される。

（出力先決定部の構成と動作の説明）
出力先決定部１６４は、受信パケットのヘッダ解析中に受信パケットを蓄積するヘッダバッファ１６５と、ヘッダバッファ１６５から読み出した受信パケットをＭＡＣ部１５またはバッファ１６７へ切り替える判定部１６６と、ストリーム処理部１７へ受信パケットを渡すためのバッファ１６７とから構成し、受信パケットをＭＡＣ部１５またはストリーム処理部１７へ渡す。以下、出力先決定部１６４の内部構成について説明する。

判定部１６６は、ＭＡＣ終了信号とＩＰ終了信号とＵＤＰ終了信号とＲＴＰ終了信号とにより、受信パケットのヘッダ解析が終了したことを認識する。ヘッダ解析中はヘッダバッファ１６５の読み出し動作は行わずに受信パケットを蓄積する。ヘッダ解析が終了した場合は、ＭＡＣヒット信号とＩＰヒット信号とＵＤＰヒット信号との全てを受けたときは受信パケットの出力先をバッファ１６７に決定し、それ以外のときはＭＡＣ部１５へ決定し、ヘッダバッファ１６５からの読み出しを開始する。ヘッダバッファ１６５からの読み出し速度は、外部ネットワークとのリンク速度よりも高速とすることにより、次の受信パケットを受けたときにヘッダバッファ１６５を空にすることができる。実験では、リンク速度の２倍速で読み出すことでバッファを空にすることができた。

ヘッダバッファ１６５から受信パケットの終端を読み出した後に読み出し動作を停止し、次の受信パケットを待つ。ＭＡＣヘッダ長とＩＰヘッダ長とＵＤＰヘッダ長とＲＴＰヘッダ長との加算結果である全ヘッダ長と、トータル長とＭＡＣヘッダ長とＣＲＣなどのその他に付加されるＭＡＣデータの加算結果であるＭＡＣパケット長とを、ストリーム処理部１７へ渡す。

（ストリーム処理部の構成と動作の説明）
図５は、本実施の形態１におけるストリーム処理部１７の構成図である。

図５において、パケット解析部１６から渡される受信パケットのペイロードに格納されている映像音声データは、ＭＰＥＧ２トランスポートストリーム（ＴＳ）データである場合を例にとって説明する。ペイロード抽出部１７０はパケット解析部１６からの受信パケットと全ヘッダ長とＭＡＣパケット長とを受け、受信パケットのＴＳデータを抽出し、ＴＳ同期検出部１７１へと渡す。

ＴＳ同期検出部１７１は、ＴＳパケットのシンクバイトが周期的に存在することを検査し、シンクバイトが存在するときはＴＳデータをライトＤＭＡＣ１７２に渡す。一方、シンクバイトを検出できなかったときは、ライトＤＭＡＣ１７２へのＴＳデータ出力を停止し、ペイロード抽出部１７０から受けるＴＳデータを検査し、シンクバイトが周期的に存在することを確認してから、ライトＤＭＡＣ１７２へのＴＳデータ出力を再開する。

なお、受信データの完全性が保証される場合は、ＴＳ同期検出部１７１は省いてもよい。

ライトＤＭＡＣ１７２は、内部に持つバッファにＴＳ同期検出部１７１から受けたＴＳデータを一旦蓄積し、メモリコントローラ１７４を介してメモリ１８へＴＳデータを蓄積する。リードＤＭＡＣ１７３は、メモリコントローラ１７４を介してメモリ１８にあるＴＳデータをリードし、ＴＳ解析部１７５へ渡す。メモリコントローラ１７４は、ライトＤＭＡＣ１７２とリードＤＭＡＣ１７３との調停と、メモリ１８へのデータのリードとライトを行う。

ＴＳ解析部１７５は、リードＤＭＡＣ１７３から受けたＴＳパケットヘッダを解析して復号部１７６へ渡す信号を生成する。ＴＳパケットヘッダの解析について詳細に説明する。

ＴＳパケットのｔｒａｎｓｐｏｒｔ＿ｓｃｒａｍｂｌｉｎｇ＿ｃｏｎｔｒｏｌ（ＴＳＣ）フラグを検査し、ＴＳパケットペイロードが暗号化されているか否かの判定と、暗号化されている場合は２種類の復号鍵、すなわち偶数鍵と奇数鍵、のどちらで復号すべきか、を判定し復号部１７６へ渡す。ＴＳパケットヘッダとアダプテーションフィールドは暗号化されていないものと判定する。

さらに、可変長のアダプテーションフィールド長と固定長のＴＳパケットヘッダとをＴＳパケット長１８８バイトから減算することによりＴＳパケットのペイロード長を計算し、暗号化の単位である暗号ブロック毎に復号モードをＣＢＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）やＯＦＢ（Ｏｕｔｐｕｔ Ｆｅｅｄｂａｃｋ）やＥＣＢ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｄｅ Ｂｏｏｋ）やＣＦＢ（Ｃｉｐｈｅｒ Ｆｅｅｄｂａｃｋ）に切り替える信号を生成し、復号部１７６へ渡す。

復号部１７６は、ＴＳ解析部１７５から受けたＴＳデータが暗号化されている場合は復号したデータを、暗号化されていない場合はそのままのデータを、ＴＳ解析部１７５から受けた時間順序を守って出力制御部１７７へ渡す。

暗号化データを復号するための２種類の復号鍵は、ホストＣＰＵ１０から暗号化された復号鍵を受けて、あらかじめ復号部１７６で復号しておき、ネットワークインターフェース２０内部またはストリーム処理部１７内部の記憶領域に保持しておく。

出力制御部１７７は、復号部１７６から受けたＴＳパケットを、ホストＣＰＵ１０から指定された出力レートで、ＡＲＩＢ規格やＤＶＢ規格の伝送フォーマットでデコーダ１９へ出力する。

図６は、１６バイトバーストでメモリ１８にアクセスする場合のメモリ１８内のデータ形式の一例である。

メモリ１８としてＳＤＲＡＭのようなバーストアクセスメモリを使用する場合、一般にデータ転送効率を高めるために、１６バイトや３２バイトなどのように１６以上の２のべき乗バイト数のバーストアクセスを使うことが多い。一方、ＴＳパケットは固定長１８８バイトであるため、１６では割り切れない。そこで、メモリ管理を簡単にするために、４バイトのダミーをＴＳパケット毎に付加して１６で割り切れる１９２バイトとした。

かかる構成によれば、ＴＳ同期検出部１７１は、シンクバイト検出時に４バイトのダミーデータをライトＤＭＡＣ１７２へ渡してから、受信したデータをライトＤＭＡＣ１７２へ渡し、ＴＳ解析部１７５は、１９２バイト読み出し毎に４バイトを読み捨てることで、ＴＳパケットの先頭を簡単に識別することができる。

さらに、ＴＳ同期検出部１７２とＴＳ解析部１７３とでダミーデータの値を特定の値に取り決めることで、ＴＳ解析部１７５が読み出したデータの正当性を確認することができる。

以上のようにかかる構成によれば、ネットワークインターフェース２０で受信パケットが映像音声データを伝送することを判定し、受信パケットのペイロードからＴＳパケットを取り出して、デコーダ１９へ直接出力することにより、バス１１の帯域を消費せずに、かつＣＰＵ性能を必要とせずに映像音声の受信再生を実現することができる。

なお、本実施の形態１では、ＭＡＣヒット信号を受けてＩＰ解析部１６１が解析を行い、ＩＰヒット信号を受けてＵＤＰ解析部１６２が解析を行い、ＵＤＰヒット信号を受けてＲＴＰ解析部が解析を行うというようにシーケンシャルな動作を示したが、必ずしもシーケンシャルに動作する必要はなく、受信パケット毎に構成要素１６０から１６３が必ず動作してもよい。この場合、複雑な動作制御が不要となる効果がある。

なお、本実施の形態１では、ＵＤＰで映像音声データを伝送する場合を例にとって説明したが、ＵＤＰの代わりにＴＣＰでもよい。この場合、ＩＰ解析部１６１は上位プロトコルフィールドがＴＣＰであることを検査し、ＵＤＰ解析部１６２ではＴＣＰヘッダの送信先ポート番号フィールドと送信元ポート番号フィールドをＵＤＰの場合と同様に解析する。

なお、本実施の形態１では、出力先決定部１６４の出力先はＭＡＣ部１５またはストリーム処理部１７のいずれか１つとしたが両方でもよく、この場合、デコーダが受信再生している映像音声データをＣＰＵでも受信し、受信データの統計情報をとることが可能となる効果がある。

また、出力先決定部１６４の出力先はＭＡＣ部１５とストリーム処理部１７としたが、図７に示すようにその他に出力先を持ってもよい。この場合、ＭＰＥＧ２プログラムストリームやＭＰＥＧ４やＨ．２６４などのデータ処理を行う構成要素をストリーム処理部１７と同様の位置付けとして追加し、その符号化方式に対応したデコーダをデコーダ１９と同様の位置付けとして追加することにより、ＴＳ以外の符号化方式にも対応することが可能となる。

なお、本実施の形態１では、パケット解析部１６からストリーム処理部１７へ渡すデータはＭＡＣパケットとしたが、ＩＰパケットやその他の形式でもよい。

なお、本実施の形態１では、ネットワークインターフェース２０にＭＡＣ部１５とパケット解析部１６とストリーム処理部１７とバスインターフェース１２を包含したが、構成要素の包含関係はこの限りではない。

なお、本実施の形態１では、受信パケットのチェックサムやＣＲＣの検査は実施しても、しなくてもよい。実施する場合は、エラー時にパケットを廃棄したり、エラー種別やエラー回数をＣＰＵへ通知し、エラーリカバリー処理が可能となる。

なお、本実施の形態１では、受信パケットのヘッダのフィールドの判定処理を必ず実行する例を示したが、判定が不要な場合においては判定を省くことも可能である。この場合、本発明の装置を適用する映像音声データのパケット配信サービスの運用ルールに、本発明の装置を適合させることが可能となる。

本発明にかかるパケット送受信装置は、バスを通ることなく映像音声データをデコーダへ渡すことが可能になるので、パケット網を利用した映像音声受信装置および映像音声受信装置用のネットワークインターフェースとして有用である。

本発明の実施の形態１におけるネットワークインターフェース並びにパケット送受信装置の構成図 本発明の実施の形態１におけるＭＡＣ部の内部ブロック図 本発明の実施の形態１におけるパケット解析部の内部ブロック図 本発明の実施の形態１におけるＩＰヘッダ解析部のアルゴリズムを示すフローチャート 本発明の実施の形態１におけるストリーム処理部の内部ブロック図 本発明の実施の形態１におけるメモリ内のデータ構造の一例を示す図 本発明の実施の形態１における異なる一例のパケット送受信装置の構成図 従来のパケット送受信装置の構成図

符号の説明

１０ ホストＣＰＵ
１１ バス
１２ バスインターフェース
１３ ＰＨＹ制御部
１４ 外部ネットワーク
１５ ＭＡＣ部
１６ パケット解析部
１７ ストリーム処理部
１８ メモリ
１９ ＭＰＥＧ２デコーダ
２０ ネットワークインターフェース
２１ ＴＳ以外のストリーム処理部
２２ ＴＳ以外のデコーダ
１５２ 受信処理部
１５３ 受信バッファ
１５４ 切替スイッチ
１６０ ＭＡＣ解析部
１６１ ＩＰ解析部
１６２ ＵＤＰ解析部
１６３ ＲＴＰ解析部
１６４ 出力先決定部
１６５ ヘッダバッファ
１６６ 判定部
１６７ バッファ
１７０ ペイロード抽出部
１７１ ＴＳ同期検出部
１７２ ライトＤＭＡコントローラ
１７３ リードＤＭＡコントローラ
１７４ メモリコントローラ
１７５ ＴＳ解析部
１７６ 復号部
１７７ 出力制御部
Ｓ１０００ ＩＰアドレスとバージョン番号判定ステップ
Ｓ１００１ フラグメント判定ステップ
Ｓ１００２ 上位プロトコル判定ステップ
Ｓ１００３ ＵＤＰ検出信号出力ステップ
Ｓ１００４ ＩＰヒット信号出力ステップ
Ｓ１００５ ＩＤフィールド判定ステップ
Ｓ１００６ パケット終端待ちステップ
Ｓ１００７ 信号出力停止ステップ

Claims (1)

1. 受信データを解析するパケット解析部と、
   入出力データをバスに対して送受信するバスインターフェースと、
   入力されたパケットから映像音声データを抽出してメモリに一旦蓄積し、符号化映像音声データを復調するデコーダへ前記メモリから読み出した映像音声データを出力するストリーム処理部と
   前記パケット解析部の解析結果に基づいて受信データの出力先を前記バスインターフェースか前記ストリーム処理部かを切替える切替スイッチを備え、
   前記パケット解析部が受信データを解析した結果、受信データが映像音声データを伝送するパケットであると判断した場合は前記ストリーム処理部へ、ＣＰＵで処理すべきデータと判断した場合は前記バスインターフェースへ出力されるように前記切替スイッチを制御することを特徴とするパケット送受信装置。

Images