top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Gx-Interface: What Gate Function does under PCC rule ?

+12 votes
805 views

Why do we require Gate Function ? I mean to say what is the need for this ? How Significant it is in Gx-Interface?

posted Mar 24, 2014 by Hiteshwar Thakur

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

1 Answer

+1 vote

Hi Hiteshwar,

Gate function is described in - ETSI section no. 4.5.2.3 3GPP TS 29.212

Up to my knowledge Gate status decides whether the Service Data Flow (SDF) detected should be allowed to pass or blocked.

The Gate Function represents a user plane function enabling or disabling the forwarding of service flow packets. A gate is described within a PCC rule. If the PCC rule contains Flow-Description AVP(s) applicable for uplink IP flows, it shall describe a gate for the corresponding uplink IP flows. If the PCC rule contains Flow-Description AVP(s) applicable for downlink IP flows, it shall describe a gate for the corresponding downlink IP flows. The Flow Status AVP of the PCC rule shall describe if the possible uplink and possible downlink gate is opened or closed.

The commands to open or close the gate shall lead to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed all packets of the related IP flows shall be dropped. If the gate is opened the packets of the related IP flows are allowed to be forwarded.

answer Mar 24, 2014 by Karan Joglekar
Similar Questions
+1 vote
Is it possible to use Credit-Control-Failure-Handling in Gx interface?

Is it possible to use Credit-Control-Failure-Handling AVP in Gx interface. If so, how?

My query is when PCEF sends a CCRequest to PCRF and PCRF does not reply anything, so in that case will that be possible to use Credit-Control-Failure-Handling(CCFH) avp.

Does this behavior allowed as per 3GPP Standards or its upto the customization of the product. Any reference are highly appreciable.

+2 votes
How QCI_X(where X = 1,2,3,4,5,6,7,8,9,65,66,67,68,69,70) is selected by PCEF for CC-Request in Gx interface

How PCEF decide which QCI_X(where X = 1,2,3,4,5,6,7,8,9,65,66,67,68,69,70) value need to be send to PCRF.
What is the significance of so many QOS-Class-Identifiers?
Even 3GPP 29.212 doesn't define any reason for classification between different QOS-Class-Identifiers.

+3 votes
Gx Rule Activation and Deactivation using Charging-Rule-Base AVP ?

If PCRF sends Charging-Rule-Base AVP for activation/deactivation of all rules inside the given rulebase in CCA , then is it possible that PCEF was able to activate/deactivate some rules in the rulebase and other rules activation/deactivation failed ?

+1 vote
CCR-U loop in Gx interface

1) Assume that susbcriber is having lower specifications handset which can support of 300kbps in 2G radio, when susbcriber creates a session/starts browsing then GGSN will send QOS in CCR-I as 300kbps & PCRF will reply CCA-I as 400kbps (Assume that at PCRF end 400kbps plan is configured), subscriber can browse successfully & no extra messages in network

2) Assume that susbcriber is having lower specifications handset which can support of 300kbps in 2G radio, when susbcriber creates a session/starts browsing then GGSN will send QOS in CCR-I as 300kbps, PCRF will reply CCA-I as 400kbps (Assume that at PCRF end 400kbps plan is configured), subscriber can browse successfully, after sometime GGSN send CCR-U1 messages with event trigger revalidation timer expired & qos as 300kbps, PCRF will again execute policy function & allocate 400kbps in CCA-U1. Now GGSN again sends an CCR-U2 with 300kbps QOS-CHANGE as event trigger & again PCRF send 400kbps in CCA-U2, like this it go on loop.

/IPCANTYPE=3GPP-EPS mode/
Concern is why same qos send in case-1 is no loop messages, where as loop in case-2

+3 votes
Handle error scenarios in the PCRF (over Gx interface)

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)

...