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 info@open.com.au . 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:



{"nas_port":"1234","source_host":"osc-dev-3","time":"1463404359","type":"authentication","timestamp":"2016-05-16T16:12:39Z","nas_identifier":"203.63.154.1","nas_ip_address":"203.63.154.1","calling_station_id":"987654321","result":"accept","username":"mikem","called_station_id":"123456789","trace_id":"43efcbe2"}



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 info@open.com.au – 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 info@open.com.au. We and our worldwide partner network are happy to provide you assistance in your project.


Tuesday, August 2, 2016

Secure your network and services with Radiator two-factor authentication

Modern services all around the Internet offer different two-factor authentication solutions. They provide stronger security than using only username and password. Two-factor authentication requires a combination of something the user knows and something the user possesses. One common combination is the username and PIN or password with a physical token, such as a specific device, smart card, or mobile phone. The two-factor secured service may range from a web service to a network device to a remote VPN (Virtual Private Network) access – wherever stronger security is needed.

Figure 1: Radiator based two-factor authentication and authorisation architecture

Radiator AAA Server Software provides flexible, interoperable, and scalable two-factor AAA (Authentication, Accounting, and Authorisation) service for any device or service, which can use RADIUS, TACACS, or TACACS+ interface for AAA. The VPN devices can authenticate remote employees, the network devices can authorise administrators, and the web services can identify the users with secure two-factor authentication. All you need is Radiator-based two-factor AAA service and a free mobile phone app, such as Google Authenticator, Microsoft Authenticator, or some other OTP/TOTP/HOTP app. The authenticator app is paired with Radiator two-factor AAA service and particular user credentials, and two-factor authentication are ready to be used.

Another major benefit of using Radiator is its legendary interoperability. Radiator can combine complementary AAA information and functions from Active Directory, LDAP, and even 3rd party two-factor services, such as RSA SecurID, YubiKey, Duo Security, and Vasco Digipass. It can check existence and validity of a user from Active Directory, retrieve a proper VPN group, perform two-factor authentication using TOTP (Time-based One-time Password Algorithm), and then combine the results to a RADIUS authentication and authorisation response, which is sent back to a Cisco ASA VPN device.

Radiator can also extend the functionalities of 3rd party two-factor authentication services by translating and complementing AAA interactions between services and devices. For example, Radiator combines fine-grained TACACS(+)- or RADIUS-based network device configuration authorisation with existing user directories and two-factor authentication. The two-factor authentication data may be retrieved from Radiator itself or some 3rd party service. With the help of Radiator’s extendable two-factor modules, Radiator also supports SMS transfer of one-time-passwords, when using tokens or authenticator app is not feasible.

Radiator and its two-factor authentication functionalities have already been deployed in several different environments such as:
  • Fortune 250 company uses Radiator for two-factor authentication of their global VPN network.
  • IT departments of world’s two top universities provide VPN service for their employees, partners, and students utilising Radiator’s capability to combine Duo Security two-factor authentication service to additional LDAP directory checks.
  • Nordic operator provides multi-function (RSA SecurID, SMS) two-factor authentication service to their enterprise customers.

Would you like to know more?

Contact our team at info@open.com.au to set up a meeting, where we can discuss how Radiator could help you in securing access to your services or network with two-factor authentication.

Monday, July 18, 2016

Flexible M2M/IoT service with Radiator and Private APN

M2M (Machine to Machine) communications, IoT (Internet of Things), and Industrial Internet are constantly bringing new connected devices, things, to the Internet. Operators and other companies already use Radiator AAA Server Software to create M2M, IoT, and Industrial Internet services to customers. Using Radiator with Private APN (access point name) is an important use case.

Figure 1: Radiator RADIUS server and Private APN service architecture

Most mobile operators provide, in addition to their own APNs, also a Private APN service for companies interested of separating their data traffic from operators’ generic subscriptions. The Private APN service utilises operator’s SIM cards for radio network access, but separates the data traffic in operator’s GGSN (gateway GPRS support node) by the access point name (e.g. internet.company instead of operator’s own access point name). These separate private access points may have their own parameters for authentication, accounting, IP networks, IP address allocation, connection parameters, traffic accounting, priorities, and other functionalities. Depending on the GGSN capabilities, it is possible to move some of these functionalities and information to a separate RADIUS service, which is provided either by the operator or company utilising the Private APN.

With the Private APN and Radiator AAA Server Software as a RADIUS service, our customers have successfully deployed M2M, IoT, and Industrial Internet solutions. Some examples are:
  • Fixed IPv4 and IPv6 address allocation for mobile operator M2M/IoT service based on MSISDN (phone number) with the option of returning any GGSN-supported subscription parameters from RADIUS to GGSN
  • Ensuring that the Australian state-wide network of water measurement devices are active and sending measurement data, and working as AAA service for VPN connection authentication for devices
  • Tracking truck locations, and authenticating, accounting, and authorising GPS tracking devices for fleet tracking service operating across several operators and European countries

Would you like to know more?

This use case is one of the many, where Radiator can be used to provide additional and complementary functionality to mobile network and Internet of Things/Industrial Internet solutions. Contact our team at info@open.com.au to set up a meeting, where we can discuss how Radiator could help you in building and deploying mobile network or IoT/Industrial Internet services and solutions.

Friday, June 17, 2016

Radiator SIM Pack, Carrier Pack and Telco Pack releases

We are happy to announce we have now new releases of Radiator SIM Pack and Telco Pack  and also the first release (v. 1.0) of Radiator Carrier Pack, which is designed to address the needs of carriers.

Radiator Carrier Pack is targeted especially for carriers: it provides the interoperability, flexibility, and performance of Radiator, and it also includes Radiator Carrier Module. This module consists of advanced Radiator Diameter server software and Diameter relay software. These provide the platform for other Radiator carrier products: Radiator SIM Pack, Radiator Telco Pack and Radiator GBA/BSF Pack.

Initial release of Radiator Carrier Pack includes following features (and more can be found from revision history):

  • The existing and new modules are reorganised. Base components from Radiator Telco Module are now included in Radiator Carrier Module.
  • DiameterTelcoConnection now calls DiaPeer's send_reply() instead of calling send() directly. This is preferred to keep the peer state machine up to date.
  • OriginHost and OriginRealm in DiaPeerDef support special formatting.
  • Diameter initiator connections are now activated after the configuration has been loaded instead of during configuration loading.

Do you want to know more?

If you like to know more about Radiator Carrier Pack and other Radiator carrier products, please do not hesitate to contact our sales team at info@open.com.au

Monday, June 6, 2016

Make your Radiator log data searchable

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


Radiator exports AAA (authentication, authorisation, accounting) data to various formats. You can process the log data further by other log collection systems, such as Splunk and Elasticsearch. In this article, we briefly describe how to export data in JSON format. The common use case is to record the metrics that best describe your environment, for example, authentication, and authorisation messages.

The image below shows you an example of visualised Radiator worker statistics. The graphics were created with Grafana. Click the image for a larger view.





Adding a new field
With Radiator, it is possible to export log data in JSON format (for more information, see JSON.org). Basically, JSON is a set of name-value pairs. The values can also be ordered lists and it is possible to nest lists inside other lists. This makes it possible to express complex data structures in an universal manner with JSON.

Usually, the hardest part in modifying configuration is to figure out how to synchronise modifications everywhere, especially if the logs are centrally collected and parsed. For example, if Client-Identifier or some other RADIUS attribute is added to a log message when authentication fails, you have to ensure the log parser engine understands the new field.

This is an example of AuthLog FILE, which has date, username, and result.

Wed May 18 15:48:44 2016:mikem:FAIL

If you add a new field, the log entry looks like this:

Wed May 18 15:48:44 2016:mikem:client-1:FAIL

Here is the same information as a default JSON message without the new field:

{"timestamp":"2016-05-18T15:48:44Z","result":"reject","source_host":"osc-dev-3","username":"mikem","type":"authentication"}

Here is the JSON message with the new field: {"timestamp":"2016-05-18T15:48:44Z","result":"reject","source_host":"osc-dev-3","username":"mikem","type":"authentication", “client”:”client-1”}
With JSON, it is easy to add the new field to Radiator log message. Usually, there is no need to modify the parser configuration since the fields are just a group of name-value pairs and not fixed together in any way.

Configuring Radiator

The configuration process is straightforward: add Log <FILE, SYSLOG, ...> clause and use it in the same way as existing ones to your Radiator config and you are done. With Radiator, you can customise your own LogFormatHook and add, remove, or modify the fields. This is how Radiator extends the log usage possibilities even further.

Note: The following configuration example needs Radiator 4.16 with latest patches. You must have JSON module installed. JSON::XS module is recommended (see https://metacpan.org/pod/JSON and https://metacpan.org/pod/JSON::XS).


Configuration example: JSON output to radius.cfg (source goodies/logformat.cfg):



# This logger logs events in JSON format. It requires the Perl JSON
# module. Note the specific requirement for loading the logger module.
<Log FILE>
       Identifier mylogger-json
       Trace 4
       Filename %L/logfile.json
       LogFormatHook sub { Radius::LogFormat::format_log_json(@_); }
</Log>


# This auth logger logs both successes and failures to a JSON file.
<AuthLog FILE>
       Identifier myauthlogger-json
       Filename %L/authlog.json
       LogFormatHook sub { Radius::LogFormat::format_authlog_json(@_); }
       LogSuccess 1
       LogFailure 1
</AuthLog>


# This is the Handler-clause.
<Handler>
   <AuthBy FILE>
       Filename %D/users
   </AuthBy>
   AuthLog myauthlogger-json
   # Log accounting messages in JSON format.
   AcctLogFileName %L/acctlog.json
   AcctLogFileFormatHook sub { Radius::LogFormat::format_acctlog_json(@_); }
</Handler>



In this example configuration, all log data is saved into a single file. This may cause problems in the real configuration because of increasing log data file size. You can avoid this by using log rotation tools, for example, logrotate in Unix-based systems. Rotating log files can safely be done without restarting Radiator. Radiator also supports the special characters in the file names. For more information, see Radiator reference manual under section Special characters.

Do you want to know more?
Your JSON files are now ready, the next step is to use them efficiently. In the next part of the series, we will introduce the more detailed use cases, which will help you get the most out of Radiator logging.

Friday, May 13, 2016

OSC Radiator team available for meetings in 5G World, London 29 June - 1st July

We are happy to invite all our blog followers at our stand #43 at the 5G World in London Olympia, 29 – 30 June to discuss how we can help you with Radiator AAA solutions.
To have discussions on our solutions from one end to another, we have joined forces with representatives from Kapsch CarrierCom, one of our partner companies in a role of a systems integrator.
Let’s discuss together about your needs and challenges so we can offer better support you. Would you like to be among the first ones to hear the news on the Radiator roadmap? Top teasers include:
  • Radiator NFV product line (More info here)
  • Our latest products such as Radiator GBA/BSF Support module
  • VoLTE, VoWiFi, 3GPP AAA Server use cases
  • New features on Radiator development roadmap 

Visit us at our stand during the event, or schedule a meeting in advance at info@open.com.auAlso, separate meetings can be arranged on 1st of July in London. Just get in touch with the Radiator team at info@open.com.au.
For more information about the event program, please visit the event website.

Wednesday, April 27, 2016

What is NFV?

We have had posts about Radiator VNF and what true NFV means to us, but a general introduction to what Network Functions Virtualisation actually means has been missing until now. Below you can find an overview presentation about What is NFV? by our managing director Karri Huhtanen.

 
If you are interested to learn more about NFV and how Radiator works to get operator AAA infrastructure virtualised, contact our team at info@open.com.au so we can arrange a proper presentation or webex about the subject.

Tuesday, April 19, 2016

More interoperability with Radiator GBA/BSF Support Module v. 1.3

We are happy to announce Radiator GBA/BSF Support Module v. 1.3.

With Generic Bootstrapping Architecture (GBA), it is possible to provide seamless authentication for VoLTE Supplementary Services. This enables the end user to manage services, such as call forwarding, knocking and video call forwarding without switching networks or extra usernames and passwords.

Radiator GBA/BSF Support Module works as an authentication proxy between the end-user user device and the HSS. It authenticates the user requests, and also separates the authentication procedure and the Application Specific server (AS) functionality into different logical entities, for example, RCS (rich communication suite) services mentioned above.

What is new?

We have added interoperability fixes, and successful testing has now been done with user equipment from following vendors:

  • Samsung
  • Microsoft
  • Apple

New features also include fixed username checks and fixed access handlers to work even when client does not send the HTTP user agent header. You can see all the updates from Radiator GBA/BSF Support module revision history.

Do you want to know more?

We are happy to provide more information, use cases and benefits about Radiator GBA/BSF Support Module. Just contact our team at info@open.com.au and we will tell you more.

Wednesday, March 23, 2016

Deploying flexible Radiator AAA for Cisco ASR/CSR VPN

The increased use of Cisco ASR/CSR and its IPSEC VPNs with IKEv2 creates new challenges for authentication, authorisation and accounting (AAA) software. The first challenge is interoperability, especially when Cisco’s implementation of IKEv2 requires EAP-MSCHAPv2 to be used for VPN user authentication.

Most AAA server softwares support MSCHAPv2 for RADIUS authentication, but only few have support also for MSCHAPv2 encapsulated inside EAP protocol. Radiator supports them both. What is more, with Radiator it is possible to separate the MSCHAPv2 from EAP by terminating the EAP tunnel in Radiator and forwarding the inner MSCHAPv2 to other authentication servers or services.

The Radiator’s ability to separate MSCHAPv2 from EAP protocol makes it possible to use Radiator as a flexible proxy for various authentication sources (see Figure 1) such as Windows Active Directory, One-Time-Password (HOTP/TOTP) services, RSA / Yubikey / Duo Security tokens etc. For some authentication sources, Radiator works as the actual endpoint for AAA service reducing the need of multiple separate authentication servers or appliances sitting in your network.



EAP_MSCHAPv2.png
Radiator EAP - MSCHAPv2 Architecture

Do you want to know more?

This is a popular use case and we have been been contacted by several customers who need to separate MSCHAPv2 from EAP protocol. This functionality is one reason why Radiator AAA Server is called 'The Swiss Army Knife of AAA Servers'. Radiator provides various protocols and can be used as a proxy in different environments – often with configurations that are provided without additional charge when purchasing the license.

For more information, please contact our team at info@open.com.au

Monday, March 14, 2016

Radiator VNF in OpenStack environment

OpenStack is the leading cloud infrastructure choice for operator Network Function Virtualisation (NFV) and Software Defined Networking (SDN) infrastructures. Several vendors, such as Ubuntu, Red Hat, and Suse, provide complete implementations for OpenStack. To ensure that Radiator VNF is easily deployed on top of various private and public cloud infrastructures, it is delivered as standard Linux distribution packages and the configuration management system handles the installation and configuration process automatically.

Instead of maintaining several large specialised virtual host images, Radiator VNF is deployed on top of your existing Linux operating system. There is no need to change the operating system, you can continue using your familiar Linux distribution with its licences, update and security services.

The basic architecture of Radiator VNF combined with OpenStack is described in the image below.


Instead of replacing the existing OpenStack controller functions and components, Radiator VNF works together with them and extends the OpenStack components if needed. Radiator VNF Manager utilises Heat and other cloud infrastructure orchestrator APIs to create, delete, and scale VNF instances and components. 

Using Radiator VNF Manager gives the additional flexibility and extended control granularity for scaling virtual AAA (authentication, authorisation, accounting) functions. It also makes it easier to adapt Radiator VNF  to any cloud infrastructure. All Radiator VNF components are also designed and implemented to securely communicate across compute nodes, which makes it possible to distribute Radiator VNF components flexibly without limiting the components within a single compute node. 

Configuring Radiator VNF components do not require any manual interaction. Every configuration task is done automatically via Radiator VNF configuration management system, not by configuring each Radiator VNF component individually. This, combined with flexible component scaling, makes Radiator a true NFV solution.

Would you like to know more?

The Radiator VNF brings its well-known flexibility and extendability to the NFV world. Enhanced with configuration provisioning, automated scaling, and platform independency, Radiator VNF continues to be the Swiss army knife of AAA software also inside cloud infrastructures. If you are interested to learn more, please contact info@open.com.au for more information.

Monday, February 29, 2016

VoLTE RCS is getting more support - be ready with Radiator

In Mobile World Congress last week, Google and several global operators announced the launch of a mobile industry initiative to accelerate the availability of Rich Communications Services (RCS) in Android. Operators have agreed to transition toward a common, universal profile based on the GSMA's RCS specifications and an Android RCS client provided by Google in collaboration with operators and OEMs.

For telcos and their customers, the improved user equipment support means that they can get more out of their VoLTE networks. For example, the following Android RCS features will become part of operator messaging experience:

  • Group chat
  • Sharing high-resolution photos
  • Reading receipts

Also, GSMA RCS advanced calling features will be supported in the future by Google.

Be ready with Radiator

The support for VoLTE RCS requires seamless authentication in operator networks. This can be implemented with Radiator GBA/BSF Support Module. Radiator GBA/BSF Support Module works as an authentication proxy between the end-user UE and HSS. It authenticates the user requests, and separates the authentication procedure and the Application Specific server (AS) functions to different logical entities – for example, call forwarding and other Rich Communication Services.

Authentication architecture, when your end user device supports VoLTE RCS

We have already deployed Radiator GBA/BSF Support module to real operator networks in order to provide support for seamless VoLTE RCS authentication. In case you are interested in our solution, please contact our team at support info@open.com.au.

Tuesday, February 16, 2016

What true NFV means?

When talking about Network Function Virtualization, it is important to differentiate between true NFV solutions and traditional server-virtualisation techniques, where someone has to care for each virtualised server and their configurations. If the NFV concept is limited to managing a farm of virtual servers manually, many benefits of NFV are missed.

In a true NFV, such as any of the Radiator VNF solutions, VNF manager does the scaling and configuration of virtual servers automatically. For example, in our vAAA solution the VNF manager monitors the RADIUS and Diameter traffic distributed by load balancers and launches new AAA workers automatically to meet the workload. In addition to launching new workers,  all the new instances in the cloud are configured automatically by using the centralised configuration management service. Configuration management uses metadata services to automatically create configuration for the current cloud setup. External connection parameters can be pre-configured and/or configured via NETCONF by OSS/BSS.

Arch-Red-Radiator-A-True-NFV-Solution-Markerwizards-10.png

This kind of scaling is needed, for example, when all end user devices authenticate to the network at the same time. This may happen during rush hours, major public events or when things like sudden power failures happen. When the new AAA workers are not needed, the NFV manager shuts them down automatically – without any manual action or configuration.

Arch-Red-Radiator-A-True-NFV-Solution-Markerwizards-11.png

This automatic scaling and configuration is essential for network function virtualisation. It enables easier workload for your engineering staff – and gives you all the benefits of true NFV solutions. For more info, please see our NFV site or contact info@open.com.au

Friday, February 5, 2016

Radiator VNF – a true NFV solution

As telcos, service providers and enterprises are now looking for solutions using network function virtualisation (NFV), we here in OSC provide a solution for this. We are happy to announce Radiator is now available as the first true implementation of the AAA virtualised network function – Radiator VNF.

Radiator VNF – an overview

Our customers have always said that Radiator is a Swiss army knife of AAA servers and we want to ensure it will be interoperable in the future as well. Because of this, Radiator VNF is developed and tested together with leading operators, integrators and vendors – and it works with any industry standard NFV infrastructure.

To get most out of scalability, the key benefit of NFV technology, Radiator VNF is equipped with additional components such as RADIUS and Diameter load balancers as well as separate AAA and database workers. This ensures that it automatically scales in and out according to actual transaction needs.




In addition to this, scaling in Radiator VNF is controlled by its management and monitoring components. Management and monitoring components together with Radiator VNF Manager ensure that instead of having too many dedicated authentication servers only waiting, you automatically have the right number of server instances at all times.

For integration needs, Radiator VNF includes a redundant message queue for inter-component communication. All Radiator VNF components utilise this message queue for communication, and provide clean, clear interfaces to make future service integration easy and flexible.


Do you want to know more?

We are happy to make Radiator VNF a part of your NFV solution. Radiator VNF is delivered as a VNF image which is ready to be deployed quickly and easily across infrastructures. For more info, please visit our website and contact our team at info@open.com.au.

Wednesday, January 20, 2016

Radiator 3GPP AAA Server white paper published

We are happy to announce that Radiator 3GPP AAA Server white paper (pdf) has now been published. 3GPP AAA Server white paper, as well as our previous white papers about Radiator SIM support and Radiator Policy and Charging support, can be found from OSC website.

If you are in a need for 3GPP AAA Server solution, you can always contact us at info(a)open.com.au