CN110945873A - 下一代网络上的360度视频递送 - Google Patents

下一代网络上的360度视频递送 Download PDF

Info

Publication number
CN110945873A
CN110945873A CN201880048278.2A CN201880048278A CN110945873A CN 110945873 A CN110945873 A CN 110945873A CN 201880048278 A CN201880048278 A CN 201880048278A CN 110945873 A CN110945873 A CN 110945873A
Authority
CN
China
Prior art keywords
segment
degree video
streaming device
segments
video streaming
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.)
Granted
Application number
CN201880048278.2A
Other languages
English (en)
Other versions
CN110945873B (zh
Inventor
贺勇
叶艳
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.)
Vid Scale Inc
Original Assignee
Vid Scale Inc
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 Vid Scale Inc filed Critical Vid Scale Inc
Priority to CN202211267345.4A priority Critical patent/CN115567755A/zh
Publication of CN110945873A publication Critical patent/CN110945873A/zh
Application granted granted Critical
Publication of CN110945873B publication Critical patent/CN110945873B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/816Monomedia components thereof involving special video data, e.g 3D video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/21805Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4728End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for selecting a Region Of Interest [ROI], e.g. for requesting a higher resolution version of a selected region
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6587Control parameters, e.g. trick play commands, viewpoint selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

公开了用于360度视频流传输的系统、方法和手段。视频流传输设备可以从网络节点接收360度视频流。所述视频流传输设备可以确定与所述视频流传输设备和/或所述360度视频流相关联的视窗。所述视频流传输设备可以(例如,基于视窗)确定提前请求所述360度视频流的第一分段和第二分段。所述视频流传输设备可以确定所述第一分段和第二分段的相对优先级顺序。所述视频流传输设备可以生成预期请求消息。该预期请求消息可以例如通过基于所确定的相对优先级顺序以递减的相对优先级列出第一分段和第二分段来指示所确定的相对优先级顺序。所述视频流传输设备可以向所述网络节点发送所述预期请求消息。

Description

下一代网络上的360度视频递送
相关申请的交叉引用
本申请要求2017年6月2日提交的美国临时专利申请no.62/514,405的优先权,其通过引用整体而被并入本文。
背景技术
360度视频是媒体行业中出现的快速增长的格式。360度视频可通过虚拟现实(VR)设备的日益增长的可用性来实现。360度视频可以向观看者提供新的存在感。当与直线视频(例如,2D或3D)相比时,360度视频可能对视频处理和/或递送造成困难的工程挑战。实现舒适和/或沉浸式用户体验可能需要高视频质量和/或非常低的延时。360度视频的大视频尺寸可能是按质量方式按比例递送360度视频的障碍。
发明内容
公开了用于360度视频流传输的系统、方法和手段。视频流传输设备(例如,诸如无线发射/接收单元(WTRU))可以从网络节点接收360度视频流。该网络节点可以是网络附着点(NAP)。所述视频流传输设备可以确定与该视频流传输设备和/或所述360度视频流相关联的视窗。该视窗可以是所述360度视频流的正被呈现给所述视频流传输设备的用户的空间区域。可以基于所述视频流传输设备的朝向来确定所述视窗。所述视频流传输设备可以(例如,基于视窗)确定提前请求所述360度视频流的第一分段和所述360度视频流的第二分段。所述360度视频流可以包括两个或更多个时间帧。所述360度视频流的时间帧中的每一者可被分割成多个图块。所述第一分段可以是所述360度视频流的两个或更多个时间帧中的帧的第一图块。第二分段可以是所述360度视频流的所述两个或更多个时间帧中的所述帧的第二图块。
所述视频流传输设备可以确定所述第一分段和第二分段的相对优先级顺序。可以通过例如基于时间偏好、质量偏好和/或相对于视窗的位置确定第一分段的第一优先级和第二分段的第二优先级来确定所述相对优先级顺序。所述视频流传输设备可以生成预期请求消息。该预期请求消息可以例如通过基于所确定的相对优先级顺序以递减的相对优先级列出第一分段和第二分段来指示所确定的相对优先级顺序。所述视频流传输设备可以向所述网络节点发送所述预期请求消息。
网络节点可以从第一视频流传输设备接收第一预期请求消息,该第一预期请求消息指示按照第一相对优先级顺序的第一多个分段。所述网络节点可以从第二视频流传输设备接收第二预期请求消息,该第二预期请求消息指示按照第二相对优先级顺序的第二多个分段。所述网络节点可以是NAP。所述网络节点可以确定与所述第一多个分段中的每个分段(例如,基于第一相对优先级顺序)和第二多个分段中的每个分段(例如,基于第二相对优先级顺序)相关联的优先级。所述网络节点可以将由所述第一预期请求消息和所述第二预期请求消息指示的公共分段识别为具有相同优先级。所述网络节点可以向服务器发送对所述公共分段的请求。所述网络节点可以接收所述公共分段并且可以将所述公共分段多播到所述第一视频流传输设备和所述第二视频流传输设备。例如,所述网络节点可以确定所述公共分段表示在时间窗口内具有相同优先级的相同视频分段。所述网络节点可以确定向服务器请求所述公共分段。所述网络节点可以向所述第一视频流传输设备和所述第二视频流传输设备单播被指示为具有不同优先级的分段。
所述网络节点可以确定一分段在所述第一多个分段和所述第二多个分段之间是公共的。例如,所述网络节点可以确定在所述第一预期请求消息和所述第二预期请求消息中指示了一公共分段。该公共分段可以表示一时间窗口内的相同视频分段。所述网络节点可以确定由所述第一预期请求消息指示(例如,基于该第一预期请求消息)的所述公共分段的第一优先级值和由所述第二预期请求消息指示(例如,基于该第二预期请求消息)的所述公共分段的第二优先级值。所述网络节点可以例如向服务器发送对所述公共分段的请求。所述网络节点可以例如从所述服务器接收所述公共分段。在所述第一优先级值和所述第二优先级值相同的情况下,所述网络节点可以将所述公共分段多播到所述第一视频流传输设备和所述第二视频流传输设备。在所述第一优先级值和所述第二优先级值不同的情况下,所述网络节点可以将所述公共分段单播到所述第一视频流传输设备和所述第二视频流传输设备。
附图说明
图1示出了360度视频的示例性等矩形投影(ERP)。
图2示出了在头戴式设备(HMD)上显示的360度视频的示例性部分。
图3示出了ERP格式的360度视频的示例性处理和递送。
图4示出了用于处理和递送360度视频的示例性单流视窗适配方法。
图5示出了用于处理和递送360度视频的示例性的基于图块的视窗适配方法。
图6示出了用于处理和递送360度视频的示例性的基于层的视窗适配方法。
图7示出了网际协议(IP)单播方法的示例。
图8示出了信息中心联网(ICN)方法的示例。
图9示出了示例性媒体呈现描述(MPD)分级数据模型。
图10示出了使用DASH服务器推送进行视频流传输的示例性工作流。
图11示出了示例性的基于图块的360度视频超文本传输协议(HTTP)请求。
图12示出了示例性的基于层的360度视频HTTP请求。
图13示出了示例性的基于图块的360度视频HTTP请求。
图14示出了示例的基于图块的HTTP请求时间。
图15示出了示例性的基于层的360度视频HTTP请求。
图16示出了示例性的基于层的逼近HTTP请求时间。
图17示出了使用多播进行客户端发起的360度视频流传输的示例性工作流。
图18示出了用于基于图块的360度视频流传输的示例性网络附着点(NAP)分类和映射。
图19示出了用于基于层的360度视频流传输的示例性NAP分类和映射。
图20示出了具有AnticipatedRequests(预期请求)和本地存储缓冲器的示例性多播设计。
图21(a)-(c)示出了基于图块的360度视频分段递送的示例。
图22示出了服务器和网络辅助的HTTP上动态适配流传输(SAND)RequestOrder(请求顺序)消息的示例性多播增益。
图23示出了RequestOrder消息的示例性工作流。
图24示出了用于服务器推送的多播设计的示例性工作流。
图25示出了经由服务器推送的基于图块的360度视频流传输的示例性NAP多播决策。
图26示出了经由服务器推送的基于层的360度视频流传输的示例性NAP多播决策。
图27示出了具有灵活推送顺序的示例性多播工作流。
图28示出了具有NAP发起推送类型的示例性多播工作流。
图29A是其中可以实施一个或多个公开的实施例的示例性通信系统的系统图。
图29B是根据实施例的可在图29A中所示的通信系统内使用的示例性无线发射/接收单元(WTRU)的系统图。
图29C是根据实施例的可在图29A中所示的通信系统内使用的示例性无线电接入网络(RAN)和示例性核心网络(CN)的系统图。
图29D是根据实施例的可在图29A中所示的通信系统内使用的另一示例性RAN和另一示例性CN的系统图。
具体实施方式
现在将参考各个附图来描述说明性实施例的详细描述。尽管本说明书提供了可能实施方式的详细示例,但是应当注意,这些细节旨在是示例性的,而不以任何方式限制本申请的范围。
360度视频可以是虚拟现实(VR)的组成部分。360度视频可被捕捉和/或渲染在球体上。球形视频格式可能是不能通过使用一些或所有可用的视频编解码器直接递送的。360度视频(例如,球形视频)可以通过使用某种投影方法将所述球形视频投影到2D平面上来压缩。可以对所投影的2D视频进行编码(例如,使用一些或所有可用的视频编解码器进行编码)。所述投影方法的示例可以包括等矩形投影(ERP)。
图1示出了用于360度视频的示例性ERP。例如,ERP可以使用以下等式中的一个或多个来将球体上的具有坐标(θ,
Figure BDA0002374465280000051
)的第一点P映射到具有2D平面上的具有坐标(u,v)的第二点P,如图1所示。
u=φ/(2*pi)+0.5 (1)
v=0.5–θ/(pi) (2)
图2示出了在头戴式设备(HMD)上显示的360度视频的示例性部分。当观看360度视频时,可以向用户呈现该视频的一部分,例如,如图2所示。当用户环顾和/或缩放图像时,可以改变所述视频的该部分。可以基于HMD和/或其他类型的用户接口(例如,无线发射/接收单元(WTRU)或智能电话)提供的反馈来改变所述视频的该部分。整个360度视频的空间区域可以被称为视窗(viewport)。该视窗被完全或部分地呈现给用户。所述视窗可以具有与360度视频的其他部分不同的一个或多个质量。
以ERP或其它投影格式表示的360度视频可以使用诸如H.264和H.265等某些视频编码器而被编码为单层比特流。该整个编码比特流可以存储在服务器处,可以被发送到接收机侧,可以由解码器解码,并且可以向用户渲染所解码的画面的与当前视窗相对应的区域。图3示出了处理和递送ERP格式的360度视频的示例。如图3所示,ERP格式的360度视频可被编码成一个或多个比特率分段以用于适配流传输。用户可以根据网络条件而动态地选择特定的分段。可以基于用户的朝向和/或视窗而向用户渲染所解码的帧的区域。图3中所示的示例可以使用很大带宽来编码整个360度视频,以便在视频的一小部分被用户消费时提供沉浸式用户体验。
全向视频(例如,整个视频区域)可由可对应于当前视窗的一个或一个以上视频图片表示。当前视窗可为由多个视频图片表示的整个视频区域的子集。所述当前视窗可以由用户在给定时间观看。例如,全向视频可以显示当前视窗(例如,用户当前正在看到的区域)。显示整个视频的子集(例如,视窗)可降低传输带宽和/或降低解码复杂度。
在单一比特流视窗适配方法中,360度视频可被编码到单一比特流中。可在相对于360度视频帧的其它区域的特定区域(例如,对应于视窗的区域)上分配更多的比特。可针对360度视频编码多个比特流,其中每一比特流可对应于特定视窗。可针对具有不同特性(例如,不同比特率)的同一视窗来编码一个或一个以上比特流。接收机可基于网络条件、观看者的当前或预测朝向、和/或视窗来选择特定比特流。可以降低总比特率,并且可以在可见视窗区域上递送高质量图像,而可以在其他不可见区域上递送低质量图像。一个或多个元数据可以指示视窗区域。
图4示出了用于处理和递送360度视频的示例性单流视窗适配方法。可在360度视频中识别两个或两个以上视窗(例如,视窗#1和视窗#2)。可为视窗区域分配比视频帧的剩余区域更多的比特。举例来说,流#1和/或流#2可在视窗#1区域上分配比视频帧的剩余区域更多的比特。每个流可以用不同的带宽编码。例如,流#1可以以1Mbps被编码,并且流#2可以以5Mbps被编码。流#3和/或#4可在视窗#2区域上分配比视频帧的剩余区域更多的比特。流#3可以以1Mbps被编码,并且流#4可以以5Mbps被编码。基于用户的观看朝向和/或网络带宽,用户可相应地选择流。如本文所述,用户可以被以下各项中的一个或多个所指代和/或互换地使用:WTRU、客户端WTRU、DASH客户端、流传输客户端、视频流传输设备和/或类似设备。举例来说,基于用户的观看朝向和/或网络带宽,用户可在经由低带宽(BW)信道观看视窗#1时,选择流#1,且可在经由高BW信道观看视窗#2时,切换到流#4。
基于图块的视窗适配方法可以包括在编码之前将源内容划分成多个图块序列。图块序列可覆盖完整全景内容的空间区域的子集。图块序列可被彼此独立地编码为单层比特流。可以从相同的子图片序列编码一个或多个比特流(例如,针对不同的比特率)。每一图块比特流可作为轨道而封装在文件中且可用于流传输。在接收机侧,可以基于用户的朝向和/或视窗元数据来选择要流传输的轨道。客户端可以接收覆盖整个全向内容的一个或多个图块轨道。可以针对当前视窗接收较高质量的图块轨道,并且可以针对剩余的且当前不可见的区域接收较低质量的图块轨道。每个轨道可以用单独的解码器解码。
图5示出了用于处理和递送360度视频的示例性的基于图块的视窗适配方法。如图5中所示,360度帧可被分割成一个或一个以上图块。图块可被编码成高质量比特流(例如,H1、H2、H3、和/或H4)和/或低质量比特流(例如,L1、L2、L3、和/或L4)。接收机可以基于朝向和/或视窗元数据而选择不同的图块比特流。例如,可以为视窗区域选择高质量图块(例如,H1和/或H2),并且可以为其他区域(例如,不可见区域)选择低质量图块(例如,L3和/或L4)。
图6示出了用于处理和递送360度视频的示例性的基于层的视窗适配方法。可以使用视频编码方法来利用360度视频(例如,整个360度视频)对基础层进行编码。一个或多个感兴趣区域(ROI)增强层(EL)可以用可缩放视频编码来编码。举例来说,一个或一个以上ROI EL可用具有层间预测的可缩放视频编码来编码。在另一示例中,一或多个ROI EL可用无层间预测的可缩放视频编码来编码。例如,每个图块位置的一个或多个层可以被编码,并且每个层可以具有不同的比特率和/或分辨率。所述ROI EL可以是空间和/或质量可缩放性层。可针对不同比特率编码一个或一个以上可缩放高效视频编码SHVC比特流。比特率适配可被配置成用一个或多个EL来处理。如图6所示,可接收并解码所述基础层。可基于所接收和/或经解码的当前观看朝向来选择一个或一个以上EL。
下一代网络(NGN)平台可以基于信息中心联网(ICN)提供灵活的路由解决方案。所述NGN平台可以是ICN和网际协议(IP)的混合。例如,NGN平台可以被配置为重新引入多播,其可以降低带宽使用。
图7示出了示例性IP单播方法。如图7所示,服务器可响应一个或多个WTRU请求,并且可将一个或多个所请求的内容分别递送到每个WTRU,即使多个WTRU可在大致相同的时间请求相同的内容。一个或多个内容递送网络(CDN)可以被用于流行内容以减少整体业务量。配置CDN可能是复杂的,并且可能导致与间接性(indirection)相关联的低效率,这对于新兴网络(诸如5G网络)可能是不可持久的。
图8示出了示例性ICN方法。如图8所示,隐式多播可被配置为在两个或更多WTRU在大致相同的时间观看相同的视频内容时使用。所述ICN可以使用网关(例如,网络附着点(NAP))。该网关可以被配置为从两个或更多客户到网络的接入网关。所述NAP可被配置成处理一些或所有协议(例如,IP、传输控制协议(TCP)、和/或超传输协议(HTTP)等),并且可提供标准网关功能,例如网络地址转换(NAT)、防火墙和/或动态IP地址指派。所述ICN网络对于WTRU和/或对等网络可以表现为标准IP网络,其中由NAP执行的HTTP到ICN转换机制。所述NAP可解析到服务器的一些或所有WTRU HTTP请求,并可识别在给定时间窗口(T)内从所述服务器请求相同内容的WTRU(例如,确定在大致相同的时间观看相同内容的WTRU)。所述NAP可向所述服务器发送请求,且所述系统可提供隐式多播以将所请求的内容递送到一些或所有WTRU。这里描述的隐式多播方法可以减少总带宽和/或服务器负载。对于请求不同内容或请求相同内容但超过给定时间窗口(T)的WTRU,可使用单播方法将所述内容从所述服务器递送到所述请求WTRU。本文描述的混合多播/单播方法可以通过本地多播为视频流传输使用情况提供网络利用,其中所述视频流传输使用情况例如为直播、视频点播、视频共享、和/或个性化VR应用等。
通过HTTP的MPEG动态适配流传输(MPEG-DASH)可以是示例性的递送格式,其可以通过动态地适应于变化的网络条件来向终端用户提供最佳可能的视频体验。DASH可以建立在HTTP/TCP/IP栈之上。DASH可以定义清单格式(其可以是媒体呈现描述(MPD))和/或分段格式。
所述MPD可以包括可扩展标记语言(XML)文档,该文档可以包括用于DASH客户端的元数据,以便在流传输会话期间构造适当的HTTP-URL来以适配方式访问视频分段(例如,如本文所述)。图9示出了示例性MPD分级数据模型。所述MPD可描述时段序列,其中媒体内容分量的编码版本的一致集合在一时段期间不改变。每个时段可以包括一个或多个适配集(例如,AdaptationSet(适配集))。
AdaptationSet可以表示共享一个或多个相同属性(例如,语言、媒体类型、图片纵横比、角色、可访问性、视点和/或评级属性)的一个或多个媒体内容分量的编码版本的集合。例如,第一AdaptationSet可以包括不同比特率的相同多媒体内容的视频分量。第二适应性设置可包括不同比特率的相同多媒体内容的音频分量(例如,较低质量立体声和/或较高质量环绕声)。每个AdaptationSet可以包括一个或多个Representation(表示)。
Representation可以描述一个或多个媒体分量的可递送的编码版本,其在比特率、分辨率、信道数量和/或其他特性方面不同于其他表示。每个Representation可以包括一个或多个分段。Representation元素的一个或多个属性(例如,@id、@bandwidth(带宽)、@qualityRanking(质量排名)和/或@dependencyId(依从Id))可以用于指定相关联的Representation的一个或多个属性。
Segment(分段)可以是可以用HTTP请求检索的数据单元(例如,最大数据单元)。分段可以具有URL(例如,服务器上的可寻址位置)。每个分段可以使用HTTP GET或具有字节范围的HTTP GET来下载。
DASH客户端可以解析MPD XML文档。所述DASH客户端可以例如基于在AdaptationSet元素中提供的信息来选择适合于其环境的AdaptationSet集合。在AdaptationSet中,客户端可以选择Representation。客户端可以基于@bandwidth属性、客户端解码能力和/或客户端渲染能力的值来选择Representation。所述客户端可以下载所选择的Representation的初始化分段。客户端可以访问所述内容(例如,通过请求整个分段或字节范围的分段)。当呈现已经开始时,客户端可以继续消费所述媒体内容。例如,客户端可以在所述呈现期间请求(例如,连续地请求)媒体分段和/或媒体分段的部分。客户端可以根据媒体呈现时间线来播放内容。客户端可以考虑来自该客户端的环境的更新信息来切换Representation。举例来说,客户端可基于来自该客户端的环境的更新信息从第一Representation切换到第二Representation。客户端可以跨时段(例如,两个或更多个时段)播放所述内容(例如,连续地播放)。当客户端消费Segment中包含的媒体接近所述Representation中所通告媒体的结尾处时,所述媒体呈现可以被终止,并且可以开始新的时段和/或可以重新获取所述MPD。
MPD描述符元素(其可被称为Descriptor(描述符))可被提供给应用以用适当的方案信息来实例化一个或多个描述元素。某些Descriptor(例如,内容保护、角色、可访问性、评级、视点、帧打包和/或UTC定时描述符)可包括@schemeIdUri属性以标识相关方案。MPD元素可以是补充属性描述符(例如,SupplementalProperty(补充属性)),其可以包括可由DASH客户端用于优化处理的元数据。所述MPD元素可以是基本属性描述符(例如,EssentialProperty(基本属性)),其可以包括用于处理包含元素的元数据。
服务器和网络辅助DASH(SAND)可以指定在流传输客户端和网络元件之间或各种网络元件之间交换的消息。流传输客户端(例如,DASH客户端)和网络元件之间或各种网络元件(例如,包括DASH感知网络元件(DANE))之间的消息可以提供关于网络、服务器、代理、缓存、CDN、和/或DASH客户端的性能和状态等的实时操作特性的信息。
可以使用以下SAND消息中的一个或多个:AnticipatedRequests(预期请求)、AcceptedAlternatives(所接受替代者)、AbsoluteDeadline(绝对截止时间)、和/或DeliveredAlternative(所递送替代者)等。
AnticipatedRequests消息可以允许DASH客户端向DANE通告DASH客户端可能对哪个特定分段集合感兴趣。所述AnticipatedRequests消息可以用信号通知DASH客户端可能选择并且可能很快请求的表示中的分段集合。表1示出AnticiptedRequests消息的示例性参数。
表1:AnticiptedRequests消息的示例性参数
Figure BDA0002374465280000121
AcceptedAlternationes消息可允许DASH客户端在DASH客户端请求给定DASH分段时通知媒体递送路径上的DANE(例如,缓存DANE):该DASH客户端可能愿意接受其它DASH分段作为替代者。如果客户端准备接收替代分段并且能够播放该替代分段,则该客户端可以包括替代分段。表2示出了AcceptedAlternationes消息的示例性参数。
表2:AcceptedAlternationes消息的示例性参数
Figure BDA0002374465280000131
AbsoluteDeadline消息可以允许DASH客户端向DANE指示挂钟时间中的绝对截止时间,在该时间之前,需要完全接收所请求的分段。表3示出了AbsoluteDeadline消息的示例性参数。
表3:AbsoluteDeadline消息的示例性参数
Figure BDA0002374465280000141
DeliveredAlternative消息可以是对DASH客户端发送的AcceptedAlternatives消息的响应。DANE可递送替代分段而不是所请求的分段。如果DANE递送替代分段而不是所请求的分段,则DANE可向DASH客户端发送DeliveredAlternative消息以通知:该响应包括分段替代者而不包括所请求的分段。表4示出了DeliveredAlternative消息的示例性参数。
表4:DeliveredAlternative消息的示例性参数
Figure BDA0002374465280000142
通过利用可由诸如HTTP/2和/或WebSocket等新近IP提供的特征和/或能力,可以增强HTTP/1.1上的MPEG-DASH的基本机制。
图10示出了使用DASH服务器推送进行视频流传输的示例性工作流。客户端可以利用推送策略来请求MPD和媒体分段。例如,通过使用推送策略,客户端可以首先请求所述MPD,并且可以来请求媒体分段。初始化数据可由服务器响应于与MPD请求相关联的推送策略而被推送。在接收到所请求的MPD之后,客户端可以开始利用相应的DASH分段URL和/或分段推送策略从服务器请求一个或多个视频分段。所述服务器可以用所请求的视频分段来响应,随后是如分段推送策略所指示的推送循环。所述客户端可以在接收到最小量的数据之后开始回放视频。这里描述的过程可以重复,直到媒体流传输会话结束。
表5示出了示例性推送策略类型。表6示出了每个PushType(推送类型)可应用于哪个请求的示例。
表5:DASH服务器推送策略类型的示例
Figure BDA0002374465280000161
表6:每个PushType的有效请求类型和参数的示例
Figure BDA0002374465280000171
360度视频由于高分辨率和/或高帧率而可能消耗大量带宽以提供引人注目的沉浸体验。对于诸如VR共享、实时VR流传输和/或社交VR应用之类的用例,数百上千个VR用户可能观看相同的360度视频,同时聚焦在不同的视窗。这里描述的视窗适配方法(例如,基于图块的或基于层的处理和递送方法)可以减少VR用户(一个或多个)的带宽消耗。
NGN平台支持的基于ICN的路由方法可以提供减少多个VR用户的带宽的机会。例如,360度视频的公共共享区域可被从服务器获取(例如,获取一次)并且可以被转发到多个VR用户。可以从所述服务器获取一个或多个唯一视窗分段,并且可以将其单独转发到对应的WTRU。例如,当两个VR用户使用基于图块的流传输方法正在观看相同视窗时,所述NGN可以实现多播增益,因为该两个用户正在共享相同的高质量视窗图块和/或剩余的低质量图块。在客户端侧的不同决策制定策略可以导致每个VR WTRU发出不同的HTTP请求序列。
图11示出了示例性的基于图块的360度视频HTTP请求。如图11所示,共享相同视窗的两个或更多WTRU(例如WTRU#A和WTRU#B)中的每一个WTRU可以发送HTTP请求。WTRU#A的用户A可以在其它图块(例如,图块L3和/或L4)之前请求一个或多个视窗图块(例如,图块H1和/或H2)。WTRU#B的用户B可以在一些或所有其他图块(例如,图块L3和/或L4)之后请求视窗图块(例如,图块H1和/或H2)。DASH客户端实施可以被配置成确定视窗图块和/或其他图块的顺序。NGN可以被配置成将每个图块多播至两个WTRU,例如,因为这些图块由该两个WTRU共享。如果如图11所示,图块分段不是大约同时从该两个用户被请求的,则所述NGN可以如同单播那样从所述服务器单独地获取每个共享分段。
对于基于层的方法,可使用层间预测。例如,在基于层的方法中,可以不使用层间预测。如图6所示,图6中的EL比特流可以是从图6中的BL比特流可独立解码的。如果BL比特流是可独立解码的,则客户端可以在该客户端可以获取一个或多个BL分段之前选择获取一个或多个EL分段。例如,客户端可以选择获取一个或多个EL分段(例如,在其获取一个或多个BL分段之前),因为客户端可能想要首先接收一个或多个视窗(例如,所述EL分段)。对于其他示例,其他客户端可以首先获取一个或多个BL分段,因为客户端可能想要首先接收整个360度视频(例如,在获取一个或多个EL分段之前)。在这种情况下,每个客户端的HTTP请求可以具有针对基础层分段和/或针对增强层分段的不同顺序,如图12所示。例如,图12示出了示例性的基于层的360度视频HTTP请求。如图12所示,WTRU#A可在接收一个或多个增强层分段(例如H2和/或H1)之前发送具有基础层分段(例如BL)的HTTP请求。WTRU#B可以在接收基础层分段(例如BL)之前发送具有一个或多个增强层分段(例如H2和/或H1)的HTTP请求。
不同的视窗可被不同的客户端观看。图13示出了示例性的基于图块的360度视频HTTP请求。如图13所示,两个或更多WTRU(例如WTRU#A和WTRU#B)可以具有相同的HTTP请求顺序,而每个WTRU可以观看不同的视窗。例如,WTRU#A的视窗可以包括图块#1(例如H1),而WTRU#B的视窗可以包括图块#3(例如H3)。图块#1和/或图块#3(例如,H1和/或H3)可经由单播而被流传输,因为图块#1和/或图块#3可能不被两个WTRU共享。NGN可被配置成经由隐式多播从服务器一次获取两个WTRU的公共共享的图块#2和/或图块#4(例如,L2和/或L4)。高质量图块的文件大小可以大于低质量图块的文件大小。不同的图块大小可能会偏移WTRU之间的HTTP请求时间(例如,Δt),如图14所示。图14示出了示例性的基于图块的HTTP请求时间。如图14所示,来自WTRU#A和WTRU#B的对图块#2的HTTP请求可能超过多播决策时间窗口(T<ΔT)。该决策时间窗口(T)可以被配置为增大,使得T可以大于ΔT。
图15示出了示例性的基于层的360度视频HTTP请求。例如,WTRU#A的用户A的视窗可以在EL区域#1(例如H1)内部,而WTRU#B的用户B的视窗可以穿过EL区域#3和#4(例如H3和H4),如图15所示。如果该两个用户在该用户请求增强层分段之前请求基础层分段,则随着时间的推进,可能会发生针对基础层分段的HTTP请求错位。图16示出了示例性的基于层的逼近HTTP请求时间。如图16所示,对与帧#1相对应的BL的请求可能是同步的。对与帧#2相对应的BL的请求可能不同步。
服务器和网络辅助DASH(SAND)消息和/或推送策略可以被配置为当多个VR用户在大约相同的时间观看相同的360度视频时,通过NGN平台递送360度视频。
可以提供混合多播/单播联网架构。例如,整个360度视频可以被编码成单个层和/或单个组块文件。当两个或更多用户在大致相同的时间观看相同360度视频的相同视窗时,所述混合多播/单播联网架构可以实现多播增益。
即使WTRU在观看会话期间可共享一些相同的分段,视窗适配流传输方法也可能不能实现足够的多播增益,因为客户端侧分段请求可能是不同步的。
HTTP/1.1上的MPEG-DASH可以基于客户端发起的机制,其中客户端可以从服务器(例如,主动地)拉取媒体数据。DASH标准的关于服务器和网络辅助DASH(SAND)的第5部分可以在DASH客户端和网络元件之间或者各种网络元件之间引入消息,以用于高效的流传输会话和/或DASH内容的高效递送。SAND消息可提供关于以下一个或多个的实时操作特性的信号信息:网络、服务器、代理、缓存、CDN、和/或DASH客户端的性能和状态等。网络连接点(NAP)可以使用这里描述的一个或多个消息来优化其媒体递送策略,以用于基于图块或基于层的360度视频流传输。
SAND消息可由NAP用于提前识别多播视频分段(例如,假设DASH客户端和NAP都支持DASH SAND)。所述NAP可以是DASH感知网络元件(DANE)。
对于基于图块的360度视频流传输,DASH客户端能够确定要提前请求的图块分段。所述DASH客户端可以基于其观看朝向而确定要提前请求的图块分段,这其中可包括用于不可见区域的低质量图块和/或用于可见视窗的高质量图块。客户端可以使用AnticpictedRequests消息来通知网络节点(例如,服务器或NAP)不久将被请求的一些或所有图块分段。DASH SAND可以提供一种机制,以允许服务器将一个或多个不同的分段和/或以与所请求的分段不同的顺序的分段发送到客户端。基于本文所述的机制,NAP可重新对齐所述客户端请求和/或将公共共享分段多播到一个或多个客户端WTRU。例如,所述NAP可多播由两个或更多客户端请求的具有相同优先级的公共分段。
例如,所述NAP可以从第一视频流传输设备(例如DASH客户端)接收第一AnticipatedRequests消息。该第一AnticipatedRequests消息可以指示按照第一相对优先级顺序的第一多个分段。所述NAP可以从第二视频流传输设备接收第二AnticipatedRequests消息。该第二AnticipatedRequests消息可以指示按照第二相对优先级顺序的第二多个分段。所述NAP可例如基于所述第一相对优先级顺序来确定与所述第一多个分段中的每个分段相关联的优先级。所述NAP可例如基于所述第二相对优先级顺序来确定与所述第二多个分段中的每个分段相关联的优先级。所述NAP可以确定一分段在所述第一多个分段和所述第二多个分段之间是公共的。例如,所述NAP可以确定在第一AnticipatedRequests消息和第二AnticipatedRequests消息中指示了一公共分段。该公共分段可以表示一时间窗口内的相同视频分段。所述NAP可以确定由所述第一AnticipatedRequests消息指示(例如,基于所述第一AnticipatedRequests消息)的所述公共分段的第一优先级值以及由所述第二AnticipatedRequests消息指示(例如,基于所述第二AnticipatedRequests消息)的所述公共分段的第二优先级值。所述NAP可以例如向服务器发送对所述公共分段的请求。所述NAP可以例如从所述服务器接收所述公共分段。在所述第一优先级值和所述第二优先级值相同的情况下,所述NAP可以将所述公共分段多播到所述第一视频流传输设备和所述第二视频流传输设备。在所述第一优先级值和所述第二优先级值不同的情况下,所述NAP可以将所述公共分段单播到第一视频流传输设备和第二视频流传输设备。
图17示出了由客户端发起的使用多播进行360度视频流传输的示例性工作流。例如,图17示出了DASH客户端(例如,WTRU#A和WTRU#B)、NAP和服务器之间的工作流程,以在服务器和NAP之间引入多播,以进行360度视频流传输。每个客户端可以向NAP发送AnticipatedRequests消息。该AnticipatedRequests消息可指示要请求的一些或所有潜在的图块分段和/或接收所请求的分段的截止时间。每个客户端可以经由针对每个分段请求的AcceptedAlternatives消息来通知NAP:该客户端可能愿意接受一个或多个DASH分段替代者。所述AcceptedAlternatives消息的替代分段可包括尚未接收到的一些或所有图块的分段。所述NAP可以分类出用于多播的公共共享分段(例如,在客户端之间)和/或确定用于从服务器单播的一个或多个唯一分段。所述NAP可将相应的替代分段映射到每个未决请求。基于该映射结果,NAP可从服务器一次获取相应的多播分段并可将这些分段转发到WTRU,并且可从服务器获取相应的单播分段并可单独转发到每个WTRU。
所述分类过程(例如,由NAP执行)可包括解析来自多个WTRU的AnticipatedRequests和/或AbsoluteDeadline消息。具有大致相同的接收截止时间值的公共共享分段可以被识别,并且可以被放入多播组。剩余的分段可以被放入单播组中。可以确定针对未决请求的替代响应顺序。
图18示出了用于基于图块的360度视频流传输的示例性NAP分类和映射。WTRU#A可被调度以请求一个或多个高质量图块分段(例如H1和/或H2)以及一个或多个低质量图块分段(例如L3和/或L4)。WTRU#B可以被调度以请求一个或多个高质量图块分段(例如H1、H2和/或H4)和低质量图块分段(例如L3)。WTRU#A和/或WTRU#B可以同意接受分段替代者。NAP可分类出来自两个或更多WTRU(例如WTRU#A和WTRU#B)的预期请求的列表,可识别用于多播的公共请求(例如H1、H2和/或L3),并可识别用于单播的唯一请求(例如L4和/或H4)。针对每个请求的替代分段可被确定,并且NAP可以从服务器一次获取所述多播分段(一个或多个)。当NAP从WTRU接收到分段请求和/或AcceptedAlternatives消息时,NAP可基于所述映射结果将分段替代者转发到WTRU,并通过所述DeliveredAlternative消息通知该WTRU实际递送的内容或要递送的实际内容。
每个客户端可以将一些或所有未被接收的预期图块分段放入AcceptedAlternatives中,并且服务器可以按照客户端请求来递送分段(例如,确切分段)。客户端可以将所请求的相应高质量图块的低质量表示添加到AcceptedAlternatives消息中。在图18所示的示例中,客户端#B可在AcceptedAlternatives消息中添加对应于高质量分段(例如,H4)的低质量图块分段(例如,L4)。所述NAP可获取L4作为多播分段,并可将该多播分段转发到客户端#A和#B,而不经由单播单独发送H4。
以此方式,NAP可以从服务器一次获取一些或所有图块(例如,H1、H2、L3、和/或L4),和/或可以将所获取的图块递送到WTRU#A和/或WTRU#B。
相同的策略可以应用于基于层的360度视窗适配流传输方法,其中客户端可以请求相同的基础层分段和/或不同的增强视窗分段。所述基础层分段可以是在其它增强分段之前被递送的多播分段。图19示出了用于基于层的360度视频流的示例性NAP分类和映射。如图19所示,两个或更多个WTRU可以具有相同的基础层分段(例如BL)请求以及一个或多个不同的增强层(例如E1、E2和/或E3)。NAP可以分类出用于多播获取的基础层分段,并且可以分类出用于单播获取的增强层分段。所述DeliveredAlternative消息可将实际内容通知给WTRU。
根据分段的大小、可用的网络带宽和/或客户端请求调度,客户端HTTP请求时间可以超过在AnticipatedRequests消息中用信号通知的原始估计的targetTime(目标时间)。NAP可基于在AnticipatedRequests消息中用信号通知的信息来检测和/或确定这种情况。如果NAP判定该客户端的请求将与来自其它客户端的请求不同步,则NAP可将这种不同步请求当作单播来对待。例如,NAP可以从服务器获取所述分段,并且可以将所获取的分段与其他客户端分开地转发到受影响的(例如,不同步)客户端。
NAP可在缓冲器中存储分段,该缓冲器可以是本地缓冲器(例如,NAP的本地缓冲器)。NAP可从一些或所有视频流传输设备(例如WTRU)接收一个或多个AnticipatedRequests消息。NAP可以识别来自多个客户端的对一个或多个分段(例如,共享分段)的多个请求。对于将由两个或多个WTRU共享的分段,NAP可从服务器取得该分段一次,并可将该分段存储在缓冲器(例如,NAP的本地缓冲器)中以用于将来的请求。如果没有对该分段的将来请求待决,则NAP可释放对该分段的存储。对于WTRU请求的分段,NAP可从服务器获取该分段,并可将它们转发到相应的WTRU。
图20示出了具有AnticipatedRequests和本地存储缓冲器的示例性多播设计。图20所示的示例性多播可以与图18所示的基于图块的360度视频流传输的NAP分类和映射示例相结合。基于来自两个或更多WTRU(例如WTRU#A和#B)的AnticipatedRequests消息,NAP可以确定一个或多个图块分段(例如H1、H2和/或L3)被该两个WTRU都请求了,并且一个或多个图块分段(例如L4和/或H4)可以从WTRU#A或WTRU#B请求一次。当NAP接收WTRU#A的对于分段H1的请求时,NAP可从服务器获取该H1并可将其转发到WTRU#A。NAP可被配置成为来自WTRU#B的待决请求将获取的H1存储在其本地缓冲器中(例如,请求计数器可被用于确定待决请求的数目)。可以对诸如H2和/或L3的图块执行相同的获得过程。当存储的图块分段被其他WTRU请求时,NAP可将存储的图块分段(例如,从其本地缓冲器)转发到对应的WTRU,而不用再次从服务器获取该请求的图块分段。通过配置使用本地缓冲器,WTRU可共享相同的图块且可不在大致相同的时间请求相同的图块。本文描述的基于图块的方法可以应用于基于层的视窗适配流传输。
对于基于图块的360度视频流,客户端(例如客户端WTRU)可能能够识别视窗。该客户端可以是视频流传输设备。该视频流传输设备可以配置有如本文所述的有线连接。例如,所述客户端可以从网络节点接收360度视频流。所述客户端可以基于用户正在观看的360度视频流的位置和/或与该360度视频流相关联的感兴趣区域来识别所述视窗。所述客户端可以请求一个或多个分段(例如,高质量视窗分段)。所述客户端可以基于所识别的视窗来请求一个或多个分段。所述客户端可以确定提前请求360度视频流的多个分段。例如,所述客户端可以确定请求所述360度视频流的第一视频分段和所述360度视频流的第二视频分段。所述客户端可以基于所述视窗来确定请求所述第一视频分段和所述第二视频分段。客户端可以在其它图块之前请求视窗图块分段,例如以保证该视窗图块可以在呈现截止时间之前被递送。例如,客户端可以使视窗图块分段优先于非视窗图块分段。利用使用本文所述的SAND消息的多播策略,可以推迟相应的视窗请求。
图21(a)-(c)示出了基于图块的360度视频分段递送的示例。例如,图21(a)示出了没有SAND消息的基于图块的360度视频递送。如图21(a)所示,DASH请求顺序可以由客户端发起,其中360度帧可以被划分成一个或多个图块(例如,4个图块)。每个图块可以被编码成一个或多个低质量图块(例如,L1、L2、L3和/或L4)和/或高质量图块(例如,H1、H2、H3和/或H4)。WTRU#A可以请求高质量视窗(例如H2)并且可以请求低质量的其他图片(例如L1、L3和/或L4)。WTRU#B可以请求高质量视窗(例如H4)并且可以请求低质量的其他图块(例如L1、L2和/或L3)。两个或更多WTRU(例如WTRU#A和WTRU#B)可以以相同的顺序请求图块。如果两个WTRU以相同顺序请求图块,则图块L1可使用隐式多播经由NAP而被获取。图21(b)可以是利用SAND消息的基于图块的360度视频递送的示例。在图21(b)中,分段递送可被重新排序,并且可以经由多播来递送一个或多个图块(例如,图块L1和/或L3)。视窗分段(例如,H2和/或H4)可被推迟到要递送的最后分段。如果网络带宽意外下降,则图21(b)中所示的方法可能不能及时递送所述视窗图块。图21(c)示出了具有高优先级视窗分段的示例性的基于图块的360度视频递送。如图21(c)所示,所述视窗图块可先于不可见区域中的其它图块而被递送(例如,以保证视窗递送)。
所述NAP可以不从客户端的请求中识别视窗分段,这可发生在例如当客户端可以请求具有相同质量的多个图块时(例如,由于带宽条件)。SAND消息指示可允许一个或多个DASH客户端向网络节点(例如,NAP)指示分段优先级。例如,客户端WTRU(例如DASH客户端)可以确定与一个或多个视频流分段相关联的优先级。客户端WTRU可以是视频流传输设备。该视频流传输设备可以配置有如本文所述的无线和/或有线连接。所述客户端WTRU可以基于与该WTRU相关联的视窗和所述视频流来确定所述优先级。例如,客户端WTRU可以确定所述视窗(例如基于客户端WTRU的朝向)。所述客户端WTRU可以基于时间偏好、质量偏好和/或相对于所述视窗的位置来确定所述优先级。例如,可以为将要在另一分段之前显示的分段确定较高优先级。可以为将要以比另一分段较高的质量显示的分段确定较高的优先级。可以为将要在视窗之内和/或在视窗附近显示的分段确定较高的优先级。所述客户端WTRU可以指示一个或多个视频流分段的优先级。所述客户端WTRU可以向网络节点(例如NAP)指示所述一个或多个视频流分段的优先级。优先级信令可以由客户端使用以向网络节点指示其(一个或多个)视窗分段。
例如,视频流传输设备(例如,客户端WTRU)可以经由AnticipatedRequests消息来指示一个或多个分段的优先级。作为示例,如表7所示,优先级参数可以被包括在AnticipatedRequests消息中。表7示出AnticipatedRequests消息的示例性优先级参数。作为另一示例,所述AnticipatedRequests消息可通过以递减的相对优先级列出所述一个或多个分段来指示该一个或多个分段的优先级。表8示出了指示分段的优先级的示例性AnticipatedRequests消息。
所述优先级参数(例如,值)可指示相关联的分段相对于相同AnticipatedRequests的其它分段的相对优先级顺序。当DASH客户端向NAP通告其感兴趣的特定分段集合时,DASH客户端可以向NAP通知每个分段的优先级。所述优先级值可用于用信号通知递送顺序和/或时间偏好(例如,客户端可能更喜欢在最早可能时间接收高优先级分段)或质量偏好(例如,客户端可能更喜欢接收高质量分段而不是低质量分段)、或递送偏好和质量偏好的组合。对于基于图块的视窗适配流传输,客户端可以将一些或所有图块的分段包括到AnticipatedRequests消息中,并且可以将高优先级值设置到视窗分段(一个或多个)并且将低优先级值设置到其他分段。
当所述NAP从客户端接收到所述AnticipatedRequests消息时,NAP可以预先获取高优先级视窗分段以便最小化传递延时。NAP可以将由多个客户端(例如,经由AnticipatedRequests消息)指示的一个或多个公共分段识别为具有相同优先级。例如,所述一个或多个公共分段在一时间窗口内可具有相同的优先级。所述NAP可以例如基于具有相同优先级的一个或多个公共分段来确定将该一个或多个公共分段多播到多个客户端。所述NAP可向多个客户端单播具有不同优先级的一个或多个分段。当NAP从多个客户端接收到AnticipatedRequests消息时,NAP可以选择不预先获取可能处于低优先级的最公共请求的分段,并且可以预先获取公共请求的高优先级分段,以便最小化递送延时。所述预先获取调度对于不同的应用和/或不同的实现可以是不同的。
表7:AnticipatedRequests消息的示例性优先级参数
Figure BDA0002374465280000271
作为另一示例,所述AnticipatedRequests消息可指示(例如,暗示)例如与sourceUrl相关联的每个请求的优先级。所述AnticipatedRequests消息可以指示相对优先级顺序(例如,由客户端WTRU确定)。例如,所述AnticipatedRequests消息中列出的分段可以按优先级顺序(例如,所述相对优先级顺序)而被列出。所述客户端WTRU可以基于所确定的AnticipatedRequests消息中列出的分段的优先级来确定所述相对优先级顺序。视频分段可以以递减的相对优先级而被列在所述AnticipatedRequests消息中。例如,较高优先级分段(例如,与sourceUrl相关联)可以在一个或多个较低优先级分段之前被列出。接收实体可以是网络节点,例如NAP,其可以基于所接收的列表的顺序来确定优先级。WTRU(一个或多个)可以在发送所述列表到NAP之前,确定列表的顺序(例如优先级顺序)。表8示出了暗示所述优先级的AnticipatedRequests消息的有序列表的示例。
表8:暗示优先级的AnticipatedRequests消息的示例性有序列表
Figure BDA0002374465280000281
作为另一个示例,ViewPortRequests(视窗请求)状态消息可以被用信号通知以向NAP通告它可能不久将观看哪个特定视窗分段集合。表9示出了ViewPortRequests消息的示例性数据表示。每个视窗分段可以由具有字节范围和/或要接收的绝对截止时间的sourceUrl指定。
表9:ViewPortRequests消息的示例性数据表示
Figure BDA0002374465280000291
利用这里描述的ViewportRequests SAND消息,NAP可以调度多播请求顺序,以保证最期望的视窗分段的按时递送。
当要递送替代分段而不是所请求的分段时,可以在NAP和DASH客户端之间交换AcceptedAlternatives和/或DeliveredAlternative消息。客户端可以以NAP所建议的期望顺序来请求一个或多个分段,例如以避免消息交换开销。SAND参数增强接收(PER)可被配置为从NAP向DASH客户端发送以用于360度视频流传输。
表10示出了RequestOrder PER消息的示例性参数。该RequestOrder PER消息可以允许NAP以优选的顺序(如在来自DASH客户端的消息中显式地用信号通知的)用信号发送要请求的分段集合。
表10:RequestOrder PER消息的示例性参数
Figure BDA0002374465280000292
如这里所述,NAP可以预见到在来自WTRU的AnticipatedRequests消息中用信号通知的一个或多个未决的被请求分段。基于每个分段的请求频率、大小和/或绝对接收截止时间,NAP可以分类出所请求的分段。例如,NAP可以分类出期望的被最多请求的分段、期望的被第二多请求的分段等等,直到期望的被最少请求的分段。NAP可基于所述分类和/或分析结果,经由RequestsOrder消息向每个WTRU通告期望的分段请求顺序。当WTRU遵循该期望的分段请求顺序时,可以跳过和/或绕过额外的SAND消息,例如AcceptedAlternatives和/或DeliveredAlternative。
表11示出了一示例,其中360度视频可以被分成4个图块:包括一个或多个高质量图块分段(例如,H1、H2、H3和/或H4)和一个或多个低质量图块分段(例如,L1、L2、L3和/或L4)。最频繁请求的分段可以是L4。第二最频繁请求的分段可以是H2、H3和/或L1。最不频繁请求的分段可以是H1、L2和/或L3。视窗图块H1、H2和H3的优先级可以比如本文所述的剩余图块更高(例如,在表11中被标记为*)。基于所述分类结果,服务器可以发送PER消息RequestsOrder以向每个WTRU通告如表11所示的优选请求顺序。
表11:分段分类示例
Figure BDA0002374465280000301
图22示出了SAND RequestOrder消息的示例性多播增益。如图22所示,通过使用RequestsOrder消息,更多的分段可以经由多播而被递送。
图23示出了RequestOrder消息的示例性工作流。如图23所示,服务器、NAP、和/或两个或更多WTRU可使用来自表11的示例的RequestOrder消息(一个或多个)。NAP可从一些或所有WTRU接收AnticipatedRequests消息,并可例如基于来自一些或所有WTRU的AnticipatedRequests消息(一个或多个)来识别每个WTRU的最优请求顺序。NAP可发送RequestsOrder消息以向每个WTRU指示优选的请求顺序。如果每个WTRU遵循该RequestsOrder消息以期望的顺序请求每个分段,则NAP可以从服务器获取公共共享分段(例如H2、H3、L4和/或L1)一次,并且可以将该共享分段转发到多个WTRU。可以减少SAND消息交换开销。
服务器可以将资源推送到客户端,而客户端不需要请求该资源。服务器可以假设推送资源可能是期望的。服务器推送可以减少延迟的往返行程,并且可以实现最低的延时(例如,其可以是沉浸式VR体验的优选组成部分之一)。
NAP可利用服务器推送协议来减少延时。图24示出了用于服务器推送的多播设计的示例性工作流。如图24所示,两个或更多WTRU客户端(例如WTRU#A和WTRU#B)可以请求MPD。可以利用推送策略来递送媒体分段。可响应于与所述MPD请求相关联的推送策略来推送初始化数据。当接收到所请求的MPD时,客户端可以开始利用相应的DASH分段URL和/或分段推送策略从服务器请求一个或多个视频分段。所述推送策略类型可以是但不限于“urn:mpeg:dash:fdh:2016:push-list”、“urn:mpeg:dash:fdh:2016:push-next”或“urn:mpeg:dash:fdh:2016:push-template”,以显式地用信号通知在推送事务期间要推送的分段。所述NAP可解析所述推送命令值,以分类出WTRU共享的公共请求分段和每个WTRU的唯一分段。NAP可从服务器获取公共请求分段(例如,一次)并将其存储在本地缓冲器中。基于显式地用信号通知的URLList(URL列表)或URL模板,NAP可以在推送事务期间将存储的分段推送到WTRU。对于WTRU所请求的唯一分段,WTRU可以从服务器获取作为单播的分段,并且可以立即将该唯一分段推送到相应的WTRU。
图25示出了经由服务器推送的基于图块的360度视频流传输的示例性NAP多播决策。如图25所示,NAP可以识别用于多播推送和/或单播推送的基于图块的360度视频分段。所述NAP可接收并解析带有来自两个或更多WTRU(例如WTRU#A和WTRU#B)的分段URL列表的推送命令。所述NAP可以识别要从服务器一次获取的一个或多个公共共享分段(例如,H1、H2和/或L3),并且可以将该公共共享分段存储在本地缓冲器(例如,NAP中的缓冲器)中,直到没有更多的将来请求待决。NAP可基于在所述推送命令中用信号通知的URL列表和/或URL模板而将一个或多个公共共享分段从所述本地缓冲器推送到每个WTRU。
图26示出了经由服务器推送的基于层的360度视频流传输的示例性NAP多播决策。如图26所示,NAP可以识别用于从服务器多播和/或单播获取的基于层的360度视频分段。NAP可接收并解析带有来自两个或更多WTRU(例如WTRU#A和WTRU#B)的分段URL列表的推送命令。所述NAP可识别用于隐式多播获取的一个或多个公共共享基础层分段(例如BL),并且可识别用于单播获取的每个WTRU的一个或多个单独的增强层分段(例如用于WTRU#A的E1和E2以及用于WTRU#B的E3)。NAP可以从服务器一次获取一个或多个公共共享BL分段,并且可以将一个或多个BL分段存储在本地缓冲器(例如,NAP的本地缓冲器)中。所述NAP可基于WTRU显式发信号通知的URL列表和/或URL模板而将BL分段从所述本地缓冲器推送到每个WTRU。
NAP可本地存储分段。服务器推送规范可以指定客户端可以使用一推送类型(例如,urn:mpeg:dash:fdh:2016:push-list、urn:mpeg:dash:fdh:2016:push-next、和/或urn:mpeg:dash:fdh:2016:push-template)来显式地用信号通知在推送事务期间要推送的分段。表12示出了由不同的推送类型用信号通知的分段推送顺序示例。
表12:分段推送顺序示例
Figure BDA0002374465280000331
所述SAND消息可允许服务器将替代分段而不是所请求的分段递送给客户端。服务器推送可被配置成类似地动作。例如,服务器可以推送可能与推送类型中用信号通知的不同的分段。服务器可以基于服务器负载、网络条件和/或特定分段的重要性中的至少一者来确定首先推送哪个分段。
PushDirective(推送命令)的格式可以被配置如下:
PUSH_DIRECTIVE=PUSH_TYPE[OWS“;”OWS QVALUE]
PUSH_TYPE=<PushType的示例可例如如表5和/或表6所提供的。>
QVALUE=<q值可被定义为:
Weight=OWS“;”OWS“q=”qvalue
qvalue=(“0”[“.”0*3DIGIT])
/(“1”[“.”0*3(“0”)])>
附加的PUSH_ORDER(推送_顺序)可以指示是否可以以如在推送类型中显式地用信号通知的确切顺序来推送分段,或者可以由NAP来确定。
ORDER=<如表13中所定义的示例性PushOrder(推送顺序)>
这里描述的具有PUSH_ORDER的PushDirective可以应用于支持DASH服务器推送的网络元件,例如边缘服务器、CDN服务器或源服务器。表13示出了PUSH_ORDER的示例性有效值。
表13:PUSH_ORDER的有效值
Figure BDA0002374465280000341
表14示出了显式PushOrder示例。客户端可以请求服务器在初始请求的分段之后推送接下来的两个分段:分段2和分段3,如PushType中所述的。例如,分段2可以在分段3之前被推送。
表14:显式PushOrder示例
Figure BDA0002374465280000342
表15示出了灵活PushOrder示例。客户端可以请求服务器在初始请求的分段之后推送接下来的两个分段:分段2和分段3,如PushType中所述。取决于服务器的条件,分段2可以在分段3之前或之后被推送。
表15:灵活PushOrder示例
Figure BDA0002374465280000351
图27示出了具有灵活推送顺序的示例性多播工作流。如图27所示,两个或多个客户端(例如WTRU#A和WTRU#B)可以将PushType发送到NAP,其中推送顺序参数被设置为“灵活”。NAP可识别将由两个或更多WTRU共享的一个或多个多播分段(例如H1、H2和/或L3)以及用于WTRU的一个或多个单播分段(例如L4和/或H4)。NAP可从服务器获取多播分段(例如,一次)并可推送到WTRU,并且可从服务器获取单播分段并可单独地推送到相应的WTRU。
图28示出了具有NAP发起的推送类型的示例性多播工作流。两个或更多客户端(例如WTRU#A和WTRU#B)可以向NAP发送PushType。NAP可被配置成用推送类型(例如,urn:mpeg:dash:fdh:2016:push-list、urn:mpeg:dash:fdh:2016:push-next、和/或urn:mpeg:dash:fdh:2016:push-template)向客户端发起推送命令,以通告要被推送到客户端的分段的顺序。当NAP从客户端接收到确认时,NAP可以从服务器获取所述分段,并且可以以在推送类型中用信号通知的顺序推送该分段。如果客户端没有确认所述推送命令,则NAP可以如最初在从客户端接收的推送类型中所发信号通知的那样来推送所述分段,或者NAP可以不确认来自客户端的推送命令。
图29A是示出了可以实施一个或多个所公开的实施例的示例性通信系统100的示图。该通信系统100可以是为多个无线用户提供语音、数据、视频、消息传递、广播等内容的多址接入系统。该通信系统100可以通过共享包括无线带宽在内的系统资源而使多个无线用户能够接入此类内容。举例来说,通信系统100可以使用一种或多种信道接入方法,例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)、零尾唯一字DFT-扩展OFDM(ZT UW DTS-s OFDM)、唯一字OFDM(UW-OFDM)、资源块过滤OFDM以及滤波器组多载波(FBMC)等等。
如图29A所示,通信系统100可以包括无线发射/接收单元(WTRU)102a、102b、102c、102d、RAN 104/113、CN 106/115、公共交换电话网络(PSTN)108、因特网110以及其他网络112,然而应该了解,所公开的实施例设想了任意数量的WTRU、基站、网络和/或网络部件。每一个WTRU 102a、102b、102c、102d可以是被配置成在无线环境中工作和/或通信的任何类型的设备。举例来说,任一WTRU 102a、102b、102c、102d都可被称为“站”和/或“STA”,其可以被配置成发射和/或接收无线信号,并且可以包括用户设备(UE)、移动站、固定或移动订户单元、基于签约的单元、寻呼机、蜂窝电话、个人数字助理(PDA)、智能电话、膝上型计算机、上网本、个人计算机、无线传感器、热点或Mi-Fi设备、物联网(IoT)设备、手表或其他可穿戴设备、头戴显示器(HMD)、车辆、无人机、医疗设备和应用(例如远程手术)、工业设备和应用(例如机器人和/或在工业和/或自动处理链环境中工作的其他无线设备)、消费类电子设备、以及在商业和/或工业无线网络上工作的设备等等。WTRU 102a、102b、102c、102d中的任意者可被可交换地称为UE。
所述通信系统100还可以包括基站114a和/或基站114b。每一个基站114a、114b可以是被配置成通过以无线方式与WTRU 102a、102b、102c、102d中的至少一个无线对接来促使其接入一个或多个通信网络(例如CN 106/115、因特网110、和/或其他网络112)的任何类型的设备。举例来说,基站114a、114b可以是基地收发信台(BTS)、节点B、e节点B、家庭节点B、家庭e节点B、gNB、NR节点B、站点控制器、接入点(AP)、以及无线路由器等等。虽然每一个基站114a、114b都被描述成了单个部件,然而应该了解。基站114a、114b可以包括任何数量的互连基站和/或网络部件。
基站114a可以是RAN 104/113的一部分,并且所述RAN还可以包括其他基站和/或网络部件(未显示),例如基站控制器(BSC)、无线电网络控制器(RNC)、中继节点等等。基站114a和/或基站114b可被配置成在名为小区(未显示)的一个或多个载波频率上发射和/或接收无线信号。这些频率可以处于授权频谱、无授权频谱或是授权与无授权频谱的组合之中。小区可以为相对固定或者有可能随时间变化的特定地理区域提供无线服务覆盖。小区可被进一步分成小区扇区。例如,与基站114a相关联的小区可被分为三个扇区。由此,在一个实施例中,基站114a可以包括三个收发信机,也就是说,每一个收发信机都对应于小区的一个扇区。在实施例中,基站114a可以使用多输入多输出(MIMO)技术,并且可以为小区的每一个扇区使用多个收发信机。举例来说,通过使用波束成形,可以在期望的空间方向上发射和/或接收信号。
基站114a、114b可以通过空中接口116来与WTRU 102a、102b、102c、102d中的一者或多者进行通信,其中所述空中接口可以是任何适当的无线通信链路(例如射频(RF)、微波、厘米波、微米波、红外线(IR)、紫外线(UV)、可见光等等)。空中接口116可以使用任何适当的无线电接入技术(RAT)来建立。
更具体地说,如上所述,通信系统100可以是多址接入系统,并且可以使用一种或多种信道接入方案,例如CDMA、TDMA、FDMA、OFDMA以及SC-FDMA等等。例如,RAN 104/113中的基站114a与WTRU 102a、102b、102c可以实施某种无线电技术,例如通用移动电信系统(UMTS)陆地无线电接入(UTRA),其中所述技术可以使用宽带CDMA(WCDMA)来建立空中接口115/116/117。WCDMA可以包括如高速分组接入(HSPA)和/或演进型HSPA(HSPA+)之类的通信协议。HSPA可以包括高速下行链路(DL)分组接入(HSDPA)和/或高速UL分组接入(HSUPA)。
在实施例中,基站114a和WTRU 102a、102b、102c可以实施某种无线电技术,例如演进型UMTS陆地无线电接入(E-UTRA),其中所述技术可以使用长期演进(LTE)和/或先进LTE(LTE-A)和/或先进LTA Pro(LTE-A Pro)来建立空中接口116。
在实施例中,基站114a和WTRU 102a、102b、102c可以实施某种无线电技术,例如NR无线电接入,其中所述无线电技术可以使用新型无线电(NR)来建立空中接口116。
在实施例中,基站114a和WTRU 102a、102b、102c可以实施多种无线电接入技术。举例来说,基站114a和WTRU 102a、102b、102c可以共同实施LTE无线电接入和NR无线电接入(例如使用双连接(DC)原理)。由此,WTRU 102a、102b、102c使用的空中接口可以通过多种类型的无线电接入技术和/或向/从多种类型的基站(例如eNB和gNB)发送的传输来表征。
在其他实施例中,基站114a和WTRU 102a、102b、102c可以实施以下的无线电技术,例如IEEE 802.11(即无线高保真(WiFi))、IEEE 802.16(全球微波接入互操作性(WiMAX))、CDMA2000、CDMA2000 1X、CDMA2000 EV-DO、临时标准2000(IS-2000)、临时标准95(IS-95)、临时标准856(IS-856)、全球移动通信系统(GSM)、用于GSM演进的增强数据速率(EDGE)以及GSM EDGE(GERAN)等等。
图29A中的基站114b可以是无线路由器、家庭节点B、家庭e节点B或接入点,并且可以使用任何适当的RAT来促成局部区域中的无线连接,例如营业场所、住宅、车辆、校园、工业设施、空中走廊(例如供无人机使用)以及道路等等。在一个实施例中,基站114b与WTRU102c、102d可以通过实施IEEE 802.11之类的无线电技术来建立无线局域网(WLAN)。在实施例中,基站114b与WTRU 102c、102d可以通过实施IEEE 802.15之类的无线电技术来建立无线个人局域网(WPAN)。在再一实施例中,基站114b和WTRU 102c、102d可通过使用基于蜂窝的RAT(例如WCDMA、CDMA2000、GSM、LTE、LTE-A、LTE-A Pro、NR等等)来建立微微小区或毫微微小区。如图29A所示,基站114b可以直连到因特网110。由此,基站114b不需要经由CN 106/115来接入因特网110。
RAN 104/113可以与CN 106/115进行通信,其中所述CN可以是被配置成向一个或多个WTRU 102a、102b、102c、102d提供语音、数据、应用和/或借助网际协议语音(VoIP)服务的任何类型的网络。该数据可以具有不同的服务质量(QoS)需求,例如不同的吞吐量需求、延时需求、容错需求、可靠性需求、数据吞吐量需求、以及移动性需求等等。CN 106/115可以提供呼叫控制、记账服务、基于移动位置的服务、预付费呼叫、因特网连接、视频分发等等,和/或可以执行用户验证之类的高级安全功能。虽然在图29A中没有显示,然而应该了解,RAN 104/113和/或CN 106/115可以直接或间接地和其他那些与RAN 104/113使用相同RAT或不同RAT的RAN进行通信。例如,除了与使用NR无线电技术的RAN 104/113相连之外,CN106/115还可以与使用GSM、UMTS、CDMA 2000、WiMAX、E-UTRA或WiFi无线电技术的别的RAN(未显示)通信。
CN 106/115还可以充当供WTRU 102a、102b、102c、102d接入PSTN 108、因特网110和/或其他网络112的网关。PSTN 108可以包括提供简易老式电话服务(POTS)的电路交换电话网络。因特网110可以包括使用了公共通信协议(例如TCP/IP网际协议族中的传输控制协议(TCP)、用户数据报协议(UDP)和/或网际协议(IP))的全球性互联计算机网络设备系统。所述网络112可以包括由其他服务供应商拥有和/或运营的有线和/或无线通信网络。例如,所述其他网络112可以包括与一个或多个RAN相连的另一个CN,其中所述一个或多个RAN可以与RAN 104/113使用相同RAT或不同RAT。
通信系统100中一些或所有WTRU 102a、102b、102c、102d可以包括多模能力(例如,WTRU 102a、102b、102c、102d可以包括在不同无线链路上与不同无线网络通信的多个收发信机)。例如,图29A所示的WTRU 102c可被配置成与可以使用基于蜂窝的无线电技术的基站114a通信,以及与可以使用IEEE 802无线电技术的基站114b通信。
图29B是示出了例示WTRU 102的系统图示。如图29B所示,WTRU 102可以包括处理器118、收发信机120、发射/接收部件122、扬声器/麦克风124、键盘126、显示器/触摸板128、不可移除存储器130、可移除存储器132、电源134、全球定位系统(GPS)芯片组136以及其他周边设备138。应该了解的是,在保持符合实施例的同时,WTRU 102还可以包括前述部件的任何子组合。
处理器118可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、其他任何类型的集成电路(IC)以及状态机等等。处理器118可以执行信号编码、数据处理、功率控制、输入/输出处理、和/或其他任何能使WTRU102在无线环境中工作的功能。处理器118可以耦合至收发信机120,收发信机120可以耦合至发射/接收部件122。虽然图29B将处理器118和收发信机120描述成单独组件,然而应该了解,处理器118和收发信机120也可以集成在一个电子组件或芯片中。
发射/接收部件122可被配置成经由空中接口116来发射或接收去往或来自基站(例如基站114a)的信号。举个例子,在一个实施例中,发射/接收部件122可以是被配置成发射和/或接收RF信号的天线。作为示例,在实施例中,发射/接收部件122可以是被配置成发射和/或接收IR、UV或可见光信号的放射器/检测器。在实施例中,发射/接收部件122可被配置成发射和/或接收RF和光信号。应该了解的是,发射/接收部件122可以被配置成发射和/或接收无线信号的任何组合。
虽然在图29B中将发射/接收部件122描述成是单个部件,但是WTRU 102可以包括任何数量的发射/接收部件122。更具体地说,WTRU 102可以使用MIMO技术。由此,在实施例中,WTRU 102可以包括两个或多个通过空中接口116来发射和接收无线电信号的发射/接收部件122(例如多个天线)。
收发信机120可被配置成对发射/接收部件122所要传送的信号进行调制,以及对发射/接收部件122接收的信号进行解调。如上所述,WTRU 102可以具有多模能力。因此,收发信机120可以包括允许WTRU 102借助多种RAT(例如NR和IEEE 802.11)来进行通信的多个收发信机。
WTRU 102的处理器118可以耦合到扬声器/麦克风124、键盘126和/或显示器/触摸板128(例如液晶显示器(LCD)显示单元或有机发光二极管(OLED)显示单元),并且可以接收来自这些部件的用户输入数据。处理器118还可以向扬声器/麦克风124、键盘126和/或显示器/触摸板128输出用户数据。此外,处理器118可以从诸如不可移除存储器130和/或可移除存储器132之类的任何适当的存储器中存取信息,以及将信息存入这些存储器。不可移除存储器130可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或是其他任何类型的记忆存储设备。可移除存储器132可以包括订户标识模块(SIM)卡、记忆棒、安全数字(SD)记忆卡等等。在其他实施例中,处理器118可以从那些并非实际位于WTRU 102的存储器存取信息,以及将数据存入这些存储器,作为示例,此类存储器可以位于服务器或家庭计算机(未显示)。
处理器118可以接收来自电源134的电力,并且可被配置分发和/或控制用于WTRU102中的其他组件的电力。电源134可以是为WTRU 102供电的任何适当设备。例如,电源134可以包括一个或多个干电池组(如镍镉(Ni-Cd)、镍锌(Ni-Zn)、镍氢(NiMH)、锂离子(Li-ion)等等)、太阳能电池以及燃料电池等等。
处理器118还可以耦合到GPS芯片组136,该芯片组可被配置成提供与WTRU 102的当前位置相关的位置信息(例如经度和纬度)。作为来自GPS芯片组136的信息的补充或替换,WTRU 102可以经由空中接口116接收来自基站(例如基站114a、114b)的位置信息,和/或根据从两个或更多个附近基站接收的信号定时来确定其位置。应该了解的是,在保持符合实施例的同时,WTRU 102可以借助任何适当的定位方法来获取位置信息。
处理器118还可以耦合到其他周边设备138,其中所述周边设备可以包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如,周边设备138可以包括加速度计、电子指南针、卫星收发信机、数码相机(用于照片和/或视频)、通用串行总线(USB)端口、振动设备、电视收发信机、免提耳机、
Figure BDA0002374465280000421
模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器、虚拟现实和/或增强现实(VR/AR)设备、以及活动跟踪器等等。周边设备138可以包括一个或多个传感器,所述传感器可以是以下的一个或多个:陀螺仪、加速度计、霍尔效应传感器、磁力计、方位传感器、邻近传感器、温度传感器、时间传感器、地理位置传感器、高度计、光传感器、触摸传感器、磁力计、气压计、手势传感器、生物测定传感器和/或湿度传感器。
WTRU 102可以包括全双工无线电设备,其中对于该无线电设备来说,一些或所有信号(例如与用于UL(例如对传输而言)和下行链路(例如对接收而言)的特定子帧相关联)的接收或传输可以是并发和/或同时的。全双工无线电设备可以包括借助于硬件(例如扼流线圈)或是凭借处理器(例如单独的处理器(未显示)或是凭借处理器118)的信号处理来减少和/或基本消除自干扰的干扰管理单元。在实施例中,WTRU 102可以包括传送和接收一些或所有信号(例如与用于UL(例如对传输而言)或下行链路(例如对接收而言)的特定子帧相关联)的半双工无线电设备。
图29C是示出了根据实施例的RAN 104和CN 106的系统图示。如上所述,RAN 104可以在空中接口116上使用E-UTRA无线电技术来与WTRU 102a、102b、102c进行通信。所述RAN104还可以与CN 106进行通信。
RAN 104可以包括e节点B160a、160b、160c,然而应该了解,在保持符合实施例的同时,RAN 104可以包括任何数量的e节点B。每一个e节点B160a、160b、160c都可以包括在空中接口116上与WTRU 102a、102b、102c通信的一个或多个收发信机。在一个实施例中,e节点B160a、160b、160c可以实施MIMO技术。由此,举例来说,e节点B160a可以使用多个天线来向WTRU 102a发射无线信号,和/或接收来自WTRU 102a的无线信号。
每一个e节点B160a、160b、160c都可以关联于一个特定小区(未显示),并且可被配置成处理无线电资源管理决策、切换决策、UL和/或DL中的用户调度等等。如图29C所示,e节点B160a、160b、160c彼此可以通过X2接口进行通信。
图29C所示的CN 106可以包括移动性管理实体(MME)162、服务网关(SGW)164以及分组数据网络(PDN)网关(或PGW)166。虽然前述的每一个部件都被描述成是CN 106的一部分,然而应该了解,这其中的任一部件都可以由CN运营商之外的实体拥有和/或运营。
MME 162可以经由S1接口连接到RAN 104中的每一个e节点B162a、162b、162c,并且可以充当控制节点。例如,MME 142可以负责验证WTRU 102a、102b、102c的用户,执行承载激活/去激活处理,以及在WTRU 102a、102b、102c的初始附着过程中选择特定的服务网关等等。MME 162还可以提供一个用于在RAN 104与使用其他无线电技术(例如GSM和/或WCDMA)的其他RAN(未显示)之间进行切换的控制平面功能。
SGW 164可以经由S1接口连接到RAN 104中的每一个e节点B160a、160b、160c。SGW164通常可以路由和转发去往/来自WTRU 102a、102b、102c的用户数据分组。并且,SGW 164还可以执行其他功能,例如在eNB间的切换过程中锚定用户平面,在DL数据可供WTRU 102a、102b、102c使用时触发寻呼处理,以及管理并存储WTRU 102a、102b、102c的上下文等等。
SGW 164可以连接到PGW 166,所述PGW可以为WTRU 102a、102b、102c提供分组交换网络(例如因特网110)接入,以便促成WTRU 102a、102b、102c与启用IP的设备之间的通信。
CN 106可以促成与其他网络的通信。例如,CN 106可以为WTRU 102a、102b、102c提供电路交换网络(例如PSTN 108)接入,以便促成WTRU 102a、102b、102c与传统的陆线通信设备之间的通信。例如,CN 106可以包括一个IP网关(例如IP多媒体子系统(IMS)服务器)或与之进行通信,并且该IP网关可以充当CN 106与PSTN 108之间的接口。此外,CN 106可以为WTRU 102a、102b、102c提供针对其他网络112的接入,其中该网络可以包括其他服务供应商拥有和/或运营的其他有线和/或无线网络。
虽然在图29A-29D中将WTRU描述成了无线终端,然而应该想到的是,在某些典型实施例中,此类终端与通信网络可以使用(例如临时或永久性)有线通信接口。
在典型实施例中,所述其他网络112可以是WLAN。
采用基础架构基本服务集(BSS)模式的WLAN可以具有用于所述BSS的接入点(AP)以及与所述AP相关联的一个或多个站(STA)。所述AP可以接入或是对接到分布式系统(DS)或是将业务送入和/或送出BSS的别的类型的有线/无线网络。源于BSS外部且去往STA的业务可以通过AP到达并被递送至STA。源自STA且去往BSS外部的目的地的业务可被发送至AP,以便递送到相应的目的地。处于BSS内部的STA之间的业务可以通过AP来发送,例如源STA可以向AP发送业务并且AP可以将业务递送至目的地STA。处于BSS内部的STA之间的业务可被认为和/或称为点到点业务。所述点到点业务可以在源与目的地STA之间(例如在其间直接)用直接链路建立(DLS)来发送。在某些典型实施例中,DLS可以使用802.11e DLS或802.11z通道化DLS(TDLS)。使用独立BSS(IBSS)模式的WLAN可不具有AP,并且处于所述IBSS内部或是使用所述IBSS的STA(例如所有STA)彼此可以直接通信。在这里,IBSS通信模式有时可被称为“自组织”通信模式。
在使用802.11ac基础设施工作模式或类似的工作模式时,AP可以在固定信道(例如主信道)上传送信标。所述主信道可以具有固定宽度(例如20MHz的带宽)或是借助信令动态设置的宽度。主信道可以是BSS的工作信道,并且可被STA用来与AP建立连接。在某些典型实施例中,所实施的可以是具有冲突避免的载波感测多址接入(CSMA/CA)(例如在802.11系统中)。对于CSMA/CA来说,包括AP在内的STA(例如每一个STA)可以感测主信道。如果特定STA感测到/检测到和/或确定主信道繁忙,那么所述特定STA可以回退。在指定的BSS中,在任何指定时间可有一个STA(例如只有一个站)进行传输。
高吞吐量(HT)STA可以使用宽度为40MHz的信道来进行通信(例如借助于将宽度为20MHz的主信道与宽度为20MHz的相邻或不相邻信道相结合来形成宽度为40MHz的信道)。
甚高吞吐量(VHT)STA可以支持宽度为20MHz、40MHz、80MHz和/或160MHz的信道。40MHz和/或80MHz信道可以通过组合连续的20MHz信道来形成。160MHz信道可以通过组合8个连续的20MHz信道或者通过组合两个不连续的80MHz信道(这种组合可被称为80+80配置)来形成。对于80+80配置来说,在信道编码之后,数据可被传递并经过一个分段解析器,所述分段解析器可以将数据非成两个流。在每一个流上可以单独执行反向快速傅里叶变换(IFFT)处理和时域处理。所述流可被映射在两个80MHz信道上,并且数据可以由执行传输的STA来传送。在执行接收的STA的接收机上,用于80+80配置的上述操作可以是相反的,并且组合数据可被发送至介质接入控制(MAC)。
802.11af和802.11ah支持1GHz以下的工作模式。与802.11n和802.11ac相比,在802.11af和802.11ah中使用信道工作带宽和载波有所缩减。802.11af在TV白空间(TVWS)频谱中支持5MHz、10MHz和20MHz带宽,并且802.11ah支持使用非TVWS频谱的1MHz、2MHz、4MHz、8MHz和16MHz带宽。根据某些典型实施例,802.11ah可以支持仪表类型控制/机器类型通信,例如宏覆盖区域中的MTC设备。MTC可以具有某种能力,例如包含了支持(例如只支持)某些和/或有限带宽在内的受限能力。MTC设备可以包括电池,并且该电池的电池寿命高于阈值(例如用于保持很长的电池寿命)。
对于可以支持多个信道和信道带宽的WLAN系统(例如,802.11n、802.11ac、802.11af以及802.11ah)来说,所述WLAN系统包括一个可被指定成主信道的信道。所述主信道的带宽可以等于BSS中的所有STA所支持的最大公共工作带宽。主信道的带宽可以由某一个STA设置和/或限制,其中所述STA源自在支持最小带宽工作模式的BSS中工作的所有STA。在关于802.11ah的示例中,即使BSS中的AP和其他STA支持2MHz、4MHz、8MHz、16MHz和/或其他信道带宽工作模式,但对支持(例如只支持)1MHz模式的STA(例如MTC类型的设备)来说,主信道的宽度可以是1MHz。载波感测和/或网络分配矢量(NAV)设置可以取决于主信道的状态。如果主信道繁忙(例如,因为STA(其仅支持1MHz工作模式)正在对AP进行传输),那么即使大多数的频带保持空闲并且可供使用,也可以认为整个可用频带繁忙。
在美国,可供802.11ah使用的可用频带是902MHz到928MHz。在韩国,可用频带是917.5MHz到923.5MHz。在日本,可用频带是916.5MHz到927.5MHz。依照国家码,可用于802.11ah的总带宽是6MHz到26MHz。
图29D是示出了根据实施例的RAN 113和CN 115的系统图示。如上所述,RAN 113可以在空中接口116上使用NR无线电技术来与WTRU 102a、102b、102c进行通信。RAN 113还可以与CN 115进行通信。
RAN 113可以包括gNB 180a、180b、180c,但是应该了解,在保持符合实施例的同时,RAN 113可以包括任何数量的gNB。每一个gNB 180a、180b、180c都可以包括一个或多个收发信机,以便通过空中接口116来与WTRU 102a、102b、102c通信。在一个实施例中,gNB180a、180b、180c可以实施MIMO技术。例如,gNB 180a、180b可以使用波束成形处理来向和/或从gNB 180a、180b、180c发射和/或接收信号。由此,举例来说,gNB 180a可以使用多个天线来向WTRU 102a发射无线信号,和/或接收来自WTRU 102a的无线信号。在实施例中,gNB180a、180b、180c可以实施载波聚合技术。例如,gNB 180a可以向WTRU 102a传送多个分量载波(未显示)。这些分量载波的一个子集可以处于无授权频谱上,而剩余分量载波则可以处于授权频谱上。在实施例中,gNB 180a、180b、180c可以实施协作多点(CoMP)技术。例如,WTRU 102a可以接收来自gNB 180a和gNB 180b(和/或gNB 180c)的协作传输。
WTRU 102a、102b、102c可以使用与可扩缩数字配置(numerology)相关联的传输来与gNB 180a、180b、180c进行通信。例如,对于不同的传输、不同的小区和/或不同的无线传输频谱部分来说,OFDM符号间隔和/或OFDM子载波间隔可以是不同的。WTRU 102a、102b、102c可以使用具有不同或可扩缩长度的子帧或传输时间间隔(TTI)(例如包含了不同数量的OFDM符号和/或持续变化的绝对时间长度)来与gNB 180a、180b、180c进行通信。
gNB 180a、180b、180c可被配置成与采用独立配置和/或非独立配置的WTRU 102a、102b、102c进行通信。在独立配置中,WTRU 102a、102b、102c可以在不接入其他RAN(例如e节点B160a、160b、160c)的情况下与gNB 180a、180b、180c进行通信。在独立配置中,WTRU102a、102b、102c可以使用gNB 180a、180b、180c中的一者或多者作为移动锚点。在独立配置中,WTRU 102a、102b、102c可以使用无授权频带中的信号来与gNB 180a、180b、180c进行通信。在非独立配置中,WTRU 102a、102b、102c会在与别的RAN(例如e节点B160a、160b、160c)进行通信/相连的同时与gNB 180a、180b、180c进行通信/相连。举例来说,WTRU 102a、102b、102c可以通过实施DC原理而以基本同时的方式与一个或多个gNB 180a、180b、180c以及一个或多个e节点B160a、160b、160c进行通信。在非独立配置中,e节点B160a、160b、160c可以充当WTRU 102a、102b、102c的移动锚点,并且gNB 180a、180b、180c可以提供附加的覆盖和/或吞吐量,以便为WTRU 102a、102b、102c提供服务。
每一个gNB 180a、180b、180c都可以关联于特定小区(未显示),并且可以被配置成处理无线电资源管理决策、切换决策、UL和/或DL中的用户调度、支持网络切片、实施双连接性、实施NR与E-UTRA之间的互通处理、路由去往用户平面功能(UPF)184a、184b的用户平面数据、以及路由去往接入和移动性管理功能(AMF)182a、182b的控制平面信息等等。如图29D所示,gNB 180a、180b、180c彼此可以通过Xn接口通信。
图29D所示的CN 115可以包括至少一个AMF 182a、182b,至少一个UPF 184a、184b,至少一个会话管理功能(SMF)183a、183b,并且有可能包括数据网络(DN)185a、185b。虽然每一个前述部件都被描述了CN 115的一部分,但是应该了解,这其中的任一部件都可以被CN运营商之外的其他实体拥有和/或运营。
AMF 182a、182b可以经由N2接口连接到RAN 113中的一者或多者gNB 180a、180b、180c,并且可以充当控制节点。例如,AMF 182a、182b可以负责验证WTRU 102a、102b、102c的用户,支持网络切片(例如处理具有不同需求的不同PDU会话),选择特定的SMF 183a、183b,管理注册区域,终止NAS信令,以及移动性管理等等。AMF 182a、182b可以使用网络切片处理,以便基于WTRU 102a、102b、102c使用的服务类型来定制为WTRU 102a、102b、102c提供的CN支持。举例来说,针对不同的使用情况,可以建立不同的网络切片,所述使用情况例如为依赖于超可靠低延时(URLLC)接入的服务、依赖于增强型大规模移动宽带(eMBB)接入的服务、和/或用于机器类型通信(MTC)接入的服务等等。AMF 162可以提供用于在RAN 113与使用其他无线电技术(例如LTE、LTE-A、LTE-A Pro和/或诸如WiFi之类的非3GPP接入技术)的其他RAN(未显示)之间切换的控制平面功能。
SMF 183a、183b可以经由N11接口连接到CN 115中的AMF 182a、182b。SMF 183a、183b还可以经由N4接口连接到CN 115中的UPF 184a、184b。SMF 183a、183b可以选择和控制UPF 184a、184b,并且可以通过UPF 184a、184b来配置业务路由。SMF 183a、183b可以执行其他功能,例如管理和分配WTRU/UE IP地址,管理PDU会话,控制策略实施和QoS,以及提供下行链路数据通知等等。PDU会话类型可以是基于IP的,不基于IP的,以及基于以太网的等等。
UPF 184a、184b可以经由N3接口连接到RAN 113中的一者或多者gNB 180a、180b、180c,这样可以为WTRU 102a、102b、102c提供对分组交换网络(例如因特网110)的接入,以便促成WTRU 102a、102b、102c与启用IP的设备之间的通信,UPF 184、184b可以执行其他功能,例如路由和转发分组、实施用户平面策略、支持多宿主PDU会话、处理用户平面QoS、缓冲下行链路分组、以及提供移动性锚定处理等等。
CN 115可以促成与其他网络的通信。例如,CN 115可以包括或者可以与充当CN115与PSTN 108之间的接口的IP网关(例如IP多媒体子系统(IMS)服务器)进行通信。此外,CN 115可以为WTRU 102a、102b、102c提供针对其他网络112的接入,这其中可以包括其他服务供应商拥有和/或运营的其他有线和/或无线网络。在一个实施例中,WTRU 102a、102b、102c可以经由对接到UPF 184a、184b的N3接口以及介于UPF 184a、184b与数据网络(DN)185a、185b之间的N6接口并通过UPF 184a、184b连接到本地DN 185a、185b。
有鉴于图29A-29D以及关于图29A-29D的相应描述,在这里对照以下的一项或多项描述的一个或多个或所有功能可以由一个或多个仿真设备(未显示)来执行:WTRU 102a-d、基站114a-b、e节点B160a-c、MME 162、SGW 164、PGW 166、gNB 180a-c、AMF 182a-b、UPF184a-b、SMF 183a-b、DN 185a-b和/或这里描述的其他任何设备(一个或多个)。这些仿真设备可以是被配置成模拟这里一个或多个或所有功能的一个或多个设备。举例来说,这些仿真设备可用于测试其他设备和/或模拟网络和/或WTRU功能。
所述仿真设备可被设计成在实验室环境和/或运营商网络环境中实施关于其他设备的一项或多项测试。例如,所述一个或多个仿真设备可以在被完全或部分作为有线和/或无线通信网络一部分实施和/或部署的同时执行一个或多个或所有功能,以便测试通信网络内部的其他设备。所述一个或多个仿真设备可以在被临时作为有线和/或无线通信网络的一部分实施/部署的同时执行一个或多个或所有功能。所述仿真设备可以直接耦合到别的设备以执行测试,和/或可以使用空中无线通信来执行测试。
所述一个或多个仿真设备可以在未被作为有线和/或无线通信网络一部分实施/部署的同时执行包括所有功能在内的一个或多个功能。例如,所述仿真设备可以在测试实验室和/或未被部署(例如测试)的有线和/或无线通信网络的测试场景中使用,以便实施关于一个或多个组件的测试。所述一个或多个仿真设备可以是测试设备。所述仿真设备可以使用直接的RF耦合和/或借助了RF电路(作为示例,该电路可以包括一个或多个天线)的无线通信来发射和/或接收数据。尽管以上以特定的组合描述了特征和元素,但是本领域的普通技术人员将理解,每个特征或元素可以单独使用或与其它特征和元素以任何组合使用。另外,本文描述的方法可以在结合在计算机可读介质中的计算机程序、软件或固件中实现,以由计算机或处理器执行。计算机可读媒体的示例包括但不限于电子信号(通过有线或无线连接传输)和计算机可读存储媒体。计算机可读存储媒体的示例包括但不限于只读存储器(ROM)、随机存取存储器(RAM)、寄存器、缓冲存储器、半导体存储器设备、磁媒体(例如内部硬盘和可移除磁盘)、磁光媒体和光学媒体(例如CD-ROM盘和数字通用盘(DVD))。与软件相关联的处理器可用于实施用于WTRU、WTRU、终端、基站、RNC或任何主计算机的射频收发信机。

Claims (20)

1.一种视频流传输设备,包括:
存储器;以及
处理器,其被配置为:
从网络节点接收360度视频流;
确定与所述视频流传输设备和所述360度视频流相关联的视窗;
基于所述视窗来确定提前请求所述360度视频流的第一分段和所述360度视频流的第二分段;
确定所述第一分段和所述第二分段的相对优先级顺序;
生成预期请求消息,该预期请求消息通过基于所确定的相对优先级顺序以递减相对优先级列出所述第一分段和所述第二分段而指示所确定的相对优先级顺序;以及
向所述网络节点发送所述预期请求消息。
2.根据权利要求1所述的视频流传输设备,其中所述相对优先级顺序是通过基于时间偏好、质量偏好或相对于所述视窗的位置中的一项或多项来确定针对所述第一分段的第一优先级和针对所述第二分段的第二优先级而确定的。
3.根据权利要求1所述的视频流传输设备,其中所述视窗是所述360度视频流的正被呈现给所述视频流传输设备的用户的空间区域。
4.根据权利要求1所述的视频流传输设备,其中所述视窗是基于所述视频流传输设备的朝向而被确定的。
5.根据权利要求1所述的视频流传输设备,其中所述360度视频流包括多个时间帧,其中所述360度视频流的每个时间帧被划分成多个图块。
6.根据权利要求5所述的视频流传输设备,其中所述第一分段是所述360度视频流的所述多个时间帧中的帧的第一图块,并且所述第二分段是所述360度视频流的所述多个时间帧中的所述帧的第二图块。
7.根据权利要求1所述的视频流传输设备,其中所述处理器还被配置为确定提前请求所述360度视频流的第三分段和所述360度视频流的第四分段,其中所确定的相对优先级顺序是针对所述第一分段、所述第二分段、所述第三分段和所述第四分段来确定的,并且其中所述预期请求消息通过基于所确定的相对优先级顺序以递减的相对优先级来列出所述第一分段、所述第二分段、所述第三分段和所述第四分段而指示所确定的相对优先级顺序。
8.根据权利要求1所述的视频流传输设备,其中所述预期请求消息通过基于所确定的相对优先级顺序以递减的相对优先级列出针对所述第一分段的第一预期请求和针对所述第二分段的第二预期请求来指示所确定的相对优先级顺序。
9.根据权利要求1所述的视频流传输设备,其中所述网络节点是网络附着点(NAP)。
10.一种与在视频流传输设备处接收360度视频流相关联的方法,所述方法包括:
从网络节点接收360度视频流;
确定与所述视频流传输设备和所述360度视频流相关联的视窗;
基于所述视窗来确定提前请求所述360度视频流的第一分段和所述360度视频流的第二分段;
确定所述第一分段和所述第二分段的相对优先级顺序;
生成预期请求消息,该预期请求消息通过基于所确定的相对优先级顺序以递减相对优先级列出所述第一分段和所述第二分段而指示所确定的相对优先级顺序;以及
向所述网络节点发送所述预期请求消息。
11.根据权利要求10所述的方法,其中所述相对优先级顺序通过基于时间偏好、质量偏好或相对于所述视窗的位置中的一者或多者来确定所述第一分段的第一优先级和所述第二分段的第二优先级而被确定。
12.根据权利要求10所述的方法,其中所述视窗是所述360度视频流的正被呈现给所述视频流传输设备的用户的空间区域。
13.根据权利要求10所述的方法,其中所述视窗是基于所述视频流传输设备的朝向来确定的。
14.根据权利要求10所述的方法,其中所述360度视频流包括多个时间帧,其中所述360度视频流的每个时间帧被划分成多个图块。
15.根据权利要求14所述的方法,其中所述第一分段是所述360度视频流的所述多个时间帧中的帧的第一图块,且所述第二分段是所述360度视频流的所述多个时间帧中的所述帧的第二图块。
16.根据权利要求10所述的方法,进一步包括确定提前请求所述360度视频流的第三分段和所述360度视频流的第四分段,其中所述所确定的相对优先级顺序是针对所述第一分段、所述第二分段、所述第三分段和所述第四分段而被确定的,且其中所述预期请求消息通过基于所述所确定的相对优先级顺序以递减相对优先级列出所述第一分段、所述第二分段、所述第三分段和所述第四分段来指示所述所确定的相对优先级顺序。
17.根据权利要求10所述的方法,其中所述预期请求消息通过基于所述所确定的相对优先级顺序以递减相对优先级列出对所述第一分段的第一预期请求和对所述第二分段的第二预期请求来指示所述所确定的相对优先级顺序。
18.一种网络节点,包括:
存储器;以及
处理器,其被配置为:
从第一视频流传输设备接收第一预期请求消息,所述第一预期请求消息指示按照第一相对优先级顺序的第一多个分段;
从第二视频流传输设备接收第二预期请求消息,所述第二预期请求消息指示按照第二相对优先级顺序的第二多个分段;
基于所述第一相对优先级顺序确定与所述第一多个分段中的每个分段相关联的优先级,并且基于所述第二相对优先级顺序确定所述第二多个分段中的每个分段相关联的优先级;
确定在所述第一预期请求消息和所述第二预期请求消息中指示了公共分段;
确定由所述第一预期请求消息指示的所述公共分段的第一优先级值和由所述第二预期请求消息指示的所述公共分段的第二优先级值;
向服务器发送对所述公共分段的请求;
从所述服务器接收所述公共分段;以及
在所述第一优先级值和所述第二优先级值相同的情况下,将所述公共分段多播至所述第一视频流传输设备和所述第二视频流传输设备。
19.根据权利要求18所述的网络节点,其中所述处理器还被配置为在所述第一优先级值和所述第二优先级值不同的情况下,将所述公共分段单播到所述第一视频流传输设备和所述第二视频流传输设备。
20.根据权利要求18所述的网络节点,其中所述公共分段表示一时间窗口内的相同视频分段。
CN201880048278.2A 2017-06-02 2018-06-01 下一代网络上的360度视频递送 Active CN110945873B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211267345.4A CN115567755A (zh) 2017-06-02 2018-06-01 下一代网络上的360度视频递送

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762514405P 2017-06-02 2017-06-02
US62/514,405 2017-06-02
PCT/US2018/035607 WO2018222996A1 (en) 2017-06-02 2018-06-01 360-degree video delivery over next generation network

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202211267345.4A Division CN115567755A (zh) 2017-06-02 2018-06-01 下一代网络上的360度视频递送

Publications (2)

Publication Number Publication Date
CN110945873A true CN110945873A (zh) 2020-03-31
CN110945873B CN110945873B (zh) 2022-11-04

Family

ID=62685218

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201880048278.2A Active CN110945873B (zh) 2017-06-02 2018-06-01 下一代网络上的360度视频递送
CN202211267345.4A Pending CN115567755A (zh) 2017-06-02 2018-06-01 下一代网络上的360度视频递送

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202211267345.4A Pending CN115567755A (zh) 2017-06-02 2018-06-01 下一代网络上的360度视频递送

Country Status (6)

Country Link
US (3) US11025993B2 (zh)
EP (2) EP3635959B1 (zh)
JP (3) JP6941694B2 (zh)
CN (2) CN110945873B (zh)
MX (1) MX2019014416A (zh)
WO (1) WO2018222996A1 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10547704B2 (en) * 2017-04-06 2020-01-28 Sony Interactive Entertainment Inc. Predictive bitrate selection for 360 video streaming
US11218711B2 (en) 2017-09-15 2022-01-04 Cable Television Laboratories, Inc. Information centric networking (ICN) media streaming
WO2019115153A1 (en) * 2017-12-12 2019-06-20 Nokia Solutions And Networks Oy Method, apparatus, system and computer readable medium to transmit data stream
CN110519652B (zh) * 2018-05-22 2021-05-18 华为软件技术有限公司 Vr视频播放方法、终端及服务器
FR3091438B1 (fr) * 2018-12-28 2021-12-31 Quortex Module elementaire d’un systeme de distribution d’un contenu audiovisuel
WO2020141248A1 (en) * 2019-01-02 2020-07-09 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding
US11805303B2 (en) * 2019-01-04 2023-10-31 Nokia Technologies Oy Method and apparatus for storage and signaling of media segment sizes and priority ranks
GB2580667A (en) * 2019-01-22 2020-07-29 Sony Corp A method, device and computer program
JP7296219B2 (ja) * 2019-03-07 2023-06-22 日本放送協会 受信装置、送信装置、及びプログラム
US11412310B2 (en) 2020-05-18 2022-08-09 Qualcomm Incorporated Performing and evaluating split rendering over 5G networks
US11503289B2 (en) * 2020-05-27 2022-11-15 Tencent America LLC Bitstream structure for viewport-based streaming with a fallback bitstream
WO2022122123A1 (en) * 2020-12-08 2022-06-16 Nokia Technologies Oy Method and apparatus for use in a data pulling operation
US11895170B2 (en) * 2021-03-09 2024-02-06 Cisco Technology, Inc. Synchronicity for virtual reality/augmented reality interactive sessions in wireless networks
CN114979089B (zh) * 2022-04-25 2023-03-24 北京邮电大学 一种实时传输全景视频的系统和方法

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1324463A (zh) * 1998-10-28 2001-11-28 国际商业机器公司 用于图象数据关键区的优先传输和显示的方法和装置
CN1722908A (zh) * 2004-04-15 2006-01-18 株式会社东芝 信息设备远程操作系统
CN102547592A (zh) * 2012-01-06 2012-07-04 电信科学技术研究院 一种数据传输方法及装置
CN102656895A (zh) * 2009-12-15 2012-09-05 夏普株式会社 内容分发系统、内容分发装置、内容重放终端及内容分发方法
US20140232819A1 (en) * 2013-02-19 2014-08-21 Tourwrist, Inc. Systems and methods for generating and sharing panoramic moments
EP2824883A1 (en) * 2013-07-12 2015-01-14 Alcatel Lucent A video client and video server for panoramic video consumption
CN104918077A (zh) * 2015-06-02 2015-09-16 北京邮电大学 一种视频传输方法、装置及系统
CN105791882A (zh) * 2016-03-22 2016-07-20 腾讯科技(深圳)有限公司 视频编码方法及装置
EP3065406A1 (en) * 2015-03-05 2016-09-07 Nokia Technologies Oy Video streaming method
CN106101610A (zh) * 2015-05-01 2016-11-09 株式会社理光 图像显示系统、信息处理设备和图像显示方法
CN106131615A (zh) * 2016-07-25 2016-11-16 北京小米移动软件有限公司 视频播放方法及装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004048546A (ja) 2002-07-15 2004-02-12 Sony Corp 情報処理装置および方法、表示装置および方法、並びにプログラム
US20160286128A1 (en) * 2002-10-01 2016-09-29 Dylan TX ZHOU Amphibious vtol super drone camera in a mobile case (phone case) with multiple aerial and aquatic flight modes for capturing panoramic virtual reality views, selfie and interactive video
EP1797723A1 (en) * 2004-10-05 2007-06-20 Vectormax Corporation A video compression system
JP5847577B2 (ja) 2008-05-07 2016-01-27 デジタル ファウンテン, インコーポレイテッド より低いレベルのパケット構造から導かれる記号識別子を用いた放送チャネル上の高品質ストリーム保護
US8751925B1 (en) * 2010-04-05 2014-06-10 Facebook, Inc. Phased generation and delivery of structured documents
US9445136B2 (en) * 2011-09-21 2016-09-13 Qualcomm Incorporated Signaling characteristics of segments for network streaming of media data
EP2665239B1 (en) * 2012-05-14 2016-08-31 Alcatel Lucent An adaptive streaming aware networks node, client and method with priority marking
KR101813770B1 (ko) * 2012-09-19 2017-12-29 인터디지탈 패튼 홀딩스, 인크 공유 액세스 시스템을 위한 방법 및 장치
US8953452B2 (en) * 2013-05-16 2015-02-10 Cisco Technology, Inc. Enhancing performance of rapid channel changes and other playback positioning changes in adaptive streaming
US10104190B2 (en) * 2013-07-12 2018-10-16 Canon Kabushiki Kaisha Adaptive data streaming method with push messages control
US9197717B2 (en) * 2013-11-27 2015-11-24 At&T Intellectual Property I, Lp Server-side scheduling for media transmissions according to client device states
US9253231B2 (en) * 2013-12-19 2016-02-02 Verizon Patent And Licensing Inc. Retrieving and caching adaptive bitrate stream segments based on network congestion
JP2016025633A (ja) 2014-07-24 2016-02-08 ソニー株式会社 情報処理装置、管理装置、情報処理方法、およびプログラム
US20160150212A1 (en) 2014-11-26 2016-05-26 Sony Corporation Live selective adaptive bandwidth
US9858706B2 (en) 2015-09-22 2018-01-02 Facebook, Inc. Systems and methods for content streaming
US10334224B2 (en) * 2016-02-19 2019-06-25 Alcacruz Inc. Systems and method for GPU based virtual reality video streaming server
US10666941B1 (en) * 2016-04-06 2020-05-26 Ambarella International Lp Low bitrate encoding of panoramic video to support live streaming over a wireless peer-to-peer connection
US11032588B2 (en) * 2016-05-16 2021-06-08 Google Llc Method and apparatus for spatial enhanced adaptive bitrate live streaming for 360 degree video playback
US11019257B2 (en) * 2016-05-19 2021-05-25 Avago Technologies International Sales Pte. Limited 360 degree video capture and playback
EP3761645A1 (en) * 2016-05-26 2021-01-06 Vid Scale, Inc. Methods and apparatus of viewport adaptive 360 degree video delivery
US11159860B2 (en) * 2016-06-08 2021-10-26 Saturn Licensing Llc Receiving device and receiving method, reproducing device and reproducing method, supply device and supply method, and program
US11677802B2 (en) * 2016-09-09 2023-06-13 Vid Scale, Inc. Methods and apparatus to reduce latency for 360-degree viewport adaptive streaming
US10542328B2 (en) * 2016-12-30 2020-01-21 Facebook, Inc. Systems and methods for providing content

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1324463A (zh) * 1998-10-28 2001-11-28 国际商业机器公司 用于图象数据关键区的优先传输和显示的方法和装置
CN1722908A (zh) * 2004-04-15 2006-01-18 株式会社东芝 信息设备远程操作系统
CN102656895A (zh) * 2009-12-15 2012-09-05 夏普株式会社 内容分发系统、内容分发装置、内容重放终端及内容分发方法
CN102547592A (zh) * 2012-01-06 2012-07-04 电信科学技术研究院 一种数据传输方法及装置
US20140232819A1 (en) * 2013-02-19 2014-08-21 Tourwrist, Inc. Systems and methods for generating and sharing panoramic moments
EP2824883A1 (en) * 2013-07-12 2015-01-14 Alcatel Lucent A video client and video server for panoramic video consumption
EP3065406A1 (en) * 2015-03-05 2016-09-07 Nokia Technologies Oy Video streaming method
CN106101610A (zh) * 2015-05-01 2016-11-09 株式会社理光 图像显示系统、信息处理设备和图像显示方法
CN104918077A (zh) * 2015-06-02 2015-09-16 北京邮电大学 一种视频传输方法、装置及系统
CN105791882A (zh) * 2016-03-22 2016-07-20 腾讯科技(深圳)有限公司 视频编码方法及装置
CN106131615A (zh) * 2016-07-25 2016-11-16 北京小米移动软件有限公司 视频播放方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
3GPP ORGANIZATIONAL PARTNERS: "3rd Generation Partnership Project; Technical Specification Group", 《3GPP》 *
IEEE-SA STANDARDS BOARD: "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: Sub 1 GHz License Exempt Operation", 《802.11AH-2016 - IEEE STANDARD FOR INFORMATION TECHNOLOGY》 *

Also Published As

Publication number Publication date
JP6941694B2 (ja) 2021-09-29
US11770594B2 (en) 2023-09-26
JP7473693B2 (ja) 2024-04-23
CN110945873B (zh) 2022-11-04
US20210321171A1 (en) 2021-10-14
CN115567755A (zh) 2023-01-03
JP2020522932A (ja) 2020-07-30
US20200137462A1 (en) 2020-04-30
JP7206341B2 (ja) 2023-01-17
EP3635959A1 (en) 2020-04-15
US20230421863A1 (en) 2023-12-28
JP2023030191A (ja) 2023-03-07
EP3635959B1 (en) 2021-08-04
WO2018222996A1 (en) 2018-12-06
JP2021185713A (ja) 2021-12-09
US11025993B2 (en) 2021-06-01
EP3896979A1 (en) 2021-10-20
MX2019014416A (es) 2020-02-05

Similar Documents

Publication Publication Date Title
CN110945873B (zh) 下一代网络上的360度视频递送
EP3939311A1 (en) Methods and apparatus for sub-picture adaptive resolution change
US11917177B2 (en) Dynamic adaptation of volumetric content component sub-bitstreams in streaming services
US20220239947A1 (en) Video-based point cloud streams
TW202205857A (zh) 用於基於視訊的點雲流的isobmff容器中的部分存取支援
US20230276053A1 (en) Adaptive streaming of geometry-based point clouds
JP2024502822A (ja) ビジュアルボリュメトリックビデオベース(v3c)及びジオメトリベース点群(g-pcc)メディアのストリーミングのためのmmtシグナリング
US20220329923A1 (en) Video-based point cloud streams
WO2024081395A1 (en) Viewport and/or region-of-interest dependent delivery of v3c data using rtp
CN116830588A (zh) 用于基于视觉体积视频(v3c)媒体和基于几何的点云(g-pcc)媒体的流式传输的mmt信令

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant