Wednesday, June 7, 2017

Radiator VNF – meeting the standards

Radiator – interoperability in NFV world

Radiator is known for its interoperability and flexibility and from the very beginning, Radiator VNF is meant to be similar. In order to make it so, we have built Radiator VNF to meet the industry standards, such as NFV release 1 by the European Telecommunications Standards Institute (ETSI). Radiator VNF follows the ETSI standard architecture as shown below.

Radiator VNF architecture

Of course, meeting the NFV release 1 standard is not enough for us. There are new releases coming, such as ETSI NFV release 2 published in autumn 2016. Our development team has been working to make Radiator VNF to meet this standard and the development goes on. The NFV release 2 added several new specifications to the previous release: various requirements and instructions for resilience, service quality metrics, management, orchestration, security, and many, many more.

Meeting these standards and constant development means that Radiator VNF customers can trust their solution to be interoperable now and in the future. This helps both our integrator partners and customers in their mission to have the best components for different needs in their infrastructure.

Meeting standards – more benefits for markets

When the vendors ensure that their software follows the NFV standards, the market will run better, too. The customers, such as telcos, can choose the components from the wide range of products without a fear for a vendor lock-in. This makes the NFV markets to mature more rapidly. Additionally, the technology itself matures and can deliver the promised benefits. More information about this is available in the industry report by SDx Central.

We in Radiator team are committed to deliver the NFV promise and Radiator’s well-known interoperability in the new Radiator VNF. Contact our sales team at to get more information about our Radiator VNF solution.

Friday, May 12, 2017

Radiator 4.18 now available!

We have published the updated version of Radiator, please meet brand new Radiator 4.18!

There are lots of enhancements and bugfixes in Radiator 4.18. Some are small, some bigger but nothing really major. The main improvements include:
  • Several security fixes
  • Enhanced logging and debugging features
  • New modules for accounting handling
  • Automatic rejection of empty passwords and some types of invalid user names
  • AuthenProto parameter for setting the allowed authentication methods
  • Several EAP enhancements

The detailed list of changes is available on Radiator revision history.

Thursday, May 4, 2017

Radiator SIM Pack updated - version 2.1 available!

We are happy to announce that new Radiator SIM Pack version 2.1 is now available!

This is mainly an enhancement and bugfix release with some minor new features. We have fixed several small issues and improved all SIM authentication methods, 3GPP AAA Server and SIGTRAN interoperability and compatibility with different vendors’ devices. Many of these improvements are based on customer requests for new features and enhancements. In addition to new interoperability features, SIGTRAN support was updated with a number of configuration options that are useful for making sure Radiator fits your existing SIGTRAN environment.

Radiator SIM Pack 2.1 requires Radiator AAA Server version 4.16 or later. Some features, such as using 3GPP AAA Server and LocalAddress or LocalPort parameters, require Radiator 4.17 or later. The complete list of changes is available on the revision history page.

Friday, April 7, 2017

Radiator VNF 2017 release components

Radiator VNF consist of independent components. The modular architecture enables the Radiator VNF system to be flexible, scalable, and configurable. The basic components are:

  • Worker
  • Loadbalancer
  • Control
  • Management
  • BEDBINT (Backend Database Interface)

The image below shows their relations:


As the name indicates, the worker component does all the work: it processes the incoming RADIUS and Diameter messages. It provides the actual business logic and its functions, such as:

  • Radiator VoWiFi
  • Radiator Service Provider Wi-Fi
  • Radiator PCRF
  • Radiator OCS
  • Radiator Custom/OEM

Radiator AAA Core is the mandatory main module. It depends on the wanted functionality which other modules are necessary.

When workers are instantiated, they send their availability information to the loadbalancer through redundant message queue. Workers do not communicate directly with the external clients.


Loadbalancer receives the incoming RADIUS and Diameter messages and forwards them to the workers. It also takes care of balancing the workers' load, the control component sends the workers' availability information to loadbalancer so that loadbalancer always has an up-to-date list of available workers. Loadbalancer is stateless from RADIUS and Diameter perspective


Control component's most important task is to provide the redundant message queue, which all other components use for communicating with each other. Inter-component communicating is extremely important in Radiator VNF, for example, scaling the system would be impossible without it. The workers sign up to the control component when they are initialised and the control component sends worker information to the loadbalancer. Also component shutdowns are informed to the control component.

The control component acts also as a data storage, it stores non-persistent session data and persistent data, such as IP addresses, prefixes, and pools. The control component is not stateless. The control component also maintains real-time user session data and provides that data to the workers and management component. The persistent data is stored in ACID-compliant storage.


The management component holds the statistics and logging data. It also provides services which handle session cleaning and other management tasks, such as logs and statistics.


BEDBINT connects Radiator VNF to the external backend systems. Depending on the configuration, these backend systems can be one of the following:

  • Customer LDAP (Lightweight Directory Access Protocol)
  • SQL
  • HSS (Home Subscriber Server)

BEDBINT includes a caching function that stores customer and configuration information. It also supports the overload protection mechanisms, scaling, and self-healing.

Do you want to know more?

Radiator VNF release 2017 will be commercially available soon. In case you are interested in Radiator VNF solutions, please contact We are happy to tell you more about Radiator VNF, and assist you with your NFV and AAA project with Radiator solutions.

Tuesday, January 10, 2017

DevOps and Radiator, part 1

With the first release of the Radiator VNF coming this year, it is a good time to take a quick look at the DevOps model, how we have embraced it, and how it will be on the center of the stage in Radiator VNF.

This post tells you a bit about DevOps in general and an example of a Chef cookbook follows after it. Radiator VNF's configuration management will be discussed in later blog posts.

What is DevOps?

You get multiple different answers when searching for clues behind the portmanteau: DevOps. Sure, it's a merging of development and operations. Possibly, it's also a bunch of different tools. Or, you might describe it as a change in the processes of an organisation.

Combining all these, DevOps can be described as a cultural change in the organisation. It's not something you purchase from the store and sprinkle on top of your employees.

DevOps emphasises communication between different parts of the organisation and pushes the processes to be more automated and agile. Changes to the software or configuration are planned, made, tested, deployed, and monitored in a continuous, automated way.

DevOps toolchain by Kharnagy, CC BY-SA 4.0, original
Compared to the old way of divided silos and huge, rarely-made releases with massive change logs, this model encourages making smaller changes, testing them swiftly, and deploying often. Stronger collaboration between developers and operators and a faster, automated cycle improve reliability.

Especially in a flexible and distributed cloud environment, this new approach is needed. Otherwise, it is very difficult for a single operator to manually handle thousands of nodes. The tools grant you the possibility of easily having identical environments with slightly different parameters. With automation, there's no more forgetting to run that command and changing those addresses when manually moving from testing to QA to production.

For us, the shift to a DevOps culture in the customer base means that we also support the DevOps tooling and make it easier for our customers to deploy Radiator with automated configuration management systems. In the Radiator VNF, the whole infrastructure is managed automatically.

Chef, tool for DevOps

Chef is a set of tools developed by a company with the same name. There are several similar tools available, such as AnsiblePuppet and SaltStack among others, so you will find suitable a DevOps-tool for your particular use case.

Chef uses Ruby to describe the infrastructure as code. This means that the configuration of the infrastructure, from the operating system level to the running software services, and their configuration, can be written as Ruby code and then tested like any piece of software.

In Chef terms, the user writes cookbooks which consist of recipes. For example, a cookbook describes a software with different recipes for installation, configuration, and starting the services. The power lies in the community that has written thousands of cookbooks for various tasks. For example, you don't have to write your own cookbooks to install nginx and configure a website. Just download ready-made cookbooks like chef_nginx and configure them to suite your needs.

By using cookbooks, you can describe your whole infrastructure. The cookbooks can be unit tested, integration tested, and after deployment you can ensure compliance with rules of your organisation.

Short Chef example

As an example and sneak peek for the next post on this theme, here is a quick introduction on Chef cookbooks. These snippets are not complete, but show some features that are used to describe installing Radiator, creating some necessary directories, and starting the service.

If you want a longer introduction on Chef attributes, recipes, and resources, have a look at the tutorials.

name 'radiator'
maintainer 'Arch Red Oy'
version '0.6.2'

depends 'perl', '~> 4.0.0'
depends 'poise-service', '~> 1.4.1'

supports 'ubuntu', '= 16.04'
supports 'centos', '= 7.2'

default['radiator']['install']['version'] = '4.17'
default['radiator']['install']['method'] = 'archive'
default['radiator']['install']['directory'] = '/opt/radiator'

install_method = node['radiator']['install']['method']

poise_service_user 'radiator' do
  group 'radiator'
  home node['radiator']['user_home'] unless node['radiator']['user_home'].nil?
  shell node['radiator']['user_shell'] unless node['radiator']['user_shell'].nil?

%w(/var/run/radiator /var/log/radiator).each do |dir|
  directory dir do
    owner 'radiator'
    group 'radiator'

unless install_method.nil? || install_method == 'skip'
  include_recipe "radiator::install_#{install_method}"

case install_method
when 'package'
  radiusd_bin = '/usr/bin/radiusd'
  dictionary_files << '/etc/radiator/dictionary'
when 'archive', 'evaluation'
  radiusd_bin = '/usr/local/bin/radiusd'
  radiusd_includes << node['radiator']['install']['directory']
  dictionary_files << node['radiator']['install']['directory'] + '/dictionary'

unless node['radiator']['options']['dictionary_source'].empty?
  dictionary_files << '/etc/radiator/' + node['radiator']['options']['dictionary_file']

radiusd_params = ['-foreground', '-config_file /etc/radiator/' + node['radiator']['options']['config_file'],
                  '-dictionary ' + dictionary_files.flatten.join(','),

radiusd_includes = [node['radiator']['options']['radiusd_includes'], radiusd_includes] { |inc| "-I #{inc}" }

perl_bin = '/usr/bin/env perl'
radiusd_command = [perl_bin, radiusd_includes, radiusd_bin, radiusd_params].flatten.join(' ')

poise_service 'radiator' do
  command radiusd_command
  user 'radiator'
  directory '/etc/radiator'
  subscribes :restart, "template[/etc/radiator/#{node['radiator']['options']['config_file']}]"

Wednesday, December 21, 2016

Coming up: Radiator VNF 2017 release

During 2016 we have been developing Radiator VNF together with our partners and customers in order implement a true unified vAAA solution. As year is closing to end, we are happy to tell a bit about the Radiator VNF and Radiator VNF Manager and the Radiator VNF 2017 release.

What is Radiator VNF?

Radiator VNF is a true NFV solution: it handles the virtualisation process automatically. The VNF manager scales and configures the virtual servers without human interaction. The scaling is based on KPIs (Key Performance Indicators), which the Radiator VNF system produces. Scaling does not compromise service reliability, there are no interruptions in service when scaling the system. Radiator VNF Manager configures automatically all the new instances.

Radiator VNF is a hardware-independent solution. This provides easy integration for Radiator VNF and makes it truly portable into different environments. The Radiator VNF 2017 release is provided for Openstack API.

Performance and scaling

Implementing the AAA system in a virtualised environment provides good scaling possibilities and high performance with lesser resources. Virtualisation allows better utilisation of the hardware layer and improves the application availability. Scaling and better performance is achieved without adding more hardware resources. The scaling process in Radiator VNF is modular, each VNF component is scaled separately according to the traffic needs.

This approach provides possibilities to optimise the scaling and resource usage for each component.

Additional key features

In addition to all the benefits of true NFV approach of Radiator VNF, we have listed some additional key features for Radiator VNF 2017 release:

  • Fault management 
    • If some kind of an error situation occurs, VNF components try to recover from it automatically.
  • Data analysing and visualisation tools
    • Radiator VNF provides interfaces for log graphical tools, which analyse the log data and create diagrams about system usage
  • Testing tools 
    • Radiator VNF package contains ready templates for testing tools - available when needed. 
  • Manual scaling 
    • Radiator VNF provides a possibility to scale the system also manually.

Do you want to know more?

Radiator VNF release 2017 will be commercially available during Q2/2017. In case you are interested in Radiator VNF solutions, please contact . We are happy to tell you more about Radiator VNF, and assist you with your NFV and AAA project with Radiator solutions.

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.