IMS基本概念之 控制承载通道媒体流的机制（SBLP）

3.9 控制承载通道媒体流的机制

控制层面和用户层面的分离可能是IMS设计中最重要的问题之一。这两层的完全独立是不可能的，这是因为如果没有控制层面和用户层面的交互，运营商就不能控制服务质量（QoS）、IMS媒体流的源和目的、以及媒体什么时候开始和结束。因此，为了IMS媒体流建立了一种机制来授权和控制承载通道的使用，它建立在IMS会话中协商的SDP参数的基础上。这种GPRS和IMS间的交互被称作基于服务的策略控制（SBLP）。再后来，计费关联也作为一种额外的能力被加入进来。下图显示了与SBLP有关的功能性实体。图中显示了在版本6种被标准化的独立的策略决定功能实体（PDF）和Gq接口。

图 3‑12 SBLP的功能实体

· IP承载通道服务（BS）管理器 – 使用标准的IP机制管理IP BS。它驻留在GGSN中，并可选的驻留在UE中。

· 翻译/映射功能实体 – 提供UMTS BS中和IP BS中使用的机制和参数间的互操作。它驻留在GGSN中，并可选的驻留在UE中。

· UMTS BS管理器 – 处理UE发过来的资源预留请求。它驻留在GGSN和UE中。

· 策略加强点 – 是一个用来加强PDF做出的策略决定的逻辑实体。它驻留在GGSN中的IP BS管理器中。

· 策略决定功能实体 – 是一个使用标准的IP机制来在IP媒体层实现SBLP的逻辑策略决定实体。在版本5中，它驻留在P-CSCF中。在版本6中，它是一个单独的实体。根据[RFC2753]定义的基于服务的准入控制的框架，PDF在功能上是一个策略控制点。

3.9.1 SBLP的功能

SBLP一共有其中功能。这些功能会在接下来的各节中介绍：

· 承载通道授权。

· QoS委托的许可。

· QoS委托的移除。

· 承载通道释放的指示。

· 承载通道丢失/恢复的指示。

· 撤销授权。

· 交换计费标识符。

3.9.1.1 承载通道授权

IMS中会话的建立和修改会使用SIP和SDP进行的端到端的消息交换。在消息交换中，双方UE协商好一系列的媒体特性（例如共同的编结码）。如果运营商部署了SBLP，则P-CSCF会将相关的SDP信息和发起者指示一起转发给PDF。通过将SDP参数映射成授权的IP QoS参数，PDF对选择的媒体成分的IP流进行授权，这些QoS参数通过Go接口发送到GGSN。

当UE需要激活或者修改PDP上下文的时候，它需要自己进行SDP参数与应用需求到UMTS QoS参数的转换。PDP上下文的激活或修改还需要包含相绑定信息：接收到的授权令牌和流标识符。当接收到PDP上下文的激活或修改请求时，GGSN向PDF索要授权信息。PDF比较绑定信息和保存的授权信息，可以返回一个授权决定。如果绑定信息被确认为正确的，那么PDF将在决定中将授权的细节发送给GGSN。授权的细节包含了与PDP上下文相关的IP QoS参数和包分类器。

GGSN将IP QoS参数映射成UMTS QoS参数，并最终将授权的UMTS QoS参数和PDP上下文的UMTS QoS参数作比较。如果PDP上下文的UMTS QoS参数位于PDF授权的限制中，则PDP上下文的激活或修改会被接受。下图显示了上面介绍的功能，并且出于简单考虑，PDF被显示为P-CSCF的一部分。

从上面可以看出两个不同的阶段：授权QoS资源（步骤1~6）和预留QoS资源。（步骤7~14）。接下来，我们更深入的观察这两个阶段，并介绍承载通道的授权和QoS委托许可的最终步骤。

图 3‑13 使用SBLP的承载通道授权

授权 QoS 资源 

上图中第2和第5步骤对应于QoS资源的授权过程。在会话建立过程中，PDF收集IP QoS授权数据，这些数据包括：

· 流标识符——用来标识与这个SIP会话关联的某个媒体成分的IP流。流标识符由两部分组成：（1）表示“m=”行在SDP会话描述符中出现的次序的数字；（2）表示该“m=”行中IP流的序数（以端口增长的次序）。

· 数据率——这部分信息从SDP的带宽参数继承而来。数据率将包含所有IP层以及IP层之上的数据形成的数据负载（例如UDP、RTP或者RTCP）。如果每个媒体部分允许多种编解码，则授权的数据率是根据需要最大带宽的编解码来设置的。

· QoS级别——QoS类别信息表示可用于这个媒体成分的最高级别。它从SDP媒体描述部分继承。

让我们假设Tobias（上图中UE#1）想要和他的妹妹Theresa（UE#2）通话。除了通常的语音通话，Tobias还想要启用双向和单向的视频流。因此，他的终端构造了一个SDP INVITE请求，这个请求包含了反映Tobias的选择和他的UE的能力的SDP。SDP包含了支持的编解码、带宽要求（包括它们每一个的特征）和为每个可能的媒体流分配的本地端口。我们这里只关注那些SBLP必需的参数。第6章包含了这个会话建立的一般描述。从UE#1发出的SDP看起来是下面这个样子：

v=0

o=-3262464865 3262464868 IN IP6 5555::1:2:3:

t=3262377600 3262809600

m=video 50230 RTP/AVP 31

c=IN IP6 5555::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/AVP 97 96

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

b=AS:25.4

b=RS:500

b=RR:500

当图中PDF#1收到这个时，它就能够明确表达上行链路（从UE#1到GGSN#1）的授权数据。当Theresa的UE应答时，PDF#1就能够明确表达下行链路（从GGSN#1到UE#1）的授权数据（注意，本人以为作者这段内容有笔误，将两个SDP描述的上行和下行链路搞反了。）。请注意Theresa并不愿意接收单向视频，因此相关的端口号被设置为0：

v=0

o=- 3262464865 3262464868 IN IP6 5555::1:2:3:4

t=3262377600 3262809600

m=video 60230 RTP/AVP 31

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

b=AS:35

b=RS:700

b=RR:700

m=video 0 RTP/AVP 31

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

b=AS:32

b=RS:640

b=RR:640

a=recvonly

m=audio 3550 RTP/AVP 0

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

b=AS:25.4

b=RS:500

b=RR:500

从这个信息，PDF#1和PDF#2就能够构建必要的流标识符。下表中展示了PDF#1中的流标识符。

“m”行次序

IP流类型

目的地IP地址

IP流的端口号

流标识符

1

RTP (video) UL

（注意，本人认为该作者搞反了上行和下行方向，表中所有的UL和DL应该改成相反的方向。）

5555: : 1:2: 3:4

50230

<1, 1>

1

RTP (video) DL

5555: : 5:6: 7:8

60230

<1, 1>

1

RTCP UL

5555: : 1:2: 3:4

50231

<1, 2>

1

RTCP DL

5555: : 5:6: 7:8

60231

<1, 2>

3

RTP (audio) DL

5555: : 5:6: 7:8

3550

<3, 1>

3

RTP (audio) UL

5555: : 1:2: 3:4

3456

<3, 1>

3

RTCP DL

5555: : 5:6: 7:8

3551

<3, 2>

3

RTCP UL

5555: : 1:2: 3:4

3457

<3, 2>

表格 3‑4 PDF#1中的流标识符信息

数据率 PDF从“b=AS”SDP参数中推导出媒体IP流的数据率。对于可能存在的相关的实时传输控制协议（RTCP）IP流，PDF将使用SDP“b=AS”、“b=RR”和“b=RS”参数。当没有PDF“b=RR”和“b=RS”时，RTCP的IP数据率按照[3GPP TS 29.208]中描述的那样从可用的参数中算出。RTCP带宽的描述：

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

· 如果没有b=RS或者b=RR参数，那么UL和DL的RTCP带宽 = MAX[0.05*bAS, bRS/1000或者bRR/1000]。

· 如果b=RS或者b=RR都不存在，那么UL和DL的RTCP带宽 = 0.05*bAS。

下表展示了在PDF#1中计算出的各个流标识符对应的最大数据率。

 

流标识符

<1，1>

<1，2>

<3，1>

<3，2>

下行链路最大数据率（kbps）

35

0.7

25.4

0.5

上行链路最大数据率（kbps

35

0.7

25.4

0.5

最大QoS级别

A

A

A

A

表格 3‑5 PDF#1中每个流标识符对应的最大数据率和QoS级别

QoS 级别 PDF将媒体类型信息映射成可被用于这种媒体的最高QoS级别。当双向链路都被使用时，PDF会为上行和下行链路使用相等的QoS级别[3GPP TS 29.207]。[3GPP TS 208]包含详细的推导规则（上表中表示了摘要）。下表显示了上表中的信息是如何在我们的例子中使用的。RTCP IP流的最大QoS授权级别和对应的RTP媒体IP流相同。

媒体类型（SDP中的m行）

最大授权QoS级别

双向音频或视频

A

单向音频或视频

B

应用

C

数据

D

控制

E

其它

F

表格 3‑6 每种媒体类型的QoS级别

授权的QoS级别于上图的第2和第5步中（承载通道授权）在PDF中建立和存储。授权的QoS包含QoS级别和数据率。与此同时，PDF创建了被用来在GGSN中建立包标识符的流标识符。表格3-5概括了上面的这些东西。

授权令牌 上图中，第2步说到“把授权令牌发送给UE#1和UE#2”。但是，什么是授权令牌？

· 它是在一个接入点中所有PDP上下文中唯一的标识符。

· 当授权数据建立时，它在PDF中建立。

· 它包含IMS会话标识符和PDF标识符。

· 它的语法格式遵从于[RFC3520]。

· 它通过[RFC3313]定义的办法传递给UE。

· UE在PDP激活/修改请求中需要包含它。

· GGSN使用在授权令牌中的PDF标识符来查找持有授权IP QoS信息的PDF。

· 在收到GGSN的请求后，PDF使用授权令牌来找到正确的授权数据。

媒体分组 SIP和IMS允许建立的多媒体会话包含一些不同类型的媒体成分，例如音频和视频。任何参与方可能在一个进行的会话中加入或者结束一个媒体成分。如在2.1.6节所述，所有的媒体成分针对计费目的应该是可单独被标识的，并且必须能够对会话中的每个媒体成分单独计费。

不幸的是，版本5中的GGSN只能够为一个PDP上下文建立一个GGSN呼叫详细记录（CDR）。因此，不可能在同一个PDP上下文中分离不同媒体成分的通信量。由于当前计费数据生成和关联的模型不允许在同一个PDP上下文中有多个媒体成分，因此IMS层面必须有一种机制迫使UE去为每个不同的媒体成分打开一个PDP上下文。出于这个原因，定义了一个keep-it-separate指示。

当P-CSCF作为被叫侧收到一个会话的初始INVITE请求，或者是收到应答发出会话的INVITE的183（Session Progress）应答，P-CSCF可以根据[RFC3524]修改SDP以向UE指示某些媒体被根据本地策略进行了分组[3GPP TS 24.229]。

[RFC3524]定义了单一预留流（SRF）组类型（a=group:SRF）。SRF组按照下面的方式使用：

· 如果一个网络想要在同一个PDP上下文上传输不同的媒体，则P-CSCF为这些媒体成分设置相同的SRF值。

· 如果一个网络想要在不同的PDP上下文上传输不同的媒体，则P-CSCF为这些媒体成分设置不同的SRF值。

· 如果网络没有设置SRF指示标志，则UE可以随意按照自己的喜好来对媒体流进行分组。

下面进一步的约束和指导方针被提供在标准文档[3GPP TS 23.228]和[3GPP TS 24.229]中：

· P-CSCF会在整个SIP会话中维持使用同一个策略。

· 如果有新的媒体加入并且媒体流的分组在INVITE或者183（Session Progress）应答中被指示，则P-CSCF将会根据[RFC3524]来修改SDP，以指示UE新加的媒体流将会被放在一个新的组或者现有的组中。

· 如果在INVITE或者183（Session Progress）应答中没有指示媒体流的分组，则P-CSCF将不会根据[RFC3524]来为新增加的媒体流修改SDP。

· P-CSCF不会在SDP中指示媒体流的重新分组。

· 所有被UE用来支持单个媒体成分的相关IP流（例如RTP/RTCP）应该在同一个PDP上下文中传输。

· 不同IMS会话的媒体成分不应该在同一个PDP上下文中传输。

版本6正在进行的工作中包含引入按照每个IP流进行计费的机制。这给了在同一个PDP中传输不同媒体成分的更多自由。

跟随我们的例子，P-CSCF#1强制为183（Session Progress）应答中所有的媒体类型分配单独的PDP上下文，如下所示（发往UE#1的183）：

v=0

o=- 3262464865 3262464868 IN IP6 5555::1:2:3:4

t=3262377600 3262809600

a=group:SRF 1

a=group:SRF 2

a=group:SRF 3

m=video 60230 RTP/AVP 31

a=mid: 1

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

b=AS:35

b=RS:700

b=RR:700

m=video 0 RTP/AVP 31

a=mid: 2

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

b=AS:32

b=RS:640

b=RR:640

a=recvonly

m=audio 3550 RTP/AVP 0

a=mid: 3

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

b=AS:25.4

b=RS:500

b=RR:500

复制（ fork ）的问题 当P-CSCF收到一个复制的应答消息时，它将会把2.3.18节中所列的信息传给PDF。当PDF收到复制指示标志时，它同样为复制的应答消息分配和之前相同的令牌。另外，PDF会根据复制的应答消息，为任何新的媒体成分和对之前媒体新增的QoS需求进行授权。如此这样，媒体成分的QoS授权会和所有复制的应答消息中媒体成分的最高QoS要求一致[3GPP TS 29.207]。这个方案可能会改变，这是因为它会在P-CSCF收到复制的应答时增加Gq和Go接口上的通信量，并要求PDF在P-CSCF收到最终应答时进行特殊处理。可能可以期望P-CSCF向PDF隐藏复制的应答。

资源预留 

UE 的功能 当UE在端到端的消息交换中收到了一个授权令牌，它就知道SBLP被应用在了网络。因此，它需要为PDP上下文激活（修改）请求生成要求的QoS参数和流标识符。要求的QoS参数包含下表中列的信息。

通信流级别

下行链路可最大比特率

下行链路可保证的比特率

上行链路可最大比特率

上行链路可保证的比特率

最大SDU大小

SDU格式信息

残留BER

SDU错误比率

通信流处理优先级

错误SDU的传输

分配/保持优先级

传输延迟

传输次序

源统计量描述符

 

表格 3‑7 需要的QoS参数

从SBLP的角度来看，上表中前面三行呈现了感兴趣的值。感兴趣的读者可能能在[3GPP TS 23.107]中找到其它QoS参数的详细描述。这里描述通信流级别、可保证的比特率和最大比特率：

· 通信流级别——UMTS定义的四种不同通信流级别：对话的（conversational）、流的（streaming）、交互的（interactive）和后台的（background）。通过包含通信流级别，UMTS可以对通信流的源进行假设并优化对这种通信类型的传输。

· 可保证的比特率（GBR）——描述UMTS承载服务能够确认给用户或者应用提供的比特率。

· 最大比特率（MBR）——描述用户或者应用可以接受或者提供的上限。这使得允许使用不同的比特率（例如在GBR和MBR之间）。

通信流级别、上行/下行链路GBR和上行/下行链路MBR不能超过每个流标识符的最大授权的通信流级别和带宽。UE中最大授权的带宽是按照和PDF中相同的方式从SDP中获取来的。最大通信流级别是根据下表得来的。这两个参数的确切获取规则在[3GPP TS 29.208]中描述。

媒体类型（SDP中的m行）

UMTS通信流级别

双向音频或视频

对话的（conversational）

单向音频或视频

流的（streaming）

应用程序（Application）

对话的（conversational）

数据（Data）

交互的（interactive）

控制（Control）

交互的（interactive）

其它

后台的（background）

表格 3‑8 UE中每种媒体类型对应的通信流级别

[3GPP TS 26.236]提供了关于对话的（conversational）编解码应用所要求的其它QoS参数如何设置的建议。对应的，[3GPP TS 26.234] 提供了关于流的（streaming）编解码应用所要求的其它QoS参数如何设置的建议。

UE按照和PDF中相同的方式推导出流标识符。下表显示了UE计算出的每个流标识符最大授权的UMTS QoS参数。

 

流标识符

<1，1>

<1，2>

<3，1>

<3，2>

下行链路最大数据率（kbps）

35

0.7

35.4

0.5

上行链路最大数据率（kbps）

35

0.7

35.4

0.5

最大QoS级别

对话的

对话的

对话的

对话的

表格 3‑9 UE#1计算出的每个流标识符最大授权的UMTS QoS参数的值

接下来，UE需要决定需要多少个PDP上下文。这其中关键的因素是媒体流的性质（也就是所需的通信流级别）和从P-CSCF接收到的分组指示标志。在我们的例子中共有两种不同的双向媒体：视频和音频。两种媒体都需要高的QoS（低延迟和保护的时间联系）；因此，一个对话的通信流级别的PDP上下文是合适的。然而，P-CSCF已经指示了每个IMS媒体成分需要单独的PDP上下文，因此UE需要激活两个不同的PDP上下文。否则PDP上下文激活请求会由于PDF增强的SBLP机制而失败。最后，下表给出了UE#1计算出的每个PDP上下文的最大授权的UMTS QoS参数。

 

流标识符

1

2

下行链路最大授权的带宽（kbps）

35.7

25.9

上行链路最大授权的带宽（kbps）

35.7

25.9

最大QoS级别

对话的

对话的

表格 3‑10 UE#1计算出的每个PDP上下文最大授权的UMTS QoS参数的值

UE到现在为止已经完成了图3.13中的第7步。在获取和选择了合适的要求的QoS参数后，UE就激活必要的PDP上下文。授权令牌和流标识符会被插入到通信流模板（traffic flow template）信元内。如何在通信流模板信元内传输授权令牌和流标识符在[3GPP TS 24.008]中详细描述。要求的QoS参数会被插入到QoS信元内。如何在QoS信元内传输QoS参数在[3GPP TS 24.008]中详细描述。

GGSN 的功能 当GGSN收到一个第二个PDP上下文激活请求时，如果Go接口被起用了，则GGSN会：

· 通过从提供的授权令牌中提取出的PDF标识符来标识正确的PDF。如果认证令牌缺失了，那么GGSN可以拒绝这个请求，或者在本地存储的QoS策略加以的限制下接受这个请求。

· 为这个PDP上下文上传输的IP流从PDF请求授权信息。发出的请求是普通开放策略服务（COPS）请求，并且包含了提供的授权令牌和提供的流标识符。请求的具体内容在17章中讲述。

· 在收到授权决定后执行这个决定。授权决定以一个COPS authorization_decision消息的形式给出。这个决定的具体内容在17章中讲述。决定的主要组成部分有：

· 方向指示标志——上行，下行。

· 授权的IP QoS——数据率，最大授权的QoS级别。

· 包分类器（也被称作门描述）——源IP地址和端口，目的地址和端口，协议ID。

· 将授权的IP QoS映射为授权的UTMS QoS。

· 比较请求的QoS参数和授权的UTMS QoS参数。如果所有的参数都是在允许的范围内，则将会接受这个PDP上下文激活请求。换句话说，也就是满足下列的规则[3GPP TS 29.208]：

· 请求的GBR DL/UL（如果请求的通信类级别是对话的或者是流的）或者MBR DL/UL（如果请求的通信类级别是交互的或者是后台的）小于或者等于最大授权的数据率DL/UL。

· 并且请求的通信类级别小于或者等于最大授权的通信流级别。

· 如果请求的QoS超过了授权的QoS，那么请求的UTMS QoS信息将会降级到授权的UTMS QoS信息。

· 基于收到的包分类器创建一个门描述符。门描述符使得能够执行门功能。门功能能够允许或者禁止IP包的转发。如果门被关闭，则相关流的所有数据包都会被丢弃。如果门被打开，则相关流的数据包会被转发。门的打开可以是授权决定事件的一个部分，或者也可以是一个在3.9.1.2节中描述的单独的决定。门的关闭可以是撤销授权决定的一个部分。

· 保存绑定信息。

· 可以缓存PDF决定的策略数据。

· 在第二的PDP上下文修改中，在修改请求不超过之前授权的QoS的情况下，GGSN可以利用先前缓存的信息来做一个本地策略决定。如果GGSN没有缓存的信息，那它就执行上面描述的功能。有一个例外的情况：如果GGSN收到了一个第二的PDP上下文修改请求并且没有收到绑定信息，只要之前有为PDP上下文提供绑定信息，则GGSN拒绝这个修改请求。

·

PDF 的功能 当PDF收到一个COPS请求时，PDF验证：

· 授权令牌是正确的。

· 对应的SIP会话存在。

· 绑定信息包含正确的流标识符。

· 授权修改请求中的授权令牌没有改变。

· UE遵循了分组指示。

· 如果验证成功，则PDF将决定和沟通授权的IP QoS、包分离器和应用在GGSN上的门状态。当正确的绑定信息包含不止一个流标识符时，发送给GGSN的信息将包含这些IP流的合计QoS和适当的包过滤器。

在我们的例子中，UE#1需要激活两个PDP上下文。当第一个PDP上下文（双向的视频）的第二的PDP上下文激活请求到达GGSN#1时，GGSN#1从通信流模板中取出授权令牌和流标识符（1,1和1,2），并将它们发送给PDF#1。PDF#1使用授权令牌来标识对应的IMS会话。PDF#1确认会话存在并返回授权的IP QoS参数和对应于流标识符（1,1和1,2）的包分类器。GGSN#1将授权的IP QoS映射为授权的UTMS QoS；它比较各种值并且意识到所有的事情都OK了。最后，GGSN#1接受这个请求并根据收到的包分类器来设置门。其它相关的PDP上下文也都经历这个过程。

另外，PDF能够在从P-CSCF收到修改的SDP信息时发出一个新的独立的决定。例如在分叉（forking）的情况下，会需要这种操作。

3.9.1.2 QoS委托批准的功能

在资源预留过程中，PDF发送一个包分离器给GGSN。根据这个包分离器，GGSN构建一个门来控制进入和出去的通信流。由PDF来决定什么时候打开这个门。当这个门打开的时候，GGSN允许通信流通过这个GGSN。门的打开可以是作为来自GGSN的初始授权请求的一个应答来发送，或者是作为一个独立的决定来发送。通过独立的决定，运营商能够确保用户层的资源不会在IMS会话被最终接受前被使用（也就是当收到SIP 200 OK消息时。）。

3.9.1.3 QoS委托移除的功能

当PDF不允许通信流穿过GGSN时，通过这个功能关闭GGSN上的门。例如在会话的一个媒体成分由于媒体重新协商而被挂起（on hold）时，这个功能被使用。

3.9.1.4 指示承载通道的丢失/恢复

当在一个更新PDP上下文请求中的MBR值为0 kbit/s时，GGSN需要发送一个COPS报告消息给PDF。类似的，当MBR从0 kbit/s改变时，GGSN将在收到SGSN的更新后发送一个COPS报告消息给PDF。

使用这个机制，当一个流的或者对话的通信流级别在GPRS系统中使用时，IMS能够知道UE丢失/恢复了它的无线承载通道。[3GPP TS 23.060]规定当无线网络控制器（RNC）通知SGSN Iu或者接入承载通道的释放时，SGSN需要发送一个更新PDP上下文请求给GGSN。

当PDF收到一个MBR为0 kbit/s的报告，它能够请求P-CSCF来释放这个会话，并按照3.9.1.6节中的过程来撤销所有相关的媒体授权。

3.9.1.5 撤销功能

这个功能被用来强制释放之前授权的GPRS网络中的承载通道资源。由了这个机制，PDF就能够在例如在一个SIP会话结束时，或者是当绑定到这个PDP上下文的媒体成分被从会话中移时，确保UE释放PDP上下文。如果UE没能在运营商预先定义的时间内完成这个操作，则PDF会撤消这些资源。

3.9.1.6 计费标识符交换功能

Go接口是IMS和GPRS网络间的连接。为了让计费关联按照3.10.2节描述的那样执行，IMS层需要知道相应的GPRS层的计费标识符，反之亦然。这些计费标识符在承载通道授权的过程中被交换。IMS计费标识符在授权决定消息中被传送给GGSN，而GGSN计费标识符则在作为授权报告消息的一部分被传送给PDF。

 

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 
本文内容来自下面的著作，如果读者对本文内容感兴趣，请购买正版原著书籍阅读。 
书名：THE IMS IP Multimedia Concepts and Services in the Mobile Domain 
出版社：John wiley & Sons, Ltd

本译文内容未经作者许可，不得用于商业用途。

转载自 http://blog.csdn.net/foolskindom/article/details/5087373