top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

RESOURCES_LIMITATION failure code sent by SAE-GW on Rx?

+1 vote
1,085 views

I would like to understand that under what circumstances the “ RESOURCES_LIMITATION” failure code sent by SAE-GW on Rx?

posted Sep 16, 2015 by Tribhuwan

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

2 Answers

+1 vote

As per my understanding Resource_Limitation failure code is used for PCC rules on Gx interface.

Could you please provide any reference for this failure code on Rx.

Even if it is coming it could be because of the failure due to admission control because of the congestion.

Regards,
Peeyush Sharma

answer Sep 17, 2015 by Peeyush Sharma
Thanks for reply !!

Yes you are correct Resource_Limitation comes under Rule-Failure-Code AVP.
According to 3GPP TS 29.212 RESOURCES_LIMITATION  failure is comes under Rule-Failure-Code AVP (All access types) The Rule-Failure-Code AVP (AVP code 1031) is of type Enumerated. It is sent by the PCEF to the PCRF within a Charging-Rule-Report AVP to identify the reason a PCC Rule is being reported.

The following values are defined:

RESOURCES_LIMITATION (5)
This value is used to indicate that the PCC rule could not be successfully installed (for those provisioned from PCRF) or activated (for those pre-provisioned in PCEF) or enforced (for those already successfully installed) due to a limitation of resources at the PCEF.

AVP Format:
Charging-Rule-Report ::= < AVP Header: 1018 >
*[Charging-Rule-Name]
*[Charging-Rule-Base-Name]
[Bearer-Identifier]
[PCC-Rule-Status]
[Rule-Failure-Code] ------------------------------- RESOURCES_LIMITATION (5)
[Final-Unit-Indication]
*[AVP]

UNKNOWN_RULE_NAME (1)
This value is used to indicate that the pre-provisioned PCC rule could not be successfully activated because the Charging-Rule-Name or Charging-Rule-Base-Name is unknown to the PCEF.

RATING_GROUP_ERROR (2)
This value is used to indicate that the PCC rule could not be successfully installed or enforced because the Rating-Group specified within the Charging-Rule-Definition AVP by the PCRF is unknown or, invalid.

SERVICE_IDENTIFIER_ERROR (3)
This value is used to indicate that the PCC rule could not be successfully installed or enforced because the Service-Identifier specified within the Charging-Rule-Definition AVP by the PCRF is invalid, unknown, or not applicable to the service being charged.

GW/PCEF_MALFUNCTION (4)
3GPP
Release 7 37 3GPP TS 29.212 V7.8.0 (2009-03)
This value is used to indicate that the PCC rule could not be successfully installed (for those provisioned from the PCRF) or activated (for those pre-provisioned in PCEF) or enforced (for those already successfully installed) due to GW/PCEF malfunction.

RESOURCES_LIMITATION (5)
This value is used to indicate that the PCC rule could not be successfully installed (for those provisioned from PCRF) or activated (for those pre-provisioned in PCEF) or enforced (for those already successfully installed) due to a limitation of resources at the PCEF.

MAX_NR_BEARERS_REACHED (6)
This value is used to indicate that the PCC rule could not be successfully installed (for those provisioned from PCRF) or activated  (for those pre-provisioned in PCEF) or enforced (for those already successfully installed) due to the fact that the maximum number of bearers has been reached for the IP-CAN session.

UNKNOWN_BEARER_ID (7)
This value is used only in the case the PCRF is performing bearer binding to indicate that the PCC rule could not be successfully installed or enforced at the PCEF because the Bearer-Id specified within the Charging-RuleInstall AVP by the PCRF is unknown or invalid.

MISSING_BEARER_ID (8)
This value is used only in the case the PCRF is performing bearer binding to indicate that the PCC rule could not be successfully  installed or enforced at the PCEF because the Bearer-Id is not specified within the ChargingRule-Install AVP by the PCRF.

MISSING_FLOW_DESCRIPTION (9)
This value is used to indicate that the PCC rule could not be successfully installed or enforced because the FlowDescription AVP is not specified within the Charging-Rule-Definition AVP by the PCRF during the first install request of the PCC rule

If you have any additional information  please let me know and will update you the traces ASAP
+1 vote

Yes that is what I wanted to say. It is specific to Gx interface and in your question you have mentioned Rx interface

answer Sep 17, 2015 by Peeyush Sharma
Yes you are correct Resource_Limitation comes under Rule-Failure-Code AVP on Gx interface i am just waiting for the actual traces will update you accordingly
Similar Questions
0 votes

Can someone suggest me the below requirements:
1. I want to test S6a interface so what are the best possible testing tools available. Open source are highly preferable
2. I want to test S5/S8 interface so what are the best possible testing tools available. Open source are highly preferable

+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.

+2 votes

Is it possible to block all Data traffic for a specific UE by sending Diameter-Rx AAR command to the PCRF?
If yes, can you indicate AVPs shall be present in the AAR?
May I suppose the following AVP list
- Subscription-Id Containing the targeted MSISDN/IMSI
- Framed-IP-Address or Framed-IPv6-Prefix (containing the IP-address allocated to the UE)
- Media-Component-description containing the following Sub AVP
- Media-Component-number Mandatory sub-AVP
- Flow-Status set to DISABLED

+4 votes

Hello,

I have been able to write a standalone basic PCRF code in our software.

I had also written them using the Gx and RX interfaces (i.e using the diameter protocol). There was no time to test this feature.

Now I find flaws in my design regarding the Diameter while testing.

Initially the SIP (i.e ike IMS) was sending the request to PGW to create the voice bearer. Now my initial implemetation of Rx i thought the TFT was calculated in the SIP and sent across in the RX, but now when revisiting the code, i feel, that there was no such parameter to pass this info to the PCRF from SIP.

Now my doubt is, how this info related to TFT is being passed across to PCRF. Is it through the "Flows".
If so how to get the TFT in the PCRF to send back to PGW...I have missed this part of the design as i was looking more into the QOS..

Any help is greatly appreciated.

thanks
pdk

+3 votes

CCA being rejected by PGW

Above wireshark shows the CCA being sent by PCRF for the "Initial Request". Somehow the thirdparty PGW is not liking the supported feature AVP .
As of now I put the supported feature and subAVPs in 3gpp Dictionary. So you can see the vnd=TGPP. If they are put in base dictionary this phrase { vnd=TGPP} is not seen in front of AVP.

Can somebody help why this is issue ? Or do you have any reference pcaps?

...