360-degree video distribution over next-generation networks

Abstract

To provide a system, a method, and means for 360 degree video streaming.SOLUTION: A video streaming device can receive a 360-degree video stream from a network node, and 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 request in advance a first segment and a second segment of the 360-degree video stream, and determine a relative priority order for the first segment and the second segment. The video streaming device can generate an anticipated requests message, and send the anticipated requests message to the network node. The anticipated requests message can indicate the determined relative priority order, for example, by listing the first segment and the second segment by decreasing relative priority based on the determined relative priority order.SELECTED DRAWING: Figure 17

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS 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. [Background technology]

[0002] 360-degree video is a rapidly growing format that has emerged in the media industry. 360-degree video is made possible by the increasing availability of virtual reality (VR) devices. 360-degree video can provide viewers with a new sense of presence. Compared to rectilinear video (e.g., 2D or 3D), 360-degree video can present difficult engineering challenges for video processing and / or distribution. Enabling a comfortable and / or immersive user experience may require high video quality and / or extremely low latency. The large video size of 360-degree video can be an obstacle to distributing 360-degree video at scale with quality in mind. Summary of the Invention

[0003] Systems, methods, and means for 360-degree video streaming are disclosed. A video streaming device (e.g., a wireless transmit / receive unit (WTRU)) may receive a 360-degree video stream from a network node. The network node may be a network attachment point (NAP). The video streaming device may determine a viewport associated with the video streaming device and / or the 360-degree video stream. The viewport may be a spatial region of the 360-degree video stream being presented to a user of the video streaming device. The viewport may be determined based on an orientation of the video streaming device. The video streaming device may determine (e.g., based on the viewport) to pre-request a first segment of the 360-degree video stream and a second segment of the 360-degree video stream. The 360-degree video stream may include two or more temporal frames. Each of the temporal frames of the 360-degree video stream may be partitioned into multiple tiles. The first segment may be a first tile of a frame of the two or more temporal frames of the 360-degree video stream. The second segment may be a second tile of a frame of two or more time frames of the 360-degree video stream.

[0004] The video streaming device may determine a relative priority order for the first segment and the second segment. The relative priority order may be determined, for example, by determining a first priority for the first segment and a second priority for the second segment based on a time preference, a quality preference, and / or a location with respect to a viewport. The video streaming device may generate an expected request message. The expected request message may indicate the determined relative priority order, for example, by listing the first segment and the second segment in decreasing relative priority based on the determined relative priority order. The video streaming device may send the expected request message to a network node.

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

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

[0007] [Figure 1] FIG. 1 illustrates an exemplary equirectangular projection (ERP) for 360-degree video. [Figure 2] FIG. 1 illustrates an exemplary portion of a 360-degree video displayed on a head-mounted device (HMD). [Figure 3] FIG. 1 illustrates an exemplary processing and delivery of 360-degree video in ERP format. [Figure 4] FIG. 1 illustrates an exemplary single-stream viewport adaptation approach for processing and delivering 360-degree video. [Figure 5] FIG. 1 illustrates an exemplary tile-based viewport adaptation approach for processing and delivering 360-degree video. [Figure 6] FIG. 1 illustrates an exemplary layer-based viewport adaptation approach for processing and delivering 360-degree video. [Figure 7] FIG. 1 illustrates an example of an Internet Protocol (IP) unicast approach. [Figure 8] FIG. 1 illustrates an example of an information-centric networking (ICN) approach. [Figure 9] FIG. 1 illustrates an exemplary media presentation description (MPD) hierarchical data model. [Figure 10] FIG. 1 illustrates an exemplary workflow for video streaming using DASH server push. [Figure 11] FIG. 1 illustrates an exemplary tile-based 360-degree video HyperText Transfer Protocol (HTTP) request. [Figure 12] FIG. 1 illustrates an example layer-based 360-degree video HTTP request. [Figure 13] FIG. 1 illustrates an exemplary tile-based 360-degree video HTTP request. [Figure 14] FIG. 1 illustrates an example tile-based HTTP request time. [Figure 15] FIG. 1 illustrates an example layer-based 360-degree video HTTP request. [Figure 16] FIG. 1 illustrates HTTP request times for an exemplary layer-based approach. [Figure 17] FIG. 1 illustrates an example workflow for client-initiated 360-degree video streaming using multicast. [Figure 18] FIG. 1 illustrates exemplary network attachment point (NAP) sorting and mapping for tile-based 360-degree video streaming. [Figure 19] FIG. 1 illustrates exemplary NAP sorting and mapping for layer-based 360-degree video streaming. [Figure 20]FIG. 1 illustrates an exemplary multicast design using AnticipatedRequests and a local storage buffer. [Figure 21] 1A to 1C are diagrams illustrating examples of tile-based 360-degree video segment distribution. [Figure 22] FIG. 1 illustrates an exemplary multicast gain of a RequestOrder message for server and network assisted dynamic adaptive streaming over HTTP (SAND). [Figure 23] FIG. 1 illustrates an exemplary workflow of a RequestOrder message. [Figure 24] FIG. 1 illustrates an example workflow of a multicast design for server push. [Figure 25] FIG. 1 illustrates an exemplary NAP multicast decision for tile-based 360-degree video streaming via server push. [Figure 26] FIG. 1 illustrates an exemplary NAP multicast decision for layer-based 360-degree video streaming via server push. [Figure 27] FIG. 1 illustrates an exemplary multicast workflow with flexible push ordering. [Figure 28] FIG. 1 illustrates an exemplary multicast workflow using a NAP-initiated push type. [Figure 29A] FIG. 1 is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented. [Figure 29B] 29B is a system diagram of an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 29A, according to one embodiment. [Figure 29C]29B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 29A, according to one embodiment. [Figure 29D] FIG. 29B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 29A, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] A detailed description of exemplary embodiments will now be described with reference to various figures. It should be noted that while this description provides detailed examples of possible implementations, the details are intended to be illustrative and in no way limiting in scope.

[0009] 360-degree video may be a component of virtual reality (VR). 360-degree video may be captured and / or rendered on a sphere. Spherical video formats may not be directly delivered using some or all available video codecs. 360-degree video (e.g., spherical video) may be compressed by projecting the spherical video onto a 2D plane using some projection method. The projected 2D video may be coded (e.g., using some or all available video codecs). An example projection method may include equirectangular projection (ERP).

[0010] An example ERP for 360-degree video is shown in Figure 1. For example, the ERP may use one or more of the following equations to map a first point P with coordinates (θ, Φ) on a sphere to a second point P with coordinates (u, v) on a 2D plane, as shown in Figure 1: u=Φ / (2*pi)+0.5 (1) v=0.5-θ / (pi) (2)

[0011] FIG. 2 shows an example portion of a 360-degree video displayed on a head-mounted device (HMD). When viewing a 360-degree video, a user may be presented with a portion of the video, for example, as shown in FIG. 2. The portion of the video may change as the user looks around and / or zooms the image. The portion of the video may change based on feedback provided by the HMD and / or other types of user interfaces (e.g., a wireless transmit / receive unit (WTRU) or smartphone). A spatial region of the entire 360-degree video may be referred to as a viewport. The viewport may be presented completely or partially to the user. The viewport may have one or more different qualities than other portions of the 360-degree video.

[0012] 360-degree video represented in ERP or other projection formats can be encoded as a single-layer bitstream using several video encoders, such as H.264 and H.265. The entire coded bitstream can be stored on a server, transmitted to a receiver, and decoded by a decoder, and the region of the decoded picture corresponding to the current viewport can be rendered to the user. Figure 3 illustrates an example of processing and delivering 360-degree video in ERP format. As shown in Figure 3, 360-degree video in ERP format can be encoded into one or more bitrate segments for adaptive streaming. The user can dynamically select a particular segment depending on network conditions. Regions of the decoded frame can be rendered to the user based on the user's orientation and / or viewport. The example shown in Figure 3 may use a large bandwidth to encode the entire 360-degree video to provide an immersive user experience while only a small portion of the video is consumed by the user.

[0013] Omnidirectional video (e.g., the entire video area) may be represented by one or more video pictures, which may correspond to a current viewport. The current viewport may be a subset of the entire video area represented by the video picture. The current viewport may be viewed by a user at a given time. For example, the omnidirectional video may display the current viewport (e.g., the area currently being viewed by the user). Displaying a subset (e.g., a viewport) of the entire video may reduce transmission bandwidth and / or reduce decoding complexity.

[0014] In a single-bitstream viewport adaptation approach, 360-degree video can be encoded into a single bitstream. Bits can be allocated to specific regions (e.g., regions corresponding to a viewport) relative to other regions of the 360-degree video frame. Multiple bitstreams can be encoded for the 360-degree video, with each bitstream corresponding to a specific viewport. One or more bitstreams can be encoded for the same viewport with different characteristics (e.g., different bitrates). A receiver can select a specific bitstream based on network conditions, the viewer's current or predicted orientation, and / or the viewport. Overall bitrates can be reduced, and high-quality images can be delivered to visible viewport areas while lower-quality images can be delivered to other non-visible areas. One or more metadata can indicate the viewport area.

[0015] FIG. 4 illustrates an exemplary single-stream viewport adaptation approach for processing and delivering 360-degree video. Two or more viewports (e.g., viewport #1 and viewport #2) may be identified in the 360-degree video. More bits may be allocated to the viewport area than to the remaining area of the video frame. For example, stream #1 and / or stream #2 may allocate more bits to the viewport #1 area than to the remaining area of the video frame. Each stream may be coded with a different bandwidth. For example, stream #1 may be coded at 1 mbps, and stream #2 may be coded at 5 mbps. Stream #3 and / or #4 may allocate more bits to the viewport #2 area than to the remaining area of the video frame. Stream #3 may be coded at 1 mbps, and stream #4 may be coded at 5 mbps. Based on the user's viewing orientation and / or network bandwidth, the user may select the stream accordingly. A user as described herein may refer to and / or be used interchangeably with one or more of the following: WTRU, client, client WTRU, DASH client, streaming client, video streaming device, etc. For example, based on a user's viewing orientation and / or network bandwidth, a user may select Stream #1 when viewing Viewport #1 over a low bandwidth (BW) channel and switch to Stream #4 when viewing Viewport #2 over a high BW channel.

[0016] A tile-based viewport adaptation approach may involve dividing the source content into tile sequences before encoding. The tile sequences may cover a subset of the spatial area of the entire panoramic content. The tile sequences can be encoded independently of each other as a single-layer bitstream. One or more bitstreams can be encoded (e.g., for different bitrates) from the same subpicture sequence. Each tile bitstream can be encapsulated in a file as a track and made available for streaming. At the receiver side, the track to be streamed can be selected based on the user's orientation and / or viewport metadata. The client can receive one or more tile tracks covering the entire omnidirectional content. A higher-quality tile track can be received for the current viewport and a lower-quality tile track can be received for the remaining and currently non-visible areas. Each track can be decoded by a separate decoder.

[0017] FIG. 5 illustrates an exemplary tile-based viewport adaptation approach for processing and delivering 360-degree video. As shown in FIG. 5, a 360-degree frame may be partitioned into one or more tiles. The tiles may 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). A receiver may select different tile bitstreams based on orientation and / or viewport metadata. For example, high-quality tiles (e.g., H1 and / or H2) may be selected for a viewport region, and low-quality tiles (e.g., L3 and / or L4) may be selected for other regions (e.g., non-visible areas).

[0018] FIG. 6 illustrates an exemplary layer-based viewport adaptation approach for processing and delivering 360-degree video. A base layer can be coded with the 360-degree video (e.g., the entire 360-degree video) using a video encoding approach. One or more region-of-interest (ROI) enhancement layers (ELs) can be encoded with scalable video coding. For example, one or more ROI ELs can be encoded with scalable video coding with inter-layer prediction. In another example, one or more ROI ELs can be encoded with scalable video coding without inter-layer prediction. For example, one or more layers for each tile position can be coded, and each layer can have a different bitrate and / or resolution. The ROI ELs can be spatial and / or quality scalability layers. One or more scalable high-efficiency video coding (SHVC) bitstreams can be encoded for different bitrates. Bitrate adaptation can be configured to handle using one or more ELs. As shown in FIG. 6, a base layer can be received and decoded. The one or more ELs may be selected based on the current viewing orientation received and / or decoded.

[0019] Next generation network (NGN) platforms may offer flexible routing solutions based on information-centric networking (ICN). NGN platforms may be hybrids of ICN and Internet Protocol (IP). For example, NGN platforms may be configured to reintroduce multicast, which may reduce bandwidth usage.

[0020] An exemplary IP unicast approach is shown in Figure 7. As shown in Figure 7, the server may respond to one or more WTRU requests and deliver one or more requested pieces of content separately to each WTRU, even if multiple WTRUs may request the same content at approximately the same time. One or more content delivery networks (CDNs) may be used to disseminate content to reduce overall traffic. Configuring a CDN may be complex, may introduce inefficiencies related to redundancies, and may be unsustainable for new networks such as, for example, 5G networks.

[0021] FIG. 8 illustrates an exemplary ICN approach. As shown in FIG. 8, implicit multicasting may be configured to be used when two or more WTRUs are watching the same video content at approximately the same time. The ICN may use a gateway (e.g., a network attachment point (NAP)). The gateway may be configured as an access gateway from two or more customers to the network. The NAP may be configured to handle some or all protocols (e.g., IP, Transmission Control Protocol (TCP), Hyper Transport Protocol (HTTP), etc.) and may provide standard gateway functions such as network address translation (NAT), firewall, and / or dynamic IP address assignment. The ICN network may appear as a standard IP network to the WTRUs and / or as a peering network using HTTP to the ICN translation mechanism performed by the NAP. The NAP may parse some or all WTRU HTTP requests to the server and identify WTRUs requesting the same content from the server within a given time window (T) (e.g., to determine WTRUs viewing the same content at approximately the same time). The NAP can send a request to the server, and the system may provide implicit multicast to deliver the requested content to some or all WTRUs. The implicit multicast approach described herein may reduce overall bandwidth and / or server load. For WTRUs requesting different content or WTRUs requesting the same content but beyond a given time window (T), a unicast approach may be used to deliver the content from the server to the requesting WTRU. The hybrid multicast / unicast approach described herein may provide network utilization over native multicast for video streaming use cases such as live steaming, video on demand, video sharing, personal VR applications, etc.

[0022] MPEG Dynamic Adaptive HTTP Streaming (MPEG-DASH) may be an exemplary delivery format that can give end users the best possible video experience by dynamically adapting to changing network conditions. DASH may be built on top of the HTTP / TCP / IP stack. DASH may define a manifest format and / or segment format, which may be a media presentation description (MPD).

[0023] An MPD may include an Extensible Markup Language (XML) document that may contain metadata for DASH clients to construct appropriate HTTP-URLs to access video segments (e.g., as described herein) in an adaptive manner during a streaming session. Figure 9 shows an example MPD hierarchical data model. An MPD can describe a series of Periods, where a consistent set of encoded versions of media content components does not change during a Period. Each Period may include one or more Adaptation Sets (e.g., AdaptationSets).

[0024] An AdaptationSet may represent a set of encoded versions of one or more media content components that share one or more of the same properties (e.g., language, media type, picture aspect ratio, role, accessibility, viewpoint, and / or rating properties). For example, a first AdaptationSet may contain different bitrates of the video component of the same multimedia content. A second AdaptationSet may contain different bitrates of the audio component of the same multimedia content (e.g., lower quality stereo and / or higher quality surround sound). Each AdaptationSet may contain one or more Representations.

[0025] A Representation describes a distributable encoded version of one or more media components and may differ from other representations by bit rate, resolution, number of channels, and / or other characteristics. Each Representation may contain one or more segments. One or more attributes of a Representation element (e.g., @id, @bandwidth, @qualityRanking, and / or @dependencyId) may be used to specify one or more properties of the associated Representation.

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

[0027] A DASH client may parse the MPD XML document. The DASH client may select a collection of AdaptationSets suitable for its environment based on, for example, information provided in the AdaptationSet element. Within the AdaptationSet, the client may select a Representation. The client may select a Representation based on the value of the @bandwidth attribute, the client's decoding capabilities, and / or the client's rendering capabilities. The client may download an initialization segment of the selected Representation. The client may access the content (e.g., by requesting an entire segment or a byte range of a segment). Once the presentation begins, the client may continue to consume the media content. For example, the client may request media segments and / or portions of media segments during the presentation (e.g., continuously). The client may play the content according to the media presentation timeline. The client may switch Representations incorporating updated information from the client's environment. For example, the client may switch from a first Representation to a second Representation based on updated information from the client's environment. A client may play content (e.g., continuously) over a Period (e.g., two or more Periods). When a client consumes media contained in a Segment toward the end of the announced media in a Representation, the media presentation may be ended, a new Period may be started, and / or the MPD may be refetched.

[0028] MPD descriptor elements, sometimes called Descriptors, may be provided to applications to instantiate one or more description elements with appropriate scheme information. Some Descriptors (e.g., content protection, role, accessibility, rating, viewpoint, frame packing, and / or UTC timing descriptors) may include a @schemeIdUri attribute to identify the relative scheme. MPD elements that may be supplemental property descriptors (e.g., SupplementalProperty) may include metadata that can be used by DASH clients to optimize processing. MPD elements that may be essential property descriptors (e.g., EssentialProperty) may include metadata for processing the containing element.

[0029] Server and network assisted DASH (SAND) may specify messages exchanged between a streaming client and a network element or between various network elements. Messages between a streaming client (e.g., a DASH client) and a network element or between various network elements (e.g., including a DASH aware network element (DANE)) may provide information about real-time operational characteristics such as performance and status of the network, server, proxy, cache, CDN, and DASH client.

[0030] One or more of the SAND messages such as AnticipatedRequests, AcceptedAlternatives, AbsoluteDeadline, DeliveredAlternative may be used.

[0031] The AnticipatedRequests message may allow a DASH client to inform the DANE of which particular set of segments the DASH client may be interested in. The AnticipatedRequests message may signal a set of segments in a representation that the DASH client may potentially select and may soon request. Table 1 shows example parameters of the AnticipatedRequests message.

[0032] [Table 1]

[0033] The AcceptedAlternatives message can enable a DASH client to inform a DANE in the media delivery path (e.g., a caching DANE) when the DASH client requests a given DASH segment that the DASH client may be willing to accept other DASH segments as alternatives. The client may include and be able to play alternative segments if the client is ready to receive them. Table 2 shows example parameters of the AcceptedAlternatives message.

[0034] [Table 2]

[0035] The AbsoluteDeadline message allows a DASH client to indicate to the DANE the absolute deadline in wall-clock time by which a requested segment must be received in its entirety. Table 3 shows example parameters for the AbsoluteDeadline message.

[0036] [Table 3]

[0037] The DeliveredAlternative message may 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 inform it that the response includes a segment alternative and does not include the requested segment. Table 4 shows example parameters of the DeliveredAlternative message.

[0038] [Table 4]

[0039] The basic mechanisms of MPEG-DASH over HTTP / 1.1 can be augmented by taking advantage of features and / or capabilities that can be provided by modern IP, such as HTTP / 2 and / or WebSockets.

[0040] FIG. 10 shows an example workflow for video streaming using DASH server push. A client may request an MPD and media segments using a push strategy. For example, a client may first request an MPD and then request media segments using the push strategy. Initialization data may be pushed in response to the push strategy associated with the MPD request by the server. After receiving the requested MPD, the client may begin requesting one or more video segments from the server using respective DASH segment URLs and / or the segment push strategy. The server may respond with the requested video segments, followed by a push cycle as indicated by the segment push strategy. After a minimum amount of data has been received, the client may begin playing the video. The process described herein may repeat until the end of the media streaming session.

[0041] Table 5 shows exemplary push strategy types. Table 6 shows an example of which requests each PushType can apply to.

[0042] [Table 5]

[0043] [Table 6]

[0044] 360-degree videos can consume large amounts of bandwidth due to their high resolution and / or high frame rate to provide a compelling and immersive experience. For use cases such as VR sharing, live VR streaming, and / or social VR applications, hundreds and thousands of VR users may watch the same 360-degree video while gazing at different viewports. The viewport adaptation approaches described herein (e.g., tile-based or layer-based processing and delivery approaches) can reduce bandwidth consumption for VR users.

[0045] The ICN-based routing approach supported by the NGN platform may provide an opportunity to reduce bandwidth for multiple VR users. For example, commonly shared regions of a 360-degree video may be fetched from the server (e.g., once) and forwarded to multiple VR users. One or more unique viewport segments may be fetched from the server and forwarded individually to corresponding WTRUs. For example, when two VR users are viewing the same viewport using a tile-based streaming approach, the NGN may achieve multicast gains because both users share the same high-quality viewport tiles and / or the remaining lower-quality tiles. Different decision-making policies on the client side may result in different sequences of HTTP requests being issued by each VR WTRU.

[0046] FIG. 11 shows an exemplary tile-based 360-degree video HTTP request. As shown in FIG. 11, each of two or more WTRUs (e.g., WTRU#A and WTRU#B) sharing the same viewport may send an HTTP request. User A of WTRU#A may 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 may request viewport tiles (e.g., tiles H1 and / or H2) after some or all other tiles (e.g., tiles L3 and / or L4). A DASH client implementation may be configured to determine the order of the viewport tiles and / or other tiles. For example, because tiles are shared by both WTRUs, the NGN may be configured to multicast each tile to both WTRUs. If tile segments are not requested by both users at approximately the same time as shown in FIG. 11, the NGN may fetch each shared segment separately from the server as unicast.

[0047] In a layer-based approach, inter-layer prediction may be used. For example, in a layer-based approach, inter-layer prediction may not be used. As shown in FIG. 6, the EL bitstream in FIG. 6 may be independently decodable from the BL bitstream in FIG. 6. If the BL bitstream is independently decodable, a client may choose to fetch one or more EL segments before the client can fetch one or more BL segments. For example, a client may want to receive one or more viewports (e.g., EL segments) first, so the client may choose to fetch one or more EL segments (e.g., before it fetches one or more BL segments). In another example, another client may want to receive the entire 360-degree video first (e.g., before fetching one or more EL segments), so the client may fetch one or more BL segments first. In this case, each client's HTTP request may be in a different order depending on the base layer segment and / or the enhancement layer segment, as shown in FIG. 12. For example, FIG. 12 shows an exemplary layer-based 360-degree video HTTP request. 12, WTRU#A may send an HTTP request with a base layer segment (e.g., BL) before receiving one or more enhancement layer segments (e.g., H2 and / or H1). WTRU#B may send an HTTP request with one or more enhancement layer segments (e.g., H2 and / or H1) before receiving a base layer segment (e.g., BL).

[0048] Different viewports may be seen by different clients. FIG. 13 shows an example tile-based 360-degree video HTTP request. As shown in FIG. 13, two or more WTRUs (e.g., WTRU#A and WTRU#B) may have the same HTTP request order, while each WTRU may be looking at a different viewport. For example, WTRU#A's viewport may include tile#1 (e.g., H1), while WTRU#B's viewport may include tile#3 (e.g., H3). Because tile#1 and / or tile#3 may not be shared by both WTRUs, tile#1 and / or tile#3 (e.g., H1 and / or H3) may be streamed via unicast. The NGN may be configured to fetch commonly shared tile#2 and / or tile#4 (e.g., L2 and / or L4) for both WTRUs from the server once via implicit multicast. The file size of the high-quality tiles may be larger than the file size of the low-quality tiles. Different tile sizes may shift the HTTP request time (e.g., Δt) between WTRUs, as shown in Figure 14. Figure 14 illustrates exemplary tile-based HTTP request times. As shown in Figure 14, HTTP requests for tile #2 from WTRU #A and WTRU #B may exceed the multicast decision time window (T<Δt). The decision time window (T) may be configured to increase, such that T may be greater than Δt.

[0049] FIG. 15 illustrates an exemplary layer-based 360-degree video HTTP request. For example, as shown in FIG. 15, User A of WTRU #A's viewport may be inside EL region #1 (e.g., H1), while User B of WTRU #B's viewport may be crossing EL regions #3 and #4 (e.g., H3 and H4). If a user requests a base layer segment before both users request an enhancement layer segment, HTTP requests for the base layer segments may become out of sync over time. FIG. 16 illustrates the HTTP request time for an exemplary layer-based approach. As shown in FIG. 16, requests for BLs corresponding to frame #1 may be synchronized. Requests for BLs corresponding to frame #2 may be out of sync.

[0050] A server and network-assisted DASH (SAND) message and / or push strategy can be configured to deliver 360-degree videos over an NGN platform when multiple VR users are watching the same 360-degree video at approximately the same time.

[0051] A hybrid multicast / unicast networking architecture may be provided, for example, where an entire 360-degree video can be coded into a single layer and / or a single chunk file, which may achieve multicast gains when two or more users are viewing the same viewport of the same 360-degree video at approximately the same time.

[0052] Because client-side segment requests may not be synchronized, the WTRUs may share some of the same segments during a viewing session, but the viewport adaptive streaming approach may not be able to achieve sufficient multicast gain.

[0053] MPEG-DASH over HTTP / 1.1 may be based on a client-initiated mechanism whereby the client can (e.g., actively) pull media data from the server. Part 5 of the DASH standard, for Server- and Network-Assisted DASH (SAND), may introduce 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 may provide signaling information regarding real-time operational characteristics of one or more of the network, server, proxy, cache, CDN, DASH client performance and status, etc. A network attachment point (NAP) may use one or more messages described herein to optimize its media delivery strategy for tile-based or layer-based 360-degree video streaming.

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

[0055] For tile-based 360-degree video streaming, a DASH client may be able to determine tile segments to be requested in advance. The DASH client may determine tile segments to be requested in advance based on its viewing orientation, including lower-quality tiles for non-visible areas and / or higher-quality tiles for the visible viewport. The client may use the AnticipatedRequests message to notify a network node (e.g., a server or NAP) of some or all tile segments to be requested immediately. DASH SAND may provide a mechanism that allows the server to send one or more different segments from the requested segments to the client and / or send the segments in a different order. Based on the mechanisms described herein, a NAP may reorganize client requests and / or multicast commonly shared segments to one or more client WTRUs. For example, a NAP may multicast common segments requested by two or more clients with the same priority.

[0056] For example, a NAP may receive a first AntiticipatedRequests message from a first video streaming device (e.g., a DASH client). The first AntiticipatedRequests message may indicate a first plurality of segments in a first relative priority order. The NAP may receive a second AntiticipatedRequests message from a second video streaming device. The second AntiticipatedRequests message may indicate a second plurality of segments in a second relative priority order. The NAP may, for example, determine a priority associated with each of the first plurality of segments based on the first relative priority order. The NAP may, for example, determine a 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 the first AntiticipatedRequests message and the second AntiticipatedRequests message. The common segment may represent the same video segment within a time window. The NAP may determine a first priority value for the common segment indicated by (e.g., based on) the first AntiticipatedRequests message and a second priority value for the common segment indicated by (e.g., based on) the second AntiticipatedRequests message. The NAP may, for example, send a request for the common segment to a server. The NAP may, for example, receive the common segment from the server. On the condition that the first priority value and the second priority value are the same, the NAP may multicast the common segment to the first video streaming device and the second video streaming device. On the condition that the first priority value and the second priority value are different, the NAP may unicast the common segment to the first video streaming device and the second video streaming device.

[0057] FIG. 17 shows an example workflow for client-initiated 360-degree video streaming using multicast. For example, FIG. 17 shows the workflow between DASH clients (e.g., WTRU#A and WTRU#B), a NAP, and a server for implementing multicast between a server and a NAP for 360-degree video streaming. Each client can send an AnticipatedRequests message to the NAP. The AnticipatedRequests message may indicate some or all potential tile segments to be requested and / or a deadline for receiving the requested segments. Each client can notify the NAP that the client may be willing to accept one or more DASH segment alternatives via an AcceptedAlternatives message for each segment request. The alternative segments in the AcceptedAlternatives message may include segments of some or all tiles that have not yet been received. The NAP may select commonly shared segments (e.g., among clients) for multicast and / or determine one or more unique segments for unicast from the server. The NAP may map the alternative segments corresponding to each pending request. Based on the mapping result, the NAP may fetch the corresponding multicast segment from the server once and forward the segment to the WTRU, and may fetch the corresponding unicast segment from the server and forward it to each WTRU individually.

[0058] The sorting process (e.g., performed by a NAP) may include parsing AnticipatedRequests and / or AbsoluteDeadline messages from multiple WTRUs. Commonly shared segments with approximately the same receive deadline value may be identified and placed in a multicast group. The remaining segments may be placed in a unicast group. An alternative response order for pending requests may be determined.

[0059] FIG. 18 shows an example NAP sorting and mapping for tile-based 360-degree video streaming. WTRU#A may 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 may be scheduled to request one or more high-quality tile segments (e.g., H1, H2, and / or H4) and a low-quality tile segment (e.g., L3). WTRU#A and / or WTRU#B may agree to accept segment alternatives. The NAP may sort through a list of expected requests from two or more WTRUs (e.g., WTRU#A and WTRU#B) and identify common requests for multicast (e.g., H1, H2, and / or L3) and unique requests for unicast (e.g., L4 and / or H4). Segment alternatives for each request may be determined, and the NAP may fetch the multicast segments from the server once. When the NAP receives a segment request and / or an AcceptedAlternatives message from the WTRU, the NAP may forward segment alternatives to the WTRU based on the mapping result using a DeliveredAlternative message to inform the WTRU of the actual content that is or should be delivered.

[0060] Each client may include some or all expected tile segments that have not been received in AcceptedAlternatives, and the server may deliver the segments (e.g., the exact segments) upon client request. The client may add lower-quality representations for the corresponding higher-quality tiles requested in the AcceptAlternatives message. In the example shown in FIG. 18, client #B may add a lower-quality tile segment (e.g., L4) corresponding to a higher-quality segment (e.g., H4) in the AcceptedAlternatives message. The NAP may fetch L4 as a multicast segment and forward the multicast segment to clients #A and #B without separately sending H4 via unicast.

[0061] In this way, the NAP may fetch some or all tiles (e.g., H1, H2, L3, and / or L4) from the server once and / or deliver the fetched tiles to WTRU#A and / or WTRU#B.

[0062] The same strategy can be applied to a layer-based 360-degree viewport adaptive streaming approach, where clients may request the same base layer segment and / or different enhanced viewport segments. The base layer segment may be a multicast segment that should be delivered before other enhanced segments. Figure 19 shows an example NAP sorting and mapping for layer-based 360-degree video streaming. As shown in Figure 19, two or more WTRUs may have the same base layer segment (e.g., BL) request and one or more different enhancement layers (e.g., E1, E2, and / or E3). The NAP may sort the base layer segments for multicast fetching and sort the enhancement layer segments for unicast fetching. The DeliveredAlternative message may inform the WTRU of the actual content.

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

[0064] The NAP may store the segments in a buffer, which may be a local buffer (e.g., a local buffer of the NAP). The NAP may receive one or more AnticipatedRequests messages from some or all of the video streaming devices (e.g., WTRUs). The NAP may identify several requests to multiple clients for one or more segments (e.g., shared segments). For segments to be shared by two or more WTRUs, the NAP may fetch the segments from the server once and store the segments in a buffer (e.g., a local buffer of the NAP) for future requests. If no future requests for such segments are pending anymore, the NAP may release the storage of the particular segment. For segments to be requested by a WTRU, the NAP may fetch the segments from the server and forward them to the corresponding WTRU.

[0065] FIG. 20 shows an example multicast design using AnticipatedRequests and a local storage buffer. The example multicast shown in FIG. 20 may be combined with the example of NAP sorting and mapping for tile-based 360-degree video streaming shown in FIG. 18. Based on the AnticipatedRequests messages from two or more WTRUs (e.g., WTRU#A and #B), the NAP may determine that one or more tile segments (e.g., H1, H2, and / or L3) are requested by both WTRUs, and one or more tile segments (e.g., L4 and / or H4) may be requested once from WTRU#A or WTRU#B. When the NAP receives WTRU#A's request for segment H1, the NAP may fetch H1 from the server and forward it to WTRU#A. The NAP may be configured to store the fetched H1 in its local buffer for the pending request from WTRU#B (e.g., a request counter may be used to determine the number of waiting requests). The same procurement procedure may be performed for tiles such as H2 and / or L3. When a stored tile segment is requested by another WTRU, the NAP may forward the stored tile segment to the corresponding WTRU (e.g., from its local buffer) without fetching the requested tile segment from the server again. By configuring to use a local buffer, WTRUs may share the same tile and may not request the same tile at approximately the same time. The tile-based approach described herein may be applied to layer-based viewport adaptive streaming.

[0066] In the case of tile-based 360-degree video streaming, a client (e.g., a client WTRU) may be able to identify a viewport. The client may 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 a viewport based on a location of the 360-degree video stream a user is viewing and / or a region of interest associated with the 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 decide to request multiple segments of the 360-degree video stream in advance. For example, the client may decide to request a first video segment of the 360-degree video stream and a second video segment of the 360-degree video stream. The client may decide to request the first video segment and the second video segment based on the viewport. The client may request a viewport tile segment before other tiles, for example, to ensure that the viewport tile can be delivered before a presentation deadline. For example, a client may prioritize viewport tile segments over non-viewport tile segments. In a multicast strategy using SAND messages as described herein, corresponding viewport requests may be deferred.

[0067] 21(a)-21(c) show examples of tile-based 360-degree video segment distribution. For example, FIG. 21(a) shows tile-based 360-degree video distribution without a SAND message. As shown in FIG. 21(a), a DASH request sequence may be initiated by a client, where a 360-degree frame may be divided into one or more tiles (e.g., four tiles). Each tile may be encoded into one or more lower-quality tiles (e.g., L1, L2, L3, and / or L4) and / or higher-quality tiles (e.g., H1, H2, H3, and / or H4). WTRU#A may request a higher-quality viewport (e.g., H2) and may request other tiles (e.g., L1, L3, and / or L4) with lower quality. WTRU#B may request a higher-quality viewport (e.g., H4) and may request other tiles (e.g., L1, L2, and / or L3) with lower quality. Two or more WTRUs (e.g., WTRU#A and WTRU#B) may request tiles in the same order. If both WTRUs request tiles in the same order, tile L1 may be fetched using implicit multicast via NAP. Figure 21(b) may be an example of tile-based 360-degree video distribution using SAND messages. In Figure 21(b), segment delivery may be reordered and one or more tiles (e.g., tiles L1 and / or L3) may be delivered via multicast. Viewport segments (e.g., H2 and / or H4) may be deferred to the last segment to be delivered. If network bandwidth drops unexpectedly, the approach shown in Figure 21(b) may not be able to deliver viewport tiles in a timely manner. Figure 21(c) shows an example tile-based 360-degree video distribution using high-priority viewport segments. As shown in Figure 21(c), viewport tiles may be delivered before other tiles in invisible areas (e.g., to guarantee viewport delivery).

[0068] For example, when a client may request several tiles with the same quality (e.g., due to bandwidth conditions), the NAP may not identify a viewport segment from a client's request. A SAND message indication may enable one or more DASH clients to indicate segment priorities to a network node (e.g., a NAP). For example, a client WTRU (e.g., a DASH client) may determine a priority associated with one or more video stream segments. The client WTRU may be a video streaming device. The video streaming device may be configured with wireless and / or wired connections as described herein. The client WTRU may determine the priority based on a viewport associated with the WTRU and the video stream. For example, the client WTRU may determine the viewport (e.g., based on the orientation of the client WTRU). The client WTRU may determine the priority based on a time priority, a quality priority, and / or a location with respect to the viewport. For example, a higher priority may be determined for a segment that should be displayed before another segment. A higher priority may be determined for a segment that should be displayed at a higher quality than another segment. A higher priority may be determined for a segment that should be displayed within and / or in close proximity to the viewport. The client WTRU may indicate the priority of one or more video stream segments. The client WTRU may indicate the priority of one or more video stream segments to a network node (e.g., a NAP). Priority signaling may be used by the client to indicate its viewport segments to the network node.

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

[0070] The priority parameter (e.g., value) may indicate the relative priority order of the associated segment with respect to other segments of the same AnticipatedRequests. When a DASH client informs a NAP of which particular set of segments it is interested in, the DASH client may inform the NAP of the priority of each segment. The Priority value may be used to signal a delivery order and / or time priority (e.g., a client may prefer to receive high-priority segments as soon as possible), or a quality priority (e.g., a client may prefer to receive high-quality segments instead of low-quality segments), or a combination of delivery and quality priorities. In tile-based viewport adaptive streaming, a client may include segments for some or all tiles in an AnticipatedRequests message and may set high priority values for viewport segments and low priority values for other segments.

[0071] When a NAP receives an AnticipatedRequests message from a client, the NAP may prefetch high-priority viewport segments to minimize delivery latency. The NAP may identify one or more common segments indicated by multiple clients (e.g., via the AnticipatedRequests message) as having the same priority. For example, one or more common segments may have the same priority within a time window. The NAP may, for example, decide to multicast one or more common segments to multiple clients based on one or more common segments having the same priority. The NAP may unicast one or more segments with different priorities to multiple clients. When a NAP receives an AnticipatedRequests message from multiple clients, the NAP may choose not to prefetch the most commonly requested segments, which may be at a lower priority, and may first prefetch commonly requested high-priority segments to minimize delivery latency. Prefetch scheduling may vary for different applications and / or implementations.

[0072] [Table 7]

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

[0074] [Table 8]

[0075] As another example, a ViewportRequests status message may be signaled to inform the NAP which particular sets it may soon see. Table 9 shows an example data representation of a ViewportRequests message. Each viewport segment may be specified by a byte range and / or a sourceUrl with an absolute deadline by which it should be received.

[0076] [Table 9]

[0077] In the ViewportRequests SAND message described herein, the NAP may schedule the multicast request order to ensure on-time delivery of the most desirable viewport segments.

[0078] When alternative segments should be delivered instead of the requested segment, AcceptedAlternatives and / or DeliveredAlternative messages can be exchanged between the NAP and the DASH client. The client can request one or more segments in a desired order suggested by the NAP, for example, to avoid message exchange overhead. SAND Parameters Enhancing Reception (PER) can be configured to be sent from the NAP to the DASH client for 360-degree video streaming.

[0079] Example parameters for the RequestsOrder PER message are shown in Table 10. The RequestOrder PER message can enable the NAP to signal the set of segments requested in a preferred order as explicitly signaled in the message from the DASH client.

[0080] [Table 10]

[0081] As described herein, the NAP may anticipate one or more pending requested segments signaled in an AnticipatedRequests message from the WTRU. Based on each segment's requested frequency, size, and / or absolute reception deadline, the NAP may sort the requested segments. For example, the NAP may sort from the expected most requested segment to the expected least requested segment, the expected next most requested segment, and so on. The NAP may inform each WTRU of the expected segment request order via a RequestsOrder message based on the sorting and / or analysis results. When the WTRU follows the expected segment request order, additional SAND messages such as AcceptedAlternatives and / or DeliveredAlternative may be skipped and / or bypassed.

[0082] Table 11 shows an example in which a 360-degree video may be divided into four tiles, including 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 next 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 (e.g., marked with * in Table 11) may have a higher priority than the remaining tiles described herein. Based on the result of the sorting, the server may send a RequestsOrder in a PER message to each WTRU to announce the prioritized order of requests as shown in Table 11.

[0083] [Table 11]

[0084] An exemplary multicast gain of the SAND RequestOrder message is shown in Figure 22. As shown in Figure 22, more segments can be delivered via multicast by using the RequestsOrder message.

[0085] FIG. 23 shows an example workflow of the RequestOrder message. As shown in FIG. 23, the server, the NAP, and / or two or more WTRUs may use the RequestOrder message from the example in Table 11. The NAP may receive AnticipatedRequests messages from some or all of the WTRUs and, for example, may identify an optimal request order for each WTRU based on the AnticipatedRequests messages from some or all of the WTRUs. The NAP may send a RequestsOrder message to each WTRU to indicate the prioritized order of requests. If each WTRU follows the RequestsOrder message to request each segment in the expected order, the NAP can fetch commonly shared segments (e.g., H2, H3, L4, and / or L1) from the server once and forward the shared segments to multiple WTRUs. SAND message exchange overhead can be reduced.

[0086] A server can push resources to a client without the client having to ask for them. The server can assume that it may be desirable to push resources. Server push can reduce round-trip delays and achieve the lowest latency (which may be one of the preferred components for an immersive VR experience, for example).

[0087] The NAP may utilize a server push protocol to reduce latency. Figure 24 shows an example workflow of a multicast design for server push. As shown in Figure 24, two or more WTRU clients (e.g., WTRU#A and WTRU#B) may request an MPD. Media segments may be delivered using a push strategy. Initialization data may be pushed in response to the push strategy associated with the MPD request. Once the requested MPD is received, the client may begin requesting one or more video segments from the server using the respective DASH segment URLs and / or segment push strategies. The push strategy type may 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 the segments to be pushed during the push transaction. The NAP may parse the push indication value to distinguish between commonly requested segments shared by the WTRUs and unique segments for each WTRU. The NAP may fetch commonly requested segments from the server (e.g., once) and store them in a local buffer. Based on an explicitly signaled URLList or URL template, the NAP may push the stored segments to the WTRU during a push transaction. For unique segments requested by a WTRU, the WTRU may fetch the segments from the server as unicast and immediately push the unique segments to the corresponding WTRU.

[0088] FIG. 25 shows an example NAP multicast decision for tile-based 360-degree video streaming via server push. As shown in FIG. 25, the NAP may identify tile-based 360-degree video segments for multicast push and / or unicast push. The NAP may receive and parse a push indication with a list of segment URLs from two or more WTRUs (e.g., WTRU#A and WTRU#B). The NAP may identify one or more commonly shared segments (e.g., H1, H2, and / or L3) to be fetched from the server once and store the commonly shared segments in a local buffer (e.g., a buffer in the NAP) where no further future requests are pending. The NAP may push one or more commonly shared segments from the local buffer to each WTRU based on the URLList and / or URL template signaled in the push indication.

[0089] FIG. 26 shows an example NAP multicast decision for layer-based 360-degree video streaming via server push. As shown in FIG. 26, the NAP may identify layer-based 360-degree video segments for multicast and / or unicast fetch from the server. The NAP may receive and parse a push indication with a list of segment URLs from two or more WTRUs (e.g., WTRU#A and WTRU#B). The NAP may identify one or more commonly shared base layer segments (e.g., BL) for implicit multicast fetch and one or more individual enhancement layer segments for each WTRU for unicast fetch (e.g., E1 and E2 for WTRU#A and E3 for WTRU#B). The NAP may fetch one or more commonly shared BL segments from the server once and store one or more BL segments in a local buffer (e.g., the NAP's local buffer). The NAP may push the BL segments from the local buffer to each WTRU based on a URL list and / or a URL template explicitly signaled by the WTRU.

[0090] The NAP may store the segments locally. The Server Push specification may specify that a client may use 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 explicitly signal the segments to be pushed during a push transaction. Table 12 shows examples of segment push orders signaled by different push types.

[0091] [Table 12]

[0092] With a SAND message, the server may be able to deliver an alternative segment instead of the segment requested by the client. Server push can be configured to work similarly. For example, the server may push segments that may be different from those signaled in the push type. The server may determine which segment to push first based on at least one of server load, network state, and / or the importance of a particular segment.

[0093] The format of the PushDirective can be configured as follows. PUSH_DIRECTIVE = PUSH_TYPE [OWS “;” OWS QVALUE] PUSH_TYPE = <An example of PushType (which may be given in Table 5 and / or Table 6 for example)> QVALUE = <The qvalue can be defined as follows. Weight = OWS “;” OWS “q =” qvalue qvalue = (“0” [“.” 0 * 3DIGIT]) / (“1” [“.” 0 * 3 (“0”)]) >

[0094] An additional PUSH_ORDER may indicate whether segments are to be pushed in a strict order so that they are explicitly signaled in the push type or can be determined by the NAP. ORDER = <An exemplary PushOrder defined in Table 13>

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

[0096]

Table 13

[0097] Table 14 shows an example of an explicit PushOrder. The client may request that the server push the next two segments, Segment2 and Segment3, as described in the PushType after the originally requested one. For example, Segment2 may be pushed before Segment3.

[0098] [Table 14]

[0099] Table 15 shows an example of a flexible PushOrder. The client may request that the server push the next two segments, Segment2 and Segment3, as described in the PushType after the first one requested. Segment2 may be pushed before or after Segment3, depending on the server's state.

[0100] [Table 15]

[0101] 27 shows an example multicast workflow using flexible push order. As shown in FIG. 27, two or more clients (e.g., WTRU#A and WTRU#B) may send a PushType to the NAP with the push order parameter set to "flexible." The NAP may identify one or more multicast segments (e.g., H1, H2, and / or L3) to be shared by two or more WTRUs and one or more unicast segments (e.g., L4 and / or H4) for the WTRUs. The NAP may fetch the multicast segments from the server (e.g., once) and push them to the WTRUs, and may also fetch the unicast segments from the server and push them individually to the corresponding WTRUs.

[0102] Figure 28 shows an example multicast workflow using a push type initiated by a NAP. Two or more clients (e.g., WTRU#A and WTRU#B) may send a PushType to the NAP. The NAP may be configured to initiate a push instruction to the client using 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 announce the order of segments to be pushed to the client. If the NAP receives an acknowledgment from the client, the NAP may fetch the segments from the server and push the segments in the order signaled in the push type. If the push instruction is not acknowledged by the client, the NAP may push the segments as originally signaled in the push type received from the client, or the NAP may not acknowledge the push instruction from the client.

[0103] 29A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ 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-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), etc.

[0104] 29A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and 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 wearables, 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 contexts), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0105] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB, a Home Node B, a Home eNodeB, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0106] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, sometimes referred to as a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage for wireless services in a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0107] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communications link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0108] More particularly, as noted above, the communications system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communications 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).

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

[0110] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio (NR) radio access, which may establish the air interface 116 using NR.

[0111] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE and NR radio access, for example, using a dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0112] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0113] 29A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a workplace, a home, a vehicle, a premises, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 29A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0114] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying Quality of Service (QoS) requirements, such as different throughput, latency, error resilience, reliability, data throughput, mobility, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 29A , it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0115] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in 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 network 112 may include another CN connected to one or more RANs that may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0116] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 29A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and with a base station 114b that may employ an IEEE 802.2 wireless technology.

[0117] 29B is a system diagram illustrating an example WTRU 102. As shown in FIG. 29B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment.

[0118] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, other types of integrated circuits (ICs), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 29B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0119] The transmit / receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0120] 29B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More particularly, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0121] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

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

[0123] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0124] 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) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location determination method while remaining consistent with an embodiment.

[0125] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0126] The WTRU 102 may include a full-duplex radio in which transmission and reception of some or all of the signals (associated with a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference through either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0127] 29C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0128] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0129] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG. 29C, the eNodeBs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0130] The CN 106 shown in Figure 29C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the above elements is shown as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0131] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0132] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handovers between eNodeBs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0133] The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0134] The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional fixed communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0135] Although the WTRU is depicted in Figures 29A-29D as a wireless terminal, in some representative embodiments that such a terminal may use (e.g., temporarily or permanently), it is contemplated that wired communications will interface with the communications network.

[0136] In a representative embodiment, the other network 112 may be a WLAN.

[0137] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and out of the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within the BSS may be sent through the AP, e.g., where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

[0138] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In some representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, the particular STA may back off. One STA (e.g., only one station) may transmit at a given time in a given BSS.

[0139] A high-throughput (HT) STA may use a 40 MHz wide channel for communication, for example, via a combination of a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0140] A very high throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may be passed through a segment parser that may split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to the medium access control (MAC).

[0141] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 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 a representative embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices, in macro coverage areas. MTC devices may have limited capabilities, including, for example, support for some and / or limited bandwidths (e.g., only support for some). MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0142] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy for a STA (that only supports 1 MHz mode of operation), it may be considered busy to transmit the entire available frequency band to the AP, even though most of the frequency band may remain idle and be available for use.

[0143] In the United States, the available frequency bands that can be used by 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0144] 29D is a system diagram showing the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

[0145] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from, for example, the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0146] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using scalable numerology-related transmissions. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, cells, and / or portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing various numbers of OFDM symbols and / or lasting for varying lengths of absolute time).

[0147] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with / connect to a gNB 180a, 180b, 180c while also communicating with / connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0148] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interconnection between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 29D, the gNBs 180a, 180b, 180c may communicate with one another via an Xn interface.

[0149] The CN 115 shown in Figure 29D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the above elements is shown as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0150] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on highly reliable and low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services with machine-type communications (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0151] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The type of PDU session may be IP-based, non-IP-based, Ethernet-based, etc.

[0152] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0153] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 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, the WTRUs 102a, 102b, 102c may be connected to the local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0154] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functionality.

[0155] The emulation device may be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in the communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communications network. The emulation device may be directly coupled to another device for testing and / or may perform testing using over-the-air wireless communications.

[0156] One or more emulation devices may perform one or more functions, inclusive, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test laboratory and / or in a test scenario in an undeployed (e.g., test) wired and / or wireless communication network to perform tests of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data. While features and elements are described above in particular combinations, those skilled in the art will appreciate that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) 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, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. A Dynamic Adaptive Streaming over HTTP (DASH) client, sending an expected request message to a DASH aware network element (DANE) including expected requests for DASH segments, the expected requests for the DASH segments being listed in the expected request message based on a descending relative priority order; generating an acceptedalternatives message, said acceptedalternatives message including parameters associated with one or more acceptable alternative DASH segments associated with said DASH segment that the DASH client is willing to accept; sending to the DANE a request associated with the DASH segment and an acceptedalternatives message indicating the one or more acceptable alternative DASH segments; receiving a deliveredalternative message from the DANE in response to the acceptedalternatives message, the deliveredalternative message including an indication of an alternative DASH segment associated with one of the one or more acceptable alternative DASH segments; 1. A DASH client comprising a processor configured to execute at least:

2. 2. The DASH client of claim 1, wherein the expected request for the DASH segment includes a representation source uniform resource locator (URL), a range, and a target time, and the expected request is arranged with at least one other expected request in the descending relative priority order.

3. The DASH client of claim 1 , wherein parameters associated with the one or more acceptable alternative DASH segments include an alternative source URL and an alternative range.

4. 4. The DASH client of claim 3, wherein the alternate source URL indicates a URL of one of the one or more acceptable alternate DASH segments, and the alternate range indicates a byte range associated with one of the one or more acceptable alternate DASH segments.

5. The DASH client of claim 1 , wherein the processor is further configured to send an absolutedeadline message containing an absolute deadline associated with the DASH segment becoming available at the DASH client.

6. The DASH client of claim 5 , wherein the absolute deadline is a date and time by which a requested DASH segment is completely received by the DASH client.

7. 1. A method performed by a Dynamic Adaptive Streaming over HTTP (DASH) client, comprising: sending an expected request message to a DASH aware network element (DANE) including expected requests for DASH segments, the expected requests for the DASH segments being listed in the expected request message based on a descending relative priority order; generating an acceptedalternatives message, said acceptedalternatives message including parameters associated with one or more acceptable alternative DASH segments associated with said DASH segment that the DASH client is willing to accept; sending to the DANE a request associated with the DASH segment and an acceptedalternatives message indicating the one or more acceptable alternative DASH segments; receiving a deliveredalternative message from the DANE in response to the acceptedalternatives message, the deliveredalternative message including an indication of an alternative DASH segment associated with one of the one or more acceptable alternative DASH segments; A method comprising:

8. 8. The method of claim 7, wherein the expected request for the DASH segment includes a representation source Uniform Resource Locator (URL), a range, and a target time, and the expected request is arranged with at least one other expected request in the descending relative priority order.

9. The method of claim 7 , wherein parameters associated with the one or more acceptable alternative DASH segments include an alternative source URL and an alternative range.

10. 10. The method of claim 9, wherein the alternate source URL indicates a URL of one of the one or more acceptable alternate DASH segments, and the alternate range indicates a byte range associated with one of the one or more acceptable alternate DASH segments.

11. 8. The method of claim 7, further comprising sending an absolutedeadline message containing an absolute deadline associated with the DASH segment to be made available at the DASH client.

12. The method of claim 11 , wherein the absolute deadline is a date and time by which a requested DASH segment is completely received by the DASH client.

13. A DANE (Dynamic Adaptive Streaming over HTTP) aware network element, receiving an expected request message from a DASH client including expected requests for DASH segments, the expected requests for the DASH segments being listed in the expected request message based on a descending relative priority order; receiving a request associated with the DASH segment and an acceptedalternatives message from the DASH client, the acceptedalternatives message including parameters associated with one or more acceptable alternative DASH segments associated with the DASH segment that the DASH client is willing to accept; generating a deliveredalternative message, the deliveredalternative message including an indication of an alternative DASH segment associated with one of the one or more acceptable alternative DASH segments; sending the deliveredAlternative message to the DASH client in response to the acceptedAlternatives message; DANE comprising a processor configured to execute:

14. 14. The DANE of claim 13, wherein the expected request for the DASH segment includes a representation source Uniform Resource Locator (URL), a range, and a target time, and the expected request is arranged in the descending relative priority order with at least one other expected request.

15. The DANE of claim 13 , wherein parameters associated with the one or more acceptable alternative DASH segments include an alternative source URL and an alternative range.

16. 16. The DANE of claim 15, wherein the alternate source URL indicates a URL of one of the one or more acceptable alternate DASH segments, and the alternate range indicates a byte range associated with one of the one or more acceptable alternate DASH segments.

17. The DANE of claim 13 , wherein the processor is further configured to receive an absolutedeadline message including an absolute deadline associated with the DASH segment to be made available at the DASH client.

18. 18. The DANE of claim 17, wherein the absolute deadline is a date and time until a requested DASH segment is completely received by the DASH client.

19. 18. The DANE of claim 17, wherein the processor is further configured to sort DASH segments, including the DASH segment, based on the absolute deadline.

20. The DANE of claim 13 , wherein the indication of the alternative DASH segment includes a URL of the actual delivered content.

21. The DANE of claim 13 , wherein the processor is further configured to transmit the alternative DASH segment to the DASH client.

Images