Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica

Elaborato finale in Protocolli per reti mobili

802.11aa: miglioramenti livello MAC per streaming audio video 2016/17

Candidato: Antonio Martinelli matr. N46001688

[Dedica]

Indice 802.11aa: miglioramenti livello MAC per streaming audio video ....................................................... I

Indice .............................................................................................................................................. IIIIntroduzione ..................................................................................................................................... 4Capitolo 1: Analisi delle problematiche .......................................................................................... 5

1.1 Problematiche relative al multicast ........................................................................................ 51.2 Gestione delle priorità intra-Access Category ................................................................. 61.3 Basic Service Sets sovrapposti ......................................................................................... 8

1.3.1 Effetto Neighborhood Capture ........................................................................................ 8Capitolo 2: Soluzioni adottate dallo standard 802.11aa ................................................................. 10

2.1 Stream Classification Service .............................................................................................. 102.2 Group Addressed Transmission Service .............................................................................. 12

2.2.1 802.11v Directed Multicast Service .............................................................................. 13 2.2.2 GCR with Unsolicited Retries ..................................................................................... 142.2.3 GCR with BlockAck ..................................................................................................... 152.2.4 Confronto dei meccanismi di trasmissione multicast ................................................... 15

2.3 Il meccanismo QLoad .......................................................................................................... 16Conclusioni .................................................................................................................................... 19Bibliografia .................................................................................................................................... 20

4

Introduzione

Il primo standard IEEE 802.11 non era in grado di gestire il traffico audio video in maniera

efficiente attraverso una rete wireless LAN. In primis perché la banda disponibile, ai tempi

della prima versione dello standard non permetteva throughput elevati. In secondo luogo,

perché lo standard supportava solo una comunicazione di tipo best-effort, non adatto per le

performance richieste da questo tipo di applicazioni. La maggior parte delle problematiche

sono state risolte con il rilascio di nuovi emendamenti dello standard, in particolare con

802.11n, che attraverso strumenti i quali la tecnologia MIMO e la banda a 5Ghz ha

incrementato il throughput massimo raggiungibile, e con 802.11e che ha introdotto per la

prima volta il meccanismo della Quality of Service. Nonostante però questi emendamenti,

restano ancora presenti alcuni problemi che affliggono lo streaming di contenuti video su di

una rete WLAN. Alcune di queste problematiche vengono trattate e risolte

nell’emendamento 802.11aa.

5

Capitolo 1: Analisi delle problematiche

In generale la trasmissione di flussi audio/video è un problema che richiede una particolare

attenzione in quanto, data la natura tempo-critica del problema, è necessario priorizzare sulla

rete questo tipo di traffico, affinché altri flussi di dati, che non richiedono un particolare

trattamento in termini di jitter e latenza (e.g. traffico web, comunicazioni testuali), non ne

rallentino il flusso. Nelle reti wireless il problema è però più difficile da arginare, proprio

perché il mezzo trasmissivo è di per sé rumoroso, tempo-variante e asimmetrico.

È quindi essenziale, nell’ambito delle reti wireless, operare ai livelli MAC e PHY dello stack

protocollare dato che questo tipo di problematiche richiedono accorgimenti alle modalità di

trasmissione dei frame dati.

1.1 Problematiche relative al multicast

In determinati ambiti di applicazione (e.g. streaming di flussi video in un hotspot pubblico,

in ambito didattica, in ambito IOT) le trasmissioni multicast wireless rappresentano un

efficiente metodo di trasmissione, il quale permette di risparmiare una buona quantità banda

sfruttando le proprietà broadcast del mezzo. Il metodo di trasmissione multicast risulta però,

nella sua versione specificata nello standard, non affidabile, in quanto non prevede

meccanismi di feedback che permettono ad ogni frame trasmessa di essere riconosciuta

(“acknowledged”) dal ricevitore. Questo meccanismo non è utilizzato per trasmissioni di

tipo multicast dato che lo scambio simultaneo di messaggi di Ack tra il sender e il gruppo

di receiver genererebbe un enorme overhead. Lo standard non prevede inoltre che i frame

6

multicast siano inviati con la tecnica RTS/CTS, esponendo cosi la trasmissione al problema

del terminale nascosto. Un'altra problematica è la mancanza di meccanismi di ritrasmissione

che assicurino la ricezione di un frame. In realtà questo tipo di controllo potrebbe esser

effettuato dai livelli superiori ma si introdurrebbe ulteriore overhead. È quindi consigliabile

che queste verifiche avvengano a livello MAC. Infine i frame inviati in multicast sono

limitati ad una velocita di trasmissione che appartiene al Basic Rate Set (BRS) (un insieme

di coding scheme a bassa modulazione), limitando non solo il throughput della trasmissione

multicast ma occupando il mezzo wireless per più tempo e rallentando significativamente

l’intero BSS.

1.2 Gestione delle priorità intra-Access Category

Come già riportato lo standard 802.11e introduce il meccanismo della Quality of Service.

Questo avviene attraverso l’utilizzo di 4 funzioni EDCA (Enanched Distributed Controlled

Access) che regolano la contesa per l’accesso al mezzo dei frame che devo essere trasmessi.

Queste definiscono 4 Access Category (AC) che differenziano il traffico in base alla priorità

(Voice, Video, Best Effort, Background). La differenziazione avviene attraverso la

modulazione dei parametri per la contesa come:

• La dimensione minima e massima della Contention Window (CWmin e CWmax).

• L’Arbitration Inter-Frame Space (AIFS)

• La dimensione della Transmission Opportunity (TXOP)

A categorie di accesso con priorità più alta (VO e VI) vengono assegnati valori di contesa

minori in modo tale da aumentare la probabilità di occupare il mezzo trasmissivo.

Nonostante però i meccanismi introdotti con 802.11e sussistono limitazioni all’utilizzo delle

AC. Prendiamo il caso in cui su di uno stesso BSS siano in corso una videoconferenza e uno

streaming video generico. La prima sarà ovviamente meno tollerante in termini di jitter e

delay, rispetto alla seconda. Ma per come è specificato nello standard 802.11e questi due

tipi di traffico appartengono alla stessa categoria di accesso e per questo i due flussi verranno

7

trattati alla stessa maniera dalle funzioni EDCA. Inoltre più flussi con valori di contesa bassi

aumentano la probabilità di collisioni, introducendo ulteriori ritrasmissioni e peggiorando il

throughput. Un'altra necessità è quella di definire delle modalità di deterioramento del flusso

audio/video, ovvero, fare in modo che in caso di rallentamenti sul canale di trasmissione, i

pacchetti possano essere scartati in maniera elastica, in da non compromettere il

funzionamento dello streaming e soprattutto senza dover effettuare operazioni d’ispezione

interne al pacchetto stesso.

Figura 1: Modello di riferimento per l’emendamento 802.11e (dal materiale didattico per il corso di Protocolli per Reti Mobili [9])

8

1.3 Basic Service Sets sovrapposti

Con il diffondersi delle reti wireless il problema della sovrapposizione dei Basic Service

Sets ha assunto sempre più rilevanza. È stato provato attraverso simulazioni che in ambiente

domestico si può arrivare oltre le 30 BSSs sovrapposti [8]. Accorgimenti come l’utilizzo di

bande di frequenza alternative (come la banda 5GHz introdotta dall’emendamento 802.11n)

hanno permesso di mitigare questo fenomeno ma non di rimuoverlo del tutto. Di fatto anche

in questi casi con 19 canali disponibili non sovrapposti ci si può trovare facilmente con 3 o

più BSS sovrapposti. Quando si utilizzano funzioni come l’EDCA, l’AP ha il compito di

trasmettere i nuovi frame sulla base delle informazioni che ha a disposizione, relative solo

al proprio BSS. Di conseguenza è possibile garantire la priorità e la protezione necessaria

nel contesto di BSSs sovrapposti.

…

1.3.1 Effetto Neighborhood Capture

È altamente probabile che si vengano a creare situazioni nelle quali meccanismi di

Figura 2: sovrapposizione di 3 BSS con rischio d effetto Neighborhood Capture

9

protezioni delle trasmissioni risultano indispensabili ai fini di ottenere flussi di

comunicazione affidabili. È il caso del Neighborhood Capture effect. Nello scenario in cui

sono presenti 3 BSS, di cui uno (il BSS nel “mezzo”) si sovrappone con i restanti due (vedi

Figura 2), è possibile che il WM sia monopolizzato. Con l’utilizzo delle funzioni di accesso

distribuito, i 3 AP provano contendersi equamente il WM. Ma come è possibile notare

nell’esempio (vedu Figura 3), gli AP A e C occupano il canale per la maggior parte del

tempo non permettendo a B di trasmettere. Questo avviene perché A e C non sono in grado

di ascoltarsi vicenda, e quindi dovranno contendersi il mezzo solo con B, viceversa B dovrà

contendersi il mezzo trasmissivo sia con A che con C.

Figura 3: Diagramma temporale che descrive l’occupazione del canale wireless, mettendo in evidenza l’effetto Neighborhood Capture (tratta da [10])

10

Capitolo 2: Soluzioni adottate dallo standard 802.11aa

Come osservato precedentemente, lo streaming di contenuti audio/video su di una rete

wireless 802.11 ha diverse limitazioni dal punto di vista delle performance e

dell’affidabilità. L’emendamento IEEE 802.11aa introduce nuovi meccanismi, sulle

specifiche base, in grado di migliorare l’affidabilità dello streaming audio e video su reti

wireless, non compromettendo però il restante traffico sulla rete. L’emendamento presenta

quattro nuovi meccanismi:

• Stream Classification Service (SCS)

• Group Addressed Transmission Service (GATS)

• Meccanismo per la gestione della sovrapposizione dei BSSs

• Interfunzionamento con IEEE 802.1 Audio Video Bridging (AVB)

Per gli scopi di questo elaborato tralasceremo l’ultimo punto.

2.1 Stream Classification Service

Come abbiamo avuto modo di notare, lo streaming di contenuti multimediali beneficerebbe

dall’introduzione di meccanismi di priorità Intra-AC. Questo servizio di Stream

Classification mira proprio ad aumentare la granularità delle categorie di accesso al mezzo

(AC) che fanno uso dei meccanismi della EDCA. Nello specifico aggiunge due alternate

queue (A_VO e A_VI) alle code di trasmissioni già presenti nello standard. Questo avviene

attraverso un nuovo campo dot11AlternateEDCAActivated (1 bit) aggiunto nei frame MAC,

11

permettendo il passaggio dalle 4 code di trasmissione previste in 802.11e alle 6 code previste

in 802.11aa (vedi Figura 4).

Figura 4: Relazioni tra User Priority e Access Category (da IEEE 802.11aa [1])

Quando il bit dot11AlternateEDCAActivated è impostato su true una funzione di

scheduling, posta al di sopra della VO EDCA (analogamente avviene per VI EDCA)

seleziona dalla coda VO o VO_A (per i flussi video VI o VI_A) la MSDU (MAC Service

Data Unit) da passare alla funzione EDCA che risolve eventuali collisioni interne, come già

definito dallo standard (vedi Figura 5). La scelta dell’algoritmo di scheduling non è definita

nello standard ed è quindi affidata alla fase di implementazione.

Al fine di differenziare maggiormente il traffico tra i vari flussi, in 802.11aa viene aggiunto

il campo Drop Eligibility Indicator (DEI) (1 bit) nel frame MAC. Questo campo permette

di riconoscere quali frame è possibile scartare. Ciò avviene assegnando ai frame con bit DE

impostato su true, un numero massimo di ritrasmissioni minore rispetto a quello di default.

Questa scelta permette di ottimizzare il flusso video in fase di presentazione, in quanto

permette di scartare informazioni meno rilevanti ai fini della decodifica video a livello

applicativo. È importante notare che lo Stream Classification Service non altera il

12

comportamento del livello MAC, in quanto questo si basa sui meccanismi già definiti di

EDCA, consentendo l’interoperabilità con degli emendamenti precedenti a 802.11aa,

ereditando però anche una serie di limitazioni relative allo streaming video legate al

meccanismo utilizzato.

2.2 Group Addressed Transmission Service

Come accennato precedentemente le trasmissioni multicast soffrono di due problematiche

principali: la mancanza di un servizio che conferisca affidabilità allo scambio di frame,

l’inefficienza nella trasmissione data dall’utilizzo dei soli rate appartenenti al Base Rate Set.

Le soluzioni che sono state proposte nel tempo sono varie e sfruttano diversi meccanismi.

Il Leader Based Protocol (LBP) [5] prevede la scelta di un leader, tra le stazioni appartenenti

al gruppo di cast, che ha il compito di proteggere e riconoscere la trasmissione scambiando

Figura 5: Modello di riferimento per l’emendamento 802.11aa quando il bit dot11AlternateEDCAActivated è impostato su true (da IEEE 802.11aa [1])

13

rispettivamente, frame RTS/CTS e frame Ack. Resta però il problema della scelta del leader,

percheè non affrontato e aperto a diverse soluzioni. Altre soluzioni come la Broadcast

Support Multiple Access (BSMA) [5] e la Broadcast Media Window (BMW) [6] adattano il

meccanismo della RTS/CTS e dell’Ack alle comunicazioni multicast, ottenendo però

soluzioni abbastanza inefficienti, che non riescono a soddisfare reti con un grosso numero

di stazioni. L’emendamento 802.11aa opta per l’utilizzo del Group Addressed Transmission

Service (GATS). Questo mette a disposizione diversi meccanismi per migliorare la

trasmissione multicast:

• 802.11v Directed Multicast Service

• Groupcast with Retries (GCR) Unsolicited Retry (ritrasmissione non sollecitata)

• Groupcast with Retries (GCR) BlockAck

A questi si aggiunge il metodo No-Ack/No-Retry supportato già dallo standard (vedi Figura

6a). È possibile alternare dinamicamente tutti questi meccanismi ed assegnare ad ogni flusso

video una politica di trasmissione diversa in base alle esigenze.

2.2.1 802.11v Directed Multicast Service

Questo meccanismo utilizza le funzioni legacy ereditate dall’emendamento IEEE 802.11v

[7]. Il DMS ha la funzione di incapsulare il traffico multicast in frame unicast, questi

vengono poi trasmessi con le modalità consuete di protezione e riconoscimento (vedi Figura

6c). I frame vengono ritrasmessi finche non sono ricevuti correttamente (riconosciuti dopo

un tempo Short Inter Frame Space con un Ack) oppure vengono scartate al raggiungimento

del numero massimo di ritrasmissioni. L’AP torna quindi a trasmettere la frame dopo un

tempo DIFS (Distributed Inter Frame Space) più il periodo di backoff. Questa rappresenta

la metodologia più affidabile, ma è anche quella con l’overhead maggiore, in quanto scala

linearmente con il numero di stazioni presenti all’interno del gruppo di multicast.

14

2.2.2 GCR with Unsolicited Retries

L’approccio adottato dal GCR with Unsolicited Retries (vedi Figura 6b) si basa sull’idea di

ritrasmettere lo stesso frame un numero predefinito di volte, separato da un intervallo

composto da un generico DIFS più il periodo di backoff, nel tentativo di aumentarne la

probabilità di ricezione. Questo metodo inoltre non prevede alcun meccanismo di

riconoscimento, in quanto si presume il frame sia stato ricevuto correttamente dopo un

numero ridondante di ritrasmissioni. Il metodo non garantisce l’affidabilità ma è in grado di

offrire minore overhead (dato dall’assenza di un riconoscimento che deve avvenire per ogni

stazione) e una migliore scalabilità in presenza di un numero elevato di stazioni appartenenti

al gruppo di ricezione multicast.

Figura 6: metodi di trasmissione disponibili mediante l’uso del Group Addressed Transmission Service (diagramma da “Performance Evaluation of the IEEE 802.11aa Multicast Mechanisms for Video Streaming” [3])

15

2.2.3 GCR with BlockAck

Questo metodo riutilizza il meccanismo del BlockAck già introdotto nell’emendamento

IEEE 802.11n e lo adatta al tipo di trasmissione multicast. Il meccanismo prevede l’invio

in multicast di un blocco di frame contigue, divise solo da un tempo SIFS, e

successivamente, l’AP invia un BlockAckRequest, al quale le stazioni, a turno,

risponderanno con un BlockAck. Al termine del riconoscimento da parte di tutte le stazioni

l’AP riprende a trasmettere il prossimo blocco di frame. Il meccanismo è disponibile in due

varianti. Il protocollo GCR Immediate BlockAck prevede che la STA ricevente, risponda

immediatamente alla BlockAckRequest (vedi Figura 5d), mentre il GCR Delayed BlockAck

prevede che dopo la ricezione del BlockAckRequest parta la procedura di backoff prima

dell’invio del BlockAck (vedi Figura 6e). Questa modalità è presente per favorire le stazioni

con poca potenza di calcolo, che altrimenti avrebbero problemi nel generare la ACK bitmap

nel solo tempo SIFS. Questo metodo permette di ottenere un buon compromesso tra

affidabilità ed overhead.

2.2.4 Confronto dei meccanismi di trasmissione multicast

In riferimento alla Figura 7, possiamo notare che non è possibile determinare con esattezza

quale metodo di trasmissione multicast sia in assoluto il migliore per quanto riguarda la

trasmissione di flussi video. È possibile però scegliere in base alle esigenze

dell’applicazione di nostro interesse. In applicazioni dove non è richiesta la totale

affidabilità della trasmissione possiamo adoperare meccanismi come il GCR Unsolicited

Retries, che permetterà di occupare il mezzo per poco più del tempo necessario per

trasmettere i frame. In applicazioni in cui invece è fondamentale che tutti i frame siano

ricevuti correttamente posso affidarmi al metodo DMS. È possibile (perché non definito

direttamente dallo standard, ma lasciato all’implementazione) anche variare il meccanismo

16

di trasmissione on-the-fly in base allo stato di congestione del canale. In via definitiva è

possibile dire che il metodo più flessibile è rappresentato dal Group Cast with Retries Block

Ack, il quale garantisce totale affidabilità, con il compromesso però di un elevato costo in

termini di implementazione ed elaborazione. È bene ricordare nonostante lo Std. 802.11aa

metta a disposizione diversi parametri settabili, la scelta di questi è lasciata alla fase di

implementazione. In questo modo si lascia la possibilità di regolare i parametri in maniera

tale da ottenere le caratteristiche di trasmissione desiderate.

2.3 Il meccanismo QLoad

L’emendamento 802.11aa prevede l’introduzione del QLoad per la gestione del problema

degli OBSSs. L’idea alla base è quella di un meccanismo distribuito, il cui scopo è quello

di informare i BSS vicini (“neighbors”) della tipologia e della quantità di traffico QoS

gestita da ogni AP. Questo avviene mediante lo scambio di frame QLoad Report, che

possono essere trasmesse su richiesta (QLoad Request) o aggregate alle comuni frame di

beacon.

Multicast Policies Overhead Scalabilità Complessità Affidabilità

Legacy multicast Nessuno Alta Bassa Bassa

DMS Grande Bassa Media Alta

GCR Unsolicited

Retries Piccolo Alta Bassa Dipendente dall’

implementazione

GCR BlockAck Dipendente dall’ implementazione

Dipendente dall’ implementazione Alta Dipendente dall’

implementazione

Figura 7: tabella comparativa dei metodi di trasmissione disponibili mediante l’uso del Group Addressed Transmission Service (diagramma da “IEEE 802.11aa: Improvements on video transmission over Wireless LANs” [2])

17

Le informazioni condivise e presenti nei frame QLoad Report sono (vedi Figura 8):

• Element ID

o Chiave per identificare i frame Qload Report

• Length

o La lunghezza del report è variabile e per questo necessita di essere definita

• Potential e Allocated Traffic Self

o Informazioni sul traffico potenziale e allocato all’interno del proprio BSS

• Allocated Traffic Shared

o Informazioni sul traffico generato dal neighborhood

• EDCA e HCCA Access Factor

o Due valori numerici che stimano la qualità del canale per le due funzioni di

accesso

• HCCA Peak

o Picco massimo richiesto per la TXOP (Transmission Opportunity) nel

periodo di 1s

• Overlap

o Numero di BSS che condividono lo stesso canale

• Sharing Policy

Figura 9: Formato del campo QLoad (da IEEE 802.11aa [1])

Figura 8: Formato del QLoad Report element (da IEEE 802.11aa[1])

18

Le informazioni nei campi Traffic hanno il formato in Figura 9 e sono:

• Media

o una stima del tempo per il quale il WM è occupato da trasmissioni scheduled

• Deviazione standard dalla media

• AC_VO Streams

o numero di trasmissioni che utilizzano l’AC_VO

• AC_VI Streams

o numero di trasmissioni che utilizzano l’AC_VI

L’obbiettivo è proprio quello di creare un ambiente in cui il Wireless Medium sia condiviso

in maniera equa tra tutti i BSS. Queste informazioni permettono quindi agli AP di scegliere

il canale di trasmissione appropriato, o nel caso in cui non è possibile evitare

sovrapposizioni, condividere il canale in maniera efficiente. Lo standard inoltre dà delle

indicazioni circa la procedura per la selezione del canale:

1. Si cerca un canale libero

2. Nel caso non sia presente un canale libero, si cerca i canali con il minor numero di

BSSs sovrapposti

3. Infine si sceglie il canale con il minor traffico QoS (informazione fornita dai frame

QLoad Report)

19

Conclusioni

Abbiamo avuto modo di fare una panoramica sugli aspetti e sulle caratteristiche più rilevanti

adoperate in questo emendamento dello Std. 802.11. Abbiamo notato che nonostante

l’introduzione di tecnologie più sofisticate come schemi di modulazione più complessi,

l’adoperamento di nuove bande di frequenza, le soluzioni alle problematiche poste si

riconducono per lo più nel compiere scelte dove è presente un trade-off.

…

20

Bibliografia [1] IEEE 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)

specifications – AMENDMENT 2: MAC enhancements for robust audio video streaming

(adoption of IEEE Std 802.11aa-2012), 2012

[2] K. Maraslis, P. Chatzimisios, A. Boucouvalas, “IEEE 802.11aa: Improvements on

video transmission over Wireless LANs”, IEEE ICC 2012-Ad-hoc and Sensor Networking

Symposium

[3] A. de la Oliva, P. Serrano, P. Salvador, A. Banchs, “Performance Evaluation of the

IEEE 802.11aa Multicast Mechanisms for Video Streaming”

[4] J. Kuri and S. K. Kasera, “Reliable multicast in multi-access wireless LANs,” Wireless

Networks, vol. 7, 2001.

[5] K. Tang and M. Gerla, “Random access MAC for efficient broadcast support in ad hoc

networks,” in Proceedings of the IEEE Wireless Communications and Networking

Conference (WCNC), 2000.

[6] K. Tang and M. Gerla, “MAC reliable broadcast in ad hoc networks,” in Proceedings of

the IEEE MILCOM 2001, 2001.

[7] IEEE 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)

specifications - AMENDMENT 8: IEEE 802.11 Wireless Network Management, IEEE Std.

802.11v, 2011

21

[8] G. Smith, D. Dillon, J. Janecek, “Overlapping BSS proposed solution,” IEEE Video

Transport Stream Study Group submission 11-08-0457-03, 2008.

[9] S. Avallone, Materiale didattico per il corso di Protocolli per Reti Mobili, 2015

[10] M. Benveniste, ‘Neighborhood Capture’ in Wireless LANs

http://slideplayer.com/slide/10922754/