Ieee 802.11 standard

4,420 views

Published on

IEEE 802.11 Standard - Layer Management

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,420
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
116
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • In the management model, there are two separations. One is MAC Layer Management Entity (MLME) and other one is Physical Layer Management Entity (PLME). These entities provide the Layer Management Service Interfaces through which layer management functions can be invoked . So in this path I will only emphasize MLME. ------------------------------------------------------------- Invoke= យកមកប្រើ ------------------------------------------------------------- MAC MIB : MAC Management Information Base PLCP : Physical Layer Convergence Procedure MIB : Management Information Base
  • Anyway, Station Management Entity, in sort (SME), is the independent entity that can be viewed as residing in a separation management plane between MAC Layer Management Entity (MLME) and Physical Layer Management Entity. ----------------------------------------------------------------------------------------------------------------------------- SME : Station Management Entity SME-MLME SAP = Service Management Entity - MAC Layer Management Entity Service Access Point
  • There are many interface with this model and each interface there are different function such as SME-MLME SAP (for SET/GET value between MLME and SME), SME-PLME SAP (for SET/GET value between PLME and SME), MLME-PLME SAP (for SET/GET value between MLME and PLME).
  • In the Generic management primitive there is Management Information Base(MIB) for manage specific information of each layer such as MLME and PLME and for manage primitives exchanged across the management SAP. SET for insert value from SME to layer management entity and GET for retrieve value from layer management to SME.
  • As I told you at the previous, MLME SAP interface is the gate for communication between MLME and SME. The general form like this: MLME-ACTION.request, MLME-ACTION.confirm and other. For the (ACTION) , there are as below:
  • Power management is very importance for wireless communication, especially, Mobile Ad-hoc Network. This mechanism supports the process of establishment and maintenance of the power management mode of a STA.
  • Power Management Request = this primitive requests a change in the power management mode. It is generated by SME to implement the power-saving strategy of an implementation. Power Management Confirm = this primitive confirms the change in power management mode. It is generated by the MLME as a result of an MLME-POWERMGT.request to establish a new power management mode. It is not generated until change has completed.
  • Active Scanning: The station sends probe request packet on each channel and collects information about the existing surrounding WLAN networks from the probe response packets. Passive Scanning: The station collects information about the existing networks by listening beacons on all the channels.
  • Passive Scanning If the ScanType parameter indicates a passive scan, the STA shall listen to each channel scanned for no longer than a maximum duration defined by the MaxChannelTime parameter. Active Scanning Active scanning involves the generation of Probe request frames and the subsequent processing of received Probe Response frames.
  • The Synchronization occur when STA joint with BSS. -------------------------------------------------------------- What is beacon interval? The default value is 100 . Enter a value between 1 and 65.535 milliseconds . The Beacon Interval value indicates the frequency interval of the beacon. A Beacon is a packet broadcast by the router to synchronize the wireless network. 50 is recommended in poor reception.
  • Joint.request = This primitive requests synchronization with a BSS that is generated by the SME for a STA to establish synchronization with a BSS Joint.confirm = This primitive confirms synchronization with a BSS that is generated by the MLME as a result of an MLME-JOIN.request to establish synchronization with a BSS
  • There are two authentication algorithm: Open System authentication - is a guaranteed result of success after two station introduce themselves to each other Share key authentication algorithm this algorithm depend on both stations having a copy of a shared WEP key uses the WEP encryption option to encrypt and decrypt data transmission as the proof that the stations share the same key
  • There are two authentication algorithm: Open System authentication - is a guaranteed result of success after two station introduce themselves to each other Share key authentication algorithm this algorithm depend on both stations having a copy of a shared WEP key uses the WEP encryption option to encrypt and decrypt data transmission as the proof that the stations share the same key
  • There are two authentication algorithm: Open System authentication - is a guaranteed result of success after two station introduce themselves to each other Share key authentication algorithm this algorithm depend on both stations having a copy of a shared WEP key uses the WEP encryption option to encrypt and decrypt data transmission as the proof that the stations share the same key
  • Authenticate Request = This primitive requests authentication with a specified peer MAC entity that is generated by the SME for a STA to establish authentication with a specified peer MAC entity in order to permit Class 2 frame to be exchanged between the two STAs. During the authentication procedure, the SME can generate additional MLME-AUTHENTICATE.request primitives. Authenticate Confirm = The primitive reports the results of an authentication attempt with a specified peer MAC entity. It is generated by the MLME as a result of an MLME-AUTHENTICATE.request to authenticate with a specified peer MAC entity. Authenticate Indication = The primitive indicates receipt of a request from a specific peer MAC entity to establish an authentication relationship with the STA processing this primitive. It is generated by MLME as a result of the receipt of an authentication request from a specific peer MAC entity. Authenticate Response = This primitive is used to send a response to a specific peer MAC entity that requested authentication with the STA that issued this primitive. It is generated by the SME of a STA as a response to an MLME-AUTHENTICATE.indication primitive.
  • Deauthentication Request : This primitive requests that authentication relationship with a specified peer MAC entity be invalidated. It is generated by the SME to invalidate authentication with a specified peer MAC entity in order to prevent the exchange of Class 2 frames between the two STAs. During the deauthentication procedure, the SME can generate additional MLME-DEAUTHENTICATE.request primitives. Deauthentication Confirm : The primitive report results of a deauthentication attempt with a specified peer MAC entity. It is generated by MLME as a result of an MLME-DEAUTHENTICATE.request to invalidate the authentication relationship with a specified peer MAC entity. Deauthentication Indication : The primitive reports the invalidation of an authentication relationship with a specific peer MAC entity. It is generated by MLME as a result of the invalidation of an authentication relationship with a specific peer MAC entity.
  • RSN : Robust Security Network
  • Disassociation Request = this primitive requests disassociation with a specified peer MAC entity that is within an AP. It is generated by the SME for a STA to establish disassociation with an AP Disassociation Confirm = this primitive reports the results of a disassociation procedure with a specific peer MAC entity that is within an AP. It is generated by the MLME as a result of an MLME-DISASSOCIATION.request to disassociate with a specified peer MAC entity that is within an AP. Disassociate Indication = This primitive reports disassociation with a specific peer MAC entity. It is generated by the MLME as a result of the invalidation of an association relationship with a specific peer MAC entity.
  • Reset is the mechanism used for resetting the MAC and to initialize the management entity. Clear all internal variables of Management Information Base(MIB) to the default values. --------------------------------------------------------------------------------- Reset Request = This primitive requests that MAC entity be reset. It is generated by the SME to reset the MAC to initial conditions. the MLME-RESET.request primitive must be used prior to use of the MLME-START.request primitive Reset Confirm = This primitive reports the results of a reset procedure. It is generated by the MLME as a result of an MLME-RESET.request to reset the MAC entity.
  • START Request = This primitive requests that the MAC entity start a new BSS. It is generated by the SME to start either an infrastructure BSS (with the MAC entity within an AP) or an IBSS (with the MAC entity acting as the first STA in the IBSS). The MLME-START.request primitive must be generated after an MLME-RESET.request primitive has been used to reset the MAC entity and before an MLME-JOIN.request primitive has been used to successfully joint an existing infrastructure BSS or IBSS The MLME-START.request primitive must not be used after successful use of the MLME-START.request primitive or successful use of the MLME-JOIN.request without generating an intervening MLME-RESET.request primitive START Confirm = This primitive reports the results of a BSS creation procedure. It is generated by MLME as a result of an MLME-START.request to create a new BSS.
  • MREQUEST Request = This primitive requests the transmission of a measurement request to a peer entity. It is generated by the SME to request that a Measurement Request frame be sent to a peer entity to initiate one or more measurements. MREQUEST Confirm = This primitive reports the result of a request to send a Measurement Request frame. It is generated by the MLME when the request to transmit a Measurement Request frame completes. MREQUEST Indication = This primitive indicates that a Measurement Request frame has been received requesting the measurement of one or more channels. It is generated by the MLME when a valid Measurement Request frame is received.
  • MREPORT Request = The primitive supports the signaling of measurement reports between peer SMEs. It is generated by the SME to request that a frame be sent to a peer entity to report the results of measurement one or more channels MREPORT Confirm = This primitive reports the result of a request to send a Measurement Report frame. It is generated by the MLME when the request to transmit a Measurement Report frame completes. MREPORT Indication = This primitive indicates that a Measurement Report frame has been received from a peer entity. This management report can be in response to an earlier measurement request (e.g. MLME-MREQUEST.request) or can be an autonomous report. It is generated by MLME when a valid Measurement Report frame is received.
  • MEASURE Request = This primitive is generated by the SME to request that the MLME initiate specified measurements. MEASURE Confirm = This primitive reports the result of a measurement. It is generated by the MLME to report the results when a measurement set completes.
  • CHANNELSWITCH Request = This primitive requests a switch to a new operating channel. It is generated by the SME to schedule a channel switch and announce this switch to peer entities in the BSS. CHANNELSWITCH Confirm = This primitive reports the result of a request to switch channel. It is generated by the MLME when a channel switch request complete. Possible unspecified failure causes include an inability to schedule a channel switch announcement. CHANNELSWITCH Indication = This primitive indicates that a channel switch announcement has been received from a peer entity. it is generated by the MLME when a valid Channel Switch Announcement frame is received. CHANNELSWITCH Response = This primitive is used to schedule an accepted channel switch. It is generated by the SME to schedule an accepted channel switch request.
  • Ieee 802.11 standard

    1. 1. MBC Laboratory IEEE 802.11 Standard 10. Layer ManagementProfessor: Keecheon Kim Department of Computer Science Konkuk University, Seoul, Korea seryvuth-tan@nida.gov.kh Mr. Tan Seryvuth Date: 04-06-2012
    2. 2. Contents 1. Overview of management model 2. Generic management primitives 3. MLME SAP interface
    3. 3. 1. Overview of management model
    4. 4. 1. Overview of management modelMLME(MAC Layer Management Entity) and PLME(Physical Layer ManagementEntity) are management entities including into MAC sublayer and PHY respectively
    5. 5. 1. Overview of management model Station Management Entity (SME) is the independent entity – can be viewed as residing in a separation management plane.
    6. 6. 1. Overview of management model MLME-PLME SAP SME-MLME SAP SME-PLME SAP  SME-MLME SAP = SME MLME Service Access Point  SME-PLME SAP = SME MLME Service Access Point  MLME-PLME SAP = MLME PLME Service Access Point
    7. 7. 2. Generic management primitives
    8. 8. 2. Generic management primitives Management Information Base(MIB) –  manage specific information of each layer (MLME, PLME)  manage primitives exchanged across the management SAP (SET/GET)  Depicts these generic primitives  XX-GET.request GET values of a MIB attribute  XX-GET.confirm  XX-SET.request SET values of a MIB attribute  XX-SET.confirm  XX-RESET.request used to initialize the management entity.  XX-RESET.confirm XX denotes MLME or PLME
    9. 9. 3. MLME SAP interface
    10. 10. 3. MLME SAP interface Communicate between MLME-SME SME-MLME SAP The general form: MLME-ACTION.request MLME-ACTION.confirm MLME-ACTION............. MLME SAP = MAC Layer Entity Management Entity – Service Access Point SME-MLME SAP = Service Management Entity - MAC Layer Management Entity - Service Access Point
    11. 11. 3. MLME SAP interfaceNo Management Service No Management Service1 Power Management 16 TPC request2 Scan 17 SetKeys3 Synchronization 18 DeleteKeys4 Authenticate 19 MIC (Michael) failure event5 Deauthenticate 20 EAPOL6 Associate 21 MLME-PeerKeySTART7 Reassociate 22 SetProtection8 Disassociate 23 MLME-PROTECTED FRAMED ROPPED9 Reset 24 TS management interface10 Start 25 Management of direct links11 Spectrum management protocol layer 26 Higher layer synchronization support model12 Measurement request 27 Block Ack13 Measurement Report 28 Schedule element management14 Channel measurement 29 Vendor-specific action15 Channel switch
    12. 12. 3. MLME SAP interface3.1 Power Management This mechanism supports the process of establishment and maintenance of thepower management mode of a STA. Basic idea  Mobile sleeps, AP buffers downlink data, and sends the data when the mobile device is awakened.  Using Timing Sync Function (TSF) all mobiles are synchronized and they will wake up at the same time to listen to the beacon.
    13. 13. 3. MLME SAP interface3.1 Power Management  Power management modes:  Active Mode (AM) • STA may receive frames at any time  Power Save Mode (PS) • STA listens to selected Beacon frames  Power Management Request PowerManagementMode, WankUp, ReceiveDTIMs  Power Management Confirm ResultCode DTIM = Delivery Traffic Indication Message
    14. 14. 3. MLME SAP interface3.2 Scan This mechanism support the process of determining the characteristics of the available BSSs.
    15. 15. 3. MLME SAP interface3.2 Scan MLME-SCAN Request BSSType, BSSID, SSID, ScanType, ProbeDelay, ChannelList, MinChannelTime, MaxChannelTime, VendorSpecificInfo MLME-SCAN Confirm BBSDescriptionSet, ResultCode, VendorSpecificInfo
    16. 16. 3. MLME SAP interface3.3 Synchronization  Timing synchronization function (TSF)  Used for power management • Beacons sent at well known intervals • All station timers in BSS are synchronized
    17. 17. 3. MLME SAP interface3.3 Synchronization  MLME-JOIN Request SelectedBSS, JoinFailureTimeout, ProbeDelay, OperationalRateSet, VendorSpecificInfo  MLME-JOIN Confirm ResultCode, VendorSpecificInfo
    18. 18. 3. MLME SAP interface3.4 Authenticate  Provides a mechanism for one station to prove its identity to anther station in the WLAN  Can be used between any 2 stations  More useful when used between a mobile station and a AP in an infrastructure There are two authentication algorithm: - Open System authentication Authentication - Share key authentication algorithm STA AP
    19. 19. 3. MLME SAP interface3.4 Authenticate  Open System example: • Assertion : I’m station 4 Authentication STA4 AP • Challenge : Null • Response : Null • Result : Station becomes Authenticated  Share key authentication algorithm  A password based example : • Assertion : I’m station 4 • Challenge : Prove your identity • Response : Here is my password • Result : if password OK, station becomes Authenticated
    20. 20. 3. MLME SAP interface3.4 Authenticate Authentication STA4 AP  A Cryptographic based example : • Assertion : I’m station 4 • Challenge : Here is some information (X). I encrypted with your public key, what is it? • Response : The contents of the information is (X) (only station4’s private key could have recovered the challenge contents). • Result : OK, I believer that you are station 4
    21. 21. 3. MLME SAP interface3.4 Authenticate  MLME-AUTHENTICATE Request PeerSTAAddress, AuthenticationType, AuthenticateFailureTimeout, VendorSpecificInfo  MLME-AUTHENTICATE Confirm PeerSTAAddress, ResultCode, VendorSpecificInfo  MLME-AUTHENTICATE Indication PeerSTAAddress, AuthenticationType, VendorSpecificInfo  MLME-AUTHENTICATE Response PeerSTAAddress, ResultCode, VendorSpecificInfo
    22. 22. 3. MLME SAP interface3. 5 Deauthenticate  It is invoked when an existing Open System or Shared key authentication is to be terminated.  The act of deauthentication shall cause the station to be disassociated – authentication is a prerequisite for association.  MLME-DEAUTHENTICATE Request PeerSTAAdress, ReasonCode, VendorSpecificInfo  MLME-DEAUTHENTICATE Confirm PeerSTAAddress, ResultCode, VendorSpecificInfo  MLME-DEAUTHENTICATE Indication PeerSTAAddress, ReasonCode, VendorSpecificInfo
    23. 23. 3. MLME SAP interface3.6 Associate  Used to establish relationship with AP. STA scan (active / passive) frequency band to select AP with best communication quality.  Accomplished after a successful authentication has been completed
    24. 24. 3. MLME SAP interface3.6 Associate  MLME-ASSOCIATE Request PeerSTAAddress, AssociationFailureTimeout, CapabilityInformation, ListenInterval, Supported Channels, RSN, QoSCapability, VendorSpeciticInfo  MLME-ASSOCIATE Confirm PeerSTAAddress, CapabilityInformation, AssociationID, SupportedRates, EDCAParameterSet, VendorSpeciticInfo  MLME-ASSOCIATE Indication PeerSTAAddress, CapabilityInformation, ListenInterval, SSID, SupportRates, RSN, QoSCapability, VendorSpeciticInfo  MLME-ASSOCIATE Response PeerSTAAddress, ResultCode, CapabilityInformation, AssociationID, EDCAParameterSet, VendorSpeciticInfo
    25. 25. 3. MLME SAP interface3.7 Re-associate
    26. 26. 3. MLME SAP interface3.7 Re-associate  MLME-REASSOCIATE Request NewAPAddress, ReassociationFailureTimeout, CapabilityInformation, ListenInterval, Supported Channels, RSN, QoSCapability, VendorSpeciticInfo  MLME-REASSOCIATE Confirm ResultCode, CapabilityInformation, AssociationID, SupportedRates, EDCAParameterSet, VendorSpeciticInfo  MLME-REASSOCIATE Indication PeerSTAAddress, CurrentAPAddress, CapabilityInformation, ListenInterval, SSID, SupportRates, RSN, QoSCapability, VendorSpeciticInfo  MLME-REASSOCIATE Response PeerSTAAddress, ResultCode, CapabilityInformation, AssociationID, EDCAParameterSet, VendorSpeciticInfo
    27. 27. 3. MLME SAP interface3.8 Disassociate  This mechanism is the termination of existing association.  It is invoked whenever an existing Association must be terminated, and can be invoked by either party to an Association (Mobile STA or AP).  It is a notification that cannot be refused.  STAs are encouraged to Disassociate whenever they leave a network
    28. 28. 3. MLME SAP interface3.8 Disassociate MLME-Disassociate Request PeerSTAAddress, ReasonCode, VendorSpecifinInfo MLME-Disassociate Confirm Resultcode, VendorSpecificInfo MLEW-Disassociate Indication PeerSTAAddress, ReasonCode, Vendorspeecity
    29. 29. 3. MLME SAP interface3.9 Reset  This mechanism supports the process of resetting the MAC.  used to initialize the management entity.  Clear all internal variables to the default values (MIB)  MLME-RESET Request STAAddress, SetDefaultMIB  MLME-RESET Confirm ResultCode
    30. 30. 3. MLME SAP interface3.10 Start This mechanism supports the process of creating a new BSS. MLME-START Request SSID, BSSType, BeaconPeriod, CF parameter set, PHY parameter set, IBSS parameter set, ProbeDelay, CapabilityInformation, BSSBasicRateSet, OperationalRateSet, Country, IBSS DFS Recovery Interval, EDCAParameterSet, VendorSpecificInfo MLME-START Confirm ResultCode, VendorSpecificInfo
    31. 31. 3. MLME SAP interface 3.11 Spectrum management protocol layer model- The layer management extensions for measurement and channel switching assume a certain partition of spectrum management functionality between the MLME and SME.
    32. 32. 3. MLME SAP interface3.11 Spectrum management protocol layer model Dialog Measurement Category Action Value Token Request elements Dialog Measurement Category Action Value Token Report elements
    33. 33. 3. MLME SAP interface3.11 Spectrum management protocol layer model
    34. 34. 3. MLME SAP interface3.11 Spectrum management protocol layer model Channel Switch Category Action Value Announcement element
    35. 35. 3. MLME SAP interface3.12 Measurement request This set of primitive supports the signaling of measurement requests between peer SMEs. MLME-MREQUEST Request Peer MAC Address, Dialog Token, Measurement Request Set, VendorSpecificInfo MLME-MREQUEST Confirm ResultCode, VendorSpecificInfo MLME-MREQUEST Indication Peer MAC Address, Dialog Token, Measurement Request Set, VendorSpecificInfo
    36. 36. 3. MLME SAP interface3.13 Measurement Report This set of primitives supports the signaling of measurement reports. MLME-MREPORT Request Peer MAC Address, Dialog Token, Measurement Report Set, VendorSpecificInfo MLME-MREPORT Confirm ResultCode, VendorSpecificInfo MLEM-MREPORT Indication Peer MAC Address, Dialog Token, Measurement Report Set, VendorSpecificInfo
    37. 37. 3. MLME SAP interface3.14 Channel measurement This set of primitives supports the requesting and reporting of measurement data. MLME-MEASURE Request Dialog Token, Measurement Request Set, VendorSpecificInfo MLME-MEASURE Confirm ResultCode, Dialog Token, Measurement Report Set, VendorSpecificInfo
    38. 38. 3. MLME SAP interface3.15 Channel Switch This primitive requests switch to a new operating channel. MLME-CHANNELSWITCH Request Mode, Channel Number, Channel Switch Count, VendorSpecificInfo MLME-CHANNELSWITCH Confirm ResultCode, VendorSpecificInfo MLME-CHANNELSWITCH Indication Peer MAC Address, Mode, Channel Number, Channel Switch Count, VendorSpecificInfo MLME-CHANNELSWITCH Response Mode, Channel Number, Channel Switch Count, VendorSpecificInfo
    39. 39. Thank You !!!

    ×