22-10-0004-00-0000-ieee-802-22-wg-minutes-plenary-session-november-2009-atlanta
EMBER EM2420 2.4 GHz IEEE 802.15.4 ZigBee RF Tra

CMOS process.Table of contentsAbbreviations_____________________________________________________________________5References_______________________________________________________________________6Features_________________________________________________________________________7Absolute Maximum Ratings_________________________________________________________8Electrical Specifications____________________________________________________________9Pin Assignment__________________________________________________________________14Circuit Description_______________________________________________________________16Application Circuit_______________________________________________________________18 Input / output matching___________________________________________________________18 Bias resistor____________________________________________________________________18 Crystal________________________________________________________________________18 Voltage regulator________________________________________________________________18 Power supply decoupling and filtering_______________________________________________18IEEE 802.15.4 Modulation Format__________________________________________________22Configuration Overview___________________________________________________________23Evaluation Software______________________________________________________________244-wire Serial Configuration and Data Interface________________________________________25 Register access_________________________________________________________________25 Status byte_____________________________________________________________________26 Command strobes_______________________________________________________________27 RAM access____________________________________________________________________27 FIFO access____________________________________________________________________29 Multiple SPI access______________________________________________________________29Microcontroller Interface and Pin Description________________________________________30 Configuration interface___________________________________________________________30 Receive mode__________________________________________________________________31 RXFIFO overflow_______________________________________________________________31 Transmit mode__________________________________________________________________32 General control and status pins_____________________________________________________32Demodulator, Symbol Synchronizer and Data Decision_________________________________33Frame Format___________________________________________________________________33 Synchronization header___________________________________________________________34 Length field____________________________________________________________________35 MAC protocol data unit___________________________________________________________35 Frame check sequence____________________________________________________________35 RF Data Buffering________________________________________________________________37 Buffered transmit mode___________________________________________________________37 Buffered receive mode___________________________________________________________38 Unbuffered, serial mode__________________________________________________________38 Address Recognition______________________________________________________________39 Acknowledge Frames_____________________________________________________________40 Radio control state machine________________________________________________________42MAC Security Operations (Encryption and Authentication)_____________________________44 Keys__________________________________________________________________________44Nonce / counter_________________________________________________________________44 Stand-alone encryption___________________________________________________________45 In-line security operations_________________________________________________________45 CTR mode encryption / decryption__________________________________________________46 CBC-MAC_____________________________________________________________________46 CCM_________________________________________________________________________46 Timing________________________________________________________________________47Linear IF and AGC Settings________________________________________________________48RSSI / Energy Detection___________________________________________________________48Link Quality Indication___________________________________________________________49Clear Channel Assessment_________________________________________________________50Frequency and Channel Programming_______________________________________________51VCO and PLL Self-Calibration_____________________________________________________51 VCO_________________________________________________________________________51 PLL self-calibration______________________________________________________________51 Output Power Programming_______________________________________________________52 Voltage Regulator________________________________________________________________53 Battery Monitor__________________________________________________________________53 Crystal Oscillator________________________________________________________________55 Input / Output Matching__________________________________________________________56 Transmitter Test Modes___________________________________________________________56 Unmodulated carrier_____________________________________________________________56 Modulated spectrum_____________________________________________________________57 System Considerations and Guidelines_______________________________________________59 Frequency hopping and multi-channel systems_________________________________________59 Data burst transmissions__________________________________________________________59 Crystal accuracy and drift_________________________________________________________59 Communication robustness________________________________________________________59 Communication security__________________________________________________________59 Low cost systems________________________________________________________________60 Battery operated systems__________________________________________________________60 BER / PER measurements_________________________________________________________60PCB Layout Recommendations_____________________________________________________61Antenna Considerations___________________________________________________________61Configuration Registers___________________________________________________________63Test Output Signals_______________________________________________________________84Package Description (QLP 48)______________________________________________________86 Package thermal properties________________________________________________________86 Soldering information____________________________________________________________87 Plastic tube specification__________________________________________________________87 Carrier tape and reel specification___________________________________________________87 Ordering Information_____________________________________________________________88 General Information______________________________________________________________89AbbreviationsADC - Analog to Digital Converter AES - Advanced Encryption Standard AGC - Automatic Gain Control ARIB - Association of Radio Industries and Businesses BER - Bit Error Rate CBC-MAC - Cipher Block Chaining Message Authentication Code CCA - Clear Cannel Assessment CCM - Counter mode + CBC-MAC CFR - Code of Federal Regulations CTR - Counter mode (encryption) CW - Continuous Wave DAC - Digital to Analog Converter DSSS - Direct Sequence Spread Spectrum ESD - Electro Static Discharge ESR - Equivalent Series Resistance EVM - Error Vector Magnitude FCC - Federal Communications Commission FCF - Frame Control Field FIFO - First In First Out FFCTRL - FIFO and Frame Control HSSD - High Speed Serial Debug IEEE - Institute of Electrical and Electronics Engineers IF - Intermediate Frequency ISM - Industrial, Scientific and Medical ITU-T - International Telecommunication Union – Telecommunication Standardization Sector I/O - Input / Output I/Q - In-phase / Quadrature-phase kbps - kilo bits per second LNA - Low-Noise Amplifier LO - Local Oscillator LQI - Link Quality Indication LSB - Least Significant Bit / Byte MAC - Medium Access Control MFR - MAC Footer MHR - MAC Header MIC - Message Integrity Code MPDU - MAC Protocol Data Unit MSDU - MAC Service Data Unit NA - Not Available NC - No Connect O-QPSK - Offset - Quadrature Phase Shift Keying PA - Power Amplifier PCB - Printed Circuit Board PER - Packet Error Rate PHY - Physical Layer PHR - PHY Header PLL - Phase Locked Loop PSDU - PHY Service Data Unit QLP - Quad Leadless Package RAM - Random Access Memory RBW - Resolution Bandwidth RF - Radio Frequency RSSI - Receive Signal Strength Indicator RX - ReceiveFigure 1. The EM2420 Pinout – Top ViewPin Pin Name Pin type Pin Description- AGND Ground (analog) Exposed die attach pad. Must be connected to solid groundplane1 VCO_GUARD Power (analog) Connection of guard ring for VCO (to AVDD) shielding2 AVDD_VCO Power (analog) 1.8 V Power supply for VCO3 AVDD_PRE Power (analog) 1.8 V Power supply for Prescaler4 AVDD_RF1 Power (analog) 1.8 V Power supply for RF front-end5 GND Ground (analog) Grounded pin for RF shielding6 RF_P RF I/O Positive RF input/output signal to LNA/from PA inreceive/transmit modeFigure 2. The EM2420 simplified block diagramA simplified block diagram of the EM2420 is shown in Figure 2.The EM2420 features a low-IF receiver. The received RF signal is amplified by the low-noise amplifier (LNA) and down-converted in quadrature (I and Q) to the intermediate frequency (IF). At IF (2 MHz), the complex I/Q signal is filtered and amplified, and then digitized by the ADCs. Automatic gain control, final channel filtering, de-spreading, symbol correlation modes are also available for test purposes.The EM2420 transmitter is based on direct up-conversion. The data is buffered in a 128 byte transmit FIFO (separate from the receive FIFO). The preamble and start of frame delimiter are generated by hardware. Each symbol (4 bits) is spread using the IEEE 802.15.4 spreading sequence to 32 chips and output to the digital-to-analog converters (DACs).Figure 4. Typical application circuit with differential antenna (folded dipole)Figure 7. EmberNet Studio user interfaceThe FCS polynomial is [1]:x16 + x12 + x5 + 1The EM2420 hardware implementation is shown in Figure 18. Please refer to [1] for further details.In transmit mode the FCS is appended at the correct position defined by the length field. The FCS is not written to the TXFIFO, but stored in a separate 16-bit register.In receive mode the FCS is verified by hardware. The user is normally only interested in the correctness of the FCS, not the FCS sequence itself. The FCS sequence itself is therefore not written to the RXFIFO during receive.Instead, when MODEMCTRL0.AUTOCRC is set the two FCS bytes are replaced by the RSSI value, average correlation value (used for LQI) and CRC OK/not OK. This is illustrated in Figure 19.The first FCS byte is replaced by the 8-bit RSSI value. See the RSSI section on page 48 for details.The 7 least significant bits in the last FCS byte are replaced by the average correlation value of the 8 first symbols of the received PHY header (length field) and PHY Service Data Unit (PSDU). This correlation value may be used as a basis for calculating the LQI. See the。
IEEE_802.3bj_100GBASE_CR4_Specifications

Proposal for Defining Material Loss 26-Jan 12
Elizabeth Kochuparambil Joel Goergen
Cisco
/3/bj/public/jan12/kochuparambil_01a_0112.pdf
-120
-140
Test fixtures included
3 dB reference receiver bandwidth, set to 20 GHz. 4
measurement data in cooperation with Mark Bugg– Molex
802.3bj Cu specifications
Proposal: Maximum integrated crosstalk noise for maximum cable assembly insertion loss of 22.64 dB at 12.89 GHz.
8
802.3bj Cu specifications
Cable Assembly ICN – 1 m – 30 AWG
IEEE 802.3bj: 100GBASE-CR4 Specifications Minneapolis, MN May 2012
Chris DiMinico MC Communications/ LEONI Cables & Systems LLC cdiminico@
1
802.3bj Cu specifications
4
6
8
10
12
14
16
18
20
-20
RX1-P2TX2-FEXT RX1-P2TX3-FEXT
Draft P802.11p_D3.03

Copyright © 2008 by the IEEE.Three Park AvenueNew York, New York 10016-5997, USA All rights reserved.This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be uti-lized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards Commit-tee participants to reproduce this document for purposes of international standardization consideration. Prior to adoption of this document, in whole or in part, by another standards development organization permission must first be obtained from the Manager, Standards Intellectual Property, IEEE Standards Activities Depart-ment. Other entities seeking permission to reproduce this document, in whole or in part, must obtain permis-sion from the Manager, Standards Intellectual Property, IEEE Standards Activities DepartmentIEEE Standards Activities Department Manager, Standards Intellectual Property 445 Hoes LanePiscataway, NJ 08854, USAIEEE P802.11p TM /D3.03, February 2008IEEE P802.11p TM /D3.03Draft Standard for Information Technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements -Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specificationsAmendment 9: Wireless Access in Vehicular EnvironmentsPrepared by the IEEE 802.11 Working Group of the IEEE 802 CommitteeAbstract: This amendment specifies the extensions to IEEE Std 802.11™ for Wireless Local Area Net-works providing wireless communications while in a vehicular environment.Keywords: 5.9 GHz, wireless access in vehicular environments, WA VE.Copyright © 2008 IEEE. All rights reserve d.ii This is an unapproved IEEE Standards Draft, subject to changeIntroductionWA VE is a mode of operation for use by IEEE Std 802.11™ devices in environments where the physical layer properties are rapidly changing and where very short-duration communications exchanges are required. The purpose of this standard is to provide the minimum set of specifications required to ensure interoperability between wireless devices attempting to communicate in potentially rapidly changing com-munications environments and in situations where transactions must be completed in time frames much shorter than the minimum possible with infrastructure or ad hoc 802.11 networks. In particular, time frames that are shorter than the amount of time required to perform standard authentication and association to join a BSS are accommodated in this amendment.This specification accomplishes the following:•Describes the functions and services required by WA VE-conformant stations to operate in arapidly varying environment and exchange messages either without having to join a BSS orwithin a WA VE BSS.•Defines the WA VE signaling technique and interface functions that are controlled by the IEEE802.11 MACThis amendment to IEEE Std 802.11™ is based on extensive testing and analyses of wireless communica-tions in a mobile environment. The results of these efforts were documented in ASTM E 2213-03, "Stan-dard Specification for Telecommunications and Information Exchange Between Roadside and Vehicle Systems - 5.9 GHz Band Wireless Access in Vehicular Environments (WAVE) / Dedicated Short Range Com-munications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) Specifications". This docu-ment is available from: ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken,PA, 19428. This amendment to IEEE 802.11 is based on the ASTM E 2213-03 document.Please see document, 11-07-2045-00-000p-Development of DSRC/WA VE Standards, (latest version) for additional information on the development of the amendment for WA VE.Notice to usersErrataErrata, if any, for this and all other standards can be accessed at the following URL:/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for errata periodically.InterpretationsCurrent interpretations can be accessed at the following URL:/reading/ieee/interp/index.html.PatentsAttention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying pat-This introduction is not part of IEEE P802.11p, Draft Amendment to Standard for Information Technology - Telecommunications and information exchange between systems - Local and Metropolitan networks - specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifica-tions: Amendment : Wireless Access in Vehicular Environmentsents or patent applications for which a license may be required to implement an IEEE standard or for con-ducting inquiries into the legal validity or scope of those patents that are brought to its attention. A patent holder or patent applicant has filed a statement of assurance that it will grant licenses under these rights without compensation or under reasonable rates and nondiscriminatory, reasonable terms and conditions to applicants desiring to obtain such licenses. The IEEE makes no representation as to the reasonableness of rates, terms, and conditions of the license agreements offered by patent holders or patent applicants. Further information may be obtained from the IEEE Standards Department.ParticipantsThe following is a list of officers in the 802.11 Working Group.Stuart J. Kerry, ChairAl Petrick and Harry Worstell, Vice ChairsStephen McCann, SecretaryAt the time this amendment to the standard was submitted to Sponsor Ballot, the WA VE task group had the following officers:Lee Armstrong, ChairSusan Dickey, Secretary*Wayne Fisher, Editor*Note, Filip Weytjens was TGp Secretary until March 2007.Major contributions were received from the following individuals:Guillermo AcostaLee Armstrong Broady CashKen CookSusan Dickey Peter Ecclesine Tim Godfrey Mary Ann Ingram Daniel Jiang Carl KainDoug KavnerKeiichiro KogaThomas KuriharaJerry LandtSheung LiJason LiuAlastair MalarkyJustin McNewAndrew MylesRick NoensSatoshi OyamaEd RingRandy RoebuckJon RosdahlRichard RoyFrancois SimonRobert SorannoLothar StiborBryan WellsFilip WeytjensJeffrey ZhuCopyright © 2008 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change iiiThe following members of the balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention.To be supplied by IEEE staff.Copyright © 2008 IEEE. All rights reserve d.iv This is an unapproved IEEE Standards Draft, subject to changeTable of Contents1.Overview (2)1.2Purpose (2)3.Definitions (2)4.Abbreviations and acronyms (3)5.General Description (3)5.2Components of the IEEE 802.11 architecture (3)5.2.2a WAVE mode and WAVE BSSs (3)5.2.3Distribution system (DS) concepts (3)5.2.3.3DS concepts in a WAVE BSS (4)5.4Overview of the services (4)5.4.1Distribution of messages within a DS (4)5.4.1.1Distribution (4)7.Frame formats (4)7.1MAC frame formats (4)7.1.3Frame fields (4)7.2Format of individual frame types (4)7.2.3Management frames (4)7.2.3.1Beacon frame format (4)7.3Management frame body components (5)7.3.1Fields that are not information elements (5)7.3.1.3Beacon interval field (5)7.3.1.10Timestamp field (5)7.3.2Information elements (5)7.3.2.27Extended Capabilities information element (5)7.3.2.29EDCA Parameter Set element (6)7.3.2.36 WAVE Information element (WIE) (7)7.5Frame usage (7)yer management (7)10.3MLME SAP interface (7)10.3.2.2MLME-SCAN.confirm (7)10.3.3Synchronization (7)10.3.3.1 MLME-JOIN.request (8)10.3.3.2MLME-JOIN.confirm (8)10.3.9Reset (8)10.3.9.1MLME-RESET.request (8)10.3.25a Get TSF timer (8)10.3.25a.1 MLME-GETTSFTIME.request (8)10.3.25a.2 MLME-GETTSFTIME.confirm (9)10.3.25b Set TSF timer (9)10.3.25b.1 MLME-SETTSFTIME.request (10)10.3.25b.2 MLME-SETTSFTIME.confirm (10)Copyright © 2008 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change v10.3.25b.3 MLME-SETTSFTIME.indication (11)10.3.25c Increment TSFtime (11)10.3.25c.1 MLME-INCTSFTIME.request (11)10.3.25c.2 MLME-INCTSFTIME.confirm (12)10.3.42 On-demand beacon (13)10.3.42.1MLME-ONDEMANDBEACON.request (13)10.3.42.2MLME-ONDEMANDBEACON. confirm (14)10.3.42.3MLME-ONDEMANDBEACON. indication (14)11.MLME (16)11.1 Synchronization (16)11.2.2 Power management in an IBSS (16)11.18 WAVE mode management (16)11.18.1 Initializing a WAVE BSS (17)11.18.2 Joining a WAVE BSS (17)11.18.3 TSF in WAVE mode (18)17.Orthogonal frequency division multiplexing (OFDM) PHY specification for the 5 GHz band (18)17.3 OFDM PLCP sublayer (18)17.3.8PMD operating specifications (general) (18)17.3.8.8Transmit and receive operating temperature range (18)17.3.9PMD transmit specifications (18)17.3.9.4Transmit center frequency tolerance (18)17.3.9.5Symbol clock frequency tolerance (18)17.3.10.2Adjacent channel rejection (19)17.3.10.3Nonadjacent channel rejection (19)17.4 OFDM PLME (19)17.4.1PLME_SAP sublayer management primitives (19)Annex A (20)(normative) Protocol Implementation Conformance Statement (PICS) proforma (20)A.4 PICS proforma--IEEE Std 802.11™—2007 Edition (20)A.4.3 IUT Configuration (20)A.4.8 OFDM PHY function (22)A.4.15 QoS enhanced distributed channel access (EDCA) (23)Annex D (23)(normative) ANS.1 encoding of the MAC and PHY MIB (23)Annex I (28)(informative) Regulatory classes (28)I.1 External regulatory references (28)I.2.2 Transmit power levels (29)I.2.3 Transmit spectrum mask (29)Annex J (33)(normative) Country information element and regulatory classes (33)Copyright © 2008 IEEE. All rights reserve d.vi This is an unapproved IEEE Standards Draft, subject to changeFigure 7-76a Capabilities field first octet (6)Figure 7-95a WAVE Information element format (7)Figure 11-23 WAVE Announcement process (17)Figure I.3 Class A transmit spectrum mask (31)Figure I.4 Class B transmit spectrum mask (31)Figure I.5 Class C transmit spectrum mask (32)Figure I.6 Class D transmit spectrum mask (32)Copyright © 2008 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change viiTable 7-8 Beacon frame body (5)Table 7-26 Element IDs (5)Table 7-37a Default EDCA parameter set for WAVE BSS (6)Table 17 -13a WAVE enhanced receiver performance requirements (19)Table 17 -14 MIB attribute default values/ranges (19)Table I.1 Regulatory requirement list (28)Table I.2 Emissions limits sets (28)Table I.3 Behavior limits sets (29)Table I.4 Transmit power level by regulatory domain (29)Table I.7 Class A thru Class D spectrum masks (30)Table J.1 Regulatory classes in the USA (33)Copyright © 2008 IEEE. All rights reserve d.viii This is an unapproved IEEE Standards Draft, subject to changeIEEE P802.11p TM/D3.03Draft Standard for Information Technology - Telecommunications and information exchange between systems -Local and metropolitan area networks -Specific requirements -Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specificationsAmendment 9: Wireless Access in Vehicular Environments[This amendment is based on IEEE Std 802.11TM -2007 as amended by P802.11k-D9.0, P802.11r-D8.0, P802.11y-D6.0, P802.11w-D3.0, P802.11n-D3.0, P802.11u-D1.0, and P802.11s-D1.0.]NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into the existing base standard and its amendments to form the comprehensive standard.The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace. Change is used to make corrections in existing text or tables. The editing instruction specifies the location of the change and describes what is being changed by using strikethrough (to remove old mate-rial) and underscore (to add new material). Delete removes existing material. Insert adds new material with-out disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is used to make changes in figures or equations by removing the existing figure or equation and replacing it with a new one. Editing instructions, change markings, and this NOTE will not be carried over into future editions because the changes will be incorporated into the base standard.Copyright © 2008 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.Wireless Access in Vehicular Environments Draft P802.11p/D3.03, February 2008Copyright © 2008 IEEE. All rights reserved .2This is an unapproved IEEE Standards Draft, subject to change.1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253 1. Overview 1.2 Purpose Change the first indented statement as follows:— Describes the functions and services required by an IEEE 802.11™-compliant device to operate within ad hoc and infrastructure networks including the aspects of STA mobility (transition) within those networks and the functions and services required by an IEEE 802.11™-compliant device to operate in rapidly varying environments (Wireless Access in Vehicular Environments (WA VE)).3. Definitions Change the text as follows:3.16 basic service set (BSS): A set of stations (STAs) that have successfully synchronized using the JOIN service primitives and one STA that has used the START primitive or the ONDEMANDBEACON primitive. Membership in a BSS does not imply that wireless communication with all other members of the BSS is possible.Insert the following new definitions:3.168a WAVE basic service set (WAVE BSS): A set of cooperating stations operating in WA VE mode consisting of a single WA VE STA that transmits a WA VE beacon and zero or more WA VE STAs that join this WA VE BSS. 3.168b WAVE information element (WIE): An information element that contains information provided by the MAC through the MLME_SAP.Note — Zero or more WIEs are included in the WA VE beacon.3.168c WAVE mode: A station (STA) is in WA VE mode when the MIB attribute dot11WA VEEnabled is true. Note — Two WA VE mode STAs may communicate within the context of a WA VE BSS or may communicate without belonging to a BSS.3.168d On-demand beacon: A beacon frame for which the On-demand beacon bit of the Extended Capabilities information element (see 7.3.2.27) is set to 1. Note — Only one On-demand beacon frame is transmitted per MLME-ONDEMANDBEACON.request from the SME. 3.168e WAVE beacon: An On-demand beacon frame for which the WA VE indication bit of the Extended Capabilities information element is set to 1, sent by a WA VE mode STA.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 544. Abbreviations and acronymsInsert the following new abbreviations and acronyms in alphabetical order:WA VE wireless access in vehicular environmentsWIE WA VE information element5. General Description5.2 Components of the IEEE 802.11 architectureInsert a new subclause (5.2.2a) after 5.2.2 renumbering as necessary:5.2.2a WAVE mode and WAVE BSSsWireless Access in Vehicular Environments (WA VE) is a mode of operation that enables the use of IEEE Std 802.11™ devices in vehicular environments. These rapidly changing environments typically involve mobile STAs that move much faster (up to 200 km/h) than a STA participating in an infrastructure BSS or IBSS. Additionally, the interval over which the communication exchanges take place may be of very short-duration (e.g measured in milliseconds). A STA is in WA VE mode if and only if the MIB attribute dot11WA VEEnabled is true. The need to enter WA VE mode is determined by upper layers, which are also responsible for system management and security. WA VE communication may take place in a frequency band that is dedicated for its use. Such a band may require licensing depending on the regulatory domain.A STA in WA VE mode may send a data frame in the context of a WA VE BSS, using the WA VE BSS's BSSID. It may also send a data frame outside of the context of a BSS, using the wildcard BSSID (see 7.1.3.3.3), and it may alternate between the two on a frame-by-frame basis.•Communication within a WA VE BSS allows a LAN to be setup quickly, a capability required in a rapidly changing communication environment. A WA VE beacon establishes or maintains a WA VE BSS (see subclause 11.18.1). A STA in WA VE mode may elect to join an established WA VE BSS (see 11.18.2), and may optionally synchronize to the WA VE BSS (See 11.18.3). Each WA VE BSS consists of the STA that establishes the WA VE BSS and zero or more STAs that have joined the WA VE BSS.The delay in joining a WA VE BSS is reduced compared to an infrastructure BSS because MAC level authentication and association do not apply to a WA VE BSS. Security services are deferred to higher layers.•WA VE mode allows communication outside the context of a BSS. A STA in WA VE mode may simply send a data frame directly over the wireless medium, to one or more STAs in WA VE mode, using an individual or broadcast/multicast MAC address.5.2.3 Distribution system (DS) conceptsInsert the following new subclause (5.2.3.3) after subclause 5.2.3.2:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 535.2.3.3 DS concepts in a WAVE BSSMAC sub-layer authentication and association services may be provided by a station management entity or protocol layer above the MAC. Neither function is required in order for a WA VE BSS STA to communicate over a DS. A STA that is a member of a WA VE BSS may access a DS directly.A STA using a non-BSS approach sets the "To DS" and "From DS" bits to 0 (Table 7-7). i.e.; it does not communicate directly with a DS.5.4 Overview of the services5.4.1 Distribution of messages within a DS5.4.1.1 DistributionChange the first paragraph of 5.4.1.1 as follows:This is the primary service used by IEEE 802.11 STAs. It is conceptually invoked by every data message to or from an IEEE 802.11 STA operating in an ESS (when the frame is sent via the DS). Distribution is via the DSS. WA VE BSSs do not use the DSS supported by the IEEE 802.11 MAC (see 5.2.3.3).7. Frame formats7.1 MAC frame formats7.1.3 Frame fields7.1.3.3.3 BSSID fieldInsert after the second paragraph of 7.1.3.3.3The value of the BSSID field in a WA VE BSS shall be a locally administered IEEE MAC address. Change the last sentence of the last paragraph of 7.1.3.3.3 to:A wildcard BSSID shall not be used in the BSSID field except for management frames of subtype probe request in the following two cases:1. Management frames of subtype Probe request2. Data frames transmitted in WA VE mode7.2 Format of individual frame types7.2.3 Management frames7.2.3.1 Beacon frame formatInsert the following after the last sentence of sub-clause 7.2.3.1In WA VE mode, the WA VE beacon includes zero or more WA VE information elements.1 23 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54Insert the following information elements into Table 7-8:Table 7-8—Beacon frame body7.3 Management frame body components7.3.1 Fields that are not information elements7.3.1.3 Beacon interval fieldInsert the following after the first sentence of subclause7.3.1.3:This field is not specified in WA VE mode.7.3.1.10 Timestamp fieldChange the first sentence as follows:This field represents the value of the timing synchronization function (TSF) timer (see 11.1 and 11.18) of a frame's source.7.3.2 Information elementsInsert the WIE into Table 7-26 - Element IDs.Table 7-26—Element IDs7.3.2.27 Extended Capabilities information elementEDITORIAL NOTE - The changes made to this IEEE 802.11 Std 2007 subclause are consistent with changes made by TGn and TGy.Change the first paragraph of subclause 7.3.2.27 as follows:Order Information Notes24a Extended Capabilities The Extended Capabilities information element carries information of an802.11 STA to augment the Capability Information Field.24b WIE The WIE contains information provided to the MAC through theMLME_SAP. Zero or more WIEs may be included in the WA VEbeacon.Information Element Element ID Length (in octets)WIE (see 7.3.2.36)69 3 to 2571 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53The Extended Capabilities information element carries information about the capabilities of an IEEE 802.11 STA intended to and augments the Capability Information field (CIF) when these bits are fully allocated. The format of this information element is shown in Figure 7-76.Change the last paragraph of subclause 7.3.2.27 as follows:The Capabilities field is a bit field indicating the capabilities being advertised by the STA transmitting the information element. There are no capabilities defined for this field in this revision of the standard. One octet of extended information has been defined. The format of that octet is shown in Figure 7-76a.EDITORIAL NOTE—In Figure 7-76a bit B0 is reserved for TGn and bit B2 is reserved for TGy.Insert in Figure 7-76a B1 and B3 as follows:.Figure 7-76a—Capabilities field first octet— Bit 1: On-demand beacon. When the on-demand bit in the first octet of the Capabilities field is set to 1, the beacon transmission is initiated by the station management entity (SME) and indi-cates an On-demand beacon.— Bit 3: WA VE indication. If MIB attribute dot11WA VEEnabled = true, then the WA VE indication bit in the first octet of the Capabilities field is set to 1, otherwise it is set to 0.7.3.2.29 EDCA Parameter Set elementInsert the following new paragraph and table at the end of subclause 7.3.2.29:WA VE prioritized access operations uses the EDCA mechanism. The default EDCA parameter set used in the WA VE beacon is defined in Table 7-37a. The default EDCA parameter set shall be used for all STAs when transmitting data frames in the absence of a WA VE BSS. For data exchanges within a WA VE BSS, the EDCA parameter set received in the WA VE beacon shall be used.Table 7-37a—Default EDCA parameter set for WAVE BSSB0B1B2B3B4B7 Reserved On-demandbeaconReserved WA VEindicationReserved Bits11111111ACI CWmin CWmax AIFSNTXOP LimitOFDM/CCK-OFDM PHY00aCWmin aCWmax9001(aCWmin+1)/2 - 1aCWmin6010(aCWmin+1)/4 - 1(aCWmin+1)/2 - 13011(aCWmin+1)/4 - 1(aCWmin+1)/2 - 1201 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54Insert the following new subclause (7.3.2.36) after subclause 7.3.2.35:7.3.2.36 WAVE Information element (WIE)The WIE is present only in the WA VE beacon frame. The WIE format is shown in Figure 7-95a..Figure 7-95a—WAVE Information element formatThe WIE content field contains management information indicating details to the Station Management Entity (SME) that are outside the scope of this standard. There may be multiple WIEs required to convey all the management information to the SME.7.5 Frame usageInsert, after Table 7-58, the following:The usage of frames subtypes while in WA VE mode is the same as shown in the IBSS columns of Table 7-58, except that ATIM, Authentication, Deauthentication, and Deassociation frames are not used. The WA VE beacon is transmitted on demand from protocol layers above the MAC. WA VE mode does not preclude the use of management frames that do not require authentication and association.10. Layer management10.3 MLME SAP interface10.3.2.2 MLME-SCAN.confirm10.3.2.2.2 Semantics of the service primitiveInsert the following row in the BSSDescription table:10.3.3 SynchronizationChange the subclause as follows:This mechanism supports the process of selection of a peer in the authentication process.Element ID Length ContentOctets11variableName TypeValidRange DescriptionExtended Capabilitiesinformation elementAs defined inframe formatAs definedin frameformatThe Extended Capabilities information elementcarries information about the capabilities of anIEEE 802.11 STA, to augment the CapabilityInformation field.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 5310.3.3.1 MLME-JOIN.request10.3.3.1.1 FunctionChange the subclause as follows:This primitive requests synchronization with or setting parameters corresponding to a BSS.10.3.3.2 MLME-JOIN.confirm10.3.3.2.1 FunctionChange the subclause as follows:This primitive confirms synchronization with or setting parameters corresponding to a BSS.10.3.9 Reset10.3.9.1 MLME-RESET.request10.3.9.1.4 Effect of receiptInsert the following text at the end of 10.3.9.1.4:If the MIB attributes are not being set to their default values, WA VE MAC operation in WA VE capable STAs shall resume in less than 2 TUs after changing the value of the locally administered MAC address.Insert the following new subclauses (10.3.25a, 10.3.25b, and 10.3.25c) after subclause 10.3.25 adjusting the subclause numbers as necessary:10.3.25a Get TSF timerThis mechanism is used to request the current value of the TSF timer that the STA maintains.10.3.25a.1 MLME-GETTSFTIME.request10.3.25a.1.1 FunctionThis primitive is generated by the SME to request that the MLME return the value of its TSF timer. The value returned shall be the value of the TSF timer at the instant the MLME-GETTSFTIME.request is received as specified in 10.3.25a.2.1.10.3.25a.1.2 Semantics of the service primitiveThis primitive has no parameter.MLME-GETTSFTIME.request()1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 5410.3.25a.1.3 When generatedThis primitive is generated by the SME to request the value of the TSF timer from the MLME.10.3.25a.1.4 Effect of receiptThe MLME issues an MLME-GETTSFTIME.confirm.10.3.25a.2 MLME-GETTSFTIME.confirm10.3.25a.2.1 FunctionThis primitive is generated by the MLME to report to the SME the result of a request to get the value of the TSF timer.10.3.25a.2.2 Semantics of the service primitiveThis primitive uses the following parameters:MLME-GETTSFTIME.confirm(ResultCode,TSFtime,)10.3.25a.2.3 When generatedThis primitive is generated by the MLME to report to the SME the result of an MLME-GETTSF-TIME.request.10.3.25a.2.4 Effect of receiptThe SME is notified of the result of an MLME-GETTSFTIME.request and, if successful, has the value of the TSF timer at the instant the MLME-GETTSFTIME.request was received by the MLME.NOTE—The TSF timer value can be used, along with other information, by higher layer functions to synchronize to external clock sources such as Universal Coordinated Time (UTC) from a Global Positioning System (GPS) unit.10.3.25b Set TSF timerThis mechanism is used to set the value of the TSF timer that the STA maintains.Name Type Valid Range DescriptionResultCode Enumeration SUCCESS,FAILUREReports the outcome of GETTSFTIME request. TSFtime Integer0 - (264 -1)Value of the TSF timer.。
IEEE 802 协议简介

IEEE 802 协议简介IEEE 802.1d, STP算法IEEE 802.1w, RSTP算法IEEE 802.1s, MSTP算法IEEE 802.1P,讲述的是交换机与优先级相关的流量处理的协议。
IEEE 802.1q,虚拟桥接局域网协议,定义了VLAN以及封装技术,包括GARP协议及其源码、GVRP源码IEEE 802.11 无线局域网IEEE 802.2 LLC (Logical Link Control,逻辑链路控制)IEEE 802.3 是一篇非常重要的业界规范文档。
其中最主要的就是规定了以太网的电气指标,从物理层的电路结构到链路层的MAC操作都有介绍。
IEEE是电气和电子工程师协会(Institute of Electrical and Electronics Engineers)的简称,IEEE组织主要负责有关电子和电气产品的各种标准的制定。
IEEE于1980年2月成立了IEEE 802委员会,专门研究和指定有关局域网的各种标准。
IEEE 802委员会由6个分委员会组成,其编号分别为802.1至802.6,其标准分别称为标准802.1至标准802.6,目前它已增加到12个委员会,这些分委员会的职能如下:802.1--高层及其交互工作。
提供高层标准的框架,包括端到端协议、网络互连、网络管理、路由选择、桥接和性能测量。
802.2--连接链路控制LLC,提供OSI数据链路层的高子层功能,提供LAN 、MAC子层与高层协议间的一致接口。
802.3--以太网规范,定义CSMA/CD标准的媒体访问控制(MAC)子层和物理层规范。
802.4--令牌总线网。
定义令牌传递总线的媒体访问控制(MAC)子层和物理层规范。
802.5--令牌环线网,定义令牌传递环的媒体访问控制(MAC)子层和物理层规范。
802.6--城域网MAN,定义城域网(MAN)的媒体访问控制(MAC)子层和物理层规范(D QDB分布队列双总线)。
IEEE-80211协议详细介绍

协议X档案:IEEE 802.11协议详细介绍作为全球公认的局域网权威,IEEE 802工作组建立的标准在过去二十年内在局域网领域内独领风骚。
这些协议包括了802.3 Ethernet协议、802.5 Token Ring协议、802.3z 100BASE-T快速以太网协议。
在1997年,经过了7年的工作以后,IEEE发布了802.11协议,这也是在无线局域网领域内的第一个国际上被认可的协议。
在1999年9月,他们又提出了802.11b"High Rate"协议,用来对802.11协议进行补充,802.11b在802.11的1Mbps和2Mbps 速率下又增加了 5.5Mbps和11Mbps两个新的网络吞吐速率,后来又演进到802.11g的54Mbps,直至今日802.11n的108Mbps。
802.11a高速WLAN协议,使用5G赫兹频段。
最高速率54Mbps,实际使用速率约为22-26Mbps与802.11b不兼容,是其最大的缺点。
也许会因此而被802.11g淘汰。
802.11b目前最流行的WLAN协议,使用2.4G赫兹频段。
最高速率11Mbps,实际使用速率根据距离和信号强度可变(150米内1-2Mbps,50米内可达到11Mbps)802.11b的较低速率使得无线数据网的使用成本能够被大众接受(目前接入节点的成本仅为10-30美元)。
另外,通过统一的认证机构认证所有厂商的产品,802.11b设备之间的兼容性得到了保证。
兼容性促进了竞争和用户接受程度。
802.11e基于WLAN的QoS协议,通过该协议802.11a,b,g能够进行VoIP。
也就是说,802.11e是通过无线数据网实现语音通话功能的协议。
该协议将是无线数据网与传统移动通信网络进行竞争的强有力武器。
802.11g802.11g是802.11b在同一频段上的扩展。
支持达到54Mbps的最高速率。
兼容802.11b。
IEEE802协议(详细介绍)

IEEE802协议集介绍(802.1~802.21)TCP/IP协议(Transfer Controln Protocol/Internet Protocol)叫做传输控制/网际协议,又叫网络通讯协议,这个协议是Internet国际互联网络的基础。
TCP/IP协议世界上有各种不同类型的计算机,也有不同的操作系统,要想让这些装有不同操作系统的不同类型计算机互相通讯,就必须有统一的标准。
TCP/IP协议就是目前被各方面遵从的网际互联工业标准。
TCP/IP是网络中使用的基本的通信协议。
虽然从名字上看TCP/IP包括两个协议,传输控制协议(TCP)和网际协议(IP),但TCP/IP实际上是一组协议,它包括上百个各种功能的协议,如:远程登录、文件传输和电子邮件等,而TCP协议和IP协议是保证数据完整传输的两个基本的重要协议。
通常说TCP/IP是Internet协议族,而不单单是TCP和IP。
TCP/IP是用于计算机通信的一组协议,我们通常称它为TCP/IP协议族。
它是70年代中期美国国防部为其ARPANET广域网开发的网络体系结构和协议标准,以它为基础组建的INTERNET是目前国际上规模最大的计算机网络,正因为INTERNET的广泛使用,使得TCP/IP成了事实上的标准。
之所以说TCP/IP是一个协议族,是因为TCP/IP协议包括TCP、IP、UDP、ICMP、RIP、TELNETFTP、SMTP、ARP、TFTP等许多协议,这些协议一起称为TCP/IP协议。
以下我们对协议族中一些常用协议英文名称和用途作一介绍:TCP(Transport Control Protocol)传输控制协议IP(Internetworking Protocol)网间网协议UDP(User Datagram Protocol)用户数据报协议ICMP(Internet Control Message Protocol)互联网控制信息协议SMTP(Simple Mail Transfer Protocol)简单邮件传输协议SNMP(Simple Network manage Protocol)简单网络管理协议FTP(File Transfer Protocol)文件传输协议ARP(Address Resolation Protocol)地址解析协议从协议分层模型方面来讲,TCP/IP由四个层次组成:网络接口层、网间网层、传输层、应用层。
远动规约报文详解(最详尽的解释)

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- IEC-60870-5-104:应用模型是:物理层,链路层,网络层,传输层,应用层物理层保证数据的正确送达,保证如何避免冲突。
(物理层利用如 RS232上利用全双工)链路层负责具体对那个slAvE的通讯,对于成功与否,是否重传由链路层控制(RS485 2线利用禁止链路层确认)应用层负责具体的一些应用,如问全数据还是单点数据还是类数据等(网络利用CSMA/CD等保证避免冲突的发生)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 基本定义:端口号2404,站端为SErvEr 控端为CliEnt,平衡式传输,2BytE站地址,2BytE传送原因,3BytE信息地址。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 注:APDU 应用规约数据单元(整个数据)= APCI 应用规约控制信息(固定6个字节)+ ASDU 应用服务数据单元(长度可变)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- APDU长度(系统-特定参数,指定每个系统APDU的最大长度)APDU的最大长度域为253(缺省)。
IEEE 802.16 WIMAX介绍解读

海南大学信息学院
目录
•
802.16标准简介
IEEE 802.16:宽带无线 MAN 标准 -WiMAX (Broadband Wireless MAN Standard - WiMAX) • IEEE 802.16 是为用户站点和核心网络(如:公共电话网 和 Internet)间提供通信路径而定义的无线服务。无线 MAN 技术也称之为 WiMAX。这种无线宽带访问标准解决 了城域网中“最后一英里”问题 • 根据是否支持移动特性, IEEE 802.16标准可以分为固定 宽带无线接入空中接口标准和移动宽带无线接入空中接口 标准,其中802.16a、802.16d属于固定无线接入空中接口 标准,而802.16e 、802.16e属于移动宽带无线接入空中 接口标准
IEEE 802.16
IEEE 目录 802简介源自• IEEE 802又称为LMSC(LAN /MAN Standards Committee,局域网/城域网标准 委员会),致力于研究局域网和城域网的 物理层和MAC层规范,对应OSI参考模型的 下两层。 LMSC执行委员会(Executive Committee)下设工作组(Working Group)、研究组(Study Group)、技术 顾问组(Technical Advisory Group)。曾 经设立的多个SG已经合并到WG中,目前 活跃的WG和TAG如下:
海南大学信息学院
IEEE 目录 802简介
• • • • • • • • • • • • • 802.1 :高层局域网协议Higher Layer LAN Protocols 802.2 :逻辑链路控制Logical Link Control 802.3 :以太网Ethernet 802.4 :令牌总线Token Bus 802.5 :令牌环Token Ring 802.11:无线局域网Wireless LAN 802.15:无线个域网 Wireless Personal Area Network 802.16:宽带无线接入 Broadband Wireless Access 802.17:弹性分组环 Resilient Packet Ring 802.18:无线管制 Radio Regulatory TAG 802.19:共存 Coexistence TAG 802.20:移动宽带无线接入 Mobile Broadband Wireless 802.21:媒质无关切换 Media Independent Handoff
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Wireless RANsWireless Regional Area NetworksAtlanta SessionNovember 2009MINUTESNew Contributions:22-09-0217-02-0000-802-22-wg-tentative-agenda-november-2009.xls22-09-0120-16-0000 WRAN Draft 2.0 Ballot Comments Database.xls22-09-0120-17-0000 WRAN Draft 2.0 Ballot Comments Database.xls22-09-0219-00-0000-ieee-802-22-wg-opening-report-november-2009.ppt18-09-0118-00-0000-ofcom-update-on-the-tv-white-space-issues.ppt22-09-0159-10-0000-modified-ieee-p802-22-par-and-5c.doc22-09-0165-08-0000-ieee-p802-22-3-draft-par-and-5c.doc22-09-0123-15-0000-802-22-incumbent-database-interface.doc22-09-0207-00-0000-phy-status-and-remaining-issues.doc22-09-0223-00-0000-mac-ad-hoc-group-report-november-2009.doc22-09-0201-01-0000-mibs-and-management-primitives-outline.doc22-09-0202-01-0000-mibs-and-management-primitives-description.doc22-09-0210-03-0000-system-level-issues-and-comments-pertinent-to-sections-7-and-9-of-the-802-22-draftv2-0.doc22-09-0229-00-0000-802-22-wg-comments-on-802-11-tvws-par-5c.doc22-09-0230-00-0000-802-22-wg-comments-on-802-19-tvws-coexistence-par-5c.doc22-09-0206-00-0000-proposed-modifications-on-802-22-3-pars.ppt…November 16, Monday PM1 (WG Opening Plenary)The WG Chair called the meeting to order at 1:30pm.The Chair reviewed the agenda of the week (22-09-0217-00-0000). Winston asked that the “Geolocation” meeting on PM1 be renamed: “Database Interface”. The agenda was approved as modified by unanimous consent. Revision 1 was uploaded to MentorThe Chair reviewed the minutes (22-08-0199-00-0000)of the Hawaii Interim Session of September 2009. The minutes were approved by unanimous consent.The chair displayed the motions that were passed in September on the screen for re-affirmation as documented in the minutes of the Hawaii Interim Session of September 2009 (Doc: 22-08-0199-00-0000)The chair asked the group if there was any objection to re-affirming these motions: no objection was expressed. All these motions were re-affirmed.The minutes on the September interim session were approved by unanimous consent.The Chair introduced the five-slide patent policies. The slides were shown and read by the Chair.Inappropriate topics for IEEE WG meetings: the usual slide was shown.The Anti-trust statement and ethics slide was presented and read by the Chair.IEEE-SA Letters of Assurance (LOA) on patents: the Chair reminded everyone of the duty to submit a LOA.–Gerald Chouinard asked if there was any update on the LOAs related to the use of a memory at the antenna to indicate the antenna gain for each channel and the interface between this memory and the CPE.–The chair indicated that there was nothing new to report.It was explained that attendance is recorded electronically using the Web-based IEEE Attendance Tool. The assumption is that 75% of the time needs to be spent in a meeting for the participant to be considered present during that meeting and 75% of the meeting slots count towards the voting rights.Documentation requirements:The WG Chair explained that the WG members need to use the templates and follow their built-in directions. He mentioned that there are still some members who do not follow the templates, and reminded the WG members that they should not create a new document by modifying an existing one. The Chair further mentioned that all documents should be submitted to the Mentor document system (https:///mentor/wiki/StartPage).Other Announcements: None.There were three new participants:- from Rice University interested in cognitive radio,- from NICT, Japan, for the 802.22.3 project, and- from Honeywell related to White Space products.Report from 802.18:Winston Caldwell indicated that he was not sure what 802.18 had on its plate for the November session.Report from 802.19:Steve Shellhammer indicated that there was a PAR to be submitted to EC on TV White Sp ace coexistence, the WG had reviewed other groups’ PAR’s, especially on TV White Space and reacted to comments received. The TAG is to meet on Wednesday PM2 whereas the WG will be dealing with its PAR on Wednesday AM1 and PM1.Report from IEEE-BTS: NoneReport from MSTV/NAB: Victor Tawil indicated that there was a lot of activities on the broadband initiative (National Broadband Plan for the US, a report is due to the Congress by February) and the possible use of the TV White Space. There was a proposal to re-allocate a portion of the TV band below channel 51 for licensed use. The FCC has a Web site on this broadband initiative.Report from NABA: NoneReport from ad-hoc groups:System group:Gerald Chouinard indicated that topics from the ad-hoc groups that are felt to go beyond their immediate responsibility because it cuts across more than one ad-hoc group or it is related to a system aspect are deferred to the the system group. Furthermore, all comments in sections 1-5 and 10, 11 and the annexes are to be dealt with by the system group.PHY group: see doc. 09-207 for a status of the PHY comment resolution. (Zander had not arrived yet).MAC group: see doc. 09-223 for a status of the PHY comment resolution. There were 7 teleconferences since the September session. All comments have been reviewed once. These comments were to be re-visited during the week. A list of items to be dealt with by the system group has been listed at the end of the document. Wendong Hu quickly explained these system topics.Cognitive and Security group:Apurva Mody gave an overview of the “security and management plane procedure”: all T and TR and Ivan Reede’s comments had been reviewed and most had been resolved. Most resolutions could be sent for ballot confirmation.MIBs development has been dealt with in documents 22-09-201 and 22-09-202. It may be possible to include MIBs in this Draft. The MIB section may not need to be comprehensive right away but will be augmented in time. Cognitive aspects: there are many issues listed in document 22-09-210 that need to be referred to the system group. These systems issues need to be resolved before making progress in the cognitive section. A few examples of these system issues are:-capability for the operator to generate his own certificate,-why we need security in CBP-need for synchronized sensing-impact on theTG1 beacon sensing.Coexistence group: Jianfeng could not make it in Atlanta. He sent an email to Wendong and Gerald on 12 Nov. summarizing the status of the coexistence discussion.Database group: Winston Caldwell explained that a document was produced in Hawaii in September and it was approved and released to other interested 802 WGs (.11, .16, .18 and .19). It was also informally presented to the WSDB group (Google, etc.) An informal response was also produced by this WSDB group. The agenda for the week was to review this response, consider some possible adjustment of the database interface in the 802.22 Draft and produce an answer to the WSDB group. Victor Tawil was asked to be the liaison between 802.22 and the WSDB group. The chair asked whether this group should hold teleconference calls between sessions. This was found not to be necessary.Report from TG1:Gregory Buchwald, Interim Chair of TG1, reported that almost all comments have been resolved. Only 30 comments are left to be decided. The plan was that the modified Draft would be prepared for the end of the week for approval by the WG to be-sent to the sponsors so that it is ready to go to REVCOM in March.Report from TG2: Winston Caldwell, the Chair of TG2, reported that 22-09-242r36 will be on Mentor and the meeting to be held this week will be to review the document on the draft Recommended Practice.Confirmation of the TG1 chair:Baowei Ji resigned as chair of TG1. The chair appointed Greg Buchwald as the interim chair of TG1.Results of the comment resolution confirmation ballot:Gerald reported that 20 out of 35 votes returned their ballot. 98% of the resolutions were confirmed (3 failed over a total of 178).Results of the PARs confirmation:Wendong reported that PARs re-affirmation ballot were confirmed by more than 96%Plan of work for the w eek:The chair presented the work plan for the week. He indicated that the 802.22 comments on the other PARs need to be sent to the EC members by Tuesday 5:00pm whereas the response on comments from the EC members is due by Wednesday, 5:00pm. As a result of the comments that will be received from the other EC members, the WG will likely need to make other changes to the two PARs and will need to vote on it again.The other objectives for the week are advancing the comment resolution for the main WG and TG1 and make progress in TG2.The meeting was recessed at 3:33pm.November 16, Monday PM2 (WG System Issues)The WG Chair called the meeting to order at 4:04pm.Gerald presented the spreadsheet summarizing the results of the recent comment confirmation ballot and commented on comment resolution discrepancies. He mentioned that an "Abstain" given by a voter on his own comment is not valid and should either be a "yes" or "no", and asked the members to get back to him with the right selection response.A discussion relating to the comment status "superceded" took place based on the fact that a comment being superceded by another one that has not been accepted or countered yet cannot really be accepted as being superceded since the status of the other comment has not been finalized. This may create some delay in advancing the comment confirmation process. The editor will work on a means to resolve it.Another concern was expressed as to the way to deal with comments that have already been closed by the commenter. It was suggested that the WG has to vote on it independently of whether the commenter is happy with the proposed resolution or not.Gerald asked if anyone had any objection to break up the current section 6.22 on co-existence, into incumbent protection and self co-existence. There was no objection. This will be done using Apurva Mody, Thomas Kiernan ER comment (#610 and #612) as a vehicle.Jinnan Liu presented her contribution: 22-09-0215 on Synchronized quiet periods. The group decided to postpone the issue on including Jinnan’s technique into the standard until some key systems iss ues were resolved.The meeting was recessed at 6:04pm.November 17, Tuesday AM1Parallel meetings of the PHY, MAC and Security ad-hoc groups took place. No minutes were kept.November 17, Tuesday AM2Parallel meetings of the PHY, MAC and Security ad-hoc groups took place. No minutes were kept.November 17, Tuesday PM1 (WG System/PAR Issues)The WG Chair called the WG meeting to order at 1:40pm.The chair presented a modified agenda where the PM1 slot was to be used for a WG meeting to discuss 802.22 comments on other WGs’ PARs with a PM2 system group meeting and new WG meeting scheduled for the evening to discuss comments from other WGs on the 802.22 PARsApurva and Winston raised the point that since the evening WG meeting on Tuesday was not announced, it should not count toward voting rights.Straw poll regarding the evening session: there were 5 votes in favor of the evening meeting, 1 opposed and 1 vote for an optional attendance. After some discussion, no one opposed an optional attendance.TG1 has completed its face-to-face meetings earlier in the day. There are still some inputs expected for the resolution of some comments.Document 11-09-934 on the 802.11 PAR was discussed. Wendong took notes based on revision 3 which was the one submitted by the 802.11WG and to the ECItem 5.2: - Scope should include protection of incumbents: Add the words from the 802.22.3 scope to 802.11 scope: “ … and provide mechanism …”Item 5.4: “… extend the 802.11 technology”Item 5.5: “… while providing protection to incumbents”Item 5C: change “technical” for “technical feasibility”Move that document 22-09-229 which contains the comments on the 802.11 PAR and 5C (Doc. 11-09-934r3) on TV White Space be approved and that the 802.22 chair send it to the chair of 802.11 and the 802 EC Move: Apurva ModySecond : Gerald ChouinardMotion passes with unanimous consent.The meeting was recessed at 3:35pm.November 17, Tuesday PM2The WG Chair called the meeting to order at 4:08pm. Document 19-09-78r4 was reviewed and a list of comment was prepared on the 802.19 PAR on TV White Space.Move that document 22-09-230 which contains the comments on the 802.19 PAR and 5C (Doc. 19-09-229r3) on TV White Space be approved and that the 802.22 chair send it to the chair of 802.19 and the 802 EC Move: Victor TawilSecond : Robert WuMotion passes with unanimous consent.The meeting was recessed at 6:01pm.November 17, Tuesday evening WG PAR issuesThe WG Chair called the meeting to order at 7:50pm.Comments from other WGs on the 802.22 and 802.22.3 PARs were reviewed and discussed. Revisions were included in document 09-236 for the modified 802.22 PAR and in document 09-206 for the new 802.22.3 PAR. The meeting was recessed at 10:00pm.November 18, Wednesday AM1The WG Chair called the meeting to order at 8:09am.Discussions continued on the resolution of comments on the 802.22 PARs from the other WGs and EC members. The meeting was recessed at 10:01am.November 18, Wednesday AM2Parallel meetings of the PHY, MAC and Security ad-hoc groups took place. No minutes were kept.The meeting was recessed at 10:00am.November 18, Wednesday PM1 (System ad-hoc group)Gerald called the meeting to order at 1:40pm.The group dealt with some MAC system issues but most needed Wendong who was not present. Resolutions were documented in the comment database 09-120r17.The meeting was recessed at 3:16pm.November 18, Wednesday PM2 (WGmeeting)The WG Chair called the meeting to order at 4:10pm.The discussion on the refinement of the two 802.22 PARs was finalized.Move to approve documents 09-236 on the modified 802.22 PAR and document 09-237 on the new 802.22.3 PAR and grant editorial privilege to the vice-chair.Move: Tom GurleySecond: Victor TawilFor: 13 Against: 0 Abstain: 0Move to approve the version of the 802.22 PAR as modified in document 22-09-0159r10 and authorize the chair to forward it to the EC members.Mover: Victor TawilSecond: Tom GurleyFor: 12 Against: 0 Abstain: 0Move to approve the version of the 802.22.3 as modified in document 22-09-0165r8 and authorize the chair to forward it to the EC members.Mover: Tom GurleySecond: Gerald ChouinardFor: 11 Against: 0 Abstain: 0The meeting was recessed at 6:05pm.November 19, Thursday AM1Parallel meetings of the PHY, MAC and Database ad-hoc groups took place. No minutes were kept.November 19, Thursday AM2Parallel meetings of the PHY, MAC and System ad-hoc groups took place. No minutes were kept.November 19, Thursday PM1Parallel meetings of the System, cognitive radio and coexistence ad-hoc groups took place.No minutes were kept.November 19, Thursday PM2Parallel meetings of the System, cognitive radio and coexistence ad-hoc groups took place. No minutes were kept.November 20, Friday AM1A meeting of the System ad-group took place. No minutes were kept.November 20, Friday AM2 (WG Closing Plenary)The WG Chair called the meeting to order at 10:37am.The Chair reviewed the agenda of the closing plenary. It was approved by unanimous consent.Item 5.1: noneItem 5.2: noneAny announcement: None.Item 6.1.1: New documents: all documents are found on Mentor. The new version of the comment database as updated during the Atlanta session (#09-120r17) will be posted on Mentor next week as well as the documents on the PARs.Item 6.1.2: Current P&P of 802.22: when the 802 P&P are ready and approved, they will have to be used and the current 802.22 P&P will become the operation manual of the WG. Any conflict between these two documents will need to be resolved (e.g., quorum for interim sessions: 50% vs no need for quorum if announced 30 days before). There will be a need to review our own P&P when the 802 P&P is out.Item 6.1.3: Straw poll on the suitability of the Atlanta venue for the session: there was a general agreement that this was a suitable location.TG1 closing reportGregory Buchwald reported that comment resolutions have been completed and resolutions have to be implemented in Draft 7. More time is needed to finalize the text. Results of the first sponsor ballot were: 77% return rate with 91% support. What is left to be done is to go for a re-circulation ballot to confirm the latest changes made in response to the comments received as a result of the first sponsor ballot. Draft 7 will be uploaded within one week along with the comment spreadsheet. The next step will be a 30-day re-circulation. The plan is to have the Draft approved by the EC in March so that it can be sent to REVCOM.TG2 closing reportWinston Caldwell reported that the list of topics as embodied in document 22-06-242-37-0000 have been reviewed and discussed. TG2 will continue its review the draft Recommended Practice. There is a need to follow through with some calculations for separation distances for the BS, etc. The goal is to have it completed and then get to letter ballot. Teleconference calls will be held if there are contributions. It is expected to start preparing for a WG ballot in March 2010.PHY ad-hoc group closing report:Zander: the PHY group covered the remaining comments. A few contentious comments still need to be resolved in conference calls.MAC and coexistence ad-hoc groups closing report:Wendong: most MAC comments have been resolved or referred to the system group because they are broader than the MAC aspect. There is still a number of outstanding comments to be discussedSecurity ad-hoc group closing reportApurva: the security group made a lot of progress on telecoms. Almost all comments, including Ivan’s comments have been resolved. There is a need to develop a formal document to integrate all responses. There are still some system issues related to privacy.Spectrum manager ad-hoc group closing reportApurva: The work has advanced on management policies. There are about 40 comments left to be resolved, many being system issues to be referred to the system group because they deal with aspects beyond section 9. The group is waiting for guidance from the modified R&O on TV White Space expected from the FCC so that it can align with it. All comments cannot be resolved by January. The group is on target to finish section 9 in March. Work will also start on the MIBs.It was suggested that, since there are many comments related to systems aspects, there should be systems calls between face-to-face meetings.Move to form a system ad-hoc group in 802.22.Move: IvanSecond: ApurvaProposed chair: GeraldMotion passes with unanimous consentDatabase ad-hoc group closing reportWinston reported that the group generated a response to an informal email from the WSDB group and will informally supply these comments to the WSDB group.Move to approve the document 22-09-239rev1 in response to the WSDB (White Space Data Base) group email and allow a presentation of this document to the WSDB group in compliance to the IEEE 802 rules. Mover: WinstonSecond: Steve K.Ivan moved to Table the motionSecond: WinstonThere was no objectionThe rules for informal communications can be found in the LMSC operations manual and by-lawsSection 8.1.2: Sponsor group communications with outside groups that are not information only: need to send a copy to the EC reflector and make sure that Paul Nikolich is kept in the loop. With this clarification, the motion was brought back for vote.For: 9 Against: 1 Abstain: 3Motion passedNote that the opposed vote was due to a procedural matter rather than the content of the motion.Item 7.1.1: 802.18 activities: Winston reported that 802.18 dealt with some concerns about 802 equipment in the UNII band creating interference to radars because they do not implement the sensing features (equipment simply re-banded to 5 GHz).Item 7.1.2: 802.19 activities: Steve Shellhammer reported that there are 4 TV White Space PARs to be discussed at the EC meeting. A lot of attention was put by the 802.19 WG on the 802.11 PAR and the comments rebuttal.8. Closing businessThe chair indicated that this had been a good week of work. The chair proposed to change the quorum rule (50%) to the 802 quorum rule for the interim sessions. Ivan: suggest that the chair revise the P&P based on the new 802 P&P and present it to the group at a next session.WG general motions: See below.Old business? NoneNew business?The following motion was proposed:Move that the behaviour of the Spectrum Sensing Automaton should include functions for out-of-band sensing, initialization process, in-band sensing as ordered by the BS spectrum manager through the MAC messages, and should exclude functions not-related to sensing such as geolocation, antenna gain fetching and processing, and behaviour to recover from the loss of association with the BS (section 9.3.2, Figure 186).After some discussion, it was concluded that this matter needs more discussion time, not available during this closing meeting. This should take place by email exchange. This motion should be brought back later once the system group has reviewed this matter.Motion: Move to conduct a divisible 30-day electronic ballot no later than December 1st for approval of the comment resolutions that the editor f eels are ready to be balloted in the document 22-09-243-00-0000-WRAN-Draft-2.0-Comments-Confirmation-2.xls which is derived from 22-09-0120-17-0000-wran-draft-2-0-draft-comments-database.xls. Respondents should indicate their vote by an “X” in the right column and state clearly what changes to those resolution(s) would be required to change their No votes to Y es in the spreadsheet with, if required, ref erring to external documents sent to the chair and the editor. Furthermore, for the purpose of this ballot, any comment number in the following lists not voted upon by that individual will be considered as Abstain.Moved: Ivan ReedeSeconded: Tom GurleyApproved by unanimous consent.Motion: Moved to authorize duly noticed w eekly conference calls for the task groups and special interest area groups from now to the March 2010 Plenary session.Moved: Winston CaldwellSeconded: Ivan ReedeApproved by unanimous consent.Any other business:Ivan: An industry forum is being formed to develop and test equipment for this upcoming standard.The chair suggested that the 802.22 gets regular updates on this industry group.The meeting adjourned at 11:46am.The next session will be held in January 2010 at Hyatt Century Plaza in LA, United States, during the week of January 17-22, 2010The list of attendees for the Atlanta plenary session is appended below.802.22 Attendance ListAtlanta Plenary SessionNovember 2010Note: Participants who had voting status appear in bold.。