Thursday, September 29, 2016

Make your Radiator log data searchable, part 2

This is the second part of blog series that helps you to use the log data that Radiator generates.

In the first part of blog series, we configured Radiator to export data in JSON format. This part shows some basic examples about utilising that data.

The setup introduced in blog series part 1 is running and it produces log data in JSON format. The JSON data is forwarded to an analysis tool. In this case, we use Elastic Stack and its visualisation tool Kibana for analysing the sample data. For more information about Elastic Stack, see The Elastic Stack website. Configuring the data forwarding depends on the chosen tool and it is not discussed in this blog post.

This image shows how the log data is processed when using Elastic Stack for analysing:

radpwtst tool, which is included in Radiator distribution, is used as a RADIUS client. Thus, it authenticates via RADIUS and Radiator logs authentication attempts as entries to authlog.json file. Here is a sample of one authentication entry as shown in the JSON file:


The name-value pairs are not ordered in any way so they are hard to read as such. To get a better idea of the data, it must be parsed. One option is to use configuration variable for the plaintext output, it is feasible to use, at least in the testing phase. This helps to verify that the data is correctly interpreted by Elastic Stack.

Visualising log data with Kibana

Elastic Stack parses the data so we can explore the contents in Kibana. Part of our sample data looks like this in Kibana:

By clicking each entry open, we can verify that all name-value pairs are distinguished. By default, each name-value pair is indexed and searchable, and if you add new fields to the JSON data, Elastic Stack indexes them automatically. They are parsed and usable in your searches without need for other modifications. This enables searching of wide variety of name-value pairs and their combinations.

Kibana shows the amount of entries in each time window. By filtering everything else but authentication-related entries, we see trends in amount of authentication attempts.

Similarly, we can create visualisation of access/reject rate within a certain time frame.

Do you want to know more?

There will be examples of more detailed JSON use cases in the blog. If you have questions, contact Radiator team at – we are happy to help you to have more benefits of your log data.

Monday, September 12, 2016

Utilising Radiator when evolving to 4G/LTE

One of the Radiator use cases is evolving your infrastructure for 4G/LTE features. Some of our customers already provide prepaid data plans in 3G/CDMA network but now they need to provide also 4G/LTE features for their subscribers. At the same time, being able to use the parts of the current infrastructure saves network operator’s money and time.

Radiator’s flexibility has a lot to offer for this kind of use case. You can choose any vendor for your LTE core network and Radiator will work seamlessly with it, thanks to Radiator’s multi-vendor support.

With Radiator, the same functionalities that have been implemented in 3G/CDMA network with RADIUS interfaces before, can now be implemented in 4G/LTE network with Diameter interfaces. You only need to replace your current RADIUS server with Radiator Telco Pack that provides all the needed features.

Radiator makes it also possible to use the existing customer data plans and business logic when updating for example from CDMA to LTE. For this integration, Radiator communicates with the original billing system using SQL or LDAP interfaces, among others. At the same time, Radiator uses Diameter interfaces, such as Gy, for integrating with LTE network infrastructure. See the picture below for basic layout.

Do you want to know more?

If you are interested in this kind of solution for your network, please do not hesitate to contact our sales team We and our worldwide partner network are happy to provide you assistance in your project.