https://mentor.ieee.org/802.11/dcn/10/11-10-0356-00-0000-wg11-response-to-proposed-802-par-march-orlando-plenary.ppt

Download Report

Transcript https://mentor.ieee.org/802.11/dcn/10/11-10-0356-00-0000-wg11-response-to-proposed-802-par-march-orlando-plenary.ppt

March 2010
doc.: IEEE 802.11-10/0356r0
WG11 response to Proposed 802 PAR March Orlando Plenary
Date: 2010-03-16
Authors:
Name
Affiliations
Address
Phone
email
Jon Rosdahl
CSR
Highland
801-492-4023
[email protected]
Submission
Slide 1
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
Abstract
802.11 WG comments on the proposed PARs for the 2010
March Plenary.
802.23: slides3-12 – 3 major issues, one suggested change
802.16: slides 12-17 – one suggested change, and one issue
802.1: slide17 – one comment
802.3: slide 18 – no comment
Submission
Slide 2
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
From the 802.23 PAR (ES-ECSG)
• 5.2 Scope: This standard defines a mechanism that
supports compliance within IEEE 802 to applicable civil
authority requirements for citizen-to-authority emergency
services packet data communications. Specifically, it
supports the need for consistent data that is required for
citizen-to-authority emergency services packet data
encoded session initiation requests.
A new MAC or PHY is outside the scope of this effort.
Submission
Slide 3
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
From the 802.23 PAR (ES-ECSG)
• 5.4 Purpose: The purpose of this standard is to support
compliance to civil authority requirements complementary
to IETF ECRIT specifications for citizen to authority
emergency services functionality. This standard intends to
encompass voice, data and multi-media requests across
IEEE 802 using a new Layer 2 entity and associated
behaviors and provide a uniform Structure of Management
Information (SMI) for transferring required data for
emergency services requests.
Submission
Slide 4
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
From the 802.23 PAR (ES-ECSG)
• 5.5 Need for the Project: VoIP emergency calls are currently less
effective than those provided by traditional wireline and cellular
networks. Emergency calls across IEEE 802 technologies need to
support regulatory requirements to assure successful completion (and
all associated requirements) of these calls to the correct Public Service
Access Point (PSAP), and to do so utilizing the existing set of IEEE
802 PHYs and MACs.
• 5.6 Stakeholders for the Standard: Emergency Service authorities
and government agencies (e.g. National Emergency Number Authority
(NENA), and the equivalent bodies in the rest of the world); IETF;
other telecom, cellular and emergency services standards development
organizations (e.g. IETF, Third generation Partnership Project (3GPP),
ETSI-Emergency Telecommunications (EMTEL)). Within IEEE 802,
the expected stake holders will be 802.1, 802.3, 802.11, 802.16, 802.20
and 802.22 as potential Layer 2 alternatives and 802.21 for related
handover development.
Submission
Slide 5
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
From the 802.23 PAR (ES-ECSG)
• 8.1 Additional Explanatory Notes (Item Number and Explanation):
There are increasingly uniform regulatory requirements that are being
imposed on telephone systems across the world on the handling of calls to
Emergency Services (911 calls in the US, for example). These requirements
have been extended to cellular telephony and are being further extended to
cover all cases of packet based telephony services. Voice over Internet
Protocol (VoIP) is the most common of these. VoIP calls can easily originate
on an 802 network. There is a need for such calls to be handled uniformly at
the interface between the 802 Layer 2 network and the Internet. IETFECRIT is the group tasked with developing the Internet standards to meet
these requirements for the upper layers of the protocol stack. This 802 effort
will work with ECRIT to develop a complete solution.
Submission
Slide 6
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
Concerns with the Emergency Services
Study Group 802.23 PAR (ES-ECSG)
• Missing Requirement definition
– Regulatory Authorities’ requirements not listed
– ECRIT Requirements and coordination
• Support level is insufficient
• Timing of moving from SG to WG (TG)
Submission
Slide 7
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
Missing Requirement definition
(EC-ECSG)
• Regulatory Authorities’ requirements are not listed
– Request for specific requirements that can be identified to be listed
in the PAR.
• ECRIT Requirements missing from PAR and 5c;
Coordination with ECRIT did not occur in SG
activities
– Specific Requirements from ECRIT for 802 be included in PAR
– Specific plan for coordination with ECRIT.
– Create a Liaison relationship with ECRIT to ensure close
coordination and cooperation with ECRIT.
• Please describe the plan for addressing these points.
Submission
Slide 8
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
Support level is insufficient (ES-ECSG)
• Concern: The participation level at the SG meetings
has been fairly light. Concern that for a new project
that sufficient support be demonstrated to warrant the
new effort. Attendance by practical Experts is also a
concern.
• Suggestion: delay the start of the WG/TG until more
support is garnered.
Submission
Slide 9
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
Timing of moving from SG to WG (TG)
(ES-ECG)
• Concern: The Study Group should continue to gather
the complete set of requirements from Regulatory
Authorities and ECRIT before progressing to a
WG/TG.
• Concern: IEEE-SA expects that the SG is convened for
6 months, and then a project is given opportunity to
progress. Without a PAR the group does not have full
indemnity.
• Concern: Prior to creating a WG, the requirements of
the Project should be defined.
• Please explain how the SG has evaluated the competing
concerns
Submission
Slide 10
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
Specific Suggested PAR changes
(ES-ECSG)
• 8.1 …(Item Number and Explanation):
– The 8.1 clause does not include an “Item Number” suggest “5.2
Scope” be inserted.
Submission
Slide 11
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
802.16 PAR
as stated in proposed PAR
• 5.2 Scope of Proposed Standard:
– This amendment specifies changes to the most recently approved
version of the IEEE 802.16 MAC with its management and data
interfaces for operation with increased robustness in degraded
infrastructure. It will make no PHY changes. This amendment will
support path redundancy, mobile and local relaying, multi-hop
relaying, Mobile Base Station, Low Duty Ratio, as well as
operation in licensed, unlicensed and lightly licensed spectrum
bands below 6 GHz with means and mechanisms to coexist with
other radio access technologies (RATs).
Submission
Slide 12
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
802.16 PAR
• Scope Issues/Questions:
• What is “the most recently approved” it is not specific. What is
“mobile and local relaying”? What is multi-hop relaying? Is a
Mobile base station mobile, or is it talking to a Mobile Station?
What is “low duty Ratio”? What bands are left after licensed, unlicensed and lightly licensed bands are excluded?
• The Scope statement seems loaded with terms lacking definition,
but not substance.
• The Scope statement should be in present tense…”will support”
should be changed to indicate what will be in the document.
Submission
Slide 13
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
WG11 proposed update to 802.16 PAR
• Propose that the PAR Scope statement be replaced with
the following:
– This amendment specifies changes to the IEEE 802.16 MAC and
its management and data interfaces for operation with increased
robustness in degraded infrastructure. No PHY changes are
included. This amendment identifies means and mechanisms to
coexist with other radio access technologies (RATs) in licensed,
unlicensed and lightly licensed spectrum bands below 6 GHz.
Submission
Slide 14
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
802.16 PAR
• Reference in the 5C is not available:
• In your 5C Technical Feasibility clause a) there are references that
we cannot access. Would you please provide a means for dot11 to
get to this material?
• a) The IEEE 802.16 GRIDMAN Study Group and prior NRR WG
Ad Hoc Committee have reviewed several presentations indicating
that the proposed functions are technically feasible. The technical
reference documents and in particular the NRR report
(C802.16nrr-08_004r3) are available on the link;
http://dot16nrr.wirelessman.org. Moreover there are examples of
prototypes that have demonstrated that the goal of the project is
achievable.
Submission
Slide 15
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
802.1AX PAR
• In the “5.5 Need for the project” a reference to
802.1AX is made, but on the 802.1 website we could not
find that reference.
• We did find a copy of 802.1AX-2008 in the “GET 802”
website.
– Suggest updating the 802.1 Website.
Submission
Slide 16
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
802.3bg
• No comments from WG11 for the WG.
Submission
Slide 17
Jon Rosdahl, CSR
March 2010
doc.: IEEE 802.11-10/0356r0
References
• Pars under consideration:
http://ieee802.org/PARs.shtml
• Input documents for comment
https://mentor.ieee.org/802.11/dcn/10/11-10-0281-00-0000comments-on-802-23-par-and-5c.ppt
Submission
Slide 18
Jon Rosdahl, CSR