May 201 0 Bruce Krae mer, Slide 1 doc.: IEEE 802.11-10/0505r1 Submission Smart Grid Technology Information - May 2010 Date: 2010-5-05 tract: Information on 802.11 technology for inclusion in the June 2010 NIST PAP#2 Repo Name Company Address Phone email Bruce Kraemer Marvell 5488 Marvell Lane, Santa Clara, CA, 95054 +1-321-751- 3988 [email protected]om Kaberi Banerjee
83
Embed
Doc.: IEEE 802.11-10/0505r1 Submission May 2010 Bruce Kraemer, MarvellSlide 1 Smart Grid Technology Information - May 2010 Date: 2010-5-05 Abstract: Information.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
May 2010
Bruce Kraemer, Marvell
Slide 1
doc.: IEEE 802.11-10/0505r1
Submission
Smart Grid Technology Information - May 2010
Date: 2010-5-05Abstract: Information on 802.11 technology for inclusion in the June 2010 NIST PAP#2 Report
Name Company Address Phone emailBruce Kraemer Marvell 5488 Marvell Lane,
Meter Read Yes Yes Direct load control In progress No Service Switch Yes Yes PHEV Yes Yes System updates In progress No Distributed GEN In progress No Distributed Storage Draft No Outage Events Yes Yes Tamper Events Draft No Meter Events Draft No Demand Response Draft No Pre-Pay Metering Yes Yes Field Force tools Not started No Distribution auto support Yes Yes Transmission auto support Not started No Pricing TOU / RTP/ CPP in progress No Configuration mgmt in progress No Accounting Mgmt in progress No Performance Mgmt in progress No Security mgmt in progress No Fault mgmt in progress No Volt/VAR Management Yes Yes
Listing of pertinent use casesIn order to create a list of functional requirements for the Smart Grid, an exercise was performed to list all pertinent use cases that involve network communication. Sources for this information include the Southern California Edison Use Cases, Grid Wise Architectural Console use cases, EPRI and others. Use cases from all of these sources were selected based upon a network requirements basis. From this research the following high level use cases have been identified
Discussion Topics from Monday May 16There are many pieces of simulation already provided and
others being constructed. Can we provide further guidance on how the data could be used to help engineer a network? Can we begin by providing guidance on how to interpret and use the model outputs e.g average and instantaneous throughput? (Dave Halasz)
Discussion Topics from Monday May 16802.11 has agreed that CCMP is thebest security
machanism to use. Since it will be used in further technical descriptions and modeling we need to further characterize the security mechanism CCMP. (Dave Halasz)
• Comprehensive review of NIST report draft on next Smart Grid call Wed June 2.
May 2010
Bruce Kraemer, Marvell
Slide 9
doc.: IEEE 802.11-10/0505r1
Submission
802.11 Project Plans
• What nees to be done to further enhance 802.11 technology for Smart Grid applications?
• Increase low bit rate range ; S1G re channelize, <1000 MHz– Project under way – speedy conclusion and demonstrations needed
• Complete mesh capability: Suitable features are in S, – Project 2/3 complete. Need to complete specification to build vendor and
user confidence
• Other evolutionary needs??
• Low power: need to demonstrate how to provide WLAN devices with 10 year+ battery life
May 2010
Bruce Kraemer, Marvell
Slide 10
doc.: IEEE 802.11-10/0505r1
Submission
Technical Capabilities
• Focused discussion on how to maximize battery life with existing radio and protocol options.
• Exploration of (near term) improvements based only upon protocol extensions.
• Exploration of (longer term) improvements based upon PHY changes and protocol extensions.
May 2010
Bruce Kraemer, Marvell
Slide 11
doc.: IEEE 802.11-10/0505r1
Submission
Following Material
Discussion Topics from Monday May 16
May 2010
Bruce Kraemer, Marvell
Slide 12
doc.: IEEE 802.11-10/0505r1
Submission
Introduction to the NIST PAP2 Report
• Report Preface• This guide is the output of the Priority Action Plan number 2 (PAP#2),
wireless communications for the smart grid, which is part of the Smart Grid Interoperability Panel (SGIP). PAP#2’s work area investigates the strengths, weaknesses, capabilities, and constraints of existing and emerging standards-based physical media for wireless communications. The approach is to work with the appropriate standard development organizations (SDOs) to determine the characteristics of each technology for Smart Grid application areas and types. Results are used to assess the appropriateness of wireless communications technologies for meeting Smart Grid applications’ requirements.
• This guide contains the smart grid reference architecture, the user applications’ requirements, candidate wireless technologies and their capabilities, a methodology to assess the appropriateness of wireless communications technologies along with an example model, and some results.
May 2010
Bruce Kraemer, Marvell
Slide 13
doc.: IEEE 802.11-10/0505r1
Submission1313
Priority Action Plan for Wireless communications(PAP#2)
Guidelines for the use of wireless communications in different Smart Grid domains:
• Identify different Smart Grid application communication requirements• Describe how well wireless communication technologies can support Smart
Grid applications:• Describe an evaluation approach to point out performance trends and issues
• Intended audience: All smart grid stakeholders including utility operators, network/communication vendors, professional and technical associations, standard setting organizations, local, state and federal agencies involved in policy, rules, and funding related to Smart Grid.
May 2010
Bruce Kraemer, Marvell
Slide 15
doc.: IEEE 802.11-10/0505r1
Submission15
Administrative logistics
Ownership: SGIP – PAP 2• No document control• No copyright protection
• Make this a NIST Internal Report in order to provide document control and copyright
Review process within PAP 2/SGIP:• Consensus within PAP 2• NIST Internal review process
Public release and revision:• 1st draft to be completed by June 30, 2010• Subsequent revisions as necessary
May 2010
Bruce Kraemer, Marvell
Slide 16
doc.: IEEE 802.11-10/0505r1
Submission16
Review of draft document
May 2010
Bruce Kraemer, Marvell
Slide 17
doc.: IEEE 802.11-10/0505r1
Submission17
Section 6: Findings and results
May 2010
Bruce Kraemer, Marvell
Slide 18
doc.: IEEE 802.11-10/0505r1
Submission 18
1. Does wireless technology X meet SG-NET requirements Y?
2. How to cover smart grid devices deployed using a particular wireless technology?
3. How many devices can a wireless technology support?• For a specific topology and traffic characteristics
4. How well can device mobility be supported and what is the impact on the user application performance?
5. How well can wireless interference be tolerated and what is the impact on the user application performance?
Key questions to answer
May 2010
Bruce Kraemer, Marvell
Slide 19
doc.: IEEE 802.11-10/0505r1
Submission
Caveats and things to keep in mind• PAP 2 is about wireless communications therefore performance evaluation is
conducted at layers 1 & 2 and on a link by link basis– A link by link performance assessment is necessary but not sufficient to assess the end-to-end
performance. • In order to relate wireless communications to the application communication
requirements, there is a need to make assumptions regarding the presence of protocol layers above layer 2 and their mutual interactions:
– Include all protocol layer overhead in size of data transmitted– Derive performance bounds within stated assumptions
• Performance results and quantitative numbers are always related to a specific scenario including topology, traffic characteristics, and for a given technology
– General performance trends emerge based on the relationship between the various performance metrics and the input parameters.
May 2010
Bruce Kraemer, Marvell
Slide 20
doc.: IEEE 802.11-10/0505r1
Submission
Performance metrics
• Reliability (data transfer): the probability that a data packet successfully reaches its destination
• Reliability (connectivity) or Outage probability: the probability that a device cannot establish a link at maximum transmit power
• Delay: the time elapsed for a data packet to successfully reach its destination, including the time spent in queuing, transmission, propagation, retransmission, processing.
• Throughput : the packet data size in bits divided by the time it takes to reach its destination
May 2010
Bruce Kraemer, Marvell
Slide 21
doc.: IEEE 802.11-10/0505r1
Submission
Input parameters
• Topology– Number of devices– coverage in cell radius (meters) or distance between transmitter and receiver
• Traffic– Offered Load (bandwidth)– Size of the data to be transmitted (bits) – Data interarrival time (seconds)
• Environment – Propagation
• Technology– Bit rate– Effective Isotropic Radiated Power (EIRP)
May 2010
Bruce Kraemer, Marvell
Slide 22
doc.: IEEE 802.11-10/0505r1
Submission
Sample output:offered load varies while the number of devices is fixed
• Plots show Reliability, Throughput, Delay, and queue blocking probability metrics versus the application offered load.
• The plots show a common breakpoint indicated by the dashed line (at about 6.5 kb/s) where all the metrics show significant performance degradation.
• Breakpoint location depends on network parameters (e.g. number of stations), and on the MAC layer technology.
May 2010
Bruce Kraemer, Marvell
Slide 23
doc.: IEEE 802.11-10/0505r1
Submission
Example showing effect of varying other network parameters
• Example plots show Reliability, Throughput, Delay, and Pr{blocking} metrics for Rmax = 300 m, all other parameters the same.
• The plot below shows the offered load breakpoint vs. Rmax.
May 2010
Bruce Kraemer, Marvell
Slide 24
doc.: IEEE 802.11-10/0505r1
Submission
Section 6 structure alternatives
• By link– Using technology x discuss performance trends and breakpoints, i.e.
reliability, delay, throughput versus number of devices, coverage, environment
OR• By application category
– Using technology x discuss performance trends and breakpoints, i.e. reliability, delay, throughput versus number of devices, coverage, environment
May 2010
Bruce Kraemer, Marvell
Slide 25
doc.: IEEE 802.11-10/0505r1
Submission
Section 6 outline
6.1 Performance metrics6.2 Input parameters6.3 General performance trends6.4 By link discussion6.4.1 Technology X6.4.2 Technology YOR6.4 By application category discussion6.4.1 Technology X6.4.2 Technology Y
May 2010
Bruce Kraemer, Marvell
Slide 26
doc.: IEEE 802.11-10/0505r1
Submission26
Tools & results validation
May 2010
Bruce Kraemer, Marvell
Slide 27
doc.: IEEE 802.11-10/0505r1
Submission2727
Priority Action Plan for Wireless communications(PAP#2)
McLean, VAMay 6, 2010
NIST
May 2010
Bruce Kraemer, Marvell
Slide 28
doc.: IEEE 802.11-10/0505r1
Submission28
Scope of PAP 2 deliverable
Guidelines for the use of wireless communications in different Smart Grid domains:
• Identify different Smart Grid application communication requirements• Describe how well wireless communication technologies can support Smart
Grid applications:• Describe an evaluation approach to point out performance trends and issues
• Intended audience: All smart grid stakeholders including utility operators, network/communication vendors, professional and technical associations, standard setting organizations, local, state and federal agencies involved in policy, rules, and funding related to Smart Grid.
May 2010
Bruce Kraemer, Marvell
Slide 29
doc.: IEEE 802.11-10/0505r1
Submission29
Administrative logistics
Ownership: SGIP – PAP 2• No document control• No copyright protection
• Make this a NIST Internal Report in order to provide document control and copyright
Review process within PAP 2/SGIP:• Consensus within PAP 2• NIST Internal review process
Public release and revision:• 1st draft to be completed by June 30, 2010• Subsequent revisions as necessary
May 2010
Bruce Kraemer, Marvell
Slide 30
doc.: IEEE 802.11-10/0505r1
Submission30
Review of draft document
May 2010
Bruce Kraemer, Marvell
Slide 31
doc.: IEEE 802.11-10/0505r1
Submission31
Section 6: Findings and results
May 2010
Bruce Kraemer, Marvell
Slide 32
doc.: IEEE 802.11-10/0505r1
Submission 32
1. Does wireless technology X meet SG-NET requirements Y?
2. How to cover smart grid devices deployed using a particular wireless technology?
3. How many devices can a wireless technology support?• For a specific topology and traffic characteristics
4. How well can device mobility be supported and what is the impact on the user application performance?
5. How well can wireless interference be tolerated and what is the impact on the user application performance?
Key questions to answer
May 2010
Bruce Kraemer, Marvell
Slide 33
doc.: IEEE 802.11-10/0505r1
Submission
Caveats and things to keep in mind• PAP 2 is about wireless communications therefore performance evaluation is
conducted at layers 1 & 2 and on a link by link basis– A link by link performance assessment is necessary but not sufficient to assess the end-to-end
performance. • In order to relate wireless communications to the application communication
requirements, there is a need to make assumptions regarding the presence of protocol layers above layer 2 and their mutual interactions:
– Include all protocol layer overhead in size of data transmitted– Derive performance bounds within stated assumptions
• Performance results and quantitative numbers are always related to a specific scenario including topology, traffic characteristics, and for a given technology
– General performance trends emerge based on the relationship between the various performance metrics and the input parameters.
May 2010
Bruce Kraemer, Marvell
Slide 34
doc.: IEEE 802.11-10/0505r1
Submission
Performance metrics
• Reliability (data transfer): the probability that a data packet successfully reaches its destination
• Reliability (connectivity) or Outage probability: the probability that a device cannot establish a link at maximum transmit power
• Delay: the time elapsed for a data packet to successfully reach its destination, including the time spent in queuing, transmission, propagation, retransmission, processing.
• Throughput : the packet data size in bits divided by the time it takes to reach its destination
May 2010
Bruce Kraemer, Marvell
Slide 35
doc.: IEEE 802.11-10/0505r1
Submission
Input parameters
• Topology– Number of devices– coverage in cell radius (meters) or distance between transmitter and receiver
• Traffic– Offered Load (bandwidth)– Size of the data to be transmitted (bits) – Data interarrival time (seconds)
• Environment – Propagation
• Technology– Bit rate– Effective Isotropic Radiated Power (EIRP)
May 2010
Bruce Kraemer, Marvell
Slide 36
doc.: IEEE 802.11-10/0505r1
Submission
Sample output:offered load varies while the number of devices is fixed
• Plots show Reliability, Throughput, Delay, and queue blocking probability metrics versus the application offered load.
• The plots show a common breakpoint indicated by the dashed line (at about 6.5 kb/s) where all the metrics show significant performance degradation.
• Breakpoint location depends on network parameters (e.g. number of stations), and on the MAC layer technology.
May 2010
Bruce Kraemer, Marvell
Slide 37
doc.: IEEE 802.11-10/0505r1
Submission
Example showing effect of varying other network parameters
• Example plots show Reliability, Throughput, Delay, and Pr{blocking} metrics for Rmax = 300 m, all other parameters the same.
• The plot below shows the offered load breakpoint vs. Rmax.
May 2010
Bruce Kraemer, Marvell
Slide 38
doc.: IEEE 802.11-10/0505r1
Submission
Section 6 structure alternatives
• By link– Using technology x discuss performance trends and breakpoints, i.e.
reliability, delay, throughput versus number of devices, coverage, environment
OR• By application category
– Using technology x discuss performance trends and breakpoints, i.e. reliability, delay, throughput versus number of devices, coverage, environment
May 2010
Bruce Kraemer, Marvell
Slide 39
doc.: IEEE 802.11-10/0505r1
Submission
Section 6 outline
6.1 Performance metrics6.2 Input parameters6.3 General performance trends6.4 By link discussion6.4.1 Technology X6.4.2 Technology YOR6.4 By application category discussion6.4.1 Technology X6.4.2 Technology Y
Group 2: Data/Media Type Supported, b: Data;• 2.1 Group 2: Data/Media Type Supported, b: Data;• Over the air PHY rate• What is the meaning of Data? It is in measurement units of Maximum user data rate per
user in Mb/s.• Since 802.15.4 gives 0.25 Mb/s one might assume that it is the physical medium rate.
However with that assumption, it does not apply to the value for 802.11 of 0.70 Mb/s.• Therefore one must assume another meaning. For example data rate minus protocol
(and/or framing) overhead results in 0.70 Mb/s (i.e., maximum user data rate (i.e., MAC Service Data Unit)), if so then the 802.15.4 value must be changed to comply with that assumption.
• Agreement on a consistent meaning of Data is needed.• Is it the maximum user data rate seen at the interface to/from the MAC sublayer?• Is it an instantaneous data rate?• Since it states Maximum user data rate per user, perhaps the number of users that was
assumed for the calculation needs to be stated as well, especially when the medium is shared as in 802.11 and 802.15.4.
May 2010
Bruce Kraemer, Marvell
Slide 48
doc.: IEEE 802.11-10/0505r1
Submission
2.3 Group 5: Data Rates items c and d (Peak goodput over the air UL/DL data rate)
• How is the goodput calculated?
• Is goodput strictly calculated on a single MAC sublayer frame’s payload divided by the resulting physical layer packet?
• Is the goodput calculated including any CSMA overhead and the entire message exchange (e.g., data frame and acknowledgement frame)?
• Both 802.11 and 802.15.4 can act as either peer to peer (p2p) or AP to/from STA for 802.11 or coordinator to/from device for 802.15.4. So for the peer case UL and DL would be the same. However for the non-P2P case UL and DL might be different. Both 802.11 and 802.15 use the same channel in this case, but the protocol overhead might be different (e.g., polling a PAN coordinator to retreive data vs device sending to PAN coordinator for 802.15.4). Clarification (i.e., note) on the type of mode that is being used to achieve the values for the data rates is needed.
May 2010
Bruce Kraemer, Marvell
Slide 49
doc.: IEEE 802.11-10/0505r1
Submission
2.3.2 Sample peak goodput for 802.11 baseline
• Was not able to obtain 0.7 Mb/s, assuming only data transmission overhead for one data frame transmission and its associated acknoledgement. What other additional overhead assumptions were assumed? Beacon transmission? RTS/CTS? Association and authentication procedures?
• 2.3.2.1 (A)• Assuming one message exchange of one 50us DIFS + zero backoff + long
preamble (144) + PLCP (48) + 28 bytes MAC overhead + 2312 bytes user data (maximum) + 10 us SIFS + ACKnowledgement packet under DCF; a peak throughput of 0.959 Mb/s.
• 2.3.2.2 (B)• Assuming one message exchange of one 50us DIFS + 15.5 backoff slots
(average first attempt successful)+ long preamble (144) + PLCP (48) + 28 bytes MAC overhead + 2312 bytes user data (maximum) + 10 us SIFS + ACKnowledgement packet under DCF and DS; a peak throughput of 0.944 Mb/s.
May 2010
Bruce Kraemer, Marvell
Slide 50
doc.: IEEE 802.11-10/0505r1
Submission
Group 7, Data frames and packets, item a frame duration and item b Maximum packet size
What is meant by frame?What is meant by packet?Are they the same or different?
May 2010
Bruce Kraemer, Marvell
Slide 51
doc.: IEEE 802.11-10/0505r1
Submission
2.4 Group 7, Data frames and packets, item a frame duration and item b Maximum packet size
What is meant by frame?There are three primary Frame group types identified in 802.11Management, Control & Data. Payload data is transported inside a data frame. The Data Frame is composed of a number of sub fields: control field, duration field, address fields, sequence field, data, frame check sequence. This collection of fields is referred to as a MAC Protocol Data Unit (MPDU). The source payload data may fit into one frame or if larger than 2312 bytes requires fragmentation and transmission using multiple data frames.
When the MPDU is prepared to send out over the air there are additional fields added for preamble, start of frame delimiter and header. These fields then comprise the Physical Layer Packet Data Unit (PPDU).
What is meant by packet?“Packet” is a general term that refers to the combination of control, address, and data fields described above that includes the payload data of interest .
Are they the same or different?When the terms Packet and Frame are used without further qualifiers they can be considered to be equivalent.
May 2010
Bruce Kraemer, Marvell
Slide 52
doc.: IEEE 802.11-10/0505r1
Submission
Technology Description
Protocol Details
May 2010
Bruce Kraemer, Marvell
Slide 53
doc.: IEEE 802.11-10/0505r1
Submission
Frame Control
(2 bytes)
Frame Control
(2 bytes)
Duration /ID
(2 bytes)
Duration /ID
(2 bytes)
Address1(6 bytes)Address1(6 bytes)
Address2(6 bytes)Address2(6 bytes)
Address3(6 bytes)Address3(6 bytes)
Sequence. Control
(2 bytes)
Sequence. Control
(2 bytes)
QoS Control
(2 bytes)
QoS Control
(2 bytes)
HT Control
(2 bytes)
HT Control
(2 bytes)
802.11 MAC and Physical Layer Data Frame Encapsulation(Ref: Draft P802.11-REVmb/D3.0, March 2010)
NDBPS) + SignalExtension(19-9)• where• PreambleLengthDSSS is 144 μs if the PREAMBLE_TYPE value from the
TXVECTOR parameter• indicates “LONGPREAMBLE,” or 72 μs if the PREAMBLE_TYPE value• from the TXVECTOR parameter indicates “SHORTPREAMBLE”• =144+48 or 24+8+
Ref1 : Draft P802.11-REVmb/D3.0, March 2010, Clause 17
OFDM PHY20
May 2010
Bruce Kraemer, Marvell
Slide 62
doc.: IEEE 802.11-10/0505r1
Submission
Behavior
May 2010
Bruce Kraemer, Marvell
Slide 63
doc.: IEEE 802.11-10/0505r1
Submission
Relationship betweenThroughput and Payload
Payload Length
Throughput
Lower SNR
High SNR
Low SNR
May 2010
Bruce Kraemer, Marvell
Slide 64
doc.: IEEE 802.11-10/0505r1
Submission
Effect of payload length on throughput for various retransmission limits (6 Mbps, SNR of 2 dB)
www.mat.ucsb.edu/~ggroup/choudhury_iwcmc06.pdf
May 2010
Bruce Kraemer, Marvell
Slide 65
doc.: IEEE 802.11-10/0505r1
Submission
Throughput versus payload (18 Mbps, SNR 8dB)
10.66 Mbps59.2%
www.mat.ucsb.edu/~ggroup/choudhury_iwcmc06.pdf
May 2010
Bruce Kraemer, Marvell
Slide 66
doc.: IEEE 802.11-10/0505r1
Submission
Capacity with 5 data users in thenetwork (SNR is 8 dB , 6 Mbps)
www.mat.ucsb.edu/~ggroup/choudhury_iwcmc06.pdf
May 2010
Bruce Kraemer, Marvell
Slide 67
doc.: IEEE 802.11-10/0505r1
Submission
Throughput
Calculations
May 2010
Bruce Kraemer, Marvell
Slide 68
doc.: IEEE 802.11-10/0505r1
Submission
Throughput Question
• 2.3.2.1 (A)
• Assuming one message exchange of one 50us DIFS + zero backoff + long preamble (144) + PLCP (48) + 28 bytes MAC overhead + 2312 bytes user data (maximum) + 10 us SIFS + ACKnowledgement packet under DCF; a peak throughput of 0.959 Mb/s
• Again, how much detail to provide?
• What is precise enough?
• How to account for theory vs practice?
May 2010
Bruce Kraemer, Marvell
Slide 69
doc.: IEEE 802.11-10/0505r1
Submission
802.11 Inter-frame Spacing
May 2010
Bruce Kraemer, Marvell
Slide 70
doc.: IEEE 802.11-10/0505r1
Submission
Frame Spacing Relationships
• aSIFSTime and aSlotTime are fixed per PHY.• aSIFSTime is: aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay +
aRxTxTurnaroundTime.• aSlotTime is: aCCATime + aRxTxTurnaroundTime + aAirPropagationTime• + aMACProcessingDelay.• The PIFS and DIFS are derived by the following equations, as illustrated in Figure 9-12.• PIFS = aSIFSTime + aSlotTime• DIFS = aSIFSTime + 2 × aSlotTime• The EIFS is derived from the SIFS and the DIFS and the length of time it takes to
transmit an ACK Control• frame at the lowest PHY mandatory rate by the following equation:• EIFS = aSIFSTime + DIFS + ACKTxTime• where• ACKTxTime is the time expressed in microseconds required to transmit an ACK frame,
including• preamble, PLCP header and any additional PHY dependent information, at the lowest
Analyzing Wireless LAN Security OverheadHarold Lars McCarterThesis submitted to the Faculty of the Virginia Polytechnic Institute and State Universityin partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering17-Apr-06Falls Church, Virginiahttp://scholar.lib.vt.edu/theses/available/etd-04202006-080941/unrestricted/mccarter_thesis.pdf
May 2010
Bruce Kraemer, Marvell
Slide 76
doc.: IEEE 802.11-10/0505r1
Submission
Example 2: Various 802.11 Reported Throughputs
802.11g and 802.11a Modulation and Coding Options 802.11g and 802.11a Modulation and Coding Optionsover payload over payloadthe Code theair rate air
• Churong Chen; Choi Look Law; , "Throughput performance analysis and experimental evaluation of IEEE 802.11b radio link," Information, Communications & Signal Processing, 2007 6th International Conference on , vol., no., pp.1-5, 10-13 Dec. 2007doi: 10.1109/ICICS.2007.4449813URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4449813&isnumber=4449533
Na, C.; Chen, J.K.; Rappaport, T.S.; , "Measured Traffic Statistics and Throughput of IEEE 802.11b Public WLAN Hotspots with Three Different Applications," Wireless Communications, IEEE Transactions on , vol.5, no.11, pp.3296-3305, November 2006doi: 10.1109/TWC.2006.05043URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4027799&isnumber=4027759
Garg, S.; Kappes, M.; , "An experimental study of throughput for UDP and VoIP traffic in IEEE 802.11b networks," Wireless Communications and Networking, 2003. WCNC 2003. 2003 IEEE , vol.3, no., pp.1748-1753 vol.3, 20-20 March 2003doi: 10.1109/WCNC.2003.1200651URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1200651&isnumber=27030
Bruno, R.; Conti, M.; Gregori, E.; , "Throughput Analysis of UDP and TCP Flows in IEEE 802.11b WLANs: A Simple Model and Its Validation," Techniques, Methodologies and Tools for Performance Evaluation of Complex Systems, 2005. (FIRB-Perf 2005). 2005 Workshop on , vol., no., pp. 54- 63, 19-19 Sept. 2005doi: 10.1109/FIRB-PERF.2005.20URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1587695&isnumber=33459
Mahasukhon, P.; Hempel, M.; Song Ci; Sharif, H.; , "Comparison of Throughput Performance for the IEEE 802.11a and 802.11g Networks," Advanced Information Networking and Applications, 2007. AINA '07. 21st International Conference on , vol., no., pp.792-799, 21-23 May 2007doi: 10.1109/AINA.2007.46URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4220972&isnumber=4220857
Bruno, R.; Conti, M.; Gregori, E.; , "IEEE 802.11 optimal performances: RTS/CTS mechanism vs. basic access," Personal, Indoor and Mobile Radio Communications, 2002. The 13th IEEE International Symposium on , vol.4, no., pp. 1747- 1751 vol.4, 15-18 Sept. 2002URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1045479&isnumber=22399
May 2010
Bruce Kraemer, Marvell
Slide 81
doc.: IEEE 802.11-10/0505r1
Submission
New Smart Grid Topic at ITU
May 2010
Bruce Kraemer, Marvell
Slide 82
doc.: IEEE 802.11-10/0505r1
Submission
ITU Smart Grid Initiative
by ITU Press Office
• Wed. May 12, 2010 Geneva - Some of the world’s biggest ICT companies have tasked a new ITU group with identifying standards needs for the world’s new Smart Grid deployments, which will bring the benefits of digital technology to the existing electricity network.
• The Focus Group on Smart Grid will survey existing national standards initiatives to see whether these can be adopted at an international level, and will also perform a gap analysis to identify new standardization requirements that will then be taken forward by relevant ITU-T Study Groups. This exploratory phase will be relatively short before work starts on the development of the standards necessary to support the global rollout of Smart Grid technologies.
• TSAG - Telecommunication Standardization Advisory Group
The ultimate aim of the Telecommunication Standardization Advisory Group (TSAG) is to make the ITU-T the most attractive place to come to do standards work.
To this end and in recognition of the increasingly dynamic environment of information and communication technologies, TSAG overhauled ITU-T working methods to streamline approval procedures for new work items and the resulting international standards. This means that on average, a standard (ITU-T Recommendation) which took as much as four years to approve 10 years ago can now be approved in about eight weeks. For Recommendations which might have policy or regulatory implications, approval takes about nine months to allow additional consultation with the world’s governments.