June 28, 2018
With the new INET 4.0 release, the development of the old INET 3.x branch is stopped. Users are strongly encouraged to use the new INET 4.0 version for new projects and also for migrating existing projects. Admittably, migration is not trivial, but there’s an ‘INET 4.0 Migration Guide’ to help with the task under the ‘doc/misc’ folder.
The main changes of the new INET 4.0 major stable release are:
Packet API
The INET Packet API has been completely redesigned to supports efficient construction, sharing, duplication, encapsulation, aggregation, fragmentation, and serialization of packets.
The new Packet API also adds many other useful features such as a detailed packet printer, a packet dissector, a packet filter based on packet data, packet tags for cross-layer communication, region tags for attaching metadata to packet data, and queueing and buffering packet data.
The new Packet API also makes implementing communication protocols easier. The resulting code looks more similar to the real world implementation. Supporting emulation is pretty much trivial when implementing communication protocols.
For more details on how to use the new Packet API, see the ‘INET Developer’s Guide’.
Network node architecture
The internal structure of network nodes has been changed considerably. With the new architecture, applications can directly talk to any protocol down to the link layer, and protocols don’t have to deal with dispatching packets and commands to other protocols. Cross-layer communication is directly supported in both downward and upward directions.
For more details on how to use the new architecture, see the ‘INET User’s Guide’.
Documentation
The somewhat outdated ‘INET Framework for OMNeT++ Manual’ has been reworked and split into the ‘INET User’s Guide’ and ‘INET Developer’s Guide’. Several new detailed showcases have been added and many have been updated, they are available on the INET website.
The highlights of this release since the last development release are:
Socket API
The Socket API has been redesigned and uniformized. All sockets can be used with similar callback interfaces. All callback functions receive the socket object as a parameter to allow handling multiple sockets concurrently.
New raw Ipv4Socket and Ipv6Socket classes have been added to directly access the IPv4 and IPv6 protocols from applications.
Module type parameters
All string NED module parameters, which were used to specify submodule types, have been replaced with the standard OMNeT++ typename parameter. This reduces the confusion caused by having two different configuration options for the same task. The typename parameter is also simpler and more generic in the sense that it allows configuring the module type for submodule vector elements.
The replacement of the EthernetInterface queueType and the Ieee80211Interface agentType parameters requires the applications which use them to be updated. The queueType parameter had effect on the dataQueueType of the EtherQosQueue, which is no longer true. The agentType parameter depended on the mgmtType parameter, which is also no longer true. These parameters must be set separately.
NED units
With the new OMNeT++ 5.4 release, INET supports the automatic conversion of non-linear units such as dBm, dBW to W, dB to ratio, etc. All 0/0 and +-1/0 parameter value assignments have been replaced with nan and +-inf respectively.
Various renames
Renamed several modules, submodules, classes, interfaces, etc. to be consistent with the INET naming conventions:
NextHopDatagram class -> NextHopForwardingHeader
Packet error representation
The physical layer error models have been extended with a corruption mode parameter. The available corruption modes are: packet, chunk, byte, or bit level. The parameter determines on what level the error model introduces errors into a packet.
In many protocols, various corruption modes don’t lead to different outcome. Nevertheless, this change allows implementing IEEE 802.11 A-MPDU aggregation with support to only dropping the individual subframes which are received incorrectly.
IEEE 802.11
Thanks to Alfonso Ariza Quintana, the 802.11/ac (VHT PHY) modes have been added to physical layer. Futhermore, the necessary 5GHz bands with 20, 40, 80, and 160 Mhz bandwidth have also been added.
The 802.11 mode lookup mechanism has been extended with bandwidth and number of spatial streams parameters, and the mechanism has also been relaxed to allow specifying more already supported bitrates (e.g. 86.7 Mbps with 0.1 Mbps precision).
Fixed bug when a packet was received from another Ap and sent up incorrectly. Fixed ACK frame duration bug reported by Raphael Elsner. Fixed exploded frame transmitter address in MsduDeaggregation. Fixed length field wrap around for large packets. Fixed center frequency calculation in Ieee80211ArithmeticalBand.
Emulation
The whole emulation support, including the ExternalInterface compound module, the Ext simple module, and the corresponding cSocketRtScheduler have been redesigned and heavily refactored. The new C++ scheduler class is called RealTimeScheduler and it is completely independent of the external interfaces.
The new scheduler still provides real time simulation execution, but it also allows for using the POSIX select mechanism to support I/O operations with file descriptors. The external interface hooks into this mechanism to read raw packets via PCAP. Futhermore, the new external interface implementation uses dedicated raw sockets to send packets.
Lifecycle and scenario management
The LifecycleController module has been removed because the module did not have and is not expected to have any parameters in the future. Therefore the LifecycleController module is no longer needed in the network for the lifecycle operations to work. The corresponding LifecycleController C++ class with the actual functionality remains there.
The ScenarioManager scripting has been extended with the following shortcuts for the lifecycle operations:
RIP
Thanks to the contributions of Mani Amoozadeh the RIP protocol has been refactored to store the protocol specific route data in the routing table instead of an internal data structure. The protocol has also been extended with new hold-down timer and triggered update parameters.
Fixed sending updates on interface which is down.
Other notable changes
The Ethernet model has been extended with 200 Gbit and 400 Gbit modes.
The antenna directional selectivity computation in wireless medium analog models has been fixed.
Several missing protocol dissectors and protocol printers have been added.
All protocol specific header serializers have been moved to the folder of their respective communication protocol.
In order to suppor more recent OSG Earth versions, the osgEarth::ObjectLocatorNode has been replaced with GeoTransform and osg::PositionAttitudeTransform.
Download INET-4.0.0 now.
INET Framework