Cigorn info


1. Cigorn Features

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


2. Cigorn Gateway Hardware Platform

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 Atom processor. A complete system can be built using standard off-the-shelf components for less than $400, and an industrial-grade machine obtained for less than $1000. Power consumption is typically less than 20 watts when running on an Atom processor. Something like a rack-mount version shown below should work, and would be big enough to fit a radio or two inside:

Back to the top


3. Cigorn Open Source

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


4. Cigorn stress tested to track 60,000 vehicles/minute

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;

How does it work?

The script above creates a number of (in this case, 20) named pipes. In addition it creates 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


5. Configuring Linux TCP Keepalive

In certain circumstances, it is important that Cigorn Gateways using TCP/IP socket communications periodically send TCP messages even if they have nothing to say. These null messages called “keepalive” packets and 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.
Linux Keepalive Packets

One most Linux distributions, the file /etc/sysctl.conf contains the keepalive settings. Using your favorite text editor (we use nano), edit this file to set the three keepalive parameters to your desired keepalive intervals. The best values to use will depend upon your network, but because keepalive traffic is so infrequent and the packets small, we recommend a fairly short keepalive interval.In the file /etc/sysctl.conf there are three parameters related to keepalive:

net.ipv4.tcp_keepalive_time

net.ipv4.tcp_keepalive_intvl

net.ipv4.tcp_keepalive_probes

The net.ipv4.tcp_keepalive_time parameter is the time before the first keepalive packet is sent out. As long as there is TCP/IP socket communications going on, no keepalive packets are needed, but if the amount of time in seconds specified in net.ipv4.tcp_keepalive_time passes without any communication on a TCP/IP socket connection, then the Linux OS will begin sending keepalive packets.

Once keepalive packets begin being sent out, they will be sent every net.ipv4.tcp_keepalive_intvl time (in seconds).

Keepalive packets are a two-way exchange. When one device sends a keepalive packet to another, the receiving device sends a quick acknowledgement packet back. This way, both devices know the communication link between them is OK. If the device sending the keepalive packet does not get a response back, it sends another keepalive packet after the net.ipv4.tcp_keepalive_intvl passes. After enough keepalive packets are sent and no response is received, the sending device will assume the link is down, close the socket, and try to re-establish communications. The number of keepalive packets sent before the device will reset if it does not get a response is configured in the net.ipv4.tcp_keepalive_probes parameter.

Configuring Linux Keepalive Settings
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.
Configure Cigorn to use Keepalive Packets

Each Ethernet DeviceDesignator in the Cigorn Gateway is configured by settings in the Cigorn SQL database table called ethdevdes.When a particular DeviceDesignator is a TCP/IP client socket, the field “parm1” specifies how the socket behaves.ket will stay permanently connected, sending periodic keep-alive packets. If the end-point resets or drops the connection, Cigorn will detect this because of the keep-alive packets, and automatically reconnect.

TCP SERVER usage: none. You may leave it blank.

Reboot Linux
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


6. Development Plan

Phase I Proof of Concept.At a minimum, the Cigorn Gateway will be valuable if it can do intelligent radio management and message routing. To get the design to the point it can do these two basic functions, software will need to be developed to give the Cigorn Gateway the initial basic functionality:

  1. Build a reliable and scalable software platform for the Cigorn software to run within.
  2. Maintain a master wireless device list (MWDL) and keep it synchronized with all gateways in the system.
  3. Assign Wireless Devices their TDMA time slots as they join the network.
  4. Route GPS position messages to a primary gateway which further routes them to multiple endpoint devices.
  5. Accept data messages from various IP based interfaces, route them to the correct radio device, or to another gateway that has communications with the appropriate radio device.
  6. Provide a management interface is via command-line.
  7. Provide normal system health monitoring.

Phase II Add global GPS Tracking

  1. Host a lightweight SQL server.
  2. Maintain a database of the GPS position and status information for all radio devices in the Cigorn network.
  3. Forward updated GPS position information via PRAVE messages to any number of computers.
  4. Serve responses to SQL data inquiries for position/status of radio devices.
  5. Add a web page server to provide a browser interface to the system management.

Phase III Trunking

  1. Dynamically assign radio devices to different radio channels, based upon class of service required.
  2. Hand-off radio devices to the best Cigorn Gateway within radio range.
  3. Add hot-standby capabilities to the site and master gateways.

Possible Extensions of the Cigorn Architecture

  1. Support for voice communications.
  2. Add support for other brand radios.
  3. Interface to various RF infrastructures
  4. Add Modbus Ethernet support.

Back to the top


7. Hot standby added to Cigorn

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


8. Making an IP Addressable Data Radio System

Most data radio modems, like Raveons M7 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.
Cellular Radio Modems The Easy 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.
Data Radio Modems with Cigorn The Better Solution

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.
How to Make an IP Radio Network

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


9. Router Features

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


10. Why Develop This?

  • To allow larger radio systems to be built using Raveon’s (and other company’s) data radio modems. This will be possible because:
    • The gateway will manage TDMA timing, slot assignment, FDMA, and bandwidth allocation.
    • Multiple Gateways will interlink to create one large network.
  • Simplify radio management. A system will be easy to deploy and manage because the Gateways will be able to reconfigure the client radios as needed.
  • Ability to quickly create ad-hock radio networks for AVL.
  • Add wide-area messaging capabilities to Raveon’s RavTrack AVL system. The Gateway will be able to route messages to-from mobile data radio modems anywhere in the Cigorn system.
  • More flexible data messaging. The Cigorn Gateway will hide the vagaries of the radio network from the user, allowing standard and proprietary protocols. Various protocols will be built into the Gateway so that users may send/receive data to/from client radio modems using protocols such as
    SMTP (send an email to the gateway, and it will route it to the correct data-radio)WMX. Raveon’s proprietary binary messaging format.
  • MODBUS TCP. This and/or other SCADA protocols will enable wide-area telemetry applications to be built using using any combination of narrow-band data radios, Ethernet, and WiFi.
  • Telnet, UDP, and TCP/IP sockets interfaces.
    Possibly interface to APCO25 or NXDN radio systems.
  • Customer Support. This project may possibly be turned into an “Open Source” project which will give sophisticated users who have software development capabilities an interesting platform to build upon.

Back to the top