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:
https://en.wikipedia.org/wiki/Reliable_multicast
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.
