OpenProvider vAAA Service Management Engine (SME)

In this blog, you can find out what OpenFunctions are and how to create logic within AAA systems for the specific services that telecoms want to perform (fixed and mobile internet, VoWiFi, etc). Introduction to Service Management Engine (SME) step by step with examples.

In the process of session establishing, the AAA system should be flexible and ready to adapt to the different requirements of Telecom. Also, AAA system should be a component that can implement logic customized for equipment of different vendors, business requirements, and customer needs. Implemented logic must be well organized, fully transparent and easily expandable and changeable in the case of introducing new services. In this blog, we will present SME as a fully adaptable component ready to support any RADIUS logic.


Service Management Engine (SME) is the main processing engine for the OpenProvider platform. It uses an internal workflow for processing each incoming packet by going through different stages and provides several improvements compared to standard AAA platforms by introducing OpenFunctions that are Run-time Policy Enforcement hooks. Each processing stage adds additional variables and triggers different OpenFunctions depending on packet attributes. Each packet processing finishes into AAA Assembler (A4) that is responsible for preparing the final response packet.

SME process is divided into 4 phases:

  1. Policy Path Selection
  2. Group Selection
  3. Policy Selection
  4. AAA Assembler.

Phase 1 is the Policy Path Selection phase and it is used to distinguish between different access types or different service types. Each Policy Path can have multiple Groups. When Phase 1 is completed and Policy Path is selected, the next SME process is to select one Group from the selected Policy Path. Group selection is Phase 2, and the group is selected depending on subscriber profile data. Phase 3 selects active Policies inside the selected Group. Each Group can have one or multiple Policies that can be activated together (Tied service bundles). The group contains a list of ordered Policies that are matched until the end of the list, or until the Policy is matched that do not allow additional policy matching (nice flag on Service definition). Each Policy that is selected during Phase 3 will proceed with Phase 4 which is AAA Assembly (figure 1).

What are OpenFunctions?

OpenFunctions allow writing complex rules in order to deliver rich policing logic such as: 

  • multi-service and quota management 
  • tiered services, 
  • service-on-demand 
  • time of day/week/month/year usage
  • balance selection and credits fail-over
  • recurring credits reset 
  • bandwidth on demand 
  • QoS
  • roaming and other session limits 
  • congestion management etc.

OpenFunctions are used as core policing routines and are developed using an application tool that allows administrators to design custom processing logic written in a pseudo-language. The pseudo language is a combination of standard PHP functions and custom-created functions for RADIUS, LDAP, and DHCP protocols for a particular IP or pool of IP addresses. The basic setup assumes a limited number of built-in PHP functions which can be easily extended without service downtime. This basic setup covers the most used PHP functions for:

  • simple data types (numeric, string, binary and boolean) and complex data types (associative arrays)
  • all PHP operators
  • conditional (if-then-else-fi)
  • iteration (foreach-as-do-end)
  • data manipulation
  • time and date functions.

Custom created functions allow performing of the following actions:

  • add, delete and get any RADIUS attribute
  • session CoA, PoD, and Close packet
  • get session values by IPv4 or IPv6 address
  • LDAPSearch, LDAPCreate, LDAPUpdate, and LDAPDelete
  • getDynamicIPAddress function which dynamically allocates an IP address in a case when OpenProvider is DHCP for public IP addresses
  • Allocate a pool of IP addresses for a particular Network Access Server (NAS).

OpenFunctions are written within an editor which is part of the Admin Web Interface. The editor checks the syntax each time a customer has to create or change something. If there is any syntax error or if some undefined function is used, the editor will raise an error and OpenFunctions will not be saved.

All OpenFunctions are loaded on run-time when the first request is received by the OpenProvider platform. They will be cached on each Policing node for 5 minutes. Also, any changes on the OpenFunction level will be propagated after maximum of 5 minutes (after cache expire) without the need for service restart.

OpenFunctions always return a Boolean value – true on success or false on failure, meaning they do not return any other data types (array, integer, string, etc). OpenFunctions are functions that can have local variables but also use predefined (global) variables as well.

Local variables are visible only on the OpenFunction level. Predefined variables are used for: 

  • sharing data between OpenFunctions executed in different stages of policing logic execution
  • configuring attribute-value pairs in the packet which is sent to a NAS, either as a request or as a response 
  • accessing attributes (external variables) provided by external systems or configured through the Admin Web Interface in order to extend policing rules logic.

A list of predefined variables is given below:

Table 1. List of predefined variables






Contains RADIUS packet data



Contains all system and custom-defined markers



Contains the request type and all submitted attributes



Contains reply for request and all attributes within it

Example: REPLY[‘Action’] = ‘ACCEPT’ sets reply code for receiving request



Contains the forwarding (proxy) request and all forwarded attributes



Contains reply for forwarding request and all attributes within it



Contains all session variables (total number of established sessions per username, start and interim time, total rated credits, etc.)



It contains policy and service system variables.



Contains subscriberʼs profile properties (User-Password, User-Pin, Calling-Station-Id)



Configuration parameters (Protocol decision parameters)



Contains external variables configured from the application interface or defined through web services



Session related persistent variables that can be maintained within OpenFunctions and once set will be available until the session expires

For example, the final goal of processing an authorization request packet through OpenFunctions is to create a REPLY global variable that contains an Accept or Reject code. The REPLY global variable with the code Accept must contain all AVPs necessary for the requested service.

Policy Path Selection and Preprocessor

After giving a brief overview of the way OpenFunctions work, we can return to the first step of the SME process and explore it further. Policy Path Selection together with Preprocessor is the first activity in request processing. Policy Paths are used to classify requests for later processing in respect to different types of access networks, vendor equipment, application middle-ware, or any information which is available from the RADIUS Request. There can only be a single policy path at the end of the selection process. In the case when several Policy Paths match certain criteria, the one with the lowest metric is selected. When no Policy Path is matched, further processing is canceled and system error is raised. All subsequent processing logic and engine routines depend on the selected Policy Path. 

In the Preprocessing phase, we retrieve subscriber data, usually by sending a LDAP request to CNTDB. The retrieved subscriber profile data is then used to link the subscriber to a certain Group and determine the next stage of packet processing. This stage can also be used for preparing information that can make further packet processing easier. Also, Preprocess can be the last phase of packet processing. For example, in a case when subscriber profile data is not available in CNTDB or OpenProvider does not manage to connect with the CNTDB we do not have enough information for further processing. In that case Preprocess phase will return REPLY message with a reject code for an authorization request.

 Example: We have OpenProvider system for mobile internet. It is assumed that an authorization request reached OpenProvider platform. The Policy Path Matching OpenFunction will check EPG IP addresses from the incoming request. If the IP address is from an expected range of IP addresses, defined in EXTVARS, we will match the policy path i.e. the Policy Path Matching OpenFunction will return true. Otherwise, it will return false. Next, in preprocess, we will send a LDAP search request to CNTDB and get all subscriber data. The system will check agreed LDAP AVP and mark this subscriber as Prepaid i.e. we will set Prepaid Group.

Table 2. Policy Path and Preprocess properties




Unique policy path identifier


Path numeric distance (lower first)


Policy path name

of selection

OpenFunction for path selection

of preprocess

Preprocess OpenFunction for selected policy path

Groups, Policies and Services

Once Policy Path is selected, all groups on the path are matched by calling a specified OpenFunction. The usage of OpenFunction within a Group is recommended for handling general business rules applicable on a group level, such as session limits, password authorization, expiration checks, subscriber status validation, etc. There can be more groups on a single path, which implies advanced policy logic configuration.

Groups also can be the last phase of packet processing. For authorization requests, if the password is incorrect or subscriber is disabled or the subscriber reached a maximum number of sessions OpenProvider will return a REPLY message with reject code and packet processing will be finished.

Example: We will create a Prepaid Group Matching OpenFunction. In this OpenFunction we will check subscriber status and session limit.

Table 3. Groups properties




Unique group identifier


Group name

policy path

Policy path on which group is located

of match

OpenFunction for group matching

All policies are bonded into groups and ordered by matching priority. The system starts with policy matching only if a group is previously matched using the specified OpenFunction. Each policy is defined with service, matching, rating, and interim rules. Matching rules are used to determine if the policy is suitable for the service. Once a policy is matched, it may apply rating and/or interim rules to the current session. The rating engine is responsible for taking care of charging the service, while the interim engine is responsible for tracking and maintaining service indicators during the session lifetime. All rules are written inside OpenFunctions. Multiple policies can be matched within a group if a nice flag exists on service definition.

Example: We assume that the subscriber is active and the number of sessions is below the limit so packet processing proceeds to the Policy Matching phase.  In this phase, we want to separate policies for Prepaid subscribers who connect to the Internet from their home country, and subscribers who use the roaming network because different AVPs will be returned in the response packet. So, our Prepaid group will have two different policies. We will create one OpenFunction for each policy. The First will be called Prepaid Home Policy Matching and the second will be called Prepaid Roaming Policy Matching. The first function will check RADIUS AVP 3GPP-SGSN-Address and compare it to the Home SGW addresses. Within the Group definition, we will always call Prepaid Home Policy Matching first because a majority of sessions came from the home network. If this function returns false then Prepaid Roaming Policy Matching will be called.

Table 4. Policies properties




Unique policy identifier


Rating balance identifier

balance unit

Rating balance unit


Policy name

of interim

OpenFunction for runtime tracking rules

of match

OpenFunction for matching rules

of rate

OpenFunction for service rating rules


Service identifier

The policy engine does not allow multiple policy matches of the same service. The first match is honored, while other policies with the same services are skipped.

Example: We will create two Services: Prepaid Home and Prepaid Roaming. None of the services will have a nice flag which means that these policies are the end of packet processing.

Table 5. Services properties




Unique service identifier


Unique service name, which is optionally referred on Service-On-Demand requests


Defines if the service is nice to other services (yes/no)


Rating engine might be optionally associated with charging policy and balance to charge credit. There are few general rules of rating engine:

  • if there is no balance defined, service might be granted with respect to other policy properties.
  • charging is performed only when the balance is defined. Rating coefficients are allowed to be zero, which will result in zero credits charged.
  • UDR records are generated only if charging was successful or when the balance is not defined and rated credits are non-zero.
  • A credit recurring is performed only if balance is defined, and such logic is controlled within OpenFunctions.

A4 (AAA Assembler)

So, up to this moment, we have explained Policy Path and Preprocess Groups, Policy, and Services. We need one more step: to connect all these stages into one logical flow. Also, through different stages and example explanations, we have treated only authorization requests. The RADIUS protocol has other types of Requests as well. In addition, OpenProvider has a custom-created request for different purposes so we need to prepare the system to process any kind of request through different stages. For that purpose, we use the AAA assembler. The AAA assembler will guide requests through all phases of SME and, in the end, select the appropriate OpenFunction to an event in respect to the mixed context of Request Type and Request Data.

Following Request Type are possible:

Table 6. Request Types

Request Type

NAS Type




Access Reply



Accounting Start



Accounting Interim



Accounting Stop

Internal Request

When Policing function detects a dead session


Dead Session

Internal Request

When Policing function requested a disconnect


Disconnect Message

Internal Request

When Policing function request a service activation


Service Activation

Internal Request

When Policing function request a service deactivation


Service Deactivation

CoA-Response or PoD-Response


CoA / PoD

CoA-Response or PoD-Response

Proxy Server

Proxy CoA / PoD

Accounting-Request (Start, Interim or Stop)

Proxy Server

Proxy Accounting


Proxy Server

Proxy Authentication

If the Request Type was Access-Request from NAS server, A4 will call the Access Reply OpenFunction. If Request Type was one of the Accounting messages, the appropriate Accounting OpenFunction will be called. 

Example: We need two AAA Assemblers, one for Prepaid Home and another for Prepaid Roaming. Both will have the same Policy Path, Preprocess, and Group Matching OpenFunctions. The majority of event OpenFunctions will be the same. Policies, Services, and the Access Reply will be different. We have to create two Access Reply OpenFunctions: Prepaid Home Access Reply and Prepaid Roaming Access Reply. Both of these functions will have an appropriate set of AVPs needed for service.

 Table 7. A4 properties




Unique A4 instruction identifier


Unique service identifier


Policy context of specified service


Group context of specified service


NAS client context of specified service

policy path

Policy path selection

of event

Instruction OpenFunction that will apply on specified A4 event. There are several A4 events defined like: Access Reply, Accounting Start, Accounting Interim, Disconnect Message, Service Activate, Service Deactivate, etc


To conclude, SME provides full flexibility and power in creating policing logic. Built-in PHP functions extended with custom-created OpenProvider functions make it very intuitive and standardized. There is a potential to segment each service in a separate flow. In that way, any future change can be isolated to a particular service or scenario which minimizes the possibility of any logical error for the complete system. The modern editor fully eliminates the possibility of any syntax error.

None of AVPs is hardcoded and can be changed and adapted according to customer needs. Also, any AVP from Incoming Request can be a parameter that can trigger logic and perform actions. The existence of predefined variables such as SESSION and POLICY make it possible to recognize any changes during the session i.e. in the interval between two interims and perform re-policing.

OpenFunctions are cached in-memory for each RADIUS thread which makes function execution the fastest possible. Cache expiration eliminates the need for service restart each time when any parameter in OpenFunctions is changed.

In our next blog, we will do a video demonstration where we will code a basic example of RADIUS packet processing, so stay tuned!

Related articles


Logate Helped Erste Bank Montenegro Implement PSD2 Directive

Logate’s collaboration with Erste Bank Montenegro continues as we enter a new era of banking in Montenegro. Recently adopted PSD2 directive brings more transparency and ...

How to migrate from legacy AAA to OpenProvider AAA system?

Migrating from a legacy AAA to a new AAA solution requires system integration with various telco network components. If you want to learn more about ...

Türk Telekom to transform Corporate Radius AAA with Odine and Logate

Odine, one of the leading virtualized and containerized infrastructure communication solution partners in EMEA today announced that together with Logate, they have successfully deployed Open ...

OpenProvider AAA system vs Legacy AAA solutions – Key Product Benefits

Legacy core network solutions such as AAA system are increasingly replaced with modern platforms that offer convergence, efficiency and redundancy. Here is why OpenProvider AAA ...

Like what you're reading?

Sign up for more updates.