Introduction

1.1 References

Refer to the following documents for more information:

Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide

1.2 Background

Service disruption due to network storm, system overload, database latency, and other events can impact signaling between Policy and BSF. This service disruption can affect session binding between Policy and BSF. In such a case, some sessions can be lost and some sessions can fail to get the binding from BSF. Failure to route Rx request through BSF impacts IP Multimedia Subsystem (IMS) flows. Situation cannot be rectified unless those subscribers reestablish their sessions.

Currently, when binding is lost and Policy sessions are in a hung state, there is no way of knowing which sessions lost or never received the binding. As a result, no action can be taken to solve this issue.

As a solution to this problem, the Binding Detection Tool is developed. The Binding Detection Tool can be run manually to query the sessions in both Policy and BSF that were created in a specific time frame. The query results can be used to identify the stale sessions that impact the Policy sessions when binding is lost.

1.3 Overview

To mitigate the impact on session binding during service disruption, Binding Detection Tool can be manually run to query the sessions in Policy and the corresponding sessions in BSF.

The query result can be used to identify the difference in sessions. This helps to identify sessions which are missing in either Policy or in BSF.

Binding Detection Tool allows to query sessions that were created in a specific time frame. These records can be processed to obtain the sessions that became stale when binding is lost.

Note:

The Binding Detection Tool must be run manually.
The tool performs an offline query on the cnDBTier database created from a backup of the online database of Policy and BSF.
Both Policy and BSF database backups can be restored in same cnDBTier.
The tool can be used to query only the stale records that are within a specified time range.
The tool does not support data compression in context_binding table.

The query can be run on the following tables:

PCF session binding (in BSF)
SmPolicyAssociation (in SM service)
Context Binding (in Binding service)
PendingOperation (in SM service)

Time range can be passed as an argument while running the Binding Detection Tool to query the sessions.

The query result can indicate the following scenarios:

Scenario 1: The record exists in Policy but does not exist in BSF.
Scenario 2: The record exists in Policy but has no binding record. This means that a PDU session in SM service (SMPolicyAssociation) does not have a matching record in contextBinding database in Binding service.
Scenario 3: The record exists in BSF but does not exist in Policy.
Scenario 4: The record exists in BSF but has no binding record. This means that a PCF Session Binding does not have a matching record in contextBinding database in Binding service.

The following tables summarizes presence of the records in Policy and BSF databases in the above mentioned scenarios:

Table 1-1 Scenarios covered from Policy

Scenario	If record present in SM service (PDU session)	If record present in Binding service (Context binding)	If record present in BSF (PCF Session binding)
Scenario 1	Present	Present	Missing
Scenario 2	Present	Missing	Not checked

Note:

If the script does not find the matching context binding for a PDU session, then the script considers it as a missing binding.

Table 1-2 Scenarios covered from BSF

Scenario	If record present in BSF (PCF Session Binding)	If record present in Binding service (Context Binding)	If record present in SM service (PDU session)
Scenario 3	Present	Present	Missing
Scenario 4	Present	Missing	Not checked

Note:

If the script does not find the matching context binding for a BSF session binding, then the script considers it as a missing binding.