--- title: "Session 4" description: "Wireless ad-hoc network with OLSR" image: "https://syntax.theether.in/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://syntax.theether.in/llms.txt > Use this file to discover all available pages before exploring further. # Session 4 A mobile ad-hoc network has no access point; every node forwards for the others. OLSR is a proactive routing protocol that keeps routes ready before they are needed. ## Objectives - Complete questions 8 to 9 of the manual: wireless ad-hoc network with olsr - Prepare the deliverable before the lab and finish it during the session - Be ready to explain every step in the viva ## Questions Covered | Question | Requirement | Status | | --- | --- | --- | | Q8 | Take three nodes n1, n2 and n3 and create a wireless mobile ad-hoc network | Complete | | Q9 | Install the optimized Link State Routing protocol on these nodes | Complete | ## Preparation - Wireless stack: WifiHelper, YansWifiPhyHelper, YansWifiChannelHelper, WifiMacHelper with `AdhocWifiMac`, and MobilityHelper with `RandomWaypointMobilityModel` for movement. - Install OLSR with `OlsrHelper` passed to `InternetStackHelper::SetRoutingHelper` before installing the stack. - Print routing tables at intervals with `Ipv4RoutingHelper::PrintRoutingTableAllAt` to show OLSR converging. ## Question 8 ### Problem Statement Take three nodes n1, n2 and n3 and create a wireless mobile ad-hoc network. ### Solution Questions 8 and 9 share one program, `adhoc_olsr.cc`. Question 8 is everything up to the mobility model; question 9 adds OLSR and the routing-table dumps. The code indices 0, 1, 2 are the manual's n1, n2, n3. #### Steps 1. Save the program as `scratch/adhoc_olsr.cc` and run `./ns3 run scratch/adhoc_olsr`. 2. Read the `positions:` lines printed at 0, 10, 20 and 30 s; they change because the nodes move. 3. Draw the topology as three dots inside a 100 m by 100 m square with the starting positions from the 0 s line; mark the 11 Mbit/s 802.11b range (roughly 100 m with the default log-distance loss model). 4. For the record run again with `--pcap=true` and note the three files `adhoc-olsr-0-0.pcap`, `adhoc-olsr-1-0.pcap`, `adhoc-olsr-2-0.pcap`. #### Program ```cpp title="adhoc_olsr.cc" file=/public/code/mcsl-223/section-1/session-4/adhoc_olsr.cc ``` #### Output Expected position lines (the random stream is seeded to 1 by default, so a given NS-3 version prints the same numbers every run, but they differ between versions; the values here illustrate the format): ```text t=0s positions: n1 (23.4, 71.2) n2 (58.9, 44.7) n3 (86.1, 12.5) t=10s positions: n1 (41.6, 55.3) n2 (61.2, 70.8) n3 (70.4, 39.9) t=20s positions: n1 (12.8, 30.1) n2 (77.5, 81.6) n3 (52.3, 63.0) t=30s positions: n1 (33.0, 9.7) n2 (90.2, 66.4) n3 (48.8, 88.2) ``` Topology sketch for the record (positions at 0 s): ```text y 100 +----------------------------+ | n1 (23,71) | | | | n2 (59,45) | 802.11b ad-hoc, 11 Mbit/s | | no access point, all peers | n3 | 0 +----------------------------+ x 0 100 ``` #### Explanation The Wi-Fi stack, layer by layer: | Layer | Helper and type | Setting used here | | --- | --- | --- | | Channel | `YansWifiChannelHelper::Default()` | constant speed propagation delay, log-distance path loss | | Physical | `YansWifiPhyHelper` | default 802.11b transmit power, attached to the channel | | Rate control | `ConstantRateWifiManager` | `DsssRate11Mbps` for data and control frames | | MAC | `WifiMacHelper` type `ns3::AdhocWifiMac` | no association, no beacons | | Standard | `WifiHelper::SetStandard` | `WIFI_STANDARD_80211b` | | Mobility | `RandomWaypointMobilityModel` | speed 1 to 5 m/s, pause 2 s, 100 m by 100 m box | Five objects make a Wi-Fi node: a `YansWifiChannel` shared by all nodes with a propagation delay and a log-distance loss model, a `YansWifiPhy` per node attached to that channel, a `WifiMac` of type `AdhocWifiMac` (no association, no beacons from an access point, every node talks to every other directly), a `WifiNetDevice` that binds them, and a `MobilityModel` that gives the phy a position so the loss model can compute the received power. `ConstantRateWifiManager` pins the rate at 11 Mbit/s so the range is predictable. `RandomWaypointMobilityModel` picks a random destination inside the `RandomRectanglePositionAllocator`, moves there at a speed drawn from 1 to 5 m/s, pauses 2 s and repeats, which is why the positions differ at every print. Mobile means the neighbour set changes over time; that is what makes a routing protocol necessary in question 9. ## Question 9 ### Problem Statement Install the optimized Link State Routing protocol on these nodes. ### Solution #### Steps 1. Create an `OlsrHelper` and an `Ipv4StaticRoutingHelper`, put both in an `Ipv4ListRoutingHelper` (static at priority 0, OLSR at priority 10). 2. Call `InternetStackHelper::SetRoutingHelper(list)` before `Install`; the order matters because routing is chosen when the stack is built. 3. Schedule `PrintRoutingTableAllAt` at 5 s, 15 s and 30 s so the record shows the tables converging and changing as nodes move. 4. Start the echo client at 10 s, after OLSR has exchanged HELLO (every 2 s) and TC (every 5 s) messages and filled the tables. 5. Run and copy the three routing-table dumps and the echo lines into the record. #### Program Same file as question 8; the OLSR part is: ```cpp OlsrHelper olsr; Ipv4StaticRoutingHelper staticRouting; Ipv4ListRoutingHelper list; list.Add(staticRouting, 0); list.Add(olsr, 10); InternetStackHelper stack; stack.SetRoutingHelper(list); stack.Install(nodes); Ptr routingStream = Create(&std::cout); olsr.PrintRoutingTableAllAt(Seconds(5.0), routingStream); ``` #### Output Expected routing table dump at 5 s for n1 (node 0). The OLSR table lists every other node with its next hop and hop count; here n3 is two hops away through n2. The same block repeats for nodes 1 and 2 and again at 15 s and 30 s with different next hops as the nodes move. ```text Node: 0, Time: +5s, Local time: +5s, Ipv4ListRouting table Priority: 10 Protocol: ns3::olsr::RoutingProtocol Node: 0, Time: +5s, Local time: +5s, OLSR Routing table Destination NextHop Interface Distance 10.1.1.2 10.1.1.2 1 1 10.1.1.3 10.1.1.2 1 2 Priority: 0 Protocol: ns3::Ipv4StaticRouting Node: 0, Time: +5s, Local time: +5s, Ipv4StaticRouting table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.0 0.0.0.0 255.0.0.0 U 0 - - 0 10.1.1.0 0.0.0.0 255.255.255.0 U 0 - - 1 ``` Expected echo lines (n1 to n3, 512 bytes, every 2 s from 10 s; the delay is about 1.5 ms per Wi-Fi hop at 11 Mbit/s, so a two-hop path shows about 3 ms each way): ```text At time +10s client sent 512 bytes to 10.1.1.3 port 9 At time +10.003s server received 512 bytes from 10.1.1.1 port 49153 At time +10.003s server sent 512 bytes to 10.1.1.1 port 49153 At time +10.006s client received 512 bytes from 10.1.1.3 port 9 At time +12s client sent 512 bytes to 10.1.1.3 port 9 At time +12.0015s server received 512 bytes from 10.1.1.1 port 49153 At time +12.0015s server sent 512 bytes to 10.1.1.1 port 49153 At time +12.003s client received 512 bytes from 10.1.1.3 port 9 ... ``` Per-hop delay from the formula sheet for a 512-byte echo at 11 Mbit/s: frame on air is 512 + 8 + 20 + 8 (LLC) + 24 (MAC) + 4 (FCS) = 576 bytes, , plus 0.192 ms PLCP preamble and header, 0.05 ms DIFS, about 0.3 ms average backoff and 0.3 ms for the MAC ACK: about 1.3 to 1.5 ms per hop. Propagation over 100 m is 0.33 microseconds and can be ignored. #### Explanation OLSR (RFC 3626) is proactive: every node broadcasts HELLO messages to learn its one-hop and two-hop neighbours, elects multipoint relays (MPRs) that are the only nodes to forward its topology control (TC) messages, and runs Dijkstra on the resulting link-state graph. Routes therefore exist before any data is sent, which is why the tables at 5 s are already complete and the echo at 10 s succeeds without a route-discovery delay. When a node moves out of range, missing HELLOs expire the link after the neighbour hold time (6 s by default) and the table is recomputed; the dumps at 15 s and 30 s show the next hop for 10.1.1.3 changing between direct and via 10.1.1.2. `Ipv4ListRouting` tries protocols in priority order, so OLSR answers first and static routing only handles the loopback and the local subnet. ## Viva Questions - **Q:** What makes a network ad-hoc? **A:** No access point; every node forwards for others using a routing protocol. - **Q:** What does `RandomWaypointMobilityModel` need that other models do not? **A:** A `PositionAllocator` attribute to draw its waypoints from. - **Q:** Why must `SetRoutingHelper` come before `Install`? **A:** The stack helper creates the routing protocol object while installing; changing it later has no effect on nodes already built. - **Q:** Proactive or reactive: which is OLSR, and what is the trade-off? **A:** Proactive; routes are ready before use, at the cost of periodic HELLO and TC traffic even when idle. - **Q:** What is a multipoint relay? **A:** A neighbour chosen to reforward TC messages so that flooding reaches every two-hop neighbour with fewer transmissions. - **Q:** Why is the echo client started at 10 s and not 1 s? **A:** OLSR needs a few HELLO and TC intervals to build the tables; early packets would be dropped for lack of a route. - **Q:** What does Distance 2 mean in the OLSR table? **A:** The destination is two hops away; the packet goes to NextHop first. - **Q:** How is the radio range set in this script? **A:** Indirectly: transmit power, the log-distance loss model and the 11 Mbit/s receive threshold give roughly 100 m. ## Common Mistakes - Using `StaWifiMac` or `ApWifiMac`; an ad-hoc network needs `AdhocWifiMac`. - Forgetting the `PositionAllocator` attribute on `RandomWaypointMobilityModel`, which aborts the run. - Installing the internet stack before calling `SetRoutingHelper`, so nodes get global routing instead of OLSR and the echo fails when nodes are more than one hop apart. - Sending traffic at 1 s and reporting that OLSR does not work. - Printing only the static routing table and missing the OLSR block above it. - Making the box much larger than the radio range with only three nodes, so the network is partitioned most of the time. ## Formula Sheet ### Throughput Bytes received at the sink divided by the time the flow was active, converted to bits per second: ### Bandwidth-delay product The amount of data in flight on a link of capacity $B$ and round-trip time $RTT$. A TCP window smaller than this cannot fill the link: For the Session 10 defaults, and one-way delay give and . ### Transmission and propagation delay where $L$ is packet size in bits, $B$ link rate, $d$ distance and $v$ signal speed (about in copper or fibre). ### Constant bit rate traffic An OnOff application with packet size $L$ bytes and rate $R$ bit/s sends one packet every ### TCP congestion window Slow start doubles the window every RTT until the threshold; congestion avoidance adds one segment per RTT; a loss halves it (TCP NewReno): The maximum throughput of one TCP flow is bounded by ### Packet loss ## Session Summary - `adhoc_olsr.cc` listing with the Wi-Fi, mobility and OLSR parts marked as questions 8 and 9 - Position printout at 0, 10, 20, 30 s and the topology sketch inside the 100 m box - OLSR routing tables of all three nodes at 5, 15 and 30 s, and the echo lines with the per-hop delay estimate Source: https://syntax.theether.in/mcsl-223/section-1/session-4/index.mdx