(57)【特許請求の範囲】
【請求項１】
インターネット・プロトコルＩＰデータを、衛星システムを通じた伝送のためのフォーマットにエンコードする方法であって、
ＩＰデータ・ブロックおよびヘッダ情報を有するＩＰパケットを受信するステップと、
前記ＩＰパケットを、データ・フレームとヘッダ情報とを有する可変長マルチパケット・トランスポートＭＰＴフレームにエンコードし、該マルチパケット・フレームの前記データ・フレームが前記ＩＰパケットを含むようにするステップと、
前記可変長ＭＴＰフレームを１つ以上の固定長ＭＴＰパケットにエンコードするステップであって、各ＭＰＴパケットがデータ・フラグメント・ブロックを有し、該データ・フラグメント・ブロックが少なくとも前記ＭＴＰフレームの一部と、前記ＭＴＰフレームのどの部分を前記データ・フラグメント・ブロック内に収容するかを指定する、関連ヘッダ情報とを含む、ステップと、
から成るエンコード方法。
【請求項２】
請求項１記載の方法において、各ＭＰＴパケットの前記ヘッダ情報が、前記関連するデータ・フラグメント・ブロック内に収容したデータは、前記ＭＰＴフレームの開始部分、前記ＭＰＴフレームの終了部分、または前記ＭＰＴフレームの中間部分の内どこからのものであるのかを指定すること、を特徴とするエンコード方法。
【請求項３】
請求項２記載の方法において、各ＭＰＴパケットの前記ヘッダ情報が、前記ＭＰＴパケットの前記関連するデータ・フラグメント・ブロック内に収容してあるデータが前記ＭＴＰフレームの開始部分を含む場合にセットするフレーム開始ビットと、前記ＭＴＰパケットの前記関連するデータ・フラグメント・ブロック内に収容してあるデータが前記ＭＴＰフレームの終了部分を含む場合にセットするフレーム終了ビットとを有する１バイト・ヘッダを備え、前記フレーム開始ビットおよび前記フレーム終了ビットは、前記ＭＴＰパケットの前記関連するデータ・フラグメント・ブロック内に収容してあるデータが前記ＭＰＴフレームの中間部分を含む場合に、双方共リセットすること、を特徴とするエンコード方法。
【請求項４】
請求項２記載の方法において、各ＭＰＴパケットの前記ヘッダ情報が、前記関連するデータ・フラグメント・ブロック内に収容してあるデータが、前記ＭＰＴフレームの前記開始部分である場合に、マルチ・ビット・アドレスを備えること、を特徴とするエンコード方法。
【請求項５】
請求項１記載の方法であって、更に、１つ以上のＭＰＴパケットについてエラー訂正情報を算出するステップを含むこと、を特徴とするエンコード方法。
【請求項６】
請求項５記載の方法であって、更に、前記ＭＰＴパケットの１つに前記エラー訂正情報を添付するステップを含むこと、を特徴とするエンコード方法。
【請求項７】
請求項１記載の方法であって、更に、アドレスとエラー訂正情報を備えたトレーラとを含むヘッダを、各固定長ＭＰＴパケットに付加し、衛星伝送可能パケットを形成するステップを含むこと、を特徴とするエンコード方法。
【請求項８】
請求項７記載の方法であって、更に、前記衛星伝送可能パケットを送信するステップを含むこと、を特徴とするエンコード方法。
【請求項９】
インターネット・プロトコルＩＰデータを、衛星システムを通じた伝送のためのフォーマットにエンコードする方法であって、
ＩＰデータ・ブロックと、トランスポート・プロトコル・ヘッダと、ＩＰヘッダとを有するＩＰパケットを受信するステップと、
データ・ペイロードとヘッダとを有する、可変長マルチパケット・トランスポートＭＰＴフレームを構築するステップと、
前記ＩＰパケット全体を、前記ＭＰＴフレームの前記データ・ペイロードに挿入するステップと、
前記ＭＰＴフレームから、１つ以上の固定サイズ・マルチ・バイトＭＰＴパケットを構築するステップであって、各ＭＰＴパケットが、前記ＭＴＰフレームのどの部分を前記ＭＰＴパケットに収容するかを指定する少なくとも１つのヘッダを有する、ステップと、
から成るエンコード方法。
【請求項１０】
請求項９記載の方法であって、更に、前記１つ以上のＭＰＴパケットについて、エラー訂正情報を算出するステップを含むこと、を特徴とするエンコード方法。
【請求項１１】
請求項１０記載の方法であって、更に、前記エラー訂正情報を、マルチ・ビット・トレーラとして前記ＭＰＴパケットの１つに添付するステップを含むこと、を特徴とするエンコード方法。
【請求項１２】
請求項９記載の方法であって、更に、前記ＭＰＴパケットを送信するステップを含むこと、を特徴とするエンコード方法。
【請求項１３】
ネットワーク・データ・パケットを、分散システムを通じた伝送のためのフォーマットにエンコードする方法であって、
ネットワーク・データ・パケットにヘッダを付加して、可変長マルチパケット・トランスポートＭＰＴフレームを形成するステップと、
前記ＭＰＴフレームを１つ以上のデータ・フラグメント・ブロックに区分するステップと、
各データ・フラグメント・ブロックにヘッダを付加して、前記分散システムを通じた伝送に適したサイズの固定長ＭＰＴパケットを形成するステップと、
から成るエンコード方法。
【請求項１４】
請求項１３記載の方法において、各ＭＰＴパケットの前記ヘッダが、関連するデータ・フラグメント・ブロックに収容してあるデータが、前記ＭＰＴフレームの開始部分、前記ＭＰＴフレームの終了部分、または前記ＭＰＴフレームの中間部分の内どこからのものであるのかを指定すること、を特徴とするエンコード方法。
【請求項１５】
請求項１３記載の方法において、各ＭＰＴパケットの前記ヘッダが、前記ＭＴＰパケットの前記関連するデータ・フラグメント・ブロック内に収容してあるデータが前記ＭＴＰフレームの開始部分を含む場台にセットするフレーム開始ビットと、前記ＭＴＰパケットの前記関連するデータ・フラグメント・ブロック内に収容してあるデータが前記ＭＴＰフレームの終了部分を含む場合にセットするフレーム終了ビットとを有する１バイト・ヘッダを備え、前記フレーム開始ビットおよび前記フレーム終了ビットは、前記ＭＴＰパケットの前記関連するデータ・フラグメント・ブロック内に収容してあるデータが前記ＭＰＴフレームの中間部分を含む場合に、双方共リセットすること、を特徴とするエンコード方法。
【請求項１６】
請求項１３記載の方法であって、更に、パディング・ビットをトレーラとして前記ネットワーク・データ・パケットに付加して、前記ＭＰＴフレームを形成するステップを含むこと、を特徴とするエンコード方法。
【請求項１７】
請求項１３記載の方法において、前記ヘッダを付加するステップが、前記ＭＴＰフレームのどの部分を前記データ・フラグメント・ブロックに収容するかを指定するヘッダを付加するステップを含むこと、を特徴とするエンコード方法。
【請求項１８】
請求項１３記載の方法であって、更に、アドレスを第１データ・フラグメント・ブロックに付加するステップを含むこと、を特徴とするエンコード方法。
【請求項１９】
請求項１３記載の方法であって、更に、前記ＭＰＴパケットについて、エラー訂正情報を算出するステップを含むこと、を特徴とするエンコード方法。
【請求項２０】
請求項１９記載の方法であって、前記エラー訂正情報を前記ＭＰＴパケットの１つに添付するステップを含むこと、を特徴とするエンコード方法。
【請求項２１】
請求項１３記載の方法であって、更に、アドレスと、エラー訂正情報を備えたトレーラとを含むヘッダを、各固定長ＭＰＴパケットに付加して、衛星伝送可能パケットを形成するステップを含むこと、を特徴とするエンコード方法。
【請求項２２】
請求項２１記載の方法であって、更に、前記衛星伝送可能パケットを、衛星分散システムを通じて送信するステップを含むこと、を特徴とするエンコード方法。
【請求項２３】
衛星伝送信号からコンピュータ・ネットワーク・データをデコードする方法であって、
多数の衛星パケットを受信するステップであって、個々の衛星パケットがデータ・ペイロードを有する、ステップと、
前記衛星パケットから前記データ・ペイロードを取り出すステップであって、各データ・ペイロードが、データ・フラグメント・ブロックと関連ヘッダ情報とを有する固定長マルチパケット・トランスポートＭＰＴパケットを含む、ステップと、
前記ＭＰＴパケットの前記ヘッダ情報を用いて、前記ＭＰＴパケットを可変長ＭＰＴフレームに配列するステップと、
前記ＭＰＴパケットの前記データ・フラグメント・ブロックから、前記ＭＰＴフレームを復元するステップと、
前記復元したＭＰＴフレームから前記ネットワーク・データを抽出するステップと、
から成るデコード方法。
【請求項２４】
衛星伝送システムであって、
コンピュータ・ネットワーク・データ・パケットを、１つ以上の衛星パケットにエンコードするエンコード・ユニットであって、該エンコード・ユニットが、（１）前記ネットワーク・データ・パケットにヘッダを付加して、可変長マルチパケット・トランスポートＭＰＴフレームを形成し、（２）前記ＭＰＴフレームを１つ以上のデータ・フラグメント・ブロックに区分し、（３）各データ・フラグメント・ブロックにヘッダを付加して、固定長ＭＰＴパケットを形成し、（４）各ＭＰＴパケットにヘッダ／トレーラ情報を付加して、１つ以上の衛星パケットを形成するように構成してある、エンコード・ユニットと、
前記エンコード・ユニットから前記衛星パケットを受信するように結合してある衛星送信ユニットであって、前記衛星パケットを衛星ネットワークを通じて送信する衛星送信ユニットと、
前記衛星ネットワークから前記衛星パケットを受信する受信ユニットと、
前記受信ユニットに結合してあり、前記衛星パケットから前記ＭＰＴパケットを回復し、前記ＭＰＴパケットから前記ＭＰＴフレームを復元し、前記ＭＰＴフレームから前記ネットワーク・データ・パケットを抽出するデコード・ユニットと、
から成る衛星伝送システム。
【請求項２５】
ネットワーク・データ・パケットを、衛星システムを通じた伝送のためのフォーマットにエンコードするエンコード・ユニットであって、
ネットワーク・データ・パケットにヘッダを付加して、可変長マルチパケット・トランスポートＭＰＴフレームを形成する手段と、
前記ＭＰＴフレームを１つ以上のデータ・フラグメント・ブロックに区分する手段と、
各データ・フラグメント・ブロックにヘッダを付加して、前記衛星システムを通じた伝送に適したサイズの固定長ＭＰＴパケットを形成する手段と、
から成るエンコード・ユニット。
【請求項２６】
請求項２５記載のエンコード・ユニットにおいて、前記ＭＰＴパケットのための前記ヘッダが、前記ＭＴＰフレームのどの部分を前記データ・フラグメント・ブロックに収容するかを指定すること、を特徴とするエンコード・ユニット。
【請求項２７】
請求項２５記載のエンコード・ユニットであって、更に、パディング・ビットをトレーラとして前記ネットワーク・データ・パケットに付加し、前記ＭＰフレームを形成する手段を備えること、を特徴とするエンコード・ユニット。
【請求項２８】
請求項２５記載のエンコード・ユニットであって、更に、アドレスを第１データ・フラグメント・ブロックに付加する手段を備えること、を特徴とするエンコード・ユニット。
【請求項２９】
請求項２５記載のエンコード・ユニットであって、更に、前記ＭＰＴパケットについて、エラー訂正情報を算出し、該エラー訂正情報を前記ＭＰＴパケットの１つに付加する手段を備えること、を特徴とするエンコード・ユニット。
【請求項３０】
請求項２５記載のエンコード・ユニットであって、更に、アドレスと、エラー訂正情報を備えたトレーラとを含むヘッダを、各ＭＰＴパケットに付加して、衛星伝送可能パケットを形成する手段を備えること、を特徴とするエンコード・ユニット。
【請求項３１】
放送ビデオ信号の垂直ブランキング期間ＶＢＩの一部として受信したコンピュータ・ネットワーク・データをデコードする受信ユニットであって、
多数の衛星パケットを受信する受信機であって、個々の衛星パケットが、固定長マルチパケット・トランスポートＭＰＴパケットを含むデータ・ペイロードを有し、各ＭＰＴパケットが、データ・フラグメント・ブロックと関連ヘッダ情報とを有する、受信機と、
前記受信機に結合したデバイス・ドライバと、
前記衛星パケットから前記ＭＰＴパケットを取り出し、該ＭＰＴパケットの前記ヘッダ情報を使用して、前記ＭＰＴパケットを可変長ＭＰＴフレームに配列するように構成してある、前記受信機またはデバイス・ドライバの一方であって、更に、前記ＭＰＴパケットの前記データ・フラグメント・ブロックから前記ＭＰＴフレームを復元し、該復元したＭＰＴフレームから前記ネットワーク・データを抽出するように構成してある前記受信機またはデバイス・ドライバの一方と、
から成る受信ユニット。
【発明の詳細な説明】
技術分野
本発明は、衛星ネットワークを通じてコンピュータ・ネットワーク・データ、特に、インターネット・プロトコル（ＩＰ）データを送る方法に関するものである。また、本発明は、衛星ネットワークおよびその他のタイプのネットワークを通じた伝送に適したパケット・サイズのネットワーク・データに対応するマルチパケット・トランスポート構造（multi-packet transport structure）に関するものでもある。
発明の背景
従来の衛星システムは、標準的なサイズのデジタル・パケットでデータを伝送する。一例として、「デジタル衛星システム」または「ＤＳＳ」ネットワークと呼ばれる衛星ネットワークの１つは、データを１４７バイト・パケットで伝送する。
図１は、従来のＤＳＳデータ・パケット２０を示す。これは、３バイトのヘッダ２２、１２７バイトのペイロード２４、および１７バイトのトレーラ２６を有する。ヘッダ２２は、４つのフラグ・ビット、サービス・チャンネル識別番号（ＳＣＩＤ：service channel identification number）のための１２のアドレス指定ビット、４つのシーケンス・ビット、および４つのタイプ・ビットを収容する。ペイロード２４は、伝送対象の実際のデータを保持する。トレーラ２６は、パケットをエラーなく伝送したか否かについて確認するのに役立つ、フォワード・エラー訂正（ＦＥＣ：forward error correction）情報を収容する。
各デジタル衛星パケット内に収容するデータは、１２７バイトのペイロード２４内に位置する。ＤＳＳパケットの一般的な使用の１つは、衛星系テレビジョンに用いるようなビデオおよびオーディオ信号を搬送することである。ビデオおよびオーディオ信号は、均一で中断のない画像および音響の提示を行うためには、特定のレートでデータ・ストリームを連続的に供給する必要がある。連続データ・ストリームを個々のパケットに変換するためには、データ・ストリームを１２７バイトの等しいサイズのブロックに分解する。各ブロックをＤＳＳパケット２０のペイロード２４に挿入する。次に、衛星システムを通じて個々のパケットをユーザの住居に送信する。ＤＳＳパケットからデータ・セグメントを抽出して、連続データ・ストリームを復元するために用いる。これらパケット形成、送信、受信および復元ステップは、受信者の住居においてリアル・タイムでビデオ／オーディオ信号を再生可能とするために、十分に高いレートで行う。
ネットワーク社会では、ＬＡＮ（ローカル・エリア・ネットワーク）やＷＡＮ（ワイド・エリア・ネットワーク）のようなデータ・ネットワークを通じて、データも個別のデジタル・パケットで同様に搬送する。共通に広く用いられているネットワーク・データの一種に、インターネット・プロトコル（ＩＰ）データと呼ばれるものがある。ＩＰデータは、イーサネットやインターネットを含む、本質的にあらゆる基礎ネットワーク上でデータを搬送するための標準的なフォーマットを定義する。ＩＰ規格は、データをカプセル化するために用いるパケットを定義する。ＩＰデータは、伝送ネットワークには関係なく、常にこのパケットにカプセル化し、多くの異なるネットワークを通じて搬送することを可能にする。
従来のネットワーク・データは、典型的に、１２７バイトよりははるかに大きいパケットにカプセル化している。これは、衛星送信に対しては問題となる。何故なら、ネットワーク・データ・パケットのサイズは、ＤＳＳパケット２０の１２７バイト・ペイロードのように、衛星パケットのペイロード・サイズを超過するからである。更に、ネットワーク・データ・パケットのサイズは劇的に変化する可能性がある。したがって、あるタイプのパケットを直接他のタイプのパケットに変換するための公式を定義することは、特に有用という訳ではない。同じ問題は、ＩＰに加えて他のネットワーク・データ・フォーマットにも、およびＤＳＳに加えて他の衛星フォーマットにも存在する。
可変長のネットワーク・データ・パケットを、固定サイズの衛星パケットおよび他のタイプのネットワーク・パケットで搬送することを可能にするトランスポート・レイヤを提供することができれば有益であろう。
また、衛星ネットワークを通じてデータを送信した後のデータの使用に関係する別の問題もある。コンピュータ・アプリケーションは、標準的な数組のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を用いて、ネットワークおよびインターネットを通じてデータの送信および受信を行う。例えば、Windows（登録商標）系のオペレーティング・システム上で走るように設計したアプリケーションは、公知のウィンドウズ・ソケット仕様（Windows Sockets Specification）に規定してある標準的な１組のＡＰＩを使用する。これらのＡＰＩは、工業委員会（industry committees）が定義したものであり、広く用いられている。ソケットＡＰＩは、基礎のコンピュータ・ネットワークが何であれ（例えば、イーサネット、非同期転送モード（ＡＴＭ）等）、ネットワークに独立してデータの送信および受信を行う方法を与える。コンピュータ・アプリケーションは、特定のネットワークからデータを受信するように特別に書く必要はない。代わりに、開発者は、Windows（登録商標）Sockets APIにインターフェースするアプリケーションのためのコードを書けば、コンピュータのハードウェアが対応する多数の異なるネットワークを通じて、アプリケーションがデータの送信および受信を行うことが可能となる。
ＩＰデータ・パケットのようなネットワーク・データ・パケットを、ＩＰデータ・パケットのアイデンティティを失うことなく、衛星またはその他のネットワーク・システムを通じた伝送と互換性のあるフォーマットにパッケージし直す技法を考案することができれば有益である。このようにすれば、ネットワーク・データ・パケットは、単一のモノリシックなクライアント・アプリケーションのみに通用する所有者固有の機能即ち非標準的な機能によってではなく、標準的な１組の既存のＡＰＩを介して、コンピュータ・アプリケーションによる使用が可能となる。
発明の概要
本発明の一形態は、インターネット・プロトコル（ＩＰ）データのようなネットワーク・データを、衛星システムを通じた伝送のためのフォーマットにエンコードする方法に関する。ネットワーク・データは、データ・ブロックとヘッダ情報とを有するパケットに構成する。一例として、ＩＰパケットは、ＩＰデータと、ＩＰヘッダおよびＵＤＰ（ユーザ・データグラム・プロトコル）ヘッダとを収容する固定長ヘッダとから成る、可変長データ・ブロックを有する。
この方法によれば、ネットワーク・データ・パケットを、可変長マルチパケット・トランスポート（ＭＰＴ）フレームにエンコードする。ＭＰＴフレームは、データ・フレームおよびヘッダ情報から成る。ＩＰパケット全体を、ＭＰＴフレームのデータ・フレームに挿入する。
次に、可変長ＭＴＰフレームを、１つ以上の固定長ＭＴＰパケットにエンコードする。各ＭＰＴパケットは、データ・フラグメント・ブロックを有し、このデータ・フラグメント・ブロックは、ＭＴＰフレームの一部と、ＭＴＰフレームのどの部分を当該データ・フラグメント・ブロックに収容するかを指定する、関連ヘッダ情報とから成る。一実現例では、ＭＰＴパケット・ヘッダは、フレーム開始ビットおよびフレーム終了ビットを含む１バイトのヘッダである。これら２ビットは、ＭＴＰフレームの関連するデータ・フラグメント・ブロックに収容されているデータが、ＭＰＴフレームの開始部分、ＭＰＴフレームの終了部分、またはＭＰＴフレームの中間部分のどれであるかを指定する。即ち、データ・フラグメント・ブロックがＭＴＰフレームの開始部分を収容する場合、フレーム開始ビットを設定する。データ・フラグメント・ブロックがＭＴＰフレームの終了部分を収容する場合、フレーム終了ビットをセットする。関連するデータ・フラグメント・ブロックがＭＰＴフレームの中間部分を収容する場合、双方のビットをリセットする。このように、ヘッダ情報は、データ・フラグメントのＭＰＴフレームへの再組み立てに役立つ。
ＭＰＴパケットは、衛星システムを通じた伝送に適したサイズである。一実現例では、ＭＰＴパケットのサイズを１２７バイトとする。このサイズで、従来の１４７バイトのＤＳＳパケット内にある１２７バイトのペイロードにＭＰＴパケット全体を埋め込む。
この方法を用いて、データ・ネットワーク（即ち、イーサネットまたはインターネット）を通じて、大きなネットワーク・データ・パケットとして受信したデータを、マルチパケット・トランスポートが定義する、小さなパケットに分解する。次に、ＤＳＳネットワークのような特定の分散媒体を介した伝送に適した標準的な固定サイズのパケット内に、これらのパケットをデータ・ペイロードとして配置する。ネットワーク・データは、基礎のネットワークには独立のままであり、受信機において容易に抽出し、コンピュータ・アプリケーションによる使用が可能である。
他の形態によれば、衛星伝送信号からのコンピュータ・ネットワーク・データをデコードする方法を記載する。各ユーザの受信ユニットにおいて、衛星パケットを受信する。衛星パケットからデータ・ペイロードを除去する。各データ・ペイロードは、固定長のマルチパケット・トランスポート（ＭＰＴ）パケットを有し、このマルチパケット・トランスポート・パケットは、データ・フラグメント・ブロックおよび関連ヘッダ情報から成る。デコード・ユニットがＭＰＴパケットのヘッダ情報を用いて、ＭＰＴパケットを可変長ＭＰＴフレーム内に配列する。次に、ＭＰＴパケットのデータ・フラグメント・ブロックからＭＰＴフレームを復元し、復元したＭＰＴフレームからネットワーク・データを抽出する。
このように、従来の衛星パケットを用いて、その公知のフォーマットを失うことなく、ネットワーク・データを送信する。各ユーザの受信ユニットにおいて、コンピュータ・アプリケーションは、ウィンドウズ・ソケット仕様が規定するもののような、標準的なＡＰＩを使用して、ネットワーク・データをコールしアクセスすることができる。ＩＰネットワーク・データ全体を衛星パケットにカプセル化することにより、コンテンツを分配する者には広範囲にわたる新たな応用が可能となろう。アプリケーション開発者は、彼らが既に熟知している標準的なインターフェースのためのプログラムを書くので、このようなデータを利用することが容易であることがわかるであろう。
【図面の簡単な説明】
図１は、従来技術のデジタル衛星システム（ＤＳＳ）パケット構造の模式図である。
図２は、衛星伝送システムの模式図である。
図３は、衛星伝送システムを通じてネットワーク・データを送る方法のフロー図である。
図４は、ネットワーク・データを搬送するために用いる、マルチパケット・トランスポート（ＭＰＴ）構造の模式図である。
図５は、衛星伝送可能なＤＳＳパケット内に埋め込んだＭＰＴパケットの模式図である。
図６は、ＭＰＴパケットからのネットワーク・パケットの再組み立てを示す、種々のパケット構造の模式図である。
図７は、目視ユニットにおいて実行中のアプリケーションに対するネットワーク・パケットのデータ・フローを示す、衛星受信／目視ユニット・インターフェースのブロック図である。
好適な実施形態の詳細な説明
図２は、コンテンツ・プロバイダ（content provider）３２（例えば、ケーブル・ヘッドエンド、テレビジョン放送局、インターネット・サービス・プロバイダ等）からの信号を、衛星ネットワーク３８を通じて受信者の住居３４に配信する、衛星伝送システム３０を示す。衛星ネットワーク３８は、コンテンツ・プロバイダ３２に位置する衛星送信機４０を含む。衛星送信機４０は、信号を個々のデジタル・パケットの形態で軌道衛星４２に送信し、この軌道衛星４２がデジタル・パケットを受信者の住居に位置する衛星受信機４４に再送信する。適切な衛星ネットワーク３８の一例は、デジタル衛星システム（ＤＳＳ）ネットワークであり、コンテンツ・プロバイダからのビデオおよびオーディオ信号を、加入者の家庭に位置する個々の衛星受信機に送信する。ＤＳＳネットワークでは、衛星受信機４４は、衛星送信信号を受信可能な小型の１８インチ・パラボラアンテナである。ＤＳＳネットワークは、衛星放送テレビジョン・ショー、ムービー、ゲーム等に対応する。
より一般的には、衛星信号は、ビデオ、オーディオ、アニメーション、テクスチュアル等を含む、多くの異なるデータ型を収容することができる。図示する実現例では、衛星受信機４４から受信者の住居３４にある２つの異なる種類の表示装置の一方に衛星信号を送る。一方の表示装置は、放送イネーブル形パーソナル・コンピュータ５０、または単純に「放送ＰＣ」として具体化したものである。放送ＰＣ５０は、大型ＶＧＡモニタ５２、処理装置５４、ならびにリモート・キーボード５６およびリモート制御ハンドセット５８という形態の入力デバイスを有する。リモート・キーボード５６およびハンドセット５８は、赤外線（ＩＲ）または無線（ＲＦ）のようなワイヤレス・データ・リンクを通じて、離れた所から処理装置５４に結合してある。他のタイプの入力デバイス（例えば、マウス、トラック・ボール、スタイラス等）も、キーボードおよびハンドセットに代わって、またはこれらに加えて使用することができる。
他方の表示装置は、従来のテレビジョン６２に結合したセットトップ・ボックス（set-top box）６０として具体化したものである。リモート制御ハンドセット６４を用いて、ワイヤレス・データ・リンクを通じて離れた所からセットトップ・ボックスおよびテレビジョンを制御する。他の実施形態では、セットトップ・ボックス６０内の機能は、テレビジョン６２に組み込むことができる。
コンテンツ・プロバイダ３２は、信号を固定サイズのデジタル・パケットにパッケージ化するように構成してある。一例として、図１に関して本発明の背景の章で述べたように、ＤＳＳパケットは１４７バイトのサイズを有する。コンテンツ・プロバイダ３２は、ネットワーク・データ・パケットを、衛星システム３８を通じた伝送のためのフォーマットにエンコードするエンコード・ユニットを含む。図示する実現例では、コンテンツ・プロバイダにおけるエンコード・ユニットは、イーサネットまたはインターネットのようなデータ・ネットワーク７２に結合してある、マルチパケット・トランスポート（ＭＰＴ）エンコーダ７０を含む。ＭＰＴエンコーダ７０は、データ・ネットワーク７２からのネットワーク・データ・パケット（例えば、ＴＣＰ／ＩＰパケットまたはＵＤＰ／ＩＰパケット）を受信し、これらをＭＰＴフレーム・フォーマットにラップ（wrap）し、次いでＭＰＴフレームを衛星伝送に適したサイズのＭＰＴパケットに分割する。一例として、ＭＰＴエンコーダは、ネットワーク・ルータとして実施することができる。ＭＰＴフレームおよびパケット構造については、以下で更に詳しく説明する。ＭＰＴパケットを衛星ＭＵＸ（マルチプレクサ）インターフェース７４に渡し、ここで衛星伝送可能なパケットにエンコードする。次に、衛星パケットを衛星送信機４０にアップリンクする。
図３は、衛星伝送システム３０を動作させ、ネットワーク・データを衛星伝送の一部として搬送する方法を示す。この方法について、図２および図４ないし図７を参照しながら説明する。
ステップ１００において、ＭＰＴエンコーダ７０は、データ・ネットワーク７２からネットワーク・データ・パケットを受信する。一例として、ネットワーク・データ・パケットは、インターネット・プロトコル（ＩＰ）パケットの形態とするが、他の形態のパケットも使用可能である。
図４は、ＩＰパケット１２０を示す。これは、可変長（Ｎバイト）データ・ペイロード１２２、固定長（Ａバイト）トランスポート・プロトコル・ヘッダ１２４、および固定長（Ｂバイト）ＩＰヘッダ１２６を有する。データ・ペイロード１２２は、実際のネットワーク・データを収容する。トランスポート・プロトコル・ヘッダ１２４は、データ・ネットワークに対してトランスポート・レイヤ・プロトコルを指定する。トランスポート・プロトコルの例には、伝送制御プロトコル（ＴＣＰ）およびユーザ・データグラム・プロトコル（ＵＤＰ）が含まれる。図４では、ＩＰパケット１２０は、長さが８バイトのＵＤＰヘッダ１２４を有する。ＩＰヘッダ１２６は、データを発信側から宛先に配信するために必要なアドレス指定情報を与える。この例では、ＩＰヘッダ１２６の長さは２０バイトである。
図３のステップ１０２において、ＭＰＴエンコーダ７０は、ネットワーク・データ・パケットを可変長ＭＰＴフレーム１３０にエンコードする。ＭＰＴフレーム１３０は、可変長（Ｍバイト）データ・ブロック即ちデータ・ペイロード１３２、および固定長（Ｃバイト）型のヘッダ１３４を有する。ＩＰパケット１２０全体（双方のヘッダを含む）を、ＭＰＴフレームのデータ・ペイロード１３２に挿入する。実現例の一例として、ヘッダ１３４は２バイトのプロトコル識別子を収容する。これは、ＩＰデータに対して、０ｘ０８００の値を有する。ヘッダ１３４は、プロトコルのオプションを指定するために、オプション・バイトを収容することも可能である。
また、ＭＰＴフレーム１３０は、データ・ペイロード１３２に添付するトレーラ１３６も有することができる。トレーラ１３６は、１つ以上のオプションのパディング・バイト（padding byte）１３６を含み、ＭＰＴフレーム１３０の最後の部分に対するバイト全数を、固定サイズのＭＰＴパケットに挿入するのに適したサイズに変換する。これについては、以下で更に詳しく説明する。また、トレーラ１３６は、更に別の使用のための空間、ならびに実際のデータ・フレーム１３２の長さを指定する長さデータおよびプロトコルのオプションのためのオプション・バイトも指定することができる。
図３のステップ１０４において、ＭＰＴエンコーダ７０は、可変長ＭＰＴフレーム１３０を、１つ以上の固定長ＭＰＴパケット１４０（１），１４０（２），．．．，１４０（ｎ）にエンコードする。図示する実現例では、各ＭＰＴパケット１４０は、１２７バイトで構成する。各ＭＰＴパケット１４０は、パケットの内容にしたがってそのサイズが変化し得るデータ・ブロック１４２と、少なくとも１つのフラグ・ヘッダ１４４とを有する。
エンコードの間、ＭＰＴフレーム１３０をデータ・フラグメントに分解して、ＭＰＴパケット１４０（１），１４０（２），．．．，１４０（ｎ）のデータ・フラグメント・ブロック１４２（１），１４２（２），．．．，１４２（ｎ）を形成する。次いで、フラグ・ヘッダ１４４（１），１４４（２），．．．，１４４（ｎ）を、対応するデータ・フラグメント・ブロック１４２（１），１４２（２），．．．，１４２（ｎ）の先頭に添付する。図示する実現例では、各フラグ・ヘッダ１４４は、１バイトのサイズを有する。フラグ・ヘッダ１４４は、２つのフラグ・ビット１４６、４つの未定義ビット１４８、１つのフレーム開始（ＳＯＦ）ビット１５０、および１つのフレーム終了（ＥＯＦ）ビット１５２を収容する。ＳＯＦビットおよびＥＯＦビットは、フラグ・ヘッダの最下位の２ビットである。
ＳＯＦビット１５０およびＥＯＦビット１５２は、対応するデータ・ブロック１４２内に収容されているＭＰＴフレームからのデータ・フラグメントが、ＭＰＴフレームの開始部分、ＭＰＴフレームの終了部分、またはＭＰＴフレームの中間部分のどれであるかを指定する。より具体的には、対応するデータ・フラグメント１４２がＭＴＰフレーム１３０の開始部分からのものである場合、ＳＯＦビット１５０をセットする。データ・フフラグメント１４２がＭＴＰフレーム１３０の終了部分からのものである場合、ＥＯＦビット１５２をセットする。データ・フラグメントがＭＰＴフレーム１３０の中間部分からのものである場合、ＳＯＦビットおよびＥＯＦビット双方をリセットする。
図４では、ＭＰＴパケット１４０（１）は、先端パケットの一例であり、ＭＰＴフレーム１３０の開始データ・フラグメントを収容する。したがって、ボックス１５４で表すように、ＳＯＦビットを二進「１」にセットし、ＥＯＦを二進「０」にリセットする。最後のＭＰＴパケット１４０（ｎ）は、終端パケットの一例であり、ＭＰＴフレーム１３０の終了データ・フラグメントを収容する。その結果、ボックス１５６で表すように、ＳＯＦビットを二進「０」にリセットし、ＥＯＦを二進「１」にセットする。ＭＰＴパケット１４０（２）は、中間パケットの一例であり、ＭＰＴフレーム１３０の中間のデータ・フラグメントを収容する。したがって、ボックス１５８で表すように、ＳＯＦビットおよびＥＯＦビット双方を二進「０」にリセットする。
先端ＭＰＴパケット１４０（１）では、データ・ブロック１４２（１）の前に、アドレス・ヘッダ１６０を位置付けてある。この実現例の例では、アドレス・ヘッダ１６０は６バイト値で構成してある。これを、既存のサービス・チャンネル識別番号（ＳＣＩＤ）と組み合わせて用いる。これは「サブ−ＳＣＩＤ」として知られている。その結果、先端ＭＰＴパケット１４０（１）は、１バイトのフラグ・ヘッダ１４４（１）、６バイトのアドレス・ヘッダ１６０，および１２０バイトのデータ・ブロック１４２（１）から成る。
最後のＭＰＴパケット１４０（ｎ）は、データ・ブロック１４２（ｎ）の後に配置してあるエラー訂正データを収容する、エラー訂正トレーラ１６２を有する。一例として、エラー訂正トレーラ１６２は、３２ビットＣＲＣ（巡回冗長チェック）値を収容する。これは、その前にあるＭＰＴパケット１４０（１）〜１４０（ｎ）全てについて計算し、破線ボックス１６４内のバイトとして表す。ＣＲＣエラー・チェックは、データ伝送中のエラーをチェックするために用いる手順である。これは複雑な計算を伴い、伝送対象のデータに基づく値を発生する。ＣＲＣ値は、送信機において計算し、送信パケットの一部として添付する。受信機はこの計算を繰り返し、それを添付してあるＣＲＣ値と比較する。受信機の計算および添付のＣＲＣ値が一致した場合、データの伝送にはエラーがないとみなす。ＣＲＣは周知であり、広く用いられている。他のタイプのエラー訂正値も代わりに使用可能であることを注記しておく。
したがって、最後のＭＰＴパケット１４０（ｎ）は、１バイトのフラグ・ヘッダ１４４（ｎ）、１２２バイトのデータ・ブロック１４２（ｎ）、および４バイトのエラー訂正トレーラ１６２から成る。全ての中間ＭＰＴパケット１４０（２），．．．，１４０（ｎ−１）は、１バイトのフラグ・ヘッダ１４４および１２６バイトのデータ・ブロック１４２から成る。
表１は、フラグ・バイト・ヘッダのＳＯＦビットおよびＥＯＦビットの値に応じた、４つの可能なパケット・タイプをまとめたものである。
0003897822.tif 000002
図３のステップ１０６において、衛星ＭＵＸインターフェース７４は、ＭＰＴパケット１４０を、衛星ネットワーク３８を通じた伝送のための固定長衛星パケットに埋め込む。以下に続く説明の目的のために、このステップは、１４７バイトの固定長を有するＤＳＳデータ・パケットとの関連で説明することにする。
図５は、ＭＰＴパケット１４０、および１４７バイトのＤＳＳパケット２０に対するその関係を示す。ＤＳＳパケット２０は、図１に関して説明したパケットと同一である。この実現例では、フラグ・ヘッダ１４４の最初の２つのフラグ・ビット１４６をゼロにセットし、ＤＳＳパケット・フォーマットを表す。１２７バイトのＭＰＴパケット１４０全体を、従来のＤＳＳパケット２０の１２７バイトのデータ・ペイロード２４に挿入する。３バイトのＤＳＳヘッダ２２を、データ・ペイロード２４の先端に添付する。ヘッダ２２は、４つのフラグ・ビット、サービス・チャンネル識別番号（ＳＣＩＤ）のための１２のアドレス・ビット、４つのシーケンス・ビット、および４つの型宣言（type）ビットを収容する。１７バイトのトレーラをデータ・ペイロード２４の終端に添付し、従来技術にしたがって計算したフォワード・エラー訂正（ＦＥＣ）情報を収容する。
ＭＰＴエンコーダ７０は、ハードウェア、ソフトウェア、またはハードウェア／ソフトウェアの組み合わせで実施可能であることを注記しておく。ハードウェアでは、データ・ネットワーク７２から受信したネットワーク・データ・パケットを最初にレジスタに配置する。ヘッダ１３４およびオプションのパディング１３６を追加してＭＰＴフレーム１３０を形成し、これを別のレジスタに格納する。次に、ＭＰＴフレーム１３０を、ＭＰＴエンコーダ７０内のシフト・レジスタに渡す。最初の１２０バイトをシフトアウトし（shift out)、１バイトのフラグ・ヘッダ１４４および６バイトのアドレス・ヘッダ１６０をそれに追加し、先端ＭＰＴパケット１４０（１）を形成する。この先端ＭＰＴパケット１４０（１）を別個のレジスタに格納する。その後、ＭＰＴフレーム１３０から１度に１２６バイトをシフトアウトし、フラグ・ヘッダ１４４を各々に追加し、中間のＭＰＴパケット１４０（２），．．．，１４０（ｎ−１）を形成する。ＭＰＴフレーム１３０の終端に達した場合、最後のデータ・バイトをシフトアウトし、１バイトのフラグ・ヘッダ１４４（ｎ）を追加して、最後のＭＰＴパケット１４０（ｎ）を形成する。次に、種々のレジスタに格納してあるＭＰＴパケット全てを用いて、ＣＲＣ値を計算する。ＣＲＣ値を４バイトのトレーラ１６２として、最後のＭＰＴパケット１４０（ｎ）に添付する。
ソフトウェアの実現例では、ネットワーク・データ・パケットをメモリ内にキャッシュする。ＭＰＴフレーム・ヘッダおよびパディングを、ネットワーク・データ・パケット中で循環させる。次に、ソフトウェアはＭＰＴフレームを適切なサイズのデータ・フラグメントに区分し、フラグ・ヘッダを追加する。アドレス・ヘッダを最初のＭＰＴパケットに追加する。次いで、ソフトウェアは、ＣＲＣ値を計算し、それをトレーラとして最後のＭＰＴパケットに添付する。
図３のステップ１０８において、コンテンツ・プロバイダ３２から衛星ネットワーク３８を通じて受信者の住居３４に衛星パケットを送信する。ＤＳＳパケットを多数のＳＣＩＤで送信し、衛星受信機４４は多数のＳＣＩＤでの受信を同時にサポートする。衛星受信機４４は、ＤＳＳパケットの境界を発見するために、広帯域パケット同期（即ち、衛星ネットワークから受信したデータを処理する技法）をサポートし、ＤＳＳパケットの境界を発見する。
衛星受信機４４が衛星パケットを受信すると（図３のステップ１１０）、最後の１７バイトを用いてＦＥＣ（フォワード・エラー訂正）分析を行い、ＤＳＳパケットが完全であることを確認する。次に、衛星受信機４４は、１４７バイトのＤＳＳパケットの内最初の３バイトにあるＳＣＩＤアドレスを用いて、ＤＳＳパケットのフィルタリングを行う。望ましくないパケットは、排棄する。受け入れ可能なパケットをデコード・ユニットに渡す。デコード・ユニットは、衛星受信機の一部として、好ましくはソフトウェアで実施する。
図６は、衛星受信機内におけるネットワーク・データ・パケットの再組み立て中における中間データ構造、およびイーサネット・プロトコルに準拠したパケットへのデータ構造の変換を示す。最初に、衛星受信機４４は、衛星パケットから１７バイトのＦＥＣトレーラを剥ぎ取り、ＭＰＴパケットを抽出する（ステップ３におけるステップ１１２）。３バイトのＤＳＳパケット・ヘッダ２２は、抽出したＭＰＴパケット１４０’の一部として残しても、残さなくてもよい。ＳＣＩＤアドレスを用いて最初にＤＳＳパケットのグループ化およびフィルタリングを行った後は、３バイトＤＳＳパケット・ヘッダ内に収容されている情報は、無関係となり、したがって欠落させることが可能となる。
ＭＰＴパケット１４０’は、フラグ・ヘッダ１１４（および最初のパケットに対するアドレス・ヘッダ）、ならびにデータ・ブロック１４２内のフラグメント・データを完全に有する。衛星受信機は、先端ＭＰＴパケット内に収容されているサブ−ＳＣＩＤアドレスを用いて、望ましくないＭＰＴパケットのフィルタリングを行う。サブ−ＳＣＩＤアドレスは、４８ビット長であり、ＭＰＴパケット内の４番目ないし９番目のバイトとして位置付ける。アドレスＭＰＴパケットを送信するために用いるＳＣＩＤ全体で、サブ−ＳＣＩＤのアドレスを同期させるが、衛星パケットに対するＳＣＩＤには無関係に、サブ−ＳＣＩＤアドレス上でのフィルタリングを行う。
実施形態の一例では、衛星受信機は、少なくとも１６個の異なるサブ−ＳＣＩＤに対し同時にフィルタリングを行う。望ましくないＭＰＴパケットを破棄しつつ、適切なサブ−ＳＣＩＤアドレスを有するＭＰＴパケットを保持する。できるだけ多くのサブ−ＳＣＩＤに対しフィルタリグを行うことが望ましい。多くの放送データ衛星システムは、３２の異なるサブ−ＳＣＩＤに対しフィルタリングを行うことが可能である。加えて、衛星受信機も、「無差別」モード（promiscuous mode）をサポートしなければならない。この場合、サブ−ＳＣＩＤのフィルタリングを全く行わず、むしろ選択した全てのＳＣＩＤからのパケットを通過させる。効率およびスループットのために、サブ−ＳＣＩＤのアドレスは、１０ｍｓ以内にロードすることができ、単一の動作でディスエーブルおよびイネーブルすることができる。
図３のステップ１１４において、衛星受信機のデコード・ユニットは、多数のＭＰＴパケット１４０’（図６）からのＭＰＴフレーム１３０’を復元する。各ＭＰＴパケットのフラグ・ヘッダを読み取り、それが先端ＭＰＴパケットか（例えば、ＳＯＦ＝１，ＥＯＦ＝１）、中間ＭＰＴパケットか（例えば、ＳＯＦ＝０，ＥＦＯ＝０）、または最終パケットか（例えば、ＳＯＦ＝０，ＥＯＦ＝１）について判定を行う。
以下に示すのは、ＭＰＴパケットが搬送するＩＰデータ・パケットの一例であり、バイト順および出力を例示するものである。以下の例では、データが衛星ネットワークから到達する毎に正確に表し、更に、いかにして１バイトずつメモリに格納するかについても示す。例１は、単一のパケットのＭＰＴフレームに対するものである。
0003897822.tif 000003
最初のバイト「３Ｆ」は、フラグ・ヘッダであり、「Ｆ」値は、ＳＯＦビットおよびＥＯＦビット双方が「１」であることを示す。したがって、このＭＰＴパケットは、アドレス・ヘッダおよびＣＲＣトレーラ双方を有することになる。
例２は、マルチパケットＭＰＴフレームに対するものである。この例では、ＭＰＴフレームは２つのパケットを収容する。
0003897822.tif 000004
最初のパケットのフラグ・ヘッダは「３Ｅ」であり、これは、最下位ビット（即ち、ＥＯＦビット）が「０」であり、最下位から２番目のビット（即ちＳＯＦビット）が「１」であることを示す。このようなＥＯＦビットおよびＳＯＦビットの値は、最初のパケットが先端ＭＰＴパケットであることを示す。２番目のパケットのフラグ・ヘッダ「３Ｄ」は、ＳＯＦ＝０およびＥＯＦ＝１を定め、２番目のパケットが最終ＭＰＴパケットであることを示す。
ＭＰＴパケットは、先端パケットから始まるように配列されているので、衛星受信機は、ＣＲＣ値をコンパイルし始める。マルチパケットＣＲＣを用いて、欠落したパケットを検出し、更にＦＥＣ分析を経てもなお未検出のエラーを含むパケットを検出する。殆どの状況下では、エラーを有するパケットが衛星ネットワークから到達すると、ＦＥＣ分析によって検出し、適切な処置を行う。しかしながら、状況によっては、到達したパケットが含むエラーが余りに多くＦＥＣが訂正できずに、エラーが発生するが、ＦＥＣはエラーを全て訂正したと誤って報告するような場合がある。これは、１／Ｎ！のレートで発生する。ここで、Ｎは訂正可能なバイト数である。ＤＳＳシステムでは、この状態を検出せずに有効なパケットを誤って報告する確立は、２．４８Ｅ−５である。２．０７Ｅ−１７未満という、これよりかなり低いエラー・レートが望ましい。各ＭＰＴフレームに与える３２ビットのＣＲＣ値は、「ビデオ・スレシホルド」における信号条件に適しており、厳格なエラー・レートを達成する。
衛星受信機は、多数のパケットにわたってＣＲＣを累算する。ＣＲＣの算出は、サブ−ＳＣＩＤのフィルタリングとは独立している。最後のＭＰＴパケットが到達するのは、フラグ・ヘッダ内のＥＯＦが「１」にセットされているときである。ＣＲＣは、ＣＲＣ値を含む４バイトのトレーラ１６２を除いて、ＭＰＴフレーム１３０’内の全てのバイトについて累算する。これによって、ＣＲＣ値は、フラグ・ヘッダ、データ・フラグメント、および最初のＭＰＴパケットの６バイトのサブ−ＳＣＩＤアドレスを含む。これは、衛星受信機において受信した各ＤＳＳパケット（最後のＭＰＴパケットを収容する１つを除く）の４番目のバイトないし１３０番目のバイトに対応する。ＣＲＣは、各ＤＳＳパケットから、順番に１バイトずつ累算する。
ＥＯＦ状態を検出した場合、算出したＣＲＣ値を、最後のＭＰＴパケット内にトレーラ１６２として添付してあるＣＲＣ値と比較する。一例として、ＭＰＴパケット内のＣＲＣ値を、ネットワーク・バイト順（Network Byte Order）フォーマットで格納する。これを、「ビッグ・エンディアン」（Big Endian）とも呼ぶ。これが意味するのは、ＣＲＣの最上位バイトはＣＲＣトレーラ１６２の最初のバイト（即ち、ＤＳＳパケットの１２７番目のバイト）に収容されており、ＣＲＣの最下位バイトはＣＲＣトレーラ１６２の最後のバイト（即ち、ＤＳＳパケットの１３０番目のバイト）に収容されているということである。衛星受信機が計算したＣＲＣと、最後のＭＰＴパケットに４バイトのトレーラ１６２として添付してあるＣＲＣとの一致は、無エラー伝送を証明する。
一実現例では、衛星受信機は、ＣＲＣ値を計算する１つのＣＲＣアキュムレータのみをサポートする場合がある。異なるＭＰＴフレームに属する（したがって、異なるサブ−ＳＣＩＤを有する）ＭＰＴパケットのインターリーブは行わない。直前のＭＰＴフレームに対する最後のＭＰＴパケットが到達した後に、次のＭＰＴフレームに対するパケットを取り込む。一方、衛星受信機が多数のＳＣＩＤ上でのＭＰＴパケット受信をサポートするという他の実現例では、各ＣＳＩＤが対応するＣＲＣアキュムレータを有する、即ち、プロセスにおいて受信中の各ＭＰＴパケット毎に１つのアキュムレータを有することも可能である。ＳＣＩＤ間で多数のＭＰＴフレームの開始および停止を同期させる方法が全くない場合もあるので、多数のＣＲＣアキュムレータがあると有用である。
実現例の一例として、ＤＳＳと互換性のある衛星受信機が用いるＣＲＣアルゴリズムは、規格ＩＳＯ／ＩＥＣ１３８１８−１において規定してあるＭＰＥＧ−２トランスポート・ストリームが使用するのと同じＣＲＣアルゴリズムである。このアルゴリズムは、以下の多項式から成る。
１＋Ｄ＋Ｄ2＋Ｄ4＋Ｄ5＋Ｄ7＋Ｄ8＋Ｄ10＋Ｄ11＋Ｄ12＋Ｄ16＋Ｄ22＋Ｄ23＋Ｄ26＋Ｄ32
ＩＳＯ／ＩＥＣ１３８１８−１仕様におけるように、この和の初期状態は、０ｘＦＦＦＦＦＦＦＦである。これは、イーサネットで用いるアルゴリズムと同一ではない。
前述の説明では、ＣＲＣの算出を衛星受信機によって行った。あるいは、ＣＲＣの算出は、視覚表示装置内のプロセッサが行うことも可能である。これについて、以下で更に詳しく説明する。しかしながら、プロセッサを用いてＣＲＣの算出を行うと、使用可能な計算資源を大量に消費する。したがって、ＣＲＣは衛星受信機で行う方が好ましい。
ＣＲＣの分析が良好な場合、図３の次のステップ１１６において、ＭＰＴフレーム１３０’からネットワーク・データ・パケット１２０’を抽出する。更に例を続けると、ＩＰパケット１２０’は、完全なＮバイトのデータ・ペイロード１２２、８バイトのＵＤＰヘッダ１２４、および２０バイトのＩＰヘッダ１２６を有する。ＩＰパケット１２０’がイーサネット・プロトコルに準拠することを保証するために、最初のＭＰＴパケット１４０（１）において見出したサブ−ＳＣＩＤアドレス・ヘッダ１６０を、ＩＰパケットの先頭に、ネットワーク宛先アドレス１７０（例えば、イーサネット宛先アドレス）として配置する。ネットワーク・ソース・アドレス１７２には、固定の有効なソース・アドレス（例えば、イーサネット・ソース・アドレス）を入力する。２バイトのプロトコル１７４には、ＭＰＴパケット１３０’のヘッダ１３４からのプロトコルを、変更せずに入力する。ＥＯＦ条件を満たすまで、ヘッダ１３４からのあらゆるプロトコル・オプションを、ＩＰパケット１２０’および全ての後続のＭＰＴパケットに添付する。
一旦ＥＯＦ条件を満たしたなら、前述のようにＣＲＣをチェックし、比較が成功であった場合、データの真の長さを記録し、シミュレートしたＩＰパケットを視覚表示装置のメモリに書き込み、ＩＰパケットが到達したことを視覚表示装置に通知する。
ネットワーク・データ・パケットを視覚表示装置のプロセッサ内部で再組み立てする場合、別の方法となる。ＭＰＴパケットは、到達した順に主メモリに書き込む。ＭＰＴパケット１４０’全体をメモリに書き込む。処理能力を向上させるために、１２７バイトのＭＰＴパケットのパケット・ストリームを書き出す（write out）のではなく、パケットを１２８バイトのブロックに整合する。最初のバイトは、パディングまたは内部フラグの形態で書き込む。これは、あらゆる内部の目的のために、衛星受信カードが使用することができる。しかしながら、ネットワーク・データの復元の目的のためには、この最初のビットは、「ドント・ケア」とみなされる。残りの１２７バイトは、フラグおよびアドレス・ヘッダ１４４，１６０（最初のパケットの場合、それ以外は、１バイトのフラグ・ヘッダのみ）、およびデータ・フラグメントを保持するデータ・ブロック１４２を含む。メモリ・バッファは、１２８バイトの倍数で構成することが好ましい。ＭＰＴパケットは、４バイトの二重ワード、即ち、「ＤＷＯＲＤ」境界上で整合するように書き込む。ＭＰＴパケットをこのように書き込み、更に予測可能なＤＷＯＲＤ境界上でバイトを整合することにより、共通のプロセッサ上で実行中のソフトウェアは、データを整合しない場合に可能な度合いよりも高い度合いの最適化が可能となる。
視覚表示装置が再組み立てを行う場合でも、衛星受信機がＣＲＣの算出を行うことが好ましい。これが望ましいのは、ビデオ表示装置にこれらの算出を行わせる計算上の負担によるものである。ビデオ表示装置は、時間に厳格なユーザ・インターフェース・タスクおよび他のデータ処理タスクを実行しなければならないので、不要な負担には何であれ気をつけるようにする。
衛星受信機は、ＣＲＣバイトをＣＲＣの算出に含ませ、元のＣＲＣバイトの代わりにその結果を書き込むことによって、ＣＲＣが失敗したか否かについて判定を行う。元のデータについて計算したＣＲＣ値をＣＲＣアルゴリズムを通じて追加の４ビットとして供給する場合、新たなＣＲＣの結果は、成功時にはゼロの値、失敗時には非ゼロの値を有する。
次に、ビデオ表示装置は、衛星受信機と同じ動作を行い、ＩＰパケットに準拠するパケットを作成する。
図７は、衛星受信機およびデコード・ユニットと視覚表示装置においてコンピュータ上で実行するソフトウェア・アプリケーションとの間のインターフェースを示す。衛星受信機ボード２００は、受信したネットワーク・データ・パケットをＰＣバス２０２上に置く。ミニポート・ドライバ（miniport driver）２０４およびレイヤード・ミニポート・ドライバ（layered miniport driver）２０６を結合し、ＰＣバス２０２からのパケットを受け取るようにする。図示の例では、これらのドライバは、インターフェース・レイヤ２０８が表す、Network Device Interface Specification（ＮＤＩＳ：ネットワーク・デバイス・インターフェース仕様）４．０に準拠する。
再組み立てしたネットワーク・データ・パケットをＩＰソフトウェア・インターフェース２１０に渡す。ＩＰソフトウェア・インターフェース２１０は、ネットワーク・データ・パケット・レベルで何らかの基本的なエラー・チェック（例えば、ヘッダのチェックサム）およびフィルタリングを行う。この時点で、ネットワーク・データ・パケットは、ウィンソック・レイヤ（Winsock layer）２０２、即ち、ウィンドウズ・ソケット仕様に準拠したソフトウェア実装インターフェースが処理するためのものになっている。ウィンドウズ・ソケット仕様は、ネットワークに独立してデータの送信および受信を行う、周知の標準的な１組のＡＰＩを定義する。アプリケーション２１４は、ウィンソック・レイヤ２１２によって調整する種々のＡＰＩコールを通じて、ネットワーク・データ・パケットを使用する。
本発明の利点は、ネットワーク・データを衛星システムを通じて伝送し、しかもその公知のフォーマットを失わない技術を規定することにある。受信側のコンピュータ・アプリケーションは、ウィンドウズ・ソケット仕様が規定するような、標準的なＡＰＩを用いてネットワーク・データにアクセスしこれを利用することができる。
本発明の形態は、衛星ネットワーク以外のタイプのネットワークにも使用可能であることを注記しておく。ＭＰＴフレームおよびＭＰＴパケット構造は、イーサネットやインターネットを含む他のネットワークで使用するために変更することができる。
法令にしたがい、構造および方法上の特徴に関して多少具体的な言葉で本発明について説明した。しかしながら、ここに開示した手段に含まれるのは本発明を実施に移す好適な形態であるので、記載した具体的な特徴に本発明を限定する訳ではないことは理解されよう。したがって、本発明は、添付の請求の範囲を均等論にしたがって適切に解釈する適正な範囲内において、その形態または変更の全てにおいてその保護を請求するものである。
【図１】
0003897822.tif 000005
【図２】
0003897822.tif 000006
【図３】
0003897822.tif 000007
【図４】
0003897822.tif 000008
【図５】
0003897822.tif 000009
【図６】
0003897822.tif 000010
【図７】
0003897822.tif 000011