September 2010

Bruce Kraemer, Marvell

Slide 1

doc.: IEEE 802.11-10/0955r5

Submission

Smart Grid Technology Summer 2010 Plans

Date: 2010-September-01Abstract: Discussion PAP#2 Report

Name Company Address Phone emailBruce Kraemer Marvell 5488 Marvell Lane,

Santa Clara, CA, 95054+1-321-751-3988 bkraemer@marvell.com

Jorjeta Jetcheva Itron

September 2010

Bruce Kraemer, Marvell

Slide 2

doc.: IEEE 802.11-10/0955r5

Submission

Call Agenda

• Comments on the content of the NIST PAP#2 report, r5.

• R5 was posted at:• http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/

PAP02Wireless/NIST_Priority_Action_Plan_2_r05.pdf

• Other items?

September 2010

Bruce Kraemer, Marvell

Slide 3

doc.: IEEE 802.11-10/0955r5

Submission

NIST Timeline

Release of draft 0.6

Release of Version 1

Draft 0.5July 28, 2010

Call for Input to Section 6August 4, 2010

End of draft 0.5 review periodSeptember 15, 2010

December 3, 2010

November 4, 2010

SGIP face-to-face, ChicagoPAP 2 meeting

OpenSG meeting, MiamiTentative PAP 2 meeting

SGIP face-to-face, St LouisTentative PAP 2 meeting

September 16, 2010

End of draft 0.6 review period

September 30, 2010

October 29, 2010

September 2010

Bruce Kraemer, Marvell

Slide 4

doc.: IEEE 802.11-10/0955r5

Submission

NIST Expectations

• Release 0.6 contains mature contents for all sections• Minor changes are expected between release 0.6 and

1.0 to allow for NIST internal review process• Technical contributions in the form comments to

current draft and/or new material shall be posted on the twiki and made publicly available

• Technical contributions will be processed as they are received up to the end of the review period– Allow time to provide comment resolution and reach consensus

prior to the close of the review period.

September 2010

Bruce Kraemer, Marvell

Slide 5

doc.: IEEE 802.11-10/0955r5

Submission

Next NIST PAP 2 meetings

• SGIP meeting in St Louis, September 16, 2010?– Is there a need for a PAP 2 meeting?

• Co-located with OpenSG meeting, November 4, 2010, Miami FL.

• SGIP meeting, December 1-3, 2010, Chicago, IL

September 2010

Bruce Kraemer, Marvell

Slide 6

doc.: IEEE 802.11-10/0955r5

Submission

• Discussion topics for September 01 call.

September 2010

Bruce Kraemer, Marvell

Slide 7

doc.: IEEE 802.11-10/0955r5

Submission

Comment #01

• Section 4.2.1.3 talks about Coverage Area. It is important to discuss coverage in conjunction with data rates and link margin for example, in order to avoid associations between inconsistent pieces of information, e.g., citing the largest coverage area achievable by a given technology along with the highest data rate achievable by the technology is incorrect – generally the two have a reverse relationship and the highest coverage is achievable at the lowest data rate.

• Suggested text change:• Add the following text at the end of Section 4.2.1.3: When

comparing coverage areas between different technologies, 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.

September 2010

Bruce Kraemer, Marvell

Slide 8

doc.: IEEE 802.11-10/0955r5

Submission

Comment #02

• Section 4.2.1.4 talks about Mobility. It would be useful to mention the data rates achievable at various mobility levels to avoid assumptions that mobile devices can communicate at the highest data rates used by a specific technology.

• Suggested text change:• Add the following text at the end of Section 4.2.1.4: Comparisons

between the capabilities of different mobile technologies have to take into account the maximum data rate achievable at each mobility level -- mobile devices may not be able to communicate at the highest available data rates.

September 2010

Bruce Kraemer, Marvell

Slide 9

doc.: IEEE 802.11-10/0955r5

Submission

Comment #03

• Section 4.2.1.5 talks about Data Rates. • Suggested text change:• Add the following text at the end of Section 4.2.1.5: Additional factors to consider

when discussing data rates:• Throughput must be considered in conjunction with packet size, coverage range

and rate of mobility (if any). • It is important to distinguish between unicast, multicast and broadcast rates, as

they may not be the same for a given wireless technology. • Throughput depends on medium access scheduling, including the capability to

provide block transmissions (whereby multiple data packets can be sent in succession with minimum or no individual medium access operations per packet except before the first packet is sent), and/or block acknowledgements (whereby a single acknowledgement packet can acknowledge multiple preceding data packets). The capability and flexibility to optimize block transmissions and acknowledgements can have a significant effect on GoodPut.

• The use of rate adaptation mechanisms, where the data rate on a link is reduced when the quality of the link degrades and increased otherwise, which results in higher throughput than using a constant data rate.

September 2010

Bruce Kraemer, Marvell

Slide 10

doc.: IEEE 802.11-10/0955r5

Submission

Comment #04

• Section 4.2.1.6 talks about RF utilization. • Suggested text change:• Add the following text at the end of Section 4.2.1.6:

– Consider the power level regulations for the different channels used by a particular technology, e.g., some Unlicensed National Information Infrastructure (UNII) channels at 5GHz have lower maximum allowed power levels from the maximum allowed for unlicensed band operation.

– Consider the impact of Dynamic Frequency Selection (DFS) regulations on the channels used by a particular technology, e.g., certain UNII channels are subject to DFS regulation which requires wireless devices to change channel when they detect the use of radar on their current channel.

September 2010

Bruce Kraemer, Marvell

Slide 11

doc.: IEEE 802.11-10/0955r5

Submission

Comment #05

• Section 4.2.1.7 talks about Data Frames and Packets. It is important to consider frame duration in conjunction with data rate and size of the frame. Also, we need to consider multicast and broadcast frames in addition to unicast frames.

• Suggested text change:• Modify item “a)” in Section 4.2.1.7 as follows:• What is the maximum frame duration for a unicast, multicast and

broadcast frame respectively, and what are the corresponding frame size and data rate at which each type of frame was sent?

• Modify item “b)” in Section 4.2.1.7 as follows:• What is the maximum packet size that can be sent in one unicast,

multicast and broadcast radio frame respectively?• Modify item “c)” in Section 4.2.1.7 as follows:• Does the radio system support segmentation of unicast, multicast and

broadcast packets respectively, when the payload size exceeds the capacity of one radio frame?

September 2010

Bruce Kraemer, Marvell

Slide 12

doc.: IEEE 802.11-10/0955r5

Submission

Comment #06

• Section 4.2.2.4 talks about Connection Topologies. The Bus and Ring topology need to be removed, they are not wireless topologies. One way to characterize wireless topologies is as single hop and multi-hop (statically configured or mesh), and wireless links as point-to-point, point-to-multipoint, and omnidirectional. We need to add figures that correspond to the text we end up with.

• Suggested text change:• Remove the Bus and Ring figures, re-label the Star figure as “Point-to-

Multipoint Link”, re-label the Mesh figure as “Mesh Network Topology” and replace the current text in Section 4.2.2.4 with the following: Wireless network topologies can be divided into single hop and multi-hop, where a multi-hop topology can be statically configured, or can be dynamic and self-forming, e.g., a mesh. A wireless link can be point-to-point, point-to-multipoint, or omnidirectional.

September 2010

Bruce Kraemer, Marvell

Slide 13

doc.: IEEE 802.11-10/0955r5

Submission

Comment #07

• Section 4.2.2.5 talks about Connection Management. The section needs to mention what aspects of “connection management” can be used to compare different wireless technologies. For example, we can evaluate the latency to join a network, available security mechanisms employed when joining a network, and overhead to join the network (number of control packets exchanged). Perhaps section titles such as “Network Participation Mechanisms” or “Joining the Network” are more descriptive of the content of this section.

• Suggested text change:• Add the following text at the end of Section 4.2.2.5: It is important to

evaluate the time it takes for a device to join a particular network, and the overhead required to do so, along with the overhead required to maintain membership in the network after the initial admission into the network. Also to be considered is the overhead associated with optimizing connectivity, e.g., in mesh-based topologies.

September 2010

Bruce Kraemer, Marvell

Slide 14

doc.: IEEE 802.11-10/0955r5

Submission

Comment #08

• Section 4.2.3.2 talks about Location Characterization. It seems like many of the techniques applicable to this section are not technology-specific but implementation-specific and as such can be incorporated across different wireless technologies even if they are not currently incorporated into the products of a specific wireless technology. It would be helpful to make the distinction between technology-specific properties and product-specific properties in the text.

• Suggested text change:• Add the following text at the end of Section 4.2.3.2: It is

important to distinguish between technology-specific location characterization mechanisms and those that are applicable across technologies or communication topologies, and can easily be added to products that may not currently support them.

September 2010

Bruce Kraemer, Marvell

Slide 15

doc.: IEEE 802.11-10/0955r5

Submission

Comment #09

• A category that is missing from Section 4 is one that characterizes the deployment complexity of each technology. I have some initial proposed text below but I would like to solicit the group’s input on how to characterize deployment complexity in a measurable way.

• Suggested text change:• Add the following text after Section 4.2.4.1: • 4.2.5 Group 22: Deployment Complexity • It is important to evaluate the complexity of installing, and

maintaining a given wireless system, including ease of integration with other, possibly existing, networks, and augmenting the wireless network footprint over time.

September 2010

Bruce Kraemer, Marvell

Slide 16

doc.: IEEE 802.11-10/0955r5

Submission

Comment #10

• It might be helpful to have some tables and text summarizing the information in Section 5, and to move a lot of the discussions/derivations to an appendix. Otherwise, the message/conclusions/recommendations get lost in the text.

September 2010

Bruce Kraemer, Marvell

Slide 17

doc.: IEEE 802.11-10/0955r5

Submission

Comment #11

• Section 4.2.1.2 (p. 24) talks about voice and video traffic over the smart grid. I think that we need more use cases motivating why we would want to have voice and video traffic over the smart grid network. The only video example given in the text is one of surveillance of affected outage areas. It would seem that voice and video might be of lower priority during outages, e.g., caused by disasters or weather-related events, since the network would require a high degree of availability for its regular functions. In addition, surveillance is generally part of the public safety infrastructure and there is spectrum allocated for such use so I am not convinced that we should be discussing this kind of application in the context of the smart grid.

• Applications such as voice and video have requirements that even broadband network providers are struggling with (wireless and landline) and making them part of the smart grid infrastructure requires significant justification.

September 2010

Bruce Kraemer, Marvell

Slide 18

doc.: IEEE 802.11-10/0955r5

Submission

New text for August 18 Telecon

New text for August 25 Telecon

September 2010

Bruce Kraemer, Marvell

Slide 19

doc.: IEEE 802.11-10/0955r5

Submission

Peter Ecclesine comments – Aug 11== Prepared definitions• Definition of Packet Radio should be removed.• Rate adaptation should be replaced by Link adaptation, including changing Modulation, Coding Scheme, smart antennas,

hopping patterns, http://en.wikipedia.org/wiki/Link_adaptation

• Link adaptation from Wikipedia, the free encyclopedia• Link adaptation, or adaptive coding and modulation (ACM), is a term used in wireless

communications to denote the matching of the modulation, coding and other signal and protocol parameters to the conditions on the (e.g. the pathloss, the interference due to signals coming from other transmitters, the sensitivity of the receiver, the available transmitter power margin, etc.).

• For example, EDGE uses a rate adaptation algorithm that adapts the modulation and coding scheme (MCS) according to the quality of the radio channel, and thus the bit rate and robustness of data transmission. The process of link adaptation is a dynamic one and the signal and protocol parameters change as the radio link conditions change -- for example in HSDPA in UMTS this can take place every 2 ms.

• Adaptive modulation systems invariably require some channel state information at the transmitter. This could be acquired in time division duplex systems by assuming the channel from the transmitter to the receiver is approximately the same as the channel from the receiver to the transmitter. Alternatively, the channel knowledge can also be directly measured at the receiver, and fed back to the transmitter. Adaptive modulation systems improve rate of transmission, and/or bit error rates, by exploiting the channel state information that is present at the transmitter. Especially over fading channels which model wireless propagation environments, adaptive modulation systems exhibit great performance enhancements compared to systems that do not exploit channel knowledge at the transmitter.

September 2010

Bruce Kraemer, Marvell

Slide 20

doc.: IEEE 802.11-10/0955r5

Submission

Link adaptation - Continued from Wikipedia

• An Example of Link Adaptation• In HSDPA link adaptation is performed by:• choice of modulation type -- the link can employ QPSK for noisy channels and 16QAM for

clearer channels. The former is more robust and can tolerate higher levels of interference but has lower transmission bit rate. The latter has twice higher bit rate but is more prone to errors due to interference and noise hence it requires stronger FEC (forward error correction) coding which in turn means more redundant bits and lower information bit rate; choice of FEC -- the FEC code used has a rate of 1/3, but it can be varied effectively by bit puncturing and HARQ with incremental redundancy. When the radio link conditions are good more bits are punctured and the information bit rate is increased. In poor link conditions all redundant bits are transmitted and the information bit rate drops. In very bad link conditions retransmissions occur due to HARQ which ensure correct reception of the sent information but further slow down the bit rate.

• Thus HSDPA adapts to achieve very high bit rates, of the order of 14 megabit/s, on clear channels using 16-QAM and close to 1/1 coding rate. On noisy channels HSDPA adapts to provide reliable communications using QPSK and 1/3 coding rate but the information bit rate drops to about 2.4 megabit/s. This adaptation is performed up to 500 times per second.

September 2010

Bruce Kraemer, Marvell

Slide 21

doc.: IEEE 802.11-10/0955r5

Submission

Peter Ecclesine comments – Aug 11

== Prepared definitions• == Definitions to refine or remove: • (unused) Generally Accepted Privacy Principles – include

Web accessed groups like Truste and Better Business Bureau. (look at AT&T and Verizon Privacy Web pages)

• http://www22.verizon.com/privacy/• http://www.att.com/gen/privacy-policy?pid=2506• How to use the references??

• Web Portal

September 2010

Bruce Kraemer, Marvell

Slide 22

doc.: IEEE 802.11-10/0955r5

Submission

Needs more development

• Section 5.1.1 Indoor-indoor radio propagation models• There should be a 5.1.2 with indoor-indoor noise

including basement/garage woodworking tools, sheetmetal shop, garage door opener, washer/dryer, hair-dryer, etc. Let there be man-made noise or our models work in a vacuum.

September 2010

Bruce Kraemer, Marvell

Slide 23

doc.: IEEE 802.11-10/0955r5

Submission

PAP#2 _ Report_r5 –Preface Para 2

• 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 specificity 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 used to assess the suitability of various wireless technologies to meet the requirements in the particular applications environment.

September 2010

Bruce Kraemer, Marvell

Slide 24

doc.: IEEE 802.11-10/0955r5

Submission

Para 2 Recommended change• Reword to incorporate the idea that SG application requirements

evolve over time, yielding to experience rather than remain locked in 1989 or 1999 or 2009 economics.

• Smart Grid application requirements must be defined with enough specificity to quantitatively define communications traffic and levels of performance over the lifetime of the applications.  Applications requirements must be combined with as complete a set of management and security requirements for the life-cycle of the equipment.  The decisions to apply wireless for any given set of applications can then be based on expected performance and costs over the projected useful lifetimes of the spectrum and equipment. 

September 2010

Bruce Kraemer, Marvell

Slide 25

doc.: IEEE 802.11-10/0955r5

Submission

Peter Ecclesine comments – Aug 11

• == Prepared definitions• (Remove, unused) Last Gasp – all are proprietary, none

scale

• Discussion: This is a term used in utilities. There is industry text on the term,e.g:

• http://http://ewh.ieee.org/conf/tdc/IEEE_-_Outage_Management_-_042308_FINAL.pdf

Leave in – review text

September 2010

Bruce Kraemer, Marvell

Slide 26

doc.: IEEE 802.11-10/0955r5

Submission

Availability – Comment (Aug 18)

• Comment: Jorjeta Jetcheva, Itron • The definition of Link Availability is vague (text on p. 22 (Section

4.2.1) and in Section 4.2.1.1 (p. 23)) and does not provide sufficient information to enable us to compare different wireless technologies.

• We want to know if the link is going to be available when we want to use it. This ultimately translates to the following question: if a wireless device wants to transmit a packet, how long does it need to wait before it can transmit the packet? The answer to that question ranges from “immediately” to “indefinitely” (e.g., if there is an (permanent) obstacle between the two devices that prevents communication).

• Some factors that affect how long a device has to wait before a link is available for it to use are technology independent (e.g., propagation conditions, interference), while others are technology-specific (e.g., medium access scheduling, power-save modes) and can thus be useful in comparing different wireless technologies.

September 2010

Bruce Kraemer, Marvell

Slide 27

doc.: IEEE 802.11-10/0955r5

Submission

Availability - Proposed Text -1 (Aug 18)

• text to be added to Section 4.2.1.1:• Link Availability refers to the ability of a device to use a wireless

link when a packet needs to be sent on the link and can be evaluated in terms of the amount of time it takes before a packet can be transmitted on the link.

• Some factors that affect how long a device has to wait before a link is available for it to use are technology-independent (e.g., propagation conditions, interference) and affect all wireless devices, while others are technology-specific (e.g., medium access scheduling, power save mechanisms) and can thus be useful in comparing different wireless technologies. It is important to note that the availability of a wireless link may not be symmetric because the wireless environment at the two endpoints of the link may be different.

September 2010

Bruce Kraemer, Marvell

Slide 28

doc.: IEEE 802.11-10/0955r5

Submission

Availability - Proposed Text -2 (Aug 18)• Propagation conditions may change dynamically and may thus

affect a link’s budget and availability unpredictably, e.g., passing trucks, construction. Similarly, interference from collocated devices (not necessarily networking devices) emitting signal on overlapping frequencies may affect the quality of a link and may make it unavailable for various periods of time. Both of these factors affect link availability across wireless technologies and can be mitigated to some extent through the use of techniques aimed at improving link quality as discussed in Section 4.2.2.1.

• Power save mechanisms may affect the ability of a device to receive traffic during the times it is in power save mode, however, they can typically be configured or turned off depending on the level of availability required by a specific network.

September 2010

Bruce Kraemer, Marvell

Slide 29

doc.: IEEE 802.11-10/0955r5

Submission

Availability - Proposed Text -3 (Aug 18)

• Medium access scheduling may be deterministic (e.g., transmissions follow a schedule computed/dictated by a “coordinator” for the link, e.g., a base station), or may incorporate a non-deterministic component (e.g., random access mechanisms, including backoff when a device senses the medium to be busy), and typically depends on the number of devices trying to use a link simultaneously, and the amount and relative priority of the traffic they are transmitting, e.g., higher priority packets may get preferential access to the wireless medium causing lower priority packets to wait before they can be transmitted. (The effects of interference caused by transmissions by devices other than those trying to use the same link are taken into account in the technology-independent discussion and is not taken into account as part of the medium access delay.)

• Medium access delay is a technology-specific metric that can be a useful tool for comparing link availability across different wireless technologies. For example, given a number of devices trying to use a wireless link simultaneously, we can estimate the average time a device has to wait before it can access the medium by taking into account scheduling and backoff parameters used for timing packet transmission attempts.

September 2010

Bruce Kraemer, Marvell

Slide 30

doc.: IEEE 802.11-10/0955r5

Submission

Next call – September 1 – 2pm EDT

• Review any additional submissions • to Sections 1-5• Or to section 6

September 2010

Bruce Kraemer, Marvell

Slide 31

doc.: IEEE 802.11-10/0955r5

Submission

Call for Contributions to Section 6

• Suggested Outline• Factors affecting performance, i.e. reliability, delay,

throughput– Channel conditions such as distance, transmitted power,

interference, propagation environment– Traffic load– Number of users

• Seeking volunteers?

September 2010

Bruce Kraemer, Marvell

Slide 32

doc.: IEEE 802.11-10/0955r5

Submission

Section 6 – Default Suggestions• 6. Findings / Results• Does wireless technology X meet SG-Network requirements

– Performance Metrics– Reliability– Latency– Scalability– meets throughput needs– handles the number of devices needed– range– interference immunity– By actor to actor / Link by link which is the best to use– How does its work in urban, sub-urban, rural– How well does it propagate (e.g. walls, basements, vaults, clutter, hills)– scalability over a quantity of end points– Equipment required to operate– Include processing time between actor to actor

September 2010

Bruce Kraemer, Marvell

Slide 33

doc.: IEEE 802.11-10/0955r5

Submission

• Comments received during/following August 4

September 2010

Bruce Kraemer, Marvell

Slide 34

doc.: IEEE 802.11-10/0955r5

Submission

Availability - 1• Hello all,• I wanted to start a discussion on Link Availability (Section 4.2.1.1 on p. 23) as a

continuation of our discussion on the call earlier today.• Currently the text mentions that Link Availability is affected by devices being in sleep

mode, or by propagation conditions and interference:• Sleep mode is generally configurable and optional (can be turned off), so one

technology is not going to offer less availability than another due to the presence of sleep mode capabilities because sleep mode can be configured appropriately or be turned off.   Perhaps the availability of sleep mode should just be considered an energy efficiency mechanism and discussed in Section 4.2.2.3?

• Propagation conditions and interference affect availability of a link across all wireless technologies.   What differs between different wireless technologies is how resilient they are to interference, multipath, etc., which is discussed in Section 4.2.2.1.  Though these kinds of techniques can generally be employed across different technologies so it’s hard to say that they are specific to a given technology and can thus be used to compare different technologies.

• Are there additional dimensions to the Link Availability metric that are part of the intention behind this section but are not captured in the text? 

• I look forward to your comments.• Jorjeta

September 2010

Bruce Kraemer, Marvell

Slide 35

doc.: IEEE 802.11-10/0955r5

Submission

Availability - 2• Jorjeta and all,• Availability can be very focused or a rather expansive topic. I believe that sleep

mode and interference are potentially problematic in mixing concepts. • When designing an RF segment to be used by an application the duty cycle (sleep

mode) and RF link reliability are a couple of the factors that go into the availability of the link as seen by an application. For example, if one were to PING across a link from an NMS application other factors come into play. I am hitting on some of them below.

• If we are speaking to the RF link alone, availability is dependent upon, but not limited to:

• - link budget: the received signal level above the thermal noise floor necessary to receive a signal with the appropriate margin (different margins [dB] imply a different reliability [%]). NIST has produced a robust link budget calculator (available on the web) that covers the topic in much greater detail.

• - SNR margin: additional margin to account for harmful interference which is dependent on the technology in use and the permissible operational rules relating to the spectrum use/users

September 2010

Bruce Kraemer, Marvell

Slide 36

doc.: IEEE 802.11-10/0955r5

Submission

Availability - 3• Designed Availability:• However, when describing the that the radio link is needed by the application, it implies far more

than just the RF layer but also the availability of the connection (end-to-end). In many circles this is aligned more with site availability (the Uptime Institute has an excellent document covering the topic regarding Tier Classifications) and includes:

• - Hardware element availability (MTBF/MTTR)• - System component redundancy• - Distribution paths (this aligns well with the wireless topology [mesh, PTM, PTP, etc.)• - Power redundancy• - Fault tolerance• Duty Cycle: this is relative to the percentage of time the link is designed to be available for use and

tends to be dependent upon technology or operator settings (such as to conserve battery life or comply with MPE limits).

• In a single point of failure (no HW, backhaul, power redundancy design), one will find that ~99.5% is a designed system reliability. With redundancy in the systems (HW and/or power and/or distribution paths) 99.95 is achievable before RF availability is considered.

• Actual reliability will take into consideration the reliability of RF, the reliability of the system elements, the duty cycle and the operational practices of the system operator (change control, maintenance practices, etc.)

• Actual system reliability (as one would expect to see measured from a Network Management System report [i.e. an application]) must factor all these element in.

• Jake Rasweiler