1. Why a new protocol?
The good old AX.25 has both good and bad features. Trying to find a better replacement we should first look at the bad features of AX.25 and the reasons why they could not be removed nor corrected. Next we should look at the good features of AX.25 that can not be found in other protocols. This is the way to design a better protocol for the future amateur packet-radio network.
After a few years of experimenting and an initial version AX.25 V1 the protocol specification was finally published as AX.25 V2.0 (1984):
AX.25 V2.0 specification
Some limitations of this AX.25 specification can be overcome easily. For example, the maximum payload length may be simply increased from the specified 256 bytes to 1500 bytes or even more. This brings great improvements especially for TCP/IP over AX.25.
Some specifications of AX.25 are a nightmare for the programmer. Addresses are seven bytes long! The odd, prime number 7 is maybe taken from some fairy tale? Not all bits of these 7 bytes are actually part of the address. Some bits are used for other purposes. Some remained undefined forever. How much programming effort does it take just to compare two AX.25 addresses?
AX.25 V2.0 introduced a terrible nuisance called the poll/final bit. In practice this generates lots of unnecessary traffic of RR-poll/RR-final (RR+/RR-) frames, slowing down the data throughput considerably. Fortunately users could switch back to AX.25 V1 on difficult links like HF. The SuperVozelj nodes use AX.25 V1 to improve the performance of backbone links and let the end user switch to AX.25 V1 if so desired.
Many programmers tried to avoid the RR+/RR- nuisance in their implementations of AX.25. Unfortunately this generated lots of incompatible software. Many AX.25 implementations introduced new protocol mistakes as well.
Some AX.25 software bugs made a really long way! A memory-management bug in the NETROM node firmware for the TNC2 was ported to the TF user firmware for the TNC2, to all versions of the TheNet node software, to the TFKISS program for MS-DOS and finally to some early versions of Linux. One could remotely crash Linux just by sending an AX.25 frame of legal but unexpected length (either too short or too long).
One of the last working implementations of AX.25 with reasonably few bugs (crash at FRMR observed) is Flexnet32 (AX.25 handling) used together with WPP150 (terminal program):
Flexnet32
WPP150The worst mistake of AX.25 is that it groups too many protocol layers into a single protocol. Unfortunately AX.25 was invented when protocol nesting was not generally known yet. Unfortunately AX.25 is not compatible downwards nor upwards with other protocols.
Downward incompatibility means that AX.25 frames may not be transported by a lower-level protocol that does not keep the same frame sequence. Changing the sequence of AX.25 ACK frames generates AX.25 protocol errors. The latter trigger FRMR replies, reset the AX.25 link and crash some AX.25 implementations. The origin of this problem is the way in which AX.25 acknowledges and protocol counters work.
Upward incompatibility is observed easily when TCP/IP traffic is transmitted through an AX.25 link in the Virtual Circuit (VC) mode. The TCP layer may retry the frame transmission before the AX.25 layer receives the acknowledge, especially if the AX.25 link is slowed down by the RR+/RR- nuisance. The resulting congestion triggers further TCP retries into an endless loop. The origin of this problem is that AX.25 insists to do a perfect data transfer regardless of the time required.
Unfortunately, except for the payload length, none of the above-mentioned problems of AX.25 have ever been solved. The last published specification of AX.25 V2.2 (1998) only makes the protocol considerably more complicated. Therefore AX.25 V2.2 was never implemented in practice on any known hardware:
AX.25 V2.2 specification
Since these well-known problems of AX.25 have never been solved, AX.25 can not compete with commercial internet nor other modern communications. AX.25 networks all over the world were abandoned. The only application where AX.25 frames are still being used are very-low-rate communications like APRS:
APRS V1.0.1 specification
Unfortunately the inventors of APRS introduced their own protocol mistakes. A major mistake of APRS is the removal of the AX.25 destination address. Therefore APRS frames can not be routed through a standard AX.25 network. Since there is no destination address, replies to APRS messages can not be sent back to the original sender.
APRS is quite popular today and will probably stay popular in the future, since there are no inexpensive alternatives for very-low-rate communications. Any future amateur packet-radio network should therefore also support APRS in spite of the many design errors of the latter.
Inexpensive WLAN (WiFi) commercial equipment uses the IEEE 802.11 family of protocols. The latter only work over a single radio link. Network routing is performed at the next higher protocol layer (IP). The symbol rate is usually fixed in a particular 802.11 protocol. Different data rates are obtained using different symbols and different degrees of Forward Error Correction (FEC).
Simple IP routing as built in WLAN (WiFi) equipment only works fine for individual users accessing the public internet at the root of a tree network. Direct user-to-user communication is difficult if possible at all. Even more difficult is the opposite way, calling form the public network back to individual WLAN (WiFi) users.
An amateur packet-radio network implies an arbitrary network topology, preferably a true mesh network. Direct user-to-user communication should be possible without any help from an almighty server somewhere in the galaxy. The same protocol should allow communication between very different users operating at data rates that may differ by several orders of magnitude!
Last but not least, in order to keep radio amateurs interested in the operation of the packet-radio network as well as keep them experimenting with new techniques, routing should be controlled by the end users, not by the network nodes. The operation of the whole network should be clearly visible to all users. This is just the opposite of professional requirements, where the user data has to be encrypted and the network operation has to be kept hidden for security reasons.
AX.25 complies with all these requirements for an amateur network! AX.25 is scalable to data rates differing several orders of magnitude. AX.25 nodes allow any network topology. Besides simple digipeater service, AX.25 digipeater addressing allows passing different routing information to more complex network nodes like RMNC (Rhein-Main Network Controller) or SuperVozelj.
Commercial protocols, in particular the IEEE 802.11 family used in inexpensive WLAN (WiFi) equipment, do not meet the above requirements! Although WLAN (WiFi) equipment including its protocols may still be very useful to radio amateurs, a new protocol is required for the core packet-radio network. Of course, the new protocol should avoid the mistakes of AX.25. On the other hand, all of the good ideas of AX.25 should be made available again!
In 2009 the old AX.25 was mostly abandoned all over the world. In Slovenia there were many SuperVozelj nodes still operational. There were a few users still struggling to get internet access through the inefficient AX.25. Some users were hanging on the last operational DX cluster. The only remaining AX.25 BBS in Maribor had no more users at all. Find the place for all that obsolete equipment in the local museum or invent something new, that was the question!
The answer was the invention of a completely new protocol called NBP in 2009...
2. NBP fundamentals
The main requirement for a new amateur packet-radio protocol is to make radio links as reliable as wire links. Any other requirements should be met by higher-layer protocols at the discretion of the end users, thus allowing as much experimentation as possible. The new protocol was named "Ne-Brezhibni Protokol" (NBP) meaning Non-Flawless Protocol:
NBP is designed to make the likelihood of frame loss or duplication reasonably small by suitable design choices. On the other hand, the likelihood of these undesired events can not be made mathematically identical to zero without making the protocol considerably more complex, introducing delays and compromising the compatibility with higher-layer protocols. Therefore NBP is intentionally made imperfect!
On the other hand, all known communication protocols rely on checksums or better CRCs to eliminate data corrupted in a noisy transmission channel. Regardless of the CRC size, there is always a small, but finite and non-zero probability that a divisible error occurs during transmission. It therefore makes little sense to seek perfection in other parts of a communication protocol, especially if this partial perfection creates bottlenecks, complexity and incompatibility!
NBP is designed both for radio links between network nodes and for simple wire links inside a network node. The NBP frame size supports the standard Ethernet IP MTU of 1500 bytes. NBP is designed to run on 32-bit microprocessors, therefore all protocol variables are 32-bit numbers except the payload, which must have an integer number of bytes:
NBP uses two different type of frames over a radio link: a data frame and an acknowledge frame. A NBP data frame includes a 32-bit tag field, two address paths, a payload and a CRC. In a radio transmission, carefully chosen 32-bit pseudo-random numbers (PRNs) are used as 32-bit tags to uniquely identify a particular data frame on a particular radio segment of the network. The same PRN is used for the initial transmission and for any retries of the same data frame.
The correct reception of a data frame is acknowledged by replying with the same PRN. The NBP acknowledge frame only contains the PRN, one single address (acknowledges may be sent to the broadcast address ALL) and the CRC:
The address information in a NBP frame includes a forward address path and a return address path. Both address paths include between 1 and 16 addresses and are terminated with a separator (32-bit zero is a prohibited address). The immediate destination of the frame is the first address in the forward address path, in other words the 32-bit field immediately following the PRN.
Most NBP frames are addressed to a single destination. NBP also allows a broadcast address (ALL) specified by having all ones in the 32-bit address. All NBP stations are expected to listen to the broadcast address. The forward address path may contain more than one broadcast address. The return address path should not contain any broadcast addresses.
After receiving a valid data frame, the NBP station shifts the forward address path down by one address. The address shifted out at the bottom is discarded. The NBP station own address is added to the beginning of the return address path. The size of the forward address path is decreased by one address while the size of the return address path is increased by one address. The total length of the NBP frame thus remains unchanged!
If the forward address path still contains one or more valid addresses after the above-mentioned address rotation, a new PRN is assigned to the NBP frame, a new CRC is computed and the frame is forwarded to the next radio link.
If the forward address path is empty after the above-mentioned address rotation, the receiver simply uses the payload. The information contained in the return address path may be used for an immediate reply and/or to update the routing table of a supported higher-level protocol.
NBP addresses are 32-bit numbers. The latter are sent over radio and wire links and are understood perfectly by computers running the described protocol. On the other hand, such large numbers are difficult to read, memorize and type again for humans. A simple and efficient human interface is modulo (36) encoding:
The modulo (36) coding table includes 10 decimal digits 0..9 and 26 letters A..Z as symbols of a 36-symbol character set. NBP addresses are therefore written as simple alphanumerical strings containing up to 6, sometimes even 7 characters. The only limitation is that trailing zeros are not displayed. Short names of people and places, abbreviations for frequency bands, radio-amateur callsigns etc can all be typed in as valid NBP addresses!
The special broadcast address includes 32 logical ones or 0xFFFFFFFF in hexadecimal. In the described modulo (36) encoding, the broadcast address is represented by the string "3Z141Z1". Rather than using this ugly string, an asterisk "*" is generally used to specify the NBP broadcast address.
NBP equipment never makes any unsolicited transmissions, like sending beacons, status messages etc. Network discovery may always be performed by the final user with one or more broadcast addresses "*" in the forward address path of a remote command. Besides an unknown end station network discovery may also include unknown nodes.
Any NBP data frame sent to a broadcast address will be multiplied to all available ports of a NBP node. Usually, a broadcast frame will be sent at the same time both to the radio port and to the local wire loop. The radio transmission will not expect an acknowledge nor it will ever be retried. Asterisks "*" must be used with caution since the number of replies grows exponentially with the number of broadcast addresses in the forward address path!
3. NBP radio transmission
Noise, interference, multipath distortion and collisions corrupt the data transmitted through a radio channel. If a data frame is lost, its transmission has to be repeated. On the other end of the radio link, correct reception has to be acknowledged and duplicates have to be discarded. All these actions require labeling the data frames with unique tags.
Unique tags can not be computed from the frame content. The information stream may contain two or more identical data frames. The receiver might consider all subsequent identical frames as duplicates if the unique tags were derived from the frame content alone.
Protocol counters are frequently used as unique tags. Counters require link establishment, synchronization and link reset. The AX.25 protocol is a clear example of several unfortunate choices for the protocol counters, increasing the protocol complexity and severely limiting its compatibility both downwards and upwards.
NBP uses large (32-bit) pseudo-random numbers as unique tags for the data frames. 32-bit numbers are large enough so that the likelihood of finding two identical ones is small enough. Pseudo-random numbers are generated by a 32-bit primitive polynomial generator. Further, the 32-bit station own address is added to the 32-bit result so that each NBP station generates its own, different sequence of pseudo-random numbers:
The NBP receiver acknowledges all correctly received frames. The PRN unique tag is compared to all of the entries in a circular table. If an identical entry is found in the table, the frame is considered a duplicate and it is discarded. If there is no identical entry in the table, the frame is considered valid and its PRN unique tag is entered in the circular table, replacing the oldest entry.
The circular table contains 1024 entries. This table size is large enough to allow all sensible settings of the retry parameters. On the other hand, the table is small enough to to be scanned in a reasonable amount of time by the CPU.
The acknowledge protocol described above may not maintain the same sequence of the data frames. A later frame may get through immediately while an earlier frame waits for several retries. Changing the sequence of data frames has no effect on TCP/IP nor on many other higher protocols, since they are all designed to operate in even more complex environments.
Unfortunately, changing the sequence of AX.25 acknowledges may crash the AX.25 protocol into a FRMR link reset. AX.25 tunnels through the NBP network may not work reliably. Fortunately, this event is very rare when the AX.25 speed (1200bps) is much smaller than the NBP speed (>1Mbps). Setting the AX.25 parameter MAXFRAME to 1 also solves the problem in most cases. APRS tunnels are not affected, since AX.25 protocol counters are not used in APRS.
A unique tag of all (32) zeros is not allowed. This could be used to run different protocols over the same radio link.
A unique tag of all (32) ones has a special meaning. This unique tag does not require acknowledgment nor it is ever compared to the content of the circular table. The corresponding data frame will not be retransmitted automatically so that duplicates can not be generated. This special unique tag is usually (but not necessarily) associated to broadcast messages intended to all listening stations.
NBP uses simple random access to a simplex radio channel. Although undesired, collisions are expected. In order to control collisions, the retry-delay time is made proportional to the number of retries already performed. Further, the retry-delay time includes a random component, so that the two colliding transmitters will not collide at the next retry as well:
The original implementation of NBP uses HDLC (X.25) framing on the radio link. Besides backward compatibility with AX.25, HDLC framing offers several advantages in a simple radio link. HDLC framing offers really low framing overhead (few inserted zeros) compared to other methods like 4B5B. Start (head) and stop (tail) flags can also be used as synchronization sequences. The NRZI(0) differential encoding guarantees clock recovery but at the same time solves the BPSK RTX signal-polarity ambiguity:
A NBP transmission packet may include more than one frame. All NBP acknowledge frames are included in the first available transmission packet and are always located at the beginning of the transmission packet. Some NBP data frames may be inserted in the transmission packet. Some data frames waiting for acknowledge may not be transmitted in the first available packet.
The NBP specifies that each data frame travels autonomously, independent of other data. Each data frame has its own retry counter. Each data frame waits its own retry timer to expire.
Although small and obsolete by today's standards, the same 16-bit CCITT-CRC was found sufficient for NBP radio links. The same algorithm is used both for CRC generation in the transmitter and for CRC check in the receiver. The content of the TX CRC generator is inverted before transmission so that it is subtracted from the content of the RX CRC checker. After 16 clocks of processing, a correct CRC subtraction will produce the pattern 0xF0B8 in the CRC checker:
Finally, all successful modems, bit synchronizers, scramblers and radio transceivers originally developed for AX.25 can also be used for NBP links. Using HDLC with NRZI(0) encoding, a Manchester modem can solve the DC-component problem with WBFM radios while a K9NG/G3RUH scrambler can solve the same problem with ZIF-BPSK radios.
Last but not least, any network protocol has to deal with congestion. Radio transmission of data frames requires buffer memory while waiting for acknowledge or retry. NBP equipment handles congestion with a special parameter called MINBLOK:
As long as the amount of free buffer-memory blocks exceeds MINBLOK, the data frames are transmitted as usual waiting for ACK and retransmitted if necessary. As the amount of free memory blocks drops below MINBLOK, the exceeding waiting data frames may only be retransmitted once in the next transmission packet and discarded immediately afterward. The oldest data frames are discarded first, maybe after giving them one last chance to get transmitted.
In the worst case, all buffer memory is filled with data frames. In this case NBP equipment does not crash, but discards all incoming data frames immediately. This situation will only persist for a limited amount of time to the next packet transmission, after which memory will be freed up to at least MINBLOK.
The above two-step, controlled discarding of valid data frames is exactly what higher-level protocols like TCP expect from the network-congestion control. In the case of discarded frames, TCP will adjust its transmission window to control congestion. This makes a perfect match between NBP and TCP and explains why is NBP really efficient for TCP/IP traffic.
The above discussion may give the wrong impression that the cause of congestion is the limited amount of buffer memory. This is not true at all! The real bottleneck is the radio channel. MINBLOK should be set to avoid congestion of the radio channel with many data frames being retransmitted simultaneously. Considering practical retry-timing parameters, not more than 50kbytes of memory may be allocated to the transmit queue awaiting acknowledge to avoid congestion of the radio channel.
4. NBP wire transmission
A network node may be designed in many different ways. There may be just a single microprocessor controlling all radio links. On the other hand, each radio link may have its own microprocessor communicating via wire links to other node members. Both solutions have their own advantages and disadvantages.
In a SuperVozelj node, a single microprocessor is controlling up to eight radio transceivers. Provided that the microprocessor has enough computing power and enough memory, this solution is simple and efficient. The only drawback is system reliability. A completely independent remote-reset telecommand is required.
NBP started with the development of an Advanced Terminal-Node Controller (ATNC or ArmTNC). For best performance, its microprocessor can only control a single radio channel. NBP requests that each ATNC also works as a small network node if required. More complex NBP nodes, also called Advanced SuperVozelj (ASV), can simply be obtained by connecting more ATNCs in a wire loop.
A wire loop has two disadvantages. First, data flow is delayed due to the additional wire links. Second, reliability is compromised since a single failure might break the loop.
On the other hand, an independent remote telecommand is not required in a multiprocessor node, since the whole-node-reset command can be issued through one of the surviving node members. Network upgrade is simple, since new, even more advanced ATNCs can simply be inserted in the existing loop. Last but not least, the same software runs both in home ATNCs as well as in mountaintop ASVs, thus greatly simplifying system development.
NBP wire transmission uses simple UARTs available in all known microprocessors. Although this solution may seem obsolete, it is very efficient! Modern UARTs run at 5Mbps or more in full-duplex. This is actually faster than 10Mbps Ethernet or full-speed USB (12Mbps), since the latter two are slowed down by the overhead of their complex protocols. The power drain and radio-frequency interference of UARTs is much smaller than Ethernet or USB interfaces.
SLIP framing is used for the NBP data frames transmitted through an asynchronous line:
All experiments confirm that data transmission through UARTs is very reliable, provided that the UART driver software does not contain errors. A NBP wire transmission therefore does not need CRCs nor acknowledgments nor retries. NBP data frames can be simplified for wire transmission and there are no acknowledge frames:
In a typical ASV wire loop, the transmitting ATNC#M simply inserts the NBP data frame into the loop. The NBP data frame then travels around the loop. Each member of the loop checks its immediate destination address. If the addresses match, then ATNC#N processes the NBP data frame in the usual way. If the NBP frame is addressed to someone else, the member reinserts the same NBP data frame back into the loop.
In any wire-loop protocol, the most dangerous thing is a data frame that no one wants. Such a data frame might circle the loop forever. All frames traveling through loops must have a lifetime counter that expires after a reasonable number of hops.
In NBP frames sent over wire loops, a 32-bit lifetime field replaces the PRN unique tag of the radio version. Each loop member shifts the lifetime field down by one nibble (4 bits), inserting four zeros at the top. When the content of the whole lifetime field becomes zero, the data frame is removed from the loop. As a NBP data frame may make up to 8 hops, a NBP wire loop may have up to 9 participants.
The current version of NBP actually supports two different wire-loop protocols that are specified with the bit pattern in the lifetime field. The first protocol is described in the above example, where ATNC#M fills the lifetime field with 32 ones or 8 nibbles 0xF. The latter tell the receiver to check the current destination as described above. A frame with an expired field is discarded in this protocol.
The other wire-loop protocol is the ASV node skip. The sender ATNC#A inserts a specified number of 0xA (1010) nibbles in the lifetime field, while the rest of the latter is filled with zeros. The immediate address is not compared in the ASV node skip. The NBP data frame is reinserted back into the loop as long as the lifetime field is different from zero. When the lifetime field becomes zero, the data frame is processed regardless of its immediate address.
The purpose of the ASN node skip is to use just one address while traveling through two members of an ASV node:
In the ASV node skip, most of the NBP data frame processing is done in the first ATNC#A. The latter identifies that the frame is addressed to some other member of the same loop, rotates the addresses and inserts the distance to ATNC#B in the lifetime field. ATNC#B inserts this frame into the transmit queue adding just a new PRN and the CRC for radio transmission.
The ASV node skip virtually doubles the number of addresses in the forward address path. The NBP data frame may travel through 30 nodes before reaching the final destination. On the other hand, the ASV node skip greatly simplifies manual path insertion, since only nodes with a radio output need to be specified.
5. NBP payload handling
NBP equipment may carry different data in the payload field:
The higher-layer-protocol data frames are simply inserted in the payload field. Protocol distinction is at user discretion. Even if this makes no sense at all, IP4 frames may be sent to an AX.25 KISS destination for example.
The only exception to the above is the NBP service channel. Service channel payload starts with yet another 32-bit separator. Since no other known communication protocol starts with 32 zeros at the beginning of the frame, a service channel payload can be identified uniquely in this way.
The main purpose of the NBP service channel is direct chat with another ATNC in plain ASCII text. The service channel may also be used to issue remote commands to another ATNC. Remote commands are identified by the ASCII string "////" or 0x2F2F2F2F after the additional 32-zero separator. Remote commands include a link test with pseudo-random sequences of selectable length up to the maximum allowed frame size.
The service channel has its own, independent service address path. Other data frames may go through additional processing. Not all functions are available in all versions of the ATNC, Ethernet-ATNC (EATNC) or Modem-ATNC (MATNC). Some functions are drawn twice for clarity on the following diagram:
Automatic NBP routing is supported for IP4 addresses and AX.25 callsigns. The routing algorithm is similar to the AX.25 routing of IP4 frames experimented with great success in the AX.25 megabit KISS/SLIP TNC. The default route usually points to a server (an internet gateway) while an additional routing table may point to individual IP4 addresses of other users.
AX.25 is considered yet another higher-level protocol for NBP besides IP4. NBP equipment may be programmed to perform automatic IP4 or AX.25 routing, but of course not both at the same time. In the case of AX.25 routing, only the six callsign characters are stored using the NBP modulo (36) encoding, while the AX.25 SSID is ignored for routing.
NBP routing may use a default address path and/or a NBP routing table:
The NBP routing table may be inserted manually or updated automatically:
In addition to IP4 and AX.25, routing of IP6 traffic through the NBP network may be required in the future. Although IP4 and IP6 are very similar protocols, they are used in different ways. We usually use fixed IP4 addresses from the 44.x.x.x range to identify users in amateur-radio communications. All connections to the public networks are made through NAT (or IP masquerade) routers. The same 44.x.x.x user may therefore appear with different IP4 addresses in the commercial internet.
IP6 is supposed to use global addresses without any NAT. At least the upper part of an IP6 address has to be assigned automatically by the global network. Accessing the global network from a different location changes the IP6 address as well. Such an IP6 address can hardly be used for identification in an amateur packet-radio network. A simple workaround could be using Ethernet MAC addresses for identification and NBP routing.
6. NBP experiments
During the first three years of experimenting with NBP, an extensive packet-radio network was built in western Slovenia with some links spanning up to 80km:
The practical results are as follows:
(1) internet download speed through few 2Mbps links around 100kbyte/s,
(2) internet download speed through many 1.2288Mbps links around 50kbyte/s,
(3) full-duplex ATV contact with two-way voice and two-way live video 320X240 at 10fps over the whole network,
(4) webcam live video 640X480 at up to 5fps,
(5) four APRS receivers on 144.8MHz forwarding traffic to the S55AOP APRS gateway through the NBP network,
(6) virtual 38.4kbps AX.25 port on S55YCP though the S55YNG AX.25 gateway,
(7) NBP-WLAN gateway S55YFH successfully bridging the NBP network to the WLAN network "Burja" in both directions,
(8) very efficient 70cm 1.2288Mbps NON-line-of-sight links providing 50kbyte/s internet download.
The following unusual and/or unexpected features of NBP were observed:
(1) the NBP node works immediately after power on, no boot time,
(2) resetting or cycling the power of a NBP node only produces some lost or duplicated frames while the TCP/IP connections continue to run smoothly,
(3) the TCP/IP throughput with hidden stations was found much better than ALOHA predicts,
(4) the NBP congestion control matches perfectly what TCP understands,
(5) the NBP hardware may be programmed to forward the TCP/IP traffic of a single user to two or more internet gateways accessing different public networks,
(6) the NBP node software NEVER crashed in three years of operation,
(7) the NBP network tolerates two or more participants with the same address on the same frequency and in some cases these two participants can even cooperate, like forwarding aggregated APRS traffic to two different APRS gateways,
(8) two or more ATNCs can be connected to the same radio to provide different services, for example S50AOP internet gateway and S55AOP APRS gateway on the same 430.8MHz BPSK RTX,
(9) two or more ATNCs can be connected to the same radio to provide different access speeds, for example S52YNG at 2Mbps and S58YNG at 1.2288Mbps both connected to the same 2360MHz BPSK RTX,
(10) new NBP equipment and old AX.25 SuperVozelj nodes can coexist using the same BPSK radios at the same speed or at different speeds,
(11) pretty reliable AX.25 operation through NBP was found possible at low to moderate speeds, as long as NBP links are fast enough to avoid swapping the sequence of AX.25 frames.
As a conclusion, NBP practically demonstrated excellent performance, compatibility and coexistence with all other known hardware and protocols.
7. Further increasing the transmission speed and protocol efficiency with NBPv2
The original NBP HDLC (X.25) radio-frame specification is fully backward compatible with AX.25. Unfortunately suitable HDLC hardware like the Infineon SAB82532 HDLC controller is no longer being manufactured. Careful machine-language coding allows a software implementation of a HDLC controller up to 2.5Mbps on an ARM7 microcontroller with a fast SPI port. Beyond 2.5Mbps some external hardware is required as well as a fast interface to a microcontroller.
The fastest data interface on most single-chip microcontrollers is the RMII (Reduced-Media-Independent-Interface) used for 10/100Mbps Ethernet. NBPv2 uses HDLC framing for the Ethernet frames generated by the RMII. The payload of these Ethernet frames are the standard NBP frames. In addition the Ethernet frames include an Ethernet sync header, a carefully-selected Ethernet destination address 58-86-FB-E8-9B-1C, a zero Ethernet source address, a standard 2byte Ethernet length field and a 4byte Ethernet CRC field:
The Ethernet frames are transmitted using HDLC framing. HDLC flags are used as the TX synchronization head, as idles between Ethernet frames and as the TX tail. As allowed by the Ethernet specification, the Ethernet sync header may be truncated to simplify the HDLC framing. Since standard Ethernet frames may contain filler zero bytes for very small payloads, the NBP frame length has to be described in the standard 2byte Ethernet length field.
In addition the RMII ports of some microcontrollers require an additional dummy Ethernet frame in the TX synchronization head to avoid frame loss. The interface between a LPC23xx microcontroller RMII port and a data radio transceiver requires a digital circuit programmed in a 32-macrocell Altera EPM3032ATC CPLD. Besides the parallel(RMII)-to-serial(HDLC) conversion and back and the NRZI(0) differential encoding/decoding the latter also stops the RMII REFCLK during HDLC zero insertion/removal:
The described Ethernet framing may be quite efficient for long NBP data frames. Unfortunately Ethernet framing is rather inefficient for the original short NBPv1 acknowledge frames. Therefore NBPv2 assembles up to 16 NBP acknowledges into a single Ethernet frame resulting in an overall throughput improvement of about 3%:
NBPv2 was tested with suitable hardware up to 32Mbps. Unfortunately due to other bottlenecks (processor speed and other interfaces) the information transfer does not improve above 15Mbps. The real-world performance of NBPv2 is impressive with 10Mbps BPSK radios. An information-transfer speed of about 8.4Mbps is regularly achieved on real-world radio links with propagation delay, noise and interference, resulting in a record simplex-radio protocol efficiency of 84%:
Please note that the above result can only be obtained with perfect Ethernet equipment on both ends. For example, if the Ethernet equipment does not implement the IEEE 802.3x flow control (many cheap routers and/or peripheral drivers do not), the transfer rate drops from 8.4Mbps down to about 7Mbps. The workaround is to insert a cheap Ethernet switch with hardware flow control between the NBP equipment and other Ethernet equipment to act as a data buffer.
Unfortunately the NBPv2 with HDLC-packed Ethernet frames (32-bit Ethernet CRC) is not compatible with the original NBP with true HDLC frames (16-bit HDLC CRC). On the other hand, the efficient NBPv2 acknowledge could also be implemented in the original NBP frames. If incompatible NBPv1 and NBPv2 acknowledges are used with the same frame format (HDLC or Ethernet but not both), the link still works without acknowledges but the transfer rate drops to about 30% of a fully compatible link.