Source: https://patents.google.com/patent/US8750279
Timestamp: 2018-02-22 05:25:18
Document Index: 514114912

Matched Legal Cases: ['Application No. 2004247256', 'Application No. 09709156', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 200980111437']

US8750279B2 - PCMM application manager - Google Patents
US8750279B2
US8750279B2 US12757544 US75754410A US8750279B2 US 8750279 B2 US8750279 B2 US 8750279B2 US 12757544 US12757544 US 12757544 US 75754410 A US75754410 A US 75754410A US 8750279 B2 US8750279 B2 US 8750279B2
US12757544
US20100316064A1 (en )
This application is a continuation of U.S. patent application Ser. No. 10/867,158 filed Jun. 14, 2004, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/477,970, filed Jun. 12, 2003; and U.S. Provisional Patent Application Ser. No. 60/547,208, filed Feb. 24, 2004, the entire contents of each which are incorporated herein by reference.
In one embodiment, the method combines high-level QoS information from the session initiation request, with understanding of underlying network technologies, to produce detailed QoS information for use in the PCMM message. In another embodiment, the method embeds QoS information either via SDP or via RSVP FlowSpecs (as defined in IETF documents Wroclawski, J., “The Use of RSVP with IETF Integrated Services”, RFC 2210, September 1997. Wroclawski, J., “Specification of the Controlled-Load Network Element Service”, RFC 2211, September 1997. Shenker, S., Partridge, C., Guerin, R., “Specification of Guaranteed Quality of Service”, RFC 2212, September 1997) in an eXtensible Markup Language message (XML), and uses the XML message to communicate the session initiation request to an application server, which subsequently transfers the QoS information to the application manager in an XML message. The method may alternatively use HTTP to communicate the XML message to an application server, which subsequently transfers the QoS information to the applications manager.
PollIntervalLimit, 6000 microseconds (upstream)
PollIntervalSet, empty (upstream)
Although the described embodiment performs session initiation between the endpoint and the application server is SIP, other even simpler and more flexible protocols can also be used for communication between the endpoint and the application server. For example, one embodiment uses eXtensible Markup Language (XML) instead of SIP for an endpoint to communicate session setup embedded with QoS information to the application server. Other embodiments use Real Time Streaming Protocol (RTSP) or HyperText Transfer Protocol (HTTP) for session initiation and resource requests. The QoS information can be in embedded or in the format of SDP or IETF RSVP FlowSpec
Although the described embodiment performs session initiation with SIP, and the interface between the application server and the application manager is also SIP, other even simpler protocols can also be used for communication between the application server and the application manager. For example, one embodiment uses eXtensible Markup Language (XML) for a application server to communicate resource requests to the application manager. Other embodiments use Real Time Streaming Protocol (RTSP) or HyperText Transfer Protocol (HTTP) for session initiation and resource requests. The QoS information can be in embedded or in the format of SDP or IETF RSVP FlowSpec (as defined in IETF documents Wroclawski, 3., “The Use of RSVP with IETF Integrated Services”, RFC 2210, September 1997. Wroclawski, J., “Specification of the Controlled-Load Network Element Service”, RFC 2211, September 1997. Shenker, S., Partridge, C., Guerin, R., “Specification of Guaranteed Quality of Service”, RFC 2212, September 1997)
VBR Video Traffic Characteristics—
Providing QoS for the transmission of real-time video over digital networks is particularly difficult because of the VBR nature of compressed digital video traffic. Video compression codecs (e.g., MPEG, H.263, H.261) use temporal compression techniques, in which the compression ratio changes from frame to frame and is dependent on the change or movement across subsequent frames from a periodic snapshot of the scene. This leads to high peak burst rates and generally high but variable peak-to-mean ratios. These characteristics make it more difficult to efficiently estimate resource utilization and make accurate reservations than for constant bit rate traffic such as voice.
DOCSIS Service Flow QoS Parameters—
The following few paragraphs describe DOCSIS QoS parameters and their relationship to the IETF's FlowSpec parameters for transmission of digital video. The FlowSpec to DOCSIS parameter mapping is specified in the PacketCable Multimedia Specification (PKT-SP-MM-101-030627, Jun. 27, 2003). The DOCSIS Service Flow QoS Parameters applicable for video transmission utilize the DOCSIS Real-Time Polling Service (rtPS) in the Upstream combined with Minimum Reserved Rate and Maximum Sustained Rate in both the Upstream and Downstream. The Real-Time Polling Service works well for bursty VBR traffic such as digital video because it provides a cable modem with contention-free, timely request opportunities without the need to allocate upstream bandwidth until the modem (also referred to herein as the network endpoint) has data to send.
Nominal Polling Interval—
The DOCSIS Nominal Polling Interval specifies the time interval, in microseconds, in which the cable modem will receive periodic unicast (contention free) request opportunities. For VBR video traffic, it is important that the Nominal Polling Interval be short enough that the modem receives request opportunities and subsequent grants often, enabling it to transmit at its peak rate during burst periods. The only way to ensure the modem enough request opportunities during peak bursts is to set the polling interval as if a flow were sending traffic at its peak rate continuously. If the polling interval only allows for the average rate, packets will be dropped or delayed during the burst period.
Tolerated Polling Jitter—
The DOCSIS Tolerated Polling Jitter parameter specifies the amount of time, in microseconds, a unicast request opportunity for Real-Time Polling may be delayed. For real-time video sessions, this value should be relatively small. PCMM specifies a default of 800 microseconds and is conveyed to the CMTS via the IETF RSpec Slack Term S parameter.
Maximum Sustained Traffic Rate—
The DOCSIS Maximum Sustained Traffic Rate parameter specifies the maximum sustainable rate over time (i.e., the average rate) in bits per second of DOCSIS MAC layer datagrams, and includes all MAC layer header and CRC overhead. In DOCSIS, the upstream overhead is slightly larger due to extended headers in the upstream. For VBR video traffic, this should be equal to the video's maximum sustainable rate after accounting for MAC layer overhead.
Maximum Traffic Burst—
The DOCSIS Maximum Traffic Burst parameter specifies the largest burst size in MAC layer bytes, the flow may transmit at its peak rate. For VBR video traffic, it is important that the Maximum Traffic Burst is set high enough to allow the flow to burst at its peak rate. The Maximum Traffic Burst is set equal to the IETF Token Bucket Depth b after accounting for MAC layer overhead. There is the additional requirement that the Traffic Burst must not be less than the DOCSIS specified minimum value of 1522 bytes.
Minimum Reserved Traffic Rate—
The DOCSIS Minimum Reserved Traffic Rate specifies a guaranteed minimum rate the flow will receive and closely resembles the IETF RSpec Reserved Rate R after accounting for MAC layer overhead. However, for the purposes of PCMM, the conversion from RSVP FlowSpec to DOCSIS specifies the use of the TSpec Bucket Rate r parameter. This conversion works well for VBR video traffic, because the RSpec Reserved Rate R is typically the same as (or greater than) the TSpec Bucket Rate r. That is to say, at the DOCSIS MAC layer, the reservation is made using the average rate of the video session. Test results show that setting the Minimum Reserved Traffic Rate using the bandwidth as advertised in the SDP media attributes works well in the upstream, however the downstream experiences enough packet loss to significantly affect the video quality at some bit rates. The described embodiment provides for a small, selectable percentage increase in the bandwidth to overcome this packet loss.
Assumed Minimum Reserved Rate Packet Size—
The DOCSIS Assumed Minimum Reserved Rate Packet Size, closely resembles the IETF TSpec Minimum Policed Unit m. Like the IETF parameter it is used to estimate per packet overhead. If the Service Flows sends packets smaller than this size, the packets will count as being of this size for the purposes of maintaining the reserved rate. For VBR video traffic where there is a large variance of packet size, our implementation will use a configured fixed packet size parameter. Note that although DOCSIS specifies this parameter for both upstream and downstream Service Flows, PCMM only specifies it for downstream. The DOCSIS default for this parameter is not defined, and is CMTS-implementation dependent.
Maximum Downstream Latency—
The DOCSIS Maximum Downstream Latency parameter specifies the maximum latency (in microseconds) a packet may experience between being received at the CMTS Network Interface and being transmitted downstream on the HFC. This parameter only applies to flows that have a downstream Minimum Reserved Rate configured and the flow is not exceeding this rate. For PCMM, this parameter is set from the RSpec Slack Term S.
Mapping SDP Video Bandwidth to RSVP FlowSpec—
If the SDP does not include a bandwidth media attribute parameter, all FlowSpec parameters are selected using preconfigured defaults. Otherwise, the application manager 110 uses the SDP bandwidth media attribute as input to map SDP to FlowSpec parameters. Other settings that affect the selection of RSVP FlowSpec parameters are configured and described in this section. In general, most of the following parameters the application manager uses are configured for each direction (i.e., upstream and downstream).
Delay (Milliseconds)—
This is the maximum worst-case queuing delay for video, and corresponds to the maximum burst size (the amount of time a flow may burst at its peak rate). An initial default value of 100 milliseconds is suggested.
BandwidthAdjust (Floating Point Multiplier)—
This is a “fudge factor” used to multiply original SDP requested bandwidth to reserve more bandwidth for clients that underestimate video bandwidth or to solve other interoperability issues. An initial default value of 1.0 is suggested for upstream and 1.125 for downstream. During initial testing it was observed that at all rates below 512 Kbps, additional bandwidth was required in the downstream for video quality to be acceptable, due mostly to excessive packet loss and delayed packets
RateFactor (Floating Point Multiplier)—
This is used to compute peak and reserved rate given a maximum sustained throughput (bandwidth). An initial default value for RateFactor is 4.0.
MinPacketSize (Bytes)—
This is the estimated IP packet size used for minimum policed unit and other calculations requiring packet size. An initial (conservative) default value for MinPacketSize is 640.
MaxPacketSize (Bytes)—
This is the maximum IP packet size expected to conform to the IETF TSpec. An initial default value for MaxPacketSize is 1500.
SlackTerm (Microseconds)—
This is the value used for IETF RSpec Slack Term S. For PCMM it corresponds to the DOCSIS Upstream Tolerated Polling Jitter in the upstream and the DOCSIS Downstream Latency in the downstream. An initial default value for SlackTerm is 800 microseconds, which is the default in PCMM.
RateLimit (Bytes Per Second)—
This is the upper limit on the Reserved Rate R and Peak Rate p, parameters specified in bytes per second. An initial default value for RateLimit is 96000 for the upstream, and 0 for the downstream (a value of 0 means there is no limit).
PollIntervaLimit (Microseconds)—
This is the minimum polling interval to request from the CMTS. An initial default value for PollIntervalLimit is 6000 microseconds (a value of 0 means there is no limit).
Bucket Depth (b)—
The TSpec Token Bucket Depth combined with the TSpec Token Bucket Rate bounds the maximum burst size (at the peak rate) of a flow, as well as the maximum worst case queuing delay the flow will experience. As such, both the maximum worst case queuing delay and the peak rate of the flow must be considered.
b=(100*32000)/1000=3200
Bucket Rate (r)—
The TSpec Token Bucket Rate specifies the average rate over time to which the IP flow will conform. The TSpec Bucket Rate r in bytes per second is:
r=512000*1.0/8=64000
Maximum Datagram Size (M)—
The TSpec Maximum Datagram Size M in bytes is set to the configured MaxPacketSize.
Minimum Policed Unit (m)—
The TSpec Minimum Policed Unit m in bytes is set to the configured MinPacketSize.
Peak Rate (p)—
The TSpec Peak Rate is the maximum rate the flow is expected to burst data onto the network. The TSpec Peak Rate p in bytes per second is always equal to RSpec Reserved Rate. This statement is an indirect result of using Reserved Rate R for the DOCSIS rtPS polling interval. The Polling Interval must be set using the Peak Rate, which effectively means the Peak Rate must be equal to the Reserved Rate.
Reserved Rate (R)—
The RSpec Reserved Rate is the guaranteed rate the flow is entitled to, provided that its traffic conforms to the TSpec. In PCMM, the Reserved Rate is used to determine the DOCSIS Nominal Polling Interval. In the described embodiment, the derivation of the Reserved Rate is controlled by configured limits. This is necessary to solve interoperability issues between the CMTS and the Policy Server/application manager. Specifically, hard limits on the maximum value for the Reserved Rate R parameter (RateLimit), as well a limit on the derived DOCSIS Upstream Nominal Polling Interval (PollIntervalLimit) are configured.
In the upstream there are two ways to configure the Nominal Polling Interval, which is derived from the Reserved Rate: either setting a limit on the Polling Interval using PollIntervalLimit setting, or only allowing Polling Intervals in a predetermined set of intervals by configuring PollIntervalSet. The PollIntervalSet is a list of acceptable Nominal Polling Intervals supported at the CMTS. If this list is non-empty, then the second method will be used, otherwise the first method is used.
First Method: Using PollIntervalLimit—
In the upstream, there is the additional requirement that the Minimum Policed Unit m (bytes) divided by the Reserved Rate R (bytes/second) MUST NOT be less than the configured PollIntervalLimit (microseconds). That is to say, the following inequality must always hold true when the configured PollIntervalLimit>0:
r = 64000 m = 640 RateFactor = 4.0 RateLimit = 96000 PollIntervalLimit = 10000 R = min ⁡ ( 64000 * 4.0 , 96000 ) ⁢ PollIntervalLimit = 0 = min ⁡ ( 256000 , 96000 ) R = min ⁡ ( 96000 , 640 * 10 6 / 10000 ) ⁢ PollIntervalLimit > 0 = 10000 = min ⁡ ( 96000 , 80000 ) = 80000
Second Method: Using PollIntervalSet—
When the PollIntervalSet is non-empty, the derived Nominal Polling Interval must be selected from the set of configured values in microseconds. When using this method, the setting, RateLimit and PollIntervalLimit have no meaning.
In general, R=(m*106)/NominalPollingInterval
Ri=(m*106)/Ii for all i [1 . . . n]
PollIntervalSet={10000, 20000, 30000}
R=32000
Slack Term (S)—
The Slack Term S in microseconds is set from the configured SlackTerm parameter.
G.711 (PCM encoding) μ-Law
First Technique—
When the SDP field specifies multiple codecs for the same media type, the application manager initially bases resource reservation decisions on the codec utilizing the greatest amount of network resources. This ensures that enough resources have been reserved so that any of the negotiated codecs will work properly.
Second Technique—
This technique uses the codec ordering in the SDP for each media type to select a particular codec. The SDP specification states that the order of the codecs in the SDP should determine the codec preference of the network endpoint. In most cases the first codec in the list will be the one used by the network endpoint. When network endpoints are known to adhere to this standard, this configuration will result in a more stringent QoS reservation, resulting in a lower cost of service.
Third Technique—
This technique uses the DOCSIS QoS MIB (Patrick, M., Murwin, W., “Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB)”, Internet-Draft (expires April 2004), http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt, Oct. 27, 2003) at the CMTS to determine the audio packet size that the network endpoints are sending. Since audio traffic is CBR (Constant Bit Rate), the same packet size will be used for all packets. Examining the DOCS-QOS MIB will reveal the number of packets and bytes forwarded by the DOCSIS Service Flows used to carry the audio data, as well as the amount of time the flow is active. Dividing the total number of bytes by number of packets used to send those bytes yields the packet size. The rate is determined by dividing the total number of bytes forwarded by the amount of time that the flow is active.
1. A method of allocating network assets for communication between first network endpoint and a second network endpoint, said method comprising:
sending a session initiation invite to an application server for initiating a call flow between the network endpoints through the set of network assets, wherein the call flow is implemented by an application residing on an application server;
in response to receiving the session initiation invite, sending a resource reservation message from the application server to an application manager, wherein the resource reservation message is provided to the application manager via a first interface of the application manager that employs a web services interface protocol, wherein the web services interface protocol is not a PacketCable multimedia (PCMM) protocol;
from the application manager sending, via a second interface of the application manager, a request to a policy server to allocate network assets for creating a call flow path connecting the network endpoints to establish a session, said second interface using a protocol that is different from the web services interface protocol.
2. The method of claim 1, wherein the web services interface protocol employs an eXtensible Markup Language (XML) protocol.
3. The method of claim 1, wherein the web services interface protocol employs a HyperText Transfer Protocol (HTTP).
4. The method of claim 1, wherein sending a session initiation invite involves using a Session Initiation Protocol (SIP).
5. The method of claim 1, further comprising using session description protocol (SDP) fields in a Session Initiation Protocol (SIP) message to perform QoS reservation of resources in the network.
6. The method of claim 1, wherein the application server is a SIP proxy server.
7. The method of claim 1, wherein the second interface is a PCMM interface and sending the request to the policy server comprises sending a PCMM message.
8. A system for allocating network assets for communication between first network endpoint and a second network endpoint, said system comprising:
an application server for initiating communication between the network endpoints through the set of network assets by sending a resource reservation message in response to receiving a session initiation invite, wherein the communication is implemented by an application residing on an application server; and
an application manager for receiving via a first interface of the application manager the resource reservation message from the application server, and sending via a second interface of the application manager a request to a policy server to allocate network assets for creating a call flow path connecting the network endpoints to establish a session, wherein said first interface employs a web service interface protocol, wherein the web services interface protocol is not a PacketCable multimedia (PCMM) protocol, and said second interface employs a protocol that is different from the web services interface protocol.
9. The system of claim 8, wherein the web services interface protocol employs an eXtensible Markup Language (XML) protocol.
10. The system of claim 8, wherein the web services interface protocol employs a HyperText Transfer Protocol (HTTP).
11. The system of claim 8, wherein the session initiation invite is a Session Initiation Protocol (SIP) session initiation invite.
12. The system of claim 8, wherein the application server is a SIP proxy server.
13. The system of claim 8, wherein the second interface is a PCMM interface and the application manager sends the request to the policy server via a PCMM message.
US12757544 2003-06-12 2010-04-09 PCMM application manager Active 2024-08-02 US8750279B2 (en)
US10867158 Continuation US7738440B2 (en) 2003-06-12 2004-06-14 PCMM application manager
US20100316064A1 true US20100316064A1 (en) 2010-12-16
US8750279B2 true US8750279B2 (en) 2014-06-10
WO2000079794A2 (en) 1999-06-17 2000-12-28 Bigband Networks, Inc. Method for delivery of narrow-cast data over digital broadcast channels
US6201790B1 (en) 1996-06-26 2001-03-13 U.S. Philips Corporation Network access control method, and device and system for implementing this method
US20070149203A1 (en) 2005-12-23 2007-06-28 Sliva Vladimir P Method and system for wireless priority call processing
EP1631917B1 (en) 2003-06-12 2010-12-08 Camiant, Inc. Dynamic service delivery with topology discovery for communication networks
"Cable Modem Termination System- Network Side Interface Specification," SP-CMTS-NSII01-960702, I01 (Jul. 2, 1996).
"Cable Modem Termination System— Network Side Interface Specification," SP-CMTS-NSII01-960702, I01 (Jul. 2, 1996).
"Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB)," (Feb. 2005).
"PacketCable 1.2 Architecture Framework Technical Report," PKT-TR-ARCH1.2-V01-001229, V01 (Dec. 29, 2000).
"PacketCable Dynamic Quality-of-Service-Specification," PKKT-SP-DQOS-I09-040402, I09 (Apr. 2, 2004).
"PacketCable Multimedia Architecture Framework Technical Report," PKT-TR-MM-ARCH-V01-030627, V01 (Jun. 27, 2003).
"PacketCable Multimedia Specification," PKT-SP-MM-I01 (Jun. 27, 2003).
"SDP: Session Description Protocol," RFC 2327 (Apr. 1998).
"SIP: Session Initiation Protocol," RFC 3261 (Jun. 2002).
"Specification of Guaranteed Quality of Service," RFC 2212 (Sep. 1997).
"Specification of the Controlled-Load Network Element Service," RFC 2211 (Sep. 1997).
"The Use of RSVP with IETF Integrated Services," RFC 2210 (Sep. 1991).
Advisory Action Before the Filing of an Appeal Brief for U.S. Appl. No. 12/051,374 (Oct. 31, 2013).
Advisory Action for U.S. Appl. No. 10/867,157 (Sep. 23, 2009).
Applicant-Initiated Interview Summary for U.S. Appl. No. 12/051,374 (Nov. 20, 2013).
Australian Examiner's Report issued for Application No. 2004247256 (Nov. 18, 2008).
Braden et al., "Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification," RFC 2205, pp. 1-112 (Sep. 1997).
Braden et al., "Resource ReSerVation Protocol (RSVP)— Version 1 Functional Specification," RFC 2205, pp. 1-112 (Sep. 1997).
Commonly-assigned, co-pending U.S. Appl. No. 11/041,779 (Filed Jan. 24, 2005).
Commonly-assigned, co-pending U.S. Appl. No. 11/041,918 (Filed Jan. 24, 2005).
Decision on Appeal for U.S. Appl. No. 10/867,157 (Apr. 11, 2013).
Ed Miller ,et al ,"the packetCable Architecture" IEEE Communications Magazine ,IEEE Service Center,Piscataway, US,vol. 39,No. 6,Jun. 2001 pp. 90-96. *
Ed Miller ,et al ,"the packetCable Architecture" IEEE Communications Magazine ,IEEE Service Center,Piscataway,US,vol. 39,No. 6,Jun. 2001 pp. 90-96. *
European Patent Office, European Search Report for PCT/US2004/019024, 4 pages (Mar. 15, 2007).
Examiner's Answer for U.S. Appl. No. 10/867,157 (Jul. 8, 2010).
Extended European Search Report for European Application No. 09709156.5 (Dec. 5, 2013).
Final Office Action for U.S. Appl. No. 12/051,374 (Aug. 8, 2013).
Final Official Action for U.S. Appl. No. 10/867,157 (Apr. 17, 2009).
Final Official Action for U.S. Appl. No. 10/867,157 (Mar. 24, 2008).
First Office Action for Canadian Applicaton No. 2,554,176 (Aug. 27, 2012).
Japanese Official Action issued for 2006-533793, 1 page (Sep. 15, 2009).
Kutscher et al., "Session Description and Capability Negotiation Draft-IEFT-Music-SDPNG-03. TXT" IETF Request for Comments, pp. 1-61, XP002205059 (Nov. 21, 2001).
Non-Final Office Action for U.S. Appl. No. 12/646,542 (Oct. 25, 2013).
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 10/867,157 (Jul. 22, 2013).
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 10/867,159 (Aug. 20, 2013).
Notice of Allowance for Canadian Application No. 2,528,648 (Nov. 25, 2013).
Notice of Panel Decision from Pre-Appeal Brief Review for U.S. Appl. No. 10/867,157 (Dec. 18, 2009).
Official Action for U.S. Appl. No. 10/867,157 (Sep. 20, 2007).
Official Action for U.S. Appl. No. 10/867,157 (Sep. 26, 2008).
Second Office Action for Canadian Application No. 2,554,176 (Nov. 12, 2013).
Second Office Action for Canadian Application No. 2,554,177 (Jan. 10, 2014).
Second Office Action for Chinese Application No. 200980111437.X (Oct. 22, 2013).