JP2002124992A

JP2002124992A - マルチキャストによるデータファイル配信方法

Info

Publication number: JP2002124992A
Application number: JP2001228075A
Authority: JP
Inventors: Kazuyuki Eguchi; 和幸江口; Masami Ishikura; 雅己石倉
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2000-08-10
Filing date: 2001-07-27
Publication date: 2002-04-26
Also published as: US6941501B2; US20020038441A1; CA2355005A1

Abstract

(57)【要約】【課題】上り方向に多重アクセスにより共有する衛星回
線のような無線伝送回線を使用する通信系においても、
高信頼のマルチキャストによるデータファイル配信を効
率よく実行可能なマルチトャストによるファイル配信方
法を提供する。【解決手段】マルチキャストによるデータファイル配信
方法であって、複数のブロックからなるデータファイル
を各配信先に送出するステップと、該データファイルの
該配信が終了した後に、前記配信先において受け取った
該複数のブロックからなるデータファイルに誤りのデー
タ配信パケットが認められたときに、該誤りのデータ配
信パケットを再送要求するステップと、を含み、該再送
要求は、該誤りのデータ配信パケットのオフセット位置
と該誤りのデータのデータ長を表すように定められてい
ることを特徴とする構成を有している。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、指定したファイル
を多地点に対してマルチキャストにより配信する方法に
関するものであり、特に、衛星回線などの無線リンクを
用いて、指定したファイルを多地点に対してマルチキャ
ストにより配信する方法に関するものである。

【０００２】

【従来の技術】この種の従来技術として配信するファイ
ルを複数のブロックに分割して送信局よりマルチキャス
トに送信し、クライアント側の受信局から、受信できな
かった誤りＤＴＵ（Data Transmission Unit）を再送要
求して、その再送要求のあったＤＴＵを送信側から再送
することにより、ファイル転送を完結するＭＦＴＰ（Mu
lticast File Transmission Protocal）方式が提案され
ている（特表平１０−５１２７２６号公報参照）。

【０００３】図２８（ａ）は、このＭＦＴＰ方式による
データ配信パケットフォーマットを示しており、ファイ
ルはブロック＃１，ブロック＃２，ブロック＃３，ブロ
ック＃４よりなる場合であり、各ブロックはフレーム＃
１１〜フレーム＃１Ｎよりなり、各フレームはＭＦＴＰ
方式の送受プロセッサ間での通信に用いるＯＨ（オーバ
ヘッド：overhead) であるＭＦＴＰ−ＯＨとオプション
で用いるＭＦＴＰ−ＯＨ（オプション）を含んでいる。
このＭＦＴＰ−ＯＨ（オプション）を含む各フレーム
が、１ＤＴＵを構成しており、この１ＤＴＵとＭＦＴＰ
−ＯＨの他にさらにＵＤＰ（User Datagram Protocol)
−ＯＨ、および、ＩＰ（インターネット・プロトコル：
Internet Protocol)用のＯＨであるＩＰ−ＯＨを含んで
１ＭＴＵ (Multicast Transmission Unit)が構成されて
いる。さらに、図２８（ｂ）はＭＦＴＰ方式による再送
要求パケットフォーマットであり、１ＤＴＵ中の各ビッ
ト毎に受信状態を表示している。この例では、×印は未
受信を示している。

【０００4 】

【発明が解決しようとする課題】この従来技術によるＭ
ＦＴＰ方式では、配信ファイルのマルチキャストによる
送信中に、再送信を要求するＤＴＵの指示を含む応答確
認を複数の受信局から受け取る方法を採っている。ま
た、ＭＦＴＰ方式では、データ誤りをビットマップで表
現しているので、たとえ１ＤＴＵの誤りであっても、１
ブロックに相当するビットマップ〔通常１ＭＴＵ（＝１
５００バイト）のサイズ〕から成る再送要求パケットを
受信局から送信局に返送する必要がある。ＭＦＴＰ方式
では、複数の受信局から送信局の方向（「上り方向」と
も称する）に各々電話回線のように占有的な回線を確保
する通信系において実施するものであるが、再送要求パ
ケットが離散的に送信され、かつその総量が大きくなる
ため、上り方向に多重アクセスにより共有する衛星回線
のような無線伝送回線を使用する通信系においては、効
率的な誤り再送処理を行ううえで、大きな制約と欠点を
有している。

【０００５】本発明は、上り方向に多重アクセスにより
共有する衛星回線のような無線伝送回線を使用する通信
系においても、高信頼のマルチキャストによるデータフ
ァイル配信を効率よく実行可能なマルチトャストによる
ファイル配信方法を提供するものである。

【０００６】

【課題を解決するための手段】この目的達成するため
に、本発明によるマルチキャストファイル配信方法は、
マルチキャストによるデータファイル配信方法であっ
て、複数のブロックからなるデータファイルを各配信先
に送出するステップと、前記データファイルの配信終了
後に、各配信先において、該複数のブロックからなるデ
ータファイル内に何れかの送出されたパケットに誤りが
あるか否かをテストするステップと、前記データファイ
ルの配信終了後に、該複数のブロックからなるデータフ
ァイルに対する前記テストにより何れかの送出されたパ
ケットに誤りがあることを検知した各配信先のいずれか
から前記送信側に、当該配信先において受信されたデー
タファイル内で誤りであることを検知した前記送出パケ
ットの再送出を要求する再送要求信号を、該再送要求信
号が前記誤りデータの該送出パケット内におけるオフセ
ット・ポジションと該誤りデータのデータ長を示してい
るように送出するステップと、前記再送要求信号に応答
して前記送信側から各配信先の前記いずれかに、前記誤
りであることを検知した前記送出パケットの再送出を行
うステップとを備えていることを特徴とする構成を有し
ている。前記再送要求は、例えば、該誤りのデータ配信
パケットのオフセット・ポジションを表す４バイトと該
誤りのデータのデータ長を表す４バイトとの合計８バイ
トを送出するように定めることができる。

【０００７】

【発明の実施の形態】本発明の方法の機能概要は、次の
通りである。（１）プロトコルとして要求機能概要配信方法限定配信方法（送達確認あり）であって、ファイル転送
開始時に受信することを登録（レジストレーション）し
た受信者に限定して、送信者が送達確認を行う方法であ
る。送達確認方法送達確認は送信者から受信者に対して接続して実施す
る。管理方法は同報配信元のサーバが全ての受信者（レ
ジストレーション済み）に対して送達確認を行う集中管
理型方式とする。配信速度設定機能送信者が回線速度，受信者数を考慮し、マルチキャスト
同報配信速度を設定できる機能である。配信先フォルダ指定機能送信者が配信するファイルを格納するための受信者のフ
ォルダを指定できる機能である。ファイルの正当確認機能同報配信フェーズ，同報再送フェーズにおいて、サーバ
からクライアントにファイルデータを送信する際に、パ
ケット単位でチェックサム検査を行い、ファイル送信の
正当性を確認する機能である。

【０００８】以下に、上記の機能について、その内容を
さらに説明する。（２）プロトコルスタック本発明方法を実施するためのマルチキャストファイル転
送ソフトウェアのプロトコルスタックを図１に示す。

【０００９】（３）通信手順通信手順はファイル配信情報の配信を行う「アナウンス
／レジストレーションフェーズ」、同報配信を行う「同
報配信フェーズ」と、同報再送を行う「同報再送フェー
ズ」と、送達確認を行う「送達確認フェーズ」に分けら
れる。アナウンス／レジストレーションフェーズ，同報
配信フェーズ，および同報再送フェーズのサーバからク
ライアントへのデータの配信は、すべてマルチキャスト
対応のＵＤＰ配信で行われる。一方、アナウンス／レジ
ストレーションフェーズ，同報再送フェーズおよび送達
確認フェーズのクライアントからサーバへのデータ送信
および送達確認フェーズのサーバからクライアントへの
データ送信は、ユニキャストのＵＤＰ配信で行われる。
それぞれのシーケンスを、図２，図３，図４，図５に示
す。

【００１０】アナウンス・レジストレーションフェ
ーズサーバは、配信開始要求トリガーにより、アナウンス用
のマルチキャストＩＰアドレスを用いて、「同報配信開
始アナウンスパケット」を送信する。このパケットはＭ
Ｆ共通ヘッダー情報以外に、これから送信するファイル
名，ファイルサイズ，配信速度，データ同報用マルチキ
ャストＩＰアドレスおよびボート番号情報が含まれてい
る。最初の「同報配信開始アナウンスパケット」を送信
後、サーバはさらに定期的（Ｔｓ４タイマーにより規定
される一定時間長毎）に「同報配信開始アナウンスパケ
ット」を送信する。サーバは、宛先として指定した Gro
upIＤに所属する全クライアントから「レジストレーシ
ョンパケット」を受信した場合、または、タイマーＴｓ
１により規定される一定時間経過後に、これらを送信開
始トリガーとして、同報配信フェーズに移行する。ま
た、レジストレーション受信期間中に受信したパケット
の内容に従って送達確認リストを作成し、同報再送フェ
ーズが開始する前に、アプリケーション・プログラム
（Application Program ：ＡＰ）に確認を求める。クラ
イアントは「同報配信開始アナウンスパケット」を受信
し、自局の所属している Group IＤならば、ＡＰに問い
合わせた後、その結果（レジストレーションコード）を
含む「レジストレーションパケット」をサーバに送り返
し、同報配信フェーズに移行する。なお、パケット間の
タイムアウトを規定するＴｃ３タイマーがタイムアウト
した時にはプログラムは終了する。

【００１１】同報配信フェーズサーバは、送信開始トリガーに従って、「ファイルデー
タパケット」を送信する。「ファイルデータパケット」
は、ファイル内のオフセット位置，パケット内のファイ
ルデータ情報のチェックサム値，ファイルデータ情報を
送る。従って、クライアントが途中で「ファイルデータ
パケット」を受信できなくても、データの受信を続ける
ことが可能である。データの送信が完了したら、最後に
「同報配信終了パケット」を送信し、ＡＰによる送達確
認リストの確認が終了している場合には、同報再送フェ
ーズに移行する。なお、「ファイルデータパケット」と
「同報配信終了パケット」の送信には、それぞれ別のポ
ート番号を使用する。クライアントは「ファイルデータ
パケット」を受信中に、ファイルデータの抜けを検出し
たら再送要求データリストを作成する。また、「ファイ
ルデータパケット」を受信するたびに、受信したファイ
ルデータのチェックサム値を計算し、サーバが計算した
チェックサム値と比較する。サーバが計算したチェック
サム値とクライアントが計算したチェックサム値が異な
る場合には、再送要求データリストを作成する。クライ
アントは、「同報配信終了パケット」の受信後に同報再
送フェーズへ移行する。なお、Ｔｃ３タイマーのタイム
アウト発生時にはプログラムは終了する。

【００１２】同報再送フェーズサーバは、「同報配信終了パケット」、または再送デー
タの「同報再送終了パケット」送信後に再送要求待ち時
間として、Ｔｓ２タイマーがタイムアウトするまで、ク
ライアントからの「再送要求パケット」、および「再送
要求終了パケット」を待つ。サーバは、タイマーＴｓ２
がタイムアウトした後、もしくは送達確認リストに登録
されている全クライアントから「再送要求（終了）パケ
ット」を受信した後に、クライアントから受信した受信
抜けリストをもとに再送データリストを作成し、同報配
信フェーズと同一のマルチキャストＩＰアドレスで「同
報再送開始パケット」と「同報再送データパケット」を
送出する。同報再送フェーズは送達確認リストの全登録
者の受信抜けリストが空になるか、もしくはＴｓ２タイ
マーのタイムアウトが発生するまで、最大Ｎ２（後述）
回まで繰り返す。サーバは、同報再送フェーズの終了
後、送達確認フェーズに移行する。なお、同報配信フェ
ーズと同様に、「同報再送データパケット」と、「同報
再送終了パケット」の送信には、それぞれ別のポート番
号を使用する。クライアントは、同報配信フェーズと同
様にファイルデータの抜けを検出したら、再送要求デー
タリストを作成する。また、同報配信フェーズと同様
に、パケット毎に、サーバで計算したチェックサム値
と、クライアントで計算したチェックサム値を比較し、
値が異なる場合には、再送要求データリストを作成す
る。「同報配信終了パケット」または、「同報再送終了
パケット」を受信した後に、「再送要求パケット」、お
よび「再送要求終了パケット」をサーバに送信する。フ
ァイルデータの抜けが無い場合には共通ヘッダ部分だけ
から成る「再送要求終了パケット」を送出する。クライ
アントでは、「送達確認開始パケット」を受信したら送
達確認フェーズへ移行する。なお、Ｔｃ３タイマーのタ
イムアウト発生時にはプログラムは終了する。

【００１３】送達確認フェーズサーバは、ファイルの転送の信頼性を確保するために、
送達確認リストの全クライアントの送達確認を行う。ク
ライアントは「送達確認開始パケット」を受信したら、
確認結果を含む「送達確認応答パケット」を送信する。
なお、Ｔｃ３タイマーのタイムアウト発生時にはプログ
ラムは終了する。

【００１４】（４）パケットフォーマットアナウンス／レジストレーションフェーズの基本パケッ
トフォーマットを図６、同報配信フェーズの基本パケッ
トフォーマットを図７、同報再送フェーズの基本パケッ
トフォーマットを図８、送達確認フェーズの基本パケッ
トフォーマットを図９に示す。

【００１５】（５）共通ヘッダ全パケットに共通な共通ヘッダ（＝ＭＦヘッダ）部分の
フォーマットを図１０に示す。

【００１６】共通ヘッダ部分の各フィールドについて、
以下に詳述する。 Version 長さは１byte長でプロトコルのバージョンの識別に用い
る。 Control 長さは１byte長で表１に示すパケットの識別に用いる。

【００１７】

【表１】

【００１８】 Stn IＤ Stn ＩＤは４byte長で、パケットの送信者を特定するた
めの識別子である。 Group IＤ Group IＤは４byte長で、受信者のグループを特定する
ための識別子である。 Ref IＤ Ref IＤはファイル転送開始から完了までの各パケット
を識別するための識別子で、サーバが重複しないように
管理する２byte長の番号である。一つのファイル転送開
始から完了までのすべてのパケットは同一の Ref IＤを
持ち、他のファイル転送のパケットと区別される。２by
te長であるため６５５３５回のファイル転送に重複なく
使用できるが、送受信者間の合意のもとにリセットして
使用する。 Ref IＤによりファイル転送を区別するた
め、複数のファイル転送を同時に進行させることが可能
となる。同一のマルチキャスト環境に複数の送信者が存
在する場合には、各送信者に対して、あらかじめ使用で
きる Ref IＤの範囲を決めておく必要がある。 Length Lengthはパケットの長さを表す２byte長のフィールドで
あり、図１１に示すように情報部分の長さを表す。

【００１９】（６）パケット種別およびフォーマット１）同報配信開始アナウンスパケットアナウンス／レジストレーションフェーズにおいてサー
バが送信する。パケットフォーマットは図１２に示す。
ファイル同報配信の開始の合図として本パケットを使用
する。サーバはアナウンス／レジストレーションフェー
ズ中にＴｓ４タイマーにより定まる一定周期で定期的に
本パケットを送出する。クライアントは最初に受信した
本パケットにより、 Ref IＤと、同報配信フェーズで受
信する「ファイルデータパケット」のマルチキャストア
ドレス，ポート番号，配信速度，ファイルサイズ，ファ
イル名との対応付けを行う。

【００２０】２）レジストレーションパケットアナウンス／レジストレーションフェーズにおいてクラ
イアントが送信する。パケットフォーマットは図１３に
示す。本パケットは「同報配信開始アナウンスパケッ
ト」と同様であるが、共通ヘッダ部分の Stn IＤはクラ
イアントの Stn IＤを入れる。本パケットはファイル受
信をサーバに対して通知するために使用する。サーバ
は、「レジストレーションパケット」により送達確認す
るべき受信者を把握し、送達確認リストを作成する。サ
ーバはＴｓ1 タイマーのタイムアウト後、もしくは、宛
て先として指定した Group IＤに所属するすべてのクラ
イアントから「レジストレーションパケット」を受信し
た後に、同報配信フェーズを開始する。

【００２１】３）ファイルデータパケット同報配信フェーズでサーバが送信する。パケットフォー
マットを図１４に示す。本パケットは、転送するファイ
ルのバイナリデータ及びそのデータのファイル中での位
置を示すオフセット値であるシーケンス番号および、サ
ーバが計算したバイナリデータのチェックサム値を含
む。シーケンス番号は４byte長であり、そのパケットが
運ぶデータがファイル中で占める位置を示すbyte単位で
表されるオフセット値である。クライアントは本パケッ
トのシーケンス番号とLength値からファイルを再構築す
る。パケット誤りや紛失により受信データに抜けが生じ
た場合には、抜けたデータの部分のオフセット値（シー
ケンス番号）と抜けたデータの長さ（レングス値）のリ
ストからなる、再送要求データリストを作成する。ま
た、クライアントは、送られてきたチェックサム値と受
信したバイナリデータから計算したチェックサム値を比
較して、パケット単位のデータ転送の成功／失敗を判断
する。チェックサム検査で転送失敗が判明した場合に
は、該当データのオフセット値とレングス値を再送要求
データリストに追加する。

【００２２】４）同報配信終了パケット同報配信フェーズにおいてサーバが送信する。パケット
フォーマットを図１５に示す。サーバはすべてのデータ
送信が終了し、同報再送フェーズを開始する合図とし
て、本パケットを送信し、Ｔｓ２タイマを起動する。サ
ーバは送達確認リストに登録してある全受信者から「再
送要求終了パケット」を受信するか、もしくはＴｓ２タ
イマーのタイムアウトが生じるまで、タイマーＴｓ５に
より規定される周期で「同報配信終了パケット」を送り
続ける。クライアントは、最初に本パケットを受信した
後、マルチキャストによる同報配信が終了したとみなし
同報再送フェーズへ移行する。クライアントは本パケッ
トを受信すると、サーバに「再送要求（終了）パケッ
ト」を送信する。

【００２３】５）同報再送開始パケット同報再送フェーズにおいてサーバが送信する。パケット
フォーマットを図１６に示す。サーバはＴｓ２タイマー
のタイムアウト後、もしくは送達確認リストに登録され
ている全クライアントから「再送要求終了パケット」を
受信した後に「同報再送開始パケット」を送出し、「同
報再送データパケット」の送出を開始する。クライアン
ト側は、本パケットの受信によりマルチキャストによる
同報再送開始の合図とする。

【００２４】６）同報再送終了パケット同報再送フェーズにおいてサーバが送信する。パケット
フォーマットは図１６の「同報再送開始パケット」と同
じである。サーバはすべての「同報再送データパケッ
ト」を送出後に、本パケットを送出し同報再送フェーズ
の終了を通知し、Ｔｓ２タイマーを起動する。サーバは
タイマーＴｓ２のタイムアウト後、もしくは送達確認リ
ストに登録されている全クライアントから「再送要求終
了パケット」を受信するまで、Ｔｓ５タイマーにより規
定される一定周期で本パケットを送信し続ける。クライ
アントは、本パケットを受信すると、サーバに「再送要
求パケット」、および「再送要求終了パケット」を送信
する。

【００２５】７）再送要求パケット，再送要求終了パケ
ット同報再送フェーズにおいてクライアントが送信するパケ
ットで、パケットフォーマットを図１７に示す。同報配
信フェーズあるいは同報再送フェーズにおいてクライア
ントが受信できなかったデータの再送を要求するパケッ
トである。クライアントが、作成した再送要求データリ
ストをもとに抜けたデータの（オフセット値＋データ
長）を一組にしてサーバに送信する。本パケット中に複
数の（オフセット値＋データ値）の組を含んでもよい。
サーバ側では、「同報配信（再送）終了パケット」受信
後、Ｔｓ２タイマーのタイムアウトまで各クライアント
からの本パケットを受付け、本パケットの情報をもとに
データの再送要求リストを作成する。各クライアント
は、再送要求データ数が多く、「再送要求パケット」が
複数パケットにまたがる場合には、１番目から（最後−
１）番目までは「再送要求パケット」、最後は「再送要
求終了パケット」を、サーバに送信する。また、受信抜
けデータが１パケットに納まる場合には、「再送要求終
了パケット」のみを送信する。

【００２６】８）同報再送データパケット同報再送フェーズにおいてサーバが送信する。パケット
フォーマットは、図１４の「ファイルデータパケット」
と同じである。再送要求リストにしたがって、本パケッ
トを作成し送信する。クライアントは、データの抜けた
部分を本パケットで補完する。

【００２７】９）送達確認開始パケット送達確認フェーズにおいて、サーバがクライアントに送
達確認を行うことを要求するために送信し、Ｔｓ３タイ
マーを起動する。サーバは、送達確認リストに登録して
ある全受信者から「送達確認応答パケット」を受信する
か、もしくはＴｓ３タイマーのタイムアウトが生じるま
で、Ｔｓ６タイマーのタイムアウト毎に「送達確認開始
パケット」を送り続ける。パケットフォーマットを図１
８に示す。クライアントは、本パケットを受信すると、
送達確認フェーズに入る。クライアントは、応答コード
を含む、「送達確認応答パケット」をサーバに送り返
す。

【００２８】１０）送達確認開始応答パケット送達確認フェーズにおいて、クライアントが「送達確認
開始パケット」を受信した時にパケットをサーバに送り
返す。パケットフォーマットを図１９に示す。

【００２９】１１）送達確認終了パケットサーバが全クライアントから「送達確認応答パケット」
を受信した場合、もしくはＴｓ３タイマーのタイムアウ
トが発生した際に、本パケットを送信する。パケットフ
ォーマットを図２０に示す。

【００３０】（７）タイマータイマーの表記は、クライアントで持つタイマーをＴｃ
Ｙ、サーバで待つタイマーをＴｓＸとする。ＴｃＹは、
クライアントが「同報配信開始アナウンスパケット」を
受信後、一定のアルゴリズムに従って計算する数値であ
る。一方、ＴｓＸは、ＡＰが設定し、引き渡す数値であ
る。

【００３１】Ｔｃ３タイマーＴｃ３タイマーはクライアント側でもつタイマーで、フ
ァイル転送の確実な終了を保証するために用いる。Ｔｃ
３タイマーは各フェーズにおいて、各フェーズに適切な
パケットを受信する度に再起動する。クライアントは、
Ｔｃ３タイマーのタイムアウトが発生した場合にはプロ
グラムを終了する。

【００３２】Ｔｓ１タイマーＴｓ１タイマーはアナウンス／レジストレーションフェ
ーズで、サーバが「レジストレーションパケット」を受
け付ける時間を設定する。タイムアウトによりレジスト
レーションの受付を終了し、受信者リストを作成しＡＰ
へ渡す。

【００３３】Ｔｓ２タイマーサーバで使用するタイマーで、「同報配信終了パケッ
ト」または「同報再送終了パケット」送信時から、「再
送要求終了パケット」の待ち時間を規定する。タイムア
ウトで次の同報再送フェーズを開始する。

【００３４】Ｔｓ３タイマーＴｓ３タイマーは、サーバが送達確認フェーズで使用す
るタイマーで、最初の「送達確認開始パケット」を送信
したときに起動する。「送達確認応答パケット」の待ち
時間であり、送達確認リスト中の全クライアントから
「送達確認応答パケット」を受信した時に停止する。Ｔ
ｓ３タイマーのタイムアウトが発生しても「送達確認応
答パケット」を返送しないクライアントが存在する場合
には、そのクライアントは送達確認失敗としてサーバロ
グ上に記録される。

【００３５】Ｔｓ４タイマーＴｓ４タイマーは「同報配信開始アナウンスパケット」
の配送間隔である。サーバはＴｓ４タイマーがタイムア
ウトする毎にＴｓ１タイムアウトが発生するまで「同報
配信開始アナウンスパケット」を配信する。

【００３６】Ｔｓ５タイマーＴｓ５タイマーは「同報配信（再送）終了パケット」の
配送間隔である。サーバは受信リスト中の全クライアン
ト（レジストレーション済）から「再送要求パケット」
を受領するか、Ｔｓ２タイマーのタイムアウトが生じる
まで、クライアントに対してＴｓ５タイマーがタイムア
ウトする毎に「同報配信（再送）終了パケット」を配信
し続ける。

【００３７】Ｔｓ６タイマーＴｓ６タイマーは「送達確認開始パケット」の配送間隔
である。サーバは送達確認リスト中の全クライアントか
ら「送達確認応答パケット」を受領するか、Ｔｓ３タイ
マーのタイムアウトが生じるまで、クライアントに対し
てＴｓ６タイマーがタイムアウトする毎に「送達確認開
始パケット」を配信し続ける。

【００３８】（８）Ｎ２Ｎ２は同報再送フェーズの繰り返し回数を規定する。

【００３９】（９）送達確認手順の起動方法サーバは、「送達確認開始パケット」を送信し、Ｔｓ３
タイマーがタイムアウトするか、もしくは受信者リスト
中の全受信者から「送達確認応答パケット」が戻ってく
るのを待つ。Ｔｓ６タイマーにより規定される一定期間
が経過しても、登録した全受信者から「送達確認応答パ
ケット」が戻ってこない場合には、「送達確認開始パケ
ット」を再度送信する。Ｔｓ３タイマーのタイムアウト
が生じても「送達確認応答パケット」を返送してこない
クライアントについては、送達確認失敗として、ログに
記録する。

【００４０】以上の各機能の説明に基づき、本発明の具
体的実施形態について説明する。図２１（ａ）は、本発
明によるマルチキャストファイル配信方法（ＭＳＡＴ方
式とも称する）で用いるデータ配信パケットフォーマッ
トを示しており、ファイルはブロック＃１，ブロック＃
２，ブロック＃３，ブロック＃４よりなる場合であり、
各ブロック＃１〜ブロック＃４にはＭＳＡＴ方式の送受
プロセッサ間での通信に用いるＯＨ（オーバヘッド：ov
erhead) であるＭＳＡＴ−ＯＨが付加されている。この
ＭＳＡＴ−ＯＨを含む各フレームには、さらにＵＤＰ
（User Datagram Protocol) −ＯＨ、および、ＩＰ（イ
ンターネット・プロトコル：InternetProtocol)用のＯ
ＨであるＩＰ−ＯＨを含んでいる。ＭＳＡＴ−ＯＨは、
制御信号Control, 局識別信号 Stn IＤ，グループ識別
信号 Group IＤ，ブロック識別信号 Ref IＤ及びブロッ
ク長 Length より構成されている。

【００４１】さらに、図２１（ｂ）はＭＳＡＴ方式によ
る再送要求パケットフォーマットであり、再送要求の単
位は、オフセット・ポジションを示すシーケンス番号
（４バイト）とデータ長（４バイト）の合計８バイトで
構成されている。これにより、単独の誤り、及び、連続
した誤りでは、短いバイト数で再送要求を実行すること
ができる。

【００４２】

【実施例】以下に、本発明の方法の動作について説明す
る。図２２は、本発明の方法において、データ伝送開始
の予備動作であるアナウンス／レジストレーション／同
報配信フェーズの送信側における動作を示すフローチャ
ートである。この場合の動作において、動作開始
（Ｓ₀）後、Ｔｓ１タイマーとＴｓ４タイマーを起動
し、「同報配信開始アナウンスパケット」を送信し（Ｓ
₁）、受信者からの「レジストレーションパケット」を
受信しているかを検査する（Ｓ₂）。この検査（Ｓ₂）
ＹＥＳのとき、送達確認リストに追加し（Ｓ₃）、Ｓ₂
の検査がＮＯであるときおよび「送達確認リスト」への
追加が行われたときに（Ｓ₃）、Ｔｓ１タイマーがタイ
ムアウトしているかを検査する（Ｓ₄）。この検査（Ｓ
₄）がＹＥＳのとき、「送達確認リスト」が生成されて
いるかを検査する（Ｓ₅）。この検査（Ｓ₅）がＹＥＳ
のとき、ファイルデータを分割しパケットを生成した後
（Ｓ₆）、「ファイルデータパケット」を同報配信した
後「同報配信終了パケット」を送信し（Ｓ₇）、再送フ
ェーズの動作（※１）に移行することになる。Ｓ₄の検
査において、Ｔｓ１タイマーがタイムアウトしていない
ＮＯのとき、Ｔｓ４タイマーがタイムアウトしているか
を検査する（Ｓ₁₀）。この検査（Ｓ ₁₀）がＹＥＳのと
き、Ｔｓ４タイマーを再起動し、「同報配信開始アナウ
ンスパケット」を送信した（Ｓ₁₁）とき、および、検査
（Ｓ₁₀）がＮＯのとき、受信者からの「レジストレーシ
ョンパケット」を受信しているかを検査する（Ｓ₂）に
復帰する。Ｓ₅の検査において、「送達確認リスト」が
生成されていないＮＯのときには、終了（Ｓ₉）とな
る。

【００４３】図２３は、アナウンス／レジストレーショ
ン／同報配信フェーズの受信側における動作を示すフロ
ーチャートである。この場合の動作において、動作開始
（Ｒ₀）後、「同報配信開始アナウンスパケット」を受
信できたかを検査し（Ｒ₁）、この検査（Ｒ₁）がＹＥ
Ｓのとき、受信者からの「レジストレーションパケッ
ト」を送信し（Ｒ₂）、Ｔｃ３タイマーを起動し
（Ｒ₃）、Ｔｃ３タイマーがタイムアウトしたかを検査
し（Ｒ₄）、この検査（Ｒ₄）がＹＥＳのときにこのフ
ェーズを終了する（Ｒ₅）。検査（Ｒ ₄）がＮＯのとき
には、「ファイルデータパケット」を受信したかを検査
し（Ｒ ₆）、この検査がＹＥＳのときに、受信した「フ
ァイルデータパケット」が正常かのテストをし
（Ｒ₇）、このテスト（Ｒ₇）がＹＥＳであれば、「フ
ァイルデータパケット」の内容を記録媒体に書き込み、
Ｔｃ３タイマーを再起動する（Ｒ _8a）。Ｒ₇のテストが
ＮＯのときには、再送要求データリストを生成し、Ｔｃ
３タイマーを再起動する（Ｒ_8b）。このようにＴｃ３タ
イマーを再起動したときおよび検査（Ｒ₆）がＮＯのと
き、「同報配信終了パケット」を受信したかを検査する
（Ｒ₉）。検査（Ｒ₉）がＹＥＳのときには、再送フェ
ーズ動作（※１０）に移行し、検査（Ｒ₉）がＮＯのと
きには、検査（Ｒ₅）戻る。

【００４４】図２４は、再送フェーズの送信側における
動作を示すフローチャートである。この場合の再送フェ
ーズの動作（※１）が開始されると（Ｓ₈）、Ｔｃ２タ
イマーとＴｃ５タイマーを起動し再送カウンタを初期化
する（Ｓ₁₂）。次に、「再送要求パケット」または「再
送要求終了パケット」を受信できたかを検査する
（Ｓ₁₃）。この検査（Ｓ₁₃）がＹＥＳである場合におい
て、「再送要求リスト」に追加したとき（Ｓ₁₄）、およ
び、前記の検査（Ｓ₁₃）がＮＯのとき、Ｔｓ２タイマー
がタイムアウトしているかの検査（Ｓ₁₅）をする。この
検査（Ｓ₁₅）がＹＥＳのとき、「再送要求リスト」に基
づき「同報再送データパケット」を同報配信し
（Ｓ₁₆）、再送カウンタのカウント値がＮ２の値を越え
たかを検査する（Ｓ₁₇）。この検査（Ｓ₁₇）がＹＥＳの
ときに、送達確認フェーズの動作（※２）に移行する
（Ｓ₂₁）。検査（Ｓ₁₇）がＮＯの場合に、再送カウンタ
をカウントアップし、Ｔｓ５タイマーを再起動させたと
き（Ｓ₁₈）、および前記の検査（Ｓ₁₅）がＮＯのとき、
Ｔｓ５タイマーがタイムアウトしているかを検査する
（Ｓ₁₉）。この検査（Ｓ₁₉）がＹＥＳである場合、およ
び、この検査（Ｓ₁₉）がＮＯであって、Ｔｓ５タイマー
を再起動し「同報再送終了パケット」を送信したとき
（Ｓ₂₀）、前記の検査Ｓ₁₃に戻る。

【００４５】図２５は、再送フェーズの受信側における
動作を示すフローチャートである。この場合の再送フェ
ーズの動作（※１０）が開始されると（Ｒ₁₀）、再送要
求データリストがあるかの検査をし（Ｒ₁₁）、この検査
（Ｒ₁₁）がＮＯのときには、「同報再送要求終了パケッ
ト」を送信し（Ｒ₁₂）、送達確認フェーズの動作（※２
０）に移行する（Ｒ₁₃）。この検査（Ｒ₁₁）がＹＥＳの
とき、「再送要求パケット」および「再送要求終了パケ
ット」を送信し（Ｒ₁₄）、「同報再送開始パケット」を
受信したかを検査する（Ｒ₁₅）。この検査（Ｒ₁₅）がＹ
ＥＳになったときに、Ｔｃ３タイマーを再起動し
（Ｒ₁₆）、Ｔｃ３タイマーがタイムアウトしたかを検査
し（Ｒ₁₇）、この検査（Ｒ₁₇）がＹＥＳのときに、この
再送フェーズの動作（※１０）は終了となる（Ｒ₁₈）。
Ｒ₁₅の検査がＮＯのときには、「Ｔｃ３タイマーはタイ
ムアウトか」の検査をし（Ｒ₁₉）、その検査（Ｒ₁₉）
が、ＮＯのときには再びＲ₁₅の検査をし、その検査（Ｒ
₁₉）がＹＥＳのときには、再送フェーズの動作（※１
０）は終了となる（Ｒ₁₈）。Ｒ₁₇の検査がＮＯのときに
は、「同報再送データパケット」を受信したかの検査
（Ｒ₂₀）をする。この検査（Ｒ₂₀）がＹＥＳのときに
は、受信した「同報再送データパケット」は正常かのテ
スト（Ｒ₂₁）をし、このＲ₂₁のテストがＹＥＳのときに
は、「同報再送データパケット」の内容を記憶媒体に書
き込み、Ｔｃ３タイマーを再起動する（Ｒ₂₂）。Ｒ₂₁の
検査がＮＯのときには、再送要求データリストを作成
し、Ｔｃ３タイマーを再起動する（Ｒ₂₃）。検査
（Ｒ₂₀）がＮＯのとき、およびＲ₂₂またはＲ₂₃の動作を
終了したときに、「同報再送終了パケット」を受信した
かの検査をする（Ｒ₂₄）。検査（Ｒ₂₄）がＹＥＳのとき
に、再送フェーズの動作（※１０）を再施行し
（Ｒ₁₀）、検査（Ｒ₂₄）がＮＯのときには、検査
（Ｒ₁₇）に戻る。

【００４６】図２６は、送達確認フェーズの送信側の動
作を示すフローチャートである。この場合の送達確認フ
ェーズの動作（※１２）が開始されると（Ｓ₂₁）、タイ
マーＴｓ３，Ｔｓ６を起動し、「送達確認開始パケッ
ト」を送信し（Ｓ₂₂）、「送達確認リスト」のすべての
送達確認が完了しているかを検査し（Ｓ₂₃）、この検査
Ｓ₂₃）がＹＥＳのときには、「送達確認終了パケット」
を送信し（Ｓ₂₄）、送達確認フェーズの動作を終了する
（Ｓ₂₅）。検査（Ｓ₂₃）がＮＯのとき、Ｔｓ３タイマー
がタイムアウトしているかの検査をし（Ｓ₂₆）、この検
査（Ｓ₂₆）がＹＥＳのときには、「送達確認リスト」で
送達確認していない受信者を送達失敗とし（Ｓ₂₇）、
「送達確認終了パケット」を送信し（Ｓ₂₄）、送達確認
フェーズの動作を終了する（Ｓ₂₅）。検査（Ｓ₂₆）がＮ
Ｏのときには、受信者からの「送達確認応答パケット」
を受信しているかの検査（Ｓ₂₈）をし、この検査
（Ｓ₂₈）がＹＥＳのときは、「送達確認リスト」上でそ
の受信者から送達確認終了とし（Ｓ₂₉）、Ｔｓ６タイマ
ーがタイムアウトしているかを検査する（Ｓ₃₀）。検査
（Ｓ₂₈）がＮＯのときにも、Ｔｓ６タイマーがタイムア
ウトしているかを検査し（Ｓ₃₀）、この検査（Ｓ₃₀）が
ＹＥＳの場合には「送達確認開始パケット」を送信し、
タイマーＴｓ６を再起動し（Ｓ₃₁）、検査（Ｓ₃₂）に戻
る。検査（Ｓ₃₀）がＮＯのときにも検査（Ｓ₂₃）に戻
る。

【００４７】図２７は、送達確認フェーズの受信側の動
作を示すフローチャートである。この場合の送達確認フ
ェーズの動作（※２０）が開始されると（Ｒ₁₃）、Ｔｃ
３タイマーを再起動した（Ｒ₂₅）の動作の次に、「送達
確認開始パケット」を受信したかを検査し（Ｒ₂₆）、こ
の検査（Ｒ₂₆）がＹＥＳになったときに、「送達確認応
答パケット」を送信し（Ｒ₂₇）、この動作（※２０）を
終了する（Ｒ₂₈）。検査（Ｒ₂₆）がＮＯのときには、Ｔ
ｃ３タイマーがタイムアウトしているかを検査し
（Ｒ₂₉）、この検査（Ｒ₂₉）がＹＥＳのとき、この動作
（※２０）を終了する（Ｒ₂₈）。検査（Ｒ₂₉）がＮＯの
ときには、Ｒ₂₆に戻る。図３０は、本発明の具体的実施
例であり、１０は送信側として用いられるハブ局、１１
はクライアントに対するパソコンの如きホスト・サーバ
で、専用線１２を介してハブ局１０に接続されている。
２０は通信衛星、３１はハブ局１０から通信衛星２０を
経由して小型地球局４０−１，４０−２，４０−３に至
る時分割多重（ＴＤＭ）通信路（例えば、２Ｍｅｇａ
ｂｉｔ／ｓｅｃ）、３２，３３はいずれも時分割多重
接続（ＴＤＭＡ）通信路（例えば、１５０ｋｉｌｏ
ｂｉｔ／ｓｅｃ）、４１−１，４１−２，４１−３はい
ずれも宅内ユニット（ＩＤＵ）、４２−１，４２−２，
４２−３，４２−４，４２−５はいずれもクライアント
側のパソコンの如きクライアント装置、４３−１，４３
−２はＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒ
ｋ）である。図３０に一例を示す通信衛星による双方向
通信サービスでは、片方向型衛星サービスとは異なり、
上り回線（リモートサイト→ハブ局）の有効利用（＝再
送要求パケットを短縮化すること）がネットワークコス
トの低減に繋がり、極めて重要となるため、「再送要求
パケット」を短縮化できる本発明方法が適している。

【００４８】

【発明の効果】以上詳細に説明したように、本発明方法
により次のような効果が得られる。従来のＭＦＴＰ方式では、データ誤りをビットマッ
プで表現するので、たとえ１ＤＴＵの誤りであっても１
ブロックに相当するビットマップ（通常１ＭＴＵ（＝１
５００バイト）のサイズとなる）から成る再送要求パケ
ットを送信する必要があった。これに対して、本発明の
マルチキャストによるデータファイル配信方法（ＭＳＡ
Ｔ方式）では、誤りを“オフセット・ポジション
（４）”＋“データ長（４）”（計８バイト）で表現す
るので、単独の誤りおよび連続した誤りにおいては、短
いバイト数で再送要求できる。最近では衛星回線を含め通信回線の品質が向上し、
通常はほとんど誤りがないか極めて稀に誤りが発生する
のみなので、このような場合、本発明によるＭＳＡＴ方
式が従来のＭＦＴＰ方式に比較して効率よく「再送要求
パケット」を伝送できる。図２９に送信ファイルサイズ
と回線ビット誤り率に対する１受信局が発生する再送要
求パケットサイズの合計を示す。実際には、衛星回線で
の誤りはブロック的に発生することが多く、ＭＳＡＴ方
式ではブロックが連続して誤った場合、単一の“オフセ
ット・ポジション（４）”＋“データ長（４）”で複数
の「ファイルデータパケット」の再送要求が可能となる
ので、さらに効率的となる。本発明方法においては、回線品質が極端に悪い場合
に「再送要求パケット」の数が増加することが懸念され
るが、一定数以上の誤りパケットが発生した場合は、再
送要求を行わない等の制限を加えることでリスクを回避
することができる。

【図面の簡単な説明】

【図１】本発明方法に用いるプロトコルスタックを示す
図である。

【図２】本発明方法に用いるアナウンス／レジストレー
ションフェーズのシーケンスを示す図である。

【図３】本発明方法に用いる同報配信フェーズのシーケ
ンスを示す図である。

【図４】本発明方法に用いる同報再送フェーズのシーケ
ンスを示す図である。

【図５】本発明方法に用いる送達確認フェーズのシーケ
ンスを示す図である。

【図６】本発明方法に用いるアナウンス／レジストレー
ションフェーズの基本パケットフォーマットを示す図で
ある。

【図７】本発明方法に用いる同報配信フェーズの基本パ
ケットフォーマットを示す図である。

【図８】本発明方法に用いる同報再送フェーズの基本パ
ケットフォーマットを示す図である。

【図９】本発明方法に用いる送達確認フェーズの基本パ
ケットフォーマットを示す図である。

【図１０】本発明方法に用いるヘッダフォーマットを示
す図である。

【図１１】本発明方法に用いるＬｅｎｇｔｈ長の概念を
示す図である。

【図１２】本発明方法に用いる同報配信開始アナウンス
パケットフォーマットを示す図である。

【図１３】本発明方法に用いるレジストレーションパケ
ットを示す図である。

【図１４】本発明方法に用いるファイルデータパケット
フォーマットを示す図である。

【図１５】本発明方法に用いる同報配信終了パケット，
同報再送終了パケットのフォーマットを示す図である。

【図１６】本発明方法に用いる同報再送開始パケット，
同報再送終了パケットフォーマットを示す図である。

【図１７】本発明方法に用いる再送要求パケット，再送
要求終了パケットを示す図である。

【図１８】本発明方法に用いる送達確認開始パケットフ
ォーマットを示す図である。

【図１９】本発明方法に用いる送達確認応答パケットフ
ォーマットを示す図である。

【図２０】本発明方法に用いる送達確認終了パケットを
示す図である。

【図２１】本発明方法に用いるデータ配信パケットフォ
ーマット（ａ）と再送要求（終了）パケットフォーマッ
ト（ｂ）を示す図である。

【図２２】本発明方法におけるアナウンス／レジストレ
ーション／同報配信フェーズの送信側フローチャートで
ある。

【図２３】本発明方法におけるアナウンス／レジストレ
ーション／同報配信フェーズの受信側フローチャートで
ある。

【図２４】本発明方法における再送フェーズの送信側フ
ローチャートである。

【図２５】本発明方法における再送フェーズの受信側フ
ローチャートである。

【図２６】本発明方法における送達確認フェーズの送信
側フローチャートである。

【図２７】本発明方法における送達確認フェーズの受信
側フローチャートである。

【図２８】従来の方法におけるデータ配信パケットフォ
ーマット（ａ）と再送要求フォーマット（ｂ）を示す図
である。

【図２９】本発明方法と従来方法による送信ファイルサ
イズと回線誤り率に対する１受信局が発生する再送要求
パケットサイズの合計との関係を対比する図である。

【図３０】本発明方法を適用する通信衛星を用いる双方
向通信サービス系の一例を示す系統図である。

【符号の説明】

１０ハブ局１１ホスト・サーバ１２専用線２０通信衛星３１時分割多重（ＴＤＭ）通信路３３，３４時分割多重接続（ＴＤＭＡ）通信路４１−１，４１−２，４１−３宅内ユニット４２−１，４２−２，４２−３，４２−４，４２−５
クライアント装置４３−１，４３−２ＬＡＮ

Claims

【特許請求の範囲】

【請求項１】マルチキャストによるデータファイル配
信方法であって、複数のブロックからなるデータファイルを各配信先に送
出するステップと、前記データファイルの配信終了後に、各配信先におい
て、該複数のブロックからなるデータファイル内に何れ
かの送出されたパケットに誤りがあるか否かをテストす
るステップと、前記データファイルの配信終了後に、該複数のブロック
からなるデータファイルに対する前記テストにより何れ
かの送出されたパケットに誤りがあることを検知した各
配信先のいずれかから前記送信側に、当該配信先におい
て受信されたデータファイル内で誤りであることを検知
した前記送出パケットの再送出を要求する再送要求信号
を、該再送要求信号が前記誤りデータの該送出パケット
内におけるオフセット・ポジションと該誤りデータのデ
ータ長を示しているように送出するステップと、前記再送要求信号に応答して前記送信側から各配信先の
前記いずれかに、前記誤りであることを検知した前記送
出パケットの再送出を行うステップとを備えたマルチキ
ャストによるデータファイル配信方法。
【請求項２】前記再送要求は、該誤りのデータ配信パ
ケットのオフセット・ポジションを表す４バイトと該誤
りのデータのデータ長を表す４バイトとの合計８バイト
を送出するように定められていることを特徴とする請求
項１に記載のマルチキャストによるデータファイル配信
方法。