Agile Rules Technology (A.R.T.)

Transcription

1 Agile Rules Technology (A.R.T.) Unique, patented technology enables flexibility and scale White Paper

2 Contents Introduction 3 Rules engine types 4 A.R.T. inside 6 Summary 8 Acronyms 8 2 White paper

3 Introduction In a rapidly changing industry, service providers face many challenges that force them to react quickly to competitive threats, to implement new business models and to further reduce operational complexity and cost. To address those challenges, service providers rely on telecoms software solutions. And along with databases and analytics engines, rules engines are a key element of many IT systems. A rules engine is a software element that executes one or more rules in a run-time production environment. Rules engine software is commonly provided as a component of a larger system, which, among other functions, provides the ability to: Register, define, classify and manage all the rules Verify consistency of rules definitions Define the relationships between different rules Relate some of these rules to other applications that are affected or need to enforce one or more of the rules. In the context of telecommunications, rules could be used to define that a certain set of services or features is offered only to a select group of customers: for example, a rule could define that a music streaming package is offered free of charge only to subscribers of a premium shared data plan who use less than a defined amount of bandwidth every month. To meet the aforementioned challenges, several multi-dimensional requirements exist for the use of rules engine-based products in telecommunications: Ease of use: Rules need to be quickly created and easily modified without long lead times and consulting/implementation costs. A rules engine must therefore be easy to use in house so that service providers can use it in support of their evolving business needs Flexibility: The breadth of use cases in this new era of unparalleled broadband usage and the Internet of Things (IoT) is extensive. The rules engine needs to be flexible enough to be able to model all of these cases while maintaining its ease of use and performance characteristics High performance and scalability: High performance is required to meet the needs of an ever-increasing number of users and devices. The measure of performance is not only about raw trans per second (TPS), but the platform must be able to handle the burden of complex use cases, scaled across many sessions that require complex rules and data processing Maintainability: An essential aspect of operational efficiency is being able to maintain the product with efficient installation, upgrades, updates, version control, redundancy and recovery. Related to ease of use, maintainability is essential for service providers to integrate the product within its current Operations Support Systems and Business Support Systems (OSS/BSS) environment. 3 White paper

4 Rules engine types For telecoms software, typically two rules engine types are leveraged: general purpose rules engines or hard-coded rules engines. General purpose rules engine A general purpose or business rules engine is based on an open source or a commercial software system that executes one or more business rules in a run-time production environment. These engines have been used in a variety of industries and have not been built specifically for the telecommunications environment, but rather have been adapted to operate in this context. In addition, the engines have their own programming language that generally requires programming expertise, severely impacting ease of use and restricting many non-technical employees from being able to operate them. Following a linear step-by-step processing flow approach, a general-purpose rules engine first processes each message and evaluates it as a candidate to trigger a policy. If the engine determines that a policy is to be triggered, it invokes the rules that define that policy. At this stage, the engine collects the data needed to evaluate the policy (this information is often not available in memory). The engine then evaluates the policy conditions and initiates the associated. Although a general-purpose rules engine offers flexibility, its lack of a telecommunications-specific callflow modeling hampers its performance and maintainability under scale, especially in complex use cases. In addition, ease of use is reduced because adding and modifying business rules often requires a consulting contract with the actual policy vendor. Hard-coded rules engine A hard-coded rules engine is specific to a few basic use cases. Within the small scope of the use cases it was written for, it generally performs well but suffers severely in terms of flexibility, ease of use and maintainability. A new software load is often needed to support additional use cases outside the scope of its basic functions, resulting in increased operational costs and lead times. A hard-coded rules engine offers a model that is streamlined to a specific set of use cases or business policies. The engine processes individually and determines if they should trigger one of the policies. If one of the policies is to be triggered, specific data is available to help in the real-time processing of the rules leading to evaluation of the conditions and the execution of. The available data may be limited by the scope of the specific policy, and the policies themselves may not offer the breadth of control that is required in many environments. This model offers good performance and scale but limited flexibility and maintainability. Agile Rules Technology Nokia s Agile Rules Technology (A.R.T.) was originally designed by Alcatel-Lucent to combine the benefits of general-purpose and hard-coded rules engines, without any of their drawbacks. A.R.T. models the call flow and data requirements of a fundamental set of use cases that represent key business models. Backed by over 150 patents, A.R.T. provides excellent run-time efficiency by anticipating and caching key data requirements of each call flow. The technology then triggers the rules engine only under specific conditions. This specific modeling effectively reduces the complexity of all use cases before they reach the rules engine, resulting in excellent performance that does not deteriorate under scale and complexity. 4 White paper

5 A.R.T. leverages intimate knowledge of today s broadband environment, coupled with a solid understanding of the key business use cases that service providers need to implement. The A.R.T. model first filters rather than processes all incoming to find those that represent a specific event or rule set that represents a trigger for a specific rule. This important differentiator reduces the load on the rules engine because it processes only those that meet the filter requirement. A.R.T. assigns each rule group one or more triggers. If an incoming message represents a trigger that is assigned to a specific rule group, A.R.T. evaluates this rule group. A rule group is an A.R.T. object that represents a specific business policy and consists of several rules. Each rule has a condition and an action, and an action is executed if the condition is evaluated to be true. The A.R.T. data modeling capability caches all required data needed to evaluate these conditions in real time. This modular approach provides a powerful rules engine that offers performance and scale across multiple complex use cases while offering excellent ease of use and maintainability. Comparing rules engine types Figure 1 depicts the different approaches described above. Figure 1. Rules engine models General purpose rules engine Hard-coded rules engine Agile Rules Technology (A.R.T.) Millions of Millions of Millions of Process Process Limited data Filter to specific rule set Determine rules Use case 1 Use case n Rule set 1 Rule set X Modeled data Invoked rules Evaluate conditions Collect required data Evaluate conditions Evaluate conditions Rule table 1 Rule table Y Evaluate conditions 5 White paper

6 Table 1 compares advantages and disadvantages of the different approaches. Table 1. Characteristics of A.R.T. compared to general purpose and hard-coded rules engines Ease of use Flexibility Performance Scalability Maintainability General purpose Hard-coded Agile Rules Technology Detailed and complex configuration, many with own programming language Flexibility provides for wide range of use cases Performance suffers with weak use case modeling Inefficient processing leads to limited scale Often requires specialized professional services to modify policy rules Rules may need reconfiguration on software upgrade Configuration straightforward but rigid Rigid approach provides for only a few basic use cases Performance is good for the few supported use cases Scale is good for a limited number of use cases Often requires a new release to offer specific use cases Quick and easy configuration/ modification Flexibility of general purpose with performance of hard-coded Performance consistent across many service provider-specific use cases Efficient, modular processing leads to large scale Easy, in-service software upgrades with no rule reconfiguration A.R.T. inside Policy Control: Nokia Smart Plan Suite Policy (SPS-P) A.R.T. was originally developed as part of the Alcatel-Lucent 5780 DSC. Nokia s SPS-P inherits A.R.T. and combines it with a state-of-the-art cloud-native architecture to provide the Policy and Charging Rules Function (PCRF) in mobile and fixed networks. It enables service providers to map business demands and network constraints to easy-to-manage network policy rules. The role of Policy Management has dramatically changed over the last few years, resulting in everincreasing complexity of rules, creating a clear need for a better rules engine. Real-time rating and charging: Nokia Smart Plan Suite Charging (SPS-C) Charging use cases often require integration with other applications. The concept of a rule profile has been implemented in support of that requirement. Rule profiles allow the assignment of rules to other objects in the system as part of a workflow. For example, rather than creating a set of rule groups in a trigger to describe the different bundles for charging, one rule profile is assigned to a charging service based on applicability condition and another one for its tariff. This means that when users are creating bundles, they can focus on the charging service they are building without worrying about the underlying rule groups and triggers. Once the user has defined a bundle, it is scanned and translated into rule groups from the rule profiles. The order in which the rule groups are executed is defined by the priority of the charging service, and the list of the specific set of services for a subscriber. Another benefit to rule profiles is the ability to make provisioning easier for rules common to a feature. In the case of a ThresholdProfile, it s possible for a user to assign various thresholds for a bucket or counter. For example, a user can provision a 25% recurring threshold to send a usage notification to the subscriber, and a 50% threshold that reduces the quality of service for the remainder of a 2GB bucket. Rather than creating several rules for sending notifications at the 25%, 50%, 75% and 100% thresholds, and an additional rule for changing the QoS once the 50% threshold is reached, the user can simply 6 White paper

7 specify the percentages and recurrence values in the threshold object itself. From these values, the system generates the underlying rule groups, and assigns the appropriate. Not only does the provisioning of thresholds become easier, users can also add additional conditions in a standard rules format. For instance, it s possible to add a condition to only send a 25% threshold notification if the subscriber is not roaming. The recurring threshold is still defined as 25% and the relevant rules is generated; however, in this example, it is combined with the additional condition of not roaming. Customer Engagement: Nokia Smart Plan Suite Customer Engagement (SPS-CE) SPS-CE helps service providers build compelling data-centric plans, offers and business models that help drive new revenue without increasing the operational burden. With SPS-CE, offers can be based on certain criteria to provide personalized, compelling and relevant offers to subscribers. The rules engine plays a critical role in evaluating different insights (such as previous usage, location, time, current service plan, etc.) from a variety of sources. As service providers strive to implement competitive offers and new business models involving external partners, the complexity of those rules will increase significantly. The flexibility of A.R.T. provides a key area of differentiation for SPS-CE. Diameter Signaling Control: Nokia Dynamic Diameter Engine (DDE) Diameter Signaling Control is another area where the advantages of A.R.T. truly shine. While not required for every Diameter routing use case, A.R.T. proves especially beneficial in the context of a Diameter Routing Agent (DRA) for use cases such as: Online Charging System (OCS) off-load: The aim of an OCS offload feature is to filter out that can be safely disregarded by the OCS, for example usage reports that contain information about zero usage. Alternatively, in situations where the DRA has detected that the OCS is in an overloaded state, some update could be filtered out by simply discarding the message or by responding to the PDN Gateway (PGW) with a Diameter Busy message Long Term Evolution (LTE) roaming steering: In this use case the DRA routes Diameter between different service providers for LTE Roaming based on a defined set of rules Session binding: In this use case, routing decisions are based on pre-existing sessions, which requires a notion of keeping track of previous Load balancing: The DRA is used to load-balance between different instances of the same function, for example PGW or PCRF instances Redirect: The DRA is used by the Subscriber Location Function (SLF) in the IP Multimedia Subsystem (IMS) to identify the right Home Subscriber Server (HSS) Topology hiding: For example, the DRA could be used to hide the HSS topology from the Mobility Management Entity (MME). 7 White paper

8 Summary With the explosion of broadband services and the rise of the IoT, service providers have a tremendous burden: offering new, innovative services with scale and performance and continuing to satisfy their subscribers while generating new streams of revenue. Performance, scale and flexibility are essential to meeting these needs. With over 150 patents filed, A.R.T. leverages the benefits of general purpose and hard-coded rules engines without adopting any of their weaknesses. Nokia products based on A.R.T. offer a range of benefits: Intuitive rules visualization GUI: Service providers are empowered to quickly and easily create and modify rules in house, without the need to understand detailed programming. This eliminates dependency on vendors or system integrators, reducing costs and time Excellent flexibility: Offering a wide range of service provider-specific use cases, A.R.T. provides the flexibility benefits of a general-purpose rules engine without the performance issues. Users can configure, test and deploy a new set of rules in minutes High performance: A.R.T. enables high performance across massive subscriber and session scale for a new breed of complex use cases Powerful operation and maintainability: Specifically tailored for service providers, A.R.T. reduces time and costs to operate, install, upgrade, troubleshoot and debug the system and associated rules. To find out more about Nokia s revenue management solution and A.R.T., please visit our website at Acronyms A.R.T. BSS DDE DRA DSC HSS IMS IoT LTE MME OCS OSS PGW Agile Rules Technology Business Support System Dynamic Diameter Engine Diameter routing agent Dynamic Services Controller (formerly Alcatel-Lucent 5780 DSC) Home Subscriber Server IP Multimedia Subsystem Internet of Things Long Term Evolution Mobility Management Entity Online Charging System Operations Support System PDN gateway 8 White paper

9 PCRF QoS SLF SPS TPS Policy and Charging Rules Function Quality of service Subscriber Location Function Smart Plan Suite Trans per second Nokia is a registered trademark of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. Nokia Oyj Karaportti 3 FI Espoo Finland Tel (0) Product code: SR EN (September) 2017 Nokia nokia.com