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