实时计费联调问题------OCS的FUA为terminate，GGSN没有执行

SGSN

最近在做实时计费联调（移动），遇到个问题一直没解决，还行各位大神指教。
GGSN是E的，OCS是HW的。

测试场景：用户使用过程中发现余额不足，

问题现象：当OCS下发CCA（抓包第15行）中指示最后一个分片，FUA为terminate时，GGSN没有按照terminate执行，而是再次发起CCR-U消息（抓包第20行），OCS响应CCA中errorcode为4012才对终止会话的

应有的现象：当OCS下发CCA中指示最后一个分片，FUA为terminate时，用户用完最后分片GGSN即执行terminate。

在E的CPI中也没找到具体的配置方法，不知道大家有没有遇到在这种场景，如何配的？

谢谢!

hycl5410

FUA的那个包里仍然给了quota，GSU=CC-Total-Octets: 536576. GGSN会把这些quota用完了再发final（也就是抓包的第20个）。

这个测试里提及的"terminate"也值得商榷：到底是credit session（其实就是PDP）的terminate还是credit instance（rg）的terminate？
从OCS发过来的CCA可以看到，FUA是在MSCC level下的，那么对于GGSN来说就是credit instance的terminate，这个terminate执行的结果就是GGSN在收到FUA之后，
1.先把GSU用掉，
2.用掉之后告诉OCS（final），
3.一定时间内，属于这个rg下的所有流量都不准通过
4. 过了一段时间后，再向OCS要quota

因为这里有两个credit instance，01和09.由于不知道分别对应什么样的service，所以不便妄加揣测（余额不足到底是什么场景）。
如果测试要求01没有quota之后，要把pdp也干掉，貌似已经抓包的这个结果就可以实现了
或者OCS在diameter层面的result code做文章，才可以实现这样的需求。

SGSN

非常感谢你的解答。
从OCS在第15个包下发了FUI，按理来说最后分片用完GGSN可以直接上报CCR-T，这样就省去第20、22个包了，总感觉这俩包是多余的~~

hycl5410

SGSN 发表于 2013-9-10 09:21
非常感谢你的解答。
从OCS在第15个包下发了FUI，按理来说最后分片用完GGSN可以直接上报CCR-T，这样就省去第 ...

我们还是回到最初的问题，我们有两个RG，其中一个（01）没有钱了，那么为何要把整个session/pdp给terminate呢？这样的设计方案是否是合理的呢？
当然，前提是我不知道01和09分别对应什么业务。
如果09对应那种永远不计费的业务，建议不要拿到gy来做。这样如果一个session里只有一个instance，当这个instance被terminate的时候，session应该也会相应的terminate了。

SGSN

09是标识异常流量的，我觉得应该就是不计费的（包含TCP建立的包）。
01是缺省流量
我发现CCR-I带的RG是09  CCR-T也是09，看了一下GGSN的配置发现调用的service-set配置如下：
            service-set all-ss {
                service-identification {
                    service-data-flow-id {
                        default {
                            payload 2000000001;
                            tcp-setup-signaling 2000000009;
                        }
                    }

这里的每次建立DCC会话和拆除DCC会话是不是与建立TCP链接和拆除TCP链接有关系，所以才出现CCR-I和CCR-T带的RG都是09的现象
多RG的场景真的很烦~~

hycl5410

如果是多rg场景，这个测试用例设计的本身就有问题。即使用户默认流量没有钱了，运营商也不应该去激活他的PDP啊，应该还有其他不计费的业务可以使用（除09外的，比如彩信等）。
如果确定一共只有两个rg--01和09，且09不计费，那么倒有办法让09不去要quota。

CCR-I带09跟建链有关系，TCP建链肯定是第一个数据包，出现流量就触发了CCR-I（估计是配置了那种有流量才发CCR-I的情况）；
CCR-T带09跟拆链没关系，根据GGSN默认配置，OCS回4012会导致DCC session terminate，由于RG01之前已经做过final了，那么CCR-T里就只有RG09的final了。