Light HTTP server
Used by communication engines to expose an API or a graphical UI.
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), Interworking 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 the 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 the same foundation. This not only eases maintenance of the microservices but also enables faster creation of new ones. Here are some of the foundation principles:
1. Self-contained
A communication engine is always self-contained, meaning it can operate independently without relying on other containers.
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 a web interface for manual intervention.
4. Auditable
A communication engine provides tools to monitor its health and audit its behavior. Common examples include CDRs, alarm logs, and audit logs.
5. Follow industry standards
Communication engines must follow the OpenAPI standard and comply with the 3GPP Common API Framework.
6. High level of customization
Communication engines implementing a telecom protocol must provide the ability to customize their protocol stack to adapt to various use cases.
The foundation components are reusable across cloud communication engines to reduce the development time of new microservices:
Async HTTP client
Used by communication engines that need to issue HTTP requests.
React UI library
A set of React components reused across the engines' single-page web GUIs.
CAPIF library
A library of the CAPIF APIs required by API invokers and API providers.
SIP library
Provides the SIP & MRFC protocol stack.
Diameter library
Provides the Diameter protocol stack.
GTP library
Provides the GTP-C v1 and GTP-C v2 protocol stacks.
RADIUS library
Provides a client/server RADIUS protocol stack.
SMPP library
Provides the ESME SMPP v3.4/v5.0 protocol stack.
SS7 library
Contains the full 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 a data access component for engines that require NoSQL document storage.
At 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 add more value. This is done by applying the common microservices architecture and by reusing the existing libraries to reach stability and production level very quickly.