OMNeT++ INET框架详览与模拟教程

4星 · 超过85%的资源需积分: 35 147 浏览量更新于2024-07-24 7 收藏 774KB PDF 举报

OMNET++框架INET用户手册是一份详细指南，专为那些想要利用OMNeT++进行网络仿真和协议开发的用户提供帮助。该手册发布于2013年10月29日，涵盖了INET框架的基础概念、安装与配置、以及其在OMNeT++中的应用。 1. **INET框架介绍**: - INET是OMNeT++的一个核心模块，它为构建复杂网络环境提供了基础架构，包括有线和无线网络的模型，如模拟网络连接的稳定性（如链路和节点故障）、IPv6地址的配置等。 - INET允许用户创建、运行和分析网络模拟，支持模拟不同类型的网络结构，如固定网络、自组网络和网络仿真。 2. **使用INET框架**: - **安装**：手册指导如何正确安装INET框架，确保所有必要的组件和技术已经准备就绪。 - **模拟流程**：从创建新项目到运行模拟，包括设置网络参数、定义节点行为和协议交互。 - **结果收集与分析**：介绍了如何收集模拟数据并对其进行深入分析，以便理解模拟性能和行为。 3. **网络节点架构**: - **概述**：这部分深入解释了节点在INET中的设计和功能，包括地址管理、通知板（用于内部通信）和接口表（存储网络连接信息）。 - **地址管理**：说明节点如何获取和处理IP地址，对于IPv6的支持尤其重要。 - **通信机制**：涉及不同层之间的通信，如协议层间通信，以及节点内部的发布/订阅通信模式。 4. **扩展与开发**: - **协议开发**：为开发者提供了关于如何在INET中设计和实现新协议的步骤，强调了模块化和可扩展性的重要性。 - **仿真工具**：探讨了如何使用packet traces（包跟踪）进行实时或离线数据分析，有助于验证和调试协议行为。通过阅读这份用户手册，用户可以深入了解如何有效地利用INET框架在OMNeT++环境中进行网络仿真研究，从基础安装到高级功能的使用，都能找到相应的指导。无论是进行科研还是教学，这份文档都是一个宝贵的参考资料。

OMNeT++ Manual – Using the INET Framework

OMNeT++ Manual – Node Architecture

Chapter 3

Node Architecture

3.1 Overview

This chapter describes the architecture of INET host and router models.

Hosts and routers in the INET Framework are OMNeT++ compound modules that are com-

posed of the following ingredients:

• Interface Table (InterfaceTable). This module contains the table of network interfaces

(eth0, wlan0, etc) in the host. Interfaces are registered dynamically during the initial-

ization phase by modules that represent network interface cards (NICs). Other modules

access interface information via a C++ class interface.

• Routing Table (RoutingTable). This module contains the IPv4 routing table. It is also

accessed from other via a C++ interface. The interface contains member functions for

adding, removing, enumerating and looking up routes, and ﬁnding the best matching

route for a given destination IP address. The IP module calls uses the latter function for

routing packets, and routing protocols such as OSPF or BGP call the route manipulation

methods to add and manage discovered routes. For IPv6 simulations, RoutingTable is

replaced (or co-exists) with a RoutingTable6 module; and for Mobile IPv6 simulations

(xMIPv6 project [TODO]), possibly with a BindingCache module as well.

• Notiﬁcation Board (NotificationBoard). This module makes it possible for several

modules to communicate in a publish-subscribe manner. Notiﬁcations include change

notiﬁcations (“routing table changed”) and state changes (“radio became idle”).

• Mobility module. In simulations involving node mobility, this module is responsible for

moving around the node in the simulated “playground.” A mobility module is also needed

for wireless simulations even if the node is stationery, because the mobility module stores

the node’s location, needed to compute wireless transmissions. Different mobility models

(Random Walk, etc.) are supported via different module types, and many host models

deﬁne their mobility submodules with parametric type so that the mobility model can be

changed in the conﬁguration ("mobility: <mobilityType> like IMobility").

• NICs. Network interfaces are usually compound modules themselves, composed of a

queue and a MAC module (and in the case of wireless NICs, a radio module or mod-

ules). Examples are PPPInterface, EthernetInterface, and WLAN interfaces such as

Ieee80211NicSTA. The queue submodule stores packets waiting for transmission, and

OMNeT++ Manual – Node Architecture

it is usually deﬁned as having parametric type as it has multiple implementations to

accomodate different needs (DropTailQueue, REDQueue, DropTailQoSQueue, etc.) Most

MACs also have an internal queue to allow operation without an external queue module,

the advantage being smaller overhead. The NIC’s entry in the host’s InterfaceTable is

usually registered by the MAC module at the beginning of the simulation.

• Network layer. Modules that represent protocols of the network layer are usually

grouped into a compound module: NetworkLayer for IP, and NetworkLayer6 for IPv6.

NetworkLayer contains the modules IP, ARP, ICMP and ErrorHandling. The IP mod-

ule performs IP encapsulation/decapsulation and routing of datagrams; for the latter it

accesses the C++ function call interface of the RoutingTable. Packet forwarding can be

turned on/off via a module parameter. The ARP module is put into the path of packets

leaving the network layer towards the NICs, and performs address resolution for inter-

faces that need it (e.g. Ethernet). ICMP deals with sending and receiving ICMP packets.

The ErrorHandling module receives and logs ICMP error replies. The IPv6 network

layer, NetworkLayer6 contains the modules IPv6, ICMPv6, IPv6NeighbourDiscovery

and IPv6ErrorHandling. For Mobile IPv6 simulations (xMIPv6 project [TODO]), Net-

workLayer6 is extended with further modules.

• Transport layer protocols. Transport protocols are represented by modules connected

to the network layer; currently TCP, UDP and SCTP are supported. TCP has several

implementations: TCP is the OMNeT++ native implementation; the TCP_lwip module

wraps the lwIP TCP stack [TODO]; and the TCP_NSC module wraps the Network Sim-

ulation Cradle library [TODO]. For this reason, the tcp submodule is usually deﬁned

with a parametric submodule type ("tcp: <tcpType> like ITCP"). UDP and SCTP

are implemented by the UDP and SCTP modules, respectively.

• Applications. Application modules typically connect to TCP and/or UDP, and model the

user behavior as well as the application program (e.g. browser) and application layer

protocol (e.g. HTTP). For convenience, StandardHost supports any number of UDP, TCP

and SCTP applications, their types being parametric ("tcpApp[numTcpApps]: <tc-

pAppType> like TCPApp; udpApp[numUdpApps]: <udpAppType> like UDPApp;

..."). This way the user can conﬁgure applications entirely from omnetpp.ini, and

does not need to write a new NED ﬁle every time different applications are needed in a

host model. Application modules are typically not present in router models.

• Routing protocols. Router models typically contain modules that implement routing

protocols such as OSPF or BGP. These modules are connected to the TCP and/or the

UDP module, and manipulate routes in the RoutingTable module via C++ function

calls.

• MPLS modules. Additional modules are needed for MPLS simulations. The MPLS module

is placed between the network layer and NICs, and implements label switching. MPLS

requires a LIB module (Label Information Base) to be present in the router which it

accesses via C++ function calls. MPLS control protocol implementations (e.g. the RSVP

module) manage the information in LIB via C++ calls.

• Relay unit. Ethernet (and possibly other) switch models may contain a relay unit, which

switches frames among Ethernet (and other IEEE 802) NICs. Concrete relay unit types

include MACRelayUnitPP and MACRelayUnitNP, which differ in their performance mod-

els.

• Battery module. INET extensions uses for wireless sensor networks (WSNs) may add

a battery module to the node model. The battery module would keep track of energy

consumption. A battery module is provided e.g. by the INETMANET project.

OMNeT++ Manual – Node Architecture

The StandardHost and Router predeﬁned NED types are only one possible example of host/router

models, and they do not contain all the above components; for speciﬁc simulations it is a per-

fectly valid approach to create custom node models.

Most modules are optional, i.e. can be left out of hosts or other node models when not needed

in the given scenario. For example, switch models do not need a network layer, a routing table

or interface table; it may need a notiﬁcation board though. Some NICs (e.g. EtherMAC) can be

used without and interface table and queue models as well.

The notiﬁcation board (NotificationBoard) and the interface table (InterfaceTable) will

be described later in this chapter. Other modules are covered in later chapters, i.e. Rout-

ingTable in the IPv4 chapter.

3.2 Addresses

The INET Framework uses a number of C++ classes to represent various addresses in the

network. These classes support initialization and assignment from binary and string rep-

resentation of the address, and accessing the address in both forms. (Storage is in binary

form). They also support the "unspeciﬁed" special value (and the isUnspecified() method)

that corresponds to the all-zeros address.

• MACAddress represents a 48-bit IEEE 802 MAC address. The textual notation it under-

stands and produces is hex string.

• IPAddress represents a 32-bit IPv4 address. It can parse and produce textual represen-

tations in the "dotted decimal" syntax.

• IPv6Address represents a 128-bit IPv6 address. It can parse and produce address

strings in the canonical (RFC 3513) syntax.

• IPvXAddress is conceptually a union of a IPAddress and IPv6Address: an instance

stores either an IPv4 address or an IPv6 address. IPvXAddress is mainly used in the

transport layer and above to abstract away network addresses. It can be assigned from

both IPAddress and IPv6Address, and can also parse string representations of both.

The isIPv6(), get4() and get6() methods can be used to access the value.

TODO: Resolving addresses with IPAddressResolver

3.3 The Notiﬁcation Board

The NotificationBoard module allows publish-subscribe communication among modules

within a host. Using NotificationBoard, modules can notify each other about events

such as routing table changes, interface status changes (up/down), interface conﬁguration

changes, wireless handovers, changes in the state of the wireless channel, mobile node posi-

tion changes, etc. NotificationBoard acts as a intermediary between the module where the

events occur and modules which are interested in learning about those events.

NotificationBoard has exactly one instance within a host or router model, and it is accessed

via direct C++ method calls (not message exchange). Modules can subscribe to categories of

changes (e.g. “routing table changed” or “radio channel became empty”). When such a change

occurs, the corresponding module (e.g. the RoutingTable or the physical layer module) will

OMNeT++ Manual – Node Architecture

let NotificationBoard know, and it will disseminate this information to all interested mod-

ules.

Notiﬁcation events are grouped into categories. Examples of categories are:

NF_HOSTPOSITION_UPDATED, NF_RADIOSTATE_CHANGED, NF_PP_TX_BEGIN, NF_PP_TX_END,

NF_IPv4_ROUTE_ADDED, NF_BEACON_LOST, NF_NODE_FAILURE, NF_NODE_RECOVERY, etc. Each

category is identiﬁed by an integer (right now it’s assigned in the source code via an enum, in

the future we’ll convert to dynamic category registration).

To trigger a notiﬁcation, the client must obtain a pointer to the NotificationBoard of the

given host or router (explained later), and call its fireChangeNotification() method. The

notiﬁcation will be delivered to all subscribed clients immediately, inside the fireChangeNo-

tification() call.

Clients that wish to receive notiﬁcations should implement (subclass from) the INotifiable

interface, obtain a pointer to the NotificationBoard, and subscribe to the categories they

are interested in by calling the subscribe() method of the NotificationBoard. Notiﬁcations

will be delivered to the receiveChangeNotification() method of the client (redeﬁned from

INotifiable).

In cases when the category itself (an int) does not carry enough information about the no-

tiﬁcation event, one can pass additional information in a data class. There is no restriction

on what the data class may contain, except that it has to be subclassed from cObject, and

of course producers and consumers of notiﬁcations should agree on its contents. If no extra

info is needed, one can pass a NULL pointer in the fireChangeNotification() method.

A module which implements INotifiable looks like this:

class Foo : public cSimpleModule, public INotifiable {

...

virtual void receiveChangeNotification(int category, const cObject

details) {..}

...

};

Note: cObject was called cPolymorphic in earlier versions of OMNeT++. You may occasion-

ally still see the latter name in source code; it is an alias (typedef) to cObject.

Obtaining a pointer to the NotificationBoard module of that host/router:

NotificationBoard

nb; // this is best made a module class member

nb = NotificationBoardAccess().get(); // best done in initialize()

TODO how to ﬁre a notiﬁcation

3.4 The Interface Table

The InterfaceTable module holds one of the key data structures in the INET Framework:

information about the network interfaces in the host. The interface table module does not

send or receive messages; other modules access it using standard C++ member function calls.

3.4.1 Accessing the Interface Table

If a module wants to work with the interface table, ﬁrst it needs to obtain a pointer to it. This

can be done with the help of the InterfaceTableAccess utility class:

IInterfaceTable

ift = InterfaceTableAccess().get();

剩余158页未读，继续阅读

y8531846yyy

粉丝: 0
资源: 1

OMNeT++ INET框架详览与模拟教程

omnet++inet

OMNET++中文使用手册

inet4.0传感网仿真框架

OMNeT++&INET&BUAANetworkExperimentTutorial 说明手册1

omnet++中inet手册

omnet++中文手册

omnet++中文使用手册

omnet++ 中文 使用手册

omnet.rar_omnet_omnet++

OMNet++框架详解与使用指南

最新资源

omnet++ 中文使用手册