滑窗算法

滑窗算法與跳窗算法類似，滑窗(Moving Window)算法也是通過限制各個時間視窗內所能接收的最大信元數對業務量進行控制。區別是，在滑窗算法中，時間視窗不是向前跳，而是每過一個信元時間向前滑動一次，滑動的長度是一個信元的時間。 以下是幾種UPC算法。信元一旦被UPC判定是違約的，就要對其採取管制措施。

主要措施包括：

1． 丟棄違約信元甚至所在連線上的所有信元。這是對違約信元及其連線的最直接、最嚴厲的懲罰。在有些場合下，這種措施不太合理。因為用現有的業務量參數難以對業務特徵進行完全準確的描述，而且在呼叫建立階段這些參數常常難以確定。

2． 將違約信元打上標記（將信元頭中的CLP置1），交換節點在網路發生擁塞時丟棄這些信元。顯然，這對違約信元的處理要寬鬆一些。但它要求網路能夠區分標記和未標記信元。會為違約者盜用資源提供機會。

3． 延遲違約信元來平滑業務特性。這種方法需要很大的緩衝區，並會增加時延。同樣也會為違約者盜用資源提供機會。

4． 通知源端降低傳送速率。這種方法的缺點是反應遲緩，難以及時保護履約連線的QoS。