Session #68 802.16 GRIDMAN Opening Report
IEEE 802.16 Presentation Submission Template (Rev. 9)
Document Number:
IEEE 802.16gman-10/xxxx
Date Submitted:
2010-07-10
Source:
Tim Godfrey
EPRI
Chair IEEE 802.16 GRIDMAN Study Group
Voice:
E-mail:
Venue:
IEEE 802.16 Session #68
Base Contribution:
N/A
Purpose:
Session #68 Opening Report / Agenda for GRIDMAN SG
Notice:
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups . It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.
Release:
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.16.
Patent Policy:
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< http://standards.ieee.org/guides/bylaws/sect6-7.html#6 > and < http://standards.ieee.org/guides/opman/sect6.html#6.3
>.
Further information is located at < http://standards.ieee.org/board/pat/pat-material.html
> and < http://standards.ieee.org/board/pat >.
1

July 12, 2010
2

• GRIDMAN Web site
• http://grouper.ieee.org/groups/802/16/sg/gridman
• PAR (80216-10/0018r2) approved by NESCOM on 18 June
2010.
• Continuing in Study Group mode for this session – voting open to all attendees
• Call for Contributions for 802.16n System Requirements
Document (80216GMAN-10/0022)
• Issued 4-15-2010 – will close this week
• http://ieee802.org/16/sg/gridman/#10_0022
• Focus for Session #68 will be on developing a draft of the
802.16n System Requirements Document (SRD) from the outline in document C80216gman-10/0022
3

Date Time Details
Tuesday
13 July 2010
08:00-12:00
08:00-10:00
• Approve agenda & minutes, review patent slides, attendance, roster
• Review of C80216gman-10/0022
• Outline of SRD from Session #67
• Revisit 802.16n integration question: 802.16m only, or all of base?
• Discuss and develop work plan, SRD process
• Establish order of contribution presentations
• Contribution presentations
• Contribution presentations
10:00-12:00
Wednesday
14 July 2010
Thursday
15 July 2010
13:00-18:00
08:00-18:00
• Joint Session with PPC (M2M)
• M2M PAR and requirements overlap, schedule alignment
• Consolidation of text proposals
• Contribution presentations
• C80216gman-10_0027.doc
• C80216gman-10_0025.doc
• 802.16m-07-001r1
• Initial editing of draft System Requirements Document
• Review Work Plan, Schedule
4

• Develop SRD
– Accept contributions through July 2010 meeting
– Approve D1.0
– Finalize Requirements section in September 2010
• System Architecture Reference Model (as an annex to SRD)
– In parallel, we can start to take contributions toward the spec
• System Design Document SDD
– SDD has value, but we can do it smarter than TGm – the purpose should be to define the architecture that defines the design. The SDD is the venue for defining the high-level features and architecture –
Maybe re-name it System Architecture.
– SDD did not work well for TGm because it became a consensus statement and took lots of realignment. (is there an option to “abandon” it at some point?)
– We don’t want to spend time on a “non-essential” document. On the other hand we need to have a well defined architecture before starting the actual spec.
• Alternate - Draft “outline” of specification prior to starting specification
– (issue with SDD process is that discussions have to occur twice)
– Reason for SDD was for ITU requirement.
– Could we make an “architecture” annex to the SRD? System Architecture Reference
Model.
– How does SAR gain “official” standing?

• Develop SRD
– Accept contributions through July 2010 meeting
– Approve D1.0.
– Call for comments on Draft 1.0 will be issued at end of July 2010
– Process comments, resolve, and refine D1.0 in September 2010
– Finalize and approve SRD Document in September 2010.
• Call for contributions for SARM and P802.16n Working Document
– Opening after September 2010 meeting, contributions to be presented at November 2010
– Develop System Architecture Reference Model (as an annex to SRD)
• We believe that the SARM is part of the SRD so it constrains the overall system architecture and is an official document.
– In parallel, will take contributions toward the baseline P802.16n Draft Standard and TOC
– Develop first draft of SARM annex (Nov ember 2010)
– Call for comments on first draft of SARM Annex (after November 2010)
– Editor issues Table of Contents for P802.16n Working Document (November 2010)
• From this point, contributions to working document are based on TOC
– Process comments on first draft of SARM annex, resolve and complete SARM Annex
– Finalize and Approve SARM annex to SRD (January 2011)
• Drafting of baseline P802.16n Working Document
– Develop P802.16n Working Document
– Contributions are voted into the working document
– Ballot Schedule….

– https://murphy.events.ieee.org/imat/index
– Now using Post-PAR slide set
– http://standards.ieee.org/board/pat/pat-slideset.ppt
8

l l
All participants in this meeting have certain obligations under the IEEE-SA
Patent Policy. Participants: l
“Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents l
“Personal awareness” means that the participant “is personally aware that the holder may have a potential Essential Patent Claim,” even if the participant is not personally aware of the specific patents or patent claims l
“Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of such potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) l
The above does not apply if the patent claim is already the subject of an
Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group
Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6.2
Early identification of holders of potential Essential Patent Claims is strongly encouraged
No duty to perform a patent search
Slide #1

Slide #2
All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development.
Patent Policy is stated in these sources:
IEEE-SA Standards Boards Bylaws http://standards.ieee.org/guides/bylaws/sect6-7.html#6
IEEE-SA Standards Board Operations Manual http://standards.ieee.org/guides/opman/sect6.html#6.3
Material about the patent policy is available at http://standards.ieee.org/board/pat/pat-material.html
If you have questions, contact the IEEE-SA Standards Board Patent Committee
Administrator at patcom@ieee.org or visit http://standards.ieee.org/board/pat/index.html
This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt

– Either speak up now or
– Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or
– Cause an LOA to be submitted
Slide #3

l
All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. l l
Don’t discuss the interpretation, validity, or essentiality of patents/patent claims.
Don’t discuss specific license rates, terms, or conditions.
l
Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. l l l l
Technical considerations remain primary focus
Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets.
Don’t discuss the status or substance of ongoing or threatened litigation.
Don’t be silent if inappropriate topics are discussed … do formally object.
---------------------------------------------------------------
See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and
“Promoting Competition and Innovation:
What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details.
Slide #4

– http://grouper.ieee.org/groups/802/16/sg/gridman/
– http://www.ieee802.org/16/sg/gridman/docs/80216gman
-10_0018r2.pdf
– http://www.ieee802.org/16/sg/gridman/contrib/C80216g man-10_0022.doc
13

–
– C80216gman-10_0023.doc
Text proposal of 802.16n System Requirements Document (Section 6.2) |
• Kyungkyu Kim, Jungje Son, Youngbin Chang | Samsung Electronics Co., Ltd
–
– C80216gman-10_0028.pdf
Proposed changes to 802.16n SRD|
• Youngbin Chang, Rakesh Taori and Jungje Son| Samsung
–
– C80216gman-10_0024.doc
Text proposal to 802.16n System Requirements Document
• Eldad Zeira, Ron Murias | InterDigital
–
– C80216gman-10_0026.doc
Proposed texts of 802.16n System Requirements
• Sungcheol Chang, Sungkyung Kim, Hyun Lee, Jaesun Cha, Chulsik Yoon| ETRI
–
– C80216gman-10_0027.doc
Text proposal to 802.16n System Requirement Document (Section 6.1) |
• Anseok Lee, Wooram Shin, Hyun Jae Kim, Kwang Jae Lim | ETRI
–
– C80216gman-10_0025.doc
Security considerations for mobile to mobile direct communications |
• Eldad Zeira, Alex Reznik| InterDigital
– 802.16m-07-001r1
• Military Deployment Scenarios for 802.16m - Mat Sherman BAE Systems
14

• PPDR is a key component of TGn
• Rakesh suggest we preview contributions to see the full set of contributions then come back for decisions.
• We should not get hung up on the current PAR – it can be refined and changed if necessary.
• Consider requirements feature or mechanism at a time.
• M2M PAR has become very focused to low power, large # devices, and small burst transmissions.
• We will have ongoing coordination with M2M.
• Some requirements called for in 0023 may be above the MAC/PHY layer that is the limit of
802.16 scope. These will be called out in the SRD.
• There is a need to facilitate group calls in MAC and PHY. (maybe call it “Group
Connection”)
• Consider existing mesh technologies developed in IEEE802 – we should not take on too many functions at one time.
• Viewpoints:
– PPDR is an essential part of 16n and closely tied to robust and reliable networks, and should be a part of 16n
– PPDR perhaps should be part of 16p (but is not part of 16p PAR today)
– PPDR and Smart Grid are applications – the projects provide functionality to serve the applications.

• Key requirement 99.999% reliability of power – drives path redundancy.
• Link from home to pole is unclear what standard is used (could be Wi-Fi or WiMAX). From pole back to utility is definite scope for WiMAX
• Reliability of communications is not the same as reliability of power. Communications does not have to be co-located with power infrastructure
• Distributed Generation – will be a part of requirements for distribution
• Sensing and relaying parts are both of distribution –
• Five 9’s of reliability is for power – what is need for communication. They are related, but we don’t know the exact number.
• In-home infrastructure for demand response. Backhaul for HAN. Is that a requirement?
• Public vs private – is a private network a requirement? Yes we think there is a need for utility-owned and –operated networks. Is this a question we have to answer in 16n – does it drive the requirements?
• Performance requirements – should they be separated by what is already addressed? What about low latency – is that better handled in M2M? How does that interact with security and network entry? It is independent of the data burst time. Need further clarification.
• Kirsten – because these are smart grid, it doesn’t mean they belong in 16n.

• Should the 802.16n amendment be written to modify all Clauses of the base
802.16 standard?
– The 802.16m amendment has been written with separate PHY and MAC clauses. (section 16)
– To modify all functionality of 802.16-2009 as well as TGm we will have to make changes in two places.
• Straw Poll from Session #67
– Option 1: Make changes for 802.16-2009+16j (2009 as amended by 16j) and
16m: 5 votes
– Option 2: Make changes for 16m only (benefits of 16n only apply to 16m): 7 votes
• Is a hybrid possible? For example some capabilities such as mobile to mobile could be 16m only, but others apply to both.
• Conclusion: We don’t have to decide now – we need to complete the
SRD and decide the applicability when we have completed the SRD.

• Start of TG, Start SRD
• Approved SRD
• CFP issued
• System Design Doc
• Interim Doc
• WG LB issued
• Recirc 1
• Recirc 2
• Sponsor
• Approved Std
July 2010
Sept 2010
Sept 2010
Jan 2011
July 2011
Sept 2011
Nov 2011
Jan 2012
Mar 2012
Nov 2012