JP6323336B2 - 情報配信システム、情報配信方法、通信端末及びプログラム - Google Patents

情報配信システム、情報配信方法、通信端末及びプログラム Download PDF

Info

Publication number
JP6323336B2
JP6323336B2 JP2014550066A JP2014550066A JP6323336B2 JP 6323336 B2 JP6323336 B2 JP 6323336B2 JP 2014550066 A JP2014550066 A JP 2014550066A JP 2014550066 A JP2014550066 A JP 2014550066A JP 6323336 B2 JP6323336 B2 JP 6323336B2
Authority
JP
Japan
Prior art keywords
terminal
information
communication
content
representative
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.)
Active
Application number
JP2014550066A
Other languages
English (en)
Other versions
JPWO2014083922A1 (ja
Inventor
ブンパデイット カンニヤウオン
ブンパデイット カンニヤウオン
藤田 範人
範人 藤田
則夫 山垣
則夫 山垣
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JPWO2014083922A1 publication Critical patent/JPWO2014083922A1/ja
Application granted granted Critical
Publication of JP6323336B2 publication Critical patent/JP6323336B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868Measures taken after transmission, e.g. acknowledgments

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、通信端末から他の通信端末へ情報を配信するための情報配信システム、情報配信方法、通信端末及びプログラムに関する。
通信端末から他の通信端末へ情報を配信する方式としては、大きく分けて1対1通信と1対多通信とがある。1対1通信の代表的な通信プロトコルとしてはTCP(Transport Control Protocol)やTCP/IP(Internet Protocol)が知られている。このような1対1通信で複数の通信端末に同じコンテンツを配信する場合、各通信端末に1台ずつコンテンツを送信していると、コンテンツの送信先となる通信端末数が増える程、配信に要する時間が長くなり通信効率が低下する。
一方、1対多通信の方式としてはブロードキャスト方式とマルチキャスト方式とがある。これらの通信方式では、複数の通信端末に対して同じコンテンツを同時に配信できるため、高い通信効率でコンテンツを配信できる。しかしながら、一般的なブロードキャスト方式やマルチキャスト方式では、通信端末間で再送要求や確認応答等の制御メッセージの送受信、あるいは消失パケットの再送等を行わないため、通信の信頼性が低いという課題がある。
また、上記のような1対多通信において、制御メッセージの送受信や消失パケットの再送等を行う場合、複数の通信端末でパケットを正常に受信できないと、それらの通信端末毎に制御メッセージの送受信やパケットの再送を行う必要がある。そのため、制御メッセージの送受信や消失パケットの再送に要する処理負荷が大きくなる問題がある。また、1対多通信では1対1通信のように輻輳制御を効果的に実施することも困難である。
このような問題を解決するコンテンツ配信方式の一例が非特許文献1や特許文献1で提案されている。
非特許文献1及び特許文献1には、コンテンツを配信する通信端末(送信端末)が特定の通信端末に1対1通信でコンテンツを送信し、それと同時に送信端末から特定の通信端末に送信されているコンテンツデータを他の通信端末(受信端末)にも傍受させる方法が記載されている。
なお、電力線通信(PLC:Power Line Communication)システムや無線LAN(Local Area Network)等のように、通信速度の変動が激しいモデムを使用する場合でも大容量のデータをマルチキャストできるマルチキャスト通信システムが、例えば特許文献2で提案されている。特許文献2には、通信速度が変動し易いPLCシステムや無線LAN等をサブネットワークとするマルチキャスト通信システムにおけるマルチキャストパケットの転送方法について記載されている。
上述した非特許文献1及び特許文献1に記載された技術では、特定の通信端末に対してコンテンツを1対1通信方式で送信し、それと同時に送信端末から特定の通信端末に送信されているコンテンツデータを他の通信端末にも傍受させるため、信頼性の高い通信を実現しつつ、より短い時間で効率よく複数の通信端末にコンテンツを配信できる。
ところで、現在、多くの通信ネットワークでは、送受信するデータが第三者に不正に取得されるのを防止するため、送受信対象のデータを所定の暗号鍵を用いて符号化(暗号化)する暗号化方式が採用されている。例えば無線LAN等では、1対多通信と1対1通信とで異なる暗号鍵を用い、さらに1対1通信において通信相手毎に異なる暗号鍵を用いるWPA(Wi-Fi Protected Access)やWPA2等の暗号化方式が採用されている。このような暗号化方式を採用した通信ネットワークに上記非特許文献1や特許文献1に記載された技術を適用すると、送信端末と1対1通信を行っていない通信端末は、暗号化されたコンテンツデータを傍受することになるため、該コンテンツデータを復号してコンテンツを再生する必要がある。
しかしながら、上記非特許文献1及び特許文献1では、暗号化方式を採用した通信ネットワークにおける具体的な処理方法に何も言及していないため、送信端末と1対1通信を行っていない通信端末は、1対1通信用の暗号鍵を取得できず、コンテンツを再生することができない。すなわち、非特許文献1や特許文献1に記載された技術では、暗号化方式を採用する通信ネットワークにおいて、情報の配信を実現することが困難である。
なお、上述したように、特許文献2にはPLCシステム(または無線LAN等)をサブネットワークとして備えるマルチキャスト通信システムが記載されている。特許文献2に記載された通信システムでは、通信速度が変動し易いPLCシステムにおけるモデム間ではマルチキャストパケットをマルチキャスト通信で転送せず、送信側のモデムは一旦マルチキャストパケットをユニキャストパケットに変換してから1対1通信で受信側のモデムに転送する。さらに、特許文献2に記載された通信システムでは、該変換されたユニキャストパケットを受信した受信側のモデムをマルチキャストパケットに戻し、マルチキャストパケットを必要とする(イーサネット(登録商標)で接続された)端末に対してマルチキャスト通信で転送する。このように、PLCシステム(電力線)におけるモデム間ではマルチキャストパケットの転送を1対1通信で実現し、イーサネット(登録商標)で接続された端末に対してマルチキャストパケットをマルチキャスト通信で転送することで、マルチキャスト通信の通信速度の変動が大きいPLCシステムをサブネットワークとするネットワークにおいて、適切にマルチキャストパケットを転送できる。
しかしながら、上記特許文献2に記載された通信システムおけるマルチキャスト通信では、送信側のモデムと受信側の端末間の通信は再送機能を持たないマルチキャスト通信であるため、高い信頼性が期待できず、上記背景技術で既に述べた1対多通信(マルチキャストを含む)の課題(通信の信頼性が低い)が解決されていない。
特開2001−147883号公報 特開2008−187626号公報
鶴田 節夫、宮本捷二著、「大量データの高効率送信用簡易高信頼ブロードキャストプロトコルの提案と評価」、情報処理学会論文誌出版、1986年4月、Vol.27、No.4、pp.462−470
そこで、本発明は、配信効率を向上させつつ、信頼性の高い通信方式で情報を配信することが可能な情報配信システム、情報配信方法、通信端末及びプログラムを提供することを目的とする。
上記目的を達成するため本発明の情報配信システムは、予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた1対1通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換して送信する送信端末と、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信し、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する1台以上の受信端末と、
を有する。
一方、本発明の情報配信方法は、送信端末が、
予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、
前記代表端末に対して信頼性のある通信プロトコルを用いた1対1通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換して送信し、
前記送信端末から前記情報を受信する複数の受信端末が、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信し、
前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する方法である。
本発明の通信端末は、情報を送信する送信端末または前記情報を受信する受信端末として動作する通信端末であって、
前記送信端末として動作するとき、予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた1対1通信で前記情報を送信し、前記受信端末として動作するとき、前記情報を送信する送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信するコンテンツ配信制御部と、
前記送信端末として動作するとき、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換するMACアドレス変換部と、
前記受信端末として動作するとき、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受するデータパケット傍受部と、
を有する。
また、本発明のプログラムは、通信端末を、情報を送信する送信端末として動作させる、または前記情報を受信する受信端末として動作させるためのプログラムであって、
前記通信端末を前記送信端末として動作させるとき、
予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択させ、
前記代表端末に対して1対1通信で前記情報を送信させると共に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換させて送信させ、
前記通信端末を前記受信端末として動作させるとき、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信させ、
前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求させるためのものである。
図1は、本発明の情報配信システムの一構成例を示すブロック図である。 図2は、図1に示した送信端末及び受信端末となる通信端末の一構成例を示すブロック図である。 図3は、図2に示した通信端末の情報受信時の処理手順の一例を示すフローチャートである。 図4は、図3に示したステップA6の処理手順の一例を示すフローチャートである。 図5は、図3に示したステップA7の処理手順の一例を示すフローチャートである。 図6は、図2に示した通信端末の情報送信時の処理手順の一例を示すフローチャートである。 図7は、図6に示したステップB5の処理手順の一例を示すフローチャートである。 図8は、本発明の情報配信システムの第1実施例の構成を示すブロック図である。 図9は、本発明の情報配信システムの第2実施例の構成を示すブロック図である。
次に本発明について図面を用いて説明する。
図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号を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (9)

  1. 予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた1対1通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換して送信する送信端末と、
    前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信し、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する1台以上の受信端末と、
    を有する情報配信システム。
  2. 前記第2のMACアドレスは、ブロードキャストアドレスである請求項1記載の情報配信システム。
  3. 前記第2のMACアドレスは、マルチキャストアドレスである請求項1記載の情報配信システム。
  4. 記送信端末は、前記代表端末へ送信する情報を1対多通信で用いる暗号鍵で暗号化し、
    前記受信端末は、前記1対多通信で用いる暗号鍵を予め備える請求項1から3のいずれか1項記載の情報配信システム。
  5. 前記1対1通信の通信プロトコルにTCPまたはTCP/IPを使用する請求項1からのいずれか1項記載の情報配信システム。
  6. 前記送信端末及び前記受信端末は、
    無線通信により前記情報を送受信する請求項1からのいずれか1項記載の情報配信システム。
  7. 送信端末が、
    予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、
    前記代表端末に対して信頼性のある通信プロトコルを用いた1対1通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換して送信し、
    前記送信端末から前記情報を受信する複数の受信端末が、
    前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信し、
    前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する情報配信方法。
  8. 情報を送信する送信端末または前記情報を受信する受信端末として動作する通信端末であって、
    前記送信端末として動作するとき、予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた1対1通信で前記情報を送信し、前記受信端末として動作するとき、前記情報を送信する送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信するコンテンツ配信制御部と、
    前記送信端末として動作するとき、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換するMACアドレス変換部と、
    前記受信端末として動作するとき、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受するデータパケット傍受部と、
    を有する通信端末。
  9. 通信端末を、情報を送信する送信端末として動作させる、または前記情報を受信する受信端末として動作させるためのプログラムであって、
    前記通信端末を前記送信端末として動作させるとき、
    予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択させ、
    前記代表端末に対して1対1通信で前記情報を送信させると共に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第1のMACアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第2のMACアドレスに変換させて送信させ、
    前記通信端末を前記受信端末として動作させるとき、
    前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記1対1通信で前記情報を受信させ、
    前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求させるためのプログラム。
JP2014550066A 2012-11-30 2013-09-24 情報配信システム、情報配信方法、通信端末及びプログラム Active JP6323336B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2012262933 2012-11-30
JP2012262933 2012-11-30
PCT/JP2013/075634 WO2014083922A1 (ja) 2012-11-30 2013-09-24 情報配信システム、情報配信方法、通信端末及びプログラム

Publications (2)

Publication Number Publication Date
JPWO2014083922A1 JPWO2014083922A1 (ja) 2017-01-05
JP6323336B2 true JP6323336B2 (ja) 2018-05-16

Family

ID=50827571

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014550066A Active JP6323336B2 (ja) 2012-11-30 2013-09-24 情報配信システム、情報配信方法、通信端末及びプログラム

Country Status (2)

Country Link
JP (1) JP6323336B2 (ja)
WO (1) WO2014083922A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105933224B (zh) * 2016-04-15 2020-04-17 国网河北省电力公司 一种提高通信网络可靠性的机会路由方法
CN113852446B (zh) 2021-09-24 2023-05-30 上海物骐微电子有限公司 无线通信系统及方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004266342A (ja) * 2003-02-03 2004-09-24 Sony Corp 無線アドホック通信システム、端末、その端末における復号方法、暗号化方法及びブロードキャスト暗号鍵配布方法並びにそれらの方法を端末に実行させるためのプログラム
TWI266495B (en) * 2005-06-15 2006-11-11 Newsoft Technology Corp Method and system of transmitting information from one to many terminals in a wireless local area network
JP4555783B2 (ja) * 2006-01-25 2010-10-06 エスアイアイ・データサービス株式会社 一斉データ配信システムおよび一斉データ配信方法
JP5360905B2 (ja) * 2009-12-25 2013-12-04 日本電気通信システム株式会社 無線通信装置、無線ネットワークシステム、データ転送方法及びプログラム

Also Published As

Publication number Publication date
JPWO2014083922A1 (ja) 2017-01-05
WO2014083922A1 (ja) 2014-06-05

Similar Documents

Publication Publication Date Title
JP5392034B2 (ja) 通信装置および通信方法
US20180288179A1 (en) Proxy for serving internet-of-things (iot) devices
US8588417B2 (en) Systems and methods for multicast retransmission over a secure wireless LAN
JP5097620B2 (ja) マルチパス通信システム
WO2014019451A1 (zh) 一种快速通知cgn异常的方法、设备及系统
US20110242971A1 (en) Communication terminal, communication method, and program
US20200228932A1 (en) Mesh communications network having mesh ports
JP5857135B2 (ja) 複数の受信機にメッセージを伝送する装置および方法
Sun et al. The Internet underwater: An IP-compatible protocol stack for commercial undersea modems
US8379514B2 (en) Route reflector for a communication system
CN104184646A (zh) Vpn网络数据交互方法和系统及其网络数据交互设备
CN102546308A (zh) 基于重复地址检测实现邻居发现代理的方法和系统
JP2006074132A (ja) マルチキャスト通信方法及びゲートウェイ装置
Seggelmann et al. SSH over SCTP—Optimizing a multi-channel protocol by adapting it to SCTP
JP6323336B2 (ja) 情報配信システム、情報配信方法、通信端末及びプログラム
US10630479B2 (en) Network communication method having function of recovering terminal session
JP2006222659A (ja) 無線通信装置、無線通信システム及び方法
JP5676067B1 (ja) 通信方法および通信システム
JP2011199732A (ja) 無線lanシステム、移動端末及び移動端末のipアドレス切替方法
JP5326815B2 (ja) パケット送受信装置およびパケット送受信方法
JP2011160286A (ja) 呼制御サーバ、中継サーバ、vpn装置、vpn通信システム、vpnネットワーキング方法、プログラム、及び記憶媒体
Kannhavong et al. An efficient one-to-many content distribution method for Wi-Fi networks
JP6961951B2 (ja) ネットワーク構築システム、方法及び無線ノード
WO2020137084A1 (ja) 端末、通信方法、および、プログラム
JP6213028B2 (ja) 通信システム、通信方法、通信プログラムおよび通信装置

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170829

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171010

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: 20180313

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180326

R150 Certificate of patent or registration of utility model

Ref document number: 6323336

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150