Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Race Conditions and Error Scenarios

 

This section describes the race conditions and error scenarios that might occur on Service Control Gateway.

  • Race conditions when CCR-U and RAR commands cross each other—The race condition handling at Service Control Gateway when CCR-U from Service Control Gateway and RAR from PCRF cross is simple. Service Control Gateway waits for the first operation to complete and only then the next operation is processed.

  • Duplicate RADIUS request detection—Duplicate request detection and handling functionality on RADIUS interface handles the duplicate requests and replays the responses already sent by the Service Control Gateway. This is needed for the cases when the response sent by Service Control Gateway gets lost and the remote node retransmits the request.

There are two possible cases . When the incoming RADIUS request is recognized as duplicate (same {port, id}) combination within certain time window) and if response has already been sent out then the same response is sent without processing of the request. If a response has not been sent out (previous request is still being processed) then the received duplicate request is dropped. The response is sent when the processing of previous request completes.

Receipt of an Accounting-Request Start Message for an Existing Session

When Accounting-Request Start is received at Service Control Gateway, the context is looked up by (VRF, Framed-IP-Address) combination. If the context is already present, then the following events occur:

  • If both identity and Called-Station-Id are the same (in the received request and the context) then it is assumed that this request is for the same session. The context is updated with received Acct-Session-Id (subject to optimization) and the response is generated.

  • If either identity or Called-Station-Id is different then it is assumed that this request is for a new session creation and Service Control Gateway has missed the termination of the existing session. The existing session is deleted and the new session is created.

Handling of Interim Accounting-Requests When a Session is Not Present

The interim Accounting-Request is considered a session creation trigger if the session is not already present. This condition might happen when the session gets erroneously deleted from Service Control Gateway or when Service Control Gateway misses the Accounting-Request Start (and GGSN/subscriber edge network element does not consider missing response as critical failure). It might also happen due to out of order receipt of Accounting-Request Start and interim Accounting-Request (when the interim accounting requests gets generated back-to-back due to signaling trigger on the remote node). The interim Accounting-Request results into session establishment on Service Control Gateway with the same handling on Service Control Gateway as the Accounting-Request Start message.

Handling of Accounting-Request Stop Without the 3GPP-Session-Stop-Indicator

Service Control Gateway interworks with the GGSN/PGW that does not sent the 3GPP-Session-Stop-Indicator in Accounting-Request Stop message when the primary PDP context or default bearer (session) is getting deleted. So when the Accounting-Request Stop is received by Service Control Gateway, it checks the Acct-Session-id received. If the Acct-Session-Id matches one of those in the context; the Acct-Session-Id in the context is marked as deleted and the Accounting-Response Stop is sent. If all the Acct-Session-Ids in the context on Service Control Gateway are marked as deleted”, Service Control Gateway starts the session detach.