JP2022051973A - 情報処理装置および情報処理方法、並びにプログラム - Google Patents
情報処理装置および情報処理方法、並びにプログラム Download PDFInfo
- Publication number
- JP2022051973A JP2022051973A JP2019021939A JP2019021939A JP2022051973A JP 2022051973 A JP2022051973 A JP 2022051973A JP 2019021939 A JP2019021939 A JP 2019021939A JP 2019021939 A JP2019021939 A JP 2019021939A JP 2022051973 A JP2022051973 A JP 2022051973A
- Authority
- JP
- Japan
- Prior art keywords
- edge
- network
- distribution terminal
- terminal
- target
- 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.)
- Pending
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 50
- 238000003672 processing method Methods 0.000 title claims description 7
- 230000001360 synchronised effect Effects 0.000 claims abstract description 55
- 230000007704 transition Effects 0.000 claims description 82
- 238000009826 distribution Methods 0.000 claims description 73
- 238000005516 engineering process Methods 0.000 abstract description 10
- 238000012545 processing Methods 0.000 description 49
- 238000000034 method Methods 0.000 description 42
- 230000004044 response Effects 0.000 description 42
- 230000008569 process Effects 0.000 description 32
- 230000003044 adaptive effect Effects 0.000 description 22
- 230000006870 function Effects 0.000 description 18
- 238000003860 storage Methods 0.000 description 12
- 230000006978 adaptation Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 8
- 239000004576 sand Substances 0.000 description 7
- 230000008859 change Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 238000001514 detection method Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001151 other effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1083—In-session procedures
- H04L65/1095—Inter-network session transfer or sharing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
- H04W36/0016—Hand-off preparation specially adapted for end-to-end data sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/16—Performing reselection for specific purposes
- H04W36/22—Performing reselection for specific purposes for handling the traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
- H04W36/023—Buffering or recovering information during reselection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/16—Performing reselection for specific purposes
- H04W36/18—Performing reselection for specific purposes for allowing seamless reselection, e.g. soft reselection
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Theoretical Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】シームレスなストリーミングを提供する。【解決手段】Source ME-HostのEdge-DANEは、DASH-Clientが移動することによりSource RANからTarget RANへのハンドオーバーが発生するのに伴って、Target RANを介してDASH-Clientに対してコンテンツをストリーミングするTarget ME-HostのEdge-DANEに対し、Source ME-HostのEdge-DANEと同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う。本技術は、例えば、シームレスなストリーミングを提供する情報処理システムに適用できる。【選択図】図1
Description
本開示は、情報処理装置および情報処理方法、並びにプログラムに関し、特に、シームレスなストリーミングを提供することができるようにした情報処理装置および情報処理方法、並びにプログラムに関する。
近年、非常な勢いで普及しているモバイルデバイスによるストリーミング視聴により、クラウドの処理負担の増大が懸念されている。このような懸念に対し、クラウドの処理負担の緩和策の1つとして、ネットワークのエッジ部に分散配置されるネットワークや、計算、ストレージリソースなどによるエッジコンピューティングを利用したストリーミングサービスの負荷分散が注目されている。
例えば、エッジコンピューティングにおいては、個々のエッジサーバの各種リソースは、セントラルクラウドに比べて小規模となるという制限がある。そのため、リソースの配置や選択などが複雑になり、管理コストが増大するというデメリットもある。それに対し、今後、いわゆる4Kや8Kなどの高画質なコンテンツのストリーミングサービスの普及がさらに拡大していくにつれて、このようなエッジコンピューティングリソースの効率的な運用を実現する仕組みが必要になると考慮される。
例えば、非特許文献1に開示されているMPEG-DASH(Dynamic Adaptive Streaming over HTTP)を利用してコンテンツを配信する技術がある。
ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)
ところで、モバイルデバイスでストリーミング視聴している最中に、デバイスが移動することによって基地局の間を跨ぐようにセルを遷移するようなハンドオーバー(以下、基地局間ハンドオーバーと称する)が発生する。このときに、遷移先のセルの環境、例えば、そのセルに含まれるクライアント数やそれらのクライアント群にサービスを提供するサービス群の実行状態などが異なるようなユースケースが想定される。
従って、このような基地局間ハンドオーバーの発生が伴うユースケースにおいても、再生ストリームが途切れることがなく、シームレスなストリーミングができることが求められる。ここで、シームレスなストリーミングとは、セルを跨って移動するような場合であっても、ストリーミングが途切れることなく継続されることである。
本開示は、このような状況に鑑みてなされたものであり、基地局間ハンドオーバーの発生が伴うユースケースにおけるシームレスなストリーミングを提供することができるようにするものである。
本開示の一側面の情報処理装置は、第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備え、前記第1の配信端末は、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う。
本開示の一側面の情報処理方法またはプログラムは、第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備える情報処理装置が、または、その情報処理装置のコンピュータに、前記第1の配信端末は、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行うことを含む。
本開示の一側面においては、第1の配信端末により、クライアント端末が移動することにより第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、第2のネットワークを介してクライアント端末に対してコンテンツをストリーミングする第2の配信端末に対し、第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼が行われる。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
<ユースケース>
図1は、本技術を適用した情報処理システムの利用が想定されるユースケースについて説明する図である。
図1は、本技術を適用した情報処理システムの利用が想定されるユースケースについて説明する図である。
図1に示す構成例では、情報処理システム11は、クラウド12およびユーザ端末13により構成されている。
クラウド12は、複数のサーバがネットワークを介して接続されて構成され、それぞれのサーバが処理を実行することにより各種のサービスを提供する。例えば、情報処理システム11においてクラウド12は、ユーザ端末13に対して動画像などのコンテンツを配信するストリーミングサービスを提供することができる。
図示するように、クラウド12は、ME-Host31-1乃至31-3、ME-Host32、およびME-Platform(Orchestrator)33がネットワークを介して接続された構成となっている。なお、ME-Host31-1乃至31-3は、それぞれ同様に構成されており、それらを区別する必要がない場合、単に、ME-Host31と称し、ME-Host31を構成する各ブロックも同様に称する。そして、ME-Host31は、Edge-DANE41およびデータベース保持部42を備えており、データベース保持部42は、記憶部43を有している。また、ME-Host32は、Origin-DANE51を備えており、Origin-DANE51は、記憶部52を有している。また、ME-Platform(Orchestrator)33は、データベース保持部61を備えている。
ユーザ端末13は、例えば、スマートフォンなどを用いることができ、クラウド12からストリーミングサービスにより配信される動画像を受信して表示することができる。例えば、ユーザ端末13には、DASH-Client21が実装された構成となっている。
そして、今後、このようなユースケースで使用されうるネットワーク網としては、5G-MEC(Multi-access Edge Computing)アーキテクチャが想定される。
具体的には、まず、ユーザ端末(UE:User Equipment)13上に実装されたDASH-Client21が、ME-Host31-1上のEdge-DANE41-1と接続される。なお、ME-Host31上にDANE(DASH Aware Network Element)を実行するということは、本開示において新たに提案されるものである。
そして、Edge-DANE41-1は、ME-Host32上のOrigin-DANE51を経由して、DASHストリーミングのルートサーバである一般のDASH-Origin-Server(図示せず)と接続される。例えば、Origin-DANE51からEdge-DANE41-1へは、一般のCDN(Content Delivery Network)のサーバ構成と同様に多段の階層を構成することもある。
例えば、DASH-Client21は、ストリームを受信するユーザ端末13上で実行されるストリーミング受信および再生アプリケーションである。また、Edge-DANE41は、DASH-Client21へのストリーミングを送信するME-Host31上で実行されるストリーミング送信アプリケーションである。
なお、Edge-DANE41およびOrigin-DANE51は、通常のWebサーバやプロキシーサーバなどの機能の他、個々のDASH-Client21側でアクセスしそうなDASHセグメントをあらかじめキャッシュする等のDASHストリーミングを最適化する機能を備える。従って、Edge-DANE41およびOrigin-DANE51は、その機能を実現するために必要な情報を、DASH-Client21とやりとりする機能(例えば、DASH-SANDメッセージのやり取りにより)を備えている。
ところで、ユーザ端末13が移動して基地局間ハンドオーバーが起こる場合、遷移前のセルとバインドされているME-Host31-1(MEC環境)で実行されていたEdge-DANE41-1も同時に、遷移後のセルとバインドされているME-Host31-2または31-3に対し遷移させることになる。これにより、ユーザ端末13が移動しても、その前後で可能な限りシームレスなストリーミングを行うことができる。このように、ME-Host31-1のEdge-DANE41-1を、ユーザ端末13の移動後のセルにバインドされたME-Host31-2のEdge-DANE41-2またはME-Host31-3のEdge-DANE41-3へ遷移させることによって、情報処理システム11は、低遅延や負荷分散などのMECコンピューティングの利点を最大限に活かすことができる。
このとき、基地局間ハンドオーバーが起こる前に、移動先のセルのネットワークトラフィックやME-Host31上のリソースの負荷状況を知った上で、事前準備をすることで、ストリーミングをシームレスにすることが期待できる。
ところで、従来の標準的なインタフェースやプロトコルなどを備えたMECアーキテクチャでは、このようなユースケースがサポートされていないため、シームレスなストリーミングは実現されていない。つまり、ベンダーやモデルの異なるモバイルネットワークキャプチャデバイスに実装できるMECアーキテクチャや、クラウド環境でこのようなサービスをサポートするMECアーキテクチャなどは存在していなかった。
そこで、以下で説明するように、本実施の形態において、上述したような事前準備などを行うことによってシームレスなストリーミングを実現するために必要なMECアーキテクチャで使用される標準プロトコル(API:Application Programming Interface)およびフロー(シーケンス)を新たに提案する。
ここで、既知の技術となっている内容について説明する。
まず、ME-Host31上において、例えば、ユーザ端末14がME-Host31-1とME-Host31-2との間をハンドオーバーする際に、アプリケーションがマイグレーションするというのは既知の技術である。これに対し、マイグレート先のアプリケーション実行に必要なリソースネゴシエーションについては、標準プロトコルとしては規定されていない。
また、ETSI(European Telecommunications Standards Institute)でも一般的なアプリケーションの実行条件(スタティックなメモリやディスク上限値など)をME-Platformに登録するための枠組みは規定されている。しかしながら、そのアプリケーションの実行に必要な要件にも基づき、ME-Platformに対して実行可否を確認するような技術は既知ではない。
なお、以下で説明するようなDANEを複製して状態同期させるプロトコルについては既知ではない。例えば、本開示では、CDNレベルの同期ではなく、異なるCDN内の個別のサーバ同士の状態同期、即ち、DASH awareな局所的な最適化が提案される。
ここで、本開示において新たに提案される内容について、さらに説明する。
まず、ユーザ端末13の近傍にあるME-Host31-1において、ユーザ端末13上のDASH-Client21と接続するEdge-DANE41-1が実行されている状態とする。そして、Edge-DANE41-1が、ユーザ端末13の基地局間ハンドオーバーが予測される遷移先基地局にバインドされたME-Host31-2上のEdge-DANE41-2またはME-Host31-3上のEdge-DANE41-3と状態同期させるプロトコルが新たに提案される。
そこで、本実施の形態では、以下で説明するように、遷移先のセルのME-Host31-2または31-3上に、Edge-DANE41-2または41-3が稼働するためのCPUや、記憶域、IO(Input/Output)スループットなどを確保するためのリソースが予約される。そして、遷移前のEdge-DANE41-1のキャッシュ状態の事前複製が行われる。即ち、予測された遷移先のセルに、遷移前のEdge-DANE41-1上の当該DASH-Client21に最適化されたキャッシュ状態が複製される。このとき、遷移が終わるまで状態同期が継続される。
また、トラフィック予測に基づくキャッシュ状態の事前変更が行われる。つまり、遷移先のセルのトラフィックの状態が異なり、遷移後のストリーム品質が変更される可能性がある場合に、変更された後の品質を見越した最適キャッシュ状態を遷移後のEdge-DANE41-2または41-3に予め構成しておく。なお、キャッシュ容量が十分に確保できない場合には、キャッシュ容量の制限の範囲内で最適化が行われる。または、遷移元のEdge-DANE41-1を維持しておき、遷移後のME-Host31-2または31-3から遷移元のEdge-DANE41-1へリクエストをリダイレクトする。
さらに、遷移先のセルが同時に2つにある場合、即ち、それらのカバレッジに階層関係があるときや、セル境界であることなどを条件とし、環境の良い方のセルのME-Host31に、上述したような最適化されたEdge-DANE41を実行する。また、遷移先のセルの予測ができない場合、隣接する複数のセルのME-Host31に、上述したような最適化されたEdge-DANE41を実行する。
<第1の実施の形態における情報処理システム>
図2乃至図27を参照して、第1の実施の形態における情報処理システム11として、遷移先のEdge-DANE41-2および41-3に対する遷移前のEdge-DANE41-1のキャッシュ状態の事前複製について説明する。なお、Edge-DANE41-1のキャッシュ状態には、現時点から予測される近い将来のリクエストに対応した近未来のキャッシュ状態を含んでもよい。
図2乃至図27を参照して、第1の実施の形態における情報処理システム11として、遷移先のEdge-DANE41-2および41-3に対する遷移前のEdge-DANE41-1のキャッシュ状態の事前複製について説明する。なお、Edge-DANE41-1のキャッシュ状態には、現時点から予測される近い将来のリクエストに対応した近未来のキャッシュ状態を含んでもよい。
例えば、第1の実施の形態における情報処理システム11では、DASH-Client21の基地局間ハンドオーバーによりME-Host31の環境が変わるとき、遷移後のME-Host31上にEdge-DANE41が稼働するためのCPUや、記憶域、IOスループット等を確保するためのリソースを予約し、遷移前のEdge-DANE41のキャッシュ状態の事前複製ができることが特徴となる。
図2には、第1の実施の形態における情報処理システム11として、5Gコアネットワークシステムファンクション群71と、MEC環境であるME-Host31におけるユーザ端末13およびアプリケーション82の間のセッションとが示されている。
例えば、情報処理システム11では、エッジコンピューティングにおけるエッジサーバにより、従来のクラウドコンピューティングのボトルネックの1つである通信遅延を大幅に改善することができる。さらに、ユーザ端末13、エッジサーバであるME-Host31、および、クラウドサーバーであるME-Host32の間で、高負荷なアプリケーションの分散処理を実行することで処理の高速化が可能となる。
なお、このエッジコンピューティングの標準仕様は”ETSI-MEC”において規定されている。そして、ETSI-MECにおけるME-Hostが、このエッジサーバであるME-Host31に相当する。
図2に示す例では、ME-Host31上のアプリケーション82と、3GPP(Third Generation Partnership Project)で標準化している5Gコアネットワーク71のアクセスネットワーク72を介したユーザ端末13(上に実装されるアプリケーション)とを接続する線が、ユーザデータセッションを表している。なお、5Gコアネットワーク71におけるアクセスネットワーク((R)AN)72は、有線アクセスネットワーク(AN:Access Network)および無線アクセスネットワーク(RAN:Radio Access Network)を包含している。
また、ME-Host31上には、ME-Platform83というエッジコンピューティングのプラットフォームがある。そして、ME-Platform83で実行されるアプリケーション82が、ユーザ端末13とのユーザデータセッションのアブストラクションであるデータプレーン81を介して、ユーザ端末13との間でストリームデータ等のユーザデータのやりとりを行う。ここで、データプレーン81は、3GPPのUPF(User Plane Function)84としての機能を備えている。なお、データプレーン81が、UPF84に相当する機能を備えていてもよい。
また、5G(第5世代移動通信システム)コアネットワーク71では、サービスベースアーキテクチャが採用されており、コアネットワークの機能である複数のNF(Network Function)が定義されている。そして、それらのNFが、サービスベースインターフェイスと呼ばれる統一的なインタフェースを介して接続されている。
図2の例では、NFとして、NRF(NF Repository Function:NFのサービスディスカバリ)、UDM(Unified Data Management:加入者情報の管理)、AUSF(Authentication Server Function:UEの認証情報の管理)、PCF(Policy Control Function:AMFとSMFを適切に動作させるためのモビリティおよびセッション管理に関するポリシーの制御)、NEF(Network Exposure Function:NFサービスのMNOネットワーク内のアプリケーションへの提供)、AMF(Access and Mobility Management Function:UEのモビリティ管理/認証/認可。SMFの制御)、および、SMF(Session Management Function:UEのセッション管理)が示されている。
図3は、図2の情報処理システム11において、ME-Host32上で実行されるOrigin-DANEアプリケーションおよびME-Host31上で実行されるEdge-DANEアプリケーションが、ME-Host31上のアプリケーションとして実装されるDistributionManagerにより起動される処理を説明する図である。
まず、Origin-DANE起動処理およびEdge-DANE起動処理が行われる。
Origin-DANE起動処理は、ME-Host31のDistributionManagerが、ME-Platform(Orchestrator)33のAPIを介して、起動の対象となるOrigin-DANEアプリケーションを実行するME-Host32のME-Platformに対して行う。同様に、Edge-DANE起動処理は、ME-Host31のDistributionManagerが、ME-Platform(Orchestrator)33のAPIを介して、ME-Host31自身のME-Platformに対して行う。
このとき、ME-Host31のDistributionManagerは、Origin-DANEアプリケーションの実行に要求されるネットワークリソースや、計算リソース、ストレージリソースなどを記述するWorkflowDescriptionに基づいて、必要なリソースを確保して対象のアプリケーションを起動する。これにより、ME-Host32のME-PlatformがOrigin-DANE51を起動し、ME-Host31のME-PlatformがEdge-DANE41を起動する。
その後、DASH-Client21は、最初に、ユーザ端末13の近傍にあるME-Host31-1上のEdge-DANE41-1を見つけ、Edge-DANE41-1を経由してOrigin-DANE51からDASHセグメントを取得する。なお、DASH-Client21は、Edge-DANE41が見つからなければ、Origin-DANE51から直接的にDASHセグメントを取得することができる。
なお、Edge-DANE41は、DASH-Client21から自身に対して送付される、近い将来取得の可能性があるDASHセグメントの集合を告げるSANDメッセージであるSAND-AnticipatedRequestメッセージを受け取ることができる。または、Edge-DANE41自身が自発的に、近い将来のリクエストを予測することができる。
そして、Edge-DANE41は、事前に、DASH-Client21から将来リクエストされる可能性のあるDASHセグメントのセグメントシーケンスを、Origin-DANE51から事前に読み込む(以下、プリフェッチと称する)ことができる。これにより、Edge-DANE41は、DASH-Client21に対するレスポンスのパフォーマンスを向上させることができる。
図4には、独自定義のWorkflow Descriptionの一例が示されている。
例えば、Workflow DescriptionにOrigin-DANEおよびEdge-DANEを記述する方式が、本開示において新たに提案されるものである。ここで、独自定義としているが、クラウド上のメディア処理のワークフローとそのアプリケーションのフレームワークについては、現時点で、MPEG-I-NBMP(Network-Based Media Processing)で仕様策定中であり、仕様は確定されていない。なお、このWorkflow Descriptionには、Origin-DANEおよびEdge-DANEが記述されているが、これらのWorkflow Description上において、それらのDANEの間には入出力の連結がない。
図4に示すように、Workfflow要素の直下の最初の要素は、url属性値’Origin-DANE-url’を持つApplication要素でありOrigin-DANEアプリケーションの実行を表す。その次に、url属性値’Edge-DANE-url’を持つApplication要素があり、Edge-DANEアプリケーションの実行を表す。
Origin-DANE51およびEdge-DANE41から提供されるストリームファイル(DASH segmentファイル)は、Origin-DANE51およびEdge-DANE41を構成するシステムを実現するWebサーバが提供するファイルアクセス方法(HTTP)を利用して、他のアプリケーションがアクセスして取得する。そして、ストリームファイルは最初、Origin-DANE51に格納されて、その後、Edge-DANE41からのリクエストに基づいて、そのEdge-DANE41にキャッシュコピーされる。
図5には、上述したようなOrigin-DANEアプリケーションやEdge-DANEアプリケーションなどのアプリケーション属性を表現するアプリケーションオブジェクトの一例が示されている。例えば、アプリケーションオブジェクトの属性定義は、ME-Platformにて管理され、その属性定義に基づいて、各々のアプリケーションの個別の属性が管理されるものとする。
アプリケーションURL(+プロバイダーURL)は、Origin/Edge-DANE等のアプリケーションの種類が識別(+オプションでプロバイダーURLも識別)される。例えば、ワークフローに記述されるApplication@urlにて指定される。
インスタンスURIは、アプリケーションの実行時にアプリケーションを識別し、アプリケーションの実行時にME-Platformにより生成される。
MECシステム-URI、バージョンは、アプリケーションが実行されるMECシステム(仮想環境)を識別する識別子である。
概要記述は、アプリケーションの処理の概要を記述する。
リソース要件には、仮想CPU使用量/秒+期間や、仮想メモリ/ストレージ容量/秒+期間、IOスループット/秒+期間等数値指定などがあり、MECシステムURL依存のリソースクラスIDにより定義される。例えば、WorkflowDescriptionに記述されるResourceDescriptionにより指定される。
アプリケーションパッケージ(URL、イメージ本体)は、MECシステム依存のアプリケーション実行イメージのurl、または、そのイメージ本体である。
トラフィック/DNSルール(フィルター/DNSレコード)は、ME-Platformを介して5Gシステムにおけるパケットのルーティングを制御する情報である。
図6は、DASH-Client21がSANDメッセージにより将来取得が予想されるセグメントを通知し、Edge-DANE41がプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
ステップS11において、DASH-Client21は、Edge-DANE41にMPD(Media Presentation Description)リクエストを送信する。そして、そのMPDリクエストを受信したEdge-DANE41を介して、Origin-DANE51がMPDリクエストを受信する。なお、MPDは、ストリーミングされるコンテンツのメタデータが記述されたファイルである。
ステップS12において、Origin-DANE51は、ステップS11で送信されてきたMPDリクエストに応じたMPDレスポンスをEdge-DANE41へ送信する。そして、そのMPDレスポンスを受信したEdge-DANE41を介して、DASH-Client21がMPDレスポンスを受信する。
ステップS13において、DASH-Client21は、ステップS12で送信されてきたMPDレスポンスに基づいて、Edge-DANE41にSegmentリクエストを送信する。そして、そのSegmentリクエストを受信したEdge-DANE41を介して、Origin-DANE51がSegmentリクエストを受信する。
ステップS14において、Origin-DANE51は、ステップS13で送信されてきたSegmentリクエストに応じたSegmentレスポンスをEdge-DANE41へ送信する。そして、そのSegmentレスポンスを介して、DASH-Client21がSegmentレスポンスを受信する。
ステップS15において、DASH-Client21は、近い将来取得の可能性があるDASHセグメントを予測し、それらのDASHセグメントの集合を告げるSAND-AnticipatedRequestメッセージをEdge-DANE41へ送信し、Edge-DANE41が受信する。
そして、ステップS16以降では、Edge-DANE41およびOrigin-DANE51の間でプリフェッチが行われる。即ち、ステップS16において、Edge-DANE41は、ステップS15で受信したSAND-AnticipatedRequestメッセージに基づいて、将来のSegmentリクエストをOrigin-DANE51へ送信する。これに応じて、ステップS17において、Origin-DANE51がSegmentレスポンスを送信する。そして、以下同様に、将来のSegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
一方、ステップS18以降では、DASH-Client21およびEdge-DANE41の間でストリーミングが行われる。即ち、ステップS18において、DASH-Client21は、SegmentリクエストをEdge-DANE41へ送信する。これに応じて、ステップS19において、Edge-DANE41は、既にプリフェッチしていたSegmentレスポンスを、DASH-Client21へ送信する。そして、以下同様に、SegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
以上のように、DASH-Client21が、Edge-DANE41に対して送付するSAND-AnticipatedRequestメッセージに基づいて、Edge-DANE41は、予め将来取得が予想されるSegmentをプリフェッチする。これにより、Edge-DANE41は、DASH-Client21に対するレスポンスのパフォーマンスを向上させることができる。
図7は、Edge-DANE41が、将来取得が予想されるセグメントを予測し自発的にプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
例えば、ステップS21乃至S24において、図6のステップS11乃至S14と同様の処理が行われる。そして、ステップS25において、Edge-DANE41は、自発的に、近い将来リクエストの可能性があるDASHセグメントを予測する自走型将来Segmentリクエスト予測を行う。
従って、ステップS26において、Edge-DANE41は、ステップS25で行った自走型将来Segmentリクエスト予測に基づいて、将来のSegmentリクエストをOrigin-DANE51へ送信する。その後、ステップS27乃至S29において、図6のステップS17乃至S19と同様の処理が行われる。
以上のように、Edge-DANE41は、例えば、DASH-Client21との間で送受信された直近の過去のsegmentリクエストおよびSegmentレスポンスの履歴に基づいて、予め将来取得が予想されるSegmentを予測し、その予測されるSegmentをプリフェッチすることができる。これにより、Edge-DANE41は、DASH-Client21に対するレスポンスのパフォーマンスを向上させることができる。
次に、図8乃至図16を参照して、DASH-Client21の基地局間ハンドオーバーによるME-Host31間のEdge-DANE41の遷移について説明する。
例えば、図8に示すように、DASH-Client21の実装されているユーザ端末13が移動する際に、ME-Host31が実装された基地局を跨った基地局間ハンドオーバーが発生する。以下では、ハンドオーバーする前のアクセスネットワーク72を、Source RAN72Sと称し、ハンドオーバーする前のME-Host31を、Source ME-Host31Sと称する。同様に、ハンドオーバーする先となるアクセスネットワーク72を、Target RAN72Tと称し、ハンドオーバーする先となるME-Host31を、Target ME-Host31Tと称する。
そして、とある基地局のSource RAN72SにバインドされたSource ME-Host31S上のEdge-DANEアプリケーションからSource RAN72Sを介してストリーミングしているDASH-Client21を実装するユーザ端末13が、別のTarget ME-Host31Tがバインドされた基地局のTarget ME-Host31T上に移動する。この移動に伴う基地局間ハンドオーバーによって、図8の二点鎖線の矢印で示すように、Source ME-Host31SのEdge-DANE41Sが、Source ME-Host31TのEdge-DANE41Tへ遷移する。
このときに行われる処理について、図13のフローを参照して説明する。なお、図13のフローでは、DASH-Client21およびEdge-DANE41Sとの間でストリーミングがすでに開始された後の処理が示されている。
即ち、Source RAN72S上のユーザ端末13に実装されたDASH-Client21は、Source ME-Host31S上のEdge-DANE41SがOrigin-DANE51からプリフェッチしたストリームファイルを元に、既にストリーミングを行っている(図13のストリーミングfrom Source ME-Host)。なお、Origin-DANE51は、Edge-DANE41Sとは別のME-Host32上で実行されている。
ここでは、図12に示すように、DASH-Client21を実装するユーザ端末13が、Source ME-Host31Sとは別のTarget ME-Host31Tがバインドされた基地局のTarget RAN72T上に移動するものとする。その際に、Source ME-Host31S上で実行されていたEdge-DANE41S(Edge-DANEアプリケーション)が、Target ME-Host31T上に遷移する。さらに、遷移先のTarget ME-Host31T上に、対応するEdge-DANEアプリケーションインスタンスが別途生成されると同時に、その状態情報がEdge-DANE41Tに複製される。
また、Source ME-Host31S上で実行されているEdge-DANE41Sは、ME-Platform83Sが提供するAPIにより、DASH-Client21が実装されたユーザ端末13の移動(位置)を検知することができる。そして、逐一の位置遷移情報や、統計情報、AI等を利用したmobility patternの解析等から、ユーザ端末13が、現在存在するSource RAN72Sから別のTarget RAN72Tに移動することが予測されたとする(図13のTarget ME-Hostへの遷移予知)。なお、その遷移先のTarget RAN72Tの基地局にはTarget ME-Host31Tが実装されているものとする。
そして、Source ME-Host31S上のEdge-DANE41Sは、ME-Platform(Orchestrator)33に依頼して、Target ME-Host31T上にEdge-DANE41Tを実行する(図13のEdge-DANE(at Target ME-Host)起動)。
これに応じて、Target ME-Host31TのME-Platform83Tは、DASH-Client21およびEdge-DANE41Sの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。
ここで、DASH-Client21との間で現在確立しているセッションを維持することや、遷移先のセルのトラフィックやME-Platform83Tの負荷状況を見越して現在確立しているセッションより品質を低下させて(または、向上させて)サービスを継続すること、品質を低下させなければならないような場合においてDASH-Client21との間で現在確立しているSource ME-Host31S上のEdge-DANE41Sとのセッションを維持することなどの方針は、図9に示すようなWorkflowDescriptionに記載する’ハンドオーバー時のセッション更新ポリシー’による指定に基づくものとする。
例えば、KeepAlreadyEstablishedIfFailed=’true’の場合には、ハンドオーバー時にセッションを現状維持することが指定されている。一方、KeepAlreadyEstablishedIfFailed=’false’の場合には、ハンドオーバー時にセッションをアップグレードすることが指定されており、こちらがデフォルトとなっている。
また、Target ME-Host31T上のEdge-DANE41Tは、必要リソースがリザーブされて起動される(図13のEdge-DANEリソース予約/生成)が、すぐにDASH-Client21に対するストリーミング処理が始まるわけではない。例えば、Source ME-Host31S上のEdge-DANE41Sが、同期した事前の読み込みを依頼する同期プリフェッチ依頼を行い、Edge-DANE41Tは、その同期プリフェッチ依頼を受け取る(図13の同期プリフェッチ依頼)。なお、同期プリフェッチ依頼で用いられる、同期プリフェッチ依頼のメッセージングプロトコルについては後述する。
これにより、Edge-DANE41Tは、Source ME-Host31S上のEdge-DANE41Sと同期しながら、Origin-DANE51からストリームファイルをプリフェッチすることができる。
さらに時間が経過して、Source ME-Host31S上のEdge-DANE41Sが、ME-Platform83Sを介して、DASH-Client21が実装されたユーザ端末13が移動して、Target ME-Host31TがバインドされたTarget RAN72Tに新たに接続されたことを検知したとする(図13のDASH-ClientのTarget ME-Hostへの遷移検知)。
これに応じて、遷移後のTarget RAN72Tからの当該ストリーミングリクエストがTarget ME-Host31T上のEdge-DANE41Tが受信できるようにトラフィック変更が行われる(図13のTarget ME-Hostへのトラフィック更新)。同時に、ターゲットME-Host31T上のEdge-DANE41Tからのレスポンスがユーザ端末13に届くようトラフィック変更が行われる。
その後、Target ME-Host31T上のEdge-DANE41Tは、Target RAN72Tを経由して、移動した後のDASH-Client21に対するストリーミングを開始する(図13のストリーミングfrom Target ME-Host)。
なお、図10に示すように、WorkflowDescriptionにおいて、Edge-DANEアプリケーションのME-Host31どうしの間の遷移そのものを認めるか否かを指定することができる。例えば、Edge-DANEアプリケーションのME-Host31どうしの間の遷移そのものを認めない場合には、Policy@DoNotMigrate=’true’が指定される。一方、ME-Host31の遷移を試みる場合には、Policy@DoNotMigrate=’false’が指定され、できる限りMECの利点を活かすことより、こちらがデフォルトとなっている。もちろん、Policy@DoNotMigrate=’true’の場合には、図9に示したKeepAlreadyEstablishedIfFailedは指定できない。
また、図11には、上述したような処理によって、DASH-Client21が移動することによって基地局間ハンドオーバーが発生するのに伴って、Edge-DANE41が遷移する遷移前および遷移後の状態が示されている。
図14には、図13の同期プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れが示されている。
例えば、図示するように、DASH-Client21では、過去のセグメント(Seg-1,Seg-2,Seg-3,・・・)がEdge-DANE41Sを介してストリーミングされ、既に再生されている。そして、DASH-Client21において、再生中となる現在のセグメント(Seg-0)がストリーミングされているタイミングで、同期プリフェッチ依頼が行われたとする。
このとき、同期プリフェッチ依頼をトリガーとして、現在のセグメントSeg-0より将来に必要となる同一AdaptationSetのセグメント(Seg+1,Seg+2,Seg+3,・・・)のプリフェッチが開始される。即ち、図示するように、将来のセグメント(Seg+1,Seg+2,Seg+3,・・・)が、Origin-DANE51からEdge-DANE41Sへ送信されるのと同期して、Edge-DANE41Tへの送信が開始される。
なお、このプリフェッチは、現在のSource ME-Host31S経由のセッションリソースと同程度のセッションリソースが、Target ME-Host31T経由の環境においても担保されることが確認されているときに開始される。また、Source ME-Host31SとTarget ME-Host31Tとの間は、NTP(Network Time Protocol)などによってシステムクロック同期が実施され、同一のWallclockを共有にしているものとする。
図15は、DASH-Client21がSANDメッセージにより将来取得が予想されるセグメントを通知し、Edge-DANE41SおよびEdge-DANE41Tがプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
ステップS31において、DASH-Client21は、Edge-DANE41SにSegmentリクエストを送信する。そして、そのSegmentリクエストを受信したEdge-DANE41Sを介して、Origin-DANE51がSegmentリクエストを受信する。
ステップS32において、Origin-DANE51は、ステップS31で送信されてきたSegmentリクエストに応じたSegmentレスポンスをEdge-DANE41Sへ送信する。そして、そのSegmentレスポンスを受信したEdge-DANE41Sを介して、DASH-Client21がSegmentレスポンスを受信する。
ステップS33において、DASH-Client21は、近い将来取得の可能性があるDASHセグメントを予測し、それらのDASHセグメントの集合を告げるSAND-AnticipatedRequestメッセージをEdge-DANE41Sへ送信し、Edge-DANE41Sが受信する。
ステップS34において、Edge-DANE41Sは、Edge-DANE41Tに対して、MPDおよびSAND-AnticipatedRequestメッセージを送付し、同期プリフェッチ依頼を行う。
そして、ステップS35以降におけるEdge-DANE41TおよびOrigin-DANE51の間のプリフェッチと、ステップS36以降におけるEdge-DANE41SおよびOrigin-DANE51の間のプリフェッチが同期して行われる。即ち、ステップS35において、Edge-DANE41Tが、将来のSegmentリクエストをOrigin-DANE51へ送信するとともに、ステップS36において、Edge-DANE41Sが、将来のSegmentリクエストをOrigin-DANE51へ送信する。これに応じて、ステップS37において、Origin-DANE51がSegmentレスポンスを送信する。そして、以下同様に、将来のSegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
一方、ステップS38以降では、DASH-Client21およびEdge-DANE41Sの間でストリーミングが行われる。即ち、ステップS38において、DASH-Client21は、SegmentリクエストをEdge-DANE41Sへ送信する。これに応じて、ステップS39において、Edge-DANE41Sは、既にプリフェッチしていたSegmentレスポンスを、DASH-Client21へ送信する。そして、以下同様に、SegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
以上のように、Edge-DANE41SおよびEdge-DANE41Tは、プリフェッチを同期して行うことができる。これにより、その後、DASH-Client21の移動に伴って、Edge-DANE41Tからのストリーミングに遷移する際に、Edge-DANE41Tは、DASH-Client21に対するレスポンスのパフォーマンスを向上させることができる。
図16は、Edge-DANE41SおよびEdge-DANE41Tが、将来取得が予想されるセグメントを予測し自発的にプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
例えば、ステップS41およびS42において、図15のステップS31およびS32と同様の処理が行われる。そして、ステップS43において、Edge-DANE41Sは、Edge-DANE41Tに対してMPDを送付し、Edge-DANE41Tとの間のプリフェッチを同期させる同期プリフェッチ依頼(自走型)を行う。
これに応じて、ステップS44において、Edge-DANE41Tは、MPDを参照し、自発的に、近い将来リクエストの可能性があるDASHセグメントを予測する自走型将来Segmentリクエスト予測を行う。同様に、ステップS45において、Edge-DANE41Sは、MPDを参照し、自発的に、近い将来リクエストの可能性があるDASHセグメントを予測する自走型将来Segmentリクエスト予測を行う。その後、ステップS46乃至S50において、図15のステップS35乃至S39と同様の処理が行われる。
以上のように、Edge-DANE41SおよびEdge-DANE41Tそれぞれは、予め将来取得が予想されるSegmentを予測し、その予測されるSegmentのプリフェッチを同期して行うことができる。これにより、その後、DASH-Client21の移動に伴って、Edge-DANE41Tからのストリーミングに遷移する際に、Edge-DANE41Tは、DASH-Client21に対するレスポンスのパフォーマンスを向上させることができる。
次に、図17乃至図19を参照して、遷移先となるME-Host31上に、リソース不足によってEdge-DANE41の起動ができなかったケースにおける処理について説明する。
図17には、Source RAN72SからTarget RAN72TへDASH-Client21が移動すること(図18参照)によって基地局間ハンドオーバーが発生するのに伴う遷移前および遷移後の状態が示されている。
即ち、とある基地局のSource RAN72SにバインドされたSource ME-Host31S上のEdge-DANEアプリケーションからSource RAN72Sを介してストリーミングしているDASH-Client21を実装するユーザ端末13が、別のTarget ME-Host31Tがバインドされた基地局のTarget ME-Host31T上に移動する。この移動に伴う基地局間ハンドオーバーによって、Source ME-Host31SのEdge-DANE41Sを遷移させようとするが、リソース不足によって、Source ME-Host31TのEdge-DANE41Tが起動できないことがある。
この場合、Source ME-Host31SのEdge-DANE41Sを維持したまま、Edge-DANE41SがOrigin-DANE51から受信したセグメントを、データプレーン81Sからデータプレーン81Tへ送信して、Target RAN72Tを介してDASH-Client21へ送信することができる。
このときに行われる処理について、図19のフローを参照して説明する。なお、図19のフローでは、DASH-Client21およびEdge-DANE41Sとの間でストリーミングがすでに開始された後の処理が示されている。
まず、図13のフローを参照して上述したように、Edge-DANE41Sは、ユーザ端末13が、現在存在するSource RAN72Sから別のTarget RAN72Tに移動することを予測する(図19のTarget ME-Hostへの遷移予知)。
そして、Source ME-Host31S上のEdge-DANE41Sは、ME-Platform(Orchestrator)33に依頼して、Target ME-Host31T上にEdge-DANE41Tを実行する(図19のEdge-DANE(at Target ME-Host)起動)。
これに応じて、Target ME-Host31TのME-Platform83Tは、DASH-Client21およびEdge-DANE41Sの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。しかしながら、このケースでは、Edge-DANE41Tの起動に失敗する。
さらに時間が経過して、Source ME-Host31S上のEdge-DANE41Sが、ME-Platform83Sを介して、DASH-Client21が実装されたユーザ端末13が移動して、Target ME-Host31TがバインドされたTarget RAN72Tに新たに接続されたことを検知したとする(図19のDASH-ClientのTarget ME-Hostへの遷移検知)。
この場合、Edge-DANE41Sは、遷移後のTarget RAN72Tからの当該ストリーミングリクエストがSource ME-Host31S上のEdge-DANE41Sが受信できるようにトラフィック維持が行われる(図19のSource ME-Hostへのトラフィック維持)。同時に、Target ME-Host31T上のME-Platform83Tに対して、Source ME-Host31Sへのトラフィック変更が行われる。
これにより、Target ME-Host31T上でEdge-DANE41Tの起動に失敗した場合でも、Source ME-Host31S上のEdge-DANE41Sを維持したまま、Target RAN72Tを介して、DASH-Client21へのストリーミングを実現することができる。
図20乃至図23を参照して、遷移先のセル(RAN72)の予測ができない場合、遷移が予想される2つのセル(TargetRAN72T-AおよびTargetRAN72T-B)にバインドされたTarget ME-Host31T-AおよびTarget ME-Host31T-Bに、それぞれEdge-DANE41Tを実行しておく処理について説明する。ここでは、最終的に、DASH-Client21がTarget ME-Host31T-AにバインドされるTargetRAN72T-Aに遷移するケースを示している。
例えば、図20には、Source RAN72SからTargetRAN72T-AへDASH-Client21が移動すること(図21参照)によって基地局間ハンドオーバーが発生するのに伴う状態が示されている。
即ち、DASH-Client21が、TargetRAN72T-AおよびTargetRAN72T-Bのどちらに遷移するか予測できない場合、Target ME-Host31T-AにEdge-DANE41T-Aを起動させておくとともに、Target ME-Host31T-BにEdge-DANE41T-Bを起動させておく。そして、DASH-Client21がTargetRAN72T-Aへの遷移が検知されると、Edge-DANE41T-AからTargetRAN72T-Aを介して、DASH-Client21へのストリーミングが行われる。
このときに行われる処理について、図22のフローを参照して説明する。なお、図22のフローでは、DASH-Client21およびEdge-DANE41Sとの間でストリーミングがすでに開始された後の処理が示されている。
まず、図13のフローを参照して上述したように、Edge-DANE41Sは、ユーザ端末13が、現在存在するSource RAN72Sから別のTarget RAN72T-AまたはTarget RAN72T-Bに移動することを予測する(図22のTarget ME-Host AorBへの遷移予知)。即ち、この場合、Target RAN72T-AおよびTarget RAN72T-Bのどちらに移動するかは予測できていない。
そして、Source ME-Host31S上のEdge-DANE41Sは、ME-Platform(Orchestrator)33に依頼して、Target ME-Host31T-A上にEdge-DANE41T-Aを実行するとともに、Target ME-Host31T-B上にEdge-DANE41T-Bを実行する(図22のEdge-DANE(at Target ME-Host A&B)起動)。
これに応じて、Target ME-Host31TのME-Platform83Tは、DASH-Client21およびEdge-DANE41Sの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。これにより、Target ME-Host31T-A上のEdge-DANE41T-Aは、必要リソースがリザーブされて起動される(図22のEdge-DANEリソース予約/生成)。同様に、Target ME-Host31T-B上のEdge-DANE41T-Bは、必要リソースがリザーブされて起動される(図22のEdge-DANEリソース予約/生成)。
その後、Target ME-Host31TのME-Platform83Tは、Target ME-Host31T-A上のEdge-DANE41T-Aに対して同期プリフェッチ依頼を行うとともに、Target ME-Host31T-B上のEdge-DANE41T-Bに対して同期プリフェッチ依頼を行う。これにより、Edge-DANE41T-AおよびEdge-DANE41T-Bは、Source ME-Host31S上のEdge-DANE41Sと同期しながらOrigin-DANE51からストリームファイルをプリフェッチすることができる。
さらに時間が経過して、Source ME-Host31S上のEdge-DANE41Sが、ME-Platform83Sを介して、DASH-Client21が実装されたユーザ端末13が移動して、Target ME-Host31T-AがバインドされたTarget RAN72T-Aに新たに接続されたことを検知したとする(図22のDASH-ClientのTarget ME-Host Aへの遷移検知)。
これに応じて、遷移後のTarget RAN72T-Aからの当該ストリーミングリクエストがTarget ME-Host31T-A上のEdge-DANE41T-Aが受信できるようにトラフィック変更が行われる(図22のTarget ME-Host Aへのトラフィック更新)。同時に、ターゲットME-Host31T-A上のEdge-DANE41T-Aからのレスポンスがユーザ端末13に届くようトラフィック変更が行われる。
その後、Target ME-Host31T-A上のEdge-DANE41T-Aは、Target RAN72T-Aを経由して、移動した後のDASH-Client21に対するストリーミングを開始する(図22のストリーミングfrom Target ME-Host A)。その際、Target ME-Host31T-A上のEdge-DANE41T-Aのプリフェッチは継続される一方で、Target ME-Host31T-B上のEdge-DANE41T-Bのプリフェッチは終了される。
図23には、図22の同期プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れが示されている。
例えば、図示するように、DASH-Client21では、過去のセグメント(Seg-1,Seg-2,Seg-3,・・・)がEdge-DANE41Sを介してストリーミングされ、既に再生されている。そして、DASH-Client21において、再生中となる現在のセグメント(Seg-0)がストリーミングされているタイミングで、同期プリフェッチ依頼が行われたとする。
このとき、同期プリフェッチ依頼をトリガーとして、現在のセグメントSeg-0より将来に必要となる同一AdaptationSetのセグメント(Seg+1,Seg+2,Seg+3,・・・)のプリフェッチが開始される。即ち、図示するように、将来のセグメント(Seg+1,Seg+2,Seg+3,・・・)が、Origin-DANE51からEdge-DANE41Sへ送信されるのと同期して、Edge-DANE41T-AおよびEdge-DANE41T-Bの両方への送信が開始される。
なお、このプリフェッチは、現在のSource ME-Host31S経由のセッションリソースと同程度のセッションリソースが、Target ME-Host31T-AおよびTarget ME-Host31T-B経由の環境においても担保されることが確認されているときに開始される。また、Source ME-Host31SとTarget ME-Host31T-AおよびTarget ME-Host31T-Bとの間は、NTP(Network Time Protocol)などによってシステムクロック同期が実施され、同一のWallclockを共有にしているものとする。
図24乃至図27を参照して、耐障害性冗長度を確保する処理について説明する。ここでは、カバレッジが重複する2つのセル(TargetRAN72T-AおよびTargetRAN72T-B)にバインドされた、Target ME-Host31T-AおよびTarget ME-Host31T-Bに、それぞれEdge-DANE41Tを実行し、2つのストリーミングセッションを同期して実行する例が示されている。なお、遷移後のDASH-Client21が、TargetRAN72T-AおよびTargetRAN72T-Bの両方に、同時に接続されるものとしている。
例えば、図24には、Source RAN72SからTargetRAN72T-AおよびTargetRAN72T-BへDASH-Client21が移動すること(図25参照)によって基地局間ハンドオーバーが発生するのに伴う状態が示されている。
即ち、TargetRAN72T-AおよびTargetRAN72T-Bのカバレッジが重複する場合、Target ME-Host31T-AにEdge-DANE41T-Aを起動させておくとともに、Target ME-Host31T-BにEdge-DANE41T-Bを起動させておく。そして、DASH-Client21がTargetRAN72T-AおよびTargetRAN72T-Bへの遷移が検知されると、Edge-DANE41T-AからTargetRAN72T-Aを介して、Edge-DANE41T-BからTargetRAN72T-Bを介して、DASH-Client21へのストリーミングが行われる。
このときに行われる処理について、図26のフローを参照して説明する。なお、図26のフローでは、DASH-Client21およびEdge-DANE41Sとの間でストリーミングがすでに開始された後の処理が示されている。
まず、図13のフローを参照して上述したように、Edge-DANE41Sは、ユーザ端末13が、現在存在するSource RAN72Sから別のTarget RAN72T-AまたはTarget RAN72T-Bに移動することを予測する(図26のTarget ME-Host AorBへの遷移予知)。
そして、Source ME-Host31S上のEdge-DANE41Sは、ME-Platform(Orchestrator)33に依頼して、Target ME-Host31T-A上にEdge-DANE41T-Aを実行するとともに、Target ME-Host31T-B上にEdge-DANE41T-Bを実行する(図26のEdge-DANE(at Target ME-Host A&B)起動)。
これに応じて、Target ME-Host31TのME-Platform83Tは、DASH-Client21およびEdge-DANE41Sの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。これにより、Target ME-Host31T-A上のEdge-DANE41T-Aは、必要リソースがリザーブされて起動される(図26のEdge-DANEリソース予約/生成)。同様に、Target ME-Host31T-B上のEdge-DANE41T-Bは、必要リソースがリザーブされて起動される(図26のEdge-DANEリソース予約/生成)。
その後、Target ME-Host31TのME-Platform83Tは、Target ME-Host31T-A上のEdge-DANE41T-Aに対して同期プリフェッチ依頼を行うとともに、Target ME-Host31T-B上のEdge-DANE41T-Bに対して同期プリフェッチ依頼を行う。これにより、Edge-DANE41T-AおよびEdge-DANE41T-Bは、Source ME-Host31S上のEdge-DANE41Sと同期しながらOrigin-DANE51からストリームファイルをプリフェッチすることができる。
さらに時間が経過して、Source ME-Host31S上のEdge-DANE41Sが、ME-Platform83Sを介して、DASH-Client21が実装されたユーザ端末13が移動して、Target ME-Host31T-AがバインドされたTarget RAN72T-A、および、Target ME-Host31T-BがバインドされたTarget RAN72T-Bに新たに接続されたことを検知したとする(図26のDASH-ClientのTarget ME-Host A&Bへの遷移検知)。
これに応じて、遷移後のTarget RAN72T-Aからの当該ストリーミングリクエストがTarget ME-Host31T-A上のEdge-DANE41T-Aが受信できるようにトラフィック変更が行われる(図26のTarget ME-Host Aへのトラフィック更新)。同時に、ターゲットME-Host31T-A上のEdge-DANE41T-Aからのレスポンスがユーザ端末13に届くようトラフィック変更が行われる。
同様に、遷移後のTarget RAN72T-Bからの当該ストリーミングリクエストがTarget ME-Host31T-B上のEdge-DANE41T-Bが受信できるようにトラフィック変更が行われる(図26のTarget ME-Host Bへのトラフィック更新)。同時に、ターゲットME-Host31T-B上のEdge-DANE41T-Bからのレスポンスがユーザ端末13に届くようトラフィック変更が行われる。
その後、Target ME-Host31T-A上のEdge-DANE41T-Aは、Target RAN72T-Aを経由して、移動した後のDASH-Client21に対するストリーミングを開始する(図26のストリーミングfrom Target ME-Host A)。また、Target ME-Host31T-A上のEdge-DANE41T-Aのプリフェッチは継続される。
同様に、Target ME-Host31T-B上のEdge-DANE41T-Bは、Target RAN72T-Bを経由して、移動した後のDASH-Client21に対するストリーミングを開始する(図26のストリーミングfrom Target ME-Host B)。また、Target ME-Host31T-B上のEdge-DANE41T-Bのプリフェッチは継続される。
例えば、図27に示すように、この冗長構成は、Workflow Descriptionにおいて、対象アプリケーションのApplication要素のduplicate属性を’true’に設定することにより指示することができるものとする。
<第2の実施の形態における情報処理システム>
図28乃至図32を参照して、第2の実施の形態における情報処理システム11において、トラフィック予測に基づくEdge-DANE41のキャッシュ状態の事前変更について説明する。例えば、第2の実施の形態における情報処理システム11では、DASH-Client21の基地局間ハンドオーバーによりME-Host31の環境が変わるとき、遷移前のEdge-DANE41のキャッシュ状態の事前複製をする際に、トラフィック予測に基づくキャッシュ状態の事前変更ができることが特徴となる。
図28乃至図32を参照して、第2の実施の形態における情報処理システム11において、トラフィック予測に基づくEdge-DANE41のキャッシュ状態の事前変更について説明する。例えば、第2の実施の形態における情報処理システム11では、DASH-Client21の基地局間ハンドオーバーによりME-Host31の環境が変わるとき、遷移前のEdge-DANE41のキャッシュ状態の事前複製をする際に、トラフィック予測に基づくキャッシュ状態の事前変更ができることが特徴となる。
例えば、図28には、Source RAN72SからTargetRAN72TへDASH-Client21が移動すること(図29参照)によって基地局間ハンドオーバーが発生するのに伴う遷移前および遷移後の状態が示されている。
例えば、遷移予定のTargetRAN72TにバインドされたME-Host31T上に実行されるEdge-DANE41Tにおいて、遷移前のセッションと同等なセッションリソースが確保できない可能性をあらかじめ検知したとする。この場合、遷移後のストリーム品質の変更を見越した最適キャッシュ状態を遷移後のEdge-DANE41Tにあらかじめ構成しておく。そして、キャッシュ容量が十分とれない場合には、制限の範囲内で最適化する。
ここで、図20を参照して上述したような遷移先のセル(RAN72)の予測ができない場合の処理や、図24を参照して上述したような耐障害性冗長度確保する処理などおける同期プリフェッチ依頼を、以下で説明する同期適合型プリフェッチ依頼に置き換えることができる。
このときに行われる処理が、図30のフローに示されている。なお、図30に示すフローは、図13のフローにおける同期プリフェッチ依頼が、同期適応型プリフェッチ依頼に置き換えられ、その後、適応型プリフェッチが行われる点以外は、図13のフローと同様の処理が行われ、その詳細な説明は省略する。
ここで、同期適応型プリフェッチ依頼について説明する。
例えば、上述したように、遷移前のDASH-Client21にストリーミングしているSource ME-Host31S上のEdge-DANE41Sが、このDASH-Client21がTarget ME-Host31TにバインドされたTarget RAN72Tに遷移する可能性を検知する。これに応じて、Target ME-Host31T上にEdge-DANE41Tを起動した後に、そのEdge-DANE41Tに対する同期適応型プリフェッチ依頼が行われる。
そして、適応型プリフェッチは、Edge-DANE41Tが、将来取得が予想されるセグメントを予測し自発的にプリフェッチするものである。また、適応型プリフェッチでは、現在のTarget RAN72Tにおけるトラフィック状態や、Target ME-Host31Tの計算やストレージなどのリソース状態を鑑みて、このDASH-Client21が将来、Target RAN72Tに遷移した場合に想定される妥当なストリーミングセッションについての制約を見越して、あらかじめ将来取得が予測されるセグメントをプリフェッチするものとする。
また、Target RAN72Tの現在のトラフィックや、計算、ストレージなどのリソース状態、または、DASH-Client21が遷移後の将来で予測されるトラフィックや、計算、ストレージなどのリソース状態によっては、Source ME-Host31Sで現在確立されているセッションリソースが担保されない可能性がある。このため、現在よりも貧弱な環境である場合には、現在再生途上のAdaptationSetのRepresentationのうち、よりリソース消費の少ない(例えば、よりビットレートの低い)Representationについて、将来取得が予想されるセグメントをプリフェッチする。なお、とあるAdaptationSetの中のRepresentation群から選択する場合もあれば、AdaptationSetそのものを変える場合もあり得る。このように、例えば、遷移先のトラフィック予測に基づいて、ストリーム品質が異なる(高ビットレートまたは低ビットレート)のセグメントを。適応的に選択することが可能である。
図31には、このような同期適応型プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れが示されている。
例えば、図示するように、現在再生途上のAdaptationSetのRepresentationのSegmentシーケンスと、よりビットレートの低い(将来のリソース状態に最適な属性を有す)AdaptationSetのRepresentationとのSegmentシーケンスの両方が用意されている。
そして、同期適応型プリフェッチ依頼をトリガーとして、現在のセグメントSeg-0より将来に必要となる同一AdaptationSetの異なるRepresentationのセグメントのプリフェッチが開始される。即ち、図示するように、現在のAdaptationSetのRepresentationの将来のセグメント(SegH+1,SegH+2,SegH+3,・・・)が、Origin-DANE51からEdge-DANE41Sへ送信されるのと同期して、よりビットレートの低いAdaptationSetのRepresentationの将来のセグメント(SegL+1,SegL+2,SegL+3,・・・)が、Edge-DANE41Tへの送信が開始される。
なお、この適応型プリフェッチは、現在のSource ME-Host31S経由のセッションリソースとは異なるセッションリソースが、Target ME-Host31T経由の環境において担保されることが確認されているときに開始される。また、Source ME-Host31SとTarget ME-Host31Tとの間は、NTP(Network Time Protocol)などによってシステムクロック同期が実施され、同一のWallclockを共有にしているものとする。
図32は、Edge-DANE41SおよびEdge-DANE41Tが、将来取得が予想されるセグメントを予測し自発的に適応型プリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
例えば、ステップS51およびS52において、図16のステップS41およびS42と同様の処理が行われる。そして、ステップS53において、Edge-DANE41Sは、Edge-DANE41Tに対してMPDを送付し、Edge-DANE41Tとの間の適応型プリフェッチを同期させる同期適応型プリフェッチ依頼(自走型)を行う。
その後、ステップS54およびS55において、図16のステップS44およびS45と同様の処理が行われる。
そして、ステップS56以降におけるEdge-DANE41TおよびOrigin-DANE51の間の適応型プリフェッチと、ステップS57以降におけるEdge-DANE41SおよびOrigin-DANE51の間のプリフェッチとが同期して行われる。
以上のように、Edge-DANE41Tが適応型プリフェッチを行うことで、例えば、トラフィック予測に基づくキャッシュ状態を事前変更することができ、遷移後のトラフィックに応じたビットレートでストリーミングを行うことができる。
以下では、同期プリフェッチ依頼および同期適応型プリフェッチ依頼のメッセージングプロトコルについて説明する。
例えば、遷移前のSource ME-Host31S上のEdge-DANE41Sから、遷移予定のTarget ME-Host31T上のEdge-DANE41Tへの同期プリフェッチ依頼および同期適応型プリフェッチ依頼のメッセージングプロトコルはDASH-SANDを拡張して定義することができる。
そして、Edge-DANE41間のSAND-PEDメッセージとして、PrefetchTriggerRequestメッセージを導入する。例えば、PrefetchTriggerRequest要素は、プリフェッチの適応型か否かを示すadaptivePrefetch属性、Source ME-Host31S上のEdge-DANE41SからのSANDメッセージを格納するrelayedSANDMessageFromDASHClient属性、および、対象のストリームのセグメントを特定するtheStream要素を持つ。
図33には、PrefetchTriggerRequestの構造の一例が示されている。
例えば、adaptivePrefetch属性は、値falseで通常のプリフェッチを実行し、値trueで適応型プリフェッチを実行することを示す。
また、relayedSANDMessageFromDASHClient属性は、例えば、上述した図15のステップS33において、DASH-Client21がEdge-DANE41Sに対して発行する、近い将来取得可能性のあるsegmentの集合を告げるSANDメッセージであるSAND-AnticipatedRequestメッセージも格納できるようにする。
また、theStream要素は、制御対象のストリームの属性を含むMPDへの参照(MPDのurl)、または、MPD本体を格納するmpd属性を持ち、このMPDに記載される特定のsegmentを指示するXPathストリングを格納するsegmentPath属性を持つ。
ここで、PrefetchTriggerRequestメッセージは、例えば、図34に示すようなHTTP-POSTを用いて、Source ME-Host31S上のEdge-DANE41SかTarget ME-Host31T上のEdge-DANE41Tに転送される。
また、図34には、http://a.com/a.mpdというurlで指定されるmpdの最初のperiod要素の最初のAdaptationSet要素のSegmentTemplate要素で指定されるsegmentの一例が示されている。
<コンピュータの構成例>
次に、上述した一連の処理(情報処理方法)は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
次に、上述した一連の処理(情報処理方法)は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
図35は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク105やROM103に予め記録しておくことができる。
あるいはまた、プログラムは、ドライブ109によって駆動されるリムーバブル記録媒体111に格納(記録)しておくことができる。このようなリムーバブル記録媒体111は、いわゆるパッケージソフトウェアとして提供することができる。ここで、リムーバブル記録媒体111としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory),MO(Magneto Optical)ディスク,DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。
なお、プログラムは、上述したようなリムーバブル記録媒体111からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク105にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。
コンピュータは、CPU(Central Processing Unit)102を内蔵しており、CPU102には、バス101を介して、入出力インタフェース110が接続されている。
CPU102は、入出力インタフェース110を介して、ユーザによって、入力部107が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)103に格納されているプログラムを実行する。あるいは、CPU102は、ハードディスク105に格納されたプログラムを、RAM(Random Access Memory)104にロードして実行する。
これにより、CPU102は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU102は、その処理結果を、必要に応じて、例えば、入出力インタフェース110を介して、出力部106から出力、あるいは、通信部108から送信、さらには、ハードディスク105に記録等させる。
なお、入力部107は、キーボードや、マウス、マイク等で構成される。また、出力部106は、LCD(Liquid Crystal Display)やスピーカ等で構成される。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理(例えば、並列処理あるいはオブジェクトによる処理)も含む。
また、プログラムは、1のコンピュータ(プロセッサ)により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
さらに、本明細書において、システムとは、複数の構成要素(装置、モジュール(部品)等)の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、1つの筐体の中に複数のモジュールが収納されている1つの装置は、いずれも、システムである。
また、例えば、1つの装置(または処理部)として説明した構成を分割し、複数の装置(または処理部)として構成するようにしてもよい。逆に、以上において複数の装置(または処理部)として説明した構成をまとめて1つの装置(または処理部)として構成されるようにしてもよい。また、各装置(または各処理部)の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置(または処理部)の構成の一部を他の装置(または他の処理部)の構成に含めるようにしてもよい。
また、例えば、本技術は、1つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能(機能ブロック等)を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、1つの装置で実行する他、複数の装置で分担して実行することができる。さらに、1つのステップに複数の処理が含まれる場合には、その1つのステップに含まれる複数の処理は、1つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、1つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を1つのステップとしてまとめて実行することもできる。
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
<構成の組み合わせ例>
なお、本技術は以下のような構成も取ることができる。
(1)
第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備え、
前記第1の配信端末は、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
情報処理装置。
(2)
前記第1の配信端末は、前記クライアント端末が、近い将来取得の可能性があるセグメントを予測し、予測したセグメントのリクエストを受信して、前記第2の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD(Media Presentation Description)と、前記リクエストとを送信して、前記同期プリフェッチ依頼を行い、
前記第1の配信端末および前記第2の配信端末において、前記MPDおよび前記リクエストを参照して、前記クライアント端末において予測されたセグメントが事前に取得される
上記(1)に記載の情報処理装置。
(3)
前記第1の配信端末は、前記第2の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD(Media Presentation Description)を送信して、前記同期プリフェッチ依頼を行い、
前記第1の配信端末および前記第2の配信端末において、前記MPDが参照されて、前記クライアント端末が、近い将来取得の可能性があるセグメントが予測され、その予測されるセグメントが事前に取得される
上記(1)に記載の情報処理装置。
(4)
前記第1の配信端末は、前記クライアント端末が前記第2のネットワークへ遷移することを予知した場合、前記第2のネットワークにバインドされたホスト装置に対し、前記第2の配信端末の起動を行わせる
上記(1)から(3)までのいずれかに記載の情報処理装置。
(5)
前記第2のネットワークにバインドされた前記ホスト装置において前記第2の配信端末の起動が失敗した場合、前記第1の配信端末を維持したまま、前記第2のネットワークを介して前記クライアント端末に対する前記コンテンツのストリーミングが行われる
上記(4)に記載の情報処理装置。
(6)
前記クライアント端末の遷移先となる前記第2のネットワークが予測できない場合、複数の前記ホスト装置に対して前記第2の配信端末の起動を行わせる
上記(4)に記載の情報処理装置。
(7)
前記クライアント端末の遷移先において、複数の前記第2のネットワークが重複する場合、それぞれの前記第2のネットワークにバインドされた前記ホスト装置に対し、前記第2の配信端末の起動を行わせる
上記(4)に記載の情報処理装置。
(8)
前記第1の配信端末は、前記第2の配信端末に対して前記同期プリフェッチ依頼を行う際に、前記第2のネットワークのトラフィック予想に基づいて適応的にストリーム品質の異なるセグメントを選択させる
上記(1)から(7)までのいずれかに記載の情報処理装置。
(9)
第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備える情報処理装置が、
前記第1の配信端末によって、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
を含む情報処理方法。
(10)
第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備える情報処理装置のコンピュータに、
前記第1の配信端末によって、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
を含む情報処理を実行させるためのプログラム。
なお、本技術は以下のような構成も取ることができる。
(1)
第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備え、
前記第1の配信端末は、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
情報処理装置。
(2)
前記第1の配信端末は、前記クライアント端末が、近い将来取得の可能性があるセグメントを予測し、予測したセグメントのリクエストを受信して、前記第2の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD(Media Presentation Description)と、前記リクエストとを送信して、前記同期プリフェッチ依頼を行い、
前記第1の配信端末および前記第2の配信端末において、前記MPDおよび前記リクエストを参照して、前記クライアント端末において予測されたセグメントが事前に取得される
上記(1)に記載の情報処理装置。
(3)
前記第1の配信端末は、前記第2の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD(Media Presentation Description)を送信して、前記同期プリフェッチ依頼を行い、
前記第1の配信端末および前記第2の配信端末において、前記MPDが参照されて、前記クライアント端末が、近い将来取得の可能性があるセグメントが予測され、その予測されるセグメントが事前に取得される
上記(1)に記載の情報処理装置。
(4)
前記第1の配信端末は、前記クライアント端末が前記第2のネットワークへ遷移することを予知した場合、前記第2のネットワークにバインドされたホスト装置に対し、前記第2の配信端末の起動を行わせる
上記(1)から(3)までのいずれかに記載の情報処理装置。
(5)
前記第2のネットワークにバインドされた前記ホスト装置において前記第2の配信端末の起動が失敗した場合、前記第1の配信端末を維持したまま、前記第2のネットワークを介して前記クライアント端末に対する前記コンテンツのストリーミングが行われる
上記(4)に記載の情報処理装置。
(6)
前記クライアント端末の遷移先となる前記第2のネットワークが予測できない場合、複数の前記ホスト装置に対して前記第2の配信端末の起動を行わせる
上記(4)に記載の情報処理装置。
(7)
前記クライアント端末の遷移先において、複数の前記第2のネットワークが重複する場合、それぞれの前記第2のネットワークにバインドされた前記ホスト装置に対し、前記第2の配信端末の起動を行わせる
上記(4)に記載の情報処理装置。
(8)
前記第1の配信端末は、前記第2の配信端末に対して前記同期プリフェッチ依頼を行う際に、前記第2のネットワークのトラフィック予想に基づいて適応的にストリーム品質の異なるセグメントを選択させる
上記(1)から(7)までのいずれかに記載の情報処理装置。
(9)
第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備える情報処理装置が、
前記第1の配信端末によって、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
を含む情報処理方法。
(10)
第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備える情報処理装置のコンピュータに、
前記第1の配信端末によって、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
を含む情報処理を実行させるためのプログラム。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
11 情報処理システム, 12 クラウド, 13 ユーザ端末, 21 DASH-Client, 31および32 ME-Host, 33 ME-Platform(Orchestrator), 41 Edge-DANE, 42 データベース保持部, 43 記憶部, 51 Origin-DANE, 52 記憶部, 61 データベース保持部, 71 5Gコアネットワークシステム, 72 アクセスネットワーク, 81 データプレーン, 82 アプリケーション, 83 ME-Platform, 84 UPF
Claims (10)
- 第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備え、
前記第1の配信端末は、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
情報処理装置。 - 前記第1の配信端末は、前記クライアント端末が、近い将来取得の可能性があるセグメントを予測し、予測したセグメントのリクエストを受信して、前記第2の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD(Media Presentation Description)と、前記リクエストとを送信して、前記同期プリフェッチ依頼を行い、
前記第1の配信端末および前記第2の配信端末において、前記MPDおよび前記リクエストを参照して、前記クライアント端末において予測されたセグメントが事前に取得される
請求項1に記載の情報処理装置。 - 前記第1の配信端末は、前記第2の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD(Media Presentation Description)を送信して、前記同期プリフェッチ依頼を行い、
前記第1の配信端末および前記第2の配信端末において、前記MPDが参照されて、前記クライアント端末が、近い将来取得の可能性があるセグメントが予測され、その予測されるセグメントが事前に取得される
請求項1に記載の情報処理装置。 - 前記第1の配信端末は、前記クライアント端末が前記第2のネットワークへ遷移することを予知した場合、前記第2のネットワークにバインドされたホスト装置に対し、前記第2の配信端末の起動を行わせる
請求項1に記載の情報処理装置。 - 前記第2のネットワークにバインドされた前記ホスト装置において前記第2の配信端末の起動が失敗した場合、前記第1の配信端末を維持したまま、前記第2のネットワークを介して前記クライアント端末に対する前記コンテンツのストリーミングが行われる
請求項4に記載の情報処理装置。 - 前記クライアント端末の遷移先となる前記第2のネットワークが予測できない場合、複数の前記ホスト装置に対して前記第2の配信端末の起動を行わせる
請求項4に記載の情報処理装置。 - 前記クライアント端末の遷移先において、複数の前記第2のネットワークが重複する場合、それぞれの前記第2のネットワークにバインドされた前記ホスト装置に対し、前記第2の配信端末の起動を行わせる
請求項4に記載の情報処理装置。 - 前記第1の配信端末は、前記第2の配信端末に対して同期プリフェッチ依頼を行う際に、前記第2のネットワークのトラフィック予想に基づいて適応的にストリーム品質の異なるセグメントを選択させる
請求項1に記載の情報処理装置。 - 第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備える情報処理装置が、
前記第1の配信端末によって、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行うこと
を含む情報処理方法。 - 第1のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第1の配信端末を備える情報処理装置のコンピュータに、
前記第1の配信端末によって、前記クライアント端末が移動することにより前記第1のネットワークから第2のネットワークへのハンドオーバーが発生するのに伴って、前記第2のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第2の配信端末に対し、前記第1の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行うこと
を含む情報処理を実行させるためのプログラム。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019021939A JP2022051973A (ja) | 2019-02-08 | 2019-02-08 | 情報処理装置および情報処理方法、並びにプログラム |
US17/424,771 US20220070750A1 (en) | 2019-02-08 | 2020-01-24 | Information processing device, information processing method, and program |
PCT/JP2020/002455 WO2020162219A1 (ja) | 2019-02-08 | 2020-01-24 | 情報処理装置および情報処理方法、並びにプログラム |
CN202080011937.2A CN113383578A (zh) | 2019-02-08 | 2020-01-24 | 信息处理装置、信息处理方法以及程序 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019021939A JP2022051973A (ja) | 2019-02-08 | 2019-02-08 | 情報処理装置および情報処理方法、並びにプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2022051973A true JP2022051973A (ja) | 2022-04-04 |
Family
ID=71947337
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019021939A Pending JP2022051973A (ja) | 2019-02-08 | 2019-02-08 | 情報処理装置および情報処理方法、並びにプログラム |
Country Status (4)
Country | Link |
---|---|
US (1) | US20220070750A1 (ja) |
JP (1) | JP2022051973A (ja) |
CN (1) | CN113383578A (ja) |
WO (1) | WO2020162219A1 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20210095457A (ko) * | 2020-01-23 | 2021-08-02 | 삼성전자주식회사 | 엣지 컴퓨팅 서비스를 위한 방법 및 장치 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5572221A (en) * | 1994-10-26 | 1996-11-05 | Telefonaktiebolaget Lm Ericsson | Method and apparatus for detecting and predicting motion of mobile terminals |
US8200747B2 (en) * | 2002-07-12 | 2012-06-12 | Hewlett-Packard Development Company, L.P. | Session handoff of segmented media data |
KR102066707B1 (ko) * | 2013-06-10 | 2020-01-15 | 삼성전자주식회사 | 비디오 스트리밍 서비스를 제공하기 위한 방법 및 그 모바일 장치 |
TW201633825A (zh) * | 2015-01-29 | 2016-09-16 | Vid衡器股份有限公司 | 增強無線網路應用QoE之頻寬預測及預取 |
US11172005B2 (en) * | 2016-09-09 | 2021-11-09 | Nokia Technologies Oy | Method and apparatus for controlled observation point and orientation selection audiovisual content |
-
2019
- 2019-02-08 JP JP2019021939A patent/JP2022051973A/ja active Pending
-
2020
- 2020-01-24 US US17/424,771 patent/US20220070750A1/en not_active Abandoned
- 2020-01-24 CN CN202080011937.2A patent/CN113383578A/zh not_active Withdrawn
- 2020-01-24 WO PCT/JP2020/002455 patent/WO2020162219A1/ja active Application Filing
Also Published As
Publication number | Publication date |
---|---|
US20220070750A1 (en) | 2022-03-03 |
CN113383578A (zh) | 2021-09-10 |
WO2020162219A1 (ja) | 2020-08-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9178928B2 (en) | Scalable content streaming system with server-side archiving | |
US8972519B2 (en) | Optimization of multimedia service over an IMS network | |
US20160295429A1 (en) | System, method and service product for content delivery | |
KR101330052B1 (ko) | 적응형 컨텐츠 전송 방식을 지원하는 컨텐츠 캐싱 서비스 제공 방법 및 이를 위한 로컬 캐싱 장치 | |
US20050015765A1 (en) | System for doing service location management taking into account the node and network characteristics | |
JP4065411B2 (ja) | 複製スイッチ上で取り扱われるストリームへのアクセス管理 | |
EP2391953A1 (en) | Application, usage&radio link aware transport network scheduler | |
WO2009155801A1 (zh) | 提供媒体流服务的方法及其***和装置 | |
US10630746B1 (en) | Streaming playlist including future encoded segments | |
US20120191876A1 (en) | Method and system for policy based transcoding brokering | |
US11522933B2 (en) | Information processing apparatus and information processing method | |
WO2019154283A1 (zh) | 一种业务迁移的方法及装置 | |
CN114531478A (zh) | 边缘资源聚合的方法、设备和计算机程序产品 | |
US20220400297A1 (en) | Method and apparatus for multicast control of a live video stream | |
WO2020162219A1 (ja) | 情報処理装置および情報処理方法、並びにプログラム | |
US20240015212A1 (en) | Methods and Systems for Ledger Based Content Delivery Using a Mobile Edge Computing (MEC) Server | |
EP1625725B1 (en) | Method for adapting service location placement based on recent data received from service nodes and actions of the service location manger | |
WO2020195705A1 (ja) | 情報処理装置および情報処理方法、並びにプログラム | |
US8774599B2 (en) | Method for transcoding and playing back video files based on grid technology in devices having limited computing power | |
KR101402923B1 (ko) | 캐시 장치에 사전 배포하는 콘텐츠를 관리하는 서버 및 방법, 그리고 캐시 장치 | |
JP2022531346A (ja) | 可変的な接続性を有するモバイル環境のためのマイクロキャッシュ方法及び装置 | |
JP2004178472A (ja) | プログラム取得方法およびその方法を利用可能なパケット転送装置 | |
WO2021140949A1 (ja) | コンテンツ配信システムおよびコンテンツ配信方法、並びにプログラム | |
KR101565137B1 (ko) | 무선 스트리밍 서비스 제공 방법 및 장치 | |
WO2024037719A1 (en) | Network entity for routing application data towards a user equipment |