APRS FUTURE USE of AX.25 SSID RR BITS 05 Dec 2012 ------------------------------------------------------------------- WB4APR Future: This is a preferred method of indicating Operator Present and packet Precedence. It must be considered in conjunction with previous proposals. See priority-bit.txt and operator-bit.txt, though precedence-bit.txt now replaes the previous "priority" bit. Precedence Bit Operator Present Bit Prempted (not used) digipeater bit 3 others - TBD AX.25 has two RR bits in every callsign SSID field. "The bits ... may be used in an agreed-upon manner in individual networks". The bits default to 11. We hope to use these for future APRS features without impacting any existing systems, hardware, firmware or software. There are 4 RR bits in the minimum FROM/TO callsign fields plust 2 more bits for each digipeater field. PROPOSED FROM-CALL RR BITS: The first bit would be a precedence bit. The default (1) means precedence. If the first bit is a (0), then the packet is a new, lower precedence packet (which can be decimated if the network finds this useful). The second bit is an operator- present-bit. PROPOSED TO-CALL RR BITS: TBD PROPOSED DIGI RR BITS: The LSB RR bit (1) (present default) means the field has not been pre-empted. If the bit is a (0) then that field has been pre-empted along the way (assuming the has- been-digipeated-bit has also been set. The MSB RR bit is still TBD and defaults to 1. One of the main drivers for finding these bits was to find a way to mark a digipeater field as having been preempted by a digipeater but keeping the field intact for network tracing. In this use, a premptive digipeater will mark all prior unused fields as has-been- used but will also mark them as "preempted". All digipeater fields after the one used by this digipeater will be retained as unused and available for further digipeating. See http://aprs.org/aprs12/preemptive-digipeating.txt TRANSPARENCY: The bits (being reserved) should be ignored by all existing receiving systems. We must first determine if this is the case for all existing systems. Unfortunately, only hardware and firmware TNC builders can do these tests, since normally the user is not given access to these bits. The easiest tests are to simply set the bits to 00 on transmit, and then operate APRS as normal and see if the bits propogate throught the system and also do not affect any existing function. The following list of tests are known to date: Kenwood - reports the bits -should- be transparent Byonics KISS TNC's - Applications that use TNC's in KISS Mode will have access to these bits for future use. SOUNDCARD TNC's - will also have access to these bits. HARDWARE TNC's - will not have access to these bits witout upgrade but will hopefully pass the bits while digipeating AX.25 FORMATS: Every byte (octet) in the AX.25 header address field has the LSB set to "0" to indicate that additional bytes follow. Only the last byte of the entire address field (FROM, TO, DIGIS...) is set to 1. This address space consists of multiple 7 byte callsigns, with the last byte of every callsign being the SSID byte. The SSID byte contains these bits MSB to LSB: HRRSSIDE Where H is the has-been-digipeated bit. Digipeaters set this bit to 1 RR are the two reserved bits planned to be used by APRS SSID are the four SSID bits E - EXTENSION bit. 0 = more fields follow. 1= this is last field. OTHER USES OF THE RR BITS: DAMA: The RR bit number 5 is being used in Europe where DAMA is popular. But since that is a CONNECTED protocol it has no impact on APRS which is an independent network from DAMA networks. Please see this link: http://www.amsat.org/amsat-new/news/viewBrowse.php?nID=382&y=1996&v=24 AX25 Modulo 128: Andre PE1RDW also reports: ax25 modulo 128 uses bit 6 of the source ssid but only as information for monitoring stations. Bob Bruninga, WB4APR