51学通信技术论坛

标题: 当UE丢失无线侧覆盖的防止对用户多计费的防护功能：Overcharging Protection on Loss [打印本页]

作者: admin 时间: 2013-4-12 20:47:25 标题: 当UE丢失无线侧覆盖的防止对用户多计费的防护功能：Overcharging Protection on Loss

思科ASR 5000系列STAROS 12.2以上有一个特性，叫做Overcharging Protection on Loss of Coverage 。作用是在UE在传递大数据（例如下载或视频业务）的过程中，如果无线环境出现了问题（例如没有无线信号了，进入了地铁等），防止对用户多计费。从而减少用户投诉，也是对用户的一种保护。

从技术角度来看，主要是描述以下一种场景：

1 UE已经完成了PDP激活，并且正在下载一个大文件或者正在看一个视频。这时无线信号突然没有了。

2 如果这个下载或视频业务在PDP激活过程中是被当做一个background或interactive类的业务来完成Qos协商的，那么SGSN此时是不会向GGSN发送update pdp context request消息将Qos设置为0kbps的（SGSN只针对streaming或conversational类型的业务才会给GGSN发送更新消息）。

3 那这样的话，GGSN侧因为没有移动性管理功能，并不知道UE已经不可达了，仍然会继续将下行数据转发给SGSN。

4 SGSN将对UE进行寻呼，但得不到UE的响应。SGSN将把这些下行数据报文进行丢弃。

5 在这种情况下，G-CDR的流量统计将不断增加，但S-CDR却不会。

最终，可能会导致对用户多收费。（因为收费的依据就是G-CDR）。

使用这个特性就能解决这个问题，这是一个思科专属的解决方案，是通过在GTP消息里增加一个私有的信息元素（名字叫LORC：loss of radio coverage ）来实现的。不需要修改RANAP消息。

解决方法如下（原文）：

“Now operators can accommodate this situation, they can configure the SGSN to set QoS to 0kbps, or to a negotiated value, upon detecting the loss of radio coverage. The overcharging protection feature relies upon the SGSN adding a proprietary private extension to GTP LORC Intimation IE to messages. This LORC Intimation IE is included in UPCQ,
DPCQ, DPCR, and SGSN Context Response GTP messages. One of the functions of these messages is to notify the GGSN to prevent overcharging.

The GGSN becomes aware of the LORC status by recognizing the message from the SGSN and discards the downlink packets if LORC status indicates loss of radio coverage or stops discarding downlink packets if LORC status indicates gain of radio coverage for the UE. ”

也就是说使用了该特性后，SGSN将在检测到UE丢失无线覆盖的情况下，给GGSN发送update pdp context request消息将Qos设置为0kbps，并且通过GTP消息中的LORC信息元素通知GGSN，UE已经丢失了无线覆盖，这样GGSN将不再增加G-CDR的流量统计，并且停止将下行数据传给SGSN。

下表描述了不同条件下该特性的行为，主要是第一个当丢失无线覆盖情况下的触发以及网络侧的动作。

[attach]2630[/attach]

作者: vicai 时间: 2013-4-18 16:07:25

hi，admin，你好，我想问下为什么background或interactive类的QoS不会导致SGSN发update咧？

作者: admin 时间: 2013-4-18 21:18:43

vicai 发表于 2013-4-18 16:07
hi，admin，你好，我想问下为什么background或interactive类的QoS不会导致SGSN发update咧？

哦，这个是协议规定的哦。如下：“

After Iu Release in Iu mode, or after termination of the downlink data transfer in A/Gb mode, the PDP contexts for architecture variants using Gn/Gp based interaction with GGSN are handled as follows:

- In the SGSN, for a PDP context using background or interactive traffic class, the PDP context is preserved with no modifications.
- In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink). The SGSN sends an Update PDP Context Request (TEID, QoS Negotiated) message to the GGSN to set the maximum bit rate to 0 kbit/s in the GGSN. The value of 0 kbit/s for the maximum bit rate indicates to the GGSN to stop sending packets to the SGSN for this PDP context. ”

作者: hycl5410 时间: 2013-4-24 04:39:39

本帖最后由 hycl5410 于 2013-4-24 05:20 编辑

个人觉得没有啥太大意思，有点得不偿失。欢迎拍砖。

如果是确认连接的传输方式，比如TCP，下行数据得不到ack之后，应该比较短时间内就会中断连接，重传包应该不会太多。
如果是非确认连接的传输方式，比如UDP，虽然传输层上不会检测数据包是否丢失，但是上层一样会检测，除非拿iperf强行灌包，才会出现非常大的计费偏差。

当然，如果终端用户长期处于无线恶化环境的话，累积起来偏差也会非常大。

这种方式看起来可以提高计费精确度，但是其实是以牺牲信令性能为代价的，因为SGSN和GGSN都要处理额外的信令单元，尤其是GGSN。特别是当无线环境比较复杂，比如类似时断时续的场景，那么就可能造成不断的update pdp来通告loss或者恢复。

从核心网的角度，很难对覆盖范围内无线情况作出有效评估，那么也就比较难以估计网络内由该类型原因导致的update pdp到底会占信令总量的多少。当然，也许网元可以定制特殊的统计来监控这一情况，但是突发的无线情况恶化仍然难以避免。

我个人钦佩在技术上精益求精的态度，但是如果一种技术带来的好处与负面影响难以评估的话，比较倾向保守一些的态度。SCDR和GCDR流量不匹配的事也不是这两年才提出来的，老早就有。但是迄今为止只有思科一家提出了这么个方案，而众所周知，思科G网在无线方面几乎毫无建树。如果从信令层面就可以解决问题的话，相信其他厂商不至于那么”笨“吧？
所以希望一切不要只是”看起来那么美好“

当然我更希望思科是经过成熟论证和充分验证之后提出的方案，比如开了这个feature之后，多处现网监控结果显示偏差下降70%；或者说他们的平台真的niub到如此程度--”区区“信令增长带来的额外开销不在话下。那实在是一件令人振奋的事情。

如果思科可以拿出多运营商开feature前后大量统计数据对比，比如，流量偏差降低70%（剔除各种roaming, DT以及inter-SGSN等等干扰因素），信令增长不超过20%，性能影响不超过10%。相信3GPP工作组没有任何理由拒绝写一个新的CR.

作者: hycl5410 时间: 2013-4-24 06:11:36

本帖最后由 hycl5410 于 2013-4-24 13:18 编辑

啊哈！还真让我想到了一个。R7以后，DT和SAEGW合设的大量launch，会让你连看到这种差别的机会都很渺茫。。。R7以下还是有搞头的。

还是3GPP高明。。。

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)