基于非事件的Diameter在线计费控制信令流程

admin

(事件型主要是指那种按次收费的应用，比如原来的彩铃下载，歌曲下载等。）

如图1所示，基于非事件的Diameter在线计费控制流程描述如下：

1 用户发送激活请求。在GGSN上可以配置在回激活应答消息之前是否发送CCR-I消息到OCS进行交互；本例配置是激活应答消息之前不交互。

2 GGSN给用户回激活请求响应，Cause值是Request Accepted，建立会话。

3 用户申请对业务1（内容计费业务）的访问，发起业务请求。

4 GGSN向OCS发送信用初始化CCR-I消息，申请访问业务1（内容计费业务）的Rating-Group 1配额。

5 OCS回复CCA-I应答消息；CCA-I消息回复成功，OCS下发使用业务1的配额信息：下发的配额总流量，有效时间，配额门限值。GGSN收到CCA后，允许用户访问业务，并实时对用户使用配额的情况进行监控。如果回复失败返回码，按照返回码动作执行。如果CCA-I Tx超时，根据本地配置的ccfh执行failover流程。

6 用户开始访问业务1，包括上下行数据传输。

7 用户同时想访问业务2，发起访问业务2的请求。

8 GGSN收到用户访问业务2的请求后，向OCS发送更新信用控制请求CCR-U消息，申请访问业务2的RG 2配额。

9 OCS成功回CCA-U应答消息，下发访问业务2的配额信息：总时长，有效时间，配额门限值。GGSN收到CCA后，允许用户访问业务2，并实时监控用户对业务2配额的使用情况。用户开始访问业务2。

10 业务2的上下行数据传输。

11 业务1的配额耗尽达到门限值，GGSN向OCS发送CCR-U消息请求，再次申请业务1的配额。

12 OCS给GGSN回成功应答消息CCA-U，并再次下发重新申请的真实配额信息。GGSN收到响应后，允许用户继续访问业务1，并继续监控业务1的配额使用情况。

13 这时，业务2的配额快要用尽，GGSN向OCS发送CCR-U消息请求，再次申请业务2的配额。

14 OCS给GGSN回CCA-U消息，表示用户帐户余额不足，需暂停对业务2的访问，并重定向到业务2的充值页面提醒充值。GGSN阻塞用户使用业务2。

15 用户进行帐户充值操作。

16 为了提高用户体验，OCS主动向GGSN发起信用重授权消息RAR。

17 GGSN向OCS发送成功响应消息RAA。

18 GGSN向OCS发送更新信用控制请求消息CCR(update)初始化信用重授权请求，请求重新分配配额。

19 OCS回响应CCA(update)，携带重新下发的配额信息。GGSN并重新监控配额的使用情况。用户继续业务2的体验。

20 一段时间后，用户发起删除会话请求，终止对业务1、业务2的访问。

21 GGSN向OCS发送信用控制结束请求消息CCR-T，上报用户使用所有业务的配额情况。GGSN终止用户对所有业务的访问。

22 OCS向GGSN返回成功的信用控制应答CCA-T，并扣除业务相关的费用。

23 GGSN向用户回删除会话响应。

zzz

多谢楼主分享

will

多谢楼主分享流程
目前碰到E方面关于OCS异常时计费问题，是否有该方面的相关信息分享？比如对于GGSN请求消息发送成功，但等待OCS响应时间超时，不能确定BOSS是否已扣费的流量，该如何记录？