SBC Software Edition - SBC SWe

The Ribbon SBC Software Edition (SWe) is the virtualized version of the Ribbon Session Border Controller (SBC). As a software-based application, the SBC SWe decouples SBC features and functionality from proprietary hardware and greatly expands the options for where and how the SBC is deployed. This article provides an overview of some key characteristics that contribute to the wide range of SBC SWe deployment models. 

Deployment Environments

In contrast to installation on dedicated SBC hardware, the SBC SWe software runs as a virtual machine (VM) or as a virtual network function (VNF) in a variety of virtualized environments. The software-based nature of SBC SWe enables great flexibility in network design. Operators select the environment and determine the number and size of SBC SWe instances, or nodes, they need to meet their requirements. Working with virtual instances, an operator can readily adapt the deployment capacities by creating or tearing down SBC SWe nodes as their requirements change. You can deploy the SBC SWe in the following environments:

• On a dedicated server: Deploy the SBC SWe as a VM on commercial off-the-shelf (COTS) hardware equipped with a hypervisor, such as a VMware vSphere ESXi or KVM environment.
• In a private cloud: Deploy the SBC SWe as a VNF in an enterprise’s private cloud infrastructure, such as an OpenStack cloud environment.
• In a public cloud: Deploy the SBC SWe as a VNF in a public cloud environment such as Amazon Web Services (AWS), Google Cloud Platform (GCP) and Azure.  

Redundancy Models

Hardware-based SBCs provide redundancy when deployed in a 1:1 high-availability (HA) configuration. The SBC SWe supports the 1:1 HA model, but also supports an N:1 HA model in which N (up to 4) active nodes are backed up by a single standby node. The characteristics of these redundancy models are summarized below:

• 1:1 HA – A single active SBC node is backed up by a single standby node. The active SBC node holds the active configuration for the pair and replicates configuration changes to the standby node so the nodes stay in sync. If RAMP is included in the deployment it provides a repository to store the configuration history for the pair.
• N:1 HA – In an N:1 deployment, multiple nodes (up to 4) are active at the same time and the active nodes are backed up by a single backup node. A 1:1 HA pair of dedicated Operations, Administration, and Maintenance (OAM) nodes is required in the deployment to configure and manage SBC N:1 HA nodes. You must have a RAMP in your deployment in order to store the configuration history for the SBC cluster.

Distributed SBC Architecture

The traditional Integrated SBC (I-SBC) architecture provides all the services associated with an SBC – call processing, media policing, transcoding, signaling normalization, and so on – within a single node. Hardware-based SBCs support the integrated SBC model.

The SBC SWe also supports a Distributed SBC (D-SBC) architecture that separates the signaling, media, and (optional) transcoding functions and implements them on separate node clusters. Clusters communicate with each other by means of a control protocol to jointly provide the full set of SBC services. Separating the services enables flexible scaling of the functional components to meet the specific requirements of a deployment.  Refer to Distributed SBC Architecture for more information.

SBC Personalities

The SBC SWe supports a range of different deployment models and requirements. Some of these variations are referred to as specific SBC "personalities" from a node instantiation standpoint, while other variations are special use cases of other personalities. Terminology related to SBC personalities is explained below:

• I-SBC: "Integrated SBC" with signaling, media, and (optional) transcoding functionality within a single node. An SBC instantiated without a personality type defaults to I-SBC. This personality type is analogous to the SBC Core hardware platforms.
• D-SBC: "Distributed SBC" refers to the architecture in which the signaling, media, and (optional) transcoding functions are handled by dedicated SBC nodes or clusters, and includes the personalities below:
  • S-SBC: "Signaling SBC" in a distributed SBC deployment. An SBC must be instantiated with the Signaling "personality" to behave as an S-SBC.
  • M-SBC: "Media-handling SBC" in a distributed SBC deployment. An SBC must be instantiated with the media "personality" to behave as an M-SBC.
    • T-SBC: "Transcoding-handling SBC" in a distributed SBC deployment. T-SBC is a special case for an M-SBC. "Transcoding-handling" requires specific configuration settings, but not a completely distinct "personality." Only an M-SBC can be configured as a T-SBC.
• SLB: “SIP-aware front-end Load-Balancer” refers to a personality consisting of nodes that provide a public-facing front end for SIP traffic targeting the SBC. In addition to providing load balancing for the back-end SBC nodes, the SLB architecture insulates the network from making configuration updates in response to increases/decreases in nodes by providing a single IP address access point for traffic from peers.    
• SO-SBC: "Signaling Only SBC" is not an SBC personality, but denotes a configuration setting dedicated to handling signaling only. Either an I-SBC or an S-SBC can be configured as an SO-SBC, which is the primary difference between S-SBC and SO-SBC.

Deployment Models Currently Supported by SBC SWe

The following tables summarize the current support the SBC SWe provides for different combinations of deployment options and platforms.

The first table lists the redundancy models currently supported by different types of SBC nodes. In this table, the column for OAM nodes refers to the OAM nodes themselves, not the nodes they are managing.

Redundancy Model Support by Specific SBC Node Type

The second table lists specific platforms and which types of SBC nodes can be deployed on each. 

Platforms Supporting Specific SBC Node Types