JP2018026657A - データ配信システム、データ転送装置、および、データ送信端末 - Google Patents

Abstract

【課題】複雑な条件でデータパケットの送信対象を指定する場合でも、システムの負荷を軽減しつつデータパケットを所定の送信対象に転送すること。【解決手段】転送装置Ｘ１は、転送装置Ｂ１から送信された属性集合と、その送信元である転送装置Ｂ１のアドレス情報とを対応付けて自身の属性ＤＢに格納するとともに、自身の属性ＤＢ内の属性集合を転送装置Ａ１に送信するデータベース作成部と、属性集合の属性についての送信条件が指定されたデータパケットを転送装置Ａ１から受信すると、そのデータパケットの送信条件を満たす属性集合を自身の属性ＤＢから特定し、その特定した属性集合に対応するアドレス情報が示す転送装置Ｂ１に対してデータパケットを転送するデータ転送部と、を備える。【選択図】図８

Description

本発明は、データ配信システム、データ転送装置、および、データ送信端末の技術に関する。

送信端末から複数の受信端末にデータパケットを配信するデータ配信システムでは、あて先となる受信端末の指定方法は様々である。受信端末の指定方法として、例えば、アドレスを１台ずつ指定するユニキャスト、すべての受信端末を一括で指定するブロードキャスト、特定のグループ単位で指定するマルチキャストが挙げられる。

図１１は、配信システムにおけるユニキャストおよびマルチキャストでの送信経路の一例を示す。
符号１０１に示すように、ユニキャストでは送信端末（Ｓ）→受信端末（Ｔ）間で１：１で通信する。よって、１台の送信端末から４台の受信端末へ同じデータパケットを送信する場合でも、例えば、Ｓ→Ｒ１に４回重複して同じデータパケットを送信するなど、転送網での無駄が多い。さらに、送信端末がすべての宛先を知る必要があるため、送信端末も転送網も負荷が高い。特に、動画等の大きな情報を送信する場合には、無駄に帯域を占有してしまう。

符号１０２に示すように、転送網での無駄を削除するためには、マルチキャストの技術が使用される（非特許文献１）。符号１０２内の太線矢印が、データパケットの経路である。ここで、ある転送元（Ｒ１）から次ホップの転送先（Ｒ２，Ｒ３，Ｒ４）が複数存在するときには、転送元（Ｒ１）は、その転送先ごとに同じデータパケットをコピーして転送する。これにより、Ｓ→Ｒ１に４回重複して同じデータパケットを送信する必要がなくなる。

なお、マルチキャストにおいて各転送装置（Ｒ１〜Ｒ４）次ホップの転送先を特定するためには、受信端末のグループを表す特別なＩＰアドレス（マルチキャストアドレス）を割り当て、受信端末が該マルチキャストグループにｊｏｉｎ（登録）する前準備が必要となる。その後、送信端末はそのマルチキャストアドレスに対してデータパケットを送信すると、中継網のルータ（Ｒ１〜Ｒ４）やスイッチなどで宛先の数だけデータパケットが複製されて受信端末へ転送される。なお、ＩＧＭＰ（Internet Group Management Protocol） Snoopingが無効の場合は、全ポートへ複製・転送され、受信側で取捨選択する。
つまり、データパケットの送信回数が、ユニキャストでは受信端末の台数に依存していたのに対し、マルチキャストではマルチキャストアドレス数分だけ繰り返し送信すればよいことになる。

図１２は、マルチキャストのグループ数の組み合わせが膨大となることを示す図である。
データパケットの送信対象をきめ細かく指定したいときには、そのデータパケットの送信条件が「ＣＰＵが２．４ＧＨｚ以上でメモリが８ＧＢ以上でカメラを持つデバイス」や「２０代男性で今日自販機でコーヒーを購入した人の端末」などの多岐にわたることもある。
テーブル１１２は、その多岐の送信条件それぞれについて、別々のマルチキャストアドレスを割り当てた例を示す。符号１１１は、テーブル１１２に沿った受信端末の集合図であり、１つ以上の受信端末（「Ａ」など）をマルチキャストアドレスでグループ化したものである。
なお、テーブル１１２の状態で、新たに「ＣＰＵが２．４ＧＨｚ以上でメモリが８ＧＢ以上でカメラを持たないデバイス」の送信条件を追加するときには、「224.0.0.22」とは別のマルチキャストアドレスを新たに割り当てる必要がある。つまり、多岐にわたる送信条件を表現するために、膨大な数のグループが必要となる。

また、非特許文献２には、ＩＰアドレスではなくコンテンツの中身を表すキーをもとに該コンテンツを受信し、該コンテンツがネットワーク経路上にキャッシュされることで、送信端末の繰り返し送信や転送帯域の節約を実現するＣＣＮ（Content-Centric Network）が記載されている。
このＣＣＮは、受信端末側からデータパケットを要求するＰｕｌｌ型の配信システムであり、送信端末側から複雑な複数の条件により受信端末群を選択し情報を送信するＰｕｓｈ型の配信システムには適用されない。

The Internet Society、"Internet Group Management Protocol, Version 3"、［online］、2002年10月、［平成28年7月28日検索］、インターネット〈URL：https://tools.ietf.org/html/rfc3376〉 V. Jacobson, et. al, "Networking Named Content," ACM CoNEXT 2009,December 1-4, 2009, Rome, Italy.

前記の図１２で説明したように、データパケットの送信対象をきめ細かく指定したいときには、マルチキャストのグループ化では送信端末や転送装置の持つマルチキャストアドレスのテーブルが膨大になるため、送信端末や転送装置への負担が大きくなりすぎてしまう上、マルチキャストアドレスの枯渇が懸念される。かといって、ユニキャストやブロードキャストを採用してしまうと、個々のデータパケットの送信対象の指定は容易だが、その分データパケットの通信量が膨大となり、転送網の帯域を圧迫してしまう。

そこで、本発明は、複雑な条件でデータパケットの送信対象を指定する場合でも、システムの負荷を軽減しつつデータパケットを所定の送信対象に転送することを、主な課題とする。

前記課題を解決するために、本発明のデータ配信システムは、以下の特徴を有する。
つまり、本発明は、最上位の送信端末から最下位の受信端末に向かってデータパケットを転送するときに、前記送信端末に接続される第１転送装置、前記第１転送装置よりも下位の第２転送装置、前記第２転送装置よりも下位であり前記受信端末に接続される第３転送装置の順にデータパケットが通過するようにレイヤ構成をとるデータ配信システムであって、
データパケットが前記送信端末から送信される前において、
前記受信端末が、自身の属性集合を前記第３転送装置に送信する第１工程と、
前記第３転送装置が、送信された前記属性集合と、その送信元である前記受信端末のアドレス情報とを対応付けて自身の属性ＤＢに格納するとともに、その格納した属性集合を前記第２転送装置に送信する第２工程と、
前記第２転送装置が、送信された前記属性集合と、その送信元である前記第３転送装置のアドレス情報とを対応付けて自身の属性ＤＢに格納するとともに、その格納した属性集合を前記第１転送装置に送信する第３工程と、
前記第１転送装置が、送信された前記属性集合と、その送信元である前記第２転送装置のアドレス情報とを対応付けて自身の属性ＤＢに格納する第４工程と、
前記属性集合の属性についての送信条件が指定されたデータパケットが前記送信端末から送信された後において、
前記第１転送装置が、前記送信端末から送信された前記データパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記第２転送装置に対してデータパケットを転送する第５工程と、
前記第２転送装置が、前記第１転送装置から転送された前記データパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記第３転送装置に対してデータパケットを転送する第６工程と、
前記第３転送装置が、前記第２転送装置から転送された前記データパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記受信端末に対してデータパケットを転送する第７工程とを実行することを特徴とする。

これにより、送信先の数だけ同じ情報を繰り返し送信元が送信する必要がなくなるため、ユニキャストとは異なり、送信元の処理負荷の軽減と転送網の帯域の節約が可能になる。
さらに、マルチキャストと異なり、同報送信先のグループそれぞれに限りあるマルチキャストアドレスを割り当てる必要がなくなるため、膨大なサイズのマルチキャストアドレスのテーブルを各転送装置が保持しなくても済む。その代わり、複雑な条件を表現するときに使用される属性集合を各転送装置が保持すればよい。つまり、条件の複雑化によりグループ数が膨大なものになっても、アドレスが枯渇せずに同報送信が可能になる。
よって、複雑な条件でデータパケットの送信対象を指定する場合でも、システムの負荷を軽減しつつデータパケットを所定の送信対象に転送することができる。

本発明は、前記第１工程、前記第２工程、および、前記第３工程のうちの少なくとも１つの工程において、前記属性集合の送信元である下位の装置が、前記属性集合の送信先である上位の装置に対して、送信対象の前記属性集合のうちの一部を省略してから送信し、
前記第５工程、前記第６工程、および、前記第７工程のうちの少なくとも１つの工程において、各転送装置が、送信が省略されたことにより前記自身の属性ＤＢに格納されなかった前記属性集合については、送信条件を満たすものとみなして、下位の装置にデータパケットを転送することを特徴とする。

これにより、同報送信先を特定するための条件のすべてを転送装置へ共有する必要がなくなるため、プライバシー性やセキュリティ性の高い属性情報を受信端末外や自身の制御下にある転送装置外に漏らす必要がなくなる。

本発明は、前記第１工程、前記第２工程、および、前記第３工程のうちの少なくとも１つの工程において、前記属性集合の送信元である下位の装置が、前記属性集合内の重複する項目については１つに集約した後に、前記属性集合の送信先である上位の装置に対して送信することを特徴とする。

これにより、受信端末が膨大な数になったとしても、属性ＤＢのサイズが縮小され、転送装置の保存容量削減と転送先検索時間の低減が可能になる。

本発明は、前記第５工程、前記第６工程、および、前記第７工程のうちの少なくとも１つの工程において、
各転送装置が、前記自身の属性ＤＢから前記データパケットの送信条件を満たす転送先のアドレス情報を特定した後に、その送信条件を示すハッシュ値と、特定したアドレス情報とを対応付けるハッシュテーブルに対して今回特定したエントリを追加し、
各転送装置が、新たなデータパケットを受信した後に、その新たなデータパケットの送信条件を示すハッシュ値が既にハッシュテーブルに登録されているときには、前記ハッシュテーブルから登録されたアドレス情報を取得することで、送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定する処理を省略することを特徴とする。

これにより、同報送信先を特定するための条件を例えばハッシュ化する等の手段により機械的に扱いやすい形にすることで、転送装置の転送先検索時間の低減が可能になる。

本発明のデータ転送装置は、自身からみて階層構造における下位として接続されている下位転送装置から送信された属性集合と、その送信元である前記下位転送装置のアドレス情報とを対応付けて自身の属性ＤＢに格納するとともに、その格納した属性集合を自身からみて階層構造における上位として接続されている上位転送装置に送信するデータベース作成部と、
前記属性集合の属性についての送信条件が指定されたデータパケットを前記上位転送装置から受信すると、そのデータパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記下位転送装置に対してデータパケットを転送するデータ転送部と、を備えることを特徴とする。

これにより、複雑な条件でデータパケットの送信対象を指定する場合でも、システムの負荷を軽減しつつデータパケットを所定の送信対象に転送することができる。

本発明のデータ送信端末は、前記のデータ転送装置に対して送信するデータパケットを作成し、そのデータパケットのあて先を示す情報として前記属性集合の属性についての送信条件を指定することを特徴とする。

これにより、複雑な条件でデータパケットの送信対象を指定する場合でも、システムの負荷を軽減しつつデータパケットを所定の送信対象に転送することができる。

本発明によれば、複雑な条件でデータパケットの送信対象を指定する場合でも、システムの負荷を軽減しつつデータパケットを所定の送信対象に転送することができる。

本実施形態に係わる配信システムの構成図である。 本実施形態に係わる配信システムにおける属性ＤＢの内容を第１の具体例で示す図である。 本実施形態に係わる図２で示した配信システムにおける属性ＤＢの内容を一般的に示す図である。 本実施形態に係わる配信システムにおける第２の具体例のデータベース作成処理を示す図である。 本実施形態に係わる配信システムにおける第２の具体例のデータ転送処理を示す図である。 本実施形態に係わる配信システムにおける第３の具体例のデータベース作成処理を示す図である。 本実施形態に係わる配信システムにおける第３の具体例のデータ転送処理を示す図である。 本実施形態に係わる図１の配信システムに対して、転送装置を１段階追加したときの構成図である。 本実施形態に係わる配信システムにおけるハッシュＤＢおよびハッシュ値を含むパケットの説明図である。 配信システムにおける配信用テーブルの大きさの比較図である。 配信システムにおけるユニキャストおよびマルチキャストでの送信経路の一例を示す図である。 マルチキャストのグループ数の組み合わせが膨大となることを示す図である。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、配信システムの構成図である。
符号５０１に示す配信システム全体は、データパケットが流れる上流側（上位側）から下流側（下位側）に向かって、送信元である第０階層の送信端末１、第１階層の転送装置Ａ１、第２階層の転送装置Ｂ１、Ｂ２、あて先である第３階層の受信端末Ｃ１〜Ｃ４の順に接続されている。図１では、データパケットが流れる順序を矢印で表記する。
なお、配信システムの各装置は、それぞれＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。

ここで、図１１の符号１０２で示したマルチキャストのように、各転送装置は、自身が収容する受信端末Ｃ１〜Ｃ４のうち、今回のデータパケットの受信対象が存在するときにはその受信対象に向かってデータパケットを転送するとともに、受信対象に向かう経路が分岐するときには、データパケットを分岐先ごとにコピーする。これにより、同じ内容のデータパケットが同じリンクを何度も通過することによる通信の無駄を抑制できる。

さらに、本実施形態の配信システムでは、データパケットのあて先を特定するための情報として、マルチキャストのグループの代わりに、受信端末Ｃ１〜Ｃ４の属性（またはその利用者の属性）の組み合わせ（集合）を用いる。よって、データパケットを転送する前準備として、各転送装置内の転送テーブル（以下「属性ＤＢ」とする）に書き込むために、下流側から上流側に向かって、つまり図１の矢印の逆方向に向かって属性集合が通知される。

符号５０２は、符号５０１に示す配信システムのうちの１つの転送装置に着目したときの装置構成図である。転送装置は、下流側（下位転送装置）から上流側（上位転送装置）へ通知される属性集合（細線矢印）を属性ＤＢに登録するデータベース作成部と、上流側から下流側への属性ＤＢを参照したデータパケット（太線矢印）の転送処理を行うデータ転送部とを有する。

このように、属性集合を指定したデータパケットの配信システムは、特定の年齢や特定のスペック端末に向けたターゲット向けの広告配信などに特に適している。また、不特定多数の端末を組み合わせて、一つのサービスを実現する場合の端末発見にも、本実施形態の配信システムは適している。例えば、○○公園内の監視カメラだけでなく公園内でスマホで写真を撮ろうとカメラをオンにしているひとの端末を組み合わせて、特定の人を発見するサービスなどに適用される。

図２は、配信システムにおける属性ＤＢの内容を第１の具体例で示す図である。
まず、テーブル２１１は、下流側の転送装置（または受信端末）から上流側の転送装置に属性集合が通知されていく様子を示す。
テーブル２１１の第１列「装置」は、どの装置内に格納された属性ＤＢの内容なのかを示す。なお、装置が受信端末であるときには、属性ＤＢの代わりに手入力された設定ファイルなどでもよい。
テーブル２１１の第２列「ＣＰＵ」は、第１属性（ＣＰＵの動作クロック）の属性値（以下「ＣＰＵ属性」）を示す。
テーブル２１１の第３列「ＣＰＵ−ｆｒｏｍ」は、第２列のＣＰＵ属性がどの下位の装置から通知されたかを示すための送信元の情報（アドレス情報）を示す。
テーブル２１１の第４列「ＲＡＭ」は、第２属性（ＲＡＭの容量）の属性値（以下「ＲＡＭ属性」）を示す。
テーブル２１１の第５列「ＲＡＭ−ｆｒｏｍ」は、第４列のＲＡＭ属性がどの下位の装置から通知されたかを示すための送信元の情報（アドレス情報）を示す。

例えば、テーブル２１１の「装置＝受信端末Ｃ１」の行を参照することにより、受信端末Ｃ１のＣＰＵ属性は「２．４ＧＨｚ」であることがわかる。また、「装置＝転送装置Ｂ１」の行を参照することにより、転送装置Ｂ１内の属性ＤＢには、別々の下位装置から通知された３つのＣＰＵ属性と、別々の下位装置から通知された３つのＲＡＭ属性とから構成される属性集合が格納されていることを示す。
なお、以下の説明では、テーブルの第ｎ行とは、第１列の「装置」で区切られたレコードを示す。ここで、１つの装置が複数の属性値を有していても、１行とカウントする。つまり、テーブル２１１の第５行＝「装置＝転送装置Ｂ１」の行、テーブル２１１の第６行＝「装置＝転送装置Ｂ２」の行、テーブル２１１の第７行＝「装置＝転送装置Ｂ２」の行である。

テーブル２１１の第１行〜第４行には、最下流の受信端末Ｃ１〜Ｃ４それぞれの属性（ＣＰＵ，ＲＡＭ）が示されている。
テーブル２１１の第５行に示す転送装置Ｂ１の属性ＤＢは、配下である３台の受信端末Ｃ１〜Ｃ３から通知された属性（第１行〜第３行の属性）が、その通知元（〜ｆｒｏｍ）に対応付けられて格納される。
テーブル２１１の第６行に示す転送装置Ｂ２の属性ＤＢは、配下である１台の受信端末Ｃ４から通知された属性（第４行の属性）が、その通知元（〜ｆｒｏｍ）に対応付けられて格納される。

テーブル２１１の第７行に示す転送装置Ａ１の属性ＤＢは、配下である転送装置Ｂ１、Ｂ２から通知された属性（第５，６行の属性）が、その通知元（〜ｆｒｏｍ）に対応付けられて格納される。ここで、ＣＰＵの属性については、第５行では３エントリ（2.4GHz,2.8GHz,2.4GHz）存在していた。しかし、転送装置Ｂ１は、上位の転送装置Ａ１にＣＰＵの属性を通知するときに、重複する属性値を１つに集約することで、２エントリ（2.4GHz,2.8GHz）分の通知で済む。同様に、転送装置Ｂ１は、上位の転送装置Ａ１にＲＡＭの属性を通知するときに、３エントリ（8GB,8GB,8GB）を１エントリ（8GB）に集約している。以上でデータパケットの送信準備である属性ＤＢの作成処理を説明した。

テーブル２１２は、上流側の転送装置から下流側の転送装置（または受信端末Ｃ３）にデータパケットが転送されていく様子を示す。以下、転送装置Ａ１は接続先の送信端末１から、属性集合を元にした以下の送信条件が指定されたデータパケットを受信する場合を考える。
「ＣＰＵ＝２．４ＧＨｚかつＲＡＭ≧４ＧＢである受信端末を送信先とする」
この送信条件は、第１属性「ＣＰＵ＝２．４ＧＨｚ」と第２属性「ＲＡＭ≧４ＧＢ」との組み合わせ（ＡＮＤ条件）であるとも言える。

テーブル２１２の第１行に示す転送装置Ａ１の属性ＤＢは、テーブル２１１の第７行と同じである。転送装置Ａ１は、送信条件を構成する２つの属性ごとに、それぞれの属性値を満たすエントリを属性ＤＢから取得する。その結果、転送装置Ａ１は、第１属性「ＣＰＵ＝２．４ＧＨｚ」を満たす１つのエントリと、第２属性「ＲＡＭ≧４ＧＢ」を満たす２つのエントリとを取得する。なお、送信条件を部分的に満たすエントリには、その末尾に「○」印を図示する。今回の送信条件は、２つの属性のＡＮＤ条件なので、ＣＰＵ属性とＲＡＭ属性とを同時に満たす次ホップ（〜ｆｒｏｍ）は転送装置Ｂ１だけである。よって、転送装置Ａ１は、データパケットを転送装置Ｂ１に転送する。

テーブル２１２の第２行に示す転送装置Ｂ１の属性ＤＢは、テーブル２１１の第５行と同じである。転送装置Ｂ１は、転送装置Ａ１と同様に、２つの属性ごとに、それぞれの属性値を満たすエントリを属性ＤＢから取得する。そして、転送装置Ｂ１は、ＣＰＵ属性とＲＡＭ属性とを同時に満たす受信端末Ｃ１、Ｃ３を特定する。よって、転送装置Ｂ１は、同じ１つのデータパケットを受信端末Ｃ１、Ｃ３とに分岐（コピー）して転送する。

テーブル２１２の第３行に示す受信端末Ｃ１のレコードは、テーブル２１１の第１行と同じである。受信端末Ｃ１は、転送装置Ｂ１から転送されたデータパケットの送信条件が自身の属性集合に適合することを確認した後、そのデータパケットを受信する。
テーブル２１２の第４行に示す受信端末Ｃ３のレコードは、テーブル２１１の第３行と同じである。受信端末Ｃ３は、転送装置Ｂ１から転送されたデータパケットの送信条件が自身の属性集合に適合することを確認した後、そのデータパケットを受信する。

図３は、図２で示した配信システムにおける属性ＤＢの内容を一般的に示す図である。
テーブル２０１は、図２のテーブル２１１を一般化したものである。図２のＣＰＵ属性を図３では属性ａとし、図２のＲＡＭ属性を図３では属性ｂとし、その各属性値を図２の「２．４ＧＨｚ」→図３「Ｃ１ａ」などに置き換える。
そして、各転送装置は、直下の転送装置から通知された属性集合の和集合を、真上の転送装置に通知する。このとき、同じ属性内の属性値が２つ以上重複する場合は、１つの属性値に集約してから通知してもよい。

テーブル２０２は、図２のテーブル２１２を一般化したものである。データパケットの送信条件を、「属性ａ＝Ｃ１ａ」と「属性ｂ＝Ｃ１ｂ」との組み合わせ（ＡＮＤ条件）とする。
転送装置Ａ１では、２つの属性値が送信条件をともに満たす送信先として、転送装置Ｂ１が選択される。
転送装置Ｂ１では、２つの属性値が送信条件をともに満たす送信先として、受信端末Ｃ１が選択される。
これにより、受信端末Ｃ１は、自身の属性に適合するデータパケットを受信することができる。なお、受信端末Ｃ１〜Ｃ４の増減、端末位置の移動、属性値の変更などに伴い、テーブル２０１に示した各装置内の属性ＤＢの内容が変更されることもある。そこで、配信システムの各装置は、最新の属性集合を随時各装置の属性ＤＢに反映させることが望ましい。

図４は、配信システムにおける第２の具体例のデータベース作成処理を示す図である。図２の第１の具体例と比較すると、図４では、第３属性「cam」が追加されている。この属性「cam」とは、受信端末Ｃ１〜Ｃ４それぞれからカメラが内蔵または接続されることで、撮影が可能か（属性値＝有）否か（属性値＝無）を示す。

テーブル２２１では、テーブル２１１と同様に、受信端末Ｃ１〜Ｃ４→転送装置Ｂ１，Ｂ２までは、３つの属性すべてが通知されている。しかし、転送装置Ｂ１，Ｂ２→転送装置Ａ１の段階では、２つの属性（ＣＰＵ，ＲＡＭ）だけが通知されるが、属性「cam」が通知されないものとする。このように、自身が保持しているにもかかわらず、上位の装置にあえて属性を通知しない理由としては、例えば、プライバシー保護や、データ量の削減（負荷軽減）などが挙げられる。

図５は、配信システムにおける第２の具体例のデータ転送処理を示す図である。テーブル２２２では、テーブル２１２と同様に、上流側から下流側へとデータパケットが通知される。このデータパケットの送信条件を、第１属性「ＣＰＵ＝２．４ＧＨｚ」と第２属性「ＲＡＭ≧４ＧＢ」と第３属性「ｃａｍ＝有」との組み合わせ（ＡＮＤ条件）とする。
テーブル２２２の第１行に示す転送装置Ａ１の属性ＤＢは、テーブル２１１の第７行と同じである。転送装置Ａ１は、送信条件を構成する３つの属性ごとに、それぞれの属性値を満たすエントリを属性ＤＢから取得する。図２と同様に、ＣＰＵ属性とＲＡＭ属性については属性値の評価ができるが、前記したとおり直下の装置から通知されていないので、ｃａｍ属性については属性値の評価ができない。

そこで、転送装置Ａ１は、ｃａｍ属性については自身で評価する代わりに、直下の装置に判断をゆだねる。具体的には、転送装置Ａ１は、ｃａｍ属性については転送装置Ｂ１、Ｂ２がともに満たす（属性値＝有）とみなした結果、３つの属性をすべて満足する転送装置Ｂ１をデータパケットの転送先とする。
転送装置Ｂ１は、転送されたデータパケットについて、テーブル２２２の第２行に示すように、３つの属性をすべて保持している。そこで、転送装置Ｂ１は、３つの属性すべてを評価できるので、その評価結果である受信端末Ｃ１をデータパケットの転送先とする。これにより、受信端末Ｃ１は、一部の属性が転送装置Ａ１に通知されていない状況下であっても、自身の属性に適合するデータパケットを受信することができる。

図６は、配信システムにおける第３の具体例のデータベース作成処理を示す図である。図４の第２の具体例と比較すると、図６では、第３属性が「age」となっている。この属性「age」とは、受信端末Ｃ１〜Ｃ４の所有者の年齢を示す。
テーブル２３１では、受信端末Ｃ１〜Ｃ４→転送装置Ｂ１，Ｂ２の段階で、２つの属性（ＣＰＵ，ＲＡＭ）だけが通知されるが、属性「age」が通知されないものとする。つまり、各受信端末Ｃ１〜Ｃ４は、所有者の年齢を秘匿情報として外部に通知しない設定になっている。よって、転送装置Ｂ１，Ｂ２→転送装置Ａ１の段階でも属性「age」が通知されない。

図７は、配信システムにおける第３の具体例のデータ転送処理を示す図である。テーブル２３２では、テーブル２２２と同様に、上流側から下流側へとデータパケットが通知される。このデータパケットの送信条件を、第１属性「ＣＰＵ＝２．４ＧＨｚ」と第２属性「ＲＡＭ≧４ＧＢ」と第３属性「ａｇｅ＝３０代」との組み合わせ（ＡＮＤ条件）とする。
テーブル２３２の第１行に示す転送装置Ａ１の属性ＤＢでは、ＣＰＵ属性とＲＡＭ属性については属性値の評価ができるが、ａｇｅ属性については属性値の評価ができない。そこで、図５と同様に、通知されないａｇｅ属性については、その判断を下位の装置にゆだねることとし（換言すると自身の装置では、ａｇｅ属性は満たしたと仮定し）、転送装置Ａ１は転送装置Ｂ１へデータパケットを転送する。
テーブル２３２の第２行に示す転送装置Ｂ１の属性ＤＢも、ＣＰＵ属性とＲＡＭ属性とをともに満たし、かつ、通知されていないａｇｅ属性は満たしたものと仮定した結果、転送先が受信端末Ｃ１、Ｃ３に特定される。

テーブル２３２の第３行に示す受信端末Ｃ１は、転送されたデータパケットの送信条件と、自身の属性とを照合した結果、ａｇｅ属性も満たしている（３８才は３０代に含まれる）ことにより、データパケットを受信する。
テーブル２３２の第４行に示す受信端末Ｃ３は、転送されたデータパケットの送信条件と、自身の属性とを照合した結果、ａｇｅ属性を満たしていない（１３才は３０代に含まれない）ことにより、データパケットを破棄する。
このように、受信端末側にデータパケットの取捨選択を求めることで、受信端末の秘匿情報を外部に通知しなくても、属性を満たす適切なデータパケットだけを受信することができる。

図８は、図１の配信システムに対して、転送装置を１段階追加したときの構成図である。配信システムは、データパケットが流れる上流側（上位側）から下流側（下位側）に向かって、以下のように階層化されている。
・第０階層の送信端末１
・第１階層の転送装置Ａ１
・第２階層の転送装置Ｘ１、Ｘ２
・第３階層の転送装置Ｂ１、Ｂ２
・第４階層の受信端末Ｃ１〜Ｃ４

第ｋ階層の装置のデータベース作成部（図１参照）は、第ｋ＋１階層の装置の（装置内の属性ＤＢの、または、装置自身の）属性集合が通知されると、その属性集合あてに送信するときの次ホップとして通知元の第ｋ＋１階層の装置を対応付けて、自身の（第ｋ階層の）属性ＤＢに登録する。なお、第ｋ階層の属性ＤＢを第ｋ−１階層に通知するときに、同じ属性に属する属性値が複数重複する場合は、それらの属性値を１つに集約してから通知してもよいし、集約しなくてもよい。
［第１工程］第４階層の受信端末Ｃ１〜Ｃ４は、第３階層の転送装置Ｂ１、Ｂ２に対して、自身の属性集合を送信する。
［第２工程］第３階層の転送装置Ｂ１、Ｂ２は、第１工程で通知された属性集合を自装置内の属性ＤＢ内に格納し、その格納した内容を第２階層の転送装置Ｘ１に対して送信する。
［第３工程］第２階層の転送装置Ｘ１は、第２工程で通知された属性集合を自装置内の属性ＤＢ内に格納し、その格納した内容を第１階層の転送装置Ａ１に対して送信する。
［第４工程］第１階層の転送装置Ａ１は、第３工程で通知された属性集合を自装置内の属性ＤＢ内に格納する。

第ｋ階層の装置のデータ転送部（図１参照）は、第ｋ−１階層の装置から通知されたデータパケット内の送信条件をもとに、自身の（第ｋ階層の）属性ＤＢ内の属性集合を評価する。この評価により、送信条件を満たす属性と、その属性に対応する次ホップ（第ｋ＋１階層の装置）を特定する。そして、第ｋ階層の装置は、特定した１つ以上の次ホップに対して、データパケットを転送する。
［第５工程］第１階層の転送装置Ａ１は、送信端末１から送信されたデータパケットの送信条件を満たす属性集合を自身の属性ＤＢから特定し、その特定した属性集合に対応する次ホップが示す第２階層の転送装置Ｘ１に対してデータパケットを転送する。
［第６工程］第２階層の転送装置Ｘ１は、第５工程で送信されたデータパケットの送信条件を満たす属性集合を自身の属性ＤＢから特定し、その特定した属性集合に対応する次ホップが示す第３階層の転送装置Ｂ１、Ｂ２に対してデータパケットを転送する。
［第７工程］第３階層の転送装置Ｂ１、Ｂ２は、第６工程で送信されたデータパケットの送信条件を満たす属性集合を自身の属性ＤＢから特定し、その特定した属性集合に対応する次ホップが示す第４階層の受信端末Ｃ１〜Ｃ４に対してデータパケットを転送する。

図９は、配信システムにおけるハッシュＤＢ（ハッシュテーブル）およびハッシュ値を含むパケットの説明図である。
テーブル３０１は、各装置が有するハッシュＤＢの内容として、データパケットの送信条件と、その送信条件をハッシュキーとしてハッシュ計算した結果のハッシュ値と、属性ＤＢに対して送信条件を評価した結果の送信先（次ホップ）とを対応付けている。
各転送装置は、受信したデータパケットの送信条件と、属性ＤＢの属性集合とを評価する前に、受信したデータパケットの送信条件がハッシュＤＢに登録済みであるか否かを、ハッシュ値から検索する。もし、ハッシュＤＢに登録済みであるなら、属性ＤＢの属性集合を評価する処理を省略し、ハッシュＤＢからただちに送信先（次ホップ）を取得することで、処理負荷が軽減される。

一方、ハッシュＤＢに未登録の送信条件であるなら、前記したように受信したデータパケットの送信条件と、属性ＤＢの属性集合とを評価することで、送信先（次ホップ）を取得する。この未登録の送信条件は、今回新たにハッシュＤＢに登録しておくことにより、次回の同じ送信条件に対する処理を高速化できる。なお、送信条件に前回の評価結果を対応付ける手段として、ハッシュ化以外にも例えば、固有のＩＤを割り当てる手法も挙げられる。
なお、ハッシュＤＢのエントリ登録処理の契機として、未登録の送信条件が到着したとき以外にも、属性ＤＢの更新時や、転送装置の電源投入時などが挙げられる。また、登録対象のエントリ（送信条件）としては、到着した送信条件だけでなく、未着であっても事前に考え得る全パターンを列挙してもよい。

符号３０２において、１つのデータパケットを、送信先を決める条件パケット（一般にC-Planeと呼ばれる）と情報パケット（一般にU-Planeと呼ばれる）に分けてもよい。この時に条件パケットと情報パケットとを対応づけるキーとしては、例えば条件のハッシュ値が考えられる。なお、送信先を特定するための情報（条件の本文、条件のハッシュ値）は、図示したように送信パケットのデータ部（Payload）に含めてもよいし、ヘッダを拡張してもよい。
これにより、複雑な条件パケットは比較的高性能な処理能力を持つ転送装置（例えば高性能ＣＰＵをもつ転送装置）で取扱い、データ量が大きい情報パケットをより大容量の転送能力を持つ転送装置（例えば高性能なＮＰ（Network Processor）／ＦＰＧＡ（Field-Programmable Gate Array）／ＡＳＩＣ（Application Specific Integrated Circuit）などの専用チップを持つ転送装置）で取り扱うなどにより、効率的な設備設計が可能になる。

図１０は、配信システムにおける配信用テーブルの大きさの比較図である。
符号４０１は、配信用テーブルの大きさを評価するためのパラメータｍ，ｎの説明図である。仮に属性の個数を属性Ａ〜属性Ｍの合計ｍ個とし、その属性１つ１つにつき、取り得る属性値のバリエーションがｎ個であったとする。
符号４０２は、符号４０１の状況において、マルチキャストグループで配信するときの配信用テーブルの大きさを示す。データパケットの送信条件を示す条件式は、属性ごとの属性値の組み合わせで定義されるので、ｎのｍ乗個のエントリ（マルチキャストＩＰアドレス）が必要となり、そのエントリを格納する配信用テーブルの肥大化が問題となっていた。

符号４０３は、符号４０１の状況において、本実施形態の属性集合で配信するときの配信用テーブル（属性ＤＢ）の大きさを示す。図２などで示したように、属性ＤＢには個々の属性ごとの属性値が登録されるため、属性ＤＢの大きさは、ｎ×ｍ個のエントリで済む。
例えば、ｍ＝５，ｎ＝１０とすると、マルチキャストの配信テーブルは１０の５乗＝１０万エントリが必要であったが、属性ＤＢは１０×５＝５０エントリで済む。

以上説明した本実施形態では、送信端末１が複雑な複数の条件で定まる受信端末Ｃ１〜Ｃ４へ向けてデータパケットを配信するシステムを提示した。この配信システムでは、受信端末Ｃ１〜Ｃ４の属性集合が、各転送装置内の属性ＤＢに登録された後、その属性ＤＢを参照してデータパケットの送信条件が評価され、送信条件に合致する次ホップにデータパケットが転送される。また、転送装置は２段以上の階層構造を取り、条件（属性）を集約していくことで、属性ＤＢのサイズを削減できる。さらに、図４の第２の具体例や、図６の第３の具体例で示したように、必要に応じて、自らが受信するパケットの条件を秘匿することが可能になる。

これにより、各受信端末Ｃ１〜Ｃ４がマルチキャストネットワークへ自ら登録する必要が無くなり、かつ、複雑な複数の条件で定まる膨大な数のマルチキャストネットワークのグループ管理も不要になる。つまり、従来のユニキャストで課題であった転送帯域の増大や送信元端末の繰り返し送信を軽減するとともに、従来のマルチキャストで課題であった複雑な条件の取扱いを可能にする。

なお、本実施形態は複数端末への同報送信に関する課題を鑑みてなされたものではあるが、適用先は同報送信に限らない。「ＩＰアドレスなどの従来の宛先端末指定スキームによらず、条件によって宛先端末を指定できる」点が特徴である。例えばＩＰアドレスといった宛先を一意に特定する従来のＩＤを用いるのではなく、宛先を送信条件によって定める。これにより、送信端末１は柔軟な表現で送信条件を作成できるので、使い勝手がよくなる。

なお、説明をわかりやすくするために、送信端末１から受信端末Ｃ１〜Ｃ４に向かう２段以上の階層構造として、図１などではツリー状のネットワークトポロジを例示したが、上位下位の階層構造を物理的に構成するネットワークだけでなく、物理的には階層構造となっていなくても、（ネットワークの設定で）論理的に階層構造を構成するネットワークを用いてもよい。例えばメッシュ状のネットワーク（Ｐ２Ｐ等）に適用してもよいし、双方向に情報をやり取りするために本発明により端末間で通信経路を確立するという適用の仕方でもよい。「論理的に階層構造を構成する」とは、例えば、それぞれのノードに対して、ＢＧＰ（Border Gateway Protocol）などで情報をやりとりすることで、どのノードが自身からみた上位ノードなのかをあらかじめ登録しておくことである。

１ 送信端末
Ａ１ 転送装置（第１転送装置）
Ｂ１，Ｂ２ 転送装置（第３転送装置）
Ｃ１〜Ｃ４ 受信端末
Ｘ１，Ｘ２ 転送装置（第２転送装置）

Claims (6)

1. 最上位の送信端末から最下位の受信端末に向かってデータパケットを転送するときに、前記送信端末に接続される第１転送装置、前記第１転送装置よりも下位の第２転送装置、前記第２転送装置よりも下位であり前記受信端末に接続される第３転送装置の順にデータパケットが通過するようにレイヤ構成をとるデータ配信システムであって、
   データパケットが前記送信端末から送信される前において、
   前記受信端末は、自身の属性集合を前記第３転送装置に送信する第１工程と、
   前記第３転送装置は、送信された前記属性集合と、その送信元である前記受信端末のアドレス情報とを対応付けて自身の属性ＤＢに格納するとともに、その格納した属性集合を前記第２転送装置に送信する第２工程と、
   前記第２転送装置は、送信された前記属性集合と、その送信元である前記第３転送装置のアドレス情報とを対応付けて自身の属性ＤＢに格納するとともに、その格納した属性集合を前記第１転送装置に送信する第３工程と、
   前記第１転送装置は、送信された前記属性集合と、その送信元である前記第２転送装置のアドレス情報とを対応付けて自身の属性ＤＢに格納する第４工程と、
   前記属性集合の属性についての送信条件が指定されたデータパケットが前記送信端末から送信された後において、
   前記第１転送装置は、前記送信端末から送信された前記データパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記第２転送装置に対してデータパケットを転送する第５工程と、
   前記第２転送装置は、前記第１転送装置から転送された前記データパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記第３転送装置に対してデータパケットを転送する第６工程と、
   前記第３転送装置は、前記第２転送装置から転送された前記データパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記受信端末に対してデータパケットを転送する第７工程とを実行することを特徴とする
   データ配信システム。
2. 前記第１工程、前記第２工程、および、前記第３工程のうちの少なくとも１つの工程において、前記属性集合の送信元である下位の装置は、前記属性集合の送信先である上位の装置に対して、送信対象の前記属性集合のうちの一部を省略してから送信し、
   前記第５工程、前記第６工程、および、前記第７工程のうちの少なくとも１つの工程において、各転送装置は、送信が省略されたことにより前記自身の属性ＤＢに格納されなかった前記属性集合については、送信条件を満たすものとみなして、下位の装置にデータパケットを転送することを特徴とする
   請求項１に記載のデータ配信システム。
3. 前記第１工程、前記第２工程、および、前記第３工程のうちの少なくとも１つの工程において、前記属性集合の送信元である下位の装置は、前記属性集合内の重複する項目については１つに集約した後に、前記属性集合の送信先である上位の装置に対して送信することを特徴とする
   請求項１に記載のデータ配信システム。
4. 前記第５工程、前記第６工程、および、前記第７工程のうちの少なくとも１つの工程において、
   各転送装置は、前記自身の属性ＤＢから前記データパケットの送信条件を満たす転送先のアドレス情報を特定した後に、その送信条件を示すハッシュ値と、特定したアドレス情報とを対応付けるハッシュテーブルに対して今回特定したエントリを追加し、
   各転送装置は、新たなデータパケットを受信した後に、その新たなデータパケットの送信条件を示すハッシュ値が既にハッシュテーブルに登録されているときには、前記ハッシュテーブルから登録されたアドレス情報を取得することで、送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定する処理を省略することを特徴とする
   請求項１に記載のデータ配信システム。
5. 自身からみて階層構造における下位として接続されている下位転送装置から送信された属性集合と、その送信元である前記下位転送装置のアドレス情報とを対応付けて自身の属性ＤＢに格納するとともに、その格納した属性集合を自身からみて階層構造における上位として接続されている上位転送装置に送信するデータベース作成部と、
   前記属性集合の属性についての送信条件が指定されたデータパケットを前記上位転送装置から受信すると、そのデータパケットの送信条件を満たす前記属性集合を前記自身の属性ＤＢから特定し、その特定した前記属性集合に対応するアドレス情報が示す前記下位転送装置に対してデータパケットを転送するデータ転送部と、を備えることを特徴とする
   データ転送装置。
6. 請求項５に記載のデータ転送装置に対して送信するデータパケットを作成し、そのデータパケットのあて先を示す情報として前記属性集合の属性についての送信条件を指定することを特徴とする
   データ送信端末。

Images