the benefits of using the rules engine paradigm in telco systems
Post on 16-Apr-2017
188 Views
Preview:
TRANSCRIPT
/
...
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
InitialBusiness Need
building
selection
department
requirements
and
approval
/
...
approval
acceptance
&
go live
Updates on theBusiness Needs
time and
cost
estimationrequirements
to the Vendor
evaluationbuilding
/
...
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 – FlexibilityWhat 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 ApproachRules 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 1and
Data 2
Data 1and
Data 2
Data 3Business Decision(not just one field)
/
...
Rules Engines in TelcoReference 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
DecoderSPR Adapter
SMS Router
Logic
SMPP
Encoder
Rules Engine
Rules Files
SMSC
Subscriber
Profile
Repository
SP 1
SP n
Convergent
Billing System
.
.
.
.
SMPP
Get SubscriberInfo
Subscriber Info
SMS InformationSPR 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 RouterThe 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 TelcoReference 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 FirewallThe solution
SS7 Firewall
MAP REQUEST
CgPA
CdPA
[MAP Parameters]
In-memory
data storeRule 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 FirewallRules 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 TelcoReference 3: Real-Time Antifraud System
06
/
...
Real-Time Antifraud SystemWhat 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 SystemArchitecture
/
...
Real-Time Antifraud SystemThe Rules
/
...
/Thankyou!
contact@computaris.com
[+44]20.7193.9189
www.computaris.com
/Software is in the details
/razvan.rusu@computaris.com
top related