特許第6857103号(P6857103)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電信電話株式会社の特許一覧
<>
  • 特許6857103-ファイル配信システム及び方法 図000004
  • 特許6857103-ファイル配信システム及び方法 図000005
  • 特許6857103-ファイル配信システム及び方法 図000006
  • 特許6857103-ファイル配信システム及び方法 図000007
  • 特許6857103-ファイル配信システム及び方法 図000008
  • 特許6857103-ファイル配信システム及び方法 図000009
  • 特許6857103-ファイル配信システム及び方法 図000010
  • 特許6857103-ファイル配信システム及び方法 図000011
  • 特許6857103-ファイル配信システム及び方法 図000012
  • 特許6857103-ファイル配信システム及び方法 図000013
  • 特許6857103-ファイル配信システム及び方法 図000014
  • 特許6857103-ファイル配信システム及び方法 図000015
  • 特許6857103-ファイル配信システム及び方法 図000016
  • 特許6857103-ファイル配信システム及び方法 図000017
  • 特許6857103-ファイル配信システム及び方法 図000018
  • 特許6857103-ファイル配信システム及び方法 図000019
  • 特許6857103-ファイル配信システム及び方法 図000020
  • 特許6857103-ファイル配信システム及び方法 図000021
  • 特許6857103-ファイル配信システム及び方法 図000022
  • 特許6857103-ファイル配信システム及び方法 図000023
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6857103
(24)【登録日】2021年3月23日
(45)【発行日】2021年4月14日
(54)【発明の名称】ファイル配信システム及び方法
(51)【国際特許分類】
   G06F 13/00 20060101AFI20210405BHJP
   H04L 12/803 20130101ALI20210405BHJP
【FI】
   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)【参考文献】
【文献】 特開平8−314821(JP,A)
【文献】 特開2013−4995(JP,A)
【文献】 特表2016−502774(JP,A)
【文献】 特開2008−283571(JP,A)
【文献】 米国特許出願公開第2010/0306373(US,A1)
【文献】 川野 敦史,代理サーバにおける可変長ブロックを用いる並列ダウンロード方式の提案,電子情報通信学会技術研究報告,社団法人電子情報通信学会,2007年 1月11日,第106巻,第461号,第7−12頁,IN2006−139
(58)【調査した分野】(Int.Cl.,DB名)
G06F 13/00
H04L 12/00
(57)【特許請求の範囲】
【請求項1】
ファイル配信サービスを提供する複数のファイル配信サーバとユーザ端末とを備えたファイル配信システムにおいて、
前記ファイル配信サーバと前記ユーザ端末との間に配置されたエッジサーバを備え、
前記エッジサーバは、
前記複数のファイル配信サーバの1つから前記ファイルの一部分を部分ファイルとしてダウンロードする複数の部分ファイルダウンロード部と、
前記ユーザ端末からダウンロード要求を受け付けるとダウンロード処理の並列化数を決定し、前記並列化数分の前記部分ファイルダウンロード部に対してダウンロード対象箇所を指定してダウンロードを指示するとともに、前記部分ファイルダウンロード部から取得した部分ファイルを結合して要求元の前記ユーザ端末に配信する統合処理部とを備え
前記統合処理部は、ダウンロード開始からダウンロード済みの部分ファイルの合計サイズが第1の閾値以上になると、前記各部分ファイルダウンロード部にダウンロードさせる部分ファイルのサイズを増加させるよう指示し、さらにダウンロード済みの部分ファイルの合計サイズが前記第1の閾値より大きい第2の閾値以上になると、前記部分ファイルダウンロード部に他の部分ファイルダウンロード部でのダウンロード対象と重複するダウンロード対象を指示する
ことを特徴とするファイル配信システム。
【請求項2】
前記複数の部分ファイルダウンロード部は、それぞれ名前解決サーバを用いてファイル配信サービスに係る名前から前記ファイル配信サーバのアドレスを解決するサーバアドレス解決手段を備え、前記統合処理部からのダウンロード指示に対して前記サーバアドレス解決手段により解決されたアドレスを有するファイル配信サーバからファイルの一部分をダウンロードする
ことを特徴とする請求項1記載のファイル配信システム。
【請求項3】
前記エッジサーバは、ファイル配信サービスに係る名前に対する1つ以上のファイル配信サーバのアドレスを保持するアドレス管理手段を備え、
前記統合処理部は、前記アドレス管理手段から取得したファイル配信サーバのアドレスを指定して前記部分ファイルダウンロード部にダウンロードを指示する
ことを特徴とする請求項1記載のファイル配信システム。
【請求項4】
前記統合処理部は、ダウンロード処理の過程において、前記並列化数を変更する
ことを特徴とする請求項1乃至何れか1項記載のファイル配信システム。
【請求項5】
前記ユーザ端末はアクセス回線を介して通信事業者網に収容されており、
前記エッジサーバは、前記統合処理部が前記アクセス回線に対して前記ユーザ端末側に配置されているとともに、前記部分ファイルダウンロード処理部が通信事業者網に配置されている
ことを特徴とする請求項1乃至何れか1項記載のファイル配信システム。
【請求項6】
ファイル配信サービスを提供する複数のファイル配信サーバとユーザ端末とを備えたファイル配信システムにおけるファイル配信方法において、
前記ファイル配信システムは前記ファイル配信サーバと前記ユーザ端末との間に配置されたエッジサーバを備え、
前記エッジサーバの統合処理部が、前記ユーザ端末からダウンロード要求を受け付けるとダウンロード処理の並列化数を決定し、前記エッジサーバの部分ファイルダウンロード部であって前記並列化数分の部分ファイルダウンロード部に対してダウンロード対象箇所を指定してダウンロードを指示するステップと、
前記エッジサーバの部分ファイルダウンロード部が、前記統合処理部からの指示に基づき前記複数のファイル配信サーバの1つから前記ファイルの一部分を部分ファイルとしてダウンロードするステップと、
前記エッジサーバの統合処理部が、前記部分ファイルダウンロード部から取得した部分ファイルを結合して要求元の前記ユーザ端末に配信するステップと
前記統合処理部が、ダウンロード開始からダウンロード済みの部分ファイルの合計サイズが第1の閾値以上になると、前記各部分ファイルダウンロード部にダウンロードさせる部分ファイルのサイズを増加させるよう指示し、さらにダウンロード済みの部分ファイルの合計サイズが前記第1の閾値より大きい第2の閾値以上になると、前記部分ファイルダウンロード部に他の部分ファイルダウンロード部でのダウンロード対象と重複するダウンロード対象を指示するステップとを備えた
ことを特徴とするファイル配信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、インターネットなどのネットワーク上の1つ以上のコンテンツサーバからコンテンツに係るファイルをユーザ端末がダウンロードするファイル配信システム及び方法に関する。
【背景技術】
【0002】
近年、高画質静止画や高画質動画等の大容量なデータをダウンロードする端末及びデータ配信サーバ並びに大容量なデータを転送するサービスの普及により、ダウンロード通信の高速化が求められている。
【0003】
ダウンロード通信は、より高速な通信アクセス規格を用いることによって高速化が期待できる。現在普及している通信アクセス規格は、無線アクセスではLTE(Long Term Evolution)(3GPP:3rd Generation Partnership Project)、有線アクセスではGE−PON(Gigabit Passive-Optical Network)(ITU−T G.984)などがあり、最大1Gbps程度の通信が利用可能である。さらに今後普及が見込まれる通信アクセス規格として無線アクセスでは最大伝送速度6.93Gbpsを提供する無線LAN規格IEEE802.11ac、IEEE802.11ay、20Gbpsを提供する5G(第5世代移動通信システム)(3GPP)、近距離無線アクセスでは最大10Gbps以上の通信速度を提供可能なIEEE802.15.3e、有線アクセスでは最大伝送速度10Gbpsを提供する10G−EPON(10Gigabit-Ethernet PON)、10G−PON(10Gigabit-PON)(ITU−T G.987)などがあり、ダウンロード通信の高速化が見込まれる。
【0004】
しかし、通信アクセス規格はダウンロード通信の速度を決める一つの要素に過ぎず、通信プロトコルの制御にボトルネックがある場合や配信サーバや端末とサーバ間のネットワーク装置の処理能力が逼迫している場合にはダウンロード通信の高速化は実現できない。
【0005】
映像データなどの配信サービスにおけるダウンロード通信の高速化を図る従来技術としては非特許文献1に記載されたものが知られている。非特許文献1は、Multipath−HTTP(Multipath-Hypertext Transfer Protocol)(Rangeリクエスト:非特許文献2参照)やMPTCP(Multipath TCP)によりダウンロード高速化を実現する研究に関するものである。非特許文献1によると、Multipath−HTTPは、MPTCPよりも性能を出せることがあるとされている(同文献Fig.13参照)。
【0006】
非特許文献4に記載のMEC(Multi-Access Edge Computing)は、クラウドコンピューティングよりも端末により近いエッジネットワークのサーバを、配信データの保持(キャッシュ)用のエッジサーバとして活用し、ダウンロードアクセス逼迫を避けることによりダウンロード通信の高速化を図ることができる技術である。MECは、端末とサーバ間の通信遅延時間を小さくすることが可能であるため、通信速度が通信遅延時間に依存するTCP(Transfer Control Protocol)やQUIC(Quick UDP Internet Connections)などのプロトコルを用いた通信を高速化する効果が期待できる。高速な通信アクセス規格とMECを用いることによりダウンロード通信の高速化を図ることができる。
【0007】
また、他の従来技術としては非特許文献3に記載されたものが知られている。非特許文献3に記載のものは、数cmの通信距離を想定したTransferJet(登録商標)と呼ばれる近距離無線転送技術である。
【先行技術文献】
【非特許文献】
【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】「TransferJetホワイトペーパー Revision 1.2」、TransferJetコンソーシアム、2015年9月
【非特許文献4】Multi-access Edge Computing, http://www.etsi.org/technologies-clusters/technologies/multi-access-edge-computing, Jun. 2007.
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかし、非特許文献1ではMultipath−HTTPが有用であると記載されているものの、ファイルの並列ダウンロード、ファイル統合、アドレス解決などの仕組みをすべて端末に実装してもらわなければできない問題がある。また、非特許文献1に記載の研究内容ではLTE、Wi−Fi(登録商標)など通信インターフェースの分のみ並列化しているため、LTE側とWi−Fi(登録商標)側それぞれのサーバまたはサーバまでのネットワークにボトルネックがある場合には、高速化できない課題がある。また、並列ダウンロードを行う相手のサーバが1台の場合には、そのサーバの処理能力がボトルネックになり、端末の回線帯域が十分あったとしてもダウンロードスループットを向上できない課題がある。
【0010】
また、非特許文献4のMECによるダウンロード高速化の方法は、ユーザ端末により近い多くのサーバにデータファイル(コンテンツ)のコピーをあらかじめ保持(キャッシュ)しておく必要があり、頻繁にダウンロードされないファイルを含めてエッジサーバに保持して高速化を図る場合、膨大なストレージをMECのエッジサーバに用意しなければならない課題がある。
【0011】
また、非特許文献3に記載の近距離無線通信技術を用いることで端末へのダウンロード高速化を図ることができるが、近距離無線通信技術を実装するサーバにあらかじめ保持していないコンテンツに関しては、配信サーバや配信サーバまでのネットワークの転送スループットがボトルネックとなり、ファイルのダウンロード高速化ができない課題がある。
【0012】
本発明は上記事情に鑑みてなされたものであり、その目的とするところは、ファイル配信サーバの配信能力や経由するネットワークに限界や制限があってもユーザ端末の可用帯域により近い高スループットを提供できるファイル配信システム及び方法を提供することにある。
【課題を解決するための手段】
【0013】
上記目的を達成するために、本願発明は、ファイル配信サービスを提供する複数のファイル配信サーバとユーザ端末とを備えたファイル配信システムにおいて、前記ファイル配信サーバと前記ユーザ端末との間に配置されたエッジサーバを備え、前記エッジサーバは、前記複数のファイル配信サーバの1つから前記ファイルの一部分を部分ファイルとしてダウンロードする複数の部分ファイルダウンロード部と、前記ユーザ端末からダウンロード要求を受け付けるとダウンロード処理の並列化数を決定し、前記並列化数分の前記部分ファイルダウンロード部に対してダウンロード対象箇所を指定してダウンロードを指示するとともに、前記部分ファイルダウンロード部から取得した部分ファイルを結合して要求元の前記ユーザ端末に配信する統合処理部とを備え、前記統合処理部は、ダウンロード開始からダウンロード済みの部分ファイルの合計サイズが第1の閾値以上になると、前記各部分ファイルダウンロード部にダウンロードさせる部分ファイルのサイズを増加させるよう指示し、さらにダウンロード済みの部分ファイルの合計サイズが前記第1の閾値より大きい第2の閾値以上になると、前記部分ファイルダウンロード部に他の部分ファイルダウンロード部でのダウンロード対象と重複するダウンロード対象を指示することを特徴とする。
【発明の効果】
【0014】
本発明によれば、ファイル配信サーバの配信能力や経由するネットワークに限界や制限があっても、ユーザ端末の可用帯域により近い高スループットを提供可能となる。
【図面の簡単な説明】
【0015】
図1】第1の実施の形態に係るファイル配信システムの構成図
図2】第1の実施の形態に係るファイル配信システムのシーケンス図
図3】第1の実施の形態に係るエッジサーバの部分ダウンロード機能の機能ブロック図
図4】第1の実施の形態に係るエッジサーバの統合ダウンロード機能の機能ブロック図
図5】チャンクサイズ変更処理を説明する図
図6】チャンクサイズ変更処理を説明する図
図7】チャンクサイズ変更処理を説明する統合処理部の処理フロー
図8】チャンクサイズ変更処理を説明する統合処理部の処理フロー
図9】チャンクサイズ変更処理を説明する統合処理部の処理フロー
図10】チャンクの冗長化処理を説明する図
図11】部分ダウンロー機能の増加処理を説明する図
図12】部分ダウンロー機能の減少処理を説明する図
図13】チャンクファイルサイズの一次評価を行うグラフ
図14】第2の実施の形態に係るファイル配信システムの構成図
図15】第2の実施の形態に係るファイル配信システムのシーケンス図
図16】第2の実施の形態に係るエッジサーバの部分ダウンロード機能の機能ブロック図
図17】第2の実施の形態に係るエッジサーバの統合ダウンロード機能の機能ブロック図
図18】統合ダウンロード機能のIPアドレス管理部における管理データの一例
図19】第3の実施の形態に係るファイル配信システムの構成図
図20】第4の実施の形態に係るエッジサーバの統合ダウンロード機能の機能ブロック図
【発明を実施するための形態】
【0016】
まず本発明の概要について説明する。本発明に係るファイル配信システムは、ユーザ端末のダウンロード要求を契機に、ユーザ端末またはエッジサーバシステムが、ユーザ端末が実際に利用可能な回線帯域に応じて1つ以上のコンテンツサーバからコンテンツを高速に並列ダウンロードするものである。
【0017】
より具体的には、コンテンツの原本ファイルを配信するファイル配信サーバと、ユーザ端末との間に、ユーザ端末のダウンロード要求に応じてファイル配信サーバに対してダウンロード通信の並列化を行うエッジサーバを配備する。ここでファイル配信サーバは、コンテンツに係る原本ファイルやその複製をユーザ端末に配信するサーバであり、分散ファイル配信サービスにおける各分散ファイル配信サーバを含む。例えばCDNでは、ファイル配信サーバは、原本ファイルを配信する原本サーバだけでなく、原本サーバから取得した原本ファイルの複製を配信する複数のCDNサーバを含む。
【0018】
エッジサーバは、ファイル配信サーバの1つ以上のIPアドレスを取得し、1つ以上のファイル配信に対して部分的ファイル(以下「チャンク」と言う)単位で部分ダウンロードを複数回行い、複数のチャンクを統合してユーザ端末に対して高速なダウンロードを提供する。
【0019】
また、エッジサーバは、ファイル配信サーバの1つ以上のIPアドレスのリストの中から並列ダウンロードに使用するファイル配信サーバを選択し、部分ダウンロードを実施し、ユーザ端末とエッジサーバ間の通信中の回線帯域に応じてファイル配信サーバの個数の変更を可能とする。
【0020】
また、エッジサーバは、チャンクの並列ダウンロードの進捗状況によって(具体的にはダウンロードが完了したチャンク合計によって)チャンクのファイルサイズとチャンク取得回数を変更することにより、エッジサーバからユーザ端末へのダウンロード開始を迅速に行うと共に並列ダウンロード完了を迅速に行う。
【0021】
また、エッジサーバの統合ダウンロード機能は、ユーザ端末に対してファイル配信サーバよりも大きな最大送信バッファサイズかつ公平性に配慮しない輻輳制御によるパケット送信を行うことにより、ファイル配信サーバよりも広帯域なダウンロードを可能とする。
【0022】
また、エッジサーバの統合ダウンロード機能は、ユーザ端末との通信、部分ダウンロード機能との通信の間に入り、通信プロトコルの変換を可能とする。
【0023】
以下、本発明の実施の形態について詳述する。
【0024】
[第1の実施の形態]
本発明の第1の実施の形態に係るファイル配信システムについて図面を参照して説明する。図1は第1の実施の形態に係るファイル配信システムの構成図である。
【0025】
図1に示すように、インターネットなどのネットワーク10には、ファイル配信サーバである複数の原本/CDNサーバ100とDNS(Domain Name System)サーバ200が配置されている。
【0026】
本実施の形態において原本/CDNサーバ100とは、原本ファイルを配信する原本ファイルを配信する原本サーバか、CDNにおけるファイル配信サーバであって原本ファイル又はその複製を配信するCDNサーバの何れかであることを意味する。各原本/CDNサーバ100は、それぞれ同一内容(同一コンテンツ)を有する同一ファイルを配信可能となっている。
【0027】
DNSサーバ200は、原本/CDNサーバ100によるファイル配信サービスに係る名前(ここでは原本/CDNサーバ100の名前)を解決して原本/CDNサーバ100のアドレスを応答する名前解決サーバである。ここで、ある名前解決要求に対してDNSサーバ200が応答するアドレスは必ずしも一意ではない点に留意されたい。すなわち、DNSサーバ200は、ファイル配信サービスの種類・規格等に応じて、同じ名前の名前解決要求に対して異なるアドレスを応答することができる。異なるアドレスの応答処理は、例えばラウンドロビンにより各原本/CDNサーバ100のアドレスを応答要求毎に異なるものを応答することができる。また例えば、CDNの設定にしたがって、要求元の装置のネットワークにおける位置等を考慮して地理的又はネットワーク距離的に最も近い原本/CDNサーバ100のアドレスを応答することができる。DNSサーバ200は権威DNSサーバであってもキャッシュDNSサーバであってもよい。
【0028】
ユーザ端末1は、アクセス回線20を介して通信事業者網(図示省略)に収容されている。アクセス回線20の規格や通信事業者網のネットワーク規格等は不問である。すなわち通信事業者網は移動体通信網であってもよいし固定通信網であってもよい。図1ではユーザ端末1は、無線アクセス回線20により通信事業者網に収容されており、ユーザ端末1が移動することにより低速RAT(Radio Access Technology)エリア25や高速RATエリア26など複数の異なる規格のアクセス回線を利用可能であることを例示している。通信事業者網は、原本/CDNサーバ100が配置されているネットワーク10に接続している。
【0029】
本発明に係るファイル配信システムは、図1に示すように、原本/CDNサーバ100とユーザ端末1との間の通信経路上に配備されたエッジサーバ300を備える。エッジサーバ300の配備場所は、例えばユーザ端末1を収容する基地局やエッジルータなどの通信事業者ネットワーク内が挙げられる。
【0030】
エッジサーバ300は、図1に示すように、複数の部分ダウンロード機能(以下「部分DL機能」と記載する)310と、統合ダウンロード機能(以下「統合DL機能」と記載する)320とを備えている。エッジサーバ300の各機能は、ハードウェアにより実装してもよいし、コンピュータにプログラムをインストールして実装してもよい。またエッジサーバ300は、基地局やエッジルータなどにおける中継機能と一体に実装してもよいし個別に実装してもよい。またエッジサーバ300は、後述するように、各機能部を分散して配備してもよい。例えば、一部の部分ダウンロード機能310を、エッジではなく通信事業者ネットワークのコアネットワークに配置することができる、
【0031】
本実施の形態に係るファイル配信システムでは、ユーザ端末1からのダウンロードリクエスト(図1のステップ(1))を契機に、エッジサーバ300の複数の部分DL機能310から、複数の原本サーバ/CDNサーバ100のIPアドレスを取得する(図1のステップ(2))。
【0032】
エッジサーバ300の複数の部分DL機能310は、複数の原本/CDNサーバ100に部分ダウンロード要求を実施する(図1のステップ(3))。部分ダウンロード処理は、例えば非特許文献2に記載のHTTP RANGEリクエストを用いることができる。
【0033】
エッジサーバ300の統合DL機能320は、複数の部分DL機能310からチャンクファイルを収集・統合し(図1のステップ(4))、ユーザ端末1にファイルを高速転送する(図1のステップ(5))。
【0034】
統合DL機能320と部分DL機能310は、地理的に異なる場所に配備してもよいし、同じ場所や同じサーバに配備してもよい。それぞれの原本/CDNサーバ100からより小さなRTT(Round-Trip Time)で高速に部分DL機能310が受信させる場合には、複数の部分DL機能310を地理的に分けて配備する。更に統合DL機能320及び部分DL機能310を実装するサーバについては、原本/CDNサーバ100よりもOSの最大送信バッファサイズを大きくし、輻輳制御アルゴリズムをより広帯域向け変更することにより、部分DL機能310と統合DL機能320間、統合DL機能320とユーザ端末1間のスループットを向上させることが可能である。
【0035】
本実施の形態に係るファイル配信システムにおけるファイル配信の流れについて図2のシーケンスチャートを参照して説明する。ここでは、ユーザ端末1が広帯域RATに在圏しているものとする(ステップS1)。
【0036】
本実施の形態では、ユーザ端末1のダウンロードリクエストを契機に、統合DL機能320が最初に利用する部分DL機能310の数すなわち並列化数を決定し、並列化数分の部分DL機能310にチャンクファイルのダウンロード指示を行う(ステップS2〜S6)。エッジサーバ300の複数の部分DL機能310は、複数の原本/CDNサーバ100のIPアドレスを取得する(ステップS7〜S12)。
【0037】
エッジサーバ300の複数の部分DL機能310は、複数の原本/CDNサーバ100に部分ダウンロード要求を実施し、チャンクファイルを取得する(ステップS13〜S18)。統合DL機能320は、部分DL機能310からチャンクファイルのダウンロード結果取得後、タスク未割り当てのチャンクファイルのダウンロード指示を与えることにより、受信速度が速い部分DL機能310ほど多くの部分ダウンロードタスクを実施することができる(ステップS19〜S24)。
【0038】
エッジサーバ300の統合DL機能320は、複数の部分DL機能310からチャンクファイルを収集・統合し、ユーザ端末1にファイルを高速転送する(ステップS25〜S28)。部分DL機能310は、統合DL機能320にチャンクファイルを配信したら、当該チャンクファイルを削除する(ステップS29〜S31)。
【0039】
次に、本実施の形態における部分DL機能310の詳細について図3を参照して説明する。図3は、第1の実施の形態に係るエッジサーバの部分DL機能の機能ブロック図である。
【0040】
部分DL機能310は、図3に示すように、統合DL機能通信処理部311と、原本/CDNサーバ処理部312と、チャンクバッファ部313とを備えている。
【0041】
統合DL機能通信処理部311は、統合DL機能320から部分ダウンロードの指示、部分ファイルを取得する際のファイルサイズ(チャンクサイズ)の指示を受信すると共に、チャンク取得結果とチャンクバッファに一時的に保持されるチャンクファイルの送信を統合DL機能320に対して実施する。
【0042】
原本/CDNサーバ処理部312は、原本/CDNサーバ100からチャンクファイルを取得し、チャンクファイルを取得するのに要した時間をチャンクファイル要求と取得完了の通信プロトコルメッセージから算出して統合DL機能320に送信する。また、原本/CDNサーバ処理部312は、DNSサーバ200を用いて原本/サーバアドレスの解決を行う。取得したチャンクファイルはチャンクバッファ部313に一時的に保持する。
【0043】
チャンクバッファ部313は、原本/CDNサーバ100から取得したチャンクファイルを一時的に保持する領域である。チャンクバッファ部313は、統合DL機能320に送信完了済みのチャンクファイルに関しては保持領域節約のため削除する機能を持つ。
【0044】
次に、本実施の形態における統合DL機能320の詳細について図4を参照して説明する。図4は、第1の実施の形態に係るエッジサーバの統合DL機能の機能ブロック図である。
【0045】
統合DL機能320は、図4に示すように、端末通信処理部321と、統合処理部322と、部分DL機能通信処理部323とを備えている。
【0046】
端末通信処理部321は、ユーザ端末1からのダウンロード要求を受信すると共に、チャンクファイルを統合してユーザ端末1に送信する。なお、ユーザ端末1はチャンクダウンロードであったことは意識しない点に留意されたい。
【0047】
統合処理部322は、端末通信処理部321と部分DL機能通信処理部323と連携し、部分DL機能310で並列ダウンロードさせる数(並列化数)、チャンクファイルサイズ、各部分DL機能310に取得させるチャンク部分を決定する。当該決定処理に当たっては、統合DL機能320からユーザ端末1へのファイル送信速度(ユーザ端末1の可用帯域に相当)、原本/CDNサーバ100から各部分DL機能310へのファイル送信速度の実績情報などを用いる。
【0048】
部分DL機能通信処理部323は、各部分DL機能310に対し部分ダウンロードの指示を行うと共に、各部分DL機能310から原本/CDNサーバ100のアドレス、チャンク取得結果、チャンクファイルを受信し、統合処理部322に伝達する。
【0049】
以下に、統合DL機能320における、部分DL機能310を用いたチャンクファイルのダウロード処理制御の詳細について図5及び図6を参照して説明する。図5及び図6はチャンクサイズ変更処理を説明する図である。
【0050】
エッジサーバ300からユーザ端末1区間のダウンロードは、エッジサーバ300が原本/CDNサーバ100から部分的にファイルを取得した後でないと開始できないため、大きなチャンクサイズで取得してしまうと、ユーザ端末1のダウンロード開始が遅れてしまう。一方、チャンクサイズが小さいと、原本/CDNサーバ100とエッジサーバ300間の部分ファイル取得の手順を実施する回数が多くなり、部分ダウンロードのスループットが下がってしまう。
【0051】
そこで本実施の形態では、図5及び図6に示すように、統合DL機能320における統合処理部322において、各部分DL機能310で取得させるチャンクサイズを可変にすることにより(前半はチャンクファイルのサイズを小さめに設定し、前半以降にサイズを大きめに設定して各部分DL機能310に要求することにより)、端末へのダウンロード開始を遅らせることなく、部分DLのスループット低下も防ぐ。
【0052】
統合DL機能320の統合処理部322におけるチャンクサイズの変更処理の一例について図7図9のフローチャートを参照して説明する。本処理例は、統合DL機能320の統合処理部322においてチャンクサイズを前半、中盤、後半用に変更するフローチャート例である。なお、チャンク取得の後半はダウンロード処理を冗長化して完了を早くすることも可能である。ここでは、チャンクサイズの変更とともにダウンロード処理の冗長化(後述する)を行う例を説明する。
【0053】
図7に示すように、統合処理部322は、ユーザ端末1のダウンロードリクエストを受信すると、各部分DL機能310に、ダウンロードさせる原本/CDNサーバ100を割り当てる(ステップS101〜S102)。統合処理部322は、ダウンロード済みのチャンクファイルサイズの合計を示す値X_SUMをゼロに初期化するとともに、チャンクサイズとして並列ダウンロード前半用のパラメータに設定し、各部分DL機能310によるチャンクファイルの並列ダウンロード処理(図8参照)を実施する(ステップS103〜S105)。そして、値X_SUMが第1の閾値以上となったら、第2の閾値以上となるまでの期間は、チャンクサイズとして並列ダウンロード中盤用のパラメータに設定し、各部分DL機能310によるチャンクファイルの並列ダウンロード処理(図8参照)を実施する(ステップS106〜S109)。そして、値X_SUMが第2の閾値以上となったら、チャンクサイズとして並列ダウンロード終盤用のパラメータに設定し、各部分DL機能310によるチャンクファイルの冗長化並列ダウンロード処理(図9参照)を実施する(ステップS106,S110〜S111)。
【0054】
前記ステップS105及びS109の並列ダウンロード処理では、統合処理部322は図8に示すように、部分DL機能310に空きタスクがあれば、当該部分DL機能310を用いて、取得済みのチャンクファイルのサイズ合計値Xから設定されたチャンクサイズ分のダウンロード処理を行う(ステップS122,S123)。すなわち、統合処理部322は、各部分DL機能310でダウンロードするチャンクは互いに重複せず且つ連続するよう各部分DL機能310に部分ダウンロード指示を行う。
【0055】
一方、前記ステップS111の冗長化並列ダウンロード処理では、統合処理部322は図9に示すように、部分DL機能310に空きタスクがあれば、当該部分DL機能310を用いて、取得済みのチャンクファイルのサイズ合計値Xから設定されたチャンクサイズ分のダウンロード処理を、各部分DL機能310で重複して行う(ステップS132,S133)。
【0056】
なお、前記第1の閾値としては、例えば、最終的なチャンクサイズ合計、すなわちユーザ端末1からのダウンロード要求に係るファイルのファイルサイズを示す値X_ALLに、所定の第1の割合X_Th1[%]を乗じた値を用いることができる。前記第2の閾値としては、同様に、値X_ALLに、所定の第2の割合X_Th1[%]を乗じた値を用いることができる。
【0057】
次に、統合DL機能320の統合処理部322におけるダウンロード処理の冗長化処理の一例について図10を参照して説明する。
【0058】
各原本/CDNサーバ100は、それぞれダウンロードスループットが異なり、また時間帯によってもダウンロードスループットが異なるため、複数の部分DL機能310の最後のチャンクダウンロードでは、いずれかの並列DL機能310のダウンロードタスクがクリティカルパスとなりダウンロード完了が遅れる。
【0059】
そこで本実施の形態では、図10に示すように、並列ダウンロード後半の並列ダウンロードタスクを冗長化し、早く取得できたチャンクファイルを用いてユーザ端末1へのダウンロードファイルを構成することにより、ダウンロード完了を向上させる。
【0060】
次に、統合DL機能320の統合処理部322において部分DL機能310を増減させる処理の一例について図11及び図12を参照して説明する。本処理例では、図11に示すように、部分DL機能310の合計帯域がユーザのRAT帯域(SRAT)より小さい場合は、原本/CDNサーバ100数の追加、すなわち並列化数を増加させる。一方、部分DL機能310の合計帯域がユーザのRAT帯域(SRAT)より大きい場合は、原本/CDNサーバ100数を減らす、すなわち並列化数を減少させる。なお、増減量はあらかじめ設定した定数であってもよいし、並列DLスループットと端末スループットから計算して決定してもよい。
【0061】
例えば、次式を満たす場合には、部分DL数kを3増加させる。なお次式でSはk番目の原本/CDNサーバ100とエッジサーバ300間のスループット、SRATはエッジサーバ300とユーザ端末1間のスループット、Cは少しのスループット変化で頻繁にサーバ数を変更させないための定数である。
【0062】
【数1】
【0063】
また例えば、次式を満たす場合には、ならば、部分DL数kを1減少させる。なお次式でSはk番目の原本/CDNサーバ100とエッジサーバ300間のスループット、SRATはエッジサーバ300とユーザ端末1間のスループット、Cは少しのスループット変化で頻繁にサーバ数を変更させないための定数である。
【0064】
【数2】
【0065】
本実施の形態に係るファイル配信システムについてチャンクファイルサイズに関して計算による一次評価を行った。図13はチャンクファイルサイズの一次評価を行うグラフである。この一次評価は、エッジサーバ300が原本/CDNサーバ100にHTTP Rangeリクエストをどのくらいのチャンクサイズ単位で部分ダウンロードすると最もパフォーマンスが出せるのかを評価するものである。
【0066】
図13において、横軸がチャンクファイルサイズ、縦軸が原本ファイルのダウンロード時間である。また、図13のグラフの算出条件は、原本ファイルサイズ:4GB、原本/CDNサーバ−エッジサーバ300間の平均スループット:200Mbps(25MB/s)である。
【0067】
図13に示すように、チャンクファイルサイズが小さすぎると部分ダウンロード取得が遅くなる、一方、チャンクファイルサイズが大きすぎるとユーザ端末1のダウンロード開始時間が遅れることが確認できた。
【0068】
以上のように、本実施の形態に係るファイル配信システムによれば、各ファイル配信サーバの配信能力や経由するネットワークに限界や制限があっても、ユーザ端末の可用帯域により近い高スループットを提供可能となる。
【0069】
具体的には、現在の商用光回線サービスでは(将来的には移動体通信5Gでも)、端末は測定サイトでしか高速通信を体感できず実際のOTT(Over The Top)サービスで高速化のメリットが受けられないが、本発明により実際のOTTサービスの利用で高速回線のメリットを実際に受けられるため、高速回線サービスの訴求力を向上できる。
【0070】
また、ユーザ端末1により近いエッジサーバシステムのサーバに、ユーザ端末がダウンロードするコンテンツをあらかじめ保持していなくてよくなる。具体的には、クラウドストレージのファイルは基本的に個人ごとに持っているデータであり、多人数で利用するものではないのでエッジサーバでのキャッシュ一時保持は膨大なストレージリソースが必要となり事実上困難であるが、そのような多人数がダウンロードしないコンテンツのダウンロードの高速化が可能となる。
【0071】
また、ユーザ端末1に新たな専用並列ダウンロード・統合・アドレス解決などのアプリケーションをインストールすることなく、ダウンロードのスループットの高速化が可能となる。
【0072】
ここで、本実施の形態に係るファイル配信システムの問題点について検討する。本実施の形態では、エッジサーバ300がDNSサーバ200から原本サーバの複数のIPアドレスを取得する際に、複数のIPアドレスが別々に分散されるとは限らない。したがって、最悪1つに偏って並列化してもスループットが上がらないことが想定される。また、ユーザ端末1からダウンロードリクエストを受けてからIPアドレス取得を行うため、並列ダウンロード開始までにその分の遅延が発生する。
【0073】
[第2の実施の形態]
本発明の第2の実施の形態に係るファイル配信システムについて図面を参照して説明する。図14は第2の実施の形態に係るファイル配信システムの構成図である。なお、本実施の形態においてエッジサーバ以外の構成は前記第1の実施の形態と同様である。ここでは相違点について詳述する。
【0074】
本実施の形態に係るファイル配信システムでは、図14に示すように、ユーザ端末のダウンロードリクエストの契機によらず、エッジサーバ300であらかじめ原本/CDNサーバ100のIPアドレスを収集、更新する(図14のステップ(1))。
【0075】
そして、ユーザ端末1のダウンロードリクエストを契機に(図14のステップ(2))、エッジサーバ300は並列ダウンロード数を決定し、DBで管理するIPアドレスを有する複数原本/CDNサーバ100に対して部分ダウンロードリクエストを送信する(図14のステップ(3))。
【0076】
エッジサーバ300の統合DL機能320が、複数の部分DL機能310からチャンクファイル(ブロックファイル)を収集・統合し(図14のステップ(4))、ユーザ端末1にファイルを高速転送する(図14のステップ(5))。
【0077】
統合DL機能320と部分DL機能310は、地理的に異なる場所に配備してもよいし、同じ場所に配備してもよい。それぞれの原本/CDNサーバ100からより小さなRTTで高速に部分DL機能310が受信させる場合には、複数の部分DL機能310を地理的に分けて配備する。更に統合DL機能320及び部分DL機能310を実装するサーバについては、原本/CDNサーバ100よりもOSの最大送信バッファサイズを大きくし、輻輳制御アルゴリズムをより広帯域向け変更することにより、部分DL機能310と統合DL機能320間、統合DL機能320とユーザ端末1間のスループットを向上させることが可能である。
【0078】
本実施の形態に係るファイル配信システムにおけるファイル配信の流れについて図15のシーケンスチャートを参照して説明する。
【0079】
本実施の形態では、ユーザ端末1のダウンロードリクエストによらず、エッジサーバ300であらかじめ原本/CDNサーバのIPアドレスを収集してDBに登録し、一定間隔で更新する(ステップS51〜56)。
【0080】
ここでは、ユーザ端末1が広帯域RATに在圏しているものとする(ステップS61)。ユーザ端末1のダウンロードリクエストを契機に、エッジサーバ300は部分ダウンロード数を決定し、DBで管理するIPアドレスの複数原本/CDNサーバ100から部分ダウンロードするよう複数の部分DL機能310に指示を行う(ステップS62〜S66)。エッジサーバ300の複数の部分DL機能310は、複数の原本/CDNサーバ100に部分ダウンロード要求を実施し、チャンクファイルを取得する(ステップS67〜S72)。統合DL機能320は、部分DL機能310からチャンクファイルのダウンロード結果取得後、タスク未割り当てのチャンクファイルのダウンロード指示を与えることにより、受信速度が速い部分DL機能310ほど多くの部分DLタスクを実施することができる(ステップS73〜S78)。
【0081】
エッジサーバ300の統合DL機能310は、複数の部分DL機能310からチャンクファイルを収集・統合し、ユーザ端末1にファイルを高速転送する(ステップS79〜S82)。部分DL機能310は、統合DL機能320にチャンクファイルを配信したら、当該チャンクファイルを削除する(ステップS83〜S85)。
【0082】
次に、本実施の形態における部分DL機能310の詳細について図16を参照して説明する。図16は、第2の実施の形態に係るエッジサーバの部分DL機能の機能ブロック図である。
【0083】
部分DL機能310は、図16に示すように、統合DL機能通信処理部311と、原本/CDNサーバ処理部312と、チャンクバッファ部313と、IPアドレス管理部314を備えている。
【0084】
統合DL機能通信処理部311は、統合DL機能320から部分ダウンロードの指示、部分ファイルを取得する際のファイルサイズ(チャンクサイズ)の指示を受信すると共に、チャンク取得結果とチャンクバッファに一時的に保持されるチャンクファイルの送信を統合DL機能320に対して実施する。
【0085】
原本/CDNサーバ処理部312は、原本/CDNサーバ100からチャンクファイルを取得し、チャンクファイルを取得するのに要した時間をチャンクファイル要求と取得完了の通信プロトコルメッセージから算出して統合DL機能320に送信する。また原本/CDNサーバ処理部312は、DNSサーバ200を用いて原本/サーバアドレスの解決を行う。取得したチャンクファイルはチャンクバッファ部313に一時的に保持する。
【0086】
チャンクバッファ部313は、原本/CDNサーバ100から取得したチャンクファイルを一時的に保持する領域である。チャンクバッファ部313は、統合DL機能320に送信完了済みのチャンクファイルに関しては保持領域節約のため削除する機能を持つ。
【0087】
IPアドレス管理部314は、ユーザ端末1のダウンロード要求とは非同期に部分DL機能310で取得したIPアドレスを統合DL機能320に送信する。統合DL機能320ではなく、各部分DL機能310でIPアドレスを取得することにより、部分DL機能310が地理的に分散して配備した場合に、部分DL機能310に地理的に近く、各部分DL機能310からより高速な部分ダウンロードが可能な原本/CDNサーバ100のIPアドレスを取得することが可能となる。
【0088】
次に、本実施の形態における統合DL機能320の詳細について図17を参照して説明する。図17は、第2の実施の形態に係るエッジサーバの統合DL機能の機能ブロック図である。
【0089】
統合DL機能320は、図17に示すように、端末通信処理部321と、統合処理部322と、部分DL機能通信処理部323と、IPアドレス管理部324と、IPアドレス取得部325を備えている。
【0090】
端末通信処理部321は、ユーザ端末1からのダウンロード要求を受信すると共に、チャンクファイルを統合してユーザ端末1に送信する。なお、ユーザ端末1はチャンクダウンロードであったことは意識しない点に留意されたい。
【0091】
統合処理部322は、端末通信処理部321と部分DL機能通信処理部323とIPアドレス管理部324と連携し、部分DL機能310で並列ダウンロードさせる数(並列化数)、チャンクサイズ、各部分DL機能310に取得させるチャンク部分を決定する。当該決定処理に当たっては、統合DL機能320からユーザ端末1へのファイル送信速度(ユーザ端末1の可用帯域に相当)、原本/CDNサーバ100から各部分DL機能310へのファイル送信速度の実績情報などを用いる。
【0092】
部分DL機能通信処理部323は、各部分DL機能310に対し部分ダウンロードの指示を行うと共に、各部分DL機能310から原本/CDNサーバ100のアドレス、チャンク取得結果、チャンクファイルを受信し、統合処理部322に伝達する。
【0093】
IPアドレス管理部324は、統合処理部322で用いる原本/CDNサーバ100のIPアドレスと各IPアドレスに関連するTTL(Time To Live)、スループット情報などを管理する。IPアドレス管理部324における管理データの一例を図18に示す。
【0094】
IPアドレス取得部325は、ユーザ端末1のダウンロードリクエストとは非同期にDNSサーバ200から原本/CDNサーバ100のIPアドレスを複数取得する。また、部分DL機能310で保持する原本/CDNサーバ100のIPアドレスを各部分DL機能310から取得することにより、地理的に異なる原本/CDNサーバ100のIPアドレスを複数取得こともできる。なお、どちらかの取得方法だけでもよい。
【0095】
本実施の形態では、統合処理部322におけるチャンクサイズ変更処理、動作フローチャート例、冗長化処理、統合処理部322で部分DL機能310の増減処理については第1の実施の形態と同様であるため説明は省略する。
【0096】
本実施の形態に係るファイル配信システムによれば、原本/CDNサーバ100のIPアドレスをエッジサーバ300で管理するので、前記第1の実施の形態で挙げた問題点を解決することができる。ただし、第1の実施の形態と比較して、エッジサーバ300の構成が複雑化すること等の問題点がある。
【0097】
[第3の実施の形態]
本発明の第3の実施の形態に係るファイル配信システムについて図面を参照して説明する。図19は第3の実施の形態に係るファイル配信システムの構成図である。なお、本実施の形態においてエッジサーバ以外の構成は前記第2の実施の形態と同様である。ここでは相違点について詳述する。
【0098】
本実施の形態では、図19に示すように、エッジサーバ300のうち統合DL機能320を、アクセス回線20に対してユーザ端末1側に配置した構成となっている。エッジサーバ300のうち他の機能部については第2の実施の形態と同様に、アクセス回線20に対して原本/CDNサーバ100側である通信事業者網に配置される。
【0099】
本実施の形態に係るファイル配信システムでは、第2の実施の形態と同様に、ユーザ端末のダウンロードリクエストの契機によらず、エッジサーバ300であらかじめ原本/CDNサーバ100のIPアドレスを収集、更新する(図19のステップ(1))。
【0100】
そして、ユーザ端末1がTransferJet等の近距離無線転送技術を用いて統合DL機能320にリクエストすることを契機に(図19のステップ(2))、統合DL機能320が並列ダウンロード数を決定し、DBで管理するIPアドレスを有する複数原本/CDNサーバ100から部分ダウンロードするよう制御する(図19のステップ(3))。
【0101】
エッジサーバ300の統合DL機能320が、複数の部分DL機能310からチャンクファイル(ブロックファイル)を収集・統合し(図19のステップ(4))、近距離無線転送技術を用いてユーザ端末1にファイルを高速転送する(図19のステップ(5))。
【0102】
統合DL機能320は、部分DL機能310との通信ではTCP/IPを用いるが、ユーザ端末1との通信では近距離無線転送技術を用いて転送プロトコルはTCP/IP以外を用いることも可能である。ユーザ端末1と統合DL機能320間で使用する近距離無線転送技術は、送信側と受信側が数cmの短距離でpoint−to−pointであり他の端末の通信の影響がないため、安定した高速転送を実現できる。
【0103】
次に、本実施の形態における統合DL機能320の詳細について図20を参照して説明する。図20は、第3の実施の形態に係るエッジサーバの統合DL機能の機能ブロック図である。
【0104】
統合DL機能320は、図20に示すように、端末近接通信処理部326と、統合処理部322と、部分DL機能通信処理部323と、IPアドレス管理部324と、IPアドレス取得部325を備えている。
【0105】
端末近接通信処理部326は、ユーザ端末1から近距離無線転送技術によりダウンロード要求を受信すると共に、ユーザ端末1に対してチャンクファイルを統合して近距離無線転送技術によりユーザ端末1にファイルを送信する。
【0106】
統合DL機能320における他の構成についての機能は、第2の実施の形態と同様であるため説明を省略する。なお、本実施の形態におけるIPアドレス取得部325およびIPアドレス管理部324は統合処理部322と同一のサーバに実装しなくてもよく、物理的に離れていてもよい。
【0107】
また、本実施の形態における部分DL機能310についての構成や機能、さらにファイル配信システムのシーケンスについても第2の実施の形態と同様であるため説明を省略する。さらに、本実施の形態では、統合処理部322のチャンクサイズ変更処理、動作フローチャート例、冗長化処理、統合処理部322で部分DL機能310の増減処理については第1の実施の形態と同様であるため説明は省略する。
【0108】
以上、本発明の実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施の形態では、チャンクサイズ変更処理、冗長化処理、並列化数の増減処理を組み合わせた例について説明したが、何れか1つ又は任意の組み合わせであってもよい。また、上記実施の形態で説明した前記各処理におけるアルゴリズム・当該アルゴリズムで用いるパラメータ・閾値・定数等は一例であって、他のアルゴリズム等であっても本発明を実施できる。
【符号の説明】
【0109】
1…ユーザ端末
10…ネットワーク
20…アクセス回線
100…原本/CDNサーバ
200…DNSサーバ
300…エッジサーバ
310…部分DL機能
311…統合DL機能通信処理部
312…原本/CDNサーバ処理部
313…チャンクバッファ部
314…IPアドレス管理部
320…統合DL機能
321…端末通信処理部
322…統合処理部
323…部分DL機能通信処理部
324…IPアドレス管理部
325…IPアドレス取得部
326…端末近接通信処理部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20