OMNeT++ based OPTIMIX system simulator
We are proud to introduce  which a system simulator developed on the OMNeT++ Framework by the OPTIMIX partners.
In order to validate OPTIMIX architecture we have selected a generic frame-work built on the OMNeT++ simulation tool and we use as far as possible only the OMNeT++ most generic features (e.g. discrete event scheduling and simple and easily re-usable C/C++ code implementation) in order to offer for each function and layer the degree of refinement needed for our overall end-to-end optimisation.
Figure 1. OPTIMIX architecture
Following the architecture presented in Figure 1, the corresponding simulation implementation has been defined: the complete protocol stack from the application to the physical layer is simulated, and the real bits and bytes of the messages transferred on the radio channel are exchanged. Exploiting the OMNeT++ framework, the communication between the different modules and nodes of the system is performed by means of messages which, as much as possible, use as reference format the standard ones. Typically, for data, the IETF datagrams (IPv6, DCCP, UDP-Lite, RTP,...) for upper layers and standard radio packets or lower layers are considered, while for signalling, existing specifications (e.g. RTSP, RTCP, ICMP,...) are studied solutions.
Application and session layers
At the application layer, the source coding module receives a request for a specific content driven by a RTSP client-server approach. The transmission is thus charactherized
by session initiation and session maintenance phases. On the one hand, a link (called
session) between the server and the terminals for the exchange of the parameters of
the audio and video streams is set up and destroyed. The link setup, the parameter
exchange, and the link destruction are achieved by RTSP handshaking that consists
of standard DESCRIBE, SETUP, PLAY, and TEARDOWN messages. On the other
hand, the established session has to be kept up and running while transmission is in
progress. Session maintenance is carried out by periodically transmitting RTP control
protocol messages between the server and terminal session layers. RTCP protocol is
not only used as a means for session maintenance, but it is also used for supplying the
terminal side with synchronization information, and for monitoring the status of the
The requested content may be both raw YUV 4:2:0 video data, which is encoded during the simulation, or pre-coded video data. The first approach is used especially for H.264/AVC, since the data-rate can be adapted after the encoding step with more difficulties. The alternative approach with a pre-coded video file is considered valid for SVC, where the data-rate (and also the image size and frame rate) can be adapted in the compressed domain by simply removing packets (i.e., NAL units) from the bitstream. The raw video data is encoded or the pre-coded file is selected following the indications provided by the application controller.
At the receiver side, the received encoded stream is thus decoded and displayed. In the first simulator version, audio codecs (i.e. AAC+ and AMR-WB+) are not present, and they will be introduced in the next release of the simulator.
Application and session layers parameters
Transport, network and packetisation
The transport layer module implements various transport protocols. UDP-Lite and
DCCP are used for the transport of real-time data and their impact on the video quality
will be compared. Over these transport protocols, the RTP protocol is considered,
with optionally its specific secure profile that provides ciphering and authentication in
unicast and multicast modes. Both RTP and RTSP implementations include the new
features of the OPTIMIX system specifications
Control messages, usually transmitted in real life situations by reliable transport
protocols as TCP, are in OPTIMIX transmitted using UDP, since TCP retransmissions
are expected to be useless due to the inevitable introduced delay.
The advanced mechanisms introduced and designed to allow users mobility and
based on the Host Identity Protocol (HIP) are currently only partially implemented,
as this is an extremely challenging task. Nevertheless, the simulation will contain HIP
support: basic/limited support will be provided which is enough to demonstrate the effect of mobility. For comparison purposes, the usage of the HIP module can be rendered
The IP layer module in the simulation chain encapsulates downstream packets received from the transport layer into IPv6 packets and, in the opposite direction, decapsulates IPv6 packets and sends them to the appropriate transport layer module. The impact of an IPv6 wired network, corresponding to a LAN or Internet crossing is modelled with a network module. The purpose of this module is to resemble the wired trunk of the telecommunication infrastructure to generate the effects (mostly packet loss and delay) of crossing multiple IP routers on the data transmission. The corresponding loss and delay parameters are established via analytical modelling generating artificially packet losses and delays based on statistical distributions (mean value, variance, etc.) from measurements of the real world environment (i.e. the Public Internet). The point to multipoint transmission with multicast functionality is emulated by a routing function inside the IP Network Module that realises the replication of the data flow addressed to the different users when needed.
Transport and network parameters
The header compression module introduced in the simulator receives network layer
packets and produces packets with a compressed header. It is integrated in the simulator
above the MAC layer in both base station and mobile users. This module, in addition
to the RTP/UDP/IP header compression specified in the standard, implements
the header compression for DCCP packets. The three operation modes (Bidirectional
Reliable Mode, Bidirectional Optimistic Mode, Unidirectional Mode) of RoHC are
The data link layer implementation is technology-specific. In the simulator basic DLL services specified in two standards of interest for OPTIMIX (i.e., IEEE 802.11g and IEEE 802.16e) are introduced, with amendments to allow end-to-end optimisation. One of the key additional techniques is a partial checksum, using only DLL headers in the checksum calculation, which allows to pass a corrupted payload data to higher layers for further processing. In the future version of the simulator, a support for prioritization using buffers above the actual DLL will be added. The buffers are used to prioritize video packets (e.g. layers of SVC video) in the access point destined to the different users.
The PHY layer module receives data packets from the DLL and arranges them for the transmission over the radio channel. At the receiver side, it has the dual role of demodulating and decoding the received symbols before passing the correspondent packets to the upper layers. The PHY module is composed of several submodules, i.e. channel co-decoder, MIMO-OFDM mo-demodulator and physical frame de-assembler unit. The possibility to choose between various channel coding and MIMO-OFDM modulation schemes permits to evaluate the results of the end-to-end optimisation process addressed in the project in case of different radio communication scenarios, e.g. WiMAX or 802.11a/g/n. Currently, the channel co-decoder includes Rate Compatible Punctured convolutional (RCPC) codes and Rate Compatible Punctured IRA LDPC codes. OFDM modulation is supported, as well as multiple transmitting and receiving antennas. More complex space-time coding (STC) and linear beamforming techniques are also implemented.
Finally, the transmission is done over a frequency-selective channel sub-module which introduces the typical radio transmission impairments met in wideband mobile communications (e.g. different Rayleigh fading for the various sub-carriers, log-normal slow fading and additive thermal noise).
Radio access parameters
Controllers and observers
The application controller, using as input encoding configuration and wireless network conditions, selects a set of encoding parameters which are then transmitted to the encoder module where they are used or to encode a raw stream in function of the user needs or to select the most suited among pre-coded streams. If applicable, the controller will also decide on the level of protection introduced in the higher layers (with application processing, RTP FEC or PECC modules). For multicast video transmissions, the encoding parameters should be selected taking into account different feedbacks received by different users. How to weight the different information which will be subject of further studies.
The TRG implementation is coupled with the IEEE 802.21 implementation: the
Media Independent Handover Function (MIHF) module provides a few of the main
services specified in IEEE 802.21. MIHF provides events to MIH User (which is a
submodule inside theMobile Observer module) related to current link conditions. These
events are initiated by the MAC layer and include timely values for several MAC and
PHY parameters. MIHU also converts the IEEE 802.21 events to TRG triggers. MIHF
on MSs and BSs can register with each other in order to be able to subscribe and receive
remote events in a fast and lightweight way over the Layer-2 communication. Also
possibility to use IEEE 802.21 command service is considered in the implementation.
The IEEE 802.21 events are used not only by the MAC to make the traffic more
effective but also by other layers interested in the current link conditions.
Controllers and observers parameters