Dispatch Zhou, Ed.
Internet-Draft Huawei Technologies, Inc.
Intended status: Standards Track January 16, 2010
Expires: July 20, 2010
draft-zhipeng-dispatch-dynamic-adaptation-00
Abstract
This document describes controls and service flow for Media Server on
the scenarios and requirements for dynamic adaptation of the terminal
types, media format and transport bit rate (Dynamic Bandwidth
Allocation), etc. To fulfill the requirements above, an Adaptor
entity is introduced in the architecture in the case of the dynamic
media adaptation.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 20, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Zhou Expires July 20, 2010 [Page 1]
Internet-Draft January 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Dynamic Adaptations . . . . . . . . . . . . . . . . . . . . . 4
3.1. Dynamic Bandwidth Allocation . . . . . . . . . . . . . . . 4
3.2. Dynamic Bandwidth Allocation with Dynamic Media Format
Adaptation . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Dynamic Terminal Adaptation with dynamic Media Format
Adaptation . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Transcoder . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Media Adaptor . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Instances of application . . . . . . . . . . . . . . . . . 9
4.2. Interface between MediaAdaptor and MediaServer . . . . . . 9
4.3. Media Adaptor Interface XML Schema . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Zhou Expires July 20, 2010 [Page 2]
Internet-Draft January 2010
1. Introduction
Nowadays the application is much variable and plentiful. For the
deployment of content service, the Media Server should always support
multiple media types and multiple terminal types, such as PC or
Mobile Phone.
In fact the concerns of media type and terminal type are much
relative since the service for PC and Mobile Phone will always adopt
different media type according to the machine capability in the
applications, exp. in the video area.
Terminal adaptation and Media adaptation will bring much economical
benefit for the service deployment if the server owns the ability of
dynamic adaptation.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology
User Equipment(UE): The device used by end-user to communicate.
Media Server (MS): The device that stores and shares media, esp.
provides media service to the UE.
Terminal Adaptation: The server MUST support multiple media format
for the same content and will dynamically select a suitable media
format to a terminal according to the terminal type and its device
capability.
Media Adaptation: The server MUST support multiple media format and
variant bit rate and will be able to adjust the media format or bit
rate when detecting the bandwidth or other communication conditions
are changing distinctly.
Media Adaptor(MA): A functional entity to fulfill dynamic adaptation
between UE and Server. It will forward the media stream from a
selected Media Server to the UE.
Transcoder: A functional entity to transform the media from one
format to another format, such as transforming a H.264 video of CIF
size to H.263 video of QCIF size.
Zhou Expires July 20, 2010 [Page 3]
Internet-Draft January 2010
3. Dynamic Adaptations
This section addresses several scenarios and relevant methods on the
Dynamic Adaptation of Media Server.
3.1. Dynamic Bandwidth Allocation
The figure 1 below depicts the general procedure for bit-rate
adjusting during the media service.
UE MS
| |
|<============== One-way RTP stream at rate X ============|
| |
| RTCP(SR) |
|<--------------------------------------------------------|
| RTCP(RR) |
|-------------------------------------------------------->|
| |
| |--+ Rate
| | | Adjusting
| |<-+
| |
|<============== One-way RTP stream at rate Y ============|
| |
. .
. .
Figure 1. Dynamic Bandwidth Allocation
Since the real bandwidth on a Connectionless Link will always jitter
during the service and hence bring much bad experience for the User.
If the jittering is quite a bit serious, the Dynamic Bandwidth
Allocation method will be much preferred.
To monitor the network conditions, the MS will occasionally send RTCP
SR(Sender Report) to the UE; UE will return the RTCP RR(Receiver
Report) to the MS.The SR will carry a TimeStamp;the RR will contain
the LSR(Last SR) and DLSR(Delay since last SR), hence the MS will get
out the RTT(Round-Trip Time). Meantime, the RR contains the
"fraction lost" element and the "interarrival jitter" element to
indicate the packet lost rate and the jittering rate,see [RFC3550].
By determining the RTT value and the information contained in the RR,
the MS will get known of the network's condition. If the MS judges
that the network bandwidth has taken a big change, then it will
adjust the bit rate of the media stream according to a policy.
For example, in the MS, an interval threshold and a count threshold
Zhou Expires July 20, 2010 [Page 4]
Internet-Draft January 2010
will be set. Once the accumulated occasions that the RTT is less
than the interval threshold has achieved the count threshold, the MS
will adjust the bit rate to a small value. Similarly, once the
accumulated occasions of which the interval is bigger than the
interval threshold has achieved the count threshold, the MS will
adjust the bit rate to a bigger value. The MS will initiate the UE
to accept the media stream on the updated bit rate.
3.2. Dynamic Bandwidth Allocation with Dynamic Media Format Adaptation
In the Dynamic Bandwidth Allocation process, it can also fulfill the
Dynamic Media Format Adaptation, such as transform the media stream
from CIF size media to QCIF size media when the bandwidth has
decreased, or transform the media stream from QCIF size media to CIF
size media when the bandwidth has increased.
According to the method described in section 3.1, the MS can get
known of the network's status. If the MS judges that the network
bandwidth has taken a big change, then it will adjust the bit rate of
the media stream and switch the media format as well according to a
policy. The Figure 2 below depicts the procedure.
UE MS
| |
|<==== One-way RTP stream (format A,rate X)=======|
| |
| RTCP(SR) |
|<------------------------------------------------|
| RTCP(RR) |
|------------------------------------------------>|
| |
| |--+ Rate Adjusting &
| | | Media Format
| |<-+ Switching
| |
|<==== One-way RTP stream (format B,rate Y)=======|
| |
. .
. .
Figure 2. Dynamic Media Format Adaptation
3.3. Dynamic Terminal Adaptation with dynamic Media Format Adaptation
Currently the adaptation to multiple terminals is essential required
for the Media Server since the media processing capability is a key
feature for most types of terminals including smart phones or
laptops. While there are plenty of media types and countless devices
Zhou Expires July 20, 2010 [Page 5]
Internet-Draft January 2010
with very variant processing capability, so the server should has
very strong media adaptation capability to serve for each kind of
terminal. Generally, it will support most of the popular media
formats.
UE-1 MS UE-2
| | |
| | Capability Adaptation |
| |<----------------------------->|
| |= Media (Format A at rate X)==>|
| Capability Adaptation | |
|<----------------------------->| |
| | |
|<= Media (Format B at rate Y)==| |
| | |
. . .
. . .
Figure 3. Dynamic Adaptation to Terminals
For the streaming service of a media file, the MS can transform the
media file in different format (such as the H.264 or flash format)
respectively and then encapsulate the media of each format into
packets (e.g. RTP packets) and store them in the server. Just by
inserting the indexes (such as offset from the media start) properly
in each file, the MS can easily provide general steaming service of
files according to the instruction of the UE(such as play, locate,
backward or forward). Since the MS has prepared well multiple media
formats for the media files, it can adapt to multiple format
requirements when serving for different terminals.
3.4. Transcoder
The Media Server can either be fixed with the transcoding ability or
just depend on an independent Transcoder entity, shown in Figure 4
and 5.
Zhou Expires July 20, 2010 [Page 6]
Internet-Draft January 2010
+----+----+
| UE-1 |<----------+
+----+----+ | +----+-----+
| |Transcoder|
+----+----+ | +----+-----+
| UE-2 |<----------+------------>| Media |
+----+----+ | | Server |
| +----+-----+
+----+----+ |
| UE-3 |<----------+
+----+----+
Figure 4. Media Server with Combined Transcoder
+-----+-----+
+------->| Media |<------+
| | Server | |
| +-----+-----+ |
| |
| |
+-----+-----+ | +-----+-----+ | +-----+-----+
| UE |<-------+------->| Media |<------+------>| Transcoder|
+-----+-----+ | | Server | | | |
| +-----+-----+ | +-----------+
| |
| |
| +-----+-----+ |
| | Media | |
+------->| Server |<------+
+-----+-----+
Figure 5. Media Server with Independent Transcoder
For the case that there is an independent Transcoder entity besides
the Media Server, the process of Media Format adaptation can be
illustrated as Figure 6 below.
Zhou Expires July 20, 2010 [Page 7]
Internet-Draft January 2010
UE MS Transcoder
| | |
| |== Media in Format A at rate X=>|
| |<= Media in Format A at rate Y==|
| |<= Media in Format B at rate X==|
| |<= Media in Format B at rate Y==|
| |<= Media in Format C at rate Y==|
| Capability Adaptation | |
|<------------------------------>| |
| | |
|<= Media in Format C at rate Y==| |
. . .
. . .
Figure 6. Adaptation Provision with Transcoder
4. Media Adaptor
In last section, several scenarios and processes for Dynamic
Adaptation have been depicted. An Adaptor can be deployed between
the UEs and Servers to fulfill the function as dynamic adjustment in
the real time service. The topology is shown in Figure 7 below.
+----+----+
+---------->| Media |<-----+
| | Server | |
| +----+----+ |
| |
| |
+---+---+ +----+----+ +----+----+ | +----+-----+
| UE |<------>| Media |<---->| Media |<-----+----->|Transcoder|
+---+---+ | Adaptor | | Server | | | |
+----+----+ +----+----+ | +----------+
| |
| |
| +----+----+ |
| | Media | |
+---------->| Server |<-----+
+----+----+
Figure 7. The Media Serving Architecture with a Media Adaptor
Generally, the Media Adaptor should conduct the dynamic adaptation as
described before and just select the proper media stream from a Media
Server and then forward the stream to the UE during the real time
media service. This architecture is beneficial for the modular
design and deployment if the adaptation function is splitted from the
Media Server to the specific Media Adaptor.
Zhou Expires July 20, 2010 [Page 8]
Internet-Draft January 2010
Regarding the architecture above, the interface between UE and Media
Adaptor should be as normal as the interface between UE and Media
Server in the previous figures. Hence the interface between Media
Adaptor and Media Server is invisible to the UE and should be defined
in this document and it can be rather simple as proposed. For
example, the Media Adaptor will hold constant media streams of
several formats at several bit rates with Media Servers, and will
select and forward the proper media stream to the UE once the Media
Adaptor detects the big change of bandwidth between UE and Media
Adaptor.
4.1. Instances of application
A suitable application for this architecture is the "Triple screen"
scenario. As for different kinds of terminals such as Mobile Phone,
TV and PC, there are respective media service systems. To converge
the different media serving capabilities for the UE, the Media
Adaptor will allocate the Media Server when receiving the application
request from the UE.
Besides, this architecture makes sense to efficiently make use of the
existing servers( to server for as many requests as possible, to make
use of the servers as long as possible). The task of taking the
adaptation with regards to different services and terminals can be
splitted from the media servers and be put on the special adaptor
server(Media Adaptor), hence the media servers focus on the media
providing, does not frequently take some changes(switches) during the
services. So the total service providing of the system will be
enhanced. For example, three media servers provide three different
streams respectively. The adaptor is responsible for allocating and
forwarding the streams to the target terminals. That will avoid much
adaptations on the media server. Therefore the media capability of
the media servers can be mostly utilized during the service.
Another, this system can make use of some old servers as best as
possible. For example, a server does not support much media formats,
so does not own much adaptation capability needed for current
service.Therefore it can merely provide the media that it supports
while some other new media servers can provide the new format
streams. By this way the system containing these different servers
will own enough adaptation capability while with the least cost.
4.2. Interface between MediaAdaptor and MediaServer
This section gives the general useful controls between Media Adaptor
and Media Server, including: Play, Change, Stop. "Play" or "Stop"
instruction is used to setup or teardown one content. Change
instruction is used to alter the bitrate.For VOD service, the
Zhou Expires July 20, 2010 [Page 9]
Internet-Draft January 2010
instructions will also include the Forward and Backward.
Two types of message are defined as below. One is
"mediaAdaptationRequest", the other one is
"mediaAdaptationResponse".In the Request, it will contain the
instruction such as "Play" or 'Stop" and the SDP packet which will
indicate the detail information including the media title and media
format, etc.( TODO: to be optimized in the later versions.)
Zhou Expires July 20, 2010 [Page 10]
Internet-Draft January 2010
--
#####################################################
ma-request TYPE
#####################################################
-->
<!-- ma-request -->
<xsd:complexType name="ma-requestType">
<xsd:complexContent>
<xsd:sequence>
<choice>
<element name="Play" type="string"/>
<element name="Stop" type="string"/>
<element name="Change" type="sting"/>
</choice>
// contains the relevant information of the Media Stream
<element name="SDP" type="string"/>
</sequence>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ma-request" type="ma-requestType" />
<!--
#####################################################
ma-response TYPE
#####################################################
-->
<!-- ma-response -->
<xsd:complexType name="ma-responseType">
<xsd:complexContent>
<xsd:element name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ma-response" type="ma-responseType" />
4.3. Media Adaptor Interface XML Schema
<?xml version="1.0"?>
Zhou Expires July 20, 2010 [Page 11]
Internet-Draft January 2010
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:dispatch:ma"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ma="urn:ietf:params:xml:ns:dispatch:ma"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xsd:element name="ma-message" type="ma-message-type" />
<xsd:complexType name="ma-message-type">
<xsd:sequence>
<xsd:choice>
<xsd:element name="mediaAdaptationRequest"
type="ma:mediaAdaptationRequestType"/>
<xsd:element name="mediaAdaptationResponse"
type="ma:mediaAdaptationResponseType"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:complexType name="mediaAdaptationRequestType">
<xsd:complexContent>
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="mediaAdaptationResponseType">
<xsd:complexContent>
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexContent>
</xsd:complexType>
<!-- DATATYPES -->
Zhou Expires July 20, 2010 [Page 12]
Internet-Draft January 2010
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[0-9][0-9][0-9]"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
5. Security Considerations
This document describes the architectural framework and relevant
processes to be used for the requirements of all kinds of dynamic
adaptations in the media service. The requirement of security can
refer to the[RFC5567].
6. IANA Considerations
IANA Considerations to be included in later versions of this
document.
7. Acknowledgements
Many thanks to all the members in this area and my colleagues as this
document has absorbed many precious ideas and experiences,esp. the
valuable discussions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
8.2. Informative References
[RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009.
Zhou Expires July 20, 2010 [Page 13]
Internet-Draft January 2010
Author's Address
Zhipeng Zhou (editor)
Huawei Technologies, Inc.
Floor 2, Building A, NO.48, Ning Nan AV.,
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-82276771
Email: zhouzp@huawei.com
Zhou Expires July 20, 2010 [Page 14]