So, hi everyone, my name is Dan, I'm here to talk you about something which becomes more
boring these days, just another attempt of thought prevention, but I'm sure it should not
be your case because your network is secure.
So it's just I know I heard it happen to someone else, nothing to have panic about.
About our company we will keep again because by now everybody should know that we are
the smartest producing the most stable software, you know, so I have to skip ahead because
of the timing.
I want to talk about cigarettes, what is cigarettes?
It's an enterprise billing suite, we call it like that in the end, it's a framework.
It's started as an online charging system and OCS, what people are calling in telecom
and it evolved towards a framework of different services and they are all related.
So it's not that we are keep putting functionality inside because we don't know what to do in
our spare time, it's because the things are asking for each other.
It's all open source, born in 2010, published in 2012, full sources are available on GitHub,
100% gop, so imagine in 2010 when we started gop was kind of weekly release, so we might
be the oldest goline developers, you know.
No add-ons in private repositories and by now we have more than 400,000 lines of code which
in gop which being a compact language, it's quite some functionality there and we do have
consideration for community contributions.
We support actively three branches which became like three versions of software nowadays.
It's performance oriented because we started as an OCS and it has a modular architecture
so you can take components out, put your own should not, should you want to avoid the licensing
problems.
Test driven development software so we like to write tests before or write after we have done
the functionality.
What can you do with it?
Online charging system is the classic thing we started with, you have a lot of things like
complex rating, bundles for online it works in mobile networks, we also work in tier 1,
MNOs, high number of interfaces in and out so you can integrate it with quite some number of
appliances there, then it can work as a routing server, popular LCR systems, you know,
in with soft switches, then what I'm also about to talk about is fraud mitigation server,
you have built in mechanism and components which are focusing on detecting fraud in your network,
it's that kind of fraud related to billing stuff so we don't go into sniffing your network for
IP packets, we focus on what it comes out of your real-time events or what it comes out out
of CDRs. Statistic server, again important, it has a lot of appliances in marketing,
in routing also, in observability of your network, so we provide that kind of component as well,
resource utilization control server, so you can have virtual channels since there are no physical
channels anymore. Mediation server, if you have to enhance your CDRs and modify their content
or beaming a source which is again popular, you can do parallel billing to what you have today
or put a server there which is sniffing, this is the kind of network sniffer, producing CDRs
and checking in real-time with what you have already, if you have doubts, if your billing system works
accurate, you can add this in parallel and have the functionality. Today I did a sort of,
this is the only nice looking slide I have because as billing system we are working
some in your basement, nobody sees it, it's there and nobody wants to touch it, so this is kind
of best I could give out of myself. You can see on the left side here communication devices doing
their things, making use of your resources and producing whether real-time or CDRs, sending them
to us to all components which we call sessions and CDRs, then this sessions by processing
them will push them into another subsystem named stats. stats are built again in real-time,
but as they are, their nature is to be like only instance, so they are not available if you
want to query them, what were my stats, 10 minutes ago, you cannot because stats are always
real-time, our all components they work in memory, so because of the speed we have to do,
everything is in memory, there is no select from my screen where average coordination or
answer time was this and stuff like that, no because that one will be slow, it's not the target
we are doing, just for your information we are doing about 7,000 requests per second per unit,
so and our RPC goes up to 35,000 requests per second, so we are we are really targeting high
speeds and this stats being in the memory, we need to somehow or hide them and also make use of
the logic behind them, so this is why we wrote a new subsystem which is trends, we just push
it like a few months ago, this is the first conference where we talk about it, and this trends
will regularly query stats, it's very similar to the approach of permitios for example,
and or hide these stats in a timely manner, so in sort of time based database, it's again
all in memory, and then this trends can push information outside and that would be
to our thresholds which is the subsystem which is able to read this events from trends and take
actions on them which is part of the flow detection or they can send it to another subsystem
ES which is our event exporter, and this ES has access to many, many interfaces including
I don't know Amazon SQS, Rabbit and Q Kafka or whatever, so there are many interfaces out where
you can make use of these trends, in terms of trends it's an archiver for start metric,
it queries on interval, the start metrics and it has some fine tuning parameters like time to
leave limits on the number of metrics are high, it can be also optionally stored into a database
which usually it's no scale like radius to be again fast, and it computes the trends growth
and trend label, I'll show you in an example so you understand easier, in terms of trends
computation the metric must be numbers, you can have correlation types like average or last,
and it can be exported as I showed you towards another subsystem, this is configuration options,
but I'll skip them too because we have some sample API data which you can understand better,
so a trend profile is our configuration and it contains the schedule how often we will query the
stats, the statistics, it contains what sort of statistics will query, normally trends and
statistics profile and statistics profile they are one to one, so you can only configure here one
stat ID and you can filter what metrics you are hiring because you might not want to
to hive all the metrics, then you have a correlation type, in this case is last since we have a
queue of statistics, we need to make sure that we know what we correlate to, so it can be from the
last statistics, so the last two statistics in the past or it can be as an average between all of them
and then it can be, it can have a tolerance when issuing the label and it can call the threshold
in order to have some detection mechanism for the fraud, this is an example of trend, how a trend
looks like, then you see it runs at points in time and then it hives at each of these points
in time, it hives some metrics, in this case it did average correlation, it has a value,
unknown trend growth, so minus one means unknown and unknown trend label and if you, if we watch the
second trend run we already see a trend growth, this means minus 48 percent, so the average
correlation went down and a positive, so a trend growth of 150 percent for the total call cost,
so this by sending this event to the thresholds, we can already make sense of them for the
fraud saying that if the trend label is negative and for for average correlation and trend label for
total call cost is positive, something is wrong, they don't match up anymore, so to us it says
we have to either look on it or escalate or take actions and just to see I was not afraid about
your shield, I finished, thank you very much