Oversikt over WLAN. IEEE og 11.e (QoS) Paal Engelstad

Oversikt over WLAN IEEE 802.11 og 11.e (QoS) Paal Engelstad

Agenda Arkitektur og protokollstakk Hovedfunksjoner til MAC laget MAC ramme format og pakke typer MAC management funksjoner QoS med 802.11e Info om 802.11 (unntatt 802.11e) er basert på følgende anbefalte bøker: - 802.11 Handbook A Designer s Companion av Bob O Hara og Al Petrick - 802.11 Wireless Networks The Definitive Guide av Matthew S. Gast (anbefales) - Multimedia Wireless Networks (lærebok)

Arkitektur - Basic Service Set (BBS) IBSS Independent BSS BSS (Infrastructure BSS) Access Point (AP) DS (Distribution System) Portal Station (STA) EBSS (Extended BSS) ID: SSID BSS (Infrastructure BSS) BSS (Infrastructure BSS) ID: BSSID

Protokoll Stakken Merk: 802.11 Protokol Arkitektur 802.2!!! - FHSS er historisk - IR er ikke implementert (IrDA isteden) - 802.11a s fremtid er usikker - DSSS mest for bakover-kompatibilitet - 802.11b er mest brukt... Mest fokus på MAClaget i denne pres. Flere managementfunksjoner i MAClaget, enn i andre Wired IEEE 802- standarder

PHY (for DSSS og 802.11b) PHY PLCP Phys. Layer Convergence Proc. PMD Phys. Medium Dependent PLCP har egen header: Signal bits: angir modulasjon for resten av pakken Service bits (reservert i DSSS, men brukes i 802.11b): 1 bit øker lengden, 1bit for clock lock, og 1 bit for typen modulasjon... Clear channel assessment: -energy level -decoding over tid -Kombinasjon PLCP Preamble Sync 128 bits Sync 56 bits SFD 16 bits PLCP Preamble SFD 16 bits Signal Service 8 bits 8 bits 1 Mbps DBPSK PPDU Signal Service 8 bits 8 bits PPDU PLCP Header Length CRC 16 bits 16 bits PLCP Header Length CRC 16 bits 16 bits MPDU (Variable) 1 Mbps DBPSK 2 Mbps DQPSK 11/5.5 Mbps CCK 802.11 Physical Layer Frame Structure (Long Preamble) 1 Mbps DBPSK 2 Mbps DQPSK MPDU (Variable) 2 Mbps DQPSK 11/5.5 Mbps CCK 802.11 Physical Layer Frame Structure (Short Preamble)

Protokoll stakken med IP Nettverkslaget (IP) Log. Link Ctrl. (802.2) MAC-laget (802.11 MAC) Fysisk lag (802.11 PHY) 802.11 er avhengig av 802.2 for logisk link kontroll 802.2-headeren kommer mellom MAC-headeren og IP-pakken: bytes 24/30 802.11 MAC hdr 1 1 1 1 SNAP SSAP Control SNAP DSAP RFC1042 Encaps. 2 0-2306 4 Type (IP/ARP) IP Pakke FCS SNAP-header Som for Ethernet

Agenda Arkitektur og protokollstakk Hovedfunksjoner til MAC laget MAC ramme format og pakke typer MAC management funksjoner QoS med 802.11e

Hovedfunksjoner i MAC-laget Pålitelig overføring => 4.way handshake: ACK av hver unicast pakke RTS/CTS handshake pga Hidden Node Problem Rettferdig Aksess til kanalen CSMA/CA DCF PCF/HCF Timing Intervals Beskyttelse av dataene som sendes WEP

Pålitelig overføring vha 4 way handshake) Hver unicast pakke ACKes pga upålitelig trådløst medium i.e. 2 way handshake ( Minimal Frame Exchange ) Før pakke sendes, utveksles RTS /CTS RTS = Request To Send CTS = Clear To Send For å håndtere Hidden Node Problem i.e. totalt: 4 way handshake RTS, CTS, Datapakke, ACK

Sette dot11rtsthreshold attributt i MIB Ingen CTS/RTS for pakkelengder kortere enn Threshold (dvs bare 2 way handshake for disse) Korte og lange pakker kan behandles anderledes Egne Retry Counters Mange leverandører vil skru av CTS/RTS helt... RTS/CTS: Hidden Node Problem Data Data A B A RTS CTS (A) Data ACK RTS CTS (A) B

Hovedfunksjoner i MAC-laget Pålitelig overføring => 4.way handshake: ACK av hver unicast pakke RTS/CTS handshake pga Hidden Node Problem Rettferdig Aksess til kanalen CSMA/CA DCF PCF/HCF Timing Intervals Beskyttelse av dataene som sendes WEP Behandles ikke her...

Access til kanalen CSMA/CA CSMA/CA er basis-mekanismen for kanalaksess CSMA = Listen before Talk Fysisk Carrier Sense Akkurat som CSMA til Ethernet (CSMA/CD) CA Virtuell Carrier Sense Hver pakke inneholder Duration informasjon Hver node opprettholder en NAV Network Allocation Vector oppdateres av Duration info Sier hvor lenge kanalen vil være opptatt Alle noder må prosessere alle pakkene på mediet!!! (Eller i Power Save Mode: Må synke med Beacon fra AP)

Funksjoner for aksess til kanalen Distributed Coordination Function (DCF) Basis funksjonen Kjerne-konseptet er Exponential Backoff for retransmisjoner Point Coordination Function (PCF) Optional! Polling-basert, AP poller stasjonene Bl.a. for å implementere tjenestegaranti Halvhjertet standard og sjelden implementert... Timing Intervals Styrer priorietet for aksess til kanalen

DCF: Binær Eksponensiell Backoff 1. MAC mottar pakke for utsendelse 2. MAC utfører fysisk (CSMA) og virtuell (CA) carrier sense 3. Pakken sendes hvis kanalen er ledig 4. Hvis kanalen er opptatt: a) MACen velger en tilfeldig nummerert timeslot (=Backoff Value) i innen et gitt intervall = Contention Window b) MACen inkrementerer Retry Counter c) Deretter decrementeres Backoff value for hver ledige timeslot MACen registrerer, og sender pakken når Backoff Value = 0 d) Hvis ingen ACK mottas, dobles Contention Window og GOTO 4a) 5. Avslutt hvis ACK mottatt (i.e. success) eller hvis Retry Counter når en gitt grense (i.e. give up)

PCF: AP-kontrollert polling Erstattes av 802.11 e AP sender Beacon Frame for å ta kontroll over kanalen Duration setter NAV hos andre STA (PIFS brukes som en back-up mekanisme, se senere) Beacon Frame setter mediet til opptatt Contention-Free Period (CFP) Under CFP: 1. AP kan sende rammer til STA og STA kan returnere ACK 2. AP kan sende CF-Poll til STA som har bedt om Contention- Free tjeneste STA kan sende en data-ramme for hver CF-Poll den mottar CF-Poll og CF-Ack piggybackes som bits i ramme-headeren AP sender CF-End pakke for eksplisitt å frigi kanalen Duration setter NAV hos andre STA

Prioritet vha Timing Intervals Short Inter-Frame Space (SIFS) Det korteste Inter-Frame Space (IFS) intervallet Brukt for umiddelbar response i basis mekanismen ACK, CTS, Poll-Response (PCF), Data etter CTS Priority IFS (PIFS = SIFS + 1 timeslot) (EIFS har vi utelatt her) AP bruker PIFS for å ta kanalen under CFP, SIFS for å holde den Distributed IFS (DIFS = SIFS + 2 timeslots) Minimum delay for asynkrone rammer som slåss om kanalen Free access when medium is free longer than DIFS DIFS DIFS PIFS Contention Window Busy Medium SIFS Backoff-Window Next Frame Slot time Defer Access Select Slot and Decrement Backoff as long as medium is idle.

Timing og NAV med DCF og 2-way handshake DIFS Time Source (Tx) Destination (Tx) CW Data SIFS ACK DIFS Other NAV Contention Window Defer access = NAV+DIFS Backoff

Timing og NAV med DCF og 4-way handshake DIFS SIFS Time Source (Tx) RTS SIFS Data SIFS Destination (Tx) CTS ACK DIFS Other NAV (RTS) NAV (CTS) CW NAV (data) Defer access Backoff

Timing og NAV med PCF CFP repetition interval CFP repetition interval CFP CP CFP CP B PCF DCF B PCF DCF SIFS SIFS SIFS PIFS SIFS CP B D1+Poll D2+ACK+Poll D3+ACK+Poll D4+Poll CF End U1+ACK U2+ACK U4+ACK PIFS SIFS SIFS SIFS

Hovedfunksjoner i MAC-laget Pålitelig overføring => 4.way handshake: ACK av hver unicast pakke RTS/CTS handshake pga Hidden Node Problem Rettferdig Aksess til kanalen CSMA/CA DCF PCF/HCF Timing Intervals Beskyttelse av dataene som sendes WEP Behandles ikke her...

Andre MAC-funksjoner: Fragmentering Fragment Burst inntil første pakketap inntreffer Må derfor sette NAV på en smart måte: Fragment burst SIFS SIFS SIFS SIFS SIFS SIFS DIFS Time Src. (Tx) Fragment 0 Fragment 1 Fragment 2 CW Dest. (Tx) ACK0 ACK1 ACK2 Other NAV (CTS) NAV (fragment 0) NAV (fragment 1) NAV(fr.2) Other NAV (ACK0) NAV (ACK1)

Andre MAC funksjoner: Scanning For å lete etter nye AP Proprietære algoritmer, men de er basert på: Passiv Scanning (lav energi, men lang tid) Lytter etter Beacon Frames Aktiv Scanning (kort tid, men energikrevende) Sender aktivt ut Probe Request, og Venter på Probe Response Lytter samtidig etter Beacon Frames

Ramme format bytes 2 Frame Control 2 6 6 6 Address Address 1 2 Duration/ ID Address 3 2 6 0-2312 4 Sequence Address Data CRC Control 4 bits 2 2 Protocol version Type Subtype To DS 4 1 1 1 1 1 1 1 1 From DS More Frag Power Retry Mgmt More Data WEP Order Frame Control Type: Data 8 types: Data / Null med CF-Poll og/eller CF-ACK Control RTS, CTS, ACK, PS-Poll (power save), CF-End, CF-End+ACK Management Beacon, Probe Request/Response, Authentication, De-Autentication Association/Re-association Request/Response, Disassociation Annoncement Traffic Indication Map (ATIM)

Noen rammeformater Vanlig rammeformat, f.eks. data i BSS: bytes 2 2 6 6 6 2 0-2312 4 Frame Duration/ Address Address Address Sequence Control ID 1 2 3 Control Data CRC From AP: DA BSSID SA To AP: BSSID SA DA Spesielle Ramme formater ACK bytes 2 2 6 4 Frame Duration Receiver CRC Control Address RTS CTS bytes 2 2 6 6 4 Frame Duration Receiver Transmitter CRC Control Address Address bytes 2 2 6 4 Frame Duration Receiver CRC Control Address

Bakgrunn for noen management funksjoner Åpent medium Funksjon: Authentisering og WEP-kryptering Mobilitet Funksjon: Assosiasjon med AP Delt medium Funksjon: Adresse filtrering Normalt basert på Address-3 feltet Batteri-drevne devicer Funksjon: Power Management + Synkronisering STA syncroniserer med Beacon fra AP AP bufrer inkomne pakker for STA, og sender TIM i Beacon STA våkner for hvert n te Beacon, sjekker TIM, og sender evt PS-Poll for bufrede pakker

Autentisering og Assosiasjon STA må autentisere før den kan (re-) assosiere seg med AP STA kan være autenisert med mange APer Kan for eksempel pre-autenisere seg STA kan bare være assosiert med ett AP Ved re-assosiering med nytt AP, sørger nytt AP for at STA de-assosieres med forrige AP Via DS Bruker kanskje IAPP?

Typisk scenario - I ID: BSSID2 ID: This-SSID ID: BSSID1 i. Merk utvekslingen av kapabiliteter og supporterte data rater mellom STA og AP ii. iii. iv. Kun ensidig autentisering av STA, dvs. STA kan ikke autentisere AP Punkt 4. og 5. utføres ikke ved Open Authentication uten WEP. Da kjøres Null-algoritmen Listen_interval = n betyr at STA vil lytte til hvert n te Beacon (i.e. i Power Save Mode) v. Association_ID (AID) brukes for polling 9. DATA TRANSMISSIONS 1. Probe_Request(SSID= /0, STA_rates) 2. Probe_Response(Timestamp, beacon_interval, AP_capabilities, SSID= This-SSID, AP_rates, PHY-parameters) 3. Authentication(Algorithm_no=1, sequence_no=0) 4. Authentication(Algorithm_no=1, sequence_no=1, Challenge= abcdefgh ) 5. Authentication(Algorithm_no=1, sequence_no=2, Challenge=RC4(key, abcdefgh )) 6. Authentication(Algorithm_no=1, sequence_no=3, Status_code=Success) 7. Association_Request(STA_capabilities, listen_interval, SSID= This-SSID, STA_rates) 8. Association_Response(AP_capabilities, Status_code = Success, Association_ID, AP_rates)

Typisk scenario - II ID: This-SSID 1. DATA TRANSMISSIONS 2. Beacon(Timestamp, beacon_interval, AP_capabilities, SSID= This-SSID, AP_rates, PHY-parameters, etc...) 3. Authentication(Algorithm_no=1, sequence_no=0) 4. Authentication(Algorithm_no=1, sequence_no=1, Challenge= abcdefgh ) 5. Authentication(Algorithm_no=1, sequence_no=2, Challenge=RC4(key, abcdefgh )) 6. Authentication(Algorithm_no=1, sequence_no=3, Status_code=Success) 7. Re-Association_Request(STA_capabilities, listen_interval, SSID= This-SSID, STA_rates, Current_AP_Address) i. På forrige slide brukte STA aktive scanning, Her viser vi eksempelet med passiv scanning. ii. iii. STA kan pre-autentisere seg i god tid med mange APer for sikkerhets skyld uten å måtte (re-)assosiere seg Noen implementasjoner vil ikke kreve ny authentiserting, når STA allerede har authentisert med et annet AP 8. Reassociation message sent to Current_AP_Address using IAPP or proprietary protocol 9. Re-Association_Response(AP_capabilities, Status_code = Success, Association_ID, AP_rates) 10. DATA TRANSMISSIONS

Typisk scenario - III ID: This-SSID 1. Disassociation (Reason_code = 4 (i.e. Disassociated due to inactivity )) 2. Deauthentication(Reason_code = 3 (i.e. Deauthenticated because STA is leaving ))

Agenda Arkitektur og protokollstakk Hovedfunksjoner til MAC laget MAC ramme format og pakke typer MAC management funksjoner QoS med 802.11e* *) Info om 802.11e er basert på: - 802.11e spec en (draft) - Bok: Multimedia Wireless Networks - Artikler, bl.a. Inside 802.11e: Making QoS a reality over WLAN Connections

Agenda Arkitektur og protokollstakk Hovedfunksjoner til MAC laget MAC ramme format og pakke typer MAC management funksjoner QoS med 802.11e Bakgrunn og behov for 802.11e Trafikk klassifisering ( Category og Stream ) Kanal aksess og pakke skedulering Signalering (av Queue State og Traffic Spec. ) Tilleggsfunksjoner Nye rammeformater for QoS

802.11e fordi 802.11 ikke støtter QoS DCF Klassifisering: Ingen - og derfor ingen tjeneste differensiering Kanal Aksess: Contention-basert Pakke skedulering: All trafikk i samme FIFO køen PCF Klassifisering: Ingen - og derfor ingen tjeneste differensiering for ulik trafikk fra samme STA Kanal Access: Polling-basert. Men offer for mulig delay av Beacon og av CPF lengde pga trafikk fra ulike STA. Pakke scedulering mellom devicer: Poll-frekvens og pollsekvens ikke standarisert Pakke skedulering på en stasjon: All trafikk i samme FIFOkøen, fordi det ikke er noen klassifisering DERFOR: Ingen kjente implementasjoner av PCF

802.11e s to målsetninger er derfor: 1. Kvantitativ (parameterisert) QoS Tilfredstille en applikasjons trafikk spesifikasjon (TSPEC) QoS for ulike Traffic Streams Kan sammenligne med IntServ 2. Differensiert (prioritert) QoS Prioriterer mellom ulike typer trafikk QoS for ulike trafikk kategorier Kan sammenligne med DiffServ

QoS enhancements i 802.11e 1. Trafikk klassifisering: Traffic Categories Traffic Streams (i.e. per-flow klassifisering) 2. Kanal Aksess og pakke skedulering: Nye MAC funksjoner: EDCF (Enhanced DCF) For Traffic Categories HCF (Hybrid Coord. Func.) For Traffic Streams 3. QoS Signalering 4. Nye ramme-typer for å støtte QoS

8 ulike trafikk kategorier Jmfr: 802.1p/Q og 802.1D MAC SAP bruker 802.1D priority tags (0..7, der 0 faktisk ikke har lavest prioritet. Se tabellen.) 4 køer!

Strict priority queuing... og ulike trafikk kategorier behandles også ulikt over kanalen, vha EDCF (= HCF-EDCA ) Ulike trafikk kategorier i ulike køer på de ulike stasjonene No. of Queues Defining Traffic Type 1 2 3 4 5 6 7 8 BK BK BK BK BK BE BE BE BE BE BE EE CL CL CL CL -- BE EE CL VI VO VI VI VO BE EE CL VI VO NEI! Her er boka feil! Standarden og artikkelen spesifiserer bruk av kun 4 køer. Se forrige slide! VO VO VO VO NC NC

Max 8 ulike trafikk streams for hver stasjon Hver trafikk stream har en gitt TSPEC Trafikk attributter: Pakke størrelse, rate, osv Trafikk karakteristikker: CBR/VBR, max delay, max jitter, osv Acknowledgement Policy Ulike trafikk streams behandles ulikt over kanalen, vha HCF

Trafikk klassifisering på stasjonen av både kategorier og strømmer 4 køer!

HCF: EDCA og HCCA Merk at boka feilaktig fremstiller at man har to funksjoner: HCF og EDCF I følge standarden har man kun HCF, med underfunksjoner: HCCA (tilsvarer HCF i boka) og EDCA (tilsvarer EDCF i boka):

EDCA ( EDCF ) og HCCA ( HCF ) kjøres sammen HC distribuerer Transmission Opportunities (TXOPs)

Hver kø har egen kanal access funksjon EDCA parametere settes av AP (se neste side) med intern kollisjonsløsning dvs virtuell backoff mekanisme mellom køene!

EDCA kanal aksess AP fastsetter parametere for hver kø: AIFS length Contention Window Length (CW) Persistence (PF) Maximum duration of transmission (TXOP limit)

EDCA Admission Control STA sender ADDTS (i.e. add TSPEC ) management ramme til AP med TSPEC som beskriver sine QoS krav Hvis AP ikke godkjenner disse, må STA redusere sine krav STA kan alltid bruke Best Effort eller Background AP kan slette en TSPEC hvis nødvendig For eksempel ved endring a kanal forholdene eller etter time-out

ECDF QoS Architecture

HCCA HC kontrollerer aksess til kanalen HC poller STA, og distribuerer dermed Transmission oportunities (TXOPs) HC bruker TSPECene til å bestemme når en STA skal gis en TXOP

HCCA QoS Architecture

HCCA underspesifisert? HCCA definerer polling kanal aksess QoS signallering TS classifisering Men ikke definert: Hvordan HCCA skedulering skal utføres Sammenheng mellom HCCA parametere og QoS krav (TSPEC) Algoritmer for å beregne pollesekvens og tidsintervallene til HCCA CF-Poll

Agenda Arkitektur og protokollstakk Hovedfunksjoner til MAC laget MAC ramme format og pakke typer MAC management funksjoner QoS med 802.11e Bakgrunn og behov for 802.11e Trafikk klassifisering ( Category og Stream ) Kanal aksess og pakke skedulering (HCF med EDCA og HCCA) Signalering (av Queue State og Traffic Spec. ) Tilleggsfunksjoner Nye rammeformater for QoS

QoS Signalering 3 måter å signallere Under CFP vha HCF Under CP vha EDCF Under CP vha CC (Controlled Contention) STA kan sende resource requests i CC periode (uten EDCF trafikk) Queue State Indicator Signalling men algoritmen for å koble kø-status til TXOP er ikke definert TSPEC Signalling Samstemmes med høyere lags signallering (RSVP, NSIS)

Tilleggsfunksjon: CFB Contention-Free Bursts (CFB) Hvis en STA har gjenstående tid av TXOPen kan den fortsette å sende pakker, med kun SIFS intervall imellom CBF representerer en egen frame exchange sequence (ulikt 802.11!) Kan brukes for TXOPs både under HCCA og EDCA CFB kan øke kanal-effektiviteten til 802.11e Brukes også til å øke effektiviteten til 802.11g

Tilleggsfunksjon: Immediate BA Block Acknowledgement (BA) En STA kan sende mange data-pakker fortløpende uten ACK i en CFB BA må først forhandles og settes opp 1. Immediate BA: STA sender BAR ved slutten av CFB:

Tilleggsfunksjon: Delayed BA 2. Delayed BA ACK sendes i neste TXOP for low capablity implementations gir lengre tid å beregne (?) ACKen

Tilleggsfunksjon: DLP Direct Link Protocol (DLP): To STA kan sende pakker direkte uten å gå via AP (ulikt 802.11!), dvs setter opp en direkte link (soft state) All signalering går gjennom AP (i.e. AP må tillate DLP)

Tilleggsfunksjon: APSD Automatic Power Save Delivery (APSD): Videreføring av 802.11 power save mode En STA kan våkne opp til et bestemt skedulert (forutbestemt) tidspunkt sett i forhold til gitte Beacon I.e. ulike STA kan våkne til ulike tider for å motta akkurat sin egen pakke, altså bedre enn 802.11 power save mode APSD signaleres vha en TSPEC med APSD-flagget satt

Nytt ramme format for QoS data bytes 2 Frame Control 2 6 6 6 6 Address 1 Address 2 Address 3 Sequence Control Duration/ ID 2 2 0-2312 4 Address QoS Data CRC 4 Control bits 2 2 4 1 1 1 1 1 1 1 1 Protocol version To Type Subtype DS From DS More Frag Power Retry Mgmt More Data WEP Order Frame Control (Type = Data): 1ste subtype bit for datapakker angir at dette er en QoS pakke 8 nye typer: QoS-Data / QoS-Null med CF-Poll og/eller CF-ACK

1ste bit av TID bestemmer om neste 3 bit gjelder UP for prioritert TC, eller TSID for parametrisert TS EOSP Settes til 1 når HC skal markere slutten på en Service Periode (SP) ACK policy skiller mellom Normal ACK No ACK No Explicite ACK BlockACK QoS Control format for QoS Data bytes 2 Frame Control 2 6 6 6 6 Address 1 Address 2 Address 3 Sequence Control Duration/ ID 2 2 0-2312 4 Address QoS Data CRC 4 Control bits 4 2 1 1 TID EOSP (HC) Info-type (STA) ACK policy Resrd 8 Info (For HC: TXOP limit for CF-Poll For STA: TXOP duration request or queue length)

To nye MAC control rammer Frame Control (Type = Control): To nye Subtypes for å spesifisere: Protocol version Block_Acknowledgement_Request (BAR) bytes 2 2 6 6 2 2 4 Frame Duration/ Address Address BAR Control Block ACK Starting CRC Control ID 1 (RA) 2 (TA) (TID + rsrvd bits) Sequence Control bits 2 2 4 1 1 1 1 1 1 1 1 To Type Subtype DS From DS More Frag Power Retry Mgmt Block_Acknowledgement (BA) More Data WEP Order bytes 2 2 6 6 2 2 128 (!) 4 Frame Duration/ Address Address BA Block ACK Starting Block ACK CRC Control ID 1 (RA) 2 (TA) Control Sequence Control Bitmap Første 64 bit av bitmap brukes til å ACKe 64 pakker, f.o.m. pakken med sekvensnummer. som angitt i Block ACK Starting feltet.

Nye Fixed Fields og Information Elements for QoS Disse brukes til å formidle QoS kapabiliteter og parametere. Brukes i ulike rammer: Beacon Frames Probe Responses Osv...... se 802.11e spec en for detaljer... Signalering av TSPEC...... se 802.11e spec en for detaljer...