(2)类型2
类型2是有业务层QoS协商能力的用户设备(如SIP电话)。用户设备通过业务信令来进行QoS协商，但不感知传输层QoS。业务QoS只关注与应用相关的QoS。
(3)类型3
类型3是有传输层QoS协商能力的用户设备(如UMTS用户终端)。用户设备支持类似资源预留协议(RSVP)的传输信令，因而能直接和传输设备协商传输层QoS。
3.2 资源控制模式
RACF需要支持下列两种QoS资源控制模式以应对上述3种用户设备类型和不同的传输层QoS能力：
(1)推模式
RACF按照策略规则授权和制订资源控制决策，并下指令给传输层功能实体执行策略决策。
(2)拉模式
RACF基于策略规则进行授权，然后根据传输层功能实体的请求进行再授权，回应最终决策并使之执行。
3.3 QoS控制流程
下面介绍两种资源控制模式的QoS控制流程以及相关层面实体间的交互。
3.3.1 推模式的QoS资源控制流程
推模式适合所有3类用户设备，而前2类用户设备只能采用推模式。
第一类用户设备，没有QoS协商能力。SCF替用户决定业务相关的QoS要求，发送给RACF进行授权和资源预留。
第二类用户设备，支持业务层QoS协商，通过业务信令提出业务层QoS要求。SCF从业务信令中抽取出QoS要求，发送给RACF进行授权和资源预留。
第三类用户设备，采用和第二类用户设备一样的QoS资源控制流程，但要求RACF预先将授权和QoS资源预留信息下到传输层功能实体中。用户设备发出的传输层QoS信令用于调用传输实体中QoS资源和QoS策略的执行。
具体控制流程如图2所示，描述如下：
(1)用户设备向SCF发出业务请求(如，SIP请求)，业务请求中有可能包括QoS需求参数。
(2)SCF从业务请求中推导出或抽取出QoS需求参数，发送一个包含QoS需求参数的资源预留请求给RACF，请求QoS授权和资源预留。
(3)RACF基于策略原则、资源状况和存储在NACF中的用户资料进行授权和接纳控制。一旦RACF批准了SCF来的资源预留请求，它就将门控信息、分组QoS标记和带宽分配等信息推到传输层功能实体中。
3.3.2 拉模式的QoS资源控制模式
拉模式只适合第三类用户设备，用户设备显式地通过传输层QoS信令，按照特定传输路径直接向传输层功能实体请求QoS资源预留。但传输QoS资源的预留需要先得到SCF的预授权。
具体控制流程如图3所示，描述如下：
