1 / 30

New WG PARs that WG11 must consider in March 2009

This document contains the comment responses received from members of the 802.11 WG regarding new PARs under consideration for March 2009. It includes feedback on various topics such as support for emergency services, multi-radio power management, and TV whitespace functionality. The document also highlights tutorials and other agenda items for the March meeting.

johnnies
Download Presentation

New WG PARs that WG11 must consider in March 2009

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. New WG PARs that WG11 must consider in March 2009 Authors: Date: 2009-03-09 Jon Rosdahl, CSR

  2. Abstract This document contains the comment responses received from members of 802.11 WG. The WG has requested that this submission be used as the 802.11 WG response to the new 802 PARs that were under consideration for March 2009. The responses from the different WGs are captured starting in Slide 16. Jon Rosdahl, CSR

  3. From Monday Agenda 4.1.5 New WG PARs that WG11 must consider in March • 802.21 WG : Support for Emergency Services • The PAR and 5C can be found at: • http://mentor.ieee.org/802.21/file/09/21-09-0027-00-00es-emergency-services-par-and-5c.doc 2. 802.21 WG : Multi-Radio Power Management • The PAR and 5C can be found at: • http://mentor.ieee.org/802.21/file/09/21-09-0021-00-mrpm-mrpm-revised-par-5c.doc 3. 802.22 WG : TV WhiteSpace PAR Amendment to add mobile and portable device functionality • https://mentor.ieee.org/802.22/file/09/22-09-0029-00-0000-draft-22a-par.doc • https://mentor.ieee.org/802.22/dcn/09/22-09-0030-01-0000-draft-22a-5c.doc Jon Rosdahl, CSR

  4. From Monday Agenda 4.1.5 New WG PARs that WG11 must consider in March 802.3ad PAR for Priority-based Flow Control MAC Control Frame • This proposed PAR is to add a MAC Control Frame to IEEE 802.3 to support 802.1Qbb Priority-based Flow Control. Note that the 802.1 Working Group will be responsible for this PAR. As usual when doing a cross group PAR, 802.3 voters who request it will be added to the Working Group voting pool on this project. • The PAR is at: • http://www.ieee802.org/1/files/public/docs2008/bb-thaler-pfc-frame-par-1108.pdf • Since this PAR is to support the 802.1Qbb PAR, the same 5 criteria applies to it: • http://www.ieee802.org/1/files/public/docs2008/new-dcb-thaler-draft-pfc-5c-0208-v3.pdf Jon Rosdahl, CSR

  5. From Monday Agenda item 4.1.6 March 2009 - Tutorials Monday, March 9, 2009 • Tutorial #1 (6:30 pm): Multi-radio Power Conservation Management sponsored by Vivek Gupta • Dennis Edwards - CoCo Communications • Junghoon Jee - ETRI • H Anthony Chan - Huawei Technology • Call for interest (8:00 pm): IEEE 802.3 Support for IEEE 802.1AS Time and Synchronization • Steve Carlson - High Speed Design • David Law - IEEE 802.3 WG Chair Tuesday, March 10, 2009 • Tutorial #2 (6:30 pm): White Space Tutorial • Matthew Sherman - BAE Systems • Tutorial #3 (9:00 pm): IEEE-SA Patent Pool Collaboration with Via Licensing • Edward Rashba - IEEE Standards Association • Torey Bruno - Via Licensing Jon Rosdahl, CSR

  6. Feedback to 802.1/802.3 • No comment feedback received. Jon Rosdahl, CSR

  7. 802.21 PAR Feedback (1) • 802.21 WG : Multi-Radio Power Management • General comment: • If you are managing Watts, then measure Watts. • Power consumption is not generally available from Radio interfaces, so it is not meaningful to manage power control using measurements that are not available. (802.2 LLC does not expose power consumption). • Multiple Radio Power Management does not belong in 802.21. • Handover control is not the same as Power management. • Power management in a client is truly an implementation issue not a standardization issue • The 5C provide insufficient justification for starting this project. Jon Rosdahl, CSR

  8. 802.21 PAR Feedback (2) • 802.21 WG : Support for Emergency Services • 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. • 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) Jon Rosdahl, CSR

  9. 802.21 PAR Feedback (3) • 802.21 WG : Support for Emergency Services Jon Rosdahl, CSR

  10. 802.22a PAR Feedback Comments (1) • General comment: 802.22 is described as a Regional Area Network that is reusing the TV Bands. All PARs from this WG should reflect this in their scope and purpose. • 5.1 – The Number of people claimed in the PAR does not match current voter list numbers or attendees of recent meetings of 802.22. Please explain the number of Attendees used. Jon Rosdahl, CSR

  11. 802.22a PAR Feedback Comments (2) • 5.2 – Information indicating the restricted network area that is envisioned should be added. Suggested change “…Operation is limited to operation in regional area networks utilizing the TV bands between….” • 5.3 – The PAR claims that work needs to start now so that changes to the current draft can be identified prior to completion of the base draft; however, this suggests that the PAR for the base standard should be revised. Suggest that a PAR revision be considered prior to requesting This new PAR. Jon Rosdahl, CSR

  12. 802.22a PAR Feedback Comments (3) • 5C: Broad Market Potential • The first three paragraphs address the fixed 802.22 standard, not the topic of this 5C. It is very unclear that there is a broad market for fixed 802.22 in United States under the FCC 08-260 rules. Nothing here addresses whether the 802.22 fixed vendors will also vend mobile and portable user terminals, and nothing addresses the cost benefits of volume production (see Technical Feasibility). While 802.16 and 802.11 vendors are in volume production, 802.22 vendors are not. Nothing addresses whether silicon vendors who already have PAN, LAN and MAN circuits in their products would add another LAN or PAN for this band, when the others could be used. Jon Rosdahl, CSR

  13. 802.22a PAR Feedback Comments (4) • 5C: Compatibility • This paragraph addresses the fixed 802.22 standard, not the topic of this 5C. • 5C: Distinct Identity • Distinct Identify has not been established. • For example, 802.11-2007 provides means to operate in bands with fixed and mobile licensed devices (see Technical Feasibility). 802.11y provides the control means for a database to allow operation on white space channels at a location, and to control power level and other operational characteristics. It is clear that 802.22a mobile and personal devices will use shorter symbol times than 802.22 fixed devices, and it is not clear how they differ from 802.16h mobile and portable devices. Jon Rosdahl, CSR

  14. 802.22a PAR Feedback Comments (5) • 5C: Technical Feasibility: • VHF is not allowed for personal/portable operation, only TV channels 21-51 in lower UHF. • 5C: Technical Feasibility: • .16/.22 type protocols which are optimized for licensed bands, and yet are being applied to unlicensed bands. For Example, the sharing of the overlap RF coverage areas will degrade faster with a .16/.22 type protocol than a .11 protocol. Jon Rosdahl, CSR

  15. References • 11-09/0286r3 • https://mentor.ieee.org/802.11/dcn/09/11-09-0286-03-0000-plenary-information-mar-09.ppt • 21-09-0027r0 • http://mentor.ieee.org/802.21/file/09/21-09-0027-00-00es-emergency-services-par-and-5c.doc • 21-09-0021r0 • http://mentor.ieee.org/802.21/file/09/21-09-0021-00-mrpm-mrpm-revised-par-5c.doc • 22-09-0029r0 and 0030r1 • https://mentor.ieee.org/802.22/file/09/22-09-0029-00-0000-draft-22a-par.doc • https://mentor.ieee.org/802.22/dcn/09/22-09-0030-01-0000-draft-22a-5c.doc • 802.3 and 802.1 docs: • http://www.ieee802.org/1/files/public/docs2008/bb-thaler-pfc-frame-par-1108.pdf: • http://www.ieee802.org/1/files/public/docs2008/new-dcb-thaler-draft-pfc-5c-0208-v3.pdf Jon Rosdahl, CSR

  16. Responses for 802.3bd MAC Control Frame for Priority-based Flow Control • We received the following comments on the PAR from 802.3:5.6 Why isn't 802.3 listed as a stakeholder? IEEE 802.3 is the registration authority for allocation of MAC Control Opcodes.8.1 Please add the following text: "Although the project is being done in 802.1, 802.3 controls the registry for code space in this area. Code points are not assigned until Sponsor Ballot. When the draft goes to Sponsor ballot, IEEE 802.3 will allocate a value for the Opcode."We accepted the comments.The updated PAR is at:http://ieee802.org/1/files/public/docs2009/bb-thaler-pfc-frame-par-0309.pdfThere were no changes to the 5 Criteria.Pat Thaler Jon Rosdahl, CSR

  17. Response from 802.22 ----- Original Message ----- From: "Gerald Chouinard" Sent: Wednesday, March 11, 2009 5:27 PM Subject: Re: [802SEC] Feedback on PARs from 802.11 Thank you for the comments from 802.11.  You will find the responses from 802.22 inserted in blue in the attached version of your Powerpoint document.Gerald • Note that the response is included here as slide 18-22. Jon Rosdahl, CSR

  18. 802.22a PAR Feedback Comments (1) • General comment: 802.22 is described as a Regional Area Network that is reusing the TV Bands. All PARs from this WG should reflect this in their scope and purpose. • Agreed. Modifications can be made accordingly. • 5.1 – The Number of people claimed in the PAR does not match current voter list numbers or attendees of recent meetings of 802.22. Please explain the number of Attendees used. • The number stated reflects maximum attendance reached over the 4 years of the WG. It has decreased lately but is expected to pick up when mobile and portable applications are considered. Jon Rosdahl, CSR

  19. 802.22a PAR Feedback Comments (2) • 5.2 – Information indicating the restricted network area that is envisioned should be added. Suggested change “…Operation is limited to operation in regional area networks utilizing the TV bands between….” • Counter proposal: “ …operation in TV bands where spectrum is available between…” Actual operation would not be limited geographically but spectrally. • 5.3 – The PAR claims that work needs to start now so that changes to the current draft can be identified prior to completion of the base draft; however, this suggests that the PAR for the base standard should be revised. Suggest that a PAR revision be considered prior to requesting This new PAR. • Fair comment. This could be done if this is the wish of the EC. Jon Rosdahl, CSR

  20. 802.22a PAR Feedback Comments (3) • 5C: Broad Market Potential • The first three paragraphs address the fixed 802.22 standard, not the topic of this 5C. It is very unclear that there is a broad market for fixed 802.22 in United States under the FCC 08-260 rules.Channels 2 to 20 will be available for fixed operation only, likely for bringing broadband access to underserved rural areas. Is IEEE 802 limited to financial viability aspects or can societal aspects come into play? • Nothing here addresses whether the 802.22 fixed vendors will also vend mobile and portable user terminals, and nothing addresses the cost benefits of volume production (see Technical Feasibility). While 802.16 and 802.11 vendors are in volume production, 802.22 vendors are not. Nothing addresses whether silicon vendors who already have PAN, LAN and MAN circuits in their products would add another LAN or PAN for this band, when the others could be used. • Physics is such that the optimum technical parameters are different in the use of lower frequencies such as VHF and low-UHF as compared to 2.4 GHz and higher (Doppler, antenna directivity, multipath, coverage). Use of current PAN, LAN and MAN circuits would be sub-optimum for appropriate operation in these lower frequency bands. Jon Rosdahl, CSR

  21. 802.22a PAR Feedback Comments (4) • 5C: Compatibility • This paragraph addresses the fixed 802.22 standard, not the topic of this 5C. • Same advantage as for the fixed operation will apply to the mobile and portable applications. Intent is to comply with 802.1. • 5C: Distinct Identity • Distinct Identify has not been established. • For example, 802.11-2007 provides means to operate in bands with fixed and mobile licensed devices (see Technical Feasibility). 802.11y provides the control means for a database to allow operation on white space channels at a location, and to control power level and other operational characteristics. It is clear that 802.22a mobile and personal devices will use shorter symbol times than 802.22 fixed devices, and it is not clear how they differ from 802.16h mobile and portable devices. • 802.22a expect to use the same symbol time as 802.22 to be fully compatible and the lower frequencies allow sufficient speed for vehicular application. Jon Rosdahl, CSR

  22. 802.22a PAR Feedback Comments (5) • 5C: Technical Feasibility: • VHF is not allowed for personal/portable operation, only TV channels 21-51 in lower UHF. • Correct. Not clear what is the point. • 5C: Technical Feasibility: • .16/.22 type protocols which are optimized for licensed bands, and yet are being applied to unlicensed bands. • 802.22 includes the necessary capabilities for sensing incumbents (database and sensing management control, synchronization of sufficiently large quiet periods and inter-cell exchange of information. • For Example, the sharing of the overlap RF coverage areas will degrade faster with a .16/.22 type protocol than a .11 protocol. • Coexistence schemes are being developed in 802.22 to improve the situation and they will be applied to 802.22a. Jon Rosdahl, CSR

  23. 802.21 Emergency Services ----- Original Message ----- From: "Gupta, Vivek G" Sent: Wednesday, March 11, 2009 4:15 PM Subject: Re: [802SEC] 802.21 PAR on Emergency Services for March 2009 (Vancouver) Dear EC Members, Emergency Services Study Group has addressed all the received comments.Please find the updated PAR and 5C at:http://mentor.ieee.org/802.21/dcn/09/21-09-0027-01-00es-emergency-services-par-and-5c.docAnd the responses to comments at:http://mentor.ieee.org/802.21/dcn/09/21-09-0047-00-00es-response-to-802-11-and-802-16-es-par-and-5c-comments.ppt Best RegardsVivek Jon Rosdahl, CSR

  24. Response from 802.21 received 3-11-09 -- 3:16pm 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 Jon Rosdahl, CSR

  25. 802.11 response on 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 Jon Rosdahl, CSR

  26. 802.21 Multi-Radio Power Management ----- Original Message ----- From: "Gupta, Vivek G“ Sent: Wednesday, March 11, 2009 4:15 PM Subject: Re: [802SEC] 802.21 PAR on Multi-Radio Power Management for March 2009 (Vancouver) Dear EC Members, The MRPM group has addressed all the received comments. Please find the updated PAR and 5C at:http://mentor.ieee.org/802.21/dcn/09/21-09-0021-02-mrpm-mrpm-revised-par-5c.docAnd the response to received comments at:http://mentor.ieee.org/802.21/dcn/09/21-09-0043-02-mrpm-response-to-par-5c-comments.pptBest Regards -Vivek Jon Rosdahl, CSR

  27. 802.21 Response to 802.11 Comments (1/4) General comment: • If you are managing Watts, then measure Watts. • Power consumption is not generally available from Radio interfaces, so it is not meaningful to manage power control using measurements that are not available. (802.2 LLC does not expose power consumption). • Each technology defines its own power saving mechanisms to reduce its own power consumption. MRPM will not change the power saving mechanisms defined by that technology. Therefore, MRPM’s approach is based on existing power saving modes and does not need to measure Watts. MRPM will provide the mechanism to manage and coordinate multi-radios in the device and their networks to save power. Jon Rosdahl, CSR

  28. 802.21 Response to 802.11 Comments (2/4) Multiple Radio Power Management does not belong in 802.21. • Handover control is not the same as Power management. • We think that 802.16’s comments, “Our suggestion is the following: “IEEE Media Independent Handover and Multi-Radio Services. We believe that this title would provide for additional future amendments” are excellent and as a matter of fact, there will be more services which can be built above 802.21 beyond handover such as multi-radio power management. • 802 EC agreed to create this study group with the objective to create PAR and 5C in 802.21. Jon Rosdahl, CSR

  29. 802.21 Response to 802.11 Comments (3/4) Power management in a client is truly an implementation issue not a standardization issue • We do not eliminate the ability of the client to manage power. MRPM extends this ability through network support of additional power saving options. • Current standards have defined various power saving modes for power management. Without such standards, the network and the device from different vendors cannot achieve today’s talk time and standby time. MRPM is built above these power saving modes in their respective standards to coordinate and manage multi-radio power. Jon Rosdahl, CSR

  30. 802.21 Response to 802.11 Comments (4/4) The 5C provide insufficient justification for starting this project. • We have added the following to section 17.5.1a Multiple vendors and numerous users in the revised 5C: “Multi-radio devices have already experienced battery life problems.” • In addition, the need for the project is in Section 5.5 of the PAR. Jon Rosdahl, CSR

More Related