- Cigorn Features
- Cigorn Gateway Hardware Plateform
- Cigorn Open Source
- Cigorn Stress Tested to Track 60,000 Vehicles/Minute
- Configuring Linux TCP Keepalive
- Development plan
- Hot Standby added to Cigorn
- Making an IP Addressable Data Radio System
- Router Features
- Why Develope This
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.
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:
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.
4. Cigorn stress tested to track 60,000 vehicles/minute
Here’s the test script, in the 1000Hz data configuration:
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`;
# 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` &
while read line;
# 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
done < praveout
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!
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:
- Configure the keepalive parameters within Linux in sysctl.conf
- Configure the various device designators to use, or not use, keepalive packets
- 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:
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
$ 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.
$ 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.
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:
- Build a reliable and scalable software platform for the Cigorn software to run within.
- Maintain a master wireless device list (MWDL) and keep it synchronized with all gateways in the system.
- Assign Wireless Devices their TDMA time slots as they join the network.
- Route GPS position messages to a primary gateway which further routes them to multiple endpoint devices.
- 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.
- Provide a management interface is via command-line.
- Provide normal system health monitoring.
Phase II Add global GPS Tracking
- Host a lightweight SQL server.
- Maintain a database of the GPS position and status information for all radio devices in the Cigorn network.
- Forward updated GPS position information via PRAVE messages to any number of computers.
- Serve responses to SQL data inquiries for position/status of radio devices.
- Add a web page server to provide a browser interface to the system management.
Phase III Trunking
- Dynamically assign radio devices to different radio channels, based upon class of service required.
- Hand-off radio devices to the best Cigorn Gateway within radio range.
- Add hot-standby capabilities to the site and master gateways.
Possible Extensions of the Cigorn Architecture
- Support for voice communications.
- Add support for other brand radios.
- Interface to various RF infrastructures
- Add Modbus Ethernet support.
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!
8. Making an IP Addressable Data Radio System
Cellular Radio Modems The Easy Solution
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:
- Individual IP address/port for each radio on your system.
- No monthly fees.
- Low latency. Messages will transfer within milliseconds.
- You can easily add additional base stations to cover remote areas.
- Works in areas where there is no cellular coverage.
- You determine your system redundancy and emergency operations, not a common carrier.
- Cellular radio modems go obsolete in short time periods compared to conventional radio modems.
- 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 firstname.lastname@example.org.
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:
- Pass datagrams between Wireless devices, other Cigorn Gateways, and End-User systems.
- 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.
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.