JP2022051973A - 情報処理装置および情報処理方法、並びにプログラム - Google Patents

情報処理装置および情報処理方法、並びにプログラム Download PDF

Info

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
Application number
JP2019021939A
Other languages
English (en)
Inventor
靖明 山岸
Yasuaki Yamagishi
和彦 高林
Kazuhiko Takabayashi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Group Corp
Original Assignee
Sony Group Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Group Corp filed Critical Sony Group Corp
Priority to JP2019021939A priority Critical patent/JP2022051973A/ja
Priority to PCT/JP2020/002455 priority patent/WO2020162219A1/ja
Priority to CN202080011937.2A priority patent/CN113383578A/zh
Priority to US17/424,771 priority patent/US20220070750A1/en
Publication of JP2022051973A publication Critical patent/JP2022051973A/ja
Pending legal-status Critical Current

Links

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
    • 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
    • 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/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/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

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と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う。本技術は、例えば、シームレスなストリーミングを提供する情報処理システムに適用できる。【選択図】図１

Description

本開示は、情報処理装置および情報処理方法、並びにプログラムに関し、特に、シームレスなストリーミングを提供することができるようにした情報処理装置および情報処理方法、並びにプログラムに関する。
近年、非常な勢いで普及しているモバイルデバイスによるストリーミング視聴により、クラウドの処理負担の増大が懸念されている。このような懸念に対し、クラウドの処理負担の緩和策の１つとして、ネットワークのエッジ部に分散配置されるネットワークや、計算、ストレージリソースなどによるエッジコンピューティングを利用したストリーミングサービスの負荷分散が注目されている。
例えば、エッジコンピューティングにおいては、個々のエッジサーバの各種リソースは、セントラルクラウドに比べて小規模となるという制限がある。そのため、リソースの配置や選択などが複雑になり、管理コストが増大するというデメリットもある。それに対し、今後、いわゆる４Ｋや８Ｋなどの高画質なコンテンツのストリーミングサービスの普及がさらに拡大していくにつれて、このようなエッジコンピューティングリソースの効率的な運用を実現する仕組みが必要になると考慮される。
例えば、非特許文献１に開示されているMPEG-DASH(Dynamic Adaptive Streaming over HTTP)を利用してコンテンツを配信する技術がある。
ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)
ところで、モバイルデバイスでストリーミング視聴している最中に、デバイスが移動することによって基地局の間を跨ぐようにセルを遷移するようなハンドオーバー（以下、基地局間ハンドオーバーと称する）が発生する。このときに、遷移先のセルの環境、例えば、そのセルに含まれるクライアント数やそれらのクライアント群にサービスを提供するサービス群の実行状態などが異なるようなユースケースが想定される。
従って、このような基地局間ハンドオーバーの発生が伴うユースケースにおいても、再生ストリームが途切れることがなく、シームレスなストリーミングができることが求められる。ここで、シームレスなストリーミングとは、セルを跨って移動するような場合であっても、ストリーミングが途切れることなく継続されることである。
本開示は、このような状況に鑑みてなされたものであり、基地局間ハンドオーバーの発生が伴うユースケースにおけるシームレスなストリーミングを提供することができるようにするものである。
本開示の一側面の情報処理装置は、第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備え、前記第１の配信端末は、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う。
本開示の一側面の情報処理方法またはプログラムは、第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備える情報処理装置が、または、その情報処理装置のコンピュータに、前記第１の配信端末は、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行うことを含む。
本開示の一側面においては、第１の配信端末により、クライアント端末が移動することにより第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、第２のネットワークを介してクライアント端末に対してコンテンツをストリーミングする第２の配信端末に対し、第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼が行われる。
本技術を適用した通信システムの利用が想定されるユースケースについて説明する図である。 第１の実施の形態における情報処理システムの構成例を示すブロック図である。 ストリーミングを開始する処理を説明する図である。 Workflow Descriptionの記述例を示す図である。 アプリケーションオブジェクトについて説明する図である。 プリフェッチおよびストリーミングを行う第１の処理例を説明するフローチャートである。 プリフェッチおよびストリーミングを行う第２の処理例を説明するフローチャートである。 基地局間ハンドオーバーによるEdge-DANEの遷移について説明する図である。 KeepAlreadyEstablishedIfFailedの記述例を示す図である。 DoNotMigrateの記述例を示す図である。 Edge-DANEの遷移について説明する図である。 Source RANからTarget RANへDASH-Clientの移動を示す図である。 ME-Host間においてEdge-DANEを遷移する処理を説明する図である。 同期プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れについて説明する図である。 同期プリフェッチおよびストリーミングを行う第１の処理例を説明するフローチャートである。 同期プリフェッチおよびストリーミングを行う第１の処理例を説明するフローチャートである。 遷移先となるME-Host上に、リソース不足によってEdge-DANEの起動ができなかったケースについて説明する図である。 Source RANからTarget RANへDASH-Clientの移動を示す図である。 遷移先となるME-Host上に、リソース不足によってEdge-DANEの起動ができなかったケースの処理を説明する図である。 遷移先のセルの予測ができない場合について説明する図である。 Source RANからTarget RAN-AへDASH-Clientの移動を示す図である。 遷移先のセルの予測ができない場合の処理を説明する図である。 同期プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れについて説明する図である。 耐障害性冗長度を確保する処理について説明する図である。 Source RANからTarget RAN-AおよびTarget RAN-BへDASH-Clientの移動を示す図である。 耐障害性冗長度を確保する処理を説明する図である。 Workflow Descriptionの記述例を示す図である。 トラフィック予測に基づくEdge-DANEのキャッシュ状態の事前変更について説明する図である。 Source RANからTarget RANへDASH-Clientの移動を示す図である。 トラフィック予測に基づくEdge-DANEのキャッシュ状態を事前変更する処理を説明する図である。 同期適応型プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れを示す図である。 適応型プリフェッチを行うケースにおける処理を説明する図である。 PrefetchTriggerRequestの記述例を示す図である。 PrefetchTriggerRequestメッセージの記述例を示す図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜ユースケース＞
図１は、本技術を適用した情報処理システムの利用が想定されるユースケースについて説明する図である。
図１に示す構成例では、情報処理システム１１は、クラウド１２およびユーザ端末１３により構成されている。
クラウド１２は、複数のサーバがネットワークを介して接続されて構成され、それぞれのサーバが処理を実行することにより各種のサービスを提供する。例えば、情報処理システム１１においてクラウド１２は、ユーザ端末１３に対して動画像などのコンテンツを配信するストリーミングサービスを提供することができる。
図示するように、クラウド１２は、ME-Host３１－１乃至３１－３、ME-Host３２、およびME-Platform(Orchestrator)３３がネットワークを介して接続された構成となっている。なお、ME-Host３１－１乃至３１－３は、それぞれ同様に構成されており、それらを区別する必要がない場合、単に、ME-Host３１と称し、ME-Host３１を構成する各ブロックも同様に称する。そして、ME-Host３１は、Edge-DANE４１およびデータベース保持部４２を備えており、データベース保持部４２は、記憶部４３を有している。また、ME-Host３２は、Origin-DANE５１を備えており、Origin-DANE５１は、記憶部５２を有している。また、ME-Platform(Orchestrator)３３は、データベース保持部６１を備えている。
ユーザ端末１３は、例えば、スマートフォンなどを用いることができ、クラウド１２からストリーミングサービスにより配信される動画像を受信して表示することができる。例えば、ユーザ端末１３には、DASH-Client２１が実装された構成となっている。
そして、今後、このようなユースケースで使用されうるネットワーク網としては、5G-MEC(Multi-access Edge Computing)アーキテクチャが想定される。
具体的には、まず、ユーザ端末（UE：User Equipment）１３上に実装されたDASH-Client２１が、ME-Host３１－１上のEdge-DANE４１－１と接続される。なお、ME-Host３１上にDANE（DASH Aware Network Element）を実行するということは、本開示において新たに提案されるものである。
そして、Edge-DANE４１－１は、ME-Host３２上のOrigin-DANE５１を経由して、DASHストリーミングのルートサーバである一般のDASH-Origin-Server（図示せず）と接続される。例えば、Origin-DANE５１からEdge-DANE４１－１へは、一般のCDN（Content Delivery Network）のサーバ構成と同様に多段の階層を構成することもある。
例えば、DASH-Client２１は、ストリームを受信するユーザ端末１３上で実行されるストリーミング受信および再生アプリケーションである。また、Edge-DANE４１は、DASH-Client２１へのストリーミングを送信するME-Host３１上で実行されるストリーミング送信アプリケーションである。
なお、Edge-DANE４１およびOrigin-DANE５１は、通常のWebサーバやプロキシーサーバなどの機能の他、個々のDASH-Client２１側でアクセスしそうなDASHセグメントをあらかじめキャッシュする等のDASHストリーミングを最適化する機能を備える。従って、Edge-DANE４１およびOrigin-DANE５１は、その機能を実現するために必要な情報を、DASH-Client２１とやりとりする機能（例えば、DASH-SANDメッセージのやり取りにより）を備えている。
ところで、ユーザ端末１３が移動して基地局間ハンドオーバーが起こる場合、遷移前のセルとバインドされているME-Host３１－１（MEC環境）で実行されていたEdge-DANE４１－１も同時に、遷移後のセルとバインドされているME-Host３１－２または３１－３に対し遷移させることになる。これにより、ユーザ端末１３が移動しても、その前後で可能な限りシームレスなストリーミングを行うことができる。このように、ME-Host３１－１のEdge-DANE４１－１を、ユーザ端末１３の移動後のセルにバインドされたME-Host３１－２のEdge-DANE４１－２またはME-Host３１－３のEdge-DANE４１－３へ遷移させることによって、情報処理システム１１は、低遅延や負荷分散などのMECコンピューティングの利点を最大限に活かすことができる。
このとき、基地局間ハンドオーバーが起こる前に、移動先のセルのネットワークトラフィックやME-Host３１上のリソースの負荷状況を知った上で、事前準備をすることで、ストリーミングをシームレスにすることが期待できる。
ところで、従来の標準的なインタフェースやプロトコルなどを備えたMECアーキテクチャでは、このようなユースケースがサポートされていないため、シームレスなストリーミングは実現されていない。つまり、ベンダーやモデルの異なるモバイルネットワークキャプチャデバイスに実装できるMECアーキテクチャや、クラウド環境でこのようなサービスをサポートするMECアーキテクチャなどは存在していなかった。
そこで、以下で説明するように、本実施の形態において、上述したような事前準備などを行うことによってシームレスなストリーミングを実現するために必要なMECアーキテクチャで使用される標準プロトコル（API：Application Programming Interface）およびフロー（シーケンス）を新たに提案する。
ここで、既知の技術となっている内容について説明する。
まず、ME-Host３１上において、例えば、ユーザ端末１４がME-Host３１－１とME-Host３１－２との間をハンドオーバーする際に、アプリケーションがマイグレーションするというのは既知の技術である。これに対し、マイグレート先のアプリケーション実行に必要なリソースネゴシエーションについては、標準プロトコルとしては規定されていない。
また、ETSI(European Telecommunications Standards Institute)でも一般的なアプリケーションの実行条件（スタティックなメモリやディスク上限値など）をME-Platformに登録するための枠組みは規定されている。しかしながら、そのアプリケーションの実行に必要な要件にも基づき、ME-Platformに対して実行可否を確認するような技術は既知ではない。
なお、以下で説明するようなDANEを複製して状態同期させるプロトコルについては既知ではない。例えば、本開示では、CDNレベルの同期ではなく、異なるCDN内の個別のサーバ同士の状態同期、即ち、DASH awareな局所的な最適化が提案される。
ここで、本開示において新たに提案される内容について、さらに説明する。
まず、ユーザ端末１３の近傍にあるME-Host３１－１において、ユーザ端末１３上のDASH-Client２１と接続するEdge-DANE４１－１が実行されている状態とする。そして、Edge-DANE４１－１が、ユーザ端末１３の基地局間ハンドオーバーが予測される遷移先基地局にバインドされたME-Host３１－２上のEdge-DANE４１－２またはME-Host３１－３上のEdge-DANE４１－３と状態同期させるプロトコルが新たに提案される。
そこで、本実施の形態では、以下で説明するように、遷移先のセルのME-Host３１－２または３１－３上に、Edge-DANE４１－２または４１－３が稼働するためのCPUや、記憶域、IO（Input/Output）スループットなどを確保するためのリソースが予約される。そして、遷移前のEdge-DANE４１－１のキャッシュ状態の事前複製が行われる。即ち、予測された遷移先のセルに、遷移前のEdge-DANE４１－１上の当該DASH-Client２１に最適化されたキャッシュ状態が複製される。このとき、遷移が終わるまで状態同期が継続される。
また、トラフィック予測に基づくキャッシュ状態の事前変更が行われる。つまり、遷移先のセルのトラフィックの状態が異なり、遷移後のストリーム品質が変更される可能性がある場合に、変更された後の品質を見越した最適キャッシュ状態を遷移後のEdge-DANE４１－２または４１－３に予め構成しておく。なお、キャッシュ容量が十分に確保できない場合には、キャッシュ容量の制限の範囲内で最適化が行われる。または、遷移元のEdge-DANE４１－１を維持しておき、遷移後のME-Host３１－２または３１－３から遷移元のEdge-DANE４１－１へリクエストをリダイレクトする。
さらに、遷移先のセルが同時に２つにある場合、即ち、それらのカバレッジに階層関係があるときや、セル境界であることなどを条件とし、環境の良い方のセルのME-Host３１に、上述したような最適化されたEdge-DANE４１を実行する。また、遷移先のセルの予測ができない場合、隣接する複数のセルのME-Host３１に、上述したような最適化されたEdge-DANE４１を実行する。
＜第１の実施の形態における情報処理システム＞
図２乃至図２７を参照して、第１の実施の形態における情報処理システム１１として、遷移先のEdge-DANE４１－２および４１－３に対する遷移前のEdge-DANE４１－１のキャッシュ状態の事前複製について説明する。なお、Edge-DANE４１－１のキャッシュ状態には、現時点から予測される近い将来のリクエストに対応した近未来のキャッシュ状態を含んでもよい。
例えば、第１の実施の形態における情報処理システム１１では、DASH-Client２１の基地局間ハンドオーバーによりME-Host３１の環境が変わるとき、遷移後のME-Host３１上にEdge-DANE４１が稼働するためのCPUや、記憶域、IOスループット等を確保するためのリソースを予約し、遷移前のEdge-DANE４１のキャッシュ状態の事前複製ができることが特徴となる。
図２には、第１の実施の形態における情報処理システム１１として、５Ｇコアネットワークシステムファンクション群７１と、MEC環境であるME-Host３１におけるユーザ端末１３およびアプリケーション８２の間のセッションとが示されている。
例えば、情報処理システム１１では、エッジコンピューティングにおけるエッジサーバにより、従来のクラウドコンピューティングのボトルネックの１つである通信遅延を大幅に改善することができる。さらに、ユーザ端末１３、エッジサーバであるME-Host３１、および、クラウドサーバーであるME-Host３２の間で、高負荷なアプリケーションの分散処理を実行することで処理の高速化が可能となる。
なお、このエッジコンピューティングの標準仕様は”ETSI-MEC”において規定されている。そして、ETSI-MECにおけるME-Hostが、このエッジサーバであるME-Host３１に相当する。
図２に示す例では、ME-Host３１上のアプリケーション８２と、3GPP（Third Generation Partnership Project）で標準化している５Ｇコアネットワーク７１のアクセスネットワーク７２を介したユーザ端末１３（上に実装されるアプリケーション）とを接続する線が、ユーザデータセッションを表している。なお、５Ｇコアネットワーク７１におけるアクセスネットワーク（(R)AN）７２は、有線アクセスネットワーク（AN：Access Network）および無線アクセスネットワーク（RAN：Radio Access Network）を包含している。
また、ME-Host３１上には、ME-Platform８３というエッジコンピューティングのプラットフォームがある。そして、ME-Platform８３で実行されるアプリケーション８２が、ユーザ端末１３とのユーザデータセッションのアブストラクションであるデータプレーン８１を介して、ユーザ端末１３との間でストリームデータ等のユーザデータのやりとりを行う。ここで、データプレーン８１は、3GPPのUPF（User Plane Function）８４としての機能を備えている。なお、データプレーン８１が、UPF８４に相当する機能を備えていてもよい。
また、５Ｇ（第５世代移動通信システム）コアネットワーク７１では、サービスベースアーキテクチャが採用されており、コアネットワークの機能である複数のＮＦ（Network Function）が定義されている。そして、それらのＮＦが、サービスベースインターフェイスと呼ばれる統一的なインタフェースを介して接続されている。
図２の例では、ＮＦとして、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のセッション管理）が示されている。
図３は、図２の情報処理システム１１において、ME-Host３２上で実行されるOrigin-DANEアプリケーションおよびME-Host３１上で実行されるEdge-DANEアプリケーションが、ME-Host３１上のアプリケーションとして実装されるDistributionManagerにより起動される処理を説明する図である。
まず、Origin-DANE起動処理およびEdge-DANE起動処理が行われる。
Origin-DANE起動処理は、ME-Host３１のDistributionManagerが、ME-Platform(Orchestrator)３３のAPIを介して、起動の対象となるOrigin-DANEアプリケーションを実行するME-Host３２のME-Platformに対して行う。同様に、Edge-DANE起動処理は、ME-Host３１のDistributionManagerが、ME-Platform(Orchestrator)３３のAPIを介して、ME-Host３１自身のME-Platformに対して行う。
このとき、ME-Host３１のDistributionManagerは、Origin-DANEアプリケーションの実行に要求されるネットワークリソースや、計算リソース、ストレージリソースなどを記述するWorkflowDescriptionに基づいて、必要なリソースを確保して対象のアプリケーションを起動する。これにより、ME-Host３２のME-PlatformがOrigin-DANE５１を起動し、ME-Host３１のME-PlatformがEdge-DANE４１を起動する。
その後、DASH-Client２１は、最初に、ユーザ端末１３の近傍にあるME-Host３１－１上のEdge-DANE４１－１を見つけ、Edge-DANE４１－１を経由してOrigin-DANE５１からDASHセグメントを取得する。なお、DASH-Client２１は、Edge-DANE４１が見つからなければ、Origin-DANE５１から直接的にDASHセグメントを取得することができる。
なお、Edge-DANE４１は、DASH-Client２１から自身に対して送付される、近い将来取得の可能性があるDASHセグメントの集合を告げるSANDメッセージであるSAND-AnticipatedRequestメッセージを受け取ることができる。または、Edge-DANE４１自身が自発的に、近い将来のリクエストを予測することができる。
そして、Edge-DANE４１は、事前に、DASH-Client２１から将来リクエストされる可能性のあるDASHセグメントのセグメントシーケンスを、Origin-DANE５１から事前に読み込む（以下、プリフェッチと称する）ことができる。これにより、Edge-DANE４１は、DASH-Client２１に対するレスポンスのパフォーマンスを向上させることができる。
図４には、独自定義のWorkflow Descriptionの一例が示されている。
例えば、Workflow DescriptionにOrigin-DANEおよびEdge-DANEを記述する方式が、本開示において新たに提案されるものである。ここで、独自定義としているが、クラウド上のメディア処理のワークフローとそのアプリケーションのフレームワークについては、現時点で、MPEG-I-NBMP（Network-Based Media Processing）で仕様策定中であり、仕様は確定されていない。なお、このWorkflow Descriptionには、Origin-DANEおよびEdge-DANEが記述されているが、これらのWorkflow Description上において、それらのDANEの間には入出力の連結がない。
図４に示すように、Workfflow要素の直下の最初の要素は、url属性値’Origin-DANE-url’を持つApplication要素でありOrigin-DANEアプリケーションの実行を表す。その次に、url属性値’Edge-DANE-url’を持つApplication要素があり、Edge-DANEアプリケーションの実行を表す。
Origin-DANE５１およびEdge-DANE４１から提供されるストリームファイル（DASH segmentファイル）は、Origin-DANE５１およびEdge-DANE４１を構成するシステムを実現するWebサーバが提供するファイルアクセス方法（HTTP）を利用して、他のアプリケーションがアクセスして取得する。そして、ストリームファイルは最初、Origin-DANE５１に格納されて、その後、Edge-DANE４１からのリクエストに基づいて、そのEdge-DANE４１にキャッシュコピーされる。
図５には、上述したような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を介して５Ｇシステムにおけるパケットのルーティングを制御する情報である。
図６は、DASH-Client２１がSANDメッセージにより将来取得が予想されるセグメントを通知し、Edge-DANE４１がプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
ステップＳ１１において、DASH-Client２１は、Edge-DANE４１にMPD（Media Presentation Description）リクエストを送信する。そして、そのMPDリクエストを受信したEdge-DANE４１を介して、Origin-DANE５１がMPDリクエストを受信する。なお、MPDは、ストリーミングされるコンテンツのメタデータが記述されたファイルである。
ステップＳ１２において、Origin-DANE５１は、ステップＳ１１で送信されてきたMPDリクエストに応じたMPDレスポンスをEdge-DANE４１へ送信する。そして、そのMPDレスポンスを受信したEdge-DANE４１を介して、DASH-Client２１がMPDレスポンスを受信する。
ステップＳ１３において、DASH-Client２１は、ステップＳ１２で送信されてきたMPDレスポンスに基づいて、Edge-DANE４１にSegmentリクエストを送信する。そして、そのSegmentリクエストを受信したEdge-DANE４１を介して、Origin-DANE５１がSegmentリクエストを受信する。
ステップＳ１４において、Origin-DANE５１は、ステップＳ１３で送信されてきたSegmentリクエストに応じたSegmentレスポンスをEdge-DANE４１へ送信する。そして、そのSegmentレスポンスを介して、DASH-Client２１がSegmentレスポンスを受信する。
ステップＳ１５において、DASH-Client２１は、近い将来取得の可能性があるDASHセグメントを予測し、それらのDASHセグメントの集合を告げるSAND-AnticipatedRequestメッセージをEdge-DANE４１へ送信し、Edge-DANE４１が受信する。
そして、ステップＳ１６以降では、Edge-DANE４１およびOrigin-DANE５１の間でプリフェッチが行われる。即ち、ステップＳ１６において、Edge-DANE４１は、ステップＳ１５で受信したSAND-AnticipatedRequestメッセージに基づいて、将来のSegmentリクエストをOrigin-DANE５１へ送信する。これに応じて、ステップＳ１７において、Origin-DANE５１がSegmentレスポンスを送信する。そして、以下同様に、将来のSegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
一方、ステップＳ１８以降では、DASH-Client２１およびEdge-DANE４１の間でストリーミングが行われる。即ち、ステップＳ１８において、DASH-Client２１は、SegmentリクエストをEdge-DANE４１へ送信する。これに応じて、ステップＳ１９において、Edge-DANE４１は、既にプリフェッチしていたSegmentレスポンスを、DASH-Client２１へ送信する。そして、以下同様に、SegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
以上のように、DASH-Client２１が、Edge-DANE４１に対して送付するSAND-AnticipatedRequestメッセージに基づいて、Edge-DANE４１は、予め将来取得が予想されるSegmentをプリフェッチする。これにより、Edge-DANE４１は、DASH-Client２１に対するレスポンスのパフォーマンスを向上させることができる。
図７は、Edge-DANE４１が、将来取得が予想されるセグメントを予測し自発的にプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
例えば、ステップＳ２１乃至Ｓ２４において、図６のステップＳ１１乃至Ｓ１４と同様の処理が行われる。そして、ステップＳ２５において、Edge-DANE４１は、自発的に、近い将来リクエストの可能性があるDASHセグメントを予測する自走型将来Segmentリクエスト予測を行う。
従って、ステップＳ２６において、Edge-DANE４１は、ステップＳ２５で行った自走型将来Segmentリクエスト予測に基づいて、将来のSegmentリクエストをOrigin-DANE５１へ送信する。その後、ステップＳ２７乃至Ｓ２９において、図６のステップＳ１７乃至Ｓ１９と同様の処理が行われる。
以上のように、Edge-DANE４１は、例えば、DASH-Client２１との間で送受信された直近の過去のsegmentリクエストおよびSegmentレスポンスの履歴に基づいて、予め将来取得が予想されるSegmentを予測し、その予測されるSegmentをプリフェッチすることができる。これにより、Edge-DANE４１は、DASH-Client２１に対するレスポンスのパフォーマンスを向上させることができる。
次に、図８乃至図１６を参照して、DASH-Client２１の基地局間ハンドオーバーによるME-Host３１間のEdge-DANE４１の遷移について説明する。
例えば、図８に示すように、DASH-Client２１の実装されているユーザ端末１３が移動する際に、ME-Host３１が実装された基地局を跨った基地局間ハンドオーバーが発生する。以下では、ハンドオーバーする前のアクセスネットワーク７２を、Source RAN７２Ｓと称し、ハンドオーバーする前のME-Host３１を、Source ME-Host３１Ｓと称する。同様に、ハンドオーバーする先となるアクセスネットワーク７２を、Target RAN７２Ｔと称し、ハンドオーバーする先となるME-Host３１を、Target ME-Host３１Ｔと称する。
そして、とある基地局のSource RAN７２ＳにバインドされたSource ME-Host３１Ｓ上のEdge-DANEアプリケーションからSource RAN７２Ｓを介してストリーミングしているDASH-Client２１を実装するユーザ端末１３が、別のTarget ME-Host３１Ｔがバインドされた基地局のTarget ME-Host３１Ｔ上に移動する。この移動に伴う基地局間ハンドオーバーによって、図８の二点鎖線の矢印で示すように、Source ME-Host３１ＳのEdge-DANE４１Ｓが、Source ME-Host３１ＴのEdge-DANE４１Ｔへ遷移する。
このときに行われる処理について、図１３のフローを参照して説明する。なお、図１３のフローでは、DASH-Client２１およびEdge-DANE４１Ｓとの間でストリーミングがすでに開始された後の処理が示されている。
即ち、Source RAN７２Ｓ上のユーザ端末１３に実装されたDASH-Client２１は、Source ME-Host３１Ｓ上のEdge-DANE４１ＳがOrigin-DANE５１からプリフェッチしたストリームファイルを元に、既にストリーミングを行っている（図１３のストリーミングfrom Source ME-Host）。なお、Origin-DANE５１は、Edge-DANE４１Ｓとは別のME-Host３２上で実行されている。
ここでは、図１２に示すように、DASH-Client２１を実装するユーザ端末１３が、Source ME-Host３１Ｓとは別のTarget ME-Host３１Ｔがバインドされた基地局のTarget RAN７２Ｔ上に移動するものとする。その際に、Source ME-Host３１Ｓ上で実行されていたEdge-DANE４１Ｓ（Edge-DANEアプリケーション）が、Target ME-Host３１Ｔ上に遷移する。さらに、遷移先のTarget ME-Host３１Ｔ上に、対応するEdge-DANEアプリケーションインスタンスが別途生成されると同時に、その状態情報がEdge-DANE４１Ｔに複製される。
また、Source ME-Host３１Ｓ上で実行されているEdge-DANE４１Ｓは、ME-Platform８３Ｓが提供するAPIにより、DASH-Client２１が実装されたユーザ端末１３の移動（位置）を検知することができる。そして、逐一の位置遷移情報や、統計情報、AI等を利用したmobility patternの解析等から、ユーザ端末１３が、現在存在するSource RAN７２Ｓから別のTarget RAN７２Ｔに移動することが予測されたとする（図１３のTarget ME-Hostへの遷移予知）。なお、その遷移先のTarget RAN７２Ｔの基地局にはTarget ME-Host３１Ｔが実装されているものとする。
そして、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓは、ME-Platform(Orchestrator)３３に依頼して、Target ME-Host３１Ｔ上にEdge-DANE４１Ｔを実行する（図１３のEdge-DANE(at Target ME-Host)起動）。
これに応じて、Target ME-Host３１ＴのME-Platform８３Ｔは、DASH-Client２１およびEdge-DANE４１Ｓの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。
ここで、DASH-Client２１との間で現在確立しているセッションを維持することや、遷移先のセルのトラフィックやME-Platform８３Ｔの負荷状況を見越して現在確立しているセッションより品質を低下させて（または、向上させて）サービスを継続すること、品質を低下させなければならないような場合においてDASH-Client２１との間で現在確立しているSource ME-Host３１Ｓ上のEdge-DANE４１Ｓとのセッションを維持することなどの方針は、図９に示すようなWorkflowDescriptionに記載する’ハンドオーバー時のセッション更新ポリシー’による指定に基づくものとする。
例えば、KeepAlreadyEstablishedIfFailed=’true’の場合には、ハンドオーバー時にセッションを現状維持することが指定されている。一方、KeepAlreadyEstablishedIfFailed=’false’の場合には、ハンドオーバー時にセッションをアップグレードすることが指定されており、こちらがデフォルトとなっている。
また、Target ME-Host３１Ｔ上のEdge-DANE４１Ｔは、必要リソースがリザーブされて起動される（図１３のEdge-DANEリソース予約/生成）が、すぐにDASH-Client２１に対するストリーミング処理が始まるわけではない。例えば、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓが、同期した事前の読み込みを依頼する同期プリフェッチ依頼を行い、Edge-DANE４１Ｔは、その同期プリフェッチ依頼を受け取る（図１３の同期プリフェッチ依頼）。なお、同期プリフェッチ依頼で用いられる、同期プリフェッチ依頼のメッセージングプロトコルについては後述する。
これにより、Edge-DANE４１Ｔは、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓと同期しながら、Origin-DANE５１からストリームファイルをプリフェッチすることができる。
さらに時間が経過して、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓが、ME-Platform８３Ｓを介して、DASH-Client２１が実装されたユーザ端末１３が移動して、Target ME-Host３１ＴがバインドされたTarget RAN７２Ｔに新たに接続されたことを検知したとする（図１３のDASH-ClientのTarget ME-Hostへの遷移検知）。
これに応じて、遷移後のTarget RAN７２Ｔからの当該ストリーミングリクエストがTarget ME-Host３１Ｔ上のEdge-DANE４１Ｔが受信できるようにトラフィック変更が行われる（図１３のTarget ME-Hostへのトラフィック更新）。同時に、ターゲットME-Host３１Ｔ上のEdge-DANE４１Ｔからのレスポンスがユーザ端末１３に届くようトラフィック変更が行われる。
その後、Target ME-Host３１Ｔ上のEdge-DANE４１Ｔは、Target RAN７２Ｔを経由して、移動した後のDASH-Client２１に対するストリーミングを開始する（図１３のストリーミングfrom Target ME-Host）。
なお、図１０に示すように、WorkflowDescriptionにおいて、Edge-DANEアプリケーションのME-Host３１どうしの間の遷移そのものを認めるか否かを指定することができる。例えば、Edge-DANEアプリケーションのME-Host３１どうしの間の遷移そのものを認めない場合には、Policy@DoNotMigrate=’true’が指定される。一方、ME-Host３１の遷移を試みる場合には、Policy@DoNotMigrate=’false’が指定され、できる限りMECの利点を活かすことより、こちらがデフォルトとなっている。もちろん、Policy@DoNotMigrate=’true’の場合には、図９に示したKeepAlreadyEstablishedIfFailedは指定できない。
また、図１１には、上述したような処理によって、DASH-Client２１が移動することによって基地局間ハンドオーバーが発生するのに伴って、Edge-DANE４１が遷移する遷移前および遷移後の状態が示されている。
図１４には、図１３の同期プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れが示されている。
例えば、図示するように、DASH-Client２１では、過去のセグメント（Seg-1，Seg-2，Seg-3，・・・）がEdge-DANE４１Ｓを介してストリーミングされ、既に再生されている。そして、DASH-Client２１において、再生中となる現在のセグメント（Seg-0）がストリーミングされているタイミングで、同期プリフェッチ依頼が行われたとする。
このとき、同期プリフェッチ依頼をトリガーとして、現在のセグメントSeg-0より将来に必要となる同一AdaptationSetのセグメント（Seg+1，Seg+2，Seg+3，・・・）のプリフェッチが開始される。即ち、図示するように、将来のセグメント（Seg+1，Seg+2，Seg+3，・・・）が、Origin-DANE５１からEdge-DANE４１Ｓへ送信されるのと同期して、Edge-DANE４１Ｔへの送信が開始される。
なお、このプリフェッチは、現在のSource ME-Host３１Ｓ経由のセッションリソースと同程度のセッションリソースが、Target ME-Host３１Ｔ経由の環境においても担保されることが確認されているときに開始される。また、Source ME-Host３１ＳとTarget ME-Host３１Ｔとの間は、NTP（Network Time Protocol）などによってシステムクロック同期が実施され、同一のWallclockを共有にしているものとする。
図１５は、DASH-Client２１がSANDメッセージにより将来取得が予想されるセグメントを通知し、Edge-DANE４１ＳおよびEdge-DANE４１Ｔがプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
ステップＳ３１において、DASH-Client２１は、Edge-DANE４１ＳにSegmentリクエストを送信する。そして、そのSegmentリクエストを受信したEdge-DANE４１Ｓを介して、Origin-DANE５１がSegmentリクエストを受信する。
ステップＳ３２において、Origin-DANE５１は、ステップＳ３１で送信されてきたSegmentリクエストに応じたSegmentレスポンスをEdge-DANE４１Ｓへ送信する。そして、そのSegmentレスポンスを受信したEdge-DANE４１Ｓを介して、DASH-Client２１がSegmentレスポンスを受信する。
ステップＳ３３において、DASH-Client２１は、近い将来取得の可能性があるDASHセグメントを予測し、それらのDASHセグメントの集合を告げるSAND-AnticipatedRequestメッセージをEdge-DANE４１Ｓへ送信し、Edge-DANE４１Ｓが受信する。
ステップＳ３４において、Edge-DANE４１Ｓは、Edge-DANE４１Ｔに対して、MPDおよびSAND-AnticipatedRequestメッセージを送付し、同期プリフェッチ依頼を行う。
そして、ステップＳ３５以降におけるEdge-DANE４１ＴおよびOrigin-DANE５１の間のプリフェッチと、ステップＳ３６以降におけるEdge-DANE４１ＳおよびOrigin-DANE５１の間のプリフェッチが同期して行われる。即ち、ステップＳ３５において、Edge-DANE４１Ｔが、将来のSegmentリクエストをOrigin-DANE５１へ送信するとともに、ステップＳ３６において、Edge-DANE４１Ｓが、将来のSegmentリクエストをOrigin-DANE５１へ送信する。これに応じて、ステップＳ３７において、Origin-DANE５１がSegmentレスポンスを送信する。そして、以下同様に、将来のSegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
一方、ステップＳ３８以降では、DASH-Client２１およびEdge-DANE４１Ｓの間でストリーミングが行われる。即ち、ステップＳ３８において、DASH-Client２１は、SegmentリクエストをEdge-DANE４１Ｓへ送信する。これに応じて、ステップＳ３９において、Edge-DANE４１Ｓは、既にプリフェッチしていたSegmentレスポンスを、DASH-Client２１へ送信する。そして、以下同様に、SegmentリクエストおよびSegmentレスポンスの送受信が繰り返して行われる。
以上のように、Edge-DANE４１ＳおよびEdge-DANE４１Ｔは、プリフェッチを同期して行うことができる。これにより、その後、DASH-Client２１の移動に伴って、Edge-DANE４１Ｔからのストリーミングに遷移する際に、Edge-DANE４１Ｔは、DASH-Client２１に対するレスポンスのパフォーマンスを向上させることができる。
図１６は、Edge-DANE４１ＳおよびEdge-DANE４１Ｔが、将来取得が予想されるセグメントを予測し自発的にプリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
例えば、ステップＳ４１およびＳ４２において、図１５のステップＳ３１およびＳ３２と同様の処理が行われる。そして、ステップＳ４３において、Edge-DANE４１Ｓは、Edge-DANE４１Ｔに対してMPDを送付し、Edge-DANE４１Ｔとの間のプリフェッチを同期させる同期プリフェッチ依頼（自走型）を行う。
これに応じて、ステップＳ４４において、Edge-DANE４１Ｔは、MPDを参照し、自発的に、近い将来リクエストの可能性があるDASHセグメントを予測する自走型将来Segmentリクエスト予測を行う。同様に、ステップＳ４５において、Edge-DANE４１Ｓは、MPDを参照し、自発的に、近い将来リクエストの可能性があるDASHセグメントを予測する自走型将来Segmentリクエスト予測を行う。その後、ステップＳ４６乃至Ｓ５０において、図１５のステップＳ３５乃至Ｓ３９と同様の処理が行われる。
以上のように、Edge-DANE４１ＳおよびEdge-DANE４１Ｔそれぞれは、予め将来取得が予想されるSegmentを予測し、その予測されるSegmentのプリフェッチを同期して行うことができる。これにより、その後、DASH-Client２１の移動に伴って、Edge-DANE４１Ｔからのストリーミングに遷移する際に、Edge-DANE４１Ｔは、DASH-Client２１に対するレスポンスのパフォーマンスを向上させることができる。
次に、図１７乃至図１９を参照して、遷移先となるME-Host３１上に、リソース不足によってEdge-DANE４１の起動ができなかったケースにおける処理について説明する。
図１７には、Source RAN７２ＳからTarget RAN７２ＴへDASH-Client２１が移動すること（図１８参照）によって基地局間ハンドオーバーが発生するのに伴う遷移前および遷移後の状態が示されている。
即ち、とある基地局のSource RAN７２ＳにバインドされたSource ME-Host３１Ｓ上のEdge-DANEアプリケーションからSource RAN７２Ｓを介してストリーミングしているDASH-Client２１を実装するユーザ端末１３が、別のTarget ME-Host３１Ｔがバインドされた基地局のTarget ME-Host３１Ｔ上に移動する。この移動に伴う基地局間ハンドオーバーによって、Source ME-Host３１ＳのEdge-DANE４１Ｓを遷移させようとするが、リソース不足によって、Source ME-Host３１ＴのEdge-DANE４１Ｔが起動できないことがある。
この場合、Source ME-Host３１ＳのEdge-DANE４１Ｓを維持したまま、Edge-DANE４１ＳがOrigin-DANE５１から受信したセグメントを、データプレーン８１Ｓからデータプレーン８１Ｔへ送信して、Target RAN７２Ｔを介してDASH-Client２１へ送信することができる。
このときに行われる処理について、図１９のフローを参照して説明する。なお、図１９のフローでは、DASH-Client２１およびEdge-DANE４１Ｓとの間でストリーミングがすでに開始された後の処理が示されている。
まず、図１３のフローを参照して上述したように、Edge-DANE４１Ｓは、ユーザ端末１３が、現在存在するSource RAN７２Ｓから別のTarget RAN７２Ｔに移動することを予測する（図１９のTarget ME-Hostへの遷移予知）。
そして、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓは、ME-Platform(Orchestrator)３３に依頼して、Target ME-Host３１Ｔ上にEdge-DANE４１Ｔを実行する（図１９のEdge-DANE(at Target ME-Host)起動）。
これに応じて、Target ME-Host３１ＴのME-Platform８３Ｔは、DASH-Client２１およびEdge-DANE４１Ｓの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。しかしながら、このケースでは、Edge-DANE４１Ｔの起動に失敗する。
さらに時間が経過して、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓが、ME-Platform８３Ｓを介して、DASH-Client２１が実装されたユーザ端末１３が移動して、Target ME-Host３１ＴがバインドされたTarget RAN７２Ｔに新たに接続されたことを検知したとする（図１９のDASH-ClientのTarget ME-Hostへの遷移検知）。
この場合、Edge-DANE４１Ｓは、遷移後のTarget RAN７２Ｔからの当該ストリーミングリクエストがSource ME-Host３１Ｓ上のEdge-DANE４１Ｓが受信できるようにトラフィック維持が行われる（図１９のSource ME-Hostへのトラフィック維持）。同時に、Target ME-Host３１Ｔ上のME-Platform８３Ｔに対して、Source ME-Host３１Ｓへのトラフィック変更が行われる。
これにより、Target ME-Host３１Ｔ上でEdge-DANE４１Ｔの起動に失敗した場合でも、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓを維持したまま、Target RAN７２Ｔを介して、DASH-Client２１へのストリーミングを実現することができる。
図２０乃至図２３を参照して、遷移先のセル（RAN７２）の予測ができない場合、遷移が予想される２つのセル（TargetRAN７２Ｔ－ＡおよびTargetRAN７２Ｔ－Ｂ）にバインドされたTarget ME-Host３１Ｔ－ＡおよびTarget ME-Host３１Ｔ－Ｂに、それぞれEdge-DANE４１Ｔを実行しておく処理について説明する。ここでは、最終的に、DASH-Client２１がTarget ME-Host３１Ｔ－ＡにバインドされるTargetRAN７２Ｔ－Ａに遷移するケースを示している。
例えば、図２０には、Source RAN７２ＳからTargetRAN７２Ｔ－ＡへDASH-Client２１が移動すること（図２１参照）によって基地局間ハンドオーバーが発生するのに伴う状態が示されている。
即ち、DASH-Client２１が、TargetRAN７２Ｔ－ＡおよびTargetRAN７２Ｔ－Ｂのどちらに遷移するか予測できない場合、Target ME-Host３１Ｔ－ＡにEdge-DANE４１Ｔ－Ａを起動させておくとともに、Target ME-Host３１Ｔ－ＢにEdge-DANE４１Ｔ－Ｂを起動させておく。そして、DASH-Client２１がTargetRAN７２Ｔ－Ａへの遷移が検知されると、Edge-DANE４１Ｔ－ＡからTargetRAN７２Ｔ－Ａを介して、DASH-Client２１へのストリーミングが行われる。
このときに行われる処理について、図２２のフローを参照して説明する。なお、図２２のフローでは、DASH-Client２１およびEdge-DANE４１Ｓとの間でストリーミングがすでに開始された後の処理が示されている。
まず、図１３のフローを参照して上述したように、Edge-DANE４１Ｓは、ユーザ端末１３が、現在存在するSource RAN７２Ｓから別のTarget RAN７２Ｔ－ＡまたはTarget RAN７２Ｔ－Ｂに移動することを予測する（図２２のTarget ME-Host AorBへの遷移予知）。即ち、この場合、Target RAN７２Ｔ－ＡおよびTarget RAN７２Ｔ－Ｂのどちらに移動するかは予測できていない。
そして、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓは、ME-Platform(Orchestrator)３３に依頼して、Target ME-Host３１Ｔ－Ａ上にEdge-DANE４１Ｔ－Ａを実行するとともに、Target ME-Host３１Ｔ－Ｂ上にEdge-DANE４１Ｔ－Ｂを実行する（図２２のEdge-DANE(at Target ME-Host A&B)起動）。
これに応じて、Target ME-Host３１ＴのME-Platform８３Ｔは、DASH-Client２１およびEdge-DANE４１Ｓの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。これにより、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａは、必要リソースがリザーブされて起動される（図２２のEdge-DANEリソース予約/生成）。同様に、Target ME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂは、必要リソースがリザーブされて起動される（図２２のEdge-DANEリソース予約/生成）。
その後、Target ME-Host３１ＴのME-Platform８３Ｔは、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａに対して同期プリフェッチ依頼を行うとともに、Target ME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂに対して同期プリフェッチ依頼を行う。これにより、Edge-DANE４１Ｔ－ＡおよびEdge-DANE４１Ｔ－Ｂは、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓと同期しながらOrigin-DANE５１からストリームファイルをプリフェッチすることができる。
さらに時間が経過して、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓが、ME-Platform８３Ｓを介して、DASH-Client２１が実装されたユーザ端末１３が移動して、Target ME-Host３１Ｔ－ＡがバインドされたTarget RAN７２Ｔ－Ａに新たに接続されたことを検知したとする（図２２のDASH-ClientのTarget ME-Host Aへの遷移検知）。
これに応じて、遷移後のTarget RAN７２Ｔ－Ａからの当該ストリーミングリクエストがTarget ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａが受信できるようにトラフィック変更が行われる（図２２のTarget ME-Host Aへのトラフィック更新）。同時に、ターゲットME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａからのレスポンスがユーザ端末１３に届くようトラフィック変更が行われる。
その後、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａは、Target RAN７２Ｔ－Ａを経由して、移動した後のDASH-Client２１に対するストリーミングを開始する（図２２のストリーミングfrom Target ME-Host A）。その際、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａのプリフェッチは継続される一方で、Target ME-Host３１Ｔ－B上のEdge-DANE４１Ｔ－Bのプリフェッチは終了される。
図２３には、図２２の同期プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れが示されている。
例えば、図示するように、DASH-Client２１では、過去のセグメント（Seg-1，Seg-2，Seg-3，・・・）がEdge-DANE４１Ｓを介してストリーミングされ、既に再生されている。そして、DASH-Client２１において、再生中となる現在のセグメント（Seg-0）がストリーミングされているタイミングで、同期プリフェッチ依頼が行われたとする。
このとき、同期プリフェッチ依頼をトリガーとして、現在のセグメントSeg-0より将来に必要となる同一AdaptationSetのセグメント（Seg+1，Seg+2，Seg+3，・・・）のプリフェッチが開始される。即ち、図示するように、将来のセグメント（Seg+1，Seg+2，Seg+3，・・・）が、Origin-DANE５１からEdge-DANE４１Ｓへ送信されるのと同期して、Edge-DANE４１Ｔ－ＡおよびEdge-DANE４１Ｔ－Ｂの両方への送信が開始される。
なお、このプリフェッチは、現在のSource ME-Host３１Ｓ経由のセッションリソースと同程度のセッションリソースが、Target ME-Host３１Ｔ－ＡおよびTarget ME-Host３１Ｔ－Ｂ経由の環境においても担保されることが確認されているときに開始される。また、Source ME-Host３１ＳとTarget ME-Host３１Ｔ－ＡおよびTarget ME-Host３１Ｔ－Ｂとの間は、NTP（Network Time Protocol）などによってシステムクロック同期が実施され、同一のWallclockを共有にしているものとする。
図２４乃至図２７を参照して、耐障害性冗長度を確保する処理について説明する。ここでは、カバレッジが重複する２つのセル（TargetRAN７２Ｔ－ＡおよびTargetRAN７２Ｔ－Ｂ）にバインドされた、Target ME-Host３１Ｔ－ＡおよびTarget ME-Host３１Ｔ－Ｂに、それぞれEdge-DANE４１Ｔを実行し、２つのストリーミングセッションを同期して実行する例が示されている。なお、遷移後のDASH-Client２１が、TargetRAN７２Ｔ－ＡおよびTargetRAN７２Ｔ－Ｂの両方に、同時に接続されるものとしている。
例えば、図２４には、Source RAN７２ＳからTargetRAN７２Ｔ－ＡおよびTargetRAN７２Ｔ－ＢへDASH-Client２１が移動すること（図２５参照）によって基地局間ハンドオーバーが発生するのに伴う状態が示されている。
即ち、TargetRAN７２Ｔ－ＡおよびTargetRAN７２Ｔ－Ｂのカバレッジが重複する場合、Target ME-Host３１Ｔ－ＡにEdge-DANE４１Ｔ－Ａを起動させておくとともに、Target ME-Host３１Ｔ－ＢにEdge-DANE４１Ｔ－Ｂを起動させておく。そして、DASH-Client２１がTargetRAN７２Ｔ－ＡおよびTargetRAN７２Ｔ－Ｂへの遷移が検知されると、Edge-DANE４１Ｔ－ＡからTargetRAN７２Ｔ－Ａを介して、Edge-DANE４１Ｔ－ＢからTargetRAN７２Ｔ－Ｂを介して、DASH-Client２１へのストリーミングが行われる。
このときに行われる処理について、図２６のフローを参照して説明する。なお、図２６のフローでは、DASH-Client２１およびEdge-DANE４１Ｓとの間でストリーミングがすでに開始された後の処理が示されている。
まず、図１３のフローを参照して上述したように、Edge-DANE４１Ｓは、ユーザ端末１３が、現在存在するSource RAN７２Ｓから別のTarget RAN７２Ｔ－ＡまたはTarget RAN７２Ｔ－Ｂに移動することを予測する（図２６のTarget ME-Host AorBへの遷移予知）。
そして、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓは、ME-Platform(Orchestrator)３３に依頼して、Target ME-Host３１Ｔ－Ａ上にEdge-DANE４１Ｔ－Ａを実行するとともに、Target ME-Host３１Ｔ－Ｂ上にEdge-DANE４１Ｔ－Ｂを実行する（図２６のEdge-DANE(at Target ME-Host A&B)起動）。
これに応じて、Target ME-Host３１ＴのME-Platform８３Ｔは、DASH-Client２１およびEdge-DANE４１Ｓの間で現在確立しているセッションと同等なプロトコル・リソース要件に基づいて、リソース予約と実行を試みる。これにより、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａは、必要リソースがリザーブされて起動される（図２６のEdge-DANEリソース予約/生成）。同様に、Target ME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂは、必要リソースがリザーブされて起動される（図２６のEdge-DANEリソース予約/生成）。
その後、Target ME-Host３１ＴのME-Platform８３Ｔは、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａに対して同期プリフェッチ依頼を行うとともに、Target ME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂに対して同期プリフェッチ依頼を行う。これにより、Edge-DANE４１Ｔ－ＡおよびEdge-DANE４１Ｔ－Ｂは、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓと同期しながらOrigin-DANE５１からストリームファイルをプリフェッチすることができる。
さらに時間が経過して、Source ME-Host３１Ｓ上のEdge-DANE４１Ｓが、ME-Platform８３Ｓを介して、DASH-Client２１が実装されたユーザ端末１３が移動して、Target ME-Host３１Ｔ－ＡがバインドされたTarget RAN７２Ｔ－Ａ、および、Target ME-Host３１Ｔ－ＢがバインドされたTarget RAN７２Ｔ－Ｂに新たに接続されたことを検知したとする（図２６のDASH-ClientのTarget ME-Host A&Bへの遷移検知）。
これに応じて、遷移後のTarget RAN７２Ｔ－Ａからの当該ストリーミングリクエストがTarget ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａが受信できるようにトラフィック変更が行われる（図２６のTarget ME-Host Aへのトラフィック更新）。同時に、ターゲットME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａからのレスポンスがユーザ端末１３に届くようトラフィック変更が行われる。
同様に、遷移後のTarget RAN７２Ｔ－Ｂからの当該ストリーミングリクエストがTarget ME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂが受信できるようにトラフィック変更が行われる（図２６のTarget ME-Host Bへのトラフィック更新）。同時に、ターゲットME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂからのレスポンスがユーザ端末１３に届くようトラフィック変更が行われる。
その後、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａは、Target RAN７２Ｔ－Ａを経由して、移動した後のDASH-Client２１に対するストリーミングを開始する（図２６のストリーミングfrom Target ME-Host A）。また、Target ME-Host３１Ｔ－Ａ上のEdge-DANE４１Ｔ－Ａのプリフェッチは継続される。
同様に、Target ME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂは、Target RAN７２Ｔ－Ｂを経由して、移動した後のDASH-Client２１に対するストリーミングを開始する（図２６のストリーミングfrom Target ME-Host B）。また、Target ME-Host３１Ｔ－Ｂ上のEdge-DANE４１Ｔ－Ｂのプリフェッチは継続される。
例えば、図２７に示すように、この冗長構成は、Workflow Descriptionにおいて、対象アプリケーションのApplication要素のduplicate属性を’true’に設定することにより指示することができるものとする。
＜第２の実施の形態における情報処理システム＞
図２８乃至図３２を参照して、第２の実施の形態における情報処理システム１１において、トラフィック予測に基づくEdge-DANE４１のキャッシュ状態の事前変更について説明する。例えば、第２の実施の形態における情報処理システム１１では、DASH-Client２１の基地局間ハンドオーバーによりME-Host３１の環境が変わるとき、遷移前のEdge-DANE４１のキャッシュ状態の事前複製をする際に、トラフィック予測に基づくキャッシュ状態の事前変更ができることが特徴となる。
例えば、図２８には、Source RAN７２ＳからTargetRAN７２ＴへDASH-Client２１が移動すること（図２９参照）によって基地局間ハンドオーバーが発生するのに伴う遷移前および遷移後の状態が示されている。
例えば、遷移予定のTargetRAN７２ＴにバインドされたME-Host３１Ｔ上に実行されるEdge-DANE４１Ｔにおいて、遷移前のセッションと同等なセッションリソースが確保できない可能性をあらかじめ検知したとする。この場合、遷移後のストリーム品質の変更を見越した最適キャッシュ状態を遷移後のEdge-DANE４１Ｔにあらかじめ構成しておく。そして、キャッシュ容量が十分とれない場合には、制限の範囲内で最適化する。
ここで、図２０を参照して上述したような遷移先のセル（RAN７２）の予測ができない場合の処理や、図２４を参照して上述したような耐障害性冗長度確保する処理などおける同期プリフェッチ依頼を、以下で説明する同期適合型プリフェッチ依頼に置き換えることができる。
このときに行われる処理が、図３０のフローに示されている。なお、図３０に示すフローは、図１３のフローにおける同期プリフェッチ依頼が、同期適応型プリフェッチ依頼に置き換えられ、その後、適応型プリフェッチが行われる点以外は、図１３のフローと同様の処理が行われ、その詳細な説明は省略する。
ここで、同期適応型プリフェッチ依頼について説明する。
例えば、上述したように、遷移前のDASH-Client２１にストリーミングしているSource ME-Host３１Ｓ上のEdge-DANE４１Ｓが、このDASH-Client２１がTarget ME-Host３１ＴにバインドされたTarget RAN７２Ｔに遷移する可能性を検知する。これに応じて、Target ME-Host３１Ｔ上にEdge-DANE４１Ｔを起動した後に、そのEdge-DANE４１Ｔに対する同期適応型プリフェッチ依頼が行われる。
そして、適応型プリフェッチは、Edge-DANE４１Ｔが、将来取得が予想されるセグメントを予測し自発的にプリフェッチするものである。また、適応型プリフェッチでは、現在のTarget RAN７２Ｔにおけるトラフィック状態や、Target ME-Host３１Ｔの計算やストレージなどのリソース状態を鑑みて、このDASH-Client２１が将来、Target RAN７２Ｔに遷移した場合に想定される妥当なストリーミングセッションについての制約を見越して、あらかじめ将来取得が予測されるセグメントをプリフェッチするものとする。
また、Target RAN７２Ｔの現在のトラフィックや、計算、ストレージなどのリソース状態、または、DASH-Client２１が遷移後の将来で予測されるトラフィックや、計算、ストレージなどのリソース状態によっては、Source ME-Host３１Ｓで現在確立されているセッションリソースが担保されない可能性がある。このため、現在よりも貧弱な環境である場合には、現在再生途上のAdaptationSetのRepresentationのうち、よりリソース消費の少ない（例えば、よりビットレートの低い）Representationについて、将来取得が予想されるセグメントをプリフェッチする。なお、とあるAdaptationSetの中のRepresentation群から選択する場合もあれば、AdaptationSetそのものを変える場合もあり得る。このように、例えば、遷移先のトラフィック予測に基づいて、ストリーム品質が異なる（高ビットレートまたは低ビットレート）のセグメントを。適応的に選択することが可能である。
図３１には、このような同期適応型プリフェッチ依頼をトリガーとしてプリフェッチが開始される際のセグメントの流れが示されている。
例えば、図示するように、現在再生途上のAdaptationSetのRepresentationのSegmentシーケンスと、よりビットレートの低い（将来のリソース状態に最適な属性を有す）AdaptationSetのRepresentationとのSegmentシーケンスの両方が用意されている。
そして、同期適応型プリフェッチ依頼をトリガーとして、現在のセグメントSeg-0より将来に必要となる同一AdaptationSetの異なるRepresentationのセグメントのプリフェッチが開始される。即ち、図示するように、現在のAdaptationSetのRepresentationの将来のセグメント（SegH+1，SegH+2，SegH+3，・・・）が、Origin-DANE５１からEdge-DANE４１Ｓへ送信されるのと同期して、よりビットレートの低いAdaptationSetのRepresentationの将来のセグメント（SegL+1，SegL+2，SegL+3，・・・）が、Edge-DANE４１Ｔへの送信が開始される。
なお、この適応型プリフェッチは、現在のSource ME-Host３１Ｓ経由のセッションリソースとは異なるセッションリソースが、Target ME-Host３１Ｔ経由の環境において担保されることが確認されているときに開始される。また、Source ME-Host３１ＳとTarget ME-Host３１Ｔとの間は、NTP（Network Time Protocol）などによってシステムクロック同期が実施され、同一のWallclockを共有にしているものとする。
図３２は、Edge-DANE４１ＳおよびEdge-DANE４１Ｔが、将来取得が予想されるセグメントを予測し自発的に適応型プリフェッチするケースにおいて、ストリーミングを開始する処理を説明するフローチャートである。
例えば、ステップＳ５１およびＳ５２において、図１６のステップＳ４１およびＳ４２と同様の処理が行われる。そして、ステップＳ５３において、Edge-DANE４１Ｓは、Edge-DANE４１Ｔに対してMPDを送付し、Edge-DANE４１Ｔとの間の適応型プリフェッチを同期させる同期適応型プリフェッチ依頼（自走型）を行う。
その後、ステップＳ５４およびＳ５５において、図１６のステップＳ４４およびＳ４５と同様の処理が行われる。
そして、ステップＳ５６以降におけるEdge-DANE４１ＴおよびOrigin-DANE５１の間の適応型プリフェッチと、ステップＳ５７以降におけるEdge-DANE４１ＳおよびOrigin-DANE５１の間のプリフェッチとが同期して行われる。
以上のように、Edge-DANE４１Ｔが適応型プリフェッチを行うことで、例えば、トラフィック予測に基づくキャッシュ状態を事前変更することができ、遷移後のトラフィックに応じたビットレートでストリーミングを行うことができる。
以下では、同期プリフェッチ依頼および同期適応型プリフェッチ依頼のメッセージングプロトコルについて説明する。
例えば、遷移前のSource ME-Host３１Ｓ上のEdge-DANE４１Ｓから、遷移予定のTarget ME-Host３１Ｔ上のEdge-DANE４１Ｔへの同期プリフェッチ依頼および同期適応型プリフェッチ依頼のメッセージングプロトコルはDASH-SANDを拡張して定義することができる。
そして、Edge-DANE４１間のSAND-PEDメッセージとして、PrefetchTriggerRequestメッセージを導入する。例えば、PrefetchTriggerRequest要素は、プリフェッチの適応型か否かを示すadaptivePrefetch属性、Source ME-Host３１Ｓ上のEdge-DANE４１ＳからのSANDメッセージを格納するrelayedSANDMessageFromDASHClient属性、および、対象のストリームのセグメントを特定するtheStream要素を持つ。
図３３には、PrefetchTriggerRequestの構造の一例が示されている。
例えば、adaptivePrefetch属性は、値falseで通常のプリフェッチを実行し、値trueで適応型プリフェッチを実行することを示す。
また、relayedSANDMessageFromDASHClient属性は、例えば、上述した図１５のステップＳ３３において、DASH-Client２１がEdge-DANE４１Ｓに対して発行する、近い将来取得可能性のあるsegmentの集合を告げるSANDメッセージであるSAND-AnticipatedRequestメッセージも格納できるようにする。
また、theStream要素は、制御対象のストリームの属性を含むMPDへの参照（MPDのurl）、または、MPD本体を格納するmpd属性を持ち、このMPDに記載される特定のsegmentを指示するXPathストリングを格納するsegmentPath属性を持つ。
ここで、PrefetchTriggerRequestメッセージは、例えば、図３４に示すようなHTTP-POSTを用いて、Source ME-Host３１Ｓ上のEdge-DANE４１ＳかTarget ME-Host３１Ｔ上のEdge-DANE４１Ｔに転送される。
また、図３４には、http://a.com/a.mpdというurlで指定されるmpdの最初のperiod要素の最初のAdaptationSet要素のSegmentTemplate要素で指定されるsegmentの一例が示されている。
＜コンピュータの構成例＞
次に、上述した一連の処理（情報処理方法）は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
図３５は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク１０５やROM１０３に予め記録しておくことができる。
あるいはまた、プログラムは、ドライブ１０９によって駆動されるリムーバブル記録媒体１１１に格納（記録）しておくことができる。このようなリムーバブル記録媒体１１１は、いわゆるパッケージソフトウェアとして提供することができる。ここで、リムーバブル記録媒体１１１としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。
なお、プログラムは、上述したようなリムーバブル記録媒体１１１からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク１０５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。
コンピュータは、CPU(Central Processing Unit)１０２を内蔵しており、CPU１０２には、バス１０１を介して、入出力インタフェース１１０が接続されている。
CPU１０２は、入出力インタフェース１１０を介して、ユーザによって、入力部１０７が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)１０３に格納されているプログラムを実行する。あるいは、CPU１０２は、ハードディスク１０５に格納されたプログラムを、RAM(Random Access Memory)１０４にロードして実行する。
これにより、CPU１０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU１０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース１１０を介して、出力部１０６から出力、あるいは、通信部１０８から送信、さらには、ハードディスク１０５に記録等させる。
なお、入力部１０７は、キーボードや、マウス、マイク等で構成される。また、出力部１０６は、LCD(Liquid Crystal Display)やスピーカ等で構成される。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備え、
前記第１の配信端末は、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
情報処理装置。
（２）
前記第１の配信端末は、前記クライアント端末が、近い将来取得の可能性があるセグメントを予測し、予測したセグメントのリクエストを受信して、前記第２の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD（Media Presentation Description）と、前記リクエストとを送信して、前記同期プリフェッチ依頼を行い、
前記第１の配信端末および前記第２の配信端末において、前記MPDおよび前記リクエストを参照して、前記クライアント端末において予測されたセグメントが事前に取得される
上記（１）に記載の情報処理装置。
（３）
前記第１の配信端末は、前記第２の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD（Media Presentation Description）を送信して、前記同期プリフェッチ依頼を行い、
前記第１の配信端末および前記第２の配信端末において、前記MPDが参照されて、前記クライアント端末が、近い将来取得の可能性があるセグメントが予測され、その予測されるセグメントが事前に取得される
上記（１）に記載の情報処理装置。
（４）
前記第１の配信端末は、前記クライアント端末が前記第２のネットワークへ遷移することを予知した場合、前記第２のネットワークにバインドされたホスト装置に対し、前記第２の配信端末の起動を行わせる
上記（１）から（３）までのいずれかに記載の情報処理装置。
（５）
前記第２のネットワークにバインドされた前記ホスト装置において前記第２の配信端末の起動が失敗した場合、前記第１の配信端末を維持したまま、前記第２のネットワークを介して前記クライアント端末に対する前記コンテンツのストリーミングが行われる
上記（４）に記載の情報処理装置。
（６）
前記クライアント端末の遷移先となる前記第２のネットワークが予測できない場合、複数の前記ホスト装置に対して前記第２の配信端末の起動を行わせる
上記（４）に記載の情報処理装置。
（７）
前記クライアント端末の遷移先において、複数の前記第２のネットワークが重複する場合、それぞれの前記第２のネットワークにバインドされた前記ホスト装置に対し、前記第２の配信端末の起動を行わせる
上記（４）に記載の情報処理装置。
（８）
前記第１の配信端末は、前記第２の配信端末に対して前記同期プリフェッチ依頼を行う際に、前記第２のネットワークのトラフィック予想に基づいて適応的にストリーム品質の異なるセグメントを選択させる
上記（１）から（７）までのいずれかに記載の情報処理装置。
（９）
第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備える情報処理装置が、
前記第１の配信端末によって、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
を含む情報処理方法。
（１０）
第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備える情報処理装置のコンピュータに、
前記第１の配信端末によって、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
を含む情報処理を実行させるためのプログラム。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
１１ 情報処理システム， １２ クラウド， １３ ユーザ端末， ２１ DASH-Client， ３１および３２ ME-Host， ３３ ME-Platform(Orchestrator)， ４１ Edge-DANE， ４２ データベース保持部， ４３ 記憶部， ５１ Origin-DANE， ５２ 記憶部， ６１ データベース保持部， ７１ ５Ｇコアネットワークシステム， ７２ アクセスネットワーク， ８１ データプレーン， ８２ アプリケーション， ８３ ME-Platform， ８４ UPF

Claims (10)

  1. 第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備え、
    前記第１の配信端末は、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行う
    情報処理装置。
  2. 前記第１の配信端末は、前記クライアント端末が、近い将来取得の可能性があるセグメントを予測し、予測したセグメントのリクエストを受信して、前記第２の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD（Media Presentation Description）と、前記リクエストとを送信して、前記同期プリフェッチ依頼を行い、
    前記第１の配信端末および前記第２の配信端末において、前記MPDおよび前記リクエストを参照して、前記クライアント端末において予測されたセグメントが事前に取得される
    請求項１に記載の情報処理装置。
  3. 前記第１の配信端末は、前記第２の配信端末に対し、前記コンテンツのメタデータが記述されたファイルであるMPD（Media Presentation Description）を送信して、前記同期プリフェッチ依頼を行い、
    前記第１の配信端末および前記第２の配信端末において、前記MPDが参照されて、前記クライアント端末が、近い将来取得の可能性があるセグメントが予測され、その予測されるセグメントが事前に取得される
    請求項１に記載の情報処理装置。
  4. 前記第１の配信端末は、前記クライアント端末が前記第２のネットワークへ遷移することを予知した場合、前記第２のネットワークにバインドされたホスト装置に対し、前記第２の配信端末の起動を行わせる
    請求項１に記載の情報処理装置。
  5. 前記第２のネットワークにバインドされた前記ホスト装置において前記第２の配信端末の起動が失敗した場合、前記第１の配信端末を維持したまま、前記第２のネットワークを介して前記クライアント端末に対する前記コンテンツのストリーミングが行われる
    請求項４に記載の情報処理装置。
  6. 前記クライアント端末の遷移先となる前記第２のネットワークが予測できない場合、複数の前記ホスト装置に対して前記第２の配信端末の起動を行わせる
    請求項４に記載の情報処理装置。
  7. 前記クライアント端末の遷移先において、複数の前記第２のネットワークが重複する場合、それぞれの前記第２のネットワークにバインドされた前記ホスト装置に対し、前記第２の配信端末の起動を行わせる
    請求項４に記載の情報処理装置。
  8. 前記第１の配信端末は、前記第２の配信端末に対して同期プリフェッチ依頼を行う際に、前記第２のネットワークのトラフィック予想に基づいて適応的にストリーム品質の異なるセグメントを選択させる
    請求項１に記載の情報処理装置。
  9. 第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備える情報処理装置が、
    前記第１の配信端末によって、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行うこと
    を含む情報処理方法。
  10. 第１のネットワークを介して、クライアント端末に対してコンテンツをストリーミングする第１の配信端末を備える情報処理装置のコンピュータに、
    前記第１の配信端末によって、前記クライアント端末が移動することにより前記第１のネットワークから第２のネットワークへのハンドオーバーが発生するのに伴って、前記第２のネットワークを介して前記クライアント端末に対して前記コンテンツをストリーミングする第２の配信端末に対し、前記第１の配信端末と同期した事前の読み込みを依頼する同期プリフェッチ依頼を行うこと
    を含む情報処理を実行させるためのプログラム。
JP2019021939A 2019-02-08 2019-02-08 情報処理装置および情報処理方法、並びにプログラム Pending JP2022051973A (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2019021939A JP2022051973A (ja) 2019-02-08 2019-02-08 情報処理装置および情報処理方法、並びにプログラム
PCT/JP2020/002455 WO2020162219A1 (ja) 2019-02-08 2020-01-24 情報処理装置および情報処理方法、並びにプログラム
CN202080011937.2A CN113383578A (zh) 2019-02-08 2020-01-24 信息处理装置、信息处理方法以及程序
US17/424,771 US20220070750A1 (en) 2019-02-08 2020-01-24 Information processing device, information processing method, and program

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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210095457A (ko) * 2020-01-23 2021-08-02 삼성전자주식회사 엣지 컴퓨팅 서비스를 위한 방법 및 장치

Family Cites Families (5)

* Cited by examiner, † Cited by third party
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 Ｖｉｄ衡器股份有限公司 增強無線網路應用QoE之頻寬預測及預取
US11172005B2 (en) * 2016-09-09 2021-11-09 Nokia Technologies Oy Method and apparatus for controlled observation point and orientation selection audiovisual content

Also Published As

Publication number Publication date
WO2020162219A1 (ja) 2020-08-13
US20220070750A1 (en) 2022-03-03
CN113383578A (zh) 2021-09-10

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
US11924650B2 (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
WO2019154283A1 (zh) 一种业务迁移的方法及装置
US11522933B2 (en) Information processing apparatus and information processing method
US20220400297A1 (en) Method and apparatus for multicast control of a live video stream
CN114531478A (zh) 边缘资源聚合的方法、设备和计算机程序产品
WO2020162219A1 (ja) 情報処理装置および情報処理方法、並びにプログラム
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
Chen et al. IEEE P1935 edge/fog manageability and orchestration: Standard and usage example
KR101402923B1 (ko) 캐시 장치에 사전 배포하는 콘텐츠를 관리하는 서버 및 방법, 그리고 캐시 장치
JP2022531346A (ja) 可変的な接続性を有するモバイル環境のためのマイクロキャッシュ方法及び装置
JP2004178472A (ja) プログラム取得方法およびその方法を利用可能なパケット転送装置
WO2021140949A1 (ja) コンテンツ配信システムおよびコンテンツ配信方法、並びにプログラム
US20240015212A1 (en) Methods and Systems for Ledger Based Content Delivery Using a Mobile Edge Computing (MEC) Server
KR101565137B1 (ko) 무선 스트리밍 서비스 제공 방법 및 장치