特許 6857103 ファイル配信システム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6857103

(24)【登録日】2021年3月23日

(45)【発行日】2021年4月14日

(54)【発明の名称】ファイル配信システム及び方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20210405BHJP

   H04L 12/803 20130101ALI20210405BHJP

【ＦＩ】

   G06F13/00 520C

   H04L12/803

【請求項の数】6

【全頁数】22

(21)【出願番号】特願2017-152935(P2017-152935)

(22)【出願日】2017年8月8日

(65)【公開番号】特開2019-32680(P2019-32680A)

(43)【公開日】2019年2月28日

【審査請求日】2019年9月3日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110001863

【氏名又は名称】特許業務法人アテンダ国際特許事務所

(72)【発明者】

【氏名】徳永 和宏

(72)【発明者】

【氏名】玉置 真也

(72)【発明者】

【氏名】岩澤 宏紀

(72)【発明者】

【氏名】高谷 直樹

【審査官】 間野 裕一

(56)【参考文献】

【文献】 特開平８−３１４８２１（ＪＰ，Ａ）

【文献】 特開２０１３−４９９５（ＪＰ，Ａ）

【文献】 特表２０１６−５０２７７４（ＪＰ，Ａ）

【文献】 特開２００８−２８３５７１（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１０／０３０６３７３（ＵＳ，Ａ１）

【文献】 川野 敦史，代理サーバにおける可変長ブロックを用いる並列ダウンロード方式の提案，電子情報通信学会技術研究報告，社団法人電子情報通信学会，２００７年 １月１１日，第１０６巻，第４６１号，第７−１２頁，ＩＮ２００６−１３９

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｈ０４Ｌ １２／００

(57)【特許請求の範囲】

【請求項1】

ファイル配信サービスを提供する複数のファイル配信サーバとユーザ端末とを備えたファイル配信システムにおいて、
前記ファイル配信サーバと前記ユーザ端末との間に配置されたエッジサーバを備え、
前記エッジサーバは、
前記複数のファイル配信サーバの１つから前記ファイルの一部分を部分ファイルとしてダウンロードする複数の部分ファイルダウンロード部と、
前記ユーザ端末からダウンロード要求を受け付けるとダウンロード処理の並列化数を決定し、前記並列化数分の前記部分ファイルダウンロード部に対してダウンロード対象箇所を指定してダウンロードを指示するとともに、前記部分ファイルダウンロード部から取得した部分ファイルを結合して要求元の前記ユーザ端末に配信する統合処理部とを備え、
前記統合処理部は、ダウンロード開始からダウンロード済みの部分ファイルの合計サイズが第１の閾値以上になると、前記各部分ファイルダウンロード部にダウンロードさせる部分ファイルのサイズを増加させるよう指示し、さらにダウンロード済みの部分ファイルの合計サイズが前記第１の閾値より大きい第２の閾値以上になると、前記部分ファイルダウンロード部に他の部分ファイルダウンロード部でのダウンロード対象と重複するダウンロード対象を指示する
ことを特徴とするファイル配信システム。

【請求項2】

前記複数の部分ファイルダウンロード部は、それぞれ名前解決サーバを用いてファイル配信サービスに係る名前から前記ファイル配信サーバのアドレスを解決するサーバアドレス解決手段を備え、前記統合処理部からのダウンロード指示に対して前記サーバアドレス解決手段により解決されたアドレスを有するファイル配信サーバからファイルの一部分をダウンロードする
ことを特徴とする請求項１記載のファイル配信システム。

【請求項3】

前記エッジサーバは、ファイル配信サービスに係る名前に対する１つ以上のファイル配信サーバのアドレスを保持するアドレス管理手段を備え、
前記統合処理部は、前記アドレス管理手段から取得したファイル配信サーバのアドレスを指定して前記部分ファイルダウンロード部にダウンロードを指示する
ことを特徴とする請求項１記載のファイル配信システム。

【請求項4】

前記統合処理部は、ダウンロード処理の過程において、前記並列化数を変更する
ことを特徴とする請求項１乃至３何れか１項記載のファイル配信システム。

【請求項5】

前記ユーザ端末はアクセス回線を介して通信事業者網に収容されており、
前記エッジサーバは、前記統合処理部が前記アクセス回線に対して前記ユーザ端末側に配置されているとともに、前記部分ファイルダウンロード処理部が通信事業者網に配置されている
ことを特徴とする請求項１乃至５何れか１項記載のファイル配信システム。

【請求項6】

ファイル配信サービスを提供する複数のファイル配信サーバとユーザ端末とを備えたファイル配信システムにおけるファイル配信方法において、
前記ファイル配信システムは前記ファイル配信サーバと前記ユーザ端末との間に配置されたエッジサーバを備え、
前記エッジサーバの統合処理部が、前記ユーザ端末からダウンロード要求を受け付けるとダウンロード処理の並列化数を決定し、前記エッジサーバの部分ファイルダウンロード部であって前記並列化数分の部分ファイルダウンロード部に対してダウンロード対象箇所を指定してダウンロードを指示するステップと、
前記エッジサーバの部分ファイルダウンロード部が、前記統合処理部からの指示に基づき前記複数のファイル配信サーバの１つから前記ファイルの一部分を部分ファイルとしてダウンロードするステップと、
前記エッジサーバの統合処理部が、前記部分ファイルダウンロード部から取得した部分ファイルを結合して要求元の前記ユーザ端末に配信するステップと、
前記統合処理部が、ダウンロード開始からダウンロード済みの部分ファイルの合計サイズが第１の閾値以上になると、前記各部分ファイルダウンロード部にダウンロードさせる部分ファイルのサイズを増加させるよう指示し、さらにダウンロード済みの部分ファイルの合計サイズが前記第１の閾値より大きい第２の閾値以上になると、前記部分ファイルダウンロード部に他の部分ファイルダウンロード部でのダウンロード対象と重複するダウンロード対象を指示するステップとを備えた
ことを特徴とするファイル配信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、インターネットなどのネットワーク上の１つ以上のコンテンツサーバからコンテンツに係るファイルをユーザ端末がダウンロードするファイル配信システム及び方法に関する。

【背景技術】

【0002】

近年、高画質静止画や高画質動画等の大容量なデータをダウンロードする端末及びデータ配信サーバ並びに大容量なデータを転送するサービスの普及により、ダウンロード通信の高速化が求められている。

【0003】

ダウンロード通信は、より高速な通信アクセス規格を用いることによって高速化が期待できる。現在普及している通信アクセス規格は、無線アクセスではＬＴＥ（Long Term Evolution）（３ＧＰＰ：3rd Generation Partnership Project）、有線アクセスではＧＥ−ＰＯＮ（Gigabit Passive-Optical Network）（ＩＴＵ−Ｔ Ｇ．９８４）などがあり、最大１Ｇｂｐｓ程度の通信が利用可能である。さらに今後普及が見込まれる通信アクセス規格として無線アクセスでは最大伝送速度６．９３Ｇｂｐｓを提供する無線ＬＡＮ規格ＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｙ、２０Ｇｂｐｓを提供する５Ｇ（第５世代移動通信システム）（３ＧＰＰ）、近距離無線アクセスでは最大１０Ｇｂｐｓ以上の通信速度を提供可能なＩＥＥＥ８０２．１５．３ｅ、有線アクセスでは最大伝送速度１０Ｇｂｐｓを提供する１０Ｇ−ＥＰＯＮ（10Gigabit-Ethernet PON）、１０Ｇ−ＰＯＮ（10Gigabit-PON）（ＩＴＵ−Ｔ Ｇ．９８７）などがあり、ダウンロード通信の高速化が見込まれる。

【0004】

しかし、通信アクセス規格はダウンロード通信の速度を決める一つの要素に過ぎず、通信プロトコルの制御にボトルネックがある場合や配信サーバや端末とサーバ間のネットワーク装置の処理能力が逼迫している場合にはダウンロード通信の高速化は実現できない。

【0005】

映像データなどの配信サービスにおけるダウンロード通信の高速化を図る従来技術としては非特許文献１に記載されたものが知られている。非特許文献１は、Ｍｕｌｔｉｐａｔｈ−ＨＴＴＰ（Multipath-Hypertext Transfer Protocol）（Ｒａｎｇｅリクエスト：非特許文献２参照）やＭＰＴＣＰ（Multipath TCP）によりダウンロード高速化を実現する研究に関するものである。非特許文献１によると、Ｍｕｌｔｉｐａｔｈ−ＨＴＴＰは、ＭＰＴＣＰよりも性能を出せることがあるとされている（同文献Ｆｉｇ．１３参照）。

【0006】

非特許文献４に記載のＭＥＣ（Multi-Access Edge Computing）は、クラウドコンピューティングよりも端末により近いエッジネットワークのサーバを、配信データの保持（キャッシュ）用のエッジサーバとして活用し、ダウンロードアクセス逼迫を避けることによりダウンロード通信の高速化を図ることができる技術である。ＭＥＣは、端末とサーバ間の通信遅延時間を小さくすることが可能であるため、通信速度が通信遅延時間に依存するＴＣＰ（Transfer Control Protocol）やＱＵＩＣ（Quick UDP Internet Connections）などのプロトコルを用いた通信を高速化する効果が期待できる。高速な通信アクセス規格とＭＥＣを用いることによりダウンロード通信の高速化を図ることができる。

【0007】

また、他の従来技術としては非特許文献３に記載されたものが知られている。非特許文献３に記載のものは、数ｃｍの通信距離を想定したＴｒａｎｓｆｅｒＪｅｔ（登録商標）と呼ばれる近距離無線転送技術である。

【先行技術文献】

【非特許文献】

【0008】

【非特許文献1】Juhoon Kim, 他4名, "Multi-source Multipath HTTP (mHTTP): A Proposal", ACM SIGMETRICS Performance Evaluation Review, October 2013

【非特許文献2】R. Fielding, 他2名, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC7233, Internet Engineering Task Force (IETF), June 2014

【非特許文献3】「ＴｒａｎｓｆｅｒＪｅｔホワイトペーパー Ｒｅｖｉｓｉｏｎ １．２」、ＴｒａｎｓｆｅｒＪｅｔコンソーシアム、２０１５年９月

【非特許文献4】Multi-access Edge Computing, http://www.etsi.org/technologies-clusters/technologies/multi-access-edge-computing, Jun. 2007.

【発明の概要】

【発明が解決しようとする課題】

【0009】

しかし、非特許文献１ではＭｕｌｔｉｐａｔｈ−ＨＴＴＰが有用であると記載されているものの、ファイルの並列ダウンロード、ファイル統合、アドレス解決などの仕組みをすべて端末に実装してもらわなければできない問題がある。また、非特許文献１に記載の研究内容ではＬＴＥ、Ｗｉ−Ｆｉ（登録商標）など通信インターフェースの分のみ並列化しているため、ＬＴＥ側とＷｉ−Ｆｉ（登録商標）側それぞれのサーバまたはサーバまでのネットワークにボトルネックがある場合には、高速化できない課題がある。また、並列ダウンロードを行う相手のサーバが１台の場合には、そのサーバの処理能力がボトルネックになり、端末の回線帯域が十分あったとしてもダウンロードスループットを向上できない課題がある。

【0010】

また、非特許文献４のＭＥＣによるダウンロード高速化の方法は、ユーザ端末により近い多くのサーバにデータファイル（コンテンツ）のコピーをあらかじめ保持（キャッシュ）しておく必要があり、頻繁にダウンロードされないファイルを含めてエッジサーバに保持して高速化を図る場合、膨大なストレージをＭＥＣのエッジサーバに用意しなければならない課題がある。

【0011】

また、非特許文献３に記載の近距離無線通信技術を用いることで端末へのダウンロード高速化を図ることができるが、近距離無線通信技術を実装するサーバにあらかじめ保持していないコンテンツに関しては、配信サーバや配信サーバまでのネットワークの転送スループットがボトルネックとなり、ファイルのダウンロード高速化ができない課題がある。

【0012】

本発明は上記事情に鑑みてなされたものであり、その目的とするところは、ファイル配信サーバの配信能力や経由するネットワークに限界や制限があってもユーザ端末の可用帯域により近い高スループットを提供できるファイル配信システム及び方法を提供することにある。

【課題を解決するための手段】

【0013】

上記目的を達成するために、本願発明は、ファイル配信サービスを提供する複数のファイル配信サーバとユーザ端末とを備えたファイル配信システムにおいて、前記ファイル配信サーバと前記ユーザ端末との間に配置されたエッジサーバを備え、前記エッジサーバは、前記複数のファイル配信サーバの１つから前記ファイルの一部分を部分ファイルとしてダウンロードする複数の部分ファイルダウンロード部と、前記ユーザ端末からダウンロード要求を受け付けるとダウンロード処理の並列化数を決定し、前記並列化数分の前記部分ファイルダウンロード部に対してダウンロード対象箇所を指定してダウンロードを指示するとともに、前記部分ファイルダウンロード部から取得した部分ファイルを結合して要求元の前記ユーザ端末に配信する統合処理部とを備え、前記統合処理部は、ダウンロード開始からダウンロード済みの部分ファイルの合計サイズが第１の閾値以上になると、前記各部分ファイルダウンロード部にダウンロードさせる部分ファイルのサイズを増加させるよう指示し、さらにダウンロード済みの部分ファイルの合計サイズが前記第１の閾値より大きい第２の閾値以上になると、前記部分ファイルダウンロード部に他の部分ファイルダウンロード部でのダウンロード対象と重複するダウンロード対象を指示することを特徴とする。

【発明の効果】

【0014】

本発明によれば、ファイル配信サーバの配信能力や経由するネットワークに限界や制限があっても、ユーザ端末の可用帯域により近い高スループットを提供可能となる。

【図面の簡単な説明】

【0015】

【図1】第１の実施の形態に係るファイル配信システムの構成図

【図2】第１の実施の形態に係るファイル配信システムのシーケンス図

【図3】第１の実施の形態に係るエッジサーバの部分ダウンロード機能の機能ブロック図

【図4】第１の実施の形態に係るエッジサーバの統合ダウンロード機能の機能ブロック図

【図5】チャンクサイズ変更処理を説明する図

【図6】チャンクサイズ変更処理を説明する図

【図7】チャンクサイズ変更処理を説明する統合処理部の処理フロー

【図8】チャンクサイズ変更処理を説明する統合処理部の処理フロー

【図9】チャンクサイズ変更処理を説明する統合処理部の処理フロー

【図10】チャンクの冗長化処理を説明する図

【図11】部分ダウンロー機能の増加処理を説明する図

【図12】部分ダウンロー機能の減少処理を説明する図

【図13】チャンクファイルサイズの一次評価を行うグラフ

【図14】第２の実施の形態に係るファイル配信システムの構成図

【図15】第２の実施の形態に係るファイル配信システムのシーケンス図

【図16】第２の実施の形態に係るエッジサーバの部分ダウンロード機能の機能ブロック図

【図17】第２の実施の形態に係るエッジサーバの統合ダウンロード機能の機能ブロック図

【図18】統合ダウンロード機能のＩＰアドレス管理部における管理データの一例

【図19】第３の実施の形態に係るファイル配信システムの構成図

【図20】第４の実施の形態に係るエッジサーバの統合ダウンロード機能の機能ブロック図

【発明を実施するための形態】

【0016】

まず本発明の概要について説明する。本発明に係るファイル配信システムは、ユーザ端末のダウンロード要求を契機に、ユーザ端末またはエッジサーバシステムが、ユーザ端末が実際に利用可能な回線帯域に応じて１つ以上のコンテンツサーバからコンテンツを高速に並列ダウンロードするものである。

【0017】

より具体的には、コンテンツの原本ファイルを配信するファイル配信サーバと、ユーザ端末との間に、ユーザ端末のダウンロード要求に応じてファイル配信サーバに対してダウンロード通信の並列化を行うエッジサーバを配備する。ここでファイル配信サーバは、コンテンツに係る原本ファイルやその複製をユーザ端末に配信するサーバであり、分散ファイル配信サービスにおける各分散ファイル配信サーバを含む。例えばＣＤＮでは、ファイル配信サーバは、原本ファイルを配信する原本サーバだけでなく、原本サーバから取得した原本ファイルの複製を配信する複数のＣＤＮサーバを含む。

【0018】

エッジサーバは、ファイル配信サーバの１つ以上のＩＰアドレスを取得し、１つ以上のファイル配信に対して部分的ファイル（以下「チャンク」と言う）単位で部分ダウンロードを複数回行い、複数のチャンクを統合してユーザ端末に対して高速なダウンロードを提供する。

【0019】

また、エッジサーバは、ファイル配信サーバの１つ以上のＩＰアドレスのリストの中から並列ダウンロードに使用するファイル配信サーバを選択し、部分ダウンロードを実施し、ユーザ端末とエッジサーバ間の通信中の回線帯域に応じてファイル配信サーバの個数の変更を可能とする。

【0020】

また、エッジサーバは、チャンクの並列ダウンロードの進捗状況によって（具体的にはダウンロードが完了したチャンク合計によって）チャンクのファイルサイズとチャンク取得回数を変更することにより、エッジサーバからユーザ端末へのダウンロード開始を迅速に行うと共に並列ダウンロード完了を迅速に行う。

【0021】

また、エッジサーバの統合ダウンロード機能は、ユーザ端末に対してファイル配信サーバよりも大きな最大送信バッファサイズかつ公平性に配慮しない輻輳制御によるパケット送信を行うことにより、ファイル配信サーバよりも広帯域なダウンロードを可能とする。

【0022】

また、エッジサーバの統合ダウンロード機能は、ユーザ端末との通信、部分ダウンロード機能との通信の間に入り、通信プロトコルの変換を可能とする。

【0023】

以下、本発明の実施の形態について詳述する。

【0024】

［第１の実施の形態］
本発明の第１の実施の形態に係るファイル配信システムについて図面を参照して説明する。図１は第１の実施の形態に係るファイル配信システムの構成図である。

【0025】

図１に示すように、インターネットなどのネットワーク１０には、ファイル配信サーバである複数の原本／ＣＤＮサーバ１００とＤＮＳ（Domain Name System）サーバ２００が配置されている。

【0026】

本実施の形態において原本／ＣＤＮサーバ１００とは、原本ファイルを配信する原本ファイルを配信する原本サーバか、ＣＤＮにおけるファイル配信サーバであって原本ファイル又はその複製を配信するＣＤＮサーバの何れかであることを意味する。各原本／ＣＤＮサーバ１００は、それぞれ同一内容（同一コンテンツ）を有する同一ファイルを配信可能となっている。

【0027】

ＤＮＳサーバ２００は、原本／ＣＤＮサーバ１００によるファイル配信サービスに係る名前（ここでは原本／ＣＤＮサーバ１００の名前）を解決して原本／ＣＤＮサーバ１００のアドレスを応答する名前解決サーバである。ここで、ある名前解決要求に対してＤＮＳサーバ２００が応答するアドレスは必ずしも一意ではない点に留意されたい。すなわち、ＤＮＳサーバ２００は、ファイル配信サービスの種類・規格等に応じて、同じ名前の名前解決要求に対して異なるアドレスを応答することができる。異なるアドレスの応答処理は、例えばラウンドロビンにより各原本／ＣＤＮサーバ１００のアドレスを応答要求毎に異なるものを応答することができる。また例えば、ＣＤＮの設定にしたがって、要求元の装置のネットワークにおける位置等を考慮して地理的又はネットワーク距離的に最も近い原本／ＣＤＮサーバ１００のアドレスを応答することができる。ＤＮＳサーバ２００は権威ＤＮＳサーバであってもキャッシュＤＮＳサーバであってもよい。

【0028】

ユーザ端末１は、アクセス回線２０を介して通信事業者網（図示省略）に収容されている。アクセス回線２０の規格や通信事業者網のネットワーク規格等は不問である。すなわち通信事業者網は移動体通信網であってもよいし固定通信網であってもよい。図１ではユーザ端末１は、無線アクセス回線２０により通信事業者網に収容されており、ユーザ端末１が移動することにより低速ＲＡＴ（Radio Access Technology）エリア２５や高速ＲＡＴエリア２６など複数の異なる規格のアクセス回線を利用可能であることを例示している。通信事業者網は、原本／ＣＤＮサーバ１００が配置されているネットワーク１０に接続している。

【0029】

本発明に係るファイル配信システムは、図１に示すように、原本／ＣＤＮサーバ１００とユーザ端末１との間の通信経路上に配備されたエッジサーバ３００を備える。エッジサーバ３００の配備場所は、例えばユーザ端末１を収容する基地局やエッジルータなどの通信事業者ネットワーク内が挙げられる。

【0030】

エッジサーバ３００は、図１に示すように、複数の部分ダウンロード機能（以下「部分ＤＬ機能」と記載する）３１０と、統合ダウンロード機能（以下「統合ＤＬ機能」と記載する）３２０とを備えている。エッジサーバ３００の各機能は、ハードウェアにより実装してもよいし、コンピュータにプログラムをインストールして実装してもよい。またエッジサーバ３００は、基地局やエッジルータなどにおける中継機能と一体に実装してもよいし個別に実装してもよい。またエッジサーバ３００は、後述するように、各機能部を分散して配備してもよい。例えば、一部の部分ダウンロード機能３１０を、エッジではなく通信事業者ネットワークのコアネットワークに配置することができる、

【0031】

本実施の形態に係るファイル配信システムでは、ユーザ端末１からのダウンロードリクエスト（図１のステップ（１））を契機に、エッジサーバ３００の複数の部分ＤＬ機能３１０から、複数の原本サーバ／ＣＤＮサーバ１００のＩＰアドレスを取得する（図１のステップ（２））。

【0032】

エッジサーバ３００の複数の部分ＤＬ機能３１０は、複数の原本／ＣＤＮサーバ１００に部分ダウンロード要求を実施する（図１のステップ（３））。部分ダウンロード処理は、例えば非特許文献２に記載のＨＴＴＰ ＲＡＮＧＥリクエストを用いることができる。

【0033】

エッジサーバ３００の統合ＤＬ機能３２０は、複数の部分ＤＬ機能３１０からチャンクファイルを収集・統合し（図１のステップ（４））、ユーザ端末１にファイルを高速転送する（図１のステップ（５））。

【0034】

統合ＤＬ機能３２０と部分ＤＬ機能３１０は、地理的に異なる場所に配備してもよいし、同じ場所や同じサーバに配備してもよい。それぞれの原本／ＣＤＮサーバ１００からより小さなＲＴＴ（Round-Trip Time）で高速に部分ＤＬ機能３１０が受信させる場合には、複数の部分ＤＬ機能３１０を地理的に分けて配備する。更に統合ＤＬ機能３２０及び部分ＤＬ機能３１０を実装するサーバについては、原本／ＣＤＮサーバ１００よりもＯＳの最大送信バッファサイズを大きくし、輻輳制御アルゴリズムをより広帯域向け変更することにより、部分ＤＬ機能３１０と統合ＤＬ機能３２０間、統合ＤＬ機能３２０とユーザ端末１間のスループットを向上させることが可能である。

【0035】

本実施の形態に係るファイル配信システムにおけるファイル配信の流れについて図２のシーケンスチャートを参照して説明する。ここでは、ユーザ端末１が広帯域ＲＡＴに在圏しているものとする（ステップＳ１）。

【0036】

本実施の形態では、ユーザ端末１のダウンロードリクエストを契機に、統合ＤＬ機能３２０が最初に利用する部分ＤＬ機能３１０の数すなわち並列化数を決定し、並列化数分の部分ＤＬ機能３１０にチャンクファイルのダウンロード指示を行う（ステップＳ２〜Ｓ６）。エッジサーバ３００の複数の部分ＤＬ機能３１０は、複数の原本／ＣＤＮサーバ１００のＩＰアドレスを取得する（ステップＳ７〜Ｓ１２）。

【0037】

エッジサーバ３００の複数の部分ＤＬ機能３１０は、複数の原本／ＣＤＮサーバ１００に部分ダウンロード要求を実施し、チャンクファイルを取得する（ステップＳ１３〜Ｓ１８）。統合ＤＬ機能３２０は、部分ＤＬ機能３１０からチャンクファイルのダウンロード結果取得後、タスク未割り当てのチャンクファイルのダウンロード指示を与えることにより、受信速度が速い部分ＤＬ機能３１０ほど多くの部分ダウンロードタスクを実施することができる（ステップＳ１９〜Ｓ２４）。

【0038】

エッジサーバ３００の統合ＤＬ機能３２０は、複数の部分ＤＬ機能３１０からチャンクファイルを収集・統合し、ユーザ端末１にファイルを高速転送する（ステップＳ２５〜Ｓ２８）。部分ＤＬ機能３１０は、統合ＤＬ機能３２０にチャンクファイルを配信したら、当該チャンクファイルを削除する（ステップＳ２９〜Ｓ３１）。

【0039】

次に、本実施の形態における部分ＤＬ機能３１０の詳細について図３を参照して説明する。図３は、第１の実施の形態に係るエッジサーバの部分ＤＬ機能の機能ブロック図である。

【0040】

部分ＤＬ機能３１０は、図３に示すように、統合ＤＬ機能通信処理部３１１と、原本／ＣＤＮサーバ処理部３１２と、チャンクバッファ部３１３とを備えている。

【0041】

統合ＤＬ機能通信処理部３１１は、統合ＤＬ機能３２０から部分ダウンロードの指示、部分ファイルを取得する際のファイルサイズ（チャンクサイズ）の指示を受信すると共に、チャンク取得結果とチャンクバッファに一時的に保持されるチャンクファイルの送信を統合ＤＬ機能３２０に対して実施する。

【0042】

原本／ＣＤＮサーバ処理部３１２は、原本／ＣＤＮサーバ１００からチャンクファイルを取得し、チャンクファイルを取得するのに要した時間をチャンクファイル要求と取得完了の通信プロトコルメッセージから算出して統合ＤＬ機能３２０に送信する。また、原本／ＣＤＮサーバ処理部３１２は、ＤＮＳサーバ２００を用いて原本／サーバアドレスの解決を行う。取得したチャンクファイルはチャンクバッファ部３１３に一時的に保持する。

【0043】

チャンクバッファ部３１３は、原本／ＣＤＮサーバ１００から取得したチャンクファイルを一時的に保持する領域である。チャンクバッファ部３１３は、統合ＤＬ機能３２０に送信完了済みのチャンクファイルに関しては保持領域節約のため削除する機能を持つ。

【0044】

次に、本実施の形態における統合ＤＬ機能３２０の詳細について図４を参照して説明する。図４は、第１の実施の形態に係るエッジサーバの統合ＤＬ機能の機能ブロック図である。

【0045】

統合ＤＬ機能３２０は、図４に示すように、端末通信処理部３２１と、統合処理部３２２と、部分ＤＬ機能通信処理部３２３とを備えている。

【0046】

端末通信処理部３２１は、ユーザ端末１からのダウンロード要求を受信すると共に、チャンクファイルを統合してユーザ端末１に送信する。なお、ユーザ端末１はチャンクダウンロードであったことは意識しない点に留意されたい。

【0047】

統合処理部３２２は、端末通信処理部３２１と部分ＤＬ機能通信処理部３２３と連携し、部分ＤＬ機能３１０で並列ダウンロードさせる数（並列化数）、チャンクファイルサイズ、各部分ＤＬ機能３１０に取得させるチャンク部分を決定する。当該決定処理に当たっては、統合ＤＬ機能３２０からユーザ端末１へのファイル送信速度（ユーザ端末１の可用帯域に相当）、原本／ＣＤＮサーバ１００から各部分ＤＬ機能３１０へのファイル送信速度の実績情報などを用いる。

【0048】

部分ＤＬ機能通信処理部３２３は、各部分ＤＬ機能３１０に対し部分ダウンロードの指示を行うと共に、各部分ＤＬ機能３１０から原本／ＣＤＮサーバ１００のアドレス、チャンク取得結果、チャンクファイルを受信し、統合処理部３２２に伝達する。

【0049】

以下に、統合ＤＬ機能３２０における、部分ＤＬ機能３１０を用いたチャンクファイルのダウロード処理制御の詳細について図５及び図６を参照して説明する。図５及び図６はチャンクサイズ変更処理を説明する図である。

【0050】

エッジサーバ３００からユーザ端末１区間のダウンロードは、エッジサーバ３００が原本／ＣＤＮサーバ１００から部分的にファイルを取得した後でないと開始できないため、大きなチャンクサイズで取得してしまうと、ユーザ端末１のダウンロード開始が遅れてしまう。一方、チャンクサイズが小さいと、原本／ＣＤＮサーバ１００とエッジサーバ３００間の部分ファイル取得の手順を実施する回数が多くなり、部分ダウンロードのスループットが下がってしまう。

【0051】

そこで本実施の形態では、図５及び図６に示すように、統合ＤＬ機能３２０における統合処理部３２２において、各部分ＤＬ機能３１０で取得させるチャンクサイズを可変にすることにより（前半はチャンクファイルのサイズを小さめに設定し、前半以降にサイズを大きめに設定して各部分ＤＬ機能３１０に要求することにより）、端末へのダウンロード開始を遅らせることなく、部分ＤＬのスループット低下も防ぐ。

【0052】

統合ＤＬ機能３２０の統合処理部３２２におけるチャンクサイズの変更処理の一例について図７〜図９のフローチャートを参照して説明する。本処理例は、統合ＤＬ機能３２０の統合処理部３２２においてチャンクサイズを前半、中盤、後半用に変更するフローチャート例である。なお、チャンク取得の後半はダウンロード処理を冗長化して完了を早くすることも可能である。ここでは、チャンクサイズの変更とともにダウンロード処理の冗長化（後述する）を行う例を説明する。

【0053】

図７に示すように、統合処理部３２２は、ユーザ端末１のダウンロードリクエストを受信すると、各部分ＤＬ機能３１０に、ダウンロードさせる原本／ＣＤＮサーバ１００を割り当てる（ステップＳ１０１〜Ｓ１０２）。統合処理部３２２は、ダウンロード済みのチャンクファイルサイズの合計を示す値Ｘ＿ＳＵＭをゼロに初期化するとともに、チャンクサイズとして並列ダウンロード前半用のパラメータに設定し、各部分ＤＬ機能３１０によるチャンクファイルの並列ダウンロード処理（図８参照）を実施する（ステップＳ１０３〜Ｓ１０５）。そして、値Ｘ＿ＳＵＭが第１の閾値以上となったら、第２の閾値以上となるまでの期間は、チャンクサイズとして並列ダウンロード中盤用のパラメータに設定し、各部分ＤＬ機能３１０によるチャンクファイルの並列ダウンロード処理（図８参照）を実施する（ステップＳ１０６〜Ｓ１０９）。そして、値Ｘ＿ＳＵＭが第２の閾値以上となったら、チャンクサイズとして並列ダウンロード終盤用のパラメータに設定し、各部分ＤＬ機能３１０によるチャンクファイルの冗長化並列ダウンロード処理（図９参照）を実施する（ステップＳ１０６，Ｓ１１０〜Ｓ１１１）。

【0054】

前記ステップＳ１０５及びＳ１０９の並列ダウンロード処理では、統合処理部３２２は図８に示すように、部分ＤＬ機能３１０に空きタスクがあれば、当該部分ＤＬ機能３１０を用いて、取得済みのチャンクファイルのサイズ合計値Ｘから設定されたチャンクサイズ分のダウンロード処理を行う（ステップＳ１２２，Ｓ１２３）。すなわち、統合処理部３２２は、各部分ＤＬ機能３１０でダウンロードするチャンクは互いに重複せず且つ連続するよう各部分ＤＬ機能３１０に部分ダウンロード指示を行う。

【0055】

一方、前記ステップＳ１１１の冗長化並列ダウンロード処理では、統合処理部３２２は図９に示すように、部分ＤＬ機能３１０に空きタスクがあれば、当該部分ＤＬ機能３１０を用いて、取得済みのチャンクファイルのサイズ合計値Ｘから設定されたチャンクサイズ分のダウンロード処理を、各部分ＤＬ機能３１０で重複して行う（ステップＳ１３２，Ｓ１３３）。

【0056】

なお、前記第１の閾値としては、例えば、最終的なチャンクサイズ合計、すなわちユーザ端末１からのダウンロード要求に係るファイルのファイルサイズを示す値Ｘ＿ＡＬＬに、所定の第１の割合Ｘ＿Ｔｈ１［％］を乗じた値を用いることができる。前記第２の閾値としては、同様に、値Ｘ＿ＡＬＬに、所定の第２の割合Ｘ＿Ｔｈ１［％］を乗じた値を用いることができる。

【0057】

次に、統合ＤＬ機能３２０の統合処理部３２２におけるダウンロード処理の冗長化処理の一例について図１０を参照して説明する。

【0058】

各原本／ＣＤＮサーバ１００は、それぞれダウンロードスループットが異なり、また時間帯によってもダウンロードスループットが異なるため、複数の部分ＤＬ機能３１０の最後のチャンクダウンロードでは、いずれかの並列ＤＬ機能３１０のダウンロードタスクがクリティカルパスとなりダウンロード完了が遅れる。

【0059】

そこで本実施の形態では、図１０に示すように、並列ダウンロード後半の並列ダウンロードタスクを冗長化し、早く取得できたチャンクファイルを用いてユーザ端末１へのダウンロードファイルを構成することにより、ダウンロード完了を向上させる。

【0060】

次に、統合ＤＬ機能３２０の統合処理部３２２において部分ＤＬ機能３１０を増減させる処理の一例について図１１及び図１２を参照して説明する。本処理例では、図１１に示すように、部分ＤＬ機能３１０の合計帯域がユーザのＲＡＴ帯域（Ｓ_ＲＡＴ）より小さい場合は、原本／ＣＤＮサーバ１００数の追加、すなわち並列化数を増加させる。一方、部分ＤＬ機能３１０の合計帯域がユーザのＲＡＴ帯域（Ｓ_ＲＡＴ）より大きい場合は、原本／ＣＤＮサーバ１００数を減らす、すなわち並列化数を減少させる。なお、増減量はあらかじめ設定した定数であってもよいし、並列ＤＬスループットと端末スループットから計算して決定してもよい。

【0061】

例えば、次式を満たす場合には、部分ＤＬ数ｋを３増加させる。なお次式でＳ_ｋはｋ番目の原本／ＣＤＮサーバ１００とエッジサーバ３００間のスループット、Ｓ_ＲＡＴはエッジサーバ３００とユーザ端末１間のスループット、Ｃ_１は少しのスループット変化で頻繁にサーバ数を変更させないための定数である。

【0062】

【数1】

【0063】

また例えば、次式を満たす場合には、ならば、部分ＤＬ数ｋを１減少させる。なお次式でＳ_ｋはｋ番目の原本／ＣＤＮサーバ１００とエッジサーバ３００間のスループット、Ｓ_ＲＡＴはエッジサーバ３００とユーザ端末１間のスループット、Ｃ_２は少しのスループット変化で頻繁にサーバ数を変更させないための定数である。

【0064】

【数2】

【0065】

本実施の形態に係るファイル配信システムについてチャンクファイルサイズに関して計算による一次評価を行った。図１３はチャンクファイルサイズの一次評価を行うグラフである。この一次評価は、エッジサーバ３００が原本／ＣＤＮサーバ１００にＨＴＴＰ Ｒａｎｇｅリクエストをどのくらいのチャンクサイズ単位で部分ダウンロードすると最もパフォーマンスが出せるのかを評価するものである。

【0066】

図１３において、横軸がチャンクファイルサイズ、縦軸が原本ファイルのダウンロード時間である。また、図１３のグラフの算出条件は、原本ファイルサイズ：４ＧＢ、原本／ＣＤＮサーバ−エッジサーバ３００間の平均スループット：２００Ｍｂｐｓ（２５ＭＢ／ｓ）である。

【0067】

図１３に示すように、チャンクファイルサイズが小さすぎると部分ダウンロード取得が遅くなる、一方、チャンクファイルサイズが大きすぎるとユーザ端末１のダウンロード開始時間が遅れることが確認できた。

【0068】

以上のように、本実施の形態に係るファイル配信システムによれば、各ファイル配信サーバの配信能力や経由するネットワークに限界や制限があっても、ユーザ端末の可用帯域により近い高スループットを提供可能となる。

【0069】

具体的には、現在の商用光回線サービスでは（将来的には移動体通信５Ｇでも）、端末は測定サイトでしか高速通信を体感できず実際のＯＴＴ（Over The Top）サービスで高速化のメリットが受けられないが、本発明により実際のＯＴＴサービスの利用で高速回線のメリットを実際に受けられるため、高速回線サービスの訴求力を向上できる。

【0070】

また、ユーザ端末１により近いエッジサーバシステムのサーバに、ユーザ端末がダウンロードするコンテンツをあらかじめ保持していなくてよくなる。具体的には、クラウドストレージのファイルは基本的に個人ごとに持っているデータであり、多人数で利用するものではないのでエッジサーバでのキャッシュ一時保持は膨大なストレージリソースが必要となり事実上困難であるが、そのような多人数がダウンロードしないコンテンツのダウンロードの高速化が可能となる。

【0071】

また、ユーザ端末１に新たな専用並列ダウンロード・統合・アドレス解決などのアプリケーションをインストールすることなく、ダウンロードのスループットの高速化が可能となる。

【0072】

ここで、本実施の形態に係るファイル配信システムの問題点について検討する。本実施の形態では、エッジサーバ３００がＤＮＳサーバ２００から原本サーバの複数のＩＰアドレスを取得する際に、複数のＩＰアドレスが別々に分散されるとは限らない。したがって、最悪１つに偏って並列化してもスループットが上がらないことが想定される。また、ユーザ端末１からダウンロードリクエストを受けてからＩＰアドレス取得を行うため、並列ダウンロード開始までにその分の遅延が発生する。

【0073】

［第２の実施の形態］
本発明の第２の実施の形態に係るファイル配信システムについて図面を参照して説明する。図１４は第２の実施の形態に係るファイル配信システムの構成図である。なお、本実施の形態においてエッジサーバ以外の構成は前記第１の実施の形態と同様である。ここでは相違点について詳述する。

【0074】

本実施の形態に係るファイル配信システムでは、図１４に示すように、ユーザ端末のダウンロードリクエストの契機によらず、エッジサーバ３００であらかじめ原本／ＣＤＮサーバ１００のＩＰアドレスを収集、更新する（図１４のステップ（１））。

【0075】

そして、ユーザ端末１のダウンロードリクエストを契機に（図１４のステップ（２））、エッジサーバ３００は並列ダウンロード数を決定し、ＤＢで管理するＩＰアドレスを有する複数原本／ＣＤＮサーバ１００に対して部分ダウンロードリクエストを送信する（図１４のステップ（３））。

【0076】

エッジサーバ３００の統合ＤＬ機能３２０が、複数の部分ＤＬ機能３１０からチャンクファイル（ブロックファイル）を収集・統合し（図１４のステップ（４））、ユーザ端末１にファイルを高速転送する（図１４のステップ（５））。

【0077】

統合ＤＬ機能３２０と部分ＤＬ機能３１０は、地理的に異なる場所に配備してもよいし、同じ場所に配備してもよい。それぞれの原本／ＣＤＮサーバ１００からより小さなＲＴＴで高速に部分ＤＬ機能３１０が受信させる場合には、複数の部分ＤＬ機能３１０を地理的に分けて配備する。更に統合ＤＬ機能３２０及び部分ＤＬ機能３１０を実装するサーバについては、原本／ＣＤＮサーバ１００よりもＯＳの最大送信バッファサイズを大きくし、輻輳制御アルゴリズムをより広帯域向け変更することにより、部分ＤＬ機能３１０と統合ＤＬ機能３２０間、統合ＤＬ機能３２０とユーザ端末１間のスループットを向上させることが可能である。

【0078】

本実施の形態に係るファイル配信システムにおけるファイル配信の流れについて図１５のシーケンスチャートを参照して説明する。

【0079】

本実施の形態では、ユーザ端末１のダウンロードリクエストによらず、エッジサーバ３００であらかじめ原本／ＣＤＮサーバのＩＰアドレスを収集してＤＢに登録し、一定間隔で更新する（ステップＳ５１〜５６）。

【0080】

ここでは、ユーザ端末１が広帯域ＲＡＴに在圏しているものとする（ステップＳ６１）。ユーザ端末１のダウンロードリクエストを契機に、エッジサーバ３００は部分ダウンロード数を決定し、ＤＢで管理するＩＰアドレスの複数原本／ＣＤＮサーバ１００から部分ダウンロードするよう複数の部分ＤＬ機能３１０に指示を行う（ステップＳ６２〜Ｓ６６）。エッジサーバ３００の複数の部分ＤＬ機能３１０は、複数の原本／ＣＤＮサーバ１００に部分ダウンロード要求を実施し、チャンクファイルを取得する（ステップＳ６７〜Ｓ７２）。統合ＤＬ機能３２０は、部分ＤＬ機能３１０からチャンクファイルのダウンロード結果取得後、タスク未割り当てのチャンクファイルのダウンロード指示を与えることにより、受信速度が速い部分ＤＬ機能３１０ほど多くの部分ＤＬタスクを実施することができる（ステップＳ７３〜Ｓ７８）。

【0081】

エッジサーバ３００の統合ＤＬ機能３１０は、複数の部分ＤＬ機能３１０からチャンクファイルを収集・統合し、ユーザ端末１にファイルを高速転送する（ステップＳ７９〜Ｓ８２）。部分ＤＬ機能３１０は、統合ＤＬ機能３２０にチャンクファイルを配信したら、当該チャンクファイルを削除する（ステップＳ８３〜Ｓ８５）。

【0082】

次に、本実施の形態における部分ＤＬ機能３１０の詳細について図１６を参照して説明する。図１６は、第２の実施の形態に係るエッジサーバの部分ＤＬ機能の機能ブロック図である。

【0083】

部分ＤＬ機能３１０は、図１６に示すように、統合ＤＬ機能通信処理部３１１と、原本／ＣＤＮサーバ処理部３１２と、チャンクバッファ部３１３と、ＩＰアドレス管理部３１４を備えている。

【0084】

統合ＤＬ機能通信処理部３１１は、統合ＤＬ機能３２０から部分ダウンロードの指示、部分ファイルを取得する際のファイルサイズ（チャンクサイズ）の指示を受信すると共に、チャンク取得結果とチャンクバッファに一時的に保持されるチャンクファイルの送信を統合ＤＬ機能３２０に対して実施する。

【0085】

原本／ＣＤＮサーバ処理部３１２は、原本／ＣＤＮサーバ１００からチャンクファイルを取得し、チャンクファイルを取得するのに要した時間をチャンクファイル要求と取得完了の通信プロトコルメッセージから算出して統合ＤＬ機能３２０に送信する。また原本／ＣＤＮサーバ処理部３１２は、ＤＮＳサーバ２００を用いて原本／サーバアドレスの解決を行う。取得したチャンクファイルはチャンクバッファ部３１３に一時的に保持する。

【0086】

チャンクバッファ部３１３は、原本／ＣＤＮサーバ１００から取得したチャンクファイルを一時的に保持する領域である。チャンクバッファ部３１３は、統合ＤＬ機能３２０に送信完了済みのチャンクファイルに関しては保持領域節約のため削除する機能を持つ。

【0087】

ＩＰアドレス管理部３１４は、ユーザ端末１のダウンロード要求とは非同期に部分ＤＬ機能３１０で取得したＩＰアドレスを統合ＤＬ機能３２０に送信する。統合ＤＬ機能３２０ではなく、各部分ＤＬ機能３１０でＩＰアドレスを取得することにより、部分ＤＬ機能３１０が地理的に分散して配備した場合に、部分ＤＬ機能３１０に地理的に近く、各部分ＤＬ機能３１０からより高速な部分ダウンロードが可能な原本／ＣＤＮサーバ１００のＩＰアドレスを取得することが可能となる。

【0088】

次に、本実施の形態における統合ＤＬ機能３２０の詳細について図１７を参照して説明する。図１７は、第２の実施の形態に係るエッジサーバの統合ＤＬ機能の機能ブロック図である。

【0089】

統合ＤＬ機能３２０は、図１７に示すように、端末通信処理部３２１と、統合処理部３２２と、部分ＤＬ機能通信処理部３２３と、ＩＰアドレス管理部３２４と、ＩＰアドレス取得部３２５を備えている。

【0090】

端末通信処理部３２１は、ユーザ端末１からのダウンロード要求を受信すると共に、チャンクファイルを統合してユーザ端末１に送信する。なお、ユーザ端末１はチャンクダウンロードであったことは意識しない点に留意されたい。

【0091】

統合処理部３２２は、端末通信処理部３２１と部分ＤＬ機能通信処理部３２３とＩＰアドレス管理部３２４と連携し、部分ＤＬ機能３１０で並列ダウンロードさせる数（並列化数）、チャンクサイズ、各部分ＤＬ機能３１０に取得させるチャンク部分を決定する。当該決定処理に当たっては、統合ＤＬ機能３２０からユーザ端末１へのファイル送信速度（ユーザ端末１の可用帯域に相当）、原本／ＣＤＮサーバ１００から各部分ＤＬ機能３１０へのファイル送信速度の実績情報などを用いる。

【0092】

部分ＤＬ機能通信処理部３２３は、各部分ＤＬ機能３１０に対し部分ダウンロードの指示を行うと共に、各部分ＤＬ機能３１０から原本／ＣＤＮサーバ１００のアドレス、チャンク取得結果、チャンクファイルを受信し、統合処理部３２２に伝達する。

【0093】

ＩＰアドレス管理部３２４は、統合処理部３２２で用いる原本／ＣＤＮサーバ１００のＩＰアドレスと各ＩＰアドレスに関連するＴＴＬ（Time To Live）、スループット情報などを管理する。ＩＰアドレス管理部３２４における管理データの一例を図１８に示す。

【0094】

ＩＰアドレス取得部３２５は、ユーザ端末１のダウンロードリクエストとは非同期にＤＮＳサーバ２００から原本／ＣＤＮサーバ１００のＩＰアドレスを複数取得する。また、部分ＤＬ機能３１０で保持する原本／ＣＤＮサーバ１００のＩＰアドレスを各部分ＤＬ機能３１０から取得することにより、地理的に異なる原本／ＣＤＮサーバ１００のＩＰアドレスを複数取得こともできる。なお、どちらかの取得方法だけでもよい。

【0095】

本実施の形態では、統合処理部３２２におけるチャンクサイズ変更処理、動作フローチャート例、冗長化処理、統合処理部３２２で部分ＤＬ機能３１０の増減処理については第１の実施の形態と同様であるため説明は省略する。

【0096】

本実施の形態に係るファイル配信システムによれば、原本／ＣＤＮサーバ１００のＩＰアドレスをエッジサーバ３００で管理するので、前記第１の実施の形態で挙げた問題点を解決することができる。ただし、第１の実施の形態と比較して、エッジサーバ３００の構成が複雑化すること等の問題点がある。

【0097】

［第３の実施の形態］
本発明の第３の実施の形態に係るファイル配信システムについて図面を参照して説明する。図１９は第３の実施の形態に係るファイル配信システムの構成図である。なお、本実施の形態においてエッジサーバ以外の構成は前記第２の実施の形態と同様である。ここでは相違点について詳述する。

【0098】

本実施の形態では、図１９に示すように、エッジサーバ３００のうち統合ＤＬ機能３２０を、アクセス回線２０に対してユーザ端末１側に配置した構成となっている。エッジサーバ３００のうち他の機能部については第２の実施の形態と同様に、アクセス回線２０に対して原本／ＣＤＮサーバ１００側である通信事業者網に配置される。

【0099】

本実施の形態に係るファイル配信システムでは、第２の実施の形態と同様に、ユーザ端末のダウンロードリクエストの契機によらず、エッジサーバ３００であらかじめ原本／ＣＤＮサーバ１００のＩＰアドレスを収集、更新する（図１９のステップ（１））。

【0100】

そして、ユーザ端末１がＴｒａｎｓｆｅｒＪｅｔ等の近距離無線転送技術を用いて統合ＤＬ機能３２０にリクエストすることを契機に（図１９のステップ（２））、統合ＤＬ機能３２０が並列ダウンロード数を決定し、ＤＢで管理するＩＰアドレスを有する複数原本／ＣＤＮサーバ１００から部分ダウンロードするよう制御する（図１９のステップ（３））。

【0101】

エッジサーバ３００の統合ＤＬ機能３２０が、複数の部分ＤＬ機能３１０からチャンクファイル（ブロックファイル）を収集・統合し（図１９のステップ（４））、近距離無線転送技術を用いてユーザ端末１にファイルを高速転送する（図１９のステップ（５））。

【0102】

統合ＤＬ機能３２０は、部分ＤＬ機能３１０との通信ではＴＣＰ／ＩＰを用いるが、ユーザ端末１との通信では近距離無線転送技術を用いて転送プロトコルはＴＣＰ／ＩＰ以外を用いることも可能である。ユーザ端末１と統合ＤＬ機能３２０間で使用する近距離無線転送技術は、送信側と受信側が数ｃｍの短距離でｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔであり他の端末の通信の影響がないため、安定した高速転送を実現できる。

【0103】

次に、本実施の形態における統合ＤＬ機能３２０の詳細について図２０を参照して説明する。図２０は、第３の実施の形態に係るエッジサーバの統合ＤＬ機能の機能ブロック図である。

【0104】

統合ＤＬ機能３２０は、図２０に示すように、端末近接通信処理部３２６と、統合処理部３２２と、部分ＤＬ機能通信処理部３２３と、ＩＰアドレス管理部３２４と、ＩＰアドレス取得部３２５を備えている。

【0105】

端末近接通信処理部３２６は、ユーザ端末１から近距離無線転送技術によりダウンロード要求を受信すると共に、ユーザ端末１に対してチャンクファイルを統合して近距離無線転送技術によりユーザ端末１にファイルを送信する。

【0106】

統合ＤＬ機能３２０における他の構成についての機能は、第２の実施の形態と同様であるため説明を省略する。なお、本実施の形態におけるＩＰアドレス取得部３２５およびＩＰアドレス管理部３２４は統合処理部３２２と同一のサーバに実装しなくてもよく、物理的に離れていてもよい。

【0107】

また、本実施の形態における部分ＤＬ機能３１０についての構成や機能、さらにファイル配信システムのシーケンスについても第２の実施の形態と同様であるため説明を省略する。さらに、本実施の形態では、統合処理部３２２のチャンクサイズ変更処理、動作フローチャート例、冗長化処理、統合処理部３２２で部分ＤＬ機能３１０の増減処理については第１の実施の形態と同様であるため説明は省略する。

【0108】

以上、本発明の実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施の形態では、チャンクサイズ変更処理、冗長化処理、並列化数の増減処理を組み合わせた例について説明したが、何れか１つ又は任意の組み合わせであってもよい。また、上記実施の形態で説明した前記各処理におけるアルゴリズム・当該アルゴリズムで用いるパラメータ・閾値・定数等は一例であって、他のアルゴリズム等であっても本発明を実施できる。

【符号の説明】

【0109】

１…ユーザ端末
１０…ネットワーク
２０…アクセス回線
１００…原本／ＣＤＮサーバ
２００…ＤＮＳサーバ
３００…エッジサーバ
３１０…部分ＤＬ機能
３１１…統合ＤＬ機能通信処理部
３１２…原本／ＣＤＮサーバ処理部
３１３…チャンクバッファ部
３１４…ＩＰアドレス管理部
３２０…統合ＤＬ機能
３２１…端末通信処理部
３２２…統合処理部
３２３…部分ＤＬ機能通信処理部
３２４…ＩＰアドレス管理部
３２５…ＩＰアドレス取得部
３２６…端末近接通信処理部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】