Background data traffic delivery for media data

Abstract

This invention provides a method for retrieving media data, a device, and a computer-readable storage medium that stores instructions. [Solution] The device for retrieving media data includes a memory configured to store media data and one or more processors implemented in a circuit mechanism, the one or more processors sending a request to a media streaming application function (AF) to retrieve media data by background data transfer (BDT), receiving instructions for a BDT opportunity from the media streaming AF in response to the request, retrieving media data by BDT in response to instructions for a BDT transfer opportunity, and storing the retrieved media data in memory.

Description

Technical Field

[0001] This application claims priority to U.S. Patent Application No. 17 / 648,886, filed on January 25, 2022, and U.S. Provisional Patent Application No. 63 / 141,580, filed on January 26, 2021, the entire contents of which are incorporated herein by reference. U.S. Patent Application No. 17 / 648,886, filed on January 25, 2022, claims the benefit of U.S. Provisional Application No. 63 / 141,580, filed on January 26, 2021.

[0002] This disclosure relates to the conveyance of encoded media data.

Background Art

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cellular or satellite radiotelephones, video conferencing devices, and the like. Digital video devices implement video compression techniques such as those defined by MPEG-2, MPEG-4, ITU-T H.263 or ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), ITU-T H.265 (also known as High Efficiency Video Coding (HEVC)), and those described in extensions to such standards, in order to transmit and receive digital video information more efficiently.

[0004] After media data such as video data is encoded, the media data can be packetized for transmission or storage. The media data can be assembled into a media file conforming to any of various standards, such as International Organization for Standardization (ISO)-based media file formats and extensions thereof, such as AVC.

Prior Art Documents

[0005] [Non-Patent Document 1] R. Fielding et al., RFC 2616, "Hypertext Transfer Protocol-HTTP / 1.1", Network Working Group, IETF, June 1999. [Non-Patent Document 2] T. Paila et al., “FLUTE-File Delivery over Unidirectional Transport”, Network Working Group, RFC 6726, November 2012 [Overview of the Initiative] [Means for solving the problem]

[0006] In general, this disclosure describes techniques for streaming media data using background data transfer. In some cases, background data transfer can be used to efficiently deliver content to customers. That is, media data may be sent to client devices during off-peak hours (for example, when many users are asleep or otherwise not using their devices). Users of client devices may then play the media data that was transferred via background data transfer at a later date. Mobile network operators (MNOs) may offer discounted rates for traffic during off-peak hours. Application providers may predict what content will be consumed by various customers and then push the appropriate content to corresponding client devices (also called “user devices” or “UEs”) during a specified time window, for example, during off-peak hours.

[0007] This disclosure describes various techniques related to transferring media data using background data transfer. For example, this disclosure describes techniques related to managing the download process on client devices and networks, how downloads may be triggered, and how cache space on client devices may be managed.

[0008] For example, a method for retrieving media data includes the steps of: sending a request to a media streaming application function (AF) via background data transfer by one or more processors of a client device; receiving instructions for a background data transfer opportunity from the media streaming AF by one or more processors of the client device in response to the request; retrieving media data via background data transfer by one or more processors in response to the instructions for a background data transfer opportunity; and storing the retrieved media data by one or more processors.

[0009] Another example is a device for retrieving media data, the device comprising a memory configured to store media data and one or more processors implemented in a circuit mechanism, the one or more processors configured to send a request to a media streaming application function (AF) to retrieve media data via background data transfer, receive instructions for a background data transfer opportunity from the media streaming AF in response to the request, retrieve media data via background data transfer in response to the instructions for a background data transfer opportunity, and store the retrieved media data in memory.

[0010] In another example, a computer-readable storage medium stores instructions, and when executed, the instructions cause one or more processors in a client device to send a request to a media streaming application function (AF) to retrieve media data via background data transfer, to receive instructions from the media streaming AF for a background data transfer opportunity in response to the request, to retrieve media data via background data transfer in response to the instructions for a background data transfer opportunity, and to store the retrieved media data in memory.

[0011] In another example, a device for retrieving media data includes means for sending a request to retrieve media data via background data transfer, means for receiving instructions for a background data transfer opportunity in response to the request, means for retrieving media data via background data transfer in response to instructions for a background data transfer opportunity, and means for storing the retrieved media data.

[0012] Details of one or more examples are described in the accompanying drawings and the following description. Other features, purposes, and advantages will become apparent from the description and drawings, as well as from the claims. [Brief explanation of the drawing]

[0013] [Figure 1] This block diagram shows an exemplary system that implements techniques for streaming media data over a network. [Figure 2] This is a block diagram showing an example set of components for a retrieval unit. [Figure 3] This is a conceptual diagram illustrating the elements of exemplary multimedia content. [Figure 4] A block diagram showing exemplary video file elements that can correspond to segments of expression. [Figure 5]Block diagram shows an exemplary system that can implement the techniques of this disclosure. [Figure 6] This flowchart illustrates an exemplary method for transporting media data using background data transfer with the techniques of this disclosure. [Figure 7] This flowchart shows an exemplary method for extracting media data using the techniques described herein. [Figure 8] This flowchart shows another exemplary method for extracting media data using the techniques of this disclosure. [Modes for carrying out the invention]

[0014] In general, this disclosure describes techniques for streaming media data using background data transfer. In some cases, background data transfer can be used to efficiently deliver content to customers. That is, media data may be sent to client devices during off-peak hours (for example, when many users are asleep or otherwise not using their devices). Users of client devices may then play the media data that was transferred via background data transfer at a later date. Mobile network operators (MNOs) may offer discounted rates for traffic during off-peak hours. Application providers may predict what content will be consumed by various customers and then, based on these predictions, push appropriate content to corresponding client devices (also called “user devices” or “UEs”) during a specified time window, for example, during off-peak hours.

[0015] This disclosure describes various techniques related to transferring media data using background data transfer. For example, this disclosure describes techniques related to managing the download process on client devices and networks, how downloads may be triggered, and how cache space on client devices may be managed.

[0016] The techniques of this disclosure may be applied to video files conforming to video data encapsulated according to any of the following: ISO-based media file formats, Scalable Video Coding (SVC) file formats, Advanced Video Coding (AVC) file formats, Third Generation Partnership Project (3GPP®) file formats, and / or Multiview Video Coding (MVC) file formats, or other similar video file formats.

[0017] In HTTP streaming, frequently used operations include HEAD, GET, and Partial GET. The HEAD operation retrieves the header of a file associated with a given Uniform Resource Locator (URL) or Uniform Resource Name (URN) without retrieving the payload associated with the URL or URN. The GET operation retrieves the entire file associated with a given URL or URN. The Partial GET operation receives a range of bytes as an input parameter and retrieves a contiguous number of bytes from the file, in this case the number of bytes corresponds to the range of bytes received. Thus, since the Partial GET operation can retrieve one or more individual movie fragments, movie fragments may be provided for HTTP streaming. Movie fragments may contain several track fragments from different tracks. In HTTP streaming, a media presentation can be a structured collection of data accessible to the client. The client can request and download media data information to present the streaming service to the user.

[0018] In an example of streaming 3GPP data using HTTP streaming, there may be multiple representations for the video and / or audio data of multimedia content. As described below, different representations may correspond to different coding characteristics (e.g., different profiles or levels of a video coding standard), different coding standards or extensions of a coding standard (such as multi-view and / or scalable extensions), or different bitrates. The manifest of such representations may be defined in a Media Presentation Description (MPD) data structure. A media presentation may correspond to a structured collection of data accessible to an HTTP streaming client device. The HTTP streaming client device can request and download media data information to present a streaming service to the user of the client device. The media presentation may be described in an MPD data structure that includes updates to the MPD.

[0019] A media presentation may include a sequence of one or more periods. Each period can extend until the start of the next period or, in the case of the last period, until the end of the media presentation. Each period may include one or more representations for the same media content. A representation can be one of several alternative encoded versions of audio, video, timed text, or other such data. Representations may vary by type of encoding, e.g., bitrate, resolution, and / or codec for video data, and bitrate, language, and / or codec for audio data. The term representation may be used to refer to a section of encoded audio data or encoded video data corresponding to a particular period of multimedia content and encoded in a particular way.

[0020] A representation for a particular period can be assigned to a group indicated by an attribute in the MPD that indicates the adaptation set to which the representation belongs. Representations within the same adaptation set are generally considered to be alternatives to each other in that a client device can switch dynamically and seamlessly between these representations, for example, to perform bandwidth adaptation. For example, each representation of video data for a particular period can be assigned to the same adaptation set, so any of the representations can be selected to be decoded to present media data, such as video data or audio data, of the multimedia content for the corresponding period. In some examples, the media content within one period can be represented by either one representation from group 0 or a combination of at most one representation from each non-zero group, if any. The timing data for each representation of a period can be represented relative to the start time of the period.

[0021] A representation can include one or more segments. Each representation may include an initialization segment, or each segment of the representation may be self-initializing. The initialization segment, if present, can include initialization information for accessing the representation. In general, the initialization segment does not contain media data. A segment can be uniquely referenced by an identifier, such as a Uniform Resource Locator (URL), Uniform Resource Name (URN), or Uniform Resource Identifier (URI). The MPD can provide an identifier for each segment. In some examples, the MPD can also provide byte ranges in the form of a range attribute that can correspond to data for segments within a file accessible by a URL, URN, or URI.

[0022] Different representations can be selected to extract different types of media data substantially simultaneously. For example, a client device can select audio, video, and timed text representations from which to extract segments. In some examples, a client device can select a specific set of adaptations to implement bandwidth adaptation; that is, a client device can select an adaptation set containing video representations, an adaptation set containing audio representations, and / or an adaptation set containing timed text. Alternatively, a client device can select an adaptation set for one type of media (e.g., video) and directly select representations for other types of media (e.g., audio and / or timed text).

[0023] Figure 1 is a block diagram illustrating an exemplary system 10 that implements a technique for streaming media data over a network. In this example, system 10 includes a content preparation device 20, a server device 60, and a client device 40. The client device 40 and the server device 60 are connected communicatively by a network 74, which may include the Internet. In some examples, the content preparation device 20 and the server device 60 may also be connected by network 74 or another network, or they may be connected communicatively directly. In some examples, the content preparation device 20 and the server device 60 may include the same device.

[0024] In the example in Figure 1, the content preparation device 20 includes an audio source 22 and a video source 24. The audio source 22 may include, for example, a microphone that generates electrical signals representing captured audio data to be encoded by an audio encoder 26. Alternatively, the audio source 22 may include a storage medium that stores previously recorded audio data, an audio data generator such as a computerized synthesizer, or any other source of audio data. The video source 24 may include a video camera that generates video data to be encoded by a video encoder 28, a storage medium encoded with previously recorded video data, a video data generation unit such as a computer graphics source, or any other source of video data. The content preparation device 20 is not necessarily communicatively coupled to the server device 60 in all examples, but may store multimedia content on a separate medium that is read by the server device 60.

[0025] Raw audio and video data may include analog or digital data. Analog data may be digitized before being encoded by the audio encoder 26 and / or video encoder 28. Audio source 22 may acquire audio data from a speaking participant while that participant is speaking, and video source 24 may simultaneously acquire video data of the speaking participant. In other examples, audio source 22 may comprise a computer-readable storage medium containing stored audio data, and video source 24 may comprise a computer-readable storage medium containing stored video data. Thus, the techniques described herein may be applied to live, streaming, real-time audio data and real-time video data, or to archived pre-recorded audio data and archived pre-recorded video data.

[0026] An audio frame corresponding to a video frame is generally an audio frame that contains audio data captured (or generated) by an audio source 22 simultaneously with video data captured (or generated) by a video source 24 contained within the video frame. For example, while a speaking participant is generating audio data by speaking, audio source 22 captures the audio data, and video source 24 simultaneously captures video data of the speaking participant, i.e., while audio source 22 is capturing the audio data. Therefore, an audio frame can temporally correspond to one or more specific video frames. Thus, an audio frame corresponding to a video frame generally corresponds to a situation in which audio data and video data are captured simultaneously, and in that situation, the audio frame and video frame each contain the simultaneously captured audio data and video data.

[0027] In some examples, the audio encoder 26 may encode a timestamp in each encoded audio frame representing the time the audio data for that encoded audio frame was recorded, and similarly, the video encoder 28 may encode a timestamp in each encoded video frame representing the time the video data for that encoded video frame was recorded. In such examples, the audio frame corresponding to the video frame may include an audio frame containing a timestamp and a video frame containing the same timestamp. The content preparation device 20 may include an internal clock that the audio encoder 26 and / or the video encoder 28 may use to generate timestamps, or an internal clock that the audio source 22 and the video source 24 may use to associate audio data and video data with timestamps, respectively.

[0028] In some examples, an audio source 22 can send data to an audio encoder 26 corresponding to the time the audio data was recorded, and a video source 24 can send data to a video encoder 28 corresponding to the time the video data was recorded. In some examples, the audio encoder 26 can encode a sequence identifier in the encoded audio data, not necessarily indicating the absolute time the audio data was recorded, but rather indicating the relative time order of the encoded audio data. Similarly, the video encoder 28 can use a sequence identifier to indicate the relative time order of the encoded video data. Likewise, in some examples, the sequence identifier may be mapped with or correlated with a timestamp.

[0029] The audio encoder 26 generally generates a stream of encoded audio data, and the video encoder 28 generates a stream of encoded video data. Each individual stream of data (whether audio or video) is sometimes called an elementary stream. An elementary stream is a single digitally coded (and possibly compressed) component of a representation. For example, the coded video or audio portion of a representation can be an elementary stream. An elementary stream can be converted to a packetized elementary stream (PES) before being encapsulated within a video file. Within the same representation, a stream ID may be used to distinguish a PES packet belonging to one elementary stream from a PES packet belonging to another elementary stream. The basic unit of data in an elementary stream is a packetized elementary stream (PES) packet. Therefore, coded video data generally corresponds to an elementary video stream. Similarly, audio data corresponds to one or more individual elementary streams.

[0030] Many video coding standards, such as the ITU-T H.264 / AVC and ITU-T H.265 High Efficiency Video Coding (HEVC) standards, and the ITU-T H.266 Multipurpose Video Coding (VVC) standard, define the syntax, semantics, and decoding processes for error-free bitstreams, all of which adhere to a certain profile or level. While video coding standards generally do not specify encoders, encoders are tasked with ensuring that the generated bitstream conforms to the standard for the decoder. In the context of video coding standards, a “profile” corresponds to a subset of algorithms, features, or tools, and the constraints that apply to them. For example, as defined by the H.264 standard, a “profile” is a subset of the overall bitstream syntax specified by the H.264 standard. A “level” corresponds to limitations on the decoder’s resource consumption, such as decoder memory and computation, which relates to picture resolution, bitrate, and block processing speed. Profiles can be signaled by the profile_idc (profile indicator) value, while levels can be signaled by the level_idc (level indicator) value.

[0031] For example, the H.264 standard acknowledges that it is still possible to expect large variations in encoder and decoder performance depending on the values ​​taken by syntax elements in a bitstream, such as a specified size of the picture being decoded, within the limits imposed by the syntax of a given profile. The H.264 standard further acknowledges that in many applications, it is neither practical nor economical to implement a decoder capable of handling all hypothetical uses of the syntax within a particular profile. Therefore, the H.264 standard defines a “level” as a specified set of constraints imposed on the values ​​of syntax elements in a bitstream. These constraints may be simple restrictions on values. Alternatively, these constraints may take the form of constraints on arithmetic combinations of values ​​(e.g., the product of the number of pictures decoded per second, the height of the picture, and the width of the picture). The H.264 standard further specifies that individual implementations may support different levels for each supported profile.

[0032] Decoders conforming to a profile typically support all features defined within that profile. For example, as a coding feature, B-picture coding is not supported in the baseline profile of H.264 / AVC, but is supported in other profiles of H.264 / AVC. A decoder conforming to a certain level should be able to decode any bitstream that does not require resources exceeding the limits defined within that level. Profile and level definitions can be useful for explainability. For example, during video transmission, pairs of profile and level definitions may be arranged and agreed upon for the entire transmission session. More specifically, in H.264 / AVC, a level can define the number of macroblocks to be processed, the size of the decoded picture buffer (DPB), the size of the coded picture buffer (CPB), the range of vertical motion vectors, the limit on the maximum number of motion vectors per two consecutive MBs, and whether a B-block can have sub-macroblock divisions smaller than 8x8 pixels. In this way, a decoder can determine whether it is capable of properly decoding a bitstream.

[0033] In the example shown in Figure 1, the encapsulation unit 30 of the content preparation device 20 receives an elementary stream containing encoded video data from the video encoder 28 and an elementary stream containing encoded audio data from the audio encoder 26. In some examples, the video encoder 28 and the audio encoder 26 may each include a packetizer for forming PES packets from the encoded data. In other examples, the video encoder 28 and the audio encoder 26 may each interface with their respective packetizers for forming PES packets from the encoded data. In yet another example, the encapsulation unit 30 may include a packetizer for forming PES packets from the encoded audio data and the encoded video data.

[0034] The video encoder 28 can encode video data of multimedia content in various ways to produce various representations of multimedia content at various bitrates having various characteristics such as pixel resolution, frame rate, compliance with various coding standards, compliance with various profiles and / or levels of profiles for various coding standards, representations having one or more views (e.g., for two-dimensional or three-dimensional playback), or other such characteristics. The representations used in this disclosure may include audio data, video data, text data (e.g., for closed captions), or one of the other such data. The representation may include an elementary stream, such as an audio elementary stream or a video elementary stream. Each PES packet may include a stream_id that identifies the elementary stream to which the PES packet belongs. The encapsulation unit 30 is responsible for assembling the elementary streams into video files (e.g., segments) of the various representations.

[0035] The encapsulation unit 30 receives PES packets for the elementary stream of the representation from the audio encoder 26 and video encoder 28, and forms corresponding Network Abstraction Layer (NAL) units from the PES packets. Encoded video segments may be organized into NAL units, which enable the application of addressing for “network-friendly” video representations, such as videophone, storage, broadcast, or streaming. NAL units can be classified into Video Coding Layer (VCL) NAL units and non-VCL NAL units. VCL units may include a core compression engine and may contain block, macroblock, and / or slice-level data. Other NAL units may be non-VCL NAL units. In some examples, an encoded picture in one time instance may be presented, typically as a primary encoded picture, and may be contained within an access unit that may contain one or more NAL units.

[0036] Non-VCL NAL units may include, in particular, parameter set NAL units and SEI NAL units. Parameter sets may contain sequence-level header information (within sequence parameter sets (SPS)) and picture-level header information (within picture parameter sets (PPS)). With parameter sets (e.g., PPS and SPS), this infrequently changing information does not need to be repeated for each sequence or picture, thus improving coding efficiency. Furthermore, the use of parameter sets can enable out-of-band transmission of critical header information, eliminating the need for redundant transmissions for error recovery. In an example of out-of-band transmission, parameter set NAL units may be transmitted on a different channel than other NAL units, such as SEI NAL units.

[0037] Supplemental Emphasis Information (SEI) may contain information not necessary for decoding coded picture samples from VCL NAL units, but may assist processes related to decoding, display, error recovery, and other purposes. SEI messages may be contained within non-VCL NAL units. SEI messages are a normative part of several standard specifications and are therefore not always required in standard-compliant decoder implementations. SEI messages can be sequence-level SEI messages or picture-level SEI messages. Some sequence-level information may be contained within SEI messages, such as the scalability information SEI message in the SVC example and the view scalability information SEI message in MVC. These exemplary SEI messages may, for example, convey information about operating point extraction and operating point characteristics. In addition, the encapsulation unit 30 may form manifest files such as Media Presentation Descriptor (MPD) that describe the characteristics of the representation. The encapsulation unit 30 may format the MPD according to Extensible Markup Language (XML).

[0038] The encapsulation unit 30 may provide data for one or more representations of multimedia content to the output interface 32, along with a manifest file (e.g., MPD). The output interface 32 may include a network interface or a Universal Serial Bus (USB) interface, an interface for writing to a storage medium such as a CD or DVD writer or burner, an interface to a magnetic storage medium or flash storage medium, or other interfaces for storing or transmitting media data. The encapsulation unit 30 can provide data for each representation of the multimedia content to the output interface 32, which can send the data to the server device 60 via network transmission or storage medium. In the example in Figure 1, the server device 60 includes a storage medium 62 that stores various multimedia content 64, each containing a manifest file 66 and one or more representations 68A to 68N (representation 68). In some examples, the output interface 32 may also send data directly to the network 74.

[0039] In some examples, representation 68 can be separated into adaptive sets. That is, various subsets of representation 68 may include each common set of characteristics such as codecs, profiles and levels, resolutions, number of views, segment file formats, text type information which may identify the language or other characteristics of the text to be displayed with the representation and / or audio data to be decoded and presented, for example by the speaker, camera angle information which may represent the camera angle or the field of view of the real-world camera in the scene of the representation within the adaptive set, and rating information which represents the appropriateness of the content to a particular audience.

[0040] The manifest file 66 may contain data indicating a subset of representations 68 corresponding to a particular adaptation set, as well as common characteristics of the adaptation set. The manifest file 66 may also contain data representing individual characteristics, such as bitrate, for individual representations of the adaptation set. In this way, the adaptation set may enable simplified network bandwidth adaptation. Representations within an adaptation set may be indicated using child elements of the adaptation set element in the manifest file 66.

[0041] The server device 60 includes a request processing unit 70 and a network interface 72. In some examples, the server device 60 may include multiple network interfaces. Furthermore, some or all of the features of the server device 60 may be implemented on other devices in the content distribution network, such as routers, bridges, proxy devices, switches, or other devices. In some examples, intermediate devices in the content distribution network may include components that cache data for multimedia content 64 and substantially conform to the components of the server device 60. Generally, the network interface 72 is configured to send and receive data over the network 74.

[0042] The request processing unit 70 is configured to receive network requests for data in the storage medium 62 from client devices such as the client device 40. For example, the request processing unit 70 may implement the Hypertext Transfer Protocol (HTTP) version 1.1, as described in RFC 2616, "Hypertext Transfer Protocol - HTTP / 1.1", Network Working Group, IETF, June 1999, by R. Fielding et al. That is, the request processing unit 70 may be configured to receive HTTP GET or partial GET requests and to respond to those requests by providing data for the multimedia content 64. A request may specify one segment of the representation 68, for example, using the segment's URL. In some examples, a request may also specify one or more byte ranges of a segment, thus including a partial GET request. The request processing unit 70 may further be configured to respond to HTTP HEAD requests to provide header data for one segment of the representation 68. In any case, the request processing unit 70 may be configured to process the request to provide the requested data to the requesting device, such as the client device 40.

[0043] As an addition or alternative, the request processing unit 70 may be configured to deliver media data via a broadcast or multicast protocol such as eMBMS. The content preparation device 20 can create DASH segments and / or subsegments in substantially the same manner as described, but the server device 60 can deliver these segments or subsegments using eMBMS or another broadcast or multicast network transport protocol. For example, the request processing unit 70 may be configured to receive multicast group join requests from client devices 40. That is, the server device 60 may advertise an Internet Protocol (IP) address associated with a multicast group associated with specific multimedia content (e.g., a broadcast of a live event) to client devices, including client device 40. Client device 40 can then submit a request to join the multicast group. This request may be propagated through the network 74, for example, to routers that make up the network 74, so that routers direct traffic destined for the IP address associated with the multicast group to joining client devices such as client device 40.

[0044] As shown in the example in Figure 1, the multimedia content 64 includes a manifest file 66 which may correspond to a Media Presentation Description (MPD). The manifest file 66 may contain descriptions of various alternative representations 68 (e.g., video services of different quality), which may include, for example, codec information, profile values, level values, bitrate, and other characteristics for further description of the representation 68. The client device 40 may retrieve the MPD of the media presentation to determine how to access segments of the representation 68.

[0045] Specifically, the retrieval unit 52 may retrieve configuration data (not shown) of the client device 40 to determine the decoding capability of the video decoder 48 and the rendering capability of the video output 44. The configuration data may also include any or all of the following: language preferences selected by the user of the client device 40, one or more camera fields of view corresponding to depth preferences set by the user of the client device 40, and / or rating preferences selected by the user of the client device 40. The retrieval unit 52 may comprise, for example, a web browser or media client configured to submit HTTP GET and partial GET requests. The retrieval unit 52 may correspond to software instructions executed by one or more processors or processing units (not shown) of the client device 40. In some examples, all or part of the functionality described with respect to the retrieval unit 52 may be implemented in hardware, or in a combination of hardware, software, and / or firmware, in which case the required hardware may be provided to execute instructions for the software or firmware.

[0046] The extraction unit 52 can compare the decoding and rendering capabilities of the client device 40 with the characteristics of the representation 68 indicated by the information in the manifest file 66. The extraction unit 52 may first extract at least a portion of the manifest file 66 in order to determine the characteristics of the representation 68. For example, the extraction unit 52 may request a portion of the manifest file 66 that describes the characteristics of one or more adaptive sets. The extraction unit 52 may select a subset of representation 68 (e.g., adaptive sets) that have characteristics that can be satisfied by the coding and rendering capabilities of the client device 40. The extraction unit 52 may then determine the bitrate for the representations in the adaptive sets, determine the amount of network bandwidth currently available, and extract a segment from one of the representations that has a bitrate that can be satisfied by the network bandwidth.

[0047] Generally, higher bitrates in a performance result in higher video playback quality, while lower bitrates in a performance may result in sufficient video playback quality when available network bandwidth is reduced. Therefore, when available network bandwidth is relatively high, the extraction unit 52 can extract data from performances with relatively high bitrates, and when available network bandwidth is low, the extraction unit 52 can extract data from performances with relatively low bitrates. In this way, the client device 40 can stream multimedia data over the network 74 while adapting to the changing network bandwidth availability of the network 74.

[0048] As an addition or alternative, the retrieval unit 52 may be configured to receive data according to broadcast or multicast network protocols such as eMBMS or IP multicast. In such an example, the retrieval unit 52 can submit a request to join a multicast network group associated with a particular media content. After joining the multicast group, the retrieval unit 52 can receive data from the multicast group without issuing any further requests to the server device 60 or the content preparation device 20. The retrieval unit 52 can submit a request to leave the multicast group when the data from the multicast group is no longer needed, for example, to stop playback or to change the channel to a different multicast group.

[0049] The network interface 54 can receive data from a selected representation segment and provide it to the extraction unit 52, which can then provide the segment to the decapsulation unit 50. The decapsulation unit 50 decapsulates the video file elements into constituent PES streams, depackets the PES streams to extract the encoded data, and can send the encoded data to either the audio decoder 46 or the video decoder 48, depending on whether the encoded data is part of an audio stream or a video stream, as indicated by the PES packet header of the stream, for example. The audio decoder 46 decodes the encoded audio data and sends the decoded audio data to the audio output 42, while the video decoder 48 decodes the encoded video data and sends the decoded video data, which may contain multiple views of the stream, to the video output 44.

[0050] The video encoder 28, video decoder 48, audio encoder 26, audio decoder 46, encapsulation unit 30, extraction unit 52, and decapsulation unit 50 may each be implemented as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic circuit mechanisms, software, hardware, firmware, or any combination thereof, where applicable. Each of the video encoder 28 and video decoder 48 may be contained within one or more encoders or decoders, and any of these may be integrated as part of a composite video encoder / decoder (codec). Similarly, each of the audio encoder 26 and audio decoder 46 may be contained within one or more encoders or decoders, and any of these may be integrated as part of a composite codec. A device including the video encoder 28, video decoder 48, audio encoder 26, audio decoder 46, encapsulation unit 30, extraction unit 52, and / or decapsulation unit 50 may include an integrated circuit, a microprocessor, and / or a wireless communication device such as a cellular phone.

[0051] The client device 40, the server device 60, and / or the content preparation device 20 may be configured to operate in accordance with the techniques of this disclosure. As an example, this disclosure describes these techniques relating to the client device 40 and the server device 60. However, it should be understood that the content preparation device 20 may be configured to implement these techniques instead of (or in addition to) the server device 60.

[0052] The encapsulation unit 30 can form a NAL unit that includes a header that identifies the program to which the NAL unit belongs, as well as the payload, such as audio data, video data, or data describing the transport or program stream to which the NAL unit corresponds. For example, in H.264 / AVC, the NAL unit includes a 1-byte header and a payload of variable size. A NAL unit that includes video data in its payload may include various levels of granularity of video data. For example, the NAL unit may include blocks of video data, multiple blocks, slices of video data, or an entire picture of video data. The encapsulation unit 30 can receive encoded video data from the video encoder 28 in the form of PES packets of elementary streams. The encapsulation unit 30 can associate each elementary stream with a corresponding program.

[0053] The encapsulation unit 30 can also assemble access units from multiple NAL units. Generally, an access unit may include one or more NAL units to represent frames of video data, and, when such audio data is available, audio data corresponding to those frames. An access unit generally includes all NAL units for one output time instance, for example, all audio and video data for one time instance. For example, if each view has a frame rate of 20 frames per second (fps), each time instance may correspond to a time interval of 0.05 seconds. During this time interval, a particular frame for all views of the same access unit (same time instance) may be rendered simultaneously. In one example, an access unit may include a coded picture within one time instance, which may be presented as a primary coded picture.

[0054] Therefore, an access unit can contain all audio and video frames of a common time instance, for example, all views corresponding to time X. This disclosure also refers to the encoded picture of a particular view as a “view component.” That is, a view component may contain the encoded picture (or frame) for a particular view at a particular time. Therefore, an access unit can be defined as containing all view components of a common time instance. The decoding order of an access unit does not necessarily have to be the same as the output or display order.

[0055] A media presentation may include a media presentation description (MPD) that can contain descriptions of different alternative representations (e.g., video services with different qualities), and the description may include, for example, codec information, profile values, and level values. An MPD is an example of a manifest file, such as manifest file 66. A client device 40 can retrieve the MPD of a media presentation to determine how to access movie fragments of various presentations. Movie fragments may be placed within movie fragment boxes (moof boxes) of video files.

[0056] The manifest file 66 (which may include, for example, an MPD) can advertise the availability of segments in representation 68. That is, the MPD may include information indicating the wall clock time when one of the first segments in representation 68 becomes available, as well as information indicating the duration of the segments within representation 68. In this way, the retrieval unit 52 of the client device 40 can determine when each segment is available based on the start time and the duration of the segments preceding a particular segment.

[0057] After the encapsulation unit 30 assembles the NAL unit and / or access unit into a video file based on the received data, the encapsulation unit 30 passes the video file to the output interface 32 for output. In some examples, instead of sending the video file directly to the client device 40, the encapsulation unit 30 can store the video file locally or send the video file to a remote server via the output interface 32. The output interface 32 may include, for example, a transmitter, a transceiver, a device for writing data to a computer-readable medium such as an optical drive, a magnetic media drive (e.g., a floppy drive), a Universal Serial Bus (USB) port, a network interface, or other output interface. The output interface 32 outputs the video file to a computer-readable medium such as a transmission signal, magnetic media, optical media, memory, a flash drive, or other computer-readable medium.

[0058] The network interface 54 can receive NAL units or access units via the network 74 and provide the NAL units or access units to the decapsulation unit 50 via the extraction unit 52. The decapsulation unit 50 decapsulates the elements of the video file into constituent PES streams, depackets the PES streams to extract encoded data, and can send the encoded data to either the audio decoder 46 or the video decoder 48, depending on whether the encoded data is part of an audio stream or a video stream, as indicated by the PES packet header of the stream, for example. The audio decoder 46 decodes the encoded audio data and sends the decoded audio data to the audio output 42, while the video decoder 48 decodes the encoded video data and sends the decoded video data, which may contain multiple views of the stream, to the video output 44.

[0059] The content preparation device 20 and / or server device 60 may represent an application provider device, and the client device 40 may represent a user device (UE). The network 74 may represent a fifth-generation (5G) mobile network. Generally, the content preparation device 20 and / or server device 60 may create a background data transfer (BDT) configuration, and the client device 40 may decide to use background data transfer to download media data. The client device 40 (e.g., retrieval unit 52) ​​may run a media session handler (MSH) and a media player application or streaming application (e.g., a DASH application or a plug-in to a web browser). According to the techniques of this disclosure, the retrieval unit 52 may, for example, request to perform a background data transfer to retrieve media data from the server device 60, receive data representing a BDT opportunity for a particular time, and then perform a background data transfer at the time indicated for the BDT opportunity.

[0060] Figure 2 is a block diagram showing in more detail an exemplary set of components of the extraction unit 52 of Figure 1. In this example, the extraction unit 52 includes a media session handler (MSH) unit 100 and a media application 112.

[0061] In this example, the MSH unit 100 further includes a receiving unit 106, a cache 104, and a proxy server unit 102. In this example, the receiving unit 106 is configured to receive data via communication standards such as 3GPP or 5G. In some examples, the receiving unit 106 may receive media data via a file delivery protocol, such as File Delivery over Unidirectional Transport (FLUTE), described by T. Paila et al., "FLUTE - File Delivery over Unidirectional Transport," Network Working Group, RFC 6726, November 2012, available, for example at tools.ietf.org / html / rfc6726. That is, the receiving unit 106 may receive files via broadcast from, for example, a server device 60 that can act as a broadcast / multicast service center (BM-SC).

[0062] When the MSH unit 100 receives data about media data (for example, a file), the MSH unit 100 may store the received data in the cache 104. The cache 104 may include a computer-readable storage medium such as flash memory, a hard disk, RAM, or any other suitable storage medium.

[0063] The proxy server unit 102 may act as a server for providing media data from the cache 104 to the media application 112. For example, the proxy server unit 102 may provide the media application 112 or an intermediate application such as a DASH client with an MPD file or other manifest file. The proxy server unit 102 may advertise the availability time for segments within the MPD file and within hyperlinks from which segments can be retrieved. These hyperlinks may include a local host address prefix corresponding to the client device 40 (e.g., 127.0.0.1 for IPv4). In this way, the media application 112 or an intermediate application may request segments from the proxy server unit 102, for example, using an HTTP GET or partial GET request. For example, with respect to a segment available from the link http: / / 127.0.0.1 / rep1 / seg3, the media application 112 may construct an HTTP GET request that includes a request for http: / / 127.0.0.1 / rep1 / seg3 and submit that request to the proxy server unit 102. The proxy server unit 102 can retrieve the requested media data from the cache 104 and, in response to such a request, provide that data to the media application 112.

[0064] According to the techniques of this disclosure, the media application 112 may correspond to a media or streaming application that interacts with the MSH unit 100 to retrieve media data via background data transfer. In the example shown in Figure 2, the MSH unit 100 may retrieve media data via background data transfer to store it, for example, in the cache 104.

[0065] In another example, the MSH unit 100 may alert the media application 112 to a BDT opportunity, and the media application 112 may retrieve the media data via background data transfer.

[0066] For illustrative purposes, assuming that MSH unit 100 retrieves media data from server device 60, for example, via background data transfer, MSH unit 100 may generally determine the time to retrieve the media data. For example, MSH unit 100 may receive data representing an off-peak designated time window for retrieving media data. For example, media application 112 may first send a request to MSH unit 100 indicating that specific media data is requested and should be transferred via background data transfer. MSH unit 100 may then send the request data to, for example, server device 60 or another unit on network 74, such as a 5G media streaming downlink (5GMSd) application function (AF) or other media streaming application function.

[0067] The 5GMSd AF may respond to the MSH unit 100 with a notification of a background data transfer opportunity. The notification may include data defining an off-peak time window. Thus, the MSH unit 100 (or, in some examples, the media application 112) may retrieve media data during the off-peak time window. In the example where the media application 112 retrieves media data, the MSH unit 100 should send the data defining the off-peak time window from the notification to the media application 112.

[0068] In the example shown in Figure 2, the MSH unit 100 may store the media data retrieved by background data transfer in the cache 104. The MSH unit 100 may store this media data in the cache 104 until a later time, for example, until the user wishes to observe the playback of the media data. In some examples, the media data may be locked until a later time so that the MSH unit 100 can prevent access to the media data until a subsequent time. For example, the media data may correspond to an unreleased movie. Therefore, the MSH unit 100 may retrieve the media data prior to its release date and prevent access to the retrieved media data until the release date and time. In some examples, the release date and time may be specified in the instructions for the background data transfer opportunity.

[0069] Figure 3 is a conceptual diagram showing the elements of an exemplary multimedia content 120. The multimedia content 120 may correspond to multimedia content 64 (Figure 1) or another multimedia content stored in the storage medium 62. In the example in Figure 3, the multimedia content 120 includes a media presentation description (MPD) 122 and multiple representations 124A to 124N (representation 124). Representation 124A includes optional header data 126 and segments 128A to 128N (segment 128), while representation 124N includes optional header data 130 and segments 132A to 132N (segment 132). The character N is conveniently used to specify the last movie fragment of each representation 124. In some examples, there may be different numbers of movie fragments between representations 124.

[0070] MPD122 may contain a data structure separate from representation 124. MPD122 may correspond to manifest file 66 in Figure 1. Similarly, representation 124 may correspond to representation 68 in Figure 1. Generally, MPD122 may contain data that generally represents the characteristics of representation 124, such as coding and rendering characteristics, adaptive sets, the profile to which MPD122 corresponds, text type information, camera angle information, rating information, trick mode information (e.g., information indicating representations that include temporal subsequences), and / or information for searching for distant time periods (e.g., for inserting targeted advertisements into media content being played).

[0071] Header data 126, if present, may describe the characteristics of segment 128, such as the temporal location of random access points (RAPs, also known as stream access points (SAPs)), which segments of segment 128 contain random access points, the byte offset to the random access points within segment 128, the uniform resource locator (URL) of segment 128, or other aspects of segment 128. Header data 130, if present, may describe similar characteristics of segment 132. Alternatively, such characteristics may be entirely contained within MPD 122.

[0072] Segments 128 and 132 include one or more coded video samples, each of which may include a frame or slice of video data. Each coded video sample in segment 128 may have similar characteristics, such as height, width, and bandwidth requirements. Such characteristics may be described by data in MPD122, but such data is not shown in the example in Figure 3. MPD122 may include characteristics as described by the 3GPP specification, with some or all of the signaled information described herein added.

[0073] Each of segments 128 and 132 can be associated with a unique uniform resource locator (URL). Therefore, each of segments 128 and 132 can be retrieved separately using a streaming network protocol such as DASH. In this way, a destination device such as client device 40 can retrieve segment 128 or 132 using an HTTP GET request. In some examples, client device 40 can retrieve a specific byte range of segment 128 or 132 using an HTTP partial GET request.

[0074] Figure 4 is a block diagram showing elements of an exemplary video file 150 that may correspond to a segment representation similar to one of segments 128 and 132 in Figure 3. Each of segments 128 and 132 may contain data substantially conforming to the data structure shown in the example in Figure 4. The video file 150 can be said to encapsulate segments. As described above, video files according to the ISO-based media file format and its extensions store data within a set of objects called "boxes". In the example in Figure 4, the video file 150 includes a file type (FTYP) box 152, a movie (MOOV) box 154, a segment index (sidx) box 162, a movie fragment (MOOF) box 164, and a movie fragment random access (MFRA) box 166. While Figure 4 represents an example of a video file, it should be understood that other media files may contain other types of media data (e.g., audio data, timed text data, etc.) that are structured similarly to the data in video file 150 according to the ISO-based media file format and its extensions.

[0075] The File Type (FTYP) box 152 generally represents the file type of the video file 150. The File Type box 152 may contain data that identifies specifications representing the best use of the video file 150. Alternatively, the File Type box 152 may be placed before the MOOV box 154, the Movie Fragment box 164, and / or the MFRA box 166.

[0076] In some examples, a segment such as video file 150 may include an MPD update box (not shown) before the FTYP box 152. The MPD update box may include information indicating that the MPD corresponding to the representation containing video file 150 should be updated, along with information for updating the MPD. For example, the MPD update box may provide the URI or URL of the resource used to update the MPD. In another example, the MPD update box may include data for updating the MPD. In some examples, the MPD update box may come immediately after the segment type (STYP) box (not shown) for video file 150, which may define the segment type for video file 150.

[0077] In the example in Figure 4, the MOOV box 154 includes a movie header (MVHD) box 156, a track (TRAK) box 158, and one or more movie extension (MVEX) boxes 160. Generally, the MVHD box 156 may describe the general characteristics of the video file 150. For example, the MVHD box 156 may include data indicating when the video file 150 was first created, data indicating when the video file 150 was last modified, data indicating the timescale of the video file 150, data indicating the playback length of the video file 150, or other data that generally describes the video file 150.

[0078] TRAK box 158 may contain data for a track in video file 150. TRAK box 158 may contain a Track Header (TKHD) box that describes the characteristics of the track corresponding to TRAK box 158. In some examples, TRAK box 158 may contain an encoded video picture, while in other examples, the encoded video picture of the track may be contained within a Movie Fragment box 164, which can be referenced by the data in TRAK box 158 and / or the data in sidx box 162.

[0079] In some examples, video file 150 may contain two or more tracks. Therefore, MOOV box 154 may contain a number of TRAK boxes equal to the number of tracks in video file 150. TRAK box 158 may describe the characteristics of the corresponding track in video file 150. For example, TRAK box 158 may describe the temporal and / or spatial information of the corresponding track. TRAK boxes similar to TRAK box 158 in MOOV box 154 may describe the characteristics of a parameter set track if the encapsulation unit 30 (Figure 3) includes a parameter set track in a video file such as video file 150. The encapsulation unit 30 may signal the presence of a sequence-level SEI message in the parameter set track within the TRAK box describing the parameter set track.

[0080] The MVEX box 160 may, for example, describe the characteristics of the corresponding movie fragment box 164 to signal that the video file 150 contains a movie fragment box 164 in addition to the video data contained within the MOOV box 154, if any. In the context of streaming video data, coded video pictures may be contained within the movie fragment box 164 rather than within the MOOV box 154. Therefore, all coded video samples may be contained within the movie fragment box 164 rather than within the MOOV box 154.

[0081] A MOOV box 154 may contain a number of MVEX boxes 160 equal to the number of movie fragment boxes 164 in the video file 150. Each MVEX box 160 may describe one corresponding characteristic of a movie fragment box 164. For example, each MVEX box may contain a movie extension header box (MEHD) box that describes the duration of one corresponding movie fragment box 164.

[0082] As described above, the encapsulation unit 30 may store a sequence dataset within a video sample that does not contain the actual coded video data. A video sample may generally correspond to an access unit, which is a representation of a coded picture at a particular time instance. In the context of AVC, a coded picture contains one or more VCL NAL units that contain information for constructing all pixels with the access unit and other relevant non-VCL NAL units such as SEI messages. Thus, the encapsulation unit 30 may include a sequence dataset, which may contain sequence-level SEI messages, within one of the movie fragment boxes 164. The encapsulation unit 30 may further signal the presence of the sequence dataset and / or sequence-level SEI messages as existing within one of the movie fragment boxes 164 within one of the MVEX boxes 160 corresponding to one of the movie fragment boxes 164.

[0083] The SIDX box 162 is an optional element of the video file 150. That is, video files conforming to the 3GPP file format or other such file formats do not necessarily contain the SIDX box 162. According to the example of the 3GPP file format, the SIDX box may be used to identify subsegments of a segment (for example, a segment contained within the video file 150). The 3GPP file format defines a subsegment as "a self-contained set of one or more consecutive movie fragment boxes having corresponding media data boxes, wherein the media data box containing the data referenced by the movie fragment box must follow that movie fragment box and precede the next movie fragment box containing information about the same track." The 3GPP file format also indicates that the SIDX box "contains a series of references to subsegments of the (sub)segment documented by the box. The referenced subsegments are consecutive in presentation time. Similarly, the bytes referenced by the segment index box are always consecutive within the segment. The referenced size gives a count of the number of bytes in the referenced material."

[0084] The SIDX box 162 generally provides information representing one or more subsegments of a segment contained within the video file 150. For example, such information may include the playback time at which the subsegment begins and / or ends, a byte offset relative to the subsegment, whether the subsegment contains a stream access point (SAP) (e.g., starts by one), the type of SAP (e.g., whether the SAP is an instantaneous decoder refresh (IDR) picture, a clean random access (CRA) picture, a broken link access (BLA) picture, etc.), the position of the SAP within the subsegment (relative to the playback time and / or byte offset), and so on.

[0085] A movie fragment box 164 may contain one or more coded video pictures. In some examples, a movie fragment box 164 may contain one or more picture groups (GOPs), each of which may contain a number of coded video pictures, such as frames or pictures. In addition, as described above, a movie fragment box 164 may contain a sequence dataset in some examples. Each movie fragment box 164 may contain a movie fragment header box (MFHD, not shown in Figure 4). The MFHD box may describe the characteristics of the corresponding movie fragment, such as the sequence number of the movie fragment. The movie fragment boxes 164 may be included in sequence number order in the video file 150.

[0086] The MFRA box 166 may describe random access points within the movie fragment box 164 of the video file 150. This can assist in performing trick modes, such as performing a search for a specific temporal location (i.e., playback time) within a segment encapsulated by the video file 150. In some examples, the MFRA box 166 is generally optional and does not need to be included in the video file. Similarly, a client device such as the client device 40 does not necessarily need to refer to the MFRA box 166 in order to accurately decode and display the video data of the video file 150. The MFRA box 166 may contain a number of track fragment random access (TFRA) boxes (not shown) equal to the number of tracks in the video file 150, or in some examples, a number of TFRA boxes equal to the number of media tracks (e.g., non-hint tracks) in the video file 150.

[0087] In some examples, a movie fragment box 164 may contain one or more stream access points (SAPs), such as IDR pictures. Similarly, an MFRA box 166 may provide an indication of the SAP's location within the video file 150. Thus, a temporal subsequence of the video file 150 may be formed from the SAPs of the video file 150. The temporal subsequence may also contain other pictures, such as P-frames and / or B-frames, that are dependent on the SAPs. The frames and / or slices of the temporal subsequence may be arranged within a segment so that frames / slice of the temporal subsequence that depend on other frames / slice of the subsequence can be properly decoded. For example, in a hierarchical structure of data, data used for predictions for other data may also be included within a temporal subsequence.

[0088] Figure 5 is a block diagram showing an exemplary system 180 that can implement the techniques of the present disclosure. In this example, system 180 includes a content service provider 182 (which may correspond to the content preparation device 20 in Figure 1), a content distribution network 184 (which may include the server device 60 in Figure 1), a mobile network operator (MNO) 190 (which may be included in the network 74 in Figure 1), and a client device 200 (which may correspond to the client device 40 in Figure 1). In the example of Figure 5, the MNO 190 includes a cache management unit 192 and an access network unit 194, and the client device 200 includes a native application or browser 202 (which may include a web browser, a web browser plugin, and / or other media player application or media streaming application), and a 3GPP standard unit 204 which includes a UE-based cache and management unit 206 and a connectivity unit 208.

[0089] In this example, the native application or browser 202 may act as a streaming application or media player application (for example, corresponding to the media application 112 in Figure 2, which may further include a DASH client), and the 3GPP standard unit 204 may act as a media session handler (MSH). The client device 200 may include an application programming interface (API), such as the M6 ​​API, between the native application or browser 202 and the 3GPP standard unit 204. The M6 ​​API may be extended to include new components representing background data transfers, such as "_backgroundTraffic" or "_backgroundDownload". The API may cover both downlink and uplink commands and data transfers. The M6 ​​API may include API calls such as registerBDT() or registerDownload() and registerUplink(), which register requests for downlink / uplink background data transfers. Parameters may include a list of files, file sizes, desired time, and / or flags indicating whether the MSH or the application is performing the download.

[0090] The M6 ​​API may also include the notifyBDTOpportunity() API call. MSH (for example, of 3GPP Standard Unit 204) may use this callback function to notify a native application or a browser 202 media player application of an opportunity to perform a download. Parameters may include the total traffic volume allocated to this session, the bitrate allocated to the session, and a time window for performing the download.

[0091] The M6 ​​API may further include the notifyBDTComplete() API call. If the registration request indicates that MSH should perform the download, MSH may use this call to notify the media player application that the download is complete. Parameters may include the location of the downloaded content, the size of the downloaded content, and the cache duration for the content.

[0092] In some cases, MSH may receive a special link to perform the download for enhanced security. Also for security reasons, the content may undergo an additional encryption step using a special key available only to media player applications. Furthermore, for extra security, the application provider may distribute a group key to all applications performing BDT downloads.

[0093] MSH may, in some cases, allow the leasing of cache space. Application providers may lease a certain amount of disk space on the UE to cache BDT downloaded content. The amount of space may vary among UEs, but the amount may be discoverable by the media player application.

[0094] Various BDT policy features can also exist. For example, an application provider may define multiple policies and tag them with one or more feature tags. Feature tags may be used to distinguish media quality, for example, 4K vs. FHD vs. HD. 5G Media Streaming Downlink (5GMSd) application features (AF) may track consumption quotas and downgrades to lower policies if quotas are exceeded.

[0095] Figure 6 is a flowchart illustrating an exemplary method for transporting media data using background data transfer according to the technique of this disclosure. While the method in Figure 6 is described with respect to the elements in Figures 1 and 2, it should be understood that other devices, such as the device in Figure 5, may also be configured to implement the technique of this disclosure.

[0096] In some examples of the techniques of this disclosure, a content preparation device 20 and / or a server device 60 may provision a background data transfer (BDT) configuration in a 5G media streaming downlink (5GMSd) application function (AF). Provisioning such a configuration may include providing the 5GMSd AF with information such as the overall data volume for media data, a list of user devices (UEs), a data budget per UE, and one or more geographical areas (220). The 5GMSd AF may contact a device providing a policy and billing function (PCF) to create a new BDT policy (222). The PCF device may respond to the integrated data repository (UDR) with a BDT reference ID for the policy (224). The 5GMSd AF may then confirm to the application provider that a successful BDT policy has been created (226).

[0097] The client device 40 may run a media player application and a media session handler (MSH). The media player application may provide the MSH with data about the need for background data transfer and register a background data transfer request (228). For example, the media player application may provide the MSH with a list of files, their corresponding sizes, and the desired available time. In various examples, the media player application may request the MSH to perform the download using background data transfer, or the media player application may request notification of download opportunities and perform the download itself. If the MSH performs the download itself, after the MSH has performed the download, it may provide the media player application with the download location.

[0098] The MSH may register a request for a BDT download opportunity with the 5GMSd AF (230). The MSH may then provide an application provider identifier or domain name and UE identifier (such as a Public Subscription Identifier (GPSI)). The 5GMSd AF may notify the MSH when a BDT download opportunity is available (232). The 5GMSd AF may also verify the existence of an appropriate BDT policy for its application provider and UE. The 5GMSd AF may directly query the Integrated Data Repository (UDR) to verify the existence of a BDT policy (234). If a BDT policy is found, the 5GMSd AF may identify the BDT reference ID, time window, per-UE data limits, aggregate data, etc. The MSH may then perform the download or trigger a media player application to perform the download. The MSH may also receive data representing the remaining allocation for downloads.

[0099] In one example, the MSH notifies the media player application that a background data transfer opportunity is available (236A). In response, the media player application retrieves the media data content directly from the application provider (238A). In another example, the MSH itself retrieves the media data and then notifies the media player application when the media data retrieval is (fully or partially) complete (236B). In response, the media player application retrieves the media data from the MSH (238B).

[0100] Thus, the method shown in Figure 6 represents an example of a method that includes the steps of: sending a request to a media streaming application function (AF) by one or more processors of a client device to retrieve media data by background data transfer; receiving an instruction for a background data transfer opportunity from the media streaming AF by one or more processors of the client device in response to the request; retrieving media data by background data transfer by one or more processors in response to the instruction for a background data transfer opportunity; and storing the retrieved media data by one or more processors.

[0101] As described above, this disclosure describes a framework that could be used, for example, to implement background data transfer for 5G media delivery. This framework can be seamlessly integrated with existing 5G media streaming architectures. These techniques also allow MNOs to retain control over data volume and download windows. These techniques are also secure and can provide opportunistic retrieval of media content.

[0102] Application providers and MNOs may encourage the use of these techniques to reduce costs and offload traffic to relatively less congested time windows. These techniques may be implemented as part of a media session handler service, which may also be part of the modem's protocol stack. These techniques may be incorporated into the 5G standard.

[0103] Figure 7 is a flowchart illustrating an exemplary method for retrieving media data using the technique of this disclosure. The method in Figure 7 is described with respect to the client device 40 in Figure 1. Other devices, such as the client device 200 in Figure 5, may be configured to perform this or a similar method. The retrieval unit 52 of the client device 40 in Figure 1 may include both a media application and a media session handler (MSH), for example, as shown in Figure 2. The media application and MSH of the retrieval unit 52 of the client device 40 in Figure 1 may perform various elements of Figure 7, which are discussed below.

[0104] First, a media application may request background data transfer for, for example, a specific media presentation (250). The media application may send the request to the MSH. In response, the MSH may register the background data transfer request with the 5GMSd AF (252). The MSH may then receive a notification from the 5GMSd AF of a background data transfer opportunity (254). The notification may include data indicating the time at which the media data for the media presentation can be retrieved via background data transfer.

[0105] In the example in Figure 7, MSH may send data about background data transfer opportunities to the media application (256). The data may indicate, for example, the time when media data for a media presentation can be retrieved via background data transfer. The media application receives the background data transfer opportunity data (258) and may then retrieve the media data via background data transfer (260). For example, the media application may retrieve the media data at the indicated time, which may correspond to an off-peak time window.

[0106] Thus, the method shown in Figure 7 represents an example of a method that includes the steps of: sending a request to a media streaming application function (AF) by one or more processors of a client device to retrieve media data by background data transfer; receiving an instruction for a background data transfer opportunity from the media streaming AF by one or more processors of the client device in response to the request; retrieving media data by background data transfer by one or more processors in response to the instruction for a background data transfer opportunity; and storing the retrieved media data by one or more processors.

[0107] Figure 8 is a flowchart illustrating another exemplary method for retrieving media data using the technique of this disclosure. The method of Figure 8 is described with respect to the client device 40 of Figure 1. Other devices, such as the client device 200 of Figure 5, may be configured to implement this or a similar method. The retrieval unit 52 of the client device 40 of Figure 1 may include both a media application and a media session handler (MSH), for example, as shown in Figure 2. The media application and MSH of the retrieval unit 52 of the client device 40 of Figure 1 may implement the various elements of Figure 8, which are discussed below.

[0108] First, a media application may request background data transfer for, for example, a specific media presentation (280). The media application may send the request to the MSH. In response, the MSH may register the background data transfer request with the 5GMSd AF (282). The MSH may then receive a notification from the 5GMSd AF of a background data transfer opportunity (284). The notification may include data indicating the time at which the media data for the media presentation can be retrieved via background data transfer.

[0109] In the example in Figure 8, the MSH may then retrieve the media data via background data transfer (286). For example, the MSH may retrieve the media data at a time indicated in the notification. The indicated time may correspond to an off-peak time window. After retrieving some or all of the media data for the media presentation, the MSH may send data indicating that the media data has been retrieved and is available to the media application (288).

[0110] A media application may receive a signal from MSH indicating that media data is available (290). In response, at some point thereafter, the media application may retrieve the media data from MSH (292).

[0111] Thus, the method shown in Figure 8 represents an example of a method that includes the steps of: sending a request to a media streaming application function (AF) by one or more processors of a client device to retrieve media data by background data transfer; receiving an instruction for a background data transfer opportunity from the media streaming AF by one or more processors of the client device in response to the request; retrieving media data by background data transfer by one or more processors in response to the instruction for a background data transfer opportunity; and storing the retrieved media data by one or more processors.

[0112] Various examples of the techniques used in this disclosure are summarized in the following clauses.

[0113] Clause 1: A method for retrieving media data, comprising the steps of: sending a request to retrieve media data using background data transfer; receiving instructions for a background data transfer opportunity in response to the request; retrieving media data using background data transfer in response to instructions for a background data transfer opportunity; and storing the retrieved media data.

[0114] Clause 2: The method of Clause 1, wherein the step of retrieving media data using background data transfer includes the step of retrieving media data during an off-peak specified time window.

[0115] Clause 3: Instructions for background data transfer opportunities shall be in accordance with the method of Clause 2, including data defining off-peak designated time windows.

[0116] Clause 4: The step of sending a request to retrieve media data using background data transfer is any of the methods in Clauses 1 to 3, which includes the step of a media session handler performed by the client device sending a request to retrieve media data using background data transfer to the 5G Media Streaming Downlink (5GMSd) application function (AF).

[0117] Clause 5: The step of receiving instructions for a background data transfer opportunity includes any of the methods in Clauses 1 to 4, which includes receiving notification of a background data transfer opportunity by a media session handler performed by the client device.

[0118] Clause 6: The method of Clause 5, further comprising the step of a media session handler sending data representing background data transfer to a media player application running on a client device, and the step of retrieving media data, comprising the step of the media player application retrieving media data using background data transfer.

[0119] Clause 7: The method of Clause 5, wherein the step of retrieving media data using background data transfer includes the step of retrieving media data using background data transfer by a media session handler, and the method further includes the step of the media session handler sending data indicating that media data has been retrieved to a media player application running on a client device, and the media session handler sending the retrieved data to the media player application.

[0120] Clause 8: The step of sending a request includes sending at least one of the following: a list of one or more files of media data to be retrieved, the size of one or more files, or a desired available time for background data transfer, in any manner of Clauses 1-7.

[0121] Clause 9: A device for extracting media data, comprising one or more means for carrying out any of the methods described in Clauses 1 to 8.

[0122] Clause 10: The device of Clause 9, wherein one or more means comprises one or more processors implemented in a circuit mechanism.

[0123] Clause 11: A computer-readable storage medium that stores instructions, when executed, causing a processor to perform any of the methods described in Clauses 1 through 8.

[0124] Clause 12: A device for retrieving media data, comprising means for sending a request to retrieve media data using background data transfer; means for receiving instructions for a background data transfer opportunity in response to the request; means for retrieving media data using background data transfer in response to instructions for a background data transfer opportunity; and means for storing the retrieved media data.

[0125] Clause 13: A method for retrieving media data, comprising the steps of: sending a request to a media streaming application function (AF) by one or more processors of a client device for retrieving media data by background data transfer; receiving an instruction for a background data transfer opportunity from the media streaming AF by one or more processors of the client device in response to the request; retrieving media data by background data transfer by one or more processors in response to the instruction for a background data transfer opportunity; and storing the retrieved media data by one or more processors.

[0126] Clause 14: The method of Clause 13, wherein the step of retrieving media data by background data transfer includes the steps of determining an off-peak designated time window and retrieving media data during the off-peak designated time window.

[0127] Clause 15: The method of Clause 14, wherein the step of determining the off-peak designated time window includes the step of determining the off-peak designated time window from data that defines the off-peak designated time window, which is included in the instructions for background data transfer opportunities.

[0128] Clause 16: The method of Clause 13, wherein the step of sending a request to retrieve media data via background data transfer includes the step of sending a request to retrieve media data via background data transfer to a 5G media streaming downlink (5GMSd) application function (AF) by a media session handler (MSH) performed by one or more processors of the client device.

[0129] Clause 17: The method of Clause 13, wherein the step of receiving instructions for a background data transfer opportunity includes receiving notification of a background data transfer opportunity by a media session handler (MSH) performed by one or more processors of the client device.

[0130] Clause 18: The method of Clause 17, further comprising the step of sending data representing background data transfer by MSH to a media player application running on one or more processors of a client device, wherein the step of retrieving media data includes the step of retrieving media data by background data transfer by the media player application running on one or more processors of a client device.

[0131] Clause 19: The method of Clause 17, wherein the step of retrieving media data by background data transfer includes the step of retrieving media data by background data transfer by an MSH performed by one or more processors of the client device, and the method further includes the step of sending data indicating that media data has been retrieved to a media player application performed by one or more processors of the client device by an MSH performed by one or more processors of the client device, and the step of sending retrieved data to a media player application by an MSH performed by one or more processors of the client device.

[0132] Clause 20: The method of Clause 13, further comprising the step of forming a request to include at least one of the following: a list of one or more files of media data to be retrieved, the size of one or more files, or a desired available time for background data transfer.

[0133] Clause 21: A device for retrieving media data, comprising a memory configured to store media data, and one or more processors implemented in a circuit mechanism, wherein the one or more processors are configured to send a request to a media streaming application function (AF) for retrieving media data by background data transfer, to receive instructions for a background data transfer opportunity from the media streaming AF in response to the request, to retrieve media data by background data transfer in response to the instructions for a background data transfer opportunity, and to store the retrieved media data in memory.

[0134] Clause 22: A device according to Clause 21, in which one or more processors are configured to determine an off-peak designated time window and to retrieve media data during the off-peak designated time window, in order to retrieve media data by background data transfer.

[0135] Clause 23: A device of Clause 22, in which one or more processors are configured to determine an off-peak designated time window from data defining an off-peak designated time window, which is included in the instructions for a background data transfer opportunity.

[0136] Clause 24: In order to send a request to retrieve media data via background data transfer, one or more processors in the device of Clause 21 are configured to execute a media session handler (MSH) configured to send a request to retrieve media data via background data transfer to the 5G media streaming downlink (5GMSd) application function (AF).

[0137] Clause 25: In order to receive instructions for background data transfer opportunities, one or more processors of the device of Clause 21 are configured to execute a media session handler (MSH) configured to receive notifications of background data transfer opportunities.

[0138] Clause 26: The MSH is further configured to send data representing background data transfers to a media player application running on one or more processors, and in order to retrieve media data, the media player application is configured to retrieve media data via background data transfers, as per the device of Clause 25.

[0139] Clause 27: For retrieving media data via background data transfer, the MSH is configured to retrieve media data via background data transfer, and the MSH is further configured to send data indicating that media data has been retrieved to a media player application running on one or more processors of the client device, and to send the retrieved data to the media player application, as per the device of Clause 25.

[0140] Clause 28: The device of Clause 21, further configured to form a request such that one or more processors include at least one of the following: a list of one or more files of media data to be retrieved, the size of one or more files, or a desired available time for background data transfer.

[0141] Clause 29: A computer-readable storage medium storing instructions, which, when executed, causes one or more processors of a client device to send a request to a media streaming application function (AF) to retrieve media data by background data transfer; in response to the request, receive instructions from the media streaming AF for a background data transfer opportunity; in response to the instructions for a background data transfer opportunity, retrieve media data by background data transfer; and store the retrieved media data in memory.

[0142] Clause 30: A computer-readable storage medium as defined in Clause 29, wherein the instruction causing the processor to retrieve media data by background data transfer includes an instruction causing the processor to determine an off-peak designated time window and to retrieve media data during the off-peak designated time window.

[0143] Clause 31: A computer-readable storage medium of Clause 30 that includes instructions causing the processor to determine an off-peak time window, which includes instructions causing the processor to determine an off-peak time window from data defining an off-peak time window, which is included in instructions for background data transfer opportunities.

[0144] Clause 32: A computer-readable storage medium as defined in Clause 29, which includes instructions causing the processor to send a request to retrieve media data via background data transfer, and which also includes instructions causing the processor to execute a media session handler (MSH) to send a request to retrieve media data via background data transfer to a 5G media streaming downlink (5GMSd) application function (AF).

[0145] Clause 33: A computer-readable storage medium as defined in Clause 29, which includes instructions causing the processor to receive instructions for background data transfer opportunities, and which also includes instructions causing the processor to execute a media session handler (MSH) to receive notifications of background data transfer opportunities.

[0146] Clause 34: A computer-readable storage medium of Clause 33, further comprising instructions causing a processor to execute MSH to send data representing background data transfer to a media player application run by one or more processors of a client device, and instructions causing a processor to retrieve media data comprising instructions causing a media player application to execute to retrieve media data by background data transfer.

[0147] Clause 35: A computer-readable storage medium of Clause 33, wherein the instruction to the processor to retrieve media data by background data transfer includes an instruction to the processor to execute MSH to retrieve media data by background data transfer, and further includes an instruction to the processor to execute MSH to send data indicating that media data has been retrieved to a media player application run by one or more processors of a client device, and to execute MSH to send the retrieved data to the media player application.

[0148] Clause 36: The computer-readable storage medium of Clause 29, further comprising structuring the request to include at least one of the following: a list of one or more files of media data to be retrieved, the size of one or more files, or a desired available time for background data transfer.

[0149] Clause 37: A device for retrieving media data, comprising means for sending a request to retrieve media data by background data transfer, means for receiving instructions for a background data transfer opportunity in response to the request, means for retrieving media data by background data transfer in response to instructions for a background data transfer opportunity, and means for storing the retrieved media data.

[0150] Clause 38: A method for retrieving media data, comprising the steps of: sending a request to a media streaming application function (AF) by one or more processors of a client device for retrieving media data by background data transfer; receiving an instruction for a background data transfer opportunity from the media streaming AF by one or more processors of the client device in response to the request; retrieving media data by background data transfer by one or more processors in response to the instruction for a background data transfer opportunity; and storing the retrieved media data by one or more processors.

[0151] Clause 39: The method of Clause 38, wherein the step of retrieving media data by background data transfer includes the steps of determining an off-peak designated time window and retrieving media data during the off-peak designated time window.

[0152] Clause 40: The method of Clause 39, wherein the step of determining an off-peak designated time window includes the step of determining an off-peak designated time window from data that defines an off-peak designated time window, which is included in the instructions for a background data transfer opportunity.

[0153] Clause 41: The step of sending a request to retrieve media data via background data transfer includes any method of Clauses 38-40, wherein a media session handler (MSH) executed by one or more processors of the client device sends a request to retrieve media data via background data transfer to the 5G media streaming downlink (5GMSd) application function (AF).

[0154] Clause 42: The step of receiving instructions for a background data transfer opportunity includes any method of Clauses 38 to 41, wherein the step of receiving notification of a background data transfer opportunity is performed by a media session handler (MSH) executed by one or more processors of the client device.

[0155] Clause 43: The method of Clause 42, further comprising the step of sending data representing background data transfer by MSH to a media player application running on one or more processors of a client device, wherein the step of retrieving media data includes the step of retrieving media data by background data transfer by the media player application running on one or more processors of the client device.

[0156] Clause 44: The method of Clause 42, wherein the step of retrieving media data by background data transfer includes the step of retrieving media data by background data transfer by an MSH performed by one or more processors of the client device, and the method further includes the step of sending data indicating that media data has been retrieved to a media player application performed by one or more processors of the client device by an MSH performed by one or more processors of the client device, and the step of sending retrieved data to a media player application by an MSH performed by one or more processors of the client device.

[0157] Clause 45: Any method of Clauses 38-44, further comprising the step of forming a request to include at least one of the following: a list of one or more files of media data to be retrieved, the size of one or more files, or a desired available time for background data transfer.

[0158] Clause 46: A device for retrieving media data, comprising a memory configured to store media data, and one or more processors implemented in a circuit mechanism, wherein the one or more processors are configured to send a request to a media streaming application function (AF) for retrieving media data by background data transfer, to receive instructions for a background data transfer opportunity from the media streaming AF in response to the request, to retrieve media data by background data transfer in response to the instructions for a background data transfer opportunity, and to store the retrieved media data in memory.

[0159] Clause 47: A device according to Clause 46, in which one or more processors are configured to determine an off-peak designated time window and to retrieve media data during the off-peak designated time window, in order to retrieve media data by background data transfer.

[0160] Clause 48: A device of Clause 47, in which one or more processors are configured to determine an off-peak designated time window from data defining an off-peak designated time window, which is included in the instructions for background data transfer opportunities.

[0161] Clause 49: Any device under Clauses 46-48, wherein one or more processors are configured to execute a media session handler (MSH) configured to send a request to retrieve media data via background data transfer to a 5G media streaming downlink (5GMSd) application function (AF).

[0162] Clause 50: In order to receive instructions for background data transfer opportunities, one or more processors in any device under Clauses 38-49 are configured to execute a media session handler (MSH) configured to receive notifications for background data transfer opportunities.

[0163] Clause 51: The MSH is further configured to send data representing background data transfers to a media player application running on one or more processors, and in order to retrieve media data, the media player application is configured to retrieve media data via background data transfers, as per the device of Clause 50.

[0164] Clause 52: For retrieving media data via background data transfer, the MSH is configured to retrieve media data via background data transfer, and the MSH is further configured to send data indicating that media data has been retrieved to a media player application running on one or more processors of the client device, and to send the retrieved data to the media player application, as per the device of Clause 50.

[0165] Clause 53: Any device of Clauses 38-52, further configured to form a request such that one or more processors include at least one of the following: a list of one or more files of media data to be retrieved, the size of one or more files, or a desired available time for background data transfer.

[0166] Clause 54: A computer-readable storage medium storing instructions, which, when executed, causes one or more processors of a client device to send a request to a media streaming application function (AF) to retrieve media data by background data transfer; in response to the request, receive instructions from the media streaming AF for a background data transfer opportunity; in response to the instructions for a background data transfer opportunity, retrieve media data by background data transfer; and store the retrieved media data in memory.

[0167] Clause 55: A computer-readable storage medium as defined in Clause 54, wherein the instruction causing the processor to retrieve media data by background data transfer includes an instruction causing the processor to determine an off-peak designated time window and to retrieve media data during the off-peak designated time window.

[0168] Clause 56: A computer-readable storage medium of Clause 55 that includes instructions causing the processor to determine an off-peak time window, which includes instructions causing the processor to determine an off-peak time window from data defining an off-peak time window, which is included in instructions for background data transfer opportunities.

[0169] Clause 57: A computer-readable storage medium according to any of Clauses 54-56, which includes an instruction causing the processor to send a request to retrieve media data via background data transfer, and which causes the processor to execute a media session handler (MSH) to send a request to retrieve media data via background data transfer to a 5G media streaming downlink (5GMSd) application function (AF).

[0170] Clause 58: A computer-readable storage medium in any of Clauses 54-57, which includes an instruction causing the processor to receive instructions for background data transfer opportunities, and which includes an instruction causing the processor to execute a media session handler (MSH) to receive notifications of background data transfer opportunities.

[0171] Clause 59: A computer-readable storage medium of Clause 58, further comprising instructions causing a processor to execute MSH to send data representing background data transfer to a media player application run by one or more processors of a client device, and instructions causing a processor to retrieve media data comprising instructions causing a media player application to execute for the processor to retrieve media data via background data transfer.

[0172] Clause 60: A computer-readable storage medium of Clause 58, wherein the instruction to the processor to retrieve media data by background data transfer includes an instruction to the processor to execute MSH to retrieve media data by background data transfer, and further includes an instruction to the processor to execute MSH to send data indicating that media data has been retrieved to a media player application run by one or more processors of a client device, and to execute MSH to send the retrieved data to the media player application.

[0173] Clause 61: A computer-readable storage medium as defined in any of Clauses 54-60, further comprising structuring the request to include at least one of the following: a list of one or more files of media data to be retrieved, the size of one or more files, or a desired available time for background data transfer.

[0174] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on or transmitted through a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may include computer-readable storage media corresponding to tangible media such as data storage media, or it may include communication media, for example, any medium that facilitates the transfer of computer programs from one location to another according to a communication protocol. Thus, the computer-readable medium may generally correspond to (1) non-temporary tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described herein. Computer program products may include computer-readable media.

[0175] As an example, and not an limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Any connection is also appropriately referred to as computer-readable media. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other temporary media, but instead refer to non-temporary tangible storage media. As used herein, "disk" and "disc" include compact discs (CDs), laser discs, optical discs, digital multipurpose discs (DVDs), floppy disks, and Blu-ray discs, where a disk typically reproduces data magnetically, and a disc reproduces data optically using a laser. Any combination of the above should also be included in the scope of computer-readable media.

[0176] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuit mechanisms. Therefore, the term “processor” as used herein may refer to any of the above-described structures or any other structure suitable for implementing the techniques described herein. In addition, in some embodiments, the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a composite codec. Furthermore, the techniques may be fully implemented by one or more circuits or logic elements.

[0177] The techniques of this disclosure can be implemented in a wide variety of devices or apparatus, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to highlight the functional aspects of devices configured to implement the disclosed techniques, but they do not necessarily require implementation by different hardware units. Rather, as described above, various units, along with suitable software and / or firmware, may be combined in a codec hardware unit, including one or more processors described above, or provided by a collection of interoperable hardware units.

[0178] Various examples have been described. These and other examples fall within the scope of the following claims. [Explanation of symbols]

[0179] 10 Systems 20 Content Preparation Devices 22 Audio Sources 24 video sources 26 Audio Encoders 28 Video Encoders 30 encapsulation units 32 output interfaces 40 client devices 42 audio outputs 44 Video Outputs 46 Audio Decoder 48 Video Decoders 50 Decapsulation Units 52 Extraction Unit 54 Network Interfaces 60 server devices 62 Storage medium 64 Multimedia Content 66. Manifest File 68 expression 68A~68N expression 70 Request Processing Units 72 Network Interfaces 74 Networks 100 Media Session Handler (MSH) Units 102 Server Unit, Proxy Server Unit 104 Cache 106 Receiving Unit 112 Media Applications 120 Multimedia Contents 122 Media Presentation Description (MPD) 124 Expression 124A Expression 124N expression 126 Header data 128 segments 128A~128N segments 130 Header data 132 segments 132A~132N segments 150 video files 152 File Type (FTYP) Box 154 Movie Box 156 Movie Header (MVHD) Box 158 TRAK Box 160 Movie Extension (MVEX) Box 162 Segment Index (SIDX) Box 164 Movie Fragment (MOOF) Box 166 Movie Fragment Random Access (MFRA) Box 180 System 182 Content Service Providers 184 Content Distribution Network 190 Mobile Network Operators (MNOs) 192 Cache Management Unit 194 Access Network Unit 204 3GPP standard unit 206 UE-based cache and management units 208 Connectivity Units

Claims

1. A method for extracting media data, The steps include: sending a request to the Media Streaming Application Function (AF) via background data transfer using one or more processors of the client device; In response to the aforementioned request, the client device receives instructions for a background data transfer opportunity from the media streaming AF by one or more processors: In response to the instruction of the background data transfer opportunity, the one or more processors take the step of retrieving the media data by the background data transfer, A method comprising the step of storing the retrieved media data by one or more processors.

2. The step of extracting the media data by the background data transfer is: Steps to determine the off-peak time window, The method according to claim 1, further comprising the step of retrieving the media data during the off-peak designated time window.

3. The method of claim 2, wherein the step of determining the off-peak designated time window includes determining the off-peak designated time window from data defining the off-peak designated time window, which is included in the instruction for the background data transfer opportunity.

4. The method according to claim 1, wherein the step of sending the request to retrieve media data via background data transfer includes sending the request to retrieve media data via background data transfer to a 5G media streaming downlink (5GMSd) application function (AF) by a media session handler (MSH) performed by one or more processors of the client device.

5. The method according to claim 1, wherein the step of receiving the instruction for the background data transfer opportunity includes receiving notification of the background data transfer opportunity by a media session handler (MSH) performed by one or more processors of the client device.

6. The method according to claim 5, further comprising the step of sending data representing the background data transfer by the MSH to a media player application executed by one or more processors of the client device, wherein the step of retrieving the media data includes the step of retrieving the media data by the background data transfer by the media player application executed by one or more processors of the client device.

7. The step of retrieving the media data by background data transfer includes the step of retrieving the media data by background data transfer performed by the MSH executed by one or more processors of the client device, and the method is The steps include: sending data indicating that the media data has been retrieved to a media player application executed by one or more processors of the client device, via the MSH executed by one or more processors of the client device; The method according to claim 5, further comprising the step of sending the retrieved data to the media player application by the MSH performed by the one or more processors of the client device.

8. The method according to claim 1, further comprising the step of forming the request to include at least one of the following: a list of one or more files of the media data to be retrieved, the size of the one or more files, or a desired available time for the background data transfer.

9. A device for extracting media data, A memory configured to store media data, The circuit mechanism comprises one or more processors implemented in the circuit, and the one or more processors are Sending a request to retrieve media data via background data transfer to the media streaming application function (AF), In response to the aforementioned request, the media streaming AF receives instructions for a background data transfer opportunity, In response to the instruction of the background data transfer opportunity, the media data is retrieved by the background data transfer, A device configured to store the extracted media data in the memory.

10. In order to retrieve the media data by the background data transfer, one or more processors Determining the off-peak time window, The device according to claim 9, configured to retrieve the media data during the off-peak specified time window.

11. The device according to claim 10, wherein the one or more processors are configured to determine the off-peak time window from data defining the off-peak time window, which is included in the instructions for the background data transfer opportunity.

12. The device according to claim 9, wherein, in order to send the request for retrieving media data via the background data transfer, one or more processors are configured to execute a media session handler (MSH) configured to send the request for retrieving media data via the background data transfer to a 5G media streaming downlink (5GMSd) application function (AF).

13. The device according to claim 9, wherein, in order to receive the instruction for the background data transfer opportunity, one or more processors are configured to execute a media session handler (MSH) configured to receive notifications for the background data transfer opportunity.

14. The device according to claim 13, wherein the MSH is further configured to send data representing the background data transfer to a media player application executed by the one or more processors, and in order to retrieve the media data, the media player application is configured to retrieve the media data by the background data transfer.

15. In order to retrieve the media data by the background data transfer, the MSH is configured to retrieve the media data by the background data transfer, and the MSH is configured Sending data indicating that the media data has been retrieved to a media player application running on one or more processors of the client device, The device according to claim 13, further configured to send the extracted data to the media player application.

16. The device according to claim 9, wherein the one or more processors are further configured to form the request, including at least one of the following: a list of one or more files of the media data to be retrieved, the size of the one or more files, or a desired available time for the background data transfer.

17. A computer-readable storage medium storing instructions, wherein, when the instructions are executed, one or more processors of a client device are sent to: Sending a request to retrieve media data via background data transfer to the media streaming application function (AF), In response to the aforementioned request, the media streaming AF receives instructions for a background data transfer opportunity, In response to the instruction of the background data transfer opportunity, the media data is retrieved by the background data transfer, A computer-readable storage medium that allows the extracted media data to be stored in the memory.

18. The instruction that causes the processor to retrieve the media data by background data transfer is given to the processor, Determining the off-peak time window, A computer-readable storage medium according to claim 17, comprising an instruction to retrieve the media data during the off-peak designated time window.

19. The computer-readable storage medium according to claim 18, wherein the instruction causing the processor to determine the off-peak time window includes an instruction causing the processor to determine the off-peak time window from data defining the off-peak time window, which is included in the instructions for the background data transfer opportunity.

20. The computer-readable storage medium according to claim 17, wherein the instruction causing the processor to send the request to retrieve media data via background data transfer includes an instruction causing the processor to execute a media session handler (MSH) to send the request to retrieve media data via background data transfer to a 5G media streaming downlink (5GMSd) application function (AF).

21. The computer-readable storage medium according to claim 17, wherein the instruction causing the processor to receive the instruction for the background data transfer opportunity includes an instruction causing the processor to execute a media session handler (MSH) to receive notification of the background data transfer opportunity.

22. The computer-readable storage medium according to claim 21, further comprising an instruction causing the processor to execute the MSH to send data representing the background data transfer to a media player application executed by one or more processors of the client device, wherein the instruction causing the processor to retrieve the media data comprises an instruction causing the processor to execute the media player application to retrieve the media data by the background data transfer.

23. The instruction that causes the processor to retrieve the media data by background data transfer includes an instruction that causes the processor to execute MSH in order to retrieve the media data by background data transfer, To send data indicating that the media data has been retrieved to a media player application running on one or more processors of the client device, the MSH is executed. The computer-readable storage medium according to claim 21, further comprising an instruction causing the MSH to execute in order to send the retrieved data to the media player application.

24. The computer-readable storage medium according to claim 17, further comprising shaping the request to include at least one of the following: a list of one or more files of media data to be retrieved, the size of the one or more files, or a desired available time for the background data transfer.

25. A device for extracting media data, Background data transfer provides a means to send a request to retrieve media data, In response to the aforementioned request, means for receiving instructions for a background data transfer opportunity, In response to the instruction of the background data transfer opportunity, means for retrieving the media data by the background data transfer, A device comprising means for storing the extracted media data.

Images