doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 1 Smart Grid Technology Information - July 2010 Date: 2010-July-12 Abstract: Discussion topics for July 802 Plenary meeting NameCompanyAddressPhone Bruce KraemerMarvell5488 Marvell Lane, Santa Clara, CA, Kaberi Banerjee

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 2 July Topics 1.Monday night tutorial Any topics for further exploration? 2.EPRI Unified Metrics Craig Rodine 3.Updates to the NIST Twiki site ad hoc status 5.Progress & next steps toward completion of PAP#2 report Review of submitted text Generation of additional text

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 3 Tutorial on Broad Scope of SG Efforts Monday July 12, EC-smart-grid-information-update-july-2010.pdfhttps://mentor.ieee.org/802-ec/dcn/10/ec EC-smart-grid-information-update-july-2010.pdf Is there any topic that merits further discussion? Topic #1

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 4 Unified Metrics Unified Metrics for Management of Smart Grid Home Area Networks (Dec 2009) Tim Godfrey, Craig Rodine 1 st International Workshop on Smart Grid Communications Multiple IEEE network technologies, including , and P1901 can all support Smart Grid applications in Home Area Networks (HANs). Utilities need visibility into the HAN to ensure the network is operational and able to support critical applications such as Demand Response and Electric Vehicle Charging. This paper describes a set of network performance metrics that are consistent among the most prevalent HAN network technologies. management-of-smart-grid-home-area-networks.ppt Topic #2

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 5 New Addition to NIST Twiki Tools provided by Others Matlab code for 802_15_4_MAC_PHY_Model README_802_15_4_MAC_PHY_Model.pdfMatlab code for 802_15_4_MAC_PHY_Model README_802_15_4_MAC_PHY_Model.pdf Topic #3

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 6 Latest Version of Report sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priotity_ Action_Plan_2_r04.pdfhttp://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priotity_ Action_Plan_2_r04.pdf Does anyone have comments? Topic #4

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 7 Recent Paper Contributions Input for consideration for next version of guideline from PAP#2 Preface_PAP_2_guidelines_v0.5_Hughes.doc: PrefacePreface_PAP_2_guidelines_v0.5_Hughes.doc Prepared_definitions.doc: additional definitions for section 2Prepared_definitions.doc Section_4-composite-r1.doc: test for consideration of section 4Section_4-composite-r1.doc a_-_C A__WG3- ProposedCovertr455ToSGIPPAP2.doc: Cover letter a_-_C A__WG3- ProposedCovertr455ToSGIPPAP2.doc – r1_-_C __WG3- ProposedInputToSGIPPAP2.pdf: results r1_-_C __WG3- ProposedInputToSGIPPAP2.pdf WTSC-RAN R3.doc: reportWTSC-RAN R3.doc –SmartGrid_Calculation.xls: calculationsSmartGrid_Calculation.xls Topic #4

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 8 Completion of the Report How can 802.1, , 802.xxx best assist NIST in completing the report? Author additional text? Review what’s been contributed? Run simulation models and provide results? Topic #4

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 9 Topics for continuation on Thursday? Room assignment = 8am Elizabeth H In-depth discussion of one or more parts of the pending NIST report? Extensions to technology needed to service this application space? –Network measurement, Security features (AES 256), range Coexistence with ? SEP 2.0 message transfer to/from g and P1901? LCRA experiment Call plan/call topics for period leading up to September interim –Wednesdays at 2pm ET has been the pattern

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 10 Previous Discussion Material

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 11 Current Priority Action Plans The priority action plans page provides a guide to the function and operation of these plans.priority action plans # Priority Action Plan 0 Meter Upgradeability Standard 1 Role of IP in the Smart GridMeter Upgradeability Standard Role of IP in the Smart Grid 2 Wireless Communications for the Smart Grid 3 Common Price Communication ModelWireless Communications for the Smart GridCommon Price Communication Model 4 Common Scheduling Mechanism 5 Standard Meter Data ProfilesCommon Scheduling MechanismStandard Meter Data Profiles 6 Common Semantic Model for Meter Data Tables 7 Electric Storage Interconnection GuidelinesCommon Semantic Model for Meter Data TablesElectric Storage Interconnection Guidelines 8 CIM for Distribution Grid Management 9 Standard DR and DER SignalsCIM for Distribution Grid ManagementStandard DR and DER Signals 10 Standard Energy Usage Information 11 Common Object Models for Electric TransportationStandard Energy Usage InformationCommon Object Models for Electric Transportation 12IEC Objects/DNP3 MappingIEC Objects/DNP3 Mapping 13Time Synchronization, IEC Objects/IEEE C HarmonizationTime Synchronization, IEC Objects/IEEE C Harmonization 14Transmission and Distribution Power Systems Model MappingTransmission and Distribution Power Systems Model Mapping 15Harmonize Power Line Carrier Standards Applliance Communications in the HomeHarmonize Power Line Carrier Standards Applliance Communications in the Home 16 Wind Plant CommunicationsWind Plant Communications

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 12 Issue: Use of Wireless Communications in the Smart Grid There are a number of advantages for using wireless communications including: –Untethered access to information –Mobility –Interoperability –Reduced cost and complexity –Availability of technologies with different characteristics to choose from A number of challenges remain to be addressed: –How to choose among technologies with different characteristics? –How do we know which technology to use for what Smart Grid application? –Are there any implications for using a certain wireless technology in a certain environment? –Are there any deployment? Interference issues?

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 13 Review of PAP#2 tasks 1.Develop Smart Grid application communication requirements and devise a taxonomy for applications with similar network requirements –Draft under development and available for review sggrid/pub/SmartGrid/PAP02Wireless/app_matrix_pap.xlshttp://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/app_matrix_pap.xls 2.Develop terminology and definitions 3.Compile and communicate use cases and develop requirements –is part of Task 1 4.Create an attribute list and performance metrics for wireless standards –Draft developed and available for reviewhttp://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/NIST_PAP2-_Wireless_Characteristics- IEEE802-v_02.xlshttp://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/NIST_PAP2-_Wireless_Characteristics- IEEE802-v_02.xls 5. Create an inventory of wireless technologies and standards that are identified by each SDO –Feedback is expected by December 6, Conduct an evaluation of the wireless technologies based on the application requirements –Perform a gap analysis and developing guidelines for the use of wireless technologies.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 14 Introduction to the NIST PAP2 Report Report Preface This guide is the output of the Priority Action Plan number 2 (PAP#2), wireless communications for the smart grid, which is part of the Smart Grid Interoperability Panel (SGIP). PAP#2’s work area investigates the strengths, weaknesses, capabilities, and constraints of existing and emerging standards-based physical media for wireless communications. The approach is to work with the appropriate standard development organizations (SDOs) to determine the characteristics of each technology for Smart Grid application areas and types. Results are used to assess the appropriateness of wireless communications technologies for meeting Smart Grid applications’ requirements. This guide contains the smart grid reference architecture, the user applications’ requirements, candidate wireless technologies and their capabilities, a methodology to assess the appropriateness of wireless communications technologies along with an example model, and some results.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 15 NIST Modeling Presentation Detailed description of the modeling approach can be found at: sggrid/pub/SmartGrid/PAP02Wireless/PAP2modeling. ppthttp://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/PAP2modeling. ppt

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 16 NIST Modeling Tools provided by NIST and used in presentation PAP2modeling.ppt PAP2modeling.ppt nist_80211_mac.m: Matlab code for 80211_MAC_Modelnist_80211_mac.m nist_80211_MAC_readme.pdf: Readme file for using the model Matlab codenist_80211_MAC_readme.pdf SNRcdf.m: Matlab code for computing SNR probability at wireless receiverSNRcdf.m SNRcdfCell.m: Matlab code for coverage analysisSNRcdfCell.m nist_phy_model_readme.pdf: Readme file for using Matlab code for SNRcdf and SNRcdfCellnist_phy_model_readme.pdfSNRcdfCell nist_channel_propagation_models.pdf: Channel propagation modelsnist_channel_propagation_models.pdf

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 17 Meter Reporting Application: Mean Delay versus Offered Load

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 18 PAP#2 Report Outline Table of Contents Revision History iii Preface Authors Overview of the process Acronyms and Definitions Acronyms Definitions Smart grid Reference Architecture List of actors Use Cases Application requirements Smart grid user applications’ quantitative requirements Aggregation of requirements per actor to actor Wireless Technology Evaluation approach / Modeling approach Channel Models Indoor-indoor environments Outdoor-outdoor environments Outdoor-indoor environments Physical Layer MAC sublayer Example Modeling Tool Other Tools Findings / Results Conclusions References Bibliography

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 19 NIST Report status Working draft of Guidelines for using wireless communications (Output of March 31, 2010). NIST_Priotity_Action_Plan_2_r04.pdf: Fourth draft version of the guideline from PAP#2NIST_Priotity_Action_Plan_2_r04.pdf Additional material submitted for insertion in paper r5. Send comments to

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 20 Example of Framing PLCP Preamble 18 Byte PLCP Header 6 Byte MAC Header 30 Byte LLC 3 Byte SNAP 5 Byte IP Header 20 Byte TCP Header 20 Byte Data 0 - xxxx Byte FCS Frame Check 4 Byte TCP/IP packet MPDU data frame PPDU data frame The bit package sent over the air is the PPDU which contains all of the PHY specific information, the MAC specific information, TCP/IP information, and the user application data.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 21 Example: Construction of PPDU around payload

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 22 Information from prior calls

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 23 Agenda Status Report on Connectivity Week - Santa Clara May Any other items from members

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 24 Status report Connectivity Week - Santa Clara May Included meetings for SGIP & P2030 Most of the SGIP DEWGs & PAPs held working meetings P2030 held 4 days of meetings

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 25 P2030 Overview Standard Title IEEE P2030 Draft Guide for Smart Grid Interoperability of Energy Technology and Information Technology Operation with the Electric Power System (EPS), and End-Use Applications and Loads Scope This document provides guidelines for smart grid interoperability. This guide provides a knowledge base addressing terminology, characteristics, functional performance and evaluation criteria, and the application of engineering principles for smart grid interoperability of the electric power system with end-use applications and loads. The guide discusses alternate approaches to good practices for the smart grid.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 26 P2030 Highlights P2030 held 4 days of meetings Primary activity was review and proposed edits of Draft p2030-draft-2-1-with-line-numbers-added.pdfhttps://mentor.ieee.org/2030/dcn/10/ p2030-draft-2-1-with-line-numbers-added.pdf Most time spent in each group refining the diagrams Comments collected will be incorporated during June Draft 3.0 due out for comment in July

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 27 SGIP Events –SGIP Plenary Meetings and Webinars (attendance required for participating members)SGIP Meeting Name Type Date/Times of upcoming meetings Registration Spring Meeting Face-to-Face May 24 to May 27 Agenda for week.Agenda for week Plenary Update Webinar July 23rd, 1pm to 3pm Eastern To register and receive web/phone accessTo register and receive web/phone access Plenary Update Webinar Sept. 17th, 1pm to 3pm Eastern To register and receive web/phone accessTo register and receive web/phone access Plenary Update Webinar Oct. 29th, 1pm to 3pm Eastern To register and receive web/phone accessTo register and receive web/phone access Fall Meeting Face-to-Face Nov. 30 to Dec. 3 Current details. Further details to post in early October.Current details

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 28

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 29 Near Term Action Items Completion for review of PAP#2 report Section 4 (Wireless) Current version of overall report can be found at: Next Call Wednesday June 9 (877) Status report on all activities for IEEE 802 July Plenary

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 30 Introduction to the NIST PAP2 Report Report Preface This guide is the output of the Priority Action Plan number 2 (PAP#2), wireless communications for the smart grid, which is part of the Smart Grid Interoperability Panel (SGIP). PAP#2’s work area investigates the strengths, weaknesses, capabilities, and constraints of existing and emerging standards- based physical media for wireless communications. The approach is to work with the appropriate standard development organizations (SDOs) to determine the characteristics of each technology for Smart Grid application areas and types. Results are used to assess the appropriateness of wireless communications technologies for meeting Smart Grid applications’ requirements. This guide contains the smart grid reference architecture, the user applications’ requirements, candidate wireless technologies and their capabilities, a methodology to assess the appropriateness of wireless communications technologies along with an example model, and some results.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 31 Section 4 – Wireless Technology -Contents Outline Introduction The data collection form –Group categories –Row descriptions Clarification of the row entry Technology information (Columns) –Technology names –Technology sources –Explanation of Entries & Validation source Per Technology descriptions –Completed –Under development Reference Sources

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 32 Wireless Characteristics 1. Link Availability 2. Data/Media Type Supported 3. Coverage Area 4. Mobility 5. Data Rates 6. RF Utilization 7. Data Frames & Packets 8. Link Quality Optimization 9. Radio Performance Measurment & Management 10. Power Management 11. Connection Topologies 12. Connection Management 13. QoS & Traffic Prioritization 14. Location Characterization 15. Security & Security Management 16. Radio Environment 17. Intra-technology Coexistence 18. Inter-technology Coexistence 19. Unique Device Identification 20. Technology Specification Source 21. Deployment Domain Characterization 22. Exclusions

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 33 Wireless Technologies Cdma2000 1x and cdma2000 HRPD Cdma2000 xHRDP GMR-1 3G IPOS/DVB-S2 RSM-A IEEE e,m IEEE IEEE Inmarsat BGAN LTE HSPA+ UMTS EDGE

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 34 Technology Description and Behavior in support of Throughput calculations Range Calculations Security

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 35 Technology Description Clarifications

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 36 Group 2: Data/Media Type Supported, b: Data; 2.1 Group 2: Data/Media Type Supported, b: Data; Over the air PHY rate What is the meaning of Data? It is in measurement units of Maximum user data rate per user in Mb/s. Since gives 0.25 Mb/s one might assume that it is the physical medium rate. However with that assumption, it does not apply to the value for of 0.70 Mb/s. Therefore one must assume another meaning. For example data rate minus protocol (and/or framing) overhead results in 0.70 Mb/s (i.e., maximum user data rate (i.e., MAC Service Data Unit)), if so then the value must be changed to comply with that assumption. Agreement on a consistent meaning of Data is needed. Is it the maximum user data rate seen at the interface to/from the MAC sublayer? Is it an instantaneous data rate? Since it states Maximum user data rate per user, perhaps the number of users that was assumed for the calculation needs to be stated as well, especially when the medium is shared as in and

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide Group 5: Data Rates items c and d (Peak goodput over the air UL/DL data rate) How is the goodput calculated? Is goodput strictly calculated on a single MAC sublayer frame’s payload divided by the resulting physical layer packet? Is the goodput calculated including any CSMA overhead and the entire message exchange (e.g., data frame and acknowledgement frame)? Both and can act as either peer to peer (p2p) or AP to/from STA for or coordinator to/from device for So for the peer case UL and DL would be the same. However for the non- P2P case UL and DL might be different. Both and use the same channel in this case, but the protocol overhead might be different (e.g., polling a PAN coordinator to retreive data vs device sending to PAN coordinator for ). Clarification (i.e., note) on the type of mode that is being used to achieve the values for the data rates is needed.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide Sample peak goodput for baseline Was not able to obtain 0.7 Mb/s, assuming only data transmission overhead for one data frame transmission and its associated acknoledgement. What other additional overhead assumptions were assumed? Beacon transmission? RTS/CTS? Association and authentication procedures? (A) Assuming one message exchange of one 50us DIFS + zero backoff + long preamble (144) + PLCP (48) + 28 bytes MAC overhead bytes user data (maximum) + 10 us SIFS + ACKnowledgement packet under DCF; a peak throughput of Mb/s (B) Assuming one message exchange of one 50us DIFS backoff slots (average first attempt successful)+ long preamble (144) + PLCP (48) + 28 bytes MAC overhead bytes user data (maximum) + 10 us SIFS + ACKnowledgement packet under DCF and DS; a peak throughput of Mb/s.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 39 Group 7, Data frames and packets, item a frame duration and item b Maximum packet size What is meant by frame? What is meant by packet? Are they the same or different?

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide Group 7, Data frames and packets, item a frame duration and item b Maximum packet size What is meant by frame? There are three primary Frame group types identified in Management, Control & Data. Payload data is transported inside a data frame. The Data Frame is composed of a number of sub fields: control field, duration field, address fields, sequence field, data, frame check sequence. This collection of fields is referred to as a MAC Protocol Data Unit (MPDU). The source payload data may fit into one frame or if larger than 2312 bytes requires fragmentation and transmission using multiple data frames. When the MPDU is prepared to send out over the air there are additional fields added for preamble, start of frame delimiter and header. These fields then comprise the Physical Layer Packet Data Unit (PPDU). What is meant by packet? “Packet” is a general term that refers to the combination of control, address, and data fields described above that includes the payload data of interest. Are they the same or different? When the terms Packet and Frame are used without further qualifiers they can be considered to be equivalent.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 41 Technology Description Protocol Details

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 42 Frame Control (2 bytes) Frame Control (2 bytes) Duration /ID (2 bytes) Duration /ID (2 bytes) Address1 (6 bytes) Address1 (6 bytes) Address2 (6 bytes) Address2 (6 bytes) Address3 (6 bytes) Address3 (6 bytes) Sequence. Control (2 bytes) Sequence. Control (2 bytes) QoS Control (2 bytes) QoS Control (2 bytes) HT Control (2 bytes) HT Control (2 bytes) MAC and Physical Layer Data Frame Encapsulation (Ref: Draft P REVmb/D3.0, March 2010) MSDU Frame CheckSum (4 bytes) MAC MSDU CCMP Header (8 bytes) MAC Header LLC MIC (8 bytes) MIC (8 bytes) PHY MPDU PHY Layer Specific PPDU ( Example : OFDM Phy, Clause 17) PLCP Header PLCP Preamble PSDU Tail Pad Bytes

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide MAC and Physical Layer Control Frame Encapsulation (Ref: Draft P REVmb/D3.0, March 2010) Frame Control (2 bytes) Frame Control (2 bytes) Duration /ID (2 bytes) Duration /ID (2 bytes) Address1 (6 bytes) Address1 (6 bytes) Optional Address2 (6 bytes) Optional Address2 (6 bytes) Frame CheckSum (4 bytes) MAC MAC Header LLC PHY MPDU PHY Layer Specific PPDU ( Example : OFDM Phy, Clause 17) PLCP Header PLCP Preamble PSDU Tail Pad Bytes Optional Control Info (BlockAck and BlockAckReq) Optional Control Info (BlockAck and BlockAckReq) Carried Frame Control HT Control Carried Frame

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide MAC and Physical Layer Management Frame Encapsulation (Ref: Draft P REVmb/D3.0, March 2010) LLC Management Frame Body Frame Control (2 bytes) Frame Control (2 bytes) Duration /ID (2 bytes) Duration /ID (2 bytes) Address1 (6 bytes) Address1 (6 bytes) Address2 (6 bytes) Address2 (6 bytes) Address3 (6 bytes) Address3 (6 bytes) Sequence. Control (2 bytes) Sequence. Control (2 bytes) HT Control (2 bytes) HT Control (2 bytes) Frame CheckSum (4 bytes) MAC Management Frame Body MAC Header LLC PHY MMPDU PHY Layer Specific PPDU ( Example : OFDM Phy, Clause 17) PLCP Header PLCP Preamble PSDU Tail Pad Bytes

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide MAC and Physical Layer Management Frame Encapsulation (Ref: Draft P REVmb/D3.0, March 2010) LLC Management Frame Body Frame Control (2 bytes) Frame Control (2 bytes) Duration /ID (2 bytes) Duration /ID (2 bytes) Address1 (6 bytes) Address1 (6 bytes) Address2 (6 bytes) Address2 (6 bytes) Address3 (6 bytes) Address3 (6 bytes) Sequence. Control (2 bytes) Sequence. Control (2 bytes) HT Control (2 bytes) HT Control (2 bytes) Frame CheckSum (4 bytes) MAC Management Frame Body MAC Header LLC PHY MMPDU PHY Layer Specific PPDU ( Example : OFDM Phy, Clause 17) PPDU

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 46 Framing

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 47 Resulting Data Message sizes (for this selection) On-demand meter read 100 bytes TLS 25 bytes TransportTCP 20 bytes IP-SEC (Tunnel mode) 80 bytes IPv6 40 bytes IEEE CCMP 16 bytes IEEE bytes DSSS 24 bytes – TOTALS 333 bytes Similarly for Application Error on-demand meter read –TOTALS 283 bytes Similarly for Multiple interval meter read –TOTALS1833 bytes bytes* *Exceeds MTU of must segment into two frames

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 48 Technology Description PHY Details

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide a Throughput

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 50 Behavior

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 51 Example throughput calculations - #1 1Mbps PHY rate, DCF, single sender to receiver pair, no backoff

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 52 Example throughput calculations - #2 1Mbps PHY rate, DCF, single sender to receiver pair, minimal backoff

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 53 MPDU Structure A question of how much detail to provide? How to account for variables such as security options? MAC HeaderVariable length frame body containing payload data Frame Check Sequence PreambleHeader MPDU PPDU Structure

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 54 Throughput Question (A) Assuming one message exchange of one 50us DIFS + zero backoff + long preamble (144) + PLCP (48) + 28 bytes MAC overhead bytes user data (maximum) + 10 us SIFS + ACKnowledgement packet under DCF; a peak throughput of Mb/s Again, how much detail to provide? What is precise enough? How to account for theory vs practice?

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 55 Example 1: 11b 2Mbps Measured Throughput Analyzing Wireless LAN Security Overhead Harold Lars McCarter Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering 17-Apr-06Falls Church, Virginia

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 56 Example 2: Various Reported Throughputs Huawei Quidway WA1006E Wireless Access Point

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 57 Behavior

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 58 Relationship between Throughput and Payload Payload Length Throughput Lower SNR High SNR Low SNR

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 59 Effect of payload length on throughput for various retransmission limits (6 Mbps, SNR of 2 dB)

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 60 Throughput versus payload (18 Mbps, SNR 8dB) Mbps 59.2%

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 61 Capacity with 5 data users in the network (SNR is 8 dB, 6 Mbps)

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 62

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 63 Individual station

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 64

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 65 Group of stations

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide Inter-frame Spacing

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 67 Frame Spacing Relationships aSIFSTime and aSlotTime are fixed per PHY. aSIFSTime is: aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + aRxTxTurnaroundTime. aSlotTime is: aCCATime + aRxTxTurnaroundTime + aAirPropagationTime + aMACProcessingDelay. The PIFS and DIFS are derived by the following equations, as illustrated in Figure PIFS = aSIFSTime + aSlotTime DIFS = aSIFSTime + 2 × aSlotTime The EIFS is derived from the SIFS and the DIFS and the length of time it takes to transmit an ACK Control frame at the lowest PHY mandatory rate by the following equation: EIFS = aSIFSTime + DIFS + ACKTxTime where ACKTxTime is the time expressed in microseconds required to transmit an ACK frame, including preamble, PLCP header and any additional PHY dependent information, at the lowest PHY mandatory rate.

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 68 PHY Header Details The value of the TXTIME parameter returned by the PLME_TXTIME.confirm primitive shall be calculated according to Equation (19-9): TXTIME = PreambleLengthDSSS + PLCPHeaderTimeDSSS + PreambleLengthOFDM + PLCPSignalOFDM + 4 × Ceiling((PLCPServiceBits + 8 × (NumberOfOctets) + PadBits) / NDBPS) + SignalExtension(19-9) where PreambleLengthDSSS is 144 μs if the PREAMBLE_TYPE value from the TXVECTOR parameter indicates “LONGPREAMBLE,” or 72 μs if the PREAMBLE_TYPE value from the TXVECTOR parameter indicates “SHORTPREAMBLE” = or 24+8+

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide Preamble Preamble The preamble is used to communicate to the receiver that data is on its way. Technically speaking, it is the first portion of the Physical Layer Convergence Protocol/Procedure (PLCP) Protocol Data Unit (PDU). The preamble allows the receiver to acquire the wireless signal and synchronize itself with the transmitter. A header is the remaining portion and contains additional information identifying the modulation scheme, transmission rate and length of time to transmit an entire data frame. Long Preamble: Compatible with legacy IEEE systems operating at 1 and 2 Mbps (Megabits per second) PLCP with long preamble is transmitted at 1 Mbps regardless of transmit rate of data frames Total Long Preamble transfer time is a constant at 192 usec (microseconds) Short Preamble: Not compatible with legacy IEEE systems operating at 1 and 2 Mbps PLCP with short preamble: Preamble is transmitted at 1 Mbps and header at 2 Mbps Total Long Preamble transfer time is a constant at 96 usec (microseconds)

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide MCS options for “a” & “g” Data Rate (Mbps) ModulationCoding RateCoded bits per subcarrier Coded bits per OFDM symbol Data bits per OFDM symbol 6BPSK1/ BPSK3/ QPSK1/ QPSK3/ QAM1/ QAM3/ QAM2/ QAM3/

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 71 Long preamble Mbit/sNet Mbit/sEfficiency % % % %

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 72 Short Preamble Mbit/sNet Mbit/sEfficiency % % % %

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 73 Short list of citations on Throughput Churong Chen; Choi Look Law;, "Throughput performance analysis and experimental evaluation of IEEE b radio link," Information, Communications & Signal Processing, th International Conference on, vol., no., pp.1-5, Dec doi: /ICICS URL: Na, C.; Chen, J.K.; Rappaport, T.S.;, "Measured Traffic Statistics and Throughput of IEEE b Public WLAN Hotspots with Three Different Applications," Wireless Communications, IEEE Transactions on, vol.5, no.11, pp , November 2006 doi: /TWC URL: Garg, S.; Kappes, M.;, "An experimental study of throughput for UDP and VoIP traffic in IEEE b networks," Wireless Communications and Networking, WCNC IEEE, vol.3, no., pp vol.3, March 2003 doi: /WCNC URL: Bruno, R.; Conti, M.; Gregori, E.;, "Throughput Analysis of UDP and TCP Flows in IEEE b WLANs: A Simple Model and Its Validation," Techniques, Methodologies and Tools for Performance Evaluation of Complex Systems, (FIRB-Perf 2005) Workshop on, vol., no., pp , Sept doi: /FIRB-PERF URL: Mahasukhon, P.; Hempel, M.; Song Ci; Sharif, H.;, "Comparison of Throughput Performance for the IEEE a and g Networks," Advanced Information Networking and Applications, AINA '07. 21st International Conference on, vol., no., pp , May 2007 doi: /AINA URL: Bruno, R.; Conti, M.; Gregori, E.;, "IEEE optimal performances: RTS/CTS mechanism vs. basic access," Personal, Indoor and Mobile Radio Communications, The 13th IEEE International Symposium on, vol.4, no., pp vol.4, Sept URL:

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 74 Other Backup material

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 75

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 76 TCP dataTCP ACK DIFS28 µs Data 20 µs + 57 * 4 µs/symbol +6 µs = 20 µs µs = 254µs 20 µs + 3 * 4 µs/symbol + 6 µs = µs = 38 µs SIFS10 µs ACK 20 µs + 1 * 4 µs/symbol + 6 µs = 20 µs + 4 µs + 6 µs = 30µs= 30 µs Frame exchange total322 µs106 µs Transaction Total428 µs

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 77

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 78

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 79 Example throughput calculation Assuming that there are two stations exchanging data using DCF using basic access what is MAC layer throughput? Answer: Total data in 1 frame = 1452 byte MAC Header length = 28 bytes Total frame size = = 1480 byte Time required for transmission at 54 Mbps = 1480*8 /(54 Mbps)= μs Total time required for transmission of 1 Frame = DIFS (34μs ) + Data Time ( μs ) + propagation time(1μs ) + Physical overhead (20 μs ) + SIFS(16 μs ) + ACK time(2.07 μs ) + propagation time for Ack (1 μs )+ Physical overhead for Ack (20 μs ) = μs Hence we are using μs to transmit 1452 bytes Hence MAC layer throughput = 37 Mbps 37/54 = 68.5%

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 80

doc.: IEEE /0861r1 Submission July 2010 Bruce Kraemer, MarvellSlide 81