The presentation discusses the benefits of implementing the rule engines in telecom IT systems to achieve high solution flexibility, ease of use and cost effectiveness for the operators. It also shares from the Computaris experience with implementing open source products such as CLIPS and DROOLS in telecom projects including SMS router, SS7 firewall, real time antifraud systems.

1. /
...
Using Rule Engines
in Telco
June 2016

2. /
...
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

3. /
...
Why So Many Change Requests?
01

4. /
...
acceptance
&
go live
cost
evaluation
Initial
Business Need
building
selection
department
requirements
and
approval

5. /
...
approval
acceptance
&
go live
Updates on the
Business Needs
time and
cost
estimationrequirements
to the Vendor
evaluation
building

6. /
...
Flexibility vs Cost vs Ease of Use

7. /
...
Vendor’s “standard” way of handling
configurability / flexibility
02

8. /
...
Configurable Product
XML-Based

9. /
...
Configurable Product
Proprietary Rules Structure

10. /
...
Configurable Product
Decision Tree

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. /
...
A New Approach
Rules Engines
03

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 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)

15. /
...
Rules Engines in Telco
Reference 1: SMS Router
04

16. /
...
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)

17. /
...
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

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 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

20. /
...
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

21. /
...
Rules Engines in Telco
Reference 2: SS7 Firewall
05

22. /
...
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;

23. /
...
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)

24. /
...
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"))))

25. /
...
Rules Engines in Telco
Reference 3: Real-Time Antifraud System
06

26. /
...
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

27. /
...
Real-Time Antifraud System
Architecture

28. /
...
Real-Time Antifraud System
The Rules

29. /
...
/
Thank
you!
contact@computaris.com
[+44]20.7193.9189
www.computaris.com
/
Software is
in the details
/
razvan.rusu@computaris.com