Monday 27 January 2014

Chapter 3 - 802.11 MAC Sublayer Frame Format

General 802.11 MPDU Format

  • MAC Header - frame ctrl, duration, address, seq ctrl & QOS (for QOS data frames) info
  • Frame Body - variable size, content varies with frame type & sub-type
  • FCS - 32 bit CRC

Image(24)

MAC Header

  • 8 major fields
    • 4 x 6 byte addr fields - each is standard MAC address
    • Frame Ctrl, Duration/ID, Seq Ctrl & QOS fields all 2 bytes each
    • Max MAC header size 32 bytes if all used
      • 802.11n introduced HT Control field - 4 bytes (after QOS Ctrl field)
      • Header 36 bytes max if included
    • Header size varies depending on number of address fields used & whether frame is QOS data frame
    • Image(25)
Frame Control Field (MAC Header)
  • First 2 bytes of header 
  • 11 sub-fields:
    • Protocol version
    • Type
    • Sub-type
    • To DS
    • From DS
    • More fragments
    • Retry
    • Power Management
    • More data
    • Protected Frame
    • Order
  • Image(26)
  • Protocol version
    • Always zero - only one version of 802.11 standard
  • Type & Subtype fields
    • Indicate function of frame
    • Type field 2 bits long:
      • 0,0 - Management frame
      • 0,1 - Control frame
      • 1,0 - Data frame
      • 1,1 - reserved
    • Sub-type is 4 bit field, indicating frame sub-type within type category
    • Image(27)
    • Notes:
      • bit 6 = 1 (data frame): no frame body
      • bit 7 = 1 (data frame): QoS frame
  • To DS & From DS
    • bits change meaning of address fields
    • Indicates flow between WLAN and the Distribution System (DS)
    • Four combinations:
      • To DS = 0, From DS = 0
        • Management or control frames (no MSDU payload, no data to or from DS)
        • Within an IBSS (Ad-hoc network)
        • Station to station link (STSL)
      • To DS = 1, From DS = 0
        • data frame upstream from wireless client to DS
      • To DS = 0, From DS = 1
        • data frame sent downstream from AP to client (sourced from device on DS)
      • To DS = 1, From DS = 1
        • Requires 4 address format of frame
        • typically mesh or WLAN bridge link
  • More Fragments
    • Set to 1 if current MSDU or MMPDU has another fragment to follow in subsequent frame
    • Fragmentation service provided by layer
    • Only fragments frames with unicast receiver address
      • multicast & broadcast frames not fragmented as no ack possible
    • Fragmentation limit defined by FragmentationThreshold
      • determined by length of unencrypted MPDU (inc header & FCS)
    • Each fragment has fragment number and is individually acknowledged with ACK
  • Retry Field
    • Set to 1 if no Ack received for mgt or data frame and frame is sent again (e.g. CRC corrupt and frame discarded by rx station)
    • Most unicast frames req Ack (RTS/CTS exchange is an exception, as is QoS No Ack policy in some data frames)
    • Broadcast & Multicast frames not acknowledged
    • Retries very significant issue in WLANs
      • increases overhead and reduce throughput
      • increases latency and jitter which affects time-sensitive applications badly (voice & video)
      • 10% retransmission OK for most data applications
      • VoWiFi requires 5% or lower retransmissions
      • Retransmission levels can be observed (down to client level) using protocol analyzer
  • Power Management Field
    • Indicates 802.11 legacy power save mode used by client when set to 1
    • Requires access point to buffer frame destined for client
  • More Data Field
    • Single bit frame used to indicate if more buffered frames to send to power save mode client
    • Each station associated with AP has association identifier (AID)
    • When AP has data for station using power save mode, indicates data available for station using AID using beacon field: TIM (traffic indication map)
    • TIM is list of stations that have undelivered unicast frames
    • Once station wakes up from doze state, sends PS-Poll to AP to retrieve its buffered frames
    • When AP sends frames, more data field indicates more frames to send, so that station does not go back to sleep
    • Station has to send a PS-Poll frame for each frame it needs to rx
    • When all frame sent, more data field set to zero and station can go back to doze mode
    • Image(28)
  • Protected Frame Field
    • Single bit which indicates if MSDU payload of data frame is encrypted
    • Does not indicate type of encryption, could be WEP, TKIP, CCMP etc.
    • Can also be set in Authentication frames to indicate if Shared Key authentication used
    • May also be set in 802.11w-2009 unicast Robust Management frames
  • Order Field
    • Set in any non-QoS frame where strictly ordered class of service req by upper layer protocol
    • Rarely used - originally intended for legacy protocols that could not enforce ordering recovery


Duration/ID Field (MAC Header)


Image(29)

  • 2 byte field (16 bits)
  • Used for 3 reasons:
    • Virtual carrier sense - main purpose to reset NAV timer of other stations
    • Legacy power management - PS-Poll frames use field as association ID (AID)
    • Contention Free Period - indicator that PCF (Point Co-ordination Function) process has begun
  • Virtual Carrier Sense
    • Main use of Duration/ID field
    • 802.11 stations use CSMA/CA to access medium
    • Virtual carrier sense uses the NAV (network allocation vector) - contains prediction of how how long medium will be busy for
    • Listening stations see NAV value and count down, knowing medium will be busy until zero is reached
    • NAV value uses 13 bits to represent value of 0 - 32,767
    • NAV value represents time in micro-secs 
    • Main purpose of field is to contain duration value to reset NAV timers of other stations
    • Only time a stations NAV timer not reset is when the receiver address is same as receiving stations MAC address
    • NAV values are always indication of frame transmissions that are to follow (e.g. ACK & SIFS)
    • Transmitting station NAV always zero
    • Image(30)
  • Legacy power management
    • When AP has data for AP in power save mode, AID added to TIM in beacons
    • Client sends PS-Poll frame to request buffered unicast frame - AID is put in to Duration/ID field to identify itself to AP
    • Least significant 14 bits used for AID - remaining 2 bits set to '1'
    • Max AID value is 2007
    • Image(31)
  • Contention Free Period
    • Fixed value of 32,768
    • Used in PCF (Point Coordination Function) & HCCA (Hybrid Coordination Function Channel Access)
    • Beyond Scope of CWAP

MAC Layer Addressing

  • 2 Types of address
    • Individual address - unicast
    • Group address - 
      • multicast - group of stations
      • broadcast - all stations : FF:FF:FF:FF:FF:FF
  • Up to 4 MAC address fields, but generally only 3 used
  • Addresses:
    • receiver address (RA)
      • MAC address of 802.11 radio receiving frame
    • transmitter address (TA)
      • MAC address of 802.11 radio sending frame
    • basic service set identifier (BSSID)
      • MAC address of the BSS
      • Is MAC address of AP radio, or derived from radio addr if multiple BSS's exist
    • destination address (DA)
      • MAC addr of final destination of the frame - may be wired or wireless station
    • source address (SA)
      • MAC addr of original sending station - may be wired or wireless station
  • Addresses 6 bytes
    • first 3 bytes are OUI (organisationally unique ID)
    • last 3 bytes: extension identifier
  • Definition of each address field changes with the settings of the ToDS and FromDS fields

Image(32)

  • Addressing definitions:
    • Vary with To DS & From DS field settings
    • Addr 1 - always RA (though may have second definition)
    • Addr 2 - always TA (though may have second definition)
    • Addr 3 - used for additional MAC addr info
    • Addr 4 - WDS only
  • To DS = 0, From DS = 0
    • Commonly management or control frames
      • No MSDU payload, no final destination on DS
      • TA & RA will always be AP & station exchanging frames
      • Example below shows mgt frame sent by client (AP = 1d:90, client = 85:10) - addr 1 = RA, addr 2 = TA, addr 3 = BSSID
      • Image(33)
      • In some cases, BSSID can be wildcard value (all 1s) - e.g. probe request when client looking to roam, as client does not know new BSSID MAC:
        Image(34)
    • Also used when performing direct frame transfer from one STA to another on an IBSS (ad-hoc)
      • Example below shows 2 stations (85:10 & 77:3a) using RA & TA, address 3 is BSSID created by first station in ad-hoc network
      • Image(35)
  • To DS = 1, From DS = 0
    • Indicates frame destined for end-point on the DS (usually Ethernet sw network), but sourced from wireless STA
    • Example below shows:
      • Addr 1 is BSSID on AP (RA) (STA sends frame to this address) - 1d:90
      • Addr 2 is wireless client source (TA) - 85:10
      • Addr 3 is MAC of destination device on DS (e.g. DHCP server) - 92:f7
      • Image(36)
  • To DS = 0, From DS = 1
    • Indicates frame sourced fro end-point on the DS (usually Ethernet sw network), but destined for wireless STA
      • Example below shows:
        • Addr 1 is MAC of destination wireless client (RA) - 85:10
        • Addr 2 is BSSID on AP (TA) - 1d:90
        • Addr 3 is MAC of source device on DS (e.g. DHCP server) - 92:f7
        • Image(37)
  • To DS = 1, From DS = 1
    • Requires use of all 4 address fields in MAC header
    • Generally used for bridges, mesh & repeater scenarios
    • Requires that a frame will be sent to another wireless system before being relayed on to a wired DS
    • Two fields are required to identify wireless radios at either end of link and two addresses required to identify wired station on DS at each end. See example below:
    • Image(38)
  • Multiple BSSIDs
    • Each WLAN has logical name (SSID) and unique layer 2 identifier (BSSID)
    • When more than 1 SSID exists, BSSID of each one has unique virtual BSSID - usually an increment of MAC address of AP radio
    • Capability called multiple basic service set identifier (MBSSID) 
    • Allows multiple layer2/3 domains to exist in one layer one domain
  • Sequence Control Field
    • 16 bit field
    • 2 subfields: 4 bit fragment number & 12 bit sequence number
    • Image(39)
    • Sequence number used to sequentially number data frames - assigned by station sending the MSDU or MMPDU
    • Sequence numbers values: 0 - 4095 - wraps once number exhausted
    • If MSDU is fragmented, each fragment is assigned a fragment number - each fragment keeps the same sequence number to allow re-assembly at the receiver
  • Fragmentation threshold
    • Every 802.11 can be configured with fragmentation threshold
    • Specifies limit (in bytes) over which an MSDU will be broken in to fragments
    • Once frame fragmented, fragment ID incremented (starting from zero) and 'More Fragments' bit in frame control is set until last fragment reached 
    • Fragmentation threshold evaluation of an unencrypted MPDU includes Header, frame body & CRC - final frame size may still be larger than threshold due to encryption expansion
    • The example below shows a threshold of 300 bytes
    • Image(40)
    • Image(41)
    • Fragments are always sent in fragment bursts - once transmission medium control gained, all fragments sent using combination of NAV values & SIFS
    • NAV value of each fragment & ACKs set to reserve time to transmit next fragment. SIFS used between frames to ensure beats stations using DIFS to keep control of medium
    • If fragment not acknowledged, retries begin at unacknowledged frame
    • Image(42)
  • QoS Control Field
    • 16 bit field that identifies quality of service params of frame
    • Field present in all data frames where QoS subtype field set to 1 (bit 7) - i.e. QoS data frames 
    • 5 sub-fields
      • traffic identifier (TID)
      • end of service period (ESOP)
      • ACK policy 
      • reserved field
      • Final field meaning varies with station type (AP or client)
      • Image(43)
    • WiFi uses Enhanced Distributed Channel Access (EDCA) access method for differentiated access
      • 8 user priority levels (UPs) (1 - 7)
      • 4 QoS access categories (ACs), based on UPs - these are (lowest to highest):
        • AC_BK (Background)
        • AC_BE (Best effort)
        • AC_VI (Video)
        • AC_VO (Voice)
      • WiFi Alliance QoS Certification called Wireless Multmedia (WMM)
      • 802.1D priority queuing for Ethernet frames mapped on to user priorities & access classes as shown below:
      • Image(44)

      • Image(45)
    • TID - traffic indicator field: first field, 4 bit
      • Identifies user priority (UP) and access category (AC) of QoS data frame (by using mappings shown above)
    • EOSP - end of service period
      • WMM client stations use WMM-PS (WMM power save) - uses "trigger & deliver" mechanism to indicate awake to AP
      • Clients can ask for delivery of multiple frames whilst awake during 'service period' - during association, client must indicate number of frames that can be rx: 2, 4, 6 or all frames
      • EOSP indicates end of current service period (i.e. last frame has bit set to 1 to indicate service period over of buffer empty)
    • ACK Policy
      • 3rd field - 2 bits
      • Indicates ACK policy to be used after delivery of QoS data frame - 4 available
        • ACK
        • No ACK
        • No Explicit ACK
        • Block ACK
    • Reserved sub-field - 4th field - 1 bit (for future use)
    • Fifth sub-field: number of meanings - 8 bits
      • TXOP Limit
        • 802.11 radio may send multiple frames in frame burst, with SIFS between each frame
        • Once it has control of the medium, its allotted period of time to burst is a "transmit opportunity" (TXOP)
        • TXOP limit value varies for each QoS access category
        • TXOP limits set in 32 uS intervals - e.g. Voice AC as TXOP of 47 by default, this is 47 x 32uS = 1,504 uS to transmit once access to channel won
        • TXOP limit is supplied by AP to STA to indicate amount of time it may burst frames
      • AP PS Buffer State
        • AP can indicate to the STA how much data PS data buffered for the client for an access category
      • TXOP Duration Requested
        • 5th field may also be used by client to request TXOP duration of the AP - i.e. how much time a client wants to send next frame burst. AP may choose to assign smaller duration than was requested
      • Queue Size
        • Client may use the field to indicate the amount of data it as buffered, to send for a traffic category
        • AP can use this to determine next TXOP req by client

Frame Body

  • Different frame types carry different payload in frame body - control frames have no body
  • Management frames also known as Management MAC Protocol Data Unit (MMPDU)
    • Carry no upper-layer information, no MSDU encapsulated
    • Only carry:
      • information fields - fixed length, mandatory fields in body
      • information elements - variable length & optional
  • Control frames acquire & clear the channel, as well as unicast acks
    • Only header & trailer - no body elements at all
  • Data frames carry MSDU as payload
    • some subtypes though may not have frame body (e.g. null function frames)
    • frame body is MSDU which contains LLC data & IP packet passed down from upper layers
    • max size of MSDU is 2,304 bytes, though size varies & may exceed limit due to encryption overhead
  • Encryption: 3 types defined in 802.11-2007 to encrypt frame body/payload:
    • WEP
      • adds 8 bytes of overhead for max of 2312 bytes
      • initialization vector = 4 bytes, integrity check value - 8 bytes
    • TKIP
      • adds 20 bytes of overhead for max frame of 2324 bytes
      • IV = 4 bytes, Extended IV = 4 bytes, MIC = 8 bytes, ICV = 4 bytes
    • CCMP
      • adds 16 bytes of overhead for max frame size 2320 bytes
      • CCMP header = 8 bytes, MIC = 8 bytes

Image(46)

FCS Field

  • FCS field contains 32 bit cyclic redundancy check
  • Validates frame integrity
  • Calculated over MAC header & frame body fields (calculation fields)
  • If FCS calc OK, then ACK sent to each frame, if FCS fails, frame assumed corrupted and no ACK sent
  • All 802.11 unicast frames require ACK, multicast & broadcast are not acknowledged

No comments:

Post a Comment