Handle error scenarios in the PCRF (over Gx interface)

Question

I am trying to handle all the error scenarios seen while testing the Gx with the third party. As of now I had coded for just the successful scenarios.

I am looking for some of inputs on these error scenarios and how to proceed and exit gracefully (rather than crashing the code)

• Dynamic rule config with wrong parameters., PGW sends CCR with the CCR type=TERMINATION_REQUEST. How can PCRF respond (just log error and comeout ?)

• Static rule config with the "wrong rule name". When the PCRF sends CCA-I with the wrong rule name, PGW sends CCR-U with the Charging Rule Report with the "Rule-Failure-Code" as "Unknown Rule Name". In this case remove those rules and continue OR just comeout with just logging error)

Answer 1

Just a small correction
Dynamic rule config with wrong parameters., PGW sends CCR with the CCR type=TERMINATION_REQUEST. How can PCRF respond (just log error and comeout ?)

In this case the CCR-Type=UPDATE_REQUEST(2) should go.

Also, it depends on how policies are configured on PCRF side. Maybe PCRF can send CCA and then PGW will continue with session creation or CCA can be sent with a new rule name.(Need to check spec once)

Regards,
Peeyush Sharma

Comments

Thanks a lot Peeyush , yes that looks correct approach, but how can PCRF know which parameters are having issues..
The CCR U is not very clear in responding with the error causes. (to pinpoint which is causing this issue). So this may keep happening , as PCRF may keep sending wrong value and PGW keeps rejecting..(This may trigger some timer expiry at PGW and SGW for the attach). Not sure whether this is right to wait till timer expiry..Or try some reasonable times and exit ...

Answer 2

On PCRF user can create a policy that if CCR-U comes with Rule-Failure-Code then some action should be taken. Else anyways PCRF has to handle the CCR message received and you can put some condition
E.g. If CCR-U has some rule-failure-code or not., if yes then what action should be taken. I guess that would be a costly affair though.

Regards,
Peeyush Sharma

Comments

Thanks, yes..But as of in my basic design, not much error handling..
In pcrf I create a map of records (like for this IMSI, these are apns, and these are rules and tfts in that apn). So I update the map on CCR, RAR etc .
So as of now I can handle this case as part of CCR message handling..But may be as you suggested there are better ways of handling this

Answer 3

Why are you storing info for a subscriber in PCRF(like APN, quota etc and rules)

You can use SPR for half of the things and then design a policy rule engine where a operator/customer can define policy by itself.

Let's say I want a IMS APN and I want to block the http traffic over default bearer then maybe operator can define a static rule where if Bearer-Usage is IMS_SGINALLING send static rule in CCA

Make it more flexible from the beginning is what I would suggest. It would be a tough task though. There are a lot of parameters which you need to provide in policy design.

All the best

Regards,
Peeyush Sharm

Comments

Thanks ..I thought SPR (Or in our case HLR) has info regarding the user subscription. (like user allowed Apns, bit rates etc). Could we add info like currently active apns , rules and their parameters (like TFT) in the SPR ? I thought it is stored in PCRF..May be my initial assumptions are wrong :(...Quite difficult to change design now..But I will try ..

---

No no, in-call related stuff should not be copied to SPR. Just the subscription info should be in SPR. In-call attributes should remain with PCRF only.

Regards,
Peeyush Sharma