2 Controllo di Accesso al Mezzo (MAC)
2.1 Introduzione
In questo capitolo verranno descritte le funzioni principali svolte dal livello di Controllo di Accesso al Mezzo; in particolare si analizzeranno separatamente le funzioni dei tre sottolivelli, quello di Convergenza di Servizio Specifico (CS), quello di MAC a Parte Comune (MAC CPS), e quello di Privacy, che compongono il MAC.
2.2 Sottolivello di Convergenza di Servizio Specifico (CS)
Il Sottolivello di Convergenza di Servizio Specifico (CS) è collocato al disopra del sottolivello MAC a parte comune (MAC CPS) ed utilizza, attraverso il punto di accesso al servizio (MAC SAP), i servizi forniti dal MAC CPS (Figura 1.1). La CS svolge come funzione primaria la classificazione dei protocolli di unità dati (PDU) per la propria connessione MAC. In particolare la CS accetterà i PDU dal livello superiore attraverso il CS SAP, li classificherà e se richiesto effettuerà su di essi delle procedure di abilitazione del QoS e di allocazione di banda, dopodiché consegnerà i CS PDU al MAC SAP adatto. Naturalmente la CS sarà in grado di compiere queste funzioni anche nel verso opposto, cioè dal MAC SAP al CS SAP. Oltre a queste funzioni di base, la CS può anche svolgere funzioni come la soppressione della testata del payload (PHS).
Lo Standard definisce due sottolivelli di CS: il sottolivello di Convergenza con modo di trasferimento asincrono definito per i servizi ATM (2.2.1), e il sottolivello di Convergenza a pacchetto definito per i servizi a pacchetto come IPv4, IPv6, Ethernet e VLAN (2.2.2).
2.2.1 Sottolivello di Convergenza ATM
L'ATM CS è un'interfaccia logica che associa i diversi servizi ATM con il MAC CPS SAP. L'ATM CS accetta le celle ATM dal livello ATM, compie la classificazione e, se è previsto, la soppressione della testata del payload (PHS), infine consegna i CS PDU al MAC SAP adatto.
Di seguito descriveremo il formato del PDU ATM, la funzione di classificazione, e quella di soppressione dell’header del payload.
2.2.1.1 Formato del PDU ATM
Gli ATM CS PDU saranno costituiti da un ATM CS PDU Header e dall'ATM CS PDU payload. L'ATM CS PDU payload sarà uguale al payload della cella ATM. L'ATM CS PDU è illustrato nella Figura 2.1.
Figura 2.1
2.2.1.2 Classificazione
Un collegamento ATM, che è unicamente identificato da un paio di valori, l’Identificatore di Percorso Virtuale (VPI) e l’Identificatore di Canale Virtuale (VCI), può essere o un Percorso Virtuale commutato (VP) o un Canale Virtuale commutato (VC). Nel modo VP-commutato, ogni
VCI all'interno di un singolo VPI entrante è automaticamente associato a quello di un VPI in uscita. Nel modo VC-commutato, i valori di ingresso VPI/VCI sono individualmente associati ai valori di uscita VPI/VCI. Così, quando si compie il PHS, l'ATM CS differenzia questi due tipi di collegamenti e compie di conseguenza la soppressione adatta.
Un classificatore è un set di criteri di accoppiamento applicato ad ogni cella ATM che entra nell'ATM CS. E’ composto da alcuni criteri di accoppiamento di cella ATM, come VPI e VCI, e da un riferimento ad un identificatore di connessione (CID). Se una cella ATM è uguale al criterio di accoppiamento specificato, viene consegnata al MAC SAP per essere inviata sul collegamento identificato dal CID.
Per il modo VP-commutato, il campo del VPI, 12 bits per un'interfaccia di network-to-network (NNI) e 8 bits per un'interfaccia di user-to-network (UNI), è associato ad un CID di 16-bit che indica il collegamento MAC sul quale è trasportato. Poiché il QoS e la categoria dei parametri di servizio per il collegamento sono settati all’istaurazione della connessione, questa corrispondenza tra VPI e CID garantisce il corretto mantenimento del traffico da parte del sottolivello di MAC.
Per il modo VC-commutato, i campi del VPI e del VCI, 28 bits totali per un NNI e 24 bits totali per un UNI, sono associati ad un CID di 16-bit che indica il collegamento MAC sul quale sono trasportati. Anche in questo caso la corrispondenza tra VPI/VCI e CID garantisce il corretto mantenimento del traffico da parte del sottolivello di MAC.
2.2.1.3 Soppressione del Payload Header
Durante la soppressione del payload header (PHS), una parte ripetitiva del payload header dei CS SDU è soppressa dall'entità che invia e ripristinata dall'entità ricevente. Nel downlink, l'entità che invia è l'ATM CS della stazione base (BS) e l'entità ricevente è l'ATM CS della stazione di utente (SS). Nell'uplink, l'entità che invia è l'ATM CS della SS, e l'entità ricevente è l'ATM CS della BS. Per risparmiare un’ulteriore banda, le celle ATM multiple (con o senza PHS) che appartengono allo stesso CID possono essere impacchettate e portate da un solo MAC CPS PDU. L’applicazione o no della PHS ad un collegamento ATM viene segnalata, insieme al VPI (per i collegamenti VP-commutati) o al VPI/VCI (per i collegamenti VC-VP-commutati), nella comunicazione DSA-REQ durante creazione del collegamento.
Nel modo VP-commutato, le uniche informazioni dell’header che non vengono soppresse sono l’indicatore del tipo di payload (PTI), i VCI, e i campi di cella a priorità di perdita (CLP). Questi campi saranno incapsulati nel header del CS PDU. La Figura 2.2 mostra un CS PDU che contiene una sola cella ATM VP-commutata con l’header di cella soppresso e la configurazione dell’ATM CS PDU Header per i collegamenti ATM VP-commutati.
Nel modo VC-commutato, le uniche informazioni dell’header che non vengono soppresse sono i campi PTI e CLP. Questi campi saranno incapsulati nel CS PDU Header. La Figura 2.3 mostra un CS PDU che contiene una sola cella ATM VC-commutata con l’header di cella soppresso e la configurazione dell'ATM CS PDU Header per i collegamenti ATM VC-commutati.
Figura 2.3
2.2.2 Sottolivello di Convergenza a pacchetto
La CS a pacchetto comunica con il MAC CP consegnando i MAC SDU al MAC SAP. Questo caso viene usato per il trasporto di tutti i protocolli basati su pacchetti come il protocollo di internet (IP), il protocollo punto-punto (PPP), ed l’IEEE Std 802.3 (Ethernet).
Di seguito descriveremo il formato del MAC SDU, la funzione di classificazione, e quella di soppressione dell’header del payload.
2.2.2.1 Formato del MAC SDU
I PDU dello strato superiore saranno incapsulati nella formato MAC SDU come illustrato nella Figura 2.4. Per alcuni protocolli di payload, ogni payload è composto da un campo di indice di soppressione del payload header di 8 bit (PHSI) seguito dall’effettivo payload; altri protocolli associano direttamente il PDU dello strato superiore sul MAC SDU: un valore pari a zero nel PHSI indica che non è stata applicata al PDU la soppressione dell’header del payload, mentre il valore nell’indice identifica la regola utilizzata per la soppressione. Questo indice è progettato con regole equivalenti sia al peer della BS che al peer della SS per tenere conto della ricostruzione delle informazioni soppresse.
Figura 2.4
2.2.2.2 Classificazione
La classificazione è il processo mediante il quale un MAC SDU viene associato ad un particolare collegamento per la trasmissione tra i peers MAC. Inoltre crea anche un'associazione con le caratteristiche del flusso di servizio di quel collegamento, facilitando la consegna dei MAC SDU con l’adatta restrizione del QoS.
Un classificatore è un set di criteri di accoppiamento applicato ad ogni pacchetto che entra in una rete IEEE Std 802.16-2001. Consiste di alcuni criteri di accoppiamento per specifici protocolli a pacchetto, di una priorità di classificatore, e di un riferimento ad un CID. Se un pacchetto è uguale al pacchetto specificato dal criterio di accoppiamento, viene consegnato al SAP per la consegna sul collegamento definito dal CID.
La classificazione di un pacchetto della SS o della BS consiste nel confronto con classificatori multipli. Ogni classificatore contiene un campo di priorità che determina l'ordine di ricerca per il classificatore. Il classificatore con priorità più alta sarà applicato per primo. Se si trova un classificatore in cui tutti i parametri si accoppiano al pacchetto, questo invierà il pacchetto alla connessione o alle connessioni corrispondenti, identificate mediante l’ID del flusso di servizio (SFID). È possibile che non si riesca ad associare il classificatore di un pacchetto con nessuno dei set di classificatori definiti; in questo caso, il CS può associare il pacchetto con un CID predefinito o scartare il pacchetto; secondo l’implementazione scelta dal costruttore. I classificatori di downlink vengono applicati dalla BS ai pacchetti che sta trasmettendo, mentre i classificatori di uplink vengono applicati dalla SS. Le Figure 2.5 e 2.6 illustrano le associazioni discusse sopra.
Figura 2.6
I classificatori possono essere aggiunti alla tabella sia mediante operazioni di gestione di rete che mediante operazioni dinamiche. Le operazioni basate sul Protocollo di Gestione della Rete Semplice (SNMP) possono vedere i classificatori che sono aggiunti mediante operazioni dinamiche, ma non li possono né cambiare e né cancellare.
Il classificatore che associa un pacchetto ad una connessione, può essere associato ad una regola di soppressione del payload header. Una regola di PHS offre i dettagli su come i bytes dell’header di un pacchetto PDU possano essere omessi, sostituiti con un PHSI per la trasmissione, e di conseguenza rigenerati alla fine della ricezione. Le regole di PHS sono identificate dalla combinazione di {SFID, PHSI}. Quando un flusso di servizio è cancellato, anche tutti i classificatori ed ogni regola di PHS associata saranno cancellati.
2.2.2.3 Soppressione del Payload Header
Nella soppressione del payload header (PHS), una porzione ripetitiva della testata del payload dei MAC SDU dello strato superiore viene soppressa dall'entità che invia e ripristinata dall'entità ricevente. Nell'uplink, l'entità che invia è la SS e l'entità ricevente è la BS. Nel downlink, l'entità che invia è la BS e l'entità ricevente è la SS. Ogni MAC SDU ha un prefisso contenente il PHSI, che indica il campo di soppressione del payload header (PHSF).
Come abbiamo visto, l'entità che invia usa dei classificatori per associare i pacchetti in un flusso di servizio, e mediante questi associa unicamente i pacchetti alla sua regola di PHS associata. L'entità ricevente usa il CID ed il PHSI per ripristinare il PHSF. Una volta che un PHSF è stato assegnato ad un PHSI, non sarà cambiato. Per cambiare il valore di un PHS su un flusso di servizio, bisognerà definire una nuova regola di PHS, quindi rimuovere quella vecchia e aggiungere quella nuova al flusso di servizio. Quando un classificatore viene cancellato, anche la sua regola di PHS associata sarà cancellata.
La PHS può scegliere, mediante il parametro di validità di soppressione del payload header (PHSV), di verificare il payload header prima di sopprimerlo. Inoltre può fare uso di una maschera di soppressione del payload header (PHSM) che permette la selezione dei bytes da non sopprimere.
Questa è usata per inviare solamente i bytes che cambiano, come la sequenza dei numeri IP, mentre si sopprimono quelli che non cambiano.
I costruttori delle SS e delle BS possono implementare la PHS in modo libero, purché venga seguito il protocollo specificato di seguito, ed illustrato dalla Figura 2.7.
Un pacchetto viene sottoposto al sottolivello CS a pacchetto. Il classificatore del pacchetto sarà confrontato con l’elenco delle regole dei classificatori della SS. Individuata la coppia classificatore-regola, questa darà luogo ad un Flusso di Servizio di Uplink, un CID, ed una Regola di PHS. La Regola di PHS fornisce il PHSF, il PHSI, la PHSM, e la PHSV. Se la PHSV è settata, la SS verificherà che i bytes nell’header del pacchetto coincidano con i bytes nel PHSF che stanno per essere soppressi come indicato dalla PHSM. Se la verifica risulta positiva, la SS sopprimerà tutti i bytes nell'Uplink PHSF eccetto i bytes mascherati da PHSM. Quindi, la SS inserirà, come prefisso al PDU, il PHSI e presenterà l’intero MAC SDU al MAC SAP per il trasporto sull'uplink.
Ricevuto il pacchetto, la BS determinerà il CID associato dall’esame del generico MAC header; quindi invierà il PDU al MAC SAP associato a quel CID. La CS a pacchetto ricevente userà il CID ed il PHSI per ricercare il PHSF e la PHSM. Infine la BS radunerà il pacchetto e poi procederà con la sua normale lavorazione. Il pacchetto radunato conterrà i bytes del PHSF. Se la verifica è stata abilitata, i bytes del PHSF uguaglieranno i bytes dell’header originale, altrimenti non ci sarà garanzia sulla loro uguaglianza. Un'operazione simile accade nel downlink.
Figura 2.7
La Figura 2.8 mostra la soppressione ed il restauro del pacchetto quando si usa il mascheramento della PHS. Il mascheramento permette solo la soppressione dei bytes che non cambiano.
Figura 2.8
2.3 Sottolivello MAC di Parte Comune (MAC CPS)
Una rete che utilizza un mezzo condiviso richiede un meccanismo per condividerlo efficientemente. Le reti wireless con topologia punto-multipunto o Mesh (a maglia) sono esempi di condivisione di un mezzo; in questo caso il mezzo è lo spazio attraverso il quale si propagano le onde radio.
2.3.1 Topologia Punto-MultiPunto (PMP)
Il downlink, dalla stazione base (BS) all'utente, opera su una base PMP. Il collegamento wireless IEEE Std 802.16-2001 opera con un BS centrale ed un’antenna settoriale che è capace di gestire simultaneamente settori indipendenti e multipli. All'interno di un determinato canale di frequenza e di un settore di antenna, tutte le stazioni ricevono la stessa trasmissione, o parte di essa. La stazione base è l'unico trasmettitore che opera in questa direzione, così trasmette senza doversi coordinare con le altre stazioni, e trasmette a tutte le stazioni nel settore; le stazioni controllano l'indirizzo nelle comunicazioni ricevute e trattengono solamente quelle indirizzate a loro.
Nell’altra direzione, la stazione di utente divide l’uplink verso la BS su una base di richiesta. La SS può trasmettere se possiede i diritti di trasmissione, altrimenti dovrà inviare una richiesta di diritto di trasmissione alla BS ed attendere che questa sia accettata.
Oltre alle comunicazioni individualmente indirizzate, si possono avere anche quelle inviate a tutte le stazioni su collegamenti multicast (le comunicazioni di controllo e la distribuzione video sono esempi di applicazioni multicast) o broadcast.
All'interno di ogni settore, gli utenti aderiscono ad un protocollo di trasmissione che controlla la loro contesa ed abilita il servizio adatto a soddisfare i requisiti di ritardo e di bandwidth di ogni loro applicazione. Questo è portato a termine attraverso quattro tipi diversi di meccanismi di pianificazione di uplink. Questi sono implementati usando concessioni di bandwidth non richieste, polling, e procedure di contesa. I meccanismi sono definiti nel protocollo per permettere ai costruttori di ottimizzare le prestazioni del sistema usando differenti combinazioni di queste tecniche di allocazione di banda, mantenendo costante le definizioni di interoperabilità.
L'uso del polling semplifica l'operazione di accesso e garantisce, se richiesto, che le applicazioni ricevano il servizio su una base deterministica. In generale, le applicazioni dati sono tolleranti al ritardo, ma le applicazioni in tempo reale come voce e video richiedono un servizio su una base più uniforme e qualche volta su una pianificazione rigorosamente controllata.
Il MAC è un collegamento orientato. Per gli scopi di progetto dei servizi sulle SS e di associazione dei diversi livelli di QoS, tutte le comunicazioni dati sono riferite ad un collegamento. Dopo la registrazione della SS, i collegamenti sono associati con i flussi di servizio (un collegamento per flusso di servizio). Un collegamento definisce le associazioni tra i processi di convergenza del peer che utilizza il MAC ed un flusso di servizio. Il flusso di servizio definisce i parametri di QoS per i PDU che sono scambiati sul collegamento.
Il concetto di un flusso di servizio su un collegamento è centrale per l'operazione del protocollo di MAC. I flussi di servizio offrono un meccanismo per la gestione del QoS nell’uplink e nel downlink. In particolare, sono integranti per il processo di allocazione di bandwidth.
2.3.2 Topologia Mesh (a maglia)
La principale differenza tra la topologia di rete PMP e quella opzionale Mesh è che nella prima il traffico avviene solo tra la BS e le SS, mentre nella seconda può essere instradato attraverso le altre SS e può avvenire direttamente tra le SS. A secondo dell’algoritmo di protocollo di trasmissione utilizzato, questa modalità di traffico potrà essere realizzata o sulla base di “uguaglianze” tra le stazioni quindi con una pianificazione distribuita oppure considerando la “superiorità” della BS e utilizzando così una pianificazione centralizzata o ancora usando una combinazione di entrambe.
All’interno di una rete Mesh, un sistema che ha una connessione diretta con l’esterno è detto Mesh BS mentre tutti gli altri sistemi sono chiamati Mesh SS; in generale tutti i sistemi sono detti nodi. Nel caso di una rete Mesh, l’uplink ed il downlink sono definiti rispettivamente come traffico nella direzione della Mesh BS e quello al di fuori da essa. Inoltre le stazioni con le quali un nodo ha collegamenti diretti sono detti “neighbor” (vicini), che formeranno un “neighborhood” (quartiere) e sono considerati a “1 hop” dal nodo. A “2 hop” si ha invece il cosiddetto “extended neighborhood” (quartiere esteso) che contiene anche tutti i vicini del quartiere.
In generale nel sistema Mesh nemmeno la BS può trasmettere senza coordinarsi con gli altri nodi. Usando quindi una pianificazione distribuita tutti i nodi, compresa la BS, coordineranno le loro trasmissioni all’interno del loro vicinato a “2 hop” e trasmetteranno le loro schede (risorse disponibili, richieste e grant) a tutti i loro vicini. Tuttavia opzionalmente le schede possono anche essere stabilite tra due nodi con richieste e grant non coordinate. Saranno i nodi che garantiranno che le trasmissioni risultanti non vadano a collidere con il traffico dati e con quello di controllo pianificato generato dagli altri nodi del quartiere a “2 hop”. Non c’è differenza nel meccanismo usato nel determinare le schede per il downlink e per l’uplink.
Nel caso di pianificazione centralizzata, le connessioni e la topologia di rete sono le stesse del caso precedente; ma in questo caso la Mesh BS accoglierà le richieste di risorse dalle SS dentro un certo range di hop, determinerà l’ammontare delle richieste accolte per ogni collegamento nella rete sia in UL che in DL e comunicherà questa informazione (grant) a tutte le SS dentro il range di hop. I messaggi grant non contengono l’attuale scheda; ma questa verrà calcolata da ciascun nodo utilizzando un algoritmo predeterminato con parametri dati.
Tipicamente i sistemi Mesh utilizzano antenne omnidirezionali o antenne dirigibili a 360°, ma possono essere utilizzate anche antenne di settore. Ai confini dell’area di copertura della rete Mesh, dove sono necessari collegamenti ad un solo punto, possono essere usate addirittura antenne estremamente direttive.
2.3.3 Definizione dei servizi MAC
Questo paragrafo definisce i servizi tra il MAC ed i CS; questi servizi sono iterazioni logiche definite mediante delle primitive, il cui scopo è di descrivere le informazioni che devono essere scambiate necessariamente tra il MAC ed i CS per abilitare un servizio.
Poiché ci sono più sottolivelli, noi divideremo le primitive riguardanti i servizi MAC offerti al CS superiore da quelle dei servizi offerti agli strati superiori esterni (non trattate nello Standard).
Di seguito si fa un elenco delle primitive supportate dal MAC 802.16 per i sistemi PMP: MAC_CREATE_CONNECTION.request MAC_CREATE_CONNECTION.indication MAC_CREATE_CONNECTION.response MAC_CREATE_CONNECTION.confirmation MAC_CHANGE_CONNECTION.request MAC_CHANGE_CONNECTION.indication MAC_CHANGE_CONNECTION.response MAC_CHANGE_CONNECTION.confirmation MAC_TERMINATE_CONNECTION.request MAC_TERMINATE_CONNECTION.indication MAC_TERMINATE_CONNECTION.response MAC_TERMINATE_CONNECTION.confirmation MAC_DATA.request MAC_DATA.indication
L'uso di queste primitive per fornire una comunicazione al peer è mostrato nella Figura 2.9. La richiesta iniziale di un servizio, effettuata da un strato inferiore, è stabilita dalla primitiva di “richiesta”. Questa richiesta è inviata attraverso l'interfaccia aria al peer del sottolivello di MAC, che genera una primitiva di “indicazione” per informare il peer CS della richiesta. L'entità di convergenza risponde con una “risposta” al MAC. Questa è rispedita attraverso l'interfaccia aria al MAC sul lato che richiede, che invia una primitiva di “conferma” all'entità che ha effettuato, inizialmente, la richiesta del servizio.
In alcuni casi, non è necessario spedire informazioni alla stazione peer e la primitiva di “conferma” è emessa direttamente dal MAC sul lato che richiede. Questi casi possono accadere, per esempio, quando la richiesta è rifiutata dal MAC sul lato che richiede. Nei casi dove è necessario tenere informato l'altro lato del collegamento, può essere inviata una “risposta” non richiesta, che porta alla generazione di una “conferma” non richiesta a beneficio del CS.
Per le azioni di DATA.request e di DATA.indication, il CS richiedente invia una primitiva di REQUEST al suo sottolivello di MAC. Il sottolivello di MAC del lato richiedente invia l’adatta comunicazione di richiesta di servizio dinamica (aggiunta, cambio, o cancellatura) al MAC ricevente. Il lato MAC non richiedente invia una primitiva di INDICATION al suo CS. Il CS non richiedente risponde con una primitiva di RESPONSE, stimolando il suo MAC a rispondere al lato MAC richiedente con l’adatta comunicazione di Risposta di Servizio Dinamica. Il lato MAC richiedente risponde al suo CS con una primitiva di CONFIRMATION e, se è adatta, con l’adatta comunicazione di servizio dinamico di riconoscimento. In ogni punto lungo il percorso, la richiesta può essere rifiutata (per mancanza di risorse, ecc.), terminando il protocollo.
Di seguito vengono descritte l'interazioni logiche tra le primitive di Servizio MAC e le comunicazioni di servizio dinamico di aggiunta, di cambio, o di cancellatura (DSx).
La sequenza degli eventi logici del MAC SAP e gli eventi MAC associati che effettuano una creazione di collegamento di CS sono mostrati in Figura 2.10.
Figura 2.10
La sequenza degli eventi logici del MAC SAP e gli eventi MAC associati che effettuano un cambio di collegamento di CS sono mostrati in Figura 2.11.
Figura 2.11
La sequenza degli eventi logici del MAC SAP e gli eventi MAC associati che effettuano una cancellazione di collegamento di CS sono mostrati in Figura 2.12.
Figura 2.12
Vediamo ora quali sono le primitive supportate dal MAC 802.16 per i sistemi Mesh:
MAC_CREATE_CONNECTION.indication MAC_CHANGE_CONNECTION.indication MAC_TERMINATE_CONNECTION.request MAC_TERMINATE_CONNECTION.indication MAC_DATA.request MAC_DATA.indication MAC_FORWARDING_UPDATE.request MAC_FORWARDING_UPDATE.indication
Nei sistemi Mesh nessuna azione porta all’invio da parte del CS del lato iniziale di una primitiva di REQUEST al suo sottolivello MAC. Queste sono tutte indicazioni di risultati provenienti dai processi gestiti dall’entità MAC CPS, o azioni di consegna dati che necessitano lo scambio d’informazioni con il CS peer.
2.3.4 Progetto dei dati e del controllo
In questo paragrafo viene descritto come si identificano le BS e le SS e i loro collegamenti, il formato dei dati ed il tipo di informazioni che vengono scambiate, e la costruzione e la trasmissione dei MAC PDU.
2.3.4.1 Indirizzamento e collegamenti
Sistemi PMP:
Ogni SS avrà un indirizzo MAC universale di 48 bits. Questo indirizzo definisce unicamente la SS all'interno dell’elenco di tutti i possibili costrutori e di tutti i tipi di attrezzature. Si usa durante il processo di ranging iniziale per stabilire i collegamenti adatti per una SS. Si usa anche come parte del processo di autenticazione in cui ogni BS e SS verifica l'identità dell'altra.
I collegamenti sono identificati da un identificatore di collegamento (CID) di 16 bits. Durante l’inizializzazione della SS, vengono stabiliti tra la SS e la BS tre collegamenti di gestione in ogni direzione (uplink e downlink). Questi CID vengono assegnati attraverso le comunicazioni RNG-RSP e REG-RNG-RSP e riflettono il fatto che tra una SS e la BS ci sono tre QoS diversi di traffico di gestione. Il collegamento di base è usato dal MAC della BS e da quello della SS per scambiare comunicazioni di gestione MAC corte e urgenti. Il collegamento di gestione primario invece è usato per scambiare comunicazioni di gestione MAC più lunghe e molto tolleranti al ritardo. La Tabella 2.5 specifica quali Comunicazioni di gestione MAC vengono trasferite su questi due collegamenti. Infine, si ha il collegamento di Gestione Secondario che viene usato dalle BS e dalle SS per trasferire comunicazioni di gestione standard di base, tolleranti al ritardo, come DHCP, TFTP, SNMP, ecc. Queste comunicazioni sono trasportate in pacchetti IP, che saranno assegnati al collegamento di gestione secondario utilizzando il completo indirizzo IP della sorgente nell'uplink ed il completo indirizzo IP del destinatario nel downlink.
Sistemi Mesh:
Come per le SS nei sistemi PMP, ciascun nodo avrà un indirizzo MAC universale a 48 bit che definisce univocamente il nodo e sarà usato durante il processo di ingresso nella rete come parte del processo di autorizzazione attraverso il quale il nodo candidato e la rete verificano l’identità di ogni altro nodo.
Una volta autorizzato, il nodo riceverà, su richiesta, dalla Mesh BS un identificatore di nodo (Node ID) di 16 bit usato durante le normali operazioni. Il Node ID è trasferito nel Mesh subheader, che segue il Generic MAC header, sia nelle comunicazioni unicast che in quelle broadcast.
Per ogni collegamento con un nodo del quartiere, saranno usati degli identificatori di collegamento di 8 bit (Link ID). Ogni nodo comunica durante il processo di istaurazione del collegamento il Link ID al nuovo nodo vicino. Questo Link ID è trasmesso come parte del CID nel generico MAC header nei messaggi unicast e sarà usato nella pianificazione distribuita per identificare le richieste e i grant di risorse; dato che questi messaggi sono broadcast, i nodi riceventi saranno in grado di
identificare la scheda sia attraverso il Node ID del nodo trasmittente nel Mesh subheader che attraverso il link ID nel MSH-DSCH payload.
2.3.4.2 Formati del PDU MAC
Il Protocollo di Unità Dati (MAC PDU) avrà la forma illustrata nella Figura 2.13; comincerà con un header MAC generico a lunghezza fissata, seguito, se presente, dal payload, il quale sarà formato da più subheaders e più MAC SDU interi e/o frammentati. Le informazioni del payload possono variare in lunghezza, così che un MAC PDU può rappresentare un numero variabile di bytes. Questo permette al MAC di incanalare i vari tipi di traffico di strato superiore senza la conoscenza delle configurazioni delle comunicazioni.
Figura 2.13
Lo Standard definisce due configurazioni dell’header MAC. Il primo è l’Header Generico MAC che comincia ogni MAC PDU contenente o le comunicazioni di gestione MAC o i dati CS. Il secondo è l’Header di Richiesta di Banda usato per richiedere una aggiunta di bandwidth. Le due configurazioni vengono distinte dal campo Tipo di Header (HT) , un singolo bit che settato zero indica l’Header MAC Generico; settato uno, quello di Richiesta di Banda.
L’Header MAC Generico è illustrata nella Figura 2.14, mentre i suoi campi sono definiti nella Tabella 2.1.
Nome Lunghezza (bits) Descrizione CI 1 Indicatore CRC 1 = CRC applicato al PDU 0 = CRC non applicato
CID 16 Identificatore del collegamento
EC 1 Controllo di codifica
0 = Payload non codificato 1 = Payload codificato
EKS 2 Sequenza di Codice di Codifica
HCS 8 Sequenza di Controllo dell’Header
HT 1 Tipo dell’Header = 0
LEN 11 Lunghezza in bytes del MAC PDU incluso l’header Type 6 Indica il tipo di Payload, includendo la presenza di subheaders
Tabella 2.1
I valori permessi per il campo Type sono elencati nella Tabella 2.2.
Type bit Descrizione
#5 (msb) Mesh Subheader
1 = presente, 0 = assente
#4 ARQ Feedback Payload
1 = presente, 0 = assente
#3 Extended Type
1 0 esteso, 0 = non esteso
Indica se i presenti subheaders di compressione o di frammentazione sono estesi
#2 Subheader di Frammentazione
1 = presente, 0 = assente
#1 Subheader di Compressione
1 = presente, 0 = assente #0 (lsb) Subheader di Gestione di Concessioni
1 = presente, 0 = assente
Sarà settato 0 nel DownLink Tabella 2.2
L’Header di Richiesta di Banda, illustrato in Figura 2.15, viene usato nei PDU per la richiesta di concessione di banda; non è seguito da payload. I campi di questo Header sono definiti nella Tabella 2.3.
Nome Lunghezza (bits)
Descrizione
BR 16 Richiesta di Banda
Numero di bytes di Banda di uplink richiesti dalla SS
CID 16 Identificatore del collegamento
EC 1 Sempre settato a zero
HCS 8 Sequenza di Controllo dell’Header
HT 1 Tipo dell’Header = 1
Type 6 Indica il tipo di header di richiesta di banda
Tabella 2.3
All’interno del MAC PDU, nel payload, si possono presentare quattro tipi di subheaders MAC; il subheader di Frammentazione, quello di Compressione, quello di Gestione della Concessione, e quello Mesh. Il subheader di Frammentazione (FSH) viene utilizzato quando i MAC SDU sono frammentati. Il subheader di Gestione della Concessione (GM) viene utilizzato dalla SS per comunicare alla BS il bisogno di gestione di bandwidth. Il subheader di Compressione viene utilizzato quando il MAC comprime gli SDU multipli in un solo MAC PDU; ogni MAC SDU sarà preceduto da un subheader di compressione. Il subheader Mesh viene utilizzato nei sistemi Mesh, segue il Generic MAC Header e precede gli eventuali altri subheaders.
Vediamo ora quali sono le comunicazioni che saranno portate nel payload dei MAC PDU. La configurazione di una generica Comunicazione di Gestione è mostrata nella Figura 2.16; questa è individuata dal campo Tipo ed è associata ad uno specifico collegamento, come mostrato nella Tabella 2.4.
Figura 2.16
Tipo Nome della
comunicazione
Descrizione della comunicazione Collegamento
0 UCD Descrittore del canale di uplink Broadcast
1 DCD Descrittore del canale di downlink Broadcast
2 DL-MAP Definizione degli accessi di uplink Broadcast
3 UL-MAP Definizione degli accessi di downlink Broadcast
4 RNG-REQ Richiesta di Ranging Ranging Iniziale o
Base
5 RNG-RSP Risposta di Ranging Ranging Iniziale o
Base
6 REG-REQ Richiesta di Registrazione Gestione Primaria
7 REG-RSP Risposta di Registrazione Gestione Primaria
8 Riservato per usi futuri
9 PKM-REQ Richiesta di Gestione della chiave di Privacy Gestione Primaria 10 PKM-RSP Risposta di Gestione della chiave di Privacy Gestione Primaria
11 DSA-REQ Richiesta di Aggiunta di Servizio Dinamico Gestione Primaria
12 DSA-RSP Risposta di Aggiunta di Servizio Dinamico Gestione Primaria
13 DSA-ACK Ricevuta di Aggiunta di Servizio Dinamico Gestione Primaria
14 DSC-REQ Richiesta di Cambi di Servizio Dinamico Gestione Primaria
15 DSC-RSP Risposta di Cambi di Servizio Dinamico Gestione Primaria
16 DSC-ACK Ricevuta di Cambi di Servizio Dinamico Gestione Primaria
17 DSD-REQ Richiesta di Cancellazione di Servizio Dinamico Gestione Primaria 18 DSD-RSP Risposta di Cancellazione di Servizio Dinamico Gestione Primaria
Tipo Nome della comunicazione
Descrizione della comunicazione Collegamento
20 Riservato per usi futuri
21 MCA-REQ Richiesta di Assegnamento Multicast Base
22 MCA-RSP Risposta di Assegnamento Multicast Base
23 DBPC-REQ Richiesta di cambio del profilo del burst di downlink Base 24 DBPC-RSP Risposta di cambio del profilo del burst di downlink Base
25 RES-CMD Comando di Reset Base
26 SBC-REQ Richiesta della Capacità base della SS Base
27 SBC-RSP Risposta della Capacità base della SS Base
28 CLK-CMP Segnale di clock di rete Broadcast
29 DREG-CMD Comando De/Re-register Base
30 DSX-RVD Comunicazione di DSx ricevuto Gestione Primaria
31 TFTP-CPLT Comunicazione di configurazione del File TFTP completo
Gestione Primaria
32 TFTP-RSP Risposta di configurazione del File TFTP completo Gestione Primaria
33 ARQ-Feedback Atandalone ARQ Feedback Base
34 ARQ-Discard Comunicazione di scarto ARQ Base
35 ARQ-Reset Comunicazione di azzeramento ARQ Base
36 REP-REQ Richiesta Rapporto Misurazioni di Canale Base
37 REP-RSP Risposta Rapporto Misurazioni di Canale Base
39 MSH-NCFG Configurazione rete Mesh Broadcast
40 MSH-NENT Entrata rete Mesh Base
41 MSH-DSCH Pianificazione Mesh Distribuita Broadcast
42 MSH-CSCH Pianificazione Mesh Centralizzata Broadcast
43 MSH-CSCF Configurazione Pianificazione Mesh Centralizzata Broadcast
44 AAS-FBCK-REQ Richiesta AAS Feedback Base
45 AAS-FBCK-RSP Risposta AAS Feedback Base
38, 46-255
Riservati per usi futuri
Tabella 2.4
Le Comunicazioni di Gestione MAC sui collegamenti di Base, Broadcast , e di Ranging Iniziale non saranno né frammentate né compresse; mentre quelle sul Collegamento di Gestione Primario potranno essere compresse e/o frammentate. Le Comunicazioni di Gestione MAC che non contengono tutti i parametri richiesti o che contengono dei parametri codificati erroneamente, saranno scartate silenziosamente.
Di seguito verrà fatta una veloce descrizione delle varie comunicazioni.
Le comunicazioni Descrittore di Canale di Uplink (UCD) e Descrittore di Canale di Downlink (DCD) vengono emesse dalla BS ad intervalli di tempo periodici per definire le caratteristiche del canale di uplink la prima, di downlink la seconda.
La comunicazione DL-MAP definisce l’accesso alle informazioni di downlink, mentre quella UL-MAP distribuisce l’accesso al canale di uplink.
La comunicazione di Richiesta di Ranging (RNG-REQ) sarà emessa dalla SS durante l’inizializzazione e periodicamente su richiesta della BS per determinare il ritardo di rete e per richiedere potenza e/o per cambiare il profilo del burst di downlink. In risposta a questa comunicazione la BS emetterà una Risposta di Ranging (RNG-RSP) per inviare le correzioni basate su misurazioni che sono state fatte su altri dati ricevuti o su comunicazioni di MAC.
Sempre durante l’inizializzazione, la comunicazione di Richiesta di Registrazione (REG-REQ) sarà emessa da una SS per registrarsi ad una BS, la quale risponderà con una comunicazione di Risposta di Registrazione (REG-RSP).
Poi si hanno le comunicazioni della Gestione della Chiave di Privacy (PKM), che possono assumere due tipi di comunicazioni MAC, la Richiesta di PKM (PKM-REQ) emessa dalla SS verso la BS, e la Risposta di PKM (PKM-RSP) emessa dalla BS alla SS. All’interno di queste comunicazioni c’è un Codice, una parola di 8 bits, che identifica il tipo del pacchetto PKM; i valori del Codice sono definiti nella Tabella 2.5. Quando un pacchetto è ricevuto con un Codice non valido, sarà scartato silenziosamente.
Codice Tipo di comunicazione PKM Nome della comunicazione di gestione MAC
0-2 riservato -
3 SA Add PKM-RSP
4 Auth Request PKM-REQ
5 Auth Reply PKM-RSP
6 Auth Reject PKM-RSP
7 Key Request PKM-REQ
8 Key Reply PKM-RSP
9 Key Reject PKM-RSP
10 Auth Invalid PKM-RSP
11 TEK Invalid PKM-RSP
12 Authent Info PKM-REQ
13-255 riservato -
Tabella 2.5
Quindi si hanno le comunicazioni di Servizio Dinamico (DSx), queste possono essere di tre tipo: di Aggiunta (DSA), di Cambio (DSC), e di Cancellazione (DSD). Le comunicazioni di Richiesta di DSx (DSx-REQ) saranno inviate dalle SS alle BS, le quali risponderanno con le comunicazioni di Risposta di DSx (DSx-RSP). Quando una SS riceve una risposta ad una sua comunicazione DSA o DSC, emettera una comunicazione di Ricevuta di DSx (DSx-ACK).
Ancora, la comunicazione di Richiesta di Assegnamento ad un Multicast Polling (MCA-REQ), che sarà spedita ad una SS per assegnarla o rimuoverla da un gruppo multicast polling. La SS risponderà con una comunicazione di Risposta di MCA (MCA-RSP).
La comunicazione di Richiesta di Cambio del Profilo del Burst di Downlink (DBPC-REQ), che viene inviata dalla SS alla BS sul suo CID di Base per richiedere un cambio del profilo del burst di downlink usato dalla BS per trasportare dati alla SS. La BS risponderà, sempre sul CID di Base della SS, con una comunicazione di Risposta DBPC (DBPC-RSP).
La comunicazione Reset Command (RES-CMD) sarà trasmessa dalla BS sul CID di Base di una SS per costringere la SS a resettarsi, rinizializzare il suo MAC, e ripetere l’accesso di sistema iniziale. Questa comunicazione si può usare se una SS è inerte alla BS o se la BS determina anomalie continue nella trasmissione di uplink dalla SS.
La comunicazione di Richiesta della Capacità di Base della SS (SBC-REQ), trasmessa dalla SS durante l’inizializzazione; quindi la comunicazione di Risposta della Capacità di Base della SS (SBC-RSP), trasmessa dalla BS in risposta ad una SBC-REQ ricevuta.
La comunicazione Clock Comparison (CLK-CMP), diffusa dalla BS periodicamente nei sistemi di rete in cui le SS ricostruiscono i loro segnali di sincronizzazione di tempo.
La Comunicazione De/Re-register Command (DREG-CMD) che sarà trasmessa dalla BS sul CID di Base di una SS per costringere la SS a cambiare il suo stato di accesso. Al ricevimento di un DREG-CMD, la SS incomincerà l’azione indicata dal codice di azione.
La comunicazione DSx Received (DSX-RVD) sarà generata dalla BS in risposta ad una SS-initiated DSx-REQ per informare la SS che la BS ha ricevuta la comunicazione DSx-REQ nella maniera più opportuna prevista e che la comunicazione DSx-RSP sarà trasmessa soltanto dopo che la DSx-REQ sarà stata autenticata.
La comunicazione Config File TFTP Complete (TFTP-CPLT) sarà generata dalla SS quando avrà recuperato con successo il suo file di configurazione dal sistema di server di approvvigionamento. La BS risponderà con una comunicazione Config File TFTP Complete Response (TFTP-RSP).
La comunicazione ARQ feedback viene utilizzata dai sistemi che supportano l’ARQ per segnalare le diverse combinazioni degli ARQ ACK (cumulativi, selettivi o selettivi con cumulazione). La comunicazione ARQ Discard, applicabile solo ai collegamenti in cui è abilitato l’ARQ, serve per ignorare un certo numero di frammenti ARQ; mentre per azzerare l’ARQ viene usata la comunicazione ARQ Reset.
Le comunicazioni Channel measurement Report Request/Response (REP-REQ/RSP) vengono utilizzate dalle BS quando si lavora nel range di frequenza al di sotto degli 11 GHz per richiedere le misure del RSSI e del CINR del canale.
Le comunicazioni MSH-x vengono utilizzate nelle reti con topologia Mesh. La comunicazione MSH-NCFG serve a configurare la rete offrendo un livello base per la comunicazione tra nodi di reti vicine indipendentemente da quale operatore wireless appartengono. La comunicazione MSH-NENT viene usata per offrire i sincronismi ad un nuovo nodo che entra a fare parte della rete Mesh. La comunicazione MSH-DSCH viene utilizzata nei sistemi Mesh con pianificazione distribuita; se i nodi sono coordinati, invieranno ad intervalli regolari delle MSH-DSCH per informare il quartiere dei loro tempi di trasmissione; sia nel caso coordinato che no, queste comunicazioni saranno utilizzate per portare le richieste di risorse e i grants ai vicini. La comunicazione MSH-CSCH, invece, viene creata nei sistemi Mesh con pianificazione centralizzata dalla Mesh BS, che la invia a tutti i suoi vicini. I nodi utilizzeranno queste comunicazioni per la richiesta di larghezza di banda. Per la configurazione della rete Mesh con pianificazione centralizzata viene usata la comunicazione MSH-CSCF inviata dalla Mesh BS ai nodi vicini, i quali la inoltreranno in modo da coprire tutta la rete.
Le comunicazioni AAS Channel Feedback (AAS-FBCK-REQ/RSP) saranno utilizzate nei sistemi che supportano l’AAS ed operano in modalità FDD e servono per richiedere misure di canale che aiutano nella correzione della direzione degli array di antenne adattativi.
2.3.4.3 Costruzione e trasmissione dei MAC PDU
Figura 2.17
La trasmissione dei MAC PDU è una trasmissione ordinata, verrà inviato per primo sempre il byte più significativo; e per ogni byte, prima il bit più significativo. Per la trasmissione possono essere usate delle varie tecniche come la concatenazione, la frammentazione, e la compressione; descritte di seguito.
La concatenazione consiste nell’inviare MAC PDU multipli in una sola trasmissione, questa può essere applicata sia nella direzione di uplink che in quella di downlink. La Figura 2.18 illustra questo concetto per una trasmissione a burst di uplink. Siccome ogni MAC PDU è identificato da un unico CID, l'entità MAC ricevente è in grado di presentare il MAC SDU (dopo averlo radunato da uno o da più MAC PDU ricevuti) al MAC SAP richiedente. Le comunicazioni di Gestione, i dati
di utente, e la richiesta di bandwidth dei MAC PDU possono essere concatenate nella stessa trasmissione.
Figura 2.18
La frammentazione consiste nel dividere un MAC SDU in uno o più MAC PDU. Questo processo viene applicato per permettere un uso efficiente della disponibilità della banda relativa ai requisiti di QoS del flusso di servizio di un collegamento.
La frammentazione può essere avviata da una BS per un collegamento di downlink, e da una SS per un collegamento di uplink. I frammenti sono etichettati come mostrato nella Tabella 2.6.
Frammento FC Primo frammento 10 Frammento di continuazione 11 Ultimo frammento 01 Non frammentato 00 Tabella 2.6
Mediante il numero di sequenza, la SS è ingrado di ricreare il payload originale ed eventualmente di individuare la perdita di alcuni pacchetti intermedi. Inseguito ad una perdita, la SS scarterà ogni MAC PDU ricevuto sul collegamento finché non viene individuato un nuovo primo frammento o un MAC PDU non frammentato.
La costruzione dei PDU, quando viene usata la compressione, varia in base al collegamento, dipendendo dal supporto o meno del meccanismo ARQ. Se il collegamento è non-ARQ si possono utilizzare due tipi di compressione in pacchetti a lunghezza fissata o variabile.
Quando si utilizza la compressione in pacchetti a lunghezza fissata, il MAC emittente comunica mediante una DSA-REQ la dimensione del SDU, mentre nell’header vi sarà un campo che indica implicitamente il numero dei MAC SDU compressi. Se la dimensione del MAC SDU è di n bytes, il lato ricevente può decomprimere semplicemente conoscendo che il campo di lunghezza nell’header MAC sarà n∗k+ j, dove k è il numero dei MAC SDU compressi nel MAC PDU e j è la dimensione dell’header MAC sommata a quella di ogni subheaders MAC presente nel MAC PDU. Un MAC PDU contenente una sequenza compressa a lunghezza fissata di MAC SDU sarà costruito come in Figura 2.19.
Invece, quando i collegamenti MAC SDU sono compressi a lunghezza variabile, come per l’Ethernet, la relazione n∗k+ j tra il campo di lunghezza dell’header MAC e i MAC SDU del livello superiore non è più valida. Questo rende necessario l’indicazione del punto in cui un MAC SDU finisce e ne comincia un altro. Nel caso di MAC SDU a lunghezza variabile, il MAC lega un subheader di Compressione (PSH) ad ogni MAC SDU. Questo subheader è descritto nel 2.3.4.2.
Un MAC PDU che contiene una sequenza impacchettata di MAC SDU a lunghezza variabile è costruito come mostrato in Figura 2.20. Se più di un MAC SDU è compresso nel MAC PDU, il campo Tipo nell’header MAC indica la presenza di subheaders di Compressione. Da notare che MAC SDU non frammentati e MAC SDU frammentati possono entrambe essere presenti nello stesso MAC PDU, come descritto sotto.
Figura 2.20
Se in un MAC PDU è presente solamente un MAC SDU (o un frammento di esso), il campo Tipo nell’header MAC indica l'assenza di subheaders di Compressione. Questo è mostrato in Figura 2.21.
Figura 2.21
La compressione dei subheaders per un collegamento con ARQ abilitato è simile a quella descritta sopra per uno non-ARQ, eccetto per il fatto che non può utilizzare la compressione a lunghezza fissa. Quando per il collegamento è abilitata la compressione, il MAC può comprimere i MAC SDU multipli in un solo MAC PDU.
Il lato trasmettitore ha la piena discrezione nel comprimere un gruppo di MAC SDU e/o frammentarli in un solo MAC PDU. A secondo della tecnica di ARQ, il trasmettitore può scegliere di comprimere frammenti multipli dello stesso SDU in un solo MAC PDU, anche se c’è bandwidth sufficiente per spedire il MAC PDU intero senza frammentazione. Questa caratteristica può essere utilizzata dal protocollo ARQ per permettere una maggiore flessibilità nella ritrasmissione.
La compressione dei MAC SDU per i collegamenti con ARQ abilitato è simile a quello dei collegamenti non-ARQ, quando è abilitata la frammentazione. Il FSN del Subheader di compressione sarà usato dal protocollo ARQ per identificare e ritrasmettere i frammenti perduti. La differenza primaria tra la compressione ARQ e non-ARQ è nell’iterazione con la frammentazione.
Per i collegamenti con ARQ abilitato, quando il campo type indica l’utilizzo di subheaders di compressione, informazioni di frammentazione per ogni MAC SDU individuale o per ogni frammento MAC SDU saranno contenute nel subheaders di compressione associato. Quando il campo type indica che la compressione non è utilizzata, le informazioni di frammentazione per il singolo payload MAC PDU (MAC SDU o frammento MAC SDU) saranno contenute nel header di frammentazione che appare nella comunicazione. La Figura 2.22 illustra l'uso di subheader di Frammentazione senza compressione.
Generic MAC Header Altri subheaders Subheader di frammentazione
Payload (un SDU o un frammento di SDU)
CRC-32
Figura 2.22
La Figura 2.23 illustra la struttura di un MAC PDU con subheader di compressione ARQ. Ogni MAC SDU compresso, o frammento di MAC SDU, o payload di feedback ARQ richiede il proprio subheader di compressione e potranno essere trasmissioni o ritrasmissioni.
Generic MAC Header Subheader di Gestione di Concessione (solo UL) Subheader di compressione
Payload (un SDU o un frammento SDU o un set di ARQ feedback IE) … Subheader di compressione
Payload (un SDU o un frammento SDU)
CRC-32
Figura 2.23
Diversamente dal caso non-ARQ, è possibile, per varie ragioni, avere frammenti di continuazione compressi con gli altri frammenti nello stesso MAC PDU. Per esempio per supportare una ritrasmissione flessibile, il meccanismo di ARQ può scegliere di frammentare un MAC SDU in frammenti multipli e comprimerli nello stesso MAC PDU durante la prima trasmissione. Analogamente un MAC PDU può avere frammenti di diversi SDU, includendo sia prime trasmissioni che ritrasmissioni.
2.3.5 Meccanismo ARQ
Il meccanismo ARQ è una parte opzionale dello strato MAC e può essere abilitato su una base di per-collegamento. Il per-collegamento ARQ e i parametri associati saranno specificati e saranno negoziati durante l’istaurazione o il cambio di un collegamento. Un collegamento non può avere un traffico misto ARQ e non-ARQ.
Le informazioni dell’ARQ feedback possono essere inviate con una comunicazione standalone di gestione del MAC su un appropriato collegamento di gestione di base, e non possono essere frammentate. La realizzazione ARQ è opzionale e non sarà usata con la specifica del PHY WirelessMAN-SC definita in 3.1.
2.3.6 Pianificazione dei Servizi di Uplink
I Servizi di pianificazione sono progettati per migliorare l'efficienza del processo di poll/grant. Specificando un servizio di pianificazione ed i suoi parametri di QoS associati, la BS può migliorare la produttività e ridurre i ritardi necessari per il traffico dell'uplink e fornire polls e/o concessioni ad istanti esatti.
I servizi di base sono l’Unsolicited Grant Service (UGS), il Real-Time Polling Service (rtPS), il Non-Real-Time Polling Service (nrtPS) ed il servizio Best Effort (BE). Ogni servizio è fatto su misura per uno specifico tipo di flusso di dati. I paragrafi seguenti definiscono i servizi di pianificazione del flusso di servizio di uplink di base ed elencano i parametri di QoS associati con ogni servizio.
L’Unsolicited Grant Service (UGS) è progettato per sostenere flussi di servizio in tempo reale che generano periodicamente pacchetti di dati di dimensione fissa. Il servizio offre periodicamente ed in tempo reale concessioni di dimensione fissa, che eliminano l'overhead ed i ritardi delle richieste della SS ed assicurano che le concessioni siano disponibili per soddisfare in tempo reale le necessità del flusso. La BS offrirà Data Grant Burst Types di dimensione fissa al flusso di servizio ad intervalli periodici.
Il Real-Time Polling Service (rtPS) è disegnato per sostenere flussi di servizio in tempo reale che generano periodicamente pacchetti di dati di dimensioni variabili, come video MPEG. Il servizio offre periodicamente ed in tempo reale l’opportunità di richiesta unicast che soddisfi le necessità del flusso in tempo reale e permetta alla SS di specificare la dimensione della concessione desiderata. Questo servizio richiede un overhead maggiore di quello UGS, ma supporta dimensioni di concessioni variabili che rendono efficiente il trasporto di dati.
Il Non-Real-Time Polling Service (nrtPS) è progettato per sostenere flussi di servizio non in tempo reale che richiedono Data Grant Burst Types di dimensione variabile a tempi regolari, come per un FTP a grande bandwidth. Il servizio offre a tempi regolari le ricezioni unicast assicurando che il flusso riceva le opportunità di richiesta anche durante la congestione di rete. La BS riceve tipicamente i CID nrtPS su un intervallo (periodico o non periodico) dell’ordine di un secondo o meno.
Il servizio Best Effort (BE) ha l'intenzione di offrire un servizio efficiente al traffico che compie un maggiore sforzo.
2.3.7 Meccanismi di allocazione e di richiesta di Banda
Durante l’entrata nella rete e l’inizializzazione di ogni SS vengono assegnati tre CID dedicati al fine di inviare e ricevere comunicazioni di controllo. I tre collegamenti sono usati per permettere a livelli differenti di QoS di essere applicati ai diversi collegamenti che portano il traffico di gestione MAC. Per qualsiasi servizio, escluso i collegamenti UGS a bit rate costante incomprimibili, la necessità di banda tra l’istaurazione e la terminazione del collegamento può variare, può essere necessario incrementare (o decrementare) i requisiti di banda.
Ci sono due meccanismi per allocare la banda: il modo Grant per Connection (GPC) e il modo Grant per Subscriber Station (GPSS). Nel primo caso, la BS accorda esplicitamente la bandwidth ad ogni collegamento, quindi ad un CID individuale, mentre nel secondo caso la bandwidth è accordato a tutti i collegamenti che appartengono alla SS, quindi al suo CID di Base. Il secondo caso (GPSS) permette progetti di uplink più piccoli e permette alle SS una maggiore intelligenza nel prendere decisioni all’ultimo momento e quindi di utilizzare differentemente la banda che originalmente era stata accordata dalla BS. Questo può essere utile per applicazioni tempo reali che richiedono al sistema una risposta più veloce.
I sistemi che utilizzano la specifica di PHY “WirelessMAN-SC” per i 10–66 GHz, descritti in 3.1, useranno il modo GPSS.
La richieste di Banda può essere incrementale o complessiva. Quando la BS riceve una richieste di Banda incrementale, aggiungerà la quantità di banda richiesta alla sua attuale stima di necessità di banda del collegamento. Quando la BS riceve una richieste di Banda complessiva, sostituirà la sua stima di necessità di banda del collegamento con la quantità di banda richiesta. Il tipo di richiesta, incrementale o complessiva, è indicato nell’Header della Richiesta di Banda. Le SS useranno periodicamente richieste complessive in modo da correggere gli errori di incrementazione.
2.3.8 Supporto opzionale della topologia Mesh
Il supporto della topologia Mesh è opzionale. Diversamente dal modo PMP, nel modo Mesh ogni stazione è capace di creare collegamenti di comunicazione dirette con più stazioni della rete invece di comunicare solamente con la BS. Comunque, quando si usa la pianificazione centralizzata Mesh (descritta sotto), ci saranno ancora dei nodi che effettuano le funzioni base svolte dalla BS nel modo PMP, tipo i collegamenti di backhaul. Quindi, la differenza chiave è quella che nel modo Mesh tutte le SS possono avere collegamenti diretti con altre SS; inoltre, non c’è bisogno di avere un collegamento diretto tra una SS e la BS della rete Mesh: queste due stazioni possono comunicare attraverso le altre SS. Le comunicazioni in tutti questi collegamenti saranno controllate da un algoritmo centralizzato (o dalla BS o decentralizzando periodicamente tutti i nodi), programmato in una maniera distribuita all'interno di ogni nodo del quartiere esteso, o usando una combinazione programmata di questi.
2.3.8.1 Pianificazione distribuita
Le stazioni che hanno collegamenti diretti sono chiamate vicini e formano un quartiere. Un vicino di nodo è considerato ad “1 hop” dal nodo. Mentre un quartiere esteso a “2 hop” contiene tutti i vicini del quartiere.
Nel modo con pianificazione distribuita e coordinata, ogni stazione (BS e SS) coordinerà le proprie trasmissioni all’interno del proprio quartiere esteso a “2 hop”; ed utilizzerà la parte di controllo di ogni trama per trasmettere e per proporre un cambio del proprio programma a tutti i suoi vicini su una base PMP. All'interno di un canale determinato, tutte le stazioni vicine ricevono le stesse trasmissioni di programmi.
La pianificazione distribuita e coordinata assicura che le trasmissioni sono programmate in modo che non si conti sull’operazione di una BS, e che non sia necessario un collegamento diretto alla BS.
All'interno delle costrizioni dei programmi coordinati (distribuiti o centralizzati), per velocizzare una trasmissione può essere usata una pianificazione distribuita e senza coordinazione; questi programmi distribuiti non coordinati saranno stabiliti da richieste e concessioni dirette tra due nodi, e saranno programmati per assicurare che le trasmissioni dati risultanti (e la richiesta e la concessione dei loro pacchetti) non provochi collisioni con i dati e con il traffico di controllo programmato dal metodo di pianificazione distribuita coordinato, e da quello centralizzato coordinato.
Per l’impiego di una pianificazione distribuita sia coordinata che no, è prevista una comunicazione a 3 vie:
• Mediante un MSH-DSCH viene fatta una richiesta di disponibilità che indica il programma attuale e i potenziali slots per repliche.
• In risposta viene spedita la concessione indicando, se possibile, un sottoinsieme di suggerimenti di disponibilità che adattano la richiesta.
• La concessione viene inviata dal richiedente originale contenente una copia del grant dell’altro partner per confermare il programma all’altro partner e per informare i vicini di questo nodo non convolti in questo programma dell’avvenuto accordo.
Le differenze tra la pianificazione distribuita coordinata e quella senza coordinazione è che nella prima le comunicazioni MSH-DSCH sono elencate nel subframe di controllo evitando le collisioni; mentre nella seconda le comunicazioni di MSH-DSCH possono collidere, e i nodi che ricevono una richiesta devono aspettare un numero sufficiente di minislots, indicato nella disponibilità, prima di rispondere con una concessione, in modo che i nodi programmati ad effettuare la richiesta per primi abbiano per primi una opportunità di rispondere. Il Grant di conferma è inviato nel minislots che segue immediatamente il primo ricevimento di un pacchetto di Grant associato riuscito.
2.3.8.2 Pianificazione centralizzata
I collegamenti di rete e la topologia per programmi con pianificazione centralizzata sono gli stessi di quelli con pianificazione distribuita descritta nel 2.3.8.1, ma i programmi delle trasmissioni delle SS sono definiti dalla BS mediante l’assegnamento alle SS di flussi di richieste di risorse. Di conseguenza, le SS determinano il programma attuale da questi assegnamenti di flusso usando un algoritmo comune che divide proporzionalmente la trama per gli assegnamenti. In questo modo, la BS agisce come in una rete PMP eccetto per il fatto che non tutte le SS devono essere connesse direttamente alla BS, e gli assegnamenti determinati dalla BS riguardano anche le SS che non sono connesse direttamente alla BS. Le richieste di risorse delle SS e gli assegnamenti della BS sono entrambe trasmessi durante la parte di controllo della trama.
La pianificazione centralizzata assicura che le trasmissioni siano coordinate per assicurare che non si verifichino collisioni sui collegamenti per e dalla BS nell'albero di instradamento.
2.3.9 PHY sostenuti dal MAC
Il protocollo MAC può sostenere più tecniche di duplexing; la scelta di questa ultima può influire sui parametri del PHY, imprimendo così le caratteristiche che possono essere sostenute.
Il MAC 802.16 è capace di sostenere specifiche di PHY sia con che senza trama. Per un PHY con trama, il MAC allinea i suoi intervalli di pianificazione con le trame del PHY fondamentale. Per un PHY senza trama, gli intervalli di pianificazione sono scelti dal MAC per ottimizzare le prestazioni del sistema.
Di seguito saranno analizzati tre tipi di PHY: l’Unframed Frequency Division Duplexing (FDD), il Framed FDD, ed il Time Division Duplexing (TDD).
In un Unframed FDD PHY, i canali di uplink e di downlink sono localizzati su frequenze separate ed ogni SS può emettere e può ricevere simultaneamente. Inoltre, le trasmissioni di uplink e di downlink non usano trame di durata fissa. In questo tipo di sistema, il canale di downlink è “always on” e tutte le stazioni utenti lo ascoltano sempre. Perciò, nel canale di downlink, il traffico è inviato in maniera broadcast usando la multiplazione a suddivisione di tempo (TDM). Il canale di uplink utilizza un Accesso Multiplo a Divisione di Tempo (TDMA), dove una pianificazione centralizzata controlla l'allocazione della banda di uplink. Attualmente lo standard 802.16 non definisce un Unframed FDD PHY.
In un sistema FDD con trame (burst), i canali di uplink e di downlink sono localizzati su frequenze separate ed i dati di downlink possono essere trasmessi in bursts. Per entrambe le trasmissioni di uplink e di downlink viene usata una trama di durata fissa. Questo facilita l'uso di diversi tipi di modulazione e permette anche l’uso simultaneo di stazione utenti full-duplex (che possono trasmettere e ricevere simultaneamente) ed opzionalmente di stazioni utenti half-duplex (che non
possono trasmettere e ricevere simultaneamente). Se vengono utilizzate le stazioni utenti half-duplex, il controllore di banda non assegnerà banda di uplink alla stazione quando questa aspetterà di ricevere dati sul canale di downlink.
La Figura 3.1 descrive le basi di operazione del modo Framed FDD. Il fatto che i canali di uplink e di downlink utilizzano una trama di durata fissa semplifica gli algoritmi di allocazione di banda. Una stazione utente full-duplex è capace di ascoltare il canale di downlink continuamente, mentre una stazione utente half-duplex può ascoltare il canale di downlink solamente quando non sta trasmettendo nel canale di uplink.
Nel caso di TDD, le trasmissioni di uplink e di downlink avvengono in tempi diversi e di solito condividono la stessa frequenza. Una trame di TDD (vedere Figura 3.2) contiene un subframe di downlink e di uplink ed ha una durata fissa. La trama è divisa in un numero intero di slots fisici (PS), che aiutano a suddividere facilmente la banda. Il TDD framing è adattabile in quanto può variare la banda assegnata al downlink rispetto all'uplink. La divisione tra uplink e downlink è un parametro di sistema che è controllato da strati superiori all'interno del sistema.
2.3.10 Supporto MAC per sistemi con antenna adattativa (AAS) per i 2 – 11 GHz (opzionale)
L’AAS attraverso l'uso di più elementi d’antenna, può migliorare il range e la capacità del sistema, adattando il modello d’antenna e concentrando la sua radiazione verso ogni singolo utente. L'efficienza spettrale può essere aumentata linearmente col numero di elementi d’antenna. Questo è realizzato gestendo simultaneamente raggi ad utenti multipli in modo da realizzare una frequenza di riuso inter-cella unitaria ed un fattore di riuso intra-cella proporzionale al numero di elementi d’antenna.
Tra i vantaggi di questi sistemi vi è il guadagno del SNR realizzato coerentemente combinando segnali multipli, e la capacità di dirigerlo verso un particolare utente. Un altro possibile vantaggio è la riduzione dell’interferenza realizzata inserendo dei nulli nelle direzioni degli interferenti co-canali.
Il supporto del meccanismo AAS specificato, offre vantaggi ad un sistema con array adattativo, mantenendo la compatibilità con le SS non-AAS. Nelle specifiche dello standard si prevede per l’opzione AAS un meccanismo per passare da un sistema non-AAS ad un sistema con AAS abilitato in cui la sostituzione iniziale della BS non-AAS con una BS AAS dovrebbe provocare soltanto l’interruzione del servizio per le SS non-AAS. Questo è realizzato dedicando parte della trama per il traffico non-AAS e parte per quello AAS. L’allocazione è compiuta dinamicamente dalla BS. Le SS non-AAS ignoreranno il traffico AAS, che potranno identificare basandosi sulle comunicazioni MAP/UL-MAP; mentre le SS AAS abilitate useranno comunicazioni DL-MAP/UL-MAP dedicate e private, e per questo non collideranno con il traffico non-AAS.
Il processo di sincronizzazione iniziale nel downlink per un sistema AAS è diverso da quello per uno non-AAS; questo perché l’array adattativi che opera nel PHY non può essere efficace finché il MAC e il PHY della BS identificano la nuova SS. L’adattamento dell’array d’antenna della BS può essere compiuto solo dopo che la BS ha identificato la SS.
Quando la prima SS tenta di sincronizzarsi alla trasmissione di downlink, la BS è ignara della sua presenza e quindi non rivolge l’array adattivo nella sua direzione. Tuttavia il preambolo di inizio trama è ripetitivo e quindi ben noto, per cui la SS può innescare il processo per sincronizzare i parametri di tempo e di frequenza con la BS.
Dopo la sincronizzazione la SS tenta di ottenere i parametri di DL che le servono per decodificare le comunicazioni DL-MAP e DCD. Possiamo avere 2 casi. Nel primo caso la SS riceve il canale Broadcast con un’energia sufficiente da permetterle di decodificare i messaggi e in tal caso continuerà il processo di ingresso nella rete come nel caso non-AAS e la BS, durante il processo di ranging, regolerà l’array adattativo verso la posizione della SS. Nel secondo caso la BS riserverà una parte fissa e predefinita della trama per gli slot di contesa per il ranging iniziale; tali slot saranno situati in posizioni ben note rispetto al preambolo del DL in modo che una SS, che riesca ad identificare almeno un preambolo di DL, sia in grado di localizzarli. Il numero e la posizione di questi slot detti AAS-alert-slot viene specificato nello standard.
Quando una AAS SS si è sincronizzata al downlink, ma non ha ancora ottenuto i parametri necessari per la decodifica, tenterà il ranging iniziale sugli AAS-alert-slot; contrariamente alla procedura usuale, la SS userà tutti gli slot di contesa disponibili per concedere alla BS il tempo necessario per adattare l’array e formare il fascio d’antenna per essa; dopo questo tentativo la SS attenderà l’arrivo delle comunicazioni private DL-MAP e DCD dalla BS e intanto continuerà il processo di ingresso nella rete come nel caso non-AAS.
Se queste comunicazioni non arrivano allora la SS userà un algoritmo di backoff esponenziale per selezionare la trama successiva nella quale tenterà di avvisare la BS della sua presenza.
Gli array adattativi,sia per il DL che per l’UL, utilizzano informazioni sullo stato del canale. Per la richiesta alla BS dello stato del canale di DL si può procedere in 2 modi:
• contando sulla reciprocità ed utilizzando così la stima dello stato del canale di uplink (in tal caso è adatta la TTD)
• utilizzando il feedback e trasmettendo lo stato del canale stimato dalla SS alla BS (è più adatta la FDD)
Per quanto riguarda invece la richiesta di banda nel caso AAS, la SS non può usare il solito meccanismo di contesa poiché l’array adattativo non può avere un beam diretto alla SS al momento della richiesta; per ovviare a questo inconveniente la BS ordina alla SS se utilizzare, oppure no, le comunicazioni broadcast per la richiesta di banda.
2.3.11 Ingresso nella rete ed inizializzazione
I sistemi supporteranno le procedure per l’ingresso e per la registrazione di una nuova SS o di un nuovo nodo nella rete.
Figura 2.24
La procedura può essere divisa nelle seguenti fasi:
a) Scansione del canale di downlink e sincronizzazione con la BS
b) Ottenimento dei parametri di trasmissione (mediante comunicazioni UCD) c) Ranging
d) Negoziazione della capacità di base
e) Autorizzazione della SS e compimento del cambio di chiave f) Registrazione
g) Istaurazione della connettività di IP h) Istaurazione del tempo odierno i) Trasferimento dei parametri operativi j) Preparazione dei collegamenti
Prima di descrivere le fasi precedenti ricordiamo che le uniche informazioni note alla SS, prima di entrare in una rete, sono quelle fornite dal costruttore, cioè un indirizzo universale MAC di 48 bits, usato per identificare la SS ai vari sistema di servizio di approvvigionamento durante l’inizializzazione, e le informazioni di sicurezza usate per autenticare la SS al sistema di servizio di sicurezza e viceversa, come descritto in 2.4.2.
Durante l’inizializzazione o dopo la perdita del segnala, la SS acquisirà un canale di downlink. La SS avrà una memoria nella quale vengono immagazzinati gli ultimi parametri operativi e come prima cosa tenterà di riacquisire questo canale di downlink. Se questo fallisce, analizzerà in modo continuo i possibili canali della banda di frequenza di downlink di lavoro finché non troverà un segnale di downlink valido.
La SS realizzerà la sincronizzazione del MAC dopo aver ricevuto almeno una comunicazione DL-MAP, e rimarrà sincronizzata finché continuerà a ricevere con successo le comunicazioni DL-MAP e DCD del suo canale. Una SS tenterà di ristabilire la sincronizzazione se dopo un tempo pari al Lost DL-MAP Interval non avrà ricevuto una comunicazione DL-MAP valida o se dopo un intervallo T1 non avrà ricevuto un DCD valido.
Sincronizzata la SS, il Sottolivello di MAC tenterà di acquisire i parametri di controllo del canale per il downlink dalla comunicazione DCD e poi per l'uplink da quella UCD.
Quindi avrà inizio la fase di Ranging. Questo è il processo di acquisizione del corretto offset di tempo in modo che le trasmissioni della SS siano allineate ad un simbolo che marchi l'inizio di un confine di minislot.
La SS analizzerà la comunicazione UL-MAP per cercare un Initial Maintenance Interval, nel quale trasmetterà alla BS con un livello di potenza minimo una comunicazione RNG-REQ. Se la SS non riceve una risposta, può rinviare una richiesta con un livello di potenza più alto alla prossima opportunità di trasmissione di Manutenzione Iniziale. Se la SS riceve una risposta che contiene il numero di trama in cui è stata trasmessa la RNG-REQ, considererà il tentativo di trasmissione senza successo ma perfezionerà le correzioni specificate nella RNG-RSP ed effettuerà un’altra comunicazione RNG-REQ dopo un appropriato intervallo di backoff. Se la SS riceve una risposta contenente il suo indirizzo MAC, considererà il ricevimento della RNG-RSP riuscito.
Quando una BS WirelessMAN-SCa o WirelessMAN-OFDM individua una trasmissione nello slot di ranging che non riesce a decodificare, può rispondere emettendo una RNG-RSP che include i parametri di trasmissione ma identifica il numero di trama e l'opportunità di trama quando la trasmissione è stata ricevuta invece dell'Indirizzo MAC della SS che trasmette.
Dopo aver ricevuto con successo la comunicazione RNG-REQ, la BS rimanderà una comunicazione RNG-RSP indirizzata alla SS. All'interno della comunicazione RNG-RSP ci saranno i CID di Base e di Gestione Primaria assegnati a questa SS. La comunicazione conterrà, oltre alle correzioni dell’offset di tempo, anche informazioni sulla correzione del livello di potenza RF e sulla correzione dell’offset di frequenza.
Quindi la SS aspetterà un intervallo di Manutenzione di Stazione assegnata al suo CID di Base per trasmettere un'altra comunicazione RNG-REQ con la quale effettuerà alcune correzioni del livello di potenza e dell’offset di tempo. La BS rimanderà un’altra comunicazione RNG-RSP alla SS con ulteriori correzioni per migliore la sintonia. Gli steps del request/response di ranging saranno ripetuti finché la risposta non conterrà una notifica di Ranging Successful o la BS non concluderà il ranging. Una volta che il ranging avrà avuto successo, la SS congiungerà il normale traffico dati nell'uplink.
Immediatamente dopo il completamento del ranging, la SS informerà la BS delle sue capacità di base trasmettendo una comunicazione REQ. La BS risponderà con una comunicazione SBC-RSP con l'intersezione delle capacità della SS e della BS.
