Technology
Slicce develops microservices that focus on performing specific tasks on top of the telecom core network. These microservices are called cloud communication engines. The communication engines can either stand by themselves or be deployed with others in a workload. A workload is a set of containers or pods put together to construct a solution, platform or service. The cloud communication engines are divided into four categories: API Exposure Functions (AEF), Application Functions (AF), Inter-Working Functions (IWF) and Load Balancers (LB). Slicce's architecture relies on OpenAPIs to communicate between microservices. Therefore, it also delivers a 3GPP Common API Framework Core Function (CAPIF-CF) to harmonize the communication between the microservices in a standard way and allow API exposure for 3G, 4G and 5G northbound APIs. All the cloud communication engines, regardless of their category, rely on one same foundation: the slicce cloud communication engine foundation.
The slicce cloud communication engine foundation
All slicce communication engines follow the same design principles and use one same foundation. This eases not only the maintenance of the microservices but also enables a faster creation of new microservices. Here are some of the foundation principles:
1. Self-contained
A communication engine is always self-contained, meaning it can operate by itself and doesn’t require the presence of other containers to service.
2. Lightweight
A communication engine is not a big silo but a microservice. It must implement a specific function that can serve a wider workload.
3. Remotely managed
Communication engines must always expose remote management capabilities; configuration files, configuration APIs or web interface for manual intervention.
4. Auditable
A communication engine provides the tools to audit its health and its behavior. An example of common audit tools are CDRs, Alarms logs or Audit logs.
5. Follow industry standards
Must follow OpenAPI industry standard and must comply with the 3GPP common API framework.
6. High level of customization
Communication engines implementing a telecom protocol must provide the ability to customize its protocol stack to adapt to various use cases.
The foundation components are reusable across cloud communication engines to reduce the time of development of a new microservices:
Light HTTP server
Used by communication engines to expose an API or a Graphical UI.
Async HTTP client
Used by communication engines that needs to issue HTTP requests.
React UI library
A set of react components reused across engines single page web GUI.
CAPIF library
A library of CAPIF API requires for API Invokers and API Providers.
SIP library
Provides the SIP & MRFC protocol stack.
DIAMETER library
Provides the DIAMETER protocol stack.
GTP library
Provides GTP-C v1 GTP-C v2 protocol stack.
RADIUS library
Provides a client/server RADIUS protocol stack.
SMPP library
Provides ESME SMPP v3.4/v5.0 protocol stack.
SS7 library
Contains all the SS7 protocol stack; SCTP, M3UA, SCCP, TCAP, MAP, CAP and INAP.
Common library
Contains common framework libraries such as logging, caching, JSON and SNMP.
Data access library
Provides data access component for engines that requires storage of noSQL docs.
In the heart of the foundation the 3GPP Common API framework facilitates communication exchanges using APIs across the workload’s microservices.
What makes the cloud communication engine foundation valuable?
It brings us the ability to rapidly develop new communication engines that adds more value. This is done by applying the common microservices architecture and by re-using the existing libraries to reach stability and production level very rapidly.