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.

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.

Claims

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.