Latest News

In case you missed it, HERE is the first part of jIN description.

jIN SLEE – what exactly is it?

jtendo Intelligent Network Service Logic Execution Environment is the environment for any kind of application that communicates with telecommunication environment. Based on GSMA and OMA standards, it is designed to be compatible with mobile and fixed networks. Moreover, it can be easily extended with additional platform components. Here are the examples of protocols our solution supports:

• SS7 (MAP/CAP/INAP/ISUP)
• SIP
• Diameter
• SMPP
• Web Services
• MM7
• CORBA
• SQL
• LDAP

There are two alternative versions of jIN SLEE

The first is based on Metaswitch (formerly OpenCloud, now part of Microsoft company) Rhino TAS server, which is one of the better implementations of JSLEE standard.

I am sure you have heard about JSLEE – JAIN SLEE, which actually stands for “Java APIs for Integrated Networks” (fully described here) and “Service Logic Execution Environment” (fully described here).

The second is called inSOA and is a different approach to environment composition. It was created by jtendo team, based on our experience and our vision of IN future.

inSOA is an idea that we have brought to life

Although we cannot take all the credit for it, as it was created on many existing concepts like OSA/Parlay, JSLEE, NFV, we are proud to have forged something new. inSOA consists of two major layers, but as it is with a good cake, there can be more and more layers…

The base is a Web Services Gateway. This is a set of, what we call, Service Capability Functions (I am sure you have noticed a resemblance to Parlay here). These are OneAPI/OMA Web Services – main interfaces for particular network functions. Like Call Control over CAP, or SMS handling over SMPP, or SMS handling over MAP, there is no limits (…endless flexibility…). Here is an infographic of SCFs subset we are offering.

It is in any way limited as all the components are separated and anyone can add his own! We have built most of them in Erlang.

Btw, we are Erlang freaks. There is nothing stopping the operator (or any vendor) to add to this architecture their own elements.

Then there is a Web Services Exposition Layer. Optional, though it allows to expose network capabilities in a safe and manageable manner to the Internet or to the internal applications. This is a wide topic which I will cover in another post. For now, let us just say – it covers security, authentication, authorization (down to methods and parameter values level), policy control, charging and accounting. Everything in a time regime that allows you to run real telco applications (so tens of milliseconds, not seconds…).

App ecosystem architecture

And for the application environment? Well, you probably see it right now. Since the Web Services Gateway exposes all network capabilities via Web Services, it might be just any kind of Web Server! Yup. Nothing more needed. However, why reinvent the wheel and keep creating the same functions over and over with the same application? This is why we have added “common components”, like a set of libraries, to simplify the development and application management.

The set consists of:

• CDR facility – allows all applications to use the same library to generate CDRs. ANS.1? Text-based? XML? Now, it is just a matter of setting a proper CDR facility configuration for particular service.
• Statistics facility – all the apps should generate statistics – let us use a common component, so that all of it lands in a pre-configured #ElasticSearch (we love it SOOOOOO much!) database, which can be easily viewed using #kibana?
• SNMP facility – for on-line integration with OSS monitoring environment., Let us have it managed centrally (thresholds, severity, you know what I am talking about…).
• Logging facility – all apps logging configuration should be managed via one single GUI, no point in providing app management via different portals… There are logs viewing, filtering, configuring retention, logging severity, etc. Each application requires appropriate configuration which can be done by a single Operation & Management GUI.
• Config facility – each service needs to be configured. Let us store it in a single DB and again, let’s have centralized management.
• VNF Manager facility – apps need to be able to scale up, scale down, get notifications about resource change etc.
• Session replication facility – some apps need to use session replication for session failover. Using this component simplifies the management of cluster data replication.

That was a lot of information for one post… We would be really honored if you (vendor or operator) would like to learn more about our concept and implementation (which is proven to handle more than 1000 TPS per single instance). Please get in touch with us! We will be more than happy to present our inSOA Solution.