Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] Request for Assistance from IEEE 802 - Emergency Services Location Identification

Pat -

I would agree. In particular, if location identification is involved, you 
are definitely looking at a higher layer function (I can't think of any 
good 802 protocol reason to stick GPS in a NIC for example).


At 22:00 28/02/2006, Pat Thaler wrote:
>I think your instincts here were good. This doesn't sound like a layer 2
>function. It shouldn't operate differently depending on the type of
>network. The place where the call placing protocols are specified (e.g.
>IETF) seems more appropriate for this kind of function.
>-----Original Message-----
>From: Paul Nikolich [mailto:paul.nikolich@ATT.NET]
>Sent: Tuesday, February 28, 2006 1:20 PM
>Subject: [802SEC] Request for Assistance from IEEE 802 - Emergency
>Services Location Identification
>Dear EC members,
>A few weeks ago I received a request from Doug Rollender asking if there
>was any interest in supporting emergency service location identification
>capability in 802 standards.  I told him I didn't think so, but I would
>share his request with the EC.  It is copied below.  If you think there
>may be synergy with you group, please respond directly to Doug.
>----- Original Message -----
>From: Rollender, Douglas Harold (Douglas)
>Sent: Thursday, February 09, 2006 8:12 PM
>Subject: Request for Assistance from IEEE 802 - Emergency Services
>Paul Nikolich, Chairman, IEEE 802 Executive Committee,
>It was good talking with you last week about how IEEE 802 could help
>support future emergency services.  This message is the request we
>discussed for IEEE 802 working groups to consider including in their
>standards whatever is needed for the generation and delivery of location
>identification and callback capability for individuals trying to gain
>access to emergency services through either voice or non-voice devices.
>This request applies for any technology that provides wired or wireless
>access to the Public Switched Telephone Network, wireless carrier
>networks, or the public Internet.  From a universal perspective, the
>overarching concern is for a consistent approach by standards
>development organizations to address social policy expectations, such as
>full 9-1-1 capability, in relation to emerging access technologies.
>Location identification and callback capability represent baseline
>requirements for emergency service.  Organizations such as the National
>Emergency Number Association (NENA), the ATIS Emergency Service
>Interconnection Forum (ESIF) and the FCC's Network Reliability and
>Interoperability Council (NRIC) have created considerable documentation
>identifying requirements and technical needs that must be addressed to
>support E911 service through emerging access technologies.  Please
>consider these requirements and the role IEEE 802 standards would play
>with other interoperable network standards to provide end users access
>to emergency service in a manner consistent with these requirements.
>I recognize this request may represent a considerable challenge.  As
>chairman of ESIF Subcommittee B, I'm confident that ESIF membership is
>prepared to assist you as well as other standards organizations and
>public safety organizations to facilitate dialogue as needed to resolve
>any concerns you may have for those aspects of emergency service
>requirements that you feel are within your scope.
>Should you have questions, please call me a 973-386-4560.  I look
>forward to receiving your response to this request for all relevant IEEE
>802 working groups.
>Douglas Rollender
>Lucent Technologies
>Wireless Standards Development and Industry Relations
>TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965
>This email is sent from the 802 Executive Committee email reflector.
>This list is maintained by Listserv.
>This email is sent from the 802 Executive Committee email reflector.  This 
>list is maintained by Listserv.

This email is sent from the 802 Executive Committee email reflector.  This list is maintained by Listserv.