Radiator Interoperating with Hotel Management Systems

One of the widely seen use cases for Radiator is interoperating with different hotel property management systems (PMS). Radiator is used between the hotel’s PMS and the network equipment that controls internet access in hotel rooms. One of the commonly used systems is Micros Opera that is used by both independent hotels and hotel chains.

For Opera, we have implemented support in Radiator that is easy to deploy with your own team or with the help of our experts. When Radiator starts up, it will receive hotel customer information from Opera. This information is used for Wifi network authentication. The basic information received from Opera is name, room and customer id of the guest. When the hotel guests check in or check out, the information Radiator maintains is updated by Opera. Radiator support is not limited to Opera: it supports any PMS that provides a FIAS interface.

Many hotels require guests to log in with their name and room number. Radiator then gives access based on customer information it has received from Opera. This functionality is shown in the picture below.

In addition to simply offering unpoliced, complimentary internet access, Radiator provides you more advanced options for revenue generating services. Radiator can, for example, give policy instructions, such as the speed given to the customer - based on the price customer is willing to pay for the internet access. Also, Radiator can pass information to network equipment (such as Mikrotik controllers) about how long the customer can use the internet with their current login without having go through the login process again.

Same need in your own hotel or hotel chain?

If you need a smart and flexible internet access service for your business, just contact our sales team at sales@radiatorsoftware.com. Our experts at Radiator Software can provide you with competitive service package suited just for your needs.

Radiator logging features - have a better understanding of your network

A proper logbook keeps the world in order. Photo by vxla.

As networks are the most business critical components of telco and ISP business, it is important to know what is happening on them. For this the network needs AAA and SIEM (Security information and event management) services. The SIEM services are often provided by different vendors with different requirements for message format. For example, some use CEF while the others can accept free format text. We are proud that Radiator already provides interoperability that our customers can rely on. We also welcome your requests for new features.

Radiator 4.14 introduces LogFormatHook that provides a new way to handle logs. The main use of LogFormatHook is to create Radiator logs in different formats such as JSON and CEF. After this the formatted log message can be transmitted to an external log server or SIEM system for further processing, visualisation and archiving. Examples of these servers and systems are Splunk, Elasticsearch and RSA enVision and Security Analytics.

Especially with SIEM systems this functionality provides Radiator users many opportunities for log analysis. The SIEM systems can process log data for forensic analysis, compliance, dashboards and alerting - everything you or your customers need to know about status of their network.

Considering updates to your logging configuration?

If you have a network environment that needs this kind of interoperability with their log or SIEM systems, please contact our sales team at sales (a.t.) radiatorsoftware.com . Also, if you have questions about interoperability concerning Radiator or some other AAA server solution - we just may have a solution for you.

Improving Clustering Support in Radiator with Gossip Protocol

 Our Radiator is deployed in various operating environments, ranging from single server instances to large clusters, sometimes called server farms. Recently, we have developed Radiator support for Gossip protocol framework and Redis based Gossip implementation. The Gossip framework allows clustered Radiator instances to share information and event notifications. The instances can be standalone or part of a Radiator server farm.

One use case for the Gossip framework is co-ordinated detection of unreachable next hop proxies. Multiple Radiator instances can now signal next hop proxy unreachability and reachability information with Gossip messages. The instances may be part of server farm, completely separate processes running on the same or different hosts or any combination of thereof - depending on the customer’s network architecture.

Radiator 1 informs Radiator 2 via Gossip

This allows, for example, one server farm worker to run Status-Server queries when the FarmSize configuration parameter is set. When the member notices that the next hop has become unreachable, it can quickly alert the other members to immediately switch over to an alternate next hop. This provides a method to quickly recover from failures - and also switch back when the failure condition has been resolved.

In general, when the instances can share information, co-operating Radiator instances as a whole can function more efficiently and respond more quickly to configuration and other changes.

As our product development continues, we are planning to develop more clustering functionality to Radiator. Our aim is to provide even more performance to network environment with large amount of end users.

How can I use them as a Radiator customer

If you already use Radiator, see goodies/farmsize.cfg for a configuration example with shared duplicate cache and Gossip and Redis configuration. As our development work continues, more modules will be added and upgraded to use the Gossip framework.

If you are not yet a Radiator customer, please contact our sales team at sales(a)open.com.au with your question about. We are happy to help you with your issues.