Studio dell’incidenza dei CS nei livelli della rete

5.2 Presentazione dei risultati

5.2.4 Studio dell’incidenza dei CS nei livelli della rete

rete.

Questo scenario studia la probabilità di successo del sistema in funzione della quantità di memoria allocata nei CS.

Lo studio è effettuato inizialmente allocando cache solo negli AP (1° livello), successivamente estendendo le capacità di memorizzazione anche al 2° e 3° livello della rete ad albero.

Impiegare risorse di memoria solo negli AP non permette di sfruttare completamente il sistema, infatti i risultati mostrano un miglioramento di poco superiore al 10% nella Psucc ed un ulteriore, molto limitato, miglio-

ramento delle prestazioni aggiungendo anche il 3° livello dell’albero. L’influenza minima del 3° livello di rete è ovviamente anche dovuta alla topologia al albero binario che, a quel livello, presenta solo 2 nodi.

L’incidenza diventa sempre più limitata aumentando le dimensioni del CS, fino a diventare ininfluente quando è possibile soddisfare le richieste totalmente dal 1° livello.

Nella tabella 5.4 è riassunto lo scenario considerato, nel grafico 5.6 sono mostrati i risultati numerici.

Parametro Descrizione Valore τ latenza del collegamento 0.25ms LC1 capacità del link in accesso 9 Mbit/s

LCl capacità dei link (l > 1) 1 Gbit/s

C dimensione del catalogo 50 contenuti αr esponente popolarità dei contenuti 1

V numero di percorsi 1

Utot numero totale di utenti 700

CS dimensione del CS {0, 125, 1000, 1500, 2000, 2500, 3000, 4000, 5000, 6000} chunk

s velocità del veicolo 90 km/h

CT R contact time ratio 1

Tcon durata della connessione con AP 10 s

Tabella 5.4: Riepilogo scenario per lo studio dell’impiego delle cache nella rete.

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000 0 0.2 0.4 0.6 0.8 1

Dimensione del content store, CS (chunk) Psucc

1° livello 1°+2° livello tutti i livelli

Figura 5.6: Probabilità di successo, Psucc, nel recupero dei contenuti valutata per

5.2.5 Studio del tempo di contatto tra utenti e AP

In questo scenario si vuole studiare come variano le prestazioni del sistema quando l’utente attraversa più o meno velocemente l’area di copertura dell’AP.

Per questo studio si agisce sul parametro Contact Time Ratio (CTR) ipotiz- zando che nell’area di copertura di alcuni AP gli utenti possano muoversi con una velocità maggiore rispetto ad altre zone.

La valutazione è effettuata allocando risorse di cache prima solo nel 1° livello dell’albero e successivamente anche nel 2° e 3° livello.

Dai risultati si nota che per CTR crescente la Psucc decresce, infatti la

connessione con l’AP è più intermittente e l’utente ha accesso per più tempo allo stesso contenuto statico dei CS.

L’andamento è molto accentuato quando si implementa la cache solo nel 1° livello dell’albero. L’aggiunta di memoria al 2° e 3° livello della rete ne riduce l’effetto.

Si nota ancora che il miglioramento nelle prestazioni dato dall’aggiunta di memoria nei livelli interni della rete è attorno al 12% per CTR = 1 e vicino al 16% per CTR = 4.

Come già osservato in precedenza l’influenza del 3° livello di rete è molto limitata.

Nella tabella 5.5 è riassunto lo scenario considerato ed i valori numerici dei parametri utilizzati, nel grafico 5.7 sono mostrati i risultati ottenuti.

Parametro Descrizione Valore τ latenza del collegamento 0.25ms LC1 capacità del link in accesso 9 Mbit/s

LCl capacità dei link (l > 1) 1 Gbit/s

C dimensione del catalogo 50 contenuti αr esponente popolarità dei contenuti 1

V numero di percorsi 1

Utot numero totale di utenti 700

CS dimensione del CS 2000 chunk CT R contact time ratio {1, 1.5, 2.33, 4} Tcon durata della connessione con AP {4, 6, 8, 10, 12, 16} s

T tempo di permanenza nel sistema 80 s

Tabella 5.5: Riepilogo scenario per lo studio della velocità degli utenti.

1 1.5 2.33 4 0.75 0.8 0.85 0.9 0.95

Contact Time Ratio, CTR Psuc

1° livello 1°+2° livello tutti i livelli

Figura 5.7: Probabilità di successo, Psucc, nel recupero dei contenuti valutata variando il

5.2.6 Studio della dimensione dei CS per garantire la pro-

babilità di successo desiderata

Attraverso il secondo modello di ottimizzazione proposto nella tesi è possibile valutare numericamente la quantità totale di risorse da investire nella rete, in termini di memoria allocata, per garantire che nel sistema la probabilità di successo sia almeno pari ad un valore desiderato.

Nelle prove si è scelto Psucc =0.95.

Lo studio è stato effettuato valutando, a parità di tempo di permanenza nella rete, l’incidenza del numero di AP che l’utente effettivamente contatta nel percorso.

La durata del percorso è 80 secondi, gli AP incontrati variano da 4 a 8, il tempo di permanenza nell’area di copertura del singolo AP aumenta quando l’utente ne incontra meno nel suo percorso.

Inoltre si è valutata l’incidenza dell’esponente di popolarità dei contenuti (αr) e dell’esponente di probabilità della scelta dei percorsi (αp).

Lo studio evidenzia che è possibile garantire la stessa probabilità di successo ma al costo di aumentare la quantità di cache impiegata in totale nella rete.

Nel caso αr = 1 l’incremento necessario di cache è circa dell’80%, nel

caso αr = 0.6 è necessario raddoppiare la memoria totale impiegata per

garantire la probabilità di successo del 95%.

Inoltre i risultati mostrati nel grafico 5.8 indicano una influenza praticamente nulla dell’esponente di popolarità della scelta dei percorsi, αp.

I risultati coincidono esattamente per Ncont = 8 e diversi αp perchè

solo un percorso tocca tutti gli AP disponibili.

Parametro Descrizione Valore τ latenza del collegamento 0.25ms LC1 capacità del link in accesso 15 Mbit/s

LCl capacità dei link (l > 1) 1 Gbit/s

C dimensione del catalogo 50 contenuti αr esponente della popolarità dei contenuti {0.6, 1}

V numero di percorsi 5

αp esponente della popolarità dei percorsi {0, 1}

Utot numero totale di utenti 700

Ncont numero di contatti con AP nel percorso {4, 5, 6, 7, 8}

T tempo di permanenza nel sistema 80 s Psucc probabilità di successo desiderata 95%

Tabella 5.6: Riepilogo scenario per lo studio della quantità di memoria necessario a garantire la Psuccdesiderata.

4 5 6 7 8 4 5 6 7 8 9 ·104

Numero di AP incontrati nel percorso, Ncont

Dimensione CS complessiva (chunk) α_r=1; α_p=1 α_r=1; α_p=0 α_r=0.6; α_p=1 α_r=0.6; α_p=0

Figura 5.8: Dimensione totale dei CS necessaria a garantire la Probabilità di successo, Psucc, desiderata calcolata al variare dell’esponente di popolarità dei contenuti, αr, e dei

In figura 5.9 sono mostrati i casi{αr = 1; αp = 1} e {αr =0.6; αp =1}

con gli intervalli di confidenza ottenuti dalle ripetizioni effettuate.

Ad ogni nuova istanza, la matrice dei contatti è generata nuovamente in maniera casuale ottenendo quindi diversi schemi di collegamento tra utenti e AP. 4 5 6 7 8 4 5 6 7 8 9 ·104

Numero di AP incontrati nel percorso, Ncont

Dimensione CS complessiva (chunk) αr=1; αp=1 αr=0.6; αp=1

Figura 5.9: Intervalli di confidenza al 95% calcolati su 25 soluzioni intere diverse per ogni valore di Ncontdel secondo modello matematico.

La figura 5.10 mostra il quantitativo di memoria allocato in ognuno dei quattro livelli di rete nello scenario con αr = 1 e αp = 1, al variare

del numero di AP contattati nel percorso. I valori sono stati mediati sulle ripetizioni effettuate.

Si nota come venga privilegiato l’impiego di memoria nel 1° livello della rete. Ovviamente va ricordato che i CS al primo livello sono in numero

maggiore rispetto agli altri livelli della rete, data la topologia ad albero binario. 4 5 6 7 8 0 1 2 3 4 5 6 7 8 ·10 4

Numero di AP incontrati nel percorso, Ncont

Dimensione CS per ogni livello (chunk) 1° Livello 2° Livello 3° Livello 4° Livello

Figura 5.10: Quantità di memoria allocata in ogni livello della rete per raggiungere Psucc=95% in funzione del numero di AP incontrati, Ncont.

Il caso Ncont=8 merita un commento particolare: questo scenario non

è ripetuto in quanto esiste solo una sequenza nella matrice dei contatti che contatta 8 AP che, banalmente, è quella costituita da tutti 1.

La soluzione del problema ILP fornisce una funzione obiettivo ottima pari a 40000 chunk ma non esiste una unica distribuzione della memoria nei livelli della rete che permetta di raggiungerla.

La figura 5.11 mostra varie soluzioni trovate attraverso l’ottimizzazione che fornisco diverse configurazioni di allocazione nella rete.

1 2 3 4 5 6 7 8 0 1 2 3 4 5 ·10 4 Indice dell’esperimento Dimensione CS per ogni livello (chunk)

1° Livello 2° Livello 3° Livello 4° Livello

Figura 5.11: Caso Ncont=8: distribuzione della memoria nei livelli della rete in diverse

Capitolo

6

Conclusioni

I

l paradigma Named Data Networking (NDN) è un interessante argo- mento di ricerca per i grandi vantaggi che può portare al funzionamento della rete Internet.

In questa tesi ci si è concentrati sulla distribuzione di contenuti e sul supporto alla mobilità degli utenti, due delle più importanti tendenze nelle reti di telecomunicazioni degli ultimi anni, per le quali è prevista ancora una forte crescita.

Dal punto di vista della distribuzione dei contenuti i vantaggi sono immediatamente percepibili, la possibilità di sfruttare il concetto di in- network caching consente alle richieste da parte degli utenti di essere in- tercettate e soddisfatte nei nodi intermedi della rete, senza dover far raggiungere ogni richiesta all’entità che introduce in rete il contenuto.

I vantaggi sono tanto più elevati quanto più le richieste si concentrano su un numero limitato di contenuti, quelli più popolari.

NDN porta vantaggi intrinseci al supporto della mobilità: le richieste non soddisfatte nella finestra di contatto con l’Access Point (AP), vengono semplicemente espresse nuovamente verso il successivo AP incontrato

non appena il collegamento fisico è nuovamente disponibile. Non è necessaria nessuna altra azione a livello di rete, non essendo ereditato dal mondo IP il concetto di connessione.

Nella tesi si è voluto studiare l’apporto del concetto di in-network ca- chingin scenario di mobilità, attraverso un modello di ottimizzazione ma- tematica che fornisca l’allocazione ottima dei contenuti nei nodi della rete partendo dalla conoscenza a priori dei percorsi degli utenti.

Il modello permette di studiare il funzionamento del sistema in funzione di vari parametri di rete e di trarre conclusioni sul dimensionamento otti- mo del sistema.

Il sistema è stato valutato in termini di probabilità di successo da parte degli utenti nel recuperare il contenuto desiderato durante il tragitto nella rete. Un secondo modello matematico è stato derivato a partire dal primo per valutare la quantità totale di memoria da impiegare nel sistema per ottenere una desiderata probabilità di successo.

Si è fornito inoltre un confronto, attraverso simulazioni, con il funzionamento standard dell’architettura NDN che mantiene i contenuti nei CS secondo la tecnica di caching Least Recently Used (LRU).

Dal confronto tra simulazioni ed allocazione ottima si osserva un miglioramento delle prestazioni vicino al 30% quando il sistema serve 400 utenti e quasi del 100% attorno ai 700 utenti attivi.

I modelli matematici sono stati ampiamente studiati valutando le prestazioni del sistema in vari scenari.

Di seguito vengono riassunti le principali osservazioni tratte da questo studio:

• l’allocazione di memoria nei Content Store (CS) all’interno della rete può incrementare le prestazioni del sistema ed essere una interessan-

te alternativa ad un costoso aggiornamento della capacità degli AP. Nel caso più limitato in banda considerato, il miglioramento con un raddoppio della capacità dei CS è stato quasi del 15%.

Si sono raggiunte praticamente le stesse prestazioni del sistema dotato di un terzo in più di capacità negli AP;

• se un collegamento nella rete ha maggiore ritardo di trasmissione è possibile ottenere la stessa probabilità di successo del sistema dotato di collegamenti a minor latenza, al costo di aumentare la capacità di memoria nel nodo;

• nella topologia di rete ad albero binario considerata allocare memoria solo negli AP non è la soluzione ideale ma, allocando memoria anche nei nodi interni, le prestazioni possono essere migliorate di un valore attorno al 10% in termini di probabilità di successo.

Come atteso, considerando un albero su 4 livelli, l’impatto dell’impiego di memoria nel terzo livello è minimo.

• Quando gli utenti non si spostano nella rete a velocità costante ma rimangono nell’area di copertura degli AP per tempi differenti si nota un degrado nelle prestazioni tanto più i contatti con gli AP sono intermittenti.

In questo caso l’impiego di rete nel 2° e 3° livello della rete aiuta a limitarne l’effetto.

• Attraverso il secondo modello matematico proposto si quantifica l’incremento della memoria impiegata nella rete con l’obiettivo di garantire la stessa probabilità di successo pur considerando un numero in- feriore di AP visitati dagli utenti. Questo incremento varia tra l’80% ed il 100% in base allo scenario considerato.

Si nota inoltre un accentuato sbilanciamento verso l’implementazione di maggiore memoria nel primo livello della rete.

6.1 Sviluppi futuri

Di seguito vengono elencate alcune proposte per possibili ampliamenti del lavoro svolto:

• Modello matematico

Attualmente il modello matematico considera un catalogo con po- polarità dei contenuti statica. Un ampliamento del lavoro potrebbe portare a valutare la possibilità che la popolarità dei contenuti cambi nel tempo: questo implica l’introduzione, non banale, della variabile tempo nei modelli.

In aggiunta, la gestione del tempo nel modello potrebbe portare ad uno studio più completo delle dinamiche di mobilità degli utenti. • Simulazioni

Una migliore ottimizzazione di quanto implementato nel simulatore permetterebbe un più rapido e completo studio delle prestazioni at- tuali della architettura NDN nella gestione della mobilità degli utenti.

Di grande interesse potrebbe essere l’implementazione in ndnSIM di un algoritmo per l’allocazione ottima dei contenuti derivato dai modelli proposti, inizialmente gestito offline da una entità onnisciente introdotta nella rete.

Idealmente si potrebbe giungere alla realizzazione di uno schema distribuito che possa variare dinamicamente l’allocazione ottima dei

contenuti nella rete e possa reagire ad una variazione nel tempo della popolarità delle richieste espresse dagli utenti.

Appendice

A

Codice AMPL

A.1 Modello 1

1 display solve_message; 2 option show_stats 1; 3

4 option solver cplexamp;

5 option cplex_options ’integrality=5e-09 round=0 presolve=0 mipdisplay 2 timing 1 nodefile 3 varselect 3’; 6 7 option omit_zero_rows 1; 8 9 #SETS 10 #Access Point: 11 set I; 12 #File: 13 set J; 14 #Paths: 15 set V;

16 #Level in binary tree: 17 set L;

19 #PARAM

20 # prob of request for file_j 21 param req{J};

22 # prob of path_v 23 param p{V};

24 # max capacity for CS of level l 25 param CS{L};

26 # bandwidth available to retrieve chunks from each node 27 param mdb{I,V,L};

28 # contact matrix 29 param cont{I,V}; 30 # cost

31 param gamma{I,V,L};

32 # number of chunk for each file 33 param n {j in J};

35 #VARS

36 # number of chunks in level l CS linked to AP_i for file_j 37 var x {I,j in J,L} integer >= 0, <= n[j];

38 # number of chunks retrieved from AP_i, from path_v, for file_j 39 #var y {I,V,J} integer >= 0;

40 # retrievability for file_j from path_v 41 var b {J,V} binary;

42 # chunk retrieved for each file, from each level, in each path, from each AP 43 var rec {I,V,J,L} integer >= 0;

44 45 #OBJECTIVE FUNCTION 46 maximize prob: 47 sum{j in J, v in V} req[j] * p[v] * b[j,v]; 48 49 #CONSTRAINTS

50 subject to Bandwidth_edge{i in I,j in J, v in V}:

51 sum{l in L} gamma[i,v,l] * rec[i,v,j,l] <= bandwidth[i,v,1]; 52

53 subject to ContentStore{i in I, v in V, j in J, l in L}: 54 rec[i,v,j,l] <= x[i,j,l];

56 subject to Retrievability{v in V, j in J}:

57 sum{i in I, l in L} (rec[i,v,j,l] * cont[i,v]) = (b[j,v] * n[j]); 58

59 subject to CS_capacity_l1{i in I}: 60 sum{j in J} x[i,j,1] <= CS[1]; 61

63 sum{j in J} (x[1,j,2] + x[2,j,2]) <= CS[2]; 64 65 subject to CS_capacity_l2_3_4: 66 sum{j in J} (x[3,j,2] + x[4,j,2]) <= CS[2]; 67 68 subject to CS_capacity_l2_5_6: 69 sum{j in J} (x[5,j,2] + x[6,j,2]) <= CS[2]; 70 71 subject to CS_capacity_l2_7_8: 72 sum{j in J} (x[7,j,2] + x[8,j,2]) <= CS[2]; 73 74 subject to CS_capacity_l3_1_2_3_4: 75 sum{j in J} (x[1,j,3] + x[2,j,3] + x[3,j,3] + x[4,j,3]) <= CS[3]; 76 77 subject to CS_capacity_l3_5_6_7_8: 78 sum{j in J} (x[5,j,3] + x[6,j,3] + x[7,j,3] + x[8,j,3]) <= CS[3]; 79 80 subject to Link_capacity_2{i in I, j in J, v in V}: 81 rec[i,v,j,2] <= mdb[i,v,2] - rec[i,v,j,1]; 82

83 subject to Link_capacity_3{i in I, j in J, v in V}:

84 rec[i,v,j,2] <= mdb[i,v,2] - sum{q in 1..2} rec[i,v,j,q]; 85

86 subject to Link_capacity_4{i in I, j in J, v in V}:

A.2 Modello 2

1 option show_stats 1; 2

3 option solver cplexamp;

4 option cplex_options ’integrality=5e-09 round=0 presolve=0 mipdisplay 2 timing 1 nodefile 3 varselect 3’;

5 option cplex_options ’return_mipgap 2 bestbound nodelim 3’; 6 7 option omit_zero_rows 1; 8 9 #SETS 10 #Access Point: 11 set I; 12 #File: 13 set J; 14 #Paths: 15 set V;

16 #Level in binary tree: 17 set L;

19 #PARAM

20 # prob of request for file_j 21 param req{J};

22 # prob of path_v 23 param p{V};

24 # max capacity for CS of level l 25 #param CS{L};

26 # mdb available to retrieve chunks from each node 27 param mdb{I,V,L};

28 # contact matrix 29 param cont{I,V}; 30 # cost

31 param gamma{I,V,L};

32 # number of chunk for each file 33 param n {j in J};

34 # prob of success wanted 35 param p_succ;

38 # number of chunks in level l CS linked to AP_i for file_j 39 var x {i in I, j in J, l in L} integer >= 0;

40 # number of chunks retrieved from AP_i, from path_v, for file_j 41 #var y {I,V,J} integer >= 0;

42 # retrievability for file_j from path_v 43 var b {J,V} binary;

44 # chunk retrieved for each file, from each level, in each path, from each AP 45 var rec {I,V,J,L} integer >= 0;

46 47 #OBJECTIVE FUNCTION 48 minimize prob: 49 sum{i in I, j in J, l in L} x[i,j,l]; 50 51 #CONSTRAINTS 52 subject to Success:

53 sum{j in J, v in V} req[j] * p[v] * b[j,v] >= p_succ; 54

55 subject to Bandwidth_edge{i in I,j in J, v in V}:

56 sum{l in L} gamma[i,v,l] * rec[i,v,j,l] <= mdb[i,v,1]; 57

58 subject to ContentStore{i in I, v in V, j in J, l in L}: 59 rec[i,v,j,l] <= x[i,j,l];

61 subject to Retrievability{v in V, j in J}:

62 sum{i in I, l in L} (rec[i,v,j,l] * cont[i,v]) = (b[j,v] * n[j]); 63

64 subject to Link_capacity_2{i in I, j in J, v in V}: 65 rec[i,v,j,2] <= mdb[i,v,2] - rec[i,v,j,1]; 66

67 subject to Link_capacity_3{i in I, j in J, v in V}:

68 rec[i,v,j,2] <= mdb[i,v,2] - sum{q in 1..2} rec[i,v,j,q]; 69

70 subject to Link_capacity_4{i in I, j in J, v in V}:

Appendice

B

Codice ndnSIM

B.1 Caricamento scenario simulazione

1 #include "ns3/core-module.h" 2 #include "ns3/network-module.h" 3 #include "ns3/applications-module.h" 4 #include "ns3/wifi-module.h" 5 #include "ns3/mobility-module.h" 6 #include "ns3/internet-module.h" 7 8 #include "ns3/ndnSIM-module.h" 9 10 using namespace std; 11 using namespace ns3; 12 13 NS_LOG_COMPONENT_DEFINE ("ndn.WifiExample"); 14 15 int

16 main (int argc, char *argv[]) 17 { 18 std::string traceFile; 19 std::string logFile; 20 21 int nodeNum; 22 double duration; 78

24 // Parse command line attribute 25 CommandLine cmdd;

26 cmdd.AddValue ("traceFile", "Ns2 movement trace file", traceFile); 27 cmdd.AddValue ("nodeNum", "Number of nodes", nodeNum);

28 cmdd.AddValue ("duration", "Duration of Simulation", duration); 29 cmdd.AddValue ("logFile", "Log file", logFile);

30 cmdd.Parse (argc,argv); 31

32 if (traceFile.empty () || nodeNum <= 0 || duration <= 0 || logFile.empty ())

33 {

34 std::cout << "Usage of " << argv[0] << " :\n\n" 35 "./waf --run \"ns2-mobility-trace"

36 " --traceFile=src/mobility/examples/default.ns_movements" 37 " --nodeNum=2 --duration=100.0 --logFile=ns2-mob.log\" \n\n"

38 "NOTE: ns2-traces-file could be an absolute or relative path. You could use the file default.ns_movements\n"

39 " included in the same directory of this example file.\n\n" 40 "NOTE 2: Number of nodes present in the trace file must match with the

command line argument and must\n"

41 " be a positive number. Note that you must know it before to be able to load it.\n\n"

42 "NOTE 3: Duration must be a positive number. Note that you must know it before to be able to load it.\n\n";

44 return 0;

45 }

47 Ns2MobilityHelper ns2 = Ns2MobilityHelper (traceFile); 48

49 NodeContainer stas; 50 stas.Create (nodeNum); 51

52 ns2.Install (); // configure movements for each node, while reading trace file 53 54 // disable fragmentation 55 Config::SetDefault ("ns3::WifiRemoteStationManager::FragmentationThreshold", StringValue ("2200"));

56 Config::SetDefault ("ns3::WifiRemoteStationManager::RtsCtsThreshold", StringValue ("2200")); 57 Config::SetDefault ("ns3::WifiRemoteStationManager::NonUnicastMode", StringValue ("OfdmRate9Mbps")); 58 59 //CommandLine cmd; 60 //cmd.Parse (argc,argv); 61 62 AnnotatedTopologyReader topologyReader ("", 1); 63 topologyReader.SetFileName ("src/ndnSIM/examples/topologies/topo-tree-mobile-anello.txt"); 64 65 topologyReader.Read ();

66 NodeContainer nodes_topo = topologyReader.GetNodes (); 67

68 WifiHelper wifi = WifiHelper::Default (); 69 wifi.SetStandard (WIFI_PHY_STANDARD_80211a);

70 wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode", StringValue ("OfdmRate9Mbps"));

72 YansWifiChannelHelper wifiChannel;// = YansWifiChannelHelper::Default (); 73 wifiChannel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel"); 74 wifiChannel.AddPropagationLoss ("ns3::ThreeLogDistancePropagationLossModel"); 75 wifiChannel.AddPropagationLoss ("ns3::NakagamiPropagationLossModel"); 76 wifiChannel.AddPropagationLoss ("ns3::RangePropagationLossModel","MaxRange", DoubleValue (10)); 77

78 //YansWifiPhy wifiPhy = YansWifiPhy::Default();

79 YansWifiPhyHelper wifiPhyHelper = YansWifiPhyHelper::Default (); 80 wifiPhyHelper.SetChannel (wifiChannel.Create ());

81 wifiPhyHelper.Set("TxPowerStart", DoubleValue(5)); 82 wifiPhyHelper.Set("TxPowerEnd", DoubleValue(5)); 83

84 NqosWifiMacHelper wifiMacHelper = NqosWifiMacHelper::Default (); 85 wifiMacHelper.SetType("ns3::AdhocWifiMac");

87 //nodes = lista dove installare wifi 88 NodeContainer nodes;

89 //lista dove installare app ndn 90 NodeContainer mobile;

92 NodeContainer wifi_ap; 93

94 for(int i=1; i <= nodeNum; i++)

95 mobile.Add(NodeList::GetNode(i-1)); 96 97 // 1. Install Wifi 98 99 //fixed 8 AP (topology_reader) 100 nodes.Add(Names::Find<Node>("leaf-1")); 101 nodes.Add(Names::Find<Node>("leaf-2")); 102 nodes.Add(Names::Find<Node>("leaf-3")); 103 nodes.Add(Names::Find<Node>("leaf-4")); 104 nodes.Add(Names::Find<Node>("leaf-5")); 105 nodes.Add(Names::Find<Node>("leaf-6")); 106 nodes.Add(Names::Find<Node>("leaf-7")); 107 nodes.Add(Names::Find<Node>("leaf-8")); 108

109 //nodes from mobility trace 110 for(int i=1; i<=nodeNum; i++){

111 nodes.Add(NodeList::GetNode(i-1)); 112 }

113

114 //container just for the pcap

115 wifi_ap.Add(Names::Find<Node>("leaf-1")); 116 wifi_ap.Add(Names::Find<Node>("leaf-3")); 117 wifi_ap.Add(Names::Find<Node>("leaf-5")); 118 wifi_ap.Add(Names::Find<Node>("leaf-7")); 119

120 NetDeviceContainer wifiNetDevices = wifi.Install (wifiPhyHelper, wifiMacHelper, nodes);

121

122 // 3. Install NDN stack

123 NS_LOG_INFO ("Installing NDN stack"); 124 ndn::StackHelper ndnHelper; 125 // ndnHelper.AddNetDeviceFaceCreateCallback (WifiNetDevice::GetTypeId (), MakeCallback (MyNetDeviceFaceCallback)); 126 ndnHelper.SetForwardingStrategy ("ns3::ndn::fw::BestRoute"); 127 128 //CS level 1

129 ndnHelper.SetContentStore ("ns3::ndn::cs::Lru", "MaxSize", "2000"); 130

131 ndnHelper.Install (nodes_topo); 132 ndnHelper.SetDefaultRoutes (true); 133

134 ndnHelper.SetContentStore ("ns3::ndn::cs::Lru", "MaxSize", "1"); 135 ndnHelper.Install (mobile);

136

137 //Static FIB for all the ’network devices’ in the tree

138 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-1"), "/root", Names::Find<Node>("rtr-1"), 1);

139 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-2"), "/root", Names::Find<Node>("rtr-1"), 1);

140

141 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-3"), "/root", Names::Find<Node>("rtr-2"), 1);

142 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-4"), "/root", Names::Find<Node>("rtr-2"), 1);

143

144 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-5"), "/root", Names::Find<Node>("rtr-3"), 1);

145 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-6"), "/root", Names::Find<Node>("rtr-3"), 1);

146

147 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-7"), "/root", Names::Find<Node>("rtr-4"), 1);

148 ndn::StackHelper::AddRoute (Names::Find<Node>("leaf-8"), "/root", Names::Find<Node>("rtr-4"), 1);

149

150 ndn::StackHelper::AddRoute (Names::Find<Node>("rtr-1"), "/root", Names::Find<Node>("rtr-5"), 1);

151 ndn::StackHelper::AddRoute (Names::Find<Node>("rtr-2"), "/root", Names::Find<Node>("rtr-5"), 1);

152

153 ndn::StackHelper::AddRoute (Names::Find<Node>("rtr-3"), "/root", Names::Find<Node>("rtr-6"), 1);

154 ndn::StackHelper::AddRoute (Names::Find<Node>("rtr-4"), "/root", Names::Find<Node>("rtr-6"), 1);

155

156 ndn::StackHelper::AddRoute (Names::Find<Node>("rtr-5"), "/root", Names::Find<Node>("root"), 1);

157 ndn::StackHelper::AddRoute (Names::Find<Node>("rtr-6"), "/root", Names::Find<Node>("root"), 1);

158

159 // 4. Set up applications

160 NS_LOG_INFO ("Installing Applications"); 161

162 // Zipf’s distribution and window

163 ndn::AppHelper consumerHelper ("ns3::ndn::ConsumerZipfMandelbrot"); 164 consumerHelper.SetPrefix("/root");

165 consumerHelper.SetAttribute ("NumberOfContents", StringValue("50")); //dim 1000 byte, #chunk=1000

166 consumerHelper.SetAttribute ("q", StringValue("0")); //Zipf Distribution 167 consumerHelper.SetAttribute ("s", StringValue("1")); //s = alpha

168 consumerHelper.SetAttribute ("RetxTimer", TimeValue (Seconds(0.010))); 169 consumerHelper.SetAttribute ("Window", StringValue("1")); //initial window 170 consumerHelper.SetAttribute("NumberOfNodes", UintegerValue(nodeNum)); 171 consumerHelper.SetAttribute("NumberOfChunks", StringValue("1000")); 172

173

174 for(int i=0; i < nodeNum; i++){

175 ApplicationContainer app_cons = consumerHelper.Install (NodeList::GetNode(i));

176

177 //double tstart = double(i)/10 + 0.5;// .1

178 double tstart = double(i)*15/100 + 0.5; // .15

179 //double tstart = double(i)/5 + 0.5; // .2 180 //double tstart = double(i)/4 + 0.5; // .25

Nel documento Allocazione ottima di contenuti in reti ICN veicolari (pagine 73-107)