top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Policy counter subscription by the PCRF to OCS

+2 votes
1,899 views

Hi,

I am going through the spec 3gpp 29.219(Sy interface) and trying to understand the call flow and AVPS between the OCS and PCRF.

The PCRF sends the the list of Policy counters to OCS initially and OCS will store it against the Sy session. How does the Counter identifiers be identified uniquely b.w OCS and PCRF ?

Because the spec says, If the OCS determines that any policy counter identifiers are invalid, the OCS shall return a response with the Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE.

But my doubt is, how the Policy counter Ids are known across the OCS and PCRF.

Any help in this area is very helpful

Thanks

posted Dec 4, 2015 by Pdk

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button
Could you please point out to that section of the spec. It will help

Regards,
Peeyush Sharma
Peeyush,
The section  I was referring to is  4.5.1.2 and 4.5.1.3 of 29.219 v b20. These are initial sections, in specs.
Thanks,
Priya

1 Answer

0 votes

Found out a note in the spec saying

A policy counter in the OCS can represent the spending for one or more services, one or more devices, one or more subscribers, etc. The representation is operator dependent. There is no explicit relationship between Charging-Key and policy counter.

To me it looks like it is the operator who has to configure these policy counters details in PCRF and OCS like how Rating-Group and Service-Ids are known across PCRF, OCS and PGW.

Meanwhile, I will try to find out if I can find sometime on provisioning policy counters in PCRF and/or OCS

Regards,
Peeyush Sharma

answer Dec 4, 2015 by Peeyush Sharma
Peeyush,
Thanks a lot for the info. But I am not able to find any messages which configures these Policy counters in the PCRF and OCS. May be I am not looking at correct specs..
Thanks,
Priya
They are not configured through messages. They are provisioned in the OCS and SPR. Like your Rating-Group and Service-Ids are there in PCRF and OCS and based on various conditions and service they are chosen. In similar way they should be configured and used.

Regards,
Peeyush Sharma
Section 4.5.1.3 says "If all the policy counter identifiers are known to the OCS,the OCS shall be able to subsequently notify the PCRF of policy counter state changes.". And Policy counter Identifier is of type UTF8String in section 5.3.1.
My doubt is UTF8String can have any value. So how it is synced b/w OCS and PCRF ?
Lets say PCRF configures the "PolicyCounter1" and how to make sure this value is known to OCS ?
See, both PCRF and OCS should be aware of this information. As per my understanding PCRF and/or OCS will not generate these values on the fly.

If you are aware of static rules, the rules names are configured in PGW and PCRF is aware of the rule names. In similar fashion PCRF and OCS should be aware of the policy counter identifier. They should be provisioned in their databases probably. If PCRF does not send any Policy Counter Identifier then information about all the identifiers known to OCS are shared with PCRF
ok that clarifies a lot ..I was trying to see if there is a standard way to pass this info across PCRF and OCS, and hidden in the corner of spec. I am looking into these specs for the first time, so I might have missed somethings..
Initially in order to negotiate there should be some information that should be configured within the 2 nodes. Otherwise in the first request whatever value that PCRF will send to OCS will be alien to it.
In order to come up with some common counters, they should be initially provisioned with something.

As per my understanding it can be restricted to policy counter per APN or subscriber maybe. Not sure though

Regards,
Peeyush Sharma
Similar Questions
+2 votes

Lets say we have counter 1, for a subscriber1, configured in SPR. Lets say this counter1 indicates that the QOS is throttled from 520kbps to 220kbps, when the usage exceeds the lets say 50MB in one month. This is what i understood..Now my query, is does this apply to only GBR bearers in the Subscriber ? And does it apply to all the dedicated GBR bearers ?
How is it applicable for the non GBR bearers ?

Also the PCEF, needs to send the CCR to OCS, i am not able to see how the PCEF is configured to trigger these reports back to OCS. (Is it by the CCA sent by the PCRF, that triggers this reporting from PCEF to PCRF ?)

+1 vote

Hi all,

We have complexity linked to Gy and Gx interfaces.

Let's say that we have two rules configured as static on PGW with :

Rule1= Reports RatingGroup1
Rule2= Reports RatingGroup2

When PCRF install Rule 1 on Gx, the ratingGroup reported by PGW to OCS is RatingGroup1
When PCRF uninstal Rule1 then install Rule2, the ratingGroup reported by PGW remain RatingGroup1 till a Gy trigger is reached (revalidation time, GSU consumption...).
Then the problem on our system is that when PCRF change the rules on Gx interface the PGW keep reporting the old rating group on Gy interface ie: Gx change do not lead to a Gy change similtanously. I m wondering if there is a standard behaviour for such a use case?

Thanks a lot

+2 votes

PGW sending a USU of 0 in CCR Updates after the first USU in first CCA Update was sent correctly. GSU from PCRF is 10Mb.

+3 votes

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)

+1 vote

Looking at interoperability issues.
The CCRequest message sent from PGW to PCRF during attach. Does the CCA sent back from PCRF to PGW needs to have TFT info?

...