1. Essentials Guide
  2. The Session Load Balancer and Route Manager
  3. SLRM Operation
  4. Establishing the Load Balance Pool

Establishing the Load Balance Pool

The SLRM creates pools of Oracle Communications Core Session Managers to load balance new registrations and applicable INVITEs. These pools include Oracle Communications Core Session Manager that service the same cores. The SLRM ranks Oracle Communications Core Session Managers to create an ordered list from which it can choose registration targets.

Oracle's Diameter Sc interface includes messaging sequences and AVPs to support the interaction between the SLRM and Oracle Communications Core Session Managers. Key to this interaction is the Oracle Communications Core Session Manager specifying cluster membership and registering to service cores at the SLRM. Load balanced pools for a given core include only the Oracle Communications Core Session Managers registered for that core.

Supporting information over the Sc interface provides the details of the Oracle Communications Core Session Manager's registration. To this end, a client-server relationship exists, with the SLRM function acting roughly as server:

  • Upon startup, each Oracle Communications Core Session Manager advertises its cluster membership, and subsequently the IMS "cores" it services and its resource utilization. This allows the SLRM function to group Oracle Communications Core Session Managers for load balancing.
  • At agreed upon intervals, the Oracle Communications Core Session Manager resends advertisements to confirm or change SLRM-core registration and resource utilization.
  • The Oracle Communications Core Session Manager is also capable of initiating graceful shutdown procedures to remove itself from any load balance pool.

Sc interface registration information that aligns with the functions above include:

  • New Registration — The SLRM includes this Oracle Communications Core Session Manager in the "core" lists and begins to assign users to it.
  • Re-Registration — The SLRM refreshes the list of cores within which this Oracle Communications Core Session Manager participates.
  • De-Registration — The SLRM removes this Oracle Communications Core Session Manager from the core list from which it is de-registering.

After a Oracle Communications Core Session Manager registers with the SLRM, the SLRM tracks its state. The SLRM only includes devices in the proper state when making load balancing calculations. Oracle Communications Core Session Manager states include:

  • In Service — The Oracle Communications Core Session Manager has registered at the SLRM. The SLRM can include this device in its load balancing calculations and send it endpoint registrations.
  • Out of Sync — Capacity information is unreliable. The Sc interface is down or the SLRM registration has timed out. This device would be selected last. The device goes back in-service if the Sc interface recovers or it re-registers with the SLRM. The system uses a back-off timing algorithm to determine when to send connectivity re-attempts, beginning with 70 seconds and proceeding by exponentially increasing the time between connectivity re-attempt until it reaches 1920 seconds (32 minutes).
  • Out of Service — Not available for use by this core. The device is not responding to attempts at re-establishment. The SLRM brings the device back into service using a truncated exponential back-off method that is capped at 32 minutes.
  • Destroyed — The SLRM has removed this device from this core's list because it has explicitly de-registered.