JP3794050B2 - データ伝送装置およびその方法とデータ受信装置 - Google Patents
データ伝送装置およびその方法とデータ受信装置 Download PDFInfo
- Publication number
- JP3794050B2 JP3794050B2 JP5974596A JP5974596A JP3794050B2 JP 3794050 B2 JP3794050 B2 JP 3794050B2 JP 5974596 A JP5974596 A JP 5974596A JP 5974596 A JP5974596 A JP 5974596A JP 3794050 B2 JP3794050 B2 JP 3794050B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- client
- server
- packet
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Radio Transmission System (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、例えば、通信衛星を用いて、マルチメディアデータ配信サービスを行うためのデータ伝送装置およびその方法とデータ受信装置に関する。
【０００２】
【従来の技術】
従来、テレビ放送などの通信衛星を用いたデータ配信サービスでは、データの流れは、データ配信者からユーザへの一方向のみであった。
近年、通信衛星を用いたデジタルデータの伝送が可能になったことで、テレビや映画などのアナログ映像・音声データのみならず、コンピュータなどで利用されるテキストやデジタル映像・音声データについても、通信衛星を用いて伝送されるようになった。
ここで、テレビ放送などの通信衛星を使った従来のデータ配信サービスは、データ配信者が配信したデータを同時に多数のユーザが受信して使用する形態である。これに対して、コンピュータなどで使用されるディジタルデータを、通信衛星を介して配信する場合には、データ配信者から単数または複数の特定のユーザにデータを配信する機能が求められる。
【０００３】
【発明が解決しようとする課題】
しかしながら、通信衛星を用いた従来の伝送方式では、アナログデータの配信であることや、データ配信はデータ配信者からユーザへの一方向のみであることから、伝送上のエラーをチェック機能は備えておらず、データ伝送の信頼性が低いという問題がある。ディジタルデータの配信では、伝送によってデータに１ビットでも誤りが生じると、受信したデータは無意味なものになってしまう。
このようなデジタルのコンピュータデータを無線方式で高品質に配信するためには、データ配信者からユーザへの一方向のデータ配信だけでなく、ユーザからデータ配信者への通信路を確保する必要があるが、従来の伝送方式では、このような機能を備えていない。
【０００４】
また、従来のデータ配信者から多ユーザへの同時通信又は放送システムでは、全ユーザは常に同じ情報を受信して使用または閲覧をしており、システムユーザ個人の識別情報がないため、データ配信者から特定ユーザのみへのデータの配信ができないという問題がある。
【０００５】
本発明は上述した従来技術の問題点に鑑みてなされ、伝送上のエラーを発生させることなく、ディジタルデータを無線方式で伝送できるデータ伝送装置およびその方法を提供することを目的とする。
また、本発明は、特定のクライアントのみに、ディジタルデータを無線方式で伝送できるデータ伝送装置およびその方法とデータ受信装置を提供することを目的とする。
【０００６】
上述した目的を達成するために、第１の発明のデータ伝送装置は、サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とを有し、前記サーバは前記第２のデータ通信経路を介して前記クライアントにデータを伝送するデータ伝送装置であって、インターネットプロトコルに基づいてサーバと通信を行う複数の前記クライアントと、前記インターネットプロトコルに基づいて、前記複数のクライアントと通信を行う前記サーバと、を有し、前記クライアントは、インターネットプロトコルに基づいて、自らのＩＰアドレスを含む要求を前記サーバに送信し、前記サーバは、前記クライアントから受信した前記要求に応じたデータをＩＰパケットに変換し、当該ＩＰパケットを前記要求の送信元の前記クライアントと前記サーバとの間でのみが知る固有の鍵を用いて暗号化し、前記送信元のクライアントの前記ＩＰアドレスを含むＭＡＣ（メディアアクセス制御）ヘッダを生成し、前記暗号化したＩＰパケットに前記ＭＡＣヘッダを付加してＭＡＣフレームを生成し、前記ＭＡＣフレームをブロードキャストし、前記クライアントは、前記サーバから受信した前記ＭＡＣフレームの前記ＭＡＣヘッダ内の前記ＩＰアドレスが当該クライアントの前記ＩＰアドレスと一致すると判断したことを条件に、当該受信したＭＡＣフレーム内のＩＰパケットを、当該クライアントの前記固有の鍵を用いて復号する。
【０００７】
第２の発明のデータ伝送装置は、サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とがある場合に、前記第２のデータ通信経路を介して前記クライアントにデータを伝送する前記サーバとして用いられるデータ伝送装置であって、インターネットプロトコルに基づいて複数のクライアントと通信を行い、前記クライアントから当該クライアントのＩＰアドレスを含む要求を受信する第１のインタフェースと、前記複数のクライアントにデータをブロードキャストする第２のインタフェースと、前記第１のインタフェースが前記クライアントから受信した前記要求に応じたデータをＩＰパケットに変換し、当該ＩＰパケットを前記要求の送信元の前記クライアントと前記サーバとの間でのみが知る固有の鍵を用いて暗号化し、前記送信元のクライアントの前記ＩＰアドレスを含むＭＡＣ（メディアアクセス制御）ヘッダを生成し、前記暗号化したＩＰパケットに前記ＭＡＣヘッダを付加してＭＡＣフレームを生成し、前記第２のインタフェースを介して前記ＭＡＣフレームを前記複数のクライアントにブロードキャストする処理手段と、を有する。
【０００８】
第３の発明のデータ受信装置は、サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とがあり、前記サーバは前記第２のデータ通信経路を介して前記クライアントにインターネットプロトコルに基づいてデータを伝送する場合に、前記クライアントとして用いられるデータ受信装置であって、ブロードキャストされたデータを受信するインタフェースと、前記インターネットプロトコルに基づいて、前記データ受信装置のＩＰアドレスを含む要求を前記サーバに送信し、前記インタフェースが前記サーバから受信したＭＡＣフレームのＭＡＣヘッダ内のＩＰアドレスが前記データ受信装置の前記ＩＰアドレスと一致するか否かを判断し、一致すると前記判断したことを条件に、前記受信したＭＡＣフレーム内のＩＰパケットを、前記データ受信装置の前記固有の鍵を用いて復号する処理手段と、を有する。
【００１０】
【発明の実施の形態】
本発明の実施形態に係わるデータ伝送装置（情報提供システム）およびその方法について説明する。
図１に、マルチメディアのデジタルデータ（映像、音声、テキスト等）を配信するデータサービスを実現するためのデータ伝送装置の概略を示す。
図１に示すデータ伝送装置では、データ提供者Ａはサーバとしてのデータ配信装置４を所有し、ユーザＢはクライアントとしてのデータ受信装置５を所有している。
データ配信装置４およびデータ受信装置５は、双方向の通信が可能なＩＳＤＮ３を介して相互に通信が可能である。また、データ配信装置４から、データ受信装置５へは、通信衛星２を介して、無線方式で大容量の通信が可能である。
【００１１】
図１に示すデータ伝送装置におけるデータの流れを説明する。
ユーザ提供者ＡとユーザＢが、マルチメディアデータの配送の契約を予め結んでいるものとする。この際、ユーザＢのデータ受信装置５にはデータ提供者Ａのデータ配信装置４からデータを受信できる機能が備わっているとする。さらに、データ提供者Ａは、予めユーザＢとの契約が結ばれていることを知っている。
【００１２】
先ず、ユーザＢは、例えば、地上通信網としてのＩＳＤＮ３を介して、データ提供者Ａが提供する所定のサービスを受けたい旨のリクエスト６をデータ提供者Ａに送る。このリエスト６を送る方法は、特に限定されず、データの種類やユーザとの契約状況によって決められ、例えば郵便などでもよい。また、リクエスト６を送らずに、予め契約に従って、データ提供者Ａがサービスを提供してもよい。
【００１３】
データ配信装置４に送られたユーザＢからのリクエスト６は、データリクエスト受付部７で受け取られ、データ管理部９に送られる。
データ管理部９は、ユーザＢの契約情報やリクエスト６が意味のあるものか否かのチェックを行ない、問題が無ければ、データ貯蓄部１１にデータの読み出し要求１０を行なう。データ貯蓄部１１は、データ読み出し要求１０に応じた、例えばマルチメディアデータ１２をデータ作成部１３へ送る。
データ作成部１３では、データ貯蓄部１１からのマルチメディアデータ１２に対してＩＰパケット化、予めユーザＢに対して固有に決められた暗号化、ＭＡＣ（Media Access Control) フレーム化、ＭＰＥＧ(Moving Picutre Experts Group)２のトランスポート化などのデータのフォーマット変換が行なわれる。このデータフォーマット変換についての後述する。
【００１４】
データ貯蓄部１１からのマルチメディアデータ１２は、データ作成部１３によって作成又はフォーマット変換された後、データ１４として通信衛星２に送られる。
通信衛星２を介して送られたデータ１４は、ユーザＢのデータ受信装置５に限らず、データを受信できる状況にある全てのユーザが受信することが可能である。データ受信装置５は、通信衛星２からの全データを受信し、その中から、自分が出したリクエスト６に応じたデータを選別して受け取る。
【００１５】
すなわち、データ受信装置５は、リクエスト６に応じた送信されたデータを含む多数のデータ１４をデータ受信部１６で受信する。データ受信装置５は、その中から、自分宛のデータ、自分が受け取るべきデータ、自分が受けるとることができるデータ（これは契約にもよる）を選別をする。この選別は、データ受信装置５のデータ選択部１８において行われる。尚、予めユーザＢとデータ提供者Ａとの契約によって、ユーザＢが持つデータ受信装置５は決定されている。従って、ユーザＢが持つデータ受信装置５を用いて、他のユーザ宛の特有のデータは選別することができない。
【００１６】
データ選択部１８において、ユーザＢが受け取ることが可能なデータ１９は全てデータ分解部２０に送られる。データ分解部２０に送られたユーザＢ宛のデータは、分解もしくは復号されてマルチメディアデータ２１となり、データ実行部２２へ送られる。
これによってユーザＢのみが、ユーザＢがリクエストしたユーザＢ宛のデータを受取ることができ、このデータサービスが完了する。
尚、リクエストしたデータの受信は、一瞬のうち行われる場合と、長期間にわたって続けられる場合がある。長期間にわたって受信し続ける種類のデータであった場合には、ユーザＢのデータ受信装置５内で、データの受信が引き続き繰り返されることになる。これは、ユーザＢがリクエストしたデータの種類によって状況が変わる。
以上が、本発明によるデータ伝送装置の一連のデータの流れである。
【００１７】
データ配信装置４
次に、データ配信装置４における、配信データのデータフォーマット変換について詳細に説明する。
先ず、図２を参照しながら、データ提供者Ａのデータ配信装置４のデータ作成部１３について説明する。
データ配信装置４内のデータ貯蓄部１１には、ユーザが必要とするマルチメディアデータが何も加工されていないかたちで蓄積されている。データ管理部９から、データの読み出し要求１０がユーザＢから来たことを知らされたデータ貯蓄部１１は、リクエストされたマルチメディアデータ１２およびユーザＢのあて先情報３０を同時にデータ作成部１３内のＩＰパケット作成部３１に送る。ここでユーザＢのあて先情報３０とは、ＩＰパケット送信に必要なＩＰアドレスである。本実施形態に係わるデータ伝送装置は、すべての契約ユーザに固有のＩＰアドレスを割り振ってある。ユーザＢが持つＩＰアドレスは、ユーザＢが確保している間は、ユーザＢ以外のユーザは持たない。
【００１８】
データ貯蓄部１１から送られたユーザＢ宛のマルチメディアデータ１２およびＩＰアドレス３０はＩＰパケット作成部３１に送られる。ＩＰパケット作成部３１では、データ貯蓄部１１から送られてきたマルチメディアデータ１２とその時点でユーザＢを特定するＩＰアドレス３０を用いて、ＩＰパケット３２を生成する。このＩＰパケットの大きさはＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol) で規定され、ユーザＢがリクエストしたマルチメディアデータがその大きさを超える場合には、このマルチメディアデータは複数のＩＰパケットに分割されて次の暗号部３３に転送される。
【００１９】
本実施形態に係わるデータ伝送装置において使用されるＩＰパケット３２のフォーマットを図４に示す。ＩＰパケット内のＩＰヘッダ内の各制御ビットの詳しい説明はここでは省略する。ただし、ＩＰケット内の送信先ＩＰアドレス６１のエリアにはユーザＢのデータ受信装置５が持つＩＰアドレスが入り、送信元ＩＰアドレス６０のエリアにはデータ提供者Ａのデータ配信装置４のＩＰアドレスが入る。さらに、図４内のデータ部５３には図２におけるデータ貯蓄部１１からのマルチメディアデータ１２が入る。
【００２０】
図２に示すＩＰパケット作成部３１で作成されたＩＰパケット３２は、暗号部３３に転送される。
暗号部３３では、ＩＰパケット３２内の送信先ＩＰアドレス６１によって、あて先がユーザＢであることを知り、その時点で既にデータ提供者ＡとユーザＢとの間のみで知りあう秘密鍵によってＩＰパケット全体３２を暗号化する。暗号化方式としては、例えばＤＥＳ(Data Encryption Standard)などが採用される。
ここで、ＩＰパケット３２のヘッダにはユーザＢのみが用いるＩＰアドレスが含まれるのでユーザＢ専用の秘密鍵で暗号化する必要はないように思われるが、これは他人がユーザＢのＩＰアドレスを用いてユーザＢに成り済ましてユーザＢ宛のデータを盗用することを防ぐために必要となる。
【００２１】
ただし、暗号化はユーザＢに対する全てのデータを暗号化するわけではなく、データの種類によっては暗号化が行なわれないこともある。暗号化が行われない場合には、ＩＰパケット作成部３１からＭＡＣフレーム作成部３６に直接ＩＰパケット３２が転送される。本実施形態では、暗号化が行なわれる場合について述べる。暗号化は通常６４ビットの平文に対して行なわれ、暗号化すべきＩＰパケット３２のデータ長が６４ビットの倍数でない場合には、データの埋め合わせ、すなわち、無効データのパッディングを行うことでＩＰパケット全体を６４ビットの倍数にする。
【００２２】
ユーザＢ宛のＩＰパケット３２全体が暗号化されたパケットデータ３５は、ＭＡＣフレーム作成部３６に転送される。ＭＡＣフレーム３７のフォーマットを図５に示す。ＭＡＣフレーム作成部３６では、暗号部３３によって暗号化されたユーザＢ宛のＩＰパケット３５に対して、図５に示す通りのＭＡＣヘッダ１１９を付加する。ＭＡＣヘッダ１１９内の送信先ＩＰアドレス５４はユーザＢが持つＩＰアドレスである。ここで、ＭＡＣヘッダ１１９の送信先ＩＰアドレス５４と、暗号化されたＩＰパケット３５内の送信先ＩＰアドレスとは同じである。このように、ＭＡＣヘッダ１１９を付けるのは、データ受信装置５はデータ受信時において、ＭＡＣヘッダ１１９からのみ送信先ＩＰアドレスを知ることができるためである。すなわち、データ受信装置５は、暗号化されたＩＰパケット３５全体を復号するまでユーザＢは送信先アドレスを見ることができないため、暗号化されたパケット３５のみでは、自分宛のパケットかどうかを識別できない。従って、データ受信装置５が、受信したＩＰパケットを復号する前に、そのＩＰパケットが自分宛のものであることを知るために、ＭＡＣフレームのヘッダに送信先ＩＰアドレス５４がセットされる必要がある。この送信先ＩＰアドレス５４は、ＩＰパケット作成部３１からＭＡＣフレーム作成部３６に直接渡される。
【００２３】
また、図５に示すＭＡＣヘッダ１１９内のＰＢＬ５５はパッディングバイト長であり、暗号化の際に埋め合わせされた無効なデータの長さである。これは、暗号化されたＩＰパケットを受信したユーザが正規なデータ長を知るために必要となる。また、ＣＰ５６は、ＩＰパケットに、ユーザが必要なマルチメディアデータかシステム運用に必要な制御データが入っているかを識別するビットである。通常、ユーザがリクエストした際に受け取るべきＭＡＣフレーム３７のＣＰ５６は、制御データでなくマルチメディアデータが入っていることを示している。ＭＡＣヘッダ１１９内のＥＮ５７は、ＩＰパケットが暗号部３３によって暗号化されたかどうかを示す制御ビットである。このビット情報によってユーザは受信したＭＡＣフレーム３７を復号をするかしないか決定する。図２のＭＡＣフレーム作成部３６では、以上の制御ビットが暗号化された（場合によっては暗号化はされない）ＩＰパケット３５に付加される。
【００２４】
図２のＭＡＣフレーム作成部３６で生成されたＭＡＣフレーム３７は、ＣＲＣ計算部３８に転送される。ＣＲＣ計算部３８では、送れられてきたＭＡＣフレーム３７全バイトのＣＲＣ（Cyclic Redundancy Checking: 巡回冗長検査）の計算を行う。本実施形態では、ＣＲＣは１６ビットである。このようにＣＲＣの計算を行うことで、データ受信装置５は、受信したＭＡＣフレームが正しく通信衛星２から伝送されているかを検査することができる。ＣＲＣ計算部３８において生成された１６ビットのＣＲＣ３８ａは、図３，図５に示すように、ＭＡＣフレーム３７の最後に付加される。
【００２５】
ＣＲＣ３８ａが付加されたＭＡＣフレーム３９は、セクション作成部４０に転送されてＭＰＥＧ２で規定されるセクションに変換される。図３に示すように、ＭＡＣフレーム３９は、セクションヘッダ（ＳｅｃＨｄ）１２０の直後に付加される。セクションヘッダ１２０のフォーマットを図６（Ａ）に示す。図６（Ａ）で示したセクションヘッダ１２０のフォーマットは、ＭＰＥＧ２によって規定され、テーブルｉｄ１００、セクション−シンク−インディケータ１０１、プライベート−インディケータ１０２、リザーブド１０３、プライベート−セクション−レングス１０４を有する。
ここで、プライベート−セクション−レングス１０４には、ＭＡＣフレーム３９のデータ長が入る。
【００２６】
図２に示すセクション作成部４０で作成されたセクション４１は、トランスポートパケット作成部４２に転送される。トランスポートパケット作成部４２では、転送されたセクションフォーマットデータをトランスポートパケット４３に分割して次のデータ転送部４４に転送する。
【００２７】
図３に示すトランスポートパケット４３のパケットヘッダ（ＴＳＨｄ）１２１のフォーマットを図６（Ｂ）に示す。トランスポートパケット４３のヘッダフォーマットはＭＰＥＧ２で規定されている。図６（Ｂ）に示すように、トランスポートパケット４３のパケットヘッダ１２１は、シンクバイト１１０、トランスポート−エラー−インディケータ１１１、ペイロード−ユニット−スタート−インディケータ１１２、トランスポート−プライオリティ１１３、ＰＩＤ１１４、トランスポート−スクランブル−コントロール１１５、アダプテイション−フィールド−コントロール１１６およびコンティニティ−カウンタ１１７を有する。
トランスポートパケット４３の１個分の大きさは１８８バイトと規定されているので、一般的に、一つのセクション４１を複数のトランスポートパケット４３に分割する必要がある。
【００２８】
ここで、通常、一つのセクションは１８４バイト（１８８バイトからヘッダ長の４バイトを引いたバイト数）の整数倍長とは限らないので、一つのセクション４１を複数のトランスポートパケット４３に分割する際に、図３に示すように、スタッフィングと呼ばれるデータ穴埋めを行い、スタッフィング領域５１を形成する。すなわち、１８４バイトの倍数でない一つのセクション４１を複数のトランスポートパケット４３に分割した場合、最後のトランスポートパケット４３の余ったデータエリアに、全てのビット１がスタッフィングされたスタッフィング領域５１を形成する。
【００２９】
このように複数のトランスポートパケット４３に分割されたセクション４１は、データ転送部４４に転送され、マルチプレクサなどのデータ処理部を通った後、通信衛星２に伝送され、ブロードキャストされる。
ブロードキャストされたユーザＢのためのマルチメディアデータは、ユーザＢのデータ受信装置５によって受信され、図２で示した逆の処理がデータ分解部２０によって行なわれ、最終的にリクエストされたマルチメディアデータはユーザＢ３の手元に届くこととなる。
データ受信装置５
【００３０】
図２に示すユーザＢのデータ受信装置５のデータ分解部２０において行なわれる具体的な処理は、基本的には、データ配信装置４のデータ作成部１３におけうアルゴリズムの逆アルゴリズムである。
先ず、図１に示すデータ受信部１６において、通信衛星２を介して受信した図３に示すトランスポートパケット４３を結合してセクション４１を生成する。次に、データ受信部１６は、セクション４１を伸長して、ＭＡＣフレーム３９を生成し、これをデータ選択部１８に出力する。そして、データ選別部１８において、図３に示すＭＡＣフレーム３９のマックヘッダ１１９に含まれる図５に示す送信先ＩＰアドレス５４に基づいて、この送信先ＩＰアドレス５４とデータ受信装置５のＩＰアドレスとが一致するかを判断する。そして、データ選別部１８は、一致するした場合に、当該データを選別し、このデータに含まれる図３に示す暗号化されたＩＰパケット３５を図１に示すデータ１９としてデータ分解部２０に出力する。
【００３１】
データ分解部２０では、データ１９として入力した図３に示す暗号化されたＩＰパケット３５を、予めデータ提供者Ａとの間のみを知りあう秘密鍵を用いて複号した後、データ誤り検査などを行う。ここで、例えば、データ誤りがある場合には、データを復帰させる処理を行うか、あるいは、当該誤りのあるデータを破棄する。
【００３２】
以上説明したように、本実施形態に係わるデータ伝送装置およびその方法とデータ受信装置によれば、ＴＣＰ／ＩＰ通信プロトコルを用いると共に、ＩＰパケットにＣＲＣビットを設けることで、データ配信装置４から通信衛星２を介してデータ受信装置５にディジタルデータを伝送した場合でも、データ伝送エラーが発生することを効果的に抑制し、高品質なディジタルデータ転送を実現できる。
また、本実施形態に係わるデータ伝送装置およびその方法とデータ受信装置によれば、ＩＰパケットをＭＡＣフレーム方式で伝送することで、特定のユーザのみにデータを伝送することができる。
また、本実施形態に係わるデータ伝送装置およびその方法によれば、伝送されるデータは暗号化されており、データ受信装置５のみが、それを復号化する秘密鍵を持っていることから、当該データが他人に盗用されることを効果的に防止できる。
【００３３】
本発明は上述した実施形態には限定されない。例えば、ＭＡＣフレームのデータ圧縮方法は、ＭＰＥＧ２には限定されず、他の圧縮方法を用いてもよい。
また、インターネットプロトコルは、ＴＣＰ／ＩＰには限定されず、例えばＯＳＩ(Open Systems Interconnection)方式を用いてもよい。
さらに、本実施形態では、暗号化方法として、秘密鍵を用いる場合について例示したが、公開鍵を用いても同様な効果を得ることできる。
【００３４】
【発明の効果】
本発明のデータ伝送装置およびその方法とデータ受信装置によれば、無線方式でデータを送信する場合でも、データ伝送エラーが発生することを効果的に抑制し、高品質なディジタルデータ転送を実現できる。
また、本発明のデータ伝送装置およびその方法とデータ受信装置によれば、ＭＡＣフレーム方式を採用することで、ブロードキャスト型のデータ配信のみならず、単数または複数の特定のユーザのみにデータを無線方式で伝送することができる。
また、本発明のデータ伝送装置およびその方法とデータ受信装置によれば、暗号化されたデータを伝送することで、当該データが他人に盗用されることを効果的に防止できる。また、本発明のデータ配信装置およびデータ受信装置を用いることで、上述したような効果を有するデータ伝送装置を実現できる。
【図面の簡単な説明】
【図１】本発明の実施形態に係わるデータ伝送装置の構成図である。
【図２】図１に示すデータ配信装置の構成図である。
【図３】図２に示すデータ配信装置およびデータ受信装置における処理を説明するための図である。
【図４】ＩＰパケットのフォーマットを説明するための図である。
【図５】ＭＡＣフレームのフォーマットを説明するための図である。
【図６】（Ａ）はセクションヘッダ（ＳｅｃＨｄ）のフォーマットを説明するための図であり、（Ｂ）はトランスポートパケットのパケットヘッダ（ＴＳＨｄ）を説明するための図である。
【符号の説明】
２…通信衛星、３…ＩＳＤＮ、４…データ配信装置、５…データ受信装置、６…リクエスト、７…リクエスト受付部、９…データ管理部、１０…データ読み出し要求、１１…データ貯蓄部、１２…マルチメディアデータ、１３…データ作成部、１４…無線方式で伝送するデータ、１６…データ受信部、１８…データ選択部、１９…ユーザＢが受け取ることができるデータ、２０…データ分解部、２１…マルチメディアデータ、２２…データ実行部、３１…ＩＰパケット作成部、３３…暗号部、２６…ＭＡＣフレーム作成部、３８…ＣＲＣ計算部、４０…セクション作成部、４２…トランスポートパケット作成部、４４…データ転送部、３２…ＩＰパケット、３５…暗号化されたＩＰパケット、３９…ＭＡＣフレーム、１２０…セクションヘッダ、１２１…トランスポートパケットヘッダ、４３…トランスポートパケット
【産業上の利用分野】
本発明は、例えば、通信衛星を用いて、マルチメディアデータ配信サービスを行うためのデータ伝送装置およびその方法とデータ受信装置に関する。
【０００２】
【従来の技術】
従来、テレビ放送などの通信衛星を用いたデータ配信サービスでは、データの流れは、データ配信者からユーザへの一方向のみであった。
近年、通信衛星を用いたデジタルデータの伝送が可能になったことで、テレビや映画などのアナログ映像・音声データのみならず、コンピュータなどで利用されるテキストやデジタル映像・音声データについても、通信衛星を用いて伝送されるようになった。
ここで、テレビ放送などの通信衛星を使った従来のデータ配信サービスは、データ配信者が配信したデータを同時に多数のユーザが受信して使用する形態である。これに対して、コンピュータなどで使用されるディジタルデータを、通信衛星を介して配信する場合には、データ配信者から単数または複数の特定のユーザにデータを配信する機能が求められる。
【０００３】
【発明が解決しようとする課題】
しかしながら、通信衛星を用いた従来の伝送方式では、アナログデータの配信であることや、データ配信はデータ配信者からユーザへの一方向のみであることから、伝送上のエラーをチェック機能は備えておらず、データ伝送の信頼性が低いという問題がある。ディジタルデータの配信では、伝送によってデータに１ビットでも誤りが生じると、受信したデータは無意味なものになってしまう。
このようなデジタルのコンピュータデータを無線方式で高品質に配信するためには、データ配信者からユーザへの一方向のデータ配信だけでなく、ユーザからデータ配信者への通信路を確保する必要があるが、従来の伝送方式では、このような機能を備えていない。
【０００４】
また、従来のデータ配信者から多ユーザへの同時通信又は放送システムでは、全ユーザは常に同じ情報を受信して使用または閲覧をしており、システムユーザ個人の識別情報がないため、データ配信者から特定ユーザのみへのデータの配信ができないという問題がある。
【０００５】
本発明は上述した従来技術の問題点に鑑みてなされ、伝送上のエラーを発生させることなく、ディジタルデータを無線方式で伝送できるデータ伝送装置およびその方法を提供することを目的とする。
また、本発明は、特定のクライアントのみに、ディジタルデータを無線方式で伝送できるデータ伝送装置およびその方法とデータ受信装置を提供することを目的とする。
【０００６】
上述した目的を達成するために、第１の発明のデータ伝送装置は、サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とを有し、前記サーバは前記第２のデータ通信経路を介して前記クライアントにデータを伝送するデータ伝送装置であって、インターネットプロトコルに基づいてサーバと通信を行う複数の前記クライアントと、前記インターネットプロトコルに基づいて、前記複数のクライアントと通信を行う前記サーバと、を有し、前記クライアントは、インターネットプロトコルに基づいて、自らのＩＰアドレスを含む要求を前記サーバに送信し、前記サーバは、前記クライアントから受信した前記要求に応じたデータをＩＰパケットに変換し、当該ＩＰパケットを前記要求の送信元の前記クライアントと前記サーバとの間でのみが知る固有の鍵を用いて暗号化し、前記送信元のクライアントの前記ＩＰアドレスを含むＭＡＣ（メディアアクセス制御）ヘッダを生成し、前記暗号化したＩＰパケットに前記ＭＡＣヘッダを付加してＭＡＣフレームを生成し、前記ＭＡＣフレームをブロードキャストし、前記クライアントは、前記サーバから受信した前記ＭＡＣフレームの前記ＭＡＣヘッダ内の前記ＩＰアドレスが当該クライアントの前記ＩＰアドレスと一致すると判断したことを条件に、当該受信したＭＡＣフレーム内のＩＰパケットを、当該クライアントの前記固有の鍵を用いて復号する。
【０００７】
第２の発明のデータ伝送装置は、サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とがある場合に、前記第２のデータ通信経路を介して前記クライアントにデータを伝送する前記サーバとして用いられるデータ伝送装置であって、インターネットプロトコルに基づいて複数のクライアントと通信を行い、前記クライアントから当該クライアントのＩＰアドレスを含む要求を受信する第１のインタフェースと、前記複数のクライアントにデータをブロードキャストする第２のインタフェースと、前記第１のインタフェースが前記クライアントから受信した前記要求に応じたデータをＩＰパケットに変換し、当該ＩＰパケットを前記要求の送信元の前記クライアントと前記サーバとの間でのみが知る固有の鍵を用いて暗号化し、前記送信元のクライアントの前記ＩＰアドレスを含むＭＡＣ（メディアアクセス制御）ヘッダを生成し、前記暗号化したＩＰパケットに前記ＭＡＣヘッダを付加してＭＡＣフレームを生成し、前記第２のインタフェースを介して前記ＭＡＣフレームを前記複数のクライアントにブロードキャストする処理手段と、を有する。
【０００８】
第３の発明のデータ受信装置は、サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とがあり、前記サーバは前記第２のデータ通信経路を介して前記クライアントにインターネットプロトコルに基づいてデータを伝送する場合に、前記クライアントとして用いられるデータ受信装置であって、ブロードキャストされたデータを受信するインタフェースと、前記インターネットプロトコルに基づいて、前記データ受信装置のＩＰアドレスを含む要求を前記サーバに送信し、前記インタフェースが前記サーバから受信したＭＡＣフレームのＭＡＣヘッダ内のＩＰアドレスが前記データ受信装置の前記ＩＰアドレスと一致するか否かを判断し、一致すると前記判断したことを条件に、前記受信したＭＡＣフレーム内のＩＰパケットを、前記データ受信装置の前記固有の鍵を用いて復号する処理手段と、を有する。
【００１０】
【発明の実施の形態】
本発明の実施形態に係わるデータ伝送装置（情報提供システム）およびその方法について説明する。
図１に、マルチメディアのデジタルデータ（映像、音声、テキスト等）を配信するデータサービスを実現するためのデータ伝送装置の概略を示す。
図１に示すデータ伝送装置では、データ提供者Ａはサーバとしてのデータ配信装置４を所有し、ユーザＢはクライアントとしてのデータ受信装置５を所有している。
データ配信装置４およびデータ受信装置５は、双方向の通信が可能なＩＳＤＮ３を介して相互に通信が可能である。また、データ配信装置４から、データ受信装置５へは、通信衛星２を介して、無線方式で大容量の通信が可能である。
【００１１】
図１に示すデータ伝送装置におけるデータの流れを説明する。
ユーザ提供者ＡとユーザＢが、マルチメディアデータの配送の契約を予め結んでいるものとする。この際、ユーザＢのデータ受信装置５にはデータ提供者Ａのデータ配信装置４からデータを受信できる機能が備わっているとする。さらに、データ提供者Ａは、予めユーザＢとの契約が結ばれていることを知っている。
【００１２】
先ず、ユーザＢは、例えば、地上通信網としてのＩＳＤＮ３を介して、データ提供者Ａが提供する所定のサービスを受けたい旨のリクエスト６をデータ提供者Ａに送る。このリエスト６を送る方法は、特に限定されず、データの種類やユーザとの契約状況によって決められ、例えば郵便などでもよい。また、リクエスト６を送らずに、予め契約に従って、データ提供者Ａがサービスを提供してもよい。
【００１３】
データ配信装置４に送られたユーザＢからのリクエスト６は、データリクエスト受付部７で受け取られ、データ管理部９に送られる。
データ管理部９は、ユーザＢの契約情報やリクエスト６が意味のあるものか否かのチェックを行ない、問題が無ければ、データ貯蓄部１１にデータの読み出し要求１０を行なう。データ貯蓄部１１は、データ読み出し要求１０に応じた、例えばマルチメディアデータ１２をデータ作成部１３へ送る。
データ作成部１３では、データ貯蓄部１１からのマルチメディアデータ１２に対してＩＰパケット化、予めユーザＢに対して固有に決められた暗号化、ＭＡＣ（Media Access Control) フレーム化、ＭＰＥＧ(Moving Picutre Experts Group)２のトランスポート化などのデータのフォーマット変換が行なわれる。このデータフォーマット変換についての後述する。
【００１４】
データ貯蓄部１１からのマルチメディアデータ１２は、データ作成部１３によって作成又はフォーマット変換された後、データ１４として通信衛星２に送られる。
通信衛星２を介して送られたデータ１４は、ユーザＢのデータ受信装置５に限らず、データを受信できる状況にある全てのユーザが受信することが可能である。データ受信装置５は、通信衛星２からの全データを受信し、その中から、自分が出したリクエスト６に応じたデータを選別して受け取る。
【００１５】
すなわち、データ受信装置５は、リクエスト６に応じた送信されたデータを含む多数のデータ１４をデータ受信部１６で受信する。データ受信装置５は、その中から、自分宛のデータ、自分が受け取るべきデータ、自分が受けるとることができるデータ（これは契約にもよる）を選別をする。この選別は、データ受信装置５のデータ選択部１８において行われる。尚、予めユーザＢとデータ提供者Ａとの契約によって、ユーザＢが持つデータ受信装置５は決定されている。従って、ユーザＢが持つデータ受信装置５を用いて、他のユーザ宛の特有のデータは選別することができない。
【００１６】
データ選択部１８において、ユーザＢが受け取ることが可能なデータ１９は全てデータ分解部２０に送られる。データ分解部２０に送られたユーザＢ宛のデータは、分解もしくは復号されてマルチメディアデータ２１となり、データ実行部２２へ送られる。
これによってユーザＢのみが、ユーザＢがリクエストしたユーザＢ宛のデータを受取ることができ、このデータサービスが完了する。
尚、リクエストしたデータの受信は、一瞬のうち行われる場合と、長期間にわたって続けられる場合がある。長期間にわたって受信し続ける種類のデータであった場合には、ユーザＢのデータ受信装置５内で、データの受信が引き続き繰り返されることになる。これは、ユーザＢがリクエストしたデータの種類によって状況が変わる。
以上が、本発明によるデータ伝送装置の一連のデータの流れである。
【００１７】
データ配信装置４
次に、データ配信装置４における、配信データのデータフォーマット変換について詳細に説明する。
先ず、図２を参照しながら、データ提供者Ａのデータ配信装置４のデータ作成部１３について説明する。
データ配信装置４内のデータ貯蓄部１１には、ユーザが必要とするマルチメディアデータが何も加工されていないかたちで蓄積されている。データ管理部９から、データの読み出し要求１０がユーザＢから来たことを知らされたデータ貯蓄部１１は、リクエストされたマルチメディアデータ１２およびユーザＢのあて先情報３０を同時にデータ作成部１３内のＩＰパケット作成部３１に送る。ここでユーザＢのあて先情報３０とは、ＩＰパケット送信に必要なＩＰアドレスである。本実施形態に係わるデータ伝送装置は、すべての契約ユーザに固有のＩＰアドレスを割り振ってある。ユーザＢが持つＩＰアドレスは、ユーザＢが確保している間は、ユーザＢ以外のユーザは持たない。
【００１８】
データ貯蓄部１１から送られたユーザＢ宛のマルチメディアデータ１２およびＩＰアドレス３０はＩＰパケット作成部３１に送られる。ＩＰパケット作成部３１では、データ貯蓄部１１から送られてきたマルチメディアデータ１２とその時点でユーザＢを特定するＩＰアドレス３０を用いて、ＩＰパケット３２を生成する。このＩＰパケットの大きさはＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol) で規定され、ユーザＢがリクエストしたマルチメディアデータがその大きさを超える場合には、このマルチメディアデータは複数のＩＰパケットに分割されて次の暗号部３３に転送される。
【００１９】
本実施形態に係わるデータ伝送装置において使用されるＩＰパケット３２のフォーマットを図４に示す。ＩＰパケット内のＩＰヘッダ内の各制御ビットの詳しい説明はここでは省略する。ただし、ＩＰケット内の送信先ＩＰアドレス６１のエリアにはユーザＢのデータ受信装置５が持つＩＰアドレスが入り、送信元ＩＰアドレス６０のエリアにはデータ提供者Ａのデータ配信装置４のＩＰアドレスが入る。さらに、図４内のデータ部５３には図２におけるデータ貯蓄部１１からのマルチメディアデータ１２が入る。
【００２０】
図２に示すＩＰパケット作成部３１で作成されたＩＰパケット３２は、暗号部３３に転送される。
暗号部３３では、ＩＰパケット３２内の送信先ＩＰアドレス６１によって、あて先がユーザＢであることを知り、その時点で既にデータ提供者ＡとユーザＢとの間のみで知りあう秘密鍵によってＩＰパケット全体３２を暗号化する。暗号化方式としては、例えばＤＥＳ(Data Encryption Standard)などが採用される。
ここで、ＩＰパケット３２のヘッダにはユーザＢのみが用いるＩＰアドレスが含まれるのでユーザＢ専用の秘密鍵で暗号化する必要はないように思われるが、これは他人がユーザＢのＩＰアドレスを用いてユーザＢに成り済ましてユーザＢ宛のデータを盗用することを防ぐために必要となる。
【００２１】
ただし、暗号化はユーザＢに対する全てのデータを暗号化するわけではなく、データの種類によっては暗号化が行なわれないこともある。暗号化が行われない場合には、ＩＰパケット作成部３１からＭＡＣフレーム作成部３６に直接ＩＰパケット３２が転送される。本実施形態では、暗号化が行なわれる場合について述べる。暗号化は通常６４ビットの平文に対して行なわれ、暗号化すべきＩＰパケット３２のデータ長が６４ビットの倍数でない場合には、データの埋め合わせ、すなわち、無効データのパッディングを行うことでＩＰパケット全体を６４ビットの倍数にする。
【００２２】
ユーザＢ宛のＩＰパケット３２全体が暗号化されたパケットデータ３５は、ＭＡＣフレーム作成部３６に転送される。ＭＡＣフレーム３７のフォーマットを図５に示す。ＭＡＣフレーム作成部３６では、暗号部３３によって暗号化されたユーザＢ宛のＩＰパケット３５に対して、図５に示す通りのＭＡＣヘッダ１１９を付加する。ＭＡＣヘッダ１１９内の送信先ＩＰアドレス５４はユーザＢが持つＩＰアドレスである。ここで、ＭＡＣヘッダ１１９の送信先ＩＰアドレス５４と、暗号化されたＩＰパケット３５内の送信先ＩＰアドレスとは同じである。このように、ＭＡＣヘッダ１１９を付けるのは、データ受信装置５はデータ受信時において、ＭＡＣヘッダ１１９からのみ送信先ＩＰアドレスを知ることができるためである。すなわち、データ受信装置５は、暗号化されたＩＰパケット３５全体を復号するまでユーザＢは送信先アドレスを見ることができないため、暗号化されたパケット３５のみでは、自分宛のパケットかどうかを識別できない。従って、データ受信装置５が、受信したＩＰパケットを復号する前に、そのＩＰパケットが自分宛のものであることを知るために、ＭＡＣフレームのヘッダに送信先ＩＰアドレス５４がセットされる必要がある。この送信先ＩＰアドレス５４は、ＩＰパケット作成部３１からＭＡＣフレーム作成部３６に直接渡される。
【００２３】
また、図５に示すＭＡＣヘッダ１１９内のＰＢＬ５５はパッディングバイト長であり、暗号化の際に埋め合わせされた無効なデータの長さである。これは、暗号化されたＩＰパケットを受信したユーザが正規なデータ長を知るために必要となる。また、ＣＰ５６は、ＩＰパケットに、ユーザが必要なマルチメディアデータかシステム運用に必要な制御データが入っているかを識別するビットである。通常、ユーザがリクエストした際に受け取るべきＭＡＣフレーム３７のＣＰ５６は、制御データでなくマルチメディアデータが入っていることを示している。ＭＡＣヘッダ１１９内のＥＮ５７は、ＩＰパケットが暗号部３３によって暗号化されたかどうかを示す制御ビットである。このビット情報によってユーザは受信したＭＡＣフレーム３７を復号をするかしないか決定する。図２のＭＡＣフレーム作成部３６では、以上の制御ビットが暗号化された（場合によっては暗号化はされない）ＩＰパケット３５に付加される。
【００２４】
図２のＭＡＣフレーム作成部３６で生成されたＭＡＣフレーム３７は、ＣＲＣ計算部３８に転送される。ＣＲＣ計算部３８では、送れられてきたＭＡＣフレーム３７全バイトのＣＲＣ（Cyclic Redundancy Checking: 巡回冗長検査）の計算を行う。本実施形態では、ＣＲＣは１６ビットである。このようにＣＲＣの計算を行うことで、データ受信装置５は、受信したＭＡＣフレームが正しく通信衛星２から伝送されているかを検査することができる。ＣＲＣ計算部３８において生成された１６ビットのＣＲＣ３８ａは、図３，図５に示すように、ＭＡＣフレーム３７の最後に付加される。
【００２５】
ＣＲＣ３８ａが付加されたＭＡＣフレーム３９は、セクション作成部４０に転送されてＭＰＥＧ２で規定されるセクションに変換される。図３に示すように、ＭＡＣフレーム３９は、セクションヘッダ（ＳｅｃＨｄ）１２０の直後に付加される。セクションヘッダ１２０のフォーマットを図６（Ａ）に示す。図６（Ａ）で示したセクションヘッダ１２０のフォーマットは、ＭＰＥＧ２によって規定され、テーブルｉｄ１００、セクション−シンク−インディケータ１０１、プライベート−インディケータ１０２、リザーブド１０３、プライベート−セクション−レングス１０４を有する。
ここで、プライベート−セクション−レングス１０４には、ＭＡＣフレーム３９のデータ長が入る。
【００２６】
図２に示すセクション作成部４０で作成されたセクション４１は、トランスポートパケット作成部４２に転送される。トランスポートパケット作成部４２では、転送されたセクションフォーマットデータをトランスポートパケット４３に分割して次のデータ転送部４４に転送する。
【００２７】
図３に示すトランスポートパケット４３のパケットヘッダ（ＴＳＨｄ）１２１のフォーマットを図６（Ｂ）に示す。トランスポートパケット４３のヘッダフォーマットはＭＰＥＧ２で規定されている。図６（Ｂ）に示すように、トランスポートパケット４３のパケットヘッダ１２１は、シンクバイト１１０、トランスポート−エラー−インディケータ１１１、ペイロード−ユニット−スタート−インディケータ１１２、トランスポート−プライオリティ１１３、ＰＩＤ１１４、トランスポート−スクランブル−コントロール１１５、アダプテイション−フィールド−コントロール１１６およびコンティニティ−カウンタ１１７を有する。
トランスポートパケット４３の１個分の大きさは１８８バイトと規定されているので、一般的に、一つのセクション４１を複数のトランスポートパケット４３に分割する必要がある。
【００２８】
ここで、通常、一つのセクションは１８４バイト（１８８バイトからヘッダ長の４バイトを引いたバイト数）の整数倍長とは限らないので、一つのセクション４１を複数のトランスポートパケット４３に分割する際に、図３に示すように、スタッフィングと呼ばれるデータ穴埋めを行い、スタッフィング領域５１を形成する。すなわち、１８４バイトの倍数でない一つのセクション４１を複数のトランスポートパケット４３に分割した場合、最後のトランスポートパケット４３の余ったデータエリアに、全てのビット１がスタッフィングされたスタッフィング領域５１を形成する。
【００２９】
このように複数のトランスポートパケット４３に分割されたセクション４１は、データ転送部４４に転送され、マルチプレクサなどのデータ処理部を通った後、通信衛星２に伝送され、ブロードキャストされる。
ブロードキャストされたユーザＢのためのマルチメディアデータは、ユーザＢのデータ受信装置５によって受信され、図２で示した逆の処理がデータ分解部２０によって行なわれ、最終的にリクエストされたマルチメディアデータはユーザＢ３の手元に届くこととなる。
データ受信装置５
【００３０】
図２に示すユーザＢのデータ受信装置５のデータ分解部２０において行なわれる具体的な処理は、基本的には、データ配信装置４のデータ作成部１３におけうアルゴリズムの逆アルゴリズムである。
先ず、図１に示すデータ受信部１６において、通信衛星２を介して受信した図３に示すトランスポートパケット４３を結合してセクション４１を生成する。次に、データ受信部１６は、セクション４１を伸長して、ＭＡＣフレーム３９を生成し、これをデータ選択部１８に出力する。そして、データ選別部１８において、図３に示すＭＡＣフレーム３９のマックヘッダ１１９に含まれる図５に示す送信先ＩＰアドレス５４に基づいて、この送信先ＩＰアドレス５４とデータ受信装置５のＩＰアドレスとが一致するかを判断する。そして、データ選別部１８は、一致するした場合に、当該データを選別し、このデータに含まれる図３に示す暗号化されたＩＰパケット３５を図１に示すデータ１９としてデータ分解部２０に出力する。
【００３１】
データ分解部２０では、データ１９として入力した図３に示す暗号化されたＩＰパケット３５を、予めデータ提供者Ａとの間のみを知りあう秘密鍵を用いて複号した後、データ誤り検査などを行う。ここで、例えば、データ誤りがある場合には、データを復帰させる処理を行うか、あるいは、当該誤りのあるデータを破棄する。
【００３２】
以上説明したように、本実施形態に係わるデータ伝送装置およびその方法とデータ受信装置によれば、ＴＣＰ／ＩＰ通信プロトコルを用いると共に、ＩＰパケットにＣＲＣビットを設けることで、データ配信装置４から通信衛星２を介してデータ受信装置５にディジタルデータを伝送した場合でも、データ伝送エラーが発生することを効果的に抑制し、高品質なディジタルデータ転送を実現できる。
また、本実施形態に係わるデータ伝送装置およびその方法とデータ受信装置によれば、ＩＰパケットをＭＡＣフレーム方式で伝送することで、特定のユーザのみにデータを伝送することができる。
また、本実施形態に係わるデータ伝送装置およびその方法によれば、伝送されるデータは暗号化されており、データ受信装置５のみが、それを復号化する秘密鍵を持っていることから、当該データが他人に盗用されることを効果的に防止できる。
【００３３】
本発明は上述した実施形態には限定されない。例えば、ＭＡＣフレームのデータ圧縮方法は、ＭＰＥＧ２には限定されず、他の圧縮方法を用いてもよい。
また、インターネットプロトコルは、ＴＣＰ／ＩＰには限定されず、例えばＯＳＩ(Open Systems Interconnection)方式を用いてもよい。
さらに、本実施形態では、暗号化方法として、秘密鍵を用いる場合について例示したが、公開鍵を用いても同様な効果を得ることできる。
【００３４】
【発明の効果】
本発明のデータ伝送装置およびその方法とデータ受信装置によれば、無線方式でデータを送信する場合でも、データ伝送エラーが発生することを効果的に抑制し、高品質なディジタルデータ転送を実現できる。
また、本発明のデータ伝送装置およびその方法とデータ受信装置によれば、ＭＡＣフレーム方式を採用することで、ブロードキャスト型のデータ配信のみならず、単数または複数の特定のユーザのみにデータを無線方式で伝送することができる。
また、本発明のデータ伝送装置およびその方法とデータ受信装置によれば、暗号化されたデータを伝送することで、当該データが他人に盗用されることを効果的に防止できる。また、本発明のデータ配信装置およびデータ受信装置を用いることで、上述したような効果を有するデータ伝送装置を実現できる。
【図面の簡単な説明】
【図１】本発明の実施形態に係わるデータ伝送装置の構成図である。
【図２】図１に示すデータ配信装置の構成図である。
【図３】図２に示すデータ配信装置およびデータ受信装置における処理を説明するための図である。
【図４】ＩＰパケットのフォーマットを説明するための図である。
【図５】ＭＡＣフレームのフォーマットを説明するための図である。
【図６】（Ａ）はセクションヘッダ（ＳｅｃＨｄ）のフォーマットを説明するための図であり、（Ｂ）はトランスポートパケットのパケットヘッダ（ＴＳＨｄ）を説明するための図である。
【符号の説明】
２…通信衛星、３…ＩＳＤＮ、４…データ配信装置、５…データ受信装置、６…リクエスト、７…リクエスト受付部、９…データ管理部、１０…データ読み出し要求、１１…データ貯蓄部、１２…マルチメディアデータ、１３…データ作成部、１４…無線方式で伝送するデータ、１６…データ受信部、１８…データ選択部、１９…ユーザＢが受け取ることができるデータ、２０…データ分解部、２１…マルチメディアデータ、２２…データ実行部、３１…ＩＰパケット作成部、３３…暗号部、２６…ＭＡＣフレーム作成部、３８…ＣＲＣ計算部、４０…セクション作成部、４２…トランスポートパケット作成部、４４…データ転送部、３２…ＩＰパケット、３５…暗号化されたＩＰパケット、３９…ＭＡＣフレーム、１２０…セクションヘッダ、１２１…トランスポートパケットヘッダ、４３…トランスポートパケット
Claims (4)
- サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とを有し、前記サーバは前記第２のデータ通信経路を介して前記クライアントにデータを伝送するデータ伝送装置において、
インターネットプロトコルに基づいてサーバと通信を行う複数の前記クライアントと、
前記インターネットプロトコルに基づいて、前記複数のクライアントと通信を行う前記サーバと、
を有し、
前記クライアントは、インターネットプロトコルに基づいて、自らのＩＰアドレスを含む要求を前記サーバに送信し、
前記サーバは、前記クライアントから受信した前記要求に応じたデータをＩＰパケットに変換し、当該ＩＰパケットを前記要求の送信元の前記クライアントと前記サーバとの間でのみが知る固有の鍵を用いて暗号化し、前記送信元のクライアントの前記ＩＰアドレスを含むＭＡＣ（メディアアクセス制御）ヘッダを生成し、前記暗号化したＩＰパケットに前記ＭＡＣヘッダを付加してＭＡＣフレームを生成し、前記ＭＡＣフレームをブロードキャストし、
前記クライアントは、前記サーバから受信した前記ＭＡＣフレームの前記ＭＡＣヘッダ内の前記ＩＰアドレスが当該クライアントの前記ＩＰアドレスと一致すると判断したことを条件に、当該受信したＭＡＣフレーム内のＩＰパケットを、当該クライアントの前記固有の鍵を用いて復号する
データ伝送装置。 - 前記ＭＡＣヘッダには、
前記ＭＡＣフレーム内の前記ＩＰパケットを復号すべき前記クライアントのＩＰアドレスと、
前記ＩＰパケットの暗号化の有無を示す制御ビットと、
前記ＭＡＣフレームが、クライアントからの要求に応じたメディアデータであるか、あるいはシステム運用のための制御データであるかを区別するための制御ビットと、
前記ＩＰパケットを暗号化するのに必要となるデータ長の正規化を行なった際の付加データ長を示すビットと、
が含まれている
請求項１に記載のデータ伝送装置。 - サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とがある場合に、前記第２のデータ通信経路を介して前記クライアントにデータを伝送する前記サーバとして用いられるデータ伝送装置であって、
インターネットプロトコルに基づいて複数のクライアントと通信を行い、前記クライアントから当該クライアントのＩＰアドレスを含む要求を受信する第１のインタフェースと、
前記複数のクライアントにデータをブロードキャストする第２のインタフェースと、
前記第１のインタフェースが前記クライアントから受信した前記要求に応じたデータをＩＰパケットに変換し、当該ＩＰパケットを前記要求の送信元の前記クライアントと前記サーバとの間でのみが知る固有の鍵を用いて暗号化し、前記送信元のクライアントの前記ＩＰアドレスを含むＭＡＣ（メディアアクセス制御）ヘッダを生成し、前記暗号化したＩＰパケットに前記ＭＡＣヘッダを付加してＭＡＣフレームを生成し、前記第２のインタフェースを介して前記ＭＡＣフレームを前記複数のクライアントにブロードキャストする処理手段と、
を有するデータ伝送装置。 - サーバとクライアント間で双方向のデータ伝送が可能な第１のデータ通信経路と、前記サーバからクライアントにデータを無線方式で伝送可能で、前記第１のデータ通信経路に比べて伝送容量が大きな第２のデータ通信経路とがあり、前記サーバは前記第２のデータ通信経路を介して前記クライアントにインターネットプロトコルに基づいてデータを伝送する場合に、前記クライアントとして用いられるデータ受信装置であって、
ブロードキャストされたデータを受信するインタフェースと、
前記インターネットプロトコルに基づいて、前記データ受信装置のＩＰアドレスを含む要求を前記サーバに送信し、前記インタフェースが前記サーバから受信したＭＡＣフレームのＭＡＣヘッダ内のＩＰアドレスが前記データ受信装置の前記ＩＰアドレスと一致するか否かを判断し、一致すると前記判断したことを条件に、前記受信したＭＡＣフレーム内のＩＰパケットを、前記データ受信装置の前記固有の鍵を用いて復号する処理手段と、
を有するデータ受信装置。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP5974596A JP3794050B2 (ja) | 1996-03-15 | 1996-03-15 | データ伝送装置およびその方法とデータ受信装置 |
| US08/952,298 US6373952B2 (en) | 1996-03-15 | 1997-03-17 | Data transmitting apparatus, data transmitting method, data receiving apparatus, data receiving method, data transmission apparatus, and data transmission method |
| PCT/JP1997/000850 WO1997034279A1 (fr) | 1996-03-15 | 1997-03-17 | Appareil transmetteur de donnees, procede de transmission de donnees, recepteur de donnees, procede de reception de donnees, dispositif de transfert de donnees et procede de transfert de donnees |
| KR1019970708232A KR19990014887A (ko) | 1996-03-15 | 1997-03-17 | 데이터 송신 장치, 데이터 송신 방법, 데이터 수신 장치, 데이터 수신 방법, 데이터 전송 장치, 및 데이터 전송 방법 |
| EP97907342A EP0833294A4 (en) | 1996-03-15 | 1997-03-17 | DATA TRANSMITTER, DATA TRANSMISSION METHOD, DATA RECEIVER, DATA RECEIVING METHOD, DATA TRANSFER DEVICE AND METHOD FOR DATA TRANSFER |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP5974596A JP3794050B2 (ja) | 1996-03-15 | 1996-03-15 | データ伝送装置およびその方法とデータ受信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09252320A JPH09252320A (ja) | 1997-09-22 |
| JP3794050B2 true JP3794050B2 (ja) | 2006-07-05 |
Family
ID=13122087
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP5974596A Expired - Fee Related JP3794050B2 (ja) | 1996-03-15 | 1996-03-15 | データ伝送装置およびその方法とデータ受信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3794050B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3077635B2 (ja) | 1997-06-20 | 2000-08-14 | 日本電気株式会社 | 高速無線アクセス装置 |
| KR100292910B1 (ko) * | 1997-12-30 | 2001-06-15 | 김진찬 | 멀티미디어 위성통신 시스템 |
| JP4273535B2 (ja) | 1998-05-12 | 2009-06-03 | ソニー株式会社 | データ伝送制御方法、データ伝送システム、データ受信装置及びデータ送信装置 |
| KR100434379B1 (ko) * | 2001-09-21 | 2004-06-04 | 엘지전자 주식회사 | 블록 암호화 알고리즘을 이용한 인터넷 프로토콜 패킷암호화 장치 및 방법 |
| EP1324541B1 (en) | 2001-12-26 | 2007-09-05 | Kabushiki Kaisha Toshiba | Communication system, wireless communication apparatus, and communication method |
| CN100373941C (zh) * | 2003-10-22 | 2008-03-05 | 深圳市研祥智能科技股份有限公司 | 基于mpeg－1的数字电视广播系统 |
| CA2648107A1 (en) * | 2006-04-24 | 2007-11-08 | Qualcomm Incorporated | Multiplexer to transmitter interface protocol |
| JP2007174639A (ja) * | 2006-12-04 | 2007-07-05 | Sony Corp | データ伝送制御方法 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04274636A (ja) * | 1991-03-01 | 1992-09-30 | Chugoku Nippon Denki Software Kk | ローカルエリアネットワークにおける暗号化方式 |
| JP2581238Y2 (ja) * | 1992-03-31 | 1998-09-21 | 日通工株式会社 | データ伝送装置 |
-
1996
- 1996-03-15 JP JP5974596A patent/JP3794050B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09252320A (ja) | 1997-09-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4190599B2 (ja) | 情報伝送装置及び情報伝送方法並びに情報受信装置及び情報受信方法 | |
| US9300465B2 (en) | Method, system and program product for attaching a title key to encrypted content for synchronized transmission to a recipient | |
| JP3439997B2 (ja) | 複数の番組を送信する方法 | |
| JP3798031B2 (ja) | 個人用プログラムの送受信方法 | |
| US6424714B1 (en) | Method and apparatus for providing conditional access in connection-oriented interactive networks with a multiplicity of service providers | |
| JP4273535B2 (ja) | データ伝送制御方法、データ伝送システム、データ受信装置及びデータ送信装置 | |
| RU2308079C2 (ru) | Система распределения цифрового контента | |
| US6038319A (en) | Security model for sharing in interactive television applications | |
| US20080063195A1 (en) | Method and system for encrypting or decrypting wmv streaming media | |
| US6373952B2 (en) | Data transmitting apparatus, data transmitting method, data receiving apparatus, data receiving method, data transmission apparatus, and data transmission method | |
| JPH08335040A (ja) | 暗号化処理方式 | |
| JP2004504765A (ja) | 安全なパケット・ベースのデータ・ブロードキャスティング・アーキテクチャ | |
| JP2002536877A (ja) | 伝送システム | |
| KR20060002787A (ko) | 컨텐츠 처리 방법, 장치 및 제품 | |
| US20030018917A1 (en) | Method and apparatus for delivering digital media using packetized encryption data | |
| JP2004516748A (ja) | Ｒｔｐヘッダにおける暗号化されたデータに対するポインタ | |
| CA2318452A1 (en) | Method and apparatus for conveying a private message to selected members | |
| JP2001127757A (ja) | データ受信方法及びデータ受信装置 | |
| JP3794050B2 (ja) | データ伝送装置およびその方法とデータ受信装置 | |
| KR20060064469A (ko) | 멀티캐스트 방식으로 스트리밍 서비스되는 동영상 파일의보호 장치 및 그 방법 | |
| US20050047449A1 (en) | Individual video encryption system and method | |
| JP2002536888A (ja) | 伝送システム | |
| JPH10290222A (ja) | 情報復号化装置及び方法並びに情報送受信装置 | |
| JP4569535B2 (ja) | データ配信システム及びサーバ | |
| JP4154753B2 (ja) | データ受信装置及び方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041124 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050121 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050802 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051003 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060322 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060404 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090421 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100421 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100421 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110421 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110421 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120421 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120421 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130421 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |