US7948878B2 - Policing networks - Google Patents

Policing networks Download PDF

Info

Publication number
US7948878B2
US7948878B2 US11/795,949 US79594906A US7948878B2 US 7948878 B2 US7948878 B2 US 7948878B2 US 79594906 A US79594906 A US 79594906A US 7948878 B2 US7948878 B2 US 7948878B2
Authority
US
United States
Prior art keywords
greediness
data flow
measure
flow
tcp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US11/795,949
Other languages
English (en)
Other versions
US20080192636A1 (en
Inventor
Robert J Briscoe
Arnaud Jacquet
C Di Cairano-Gilfedder
Alessandro Salvatori
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0502483A external-priority patent/GB0502483D0/en
Priority claimed from EP05255164A external-priority patent/EP1758313A1/en
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Assigned to BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY reassignment BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SALVATORI, ALESSANDRO, CAIRANO-GILFEDDER, CARLA DI, BRISCOE, ROBERT JOHN, JACQUET, ARNAUD
Publication of US20080192636A1 publication Critical patent/US20080192636A1/en
Application granted granted Critical
Publication of US7948878B2 publication Critical patent/US7948878B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/18—End to end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/31—Flow control; Congestion control by tagging of packets, e.g. using discard eligibility [DE] bits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Definitions

  • the present invention relates primarily to the control of data in a network, and to methods and systems for enabling the policing of use of networks such as the Internet for communicating data.
  • Some applications need to be unresponsive (e.g. interactive voice, video and games). Others simply choose to be aggressive to give themselves premium service. Also, some users continuously fill their access link with more flows than others, whether deliberately (peer-to-peer file sharing) or unwittingly (worm infected zombie hosts). Even if each flow is responsive, in total more congestion results.
  • the TCP rate control algorithm [7] was developed in the late 1980s in response to a major congestion collapse on the Internet. It was designed to ensure that the rate of every flow traversing the Internet rapidly adapted to the level of congestion it experienced in such a way that each flow would tend towards a rate that shared capacity of any congested router or link fairly.
  • the TCP rate control algorithm runs within the operating system of the sending host.
  • the programmer of an application can choose to use it or not.
  • the TCP algorithm characterised the path being used across the Internet by detecting losses through missing acknowledgements and by measuring the round trip delay before those acknowledgements arrived.
  • the TCP/IP standard was improved by the optional addition of Explicit Congestion Notification (ECN), so that a router experiencing early signs of congestion could mark packets before forwarding.
  • ECN Explicit Congestion Notification
  • the acknowledgement protocol was also changed to allow these marks to be conveyed back to the source.
  • the standard for the TCP algorithm was altered to require the sending host to respond to these returned marks as if there had been a loss.
  • x k ⁇ s T ⁇ m ( 1 )
  • x is the expectation of the throughput
  • k is a constant of the order of ⁇ ( 3/2)
  • s is the packet size for the flow
  • T is its round-trip-time
  • m is the end-to-end congestion metric (as represented by the proportion of marked and dropped packets within the flow).
  • x w ⁇ s m ( 2 ) where x, m, and s have the same meaning as above while w is the willingness-to-pay parameter of the user.
  • an Internet network element cannot currently know the relevant metrics about the path to verify that a sender is complying with the TCP protocol.
  • Commercially available policers e.g. from Sandvine (www.sandvine.com), or Riverhead Networks (www.riverhead.com) ensure that no flow exceeds a maximum rate, irrespective of the condition of each path being used through the rest of the network. Some such policers can use their knowledge of any local congestion on the equipment itself, but not elsewhere.
  • policers that reduce the amount of state required by these commercial policers [4, 5, 12, 13, 14, 15, 16] must be sited on relays that are congested themselves in order to work. All these policers, which we will refer to as “bottleneck policers”, detect unusually high bit rates, but a high sending rate might be perfectly legitimate if the path is uncongested or the round-trip time is short. Similarly, other policers on the latest broadband remote access servers enforce monthly volume caps in an attempt to control high volume file-sharing. But they punish traffic that fills troughs as much as traffic that causes peaks in utilization.
  • RED random early detection
  • CHOKe also exploits the idea that a grossly misbehaving flow will appear far more in the data stream than a compliant TCP flow. Whenever a packet arrives, it is compared with another randomly picked from the queue. If the two are from the same flow, that flow is suspected of misbehaving. CHOKe shows very good results in forcing down unusually high rate traffic.
  • Stabilized RED SRED [12] was published in parallel, while later improvements include CHOKe [5], RED with Preference Dropping (RED-PD [13]), Least Recently Used RED (LRU-RED [14]), XCHOKe [16], and Approx. Fair Dropping (AFD [15]).
  • rate is policed with no respect to the specific characteristics of the path. For instance, let us consider two flows crossing a common bottleneck: flow A with a short round-trip time passes over an otherwise barely congested path while flow B has a round trip-time four times as long and experiences four times as much congestion on its path. In the long-term, flow B should get only 1 ⁇ 8 of the bandwidth flow A gets. Nevertheless, with all existing policers, if congestion is elsewhere than on the network element housing the policer itself, both packets will be considered equally responsible, and flow A will therefore be much more likely to be constrained than flow B.
  • Nikolouzou et al [19] describes a generic Differentiated Services (DiffServ) arrangement, and addresses the definition and deployment of specific network services in a DiffServ environment.
  • DiffServ Differentiated Services
  • the source places a request in a protocol field.
  • the request is in terms of how much data can be sent before any acknowledgement has been received (termed the amount of data in flight, or the congestion window).
  • Quick-Start the field is in terms of sending rate. As a packet traverses the network, if the value of the metric that a router can tolerate is less than the request, it re-writes the field. However, the resulting field must still be returned to the sender, and the sender must ensure its future rate complies with the network's response to its request.
  • connection-oriented networks such as ATM
  • network elements send congestion back-pressure messages [9] along each connection, duplicating any end-to-end feedback because they don't trust it.
  • congestion back-pressure messages [9] along each connection, duplicating any end-to-end feedback because they don't trust it.
  • it is inherently hard to use similar techniques in a connectionless datagram network without losing the benefits of low connection set-up latency and robustness of a packet network.
  • re-feedback a novel feedback mechanism was proposed termed “re-feedback”, this term being indicative of the idea of “Receiver-Normalised” feedback.
  • the sender sets the initial value of any path characterization field so that, by the time it has accumulated path information, it tends to arrive at the destination set to a commonly standardised value. Feedback from the destination to the source is then used to continuously correct any error in the destination value when future data is sent.
  • a principal advantage is that data effectively carries with it a “prediction” of its own downstream path for use by in-line equipment along the transmission path.
  • rate is policed with no respect to the specific characteristics of the path.
  • existing policers deny themselves opportunities for optimising certain policing characteristics, including their responsiveness (i.e. ability to detect misbehaving flows quickly), their robustness (i.e. ability to identify as misbehaving as few compliant flows as possible, thus avoiding “false positives”), and in particular the trade-off between characteristics such as these.
  • Flow in a data network can in general be regarded as comprising a plurality of messages, these being the individual data-carrying items applicable to the network and/or protocol in question.
  • a policing method is used in relation to current Internet Protocol (IP)
  • IP Internet Protocol
  • Host-based rate control algorithms maintain state about the recent condition of each flow's path, which determines the sending rate. For instance, TCP maintains a congestion window variable while TCP-friendly rate control and Kelly's algorithm maintain a variable holding the current sending rate.
  • FIGS. 1( a ) and 1 ( b ) outline the difference between bottleneck policers ( FIG. 1( a )) and a path-specific policer of the type we propose in an exemplary embodiment ( FIG. 1( b )).
  • a congestion metric We illustrate the difference specifically for a congestion metric, although the same concept can be used for other metrics too.
  • Policing nodes are represented with the local level of congestion “m i ” and the information “y” upon which they will perform the policing.
  • x(y) the throughput they are designed to let through.
  • y m i , which means a policer is required on every potential bottleneck, that is every router on the path.
  • misbehaving flow may be defined as a flow that uses significantly more bandwidth than would a compliant flow given the same path conditions.
  • it is proposed to detect misbehaving flows by recording the flow description of packets in the stream, with a probability in inverse proportion to their expected throughput. Equation (1) (see above) is used as an example of how expected throughput may be determined, noting that is based on the specific path characterization values obtained from the packet.
  • misbehaving flows are not characterised only because of their absolute throughput, but rather on their throughput relative to that a compliant flow would get with the same network conditions on the data path. This is much more accurate in selecting which flows to sanction.
  • a further mechanism should preferably operate at the granularity of each sending user, rather than each flow.
  • a “per user” counter should be maintained of the accumulated total of all the congestion values from packets probabilistically selected for the polling record. Then this counter can be used to weight the “per flow” algorithms more harshly against users who cause more congestion.
  • rate policers such as those available from vendors such as Sandvine or Riverhead Networks (see above). It is certainly desirable to be able to limit the rate, and hence the value that lower-tier customers can derive from a network. But such limits represent the maximum under the best conditions. To maximize the value all customers derive from a network and to balance revenues and the costs of interconnect with other networks, the allowed rate should further depend on path conditions across the whole or any relevant part of the inter-network.
  • DPI deep packet inspection
  • a policer according to a preferred embodiment of the present invention, it is made possible to push back harder the more congestion people cause cumulatively over periods, measured in days for example. So use of the network for high-bandwidth activities such as p2p file-sharing can be pushed into the troughs and off the peaks at the network edge.
  • edge network devices can police any desired congestion response, not just TCP, thereby enabling inter-provider QoS to be carried out by carrying out policing solely at the very edges of the Internet.
  • FIGS. 1( a ) and 1 ( b ) outline a fundamental difference between bottleneck policers ( FIG. 1( a )) and a path-specific policer ( FIG. 1( b )) operating according to an exemplary embodiment of the present invention
  • FIGS. 2( a ) and 2 ( b ) show graphs indicating potential differences in policing behaviour between a classic policer ( FIG. 2( a )) and a path-specific policer operating according to a preferred embodiment of the present invention ( FIG. 2( b ));
  • FIG. 3 is a diagram showing a policer according to a comparatively generic embodiment of the present invention.
  • FIG. 4 is a diagram showing a policer operating according to an embodiment of the present invention, using the model of a token bucket of fixed depth;
  • FIG. 5 is a diagram showing a policer operating according to a preferred embodiment of the present invention, wherein greediness is monitored by sampling traffic in inverse proportion to its expected throughput;
  • FIG. 6 is a flow-chart showing steps taken by a policer operating according to an embodiment of the present invention wherein greediness is monitored without sampling traffic;
  • FIG. 7 is a flow-chart showing steps taken by a policer operating according to an embodiment of the present invention wherein greediness is monitored by sampling traffic;
  • FIG. 8 is a graph showing the expected throughput of a TCP flow through a policer operating in accordance with a preferred embodiment of the invention.
  • x app ⁇ s j , i t j , N j - t j , 1 ( 3 )
  • s j,i and t j,i are the size and arrival time of packet i of flow j.
  • Equation (1) which we repeat here as Equation (4).
  • x TCP s k TCP ⁇ T ⁇ m ( 4 )
  • x # as a reference compliant rate for policing the traffic with respect to the conditions of the path they follow, where # denotes the rate adaptation policy used for that class of traffic.
  • x TCP becomes a special case of x # .
  • FIG. 3 outlines the objective of the policer: it has to flag any flow whose apparent greediness ⁇ j is higher than the ceiling ⁇ * for a period of time T *.
  • Flow j arrives at the policer at a rate x app .
  • the effect of the policer is to identify whether the flow is behaving ( ⁇ j ⁇ *) or misbehaving ( ⁇ j > ⁇ *) and to segregate their subsequent treatment based on that information.
  • x TCP has to be maintained per flow and can be updated whenever a packet is received. For instance, x TCP may be obtained for each packet from the re-feedback fields thanks to Equation (4).
  • Equation (4) We describe below several mechanisms to monitor ⁇ j per flow, and segregate for sanction those flows with a greediness higher than the ceiling ⁇ * for a period of time T*.
  • the exact definition of the flow is left open. Preferably, it would be the packets of an end-to-end connection, as identified by the source and destination addresses and ports. It may also be an aggregate of such connections: for instance, all connections incoming on a given interface of the policer and destined to an IP prefix.
  • FIG. 2 shows this distinction. While high-rate flows experiencing bad path conditions (characterised by long round-trip times and/or high congestion for instance) are caught with both a classic policer ( FIG. 2( a )) and a path-specific policer ( FIG. 2( b )) (see zone 1 in each figure), and while low-rate flows experiencing good path conditions are let through in both cases again (zone 2), classic policers would wrongly characterise two categories of flows:
  • Embodiments of the invention allow instead for the policing to be performed at the upstream edge of the network, therefore enabling a more efficient protection of the network.
  • FIG. 4 shows how this can be done by means of a token bucket. Whenever a packet arrives, ⁇ TCP .dt j,i is added to the token bucket (where dt j,i is the inter-arrival time since the last packet), while k TCP .T j,i . ⁇ m j,i is taken out of it (where T j,i and m j,i are obtained from the fields in the packet). If the bucket is not empty after the adjustment, the packet is served as requested. If on the other hand the bucket is empty, the flow is flagged for sanction and the packet is dealt with appropriately.
  • FIG. 6 describes the flow chart related to FIG. 4 .
  • a packet arrives, it is associated with its flow id j, the downstream congestion metric m j,i , the round-trip time T j,i and the time t new when it is received.
  • n TCP is not a very simple computational operation as it may require extracting a square root (or a cubic root, as explained in the section dealing with “Obtaining the path metrics”). Therefore, if the implementation of the policer is required to minimise delay in forwarding packets, the order of operation may be different. First the number of tokens in the bucket would be checked. If B j >0, the packet would be forwarded immediately. Updating the state of the token bucket would be done offline, but quickly enough so that the update occurs within a round-trip time. The delay minimization in the packet processing may come at the expense of responsiveness, as it may take longer to detect misbehaving flows.
  • the depth of the bucket follows from the objective of the policer.
  • the policer should flag any flow whose apparent greediness ⁇ j is higher than the ceiling ⁇ * for a period of time T *.
  • T * 0
  • FIG. 5 Another variant on the design, illustrated in FIG. 5 , limits the requirements on per-flow state for small flows. It monitors the greediness by sampling traffic in each flow in inverse proportion to its expected throughput, given by x TCP as previously.
  • the advantage of the sampling version for the policer is that small compliant flows will not require the creation of a token bucket, which will reduce the state requirement (number of active token buckets) of the policer when compared to a non-sampling embodiment. This feature is important in protecting the policer against denial-of-service attacks.
  • FIG. 7 describes the flow chart related to FIG. 5 .
  • a packet arrives, it is associated with its flow id j, the downstream congestion metric m j,i , the round-trip time T j,i and the time t new when it is received.
  • a sampling policer selects a random variable u i picked in the range [0 . . . 1] and compares it to ⁇ .n TCP .
  • the state of the token bucket B j may still be updated at that point.
  • One treatment may be applied when the flow has just been blacklisted, a harsher treatment may be applied if the number of tokens in the bucket remains negative, and the flow may be removed from the blacklist when the number of tokens in the bucket becomes positive again (as would happen if the flow drastically reduces its sending rate).
  • three values may be extracted from the packet header: the flow id j, the re-feedback congestion field h j , and the re-feedback downstream delay D j .
  • the policer should be located close to the ingress of the network. Indeed the re-feedback fields may only characterise the downstream path while end-to-end metrics are required for the compliance test. If the policer is located close to the network ingress, there are two options: either the discrepancy might be ignored because the upstream contribution to the end-to-end metrics can be shown to be negligible, or the upstream contribution could be monitored by the policing node and used together with the downstream metrics in order to obtain the end-to-end metrics. This may require the policing node to keep permanent state of its upstream paths, which may only be manageable at a network ingress where the number of upstream nodes is limited.
  • m j is a standard re-feedback operation. This assumes that the upstream network between the ingress access element and the sending host doesn't experience significant congestion.
  • Equation (1) requires for m the probability m rtt that one such mark occurs for one or more packets in a round-trip time. It may happen in the future that m pkt is more appropriate, but at the moment m rtt is more appropriate.
  • the policing node a record of the upstream round-trip delay T 0 between each upstream source and itself using the minimum of a number of tests at uncongested periods.
  • Other techniques might be used to retrieve the roundtrip: see for instance Jiang & Dovrolis [20].
  • ⁇ * is the main control parameter of the policer. Its choice is key in setting the trade-off between responsiveness (detecting misbehaving flows quickly) and robustness (identifying as misbehaving as few compliant flows as possible) of the policer. We explain here how to set ⁇ * so that the proportion of compliant flows identified as misbehaving (that is, the proportion of false positives) remains smaller than ⁇ (we would expect ⁇ to take very small values, say 10 ⁇ 3 at most).
  • ⁇ * should therefore be set so that the probability for the congestion window to exceed ⁇ * times the expected average cwnd avg is smaller than ⁇ , which is given by P(cwnd> ⁇ *.cwnd avg ) ⁇ .
  • ⁇ *.cwnd avg ⁇ 35 we get ⁇ *.cwnd avg ⁇ 35 while cwnd avg ⁇ 12.7 (the value of the average comes from analysis of the TCP congestion window as a Markov chain).
  • T * Let the observation period grow and the robustness of the policer will get better (although it will get less responsive).
  • the depth of the bucket should be set to a lower value.
  • sampling version of the policer is to be dimensioned to minimise its state requirement (as defined by the number of buckets necessary to monitor the traffic flowing through), a shorter bucket will reduce the state requirement, as well as a smaller value for the sampling parameter ⁇ .
  • sampling coefficient for user k ⁇ . max ⁇ 1, (m k /U k )/(M/U) ⁇ so that data for user k is policed much more strictly when user k has used up the congestion “budget” (M/U)*U k .
  • Different classes of traffic may also be tested against different compliance formulas by using different classes.
  • the amount of token in the bucket is equivalent to ( ⁇ TCP ⁇ j ).
  • EWMA exponentially-weighted moving average
  • the amount of tokens in the bucket is equivalent to ( ⁇ TCP ⁇ j ). ⁇ .
US11/795,949 2005-02-07 2006-02-07 Policing networks Active 2027-07-13 US7948878B2 (en)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
GB0502483A GB0502483D0 (en) 2005-02-07 2005-02-07 Policing networks
GB0502483.1 2005-02-07
EP05255164 2005-08-22
EP05255164.5 2005-08-22
EP05255164A EP1758313A1 (en) 2005-08-22 2005-08-22 Policing networks
PCT/GB2006/000417 WO2006082443A1 (en) 2005-02-07 2006-02-07 Policing networks

Publications (2)

Publication Number Publication Date
US20080192636A1 US20080192636A1 (en) 2008-08-14
US7948878B2 true US7948878B2 (en) 2011-05-24

Family

ID=36103258

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/795,949 Active 2027-07-13 US7948878B2 (en) 2005-02-07 2006-02-07 Policing networks

Country Status (6)

Country Link
US (1) US7948878B2 (zh)
EP (1) EP1847081B1 (zh)
JP (1) JP4705115B2 (zh)
KR (1) KR101228288B1 (zh)
CN (1) CN101116292B (zh)
WO (1) WO2006082443A1 (zh)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9794210B1 (en) 2013-11-14 2017-10-17 The United States Of America, As Represented By The Secretary Of The Army Priority assignment based on similarity
US9800275B2 (en) 2015-12-16 2017-10-24 Kumu Networks, Inc. Systems and methods for out-of band-interference mitigation
US9819325B2 (en) 2015-12-16 2017-11-14 Kumu Networks, Inc. Time delay filters
US9832003B2 (en) 2013-08-09 2017-11-28 Kumu Networks, Inc. Systems and methods for self-interference canceller tuning
US9979374B2 (en) 2016-04-25 2018-05-22 Kumu Networks, Inc. Integrated delay modules
US10050659B2 (en) 2013-08-09 2018-08-14 Kumu Networks, Inc. Systems and methods for non-linear digital self-interference cancellation
US10103774B1 (en) 2017-03-27 2018-10-16 Kumu Networks, Inc. Systems and methods for intelligently-tuned digital self-interference cancellation
US10200217B2 (en) 2015-12-16 2019-02-05 Kumu Networks, Inc. Systems and methods for adaptively-tuned digital self-interference cancellation
US10230422B2 (en) 2013-12-12 2019-03-12 Kumu Networks, Inc. Systems and methods for modified frequency-isolation self-interference cancellation
US10236922B2 (en) 2017-03-27 2019-03-19 Kumu Networks, Inc. Systems and methods for tunable out-of-band interference mitigation
US10243598B2 (en) 2015-10-13 2019-03-26 Kumu Networks, Inc. Systems for integrated self-interference cancellation
US10382085B2 (en) 2017-08-01 2019-08-13 Kumu Networks, Inc. Analog self-interference cancellation systems for CMTS
US10425115B2 (en) 2018-02-27 2019-09-24 Kumu Networks, Inc. Systems and methods for configurable hybrid self-interference cancellation
US10454444B2 (en) 2016-04-25 2019-10-22 Kumu Networks, Inc. Integrated delay modules
US10666305B2 (en) 2015-12-16 2020-05-26 Kumu Networks, Inc. Systems and methods for linearized-mixer out-of-band interference mitigation
US10868661B2 (en) 2019-03-14 2020-12-15 Kumu Networks, Inc. Systems and methods for efficiently-transformed digital self-interference cancellation
US11211969B2 (en) 2017-03-27 2021-12-28 Kumu Networks, Inc. Enhanced linearity mixer
US11888749B2 (en) 2021-10-25 2024-01-30 Hewlett Packard Enterprise Development Lp Reverse loss detection for communication network bandwidth estimation with token buckets

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7965717B2 (en) * 2003-01-17 2011-06-21 Nortel Networks Limited Multi-staged services policing
EP2106068A1 (en) * 2008-03-28 2009-09-30 British Telecommunications Public Limited Company Measuring data source-specific network metrics
CN101557335B (zh) * 2008-04-11 2012-11-21 华为技术有限公司 控制节点加入对等网络的方法和装置
US8000235B2 (en) * 2008-10-05 2011-08-16 Contextream Ltd. Bandwidth allocation method and apparatus
EP2234346A1 (en) 2009-03-26 2010-09-29 BRITISH TELECOMMUNICATIONS public limited company Policing in data networks
US20110083175A1 (en) * 2009-10-06 2011-04-07 Sonus Networks, Inc. Methods and Apparatuses for Policing and Prioritizing of Data Services
US8340126B2 (en) 2010-06-07 2012-12-25 Lockheed Martin Corporation Method and apparatus for congestion control
EP2398194A1 (en) 2010-06-17 2011-12-21 British Telecommunications Public Limited Company Monitoring path characterisation information
US10284356B2 (en) 2011-02-03 2019-05-07 The Board Of Trustees Of The Leland Stanford Junior University Self-interference cancellation
US9887728B2 (en) 2011-02-03 2018-02-06 The Board Of Trustees Of The Leland Stanford Junior University Single channel full duplex wireless communications
EP2541850A1 (en) 2011-06-30 2013-01-02 British Telecommunications Public Limited Company Determining path congestion measures
CN103814555B (zh) 2011-06-30 2017-02-22 英国电讯有限公司 确定路径拥塞测量
US9998400B2 (en) 2011-09-30 2018-06-12 British Telecommunications Public Limited Company Attribution of congestion contributions
EP2575303A1 (en) 2011-09-30 2013-04-03 British Telecommunications Public Limited Company Determining congestion measures
US10243719B2 (en) 2011-11-09 2019-03-26 The Board Of Trustees Of The Leland Stanford Junior University Self-interference cancellation for MIMO radios
CN102571570A (zh) * 2011-12-27 2012-07-11 广东电网公司电力科学研究院 一种基于强化学习的网络流量负载均衡控制方法
TWI459768B (zh) 2011-12-30 2014-11-01 Ind Tech Res Inst 協助ｔｃｐ封包傳送的通訊系統與方法
US9325432B2 (en) 2012-02-08 2016-04-26 The Board Of Trustees Of The Leland Stanford Junior University Systems and methods for full-duplex signal shaping
KR101475935B1 (ko) 2013-06-20 2014-12-23 고려대학교 산학협력단 적응적 확률 기반 패킷 필터링 라우터 및 그 방법
US11163050B2 (en) 2013-08-09 2021-11-02 The Board Of Trustees Of The Leland Stanford Junior University Backscatter estimation using progressive self interference cancellation
WO2015021463A2 (en) 2013-08-09 2015-02-12 Kumu Networks, Inc. Systems and methods for frequency independent analog selfinterference cancellation
US9054795B2 (en) 2013-08-14 2015-06-09 Kumu Networks, Inc. Systems and methods for phase noise mitigation
US10673519B2 (en) 2013-08-29 2020-06-02 Kuma Networks, Inc. Optically enhanced self-interference cancellation
JP6183939B2 (ja) 2013-08-29 2017-08-23 クム ネットワークス インコーポレイテッドＫｕｍｕ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ． 全二重中継装置
US9520983B2 (en) 2013-09-11 2016-12-13 Kumu Networks, Inc. Systems for delay-matched analog self-interference cancellation
US9774405B2 (en) 2013-12-12 2017-09-26 Kumu Networks, Inc. Systems and methods for frequency-isolated self-interference cancellation
US9712312B2 (en) 2014-03-26 2017-07-18 Kumu Networks, Inc. Systems and methods for near band interference cancellation
WO2015168700A1 (en) 2014-05-02 2015-11-05 The Board Of Trustees Of The Leland Stanford Junior University Method and apparatus for tracing motion using radio frequency signals
US10225195B2 (en) * 2014-05-07 2019-03-05 Adtran, Inc. Telecommunication systems and methods using dynamic shaping for allocating network bandwidth
US9276682B2 (en) 2014-05-23 2016-03-01 Kumu Networks, Inc. Systems and methods for multi-rate digital self-interference cancellation
US9521023B2 (en) 2014-10-17 2016-12-13 Kumu Networks, Inc. Systems for analog phase shifting
US9712313B2 (en) 2014-11-03 2017-07-18 Kumu Networks, Inc. Systems for multi-peak-filter-based analog self-interference cancellation
US9673854B2 (en) 2015-01-29 2017-06-06 Kumu Networks, Inc. Method for pilot signal based self-inteference cancellation tuning
US9537777B1 (en) * 2015-03-30 2017-01-03 EMC IP Holding Company LLC Adjusting input/output operation arrival times to represent a token bucket that enforces maximum rate and burst size limits
US9948561B2 (en) * 2015-04-14 2018-04-17 Cisco Technology, Inc. Setting delay precedence on queues before a bottleneck link based on flow characteristics
CN105119778B (zh) * 2015-09-09 2018-09-07 华为技术有限公司 测量时延的方法和设备
US10153974B2 (en) * 2016-04-13 2018-12-11 Futurewei Technologies, Inc. Software defined network traffic congestion control
US10338205B2 (en) 2016-08-12 2019-07-02 The Board Of Trustees Of The Leland Stanford Junior University Backscatter communication among commodity WiFi radios
EP3300411B1 (en) 2016-09-21 2018-12-12 Swisscom AG Data-driven roll-out planning optimization method
CN110100464A (zh) 2016-10-25 2019-08-06 小利兰·斯坦福大学托管委员会 反向散射环境ism频带信号

Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6266327B1 (en) * 1998-03-20 2001-07-24 Lucent Technologies Inc. Non-conformance indicator for the guaranteed frame rate service
US20030007454A1 (en) * 2001-07-09 2003-01-09 International Business Machines Corporation Traffic management in packet-based networks
US20030081546A1 (en) * 2001-10-26 2003-05-01 Luminous Networks Inc. Aggregate fair queuing technique in a communications system using a class based queuing architecture
WO2003049319A1 (en) 2001-11-30 2003-06-12 British Telecommunications Public Limited Company Method of resource control in a wireless network
US6724721B1 (en) * 1999-05-07 2004-04-20 Cisco Technology, Inc. Approximated per-flow rate limiting
US6839321B1 (en) * 2000-07-18 2005-01-04 Alcatel Domain based congestion management
US6865185B1 (en) * 2000-02-25 2005-03-08 Cisco Technology, Inc. Method and system for queuing traffic in a wireless communications network
WO2005032068A1 (en) 2003-09-29 2005-04-07 British Telecommunications Public Limited Company Bandwidth allocation
US6898182B1 (en) * 2000-07-21 2005-05-24 Arris International, Inc Congestion control in a network device having a buffer circuit
WO2005096566A1 (en) 2004-03-30 2005-10-13 British Telecommunications Public Limited Company Data network, method and feedback node for assigning and providing path characterisation metrics
WO2005109783A1 (en) 2004-05-07 2005-11-17 British Telecommunications Public Limited Company Processing of data in networks
US20050276219A1 (en) * 2004-05-26 2005-12-15 Axiowave, Networks, Inc. Routing of data packet traffic to a common destination egress queue from a plurality of subscribers each contracting for respective bandwidth of data flow, a method of and apparatus for fairly sharing excess bandwidth and packet dropping amongst the subscribers and with the granularity of contracted traffic flow
US7027393B1 (en) * 2001-03-02 2006-04-11 Cisco Technology, Inc. TCP optimized single rate policer
US7092357B1 (en) * 2001-11-13 2006-08-15 Verizon Services Corp. Anti-flooding flow-control methods and apparatus
US20070076606A1 (en) * 2005-09-15 2007-04-05 Alcatel Statistical trace-based methods for real-time traffic classification
US7295516B1 (en) * 2001-11-13 2007-11-13 Verizon Services Corp. Early traffic regulation techniques to protect against network flooding

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3788908B2 (ja) * 2000-12-28 2006-06-21 株式会社エヌ・ティ・ティ・ドコモ 受付制御装置及びその新規接続受付制御方法
CN1170444C (zh) * 2001-08-10 2004-10-06 华为技术有限公司 一种对每个分组数据协议上下文进行流量监管的装置和方法
US7376159B1 (en) * 2002-01-03 2008-05-20 The Directv Group, Inc. Exploitation of null packets in packetized digital television systems
CN1319326C (zh) * 2003-04-01 2007-05-30 华为技术有限公司 一种基于承诺接入速率的带宽统计复用方法
JP4722964B2 (ja) * 2008-05-30 2011-07-13 富士通株式会社 移動通信システムにおけるチャネル設定方法

Patent Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6266327B1 (en) * 1998-03-20 2001-07-24 Lucent Technologies Inc. Non-conformance indicator for the guaranteed frame rate service
US6724721B1 (en) * 1999-05-07 2004-04-20 Cisco Technology, Inc. Approximated per-flow rate limiting
US6865185B1 (en) * 2000-02-25 2005-03-08 Cisco Technology, Inc. Method and system for queuing traffic in a wireless communications network
US6839321B1 (en) * 2000-07-18 2005-01-04 Alcatel Domain based congestion management
US6898182B1 (en) * 2000-07-21 2005-05-24 Arris International, Inc Congestion control in a network device having a buffer circuit
US7027393B1 (en) * 2001-03-02 2006-04-11 Cisco Technology, Inc. TCP optimized single rate policer
US20030007454A1 (en) * 2001-07-09 2003-01-09 International Business Machines Corporation Traffic management in packet-based networks
US20030081546A1 (en) * 2001-10-26 2003-05-01 Luminous Networks Inc. Aggregate fair queuing technique in a communications system using a class based queuing architecture
US7092357B1 (en) * 2001-11-13 2006-08-15 Verizon Services Corp. Anti-flooding flow-control methods and apparatus
US7295516B1 (en) * 2001-11-13 2007-11-13 Verizon Services Corp. Early traffic regulation techniques to protect against network flooding
WO2003049319A1 (en) 2001-11-30 2003-06-12 British Telecommunications Public Limited Company Method of resource control in a wireless network
WO2005032068A1 (en) 2003-09-29 2005-04-07 British Telecommunications Public Limited Company Bandwidth allocation
WO2005096566A1 (en) 2004-03-30 2005-10-13 British Telecommunications Public Limited Company Data network, method and feedback node for assigning and providing path characterisation metrics
WO2005109783A1 (en) 2004-05-07 2005-11-17 British Telecommunications Public Limited Company Processing of data in networks
US20050276219A1 (en) * 2004-05-26 2005-12-15 Axiowave, Networks, Inc. Routing of data packet traffic to a common destination egress queue from a plurality of subscribers each contracting for respective bandwidth of data flow, a method of and apparatus for fairly sharing excess bandwidth and packet dropping amongst the subscribers and with the granularity of contracted traffic flow
US20070076606A1 (en) * 2005-09-15 2007-04-05 Alcatel Statistical trace-based methods for real-time traffic classification

Non-Patent Citations (24)

* Cited by examiner, † Cited by third party
Title
Chhabra et al., "XCHOKE: Malicious Source Control for Congestion Avoidance at Internet Gateways," Proceedings of the 10th IEEE International Conference on Network Protocols (ICNP'02), 2 pages.
Clerget et al., "TUF: Tag-Based Unified Fairness," IEEE INFOCOM 2001, 10 pages.
Crowcroft et al., "Differentiated End-to-End Internet Services Using a Weighted Proportional Fair Sharing TCT," Computer Communications Review, Jul. 1998, 17 pages.
European Search Report mailed Jan. 26, 2006 in Application No. 05255164.5.
Floyd et al., "Equation-Based Congestion Control for Unicast Applications," Proc. ACM SIGCOMM, Aug. 2000, pp. 1-14.
Floyd et al., "Promoting the Use of End-to-End Congestion Control in the Internet," IEEE/ACM Transactions on Networking, May 3, 1999, pp. 1-16.
International Search Report for PCT/GB2006/000417 mailed Apr. 18, 2006.
International Search Report mailed Apr. 18, 2006 in International Application No. PCT/GB2006/000417.
ITU-T Recommendation I.371, "Traffic Control and Congestion Control in B-ISDN," Mar. 2004, pp. 1-125.
Jain et al., "Quick-Start for TCP and IP," Ietf Internet Draft, Sep. 2004, pp. 1-55.
Jiang et al., "Passive Estimation of TCP Round-Trip Times," ACM SIGCOMM Computer Communications Review, vol. 32, No. 3, Jul. 2002, pp. 75-88.
Katabi et al., "Congestion Control for High Bandwidth-Delay Product Networks," ACM SIGCOMM'02, Computer Communication Review, Oct. 2002, 14 pages.
Kelly et al., "Rate Control for Communication Networks: Shadow Prices, Proportional Fairness and Stability," Journal of the Operational Research Society, 1998, 49(3), pp. 1-20.
Mahaj an et al., "Controlling High-Bandwidth Flows at the Congested Router," Proc. IEEE International Conference on Network Protocols (ICNP'01), 2001, pp. 192-201.
Nikolouzou et al., "Network services definition and deployment in a differentiated services architecture," 2002 IEEE International Conference on Communications, vol. 1 of 5, Apr. 28, 2002, pp. 1057-1062, XP010589653.
Nikolouzou et al., "Network Services Definition and Deployment in a Differentiated Services Architecture," IEEE International Conference on Communications, 2002, 6 pages.
Ott et al., "SRED: Stabilized RED," IEEE Conference on Computer Communications (Infocom'99), Mar. 1999, pp. 1-10.
Padhye et al., "Modeling TCP Throughout: A Simple Model and its Empirical Validation," Proc. ACM SIGCOMM, 1998, 12 pages.
Pan et al., "Approximate Fairness Through Differential Dropping," Computer Communication Review, 33(2), Apr. 2003, pp. 1-18.
Pan et al., "CHOKe A Stateless Active Queue Management Scheme for Approximating Fair Bandwidth Allocation," Jun. 12, 1999, pp. 1-20.
Raisinghani et al., "Analysis of Receiver Window Control in Presence of a Fair Router," IEEE Intl. Conf. on Personal and Wireless Communications, Jan. 2005, 3 pages.
Reddy, "LRU-RED: An Active Queue Management Scheme to Contain High Bandwidth Flows at Congested Routers," Proc. Globecomm'01, Nov. 2001, 5 pages.
Siris, "Resource Control for Elastic Traffic in CDMA Networks," Proc. ACM International Conference on Mobile Computing and Networks (MobiCom'02), Sep. 2002, 12 pages.
Van Jacobson et al., "Congestion Avoidance and Control," Proc. ACM SIGCOMM'88, Computer Communication Review, Nov. 1988, pp. 1-21.

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9832003B2 (en) 2013-08-09 2017-11-28 Kumu Networks, Inc. Systems and methods for self-interference canceller tuning
US10050659B2 (en) 2013-08-09 2018-08-14 Kumu Networks, Inc. Systems and methods for non-linear digital self-interference cancellation
US9794210B1 (en) 2013-11-14 2017-10-17 The United States Of America, As Represented By The Secretary Of The Army Priority assignment based on similarity
US10516642B2 (en) 2013-11-14 2019-12-24 The Government Of The United States, As Represented By The Secretary Of The Army Priority assignment based on similarity
US10439975B2 (en) 2013-11-14 2019-10-08 The Government Of The United States, As Represented By The Secretary Of The Army Priority assignment based on similarity
US10230422B2 (en) 2013-12-12 2019-03-12 Kumu Networks, Inc. Systems and methods for modified frequency-isolation self-interference cancellation
US10243598B2 (en) 2015-10-13 2019-03-26 Kumu Networks, Inc. Systems for integrated self-interference cancellation
US11671129B2 (en) 2015-12-16 2023-06-06 Kumu Networks, Inc. Systems and methods for linearized-mixer out-of-band interference mitigation
US10200217B2 (en) 2015-12-16 2019-02-05 Kumu Networks, Inc. Systems and methods for adaptively-tuned digital self-interference cancellation
US11082074B2 (en) 2015-12-16 2021-08-03 Kumu Networks, Inc. Systems and methods for linearized-mixer out-of-band interference mitigation
US10230410B2 (en) 2015-12-16 2019-03-12 Kumu Networks, Inc. Systems and methods for out-of-band interference mitigation
US10666305B2 (en) 2015-12-16 2020-05-26 Kumu Networks, Inc. Systems and methods for linearized-mixer out-of-band interference mitigation
US10050597B2 (en) 2015-12-16 2018-08-14 Kumu Networks, Inc. Time delay filters
US10541840B2 (en) 2015-12-16 2020-01-21 Kumu Networks, Inc. Systems and methods for adaptively-tuned digital self-interference cancellation
US9819325B2 (en) 2015-12-16 2017-11-14 Kumu Networks, Inc. Time delay filters
US10404297B2 (en) 2015-12-16 2019-09-03 Kumu Networks, Inc. Systems and methods for out-of-band interference mitigation
US9800275B2 (en) 2015-12-16 2017-10-24 Kumu Networks, Inc. Systems and methods for out-of band-interference mitigation
US10454444B2 (en) 2016-04-25 2019-10-22 Kumu Networks, Inc. Integrated delay modules
US9979374B2 (en) 2016-04-25 2018-05-22 Kumu Networks, Inc. Integrated delay modules
US10862528B2 (en) 2017-03-27 2020-12-08 Kumu Networks, Inc. Systems and methods for tunable out-of-band interference mitigation
US11515906B2 (en) 2017-03-27 2022-11-29 Kumu Networks, Inc. Systems and methods for tunable out-of-band interference mitigation
US10103774B1 (en) 2017-03-27 2018-10-16 Kumu Networks, Inc. Systems and methods for intelligently-tuned digital self-interference cancellation
US11121737B2 (en) 2017-03-27 2021-09-14 Kumu Networks, Inc. Systems and methods for intelligently-tuned digital self-interference cancellation
US10236922B2 (en) 2017-03-27 2019-03-19 Kumu Networks, Inc. Systems and methods for tunable out-of-band interference mitigation
US11764825B2 (en) 2017-03-27 2023-09-19 Kumu Networks, Inc. Systems and methods for tunable out-of-band interference mitigation
US10840968B2 (en) 2017-03-27 2020-11-17 Kumu Networks, Inc. Systems and methods for intelligently-tuned digital self-interference cancellation
US10382089B2 (en) 2017-03-27 2019-08-13 Kumu Networks, Inc. Systems and methods for intelligently-tuned digital self-interference cancellation
US11211969B2 (en) 2017-03-27 2021-12-28 Kumu Networks, Inc. Enhanced linearity mixer
US10547346B2 (en) 2017-03-27 2020-01-28 Kumu Networks, Inc. Systems and methods for intelligently-tuned digital self-interference cancellation
US10623047B2 (en) 2017-03-27 2020-04-14 Kumu Networks, Inc. Systems and methods for tunable out-of-band interference mitigation
US10382085B2 (en) 2017-08-01 2019-08-13 Kumu Networks, Inc. Analog self-interference cancellation systems for CMTS
US11128329B2 (en) 2018-02-27 2021-09-21 Kumu Networks, Inc. Systems and methods for configurable hybrid self-interference cancellation
US10425115B2 (en) 2018-02-27 2019-09-24 Kumu Networks, Inc. Systems and methods for configurable hybrid self-interference cancellation
US10804943B2 (en) 2018-02-27 2020-10-13 Kumu Networks, Inc. Systems and methods for configurable hybrid self-interference cancellation
US11562045B2 (en) 2019-03-14 2023-01-24 Kumu Networks, Inc. Systems and methods for efficiently-transformed digital self-interference cancellation
US10868661B2 (en) 2019-03-14 2020-12-15 Kumu Networks, Inc. Systems and methods for efficiently-transformed digital self-interference cancellation
US11888749B2 (en) 2021-10-25 2024-01-30 Hewlett Packard Enterprise Development Lp Reverse loss detection for communication network bandwidth estimation with token buckets

Also Published As

Publication number Publication date
JP4705115B2 (ja) 2011-06-22
EP1847081B1 (en) 2014-12-24
KR101228288B1 (ko) 2013-01-30
KR20070100899A (ko) 2007-10-12
CN101116292A (zh) 2008-01-30
WO2006082443A1 (en) 2006-08-10
CN101116292B (zh) 2014-11-05
JP2008530841A (ja) 2008-08-07
EP1847081A1 (en) 2007-10-24
US20080192636A1 (en) 2008-08-14

Similar Documents

Publication Publication Date Title
US7948878B2 (en) Policing networks
Floyd et al. Promoting the use of end-to-end congestion control in the Internet
Feng et al. GREEN: proactive queue management over a best-effort network
Chatranon et al. A survey of TCP-friendly router-based AQM schemes
US8289851B2 (en) Lightweight bandwidth-management scheme for elastic traffic
EP1758313A1 (en) Policing networks
Seddigh et al. Experimental study of assured services in a Diffserv IP QoS network
Chandrayana et al. Uncooperative congestion control
Yamaguchi et al. A queue management algorithm for fair bandwidth allocation
Mellia et al. TCP-aware packet marking in networks with diffserv support
Khosroshahy UARA in edge routers: an effective approach to user fairness and traffic shaping
Chatranon et al. Fairness of AQM schemes for TCP-friendly traffic
Haider et al. Congestion control algorithms in high speed telecommunication networks
Habib et al. Network tomography-based unresponsive flow detection and control
Pan et al. Approximate fair bandwidth allocation: A method for simple and flexible traffic management
Akintola et al. Modeling and Performance Analysis of Dynamic Random Early Detection (DRED) Gateway for Congestion Avoidance.
Aweya et al. WINTRAC: A TCP window adjustment scheme for bandwidth management
Prasad et al. A stateless and light-weight bandwidth management mechanism for elastic traffic
Orozco et al. A simulation study of the Adaptive RIO (A-RIO) queue management algorithm
Casetti et al. A lightweight marker with partial state information for DiffServ networks
Zhu A new class-based traffic queue management algorithm in the internet
Kinicki et al. A Performance Studym of Explicit Congestion Notification (ECN) with Heterogeneous TCP Flows
Zheng et al. Adaptive explicit congestion notification
Li et al. Core‐stateless fair rate estimation fair queuing
Jacquet et al. A path-aware rate policer: design and comparative evaluation

Legal Events

Date Code Title Description
AS Assignment

Owner name: BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY,

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JACQUET, ARNAUD;BRISCOE, ROBERT JOHN;CAIRANO-GILFEDDER, CARLA DI;AND OTHERS;REEL/FRAME:019672/0608;SIGNING DATES FROM 20060220 TO 20060616

Owner name: BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY,

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JACQUET, ARNAUD;BRISCOE, ROBERT JOHN;CAIRANO-GILFEDDER, CARLA DI;AND OTHERS;SIGNING DATES FROM 20060220 TO 20060616;REEL/FRAME:019672/0608

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12