Cigorn Gateway Info

The CIGORN Commercial Gateway is an opensource Linux device for connecting many base stations to a network. It can be used on a private network or used as an IoT gateway to connect base stations and RTUs to cloud servers or private servers.

Safe for your Network and low cost.  This does not need to use IoT and not share IoT.  You network with a CIGORN Gateway will run your system the way you want.

Using a commercial gateway is always recommended systems where you do not have developers in your organization. If you prefer a black box approach where a vendor will implement and support a gateway between your system and remote devices, then using a commercial gateway like Cigorn is the right choice.

Gateways like CIGORN make systems secure, flexible, easy to communicate with unlimited numbers of devices. Gateways make managing networks and communications very flexible and reliable, and it records activity to help managers ensure the system is operating as expected.

To see how to acquire a Cigorn Gateway contact contact Raveon Sales or look at this About Cigorn Website.

CIGORN supports many SCADA and Telemetry protocols, such as MODBUS, DNP3, and IEC 60870.  Internally, there is a protocol translator, and a router that can direct messages based on the ID of the Remote Terminal Unit.

If you are managing a large network of remote devices, SCADA devices, telemetry devices, or GPS tracking, a CIGORN gateway makes your system reliable and flexable. If you want a secure system, and don’t want to put your data in the Internet, CIGORN can be run on a private network to connect your devices as if they were on cloud servers.

1. Cigorn Features
2. Cigorn Gateway Hardware Plateform
3. Cigorn Open Source
4. Cigorn Stress Tested to Track 60,000 Vehicles/Minute
5. Configuring Linux TCP Keepalive
6. Development plan
7. Hot Standby added to Cigorn
8. Making an IP Addressable Data Radio System
9. Router Features
10. Why Develop This

Wireless Network Addressing (WNAT). WNAT gives each radio in the system a unique IP/Port number. To communicate to a particular radio modem, simply connect a TCP/IP telnet or socket connection to its particular port.

Multiple Base Station Support. The Cigorn Gateway can be configured with any number of radio modems assigned to any number of base stations. The Cigorn Gateway will keep track of which base station a particular radio is supposed to communicate on.

Multiple Routes. Cigorn’s powerful message routing software allows messages to be routed to/from any number of radios and IP addresses. A single message may even be routed to multiple destinations.

Web interface. To monitor the system, Cigorn’s Web interface provides a rich set of operational statistics in real time.

Hot Standby. The Cigorn Gateway supports synchronization and failure detection using a second gateway. A backup gateway will keep it’s configuration continuously matched to a primary gateway. If it ever detects a failure, it will automatically take over to ensure the system always works.

Back to the top

A primary goal of the Cigorn gateway project is to be able to run the Cigorn Gateway software on any POSIX Linux platform that has Ethernet and Serial port capabilities. The Cigorn software program does not require any human intervention, video monitor, keyboard, or mouse.Although we expect the software to be able to run on most any Linux machine, the target we envision is an Mini ITX motherboard with an Celeron processor. A complete Cigorn system can be built using standard off-the-shelf miniature fan-less PC for less than $300. Power consumption is typically less than 20 watts.

Back to the top

Open Source is software created by a community of people who are dedicated to working together in a highly collaborative and revolutionary way. This project was started by Raveon, with the desire is to bring together a community of developers to mold Cigorn into a powerful backbone technology for wireless data networking. For users of software who have the skills to download and install software, open source means choice and freedom. The freedom comes from the fact that the source code is available. If you want to change something, then you can, if you have the right skills.

The Open Source License under which the Cigorn source code may be used requires no payment to Raveon. Abide by the terms of the License, and you may use or resell products that use this program without having to pay Raveon anything.

This is a technical product, and is provided to the Open Source developer community AS IS. We hope that enough parties are interested in developing Cigorn that the blog will be a valuable source of technical assistance. Raveon will offer technical assistance on a per-hour consulting basis.

For companies or people who would like to purchase a Cigorn Gateway pre-configured and ready to use, Raveon will sell complete Cigorn Wireless Gateways with full technical support.

Back to the top

Building on our recent post about brokering a telnet session, we’ve created a bash script to send a continuous burst of $PRAVE messages through the router. Running this script has allowed testing of 60,000 tracking messages per second through a single Cigorn Gateway. This test ran for two weeks without any dropped messages or issues. In the end, the test was stopped to resume normal operation.Tracking messages were used as this was a stress test for Raveon’s recent thousand bus tracking installation using Cigorn.
Here’s the test script, in the 1000Hz data configuration:
#!/bin/bash
clear
NUM_FEEDS=20
START_PORT=6780
SLEEP_TIME=".001"echo "Beginning stream with $NUM_FEEDS ports starting at $START_PORT"
pkill -f "ncat localhost 6"
pkill -f "tail -f pravepipe"for i in `seq 1 $NUM_FEEDS`;
do
# Make named pipes and set up a tail to an ncat session.
# Ignore error if pipe exists
mkfifo "pravepipe$i" > /dev/null
ncat -k -l `expr $START_PORT + $i` --broker &
nohup tail -f "pravepipe$i" | ncat localhost `expr $START_PORT + $i` &
done
i=1
while true;
do
while read line;
do
# Send this $PRAVE message through prave pipe number "i"
echo -ne "$line\r\n" > "pravepipe$i";
# Increment i and then check if we need to go back to 1
i=`expr $i + 1`
test "$i" -gt "$NUM_FEEDS" && i=1
sleep $SLEEP_TIME;
done < praveout
done;


The script above created a number of (in this case, 20) named pipes. In addition it created the same number of brokered ncat sessions, listening on incrementing port numbers. Each named pipe is tailed to its corresponding ncat session, creating pipes that, when written to, send data to anyone who connects to a certain port. Data is then simply read from the “praveout” file and send, round robin, to each of the input feeds with a data point written every millisecond.For our particular test, Cigorn was configured to connect to all of the streaming ports and then direct all incoming traffic to two data sinks. This particular configuration mocks up the aforementioned bus tracking solution…excepting the much higher message volume!

Back to the top

In certain circumstances, it is important that Gateways using TCP/IP socket communications periodically send TCP messages even if they have nothing to say. These null messages called “keepalive” packets can help inform networking infrastructure that the endpoints are still there, connected, and expect the TCP/IP socket to stay connected even though at the moment, they don’t have any data to exchange.By default, most Linux computers disable keepalive packets because they do add some additional loading to the network. The network load is very minimal, and this article describes how to enable keepalive packets, and how to configure Cigorn to use keepalive packets on a case-by-case basis.

These are the steps to enable keepalive packets on a Cigorn Gateway:

1. Configure the keepalive parameters within Linux in sysctl.conf
2. Configure the various device designators to use, or not use, keepalive packets
3. Reboot Linux for your new settings to take place.

 

From the Linux command line, use your favorite text editor to open up the file /etc/sysctl.conf, and edit the setting to meet your infrastructure needs. The net.ipv4.tcp_keepalive_xxxx parameters may or may not be in the sysctl.conf file. If they are not, add them. Make sure there is not a hash ( # ) on the line because that designates a comment. Raveon recommends these settings for a typical Cigorn Gateway configuration:

$ sudo nano /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 5
net.ipv4.tcp_keepalive_probes = 6

The above settings will cause keepalive packets to be sent every minute. If a response it not receive it will resend the keepalive packet every 5 seconds. After 30 seconds, it will reset the socket connection if 6 keepalives fail to get through. This allows a cable to be disconnected and reconnected for up to 30 seconds without dropping the connection, but it will also re-connect in less than 2 minutes if a device reboots or shuts down without properly closing the TCP/IP socket.

From the console on the local machine, or from a remote login SSH session, issue the following Linux command to shut down the Linux machine, and restart it:

$ shutdown -r now

Your new keepalive settings will be loaded, and Cigorn will restart.To view the current keepalive settings, use the “config” command from the Cigorn command-line interface.

Back to the top

The Cigorn Gateway now has the ability to act in pairs as a fault tolerant system. In this configuration, a designated gateway runs in Standby Mode. The gateway will not make any connections or route any messages. Instead it will keep its settings synchronized with the primary gateway and monitor its health.If at any point the standby gateway detects (via non-responsiveness) that the primary gateway is not online, it will enter normal operation mode and begin to route messages.

While in Takeover Mode, the standby gateway continuously attempts to notify the primary gateway of the takeover. If the primary comes back online, a clean takeover will be negotiated and the primary and standby return to their normal operation state. These transactions (Takeover, Primary Mute, Hand-back) have been designed to minimize data loss in a hardware failure situation.

This feature has been tested extensively and is already in use in one of the Cigorn appliance installations!

Back to the top

Most data radio modems, like Raveon’s M7 and M21 series of radio modems, have RS232 serial interfaces. RS232 is a fine way to communicate, but IP based networks form the backbone of wide-area communication networks. A terminal server may be used to connect an RS232 device to an IP based network. Raveon has an application note AN140 describing how this is done. Using a terminal server to connect a radio modem to your IP network may be a good way to communicate with the modem, but as your system grows, there are limits to this simple solution.

As the number of wireless modems on the system grows, and the radio coverage expands, wireless users often find themselves looking toward using public cellular radio networks for their wireless data. Cellular modems are easy to use and deploy. But, besides the large monthly recurring costs, system latency, coverage, routine obsolescence, and redundancy requirements are issues that make some users prefer to manage their own radio network. As an alternative to cellular modems, a Cigorn Gateway can manage a large number of radio modems, a large number of base stations, and provide a seamless IP interface to the whole system. This page describes the general configuration, and if you are interested in fielding a radio system with hundreds or thousands of radio modems, contact Raveon to discuss how our data radio modems and the Cigorn Gateway and be used in your application.

There are many reasons that a narrow-band radio system built with a Cigorn Gateway will be a better communication solution for you. Some of the reasons are:

1. Individual IP address/port for each radio on your system.
2. No monthly fees.
3. Low latency. Messages will transfer within milliseconds.
4. You can easily add additional base stations to cover remote areas.
5. Works in areas where there is no cellular coverage.
6. You determine your system redundancy and emergency operations, not a common carrier.
7. Cellular radio modems go obsolete in short time periods compared to conventional radio modems.
8. A cellular data carrier can at any time change billing, hardware requirements, and coverage without your permission.

At the heart of the system is a Cigorn Gateway. The primary gateway keeps track of all radios, and knows where in the system each radio is located, and how to talk to it. Your application need only communicate to the Cigorn Gateway via TCP/IP.A Cigorn Gateway can communicate with thousands of radio modems, giving them each a unique IP address. Your application software does not need to know anything about how the radios are addressed or over-the-air protocols. Any application that can use IP addressing can be used to communicate to data radio modems via a Cigorn Gateway. A unique port number on the gateway is assigned to each radio in the network.

The Cigorn gateway can be configured to route data to/from radios in the field to/from specific IP addresses. Additionally, it can keep track of which base station in the field a particular radio is within communication range, and ensure that messages are sent to the correct base station for a particular radio modem.

For more information on creating a large IP addressable narrow-band radio modem system, contact Raveon sales at sales@raveon.com.

Back to the top

Cigorn’s data router engine is a very flexible component of the Cigorn Gateway. It is user-configurable via entries in the SQL data table routes. The router engine performs the following functions:

1. Pass datagrams between Wireless devices, other Cigorn Gateways, and End-User systems.
2. Fitler routed datagrams based upon protocol type, NAP, and destination Wireless Dvice ID.

To simplify entries in the router engines route table, the input/output interface on the Cigorn Gateway are given a uniq name. When user assigns a name to an interface, they also assign a device to the interface. The name they assign is referred to as a Device Designator. Each bound pair of device&interface is referred to by a unique Device Designator. The Device Designator is assigned to the pair with the Device Binding entry in the .ini file. For example a radio modem setup on frequency 1 that is connected to serial port ttyS3 could be called “RFP1”. In the routing table, the user refers to this as combination as RFP1 the router engines know knows what serial port to use and what protocols are supported.

Back to the top