次に本発明について図面を用いて説明する。
図1は、本発明の情報配信システムの一構成例を示すブロック図である。
図1に示すように、本発明の情報配信システムを適用する通信ネットワークは、情報を送信する通信端末である少なくとも1台の送信端末1と、情報を受信する通信端末である複数の受信端末10とを有する構成である。送信端末1と受信端末10とは、例えばWPAやWPA2等の暗号化方式を採用したIEEE802.11a、IEEE802.11b、IEEE802.11g、IEEE802.11n等の無線通信規格に基づいて情報の送受信が可能に接続される。送信端末1と受信端末10とは、例えば周知のWi−Fi directのように、通信端末間で直接リンクを形成する通信規格に基づいて情報の送受信が可能に接続されていてもよい。
以下では、本発明における配信対象を「コンテンツ」と称するが、配信対象は「情報」全般であり、特定のコンテンツに限定されるものではない。
図2は、図1に示した送信端末及び受信端末となる通信端末の一構成例を示すブロック図である。
図2に示すように、本実施形態の通信端末100は、コンテンツ配信制御部101、MAC(Media Access Control)アドレス変換部102、データパケット傍受部103、コンテンツ復元部104、ネットワーク処理部105、MAC処理部106及びパケット送受信部107を備える。
図1に示した送信端末1及び受信端末10は、図2に示すコンテンツ配信制御部101、MACアドレス変換部102、データパケット傍受部103、コンテンツ復元部104、ネットワーク処理部105、MAC処理部106及びパケット送受信部107を備えた通信端末100であり、コンテンツを送信する場合は送信端末1となり、コンテンツを受信する場合は受信端末10となる。各通信端末100は、自端末が保有しているコンテンツの一覧(コンテンツリスト)を定期的に交換することで、通信ネットワーク内の各通信端末100が保有しているコンテンツを互いに知ることができるものとする。コンテンツリストの交換方法は、例えば非特許文献2(Jonah P. Tower and Thomas D.C. Little, “A Proposed Scheme for Epidemic Routing with Active Curing for Opportunistic Networks”, Proceeding of 22nd International Conference on Advanced Information Networking and Applications, 2008年3月、pp. 1696-1701)に記載された技術で実現できる。非特許文献2では、各通信端末がSummary Vectorと呼ばれる情報(共有情報のリスト)を交換することで、各通信端末で保有する情報を共有する手法が開示されている。
図2に示す通信端末100は、プログラムにしたがって動作するCPU、メモリ、入出力装置、通信回路等を備えた情報処理装置としての機能を備える各種の電気機器で実現できる。通信端末100としては、例えば携帯電話機、PHS(Personal Handyphone System)、PDA(Personal Data Assistance,Personal Digital Assistants)、ゲーム機、デジタルカメラ、ノート型やタブレット型あるいは据え置き型のパーソナルコンピュータ等が考えられる。
本発明の通信端末100は、情報配信用の通信モードとして、通常モードと相乗り通信モードとを有する。通常モードとは、一般的な1対1通信で情報を送受信する通信モードであり、例えば通信プロトコルとしてTCPやTCP/IPを利用して通信を行う。TCPやTCP/IP等を利用する1対1通信は、当業者によく知られた技術であるため、ここではその詳細な説明を省略する。相乗り通信モードとは、送信端末1が選択した特定の受信端末10(以下、代表端末と称す)に対して1対1通信でコンテンツデータをパケット形式で送信しつつ、同時に他の受信端末10に同じパケットを傍受させる通信モードである。
本発明では、相乗り通信モードによる情報配信時、送信端末1から代表端末に1対1通信でデータパケットを送信する際に、送信端末1から代表端末へ送信するデータパケットに含まれる、該データパケットの送信先を示すMACアドレス(第1のMACアドレス)を、該代表端末以外の受信端末10でも傍受可能なMACアドレス(第2のMACアドレス)に変換する。そのようなMACアドレスとしては、例えばブロードキャストアドレスやマルチキャストアドレスがある。また、本発明では、相乗り通信モードによる情報配信時、送信端末1から代表端末に対してデータパケットをブロードキャストやマルチキャスト等の1対多通信用の暗号鍵を用いて暗号化して送信する。送信端末1と代表端末間の1対1通信には、通常モードと同様にTCPやTCP/IP等の通信プロトコルを用いる。
データパケットを傍受する受信端末10は、例えば周知のPromiscuousモードで動作し、自端末のIPアドレス宛ではないパケットを傍受することで、所望のコンテンツのデータパケットを受信できる。データパケットを傍受した受信端末10は、事前に配布されたブロードキャストやマルチキャスト等の1対多通信用の暗号鍵を用いてコンテンツデータを復号してコンテンツを再生する。さらに、本発明では、送信端末1が、配信するコンテンツを予め設定した所定サイズのデータブロックに分割し、該データブロック毎にコンテンツID及びブロックIDを付与して送信する。受信端末10は、データブロックの傍受に失敗した場合、傍受に失敗したデータブロック単位で送信端末1に再送を要求する。
まず、本発明で用いる制御メッセージである、コンテンツリクエスト、コンテンツリプライ、終了メッセージ及び再送リクエストについて説明する。
コンテンツリクエストとは、あるコンテンツ(情報)の受信を希望する通信端末100がそのコンテンツを保有する通信端末100に対して該コンテンツの送信を要求するために使用するメッセージである。コンテンツリクエストには、少なくとも、送信を要求するコンテンツを識別するためのコンテンツIDと、該コンテンツリクエストを送信した通信端末100を識別するためのIDとが含まれる。
コンテンツリプライとは、コンテンツを保有する通信端末100が該コンテンツの送信を要求した通信端末100に対して、要求されたコンテンツを送信する旨を知らせるためのメッセージである。コンテンツリプライには、少なくとも、上記代表端末を識別するためのID、あるいは代表端末のIPアドレスと、該コンテンツリプライを送信した通信端末100を識別するためのIDと、送信対象のコンテンツを識別するためのコンテンツIDとが含まれる。コンテンツを保有する通信端末100が通常モードでコンテンツデータを送信する場合、代表端末のIDのフィールドには、例えば全て「1」が格納される。
終了メッセージとは、コンテンツデータを送信する通信端末100(送信端末1)が相乗り通信モードによるコンテンツの配信が終了したことを、コンテンツデータを受信する通信端末100(受信端末10)に知らせるためのメッセージである。終了メッセージには、少なくとも送信端末1を識別するためのIDと、送信対象のコンテンツを識別するためのコンテンツIDと、終了メッセージであることを示すフラグとが含まれる。
再送リクエストとは、コンテンツの傍受に失敗した受信端末10が、傍受に失敗した該コンテンツのデータブロックの再送を送信端末1に要求するためのメッセージである。再送リクエストには、少なくとも、再送を要求するコンテンツを識別するためのコンテンツIDと、再送を要求するデータブロックのブロックIDと、該再送リクエストを送信する通信端末を識別するためのIDとが含まれる。
図2に示したパケット送受信部107は、ネットワークプロトコルで規定されたPHY層(physical layer)を実現する。パケット送受信部107は、他の通信端末100からパケットを受信すると、受信したパケットをMAC処理部106に出力する。また、自端末のMAC処理部106からパケットを受け取ると、該パケットの宛先である他の通信端末100へ送信する。
MAC処理部106は、ネットワークプロトコルで規定されたMAC層を実現する。MAC処理部106は、ネットワーク処理部105からパケットを受け取ると、MACプロトコルにしたがって所要の処理を実行し、処理後のパケットをパケット送受信部107に出力する。また、MAC処理部106は、パケット送受信部107からパケットを受け取ると、MACプロトコルにしたがって所要の処理を実行し、処理後のパケットをネットワーク処理部105に出力する。さらに、MAC処理部106は、データパケット傍受部103から相乗り通信モードによるパケットの傍受指示(例えば、Promiscuousモードの実行命令)を受け取ると、パケット送受信部107で受信した自端末のIPアドレス宛ではないパケットをデータパケット傍受部103へ出力する。また、MAC処理部106は、MACアドレス変換部102から代表端末へ送信するパケットの送信先のMACアドレスの変換が指示されると、該指示にしたがって、代表端末へ送信するパケットに含まれる、該パケットの送信先のMACアドレスを書き換える。
ネットワーク処理部105は、ネットワークプロトコルにおけるTCPまたはTCP/IP層を実現する。ネットワーク処理部105は、MAC処理部106からパケット(制御メッセージまたはデータパケット)を受け取ると、TCPまたはTCP/IPで規定された周知の処理を実行し、処理後のパケットをコンテンツ配信制御部101に出力する。また、ネットワーク処理部105は、コンテンツ配信制御部101からデータブロックを受け取ると、TCPまたはTCP/IPにしたがって該データブロックを分割してデータパケットを生成し、生成したデータパケットをMAC処理部106に出力する。
上記ネットワーク処理部105、MAC処理部106及びびパケット送受信部107の機能は、例えば通信端末100のOS(Operation System)に含まれるカーネルで実現される。その場合、通信端末100は、カーネルに実装されたTCP/IP、MAC、PHY等のネットワークプロトコルにしたがって処理を実行する。ネットワークプロトコルのTCP/IP、MAC、PHY等にしたがった処理は、当業者によく知られているため、ここではその詳細な説明を省略する。
MACアドレス変換部102は、コンテンツ配信制御部101から相乗り通信モードでコンテンツを配信する指示を受け取った場合、代表端末へ送信するデータパケットに含まれる、該データパケットの送信先のMACアドレスを他の受信端末10でも傍受可能なMACアドレスに変換させる。そのようなアドレスとしては、ブロードキャストアドレス(具体的には「ff-ff-ff-ff-ff-ff」)やマルチキャストアドレスがある。MACアドレスの変換処理は、例えば周知のARP(Address Resolution Protocol)技術を用いることで実現できる。ARPは、送信先のMACアドレスをIPアドレスから求める際に用いる、MACアドレスとIPアドレスの対応関係を示す情報をARPテーブルとして保存・更新する技術である。ARPは、当業者によく知られた技術であるため、ここではその詳細な説明を省略する。
データパケット傍受部103は、コンテンツ配信制御部101から相乗り通信モードによるデータパケットの傍受の起動命令を受け取った場合、自端末のIPアドレス宛ではないパケットを受信するようMAC処理部106に指示する。このような傍受機能は、例えばUNIX(登録商標)系のOSで提供されるパケットキャプチャー用のライブラリ(プログラム)であるLibpcap(Windows(登録商標)の場合はWinpcap等)のPromiscuousモードを起動することで実現できる。Promiscuousモードによるパケットの傍受は一般的な技術であるため、ここでは詳細な説明を省略する。以下では、受信端末10がデータパケットを傍受する動作を「傍受モード」と称す。また、データパケット傍受部103は、MAC処理部106から受け取ったデータパケットからデータブロックを組み立て、組み立てたデータブロックをコンテンツ復元部104に出力する。
コンテンツ復元部104は、コンテンツ配信制御部101またはデータパケット傍受部103から受け取ったデータブロックを組み立て、元のコンテンツを復元する。コンテンツを構成する全てのデータブロックが揃わない場合、コンテンツ復元部104は、不足するデータブロック、すなわち傍受に失敗したデータブロック(以下、傍受失敗データブロックと称す)のブロックIDをコンテンツ配信制御部101に通知する。
コンテンツ配信制御部101は、本発明のコンテンツ配信方法を実現する制御装置である。
自端末が送信端末1である場合、コンテンツ配信制御部101は、ネットワーク処理部105を介してコンテンツリクエストを受信すると、予め設定された所定時間(待機時間)内に到着したコンテンツリクエスト数に基づいて通常モードでコンテンツを配信するか、相乗り通信モードでコンテンツを配信するかを決定する。コンテンツ配信制御部101は、待機時間内に予め設定されたしきい値以上のコンテンツリクエストを受信した場合、相乗り通信モードでコンテンツを送信すると決定し、コンテンツリクエストがしきい値よりも少なければ通常モードでコンテンツを送信すると決定する。また、コンテンツ配信制御部101は、相乗り通信モードでコンテンツを送信すると決定した場合、予め決められた選択方法にしたがって代表端末を選択する。代表端末の選択方法としては、例えばコンテンツリクエストを送信した受信端末10のうち、ランダムに1台の受信端末10を代表端末として選択する方法がある。コンテンツ配信制御部101は、代表端末を選択すると、選択した受信端末10のIDをコンテンツリプライに格納し、該コンテンツリプライをネットワーク処理部105からコンテンツリクエストを送信した受信端末10にブロードキャストさせる。さらに、コンテンツ配信制御部101は、代表端末へ送信するパケットに含まれる、該パケットの宛先(送信先)を示すMACアドレスを他の受信端末10でも傍受可能なMACアドレスに変換するようMACアドレス変換部102に指示する。そして、コンテンツ配信制御部101は、配信するコンテンツデータを所定サイズのデータブロックに分割し、各データブロックにコンテンツID及びブロックIDを付与した後、ネットワーク処理部106に出力する。相乗り通信モードによるコンテンツの送信が終了した場合、コンテンツ配信制御部101は、終了メッセージを生成して、ネットワーク処理部105に出力する。
一方、自端末が受信端末10である場合、コンテンツ配信制御部101は、ネットワーク処理部105を介してコンテンツリプライを受け取ると、該コンテンツリプライの情報に基づいて傍受モードでコンテンツを受信すべきか否かを判定する。傍受モードでコンテンツを受信すると判定した場合、コンテンツ配信制御部101は、データパケットを傍受するようにデータパケット傍受部103に指示する。自端末が代表端末である場合、コンテンツ配信制御部101は、ネットワーク処理部105を介して受け取ったデータパケットからデータブロックを組み立て、該データブロックをコンテンツ復元部104に出力する。以下では、受信端末10が代表端末としてデータパケットを受信する動作を「代表モード」と称す。自端末が傍受モードで動作中であり、相乗り通信モードの終了メッセージを受信した場合、コンテンツ配信制御部101は、傍受失敗データブロックがあるか否かを確認する。傍受失敗データブロックがある場合、コンテンツ配信制御部101は、該傍受失敗データブロックを送信端末1に再送させるための再送リクエストを生成し、該再送リクエストをネットワーク処理部105に出力する。
以下、通信端末100がコンテンツを受信する場合とコンテンツを送信する場合とに分けて、本発明のコンテンツ配信方法について説明する。
まず、図2〜図5を用いて、本実施形態の通信端末100がコンテンツを受信する場合の動作について説明する。
図3は、図2に示した通信端末のコンテンツ受信時の処理手順の一例を示すフローチャートである。図4は図3に示したステップA6の処理手順の一例を示すフローチャートであり、図5は図3に示したステップA7の処理手順の一例を示すフローチャートである。
なお、上述したように各通信端末100は、自端末が保有しているコンテンツの一覧(コンテンツリスト)を定期的に交換することで、通信ネットワーク内の各通信端末100で保有している情報を共有しているものとする。
図3に示すように、通信端末100のユーザが、不図示の入力装置を用いて他の通信端末100が保有するコンテンツの受信指示を入力すると、該通信端末100のコンテンツ配信制御部101は、指定されたコンテンツの送信を要求するコンテンツリクエストを生成し、ネットワーク処理部105に出力する。
ネットワーク処理部105は、所定のプロトコル(TCPまたはTCP/IP等)にしたがってコンテンツリクエストを処理し、処理後のコンテンツリクエストをMAC処理部106に出力する。MAC処理部106は、MACプロトコルにしたがってコンテンツリクエストを処理し、処理後のコンテンツリクエストをパケット送受信部107に出力する。パケット送受信部107は、コンテンツを保有する、指定された通信端末100(送信端末1)にコンテンツリクエストを送信する(ステップA1)。
パケット送受信部107は、送信端末1からコンテンツリプライを受信すると、該コンテンツリプライをMAC処理部106に出力する。
MAC処理部106は、MACプロトコルにしたがってコンテンツリプライを処理し、処理後のコンテンツリプライをネットワーク処理部105に出力する。ネットワーク処理部105は、所定のプロトコル(TCPまたはTCP/IP等)にしたがってコンテンツリプライを処理し、処理後のコンテンツリプライをコンテンツ配信制御部101に出力する。
コンテンツ配信制御部101は、コンテンツリプライを受け取ると(ステップA2)、該コンテンツリプライの内容を参照し、送信端末1が相乗り通信モードでコンテンツを送信するか否かを確認する(ステップA3)。
送信端末1が相乗り通信モードでコンテンツを送信しない場合、すなわちコンテンツリプライの代表端末IDのフィールドが特定の値(例えば、代表端末IDのフィールドが4bitであり、その値が「1111」)である場合、以降、受信端末10は通常モードでコンテンツを受信する(ステップA4)。
送信端末1が相乗り通信モードでコンテンツを送信する場合、すなわちコンテンツリプライの代表端末IDのフィールドが上記特定の値以外である場合、コンテンツ配信制御部101は、該フィールドの値が自端末のIDであるか否かを確認する(ステップA5)。
コンテンツリプライの代表端末IDのフィールドが自端末のIDと一致する場合、すなわち自端末が相乗り通信モードの代表端末に選択されている場合、受信端末10はステップA6の処理へ移行し代表モードとして動作する。ステップA6において、受信端末10は、例えば図4に示す手順にしたがって処理を実行する。
ステップA6において、受信端末10は、パケット送受信部107によりパケットを受信すると、受信したパケットをMAC処理部106及びネットワーク処理部105を介してコンテンツ配信制御部101に出力する(ステップA8)。
コンテンツ配信制御部101は、ネットワーク処理部105からパケットを受け取ると、受け取ったパケットがデータパケットであるか否か(制御メッセージではないこと)を確認し、データパケットの場合は該データパケットからデータブロックを組み立て、該データブロックをコンテンツ復元部104に出力する(ステップA9)。
コンテンツ復元部104は、コンテンツ配信制御部101から全てのデータブロックを受け取ると、コンテンツを復元して処理を終了する(ステップA10)。
ステップA5において、コンテンツリプライの代表端末IDのフィールドが自端末のIDと一致しない場合、すなわち自端末が相乗り通信モードの代表端末に選択されていない場合、コンテンツ配信制御部101は、データパケット傍受部103にデータパケットを傍受モードで受信するよう指示する。
データパケット傍受部103は、コンテンツ配信制御部101から傍受モードの起動命令を受け取ると、自端末のIPアドレス宛ではないパケットを受信するようMAC処理部106に指示する。具体的には、上記LibpcapやWinpcap等のPromiscuousモードの受信プログラムを起動することで、自端末のIPアドレス宛ではないパケットを受信させる。
続いて、受信端末10は、ステップA7の処理へ移行し、例えば図5に示す手順にしたがって処理を実行する。
ステップA7において、受信端末10は、パケット送受信部107でパケットを受信すると、受信したパケットをMAC処理部106に出力する。MAC処理部106は、受け取ったパケットをMACプロトコルにしたがって処理し、処理後のパケットをコピーしてデータパケット傍受部103に出力する(ステップA11)。
データパケット傍受部103は、受け取ったパケットが自端末から送信を要求したコンテンツのデータパケットであるか否かを確認する。具体的には、パケットの宛先MACアドレスがブロードキャストアドレスであり、かつ宛先IPアドレスが代表端末のIPアドレスと一致しており、かつ送信元IPアドレスがコンテンツリクエストを送信した送信端末1のIPアドレスと一致しており、かつIPヘッダのプロトコル番号がTCP(6)である場合、受け取ったパケットが自端末から送信を要求したコンテンツのデータパケットである可能性が高いと判定する。
受け取ったパケットが送信を要求したコンテンツのデータパケットである場合、データパケット傍受部103は、受信したパケットのTCPヘッダにある宛先ポート番号と送信元ポート番号の組が一致するデータパケット群毎に該データパケットからデータブロックを組み立て、組み立てたデータブロックのコンテンツIDが送信を要求したコンテンツIDと一致する場合はコンテンツ復元部104に出力する。このとき、データブロックを構成する全てのデータパケットを受信できなかった場合、データパケット傍受部103は、データブロックを組み立てられないため、データブロックをコンテンツ復元部104に出力しない。
受け取ったパケットが送信を要求したコンテンツのデータパケットでない場合、あるいは該データパケットのコピーを既に受け取っている場合、データパケット傍受部103は、MAC処理部106から受け取ったパケットを廃棄する。
また、コンテンツ配信制御部101は、パケット送受信部107、MAC処理部106、ネットワーク処理部105を介してパケットを受け取ると、該受信したパケットが終了メッセージであるか否かを確認する(ステップA12)。
受信したパケットが終了メッセージでない場合、コンテンツ配信制御部101は、ステップA11の処理に戻って、データパケット傍受部103に引き続き傍受モードでデータパケットを受信させる。
受信したパケットが終了メッセージの場合、コンテンツ配信制御部101は、コンテンツ復元部104にデータパケット傍受部103で受信したデータブロックを用いてコンテンツを復元させる。このとき、コンテンツ配信制御部101は、傍受失敗データブロックがあるか否かを確認する(ステップA13)。傍受失敗データブロックがあるか否かは、例えばコンテンツを構成するデータブロックが不足する場合、例えば受信したブロックIDが連続値でない場合に傍受失敗データブロックがあると判定する。
傍受失敗データブロックが無い場合、コンテンツ配信制御部101は、受信したデータブロックを組み立て、コンテンツ復元部104にコンテンツを復元させて(ステップA14)処理を終了する。
一方、傍受失敗データブロックがある場合、コンテンツ配信制御部101は、コンテンツ復元部104に傍受失敗データブロックの情報を通知させる。コンテンツ配信制御部101は、コンテンツ復元部104から傍受失敗データブロックの情報が通知されると、該傍受失敗データブロックの再送を要求するための再送リクエストを生成し、該再送リクエストを、ネットワーク処理部105、MAC処理部106及びパケット送受信部107を介して送信端末1に送信する(ステップA15)。再送リクエストの送信処理は、図3で示したステップA1におけるコンテンツリクエストの送信手順と同様であるため、ここではその説明を省略する。
受信端末10は、送信端末から再送された全ての傍受失敗データブロックを受信すると(ステップA16)、コンテンツ配信制御部101によりデータブロックを組み立て、コンテンツ復元部104にコンテンツを復元させて処理を終了する。なお、傍受失敗データブロックは、TCPやTCP/IP等の既存の通信プロトコルを用いて再送してもよく、相乗り通信モードで再送してもよい。相乗り通信モードで傍受失敗データブロックを再送する場合、図5に示すステップA16の処理は、本実施形態の通信端末100におけるコンテンツの受信処理(ステップA1〜ステップA16)と同様である。
次に、図2及び図6〜図7を用いて、本実施形態の通信端末100がコンテンツを送信する場合の動作について説明する。
図6は図2に示した通信端末のコンテンツ送信時の処理手順の一例を示すフローチャートであり、図7は図6に示したステップB5の処理手順の一例を示すフローチャートである。
図6に示すように、送信端末1がパケット送受信部107によりコンテンツリクエストを受信すると、該コンテンツリクエストはMAC処理部106及びネットワーク処理部105を介してコンテンツ配信制御部101に出力される(ステップB1)。
コンテンツ配信制御部101は、予め設定された所定時間以内に受信したコンテンツリクエストのうち、異なる端末IDを含むコンテンツリクエスト数をカウントすることで、同一コンテンツの受信を希望する通信端末100が予め設定されたしきい値以上であるか否かを確認する(ステップB2)。
同一コンテンツの受信を希望する通信端末100数がしきい値よりも少ない場合、送信端末1は、コンテンツリプライの代表端末IDのフィールドに特定の値(例えば「1111」)を格納し、受信端末10宛に該コンテンツリプライを送信した後、TCPやTCP/IP等(通常モード)にしたがってコンテンツを受信端末10に送信する(ステップB3)。この場合、送信端末1は、受信端末10がコンテンツを構成する全てのデータブロックの受信を完了するまでTCPやTCP/IP等にしたがってコンテンツを配信する。
コンテンツの受信を希望する通信端末100数がしきい値以上である場合、送信端末1は、コンテンツ配信制御部101により相乗り通信モードでコンテンツを送信すると決定し、コンテンツリクエストを送信した受信端末10から予め決められた選択方法にしたがって代表端末を選択する(ステップB4)。
代表端末を選択すると、送信端末1は、ステップB5の処理に移行して相乗り通信モードでコンテンツを送信する。ステップB5において、送信端末1は、例えば図7に示す手順にしたがって処理を実行する。
送信端末1が相乗り通信モードでコンテンツを送信する場合、コンテンツ配信制御部101は、代表端末として選択した受信端末10の端末IDをコンテンツリプライの代表端末IDのフィールドに格納し、該代表端末IDを含むコンテンツリプライをネットワーク処理部105、MAC処理部106及びパケット送受信部107を介してコンテンツリクエストを送信した全ての受信端末10にブロードキャストする(ステップB6)。
コンテンツ配信制御部101は、コンテンツリプライをネットワーク処理部105に出力すると、代表端末へ送信するパケットに含まれる、該パケットの宛先を示すMACアドレスを他の受信端末10でも傍受可能なMACアドレス(例えば、ブロードキャストアドレス)に変換するようMACアドレス変換部102に指示する。MACアドレス変換部102は、コンテンツ配信制御部101の指示にしたがってMACアドレスの変換処理を実行する(ステップB7)。
以降、送信端末1は、TCPやTCP/IP等の通信プロトコルにしたがって代表端末にコンテンツを送信する(ステップB8)。代表端末に対するコンテンツの送信が終了すると、送信端末1は、終了メッセージをブロードキャストし、傍受中の全ての受信端末10にコンテンツの配信終了を通知する(ステップB9)。終了メッセージの送信処理は、図3で示したステップA1におけるコンテンツリクエストの送信手順と同様であるため、ここではその説明を省略する。
次に、送信端末1は、コンテンツ配信制御部101により予め設定された所定時間内に代表端末以外の受信端末10(傍受中の受信端末)から再送リクエストを受信したか否かを確認する(ステップB10)。
傍受中の受信端末10から再送リクエストを受信しなかった場合、送信端末1は処理を終了する。
傍受中の受信端末10から再送リクエストを受信した場合、送信端末1は再送リクエストを送信した受信端末10に対して要求されたデータブロックを再送する(ステップB11)。なお、傍受失敗データブロックは、TCPやTCP/IP等の既存の通信プロトコルを用いて再送してもよく、相乗り通信モードで再送してもよい。相乗り通信モードで傍受失敗データブロックを再送する場合、図7に示すステップB11の処理は、本実施形態の通信端末100におけるコンテンツの送信処理(ステップB1〜ステップB11)と同様である。
上述したように、本発明では、相乗り通信モードにおけるコンテンツ配信時、送信端末1から代表端末に1対1通信でコンテンツのデータパケットを送信すると共に、該データパケットを他の受信端末10でも傍受できるように送信端末1によって該データパケットの送信先を示すMACアドレスを、例えばブロードキャストアドレスやマルチキャストアドレスに変換する。また、本発明では、相乗り通信モードによるコンテンツの配信時、送信端末1から代表端末に対してコンテンツのデータパケットをブロードキャストやマルチキャスト等の1対多通信用の暗号鍵を用いて暗号化して送信する。送信端末1と代表端末間の1対1通信には、通常モードと同様にTCPやTCP/IP等の通信プロトコルを用いる。
さらに、本発明では、コンテンツのデータパケットを傍受する受信端末10が、例えばPromiscuousモードで動作し、自端末のIPアドレスを宛先としないパケットであっても受信することで、所望のコンテンツのデータパケットを傍受できる。データパケットを傍受した受信端末10は、事前に配布されたブロードキャストやマルチキャスト等の1対多通信用の暗号鍵を用いてコンテンツデータを復号してコンテンツを再構築する。また、本発明では、受信端末10がコンテンツのデータブロックの傍受に失敗した場合、該受信端末10は、傍受に失敗したデータブロック単位で送信端末1に再送を要求し、該再送要求にしたがって送信端末1から傍受失敗データブロックを受信できる。
そのため、本発明によれば、WPAやWPA2等のように、1対多通信と1対1通信とで用いる暗号鍵が異なり、1対1通信においても通信相手毎に異なる暗号鍵を用いる暗号化方式を使用した通信ネットワークであっても、送信端末1から代表端末へ、例えばTCPまたはTCP/IPのような信頼性の高いトランスポートプロトコルを用いてコンテンツを配信しつつ、同一のコンテンツを他の受信端末10でも受信させることができる。
したがって、配信効率を向上させつつ、信頼性の高い通信方式によりコンテンツを配信することが可能になる。
なお、本実施形態では、送信端末1と代表端末間の1対1通信にTCPやTCP/IPを用いる例を示したが、送信端末1と代表端末間の通信プロトコルはTCPやTCP/IPに限定されるものではなく、再送機能を追加したUDP(User Datagram Protocol)等、他の信頼性の高い通信プロトコルを用いてもよい。
また、本実施形態では、送信端末1が相乗り通信モードでコンテンツを配信する場合に1台の代表端末を固定的に選択する例を示したが、送信端末1は、複数台の代表端末を選択してもよい。その場合、例えば所定量のコンテンツデータを送信する毎に代表端末を変更すればよい。
さらに、本実施形態では、各通信端末100が無線通信によりコンテンツを送受信する例を示したが、通信端末100間は有線通信によりコンテンツを送受信してもよい。
また、本実施形態では、送信端末1から受信端末10にコンテンツを直接送信する例で説明したが、送信端末1と受信端末10間には、送信端末1と受信端末10間で送受信する情報を中継する各種の中継装置(ルータ、ブリッジやアクセスポイント等)が挿入されていてもよい。その場合、受信端末10と通信する中継装置に、図2に示したコンテンツ配信制御部101、MACアドレス変換部102、データパケット傍受部103、コンテンツ復元部104、ネットワーク処理部105、MAC処理部106及びパケット送受信部107の機能を備えていてもよい。
また、本実施形態では、送信端末1が代表端末との通信終了を他の受信端末10へ通知するために終了メッセージを使用する例を示したが、送信端末1と代表端末との通信終了は終了メッセージを使用しなくても代表端末以外の受信端末10で知ることが可能である。例えば、代表端末以外の受信端末10は、代表端末が送信端末1から最終のデータブロックを受信したことを検出した場合に、送信端末1と代表端末間の通信が終了すると判断してもよい。あるいは、代表端末以外の受信端末10は、送信端末1と代表端末間の通信レート及び残りの通信データサイズを計算し、その計算結果に基づいて送信端末1と代表端末間の通信が終了する時刻を推測し、該推測した時刻が過ぎた時点(タイムアウト)で通信終了と判断してもよい。
また、本実施形態では、各受信端末10がコンテンツを1台の送信端末から受信する例で示したが、受信端末10はコンテンツを受信する通信端末100を変更してもよい。例えば、傍受モードによる1回目の処理サイクルにおけるコンテンツデータの傍受が終了し、傍受失敗データブロックの再送を要求する場合、再送を要求する通信端末100は、最初にコンテンツの送信を要求した通信端末100である必要はなく、当該コンテンツを保有する他の通信端末100に再送を要求してもよい。
さらに、本実施形態では、コンテンツリプライを用いて代表端末のID(もしくはIPアドレス)を受信端末10に通知し、受信端末10が該代表端末のIDのフィールドの値に基づいて、通常モード、代表モードまたは傍受モードで受信処理を実行する例を示したが、代表端末のID(もしくはIPアドレス)等は予め設けた専用の制御メッセージを用いて受信端末10に通知してもよい。その場合、コンテンツリプライには、受信端末10からのコンテンツリクエストを送信端末1が正しく受信できたことを通知する働きを持たせればよい。
次に本発明の実施例について図面を用いて説明する。
(第1実施例)
図8は、本発明のコンテンツ配信システムの第1実施例の構成を示すブロック図である。
第1実施例のコンテンツ配信システムは、送信端末11、受信端末101及び受信端末102を有する構成である。送信端末11、受信端末101及び受信端末102は、例えばWPAやWPA2等の暗号化方式を採用する通信ネットワークを構成する。
以下では、送信端末11がコンテンツAを保有し、受信端末101及び102が該コンテンツAを受信するものとする。また、コンテンツリクエストの待機時間を100msとし、相乗り通信モードで動作するか否かを判定するためのコンテンツリクエスト数のしきい値を「2」とする。さらに、代表端末は、コンテンツリクエストを送信した受信端末10のなかから1台の受信端末10をランダムに選択するものとする。また、受信端末101のIDを「0001」とし、受信端末102のIDを「0010」とする。また、受信端末101のIPアドレスは「192.168.0.101」とする。
まず、送信端末11から受信端末101及び102へコンテンツを配信する場合の動作について説明する。
受信端末101及び受信端末102は、ユーザによって受信を希望するコンテンツAが指定されると、送信端末11にコンテンツAの送信を要求するコンテンツリクエストを送信する(図3のステップA1)。送信端末11は、受信端末101及び102から送信されたコンテンツリクエストを受信する(図6のステップB1)。ここでは、送信端末11が、待機時間である100ms以内に受信端末101及び受信端末102からそれぞれコンテンツリクエストを受信したものとする。
送信端末11は、コンテンツリクエスト数がしきい値「2」以上であるため、相乗り通信モードでコンテンツを送信することを決定し、受信端末101及び102からランダムに1台の代表端末を選択する(図6のステップB4)。ここでは受信端末101を代表端末として選択する。また、送信端末11は、相乗り通信モードでコンテンツを送信することを受信端末101及び102に通知するため、代表端末ID「0001」を含むコンテンツリプライをブロードキャストする(図7のステップB6)。
受信端末101は、送信端末11からコンテンツリプライを受信すると(図3のステップA2)、コンテンツが相乗り通信モードで配信されるか否かを確認する(図3のステップA3)。ここでは受信したコンテンツリプライに含まれる代表端末IDのフィールドが特定の値(例えば、「1111」)ではないため、受信端末101は、送信端末11が相乗り通信モードでコンテンツを配信すると判定する。また、受信端末101は、コンテンツリプライに含まれる代表端末IDのフィールドの値が自端末のIDと一致するため、自端末が代表端末に選択されたと判定する(図3のステップA5)。以降、受信端末101は、代表モードで動作して送信端末1から送信されるコンテンツを受信する(図3のステップA6)。
一方、受信端末102は、送信端末11からコンテンツリプライを受信すると(図3のステップA2)、コンテンツが相乗り通信モードで配信されるか否かを確認する(図3のステップA3)。ここでは受信したコンテンツリプライに含まれる代表端末IDのフィールドが特定の値(例えば、「1111」)ではないため、受信端末102は、送信端末11が相乗り通信モードでコンテンツを配信すると判定する。また、受信端末102は、コンテンツリプライに含まれる代表端末IDのフィールドの値が自端末のIDと一致しないため、自端末が代表端末ではないと判定する(図3のステップA5)。以降、受信端末102は、傍受モードで動作して送信端末1から受信端末101に送信されるコンテンツを傍受する(図3のステップA7)。
送信端末11は、コンテンツの配信時、代表端末(受信端末101)へ送信するデータパケットの宛先を示すMACアドレスを、代表端末(受信端末101)のMACアドレスからブロードキャストアドレスに変換する。具体的に、MACアドレスは、OSのコマンドを用いて変換できる。例えば、送信端末11がWindows(登録商標)端末の場合、コマンドプロンプト等で「arp -s 192.168.0.101 FF-FF-FF-FF-FF-FF」を実行することで、受信端末101へ送信するデータパケットの宛先を示すMACアドレスをブロードキャストアドレスに変換できる(図7のステップB7)。この結果、受信端末102は送信端末11から受信端末101へ送信されるデータパケットを傍受できるようになる。
ここで、送信端末11が、コンテンツAをデータブロックA1とデータブロックA2とに分割したとする。この場合、送信端末11は、代表端末である受信端末101に対してTCP/IPを用いてデータブロックA1を少なくとも1つのデータパケットに分割して送信を開始する(図7のステップB8)。
受信端末101は、送信端末11からデータブロックA1のデータパケットを受信すると(図4のステップA8)、受信したデータパケットからデータブロックA1を組み立てる(図4のステップA9)。
受信端末102は、送信端末11が受信端末101に送信したデータパケットを傍受モードで受信し、受信したデータパケットからデータブロックA1を組み立てる(図5のステップA11)。
続いて、送信端末11は、データブロックA2のデータパケットを受信端末101に送信し、受信端末101は受信したデータパケットからデータブロックA2を組み立てる。ここでは、受信端末102が、通信環境の劣化等により送信端末11から送信されたデータブロックA2を正常に受信できなかったものとする。
この場合、受信端末101は、全てのデータブロックが揃っているため、コンテンツAを復元する(図4のステップA10)。この段階で、送信端末11は、コンテンツAの全データブロックを代表端末である受信端末101に送信し終わったため、終了メッセージをブロードキャストし、相乗り通信モードによるコンテンツの配信終了を受信端末102にも知らせる(図7のステップB9)。
終了メッセージを受信した受信端末102は、相乗り通信モードの終了を検知すると(図5のステップA12)、傍受失敗データブロックがあるか否かを確認する(図5のステップA13)。ここでは、データブロックA2の傍受を失敗しているため、受信端末102はデータブロックA2を再送するよう送信端末11に再送リクエストを送信する(図5のステップA15)。
送信端末11は、受信端末102からデータブロックA2の再送要求を受信すると、受信端末102に要求されたデータブロックA2を再送する(図7のステップB11)。
受信端末102は、送信端末11から再送されたデータブロックA2を受信し(図5のステップA16)、データブロックA1及びA2が揃った時点でそれらを組み立ててコンテンツAを復元する。
このようにして、送信端末11は受信端末101及び102に対するコンテンツの配信を終了する。
(第2実施例)
図9は、本発明のコンテンツ配信システムの第2実施例の構成を示すブロック図である。
図9に示すように、第2実施例のコンテンツ配信システムは、コンテンツを送信する通信端末である送信端末2と、コンテンツを受信する通信端末である複数台の受信端末20と、送信端末2と受信端末20間で送受信されるデータを中継するブリッジであるアクセスポイント30とを有する。
第2実施例のコンテンツ配信システムは、送信端末2と受信端末20間にアクセスポイント30が挿入される点で第1実施例のコンテンツ配信システムと異なっている。送信端末2及び受信端末20の構成、並びに動作は、第1実施例の送信端末11、並びに受信端末101及び102と同様であるため、その説明は省略する。送信端末2とアクセスポイント30間は無線通信で情報の送受信が可能に接続されていてもよく、有線通信で情報の送受信が可能に接続されていてもよい。
なお、図9に示す第2実施例のコンテンツ配信システムでは、アクセスポイント30に、図2に示したコンテンツ配信制御部101、MACアドレス変換部102、データパケット傍受部103、コンテンツ復元部104、ネットワーク処理部105、MAC処理部106及びパケット送受信部107の機能を備えていてもよい。
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されものではない。本願発明の構成や詳細は本願発明のスコープ内で当業者が理解し得る様々な変更が可能である。
この出願は、2012年11月30日に出願された特願2012−262933号を基礎とする優先権を主張し、その開示の全てをここに取り込む。