NIST Priority Action Plan 2 

Guidelines for Assessing Wireless Standards for Smart Grid 

Applications 
ii

Table of Contents 

REVISION HISTORY ............................................................................................................................... V

PREFACE............................................................................................................................................ ‐ 1 ‐

1 OVERVIEW OF THE PROCESS..................................................................................................... ‐ 3 ‐

2 ACRONYMS AND DEFINITIONS.................................................................................................. ‐ 4 ‐

2.1 ACRONYMS ....................................................................................................................................... ‐ 4 ‐

2.2 DEFINITIONS ..................................................................................................................................... ‐ 8 ‐

3 SMART GRID CONCEPTUAL MODEL AND BUSINESS FUNCTIONAL REQUIREMENTS .................. ‐ 13 ‐

3.1 SMART GRID CONCEPTUAL REFERENCE DIAGRAMS ................................................................................. ‐ 13 ‐

3.2 LIST OF ACTORS ............................................................................................................................... ‐ 16 ‐

3.3 SMART GRID USE CASES.................................................................................................................... ‐ 18 ‐

3.4 SMART GRID BUSINESS FUNCTIONAL AND VOLUMETRIC REQUIREMENTS .................................................... ‐ 20 ‐

3.5 USE OF SMART GRID USER APPLICATIONS’ QUANTITATIVE REQUIREMENTS FOR PAP 2 TASKS ........................ ‐ 22 ‐

3.6 ADAPTATION OF SG NETWORK TF’S REQUIREMENTS TABLE DATA FOR USE IN NETWORK MODELING TOOLS .... ‐ 23 ‐

3.7 SECURITY........................................................................................................................................ ‐ 30 ‐

4 WIRELESS TECHNOLOGY ......................................................................................................... ‐ 31 ‐

4.1 TECHNOLOGY DESCRIPTOR HEADINGS .................................................................................................. ‐ 31 ‐

4.2 TECHNOLOGY DESCRIPTOR DETAILS ..................................................................................................... ‐ 32 ‐

4.2.1 Descriptions of Groups 1‐7 Submissions........................................................................... ‐ 32 ‐

4.2.1.1 Group 1:  Link Availability ...................................................................................................... ‐ 33 ‐

4.2.1.2 Group 2: Data/Media Type Supported................................................................................... ‐ 33 ‐

4.2.1.3 Group 3: Coverage Area......................................................................................................... ‐ 33 ‐

4.2.1.4 Group 4: Mobility................................................................................................................... ‐ 34 ‐

4.2.1.5 Group 5: Data Rates............................................................................................................... ‐ 34 ‐

4.2.1.6 Group 6: RF Utilization........................................................................................................... ‐ 34 ‐

4.2.1.7 Group 7: Data Frames and Packets........................................................................................ ‐ 36 ‐

4.2.2 Descriptions of Groups 8‐12 Submissions......................................................................... ‐ 36 ‐

4.2.2.1 Group 8: Link Quality Optimization........................................................................................ ‐ 36 ‐

4.2.2.2 Group 9: Radio Performance Measurement & Management................................................ ‐ 37 ‐

4.2.2.3 Group 10: Power Management.............................................................................................. ‐ 37 ‐

4.2.2.4 Group 11: Connection Topologies.......................................................................................... ‐ 37 ‐

4.2.2.5 Group 12: Connection Management ..................................................................................... ‐ 37 ‐

4.2.3 Descriptions of Groups 13‐20 Submissions....................................................................... ‐ 37 ‐

4.2.3.1 Group 13: QoS and Traffic Prioritization ................................................................................ ‐ 38 ‐

4.2.3.2 Group 14: Location Characterization ..................................................................................... ‐ 38 ‐

4.2.3.3 Group 15: Security and Security Management...................................................................... ‐ 38 ‐

4.2.3.4 Group 16: Radio Environment................................................................................................ ‐ 39 ‐

4.2.3.5 Group 17: Intra‐technology Coexistence ............................................................................... ‐ 39 ‐

4.2.3.6 Group 18: Inter‐technology Coexistence ............................................................................... ‐ 39 ‐

4.2.3.7 Group 19: Unique Device Identification................................................................................. ‐ 39 ‐

4.2.3.8 Group 20: Technology Specification Source........................................................................... ‐ 40 ‐

4.2.4 Descriptions of Group 21 Submission ............................................................................... ‐ 40 ‐

4.2.4.1 Group 21 Description............................................................................................................. ‐ 40 ‐

4.3 TECHNOLOGY SUBMISSION TITLES ....................................................................................................... ‐ 41 ‐

5 MODELING AND EVALUATION APPROACH.............................................................................. ‐ 41 ‐

5.1 ASSESSMENT OF WIRELESS TECHNOLOGIES AGAINST SMART GRID BUSINESS APPLICATION REQUIREMENTS ...... ‐ 41 ‐

5.1.1 Initial Screening ................................................................................................................ ‐ 42 ‐
iii

5.1.2 Perform Refinements to Initial Screening ......................................................................... ‐ 42 ‐

5.1.2.1 Mathematical Models............................................................................................................ ‐ 42 ‐

5.1.2.2 Simulation Models................................................................................................................. ‐ 42 ‐

5.1.2.3 Testbeds................................................................................................................................. ‐ 42 ‐

5.1.2.4 Network Design...................................................................................................................... ‐ 43 ‐

5.2 MODELING FRAMEWORK................................................................................................................... ‐ 43 ‐

5.2.1 Channel Propagation Models ........................................................................................... ‐ 44 ‐

5.2.1.1 Generic Model ....................................................................................................................... ‐ 45 ‐

5.2.1.2 Outdoor Channel Models....................................................................................................... ‐ 46 ‐

5.2.1.2.1 The Hata Model: ............................................................................................................... ‐ 46 ‐

5.2.1.2.2 Modified Hata (aka COST 231 Model): ............................................................................. ‐ 47 ‐

5.2.1.2.3 Erceg Model:..................................................................................................................... ‐ 47 ‐

5.2.2 Coverage and Range Analysis........................................................................................... ‐ 50 ‐

5.2.3 Physical Layer Model ........................................................................................................ ‐ 53 ‐

5.2.4 MAC Sublayer Model ........................................................................................................ ‐ 53 ‐

5.2.5 Multilink Model................................................................................................................. ‐ 55 ‐

6 FACTORS TO CONSIDER IN DETERMINING PERFORMANCE ...................................................... ‐ 56 ‐

6.1 PERFORMANCE METRICS AND USER APPLICATION REQUIREMENTS ............................................................ ‐ 57 ‐

6.2 THE COVERAGE‐CAPACITY TRADEOFF................................................................................................... ‐ 57 ‐

6.3 EXTENDING COVERAGE WITH MULTI‐HOP COMMUNICATIONS.................................................................. ‐ 61 ‐

6.4 THE EFFECT OF THE WIRELESS LINK ENVIRONMENT................................................................................. ‐ 62 ‐

6.5 THE EFFECT OF INTERFERENCE ............................................................................................................ ‐ 64 ‐

7 CONCLUSIONS ........................................................................................................................ ‐ 66 ‐

8 REFERENCES ........................................................................................................................... ‐ 68 ‐

9 BIBLIOGRAPHY ....................................................................................................................... ‐ 68 ‐

ANNEX A IEEE 802.11 ............................................................................................................... ‐ 69 ‐

A.1 LINK TRAFFIC MODEL ................................................................................................................... ‐ 69 ‐

A.2 PHYSICAL LAYER MODEL ............................................................................................................... ‐ 69 ‐

A.3 MAC LAYER MODEL .................................................................................................................... ‐ 69 ‐

A.4 MULTILINK MODEL...................................................................................................................... ‐ 70 ‐

A.5 PARAMETERS AND ASSUMPTIONS USED IN THE NUMERICAL EXAMPLES.................................................. ‐ 70 ‐

A.6 REFERENCES ............................................................................................................................... ‐ 72 ‐

ANNEX B 3GPP LONG TERM EVOLUTION (LTE).......................................................................... ‐ 74 ‐

B.1 MODELING APPROACH AND ASSUMPTIONS ...................................................................................... ‐ 74 ‐

B.2 CHANNEL PROPAGATION MODEL ................................................................................................... ‐ 76 ‐

B.3 COVERAGE ANALYSIS.................................................................................................................... ‐ 76 ‐

B.4 CAPACITY ANALYSIS ..................................................................................................................... ‐ 77 ‐

B.4.1 Sector Capacity ................................................................................................................. ‐ 77 ‐

B.4.2 Available Throughput per Smart Meter............................................................................ ‐ 79 ‐

B.5 REFERENCES ............................................................................................................................... ‐ 81 ‐

ANNEX C 3GPP HIGH SPEED PACKET ACCESS (HSPA)................................................................. ‐ 82 ‐

C.1 MODELING APPROACH AND ASSUMPTIONS........................................................................................... ‐ 82 ‐

C.2 ANALYSIS........................................................................................................................................ ‐ 83 ‐

C.3 CAPACITY‐LIMITED AND COVERAGE‐LIMITED SCENARIOS........................................................................... ‐ 84 ‐

C.3.1 Scenario 1: Capacity‐limited system................................................................................. ‐ 84 ‐

C.3.2 Scenario 2: Coverage‐limited system................................................................................ ‐ 85 ‐

ANNEX D CDMA2000 1X AND HIGH RATE PACKET DATA (HRPD) ............................................... ‐ 86 ‐
iv

D.1 INTRODUCTION ........................................................................................................................... ‐ 86 ‐

D.2 SYSTEM MODEL .......................................................................................................................... ‐ 86 ‐

D.3 TRAFFIC BETWEEN DAP AND AMI HEAD END.................................................................................... ‐ 88 ‐

D.4 NUMBER OF METERS IN A CDMA2000 1X OR HRPD SECTOR ............................................................ ‐ 96 ‐

D.5 CDMA2000 1X AND HRPD SYSTEM THROUGHPUT.......................................................................... ‐ 96 ‐

D.6 CONCLUSION .............................................................................................................................. ‐ 97 ‐

D.7 REFERENCES ............................................................................................................................... ‐ 97 ‐

ANNEX E IEEE 802.16/WIMAX NETWORK ..................................................................................... ‐ 99 ‐

E.1 REFERENCES.................................................................................................................................. ‐ 104 ‐
v

Revision History 

Revision 

Number 

Revision 

Date 

Revision 

By 

Summary of Changes 

.01 3/31/2010 Matt 

Gillmore 

Initial take on the outline, TOC, ,authors, 

definitions, acronyms, reference architecture 

.02 4/28/2010 David 

Cypher 

Added outline numbering for cross reference 

purposes, added text for 1, 3.3 and 5 

.03 5/3/2010 David 

Cypher 

Edits and additional material for 3.2, 5 and 6 

.04 5/4/2010 Nada 

Golmie 

Edits to section 5 

.05 7/28/2010 NIST & 

PAP2 Team 

Updated most of the document 

.06 9/30/10 NIST & 

PAP2 Team 

Updated most of the existing sections and 

provided material for empty sections. 

.06a 10/25/10 NIST Included material presented at St.Louis, MO 

meeting (and formatting) 

1.0 12/31/10 NIST Included material from call for comments on 

.06 
- 1 -

Preface 

Wireless technologies for technical and business communications have been available for 

over a century and are widely used for many popular applications. The use of wireless 

technologies in the power system is also not new. Its use for system monitoring, 

metering and data gathering goes back several decades. However, the advanced 

applications and widespread use now foreseen for the Smart grid require highly reliable, 

secure, well designed, and managed communication networks. 

The decision to apply wireless technologies for any given set of applications is a local 

decision that must take into account several important elements including both technical 

and business considerations. Smart grid applications requirements must be defined with 

enough specification to quantitatively define communications traffic loads, levels of 

performance, and quality of service. Applications requirements must be combined with 

as complete a set of management and security requirements for the life-cycle of the 

system. These requirements can then be used to assess the suitability of various wireless 

technologies to meet the requirements in the particular applications environment. 

This report is a draft of key tools and methods to assist Smart grid system designers in 

making informed decisions about existing and emerging wireless technologies. An 

initial set of quantified requirements have been brought together for advanced metering 

infrastructure (AMI) and initial Distribution Automation (DA) communications. These 

two areas present technological challenges due to their scope and scale. These systems 

will span widely diverse geographic areas and operating environments and population 

densities ranging from urban to rural. 

The wireless technologies presented here encompass different technologies that range in 

capabilities, cost, and ability to meet different requirements for advanced power systems 

applications. System designers are further assisted by the presentation of a set of wireless 

functionality and characteristics captured in a matrix for existing and emerging standards 

based wireless technologies. Details of the capabilities are presented in this report as a 

way for designers to initially sort through the available wireless technology options. 

To further assist decision making, the document presents a set of tools in the form of 

models that can be used for parametric analyses of the various wireless technologies. 

This document represents an initial set of guidelines to assist smart grid designers and 

developers in their independent evaluation of candidate wireless technologies. While 

wireless holds many promises for the future, it is not without limitations. In addition 

wireless technology continues to evolve. Priority Action Plan 2 fundamentally cuts 

across the entire landscape of the smart grid. Wireless is one of several communications 

options for the smart grid that must be approached with technical rigor to ensure 

communication systems investments are well suited to meet the needs of the Smart grid 

both today, as well as in the future. 

The scope and scale of wireless technology will represent a significant capital 

investment. In addition the Smart grid will be supporting a wide diversity of applications 
- 2 -

including several functions that represent critical infrastructure for the operation of the 

nation’s electric and energy services delivery systems. 

Feedback and critical review of this document are welcome. Individuals interested in 

directly participating in follow on work are encouraged to join in assisting with tasks 

defined within PAP 2 on the SGIP twiki page at 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP02Wireless. 

Authors 

Steve Barclay – ATIS 

Ron Cunningham – American Electric Power 

David Cypher – NIST 

Camillo Gentile – NIST 

Matthew Gillmore – Consumers Energy 

William (Bill) Godwin – Progress Energy 

Nada Golmie – NIST 

Doug Gray – WiMAX Forum 

David Griffith – NIST 

Joe Hughes - Electric Power Research Institute 

Jorjeta Jetcheva – Itron 

Farrokh Khatibi - Qualcomm 

Mark Klerer – Qualcomm 

Bruce Kraemer – Marvell 

Orlett W. Pearson – TIA TR-45.5 

Michael Souryal – NIST 
- 3 -

1 Overview of the Process 

The process by which this document was generated is based on the six tasks for Priority 

Action Plan 2 (PAP 2). 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP02Wireless 

Task 1: Segment the smart grid and wireless environments into a minimal set of 

categories for which individual wireless requirements can be identified. This was 

accomplished by the creation of a template (app_matrix_pap.xls) for input to application 

communication requirements. This template contained two main sheets: one for 

characterizing the user application and the other for characterizing the physical devices 

that would be used for the user applications. With this template as a basis, OpenSG1

submitted a subset of user application quantitative information (SG Network System 

Requirements Specification v4.0.xls). See section 3.4. 

Task 2: Develop Terminology and definitions. This was accomplished by combining the 

terms and definitions from the various input documents to other tasks of PAP 2, as well 

as using those from the base Smart grid documents (NIST IR 7628 Guidelines for 

Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, 

and High-Level Requirements). For Acronyms see 2.1 and definitions see 2.2. 

Task 3: Compile and communicate use cases and develop requirements for all smart grid 

domains in terms that all parties can understand. This task is in progress and has been 

partially completed for the submitted user applications (see 3.3) and the smart grid 

domains that are applicable to the user requirements. 

Task 4: Compile and communicate a list of capabilities, performance metrics, etc. in a 

way that all parties can understand. - Not quantifying any standard, just defining the set 

of metrics. This was accomplished by default with the submission for task 5. 

Task 5: Create an inventory of wireless standards and their associated characteristics 

(defined in task 4) for the environments identified in task 1. The Wireless Functionality 

and Characteristics Matrix for the identification of smart grid domain application 

(Consolidated_NIST_Wireless_Characteristics_Matrix-V5.xls.) excel spreadsheet 

captures a list of wireless standards and their associated characteristics. (See section 4) 

Task 6: Perform the mapping and conduct an evaluation of the wireless technologies 

based on the criteria and metrics developed in task 4. This is the subject of sections 5 – 6 

of this document ( Modeling and Evaluation Approach (5), Factors to Consider in 

Determining Performance (6)) and the Conclusions (7). 

 

1

 The full description of the procedures used in this document requires the identification of certain 

commercial products and their suppliers. The inclusion of such information should in no way be construed 

as indicating that such products or suppliers are endorsed by NIST or are recommended by NIST or that 

they are necessarily the best materials, instruments, software or suppliers for the purposes described. 
- 4 -

2 Acronyms and Definitions 

The acronyms and definitions provided are used in this document and in some of its 

referenced supporting documentation. 

2.1 Acronyms 

3G Third Generation 

AC Alternating Current 

ACK Acknowledgement 

AICPA American Institute of Certified Public Accountants2

AMI Advanced Metering Infrastructure 

AMS Asset Management System 

ARQ Automatic Repeat-reQuest 

ASAP-SG Advanced Security Acceleration Project-Smart Grid 

AWGN Additive White Gaussian Noise 

B2B Business to Business 

BAN Business Area Network 

BER Bit Error Rate 

BGAN Broadband Global Area Network 

BPSK Binary Phase Shift Keying 

CIM Common Information Model 

CIP Critical Infrastructure Protection 

CPP Critical Peak Pricing 

CRC Cyclic Redundancy Check 

CSWG Cyber Security Working Group 

DA Distribution Automation 

DAC Distributed Application Controller 

DAP Data Aggregation Point 

DCF Distributed Coordination Function 

DER Distributed Energy Resources 

DHS Department of Homeland Security3

DIFS Distributed InterFrame Space 

DMS Distribution Management System 

DNP Distributed Network Protocol 

DO Downlink Only 

DOE Department of Energy 

DOMA Distribution Operations Model and Analysis 

DR Demand Response 

DRMS Distribution Resource Management System 

DSDR Distribution Systems Demand Response 

 

2

 AICPA, 1211 Avenue of the Americas, New York, NY 10036; www.aicpa.org 

3

 Department of Homeland Security – www.dhs.gov 
- 5 -

DSM Demand Side Management 

DVB Digital Video Broadcast 

EDGE Enhanced Data Rates for GSM Evolution 

EIFS Extended InterFrame Space 

EIRP Effective Isotropic Radiated Power 

EMS Energy Management System 

EPRI Electric Power Research Institute4

ES Electric Storage 

ESB Enterprise Service Bus 

ESI Energy Services Interface 

ET Electric Transportation 

EUMD End Use Measurement Device 

EV/PHEV Electric Vehicle/Plug-in Hybrid Electric Vehicles 

EVSE Electric Vehicle Service Element 

FAN Field Area Network 

FDD Frequency Division Duplexing 

FEP Front End Processor 

FER Frame Error Rate 

FERC Federal Energy Regulatory Commission5

FIPS Federal Information Processing Standard Document 

FLIR Fault Location, Isolation, Restoration 

G&T Generations and Transmission 

GAPP Generally Accepted Privacy Principles 

GFSK Gaussian Frequency-Shift Keying 

GIS Geographic Information System 

GL General Ledger 

GMR Geo Mobile Radio 

GMSK Gaussian Minimum Shift Keying 

GPRS General Packet Radio Service 

HAN Home Area Network 

HARQ Hybrid Automatic Repeat reQuest 

HMI Human-Machine Interface 

HRPD High Rate Packet Data 

HSPA+ Evolved High-Speed Packet Access 

HVAC Heating, Ventilating, and Air Conditioning 

I2G Industry to Grid 

IEC International Electrotechnical Commission6

IED Intelligent Electronic Device 

IETF Internet Engineering Task Force 

 

4

 Electric Power Research Institute, Inc. (EPRI) 3420 Hillview Avenue, Palo Alto, California 94304 5

 Federal Energy Regulatory Commission - www.ferc.gov 

6

 International Electrotechnical Commission – www.iec.ch 
- 6 -

IHD In-Home Display / In-Home Device 

IKB Interoperability Knowledge Base 

IPoS Internet Protocol over Satellite 

ISA International Society of Automation7

ISO 

Independent System Operator 

International Organization for Standardization 

IT Information Technology 

LAN Local Area Network 

LMS Load Management System 

LMS/DRMS Load Management System/ Distribution Resource 

Management System 

LTE Long Term Evolution 

LV Low Voltage 

MAC Medium Access Control 

MDMS Meter Data Management System 

MFR Multi-Feeder Reconnection 

MIMO Multiple-Input / Multiple-Output 

MSW Meter Service Switch 

MV Medium Voltage 

NAN Neighborhood Area Network 

NERC North American Electric Reliability Corporation8

NIPP National Infrastructure Protection Plan 

NISTIR NIST Interagency Report 

NLOS Non Line of Sight 

NMS Network Management System 

ODW Operational Data Warehouse 

OFDM Orthogonal Frequency Division Multiplexing 

OMS Outage Management System 

OSI Open Systems Interconnection 

OWASP Open Web Application Security Project 

PAP Priority Action Plan 

PCT Programmable Communicating Thermostat 

PEV Plug-In Electric Vehicle 

PGF Probability Generating Function 

PHEV Plug-in Hybrid Electric Vehicle 

PHY Physical Layer 

PI Process Information 

PIA Privacy Impact Assessment 

PII Personally Identifying Information 

QAM Quadrature Amplitude Modulation 

 

7

 ISA, 67 Alexander Drive, Research Triangle Park, NC 27709 USA - www.isa.org 

8

 www.nerc.com 
- 7 -

QoS Quality of Service 

QPSK Quadrature Phase Shift Keying 

R&D Research and Development 

REP Retail Electric Provider 

RF Radio Frequency 

RFC Request for Comments 

RSM Regenerative Satellite Mesh 

RSSI Received Signal Strength Indication 

RTO Regional Transmission Operator 

RTP Real Time Pricing 

RTU Remote Terminal Unit 

SCADA Supervisory Control and Data Acquisition 

SCE Southern California Edison9

SDO Standards Development Organization 

SGIP Smart Grid Interoperability Panel 

SGIP-CSWG SGIP – Cyber Security Working Group 

SIFS Short InterFrame Space 

SIM Subscriber Identity Module 

SIMO Single-input / Multiple-output 

SINR Signal to Interference plus Noise Ratio 

SISO Single-input / Single-output 

SM Smart Meter 

SNR Signal to Noise Ratio 

SP Special Publication 

SSP Sector-Specific Plans 

T/FLA Three/Four Letter Acronym 

TDD Time Division Duplexing 

TOU Time Of Use 

UMTS Universal Mobile Telecommunications System 

VAR Volt-Amperes Reactive 

VVWS Volt-VAR-Watt System 

WAMS Wide-Area Measurement System 

WAN Wide Area Network 

WASA Wide Area Situational Awareness 

WLAN Wireless Local Area Network 

WMS Work Management System 

WWAN Wireless Wide Area Network 

 

9

 www.sce.com 
- 8 -

2.2 Definitions10

Actor A generic name for devices, systems, or programs that make decisions 

and exchange information necessary for performing applications: smart 

meters, solar generators, and control systems represent examples of 

devices and systems. 

Anonymize A process of transformation or elimination of personally identifiable 

information (PII) for purposes of sharing data 

Aggregation Practice of summarizing certain data and presenting it as a total without 

any personally identifiable information (PII) identifiers 

Aggregator SEE FERC OPERATION MODEL 

Applications Tasks performed by one or more actors within a domain. 

Asset Management 

System 

A system(s) of record for assets managed in the smart grid. 

management context may change (e.g. financial, network). 

Capacitor Bank This is a device used to add capacitance as needed at strategic points in 

a distribution grid to better control and manage volt-amperes reactives 

(VARs) and thus the power factor and they will also affect voltage 

levels. 

Common Information 

Model 

A structured set of definitions that allows different smart grid domain 

representatives to communicate important concepts and exchange 

information easily and effectively. 

Common Web Portal Web interface for regional transmission operator, customers, retail 

electric providers and transmission distribution service provider to 

function as a clearing house for energy information. Commonly used in 

deregulated markets. 

Data Collector See Substation controller 

Data Aggregation 

Point 

This device is a logical actor that represents a transition in most 

advanced metering infrastructure (AMI) networks between wide area 

networks and neighborhood area networks. (e.g. collector, cell relay, 

base station, access point, etc.) 

De-identify A form of anonymization that does not attempt to control the data once 

it has had personally identifiable information (PII) identifiers removed, 

so it is at risk of re-identification. 

Demand Side 

Management 

A system that co-ordinates demand response / load shedding messages 

indirectly to devices (e.g., set point adjustment) 

Distribution 

Management System 

A system that monitors, manages and controls the electric distribution 

system. 

Distribution Systems 

Demand Response 

A system used to reduce load during peak demand. Strictly used for 

distribution systems only. 

 

10 The definitions are specific to this document’s context and intended usage. Even though other Standards 

Development Organizations have their own copyrighted definitions for some of these same terms, a 

specific effort to harmonize or obtain permission to reuse copyrighted definitions was not included in scope 

of this work. 
- 9 -

Electric Vehicle (EV) 

/Plug-in Hybrid 

Electric Vehicles 

(PHEV) 

Cars or other vehicles that draw electricity from batteries to power an 

electric motor. PHEVs also contain an internal combustion engine. 

Energy Services 

Interface (ESI) 

Provides the communications interface to the utility. It provides security 

and, often, coordination functions that enable secure interactions 

between relevant home area network devices and the utility. Permits 

applications such as remote load control, monitoring and control of 

distributed generation, in-home display of customer usage, reading of 

non-energy meters, and integration with building management systems. 

Also provides auditing/logging functions that record transactions to and 

from home area networking devices. 

Enterprise Service 

Bus (ESB) 

The enterprise service bus consists of a software architecture used to 

construct integration services for complex event-driven and standardsbased messaging to exchange meter or grid data. The enterprise service 

bus (ESB) is not limited to a specific tool set rather it is a defined set of 

integration services. 

Fault Detector A device used to sense a fault condition and can be used to provide an 

indication of the fault. 

Field Force Employee working in the service territory that may be working with 

smart grid devices. 

Generally Accepted 

Privacy Principles 

Privacy principles and criteria developed and updated by the American 

Institute of Certified Public Accountants (AICPA) and Canadian 

Institute of Chartered Accountants to assist organizations in the design 

and implementation of sound privacy practices and policies. 

Goodput Goodput is the application level throughput, i.e. the number of useful 

bits per unit of time forwarded by the network from a certain source 

address to a certain destination, excluding protocol overhead, and 

excluding retransmitted data packets. 

Header The portion of a packet, before the data field that typically contains 

source and destination addresses, control fields and error check fields. 

Home Area Network A network of energy management devices, digital consumer electronics, 

signal-controlled or enabled appliances, and applications within a home 

environment that is on the home side of the electric meter. 

Intelligent Fault 

Detector 

A device that can sense a fault and can provide more detailed 

information on the nature of the fault, such as capturing an 

oscillography trace. 

ISO/IEC27001 Provides an auditable international standard that specifies the 

requirements for establishing, implementing, operating, monitoring, 

reviewing, maintaining and improving a documented Information 

Security Management System within the context of the organization's 

overall business risks. It uses a process approach for protection of 

critical information 

Last Gasp Refers to the capability of a device to emit one last message when it 

loses power. Concept of an energized device within the smart grid 

detecting power loss and sending a broadcast message of the event 
- 10 -

Latency As used in the OpenSG – SG Communications SG Network TF’s 

Requirement Table, is the summation of actor (including network 

nodes) processing time and network transport time measured from an 

actor sending or forwarding a payload to an actor, and that receiving 

actor processing (consuming) the payload. This “latency” is not the 

classic round trip “response time”, or the same as “network link 

latency.” 

Link Budget Accounts for the attenuation of the transmitted signal due to antenna 

gains, propagation, and miscellaneous losses. 

Load Management 

System 

A system that controls load by sending messages directly to device (e.g. 

On/Off) 

Low Voltage Sensor A device used to measure and report electrical properties (such as 

voltage, current, phase angle or power factor, etc.) at a low voltage 

customer delivery point. 

Medium Voltage 

Sensor 

A device used to measure and report electrical properties (such as 

voltage, current, phase angle or power factor, etc.) on a medium voltage 

distribution line. 

Motorized Switch A device under remote control that can be used to open or close a circuit 

Neighborhood Area 

Network 

A network comprised of all communicating components within a 

distribution domain. 

Network 

Management System 

A system that manages fault, configuration, auditing/accounting, 

performance and security of the communication. This system is 

exclusive from the electrical network. 

Outage Management 

System 

A system that receives out power system outage notifications and 

correlates where the power outage occurred 

Packet A formatted unit of data sent across a network. 

Personal Information 

Information that reveals details, either explicitly or implicitly, about a 

specific individual’s household dwelling or other type of premises. This 

is expanded beyond the normal "individual" component because there 

are serious privacy impacts for all individuals living in one dwelling or 

premise. This can include items such as energy use patterns or other 

types of activities. The pattern can become unique to a household or 

premises just as a fingerprint or DNA is unique to an individual. 

Phase Measuring 

Unit 

A device capable of measuring the phase of the voltage or current 

waveform relative to a reference. 

Power Factor A dimensionless quantity that relates to efficiency of the electrical 

delivery system for delivering real power to the load. Numerically, it is 

the cosine of the phase angle between the voltage and current 

waveforms. The closer the power factor is to unity the better the 

inductive and capacitive elements of the circuit are balanced and the 

more efficient the system is for delivering real power to the load(s). 

Privacy Impact 

Assessment 

A process used to evaluate the possible privacy risks to personal 

information, in all forms, collected, transmitted, shared, stored, disposed 

of, and accessed in any other way, along with the mitigation of those 

risks at the beginning of and throughout the life cycle of the associated 

process, program or system. 
- 11 -

Programmable 

Communicating 

Thermostat 

A device within the premise that has communication capabilities and 

controls heating, ventilation and cooling systems. 

Rate Adaptation The mechanism by which a modem adjusts its modulation scheme, 

encoding and/or speed in order to reliably transfer data across channel 

exhibiting different signal-to-noise ratio (SNR) characteristics. 

Recloser (non-Team) A device used to sense fault conditions on a distribution line and trip 

open to provide protection. It is typically programmed to automatically 

close (re-close) after a period of time to test if the fault has cleared. 

After several attempts of reclosing it can be programmed to trip open 

and stop trying to reclose until reset either locally or under remote 

control. 

Recloser (Team) A device that can sense fault conditions on a distribution line and to 

communicate with other related reclosers (the team) to sectionalize the 

fault and provide a coordinated open/close arrangement to minimize the 

effect of the fault. 

Regional 

Transmission 

Operator 

An organization that is established with the purpose of promoting 

efficiency and reliability in the operation and planning of the electric 

transmission grid and ensuring non-discrimination in the provision of 

electric transmission services based on the following 

required/demonstrable characteristics and functions. 

Remote Terminal 

Unit 

Aggregator of multiple serialized devices to a common communications 

interface 

Smart Meter Term applied to a 2-Way Meter (meter metrology plus a network 

interface component) with included energy services interface (ESI) in 

the meter component 

Sub Meter Premise based meter (e.g., used for Distributed Energy Resources and 

PHEV), which permits additional metering capabilities subordinate to a 

main meter. 

Substation Controller Distributed processing device that has supervisory control or 

coordinates information exchanges from devices within a substation 

from a head end system. 

Throughput The number of bits (regardless of purpose) moving over a 

communications link per unit of time. Throughput is most commonly 

expressed in bits per second. 

Transformer (MV-toLV) A standard point of delivery transformer. In the smart grid context it is 

assumed there will be a need to measure some electrical or physical 

characteristics of this transformer such as voltage (high and/or low side) 

current, MV load, temperature, etc. 

Use Case A systems engineering tool for defining a system’s behavior from the 

perspective of users. In effect, a use case is a story told in structure and 

detailed steps—scenarios for specifying required usages of a system, 

including how a component, subsystem, or system should respond to a 

request that originates elsewhere. 
- 12 -

Voltage Regulator This device is in effect an adjustable ratio transformer positioned at 

strategic points in a distribution grid and is utilized to better manage and 

control the voltage as it changes along the distribution feeder. 

Volt-Amperes 

Reactive; 

In an alternating current (AC) power system the voltage and current 

measured at a point along the delivery system will often be out of phase 

with each other as a result the combined effects of the resistive and 

reactive (i.e. the capacitance and inductive) characteristics of the 

delivery system components and the load. The phase angle difference at 

a point along the delivery system is an indication of how well the 

inductive and capacitive effects are balanced at that point. The real 

power passing that point is the product of the magnitude of the voltage 

and current and the cosine of the angle between the two. The VAR 

parameter is the product of the magnitude of the voltage and current and 

the sine of the angle between the two. The magnitude of the VAR 

parameter is an indication of the phase imbalance between the voltage 

and current waveforms. 

Web Portal Interface between customers and their smart grid service provider (e.g., 

utility or third party or both). 
- 13 -

3 Smart Grid Conceptual Model and Business Functional Requirements 

This section provides an overview of the primary sets of information that UCAiug – 

OpenSG – SG Communications – SG Network Task Force (SG Network TF), prepared to 

address task 3 of PAP 2, plus an explanation of how this information is intended to be 

interpreted and an example of how to consume the information as an input into other 

analysis tools (e.g. network traffic modeling). 

3.1 Smart Grid Conceptual Reference Diagrams 

SG Network TF expanded upon the smart grid conceptual reference diagram that was 

introduced in NIST Special Publication 1108 - NIST Framework and Roadmap for Smart 

Grid Interoperability Standards, Release 1.0 and other reference diagrams included in 

NISTIR 7628 - Guidelines for Smart Grid Cyber Security. The smart grid conceptual 

reference diagram is included below, along with two views of SG Network TF’s 

conceptual reference diagrams, one without and one with cross domain data flows. 

Alternative (optional) interfaces between actors and communication paths amongst actors 

are also contained in the diagrams. These reference diagrams are further explained in 

smart grid use case documentation and detailed business functional and volumetric 

requirements in the sections that follow. In these figures the customer domain is focused 

on the residential customer. 

Figure 1 - Smart grid conceptual reference diagram 
- 14 -

Figure 2 - OpenSG SG Network TF smart grid conceptual reference diagram 
- 15 -

Figure 3 - OpenSG_SG Network TF smart grid conceptual reference diagram with cross 

domain data flows 
- 16 -

The latest set of SG Network TF reference diagrams are located at 

 http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Latest_Release_Deliv

erables/Diagrams/ 

3.2 List of Actors 

Table 1 maps the actors included in the SG Network TF smart grid conceptual reference 

diagram (Figure 3) and the NIST smart grid conceptual reference diagram (Figure 1). 

The SG Network TF high level list of actors are further qualified by domain and subdomain as used in documenting the smart grid business functional and volumetric 

requirements. 

Table 1: Mapping of actors to domain names 

SG Network TF reference 

diagram descriptor (actor) 

SG Network TF 

reference diagram 

domain name 

Related NIST diagram 

descriptor (actor) 

Field Tools Customer / Distribution 

Generators Bulk Generation Generators 

Market Services Interface Bulk Generation Market Services Interface 

Plant Control Systems Bulk Generation Plant Control Systems 

 Customer Electric Storage 

Customer Energy Management 

System (EMS) 

Customer Customer EMS 

DERs (Solar, Wind, premise 

generation sources) 

Customer Distributed Generation 

ESI (3rd party) Customer Energy Services Interface 

ESI (Utility) Customer Energy Services Interface 

ESI (In meter) Customer Energy Services Interface 

Electric Vehicle Service 

Element (EVSE) / End Use 

Measurement Device (EUMD) 

Customer Customer Equipment 

Heating, Ventilating, and Air 

Conditioning (HVAC) 

Customer Customer Equipment 

IHD (In Home Device) Customer Customer Equipment 

Load Control Device Customer Customer Equipment 

PCT Customer Thermostat 

PHEV Customer Electric Vehicle 

Phone/Email/Text/Web Customer Customer Equipment 

Smart Appliances Customer Appliances 

Smart Meter Customer Meter 

Sub-Meter Customer Customer Equipment 

Two Way Meter - Electric Customer Meter 

Two Way Meter - Gas Customer Meter 

Two Way Meter - Water Customer Meter 

Capacitor Bank Distribution Field Device 

Circuit Breaker Distribution Field Device 
- 17 -

SG Network TF reference 

diagram descriptor (actor) 

SG Network TF 

reference diagram 

domain name 

Related NIST diagram 

descriptor (actor) 

Recloser Distribution Field Device 

Distributed Customer 

Generation 

Distribution Distribution Generation 

Distributed Customer Storage Distribution Storage System 

Sectionalizer Distribution Field Device 

Switch Distribution Field Device 

Voltage Regulator Distribution Field Device 

Distributed Application 

Controller (DAC) 

Distribution / 

Transmission 

Substation Controller 

Distributed Generation Distribution / 

Transmission 

Distributed Generation 

Distributed Storage Distribution / 

Transmission 

Storage System 

Field Area Network (FAN) 

Gateway 

Distribution / 

Transmission 

Field Sensors Distribution / 

Transmission 

Field Device 

Remote Terminal Unit (RTU) Distribution / 

Transmission 

Data Collector 

Substation Devices Distribution / 

Transmission 

Substation Device 

Energy Market Clearinghouse Markets Energy Market 

Clearinghouse 

Retailer/Wholesaler Markets Aggregator/Retail Energy 

Provider 

Regional Transmission 

Operator (RTO)/ Independent 

System Operator (ISO) 

Markets RTO/ISO 

Aggregator Markets / Service 

Providers 

Aggregator 

 Operations Asset Mgmt 

 Operations WAMS 

AMI Head end Operations Metering System 

Analytic Database Operations 

Distributed SCADA Front End 

Processor (FEP) 

Operations Distributed SCADA 

Demand Side Management 

(DSM) 

Operations Demand Response 

EMS Operations Utility EMS 

Event/OMS Operations 

Geographic Information 

System (GIS) 

Operations 
- 18 -

SG Network TF reference 

diagram descriptor (actor) 

SG Network TF 

reference diagram 

domain name 

Related NIST diagram 

descriptor (actor) 

General Ledger (GL) / 

Accounts Payable / Receivable 

Operations 

Load Management System 

(LMS) 

Operations 

MDMS Operations MDMS 

NMS Operations 

RTO SCADA Operations RTO SCADA 

Transmission SCADA FEP Operations Transmission SCADA FEP 

Utility Distribution 

Management System (DMS) 

Operations DMS 

Utility EMS Operations EMS 

Work Management System Operations 

Bill Payment 

Organizations/Banks 

Service Provider Other 

Common Web PortalJurisdictional Service Provider Other 

Home/Building Manager Service Provider Home/Building Manager 

Internet/Extranet Gateway Service Provider 

ODW Service Provider 

REP CIS/Billing Service Provider Retail Energy Providers 

Billing 

REP CIS/Billing Service Provider Retail Energy Providers 

CIS 

Utility CIS/Billing Service Provider Utility CIS 

Utility CIS/Billing Service Provider Utility Billing 

Web Portal Service Provider 

3.3 Smart Grid Use Cases 

From the Interoperability Knowledge Base (IKB), 

 http://collaborate.nist.gov/twikisggrid/bin/view/SmartGrid/InteroperabilityKnowledgeBase#Use_Cases 

use cases come in many shapes and sizes. With respect to the IKB, fairly comprehensive 

use case descriptions are used to expose functional requirements for applications of the 

smart grid. In order to provide this depth, these use cases contain the following 

information: 

• Narrative: a description in prose of the application represented including all 

important details and participants described in the context of their 

activities 

• Actors: identification of all the persons, devices, subsystems, software 

applications that collaborate to make the use case work 
- 19 -

• Information Objects: defines the specific aggregates of information exchanged 

between Actors to implement the use case 

• Activities/Services: description of the activities and services this use case relies 

on or implements 

• Contracts/Regulations: what contractual or regulatory constraints govern 

this use case 

• Steps: the step by step sequence of activities and messaging exchanges 

required to implement the use case 

For use cases following this description, see: 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/IKBUseCases 

SG Network TF performed an exercise to research and to identify all pertinent use cases 

(namely concerning AMI and DA) that involve network communication to help satisfy 

the OpenSG input requirements into the NIST PAP 2 tasks. Use cases from several 

sources (Southern California Edison, Grid Wise Architecture Console, Electric Power 

Research Institute and others) were researched. Table 2 summarizes the use cases SG 

Network TF has currently in scope for this work effort. 

Table 2: OpenSG SG Network TF use cases and status 

Smart grid use case11 – based on release V4.0.xls 

Customer Information / Messaging 

Demand Response – Direct Load Control (DR-DLC) 

Distributed Storage – Dispatch ; Island 

Distribution Systems Demand Response (DSDR) - 

Centralized Control 

Fault Clear Isolation Reconfigure (FCIR) – Distributed DAC 

– Substations; DMS; Regional Distributed DAC 

Field Distribution Automation Maintenance / Support – 

Centralized Control 

Meter Events 

Meter Read 

Outage Restoration Management 

PHEV 

Premise Network Administration 

Pre-Pay Metering 

Service Switch 

System Updates (Firmware / Program Update) 

Volt/VAR Management – Centralized Control 

Smart grid use case12 – potential for releases post V4.0.xls 

Configuration Management 

 

11 For several of the payloads that might be classified as associated to Accounting (Auditing), Fault 

Management, those payloads are included across several of the other listed use cases. 

12 For the current status of what use cases and application payloads have been documented, see the latest 

Requirement Table. 
- 20 -

Distributed Generation 

Field Force Tools 

Performance Management 

Pricing: 

Time of Use (TOU) / 

Real Time Pricing (RTP)/ 

Critical Peak Pricing (CPP) 

Security Management 

Transmission automation support 

Documenting and describing the in-scope smart grid use cases by SG Network TF is 

contained in the System Requirements Specification (SRS) document. The SG Network 

TF objective for the SRS is to provide sufficient information for the reader to understand 

the overall business requirements for a smart grid implementation and to summarize the 

business volumetric requirements at a use case payload level as focused on the 

communications networking requirements, without documenting the use cases to the full 

level of documentation detail as described by the IKB. 

The scope of the SRS focuses on explaining: the objectives, approach to documenting the 

use cases; inclusion of summarization of the network and volumetric requirements and 

necessary definition of terms; and guidance upon how to interpret and consume the 

business functional and volumetric requirements. The latest released version of the SRS 

is located at 

 http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Latest_Release_Deliv

erables/ 

with a file name syntax of “SG Network System Requirements Specification vN.doc”, 

where N represents the version number. 

3.4 Smart Grid Business Functional and Volumetric Requirements 

There are many smart grid user applications (use cases) collections of documentation. 

Many have text describing the user applications (see IKB), but few contain quantitative 

business functional and volumetric requirements, which are necessary to design 

communications protocols, to assess, or to plan communication networks. Documenting 

the detailed actor to actor payloads and volumetric requirements allows for: 

• aggregation of the details to various levels (e.g., specific interface or network link, 

a specific network or actor and have the supporting details versus making 

assumptions about those details) and 

• allows the consumer of the Requirements Table to scope and customize the smart 

grid deployment specific to their needs (e.g., which set of use cases, payloads, 

actors, communication path deployments). 

OpenSG -SG Communications - SG Network TF took on the task to document the smart 

grid business functional and volumetric requirements for input into the NIST PAP 2 tasks 

and to help fill this requirements documentation void. The current SG-Network business 

functional and volumetric requirements are located at 
- 21 -

 http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Latest_Release_Deliv

erables/ 

with a file name syntax of “SG Network System Requirements Specification vN.R.xls”, 

where N represents the version number and R represents the revision number. This 

spreadsheet is referred to below as the Requirements Table. (as of this writing v4.0.xls) 

Instructions for how to document the business functional and volumetric requirements 

were prepared for the requirement authors, but also can be used by the consumer of the 

Requirements Table to better understand what is and is not included, and how to interpret 

the requirements data. The requirements documentation instructions are located at: 

 http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Latest_Release_Deliv

erables/ 

with a file name syntax of “rqmts-documentation-instructions-rN.R.doc”, where N 

represents the version number and R represents the revision number. 

The Requirements Table consists of several major sets of information for each use case: 

For example: 

• Business functional requirement statements are documented as individual 

information flows (e.g., specific application payload requirement sets). This is 

comparable to what many use case tools capture as information flows and/or 

illustrated in sequence diagram flows. 

• To the baseline business requirements are added the: 

o volumetric attributes (the when, how often, with what availability, latency, 

application payload size). Take note that the SG Network TF 

Requirements Table definition for some terms (e.g. latency) is different 

than the classic “network link latency” usage. Please refer to the SG 

Network TF Requirements Documentation Instructions or section 2.2 for 

the detailed definitions for clarification. 

o an assignment of the security confidentiality, integrity, and availability 

low-medium-high risk values for that application payload. 

• Payload requirement sets are grouped by rows in the table that contains all the 

detailed actor to actor passing of the same application payloads in a sequence that 

follows the main data flow from that payload’s originating actor to primary 

consuming actor(s) across possible multiple communication paths that a 

deployment might use. The payload requirements’ sets will always contain a 

parent (main) actor to actor row and most will contain child (detailed) rows for 

that requirement set. 

• Payload communication path (information or data flow) alternatives that a given 

smart grid deployment might use. 

The process of requirements gathering and documentation has been evolutionary in 

nature as various combinations of additional attributes are documented; use cases added; 

payload requirement sets added; and alternative communication paths documented. The 

SG Network TF has defined over 1400 (as of release v4.0.xls; the basis of this work) 

functional and volumetric detailed requirements rows in the Requirements Table 

representing 165 different payloads for 18 use cases. 
- 22 -

SG Network TF intends to continue this incremental version release approach to manage 

the scope and focus on documenting the requirements for specific use cases and payloads, 

yet giving consumers of this information something to work with and provide feedback 

for consideration in the next incremental releases. It is expected that the number of 

requirements rows in the Requirements Table will more than double if not triple from the 

current size when completed. 

To effectively use the business functional and volumetric requirements, the consumer of 

the Requirements Table must: 

• select which use cases and payloads are to be included 

• select which communication path scenario (alternative) is to be used for each of 

the main information/data flows from originating actor to target consuming actor 

• specify the size (quantity and type of devices) of the smart grid deployment 

• perform other tweaks to the payload volumetrics to match that smart grid 

deployment’s needs over time. 

The current Requirements Table (v4.0.xls) as a spreadsheet is not very conducive to 

performing these tasks. SG Network TF is building a database that is synchronized with 

the latest release of the Requirements Table (spreadsheet). SG Network TF will be 

adding capabilities to the database to: 

• solicit answers to the questions summarized above; 

• query the database; and 

• format and aggregate the query results for either reporting or exporting into other 

tools. 

The current SG Network TF Requirements database and related user documentation are 

located at 

 http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Latest_Release_Deliv

erables/Rqmts_Database/ 

Note : SG-Network_Rqmts_Database_r4.0 is the version available for the database as of 

this writing. 

3.5 Use of Smart Grid User Applications’ Quantitative Requirements for PAP 2 Tasks 

Release 4.0 (June 15, 2010) of the SG Network TF Requirements Table contains 

numerous use cases, payloads (applications), communication path options, and associated 

volumetric requirements data sufficient for a variety of smart grid deployment scenarios 

as input to PAP 2. As SG Network TF continues to provide incremental Requirement 

Table releases and eventually completes that effort, that availability of quantified 

business functional and volumetric data will provide PAP 2 and the reader of this 

document with a more complete set of smart grid business functional and volumetric 

requirement data for assessment of any given network standard and technology against. 

This is not a do it once and it is completed type of task. 
- 23 -

3.6 Adaptation of SG Network TF’s Requirements Table Data for Use in Network 

Modeling Tools 

When examining the detailed records of the Requirements Table and as noted in section 

3.4, there are several decisions and selections the consumer of the Requirements Table 

must make. This section identifies a method for making most of those decisions and 

selections, and how to adapt the detailed quantified requirements into a form that can be 

loaded into the wireless model in section 5.2 or into any other traffic modeling or 

assessment tool. 

Method: 

Step 1 - Determine which use cases (applications) to use. 

Step 2 - Select which actor to actor interface is to be investigated: 

a) which communication path 

b) which network link(s). 

Step 3 - Identify the applications’ events (payloads) that are to be used. 

Step 4 - Select one value for metrics where ranges are provided. 

Step 5 - Assume (and document) values for missing information. 

Step 6 - Select which type of data analysis method is to be used: 

a) aggregation of data volumetrics based on values per a specified time 

period for input into a static system model 

b) simulation of multiple discrete transactions (payloads) retaining each 

events unique data volumetrics and profiles 

Step 7 - Finalize the data preparation tasks based on the selections and 

assumptions from steps 1-6. 

The remainder of this section provides an example of using the steps above on the 

Requirements Table (release v4.0.xls). As the seven steps are exercised, a very limited 

and focused amount of requirements from the Requirements Table will be selected for 

analysis. The user of the Requirements Table and this method needs to perform the steps 

as driven by the specific objectives and scope of their assessment. 

Example use of the method 

Step 1 - Determine which use cases (applications) to use 

The spreadsheet filter feature can be used on the “Use Case Ref” column to identify and 

select which uses cases are of interest. For this example exercising of the steps above, 

two applications (meter reading and service switch) of the available use cases will be 

used. 

Step 2 - Select which actor to actor interface is to be investigated: 

a) which communication path 

Using a combination of “pivot tables or data pilots” and additional queries of the 

Requirements Table for the two selected applications and reviewing the distinct two-way 

communications between the “From” and “To” actors indicates that there are 41 unique 

actor to actor pairings. 
- 24 -

Let us focus on the Data Aggregation Point (DAP) from/to 2-Way Meter actor to actor 

pairing. 

b) which network link 

The SG Network TF conceptual reference diagrams (Figure 2 and Figure 3), indicates 

that there are three network interfaces “MeA”, “MgA”, :MwA” between the DAP and the 

2-Way Meter13. Note the term, smart meter, includes both the 2-Way Meter and the ESI 

– in meter components. There are two independent data flows identified between the 

DAP to the electric Smart Meter: “1D’” which is intended to deal with that traffic 

terminating with the meter metrology, and “5Ba” which is terminating with the ESI 

module in meters that have ESI modules, plus “1Dg” and “1Dw” for the other two 2-Way 

Meters. Without getting too technology specific, many technologies for communicating 

with 2-way meters use one network interface module that “MeA” interfaces to. 

Consequently, both the “1D” and “5Ba” data flows would traverse across the “MeA” 

interface. 

The vast majority of the communication interfaces included in the Requirements Table 

are documented as data flows, which are further decomposed to specific network actor to 

actor or actor to network or network to network links. If the modeling effort is intended 

to focus on ALL traffic that passes across a network link (e.g. “MeA), for a specific smart 

grid deployment, then all business requirements in the Requirements Table that have data 

flows that traverse this interface for the specific selection of use cases, payloads, and 

communication paths (deployment topologies), must be used in selecting the 

requirements data for analysis. 

For this simple example, let us focus on just the payloads that use the 2-Way Meter –

Electric actor metrology to/from the DAP (i.e., “1D”) data flow and NOT the traffic with 

the ESI – In meter component via “5Ba” or the gas “1Dg” or water “1Dw” data flows. 

Step 3 – Identify the applications’ events (payloads) that are to be used 

Using the Requirements Table (v4.0.xls) filter capabilities against the previous two 

application filters and applying the following two column filters: 

• “Data Flow Ref” contains “1D” 

• “Data Flow from Actor” equals “DAP” 

would include those events coming from three actors: 

 CIS/Billing – Utility 

 IHD if the communications option via ESI –Utility actor “1D + 5Bb + 16Ab” 

is selected 

 Customer EMS if the communications option – ESI – Utility actor “1D + 5Bb 

+ 16Cb” is selected. 

 

13 Smart grid architectures include the use of AMI technologies which specifies telecommunication 

capabilities with the meters as being 2-way. Consequently this excludes 1-way meters and meters without 

any remote communication capabilities. If the user of the Requirements Table wants to include 1-way 

meters into their analysis, then the requirements specific to those 1-way meters will need to be created by 

the user specific to their needs. 
- 25 -

For this example let us restrict the events to those only coming from the CIS/Billing – 

Utility actor, which results in five events present in the DAP to 2-Way Meter – Electric 

metrology direction 

• two for the meter reading application, 

o multiple interval meter reading request and 

o on-demand meter read request. 

• three for service switch application 

o cancel service switch operate request, 

o service switch operate request, and 

o service switch state request. 

After resetting the previous filters and applying the following two column filters: 

• “Data Flow Ref” contains “1D” 

• “Data Flow to Actor” equals “DAP” 

would include those events going to three actors: 

 CIS/Billing – Utility 

 IHD if the communications option via ESI –Utility actor “16Ab + 5Bb + 1D” 

is selected 

 Cust. EMS if the communications option – ESI – Utility actor “16Cb + 5Bb + 

1D” is selected . 

For this example let us restrict the events to those only going to the CIS/Billing – Utility 

actor, which results in eight events present in the 2-Way Meter –Electric metrology to 

DAP direction 

• four for meter reading application, 

o multiple interval meter read data 

 Commercial / industrial electric meters, 

 Residential electric smart meters. 

o on-demand read request application errors, and 

o on-demand meter read data. 

• four for service switch application 

o send service switch operate acknowledgment, 

o send service switch operate failure, 

o send metrology information after a successful service switch operate, and 

o send service switch state data. 

Step 4 – Select one value for metrics where ranges are provided. 

Use the information from these events (and perhaps others) to calculate the individual 

contribution of each event in terms of its frequency (Requirements Table: “How Often” 

values) and its application payload size. Please note that the Requirements Table “Daily 

Clock Periods” values directly impacts the frequency calculations when the frequency is 

taken down from say a daily value to an hourly value for specific time blocks in the day, 

refer to the hourly columns in Table 3 and Table 4 below. Also if the hour of 

consideration is shifted to an evening hour, the values may or may not change depending 

upon the “Daily Clock Periods” for that payload (event). 
- 26 -

These metrics have either ranges of values or scalar values. An example of a range of 

values is the multiple interval meter read data (Commercial / Industrial Electric smart 

meters) where the frequency is 12 – 24 transactions per day and the size of the data is 200 

bytes – 1600 bytes. An example of a scalar value is the send service switch operate 

failure to DAP where the frequency is 1 trans per 1000 switch operate per day. Since this 

is an error based on the original number of switch operate commands, that event’s 

frequency information, which is 1 - 50 transactions per 1000 meters per day, must be 

obtained. 

For each of the possible ranges of values, select a value that is meaningful to your 

particular deployment scenario. The Table 3 and Table 4 contain example selections of 

values. 

Table 3: Selected values for DAP to smart meter direction 

Event How often 

(events/meter/day) 

How often 

(events/meter/midday 

hour) 

Size 

(bytes) 

multiple interval meter 

reading request 

25 events / 1000 meters 

/ day 

Daily value/11 25 

on-demand meter read 

requests 

25/1000 Daily value/15 25 

cancel service switch 

operate request 

2/1000 Daily value/8 25 

service switch operate 

request 

50/1000 Daily value/8 25 

service switch state request 50/1000 Daily value/8 25 

Table 4: Selected values for smart meter to DAP direction 

Event How often 

(events/meter/d

ay) 

How often 

(events/meter/midday 

hour) 

Size 

(bytes) 

multiple interval meter read 

data (Commercial / 

Industrial Electric meters) 

2414 If randomized then daily 

value/24, otherwise 

depends on fixed hourly 

periods 

1600 

multiple interval meter read 

data (Residential electric 

smart meters) 

6 If randomized then daily 

value/24, otherwise 

depends on fixed hourly 

periods 

2400 

 

14 There is an inverse relationship between one value of the “How Often” range to that of some of the 

associated “Payload Size” range values. The intended interpretation of the stated payload size of 1600 is 

associated with a “How Often” value of 12 which ties with 15 minute interval data and 20 data points per 

interval. This misinterpretation of the Requirements Table should not take away from the example of using 

the method and steps. SG Network TF will address how to better document the intended interpretation and 

use of these range of values in the next release (i.e., after v4.0) of the Requirements Table. 
- 27 -

Event How often 

(events/meter/d

ay) 

How often 

(events/meter/midday 

hour) 

Size 

(bytes) 

on-demand read request 

app errors 

25/1000 *1/1000 Daily value/15 50 

on-demand meter read data 25/1000 Daily value/15 100 

send service switch operate 

acknowledgment 

2/1000 Daily value/8 25 

send service switch operate 

failure 

1/1000 * 

50/1000 

Daily value/8 50 

send metrology information 

after a successful service 

switch operate 

2/1000 Daily value/8 100 

send service switch state 

data 

50/1000 Daily value/8 100 

Step 5 - Assume (and document) values for missing information. 

There is still some information not available from the user applications matrix. For 

example to calculate the aggregate traffic from a single 2-Way meter to a DAP, the type 

of 2-way meter is needed; also the number of 2-way meters that will be sending their data 

to a single DAP is needed. 

• How many 2-way Meters? 

o What proportion of types (deployment classifications using the same 

network technology) of smart meters? 

 Commercial / industrial gas smart meters, 

 Commercial / industrial electric meters, 

 Commercial / industrial water meters, 

 Residential gas smart meters, 

 Residential electric smart meters, and 

 Residential water smart meters. 

Assume the following proportions of types of 2-way meters using scenario 2 in Table 5 

as this example has been filtered to just the electric meters: 

 

Table 5: Example 2-way meter deployment classifications and example apportionments 

2-Way meter deployment 

classifications 

Scenario 1 – 

meter (%) 

Scenario 2 – 

meter (%) 

Scenario 3 – 

meter (%) 

Commercial / industrial gas smart 

meters 

 6.5 2.5 

Commercial / industrial electric meters 17.4 10 5.0 

Commercial / industrial water meters 2.5 

Residential gas smart meters 6.5 20 

Residential electric smart meters 69.6 90 45 

Residential water smart meters 25 

Total 100 100 100 
- 28 -

• Quantity of endpoints (meters) per the same technology DAP in a specific 

deployment geographic area. 

Current AMI networks have design maximum number of endpoints per DAP that 

typically range from 1,000 – 50,000. Actual deployment quantity of endpoints per DAP 

will be less than the technology’s maximums based on: 

• the endpoint density 

• design limits’ thresholds imposed by the network designers to address application 

latency requirements and providing “headroom” in the network. 

For deployments of 100,000 endpoints, multiple DAPs will be required, with the actual 

quantity of endpoints (e.g., meters) per DAP varying significantly across that 100,000 

deployment. When the assessment is focused on the ability of a technology to handle the 

deployment, two areas of concern arise (i.e., the high density urban areas and the low 

endpoint density rural areas). One is focused on the handling of all the traffic and the 

other is being able to extend the reach between the DAP and the endpoints and still 

provide acceptable application latency and reliability at acceptable cost points. 

For example purposes only, let us assume a 1000 endpoints per DAP assessment. 

Step 6 - Select which type of data analysis method is to be used: 

There are at least two common approaches to data analysis that deal with events that 

occur in time displaying deterministic timings and those with probabilistic distributions: 

a) aggregation of data volumetrics based on values per a specified time 

period for input into a static system model 

b) simulation of multiple discrete transactions (payloads) retaining each 

event’s unique data volumetrics and profiles 

The aggregation of data volumes based on values per specified time periods will be 

discussed in this step. The simulation approach is further discussed in section 5. 

Aggregation of data volumes based on values per specified time periods, carries with it 

no indication of when those events occur during the time period. Many readers may 

make the assumption that the events occur evenly across the time period, but it is just 

that, an assumption. All that can be stated is that during that time period the events are 

expected to occur at the stated quantity per total period. 

When using the “Daily Clock Periods” a better understanding of the quantity of events 

occurring in that shorter time period is possible, though as in illustrated in Table 3 and 

Table 4 above, interpolating that value to an hourly value for a specific hour of the day is 

possible, but carries the same limits to that usage as mentioned above. 

An alternative to just these simple “How Often” values is to consider what those values 

would be for different operating modes that a smart grid deployment might encounter. 

This might be represented as three different values to account for: normal; medium; and 

high periods of event occurrence. For the meter reading and service switch use cases, 

this might entail: 
- 29 -

• after new rate structures have been imposed 

• high energy usage billing periods 

• college move ins / move outs or entry or exodus of customers 

• storm events 

Whether or not SG Network TF adds this additional level of detail to the Requirements 

Table, the user of the Requirements Table can modify the requirement data themselves to 

match their analysis needs and assumptions, but it must be documented. 

For simplicity, let us disregard the “Daily Clock Periods” and keep the frequency (How 

Often) based on a 24 hour period, daily values. 

Step 7 – Finalize the data preparation tasks based on the selections and assumptions from 

steps 1-6. 

Using the selected values from step 4 and the assumed values from step 5, and assuming 

that a data analysis method is selected using the aggregation of data volumetrics to simple 

per period metrics, the aggregate traffic for each direction is calculated in Table 6 and 

Table 7. 

Table 6: DAP to smart meter direction 

Event How often 

(events/meter/day)

Size 

(bytes/event) 

Average traffic 

load 

(bytes/meter/day) 

multiple interval meter 

reading request 

25/1000 25 0.625 

on-demand meter read 

requests 

25/1000 25 0.625 

cancel service switch operate 

request 

2/1000 25 0.05 

service switch operate 

request 

50/1000 25 1.25 

service switch state request 50/1000 25 1.25 

Total 0.152 N/A 3.8 

Mean message size (bytes) per event = 3.8 / 0.152 = 25 bytes/event 

Number of events per meter per second = 0.152 / 86400 = 1.76 x 10-6 events/meter/s 

Table 7: Smart meter to DAP direction 

Event How often 

(events/ 

meter/ day) 

proportion Size 

(bytes/ 

event) 

Average 

traffic load 

(bytes/ 

meter/day) 

multiple interval meter read 

data (Commercial / industrial 

electric meters) 

24 0.10 1600 3840
- 30 -

multiple interval meter read 

data (Residential electric 

smart meters) 

6 0.90 2400 12960

Subtotal Frequency * 

proportion = 

7.8 events/ 

meter/day 

Frequency 

* Size * 

proportion 

= 

16800 

bytes/ 

meter/day 

on-demand read request app 

errors 

25/1000 * 1/1000 50 0.000025 

on-demand meter read data 25/1000 100 2.5 

send service switch operate 

acknowledgment 

2/1000 25 0.05 

send service switch operate 

failure 

1/1000 * 50/1000 50 0.0025 

send metrology information 

after a successful service 

switch operate 

2/1000 100 0.2 

send service switch state data 50/1000 100 5 

Subtotal 0.079 N/A 7.75375 

Total 7.879 events/meter/day N/A 16808 

bytes/ 

meter/day 

Mean message size (bytes) per event = 16808 / 7.879 = 2133 bytes/event 

Number of events per meter per second = 7.879 / 86400 = 9.12 x 10-5 events/meter/s 

3.7 Security 

Security can be considered at every layer of the communication protocol stack, from the 

physical layer to the application layer. To consider security in the context of PAP 2, 

which is mainly concerned with the physical and media access control layers, implies the 

inclusion of additional protocol and traffic events to achieve security signaling 

functionality as in the case of authentication and authorization, and additional bytes to 

existing payloads to achieve encryption. As a first step towards this goal, the SG Network 

TF Requirements Table lists the security objectives of confidentiality, integrity, and 

availability (CIA’s) for each event. As a second step, a mapping between these CIA 

levels (low/moderate/high) and the security protocols available at the various 

communication layers is needed in order to fully address security in the context of PAP 2. 
- 31 -

4 Wireless Technology 

PAP 2’s task 5 calls for the collection of an inventory of wireless technologies. This 

inventory of wireless technologies is captured as a spreadsheet, Wireless Functionality 

and Characteristic Matrix for the Identification of Smart Grid Domain Applications, 

which can be found on the PAP 2 web site: 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP02Wireless 

with a file name syntax of “Consolidated_NIST_Wireless_Characteristics_MatrixVN.xls”, where N represents the version number. 

Disclaimer: The spreadsheet was created and populated by the Standards Setting 

Organizations (SSO), which proposed their wireless technologies as candidates for the 

smart grid. The parameters and metrics contained and values entered for each wireless 

technology were done by proponents for that technology. The values were not verified 

by PAP 2. 

The next subsections give a brief description of the parameters and metrics contained in 

the spreadsheet, Wireless Functionality and Characteristic Matrix for the Identification of 

Smart Grid Domain Applications and a listing of the technologies submitted (as of 

V5.xls). 

4.1 Technology Descriptor Headings 

To be able to describe wireless technology a set of characteristics were identified and 

organized into logical groups. The group titles are listed below. 

• 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 Measurement & 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 
- 32 -

• 22. Exclusions 

4.2 Technology Descriptor Details 

Each of these groups was composed of individual descriptive components for which an 

entry for each technology was requested. The rows are described in more detail below. 

4.2.1 Descriptions of Groups 1-7 Submissions 

Wireless Functionality and Characteristics Matrix for the Identification of Smart Grid 

Domain Application 

Functionality/Characteristic Measurement Unit 

 

Group 1: Link Availability 

a: 

Ability to reliably establish an appropriate device 

link % of time 

b: Ability to maintain an appropriate connection failure rate per 1000 sessions 

Group 2: Data/Media Type Supported 

a: Voice 

b: Data Max user data rate per user 

in Mb/s 

c: Video Max resolution in pixels @ 

x fps 

Group 3: Coverage Area 

a: Geographic coverage area km2

b: Link budget dB 

Group 4: Mobility 

a: Maximum relative movement rate m/s 

b: Maximum Doppler Hz 

Group 5: Data Rates 

a: Peak over the air uplink data rate Mb/s 

b: Peak over the air downlink data rate Mb/s 

c: Peak goodput uplink data rate Mb/s 

d: Peak goodput downlink data rate Mb/s 

Group 6: RF Utilization 

a: Public radio standard operating in unlicensed bands GHz L/UL 

b: Public radio standard operating in licensed bands GHz L/UL 

c: Private radio standard operating in licensed bands GHz L/UL 

d: Duplex method TDD/FDD 

e: Bandwidth kHz 

f: Channel separation kHz 

g: 

Number of non overlapping channels in band of 

operation 

h: Spectral Efficiency bits/s/Hz 

i: Cell Spectral Efficiency bits/s/Hz/cell 
- 33 -

Wireless Functionality and Characteristics Matrix for the Identification of Smart Grid 

Domain Application 

Group 7: Data Frames and Packets 

a: Frame duration ms 

b: Maximum packet size bytes 

c: Segmentation support Yes/No 

4.2.1.1 Group 1: Link Availability 

The desire is to be able to use the radio link whenever it is needed by the application. 

There is an expectation that the radio link will not be continuously maintained and that 

some devices will be “put to sleep” for periods of time and then, upon “wake up,” be 

required to connect to another device on the network to transfer control information or 

data. Since there is no absolute certainty that a link will be fully operational, there is a 

probability associated with the connection. The technology “Operating Point” chosen is 

presumably chosen recognizing that a high % availability is desired. 

During the period when a radio link is active there is, again, no guarantee that the link 

will be flawlessly maintained. The failure source is not defined but is presumed to be 

associated with the failure of the radio to decode properly the radio symbols causing a 

packet error. Failure could also be caused by interference from other radio sources or 

perhaps deep fading due to shadowing, but these effects are not explicitly included in the 

failure calculations. Rate is another way to represent the statistical nature of a radio link. 

The technology “Operating Point” chosen is presumably chosen recognizing that 

achieving a low failure rate is desirable. 

4.2.1.2 Group 2: Data/Media Type Supported 

Information transferred within the smart grid is usually associated with data. However, it 

was noted that there would be value in transferring both voice and video information. 

a) Voice: There is no specification of the codec being used but the assumption was 

that some form of packetized voice processing would be used and the connection 

would be two-way. 

b) Data: is a generic term for information being transferred from machine to machine 

and can include information being displayed to a person for interpretation and 

further action. 

c) Video: Especially in cases where there is an outage and the situation in the field 

needs to be displayed to others remote from the outage site, video is desirable. 

Video could be still pictures or motion pictures. The request is that the best case 

capabilities be reported. 

4.2.1.3 Group 3: Coverage Area 

Wireless systems are designed to service a wide variety of application scenarios. The 

intent of this group is to capture the expected coverage area in a typical deployment. 

Some systems are optimized for very short ranges, perhaps 10 meters or less, while others 

are intended for longer ranges, perhaps on the order of 30 km. 

The intent of this group is to capture the expected coverage area in a typical deployment. 
- 34 -

When comparing coverage areas, it is important to take into account the link budgets 

used in the coverage computation. Note that the largest coverage area achievable by a 

specific technology typically requires transmission at the lowest data rate used by that 

technology. 

4.2.1.4 Group 4: Mobility 

Some smart grid applications might require relative movement between a transmitter and 

receiver during the operation of the radio link. The inability of the radio link to operate 

successfully in situations of movement is due to Doppler shift. 

This metric is intended to display the mobility capability of the radio technology in one 

or both of the two ways commonly used: 

a) Maximum relative movement rate (expressed in meters/second) 

b) The maximum tolerated Doppler shift (expressed in Hertz) 

Mobile devices may not be able to communicate at the highest available data rates when 

moving at high speeds. 

4.2.1.5 Group 5: Data Rates 

Data rates are a very frequently used metric of radio link capability. The data rates for 

wireless technologies can span three decades of range starting at a few kilo bits per 

second up to several mega bits per second. However, data rate can be considered to be an 

ambiguous term unless the terms of use are fully described. An additional complication 

comes from the fact that the data payload of interest is “surrounded” with additional bits 

used to provide error correction, error detection, address information and a variety of 

pieces of control information. Because of these added bits the data payload may be a 

small portion of the total number of bits transmitted and received. The metrics used for 

this group are therefore in two subsets. 

a) Peak over the air data rates are intended to display the data rates of the PHY when 

sending bits through the air from transmitter to receiver. 

b) Peak goodput is intended to display the rate at which “application data” is being 

transferred. 

Peak goodput rate calculations remove such items as PHY and MAC preamble, address 

and error correction from the calculation. A Goodput data rate will always be less than 

the over the air rate used to send data. 

Additionally, some radio systems are designed with uplink and downlink data rates that 

are equal in both directions, as well as others that allow asymmetric rates. Downlink 

represents the data transmission from the “central” transmitter to the client device 

receiver. Uplink represents the data transmission from the client device transmitter to the 

“central” receiver. Typically the asymmetry is designed to provide a higher downlink 

rate than uplink. This allows a “central” station or base station to take advantage of 

antenna height and transmit power that may not be available on the client device. 

4.2.1.6 Group 6: RF Utilization 

This group asks for display of information on radio spectrum use. 

a) Public radio standard operating in unlicensed band 
- 35 -

b) Public radio standard operating in licensed band 

c) Private radio standard operating in licensed band 

Some radio spectrum is license-exempt and is shared among a wide 

variety of devices. An example of this would be the 2.4 GHz ISM band 

which is generally available anywhere in the world but shared among 

diverse radio technologies, such as cordless phones, 802.11 Wireless 

Local Area Networks (WLANs), 802.15 personal area networks (including 

Bluetooth) devices, to name a few. 

Some spectrum is sold and licensed to individual entities, such as a mobile 

phone service provider, and the designated spectrum (at least on a regional 

basis) is not expected to be used by any other radio type. 

d) Duplex method - It is also generally assumed that Smart Grid radios will be both 

transmitting and receiving information. One method used to accomplish bidirectional transfer is time division duplexing (TDD) where uplink and downlink 

packets are alternated in time. Another method is frequency division duplexing 

(FDD) where uplink and downlink packets are carried on different frequencies. 

e) Channel bandwidth - As with data rates, some radios use a very small amount of 

radio spectrum for their channel bandwidths (perhaps a few kilohertz) while 

others may use a very large swath (perhaps several MHz). 

f) Channel separation - This metric is intended to report the separation between 

channels. 

g) Non-overlapping channels in the band 

To use an example, some 802.11 radios operate in the 2.4 GHz unlicensed 

ISM band. Within the US there is 83.5 MHz of spectrum available; 

however, there are restrictions on “out of band emissions”. (Described in 

FCC Title 47). 802.11 initially chose to use a spread spectrum technology 

that occupied 20 MHz of channel bandwidth. When the FCC rules and the 

technology choices are combined, the result is a technology that has 11 

operating channels defined with center carrier frequencies separated by 5 

MHz. Hence, in the 2.4 GHz band, 802.11 technology would be described 

as having 11 operating channels, separated by 5 MHz and three nonoverlapping channels. 

h) Spectral efficiency (bits/second/Hz) - This is a measure of the efficiency of use of 

the spectrum. It is highly dependent on the modulation scheme being used. 

Although the differences between over-the-air and usable data described under 

“Group 5 - data rate” could be repeated here, the intent for this study is only to 

represent over-the air information. As an example, a radio system operates at a 

nominal 1800 MHz with a signal that uses 10 kHz of spectrum (Channel 

bandwidth) to transfer 10 kb/s of signal information, plus has a spectral efficiency 

of 1 bit per second per Hertz. 

i) Spectral efficiency (bits/second/Hz/cell) - By default a simple monopole antenna 

generates an isotropic pattern with equal transmit and receive gain equal in all 

directions. Some systems employ narrow band antenna technology to allow the 

otherwise circular coverage area to be subdivided into “sectors”. Each sector then 

services its own group of radios independently. Although the “central” station 
- 36 -

requires a separate antenna for each sector the scheme allows for a greater number 

of client devices per area of coverage. 

4.2.1.7 Group 7: Data Frames and Packets 

This group asks for display of information on packetization process. 

a) What is the maximum frame duration? 

b) What is the maximum packet size that can be sent in one radio frame? 

c) Does the radio system support segmentation when the payload size exceeds the 

capacity of one radio frame? 

4.2.2 Descriptions of Groups 8-12 Submissions 

Group 8: Link Quality Optimization 

a: Diversity technique antenna, polarization, 

space, time 

b: Beam steering Yes/No 

c: Retransmission ARQ/HARQ/- 

d: Error correction technique 

e: Interference cancellation 

Group 9: Radio Performance Measurement & Management 

a: RF frequency of operation 

b: Retries 

c: RSSI 

d: Lost packets 

Group 10: Power Management 

a: Mechanisms to reduce power consumption 

b: Low power state support 

Group 11: Connection Topologies 

a: Point to point 

b: Point to Multipoint 

c: Broadcast 

d: MESH 

Group 12: Connection Management 

a: Handover 

b: Media Access Method 

c: Discovery 

d: Association 

4.2.2.1 Group 8: Link Quality Optimization 

Radio systems can use a variety of techniques to improve the likelihood a transmitted 

packet will be successfully received. The most fundamental technique is to have the 

receiving radio send an acknowledgement (ACK) back to the transmitting station. If the 

ACK is not received, then the transmitter will try again (up to some limit of retries). 

Other techniques seek to improve the signal to noise ratio (SNR) at the receiver. The 
- 37 -

techniques include polarization, beam steering, etc. The intent here is to capture the 

techniques employed by the candidate systems. 

4.2.2.2 Group 9: Radio Performance Measurement & Management 

This group is used to indicate what the radio technology provides to an administrator to 

assist in link assessment. Most radio systems dynamically and autonomously assess their 

environment and adjust to optimize performance. Sometimes it is useful for a network 

administrator to monitor behavior to determine if problems exist that are impeding 

performance or perhaps make manual selections that might indeed improve radio 

performance beyond what might be achieved autonomously. 

4.2.2.3 Group 10: Power Management 

Radio devices may not be directly powered by mains power supply and may be required 

to “run off” a battery that is seldom, if ever, recharged. The intent is to capture 

information on techniques the radio technology has defined that can be used to reduce 

power consumption. 

4.2.2.4 Group 11: Connection Topologies 

Radio systems may be designed to use one or more connection topologies. One form that 

is often used is the star topology. 

Bus Ring

Mesh

Star

4.2.2.5 Group 12: Connection Management 

This group is intended to capture the capabilities provided to initiate and maintain radio 

connectivity. 

4.2.3 Descriptions of Groups 13-20 Submissions 

Group 13: QoS and Traffic Prioritization 

a: Traffic priority diffserv, resserv 

b: Pass-thru Data Tagging 

c: Radio queue priority 

Group 14: Location characterization 

a: Location awareness (x,y,z coordinates) 

b: Ranging (distance reporting) 

Group 15: Security and Security Management 

a: Encryption Algorithms supported

b: Authentication 

c: Replay protection 
- 38 -

d: Key exchange Protocols supported 

e: Rogue node detection 

Group 16: Radio Environment 

 Channel model 

 Interference sources 

Group 17: Intra-technology Coexistence 

a: Co-channel interference 

b: Adjacent channel interference 

c: Alternate channel interference 

d: Collision avoidance 

e: Protection mechanisms 

Group 18: Inter-technology Coexistence 

a: Sensitivity to other interfering radio technologies 

b: Degree of interference caused to other radio technologies 

c: Sensitivity to power line RF emissions 

Group 19: Unique Device Identification 

a: MAC address 

b: SIM card 

c: Other identity 

d: Rogue detection 

Group 20: Technology Specification Source 

a: Base Standard SDO SDO name 

b: 

Profiling and Application Organizations Association / Forum 

Name 

4.2.3.1 Group 13: QoS and Traffic Prioritization 

Quality of service can be viewed as an end-to-end requirement, but some radio systems 

assist in the process by providing QoS between radio nodes. This group is used to 

capture information regarding the capabilities to manage traffic priority. 

a) Traffic priority refers to the ability of radio systems to use high level priority 

schemes such as diffserv (defined by Internet Engineering Task Force (IETF) 

RFCs 2472 & 2475) & intserv (defined by IETF RFCs 1633 & 2205). 

b) Pass-thru data tagging refers to the ability to transfer successfully packets that 

use a class of service priority tags, such as those defined by IEEE 802.1p 

c) Radio queue priority refers to the ability of radio nodes to prioritize packets 

that are queued for transmission. 

4.2.3.2 Group 14: Location Characterization 

Radio systems that provide information about their location can be helpful. One common 

form of location information would provide three-dimensional information regarding 

position, such as that provided via GPS coordinates. An alternate form would provide 

range information such that when the absolute location of every node is not known, if the 

location of one radio device was known, then at least the distance between the nodes 

could be provided. 

4.2.3.3 Group 15: Security and Security Management 
- 39 -

Ensuring that smart grid data is transferred securely is a high priority. As with others such 

as QoS there are options to apply security at multiple different layers in the 

communications OSI model. This group focuses on options provided and by the radio 

system at layer 1 and layer 2. 

4.2.3.4 Group 16: Radio Environment 

When a wireless technology is designed, the radio environment is considered for effects 

that it might have on the quality of the radio link. A channel model is usually chosen to 

represent a typical (or expected) radio environment where the wireless technology is to 

be deployed. A channel model may consider various forms of signal degradation due to 

propagation losses and system losses, and it may include environmental effects such as 

fading and shadowing. 

Interference sources generate electromagnetic energy that impinges on the receiver, and 

which can make receiving the intended transmitted signal difficult. Interference can arise 

from a variety of natural and human-made sources. Interference can be unintentional 

(e.g. sources such as rotating machinery or other wireless communications networks that 

share the same frequency band) or it can be intentional (e.g. jamming). 

When the details are provided for both the channel model and the interference sources, 

the expected performance and quality of service for a given wireless technology can be 

studied and verified. Without such details, the behavior of a wireless technology in a 

radio environment for which it was not designed would be unpredictable. In the absence 

of testing, wireless technologies should not be assumed to operate in environments for 

which they were not designed. 

4.2.3.5 Group 17: Intra-technology Coexistence 

Some radio technologies provide mechanisms for avoiding or detecting interference 

caused by other radios of the same type within receiving range. The intent is to 

determine if a system has such capabilities that can be used to reduce detrimental 

interference and thereby improve SINR, and thus allow the radio to maintain a low error 

rate link. 

4.2.3.6 Group 18: Inter-technology Coexistence 

As with the previous group, some radio technologies provide mechanisms for avoiding or 

detecting interference caused by other radios of a different type that are operating in the 

same spectrum and are within receiving range. The intent is to determine if a system has 

such capabilities that can be used to reduce detrimental interference and thereby improve 

SINR, and thus allow the radio to maintain a low error rate link. 

4.2.3.7 Group 19: Unique Device Identification 

It is desired that each radio node be directly identifiable and addressable. This requires 

that each device have a unique identification scheme. There is more than one way to 

accomplish this. The information provided will identify the unique identification scheme 

offered. 
- 40 -

4.2.3.8 Group 20: Technology Specification Source 

The intent is to provide information about the SDO that developed and maintains the 

radio technology, plus identify who provided the information contained in the matrix. 

Also, in some cases the base standard source is assisted by a compatriot organization that 

provides additional support including specifications or applications that operate above 

Layer 2. The support organizations may also provide certification of specification 

compliance, interoperability and performance. 

4.2.4 Descriptions of Group 21 Submission 

Wireless Functionality NOT directly specified by a standard 

that is needed in quantifying operating metrics 

 Rx sensitivity dBm 

 Tx power peak dBm 

 Antenna gain dBi 

 Noise floor dBm 

Modulation GFSK, OFDM, 

BPSK, GMSK 

 Forward error coding Coding rate 

4.2.4.1 Group 21 Description 

Although these items are vital components of a radio technology description, they do not 

directly affect the suitability of a technology to a smart grid application. 

They are a few additional characteristics that are needed to characterize the operation of 

the radio for the chosen operating point. 

• Rx sensitivity - Receiver sensitivity may be specified as a minimum capability 

required by the SDO in the technology specification. Technology 

implementations may provide much greater sensitivity than the minimum, so the 

intent is to capture a typical value that is used for the operating point calculations. 

• Tx power peak – Transmission peak power is needed for the calculations as well. 

Some technologies specify only a regulatory limit or allow for a wide variety of 

options. The Tx power of the devices under consideration for the operating point 

calculations needs to be specified. 

• Antenna gain - Antenna gain is rarely part of a technical radio standard, but is a 

critical component of link budget calculations. 

• Noise floor - Noise floor is much like receiver sensitivity. There might be a 

minimal specification for noise floor required by the SDO in the technology 

specification. Technology implementations may provide a much lower noise floor 

than the minimum, so the intent is to capture a typical value that is used for the 

operating point calculations. 

• Modulation - The modulation scheme is not directly part of any calculation but 

needs to be indentified to aid in other technologists verifying the operating point 

calculations were correct. 
- 41 -

• Forward error coding - The methods used by the technology are not of direct 

interest but the coding rate is when trying to understand the difference between 

over-the-air data rates and goodput rates. 

4.3 Technology Submission Titles 

Responses have currently been received for the following technologies: 

• Cdma2000 1x and cdma2000 High Rate Packet Data (HRPD) 

• Cdma2000 xHRDP 

• Geo Mobile Radio 1 (GMR-1) Third Generation (3G) 

• Internet Protocol over Satellite (IPOS) /Digital Video Broadcast (DVB)-S2 

• Regenerative Satellite Mesh - A (RSM-A) 

• IEEE 802.16 e,m 

• IEEE 802.11 

• IEEE 802.15.4 

• Inmarsat Broadband Global Area Network (BGAN) 

• Long Term Evolution (LTE) 

• Evolved High-Speed Packet Access (HSPA+) 

• Universal Mobile Telecommunications Systems (UMTS) 

• Enhanced Data rates for GSM Evolution (EDGE) 

• Bluetooth 

5 Modeling and Evaluation Approach 

Determining an assessment method for evaluating whether a wireless technology can 

satisfy the smart grid user applications’ requirements is a daunting task, especially given 

that there are many possible physical deployment options for smart grid devices and 

facilities, many wireless technology standards, and uncertainty in planning for future 

needs. 

Some wireless technologies are a part of a larger system, while others are complete 

communication networks. For example, wireless technologies developed by many IEEE 

802 working groups consider mostly the Media Access Control (MAC) sublayer and 

Physical Layer (PHY). In many such cases, other non-IEEE specifications are used as 

the basis of a complete network specification; for example, the WiMAX Forum provides 

complete end-to-end specifications for mobile networks based on the IEEE Std 802.16. 

Likewise, the Universal Mobile Telecommunications System (UMTS) is a complete 

mobile (and wireless) network system. For many reasons, including the differing scope 

of the basic specifications, comparing wireless technologies is impractical. PAP 2 

assesses each wireless technology on whether it can satisfy the smart grid user 

applications’ requirements; PAP 2 will not rank the various wireless technologies relative 

to each other. 

5.1 Assessment of Wireless Technologies Against Smart Grid Business Application 

Requirements 
- 42 -

The assessment approach described below should be considered as an example, not the 

approach that must be used. Options are discussed on how the assessment can be refined 

with one method further described and detailed in this section’s subsections. The two 

main tasks are: 

1) Perform an initial screening of the wireless technologies against the smart grid 

business functional and volumetric requirements and 

2) Perform refinements to the initial screening using one or a combination of the 

following: 

• Mathematical models 

• Simulation models 

• Testbeds (lab and in the field) 

5.1.1 Initial Screening 

The initial screening (technology assessment) is based on the smart grid user 

applications’ requirements in section 3.4 and the wireless functionality and characteristics 

matrix in section 4. For example, a user application’s requirement for reliability should 

be related to the wireless technology’s link availability (i.e. the ability to reliably 

establish an appropriate device link and the ability to maintain an appropriate 

connection). One can use the results from the initial assessment to determine whether a 

given wireless technology should be further considered for use with a particular 

application in a particular deployment. 

5.1.2 Perform Refinements to Initial Screening 

After the initial screening, the next step is to refine the assessment using other methods 

(i.e., mathematical models, simulations models, or testbeds). 

5.1.2.1 Mathematical Models 

These types of models require creating mathematical model representations that 

approximate the characteristics of the system in question (e.g., the smart grid). These 

models can be simplistic in that event data volumetrics are aggregated to singular values, 

or events are treated as individual inputs into the models, or data volumetrics represented 

and input based on probabilities. Mathematical models usually take less time to produce 

results than simulation models. There are some limitations to what some of the simpler 

mathematical models can adequately model. 

5.1.2.2 Simulation Models 

These types of models, attempt to account for more of the event occurrence variability as 

noted in the mathematical model discussion above. Simulation models can provide more 

realistic results than mathematical models, which often require simplifying assumptions 

to make them tractable. 

5.1.2.3 Testbeds 

Usually, neither mathematical or simulation model types are able to capture all of the 

details of a proposed network deployment (e.g., accurate channel models are difficult to 

obtain without direct measurement of the deployment environment). Using testbeds (in 
- 43 -

the lab and, preferably, actual in the field), can provide very accurate results; however, 

this method requires significant time, effort, and resources to produce results. 

These results may also be provided as feedback to the other types of models to improve 

their results. 

5.1.2.4 Network Design 

The key for network design is to understand and define the network’s system design 

goals. Designing a network system to support the average data requirements is one design 

concept, which tends to result in under designed and built networks. Another concept is 

to design network systems that can handle the absolute worst case imaginable, which 

tends to result in over designed and built networks. Again the key is to establish a goal of 

the network and of the individual elements and threads of that network so that it will 

handle the heaviest expected (combined) burst rates with an acceptable level of failure. 

For example, in the old telephone trunk design days, one would specify the number of 

voice trunks necessary to carry the “busy hour” traffic with an acceptable level of failure 

(2% failure, 5% failure, etc.). 

This then leads to two questions that the network designers and implementers need to 

address, but are not answered in this guideline: 

1) What is this highest level of traffic that must be accommodated over the burst 

period(s)? 

a. The methods for determining this will be highly dependent on the 

individual utility operational modes and the aggregated data that will flow 

through a particular network link or thread. As you can imagine, this will 

vary greatly from utility to utility and with the topology/technology used 

to construct the network threads. 

2) What is an acceptable level of overloading these threads that will result in failure 

to deliver the data within the required latency and fidelity constraints? 

a. This will depend on multiple factors, including the latency and fidelity 

requirements of the system or application, buffering capabilities to buffer 

overflow traffic, and how error recovery is accomplished. 

The Utilities will need to implement systems that will satisfy the needs of that specific 

utility. Translation – one size does not fit all. So the network designers need to find a 

way to project and predict the real temporal (and spatial) requirements of the data flows 

(for the utility, application, or operating mode in question) and to then select and 

implement technologies and topologies that will provide the needed capacity, reliability, 

security, cost effectiveness, etc. 

A general modeling framework was developed by the PAP2 working group and it is 

described in section 5.2. 

5.2 Modeling Framework 

The goal of the development process was to produce an analytical structure that was 

flexible so that it allows users to employ a variety of modeling techniques that can be 
- 44 -

used with virtually any proposed wireless technology. The framework’s main 

components are a MAC sublayer model, a PHY model, a module that performs coverage 

analysis, a channel propagation model, and a model for multiple links (multilink). The 

overall design of the model is shown in Figure 4. The following subsection discuss each 

of these components and explain how they interact with each other and operate within the 

larger analytical framework. 

Probability

Tx Failure

Requirements

Output

Application

Distance

Tx-Rx

PHY

Model

SNR

Application Requirements Input

SINR

Number of Devices

Message Frequency

Message Size

Environment

Outage Prob.

Multilink Reliability

Multilink Delay

Multilink Throughput

Routing

Top. Link Reliability

Link Delay

Link Throughput

Model

Propagation

Channel

Path Loss

Model

Analysis

Coverage

Max. Outage

Prob.

Max. Tx-Rx Dist.

Wireless Technology Inputs

MAC

Model

Model

Multilink

Figure 4 – Modeling Framework Building Blocks 

5.2.1 Channel Propagation Models 

Channel propagation models characterize how different electromagnetic environments 

alter a communications signal propagating along the wireless path between a transmitter 

and receiver. Because it affects the receiver signal-to-noise ratio, the characteristic of 

greatest interest to the wireless communications designer is signal attenuation. Other 

important characteristics are shadow fading and small-scale fading. 

Signal attenuation is modeled through the quantity known as the path loss. It is important 

to recognize that a single model cannot fully describe or predict path loss characteristics 

for all possible scenarios. Operating frequency and deployment environment such as 

indoor, outdoor, urban, suburban, or rural; must also be considered. Following are some 

well-known narrowband channel models that can used to predict the path loss for groundto-ground and tower-to-ground systems. 
- 45 -

5.2.1.1 Generic Model 

The path loss quantity, PL, models the attenuation of the signal in terms of the fraction of 

the received power to the transmitted power measured at the antennas. The deterministic 

component of the path loss, PLd, is a function of the path distance, d, in meters between 

the pair. The widely accepted model in the wireless propagation community is 

exponential attenuation in function of distance according to a path loss exponent, n0. 

However, in particular in non-line-of-sight environments, the degree of exponential 

fading increases to n1 after a certain breakpoint distance, d1. The breakpoint path loss 

model below (equivalently shown on a dB scale) is more general to capture this 

phenomenon: 

⎪

⎩

⎪

⎨

⎧

+ >

≤ = +

0 10 1 0 1 10 1 1

0 10 0 1

d,dB 0,dB 10n log (d / d ) 10n log (d / d ), d d

10n log (d / d ), d d

PL (d) PL , 

where PL0,dB is the reference path loss at d0 = 1 meter. All the model parameters are 

frequency-specific. 

The random component of the path loss (PLr,dB = Xs,dB + Xf,dB) is composed from two 

terms. The first term, Xs,dB, is referred to as shadow fading. It represents the deviation of 

the signal from its predicted deterministic model due to the presence of large obstructions 

on the wireless path. Obstructions may be buildings or cars in the outdoor environment 

or walls or furniture in the indoor environments. These objects have varying size, shape, 

and material properties which affect the signal in different ways. Xs,dB is modeled as a 

zero mean Gaussian random variable with standard deviation, σ. The second term, Xf,dB, 

is referred to as small-scale fading. It represents the deviation of the signal due to the 

presence of smaller obstructions on the path which cause scattering of the signal. The 

signals then constructively and destructively recombine at the receiver. Xf is modeled as 

a unit-mean gamma-distributed random variable with variance 1/m (where m is the 

Nakagami fading parameter) and Xf,dB = 10 log10(Xf ). The shadow fading and smallscale fading are assumed to be constant during the transmission of a frame, mutually 

independent, and independent of those on other links. 

The complete path loss model, including both deterministic and random components, is 

dB d,dB PLr,dB PL = PL (d) +

Figure 5 shows the path loss model extracted from actual measured data points. The 

deterministic component in red is fit to the blue data points collected in an indoor-indoor 

residential environment at fc = 5 GHz. The deviation of the data points from the line 

reflects the random component. 
- 46 -

 Figure 5 - The breakpoint path loss model in an indoor-indoor residential environment at 

fc = 5 GHz 

5.2.1.2 Outdoor Channel Models 

5.2.1.2.1 The Hata Model: 

The Hata model for the deterministic component of the path loss PLd,dB, based on 

empirical data, is applicable over a frequency range from 700 MHz to 1500 MHz. 

PLd,dB = 69.55 + 26.16log10(f) - 13.82log10(Th) - a(Rh) + [44.9 - 6.55log(Th)]log10(d) + D, 

 where: 

 d = path distance in km from 1 – 20 

 f = frequency in MHz 

 Th = base station antenna height from 30 to 200 meters 

 Rh = subscriber station antenna height from 1.0 to 10 meters 

and 

for Urban environments: 

 a(Rh) = 3.2[Log10(11.75*Rh)]2

 - 4.97 

 D = 0 

for Suburban environments: 

 a(Rh) = [1.1*Log10(f)-0.7]*Rh - [1.56*Log10(f)-0.8] 

 D = - 2[Log10(f/28)]2

 - 5.4. 
- 47 -

5.2.1.2.2 Modified Hata (aka COST 231 Model): 

The modified Hata model, also for the deterministic component of the path loss PLd,dB, is 

applicable from 1500 MHz to 2000 MHz and with a frequency correction factor fc can be 

extended to higher frequencies. 

PLd,dB = 46.2 + 33.9log10(f) - 13.82log10(Th) - a(Rh) + [44.9-6.55log(Th)]log10(d) + 

 0.7*Rh + C + fc 

where: 

 d = path distance in km from 1 – 20 

 f = frequency in MHz 

 Th = base station antenna height from 30 to 200 meters 

 Rh = Subscriber Station Antenna Height from 1.0 to 10 meters 

 fc = 26*Log10(f/2000) for f >2000 MHz, 0 for f <2000 MHz 

and 

for Urban environments: 

 a(Rh) = 3.2*[log10(11.75*Rh)]2

 - 4.97 and C = 3 dB 

for Suburban environments: 

 a(Rh) = [1.1*log10(f)-0.7]*Rh - [1.56*Log10(f)-0.8] and C = 0. 

5.2.1.2.3 Erceg Model: 

Another channel model that has proven effective for projecting path loss for fixed rural 

area deployments is the Erceg Model. For this model, which is considered applicable 

from 1800 to 2700 MHz, three terrain types are defined as follows: 

• Terrain Type A: Hilly with moderate to heavy tree density 

• Terrain Type B: Hilly with light tree density or flat and moderate to heavy tree 

density 

• Terrain Type C: Flat with light tree density 

The path loss is given by the following expression: 

PLd,dB = 20log10(4π d0 /λ) + 10(a-b*Th + c/Th)log10(d/ d0) +6log10(f/2000)-

XLog10(Rh/2) 

where: 

 d = distance of path distance in meters 

 f = frequency in MHz 

Th = base station antenna height in meters 

Rh = subscriber station antenna height in meters 
- 48 -

d0 = 100 meters 

λ = wavelength in meters

The remaining parameters are provided in the following table: 

Parameter Type A Type B Type C 

a 4.6 4.0 3.6 

b 0.0075 0.0065 0.005 

c 12.6 17.1 20 

X 10.8 10.8 20 

The following figures (Figure 6, Figure 7, and Figure 8) provide a view of the path loss 

predicted based on the above models for frequencies ranging from 700 MHz to 3650 

MHz. In all cases, the base station antenna height is assumed to be 30 meters and the 

subscriber station antenna is assumed to be 10 meters. The subscriber station antenna 

height assumption is considered reasonable for a DAP. 

Figure 6 - Path loss as a function of path length for an urban area 
- 49 -

Figure 7 - Path loss as a function of path length for a suburban area 

Figure 8 - Path loss as a function of path length for a rural area 

Another parameter that is of interest in assessing the path loss is the sensitivity to the 

relative antenna heights. Each of the three channel models described above has a 

dependency on both the base station and subscriber antenna height. In most deployments 

the base station will be mounted on a tower or on a building rooftop to achieve an 

antenna height of 30 meters or more. The subscriber station antenna height, however, will 

be more variable as it is strongly tied to the usage model. 

Figure 9 and Figure 10 show the effect of varied subscriber station antenna heights on 

path loss as predicted by the Hata and modified Hata models. Note that for urban areas 

the impact of the subscriber station antenna height on path loss is independent of 

frequency. 
- 50 -

Figure 9 - Effects of SS antenna height on relative path loss in an urban area 

Figure 10 - Effects of SS antenna height on relative path loss in a suburban area 

5.2.2 Coverage and Range Analysis 

The purpose of the coverage analysis is to predict the maximum range of a wireless 

technology for a given outage probability and a specified set of operating parameters. 

The maximum range is useful in determining the suitability of a technology for linking a 

particular pair of smart grid actors and predicts its coverage area in a point-to-multipoint 

topology. The outage criterion is the probability that the wireless transmitter-receiver 

link is not operational. It is expressed in terms of a probability due to the unpredictable 

behavior of RF propagation. Outage is often modeled as a stochastic process when 

accounting for the possible losses due to obstructions (shadowing) and reflections 

(multipath fading). 

In the context of point-to-multipoint wireless technology, coverage can be analyzed in 

terms of the maximum cell radius that a base station or an access point can support. In 
- 51 -

this spirit, the link budget of the wireless link is examined in conjunction with the 

appropriate path loss models described in section 5.2.1. 

A Link Budget analysis considers all of the relevant network parameters and thus serves 

as an essential tool in the design of point-to-multipoint wireless networks. 

Control channels and data channels in wireless networks often use different features. 

Therefore the link budget for control channels and data channels tend to be different. For 

example, during the network entry procedure when the bulk of the control messaging is 

exchanged in a wireless network, several features that enhance the link budget are not 

used. These features are available however, for the data channels. These link budget 

enhancing features include: Hybrid Automatic Repeat Request (HARQ), multiple-input / 

multiple-output (MIMO), etc. 

The link budget must be calculated for the data channels and the control channels for 

both uplink (UL) and downlink (DL) traffic. The applicable link budget for projecting the 

range is the minimum of: DL Control Channel link budget, UL Control Channel link 

budget, DL Data Channel link budget, and the UL Data Channel link budget. 

To calculate the various link budgets, the following parameters are required: 

• Effective isotropically radiated transmit power (EIRP) in dBm (TxEIRP) 

• Receiver sensitivity at lowest operating MCS in dBm (RxSNS) 

• Combining gains (HARQ gains, repetition gain, etc...) in dB (CombGain) 

• Receiver antenna + amplifier gain in dB (RxGain) 

• Receiver cable loss in dB (CablLoss) 

• Wall penetration loss in dB (PenLoss) 

The maximum allowable path loss for a specific channel is given by: 

 MaxPL = TxEIRP – RxSNS + CombGain + RxGain – CablLoss – PenLoss (1) 

The maximum system allowable path loss is given by the minimum MaxPL for all 

channels 

 MaxPLsys = min (MaxPL over all channels in either UL or DL direction) (2) 

For a predefined system, the outage probability at a certain distance, d, from a base 

station or an access point can be calculated as follows: 

 Fade Margin = MaxPLsys – PLd,dB , (3) 

where PLd,dB is the path loss at d as calculated by one of the path loss models in 

section 5.2.1. 

In addition, given the stochastic models for various categories of fading (shadow, smallscale), the outage probability can be expressed as: 
- 52 -

 Outage Probability = Probability (Random Fading > Fade Margin) (4) 

The above analysis can be done in reverse to calculate the maximum range or, for 

ubiquitous coverage, the maximum allowable base station–to-base station spacing to 

guarantee a specific outage probability. 

Both the Link Budget and the Path Loss are also linked to the usage model of interest. 

While the base station parameters are relatively independent of the usage model, the 

terminal or subscriber station parameters will vary considerably depending on the 

application. 

Usage models for smart grid applications can be described as follows: 

• Fixed Outdoor-Mounted Subscriber Station: This would be a typical 

installation for a DAP, substation, or other distribution facility. The terminal or 

subscriber station can be mounted on an existing utility pole, on top of, or on the 

side of an existing structure. For this usage model the subscriber station is 

equipped with a high gain directional antenna that is aligned to maximize received 

signal strength. With easy access to AC power, the uplink transmit power 

(TxEIRP) can be set to the maximum allowed by regulation. In summary, this 

usage model is characterized by: 

o High subscriber station antenna gain: typically 12 dBi to 17 dBi dependent 

on operating frequency and antenna size 

o Higher transmit amplifier power 

o Relatively high antenna height: typically 8 meters -10 meters (or higher) 

• Vehicular-Installed Mobile Station: Equipping utility emergency vehicles with 

mobile wireless stations can provide a key communications link for disaster 

recovery as well as routine grid maintenance activities. Compared to the Fixed 

Outdoor Subscriber Station, these installations are characterized by:

o Lower antenna gain: must be omnidirectional in azimuth, typically 6 dBi - 

8 dBi 

o Lower antenna height: typically two meters to three meters, if mounted on 

vehicle roof 

• Fixed Indoor Subscriber Station: For smart grid applications, this usage model 

would apply to a smart meter, remote office, a temporary quick-to-install station, 

or possibly a work-at-home situation for a key utility worker. For this usage 

model, the link budget is impacted by: 

o Antenna gain: limited in size for convenience purposes, typically 6 dBi - 8 

dBi 

o Antenna height: typically 1 meter to 3 meters 

o Building/wall penetration loss: this can vary from 3 dB to 4 dB for a 

window-placed station in the 700 MHz band to more than 15 dB to 20 dB 

for a location well inside an urban building in the higher frequency bands. 
- 53 -

• Mobile Hand-Held Subscriber Station: This may not necessarily be a common 

usage model for smart grid applications, since it can in most cases be covered 

with the use of public networks. Nevertheless, for completeness, it is worth 

mentioning here. The link budget for the mobile usage model is almost always 

limited by the uplink control channel; this is due to the limited antenna size and 

the lower transmit power of the hand-held device. The transmit power is 

constrained by the battery capability. For this usage model, the link budget must 

account for:

o Lower antenna gain: must be omnidirectional, typically -1 dBi to 0 dBi

o Antenna height: typically 1.5 meters

o Lower transmit power: typically 200 mW

o Building/wall penetration loss: to support indoor operation

Taking these factors into account, the difference in link budget for a fixed outdoor 

subscriber station compared to a mobile hand-held subscriber station can range from as 

much as 20 dB in the 700 MHz band to more than 30 dB in the 3650 MHz band. 

Deciding on which usage models are most important for smart grid applications is a key 

consideration in determining the base station requirements for ubiquitous wireless 

coverage. 

5.2.3 Physical Layer Model 

The purpose of the PHY layer model is to estimate the probability that a transmission 

attempt fails due to channel errors caused by noise and interference. The transmission 

failure probability takes into account factors affecting the link budget, including 

transmission power, antenna gains, channel attenuation, thermal noise, background 

interference, the number of contending stations (if the channel is shared), and the spread 

spectrum processing gain, if applicable. Depending on the level of modeling, the PHY 

layer model may also explicitly model the stages of the transceiver, such as channel 

equalization, demodulation, and forward error correction, resulting in a bit error rate or 

block error rate. Alternatively, the PHY model may abstract some of these functions and 

model them with an overall required Eb/N0 (energy per bit to noise power spectral density 

ratio), wherein the probability of transmission failure is reflected as the probability that 

the received signal-to-noise-and-interference ratio (SINR) per bit exceeds the required 

Eb/N0. 

As part of the modeling framework, the PHY model provides the MAC sublayer model 

with a conditional probability of transmission failure. For example, with a contentionbased MAC, the MAC model supplies the PHY model with the number of contending 

transmissions. Given the parameters of the link budget and channel statistics, the PHY 

model then returns the probability that the transmission of interest is unsuccessful 

conditioned on the number of contending transmissions. 

5.2.4 MAC Sublayer Model 
- 54 -

The MAC sublayer model can be either analytical or simulation-based, and its 

complexity is determined by the preferences and needs of the user. The MAC sublayer 

model receives inputs based on the application requirements and the wireless (or wired) 

technology that is being used to transport the data; the model interacts with both the PHY 

model and the coverage model. 

The MAC sublayer model is responsible for returning values for the following 

performance metrics for the communications system: 

• Reliability 

• Mean packet delay 

• Throughput 

Reliability, R, is defined to be the probability that a packet originating from a sending 

node’s MAC sublayer is correctly received by the corresponding MAC sublayer at the 

receiving node. Thus the reliability is defined with respect to a single link, rather than on 

an end-to-end or edge-to-edge basis. For MAC sublayers with a shared channel, where 

there is contention for resources, the reliability is the probability that the packet does not 

collide with any packets that are transmitted by other senders and that the packet is not 

corrupted by channel errors. If the channel is dedicated to the sender (no contention), 

then the reliability is simply the probability that the packet does not experience any 

channel errors. 

The mean packet delay, D, is the average time from the passage of the packet to the 

sender’s MAC sublayer from the protocol layer immediately above to the delivery of the 

packet by the receiver’s MAC sublayer to the protocol layer immediately above it. The 

mean packet delay includes the following: 

• The time that the packet spends in the sender’s MAC sublayer’s transmission 

buffer 

• The processing time at the sender’s MAC sublayer 

• The time required to transmit the packet, which is the packet length in bits divided 

by the PHY channel rate in bits/s 

• The time spent waiting to retransmit the packet if it encounters collisions (in the 

case of a contention-based MAC protocol) or channel errors 

• The propagation delay between the sender and the receiver 

• The processing time at the receiver’s MAC sublayer 

The throughput, S, is a measure of how efficiently the channel is being used, and it is 

measured in units of application bits per second. The model computes two types of 

throughput. The first type is the average throughput, which is the product of the offered 

load at the application layer, λ, and the packet reliability, R. Note that this means that the 

ratio of the throughput to the offered load is always a number between 0 and 1. The 

second type of throughput measured by the model is the instantaneous throughput, which 

is the ratio of the mean number of application data bits per packet to the mean packet 

delay. This gives the effective channel rate experienced by a packet that is ultimately 

successfully sent across the link, even if it requires retransmissions. 
- 55 -

The major external inputs that do not depend on the particular MAC technology are the 

number of devices accessing the channel, the mean packet generation rate of each device, 

and the mean packet size. The mean packet generation rate is typically given in units of 

packets per second; the actual packet generation process is arbitrary. Packets can arrive 

according to a deterministic process, in which case the mean generation rate is simply the 

actual generation rate, or they can arrive according to a random process (e.g., a Poisson 

arrival process). The size of the packet typically includes the size of the application data, 

as well as the combined size of all headers, including the MAC sublayer and PHY 

headers. The packet size can be deterministic or random, depending on the applications 

that are being modeled. 

There are additional inputs that are unique to the MAC technology that is being modeled. 

In the case of a contention-based MAC technology, these parameters can include the 

number of times the MAC sublayer will attempt to transmit a packet before giving up and 

dropping it, rules for handling packet collisions, such as the amount of time that the MAC 

sublayer must wait to retransmit a packet after it has collided with a packet from another 

transmitter, and the amount of time the sending MAC sublayer must wait for an 

acknowledgement of a transmitted packet before taking further action. Non-contention 

MAC technologies will use different parameter sets. 

The PHY layer model exports the probability of transmission failure (Pfail) to the MAC 

sublayer model, which uses it to help compute the output metrics. For instance, if 

modeling a very simple MAC layer that uses dedicated resources (so no contention) and 

no retransmissions, it would be found that the reliability is equal to (1 − Pfail), and the 

mean delay of successfully received packets is the sum of the propagation delay and the 

transmission time. 

The coverage model exports the maximum Tx-Rx distance to the MAC sublayer model. 

With only a user population density, the maximum Tx-Rx distance can be used to 

compute the size of the user population. 

5.2.5 Multilink Model 

When the PHY parameters of a wireless link are such that the link is coverage limited, 

the effective coverage can be extended by routing through a sequence of multiple links, 

denoted as a multilink, rather than through a single link alone. The MAC model 

generates performance metrics for single links; the multilink model, on the other hand, 

works interactively with the MAC model to generate end-to-end performance metrics for 

multilinks. 

As illustrated in Figure 4, the multilink model accepts single-link performance metrics as 

input from the MAC model. From them, the multilink model generates the same classes 

of performance metrics for multilinks. The actual sequence of links depends on the pair 

of source and destination nodes and the pair wise link metric between the intermediate 

nodes. Common link metrics are minimum-hop and minimum-airtime. The resultant 

routing topology indicates the routes through which traffic is forwarded through the 

multilinks. 
- 56 -

The routing topology affects links in a different manner. For example, if a link is 

forwarding traffic from multiple sources, it will have a heavier traffic load than 

otherwise. In particular, if the destination of all sources nodes is a single base station or 

access point, links connected directly to the destination will be forwarding traffic from all 

other sources. This translates to a higher offered load λ for these links. The offered load 

of the source is an input to the MAC model from the application requirements. The 

MAC model also accepts the routing topology as input from the multilink model and in 

turn computes the offered load of all links accordingly. 

6 Factors to Consider in Determining Performance 

This section identifies key performance trends and factors that are common to many 

smart grid wireless communication deployments. Among these factors are coverage, 

capacity, interference, and the wireless environment.15 Though these factors by no means 

represent an exhaustive list, they are a subset that will have to be considered in almost 

any deployment. 

Rather than consider every candidate wireless technology in the context of every 

environment and smart grid application that has been catalogued, and given the need to 

produce this report in a timely fashion, examples drawn from the models contributed in 

the Annexes are used to illustrate how these factors can affect whether the application 

requirements of certain use cases can or cannot be met. While these examples are based 

on models of specific technologies and environments, the trends observed and the 

conclusions drawn generally apply to many other wireless technologies and deployment 

scenarios. 

The main conclusions are summarized as follows. 

• There is an inherent tradeoff between wireless coverage and capacity. For example, 

reducing the coverage range of a DAP increases the maximum sustainable load per 

smart meter. However, if interference is severe enough to cause performance loss 

even at low loads, then reducing coverage will not bring any benefit. Also, there is a 

cost associated with reducing coverage, namely a greater number of base stations or 

access points. Conversely, in coverage-limited cases where wireless capacity is 

underutilized, one model is used to illustrate the benefits and limits of extending 

coverage through multi-hop communication. 

• Whether a link is coverage-limited or capacity-limited depends not only on the 

offered load, but also on environmental conditions. In one example using 

representative urban, suburban, and rural environments, the wireless link is shown to 

be coverage-limited in all three environments under average offered load per smart 

meter. However, at peak offered load, the link is capacity-limited in urban and 

 

15 One recognizes that these factors are interdependent. For example, there is a tradeoff between coverage 

and capacity, and both are affected by interference and the propagation environment. 
- 57 -

suburban environments, but remains coverage-limited in a rural environment. Thus, 

the network designer may have to consider the environment carefully, especially 

when designing the link to handle the more infrequent high-load cases. 

• Interference lowers the maximum load per smart meter that can be sustained while 

still satisfying reliability and delay requirements. Furthermore, associated with each 

wireless technology deployment is a maximum tolerable level of interference beyond 

which reliability suffers even at low smart meter loads. 

Quantitative examples supporting these conclusions are provided in the ensuing sections. 

Implicit in their use is the fact that a network designer has to accurately measure the 

environment over a period of time to fully characterize the channel, and that only then 

can one make predictions about how the link will perform. For example, considering the 

interference and the wireless technology’s ability to deal with it will be an important step 

in the design process. Determining the coverage area will also involve design tradeoffs 

that can be made only with an accurate picture of the environment in hand, and as 

projected to change over the life of the deployment. Finally, the network operator must 

make design decisions with future traffic growth in mind. 

It is important to note that the quantitative data used in this section is for illustrative 

purposes only. While the degree to which the environment impacts a particular wireless 

technology depends on the technology itself and how it is implemented, the general 

implications of the environmental effects that will be discussed applies to any wireless 

link-layer technology that could be used to communicate over the link of interest. 

6.1 Performance Metrics and User Application Requirements 

The performance metrics used below directly relate to the user requirements that have 

been compiled for this effort. They include the application throughput, the reliability (i.e. 

the probability that the frame can be successfully sent over the wireless link), and the 

average delay in sending a frame over the wireless link from one node to the next. 

It is important to note that the user requirements are measured at the application layer, 

while the numerical data presented in this section is for the link performance and 

represents only a component of these requirements. Additional protocol and processing 

overheads may introduce additional components that need to be considered. For 

example, the link performance for latency is required to be less than the application 

latency requirement in order to account for the additional delay components and 

processing times introduced by higher layers. 

6.2 The Coverage-Capacity Tradeoff 

There are several factors which may influence the setting of the coverage range by a 

network designer. Typically, a designer wishes to extend the coverage range as much as 

possible, keeping in mind the changing capacity requirements over time. For example in 

the case of the link between a DAP and a smart meter, this enables the DAP to serve the 
- 58 -

greatest number of smart meters. In some other examples, the coverage range may be 

intentionally set lower in order to mitigate interference, conserve power, or increase the 

available capacity per device over time. 

 (a) Uplink throughput per smart meter (b) Downlink throughput with 1 receiver (1Rx) and 

receiver diversity (RxD) 

Figure 11 - Throughput vs. cell radius using model in Annex C 

0 0.5 1 1.5 2 2.5 3

4

6

8

10

12

14

16

18

Cell radius (km)

Aggregate sector throughput (Mb/s)

900 MHz Downlink

900 MHz Uplink

2 GHz Downlink

2 GHz Uplink

0 2 4 6 8 10 12 14 16 18 20 22

4

6

8

10

12

14

16

18

Cell radius (km)

Aggregate sector throughput (Mb/s)

900 MHz Downlink

900 MHz Uplink

 (a) Urban environment (b) Rural environment 

Figure 12 - Average sector throughput vs. cell radius using model in Annex B 

In general, as coverage increases, overall capacity in the coverage area decreases due to 

attenuation of the signal with distance. Furthermore, increasing the coverage area often 

means increasing the number of devices sharing the system capacity, further depressing 

per-device capacity. Numerical examples of this tradeoff in the context of wide area 

network cellular technologies are shown in Figure 11, reproduced here from Annex C, 

and in Figure 12, reproduced from Annex B. These graphs demonstrate the decrease in 

uplink and downlink throughput with increasing cell radius. 

Similarly, in a local or neighborhood area network using carrier sense multiple access 

protocols, an increase in coverage area translates to more stations contending for access 
- 59 -

to the medium. Figure 13 shows results generated using the model in Annex A for the 

meter reading and service switch use cases (i.e., between DAP and smart meter) in a 

suburban environment. The graphs plot throughput per smart meter, reliability, and mean 

MAC sublayer delay versus the offered load per smart meter (measured in application 

bits per second) at three different coverage ranges of the DAP. In each graph, the peak 

and average offered loads per smart meter are indicated by dotted and dash-dotted 

vertical lines, respectively. In addition, dashed horizontal lines indicate a lower limit on 

the reliability (98%) and an upper limit on the delay (5 s). These offered load, reliability, 

and delay thresholds are derived from the use case requirements. In practice, these limits 

would be determined by the network designer based on the smart grid’s operational 

requirements. 

The critical values of the offered load, beyond which the system saturates and the 

performance becomes poor, are the values at which the throughput plot flattens, the 

reliability plot turns downward, and the delay plot jumps from a low unsaturated value to 

a higher saturated value. The results in Figure 13, which demonstrate acceptable 

performance for all three coverage ranges, even at peak offered load, also illustrate the 

coverage-capacity tradeoff. For example, Figure 13(a) shows lower saturation 

throughput levels for larger DAP coverage areas. In other words, as the coverage area 

increases, the sustainable load per smart meter decreases. 

 (a) Throughput (b) Reliability 
- 60 -

 (c) Mean MAC layer delay 

Figure 13 - Performance vs. offered load for various coverage ranges using model in 

Annex A 

Figure 14 - Comparing base station site capacity by frequency reuse 

Another factor that affects capacity in cellular deployments is frequency reuse. A threesector base station with a reuse factor of 3 requires a unique channel to be assigned to 

each sector. This will result in a high channel or sector spectral efficiency since intersector interference is minimized, but this approach requires 3 times as much spectrum. 

With a reuse factor of 1, the same channel is reused in each of the three sectors. While 

inter-sector interference will result in a lower sector or channel spectral efficiency, the net 

site spectral efficiency can be higher in some cases. 

A comparison of frequency reuse factors is made in Figure 14 in terms of downlink DAP 

capacity for an OFDMA-based metropolitan area network, reproduced here from Annex 
- 61 -

E. Comparing reuse 3 with 30 MHz of spectrum to reuse 1 with 10 MHz of spectrum, the 

site capacity is approximately doubled, but at a cost of requiring three times as much 

spectrum. In this example, a frequency reuse factor of 1 provides a net 50% 

improvement in site spectral efficiency compared to reuse 3. 

6.3 Extending Coverage with Multi-Hop Communications 

Wireless deployments for the smart grid may be underutilized in some cases, leading to 

coverage-limited rather than capacity-limited scenarios.16 In order to fully utilize the 

network resources in coverage-limited scenarios, multi-hop communications offers a 

means to extend coverage. 

Multi-hop stations route through one or more relay stations in the network when there is 

no direct link to the base station or access point. However, a consequence of multi-hop 

communication is the buildup of traffic at the relay stations. Besides transmitting their 

own generated traffic, the relays are charged with forwarding traffic from stations routing 

through them. The stations with a direct link to the base station or access point are the 

most heavily taxed, since they must relay for all other stations. Their forwarded traffic 

can be orders of magnitude greater than their own generated traffic. As a result, they are 

the first to reach saturation. As the deployment range increases, so does the amount of 

forwarded traffic through them. At some deployment range, they reach full capacity at 

which point network resources are fully exploited. 

Using the model described in Annex A.4, Figure 15 shows the effect of extending 

coverage with multi-hop communication on a network of smart meters connected to a 

DAP. The graph plots the throughput per smart meter versus the deployment range at 

peak offered load in three different environments: urban, suburban, and rural. At the 

nominal transmission power levels specified in section A.5, the single-hop coverage 

ranges are 113 m, 159 m, and 738 m in the urban, suburban, and rural environments, 

respectively, and are indicated on the plots by vertical dashed lines. 

 

16 See, for example, the analysis in Annex D. 
- 62 -

Figure 15 - Throughput vs. deployment range for various environments using model 

in Annex A.4 

While saturation is reached prior to the single-hop coverage limits in the urban and 

suburban environments—implying a capacity-limited network in those environments—

the rural environment is shown here to be a suitable candidate for multi-hop 

communication. Saturation in the rural environment is reached around 2150 m (note the 

discontinuity in the horizontal axis), which is nearly three times the single-hop range in 

that environment. While this example assumed peak offered load, coverage can be 

extended even further at more typical levels of offered load. 

6.4 The Effect of the Wireless Link Environment 

In the previous section, it was shown that a wireless deployment can be coverage-limited 

in some environments and capacity-limited in others. This section further investigates 

the impact of the RF environment. 

As noted in section 5.2.1, the RF environment affects the degree to which a signal is 

attenuated with distance. In a flat, open area, for example, a signal will typically 

propagate longer distances than in an area with many buildings, mountains and foliage. 

Furthermore, the environment impacts how much the signal will vary from one location 

to another. The greater the variability, the more margin is needed in the link budget to 

maintain a certain reliability. Both attenuation and variability depend on the carrier 

frequency of the signal, as well as the transmitter and receiver antenna heights, and the 

models in section 5.2.1.2 attempt to model these dependencies. 

In order to illustrate the impact on performance of a range of RF environments, three 

representative environments ranging from least challenging to most challenging in terms 

of signal reach and stability were selected. The “rural” environment is relatively benign, 

featuring shallow path loss and low-variance shadowing. The other environments, 

denoted as “suburban” and “urban,” feature steeper path loss and more severe shadowing, 
- 63 -

with the “urban” environment being the worst. The parameter values for these 

environments, corresponding to the channel model in section 5.2.1.1, are summarized in 

Table 8, reproduced here from section A.5. The last row of the table lists representative 

smart meter densities for these environments. 

Table 8 : Channel parameters and smart meter density for rural, suburban, and urban 

environments 

Environment Rural Suburban Urban 

n0 2.1 2.7 3.6 

n1 7.5 N/A N/A 

d1 (m) 650 N/A N/A 

L0 (dB) 38.3 40 21.3 

σ (dB) 2.2 7.4 7.4 

m (Nakagami fading 

parameter) 

 1 1 1 

ρ (smart meters per km2) 10 800 2000 

 (a) Throughput (b) Reliability 
- 64 -

 (c) Mean MAC layer delay 

Figure 16 - Performance vs. offered load for various environments using model 

in Annex A 

The performance of the link between smart meters and a DAP in each of these 

environments was then compared using the model in Annex A. The graphs in Figure 16 

plot throughput, reliability, and delay versus the offered load. As the offered load 

increases, saturation is reached first in the urban environment, followed closely by the 

suburban environment, and finally the rural environment. At the average offered load of 

the meter reading and service switch use cases (denoted by the vertical dash-dotted line), 

the performance requirements (98% reliability and 5 s delay) can be met in all three 

environments in this example. However, under peak load conditions (vertical dotted 

line), these requirements can be met with certainty only in the more benign rural 

environment. In a suburban environment, the network is just barely able to meet the 

reliability and delay requirements. The difference in performance is due to better RF 

propagation characteristics and a lower density of smart meters in the rural environment. 

The results suggest that, under average load conditions, the wireless link is coveragelimited in all three environments in this example. However, under peak load conditions, 

the link is capacity-limited in the urban and suburban environments but remains 

coverage-limited in the rural environment. The implication is that both traffic load and 

type of environment must be considered when assessing the coverage and capacity limits 

of a technology. 

6.5 The Effect of Interference 

An additional factor to consider in almost any wireless deployment is the potential for RF 

interference. The fact that spectrum is often a limited resource necessitates spectral reuse 

where appropriate to increase spectral efficiency. However, as spectral reuse increases, 

the potential for interference also increases. The source of interference can be other 

devices belonging to the same deployment or, in an unlicensed band, belonging to other 

operators. 

In wide-area cellular deployments, carrier frequencies are reused from one cell to 

another. Depending on the level of reuse, inter-cell interference must be managed, 
- 65 -

especially at the cell edge. Another means to increase spectral efficiency is cell 

sectorization, whereby a cell is split into typically three or six sectors. As a result, intersector interference at the sector edges may also need to be managed. 

In local or neighborhood area deployments, the technology may rely on random access to 

a shared channel. Here, the link experiences multiple access interference when two or 

more stations attempt to use the channel at the same time. Mitigation strategies include 

increasing the duration of the backoff window with the number of collisions. 

In general, interference decreases the available link margin. If the margin is degraded 

enough, transmitted frames will be so severely corrupted that they will be unrecoverable 

and will have to be resent. This will in turn reduce throughput, decrease reliability, and 

increase the average frame delay. Whether the interference is inter-cell, multiple access, 

or the result of sharing an unlicensed band, it is important to assess its impact on the 

wireless deployment of interest and, if necessary, employ strategies to mitigate the 

impact. 

 (a) Reliability (b) Mean MAC layer delay 

Figure 17 - Performance vs. offered load for various levels of interference using 

model in Annex A 

To illustrate the impact of interference on performance, the following example considers 

the effect of a constant level of ambient interference on the link. The source of this 

interference might be other cells using the same channel or other wireless users in the 

case of an unlicensed band. 

Using the model in Annex A, Figure 17 illustrates the impact of interference on a 

wireless network connecting smart meters to a DAP. The graphs plot reliability and 

mean delay versus offered load for three values of the ratio of the interference power 

spectral density to the noise power spectral density (I0/N0). Figure 17(a) shows that 

reliability is below the required 98% level even at very low loads under moderate and 

severe interference conditions. At peak load, the reliability is at around 100% when the 

interference is relatively small, but Figure 17 (a) shows that higher loads are 
- 66 -

unsupportable. Moreover, saturation occurs earlier under the highest interference 

conditions than it does when the interference is less severe. 

Figure 17(b) shows the impact on delay. Here, the difference in performance between all 

three interference cases is apparent at low loads. Though the delays are within the limit 

at low loads, as shown in Figure 17(a) the reliability is unacceptably low in two of the 

cases. The moderate and high interference scenarios result in unacceptable delays at peak 

offered load and the low interference scenario results in acceptable performance, but the 

figure shows that the network is at its load limit. 

While the numerical results presented here are specific to the model in Annex A, similar 

effects can be expected to be seen for other wireless technologies. The task for the 

network designer will be to identify the maximum tolerable interference strength for the 

technologies under consideration and determine, based on the ambient interference in the 

deployment environment, which subset of technologies is feasible. One must keep in 

mind that the exact value of the maximum tolerable interference will depend on the 

environment and the wireless technology that the network operator decides to use. 

7 Conclusions 

The goals of PAP 2 are to develop guidelines for the use wireless communications in a 

smart grid environment. To date several milestones have been achieved towards these 

goals and are described in this report. 

The first significant milestone is the development of smart grid application 

communication requirements. While many use cases and scenarios have been described 

in the past, the task undertaken by OpenSG provides comprehensive and detailed sets of 

quantitative user communication requirements capturing different use cases and 

environments. These requirements are tremendously valuable to both the user and 

network technology communities in order to better understand the smart grid landscape. 

The use of these requirements is not only limited to wireless technologies, but they can 

also be used for evaluating any communication technology, be it wireless or wired. 

Another milestone described in this report is a framework to evaluate wireless 

communication technologies. This is a general methodology that helps users and network 

technologists provide answers to the question: how well does wireless technology, X, 

support application requirements, Y? Rather than provide a single answer to this 

question, a framework and a set of tools are provided for users and network technologists 

to help them formulate answers that apply to their own environment. Recognizing that 

every environment is different and every user requirement may pose additional 

constraints and challenges to the network designer, this approach is more useful because 

it is universal. Proof of concept examples are also included in this document in order to 

further illustrate the concepts described and make it easier for users to develop their own 

evaluations. Additional tools and evaluation models developed by different contributors 

are referenced in this document and are available on the NIST PAP 2 collaborative site. 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP02Wireless
- 67 -

Also included in this report are key performance findings that are applicable to most 

environments and wireless technologies. These represent key factors to consider in the 

assessment of wireless technologies such as interference, environment, coverage range, 

and deployment range extension. 

Going forward, this document may be revised as needed in order to include additional 

material contributed by PAP 2 members. Additional material may include examples on 

how to combine security and communication requirements and their implications on 

performance, additional communication requirements and wireless technology evaluation 

examples and models. 
- 68 -

8 References 

ISO/IEC27001 - International Organization for Standardization/International 

Electrotechnical Commission Standard 27001 –Information technology -- Security 

techniques -- Information security management systems -- Requirements 

NIST Special Publication 1108 - NIST Framework and Roadmap for Smart Grid 

Interoperability Standards, Release 1.0, January 2010 

NIST Internal Report 7628 - Guidelines for Smart Grid Cyber Security: Vol. 1, Smart 

Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010 

NIST Internal Report 7628 -Guidelines for Smart Grid Cyber Security: Vol. 2, Privacy 

and the Smart Grid, August 2010 

NIST Internal Report 7628 -Guidelines for Smart Grid Cyber Security: Vol. 3, 

Supportive Analyses and References, August 2010 

9 Bibliography 

[1] SG Network Systems Requirements Specification, v4.0, July 21, 2010. Available 

online at: 

http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Latest_Release_Deliverables/ 
- 69 -

Annex A IEEE 802.11 

Based on the framework described in section 5, this annex presents a model that can be 

used to quantify the performance of an IEEE 802.11 system in a smart grid scenario. It is 

composed of a link traffic model, a physical (PHY) layer model, a medium access control 

(MAC) layer model, and a multilink model, each of which is described below. 

A.1 Link Traffic Model 

The numerical examples of this model used in section 6 are of a hypothetical link 

between a population of smart meters and a DAP. The link is loaded with traffic from 

applications associated with the following two use cases defined in [1]: Service switch 

(SS) and meter reading (MR). The example in section 3.6 translates the application 

requirements for these use cases into a form suitable for traffic modeling. It finds the 

aggregate message arrival rate to be 1.76×10-6 events per electric smart meter (emeter) 

per second on the downlink from the DAP to the smart meter, with an average application 

message size of 25 bytes. On the uplink from the smart meter to the DAP, it finds the 

aggregate arrival rate and average message size to be 9.12×10-5 events/emeter/s and 2133 

bytes, respectively. These data points represent the average offered load in each direction 

of the two-way link. The model described below also permits varying the offered load 

across a continuum. For the purpose of analysis, it is assumed that the sources can be 

modeled as independent Poisson processes. 

A.2 Physical Layer Model 

The probability of failure of a transmission attempt is modeled as the probability that the 

received signal-to-interference and-noise ratio (SINR) is less than a threshold. The 

received SINR is modeled as random due to channel attenuation (fading, shadowing, path 

loss) and interference, both of which are treated as random processes. The SINR 

threshold model for transmission success/failure is based on the observation that for 

block transmissions the block error probability in the absence of fading and shadowing is 

a steep function of the SINR. The model approximates this function as a step function at 

a threshold value of SINR. According to this model, when the actual received SINR—

after accounting for fading, shadowing, and the instantaneous interference power—is less 

than this threshold, the transmission is deemed a failure; otherwise, it is deemed 

successful. The probability of failure jointly accounts for loss due to a weak received 

signal, failure due to collision with other stations, and the possibility of capture in the 

presence of interfering transmissions. Mathematical expressions for the probability of 

transmission failure are detailed in [A2]. 

A.3 MAC Layer Model 

The MAC layer model combines elements of the Bianchi and Zhai models of the IEEE 

802.11 MAC[A3], [A4] to produce an extended MAC layer model for the half-duplex 

channel. This model contains novel elements that allow us to more accurately predict the 
- 70 -

performance of lightly loaded wireless networks that feature bidirectional traffic patterns 

on their links. The principal features of this model are described in detail in [A2]. 

A.4 Multilink Model 

Given a maximum coverage range (described in 5.2.2) and a pair wise link metric 

between nodes, the multilink model described in [A5] generates multilinks between all 

pairs of source and destination nodes. The multilinks are defined through a routing 

topology, i.e. sequences of links between source, intermediate, and destination nodes. 

The routing topology is used to determine the offered loads at all links. The offered loads 

are not only a function of the routing topology, but also a function of the reliabilities of 

the intermediate links. The analysis uses the fact that less-than-perfect reliability results 

in the attrition of the loads over the multilink, so that the total load of the multilink is not 

merely a sum of the contributions of each. 

A.5 Parameters and Assumptions Used in the Numerical Examples 

For the numerical results in section 6, the modeling components described above are used 

to compare the performance of three environments: a rural environment, a suburban 

environment, and an urban environment. The channel parameters and the smart meter 

density associated with the three environments are shown in Table 9. The channel 

parameters based on ground-to-ground links were taken from [A6], [A7], and [A8]. 

Table 9 : Channel parameters and smart meter density for three environments at 2.4 GHz 

Environment Rural Suburban Urban 

n0 2.1 2.7 3.6 

n1 7.5 N/A N/A 

d1 (m) 650 N/A N/A 

L0 (dB) 38.3 40 21.3 

σ (dB) 2.2 7.4 7.4 

n (Nakagami fading) 1 1 1 

ρ (smart meters per 

km2

) 

 10 800 2000 

In Figure 18 outage curves for the three environments are shown. Each curve was 

generated by computing the outage probability for a given coverage range, assuming a 

station Effective Isotropic Radiated Power (EIRP) of 25 dBm. The graph shows that, for 

this range of outage probabilities, the coverage range in the rural environment far exceeds 

that of either the urban or suburban environments. Furthermore, the coverage areas that 

can be achieved in the urban and suburban environments are very close in size, especially 

as the value of the average outage probability decreases. Also shown is that the 

maximum coverage range of the rural environment approaches that of the urban and 

suburban environments as the average outage probability becomes large. However, the 

outage values at which this occurs are large enough to preclude effective communication. 
- 71 -

101102103 10-4

10-3

10-2

10-1

100

Maximum coverage radius, rcoverage (m)

Average outage probability in coverage area

Urban

Suburban

Rural

Figure 18 - Outage curves for three environments at 2.4 GHz (0.1 % outage ranges: 

113 m, 159 m, and 738 m) 

For each environment, the effect of interference and smart meter densities for various 

amounts of offered load per smart meter is examined. For the case where the interference 

to noise ratio was varied, the EIRP was set to 25 dBm. Using this value, the maximum 

coverage range of the DAP for each of the three environments was computed, given an 

outage probability of 0.001. The coverage ranges of 738 m, 159 m, and 113 m for the 

rural, suburban, and urban channels were obtained, respectively. For the smart meter 

densities shown in Table 9, the number of meters that can communicate with a DAP was 

obtained as follows: 

π ρ

2

coverage

1000 ⎟

⎟

⎠

⎞

⎜

⎜

⎝

⎛ = r

N (A-1) 

resulting in N = 17, 64, and 80 for the rural, suburban, and urban environments, 

respectively. 

The values of EIRP = 25 dBm, Pout = 0.001, and their resultant values for rcoverage and N

in each environment, together with an interference ratio of I0/N0 = 10 dB, provide a set of 

nominal PHY parameter values given in Table 10. This nominal set was used to generate 

the numerical results in section 6. Table 11 lists the parameters that are varied from this 

nominal set according to the figure number. 

Table 10 : Nominal PHY parameter values used for the results in section 6. 

Environment Rural Suburban Urban 

EIRP 25 dBm 25 dBm 25 dBm 
- 72 -

Environment Rural Suburban Urban 

Pout 0.001 0.001 0.001 

rcoverage 738 m 159 m 113 m 

N 17 64 80 

I0/N0 10 dB 10 dB 10 dB 

Table 11 : Varied PHY parameters from their nominal values used to generate the 

indexed figures in section 6. 

Parameter varied from its nominal value 

Figure 13 rcoverage = {50, 100, 150} m 

Figure 15 

N varies according to Equation (10-1), however by replacing rcoverage

with rdeployment ; Offered load per Smart Meter = 3.84 kb/s from the 

application. 

Figure 16 N/A 

Figure 17 I0/N0 = {20, 40, 60} dB 

In Table 12 lists the input parameters that were used to implement the PAP2 model of the 

IEEE 802.11 wireless protocol. The MAC layer model was designed to capture some of 

the main features of the IEEE 802.11 half-duplex channel, and allows the user to 

characterize the remote stations (whose role is taken by the smart meters in this study) 

separately from the central access point (whose role is taken by the DAP). In the 

calculations for section 6, the frame arrival rate was varied for the smart meters and the 

DAP, so the arrival rate is not given in this table. 

Table 12 : Input parameters for IEEE 802.11 model (2.4 GHz) 

Parameter Smart Meters DAP 

α (maximum number of retries) 7 7 

K (buffer size in frames) 50 100 

L (application data, bytes) 2133 25 

C (channel data rate, Mb/s) 1.0 1.0 

A.6 References 

[A1] SG Network Systems Requirements Specification, v4.0, July 21, 2010. Available 

online at: 

http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Latest_Release_Deliverables/ 

[A2] Griffith, D., Souryal, M., Gentile, C., and Golmie, N., “An integrated PHY and 

MAC layer model for half-duplex IEEE 802.11 networks,” in Proc. IEEE Military 

Communications Conference (MILCOM), Nov. 2010. 

[A3] Bianchi, G., “Performance analysis of the IEEE 802.11 distributed coordination 

function,” IEEE J. Selected Areas Communications, vol. 18, no. 3, pp. 535–547, 2000. 
- 73 -

[A4] Zhai, H.Q., Kwon, Y.G., and Fang, Y.G., “Performance analysis of IEEE 802.11 

MAC protocols in wireless LANs,” Wireless Communications and Mobile Computing, 

vol. 4, no. 8, pp. 917–931, 2004. 

[A5] Gentile, C., Griffith, D., Souryal, M., and Golmie, N., “Throughput and Delay 

Analysis in Half-Duplex IEEE 802.11 Mesh Networks,” submitted to IEEE Intl. Conf. on 

Communications (ICC), Sept. 2010. 

[A6] Laselva, D., Zhao, X., Meinila, J., Jamsa, T., Nuutinen, J.-P., Kyosti, P., and 

Hentila, L., “Empirical Models and Parameters for Rural and Indoor Wideband Radio 

Channels at 2.45 and 5.25 GHz,” IEEE Intl. Symposium on Personal, Indoor, and Mobile 

Radio Communications, pp. 654-658, Sept. 2010. 

[A7] Xia, H.H., Bertoni, H.L., Maciel, L.R., Lindsay-Stewart, A., and Rowe, R., 

“Microcellular Propagation Characteristics for Personal Communications in Urban and 

Suburban Environments,” IEEE Trans. on Vehicular Technology, vol. 43, no. 3, Aug. 

1994. 

[A8] Matolak, D.W., Remley, K.A., Gentile, C., Holloway, C.L., Wu, Q., and Zhang, 

Q. “Ground-Based Urban Channel Characteristics for Two Public Safety Frequency 

Bands,” Submitted to IEEE Trans. on Antennas and Propagation, Aug. 2010. 
- 74 -

Annex B 3GPP Long Term Evolution (LTE) 

This annex presents an analysis of the 3rd Generation Partnership Project (3GPP) long 

term evolution (LTE) technology for advanced metering applications. 

The analysis below is representative of analyses that can be performed of cellular 

network technologies with scheduled traffic. It is more limited in scope than the model 

of Annex A, focusing on coverage and capacity rather than delay and reliability. 

B.1 Modeling Approach and Assumptions 

The approach to modeling LTE for advanced metering applications, illustrated in Figure 

19, utilizes an analogous, but scaled-down version of the framework of section 5.2. The 

two core components are the coverage analysis and capacity analysis. The coverage 

analysis predicts the maximum coverage radius of a cell, based on a channel propagation 

model and parameters of the LTE deployment. The capacity analysis predicts the overall 

capacity of a sector (in bits per second) and, based on the geographic density of smart 

meters, estimates the average capacity per smart meter. The channel propagation model 

is driven by the deployment environment (e.g., urban, suburban, rural) and is used by 

both the coverage analysis and capacity analysis. 

The analysis assumes that smart meters are randomly and uniformly distributed in the 

cell. A cell is sectorized into three 120o sectors. Inter-sector interference is neglected for 

now, but future work may revisit this point.17

Channel Propagation Model

Coverage 

Analysis

Capacity 

Analysis

LTE Technology Inputs

Deployment Environment Inputs

Max Coverage 

Radius

Capacity per 

Smart Meter (b/s)

Figure 19 - Building blocks of modeling approach 

 

17 With expected traffic load and smart meter deployment densities, channel utilization is anticipated to be 

very low. Low utilization permits fractional reuse of the spectrum whereby traffic in adjacent sectors is 

allocated to non-overlapping time/frequency resources, thereby reducing inter-sector interference. 
- 75 -

The interface to the LTE network may reside directly in the smart meter, in which case 

the smart meter would send data to and receive data from the head end system directly. 

On the other hand, the interface to the LTE network may reside in a Data Aggregation 

Point (DAP) that aggregates traffic from smart meters, likely using a different 

technology, before relaying it to the head end. In the latter case, no aggregation 

efficiencies are assumed in this analysis. 

For the purpose of providing example numerical results, specific values are chosen for 

certain LTE device parameters. These values are summarized in Table 13 and are taken 

from [B1]. In addition, the analysis assumes channel-dependent adaptation of the 

modulation and coding scheme (MCS) and the use of single-input / single-output (SISO) 

antennas. The radiation pattern of the base station (eNodeB) antenna is also taken from 

[B1] and is illustrated in Figure 20. 

Table 13: LTE device parameters 

Base 

Station 

(eNodeB) 

Power per Downlink Traffic Channel 32 dBm 

Peak Antenna Gain 15 dBi @ 2 GHz 

12 dBi @ 900 MHz 

Noise Figure 5 dB 

Terminal 

(UE) 

Transmission Power 24 dBm 

Antenna Gain (omnidirectional) 0 dBi 

Noise Figure 9 dBm 

Bandwidth Downlink 5 MHz 

Uplink 5 MHz 

-180 -150 -120 -90 -60 -30 0 30 60 90 120 150 180

-25

-20

-15

-10

-5

0

Horizontal Angle (degrees)

Gain (dB)

Figure 20 - Radiation pattern of base station (eNodeB) antenna 
- 76 -

B.2 Channel Propagation Model 

Using the recommended channel propagation model in [B1], the path loss (in dB) with 

distance R (km) is modeled by the following equation: 

L = L0 +10nlog10 (R) + X

The values for the reference path loss (L0) and the path loss exponent (n) are given in 

Table 14 for urban and rural environments. The last term, X, is a random component 

representing lognormal shadowing with a standard deviation of 10 dB. 

Table 14 Path loss parameters[B1] 

Environment Carrier frequency L0 n 

Urban Area 900 MHz 120.9 dB 3.76 

2 GHz 128.1 dB 3.76 

Rural Area 900 MHz 95.5 dB 3.41 

With the path loss and device parameters, one can calculate the received power and 

signal-to-noise ratio. The received power Prx (dBm) is obtained as 

Prx = Ptx + Gtx + Arad − L + Grx

where Ptx is the transmission power (dBm), Gtx and Grx are the transmit and receive 

antenna gains (dBi), respectively, and Arad is the base station antenna radiation pattern 

(dB) shown in Figure 20. 

The received signal-to-noise ratio (SNR) per subcarrier symbol (dB) is then given by 

SNR ES N0 Prx N0 10 RS = = − −10log

where RS is the symbol rate (sym/s) and N0 is the power spectral density (p.s.d.) of the 

noise (dBm/Hz). The noise p.s.d. can be calculated from the temperature, T (°K), and the 

receiver’s noise figure, F (dB), as 

N0 = −198.6 +10log10T + F

The received SNR is used in both the coverage and capacity analyses. 

B.3 Coverage Analysis 

The purpose of the coverage analysis is to find the maximum cell radius that satisfies a 

performance criterion. That criterion could be a maximum outage probability, as stated 

in section 5. In this example analysis, the coverage criterion used is that the median 

uplink SNR is at least as high as that required by the lowest, most robust MCS. In 
- 77 -

general, the uplink is more limiting than the downlink because of the uplink’s lower 

transmission power. 

Expressed mathematically, the maximum cell radius is 

Rmax = max{R : SNRUL (R) ≥ γ 0 }

where γ0 is the minimum SNR required to achieve a block error rate of 10-3 when using 

MCS 0. 

Using the channel propagation model described in section B.2 and a value of 2.41 dB for 

γ0, Table 15 lists the resulting maximum cell radii. With all other factors remaining 

equal, the rural cell coverage is larger than the urban cell coverage, and coverage with a 

900 MHz carrier is larger than that with a 2 GHz carrier. 

Table 15: Maximum cell radii 

Environment Carrier frequency Maximum cell radius 

Urban Area 900 MHz 2.7 km 

2 GHz 2.1 km 

Rural Area 900 MHz 20 km 

B.4 Capacity Analysis 

The capacity analysis aims to estimate the total available throughput in a sector, as well 

as the available throughput per smart meter. 

B.4.1 Sector Capacity 

The approach is to evaluate the probability that each MCS is in use and, knowing the data 

rate achievable with each MCS, to use these probabilities to compute the average data 

rate. 

The probability that an MCS is in use can be obtained from the statistics of the received 

SNR. According to the channel model used in this analysis (section B.2), the SNR varies 

with the distance from the base station and with the shadowing on the link. Based on the 

assumptions for these variables, the probability that the SNR lies between the minimum 

SNR value required by a given MCS and the SNR value required by the next higher MCS 

is evaluated. Denoting this probability as PMCS,i, then 

[ ] PMCS ,i = Pr i ≤ SNR < i+1 γ γ . 

The average data rate per resource block achievable in the sector is then computed 

through the following summation over all i: 
- 78 -

= ∑

i

Cavg CMSC,iPMCS,i . 

Here, CMCS,i is the data rate obtained when using MCS i in a resource block. The total 

data rate is Cavg multiplied by the total number of resource blocks. This result assumes 

round-robin scheduling and saturated transmission (data is always available to send) and 

should be viewed as an upper bound on the actual achievable throughput. Actual 

throughput may be lower due to retransmissions and under-utilization of resource 

blocks.18

Example results using the assumptions stated in section B.1 and the sample SNR 

threshold values listed in Table 16 are illustrated in Figure 21 for the urban and rural 

environments. Each graph plots the sector capacity as a function of the cell radius for the 

uplink and downlink. The graph for the urban environment also compares capacity with 

900 MHz and 2 GHz carriers. In all cases, as cell radius increases, capacity decreases 

because a larger fraction of the area experiences lower SNR, necessitating the use of 

lower data rates. 

Table 16: Sample SNR thresholds for each MCS 

MCS 

index 

SNR threshold (dB) MCS 

index 

SNR threshold (dB) 

Uplink Downlink Uplink Downlink 

0 2.41 2.41 15 12.90 12.90 

1 2.97 2.97 16 13.50 13.50 

2 3.63 3.63 17 15.00 14.45 

3 3.86 3.86 18 15.25 15.70 

4 4.47 4.47 19 16.50 15.82 

5 5.31 5.31 20 18.06 16.89 

7 6.81 6.81 21 17.76 17.76 

8 7.65 7.65 22 18.66 18.66 

9 8.45 8.45 23 19.77 19.77 

10 9.07 8.80 24 20.55 20.55 

11 9.27 9.27 25 21.35 21.35 

12 10.25 10.25 26 22.20 22.20 

13 11.23 11.23 27 23.67 23.67 

14 11.79 11.79 28 23.74 23.74 

 

18 For example, resource block efficiency may be reduced to satisfy a delay constraint. 
- 79 -

0 0.5 1 1.5 2 2.5 3

4

6

8

10

12

14

16

18

Cell radius (km)

Aggregate sector throughput (Mb/s)

900 MHz Downlink

900 MHz Uplink

2 GHz Downlink

2 GHz Uplink

0 2 4 6 8 10 12 14 16 18 20 22

4

6

8

10

12

14

16

18

Cell radius (km)

Aggregate sector throughput (Mb/s)

900 MHz Downlink

900 MHz Uplink

(a) Urban environment (b) Rural environment 

Figure 21 - Aggregate sector throughput vs. cell radius 

B.4.2 Available Throughput per Smart Meter 

An estimate of the available throughput per smart meter is obtained by first determining 

the minimum time interval needed between consecutive messages. Then, knowing the 

average message size, the maximum supportable throughput is calculated by taking the 

ratio of the two. 

To determine the minimum time interval needed between consecutive messages, the 

number of transport blocks required to send a message needs to be calculated. Letting Bi

represent the transport block size of MCS i, then the number of transport blocks required 

to send a message of length L bits is 

⎥

⎥

⎤ ⎢

⎢

⎡ =

i

i B

L N . 

For the numerical results below, the average message sizes used are those computed in 

the example in section 3.6 for the meter reading (MR) and service switch (SS) use cases: 

25 bytes on the downlink and 2133 bytes on the uplink. The number of overhead bytes 

per message is assumed to be 42. 

Next, the average number of smart meters in the sector is calculated by: 

3 2 K = ρπRc

where Rc is the cell radius (km) and ρ is the smart meter density (number of meters per 

square kilometer). The factor 1/3 in the denominator is due to sectorization. Table 17 

lists example meter densities for three different deployment environments. 
- 80 -

Table 17: Example meter densities 

Environment Meter density, ρ

Urban area 2000 / km2

Suburban area 800 / km2

Rural area 10 / km2

The average number of transport blocks needed by all K smart meters in the sector to 

send or receive a message is given by 

= ∑

i

N K PMCS,iNi . 

Then, the minimum time interval needed between successive messages, τmin, is obtained 

by taking the ratio of the needed number of transport blocks to the transport block rate of 

the LTE system (i.e., the number of available transport blocks per second): 

TB

MCS,

min R

K P N

i

∑ i i

τ = . 

For example, in a 5 MHz LTE system, the transport block rate, RTB, is 25,000 blocks per 

second. 

Finally, taking the ratio of the application message size to τmin gives an upper bound on 

the application throughput per smart meter. Figure 22 plots the resulting capacity per 

smart meter (maximum application throughput per smart meter) as a function of the cell 

radius for the urban 900 MHz, urban 2 GHz, and rural 900 MHz cases. Interestingly, 

though the aggregate sector capacity is higher in the downlink than the uplink (Figure 

21), the reverse is true for the available capacity per smart meter. The reason is that the 

42-byte overhead represents a much larger percentage of the downlink message size 

(25+42 bytes) than the uplink message size (2133+42 bytes). 

0 0.5 1 1.5 2 2.5 3

102

103

104

105

Cell radius (km)

Available capacity per smart meter (b/s)

900 MHz Uplink

900 MHz Downlink

2 GHz Uplink

2 GHz Downlink

0 2 4 6 8 10 12 14 16 18 20 22 102

103

104

105

Cell radius (km)

Available capacity per smart meter (b/s)

900 MHz Uplink

900 MHz Downlink

 (a) Urban environment (b) Rural environment 

Figure 22 - Capacity per smart meter vs. cell radius 
- 81 -

B.5 References 

[B1] Radio Frequency (RF) system scenarios, 3rd Generation Partnership Project, 

Technical Report 36.942, V8.2.0, June 2009. 
- 82 -

Disclaimer: The information provided in this annex was submitted "as is", with little or 

no review of its contents. Some minor editing (e.g., spelling and formatting) may have 

occurred. 

Annex C 3GPP High Speed Packet Access (HSPA) 

This annex presents an analysis of the 3rd Generation Partnership Project (3GPP) High 

Speed Packet Access (HSPA) technology. The approach to modeling HSPA for 

advanced metering applications is done very much the same as what is described for long 

term evolution (LTE) in Annex B. As such, the primary concentration is on items that 

are specific to HSPA. 

Also, the HSPA analysis is based only on a carrier frequency of 2 GHz as the 

performance at 900 MHz will be better. 

C.1 Modeling Approach and Assumptions 

The analysis assumes that smart meters are randomly and uniformly distributed in the 

cell. A cell is sectorized into three 120o sectors. Inter-sector interference is neglected for 

now, but future work should revisit this point.19

The interface to the HSPA network may reside directly in the smart meter, in which case 

the smart meter would send data to and receive data from the head end system directly. 

On the other hand, the interface to the HSPA network may reside in a Data Aggregation 

Point (DAP) that aggregates traffic from smart meters, likely using a different 

technology, before relaying it to the head end. In the latter case, no aggregation 

efficiencies are assumed in this analysis. 

For the purpose of providing example numerical results, specific values are chosen for 

certain HSPA device parameters. These values are summarized below: 

• Cell radius: Varied from 500 m to 2000 m 

• Carrier frequency: 2 GHz 

• This is the worst case. Performance at 900 MHz will be better. 

• Path loss (dB) = 128.1 + 37.6*Log10dkm. 

• Scenario: Urban 

• Again, this is the worst case in terms of UE density. 

• Other cell interference is ignored 

• PA3 channel (per 3GPP TR 25.896) 

• Linear minimum mean squared error (LMMSE) Receiver w/RxD 

• With 1 Rx antenna, throughput falls by 30%. 

• Lognormal shadowing: Standard deviation = 10 dB 

 

19 With expected traffic load and smart meter deployment densities, channel utilization is anticipated to be 

very low. Low utilization permits fractional reuse of the spectrum whereby traffic in adjacent sectors is 

allocated to non-overlapping time/frequency resources, thereby reducing inter-sector interference. 
- 83 -

• Two dimension (2D) antenna pattern with a 70 degree 3 dB beamwidth (per 3GPP 

TR 25.996) 

• DL antenna gain = 14 dBi 

• Penetration loss = 10 dB 

• Noise figures: 

• UE: 9 dB 

• NodeB: 5 dB 

• Downlink (DL) Single-input / multiple-output (SIMO) simulations (64-QAM 

allowed) 

• Cell throughputs averaged over several drops with fixed user density per 

km2

• Uplink (UL) SIMO simulations (QPSK) 

• The expectation is that UEs to be ON only for a small amount of time. 

Effectively, this will be a Time Division Multiplex (TDM) system. 

• Fixed user density per km2 assumed. 

C.2 Analysis 

An estimate of the average capacity per smart meter is obtained by dividing the total 

sector capacity, Ctotal, by the number of smart meters in the sector. Please note that in 

UL, the Ctotal is constant at 2.5923 Mb/s since a TDM system is assumed. Given the 

number of electric meters per square kilometer (ρ) in a deployment environment, the 

average capacity per smart meter can be calculated as 

 3 2 Rmax

C C total

meter ρπ = . 

The factor 1/3 in the denominator is due to sectorization. Table 18 lists example meter 

densities for three different deployment environments, and Figure 23 shows the cell 

throughput as a function of the cell radius for DL. 

Table 18: Example meter densities 

Environment Meter density, ρ

Urban area 2000 / km2

Suburban area 800 / km2

Rural area 10 / km2
- 84 -

0.5 1 1.5 2 2.5 3 4

6

8

10

12

14

16

18

20

Cell Radius (km)

Cell Throughput (Mbps)

RxD

1Rx

Figure 23 - Cell Throughput as a function of the cell radius for DL 

Figure 24 shows the throughput available per Smart Meter. 

0.5 1 1.5 2 2.5 3 102

103

104

105

Cell Radius (km)

Throughput Available per Smart Meter (Urban) (bps)

RxD

1Rx

0.5 1 1.5 2 2.5 3 102

103

104

Cell Radius (km)

Throughput Available per Smart Meter (Urban) (bps)

Figure 24 - Throughput available per smart meter vs. cell radius for DL (left) and 

UL (right) 

C.3 Capacity-limited and coverage-limited scenarios 

Depending on a given deployment environment, a smart grid system may be capacitylimited or coverage-limited. For example, in a dense urban area where there are many 

high-rise buildings, the system may be capacity-limited. However, in a rural area, a 

coverage limitation may prevail. As such, one must analyze the system based on both 

scenarios. 

C.3.1 Scenario 1: Capacity-limited system 

For this scenario, the maximum number of deployable smart meters is determined given 

the technology’s channel capacity and assuming no limitation on the coverage. The 

maximum number of deployable smart meters per sector is given by 

Ncap = Ctotal λmeter . 
- 85 -

For example, considering a total uplink capacity of Ctotal = 2.5 Mb/s and a smart meter 

throughput of λmeter = 2.5 b/s, one million meters would be required to fully utilize the 

sector’s capacity. 

To assist with this analysis, a spreadsheet (Analysis_Tool.xls) is available at: 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP02Wireless 

C.3.2 Scenario 2: Coverage-limited system 

For this scenario, the number of deployable smart meters that lie within the geographic 

coverage area of a single sector is the starting point. Then the percentage of radio 

channel utilization needed to support the traffic load generated by the meters is 

calculated. Given the geographic density of smart meters, ρ, the number of smart meters 

in a coverage-limited sector is 

 ( 3) 2 Ncov = ρ πRmax . 

To assist with this analysis, a spreadsheet (Analysis_Tool.xls) is available at: 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP02Wireless 

Then, the aggregate load and utilization are given, respectively, by 

λtotal = Ncov λmeter

U = λtotal Ctotal . 

To assist with this analysis, a spreadsheet (Analysis_Tool.xls) is available at: 

 http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP02Wireless 
- 86 -

Disclaimer: The information provided in this annex was submitted "as is", with little or 

no review of its contents. Some minor editing (e.g., spelling and formatting) may have 

occurred. 

Annex D CDMA2000 1x and High Rate Packet Data (HRPD) 

D.1 Introduction 

This annex presents an analysis of the wireless wide area network (WWAN) related 

Smart Grid Interoperability Panel Priority Action Plan 2’s requirements spreadsheet [D1] 

developed by the Open SG User Group. This sheet contains frequency, size, delay 

constraints, and other details about the various messages for some of the use cases in 

smart grid. The analysis looks at all messages from the listed use cases over the WWAN 

segment (between the Data Aggregation Point (DAP) and the advanced metering 

infrastructure (AMI) head end). These cases include meter reading (MR), plug-in hybrid 

electric vehicle (PHEV), service switching (SS), pre-pay metering (PP), and outage 

manage and recovery (ORM). The total amount of forward link (AMI head end to DAP) 

and reverse link (DAP to AMI head end) traffic is computed and compared with the 

system throughput of the cdma2000 1x and HRPD systems. 

D.2 System Model 

This analysis is based on the system model in Figures 1 and 2 of [D2]. In that model, 

there can be multiple (N) customers connected to a DAP which can be connected 

wirelessly to the fixed network containing the AMI head end. Further, one can imagine 

each customer has one electric meter and one gas meter. In this analysis, the actual value 

of N does not affect the end result in general, but one can assume the value of N ranges 

from 1 to 1,000 or even more. It is further assumed that of the N customers, there is a 

certain percentage of commercial/industrial customers. Figure 25 shows the DAP / AMI 

head end segment that is of interest to this analysis. 
- 87 -

Figure 25 - Simplified model of smart grid supported by a cellular network 

Note that the following assumptions were made to make sure the analysis has the largest 

possible load on the WWAN: 

1. There is one electric meter and one gas meter for every customer. However, all 

smart meter messages listed in the spreadsheet are assumed to be to for the 

electric meter unless otherwise specified. 

2. There is one PHEV for every customer. 

3. Fifty percent of the customers are assumed to be commercial or industrial ones, 

and the rest are residential ones. 

4. For use cases where the number of transactions is listed as a range of possible 

value, the largest value is used in the analysis. 

5. Ten percent of all the customers also support additional pre-pay users on their 

meters in addition to the messages sent and received from the other use cases. 

6. To compute the error event reporting message load, the communication error rate 

is assumed to be at 20% and application error 10%. 

7. There is an overhead of 42 bytes in each message as discussed in the next section. 

Figure 26 shows the assumptions made about this model, which includes overhead in 

each transaction (42 bytes). Note that the two bytes per transport layer header is 

somewhat arbitrary, but this should not materially affect the final conclusion. 
- 88 -

Figure 26 - Per transaction overhead of smart grid supported by a cellular network 

Note also that the analysis assumes no bundling of messages at the DAP (for messages 

originating from different meters connected to the same DAP) or the AMI head end (for 

messages intended for meters attached to the same DAP), meaning that each message is 

sent over the cellular network individually, incurring the maximum amount of overhead 

possible. 

D.3 Traffic between DAP and AMI head end 

Table 19 lists the forward link (AMI head end to DAP) messages from the requirement 

[D1] and their total daily load of 1,714,657 bytes (including overhead) for 1,000 

customers (1,000 electric meters, 1,000 gas meters, and 1,000 PHEVs) on the WWAN. 

Table 19: Forward link (AMI head end to DAP) traffic per 1000 customers, worst 

case summary 
- 89 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How 

Often 

App 

Payload 

Size - 

bytes 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

PP-082 AMI Head end 

shall be able 

to process & 

forward any of 

the Pre-pay 

messages (~10 

different 

types) to DAP 

25 trans 

per Prepay mtr 

with Cust. 

EMS per 

month 

50 - 150 83.3 7,667

PP-096 AMI Head end 

shall be able 

to process & 

forward any of 

the Pre-pay 

messages (~10 

different 

types) to DAP 

25 trans 

per Prepay mtr 

with IHD 

per month 

50 - 150 83.3 16,000

PP-110 AMI Head end 

shall be able 

to process & 

forward any of 

the Pre-pay 

messages (~10 

different 

types) to DAP 

25 trans 

per Prepay mtr 

with Cust. 

EMS per 

month 

50 - 150 83.3 16,000

PP-122 AMI Head end 

shall be able 

to process & 

forward a 

cancel service 

switch operate 

request to 

DAP 

1-2 trans 

per 1000 

Pre-pay 

mtrs per 

day 

25 0.2 13

PP-132 AMI Head end 

shall be able 

to process & 

forward a 

service switch 

operate 

request to 

DAP 

1-50 trans 

per 1000 

Pre-pay 

mtrs per 

day 

25 5 335
- 90 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How 

Often 

App 

Payload 

Size - 

bytes 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

PP-141 AMI Head end 

shall be able 

to process & 

forward a 

service switch 

state request to 

DAP 

1-50 trans 

per 1000 

Pre-pay 

mtrs per 

day 

25 5 335

PP-202 Head end shall 

be able to 

process & 

forward ondemand meter 

read requests 

to DAP 

25 trans 

per 1000 

Pre-pay 

mtrs per 

day 

25 2.5 168

Total Load (Bytes per day per 1,000 customers) 1,714,657 

Table 20 shows the reverse link (DAP to AMI head end) messages and their total load of 

27,454,142 bytes per day for 1,000 customers (1,000 electric meters, 1,000 gas meters, 

and 1,000 PHEVs).20

Table 20: Reverse link (DAP to AMI head end) traffic per 1000 meters, worst case 

summary 

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How Often App 

Payload 

Size 

(bytes) 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

MR- 58 Meter reading DAP shall be able to 

forward Smart Meter 

(Gas Commercial) 

multiple-interval-data 

to AMI Head end 

1-6 

trans 

per 

DAPjmgas-C/Imeter 

per day 

1600 - 2400 3000 

 

20 MR-58 is about DAP relaying messages from smart meters to the AMI head end. These relate to MR-32, 

33, 34, and 35, which are labeled as for commercial gas meters, residential gas meters, 

commercial/industrial electric meters, and residential electric meters, respectively. It is assumed that MR32, even though it is labeled as commercial gas meter to DAP, it also represents industrial meter to DAP 

statistics. 
- 91 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How Often App 

Payload 

Size 

(bytes) 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

MR-62 Meter reading DAP shall be able to 

forward Smart Meter 

(Gas Residential) 

multiple-interval-data 

to AMI Head end 

1-6 

trans 

per 

DAPjmgasresdntmeter 

per day 

1600 - 2400 3000 

MR- 66 Meter reading DAP shall be able to 

forward Smart Meter 

(Electric 

Commercial/Industrial) 

multiple-interval-data 

to AMI Head end 

4-6 

trans 

per 

DAPjmelectC/Imeter 

per day 

200 - 1600 3000 

MR- 26 Meter reading DAP shall be able to 

forward Smart Meter 

(Electric Residential) 

multiple-interval-data 

to AMI Head end 

4-6 

trans 

per 

DAPjmelectresdntmeter 

per day 

1600 - 2400 3000 

 Meter reading DAP shall be able to 

process & forward 

multiple interval meter 

reading data (per 

specific meter request 

from MDMS) to AMI 

Head end 

25 trans 

per 

1000 

DAPjmmtrs per 

day 

200 - 2400 25 

MR- 28 Meter reading DAP shall be able to 

report & send "DAP to 

Smart Meter ondemand meter read 

request 

communications 

errors", to AMI Head 

end 

1 trans 

per 

meter 

per x 

ondemand 

cmds 

per time 

period 

50 5 
- 92 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How Often App 

Payload 

Size 

(bytes) 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

MR- 30 Meter reading DAP shall be able to 

process & forward 

Meter on-demand read 

request app errors to 

AMI Head end 

1 trans 

per each 

DAPjmmeters' 

app 

error 

event 

50 2.5 

MR- 31 Meter reading DAP shall be able to 

process & forward ondemand meter read 

data from Smart Meter 

to AMI Head end 

25 trans 

per 

1000 

DAPjmmtrs per 

day 

100 25 

PHEV- 22 PHEV DAP shall be able to 

forward "Send of Price 

Rate (from LM) to 

PHEV" 

communication failure 

to AMI Head end 

1 trans 

per 

1000 

DAPjmPHEVmtrsESInonSMtr 

per day 

50 0.8 

PHEV- 72 PHEV DAP shall be able to 

forward "Send of Price 

Rate (from LM) to 

PHEV" 

communication failure 

to AMI Head end 

1 trans 

per 

1000 

DAPjmPHEVmtrsESISMtr 

per day 

50 3.2 

PHEV- 25 PHEV DAP shall be able to 

forward "negotiate 

Power Charging Rate 

messages (from LMS) 

to PHEV" 

communication failure 

to AMI Head end 

1 trans 

per 

1000 

DAPjmPHEVmtrs per 

day 

50 4 

PHEV- 26 PHEV DAP shall be able to 150 100 150 
- 93 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How Often App 

Payload 

Size 

(bytes) 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

forward negotiate 

Power Charging Rate 

messages (from 

PHEV) to AMI Head 

end 

trans 

per 

1000 

DAPjmmtrs 2-4 

times 

per day 

PHEV- 29 PHEV DAP shall be able to 

forward charging 

status of the PHEV to 

AMI Head end 

150 

trans 

per 

1000 

DAPlmPHEVmtrs 2-4 

times 

per day 

100 600 

PHEV- 30 PHEV DAP shall be able to 

forward PHEV VIN 

information request to 

AMI Head end 

1 trans 

per 

PHEVmtrs 

connect 

per day 

50 4000 

SS- 29 Service 

Switch 

DAP shall be able to 

process & send 

"service switch operate 

request (from CIS, or 

MDMS) 

communications 

failure" with Smart 

Meter, to AMI Head 

end 

1-4 

trans 

per 

1000 

mtrsSWoper per 

day 

50 0.016 

SS- 34 Service 

Switch 

DAP shall be able to 

process & forward 

service switch state 

data to AMI Head end 

1-50 

trans 

per 

1000 

mtrs per 

day 

100 50 

SS- 28 Service 

Switch 

DAP shall be able to 

process & forward 

service switch operate 

1-2 

trans 

per 

25 2 
- 94 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How Often App 

Payload 

Size 

(bytes) 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

acknowledgment to 

AMI Head end 

1000 

mtrs per 

day 

SS- 31 Service 

Switch 

DAP shall be able to 

process & forward 

service switch operate 

operate failure to AMI 

Head end 

1 trans 

per 

1000 

SWoper per 

mtr per 

day 

50 0.016 

SS- 32 Service 

Switch 

DAP shall be able to 

process & forward 

metrology information 

after a successful 

service switch operate 

to AMI Head end 

1-2 

trans 

per 

1000 

mtrs per 

day 

100 2 

PP-152 Pre-pay DAP shall be able to 

process & send 

"service switch operate 

request (from CIS - 

Utility, or MDMS) 

communications 

failure" with Smart 

Meter, to AMI Head 

end 

1-4 

trans 

per 

1000 

Pre-pay 

mtrsSWoper per 

day 

50 0.0008 

PP-162 Pre-pay DAP shall be able to 

process & forward 

service switch state 

data to AMI Head end 

1-50 

trans 

per 

1000 

Pre-pay 

mtrs per 

day 

100 5 

PP-176 Pre-pay DAP shall be able to 

process & forward 

service switch operate 

acknowledgment to 

AMI Head end 

1-2 

trans 

per 

1000 

Pre-pay 

mtrs per 

day 

25 0.2 

PP-185 Pre-pay DAP shall be able to 1 trans 50 0.0002 
- 95 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How Often App 

Payload 

Size 

(bytes) 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

process & forward 

service switch operate 

operate failure to AMI 

Head end 

per 

1000 

SWoper per 

Pre-pay 

mtr per 

day 

PP-191 Pre-pay DAP shall be able to 

process & forward 

metrology information 

after a successful 

service switch operate 

to AMI Head end 

1-2 

trans 

per 

1000 

Pre-pay 

mtrs per 

day 

100 0.2 

PP-213 Pre-pay DAP shall be able to 

report & send "DAP to 

Smart Meter ondemand meter read 

request 

communications 

errors", to AMI Head 

end 

1 trans 

per Prepay 

meter 

per x 

ondemand 

cmds 

per time 

period 

50 20 

PP-225 Pre-pay DAP shall be able to 

process & forward ondemand meter read 

data from Smart Meter 

to AMI Head end 

25 trans 

per 

1000 

DAPjmPre-pay 

mtrs per 

day 

100 2.5 

PP-244 Pre-pay DAP shall be able to 

process & forward 

Meter on-demand read 

request app errors to 

AMI Head end 

1 trans 

per each 

DAPjmPre-pay 

meters' 

app 

error 

event 

50 0.25 

ORM-03 ORM DAP shall be able to 100 25 1 
- 96 -

Requirement 

Reference 

Requirements 

(assumed 

electric unless 

noted 

otherwise) 

How Often App 

Payload 

Size 

(bytes) 

Transactions 

per 1,000 

customer 

per day 

Traffic 

(including 

overhead) 

per 1,000 

customer 

per day 

send outage 

notifications to AMI 

Head end from Smart 

Meters 

percent 

of 

meters 

that lose 

power 

per day 

ORM-14 ORM DAP shall be able to 

send power restoration 

notifications to the 

AMI Head end from 

Smart Meters 

100 

percent 

of 

meters 

that 

returned 

to 

power 

per day 

25 1 

ORM-24 ORM DAP shall be able to 

send a notification 

when DAP running on 

battery power AMI 

Head end 

20 per 

1000 

DAP 

per 

system 

power 

outage 

event 

per day 

25 0.02 

Total Load: bytes per day per 1,000 customers 27,454,152

D.4 Number of Meters in a CDMA2000 1x or HRPD Sector 

Using a site-to-site (base station to base station in a regularly spaced deployment) 

distance in [D4] of 2 km, one can compute the area of a given sector of a base station as 

approximately 1,154,701 m2

. If there are one thousand customers in this sector, one can 

arrive at a 1154.7 m2

 average area per customer. If there are M thousand customers, then 

the per-customer area is 1,155/M m2

. 

D.5 CDMA2000 1x and HRPD System Throughput 

The actual throughput of the cdma2000 system in a sector over a 1.25 MHz bandwidth 

RF carrier depends on many factors. Using the relatively large cell sizes in [D4] together 

with a mix of Rayleigh and Rician fading assumption for each of the terminals, [D5] has 
- 97 -

a set of HRPD throughput results without using multiple-input / multiple-output 

(MIMO): 

• Forward link: 1.733 Mb/s to 2.08 Mb/s 

• Reverse link: 1.26 Mb/s to 2.35 Mb/s. 

Under a similar setting, [D6] and [D7] list the forward link throughput of cdma2000 1x in 

for 3 km/hr fading, which is expected to be less than the additive white Gaussian noise 

(AWGN) throughput which is more typical of the smart grid DAPs’ environments: 

• Forward link: 1.763 Mb/s to 1.845 Mb/s 

Separately, [D8] lists the reverse link throughput simulated by Ericsson, LG Electronics, 

Nokia, Nortel, Samsung, and Qualcomm under a relatively lightly loaded condition of 

less than 5 dB of total reverse link received power above no-load level (“rise-overthermal”). 

• Reverse link: 530 kb/s to 647 kb/s 

Table 21 compares the demand from the smart grid use cases from 1,000 customers to the 

system throughput in 1.25 MHz carrier. One can easily see that these load levels are such 

a small percentage of the possible capacity of the cdma2000 1x and downlink only (DO) 

systems, that these two systems can support many thousands of customers per sector 

without problems. 

Table 21: Smart grid use case demand versus CDMA2000 system throughput 

 Smart Grid 

Demand per 1,000 

Customers (b/s) 

CDMA2000 1x System 

Throughput (b/s) 

CDMA2000 HRPD 

System Throughput 

(b/s) 

Forward Link 159 1,763,000-1,845,000 1,733,000 - 2,080,000 

Reverse Link 2,542 530,000-647,000 1,260,000 - 2,350,000 

D.6 Conclusion 

The analysis shows that the total amount of forward link and reverse link traffic 

generated by these three use cases is very small compared with the system throughput of 

either the cdma2000 1x or HRPD system. 

D.7 References 

[D1] “SG-Network functional requirements spreadsheet, Version 3.0,” 

http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Interium_Release_3/

[D2] “SG Network System Requirements Specification Interim Release 3,” May 17, 

2010, 

http://osgug.ucaiug.org/UtiliComm/Shared%20Documents/Interium_Release_3/ 
- 98 -

[D3] “Working draft of Guidelines for using wireless communications,” 

http://collaborate.nist.gov/twikisggrid/pub/SmartGrid/PAP02Wireless/NIST_Priotity_Action_Plan_2_r04.pdf

[D4] “cdma2000 Evaluation Methodology,” 3rd Generation Partnership Project 2, 

3GPP2 C.R1002-B, http://www.3gpp2.org/Public_html/specs/C.R1002-

B%20v1.0_Evaluation_Methodology.pdf

[D5] “UHDR-DO Overview,” Qualcomm Incorporated contribution to 3GPP2 TSG-C 

Working Group 3, C30-20060626-031R1, 

ftp://ftp.3gpp2.org/TSGC/Working/2006/2006-06-MiyazakiJapan/TSG-C-2006-

06-Miyazaki%20-%20Japan/WG3/C30-20060626-031R1_QCOM_UHDRDO_update.pdf

[D6] “Results of L3NQS Simulation Study,” joint contribution from LG Electronics, 

Lucent Technologies, LSI Logic, Nortel Networks, Qualcomm Incorporated, and 

Samsung Electronics to 3GPP2 TSG-C Working Group 5, C50-20010820-011, 

August 20, 2001, ftp://ftp.3gpp2.org/TSGC/Working/2001/TSG-C_0108/TSG-C0801-Portland/WG5/C50-20010820-011-

Results%20of%20L3NQS%20Simulation%20Study.pdf

[D7] “System Simulation Results for the L3NQS Framework Proposal for cdma2000 

1x-EVDV,” joint contribution from LG Electronics, Lucent Technologies, LSI 

Logic, Nortel Networks, Qualcomm Incorporated, and Samsung Electronics to 

3GPP2 TSG-C Working Group 5, C50-20010820-012, August 20, 2001, 

ftp://ftp.3gpp2.org/TSGC/Working/2001/TSG-C_0108/TSG-C-0801-

Portland/WG5/C50-20010820- 

012%20L3NQS%20System%20Simulation%20Results.pdf 

[D8] “Summary of system-level simulation results presented by various companies for 

Rev-D development,” Qualcomm Incorporated contribution to 3GPP2 TSG-C 

Working Group 3, C30-20030812-062, August 12, 2003, 

ftp://ftp.3gpp2.org/TSGC/Working/2003/2003-08-Seoul/TSG-C-2003-08-

Seoul/WG3/WG3%20Call,%202003.08.12/C30-20030812-062- 

Summary_system_simulation_results.doc 
- 99 -

Disclaimer: The information provided in this annex was submitted "as is", with little or 

no review of its contents. Some minor editing (e.g., spelling and formatting) may have 

occurred. 

Annex E IEEE 802.16/WiMAX Network 

In this annex it is shown how some of the models and deployment considerations 

described in sections 5 and 6 apply to smart grid solutions based on the IEEE 

802.16/WiMAX technology. In the analysis that follows, it is important to recognize that 

some of the parameters that comprise the system gain, a key component of the link 

budget, are vendor or equipment-specific. The values used for the analysis that are 

representative. 

Figure 27, shows the range projections in the 1800 MHz band based on the modified Hata 

path loss model considering the different usage models described in section 5.2.2. A 

10 dB fade margin is assumed for each of the usage models and the assumed receiver 

sensitivity is consistent with a cell-edge downlink (DL) channel data rate of 

approximately 3 Mb/s. Assumptions for other key device parameters for each of the 

usage models are as follows: 

• Fixed Outdoor Subscriber Station (Fxd OD SS): 

o SS Antenna Gain = 14 dBi 

o SS Antenna Height = 10 m 

• Vehicular-Installed Mobile Station (Veh-Ins MS): 

o MS Antenna Gain = 8 dBi 

o MS Antenna Height = 2 m 

• Fixed Indoor Subscriber Station (Fxd ID SS): 

o SS Antenna Gain = 6 dBi 

o SS Antenna Height = 2.5 m 

o Building Penetration Loss = 10 dB 

• Mobile Hand-Held Subscriber Station (Mob HH SS): 

o SS Antenna Gain = -1 dBi 

o SS Antenna Height = 1.5 m 

o SS Transmit Power = 200 mW 

o Building Penetration Loss = 10 dB 
- 100 -

Figure 27 - Range and usage models 

The range projections in Figure 27 can be used to provide some insights as to how the 

IEEE 802.16/WiMAX technology can apply to the backhauling of Data Aggegation 

Points (DAPs), a key requirement for a smart grid wide area network (WAN). It is 

anticipated that DAPs can be strategically deployed to take advantage of a reasonably 

high antenna height. This can be achieved by mounting the DAP antennas on existing 

utility poles, substation structures, etc. As seen from the previous analysis and the 

applicable channel models, the elevated antenna height can dramatically enhance the base 

station range and coverage. The following charts show the number of DAPs that fall 

within the projected base station coverage area for different DAP densities that might be 

encountered in urban or suburban environments. If a typical DAP were to support 500 to 

1000 Smart Meters (SMs), 20 DAPs per km2

 would represent 10,000 to 20,000 SMs per 

km2

, an SM density consistent with many high population urban centers. 

Although DAPs may represent the majority of actors to be covered with a smart grid 

WAN, there will, in most cases, be other actors as well. Video surveillance sites, for 

example, may be deployed throughout the same coverage area along with connections to 

emergency vehicles, remote offices, etc. 

With the anticipated DAP densities and other smart grid actor sites, urban area 

deployments, especially in the lower frequency bands with limited spectrum, are likely to 

be capacity-constrained vs. range-constrained. 
- 101 -

Figure 28 - Urban area DAP coverage

SM and DAP densities in suburban areas will be considerably less but with the increased 

range capability and the inclusion of other smart grid actors, deployments in frequency 

bands below 1000 MHz may still be capacity-constrained. 

Figure 29 - Suburban area DAP coverage 
- 102 -

Figure 30 - Cluster of 19 three-sector base stations used for evaluation 

Another important step in the technology assessment process is an analysis of channel, 

sector, and site capacity to ensure that the deployment meets requirements for the 

applications envisioned for the smart grid. The amount of available spectrum and 

whether it is shared with other applications, as would be the case in the license-exempt 

bands, or is uniquely allocated for smart grid is a key consideration. Whether licensed or 

un-licensed it is safe to assume that spectrum will always be at a premium making it 

important to consider spectral efficiency in the assessment of the alternative technologies 

for a WAN. Channel, sector and site capacity, and spectral efficiency for IEEE 

802.16/WiMAX and other wireless technologies can be evaluated using an approach 

accepted by the IEEE 802.16 Working Group [E1] and ITU-R. This methodology, 

widely used to evaluate WiMAX/802.16 and long term evolution (LTE) solutions, 

assumes a cluster of 19 three-sector base stations (see Figure 30) in a range of 

deployment scenarios assuming 10 active users per sector. The methodology takes into 

account mobility (pedestrian and/or vehicular), multipath, inter-base station handoff, 

reuse factor, etc. Base station spacing is either 0.5 km or 1.732 km to reflect a micro or 

macro-cellular deployment. 
- 103 -

Figure 31 - Comparing base station site capacity and reuse 

The frequency reuse factor plays a key role in determining net site spectral efficiency. A 

three-sector base station with a reuse of three requires a unique channel to be assigned to 

each sector. This will result in a high channel or sector spectral efficiency since intersector interference is minimized, but this approach requires three times as much 

spectrum. With reuse factor of one, the same channel is reused in each of the three 

sectors as shown in Figure 30. While inter-sector interference will result in a lower 

sector or channel spectral efficiency the net site spectral efficiency will be higher. 

Orthogonal Frequency Division Multiple Access (OFDMA) based IEEE 802.16/WiMAX 

solutions can support a reuse of one. With OFDMA inter-sector and inter-cell co-channel 

interference is managed through the use of different subcarrier permutation zones [E2]. 

This is typically referred to as fractional frequency reuse. 

Figure 31 shows the available payload per DAP for a typical IEEE 802.16/WiMAX 

deployment assuming a three-sector base station, 10 MHz Time Division Duplex (TDD) 

channels with a DL to uplink (UL) ratio of one with either 10 MHz or 30 MHz of 

available spectrum21. Comparing reuse three with 30 MHz of spectrum to reuse one with 

10 MHz of spectrum the site capacity is approximately doubled, but at a cost of requiring 

three times as much spectrum. A frequency reuse factor of one provides a net 50% 

improvement in site spectral efficiency compared to reuse of three. 

The above analysis is highly simplified in that it only looks at one aspect of a smart grid 

deployment, namely that of backhauling DAPs. Obviously a more detailed analysis 

would be necessary for a complete technology assessment with respect to capacity and 

coverage. The inclusion of additional actors and usage models, especially those with 

high capacity requirements such as video surveillance, would be required for a more 

complete study. There may also be a need to assess performance in other frequency 

 

21 Results would be similar for FDD with a 5 MHz DL channel and a 5 MHz UL channel 
- 104 -

bands, other channel bandwidths, etc. Other technology attributes must also be taken into 

account for a full smart grid suitability assessment. Latency, security, cell edge 

performance, quality of service (QoS), support for multi-casting, and location-basedservices (LBS), etc. are all important to varying degrees when considering all the 

applications planned or envisioned for the smart grid network. 

Nevertheless, the above examples based on the IEEE 802.16/WiMAX Network 

technology provide insights as to how the models described in section 5 can be utilized in 

assessing the suitability of the technology for a smart grid wide area network. 

E.1 References 

[E1] IEEE 802.16m Evaluation Methodology Document, IEEE 802.16m-08/004r5 

<http://ieee802.org/16/tgm/core.html#08_004> 

http://ieee802.org/16/tgm/docs/80216m-08_004r5.zip. 

[E2] Mobile WiMAX – Part I: A Technical Overview and Performance Evaluation, 

August 2006