Oracle Communications Diameter Signaling Router (DSR)
 

PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec DSR
 

In this Document

Symptoms

Cause

Solution

References

Created from <SR 3-12979864861>

Applies to:

Symptoms

• P-DRA Does not clears the stale sessions / P-DRA clearing the stale sessions very slowly.
•  If all 10 sessions for a subscriber (IMSI) are stale then Alarm "Event_Number 22719 - Maximum Number of Sessions per Binding Exceeded" will be generated.

Cause

• Stale Session Timer is a Configurable Parameter on P-DRA
  • Default value is configured in NOAM GUI: Main Menu --> Policy and Charging -> Configuration -> General Options
  • Per-APN, stale session timeout is set in Policy and Charging -> Configuration -> Access Point Names
• Each network device that maintains the session state must include a mechanism by which session related resources can be freed in the event that the session is not torn down properly via Diameter Signaling.
• For P-DRA, this mechanism is through Session Audit.
• This is generally accomplished by keeping track of last time a session was "touched" and assigning a time interval beyond which if the session is not touched again, the session is considered as stale.
• If the P-DRA simply removed a binding capable session that it considered to be stale, any keys associated with that session would also be removed.
• Instead of removing a session considered to be stale, P-DRA queries the Policy Client by sending a RAR (Re-Authorization-Request) message, now there are following possible responses from Policy Client and corresponding actions from P-DRA.

1. 1. Policy Client sends RAA (Re-Authorization-Answer) with Error Code 5002 indicating that session is not found on Policy Client.
      • P-DRA will terminate the stale session once this response is received.
   2. Policy Client sends RAA with success (2xxx result code) which means that session still exists on Policy Client.
      • This will cause P-DRA to touch the session and give it another interval of time before it can be considered to be stale again.
   3. Policy Client does not responds to RAR message sent by P-DRA.
      • In this case P-DRA will re-transmit RAR to Policy Client in 2.5 seconds and after trying 12 times P-DRA will terminate the session.

• In the vast majority of cases binding and session database records are successfully removed as a result of signaling to terminate Diameter sessions. There are, however, instances in which it may not be possible to remove a database record that should have been removed. Cases that may result in stale binding or session records include the following:
  • No Diameter session termination message is received when the UE no longer wants the session.
  • IP signaling network issues prevent communication between MP servers that would have resulted in one or more records being deleted.
  • Policy SBR congestion could cause stack events to be discarded that would have resulted in removal of a binding or session record.
  • Software errors could prevent records from being successfully removed.
•  In order to limit the effects of stale binding and session records, the P-DRA continually audits each table to detect and remove stale records.
• As per design Audit runs every 10mins
• As per current design P-DRA can add only maximum 1000 RAR (Query+Release) record to Pending RAR table per audit.
  • RAR Type: Query - RAR sent when Session is determined to be stale
  • RAR Type: Release -  RAR sent when alternate key is not created, when session record is not created, failed to update the binding.
• The rate of RARs initiated by a given session pSBR is bounded to be no faster than one RAR every 20 ms (50 per second) and no slower than one RAR every 500 ms (2 per second)
• Now, in case of network issues (IP media issues), there will huge number of sessions for which session termination message may not be received on P-DRA.
• As explained above P-DRA can add only 1000 RAR records to Pending RAR table per Audit and further it can initiate a maximum of 50 RAR/second.
• This will slow down the processing of stale sessions and it may take several hours to clear the stale sessions.
• Binding Key Query Report can be executed to determine number of stale sessions for a IMSI

Solution

• In case of network events when there are huge number of stale sessions, processing / clearing of stale sessions may seem to be very slow on P-DRA.
• In cases where all 10 sessions for a subscriber (IMSI) are stale then the subscriber will not be able to create new sessions and will not be able to latch on network.
• All these stale sessions will eventually terminate however the termination may be slow.
• In Case the sessions termination is taking too much time causing service impact for certain IMSIs as all 10 sessions for such IMSIs are stale, then contact ORACLE support Team to investigate/fix the issue.

 Here is command with steps:-

1. Search the IMSI from Binding Query Tool from Active NOAMP Server GUI.
2. Please note down the report results in some file to have data with us what we have removed.
3. You will have the Binding Server Name from the Binding Query Report where IMSI is residing. This will be with “SBR(B) Server Name” in the report.
4. Go to that Server using CLI (ssh).
5. And execute the command:-
   • irem ImsiApnAnchorKey where "imsiAnchorKey='ImsiUnderRemoval'"
6. Replace the ImsiUnderRemoval with the IMSI value you want to remove. Please care about '' and "" in the command.

• Further The above method may be efficient if you have only a couple of IMSI for which all 10 sessions are marked stale, as it requires querying and deleting the IMSIs one by one.
• If customer reports several IMSI for which all 10 sessions are marked stale then the above method may not be efficient.
• In that case you prepare a script and follow the procedure as below:

1. Login to the Active NOAM and identify the Active Binding SBR server(s) (NOAM GUI--> Main Menu--> Policy and Charging--> Maintenance--> SBR status

   Note: There are 2 Server groups "Session" and "Binding", make sure the script is executed on only Active Servers in the binding group,

2. Now login to Active Binding Server identified in above step and go to cd /usr/tmp directory and prepare a script as below
3. vi IMSI_Clean.sh

1. Replace the ImsiUnderRemoval with the IMSI value you want to remove. Please care about '' and "" in the command.
2. chmod 755 IMSI_Clean.sh
3. ./IMSI_Clean.sh
4. Wait for script to be executed.
5. Execute the script on All Active servers in Policy Binding Group

• Further P-DRA processing of stale sessions has been enhanced in DSR 7.1 and higher
• Following parameter are made configurable in DSR 7.1 and higher.
  • Maximum Query RAR Rate Per Session Server Group - This value specifies the maximum rate in messages per second at which a given Session SBR Server Group can send RAR messages to Policy Clients for the purpose of auditing to determine if the session still exists.
  • Query RAR Queue Capacity Per Session Server Group - This value specifies the maximum number of RARs that can be queued in a given session SBR Server Group for sending to Policy Clients for the purpose of querying for session existence. If a query RAR cannot be queued because the Pending Query RAR Capacity Per Session Server Group has been reached, the next pass of the session audit will attempt to queue the query RAR again. 

References:

FD007479: Policy DRA Signaling Requirements

FD008385 (cgbu_eg_1068): PCA Suspect Binding Removal Enhancement

References

This solution has no attachment