Zum Inhalt springen
aprs.helpAPRS-Wissen und Ressourcen

IGate and data exchange with APRS-IS

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

An IGate (Internet Gateway) connects the APRS radio network to APRS-IS. It receives packets over radio and forwards them to the Internet network. A bidirectional IGate can also transmit selected packets received from APRS-IS on RF. It is not, however, a transparent bridge: different forwarding rules apply in each direction, and APRS-IS servers play an important role on the Internet side.

From RF to APRS-IS

The primary task of an IGate is to make packets received over radio available on APRS-IS. These include positions, messages, objects, telemetry, and weather data. An IGate forwards valid packets while preserving their contents and radio path, subject to rules preventing the same data from being reintroduced into the network.

Under IGate rules, the following must not be forwarded to APRS-IS, among other things:

  • AX.25 frames without the proper UI control (0x03) and PID (0xF0) fields;
  • frames received in PASSALL mode, which does not guarantee data integrity;
  • general APRS queries beginning with ?;
  • packets containing TCPIP or TCPXX in their path and, according to the applicable rules, NOGATE or RFONLY;
  • third-party packets containing TCPIP or TCPXX in their inner header.

For a third-party packet without those markers, the outer radio header and third-party marker must be appropriately removed before forwarding it to APRS-IS.

An IGate must not arbitrarily rewrite the packet path. It records that the packet entered APRS-IS from RF in the designated part of the header.

q construct: identifying packet origin

A q construct is a header mechanism used exclusively in APRS-IS. It identifies how a packet entered the network, indicates its entry point, and helps detect loops. It is not part of the AX.25 radio path and must never be transmitted on RF.

Example of a packet received on RF:

SQ9ABC>APRS,WIDE1-1:!5000.00N/01900.00E-

After forwarding by bidirectional IGate SQ9MDD-4, its APRS-IS header may look like this:

SQ9ABC>APRS,WIDE1-1,qAR,SQ9MDD-4:!5000.00N/01900.00E-

qAR indicates a packet gated from RF by an IGate capable of forwarding messages to that station. SQ9MDD-4 identifies the entry point. This notation alone does not prove that a message will actually be transmitted on RF: that also depends on the IGate’s forwarding rules and network conditions.

The principal constructs encountered in APRS-IS are:

Construct Meaning
qAR Packet gated from RF by an IGate declaring the ability to forward messages to that station.
qAO Packet gated from RF without the ability to forward messages to that station, particularly by a receive-only IGate.
qAC Packet originating directly from a client with a successfully verified login, marked by the server.
qAS Packet received by a server without an existing q construct or generated by the server.
qAU Packet received directly via UDP.
qAI Construct for tracing a packet’s route through APRS-IS servers.

The documentation also describes constructs associated with older packet-forwarding methods, including qAr and qAo, as well as deprecated unverified-login mechanisms. Letter case in q constructs matters.

Do not treat qAR as proof that an IGate has a physically operational transmitter, or qAO as meaning only that it lacks a transmitter. A bidirectional IGate may also use qAO for a station to which it will not forward messages.

From APRS-IS to RF

Forwarding data from the Internet to the radio channel is much more selective. The entire APRS-IS stream must not be retransmitted: doing so would quickly overload the local channel.

A bidirectional IGate’s primary use is delivering messages to stations within its radio coverage. Under the basic IGate criteria, it forwards a message and associated position packets when the relevant conditions are met:

  • the addressee has been heard on RF within a configured time window and falls within the IGate’s service area, defined, for example, by DIGI hop count or distance;
  • the message sender has not recently been heard locally on RF;
  • the sender’s packet does not contain markers blocking this forwarding, notably TCPXX, NOGATE, or RFONLY;
  • the addressee has not recently been seen as a station available directly via the Internet.

The exact time windows, radio service area, and additional restrictions depend on IGate configuration. The operator may also define criteria for forwarding selected other packets, such as particular objects. Receiving a packet from APRS-IS does not automatically mean that the IGate will transmit it on RF.

APRS-IS filters and automatically delivered traffic

An IGate often connects to the filtered APRS-IS port 14580. A server-side filter specifies an additional data stream that the client wishes to receive. It does not replace the server’s basic mechanisms for communicating with stations served by the IGate.

Example filter:

filter m/10

m/10 defines a 10 km radius around the last known position of the callsign used to log in to APRS-IS. It is not the IGate’s radio reception radius, an area around all stations it has heard, or an absolute limit on data delivered by the server. If the server does not know the login callsign’s position, the filter has no established reference point.

An equivalent filter with a fixed center is, for example:

filter r/50/19/50

It covers positions and objects within 50 km of 50°N, 19°E, as well as messages addressed to stations located in that area. In both cases, the additional subscription operates alongside the server’s basic stream, not instead of it.

What does the server deliver independently of the additional filter?

The APRS-IS filtering documentation identifies three important categories of traffic delivered by default on the filtered port:

  • APRS messages addressed to the logged-in client and to stations whose packets that client has gated from RF to APRS-IS.
  • Associated positions of message senders: the next available position report from a station that sent such a message. This does not mean automatically delivering its entire position history.
  • TCPIP packets from stations gated by the client: this mechanism requires no preceding message. It can cause subsequent packets from a station previously introduced to APRS-IS by the IGate to arrive even when that station is outside the filter radius.

The last point is particularly important when interpreting real logs. Not every packet received from outside m/10 is a message or the position of a message sender. The server may also deliver Internet-originated traffic from stations associated with the IGate through earlier RF gating.

Inclusive filters are additive: a packet matching any active rule may be delivered. Exclusion filters restrict additional subscriptions but do not disable standard message handling. Filtering applies to the stream from the server to the client. It does not restrict packets the IGate sends to APRS-IS.

How does long-distance RF reception affect the APRS-IS stream?

An IGate’s radio coverage varies. During enhanced propagation, it may receive a station hundreds of kilometers away, either directly or through digipeaters. In either case, the packet may legitimately be gated to APRS-IS. The radius configured in the Internet connection’s filter does not limit this process.

Consider an IGate with the m/10 filter:

  1. The IGate receives a distant station’s packet on RF, for example through tropospheric propagation or a route via a DIGI, and forwards it to APRS-IS.
  2. The server includes that station in its mechanisms for handling traffic gated by the client.
  3. If the station subsequently sends packets directly to APRS-IS with an Internet TCPIP path, the server may deliver them to this IGate regardless of m/10. No APRS message is required.
  4. If another station sends a message to the station previously gated by the IGate, the server also delivers that message and the next available position report of its sender. The sender may also be far outside the filter area.
  5. Receiving these packets from APRS-IS does not mean the IGate automatically retransmits them on RF. IS-to-RF forwarding follows separate rules.

Consequently, a small geographic filter can coexist with intermittent packets from much more distant stations. This is not an expansion of the m/10 radius, but the parallel operation of the APRS-IS server’s basic functions. It may be particularly noticeable after periods of long-distance RF reception, when the IGate has gated packets from stations it does not normally hear.

Two different cases that are easily confused

Packets from a station previously gated by the IGate. The IGate receives SQ9ABC on RF and gates its packet to APRS-IS. If SQ9ABC then sends its own packet directly to APRS-IS as TCPIP, that packet may return in the IGate’s stream outside its geographic filter. No correspondence with another station is needed.

Packets associated with a message to a previously gated station. The IGate receives SQ9ABC on RF. Station EA1XYZ sends a message via APRS-IS addressed to SQ9ABC. The server delivers the message to the IGate and forwards the next available position packet from EA1XYZ, even if the message sender is far outside the filter area.

The first mechanism concerns TCPIP packets from a station previously gated by the client. The second concerns messages to that station and the positions of the message sender. This distinction explains why packets can appear outside the filter without any visible preceding APRS correspondence.

How should these packets be interpreted in practice?

The APRS-IS stream may simultaneously contain packets selected by m/10, TCPIP packets from stations previously gated by the IGate, messages with associated positions, and data allowed by other active rules. These mechanisms operate in parallel.

A header such as:

SQ9ABC>APRS,TCPIP*,qAC,T2SERVER:!5000.00N/01900.00E-

indicates how the packet entered APRS-IS. qAC alone does not indicate why a particular server delivered it to a particular client. A single log entry cannot establish whether the packet arrived because of the geographic filter, earlier gating of the station by the IGate, or another rule.

If a log contains statuses, telemetry, and objects alongside distant positions, do not automatically attribute all of them to message handling. They may include TCPIP packets from stations previously gated by the IGate or data admitted by other active filters. The documentation does not support the claim that hearing a station just once unconditionally causes all traffic from its surrounding area to be delivered for a fixed period.

For operators, the essential principle is: the geographic filter defines additionally requested traffic, while the server continues to serve stations whose packets the IGate has introduced into APRS-IS. That is why packets outside m/10 may be normal network behavior.

Third-party format when forwarding to RF

A packet received from APRS-IS cannot be transmitted on RF with its Internet path and q construct. The IGate uses the third-party format: an outer radio frame containing the original packet as data.

Structure:

IGATECALL>APRS,GATEPATH:}FROMCALL>TOCALL,TCPIP,IGATECALL*:original_data

The inner TCPIP,IGATECALL* header identifies the packet’s origin. Its APRS-IS path must be removed before transmission. This allows another IGate receiving the radio transmission to recognize an Internet-originated packet and avoid reintroducing it into APRS-IS.

The } marker begins the inner third-party packet. It must not be confused with the q construct, which exists only on the Internet side.

Documentation