JPH09266493A - 連続データ配送方法及びシステム - Google Patents

Abstract

(57)【要約】 【課題】 ＡＶ情報のような連続データについて、ネッ
トワークのデータ伝送誤りの劣化や端末での一時的な受
信性能劣化のため、データ損失が起こる場合でも、連続
データを誤りなく、高品質で多数の端末に対して配送す
ることが可能な連続データ配送方法及びシステムを提供
することを目的とする。 【解決手段】 本発明は、サーバにおいて、連続データ
の符号化レートと通信ネットワークの送信速度の差によ
り生じる通信空き時間を利用して、同一ブロックを複数
回端末に送信し、初回のブロック配送で欠落が生じた場
合には、後続のブロックのデータで補う。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、連続データ配送方法及
びシステムに係り、特に、撮影中のＡＶ（Audio-Visua
l）情報や、連続して、あるいは、適当な頻度で入力さ
れ、特定の書式に従って、コード化された文字・数値情
報（以下連続コード情報と呼ぶ）や、大容量データベー
スに格納されたＡＶ情報や連続コード情報を端末に配送
し、即座に再生する連続データの提供を行う連続データ
配送方法及びシステムに関する。

【０００２】また、本発明は、端末において、サーバか
ら受信した受信情報を大容量のデータベースに格納して
再利用するようなシステムにも適用される。

【０００３】

【従来の技術】従来の連続データの配送技術としては、
データの配送時に、単に、サーバから複数の端末に対し
て配送データを送信する方法がある。例えば、インター
ネットのＭＢＯＮＥ実験で行われているものが知られて
いるが、これは、マルチキャスト配送（端末グループへ
の配送）を利用している。この配送方法は、データは、
単に配送のみを行っているため、欠落データへの処理は
行われない。

【０００４】図１６は、従来の複数端末へのデータ配送
シーケンスを示す。同図において、通信に用いられるバ
ッファがブロックバッファである。情報の符号化／復号
化の処理は、エンコーダ／デコーダにおいて、処理が行
われる。さらに、符号化／復号化と通信の処理の間にＡ
Ｐバッファが中間バッファとして設けられる。従来は、
アプリケーションバッファを用いないものもある。

【０００５】図１６において、撮影機やマイクを利用し
たＡＶデータのリアルタイムの撮影が行われると、それ
らのＡＶデータは、エンコードバッファに蓄積され、Ａ
Ｖセグメント化されて、アプリケーションバッファに蓄
積される。これをサーバから端末に配送する場合には、
配送ブロックに分割してブロックバッファに蓄積してお
き、配送時に、ブロック毎に複数の端末に配送される。

【０００６】端末側では、サーバから受信したブロック
をブロックバッファに蓄積し、配送ブロック毎にアプリ
ケーションバッファに蓄積され、デコードを行うことに
より出力機器に再生される。連続コード情報の場合、数
値をグラフ表示する等の処理を施して出力機器に表示さ
れる場合もある。

【０００７】また、従来の方式として、ブロック化せず
に、単に与えられたデータをそのまま逐次配送する方法
もある。ブロック化による配送または、データをそのま
ま転送するいずれの方法においても従来は、通信空き時
間が生じた場合でも利用せずに、データは１回だけ配送
される。

【０００８】なお、パケットは１Ｋbyte程度、ブロック
は、数Ｍbyte、ＡＶセグメントは数百byte程度の大きさ
である。

【０００９】

【発明が解決しようとする課題】しかしながら、上記に
示すように、従来は、ネットワーク上でのデータの伝送
誤りや紛失あるいは、受信端末において、バッファが溢
れた等の理由により、配送データに損失が生じた場合、
端末では、欠落したまま再生されるので、配送情報の品
質が劣化する。端末で受信データをデータベースに格納
する場合も受信した時点では、劣化したままである。

【００１０】従って、上記の従来の方式では、配送デー
タの一部欠落に対して対処できないため、ネットワーク
の品質劣化や端末でのデータ紛失に対して受信情報の品
質が劣化し、高品質の情報再生ができなくなるという問
題がある。本発明は、上記の点に鑑みなされたもので、
情報や連続コード情報のような連続データについて、ネ
ットワークのデータ伝送誤りの劣化や端末での一時的な
受信性能劣化のため、データ損失が起こる場合でも、連
続データを誤りなく、高品質で多数の端末に対して配送
することが可能な連続データ配送方法及びシステムを提
供することを目的とする。

【００１１】

【課題を解決するための手段】本発明は、通信ネットワ
ークを介して、サーバから少なくとも１つの端末に対し
て連続して情報を配送する連続データ配送方法におい
て、サーバにおいて、情報の符号化レートと通信ネット
ワークの送信速度の差により生じる通信空き時間を利用
して、同一ブロックを複数回端末に送信し、初回のブロ
ック配送で欠落が生じた場合には、後続のブロックのデ
ータで補う。

【００１２】図１は、本発明の原理を説明するための図
である。本発明は、サーバにおいて、連続するデータを
シーケンス番号を付与したブロック単位及びブロックを
細分したパケット単位で端末に配送し（ステップ１）、
端末において、サーバから配送された前記ブロック単位
及び前記パケット単位のデータを受信し（ステップ
２）、パケット単位のデータのパケットのシーケンス番
号に基づいて、データパケット単位の受信の成否の記録
を行い（ステップ３）、受信の成否の記録とたった今受
信したパケットのシーケンス番号を照合して、該受信デ
ータパケットが以前に未受信であれば、ブロックバッフ
ァに格納処理し（ステップ４）、該受信データパケット
が受信済みであれば、格納せずに廃棄する（ステップ
４）。

【００１３】また、本発明は、サーバ内に複数のブロッ
クバッファを用意し、外部からの情報を先行して読み込
み、該複数のブロックバッファに格納しておき、端末へ
のブロック配送の空きが生じないように制御する。ま
た、本発明は、端末において、サーバより配送開始通知
を受信した際に、データ配送の一番最初に受信した配送
開始通知に対してのみ、サーバに応答を返却する。

【００１４】図２は、本発明の原理構成図である。本発
明は、通信ネットワークと、該通信ネットワークを介し
て接続されるサーバと、該サーバから該通信ネットワー
クを介して連続してデータを配送される少なくとも一つ
の端末から構成される連続データ配送システムであっ
て、ブロック単位に分割された連続データの配送／受信
を管理するアプリケーション管理手段１１０、３１０
と、ブロックをパケットに分割し、パケット単位で配送
処理する配送処理手段１２０、３２０とを含むサーバ１
００及び端末３００から構成される。

【００１５】また、上記のサーバ１００の配送処理手段
１２０は、連続するデータをシーケンスを付与したブロ
ック単位、及びブロックを細分化したパケット単位で端
末に重複させて配送する重複配送手段１４０を含む。ま
た、上記の端末３００は、シーケンス番号に基づいてデ
ータパケット単位の受信の成否を記録する成否記録手段
３５０と、成否記録手段３５０を参照して、受信したデ
ータパケットが以前に未受信であれば格納処理し、受信
済のデータパケットであれば破棄するパケット格納・破
棄手段３８０を含む。

【００１６】また、上記のサーバ１００の配送処理手段
１２０は、データ配送の一番最初及びブロックの配送の
毎に、次のブロック配送に先だって、配送開始通知パケ
ットを端末に配送する配送開始通知手段１６０と、配送
の完了時に配送完了通知パケットを端末に配送する配送
完了通知手段１５０を含む。

【００１７】また、上記の端末３００の配送処理手段３
２０は、サーバから配送開始通知を受信すると当該配送
開始通知が、データ配送の一番最初の通知であるときの
み、サーバ１００に応答を返却する応答手段３６０を含
む。また、サーバ１００の配送処理手段１２０は、複数
のブロックバッファを有し、アプリケーション管理手段
のアプリケーションバッファからの読み込みを先行し、
該ブロックバッファに格納する第１の先行格納手段を含
む。

【００１８】また、端末３００のアプリケーション管理
手段３１０は、複数のアプリケーションバッファを有
し、配送管理手段３２０のブロックバッファからの読み
込みを先行し、該アプリケーションバッファに格納する
第２の先行格納手段を含む。

【００１９】上記のように本発明は、通信ネットワーク
を介して、サーバから複数の端末に対して連続して情報
を配送する際に、情報の符号化レートと通信ネットワー
クの送信速度の差により生じる通信空き時間を利用し
て、同一ブロックを複数回端末に送信し、初回のブロッ
ク配送で欠落が生じた場合であっても、複数回同一のブ
ロックを送信するため、当該ブロックのデータで補うこ
とができる。

【００２０】また、本発明は、端末側で、サーバより受
信したパケット単位のデータのパケットのシーケンス番
号に基づいてデータパケット単位の受信の成否の記録を
行うことにより、受信の成否の記録を参照して、受信し
たデータパケットが未受信であれば、ブロックバッファ
に格納して受信処理し、当該データパケットが受信済み
であれば、格納せずに廃棄する処理を行うことにより、
確実にブロックの欠落や紛失等を補完することが可能で
ある。特に、パケットシーケンス番号の照会のみでデー
タ格納の判断を行うので、重複受信を行っても余分な格
納領域やメモリ間のデータコピーが不要である。

【００２１】また、本発明は、サーバ内に複数のブロッ
クバッファを用意し、外部からの情報を先行して読み込
み、該複数のブロックバッファに格納しておくことによ
り、端末へのブロック配送の空きが生じない。また、本
発明は、端末において、サーバより配送開始通知を受信
した際に、データ配送の最初の配送開始通知に対しての
み、サーバに応答を返却し、第２ブロック以降の配送開
始通知内の応答は省略し、当該配送開始通知についても
重複して端末に送信することにより、上記と同様に救済
されると共に、データ全体の通信時間を短縮することが
可能となる。

【００２２】また、本発明は、端末において、サーバよ
り配送完了通知を受信した際に、受信の成否の記録を、
サーバに送信することにより、端末側で受信したデータ
に対する課金情報として利用することが可能となる。

【００２３】

【発明の実施の形態】図３は、本発明が適用されるシス
テム構成を示す。同図に示される情報の通信システム
は、サーバ１００には撮影機・マイク１０６から取得し
た情報を符号化するエンコーダ１０７と、符号化された
ＡＶ情報或いは連続コード情報を蓄積するデータベース
１０８が接続される。連続コード情報は、逐次外部から
データベースに格納されていく場合もある。

【００２４】また、各端末３００₁ 、３００₂ 、…、３
００_n には、デコードされた情報を再生出力する出力機
器３０１及びデータベース３０２が接続されている。ま
た、サーバ１００と複数の端末３００₁ 、３００₂ 、
…、３００_n は、有線または、無線の通信ネットワーク
２００に接続され、当該通信ネットワーク２００を介し
てサーバ１００から各端末３００₁ 、３００₂ 、…、３
００_n にデータ配送される。

【００２５】撮影機・マイク１０６で入力された情報
は、エンコーダ１０７で符号化され、サーバ１００に取
り込まれる。情報は、予め大容量のデータベース１０８
に格納されており、そこからサーバ１００に取り込まれ
る場合もある。端末３００側では、サーバ１００から配
送された情報は直ちに、モニタやスピーカ等の出力機器
３０１に出力される。端末３００では、受信情報をデー
タベース３０２に格納する場合もある。以上は、通常の
連続データ配送サービスの利用例である。

【００２６】図４は、本発明のサーバの構成を示す。同
図に示すサーバ１００は、アプリケーション管理部１１
０、配送管理部１２０及び通信制御部１３０より構成さ
れる。アプリケーション管理部１１０は、アプリケーシ
ョンバッファ１１１と、当該アプリケーションバッファ
１１１の連続データをブロックに分割管理するアプリケ
ーション処理部１１２を有する。配送管理部１２０は、
ブロックバッファ１２１と、当該ブロックバッファ１２
１のブロック単位及び細分したパケット単位のデータ転
送を行い、１回のブロック配送が終わる毎に、アプリケ
ーション処理部１１２に次のブロックを要求する配送処
理部１２２を有する。

【００２７】図５は、本発明のサーバの配送処理部の構
成を示す。配送処理部１２２は、パケット管理テーブル
１２２３を含むパケット配送処理部１２２１と配送開始
／終了処理部１２２２より構成される。パケット配送処
理部１２２１は、ブロックをパケット単位で分割配送
し、パケット管理テーブル１２２３において当該配送の
成否を管理する。配送開始／終了処理部１２２２は、パ
ケット配送の開始及び終了について管理する。

【００２８】図６は、本発明のサ−バのパケット管理テ
ーブルの例を示す。同図に示すパケット管理テーブル１
２２３は、各パケット番号毎に、ブロックバッファ１２
１の各パケット位置を管理する。同図に示すようにパケ
ット管理テーブル１２２３は、各パケット毎にシーケン
ス番号（パケット番号）を割当て、各パケット毎にメモ
リ上の格納位置も指定している。プログラム実装上は、
番号対応に固定サイズのパケット格納域を設けるが、メ
モリ上の格納位置まで陽に表現されない場合が多い。

【００２９】図７は、本発明の端末の構成を示す。同図
に示す端末３００は、アプリケーション管理部３１０、
配送管理部３２０、通信制御部３３０及びデコーダ３４
１を有する。アプリケーション管理部３１０は、アプリ
ケーション処理部３１２、アプリケーションバッファ３
１１を有し、配送管理部３２０から渡された情報を取得
し、アプリケーションバッファ３１１に格納する。

【００３０】配送管理部３２０は、配送処理部３２２と
ブロックバッファ３２１を有し、配送処理部３２２は、
通信制御部３３０を介してサーバ１００からブロック単
位及び細分されたパケット単位でデータの受信処理を行
い、ブロック受信完了毎に受信ブロックをアプリケーシ
ョン管理部３１０のアプリケーション処理部３１１に渡
す。

【００３１】デコーダ３４０は、アプリケーション管理
部３１０から渡された符号化された情報をデコードして
デコードバッファ３４１に蓄積すると共に、外部ＡＶ出
力または、データベース３０２に出力する。図８は、本
発明の端末の配送処理部の構成を示す。配送処理部３２
２は、パケット管理テーブル３２２３を含むパケット配
送処理部３２２１と配送開始／終了処理部３２２２を有
する。

【００３２】パケット管理テーブル３２２３は、図９に
示すように、受信したパケット番号毎に、ブロックバッ
ファ３２１の各パケット位置を示し、更に、当該パケッ
ト毎に受信済か未受信かを管理する。このように端末３
００のパケット管理テーブル３２２３は、各パケット毎
に、パケット受信済／未受信を記録するフィールドも、
各パケット毎に持っている。成否は同図では、○×で示
しているが、実装上では、ビットＯＮ（＝１）、或いは
ビットＯＦＦ（＝０）の１ビットで表現される。パケッ
トシーケンス番号は整数であり、１０Ｍbyteブロックを
１Ｋbyte長のパケットに分割した場合、１番から１００
００番までとなる。格納位置の形式は各コンピュータシ
ステムあるいは、テーブルを記述するプログラミング言
語において用いられる通常の形式に従う。

【００３３】次に、上記の構成の一連の概要動作を説明
する。図１０は、本発明の連続配送の一連の動作を説明
するための図である。アプリケーション処理部１１２
は、外部から配送要求を受けると、アプリケーションバ
ッファ１１１のデータをブロックに分割し、配送開始の
通知を端末３００に通知する。

【００３４】端末３００の配送処理部３２２の配送開始
／終了処理部３２２２において、配送開始通知を受ける
と、端末３００の配送管理部３２２は、ブロックバッフ
ァ３２１を用意し、アプリケーション処理部３１２は、
アプリケーションバッファ３１１とブロック管理テーブ
ル３２２３を用意し、受信の準備を行う。

【００３５】サーバ１００のアプリケーション処理部１
１２は、ブロック単位で配送処理部１２２にデータを渡
す。配送処理部１２２では、ブロックバッファ１２１を
用意し、複数回ブロック送信を行う。同図では、この重
複回数を３回の例を示している。

【００３６】端末３００は、通信制御部３３０でデータ
パケットを受信すると、パケット管理テーブル３２２３
を参照して、未受信であれば（当該パケットを初めて受
信した時は）、そのパケットをブロックバッファ３２１
に格納する。もし、既に受信済であれば、当該パケット
は格納せずに、廃棄する。

【００３７】この端末３００の動作により、損失パケッ
トの受信成功率を向上させることができる。また、既受
信パケットは直ちに廃棄するので、余分な格納領域やメ
モリ間のデータコピーが不要である。ネットワークとの
接続処理、パケットの転送処理、並びにパケットのビッ
トエラー誤りの検出及び誤りパケットの廃棄は、サーバ
１００及び端末３００の通信制御部１３０、３３０にお
いて行われる。

【００３８】このように、本発明では、同一ブロックを
複数回（同図では３回）各端末３００に配送する。端末
３００では、ブロックを重複受信する。後述するが、同
じブロックの２回目以降の配送では、未受信パケットの
みブロックバファ３２１に格納し、既受信パケットは直
ちに破棄する。

【００３９】なお、同図では、重複配送が３回の場合を
示しているが、情報の符号化及び復号化レートとネット
ワーク２００で利用できるデータ送信速度の差によっ
て、２回の場合もあるし、さらに、４回以上の場合もあ
る。このように、本発明は、サーバ１００において、ブ
ロック配送後の次の新規のブロック配送の空き時間を重
複配送に利用し、端末３００において、パケットシーケ
ンス番号に基づいて重複受信処理を行うことにより、効
率的な重複データ配送が実現でき、受信データの品質の
向上が図れる。

【００４０】また、複数端末へのマルチキャスト送信
（グループを指定したデータの一斉送信）は、マルチキ
ャスト通信可能なＯＳ（オペレーティングシステム）を
利用することにより実現できる。即ち、サーバ１００及
び端末３００の通信制御部１３０、３３０として、例え
ば、ＵＤＰ（User Datagram Protocol) 及びＩＰ(Inter
net Protocol) のプロトコル処理が可能なＯＳを用いる
ことにより実現できる。特に、ＩＰのグループアドレス
（クラスＤアドレス）の処理が可能なＯＳを利用する。
ＵＤＰの処理では、受信パケットのビット誤りの検出と
ビット誤りパケットの廃棄も含まれる。

【００４１】また、情報の符号化技術として高能率で低
ビットレートの符号化方法ＭＰＥＧ標準化、及びＭＰＥ
Ｇの方法に基づくエンコーダ及びデコーダの製品化（Ｌ
ＳＩ，通信ボード）が進み、一方で、ネットワークもフ
レームリレーやＡＴＭのような高速ネットワーク技術が
利用可能になりつつある。本発明は、このような低ビッ
トレート情報符号化技術と、高速ネットワークを利用す
ることにより生じるデータ配送の空き時間を重複配送に
利用するものである。また、文字・数値情報等の低ビッ
トレートで、符号化できる連続コード情報についても高
速ネットワークを利用することによりより、同様に重複
配送ができる。ここで、情報の復号化も符号化に用いる
エンコーダと同じ復号レートのデコーダを通常用いる。

【００４２】符号化及び復号化レートの例を以下に示
す。 ＭＰＥＧ１：１．５Ｍb/s 程度； ＭＰＥＧ２：６Ｍb/s 程度； ＭＰＥＧ４：６４Ｋb/s 程度； 文字コード：６．４Ｋb/s 程度（４００文字／ｓ，２バ
イトコードの場合）：ネットワークの通信速度の例を以
下に示す。 ＡＴＭ：１５６Ｍb/s ，６２２Ｍb/s ：イーサネットＬ
ＡＮ：１０Ｍb/s ，ＦＤＤＩ−ＬＡＮ：１５０Ｍb/s ：
高速専用線、フレームリレー：１．５Ｍb/s ，６Ｍb/s
等：

【００４３】

【実施例】以下、本発明の実施例を図面と共に説明す
る。まず、図４および図７に示すサーバ１００と端末３
００について説明する。サーバ１００及び端末３００共
に、アプリケーション管理部１３０、３３０にアプリケ
ーションバッファ１１１、３１１を有し、サーバ１００
では、アプリケーション処理部１１２がブロック単位で
配送処理部１２２に配送データを渡す。配送管理部１２
０にブロックバッファ１２１を有し、サーバ１００で
は、配送処理部１２２がブロックバッファのブロックを
データパケットに分割し、通信制御部１３０を介してデ
ータ配送を行う。

【００４４】端末３００では、通信制御部３３０を介し
て受信したデータパケットを配送処理部３２２が受信す
るか廃棄するかの判断を行い、ブロックバッファ３２１
に格納していく。すべてパケットが揃う等の契機で、受
信したデータブロックをアプリケーション処理部３２２
を介してアプリケーションバッファ３１１に格納する。

【００４５】アプリケーションバッファ１１１、３１１
は、ブロックバッファ１２１、３２１以上の大きさを有
する。サーバ１００側では、エンコーダ１０７から渡さ
れたＡＶセグメントを逐次蓄積していき、データ（ＡＶ
セグメント）が蓄積された順にアプリケーション処理部
１１２を介してブロック単位で配送のために消費されて
いく。

【００４６】端末３００側では、サーバの配送処理部１
２２から受け取ったブロックを配送処理部３２２、アプ
リケーション処理部３１２を介して、アプリケーション
バッファ３１１に逐次蓄積し、蓄積された順にＡＶセグ
メント単位で外部出力あるいは、データベース３０２へ
の蓄積のために消費されていく。

【００４７】本実施例では、エンコーダ１０７は、サー
バ１００の外部におき、デコーダ３４０は、端末３００
内部に設けた構成とする。勿論、エンコーダ１０７がサ
ーバ１００との一体構成や、デコーダ３４０が端末３０
０の外部に設けられる構成も可能である。

【００４８】通常エンコーダ１０７の方が処理の負荷が
大きいので、独立した構成をとることが多く、デコーダ
３４０は、製品化が進みＬＳＩやボードとして端末内に
組み込まれる場合が多いので、図７に示す構成としてい
る。サーバ１００から端末３００に対して、配送を開始
する際に、データ配送に先立って、サーバ１００の配送
処理部１２２の配送開始／終了処理部１２２２から配送
開始通知パケットが配送される。

【００４９】図１１は、本発明の一実施例の配送開始通
知パケットの構成を示す。これは、データ配送の一番最
初及びブロックの配送毎に次のブロック配送に先立っ
て、サーバ１００から端末３００に通知される。複数端
末に対しては、効率のためマルチキャストで行うものと
する。２番目以上の配送開始通知パケットは、次のブロ
ック配送開始を端末３００に知らせるために念のために
行うものである。端末３００は、１ブロック分のパケッ
ト受信を完了したときや、１ブロック分受信のタイムア
ウトによっても１回分のブロック配送の完了及び次のブ
ロック受信準備の契機を得ることができる。

【００５０】同図に示す配送開始通知パケット６００に
は、端末宛先６０１、パケットの種別（配送開始通知パ
ケットであること）を示すパケットＩＤ６０２、及び配
送情報６０３から構成される。配送情報６０３には、ブ
ロックサイズ６０５及びブロック配送が何番目を示すブ
ロック番号６０６を含む。

【００５１】ブロック番号６０６の符号長については、
１６ビットで符号化すると、２の１６乗で６５５３６個
まで表現でき、１０Ｍbyteブロックで約６５５．３６Ｇ
byteまで扱うことができる。３２ビットで符号化する
と、２の３２乗で4,294,967,29個まで表現でき、１０Ｍ
byteブロックで約４２９４９．６Ｔbyteまで扱うことが
できる。短い１００Ｋbyteブロックを用いた場合でも、
ブロック番号６０６を１６ビット、３２ビットで符号化
するとそれぞれ約６．５５Ｇbyte、約４２９Ｔbyteまで
のデータ容量を扱うことができ、実用上問題がない。

【００５２】サーバ１００から配送した配送開始通知パ
ケットに対して、確認のため、端末から応答を返しても
らう。但し、配送開始通知パケットは、配送開始及びブ
ロックの先頭配送時に配送するが、端末３００から応答
を返却して貰うのは、配送開始時のみとし、途中の先頭
以外のブロックの配送では、この応答待ちを行わない。
その代わり、通知パケットを重複して転送するため、ネ
ットワーク等での通知パケット紛失に有効である。ブロ
ックサイズも固定値を用いるのであれば、初回の配送開
始通知パケットで通知されたブロックサイズを固定的に
用いる。

【００５３】図１２は、本発明の一実施例のデータパケ
ットのデータ構成を示す。同図に示すデータパケット
は、サーバ１００から端末３００にブロックを分割して
送るパケットである。データパケットＤ００は、端末宛
先Ｄ０１、パケット種別Ｄ０２、パケット番号Ｄ０Ｂ、
パケット番号Ｄ０Ｐ、ユーザデータＤ−３より構成され
る。複数宛先配送の場合は、端末宛先Ｄ０１には、グル
ープアドレスが用いられる。パケット種別Ｄ０２には、
データパケットであることが示される。ブロック番号Ｄ
０Ｂには、図１１に示した配送開始通知パケットのブロ
ック番号（シーケンス番号）が設定される。パケット番
号Ｄ０Ｐには、当該パケットのシーケンス番号が符号化
される。ユーザデータ部Ｄ０３にはブロックを分割した
データが設定される。

【００５４】ここで、ブロック番号を用いているのは、
端末３００で一連のデータパケットを受信中に、当該受
信ブロック以前の既に受信処理が完了しているブロック
のパケットが紛れこんできたとき、このパケットをブロ
ック番号により判断して廃棄するためである。

【００５５】図１３は、本発明の一実施例の配送完了通
知パケットの構成を示す。配送完了通知パケットＦ００
は、端末宛先Ｆ０１と、配送完了通知であることを示す
パケット種別を有する。複数端末への配送の場合には、
端末宛先Ｆ０１にグループアドレスを用いる。

【００５６】以下に図１４及び図１５に基づいて本実施
例のサーバ１００及び端末３００の動作を説明する。図
１４は、本発明の一実施例のサーバの配送手順のフロー
チャートである。 ステップ８０１） サーバ１００の外部からサーバ１０
０のアプリケーション処理部１１２に対してデータ配送
の指示が行われる。このとき、端末３００のグループと
送信すべき連続データが指定される。

【００５７】ステップ８０２） サーバ１００は、配送
開始の準備として、アプリケーション管理部１１０にア
プリケーションバッファ１１１が用意される。サーバ１
００の配送管理部１２０において、ブロックバッファ１
２１及びブロックサイズとパケットサイズに応じて、パ
ケット配送処理部１２２１内のパケット管理テーブル１
２２３が用意される。このブロックバファ１２１は、予
めサーバ１００及び各端末３００の利用可能メモリサイ
ズを考慮した領域がメモリ上に確保されていることを前
提としている。

【００５８】ステップ８０３） アプリケーション処理
部１１２が、配送処理部１２２に配送の開始を指示す
る。これにより、配送開始／終了処理部１２２２が配送
開始通知パケット６００を生成し、端末３００にマルチ
キャストで送信する。 ステップ８０４） 配送開始／終了部１２２２は、配送
開始通知パケットに対する各端末からの応答が揃うのを
待機する。端末３００からの応答が全て揃ったとき、あ
るいは、タイムアウトにより制限時間が到来したとき、
配送を行う端末３００のメンバを確定する。このメンバ
はステップ８０１で指定されたグループの範囲である。
また、この時、サーバ１００は、外部のエンコーダ１０
７に通知し、外部からの情報の入力及び符号化が始ま
る。符号化された連続データは、アプリケーションバッ
ファ１１１へ逐次格納される。

【００５９】ステップ８０５） 配送管理部１２０のブ
ロックバッファ１２１に、アプリケーションバッファ１
１１から１ブロックを取り込む。 ステップ８０６） 配送管理部１２０がブロックバッフ
ァ１２１の１ブロックをパケット分割して配送する。複
数端末に、マルチキャストを利用して通信制御部１３０
を介して配送する。

【００６０】ステップ８０７） 更に、配送管理部１２
０は、同じブロックを規定の回数だけ重複配送する。 ステップ８０８） 引き続いて次のブロック配送がある
かないかを判定する。配送開始／終了処理部１２２２
は、アプリケーション処理部１１２から終了が通知され
るか、タイムアウトにより配送の終了を判定する。終了
の場合には、ステップ８１０に移行し、継続の時はステ
ップ８０９に移行する。

【００６１】ステップ８０９） 継続の場合には、配送
開始／終了処理部１２２２は、ブロック番号をインクリ
メントし、配送開始通知パケット６００を送付し、各端
末に次のブロックの配送が引き続いて行われることを通
知し、ステップ８０５に移行し、次のブロックの配送に
移行する。このとき、最初の通知を行うステップ８０３
の処理と異なり、端末３００からの応答は待機せず、次
の再送に直ぐ移行することにより、次のブロック再送ま
での時間を短縮する。この場合、配送開始通知パケット
は複数個、各端末に送付することにより、ネットワーク
上等での通知パケットの紛失に対して対処することがで
きる。

【００６２】ステップ８１０） 次のブロックの配送開
始指示終了の場合には、配送開始／終了処理部１２２２
は、配送終了通知パケットＦ００を生成し、端末３００
に配送する。複数端末の場合には、マルチキャストを用
いて配送する。ここで、各端末３００からの応答の手順
を設けることにより、各端末３００の受信の成否が記録
できる。この記録は、情報配送に対する課金を行う場合
に管理上有効である。勿論、サーバ１００から端末３０
０への通知のみで、端末３００から応答を行わない手順
を実装することもあり得る。応答を全て受けるか、タイ
ムアウトとなった場合には、処理を終了する。

【００６３】以上の処理は、１つのブロックバッファ１
２１が設けられている例を用いて説明したが、複数のブ
ロックバッファを用意し、アプリケーションバッファ１
１１から予備のブロックバッファ１２１への読み込みを
先行して行うことも可能である。これによりステップ８
０５の処理のために送信の空きが生じないように制御す
ることが可能である。

【００６４】次に、サーバ１００の配送手順に対応する
端末３００の手順を説明する。図１５は、本発明の一実
施例の端末の配送処理手順のフローチャートである。 ステップ９０１） 端末３００は、配送処理部３２２の
配送開始／終了処理部３２２２において、サーバ１００
から配送された配送開始通知パケット６００を受信する
と、アプリケーション処理部３１２に通知する。

【００６５】ステップ９０２） アプリケーション処理
部３１２では、配送開始通知を受けると、アプリケーシ
ョンバッファ３１１を用意し、デコーダ３４０及び外部
の出力装置３０１や、データベース３０２に準備を確認
する。配送管理部３２０では、配送情報６０３のブロッ
クダイズのブロックバッファ３２１とパケット管理テー
ブル３２２３を用意する。パケット管理テーブル３２２
３は、ブロックサイズとパケットサイズにより決まる。
本実施例では、ブロックサイズは配送開始通知パケット
６００により通知され、パケットサイズはシステムで予
め決められていることを想定している。

【００６６】ステップ９０３） 端末３００の配送処理
部３２２は、配送開始通知に対する応答をサーバ１００
に返却する。。 ステップ９０７） 配送開始通知を受信してから、パケ
ット受信待ち状態となる。データパケットを受信する
と、ステップ９１０のデータパケット１個の受信処理に
移行する。１ブロックのパケットが全て揃うか、配送開
始通知パケットを受信するかデータパケット待ちのまま
タイムアウトするとステップ９２０に移行する。

【００６７】ステップ９１０） １個のデータパケット
の格納／廃棄処理を以下のステップ９１１、９１２、９
１３で説明する。当該ステップでは、各ブロックの配送
において、重複した２個目以降の重複ブロックに対して
のみ行い、１個目のブロックは全て受信処理することに
より、パケット管理テーブル３２２３の照合の処理を重
複しない初回のブロックに対して省くこともできる。こ
の場合は、１個のデータパケットには、２個目以降との
区別のための１ビットのフィールドをパケット構成に設
けておけてばよい。

【００６８】ステップ９１１） 受信した１パケットの
パケット番号をキーとしてパケット管理テーブル３２２
３の当該パケットが未受信であるか（今回始めて受信し
たか）を判定する。未受信である場合には、ステップ９
１２に移行し、既に受信している場合には、ステップ９
１３に移行する。また、このとき、パケットのブロック
番号もチェックし、古いブロック番号のパケットが紛れ
込んできたときにはステップ９１３に移行する。

【００６９】ステップ９１２） 未受信であれば、受信
パケットをブロックバッファ３２１に格納し、パケット
管理テーブル３２２３に当該パケットが受信済を示す○
を期す。 ステップ９１３） 既に受信済または、古いブロック番
号のパケットが紛れ込んできたときには廃棄する。

【００７０】ステップ９１４） 配送開始／終了処理部
３２２２は、ブロックのパケットが全て揃うか、配送開
始を受信するか、タイムアウトかを判定する。 ステップ９１５） ステップ９１４にいおいて、いずれ
かの終了条件を満たしたとき、１ブロックをアプリケー
ションバッファ３１１に渡す。アプリケーションバッフ
ァ３１１に適当にブロック数が蓄積されたとき、デコー
ダ３４０は、復号化及び外部のＡＶ出力機器３０１やデ
ータベース３０２に出力していく。特に、複数ブロック
数蓄積するのは、ＡＶ機器３０１に出力する場合に、ブ
ロックがなくなって出力の途切れを生じさせないように
するためである。具体的な値は、アプリケーションバッ
ファ３１１のサイズと入力から出力までの許される遅延
等に依存する。次のブロックバッファを用意し、パケッ
ト管理テーブル３２２３をリセットする（パケットは全
て未受信と記録する）。

【００７１】ここでは、ブロックバッファ１個の場合を
説明したが、ブロックバッファを複数個用意することに
より、引続き行われる次のブロック受信に予備のバッフ
ァで対処することができる。これにより、ＡＰバッファ
にブロックを渡す処理が受信処理のネックになることを
回避できる。

【００７２】ステップ９１６） 配送終了通知を受信し
た場合には、ステップ９１８に移行し、未受信の場合
は、ステップ９１７に移行する。 ステップ９１７） 配送開始通知待ちとなる。配送開始
通知を受信するかタイムアウトすると、ステップ９０７
に移行し、次のブロックのデータパケット受信待ちとな
る。配送開始通知は複数個の場合もあるが、１個でも受
信するとステップ９０７に移行する。

【００７３】ここで配送開始通知がネットワーク２００
上等で紛失すると、次のブロックの配送がいきなり始ま
るが、ステップ９１５において既に準備されているた
め、次のブロックの受信は可能である。また、ステップ
９１５の前で既に配送開始通知を受け取っている場合に
は、当該ステップ９１７の処理は行わない。

【００７４】ステップ９１８） 配送開始通知に対する
応答パケットをサーバに返し、受信終了する。この処理
は、端末３００からの応答に基づいてサーバ１００が各
端末３００に情報配送の成否を管理する場合に用いる。
この応答を省略するような実装方法もある。

【００７５】なお、本発明は、上記の実施例に限定され
ることなく、特許請求の範囲内で種々変更・応用が可能
である。

【００７６】

【発明の効果】上述のように本発明の連続データ配送方
法及びシステムによれば、情報のような連続データにつ
いて、パケット単位のデータ受信の成否の記録を行うこ
とにより、重複データ配送を効率的に実現できる。特
に、パケットシーケンス番号の照合のみで、受信パケッ
トの格納実行の判断を行うので、余分な格納領域やメモ
リ間のデータコピーが不要であり、効率的である。これ
により、ネットワークのデータ伝送誤りの劣化や端末で
の一時的な受信性能劣化のため、データ損失が起きる場
合でも、連続データを誤りなく高品質で多数の端末に対
して配送することができる。

【００７７】本発明は、再送を行わないので、衛星を利
用したデータ配送や、数万キロに及ぶ超長距離配送等の
ように伝送遅延が大きい場合に特に適用領域がある。

【図面の簡単な説明】

【図１】本発明の原理を説明するための図である。

【図２】本発明の原理構成図である。

【図３】本発明が適用されるシステム構成図である。

【図４】本発明のサーバの構成図である。

【図５】本発明のサーバの配送処理部の構成図である。

【図６】本発明のサーバのパケット管理テーブルの例で
ある。

【図７】本発明の端末の構成図である。

【図８】本発明の端末の配送処理部の構成図である。

【図９】本発明の各端末のパケット管理テーブルの例で
ある。

【図１０】本発明の連続配送の一連の動作を説明するた
めの図である。

【図１１】本発明の一実施例のデータパケットのデータ
構成図である。

【図１２】本発明の一実施例のデータパケットのデータ
構成図である。

【図１３】本発明の一実施例の配送終了通知パケットの
データ構成図である。

【図１４】本発明の一実施例のサーバの配送手順のフロ
ーチャートである。

【図１５】本発明の一実施例の端末の配送手順のフロー
チャートである。

【図１６】従来の複数端末へのデータ配送シーケンスで
ある。

【符号の説明】

１００ サーバ １０６ 撮影機・マイク １０７ エンコーダ １０８ データベース １１０ アプリケーション管理部、アプリケーション管
理手段 １１１ アプリケーションバッファ １１２ アプリケーション処理部 １２０ 配送管理部、配送処理手段 １２１ ブロックバッファ １２２ 配送処理部 １３０ 通信制御部 １４０ 重複配送手段 １５０ 配送完了通知手段 １６０ 配送開始通知手段 ２００ 通信ネットワーク ３００ 端末 ３０１ ＡＶ出力機器 ３０２ データベース ３１０ アプリケーション管理部、アプリケーション管
理手段 ３１１ アプリケーションバッファ ３１２ アプリケーション処理部 ３２０ 配送管理部 ３２１ ブロックバッファ ３２２ 配送処理部 ３３０ 通信制御部 ３４０ デコーダ ３４１ デコードバッファ ３５０ 成否記録手段 ３６０ 応答手段 ３８０ パケット格納・破棄手段 ６００ 配送開始通知パケット ６０１ 端末宛先 ６０２ パケット種別 ６０３ 配送情報 ６０５ ブロックサイズ ６０６ ブロック番号 １２２１ パケット配送処理部 １２２２ 配送開始終了処理部 １２２３ パケット管理テーブル ３２２１ パケット配送処理部 ３２２２ 配送開始／終了処理部 ３２２３ パケット管理テーブル Ｄ００ データパケット Ｄ０１ 端末宛先 Ｄ０２ パケット種別 Ｄ０Ｂ ブロック番号 Ｄ０Ｐ パケット番号 Ｄ０３ ユーザデータ Ｆ００ 配送終了通知パケット Ｆ０１ 端末宛先 Ｆ０２ パケット種別

Claims (11)

【特許請求の範囲】
1. 【請求項１】 通信ネットワークを介して、サーバから
   少なくとも１つの端末に対して連続して情報を配送する
   連続データ配送方法において、 前記サーバにおいて、 前記情報の符号化レートと前記通信ネットワークの送信
   速度の差により生じる通信空き時間を利用して、同一ブ
   ロックを複数回端末に送信し、 初回のブロック配送で欠落が生じた場合には、後続のブ
   ロックのデータで補うことを特徴とする連続データ配送
   方法。
2. 【請求項２】 前記サーバにおいて、 連続するデータをシーケンス番号を付与したブロック単
   位及びブロックを細分したパケット単位で前記端末に配
   送し、 前記端末において、 前記サーバから配送された前記ブロック単位及び前記パ
   ケット単位のデータを受信し、 前記パケット単位のデータのパケットのシーケンス番号
   に基づいて、データパケット単位の受信の成否の記録を
   行い、 前記受信の成否の記録とたった今受信したパケットのシ
   ーケンス番号を照合して、該受信データパケットが以前
   に未受信であれば、ブロックバッファに格納処理し、 該受信データパケットが受信済みであれば、格納せずに
   廃棄することを特徴とする連続データ配送方法。
3. 【請求項３】 前記サーバ内に複数のブロックバッファ
   を用意し、外部からの前記情報を先行して読み込み、該
   複数のブロックバッファに格納しておき、 前記端末へのブロック配送の空きが生じないように制御
   する請求項１または２記載の連続データ配送方法。
4. 【請求項４】 前記端末において、 前記サーバより配送開始通知を受信した際に、 データ配送の一番最初に受信した配送開始通知に対して
   のみ、前記サーバに応答を返却する請求項２記載の連続
   データ配送方法。
5. 【請求項５】 通信ネットワークと、該通信ネットワー
   クを介して接続されるサーバと、該サーバから該通信ネ
   ットワークを介して連続してデータを配送される少なく
   とも一つの端末から構成される連続データ配送システム
   であって、 ブロック単位に分割された連続データの配送／受信を管
   理するアプリケーション管理手段と、 前記ブロックをパケットに分割し、パケット単位で配送
   処理する配送処理手段とを含むサーバ及び端末から構成
   されることを特徴とする連続データ配送システム。
6. 【請求項６】 前記サーバの配送処理手段は、 連続するデータをシーケンスを付与したブロック単位、
   及びブロックを細分化したパケット単位で端末に重複さ
   せて配送する重複配送手段を含む請求項５記載の連続デ
   ータ配送システム。
7. 【請求項７】 前記端末は、 前記シーケンス番号に基づいてデータパケット単位の受
   信の成否を記録する成否記録手段と、 前記成否記録手段を参照して、受信したデータパケット
   が以前に未受信であれば、格納処理し、受信済のデータ
   パケットであれば破棄するパケット格納・破棄手段を含
   む請求項５記載の連続データ配送システム。
8. 【請求項８】 前記サーバの配送処理手段は、 データ配送の一番最初及びブロックの配送の毎に、次の
   ブロック配送に先だって、配送開始通知パケットを前記
   端末に配送する配送開始通知手段と、 配送の完了時に配送完了通知パケットを前記端末に配送
   する配送完了通知手段を含む請求項５記載の連続データ
   配送システム。
9. 【請求項９】 前記端末の配送処理手段は、 前記サーバから前記配送開始通知を受信すると当該配送
   開始通知が、データ配送の一番最初の通知であるときの
   み、前記サーバに応答を返却する応答手段を含む請求項
   ５及び７記載の連続データ配送システム。
10. 【請求項１０】 前記サーバの前記配送処理手段は、 複数のブロックバッファを有し、前記アプリケーション
    管理手段のアプリケーションバッファからの読み込みを
    先行し、該ブロックバッファに格納する第１の先行格納
    手段を含む請求項５記載の連続データ配送システム。
11. 【請求項１１】 前記端末の前記アプリケーション管理
    手段は、 複数のアプリケーションバッファを有し、前記配送管理
    手段のブロックバッファからの読み込みを先行し、該ア
    プリケーションバッファに格納する第２の先行格納手段
    を含む請求項５記載の連続データ配送システム。