JP2022051975A - 情報処理装置および情報処理方法 - Google Patents

情報処理装置および情報処理方法 Download PDF

Info

Publication number
JP2022051975A
JP2022051975A JP2019022675A JP2019022675A JP2022051975A JP 2022051975 A JP2022051975 A JP 2022051975A JP 2019022675 A JP2019022675 A JP 2019022675A JP 2019022675 A JP2019022675 A JP 2019022675A JP 2022051975 A JP2022051975 A JP 2022051975A
Authority
JP
Japan
Prior art keywords
application
information processing
flus
executed
communication device
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
JP2019022675A
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 JP2019022675A priority Critical patent/JP2022051975A/ja
Priority to PCT/JP2020/003079 priority patent/WO2020166323A1/ja
Priority to US17/424,742 priority patent/US11522933B2/en
Priority to CN202080012193.6A priority patent/CN113383322A/zh
Publication of JP2022051975A publication Critical patent/JP2022051975A/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/80—Responding to QoS
    • 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/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication
    • 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/1069—Session establishment or de-establishment
    • 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/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1025—Dynamic adaptation of the criteria on which the server selection is based

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

【課題】アップリンクストリーミングをアダプディブに行う。【解決手段】情報処理システムにおいて、コンテンツアップリンクストリームのためのプロトコルネゴシエーションを行う通信モジュールが、プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトを、他の通信装置に送信し、他の通信装置から、Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報を受信し、他の通信装置との間で、コンテンツアップリンクストリームの制御プロトコルネゴシエーションを行う。本技術は、例えば、アップリンクストリーミングを行う通信システムに適用できる。【選択図】図３

Description

本開示は、情報処理装置および情報処理方法に関し、特に、アップリンクストリーミングをアダプディブに行うことができるようにした情報処理装置および情報処理方法に関する。
近年、一般ユーザによって生成されたUGC（User Generated Contents）コンテンツなどのストリームを配信するユースケースが増加している。これに伴い、ビデオエコシステムと呼ばれている配信プラットフォームにおいて、標準的なコンテンツ（ストリーム）アップリンクインターフェイスがサポートされていく可能性がある。
例えば、この様なユースケースにおいて、低コストのスマートフォンのカメラやビデオカメラなどが使用されるだけではなく、プロフェッショナルユースの業務用カメラで収録した多種多様なストリームをアップリンクすることも想定される。従って、ストリームアップリンクインターフェイスは、それらの全てにアダプディブに対応できるようにすることが求められる。
また、第５世代移動通信システム（以下、５Ｇと称する）への移行に伴い、今後、キャリア網やインターネット網などを経由してのプロフェッショナルユースの収録ストリームの超高品質なアップリンクが一般化することが想定される。さらに、スマートフォンや、デジタルスチルカメラ、ウェアラブル端末などのような、あらゆるキャプチャモバイルデバイスでのインスタントキャプチャおよび瞬間アップリンクが一般化することも想定される。従って、それらがクラウド上のメディア処理系において低遅延で処理されて、その後、配信系に展開されていくというクラウドネイティブなメディア処理環境がより強く求められることになる。
例えば、現在、ストリームキャプチャデバイスからクラウドへのアップロードインターフェイスとして、3GPP（Third Generation Partnership Project）において、FLUS（Framework For Live Uplink Streaming）のフレームワークが検討されている（例えば、非特許文献１および２参照）。
3GPP TS 26.238 V15.0.0(2017-12) 3rd Generation Partnership Project ; Technical Specification Group Services and System Aspects ; Uplink Streaming (Release 15) 3GPP TS 26.114 V15.1.0(2017-12) 3rd Generation Partnership Project ; Technical Specification Group Services and System Aspects ; IP Multimedia Subsystem(IMS) ; Multimedia Telephony ; Media handling and interaction (Release 15)
上述したように、多種多様なストリームをアップリンクするストリームアップリンクインターフェイスにおいて、あらゆるユースケースにアダプディブに対応することが求められている。
本開示は、このような状況に鑑みてなされたものであり、アップリンクストリーミングをアダプディブに行うことができるようにするものである。
本開示の一側面の情報処理装置は、コンテンツアップリンクストリームのためのプロトコルネゴシエーションを行う通信モジュールが、前記プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトを、他の通信装置に送信し、前記他の通信装置から、前記Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報を受信し、前記他の通信装置との間で、前記コンテンツアップリンクストリームの制御プロトコルネゴシエーションを行う。
本開示の一側面の情報処理方法は、コンテンツアップリンクストリームのためのプロトコルネゴシエーションを行う通信モジュールが、前記プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトを、他の通信装置に送信し、前記他の通信装置から、前記Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報を受信し、前記他の通信装置との間で、前記コンテンツアップリンクストリームの制御プロトコルネゴシエーションを行うことを含む。
本開示の一側面においては、プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトが、他の通信装置に送信され、他の通信装置から、Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報が受信され、他の通信装置との間で、コンテンツアップリンクストリームの制御プロトコルネゴシエーションが行われる。
本技術を適用した情報処理システムの利用が想定されるユースケースについて説明する図である。 情報処理システムとして想定される環境の詳細について説明する図である。 本技術を適用した情報処理システムの構成例を示すブロック図である。 第１の実施の形態における情報処理システムの第１の構成例を示す図である。 アップリンクストリーミングを開始する処理を説明する図である。 アップリンクプロトコルネゴシエーションについて説明する図である。 Serviceオブジェクトの構造の一例を示す図である。 ＠SessionDescriptionに格納されるCandidateDescription＠sdIdについて説明する図である。 CandidateDescription＠SessionDescriptionに格納されるSDP（Session Description Protocol）またはMPD（Media Presentation Description）について説明する図である。 アップリンクプロトコルネゴシエーションを実行する際のフローチャートである。 第１の実施の形態における情報処理システムの第２の構成例を示す図である。 各アプリケーションの依存関係を示す図である。 Workflow-Descriptionの一例を示す図である。 FLUS-Sinkから出力する際の記述例を示す図である。 トランスコード処理部へ入力する際の記述例を示す図である。 記憶装置へ入力する際の記述例を示す図である。 トランスコード処理部から出力する際の記述例を示す図である。 ディストリビューション処理部へ入力する際の記述例を示す図である。 アプリケーションオブジェクトについて説明する図である。 アップリンクストリーミングを開始する処理を説明する図である。 Workflow-Descriptionの記述例を示す図である。 各アプリケーションの連結を示す図である。 アップリンクプロトコルネゴシエーションについて説明する図である。 アプリケーションを起動するエンティティが、アプリケーションを起動する処理を説明するフローチャートである。 汎用リソースクラス識別子およびMECシステム依存リソースクラス識別子のマッピングの定義を示す図である。 MECシステム依存の辞書の項目の一例を示す図である。 リソースディスクリプションの一例を示す図である。 リソースディスクリプションにおけるResourceClass＠startTimeおよびResourceClass＠endTimeの記述例を示す図である。 アップリンクストリーミングを開始する処理を説明する図である。 アップリンクストリーミングを開始する処理を説明する図である。 Workflow-Descriptionの記述例を示す図である。 各アプリケーションの連結を示す図である。 第３の実施の形態における情報処理システムの構成例を示す図である。 KeepAlreadyEstablishedIfFialedについて説明する図である。 DoNotMigrateについて説明する図である。 FLUS-SinkおよびCache/PStorageアプリケーションの遷移について説明する図である。 Source RANからTarget RANへFLUS-Sourceの移動について説明する図である。 アップリンクストリーミングを開始する処理を説明する図である。 第４の実施の形態における情報処理システムの構成例を示す図である。 Source RANからTarget RANへFLUS-Sourceの移動について説明する図である。 アップリンクストリーミングを開始する処理を説明する図である。 ２つのターゲットME-Hostに遷移させるケースについて説明する図である。 Source RANからTarget RAN-AへFLUS-Sourceの移動について説明する図である。 アップリンクストリーミングを開始する処理を説明する図である。 耐障害性冗長度を確保する例について説明する図である。 Source RANからTarget RAN-AおよびTarget RAN-BへFLUS-Sourceの移動について説明する図である。 アップリンクストリーミングを開始する処理を説明する図である。 Workflow-Descriptionの記述例を示す図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜本技術の概要＞
まず、図１乃至図３を参照して、本技術の概要について説明する。
図１は、本技術を適用した情報処理システムの利用が想定されるユースケースについて説明する図である。
図１に示す構成例では、情報処理システム１１は、クラウド１２、複数の基地局１３、並びに、様々なユーザ端末１４の集合により構成されている。
クラウド１２は、複数のサーバがネットワークを介して接続されて構成され、それぞれのサーバが処理を実行することにより各種のサービスを提供する。例えば、図１に示すように、クラウド１２は、アップリンクサービスや、ディストリビューションサービス、プロダクションサービスなどを提供することができる。
複数の基地局１３（図１の例では、２つの基地局１３－１および１３－２）は、それぞれが通信可能な範囲としてカバーするセル内にあるユーザ端末１４と通信を行う。
様々なユーザ端末１４としては、例えば、図示するようなプロフェッショナルカメラやデジタルスチルカメラ、スマートフォン、ドローンなどを用いることができる。即ち、ユーザ端末１４は、ネットワークを介したストリームアップリンク機能を実装したモバイルネットワークキャプチャデバイスであり、動画像を撮影しながら基地局１３と通信を行って、クラウド１２にストリームをアップリンクすることができる。
そして、このように構成される情報処理システム１１において、アップリンクストリーミングにおけるプロトコルおよびリソースネゴシエーションをアダプディブに行えるようにすること（第１および第２の実施の形態）が求められる。
さらに、情報処理システム１１において、ユーザ端末１４が、例えば、基地局１３－１から基地局１３－２へと跨いでセルを移動する際に、基地局１３－１と基地局１３－２との間でハンドオーバーが行われる。このときに、途切れることなくアップリンクストリーミングを行えるようにすること（第３および第４の実施の形態）が求められる。ここで、シームレスなアップリンクとは、ユーザ端末１４が、動く被写体を撮影していて、その被写体とともにセルを跨って移動する場合であっても、ライブ撮影ストリームが途切れることなくストリーミングされるようにすることである。
具体的には、情報処理システム１１のユースケースとしては、マラソン等の長距離移動を伴うライブ中継が想定される。この様なライブ中継において、万が一、移動先のセルが混んでいるような環境であった場合、アップリンクストリーミングが途切れると、中継ができなくなってしまうことから、ストリームそのもののシームレスなアップリンクが求められる。また、アップリンクした後段の処理および配信を考慮した、キャプチャデバイス側で（もしくは、プロダクションサービス側の意向のもとでキャプチャデバイスを介して）の適切な制御が求められる。
図２を参照して、情報処理システム１１として想定される環境の詳細について説明する。
例えば、現状、上述の図１で説明したような情報処理システム１１で使用され得るネットワーク網としては、MEC（Multi-access Edge Computing）アーキテクチャが想定される。
MECアーキテクチャでは、まず、ユーザ端末１４に実装されているFLUS-Source２１が、基地局１３ごとに設けられるエッジサーバであるME（Multi-access Edge）-Host３１に実装されているFLUS-Sink４１と接続される。例えば、FLUS-Source２１は、アップリンクストリームを送信するクライアント上に実装されるストリーミング送信モジュールである。FLUS-Sink４１は、FLUS-Source２１からのアップリンクストリーミングを受信するサーバ上に実装されるストリーミング受信モジュールである。この際、FLUS-Sink４１の後段にはキャッシュや、ストレージ処理、トランスコード処理（図３参照）などが、MECアプリケーションとして実行されている。
そして、ユーザ端末１４が、基地局１３－１のセル内から、基地局１３－２のセル内に移動すると、基地局１３－１と基地局１３－２との間でハンドオーバーが発生する。この際、ユーザ端末１４が移動する前のセルとバインドされているMEC環境で実行されていたMECアプリケーションも同時に、ユーザ端末１４が移動した後のセルとバインドされているMEC環境に遷移されることになる。
つまり、ハンドオーバーが発生することにより、ME-Host３１－１のFLUS-Sink４１－１が、ME-Host３１－２のFLUS-Sink４１－２へと遷移する。このようにME-Host３１（MEC環境）を遷移させることによって、情報処理システム１１は、低遅延や負荷分散などのMECコンピューティングの利点を最大限に活かすことができる。
このとき、図２に示すように、基地局１３－１のセル内よりも、基地局１３－２のセル内に多数のユーザ端末１４が存在することも想定される。この場合、例えば、遷移前の基地局１３－１ではブロードバンド（ベースバンドまたはVisually Lossless）でのアップリンクが可能な環境であったが、遷移後の基地局１３－２ではナローバンド（Intra-GOP，Long-GOP）でしかアップリンクできないことが発生する。そこで、ユーザ端末１４の遷移において、その前後で可能な限りシームレスなアップリンクを可能とすることが求められる。
さらに、このような遷移の前後いずれにおいても、ディストリビューション状況を考慮した適応的なアップリンクを実現することにより、シームレスなアップリンクストリーミング制御を可能とすることが求められる。
そこで、以下で説明するように、本実施の形態において、上述した事前準備などのようなシームレスなアップリンクを実現するために必要なMECアーキテクチャで使用できる標準プロトコル（API：Application Programming Interface）およびフロー（シーケンス）を新たに提案する。
ここで、既知の技術となっている内容について説明する。
まず、ユーザ端末１４の近傍にあるME-Host３１－１において、そのユーザ端末１４に関連するサーバ側アプリケーションを実行するということは既知の技術である。ただし、動的な構成変更が伴った場合でも、ストリームの処理に関連するアプリケーション群の範囲をME-Platform側に伝えるという技術は既知ではない。
即ち、ME-Host３１において、ユーザ端末１４と直接会話するFLUS-Sink４１が、ME-Host３１上でFLUS-Sink４１の後段に存在するストリームの処理に関連するHostアプリケーション群の系列を定義したり、ME-Platformに周知したりする標準プロトコルはない。
また、ME-Host３１上において、例えば、ユーザ端末１４がME-Host３１－１とME-Host３１－２との間をハンドオーバーする際に、アプリケーションがマイグレーションするというのは既知の技術である。これに対し、マイグレート先のアプリケーション実行に必要なリソースネゴシエーションについては、標準プロトコルとしては規定されていない。
また、ETSI(European Telecommunications Standards Institute)でも一般的なアプリケーションの実行条件（スタティックなメモリやディスク上限値など）をME-Platformに登録するための枠組みは規定されている。しかしながら、アプリケーションの実行に、必要な要件をネゴシエーションするような技術は既知ではない。
ここで、本開示において新たに提案される内容について説明する。
まず、ユーザ端末１４の近傍にあるME-Host３１－１において、ユーザ端末１４上のFLUS-Source２１とFLUS-Sink４１－１とを接続する処理を行い、さらにその後段（例えばCloud１２）のメディアストリームの処理のサービス（アプリケーション）の実行を可能とする“Workflow-Description”を新たに定義することが提案される。そして、それらの処理が動的な構成変更にも対応できるよう、さらに、そのWorkflow-Descriptionの中に、メディアストリームの処理に関連するアプリケーション群の系列を情報として格納するWorkflow-Descriptionが新たに提案される。
また、FLUS-Sink４１の後段にあるアプリケーション群のME-Host３１間のマイグレーションの可否や、マイグレート先での実行時の条件（ストリーミングの品質やプロトコル）などを、FLUS-Source２１で制御できるようにWorkflow-Descriptionを定義することが新たに提案される。
具体的には、マイグレート先のリソースネゴシエーションに必要な条件をWorkflow-Descriptionに記載してFLUS-Source２１側の意思でネゴシエーションできるようにする。即ち、FLUS-Source２１側がWorkflow-Descriptionを指定して、マイグレーションに必要なリソースや期待する品質を宣言または通知でき、あらかじめ移動後のサービス品質を予想および担保することができるようにすることが新たに提案される。逆に、移動後のサービス品質を担保することができなければ、遷移前のリソースを維持することができるようにすることも新たに提案される。
また、Workflow-Descriptionの中に記載されているメディアストリームの処理に関連するアプリケーションごとに、その処理に必要なリソース評価指標のクラス分け（リファレンスシステムで実行してセットを定義）を情報として格納しておくことにより、リソースネゴシエーションを軽減することが提案される。即ち、期待するリソース量を数値で示すのではなく、MECシステム依存のクラス定義で行えるようにすることにより、Workflow-Descriptionの中に定義されるアプリケーションの実行条件を記述するリソースディスクリプションの指定の仕方の煩雑さを軽減できる。また、その該当クラスの特定を、あらかじめリファレンスのMECシステムで行うことによりクラス指定の精度を向上させることができる。
そこで、本実施の形態では、以下で説明するように、遷移先のセルが予測できる場合、即ち、遷移先のセルの混雑状況の予測ができる場合には、遷移先のセルに移動する前にあらかじめ移動後のリソースを予約するネゴシエーションが行われる。また、遷移先のセルにバインドされたME-Host３１上でFLUS-Sink４１（および後段処理）が稼働するためのCPUリソースや、記憶領域、IO（Input/Output）スループットなどの予約が行われる。さらに、遷移先のセルが同時に２つある場合、それらのカバレッジに階層関係があるときや、セル境界であることなどを条件とし、より有利なセルを選択して、シームレスにアップリンクできるようにする。また、遷移先のセルの予測ができない場合に、または、耐障害性冗長を確保するために、複数の隣接セルにバインドされたME-Host３１に、FLUS-Sink４１（および後段処理）を実行し、複数のアップリンクセッションを同期できるようにする。
図３は、本技術を適用した情報処理システムの構成例を示すブロック図である。
図３に示す情報処理システム１１において、クラウド１２は、アップリンクサービスを提供するME-Host３１－１乃至３１－３、および、ディストリビューションサービスおよびプロダクションサービスを提供するME-Host３２を備えて構成される。さらに、クラウド１２には、ME-Host３１－１乃至３１－３およびME-Host３２についての設定を統合的に行うME-Orchestrator３３も設けられる。
図３では、ユーザ端末（UE：User Equipment）１４が、ME-Host３１－１が設けられる基地局１３－１のセル内から、ME-Host３１－２が設けられる基地局１３－２、または、ME-Host３１－３が設けられる基地局１３－３（図示せず）のセルのうち、どちらか一方に移動する状態が示されている。なお、ME-Host３１－１乃至３１－３は、同様に構成されており、それらを区別する必要がない場合、単にME-Host３１と称し、ME-Host３１を構成する各部についても同様に称する。
ME-Host３１は、FLUS-Sink４１、データ保持処理部（Cache/PStorage）４２、トランスコード処理部４３、および、データベース保持部４４を備えて構成され、データ保持処理部（Cache/PStorage）４２は、記憶装置４５を有している。
ME-Host３２は、プロダクションネットワーク処理部５１、ディストリビューション処理部５２、およびデータベース保持部５３を備えて構成され、プロダクションネットワーク処理部５１は、記憶部５４を有している。
ME-Orchestrator３３は、データベース保持部６１を有しており、データベース保持部６１は、リアルタイムに、ME-Host３１および３２それぞれの稼働環境や識別情報などを管理するリソースデータベースを保持している。
＜第１の実施の形態における情報処理システムの第１の構成例＞
図４乃至図１０を参照して、第１の実施の形態における情報処理システムの第１の構成例として、アップリンクストリーミングにおけるプロトコルおよびリソースネゴシエーションについて説明する。例えば、第１の実施の形態における情報処理システムの第１の構成例では、FLUS-Source２１とFLUS-Sink４１との間のプロトコルネゴシエーションの際に、アップリンクに使用するWorkflow-Descriptionの選択のための優先度指定ができることが特徴となる。
図４には、第１の実施の形態における情報処理システム１１の第１の構成例として、５Ｇコアネットワークシステムファンクション群７１と、MEC環境であるME-Host３１におけるユーザ端末１４およびアプリケーション８２の間のセッションとが示されている。
例えば、情報処理システム１１では、エッジコンピューティングにおけるエッジサーバにより、従来のクラウドコンピューティングのボトルネックの１つである通信遅延を大幅に改善することができる。さらに、ユーザ端末１４、エッジサーバであるME-Host３１、および、クラウドサーバーであるME-Host３２（図３）の間で、高負荷なアプリケーションの分散処理を実行することで処理の高速化が可能となる。
なお、このエッジコンピューティングの標準仕様は”ETSI-MEC”において規定されている。そして、ETSI-MECにおけるME-Hostが、このエッジサーバであるME-Host３１に相当する。
図４に示す例では、ME-Host３１上のアプリケーション８２と、3GPPで標準化している５Ｇコアネットワーク７１のアクセスネットワーク７２を介したユーザ端末１４（上に実装されるアプリケーション）とを接続する線が、ユーザデータセッションを表している。なお、５Ｇコアネットワーク７１におけるアクセスネットワーク（(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のセッション管理）が示されている。
図５乃至図１０を参照して、プロトコルおよびリソースネゴシエーションについて説明する。
図５は、図４の情報処理システム１１において、アップリンクストリーミングを開始する処理を説明する図である。また、図５では、FLUS-Source２１とFLUS-Sink４１との間で行われる処理が中心に図示されている。
まず、FLUS-Sink起動処理が行われる。
FLUS-Sink起動処理は、FLUS-Source２１が開始して、ME-Platform８３との間で行われ、これにより、FLUS-Sink４１が起動する。また、FLUS-Sink起動処理の中の１つの処理として、FLUS-Sinkリソース予約/生成処理が行われる。FLUS-Sinkリソース予約/生成処理は、ME-Platform８３が開始してFLUS-Sink４１との間で行われ、これにより、FLUS-Sink４１のリソースが予約され、生成される。
具体的には、FLUS-Source２１が、ME-Platform８３が提供する当該ME-Host３２上で稼働するアプリケーションの稼働制御を行うAPIにアクセスする。そして、ME-Platform８３が、ME-Host３２上に必要なリソース（例えば、計算リソースやストレージリソースなど）を確保し、FLUS-Sinkアプリケーションの実行を要求する。これにより、FLUS-Sink４１が起動する。
また、FLUS-Sink起動処理が行われた後、アップリンクプロトコルネゴシエーション処理が行われる。
アップリンクプロトコルネゴシエーション処理は、FLUS-Source２１が開始して、FLUS-Sink４１との間で行われ、アップリンクストリーミングに利用するプロトコルネゴシエーションを行って、プロトコルが確定される。また、アップリンクプロトコルネゴシエーション処理の中の１つの処理として、アプリケーション群（アプリケーション８２）のためのリソース予約可否確認処理が行われる。アプリケーション群のためのリソース予約可否確認処理は、FLUS-Sink４１が開始して、ME-Platform８３との間で行われ、アプリケーション群のリソースの予約が可能か否かの確認が行われる。
そして、アップリンクプロトコルネゴシエーション処理が行われた後、FLUS-Source２１とFLUS-Sink４１との間でアップリンクストリーミングが行われる。
ここで、図６に示すように、アップリンクプロトコルネゴシエーションは、FLUS-Source２１からServiceオブジェクトをもとにFLUS-Sink４１と何度かやり取りすることにより行う。
例えば、Serviceオブジェクトは、FLUS-Source２１からFLUS-Sink４１へのアップリンクストリーミングサービスのセッションを管理するために必要な情報を格納しているオブジェクトであり、そこにはアップリンクプロトコルネゴシエーションの結果、選択されたCandidateDescriptionsから抽出された情報がSessionオブジェクトに格納される。このSessionオブジェクトには、ストリーミングサービスのセッションで利用するプロトコルや通信のためのフォーマット情報（Session Description）が格納され、さらには、後述するFLUS-Sink後段アプリケーション（例えば、図１１のアプリケーション８２）に関連する情報（WorkflowDescription）が含まれる。
具体的には、まず、Serviceオブジェクトには、CandidateDescriptionsオブジェクトとして、利用するプロトコルやフォーマットについて複数のCandidateDescriptionが候補として記載される。そして、FLUS-Source２１およびFLUS-Sink４１との両方で、この記載を変更することによりネゴシエーションのやりとり（オファー/アンサー交換）を行うことができる。
例えば、各候補であるCandidateDescriptionには、CandidateDescriptionそのものを識別するsdIdとともに、SessionDescriptionおよびWorkflowDescriptionが配置される。
SessionDescriptionは、ストリーミングプロトコルのメディアコンテナやトランスポートプロトコル等を記述するセッション記述ファイル（SDPまたはMPD）のurl（またはファイル本体）を格納する。WorkflowDescriptionは、そのストリーミングを処理するのに必要な、アプリケーション群やそれらの実行に要求されるネットワークリソースや、計算リソース、ストレージリソースなどを表す。さらに、それぞれのCandidateDescriptionに割り当てられる優先度は、CandidateDescriptionオブジェクトの列挙出現順序（例えば、上位に出現するほど優先度が高い）で表現する。この優先度は、何に基づいてもよく、例えば、ネットワーク帯域の状況に応じて決定されたり、FLUS-Source２１のネットワーク接続環境に基づいて、ネゴシエーションの中で割り当てられたりするようにしてもよい。
そして、FLUS-Source２１およびFLUS-Sink４１は、このCandidateDescriptionsに自身が期待する優先順位でCandidateDescriptionを列挙して、Service/CandidateDescriptionオブジェクトをやりとりすることによりネゴシエーションを行う。その後、候補が最終的に１つに決定されると、現在アクティブに確立されるセッションであることを示すSession ＠active=’true’のSessionオブジェクトの＠SessionDescriptionに、最終的に決定されたSession/CandidateDescription＠sdIdの値が格納されて、セッションが確立される。
図７には、Serviceオブジェクトの構造の一例が示されている。
図７に示すように、Serviceオブジェクトは、Serviceを識別するIDなどのようなService特有の属性群と、１つのCandidateDescriptions要素（その配下に複数のCandidateDescription要素群を持つ）とを持つ。
ここで、Serviceオブジェクト（ServiceID等を記述する）にセッション属性の格納に利用するSessionオブジェクトを含むということは既知である。これに対し、Serviceオブジェクト配下のCandidateDescriptions/CandididateDescription，CandididateDescription配下の＠sdId，＠SessionDescription，＠WorkflowDescription、および、Session＠activeは、本開示において新たに提案されるものである。
そして、ネゴシエーションが行われた後、図８に示すように、Session＠active=’true’の＠SessionDescriptionに、上記いずれかの確定したCandidateDescription＠sdIdが格納される。これにより、Session＠active=’true’は、ネゴシエーションが終わって確立されたストリーミングセッション、即ち、処理が開始されているストリーミングセッションを表すことになる。一方、Session＠active=’false(ディフォルト)’は、まだセッションが始まっていないこと、または、終了していることを示すことになる。
また、図９に示すように、CandidateDescription＠SessionDescriptionには、SDPまたはMPDのurlを格納する。または、このurlに替えて、SDPまたはMPDのファイル本体をbase64/urlエンコードしたものを格納してもよい。このとき、以下で説明するような第１乃至第３の格納方法を選択することができる。
例えば、第１の格納方法では、SDPファイルでRTP転送の場合の例として図示されている内容を、base64/urlエンコードしてSessionDescriptionに格納する。例えば、第１の格納方法は、アップリンクのネットワークリソースが潤沢で、かつ、遅延が許容されない場合で、プロダクション処理系に直接接続する場合に選択することが好適である。このとき、RTP転送の場合のスタック構成は、図示するような構成となる。
また、第２の格納方法では、SDPファイルでFLUTE（File Delivery over Unidirectional Transport）転送の場合の例として図示されている内容を、base64/urlエンコードしてSessionDescriptionに格納する。例えば、第２の格納方法は、アップリンクのネットワークリソースに制限があり、遅延が許容されない場合に選択することが好適である。このとき、FLUTE転送の場合のスタック構成は、図示するような構成となる。
また、第３の格納方法では、MPDファイルでHTTP転送の場合の例として図示されている内容を、base64/urlエンコードしてSessionDescriptionに格納する。なお、HTTPの種類には、HTTPや、HTTP/2，HTTP/3がある。例えば、第３の格納方法は、アップリンクのネットワークリソースに制限があり、配信系と親和性の高いフォーマットを維持する場合に選択することが好適である。このとき、HTTP転送の場合のスタック構成は、図示するような構成となる。
ここで、RTP転送の場合のスタック構成で用いられているSMPTE2022は、従来の放送機器間の非圧縮映像および音声伝送方式であるSDI(Serial Digital Interface)をIPパケットに格納して伝送するプロトコルである。同様に、SMPTE2110は、各映像/音声コンポーネントを個別のストリームとしてPTP(Precision Time Protocol)同期して伝送するプロトコルである。
また、上述したFLUTEは、マルチキャストにおけるファイル転送プロトコルである。例えば、FLUTEは、転送するファイルの転送制御属性を記述するFDT(File Delivery Table)と、LCT(Layered Coding Transport)と呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルの組み合わせにより構成される。従来のFLUTEは、主に非同期型のファイル転送に利用するために開発されたが、次世代放送規格であるATSC3.0において、ブロードキャストライブストリーミングにも適用しやすくするための拡張が行われた。この拡張仕様がROUTEと呼ばれているが、これは、従来のリアルタイムストリーミングに適用されてきたRTPに置き換わり、放送型のDASH-fragmentedMP4(fMP4)ストリーミングのトランスポートに最適化されている。なお、ROUTEにおけるFDTに相当する転送制御メタデータをS-TSID(Service-based Transport Session Instance Description)と呼ぶ。
また、上述したHTTP/3は、Webアクセスに使われるプロトコルであるHTTP（Hypertext Transfer Protocol）の新しいバージョンである。HTTP/3の特徴は、トランスポート層のプロトコルとしてUDPを利用している点である。従来のHTTPは、TCPを利用する代表的な通信プロトコルの１つだったのに対し、HTTP/3は、TCPではなくUDPを利用することで、Webアクセスの高速化を実現する。なお、HTTPでは、HTTP/1.1というバージョンが広く使われているが、通信効率を改善したHTTP/2もある。HTTP/2は、例えば、OTT（Over The Top）と呼ばれるサービス事業者によって主に利用されている。
図１０には、アップリンクプロトコルネゴシエーションを実行する際のフローチャートが示されている。
ステップＳ１１において、FLUS-Source２１は、Serviceオブジェクトを生成し、FLUS-Sink４１へオファーを送信する。このとき、FLUS-Source２１は、図９を参照して説明した、第１の格納方法、第２の格納方法、および第３の格納方法の順でオファーを送信する。なお、Serviceオブジェクトの＠workflowDescriptionについては、後述する第２の実施の形態で説明する。
その後、FLUS-Sink４１およびME-Platform８３により、アプリケーション群のリソース予約についての可否の確認が行われる。
ステップＳ１２において、FLUS-Sink４１は、優先順位の高い順に、ME-Platform８３に対して、workflowDescriptionに記載されているアプリケーション毎のリソース予約可否を確認する。そして、FLUS-Sink４１は、ステップＳ１１で送信されてきたServiceオブジェクトに記載されている複数の候補のCandidateDescriptionの中から、選択したCandidateDescriptionを確定する。
ステップＳ１３において、FLUS-Sink４１は、Serviceオブジェクトを更新し、FLUS-Source２１へアンサーとなるServiceオブジェクトを送信する。例えば、ステップＳ１２においてsdId=’2’と確定していた場合、ServiceオブジェクトはSession ＠sessionDescription=’2’と更新される。
＜第１の実施の形態における情報処理システムの第２の構成例＞
図１１乃至図２８を参照して、第１の実施の形態における情報処理システム１１Ａの第２の構成例として、アップリンクストリーミングにおけるプロトコルおよびリソースネゴシエーション（FLUS-SINK後段アプリケーションを含む）について説明する。
なお、この第２の構成例では、「アップリンクにFLUSを用いてAdaptiveに行える用にする、その際、アップリンク確立のためのプロトコルネゴシエーションに課題があるので、それを解決するメソッドの提案」のうち、「アップリンクするメディアストリームの処理に関わる、エッジHostで実行されるアプリケーション群のWorkflow-Description」について説明する。例えば、プロトコルネゴシエーションは一般に、プロトコル種（とそのパラメタ値）を列挙して行われるものである。これに対し、そこに受信後の後段のアプリケーションのフローとリソース要件をバインドした、「プロトコル属性+後段アプリケーションフローのリソース要件」を列挙してネゴシエーションの材料とすることを新たに提案する。また、WorkflowDescriptionは、後段のアプリケーションのフローとリソース要件を記載するものとなる。
図１１には、第１の実施の形態における情報処理システム１１Ａの第２の構成例が示されている。
例えば、情報処理システム１１Ａでは、ユーザ端末１４の近傍にあるME-Host３１において、ユーザ端末１４上のFLUS-Source２１と接続するFLUS-Sinkアプリケーション４１Ａが実行される。そして、付随する”Workflow-Description”で定義される、その後段のメディア処理のサービス（アプリケーション８２－１乃至８２－Ｎ）が実行されることが特徴となる。また、情報処理システム１１Ａでは、Workflow-Descriptionに必要なリソース条件を記載して、FLUS-Source２１側の意思でネゴシエーションすることができる。また、情報処理システム１１Ａでは、リソース条件の記述にプロファイル（アプリケーションの実行に必要なリソースのクラス）を定義してリソースネゴシエーションの簡素化が図られる。
一般に、プロトコルネゴシエーションは、送受信モジュールの間のプロトコル種（とそのパラメタ値）を列挙して行われるものである。さらに、そこに受信後の後段のアプリケーションのフローとリソース要件をバインドした、「プロトコル属性+後段アプリケーションフローのリソース要件」を列挙してネゴシエーションの材料とする点が、本開示において新たに提案されるものである。
図１１に示すように、情報処理システム１１Ａは、FLUS-Sinkアプリケーション４１Ａの後段に複数のアプリケーション８２－１乃至８２－Ｎが連なった構成となっている。そして、情報処理システム１１Ａでは、FLUS-Sinkアプリケーション４１Ａがアップリンク受信したストリームが、ME-Host３１Ａ上で実行されるアプリケーション８２－１乃至８２－Ｎによって処理される。
例えば、FLUS-Sinkアプリケーション４１Ａの後段のアプリケーション８２－１乃至８２－Ｎとしては、キャッシュ/ストレージアプリケーションや、トランスコードアプリケーションなどがある。
キャッシュ/ストレージアプリケーションは、入力されたストリームをメモリやSSD（Solid State Drive）などのストレージにファイルとして保存するアプリケーションである。例えば、キャッシュ/ストレージアプリケーションは、I/Oスループットや耐障害性要件の違いにより様々なクラスのストレージを抽象化する機能を提供する。
トランスコードアプリケーションは、入力されたストリームの符号化方式を変更するアプリケーションである。例えば、トランスコードアプリケーションは、ネットワーク環境が悪いためIntraGOPでしかアップリンクできなかったストリームをプロダクション等の処理系に親和性のあるベースバンド（またはVisuallyLossless）フォーマットに変換したりする。なお、現在、こういったメディア処理系のアプリケーションがクラウド上のサービス（マイクロサービス等と呼ばれる）として提供されていく流れが加速している。そして、オンプレミスで稼働していた高価なプロフェッショナル用メディア処理機器で提供されていた機能が、クラウド上のネットワークサービスとして、必要な時に必要な分だけ利用できる環境が整備されるようになることが想定される。
そして、これらのアプリケーション群の一連の処理の順序や入出力のパラメタ等を記述するファイルが、Workflow-Descriptionと称される。以下のメディア処理のWorkflow-Descriptionの記述方法は、本開示において新たに提案されるものである。つまり、Workflow-Descriptionに、関連するアプリケーションを列挙するということ、シーケンスの記述の仕方に逐次処理と並行処理とを区別できるというところは既知であるのに対し、各々のアプリケーションの入出力パラメタの記述の仕方および遅延限界属性については、新たに提案されるものである。
図１２および図１３を参照して、ワークフローの記述例について説明する。
図１２には、FLUS-Sinkアプリケーション４１Ａの後段のアプリケーション８２－１乃至８２－Ｎの依存関係が示されており、図１３には、独自定義のWorkflow-Descriptionの一例が示されている。ここで、独自定義としているが、クラウド上のメディア処理のワークフローとそのアプリケーションのフレームワークについては、現時点で、MPEG-I-NBMP（Network-Based Media Processing）で仕様策定中であり、仕様は確定されていない。なお、類似の標準として、既にMPEG-Mがある。
例えば、図１２に示すように、FLUS-Sinkアプリケーション４１Ａの後段のアプリケーション８２－１乃至８２－Ｎとして、トランスコードアプリケーション（Transcode）、キャッシュ/ストレージアプリケーション（Cache/PStorage）、ストリーム配信系アプリケーション（Distribution）とがある。そして、これらの間には、図示するような依存関係（シーケンス）があるものとする。
そして、図１３に示すように、例えば、workflow要素のstartTime属性は、スケジュールがあらかじめ定まっている場合のワークフローの処理開始の絶対時刻（ウォールクロックタイム）を示す。なお、処理の開始時刻に制限がない場合（ベストエフォートで処理が可能な場合）は、この属性は記載しない。
また、workflow要素の子要素としてseq要素またはpar要素を配置することができる。seq要素は、その配下の要素で示されるアプリケーションの逐次処理を表し、par要素は、その配下の要素で示されるアプリケーションの逐次処理または並行処理を表す。
まず、Seq要素下の最初の要素は、url属性値’FLUS-Sink-url’を持つApplication要素であり、起点となるFLUS-Sinkアプリケーションの実行を表す。その後に、par要素があるが、par要素下には、url属性値’Transcode-url’を持つApplication要素と、url属性値’Cache/PStorage-url’を持つApplication要素がある。これら２つのアプリケーション（Transcodeアプリケーション、Cache/PStorageアプリケーション）が、図１２に示したように並行して処理されること、即ち、時間的に同期しながら処理されることを表す。
さらに、par要素の後には、url属性値’Distribution-url’を持つApplication要素があり、このアプリケーション（Distributionアプリケーション）が、図１２に示したように最後に実行されることを表す。それぞれのApplication要素にはdelayLimit属性があり処理の遅延リミット（入力の最初の先頭ビットが出力完了するまでの遅延の最大許容値(msec)）を指示することができる。
このワークフローの処理の対象となるデータはアップリンクされるストリームであり、url属性値’FLUS-Sink-url’を持つApplication要素で表されるFLUS-Sinkアプリケーションの入力となる。即ち、このFLLUS-Sinkアプリケーションの入力ストリームの属性は、このFLUS-Sinkアプリケーションがアップリンクストリーミングセッションを確立するFLUS-Source２１との間でアップリンクプロトコルネゴシエーションされた後、ApplicationオブジェクトのSession＠active=’true’であるSession要素のSessionDescription属性に格納されるsdId値（確定されたCandidateDescription＠sdIdの値）で示されるCandidateDescriptionのSessionDescriptionのurlで参照されるSDPまたはMPDで示されるものとする。または、このurlに替えて、SDPまたはMPDのファイル本体をbase64/urlエンコードしたもので示されるものとしてもよい。
そして、FLUS-Sinkアプリケーションが受信したアップリンクストリームは、FLUS-Sinkアプリケーションの出力として、Transcodeアプリケーション、Cache/PStorageアプリケーションの入力として引き継がれる。即ち、FLUS-Sinkアプリケーションの出力は、url属性値’FLUS-Sink-url’を持つApplication要素のOutputDescription属性で示され、これはurl属性値’Transcode-url’を持つApplication要素と、url属性値’Cache/PStorage-url’を持つApplication要素のInputDescription属性と等しくなる。
また、url属性値’FLUS-Sink-url’を持つApplication要素のOutputDescription属性には、例えば、図１４に示すような記述テンプレートに基づいて対象ストリームとその属性を特定する。なお、FLUS-Sink４１の場合は、アップリンクストリームを受信してそのまま後段のアプリケーションに引き渡すだけなのでストリームの属性に変更はなく、必要に応じてurl等のアドレスの類が変更されることがあるだけである。
ここで、上述のWorkflowの記述方法において、Seqの要素で逐次処理を記述し、Parの要素で並行処理を記述する方法は既知である。これに対し、アプリケーション毎における入出力の記述や、必要リソース記述を付記することは、本開示において新たに提案されるものである。また、図１４乃至図１８に示すように定義する、各Applicationの入出力の記述方法も、本開示において新たに提案されるものである。
図１４には、FLUS-Sink４１（FLUS-Sinkアプリケーション４１Ａ）の出力における記述方法の一例を示す図である。
図示するように、FLUS-Sink４１の後段処理へのストリームの属性は、出力用MPDまたはSDPに記載する。
なお、MPD（または、ROUTEの場合にはS-TSID）内に複数のストリームが含まれる場合には、XPathで、そのうち１つのストリームが特定される。このXPathについては、図１５乃至図１８においても同様である。
図１５には、トランスコード処理部４３（複数のアプリケーション８２のうちの１つのTranscodeアプリケーション）の入力における記述方法の一例が示されている。
図示するように、トランスコード処理部４３に入力されるInputDescriptionは、FLUS-Sink４１から出力されるOutputDescription（図１４）と同一の内容となる。
図１６には、データ保持処理部（Cache/PStorage）４２（複数のアプリケーション８２のうちの１つのCache/PStorageアプリケーション）の入力における記述方法の一例が示されている。
図示するように、トランスコード処理部４３と同じストリームを引き渡されるデータ保持処理部（Cache/PStorage）４２に入力されるInputDescriptionも、FLUS-Sink４１から出力されるOutputDescription（図１４）と同一の内容となる。さらに、データ保持処理部（Cache/PStorage）４２の場合には、記憶装置４５であるストレージ（オンメモリ、または、SSDやハードディスクなど）内に保持する格納期限として、絶対時刻指定を指定すること、または、入力時刻からの相対時刻指定を指定することができる。なお、期限を切って消去する場合には、input記述の格納期限に指定することができる。
また、データ保持処理部（Cache/PStorage）４２は、入力されたストリームを記憶装置４５に格納する処理を行うのみであるため、ストリームを引き継ぐアプリケーションの指定がない。即ち、記憶装置４５に格納されたストリームファイルは、そのCache/PStorageシステムを実現するWebサーバやファイルシステムなどが提供するファイルアクセス方法により、他のアプリケーションが必要に応じて、それらファイルの格納期限内にアクセスして取得される。
一方、トランスコード処理部４３は、入力されたストリームをトランスコード処理する際に、そのトランスコード処理後のストリームの属性が、MPDやSDP等の当該ストリームの属性により指定されるものとする。そして、図１７に示すように、トランスコード処理部４３から出力されるOutputDescriptionに指定する。なお、トランスコード後のストリームの属性は、出力用MPDまたはSDPに記載する。
図１８には、ディストリビューション処理部５２（複数のアプリケーション８２のうちの１つのDistributionアプリケーション）の入力における記述方法の一例が示されている。
トランスコード処理部４３が出力したトランスコード済みストリームは、ディストリビューション処理部５２の入力として引き継がれる。すなわち、トランスコード処理部４３から出力されるOutputDescriptionは、url属性値’Distribution-url’を持つApplication要素のInputDescription属性と等しく、さらに、配信期限を指示することもできる。
そして、ディストリビューション処理部５２は、入力されたストリームを、クラウドを介してクライアントデバイスに配信する処理を行うため、OutputDescriptionはない。即ち、配信システムを実装するWebサーバやストリームサーバなどが提供するストリームアクセス方法により、クライアント側が配信期限内に取得して受信する。なお、期限を切って配信をとりやめる場合には、input記述の配信期限に指定することができる。
図１９には、上述したようなFLUS-Sinkアプリケーション４１Ａや、アプリケーション８２－１乃至８２－Ｎ（Transcodeアプリケーション、Cache/PStorageアプリケーション、Distributionアプリケーション）などのアプリケーション属性を表現するアプリケーションオブジェクトの一例が示されている。例えば、アプリケーションオブジェクトの属性定義は、ME-Platformにて管理され、その属性定義に基づいて、各々のアプリケーションの個別の属性が管理されるものとする。
アプリケーションURL（+プロバイダーURL）は、Transcodeアプリケーションや、Cache/PStorageアプリケーション、Distributionアプリケーションなどの種類を識別（+オプションでプロバイダーURLも識別）する。例えば、ワークフローに記述されるApplication＠urlにて指定される。
インスタンスURIは、アプリケーションの実行時にアプリケーションを識別し、アプリケーションの実行時にME-Platformにより生成される。
MECシステム-URI、バージョンは、アプリケーションが実行されるMECシステム（仮想環境）を識別する識別子である。
インプット記述およびアウトプット記述は、アプリケーションの入出力のurlやプロトコルなどを記述し、例えば、WorkflowDescriptionに記述されるApplication/InputDescriptionや/OutputDescriptionなどにて指定される。概要記述は、アプリケーションの処理の概要を記述する。
リソース要件には、仮想CPU使用量/秒+期間や、仮想メモリ/ストレージ容量/秒+期間、IOスループット/秒+期間等数値指定などがあり、MECシステムURL依存のリソースクラスIDにより定義される。例えば、WorkflowDescriptionに記述されるResourceDescriptionにより指定される。
アプリケーションパッケージ（URL、イメージ本体）は、MECシステム依存のアプリケーション実行イメージのurl、または、そのイメージ本体である。
トラフィック/DNSルール（フィルター/DNSレコード）は、ME-Platformを介して５Ｇシステムにおけるパケットのルーティングを制御する情報である。
図２０乃至図２４を参照して、図１１の情報処理システム１１Ａのように、同一のME-Host３１内において、FLUS-Sinkアプリケーション４１Ａの後段にアプリケーション８２が連結される構成における処理について説明する。
図２０は、図１１の情報処理システム１１Ａにおいて、アップリンクストリーミングを開始する処理を説明する図である。即ち、図２０は、FLUS-Sinkアプリケーション４１Ａの後段のアプリケーション８２が、FLUS-Sinkアプリケーション４１と同一のME-Host３１において実行される場合に、アプリケーション８２を起動する処理の一例が示されている。
まず、FLUS-Sink起動処理が行われる。
FLUS-Sink起動処理は、FLUS-Source２１が開始して、ME-Platform８３との間で行われ、これにより、FLUS-Sinkアプリケーション４１Ａが起動する。また、FLUS-Sink起動処理の中の１つの処理として、FLUS-Sinkリソース予約/生成処理が行われる。FLUS-Sinkリソース予約/生成処理は、ME-Platform８３が開始してFLUS-Sinkアプリケーション４１Ａとの間で行われ、これにより、FLUS-Sinkアプリケーション４１Ａのリソースが予約され、生成される。
また、FLUS-Sink起動処理が行われた後、アップリンクプロトコルネゴシエーション処理が行われる。
アップリンクプロトコルネゴシエーション処理は、FLUS-Source２１が開始して、FLUS-Sinkアプリケーション４１Ａとの間で行われ、アップリンクストリーミングに利用するプロトコルネゴシエーションが行われる。また、アップリンクプロトコルネゴシエーション処理においては、FLUS-Sinkアプリケーション４１ＡがFLUS-Source２１とやりとりするServiceオブジェクトに記載されるCandidateDescriptionのWorkflow-Descriptionが解析される。
例えば、このWorkflow-Descriptionは、図２１に示すように記述され、このWorkflow-Descriptionでは、図２２に示すように、FLUS-Sinkの出力がProductionアプリケーションに連結されている。
例えば、図２１に示されているWorkflow/Seq/Application[＠url=’FLUS-Sink-url’]/ResourceDescription（Workflow要素配下のSeq要素配下の、Application要素の属性urlの値が’FLUS-Sink-url’であるApplication要素の配下のResourceDescription要素）に記述されるFLUS-Sinkアプリケーションの必要リソースは、FLUS-Source２１が起点となるFLUS-Sink起動処理において参照される。
また、FLUS-Source２１からのFLUS-Sink起動依頼を受けたME-Platform８３は、このResourceDescriptionに記載されるリソース要件を満たされるか否かを自身のME-Host３１上でチェックする。そして、ME-Platform８３は、充足できる場合には、新たなFLUS-Sinkアプリケーション４１Ａを生成して、そのFLUS-Sinkアプリケーション４１ＡのアドレスをFLUS-Source２１に返す。
そして、例えば、図２３に示すように、FLUS-Source２１とFLUS-Sink４１との間でアップリンクプロトコルネゴシエーションが行われる。
まず、FLUS-Sinkアプリケーション４１Ａが、FLUS-Source２１から受信したSessionオブジェクトのCandidateDescritionsの個々のCandidateDescriptionのWorkflow-Descriptionを優先度順に解析する。これにより、FLUS-Sinkアプリケーション４１Ａは、その後段のアプリケーション８２－１乃至８２－Ｎのそれぞれに必要なリソースが確保できるか確認する。
例えば、図２０における処理の場合、FLUS-Sinkアプリケーション４１Ａが、複数のアプリケーション８２のうちの１つとしてProductionアプリケーション起動フェーズを開始する。そして、ME-Platform８３が提供するAPIにアクセスして、Workflow/Seq/Application[＠url=’Production-url’]/ResourceDescriptionに記載されるリソースを確保する。これにより、FLUS-Sinkアプリケーション４１Ａは、複数のアプリケーション８２のうちの１つとして、Productionアプリケーションを起動することができる。
そして、アップリンクプロトコルネゴシエーション処理が行われた後、FLUS-Source２１とFLUS-Sinkアプリケーション４１Ａとの間でアップリンクストリーミングが行われるとともに、Productionアプリケーションによってプロダクション処理が行われる。
図２４は、アプリケーションを起動するエンティティが、アプリケーションを起動する処理を説明するフローチャートである。
例えば、起動対象のアプリケーションがFLUS-Sinkアプリケーション４１Ａである場合には、起動するエンティティはFLUS-Source２１となる。また、起動対象のアプリケーションがWorkflow-Descriptionに記載の各アプリケーションである場合には、起動するエンティティはFLUS-Sinkアプリケーション４１Ａとなる。
ステップＳ２１において、アプリケーションを起動するエンティティは、アプリケーション定義に従ってアプリケーションオブジェクトを生成し、ME-Platform８３に対してアプリケーションの実行を依頼する。このとき、アプリケーションを起動するエンティティが送信するアプリケーションオブジェクトのリソース要件には、Workflow-DescriptionのResourceDescriptionに記述される必要リソース要件が格納される。
ステップＳ２２において、ME-Platform８３は、アプリケーションオブジェクトの内容に基づいて、アプリケーションを実行する前に、計算リソース、メモリ/ストレージ、ネットワークリソースなどのアプリケーション実行に必要となる諸々のリソースの確保を試みる。
ステップＳ２３において、ME-Platform８３は、ステップＳ２２で試みたリソースを確保することができたか否かを判定する。
ステップＳ２３において、ME-Platform８３が、リソースを確保することができたと判定した場合、処理はステップＳ２４に進む。
ステップＳ２４において、ME-Platform８３は、アプリケーションオブジェクトのアプリケーションインスタンスを識別するインスタンスIDを生成し、アプリケーションを実行する。
ステップＳ２５において、ステップＳ２４でME-Platform８３が実行することで起動された起動対象のアプリケーションは、その入力記述に従って入力オブジェクト（ファイルやストリームなど）を待ち受けて、処理を待機する。そして、起動対象のアプリケーションは、入力オブジェクトを受信すると、処理を開始する。
一方、ステップＳ２３において、ME-Platform８３が、所望のリソースを確保することができなかったと判定した場合、ステップＳ２６に進む。そして、ME-Platform８３は、アプリケーションを起動するエンティティに対するNACK応答を行って、リソース確保に失敗したアプリケーションオブジェクトを送信する。
ステップＳ２７において、アプリケーションを起動するエンティティは、アプリケーションに複数のResourceDescriptionがある場合には、アプリケーションオブジェクトのリソース要件パートを書き換えて、ME-Platform８３に対して再度実行を依頼する。そして、処理はステップＳ２１に戻って、その書き換えられたアプリケーションオブジェクトが送信され、以下、同様処理が、これをデッドラインとして設定されたタイムリミットになるまで繰り返される。なお、このタイムリミットを超過した場合には、アプリケーション起動失敗となる。
そして、起動対象のアプリケーションが起動した後、FLUS-Source２１からアップリンクストリーミングが開始され、FLUS-Sinkアプリケーション４１Ａは、受信したストリームをProductionアプリケーションに引き渡してProduction処理が行われる。
なお、後述する第３および第４の実施の形態では、アプリケーションを起動するエンティティがSourceMEHostのFLUS-Sink４１Ｓである場合、起動対象のアプリケーションTargetMEHostのFLUS-Sink４１Ｔとなる。
図２５乃至図２８を参照して、アプリケーション毎のリソース記述について説明する。
例えば、Workflow-Descriptionの各アプリケーションのResourceDescriptionには、アプリケーション毎の実行に必要なリソースが記述される。一般に、アプリケーションの実行に必要なリソースとしては、
・CPU使用量/秒+期間(時間/絶対時刻指定)
・メモリ/ストレージ容量/秒+期間(時間/絶対時刻指定)
・IOスループット/秒+期間(時間/絶対時刻指定)
等が挙げられる。
しかしながら、これらの数値表現によりアプリケーション毎にリソースを予約するのは非常に煩雑になることが想定される。そこで、これらをいくつかのセットにまとめてプロファイリングのための辞書を定義することによって、Workflow-Descriptionのリソース記述の簡易化を図ることができる。例えば、辞書は、MEC環境を提供するベンダーに依存しない汎用的なものであれば、異なるベンダーからのMEC環境の違いに依存させないでMEC環境透過に指定することができる。
さらに、汎用リソースクラス識別子‘urn:generic_resource_class:class-x’により、上記のセットを参照できるようにする。または、MECシステム依存の辞書を用意して、MECシステム識別子およびMECシステム依存リソースクラス識別子のセットを、‘urn:vendor_specific_resource_class:vendor_x:class-x’のように表現してもよい。
このような表現の両方とも運用する場合には、図２５に示すようなマッピングを定義しておく。即ち、汎用リソースクラス識別子とMECシステム依存リソースクラス識別子との等価なセットどうしを定義しておく。
また、図２６に示すように、MECシステム依存の辞書の項目には、対応するCPU使用量/秒+期間、(揮発性-)メモリ/(永続的-)ストレージ容量/秒+期間、および、IOスループット/秒のセットを定義しておく。そして、これらの項目と、時間（時間間隔、または、開始絶対時刻/終了絶対時刻）との組み合わせにより、リソースを表現する。さらに、項目名’class-1‘や’class-11’等は、アップリンクストリーミングのユースケースに典型的な値で表現する。
具体的には、AVC-UHDTV(4K,10,4:2:2)-LongGOP-DASHでは、200Mbpsにて4K(3840×2160)-UHDTV(10bit/4:2:2)ストリームをAVCエンコードして数フレーム(LongGOP)DASH/CMAFにてストリームするユースケースを示す。なお、このストリームを永続ストレージ上のキャッシュに保持するユースケースは、AVC-UHDTV(4K,10,4:2:2)-LongGOP-DASH-onPStorageで示す。また、AVC-UHDTV(4K,10,4:2:2)-AllIntra-DASHでは、600Mbpsにて1フレーム(IntraGOP)DASH/CMAFによりストリームするユースケースを示す。なお、このストリームを永続ストレージ上のキャッシュに保持するユースケースは、AVC-UHDTV(4K,10,4:2:2)-AllIntra-DASH-onPStorageで示す。
そして、これらの典型的な代表的なプロトコルセットおよびパラメタ値をもとに、それぞれの対象MECシステムごとに、適当なリファレンスストリームを用いて概略的に実測しておくことにより、あらかじめ定義しておく。
図２７には、リソースディスクリプションの一例が示されている。
図２７に示すように、ResourceClass＠idは、上述の図２５に示したような汎用リソースクラス識別子やMECシステム依存リソースクラス識別子などを指定する。また、ResourceClass＠tは、それを維持する時間（sec）を示す。
さらに、実行される時間が絶対時刻上の開始および終了を持つ場合には、図２８に示すように、その開始時刻がResourceClass＠startTimeで示され、その終了時刻がResourceClass＠endTimeで示される。この例は、１ＴＢ（terabyte）のストレージをstartTimeからendTimeまで確保するということを示している。
＜第２の実施の形態＞
図２９乃至図３２を参照して、第２の実施の形態として、異なるME-Host３１に、FLUS-Sink４１の後段のアプリケーション８２が連結される場合（ME-Host３１のリソースが十分でない場合）の例について説明する。
即ち、第２の実施の形態では、FLUS-Sink４１の後段のアプリケーション８２の必要なリソースが確保できないときに、リソース要件を満たす複数のME-Host３１上でアプリケーション８２が実行されることが特徴となる。
図２９は、ME-Host３１上の計算リソースやストレージリソース等の制限により、ProductionアプリケーションをFLUS-Sink４１が実行されているME-Host３１上で実行できない場合において、アップリンクストリーミングを開始する処理を説明する図である。
この場合、図２９に示すように、ME-Platform８３が、複数のME-Host３１から最適なME-Host３１を探して、Productionアプリケーションを実行するものとする。また、ME-Platform８３は、図３に示したようなME-Orchestrator３３としての機能、即ち、複数のME-Host３１をコーディネートする役割を備えている。
まず、FLUS-Sink起動処理が行われる。
FLUS-Sink起動処理は、FLUS-Source２１が開始して、ME-Platform８３との間で行われ、これにより、FLUS-Sink４１が起動する。また、FLUS-Sink起動処理の中の１つの処理として、FLUS-Sinkリソース予約/生成処理が行われる。FLUS-Sinkリソース予約/生成処理は、ME-Platform８３が開始して、FLUS-Sink４１のリソースが予約され、生成される。
FLUS-Sink起動処理が行われた後、アップリンクプロトコルネゴシエーション処理が行われる。
アップリンクプロトコルネゴシエーション処理は、FLUS-Source２１が開始して、ME-Platform８３との間で行われ、アップリンクに必要なプロトコルがやり取りされる。また、アップリンクプロトコルネゴシエーション処理の中の１つの処理として、アプリケーション群リソース予約可否確認処理が行われる。アプリケーション群リソース予約可否確認処理は、FLUS-Sink４１が開始して、ME-Platform８３との間で行われ、アプリケーション群リソースの予約が可能か否かの確認が行われる。
そして、アプリケーション群リソース予約可否確認処理の中の１つの処理として、Production起動処理が行われる。Production起動処理は、FLUS-Sink４１が開始して、ME-Platform８３との間で行われる。ME-Platform８３は、自身のME-Host３１においてリソースの予約を行い、それに失敗すると、ME-Orchestrator３３として機能するME-Platform８３との間で、Production起動処理を行う。
これにより、ME-Orchestrator３３として機能するME-Platform８３が、複数のME-Host３１から最適なME-Host３１を探して、そのME-Host３１においてProductionアプリケーションを実行する。
そして、アップリンクプロトコルネゴシエーション処理が行われた後、FLUS-Source２１とFLUS-Sink４１との間でアップリンクストリーミングが行われるとともに、Productionアプリケーションによってプロダクション処理が行われる。
図３０は、FLUS-Sink４１とME-Host３１に実行されるアプリケーション８２（Cache/PStorageアプリケーション）が１つあり、さらに、別のME-Host３１に実行されるアプリケーション８２（Distributionアプリケーション）が１つある場合において、アップリンクストリーミングを開始する処理を説明する図である。
まず、FLUS-Source２１は、FLUS-Sink起動処理を行って、FLUS-Sink４１を起動する。そして、FLUS-Sink起動処理が行われた後、アップリンクプロトコルネゴシエーション処理が行われる。
アップリンクプロトコルネゴシエーション処理では、FLUS-Sink４１が、FLUS-Source２１とやりとりするServiceオブジェクトに記載されるCandidateDescriptionのWorkflow-Descriptionを解析する。このWorkflow-Descriptionでは、FLUS-Sink４１の出力が、キャッシュ/ストレージ処理を実行するCache/PStorageアプリケーションと、ストリーム再生クライアントへのダウンリンクストリーミング処理を実行するDistributionアプリケーションとに連結されている。
ここで、リソースの制限により、Cache/PStorageアプリケーションおよびDistributionアプリケーションの両方を、FLUS-Sink４１と同一のME-Host３１上で実行できない（Distributionリソースの予約に失敗した）とする。このとき、Distributionのリソース要件を満たせる別のME-Host３１が見つかった場合、その別のME-Host３１上で、Distributionアプリケーションは実行される。
図３１には、このような場合のWorkflow-Descriptionの記述の一例が示されており、図３２に示すように、FLUS-Sinkの出力がCache/PStorageアプリケーションおよびDistributionアプリケーションに連結されている。
＜第３の実施の形態＞
図３３乃至図３８を参照して、第３の実施の形態として、FLUS-Source２１の基地局１３間のハンドオーバーによって、FLUS-Sink４１および後段のアプリケーション８２のME-Host３１間の遷移について説明する。
即ち、第３の実施の形態では、FLUS-Source２１の基地局１３間ハンドオーバーによってME-Host３１の環境が変わるとき、後段のアプリケーション８２の必要リソース確保を含めたプロトコルネゴシエーションが行われることが特徴となる。
図３３には、第３の実施の形態における情報処理システム１１Ｂの構成例が示されている。
ここで、図１に示したようなカメラなどのFLUS-Source２１の実装されているユーザ端末１４が被写体を追って移動する際に、ME-Host３１が実装された基地局１３を跨ってハンドオーバーするケースを考える。このとき、それぞれの基地局１３にはME-Host３１が実装されているものとする。
また、以下では、ハンドオーバーする前のアクセスネットワーク７２を、ソースアクセスネットワーク７２Ｓと称し、ハンドオーバーする前のME-Host３１を、ソースME-Host３１Ｓと称する。同様に、ハンドオーバーする先となるアクセスネットワーク７２を、ターゲットアクセスネットワーク７２Ｔと称し、ハンドオーバーする先となるME-Host３１を、ターゲットME-Host３１Ｔと称する。
そして、図３３に示すように、所定の基地局１３にバインドされたソースME-Host３１Ｓ上のFLUS-Sinkアプリケーション４１Ｓと、ソースアクセスネットワーク７２Ｓを介してアップリンクストリーミングしているFLUS-Source２１がある。このFLUS-Source２１を実装するユーザ端末１４が、ターゲットME-Host３１Ｔがバインドされた基地局１３のターゲットアクセスネットワーク７２Ｔ上に移動するものとする。
以下では、このような構成における処理のフローについて説明する。
図３８には、アップリンクストリーミングがすでに開始された後のフローを示している。なお、図３８において、上述したようなFLUS-Source２１がソースME-Host３１Ｓ上のFLUS-Sink４１Ｓを起動するフェーズと、アップリンクプロトコルネゴシエーションを行うフェーズは省略されている。
例えば、図３６に示すように、ソースME-Host３１Ｓ上のFLUS-Sink４１ＳとアップリンクストリーミングしているFLUS-Source２１がある。また、FLUS-Sink４１Ｓの後段には、データ保持処理部（Cache/PStorage）４２Ｓおよびディストリビューション処理部５２が連結されている。ここで、データ保持処理部（Cache/PStorage）４２およびディストリビューション処理部５２は、アプリケーション８２として実行されるCache/PStorageアプリケーションおよびDistributionアプリケーションである。また、図３６に示す例では、Distributionアプリケーションは、FLUS-Sink４１Ｓとは別のME-Host３２上で実行されている。
そして、FLUS-Source２１を実装するユーザ端末１４が、別のターゲットME-Host３１Ｔがバインドされた基地局１３のターゲットアクセスネットワーク７２Ｔ上に移動する。その際に、ソースME-Host３１Ｓ上で実行されていたCache/PStorageアプリケーションがターゲットME-Host３１Ｔ上に遷移する。ここでの遷移の意味は、アプリケーションがその状態情報とともに移動するのではなく、遷移先のターゲットME-Host３１Ｔ上に対応するアプリケーションが別途生成される。すなわちアプリケーションの状態情報の移動はない。
また、ソースME-Host３１Ｓ上で実行されているFLUS-Sink４１Ｓは、ME-Platform８３Ｓが提供するAPIにより、FLUS-Source２１が実装されたユーザ端末１４の移動（位置）を検知することができる。そして、逐一の位置遷移情報や、統計情報、AI等を利用したmobility patternの解析等から、ユーザ端末１４が現在存在するソースアクセスネットワーク７２Ｓから別のターゲットアクセスネットワーク７２Ｔに移動することが予測されたとする（図３８のTarget ME-Hostへの遷移予知）。なお、その遷移先のターゲットアクセスネットワーク７２Ｔの基地局にはターゲットME-Host３１Ｔが実装されているものとする。このとき、ソースME-Host３１Ｓ上のFLUS-Sink４１ＳはME-Orchestrator３３に依頼して、ターゲットME-Host３１Ｔ上にFLUS-Sink４１Ｔと、後段のアプリケーションを実行する（図３８のFLUS-Sink(at Target ME-Host)起動）。
このとき、現状確立しているセッションと同等なプロトコル・リソース要件に基づいて、または、Service/CandidateDescriptionsに列挙されているCandidateDescriptionの候補の一覧から、優先順位に基づいてアプリケーションのリソース予約と実行を試みる（図３８のFLUS-Sinkリソース予約/生成）。ここで、プロトコル・リソース要件は、Service/Session[＠state=’active’]のSessionDescriptionに格納されているsdIdにより参照されるCandidateDesriptionで参照されるプロトコルとWorkflowDescriptionに記載される。
さらに、このとき、現状確立しているセッションを維持するか、または、候補一覧の優先順位に基づいてアプリケーション実行を試みるかは、図３４に示すように、遷移後のセッション候補選択ポリシーを指示するService/Policy/KeepAlreadyEstablishedIfFailedのフラグ（true:現状維持、false:候補優先度順）で判断することができる。このフラグがない場合は、KeepAlreadyEstablishedIfFialed=’false’(ディフォルト)とする。即ち、できる限りMECの利点を活かすため、ME-Host３１の遷移を試みるものとする。
また、ターゲットME-Host３１Ｔ上のFLUS-Sink４１Ｔおよび後段アプリケーション群は、必要リソースがリザーブされて起動される（図３８のアプリケーション群リソース予約可否確認）一方で、すぐに処理が開始されるのではなく、実際にストリームが到着してから実処理が行われる。さらに時間が経過して、ソースME-Host３１Ｓ上のFLUS-Sink４１ＳがME-Platform８３Ｓを介して、FLUS-Source２１が実装されたユーザ端末１４が移動して、ターゲットME-Host３１Ｔがバインドされた新たなターゲットアクセスネットワーク７２Ｔに接続されたことを検知したとする（図３８のFLUS-SourceのTarget ME-Hostへの遷移検知）。
これに応じて、遷移後のターゲットアクセスネットワーク７２Ｔからの当該ストリームがターゲットME-Host３１Ｔ上で待機しているFLUS-Sink４１Ｔが受信できるようにトラフィックを変更する（図３８のTarget ME-Hostへのトラフィック更新）。これにより、待機状態であったFLUS-Sink４１Ｔおよびデータ保持処理部（Cache/PStorage）４２が遷移後のターゲットアクセスネットワーク７２Ｔを経由してFLUS-Source２１から送られてくるアップリンクストリームの処理を開始する（図３８のアップリンクストリーミングto Target ME-Host）。
なお、FLUS-Sink４１を含めたアプリケーションのME-Host３１間の遷移そのものを認めない場合には、図３５に示すように、Policy＠DoNotMigrate=’true’を指定できるものとする。なお、このフラグがtrueの場合には、KeepAreadyEstablishedIfFailedは指定しない。
＜第４の実施の形態＞
図３９乃至図４８を参照して、第４の実施の形態として、FLUS-Sink４１および後段のアプリケーションのME-Host３１間の遷移（ME-Host３１のリソースが十分でない場合）について説明する。
即ち、第４の実施の形態では、FLUS-Source２１の基地局１３間ハンドオーバーによりME-Host３１の環境が変わるとき、後段のアプリケーションの必要リソースが確保できるMH-Hostが選択されることが特徴となる。
図３９には、第４の実施の形態における情報処理システムの構成例として、ターゲットME-Host３１Ｔ上に十分なリソースが確保できず、ターゲットME-Host３１Ｔ上に所望のアプリケーションが実行できなかった場合の例が示されている。
即ち、図３９では、図４０に示すように、Source RANからTarget RANへFLUS-Source２１が移動するのに伴うハンドオーバーする際に、ターゲットME-Host３１Ｔ上で、FLUS-Sink４１は実行できるが、Cache/PStorageアプリケーションが起動できなかった場合の例が示されている。
この場合、図４１を参照して説明するような処理が行われる。
即ち、ソースME-Host３１Ｓ上のFLUS-Sink４１ＳはME-Orchestrator３３に依頼して、ターゲットME-Host３１Ｔ上にFLUS-Sink４１Ｔ、および、Cache/PStorageを実行しようとするが、Cache/PStoageのみリソース要件が満足できずに実行に失敗する（図４１のCache/PStoageリソース予約/失敗）。この場合、FLUS-Source２１を実装するユーザ端末１４が、ターゲットME-Host３１Ｔにバインドされたターゲットアクセスネットワーク７２Ｔに遷移したとしても、ターゲットME-Host３１Ｔ上のCache/PStorageが、FLUS-Sink４１Ｔからの出力としてのアップリンクストリームを処理することができないことが事前にわかるので、遷移が起こった場合でも、ソースME-Host３１Ｓ上のデータ保持処理部（Cache/PStorage）４２Ｓの実行状態を維持するように待機しておく。
その後、時間が経過して、ソースME-Host３１Ｓ上のFLUS-Sink４１ＳがME-Platform８３Ｓを介して、FLUS-Source２１が実装されたユーザ端末１４が移動して、ターゲットME-Host３１Ｔがバインドされた新たなRANに接続されたことを検知する（図４１のFLUS-SourceのTarget ME-Hostへの遷移検知）。これに応じて、遷移後のターゲットアクセスネットワーク７２ＴからのアップリンクストリームがターゲットME-Host３１Ｔ上で待機しているFLUS-Sink４１Ｔが受信できるようにトラフィックを変更する（図４１のTarget ME-Hostへのトラフィック更新）。
これにより、待機状態であったFLUS-Sink４１Ｔが、遷移後のターゲットアクセスネットワーク７２Ｔを経由してFLUS-Source２１から送られてくるアップリンクストリームの処理を開始する（図３８のアップリンクストリーミングto Target ME-Host）。ただ、同じターゲットME-Host３１Ｔ上には後段のCache/PStorageが起動されていないため、FLUS-Sink４１の出力ストリームは、遷移前に実行していたソースME-Host３１Ｓ上のデータ保持処理部（Cache/PStorage）４２Ｓに送られる。
次に、図４２に示すブロック図は、遷移先のセル（アクセスネットワーク７２）の予測ができない場合、遷移が予想される２つのセルにバインドされた、それぞれターゲットME-Host３１Ｔ－ＡとターゲットME-Host３１Ｔ－Ｂに、FLUS-Sink４１とCache/PStorageのセットを実行しておく例である。なお、遷移が予想される２つのセルは、図４３に示すようなTargetRAN-AおよびTargetRAN-Bである。ここでは、最終的に、FLUS-Source２１がターゲットME-Host３１Ｔ－Ａにバインドされるターゲットアクセスネットワーク７２Ｔ－Ａに遷移するケースが示されている。
この場合、図４４に示す処理が行われる。
図４４には、アップリンクストリーミングがすでに開始された後のフローを示している。
例えば、FLUS-Sink４１が、ユーザ端末１４が現在存在するソースアクセスネットワーク７２Ｓから別のターゲットアクセスネットワーク７２Ｔ－Ａまたは７２Ｔ－Ｂに移動することが予測されたとする（図４４のTarget ME-Host AorBへの遷移予知）。
このとき、ソースME-Host３１Ｓ上のFLUS-Sink４１ＳはME-Orchestrator３３に依頼して、ターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂ上にそれぞれFLUS-Sink４１Ｔ－Ａおよび４１Ｔ－Ｂと、後段のアプリケーションを実行する（図４４のFLUS-Sink(at Target ME-Host A&B)起動）。
そして、FLUS-Sink４１とターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂそれぞれの間でアップリンクプロトコルネゴシエーションが行われ、ターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂそれぞれにおいて、アプリケーション群リソース予約可否確認が行われる。
さらに時間が経過して、FLUS-Source２１が実装されたユーザ端末１４が移動して、ターゲットME-Host３１Ｔ－Ａがバインドされた新たなターゲットアクセスネットワーク７２Ｔ－Ａに接続されたことを検知したとする（図４４のFLUS-SourceのTarget ME-Host Aへの遷移検知）。
これに応じて、遷移後のターゲットアクセスネットワーク７２Ｔ－Ａからの当該ストリームがターゲットME-Host３１Ｔ－Ａ上で待機しているFLUS-Sink４１Ｔ－Ａが受信できるようにトラフィックを変更する（図４４のTarget ME-Host Aへのトラフィック更新）。これにより、待機状態であったFLUS-Sink４１Ｔ－Ａおよびデータ保持処理部（Cache/PStorage）４２－Ａが遷移後のターゲットアクセスネットワーク７２Ｔ－Ａを経由してFLUS-Source２１から送られてくるアップリンクストリームの処理を開始する（図４４のアップリンクストリーミングto Target ME-Host A）。
次に、図４５に示すブロック図は、耐障害性冗長度を確保する例であり、カバレッジが重複する２つのセル（ターゲットアクセスネットワーク７２Ｔ－Ａおよび７２Ｔ－Ｂ）にバインドされたME-Host３１（ターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂ）に、FLUS-Sink４１とCache/PStorageのセットを実行し、２つのアップリンクセッションを同期して実行する例である。
例えば、遷移後のFLUS-Source２１が、図４６に示すように、TargetRAN-AおよびTargetRAN-Bの両方に、同時に接続されるものとしている。この場合、ターゲットME-Host３１Ｔ－Ａ上のFLUS-Sink４１Ｔ－Ａの出力と、ターゲットME-Host３１Ｔ－Ｂ上のFLUS-Sink４１Ｔ－Ｂの出力のいずれか一方を、Distributionアプリケーションに入力するものとする。
この場合、図４７を参照して説明するような処理が行われる。
図４７には、アップリンクストリーミングがすでに開始された後のフローを示している。
例えば、FLUS-Sink４１が、ユーザ端末１４が現在存在するソースアクセスネットワーク７２Ｓから別のターゲットアクセスネットワーク７２Ｔ－Ａまたは７２Ｔ－Ｂに移動することが予測されたとする（図４７のTarget ME-Host AorBへの遷移予知）。
このとき、ソースME-Host３１Ｓ上のFLUS-Sink４１ＳはME-Orchestrator３３に依頼して、ターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂ上にそれぞれFLUS-Sink４１Ｔ－Ａおよび４１Ｔ－Ｂと、後段のアプリケーションを実行する（図４７のFLUS-Sink(at Target ME-Host A&B)起動）。
そして、FLUS-Sink４１とターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂそれぞれの間でアップリンクプロトコルネゴシエーションが行われ、ターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂそれぞれにおいて、アプリケーション群リソース予約可否確認が行われる。
さらに時間が経過して、FLUS-Source２１が実装されたユーザ端末１４が移動して、ターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂそれぞれがバインドされた新たターゲットアクセスネットワーク７２Ｔ－Ａおよび７２Ｔ－Ｂに接続されたことを検知したとする（図４７のFLUS-SourceのTarget ME-Host AorBへの遷移検知）。
これに応じて、遷移後のターゲットアクセスネットワーク７２Ｔ－Ａおよび７２Ｔ－Ｂからの当該ストリームがターゲットME-Host３１Ｔ－Ａおよび３１Ｔ－Ｂ上で待機しているFLUS-Sink４１Ｔ－Ａおよび４１Ｔ－Ｂが受信できるようにトラフィックを変更する（図４７のTarget ME-Host A&Bへのトラフィック更新）。これにより、待機状態であったFLUS-Sink４１Ｔ－Ａおよびデータ保持処理部（Cache/PStorage）４２－Ａが遷移後のターゲットアクセスネットワーク７２Ｔ－Ａおよび７２Ｔ－Ｂを経由してFLUS-Source２１から送られてくるアップリンクストリームの処理を開始する（図４４のアップリンクストリーミングto Target ME-Host Aおよびのアップリンクストリーミングto Target ME-Host B）。
この冗長構成は、Workflow-Descriptionにおいて、図４８に示すように、対象アプリケーションのService要素のduplicate属性を’true’に設定することにより指示することができるものとする。
なお、上述した本実施の形態では、FLUS-Source２１がServiceオブジェクトを生成してFLUS-Sink４１へ送信するものとして説明したが、FLUS-Sink４１がServiceオブジェクトを生成してもよい。さらに、FLUS-Sink４１が、ServiceオブジェクトをFLUS-Source２１へ送信し、FLUS-Source２１が、そのServiceオブジェクトの中からCandidateDescriptionを選択し、Serviceオブジェクトを更新してFLUS-Sink４１へ送信するようにしてもよい。即ち、FLUS-Source２１およびFLUS-Sink４１の間で、Serviceオブジェクトを送受信して、アップリンクに必要なプロトコルをやり取りし、コンテンツアップリンクストリームの制御プロトコルネゴシエーションが行われれば、どちら側から処理を開始してもよい。
＜コンピュータの構成例＞
次に、上述した一連の処理（情報処理方法）は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
図４９は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク１０５や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)やスピーカ等で構成される。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
コンテンツアップリンクストリームのためのプロトコルネゴシエーションを行う通信モジュールが、
前記プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトを、他の通信装置に送信し、
前記他の通信装置から、前記Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報を受信し、
前記他の通信装置との間で、前記コンテンツアップリンクストリームの制御プロトコルネゴシエーションを行う
情報処理装置。
（２）
前記Serviceオブジェクトには、前記コンテンツアップリンクストリームにおいて利用されるプロトコルおよびフォーマットについての複数のCandidateDescriptionsが候補として記載される
上記（１）に記載の情報処理装置。
（３）
前記Serviceオブジェクトには、前記複数のCandidateDescriptionsそれぞれに割り当てられる優先度が含まれる
上記（２）に記載の情報処理装置。
（４）
前記優先度は、ネットワーク帯域の状況に応じて決定される
上記（３）に記載の情報処理装置。
（５）
前記複数のCandidateDescriptionsそれぞれには、前記他の通信装置におけるメディアの処理に関連する他のアプリケーション、および、そのメディアの処理に必要なリソース条件を定義するWorkflowDescriptionが含まれる
上記（２）または（３）に記載の情報処理装置。
（６）
前記ネゴシエーションのための情報には、前記Serviceオブジェクトに基づいて、前記他の通信装置が選択した前記CandidateDescriptionの情報が含まれる
上記（２）から（５）までのいずれかに記載の情報処理装置。
（７）
前記ネゴシエーションのための情報に基づいて、前記Serviceオブジェクトには、前記Serviceオブジェクトから選択された前記CandidateDescriptionに基づいて、Sessionオブジェクトが格納される
上記（６）に記載の情報処理装置。
（８）
前記Serviceオブジェクトは、前記コンテンツアップリンクストリームにおいてコンテンツを送信する側となる前記通信モジュールにより生成される
上記（１）から（７）までのいずれかに記載の情報処理装置。
（９）
複数の前記情報処理装置がネットワークを介して接続されて情報処理システムが構成されており、
前記他の通信装置の近傍にある前記情報処理装置において、前記通信モジュールとなるアプリケーションが実行され、前記通信モジュールのアプリケーションの後段に、他のアプリケーションが連結するように実行される
上記（１）から（８）までのいずれかに記載の情報処理装置。
（１０）
前記他の通信装置の近傍にある前記情報処理装置において、前記通信モジュールのアプリケーションの後段に連結される前記他のアプリケーションの必要なリソースが確保できない場合に、
前記通信モジュールのアプリケーションが実行される前記情報処理装置以外の他の前記情報処理装置上において、前記他のアプリケーションが実行される
上記（９）に記載の情報処理装置。
（１１）
前記他の通信装置の移動に伴ってハンドオーバーが発生するとき、遷移前となる第１の前記情報処理装置から遷移後となる第２の前記情報処理装置へ、前記他のアプリケーションの必要なリソースを確保するようにネゴシエーション処理が行われる
上記（１０）に記載の情報処理装置。
（１２）
前記他のアプリケーションのうちの一部が、遷移前となる第１の前記情報処理装置において維持されたまま、それ以外の一部が、遷移後となる第２の前記情報処理装置において実行される
上記（１１）に記載の情報処理装置。
（１３）
遷移後となる第２の前記情報処理装置として、複数の前記情報処理装置で前記他のアプリケーションを実行させておく
上記（１２）に記載の情報処理装置。
（１４）
前記Serviceオブジェクトは、前記コンテンツアップリンクストリームにおいてコンテンツを受信する側となる前記通信モジュールにより生成される
上記（１）から（７）までのいずれかに記載の情報処理装置。
（１５）
複数の前記他の通信装置がネットワークを介して接続されて情報処理システムが構成されており、
前記情報処理装置の近傍にある前記他の通信装置において、前記通信モジュールとなるアプリケーションが実行され、前記通信モジュールのアプリケーションの後段に、他のアプリケーションが連結するように実行される
上記（１）から（８）まで、および（１４）のいずれかに記載の情報処理装置。
（１６）
前記情報処理装置の近傍にある前記他の通信装置において、前記通信モジュールのアプリケーションの後段に連結される前記他のアプリケーションの必要なリソースが確保できない場合に、
前記通信モジュールのアプリケーションが実行される前記他の通信装置以外の、さらに
他の前記通信装置上において、前記他のアプリケーションが実行される
上記（１５）に記載の情報処理装置。
（１７）
前記情報処理装置の移動に伴ってハンドオーバーが発生するとき、遷移前となる第１の前記他の通信装置から遷移後となる第２の前記他の通信装置へ、前記他のアプリケーションの必要なリソースを確保するようにネゴシエーション処理が行われる
上記（１６）に記載の情報処理装置。
（１８）
前記他のアプリケーションのうちの一部が、遷移前となる第１の前記他の通信装置において維持されたまま、それ以外の一部が、遷移後となる第２の前記他の通信装置において実行される
上記（１７）に記載の情報処理装置。
（１９）
遷移後となる第２の前記他の通信装置として、複数の前記他の通信装置で前記他のアプリケーションを実行させておく
上記（１８）に記載の情報処理装置。
（２０）
コンテンツアップリンクストリームのためのプロトコルネゴシエーションを行う通信モジュールが、
前記プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトを、他の通信装置に送信し、
前記他の通信装置から、前記Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報を受信し、
前記他の通信装置との間で、前記コンテンツアップリンクストリームの制御プロトコルネゴシエーションを行う
ことを含む情報処理方法。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
１１ 情報処理システム， １２ クラウド， １３ 基地局， １４ ユーザ端末， ２１ FLUS-Source， ３１および３２ ME-Host， ３３ ME-Orchestrator， ４１ FLUS-Sink， ４２ データ保持処理部（Cache/PStorage）， ４３ トランスコード処理部， ４４ データベース保持部， ４５ 記憶装置， ５１ プロダクションネットワーク処理部， ５２ ディストリビューション処理部， ５３ データベース保持部， ５４ 記憶部， ６１ データベース保持部， ７１ ５Ｇコアネットワーク， ７２ アクセスネットワーク， ８１ データプレーン， ８２ アプリケーション， ８３ ME-Platform， ８４ UPF

Claims (20)

  1. コンテンツアップリンクストリームのためのプロトコルネゴシエーションを行う通信モジュールが、
    前記プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトを、他の通信装置に送信し、
    前記他の通信装置から、前記Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報を受信し、
    前記他の通信装置との間で、前記コンテンツアップリンクストリームの制御プロトコルネゴシエーションを行う
    情報処理装置。
  2. 前記Serviceオブジェクトには、前記コンテンツアップリンクストリームにおいて利用されるプロトコルおよびフォーマットについての複数のCandidateDescriptionsが候補として記載される
    請求項１に記載の情報処理装置。
  3. 前記Serviceオブジェクトには、前記複数のCandidateDescriptionsそれぞれに割り当てられる優先度が含まれる
    請求項２に記載の情報処理装置。
  4. 前記優先度は、ネットワーク帯域の状況に応じて決定される
    請求項３に記載の情報処理装置。
  5. 前記複数のCandidateDescriptionsそれぞれには、前記他の通信装置におけるメディアの処理に関連する他のアプリケーション、および、そのメディアの処理に必要なリソース条件を定義するWorkflowDescriptionが含まれる
    請求項２に記載の情報処理装置。
  6. 前記ネゴシエーションのための情報には、前記Serviceオブジェクトに基づいて、前記他の通信装置が選択した前記CandidateDescriptionの情報が含まれる
    請求項２に記載の情報処理装置。
  7. 前記ネゴシエーションのための情報に基づいて、前記Serviceオブジェクトには、前記Serviceオブジェクトから選択された前記CandidateDescriptionに基づいて、Sessionオブジェクトが格納される
    請求項６に記載の情報処理装置。
  8. 前記Serviceオブジェクトは、前記コンテンツアップリンクストリームにおいてコンテンツを送信する側となる前記通信モジュールにより生成される
    請求項１に記載の情報処理装置。
  9. 複数の前記情報処理装置がネットワークを介して接続されて情報処理システムが構成されており、
    前記他の通信装置の近傍にある前記情報処理装置において、前記通信モジュールとなるアプリケーションが実行され、前記通信モジュールのアプリケーションの後段に、他のアプリケーションが連結するように実行される
    請求項１に記載の情報処理装置。
  10. 前記他の通信装置の近傍にある前記情報処理装置において、前記通信モジュールのアプリケーションの後段に連結される前記他のアプリケーションの必要なリソースが確保できない場合に、
    前記通信モジュールのアプリケーションが実行される前記情報処理装置以外の他の前記情報処理装置上において、前記他のアプリケーションが実行される
    請求項９に記載の情報処理装置。
  11. 前記他の通信装置の移動に伴ってハンドオーバーが発生するとき、遷移前となる第１の前記情報処理装置から遷移後となる第２の前記情報処理装置へ、前記他のアプリケーションの必要なリソースを確保するようにネゴシエーション処理が行われる
    請求項１０に記載の情報処理装置。
  12. 前記他のアプリケーションのうちの一部が、遷移前となる第１の前記情報処理装置において維持されたまま、それ以外の一部が、遷移後となる第２の前記情報処理装置において実行される
    請求項１１に記載の情報処理装置。
  13. 遷移後となる第２の前記情報処理装置として、複数の前記情報処理装置で前記他のアプリケーションを実行させておく
    請求項１２に記載の情報処理装置。
  14. 前記Serviceオブジェクトは、前記コンテンツアップリンクストリームにおいてコンテンツを受信する側となる前記通信モジュールにより生成される
    請求項１に記載の情報処理装置。
  15. 複数の前記他の通信装置がネットワークを介して接続されて情報処理システムが構成されており、
    前記情報処理装置の近傍にある前記他の通信装置において、前記通信モジュールとなるアプリケーションが実行され、前記通信モジュールのアプリケーションの後段に、他のアプリケーションが連結するように実行される
    請求項１に記載の情報処理装置。
  16. 前記情報処理装置の近傍にある前記他の通信装置において、前記通信モジュールのアプリケーションの後段に連結される前記他のアプリケーションの必要なリソースが確保できない場合に、
    前記通信モジュールのアプリケーションが実行される前記他の通信装置以外の、さらに
    他の前記通信装置上において、前記他のアプリケーションが実行される
    請求項１５に記載の情報処理装置。
  17. 前記情報処理装置の移動に伴ってハンドオーバーが発生するとき、遷移前となる第１の前記他の通信装置から遷移後となる第２の前記他の通信装置へ、前記他のアプリケーションの必要なリソースを確保するようにネゴシエーション処理が行われる
    請求項１６に記載の情報処理装置。
  18. 前記他のアプリケーションのうちの一部が、遷移前となる第１の前記他の通信装置において維持されたまま、それ以外の一部が、遷移後となる第２の前記他の通信装置において実行される
    請求項１７に記載の情報処理装置。
  19. 遷移後となる第２の前記他の通信装置として、複数の前記他の通信装置で前記他のアプリケーションを実行させておく
    請求項１８に記載の情報処理装置。
  20. コンテンツアップリンクストリームのためのプロトコルネゴシエーションを行う通信モジュールが、
    前記プロトコルネゴシエーションに用いられるコンテンツのストリームに関する情報を含むServiceオブジェクトを、他の通信装置に送信し、
    前記他の通信装置から、前記Serviceオブジェクトに基づいて送信されるネゴシエーションのための情報を受信し、
    前記他の通信装置との間で、前記コンテンツアップリンクストリームの制御プロトコルネゴシエーションを行う
    ことを含む情報処理方法。
JP2019022675A 2019-02-12 2019-02-12 情報処理装置および情報処理方法 Pending JP2022051975A (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2019022675A JP2022051975A (ja) 2019-02-12 2019-02-12 情報処理装置および情報処理方法
PCT/JP2020/003079 WO2020166323A1 (ja) 2019-02-12 2020-01-29 情報処理装置および情報処理方法
US17/424,742 US11522933B2 (en) 2019-02-12 2020-01-29 Information processing apparatus and information processing method
CN202080012193.6A CN113383322A (zh) 2019-02-12 2020-01-29 信息处理装置和信息处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019022675A JP2022051975A (ja) 2019-02-12 2019-02-12 情報処理装置および情報処理方法

Publications (1)

Publication Number Publication Date
JP2022051975A true JP2022051975A (ja) 2022-04-04

Family

ID=72044866

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019022675A Pending JP2022051975A (ja) 2019-02-12 2019-02-12 情報処理装置および情報処理方法

Country Status (4)

Country Link
US (1) US11522933B2 (ja)
JP (1) JP2022051975A (ja)
CN (1) CN113383322A (ja)
WO (1) WO2020166323A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11063992B1 (en) * 2020-03-30 2021-07-13 Tencent America LLC Network-based media processing (NBMP) workflow management through 5G framework for live uplink streaming (FLUS) control
US11297121B2 (en) * 2020-04-07 2022-04-05 Tencent America LLC Split rendering using network based media processing workflow
US11750676B2 (en) * 2020-12-04 2023-09-05 Tencent America LLC Network-based media processing (NBMP) deployment with framework for live uplink streaming (FLUS) and 5G application function (AF)
US12069125B2 (en) * 2021-04-19 2024-08-20 Tencent America LLC Method for switching workflow or updating workflow with continuity and no interruption in dataflow
JP2022184168A (ja) * 2021-05-31 2022-12-13 シャープ株式会社 端末装置、サーバ装置、通信方法及びプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007036835A (ja) 2005-07-28 2007-02-08 Canon Inc プロファイル管理システム
DE102005050588B4 (de) * 2005-10-21 2010-07-08 Siemens Ag Signalisierung bezüglich des Aufbaus von H.324 Videotelefonie zwischen einer Mediagateway und einem Controller
KR101669276B1 (ko) * 2009-10-19 2016-10-25 삼성전자주식회사 통신 시스템에서 단말의 우선순위를 고려하여 서비스 품질을 보장하는 방법 및 장치
KR101446028B1 (ko) * 2009-10-28 2014-10-01 알까뗄 루슨트 패킷 스위칭된 도메인으로부터 회로 스위칭된 도메인으로 비디오 호를 핸드 오버하기 위한 방법 및 디바이스
WO2012123001A1 (de) * 2011-03-16 2012-09-20 Siemens Enterprise Communications Gmbh & Co. Kg Verfahren zum aufbau einer kommunikationsverbindung
CN102868873B (zh) * 2011-07-08 2017-10-17 中兴通讯股份有限公司 一种远程呈现方法、终端和系统
US9119111B2 (en) 2011-08-12 2015-08-25 Alcatel Lucent Method and apparatus for controlling wireless uplink sessions
US9288810B2 (en) * 2013-12-05 2016-03-15 Qualcomm Incorporated Wireless media sharing from multiple sources to a single sink
US9699500B2 (en) 2013-12-13 2017-07-04 Qualcomm Incorporated Session management and control procedures for supporting multiple groups of sink devices in a peer-to-peer wireless display system
KR101581947B1 (ko) * 2014-07-17 2015-12-31 주식회사 케이티 선택적 트랜스코딩 시스템 및 방법
JP2018190040A (ja) 2017-04-28 2018-11-29 キヤノン株式会社 通信装置、制御方法、およびプログラム
US11190554B2 (en) * 2017-06-20 2021-11-30 Samsung Electronics Co., Ltd. System and method for discovery and access of uplink services

Also Published As

Publication number Publication date
US20220124139A1 (en) 2022-04-21
CN113383322A (zh) 2021-09-10
WO2020166323A1 (ja) 2020-08-20
US11522933B2 (en) 2022-12-06

Similar Documents

Publication Publication Date Title
WO2020166323A1 (ja) 情報処理装置および情報処理方法
EP3208979B1 (en) Software-defined network-based method and system for implementing content distribution network
EP1642443B1 (en) Method for managing a streaming media service
CN101589634B (zh) 向分组流提供动态变化
EP3216223B1 (en) Collaborative distributed/unstructured service management framework for wireless-display platform
US9538134B2 (en) Method and system for resource load balancing in a conferencing session
US8639718B2 (en) Systems and methods for client transparent video readdressing
CN101252546B (zh) 媒体流在线服务迁移的方法和装置
US20170237686A1 (en) Software-Defined Network-Based Method and System for Implementing Content Distribution Network
KR20140044923A (ko) 적응성 비디오 통신을 위한 시스템 및 방법
CN112532945B (zh) 一种多类型媒体业务融合系统
US7797451B2 (en) A/V stream-forwarding system and method for forwarding A/V streams from data network to IEEE1394 network
CN110445723A (zh) 一种网络数据调度方法及边缘节点
US8527659B2 (en) Method and system for optimizing CPNS enabler
US20210289015A1 (en) Dynamic multiple endpoint generation
Komorita et al. Loosely coupled service composition for deployment of next generation service overlay networks
Andriescu et al. AmbiStream: a middleware for multimedia streaming on heterogeneous mobile devices
KR102174325B1 (ko) 네트워크 적응형 컨텐츠 제공을 위한 프로그램을 기록한 컴퓨터 판독 가능한 기록 매체 및 네트워크 적응형 컨텐츠 제공 장치
Thomas et al. Application of sand technology in dash-enabled content delivery networks and server environments
US20220167023A1 (en) Information processing apparatus, information processing method, and program
US20130058634A1 (en) Method for transcoding and playing back video files based on grid technology in devices having limited computing power
WO2020162219A1 (ja) 情報処理装置および情報処理方法、並びにプログラム
CN110196839A (zh) 一种基于视联网的共享文件方法和装置
CN105100147A (zh) 一种基于内容提供商与服务提供商分离的控制方法及装置
WO2021140949A1 (ja) コンテンツ配信システムおよびコンテンツ配信方法、並びにプログラム