IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-09-0047-00-0000
Title: Response to 802.11 and 802.16 ES PAR and 5C
Comments
Date Submitted: March, 11, 2009
Presented at IEEE 802.21 session #31 in Vancouver
Authors or Source(s):
G. Scott Henderson, RIM
Abstract: This presentation is a point by point response to
comments on the Emergency Services PAR and 5C as presented
in 802.16 contribution 802.16-09/0017 and 802.11 contribution
802.11-09/0356r0. These comments were prepared by the
802.21 Emergency Services SG.
21-09-0047-00-00es
IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 802.21 Working Group. It is
offered as a basis for discussion and is not binding on the contributing
individual(s) or organization(s). The material in this document is subject to
change in form and content after further study. The contributor(s) reserve(s)
the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate
material contained in this contribution, and any modifications thereof, in the
creation of an IEEE Standards publication; to copyright in the IEEE’s name
any IEEE Standards publication even though it may include portions of this
contribution; and at the IEEE’s sole discretion to permit others to reproduce in
whole or in part the resulting IEEE Standards publication. The contributor also
acknowledges and accepts that this contribution may be made public by IEEE
802.21.
The contributor is familiar with IEEE patent policy, as stated
outlined
in in
Section
Section
6 of
6.3the
of
the IEEE-SA
IEEE-SA
Standards
Standards
Board
Board
bylaws
Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6>
and in
in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
http://standards.ieee.org/board/pat/faq.pdf>
21-09-0047-00-00es
802.21 thanks 802.11 and 802.16 for their
comments on the Emergency Services draft
PAR and 5 Criteria. Point by point responses to
the inputs are on the following slides, and the
modified PAR and 5C files resulting from all
comments can be found on the 802.21
document server as:
21-09-0027-01-00es Emergency Services PAR and 5C
21-09-0047-00-00es
802.11 PAR and 5C Comments
• General comments:
• Emergency Services (E-911, PSAP, etc) are important services that may
benefit from standardization. This needs to start soon, but we do not
believe that 802.21 is not the proper place.
• We suggest that a separate 802 WG be considered to allow the autonomy
and focus necessary to create a standard in a timely manner. This WG
would also need to ensure cooperation and coexistence with the other
802 WGs.
This is an EC decision/action.
• The PAR should be broken up into 3 separate destinct PARS
• 1-- Client to Authority (E-911)
• 2 – Authority to client (emergency warning broadcast – Amber alert)
• 3 – Authority to Authority (network prioritization and control)
The PAR and 5C have been amended to cover only the first
category, Citizen to Authority or emergency call
21-09-0047-00-00es
802.16 Questions for clarification
• Why is this being proposed as a New Standard? How can you propose to
solve the problem across all 802 standards by writing a document that
specifically, by virtue of being a NEW standard, does not amend or modify
any existing 802 standards? Until we understand the proposed functionality,
we cannot understand how this is possible.
This work is not intended as an extension of 802.21, but rather as an
independent standards development effort. As a part of this project,
there may be MAC and PHY amendments to other 802 standards
• What is common about the PHY/MAC protocols under the 802 architecture
that provides the ability to do an 802-wide solution for emergency services?
Until we understand the proposed functionality, we cannot understand how
this is possible.
The work project will provide enabling tools to support emergency
calling. Specific MAC and PHY changes would have to be developed
by the appropriate WGs if necessary.
• Section 5.2 (Scope) says ‘for emerging requirements for text message and
multimedia based emergency services requests.’ How does the media type
map into 802 access technologies, especially those that are insensitive to
higher layer media type definitions?
The PAR has been modified to indicate that this work project will
provide SUPPORT for emergency data sessions of any type.
21-09-0047-00-00es
802.16 Questions for clarification
• Where are the emergency service (ES) ‘functions’ defined? At what layer?
For what geographical regions? The proposed standard does not constrain
the geographic applicability of the standard, but neither is there any clear
indication that the requirements are global.
Emergency call requirements are defined by NENA, FCC and ETSI
EMTEL as at least support for location, call integrity, call back and
authenticated & unauthenticated calling. Geographical requirements
vary, but that should not affect the L1/L2 tools proposed here.
• In Item B under the 5 Criteria Broad Market Potential, the response indicates
that interested parties will have to respond to ‘changes resulting from this
standard’. But the proposed standard is a NEW standard, not changes to
existing standards. Please clarify what the changes are.
The wording in the 5C has been clarified to indicate that the 'changes'
would be to higher layer functionality in, for instance, IETF ECRIT.
• In Item C under the 5 Criteria Broad Market Potential,, if the changes are
expected to be primarily to ‘software/firmware’, why is this being
considered as a PHY & MAC new standard? Software/firmware is usually
implementation-dependent and outside the scope of 802.
Implementation of the changes is expected to be limited to
software/firmware rather than new hardware. The 5C has been
amended.
21-09-0047-00-00es
802.16 Questions for clarification
• The 5 Criteria Technical Feasibility response alleges that existing 802
solutions to ‘do not fully address all emergency services criteria.’ However,
the PAR proposal admits intention to meet only a very limited set of the
overall set of ES features. So why is a new partial solution superior to an
existing partial solution?
The final paragraph in 'Technical Feasibility' addresses the comment.
• In the 5 Criteria Technical Feasibility, what existing 802 functionality does
the proposed new standard plan to reuse?
There has been development in 802.3 for location, in 802.11u for
location and unauthenticated sessions, and 802.16 has indicated that
they have some support for emergency calls. As much as feasible, this
existing work would be reused, along with any other work by other
WGs.
• The draft PAR indicates that the project plan anticipates going to Sponsor
Ballot in June 2010. This seems remarkably optimistic. On what basis does
the group make such evaluation, given the expected level of cross-group
coordination and experience in time required to develop standards?
Agreed. The PAR is changed to June, 2011.
21-09-0047-00-00es
802.16 Questions for clarification
• In the 5 Criteria Distinct Identity section (1), the response identifies
‘location’ and ‘connection integrity’ functional requirements. What is it
about the 802 architecture that enables a common method for assessing
‘location’?‘Connection integrity?’
For 802.3 and 802.11, this would be the location of the 'point of
attachment' (Ethernet port or AP). Location for 802.16 would
inherit/require work by that WG/WMF.
Connection integrity can be identified as a combination of call
continuity and anti spoofing. A layer 1-2 implementation rather than
the current L3 and above has inherent advantages.
• In 5 Criteria Distinct Identity section (2), the response identifies ‘VoIP based
emergency calls across all current 802 transport standards’. Including
wireline? Doe the draft PAR propose solving this problem in both 802
wireless and wireline solutions?
Yes. Emergency calls over 802.3 need to supported equally well.
21-09-0047-00-00es
802.16 Comments and Suggested Remedies
• Comment: This PAR proposal is bipolar: in one place it says that it will provide an
entirely new PHY & MAC specification; in other places is says that it will write
other layer solutions or will amend other 802 standards.
• Suggested remedy: Please specify coherently and unambiguously in the Scope and
Purpose whether this proposed project will be for a new PHY & MAC specification,
for amendments to existing other 802 PHY & MAC specifications, for some other
entirely new non-PHY&MAC layer development, or for an amendment to the
existing 802.21 features and functions. Ensure that the remainder of the draft PAR
and 5 Criteria is consistent with the expression of the Scope and Purpose.
PAR and 5C have been limited to support for emergency calling, with
supporting MAC/PHY development if necessary in respective WGs.
• Comment: Section 5.2 (Scope): ‘As first priority…’ is unacceptable language for a
Scope statement. The anticipated standard either does or does not specify the
mechanisms. The same problem exists with ‘The additional objectives.’
• Suggested remedy: The Scope should say ‘This standard defines mechanisms…’ or
‘This standard provides...methods…’ or similar language. Modify the Scope
statement to employ the proper format and language for standards PARs.
Furthermore, be explicit as to what sort of mechanisms, at what network layers, are
being specified.
PAR is amended. Phase 2 - 3 are for future PARs.
21-09-0047-00-00es
802.16 Comments and Suggested Remedies
• Comment: Section 5.4 (Purpose): The language refers to ‘initial’ and ‘longer
term’ development. The proposed standard cannot bind a future action; can
only address what THIS standard achieves. The purpose statement, as
written, is inappropriate for inclusion in a standard.
• Suggested remedy: Modify the Purpose statement to employ the proper
format and language for standards PARs.
PAR has been modified to cover only emergency calling.
• Comment: Section 5.5 of the PAR specifies that the proposed standard will
develop a NEW PHY and (“This standard will provide the underlying
transport layer (PHY and MAC) functionality”). Please describe this
protocol in more detail. What is the medium? Is it for wireline applications?
Wireless? While this text is in the ‘Need for the Project’ section, this
language is consistent with actual Scope language, while Section 5.2
language is more consistent with identification of need.
• Suggested remedy: Modify Section 5.5 (“Need for the Project”) section to
use appropriate ‘needs’ language, not Scope language.
Section 5.5 has been modified.
21-09-0047-00-00es
802.16 Comments and Suggested Remedies
• Comment: In the 5 Criteria “Technical Feasibility” section,
none of the responses seem to address Technical Feasibility.
• Suggested remedy: Modify The 5 criteria Technical Feasibility
section to properly address Technical Feasibility.
5C has been amended.
• Comment: In the 5 Criteria “Economic Feasibility” section, the
response should not depend on connection to the Internet. It
should be independent of L3/L4 solution and network design.
• Suggested remedy: Modify 5 Criteria Economic Feasibility
section to eliminate reference to Internet.
Reference to the Internet has been removed.
21-09-0047-00-00es