Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20040196852 A1
Publication typeApplication
Application numberUS 10/778,941
Publication dateOct 7, 2004
Filing dateFeb 13, 2004
Priority dateFeb 13, 2003
Also published asCA2515952A1, EP1593046A2, EP1593047A2, EP1593047A4, EP1593107A2, EP1593107A4, US7558869, US20040193762, US20040196849, WO2004072764A2, WO2004072764A3, WO2004072765A2, WO2004072765A3, WO2004072766A2, WO2004072766A3
Publication number10778941, 778941, US 2004/0196852 A1, US 2004/196852 A1, US 20040196852 A1, US 20040196852A1, US 2004196852 A1, US 2004196852A1, US-A1-20040196852, US-A1-2004196852, US2004/0196852A1, US2004/196852A1, US20040196852 A1, US20040196852A1, US2004196852 A1, US2004196852A1
InventorsEmre Aksu, Igor Curcio, David Leon, Viktor Varsa, Ru-Shang Wang
Original AssigneeNokia Corporation
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Method for signaling client rate capacity in multimedia streaming
US 20040196852 A1
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.
Images(2)
Previous page
Next page
Claims(9)
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→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.

Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7720970 *Sep 30, 2005May 18, 2010Microsoft CorporationMethod for processing received networking traffic while playing audio/video or other media
US8107438Jun 18, 2008Jan 31, 2012Sprint Spectrum L.P.Method for initiating handoff of a wireless access terminal based on the reverse activity bit
US8204000Jul 23, 2009Jun 19, 2012Sprint Spectrum L.P.Achieving quality of service (QoS) by using the reverse activity bit (RAB) in creation of neighbor lists for selected access terminals
US8245088Jun 30, 2009Aug 14, 2012Sprint Spectrum L.P.Implementing quality of service (QoS) by using hybrid ARQ (HARQ) response for triggering the EV-DO reverse activity bit (RAB)
US8254930 *Feb 18, 2009Aug 28, 2012Sprint Spectrum L.P.Method and system for changing a media session codec before handoff in a wireless network
US8310929Jun 4, 2009Nov 13, 2012Sprint Spectrum L.P.Method and system for controlling data rates based on backhaul capacity
US8363564Mar 25, 2010Jan 29, 2013Sprint Spectrum L.P.EVDO coverage modification based on backhaul capacity
US8472952Nov 30, 2010Jun 25, 2013Sprint Spectrum L.P.Discovering a frequency of a wireless access point
US8515434Apr 8, 2010Aug 20, 2013Sprint Spectrum L.P.Methods and devices for limiting access to femtocell radio access networks
US8578056 *Mar 31, 2008Nov 5, 2013Symantec CorporationOptimized application streaming for just in time compiled components
US8619674Nov 30, 2010Dec 31, 2013Sprint Spectrum L.P.Delivery of wireless access point information
US8644176Mar 11, 2010Feb 4, 2014Sprint Spectrum L.P.Methods and systems for supporting enhanced non-real-time services for real-time applications
US8677029Jan 5, 2012Mar 18, 2014Qualcomm IncorporatedUser input back channel for wireless displays
WO2012100218A1 *Jan 20, 2012Jul 26, 2012Qualcomm IncorporatedNegotiating capabilities between a wireless sink and a wireless source device
Classifications
U.S. Classification370/395.21, 709/231, 375/E07.013, 375/E07.016, 709/233
International ClassificationG06F15/16, H04N7/24, H04L12/28, H04L29/08, H04L12/56, H04L29/06
Cooperative ClassificationH04L65/608, H04L65/4092, H04L65/607, H04L65/4084, H04L65/80, H04L49/9078, H04N21/6377, H04N21/6437, H04N21/6332, H04L29/06027, H04N21/6373, H04N21/643, H04N21/6375, H04N21/2401, H04N21/2662, H04L47/10, H04N21/6131, H04L47/6255, H04N21/6125, H04L47/263, H04N21/44004, H04N21/658, H04N21/41407, H04L69/329, H04L67/42, H04L67/322, H04L69/24
European ClassificationH04N21/6373, H04N21/2662, H04N21/658, H04N21/6377, H04N21/6332, H04N21/6437, H04N21/6375, H04N21/24B, H04L29/06M4S4, H04N21/44B, H04L47/10, H04L49/90Q3, H04L47/62G1, H04N21/643, H04L29/06M4S6, H04N21/61D3, H04L47/26A, H04N21/61D4, H04L29/06C8, H04N21/414M, H04L29/06P, H04L29/06C2, H04L29/08N31Q, H04L29/08A7, H04L29/06M8, H04L29/06M6P, H04L29/06M6E
Legal Events
DateCodeEventDescription
Jun 14, 2004ASAssignment
Owner name: NOKIA CORPORATION, FINLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AKSU, EMRE BARIS;CURCIO, IGOR DANILO DIEGO;LEON, DAVID;AND OTHERS;REEL/FRAME:015463/0337
Effective date: 20040401