A Discrete-Event Network Simulator
API
Loading...
Searching...
No Matches
mesh.h
Go to the documentation of this file.
1/*
2 * Copyright (c) 2009 IITP RAS
3 *
4 * SPDX-License-Identifier: GPL-2.0-only
5 *
6 * Authors: Kirill Andreev <andreev@itp.ru>
7 * Aleksander Safonov <safa@iitp.ru>
8 * Pavel Boyko <boyko@iitp.ru>
9 *
10 * This is top level mesh module description
11 */
12
13/**
14 * \defgroup mesh Mesh Device
15 *
16 * \brief MAC-layer mobile mesh networking.
17 * \section MeshOverview Overview of Layer-2 Mesh networking protocols
18 *
19 * The main goal of this module is to provide MAC-layer routing functionality.
20
21 * The main part of MAC-layer routing model is specific type of a network device --
22 * ns3::MeshPointDevice. Being an interface to upper-layer protocols, it provides routing
23 functionality
24 * hidden from upper-layer protocols, by means of ns3::MeshL2RoutingProtocol.
25 *
26 * Our model supports stations with multiple network devices handled by a single
27 * MAC-layer routing protocol. So, ns3::MeshPointDevice serves as an umbrella to multiple
28 * network devices ("interfaces") working under the same MAC-layer routing protocol.
29 *
30 * Network devices may be of different types, each with a specific medium access method.
31 * So ns3::MeshL2RoutingProtocol consists of two parts: the one independent from the network device
32 type,
33 * which we refer to as a routing protocol, and the other one depended on the network device type
34 which
35 * we refer to as a plug-in to the routing protocol.
36 *
37 * One can imagine a MAC-layer routing as a two-tier model. ns3::MeshL2RoutingProtocol and
38 ns3::MeshPointDevice
39 * belong to the upper tier. The task of ns3::MeshPointDevice is to send, receive, and forward
40 frames,
41 * while the task of ns3::MeshL2RoutingProtocol is to resolve routes and keep frames waiting for
42 route resolution.
43 * This functionality is independent from the types of underlying network devices ("interfaces").
44 *
45 * The lower tier implements the part of MAC-layer routing, specific for underlying network devices
46 * and their medium access control methods. For example, HWMP routing protocol in IEEE802.11s
47 * uses its own specific management frames.
48 *
49 * At present, two routing protocols are implemented in this module:
50 * - HWMP (default routing protocol for IEEE802.11s standard) + Peer management protocol
51 * (also described in 802.11s standard draft) which is required by HWMP to manage peer links
52 * (it works like association mechanism in IEEE802.11).
53 * - FLAME (Forwarding LAyer for MEshing).
54
55 * While HWMP only works with 802.11-MAC, FLAME works with all types of network devices, which
56 support
57 * 48-bit MAC-addressing scheme.
58 *
59 * \subsection Architecture Architecture of MAC-layer routing stack
60 * As already mentioned, MAC-layer routing consists of two tiers.
61 * An ns3::MeshPointDevice which forwards frames by using an attached ns3::MeshL2RoutingProtocol
62 forms
63 * the upper tier. The interface between ns3::MeshPointDevice and the upper-layer protocols is
64 inherited
65 * from ns3::NetDevice class. The ns3::MeshPointDevice interacts with ns3::MeshL2RoutingProtocol as
66 follows:
67 * ns3::MeshPointDevice gives to ns3::MeshL2RoutingProtocol a frame with the source and destination
68 addresses,
69 * the network device index which the frame is received from, and a callback to be executed when the
70 route is found.
71 * The callback is needed because all routing queues are implemented inside
72 ns3::MeshL2RoutingProtocol.
73 * When the route is resolved, ns3::MeshL2RoutingProtocol returns the frame back to
74 ns3::MeshPointDevice with the
75 * network device index which the packet shall be sent to. All additional routing information is
76 stored inside
77 * the frame by means of tags. In the end, when all these routines are done, the frame goes to the
78 lower tier.
79
80 * The lower tier is responsible for filling MAC-specific headers. At present, we have only
81 implemented the
82 * lower tier which is specific for ns3::WifiNetDevice. This tier is implemented as two base
83 classes:
84 * ns3::MeshWifiInterfaceMac and ns3::MeshWifiInterfaceMacPlugin. The former is a new kind of
85 WifiMac. If beacon
86 * generation is enabled or disabled, it implements IEEE802.11s mesh functionality or a simple ad
87 hoc functionality
88 * of the MAC-high part of the WiFi model, respectively. The latter is a plug-in to L2Routing
89 protocol.
90 * It handles all outgoing and incoming frames, fills headers and make decisions to drop a frame or
91 not. Also, it
92 * adds information elements to beacons specific to given L2Routing protocol, if needed.
93 * \image html MeshArchitecture.png "Overview of the Mesh MAC-layer routing system"
94 *
95 * \subsection NewProtocol Adding a new protocol
96 * This module requires all the network devices operate with ns3::Mac48Address addressing scheme.
97 *
98 * To add a new L2Routing protocol, one needs to define the following:
99 * - Write an upper part of the protocol inherited from ns3::MeshL2Routing.
100 * - If the protocol works only with 802.11 MAC -- write a plug-in inherited from
101 ns3::MeshWifiInterfaceMacPlugin
102 * - If the protocol works with other types of network devices -- write your own plug-in
103 (interface for
104 * communication with other types of network devices is not implemented).
105 *
106 * When you implement a L2Routing protocol, remember that when you are at L2Routing tier,
107 * you work with a frame without an LLC header, and when you are at plug-in tier using
108 * ns3::MeshWifiInterfaceMacPlugin, an LLC header is already attached (by WifiNetDevice)
109 *
110 * \attention Note, when you use ns3::MeshWifiInterfaceMac, multiple plug-ins may be installed.
111 *
112 * \subsection Statistics
113 * Each L2Routing protocol has a structure to capture statistics, Report and ResetStats methods.
114 * This gives an opportunity to collect statistic to an *.xml file periodically.
115 */