IGate Design

Skip Navigation LinksAPRS-IS > APRS-IS Specifications > Connecting to APRS-IS > IGate Design

An IGate (Internet Gateway) has two functions: to pass all packets heard on RF to APRS-IS and to pass all message packets destined for local stations to RF (if a bidirectional IGate). The first part of this is sometimes misunderstood. It should be to pass "all valid AX.25 packets with a control field of 0x03 and a PID of 0xF0 and that did not originate on APRS-IS and that are not generic queries". The "valid" part means that that CRC is valid. Do not set passall on in your TNC. The AX.25 control field and PID designate a non-level 3 protocol using UI frames.

An APRS packet that is a third-party format with either TCPIP or TCPXX in the third-party header is considered to have originated from APRS-IS and must not be gated back to APRS-IS. This is to ensure no RF delays will induce looping.

Generic queries are APRS query packets that are not directed to a single station. Blocking these packets prevents a station on RF from generating thousands of responses.

Passing all message packets also includes passing the sending station's position along with the message. When APRS-IS was small, we did this using historical position packets. This has become problematic as it introduces historical data on to RF. The IGate should note the station(s) it has gated messages to RF for and pass the next position packet seen for that station(s) to RF.

An IGate should be set for the minimum number of hops necessary to cover the intended area (both in the transmit path and what is considered a local station). It should only gate to RF for local stations heard within 1 hour (or less) and within the intended coverage area (should be based on digipeater hops, not distance, although this is more difficult with the multitude of UIFlood and UITrace implementations).

The two areas of the APRS specification that have a direct affect on IGates are:

Third Party Packets

The link to the left takes you to the chapter in the specification on third-party packets. At this time, all IGates strip any path information out of the third-party header to reduce bandwidth requirements and maintain AX.25 packet length compatibility. 

* An IGate should not gate third-party packets (data type }) with TCPIP or TCPXX in the third-party header to APRS-IS. Third-party packets without TCPIP in the header are to be gated to APRS-IS AFTER stripping the RF header and third-party data type.

Queries

The link to the left takes you to the chapter in the specification on queries. An IGate responds to an ?IGATE? query with a station capabilities message of the format

<IGATE,MSG_CNT=n,LOC_CNT=n

The IGate may append other user information.

* An IGate should not gate generic queries (data type ?) to or from APRS-IS.

Only stations with a validated login are allowed to gate to APRS-IS.

No modification of the TNC2 format line should be made except to add ,qAR,IGATECALL to the end of the path (and the third-party exception noted above). IGATECALL is the callsign-SSID of the IGate and denotes the point of entry for the packet. The data portion of the packet should never be modified (with the third-party exception noted above).

Remember that an IGate has access to over 30 kbps of data. You do not want to try to gate everything to RF or no one will be able to use the frequency. Any special gating to RF should be done with the utmost consideration of the effect to other Amateurs in the reception area.


APRS® - APRS Software and Bob Bruninga, WB4APR.
Copyright © 2017 - Peter Loveall AE5PL
Hosted by AME Corp.