From ICT-OPTIMIX website
Jump to: navigation, search

OMNeT++ based OPTIMIX system simulator


Optimix sim logo.PNG


We are proud to introduce [1] which a system simulator developed on the OMNeT++ Framework by the OPTIMIX partners.


OPTIMIXSim description

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.

Architecture yearII.PNG

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 communication link.

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 optional.

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

Radio access

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 developed.

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

Download

The simulator is currently available upon request: please send us an email to:Contact.png