Re: [Ieprep] on the ieprep charter
ken carlberg <carlberg@g11.org.uk> Fri, 28 July 2006 19:52 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YOC-0008Mt-TS; Fri, 28 Jul 2006 15:52:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YOB-0008L1-EB for ieprep@ietf.org; Fri, 28 Jul 2006 15:52:51 -0400
Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6YOA-0006hL-20 for ieprep@ietf.org; Fri, 28 Jul 2006 15:52:51 -0400
Received: from [69.138.71.89] (helo=[192.168.1.2]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62) (envelope-from <carlberg@g11.org.uk>) id 1G6YO9-0000Lp-Vf; Fri, 28 Jul 2006 20:52:50 +0100
In-Reply-To: <042EB3AC-C5A9-463E-B2B6-308231411ED9@cisco.com>
References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <B8C892A4-F711-4928-8EDA-FD7E717B702F@cisco.com> <44C9160F.1060001@jhuapl.edu> <DBC1A7C7-9F3C-4557-A7BC-E081C482A5C3@cisco.com> <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk> <1154103399.5427.366.camel@north-latitude.nps.navy.mil> <042EB3AC-C5A9-463E-B2B6-308231411ED9@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <932AEBC1-2418-40B7-8AB7-5E3C83628846@g11.org.uk>
Content-Transfer-Encoding: 7bit
From: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Ieprep] on the ieprep charter
Date: Fri, 28 Jul 2006 15:52:40 -0400
To: Fred Baker <fred@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -1.4 (-)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Rex Buddenberg <budden@nps.navy.mil>, Robert Cole <robert.cole@jhuapl.edu>, ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org
Fred, > In the general case, I would expect push-to-talk to be handled by > provisioning. I'm not certain that the capability is of an > "emergency" nature. In civilian networks, it is commonly used on > virtual trading floors and as a walkie-talkie replacement. I can't > say I know for certain how it is used in military networks (they > haven't told me), but I would expect that it permits communication > among a physically distributed group of people that operate as a > team, such as command/control operations. In civilian networks, the > way it generally works is by ensuring (either by provisioning of > bandwidth or by placing traffic into an appropriate class) that > there is bandwidth available to the application at the time it > needs it, and is generally a low capacity channel. a good read on things, though the headache arises in the details. Today, provisioning in LMR systems used by first responders (police, firemen, EMS, etc.) is accomplished by man-in-the-loop dispatchers that assign channels per talkgroup (analogous to per multicast group). and what is known as "radio discipline" (by end users) is primarily used to control contention on the channel. failing that, the dispatcher manages the group and can assign more talkgroups/ channels, though these are limited. and as Janet mentioned, prioritization in LMR (layer 2) packets has recently been added tot he mix. Project 16a of APCO defined a set of 5 priorities, and Project 25 defines 7 levels. one moral in that story is not to be fixated on the number of levels....they may change. my understanding is that the number of towers involved in a talkgroup generally range from 0 (direct communication between end users) to 4, with a gausian decay after that. today, these towers don't have IP embedded within them, but that will come in time. outside of this, there are also remote observer participants that receive the communications from remote geographic regions. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Howard C. Berkowitz
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Nguyen, An P CIV NCS NC2
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Howard C. Berkowitz
- Re: [Ieprep] on the ieprep charter Fred Baker
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Rex Buddenberg
- Re: [Ieprep] on the ieprep charter ken carlberg
- [Ieprep] Question about the IEPREP Recharting Pro… Hannes Tschofenig
- Re: [Ieprep] on the ieprep charter Rex Buddenberg
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Janet P Gunn
- Re: [Ieprep] on the ieprep charter ken carlberg
- Re: [Ieprep] Question about the IEPREP Recharting… ken carlberg
- Re: [Ieprep] Question about the IEPREP Recharting… Hannes Tschofenig