Feature Overview
Subscriber Overcharging Protection enables the SGSN to avoid overcharging the subscriber if/when a loss of radio coverage (LORC) occurs.
When a mobile is streaming or downloading files from external sources (for example, via a background or interactive traffic class) and the mobile goes out of radio coverage, the GGSN is unaware of such loss of connectivity and continues to forward the downlink packets to the SGSN.
Previously, upon loss of radio coverage (LORC), the SGSN did not perform the UPC procedure to set QoS to 0kbps, as it does when the traffic class is either streaming or conversational. Therefore, when the SGSN did a Paging Request, if the mobile did not respond the SGSN would simply drop the packets without notifying the GGSN; the G-CDR would have increased counts but the S-CDR would not, causing overcharges when operators charged the subscribers based on the G-CDR.
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.
The following table summarizes the SGSN's actions when radio coverage is lost or regained and LORC overcharging protection is enabled.
Condition | Triggered by | SGSN Action | LORC Intimation IE - private extension payload |
---|---|---|---|
Loss of radio coverage (LORC) | RNC sends Iu release request with cause code matching configured value |
Send UPCQ to GGSN Start counting unsent packets/bytes Stop forwarding packets in downlink direction |
No payload |
Mobile regains coverage in same SGSN area | MS/SGSN |
Send UPCQ to GGSN Stop counting unsent packets/bytes Stop discarding downlink packets |
New loss-of-radio-coverage state and unsent packet/byte counts |
Mobile regains coverage in different SGSN area | MS/SGSN |
Send SGSN Context Response message to new SGSN Stop counting unsent packets/bytes |
Unsent packet/byte counts |
PDP deactivated during LORC | MS/SGSN |
Send DPCQ to GGSN Stop counting unsent packets/bytes |
Unsent packet/byte counts |
PDP deactivated during LORC | GGSN |
Send DPCR to GGSN Stop counting unsent packets/bytes |
Unsent packet/byte counts |
Triggering Iu Release Procedure
When SGSN receives the RAB Release Request with cause "Radio Connection with UE Lost" from RNC, it triggers the Iu Release Command. RNC then sends the Iu Release Complete message to SGSN.
SGSN proceeds with the following steps when it receives the RAB Release Request with cause "Radio Connection with UE Lost":
-
SGSN verifies if the ranap rabrel-with-radiolost CLI command is enabled.
-
If the ranap rabrel-with-radiolost CLI command is enabled, then SGSN triggers the Iu Release Command towards the RNC to release the Iu connection for that specific UE.