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

[802SEC] P802.21.1 Par Review, Review input from 802.3 ad hoc



*At its opening plenary on Monday, July 13, 2009, 802.3 chartered an ad hoc to provide the critique of the proposed P802.21.1 PAR (Standard for Support of Emergency Services in IEEE 802 Local and Metropolitan Area Networks). The following is the output of that ad hoc. It is being provided to 802.21 as the input from 802.3 as their input as due Tuesday by 5:00 PM.
*

*Geoff Thompson, Ad Hoc Chair
*

*
5.2 Scope of Proposed Standard:*

This standard will define mechanisms that support compliance within IEEE 802 to civil authority requirements for local and national emergency services such as citizen-to-authority (e.g. packet data encoded 911/112 calls), authority-to-citizen (e.g. emergency alert broadcasts for weather or tsunami) and authority-to-authority (e.g. priority override).

This project does not propose a new MAC and PHY.



Scope criticisms

   * The proposed scope statement does not sufficiently define the term
     "civil authority requirements..."
     Such requirements should be defined and available for reference
     before the PAR is presented for approval.
   * The proposed scope statement does not discuss what interfaces it
     will work to with respect to higher layers
   * The proposed scope statement does not state that it will confine
     its work to the layers that are within the scope of 802.
   * The proposed scope statement does not state whether or not it will
     require changes to existing MACs or MAC service interfaces.
   * The proposed scope statement does not state whether or not it will
     work with the existing installed base of hardware.
   * 802.1 is not listed as a stakeholder. In many implementations the
     higher layers have no access to the MAC without going through an
     802.1 layer.

Each of these points must be addressed and resolved before such a PAR (which is attempting to stake out a new scope area) is acceptable for consideration.

*5.3 Is the completion of this standard is dependent upon the completion of another standard:* No *
If yes, please explain:*

5.3 criticisms
We can't imagine that this is true given the breadth of the scope as currently presented, unless it is the intention to go all the way to the user interface. That would be a violation of 802 scope.

This proposed standard has to do one of three things:

  1. Work to existing interfaces. Ifso then they should be specified.
  2. Depend on new interfaces currently being specified. Ifso then the
     answer to this question is yes and that work needs to be cited
  3. The work will specify new interfaces that the rest of industry
     will have to accept. That needs to be stated

*5.4 Purpose of Proposed Standard: *

The purpose of this standard is to define and specify across IEEE 802 technologies: emergency calling transport functions to support compliance to civil authority requirements, including support of the 'Next Generation E911' emergency services functionality; to support compliance to Emergency Alert Broadcast; and to support Authority to Authority requirements.

5.4 criticisms
We believe that the words "transport functions" refers to the standardized reference "Transport Layer".
That layer is outside the 802 scope and expertise.

*5.5 Need for the Project: *

The emergence and rapid growth in the use of packet based voice calling has reduced the effectiveness of emergency calling functionality compared to that typically achieved by the traditional wireline and cellular telecom networks. This standard will provide the underlying transport (PHY and MAC) layer functionality to achieve parity with traditional emergency service transport functions. This project will also satisfy regulatory requirements for support of data encoded emergency calls (e.g. VoIP sessions) for IEEE 802 technologies. In addition, Emergency Alert Broadcasts have become increasingly important and the growth in usage of 802 based services as either a primary or only network access for users provides a need to develop a consistent means of distributing Emergency Alerts on 802 technologies.


5.5 criticisms
It is clear that government and emergency services agencies have expressed a need for a coordinated set of standards to address this area of concern. It is obvious that 802 can not do the entire job. This PAR does not describe what piece it is appropriate for 802 to do and how that piece will fit into the overall picture.

*5.6 Stakeholders for the Standard:** *

Emergency Service authorities and government agencies (e.g. NENA, and the equivalent bodies in ROW); IETF; other telecom, cellular and emergency services standards development organizations (e.g. IETF, 3GPP). Within IEEE 802, the expected stake holders will be 802.3, 802.11, 802.16, 802.20 and 802.22 as potential transport alternatives and 802.21 for related handover development.

5.6 criticisms
The term "transport alternative" is probably a bad choice of words, see above. We can not imagine that 802.1 is not a stakeholder in this proposed standard. They are not shown as such.


The responses to question *7.1* are inconsistent and unsatisfactory. This question needs to be addressed correctly.

*8.1 *Given the vast new areas that this project intends to address, we strongly believe that substantial further explanation is appropriate.

We have not reviewed the submitted *5 Criteria* at this point but we strongly feel that the 5 Criteria need to be reviewed and approved in detail across all 802.

*We do not feel that this effort is ready to commence a standards project at this time.
A more appropriate effort would be an EC Study Group to define:
*

   * The interfaces that an 802 project would work to
   * The precise services that an 802 project would provide in order to
     make E911 services possible via 802
   * What specific (non conflicting) set of requirements the project
     would work to
   * What changes would be required to existing 802 standards to
     satisfy the new project
   * Whether the 802 project would be a standard, guide or recommended
     practice.


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