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.。