You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Sonus supports a new N:1 mechanism for the SBC SWe Cloud where one standby instance acts as a back up for N active SBC instances. On a fail-over scenario, the standby instance takes over and becomes active and the failed active instance becomes standby, once it is up and running.

Note

 The maximum value for N is one for Signaling SBC (S-SBC) and four for Media SBC (M-SBC).

 

SBC Redundancy Group

The SBC Redundancy Group (RG) consists of one or more SBC SWe Cloud instances. All the instances in a RG must have homogeneous resource allocation, configuration and personality. Each SBC SWe Cloud instance including standby maintains its own configuration DB, logs, events, and alarms.

A Cluster is a group of one or more SBC RGs. All RGs in a cluster must use the same SBC type (Signaling SBC or Media SBC), which dictates the cluster type such as Signaling cluster or Media cluster.

The following diagrams depict the N:1 architecture with a single SBC Redundancy group (RG) and multiple redundancy groups within an SBC cluster.

N:1 Architecture

Cluster with different Redundancy Groups

Launching N:1 SBC Instances

The N:1 SBC is instantiated using the following methods:

The N:1 architecture is grouped into three different areas:

  • The SBC SWe Instances, which implements the N:1 redundancy for service availability and stable call and registration.
  • The VNF lifecycle management, which defines the SBC redundancy groups, directs both the initial instantiation and subsequent healing after fault management.
    The SBC redundancy group is initiated by the VNF lifecycle orchestrator. The VNFM, either through VNFD template or through SBC heat templates, implements a Redundancy Group (RG) with up-to four active SBC instances and a single standby instance. The VNFM dynamically assigns each RG a unique Redundancy Group ID (RGID). You can create multiple Redundancy Groups that forms the SBC cluster.
  • The EMS, which manages the SBC SWe Cloud instances.
    All the SBC SWe instances are registered with the EMS and download the configuration from the EMS. The EMS adds the SBC SWe instances to the registered list and to the active SBC SWe database. Once the SBC application is up and running, the EMS connects to the SBC application and starts monitoring and collects the statistics.

  • No labels