[Namaste-dev] Re: Thoughts on ACP Interoperability
brickle at pobox.com
Sun Jul 13 17:38:08 PDT 2008
On Sun, Jul 13, 2008 at 2:11 PM, Bob McGwier <rwmcgwier at gmail.com> wrote:
> Is there no middle ground? That is, what is to prevent us from
> implementing the CAI sans the vocoder and passing the digital streams
> encapsulated in "AMSAT-MAC"? Is there something that prevents this?
Nothing prevents. I believe this is exactly what we *should* do. What's
required, however, is...a port and a socket.
Or maybe just a little more, in the form of a tunnel through which alien
EMCOMM packets can move over AMSAT links. If we were to adopt something
sensible like Jingle or SIP for signalling, then the tunneling would be
Whatever the exact transport mechanism, though, there's essentially nothing
to *do* at the AMSAT end, in this scenario.
> It would clearly require control operators sitting at either end of the big
> pipe who can hear the synthesized speech or see the content of file transfer
> to be legal, as in sitting on a kill switch I think, without waivers. But
> is this not even theoretically possible is my question?
> Anyway the team goes it seems to me that passing digital data according to
> some agreed upon standard that would allow some ease of use by the first
> responders even if it is as dumb as synthesize- reencode and then
> decode-analyze. We only need to walk right up the boundary of what Part 97
> will allow in time of emergency and use a "waterfilling algorithm" to push
> at the legal limit it seems to me.
> ARRL SDR Working Group Chair
> Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
> NJQRP, QRP ARCI, QCWA, FRC.
> "Trample the slow .... Hurdle the dead"
> *From:* namaste-dev-bounces at AMSAT.Org [mailto:
> namaste-dev-bounces at AMSAT.Org] *On Behalf Of *Frank Brickle
> *Sent:* Sunday, July 13, 2008 11:54 AM
> *To:* Rick Hambly (W2GPS)
> *Cc:* namaste-dev
> *Subject:* [Namaste-dev] Re: Thoughts on ACP Interoperability
> >From the Project 25website:
> *What is Required for P25 Compliance? *
> At a minimum, a P25 radio system must provide interoperability with these
> mandatory P25 Standard components:
> - *The Common Air Interface (CAI) specifies how information is coded,
> transmitted and received over the air. *
> It enables users to interoperate and communicate digitally across
> networks, agencies, and vendors.
> - *The Improved Multi-Band Excitation (IMBE) vocoder converts speech
> into a digital bit stream. *
> Test panels judged IMBE as the coding scheme most successful at making
> male and female voices audible against background noises such as moving
> vehicles, sirens, gunshots, and traffic noise – the conditions of public
> safety use.
> P25 has also defined standard modes of operation to enable multi-vendor
> interoperability for additional system functions: trunking, encryption,
> over-the-air rekeying, to name a few.
> A set of defined system interfaces allow the P25 system elements to
> communicate with host computers, data terminals and the public switched
> telephone network (PSTN).
> My reading of the situation is that any AMSAT system can be provided
> *additional* capabilities for using the CAI and some other interfaces. These
> interfaces are nominally open, although conspicuously lacking reference
> However, thanks to the use of IMBE, having an AMSAT system that implements
> any function where the codec is applied is completely out of bounds until
> such time as the intellectual property issues surrounding it are resolved.
> For the sake of completeness, I would point interested readers to other
> areas of the website where P25 vendors are criticized (by GAO and others)
> for failing to provide complete implementations of the standard. It would
> appear that vendors have been lagging grievously in providing precisely the
> interoperability parts of the standard, while they've shown remarkable
> alacrity at fielding systems employing the proprietary codec technology.
> In short, the vendors seem largely to have blown off interop, but have
> demonstrated great motivation at shouldering out competition. My private
> impression is that AMSAT could implement the full buffet of CAI specs and
> wind up with systems that have nobody to talk to at the P25 end. A person
> more cynical than myself might infer that P25 is nothing more than yet
> another scam to ensure virtual monopolies for large vendors.
> None of this is a surprise -- in fact, it's business as usual -- where
> proprietary specs are concerned. Again, my private conviction is that AMSAT
> would be flat-out loony to devote any effort whatsoever at realizing
> anything but a certifiably Open standard.
> On Sun, Jul 13, 2008 at 8:17 AM, Rick Hambly (W2GPS) <w2gps at cnssys.com>
> Thank you for your input. I strongly agree that any external interface with
> the ground station should be IP based. That opens up a number of
> and emergency communications application interfaces that can easily be
> on top of IP.
> The average satellite user of this ground station will be an individual in
> his or her home. Even then, the IP interface will allow that user to
> the ground station to their computer and exchange IP voice, pictures,
> files, etc. with the users on the communications channel.
> Could we put applications like a P25/IP interface in our PC or laptop,
> thereby separating this applications issue from the immediate need to get
> affordable ACP ground station built soon? I don't really know enough about
> P25 or its implications (technical, legal) to know.
> AMSAT LM2232
> -----Original Message-----
> From: namaste-dev-bounces at amsat.org [mailto:namaste-dev-bounces at amsat.org]
> On Behalf Of Timothy J. Salo
> Sent: Saturday, July 12, 2008 7:05 PM
> To: 'namaste-dev'
> Subject: [Namaste-dev] Thoughts on ACP Interoperability
> A few quick thoughts on ACP interoperability objectives
> follow. This note is motivated, in part, by "An Overview
> of AMSAT Opportunities for Communications Interoperability",
> available at:
> (Note that these comments are based on my recollection
> of how Project 25 (P25) systems work, rather than
> recent investigations.)
> The ACP Interoperability document seems to me to
> suggest that there is an opportunity for ACP to
> provide connectivity between amateur radio systems
> and public safety systems. That is, ACP should
> (arguably) enable an amateur radio device to
> communicate with a public safety system.
> The public safety community is moving towards P25
> systems. As such, P25 seems to be the best system
> for the ACP to target. (In other words, the ACP
> should target the system towards which the public
> safety community is migrating, rather than some
> system that the public safety community is migrating
> away from.)
> So, the refined requirement might be that the ACP
> should enable connectivity between amateur radio
> devices [or systems] and P25 systems.
> I know of two ways for a device to connect to a
> P25 system:
> 1) Look like (appear to the P25 system to be)
> an end device (e.g., a handheld, mobile or
> basestation radio), or
> 2) Look like a repeater.
> It turns out that P25 repeaters can be
> interconnected with IP, or more precisely,
> with a P25 protocol that runs over IP.
> So, if the ACP could provide connectivity
> between two IP devices, it would become a
> simple, powerful, general solution. It
> could provide amateur/P25 interoperabil9ty,
> as well as a bunch of other useful services.
> An IP-capable ACP becomes simple, because a
> large number of very useful interoperability
> issues get moved outside of the ACP system.
> In this architecture, amateur/P25 interoperability
> would be provided by an external (to the ACP)
> device that converts an amateur radio conversation
> to the P25 protocols.
> (Actually, a better solution would be to build an
> IP/P25 device that is integrated into an amateur
> repeater. That is, the amateur repeater would
> appear to the P25 repeater to be just another
> P25 repeater. This device could use the ACP, or
> it could use any other IP-enabled path. By the
> way, another important theme here is that the
> ACP is much more useful if it connects systems,
> such as repeaters, rather than individual devices.)
> An IP-capable ACP becomes much more powerful and
> general because users, rather than system designers,
> are now able to develop new uses for the ACP.
> A few more random thoughts.
> o In my opinion, system-level architecture discussions,
> such as those hinted at by the "Namaste Layers" document,
> should probably occur sooner rather later. Specifically,
> it is important to understand how the ACP should fit
> architecturally with other systems. Is it a network
> device? What sorts of systems will it (meaning the
> whole ACP system, not just the satellite segment)
> connect with? The right answers will make the ACP a
> very useful, general device, while a wrong answer
> might make it difficult to get the ACP to work well.
> (And, I don't like the protocol layer summery in the
> o It looks like the ACP ground station may be two
> subsystems connected by an Ethernet. Now, if this
> is IP running over Ethernet, then the ACP system might
> become really useful, really easily, for a wide
> variety of useful applications. I hope this concept
> does not get lost with the changing (or unchanging) of
> the guard.
> o Note that P25 has a data channel. I assume that
> the ACP ought to also interconnect this data channel
> with amateur data systems (no, not AX.25 systems...).
> More free advice from,
> Namaste-dev mailing list
> Namaste-dev at amsat.org
> Namaste-dev mailing list
> Namaste-dev at amsat.org
> What else may hap to time I will commit... -- Twelfth Night
We may yet reach a point where the only sector of scientific inquiry that is
safe from the anti-science mobs on the Right is weapons research. -- Arianna
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Namaste-dev