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.
SME
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:
- Policy Path Selection
- Group Selection
- Policy Selection
- 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
Type | Name | Description |
Array | PACKET | Contains RADIUS packet data |
Array | MARKER | Contains all system and custom-defined markers |
Array | REQUEST | Contains the request type and all submitted attributes |
Array | REPLY | Contains reply for request and all attributes within it Example: REPLY[‘Action’] = ‘ACCEPT’ sets reply code for receiving request |
Array | PROXY_REQUEST | Contains the forwarding (proxy) request and all forwarded attributes |
Array | PROXY_REPLY | Contains reply for forwarding request and all attributes within it |
Array | SESSION | Contains all session variables (total number of established sessions per username, start and interim time, total rated credits, etc.) |
Array | POLICY | It contains policy and service system variables. |
Array | PROFILE | Contains subscriberʼs profile properties (User-Password, User-Pin, Calling-Station-Id) |
Array | CONFIG | Configuration parameters (Protocol decision parameters) |
Array | EXTVARS | Contains external variables configured from the application interface or defined through web services |
Array | SESSIONVARS | 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
Property | Description |
id | Unique policy path identifier |
metric | Path numeric distance (lower first) |
name | 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
Property | Description |
id | Unique group identifier |
name | 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
Property | Description |
id | Unique policy identifier |
balance | Rating balance identifier |
balance unit | Rating balance unit |
name | Policy name |
of interim | OpenFunction for runtime tracking rules |
of match | OpenFunction for matching rules |
of rate | OpenFunction for service rating rules |
service | 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
Property | Description |
id | Unique service identifier |
name | Unique service name, which is optionally referred on Service-On-Demand requests |
nice | Defines if the service is nice to other services (yes/no) |
Rating
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 | OpenFunction |
Access-Request | NAS | Access Reply |
Accounting-Start | NAS | Accounting Start |
Accounting-Interim | NAS | Accounting Interim |
Accounting-Stop | NAS | Accounting Stop |
Internal Request When Policing function detects a dead session | n/a | Dead Session |
Internal Request When Policing function requested a disconnect | n/a | Disconnect Message |
Internal Request When Policing function request a service activation | n/a | Service Activation |
Internal Request When Policing function request a service deactivation | n/a | Service Deactivation |
CoA-Response or PoD-Response | NAS | CoA / PoD |
CoA-Response or PoD-Response | Proxy Server | Proxy CoA / PoD |
Accounting-Request (Start, Interim or Stop) | Proxy Server | Proxy Accounting |
Access-Request | 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
Property | Description |
id | Unique A4 instruction identifier |
service | Unique service identifier |
policy | Policy context of specified service |
group | Group context of specified service |
nas | 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 |
Conclusion
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!
