具体实施方式

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

<已知的通用服务器中的VDO处理>

首先，在描述应用本技术的信息处理系统之前，将参照图1描述已知的通用服务器中的视口相关优化器(VDO)处理。

如图1所示，通常，DASH客户端向DASH服务器发出用于请求获取DASH片段的片段请求。然后，响应于接收到片段请求，DASH服务器激活执行VDO处理的VDO应用程序(在下文中，也简称为VDO)。

此时，一个DASH服务器执行与来自多个DASH客户端的片段请求相对应的处理。因此，与从每个DASH客户端接收到的片段请求分开地，VDO基于每个DASH客户端给出的通知的视口度量(VM)的内容生成经历VDO处理的DASH片段，并且返回对片段请求的响应(VDO片段响应)。

顺便提及，通常，片段请求和VM是从DASH客户端分别发送的。因此，在给出VM的通知的通知频率的间隔长于片段长度的情况下，特别是在片段的粒度精细的情况下，有可能难以将VM的切换定时与VDO目标片段相关联。另一方面，当VM的通知频率的间隔被缩短时，假设VM的数据量成为流量的负担。

<用例>

图2是用于说明其中假设使用应用本技术的信息处理系统的用例的图。

在图2所示的配置示例中，信息处理系统11包括云12和用户终端13。

云12通过经由网络连接多个服务器来配置，并且每个服务器执行处理以提供各种服务。例如，在信息处理系统11中，云12可以提供向用户终端13分发VR内容的流传输服务。

如图所示，云12具有其中ME主机31-1至31-3、原始服务器32和ME平台(编排器)33经由网络连接的配置。注意，ME主机31-1至31-3被类似地配置，并且在不必区分它们的情况下被简称为ME主机31，并且也类似地称为配置ME主机31的每个块。而且，ME主机31包括VDO41和数据库保存单元42，并且VDO 41包括存储单元43。此外，ME平台(编排器)33包括数据库保存单元61和工作流管理器62。

例如，如图8所示的智能电话、头戴式显示器等可以用作用户终端13，并且用户终端可以接收并显示通过流传输服务从云12分发的VR内容。例如，用户终端13具有其中安装了DASH客户端21的配置。

然后，假设5G多访问边缘计算(MEC)架构作为将来可以在这样的用例中使用的网络。

具体地，首先，在DASH用作流传输协议的情况下，安装在用户终端(UE：用户设备)13上的DASH客户端21连接至ME主机31-1上的VDO 41-1。然后，VDO 41连接至作为DASH流传输的根服务器的通用原始服务器32。例如，可以类似于通用内容递送网络(CDN)服务器配置，从VDO 41到原始服务器32配置多级层级结构。

DASH客户端21是在接收流的用户终端13上执行的流传输接收/再现应用。

VDO 41是在ME主机31上执行的流传输应用，其向DASH客户端21发送流。此外，VDO41具有优化DASH流的功能，并且具有与DASH客户端21交换优化所需的信息的功能。例如，VDO 41具有执行视口相关(VD)优化的功能，这是优化的一个用例。

例如，作为VDO 41进行VD优化的一种方法，存在一种生成DASH片段(视口相关优化片段)的方法，该片段由在DASH客户端21中的用户视线方向上优化的视口相关打包图片(通过区域性打包处理的图像)配置。这里，用户视线方向上的优化例如是增加用户视线方向上的图像的信息量或高清晰度。

顺便提及，在由于用户终端13的移动而导致伴随基站间切换而发生MEC环境的转移的情况下，需要在基站间切换前后尽可能地能够进行无缝流传输，而不考虑MEC环境的转移。然后，作为用于确保无缝流传输的方案，考虑一种方法，其中在转移之前绑定到小区的ME主机31-1(MEC环境)中执行的VDO 41-1也同时被转移到在转移之后绑定到小区的ME主机31-2或31-3。具体地，在转移之前在MEC环境中执行的VDO应用程序在转移之后在MEC环境中执行，使得在转移之后在MEC环境中再现和复制转移之前在MEC环境中的执行状态。

然后，当实现该方法时，通过掌握转移目的地的小区的网络流量或ME主机31上的资源的负载状态，然后在基站间切换发生之前复制转移目的地的ME主机31-2或ME主机31-3上的转移之前的ME主机31-1上的执行状态，可以获得可以无缝进行流传输的效果。

以此方式，通过在用户终端13移动之后将ME主机31-1的VDO 41-1转移到绑定到小区的ME主机31-3的VDO 41-3或ME主机31-2的VDO 41-2，信息处理系统11可以使MEC计算的优点最大化，例如低延迟和负载分布。

顺便提及，在包括常规的标准接口、协议等的MEC架构中，不支持这样的用例，并且因此不能实现无缝流传输。也就是说，不存在可以安装在具有不同厂商和型号的移动网络捕获设备上的MEC架构、在云环境中支持这样的服务的MEC架构等。

在这点上，如下所述，在本实施方式中，新提出了在MEC架构中使用的、为了通过执行如上所述的执行状态的复制(处理复制)来实现无缝流传输而必要的标准协议(应用程序接口(API))和流程(序列)。

这里，将描述作为已知技术的内容。

首先，已知的技术是应用在ME主机31上迁移(转移)，例如，当用户终端14执行ME主机31-1和ME主机31-2之间的切换时。另一方面，迁移目的地的运行时间(执行)资源协商没有被定义为标准协议。

此外，在欧洲电信标准协会(ETSI)中，已知一种在ME平台中登记通用应用的执行条件(例如静态存储器和磁盘上限)的技术。另一方面，尚未讨论用于实现这样的注册的具体手段。

这里，将进一步描述本公开内容中新提出的内容。

首先，在用户终端13附近的ME主机31-1中，执行连接至用户终端13上的DASH客户端21的VDO 41-1。然后，新提出了用于在VDO 41-1与绑定到其中预测用户终端13的基站间切换的转移目的地基站的ME主机31-2上的VDO 41-2或ME主机31-3上的VDO 41-3之间执行状态同步的协议。

此外，提出了一种将VM附接至要经历VDO处理的片段请求的方法，特别是一种处理在假设片段的粒度精细时需要确保片段与VM之间的同步精度的情况的方法。

在这点上，在该实施方式中，如下所述，在转移目的地小区的ME主机31-2或31-3上保留用于操作VDO 41-2或41-3的CPU或用于确保存储区域、输入/输出(IO)吞吐量等的资源。此后，复制基于VM(用户终端13的状态信息)的VDO处理状态，该VDO处理状态是由VDO41-1在转移之前从建立流传输会话的单独DASH客户端21获取的。也就是说，在转移之前为由VDO 41-1执行的DASH客户端21优化的处理在预测的转移目的地的小区的ME主机31-2或31-3上被复制。此时，状态同步继续，直到转移完成为止。处理状态同步包括例如通过执行VDO处理生成的VDO片段和已经获取的用户终端13的状态信息。

此外，在该处理状态同步中，存在与在由VDO 41-2或41-3执行转移之前由VDO 41-1执行的VDO处理完全相同的处理的情况，以及执行状态同步以针对转移(调度)目的地的环境进行优化的情况。

例如，在针对转移(调度)目的地的环境优化地执行状态同步的情况下，将转移目的地的环境中的流传输质量改变为与转移之前的流传输质量不同的流传输质量。该流传输质量的改变是基于转移目的地小区的流量信息或转移目的地ME主机31-2或31-3的负载信息来执行的，由在转移(调度)目的地ME主机31-2或31-3中执行的VDO 41-2或41-3经由用于获取在转移目的地ME主机31-2或31-3中安装的转移目的地的ME环境信息的API所获取转移目的地小区的流量信息。替选地，基于根据当前环境信息的近期的变化预测来执行流传输质量的改变。

例如，在流传输质量可以在该限制的范围内改变的情况下，流传输质量在该限制的范围内改变。注意，在流传输质量无法在该限制的范围内改变的情况下，即使在用户终端13的转移之后，转移源VDO 41-1的处理也被保持，并且生成必要VDO片段的请求被从转移目的地ME主机31-2或31-3重定向至转移源ME主机31-1。

此外，在同时存在两个或更多个转移目的地小区(ME主机环境)的情况下，也就是说，在覆盖范围之间存在分层关系的情况下，在存在小区边界(ME主机环境边界)的情况下，或者在无法预测转移目的地小区(ME主机环境)的情况下，在多个转移目的地小区中的ME主机31中同时执行VDO 41以执行处理同步，或者在具有更好环境的小区的ME主机31中执行VDO 41以执行处理同步。

这里，将参照图3描述本实施方式的信息处理系统11中的5G核心网络系统功能组71以及用户终端13与作为MEC环境的ME主机31中的应用程序82之间的会话。

例如，在信息处理系统11中，边缘计算中的边缘服务器可以显著地改善通信延迟，通信延迟是传统云计算中的瓶颈之一。此外，通过在用户终端13、作为边缘服务器的ME主机31和作为云服务器的原始服务器32之间执行高负载应用程序的分发处理，可以加速处理。

注意，边缘计算的标准规范被定义为“ETSI-MEC”。然后，ETSI-MEC中的ME主机对应于作为边缘服务器的ME主机31。

在图3中所示的示例中，经由由第三代合作伙伴计划(3GPP)标准化的5G核心网络系统功能组71的接入网72连接ME主机31上的应用程序82和用户终端13(以上安装的应用程序)的线路表示用户数据会话。注意，5G核心网络系统功能组71中的接入网((R)AN)72包括有线接入网(AN)和无线接入网(RAN)。

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

此外，在5G(第5代移动通信系统)核心网络系统功能组71中，采用基于服务的架构，并且定义了作为核心网络的功能的多个网络功能(NF)。然后，这些NF经由被称为基于服务的接口的统一接口连接。

在图3的示例中，NF知识库功能(NRF：NF的服务发现)、统一数据管理(UDM：订户信息的管理)、认证服务器功能(AUSF：UE的认证信息的管理)、策略控制功能(PCF：关于用于AMF和SMF的适当操作的移动性和会话管理的策略的控制)、网络公开功能(NEF：向MNO网络中的应用提供NF服务)、接入和移动性管理功能(AMF：UE的移动性管理/认证/授权、SMF的控制)以及会话管理功能(SMF：UE的会话管理)被示为NF。

<信息处理系统的第一信息处理示例>

将参照图4至17描述边缘服务器中的多播和VDO处理作为信息处理系统11的第一信息处理示例。

图4是用于说明工作流管理器62对VDO 41的激活、以及推送流传输和VDO处理的图。

例如，在信息处理系统11中，在ME主机31上执行的VDO应用程序由作为应用安装在ME平台(编排器)33上的工作流管理器62激活。

首先，基于描述执行要被激活的VDO应用程序所需的网络资源、计算资源、存储资源等的工作流描述，工作流管理器62经由ME平台83的API来确保必要的资源，并激活目标应用程序(图4中的VDO激活和VDO资源预留/生成)。

此后，DASH客户端21首先找到附近的ME主机31上的VDO 41，并且向VDO 41发出用于请求获取DASH片段的片段请求。此时，假设原始服务器32执行DASH片段(或如稍后描述的编码之前的基带流)到VDO41的多播推送分发(图4中的推送分发)。

另一方面，VDO 41从多个DASH客户端21接收用于每个DASH客户端21的VM。注意，任何通知方法都可以用于VM的发送和接收，并且例如，可以使用网络辅助DASH(SAND)和服务器的度量通知。

这里，在本实施方式中，作为不能由SAND的度量通知处理的通知方法，新提出了将DASH中定义的URL参数(23009-1：Annex.I.URL参数的灵活插入)应用于VM的通知方法，使得可以清楚地指示要优化的片段。注意，除此之外，例如，可以考虑在片段的HTTP请求的报头中执行存储和传递的方法。

然后，基于VM的接收内容，VDO 41对从原始服务器32推送分发的DASH片段(或基带流)执行VDO处理。例如，在VDO处理中，从原始服务器32分发的DASH片段被解码一次(如在基带流的情况下)，并且通过区域性打包等来提高视点方向上的图像质量和分辨率，并且编码数据被重新编码以生成VDO片段(经历VDO处理的DASH片段)。

这里，将描述流栈的配置示例。

例如，在一些情况下，原始服务器32多播DASH片段作为到VDO 41的推送分发，而在其他情况下，在编码之前多播基带流。也就是说，原始服务器32使用例如文件多播协议(诸如FLUTE(ROUTE))等，同时将相同的片段或基带流文件广播到连接至云12的所有ME主机31上的VDO41。

例如，在发送侧不能预先预测来自DASH客户端21的请求的质量(例如，比特率等)的变化的情况下，使用通过多播的推送分发。另一方面，在可以预先假设请求的质量变化的情况下，基于特定的适配集来编码和准备具有不同质量的多个表示。

此外，在VR流传输的用例中，存在准备其中取决于终端用户的视点方向(视口)优化图像质量的变化的情况。在这种情况下，为了准确地跟随用户的视点移动，需要准备在所有视点方向上的大量优化的片段变化，因此存在服务器资源和网络资源被不必要的浪费的可能性。

因此，在原始服务器32侧，在无法假设从DASH客户端21请求的片段的质量、视口的转轨迹等的情况下，例如，在特定适配集中布置一个表示，并且在其中布置一个未经历VDO处理并且在整个视角方向上具有均匀图像质量的片段(具有最高质量的片段，例如，全部配置有I帧的片段)。然后，优选采用这样的方法，其中，从原始服务器32向所有ME主机31多播分发这一种类型的片段，并且在靠近DASH客户端21的边缘处的ME主机31中，基于从各个DASH客户端21逐个获得的VM中的所通知的视点方向信息，生成经历VDO处理的DASH片段(VDO片段)。也就是说，通过采用该方法，假设可以避免分发资源的浪费。

注意，在一些情况下，要多播的片段的质量以最高质量进行编码(压缩)，或者在其他情况下，要多播的片段作为基带流发送而不进行编码。例如，即使在基带宽带流中，与诸如HTTP/TCP的双向协议相比，通过使用多播协议也可以充分地节省分发资源。

此外，除了在适配集中布置一个表示之外，还考虑以下情况，通过预先划分成多个比特率等来准备在整个视角方向上均匀的图像质量的片段(替选地，可能存在变化，诸如在方位角方向上均匀的图像质量和在高度角方向上不均匀的图像质量)。

图5和图6示出了DASH客户端21、VDO 41与原始服务器32之间的流栈的配置示例。

例如，图5示出了流栈的第一配置示例，其中，执行从原始服务器32到VDO 41的单向多播，以便通过推送分发来执行同时广播，并且具有相同内容的流被分发到所有VDO 41。

此外，图6示出了流栈的第二配置示例，其中，从VDO 41侧发出获取请求，并且以双向单播从原始服务器32获取流，尽管其整体上看起来类似于推送分发。例如，在流栈的第二配置示例中，VDO 41侧掌握来自从属DASH客户端21的请求的趋势，并且可以分发流，以将分发资源优先分配给在具有相对高的访问可能性的视点方向上具有较高分辨率的片段。也就是说，在流栈的第二配置示例中，可以根据来自DASH客户端21的请求的趋势来实现分发，而不是成为完美同时广播的推送分发。

图7示出了流栈的第三配置示例，其中，通过捆绑多个VDO 41获得的聚合VDO被配置在多个级中。例如，聚合VDO在配置云12的某个ME主机31中执行。

例如，在流栈的第三配置示例中，从原始服务器32到聚合VDO，通过单向多播将相同的内容分发到所有聚合VDO，以便以推送类型执行同时广播。然后，在单个的聚合VDO中，以分层密集方式掌握来自DASH客户端21的请求要由其自身的从属VDO 41处理的趋势，并且可以分发流，以将分发资源优先分配给在具有相对高的访问可能性的视点方向上具有较高分辨率的片段。也就是说，同样在流栈的第三配置示例中，可以根据来自DASH客户端21的请求的趋势来实现分发，而不是成为完美同时广播的推送分发。

这里，将描述发送VM的方法。

例如，DASH客户端21中的视口由图8所示的X轴、Y轴和Z轴以及围绕这些轴的俯仰旋转、偏航旋转和滚转旋转指定。此时，假设终端用户的主体是固定的，根据终端用户的头部的运动来确定角度。例如，俯仰旋转、偏航旋转和滚转旋转的角度在顺时针方向上朝向X轴、Y轴和Z轴中的每个的正方向增大。此外，X-Z平面平行于地面，并且当观察Z轴的正方向时，定义所有的角度为零。然后，执行从视口元数据的坐标系到流源的坐标系的映射。

例如，假设源中的坐标系使用利用方位角和高度角的表示方法，并且客户端侧使用由俯仰旋转、偏航旋转和滚转旋转表示的坐标系。在这种情下，执行映射，使得源坐标系的方位角和高度角(中心方位角/中心仰角)二者均为零的方向与DASH客户端21中的俯仰旋转、偏航旋转和滚转旋转都为零的方向一致。然后，沿着以全向媒体应用格式(OMAF)定义的结构SphereConRegionStructure，转换后的坐标系中的视口坐标值被存储在23090-6：沉浸式媒体量度的呈现视口度量中(该度量在提交本申请时被考虑)，并且被设置为VM。

图9示出了视口度量(呈现视口度量)和视口数据类型的示例。

例如，作为将VM发送到VDO 41的方法的示例，存在使用DASH中定义的URL参数(23009-1：Annex.I.URL参数的灵活插入)的方法。注意，在本公开内容中，新提出了将DASH的URL参数应用于VM传输。

此外，DASH的URL参数将查询字符串插入片段请求的片段URL中，并且在服务器侧指定的DASH客户端21的信息可以存储在查询字符串中。这里，通过媒体呈现描述(MPD)向DASH客户端21通知要存储在查询字符串中的信息类型。

图10示出了应用于本实施方式中提出的VM的通知的MPD和VM的示例。

如图10所示，MPD包括寻址要再现的VR流的适配集。然后，指定作为当请求VR流的片段时使用的片段URL的查询字符串要添加的VM的数据结构的urn被存储为由XML命名空间“urn：mpeg：dash：schema：urlparam：2014”在适配集的从属基本属性元素下定义的URL查询信息元素的属性queryString的值。例如，在图10所示的示例中，从右下字段“startTime”开始的JSON实例的数据结构被指定为VM的数据结构，并且“urn：viewportMetrics”被存储为指定VM的数据结构的urn。因此，DASH客户端21可以给出将VM添加到片段请求并且发送片段请求的指令。

图11是用于说明对经历了VDO 41的VDO处理的片段进行分发的处理的流程图。

在步骤S11中，VDO 41将图10所示的MPD发送给DASH客户端21。因此，DASH客户端21接收MPD。

在步骤S12，DASH客户端21解析在步骤S11中发送的MPD，并找到“urn：viewportMetrics”。

然后，在“urn：viewportMetrics”的结构在安装在DASH客户端21中的硬代码中是未知的情况下，处理进行到步骤S13。在步骤S13中，DASH客户端21从urn参数数据库中搜索并获取“urn：viewportMetrics”的结构，并且然后处理进行到步骤S14。

另一方面，在“urn：viewportMetrics”的结构在安装在DASH客户端21中的硬代码中是已知的情况下，处理跳过步骤S13，并且进行到步骤S14。

在步骤S14，DASH客户端21将指示观察的视点方向的视口存储在VM的数据结构中。

在步骤S15中，DASH客户端21对VM的数据结构进行URL编码，将查询字符串添加到片段URL，并且将片段请求发送到VDO 41。因此，VDO 41接收片段请求。

在步骤S16中，VDO 41返回通过基于在步骤S15中发送的VM来对该片段执行VDO处理而优化的片段响应。因此，DASH客户端21接收片段响应。

在步骤S17中，DASH客户端21基于在步骤S16中返回的片段响应来再现经历VDO处理的片段。然后，类似地，重复执行片段请求的发送和片段响应的返回。

图12和图13示出了本公开内容中新提出的唯一定义的工作流描述的示例。这里，尽管是唯一定义的，但是云上的媒体处理的工作流和应用程序的框架当前正在通过基于MPEG-I网络的媒体处理(NBMP)进行规范开发中，并且规范未被确定。注意，在该工作流描述中仅描述VDO。

如图12所示，紧接在Workflow元素下方的元素是具有URL属性值“VDO-ur1”的应用元素，并且表示VDO应用程序的执行。此外，在资源描述元素中，描述了执行VDO应用程序所需的资源。

这里，在应用程序之间不存在输入/输出连接。此外，由VDO 41处理和提供的流文件(例如，DASH片段文件)通过访问作为代理服务器的另一应用程序而获取，或者以由其上安装了VDO 41的web服务器提供的文件访问方法(例如，HTTP)通过从另一应用程序访问而提供。

注意，如在上述图7中的流栈的配置示例中所示的VDO 41和聚合VDO中，可以在VDO41之间配置层级。因此，可能存在以下情况：流文件首先由上层的VDO 41处理，并且此后被传送到其下属的VDO 41，或者由下属的VDO 41处理，而无需由上层的VDO 41处理。

在这点上，在图13所示的工作流描述中，新引入siblingOf属性，使得可以定义应用程序之间的处理的这样的层次关系。因此，这表示VDO应用程序可以位于不同的VDO实例下。

图14示出了表示如上所述的VDO应用程序的应用属性的应用对象的示例。例如，应用对象的属性定义由ME平台管理，并且每个应用程序的个体属性基于属性定义来管理。

在应用URL(+提供者URL)中，标识VDO等的应用程序的类型(提供者URL也在+选项中标识)。例如，VDO等的应用程序的类型由工作流描述中描述的[email protected]指定。

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

MEC系统URI版本是标识在其中执行应用程序的MEC系统(虚拟环境)的标识符。

概要描述对应用程序的处理的概要进行了描述。

资源需求包括诸如虚拟CPU使用/秒+周期、虚拟存储器/存储容量/秒+周期、IO吞吐量/秒+周期等数值规范，并且由MEC系统URL相关资源类ID定义。例如，资源需求由工作流描述中描述的资源描述来指定。

应用包(URL，图像主体)是MEC系统相关的应用程序执行图像或其图像主体的URL。

流量/DNS规则(过滤器/DNS记录)是用于经由ME平台控制5G系统中的分组路由的信息。

注意，在从工作流管理器62开始的VDO激活阶段中，参考工作流描述中的工作流/应用程序[@url＝‘VDO-url’]/资源描述中描述的VDO应用程序的必要资源。

例如，如图15所示，从工作流管理器62接收VDO激活请求的ME平台83检查在其自己的ME主机31上是否满足在资源描述中描述的资源需求。然后，在可以满足在资源描述中描述的资源需求的情况下，ME平台83执行新的VDO应用程序以生成应用程序实例，并且将实例的地址返回至工作流管理器62。

将参照图16描述应用程序激活处理。

在步骤S21中，工作流管理器62根据工作流描述中描述的应用定义生成应用对象，并请求ME平台83执行该应用程序。因此，ME平台83接收从工作流管理器62发送的应用对象。这里，在应用对象的资源需求中，例如，存储在工作流描述的资源描述中描述的必要资源需求。

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

在步骤S23，ME平台83确定是否确保了必要资源，并且在确定确保了必要资源的情况下，处理进行到步骤S24。

在步骤S24中，ME平台83生成应用对象的实例ID并激活应用程序。然后，在步骤S25中，激活要激活的应用程序，并且等待处理。

另一方面，在步骤S26中，在ME平台83确定了不能确保必要资源的情况下，处理进行到步骤S26。在步骤S26中，ME平台83对其中资源确保失败的应用对象向工作流管理器进行NACK响应。因此，工作流管理器62接收从ME平台83发送的应用对象。

这里，在资源描述中描述多个候选资源需求的情况下，在步骤S27中，工作流管理器62重写应用对象的资源需求部分，并请求ME平台83再次执行应用程序。然后，处理返回到步骤S21，发送重写的应用对象，并且此后，直到达到通过使用其作为截止期限而设置的时限为止，重复类似的处理。注意，在超过时限的情况下，应用程序无法激活。

将参照图17描述从DASH客户端21给出视图度量的通知并且在VDO 41中生成VDO片段的处理。

在步骤S31中，原始服务器32将MPD发送至VDO 41。因此，VDO41接收MPD。

在步骤S32中，DASH客户端21将MPD请求发送至VDO 41。因此，VDO 41接收MPD请求。

在步骤S33中，VDO 41向DASH客户端21发送对在步骤S32中发送的MPD请求的MPD响应。因此，DASH客户端21接收MPD响应。

在步骤S34中，原始服务器32将片段发送至VDO 41。因此，VDO 41接收片段。

在步骤S35中，DASH客户端21将VM附接至片段请求，并将片段请求发送至VDO 41。因此，VDO 41接收片段请求和VM。

在步骤S36中，VDO 41基于在步骤S35中伴随片段请求发送的VM，对在步骤S34中从原始服务器32分发的目标片段执行VDO处理，并且生成VDO片段(经历VDO处理的DASH片段)。

在步骤S37中，VDO 41将经历VDO处理的VDO片段返回给DASH客户端21作为对片段请求的响应。

如上所述，信息处理系统11可以通过多播将片段从原始服务器32分发到VDO 41，通过作为边缘服务器的ME主机31的VDO 41执行VDO处理，并且将VDO片段发送到DASH客户端21。

<信息处理系统的第二信息处理示例>

作为信息处理系统11的第二信息处理示例，将参照图18至图23描述随着DASH客户端21的基站间切换而同步复制ME主机31之间的VDO 41的处理的处理。例如，信息处理系统11的第二信息处理示例具有这样的特性，即，当ME主机31的环境由于DASH客户端21的基站间切换而改变时，在转移目的地的ME主机31上保留用于操作VDO 41的CPU、存储区域、IO吞吐量等，并且在转移之前VDO 41的处理状态相对于转移目的地的ME主机31上的VDO 41被同步复制。

例如，如图18所示，当安装DASH客户端21的用户终端13移动时，在安装了ME主机31的基站之间发生基站间切换。在下文中，切换前的接入网72被称为源RAN 72S，并且切换前的ME主机31被称为源ME主机31S。类似地，作为切换目的地的接入网72被称为目标RAN 72T，而作为切换目的地的ME主机31被称为目标ME主机31T。

然后，在绑定到某个基站的源RAN 72S的源ME主机31S上安装从VDO应用程序经由源RAN 72S流传输的DASH-客户端21的用户终端13移动到目标ME主机31T所绑定的另一基站的目标ME主机31T上。由于伴随该移动的基站间切换，源ME主机31S的VDO 41S转移到源ME主机31T的VDO 41T，如图18中的双点划线箭头所示。

将参照图22的流程描述此时执行的处理。注意，图22的流程示出了在DASH客户端21与VDO 41S之间已经开始流传输之后的处理。

也就是说，安装在源RAN 72S上的用户终端13上的DASH客户端21基于从源ME主机31S上的VDO 41S经历VDO处理的流文件已经执行了流传输(图22中来自源ME主机的流传输)。

这里，如图19所示，假设安装DASH客户端21的用户终端13在不同于源ME主机31S的目标ME主机31T所绑定的基站的目标RAN 72T上移动。

此外，在源ME主机31S上执行的VDO 41S可以通过ME平台83S提供的API来检测其上安装了DASH客户端21的用户终端13的移动(位置)。然后，根据位置转移信息、使用统计信息和AI的移动性模式分析等，逐个假设预测用户终端13从当前现有的源RAN 72S移动到另一目标RAN72T(图22中，到目标ME主机的转移的预测)。

然后，源ME主机31S上的VDO 41S请求ME平台(协调器)33在目标ME主机31T上执行VDO 41T(图22中的VDO激活)。也就是说，在DASH客户端21转移到目标RAN 72T之前，在目标ME主机31T上单独地生成对应的VDO应用程序，并且复制该应用程序的执行状态。

作为响应，目标ME主机31T的ME平台83T尝试基于与当前在DASH客户端21与VDO 41之间建立的流传输会话(图22中的VDO资源预留/生成)等效的协议资源需求来保留和执行资源。

这里，策略(例如：保持与DASH客户端21当前建立的会话、以低于(或改进的)质量继续服务(该服务比预期的转换目的地小区的流量和ME平台83T的负载状态而当前建立的会话的质量低)、以及在需要降低质量的情况下在当前与DASH客户端21建立的源ME主机31S上保持与VDO 41S的会话)基于如图20所示的工作流程描述中描述的“切换时会话更新策略”的规范。

例如，在KeepAlreadyEstablishedIfFailed＝‘假’的情况下，工作流/[email protected]的默认值为假，并且在没有描述该属性的情况下，其总是指示如果可能则升级(例如，提高流传输质量)并且如果必要则降级(例如，降低流传输质量)。注意，在第三信息处理示例中，将描述在MEC环境中由于切换等而发生变化的情况下的处理。

此外，在目标ME主机31T上的VDO 41T中，必要的资源被保留和激活(图22中的VDO资源保留/生成)，但是对DASH客户端21的流传输处理不立即开始。例如，VDO 41T从源ME主机31S上的VDO 41S接收用于请求同步VDO处理的同步VDO处理请求，并与源ME主机31S上的VDO 41S同步地执行VDO处理。

假设在一段时间过去之后，源ME主机31S上的VDO 41S检测到其上安装有DASH客户端21的用户终端13经由ME平台83S移动，并且新连接至目标ME主机31T所绑定的目标RAN72T(图22中DASH客户端到目标ME主机的转移的检测)。

响应于此，执行流量改变，使得目标ME主机31T上的VDO 41T可以在转移(图22中对目标ME主机的流量更新)之后从目标RAN 72T接收流传输请求。同时，执行流量改变，使得来自目标ME主机31T上的VDO 41T的响应到达用户终端13。

因此，目标ME主机31T上的VDO 41T在经由目标RAN 72T移动之后，开始向DASH客户端21的流传输(图22中从目标ME主机进行流传输)。

注意，如图21所示，在工作流描述中，可以指定是否允许VDO应用程序的ME主机31之间的转移本身。例如，在不允许VDO应用程序的ME主机31之间的转移本身的情况下，指定[email protected]＝‘真’。另一方面，在尝试ME主机31的转移的情况下，指定[email protected]＝‘假’，将其设置为默认值，而不是尽可能地利用MEC。当然，在[email protected]＝‘真’的情况下，忽略图20中所示的KeepAlreadyEstablishedIfFailed。

图23是用于说明通过基站间切换进行的VDO转移处理的流程图。

在步骤S41中，原始服务器32将片段发送至VDO 41S和VDO 41T。因此，VDO 41S和VDO 41T接收这些片段。

在步骤S42中，DASH客户端21将VM附接至片段请求，并且将片段请求发送至VDO41S。因此，VDO 41S接收片段请求和VM。

在步骤S43中，VDO 41S将片段URL、MPD和VM发送到VDO 41T，并请求同步VDO处理。因此，VDO 41T接收片段URL、MPD和VM。

在步骤S44中，VDO 41S执行VDO处理以生成VDO片段，并且在步骤S45中，VDO 41T执行同步VDO处理以生成VDO片段。

此后，当发生切换时，在步骤S46中，DASH客户端21将VM附接至片段请求，并且将片段请求发送到VDO 41T。因此，VDO 41T接收片段请求和VM。

在步骤S47中，VDO 41T将经历了步骤S45中的VDO处理的VDO片段返回给DASH客户端21，作为对片段请求的响应。

如上所述，在信息处理系统11中，通过同步地复制ME主机31之间的VDO 41的VDO处理以及DASH客户端21的基站间切换，可以将VDO片段无缝地发送到DASH客户端21。

将参照图24至图26描述在由于资源短缺而导致无法在用作转移目的地的ME主机31上激活VDO 41的情况下的处理。

图24示出了由于DASH客户端21从源RAN 72S移动到目标RAN 72T(参见图25)而伴随发生的基站间切换的转移前后的状态。

也就是说，在绑定到某个基站的源RAN 72S的源ME主机31S上安装从VDO应用程序经由源RAN 72S流传输的DASH-客户端21的用户终端13移动到目标ME主机31T所绑定的另一基站的目标ME主机31T上。源ME主机31S的VDO 41S由于伴随该移动的基站间切换而尝试转移，但是源ME主机31T的VDO 41T可能由于资源短缺而未被激活。

在这种情况下，当源ME主机31S的VDO 41S被维护时，VDO 41S可以将从原始服务器32接收的片段从数据平面81S发送到数据平面81T，并且经由目标RAN 72T将该片段发送到DASH客户端21。

将参照图26的流程描述此时执行的处理。注意，在图26的流程中，示出了在DASH客户端21与VDO 41S之间已经开始流传输之后的处理。

首先，如上参照图22的流程所述，VDO 41S预测用户终端13从当前现有的源RAN72S移动到另一目标RAN 72T(图26中的到目标ME主机的转移的预测)。

然后，源ME主机31S上的VDO 41S请求ME平台(编排器)33的工作流管理器62在目标ME主机31T上执行VDO 41T(图26中的VDO(在目标ME主机处)激活)。

作为响应，目标ME主机31T的ME平台83T基于与当前在DASH客户端21与VDO 41S之间建立的会话等效的协议资源需求来尝试资源保留和执行。然而，在这种情况下，VDO 41T的激活失败。

假设在一段时间过去之后，源ME主机31S上的VDO 41S检测到其上安装有DASH客户端21的用户终端13经由ME平台83S移动，并且新连接至目标ME主机31T所绑定的目标RAN72T(图26中DASH客户端到目标ME主机的转移的检测)。

在这种情况下，VDO 41S执行流量改变，使得源ME主机31S上的VDO 41S可以在转移(图26中对源ME主机的流量改变)之后从目标RAN 72T接收流传输请求。同时，在目标ME主机31T上的ME平台83T上执行对源ME主机31S的流量改变。

因此，即使在目标ME主机31T上的VDO 41T的激活失败的情况下，也可以经由目标RAN 72T实现到DASH客户端21的流传输，同时保持源ME主机31S上的VDO 41S。

将参照图27至图29描述在无法预测转移目的地小区(RAN 72)的情况下，在绑定到预期转移的两个小区(目标RAN 72T-A和目标RAN 72T-B)的目标ME主机31T-A和目标ME主机31T-B的每个中执行VDO 41T的处理。这里，示出了DASH客户端21最终转移到绑定到目标ME主机31T-A的目标RAN 72T-A的情况。

例如，图27示出了由于DASH客户端21从源RAN 72S移动到目标RAN 72T-A而伴随发生的基站间切换的状态(见图28)。

也就是说，在DASH客户端21无法预测转移进行到目标RAN 72T-A和目标RAN 72T-B中的哪一个的情况下，在目标ME主机31T-A中激活VDO 41T-A，并且在目标ME主机31T-B中激活VDO 41T-B。然后，当检测到DASH客户端21到目标RAN 72T-A的转移时，执行经由目标RAN72T-A从VDO 41T-A到DASH客户端21的流传输。

将参照图29的流程描述此时执行的处理。注意，在图29的流程中，示出了在DASH客户端21与VDO 41S之间已经开始流传输之后的处理。

首先，如上参照图22的流程所述，VDO 41S预测用户终端13从当前现有的源RAN72S移动到另一目标RAN 72T-A或目标RAN 72T-B(图29中到目标ME主机A或B的转移的预测)。也就是说，在这种情况下，不可能预测用户终端移动到目标RAN 72T-A和目标RAN 72T-B中的哪一个。

然后，源ME主机31S上的VDO 41S请求ME平台(编排器)33的工作流管理器62在目标ME主机31T-A上执行VDO 41T-A，并在目标ME主机31T-B上执行VDO 41T-B(图29中的VDO(在目标ME主机A和B处)激活)。

作为响应，目标ME主机31T的ME平台83T基于与当前在DASH客户端21与VDO 41S之间建立的会话等效的协议资源需求来尝试资源保留和执行。因此，在目标ME主机31T-A上的VDO 41T-A中，必要的资源被保留和激活(图29中的VDO资源保留/生成)。类似地，在目标ME主机31T-B上的VDO 41T-B中，必要的资源被保留和激活(图29中的VDO资源保留/生成)。

此后，目标ME主机31T的ME平台83T向目标ME主机31T-A上的VDO 41T-A请求同步VDO处理，并向目标ME主机31T-B上的VDO 41T-B请求同步VDO处理。因此，VDO 41T-A和VDO41T-B可以与源ME主机31S上的VDO 41S同步地执行VDO处理。

假设在一段时间过去之后，源ME主机31S上的VDO 41S检测到其上安装有DASH客户端21的用户终端13经由ME平台83S移动，并且新连接至目标ME主机31T-A所绑定的目标RAN72T-A(图29中DASH客户端到目标ME主机A的转移的检测)。

响应于此，执行流量改变，使得目标ME主机31T-A上的VDO 41T-A可以在转移之后从目标RAN 72T-A接收流传输请求(图29中对目标ME主机A的流量更新)。同时，执行流量改变，使得来自目标ME主机31T-A上的VDO 41T-A的响应到达用户终端13。

此后，目标ME主机31T-A上的VDO 41T-A在经由目标RAN 72T-A移动之后开始向DASH客户端21的流传输(图29中来自目标ME主机A的流传输)。此时，VDO 41T-A在目标ME主机31T-A上的同步VDO处理继续，并且VDO 41T-B在目标ME主机31T-B上的同步VDO处理结束。

将参照图30至图33描述确保容错冗余的处理。这里，示出了以下示例，其中，在绑定到具有交叠覆盖的两个小区(目标RAN 72T-A和目标RAN 72T-B)的目标ME主机31T-A和目标ME主机31T-B中的每个中执行VDO 41T，并且两个流传输会话同步执行。注意，假设在转移之后DASH客户端21同时连接至目标RAN 72T-A和目标RAN 72T-B两者。

例如，图30示出了由于DASH客户端21从源RAN 72S移动到目标RAN 72T-A和目标RAN 72T-B而伴随发生的基站间切换的状态(见图31)。

也就是说，在目标RAN 72T-A和目标RAN 72T-B的覆盖交叠的情况下，VDO 41T-A在目标ME主机31T-A中被激活，并且VDO 41T-B在目标ME主机31T-B中被激活。然后，当检测到DASH客户端21到目标RAN 72T-A和目标RAN 72T-B的转移时，执行从VDO 41T-A经由目标RAN72T-A到DASH客户端21的流传输以及从VDO 41T-B经由目标RAN 72T-B到DASH客户端21的流传输。

将参照图32的流程描述此时执行的处理。注意，图32的流程示出了在DASH客户端21与VDO 41S之间已经开始流传输之后的处理。

首先，如上参照图22的流程所述，VDO 41S预测用户终端13从当前现有的源RAN72S移动到另一目标RAN 72T-A或目标RAN 72T-B(图32中到目标ME主机A或B的转移的预测)。

然后，源ME主机31S上的VDO 41S请求ME平台(编排器)33的工作流管理器62在目标ME主机31T-A上执行VDO 41T-A，并在目标ME主机31T-B上执行VDO 41T-B(图32中的VDO(在目标ME主机A和B处)激活)。

作为响应，目标ME主机31T的ME平台83T基于与当前在DASH客户端21与VDO 41S之间建立的会话等效的协议资源需求来尝试资源保留和执行。因此，在目标ME主机31T-A上的VDO 41T-A中，必要的资源被保留和激活(图32中的VDO资源保留/生成)。类似地，在目标ME主机31T-B上的VDO 41T-B中，必要的资源被保留和激活(图26中的VDO资源保留/生成)。

此后，目标ME主机31T的ME平台83T向目标ME主机31T-A上的VDO 41T-A请求同步VDO处理，并向目标ME主机31T-B上的VDO 41T-B请求同步VDO处理。因此，VDO 41T-A和VDO41T-B可以与源ME主机31S上的VDO 41S同步地执行VDO处理。

假设在一段时间过去之后，源ME主机31S上的VDO 41S检测到其上安装有DASH客户端21的用户终端13经由ME平台83S移动，并且新连接至目标ME主机31T-A所绑定的目标RAN72T-A以及目标ME主机31T-B所绑定的目标RAN 72T-B(图32中DASH客户端到目标ME主机A和B的转移的检测)。

响应于此，执行流量改变，使得目标ME主机31T-A上的VDO 41T-A可以在转移之后从目标RAN 72T-A接收流传输请求(图32中对目标ME主机A的流量更新)。同时，执行流量改变，使得来自目标ME主机31T-A上的VDO 41T-A的响应到达用户终端13。

类似地，执行流量改变，使得目标ME主机31T-B上的VDO 41T-B可以在转移之后从目标RAN 72T-B接收流传输请求(图26中对目标ME主机B的流量更新)。同时，执行流量改变，使得来自目标ME主机31T-B上的VDO 41T-B的响应到达用户终端13。

此后，目标ME主机31T-A上的VDO 41T-A在经由目标RAN 72T-A移动之后开始向DASH客户端21的流传输(图32中的来自目标ME主机A的流传输)。此外，继续VDO 41T-A在目标ME主机31T-A上的同步VDO处理。

类似地，目标ME主机31T-B上的VDO 41T-B在经由目标RAN 72T-B移动之后开始向DASH客户端21的流传输(图32中的来自目标ME主机B的流传输)。此外，继续VDO 41T-B在目标ME主机31T-B上的同步VDO处理。

例如，如图33所示，假设可以通过在工作流描述中将目标应用程序的应用元素的复制属性设置成“真”来给出关于该冗余配置的指令。

<信息处理系统的第三信息处理示例>

作为信息处理系统11的第三信息处理示例，将参照图34至图38描述基于流量预测的VDO处理的状态的可变复制。例如，信息处理系统11的第三信息处理示例具有这样的特性，即，当在转移之前的VDO处理的状态相对于转移目的地的ME主机31上的VDO 41被同步复制时，流质量基于流量预测和ME主机31的资源预测而改变。

例如，假设在绑定到计划转移的目标RAN 41T的ME主机31T上执行的VDO 72T中预先检测到与转移之前的会话等效的会话资源不能被保证的可能性。在这种情况下，在预期转移之后流质量的改变时，执行VDO处理(在下文中，称为同步适配VDO处理请求)以生成质量改变的片段。然后，在目标质量的选择中，基于MPD或推荐速率在限制的范围内执行优化。

同样在这种情况下，如以上参照图29所述的在无法预测转移目的地小区(RAN 72)的情况下的处理中的同步VDO处理请求、如上参照图32所述的用于确保容错冗余的处理等可以被替换为同步适配VDO处理请求。

在图34的流程中示出此时执行的处理。注意，在图34所示的流程中，执行与图22的流程类似的处理，除了图22的流程中的同步VDO处理请求被同步适配VDO处理请求所代替，并且然后执行同步适配VDO处理，并且省略对其的详细描述。

图35是用于说明基于流量预测来可变地复制VDO处理的状态的处理的流程图。

例如，在步骤S51和S52中，执行与图23中的步骤S41和S42中的处理类似的处理。然后，在步骤S53中，VDO 41S将片段URL、MPD和VM发送到VDO 41T，并请求同步适配VDO处理。因此，VDO 41T在步骤S55中执行同步适配VDO处理。

然后，在步骤S54、S56和S57中，执行与图23中的步骤S44、S46和S47中的处理类似的处理。

如上所述，当VDO 41T执行同步适配VDO处理时，例如，可以基于流量预测可变地复制VDO处理的状态，并且例如，可以在转移之后预期流质量的改变而执行流传输。

这里，将描述同步适配VDO处理请求。

例如，如上所述，在转移之前流传输到转移DASH客户端21的源ME主机31S上的VDO41S检测到DASH客户端21转移到被绑定至目标ME主机31T的目标RAN 72T的可能性。响应于此，在目标ME主机31T上激活VDO 41T之后，执行关于VDO 41T的同步适配VDO处理。

然后，在同步适配VDO处理中，假设VDO处理之后的流质量在鉴于目标RAN 72T中的当前流量状态和目标ME主机31T中的计算、存储等资源状态而预期到未来DASH客户端21转移到目标RAN 72T的情况下假设的适当的流传输会话的约束而改变。

此外，存在以下可能性：取决于目标RAN 72T的当前流量和计算、存储等资源状态，或者取决于在DASH客户端21转移之后未来预测的流量和计算、存储等资源状态，不能确保在源ME主机31S中当前建立的会话资源。因此，在环境比当前环境更差的情况下，执行VDO处理，使得在当前再现的适配集的表示中生成具有较少资源消耗(例如，较低比特率)的表示的片段。注意，在一些情况下，从某个适配集中的表示组中选择表示，或者在其他情况下，改变适配集本身。以这种方式，例如，可以基于转移目的地的流量预测来自适应地选择具有不同流质量(较高比特率或较低比特率)的片段。

图36示出了当利用这样的同步适配VDO处理请求作为触发来执行VDO处理时的片段流。

例如，如图所示，假设在源ME主机31S的VDO 41S中用作再现目标的表示是表示-(高)，并且具有对于目标ME主机31T中的当前或未来资源状态最佳的属性的表示是表示-(低)。

然后，使用同步适配VDO处理请求作为触发，基于与当前再现的片段在相同时间段中的相同适配集的不同表示的片段来开始VDO处理。也就是说，根据同步适配VDO处理请求，在VDO 41S中，对具有较高比特率的片段SegH执行VDO处理，而在VDO 41T中，对具有较低比特率的片段SegL执行VDO处理。注意，当确认在通过目标ME主机31T的环境中确保了与通过当前的源ME主机31S的会话资源不同的会话资源时，执行该同步适配VDO处理请求。

在下文中，将描述同步适配VDO处理请求的消息传送协议。

例如，在转移到计划转移的目标ME主机31T上的VDO 41T之前，来自源ME主机31S上的VDO 41S的同步适配VDO处理请求的消息传送协议可被定义如下。

也就是说，VDO触发请求消息作为VDO 41之间的消息被引入。例如，VDO触发请求元素具有指示VDO处理是否是适配的适配VDO属性、用于将来自VDO 41S的VM存储在源ME主机31S上的viewportMetricsFromDASHClient属性、以及用于指定目标流的片段的流元素。

图37示出了VDO触发请求的结构的示例。

例如，适配VDO属性指示正常VDO处理以假值执行，并且符合性VDO处理以真值执行。

此外，例如，在上述图35的步骤S52中，DASH客户端21向VDO 41S发出viewportMetricsFromDASHClient属性。

此外，流元素具有对MPD的引用，包括要控制的流的属性(MPD的URL)或用于存储MPD主体的mpd属性，并且具有用于存储指示MPD中描述的特定片段的XPath字符串的片段路径属性。

这里，通过使用例如如图38所示的HTTP-POST将VDO触发请求消息从源ME主机31S上的VDO 41S传送到目标ME主机31T上的VDO 41T。

例如，图38示出了在由(视口度量)指示的视点方向上优化的片段可以被改变成对于作为转移目的地的ME主机31的环境最优的质量(例如，比特率等)，并且相对于在http://a.com/a.mpd的URL处指定的mpd的初始时段元素的初始适配集元素的片段模板元素中指定的片段生成。

<边缘服务器中的VDO处理的概要>

将参照图39描述边缘服务器中的VDO处理的概要。

例如，图39的A示出了在传统信息处理系统中执行的VDO处理的概要，并且图39的B示出了在作为本实施方式的信息处理系统11中的边缘服务器的ME主机31中执行的VDO处理的概要。

例如，在传统的信息处理系统中，通过在原始服务器32中区域性打包(RWP)而生成的DASH片段被多播到ME主机31-1至31-3。然后，基于MPD选择适合于DASH客户端21-1至21-3的每个状态的DASH片段，并且基于每个片段URL从ME主机31-1至31-3获取DASH片段。

另一方面，在信息处理系统11中，DASH片段从原始服务器32多播到ME主机31-1至31-3。然后，基于MPD选择适合于DASH客户端21-1至21-3中的每个的状态的片段，并且基于片段URL和VM在ME主机31-1至31-3中的每个中执行RWP。因此，针对每个DASH客户端21-1至21-3的视口优化的DASH片段可以在ME主机31-1至31-3中生成，并且分别由DASH客户端21-1至21-3获取。

因此，在信息处理系统11中，通过对ME主机31-1至31-3中的VR流传输执行分发处理，可以避免负载集中或在原始服务器32中发生延迟。

<计算机的配置示例>

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

图40是示出其中安装了用于执行上述一系列处理的程序的计算机的实施方式的配置示例的框图。

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

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

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

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

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

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

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

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

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

此外，在本说明书中，系统是指多个部件(设备、模块(部件)等)的集合，并且所有部件是否在同一壳体中无关紧要。因此，容纳在不同壳体中并且经由网络连接的多个设备和其中多个模块被容纳在一个壳体中的一个设备均是系统。

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

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

此外，例如，上述程序可以在任意设备中执行。在这种情况下，如果设备具有必要的功能(功能块等)并且可以获得必要的信息就足够了。

此外，例如，上述流程图中描述的每个步骤可以由一个设备执行或由多个设备共享。此外，在一个步骤包括多个处理的情况下，一个步骤中包括的多个处理可以由一个设备执行或者由多个设备共享。换言之，包括在一个步骤中的多个处理也可以作为多个步骤的处理被执行。相反，描述为多个步骤的处理可以作为一个步骤来共同执行。

注意，在由计算机执行的程序中，描述程序的步骤中的处理可以按照本说明书中描述的顺序以时间序列来执行，或者可以在诸如进行调用时以必要的定时处单独执行或并行执行。也就是说，只要不存在矛盾，则可以以与上述顺序不同的顺序执行每个步骤的处理。此外，描述程序的步骤的处理可以与另一程序的处理并行执行，或者可以与另一程序的处理组合执行。

注意，只要不存在矛盾，本说明书中描述的多个本技术就可以独立地实现。当然，可以组合地实现多个任意的现有技术。例如，在任何实施方式中描述的本技术的一些或全部可以与在其他实施方式中描述的本技术的一些或全部组合地实现。此外，可以与以上未描述的其他技术组合地实现上述任意的本技术中的一些或全部。

<配置的组合示例>

注意，本技术还可以具有以下配置。

(1)

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

优化处理单元，其通过根据客户终端中的视点方向对与所述客户终端的请求相对应的片段执行优化处理，根据从分发服务器多播的内容生成优化片段；以及

发送单元，其将所述优化片段发送到所述客户终端。

(2)

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

所述发送单元经由第一网络将所述内容流传输到所述客户终端，所述装置还包括：

同步优化处理请求单元，其响应于由于所述客户终端的移动而发生的从所述第一网络到第二网络的切换，请求经由所述第二网络向所述客户终端流传输所述内容的另一信息处理装置执行与所述优化处理单元同步的优化处理。

(3)

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

所述同步优化处理请求单元向所述另一信息处理装置发送用于指定所述片段的信息、作为描述所述内容的元数据的文件的MPD(媒体呈现描述)、以及指示所述客户终端中的视点方向的视点方向信息，并且执行控制以复制所述优化处理单元中的处理状态。

(4)

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

所述视点方向信息被附接至所述片段的请求，并且从所述客户终端被发送。

(5)

根据(4)所述的信息处理装置，其中，

所述客户终端通过使用在MPEG-DASH(基于HTTP的MPEG动态自适应流)中定义的URL参数，向所述优化处理单元通知所述视点方向信息。

(6)

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

所述同步优化处理请求单元在请求所述另一信息处理装置执行所述优化处理时，改变切换之前和切换之后的内容的流质量。

(7)

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

所述同步优化处理请求单元基于切换之后网络中的流量预测或所述另一信息处理装置的资源预测，改变所述内容的流质量。

(8)

一种用于信息处理装置的信息处理方法，包括：

通过根据客户终端中的视点方向对与所述客户终端的请求相对应的片段执行优化处理，根据从分发服务器多播的内容生成优化片段；以及

将所述优化片段发送到所述客户终端。

(9)

一种用于使信息处理装置的计算机执行信息处理的程序，包括：

通过根据客户终端中的视点方向对与所述客户终端的请求相对应的片段执行优化处理，根据从分发服务器多播的内容生成优化片段；以及

将所述优化片段发送到所述客户终端。

注意，本实施方式不限于上述的实施方式，并且在不脱离本公开内容的范围的情况下可以进行各种修改。此外，本说明书中描述的效果仅为示例，而非限制性的，并且可以提供其他效果。

附图标记列表

11 信息处理系统

12 云

13 用户终端

21 DASH客户端

31 ME主机

32 原始服务器

33 ME平台(编排器)

41 VDO

42 数据库保存单元

43 存储单元

61 数据库保存单元

62 工作流管理器

71 5G核心网系统

72 接入网

81 数据平面

82 应用程序

83 ME平台

84 UPF