CN113383322A - 信息处理装置和信息处理方法 - Google Patents

Abstract

本公开内容涉及可以自适应地执行上行链路流送的信息处理装置和信息处理方法。信息处理系统，其中，用于执行用于内容上行链路流的协议协商的通信模块将包括在协议协商中使用的与内容的流有关的信息的服务对象发送至其他通信装置，并且从其他通信装置接收基于服务对象发送的用于协商的信息，并且执行用于内容上行链路流的控制的协议协商。本特征可以应用于执行上行链路流送的通信系统。

Description

信息处理装置和信息处理方法

技术领域

本公开内容涉及信息处理装置和信息处理方法，并且更特别地涉及使得能够自适应地执行上行链路流送的信息处理装置和信息处理方法。

背景技术

近年来，分发诸如普通用户生成的用户生成的内容(UGC)内容的流的使用实例的数量正在增加。随之，存在将在被称为视频生态系统的分发平台中支持标准内容(流)上行链路接口的可能性。

例如，在这样的使用实例中，假设将对不仅使用低成本智能电话摄像装置或视频摄像装置而且还使用用于商业目的的专业用途摄像装置记录的各种流进行上行链路传输。因此，需要流上行链路接口能够自适应地处理所有这些流。

此外，根据向第五代移动通信系统(下文中被称为5G)的过渡，假设经由载波网络和因特网网络对专业用途记录的流的超高质量上行链路传输在未来将变得普遍。此外，假设使用诸如智能电话、数字静态摄像装置和可穿戴终端的任何捕获移动设备进行即时捕获和即时上行链路传输将变得普遍。因此，将存在对云原生媒体处理环境的强烈需求，在该云原生媒体处理环境中，在云上的媒体处理系统中以低延迟来处理流，并且然后将其传递至分发系统。

例如，当前在第三代合作伙伴项目(3GPP)中正在考虑实时上行链路流送框架(FLUS)框架作为从流捕获设备到云的上传接口(例如，参考非专利文献1和2)。

引文列表

非专利文献

非专利文献1：3GPP TS 26.238 V15.0.0(2017-12)第三代合作伙伴项目；技术规范组服务和系统方面；上行链路流送(版本15)。

非专利文献2：3GPP TS 26.114 V15.1.0(2017-12)第三代合作伙伴项目；技术规范组服务和系统方面；IP多媒体子系统(IMS)；多媒体技术；媒体处理和交互(版本15)。

发明内容

本发明要解决的问题

如上所述，需要对各种流进行上行链路传输的流上行链路接口来自适应性地处理任何使用实例。

鉴于这样的情况做出了本公开内容，并且本公开内容旨在使得能够自适应地执行上行链路流送。

问题的解决方案

在作为本公开内容的一方面的一种信息处理装置中，执行用于内容上行链路流的协议协商的通信模块向不同通信设备发送包括在协议协商中使用的与内容的流有关的信息的服务对象；从其他的通信装置接收基于服务对象发送的用于协商的信息；以及与不同通信设备执行用于内容上行链路流的控制协议协商。

作为本公开内容的一方面的一种信息处理方法包括：执行用于内容上行链路流的协议协商的通信模块向其他的通信装置发送包括在协议协商中使用的与内容的流有关的信息的服务对象，从其他的通信装置接收基于服务对象发送的用于协商的信息，并且与其他的通信装置执行用于内容上行链路流的控制协议协商。

在本公开内容的一方面中，将包括在协议协商中使用的与内容的流有关的信息的服务对象发送至其他的通信装置，从该不同通信设备接收基于服务对象发送的用于协商的信息，并且与不同通信设备执行用于内容上行链路流的控制协议协商。

附图说明

图1是示出假设要使用应用了本技术的信息处理系统的使用实例的图。

图2是示出被假设为信息处理系统的环境的细节的图。

图3是示出应用了本技术的信息处理系统的配置示例的框图。

图4是示出根据第一实施方式的信息处理系统的第一配置示例的图。

图5是示出用于开始上行链路流送的处理的图。

图6是示出上行链路协议协商的图。

图7是示出服务对象的结构的示例的图。

图8是示出存储在@SessionDescription中的CandidateDescription@sdId的图。

图9是示出存储在CandidateDescription@SessionDescription中的会话描述协议(SDP)或媒体呈现描述(MPD)的图。

图10示出了用于执行上行链路协议协商的流程图。

图11是示出根据第一实施方式的信息处理系统的第二配置示例的图。

图12是示出应用之间的依赖关系的图。

图13是示出工作流程描述(Workflow-Description)的示例的图。

图14是示出用于从FLUS-接收器(FLUS-Sink)的输出的描述示例的图。

图15是示出用于向转码处理单元中的输入的描述示例的图。

图16是示出用于向存储设备中的输入的描述示例的图。

图17是示出用于从转码处理单元的输出的描述示例的图。

图18是示出用于向分发处理单元中的输入的描述示例的图。

图19是示出应用对象的图。

图20是示出用于开始上行链路流送的处理的图。

图21是示出工作流描述的描述示例的图。

图22是示出应用之间的连接的图。

图23是示出上行链路协议协商的图。

图24是示出其中启动应用的实体启动应用的处理的流程图。

图25是示出通用资源类标识符和MEC系统相关资源类标识符的映射的定义的图。

图26是示出MEC系统相关词典的项的示例的图。

图27是示出资源描述的示例的图。

图28是示出资源描述中的ResourceClass@startTime和ResourceClass@endTime的描述示例的图。

图29是示出用于开始上行链路流送的处理的图。

图30是示出用于开始上行链路流送的处理的图。

图31是示出工作流描述的描述示例的图。

图32是示出应用之间的连接的图。

图33是示出根据第三实施方式的信息处理系统的配置示例的图。

图34是示出KeepAlreadyEstablishedIfFialed的图。

图35是示出DoNotMigrate的图。

图36是示出FLUS-接收器和高速缓存/PStorage应用的转移的图。

图37是示出FLUS-源从源RAN到目标RAN的移动的图。

图38是示出用于开始上行链路流送的处理的图。

图39是示出根据第四实施方式的信息处理系统的配置示例的图。

图40是示出FLUS-源从源RAN到目标RAN的移动的图。

图41是示出用于开始上行链路流送的处理的图。

图42是示出转移至两个目标ME-主机的情况的图。

图43是示出FLUS-源从源RAN到目标RAN的移动的图。

图44是示出用于开始上行链路流送的处理的图。

图45是示出确保容错冗余的示例的图。

图46是示出FLUS-源从源RAN到目标RAN-A和目标RAN-B的移动的图。

图47是示出用于开始上行链路流送的处理的图。

图48是示出工作流程描述的描述示例的图。

图49是示出应用了本技术的计算机的实施方式的配置示例的框图。

具体实施方式

在下文中，将参照附图详细描述应用了本技术的具体实施方式。

<本技术的概述>

首先，将参照图1至图3描述本技术的概述。

图1是示出假设要使用应用了本技术的信息处理系统的使用实例的图。

在图1所示的配置示例中，信息处理系统11包括云12、多个基站13和各种用户终端的集合14。

云12形成为经由网络连接多个服务器，并且在各个服务器执行处理时提供各种服务。例如，如图1所示，云12可以提供上行链路服务、分发服务、制作服务等。

多个基站13中的每一个(在图1的示例中，两个基站13-1和13-2)在每个基站作为可通信范围覆盖的小区中与用户终端14通信。

作为各种用户终端14，例如，可以使用如图所示的专业摄像装置、数字静态摄像装置、智能电话、无人机等。即，用户终端14是移动网络捕获设备，其经由网络实现流上行链路功能并且可以在捕获运动图像的同时与基站13通信以将流上行链路传输至云12。

然后，在以这种方式配置的信息处理系统11中，需要使得能够自适应地执行上行链路流送中的协议和资源协商(第一实施方式和第二实施方式)。

此外，在信息处理系统11中，在用户终端14在从基站13-1至基站13-2的小区之间移动的情况下，例如，在基站13-1与基站13-2之间执行切换。此时，需要使得能够无缝地执行上行链路流送(第三实施方式和第四实施方式)。此处，无缝上行链路意味着，即使在用户终端14正在捕获运动被摄体并且随着该被摄体从一个小区移动到另一个小区的情况下，也无缝地流送实时捕获流。

具体地，作为信息处理系统11的使用实例，假设诸如马拉松的长距离运动的实时广播。在这样的实时广播中，在目的地小区拥塞的环境中中断上行链路流送的情况下，不能执行广播。出于该原因，需要对流本身的无缝上行链路传输。此外，考虑到上行链路传输之后的处理和分发，需要在捕获装置侧(或基于制作服务侧的意图经由捕获设备)进行适当的控制。

将参照图2描述被假设为信息处理系统11的环境的细节。

例如，目前，多访问边缘计算(MEC)架构被假设为可以在如图1所示的信息处理系统11中使用的网络。

在MEC架构中，首先将在用户终端14上实现的FLUS-源21连接至在用作为每个基站13提供的边缘服务器的多访问边缘主机(ME-主机)31上实现的FLUS-接收器41。例如，FLUS-源21是在发送上行链路流的客户端上实现的流发送模块。FLUS-接收器41是在从FLUS-源21接收上行链路流的服务器上实现的流接收模块。此时，在FLUS-接收器41的后续级处作为MEC应用执行高速缓存、存储处理、转码处理(参见图3)等。

然后，在用户终端14从基站13-1的小区移动到基站13-2的小区的情况下，在基站13-1与基站13-2之间发生切换。此时，在绑定至用户终端14移动之前的小区的MEC环境中已经执行的MEC应用也被转移至绑定至用户终端14移动之后的小区的MEC环境。

即，随着切换的发生，ME-主机31-1的FLUS-接收器41-1被转换成ME-主机31-2的FLUS-接收器41-2。通过以这种方式转换ME-主机31(MEC环境)，信息处理系统11可以充分利用MEC计算的优点，例如低延迟和负荷分发。

此时，如图2所示，假设与在基站13-1的小区中相比在基站13-2的小区中存在较多的用户终端14。在这种情况下，例如，发生以下情况：尽管转移之前的基站13-1处于可以进行宽带(基带或视觉无损)上行链路传输的环境中，但是转移之后的基站13-2处于仅可以进行窄带(Intra-GOP或Long-GOP)上行链路传输的环境中。在这种情况下，在用户终端14的移动中，需要使得上行链路传输能够在移动之前和之后尽可能无缝。

此外，需要考虑在这样的转移之前和之后的分发情况实现自适应上行链路传输来实现无缝上行链路流送控制。

因此，如以下所述，在本实施方式中，新提出了实现诸如以上提及的预先准备的无缝上行链路传输所需的MEC架构中能够使用的标准协议(API：应用编程接口)和流(序列)。

在此处，将描述已知技术的内容。

首先，其中用户终端14附近的ME-主机31-1执行与用户终端14有关的服务器侧应用的技术是已知技术。然而，在发生动态配置改变的情况下将与流处理有关的一系列应用传送至ME-平台侧的技术是未知的。

即，在ME-主机31中，不存在用于直接与用户终端14通信的FLUS-接收器41的标准协议，以定义在ME-主机31上的FLUS-接收器41的后续级处存在的与流处理有关的一系列主机应用，并且将该一系列主机应用传送至ME-平台。

此外，在ME-主机31上当例如在ME-主机31-1与ME-主机31-2之间切换用户终端14时应用迁移的技术是已知技术。另一方面，在迁移目的地处执行应用所需的资源协商未被指定为标准协议。

此外，欧洲电信标准协会(ETSI)指定用于在ME-平台中注册一般应用执行条件(静态存储器、磁盘上限等)的框架。然而，没有已知技术用于协商针对应用的执行的必要要求。

此处，将描述本公开内容中新提出的内容。

首先，提出的是新定义“工作流程描述”，该工作流程描述在用户终端14附近的ME-主机31-1中执行用于将用户终端14上的FLUS-源21连接至FLUS-接收器41-1的处理，并且然后使得能够执行用于在后续级(例如，云12)处处理媒体流的服务(应用)。此外，为了使得这样的处理能够应对动态配置改变，新提出的是工作流描述，该工作流描述在其中存储与媒体流的处理有关的一系列应用作为信息。

此外，新提出的是限定工作流描述，使得FLUS-源21可以控制在FLUS-接收器41的后续级处的应用是否可以在ME-主机31之间迁移、在迁移目的地处执行时的条件(流送质量和协议)等。

具体地，可以在工作流描述中描述在迁移目的地处进行资源协商所需的条件，使得可以按照FLUS-源21侧的意愿执行协商。即，新提出的是使得FLUS-源21侧能够指定工作流描述，并且声明或传送迁移和期望质量所需的资源，以使得能够预先预测并确保转移之后的服务质量。新提出的是，如果另一方面不能确保转移之后的服务质量，则使得能够维持转移之前的资源。

此外，提出了通过针对与工作流描述中描述的媒体流的处理有关的每个应用，将类标识存储为处理(在参考系统中执行以限定集合)所需的资源评估指标作为信息，来缓解资源协商。即，通过允许由MEC系统相关类定义来指定期望的资源量，而不是数值地指定量，可以减轻指定描述用于执行工作流描述中定义的应用的条件的资源描述的方式的复杂性。此外，通过预先识别参考MEC系统中的对应类，可以提高类识别的准确性。

因此，在本实施方式中，如以下所述，在可以预测转移目的地小区的情况下，即，在可以预测转移目的地小区的拥塞状态的情况下，在移动至转移目的地小区之前，预先执行协商以预留移动之后需要的资源。此外，预留FLUS-接收器41(以及后续的处理)在绑定至转移目的地小区的ME-主机31上操作所需的CPU资源、存储区域、输入/输出(IO)吞吐量等。此外，在同时存在两个转移目的地小区的情况下，可以选择更有利的小区，并且可以在这些小区在覆盖方面具有层级关系并且位置在小区边界处的条件下无缝地执行上行链路传输。此外，在不能预测转移目的地小区的情况下或为了确保容错冗余，在绑定至多个相邻小区的ME-主机s 31上运行FLUS-接收器41(以及后续的处理)，以允许多个上行链路会话被同步。

图3是示出应用了本技术的信息处理系统的配置示例的框图。

在图3所示的信息处理系统11中，云12包括提供上行链路服务的ME-主机31-1至31-3以及提供分发服务和制作服务的ME-主机32。云12还包括ME-协调器33，该ME-协调器33以集成的方式执行对ME-主机31-1至31-3和ME-主机32的设置。

图3示出了其中用户终端(UE：用户设备)14从提供有ME-主机31-1的基站13-1的小区移动至提供有ME-主机31-2的基站13-2的小区或提供有ME-主机31-3的基站13-3(未示出)的小区的状态。注意，以类似的方式形成ME-主机31-1至31-3，并且在不需要区分ME-主机31-1至31-3的情况下，它们中的每一个将被简单地称为ME-主机31，并且ME-主机31的部件中的每一个将以类似的方式被引用。

ME-主机31包括FLUS-接收器41、数据保留处理单元(高速缓存器/PStorage)42、转码处理单元43和数据库保留单元44，并且数据保留处理单元(高速缓存器/PStorage)42包括存储设备45。

ME-主机32包括制作网络处理单元51、分发处理单元52和数据库保留单元53，并且制作网络处理单元51包括存储单元54。

ME-协调器33包括数据库保留单元61，并且数据库保留单元61保留实时管理ME-主机31和32中的每一个的操作环境和标识信息的资源数据库。

<根据第一实施方式的信息处理系统的第一配置示例>

参照图4至图10，将描述上行链路流送中的协议和资源协商作为根据第一实施方式的信息处理系统的第一配置示例。例如，根据第一实施方式的信息处理系统的第一配置示例具有以下特性：可以在FLUS-源21与FLUS-接收器41之间的协议协商时指定用于选择上行链路传输中使用的工作流描述的优先级。

图4示出了作为根据第一实施方式的信息处理系统11的第一配置示例的5G核心网络系统功能组71以及用户终端14与用作MEC环境的ME-主机31中的应用82之间的会话。

例如，在信息处理系统11中，由于边缘计算中的边缘服务器，可以显著避免作为常规云计算的瓶颈之一的通信延迟。此外，通过在用户终端14、用作边缘服务器的ME-主机31和用作云服务器的ME-主机32(图3)之间执行对高负荷应用的分布式处理，可以加速处理。

注意，在“ETSI-MEC”中指定该边缘计算的标准规范。此外，ETSI-MEC中的ME-主机对应于用作边缘服务器的ME-主机31。

在图4所示的示例中，经由在3GPP中标准化的5G核心网络71的接入网络72将ME-主机31上的应用82连接至用户终端14(在用户终端14上实现的应用)的线表示用户数据会话。注意，5G核心网络71中的接入网络((R)AN)72包括有线接入网络(AN：接入网络)和无线接入网络(RAN：无线电接入网络)。

此外，在ME-主机31上，存在被称为ME-平台83的边缘计算平台。然后，在ME-平台83上执行的应用82经由数据平面81与用户终端14交换诸如流数据的用户数据，该数据平面81用作与用户终端14的用户数据会话的抽象。此处，数据平面81具有作为3GPP中的用户平面功能(UPF)84的功能。注意，数据平面81可以具有与UPF 84对应的功能。

此外，5G核心网络71采用基于服务的架构，并且限定作为核心网络的功能的多个网络功能(NF)。然后，NF经由称为基于服务的接口的统一接口连接。

在图4的示例中，作为NF示出的是NF储存库功能(NRF：NF服务发现)、统一数据管理(UDM：订户信息的管理)、认证服务器功能(AUSF：UE认证信息的管理)、策略控制功能(PCF：与AMF和SMF的正常操作的移动性和会话管理有关的策略的控制)、网络开放功能(NEF：向MNO网络中的应用提供NF服务)、访问和移动性管理功能(AMF：UE移动性的管理、认证和授权以及SMF的控制)和会话管理功能(SMF：UE会话管理)。

将参照图5至图10描述协议和资源协商。

图5是示出图4中的信息处理系统11中用于开始上行链路流送的处理的图。此外，图5主要示出在FLUS-源21与FLUS-接收器41之间执行的处理。

首先，执行FLUS-接收器启动处理。

FLUS-接收器启动处理由FLUS-源21开始，并利用ME-平台83执行，这使FLUS-接收器41启动。此外，作为FLUS-接收器启动处理之一，执行FLUS-接收器资源预留和生成处理。FLUS-接收器资源预留和生成处理由ME-平台83开始并且利用FLUS-接收器41执行，这使得FLUS-接收器41的资源被预留和生成。

具体地，FLUS-源21访问由ME-平台83提供的API，该API控制在ME-主机32上操作的应用的操作。然后，ME-平台83确保ME-主机32上所需的资源(例如，计算资源和存储资源)，并且请求FLUS-接收器应用的执行。因此，FLUS-接收器41被启动。

此外，在执行FLUS-接收器启动处理之后，执行上行链路协议协商处理。

上行链路协议协商处理由FLUS-源21开始，并利用FLUS-接收器41执行。执行在上行链路流送中使用的协议的协商，并且确定该协议。此外，作为上行链路协议协商处理之一，执行针对应用(应用82)组的资源预留可用性确认处理。针对该应用组的资源预留可用性确认处理由FLUS-接收器41开始，并利用ME-平台83执行以确认针对该应用组的资源的预留是否可用。

然后，在执行上行链路协议协商处理之后，在FLUS-源21与FLUS-接收器41之间执行上行链路流送。

此处，如图6所示，FLUS-源21基于服务对象与FLUS-接收器41通信若干次，以执行上行链路协议协商。

例如，服务对象是存储管理从FLUS-源21到FLUS-接收器41的上行链路流送服务的会话所需的信息的对象，并且在服务对象中，从选择作为上行链路协议协商的结果的CandidateDescription(候选描述)中提取的信息被存储在会话对象中。该会话对象中存储有与在流送服务的会话中使用的协议和通信格式有关的信息(会话描述(SessionDescription))，并且包括与在FLUS-接收器的后续级处的下述应用(例如，图11中的应用82)有关的信息(工作流描述)。

具体地，首先，在服务对象中，作为CandidateDescriptions对象，描述用于使用的协议和格式的多个CandidateDescriptions作为候选。然后，FLUS-源21和FLUS-接收器41改变描述以使得能够执行协商(提议/应答交换)。

例如，在作为候选的每个CandidateDescription中，布置标识CandidateDescription本身的sdId、SessionDescription(会话描述)和WorkflowDescription(工作流程描述)。

SessionDescription中存储有会话描述文件(SDP或MPD)的url(或文件体)，该会话描述文件描述了流送协议、传输协议等的媒体容器。工作流程描述表示处理流送所需的应用组，以及执行该组应用所需的网络资源、计算资源、存储资源等。此外，分配给每个CandidateDescriptions的优先级由CandidateDescriptions对象中的列表呈现顺序来表示(例如，呈现排名越高，则优先级越高)。该优先级可以基于任何事物。例如，可以根据网络带宽情况确定优先级，或者可以基于FLUS-源21的网络连接环境在协商中分配优先级。

然后，FLUS-源21和FLUS-接收器41通过以FLUS-源21和FLUS-接收器41期望的优先级顺序在CandidateDescription中列出CandidateDescription并以Service/CandidateDescriptions对象进行通信来执行协商。此后，当最终确定一个候选时，将最终确定的Session/CandidateDescription@sdId的值存储在会话对象的@SessionDescription中，其中Session@active＝‘真’，这指示该会话是被确定为当前活动的会话，并且确定会话。

图7示出了服务对象的结构的示例。

如图7所示，服务对象具有特定于服务的属性组，例如标识服务的ID和一个CandidateDescriptions元素(在其下具有多个CandidateDescription元素)。

此处，已知服务对象(其描述ServiceID等)包括存储会话属性时使用的会话对象。另一方面，在本公开内容中新提出了在服务对象下的CandidateDescriptions/CandididateDescription、在CandididateDescription下的@sdId、@SessionDescription和@WorkflowDescription以及Session@active。

然后，在执行协商之后，如图8所示，将从以上中确定的CandidateDescription@sdId存储在Session@active＝′true′的@SessionDescription中。因此，Session@active＝′true′指示已协商并且确定的流送会话，即已开始处理的流送会话。另一方面，Session@active＝′false(默认)′指示会话尚未开始或已结束。

此外，如图9所示，SDP或MPD的url被存储在CandidateDescription@SessionDescription中。替选地，代替该url，可以存储base64/url编码的SDP或MPD文件体。此时，可以选择以下描述的第一存储方法至第三存储方法中的任何一种。

例如，在第一存储方法中，在SDP文件中的RTP传输的情况下作为示例示出的内容被base64/url编码并且存储在SessionDescription中。例如，在上行链路网络资源充足，不允许延迟并且建立与制作处理系统的直接连接的情况下，优选选择第一存储方法。此时，RTP传输的情况下的堆栈配置如图所示出。

此外，在第二存储方法中，在SDP文件中的通过单向传输的文件递送(FLUTE)传输的情况下作为示例示出的内容被base64/url编码并存储在SessionDescription中。例如，在上行链路网络资源有限并且不允许延迟的情况下优先地选择第二存储方法。此时，在FLUTE传输的情况下的堆栈配置如图所示出。

此外，在第三种存储方法中，在MPD文件中的HTTP传输的情况下作为示例示出的内容被base64/url编码并存储在SessionDescription中。注意，HTTP的类型包括HTTP、HTTP/2和HTTP/3。例如，在上行链路网络资源有限并且维持与分发系统具有高亲和性的格式的情况下优先地选择第三存储方法。此时，HTTP传输的情况下的堆栈配置如图所示出。

此处，在RTP传输的情况下在堆栈配置使用的SMPTE2022是用于存储在IP分组中并发送串行数字接口(SDI)的协议，这是广播设备之间的常规未压缩视频和音频传输方法。同样，SMPTE2110是用于在精确时间协议(PTP)同步中将每个视频/音频分量作为单独的流进行发送的协议。

此外，上述FLUTE是多播中的文件传输协议。例如，FLUTE包括文件递送表(FDT)和多播协议的组合，该文件递送表描述了要传输的文件的传输控制属性，而该多播协议用于被称为分层编码传输(LCT)的可扩展文件对象。常规地开发FLUTE主要用于异步文件传输，但是在作为下一代广播标准的ATSC 3.0中，FLUTE已被扩展成容易地应用于广播实时流送。被称为ROUTE的该扩展版本代替已应用于常规实时流送的RTP，并且针对广播型DASH-fragmentedMP4(fMP4)流送的传输优化该扩展版本。注意，ROUTE中与FDT对应的传输控制元数据被称为基于服务的传输会话实例描述(S-TSID)。

此外，上述HTTP/3是超文本传输协议(HTTP)的新版本，该超文本传输协议是用于Web访问的协议。HTTP/3的特性是使用UDP作为传输层协议。虽然常规的HTTP是使用TCP的典型通信协议之一，但HTTP/3使用UDP而不是TCP来实现高速度Web访问。注意，在HTTP中，广泛使用称为HTTP/1.1的版本，并且还存在HTTP/2，这提高了通信效率。例如，HTTP/2主要由被称为越顶(OTT)的服务提供商使用。

图10示出了用于执行上行链路协议协商的流程图。

在步骤S11中，FLUS-源21生成服务对象，并将提议(offer)发送至FLUS-接收器41。此时，FLUS-源21按参照图9描述的第一存储方法、第二存储方法和第三存储方法的顺序发送提议。注意，将在稍后描述的第二实施方式中描述服务对象的@workflowDescription。

此后，FLUS-接收器41和ME-平台83确认针对该组应用的资源预留是否可用。

在步骤S12中，FLUS-接收器41利用ME-平台83按优先级的降序顺序来确认针对工作流程描述中所描述的每个应用的资源预留是否可用。然后，FLUS-接收器41从在步骤S11中发送的服务对象中描述的多个CandidateDescription候选中确定选择的CandidateDescription。

在步骤S13中，FLUS-接收器41更新服务对象，并且将用作应答的服务对象发送至FLUS-源21。例如，在步骤S12中确定sdId＝′2′的情况下，利用会话@sessionDescription＝′2′来更新服务对象。

<根据第一实施方式的信息处理系统的第二配置示例>

参照图11至图28，将描述作为根据第一实施方式的信息处理系统11A的第二配置示例的上行链路流送中的协议和资源协商(包括在FLUS-接收器的后续级的应用)。

注意，在该第二配置示例中，“用于解决在上行链路传输中使用FLUS以使上行链路传输自适应的情况下发生的用于建立上行链路传输的协议协商问题的提出的方法”中，将描述“在与上行链路媒体流的处理有关的边缘主机中执行的应用组的工作流程描述”。例如，通常，通过列出协议类型(及其参数值)来执行协议协商。另一方面，新提出的是列出“协议属性+后续应用流程的资源要求”，其中协议类型在接收后被绑定到后续应用的流程和资源要求，并将其用作用于协商的材料。此外，WorkflowDescription描述了后续应用的流程和资源要求。

图11示出了根据第一实施方式的信息处理系统11A的第二配置示例。

例如，在信息处理系统11A中，在用户终端14附近的ME-主机31中执行将要连接到用户终端14上的FLUS-源21的FLUS-接收器应用41A。然后，作为特征，执行在所附的“工作流程描述”中定义的后续级的媒体处理服务(应用82-1至82-N)。此外，在信息处理系统11A中，在工作流程描述中描述了所需的资源条件，并且可以按照FLUS-源21侧的意愿进行协商。此外，在信息处理系统11A中，在资源条件的描述中定义了简档(执行应用所需的资源的类别)以简化资源协商。

通常，通过列出发送/接收模块之间的协议类型(及其参数值)来执行协议协商。本公开内容中新提出的是列出“协议属性+后续应用流程的资源需求”，其中，协议类型在接收后被绑定到后续应用的流程和资源需求，并将其用作协商的材料。

如图11所示，信息处理系统11A具有以下配置，其中多个应用82-1至82-N连接在FLUS-接收器应用41A的后续级。然后，在信息处理系统11A中，由FLUS-接收器应用41A接收的上行链路流由在ME-主机31A上执行的应用82-1至82-N处理。

例如，在FLUS-接收器应用41A的后续级的应用82-1至82-N包括高速缓存/存储应用和转码应用。

高速缓存/存储应用是将输入流作为文件存储在诸如存储器和固态驱动器(SSD)之类的存储器中的应用。例如，高速缓存/存储应用提供了根据I/O吞吐量和容错要求的差异来抽象各种类的存储的功能。

转码应用是更改输入流的编码格式的应用。例如，转码应用将由于不良的网络环境而只能以IntraGOP格式进行上行链路传输的流的格式转换为与处理系统(例如制作)具有亲和力的基带(或视觉上无损)格式。注意，当前，提供诸如云上的服务(称为微服务等)之类的媒体处理应用的趋势正在加速。而且，假设将创建下述环境：其中，由在预置环境中运行的昂贵的专业媒体处理设备提供的功能将在时间和数量方面根据需要作为云上的网络服务可用。

此外，将描述应用组的处理顺序，输入/输出参数等的文件称为工作流程描述。在本公开内容中新提出了描述用于媒体处理的工作流程描述的以下方法。换句话说，已知在工作流程描述中列出了相关应用，并且可以根据描述序列的方式，描述各个应用的输入/输出参数的方式来区分顺序处理和并行处理，同时新提出了延迟限制属性。

将参考图12和图13描述工作流程描述的示例。

图12示出了在FLUS-接收器应用41A的后续级处的应用82-1至82-N之间的依赖关系，并且图13示出了原始定义的工作流程描述的示例。此处，工作流程描述被认为是原始定义的工作流程描述，并且目前正在MPEG-I-基于网络的媒体处理(MPEG-I-NBMP)中定义用于云上的媒体处理的工作流程的规范和应用框架，但是尚未完成定义。注意，当前存在的类似标准是MPEG-M。

例如，如图12所示，作为FLUS-接收器应用41A的后续级处的应用82-1至82-N，提供了转码应用(Transcode)、高速缓存/存储应用(Cache/PStorage)和流分发应用(Distribution)。然后，假设在它们之间存在如图中所示的依赖关系(序列)。

然后，如图13所示，例如，工作流程元素的startTime属性指示在预先确定时间表的情况下开始工作流程处理的绝对时间(壁钟时间)。注意，在开始处理的时间没有限制的情况下(在尽力处理是可能的情况下)，未描述该属性。

此外，可以将seq元素或par元素布置为工作流程元素的子元素。seq元素表示在其下的元素中指示的应用的顺序处理，而par元素表示在其下的元素中指示的应用的顺序处理或并行处理。

首先，Seq元素下面的第一个元素是具有url属性值‘FLUS-Sink-url’的Application(应用)元素，其表示作为起点的FLUS-接收器应用的执行。此后，布置par元素，并且在par元素下面，布置具有url属性值‘Transcode-url’的Application元素和具有url属性值‘Cache/PStorage-url’的Application元素。这意味着这两个应用(Transcode应用和Cache/PStorage应用)如图12所示的那样被并行处理，即，它们在时间方面彼此同步地被处理。

此外，在par元素之后，布置具有url属性值‘Distribution-url’的Application元素，这意味着如图12所示的那样最后执行该应用(Distribution应用)。每个应用元素都具有delayLimit属性，以使得能够指定用于处理的延迟限制(在输入的第一位被输出之前的最大允许延迟值(msec))。

在该工作流程中要处理的数据是上行链路流，其是由具有URL属性值‘FLUS-Sink-url’的Application元素表示的FLUS-接收器应用的输入。即，在FLUS-接收器应用与建立上行链路流送会话的FLUS-源21之间执行上行链路协议协商之后，FLLUS-接收器应用的输入流的属性在由CandidateDescription的SessionDescription的url引用的SDP或MPD中表示，CandidateDescription的SessionDescription的url由在应用对象中的具有Session@active＝′true′的Session元素的SessionDescription属性中存储的sdId值(CandidateDescription@sId的确定值)表示。替选地，可以用base64/url编码的SDP或MPD文件体代替该url来表示属性。

然后，由FLUS-接收器应用接收到的上行链路流用作FLUS-接收器应用的输出，并且被接管为Transcode应用和Cache/PStorage应用的输入。即，FLUS-接收器应用的输出被表示为具有url属性值‘FLUS-接收器-url’的Application元素的OutputDescription属性，其等于具有url属性值‘Transcode-url’的Application元素的InputDescription属性和具有url属性值‘Cache/PStorage-url’的Application元素的InputDescription属性。

此外，例如，在具有URL属性值‘FLUS-接收器-url’的Application元素的OutputDescription属性中，基于图14所示的描述模板来指定目标流及其属性。注意，在FLUS-接收器41的情况下，由于上行链路流被按原样接收并且被直接传递给后续应用，因此流的属性不改变，并且根据需要仅改变诸如url的地址。

此处，在以上提及的工作流程描述方法中，用于描述Seq元素中的顺序处理的方法和用于描述Par元素中的并行处理的方法都是已知的。另一方面，在本公开内容中新提出增加输入和输出的描述以及每个应用所需的资源的描述。此外，在本公开内容中新提出用于描述如图14至图18所示的那样限定的每个应用的输入和输出的方法。

图14是示出用于描述从FLUS-接收器41(FLUS-接收器应用41A)的输出的方法的示例的图。

如图中所示，在输出MPD或SDP中描述了用于在FLUS-接收器41的后续级处的处理的流的属性。

注意，在MPD(或在ROUTE的情况下为S-TSID)中包括多个流的情况下，这些流中之一由XPath指定。关于该XPath，这同样适用于图15至图18。

图15示出了用于描述向转码处理单元43(多个应用82中的一个Transcode应用)中的输入的方法的示例。

如图中所示，输入到转码处理单元43中的InputDescription具有与从FLUS-接收器41输出的OutputDescription(图14)相同的内容。

图16示出了用于描述向数据保留处理单元(Cache/PStorage)42(多个应用82中的一个Cache/PStorage应用)中的输入的方法的示例。

如图中所示，输入到数据保留处理单元(Cache/PStorage)42中的InputDescription具有与从FLUS-接收器41输出的OutputDescription(图14)相同的内容，该数据保留处理单元42接收与转码处理单元43接收的流相同的流。此外，在数据保留处理单元(Cache/PStorage)42的情况下，可以将绝对时间或从输入时间起的相对时间指定为用于保留在用作存储装置(在存储器、SSD、硬盘等上)的存储设备45中的存储期限。注意，在设置用于删除的期限的情况下，可以在输入描述的存储期限中指定期限。

此外，由于数据保留处理单元(Cache/PStorage)42仅执行用于将输入流存储在存储设备45中的处理，因此未指定接管该流的应用。即，以由实现Cache/PStorage系统的Web服务器、文件系统等提供的文件访问方法，由另一应用按照文件的存储期限，根据需要访问并获取存储在存储设备45中的流文件。

另一方面，在转码处理单元43中，当对输入流进行转码时，通过诸如MPD和SDP的流的属性来指定经转码的流的属性。然后，如图17中所示，在从转码处理单元43输出的OutputDescription中指定属性。注意，在输出MPD或SDP中描述了经转码的流的属性。

图18示出了用于描述向分发处理单元52(多个应用82中的一个Distribution应用)中的输入的方法的示例。

从转码处理单元43输出的经转码的流被接管为到分发处理单元52中的输入。即，从转码处理单元43输出的OutputDescription在属性方面等于具有url属性值‘Distribution-url’的Application元素的InputDescription，并且可以指定分发期限。

然后，由于分发处理单元52执行用于经由云将输入流分发至客户端设备的处理，因此分发处理单元52不具有OutputDescription。即，以通过实现分发系统的Web服务器、流服务器等提供的流访问方法，客户端侧按照分发期限来获取和接收流。注意，在设置用于分发停止的期限的情况下，可以在输入描述的分发期限中指定期限。

图19示出了表示诸如FLUS-接收器应用41A和应用82-1至82-N(Transcode应用、Cache/PStorage应用和Distribution应用)的应用的属性的应用对象的示例。例如，在ME-平台中管理应用对象的属性的定义，并且基于该属性的定义来管理每个应用的属性。

应用URL(+提供商URL)标识Transcode应用、Cache/PStorage应用、Distribution应用等的类型(+可选地，标识提供商URL)。例如，应用URL由工作流程中描述的Application@url指定。

实例URI在应用被执行时标识该应用，并且在应用被执行时由ME-平台生成。

MEC系统-URI、版本(MEC system-URI,version)是标识在其中执行应用的MEC系统(虚拟环境)的标识符。

输入描述(Input Description)和输出描述(Output Description)描述了输入和输出的url以及应用的协议，并且例如在工作流程描述中描述的Application/InputDescription和/OutputDescription中指定。概要描述(Overview Description)描述了应用的处理的概要。

资源需求包括指定的值，例如虚拟CPU使用量/秒+周期、虚拟存储器/存储容量/秒+周期和IO吞吐量/秒+周期，并且由MEC系统-URL相关资源类ID来限定。例如，在工作流程描述中描述的ResourceDescription中指定了资源需求。

应用封装(URL、图像体)是MEC系统相关应用执行图像的url或图像体。

业务/DNS规则(滤波器/DNS记录)是控制5G系统中的分组经由ME-平台的路由的信息。

参照图20至图24，将描述在与在图11中的信息处理系统11A中相同的ME-主机31中的FLUS-接收器应用41A的后续级处连接应用82的配置中的处理。

图20是示出在图11的信息处理系统11A中的用于开始上行链路流送的处理的图。即，图20示出了用于在与FLUS-接收器应用41相同的ME-主机31中执行在FLUS-接收器应用41A的后续级处的应用82的情况下启动应用82的处理的示例。

首先，执行FLUS-接收器启动处理。

FLUS-接收器启动处理由FLUS-源21开始，并利用ME-平台83执行，这使FLUS-接收器应用41A被启动。此外，作为FLUS-接收器启动处理之一，执行FLUS-接收器资源预留和生成处理。FLUS-接收器资源预留和生成处理由ME-平台83开始并且利用FLUS-接收器应用41A执行，这使FLUS-接收器应用41A的资源被预留和生成。

此外，在执行FLUS-接收器启动处理之后，执行上行链路协议协商处理。

上行链路协议协商处理由FLUS-源21开始，并利用FLUS-接收器应用41A来执行。执行对在上行链路流送中使用的协议的协商。此外，在上行链路协议协商处理中，分析在FLUS-接收器应用41A与FLUS-源21之间的通信中使用的服务对象中描述的CandidateDescription的工作流程描述。

例如，如图21中所示的那样来描述该工作流程描述，并且在该工作流程描述中，来自FLUS-接收器的输出被链接到Production(制作)应用，如图22所示。

例如，在以FLUS-源21用作起点的FLUS-接收器启动处理中参考图21所示的Workflow/Seq/Application[@url＝'FLUS-Sink-url']/ResourceDescription中描述的FLUS-接收器应用所需的资源(在Workflow元素下的Seq元素中的具有url属性值‘FLUS-Sink-url’的Application元素下的ResourceDescription元素)。

此外，从FLUS-源21接收到FLUS-接收器启动请求的ME-平台83在其自己的ME-主机31上检查是否满足该ResourceDescription中描述的资源需求。然后，在可以满足资源需求的情况下，ME-平台83生成新的FLUS-接收器应用41A，并将FLUS-接收器应用41A的地址返回至FLUS-源21。

然后，例如，如图23所示，在FLUS-源21与FLUS-接收器41之间执行上行链路协议协商。

首先，FLUS-接收器应用41A按优先级顺序分析从FLUS-源21接收到的会话对象中的CandidateDescriptions中的每个CandidateDescription的工作流程描述。以这种方式，FLUS-接收器应用41A检查是否可以确保每个后续应用82-1至82-N所需的资源。

例如，在图20所示的处理的情况下，FLUS-接收器应用41A开始启动作为多个应用82之一的Production应用的阶段。然后，访问由ME-平台83提供的API，并且确保了Workflow/Seq/Application[@url＝′Production-url′]/ResourceDescription中描述的资源。这允许FLUS-接收器应用41A启动作为多个应用82之一的Production应用。

然后，在执行上行链路协议协商处理之后，在FLUS-源21与FLUS-接收器应用41A之间执行上行链路流送，并且由Production应用执行制作处理。

图24是示出其中启动应用的实体启动应用的处理的流程图。

例如，在要启动的应用是FLUS-接收器应用41A的情况下，启动该应用的实体是FLUS-源21。此外，在要启动的应用是在工作流程描述中描述的任何应用的情况下，启动应用的实体是FLUS-接收器应用41A。

在步骤S21中，启动应用的实体根据应用定义来生成应用对象，并请求ME-平台83执行该应用。此时，在工作流程描述的ResourceDescription中描述的所需资源需求被存储在由启动应用的实体发送的应用对象的资源需求中。

在步骤S22中，ME-平台83尝试在基于应用对象的内容执行应用之前，确保执行应用所需的各种资源，例如计算资源、存储器/存储装置和网络资源。

在步骤S23中，ME-平台83确定是否已经通过步骤S22中的尝试而确保了资源。

在ME-平台83在步骤S23中确定已确保资源的情况下，处理进行至步骤S24。

在步骤S24中，ME-平台83生成标识应用对象的应用实例的实例ID并且执行应用。

在步骤S25中，在随着在步骤S24中ME-平台83已执行应用而启动要启动的应用之后，该应用等待根据输入描述的输入对象(文件、流等)，并且待机以待处理。然后，当要启动的应用接收到输入对象时，该应用开始处理。

相反，在步骤S23中ME-平台83确定尚未确保期望的资源的情况下，处理进行至步骤S26。然后，ME-平台83向启动应用的实体返回NACK响应并发送未能确保资源的应用对象。

在步骤S27中，在应用具有多个ResourceDescription的情况下，启动应用的实体重写应用对象的资源需求部分，并且请求ME-平台83再次执行该应用。然后，处理返回至步骤S21，发送重写的应用对象，然后重复类似的处理，直到达到被设置为期限的时间限制。注意，在达到该时间限制的情况下，这意味着应用启动失败。

然后，在启动要启动的应用之后，FLUS-源21开始上行链路流送，并且FLUS-接收器应用41A将接收到的流移交给Production应用，以使Production处理被执行。

注意，在稍后描述的第三实施方式和第四实施方式中，在启动应用的实体是SourceMEHost的FLUS-接收器41S的情况下，要启动的应用是TargetMEHost的FLUS-接收器41T。

将参照图25至图28描述每个应用的资源描述。

例如，在工作流程描述中的针对每个应用的ResourceDescription中，描述了执行每个应用所需的资源。通常，执行应用所需的资源为：

-CPU使用量/秒+周期(指定的时间/绝对时间)，

-存储器/存储容量/秒+周期(指定的时间/绝对时间)，

-IO吞吐量/秒+周期(指定的时间/绝对时间)，

等。

然而，假设借助于这样的数值表达式为每个应用预留资源是复杂的。因此，通过将它们分组成若干个集合并定义用于概要分析的词典，可以简化工作流程描述中的资源描述。例如，如果词典是不依赖于提供MEC环境的供应商的通用词典，则可以在不依赖于不同供应商提供的MEC环境之间的差异的情况下与MEC环境无关地指定词典。

此外，通用资源类标识符‘urn:generic_resource_class:class-x’被定义成使得可以由标识符引用以上集合。替选地，可以准备MEC系统相关词典，并且可以将MEC系统标识符和MEC系统相关资源类标识符的集合表示为‘urn:vendor_specific_resource_class:vendor_x:class-x’。

在使用这两个表达式的情况下，定义图25所示的映射。即，定义通用资源类标识符和MEC系统相关资源类标识符的等效集合。

此外，如图26所示，作为MEC系统相关词典的项，将CPU使用量/秒+周期、(易失性)存储器/(非易失性)存储容量/秒+周期以及IO吞吐量/秒+周期定义为集合。然后，通过这些项和时间(一段时间或绝对开始时间/绝对结束时间)的组合来表达资源。此外，由上行链路流送的使用实例的典型值来表示项名称‘class-1’、‘class-11’等。

具体地，AVC-UHDTV(4K，10，4:2:2)-LongGOP-DASH指示以下使用实例，其中，4K(3840×2160)-UHDTV(10bit/4:2:2)流以200Mbps被AVC编码并且在若干个帧(LongGOP)DASH/CMAF中被流送。注意，该流被存储在非易失性存储装置上的高速缓存器中的使用实例被表示为AVC-UHDTV(4K，10，4:2:2)-LongGOP-DASH-onPStorage。此外，AVC-UHDTV(4K，10，4:2:2)-AllIntra-DASH指示以下使用实例，其中在一帧(IntraGOP)DASH/CMAF中以600Mbps来流送流。注意，该流被存储在非易失性存储装置上的高速缓存器中的使用实例被表示为AVC-UHDTV(4K，10，4:2:2)-AllIntra-DASH-onPStorage。

然后，基于典型的代表性协议集合和参数值，通过使用适当的参考流进行粗略测量，预先为每个目标MEC系统定义该集合。

图27示出了资源描述的示例。

如图27所示，对于ResourceClass@id，指定如以上图25中所示的通用资源类标识符、MEC系统相关资源类标识符等。此外，ResourceClass@t指示保持它的时间(秒)。

此外，如图28所示，在执行时间具有绝对时间的开始和结束的情况下，开始时间由ResourceClass@startTime指示，并且结束时间由ResourceClass@endTime指示。该示例指示从startTime到endTime预留1TB(百万兆字节)的存储。

<第二实施方式>

参照图29至图32，作为第二实施方式，将描述在不同的ME-主机31中连接在FLUS-接收器41的后续级处的应用82的情况(ME-主机31的资源不足的情况)的示例。

即，第二实施方式具有以下特性：在不能确保FLUS-接收器41的后续级处的应用82所需的资源的情况下，在满足资源需求的多个ME-主机31上执行应用82。

图29示出了由于ME-主机31上的计算资源、存储资源等的限制而不能在正在运行FLUS-接收器41的ME-主机31上执行Production应用的情况下的开始上行链路流送的处理。

在这种情况下，如图29所示，假设ME-平台83从多个ME-主机31中搜索最佳ME-主机31并且执行Production应用。此外，ME-平台83用作如图3所示的ME-协调器33，即，起到协调多个ME-主机31的作用。

首先，执行FLUS-接收器启动处理。

FLUS-接收器启动处理由FLUS-源21开始，并利用ME-平台83执行，这使FLUS-接收器41启动。此外，作为FLUS-接收器启动处理之一，执行FLUS-接收器资源预留和生成处理。FLUS-接收器资源预留和生成处理由ME-平台83开始，并且FLUS-接收器41的资源被预留以及生成。

在执行FLUS-接收器启动处理之后，执行上行链路协议协商处理。

上行链路协议协商处理由FLUS-源21开始并且利用ME-平台83执行，并且执行上行链路传输所需的协议的协商。此外，作为上行链路协议协商处理之一，执行针对应用组的资源预留可用性确认处理。针对该应用组的资源预留可用性确认处理由FLUS-接收器41开始，并且利用ME-平台83执行以确认针对该应用组的资源预留是否可用。

然后，作为针对该应用组的资源预留可用性确认处理之一，执行Production启动处理。Production启动处理由FLUS-接收器41开始，并利用ME-平台83来执行。ME-平台83在其自己的ME-主机31中预留资源，并且在ME-平台83未能这样做的情况下，ME-平台83利用用作ME-协调器33的ME-平台83执行Production启动处理。

因此，用作ME-协调器33的ME-平台83从多个ME-主机31中搜索最佳ME-主机31，并且在该ME-主机31中执行Production应用。

然后，在执行上行链路协议协商处理之后，在FLUS-源21与FLUS-接收器41之间执行上行链路流送，并且由Production应用执行制作处理。

图30示出了用于在存在要由FLUS-接收器41和ME-主机31执行的一个应用82((Cache/PStorage)应用)以及存在要由另一ME-主机31执行的一个应用82(Distribution应用)的情况下开始上行链路流送的处理。

首先，FLUS-源21执行FLUS-接收器启动处理以启动FLUS-接收器41。然后，在执行FLUS-接收器启动处理之后，执行上行链路协议协商处理。

在上行链路协议协商处理中，FLUS-接收器41分析用于与FLUS-源21进行通信的在服务对象中描述的CandidateDescription的工作流程描述。在该工作流程描述中，FLUS-接收器41的输出链接至执行高速缓存/存储处理的Cache/PStorage应用以及执行到流回放客户端的下行链路流送处理的Distribution应用。

此处，假如由于资源限制，不能在与FLUS-接收器41的ME-主机31相同的ME-主机31上执行Cache/PStorage应用和Distribution应用(Distribution资源的预留失败)。此时，在找到可以满足Distribution的资源需求的不同ME-主机31的情况下，在不同的ME-主机31上执行Distribution应用。

图31示出了在这种情况下的工作流程描述的描述示例，并且如图32所示，FLUS-接收器的输出被接至Cache/PStorage应用和Distribution应用。

<第三实施方式>

参照图33至图38，作为第三实施方式，将描述由于FLUS-源21在基站13之间的切换而引起的FLUS-接收器41和后续的应用82在ME-主机31之间的转移。

即，第三实施方式具有以下特性：在ME-主机31的环境由于FLUS-源21在基站13之间的切换而转变的情况下，执行包括确保后续的应用82所需的资源的协议协商。

图33示出了根据第三实施方式的信息处理系统11B的配置示例。

此处，考虑如下情况：当实现诸如图1所示的摄像装置的FLUS-源21的用户终端14移动以跟随被摄体时，用户终端14在每个都实现ME-主机31的基站13之间切换。此时，假设在每个基站13上实现ME-主机31。

此外，在下面的描述中，切换之前的接入网络72被称为源接入网络72S，并且切换之前的ME-主机31被称为源ME-主机31S。类似地，切换的目的地中的接入网络72被称为目标接入网络72T，并且切换的目的地中的ME-主机31被称为目标ME-主机31T。

然后，如图33所示，提供了绑定至预定基站13的源ME-主机31S上的FLUS-接收器应用41S和经由源接入网络72S进行上行链路流送的FLUS-源21。假设实现该FLUS-源21的用户终端14移动到目标ME-主机31T绑定至的基站13中的目标接入网络72T。

以下将描述这样的配置中的处理流程。

图38示出了上行链路流送已经开始之后的流程。注意，在图38中，省略了FLUS-源21启动源ME-主机31S上的FLUS-接收器41S的阶段以及如以上所述的那样执行上行链路协议协商的阶段。

例如，如图36所示，存在与源ME-主机31S上的FLUS-接收器41S进行上行链路流送的FLUS-源21。此外，数据保留处理单元(Cache/PStorage)42S和分发处理单元52连接至FLUS-接收器41S的后续级。此处，数据保留处理单元(Cache/PStorage)42和分发处理单元52是作为应用82执行的Cache/PStorage应用和Distribution应用。此外，在图36所示的示例中，在与FLUS-接收器41S的ME-主机32不同的ME-主机32上执行Distribution应用。

然后，实现FLUS-源21的用户终端14移动至基站13中的目标接入网络72T，作为不同的ME-主机的目标ME-主机31T绑定至该基站13。此时，正在源ME-主机31S上执行的Cache/PStorage应用转移至目标ME-主机31T。此处，转移并不意味着应用与其状态信息一起移动，而是意味着在转移目的地中的目标ME-主机31上单独生成相应的应用。即，应用的状态信息不移动。

此外，正在源ME-主机31S上运行的FLUS-接收器41S可以检测用户终端14的移动(位置)，在该用户终端14上由ME-平台83S提供的API实现FLUS-源21。然后，假设根据每个时间点处的位置转移信息、统计信息、使用AI的移动性模式分析等来预测用户终端14从用户终端14当前所在的源接入网络72S到作为不同接入网络的目标接入网络72T的移动(到图38中的目标ME-主机的转移的预测)。注意，假设在作为转移目的地的目标接入网络72T的基站上实现目标ME-主机31T。此时，源ME-主机31S上的FLUS-接收器41S请求ME-协调器33在目标ME-主机31T上执行FLUS-接收器41T和随后的应用(图38中的(目标ME-主机处的)FLUS-接收器启动)。

此时，将基于与当前建立的会话的协议资源需求相同的协议资源需求或从Service/CandidateDescriptions中列出的CandidateDescription候选的列表中按优先级顺序尝试为应用预留资源(图38中的FLUS-接收器资源预留/生成)。此处，在CandidateDesription中引用的协议和Workflow-Description中描述协议资源要求，CandidateDesription通过存储在具有Service/Session[@state＝′active′]的SessionDescription中的sdId引用。

此外，此时，如图34所示，可以通过给出关于转移之后的会话候选选择的策略的指令的Service/Policy/KeepAlreadyEstablishedIfFailed中的标志(true：保持当前会话，false：候选优先级顺序)来确定是否保持当前建立的会话或尝试按候选列表中的优先级执行应用。在该标志不存在的情况下，指定KeepAlreadyEstablishedIfFialed＝′false′(默认)。即，将尝试ME-主机31的转移以尽可能多地利用MEC。

此外，虽然目标ME-主机31T上的FLUS-接收器41T和后续的应用在预留所需资源(图38中的应用组资源预留可用性确认)时被启动时，但是该处理不是立即开始，而是在流实际到达之后执行实际处理。假设随着时间进一步过去，源ME-主机31S上的FLUS-接收器41S经由ME-平台83S检测到实现了FLUS-源21的用户终端14移动并连接至新的目标接入网络72T，目标ME-主机31T绑定至该目标接入网络72T(图38中的FLUS-源到目标ME-主机的转移的检测)。

响应于此，改变业务，使得在目标ME-主机31T上待机的FLUS-接收器41T可以从转移之后的目标接入网络72T接收流(图38中的到目标ME-主机的业务更新)。因此，处于待机状态的FLUS-接收器41T和数据保留处理单元(Cache/PStorage)42开始处理经由转移之后的目标接入网络72T从FLUS-源21发送的上行链路流(图38中的到目标ME-主机的上行链路流送)。

注意，在不允许包括FLUS-接收器41的应用在ME-主机31之间的转移本身的情况下，可以如图35所示的那样指定Policy@DoNotMigrate＝′true′。注意，在该标志为真的情况下，未指定KeepAreadyEstablishedIfFailed。

<第四实施方式>

参照图39至图48，作为第四实施方式，将描述FLUS-接收器41和后续的应用在ME-主机31之间的转移(ME-主机31的资源不足的情况)。

即，第四实施方式具有以下特性：在ME-主机31的环境由于FLUS-源21在基站13之间的切换而转变的情况下，选择可以确保后续的应用所需的资源的MH-主机。

图39示出了作为根据第四实施方式的信息处理系统的配置示例的在目标ME-主机31T上不能确保足够的资源并且在目标ME-主机31T上不能执行期望的应用的情况的示例。

即，图39示出了如下情况的示例：当如图40所示，随着FLUS-源21从源RAN移动到目标RAN而移交FLUS-源21时，FLUS-接收器41可以在目标ME-主机31T上执行，但不能启动Cache/PStorage应用。

在这种情况下，执行参照图41描述的处理。

即，源ME-主机31S上的FLUS-接收器41S请求ME-协调器33在目标ME-主机31T上执行FLUS-接收器41T和Cache/PStorage，但是仅Cache/PStoage不能满足资源需求并且无法被执行(图41中的Cache/PStoage资源预留/失败)。在这种情况下，预先明显的是，即使在实现FLUS-源21的用户终端14被转移至目标ME-主机31T绑定至的目标接入网络72T的情况下，目标ME-主机31T上的Cache/PStorage不能处理用作来自FLUS-接收器41T的输出的上行链路流。因此，即使在发生转移的情况下，源ME-主机31S上的数据保留处理单元(Cache/PStorage)42S也处于待机状态，使得可以维持数据保留处理单元(Cache/PStorage)42S的执行状态。

此后，随着时间的过去，源ME-主机31S上的FLUS-接收器41S经由ME-平台83S检测到实现FLUS-源21的用户终端14移动并且连接至目标ME-主机31T绑定至的新RAN(图41中的FLUS-源到目标ME-主机的转移的检测)。响应于此，改变业务，使得在目标ME-主机31T上待机的FLUS-接收器41T可以从转移之后的目标接入网络72T接收上行链路流(图41中的到目标ME-主机的业务更新)。

因此，处于待机状态的FLUS-接收器41T开始处理经由转移之后的目标接入网络72T从FLUS-源21发送的上行链路流(图38中的到目标ME-主机的上行链路流送)。然而，由于后续的Cache/PStorage不在同一目标ME-主机31T上启动，因此FLUS-接收器41的输出流被发送至转移之前执行的源ME-主机31S上的数据保留处理单元(Cache/PStorage)42S。

接下来，图42所示的框图示出了如下示例，其中，在不能预测到转移目的地小区(接入网络72)的情况下，在分别与可以作为转移目的地的两个小区绑定的目标ME-主机31T-A和目标ME-主机31T-B上执行FLUS-接收器41和Cache/PStorage的集合。注意，如图43所示，可以作为转移目的地的两个小区是目标RAN-A和目标RAN-B。此处，示出了FLUS-源21最终被转移至与目标ME-主机31T-A绑定的目标接入网络72T-A的情况。

在这种情况下，执行图44所示的处理。

图44示出了上行链路流送已经开始之后的流程。

例如，假设FLUS-接收器41预测到用户终端14从用户终端14当前存在的源接入网络72S移动到作为不同的接入网络的目标接入网络72T-A或72T-B(图44中的到目标ME-主机A或B的转移的预测)。

此时，源ME-主机31S上的FLUS-接收器41S请求ME-协调器33在目标ME-主机31T-A和31T-B上执行FLUS-接收器41T-A和41T-B以及后续的应用(图44中的FLUS-接收器(目标ME-主机A&B处的)启动)。

然后，分别在FLUS-接收器41与目标ME-主机31T-A之间以及FLUS-接收器41与目标ME-主机31T-B之间执行上行链路协议协商，并且在目标ME-主机31T-A和目标ME-主机31T-B中分别执行针对该应用组的资源预留可用性确认。

假设随着时间的过去，检测到实现FLUS-源21的用户终端14移动并连接至目标ME-主机31T-A绑定至的新目标接入网络72T-A(图44中的FLUS-源到目标ME-主机A的转移的检测)。

响应于此，改变业务，使得在目标ME-主机31T-A上待机的FLUS-接收器41T-A可以从转移之后的目标接入网络72T-A接收流(图44中的到目标ME-主机A的业务更新)。因此，处于待机状态的FLUS-接收器41T-A和数据保留处理单元(Cache/PStorage)42-A开始处理经由转移之后的目标接入网络72T-A从FLUS-源21发送的上行链路流(图44中的到目标ME-主机A的上行链路流送)。

接下来，图45所示的框图是确保容错冗余的示例，其中在绑定至覆盖范围交叠的两个小区(目标接入网络72T-A和72T-B)的ME-主机31(目标ME-主机31T-A和31T-B)上执行FLUS-接收器41和Cache/PStorage的集合，并且其中两个上行链路会话被同步并执行。

例如，假设转移的FLUS-源21如图46所示的那样同时连接至目标RAN-A和目标RAN-B两者。在这种情况下，假设目标ME-主机31T-A上的FLUS-接收器41T-A的输出或目标ME-主机31T-B上的FLUS-接收器41T-B的输出被输入到Distribution应用中。

在这种情况下，执行参照图47描述的处理。

图47示出了上行链路流送已经开始之后的流程。

例如，假设FLUS-接收器41预测到用户终端14从用户终端14当前存在的源接入网络72S移动到作为不同的接入网络的目标接入网络72T-A或72T-B(图47中的到目标ME-主机A或B的转移的预测)。

此时，源ME-主机31S上的FLUS-接收器41S请求ME-协调器33在目标ME-主机31T-A和31T-B上执行FLUS-接收器41T-A和41T-B以及后续的应用(图47中的(目标ME-主机A&B处的)FLUS-接收器启动)。

然后，分别在FLUS-接收器41与目标ME-主机31T-A之间以及FLUS-接收器41与目标ME-主机31T-B之间执行上行链路协议协商，并且在目标ME-主机31T-A和目标ME-主机31T-B中分别执行针对该应用组的资源预留可用性确认。

假设随着时间进一步过去，检测到实现FLUS-源21的用户终端14移动并连接至目标ME-主机31T-A和31T-B分别绑定至的新的目标接入网络72T-A和72T-B(图47中的FLUS-源到目标ME-主机A或B的转移的检测)。

响应于此，改变业务，使得在目标ME-主机31T-A和31T-B上待机的FLUS-接收器41T-A和41T-B可以从转移之后的目标接入网络72T-A和72T-B接收流(图47中的到目标ME-主机A&B的业务更新)。因此，处于待机状态的FLUS-接收器41T-A和数据保留处理单元(Cache/PStorage)42-A开始处理经由转移之后的目标接入网络72T-A和72T-B从FLUS-源21发送的上行链路流(图44中的到目标ME-主机A的上行链路流送以及到目标ME-主机B的上行链路流送)。

该冗余配置可以通过在如图48所示的工作流程描述中将目标应用的Service元素的重复属性设置为‘true’来指定。

注意，在以上实施方式的描述中，尽管FLUS-源21生成服务对象并将服务对象发送至FLUS-接收器41，但是FLUS-接收器41可以生成服务对象。此外，FLUS-接收器41可以向FLUS-源21发送服务对象，并且FLUS-源21可以从服务对象中选择CandidateDescription，更新服务对象，并且将服务对象发送至FLUS-接收器41。即，FLUS-源21或FLUS-接收器41均可以开始处理，只要FLUS-源21和FLUS-接收器41发送和接收服务对象、对上行链路所需的协议进行协商并且执行对内容上行链路流的控制协议协商即可。

<计算机的配置示例>

接下来，可以通过硬件或软件来执行上述一系列处理(信息处理方法)。在通过软件执行一系列处理的情况下，包括软件的程序被安装在通用计算机等中。

图49是示出安装执行以上提及的一系列处理的程序的计算机的实施方式的配置示例的框图。

程序可以预先记录在用作内置在计算机中的记录介质的硬盘105或ROM 103上。

替选地，程序可以存储(记录)在由驱动器109驱动的可移除记录介质111中。这样的可移除记录介质111可以作为所谓的封装软件来提供。此处，可移除记录介质111的示例包括软盘、致密盘只读存储器(CD-ROM)、磁光(MO)盘、数字多功能盘(DVD)、磁盘和半导体存储器等。

注意，程序不仅可以如上所述从可移除记录介质111安装在计算机中，而且也可以经由通信网络或广播网络下载至计算机并且安装在内置硬盘105中。即，例如，程序可以经由用于数字卫星广播的人造卫星从下载站点无线地传送到计算机，或者经由诸如局域网(LAN)和因特网的网络有线地传送到计算机。

计算机具有内置在其中的中央处理单元(CPU)102，并且输入/输出接口110经由总线101连接至CPU 102。

当由用户操作输入单元107以使命令经由输入/输出接口110输入时，CPU 102根据该命令执行在只读存储器(ROM)103中存储的程序。替选地，CPU 102将存储在硬盘105中的程序加载到随机存取存储器(RAM)104中并执行该程序。

因此，CPU 102执行根据以上提及的流程图的处理或根据以上提及的框图的配置的处理。然后，例如，CPU 102根据需要从输出单元106输出处理结果，从通信单元108发送处理结果，或者经由输入/输出接口110将处理结果记录在硬盘105中。

注意，输入单元107包括键盘、鼠标、麦克风等。此外，输出单元106包括液晶显示器(LCD)、扩音器等。

此处，在本说明书中，由计算机根据程序执行的处理不必按照流程图中描述的顺序按时间顺序执行。即，由计算机根据程序执行的处理还包括并行或单独执行的处理(例如，并行处理或者由对象进行的处理)。

此外，程序可以通过一个计算机(处理器)处理或者可以由多个计算机以分布式方式处理。此外，程序可以被传送至远程计算机并被执行。

此外，在本说明书中，系统是指多个部件(装置、模块(部件)等)的集合，并且所有部件是否都在同一壳体中并不重要。因此，容纳在单独的壳体中并经由网络连接的多个设备的集合和具有容纳在一个壳体中的多个模块的设备两者都是系统。

此外，例如，被描述为一个设备(或处理单元)的配置可以被划分且被配置为多个设备(或处理单元)。相反，以上被描述为多个设备(或处理单元)的配置可以被共同配置为一个设备(或处理单元)。此外，应当理解，可以将除了上述配置之外的配置添加到每个设备(或每个处理单元)的配置。此外，只要整个系统的配置和操作基本相同，则一个设备(或处理单元)的配置的一部分可以包括在另一设备(或另一处理单元)的配置中。

此外，例如，本技术可以被配置为云计算，其中一种功能由多个设备经由网络共享并协同处理。

此外，例如，可以在任意设备中执行以上提及的程序。在这种情况下，设备仅需要具有必要的功能(功能块等)并且能够获取必要的信息。

此外，例如，以上提及的流程图中描述的每个步骤不仅可以由一个设备执行，而且还可以由多个设备共享并执行。此外，在一个步骤包括多个处理的情况下，该步骤中包括的多个处理不仅可以由一个设备执行，而且还可以由多个设备共享并执行。换言之，可以将一个步骤中包括的多个处理执行为多个步骤的处理。相反，被描述为多个步骤的这些处理可以作为一个步骤被共同执行。

注意，在由计算机执行的程序中，用于描述程序的步骤的处理可以以本说明书中描述的顺序按时间顺序执行，或者可以并行地执行或在必要的时间例如在执行调用时单独执行。即，除非是矛盾的，否则可以以与以上提及的顺序不同的顺序执行步骤的处理。此外，用于描述该程序的步骤的处理可以与另一程序的处理并行执行，或者可以与另一程序的处理组合执行。

注意，除非是矛盾的，否则可以独立地和单独地执行本说明书中描述的多个本技术。应当理解，可以组合地执行多个本技术中的一些。例如，在实施方式中的一个实施方式描述的本技术的一些或全部可以与在实施方式中的另一个实施方式中描述的本技术的一些或全部结合。此外，上述任何本技术的一部分或全部可以与以上未描述的另一技术组合地进行。

<配置组合的示例>

注意，本技术可以采用以下配置。

(1)

一种信息处理装置，包括：

通信模块，其执行针对内容上行链路流的协议协商，

其中，所述通信模块：

向其他通信装置发送服务对象，所述服务对象包括在所述协议协商中使用的与内容的流有关的信息；

从所述其他通信装置接收基于所述服务对象发送的用于协商的信息；以及

与所述其他的通信装置之间执行所述内容上行链路流的控制协议协商。

(2)

根据上述(1)所述的信息处理装置，

其中，在所述服务对象中，用于在所述内容上行链路流中使用的协议和格式的多个候选描述被描述为候选。

(3)

根据上述(2)所述的信息处理装置，

其中，所述服务对象包括分配给所述多个候选描述中的每个候选描述的优先级。

(4)

根据上述(3)所述的信息处理装置，

其中，所述优先级是根据网络带宽情况确定的。

(5)

根据上述(2)或(3)所述的信息处理装置，

其中，所述多个候选描述中的每个候选描述包括工作流程描述，所述工作流程描述定义与所述其他通信装置中的媒体处理有关的其他应用以及所述媒体处理所需的资源条件。

(6)

根据上述(2)至(5)中任一项所述的信息处理装置，

其中，用于所述协商的信息包括由所述其他通信装置基于所述服务对象选择的所述候选描述的信息。

(7)

根据上述(6)所述的信息处理装置，

其中，基于用于所述协商的信息，在所述服务对象中基于从所述服务对象选择的所述候选描述来存储会话对象。

(8)

根据上述(1)至(7)中任一项所述的信息处理装置，

其中，所述服务对象是由所述通信模块生成的，所述通信模块用作在所述内容上行链路流中发送内容的一侧。

(9)

根据上述(1)至(8)中任一项所述的信息处理装置，

其中，多个所述信息处理装置经由网络连接以形成信息处理系统，并且

在位于所述其他通信装置附近的所述信息处理装置中，执行用作所述通信模块的应用，并且在用作所述通信模块的应用的后续级处连接其他应用并且执行所述其他应用。

(10)

根据上述(9)所述的信息处理装置，

其中，在位于所述其他通信装置附近的所述信息处理装置中不能确保在用作所述通信模块的应用的后续级处连接的所述其他应用所需的资源的情况下，

在除了执行用作所述通信模块的应用的所述信息处理装置之外的其他的所述信息处理装置上执行所述其他应用。

(11)

根据上述(10)所述的信息处理装置，

其中，当由于所述其他通信装置的移动而发生切换时，转移前的作为第一装置的信息处理装置与转移后的作为第二装置的信息处理装置协商以确保所述其他应用所需的资源。

(12)

根据上述(11)所述的信息处理装置，

其中，在转移前的作为第一装置的信息处理装置中保持所述其他应用的第一部分的状态下，在转移后的作为第二装置的信息处理装置中执行除所述第一部分之外的第二部分。

(13)

根据上述(12)所述的信息处理装置，

其中，在作为转移后的作为第二装置的信息处理装置的多个所述信息处理装置中执行所述其他应用。

(14)

根据上述(1)至(7)中任一项所述的信息处理装置，

其中，所述服务对象是由所述通信模块生成的，所述通信模块用作在所述内容上行链路流中接收内容的一侧。

(15)

根据上述(1)至(8)和(14)中任一项所述的信息处理装置，

其中，多个所述其他通信装置经由网络连接以形成信息处理系统，并且

在位于所述信息处理装置附近的所述其他通信装置中，执行用作所述通信模块的应用，并且在用作所述通信模块的应用的后续级处连接其他应用并且执行所述其他应用。

(16)

根据上述(15)所述的信息处理装置，

其中，在位于所述信息处理装置附近的所述其他通信装置中不能确保在用作所述通信模块的应用的后续级处连接的所述其他应用所需的资源的情况下，

在除了执行用作所述通信模块的应用的所述其他通信装置之外的其他通信装置上执行所述其他应用。

(17)

根据上述(16)所述的信息处理装置，

其中，当由于所述信息处理装置的移动而发生切换时，转移前的作为第一装置的其他通信装置与转移后的作为第二装置的其他通信装置协商以确保所述其他应用所需的资源。

(18)

根据上述(17)所述的信息处理装置，

其中，在转移前的作为第一装置的其他通信装置中保持所述其他应用的第一部分的状态下，在转移后的作为第二装置的其他通信装置中执行除所述第一部分之外的第二部分。

(19)

根据上述(18)所述的信息处理装置，

其中，在作为转移后的作为第二装置的其他通信装置的多个所述其他通信装置中执行所述其他应用。

(20)

一种信息处理方法，包括：

由执行用于内容上行链路流的协议协商的通信模块：

向其他通信装置发送服务对象，所述服务对象包括在所述协议协商中使用的与内容的流有关的信息；

从所述其他通信装置接收基于所述服务对象发送的用于协商的信息；以及

与所述其他通信装置之间执行所述内容上行链路流的控制协议协商。

注意，本实施方式不限于前述实施方式，并且在不脱离本公开内容的范围的情况下可以作出各种改变。此外，本说明书中描述的效果仅是示例性的，并且不应被限制，并且可能存在其他效果。

附图标记列表

11信息处理系统、12云、13基站、14用户终端、21FLUS-源、31和32ME-主机、33ME-协调器、41FLUS-接收器、42数据保留处理单元(高速缓存/PStorage)、43转码处理单元、44数据库保留单元、45存储设备、51制作网络处理单元、52分发处理单元、53数据库保留单元、54存储单元、61数据库保留单元、71 5G核心网络、72接入网络、81数据平面、82应用、83ME-平台、84UPF。

Claims (20)

1.一种信息处理装置，包括：

通信模块，其执行用于内容上行链路流的协议协商，

其中，所述通信模块：

向其他通信装置发送服务对象，所述服务对象包括在所述协议协商中使用的与内容的流有关的信息；

从所述其他通信装置接收基于所述服务对象发送的用于协商的信息；以及

与所述其他的通信装置之间执行所述内容上行链路流的控制协议协商。

2.根据权利要求1所述的信息处理装置，

其中，在所述服务对象中，用于在所述内容上行链路流中使用的协议和格式的多个候选描述被描述为候选。

3.根据权利要求2所述的信息处理装置，

其中，所述服务对象包括分配给所述多个候选描述中的每个候选描述的优先级。

4.根据权利要求3所述的信息处理装置，

其中，所述优先级是根据网络带宽情况确定的。

5.根据权利要求2所述的信息处理装置，

其中，所述多个候选描述中的每个候选描述包括工作流程描述，所述工作流程描述定义与所述其他通信装置中的媒体处理有关的其他应用以及所述媒体处理所需的资源条件。

6.根据权利要求2所述的信息处理装置，

其中，用于所述协商的信息包括由所述其他通信装置基于所述服务对象选择的所述候选描述的信息。

7.根据权利要求6所述的信息处理装置，

其中，基于用于所述协商的信息，在所述服务对象中基于从所述服务对象选择的所述候选描述存储会话对象。

8.根据权利要求1所述的信息处理装置，

其中，所述服务对象是由所述通信模块生成的，所述通信模块用作在所述内容上行链路流中发送内容的一侧。

9.根据权利要求1所述的信息处理装置，

其中，多个所述信息处理装置经由网络连接以形成信息处理系统，并且

在位于所述其他通信装置附近的所述信息处理装置中，执行用作所述通信模块的应用，并且在用作所述通信模块的应用的后续级处连接其他应用并且执行所述其他应用。

10.根据权利要求9所述的信息处理装置，

其中，在位于所述其他通信装置附近的所述信息处理装置中不能确保在用作所述通信模块的应用的后续级处连接的所述其他应用所需的资源的情况下，

在除了执行用作所述通信模块的应用的所述信息处理装置之外的其他的所述信息处理装置上执行所述其他应用。

11.根据权利要求10所述的信息处理装置，

其中，当由于所述其他通信装置的移动而发生切换时，转移前的作为第一装置的信息处理装置与转移后的作为第二装置的信息处理装置协商以确保所述其他应用所需的资源。

12.根据权利要求11所述的信息处理装置，

其中，在转移前的作为第一装置的信息处理装置中保持所述其他应用的第一部分的状态下，在转移后的作为第二装置的信息处理装置中执行除所述第一部分之外的第二部分。

13.根据权利要求12所述的信息处理装置，

其中，在作为转移后的作为第二装置的信息处理装置的多个所述信息处理装置中执行所述其他应用。

14.根据权利要求1所述的信息处理装置，

其中，所述服务对象是由所述通信模块生成的，所述通信模块用作在所述内容上行链路流中接收内容的一侧。

15.根据权利要求1所述的信息处理装置，

其中，多个所述其他通信装置经由网络连接以形成信息处理系统，并且

在位于所述信息处理装置附近的所述其他通信装置中，执行用作所述通信模块的应用，并且在用作所述通信模块的应用的后续级处连接其他应用并且执行所述其他应用。

16.根据权利要求15所述的信息处理装置，

其中，在位于所述信息处理装置附近的所述其他通信装置中不能确保在用作所述通信模块的应用的后续级处连接的所述其他应用所需的资源的情况下，

在除了执行用作所述通信模块的应用的所述其他通信装置之外的其他通信装置上执行所述其他应用。

17.根据权利要求16所述的信息处理装置，

其中，当由于所述信息处理装置的移动而发生切换时，转移前的作为第一装置的其他通信装置与转移后的作为第二装置的其他通信装置协商以确保所述其他应用所需的资源。

18.根据权利要求17所述的信息处理装置，

其中，在转移前的作为第一装置的其他通信装置中保持所述其他应用的第一部分的状态下，在转移后的作为第二装置的其他通信装置中执行除所述第一部分之外的第二部分。

19.根据权利要求18所述的信息处理装置，

其中，在作为转移后的作为第二装置的其他通信装置的多个所述其他通信装置中执行所述其他应用。

20.一种信息处理方法，包括：

由执行用于内容上行链路流的协议协商的通信模块：

向其他通信装置发送服务对象，所述服务对象包括在所述协议协商中使用的与内容的流有关的信息；

从所述其他通信装置接收基于所述服务对象发送的用于协商的信息；以及

与所述其他通信装置之间执行所述内容上行链路流的控制协议协商。

Images