承载业务流的控制机制

控制平面和用户平面的分离可能是IMS设计中最重要的方面之一。这两层之间完全独立并不可行，因为没有用户平面和控制平面之间的交互，运营商将无法控制服务质量（QoS）、IMS媒体业务流的源/目标、以及媒体业务流开始和停止的时间。因此，创建了一种机制对IMS媒体业务流将要使用的承载业务流进行授权和控制。该机制基于在IMS会话中所协商的SDP参数。这种在GPRS和IMS之间的交互总体上被称为基于服务的本地策略（SBLP）控制。随后，作为一种附加的能力，还对计费关联进行了定义。图3-10展示了SBLP中所包含的功能实体。该图还给出了基于版本6的体系结构模型，其中使用了一个独立的策略决策功能（PDF）以及Gq参考点。在版本5的体系结构中，PDF是与P-CSCF整合在一起的。本节中的例子既没有说明P-CSCF如何把SIP/SDP信息映射成为Diameter信息元素，也没有说明这个信息在Gq参考点上如何使用Diameter命令传送给PDF。相反地，这个例子主要关注于下列要点：从SIP/SDP会话信令角度看需要哪个信息，以及这个信息如何用于PDF。3.10.8节涵盖了Gq参考点的使用细节：

图3-10   SBLP实体

•  IP承载服务(BS)管理器——使用标准IP机制进行IPBS的管理。这个机制存在于GGSN中，并且在UE中可选。

•  翻译/映射功能——对用在UMTSBS中和用在IPBS中的机制和参数之间实现相互配合。它存在于GGSN中，并且在UE中可选。

•  UMTSBS管理器——处理来自UE的资源预留请求。它存在于GGSN和UE中。

•  策略实施点——是一个逻辑实体,负责对PDF所作的策略决策进行实施。它存在于GGSN的IPBS管理器中。

•  策略决策功能——是一个逻辑策略决策单元，使用标准IP机制在IP媒

体层中实现SBLP»在版本5中，它存在于P-CSCF；在版本6中，它是一个独立的实体。根据[RFC2753],PDF实际上是一个策略决策点，为基于策略的接纳控制定义了一个框架。

SBLP有7种功能。这7种功能将在后续的章节中逐一介绍：

• 承载授权。

• QoS承诺的批准。

• QoS承诺的删除。

• 承载释放的指示。

• 承载丢失/修复指示。

• 授权撤销。

• 计费标识符的交换。

3.10.1承载授权

IMS网络中的会话建立和修改包含了使用SIP和SDP进行的端到端消息交换。在这个消息交换期间，UE将协商一套媒体特性（例如，通用的编码方案）。如果一个运营商实施了SBLP,那么P-CSCF就将转发相关的SDP信息给PDF,同时指出发起者是谁。对选取的媒体成分，PDF对其IP流进行记录并且授权，这是通过将SDP参数映射到所授权的IP QoS参数上来实现的，以便将媒体通过Go接口传输到GGSN。

当UE为媒体激活或者修改PDP上下文时，它必须在其自身执行从SDP参数和应用的要求向UMTSQoS参数的映射。PDP上下文的激活或者修改还会包含收到的授权令牌和流标识符，用作绑定信息。

一旦接收到PDP上下文激活或修改请求时，GGSN就向PDF申请授权信息。PDF会比较接收到的绑定信息和存储的授权信息，并返回一个授权决策。如果绑定信息被验证是正确的，那么PDF将决策中的媒体授权细节告知GGSN。这个媒体授权细节包含与PDP上下文相关的IPQoS参数和分组分类器。

GGSN将授权得到的IPQoS参数映射为授权的UMTSQoS参数，并且最终GGSN会对UMTSQoS参数与PDP上下文授权得到的UMTSQoS参数进行比较。如果PDP上下文请求中的UMTSQoS参数包含在PDF授权的限制之中，那么PDP上下文的激活或者修改就会被接受。图3-11展示了上述介绍的功能，并且为了简化，将PDF表示为P-CSCF的一部分。如果存在独立的PDF,那么P-CSCF就需要将SIP/SDP信令信息映射成为合适的Diameter信息元素，并且通过Gq参考点上发送合适的Diameter请求给PDFO3.10.8节对这个功能进行了进一步的说明。

从上述介绍，我们可以发现两种不同的阶段：对QoS资源的授权（第1〜6步）和资源预留（第7〜14步）。下面我们将深入分析这两部分，并且还将介绍承载授权的最后一步，即QoS承诺的批准。

3.10.1.1对QoS资源的授权

图3-11中与QoS资源授权过程相对应的是第2~5步。在会话建立过程中，PDF收集IPQoS授权数据。这些数据包括：

（1）流标识符——用于标识IP流，这在与一个SIP会话相关联的媒体成分中进行了说明。流标识符包括两个部分：1）SDP会话描述中“m=”行的位置顺序号；2）指定的“m=”行中的IP流的顺序号（按端口号递增顺序）。

（2）数据速率——这个信息是从SDP带宽参数中获得的。数据速率包含IP层及其上层（例如UDP、RTP或者RTCP）的所有开销。如果允许会话中每个媒体使用多个编码方案，那么所授权的数据速率就按照带宽要求最高的编码方案进行设置。

图3.11使用SBLP的承载授权

（3）QoS类别一oS类别信息表示了可以用于该媒体成分的最高QoS类别。它是从SDP的媒体描述中获得的。

我们假设托拜厄斯（图3-11中的UE#1）想要和他的姐姐特里萨（UE#2）谈话。除了普通的语音呼叫之外，托拜厄斯还想激活双向或者单向的视频流。因此,他的终端生成一个SIPINVITE命令，它包含了反映托拜厄斯的选择及其UE能力的SDP。SDP包含所支持的编码方案、带宽需求（加上各自的特性），以及为每个可能的媒体流所指定的本地端口号。这儿我们只关注SBLP必需的那些参数。第11章包含了为整个会话建立的通用描述。从UE#1发出的SDP看起来会是这样的:

v=0

o=-32624648653262464868INIP65555::1:2:3:

t=32623776003262809600

m=video 50230 RTP/AVP 31

c=INIP65555::1:2:3:4

b=AS:35

b=RS:700

b=RR:700

m=video 50240 RTP/AVP 31

c=IN IP6 5555::1:2:3:4

b=AS:32

b=RS:640

b=RR:640

a=sendonly

m=audio 3456 RTP/AVP97 96

c=IN IP6 5555::1:2:3:4

b=AS:25.4

b=RS:500

b=RR:500

 当图3-11中PDF#1接收到这个SDP时，它就能够为上行链路方向（从UE#1到GGSN#1）生成授权数据。当托拜厄斯的UE响应时，PDF#1就能够为下行链路方向（从GGSN#1到UE#1）生成授权数据。需要注意，特里萨并不希望接收单向视频，因此相应的端口号被设置为0。

v=0

o=-32624648653262464868INIP65555::1:2:3:4

t=32623776003262809600

m=vide o 60230RTP/AVP 31

c=IN IP6 5555::5:6:7:8

b=AS:35

b=RS:700

b=RR:700

m=video 0RTP/AVP 31

c=IN IP6 5555::5:6:7:8

b=AS:32

b=RS:640

b=RR:640

a=recvonly

m=audio3550RTP/AVP 0

c=IN IP65555::5:6:7:8

b=AS:25.4

b=RS:500

b=RR:500

（1）流标识符根据上述信息，PDF#1和PDF#2就能够生成必需的流标识符。表3-3给出了PDF#1中的流标识符。

表3-3PDF#1中的流标识符信息

（2）数据速率 PDF从SDP参数"b=AS”中获得该媒体IP流的数据速率值。对于可能的关联的实时传输控制协议（RTCP）IP流，如果存在SDP参数"b=AS”、“b=RR”和“b=RS”，PDF将直接使用。如果SDP参数"b=RR”或“b=RS”不存在时，RTCPIP流的数据速率就可以按照协议［3GPPTS29.208］中所说明的方法从可利用的参数中获得。RTCP带宽的说明如下：

•  如果b=RS和b=RR存在，那么UL和DL的RTCP带宽=(bRS+bRR)/1000。

•  如果b=RS或者b=RR之一不存在，那么UL和DL的RTCP带宽=MAX［0.05XbAS,bRS/1000或者bRR/1000］。

•  如果b=RS和b=RR都不存在，那么UL和DL的RTCP带宽=0.05XbAS。表3-4给出了PDF#1计算得到的每个媒体类型的最大数据速率。

(3)QoS类型PDF将媒体类型信息映射到该媒体可以使用的最高QoS类型。当两个链路方向都使用时，在上行链路和下行链路方向上PDF将使用相同的Qos 类型[3GPP TS 29.207].[3GPP TS29.208]包含了详细的推导规则（表3-4中给出了一个汇总）。表3-5说明了在我们的例子中表3-4中的信息是如何应用的。一个RTCP IP流被授权的最大QoS类型与相应的RTP媒体IP流相同。

表3-4每个媒体类型的最大数据速率

表3-5 PDF#1中每个流标识符的最大数据速率和QOS类型

如图3-11所示(承载授权)，从第2和第5步，授权的IP QoS在PDF处被创建并保存。授权的IPQoS包括QoS类型和数据速率。同时，PDF创建流标识符,这个标识符将在随后被用于GGSN中分组分类器的创建。表3-5对此进行了汇总。

(4)授权令牌图3-11中，第2步提到“传送授权令牌给UE#1和UE#2”。但是，什么是授权令牌呢？

• 它是与接入点名称相关联的一个标识符，并且在所有PDP上下文中保持惟一性。

• 它在授权数据生成的同时由PDF产生。

• 它由IMS会话标识符和PDF标识符组成。

• 它的语法遵循［RFC3520］。

• 它被按照［RFC3313］的方法传送给UE。

• UE在PDP上下文激活或者修改请求中包括它。

• GGSN使用授权令牌内的PDF标识符来找到拥有授权的IPQoS信息的PDF。

• 当接收到来自GGSN的请求时，PDF使用授权令牌来找到正确的授权数据。

(5)媒体聚合SIP和IMS允许建立的多媒体会话包含许多不同的成分，例如音频和视频。任何参与方都可以在一个正在进行的会话中增加或者减少一个媒体成分。正如2.1.6节中所述，为了计费的目的，所有媒体成分都必须是可以惟一标识的，并且必须可以对一个会话中的每个成分都能单独计费。

不幸的是，版本5的GGSN只能为PDP上下文产生一个GGSN呼叫细节记录(CDR)。因此，在同一PDP上下文中区分不同媒体成分的业务流是不可能的。由于当前的计费数据生成和关联模型并不允许同一个次PDP上下文中媒体流的复用，因此必须有一个IMS层机制来强制UE为每个媒体成分建立单独的PDP上下文。为了这个目的，定义了一个“保持独立(keep-it-separate)"指示。

当P-CSCF接收到一个终结会话的初始INVITE请求或者一个发起会话的对INVITE请求的183响应(会话过程)时，P-CSCF可以根据［RFC3524］对SDP进行修改，以向UE指示根据局部策略对一个特定媒体流进行了聚合［3GPPTS24.229］。

［RFC3524］定义了单预留流(SRF)聚合类型(a=group:SRF)。SRF聚合按下列方式使用：

•  如果网络想在相同的PDP上下文中承载多个特定媒体，那么P-CSCF为这些媒体成分设置相同的SRF值。

•  如果网络想在不同的PDP上下文中承载多个特定媒体，那么P-CSCF为每个媒体成分设置不同的SRF值。

•  如果网络不设置SRF指示，那么UE就可以根据它的喜好对媒体流进行自由的聚合。

标准［3GPPTS23.228］和［3GPPTS24.229］中给出了如下进一步的限制和原则：

•  P-CSCF应在整个SIP会话过程中应用和维护相同的策略。

•  如果增加了一个媒体流并且在初始INVITE或者183(会话过程)响应中指示进行媒体流聚合，P-CSCF就会根据［RFC3524］来修改SDP,以向UE指示这个新增的媒体流将被分到一个新聚合或者现有聚合中的一个。

•  如果在初始INVITE请求或者183(会话过程)响应中没有指示媒体流聚合，P-CSCF就不会对新增媒体流的SDP应用［RFC3524］。

•  P-CSCF不应在SDP中指示媒体流的重新聚合。

•  UE为支持一个单一媒体成分而使用的所有相关IP流（例如RTP/RTCP）都在同一PDP上下文中承载。

• 在版本5中假设来自不同IMS会话的媒体成分不能在同一PDP上下文内承载。这个要求在版本6中并没有使用，因为版本6引入了基于单个IP流进行计费的能力。

在下面的例子中，P-CSCF#1为183（会话过程）响应中的所有媒体类型强制给出了各自独立的PDP上下文，如下所示（给UE#1的183响应）：

v=0

o=-32624648653262464868INIP65555::1:2:3:4

t=3262377600 3262809600

a=group:SRF1

a=group:SRF2

a=group:SRF3

m=video60230RTP/AVP 31

a=mid:l

c=IN IP65555::5:6:7:8

b==AS:35

b=RS:700

b=RR:700

m=video 0 RTP/AVP 31

a=mid:2

c=IN IP65555::5:6:7:8

b=AS:32

b=RS:640

b=RR:640

a=recvonly

m=audio3550RTP/AVP0

a=mid:3

c=INIP65555::5:6:7:8

b=AS:25.4

b=RS:500

b=RR:500

分叉问题

当P-CSCF接收到一个分叉响应时，它将2.3.19节列出的信息发送给PDF。由于PDF收到了分叉指示，它也将先前分配的授权令牌指派给了分叉响应。另外,PDF还对任何新增的媒体成分进行授权，以及为先前授权的媒体成分任何增加的QoS要求进行授权，正如分叉响应所请求的。因此，一个媒体成分被授权的QoS等于所有分叉响应为这个媒体成分请求的最高QoS［3GPPTS29.207］。

3.10.1.2资源预留

UE功能

当UE在端到端消息交换中收到授权令牌时，它就得知网络中应用了SBLP。因此，它必须为PDP上下文激活(修改)请求，生成请求的QoS参数和流标识符。请求的QoS参数包括表3-6所列出的信息。从SBLP的角度看，表3-6中前三行给出了值得关注的值。有兴趣的读者可以在［3GPP TS 23.107］中找到其他QoS参数的更详细的说明。此处，只对业务流类别、确保比特速率和最大比特速率进行说明。

表3-6   请求的QOS参数

•  业务流类别——UMTS定义了四种不同的业务流类别，分别是会话(Conversational)类、流(Streaming)类、交互(Interactive)类和后台(Background)类。通过包含业务流类型信息，UMTS就可以对业务流信源模型进行假设，并且为该业务流类型的传输进行优化。

•  确保比特速率(GBR)——说明UMTS承载服务对用户或者应用所能够确保的比特速率。

•  最大比特速率(MBR)——说明用户或者应用能够接受或者提供的比特速率上限。这使得实际操作中可以使用不同的速率(例如，在GBR和MBR之间)。

业务流类别的值——下行或者上行链路的GBR和MBR——都不能超过每个流标识符的最大授权带宽和最大授权业务流类别所推导出的值。UE中的最大授权带宽是从SDP中推导出来的，推导方法与PDF中的一样。最大授权业务流类别是根据表3-7得到的。［3GPPTS29.208］中对这些参数的更为确切的推导原则进行了说明。

表3-7UE中每个媒体类型的最大授权业务流类别

［3GPPTS26.236］给出了对于会话类编码方案应用，如何设置其所请求的其他参数的建议；相应地，［3GPPTS26.234］给出了对于流类编码方案应用，如何设置其所请求的其他参数的建议。

在UE中，流标识符是以与PDF中相同的方式获得的。表3-8给出了由UE计算得到的每个流标识符的最大授权UMTS QoS参数。

表3-8 UE1（托拜厄斯）计算出的每个流标识符的最大授权UMTSQoS参数值举例

然后，UE需要决定总共需要多少个PDP上下文，关键的决定因素就是媒体流的本质（即要求的业务流类别）和从P-CSCF接收的聚合指示。在上面的例子中，包括了两种不同类型的双向媒体：视频和音频。这两种媒体都会要求高QoS（低延时和受保护的时间关系），因此，一个会话类业务流类别的PDP上下文就比较合适。不过，P-CSCF已经指出，每个IMS媒体成分都需要一个独立的PDP上下文。因此，UE#1应当激活两个不同的PDP±下文。否则，由PDF所执行的SBLP决策会导致PDP上下文激活过程失败。当P-CSCF没有指出需要单独PDP上下文时，那么UE可以对PDP上下文的数量进行优化。在我们的例子中，可能会打开一个新的用于视频和音频业务的PDP上下文。而且，如果存在合适的PDP上下文，UE甚至可能会利用现存的PDP上下文传输新的媒体元素。最后，表3-9给出了UE#1计算出的每个PDP上下文的最大授权UMTSQoS参数。

到此为止，UE已经完成了图3-11中的第7步。在导出和选择了合适的请求的QoS参数之后，UE就会激活必要的PDP上下文。授权令牌和流标识符都被插入到业务流模板信息单元中，［3GPPTS24.008］中给出了业务流模板信息单元中如何承载授权令牌和流标识符的详细说明。请求的QoS参数被插入到QoS信息单元中，［3GPPTS24.008］中对QoS信息单元中如何承载请求的QoS参数进行了详细说明。

表3-9UE#1（托拜厄斯）计算出的每个PDP上下文的最大授权UMTSQoS参数值举例

GGSN功能

当GGSN接收了向一个接入点名称发出的次PDP上下文激活请求，并且该接入点打开了Go参考点时，GGSN就会：

•  用从提供的授权令牌中提取出的PDF身份来识别正确的PDF。如果不存在授权令牌，那么GGSN可以拒绝该请求，或者在由一个本地存储的QoS策略所加的限制之内接收该请求。如果所请求的PDP上下文是非实时的（对应UMTS业务类型“背景类”或者“交互类”），并且这种PDP上下文并没有分配给UE用于相同的APN,版本6标准要求GGSN至少接受一个没有绑定信息和SBLP授权的辅助PDP上下文激活请求［3GPPTS29.207］。这种功能是必需的，当一个运营商提供单独的APN给没有利用SBLP的业务（例如，蜂窝上的按键通话或者基于会话的消息）或者利用SBLP的业务（例如，话音和视频会话）。

•  为PDP上下文所承载的IP流向PDF申请授权信息。这个请求是一个公共开放策略服务（COPS）请求，并且包含提供的授权令牌和流标识符。请求的确切内容在第21章中介绍。

•  在收到一个授权决策之后执行该决策。该授权决策通过一个COPS授权决策（Authorization-Decision）消息给出。第21章介绍了该决策的确切内容。该决策主要的组成部分有：

■方向指示——上行链路、下行链路。

■授权的IPQoS——数据速率、最大授权QoS类别。

■分组分类器（也被称为门描述符）——源IP地址和端口号、目的IP地址和端口号、协议ID。

•  将授权的IPQoS映射到授权的UMTSQoS=

•  对请求的QoS参数和授权的UMTSQoS进行比较。如果所有请求的参数都在这个限制范围之内，那么就接受该PDP上下文激活。换言之，如果满足下列准则［3GPPTS29.208］：

■请求的GBRDL/UL（如果请求的业务流类别是会话类或者流媒体类）或者MBRDL/UL（如果请求的业务流类别是交互类或者后台类）小于或者等于最大DL/UL授权数据速率。

■并且请求的业务流类别小于或者等于最大授权业务流类别。

如果请求的QoS超过授权的UMTS QoS,那么请求的UMTS QoS信息就将会被下调为授权的UMTSQoS信息。

• 基于接收到的分组分类器构建一个门描述符。门描述符允许执行一种门功能。门功能控制是否对IP分组进行转发。如果门关闭了，那么相关的IP流的所有分组都将被丢弃。如果门开启，那么相关的IP流的所有分组都将被转发。如3.10.8.2节所述，门的开启可以是授权决策事件的一部分或者可以是一个独立的决策。门的关闭可能是授权撤销决策的一部分。

• 存储绑定信息。

• 可能需要对PDF决策的策略决定数据进行缓存。

在对次PDP上下文进行修改时，如果修改请求没有超出以前授权的QoS,GGSN就可以利用以前的缓存信息来进行一个本地策略决策。如果GGSN没有对信息进行缓存，那么它就要执行上述介绍的功能。有一种情况例外：如果GGSN收到了对一个打开了Go接口的接入点名称的次PDP上下文修改请求，并且没有收到任何绑定信息，那么只要先前已经为该PDP上下文提供了绑定信息，GGSN就会拒绝这个次PDP上下文修改。

PDF功能

当PDF收到了COPS请求的时候，则PDF会确认：

•  授权令牌是有效的。

•  相关SIP会话存在。

•  绑定信息中包含有效的流标识符。

•  授权令牌没有被一个授权变更请求所改变。

•  UE遵循聚合指示。

•  如果PDF的确认成功，那么PDF将决定以下信息并将它们发送给GGSN：授权的IP QoS、分组分类器和门状态。当有效绑定信息包括一个以上的流标识符时，则返回GGSN的信息就包括了对所有IP流的QoS总和以及对这些IP流的合适的分组过滤器。

在我们的例子中，UE#1需要激活两个PDP上下文。当第一个PDP上下文（双向视频）的一个次PDP上下文激活到达GGSN#1时，GGSN就会将授权令牌和流标识符（1,1和1,2）从业务流模板中提取出来，并且将它们发送给PDF#loPDF#l使用这个授权令牌来识别相应的IMS会话。PDF#1确认该会话确实存在，并且为流标识符（1,1和1,2）返回授权的IPQoS参数和分组分类器。GGSN#1将授权的IPQoS映射为授权的UMTSQoS,它比较这两个值并且发现一切正常。最后，GGSN#1接受这个请求，并且根据接收到的分组分类器来建立门功能。相同的过程还适用于其他的相关PDP上下文。

另外，当PDF从P-CSCF处收到了修改后的SDP信息时，它能够发送新的独立决策给GGSN。这可能是需要的，例如在有分叉的情况下。

3.10.2QoS承诺批准功能

在资源预留过程期间，一个PDF发送分组分类器给一个GGSN。基于这些分组分类器，GGSN生成一个门，对输入和输出的业务流进行策略控制。何时开启这个门是由PDF决定的。当门开启的时候，GGSN就允许业务流通过GGSN。开门的命令可能作为对GGSN发出的初始授权请求的响应而被发送，或者作为独立的决策被发送。通过独立的决策，运营商可以确信用户平面的资源在IMS会话最终被接受（即当接收到SIP200OK消息时）之前不被使用。在这种情况下，终端用户将在完成会话之前失去所有要被传送的通告，因为GGSN将丢弃所有用户平面来话的IP分组。

3.10.3QoS承诺删除功能

当PDF不允许业务流穿过GGSN的时候，本功能将关闭GGSN中的门。例如，当会话中的一个媒体成分由于媒体的重新协商而被置于挂起状态时，这个功能就被使用。

3.10.4承载释放指示功能

当GGSN接收到一个PDP上下文删除请求，并且PDP上下文先前已经通过Go参考点被授权时，那么GGSN将通过发送一个COPS请求状态删除消息，把与SIP会话有关的承载释放通知给PDF,PDF则为相应的媒体成分删除其授权。当PDF收到了一个承载已被释放的报告时，它可以请求P-CSCF释放会话，并且通过3.10.6节描述的步骤撤销所有的相关媒体授权。

3.10.5对于承载丢失/修复的指示

当一个PDP上下文更新请求中的MBR值等于Okbit/s时，GGSN需要向PDF发送一个COPS报告消息。同样，当这个MBR被从Okbit/s改变时，GGSN会在从服务GPRS支持节点（SGSN）接收到一个更新之后向PDF发送一个COPS报告消息。

当GPRS系统中正在使用媒体流和会话服务类型时，IMS使用这个机制能够知道UE巳经丢失或者修复了它的无线承载。［3GPPTS23.060］指出，当无线网络控制器（RNC）通知SGSN有关lu释放或者无线接入承载释放的时候，SGSN需要向GGSN发送一个PDP上下文更新请求。当PDF接收到MBR等于Okbit/s的报告时，它可以请求P-CSCF来释放会话，并且通过3.10.6节中所述的过程取消所有相关的媒体授权。

3.10.6撤销功能

这个功能用于在GPRS网络中强制释放先前授权的承载资源。通过这个机制,当一个SIP会话结束的时候PDF能够确保UE释放PDP上下文，或者当与PDP上下文捆绑的一个媒体成分从会话中删除的时候UE会修改该PDP上下文。如果UE在运营商所设置的预定时间内无法完成撤销，那么PDF就会撤消这些资源。

3.10.7计费标识符交换功能

Go参考点是IMS和GPRS网络之间的联系纽带。为了像第3.10.2节所描述的那样开展计费关联，IMS层需要知道相应的GPRS层计费标识符，反之亦然。这些计费标识符在承载授权阶段被交换。IMS计费标识符在授权决策消息中被传送给GGSN,而GPRS计费标识符作为授权报告的一部分被传送给PDF。

3.10.8 Gq参考点的使用

通过使用Gq参考点，PDF就可以作为一个独立的网络实体被部署。当使用独立的PDF时，P-CSCF需要把来自SIP/SDP会话信令的必要信息传送给PDFo相同地，PDF使用Gq来发送回复和独立的通知给P-CSCF。为了传送这些信息，P-CSCF和PDF使用RFC3588、NASREQDiameter应用和3GPPTS29.209所定义的Diameter命令。本节给出了这些命令的简要汇总，以及这些命令在P-CSCF和PDF之间使用的时间，以便支持不同的SBLP功能。

Gq参考点使用四对请求和回复：

•  AA请求/AA回复（AAR&AAA）；

•  Re-Auth请求/Re-Auth回复（RAR&RAA）；

•  会话终止请求/会话终止回复（STR&STA）；

•  放弃会话请求/放弃会话回复（ASR&ASA）。

3.10.8.1承载授权

当SBLP用于网络的时候，P-CSCF需要把SIP/SDP会话信令中获取的相关信息发送给PDFoPDF使用这个信息对通过Go参考点接收的请求进行授权判断。而且，P-CSCF需要得到授权标志以及GPRS计费标识符用于与计费相关的操作。为此，就要使用AAR&AAA以及RAR&RAADiameter命令对。

在接收到包含SDP信息的SIP请求或者响应之后，P-CSCF发送一个AAR命令给PDF。这个AAR命令在其他基本信息之外还包含了媒体流、资源预留策略、

指示转发策略、IMS计费标识符等相关信息，及所使用的应用的相关信息以及SIP分支（SIPFORKING）的信息。在我们的例子中，在收到来自Tobia的UE的SIPINVITE请求的时候，图3-11中的P-CSCF#1将首先发送AAR命令。这个命令承载了用于PDF创建下行链路信息（流标识符、计算最大带宽以及获得最大授权的QoS类型）所必需的信息。然后当P-CSCF#!收到来自Teresa的UE的183会话过程响应的时候，它就会回复一个AAR命令。第二个AAR命令将承载必要的信息来创建上行链路信息。现在PDF就准备对整个承载激活请求进行授权了。

在初始的AAR命令中，P-CSCF还将指出在每个承载授权中P-CSCF是否希望被联络，以及PDF是否可以使用可用信息来完成授权的判断（资源预留策略）。而且，P-CSCF可能指出它对接收承载丢失、承载恢复或者承载释放的指示更感兴趣（指示转发策略）。在这些情况下，PDF在接收到通过Go参考点的来自GGSN的合适信息后会发送一个RAR命令给P-CSCF»RAR命令是由RAA命令进行确认的。AAR命令是由AAA命令进行确认的。授权标志和/或GPRS计费标识符和/或去往P-CSCF的GGSN的IP地址将在AAA命令中传送。

3.10.8.2   QoScommit委托的确认和删除

QoS委托的确认和删除是作为AAR命令的一部分给可的——也就是说，在GGSN中开放/关闭/删除合适的通道。为此，3GPP在［3GPPTS29.209］中定义和开发了DiameterAVP,即所谓的“流状态AVP”。这个AVP可以有五个不同的值：上行可用、下行可用、可用（双向）、不可用和删除。不同的“可用”值是用于打开通道的（即允许用户平面业务传送）。P-CSCF可能在初始的AAR命令或者在P-CSCF中接收到SIP200OK后触发的AAR命令中指示PDF打开合适的通道。P-CSCF使用“不可用"值，例如当SIP会话或者其媒体单元之一beputonhold。"删除”值用于删除IP流的授权。这可能发生在诸如特定单元从SIP会话删除的时候。

3.10.8.3承载释放功能指示

在接收到通过Go参考点的来自GGSN承载释放通告后，如果P-CSCF已经请求了这种类型的通告，PDF就需要通知P-CSCFo如果一个SIP会话中的所有IP流都受影响的话，PDF就使用ASR命令。在ASR命令中，3GPP已经定义了3GPP特定的AVP,即“放弃原因AVP”，用来指出承载释放的原因。相反地，如果不是一个SIP会话中的所有IP流都受影响的话，就使用RAR命令。在RAR命令中，3GPP已经定义了3GPP特定的AVP,即"特定动作AVP”，用来指出承载释放的原因。这种情况是可能发生的，例如，一个多媒体会话中只有视频部分掉话的时候。

3.10.8.4承载丢失/恢复功能指示

当GGSN通过Go参考点报告承载丢失或者承载恢复的时候，如果P-CSCF已经请求了这种类型的通告，PDF就需要通知P-CSCFo为此，PDF发送包括特定动作AVP的RAR命令，用来指出承载的丢失或者承载的恢复。

3.10.8.5撤销功能

为了触发与SIP会话相关的PDP上下文的释放,P-CSCF发送一个STR命令。例如，这可能发生在SIP会话被释放的时候。当PDF接收到这个命令的时候，它将通过Go参考点发送其他消息来触发GGSN发起的PDP上下文去激活，以便在SIP会话终止之后防止承载的误用。

表3-10    GQ命令