[Namaste-dev] Re: Weekly Plan June 2 - June 6 (APCO-25 InterOp)

JoAnne Maenpaa k9jkm at comcast.net
Tue Jun 3 07:12:29 PDT 2008


Hi everyone,

I'm the person who volunteered to examine the InterOperability opportunity for our ACP Ground Segment.

> 5. Requirements analysis (technical) and Position Paper (policy) work 
>    on the optional APCO-25 terrestrial interface module continues. I 
>    have one volunteer for this effort, and am looking for more. A re-
>    quest for a copy of the series 102 spec from TIA has been made to 
>    AMSAT. The spec is free under certain circumstances, and I think 
>    we may qualify. If not, and if AMSAT agrees it’s worth buying, 
>    it will be purchased.

I'm retired from the communication systems engineering business (20 years at Motorola) but during that part of my career I had the opportunity to drive requirements definition and customer cost quoting for large systems.  Some of the interoperability features I had been a part of include cellular nationwide/automatic roaming, cellular E911, CDMA-to-AMPS handoff, cellular location service (GPS), cellular caller ID, etc.

The one thing these cellular interoperability designs had in common is that they were driven by either a standards document mandate or by considerable customer interest and investment in the system design.  Sometimes the customer knew what he wanted and was able to specify what Motorola was going to build for him.  Other times Motorola would sense an opportunity to dangle a technical proposal in front of the customer and sell him on the idea.

At this phase of our InterOperability investigation I have a feeling we're at a point where we sense potential customer interest translating into launch funding and the opportunity to dangle a technical proposal in front of launch funding sources.  (Likely DHS or DoD?)

Effective project proposal and requirements definition should define WHAT you are going to do before you define HOW you are going to do it.  

This is just my opinion only - but jumping in with 30 volumes of APCO specifications seems to be jumping right into that "how you are going to do it" phase.  We can imagine a scenario where you would tell 50 hardware and software designers to go "write some code and make a CPU board" and we'll get back to you about what it should do! :-)

Here is what I am dangling out for our Namaste team to consider and discuss:

a. AMSAT uses the Incident Command System as the basis of our InterOperability
   model.

b. This is WHAT we propose to do: The Namaste InterOperability feature set 
   should include the ability for customer specified layers and sectors of 
   the Incident Command System to communicate with each other.  ICS Command 
   Posts will likely have more need for a satellite earth station than an 
   individual firefighter on standby at a levee.  The types of messaging 
   traffic at this different levels varies considerably.

c. Perhaps not call it APCO-25 during our initial technical proposal phase?
   When DHS tells AMSAT we are on the right track by allowing Incident Com-
   manders access to other services, and, "Oh by the way, 90% of our radios
   are APCO-25" then we will be on track to worry about all the octets of
   radio packet traffic.

Quoting from http://en.wikipedia.org/wiki/Unity_of_command#Unity_of_Command :
The Incident Command System (ICS) is a standardized, on-scene, all-hazard 
incident management concept in the United States. It is a management 
protocol originally designed for emergency management agencies and 
later federalized. ICS is based upon a flexible, scalable response 
organization providing a common framework within which people can 
work together effectively. These people may be drawn from multiple 
agencies that do not routinely work together, and ICS is designed 
to give standard response and operation procedures to reduce the 
problems and potential for miscommunication on such incidents.

In the next week or two, I plan to put together a more detailed graphical proposal of how Namaste can help facilitate a wide-area implementation of ICS.  Just thought I'd dangle my thought process out here.  The APCO bytes and protocols are well defined and are the least of our problems.  I thought perhaps we need to start with a proposal using the language of likely funding managers.

--
73 de JoAnne K9JKM
k9jkm at amsat.org 





More information about the Namaste-dev mailing list