Gestione dell'handover verticale in Reti Mobili di ultima ... - InfoCom
Gestione dell'handover verticale in Reti Mobili di ultima ... - InfoCom Gestione dell'handover verticale in Reti Mobili di ultima ... - InfoCom
Figura 12: MIP Architecture 60 CAPITOLO III Il problema del cosiddetto routing triangolare, consiste nel fatto che mentre i pacchetti mandati dal CH verso il MH vengono catturati dal HA, il quale li instrada verso il MH, al contrario il MH può mandare direttamente i propri pacchetti verso il CH. Pertanto vi è questa entità intermediaria, nota anche come Proxy server, la quale interviene solamente sul traffico in una direzione. Tale routing asimmetrico genera dei ritardi sul traffico verso il MH, e tali ritardi possono non essere tollerati a seconda del tipo di servizio che si sta effettuando( se pensiamo ad un traffico VoIP, il ritardo è un requisito utente molto importante!). Inoltre i pacchetti vengono tunnellizati e pertanto si aggiunge overhead sui pacchetti, di circa 20 Bytes, dovuto all’incapsulamento.
61 CAPITOLO III Un ulteriore svantaggio del Mobile IP, è che ogni MH richiede un indirizzo IP permanente, e questo potrebbe essere un problema in IPv4, a causa del numero di indirizzi IP limitato. Vi sono molteplici studi in corso per ovviare alle problematiche suddette, tra tali studi trova la sua definizione l’IPv6, che è un’estensione dell’IPv4 ed in tale protocollo si va a superare il problema del routing triangolare. Viene studiato un meccanismo di aggiornamenti obbligatori mandati verso il CH, per tenerlo sempre informato sulla posizione attuale del MH. Inoltre vi sono ulteriori estensioni del MIPv6, che prevedono delle strategie di handover veloci, chiamati Hierarchical Mobile IP e Fast Handovers. Senza scendere nel dettaglio sulle strategie citate va sottolineato il fatto che il Mobile IP risulta essere una soluzione onerosa nella misura in cui viene richiesta una vera e propria modifica degli apparati di rete coinvolti, ed una modifica sui terminali. Questa risulta essere la causa scatenante del fatto che tale soluzione non ha preso piede, nell’ambito del vertical handover. Di seguito è riportata la figura che mostra la procedura di segnalazione generata quando viene eseguito un vertical handover.
- Page 15 and 16: 9 Capitolo I geografici: da qualunq
- Page 17 and 18: 1.1 Le reti per comunicazioni mobil
- Page 19 and 20: 13 Capitolo I generazione ha sugger
- Page 21 and 22: Si distinguono due tipi di WLAN / W
- Page 23 and 24: 17 Capitolo I Infine, un consorzio
- Page 25 and 26: 19 Capitolo I territori scoperti da
- Page 27 and 28: 21 Capitolo I La presenza di parecc
- Page 29 and 30: 1.3 UMTS 23 Capitolo I UMTS (Univer
- Page 31 and 32: 25 Capitolo I Un altro sistema evol
- Page 33 and 34: 27 Capitolo I Le bande di frequenza
- Page 35 and 36: 29 Capitolo I fosse destinata ad un
- Page 37 and 38: 1.4 WLAN 31 Capitolo I concentrazio
- Page 39 and 40: 33 Capitolo I L’architettura Wire
- Page 41 and 42: 35 Capitolo I Mobile WiMAX sullo st
- Page 43 and 44: 37 Capitolo I amplificare e ritrasm
- Page 45 and 46: 39 Capitolo I accesso di ciascun ut
- Page 47 and 48: 41 Capitolo I sono cambiate radical
- Page 49 and 50: 43 Capitolo I Per sfruttare le oppo
- Page 51 and 52: 45 Capitolo I computer, ma è veros
- Page 53 and 54: o ingegnerizzazione della mobilità
- Page 55 and 56: 2.1 Handover verticale 49 CAPITOLO
- Page 57 and 58: 51 CAPITOLO II terminali a gestire
- Page 59 and 60: 53 CAPITOLO II Infatti quando un te
- Page 61 and 62: 55 CAPITOLO II L’802.21 specifica
- Page 63 and 64: 57 CAPITOLO III protocollo IP. Di s
- Page 65: 59 CAPITOLO III da quell’istante
- Page 69 and 70: 63 CAPITOLO III SIP gestisce in mod
- Page 71 and 72: Figura 15: SIP Re-Invite Signalling
- Page 73 and 74: 67 CAPITOLO III Ogni MH è munito d
- Page 75 and 76: 69 CAPITOLO III Effettuata tale pro
- Page 77 and 78: 71 CAPITOLO III energia. I metodi d
- Page 79 and 80: 73 CAPITOLO III Innanzitutto il ver
- Page 81 and 82: Inoltre di seguito vengono riportat
- Page 83 and 84: 77 CAPITOLO III conseguenza dell’
- Page 85 and 86: 79 CAPITOLO III Nel diagramma a blo
- Page 87 and 88: 81 CAPITOLO III mobile. Quando tale
- Page 89 and 90: 83 CAPITOLO IV Il progetto si basa
- Page 91 and 92: 85 CAPITOLO IV trasmittenti e ricev
- Page 93 and 94: 87 CAPITOLO IV In questo sottoparag
- Page 95 and 96: 89 CAPITOLO IV garantire. Un’inte
- Page 97 and 98: 91 CAPITOLO IV tempo per l’arrivo
- Page 99 and 100: 93 CAPITOLO IV Analogamente è stat
- Page 101 and 102: 95 CAPITOLO IV La previsione per il
- Page 103 and 104: 97 CAPITOLO IV Con i valori dei goo
- Page 105 and 106: CAPITOLO V 99 CAPITOLO V Validazion
- Page 107 and 108: 101 CAPITOLO V In questo paragrafo
- Page 109 and 110: 103 CAPITOLO V diffuso, sia in Euro
- Page 111 and 112: Tabella 4: Confronto dati tecnici 1
- Page 113 and 114: 107 CAPITOLO V La doppia condizione
- Page 115 and 116: 109 CAPITOLO V Nella Figura 23 è r
Figura 12: MIP Architecture<br />
60<br />
CAPITOLO III<br />
Il problema del cosiddetto rout<strong>in</strong>g triangolare, consiste nel fatto che<br />
mentre i pacchetti mandati dal CH verso il MH vengono catturati dal HA, il<br />
quale li <strong>in</strong>strada verso il MH, al contrario il MH può mandare <strong>di</strong>rettamente i<br />
propri pacchetti verso il CH. Pertanto vi è questa entità <strong>in</strong>terme<strong>di</strong>aria, nota<br />
anche come Proxy server, la quale <strong>in</strong>terviene solamente sul traffico <strong>in</strong> una<br />
<strong>di</strong>rezione.<br />
Tale rout<strong>in</strong>g asimmetrico genera dei ritar<strong>di</strong> sul traffico verso il MH, e tali<br />
ritar<strong>di</strong> possono non essere tollerati a seconda del tipo <strong>di</strong> servizio che si sta<br />
effettuando( se pensiamo ad un traffico VoIP, il ritardo è un requisito utente<br />
molto importante!).<br />
Inoltre i pacchetti vengono tunnellizati e pertanto si aggiunge overhead<br />
sui pacchetti, <strong>di</strong> circa 20 Bytes, dovuto all’<strong>in</strong>capsulamento.
Change language