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 date7 Oct 2004
Filing date13 Feb 2004
Priority date13 Feb 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]
    [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.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5565924 *18 Jan 199615 Oct 1996Lucent Technologies Inc.Encoder/decoder buffer control for variable bit-rate channel
US5959973 *19 Mar 199728 Sep 1999Alcatel Alsthom Compagnie Generale D'electriciteMethod to control data flow rate, queuing network node and packet switching network
US6175856 *30 Sep 199616 Jan 2001Apple Computer, Inc.Method and apparatus for dynamic selection of compression processing during teleconference call initiation
US6212194 *5 Aug 19983 Apr 2001I-Cube, Inc.Network routing switch with non-blocking arbitration system
US6222823 *10 Sep 199724 Apr 2001British Telecommunications Public Limited CompanyBroadband switching system
US6330286 *8 Jun 200011 Dec 2001Sarnoff CorporationFlow control, latency control, and bitrate conversions in a timing correction and frame synchronization apparatus
US6453336 *14 Sep 199817 Sep 2002Siemens Information And Communication Networks, Inc.Video conferencing with adaptive client-controlled resource utilization
US6466980 *17 Jun 199915 Oct 2002International Business Machines CorporationSystem and method for capacity shaping in an internet environment
US6570921 *9 Jul 199927 May 2003Koninklijke Philips Electronics N.V.Data compression assembly having several data-compression channels
US6778525 *31 Aug 200017 Aug 2004Verizon Communications Inc.Automated service provisioning in combination of vertical services and digital subscriber line domains
US6885861 *24 Aug 200126 Apr 2005Nokia CorporationService mobility and recovery in communication networks
US6909702 *20 Aug 200121 Jun 2005Qualcomm, IncorporatedMethod and apparatus for out-of-band transmission of broadcast service option in a wireless communication system
US6937770 *28 Dec 200030 Aug 2005Emc CorporationAdaptive bit rate control for rate reduction of MPEG coded video
US7421508 *8 Feb 20022 Sep 2008Nokia CorporationPlayback of streamed media
US7467220 *19 Mar 200416 Dec 2008Microsoft CorporationMedia streaming techniques and systems
US7720096 *30 Dec 200518 May 2010Microsoft CorporationRTP payload format for VC-1
US20020004840 *5 Jul 200110 Jan 2002Hideaki HarumotoStreaming method and system for executing the same
US20020099969 *18 Jun 200125 Jul 2002Takashi YamasakiData input and output device using timer function
US20020142769 *26 Oct 20013 Oct 2002Richard TaylorProvision of services via an information technology network
US20020142796 *30 Mar 20013 Oct 2002Gregory SuttonAntenna switch assembly, and associated method, for a radio communication station
US20030097460 *18 Nov 200222 May 2003Anritsu CorporationRelay apparatus and relay method suitable for performing communication to ensure quality of service
US20030131353 *11 Dec 200210 Jul 2003Rolf BlomMethod of rights management for streaming media
US20030133545 *29 Oct 200217 Jul 2003Jean-Michel RossetData processing system and method
US20030221014 *24 May 200227 Nov 2003David KosibaMethod for guaranteed delivery of multimedia content based on terminal capabilities
US20030236912 *24 Jun 200225 Dec 2003Microsoft CorporationSystem and method for embedding a sreaming media format header within a session description message
US20040057412 *25 Sep 200225 Mar 2004Nokia CorporationMethod in a communication system, a communication system and a communication device
US20040057420 *18 Feb 200325 Mar 2004Nokia CorporationBandwidth adaptation
US20040139088 *11 Mar 200215 Jul 2004Davide MandatoMethod for achieving end-to-end quality of service negotiations for distributed multi-media applications
US20040148400 *14 Nov 200329 Jul 2004Miraj MostafaData transmission
US20080263219 *21 Dec 200523 Oct 2008Alessandro BacchiMethod and System to Minimize the Switching Delay Between Two Rtp Multimedia Streaming Sessions
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7720970 *30 Sep 200518 May 2010Microsoft CorporationMethod for processing received networking traffic while playing audio/video or other media
US810743818 Jun 200831 Jan 2012Sprint Spectrum L.P.Method for initiating handoff of a wireless access terminal based on the reverse activity bit
US820400023 Jul 200919 Jun 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
US824508830 Jun 200914 Aug 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 *18 Feb 200928 Aug 2012Sprint Spectrum L.P.Method and system for changing a media session codec before handoff in a wireless network
US83109294 Jun 200913 Nov 2012Sprint Spectrum L.P.Method and system for controlling data rates based on backhaul capacity
US836356425 Mar 201029 Jan 2013Sprint Spectrum L.P.EVDO coverage modification based on backhaul capacity
US847295230 Nov 201025 Jun 2013Sprint Spectrum L.P.Discovering a frequency of a wireless access point
US85154348 Apr 201020 Aug 2013Sprint Spectrum L.P.Methods and devices for limiting access to femtocell radio access networks
US8578056 *31 Mar 20085 Nov 2013Symantec CorporationOptimized application streaming for just in time compiled components
US861967430 Nov 201031 Dec 2013Sprint Spectrum L.P.Delivery of wireless access point information
US864417611 Mar 20104 Feb 2014Sprint Spectrum L.P.Methods and systems for supporting enhanced non-real-time services for real-time applications
US86770295 Jan 201218 Mar 2014Qualcomm IncorporatedUser input back channel for wireless displays
US9356981 *21 Dec 201231 May 2016Broadcom CorporationStreaming content over a network
US93743064 Mar 200921 Jun 2016Sprint Spectrum L.P.Using packet-transport metrics for setting DRCLocks
US94138035 Jan 20129 Aug 2016Qualcomm IncorporatedUser input back channel for wireless displays
US946793829 Apr 200911 Oct 2016Sprint Spectrum L.P.Using DRCLocks for conducting call admission control
US9495312 *20 Dec 201315 Nov 2016International Business Machines CorporationDetermining command rate based on dropped commands
US9495314 *23 Jun 201415 Nov 2016International Business Machines CorporationDetermining command rate based on dropped commands
US95822395 Jan 201228 Feb 2017Qualcomm IncorporatedUser input back channel for wireless displays
US97877255 Jan 201210 Oct 2017Qualcomm IncorporatedUser input back channel for wireless displays
US20050091395 *8 Oct 200328 Apr 2005Jason HarrisMethod and system for transferring data files
US20070076704 *30 Sep 20055 Apr 2007Microsoft CorporationMethod for processing received networking traffic while playing audio/video or other media
US20070258418 *3 May 20068 Nov 2007Sprint Spectrum L.P.Method and system for controlling streaming of media to wireless communication devices
US20090059807 *29 Aug 20085 Mar 2009At&T Intellectual Property I, L.P.Systems and Methods to Monitor a Network
US20140149539 *21 Dec 201229 May 2014Broadcom CorporationStreaming content over a network
US20150178230 *20 Dec 201325 Jun 2015International Business Machines CorporationDetermining command rate based on dropped commands
US20150178231 *23 Jun 201425 Jun 2015International Business Machines CorporationDetermining command rate based on dropped commands
WO2012100218A1 *20 Jan 201226 Jul 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
14 Jun 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