Talk:AX.25

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

I've created a separate page for AX.25 because I think there are enough things to say about it that are not directly relevant to packet radio—even though I realize there is an inexorable connection between the two topics.

My thinking is that "packet radio" should cover the history, construction, and operation of packet radio stations, while this page can delve into more of the nitty-gritty of the protocol's development, design, and use.

I'll be moving most of what is currently at packet radio over here shortly. Discussion always welcome on my talk page. Simon 15:55, 21 Jan 2005 (UTC)

Below is the text copied from packet radio. I'm placing it here instead of in the article because, to me, it sounds like a rant (even moreso before I made some edits) and is not particularly relevant. Bragging that AX.25 can operate on "multi-megabit" networks is meaningless, for instance, as these networks simply do not exist in amateur radio.

However, some of the information on acknowledgements and so forth could usefully be included in the article.

Version 2.0 and earlier of the specification had limited packet lengths, and for connected virtual circuits, could only transmit eight packets before having to wait for an acknowledgement. These limitations made sense in the context of the noisy, bandwidth-limited channels encountered in earlier packet radio implementations. While good for slower links, however, it was inefficient for faster channels. Today's AX.25, however, supports up to 128 outstanding packets before an acknowledgement is necessary, and packets with up to 8192 bytes of payload data. This makes AX.25 suitable for use on multi-megabit per second networks.
AX.25 version 2.0 and later also supports raw datagram mode of operation too. While using virtual circuits for slower links (e.g., 5 Mbit/s or slower) makes more efficient use of bandwidth and improves end-to-end throughput, the 128 packet window is a limiting factor on faster networks. Therefore, one can use AX.25 entirely in datagram mode as well, thus allowing AX.25 to rival Frame Relay and Ethernet in performance. Support for 8192 byte payloads makes AX.25 suitable for use over multi-gigabit per second networks
AX.25 has been adopted for applications outside of amateur radio as well.
Let me also add: in spite of the last paragraph above, I have never heard of AX.25 being used in a non-amateur setting. I can't imagine what benefits it would offer in a commercial environment over plain old X.25, considering that most of the differences between the two have to do with satisfying legal requirements unique to amateur radio.
Simon 18:14, 21 Jan 2005 (UTC)
Similar functional needs do exist in other applications as well. I recall having seen Geodetic GPS receivers that talk over UHF radio link to exchange ionospheric modelling data and in case of "known position reference" also "dgps" data. Having a bunch of similar devices talking to each other does need some way to identify stations. Identity in those frames is not a "call-sign", but something analogous.
Packet radio is also popular among CB enthusiasts, there are no official callsigns but everybody invents something.
Oh2mqk 11:35, 1 June 2006 (UTC)[reply]

OSI levels[edit]

Since AX25 involves some kind of routing decisions, at least in the unconnected environments used for APRS, or for connection between stations using a digipeater, wouldn't it be better to include "layer 3" in the description? The boundary between PDUs is less strict than in most other "OSI layered" protocols, but routing is conceptually layer 3. Any comment?

--Michael 21:22, 6 April 2006 (UTC)[reply]

AX.25 contains both layer 2 and layer 3 functionality. To some extent, it's not entirely a case of "blurring", because it is almost possible to run AX.25 layer 3 on top of, say, ethernet layer 2 natively (not encapsulating AX.25 frames). It actually IS possible to run other layer 3 protocols (such as IPv4) on top of AX.25 layer 2. Due to the fuzziness of the AX.25 specification's wording (and slight disagreement among variants and updates) it is actually hard to implement AX.25 layer 2 + 3 in a way that is *clearly* spec-compliant.

75.140.251.185 (talk) 20:47, 9 March 2009 (UTC)[reply]

AX.25 doesn't cover third layer. I've been searching on the Internet about AX.25 to write my degree project and I haven't seen that AX.25 covers third layer. --Joseygnacyo (talk) 11:46, 27 August 2011 (UTC) — Preceding unsigned comment added by Joseygnacyo (talkcontribs) 11:38, 27 August 2011 (UTC)[reply]

AX.25 does not specify a level 3 protocol, I think "AX.25 occupies the first, second, and often the third layers of the OSI networking model" isn't the best sentence since layer 3 protocols are above AX.25 not in AX.25 protocol. My words are based on this document: http://www.tapr.org/pub_ax25.html--Joseygnacyo (talk) 16:43, 27 August 2011 (UTC)[reply]

I removed a number of confusing and not very accurate statements about layer 3 functionality. None is included in the definitive v2.0 and v2.2 speces. The Yeti 18:36, 15 January 2014 (UTC)[reply]

" although very little use of AX.25 on HF exists today"[edit]

I think this is wrong. My understanding is that ax.25 is still heavly used in Europe (I gather they route IPv4 over it) and I'm almost sure sailmail and winlink are built on top of ax.25. sailmail and winlink are commonly used aboard vessels far out at sea (e.g. sail boats). I preparing a 35' catamaran to put to sea and AFAIK Iridium, Immersat and AX.25/winmail/sailmail are about my only choices with the first two being too deep for my pocket. Indeed this (http://www.winlink.org/RMSChannels) map shows all the stations known to winlink which (I think) are by definition running AX.25. Please note that I am reluctant to edit the page itself as I'm still ramping up on this subject. — Preceding unsigned comment added by 74.143.73.222 (talkcontribs) 08:28, 16 April 2015 (UTC)[reply]

on bringing article to MOS Wikipedia standards[edit]

to be done:

Wolf1098 (talk) 01:59, 16 February 2024 (UTC)[reply]