Mobius Diameter API 10.0.0.1

1. Introduction

The Mobius Diameter API is a comprehensive toolset designed to enable developers to build, manage, and optimize Diameter-based applications across various telecommunications networks. Whether implementing billing solutions, managing subscriber data, or enhancing network policy controls, the Mobius Diameter API provides the flexibility, scalability, and performance required for modern telecommunication systems.

This API is built on top of the Diameter protocol, which is a critical component in AAA (Authentication, Authorization, and Accounting) infrastructure for LTE, 4G, IMS, and evolving 5G networks. By offering developers fine-grained control over network interactions, message exchanges, and session management, Mobius Diameter API allows operators and service providers to create reliable, high-performance solutions that serve to the demands of today’s telecommunication environments.

2. Core Concepts

This section provides a high-level description of key concepts directly related to the API of the Mobius Diameter Stack, including an overview of the Diameter protocol, API design principles, and interaction between the core components. 

2.1 Diameter Protocol Overview

The Diameter protocol is a highly flexible, extensible, and robust framework. It is an evolution of the RADIUS protocol, addressing many of its limitations, particularly in scalability and security. Diameter is commonly used in network access control, mobility management, billing, and charging systems, especially in telecommunications and Internet Service Provider (ISP) environments.

2.2.1 Key features of the Diameter protocol:

Modular Design: The API is designed to be modular, allowing developers to work with specific Diameter interfaces depending on the requirements of their application. Each interface has its own SessionFactory, AVPFactory, and MessageFactory, enabling fine-grained control over the message and session handling process.

Extensibility with Vendor-Specific Interfaces: Alongside the standard interfaces, the API supports vendor-specific interfaces such as Ericsson and Huawei Credit-Control, allowing the creation of applications that integrate seamlessly with proprietary network solutions.

Customizable Session Management: The API provides robust session management for both client and server sides, ensuring that message exchanges are tracked, retried when necessary, and properly terminated. 

Comprehensive AVP and Message Handling: With AVPFactory and MessageFactory, developers can easily construct, encode, decode, and validate Diameter messages. 

Optimized Network Logic Using Netty: The network logic in Mobius Diameter has been optimized using the Netty framework, a non-blocking I/O client-server framework designed for high-performance network applications. Netty’s asynchronous, event-driven architecture ensures that network operations, such as managing TCP and UDP socket connections, are handled more efficiently.

2.2.2 Client/Server Logic in the Diameter Protocol

In Diameter, there are two primary roles: the client and the server. These roles are not like traditional web-based client-server relationships but are more focused on the context of message exchanges for specific Diameter applications. Each Diameter application defines how client and server roles interact within the application layer.

The ClientSession and ServerSession classes are essential for managing these roles. Each session manages the lifecycle of a request-response interaction between the client and the server. These sessions handle the internal logic required to send messages (requests and responses) and manage the state of the session during its lifetime.
The ClientSession represents a client that is the entity that initiates communication by sending a request to the server. It typically awaits a response from the server and processes it once it arrives.
The ServerSession represents the server-side logic, where the server responds to incoming requests initiated by the client. The server receives requests, processes them, and sends appropriate responses (answers).
By separating the client and server logic, the Mobius Diameter API ensures clear responsibilities for both sides of the message exchange:
Client: The client initiates requests (such as CreditControlRequest for billing) using SessionFactory to manage the session. The client session keeps track of multiple transactions for the duration of the interaction with the server.
Server: The server receives the client's request and, using SessionFactory, creates a server session to manage the interaction. The server sends back responses such as CreditControlAnswer.

2.2 API Design Principles

The Mobius Diameter API is built with key principles that provide developers with a modular, extensible, and scalable framework. The following sections outline these core design principles, helping to understand the architectural choices that support the versatility and adaptability of the Diameter protocol implementation.
Modularity: Each Diameter application has its own distinct AvpFactory, MessageFactory, and SessionFactory, ensuring separation of logic and easy management of each component.
Extensibility: Developers can introduce new AVPs, messages, and commands by extending existing factories without altering the core API logic.
Protocol Independence: The core logic of Diameter is abstracted from the application-specific logic, promoting flexibility for adapting to new use cases and applications.
Reusability: Common patterns are shared across all factories and applications, ensuring developers can easily work with different parts of the API without learning new paradigms.
Scalability: The system is built to handle high volumes of network interactions, with session management that scales to meet the demands of 4G, 5G, and IMS networks.

2.3 Interaction Between Core Components

The API's key components interact through well-defined interfaces and methods. These interactions define the core functionality of the Diameter stack, including session management, message creation, and AVP handling.

2.3.1 DiameterStack

The DiameterStack is the central piece of the Mobius Diameter architecture. It is responsible for managing the network connections, session handling, and various aspects of Diameter protocol message exchange. The stack creates, manages, and provides access to different protocol functionalities based on the specific application.

2.3.2 DiameterProvider

The DiameterProvider is responsible for managing different types of listeners (ClientListener, ServerListener) and is an interface to handle interactions between the application logic and the Diameter stack. It facilitates the sending and receiving of Diameter messages and links the specific behavior of Diameter interfaces with the session management.

2.3.3 SessionFactory

Each interface has its own SessionFactory. The SessionFactory is responsible for creating instances of ClientSessions and ServerSessions based on the type of Diameter request (e.g., PushNotificationRequest, UserDataRequest, CreditControlRequest).

2.3.4 MessageFactory and AvpFactory

Both AVPFactory and MessageFactory serve as fundamental tools for constructing and managing Diameter messages in the Mobius Diameter stack. They handle the core responsibilities of creating, encoding, and decoding AVPs (Attribute-Value Pairs) and Messages, ensuring that the Diameter protocol communication adheres to the expected format and structure for each specific interface.

2.3.5 NetworkManager

This component within the DiameterStack handles all network communication, including setting up links, managing reconnections, and ensuring the proper routing of Diameter messages between clients and servers.

2.3.6 Listeners

ClientListener: Receives responses from the network and processes them in the context of a client session.
ServerListener: Receives requests from the network and processes them within a server session, sending back responses.

2.3.6 Workflow Example: E4 Interface

To understand how the workflow operates in practice, let's consider an example using the E4 interface:

Creating a Session: The SessionFactory for E4 is used to create either a ClientSession or a ServerSession based on the type of message. For instance, a PushNotificationRequest creates an E4 client session when initiated by the client through the SessionFactoryImpl.

Sending a Message: The ClientSession is responsible for sending requests like PushNotificationRequest through the DiameterProvider, which interacts with the NetworkManager to send the message over the network.

Receiving a Response: When the corresponding answer (e.g., PushNotificationAnswer) is received, it is handled by the ClientListener. This listener is registered with the DiameterProvider to capture incoming events.

Session Management: Throughout the lifecycle of a session, both client and server sessions manage states and transitions (e.g., handling timeouts, reconnections, etc.).