Skip to content

Cloud Native

Load Balancers

SS7

built by Slicce

Supercharge your kubernetes workload with SS7 load balancing capabilities

The SS7 load balancer terminates one or many M3UA IPSPs, SGPs or ASPs and load balance SCCP payloads based on SCCP GT or SCCP SSN. The engine also has the ability to perform Global Title Translation on the calling or called party addresses. This is ideal to have a single entry point for SIGTRAN traffic into a workload and distribute traffic across multiple SIGTRAN-based microservices.

  • Lightweight docker image
  • Orchestrated via ConfigMap or API
  • Ultra-reliable & high performant
  • Carrier-grade alarms and KPIs

Indispensable tool to drive 3G services on cloud native environments

Load balancers are most commonly coming as a part of the kubernetes cluster in a form of ingress controller or as part of the cloud infrastructure in various forms. While these perform perfectly for UDP/TCP/HTTP type of traffic, we sometimes need more telecom protocols aware load balancers to properly distribute the telecom control plane within a workload. Slicce load balancers come to fulfill this need when the generic load balancer of the infrastructure is not able to load balance a specific telecom protocol.

In particular and focus on SIGTRAN traffic, the SS7 Load balancer facilitate:

  • Optimized traffic distribution: It effectively distributes traffic within the telecom control plane to ensure balanced workloads and minimize bottlenecks.
  • Elastic and scalable: Capable of scaling dynamically to meet the changing demands of SS7 traffic, ensuring flexibility in cloud-native environments.
  • High customizability: Allows extensive customization to meet specific operational needs and accommodate different customer use cases.
  • STP like routing capabilities: Route by Point Code, Sub System Number or Global Title with Global Title Translation capabilities on calling and called party addresses.
  • Multiple load balancing schemes: First available, Round Robin, Time-based and Event-based schemes via API.
Cloud Native api exposure functions CAMEL gateway DIAMETER gateway SIP gateway MAP gateway USSD gateway SMS gateway SMS and Charging Interworking functions cloud native SS7 load balancers cloud native diameter load balancer cloud native sip load balancer cloud native GTP load balancer

Easily distribute traffic between services in your workload

1. When an SS7 signaling message arrives at an SCCP router (or at a signaling point), it typically contains the destination Global Title (GT), which includes the address information for the service. The message also contains an SSN associated with the signaling function or service for which the message is intended.

2. SCCP performs Global Title Translation (GTT) to resolve the Global Title (GT) to an SSN. In the translation process, SCCP examines its translation tables to find out which SSN is associated with the given GT and then uses that SSN to route the traffic to the appropriate signaling point or application server.

3. Once the SSN is determined, the SCCP routing engine uses it to direct the message to the correct application server or signaling point in the network. The SSN essentially acts as a selector or indicator for a specific service or function within the signaling point.

4. The signaling point or application server that receives the message based on the SSN performs the necessary application-specific processing. For instance, the SSN might map to a call processing service, a message routing service, or any other telecommunication service, depending on the nature of the message.

Traffic Routing Based on SSN (Signaling Subsystem Number) in SCCP Traffic Routing Based on SSN (Signaling Subsystem Number) in SCCP

Momentary service failures are no longer a problem

The SS7 Load Balancer can distribute traffic towards a same global titlte between multiple service instances of a same kind. In which case it can automatically detects a failing service and assure service continuity via remaining service instances. The service set can be elastic or auto-scaled since the load balancer will allow traffic distribution to new instances of the service immediately. It is also possible for an external orchestrator to orchestrate the load balancer via REST API in case the topology of the workload is getting updated.

Automatic failover with API Orchestration Automatic failover with API Orchestration

functional specs

Software packaging Docker image, RPM or DEB package.
SCTPRFC 4960; with multi-homing support
M3UARFC 4666; IPSP, ASP and SGP modes
SCCPITU-T Q.711 through Q.714 Connectionless Class 0 & 1
Orchestration APIRESTful over HTTP2

Let'sconnect

Telecom is our expertise