Gunter Jost, DK7WJ
FlexNet Gruppe Darmstadt
Lichtenbergstrasse 77, D-64289 Darmstadt, Germany
Donald Rotolo, N2IRZ
Radio Amateur Telecommunications Society
PO Box 93, Park Ridge NJ 07656, USA
Features and operation of FlexNet packet networking software are discussed. Details of the software architecture, RMNC and MS-DOS hardware platforms, applications, user interface, adaptive parameters, and routing techniques are presented.
FlexNet is a flexible, modular and user-friendly software program for packet radio networking. First conceived in 1987, the software has undergone numerous changes and improvements since then, and is presently (July 1995) at version 3.3. The most notable features of FlexNet are:
FlexNet is presently the most widely used packet radio networking software
in Germany, with over 500 installations. Due to German amateur radio regulations,
each unattended station (node) must receive special permission to operate,
and must use tightly coordinated dedicated point-to-point links. Despite
creating problems and red tape, these limitations have forced the creation
of a very high-quality network, where round-trip response times over hundreds
of kilometers and tens of node sites are typically only a few seconds.
Although FlexNet is primarily used for networking, the PC version can also
be used by users by simply eliminating the Node module. PC/FlexNet is thus
a flexible yet powerful replacement for permanent TNC emulations (such
as TFPCX). It is extremely simple to set up, since there are no hassles
with parameters.
FlexNet software is a copyrighted product of Gunter Jost DK7WJ, who retains all rights. The software may be freely copied, distributed and used for non-commercial Amateur Radio purposes.
FlexNet is presently ported to two hardware platforms: The Rhein-Main Net Controller (RMNC) system and the Intel 80x86 processor running MS-DOS.
The RMNC platform is a 6809-based system using a Z8530 SCC. Each channel control card (one for each radio/data channel) is on a standard Eurocard, and is plugged into a standard card cage with backplane bus. One master card can control up to 15 slave cards. Developed by the Frankfurt (Rhein-Main) Packet Radio Group, the RMNC remains the preferred platform for FlexNet because of its low cost and high performance. The software resides on a single EPROM. The MS-DOS version has existed since 1990, but was not distributed, as it was used primarily as a test and development platform. In 1994, development of a stable version for MS-DOS was begun in earnest. FlexNet runs problem-free in an XT-class system, although faster processors are preferred. A number of different channel drivers exist, allowing for some flexibility in I/O hardware.
The choice of MS-DOS was based primarily upon the large installed base. Admittedly, a better choice would be LinuX, and in fact the task of porting FlexNet over is already being worked upon.
In 1994, a discussion between the present FlexNet author (DK7WJ) and BayCom author Flori Radlherr DL8MBT yielded a new concept for FlexNet: Modularity. The major portions of the software were developed as separate modules, the most important being the channel drivers and applications. These modules can be used in combinations as desired, on either hardware platform, creating a very flexible system, and allowing a larger number of authors to contribute talent. In the near future, a "developer's kit" will be available, further easing module development.
A number of driver modules presently exist:
Other drivers being developed include those for TMC320C25 DSP systems as well as Sound Blaster cards.
The FlexNet system supports a number of applications, primarily for the purpose of providing users and Sysops with information about the network or a node. These applications are mentioned in "User Interface" below. Due to the modular design of FlexNet, implementing new applications is relatively easy, and can be written by anyone having sufficient programming experience. Three unique applications deserve special mention:
FlexNet appears as a simple interactive application to the user. A number
of commands are used to set up connections, access applications, etc. The
user connects to the node's Info-Box and sends the desired command.
To initiate a connection, the user need merely specify the destination,
although other options including manual routing are possible. Information
about link round trip times and channel throughputs is available, too.
The Info-Box even provides a simple local, i.e. not nested round table
conversation server.
To connect it is only necessary for the user to specify the point of entry to the network and the destination. There are four methods available to route the users connect request:
Routing is only performed for the Connect (SABM) frame. Once the Virtual Circuit is set up (the UA of the SABM is received by the calling station), all subsequent frames take the exact same path. If a failure occurs, the link is torn down after informing both ends of the failure. A failed link must be reestablished manually.
The first method is based upon routing by callsign information. Thereby the node seeks the next available node callsign of the received frames, and compares this with a table of calls that have been stored in a destination table by the autorouter. If a match is found, the call is passed along to the specified neighbor. [NOTE:All node callsigns begin with DB0...]
Example: DB0ODW has the following links:
1: DB0KT 2: DB0AAC 3: DB0IE
and knows the following destinations: DB0EQ, DB0ZDF, etc. The frame
<fm DG3FBL to DK7WJ via DB0ODW,DB0ZDF>
is expanded to:
<fm DG3FBL to DK7WJ via DB0ODW,DB0AAC,DB0ZDF>
This is because DB0ODW knows that DB0AAC (which it has a direct link to, on Port 2) is the next (and best choice) node along the path to DB0ZDF. Thus, the frame is sent via Port 2, despite the fact that there is no direct link to DB0ZDF. The 'best' path is always selected for any given destination, as determined by the average 'ping' time for a given path.
The node sends out test frames ("Pings") to each neighbor, and then stores the round-trip response time. Using the ping information, the destination tables are constantly updated in real time. If a destination becomes available (or unavailable), that information is instantly broadcast throughout the network (limited only by the propagation time through the network), thus all destination tables are nearly identical. The destination table is built automatically and cannot be changed by the operators. It is thus assured that only accessible destinations are forwarded, and instantly deleted when they (or their path) disappear.
If the autorouter does not find an entry in the destination table, it then goes to the sysop-defined link table. If a pre-defined route is found here, the frame is sent to the specified neighbor (on a specified port) for handling. The link table normally contains only the direct neighbors, that is, those nodes having a direct link with the node. Example: DB0ODW has the following links:
1: DB0KT 2: DB0AAC 3: DB0IE 4: DB0AIS
The frame
<fm DG3FBL to DK7WJ via DB0ODW,DB0AIS>
would be routed to Port 4 so long as no entry exists in the destination table, because DB0AIS is known in the link table. Hopefully, DB0AIS would have a route to DB0ODW.
The node stores the last 200 directly heard callsigns in an internal list. This list remains in memory until a RESET occurs. An entry to this list occurs only when a station has an active connection, or when it is found using the 'Seek' command. At first, the node uses the SSID of the desired station to establish a connection but, if there is no response, then the SSID is ignored. It is therefore without problems possible to be in STBY on various ports with various SSIDs, so that one can always be found on the correct port. Incoming connect requests or also UNproto frames are routed with this list.
A final chance for the node to route frames is based upon the SSID. Specific channels can be arranged by SSID (this can also be done by Port number). This is shown with the PARMS command. To use the SSID routing, the user specifies the SSID (Port) that the frame should be sent from.
Example: DB0ODW has the following arrangement of SSID versus Channel numbers: Channel 1 has SSID 0, Channel 5 has SSID 12, Channel 6 has SSID 3. If a connect frame arrives that has specified an SSID for DB0ODW, the frame is routed directly to the channel specified by the SSID:
The frame
<fm DG3FBL to DK7WJ via DB0ODW-12>
is routed to channel 5, which has the SSID of 12, since no other way to DK7WJ is known. The following frame is sent out from channel 5:
<fm DG3FBL to DK7WJ v DB0ODW-3*>
which clearly shown where the frame came from (in this case, channel 6 has the SSID 3). This also carries the entry node information. This turnaround of SSIDs is also notable, in that every frame shows where it came from.
One of the most important features of FlexNet is that all connections are reversible, that is, you are always provided sufficient info to have the same connection in the reverse direction. This routing method is naturally used above all for user access.
If all of these routing methods fail, the connect frame is lost. If this occurs when the user is connected to the node, the message
*** <callsign>: can't route
is sent to the user. If the user issued a connect command when disconnected from the node, the TNC will eventually reach the RETry limit.
All level 1 and level 2 parameters within the network (including user access channels) are either self-adjusting according to the current channel conditions or fixed in the software. The only exception to this is TXDelay, which is set by the sysop.
A RETry limit of 10 is used, to ensure a quick recovery for links subjected to temporary interference. Regular polling is used to verify that links are operational, as well as to determine the actual one-way or round trip data transfer time. The polling interval, controlled by FRAck (T1), varies according to channel conditions. If FRAck is small, polling occurs no sooner than every 90 seconds, lengthening when FRAck becomes larger. Each node polls only its neighbors. The round-trip turnaround time is used to adjust FRAck (T1) to the time it takes for the neighboring station to acknowledge I-frames, and is also used (along with other factors) by the autorouter to determine the best (fastest) path to other stations.
MAXframe is regulated according to the capability of the link. When the other station receives all frames without problems, MAXframe runs as high as 7. At 1k2 baud, 7 frames in a row are seldom sent, since the maximum key-down time is limited to about 12 seconds. When multiple streams are active, the 12 seconds is divided up and shared. When the other station begins missing frames (for example by sending reject frames), MAXframe is reduced. In this case, the throughput is actually increased with a lower MAXframe. It should be noted that evaluation checks the link quality TO the other station, not FROM the other station, and that the value changes as necessary. A poll, in which all frames are acknowledged, or with lost acknowledgements, don't reduce MAXframe.
P-Persistence is the critical parameter when many users are on the channel simultaneously. A fixed parameter is, at best, a compromise between collision potential and transmit potential. FlexNet notes the number of users on the channel, as well as the data rate and other factors, and adjusts P-Persistence to offer the best performance at all times. Aggressive stations no longer have the advantage of faster performance at the expense of weaker stations, yet fast downloads remain feasible when channel activity is low. The improvement over a fixed parameter is most notable on duplex user ports (the most common in Germany), but improvement is noticeable on simplex channels as well.
Concerning TXDelay, if the node hears more than 100mS of flags from
a user station, which indicates an excessive TXDelay setting in the users
TNC, a polite message is sent informing the user of this fact, and then
disconnects. Thus, a user running excessive TXDelay cannot use the network
until the problem is corrected.
It would be highly desirable if user software were to also follow the trend
towards full adaptation to the channel conditions. It is clear that a computer
can adjust to prevailing conditions faster and more accurately than a human,
not to mention the fact than most users are totally baffled by TNC parameters
anyway. Other problems also are caused by using a single fixed parameter
to control a constantly changing channel, which would be resolved with
adaptive user software.
PC/FlexNet can be installed as user software, to take full advantage of adaptive parameter adjustment, by simply omitting the Node module. It becomes a powerful yet flexible replacement for permanent TNC emulations like TFPCX - simply use FlexNet with TFEMU and channel drivers as needed. Setup is simple, with only one parameter (TXDelay) requiring operator input.
It is relatively easy and painless to include TheNET network nodes into a FlexNet network. Each TheNET node that interfaces directly with a FlexNet node appears in the FlexNet destination table. The interface must be single-stepped manually, but no serious problems occur as TheNET users are used to single-stepping ;-)
This overview is necessarily brief. Complete details are available with the software (as an ASCII file) or in separate printed documentation available from the author. At this time (July 1995) the documentation is available in German as well as English.
G. Jost, DK7WJ and J. Sonnabend, DG3FBL, "FlexNet, the European Solution", Proceedings of the 9th ARRL Computer Networking Conference, pp127-133, 1990.
G. Jost, DK7WJ, "FlexNet Sysop Manual v3.3", 2nd edition, 1995.