The whole "zone" concept really is dependent on the DOA (marketing
wise) 10 gHz backbone system, using ATM to bring multiple controllers
together to provide the zone and optionally share a gateway.
A smart controller/gateway would operate the same way whether attached
to the Internet or not. In fact, it would make the air protocol more
logical. In its simplest form the controller/gateway would implement
the idea behind a Forwarding Information Base (FIB) only on the D-STAR
frame addresses (callsigns) rather than on IP addresses. If the DST
or UR address was last seen on one of the attached repeaters, forward
the frame there, if not send it to the remote controller/gateway
through encapsulation (e.g. IP over the Internet). If RPT2 is set, it
overrides the UR field for forwarding, the controller/gateway just
sends it to that designated local repeater, if not local, forward it
to the proper controller/gateway and let it in turn use its FIB to
send it to the right repeater.
I think David's (G4ULF) original design is much smarter, combine the
controller with the gateway function. An ITX motherboard with CF or
SD storage is economical, potentially low power, and can contain a lot
of intelligence. If Icom had designed their controller that way, the
"G" port would be unnecessary -- if they could do a firmware upgrade
so that by default all traffic was sent to the gateway computer, the
same would be true.
That a user needs to know about a "G" port, is inefficient and not
really logical. You either want to talk to K7VE or you want to send
a call to K7VE (or CQCQCQ) at a given repeater (by using RPT2).
On Jul 27, 2009, at 2:59 PM, Woodrick, Ed wrote:
Don’t forget the original design of DSTAR with the zones and
multiple stacks in a zone. Also, don’t forget that there are
repeaters that aren’t attached to a gateway computer and may never
be. That’s one of the biggest reasons for the G routing in my mind.
Ed WA4YIH
.
John Hays
Amateur Radio: K7VE
j...@hays.org
