WO2017100569A1 - Trick mode restrictions for mpeg dash - Google Patents

Abstract

Systems, methods and instrumentalities are disclosed for controlling playback of streaming media content by placing playback restrictions for a time interval within a period of the media content. A type of playback a user selects may be determined. Whether the type of playback the user selects satisifies the playback restrictions in the time interval may be determined. If the type of playback the user is selecting is allowed by the playback restrictions, the media content may be played at the selected playback type. If the type of playback the user selects is disallowed by the playback restrictions, the type of playback the user selects for the media content may be disallowed within the time interval. The playback restrictions may be defined by a DASH event in a MPD file or an inband DASH event.

Description

TRICK MODE RESTRICTIONS FOR MPEG DASH

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of the filing date of U.S. provisional application no. 62/265,216, filed December 9, 2015, which is hereby incorporated by reference as if fully set forth herein.

BACKGROUND

[0002] "Over-the-top" (OTT) streaming utilizes the Internet as a content delivery medium. Network capabilities have evolved to make high-quality video delivery over the Internet viable. There are a wide range of video-capable devices (e.g., mobile devices, Internet set-top boxes (STBs) and network TVs) that utilize OTT streaming.

[0003] The Internet is a "best effort" environment, where bandwidth and latency may be constantly changing, e.g. , as opposed to traditional "closed" networks that may be completely controlled by a multi-system operator (MSO). Network conditions may be highly volatile in mobile networks. Such volatility makes dynamic adaptation to network changes desirable to provide a satisfactory user experience, e.g., viewing streamed content.

SUMMARY

[0004] Systems, methods and instrumentalities are disclosed for controlling playback of streaming media content by placing playback restrictions for a time interval within a period of the media content. A type of playback a user selects may be determined. Whether the type of playback the user selects satisifies the playback restrictions in the time interval may be determined. If the type of playback the user is selecting is allowed by the playback restrictions, the media content may be played at the selected playback type. If the type of playback the user selects is disallowed by the playback restrictions, the type of playback the user selects for the media content may be disallowed within the time interval. The playback restrictions may be defined by a Dynamic Adaptive Streaming over HTTP (DASH) event in a Media Presentation Description (MPD) file or an inband DASH event.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] FIG. 1 is a diagram of an example DASH system. [0006] FIG. 2 is an example of a media content with playback periods and ad break periods.

[0007] FIG. 3A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0008] FIG. 3B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 3A.

[0009] FIG. 3C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 3A.

[0010] FIG. 3D is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG.

3A.

[0011] FIG. 3E is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. 3A.

DETAILED DESCRIPTION

[0012] A detailed description of illustrative embodiments will now be described with reference to the various figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to provide examples and in no way limit the scope of the application. In addition, the figures may illustrate one or more message charts, which are meant to be exemplary. Other embodiments may be used. The order of the messages may be varied where appropriate. Messages may be omitted if not needed, and, additional messages may be added.

[0013] FIG. 1 is a diagram of an example DASH system. HTTP streaming may provide adaptive streaming. HTTP may provide a video transport protocol. The existing extensive HTTP infrastructure, such as content distribution networks (CDNs), as well as the ubiquity of HTTP support on multiple platforms and devices, may make use of HTTP for Internet video streaming more attractive and more scalable than other approaches. For example, while many firewalls disallow UDP traffic, video over HTTP may be available behind firewalls.

[0014] HTTP streaming may be the technology of choice for rate-adaptive streaming. In HTTP adaptive streaming, an asset may be segmented, either virtually or physically, and published to CDNs. Intelligence may reside in the client. The client may acquire knowledge of the published alternative encodings (e.g. , representations) and the way to construct URLs to download a segment from a given representation. A client may observe network conditions, and may decide which combination of bitrate, resolution, etc., will provide best quality of experience on the client device at a (e.g., each) specific instance of time. As the client determines the optimal URL to use, it may issue an HTTP GET request to download a segment.

[0015] Dynamic Adaptive Streaming over HTTP (DASH) may be built on top of a ubiquitous HTTP/TCP/IP stack. DASH may define a manifest format, Media Presentation Description (MPD) and segment formats for ISO Base Media File Format and MPEG-2

Transport Streams. DASH may define a set of quality metrics at network, client operation, and/or media presentation levels. DASH may provide an inter-operable way of monitoring Quality of Experience and Quality of Service.

[0016] In DASH, a representation may be an encoded version of the complete asset, or of a subset of its components. An example representation includes an ISO-BMFF containing unmultiplexed 2.5 Mbps 720p AVC video, and separate ISO-BMFF representations for 96 Kbps MPEG-4 AAC audio in different languages. In an example, a transport stream containing video, audio and subtitles may be a multiplexed representation (e.g. , a single multiplexed

representation). In an example, a combined structure (e.g. , video and English audio) may be a single multiplexed representation, while Spanish and Chinese audio tracks may be separate unmultiplexed representations.

[0017] In DASH, a segment may be a individually addressable unit of media data. A segment may be downloaded using URLs advertised via the MPD. One example of a media segment may be a 4-second part of a live broadcast, which starts at playout time 0:42:38, ends at 0:42:42 and may be available within a 3-min time window. An example of a media segment may be a complete on-demand movie, which may be available for the whole period the movie may be licensed.

[0018] An MPD may be an XML document that advertises available media and provides information needed by the client to select a representation, make adaptation decisions and retrieve segments from the network. An MPD may be completely independent of a segment and may signal (e.g., only signal) properties useful to determine whether a representation may be successfully played and its functional properties (e.g., whether segments start at random access points). An MPD may use a hierarchical data model to describe the complete presentation.

[0019] Representations may be the lowest conceptual level of the hierarchical data model. At this level, an MPD may include/signal information such as bandwidth and codecs for successful presentation, as well as ways of constructing URLs for accessing segments.

Additional information may be provided at this level (e.g. , from trick mode and random access information, to layer and view information for scalable and multiview codecs, to generic schemes that may be supported by a client wishing to play a given representation). [0020] DASH may provide a very rich and flexible URL construction functionality. As opposed to a single monolithic per-segment URL (which may also be possible in DASH), DASH allows dynamic construction of URLs by combining parts of the URL (base URLs) that appear at different levels of the hierarchical data model. As multiple base URLs may be used, segments with multi-path functionality may be possible, with segments requested from more than one location, improving performance and reliability.

[0021] An explicit list of URLs and byte ranges may reach several thousand elements per representation, for example, when short segments are used. This may be inefficient and wasteful, especially in cases where there may be a larger amount of representations. DASH allows using predefined variables (such as, for example, segment number, segment time, etc.) and printf-style syntax for on-the-fly construction of URLs using templates. Instead of listing all segments (e.g., seg_00001. ts, seg_00002. ts, ... , seg_03600. ts, it is enough to write a single line, seg_$ Index%05$ . ts, to express any number of segments, even if they may not be retrieved at the time the MPD may be fetched. Due to template efficiency, multi-segment representations may be required to use templates.

[0022] Different representations of a same asset (and, in the un-multiplexed case, a same component) may be grouped into adaptation sets. The representations within an adaptation set may render the same content, and a client may switch between them, if desired.

[0023] An example of an adaptation set includes a collection of 10 representations with video encoded in different bitrates and resolutions. It may be possible to switch among the representations at a segment (or even a subsegment) granularity, while presenting the same content to the viewer. Under some segment-level restrictions, seamless representation switch may be possible. These restrictions may be required for most practical applications (e.g., required by most DASH profiles, as well as DASH subsets adopted by multiple SDOs). These segment restrictions may be applied to some or alll representations within an adaptation set.

[0024] A period may be a time-limited subset of the presentation. Adaptation sets may be valid (e.g. , are only valid) within the period, and there may be no guarantee that adaptation sets in different periods will contain similar representations (in terms of codecs, bitrates, etc.). An MPD may contain a single period for the whole duration of the asset. Periods may be used for ad markup, where separate periods may be dedicated to parts of the asset itself and to each advertisement.

[0025] MPD may present a hierarchy, starting from global presentation-level properties (e.g., timing), continuing with period-level properties, and adaptation sets available for that period. In an example, representations may be the lowest level of this hierarchy. [0026] DASH may use a simplified version of XLink in order to allow loading parts of the MPD (e.g. , periods) in real time from a remote location. A simple use case for this may be ad insertion, when precise timing of ad breaks may be known ahead of time, whereas ad servers determine the exact ad in real time.

[0027] A dynamic MPD may change and may be periodically reloaded by the client, while a static MPD may be valid for the whole presentation. Static MPDs may be a good fit for VoD applications, whereas dynamic MPDs may be used for live and PVR applications.

[0028] Media segments may be time-bounded parts of a representation, and approximate segment durations appear in the MPD. Segment duration may not be the same for all segments. Segment durations may be close to constant (e.g. , DASH-AVC/264 may use segments with durations within a 25% tolerance margin).

[0029] In a live broadcast scenario, MPD may contain information regarding media segments that are unavailable at the time the MPD may be read by the client. For example, segments may be (e.g. , only) available within a well-defined availability time window, which may be calculated from the wall-clock time and segment duration.

[0030] Index segments may be provided. Index segments may appear as side files, or within the media segments, and may contain timing and random access information. Indexes may make efficient implementation of random access and trick modes. Index segments may be used for more efficient bitstream switching. Indexing may be particularly useful for VoD and PVR type of applications.

[0031] Several segment-level and representation-level properties may be necessary to implement efficient bitstream switching. DASH may provide explicit functional requirements for these, which are expressed in the MPD in a format-independent way. A (e.g., each) segment format specification may contain the format-level restrictions that correspond to these generic requirements.

[0032] Media segment i of representation R may be denoted as <¾,(/), and its duration as

D(S_j^i)). Earliest presentation time may be denoted EPT(S_j^i)). EPT may correspond to the earliest presentation time of the segment, rather than the time at which a segment may be successfully played out at random access.

[0033] Efficient switching may be achieved by time alignment of segments for the representations within an adaptation set. This may be a requirement that for any pair of representation R_Q and ¾ and segment i, EPT(S^ (i))<EPT(S^(i-\))+D(S^(i-\)). This, combined with the requirement that a segment starts with a random access point of certain types, may ensure the ability to switch at segment border without a need for overlapped downloads and dual decoding.

[0034] When indexing may be used, it may be possible to perform bitstream switching at a subsegment level as well, if similar requirements hold for subsegments.

[0035] Most systems require time alignment and random access point placement restrictions. In terms of video encoding, these restrictions may translate into encodings with matching IDR frames at segment borders and closed group of pictures (GOPs).

[0036] As decpited in FIG. 1, a DASH client conceptually may include an access client (e.g. , an HTTP client), a media engine (which may decode and present media provided to it), and an application, to which the access client may passe events. Defined interfaces may include on-the- wire formats of the MPD and segments.

[0037] Timing behavior of a DASH client may be relatively complex. While in Apple HLS all segments mentioned in a manifest are valid, and a client may be polling for new manifests, DASH MPD may reduce the polling behavior by defining MPD update frequency and allowing explicit calculation of segment availability.

[0038] A static MPD may be valid (e.g. , always valid), whereas a dynamic MPD may be valid from the time it was fetched by the client, for an explicitly stated refresh period. An MPD also may have a notion of versioning. For example, an MPD may explicitly expose its publication time.

[0039] An MPD may provide the availability time of the earliest segment of a period, 7^(0).

n-\

For example, media segment n may be available starting from time (¾(/^')),

available for the duration of the timeshift buffer T_f , where the latter may be explicitly stated in an MPD. Availability window size may have a direct impact on the catch-up TV functionality of a DASH deployment. Segment availability time may be relied upon by the access client, e.g. , as long as it falls within the MPD validity period.

[0040] In an example, for any representation R, an MPD may declare bandwidth Bg. The

MPD may define a global minimum buffering time, BT_min. An access client may be able to pass a segment to the media engine after B^xBT_mjn bits are downloaded, thus, given a segment starts with a random access point, the earliest time segment n may be passed to the media engine is T (n)+T^n)+BT ^ where J/i) stands for the download time of segment n. A DASH client may start the play out immediately, e.g. , to minimize delay. An MPD may include a presentation delay (e.g. , as an offset from T^(n)), for example, to ensure synchronization between different clients. Tight synchronization of segment HTTP GET requests may create a thundering herd effect, severely taxing the infrastructure.

[0041] MPD validity and segment availability may be calculated using absolute (e.g. , wall- clock) time. Media time may be expressed within the segments themselves, and in the live case, drift may develop between the encoder and client clocks. This may be addressed at the container level, where both MPEG-2 TS and ISO-BMFF provide synchronization functionality.

[0042] As HTTP may be stateless and client-driven, "push"-style events may be emulated using frequent polls. In ad insertion practice in cable/IPTV systems, upcoming ad breaks may be signaled 3-8 sec. before their start. A straightforward poll-based implementation may be inefficient in this case. Events were designed to address such use cases.

[0043] Events may be associated with (e.g., include) explicit time and duration information and application-specific payloads. Inband events may be small message boxes appearing at the beginning of media segments, while MPD events are a period-level list of timed elements.

DASH may define an MPD validity expiration event, which may identify the earliest MPD version valid after a given presentation time.

[0044] DASH may be agnostic to digital rights management (DRM), and may support signaling DRM scheme and its properties within the MPD. A DRM scheme may be signaled via a ContentProtection descriptor, and an opaque value may be passed within it. In order to signal a DRM scheme, it may be enough to have a unique identifier for a given scheme and to define the meaning of the opaque value. A scheme-specific namespace may be used, e.g. , instead.

[0045] MPEG developed two content protection standards, Common Encryption for ISO- BMFF (CENC) and Segment Encryption and Authentication. Common encryption standardizes which parts of a sample are encrypted, and how encryption metadata may be signaled within a track. This means that the DRM module may be responsible for delivering the keys to the client, given the encryption metadata in the segment, while decryption itself uses standard AES-CTR or AES-CBC modes. The CENC framework may be extensible and may use other encryption algorithms beyond these two, if defined. Common Encryption may be used with several commercial DRM systems, and may be the system used in DASH- Advanced Video Coding (AVC)/264.

[0046] DASH Segment Encryption and Authentication (DASH-SEA) may be agnostic to the segment format. Encryption metadata may be passed via the MPD. For example, MPD may contain information on which key may be used for decryption of a given segment, and how to obtain this key. The baseline system may be equivalent to the one defined in HLS, with AES- CBC encryption and HTTPS-based key transport. This may have a side effect of making MPEG-2 TS media segments compatible with encrypted HLS segments. The standard itself may be very extensible and may allow other encryption algorithms and more DRM systems, e.g. , similar to CENC.

[0047] DASH-SEA may offer a segment authenticity framework. This framework may ensure that the segment received by the client is same as the one the MPD author intended the client to receive. This may be done using MAC or digest algorithms, to prevent content modification within the network (e.g., ad replacement, altering inband events).

[0048] A video system may have normal playback and trick modes (e.g., playback modes or operations other than normal playback). Terminology such as fast forward and rewind refers to content playback regardless of content and content player format (e.g., VCR, DVD, Blu-ray). A digital video system may emulate this functionality using a computer, e.g. , instead of moving parts, to play content. Digital video system playback may be referred to in terms of scale.

[0049] Video content may be encoded at a frame rate of ER frames per second and may be played back at rate of DR frames per second. Scale S may be defined as the ratio between the two, as shown in Eq. 1 :

[0050] A user may (e.g. , most often) view content at the same rate it was captured, which may be referred to as a scale of one (e.g., 1.0).

[0051] TABLE 1 shows an example translation of some trick modes into units of scale.

TABLE 1

[0052] Normal playback time (NPT) may be indicated by a playback clock. NPT may be displayed on a VCR, DVD, Blu-ray player and/or other player user interface. NPT may be expressed in terms of hours hh, minutes mm and seconds ss, e.g., hh:mm:ss, advancing at a scale

S. As indicated in Table 1, playback operations may advance a player between first and second

NPTs of content in the same, more, or less than real-time, which may also be known as wall clock time. A rate of accumulation of wall clock time may be different than a difference between a first and second NPT depending on the playback operation(s) to get from the first NPT to the second NPT. A ratio of accumulation of wall clock time to NPT may be - For normal playback, where the NPT scale S=l.0, the ratio may be 1 : 1 NPT to wall-clock time. For playback pause, the ratio may be infinite. For a 2x fast forward playback operation, the ratio may be ½ or 0.5, where 0.5 seconds of wall clock time accumulate per 1 second of NPT. A seek operation may be an operation in which content at a first time offset (e.g. , NPT=00:00:00) is skipped to a second time offset (e.g. , NPT=00:42:00). Seek may be the same as skip starting from a bookmarked location or starting at an offset when performed at the beginning of a playback session. A bookmark location or offset may be described by an NPT value, although equivalent frame-accurate alternatives may be, for example, SMPTE time code. A seek or skip operation may be defined as playback at an infinitely large scale (e.g. , S=∞), where the rate of accumulation of wall clock time is infinitesimally small (e.g. , assumed to be zero), e.g. , between the skip from NPT 00:00:00 to NPT 00:42:00. A "resume" operation may be defined as changing scale from zero to any non-zero value.

[0053] Ad insertion in video content may be implemented in a variety of ways. In an example, a content provider may allow ad breaks at certain locations of (e.g. , breaks in) content, for example, at a break between two periods of a soccer game. Breaks may be marked up. A service provider may fill breaks with any combination of ads. Targeted ad insertion may occur, for example, when different people see different ads in the same break. The break (or part thereof) that may be filled with ads may be called avail, which may also be known as a placement opportunity or ad pod. An avail may be filled with ads, or all or a portion of an avail may be skipped (e.g. , for video on demand (VoD)). An ad decision may be triggered, for example, when there is a request to fill an avail with actual ads. Ad viewing may be reported to a tracking server.

[0054] Playback speeds may need to be limited. For example, an advertiser may want to disallow fast forward or skipping operations for ad content. As an example, a server may want to limit the maximum speed of fast forward, for example. Higher fast forward speed may necessitate a higher rate of segment downloads, which may strain resources. Moreover, different playback speeds may affect ad insertion behavior, e.g. , an ad may not be shown when an avail occurs during a rewind mode or operation.

[0055] Methods of controlling playback of streaming media content may be provided by placing playback restrictions for a time interval within a period of the media content. A type of playback a user selects may be determined. Whether the type of playback the user selects satisifies the playback restrictions in the time interval may be determined. If the type of playback the user is selecting is allowed by the playback restrictions, the media content may be played at the selected playback type. If the type of playback the user selects is disallowed by the playback restrictions, the type of playback the user selects for the media content may be disallowed within the time interval.

[0056] Trick mode operations (including skip) may be represented as playback scale values.

[0057] A permissible range of scale values may be communicated to DASH clients. A syntax may be used to express a range of scale values. Restrictions may be defined on a Period basis (or on basis of its parts) in an MPD and may be expected to be available at the start time of a DASH period.

[0058] Trick mode restrictions may (e.g., additionally or alternatively) be expressed on a timed basis (e.g. , a dynamic, time varying or just-in-time basis), e.g. , without knowing them ahead of time. Scale restrictions may be enforced and reported, for example, in the context of content viewing restrictions, such as the use of content access tokens, for example.

[0059] Restrictions, which may be represented as scale ranges, may be expressed in DASH events, e.g., DASH MPD events. Time ranges may be expressed using a DASH events' presentation offset and duration. A range of one or more real numbers in the interval between -∞ and +∞ may be represented.

[0060] Values may be represented, e.g. , in a textual format, for example, as a space- separated list of intervals, e.g. , proper or degenerate intervals. A syntax may be used with an interval of real numbers between a and b. A closed interval including a and b may be denoted fa, bj. An open interval excluding a and b may be denoted (a, b). In an example, a degenerate interval comprising only a may be denoted fa,aj.

[0061] Trick mode restrictions (e.g., allowed trick mode operations such as fast forward, rewind and skip and/or scale ranges) may be signaled in DASH, for example, using DASH MPD events and inband events. This may permit stream restrictions to be embedded into an arbitrary place in a stream. Trick mode use or transitions may be reported using DASH events. Trick mode restrictions and reporting may be integrated with token-based content reporting and enforcement. DASH events may be used to enable trick modes and random access to content, e.g., where a server allows viewing main content based on viewing ad content. Systems, methods and/or instrumentalities may be implemented, for example, in MPEG DASH, SCTE DASH, DASH-IF IOP, 3 GPP DASH and/or ATSC 3.0.

[0062] TABLE 2 shows an example of expressing trick mode restrictions in an MPD as an event. The example indicates a 30 second ad with the following scale restrictions: for the first 5 seconds, normal playback (S=l), rewind (S < 0 or -∞), and pause (S=0) are permitted.

Thereafter (e.g., in the last 25 seconds play), fast forward and skip are also permitted. Note that playing forward in slow motion (0.00 < S < 1.0) would not be allowed in this example.

TABLE 2

<MPD ... >

<Period id="l" duration=" PT30.03S >

<Eventstream

schemeIdUri="urn: mpeg : dash : stream-restrictions : 2016" timescale="l" value="l">

<Event presentationTime=" 0 " duration="5" id="0" messageData=" [-lnf,0], [1,1] "/>

<Event presentationTime="5" id="l" messageData=" [-Inf, 0]

[l,Inf]"/>

</EventStream>

</ PD>

[0063] In an example, a negation operator may be added, for example, to mark certain values as explicitly excluded, e.g. , compared to writing them as a set of disjointed sets. For example, a prohibition on pause may be indicated by " ! [0,0]," e.g. , compared to "[-lnf,0) (0,lnf]."

[0064] An event may be assumed to apply to the remaining period, for example, when Event@duration is not specified.

[0065] Multiple instances of Event element within the same EventStream may have

Event@id values that match. In an example where Event@id values match, the later event may entirely supersede the previous Event. Matching Event@id values may be used to cancel an event, e.g. , an empty or absent Event@messageData may indicate a lack of restrictions.

[0066] Multiple instances of Event element within the same EventStream may have

Event@id values that differ while having overlapping time ranges. In an example where a second event applies to a time range when a first event is still valid (e.g., sum of

Event@presentationTime and Event@duration of the first event is less than

Event@presentationTime of the second event), restrictions from both events may be applicable during the time they intersect. In an example, a scale range permitted by a first event but prohibited by the second event may be allowed during an intersection.

[0067] Restriction information may be carried in inband dash events, e.g., in addition to or alternative to restrictions that may be expressed in DASH MPD events.

[0068] TABLE 3 shows an example implementation that defines a structure for use in an ^' emsg^' .message_data[] field of a stream restriction event. TABLE 3

aligned (8) struct StreamRestriction

{

unsigned int(8) num_ranges ;

for (i=0; i<num_scales ; i++)

{

int(l) open_start;

int ( 1) open_end;

int ( 1) degenerate ;

int (5) reserved;

// permissible scale value(s) as IEEE 75416-bit floating point numbers binaryl6 min_scale;

if ( ! degenerate) {

binaryl6 max_scale

}

}

}

[0069] Validity ranges may be expressed for inband DASH events, e.g. , using the same or similar logic for expressing validity ranges for DASH MPD events. In an example, ^λ emsg^' .presentation_time_delta and ^λ emsg\event_duration may be used to express a time range within the period to which the restriction applies. In an example, ^λ emsg^' .id may be used to enforce validity and cancelation rules.

[0070] Trick mode transitions may be reported. Data on user actions taken while viewing content may be reported and may be used. In an example, an advertiser may be interested in knowing at which point a viewer/user decided to skip an ad or to rewind an ad to a particular time or point, perhaps indicating something caught a viewer's attention.

[0071] In an example, trick mode transition reporting may be implemented similar to a DASH callback event defined in ISO/IEC 23009-1 :2014 AMD3. Reporting may use

Event@messageData (e.g. , for MPD event) or ^λ emsg^' .message_data[] (e.g. , for inband event), for example, to carry a URL to a tracking server. An HTTP GET to a specified URL may be issued at the presentation time of the event.

[0072] Reporting of trick mode events (e.g. , "trickmode callback events") may be implemented in several ways. In a first example, a URL may be carried (e.g., may be relayed to the client in an MPD, an event or in other signaling) and an HTTP GET to that URL may be triggered (e.g. , may be sent by the client), for example, when scale (e.g. , playback speed) changes. In an example, a more informative extension may be to also carry in the URL or in a custom HTTP header a value of the new scale. In an example, a different implementation may allow or assign different URLs for different modes. For example, different URLs may be used for pause, rewind, fast forward and skip. URLs may optionally contain the value of the new scale. One or more examples (e.g., using different URLs for different purposes or modes) may be compatible with IAB Digital Video Ad Serving Template (VAST).

[0073] In an example, an additional extension to this model is carrying the time relative to the start of the period until the point in the presentation timeline at which the transition between scale values occurred (e.g., NPT time at the scale change point). A value may be carried within a URL or in a custom HTTP header.

[0074] Trick mode restrictions and/or reporting may be integrated with token-based content playback enforcement.

[0075] FIG. 2 is a diagram of an example of media content periods with breaks for ad content. For example, a single movie may be split into three movie periods Ml, M2, M3 with ad breaks Al, A2 and A3 preceding them, respectively.

[0076] In an example, playback of Ml may require playback of Al . One or more tokens may be used to enforce such playback requirements. Tokens may be used to access and/or playback content. A token may or may not indicate a prerequisite action (e.g. , normal playback) was taken with a prerequisite content (e.g. , Al). Access and/or quality of other content (e.g., Ml) may be denied or otherwise restricted (e.g., based on quality of available versions), for example, when one or more prerequisites (e.g. , normal playback of Al) are not satisfied, e.g., according to an ad tracking server that receives ad reports, which may originate from DASH clients.

[0077] During normal playback, Al may play back before Ml . However, a trick mode may seek or fast forward into the middle of Ml or may fast-forward into M2. A prerequisite for access to or playback of Ml may be normal playback of one or more ads, e.g. , A2. Trick mode callback events may be used, for example, by integrating them with token acquisition.

[0078] A trick mode callback event may occur in response to a trick operation/event, e.g. , seeking into M2. A trick mode callback event may be associated with a specific URL. A callback event may be implemented by issuing an HTTP GET message to the specified URL. A token may be acquired in a response to a trick mode callback event. For example, a token may be provided in an HTTP response header. The token may be used in subsequent requests for content.

[0079] A parameter passing framework may implemented. An example of a parameter passing framework is described in ISO/IEC 23009-1 AMD3 Annex I. For example, a parameter named "overri de-token" may be instantiated from an HTTP response header for a trick mode callback event. The instantiated parameter may be used in a subsequent HTTP GET in XLink resolution or/and segment request.

[0080] In an example, a content author may allow skipping ad A2, for example, when a viewer fast forwards from a start of Ml, over Ml and to M2. A content author may require playback of A2, for example, when A2 is encountered or reached while playing at normal speed (S = 1.0) , e.g., normal playback. An example implementation (e.g. , sequence of events) based on such authored content is provided below. Other implementations with the same, different, more or fewer interactions are possible for the same or similar content.

[0081] In an example, at NPT of 00: 10:00 (the 10^th minute of Ml), a viewer/user presses a fast forward button, switching to 32x playback speed (a scale S of 32.0).

[0082] A trick mode callback event may be executed. An HTTP GET may be issued to a URL specified in or for the trick mode callback event (e.g., 32 scale playback). For example, an HTTP GET may be issued to a URL that indicates fast forward trick mode. The HTTP GET may include the scale value 32 as an HTTP header within the GET request. Other information, e.g. , one or more identifiers (client identifier, session identifier and/or content identifier) may also be provided in or with the HTTP GET request.

[0083] An HTTP response to this event may contain a value for parameter T, e.g. , a token. An HTTP request for an XLink resolution of A2 may contain a value of T. The server may return an empty period for A2. Subsequent requests to media segments within M2 may carry the value of T. The server may determine that there is no evidence of viewing or downloading prerequisite content A2, but may determine that the value of T in the request permits media segment download. Playback at scale 32 may continue until the user changes playback, for example, at 00:20:00 (the 5^th minute of M2) the user presses a play button.

[0084] A trick mode callback event may be executed, e.g. , because the scale value changed. An HTTP GET may be issued to the URL specified in the trick mode callback event. An HTTP response to this event may contain a value for parameter T (e.g., T2). The value of T2 may be new (changed) relative to a previous value of T. Subsequent requests to media segments within M2 may carry the value of T2 provided in the most recent HTTP response to a callback event message. The server may determine that there is no evidence of viewing or downloading prerequisite content A2, but may determine that the value of T2 in the request permits media segment download.

[0085] Various server-side implementations for the foregoing example scenario may or may not keep session state on the server side (e.g., in a database). A content author or service provider may, for example, have a generic rule that there may be no advertisement during trick modes. This may be implemented, for example, as stateless logic where a token Tl may be identified as a permission to download further content. Tighter control may be implemented, for example, when token Tl allows access to (e.g. , only) a subset of representations, such as audio- less (video only) content at lfps.

[0086] Token values may be defined by an implementation. Examples of options that may be used in defining token values are issuance and/or expiry times, client and/or IP identification, for example, to prevent a "replay attack." Token values may be transmitted unencrypted or encrypted (e.g., using AES) and/or replaced by a hash or signature (such as SHA or SHA- HMAC).

[0087] FIG. 3 A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0088] As shown in FIG. 3 A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like. A DASH client may be run on a WTRU.

[0089] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0090] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

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

[0092] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

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

[0094] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for

Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0095] The base station 114b in FIG. 3 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A) to establish a picocell or femtocell. As shown in FIG. 3 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0096] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 3 A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0097] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

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

[0099] FIG. 3B is a system diagram of an example WTRU 102. As shown in FIG. 3B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB or HeNodeB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 3B and described herein.

[0100] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG. 3B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip. [0101] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g. , base station 114a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0102] In addition, although the transmit/receive element 122 is depicted in FIG. 3B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g. , multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

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

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

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

[0106] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g. , base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination implementation while remaining consistent with an embodiment.

[0107] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0108] FIG. 3C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. The RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115. The RAN 103 may also be in

communication with the core network 106. As shown in FIG. 3C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0109] As shown in FIG. 3C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0110] The core network 106 shown in FIG. 3C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0111] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0112] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0113] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0114] FIG. 3D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

[0116] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 3D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface. [0117] The core network 107 shown in FIG. 3D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0118] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer

activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0119] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0120] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0121] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0122] FIG. 3E is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0123] As shown in FIG. 3E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0124] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication,

authorization, IP host configuration management, and/or mobility management.

[0125] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0126] As shown in FIG. 3E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0127] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0128] Although not shown in FIG. 3E, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0129] Systems, methods and instrumentalities have been disclosed for trick mode restrictions for Dynamic Adaptive Streaming over HTTP (DASH). Trick mode restrictions (e.g. , allowed trick mode operations such as fast forward, rewind and skip and/or scale ranges) may be signaled in DASH, for example, using DASH MPD events and inband events. This may permit stream restrictions to be embedded into an arbitrary place in a stream, e.g. , compared to announcing restrictions in advance at a period level in an MPD. Trick mode use or transitions may be reported using DASH events. Trick mode restrictions and reporting may be integrated with token-based content reporting and enforcement. DASH events may be used to enable trick modes and random access to content, e.g., where a server allows viewing main content based on viewing ad content. Systems, methods and/or instrumentalities may be implemented, for example, in MPEG DASH, SCTE DASH, DASH-IF IOP, 3 GPP DASH, and/or ATSC 3.0.

[0130] The processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, intemal hard disks and removable disks, magneto-optical media, and/or optical media such as CD-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, and/or any host computer.

Claims

1. A method of controlling playback of streaming media content on a WTRU, comprising: receiving a period of the media content, the period containing playback restrictions for a time interval within the period;

determining what type of playback a user of the WTRU selects;

determining whether the type of playback the user of the WTRU selects satisifies the playback restrictions in the time interval; and

upon determining the type of playback the user of the WTRU is selecting is allowed by the playback restrictions, playing the media content, or

upon determining the type of playback the user of the WTRU selects is disallowed by the playback restrictions, disallowing the type of playback the user of the WTRU selects for the media content within the time interval.

2. The method of claim 1, wherein the playback restrictions are defined by a Dynamic Adaptive Streaming over HTTP (DASH) event in a Media Presentation Description (MPD) file.

3. The method of claim 1, wherein the playback restrictions are defined by an inband DASH event.

4. The method of claim 1, wherein the time interval does not occur at the start time of the period.

5. The method of claim 1, wherein the type of playback the user of the WTRU selects is represented by a playback scale value, wherein a playback scale value of 1.0 corresponds to forward playback at a normal speed, a playback scale value greater than 1.0 corresponds to forward playback at a faster than normal speed, a playback scale value less than 1.0 corresponds to forward playback at a slower than normal speed, and a playback scale value of 0 corresponds to a pause in playback.

6. The method of claim 5, wherein the playback restrictions define permissible playback scale values.

7. The method of claim 5, wherein the playback restrictions specifically exclude one or more playback scale values.

8. The method of claim 1, wherein the time interval contains an advertisement.

9. The method of claim 1, further comprising, during playback of the media content, detecting a change in a playback speed a user of the WTRU selects from a first playback scale value to a second playback scale value; and sending a message reporting the same.

10. The method of claim 9, further comprising determining a time from the start of the period to the time of the change from the first playback scale value to the second playback scale value.

11. The method of claim 9, further comprising associating a portion of the media content with the change from the first playback scale value to the second playback scale value.

12. The method of claim 1, further comprising determining that the WTRU was in compliance for playback restrictions for the period, and if so, sending a message reporting the same, and allowing playback of another period.

13. A WTRU, comprising:

a processor for controlling playback of streaming media content, the processor configured to:

receive a period of the media content, the period containing playback restrictions for a time interval within the period;

determine what type of playback a user of the WTRU selects;

determine whether the type of playback the user of the WTRU selects satisifies the playback restrictions in the time interval; and

upon determining the type of playback the user of the WTRU selects is allowed by the playback restrictions, play the media content, or

upon determining the type of playback the user of the WTRU selects is disallowed bythe playback restrictions, disallow the type of playback the user of the WTRU selects for the media content within the time interval.

14. The WTRU of claim 13, wherein the playback restrictions are defined by a DASH event in a MPD file.

15. The WTRU of claim 13, wherein the playback restrictions are defined by an inband DASH event.

16. The WTRU of claim 13, wherein the time interval does not occur at the start time of the period.

17. The WTRU of claim 13, wherein the type of playback the user of the WTRU selects is represented by a playback scale value, wherein a playback scale value of 1.0 corresponds to forward playback at a normal speed, a playback scale value greater than 1.0 corresponds to forward playback at a faster than normal speed, a playback scale value less than 1.0 corresponds to forward playback at a slower than normal speed, and a playback scale value of 0 corresponds to a pause in playback.

18. The WTRU of claim 17, wherein the playback restrictions define permissible playback scale values.

19. The WTRU of claim 17, wherein the playback restrictions specifically exclude one or more playback scale values.

20. The WTRU of claim 13, wherein the time interval contains an advertisement.

21. The WTRU of claim 13, wherein the processor is further configured to, during playback of the media content, detect a change in a playback speed a user of the WTRU selects from a first playback scale value to a second playback scale value, and send a message reporting the same.

22. The WTRU of claim 21, wherein the processor is further configured to determine a time from the start of the period to the time of the change from the first playback scale value to the second playback scale value.

23. The WTRU of claim 21, wherein the processor is further configured to associate a portion of the media content with the change from the first playback scale value to the second playback scale value.

24. The WTRU of claim 13, wherein the processor is further configured to determine that the WTRU was in compliance for playback restrictions for the period, and if so, sending a message reporting the same, and allowing playback of another period.

25. A method of controlling playback of streaming media content on a WTRU, comprising: receiving a period of the media content, the period containing playback restrictions for a time interval within the period, wherein the playback restrictions are defined by a DASH event in a MPD file or an inband DASH event;

determining what type of playback a user of the WTRU selects;

determining whether the type of playback the user of the WTRU selects satisifies the playback restrictions in the time interval; and

upon determining the type of playback the user of the WTRU selects is disallowed by the playback restrictions, disallowing the type of playback the user of the WTRU selects for the media content within the time interval.