/
...
Using Rule Engines
in Telco
June 2016
/
...
Contents
1. Why so many change requests?
2. Vendor’s “standard” way of handling configurability / flexibility
3. A new approach: Rules Engines
4. Rules Engines in telco: References
/
...
Why So Many Change Requests?
01
/
...
acceptance
&
go live
cost
evaluation
Initial
Business Need
building
selection
department
requirements
and
approval
/
...
approval
acceptance
&
go live
Updates on the
Business Needs
time and
cost
estimationrequirements
to the Vendor
evaluation
building
/
...
Flexibility vs Cost vs Ease of Use
/
...
Vendor’s “standard” way of handling
configurability / flexibility
02
/
...
Configurable Product
XML-Based
/
...
Configurable Product
Proprietary Rules Structure
/
...
Configurable Product
Decision Tree
/
...
Configurable Product – Flexibility
What Is the Problem?
> Flexible products have one thing in common: the proprietary means of
configuration (file based or GUI) which often leads to vendor being asked to
make configuration changes.
/
...
A New Approach
Rules Engines
03
/
...
Why Rules Engines?
> Designed specifically for processing rules:
• Extremely fast
• Very flexible
> Available for many years, hence reliable:
• CLIPS
• DROOLS
> Open products:
• There is a community around them
• Easy integration on all popular programming languages (Java, C/C++/C#, PHP)
• Not vendor specific
/
...
How Can Rules Engines Help?
> Design the application to “Externalize” the decision making process by
using a Rules Engine and defining the Business Logic in the rules definition
> ALL available information must be passed to the rules engine (even if some
information is not currently needed)
Decode
message
Context Data
Management
Application
Business Logic
Encode
message
Rules Engine
Rules Files
Incoming
Message
Outgoing
Message
Simplified version of a
Rules Engine integration
Data 1
Data 1
Context Data for current
message = Data 2
Data 1
and
Data 2
Data 1
and
Data 2
Data 3
Business Decision
(not just one field)
/
...
Rules Engines in Telco
Reference 1: SMS Router
04
/
...
SMS Router
What the Customer Wanted
> The customer wanted a system which:
• Can accept connections from multiple service providers
• Is able to route SMSes to right Service Provider based on the destination
number
• Charges the subscriber based on the destination Short Code of the SMS
• Restricts access to certain Short Codes for prepaid subscribers
> An SPR (Subscriber Profile Repository) could be queried based on
MSISDN to retrieve information about the customer:
1. Prepaid/Postpaid
2. Corporate Customer / Private Subscriber
3. Customer address (only for postpaid subscribers)
/
...
SMS Router
The Proposed Solution
SMPP
Decoder
SPR Adapter
SMS Router
Logic
SMPP
Encoder
Rules Engine
Rules Files
SMSC
Subscriber
Profile
Repository
SP 1
SP n
Convergent
Billing System
.
.
.
.
SMPP
Get Subscriber
Info
Subscriber
Info
SMS Information
SPR Information
Selected Serv. Prov.
Billing Info
/
...
SMS Router
The Rules
> ALL available information from SMPP (the SMS) and from SPR
(customer info) is passed to the rules engine
• SMPP: Originator Address, Destination Address, Encoding Language,
SMS Text, …
• SPR: Pre or Postpaid, Corporate or Individual, Address
Rules Engine:
Drools – Table Based
/
...
SMS Router
The Change Request
The customer’s initial request
> A system which:
• Can accept connections from
multiple service providers
• Is able to route SMSes to the right
Service Provider based on the
destination number
• Charges the subscriber based on
the destination Short Code of the
SMS
• Restricts access to certain Short
Codes for prepaid subscribers
Later requests
> Share a short code between
different Service Providers based on
the first word of the SMS text
> Restrict the access of corporate
subscribers to certain short codes
/
...
SMS Router
The Change Request Simple Solution
> Taking advantage of the information passed to the rules engine was not
restricted to the initial need
> The new functionality was implemented by only updating the rules
• SMPP: Originator Address, Destination Address, Encoding Language, SMS Text,
…
• SPR: Pre or Postpaid, Corporate or Private, Address
/
...
Rules Engines in Telco
Reference 2: SS7 Firewall
05
/
...
SS7 Firewall
What the Customer Wanted
> The customer wanted a system which:
• Intercepts incoming traffic from SS7 interconnect partners;
• Allows legitimate traffic to go through and rejects malicious messages (as
specified by GSMA IR.82);
• Allows detection of new type of attacks, not known at RFP date;
• Does not restrict them in setting up commercial agreements with partners
(e.g. MVNOs);
• Is able to handle 10,000 TPS;
/
...
SS7 Firewall
The solution
SS7 Firewall
MAP REQUEST
 CgPA
 CdPA
 [MAP Parameters]
In-memory
data store
Rule engine
 Get
context data
 Determine treatment
 of current request
Action
> Rules Engine decides if a message is a valid one or an attack;
> The Rules Engine receives information from:
1. The incoming message from SCCP, TCAP and MAP layers;
2. The context of the message (for sessions);
3. External sources of information (HLR which provides the real subscriber
location)
/
...
SS7 Firewall
Rules examples
Handling of ISD (Insert Subscriber
Data) according to GSMA IR.82 ->
reject all incoming traffic for own
IMSI ranges.
; IF (OpCode=ISD AND IMSI=22610*) THEN
Reject+Alarm
(defrule rule-for-prod-2p
(ParamInMAP (opCode "7"))
(ParamInMAP (IMSI “22610*"))
=>
(reset)
(assert (ParamOut (action 3)
(sendAlarm 1) (alarmAdditionalInfo "Reject:
ISD and within own IMSIs range"))))
The customer wanted to have an MVNO
using interconnect links which should be
considered as “own network”.
By passing all available info to the rules
engine, this requirement is solved with a
simple rule modification.
(defrule rule-for-prod-2p
(ParamInMAP (opCode "7"))
(ParamInMAP (IMSI “22610*"))
(not (ParamInSCCP (CgPA “4012234567890")))
=>
(reset)
(assert (ParamOut (action 3) (sendAlarm 1)
(alarmAdditionalInfo "Reject: ISD and within own
IMSIs range"))))
/
...
Rules Engines in Telco
Reference 3: Real-Time Antifraud System
06
/
...
Real-Time Antifraud System
What the Customer Wanted
SYSTEM
Identify
potential
frauds on the
voice calls
Easy
modification
of the
parameters
involved in
fraud
detection
Add new
scenarios
Multiple
operators in
the group
/
...
Real-Time Antifraud System
Architecture
/
...
Real-Time Antifraud System
The Rules
/
...
/
Thank
you!
contact@computaris.com
[+44]20.7193.9189
www.computaris.com
/
Software is
in the details
/
razvan.rusu@computaris.com

The benefits of using the rules engine paradigm in telco systems

  • 1.
  • 2.
    / ... Contents 1. Why somany change requests? 2. Vendor’s “standard” way of handling configurability / flexibility 3. A new approach: Rules Engines 4. Rules Engines in telco: References
  • 3.
    / ... Why So ManyChange Requests? 01
  • 4.
  • 5.
    / ... approval acceptance & go live Updates onthe Business Needs time and cost estimationrequirements to the Vendor evaluation building
  • 6.
  • 7.
    / ... Vendor’s “standard” wayof handling configurability / flexibility 02
  • 8.
  • 9.
  • 10.
  • 11.
    / ... Configurable Product –Flexibility What Is the Problem? > Flexible products have one thing in common: the proprietary means of configuration (file based or GUI) which often leads to vendor being asked to make configuration changes.
  • 12.
  • 13.
    / ... Why Rules Engines? >Designed specifically for processing rules: • Extremely fast • Very flexible > Available for many years, hence reliable: • CLIPS • DROOLS > Open products: • There is a community around them • Easy integration on all popular programming languages (Java, C/C++/C#, PHP) • Not vendor specific
  • 14.
    / ... How Can RulesEngines Help? > Design the application to “Externalize” the decision making process by using a Rules Engine and defining the Business Logic in the rules definition > ALL available information must be passed to the rules engine (even if some information is not currently needed) Decode message Context Data Management Application Business Logic Encode message Rules Engine Rules Files Incoming Message Outgoing Message Simplified version of a Rules Engine integration Data 1 Data 1 Context Data for current message = Data 2 Data 1 and Data 2 Data 1 and Data 2 Data 3 Business Decision (not just one field)
  • 15.
    / ... Rules Engines inTelco Reference 1: SMS Router 04
  • 16.
    / ... SMS Router What theCustomer Wanted > The customer wanted a system which: • Can accept connections from multiple service providers • Is able to route SMSes to right Service Provider based on the destination number • Charges the subscriber based on the destination Short Code of the SMS • Restricts access to certain Short Codes for prepaid subscribers > An SPR (Subscriber Profile Repository) could be queried based on MSISDN to retrieve information about the customer: 1. Prepaid/Postpaid 2. Corporate Customer / Private Subscriber 3. Customer address (only for postpaid subscribers)
  • 17.
    / ... SMS Router The ProposedSolution SMPP Decoder SPR Adapter SMS Router Logic SMPP Encoder Rules Engine Rules Files SMSC Subscriber Profile Repository SP 1 SP n Convergent Billing System . . . . SMPP Get Subscriber Info Subscriber Info SMS Information SPR Information Selected Serv. Prov. Billing Info
  • 18.
    / ... SMS Router The Rules >ALL available information from SMPP (the SMS) and from SPR (customer info) is passed to the rules engine • SMPP: Originator Address, Destination Address, Encoding Language, SMS Text, … • SPR: Pre or Postpaid, Corporate or Individual, Address Rules Engine: Drools – Table Based
  • 19.
    / ... SMS Router The ChangeRequest The customer’s initial request > A system which: • Can accept connections from multiple service providers • Is able to route SMSes to the right Service Provider based on the destination number • Charges the subscriber based on the destination Short Code of the SMS • Restricts access to certain Short Codes for prepaid subscribers Later requests > Share a short code between different Service Providers based on the first word of the SMS text > Restrict the access of corporate subscribers to certain short codes
  • 20.
    / ... SMS Router The ChangeRequest Simple Solution > Taking advantage of the information passed to the rules engine was not restricted to the initial need > The new functionality was implemented by only updating the rules • SMPP: Originator Address, Destination Address, Encoding Language, SMS Text, … • SPR: Pre or Postpaid, Corporate or Private, Address
  • 21.
    / ... Rules Engines inTelco Reference 2: SS7 Firewall 05
  • 22.
    / ... SS7 Firewall What theCustomer Wanted > The customer wanted a system which: • Intercepts incoming traffic from SS7 interconnect partners; • Allows legitimate traffic to go through and rejects malicious messages (as specified by GSMA IR.82); • Allows detection of new type of attacks, not known at RFP date; • Does not restrict them in setting up commercial agreements with partners (e.g. MVNOs); • Is able to handle 10,000 TPS;
  • 23.
    / ... SS7 Firewall The solution SS7Firewall MAP REQUEST  CgPA  CdPA  [MAP Parameters] In-memory data store Rule engine  Get context data  Determine treatment  of current request Action > Rules Engine decides if a message is a valid one or an attack; > The Rules Engine receives information from: 1. The incoming message from SCCP, TCAP and MAP layers; 2. The context of the message (for sessions); 3. External sources of information (HLR which provides the real subscriber location)
  • 24.
    / ... SS7 Firewall Rules examples Handlingof ISD (Insert Subscriber Data) according to GSMA IR.82 -> reject all incoming traffic for own IMSI ranges. ; IF (OpCode=ISD AND IMSI=22610*) THEN Reject+Alarm (defrule rule-for-prod-2p (ParamInMAP (opCode "7")) (ParamInMAP (IMSI “22610*")) => (reset) (assert (ParamOut (action 3) (sendAlarm 1) (alarmAdditionalInfo "Reject: ISD and within own IMSIs range")))) The customer wanted to have an MVNO using interconnect links which should be considered as “own network”. By passing all available info to the rules engine, this requirement is solved with a simple rule modification. (defrule rule-for-prod-2p (ParamInMAP (opCode "7")) (ParamInMAP (IMSI “22610*")) (not (ParamInSCCP (CgPA “4012234567890"))) => (reset) (assert (ParamOut (action 3) (sendAlarm 1) (alarmAdditionalInfo "Reject: ISD and within own IMSIs range"))))
  • 25.
    / ... Rules Engines inTelco Reference 3: Real-Time Antifraud System 06
  • 26.
    / ... Real-Time Antifraud System Whatthe Customer Wanted SYSTEM Identify potential frauds on the voice calls Easy modification of the parameters involved in fraud detection Add new scenarios Multiple operators in the group
  • 27.
  • 28.
  • 29.