与跳窗算法类似，滑窗(Moving Window)算法也是通过限制各个时间窗口内所能接收的最大信元数对业务量进行控制。区别是，在滑窗算法中，时间窗口不是向前跳，而是每过一个信元时间向前滑动一次，滑动的长度是一个信元的时间。 以下是几种UPC算法。信元一旦被UPC判定是违约的，就要对其采取管制措施。主要措施包括：

1． 丢弃违约信元甚至所在连接上的所有信元。这是对违约信元及其连接的最直接、最严厉的惩罚。在有些场合下，这种措施不太合理。因为用现有的业务量参数难以对业务特征进行完全准确的描述，而且在呼叫建立阶段这些参数常常难以确定。

2． 将违约信元打上标记（将信元头中的CLP置1），交换节点在网络发生拥塞时丢弃这些信元。显然，这对违约信元的处理要宽松一些。但它要求网络能够区分标记和未标记信元。会为违约者盗用资源提供机会。

3． 延迟违约信元来平滑业务特性。这种方法需要很大的缓冲区，并会增加时延。同样也会为违约者盗用资源提供机会。

4． 通知源端降低发送速率。这种方法的缺点是反应迟缓，难以及时保护履约连接的QoS。