Enea Aptilo SMP Common Core Functions
We have built Enea Aptilo SMP for stability, scalability, and high availability with geographical redundancy. The application logic is separate from the communication, which makes it easy to scale with additional nodes where capacity is most needed.
Taking the Scalability Issue Out of the Equation
When it comes to performance, we can only be sure of one thing. No matter if we use RISC-based, standard Intel®-based or proprietary servers or hyperscalers, today’s top performance will be considered a mediocre performance tomorrow. We can also be sure that the server hardware price will go down at the same pace as the speed goes up.
The only way to be sure to take the scalability issue out of the equation is to get linear scalability when adding more servers. With the fast development of server hardware, it is crucial to go with a platform that can offer the best price-performance ratio.
We achieve carrier-class scalability by distributing our system over different layers in several standard Intel®-based servers. This provides the most cost-effective platform for delivering additional performance by just adding another server.
The Intel®- architecture offers economy of scale thanks to its pure volume in the number of units. This means you will not risk investing in individual high-performance servers that may not fit the purpose in the end. True linear scalability can only be achieved with 100% flexibility in both hardware and software.
The Aptilo SMP ALE Architecture
In the Aptilo Long-term Evolution (ALE) architecture, we have divided the functionality into three distinct layers:
- A management layer for configuration and monitoring
- A control layer for protocol-level interactions with external systems
- An execution layer for application logic processing.
The different layers are distributed over several server nodes to increase capacity where needed most and obtain high availability, including geographic redundancy and distribution.
We scale from two redundant server pairs up to a large linearly scalable server cluster by just adding more server nodes.
ALE Application Control Layer
The control layer runs a number of protocol adapters that facilitate interoperability with the required set of external systems. These protocol adapters include RADIUS, Diameter, REST, SOAP/XML, LDAP, and SNMP. New adapters are introduced as needed to implement new or modified relationships with external systems. This layer does not need redundant servers as it is state-less and can be replaced by any other server with the control layer running.
ALE Application Execution Layer
All application logic is performed in this layer. It holds state and thus needs to be on redundant server pairs. We have learned the hard way that no matter how many features we add, there will always be one more needed. Every customer has different legacy aspects we need to consider when designing the solution. Thus new logic needs to be added as configuration. Learn more about how we have solved this in the separate section about the Aptilo ServiceGlue™ concept. The application execution layer architecture allows us to run several different types of applications such as EAP-SIM authentication and Policy Management from the same scalable platform.
ALE application management layer
The application management layer handles the configuration and monitoring and is tightly integrated with a management plane spanning all layers. With this design, we can assure that we add capacity where it is most needed. It might be the control layer that needs the most power for signaling intensive applications, while in applications with extensive business logic, it might be the execution layer.