top button
Flag Notify
Site Registration

Why Gxc interface (PCRF-SGW) is needed when we have Gx interface(PCRF-PGW)?

+3 votes
Why Gxc interface (PCRF-SGW) is needed when we have Gx interface(PCRF-PGW)?
posted Jan 13, 2015 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+2 votes

I'm not quite sure but I'll tell you about my experience. A lot of operator uses SAE-GW instead S-GW and P-GW separated. This architecture can avoid to use Gxc interface using only Gx. However, if you have to use S-GW separated for geographical purposes or if you use P-GW separated by applications, you use Gxc for QoS treatment. The Gxc interface is only applicable in the S5 PMIP variant and, in this case, S-GW acts as BBERF.

I extracted this paragraph from

The PCC rule needs to be mapped to a particular IP-CAN bearer to ensure the packets receive the appropriate QoS treatment. The association between PCC rule and a bearer is referred to as bearer binding. The bearer binding is done by the Bearer Binding Function (BBF). The BBF is located either in the PCEF (if GTP is used as the protocol on S5/S8 interface aka. on-path model) or the BBERF (if Mobile IP is used as the protocol on S5/S8 interface aka. off-path model).
When the PCRF sends new or modified PCC rules to the PCEF or BBERF (depending upon the location of BBF), the BBF evaluates whether it is possible to use one of the existing IP-CAN bearers and initiate IP-CAN Bearer Modification procedure or initiate a new IP-CAN Bearer Establishment procedure. The binding is created between the Service Data Flow(s) and the IP-CAN bearer which has the same QoS Class Identifier (QCI - applies to user plane) and Allocation and Retention Priority (ARP - applies to control plane).

answer Jun 17, 2015 by anonymous
It was my answer :)
Thanks for answering and helping people :)
Similar Questions
+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)

+3 votes

Looking for the information related to PCRF.

Another specific question. When the PCRF decides on a QOS and sends across to P-GW. P-GW might not have got any info related to Dedicated bearer to be established earlier. So how does it map this newly sent QOS for the new dedicated bearer to the one it requested by P-CSCF.

I am trying to understand, how to map the QOS info sent by PCRF to the "dedicated bearer request by the P-CSCF. Can PCRF on sending the QOS, also create the new dedicated bearer id, which is sent back to P-CSCF ?

Any info regarding with is very helpful.

+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