Under Construction.  Last Modified
Friday, December 18, 1998 08:50:34 PM EST

The FlexNET node

1.10. New U-Options

= show only Infobox-QSOs (was: any character)

<call> show only QSOs from/to this callsign (solomaster only)

* as usual, display additional QSO data

1.11. New L-Option

With "L *", extended statistics are shown. This includes the uptime of the software and the up- or downtime of each link. Link resets will reset this time only if they are caused locally or the connection is interrupted.

1.13. Better command line interpreter

The command line interpreter of the infobox now works line oriented instead of frame oriented. This makes uploading of parameters faster and the convers mode has fewer problems formatting the text. Not implemented on RMNC fullmasters.

1.14. Other changes to Version 3.2

• Baudrate no longer defaults to 1200 baud. It now needs to be explicitly set for each port. Therefore, the list file only shows the used ports now.

• The P-command accepts a port number; "P 1" now only lists the line for port 1

• On solomasters, text memory is 7.5KB now

• The autorouter has been modified slightly; routing-changes in the network are broadcasted faster now.

2. INTRODUCTION

2.2 Important features of FlexNet

RMNC/FlexNet V2 was a version which had many differences to previous versions for users and sysops, both operational & optical. The RMNC/FlexNet V3.0 had some new features, where the autorouter was the most important one. V3.2 was completely revised and became faster and more comfortable again. V3.3 brought the DAMA channel access method and is forerunner of a completely new access method which is also usable on echo duplex nodes. Maintenance of the RMNC was even more simplified, the change of the whole software of the node can now be done by changing one single EPROM. All L2- and L1-parameters except TxDelay are set adaptively to the current working conditions; this means that the sysop has almost no work in setting up parameters. We found it unnecessary to have parameters for every special cases.It was reached the point where the node runs without any maintenance, except for dropouts, of course. Some statistics are useful for the sysop in optimizing the interlinks and make the network transparent to the user. The permanent development and the very cheap hardware made RMNC/FlexNet to the most popular system within Germany, and the growth rates in foreign countries are impressive. From now on FlexNet for MS-DOS is available. The RMNC is not intended to be replaced, it is still the preferred platform for unattended nodes. However, it is an alternative for existing PC-based nodes and makes it possible to experiment with FlexNet without prior high investments in hardware.

2.2.1 Hop-to-Hop-Acknowledgement

Since V2 an important feature has been the immediate acknowledgement of received frames of QSOs which run via the digi. This greatly improves the stability of the links. The possibility of a failure used to be increased exponentially to the number of digipeaters in the path. Now the whole link is as good as the worst interlink on the way.

2.2.2 Connectability

Since V2 the RMNC-digi has been connectable, i.e. QSOs are now possible with the digipeater itself (previously it was only a L2-digi). The digi offers several service functions, for instance convers mode, link information and some information pages.

2.2.3 Remote Control

The FlexNet-software makes it possible to enter sysop mode of the digipeater remotely. This allows changing of parameters, information pages, link information and so on after successful authorization as sysop.

3. Using FlexNet

Using a FlexNet node is very similar to using any other digipeater system. However, you have to specify the callsign of the entry and the destination node. The hop-to-hop-acknowledgement which has been used since V2 should now be known to the users. The FlexNet auto-router should not cause problems anymore also. Surprises can occur from the loop detector only. It displays the message "loop detected" if the user tries to connect a node which would be routed back to the same port the user comes from.

3.1. Adaptive Parameter Settings

Most parameters which had to be set manually on traditional node systems are set automatically by FlexNet according to the actual conditions.

After many experiments, RETRIES were set to 10, but this caused QSOs on fast links to break on short interrupts. To fix this, the node polls at least 90 seconds before giving up. The number of polls, therefore, indirectly depends on the data rate and the use of the channel. FRACK (Frame-Acknowledge-Time, T1) is permanently adjusted to the time the other station needs to acknowledge the I-Frames. MAXFRAME is set according to the reliability of the connection. When all frames are acknowledged reliably, MAXFRAME is quickly set to 7. On 1200Bd, however, 7 frames are sent relatively rarely, since the maximum time of one transmission is restricted to 12 seconds. All QSOs are handled equally, i.e. they share the 12 seconds transmission time. If one station needs a retransmission of frames (e.g. by REJects), MAXFRAME is decreased instantly. In this case it is provable that the throughput is significantly higher when MAXFRAME is set between 1 and 3. Only the quality of the connection TO the other station is checked, not the connection FROM the other station. A poll which gets the acknowledgement of all frames or a lost acknowledgement does not affect MAXFRAME. PERSISTENCE is the most critical parameter when many users are using the same channel. A fixed parameter setting is always only a bad compromise between collision probability and transmission willingness. FlexNet, therefore, makes use of a new access method, which works fully adaptively.

All stations on the channel are permanently counted (column "usr" in the P-list). A waiting time is calculated from this value and from the data rate. The channel needs to be free for at least this time (about 4 secs on 1200Bd and 10 users) to cause FlexNet to think about transmitting. When this time is over, the channel is checked in variable intervals and - if necessary - the node goes "on air". The throughput is drastically increased by this algorithm, especially on duplex nodes. Now aggressive stations do not have the advantage of being serviced faster; there is always enough free time for weak stations. If there are only one or two stations, the channel is almost fully accessed, thus making fast downloads possible on low traffic times. On simplex nodes, of course, many collisions still happen. But even here, the new algorithm improves things significantly. It would be good if the user software could follow this trend to adapt the parameters to the actual conditions. A computer should be able to do this job better and faster than a human could do, especially since it seems to be common that most users are unable to set their parameters correctly.

3.2. The phases of a connection via the Digipeater

3.2.1. Link Setup

During the connection setup the received SABM-frames are routed normally, the UA is not sent immediately. This means that the connection is established only if the called station is reachable. When the called station answers with an UA, this will be routed to the calling station. At this moment, 2 QSOs are in the user list, one from the calling station to the called station, and one back. A special feature of FlexNet is, that the connection can be established in one single step without disadvantages, the common L2 digipeating is simulated. At home, you can directly "Connect <user> via <entrynode> ,<exit node>" or "Connect <destination node> via <entry node>". You do not need several "Connect" commands to make your way to the destination. As hop-to-hop-acknowledgement is still active, the quality of your QSO is not affected.

3.2.2. Information Transfer

During the information transfer, hop-to-hop-acknowledgement gets activated. Every I-Frame is immediately acknowledged by the digipeater. Now the digipeater tries to route the packet further on to its destination. REJects due to interference or collision only happen at one section, not in the whole route.

3.2.3. Link Failure

If the connection breaks at one side during information transfer, the digipeater interrupts the whole connection and displays the message: "*** OK0NE: link failure". Thus, the partner gets informed that something does not work.

3.2.4 Disconnect

When station "A" disconnects, the digipeater responds immediately with an UA. The digi now tries to abort the connection to "B". When there is not any data for station "B" anymore, this happens at once. If there are some I-frames left, they are sent to "B" before the connection is terminated. When "B" tries to send frames to "A", which is already disconnected, these frames are discarded.

3.3. Methods of Routing

As mentioned above, not every digipeater in between needs to be named, only the entry and the destination digipeater must be known. There are 4 methods to route a frame to its destination, tried in the following order:

1 destination table routing
2 link table routing
3 Heardlist routing
4 SSID routing

3.3.1. Destination Table Routing

The first method is based upon the callsign information. The digi tries to look up the destination callsign in a table maintained by the autorouter. If the callsign is found in this list, the frame is sent to the corresponding neighbor.

Example: DB0ODW has the following interlinks: 1:DB0KT 2:DB0AAC 3:DB0IE

and knows the destinations: DB0EQ, DB0ZDF etc. The frame: <fm DG3FBL to DK7WJ via DB0ODW, DB0ZDF> gets expanded to <fm DG3FBL to DK7WJ via DB0ODW*,DB0AAC,DB0ZDF> DB0AAC is now the next call in the digipeater field, and is known as a neighbor of DB0ODW on port 2. So the frame is sent on port 2 to DB0AAC which will then route it to DB0ZDF.

3.3.2. Link Table Routing

When the router does not find a matching entry in the destination table, the digi now tries to look up the call in the link table as set up by the sysop. If a route is found here, the frame is sent to the right port.

Example: DB0ODW has the following interlinks: 1:DB0KT 2:DB0AAC 3:DB0IE 4:DB0AIS #

The frame <fm DG3FBL to DK7WJ via DB0ODW,DB0AIS> is transmitted on port 4, although there is no entry in the destination table. In this case, only the link table is used for routing.

3.3.3. Heardlist routing

The node remembers the last 200 stations heard in an internal list. The SSID of the station is taken care of, if possible. So it is possible to be standby on different ports with different SSID’s without any problems; you will always receive your frames on the right port. Incoming connection wishes and UNPROTOS are routed according to this list.

3.3.4. SSID routing

The last chance to get the frame delivered is the SSID specified for the digipeater. The sysop can assign SSID’s to certain ports using the PARMS command. To make use of the SSID routing, the user just specifies the SSID of the port where he wishes his frame to be transmitted.

Example: DB0ODW has the following mappings of the SSID’s to the port numbers:

port 1 has the SSID -0, port 5 the SSID -12, port 6 the SSID -3

When there is a connect request received which specifies a SSID for the node, the frame is sent on the port specified by the SSID:

<fm DG3FBL to DK7WJ via DB0ODW-12>

This frame is transmitted on port 5, which owns the SSID -12, provided there is no other way known to DK7WJ. On port 5 the following frame appears:

<fm DG3FBL to DK7WJ via DB0ODW-3*>

This ensures that someone on port 5 knows where the frame came from, i.e. the entry-SSID is put into the frame. This SSID change is needed to ensure that the receiver knows where to send his UA to, i.e. port 6 with the SSID -3. This is an important feature of FlexNet. All paths are reversible, i.e. transparent to the receiver, even if the connection came by connecting further on at a node. This routing method is used mainly on user ports.

When all these routing methods fail, the frame is discarded. If the frame was created by an "Connect" command at the node, the user gets the message: "*** <call>: can’t route"

Features

Text messages from the node to a user

Shortcuts for connecting to important stations

<section 7 deleted>

9. Appendix

9.1. Protocol version AX25 V2

FlexNet understands QSO’s with AX25 version 1 and AX25 version 2. A QSO with the node itself can only be done using version 2. When the node encounters a SABM to it with V1, it replies with DM. When station A is trying to connect a station B via the digi using V2, and the other station responds with V1, the connection happens in V1. However, hop-to-hop acknowledgement is disabled for this QSO, it is not even mentioned in the user list.

9.2. Unproto-Frames

All UI- (unproto) frames are transmitted and routed, even frames using protocol version 1. This makes it possible to run TCP/IP without any problems, since most TCP/IP programs send their UI-frames in AX25 V1. The length of the I-field of the UI-frames must not exceed 256 bytes.

9.3. RNR-Behavior/Recovery

Because the memory of the node is limited, it may happen that a user is set to RemoteBusy (RNR) from the digipeater. FlexNet works very defensively in this matter to ensure that there is not too much memory used for one single QSO. It makes no sense anyway to buffer more than about 10 frames for one QSO. RNRs therefore do not mean that the memory of the node is short, but only that there are enough frames buffered to service the QSO fluently. This ensures a fair partition of the channel resources to the QSOs. RNRs often happen in convers mode when one of the partners has a slow link. When the RNR condition has gone, the braked station gets a RR frame with the poll bit set. This causes a RR-final from the station, but only this ensures that the status change is detected by that station. On many AX25-implementations only a RR without poll is sent, which causes hangs of several minutes when it gets lost.

9.4. Reconnects

A special problem on digipeaters with hop-to-hop acknowledgement are reconnects. A reconnect does mean that a station tries to (re-) establish another connect to its partner using the same calls (and SSID’s) and the same or a different path. When this connection happens on a different path, problems may arise. The digi holds the running QSO in his table. When there are no unacknowledged frames, nothing happens. The "zombie-QSO" dies after 15 minutes. However, if there is still data to be sent, the digi tries to service the other station. But since the QSO was re-established using the other path, the sequence numbers of the original QSO do not match with the new ones. This causes a FRMR (frame reject) and the connection is aborted. The best way to avoid this trouble is to end an existing connection properly before establishing a new one.

9.5. I-Polling Method

During a connection, it often happens that an I-frame is not acknowledged correctly. In this case, AX25 V2 says that a poll frame (RR) has to be sent in order to query whether the I-frame was received correctly. If not, the I-frame is retransmitted, otherwise the next frame is sent. However, it is provable that this method causes a useless load to the channel, when the I-frame in question is a very short one. With the I-polling method, the short I-frame is repeated immediately with the poll bit set. This is a mixture of the old V1 and the new V2-protocol version. For statistical reasons, the threshold of this method is set to 40 bytes. Any I-frame with fewer than 40 bytes length is repeated immediately when it was not acknowledged within the FRACK-time (T1). The I-poll method is only used at the first 3 retries, then normal polls are applied.

9.6. Channel Access Method

Up to FlexNet V3.1 the p-persistence algorithm was used. This had the disadvantage that the send-willingness of the station could only be adjusted manually. Since V3.2 there has existed a fully adaptive channel access method, which adapts itself by determining the number of users and the channel allocation to calculate an optimal compromise between throughput and the collision-probability. Variables used:

B Baudrate (1/s)

TxD Tx-Delay (s)

R Random number (1 .. 10)

U Total of the users on the channel

K channel allocation

t1 waiting time after transmission (s)

t2 waiting time between two TX-tries

19200/s

K = (————— + 1 ) * (U + 1)

B

If K > 255, then K is set to 255. This prevents an increase of t1 on more than twenty users on 1200Bd.

t1 = K * (R+1)*8 * TxD

If t1 > 10s, then t1 is set to 10s, this can only happen on baudrates below 1200Bd.

t1 starts when its own transmission has ended. t1 is stopped as long as the channel is busy. As long as t1 is active, the TX is blocked. When t1 has expired, and the node wants to transmit, the DCD is checked in t2 intervals. If there is only one user, t2 becomes 0.

t2 = 2*TxD * (U-1)

When the channel is busy after the expiration of t2, t2 starts again, otherwise the transmission is started. t2 is not interrupted by the DCD.

9.7. Layer 2 States

The second column of the user list shows the actual L2 states. They shall be briefly explained here. For more information, please refer to the AX25-V2 protocol specification. Attention, we are using other numbers for the single states. Only the numbers 1-7 are the same as in the specification. The other states, which are only relevant for BUSY (NR) states, have been done by using bit masks, i.e. there are offsets added.

Disconnected

This state is the default state. No QSO exists at the moment, therefore it is not shown in the user list.

Link Setup

A connection is being set up, i.e. SABM-frames are being transmitted, the acknowledge (UA) has not been received yet.

Frame Reject

Due to a sync error a FRMR-frame was sent, the connection is restarted. This may happen due to a software error or due to two stations with the same callsign.

Disconnect-Request

A connection is being disconnected, i.e. DISC-frames are being sent. The acknowledge (UA) has not been received yet.

Information Transfer

Hopefully, the most seen state. The connection is established, info-frames are being exchanged.

REJ Frame sent

A REJ-frame was sent, because a received frame was not in the correct order. A retransmission is requested.

Waiting Acknowledge

The link is being polled, either because I-Frames have not been acknowledged or because the link has to be checked.

Busy-States

When the station is busy, i.e. cannot receive any more packets, 8 is added to the state number. When the opposite station is busy, 16 is added to the state. When both stations are busy, 24 is added. Thus, numbers up to 31 may occur.

10.  Working with FlexNET group

10.1. Subscription Service

For the FlexNet software, a subscription service is available to sysops. All sysops always get the new versions without looking out for it everywhere. This service is provided free of charge, but cannot be guaranteed. It depends on whether there come in enough donations for funding this service, also there is not always enough time to do it. If you are interested in subscribing, ask the author.

The FlexNet-Group of Darmstadt, and therefore the authors and the maintainers of the software are reachable by mail:
FlexNet Gruppe Darmstadt
Gunter Jost, DK7WJ
Lichtenbergstrasse 77
D-64289 Darmstadt Germany

E-Mail: flexnet@dl0td.afthd.tu-darmstadt.de
(the callsign is "dee ell zero tee dee"

The manual was translated by:
Mario Lorenz,
DG0JAB@DB0JES.#SAA.DEU.EU,
Internet-Email: ml@donald.bsz.szb.sn.schule.de.

11. Legal Terms-License Agreement

The following restrictions have only the purpose to guarantee the quality and the development of the software and, of course, to avoid commercial use of it, except in special cases agreed on with the author of each module. By experience, on uncontrolled distribution it happens that only parts of the software or obsolete versions of it are spread. This results into problems at the end-user’s and into unnecessary and annoying check-backs. Bad experiences cause the list to grow constantly...

• RMNC/FlexNet, PC/FlexNet and the accompanying utilities and the documentation are products of Gunter Jost, DK7WJ. Exceptions are marked as such. All rights reserved by the author. The user is granted the right to use the software under the following conditions:

• The software is used only for non-commercial purposes within amateur (HAM-) radio. All other usages, especially in other radio services, need a written consent by the author in each separate case.

• The legal rules of amateur radio operation are strictly followed.

• Commercial copying and sale of the software is not allowed without prior written consent of the author.

• No changes must be made at the software which are not explicitly agreed with the author. This does NOT apply for setting specific parameters.

• Copyright marks and copyright messages of the software modules must not be changed or removed.

• The software must not be distributed via BBS systems or public accessible bulletin boards, neither in part nor as a whole.

• Neither the author nor the distributors of the software may be liable for any damages, no matter of what kind, which may occur when using the software. THE RISK OF USING THE SOFTWARE IS ENTIRELY YOUR OWN!

Under this conditions you may make as many copies of the distribution disk as you wish and give them away, where you always have to state the original source (FlexNet-Gruppe Darmstadt, G. Jost, DK7WJ). The sourcecode of the software is not available.

11.1. Disclaimer

Neither the author nor the distributor of the software may be liable for any damages that may eventually occur when using the software RMNC/FlexNet or PC/FlexNet. The software is provided "AS IS", without warranty of any kind, including but not limited to the warranties of merchantability and fitness for a particular purpose. No features should be taken for granted. The documentation may contain errors or mis-translations.

By using the software you agree to the conditions above.

12 The End

As I am not a native English speaker, this translation surely contains mistakes. Please send bug reports or suggestions to my Email-address. Thanks.