360-degree video delivery over next generation networks

Abstract

Systems, methods, and instrumentalities are disclosed for 360-degree video streaming. A video streaming device can receive a 360-degree video stream from a network node. The video streaming device can determine a viewport associated with the video streaming device and / or the 360-degree video stream. The video streaming device can determine (e.g., based on the viewport) to proactively request a first segment and a second segment of the 360-degree video stream. The video streaming device can determine a relative priority order of the first segment and the second segment. The video streaming device can generate an anticipated request message. The anticipated request message can indicate the determined relative priority order, for example, by listing the first segment and the second segment in a decreasing relative priority based on the determined relative priority order. The video streaming device can send the anticipated request message to the network node.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201880048278.2 entitled "360-degree video delivery on next-generation networks", filed on June 1, 2018, the contents of which are incorporated herein by reference in their entirety.

[0002] Cross-reference to related applications

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 514,405, filed June 2, 2017, which is incorporated herein by reference in its entirety. Technical Field

[0004] This invention relates to the generation and delivery of 360-degree video content. Background Technology

[0005] 360-degree video is a rapidly growing format in the media industry. It is made possible by the increasing availability of virtual reality (VR) devices. 360-degree video can provide viewers with a new sense of presence. However, compared to linear video (e.g., 2D or 3D), 360-degree video can present significant engineering challenges in video processing and / or delivery. Achieving a comfortable and / or immersive user experience may require high video quality and / or very low latency. The large video size of 360-degree video can be an obstacle to delivering it proportionally in a high-quality manner. Summary of the Invention

[0006] Systems, methods, and means for 360-degree video streaming are disclosed. A video streaming device (e.g., a Wireless Transmit / Receive Unit (WTRU)) can receive a 360-degree video stream from a network node. This network node may be a Network Attachment Point (NAP). The video streaming device can determine a viewport associated with the video streaming device and / or the 360-degree video stream. This viewport may be a spatial area of ​​the 360-degree video stream that is being presented to a user of the video streaming device. The viewport may be determined based on the orientation of the video streaming device. The video streaming device may (e.g., based on the viewport) determine a first segment and a second segment of the 360-degree video stream that have been requested in advance. The 360-degree video stream may include two or more time frames. Each of the time frames of the 360-degree video stream may be divided into multiple tiles. The first segment may be a first tile of a frame in one of the two or more time frames of the 360-degree video stream. The second segment can be a second tile of one of the two or more time frames of the 360-degree video stream.

[0007] The video streaming device can determine the relative priority order of the first segment and the second segment. This relative priority order can be determined, for example, by determining a first priority for the first segment and a second priority for the second segment based on time preference, quality preference, and / or position relative to the viewport. The video streaming device can generate a pre-request message. This pre-request message can indicate the determined relative priority order, for example, by listing the first and second segments in descending order of relative priority. The video streaming device can send the pre-request message to the network node.

[0008] A network node can receive a first expected request message from a first video streaming device, the first expected request message indicating a first plurality of segments in a first relative priority order. The network node can receive a second expected request message from a second video streaming device, the second expected request message indicating a second plurality of segments in a second relative priority order. The network node may be a NAP (Network Access Point). The network node can determine the priority associated with each of the first plurality of segments (e.g., based on the first relative priority order) and each of the second plurality of segments (e.g., based on the second relative priority order). The network node can identify common segments indicated by the first and second expected request messages as having the same priority. The network node can send a request for the common segment to a server. The network node can receive the common segment and can multicast the common segment to both the first and second video streaming devices. For example, the network node can determine that the common segment represents the same video segments with the same priority within a time window. The network node can determine to request the common segment from the server. The network node can unicast to the first video streaming device and the second video streaming device, indicating segments with different priorities.

[0009] The network node can determine that a segment is common between the first plurality of segments and the second plurality of segments. For example, the network node can determine that a common segment is indicated in the first expected request message and the second expected request message. This common segment may represent the same video segment within a time window. The network node can determine a first priority value of the common segment indicated by the first expected request message (e.g., based on the first expected request message) and a second priority value of the common segment indicated by the second expected request message (e.g., based on the second expected request message). The network node can, for example, send a request for the common segment to a server. The network node can, for example, receive the common segment from the server. If the first priority value and the second priority value are the same, the network node can multicast the common segment to the first video streaming device and the second video streaming device. If the first priority value and the second priority value are different, the network node can unicast the common segment to the first video streaming device and the second video streaming device. Attached Figure Description

[0010] Figure 1 An exemplary isometric projection (ERP) of a 360-degree video is shown.

[0011] Figure 2 An exemplary portion of a 360-degree video displayed on a head-mounted device (HMD) is shown.

[0012] Figure 3 An exemplary processing and delivery of 360-degree video in ERP format is shown.

[0013] Figure 4 An exemplary single-stream viewport adaptation method for processing and delivering 360-degree video is shown.

[0014] Figure 5 An exemplary tile-based viewport adaptation method for processing and delivering 360-degree video is shown.

[0015] Figure 6 An exemplary layer-based viewport adaptation method for processing and delivering 360-degree video is shown.

[0016] Figure 7 An example of the Internet Protocol (IP) unicast method is shown.

[0017] Figure 8 An example of the Information Center Networking (ICN) method is shown.

[0018] Figure 9 An exemplary Media Presentation Description (MPD) hierarchical data model is shown.

[0019] Figure 10 An exemplary workflow for video streaming using DASH server push is shown.

[0020] Figure 11 An exemplary tile-based 360-degree video Hypertext Transfer Protocol (HTTP) request is shown.

[0021] Figure 12 An exemplary layer-based 360-degree video HTTP request is shown.

[0022] Figure 13 An example tile-based 360-degree video HTTP request is shown.

[0023] Figure 14 The example shows the HTTP request time based on tiles.

[0024] Figure 15 An exemplary layer-based 360-degree video HTTP request is shown.

[0025] Figure 16 An exemplary layer-based approximation of HTTP request time is shown.

[0026] Figure 17 An exemplary workflow for client-initiated 360-degree video streaming using multicast is shown.

[0027] Figure 18 An exemplary network attachment point (NAP) classification and mapping for tile-based 360-degree video streaming is shown.

[0028] Figure 19 An exemplary NAP classification and mapping for layer-based 360-degree video streaming is shown.

[0029] Figure 20 An exemplary multicast design with AnticipatedRequests and a local storage buffer is shown.

[0030] Figure 21 (a)-(c) show examples of tile-based 360-degree video segment delivery.

[0031] Figure 22 An exemplary multicast gain is shown for server- and network-assisted HTTP dynamically adapted streaming (SAND) RequestOrder messages.

[0032] Figure 23 An exemplary workflow for the RequestOrder message is shown.

[0033] Figure 24 An exemplary workflow for a multicast design for server push is shown.

[0034] Figure 25 An exemplary NAP multicast decision is shown for tile-based 360-degree video streaming via server push.

[0035] Figure 26 An exemplary NAP multicast decision is shown for layer-based 360-degree video streaming via server push.

[0036] Figure 27 An exemplary multicast workflow with a flexible push order is shown.

[0037] Figure 28 An exemplary multicast workflow with NAP-initiated push type is shown.

[0038] Figure 29A This is a system diagram of an exemplary communication system in which one or more of the disclosed embodiments may be implemented.

[0039] Figure 29B According to the embodiments, it is possible Figure 29A The diagram shows an exemplary wireless transmit / receive unit (WTRU) used within a communication system.

[0040] Figure 29C According to the embodiments, it is possible Figure 29A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system.

[0041] Figure 29D According to the embodiments, it is possible Figure 29A The system diagram shows another exemplary RAN and another exemplary CN used within the communication system shown. Detailed Implementation

[0042] A detailed description of illustrative embodiments will now be described with reference to the accompanying drawings. Although detailed examples of possible implementations are provided in this specification, it should be noted that these details are intended to be exemplary and do not limit the scope of this application in any way.

[0043] 360-degree video can be a component of virtual reality (VR). 360-degree video can be captured and / or rendered on a sphere. Spherical video formats may not be directly deliverable using some or all available video codecs. 360-degree video (e.g., spherical video) can be compressed by projecting the spherical video onto a 2D plane using some projection method. The projected 2D video can be encoded (e.g., using some or all available video codecs). Examples of such projection methods may include equal rectangular projection (ERP).

[0044] Figure 1 An exemplary ERP for 360-degree video is shown. For example, the ERP can use one or more of the following equations to represent coordinates on a sphere. The first point P is mapped to a second point P with coordinates (u, v) on a 2D plane, as follows: Figure 1 As shown.

[0045] u=φ / (2*pi)+0.5 (1)

[0046] v=0.5–θ / (pi) (2)

[0047] Figure 2 An exemplary portion of a 360-degree video displayed on a head-mounted device (HMD) is shown. When watching a 360-degree video, a portion of the video can be presented to the user, for example, as shown... Figure 2 As shown. This portion of the video can be altered as the user views and / or zooms in on the image. This alteration can be based on feedback provided by the HMD and / or other types of user interfaces (e.g., a wireless transmit / receive unit (WTRU) or a smartphone). The entire spatial region of the 360-degree video can be referred to as the viewport. This viewport is presented to the user, either fully or partially. The viewport can have one or more qualities different from the rest of the 360-degree video.

[0048] 360-degree video represented in ERP or other projection formats can be encoded into a single-layer bitstream using certain video encoders such as H.264 and H.265. This entire encoded bitstream can be stored on a server, sent to the receiver, decoded by a decoder, and the decoded image corresponding to the current viewport can be rendered to the user. Figure 3 An example of processing and delivering 360-degree video in ERP format is shown. Figure 3 As shown, 360-degree video in ERP format can be encoded into one or more bitrate segments for streaming adaptation. Users can dynamically select specific segments based on network conditions. Regions of the decoded frames can be rendered to the user based on their orientation and / or viewport. Figure 3 The example shown can use a large amount of bandwidth to encode the entire 360-degree video in order to provide an immersive user experience when only a small portion of the video is consumed by the user.

[0049] Omnidirectional video (e.g., an entire video region) can be represented by one or more video frames that correspond to the current viewport. The current viewport can be a subset of the entire video region represented by multiple video frames. The current viewport can be viewed by a user at a given time. For example, omnidirectional video can display the current viewport (e.g., the area the user is currently viewing). Displaying a subset of the entire video (e.g., the viewport) can reduce transmission bandwidth and / or reduce decoding complexity.

[0050] In a single bitstream viewport adaptation method, 360-degree video can be encoded into a single bitstream. More bits can be allocated to specific regions (e.g., regions corresponding to the viewport) relative to other regions of the 360-degree video frame. Multiple bitstreams can be encoded for the 360-degree video, each corresponding to a specific viewport. One or more bitstreams can be encoded for the same viewport with different characteristics (e.g., different bitrates). The receiver can select a specific bitstream based on network conditions, the viewer's current or predicted orientation, and / or the viewport. The overall bitrate can be reduced, and high-quality images can be delivered over visible viewport regions while low-quality images can be delivered over other invisible regions. One or more metadata can indicate the viewport region.

[0051] Figure 4 An exemplary single-stream viewport adaptation method for processing and delivering 360-degree video is illustrated. Two or more viewports (e.g., viewport #1 and viewport #2) can be identified in the 360-degree video. More bits can be allocated to the viewport region than to the remaining area of ​​the video frame. For example, stream #1 and / or stream #2 can allocate more bits to the viewport #1 region than to the remaining area of ​​the video frame. Each stream can be encoded with a different bandwidth. For example, stream #1 can be encoded at 1 Mbps, and stream #2 can be encoded at 5 Mbps. Stream #3 and / or #4 can allocate more bits to the viewport #2 region than to the remaining area of ​​the video frame. Stream #3 can be encoded at 1 Mbps, and stream #4 can be encoded at 5 Mbps. The user can select the stream accordingly based on the user's viewing orientation and / or network bandwidth. As described herein, the user can be used by one or more of the following and / or interchangeably: WTRU, client WTRU, DASH client, streaming client, video streaming device, and / or similar device. For example, based on the user's viewing orientation and / or network bandwidth, the user can select stream #1 when viewing viewport #1 via a low bandwidth (BW) channel, and switch to stream #4 when viewing viewport #2 via a high BW channel.

[0052] Tile-based viewport adaptation methods may include dividing the source content into multiple tile sequences before encoding. A tile sequence may cover a subset of the spatial region of the complete panoramic content. Tile sequences may be encoded independently of each other into single-layer bitstreams. One or more bitstreams may be encoded from the same sub-picture sequence (e.g., for different bitrates). Each tile bitstream may be encapsulated as a track in a file and can be used for streaming. On the receiver side, the track to be streamed may be selected based on the user's orientation and / or viewport metadata. The client may receive one or more tile tracks covering the entire omnidirectional content. A higher-quality tile track may be received for the current viewport, while a lower-quality tile track may be received for the remaining and currently invisible areas. Each track may be decoded using a separate decoder.

[0053] Figure 5 An exemplary tile-based viewport adaptation method for processing and delivering 360-degree video is shown. Figure 5 As shown, a 360-degree frame can be divided into one or more tiles. Tiles can be encoded into high-quality bitstreams (e.g., H1, H2, H3, and / or H4) and / or low-quality bitstreams (e.g., L1, L2, L3, and / or L4). The receiver can select different tile bitstreams based on orientation and / or viewport metadata. For example, high-quality tiles (e.g., H1 and / or H2) can be selected for viewport regions, and low-quality tiles (e.g., L3 and / or L4) can be selected for other regions (e.g., invisible regions).

[0054] Figure 6 An exemplary layer-based viewport adaptation method for processing and delivering 360-degree video is illustrated. A base layer can be encoded using video coding methods to utilize 360-degree video (e.g., the entire 360-degree video). One or more Region of Interest (ROI) Enhancement Layers (ELs) can be encoded using scalable video coding. For example, one or more ROI ELs can be encoded using scalable video coding with inter-layer prediction. In another example, one or more ROI ELs can be encoded using scalable video coding without inter-layer prediction. For example, one or more layers at each tile location can be encoded, and each layer can have a different bitrate and / or resolution. The ROI EL can be a spatially and / or quality-scalable layer. One or more scalable efficient video-coded (SHVC) bitstreams can be encoded for different bitrates. Bitrate adaptation can be configured to be processed using one or more ELs. Figure 6 As shown, the base layer can be received and decoded. One or more ELs can be selected based on the received and / or decoded current viewing orientation.

[0055] Next-Generation Network (NGN) platforms can provide flexible routing solutions based on Information Center Networking (ICN). The NGN platform can be a hybrid of ICN and Internet Protocol (IP). For example, an NGN platform can be configured to reintroduce multicast, which can reduce bandwidth usage.

[0056] Figure 7 An exemplary IP unicast method is shown. For example... Figure 7 As shown, a server can respond to one or more WTRU requests and can deliver one or more requested contents to each WTRU separately, even if multiple WTRUs may request the same content at approximately the same time. One or more Content Delivery Networks (CDNs) can be used for popular content to reduce overall traffic. Configuring a CDN can be complex and may lead to inefficiencies associated with indirection, which may not be sustainable for emerging networks such as 5G networks.

[0057] Figure 8 An exemplary ICN method is shown. Figure 8 As shown, implicit multicast can be configured to be used when two or more WTRUs are watching the same video content at approximately the same time. The ICN can use a gateway (e.g., a Network Attachment Point (NAP)). This gateway can be configured as an access gateway from two or more clients to the network. The NAP can be configured to handle some or all protocols (e.g., IP, Transmission Control Protocol (TCP), and / or Hypertransmission Protocol (HTTP), etc.) and can provide standard gateway functionalities such as Network Address Translation (NAT), firewall, and / or dynamic IP address assignment. The ICN network can appear as a standard IP network to the WTRUs and / or peer-to-peer network, with an HTTP-to-ICN translation mechanism performed by the NAP. The NAP can resolve some or all WTRU HTTP requests to the server and can identify WTRUs requesting the same content from the server within a given time window (T) (e.g., determining WTRUs watching the same content at approximately the same time). The NAP can send a request to the server, and the system can provide implicit multicast to deliver the requested content to some or all WTRUs. The implicit multicast method described herein can reduce overall bandwidth and / or server load. For WTRUs requesting different content or the same content but exceeding a given time window (T), a unicast method can be used to deliver the content from the server to the requesting WTRU. The hybrid multicast / unicast method described herein can provide network utilization for video streaming use cases such as live streaming, video on demand, video sharing, and / or personalized VR applications through local multicast.

[0058] MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH) is an exemplary delivery format that can dynamically adapt to changing network conditions to provide end users with the best possible video experience. DASH can be built on top of the HTTP / TCP / IP stack. DASH can define manifest formats (which can be Media Presentation Descriptions (MPDs)) and / or segmented formats.

[0059] The MPD may include an Extensible Markup Language (XML) document that may include metadata for the DASH client to construct appropriate HTTP-URLs during a streaming session to adaptively access video segments (e.g., as described herein). Figure 9 An exemplary MPD hierarchical data model is illustrated. The MPD can describe a time-segment sequence, where a consistent set of encoded versions of media content components remains unchanged during a time segment. Each time segment may include one or more adaptation sets (e.g., AdaptationSet).

[0060] An AdaptationSet can represent a collection of encoded versions of one or more media content components that share one or more of the same attributes (e.g., language, media type, image aspect ratio, character, accessibility, viewpoint, and / or rating attributes). For example, a first AdaptationSet may include video components of the same multimedia content at different bitrates. A second AdaptationSet may include audio components of the same multimedia content at different bitrates (e.g., lower-quality stereo and / or higher-quality surround sound). Each AdaptationSet may include one or more Representations.

[0061] A representation can describe a deliverable coded version of one or more media components that differs from other representations in terms of bit rate, resolution, number of channels, and / or other characteristics. Each representation can include one or more segments. One or more attributes of the representation element (e.g., @id, @bandwidth, @qualityRanking, and / or @dependencyId) can be used to specify one or more attributes of the associated representation.

[0062] A segment can be a unit of data that can be retrieved using an HTTP request (e.g., the largest unit of data). A segment can have a URL (e.g., an addressable location on a server). Each segment can be downloaded using an HTTP GET or an HTTP GET with a byte range.

[0063] A DASH client can parse MPD XML documents. The DASH client can select an AdaptationSet set suitable for its environment, for example, based on information provided in the AdaptationSet element. Within the AdaptationSet, the client can select a Representation. The client can select a Representation based on the @bandwidth attribute, the client's decoding capabilities, and / or the client's rendering capabilities. The client can download the initial segments of the selected Representation. The client can access the content (e.g., by requesting the entire segment or a segment of bytes). Once rendering has begun, the client can continue consuming the media content. For example, the client can request (e.g., continuously) media segments and / or portions of media segments during the rendering. The client can play content according to the media rendering timeline. The client can switch Representations based on updated information from its environment. For example, the client can switch from a first Representation to a second Representation based on updated information from its environment. The client can play the content across time periods (e.g., two or more time periods) (e.g., continuously). When the client consumes media contained in a segment nears the end of the media announced in the representation, the media presentation can be terminated, and a new segment can begin and / or the MPD can be re-acquired.

[0064] MPD descriptor elements (which may be referred to as Descriptors) may be provided to applications to instantiate one or more descriptor elements with appropriate scheme information. Some descriptors (e.g., content protection, roles, accessibility, rating, viewpoint, frame packing, and / or UTC timing descriptors) may include the @schemeIdUri attribute to identify the relevant scheme. MPD elements may be supplemental property descriptors (e.g., SupplementalProperty) that may include metadata that can be used by DASH clients to optimize processing. The MPD element may also be a basic property descriptor (e.g., EssentialProperty) that may include metadata for processing the containing element.

[0065] Server and network-assisted DASH (SAND) can specify messages exchanged between streaming clients and network elements or between various network elements. Messages between streaming clients (e.g., DASH clients) and network elements or between various network elements (e.g., including DASH-aware network elements (DANEs)) can provide real-time operational characteristics of the network, servers, proxies, caches, CDNs, and / or DASH clients, including performance and status.

[0066] One or more of the following SAND messages can be used: AnticipatedRequests, AcceptedAlternatives, AbsoluteDeadline, and / or DeliveredAlternative.

[0067] The AnticipatedRequests message allows DASH clients to notify DANE which specific set of segments they may be interested in. The AnticipatedRequests message can signal to the DASH client which set of segments in the representation they may select and may soon request. Table 1 shows exemplary parameters for the AnticipatedRequests message.

[0068] Table 1: Example parameters of the AnticipatedRequests message

[0069]

[0070] The AcceptedAlternationes message allows a DASH client to notify the DANE (e.g., cached DANE) on the media delivery path when a DASH client requests a given DASH segment: the DASH client may be willing to accept other DASH segments as alternatives. The client may include the alternative segment if it is prepared to receive and play it.

[0071] Table 2 shows exemplary parameters for the AcceptedAlternationes message.

[0072] Table 2: Example parameters of the AcceptedAlternationes message

[0073]

[0074] The AbsoluteDeadline message allows DASH clients to indicate an absolute deadline in clock time to DANE before the requested segment needs to be fully received. Table 3 shows exemplary parameters for the AbsoluteDeadline message.

[0075] Table 3: Example parameters of the AbsoluteDeadline message

[0076]

[0077] The DeliveredAlternative message can be a response to an AcceptedAlternatives message sent by a DASH client. DANE may deliver an alternative segment instead of the requested segment. If DANE delivers an alternative segment instead of the requested segment, DANE may send a DeliveredAlternative message to the DASH client to notify that the response includes the segment alternative but not the requested segment. Table 4 shows exemplary parameters for the DeliveredAlternative message.

[0078] Table 4: Exemplary parameters of the DeliveredAlternative message

[0079]

[0080] The underlying mechanisms of MPEG-DASH over HTTP / 1.1 can be enhanced by leveraging features and / or capabilities available from recent IPs such as HTTP / 2 and / or WebSocket.

[0081] Figure 10 An exemplary workflow for video streaming using DASH server push is illustrated. Clients can utilize push policies to request MPDs and media segments. For example, by using a push policy, a client can first request the MPD and then request media segments. Initialization data can be pushed by the server in response to the push policy associated with the MPD request. After receiving the requested MPD, the client can begin requesting one or more video segments from the server using the appropriate DASH segment URL and / or segment push policy. The server can respond with the requested video segments, followed by a push loop as indicated by the segment push policy. The client can begin playing back the video after receiving a minimum amount of data. The process described herein can be repeated until the media streaming session ends.

[0082] Table 5 shows exemplary push policy types. Table 6 shows examples of which requests each PushType can be applied to.

[0083] Table 5: Examples of DASH Server Push Strategy Types

[0084]

[0085] Table 6: Examples of valid request types and parameters for each PushType

[0086]

[0087] 360-degree video can consume significant bandwidth due to its high resolution and / or high frame rate to deliver a compelling immersive experience. For use cases such as VR sharing, real-time VR streaming, and / or social VR applications, hundreds or thousands of VR users may watch the same 360-degree video while focusing on different viewports. The viewport adaptation methods described herein (e.g., tile-based or layer-based processing and delivery methods) can reduce the bandwidth consumption of one or more VR users.

[0088] The ICN-based routing method supported by the NGN platform can provide opportunities to reduce bandwidth usage for multiple VR users. For example, a shared area of ​​360-degree video can be retrieved from the server (e.g., retrieved once) and forwarded to multiple VR users. One or more unique viewport segments can be retrieved from the server and forwarded individually to their respective WTRUs. For example, when two VR users are watching the same viewport using a tile-based streaming method, the NGN can achieve multicast gain because the two users are sharing the same high-quality viewport tiles and / or the remaining low-quality tiles. Different decision-making strategies on the client side can result in each VR WTRU issuing different sequences of HTTP requests.

[0089] Figure 11 An example tile-based 360-degree video HTTP request is shown. (e.g.) Figure 11 As shown, each of two or more WTRUs (e.g., WTRU#A and WTRU#B) sharing the same viewport can send HTTP requests. User A of WTRU#A can request one or more viewport tiles (e.g., tiles H1 and / or H2) before other tiles (e.g., tiles L3 and / or L4). User B of WTRU#B can request viewport tiles (e.g., tiles H1 and / or H2) after some or all other tiles (e.g., tiles L3 and / or L4). The DASH client implementation can be configured to determine the order of viewport tiles and / or other tiles. NGN can be configured to multicast each tile to both WTRUs, for example, because these tiles are shared by the two WTRUs. Figure 11As shown, if the tile segments are not requested from the two users at approximately the same time, then the NGN can obtain each shared segment individually from the server, just as with unicast.

[0090] For layer-based methods, inter-layer prediction can be used. For example, in layer-based methods, inter-layer prediction may not be used. Figure 6 As shown, Figure 6 The EL bitstream in the middle can be from Figure 6 The BL bitstream in the video is independently decodeable. If the BL bitstream is independently decodeable, a client can selectively acquire one or more EL segments before acquiring one or more BL segments. For example, a client may selectively acquire one or more EL segments (e.g., before acquiring one or more BL segments) because the client may want to receive one or more viewports (e.g., the EL segments) first. In other examples, a client may acquire one or more BL segments first because the client may want to receive the entire 360-degree video first (e.g., before acquiring one or more EL segments). In this case, each client's HTTP requests may have a different order for the base layer segments and / or for the enhancement layer segments, such as... Figure 12 As shown. For example, Figure 12 An example layer-based 360-degree video HTTP request is shown. (e.g.) Figure 12 As shown, WTRU#B can send an HTTP request that retrieves a base layer segment (e.g., BL) before one or more enhancement layer segments (e.g., H2 and / or H1). WTRU#A can send an HTTP request that retrieves one or more enhancement layer segments (e.g., H2 and / or H1) before the base layer segment (e.g., BL).

[0091] Different viewports can be viewed by different clients. Figure 13 An example tile-based 360-degree video HTTP request is shown. (e.g.) Figure 13As shown, two or more WTRUs (e.g., WTRU#A and WTRU#B) can have the same HTTP request order, while each WTRU can view different viewports. For example, the viewport of WTRU#A may include tile #1 (e.g., H1), while the viewport of WTRU#B may include tile #3 (e.g., H3). Tile #1 and / or tile #3 (e.g., H1 and / or H3) can be streamed via unicast because tile #1 and / or tile #3 may not be shared by the two WTRUs. The NGN can be configured to retrieve the commonly shared tile #2 and / or tile #4 (e.g., L2 and / or L4) of both WTRUs from the server at one time via implicit multicast. The file size of high-quality tiles can be larger than that of low-quality tiles. Different tile sizes may offset the HTTP request time between WTRUs (e.g., Δt), such as Figure 14 As shown. Figure 14 An example of tile-based HTTP request time is shown. Figure 14 As shown, HTTP requests to tile #2 from WTRU#A and WTRU#B may exceed the multicast decision time window (T < ΔT). This decision time window (T) can be configured to increase so that T can be greater than ΔT.

[0092] Figure 15 An exemplary layer-based 360-degree video HTTP request is illustrated. For example, user A (WTRU#A) can have their viewport inside EL region #1 (e.g., H1), while user B (WTRU#B) can have their viewport across EL regions #3 and #4 (e.g., H3 and H4), as shown. Figure 15 As shown. If the two users request the base layer segment before the user requests the enhancement layer segment, then as time progresses, HTTP requests for the base layer segment may be misaligned. Figure 16 An exemplary layer-based approximation of HTTP request time is shown. For example... Figure 16 As shown, the request for the BL corresponding to frame #1 may be synchronous. The request for the BL corresponding to frame #2 may be asynchronous.

[0093] Server and network-assisted DASH (SAND) messaging and / or push policies can be configured to deliver 360-degree video via the NGN platform when multiple VR users are watching the same 360-degree video at approximately the same time.

[0094] A hybrid multicast / unicast networking architecture can be provided. For example, an entire 360-degree video can be encoded into a single layer and / or a single chunk file. This hybrid multicast / unicast networking architecture can achieve multicast gain when two or more users are watching the same 360-degree video from the same viewport at approximately the same time.

[0095] Even if WTRUs can share some of the same segments during a viewing session, the viewport-adaptive streaming method may not achieve sufficient multicast gain because client-side segment requests may be asynchronous.

[0096] MPEG-DASH over HTTP / 1.1 can be based on a client-initiated mechanism, where the client can actively retrieve media data from the server. Part 5 of the DASH standard, concerning Server and Network-Assisted DASH (SAND), introduces messages between DASH clients and network elements, or between various network elements, for efficient streaming sessions and / or efficient delivery of DASH content. SAND messages can provide signaling information about one or more real-time operational characteristics of the network, server, proxy, cache, CDN, and / or DASH client, etc. Network Connection Points (NAPs) can use one or more of the messages described herein to optimize their media delivery strategies for tile-based or layer-based 360-degree video streaming.

[0097] SAND messages can be used by NAP to identify multicast video segments in advance (e.g., assuming both the DASH client and NAP support DASH SAND). The NAP can be a DASH-aware network element (DANE).

[0098] For tile-based 360-degree video streaming, a DASH client can determine which tile segments to request in advance. The DASH client can determine the tile segments to request in advance based on its viewing orientation, which may include low-quality tiles for invisible areas and / or high-quality tiles for visible viewports. The client can use AntipictedRequests messages to notify network nodes (e.g., servers or NAPs) of some or all tile segments that will be requested soon. DASH SAND can provide a mechanism to allow the server to send one or more different segments and / or segments in a different order than the requested segments to the client. Based on the mechanism described herein, the NAP can re-align the client requests and / or multicast common shared segments to one or more client WTRUs. For example, the NAP can multicast common segments with the same priority requested by two or more clients.

[0099] For example, the NAP may receive a first AntiipatedRequests message from a first video streaming device (e.g., a DASH client). This first AntiipatedRequests message may indicate a first plurality of segments in a first relative priority order. The NAP may receive a second AntiipatedRequests message from a second video streaming device. This second AntiipatedRequests message may indicate a second plurality of segments in a second relative priority order. The NAP may, for example, determine the priority associated with each of the first plurality of segments based on the first relative priority order. The NAP may, for example, determine the priority associated with each of the second plurality of segments based on the second relative priority order. The NAP may determine that a segment is common between the first plurality of segments and the second plurality of segments. For example, the NAP may determine that a common segment is indicated in both the first and second AntiipatedRequests messages. This common segment may represent the same video segment within a time window. The NAP can determine a first priority value for the common segment indicated by the first AntipipatedRequests message (e.g., based on the first AntipipatedRequests message) and a second priority value for the common segment indicated by the second AntipipatedRequests message (e.g., based on the second AntipipatedRequests message). The NAP can, for example, send a request for the common segment to a server. The NAP can, for example, receive the common segment from the server. If the first priority value and the second priority value are the same, the NAP can multicast the common segment to both the first and second video streaming devices. If the first priority value and the second priority value are different, the NAP can unicast the common segment to both the first and second video streaming devices.

[0100] Figure 17 An exemplary workflow for 360-degree video streaming using multicast, initiated by a client, is shown. For example, Figure 17The diagram illustrates the workflow between DASH clients (e.g., WTRU#A and WTRU#B), the NAP, and the server to introduce multicast between the server and the NAP for 360-degree video streaming. Each client can send an AnticipatedRequests message to the NAP. This AnticipatedRequests message may indicate some or all potential tile segments to be requested and / or a deadline for receiving the requested segments. Each client may notify the NAP via an AcceptedAlternatives message for each segment request that the client may be willing to accept one or more DASH segment alternatives. The alternative segments in the AcceptedAlternatives message may include segments of some or all tiles that have not yet been received. The NAP may classify publicly shared segments for multicast (e.g., between clients) and / or determine one or more unique segments for unicast from the server. The NAP may map the corresponding alternative segments to each pending request. Based on this mapping result, NAP can obtain the corresponding multicast segments from the server at once and forward these segments to WTRUs, and can also obtain the corresponding unicast segments from the server and forward them individually to each WTRU.

[0101] The classification process (e.g., performed by NAP) may include parsing AnticipatedRequests and / or AbsoluteDeadline messages from multiple WTRUs. Commonly shared segments with substantially the same receive deadline value can be identified and placed into a multicast group. The remaining segments can be placed into a unicast group. Alternative response orders for pending requests can be determined.

[0102] Figure 18An exemplary NAP classification and mapping for tile-based 360-degree video streaming is illustrated. WTRU#A can be scheduled to request one or more high-quality tile segments (e.g., H1 and / or H2) and one or more low-quality tile segments (e.g., L3 and / or L4). WTRU#B can be scheduled to request one or more high-quality tile segments (e.g., H1, H2, and / or H4) and low-quality tile segments (e.g., L3). WTRU#A and / or WTRU#B can agree to accept segment substitutes. The NAP can classify a list of anticipated requests from two or more WTRUs (e.g., WTRU#A and WTRU#B), identify common requests for multicast (e.g., H1, H2, and / or L3), and identify unique requests for unicast (e.g., L4 and / or H4). Alternative segments for each request can be determined, and the NAP can retrieve the multicast segments (one or more) from the server at a time. When NAP receives a segmentation request and / or AcceptedAlternatives message from WTRU, NAP can forward the segmentation alternative to WTRU based on the mapping result, and notify WTRU of the actual content to be delivered or the actual content to be delivered through the DeliveredAlternative message.

[0103] Each client can add some or all of the expected tile segments that were not accepted to the `AcceptedAlternatives` message, and the server can deliver the segments (e.g., exact segments) according to the client's request. The client can also add a low-quality representation of the requested high-quality tile to the `AcceptedAlternatives` message. Figure 18 In the example shown, client #B can add a low-quality tile segment (e.g., L4) corresponding to a high-quality segment (e.g., H4) to the AcceptedAlternatives message. The NAP can acquire L4 as a multicast segment and forward it to clients #A and #B without sending H4 separately via unicast.

[0104] In this way, NAP can retrieve some or all tiles (e.g., H1, H2, L3, and / or L4) from the server at once, and / or deliver the retrieved tiles to WTRU#A and / or WTRU#B.

[0105] The same strategy can be applied to layer-based 360-degree viewport adaptation streaming methods, where clients can request the same base layer segment and / or different enhanced viewport segments. The base layer segment may be a multicast segment delivered prior to other enhanced segments. Figure 19 An exemplary NAP classification and mapping for layer-based 360-degree video streams is shown. Figure 19As shown, two or more WTRUs can have the same base layer segment (e.g., BL) request and one or more different enhancement layers (e.g., E1, E2, and / or E3). NAP can classify base layer segments for multicast acquisition and enhancement layer segments for unicast acquisition. The DeliveredAlternative message informs the WTRU of the actual content.

[0106] Depending on the segment size, available network bandwidth, and / or client request scheduling, a client's HTTP request time may exceed the original estimated targetTime (target time) signaled in the AnticipatedRequests message. NAP can detect and / or determine this situation based on the information signaled in the AnticipatedRequests message. If NAP determines that a client's request will be out of sync with requests from other clients, NAP can treat this out-of-sync request as a unicast. For example, NAP can retrieve the segment from the server and forward the retrieved segment separately to the affected (e.g., out-of-sync) clients.

[0107] NAP can store segments in a buffer, which can be a local buffer (e.g., NAP's local buffer). NAP can receive one or more AnticipatedRequests messages from some or all video streaming devices (e.g., WTRUs). NAP can identify multiple requests from multiple clients for one or more segments (e.g., shared segments). For a segment to be shared by two or more WTRUs, NAP can retrieve the segment from the server once and store it in a buffer (e.g., NAP's local buffer) for future requests. If no future requests for the segment are pending, NAP can release the storage for the segment. For segments requested by WTRUs, NAP can retrieve the segment from the server and forward them to the appropriate WTRU.

[0108] Figure 20 An exemplary multicast design with AnticipatedRequests and a local storage buffer is shown. Figure 20 The exemplary multicast shown can be used with Figure 18The illustrated example combines NAP classification and mapping for tile-based 360-degree video streaming. Based on AnticipatedRequests messages from two or more WTRUs (e.g., WTRU#A and #B), NAP can determine that one or more tile segments (e.g., H1, H2, and / or L3) have been requested by both WTRUs, and that one or more tile segments (e.g., L4 and / or H4) can be requested once from either WTRU#A or WTRU#B. When NAP receives a request for segment H1 from WTRU#A, NAP can retrieve H1 from the server and forward it to WTRU#A. NAP can be configured such that pending requests from WTRU#B store the retrieved H1 in its local buffer (e.g., a request counter can be used to determine the number of pending requests). The same retrieval process can be performed for tiles such as H2 and / or L3. When a stored tile segment is requested by another WTRU, NAP can forward the stored tile segment (e.g., from its local buffer) to the corresponding WTRU without having to retrieve the requested tile segment from the server again. By configuring the use of a local buffer, WTRUs can share the same tiles and may not request the same tiles at approximately the same time. The tile-based approach described in this paper can be applied to layer-based viewport adaptation streaming.

[0109] For tile-based 360-degree video streams, a client (e.g., a client WTRU) may be able to identify the viewport. This client can be a video streaming device. The video streaming device may be configured with a wired connection as described herein. For example, the client may receive a 360-degree video stream from a network node. The client may identify the viewport based on the location of the 360-degree video stream being viewed by the user and / or the region of interest associated with that 360-degree video stream. The client may request one or more segments (e.g., high-quality viewport segments). The client may request one or more segments based on the identified viewport. The client may determine to request multiple segments of the 360-degree video stream in advance. For example, the client may determine to request a first video segment and a second video segment of the 360-degree video stream. The client may determine to request the first video segment and the second video segment based on the viewport. The client may request viewport tile segments before other tiles, for example, to ensure that the viewport tile can be delivered before the rendering deadline. For example, a client can prioritize viewport tile segments over non-viewport tile segments. Using the multicast strategy employing the SAND messages described herein, corresponding viewport requests can be deferred.

[0110] Figure 21 (a)-(c) illustrate examples of tile-based 360-degree video segment delivery. For example, Figure 21(a) illustrates tile-based 360-degree video delivery without SAND messages. Figure 21 As shown in (a), the DASH request sequence can be initiated by the client, where a 360-degree frame can be divided into one or more tiles (e.g., 4 tiles). Each tile can be encoded into one or more low-quality tiles (e.g., L1, L2, L3, and / or L4) and / or high-quality tiles (e.g., H1, H2, H3, and / or H4). WTRU#A can request a high-quality viewport (e.g., H2) and can also request other low-quality tiles (e.g., L1, L3, and / or L4). WTRU#B can request a high-quality viewport (e.g., H4) and can also request other low-quality tiles (e.g., L1, L2, and / or L3). Two or more WTRUs (e.g., WTRU#A and WTRU#B) can request tiles in the same order. If two WTRUs request tiles in the same order, tile L1 can be obtained via NAP using implicit multicast. Figure 21 (b) could be an example of tile-based 360-degree video delivery utilizing SAND messages. Figure 21 In (b), segment delivery can be reordered, and one or more tiles (e.g., tiles L1 and / or L3) can be delivered via multicast. Viewport segments (e.g., H2 and / or H4) can be deferred to the last segment to be delivered. If network bandwidth unexpectedly decreases, Figure 21 The method shown in (b) may not deliver the viewport tile in a timely manner. Figure 21 (c) illustrates an exemplary tile-based 360-degree video delivery with high-priority viewport segmentation. For example... Figure 21 As shown in (c), the viewport tile may be delivered before other tiles in the invisible area (e.g., to ensure viewport delivery).

[0111] The NAP may not identify viewport segments from client requests, which can occur, for example, when a client can request multiple tiles of the same quality (e.g., due to bandwidth conditions). A SAND message indication allows one or more DASH clients to indicate segment priorities to a network node (e.g., the NAP). For example, a client WTRU (e.g., a DASH client) can determine priorities associated with one or more video stream segments. The client WTRU can be a video streaming device. This video streaming device can be configured with wireless and / or wired connections as described herein. The client WTRU can determine the priority based on the viewport associated with it and the video stream. For example, the client WTRU can determine the viewport (e.g., based on the client WTRU's orientation). The client WTRU can determine the priority based on time preferences, quality preferences, and / or its position relative to the viewport. For example, a higher priority can be determined for a segment that will be displayed before another segment. A higher priority can be determined for a segment that will be displayed at a higher quality than another segment. A higher priority can be determined for a segment that will be displayed within and / or near the viewport. The client-side WTRU can indicate the priority of one or more video stream segments. The client-side WTRU can indicate the priority of the one or more video stream segments to a network node (e.g., NAP). Priority signaling can be used by the client to indicate its viewport(s) segments(s) to the network node.

[0112] For example, a video streaming device (e.g., a client WTRU) can indicate the priority of one or more segments via an AnticipatedRequests message. As an example, as shown in Table 7, a priority parameter can be included in the AnticipatedRequests message. Table 7 shows exemplary priority parameters for the AnticipatedRequests message. As another example, the AnticipatedRequests message can indicate the priority of the one or more segments by listing them in descending relative priority. Table 8 shows an exemplary AnticipatedRequests message indicating the priority of a segment.

[0113] The priority parameter (e.g., a value) indicates the relative priority order of an associated segment with respect to other segments in the same AnticipatedRequests. When a DASH client announces a specific set of segments of interest to the NAP, the DASH client can notify the NAP of the priority of each segment. The priority value can be used to signal delivery order and / or timing preferences (e.g., a client may prefer to receive high-priority segments at the earliest possible time) or quality preferences (e.g., a client may prefer to receive high-quality segments rather than low-quality segments), or a combination of delivery and quality preferences. For tile-based viewport-adaptive streaming, a client can include segments of some or all tiles in the AnticipatedRequests message, and can set high priority values ​​for viewport segments (one or more) and low priority values ​​for other segments.

[0114] When the NAP receives the AnticipatedRequests message from a client, the NAP can prefetch high-priority viewport segments to minimize delivery latency. The NAP can identify one or more common segments indicated by multiple clients (e.g., via the AnticipatedRequests message) as having the same priority. For example, the one or more common segments may have the same priority within a time window. The NAP can determine to multicast one or more common segments to multiple clients, for example, based on one or more common segments with the same priority. The NAP can unicast one or more segments with different priorities to multiple clients. When the NAP receives the AnticipatedRequests message from multiple clients, the NAP may choose not to prefetch the most common request segment that might be at a low priority, and may prefetch the high-priority segments of the common requests to minimize delivery latency. This prefetching schedule may differ for different applications and / or different implementations.

[0115] Table 7: Exemplary Priority Parameters for AnticipatedRequests Messages

[0116]

[0117] As another example, the AntiipatedRequests message may indicate (e.g., imply) the priority of each request, for example, associated with the sourceUrl. The AntiipatedRequests message may indicate a relative priority order (e.g., determined by the client WTRU). For example, segments listed in the AntiipatedRequests message may be listed in priority order (e.g., the relative priority order). The client WTRU may determine the relative priority order based on the determined priorities of the segments listed in the AntiipatedRequests message. Video segments may be listed in the AntiipatedRequests message with decreasing relative priorities. For example, higher priority segments (e.g., associated with the sourceUrl) may be listed before one or more lower priority segments. The receiving entity may be a network node, such as a NAP, which may determine priorities based on the order of the received list. The WTRU(one or more) may determine the order (e.g., priority order) of the list before sending the list to the NAP. Table 8 shows an example of an ordered list of AntiipatedRequests messages implying the priorities.

[0118] Table 8: An exemplary ordered list of AnticipatedRequests messages that indicate priority

[0119]

[0120] As another example, ViewPortRequests status messages can be signaled to inform the NAP which specific set of viewport segments it may soon be viewing. Table 9 shows an exemplary data representation of the ViewPortRequests message. Each viewport segment can be specified by a sourceUrl having a byte range and / or an absolute deadline to be received.

[0121] Table 9: Exemplary Data Representation of ViewPortRequests Messages

[0122]

[0123] Using the ViewportRequests SAND message described here, NAP can schedule the order of multicast requests to ensure the timely delivery of the most desired viewport segments.

[0124] When alternative segments are to be delivered instead of the requested segments, AcceptedAlternatives and / or DeliveredAlternative messages can be exchanged between the NAP and DASH clients. Clients can request one or more segments in the desired order suggested by NAP, for example, to avoid message exchange overhead. SAND Parameter Enhanced Receive (PER) can be configured to be sent from NAP to the DASH client for 360-degree video streaming.

[0125] Table 10 shows exemplary parameters for the RequestOrder PER message. This RequestOrder PER message allows NAP to send the requested set of segments in a preferred order (as explicitly signaled in a message from the DASH client).

[0126] Table 10: Example parameters of the RequestOrder PER message

[0127]

[0128] As described here, NAP can anticipate one or more pending requested segments signaled in the AnticipatedRequests message from the WTRU. Based on the request frequency, size, and / or absolute reception deadline of each segment, NAP can categorize the requested segments. For example, NAP can categorize the most requested segments, the second most requested segments, and so on, down to the least requested segments. Based on the categorization and / or analysis results, NAP can notify each WTRU of the expected segment request order via the RequestsOrder message. When the WTRU follows this expected segment request order, additional SAND messages, such as AcceptedAlternatives and / or DeliveredAlternative, can be skipped and / or bypassed.

[0129] Table 11 illustrates an example where a 360-degree video can be divided into four tiles: one or more high-quality tile segments (e.g., H1, H2, H3, and / or H4) and one or more low-quality tile segments (e.g., L1, L2, L3, and / or L4). The most frequently requested segment may be L4. The second most frequently requested segment may be H2, H3, and / or L1. The least frequently requested segment may be H1, L2, and / or L3. The viewport tiles H1, H2, and H3 may have higher priorities than the remaining tiles described herein (e.g., marked with * in Table 11). Based on the classification results, the server may send a PER message RequestsOrder to inform each WTRU of the preferred request order as shown in Table 11.

[0130] Table 11: Examples of Segmentation and Classification

[0131]

[0132] Figure 22 An example multicast gain for the SAND RequestOrder message is shown. Figure 22 As shown, more segments can be delivered via multicast by using the RequestsOrder message.

[0133] Figure 23 An exemplary workflow for the RequestOrder message is shown. For example... Figure 23 As shown, the server, NAP, and / or two or more WTRUs can use RequestOrder messages (one or more) from the examples in Table 11. The NAP can receive AnticipatedRequests messages from some or all WTRUs and can, for example, identify the optimal request order for each WTRU based on the AnticipatedRequests messages (one or more) from some or all WTRUs. The NAP can send RequestsOrder messages to indicate the preferred request order to each WTRU. If each WTRU follows the RequestsOrder message and requests each segment in the desired order, the NAP can obtain a common shared segment (e.g., H2, H3, L4, and / or L1) from the server once and can forward that shared segment to multiple WTRUs. This can reduce SAND message exchange overhead.

[0134] The server can push resources to the client without the client needing to request them. The server can assume that pushing the resource is desirable. Server-side pushing can reduce round trips and achieve minimal latency (e.g., it can be a preferred component of immersive VR experiences).

[0135] NAP can utilize server push protocols to reduce latency. Figure 24 An exemplary workflow for a multicast design used for server push is shown. Figure 24As shown, two or more WTRU clients (e.g., WTRU#A and WTRU#B) can request MPD. Push strategies can be used to deliver media segments. Initialization data can be pushed in response to the push strategy associated with the MPD request. Upon receiving the requested MPD, the client can begin requesting one or more video segments from the server using the appropriate DASH segment URL and / or segment push strategy. The push strategy type can be, but is not limited to, “urn:mpeg:dash:fdh:2016:push-list”, “urn:mpeg:dash:fdh:2016:push-next”, or “urn:mpeg:dash:fdh:2016:push-template” to explicitly signal which segments to be pushed during a push transaction. The NAP can parse the push command value to classify common requested segments shared by WTRUs and unique segments for each WTRU. The NAP can retrieve common requested segments from the server (e.g., once) and store them in a local buffer. Based on an explicitly signaled URLList or URL template, NAP can push stored segments to WTRUs during a push transaction. For a unique segment requested by a WTRU, the WTRU can obtain the segment as a unicast from the server and immediately push that unique segment to the corresponding WTRU.

[0136] Figure 25 An exemplary NAP multicast decision is shown for tile-based 360-degree video streaming via server push. Figure 25 As shown, the NAP can identify tile-based 360-degree video segments for multicast and / or unicast pushes. The NAP can receive and parse push commands with a list of segment URLs from two or more WTRUs (e.g., WTRU#A and WTRU#B). The NAP can identify one or more common shared segments (e.g., H1, H2, and / or L3) to be retrieved from the server at a time, and can store these common shared segments in a local buffer (e.g., a buffer within the NAP) until no further future requests are pending. The NAP can push one or more common shared segments from the local buffer to each WTRU based on the list of URLs and / or URL templates signaled in the push command.

[0137] Figure 26 An exemplary NAP multicast decision is shown for layer-based 360-degree video streaming via server push. Figure 26As shown, the NAP can identify the layer-based 360-degree video segments used for obtaining from the server through multicast and / or unicast. The NAP can receive and parse a push command that includes a segment URL list from two or more WTRUs (e.g., WTRU #A and WTRU #B). The NAP can identify one or more publicly shared base layer segments (e.g., BL) for implicit multicast acquisition, and can identify one or more individual enhancement layer segments for each WTRU for unicast acquisition (e.g., E1 and E2 for WTRU #A, and E3 for WTRU #B). The NAP can acquire one or more publicly shared BL segments from the server one at a time, and can store the one or more BL segments in a local buffer (e.g., the local buffer of the NAP). The NAP can push the BL segments from the local buffer to each WTRU based on the URL list and / or URL template explicitly signaled by the WTRU.

[0138] The NAP can store segments locally. A server push specification may specify that a client can use a push type (e.g., urn:mpeg:dash:fdh:2016:push-list, urn:mpeg:dash:fdh:2016:push-next, and / or urn:mpeg:dash:fdh:2016:push-template) to explicitly signal the segments to be pushed during a push transaction. Table 12 shows an example of the segment push order signaled by different push types.

[0139] Table 12: Example of segment push order

[0140]

[0141] The SAND message may allow the server to deliver an alternative segment to the client instead of the requested segment. Server push may be configured to operate similarly. For example, the server may push a different segment than that signaled in the push type. The server may determine which segment to push first based on at least one of server load, network conditions, and / or the importance of a particular segment.

[0142] The format of the PushDirective can be configured as follows:

[0143] PUSH_DIRECTIVE = PUSH_TYPE [OWS ";" OWS QVALUE]

[0144] PUSH_TYPE = <Examples of PushType can be provided as shown in Table 5 and / or Table 6, for example.>

[0145] QVALUE = <The q value can be defined as:

[0146] Weight=OWS";"OWS"q="qvalue

[0147] qvalue=(“0”[“.”0*3DIGIT])

[0148] / (“1”[“.”0*3(“0”)])>

[0149] The additional PUSH_ORDER can indicate whether segments can be pushed in the exact order as explicitly signaled in the push type, or it can be determined by NAP.

[0150] ORDER = <Example PushOrder (push order) as defined in Table 13>

[0151] The PushDirective with PUSH_ORDER described herein can be applied to network components that support DASH server push, such as edge servers, CDN servers, or origin servers. Table 13 shows exemplary valid values ​​for PUSH_ORDER.

[0152] Table 13: Valid values ​​for PUSH_ORDER

[0153]

[0154] Table 14 shows an example of an explicit PushOrder. A client can request the server to push the next two segments after the initial requested segment: segment 2 and segment 3, as described in PushType. For example, segment 2 can be pushed before segment 3.

[0155] Table 14: Examples of Explicit PushOrder

[0156]

[0157] Table 15 illustrates a flexible PushOrder example. A client can request the server to push the next two segments after the initial requested segment: segment 2 and segment 3, as described in PushType. Depending on the server's conditions, segment 2 can be pushed before or after segment 3.

[0158] Table 15: Examples of Flexible PushOrder

[0159]

[0160] Figure 27 An exemplary multicast workflow with a flexible push order is shown. For example... Figure 27As shown, two or more clients (e.g., WTRU#A and WTRU#B) can send PushType to NAP, where the push order parameter is set to "flexible". NAP can identify one or more multicast segments (e.g., H1, H2, and / or L3) that will be shared by two or more WTRUs, and one or more unicast segments (e.g., L4 and / or H4) for WTRUs. NAP can retrieve multicast segments from the server (e.g., once) and push them to WTRUs, and can retrieve unicast segments from the server and push them individually to the respective WTRUs.

[0161] Figure 28 An exemplary multicast workflow with push types initiated by NAP is illustrated. Two or more clients (e.g., WTRU#A and WTRU#B) can send PushTypes to NAP. NAP can be configured to initiate push commands to clients with push types (e.g., urn:mpeg:dash:fdh:2016:push-list, urn:mpeg:dash:fdh:2016:push-next, and / or urn:mpeg:dash:fdh:2016:push-template) to announce the order in which segments are to be pushed to the clients. When NAP receives an acknowledgment from the client, NAP can retrieve the segments from the server and push them in the order signaled in the push type. If the client does not acknowledge the push command, NAP can push the segments as initially signaled in the push type received from the client, or NAP can choose not to acknowledge the push command from the client.

[0162] Figure 29A This diagram illustrates an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system providing voice, data, video, messaging, broadcasting, and other content to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 can use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT-Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtering OFDM, and Filter Bank Multicarrier (FBMC), etc.

[0163] like Figure 29AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, and RANs (e.g., RAN 104 or RAN 113, such as...). Figure 29D As shown), CN (e.g., CN 106 or CN 115, such as... Figure 29D (As shown), Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112; however, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, any WTRU 102a, 102b, 102c, or 102d may be referred to as a “station” and / or “STA”, and may be configured to transmit and / or receive wireless signals. It may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics, and devices operating on commercial and / or industrial wireless networks, etc. Any of WTRU 102a, 102b, 102c, or 102d may be interchangeably referred to as a UE.

[0164] The communication system 100 may further include base station 114a and / or base station 114b. Each base station 114a, 114b may be configured to enable its access to one or more communication networks (e.g., such as WTRU 102a, 102b, 102c, 102d) by wirelessly interfacing with at least one of them. Figure 29D This refers to any type of equipment (CN 115, Internet 110, and / or other network 112) shown. For example, base stations 114a and 114b can be base transceiver stations (BTS), node B, e-node B, home node B, home e-node B, gNB, NR node B, site controller, access point (AP), and wireless routers, etc. Although each base station 114a and 114b is described as a single component, it should be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network components.

[0165] Base station 114a can be RAN (e.g., RAN 104 or RAN 113, such as...). Figure 29DAs shown, the RAN may also include other base stations and / or network components (not shown), such as a Base Station Controller (BSC), Radio Network Controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies called cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, each transceiver corresponds to one sector of the cell. In embodiments, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals can be transmitted and / or received in a desired spatial direction.

[0166] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, wherein the air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0167] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, etc. For example, RAN (e.g., RAN104 or RAN 113, such as...) Figure 29D Base station 114a and WTRUs 102a, 102b, and 102c (shown) can implement a certain radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), wherein the technology can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0168] In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a certain radio technology, such as Evolved UMTS Terrestrial Radio Access (E-UTRA), wherein the technology may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTA Pro (LTE-A Pro) to establish air interface 116.

[0169] In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a certain radio technology, such as NR radio access, wherein the radio technology may use a novel radio (NR) to establish air interface 116.

[0170] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access (e.g., using the dual connectivity (DC) principle). Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0171] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement the following radio technologies, such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN), etc.

[0172] Figure 29ABase station 114b can be a wireless router, home node B, home e node B, or access point, and can use any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, residence, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), and road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless local area network (WLAN) by implementing radio technology such as IEEE 802.11. In another embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless personal area network (WPAN) by implementing radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c, 102d can establish a picocell or femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). Figure 29A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b does not need to go through a CN (e.g., CN 106 or CN 115, such as...). Figure 29D (As shown) to access the Internet 110.

[0173] RAN (e.g., RAN 104 or RAN 113, such as...) Figure 29D (As shown) can be used with CN (e.g., CN 106 or CN 115, such as Figure 29D The CN (as shown) communicates with one or more WTRUs 102a, 102b, 102c, 102d, where the CN can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services. The data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, etc. The CN (e.g., CN 106 or CN 115, as shown) Figure 29D (As shown) can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or can perform advanced security features such as user authentication. Although in Figure 29A It is not shown in the table, however it should be understood that RAN (e.g., RAN 104 or RAN 113, such as...) Figure 29D (as shown) and / or CN (e.g., CN 106 or CN 115, as shown) Figure 29D (as shown) can be directly or indirectly related to other RANs (e.g., RAN 104 or RAN 113, such as Figure 29D(As shown) RANs that communicate using the same RAT or different RATs. For example, in addition to communicating with RANs using NR radio technology (e.g., RAN 104 or RAN 113, such as...) Figure 29D In addition to the connection shown, CN (e.g., CN 106 or CN 115, such as...) Figure 29D (As shown) It can also communicate with other RANs (not shown) that use GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technologies.

[0174] CN (e.g., CN 106 or CN 115, such as...) Figure 29D (As shown) can also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). The Internet 110 may include a global interconnected computer network equipment system using common communication protocols (e.g., Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite). The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the other network 112 may include another CN connected to one or more RANs, wherein the one or more RANs may be connected to RANs (e.g., RAN 104 or RAN 113, such as...). Figure 29D (As shown) Use the same RAT or different RATs.

[0175] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links). For example... Figure 29A The WTRU 102c shown can be configured to communicate with base station 114a, which can use cellular-based radio technology, and with base station 114b, which can use IEEE 802 radio technology.

[0176] Figure 29B This is a system diagram illustrating an example of WTRU 102. (See diagram below.) Figure 29BAs shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive unit 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while remaining consistent with the embodiments, WTRU 102 may also include any sub-combination of the foregoing components.

[0177] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving unit 122. Although Figure 29B While the processor 118 and transceiver 120 are described as separate components, it should be understood that the processor 118 and transceiver 120 can also be integrated into a single electronic component or chip.

[0178] Transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in an embodiment, transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In an embodiment, transmit / receive component 122 may be configured to transmit and / or receive RF and optical signals. It should be understood that transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0179] Although Figure 29B The transmit / receive component 122 is described as a single component, but the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive radio signals via the air interface 116.

[0180] Transceiver 120 can be configured to modulate signals to be transmitted by transmitter / receiver 122 and demodulate signals received by transmitter / receiver 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers that allow WTRU 102 to communicate using various RATs (e.g., NR and IEEE 802.11).

[0181] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from these components. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 can include a subscriber identification module (SIM) card, a memory stick, a secure digital card (SD) memory card, etc. In other embodiments, the processor 118 can access and store information from memory that is not actually located in WTRU 102; for example, such memory could be located in a server or home computer (not shown).

[0182] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (such as nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, and fuel cells, etc.

[0183] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on signal timing received from two or more nearby base stations. It should be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable positioning method.

[0184] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game console modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0185] WTRU 102 may include a full-duplex wireless device, wherein the reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the wireless device. The full-duplex wireless device may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., choke coils) or by means of a processor (e.g., a separate processor (not shown) or by means of processor 118) for signal processing. In embodiments, WTRU 102 may include a half-duplex wireless device that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception).

[0186] Figure 29C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c using E-UTRA radio technology on air interface 116. RAN 104 can also communicate with CN 106.

[0187] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each eNodeB 160a, 160b, and 160c may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0188] Each eNodeB 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. For example... Figure 29C As shown, nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0189] Figure 29C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing components is described as part of the CN 106, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0190] MME 162 can connect to each eNodeB 162a, 162b, 162c in RAN 104 via the S1 interface and can act as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processes, and selecting a specific serving gateway during the initial attach process of WTRUs 102a, 102b, 102c, etc. MME 162 can also provide control plane functionality for handover between RAN 104 and other RANs (not shown) using other radio technologies (such as GSM and / or WCDMA).

[0191] The SGW 164 can connect to each eNodeB 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. Furthermore, the SGW 164 can perform other functions, such as anchoring the user plane during handover between eNBs, triggering paging processes when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0192] SGW 164 can be connected to PGW 166, which can provide packet-switched network (e.g., Internet 110) access for WTRU 102a, 102b, 102c to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0193] CN 106 can facilitate communication with other networks. For example, CN 106 can provide circuit-switched network (e.g., PSTN 108) access for WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may act as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0194] Although Figures 29A-29D The WTRU is described as a wireless terminal; however, it should be understood that in some typical embodiments, such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.

[0195] In a typical embodiment, the other network 112 may be a WLAN.

[0196] A WLAN employing an Infrastructure Basic Services Set (BSS) model may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may access or interface with a Distributed System (DS) or other type of wired / wireless network that sends services into and / or out of the BSS. Services originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Services originating from a STA and destined for an external BSS can be sent to the AP for delivery to the appropriate destination. Services between STAs within the BSS can be sent via the AP; for example, a source STA can send a service to the AP, and the AP can deliver the service to the destination STA. Services between STAs within the BSS may be considered and / or referred to as point-to-point services. Point-to-point services can be sent between the source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some typical embodiments, the DLS may use 802.11e DLS or 802.11z Channelized DLS (TDLS). A WLAN using the Independent BSS (IBSS) mode may not have an access point (AP), and STAs (STAs) within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. Here, the IBSS communication mode is sometimes referred to as a "self-organizing" communication mode.

[0197] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some typical embodiments, Carrier-Sensed Multiple Access with Collision Avoidance (CSMA / CA) can be implemented (e.g., in an 802.11 system). For CSMA / CA, STAs, including the AP (e.g., each STA), can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can fall back. Within a given BSS, at any given time, only one STA (e.g., only one station) can be transmitting.

[0198] High-throughput (HT) STAs can communicate using a 40MHz wide channel (e.g., by combining a 20MHz wide main channel with adjacent or non-adjacent 20MHz wide channels to form a 40MHz wide channel).

[0199] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is transmitted and passed through a segmented parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed individually on each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the STA performing the transmission. On the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0200] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to 802.11n and 802.11ac, the channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to some typical embodiments, 802.11ah can support instrument-type control / machine-type communication, such as MTC devices in macro coverage areas. MTCs may have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include a battery with a battery life exceeding a threshold (e.g., for maintaining a very long battery life).

[0201] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), the WLAN system includes a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a single STA, wherein the STA originates from all STAs operating in the BSS that support the minimum bandwidth operating mode. In the example of 802.11ah, even if the APs and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the width of the primary channel can be 1MHz for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the main channel is busy (e.g., because the STA (which only supports 1MHz operating mode) is transmitting to the AP), then the entire available band can be considered busy even if most of the band remains idle and available.

[0202] In the United States, the available frequency band for 802.11ah (e.g., the 802.ah-2012 standard) is 902 MHz to 928 MHz. In South Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6 MHz to 26 MHz.

[0203] Figure 29D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c using NR radio technology on air interface 116. RAN 113 can also communicate with CN 115.

[0204] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit and / or receive signals to and / or from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0205] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable digital configuration (numerology). For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0206] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in unlicensed frequency bands to communicate with gNBs 180a, 180b, and 180c. In a non-standalone configuration, WTRUs 102a, 102b, and 102c communicate / connect with gNBs 180a, 180b, and 180c simultaneously with other RANs (e.g., eNodeBs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNodeBs 160a, 160b, and 160c, by implementing DC principles. In a non-standalone configuration, eNodeBs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRUs 102a, 102b, and 102c.

[0207] Each gNB 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, implement dual connectivity, implement interoperability processing between NR and E-UTRA, route user plane data to User Plane Functions (UPF) 184a and 184b, and route control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 29D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0208] Figure 29DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include data network (DN) 185a, 185b. While each of the foregoing components is described as part of CN 115, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0209] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different needs), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, and mobility management, etc. AMF 182a and 182b can use network slicing to customize the CN support provided to WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and / or services for Machine Type Communication (MTC) access, etc. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) using other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0210] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and can configure service routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU / UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications, etc. PDU session types can be IP-based, non-IP-based, and Ethernet-based, etc.

[0211] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This provides WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring, etc.

[0212] CN 115 can facilitate communication with other networks. For example, CN 115 may include or can communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via the N3 interface connected to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and data networks (DNs) 185a and 185b.

[0213] In view of Figures 29A-29D And about Figures 29A-29D The corresponding descriptions herein refer to one or more of the functions described below, which can be performed by one or more emulation devices (not shown): WTRU 102a-d, Base Station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other devices (one or more) described herein. These emulation devices can be one or more devices configured to simulate one or more of the functions described herein. For example, these emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0214] The simulation equipment may be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, the one or more simulation devices may perform one or more functions while being implemented and / or deployed, wholly or partially, as part of a wired and / or wireless communication network, to test other devices within the communication network. The one or more simulation devices may perform one or more functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation equipment may be directly coupled to other devices to perform tests, and / or may use over-the-air wireless communication to perform tests.

[0215] The one or more simulation devices can perform one or more functions, including all functionalities, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices can be used in test laboratories and / or test scenarios where wired and / or wireless communication networks are not deployed (e.g., for testing) to perform tests on one or more components. The one or more simulation devices can be test devices. The simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (which, as an example, may include one or more antennas). Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROMs and DVDs). The processor associated with the software can be used to implement an radio frequency transceiver for a WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A video decoder device, the video decoder device comprising: Memory; as well as The processor is configured as follows: Determine the first and second segments of the video stream; A first request is determined for the first segment, the first request including a first source Uniform Resource Locator URL, a first range, and a first target time; Determine a second request for the second segment, the second request including a second source URL, a second range, and a second target time; as well as Send an expected request message to a network node, wherein the expected request message includes a first request for the first segment and a second request for the second segment, wherein the first request and the second request are ordered in descending relative priority.

2. The video decoder device of claim 1, wherein the processor is further configured to determine a first priority of the first segment and a second priority of the second segment based on one or more of time preference, quality preference, and position relative to the viewport.

3. The video decoder device of claim 1, wherein the processor is further configured to determine a viewport associated with the video stream, wherein the first segment or the second segment is associated with the viewport.

4. The video decoder device of claim 3, wherein being configured to determine the viewport associated with the video stream comprises: It is configured to determine the viewport associated with the video stream based on the orientation of the video decoder device.

5. The video decoder device of claim 1, wherein the video stream comprises at least time frames divided into one or more tiles, wherein the first segment is a first tile of a first time frame, and the second segment is a second tile of a second time frame.

6. The video decoder device according to claim 1, wherein the network node is a Network Attachment Point (NAP).

7. A method performed by a video decoder device for dynamically adapting a streaming DASH using Hypertext Transfer Protocol, the method comprising: Determine the first and second segments of the video stream; A first request is determined for the first segment, the first request including a first source Uniform Resource Locator URL, a first range, and a first target time; Determine a second request for the second segment, the second request including a second source URL, a second range, and a second target time; as well as Send an expected request message to a network node, wherein the expected request message includes a first request for the first segment and a second request for the second segment, wherein the first request and the second request are ordered in descending relative priority.

8. The method according to claim 7, wherein the method further comprises: A first priority for the first segment and a second priority for the second segment are determined based on one or more of time preference, quality preference, and position relative to the viewport.

9. The method according to claim 7, further comprising: Determine the viewport associated with the video stream, wherein the first segment or the second segment is associated with the viewport.

10. The method according to claim 9, wherein the method further comprises: The viewport associated with the video stream is determined based on the orientation of the video decoder device.

11. The method of claim 7, wherein the video stream includes time frames segmented into one or more tiles, and wherein the first segment is a first tile of a first time frame, and the second segment is a second tile of a second time frame.

12. The method of claim 7, further comprising: A third request for the third segment of the video stream is determined.

13. The method according to claim 7, wherein, The network node is a Network Attachment Point (NAP).

Images