08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
Ieee 802.11 standard
1. MBC Laboratory
IEEE 802.11 Standard
10. Layer Management
Professor: Keecheon Kim
Department of Computer Science
Konkuk University, Seoul, Korea
seryvuth-tan@nida.gov.kh
Mr. Tan Seryvuth
Date: 04-06-2012
2. Contents
1. Overview of management model
2. Generic management primitives
3. MLME SAP interface
4. 1. Overview of management model
MLME(MAC Layer Management Entity) and PLME(Physical Layer Management
Entity) are management entities including into MAC sublayer and PHY respectively
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. 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
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
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. 3. MLME SAP interface
No Management Service No Management Service
1 Power Management 16 TPC request
2 Scan 17 SetKeys
3 Synchronization 18 DeleteKeys
4 Authenticate 19 MIC (Michael) failure event
5 Deauthenticate 20 EAPOL
6 Associate 21 MLME-PeerKeySTART
7 Reassociate 22 SetProtection
8 Disassociate 23 MLME-PROTECTED FRAMED ROPPED
9 Reset 24 TS management interface
10 Start 25 Management of direct links
11 Spectrum management protocol layer 26 Higher layer synchronization support
model
12 Measurement request 27 Block Ack
13 Measurement Report 28 Schedule element management
14 Channel measurement 29 Vendor-specific action
15 Channel switch
12. 3. MLME SAP interface
3.1 Power Management
This mechanism supports the process of establishment and maintenance of the
power 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. 3. MLME SAP interface
3.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. 3. MLME SAP interface
3.2 Scan
This mechanism support the process of determining the characteristics of
the available BSSs.
16. 3. MLME SAP interface
3.3 Synchronization
Timing synchronization function (TSF)
Used for power management
• Beacons sent at well known intervals
• All station timers in BSS are synchronized
18. 3. MLME SAP interface
3.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. 3. MLME SAP interface
3.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. 3. MLME SAP interface
3.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
22. 3. MLME SAP interface
3. 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. 3. MLME SAP interface
3.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
27. 3. MLME SAP interface
3.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
29. 3. MLME SAP interface
3.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. 3. MLME SAP interface
3.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. 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. 3. MLME SAP interface
3.11 Spectrum management protocol layer model
Dialog Measurement
Category Action Value
Token Request elements
Dialog Measurement
Category Action Value
Token Report elements
33. 3. MLME SAP interface
3.11 Spectrum management protocol layer model
34. 3. MLME SAP interface
3.11 Spectrum management protocol layer model
Channel Switch
Category Action Value
Announcement element
35. 3. MLME SAP interface
3.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. 3. MLME SAP interface
3.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. 3. MLME SAP interface
3.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. 3. MLME SAP interface
3.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
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.