Sc Interface Messaging

The SLRM function uses the Sc interface to determine when and how to load balance Oracle Communications Core Session Managers. For the purposes of Diameter exchange, the Oracle Communications Core Session Manager acts as client and the SLRM function acts as agent (server). This messaging includes standard Diameter exchanges, complemented with proprietary exchanges to handle all aspects of load balancing.

A typical message flow between SLRM and Oracle Communications Core Session Manager is shown below.

This image depicts the messages exchanged between the SLRM and the OCCSM over the SC interface.

Sc interface messaging procedures, from the perspective of the SLRM function, includes these steps.

  1. The SLRM listens on a TCP socket for connection requests from peer Oracle Communications Core Session Managers.
  2. After establishing a new Diameter connection, the SLRM waits for a CER from the peer CSM. The SLRM closes the connection if it does not get a CER after a timeout.
  3. The SLRM exchanges the peer identity, supported vendor-ids and application-ids with the peer Oracle Communications Core Session Manager within the CER/CEA exchange. A successful CER/CEA handshake creates a new peer relationship. If there is any error in the initial handshake, the SLRM sends an appropriate error response in the CEA and closes the connection.
  4. The SLRM sends periodic DWR requests on idle connections, to check the availability of peer Oracle Communications Core Session Managers. The SLRM also responds to DWR's from peer Oracle Communications Core Session Manager's
  5. The SLRM responds to SVR requests sent by Oracle Communications Core Session Managers to advertise themselves to the SLRM.
  6. The SLRM responds to CRR requests as follows.
    • On a new registration, the SLRM starts managing the cores for the Oracle Communications Core Session Manager.
    • On re-registration, the SLRM refreshes and updates the information of the cores for the Oracle Communications Core Session Manager.
    • On de-registration, the SLRM removes the core and stops managing the core for the Oracle Communications Core Session Manager.

SLRM rejects bad message requests with error responses.

Sc interface messaging procedures, from the perspective of the Oracle Communications Core Session Manager, includes these steps.

  1. The Oracle Communications Core Session Manager establishes a diameter session with peer SLRM. The initial handshake includes Diameter connection is setup and the capabilities exchange negotiation (CER/CEA).
  2. The Oracle Communications Core Session Manager sends periodic DWR requests on idle connections, to check the availability of the peer SLRM. The Oracle Communications Core Session Manager also responds to DWR's from peer SLRMs.
  3. The Oracle Communications Core Session Manager advertises itself and sends periodic refreshes to update current Capacity using SVR/SVA requests.
  4. The Oracle Communications Core Session Manager periodically registers with the IMS cores that it is serving using CRR/CRA requests.
  5. During shutdown, the Oracle Communications Core Session Manager de-registers with the SLRM using a SVR/SVA (TERM) transaction.