JP2005341507A - マルチキャストデータ配信システムにおけるクライアント - Google Patents

Abstract

【課題】 この発明は、マルチキャスト方式によってストリームを配信する場合に、ストリーム送信サーバの負荷を一定にできるようになるマルチキャストデータ配信システムにおけるクライアントを提供することを目的とする。
【解決手段】 第１のストリームの受信中において、パケットの欠落が発生した場合には、欠落したパケットを特定するとともに、第１のストリームとコンテンツが同一で送信開始時刻が第１のストリームより遅い第２のストリームに対応するグループへの参加をネットワーク内のマルチキャスト対応ルータに要求する第５手段、ならびに第５手段によるグループ参加要求に基づいて、ネットワーク内のマルチキャスト対応ルータから送信されてきた第２のストリームを受信し、受信した第２のストリームから、第１のストリームの受信において欠落したパケットを取得して、記憶手段に記憶させる第６手段を備えている。【選択図】 図３

Description

この発明は、マルチキャストデータ配信システムにおけるクライアントに関する。

図１は、インターネットを利用した映像配信システムの構成を示している。

映像配信システムは、映像配信サービス全体のコンテンツに関する情報（以下、コンテンツ情報という）を送信するコンテンツ情報送信サーバ１と、コンテンツのＡＶストリームを送信するＡＶストリーム送信サーバ２と、これらのサーバ１、２にインターネット網３を介して接続されたクライアント（視聴端末）４とを備えている。

ユーザが特定のコンテンツを視聴したい場合、クライアント４からコンテンツ情報送信サーバ１にサービス全体のコンテンツ情報を要求することにより、コンテンツ情報送信サーバ１からコンテンツ情報を取得する。取得したコンテンツ情報は、ＨＴＭＬ言語、ＢＭＬ言語等で記述されており、クライアント４に搭載されている各言語に対応したブラウザによって表示される。ユーザは、ＷＥＢブラウジングと同様な操作で、サービス全体のコンテンツ情報を文字または静止画で得て、視聴したいコンテンツを選択する。

映像配信方式には、ユニキャスト方式とマルチキャスト方式とがある。ユニキャスト方式では、各コンテンツはコンテンツ情報に含まれているコンテンツ識別番号によって区別されており、クライアント４上でユーザがコンテンツを選択すると、選択されたコンテンツに対応するコンテンツ識別番号が、クライアント４からＡＶストリーム送信サーバ２にコンテンツ送信要求とともに送信される。ＡＶストリーム送信サーバ２は、受信したコンテンツ識別番号に対応するコンテンツのＡＶストリームをクライアント４に送信する。クライアント４は、受信したＡＶストリームを記憶装置に蓄積する。クライアント４は、要求したコンテンツに対するＡＶストリームを全て蓄積した後、ＡＶストリームの再生を開始する。

マルチキャスト方式では、各コンテンツは既にＡＶストリーム送信サーバ２から送信されている。各コンテンツは、コンテンツ情報に含まれているマルチキャストグループＩＤによって区別されている。クライアント４上でユーザがコンテンツを選択すると、クライアント４は、選択されたコンテンツに対応するマルチキャストグループＩＤで表されるグループへの参加をインターネット網内のマルチキャスト対応ルータに要求する。

これにより、上記マルチキャストグループＩＤに対応するＡＶストリームがインターネット網内のマルチキャスト対応ルータからクライアント４に送信される。クライアント４は、受信したＡＶストリームを記憶装置に蓄積する。クライアント４は、要求したコンテンツに対するＡＶストリームを全て蓄積した後、ＡＶストリームの再生を開始する。

ユニキャスト方式では、ユーザがコンテンツを要求してからすぐにコンテンツの送信が開始されるが、同時に複数のユーザからのコンテンツ要求があった場合には、ＡＶストリーム送信サーバは、これらのユーザの数と同数のストリームを送信する必要がある。

マルチキャスト方式では、ユーザがコンテンツを要求してから、コンテンツが受信できるまでに時間がかかるが、ＡＶストリーム送信サーバから送信するストリーム数は、サーバ側で決定した数を越えることはない。
特開平５−９１５１０号公報

ユニキャスト方式では、システム内で稼働しているクライアントの数だけＡＶストリームを送信する必要があるため、１台のＡＶストリーム送信サーバで処理できるクライアント数に制限がある。また、ＡＶストリームの送信中にエラーが発生したために、クライアントで受信したＡＶストリームの一部に欠落が生じた場合、クライアントは欠落した部分のデータの再送をＡＶストリーム送信サーバに要求するため、ＡＶストリーム送信サーバの負荷が増加する。このようなことから、ＡＶストリーム送信サーバの負荷が不定となるという問題がある。

マルチキャスト方式では、クライアントの数に関係なくＡＶストリームを送信するため、通常は、ＡＶストリーム送信サーバの負荷は一定である。しかしながら、ＡＶストリームの送信中にエラーが発生した場合には、ユニキャスト方式と同様にデータの再送がＡＶストリーム送信サーバに対して要求され、この要求に対してユニキャスト方式で通信が行われるため、サーバの負荷が不定となる。また、１台のＡＶストリーム送信サーバで再送要求を受け付けるクライアント数に制限がある。

この発明は、マルチキャスト方式によってストリームを配信する場合に、ストリーム送信サーバの負荷を一定にできるとともに、１台のストリーム送信サーバで処理できるクライアント数に制限がかからなくなるマルチキャストデータ配信システムにおけるクライアントを提供することを目的とする。

請求項１に記載の発明は、コンテンツのストリームをマルチキャスト方式で送信するストリーム送信サーバと、ストリーム送信サーバから送信されるコンテンツに関する情報を提供するコンテンツ情報送信サーバ、およびこれらのサーバにネットワークを介して接続されているクライアントとからなるマルチキャストデータ配信システムにおけるクライアントにおいて、コンテンツ情報送信サーバからコンテンツ情報を取得する第１手段、
第１手段によって取得したコンテンツ情報に基づいて、ユーザに所望の第１のストリームを選択させるための第２手段、ユーザによって選択された第１のストリームに対応するグループへの参加をネットワーク内のマルチキャスト対応ルータに要求する第３手段、第３手段によるグループ参加要求に基づいて、ネットワーク内のマルチキャスト対応ルータから送信されてきた第１のストリームを受信して記憶手段に蓄積させる第４手段、第１のストリームの受信中において、パケットの欠落が発生した場合には、欠落したパケットを特定するとともに、第１手段によって取得したコンテンツ情報に基づいて、第１のストリームとコンテンツが同一で送信開始時刻が第１のストリームより遅い第２のストリームに対応するグループへの参加をネットワーク内のマルチキャスト対応ルータに要求する第５手段、ならびに第５手段によるグループ参加要求に基づいて、ネットワーク内のマルチキャスト対応ルータから送信されてきた第２のストリームを受信し、受信した第２のストリームから、第１のストリームの受信において欠落したパケットを取得して、記憶手段に記憶させる第６手段を備えていることを特徴とする。

この発明によれば、マルチキャスト方式によってストリームを配信する場合に、ストリーム送信サーバの負荷を一定にできるとともに、１台のストリーム送信サーバで処理できるクライアント数に制限がかからなくなる。

以下、図面を参照して、この発明の実施例について説明する。

映像配信システムの構成は、図１に示した構成と同じである。なお、ＡＶストリーム送信サーバ２は、マルチキャスト方式によってＡＶストリームを配信しているものとする。この例では、図２に示すように、複数のコンテンツＡ，Ｂを繰り返し送信している。また、同じコンテンツを異なる送信開始時刻で送信している。

図３は、クライアント（視聴端末）４の構成を示している。

クライアント４は、ＣＰＵ１０を備えている。ＣＰＵ１０は、図示しないＲＯＭおよびＲＡＭを備えている。ＣＰＵ１０には、イーサネット（登録商標）回路１１、記録デバイス１２、ＡＶデコーダ１３、リモコン受光器１４が接続されている。リモコン１５からのリモコン信号は、リモコン受光器１４を介してＣＰＵ１０に入力される。ＡＶデコーダ１３には、図示しないモニタおよびスピーカが接続されている。ＣＰＵ１０が行うタスクには、メインタスクとパケット復元タスクとがある。

図４は、ＣＰＵ１０によって実行されるメインタスクの処理手順を示している。

クライアント４内のＣＰＵ１０は、リモコン操作に基づいて、イーサネット（登録商標）回路１１を用いて、インターネット網３を経由して、コンテンツ情報送信サーバ１にコンテンツ情報を要求する（ステップＳ１）。コンテンツ情報送信サーバ１は、クライアント４からの要求を受信すると、コンテンツ情報をクライアント４に送信する。コンテンツ情報とは、ＡＶストリーム送信サーバ２が送信している複数のコンテンツの送信スケジュール情報やコンテンツを特定するために必要な情報である。コンテンツ情報には、ユーザが視聴したいコンテンツを選択するためのメニュー画面の描画に必要なＨＴＭＬ言語やＢＭＬ言語で記述されたメニュー画面情報も含まれている。

ＣＰＵ１０は、コンテンツ情報を受信すると（ステップＳ２）、表１に示すような送信スケジュールテーブルを作成するとともに（ステップＳ３）、受信したコンテンツ情報に基づいてメニュー画面をモニタに表示させる（ステップＳ４）。

送信スケジュールテーブルは、コンテンツ識別番号毎に、送信開始時刻、送信終了時刻、グループＩＤ、送信レートおよびパケット数（パケット総数）の情報を記憶したテーブルである。同じコンテンツであっても異なる送信開始時刻で送信されているものがある場合には、送信開始時刻が異なるＡＶストリーム毎に、送信開始時刻、送信終了時刻、グループＩＤ、送信レートおよびパケット数（パケット総数）の情報が記憶される。

ユーザは、メニュー画面を見ながら、リモコン操作によって視聴したいコンテンツを選択する。ユーザによってコンテンツが選択されると（ステップＳ５）、ＣＰＵ１０は、ユーザが選択したコンテンツの識別番号を認識する。そして、ＣＰＵ１０は、送信スケジュールテーブルに基づいて、ユーザが選択したコンテンツのうち、送信開始時刻が現在時刻より後でかつ現在時刻に最も近いＡＶストリームを選択し、選択したＡＶストリームのマルチキャストグループＩＤを取得する（ステップＳ６）。

ＣＰＵ１０は、ＴＣＰ／ＩＰプロトコルに則って、取得したマルチキャストグループＩＤに対応するマルチキャストグループへの参加を、インターネット網３内のマルチキャスト対応ルータに要求する（ステップＳ７）。

上記マルチキャストグループへの参加が成功すると、ＡＶストリーム送信サーバ２が上記マルチキャストグループに対して送信しているＡＶストリームが、インターネット網３内のマルチキャスト対応ルータによってクライアント４に送信される。

ＡＶストリームのパケットは、図５に示すように、ＩＰヘッダ、ＵＤＰヘッダ、コンテンツ識別番号、パケット識別番号、当該パケットのデータ位置、ＡＶデータ長およびＡＶデータから構成されている。パケット識別番号は、ＡＶストリームの先頭から順にインクリメントされている。

ＣＰＵ１０は、１パケットを受信すると（ステップＳ８）、受信したパケット内のＡＶデータを識別番号順に記録デバイス１２に保存するとともに（ステップＳ９）、受信したパケットのパケット識別番号に基づいて、パケットの欠落が発生したか否かを判別する（ステップＳ１０）。

パケットの欠落が発生したと判別したときには、その旨および欠落したパケットのパケット識別番号をパケット復元タスクに通知した後（ステップＳ１１）、ステップＳ１２に進む。パケットの欠落が発生したと判別しなかったときには、ステップＳ１２に進む。

ステップＳ１２では、ＣＰＵ１０は、当該ＡＶストリームの受信が完了したか否かを判別する。当該ＡＶストリームの受信が完了したか否かは、原則的には、当該ＡＶストリームのパケット数（パケット総数）と上記ステップＳ８で受信したパケットのパケット識別番号に基づいて、当該ＡＶストリームの最終パケットを受信したか否かを判別することによって判別する。ただし、最終パケットが欠落する場合も想定されるので、当該ＡＶストリームの終了時刻（表１参照）から所定時間を経過した時点において、最終パケットが受信されていないときには、当該ＡＶストリームの受信が完了したと判別するようにしている。当該ＡＶストリームの受信が完了していない場合には、ステップＳ８に戻る。当該ＡＶストリームの受信が完了している場合には、ＣＰＵ１０は、上記マルチキャストグループへの参加を停止し、当該ＡＶストリームの終了をパケット復元タスクに通知する（ステップＳ１３）。

図６は、ＣＰＵ１０によって実行されるパケット復元タスクの処理手順を示している。 パケット復元タスクにおいては、メインタスクでＡＶストリームの受信が開始されると（ステップＳ２１）、ＣＰＵ１０は、パケット欠落有りの通知を監視するとともに（ステップＳ２２）、ＡＶストリームの終了の通知を監視する（ステップＳ２３）。

パケット欠落有りの通知を欠落したパケットのパケット識別番号とともに受信したときには、送信スケジュールテーブルの中から、現在受信しているＡＶストリームとコンテンツが同じでかつ送信開始時刻が現在受信しているＡＶストリームの送信開始時刻の次であるＡＶストリームのマルチキャストグループＩＤを取得する（ステップＳ２４）。そして、取得したマルチキャストグループＩＤに対応するマルチキャストグループへの参加を、インターネット網３内のマルチキャスト対応ルータに要求する（ステップＳ２５）。これにより、ＡＶストリームサーバ２が上記マルチキャストグルーブに対して送信しているＡＶストリームが、インターネット網３内のマルチキャスト対応ルータによってクライアント４に送信される。

ＣＰＵ１０は、１パケットを受信すると（ステップＳ２６）、受信したパケットのパケット識別番号が欠落したパケットのパケットの識別番号と一致するか否かを判別する（ステップＳ２７）。両パケットの識別番号が一致した場合には、受信した当該パケット内のＡＶデータを記録デバイス１２に記録（保存）する（ステップＳ２８）。パケット内のＡＶデータを記録する位置は、パケット識別番号に応じた位置となる。この後、欠落パケットが残っているか否かを判別する（ステップＳ２９）。欠落パケットが残っている場合には、ステップＳ２６に戻る。欠落パケットが残っていない場合には、上記マルチキャストグループへの参加を停止し（ステップＳ２９）、パケット欠落有りの通知とＡＶストリームの終了の通知との監視に戻る。上記ステップＳ２７において、両パケットの識別番号が一致しないと判別した場合には、ステップＳ２６に戻る。

ＡＶストリームの終了が通知されると（ステップＳ２３）、パケット復元タスクを終了する。これにより、取得したＡＶストリームの再生が可能となる。

なお、パケット復元タスクにおいて、欠落パケットのパケット識別番号と一致するパケットが受信できなかった場合、つまりパケット復元タスクにおいて受信しているＡＶストリームにおいても欠落パケットと同じパケットの欠落が発生した場合には、さらに同じコンテンツの次の開始時刻のＡＶストリームを受信するように受信するＡＶストリームを切り替えて、パケット復元タスクを繰り返せばよい。

インターネットを利用した映像配信システムの構成を示すブロック図である。 ＡＶストリーム送信サーバ２から送信されているＡＶストリームを示す模式図である。 クライアント（視聴端末）４の構成を示すブロック図である。 ＣＰＵ１０によって実行されるメインタスクの処理手順を示すフローチャートである。 ＡＶストリームのパケットの構成を示す模式図である。 ＣＰＵ１０によって実行されるパケット復元タスクの処理手順を示すフローチャートである。

符号の説明

１ コンテンツ情報送信サーバ
２ ＡＶストリーム送信サーバ
３ インターネット網
４ クライアント（視聴端末）
１０ ＣＰＵ
１１ イーサネット（登録商標）回路
１２ 記録デバイス
１３ ＡＶデコーダ
１４ リモコン受光器
１５ リモコン

Claims (1)

1. コンテンツのストリームをマルチキャスト方式で送信するストリーム送信サーバと、ストリーム送信サーバから送信されるコンテンツに関する情報を提供するコンテンツ情報送信サーバ、およびこれらのサーバにネットワークを介して接続されているクライアントとからなるマルチキャストデータ配信システムにおけるクライアントにおいて、
   コンテンツ情報送信サーバからコンテンツ情報を取得する第１手段、
   第１手段によって取得したコンテンツ情報に基づいて、ユーザに所望の第１のストリームを選択させるための第２手段、
   ユーザによって選択された第１のストリームに対応するグループへの参加をネットワーク内のマルチキャスト対応ルータに要求する第３手段、
   第３手段によるグループ参加要求に基づいて、ネットワーク内のマルチキャスト対応ルータから送信されてきた第１のストリームを受信して記憶手段に蓄積させる第４手段、
   第１のストリームの受信中において、パケットの欠落が発生した場合には、欠落したパケットを特定するとともに、第１手段によって取得したコンテンツ情報に基づいて、第１のストリームとコンテンツが同一で送信開始時刻が第１のストリームより遅い第２のストリームに対応するグループへの参加をネットワーク内のマルチキャスト対応ルータに要求する第５手段、ならびに
   第５手段によるグループ参加要求に基づいて、ネットワーク内のマルチキャスト対応ルータから送信されてきた第２のストリームを受信し、受信した第２のストリームから、第１のストリームの受信において欠落したパケットを取得して、記憶手段に記憶させる第６手段、
   を備えていることを特徴とするマルチキャストデータ配信システムにおけるクライアント。

Images