Two projects, one common confusion
OMNeT++, short for Objective Modular Network Testbed in C++, is a modular, component-based simulation framework and class library, primarily built for constructing network simulators. On its own, though, OMNeT++ ships with no models for actual networking protocols — no IP stack, no HTTP, no Wi-Fi MAC layer. It is a discrete-event simulation engine and a component model, not a networking library. OMNeT++ is free for academic and non-commercial use; a commercial variant, OMNEST, is available for industry use.
That gap is filled by external model frameworks, the most widely used of which is INET. INET is an open-source model library for the OMNeT++ environment that supplies the protocols, network nodes, and connections that OMNeT++ itself does not include — from the Internet stack (TCP, UDP, IPv4, IPv6, OSPF, BGP) through wired and wireless link-layer protocols such as Ethernet, PPP, and IEEE 802.11, plus mobility models and MANET routing protocols. Several other frameworks, in turn, build on INET to target more specialized domains such as vehicular networks, peer-to-peer overlays, or LTE.
How the pieces fit together
OMNeT++ organizes a simulation around modules — the fundamental building blocks that exchange messages through gates and connections. A module’s structural description (its gates, connections, and parameters) is written in NED, OMNeT++’s own Network Description language, while its behavior is implemented in C++. Initialization files, conventionally with an .ini extension, then set parameter values for a specific simulation run, and can define ranges or multiple values to sweep across several runs automatically.
INET builds directly on that infrastructure: its models are themselves OMNeT++ modules, assembled and parameterized the same way, which means a researcher can often build a working network scenario using only INET’s existing modules and NED/INI configuration — without writing any new C++ code at all. New protocols or modified behavior require adding code under INET’s source tree, but the common case of composing existing, validated models does not.
What this split buys you
Separating the simulation engine from the protocol models has a practical payoff: OMNeT++’s core — its scheduler, its component model, its result-recording and statistics infrastructure — does not need to change when a new protocol model is added, and a protocol model contributed to INET benefits from every improvement made to the underlying engine. It also means INET is not the only option; frameworks targeting flying ad hoc networks, opportunistic networking, and other niches have been built as INET extensions specifically because INET’s existing protocol coverage did not include those use cases, rather than by forking OMNeT++ itself.
The practical downside is that a newcomer has to learn two related but distinct things at once: OMNeT++’s general simulation concepts (modules, NED, the event scheduler) and INET’s specific model set and configuration conventions. Most confusion reported by new users traces back to not realizing which of the two layers a given piece of documentation or error message belongs to.
Where to go deeper
For the simulation engine itself, see the OMNeT++ project documentation. For protocol models, node types, and mobility, INET maintains its own documentation and API reference separately, since the two projects are versioned and released independently.