On 21/1/19 3:56 am, David Ranch wrote:

Hello Stuart,

The thinking here is if I want to send a message to a station, VK4BWI-0,
if it's just to that station, I'd address it to "VK4BWI-0" as normal.

However, supposing a few of us in Brisbane WICEN had a little chat group
on our digipeater network, and we wished to have a common UI frame
destination address that we all listen for to receive real-time messages.

So you're looking to use unconnected UI frames to communicate to multiple people at the same time?  Are you looking to have those remote stations listen and *only* selectively show the traffic either to their own callsign+ssid or to a specific "multicast" group?

Essentially, yes, the stations ideally will be just listening out for traffic to a couple of SSIDs:

- their own SSID (for unicast traffic)
- the "group" SSID (for multicast traffic)

Long term, the actual chatting will be done on a higher layer with a protocol built on AX.25 being used as the transport mechanism. It may also include encoded forms (perhaps CBOR-encoding to make things compact) for sending welfare-type information.

e.g. the "base station" for an emergency comms net might transmit a form to be filled out by operators at the "checkpoints"; this would be sent multicast (with each station then unicasting an ACK when they receive it) … the operators could then fill the form in and their replies would be sent back unicast to the base.

In my area, we have a weekly UI net where different HAMs essentially send beacons along a 7-hop digi path to chat.  Everyone monitors the channel in a promiscuous method to hear everyone's traffic.  It's not an ideal system as we see all the other traffic on the channel as well but it does work well enough.  If you wanted to filter on this traffic to only your net, you could have everyone send their traffic to a specific destination across your digipeaters and filter all promiscuous traffic to a specific destination address, say "vk4cht-0".

It's promising to hear the concept can work. I guess the aim here is to try and build on that concept.

If you're looking for a guaranteed delivery transport, you could do something at the application layer to put a sequence number in the UI payload to identify missing packets and re-request a re-transmit.  This is something that D-RATS had developed years ago.  That could become a challenge in a lossy multi-point network but it it works fine when someone is acting as a net control.

Sequence numbering could be done at a higher layer for sure. I figure it's up to the higher-level application to guarantee delivery.

In the TCP/IP world, Pragmatic General Multicast (PGM) attempts to solve this problem:


I'll definitely have a look at that.  This could be interesting.
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Reply via email to