U.S. patent application number 14/153869 was filed with the patent office on 2014-07-17 for supporting transport diversity and time-shifted buffers for media streaming over a network.
This patent application is currently assigned to QUALCOMM Incorporated. The applicant listed for this patent is QUALCOMM Incorporated. Invention is credited to Ralph Akram Gholmieh, Chaitali Gupta, Nagaraju Naik, Carlos Marcelo Dias Pazos.
Application Number | 20140199044 14/153869 |
Document ID | / |
Family ID | 51165207 |
Filed Date | 2014-07-17 |
United States Patent
Application |
20140199044 |
Kind Code |
A1 |
Gupta; Chaitali ; et
al. |
July 17, 2014 |
SUPPORTING TRANSPORT DIVERSITY AND TIME-SHIFTED BUFFERS FOR MEDIA
STREAMING OVER A NETWORK
Abstract
A device for processing media data includes one or more
processors configured to receive a session description protocol
(SDP) message including an attribute that defines a time-shifted
buffer (TSB) depth, determine an amount of memory for the TSB based
on a value of the attribute, allocate the determined amount of
memory to the TSB, and store at least a portion of media data
associated with the SDP message in the TSB. The value for the
attribute may signal the depth of the TSB in terms of playback time
in seconds. The attribute may leverage the extensibility of SDP
messages through, for instance, "a=" lines. For instance, the TSB
depth attribute may correspond to an "a=tsb-length:" attribute.
Inventors: |
Gupta; Chaitali; (San Diego,
CA) ; Naik; Nagaraju; (San Diego, CA) ; Pazos;
Carlos Marcelo Dias; (Carlsbad, CA) ; Gholmieh; Ralph
Akram; (San Diego, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
QUALCOMM Incorporated |
San Diego |
CA |
US |
|
|
Assignee: |
QUALCOMM Incorporated
San Diego
CA
|
Family ID: |
51165207 |
Appl. No.: |
14/153869 |
Filed: |
January 13, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61752456 |
Jan 15, 2013 |
|
|
|
61809871 |
Apr 8, 2013 |
|
|
|
Current U.S.
Class: |
386/239 ;
709/217 |
Current CPC
Class: |
H04L 67/1097 20130101;
H04W 4/18 20130101; H04L 67/2814 20130101; H04N 5/91 20130101; H04L
67/10 20130101; H04L 67/2842 20130101; H04L 65/4076 20130101; H04L
65/608 20130101; H04L 65/4084 20130101 |
Class at
Publication: |
386/239 ;
709/217 |
International
Class: |
H04N 5/91 20060101
H04N005/91; H04L 29/06 20060101 H04L029/06 |
Claims
1. A method of processing media data, the method comprising:
receiving a session description protocol (SDP) message including an
attribute that defines a time-shifted buffer (TSB) depth;
determining an amount of memory for the TSB based on a value of the
attribute; allocating the determined amount of memory to the TSB;
and storing at least a portion of media data associated with the
SDP message in the TSB.
2. The method of claim 1, wherein receiving comprises receiving the
SDP message in accordance with one of real-time transport protocol
(RTP) and real-time streaming protocol (RTSP).
3. The method of claim 1, wherein the attribute comprises an
"a=tsb-length:" attribute.
4. The method of claim 1, wherein the value of the attribute
defines a length of the TSB.
5. The method of claim 4, wherein the value for the attribute
defines the length in terms of seconds of playback for media data
stored in the TSB.
6. The method of claim 1, wherein determining the amount of memory
comprises determining the amount of memory based at least in part
on a frame rate for media data associated with the SDP.
7. The method of claim 1, further comprising extracting at least a
portion of the stored media data from the TSB to perform trick mode
playback.
8. The method of claim 7, wherein the trick mode comprises one of
fast forward and rewind.
9. The method of claim 1, wherein the SDP message comprises an SDP
message for one of a broadcast SDP session and a unicast SDP
session.
10. The method of claim 1, wherein the SDP message comprises a
unicast session description and a broadcast session
description.
11. The method of claim 10, wherein the SDP message includes
attributes associated with identifiers of various sets of media
data, wherein the attributes indicate whether the associated media
data correspond to a broadcast media stream or a unicast media
stream.
12. The method of claim 11, wherein the attributes comprise
respective "a=group:" attributes.
13. The method of claim 10, wherein the SDP message includes
attributes that distinctly identify each media stream.
14. The method of claim 13, wherein the attributes that distinctly
identify each media stream comprise "a=mid:" identification tags,
each having unique identifier values.
15. The method of claim 1, wherein allocating comprises allocating
the determined amount of memory of a multicast services device
client (MSDC) to the TSB.
16. A device for processing media data, the device comprising one
or more processors configured to receive a session description
protocol (SDP) message including an attribute that defines a
time-shifted buffer (TSB) depth, determine an amount of memory for
the TSB based on a value of the attribute, allocate the determined
amount of memory to the TSB, and store at least a portion of media
data associated with the SDP message in the TSB.
17. A computer-readable storage medium having stored thereon
instructions that, when executed, cause a processor to: receive a
session description protocol (SDP) message including an attribute
that defines a time-shifted buffer (TSB) depth; determine an amount
of memory for the TSB based on a value of the attribute; allocate
the determined amount of memory to the TSB; and store at least a
portion of media data associated with the SDP message in the TSB.
Description
[0001] This application claims the benefit of U.S. Provisional
Application Ser. No. 61/752,456, filed Jan. 15, 2013, and U.S.
Provisional Application Ser. No. 61/809,871 filed Apr. 8, 2013, the
entire contents of each of which are hereby incorporated by
reference.
TECHNICAL FIELD
[0002] This disclosure relate to communication systems, and more
particularly, to delivery of content via a network.
BACKGROUND
[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 gaming
devices, video game consoles, cellular or satellite radio
telephones, video teleconferencing devices, and the like. Digital
video devices implement video compression techniques, such as those
described in the standards defined by MPEG-2, MPEG-4, ITU-T H.263
or ITU-T H.264/MPEG-4, Part 10, Advanced Video Coding (AVC), and
extensions of such standards, to transmit and receive digital video
information more efficiently.
[0004] Video compression techniques perform spatial prediction
and/or temporal prediction to reduce or remove redundancy inherent
in video sequences. For block-based video coding, a video frame or
slice may be partitioned into blocks. Each block can be further
partitioned. Blocks in an intra-coded (I) frame or slice are
encoded using spatial prediction with respect to neighboring
blocks. Blocks in an inter-coded (P or B) frame or slice may use
spatial prediction with respect to neighboring blocks in the same
frame or slice or temporal prediction with respect to other
reference frames.
[0005] After video data has been encoded, the video data may be
packetized for transmission or storage. The video data may be
assembled into a video file conforming to any of a variety of
standards, such as the International Organization for
Standardization (ISO) base media file format and extensions
thereof, such as AVC.
[0006] Wireless communication networks are widely deployed to
provide various communication services such as voice, video, packet
data, messaging, broadcast, etc. These wireless networks may be
multiple-access networks capable of supporting multiple users by
sharing the available network resources. Examples of such
multiple-access networks include Code Division Multiple Access
(CDMA) networks, Time Division Multiple Access (TDMA) networks,
Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA
(OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks.
[0007] The 3rd Generation Partnership Project (3GPP) Long Term
Evolution (LTE) represents a major advance in cellular technology
as an evolution of Global System for Mobile communications (GSM)
and Universal Mobile Telecommunications System (UMTS). The LTE
physical layer (PHY) provides a highly efficient way to convey both
data and control information between base stations, such as an
evolved Node Bs (eNBs), and mobile devices, such as UEs. In prior
applications, a method for facilitating high bandwidth
communication for multimedia has been single frequency network
(SFN) operation. SFNs utilize radio transmitters, such as, for
example, eNBs, to communicate with subscriber UEs. In unicast
operation, each eNB is controlled so as to transmit signals
carrying information directed to one or more particular subscriber
UEs. The specificity of unicast signaling enables person-to-person
services such as, for example, voice calling, text messaging, or
video calling.
SUMMARY
[0008] In general, this disclosure describes techniques for
streaming media data over a network. For example, this disclosure
describes techniques for receiving media data via various types of
transports, e.g., any of unicast, broadcast, and/or multicast. For
instance, a redirector/proxy unit may cause a streaming client to
retrieve media data from the Internet directly via unicast, or when
a broadcast or multicast service is available, from a broadcast or
multicast middleware unit. Alternatively, the redirector/proxy unit
may retrieve the media data on behalf of the streaming client when
the broadcast or multicast service is not available.
[0009] This disclosure also describes techniques related to
buffering retrieved media data. For instance, retrieved media data
may be stored in a time-shifted buffer (TSB). This disclosure
describes techniques for signaling a size of the TSB, e.g., in
terms of playback time for the media content, such that an
appropriate amount of memory can be allocated for the TSB. In this
manner, the media data can be played back at a later time and/or
played back using a trick mode, e.g., fast forward or rewind.
[0010] In one example, a method of retrieving media data includes,
by a proxy unit: obtaining mapping information that maps an
identifier for media data to a resource location based on a service
for retrieving the media data, wherein the service defines a type
of transport for transporting the media data, receiving a request
for the media data from a streaming client, determining whether the
service is available, and, when the service is available, causing
the streaming client to receive the media data from a unit that
receives the media data using the service from the resource
location, based on the mapping information.
[0011] In another example, a device for retrieving media data
includes a proxy unit configured to obtain mapping information that
maps an identifier for media data to a resource location based on a
service for retrieving the media data, wherein the service defines
a type of transport for transporting the media data, receive a
request for the media data from a streaming client, determine
whether the service is available, and, when the service is
available, cause the streaming client to receive the media data
from a unit that receives the media data using the service from the
resource location, based on the mapping information.
[0012] In another example, a device for retrieving media data
includes means for obtaining mapping information that maps an
identifier for media data to a resource location based on a service
for retrieving the media data, wherein the service defines a type
of transport for transporting the media data, means for receiving a
request for the media data from a streaming client, means for
determining whether the service is available, and means for
causing, when the service is available, the streaming client to
receive the media data from a unit that receives the media data
using the service from the resource location, based on the mapping
information.
[0013] In another example, a computer-readable storage medium has
stored thereon instructions that, when executed, cause a processor
to obtain mapping information that maps an identifier for media
data to a resource location based on a service for retrieving the
media data, wherein the service defines a type of transport for
transporting the media data, receive a request for the media data
from a streaming client, determine whether the service is
available, and cause, when the service is available, the streaming
client to receive the media data from a unit that receives the
media data using the service from the resource location, based on
the mapping information.
[0014] In another example, a method of processing media data
includes receiving a session description protocol (SDP) message
including an attribute that defines a time-shifted buffer (TSB)
depth, determining an amount of memory for the TSB based on a value
of the attribute, allocating the determined amount of memory to the
TSB, and storing at least a portion of media data associated with
the SDP message in the TSB.
[0015] In another example, a device for processing media data
includes one or more processors configured to receive a session
description protocol (SDP) message including an attribute that
defines a time-shifted buffer (TSB) depth, determine an amount of
memory for the TSB based on a value of the attribute, allocate the
determined amount of memory to the TSB, and store at least a
portion of media data associated with the SDP message in the
TSB.
[0016] In another example, a device for processing media data
includes means for receiving a session description protocol (SDP)
message including an attribute that defines a time-shifted buffer
(TSB) depth, means for determining an amount of memory for the TSB
based on a value of the attribute, means for allocating the
determined amount of memory to the TSB, and means for storing at
least a portion of media data associated with the SDP message in
the TSB.
[0017] In another example, a computer-readable storage medium
having stored thereon instructions that, when executed, cause a
processor to receive a session description protocol (SDP) message
including an attribute that defines a time-shifted buffer (TSB)
depth, determine an amount of memory for the TSB based on a value
of the attribute, allocate the determined amount of memory to the
TSB, and store at least a portion of media data associated with the
SDP message in the TSB.
BRIEF DESCRIPTION OF DRAWINGS
[0018] FIG. 1 illustrates an example system for supporting
transport diversity.
[0019] FIGS. 2A-2B illustrate alternative examples of apparatus
including a re-director/proxy for supporting transport
diversity.
[0020] FIG. 3 illustrates aspects of an example process flow using
a re-director/proxy configured for re-direction operation.
[0021] FIG. 4 illustrates aspects of a method using a
re-director/proxy configured for proxy operation.
[0022] FIG. 5 illustrates examples of a methodology for supporting
transport diversity.
[0023] FIG. 6 illustrates an example apparatus for implementing the
methodology of FIG. 5.
[0024] FIGS. 7 and 8 illustrate further aspects for supporting
transport diversity.
[0025] FIGS. 9 and 10 are block diagrams illustrating example
multicast services device client (MSDC) architectures for
supporting Real-Time Transport Protocol (RTP)/Real-Time Streaming
Protocol (RTSP) streaming.
[0026] FIG. 11 is a conceptual diagram illustrating an example
evolved MBMS (eMBMS) user service description (USD) schema
snippet.
[0027] FIGS. 12 and 13 are block diagrams illustrating example
components for supporting transport diversity for an RTSP/RTP
client.
[0028] FIGS. 14A and 14B are conceptual diagrams illustrating an
example extensible markup language (XML) content model for
extending a USD to carry dynamic adaptive streaming over HTTP
(DASH) Transport information.
[0029] FIG. 15 is a conceptual diagram illustrating an example
architecture for supporting DASH over MBMS.
[0030] FIG. 16 is a flow diagram illustrating a call-flow
associated with the network architecture of FIG. 15 for DASH
content delivery over broadcast and unicast transport.
[0031] FIG. 17 is a conceptual diagram illustrating another example
architecture for supporting DASH over MBMS.
[0032] FIGS. 18-23 are flow diagrams illustrating various example
call-flows associated with the network architecture of FIG. 17 for
DASH content delivery over broadcast and unicast transport.
[0033] FIG. 24 is a flowchart illustrating an example method for
signaling data related to a time-shifted buffer (TSB) depth in
accordance with the techniques of this disclosure.
DETAILED DESCRIPTION
[0034] In general, this disclosure describes techniques for
supporting various types of transport mechanisms for streaming
media data, such as audio and/or video data, through a network. For
example, an application service client (which may also be referred
to as a streaming client) may be configured to interact with a
proxy unit to retrieve media data either according to a unicast
protocol or a broadcast (or multicast) protocol. In some examples,
the proxy unit may determine whether the media data can be
retrieved using the broadcast protocol, e.g., based on whether a
client device is within an area of coverage of a service provider
for delivering media data using the broadcast protocol, and select
either the unicast protocol or the broadcast protocol based on
whether the client device is within the area of coverage. The
client device may execute the application service client and/or
include the proxy unit. In some examples, the client device may
execute the application service client, and the proxy unit may be
included in a device separate from the client device.
[0035] The techniques of this disclosure may be used in conjunction
with various application-layer protocols for streaming media data.
For example, the techniques of this disclosure may be used in
conjunction with Dynamic Adaptive Streaming over HTTP (DASH), which
utilizes HTTP to stream media data. As another example, the
techniques of this disclosure may be used in conjunction with
Real-time Transport Protocol (RTP) or Real-Time Streaming Protocol
(RTSP). In these and other instances, an application service client
(e.g., an RTP client, an RTSP client, or a DASH client) may be
transport-agnostic, in the sense that the application service
client need not be aware of a transport mechanism used to retrieve
media data. For instance, the application service client need not
be aware of whether an underlying transport mechanism corresponds
to a unicast protocol or a broadcast or multicast protocol.
[0036] As discussed in greater detail below, the proxy unit (which
may also be referred to as a redirector/proxy unit) may be
configured to receive a request from an application service client,
where the request specifies certain media data. The proxy unit may
determine whether the media data can be retrieved using a
particular transport mechanism, e.g., a broadcast protocol or a
unicast protocol. The proxy unit may then cause the application
service client to receive the media data using one of the transport
mechanisms (based on availability, preference, reliability, and/or
other factors). For example, if the broadcast protocol is more
preferable than the unicast protocol, and the broadcast protocol is
available, the proxy unit may cause the application service client
to receive the media data via the broadcast protocol, whereas if
the broadcast protocol is not available, the proxy unit may cause
the application service client to receive the media data via the
unicast protocol.
[0037] As one example, with respect to DASH, media data may be
available from one or more servers, e.g., a broadcast server and a
unicast server, as a broadcast and/or a unicast service. A DASH
client may receive a modified media presentation description (MPD)
for the media data that indicates that the media data is available
from a proxy unit (rather than the server(s)). When the DASH client
sends a request for media data to the proxy unit, the proxy unit
may determine whether a unicast protocol or a broadcast protocol is
available for retrieving the requested media data. If the broadcast
protocol is available, a broadcast receiving unit (e.g., a
multimedia broadcast multicast services (MBMS) or evolved MBMS
(eMBMS) middleware unit) may receive the media data, and the proxy
unit may cause the DASH client to send a request for the media data
to the broadcast receiving unit. On the other hand, if the
broadcast protocol is not available, the proxy unit may cause the
DASH client to send a request for the media data to a unicast
server, to retrieve the media data using unicast. Alternatively,
the proxy unit may retrieve the media data from the unicast server,
and then provide the retrieved media data to the DASH client. In
some examples, the unicast server and the broadcast server may
correspond to the same server.
[0038] As another example, with respect to RTP or RTSP, an RTP
client (which, alternatively, may correspond to an RTSP client) may
submit DESCRIBE, SETUP, and PLAY commands to a proxy unit. In
response to the DESCRIBE command, the proxy unit may provide a
modified session description protocol (SDP) message to the RTP
client. The modified SDP message may specify an address of the
proxy unit as the address from which the media data is available.
This modified SDP message may cause the RTP client to send the
SETUP and PLAY commands to the proxy unit. When the proxy unit
determines that the broadcast protocol is available, the proxy unit
may send SETUP and PLAY commands to a broadcast receiving unit
(e.g., an MBMS or eMBMS middleware unit), which may receive the
media data and forward the media data to the RTP client. On the
other hand, when the proxy unit determines that the broadcast
protocol is not available, the proxy unit may retrieve the media
data from a unicast server, and then provide the retrieved media
data to the RTP client.
[0039] In some examples, components for performing the techniques
of this disclosure may include an application service client, a
proxy unit, and a broadcast receiving unit. In various examples, a
client device may include any or all of these components, alone or
in any combination. Alternatively, the client device may include
the application service client, and the proxy unit and/or the
broadcast receiving unit may be included in one or more devices
that are separate from the client device.
[0040] Moreover, this disclosure also describes techniques related
to signaling data for a time-shifted buffer (TSB). A client device
(also referred to herein as "user equipment") may allocate memory
to form a TSB to be used for holding media data in support of
various trick modes, such as fast forward, rewind, replay, or the
like. In general, a trick mode may refer to a playback mode in
which media data is played back in an order or rate other than a
defined output order. For instance, in fast forward, certain media
data may be skipped. As another example, in rewind, an output order
for media data may be inverted, and certain media data may also be
skipped. To skip media data, e.g., with respect to video data, only
pictures coded using an intra-coding mode could be displayed,
skipping inter-coded pictures.
[0041] In accordance with the techniques of this disclosure, data
may be signaled in, e.g., an SDP message, for instantiating a TSB.
For example, a TSB attribute may be signaled, with a value
defining, in seconds, an amount of media data that can be stored in
the TSB. A client device may calculate an amount of memory needed
for the TSB based on the value of the TSB attribute. This
calculation may involve, for video data as an example, a frame rate
of video data in the media data. The client device may calculate a
memory size for the TSB based on an average amount of data per
picture, a number of pictures in a period of time (based on frame
rate), and a length of time as defined by the TSB attribute.
Likewise, the client device may further determine an amount of
memory needed for audio data, text data, or other data or media for
the period of time. Thus, the client device may allocate this data
to the TSB for storing media data to perform trick modes.
Furthermore, the client device may perform trick modes for data
received via a broadcast protocol, such as MBMS or eMBMS.
[0042] In other words, in some examples, the techniques of this
disclosure include a middleware architecture for supporting
features of Real-time Protocol/Real-time Streaming Protocol
(RTP/RTSP) streaming over evolved Multimedia Broadcast Multicast
Service (eMBMS) network. These features include time-shifted buffer
and transport diversity (e.g., unicast to broadcast switching or
vice-versa for content delivery). For the time-shifted buffer (TSB)
feature, the architecture may support extensions of the session
description protocol (SDP) to include data signaling a buffer
depth. As one example of the transport diversity feature, this
disclosure describes proposes an architecture where applications
consuming the content need not be aware of the details of transport
switching from unicast to broadcast or vice-versa, as this
switching may be managed in the middleware level.
[0043] In HTTP streaming, frequently used operations include GET
and partial GET. The GET operation requests the retrieval of a
whole file associated with a given uniform resource identifier
(URI) (e.g., URL or URN). The partial GET operation requests the
retrieval of a byte range (subset) of a resource. Thus, movie
fragments may be provided for HTTP streaming, because a GET or
partial GET operation can retrieve one or more individual movie
fragments. In a movie fragment, there can be several track
fragments of different tracks. In HTTP streaming, a media
presentation may be a structured collection of data that is
accessible to the client. The client may request and download media
data information to present a streaming service to a user.
[0044] In the example of streaming DASH data using HTTP, there may
be multiple representations for video and/or audio data of
multimedia content. 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 that is accessible to an HTTP streaming client device. The
HTTP streaming client device may request and download media data
information to present a streaming service to a user of the client
device. A media presentation may be described in the MPD data
structure, which may include dynamic updates of the MPD.
[0045] A media representation may contain a sequence of one or more
periods. Periods may be defined by a Period element in the MPD.
Each period may have an attribute start in the MPD. The MPD may
include a start attribute and an availablityStartTime attribute for
each period. For live services, the sum of the start attribute of
the period and the MPD attribute availableStartTime may specify the
availability time of the period in UTC format, in particular the
first Media Segment of each representation in the corresponding
period. For on-demand services, the start attribute of the first
period may be 0. For any other period, the start attribute may
specify a time offset between the start time of the corresponding
Period relative to the start time of the first Period. Each period
may extend until the start of the next Period, or until the end of
the media presentation in the case of the last period. Period start
times may be precise. They may reflect the actual timing resulting
from playing the media of all prior periods.
[0046] Each period may contain one or more representations for the
same media content. A representation may be one of a number of
alternative encoded versions of audio, video or other data. The
representations may differ by encoding types, e.g., by 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 or video data or other media or
data corresponding to a particular period of the multimedia content
and encoded in a particular way.
[0047] Representations of a particular period may be assigned to a
group indicated by a group attribute in the MPD. Representations in
the same group are generally considered alternatives to each other.
For example, each representation of video data for a particular
period may be assigned to the same group, such that any of the
representations may be selected for decoding to display video data
of the multimedia content for the corresponding period. The media
content within one period may be represented by either one
representation from group 0, if present, or the combination of at
most one representation from each non-zero group, in some examples.
Timing data for each representation of a period may be expressed
relative to the start time of the period.
[0048] A representation may include one or more segments. Each
representation may include an initialization segment, or each
segment of a representation may be self-initializing. When present,
the initialization segment may contain initialization information
for accessing the representation. In general, the initialization
segment does not contain media data. A segment may be uniquely
referenced using an identifier, such as a uniform resource
identifier (URI) (e.g., uniform resource locator (URL) or uniform
resource name (URN)). The MPD may provide the identifiers for each
segment. In some examples, the MPD may also provide byte ranges in
the form of a range attribute, which may correspond to the data for
a continuous byte range of segment within a resource (e.g., file)
accessible by referencing the corresponding URI.
[0049] Each representation may also include one or more media
components, where each media component may correspond to an encoded
version of one individual media type, such as audio, video, or
timed text (e.g., for closed captioning). Media components may be
time-continuous across boundaries of consecutive media segments
within one representation.
[0050] The techniques described herein may be used for the wireless
networks and radio technologies mentioned above as well as other
wireless networks and radio technologies. For clarity, certain
aspects of the techniques are described below for LTE, and LTE
terminology is used in much of the description below.
[0051] RTP/RTSP streaming is a common protocol for supporting
real-time streaming services. The 3GPP specification for eMBMS
services describes the architecture for RTP streaming over Long
Term Evolution (LTE) networks. However, this disclosure, recognizes
two problems with RTP/RTSP, and discusses techniques that may be
used to overcome these problems.
[0052] The Time-shifted buffer (TSB) is a feature that may be used
to store a portion of media content in User Equipment (UE). The
buffer allows users to move the playback point of media content
forward or backward. In this process, the UE needs to have been
informed of the buffer depth, which provides an indication of how
much time worth of content the UE needs to accumulate at the device
to allow for trick mode playback, e.g., fast-forward and rewind of
playback. In one implementation of a VLC media player, the TSB
feature is enabled by providing the buffer depth as an argument to
the VLC player at startup. The process is not automatic, and
instead requires intervention of a user to provide the buffer depth
argument and consequently enable the TSB. This disclosure describes
techniques for supporting a TSB in an eMBMS-enabled middleware
layer, such as a multicast services device client (MSDC).
[0053] The session description protocol (SDP) describes endpoint
information of a streaming service and its media stream (session)
related parameters, collectively known as a "session profile."
Therefore, if a streaming service is available in different
transport methods, multiple profiles that describe different
transport/endpoint parameters for the service are needed. For
example, a broadcast real-time RTP-based service can refer to a
multicast IP address and port for its media streams, whereas the
unicast version of the service may refer to a unicast IP address
and port. There may be different representations of the media
streams for broadcast and unicast delivery methods. In LTE
networks, the MSDC provides delivery of streaming services to
eMBMS-enabled applications. To support switching between unicast
and other (e.g., broadcast or multicast) transport methods, it
needs to utilize multiple session profiles, the choice of which
will be based mainly on whether a UE is out of coverage or in
coverage of broadcast. Whenever a UE moves to broadcast coverage
area, the MSDC may use the broadcast-enabled version of the SDP
profile to set up a connection and consume content. However, in the
reverse scenario, when a UE moves out of broadcast coverage, MSDC
may need to use the unicast SDP and set up a unicast connection
with the remote RTSP server to consume unicast content. To keep the
transitions between unicast and broadcast hidden from users or
applications, this disclosure describes a mechanism for seamless
transition.
[0054] This disclosure describes, among other techniques,
techniques related to supporting the TSB and techniques for
supporting transport switching, which may be used alone, together,
and/or in any combination with other techniques described in this
disclosure. For enabling the TSB feature in RTP-based streaming
over eMBMS, this disclosure describes techniques for using the
extension of the SDP mechanism to signal the time-shifted buffer
depth value. For the transport switching problem, this disclosure
describes a unified approach for an SDP description that includes
both unicast and broadcast descriptions. Also, in order to make the
transitions between broadcast and unicast seamless to the
applications/users, this disclosure describes a middleware-based
solution where the middleware handles the redirection of content
using unified SDP, hiding the process from the users.
[0055] In accordance with aspects of the subject matter of this
disclosure, there are provided methods, apparatus, and an
architecture for deployment within a client device or collection of
devices, to provide a layer of abstraction wherein multiple
different types of transport mechanisms/protocols (e.g., eMBMS,
digital video broadcast (DVB), etc.) may be employed to, e.g.,
deliver meta-data and digital content to applications of a client.
Applications need not be cognizant of the details of each
individual transport. The disclosure may include the option of a
configurable set of policies which may be used to determine the
choice, location, or timing of availability of data and meta-data
that are delivered to the applications.
[0056] Applications that access web content on the Internet may
identify the content (or its constituent parts) using a universal
resource identifier (URI), which may be a universal resource
locator (URL) that utilizes the HTTP or HTTP secure (HTTPS)
schemes. For example, in the context of MPEG-DASH, URL references
containing the HTTP or HTTPS schemes may be resolved using the HTTP
or HTTPS protocols. In addition, HTTP may be used to fetch data
referenced by the URLs. The DASH standard may utilize non-HTTP
URLs, and the disclosure may relate to cases where arbitrary
requests (including HTTP-based requests) from clients are handled
in a flexible manner that provides an option to cause requests to
be directed to a different location, at a different time, and/or
instruct the requesting client to access alternative content.
[0057] Techniques of this disclosure may involve the instantiation
of a re-director function that handles client requests for content.
The re-director (also referred to herein as a redirector/proxy) may
be able to apply processing to the material identified in a client
request, invoke a method or algorithm to compare the result of this
processing against a table of matching criteria, and indicate to
the client an alternative location, access method, timing
information, or content (e.g., in a file) so that the client may
know where to perform a subsequent request. In another aspect, the
re-director may perform the request for the content on the client's
behalf and fetch the requested content. In this case, the
re-director may act in a proxy or recursive function.
[0058] FIG. 1 is a block diagram illustrating an example system 100
for supporting transport diversity. The example system 100 may
include an application 101, e.g., of a mobile device. The
application 101 may perform a request for content. For example, a
DASH multimedia playback application processes a manifest or MPD,
and determines URLs containing meta-data and data, and sends HTTP
requests. The request for content may use a pre-determined,
pre-configured, or dynamically determined protocol port (e.g., with
TCP or UDP) such as a protocol that would typically be used in
configuring a web browser's "proxy" function. The determination of
the protocol port may include using a configuration file, e.g.,
established by a user or network/system administrator such as in a
proxy auto-config (PAC) file, or via protocol such as by web proxy
auto-discovery protocol (WPAD).
[0059] A re-director/proxy 104 may receive the application's 101
request via an application service client 102 and process or parse
the request to determine the requested content. The
re-director/proxy 104 may compare the result against a table (or
other suitable type of data structure) containing matching criteria
to determine if a match has occurred. If a match occurs, the
re-director/proxy 104 may determine a redirection target. The
target may be delivered to the application 101. In another aspect,
the re-director/proxy 104 may act in a recursive fashion and the
application 101 may not need to process the redirection target. For
example, the re-director/proxy 104 may fetch the content based on
the redirection target on behalf of the application 101.
[0060] The re-director/proxy 104 may be co-located with the
application 101 on the same device, or the re-director/proxy 104
may be located on a separate device. In the case of a co-located
re-director/proxy 104, the application 101 may communicate with the
re-director/proxy 104 through HTTP, application programming
interface (API), inter-process communication (IPC), etc. In the
case of the re-director/proxy 104 located on a separate device, the
application 101 may communicate with the re-director (via the
application service client 102) through HTTP, etc.
[0061] Subsequent to the determination of a "match" (or non-match),
a re-direction target may be provided to the application 101. The
target may indicate alternative content object(s) to access in lieu
of content object(s) requested by the application 101. There may be
various methods by which the re-direction target may be indicated
to the application 101.
[0062] Signaling between components of the system 100 may be
performed using an API or IPC. This aspect, the API or IPC
mechanism may be utilized to provide communication between the
re-director/proxy 104 and the application 101. In the case of using
the API, the re-director/proxy 104 may invoke methods or procedures
implemented within the application 101 or application library to
indicate the redirect target.
[0063] Signaling between components of the system 100 may be
performed through meta-data re-writing. In this aspect, the
meta-data (e.g., a DASH MPD) may be re-written so as to indicate
alternative references for objects. For example, a URI present in
the original meta-data may be re-written to form an alternative URI
for accessing equivalent or replacement content.
[0064] Signaling between components of the system 100 may be
performed using indications in a communication protocol. In this
aspect, an application layer communications protocol (e.g., HTTP)
may be utilized in such a way as to communicate signaling
information to the application 101. In one variant, the HTTP
response code category of "re-direct" may be used (e.g., this may
correspond to codes of the form 3xx, where x may be a number from
zero through nine). In one subcase of this variant, e.g., the code
300 (indicating multiple choices available) may be used, in which
the re-director/proxy 104 provides a vector of references (e.g.,
URIs) from which an application 101 may select one or more for
use.
[0065] The matching function may give the result of comparing
object references originated from the application 101 (e.g., a
request URI) with object references present in a data structure
(e.g., a file, database, matching table, etc.).
[0066] By way of non-limiting examples, in one aspect, matching
criteria may be expressed as URI prefixes and a single preferred
match occurs is indicated by the match with the longest prefix
(e.g., as determined by the number of bits or bytes in common). In
another aspect, each potential match may be assigned a
corresponding priority number, and the entry with the largest (or
smallest) priority number may be selected.
[0067] In another aspect, matching criteria may be expressed as
regular expressions, and the preferred match may be determined
using the largest number of matching characters. In another
variation, regular expressions may be used to express the matching
criteria and the potential match with the largest (or smallest)
priority number may be selected.
[0068] The matching algorithm or contents of the data structure
discussed above may be based on policies that may be pre-determined
or pre-configured. In another aspect, the policies may be
dynamically added or deleted from a logical policy database. The
policy database may be implemented using various data structures
and is not limited to any particular type of data structure or
database implementation.
[0069] Policies may be used to determine the operation of the
matching algorithm in a number of ways including, for example,
prioritizing or de-prioritizing matching criteria from one source
over other(s) (e.g., one transport type may be favor/disfavored
over (s)); removing matching criteria as a function of source,
time, redirection target, and/or matching criteria value; adding
matching criteria as a function of source or time or redirection
target or matching criteria value; and/or modifying matching
criteria as a function of source or time or redirection target or
matching criteria value.
[0070] The example system 100 may include a transport middleware
110 for requesting content based on the redirected location. The
transport middleware 110 may include a number of transport
mechanisms/protocol such as Transport A 110A through Transport R
110R. Each transport mechanism (Transport A 110A through Transport
R 110R) may have a corresponding module capable of acquiring a list
and details of file information and producing, e.g., a summarizing
URI or common URI prefix. These modules may convey this information
via a communication mechanism (e.g., IPC, API, or protocol) to the
Controller 106 which may apply policy and resolution, and which may
in turn program the re-director/proxy 104 subject to the policy.
The transport mechanisms (Transport A 110A through Transport R
110R) may include, e.g., eMBMS, DVB-T2, DVB-S, other DVB-family
broadcast technologies, or the like. Each transport middleware may
include a cache for storing content or other data. For example, the
transport middleware may cache a starting segment of content so
that content delivery to the application 101 may appear
instantaneous to the user. The transport middleware 110 may request
the content from a source such as a content server 120.
Additionally or alternatively, the client may request the content
over a network, including the Internet 122. For the
re-director/proxy 104 configured for proxy or "recursive"
operation, the re-director/proxy 104 may request content via the
transport middleware 110 or via a network or the Internet 122. The
re-director/proxy 104 may be pre-configured to operate in one of
the re-direction or proxy roles. The role of the re-director/proxy
104 may be determined at run-time, e.g., based on a set of
rules.
[0071] FIGS. 2A-2B illustrate alternative examples of apparatuses
including a re-director/proxy 104 for supporting transport
diversity. Any or all of the re-director/proxy 104, controller 106
with policy database 108, or transport middleware 110 may be
co-located with the application 101 and client on a device or may
be located on separate device(s). In the example of FIG. 2A, the
system 200A includes the re-director/proxy 104A which is shown
co-located with the client and application 101 on a UE 101A. For
example, the application service client 102A may be a DASH client,
HTTP Live Streaming (HLS), Apple Live Streaming (ALS) client,
Adaptive HTTP Streaming (AHS) client, or any other suitable client.
The application service client 102A may communicate with
re-director/proxy 104A via HTTP, API, IPC, or any other suitable
protocol or manner. In the example of FIG. 2B, the system 200B
includes the re-director/proxy 104B which is shown located on a
separate entity 110 as the application service client 102B and
application 101 which are located in a UE 101B. For example, the
application service client 102B may be a DASH client, HLS (ALS)
client, AHS client, or any other suitable client. The application
service client 102B may communicate with the re-director/proxy 104B
via HTTP, or any other suitable protocol or manner. The
re-director/proxy 104B may be located on any suitable network
entity such as a proxy server, gateway, router, etc.
[0072] FIG. 3 is a flow diagram illustrating aspects of an example
process flow 320 using a re-director/proxy configured for
re-direction operation. Prior to initiation of the process flow
320, the policy database 108 (coupled to the controller 106) may be
provided or pre-configured with policy information for determining
the actions of the controller 106. The policy database 108 may be
provided with the information at provisioning time.
[0073] The application 101, which may or may not be related to
application 101 in FIG. 1, may be a provisioning application.
Application 101 may be configured to activate the transport
middleware 110 (321), as well as determine status for transport
middleware 110. Application 101 may be configured to activate one
or more transport mechanisms of the transport middleware 110.
Application 101 may initially configure application service client
102 with information identifying a proxy endpoint (e.g., a host
name or address, protocol, or protocol port number) at startup
(322).
[0074] In this example, more than one transport may be available
and various content may be available over the various transports at
different times. In particular, various services may be available,
where the various services may each define different respective
types of transports, such as broadcast, multicast, unicast, or the
like, for transporting media data. For example, the eMBMS and/or
one or more of the DVB-family of transports may be available.
Further, the available media content (e.g., files) may be expressed
using, e.g., an application service description. One example of an
application service description is an MBMS user service description
(USD) metadata fragment, such as an MPD fragment in the case of
DASH content delivered as an MBMS User Service, in describing the
various available media components. Another example of an
application service description is an Apple HLS (HTTP Live
Streaming) manifest file, in the case of HLS content delivered as
MBMS User Service. Each transport mechanism may have a
corresponding module capable of acquiring the list and details of
file information and producing a summarizing URI or common URI
prefix. These modules may convey this information via a
communication mechanism (e.g., IPC, API or other protocol) to the
controller 106 which may apply policy and resolution, and which in
turn programs the re-director/proxy 104 subject to the policy.
[0075] Content server 310 may broadcast (e.g., using LTE RAN,
DVB-T, etc.) a service listing (e.g., USD, ESG), which may be
received by the transport middleware 110. An appropriate module
(e.g., one of Transport A 110A through Transport R 110R) parses the
service listing and processes the information into a form which is
not transport specific. The transport middleware 110 may convey the
results (e.g., an identifier of a service and data defining a list
of available files, also referred to as a file availability list)
to the controller 106 (324). The controller 106 may process the
file availability list in conjunction with the access policy to
produce a set of mappings (325). The mappings may include which
URIs (or URI prefixes) should be re-directed to which server (e.g.,
files available over MBMS may be available from the server
instantiated within or associated with the MBMS middleware).
[0076] Once the application service client 102 is invoked, the
application service client 102 may issue a request (e.g., an HTTP
request) via the configured proxy address to obtain, e.g., the MPD
contents (326). The request may be communicated to the
re-director/proxy 104. The re-director/proxy 104 may perform the
matching algorithm to determine matching criteria or, if a match
does not occur, another indicator (e.g., a default re-direction
target, error indication, or copy of the original request).
Redirector/proxy 104 may then provide a re-direction target or
error to the application service client 102, e.g., using HTTP
(327A). The application service client 102, having observed a code
(e.g., HTTP code) indicating re-direction (e.g., 3xx type code)
responds depending on the code type. For example, code types other
than 300 include an HTTP "Location:" header that may indicate the
alternate location for a resource. Upon receiving such an
indication, the application service client 102 may re-try its
request using the alternate location indicated. In this example,
the re-director/proxy 104 indicates a particular URI should be
directed to the server integrated within the MBMS middleware.
Accordingly, the application service client 102 may submit a
request to the transport middleware 110 to obtain, e.g., the MPD
(327B) in response to such a redirection code.
[0077] Once the application service client 102 has acquired the MPD
information, the application service client 102 may determine which
media segments to access (e.g., which "representation" in the case
of MPEG-DASH) and issue an HTTP-based request (328) to the
redirector/proxy 104. Using the mechanism described above (e.g.,
the type of transport associated with the service identified by the
service ID), the re-director/proxy 104 may provide a redirect
target (329) to the application service client 102. The target may
be a default value, a copy of the request (indicating the
application service client 102 should handle the request), or a
reference to a different server. The targets then serve as the
locations used by the application service client 102 to obtain
media segments. That is, assuming that the content is available
using the service, the application service client 102 may submit a
content request to the transport middleware 110 (330A), and in
response, the transport middleware 110 may deliver the content to
the application service client 102 (331A). For content available
through other sources (e.g., when the service is not available),
the application service client 102 may obtain the content via other
methods (e.g., from other servers, storage/cache or the Internet).
For example, the application service client 102 may send a content
request to content server 310 (330B), and, in response, the content
server 310 may deliver the requested content to the application
service client 102 (331B).
[0078] In some cases, the URIs requested from the application
service client 102, at step 326 or step 328, may be unknown to the
re-director/proxy 104. In such cases, errors (e.g., HTTP code 404)
may be generated to indicate to the application service client 102
that it may try to request a different segment or stop using the
re-director/proxy 104 (e.g., use a direct Internet access request
instead). Alternatively, the re-director 104 may use a location
header equivalent to the incoming request to suggest non-proxy
operation. Another aspect may involve the re-director/proxy 104
acting as a proxy or web proxy, in which case it may access the
Internet or another network or cache on behalf of the application
service client 102, e.g., as illustrated below in example process
flow 400 of FIG. 4.
[0079] For the 300-type HTTP error codes, the application service
client 102 may be presented with a vector of choices that may not
be present in the "Location:" header. In this case, the application
service client 102 may choose among the multiple choices provided
and, depending on the particulars of the media encoding format,
re-initialize its decoding state. The scenario may arise, for
example, if a re-direction occurs in the middle of a playback
scenario to a representation encoded in a way other than that which
the application service client 102 has been processing so far.
[0080] Whichever process the application service client 102 uses to
select its next media request(s)/access(es), the application
service client 102 may initiate the request(s)/access(es) based on
the re-directed information. Subsequent requests/access may pass
through the re-director initially, providing the opportunity for
the re-director to intervene and effectively modify the location
(and other characteristics) from which segments (e.g., meta-data
and/or media segments stored as files) are retrieved.
[0081] FIG. 4 is a flow diagram illustrating aspects of an example
process flow 400 using a re-director/proxy configured for proxy
operation. Prior to initiation of the process flow 400, the policy
database 108 (coupled to the controller 106) may be provided or
pre-configured with policy information for determining the actions
of the controller 106. The policy database 108 may be provided with
the information at provisioning time.
[0082] The application 101 may be a provisioning application.
Although described with respect to application 101 of FIG. 1, it
should be understood that the application need not be the same as
that described with respect to FIG. 1. Application 101 may be
configured to activate the transport middleware 110 (401).
Application 101 may be configured to activate one or more transport
mechanisms of the transport middleware 110. The application service
client 102 may initially be configured with information identifying
a proxy endpoint (e.g., a host name or address, protocol, or
protocol port number) at startup by the application 101 (402).
[0083] In this example, more than one transport mechanism may be
available and various media may be available over the various
transports at different times. The various types of transports may
be defined by respective services. For example, the eMBMS and/or
one or more of the DVB family of transports may be available.
Further, the available media files may be expressed using, e.g.,
the MPD fragment of the eMBMS USD, and via DVB electronic service
guide (ESG) for DVB transport. Each transport mechanism,
represented by the transport middleware 110, may have a
corresponding module capable of acquiring a list of available
services and details of file information and for producing a
summarizing URI or common URI prefix. These modules may convey this
information via a communication mechanism (e.g., IPC, API or other
protocol) to the controller 106 which may apply policy and
resolution, and which in turn programs the re-director/proxy 104
subject to the policy.
[0084] Content server 310 may broadcast a service listing (e.g.,
USD, ESG) and received by the transport middleware 110 (403). An
appropriate module (e.g., one of Transport A 110A through Transport
R 110R) parses the service listing and processes the information
into a form which is not transport specific. The transport
middleware 110 may convey the results to the controller 106 (404).
The controller 106 may process the file availability list in
conjunction with the access policy to produce a set of mappings
(405). The mappings may include which URIs (or URI prefixes) should
be re-directed to which server instantiated (e.g., files or media
available over MBMS may be available from the server instantiated
within or associated with the MBMS middleware).
[0085] Once the application service client 102 is invoked, the
application service client 102 may issue a request (e.g., an HTTP
request) via the configured proxy address to obtain, e.g., the MPD
contents (406). The request may be communicated to the
re-director/proxy 104. The re-director/proxy 104 may perform the
matching algorithm to determine matching criteria or, if a match
does not occur, another indicator (e.g., a default re-direction
target, error indication, or copy of the original request). In the
case of an error, the error may be provided to the application
service client 102. If a match occurs, the re-director/proxy 104
may act as a proxy and retrieve the content on behalf of the
application service client 102. The targets then serve as the
locations used by the re-director/proxy 104, acting as a proxy, to
obtain media segments. That is, the redirector/proxy 104 may submit
a content request to the transport middleware 110 (407A), and the
transport middleware may deliver the content to the
redirector/proxy 104 (408A). For content available through other
sources, the re-director/proxy 104, acting as a proxy, may obtain
the content via other servers, from storage/files or the Internet.
That is, the redirector/proxy 104 may submit a content request to
content server 310 (407B), and the content server 310 may deliver
the requested content to the redirector/proxy (408B).
[0086] FIG. 5 is a flowchart illustrating an example method for
supporting transport diversity associated with multimedia content
for a multimedia client of a wireless communications network (WCN).
The multimedia client may be, or may include, a mobile entity. The
method 500 may include receiving a request for content, at 502. The
method 500 may include determining whether a match exists for the
request based on a set of rules, at 504. The method 500 may include
in response to determining a match exists, sending a re-direction
to the multimedia client, at 506.
[0087] FIG. 6 is a block diagram illustrating an example apparatus
600 that may be configured as a UE, network entity, or other
suitable entity, or as a processor, component or similar device for
use within the UE, network entity, or other suitable entity, for
supporting transport diversity associated with multimedia content
for a multimedia client of a wireless communications network (WCN).
The apparatus 600 may include functional blocks that can represent
functions implemented by a processor, software, or combination
thereof (e.g., firmware).
[0088] As illustrated, in one example, the apparatus 600 may
include an electrical component or module 602 for receiving a
request for content. The apparatus 600 may include an electrical
component or module 604 for determining whether a match exists for
the request based on a set of rules. The apparatus 600 may include
an electrical component or module 606 for sending a re-direction to
the multimedia client in response to determining a match
exists.
[0089] In related aspects, the apparatus 600 may optionally include
a processor component 610 having at least one processor, in the
case of the apparatus 600 configured as a network entity. The
processor 610, in such case, may be in operative communication with
the components 602-606 or similar components via a bus 612 or
similar communication coupling. The processor 610 may effect
initiation and scheduling of the processes or functions performed
by electrical components or modules 602-606.
[0090] In further related aspects, the apparatus 600 may include a
network interface component 614 for communicating with other
network entities. The apparatus 600 may optionally include a
component for storing information, such as, for example, a memory
device/component 616. The computer readable medium or the memory
component 616 may be operatively coupled to the other components of
the apparatus 600 via the bus 612 or the like. The memory component
616 may be adapted to store computer readable instructions and data
for performing the activity of the components 602-606, and
subcomponents thereof, or the processor 610. The memory component
616 may retain instructions for executing functions associated with
the components 602-606. While shown as being external to the memory
616, it is to be understood that the components 602-606 can exist
within the memory 616.
[0091] FIGS. 7 and 8 are block diagrams that illustrate further
aspects for supporting transport diversity. The components of FIGS.
7 and/or 8 may correspond substantially to the components of FIG. 1
described above. FIG. 7, for example, illustrates network 700,
application service client 702, media application 704, HTTP
redirector/proxy 706, controller 708, middleware 712, and policy
manager 716. Media application 704 is generally responsible for
selecting media content (e.g., in response to a user's selection),
and application service client 702 is configured to retrieve the
selected media content and provide the retrieved media content to
media application 704 for playback. Application service client 702
may comprise, for example, a DASH client configured to utilize HTTP
to stream media data.
[0092] As discussed above with respect to FIG. 1, application
service client 702 may retrieve media data either directly from
network 700 or from middleware 712. For example, when a service
supporting broadcast or multicast is available (e.g., as determined
by controller 708 and defined by policies stored by policy manager
716), middleware 712 may receive media data and store the received
media data within cache 714. Application service client 702 may
issue requests for media data to HTTP redirector/proxy 706. When
the requested media data has been received by middleware 712, HTTP
redirector/proxy 706 may redirect a request for the media data to
middleware 712. Thus, application service client 702 may issue an
HTTP request to middleware 712, which may provide the media data to
application service client 702. On the other hand, when middleware
712 has not received the media data, HTTP redirector/proxy 706 may
redirect application service client 702 to a network location of a
server from which the media data is available, where the server may
be available via network 700.
[0093] FIG. 8, as another example, illustrates DASH client 802,
playback application 804, HTTP redirector/proxy 818, controller
814, MSDC 808, MBMS transmission unit 820, and policy database 816.
These components may correspond substantially to the similarly
named components in FIGS. 1 and/or 7. In general, the techniques of
FIG. 8 are discussed as utilizing DASH (which in turn utilizes
HTTP), but it should be understood that other streaming protocols
may be used as well. Alternative examples are discussed below with
respect to RTP/RTSP, for instance.
[0094] Initially, policy information may be provided to the system
including DASH client 802, playback application 804, HTTP
redirector/proxy 818, controller 814, and MSDC 808. Such policy
information may be stored within policy database 816 (830). This
policy information may influence the action of controller 814.
Controller 814 may be implemented in hardware, software, firmware,
or any combination thereof. It is presumed that, when implemented
in software and/or firmware, requisite hardware may is also
provided, such as one or more hardware-based processing units for
executing instructions of software corresponding to controller
814.
[0095] Initially, playback application 804 may provision
identifying information, such as information identifying a proxy
endpoint (e.g., host name or address, protocol, and protocol port
number) (832). This information may be provided by an optional
provisioning application. DASH client 802 may be configured with
the identifying information (834).
[0096] In the example of FIG. 8, more than one transport may be
available and various media (e.g. in files) may be available over
the various transports at different times. Consider, for example,
that the eMBMS and DVB transports are available. Further consider
that the media files available are expressed using an application
service description. Each transport may have a corresponding module
capable of acquiring the list and details of media information and
producing a summarizing URI or common URI prefix, as shown by
transport modules 110A-110R of FIG. 1. Only MSDC 808 is shown in
the example of FIG. 8, but it should be understood that MSDC 808
may include multiple respective transport modules. These modules
convey the file information via a communication mechanism (e.g.,
IPC, API or protocol) to controller 814, which may apply policy and
resolution, and which in turns programs the re-director subject to
policy. FIG. 8 depicts only the portions for MBMS (to limit
clutter). MBMS rX 820 may receive the USD (836), and parse/deliver
the USD to MSDC 808 (838).
[0097] MSDC 808 processes the USD-specific information into a form
which is not transport-specific and conveys the results to
controller 814 (840). Controller 814 may then process the file
availability list in conjunction with the access policy to produce
a set of mappings (842). The mappings indicate which URIs (or URI
prefixes) should be re-directed to which server instantiated (e.g.,
files available over MBMS may be available from server 812,
instantiated within or associated with MSDC 808). In other words,
HTTP redirector/proxy 818 may obtain mapping information that maps
an identifier for media data to a resource location based on a
service for retrieving the media data, wherein the service defines
at least one of a plurality of types of transports (e.g.,
broadcast, unicast, or multicast) for transporting the media data.
For example, the service may define broadcast or multicast
transport types for transporting the media data, in which case MSDC
808 may receive the data. MSDC 808 may store received media data in
cache 810, for subsequent retrieval by, e.g., DASH client 802, as
discussed below.
[0098] Once invoked, DASH client 802 may issue an HTTP request via
the configured proxy address (to HTTP redirector/proxy 818) to
obtain the MPD contents (844). Likewise, HTTP redirector/proxy 818
may receive the HTTP request from DASH client 802. The HTTP request
may be a request for media data. HTTP redirector/proxy 818 may
perform the matching algorithm to determine matching criteria or,
if a match does not occur, another indicator (e.g., a default
re-direction target, error indication, or copy of the original
request). Thus, using the matching criteria on the mapping
information, HTTP redirector/proxy 818 may determine whether a
particular service is available, e.g., a service defining broadcast
or multicast for transporting the requested media data. HTTP
redirector/proxy 818 may then provide a re-direction target or
error to DASH client 820 using HTTP (846), based on the matching
algorithm.
[0099] DASH client 802, having observed an HTTP code indicating a
re-direction (e.g., a 3xx type HTTP code) may respond depending on
the code type. For types other than 300, an HTTP "Location:" header
may indicate the alternate location for a resource. Upon receiving
such an indication, DASH client 802 may re-try its request using
the indicated alternative location. In this example, HTTP
re-director/proxy 818 may indicate that a particular URI should be
directed to the server integrated within MSDC 808, from which DASH
client 802 may obtain the MPD (848).
[0100] Once DASH client 802 has acquired the MPD information, DASH
client 802 may determine what media files to access (e.g., which
"representation" in the case of MPEG-DASH) and issue one or more
HTTP-based requests to retrieve the determined media files (852).
Using the mechanism described above, HTTP redirector/proxy 818
provides a redirect target to DASH client 802 (854). The target may
be a default value, a copy of the request (indicating the client
should handle the request), or a reference to a different server.
The targets then serve as the locations used by DASH client 802 to
obtain media segments, e.g., from MSDC 808 (856). In this manner,
when a service defining, e.g., broadcast or multicast for
transporting media is available, HTTP redirector/proxy 818 may
cause DASH client 802 to receive the requested media data from a
unit (e.g., MSDC 808) that receives the media data using the
service from the resource location indicated in the mapping
information. Alternatively, the redirection target may correspond
to a network location available via some network, including
Internet 806.
[0101] In some cases, the URIs requested from the client (steps
844/852) may be unknown to HTTP redirector/proxy 818. In such
cases, errors (e.g., HTTP code 404) could be generated to indicate
to DASH client 802 that DASH client 802 should try to request a
different segment or change to not use HTTP redirector/proxy 818
(i.e., instead use a direct network or Internet access request).
Alternatively, HTTP redirector/proxy 818 may use a Location: header
equivalent to the incoming request to suggest non-proxy operation.
One further variant would involve HTTP redirector/proxy 818 acting
as a conventional web proxy, in which case HTTP redirector/proxy
818 may access Internet 806 on behalf of DASH client 802.
[0102] In this manner, the techniques of FIG. 8 represent an
example of a method including, by a proxy unit (e.g., HTTP
redirector/proxy 818), obtaining mapping information that maps an
identifier for media data to a resource location based on a service
for retrieving the media data, wherein the service defines at least
one of a plurality of types of transports (e.g., broadcast,
multicast, or unicast) for transporting the media data, receiving a
request for the media data from an application service client
(e.g., DASH client 802), determining whether the service is
available, and, when the service is available, causing the
application service client to receive the media data from a unit
that receives the media data using the service from the resource
location, based on the mapping information. The unit that receives
the media data, in this example, corresponds to MSDC 808.
[0103] Furthermore, if the resource location corresponds to a
network location (e.g., a location within or accessible via
Internet 806), HTTP redirector/proxy 818 may be configured to
determine whether media data specified in a request matches media
data in mapping information, and when the media data specified in
the request matches the media data in the mapping information, send
a redirect message to the application service client specifying the
network location to which the identifier for the media data is
mapped in the mapping information to cause the application service
client to retrieve the media data from the network location.
[0104] Likewise, HTTP redirector/proxy 818 represents an example of
a proxy unit configured to obtain mapping information that maps an
identifier for media data to a resource location based on a service
for retrieving the media data, wherein the service defines at least
one of a plurality of types of transports (e.g., broadcast,
multicast, or unicast) for transporting the media data, receive a
request for the media data from an application service client,
determine whether the service is available, and, when the service
is available, cause the application service client to receive the
media data from a unit that receives the media data using the
service from the resource location, based on the mapping
information.
[0105] FIGS. 9 and 10 are block diagrams illustrating example MSDC
architectures for supporting RTP/RTSP streaming. FIG. 9 shows the
architecture without the TSB feature and FIG. 10 shows the
architecture supporting a TSB. In these examples, the TSB will be
maintained in the middleware. The numbered arrows indicate the data
flow from a network layer to middleware and eventually to the
RTSP/RTP client. In particular, data received by the LTE modem is
provided to the IP stack, which supports multicast (or broadcast).
The IP stack provides the received data to a Real-time Transport
Protocol (RTP) function of the MSDC middleware (901), which
performs forward error correction (FEC) processing on the data. The
data is then provided back to the IP stack (902). The IP stack then
provides the data to the RTP client (903).
[0106] In the example of FIG. 10, MSDC 1010 may support TSB 1012.
Thus, in the example of FIG. 10, data received by the LTE modem is
provided to the IP stack, which supports multicast (or broadcast).
The IP stack provides the received data to a Real-time Transport
Protocol (RTP) function of MSDC 1010 (1001), which performs forward
error correction (FEC) processing on the data. The data is then
buffered in a time-shifted buffer (TSB) 1012 (1002). The IP stack
may then receive the data from TSB 1012 (1003) at an appropriate
time and provide the data to the RTP client (1004).
[0107] In addition, as described in greater detail below, MSDC 1010
may receive an SDP message including an attribute that defines a
time-shifted buffer (TSB) depth for TSB 1012 of FIG. 10. MSDC 1010
may determine an amount of memory for TSB 1012 based on a value of
the attribute as signaled in the SDP message. For example, the
value of the attribute may define a length of the TSB, e.g., in
terms of seconds of playback for media data to be stored in TSB
1012. Thus, MSDC 1010 may determine the amount of memory to be
allocated to form TSB 1012 based on, e.g., a frame rate for video
data of the media data to be received and on the number of seconds
of playback to be potentially buffered in TSB 1012. MSDC 1010 may
then allocate the determined amount of memory for TSB 1012 and
store at least a portion of received media data, associated with
the SDP message, in TSB 1012.
[0108] In order to signal the TSB depth, the techniques of this
disclosure may be used to leverage the extension mechanism of SDP.
SDP "a=" (attribute) lines may be used for providing extensions to
the general session description. The following semantics may be
used to signal data related to the TSB, as one example: [0109]
TSB-attribute="a=tsb-length:" Value [0110] Value=token [0111] Value
will have seconds as unit
[0112] As an example, the following SDP snippet mentioned in Table
1 describes data for the TSB. The buffer depth in this example is
60 seconds, or 1 minute. This implies that the MSDC (e.g., the TSB
of the MSDC illustrated in FIG. 10) will maintain 1 minute worth of
media content in its time-shifted buffer. The underlined text
represents an example attribute in the form of an "a=" line, in
accordance with the techniques of this disclosure, related to the
TSB.
TABLE-US-00001 TABLE 1 v=0 s=RTSP session c=IN IP4 127.0.0.1/1
a=3GPP-QoE-
Metrics:metrics={Network_Resource|Loss_Of_Objects};rate=End;
resolution=60 t=0 0 a=rtsp://localhost:554/concert a=tsb-length: 60
a=control:trackID=1 m=audio 5676 RTP/AVP 0 a=control:trackID=2
m=video 5677 RTP/AVP 31
[0113] When data for the TSB is provided in the SDP, the MSDC may
allocate an equivalent amount of buffer of the size mentioned in
the SDP, and may allow the RTSP/RTP client to fast-forward or
rewind playback, with respect to the buffer duration.
[0114] One example technique for achieving transport diversity is
based upon the solution proposed by U.S. Provisional Application
Ser. No. 61/752,456, "ARCHITECTURE SUPPORTING TRANSPORT DIVERSITY,"
to Fall et al., filed, Jan. 15, 2013, attorney docket no. 131286P1
(hereinafter, the "Fall provisional application"), the entire
contents of which are hereby incorporated by reference. The Fall
provisional application proposes common client architecture for
supporting diverse transport protocols. The techniques of this
disclosure for supporting transport diversity in RTP may be used to
extend the techniques described in the Fall provisional
application, which relates to DASH-based delivery of contents.
[0115] Unlike the DASH protocol, where media representations in
Media Presentation Description (MPD) may change based on transport
delivery methods, RTP protocol conventionally has no way to
differentiate the transport diversity via a single SDP profile
directly. This disclosure describes to example techniques to
achieve transport diversity.
[0116] As one example, eMBMS broadcast definitions of services
allow mechanisms to select between unicast and broadcast transport
mechanisms. For example, a deliveryMethod element in an eMBMS
service definition schema may contain an SDP profile that describes
broadcast delivery sessions, while an AlternativeAccessDelivery
element may contain references to an RTSP URL for unicast access or
PSS SDP file that denotes unicast SDP session information. When a
UE is under broadcast network coverage, eMBMS middleware may
consume broadcast content using broadcast SDP session information.
Otherwise, the middleware may pass the content by connecting to the
unicastAccessURI in AlternateAccessDelivery. An example of the
eMBMS user service description (USD) schema snippet is shown in
FIG. 11.
[0117] An alternative example to the deliveryMethod carrying
broadcast SDP and unicast access URI is to have a unified single
SDP that contains both unicast and broadcast session descriptions
in different media streams. Since any session description in SDP
can contain multiple media stream definitions (for example, one for
an audio track and another for a video track), a mechanism may be
used to group broadcast and unicast media streams into different
sets to provide a unified SDP profile. This can be achieved by a
grouping method in SDP. An example of the grouping mechanism is
described as follows: [0118] Media stream identification [0119]
Identifies media streams within groups [0120]
Media-attribute="a=mid:" Identification-tag [0121]
Identification-tag=token [0122] Group attribute [0123] Identifies
unicast/broadcast media streams [0124] Group-attribute="a=group:"
Semantics (identification-tag)* [0125]
Semantics="BROADCAST"|"UNICAST"
[0126] The following snippet in Table 2 provides an example in
which values are provided for group and media stream identifier
attributes. In the example below, the "a=group:" lines denote which
media streams are used for broadcast and which media streams are
used for unicast. In this example, broadcast media streams are
denoted by "a=mid:" values 1 and 2 and unicast are denoted by
"a=mid:" values 3 and 4, respectively. Therefore, middleware may
connect to IP address 224.1.1.2 and ports 30000 and 30002 for
broadcast content, and to IP address 131.10.1.2 and ports 26890 and
26892 for unicast streams.
TABLE-US-00002 TABLE 2 v=0 t=0 0 c=IN IP4 224.2.17.12/127
a=group:BROADCAST 1 2 a=group:UNICAST 3 4 m=audio 30000 RTP/AVP 0
c=IN IP4 224.1.1.2/127 a=mid:1 m=video 30002 RTP/AVP 31 c=IN IP4
224.1.1.2/127 a=mid:2 m=audio 26890 RTP/AVP 31 c=IN IP4
131.10.1.2/127 a=mid:3 m=video 26892 RTP/AVP 31 c=IN IP4
131.10.1.2/127 a=mid:4
[0127] In this manner, FIG. 10 illustrates an example of a device
including one or more processors configured to receive a session
description protocol (SDP) message including an attribute that
defines a time-shifted buffer (TSB) depth, determine an amount of
memory for the TSB based on a value of the attribute, allocate the
determined amount of memory to the TSB, and store at least a
portion of media data associated with the SDP message in the
TSB.
[0128] FIGS. 12 and 13 are block diagrams illustrating example
components for supporting transport diversity for an RTSP/RTP
client. Whether deliveryMethod in an eMBMS USD is used to
differentiate between broadcast and unicast transport, or the
unified single SDP mechanism is used, the techniques of this
disclosure may provide seamless content acquisition by the RTSP/RTP
client. In order to achieve that, as proposed in the Fall
provisional application, a policy manager, a controller, and an
RTSP redirector/proxy may be maintained in UE, possibly outside
eMBMS middleware (also referred to as a multicast services device
client (MSDC)). When an RTSP client asks for SDP, a RTSP
redirector/proxy always provides SDP profiles that carry localhost
(e.g., IP version 4 address 127.0.0.1) as the connection endpoint
address. The idea is that whether the RTSP redirector/proxy
receives content via eMBMS middleware (for broadcast) or a unicast
RTSP server (for unicast), it always serves the content to the
RTSP/RTP client from the localhost. Therefore, the client is
unaware of diversity in the transport mechanism. Below we provide a
brief description of the main components of the architecture and
give an example of how content is delivered to the client.
[0129] In the examples of FIGS. 12 and 13, Playback App is the
application that is attempting to consume streaming content;
RTSP/RTP Client is the client that implements the RTP protocol for
client behavior; eMBMS Middleware is the middleware architecture
that implements eMBMS (or MBMS) broadcast service discovery (for
streaming or file download) and consumes streaming or file delivery
content via broadcast LTE network; Policy Manager maintains a
database of policies as discussed above; Controller is a component
that gets policy information from the policy manager and eMBMS
broadcast coverage indication from the eMBMS middleware and
provides a mapping to the RTSP redirector/proxy, stating which SDP
profile to choose from (unicast or broadcast); and RTSP
Redirector/Proxy is a proxy unit that receives mapping information
from the controller and, depending on the mapping, collects RTP
content from eMBMS middleware (in case UE is in broadcast coverage)
or connects to the unicast RTSP URI and receives content via
unicast transport, which it may then pass to the RTSP/RTP
Client.
[0130] FIG. 12 represents an example procedure for the broadcast
delivery of RTP content. FIG. 12 includes RTSP/RTP client 1202,
playback application 1204, RTSP redirector/proxy 1218, controller
1214, eMBMS middleware (also referred to as MSDC) 1208, policy
manager 1216, and broadcast transmission unit (also referred to as
eMBMS rX) 1220. FIG. 12 also depicts Long Term Evolution (LTE)
radio access network (RAN) 1206. LTE RAN 1206 provides an MBMS
service, which defines at least one of a plurality of types of
transports (e.g., broadcast, multicast, or unicast) for media data.
Thus, when MSDC 1208 is in a service area of coverage provided by
LTE RAN 1206, MSDC 1208 can receive media data via LTE RAN 1206
using broadcast or multicast transport. Furthermore, MSDC 1208
implements server 1212, which includes cache 1210. In this manner,
MSDC 1208 can act as both a client that receives media data and a
server that provides data to, e.g., RTSP/RTP client 1202. Moreover,
RTSP/RTP client 1202 may retrieve media data from, e.g., MSDC 1208
or RTSP redirector/proxy 1218, and then provide the media data to
playback application 1204.
[0131] Playback application 1204 may correspond substantially to
application 101 (FIG. 1), while RTSP/RTP client 1202 may correspond
substantially to application service client 102 (FIG. 1).
Similarly, MSDC 1208 may correspond substantially to one of
transport middleware 110A-110R (FIG. 10). Controller 1214 may
correspond substantially to controller 106 (FIG. 1). RTSP
redirector/proxy 1218 may correspond substantially to
redirector/proxy 104 (FIG. 1).
[0132] In this example, the policy manager is provisioned with
policies (1230). The eMBMS Middleware (or MSDC) 1208 receives USD
descriptions (1232, 1234) for the list of eMBMS services. The MSDC
1208 then passes the SDP profile information for the RTP streaming
service and the broadcast coverage notification to the controller
1214 (1236), which in turn matches the SDP information with the
list of policies and provides mapping information to the RTSP
redirector/proxy 1218 (1238). Mapping information contains data
indicating, for each scenario (broadcast or unicast coverage),
which SDP profile connection-endpoints to use. In this manner, the
RTSP redirector may obtain mapping information that maps an
identifier for media data to a resource location based on a service
for retrieving the media data. The resource location may correspond
to a network address, e.g., an address available via LTE RAN 1206.
The service may define at least one of a plurality of types of
transports for transporting the media data, e.g., broadcast or
multicast.
[0133] The MSDC 1208, meanwhile, passes a list of services to the
playback application 1204 (1240). The playback application 1204 may
correspond to application 101 (FIG. 1). The playback application
1204 then passes the RTSP URI (provided with the list of services
from MSDC) and the proxy address to the RTSP/RTP client 1202
(1242). When the RTSP/RTP 1202 client calls DESCRIBE command (an
RTSP defined command) (1244), the RTSP redirector/proxy 1218
provides a modified SDP message redirected to local server (1246).
The RTSP/RTP client 1202 parses the SDP information (1248) and
calls the SETUP command (RTSP command) to set up a RTP session with
the local server. The RTSP/RTP client 1202 also passes the PLAY
command when setup with the server succeeds (1250). The RTSP
redirector/proxy 1218 provides a success message to the SETUP and
PLAY request (1252) to the RTSP/RTP client 1202. The SETUP and PLAY
commands received by the RTSP redirector/proxy 1218 from RTSP/RTP
client 1202 represent an example of a request for media data. In
addition, the RTSP redirector/proxy 1218 sends SETUP and PLAY
commands to the MSDC 1208 (1251).
[0134] RTSP redirector/proxy 1218 may determine whether the service
for retrieving media data is available, e.g., whether a service
that defines broadcast or multicast as a transport is available.
RTSP redirector/proxy 1218 may determine whether the service is
available based at least in part on whether RTSP redirector/proxy
1218, or MSDC 1208, is within a service coverage area. The
techniques of FIG. 12 presume that the service is available. FIG.
13, as discussed in greater detail below, describes additional
techniques that may be employed when the service is not
available.
[0135] Meanwhile, during the active broadcast session of the
streaming service, a network operator sends RTP content over LTE
RAN 1206 (1254). MSDC collects RTP content for the service from
broadcast connection endpoint (labeled eMBMS rX 1220 in FIG. 12)
(1256), processes the content (if needed), and passes the content
to the RTSP/RTP client 1202 at an endpoint specified by the client
during the SETUP command with the RTSP redirector/proxy (1258). In
this manner, when the service is available (e.g., a service
defining broadcast or multicast transport), RTSP redirector/proxy
1218 causes RTSP/RTP client 1202 to receive media data from MSDC
1208 (i.e., a unit that receives the media data using the service
from a resource location, e.g., via LTE RAN 1206). In particular,
in this example, MSDC 1208 receives media data from a network
location via LTE RAN 1206, based on mapping information (e.g., the
USD data described above) that maps the service to this
location.
[0136] In this manner, the techniques of FIG. 12 represent an
example of a method including, by a proxy unit (e.g., RTSP
re-director/proxy 1218), obtaining mapping information that maps an
identifier for media data to a resource location based on a service
for retrieving the media data, wherein the service defines at least
one of a plurality of types of transports (e.g., broadcast,
multicast, or unicast) for transporting the media data, receiving a
request for the media data from an application service client
(e.g., RTSP/RTP client 1202), determining whether the service is
available, and, when the service is available, causing the
application service client to receive the media data from a unit
that receives the media data using the service from the resource
location, based on the mapping information. The unit that receives
the media data, in this example, corresponds to MSDC 1208.
[0137] FIG. 13 represents an example procedure for the unicast
delivery of RTP content. In this example, steps 1232-1248 are
substantially the same as the broadcast delivery of content as
described with respect to FIG. 12. However, in this case, when
RTSP/RTP client calls SETUP and PLAY commands (1310), the RTSP
redirector/proxy 1218 contacts a unicast RTSP server via
RAN/Internet 1302 from the mapping information (1312), retrieves
the contents from the unicast RTSP server (1314), and passes the
content to the endpoint mentioned by the RTSP/RTP client 1202
during SETUP command or the ones announced in the SDP at step 1246
(1316). Therefore, in this case, the RTSP redirector/proxy 1218
(which may be present in user equipment that also includes RTSP/RTP
client 1202) acts as client to the remote RTSP server and retrieves
the content on RTSP/RTP client's behalf.
[0138] In this manner, the techniques of this disclosure may use an
SDP extension mechanism (attribute) to provide TSB indication for
eMBMS broadcast delivery of RTP content. This disclosure also
defines an example architecture to support seamless transition
between broadcast and unicast transport, and to provide RTP media
content delivery mechanisms within a UE. Moreover, this disclosure
describes techniques for grouping of multiple RTP-based media
streams for unicast and broadcast delivery of content within an SDP
message.
[0139] RTSP redirector/proxy 1218 represents an example of a proxy
unit that may be configured to obtain mapping information that maps
an identifier for media data to a resource location based on a
service for retrieving the media data, wherein the service defines
at least one of a plurality of types of transports (e.g.,
broadcast, multicast, or unicast) for transporting the media data,
receive a request for the media data from an application service
client, determine whether the service is available, and, when the
service is available, cause the application service client to
receive the media data from a unit that receives the media data
using the service from the resource location, based on the mapping
information.
[0140] FIGS. 14A and 14B are conceptual diagrams illustrating an
example XML content model for extending a USD to carry DASH
Transport information. The circled A represents a point at which
connections between FIGS. 14A and 14B are joined. The XML content
model may be used alone or in combination with any of the
techniques described above. For example, the components of FIGS. 1,
2A, 2B, 6, 7, and/or 8 may be configured to utilize the XML content
model described with respect to FIGS. 14A and 14B. As discussed
above, the techniques of this disclosure include techniques for
selecting between unicast and broadcast transport modes. FIG. 14B
illustrates data defining both a broadcast representation
(broadcast element in the USD) and a unicast representation
(unicast element in the USD).
[0141] In accordance with certain techniques of this disclosure, an
application service client, such as a DASH client (e.g., the DASH
client of FIGS. 1, 2A, 2B, 6, 7, and/or 8), may make an initial
selection of a representation from which to retrieve a Segment. In
particular, the DASH client may make such an initial selection
while remaining agnostic of the transport mode (broadcast and/or
unicast) of the Representation to which the requested Segment
belongs. Assume, for purpose of example, that HTTP is used by the
DASH client in requesting Segments of a selected Representation, as
well as the extended USD shown in FIG. 14B is used to carry DASH
Transport information. Each of the one or more broadcast
Representations is identified in the USD by a unique baseURL
attribute of the broadcast element.
[0142] Each instance of broadcast maps to a unique Representation
delivered over the MBMS bearer. Its baseURL will be compared to a
portion of the Segment URL used by the DASH client to request
Segments--specifically, the initial portion of the Segment URL
starting from the URI scheme and extending to and inclusive of the
identifier of the Representation to which the Segment belongs, to
determine whether that Representation is being requested.
[0143] For example, assume the Segment URL issued by the DASH
client to be "http://example.com/per-3/rep-512/seg-99.3gp",
corresponding to a request for Segment 99 of Representation 512
(Representation@id=`512`) in Period 3 (Period@id=`3`). The portion
of this URL of concern for the purpose of matching with the
basesURL in the USD is "http://example.com/per-3/rep-512. In the
event that this Representation is also available over broadcast, an
instance of mediaPresentationDescription2.broadcast will be present
in the USD with baseURL given by
"http://example.com/per-3/rep-512", identical to the portion
interest in the request URL. For instance, a match in the portion
of interest for the request URL to the baseURL attribute of the
USD's broadcast element denotes broadcast transport of the
Representation to which the requested Segment belongs.
[0144] Similarly, each of the zero or more unicast Representations,
in this example, is identified in the USD by a unique baseURL
attribute of the mediaPresentationDescription2.unicast element. A
matching pattern in the same portion of the request URL as
discussed above to the unicast baseURL implies that this
Representation is available over unicast delivery. The same
Representation may be available over both, one-only, or neither of
the transport modes.
[0145] The entity to which the DASH client submits the Segment
request may be a proxy unit (or to an MBMS or eMBMS client). For
purposes of example, the proxy unit is described below as
performing these techniques, but it should be understood that the
MBMS or eMBMS of, e.g., FIGS. 1, 2A, 2B, 6, 7, and/or 8 may be
configured to perform the techniques attributed to the proxy unit,
as described below. By using pattern matching between the portion
of interest for the request URL to the value of baseURL in the
broadcast and unicast elements in the USD, the proxy unit may
determine whether the selected transport mode is available and/or
preferable to another transport mode.
[0146] The proxy unit may retrieve a policy that indicates
preferences among types of transports. For example, the policy may
indicate that if the request is for a Representation delivered over
unicast, as long as the device is located in a broadcast coverage
area, only a broadcast-delivered Representation should be
accessible to the DASH client. Such a broadcast Representation may
be the same Representation as original requested, if the baseURL
appears in the USD's identicalContent element, and can be
substituted for the requested Representation, albeit delivered over
a different transport mode.
[0147] Alternatively, the broadcast Representation may be an
alternative Representation known to be delivered over broadcast,
and is considered a switchable Representation, since the baseURL
for the alternative Representation appears in the list of entries
of the USD element switchableContent. In this case, the proxy unit
may send a message back to the DASH client to cause the DASH client
to request the same Segment belonging to an alternative
Representation which is delivered over broadcast. For instance, the
proxy unit may send a 300-type HTTP response message to the DASH
client, which corresponds to a redirect message, and the redirect
message may specify a resource URL corresponding to the alternative
representation from the list contained in switchableContent.
[0148] As another example, if the DASH client requested a Segment
known to the proxy unit to be delivered over broadcast but
broadcast reception is not available (e.g., due to a client device
being out of a coverage area for broadcast transport), the proxy
unit may send a 300-type HTTP response message that includes a URL
of a Segment corresponding to a unicast transport of the same, or a
different Representation if that same Representation is not
available over unicast transport, but appears as an entry in
switchableContent.
[0149] As another example, if the DASH client requested a Segment
known to the proxy unit to be delivered over broadcast and
broadcast reception is available, the proxy unit will proxy the
request to the local content cache, and deliver the retrieved
Segment back to the DASH client.
[0150] Alternatively, the proxy unit may respond with a 400-type
error message, which may cause the DASH client to re-submit a
request using a different Segment URL. The proxy unit may
communicate a different transport protocol in other ways as well,
e.g., via an application programming interface (API), inter-process
communication (IPC), sending a modified MPD that omits the selected
base URL, or the like.
[0151] The redirect or error message from the proxy unit may cause
the DASH client to select a different transport mode. In some
examples, more than one Representation may be available on the
redirected transport mode, in which case the DASH client may select
from among one of those available Representations. As an example,
if the DASH client had attempted to select a broadcast
Representation (as given by an instance of the broadcast element of
FIGS. 14A and 14B), but the proxy unit determined that broadcast
reception is not available, the proxy unit may send a message
(e.g., a 300-type redirect message, a 400-type error message, an
API call, via IPC communications, or the like) to the DASH client
to cause the DASH client to instead select the unicast
Representation of FIGS. 14A and 14B.
[0152] In some instances, an application service client, such as
the DASH client, may be tasked with managing unicast-broadcast
transitions. This disclosure describes, with respect to FIGS. 14A
and 14B as one example, a framework for extending the USD with
additional parameters that may, in the case of DASH over MBMS
download delivery, enable an MBMS client to determine whether
Segment requests from a DASH client can be served as-is, or only
from one or more alternative Representations. The USD may indicate
the transport mode (broadcast-only, unicast-only, or both broadcast
and unicast) of each Representation specified in the Media
Presentation Description (MPD). Example scenarios for rules and
mechanisms for determining Representation availability are
described below.
[0153] In one example, user equipment (UE) may be located within an
MBMS coverage area, and the DASH client may request a particular
Representation that the USD indicates is unavailable via broadcast
delivery. Service provider policy may dictate that whenever the UE
is in MBMS coverage, only broadcast-delivered Representations of
the same program can be accessed. In this situation, the DASH
client may be limited to selecting (or redirected or instructed to
select) from among the alternative Representation(s) available over
broadcast delivery.
[0154] In another example, UE may be located within MBMS coverage,
and the DASH client may request a Representation that is known to
be available over broadcast delivery. In this situation, the
desired Representation can be directly accessed by the UE.
[0155] In another example, UE may be outside MBMS reception area,
and the DASH client may request a Representation that is known to
be only available over broadcast delivery. In this situation, the
DASH client may be limited to selecting (or redirected or
instructed to select) from among the alternative Representation(s)
available over unicast delivery, in the form of switchable
content(s).
[0156] In another example, UE may be outside MBMS reception area,
and the DASH client may request a Representation that is known to
be also available over broadcast delivery. In this situation, the
DASH client may be able to receive the same Representation over
unicast, in the form of identical content.
[0157] Additional information that may be carried in the USD
includes the indication of the service area(s) over which each
Representation is delivered, and/or the identification of the SDP
that describes the FLUTE session carrying that Representation.
[0158] This disclosure describes techniques by which a
mediaPresentationDescription2 child element may be added under
userServiceDescription to carry additional transport parameters.
Previously, it was proposed that MPD-specific parameters, such as
Period ID, Adaptation Set ID, and Representation ID be contained in
mediaPresentationDescription2, which may identify those
Representations available over unicast delivery. These same
parameters, along with URI reference to a Session Description
fragment, may identify each Representation that can be delivered
over broadcast, as well as the mapping to the FLUTE session
carrying the Segments of that Representation.
[0159] One issue that the techniques of this disclosure may
overcome is with regards to enabling the use of HTTP/1.1 as the
protocol interface between the DASH client and the MBMS client for
Segment request/response, while maintaining clean layering
separation in protocol processing. For instance, in previous
techniques, the MBMS client has to process MPD-specific information
to be able to correlate the DASH client request for Segments of a
particular Representation to an actually available and permitted
(e.g. in accordance to service provider policy) Representation
Segments by transport mode (broadcast or unicast). In the event
that a requested Representation cannot be provided, in order for
the MBMS client to use HTTP Redirection (via 3xx response codes as
defined in Fielding et al., "Hypertext Transfer
Protocol--HTTP/1.1," Network Working Group, RFC 2616, June 1999
available at http://www.ietf.org/rfc/rfc2616.txt) to inform the
DASH client of one or more alternative Representations, the MBMS
client will have to compose a complete Segment URI for each
alternative resource. Such a layering violation on the part of the
MBMS client can be eliminated through the use of the techniques of
this disclosure.
[0160] The techniques of this disclosure eliminate the need for the
MBMS client (or proxy unit) to be aware of or have to process
(DASH-specific) MPD information. The MBMS client merely performs
data/pattern matching, based on the presence of new metadata in the
USD, with the Segment request URIs generated by the DASH client, in
determining whether the requested Segment is available over
broadcast, unicast, neither or both transport modes, or by some
other fashion (e.g., cache). This is possible because the portion
of the request URI that uniquely identifies the Representation to
which the requested Segment belongs is also conveyed in the USD. In
addition, the MBMS client can determine whether the Representation
requested by the DASH client (which is agnostic to the transport
mode) is available over broadcast, unicast, neither or both
transport modes, or by some other fashion (e.g., cache), by the
location of the matching data pattern in the USD. In conjunction
with any other relevant rules and conditions, such as coverage
condition (whether the UE is in unicast and/or broadcast service
area), service provider policy, etc., and assuming that the
substitution method for returning the alternative resource URI is
allowed based on the USD attribute replacementAllowed=`true`. The
MBMS client can use HTTP/1.1 mechanisms to mediate Segment requests
to the appropriate resource--e.g., a local content cache in the UE,
or an external HTTP server, without a protocol layering
violation.
[0161] As can be seen in the examples of FIGS. 14A and 14B, each of
the one or more broadcast Representations is identified in the USD
by a unique baseURL attribute of the broadcast element. The baseURL
value may be identical to a portion of the Segment URI used by the
DASH client to request a Segment of that
Representation--specifically, the initial portion of the Segment
URI starting from the method and extending to and inclusive of the
RepresentationID. For example, if the Segment URI is the URL
"http://example.com/per-3/rep-512/seg-99.3gp," corresponding to a
request for Segment 99 of Representation 512 (RepresentationID=512)
in Period 3, the baseURL may be defined as
"http://example.com/per-3/rep-512".
[0162] In this example, each of the one or more broadcast
Representations is identified in the USD by a unique baseURL
attribute of the broadcast element. Each instance of broadcast maps
to a unique Representation delivered over the MBMS bearer. Its
baseURL will be compared to a portion of the Segment URI used by
the DASH client to request Segments--specifically, the initial
portion of the Segment URI starting from the URI scheme and
extending to and inclusive of the Representation-ID (value of
Representation@id in the MPD). For example, assume the Segment URI
issued by the DASH client is the URL
"http://example.com/per-3/rep-512/seg-99.3gp", corresponding to a
request for Segment 99 of Representation 512
(Representation@id=`512`) in Period 3 (Period@id=`3`). The portion
of this URL of concern for the purpose of matching with USD data is
"http://example.com/per-3/rep-512. In the event that this
Representation is also available over broadcast, an instance of
mediaPresentationDescription2.broadcast will be present in the USD
with baseURL given by "http://example.com/per-3/rep-512", identical
to the portion interest in the request URI.
[0163] In the event the MBMS client determines that only
alternative Representation(s) to what is requested by the DASH
client can be accessed, the replacementAllowed attribute of
mediaPresentationDescription2 may indicate to the MBMS client
whether and how to provide such notification to the DASH client via
the HTTP Redirect (3xx status code) method, e.g., as defined in RFC
2616.
[0164] For instance, if replacementAllowed=`true`, it may be
assumed that the DASH content and MPD are authored in such a way
that allows the MBMS client to provide, to the DASH client,
alternative resource URI(s) via `303 See Other` redirection,
regardless of the transport mode of the alternative Representation.
Specifically, each alternative URI may be formed by replacing the
portion of interest in the Segment URI as described above with the
baseURL in the USD corresponding to the alternative Representation,
while retaining the Segment number in the original request.
[0165] On the other hand, if replacementAllowed=`false`, then such
replacement method for generating an alternative resource URI and
providing that to the DASH client may not be allowed. The resulting
technique for causing an alternative Representation to be requested
and delivered may be implementation dependent (e.g., the MBMS
client may return a 4xx error code accompanied with the alternative
Representation signaled by the baseURL value, and rely on the DASH
client to formulate an alternative request). An example call-flow
showing interactions between the MBMS client and the DASH client,
based on HTTP `303` redirection, is described below with respect to
FIGS. 15 and 16.
[0166] Similarly, each of the zero or more unicast Representations
may be identified in the USD by a unique baseURL attribute of the
mediaPresentationDescription2.unicast element. A matching pattern
in the same portion of the request URI, as discussed above, to the
unicast baseURL implies that this Representation is available over
unicast delivery. Note that the same Representation may be
available over both, one-only, or neither of the transport
modes.
[0167] Otherwise, via the sessionDescription element, each
broadcast Representation may be linked to a Session Description
fragment or SDP document pertaining to the FLUTE session carrying
that Representation. In addition, the serviceArea element, if
present, may denote the MBMS service area(s) over which the
broadcast Representation(s) are available.
[0168] FIG. 15 is a conceptual diagram illustrating an architecture
for supporting DASH over an MBMS. The example of FIG. 15 represents
an end-to-end network architecture for DASH content delivery over
MBMS bearer with unicast fallback. FLUTE-based download delivery
represents the TS 26.346-defined interface between the BM-SC and
MBMS client. The assumed interface between the DASH client and the
MBMS client (here assumed to be a composite entity including MBMS
receiver, device-based HTTP server, policy, redirection and proxy
functions) is HTTP/1.1.
[0169] FIG. 16 is a flow diagram illustrating a call-flow
associated with the network architecture of FIG. 15 for DASH
content delivery over broadcast and unicast transport. The
techniques described with respect to FIG. 16 are based on the USD
extension shown in FIGS. 14A and 14B for carrying DASH transport
information. Although described as corresponding to the network
architecture of FIG. 15, it should be understood that the
techniques of FIG. 16 may be performed by other devices, e.g., the
devices in the architectures of FIGS. 1, 2A, 2B, 6, 7, 8, and/or
17. In the example of FIG. 16, it is assumed that the USD contains
the information shown in Table 3, which includes values of the
baseURL attribute under mediaPresentationDescription2.broadcast and
mediaPresentationDescription2.unicast, and it is assumed that the
value of the replacementAllowed attribute in the USD is "true."
TABLE-US-00003 TABLE 3 mediaPresentationDescription2.-
mediaPresentationDescription2.- broadcast unicast (baseURL)
(baseURL) http://example.com/per-3/rep-512
http://example.com/per-3/rep-256
http://example.com/per-3/rep-128
[0170] Furthermore, in this example, it is assumed that the MPD
includes the following contents: [0171] MPD@type=`dynamic` [0172]
Period@id=`3` [0173] Period.
SegmentTemplate@media=`http://example.com/per-3/rep-$RepresentationID$/se-
g-$Number$0.3gp` [0174] Representation@id=`512` . . . [0175]
Representation@id=`256` . . . [0176] Representation@id=`128` . .
.
[0177] Given these example MPD parameter values, the DASH client
attempting to request Segment no. 99 for Representation 512 in
Period 3 may issue the following request URI:
http://example.com/per-3/rep-512/seg-99.3gp. The call flow of FIG.
16 describes DASH content delivery for two different situations: 1)
UE is located in MBMS coverage, and requests Segments of
Representation 512 of Period 3, which is available over broadcast
delivery, and subsequently, 2) UE moves outside MBMS coverage, and
continues to request the same Representation (i.e., Representation
512), which is not available over unicast delivery, but
Representations 256 and 128 are available over unicast.
[0178] In other words, this disclosure describes certain techniques
for the use of USD-based signaling of DASH transport in support of
transport diversity. It may provide one or more improvements over a
previous proposal described in Tdoc S4-130051, "Rationale for USD
Indication of DASH Delivery Mode and Illustrative Implementation"
from Qualcomm Inc. For instance, a layering violation may be
entirely avoided in this method, because the MBMS client does not
have to understand or process MPD information. Instead, the MBMS
client may perform data pattern matching of known transport
semantics against the URIs of Segments requested by the DASH client
to determine whether the requested Segments are requested to be
delivered via broadcast and/or unicast, and whether that request
can be satisfied as is, or needs to be redirected to the same or an
alternate Representation available using another transport
mode.
[0179] Such determination may be based on factors such as whether
UE is located inside or outside of MBMS coverage, service provider
policy, if any, governing accessibility of Representations by
transport mode, and possibly dependent on other conditions or
rules. Example network architecture and call flow diagram for DASH
content delivery via MBMS with unicast fallback were provided to
illustrate end-to-end content delivery featuring the use of HTTP
protocol interface between the DASH client and MBMS client. The
adherence to protocol layering should provide architectural
benefits in extensibility and simplicity of UE implementation in
support of DASH-in-MBMS services.
[0180] The use of HTTP Redirect via the 3xx status code by the MBMS
client to restrict the DASH client access to an alternative
resource (Representation) is predicated on the
mediaPresentationDescription2's replacementAllowed attribute having
the value `true`. In such event, it is assumed that the DASH
content and MPD are authored in such a way that allows the MBMS
client to provide to the DASH client alternative resource URI(s)
via `303 See Other` redirection, regardless of the transport mode
of the alternative Representation. Specifically, each alternative
URI is formed by replacing the portion of interest in the Segment
URL as described above with the baseURL in the USD corresponding to
the alternative Representation, while retaining the Segment number
in the original request. If the value of
replacementAllowed=`false`, then such replacement method for
generating an alternative resource URI and providing that to the
DASH client is not allowed.
[0181] The resulting techniques to cause an alternative
Representation to be requested and delivered may be implementation
dependent. For example, the MBMS client may return an 4xx error
code accompanied with or without an alternative Representation as
signaled by the baseURL value in the entity body of the HTTP
response, and rely on the DASH client to form an alternative
request. Here, the presence of the baseURL identifying an
alternative Representation is available in the response may be used
as a hint to the DASH client with the intelligence to directly
request that Representation as follow-up. Alternatively, the
baseURL "hint" may not be provided in the 4xx response, or the DASH
client may lack the intelligence to utilize such hint in generating
a new request for another Representation which may or may not
correspond to the allowed Representation from the MBMS client
perspective.
[0182] FIG. 17 is a conceptual diagram illustrating another example
architecture for supporting DASH over MBMS. It may be important to
specify the interface between BM-SC and eMBMS Client and the
interface between eMBMS Client and DASH Client in an appropriate
standard. For example, the standard may specify that the interface
between BM-SC and eMBMS Client shall comply with TS 26.346. The
standard may also specify that the interface between eMBMS Client
and DASH Client should follow TS 26.247 if DASH client and eMBMS
client are from different vendors. Contrasted with the example of
FIG. 16, FIG. 17 illustrates an example in which an interface
between a DASH client and an eMBMS client may conform to TS 26.247
(which may be, for example, HTTP/1.1). FIG. 17 illustrates a high
level architecture to allow DASH over MBMS to be fall back to DASH
over unicast.
[0183] FIGS. 18-23 are flow diagrams illustrating various example
call-flows associated with the network architecture of FIG. 17 for
DASH content delivery over broadcast and unicast transport.
Although described as corresponding to the network architecture of
FIG. 17, it should be understood that the techniques of FIGS. 18-23
may be performed by other devices, e.g., the devices in the
architectures of FIGS. 1, 2A, 2B, 6, 7, 8, and/or 15.
[0184] With respect to the example of FIG. 18, USD signaling may
include the data shown in Table 4 below for the eMBMS Client:
TABLE-US-00004 TABLE 4 Broadcast@BaseURL Unicast@BaseURL
http://www.cnn.com/512/ http://www.cnn.com/256/seg$Number$.3pg
seg$Number$.3pg http://www.cnn.com/128/seg$Number$.3pg
[0185] The MPD in this example may specify the following data,
where BaseURLs correspond to base portions of URLs for accessing
Segments:
BaseURL1=http://www.cnn.com/512/, RepresentationId="512";
[0186] Template=seg$Number$0.3 gp,
BaseURL2=http://www.cnn.com/256/, RepresentationId="256";
[0187] Template=seg$Number$0.3gp,
BaseURL3=http://www.cnn.com/128/, RepresentationId="128";
[0188] Template=seg$Number$0.3gp.
[0189] In the example of FIG. 18, it is assumed that the eMBMS
client does not have HTTP Proxy functions, but only has HTTP
redirector functions.
[0190] With respect to the example of FIG. 19, USD signaling may
include the data shown in Table 5 below for the eMBMS Client:
TABLE-US-00005 TABLE 5 Broadcast@BaseURL Unicast@BaseURL
http://www.cnn.com/512/ http://www.cnn.com/256/seg$Number$.3pg
seg$Number$.3pg http://www.cnn.com/128/seg$Number$.3pg
[0191] The MPD in this example may specify the following data,
where BaseURLs correspond to base portions of URLs for accessing
Segments:
BaseURL1=http://www.cnn.com/512/, RepresentationId="512";
[0192] Template=seg$Number$0.3gp,
BaseURL2=http://www.cnn.com/256/, RepresentationId="256";
[0193] Template=seg$Number$0.3gp,
BaseURL3=http://www.cnn.com/128/, RepresentationId="128";
[0194] Template=seg$Number$0.3gp.
[0195] In the example of FIG. 19, it is assumed that eMBMS client
has both HTTP Proxy and HTTP Redirector function.
[0196] With respect to the example of FIG. 20, USD signaling may
include the data shown in Table 6 below for the eMBMS Client:
TABLE-US-00006 TABLE 6 Broadcast@BaseURL Unicast@BaseURL
http://www.cnn.com/512/ http://www.cnn.com/512/seg$Number$.3pg
seg$Number$.3pg http://www.cnn.com/256/seg$Number$.3pg
http://www.cnn.com/128/seg$Number$.3pg
[0197] The MPD in this example may specify the following data,
where BaseURLs correspond to base portions of URLs for accessing
Segments:
BaseURL1.1=http://www.cnn.com/512/,
[0198] BaseURL1.2=http://localhost/512/,
RepresentationId="512";
[0199] Template=seg$Number$0.3gp,
BaseURL2=http://www.cnn.com/256/, RepresentationId="256";
[0200] Template=seg$Number$0.3gp,
BaseURL3=http://www.cnn.com/128/, RepresentationId="128";
[0201] Template=seg$Number$0.3gp.
[0202] In the example of FIG. 20, it is assumed that the eMBMS
client does not have HTTP Proxy function, but only has HTTP
Redirector function.
[0203] With respect to the example of FIG. 21, USD signaling may
include the data shown in Table 7 below for the eMBMS Client:
TABLE-US-00007 TABLE 7 Broadcast@BaseURL Unicast@BaseURL
http://www.cnn.com/512/ http://www.cnn.com/512/seg$Number$.3pg
seg$Number$.3pg http://www.cnn.com/256/seg$Number$.3pg
http://www.cnn.com/128/seg$Number$.3pg
[0204] The MPD in this example may specify the following data,
where BaseURLs correspond to base portions of URLs for accessing
Segments:
BaseURL1=http://www.cnn.com/;
RepresentationId="512"; Template=$RepresentationId$/seg$Number$0.3
gp,
RepresentationId="256";
Template=$Representagtion$/seg$Number$0.3gp,
RepresentationId="128";
Template=$Representagtion$/seg$Number$0.3gp.
[0205] In the example of FIG. 21, it is assumed that eMBMS client
does not have HTTP Proxy function, but only has HTTP Redirector
function.
[0206] With respect to the example of FIG. 22, USD signaling may
include the data shown in Table 8 below for the eMBMS Client:
TABLE-US-00008 TABLE 8 Broadcast@BaseURL Unicast@BaseURL
http://localhost/512/ http://www.cnn.com/256/seg$Number$.3pg
seg$Number$.3pg http://www.cnn.com/128/seg$Number$.3pg
[0207] The MPD in this example may specify the following data,
where BaseURLs correspond to base portions of URLs for accessing
Segments:
BaseURL1=http://localhost/512/, RepresentationId="512";
[0208] Template=seg$Number$0.3gp,
BaseURL2=http://www.cnn.com/256/, RepresentationId="256";
[0209] Template=seg$Number$0.3gp,
BaseURL3=http://www.cnn.com/128/, RepresentationId=""128";
[0210] Template=seg$Number$0.3gp.
[0211] In the example of FIG. 22, it is assumed that eMBMS client
does not have HTTP Proxy function, but only has HTTP Redirector
function.
[0212] With respect to the example of FIG. 23, USD signaling may
include the data shown in Table 9 below for the eMBMS Client:
TABLE-US-00009 TABLE 9 Broadcast@BaseURL Unicast@BaseURL
http://www.cnn.com/1024/ http://www.cnn.com/256/seg$Number$.3pg
seg$Number$.3pg http://www.cnn.com/512/
http://www.cnn.com/128/seg$Number$.3pg seg$Number$.3pg
[0213] The MPD in this example may specify the following data,
where BaseURLs correspond to base portions of URLs for accessing
Segments:
BaseURL1=http://www.cnn.com/1024/, RepresentationId="1024";
[0214] Template=seg$Number$0.3gp,
BaseURL2=http://www.cnn.com/512/, RepresentationId="512";
[0215] Template=seg$Number$0.3gp,
BaseURL3=http://www.cnn.com/256/, RepresentationId="256";
[0216] Template=seg$Number$0.3gp,
BaseURL4=http://www.cnn.com/128/, RepresentationId=""128";
[0217] Template=seg$Number$0.3gp.
[0218] In the example of FIG. 23, it is assumed that eMBMS client
does not have HTTP Proxy function, but only has HTTP Redirector
function.
[0219] FIG. 24 is a flowchart illustrating an example method for
signaling data related to a time-shifted buffer (TSB) depth in
accordance with the techniques of this disclosure. For purposes of
example, the method of FIG. 25 is explained with respect to the
components of FIG. 10, e.g., MSDC 1010 and TSB 1212. However, it
should be understood that the techniques for utilizing a
time-shifted buffer may be incorporated into any of the various
systems described herein, e.g., the systems of any of FIGS. 1, 7,
8, 9, 12, 13, and/or 17.
[0220] Initially, MSDC 1010 may receive a session description
protocol (SDP) message (2400). The SDP message may include an
attribute that defines a time-shifted buffer (TSB) depth.
Accordingly, MSDC 1010 may determine a value for the attribute
(also referred to as a TSB depth attribute) in the SDP message
(2402). The value of the TSB depth attribute may define the depth
of the TSB, e.g., in terms of seconds of playback for media data to
be stored in the TSB. For example, the value of the attribute may
define a maximum playback time, in seconds, that can be stored in
the TSB.
[0221] MSDC 1010 may therefore determine an amount of memory to be
allocated to form the TSB from the signaled depth (2404). For
example, assuming that the depth of the TSB is signaled in terms of
seconds of playback for media data, and assuming that a frame rate
is signaled for video data, MSDC may determine a number of video
frames to be stored in the TSB, as the product of the frame rate
(expressed in frames per second) and the number of seconds of media
data to be stored. MSDC 1010 may then determine an amount of memory
for the TSB based on the product of an average bitrate per frame
and the number of frames. MSDC 1010 may use similar concepts for
determining memory size for audio data, timed text data, and the
like.
[0222] MSDC 1010 may then allocate the determined amount of memory
to form the TSB (2406). Thus, as MSDC 1010 receives media data,
MSDC 1010 may store the received media data in the TSB (2408). A
playback application may use this buffered media data for
time-shifted application, such as for watching at a later time or
for performing a trick mode, such as fast forward or rewind. Of
course, the buffered data may also be used for substantially real
time playback.
[0223] In this manner, the method of FIG. 24 represents an example
of a method including receiving a session description protocol
(SDP) message including an attribute that defines a time-shifted
buffer (TSB) depth, determining an amount of memory for the TSB
based on a value of the attribute, allocating the determined amount
of memory to the TSB, and storing at least a portion of media data
associated with the SDP message in the TSB.
[0224] Those of ordinary skill in the art will understand that
information and signals may be represented using any of a variety
of different technologies and techniques. For example, data,
instructions, commands, information, signals, bits, symbols, and
chips that may be referenced throughout the above description may
be represented by voltages, currents, electromagnetic waves,
magnetic fields or particles, optical fields or particles, or any
combination thereof.
[0225] Those of ordinary skill will further appreciate that the
various illustrative logical blocks, modules, circuits, and
algorithm steps described in connection with the disclosure herein
may be implemented as electronic hardware, computer software, or
combinations of both. To clearly illustrate this interchangeability
of hardware and software, various illustrative components, blocks,
modules, circuits, and steps have been described above generally in
terms of their functionality. Whether such functionality is
implemented as hardware or software depends upon the particular
application and design constraints imposed on the overall system.
Skilled artisans may implement the described functionality in
varying ways for each particular application, but such
implementation decisions should not be interpreted as causing a
departure from the scope of the present disclosure.
[0226] In one or more examples, the functions described may be
implemented in hardware, software, firmware, or any combination
thereof. If implemented in software, the functions may be stored on
or transmitted as one or more instructions or code on a
computer-readable medium and executed by a hardware-based
processing unit. Computer-readable media may include
computer-readable storage media, which corresponds to a tangible
medium such as data storage media, or communication media including
any medium that facilitates transfer of a computer program from one
place to another, e.g., according to a communication protocol. In
this manner, computer-readable media generally may correspond to
(1) tangible computer-readable storage media which is
non-transitory or (2) a communication medium such as a signal or
carrier wave. Data storage media may be any available media that
can be accessed by one or more computers or one or more processors
to retrieve instructions, code and/or data structures for
implementation of the techniques described in this disclosure. A
computer program product may include a computer-readable
medium.
[0227] By way of example, and not limitation, such
computer-readable storage media can comprise 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. Also, any connection is properly termed a
computer-readable medium. For example, if instructions are
transmitted from a website, server, or other remote source using a
coaxial cable, fiber optic cable, twisted pair, digital subscriber
line (DSL), or wireless technologies such as infrared, radio, and
microwave, then the coaxial cable, fiber optic cable, twisted pair,
DSL, or wireless technologies such as infrared, radio, and
microwave are included in the definition of medium. It should be
understood, however, that computer-readable storage media and data
storage media do not include connections, carrier waves, signals,
or other transitory media, but are instead directed to
non-transitory, tangible storage media. Disk and disc, as used
herein, includes compact disc (CD), laser disc, optical disc,
digital versatile disc (DVD), floppy disk and blu-ray disc where
disks usually reproduce data magnetically, while discs reproduce
data optically with lasers. Combinations of the above should also
be included within the scope of computer-readable media.
[0228] 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 circuitry. Accordingly, the term
"processor," as used herein may refer to any of the foregoing
structure or any other structure suitable for implementation of the
techniques described herein. In addition, in some aspects, the
functionality described herein may be provided within dedicated
hardware and/or software modules configured for encoding and
decoding, or incorporated in a combined codec. Also, the techniques
could be fully implemented in one or more circuits or logic
elements.
[0229] The techniques of this disclosure may be implemented in a
wide variety of devices or apparatuses, including a wireless
handset, an integrated circuit (IC) or a set of ICs (e.g., a chip
set). Various components, modules, or units are described in this
disclosure to emphasize functional aspects of devices configured to
perform the disclosed techniques, but do not necessarily require
realization by different hardware units. Rather, as described
above, various units may be combined in a codec hardware unit or
provided by a collection of interoperative hardware units,
including one or more processors as described above, in conjunction
with suitable software and/or firmware.
[0230] The detailed description set forth above, in connection with
the appended drawings, is intended as a description of various
configurations and is not intended to represent the only
configurations in which the concepts described herein may be
practiced. The detailed description includes specific details for
the purpose of providing a thorough understanding of the various
concepts. However, it will be apparent to those skilled in the art
that these concepts may be practiced without these specific
details. In some instances, well-known structures and components
are shown in block diagram form in order to avoid obscuring such
concepts.
[0231] Various examples have been described. These and other
examples are within the scope of the following claims.
* * * * *
References