[Namaste-dev] Re: Thoughts on ACP Interoperability

Frank Brickle 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
off-the-shelf anyway.

Whatever the exact transport mechanism, though, there's essentially nothing
to *do* at the AMSAT end, in this scenario.

73
Frank
AB2KT

> 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.
>
>
>
>
>
> Bob
>
>
>
>
>
> 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
> implementations.
>
> 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.
>
> 73
> Frank
> AB2KT
>
>
>  On Sun, Jul 13, 2008 at 8:17 AM, Rick Hambly (W2GPS) <w2gps at cnssys.com>
> wrote:
>
> Timothy,
>
> 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
> Ham-centric
> and emergency communications application interfaces that can easily be
> built
> 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
> connect
> the ground station to their computer and exchange IP voice, pictures,
> video,
> 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
> an
> affordable ACP ground station built soon? I don't really know enough about
> P25 or its implications (technical, legal) to know.
>
> Rick
> W2GPS
> 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:
>
> <
> http://www.delmarnorth.com/namaste/requirements/AMSAT_Communications_Intero
> perability_Ver1.pdf<http://www.delmarnorth.com/namaste/requirements/AMSAT_Communications_Interoperability_Ver1.pdf>
> >
>
> (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
>   document...)
>
> 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,
>
> -tjs
>
>
> _______________________________________________
> Namaste-dev mailing list
> Namaste-dev at amsat.org
> http://amsat.org/mailman/listinfo/namaste-dev
>
> _______________________________________________
> Namaste-dev mailing list
> Namaste-dev at amsat.org
> http://amsat.org/mailman/listinfo/namaste-dev
>
>
>
>
> --
> 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
Huffington
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://amsat.org/pipermail/namaste-dev/attachments/20080713/a93cad5d/attachment.html


More information about the Namaste-dev mailing list