U.S. patent application number 10/778941 was filed with the patent office on 2004-10-07 for method for signaling client rate capacity in multimedia streaming.
This patent application is currently assigned to Nokia Corporation. Invention is credited to Aksu, Emre Baris, Curcio, Igor Danilo Diego, Leon, David, Varsa, Viktor, Wang, Ru-Shang.
Application Number | 20040196852 10/778941 |
Document ID | / |
Family ID | 32872992 |
Filed Date | 2004-10-07 |
United States Patent
Application |
20040196852 |
Kind Code |
A1 |
Aksu, Emre Baris ; et
al. |
October 7, 2004 |
Method for signaling client rate capacity in multimedia
streaming
Abstract
A method for signaling and negotiation between a
resource-limited client and a server in a multimedia streaming
service regarding packet data delivery. In order to avoid dropping
packets at the client side due to its maximum packet rate
capability, the client signals to the server declaring the maximum
packet rate capability. This capability can be signaled to the
client via a capability exchange mechanism or using a multimedia
streaming protocol. The client inserts a parameter indicative of
the maximum packet data rate capability in a request sent to
server. It is up to the server to take the necessary action and
make the packet delivery rate adjustment.
Inventors: |
Aksu, Emre Baris; (Tampere,
FI) ; Curcio, Igor Danilo Diego; (Tampere, FI)
; Leon, David; (Irving, TX) ; Varsa, Viktor;
(Irving, TX) ; Wang, Ru-Shang; (Coppell,
TX) |
Correspondence
Address: |
WARE FRESSOLA VAN DER SLUYS &
ADOLPHSON, LLP
BRADFORD GREEN BUILDING 5
755 MAIN STREET, P O BOX 224
MONROE
CT
06468
US
|
Assignee: |
Nokia Corporation
|
Family ID: |
32872992 |
Appl. No.: |
10/778941 |
Filed: |
February 13, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60447264 |
Feb 13, 2003 |
|
|
|
60448309 |
Feb 14, 2003 |
|
|
|
60448284 |
Feb 14, 2003 |
|
|
|
60448299 |
Feb 14, 2003 |
|
|
|
Current U.S.
Class: |
370/395.21 ;
375/E7.013; 375/E7.016; 709/231; 709/233 |
Current CPC
Class: |
H04L 69/329 20130101;
H04L 69/24 20130101; H04L 67/42 20130101; H04L 47/6255 20130101;
H04N 21/6125 20130101; H04N 21/6131 20130101; H04N 21/6377
20130101; H04N 21/41407 20130101; H04L 29/06027 20130101; H04N
21/6373 20130101; H04L 47/263 20130101; H04L 67/322 20130101; H04N
21/2662 20130101; H04L 47/10 20130101; H04L 65/4084 20130101; H04L
65/80 20130101; H04N 21/658 20130101; H04L 65/4092 20130101; H04L
65/608 20130101; H04N 21/643 20130101; H04N 21/44004 20130101; H04L
49/9078 20130101; H04N 21/2401 20130101; H04L 65/607 20130101; H04N
21/6332 20130101; H04N 21/6437 20130101; H04N 21/6375 20130101 |
Class at
Publication: |
370/395.21 ;
709/233; 709/231 |
International
Class: |
H04L 012/28; G06F
015/16; H04L 012/56 |
Claims
What is claimed is:
1. A method of controlling streaming data delivery in a multimedia
streaming network having a server for providing the streaming data
to a client at a packet data rate, said method comprising:
declaring in a message a maximum data rate capability at the
client; and signaling the message to the server.
2. The method of claim 1, wherein the message comprises a request
sent to the server via a capability exchange mechanism, and the
request comprises a capability profile for indicating the maximum
data rate capability.
3. The method of claim 2, wherein the maximum data rate capability
is indicated by a capability parameter in the capability
profile.
4. The method of claim 3, wherein the capability parameter is
included in an RTSP DESCRIBE request.
5. The method of claim 4, wherein the maximum data rate capability
is indicated in capability information residing in a capability
exchange server, and wherein the request includes a URL pointing to
the capability information.
6. The method of claim 5, wherein the server, responding to the
request, retrieves the capability parameter from the capability
exchange server via the capability exchange mechanism for adjusting
the packet data rate.
7. The method of claim 6, further comprising the server adjusts the
packet data rate based on capability parameter in order to conform
to the maximum data rate capability at the client.
8. The method of claim 1, wherein the message is signaled to the
server via a multimedia streaming control protocol.
9. The method of claim 9, wherein the message comprises a request
including a RTSP header extension indicative of the maximum data
rate capability.
Description
[0001] This patent application is based on and claims priority to
U.S. Provisional Applications No. 60/447,264, filed Feb. 13, 2003;
No. 60/448,309, filed Feb. 14, 2003; No. 60/448,284, filed Feb. 14,
2003 and No. 60/448,299, filed Feb. 14, 2003.
CROSS REFERENCE TO RELATED PATENT APPLICATIONS
[0002] This patent application is related to U.S. Patent
Applications, Docket No. 944-001.103-4, and Docket No.
944-001.103-5, both assigned to the assignee of the present patent
application and filed on even date herewith.
FIELD OF THE INVENTION
[0003] The present invention relates generally to multimedia
streaming and, more particularly, to signaling of client's packet
rate capacity in multimedia streaming sessions.
BACKGROUND OF THE INVENTION
[0004] In a multimedia streaming service, there are three
participants involved: a streaming server, a streaming client and
an underlying network which provides the connectivity between the
server and the client. The server provides the functionality to
deliver the multimedia streaming content to the client. For that
purpose, the client and server communicate with each other over the
network regarding the methods of capability exchange, content
delivery method negotiation, content delivery control, and so
forth. Such information exchange can be carried out via
well-defined network protocols.
[0005] For a multimedia streaming session to be set up and started
successfully, the server and the client need to support a minimal
set of protocols, which are selected as standard protocols by the
service. An example of such a service can be found in 3GPP TS
26.234 V5.1.0, "Transparent End-to-End Packet Switched Streaming
Service (PSS); Protocols and Codecs (Release 5)", June 2002,
hereafter referred to as TS 26.234). Examples of such a set of
protocols used in 3G PSS are SDP (see, for example, IFTF TFC 2327:
"SDP: Session Description Protocol", Handley et al., April 1998),
RTSP (see, for example, IETF RFC 2326: "Real Time Streaming
Protocal (RTSP)", Schulzrinne et al., April 1998) and RTP/RTCP
(see, example, IETF RFC 1889: "RTP: A Transport Protocol for
Real-Time Applications", Schulzrinne et al., January 1996).
[0006] In a streaming service, the client may be an application
running on a device that is resource-limited. It may be the case
that the client could not handle more than a well-defined number of
packets arriving to its receiving node.
[0007] In most of the services, the server and client negotiate on
the available bandwidth to use for the content delivery. However,
if the client is a resource-limited device, then it also has a
limitation on the maximum number of packets that it can actually
capture from its receiving node. Most of the time, this limitation
is not signaled.
[0008] One particular case where this can be a problem is in audio
streaming, where there can be data delivery at a packet rate of 50
packets/second (e.g., AMR-NB codec with 1 AMR-NB frame/payload). If
there are two audio media sources delivering data to the same
client at the same time (or in a different case when there is also
a video source delivering media packets at the packet rate of 50
packets/second, in addition to the audio media source), there will
be a 100 packets/second packet delivery rate, which can be too high
for the client to handle without packet dropping.
[0009] Therefore, there is a certain need to negotiate this value
between the client and server to have a well-adapted session.
SUMMARY OF THE INVENTION
[0010] The present invention provides a method of signaling and
negotiation between a resource-limited client and a server in a
multimedia streaming service regarding the data delivery from the
server to the client. In particular, the present invention provides
a method of signaling the maximum packet rate capability of the
client to the server so that the server does not overrun this
maximum packet rate value, causing packet drops at the client side
or crashing the client mobile device. The method can be carried out
using a capability exchange mechanism, or using a multimedia
streaming control protocol.
[0011] Thus, the present invention provides a method for
controlling streaming data delivery in a multimedia streaming
network having a server for providing the streaming data to a
client at a packet data rate. The method comprises:
[0012] declaring in a message a maximum data rate capability at the
client; and
[0013] signaling the message to the server.
[0014] According to the present invention, the message comprises a
request sent to the server via a capability exchange mechanism, and
the request comprises a capability profile for indicating the
maximum data rate capability. The maximum data rate capability is
indicated by a capability parameter in the capability profile, and
the capability parameter is included in an RTSP DESCRIBE
request.
[0015] Furthermore, the maximum data rate capability is indicated
in capability information residing in a capability exchange server,
and wherein the request includes a URL pointing to the capability
information. The server, responding to the request, retrieves the
capability parameter from the capability exchange server via the
capability exchange mechanism for adjusting the packet data
rate.
[0016] The server may adjust the packet data rate based on
capability parameter in order to fit the maximum data rate
capability at the client.
[0017] Alternatively, the message is signaled to the server via a
multimedia streaming control protocol, and the message comprises a
request including a RTSP header extension indicative of the maximum
data rate capability.
BRIEF DESCRIPTION OF THE DRAWINGS
[0018] FIG. 1 shows a declaration by a client as part of the
signaling and negotiation process, according to the present
invention.
DETAILED DESCRIPTION OF THE INVENTION
[0019] The method of signaling and negotiation between a client and
a server in a multimedia streaming service regarding the adaptation
of the data delivery process, according to the present invention,
can be carried out via a capability exchange mechanism or via a
Multimedia Streaming Control Protocol. The Multimedia Streaming
Control Protocol is well-defined and standardized within the
service context. The capability exchange mechanism is known in the
art and, therefore, is not part of the present invention. The
adaptation of the data delivery process is based on the maximum
packet rate capability of a resource-limited client. The client
uses a MaxPacketRate value (packets/second) to define the maximum
amount of packets it can handle in a certain time interval.
[0020] When the signaling is carried out via a capability exchange
mechanism, the procedure can be based on the standard as set forth
in TS 26.234, for example.
[0021] Let the attribute "MaxPacketRate" be defined in the RDF
(Resource Description Framework) Schema vocabulary for signaling
the value of the maximum packet handling rate capability of the
client. The attribute is defined in packets-per-second units.
[0022] The signaling procedure is as follows:
[0023] Client declares the MaxPacketRate value as a capability
parameter in its capability profile. For example, the client sends
an RTSP DESCRIBE request to the server with a URI pointing to the
client capability information residing in a capability exchange
server.
[0024] The server retrieves the capability declaration of the
client from the capability exchange server via the capability
exchange mechanism. The declaration has the part for the
client-side streaming capabilities, as shown in FIG. 1. The bold
lines in the declaration represent the maximum packet rate
capability of the client. Having obtaining the MaxPacketRate value,
the server has the information about the current packet rate to
adjust the maximum packet reception rate capability of the client.
The server can then adjust the maximum packet rate delivered to the
client. However, it is up to the server to take the necessary
action and make the packet delivery related adjustments.
[0025] When the signaling is carried out via a Multimedia Streaming
Control Protocol, the client can use the well-defined RTSP option
tag, and the RTSP header extension (see, for example, IETF RFC
2326).
[0026] Let "x-maxpacketratesupport" be an RTSP option-tag.
[0027] Let "x-maxpacketrate" be an RTSP header extension defined in
packets-per-second units.
[0028] The client is assumed to know the RTSP URL (universal
resource locator) for the multimedia session beforehand.
[0029] The signaling procedure is as follows:
[0030] Client declares the MaxPacketRate value in a DESCRIBE
request sent with the x-maxpacketrate value signaled:
[0031] Client.fwdarw.Server:
[0032] DESCRIBE rtsp://foo/twister RTSP/1.0
[0033] CSeq: 1
[0034] Require: x-maxpacketratesupport
[0035] x-maxpacketrate: 70
[0036] If the server does not make use of the maximum packet rate
capability of the client, server responds either with an RTSP 551
"Option Not Supported" message containing the "Unsupported:
x-maxpacketrate" line, or with an RTSP 200 OK message containing
the "Unsupported: x-maxpacketrate" line. By the usage of RTSP
"Require" header, the client understands whether the server takes
the parameter into account or not. If the server takes the
parameter into account, the client can signal the updated maximum
packet rate capability during the session, using any RTSP message
body.
[0037] If the server makes use of this parameter, the server checks
the RTSP request and sees that it contains the well-defined
x-maxpacketrate value. It retrieves the value from the RTSP request
message.
[0038] After knowing the MaxMacketRate value in requests sent by
the client, the server uses the value to adjust the maximum packet
rate delivered to the client. However, it is up to the server to
take the necessary action and make the packet delivery related
adjustments.
[0039] It should be noted that the maximum input packet rate coming
from a network interface, which is sustainable by the client device
can be defined as MaxPacketRate in the RDF Schema vocabulary, but
it can be called differently. Likewise, "x-maxpacketrate" or a
different name can be used in an RTSP message, so long as it can be
used to specify the maximum input packet rate coming from the
network interface, which is sustainable by the client device.
"x-maxpacketratesupport" or a different name can be used in an RTSP
"Require" header, so long as it can be used to specify the
capability of the server to understand and take into account the
maximum input packet rate header transmitted in any RTSP message
body sent by the client device.
* * * * *