Piotr Gaj

Michał Sawicki
Grażyna Suchacka
Andrzej Kwiecień (Eds.)

Communications in Computer and Information Science 860

Computer Networks
25th International Conference, CN 2018
Gliwice, Poland, June 19–22, 2018
Proceedings

123
Communications
in Computer and Information Science 860
Commenced Publication in 2007
Founding and Former Series Editors:
Alfredo Cuzzocrea, Xiaoyong Du, Orhun Kara, Ting Liu, Dominik Ślęzak,
and Xiaokang Yang

Editorial Board
Simone Diniz Junqueira Barbosa
Pontifical Catholic University of Rio de Janeiro (PUC-Rio),
Rio de Janeiro, Brazil
Phoebe Chen
La Trobe University, Melbourne, Australia
Joaquim Filipe
Polytechnic Institute of Setúbal, Setúbal, Portugal
Igor Kotenko
St. Petersburg Institute for Informatics and Automation of the Russian
Academy of Sciences, St. Petersburg, Russia
Krishna M. Sivalingam
Indian Institute of Technology Madras, Chennai, India
Takashi Washio
Osaka University, Osaka, Japan
Junsong Yuan
University at Buffalo, The State University of New York, Buffalo, USA
Lizhu Zhou
Tsinghua University, Beijing, China
More information about this series at http://www.springer.com/series/7899
Piotr Gaj Michał Sawicki
•

Grażyna Suchacka Andrzej Kwiecień (Eds.)

•

Computer Networks
25th International Conference, CN 2018
Gliwice, Poland, June 19–22, 2018
Proceedings

123
Editors
Piotr Gaj Grażyna Suchacka
Institute of Informatics University of Opole
Silesian University of Technology Opole
Gliwice Poland
Poland
Andrzej Kwiecień
Michał Sawicki Silesian University of Technology
Silesian University of Technology Gliwice
Gliwice Poland
Poland

ISSN 1865-0929 ISSN 1865-0937 (electronic)

Communications in Computer and Information Science
ISBN 978-3-319-92458-8 ISBN 978-3-319-92459-5 (eBook)
https://doi.org/10.1007/978-3-319-92459-5

Library of Congress Control Number: 2018944399

© Springer International Publishing AG, part of Springer Nature 2018

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, express or implied, with respect to the material contained herein or for any errors or
omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in
published maps and institutional affiliations.

Printed on acid-free paper

This Springer imprint is published by the registered company Springer International Publishing AG
part of Springer Nature
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
 Preface

In 1993, our dear colleague, prof. Andrzej Grzywak, was thinking about how to
integrate the Polish academic community involved in computer networks research and
development. On the one hand, it was a time of great progress in network usage and
application, both in local and wide area network types. On the other hand, at this time
the public Internet was just beginning; it was just started as an open and global network
and its range and availability were incomparable to those of today. Therefore, the
common access to knowledge dissemination and lookups was limited. Moreover, the
number of scientific journals related to computer networks domains and their quality
were not as high as today and access to them was also imperfect. Thus, there was a
need to create an opportunity to exchange knowledge and experiences between people
involved in this area, employed in various business and academic institutions. As a
result, the domestic science conference on Computer Networks (CN) was initiated as an
annual event dedicated to the academic and industry communities in Poland.
The conference was established at the Faculty of Automatic Control, Electronics and
Computer Science at the Silesian University of Technology in Gliwice and the first five
editions of the conference took place in the halls of this faculty. The cycle of these
initial editions was approximately annual but not strictly constant. It depended on
various conditions, e.g., the fact that the event was new and not widely known. From
year to year, the conference grew in popularity and recognition and its range gradually
evolved from local to nationwide. In 1999, the conference was organized as an external
event for the first time. Each of the next editions was organized outside the university.
From the very beginning, for many years, Prof. Andrzej Grzywak together with
Ms. Halina Węgrzyn worked actively on the conference organization, becoming the main
stem of the Organizing Committee. In 2007, Prof. Grzywak retired and Dr. Piotr Gaj
became the chair of the Organizing Committee while Prof. Andrzejń Kwiecie became the
head of the Technical Program Committee. In 2008, the form of the conference was
transformed from domestic into international with English as the official language. This
gave guests from abroad an opportunity to participate in the CN conference.
In 2009, the conference proceedings were published in Springer’s CCIS series for
the first time, as volume 39. Since then, the conference proceedings have been pub-
lished in this series each year.
For many years, among the co-organizers, technical co-sponsors, and partners has
been the Section of Computer Networks and Distributed Systems belonging to the
Committee on Informatics of the Polish Academy of Sciences (PAN), IEEE Poland
Section, and the International Network for Engineering Education and Research
(iNEER).
VI Preface

25th International Science Conference Computer Networks

This year, the 25th edition of the conference took place. Hence, the scientific
conference on Computer Networks has been present on the conference market for a
quarter of a century, giving attendees a chance to meet people, discuss valid and
important issues, as well as disseminate research results in the proceedings published in
a significant and recognized book series. Over the past 25 years of the conference’s
history, all important topics related to computer network development have been dis-
cussed at the conference and major breakthroughs in this area have been deliberated.
Thus, we believe that the event has had a significant contribution to the global pool of
achievements in this domain.
Computer networks are still the main means for transferring data among distributed
nodes of all computer systems currently available. Thus, this area of research and
applications is up to date and very important for current industrial and social activities,
as well as for the needs of the future. Computer network-related techniques and
technologies are not spectacular at their base but without them many spectacular ser-
vices would be unavailable.
For this jubilee edition of the CN conference, almost 90 papers were submitted. To
maintain the high quality of the conference proceedings, only 34 carefully selected
papers have been published in this book. Each paper was reviewed by three inde-
pendent reviewers in a double-blind process. Each of four chapters includes highly
stimulating studies that may interest a wide readership.
– Computer Networks
This chapter contains 12 papers. They refer to general networking issues, such as
architecture design, analyzing, modeling, and programming computer networks,
issues related to networked systems, their operations and management, Internet
networks, cooperative and cognitive networks, issues related to quantum technol-
ogy, as well as multimedia networks.
– Teleinformatics and Telecommunications
This chapter contains five papers related to communication architecture, wireless
systems, sensor and mobile networking, and isochronous communication.
 Preface VII

– Queueing Theory
This chapter contains eight papers. The papers refer to the theory of queues and
queuing networks, as well as to network modelling and architecture design from the
queueing theory point of view.
– Cybersecurity and Quality of Service
This chapter contains nine papers that refer to cybersecurity issues in computer
networks, as well as topics related to the quality of service domain and related
innovative solutions.
On behalf of the Program and Organizing Committee of the CN Conference, we
would like to express our gratitude to all authors for sharing their research results and
for their assistance in producing this volume, which we believe is a reliable reference in
the computer networks domain.
We also want to thank the members of the Technical Program Committee and all
reviewers for their involvement and participation in the reviewing process.
If you would like to help us make the CN conference more attractive and interesting,
please send us your opinions and propositions at [email protected].

April 2018 Piotr Gaj

Grażyna Suchacka
Michał Sawicki
Andrzej Kwiecień
 Organization

CN 2018 was organized by the Institute of Informatics of the Faculty of Automatic

Control, Electronics and Computer Science, Silesian University of Technology
(SUT) and supported by the Committee on Informatics of the Polish Academy of
Sciences (PAN), the Section of Computer Networks and Distributed Systems in
technical co-operation with the IEEE and consulting support of the iNEER
organization.
His Magnificence Rector of Silesia University of Technology, the Mayor of Gliwice
and Mayor of Katowice were the honorary patrons.
The official sponsor and partner of the CN 2018 conference was Wasko S.A.
The companies 3Soft S.A. and Bombardier Inc. were conference partners.

Executive Committee

All members of the Executive Committee are from the Silesian University of
Technology, Poland.

Honorary Member Halina Węgrzyn

Organizing Chair Piotr Gaj
Technical Volume Editor Michał Sawicki
Technical Support Aleksander Cisek
Technical Support Jacek Stój
Office Małgorzata Gładysz
Web Support Piotr Kuźniacki

Co-ordinators
PAN Co-ordinator Tadeusz Czachórski
IEEE PS Co-ordinator Jacek Izydorczyk
iNEER Co-ordinator Win Aung

Program Committee
Program Chair
Andrzej Kwiecień Silesian University of Technology, Poland

Honorary Members
Win Aung iNEER, USA
Adam Czornik Silesian University of Technology, Poland
Bogdan M. Wilamowski Auburn University, USA
X Organization

Technical Program Committee

Davide Adami University of Pisa, Italy
Wessam Ajib University of Quebec at Montreal, Canada
Olumide Akinwande Imperial College London, UK
Iosif Androulidakis University of Ioannina, Greece
Tülin Atmaca Institut National de Télécommunication, France
Rajiv Bagai Wichita State University, USA
Jiří Balej Mendel University in Brno, Czech Republic
Alexander Balinsky Cardiff University, UK
Zbigniew Banaszak Warsaw University of Technology, Poland
Thomas Bauschert Chemnitz University of Technology, Germany
Robert Bestak Czech Technical University in Prague, Czech Republic
Grzegorz Bocewicz Koszalin University of Technology, Poland
Leoš Bohac Czech Technical University in Prague, Czech Republic
Leszek Borzemski Wrocław University of Technology, Poland
Juan Felipe Botero Universidad de Antioquia, Colombia
Markus Bregulla University of Applied Sciences Ingolstadt, Germany
Berk Canberk Istanbul Technical University, Turkey
Amlan Chatterjee California State University, USA
Ray-Guang Cheng National University of Science and Technology,
Taiwan
Erik Chromý Slovak University of Technology, Slovakia
Yeon Ho Chung Pukyong National University, South Korea
Andrzej Chydziński Silesian University of Technology, Poland
Tadeusz Czachórski Silesian University of Technology, Poland
Dariusz Czerwiński Lublin University of Technology, Poland
Andrzej Duda INP Grenoble, France
Alexander N. Dudin Belarusian State University, Belarus
Peppino Fazio University of Calabria, Italy
Max Felser Bern University of Applied Sciences, Switzerland
Holger Flatt Fraunhofer IOSB-INA, Germany
Jean-Michel Fourneau Versailles University, France
Janusz Furtak Military University of Technology, Poland
Rosario G. Garroppo University of Pisa, Italy
Natalia Gaviria Universidad de Antioquia, Colombia
Erol Gelenbe Imperial College, UK
Roman Gielerak University of Zielona Góra, Poland
Mariusz Głąbowski Poznan University of Technology, Poland
Agustín J. González Federico Santa María Technical University, Chile
Peter Gregorius Beuth University of Applied Sciences, Germany
Sebastien Harispe IMT Mines Alés, France
Faouzi Hidoussi Corgascience Limited, Algeria
Edward Hrynkiewicz Silesian University of Technology, Poland
Zbigniew Huzar Wrocław University of Technology, Poland
Jacek Izydorczyk Silesian University of Technology, Poland
 Organization XI

Sergej Jakovlev University of Klaipeda, Lithuania

Jürgen Jasperneite Ostwestfalen-Lippe University of Applied Sciences,
Germany
Krzysztof Juszczyszyn Wrocław University of Science and Technology,
Poland
Jerzy Klamka IITiS Polish Academy of Sciences, Gliwice, Poland
Wojciech Kmiecik Wrocław University of Science and Technology,
Poland
Grzegorz Kołaczek Wrocław University of Science and Technology,
Poland
Ivan Kotuliak Slovak University of Technology in Bratislava,
Slovakia
Zbigniew Kotulski Warsaw University of Technology, Poland
Demetres D. Kouvatsos University of Bradford, UK
Stanisław Kozielski Silesian University of Technology, Poland
Henryk Krawczyk Gdańsk University of Technology, Poland
Udo R. Krieger University of Bamberg, Germany
Mirosław Kurkowski Cardinal Stefan Wyszynski University in Warsaw,
Poland
Andrzej Kwiecień Silesian University of Technology, Poland
Piotr Lech West-Pomeranian University of Technology, Poland
Ricardo Lent University of Houston, USA
Jerry Chun-Wei Lin Harbin Institute of Technology, China
Wolfgang Mahnke TE Industrial, Germany
Francesco Malandrino Politecnico di Torino, Italy
Aleksander Malinowski Bradley University, USA
Marcin Markowski Wrocław University of Science and Technology,
Poland
Przemysław Mazurek West-Pomeranian University of Technology, Poland
Agathe Merceron Beuth University of Applied Sciences, Germany
Jarosław Miszczak IITiS Polish Academy of Sciences, Poland
Vladimir Mityushev Pedagogical University of Cracow, Poland
Evsey Morozov Petrozavodsk State University, Russia
Włodzimierz Mosorow Lodz University of Technology, Poland
Sasa Mrdovic University of Sarajevo, Bosnia and Herzegovina
Mateusz Muchacki Pedagogical University of Cracow, Poland
Gianfranco Nencioni University of Stavanger, Norway
Sema F. Oktug Istanbul Technical University, Turkey
Michele Pagano University of Pisa, Italy
Nihal Pekergin University Paris-Est Creteil, France
Maciej Piechowiak University of Kazimierz Wielki in Bydgoszcz, Poland
Piotr Pikiewicz College of Business in Dabrowa Górnicza, Poland
Jacek Piskorowski West Pomeranian University of Technology, Poland
Bolesław Pochopień Silesian University of Technology, Poland
Oksana Pomorova Khmelnitsky National University, Ukraine
Sławomir Przyłucki Lublin University of Technology, Poland
XII Organization

Tomasz Rak Rzeszow University of Technology, Poland

Stefan Rass Alpen-Adria-Universität Klagenfurt, Austria
Przemysław Ryba Wrocław University of Science and Technology,
Poland
Vladimir Rykov Russian State Oil and Gas University, Russia
Wojciech Rząsa Rzeszow University of Technology, Poland
Dariusz Rzońca Rzeszow University of Technology, Poland
Alexander Schill Technische Universität Dresden, Germany
Artur Sierszeń Lodz University of Technology, Poland
Mirosław Skrzewski Silesian University of Technology, Poland
Adam Słowik Koszalin University of Technology, Poland
Pavel Smolka University of Ostrava, Poland
Tomas Sochor University of Ostrava, Czech Republic
Maciej Stasiak Poznań University of Technology, Poland
Janusz Stokłosa Poznań University of Technology, Poland
Ioannis Stylios University of the Aegean, Greece
Grażyna Suchacka University of Opole, Poland
Wojciech Sułek Silesian University of Technology, Poland
Zbigniew Suski Military University of Technology, Poland
Bin Tang California State University, USA
Kerry-Lynn Thomson Nelson Mandela Metropolitan University, South Africa
Oleg Tikhonenko Cardinal Stefan Wyszynski University, Poland
Ewaryst Tkacz Silesian University of Technology, Poland
Homero Toral Cruz University of Quintana Roo, Mexico
Mauro Tropea University of Calabria, Italy
Leszek Trybus Rzeszów University of Technology, Poland
Kurt Tutschku Blekinge Institute of Technology, Sweden
Selda Uyanik Istanbul Technical University, Turkey
Adriano Valenzano National Research Council of Italy, Italy
Peter van de Ven Eindhoven University of Technology, The Netherlands
Bane Vasic University of Arizona, USA
Miroslaw Voznak VSB-Technical University of Ostrava, Czech Republic
Krzysztof Walkowiak Wrocław University of Technology, Poland
Sylwester Warecki Intel, USA
Jan Werewka AGH University of Science and Technology, Poland
Tadeusz Wieczorek Silesian University of Technology, Poland
Lukasz Wisniewski Hochschule Ostwestfalen-Lippe, Germany
Przemysław Włodarski West Pomeranian University of Technology, Poland
Józef Woźniak Gdańsk University of Technology, Poland
Hao Yu Auburn University, USA
Grzegorz Zaręba University of Arizona, USA
Piotr Zawadzki Silesian University of Technology, Poland
Zbigniew Zieliński Military University of Technology, Poland
Liudong Zuo California State University, USA
Piotr Zwierzykowski Poznań University of Technology, Poland
 Organization XIII

Referees

Davide Adami Anna Przemysław Ryba

Rajiv Bagai Kamińska-Chuchmaa Wojciech Rząsa
Sebastian Bala Jerzy Klamka Dariusz Rzońca
Jiří Balej Grzegorz Kołaczek Alexander Schill
Zbigniew Banaszak Ivan Kotuliak Olga Siedlecka-Lamch
Thomas Bauschert Zbigniew Kotulski Artur Sierszeń
Robert Bestak Henryk Krawczyk Tomas Sochor
Grzegorz Bocewicz Mirosław Kurkowski Janusz Stokłosa
Leoš Bohac Andrzej Kwiecień Ioannis Stylios
Juan Felipe Botero Piotr Lech Grażyna Suchacka
Amlan Chatterjee Zbigniew Lipiński Wojciech Sułek
Ray-Guang Cheng Marcin Markowski Zbigniew Suski
Erik Chromý Francesco Masulli Bin Tang
Yeon Ho Chung Przemysław Mazurek Oleg Tikhonenko
Andrzej Chydziński Jarosław Miszczak Ewaryst Tkacz
Dariusz Czerwiński Vladimir Mityushev Homero Toral Cruz
Adam Czubak Alexander Moiseev Mauro Tropea
Peppino Fazio Evsey Morozov Leszek Trybus
Max Felser Włodzimierz Mosorow Kurt Tutschku
Holger Flatt Sasa Mrdovic Peter van de Ven
Jean-Michel Fourneau Mateusz Muchacki Miroslaw Voznak
Rosario G. Garroppo Gianfranco Nencioni Sylwester Warecki
Natalia Gaviria Sema F. Oktug Jan Werewka
Erol Gelenbe Remigiusz Olejnik Tadeusz Wieczorek
Roman Gielerak Michele Pagano Lukasz Wisniewski
Mariusz Głąbowski Nihal Pekergin Przemysław Włodarski
Daniel Grzonka Maciej Piechowiak Józef Woźniak
Sebastien Harispe Piotr Pikiewicz Hao Yu
Artur Hłobaż Jacek Piskorowski Krzysztof Zatwarnicki
Zbigniew Huzar Oksana Pomorova Zbigniew Zieliński
Jacek Izydorczyk Sławomir Przyłucki Liudong Zuo
Sergej Jakovlev Tomasz Rak Piotr Zwierzykowski
Agnieszka Jakóbik Stefan Rass
Jürgen Jasperneite Stefano Rovetta

Sponsoring Institutions

Organizer: Institute of Informatics, Faculty of Automatic Control, Electronics and

Computer Science, Silesian University of Technology
Co-organizer: Committee on Informatics of the Polish Academy of Sciences, Section of
Computer Networks and Distributed Systems
XIV Organization

Honorary Patrons: His Magnificence Rector of Silesia University of Technology,

Mayor of Gliwice, and Mayor of Katowice
Official Sponsor and Partner: Wasko S.A.
Official Partners: 3Soft S.A. and Bombardier Inc.

Technical Partner

Technical Co-sponsor: IEEE Poland Section

Conference Partner: iNEER
 Contents

Computer Networks

The Method of Determining the Optimal Communication Structure . . . . . . . . 3

Jan Chudzikiewicz and Tomasz Malinowski

Researching Measured and Modeled Traffic with Self-similar Properties

for Ateb-Modeling Method Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Olga Fedevych, Ivanna Dronyuk, and Danylo Lizanets

A Validation Method of a Real Network Device Model

in the Riverbed Modeler Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Dagmara Mazur

Energy Efficient MPTCP Transmission Over Channels

with a Common Bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Michał Morawski and Przemysław Ignaciuk

Light-Weight Congestion Control for the DCCP Protocol

for Real-Time Multimedia Communication . . . . . . . . . . . . . . . . . . . . . . . . . 52
Robert R. Chodorek and Agnieszka Chodorek

On Improving Communication System Performance

in Some Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Tomasz Malinowski and Jan Chudzikiewicz

New SDN-Oriented Authentication and Access Control Mechanism . . . . . . . 74

Fahad Nife and Zbigniew Kotulski

Full Network Coverage Monitoring Solutions – The netBaltic

System Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Damian Karpowicz, Tomasz Gierszewski, and Krzysztof Nowicki

A Novel Auction Based Scheduling Algorithm in Industrial Internet

of Things Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Mike Ojo, Stefano Giordano, Davide Adami, and Michele Pagano

A New Approach for SDN Performance Enhancement. . . . . . . . . . . . . . . . . 115

Madhukrishna Priyadarsini and Padmalochan Bera

Quantum Coherence Measures for Quantum Switch . . . . . . . . . . . . . . . . . . 130

Marek Sawerwain and Joanna Wiśniewska
XVI Contents

Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 . . . . . . . 142

Michał Druzgała and Ziemowit Nowak

Teleinformatics and Telecommunications

Modified OMP Algorithm for Compressible Channel

Impulse Response Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Grzegorz Dziwoki, Marcin Kucharczyk, and Jacek Izydorczyk

Evaluation of the Jammers Performance in the WiFi Band . . . . . . . . . . . . . . 171

Dariusz Czerwinski, Jaroslaw Nowak, and Slawomir Przylucki

LTE Load Balancing with Tx Power Adjustment and the Real

Life Mobility Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Konrad Połys, Krzysztof Grochla, and Michał Gorawski

Determining the Usability of Embedded Devices Based on Raspberry Pi

and Programmed with CODESYS as Nodes
in Networked Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Jacek Stój, Ireneusz Smołka, and Michał Maćkowski

The Method of Isochronous Cycle Duration Measurement for Serial

Interface IEEE 1394A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Michał Sawicki and Andrzej Kwiecień

Queueing Theory

Time to Buffer Overflow in a Queueing Model with Working

Vacation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Wojciech M. Kempa and Martyna Kobielnik

Adaptation of the N-GREEN Architecture for a Bursty Traffic . . . . . . . . . . . 232

Tulin Atmaca, Amira Kamli, and Artur Rataj

The Model of the DWDM Access Node . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Slawomir Hanczewski, Maciej Stasiak, and Joanna Weissenberg

A Queueing Model of the Edge Node in IP over All-Optical Networks . . . . . 258

Kuaban Godlove Suila, Tadeusz Czachórski, and Artur Rataj

Multiserver Queueing System with Non-homogeneous Customers

and Sectorized Memory Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Marcin Ziółkowski and Oleg Tikhonenko
 Contents XVII

GPU Accelerated Non-integer Order PI a Db Controller Used

as AQM Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Adam Domański, Joanna Domańska, Tadeusz Czachórski,
Jerzy Klamka, Dariusz Marek, and Jakub Szyguła

Consequences of the Form of Restrictions in Coloured Petri Net Models

for Behaviour of Arrival Stream Generator Used
in Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Dariusz Rzonca, Wojciech Rząsa, and Sławomir Samolej

Transient Queueing Delay in a Finite-Buffer Batch-Arrival Model

with Constant Repeated Vacations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Wojciech M. Kempa and Rafał Marjasz

Cybersecurity and Quality of Service

Cache Enhanced Anonymity Systems Against Probabilistic Attacks. . . . . . . . 323

Huabo Lu and Rajiv Bagai

The Impact of Time Parameters on the Security Protocols Correctness. . . . . . 333

Sabina Szymoniak

On Some Time Aspects in Security Protocols Analysis . . . . . . . . . . . . . . . . 344

Sabina Szymoniak, Olga Siedlecka-Lamch, and Mirosław Kurkowski

A Note on Keys and Keystreams of Chacha20 for Multi-key Channels . . . . . 357

Adam Czubak, Andrzej Jasiński, and Marcin Szymanek

Security Considerations of Modern Embedded Devices

and Networking Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Błażej Adamczyk

Self-adaptive System for the Corporate Area Network Resilience

in the Presence of Botnet Cyberattacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Sergii Lysenko, Oleg Savenko, Kira Bobrovnikova,
and Andrii Kryshchuk

QoS- and Energy-Aware Services Management of Resources

in a Cloud Computing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Jerzy Martyna

Maximum Lifetime of the Wireless Sensor Network

and the Gossip Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Zbigniew Lipiński
XVIII Contents

Wireless Network with Bluetooth Low Energy Beacons for Vehicle

Detection and Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Marcin Bernas, Bartłomiej Płaczek, and Wojciech Korski

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Computer Networks
 The Method of Determining the Optimal
Communication Structure

Jan Chudzikiewicz(B) and Tomasz Malinowski(B)

Faculty of Cybernetics, Military University of Technology,

ul. Gen. Witolda Urbanowicza 2, 00-908 Warszawa, Poland
{jan.chudzikiewicz,tomasz.malinowski}@wat.edu.pl
http://www.wat.edu.pl/

Abstract. In the paper, the problem of determining the optimal com-

munication structure (communication routes) for wireless or wired data
communication networks with predefined structure of usable communica-
tion links was considered. The procedure of determining such structure,
which is based on identifying and comparing of selected characteristics
of the dendrites describing the network nodes and communication links,
was developed. The correctness of the method has been confirmed by
results obtained by comparative simulation studies of different commu-
nication substructures (dendrites). Simulation tests were prepared and
implemented in Riverbed Modeler environment.

Keywords: Data communication networks

Optimal communication structure · Internet of Things

1 Introduction
Determining the optimal communication structures is the issue raised in many of
research works focused on improving the reliability, performance, and usability
of transmission systems (multiprocessor systems, military computer networks -
wired and wireless networks of stationary or mobile nodes). A lot of research
focuses on the problems with networks of the hypercube structure and on the
problems with location and relocation of network resources ([1–7]). In the era of
IoT (Internet of Things), results of research on “energy-efficient” communication
structures, prolong the life time of the network with battery-powered nodes, are
particularly important ([8–10]). The work is focused on developing new routing
protocols, effective medium access protocols, selecting of nodes collecting and
processing information from other nodes, constituting the catchment informa-
tion nodes (sink nodes), meeting points nodes (rendezvous points) or acting as
coordinator nodes ([10–14]).
In this paper we introduce a centralized procedure for determining the optimal
communication structure. The result of the procedure is the shortest path tree with
the root in the specific node. We abstract from considering the role this node can
play (server, coordinator, collector of information from other nodes). We assume
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 3–12, 2018.
https://doi.org/10.1007/978-3-319-92459-5_1
4 J. Chudzikiewicz and T. Malinowski

for example, as many articles on the same topic, that indication and use “our” opti-
mal communication structure in a network of wireless nodes, will result in reduc-
ing the number of packets generated by the nodes and exchanged between nodes,
thereby limiting power consumption and increase the life of network.
Our procedure for determining the optimal communication structure is cen-
tralized and we hope that it is universal, on the assumption that we will be able
to assess, based on various parameters (bandwidth of transmission channels,
delays, packets lost, etc.), the functioning of the network (wireless or wired) at
a given moment. We have assumed that we will get information about routing
and quality of communication connections (from sensors testing communication
channels). On this basis, we will be able to give an optimal (probably subop-
timal) communication structure resulting from the use of the best communi-
cation routes (dendrite of the best routes). These routes can then be entered
(distributed) into the configuration files of network devices. In our opinion, a
centrally determined suboptimal communication structure, considering not only
the number of hops from the source to the destination (in our procedure only this
characteristic has been taken into account), but also other important parameters
and regardless of the routing protocol used (whether for wired or wireless net-
works) will have a positive effect on the functioning of the network (minimizing
delays, energy consumption by communication nodes, etc.). We also assumed
that the analyzed network is rather small (cluster of whole network) and in our
assumptions it’s size is limited to ten nodes.
The paper is organized as follows. In Sect. 2, basic definitions were intro-
duced. The calculation of attainability for exemplary structures were presented.
In Sect. 3, the proposal of the method and the algorithm of determining opti-
mal communication structure was presented. In Sect. 4, the results of simulation
tests for proposed method verification were described. In Sect. 5, some conclud-
ing remarks were presented.

2 The Basic Definitions

Definition 1. The structure of a network is described by coherent ordinary
graph G = E, U  (E – set of network nodes, U – set of bidirectional com-
munication link).
Let d (e, e |G ) be the distance (the number of hops) between nodes e and e
in a coherent graph G, that is the length of the shortest chain (in the graph G)
connecting node e with the node e .
max
Let r (e|G) =e ∈E(G) d ((e, e ) |G ) be the radius of a node, and D (G) =
max {d (e , e |G ) : {e , e } ⊂ E (G)} be the diameter of a graph G. The radius
of node e is the largest number of hops from node e to any other node of G. The
diameter of G is the largest radius in G.
Denote by E (d) (e|G) = {e ∈ E (G) : d (e, e |G ) = d} for d ∈ {1, . . . , D (G)} ,
and by
ς (e |G ) = (ς1 (e |G ) , . . . , ςr (e |G )) (1)
 (d) 

for ςd (e |G ) = E (e |G ) . 
 The Method of Determining 5


Definition 2 [6]. Let ϕ (e |G ) = d (e, e |G ) for e ∈ E (G) be attainability
e ∈E(G)

of the node e in the network G and Φ (G) = ϕ (e |G ) be attainability of
e∈E(G)
the network G.

Using (1) we have


r(e|G )
ϕ (e |G ) = dςd (e |G ) .
d=1

Definition 3 [7]. Let T = E, U ∗  be the dendrite i.e. such coherent acyclic
partial graph of G that:

∃ e , e  ∈ U =⇒ e , e  ∈ U ∗ ⇐⇒

⇐⇒ [(d (ei , e ) = d (ei , e )) ∧ d (e , e ) = 1]

min
for r (ei ) =e∈E(G) r (e).

Denote by T (e) for e ∈ E(G) the set of all possible dendrites determined for
node e. 
min
Let Φmin (T (e)) =t∈T (e) ϕ (e |t ) be the value of minimal attainability
e∈E(t)
for T (e).
The dendrite T is a base to determine the communication structure of G.
The algorithm for determined dendrite T is presented in [7]. The method and
the algorithm for determined the optimal communication structure based on the
dendrites determination is presented in Sect. 3.

3 The Method and the Algorithm for Determining

the Optimal Communication Structure

The method consists of fourth stages. In the first stage for G, as the first node
min min
we choose a node that r (e |G ) =e ∈E(G) r (e ) or ϕ (e |G ) =e ∈E(G) ϕ (e ). In the
second stage for the chosen node we determine all possible dendrites T (e) for
e ∈ E (G). In the third stage, for each dendrite determined in the second stage,
the value of attainability Φ (T (e)) is calculated. In the fourth stage, based on
the attainability calculated in the third stage, the dendrite T , which is an opti-
mal communication structure satisfying the condition Φmin (T (e)) is determined.
Based on the presented method the algorithm for determining the optimal com-
munication structure was developed.
The algorithm for determining the optimal communication structure.
Step 1. (first stage)
Calculate r (e |G ) and ϕ (e |G ) for e ∈ E (G).
min
Choose a node e∗ ∈ E (G) such that r (e∗ |G ) =e ∈E(G) r (e ) or
6 J. Chudzikiewicz and T. Malinowski

min
ϕ (e∗ |G ) =e ∈E(G) ϕ (e ).
Selected node ei will be a central node of G.
Step 2. (second stage)
For the chosen node e∗ determine set T (e∗ ), wherein r ( e∗ | T ) = r ( e∗ | G) .
Step 3. (third stage)
Calculate Φ (t (e∗ )) for t ∈ T (e∗ ).
Step 4. (fourth stage)
min
Choose a dendrite t such that Φ (t) =t ∈T (e∗ ) Φ (t ).
Step 5.
The end of the algorithm.
For illustrating the algorithm’s operation, consider the following example.
Example 1. Let the structure G1 (presented in Fig. 1) be the basis for deter-
mining the optimal communication structure.

Fig. 1. An exemplary communication structure G1

In the first step of the presented algorithm, the radius and the attainability
for each node of G1 must be calculated. In the Table 1 the results of calculating
radius (A) and attainability (B) of G1 ’s nodes are presented.

Table 1. The results of determining the radius (A) and the attainability (B) of G1

A B
e ∈ E (G1 ) r (e |G1 ) e ∈ E (G1 )/d (e, e |G1 ) 1 2 3 4 ϕ (e, G1 )
e0 3 e0 3 3 2 0 15
e1 2 e1 4 4 0 0 12
e2 4 e2 2 3 2 1 18
e3 3 e3 3 3 2 0 15
e4 3 e4 2 3 3 0 14
e5 4 e5 2 3 2 1 18
e6 3 e6 4 3 1 0 13
e7 4 e7 2 4 2 0 16
e8 4 e8 2 4 2 0 16
 The Method of Determining 7

Next, the node with a minimal radius or (if nodes with a minimum radius
value is more) the node with a minimal attainability is chosen. In the case of G1 ,
the node with the minimal radius, and minimal attainability is node e1 . In the
next step, for chosen node e1 , the algorithm determines the set T (e1 ) (presented
in Fig. 2) of possible dendrites and calculates the attainability (presented in
Table 2) for all of them.

Fig. 2. The set T (e1 ) of possible dendrites of the e1 node

The algorithm, as the optimal communication structure TOP T for G1 , choses

the dendrite t15 shown in Fig. 3.

Fig. 3. The optimal communication structure TOP T for G1

In Table 3 the results of calculating radius (A) and attainability (B) of TOP T
are presented.
8 J. Chudzikiewicz and T. Malinowski

Table 2. The attainability for dendrites of set T (e1 )

ϕ (e)/T (e1 ) t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16

ϕ (e0 ) 17 17 15 17 15 15 15 15 17 17 17 17 19 19 19 19
ϕ (e1 ) 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
ϕ (e2 ) 24 24 22 24 22 22 22 22 24 22 20 22 24 22 24 22
ϕ (e3 ) 17 19 19 17 20 17 17 19 17 15 17 15 17 15 17 15
ϕ (e4 ) 17 18 19 19 17 17 19 19 17 19 19 17 17 19 19 17
ϕ (e5 ) 24 24 22 22 24 24 24 22 24 24 22 24 24 22 20 24
ϕ (e6 ) 17 15 15 15 17 19 17 15 17 17 15 19 15 15 13 17
ϕ (e7 ) 24 22 22 22 22 22 22 22 24 24 24 20 22 22 20 24
ϕ (e8 ) 24 22 22 24 24 24 24 22 24 22 22 22 22 22 20 22
Φ (T (e1 )) 176 173 168 172 173 172 172 168 176 172 168 168 172 168 164 172

Table 3. The radius (A), and the attainability (B) of TOP T

A B
e ∈ E (TOP T ) r (e |TOP T ) e ∈ E (TOP T ) / d (e, e |TOP T ) 1 2 3 4 ϕ (e, TOP T )
e0 3 e0 1 3 4 0 19
e1 2 e1 4 4 0 0 12
e2 4 e2 1 1 3 3 24
e3 3 e3 2 3 3 0 17
e4 3 e4 1 3 4 0 19
e5 4 e5 1 3 3 1 20
e6 3 e6 4 3 1 0 13
e7 4 e7 1 3 3 1 20
e8 4 e8 1 3 3 1 20
Φ (TOP T ) 164

4 The Results of Simulation Studies

Simulation studies have been realized in Riverbed Modeler environment. The
verification of method proposed and described in Sect. 3 was carried out in a
wired network environment (due to the rapid and easy modeling of many network
structures).
In this subsection, we present results for the procedure verification for T (e1 )
set of dendrites. From section Sect. 3 we know that the best communication
structure for these set is t15 (TOP T for G1 ).
The conducted simulation tests certainly do not serve to verify the design
of any network. The tests were to authenticate the procedure for determining
the optimal communication structure. We decided that the simulation model
does not have to be or even should not be a model fully adequate to the real
network. We assumed that it would be acceptable to design any communication
 The Method of Determining 9

system with the minimal number of network services. We set the LAN model
with an unspecified shape of network traffic and the selected http service. In
our case, when assessing the impact of the routing method (corresponding to
the chosen subgraph) on how the chosen service works, we decided that it would
be the best solution, with transparent results. Therefore, we only took care of
the homogeneity of links and network devices. What was important for us is
that in the randomness of generating network streams and the randomness of
client-server connections, the simulation results confirm the correctness of the
theoretical arguments.
All dendrites were modeled as computer networks with routers with attached
LAN segment and servers. Routers play a role of a dendrite’s node. For example,
the network topology of the single scenario (single dendrite) was shown in the
Fig. 4.

Fig. 4. Network topology for single simulation scenario

Workstations within LAN segments (ten workstations in each segment) were

functioning as the server’s clients. The basic server’s service was http server
(quite enough to carry out research), with standard application [15]. Communi-
cation links bandwidth was set to 1,5 Mb/s.
We performed some tests with other settings of network traffic generators
and the number of tcp clients in each network segments (to saturate network
links), but the obtained results for the characteristics chosen by us (number of
hops and delay for tcp transmission) were comparable, i.e. have indicated the
communication structure chosen by the procedure, so we gave up the detailed
description of each experiments by selecting a representative one.
Selected results (for set T (e1 ) of dendrites), confirming the correctness of
the procedure for determining the optimal communication structure are shown
in the figures below.
10 J. Chudzikiewicz and T. Malinowski

We used two important characteristics (in our opinion sufficient at this stage
of research). The first of them was global average Number of Hops (representing
an average number of IP hops taken by data packets reaching at a destination
node) and the second, average TCP Delay (representing delay of TCP packets.
This value is measured from the time an application data packet is sent from the
source TCP layer to the time it is received by the TCP layer in the destination
node for all connections).
We knew which communication structure for each set of dendrites is optimal
and we were looking for confirmation of the correctness of calculations performed
earlier. The collected results looked like this from Fig. 5. Figure illustrates aver-
age Number of Hops for the best dendrite t15 (the lowest drawn line) against
results for selected three other dendrites.

Fig. 5. Average Number of Hops for selected dendrites

Complete results, in the form of a bar chart, for all dendrites from set T (e1 ) are
presented in Fig. 6. The highlighted bar (No 15) refers to the best structure t15 .

Fig. 6. Average Number of Hops for all dendrites of T (e1 )

Similarly, for all dendrites from the selected set, average TCP Delay was
measured. The results are presented in Fig. 7.
 The Method of Determining 11

Fig. 7. Average TCP delay (in seconds) for TCP-based services

Results of simulation studies (we expected the lowest values of Average Num-
ber of Hops and Average TCP delay for TCP-based services) confirmed the cor-
rectness of the developed method of determining the optimal communication
structure, determined analytically in section Sect. 3.

5 Summary
Correctness of developed method and its usefulness for determining optimal
communication structure was confirmed by simulation tests. In analytical cal-
culations two essential characteristics, number of hops and attainability, were
used. According to our expectations, in simulation tests you could also use other
characteristics, reflecting real condition of the network (in our study we used
only TCP delay, but it was quite enough to confirm the correctness of analytical
argumentations). The authors believe that the developed method can be used to
determine the optimal structure also in wireless networks (for example to extend
its life or for the efficient collection of information from wireless nodes). In the
nearest future we plan to investigate the impact of such a network monitoring
procedure with a periodically scheduled routing plan on how a specific network
of wireless nodes works.
At this stage, for a small communication structure, complexity of the devel-
oped algorithm was not calculated. Our observations show that the efficiency of
the algorithm depends on the number of nodes, the structure diameter and the
radius of the node for which dendrites were determined. Currently, calculations
are performed on a PC and it does not matter the memory usage and CPU load.
We notice the need to modify the procedure (to be fast and not burdening the
system) if it is going to be implemented by a wireless network node.

References
1. AlBdaiwia, B.F., Bose, B.: On resource placements in 3D tori. J. Parallel Distrib.
Comput. 63, 838–845 (2003)
2. AlBdaiwia, B.F., Bose, B.: Quasi-perfect resource placements for two-dimensional
toroidal networks. J. Parallel Distrib. Comput. 65, 815–831 (2005)
12 J. Chudzikiewicz and T. Malinowski

3. Bae, M.M., Bose, B.: Resource placement in torus-based networks. IEEE Trans.
Comput. 46(10), 1083–1092 (1997)
4. Imani, N., Sarbazi-Azad, H., Zomaya, A.Y.: Resource placement in Cartesian prod-
uct of networks. J. Parallel Distrib. Comput. 70, 481–495 (2010)
5. Moinzadeh, P., Sarbazi-Azad, H., Yazdani, N.: Resource placement in cube-
connected cycles. In: The International Symposium on Parallel Architectures, Algo-
rithms, and Networks, pp. 83–89. IEEE Computer Society (2008)
6. Chudzikiewicz, J., Zieliński, Z.: On some resources placement schemes in the
4-dimensional soft degradable hypercube processors network. In: Zamojski, W.,
Mazurkiewicz, J., Sugier, J., Walkowiak, T., Kacprzyk, J. (eds.) Proceedings of the
Ninth International Conference on Dependability and Complex Systems DepCoS-
RELCOMEX. June 30 – July 4, 2014, Brunów, Poland. AISC, vol. 286, pp. 133–
143. Springer, Cham (2014). https://doi.org/10.1007/978-3-319-07013-1 13
7. Chudzikiewicz, J., Malinowski, T., Zieliński, Z.: The method for optimal server
placement in the hypercube networks. In: Proceedings of the 2015 Federated Con-
ference on Computer Science and Information Systems, ACSIS, Vol. 2, pp. 947–954
(2015). https://doi.org/10.15439/2014F159
8. Niewiadomska-Szynkiewicz, E., Kwaśniewski, P., Windyga, I.: Comparative study
of wireless sensor networks energy-efficient. J. Telecommun. Inf. Technol. (2009)
9. Jindal, A., Liu, M.: Networked computing in wireless sensor networks for structural
health monitoring. In: IEEE/ACM Transactions on Networking (TON) (2012)
10. Brindha, L., Muthaiah, U.: Energy efficient mobile sink path selection using a
cluster based approach in WSNs. Int. J. Innov. Res. Comput. Commun. Eng. 3(3)
(2015)
11. Erzin, A.I., Plotnikov, R.V.: Using VNS for the Optimal synthesis of the commu-
nication tree in wireless sensor networks. Electron. Notes Discrete Math. 47, 21–28
(2015)
12. Rekha, G., AjeethaKumari, A.S.: High data aggregation in wireless sensor networks
using Rendezvous-Drina. Int. J. Emerg. Technol. Adv. Eng. 4(6), 139–144 (2014)
13. Ghotra, A., Soni, N.: Performance evaluation of ant colony optimization based
rendezvous leach using for mobile sink based WSNs. Int. J. Eng. Res. Dev. 11(07),
43–49 (2015)
14. Baby, S., Soman, M.: Rendezvous based techniques for energy conservation in
wireless sensor networks - a survey. J. Netw. Commun. Emerg. Technol. (JNCET)
3(3) (2015)
15. Sethi, A.S., Hnatyshin, V.Y.: The Practical OPNET User Guide for Computer
Network Simulation. Chapman and Hall/CRC, Boca Raton (2012)
 Researching Measured and Modeled
Traffic with Self-similar Properties
for Ateb-Modeling Method Improvement

Olga Fedevych1(B) , Ivanna Dronyuk1 , and Danylo Lizanets2

1
ACS Department, Lviv Polytechnic National University,
12 Bandera Street, Lviv, Ukraine
[email protected], [email protected]
2
Division of Microengineering and Photovoltaics,
Wroclaw University of Science and Technology,
27 Wybrzeze Wyspiańskiego, Wroclaw, Poland
[email protected]
http://www.lp.edu.ua/asu
http://www-old.wemif.pwr.wroc.pl/zmf/

Abstract. In this paper, improvements in the traffic behavior modeling

method based on the consideration of traffic self-similarity properties was
proposed. Two methods for calculating the Hurst parameter were used:
R/S plot method and V/S analysis method. The research was carried
out on real traffic network data, collected from LPNU ACS Department.
The selected methods were implemented in the corresponding software.
The work of the methods was illustrated in experimental calculations.
Also, the results was shown in the form of both tables and plots.

Keywords: Computer network traffic · Ateb-function

Traffic modeling · Self-similar properties · Hurst parameter

1 Introduction

One of the biggest challenges nowadays is the gradual shift from the Internet
of Devices concept to the new Internet of Things concept, given the aspirations
of those who developed these concepts to boost their user-friendliness and the
growing demand for dynamic scalability of networks that differ by scale, type
or functionality. Also, the revolutionary influence on traffic parameters changing
has an alteration of its internal structure. Based on today’s Internet research,
provided by Cisco, mobile traffic on 75% consists of the video traffic [1].
According to the forecasts of the same company, the share of video content
in the future will only be increasing. Another factor that significantly influences
the structure of traffic is the widespread introduction of cloud technologies. The
cloud computing paradigm has become the foundation of the modern economy
by offering subscription-based services anytime, anywhere with services paid by
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 13–25, 2018.
https://doi.org/10.1007/978-3-319-92459-5_2
14 O. Fedevych et al.

users. The transition of many technologies to distributed computing, software-

managed networks and data processing at the network level in nodes of network
equipment are also among the modern trends that open up new opportunities
for traffic management [2,3].
At the same time, computer networks have certain disadvantages, such as:
the complexity of network management, the high cost of network equipment, the
lack of efficient use of the channel through the transmission of a large amount of
information to manage the network instead of useful traffic. Multimedia traffic
samples were selected for the research.
The purpose of this development is to expand the functionality of the previously
[4] proposed method of modeling the behavior of traffic based on the consideration
of self-similar properties of traffic. In this article, under the term of traffic modeling
(forecasting), the conception of the process of collecting data for real traffic and
based on these data and the corresponding formulas of the mathematical model,
the calculation of the following traffic values was considered.

2 Simulation of Traffic Behavior for Model Construction

One of the most pressing problems of traffic research is adequate consideration of
its features. Studies show that the traffic of modern telecommunication networks
has a special structure that does not allow to use classical methods to design
network equipment based on Markov models and Erlang’s formulas [4]. This is
the effect of self-similarity of traffic, which leads to the ripples of its receipt. This
phenomenon significantly degrades the characteristics (increases losses, delays,
jitter) while passing self-similar traffic through the network equipment, so the
study of this indicator will predict and reduce the impact of such undesirable
factors.
Research of various types of network traffic over the past fifteen years has
shown that network traffic is self-similar or fractal in its nature. It follows from
this that the classical methods that are used for modeling of network systems
based on the use of Poisson flows [5], do not give a complete and accurate picture
of what is happening online. In [4] a mathematical model for modeling traffic
behaviour in computer networks based on differential equations describing the
oscillatory motion was proposed.
In addition, self-similar traffic has a special structure, stored at multiple scal-
ing. When passing traffic on the network, as a rule, there is a certain number of
pulsations with a relatively small average traffic level. In practice, this is imple-
mented in such a way that packets, at high speed of their network movement,
arrive at the site not separately, but as a whole package, which can lead to their
losses due to limited buffer, calculated according to classical techniques.
Many contemporary researchers note [6] that combining of traffic from mul-
tiple variable ON/OFF sources increases self-similar properties of traffic. Traffic
becomes highly autocorrelated with long-term dependence. The unification of a
large number of data sources is characterized by a syndrome of infinite disper-
sion and, as a result, gives a self-similar unified network traffic that seeks for a
 Researching Traffic with Self-similar Properties 15

fractal Brownian motion. In addition, the research of various sources of traffic

indicates that the very variable behavior of traffic is a function inherent in the
client/server architecture [7].
There is no single causative factor that causes self-similarity. Different corre-
lations that exist in self-similar network traffic and that take effect on different
time scales may occur for various reasons, changing the characteristics at specific
time scales.

3 Methods of Traffic Self-similar Properties

Determination
To analyze the self-similar properties of traffic, the Hurst coefficient was selected.
At the same time, the Hurst method, being robust, can reveal such properties
as clustering, the tendency to be in the direction of the trend, strong afteref-
fect, separate memory, rapid change of sequential values, fractality, the presence
of periodic and nonperiodic cycles, the ability to distinguish “stochastic” and
“chaotic” nature of noise in the statistical data.
The value of the Hurst coefficient can be found in several methods [8–10]:
1. Variance method. Logarithmic selective dispersion in comparison with the
level of aggregation should be a straight line with a slope of more than −1.
2. R/S plot method. The logarithmic sample of R/S statistics compared with
the number of points in the aggregated series is a straight line with a slope.
3. Absolute moments method. The aggregated series X(m) determines the use
of different sizes of blocks m.
4. Variance of residuals method. Logarithmic aggregation in comparison with
the average dispersion level of the residues should be a straight line with a
slope of H/2.
5. Abry-Veitch estimation method. To estimate the H parameter, the energy of
the series on different scales is used.
6. Whittle estimation method is based on the minimization of the likelihood
function, which applies to the time series period, gives the assessment of H
and dependence on the confidence interval.
7. V/S analysis, described in detail in [11].
All seven mentioned methods were tested for realization of scientific
researches. During the computational experiments, R/S plot method and V/S
analysis were selected as the best methods for determining the proximity of the
Hurst coefficient for modeled and real traffic. These methods were chosen among
others due to the ease of their program implementation.
In addition to the key contribution of Hurst to the development of the theory
of R/S-method and its application in practice, a significant role was played
by Mandelbrot [12]. According to this method, not the data that compose a
dynamic time series are analyzed, but the scale of the amount of deviations
of these data from the mean arithmetic, normalized by dividing on standard
deviation. The sum of these deviations is calculated for different periods of time
16 O. Fedevych et al.

(or for different number of successive observation points), which act as a scale
of measurement.
The main difference between R/S estimation method and other existing sta-
tistical methods for analyzing of time series is that this method includes the time
direction in its analysis, while other known methods for this time are invariant.
The Hurst H coefficient is described by the empirical relation
R
= NH (1)
S
where R – the range of deviations values of the series x, S – standard deviation
x, N – number of observations.
Express the Hurst H factor as:

R
log
H= S (2)
log N

Let x̄(N ) – average value of random variable

1 
N
x̄(N ) = x(ti ) (3)
N i=1

The standard deviation is determined from the formula



1  N
S(N ) =  [x(ti ) − x̄(N )]2 (4)
N i=1

Denote by the following formula the accumulated deviation of the values of

the random variable x(t) from its mean value x̄(N ) for time t:


t
X(t, N ) = [x(u) − x̄(N )] (5)
u=1

Difference between maximum and minimum values X(t, N ) is called a scope

R(N ) = max X(t, N ) − min X(t, N ) (6)

where 1 ≤ t ≤ N .
Calculated deviations (4), (5) are substituted in the formula (1) and there is
a Hurst coefficient.
Two methods for calculating the Hurst parameter are implemented in the
developed software module. Conducted calculations of the Hurst parameter are
implemented for the real traffic values and the modeled traffic values based on
the R/S method and the V/S method described in detail in [11,12].
 Researching Traffic with Self-similar Properties 17

4 Development of Software Solution

This work envisaged the creation of two separate software solutions that collec-
tively carried out modeling and traffic analysis in order to model its behavior.
First, a solution for analysis of traffic samples and the implementation of the
short-term behaviour modeling method was developed, followed by a separate
module for analyzing and calculating the Hurst parameter in the collected traffic
data.
To carry out these studies, an additional software module has been imple-
mented to calculate the Hurst parameter for different time intervals, samples
of traffic, as well as to calculate the Hurst parameter for pre-recorded modeled
values of the short-term behaviour modeling method of traffic values.
Figure 1 shows the main window of the software module for calculating the
Hurst parameter.

Fig. 1. Program module interface for Hurst parameter calculation

18 O. Fedevych et al.

5 Analysis of Experimental Calculations

There is an ability to open captured traffic in the analyzer program, analyze
and calculate the properties of the traffic. Opening of pcap files does not require
much resources since the reading of the file occurs in the thread, though opening
of the same file in other programs may require a lot of resources.
To test the traffic analysis software, data was captured in two different pro-
grams - Wireshark and CommView. Data capture was carried out in different
places and different devices: a wireless adapter, a network card, a virtual network
adapter.
The results were analyzed by a software solution for traffic analysis. It was
established that since the captured data is exported to the standardized format
of the pcap file, there were no errors in the reading. Traffic properties were
determined correctly.
Developed software was also tested on different machines with different oper-
ating systems. After the testing, the software continued to work in as stable and
predictable manner as before.

5.1 Description of Conducted Experiments

Traffic was captured at the point where it had already been merged and sent
(received) from the Internet. The network of the ACS department contains about
20 working computers, loaded on average from 8:30 to 17:30; about 4 computers
are loaded until 21:00, and 3 computer classes with 32 workstations are loaded on
average from 8:30 to 16:00. The measurements were carried out during the month
on each working day from 9.00 to 13.00 o’clock, at an average data transfer rate
of 150 Mbit/sec. However, for visualization of the conducted research, three days
in a row were randomly chosen.
The collected data was analyzed by the developed software solution in terms
of traffic; the results of the analysis are shown in Table 1.
Duration of data collection differs in samples, which may slightly affect the
Hurst coefficient. The simulation time is chosen identically to the time of data
capture on a network.
In the previously proposed method of modeling, the property of the alter-
nating period of the Ateb-functions was used to select modeling parameters.
In [13] is proved that the Ateb-cosine and the Ateb-sine are periodic with
period 2Π(m, n), where Π(m, n) is shown by the formula
   
1 1
Γ Γ
n+1 m+1
Π(m, n) =   (7)
1 1
Γ +
n+1 m+1

where Γ ( n+1
1
), Γ ( m+1
1
) – gamma function.
 Researching Traffic with Self-similar Properties 19

For the modeling, the parameters n, m were selected in such a way that the
modeling period corresponded to the period of real traffic. In order to apply
the self-similarity property to improve the traffic behavior modeling, the Hurst
parameter for Ateb-functions in the half-period was calculated by the formula
(7). These calculations are presented in Table 1. Parameter t - modeling time, s.

Table 1. Dependency of Hurst parameter from Ateb-sine parameter

Function type Hurst parameter value H(m, n)

sa(1, 1, t) 0.861452
sa(1/7, 3, t) 0.884723
sa(1/5, 1, t) 0.873587
sa(1/3, 1, t) 0.875528
sa(0.01, 0.1, t) 0.823017
sa(1, 7, t) 0.879125
sa(1, 1/3, t) 0.855861

Fig. 2. The example of investigated traffic sample

Not only the proximity of the period of real and modeled traffic, but also the
proximity of the Hurst parameter as the second factor are taken into account
when choosing the values of the parameters n, m, when implementing modeling
in the improved method (Fig. 2).
min |H(m, n) − Htr | → 0 (8)
n,m

where H(m, n) – Hurst parameter for Ateb-function, Htr – Hurst parameter for
real traffic.
The traffic modeling is implemented using the method with the addition of
the delta function after the parameters n, m are chosen with the consideration
of the period and self-similarity using the formula (8).
20 O. Fedevych et al.

5.2 Evaluation and Analysis of Computational Results

The obtained data was analyzed and the Hurst coefficient was obtained. The
Hurst coefficient is consistently greater than 0.5 for all collected and simulated
traffic data, which indicates a self-similarity effect appearance.
The Hurst coefficient (H) is a measure of the stability of a statistical phe-
nomenon or measure of the duration of the long-term dependence of the process.
The closer the value of H is to 1, the higher the degree of stability of long-term
dependence and self-similarity is.
Thus, in the follow-up of the long-term observations, there is the possibility
to learn the tendency of traffic and to be able to model network traffic load. If
0 ≤ H ≤ 0.5, then the collected data is trend-resistant, if 0.5 ≤ H ≤ 1, the series
is the self-similar and trend-stable and thus the tendency of its changes can be
predicted.
The calculation were carried out for the R/S method (Tables 1, 2 and 3,
Fig. 3), as well as for the V/S method with different values of the amount of
division of the time interval k, where k = 100 (Tables 4 and 5, Fig. 4) and
k = 300 (Tables 6 and 7, Fig. 5).

Table 2. Hurst parameter calculation results for real traffic using R/S analysis

Hurst parameter value Hurst parameter value Traffic for Hurst parameter
(traffic for 10.05.2017) (traffic for 11.05.2017) value (12.05.2017)
0,776487 0,755443 0,578647

Table 3. Hurst parameter calculation results for modeled traffic using R/S analysis

Function type Hurst parameter Hurst parameter Hurst parameter

value (10.05.2017) value (11.05.2017) value (12.05.2017)
sa(1, 1, t) 0,702865 0,757899 0,704181
sa(1/7, 3, t) 0,706573 0,762734 0,699697
sa(1/5, 1, t) 0,70686 0,759841 0,692659
sa(1/3, 1, t) 0,708239 0,749252 0,701112
sa(0.01, 0.1, t) 0,695051 0,745324 0,697232
sa(1, 7, t) 0,696894 0,755396 0,699143
sa(1, 1/3, t) 0,702687 0,762055 0,708672

In Figs. 3 and 4, the first column of the chart corresponds to the selected
data of real traffic sample, the Hurst coefficient values of which are shown in
Tables 3 and 4 in the first line. Comparing the results of calculations for real and
modeled traffic shows a larger spread of computing results for real traffic samples
compared with the model traffic samples. The comparison of the calculations by
 Researching Traffic with Self-similar Properties 21

Fig. 3. Hurst parameter values for real and modeled traffic samples using R/S analysis.

Table 4. Hurst parameter calculation results for real traffic using V/S analysis for
k = 100

Hurst parameter value Hurst parameter value Hurst parameter value

(traffic for 10.05.2017) (traffic for 11.05.2017) (traffic for 12.05.2017)
0,472811 0,380671 0,313827

Table 5. Hurst parameter calculation results for modeled traffic using V/S analysis
for k = 100

Function type Hurst parameter Hurst parameter Hurst parameter

value (10.05.2017) value (11.05.2017) value (12.05.2017)
sa(1, 1, t) 0,608668 0,605909 0,605868
sa(1/7, 3, t) 0,600347 0,595662 0,600275
sa(1/5, 1, t) 0,600398 0,596081 0,60033
sa(1/3, 1, t) 0,599482 0,596307 0,599413
sa(0.01, 0.1, t) 0,609914 0,607638 0,610486
sa(1, 7, t) 0,60995 0,60788 0,610553
sa(1, 1/3, t) 0,607961 0,607886 0,60801
22 O. Fedevych et al.

Fig. 4. Hurst parameter values for real and modeled traffic samples using V/S analysis
for k = 100

Table 6. Hurst parameter calculation results for real traffic using V/S analysis for
k = 300

Name Hurst parameter Hurst parameter Hurst parameter

value (10.05.2017) value (11.05.2017) value (12.05.2017)
Traffic 0,510714 0,442446 0,346464

Table 7. Hurst parameter calculation results for modeled traffic using V/S analysis
for k = 300

Function type Hurst parameter Hurst parameter Hurst parameter

value (10.05.2017) value (11.05.2017) value (12.05.2017)
Traffic 0,510714 0,442446 0,346464
sa(1, 1, t) 0,642291 0,642654 0,64264
sa(1/7, 3, t) 0,636954 0,63623 0,636924
sa(1/5, 1, t) 0,637107 0,636658 0,637082
sa(1/3, 1, t) 0,636594 0,636614 0,636561
sa(0.01, 0.1, t) 0,642945 0,642956 0,642529
sa(1, 7, t) 0,643276 0,643293 0,642884
sa(1, 1/3, t) 0,642028 0,642069 0,642105

R/S method (Tables 1, 2 and 3, Fig. 3) and the V/S method (Tables 4, 5, 6 and
7, Figs. 4 and 5) shows the higher values of the calculated Hurst coefficient by
about 0.7 according to the R/S method than by the V/S method is about 0.6.
 Researching Traffic with Self-similar Properties 23

Fig. 5. Hurst parameter values for real and modeled traffic samples using V/S analysis
for k = 300

Consequently, it can be concluded that for the studied traffic samples, the R/S
method gives higher values of the Hurst coefficient.
The comparison of calculations of the Hurst coefficient for real traffic samples
using the V/S method for different values of the coefficient k (Table 4, k = 100)
and (Table 6, k = 300) shows that an increase of k value corresponds to increasing
of the Hurst coefficient value. On the contrary, for modeled traffic samples, the
increase of k value corresponds to reducing of the Hurst coefficient value (Table 5,
k = 100) and (Table 7, k = 300).

6 Conclusions
New trends in the development of computer networks create the need for new
approaches and strategies for their research, as well as a reappraisal of mod-
els designed to address such issues as scalability, elasticity, reliability, security,
sustainability and application of traffic behavior patterns.
This paper shows improvements in the traffic behavior modeling method
based on the consideration of traffic self-similarity parameters. Two methods for
calculating the Hurst parameter were used: R/S plot method and V /S analysis
method.
Committed studies have shown that for the traffic that is available in the
network of the ACS NULP department, the method that gives the higher value
of the Hurst parameter is the R/S method. This was observed in all cases that
were considered. In addition, this method has a faster computation time com-
pared to the V/S method in 7 times in average. So it can be concluded that
the R/S method can be used for the implementation in the network nodes for
determination of the Hurst parameter to improve the Ateb-modeling method,
developed before.
The selected methods are implemented in the corresponding software. The
work of the methods is illustrated in experimental calculations. The work has a
24 O. Fedevych et al.

practical application for studying the self-similar properties of traffic. The growth
of traffic volumes, transmitted through the network, as well as a significant
increase in the proportion of video files in traffic, causes the use of additional
traffic management tools directly at the nodes of the network. In order to manage
traffic at a network node and redistribute it to reduce delays, it is efficient to use
traffic modeling methods. Thereby, the investigation of self-similarity parameters
of traffic helps to increase the effective traffic management in the nodes of the
network.

References
1. The Zettabyte Era: Trends and Analysis. https://www.cisco.com/c/en/us/solutio
ns/collateral/service-provider/visual-networking-index-vni/vni-hyperconnectivity-
wp.html
2. Gelembe, E.: Steps towards self-aware networks. Commun. ACM 52(7), 66–75
(2009). https://doi.org/10.1109/CIT.2010.508
3. Toral-Cruz, H., Pathan, A.K., Ramirez Pacheco, J.C.: Accurate modeling of VoIP
traffic QoS parameters in current and future networks with multifractal and
Markov models. Math. Comput. Model. 57(11–12), 2832–2845 (2013). https://
doi.org/10.1016/j.mcm.2011.12.007
4. Dronyuk, I., Fedevych, O.: Traffic flows ateb-prediction method with fluctuation
modeling using Dirac functions. Commun. Comput. Inf. Sci. 718, 3–13 (2017).
https://doi.org/10.1007/978-3-319-59767-6 1
5. Mishura, Y., Ral’chenko, K., Seleznev, O., Shevchenko, G.: Asymptotic properties
of drift parameter estimator based on discrete observations of stochastic differen-
tial equation driven by fractional brownian motion. In: Korolyuk, V., Limnios, N.,
Mishura, Y., Sakhno, L., Shevchenko, G. (eds.) Modern Stochastics and Appli-
cations. SOIA, vol. 90, pp. 303–318. Springer, Cham (2014). https://doi.org/10.
1007/978-3-319-03512-3 17
6. Park, K., Willinger, W.: Self-similar network traffic: an overview. In: Self-Similar
Network Traffic and Performance Evaluation. Wiley (2000). https://doi.org/10.
1002/047120644X.ch1
7. Demydov, I., Klymash, M., Kharkhalis, Z., Strykhaliuk, B., Komada, P., She-
dreyeva, I., Targeusizova, A., Iskakova, A.: The research of the availability at
cloud service systems In: Proceedings Volume 10445, Photonics Applications in
Astronomy, Communications, Industry, and High Energy Physics Experiments
2017, 104451V (2017). https://doi.org/10.1117/12.2280885
8. Gnatushenko, V.V., Ali, D.: Studies of self-similar processes traffic based on the
ON/OFF model. In: Bulletin of the National University “Lviv Polytechnic”, Series
of “Computer Science and Information Technologies” - Lviv, No. 751, pp. 87–94
(2013). (in Ukrainian)
9. Ramirez-Pacheco, J.C., Torres-Roman, D., Toral-Cruz, H., Estrada-Vargas, L.: A
high performance tool for the test of long-memory and self-similarity. In: Simulation
Technologies in Networking and Communications: Selecting the Best Tool for the
Test, pp. 93–114. CRC Press, Taylor & Francis Group, USA (2014). https://doi.
org/10.1201/b17650-6
10. Estrada Vargas, L., Torres Romn, D., Toral-Cruz, H.: A study of wavelet analysis
and data extraction from second-order self-similar time series. Math. Probl. Eng.
2013, 1–14 (2013). https://doi.org/10.1155/2013/102834
 Researching Traffic with Self-similar Properties 25

11. Cajueiro, D., Tabak, B.: The rescaled variance statistic and the determination of
the Hurst exponent. Math. Comput. Simul. 70, 172–179 (2005). https://doi.org/
10.1016/j.matcom.2005.06.005
12. Mandelbrot, B.B.: The Fractal Geometry of Nature. W. H. Freeman, NewYork
(1982). https://doi.org/10.1119/1.13295. 550 p. 8
13. Senyk, P.: Reversal of incomplete Beta function. Ukrainian Math. J. 3, 325–333
(1969). (in Ukrainian)
 A Validation Method of a Real Network
Device Model in the Riverbed Modeler
Simulator

Dagmara Mazur(B)

Faculty of Cybernetics, Military University of Technology,

ul. gen. Urbanowicza 2, 00-908 Warszawa, Poland
[email protected]

Abstract. The paper proposes a validation method of a model of a

real routing device. In the developed method assessment of the device
model accuracy is made with the use of statistical inference method.
The paper presents results of research on the adequacy of the router
model operation in the Riverbed Modeler simulator in relation to the
operation of the real router in a real computer network environment.
The router model was validated for the behaviour of selected queuing
mechanisms. The obtained research results indicate the need to adapt
the router model in the Riverbed Modeler simulator in the field of tested
mechanisms before the model will be used to carry out research on these
mechanisms on a large scale.

Keywords: Simulation · Validation · Riverbed Modeler

Queuing mechanisms

1 Introduction
The development of the Internet and web applications forces the evolution and
appearance of new protocols and network mechanisms. Development or new
technologies creation can be performed using real networks or simulators. Con-
ducting research in both environments has its advantages and disadvantages.
Modifications of an existing protocol, implementations of a new protocol or a
network mechanism in real network devices involves high costs. The construction
of large real networks also means large financial and time outlays. However,
studies conducted in such networks allow to get accurate and detailed results
that may be observed in the target production environment.
By using simulators one can create only the model of real devices. Such a
model is only an approximate playback of phenomena or behaviours of a given
device. Computer simulation refers to mapping the actual behaviour of the device
through a computer program [1]. Simulators allow only to conduct research in
a virtual and not real environment. On the other hand, simulators have many
advantages [2] and some of them are as follows: possibility to study a very com-
plex phenomena, relatively easy way to change device parameters, a significant
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 26–39, 2018.
https://doi.org/10.1007/978-3-319-92459-5_3
 A Validation Method of a Real Network Device Model 27

reduction of financial outlays needed to carry out the research and short time
required for reconfiguration of all devices. There are many simulators available
on the market, some examples are as follows: ns-3 [3], Riverbed Modeler [4],
OMNeT++ [5], REAL [6], NetSim [7], QualNet [8], J-Sim [9], and SSFNet [10].
The aim of this paper is to present a developed method of checking whether
a given real network device model properly reflects this device in the scope
of a tested application. The developed method allows to answer the following
questions: whether the results of tests performed in the simulator coincide with
the results which were obtained in the real environment; whether a given model
of the device can be used for tests carried out on a large scale, without the use
of real devices and a computer network.

2 Related Works
In the literature one can find results of tests carried out using various simula-
tors confronted with results obtained in real networks. The paper [11] focuses on
the comparison of results obtained in the OPNET Modeler simulator (OPNET
Modeler is the previous version of the Riverbed Modeler simulator), the ns-2 sim-
ulator, and the real network. The research concerns the network transmission
study for two types of data streams: the Constant Bit Rate (CBR) and the File
Transfer Protocol (FTP). The another paper [12] also concerns a transmission
of the CBR data stream, but the FTP data stream is not taken into account.
Moreover, the authors compared results obtained in simulators considered in the
previous publication with results obtained in the QualNet simulator. The paper
[13] presents results of research on packets queuing mechanisms in the ns-2 sim-
ulator and compares them with results of testing the same mechanisms in a real
network. Respectively, work described in the paper [14] focuses on model credi-
bility verification for network devices used for military purposes in the OPNET
Modeler simulator. The research concerned packets queuing mechanisms opera-
tion in terms of the performance.
This paper presents research results on the adequacy of queuing mechanisms
operation implemented in the router model in the Riverbed Modeler simulator.
Simulation results are compared to research results achieved during testing the
operation of these mechanisms in a real network. The Riverbed Modeler simu-
lator was chosen for this research due to its popularity in academic, commercial
and industrial environments. The paper expands work presented in [13] and [14]
with different set of selected queuing mechanisms, and focuses on the comparison
of mechanisms behaviour. Additionally, in the developed method assessment, the
accuracy of the device model is performed with the use of statistical inference
method.

3 The Validation Method

The validation [15] is a process in which it is assessed whether a model intended
to represent any real phenomenon in the expected manner reflects this phe-
nomenon in the field of the tested application.
28 D. Mazur

Figure 1 shows a scheme of the validation process of the real device model.
The first step in the validation process is to conduct independent research in a
real and simulated environment. In the next step obtained research results are
compared with each other. If the developed device model does not reflect the
real phenomenon in the expected way, attributes of the device model should be
adjusted, and the research should be repeated in the simulated environment.
Then, the comparison of test results should be repeated. The device model
attributes are iteratively adjusted until the developed device model is reflect-
ing the real phenomenon in the expected way.

Fig. 1. Scheme of the developed validation process of the real device model.

Assessment of the accuracy of the reflection of the real phenomenon in the

device model can be based on selected, measurable technical parameters. These
parameters are characteristic for the researched phenomenon. The evaluation
accuracy of the device model may focuses on the behaviour study of the device
model (characteristics of a given phenomenon) or quantitative study of these
behaviours (values of given technical parameters).
The statistical inference method should be used for the device model evalu-
ation when quantitative study is subject to the research [16]. The method itself
allows to determine whether there is a significant statistical difference between
data samples received in the real and simulated environment. The method con-
sists of the following stages:
STAGE I: Formulating the null and alternative hypotheses, H0 and H1
respectively.
 A Validation Method of a Real Network Device Model 29

The null hypothesis H0 is the one to be checked. The alternative hypothesis

H1 is the one to be accepted when the null hypothesis is rejected.
STAGE II: Setting a level of significance α.
The level of significance α means probability of making mistake which con-
sists in rejecting the hypothesis H0 despite H0 is true.
STAGE III: Selecting a statistical test to check the null hypothesis H0 .
The statistical test selection depends on data samples type.
STAGE IV: Calculation of the value T of the selected statistical test based
on data samples.
STAGE V: Finding a critical value t for the fixed level of significance α.
The critical value t comes from statistical tables. Based on value t a decision
is made about acceptance or rejection of the null hypothesis H0 .
STAGE VI: Making decision about acceptance or rejection of the null hypoth-
esis H0 at the given level of significance α.
The null hypothesis H0 should be accepted when |T | < t. However when the
condition |T | < t is not met and the condition |T | ≥ t is true then the null
hypothesis H0 should be rejected and the alternative hypothesis H1 should be
accepted.
The acceptance of the null hypothesis ends the validation process with a posi-
tive result. The positive result means that the existing approximations of reality
in the device model do not significantly affect the mapped real phenomenon.
Moreover, the statistical method application proves positive result of the vali-
dation to be objective. The validated simulator model can be used to carry out
the same research in the case of a large scale network.

4 Completed Research
4.1 Research Environment
Research consist in checking the adequacy of operation of the router model in the
Riverbed Modeler simulator in relation to the operation of the real device. The
router model was validated for the behaviour of selected queuing mechanisms. To
conduct these research two environments should be prepared: real and simulated
ones. The physical topology of the real network is shown in the Fig. 2, and the
topology of the simulated network is shown in Fig. 3.
The real computer network has been equipped with two Cisco 2620 routers:
R1 and R2, two switches: S1 and S2 and traffic generator TG and traffic receiver
TR. The generator and the traffic receiver were realized using application IP
Traffic - Test and Measure [17]. In order to obtain correct research results traffic
generator TG and traffic receiver TR must indicate simultaneously the same
system time. Therefore, their operating system clocks were synchronized with
the clock of the external NTP server [18]. Both switches were connected with
other network elements using ethernet link with the bandwidth of 100 Mb/s, and
both routers were connected using serial link with the bandwidth of 128 kb/s.
This allowed the creation of a so-called bottleneck on the serial link, which is
necessary to observe the characteristic operation of selected queuing mechanisms.
30 D. Mazur

Fig. 2. Physical topology of the real network.

Analogically to the real computer network, the computer network in the

Riverbed Modeler simulator was built. The simulator network consists of two
Cisco 2620 routers: R 1 and R 2, two switches: S 1 and S 2, traffic generators
and traffic receivers (ethernet ip workstation adv [19]): TG 1, TG 2, TR 1, and
TR 2. There are more traffic generators and receivers than in the case of the real
network. This is because the Riverbed Modeler simulator traffic generator can
generate only one type of traffic – one traffic stream. In the simulated network,
traffic generators and receivers are not connected to the NTP server, because
their clocks are synchronized by the simulator. As in the real network, both
switches were connected to other network elements using ethernet link with the
bandwidth of 100 Mb/s, and both routers were connected using serial link with
the bandwidth of 128 kb/s.

Fig. 3. Physical topology of the simulated network.

 A Validation Method of a Real Network Device Model 31

4.2 Phenomena and Metrics Selected for the Validation of the

Router Model
In order to validate the Cisco 2620 router model in the Riverbed Modeler simu-
lator, there were selected following mechanisms and phenomena:
1. Priority Queuing (PQ) [20]: appropriation of the whole bandwidth by the
highest priority traffic.
2. Custom Queuing (CQ) [20]: preservation of the allocated bandwidth to a
given queue and rejection of packets that exceed the bandwidth allocated to
the given queue when the interface is saturated.
3. Low Latency Queuing (LLQ) [20]: limitation of the bandwidth on the priority
queue and rejection of packets that exceed the bandwidth allocated to the
given queue when the interface is saturated.
The accuracy of the reflection of the above mechanisms in the validated router
model was evaluated on the basis of the throughput parameter.

4.3 Routers Configuration

As part of the router model validation three tests: A, B, C were performed. The
routers configuration during each test is described below:

1. Test A: PQ mechanism was configured on router R1 and R 1.

2. Test B: CQ mechanism was configured on router R1 and R 1; In this mecha-
nism two queues were created; The first queue was intended for high-priority
traffic operation and was allocated 2/3 of the available bandwidth to it; The
second queue was dedicated to low-priority traffic and was allocated 1/3 of
the available bandwidth to it.
3. Test C: LLQ mechanism was configured on router R1 and R 1; In this mech-
anism two queues were created; The first queue is a priority queue, which
was intended for high-priority traffic operation and was allocated 64kb/s of
available bandwidth to it; The second queue was intended for low-priority
traffic and it was no restrictions imposed on it on the allocation of available
bandwidth.

4.4 Traffic Generators Configuration

Two traffic streams of constant bit rate (CBR) were generated during each test
(A, B and C). It means that the Packet Size and the Inter Arrival Time param-
eters were configured for both generated traffic stream. Each test was executed
in the real network and in the Riverbed Modeler simulator. Table 1 presents
detailed settings for the parameters of both traffic streams, and Fig. 4 shows the
time ranges in which traffic flows were generated.
Additionally in both traffic stream generators the MTU size parameter was
set the same. The MTU size parameter is a crucial factor which could influence
on a traffic streams characteristic. The generators ability to generate expected
32 D. Mazur

Table 1. Traffic streams parameters.

Number of traffic Throughput at layer Throughput at layer Priority of

stream 2 level of the 4–7 level of the traffic stream
ISO/OSI model ISO/OSI model [20]
Traffic stream no. 1 100 kb/s 89,2 kb/s High (ToS = 6)
Traffic stream no. 2 80 kb/s 69,2 kb/s Medium
(ToS = 4)

Fig. 4. Time intervals of generating traffic streams.

traffic streams characteristic was automatically validated by observation of the

traffic stream no 1 in the first 60 s of each test.
It should be noticed that the total sum of the throughput of both traffic
streams exceeds the available bandwidth of the serial link. Such throughput
values of traffic streams allow to observe the characteristic operation of each
tested queuing mechanism. Higher throughput values of traffic streams would
also give this opportunity.

4.5 Research Results

All performed tests A, B, and C were carried out in the real network and in the
Riverbed Modeler simulator. After the first series of tests, it turned out that
the throughput values of traffic streams sent by router R 1 in the simulator are
about 25% smaller than the values received on the router R1 in the real network.
The study of this case revealed the fact that both routers (R1 and R 1) with
configured the queuing mechanism on its interface, automatically reserve only
75% of the interface bandwidth for the needs of defined queues. In turn the real
router was using the remaining 25% of the interface bandwidth when no traffic
exist outside defined queues. The observed behaviour is the first discrepancy
found in the implementation of the router model in relation to the real device.
After customizing the configuration of router model in the Riverbed Modeler
simulator all tests were repeated in the real and simulated network. Adjusting
the configuration of the router model depends on setting the value of 100 in the
field max-reserved-bandwidth on its serial interface [21].
 A Validation Method of a Real Network Device Model 33

Data samples received from the real and simulated environment were checked
using the statistical inference method described in Sect. 3. Tests A, B and C were
in the scope of the statistical verification. One can find below the procedure used
for each stage of the mentioned method.
STAGE I: The following research hypotheses were formulated:
The null hypothesis H0 – The average of traffic stream throughput in the real
environment is not significantly statistically different from the average through-
put obtained in the Riverbed Modeler simulator.
The alternative hypothesis H1 – The average of traffic stream throughput
in the real environment is significantly statistically different from the average
throughput obtained in the Riverbed Modeler simulator.
STAGE II: Assumed α = 0, 05 as a level of significance.
STAGE III: Statistical Student’s t-test was selected, because all obtained
results have a normal distribution, sets of traffic stream throughput results in the
real environment and in the Riverbed Modeler simulator have similar numbers,
variances of results obtained in both environments are similar – homogeneous
and this results are measured on interval scale (interval) – samples can be ordered
and have a unit of measure [kb/s].
STAGE IV: A statistical Student’s t-test T value calculation with the follow-
ing equation:
X1 − X2
T = (1)
Sx1 −x2
  
(n1 − 1) · s21 + (n2 − 1) · s22 1 1
Sx1 −x2 = · + (2)
n1 + n2 − 2 n1 n2
where:
X1 − the average value of the traffic stream throughput in the real envi-
ronment
X2 − the average value of the traffic stream throughput in the Riverbed
Modeler simulator
s21 − the variance of traffic stream throughput in a real environment
s22 − the variance of traffic stream throughput in the Riverbed Modeler
simulator
n1 − the samples number of traffic stream throughput in a real environment
n2 − the samples number of traffic stream throughput in a real Riverbed
Modeler simulator
STAGE V: The critical value t is read from the Student’s t-distribution tables
for the level of significance α = 0, 05 and the number of degrees k of freedom
expressed by the formula:
k = n1 + n2 − 2 (3)
STAGE VI: When the following condition is met:
|T | < t (4)
Acceptance decision on the null hypothesis H0 is making and the alternative
hypothesis is rejecting H1 . Otherwise, the alternative hypothesis H1 is accepted.
34 D. Mazur

Expected Behaviours of Configured Queuing Mechanisms. Figures 5, 6

and 7 show respectively operating schemes of configured PQ, CQ, and LLQ
mechanisms in the real and simulated network. Each queuing mechanism is
implemented on routers R1 and R 1 for respective test execution (A, B, and C).
Routers R1 and R 1 receive packets on input interface from traffic streams no. 1
and no. 2. Packets from each traffic stream are classified based on the assigned
priority (ToS field values) and placed in the appropriate queue. Below describes
how each queuing mechanism continues to work according to the configuration
described in Sect. 4.3.

Fig. 5. The scheme of operation of the configured PQ mechanism.

PQ mechanism (Figure 5): Packets from traffic stream no. 1 are routed to the
high priority queue, and packets from traffic stream no. 2 are routed to the
medium priority queue; then the scheduling algorithm is putting the packets in
the router’s interface as per the rule: packets from a high priority queue have
priority over packets from other queues.

Fig. 6. The scheme of operation of the configured CQ mechanism.

 A Validation Method of a Real Network Device Model 35

CQ mechanism (Figure 6): Packets from traffic stream no. 1 are routed to the
first queue, and packets from traffic stream no. 2 are routed to the second queue;
then the Weighted Round Robin algorithm (WRR) is putting packets in the
router’s output interface. Packets from the first queue should be sent as first
until their total number of bits reach the value set for this queue (2/3 of the
serial link bandwidth).

Fig. 7. The scheme of operation of the configured LLQ mechanism.

LLQ mechanism (Figure 7): Packets from traffic stream no. 1 are routed to the
first queue – priority queue, and packets from traffic stream no. 2 are routed
to the second queue. Then the packets are scheduled in the router’s output
interface. Packets from the first queue should be sent as first until their total
number of bits reach the value set for this queue (64 kb/s – at the layer 2 level
of the ISO/OSI model).

Test A – Research Results. Figure 8 shows results of the conducted test A.

Research results shown that the throughput of the traffic stream no. 1 on router
R 1 is less by about 4kb/s than the throughput of the traffic stream no. 1 on
router R1. Mentioned difference in the throughput is observed from the moment
when the traffic stream no. 2 appears on the input interface of the R 1 and R1
routers. As a consequence, the described phenomenon causes the traffic stream
no. 2 in the Riverbed Modeler simulator to be about 4 kb/s higher than in the
real network. This means that the traffic stream no. 1 in the Riverbed Modeler
simulator does not cover the whole bandwidth.
The source of observed decreases and increases of the throughput on the
router’s output interface in the Riverbed Modeler simulator may be the auto-
matic application of mechanisms to optimize packet traffic efficiency at the
crowded router interface. Examples of such mechanisms include: compression
of packet headers, packet fragmentation or frame size modification at the layer 2
level of the ISO/OSI model. During the research both simulated and real routers
were not modified with mentioned mechanisms.
36 D. Mazur

Fig. 8. Graph of the throughput dependence on the time after conducting the test A.

After usage the statistical inference method, it turned out that for both traf-
fic streams the alternative hypothesis was accepted. The results of the average
throughput of the traffic stream no. 1 and no. 2 in the real environment signifi-
cantly differ statistically from the results of the average throughput of the traffic
stream no. 1 and no. 2 obtained in the simulator. This means a negative result of
the validation of the Cisco 2620 router model in the Riverbed Modeler simulator.
Current implementation of the router model cannot be used for conducting the
research of the PQ mechanism on a large scale network.
A detailed analysis of the code of the implemented PQ mechanism in the
Riverbed Modeler simulator and its impact on the obtained research results will
be the subject of further research.

Test B – Research Results. Figure 9 shows the results of the conducted test
B. The research results shown that the Cisco 2620 router model in the Riverbed
Modeler simulator perfectly reflects the behaviour of the real router for the CQ
mechanism. After 60 s of test B duration, the throughput of the traffic stream
no. 1 is equal to the bandwidth allocated to the first queue (approximately
77 kb/s – 2/3 of the available bandwidth), and the throughput of the traffic
stream no. 2 is equal to the bandwidth allocated to the second queue (approx-
imately 37 kb/s – 2/3 of available bandwidth). The rest of packets from both
streams is discarded.
As a result of usage the statistical inference method, it turned out that for
both traffic streams the zero hypothesis was accepted. The results of the average
throughput of the traffic stream no. 1 and no. 2 in the real environment do
not significantly differ statistically from the results of the average throughput
 A Validation Method of a Real Network Device Model 37

of the traffic stream no. 1 and no. 2 obtained in the simulator. This means a
positive result of the validation of the Cisco 2620 router model in the Riverbed
Modeler simulator. Current implementation of the router model can be used for
conducting the research of the CQ mechanism on a large scale network.

Fig. 9. Graph of the throughput dependence on the time after conducting the test B.

Fig. 10. Graph of the throughput dependence on the time after conducting the test C.
38 D. Mazur

Test C – Research Results. Figure 10 shows the results of the conducted test
C. The research results shown that the Cisco 2620 router model in the Riverbed
Modeler simulator does not introduce a bandwidth limitation for the first queue
(priority queue). Therefore, the research results conducted for the LLQ and PQ
mechanisms in the simulated network overlap with each other for both traffic
streams.
Despite such divergent research results, procedures of the statistical inference
method was conducted. The result of the Cisco 2620 router model validation in
the Riverbed Modeler simulator is negative as the null hypothesis was rejected.
Current implementation of the router model cannot be used for conducting the
research of the LLQ mechanism on a large scale network.

5 Summary

The paper describes the validation method of the real device model. In the
developed method assessment of the accuracy of the device model is made with
use of the statistical inference method.
The use of the developed method was demonstrated on the example of val-
idation of the Cisco 2620 router model. The paper presents research results on
the adequacy of operation of the router model in the Riverbed Modeler simulator
in relation to the operation of the real router in the real computer network. The
router model was validated for the behaviour of the PQ, CQ and LLQ mecha-
nisms. Accuracy assessment of the router model was made on the basis of the
throughput parameter.
After the first series of tests, it turned out that throughput values of traffic
streams received in the simulator were about 25% smaller than values received
in the real network. The developed model did not reflect the real phenomenon
in the expected way, so the configuration of the device model in the simulator
was adapted in accordance with the scheme of the validation process shown in
Fig. 1. Then the accuracy research of the model was repeated. For this purpose,
the statistical inference method was used, in which Student’s t-test was selected
to verify the research hypothesis.
After another iteration of the conducted research, the validation of the Cisco
2620 router model received a positive result only for the CQ mechanism. For the
PQ and LLQ mechanisms, the results of the average throughput of the traffic
stream no. 1 and no. 2 in the real environment significantly differ statistically
from the results of the average throughput of the traffic stream no. 1 and no. 2
obtained in the simulator. This involves a negative result of the validation of
the Cisco 2620 router model in the Riverbed Modeler simulator. The current
implementation of the router model cannot be used for conducting a research of
the PQ and LLQ mechanisms on a large scale network. Thus, another validation
of the router model in the field of the PQ and LLQ mechanisms should be
preceded by a modification of the implementation of these mechanisms in the
simulator; and that will be the subject of the further research.
 A Validation Method of a Real Network Device Model 39

References
1. Balci, O.: Validation, verification, and testing techniques throughout the life cycle
of a simulation study. In: IEEE Winter Simulation Conference, pp. 215–220 (1994)
2. Breslau, L., Estrin, D., Fall, K., Floyd, S., Heidemann, J., Helmy, A., Huang, P.,
McCanne, S., Varadhan, K., Xu, Y., Yu, H.: Advances in network simulation. IEEE
Comput. Magaz. 33, 59–67 (2000)
3. NS, Discrete Event Network Simulator. http://www.nsnam.org. Accessed 21 Feb
2018
4. Riverbed Modeller, Network Simulator. https://www.riverbed.com/. Accessed 21
Feb 2018
5. OMNeT++, Discrete Event Simulator. https://www.omnetpp.org/. Accessed 21
Feb 2018
6. REAL, Network Simulator. http://www.cs.cornell.edu/skeshav/real/overview.
html. Accessed 21 Feb 2018
7. NetSim, Network Simulation and Emulation Platform. http://www.tetcos.com/
index.html. Accessed 21 Feb 2018
8. QualNet, Network Simulator. www.scalable-networks.com. Accessed 21 Feb 2018
9. J-Sim, Java-based simulation system. http://www.physiome.org/jsim/. Accessed
21 Feb 2018
10. SSFNet. http://www.ssfnet.org/. Accessed 21 Feb 2018
11. Lucio, G.F., Paredes-Farrera, M., Jammeh, E., Fleury, M., Reed, M.J.: OPNET
modeler and NS-2: comparing the accuracy of network simulators for packet level
analysis using a network Testbed. In: ICOSMO, vol. 2, pp. 700–707 (2003)
12. Puneet R., Srinath P., Raghuraman R.: Bridging the gap between the reality and
simulations: an Ethernet case study. In: IEEE 9th International Conference on
Information Technology (ICIT 2006), pp. 52–55 (2006)
13. Andreozzi, S.: Differentiated services: an experimental vs. simulated case study.
In: IEEE Seventh International Symposium on Computers and Communications,
pp. 383–390 (2002)
14. Boltjes, B., Thiele, F., Fernandez Diaz, I.: Credibility and validation of simulation
models for tactical IP networks. In: IEEE Military Communications Conference,
pp. 1–10 (2006)
15. Heidemann, J.: Expanding confidence in network simulations. IEEE Netw. Magaz.
15, 58–63 (2001)
16. Kowalski, L.: Statystyka. Bel Studio, Warsaw (2005)
17. IP Traffic - Test and Measure. https://www.zticommunications.com/iptraffic/.
Accessed 21 Feb 2018
18. RFC 958: Network Time Protocol (NTP). http://tools.ietf.org/html/rfc958.
Accessed 21 Feb 2018
19. Adarshpal, S.S., Vasil, Y.H.: The Practical RiverbedUserR Guide for Computer
Network Simulation. CRC Press, Boca Raton (2013)
20. Odom, W., Cavanaugh, M.: Cisco QOS Exam Certification Guide. Cisco Press,
Indianapolis (2004)
21. Cisco website. http://www.cisco.com/c/en/us/support/docs/quality-of-service-
qos/qos-packet-marking/10100-priorityvsbw.html. Accessed 21 Feb 2018
 Energy Efficient MPTCP Transmission
Over Channels with a Common
Bottleneck

Michal Morawski(B) and Przemyslaw Ignaciuk

Institute of Information Technology, Lodz University of Technology,

215 Wólczańska St., 90-924 L
 ódź, Poland
{michal.morawski,przemyslaw.ignaciuk}@p.lodz.pl

Abstract. The majority of networking devices currently available are

equipped with a few communication interfaces. However, the design of
the fundamental transport protocol – TCP – prohibits using them simul-
taneously. Recently, a variant of TCP – Multipath TCP (MPTCP) – that
allows for parallel transmission over different paths has been developed.
The protocol itself does not define any particular way of splitting the
application data stream. Taking into account the proliferation of mobile
terminals, a good quality indicator is the amount of energy dissipated
by the communicating device. The previous works in the field assume
that the paths established by the MPTCP stack are independent. This
paper discusses the theoretical and practical aspects of stream splitting
when the paths influence each other through a common bottleneck. A
comparison with the reference solution is provided. The tests conducted
in the public networking environment show a substantial improvement
in energy economy.

Keywords: Multipath TCP · Load balancing · Energy efficiency

1 Introduction
Nowadays, the networking devices, like phones, laptops, or servers, have installed
multiple communication interfaces (NICs), e.g., Ethernet, WiFi, or cellular. How-
ever, the design restrictions of the protocols created in the past permit only one
interface to be actively engaged in serving the application data stream at a time.
The other interfaces are incorporated if the active one fails, or if the applica-
tion dictates a switch according to certain quality measure. Such behavior is no
longer satisfactory owing to the widespread use of radio technologies. Trying to
maintain the ongoing session within a chosen radio channel, with highly vari-
able temporal characteristics (determined by the distance from the access point,
nearby obstacles, node mobility, interferences, etc.), has negative impact on the
user’s experience [1,2]. Instead, one would opt for a communication solution in
which the traffic is dynamically distributed among the available interfaces, with
explicit consideration of their current transfer capabilities.
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 40–51, 2018.
https://doi.org/10.1007/978-3-319-92459-5_4
 Energy Efficient MPTCP Transmission 41

The recent proposals, like Multipath TCP (MPTCP) [3–5] promise to ensure
truly parallel and load-balanced traffic distribution. However, the reference
implementation of MPTCP [6] covers only the general protocol issues, leaving
area for further improvements and adjustments. One of such unresolved chal-
lenges – addressed in this work – is formulating a method of MPTCP stream
splitting into multiple sub-streams so that selected performance criteria are sat-
isfied. As the popularity and functional spectrum of mobile computers have out-
grown the progress in battery design, reducing the energy expenditure becomes a
critical factor to consider within the ever more stringent service and environmen-
tal constraints (green networking) [7]. Therefore, in the presented approach, the
emphasis is placed on improving the end user’s experience through better energy
economy while handling the transmission at the communicating terminals.
At a mobile device, the amount of dissipated energy depends both on the
power efficiency of NICs and application level activity, i.e., turning on and off
the display, triggering additional cores, GPU, or external sensors. For instance,
one can observe faster battery depletion when the data is sent though a secure
connection rather than in a plain-text form. The power drain rate also increases
when the information regarding the transferred data is rendered on the screen.
Therefore, in order to reduce the energy expenditure while effectuating the net-
work connectivity, one should shorten the time of data transfer and allow the
user to switch off the screen (and additional hardware components), or put the
application in an idle state. This paper proposes a new load-balancing solution
for the MPTCP scheduler, particularly well-suited for battery-powered devices
equipped with a few independent interfaces. Although addressing similar prob-
lems as in the current literature [8–11], the idea presented here differs both in
the objectives and in the way the traffic is distributed among the interfaces. The
paper focuses on the situation when the sub-streams directed through different
logical interfaces influence each other before reaching the destination, The trans-
mission through independent channels is considered as a special case, only. The
way the MPTCP stream is divided into sub-streams by the scheduler is deter-
mined as a solution of optimization problem set in a mathematical framework of
power dissipation. The performance assessment and comparison with the refer-
ence scheduler is not restricted to simulations but involves public networks and
real networking devices.

2 Multipath Data Transfer

The system architecture is illustrated in Fig. 1. In the considered communication
scenario, the user application seeks to send B bits of data to a remote peer. The
data is placed in the buffer held by a local MPTCP controller. The MPTCP
controller opens sub-channels and distributes the traffic among the correspond-
ing sub-streams that are left under the control of the ordinary, single path TCP
(SPTCP). The SPTCP flow control is executed separately for each sub-channel.
The research objective is to design an efficient load-balancing algorithm for the
MPTCP traffic scheduler. The operation of SPTCP within the sub-channels,
e.g., CUBIC, is not affected.
42 M. Morawski and P. Ignaciuk

SPTCP 1
SPTCP 1
MPTCP controller
MPTCP scheduler

NIC
MPTCP buffer
Channel 1

Applica on

Receiver
SPTCP N
SPTCP N
NIC
Channel n

Fig. 1. MPTCP architecture with local feedback – the current power profile of NIC
and SPTCP internals. Solid line – data, dashed line – acknowledgments.

The specification of MPTCP does not define how the user’s data should be
distributed among the sub-channels. Sometimes, it is appropriate to use only
one path and switch to another only when the quality of service drops below a
predefined level. The primary intention of MPTCP, however, is to employ multi-
ple channels simultaneously. In its reference implementation [6], three schedulers
have been defined:
(a) round-robin – evenly distribute subsequent segments among the sub-
channels (insignificant in practice, serve as a theoretical baseline),
(b) redundant – send the same segment through all the available sub-channels
– results in low latency but leads to increased bandwidth consumption,
(c) default – send the data using the channel with the lowest smoothed round-
trip time (SRTT). Smoothing is performed by the filter typical for the
selected SPTCP dialect.
Solution (c) – proposed to increase the total effective throughput – is strongly
recommended by the authors of implementation [6]. In this paper, this solution is
treated as a reference one. Other schedulers described in the current literature,
e.g., [8–11], have not been adopted in the formal development works. On the
other hand, the default scheduler suffers from a number of disadvantages:
– sticky behavior [12] – when the smoothed round-trip time (SRTT) differs a
little among the active channels, the one with the shortest SRTT value is used
exclusively,
– imprecise SRTT estimates – and thus wrong channel selection – originating
from the buffer bloat (different, but generally large, queue lengths in the
buffers of intermediate devices on the established paths),
– Karn’s algorithm implications,
– spurious acknowledgments – if the channels differ much in their properties,
then the retransmission timeout (RTO) at the MPTCP level can be shorter
than the variance of SRTT in the ‘worse’ ones; then, the MPTCP stack mis-
takenly signals the sender that a segment has been lost;
– head-of-line blocking – if the buffers are too short at the end-points, then
some data cannot be temporary sent via the available channel because there
are unacknowledged data transmitted previously through the ‘worse’ ones.
 Energy Efficient MPTCP Transmission 43

3 Energy Considerations and Optimal Load Distribution

In the mobile devices, the GPU, CPU, and display tend to consume more energy
than the network interfaces. The NIC energy expenditure depends on the trans-
mission power, noise level, number of retransmissions, and control plane activity.
These factors differ among the interfaces and their mode of operation. In general,
the transmit power is highly variable in time [13], but even the median measure-
ments differ much. The power effectiveness for the transmission can be as low
as 2 [mW/Mbps] for cable NIC (e.g., Ethernet), and as high as 440 [mW/Mbps]
for LTE NIC. Similarly, the power necessary to keep the interface in the opera-
tional state can be as low as 90 [mW], and as high as 1440 [mW], for the same
interfaces, respectively [10]. Hence, the energy dissipated by the NICs does not
have to be comparable with the energy consumed by the operating system and
application activities (200–300 mW in low-end systems up to 300 W in high-end
ones). Therefore, in order to reduce the overall energy expenditure during the
data transfer the following optimization problem may be considered – minimize
ϑ given by

n
ϑ= ϑi + D max Ti (1)
i=1

subject to Ti > 0, where

 Ti
ϑi = pi (t)dt (2)
0

is the total energy dissipated by interface i ∈ [1, n], n being the number of
interfaces, pi (t) > 0 is the power necessary to transmit the data through this
interface at time t, Ti is the total transmission time at this interface, and D > 0 is
the power consumed by non-NIC system components (display, additional cores,
sensors, etc.). D can be obtained as a difference between the power consumed
at a given moment and the power drained when the system is in an idle state.
Meanwhile, the transmit power pi (t) [W] is a function of the power efficiency
of NIC – ρi (t) [W/bit], the number of bits sent through channel i – bi , and the
power necessary to keep the NIC in the operational state – wi [W]. It can be
expressed as

pi (t) = ρi (t)bi + wi (t), (3)

with ρi (t) and wi (t) being functions of:

– the distance from the end-point to the hub (access point, head-end, or BTS),
– the mode of operation, which includes the selection standard ‘b’, ‘g’, ‘n’, ‘ac’,
band, RTS, or CCA mode in WiFi and band, GPRS, or the revision of the
UMTS class in the case of cellular interfaces,
– interferences level, number of retransmissions at the link layer.
44 M. Morawski and P. Ignaciuk

Due to large number of factors affecting ρi (t) and wi (t), these profiles should
be directly measured by the communication end-point (e.g., such approach is
suggested in [8]). The profile varies with time as a result of node mobility, con-
troller activity, or other terminals behavior. Here, piece-wise constant evolution
is assumed.

4 Analytical Background
Often, the paths established by the MPTCP subsystem are independent, i.e.,
there is no common bottleneck between the communicating peers. An energy-
oriented solution for the independent channels case has been presented in [13].
However, such premise is not always justified. The streams may encounter a
common bottleneck, or interfere through a third-party connection. The mutual
dependency may be persistent or temporary, and may result in network or appli-
cation performance decrease and is both difficult to predict and not necessarily
related to a common protocol framework. In the conducted tests: identical con-
nection end-points, transmission proceeding at the same time, yet using different
protocols; the paths differ significantly in SRTT (ipv4: 40–110 ms and ipv6: 60–
300 ms) and number of hops (ipv4: 9 hops and ipv6: 17 hops). Moreover, as the
ipv6 traffic traverses the potentially congested international backbone, it is more
likely to be exposed to throughput fluctuations.
In this paper, extremum seeking control [14] is used as a basis to find a
solution to problem (1) when the channels cannot be treated as independent
of each other. The idea behind extremum seeking control is to obtain optimal
system performance (according to a chosen measure) for an uncertain, possibly
non-linear dynamic system by probing it through a known excitation injected
into the control input. By observing the system response and the gradient of
performance index it is possible to retrieve the unknown plant properties. In the
typical implementation, the estimate of performance index gradient is obtained
through a periodic excitation applied to linear system representation. Usually,
this signal is much faster than the nominal plant dynamics. The response induced
by the injected perturbation can then be removed by a low-pass filter (Fig. 2).
Owing to the hard non-linearities and delays, the classical extremum seek-
ing approach cannot be directly applied to optimize the MPTCP transmission.
Therefore, in this work, a modified method is elaborated. In the classical app-
roach, by observing the performance index gradient, one estimates the unknown
system parameters. In the method proposed here, the system parameters (path
properties) are determined with high accuracy and thus assumed known, whereas
the gradient measurement is used to decide whether the mutual dependency
among the MPTCP sub-channels occurs, or not. The channels are deemed unre-
lated (independent) if the gradient is zero. Otherwise, an appropriate action
needs to be taken, as illustrated in Fig. 2. In the discussed method, in order
to assess the extent of mutual dependency of the sub-streams, the gradient of
performance index (1) needs to be evaluated. It is assumed that the device estab-
lishes two paths only, as is the most common situation in the considered applica-
tion area. The power efficiency is improved by changing the sub-channels load so
 Energy Efficient MPTCP Transmission 45

Plant with unknown parameters

Gradient es ma on and
Low-pass
+ feedback parameter
filter
adjustment

Addi onal excita on

1 c1
Plant (path 1) with known parameters Unknown ϑ
coupling
2 c2 parameters
Plant (path 2) with known parameters

Gradient es ma on and
Low-pass
feedback parameter
filter
adjustment

Fig. 2. Classical approach to extremum seeking control [14] (above) and the proposed
one (below) with the additional excitation replaced by a legitimate signal from other
channels.

that the gradient ∇ϑ = ϑ̇ ≤ 0. Since the performance index ϑ(t) = f (c1 (t), c2 (t)),
the chain rule applied to (1) leads to
∂ϑ ∂ϑ
ϑ̇ = ċ1 + ċ2 ≤ 0. (4)
∂c1 ∂c2
Assuming pi and D change sufficiently slow, the energy expenditure related
T
to channel i may be approximated as ϑi = 0 i pi (t)dt ≈ pi Ti . Then, rewriting
(1) with Ti ≈ bi /av(ci ) and max Ti ≈ (b1 + b2 )/[av(c1 ) + av(c2 )], one obtains
b1 b2 b1 + b 2
ϑ = ρ1 + ρ2 + Dw , (5)
av(c1 ) av(c2 ) av(c1 ) + av(c2 )

where av(ci ) = fi /τi is the average throughput of channel i obtained as the

fraction of in-flight (i.e., sent but not acknowledged yet) data (fi ) and SRTT
(τi ). Dw equals D + w1 + w2 . The quantities fi and τi are available in any
contemporary SPTCP stack.
Applying multivariable chain rule (4) to (5), the gradient is determined as
b1 b2 b1 + b 2
∇ϑ = ϑ̇ = −ρ1 ċ1 − ρ2 2 ċ2 − Dw 2 (ċ1 + ċ2 ) . (6)
av2 (c1 ) av (c2 ) [av(c2 ) + av(c2 )]

The term ρi bi /av2 (ci ) in (6) can be physically interpreted as the inverse of energy
efficiency of path i and Dw (b1 + b2 )/[av(c1 ) + av(c2 )]2 , as the inverse of energy
efficiency of the communicating device as a whole.
Since by definition ρi , ci , bi , and Dw are all positive and bounded, according
to (6), the gradient follows the changes of the
  channel capacity (with reverse sign)
 
and the energy dissipation decreases with ϑ̇ increasing. Therefore, the minimum
46 M. Morawski and P. Ignaciuk

energy dissipation – the largest gradient – is achieved by transferring the data

as fast as possible, i.e., when ċi → ∞. On the other hand, the channels have
limited capacity and the derivatives in Eq. (6) cannot be positive all the time.
In particular, when the common bottleneck is encountered, then the derivatives
ċi differ in sign, and the gradient value is determined by the power efficiency of
the transmitting device.

Remark 1. In some publications, e.g., [15], the use of correlation is advocated

to assess the channel coupling. The correlation-based methods, however, require
long measurement history to infer about the channel dependency due to temporal
differences (mainly SRTT fluctuations). For the practical reasons, a method with
short memory is preferable, as proposed in this work.
Reordering the terms in (6) yields

−ρ1 av2b(c
1
1)
ċ1 − ρ2 av2b(c
2
2)
(7)
−Dw [av(c )+av(cb1
)] 2 (ċ1 + ċ2 ) − Dw
[av(c
b2
2 (ċ1 + ċ2 ) ≤ 0.
1 2 1 )+av(c2 )]

Thus,

b1 ρ2 av21(c2 ) ċ2 + Dw [av(c )+av(c

1
2 (ċ1 + ċ2 )
2 )]
≥− 1
1
1 , (8)
b2 ρ1 av2 (c1 ) ċ1 + Dw [av(c )+av(c )]2 (ċ1 + ċ2 )
1 2

if the denominator is positive and

b1 ρ2 av21(c2 ) ċ2 + Dw [av(c )+av(c

1
2 (ċ1 + ċ2 )
2 )]
≤− 1
, (9)
b2 ρ1 av21(c1 ) ċ1 + Dw [av(c )+av(c
1
)]2
(ċ1 + ċ2 )
1 2

otherwise.
In the steady state, when ċi → 0, applying L’Hôpital’s rule to (8) (or (9)),
one obtains

b1 ρ2 av21(c2 ) + Dw [av(c )+av(c

1
2
2 )]
=− 1
1
1 . (10)
b2 ρ1 av2 (c1 ) + Dw [av(c )+av(c )]2
1 2

Inequalities (8)–(10) define the scheduler for coupled channels. If b1 > b2

the current segment ought to be transmitted by channel 1, and by channel 2,
otherwise.

5 Implementation Issues
For the purpose of verification of the developed load-balancing strategies a new
Linux kernel module implementing (8)–(10) has been created. In addition to
this new scheduler, the Linux implementation encompasses the standard path-
manager that establishes the paths along which the data will be directed and
MPTCP master controller that targets the fairness issues. Since the objective of
 Energy Efficient MPTCP Transmission 47

this work is to provide a method of stream division, only the scheduler has been
modified with respect to the reference MPTCP implementation [6]. The other
modules are left unaltered with the parameters set at their defaults, i.e., the
path manager operates in the full-mesh mode (the number of sub-streams is the
product of the number of logical interfaces at both peers) and no specific master
control is executed. The standard Linux congestion control algorithm (CUBIC)
supervises the individual SPTCP sub-streams.
In contrast to the default scheduler, in the proposed approach, the previously
selected paths influence the present scheduling decisions. To properly evaluate
(8)–(10), the scheduler uses the internal SPTCP variables (fi and τi ). In addition,
it needs to track variable ci to obtain ċi . For that purpose, a recurrent filter
(typical for the TCP implementations) is used, namely,

ċi (k) = (1 − α) ċi (k) + α (ci (k) − ci (k − 1)) , (11)

where k denotes the subsequent time instants of ċi evaluation. The averaging
coefficient α has been experimentally chosen as 1/16. In order to obtain the
allocation decision, scheduler (8)–(10) performs two iterations per MPTCP seg-
ment (mptcp for each sk loop): the first one provides the sub-stream coefficients
(ċi ), the second one finds the best channel for data transfer. The details of the
kernel module organization and power measurement one can find in [13], where
the case of independent channels has been considered. In the tests described
here in Sect. 6, the following artificially injected patterns have been applied: (a)
constant, (b) linear increase/decrease (simulates moving away, or getting closer
to a link layer hub), (c) stepwise (simulates handover, or getting in or out of
a radio shadow), and (d) oscillatory (simulates channel fading). Consequently,
in addition to already covering a broad spectrum of practical networking situa-
tions, new profiles can be seamlessly introduced into the applied framework for
conducting a variety of tests.

6 Evaluation

The developed scheduling solution has been verified using the setup based on the
general system architecture depicted in Fig. 1. The popular low-end Raspberry
Pi device has been chosen as the MPTCP client and a high-end virtual machine
in the local data center (in the cloud ) as the server, which corresponds to the typ-
ical use pattern in the MPTCP networking. During all the tests the server runs
unmodified, following the standardized MPTCP rules. In all the experiments,
the public network (neither Intranet, nor closed simulations) is employed. While
in such environment a single measurement is hardly repeatable, a large number
of trials allows one to filter the artifacts and gives a sound basis for the pro-
tocol assessment in a realistic rather than artificially created lab environment.
To minimize the influence of channel temporal variations and give statistically
meaningful results, the tests have been repeated multiple times.
48 M. Morawski and P. Ignaciuk

6.1 Test Scenarios

Two channel combinations have been tested. In the first one – scenario 1 –
the probability of a common bottleneck is low, in the second – scenario 2 –
high. The first scenario represents the case of a smartphone, or an IoT device
[16,17], communicating with the server, with one interface connected to a cable
network and the second inter-face connected to an LTE network. The cable and
LTE networks are unrelated. The measured initial SRTT of the cable network
channel varies within 70–85 ms and the segments traverse 7 hops, whereas for
the LTE connection the SRTT fluctuates within 80–400 ms and the segments
encounter 9 hops before reaching the destination. In the second scenario, the
same interface is used by the endpoints, yet the channels differ in the applied
network protocol. Such paths frequently influence each other. During the tests,
the first path consists of 9 hops and the measured SRTT varies in the interval
40–110 ms and the second path covers 17 hops with the SRTT fluctuating in the
range 60–300 ms.

6.2 Test Case Conditions

In all the tests, Dw = 600 [mW], ρ1 = 30 [mW/Mb], ρ2 = 400 [mW/Mb] (sce-

nario 1) and ρ1 = ρ2 = 140 [mW/Mb] (scenario 2). A single test case (in both
scenarios) involves an iperf3 generated stream controlled first by the default
scheduler, next by the proposed energy-aware one. The tests are performed at
different days and times, and using different power profiles. As already men-
tioned, in order to obtain statistically relevant results the tests are repeated
multiple times and are executed at different times and days. During all the tests
the gain is defined as
 
G = ϑdefault − ϑproposed /ϑdefault , (12)

where ϑdefault is the energy dissipated when the default scheduler operates,
whereas ϑproposed refers to the energy expenditure of scheduler (8)–(10).

6.3 Test Results

Selected test results are presented in Table 1. The advantages of using the pro-
posed power-aware scheduler are highlighted when the amount of fluctuations
(congestion incidents, interferences, etc.) in the network grows. The advantages
of the discussed solution are particularly visible during rush hours (7–8 PM).
In scenario 1, the proposed scheduler outperforms the default one in terms of
lower energy expenditure (10–36%), and occasionally in terms of throughput. In
an uncommon situation, when the channel with a shorter SRTT dissipates more
energy (LTE), it is possible to obtain the gain as high as 90%. In scenario 2, the
power-aware scheduler gives 4–10% better results (maximum 12%) with respect
to the reference one.
 Energy Efficient MPTCP Transmission 49

Table 1. Experiment results. T – Time of transmission [s], ϑ – dissipated energy [J],

G – gain in applying energy-aware solution [%]. R – rush hours (7–8 PM), E – Early
morning (5–6 AM), O – ordinary hours (1 PM–4 PM).

Scenario 1 Scenario 2 When

Default Proposed Default Proposed
T ϑ T ϑ G T ϑ T ϑ G
8.58 7.99 7.99 7.99 8 9.56 6.45 9.50 6.41 1 E
8.20 8.01 8.01 8.01 11 9.52 6.37 9.45 6.35 0 E
9.35 9.02 9.02 9.02 3 10.62 7.16 10.07 6.91 4 O
9.82 8.34 8.34 8.34 14 10.66 7.19 10.20 6.97 3 O
11.59 9.12 9.12 9.12 21 9.95 6.60 9.72 6.56 1 O
22.55 16.1 16.1 16.1 23 13.07 7.71 11.41 7.06 8 R
22.82 15.5 15.5 15.5 36 12.93 7.55 11.52 7.12 6 R

During ordinary hours (12 AM–4 PM), in scenario 1, the gain of using the
energy-aware schedulers oscillates between 3% and 25% and differs much in
subsequent test runs. Nevertheless, a case when the gain is negative has not
been observed. In scenario 2, the power saving is smaller gain is smaller than in
rush hours yet still meaningful with respect to the default solution.
When the network traffic is stable and low (e.g. in the early morning – 5–
6 AM) the proposed scheduler provides limited gain. The allocation decisions
are highly influenced by the buffer-bloat phenomenon (BB). While other net-
work users are absent, large buffers in the intermediate devices prohibit the
cwnd reduction at the end-points and SRTT increases. When the default sched-
uler controls the segment-to-path assignment, the energy greedy interface (LTE)
is erroneously chosen over the more economic one if the SRTT, elongated by BB,
exceeds the transfer time in the expensive one. The proposed scheduler is immune
to the BB effects – see also [18]. When the throughput does not undergo signif-
icant variations (ċi ’s are close to zero), then the proposed scheduler operates in
the steady-state conditions according to (10). Except for the segment ordering
there are no substantial differences comparing to the reference solution.

6.4 Detailed Analysis

An example run of scheduler (8)–(10) under scenario 2 is illustrated in Fig. 3.

The established paths have similar initial SRTT and they are exposed to BB
(SRTT grows from the initial 52 ms for channel 1 and 69 ms for channel 2,
respectively, up to 400 ms as a result of buffering in the intermediate routers).
At the beginning of the transmission, the scheduler is in the steady state (the
split ratio is constant) and it allocates the channels according to (10). At t ≈
4 s, stream 2 experiences a congestion incident. Both the in-flight data (f2 )
and throughput (c2 ) are reduced, thus ċ2 < 0. Then, according to rule (9),
50 M. Morawski and P. Ignaciuk

450 250 8
SPTCP#1
400 SPTCP#2 7
350 200
6

Throughput [Mbps]
in-flight data [seg]
300
SRTT [ms]

150
250 5

200 4
100
150
3
100 50 SPTCP#1
SPTCP#1 2 SPTCP#2
50
SPTCP#2 MPTCP
0 0 1
0 2 4 6 8 10 0 2 4 6 8 10 0 2 4 6 8 10
Time[s] Time[s] Time[s]

Fig. 3. Performance of the proposed scheduler in scenario 2, sampling period 0.5 s:

SRTT (left), in-flight data (middle), throughput (right).

the transfer speed in stream 2 is throttled, and in stream 1 it accelerates. Since

the sum av(c1 ) + av(c2 ) is approximately constant, the stream 2 cannot increase
its speed and the transmission proceeds mainly in channel 1.

6.5 Beneficial Side Effects

As a beneficial side effect, it has been noticed that even if the power coefficients
are not considered in the allocation decisions (ρ1 = ρ2 = 1, D = Dw = 0 in
(8)–(10)), the energy-aware scheduler gives on average a few-percent improve-
ment over the default one. This gain increases with the throughput fluctuations.
It is attributed to the BB reduction (as noticed also in the case of SPTCP in
[18]). Moreover, without any tricky heuristics, or link layer dependency [6], the
jitter is constrained to 2–4 segments and fast response to the channel variability
is obtained. In consequence, the redundant scheduler from the standard imple-
mentation [6] need not be applied, low buffer occupancy is observed, and the
risk of head-of-line blocking is limited. All these favorable characteristics are
obtained at a small computational cost.

7 Summary and Conclusions

The paper presents a new stream splitting algorithm for the MPTCP traffic
scheduler for the paths encountering a common bottleneck. In the proposed
solution, the load over the available network interfaces is distributed so as to
achieve low energy consumption. Thus, it is particularly well-suited for mobile,
battery-powered devices, like tablets, or smartphones. The algorithm is formu-
lated on the basis of a modified extremum seeking approach. By incorporat-
ing broader information about the channel dynamic characteristics, the energy
efficiency as compared with the default, recommended solution, is improved.
Numerous experiments (conducted in the open, public Internet, as opposed to
the commonly-applied simulated environments) show several percent reduction
in the energy expenditure. In many of the analyzed cases, higher throughput is
also attained. As a result, the energy economy of the multipath transfer in a
dynamic networking environment can be enhanced.
 Energy Efficient MPTCP Transmission 51

References
1. Ignaciuk, P., Bartoszewicz, A.: Congestion Control in Data Transmission Networks:
Sliding Mode and Other Designs. Springer, London (2013). https://doi.org/10.
1007/978-1-4471-4147-1
2. Ignaciuk, P., Karbowańczyk, M.: Active queue management with discrete sliding
modes in TCP networks. Bull. Polish Acad. Sci. Tech. Sci. 62(4), 701–711 (2014)
3. Peng, Q., Walid, A., Hwang, J., Low, S.: Multipath TCP: analysis, design, and
implementation. IEEE/ACM Trans. Netw. 24(1) 596–609 (2016)
4. Xu, C., Zhao, J., Muntean, G.: Congestion control design for multipath transport
protocols: a survey. IEEE Commun. Surv. Tutor. 18(4), 2948–2969 (2016)
5. Ford, A., Raiciu, C., Handley, M., Bonaventure, O.: TCP extensions for multipath
operation with multiple addresses. Technical report 6824, RFC (2013)
6. Barré, S., Paasch, C.: Multipath TCP Linux Kernel implementation. http://www.
multipath-tcp.org
7. Kwak, J., Choi, O., Chong, S., Mohapatra, P.: Processor-network speed scaling
for energy-delay tradeoff in smartphone applications. IEEE Trans. Netw. 24(3),
1647–1660 (2016)
8. Deng, S., Netravali, R., Sivaraman, A., Balakrishnan, H.: WiFi, LTE, or both?
measuring multi-homed wireless internet performance. In: Proceedings on ACM
IMC, Vancouver, Canada, pp. 181–194 (2014)
9. Paasch, C., Ferlin, S., Alay, O., Bonaventure, O.: Experimental evaluation of multi-
path TCP schedulers. In: Proceedings on ACM SIGCOMM CSWS, Chicago, USA,
pp. 27–32 (2014)
10. Hwang, J., Yoo, J.: Packet scheduling for multipath TCP. In: Proceedings on 7th
International Conference on Ubiquitous and Future Networks, Sapporo, Japan, pp.
177–179 (2015)
11. Peng, Q., Walid, A., Chen, M., Low, S.: Energy efficient multipath tCP for mobile
devices. In: Proceedings on 15th ACM International Symposium on Mobile Ad
Hoc Networking and Computing, Philadelphia, Pennsylvania, USA, pp. 257–266
(2014)
12. Arzani, B., Gurney, A., Cheng, S., Guerin, R., Loo, B.: Impact of path charac-
teristics and scheduling policies on MPTCP performance. In: Proceedings on 28th
International Conference on Advanced Information Networking and Applications
Workshops (AINA), Victoria, BC, Canada, pp. 743–748 (2014)
13. Morawski, M., Ignaciuk, P.: On implementation of energy-aware MPTCP sched-
uler. In: Borzemski, L., Światek,
 J., Wilimowska, Z. (eds.) ISAT 2017. AISC,
vol. 655, pp. 242–251. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-
67220-5 22
14. Ariyur, K., Krsti, M.: Real-Time Optimization by Extremum-Seeking Control.
Wiley, Hoboken (2003)
15. Kou, L., Liu, J., Hu, M.: A multiple-path TCP congestion control algorithm based
on sub flow correlation matrix. In: Proceedings on International Conference on
Cloud Computing and Internet of Things, Changchun, China, pp. 140–144 (2014)
16. Morawski, M., Ignaciuk, P.: Reducing impact of network induced perturbations in
remote control systems. Control Eng. Pract. 44(10), 127–138 (2016)
17. Morawski, M., Ignaciuk, P.: Network nodes play a game - a routing alternative in
multihop ad-hoc environments. Comput. Netw. 122, 96–104 (2017)
18. Cardwell, N., Cheng, Y., Gunn, C., Yeganeh, S., Jacobson, V.: BBR: congestion-
based congestion control. Commun. ACM 60(2), 58 (2017)
 Light-Weight Congestion Control
for the DCCP Protocol for Real-Time
Multimedia Communication

Robert R. Chodorek1(B) and Agnieszka Chodorek2

1
Department of Telecommunications, The AGH University of Science
and Technology, Al. Mickiewicza 30, 30-059 Krakow, Poland
[email protected]
2
Department of Information Technology, Kielce University of Technology,
Al. Tysiaclecia Panstwa Polskiego 7, 25-314 Kielce, Poland
[email protected]

Abstract. The Datagram Congestion Control Protocol (DCCP) is a

multi-purpose transport protocol that does not preserve reliability of
transmission. The DCCP was intended to convey large amounts of data,
especially in the real-time - which makes it suitable for real-time multi-
media applications. Consequently, the RTP/DCCP protocol stack can be
used for data transmission (instead of the RTP/UDP protocol stack, typ-
ically used during the transmission of real-time multimedia), when the
DCCP works in mode CCID 3 (TCP-Friendly Rate Control, TFRC).
However, the TFRC manifests strong equality towards competing
TCP flows, which (in some situations) can lead to the degradation of the
multimedia stream transmitted over the TFRC. In this paper we describe
the light-weight congestion control mechanism, previously designed by
the Authors for TFRC-based real-time multimedia communication. The
mechanism is based on the TFRCs congestion control, in which the orig-
inal TFRCs throughput equation was substituted with a linear through-
put equation. The mechanism that was introduced for the DCCP imple-
mentation and the results of experiments carried out in a mixed (real
and emulated) network show that this type of congestion control is more
suitable for multimedia than the DCCP working in the standard CCID
3 mode.

Keywords: Multimedia · Real-time · DCCP · Congestion control

1 Introduction

Modern communication is based on convergent, multi-service networks, where

data traffic and multimedia traffic coexist in shared links. These two kinds of
traffic have two different quality of service (QoS) requirements, as well as two
different approaches to the problem of network congestion. As a result, when a
window-controlled data stream meets with a multimedia stream, which cannot
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 52–63, 2018.
https://doi.org/10.1007/978-3-319-92459-5_5
 Light-Weight Congestion Control for the DCCP Protocol for Real-Time 53

be window controlled, the stream may not be congestion controlled at all. Such
multimedia streams are called unresponsive, in that they cannot respond to
congestion. If an unresponsive flow meets a congestion controlled (responsive)
flow in the same link, the unresponsive flow shows a tendency to dominate the
transmission in the link. It was observed that in the case of Transmission Control
Protocol (TCP) transmissions, multimedia can overwhelm the traffic for TCP
flows. Lack of TCP-like congestion control was blamed for this effect, so protocols
that implements TCP-like congestion control are called TCP-friendly protocols.
For the last few years, because of a significant amount of multimedia traffic
in overall communication traffic, newly designed protocols are often required to
be TCP-friendly [2,9,16,17]. Nowadays, web browsers that use the Real-Time
Communications (WebRTC) technologies enable congestion control for trans-
mission of multimedia data, based on the TCP-Friendly Rate Control (TFRC)
[7] congestion control mechanism [10].
However, obligatory TCP-friendliness can cause problems in the case of real-
time multimedia transmissions carried out in medium and heavily congested net-
works. The aim of this paper is to analyze a light-weight congestion mechanism
intended for the Datagram Congestion Control Protocol (DCCP) working in the
TFRCs congestion control mode. The mechanism was designed for real-time mul-
timedia communication in medium and heavily congested networks. It is an imple-
mentation of our previous work [1], in which we substitute a linear throughput
equation for the original TFRCs throughput equation in the DCCP protocol.
The paper is organized as follows. The next Section is devoted to the
DCCP protocol. In Sect. 3 we describe the light-weight congestion control mech-
anism implemented for the DCCP protocol that conveyed real-time multimedia.
Section 4 shows the experimental environment that combines real network equip-
ment and an emulation server. Section 5 presents results of the experiments car-
ried out in the mixed, real and emulated environment. Section 6 summarizes our
experiences.

2 The DCCP Protocol and Its Use for Multimedia

Transmission
Typically, real-time multimedia transmission is carried out using the User Data-
gram Protocol (UDP), which in the case of professional and semi-professional
applications is often supplemented by the Real-time Transport Protocol (RTP),
working on top of the UDP, and using its checksum and multiplexing services.
The transport layer is divided into two sublayers, where the RTP occupies the
upper sublayer, and the UDP the lower one. Because of the lack of congestion
control in both transport protocols1 , the Datagram Congestion Control Protocol,
specified in the RFC 4340 [13], is intended to be used instead of the UDP.
1
The UDP is not congestion controlled at all. The RTP also isn’t congestion con-
trolled, however it supports media translators, which usually are placed at the bound-
ary of high-speed and slow network. Translators lower bit rate of transmitted stream
and make it available for low-speed clients.
54 R. R. Chodorek and A. Chodorek

The DCCP is a multi-purpose transport protocol, designed to convey a large

amount of data, such as the UDP. In contrast to the UDP, which is able to
create both unicast and multicast connections, the DCCP transmits data only
via unicast connections. Both the UDP and the DCCP do not assure reliable
data transfer2 , which makes the protocols suitable for streaming media and other
real-time applications.
The DCCP doesn’t support specific multimedia services (such as, for exam-
ple, timestamps or source identifiers), so professional and semi-professional use of
the DCCP for multimedia transmission requires the co-operation of the protocol
with other transport protocols, that are able to assure the necessary function-
alities. If the DCCP works with RTP-transported multimedia, the protocol will
replace the UDP in the RTP/UDP protocol stack and the RTP/DCCP protocol
stack is constructed.
Its worth noting that the replacement of the UDP by the DCCP limits the
functionality of the overlaying protocol. The RTP is a multicast protocol, but
the underlying DCCP - due to its unicast nature - confines it to point-to-point
transmissions. This is not noticeable in the case of naturally unicast services,
such as video telephony or Video on Demand (VoD), but multicast multimedia
services must substitute one multicast connection with a series of unicast ones.
The DCCP implements multi-mode congestion control of unicast connec-
tions. Each congestion control mode is identified by a Congestion Control Iden-
tifier (CCID). The specification of the protocol assigns only CCID 2 and 3, while
CCID 0–1 and 4–255 are reserved for future applications. Both modes offer TCP-
friendly congestion control, which is able to use both implicit (through packet
loses) and explicit (through ECN signalling) congestion notification. However,
they achieve TCP-friendliness of DCCP flows with the use of different methods
of building TCP-like congestion control:

– direct implementation of TCP’s congestion control mechanism,

– emulation of TCP’s behavior with the use of mathematical modelling.

The first method directly implements the mechanism specified in the RFC
2581 [18] document - including the congestion control window, two areas of
probability (low and high probability of congestion increases) associated with
the mechanisms of slow start and exponential window growth, etc. This method
allows applications to maximally utilize available bandwidth and is identified as
mode CCID 2, specified in the RFC 4341 [5].
The second method, typical for TCP-friendly multimedia systems, describes
TCP’s behavior under congestion using the so-called TCP throughput equation,
and sends packets of TCP-friendly protocol according to the rate computed from
this equation. The best known TCP-friendly congestion control module, based

2
The UDP is not error controlled at all. The DCCP assures only reliable negotiation
of options and reliable congestion notification, as well as transmits full signalling
information about packet losses.
 Light-Weight Congestion Control for the DCCP Protocol for Real-Time 55

on the throughput equation, is the TFRC [7]. According to the equation used
by the TFRC, the throughput of the TCP connection is a function of a packet
error rate (PER) [1,7]:
M SS
T (P ER) = · C·
RT T
  −1
2 3  
· · P ER + 12 · P ER · · P ER · 1 + 32 · P ER 2
(1)
3 8

where T is a TCP throughput, MSS is TCP’s maximum segment size, RTT is

round-trip time, and C is a scale coefficient.
The DCCP implements Eq. (1) as mode CCID 3, described in detail in the
RFC 4342 [6].
The last mode, CCID 4, is a modification of the TFRC mechanism for trans-
mission of small packets (e.g. voice stream). A profile for Congestion Control
Identifier 4 is specified in the RFC 5622 [8]. Modes CCID 3 and CCID 4 are
recommended for the transmission of streaming media.

3 Light-Weight Congestion Control for the DCCP

Protocol: Design and Implementation
Although the TFRC is recommended as the congestion control building block
for protocols that convey real-time multimedia, the TFRC congestion control
mechanism manifests strong equality towards competing TCP flows. This feature
is an effect of the TCP-friendliness of the TFRC - therefore, it is desirable.
However, in some situations, it can lead to the degradation of multimedia streams
transmitted over the TFRC.
This soft nature of the TFRC was moved to the DCCP working in mode
CCID 3. Moreover, the DCCP that was used as a lower sublayer of the transport
layer in the RTP/DCCP stack, limits the aggressiveness of the RTP. As a result,
the TCP becomes too aggressive to allow the RTP/DCCP to preserve QoS for
multimedia traffic. In this paper we propose a new mode of the DCCP congestion
control, based on the modified TFRC building block described in [1], which
joins elements of RTP behavior with equation-based congestion control and rate
control mechanism of the TFRC.
RTP streams are unresponsive. Their response to congestion is not very elas-
tic, as in the case of congestion controlled protocols. The RTP flow itself is not
able to react to congestion, so the only reaction is packet losses in intermediate
routers. Packet losses reduce the bit rate of the flow linearly [1]. As a result, in
a network that is well-dimensioned for multimedia traffic, the RTP throughput
equation depends only on the bit rate of the carried multimedia stream and the
packet error rate [1]:

T (P ER) = BR(1 − P ER) (2)

where BR is a bit rate of multimedia stream.

56 R. R. Chodorek and A. Chodorek

The light-weight congestion control mechanism for the DCCP protocol has
been implemented in an environment of the Linux operating system. The Linux
kernel since version 2.6.x contains the implementation of the DCCP protocol
(stored in branch /net/dccp/) along with congestion control mechanisms imple-
mented for mode CCID 2 and CCID 3 (stored in branch /net/dccp/cids/). The
protocol’s implementation is build as a kernel module (dccp). Depending on the
initial configuration of the Linux kernel, the implementation can be loaded one
of two ways: immediately (loaded by the system during the start of the Linux) or
on demand (loaded by the user). The congestion control CCID 2 and 3 modes are
implemented as a separate modules (dccp ccid2 and dccp ccid3, respectively).
The original DCCP protocol implementation on Linux was written by
Arnaldo C. Melo. It uses standard socket application programming interface
(API). Therefore, the code of user programs, written for server and client, is
similar to the code of a regular TCP application. Some parts of the DCCP
implementation share code with the Linux’s TCP implementation and any other
Linux’s implementation of INET3 transport protocols, such as the Stream Con-
trol Transmission Protocol (SCTP). In the case of the DCCP implementation,
the server initializes a socket, binds it to a port, and waits to accept clients to
connect. The client needs only to initialize a socket and connect to the server.
This model of connection setup is similar to the TCP’s connection setup.
After connection setup, a client and a server are able to exchange data. If
DCCP’s congestion control mechanism recognizes that the sending rate is too
large, the current data packet will be refused before it can be sent to a network.
Thus, the user’s programs that use the DCCP must check the status of each
sending routine.
Our implementation for the new DCCP’s congestion control module has been
created for the Linux 4.4.0 kernel. We built a new Linux kernel module, analogous
to existing modules for CCID 2 and 3 dccp ccid lin. Our implementation included
a base congestion control module (ccid.c), which registers and calls the currently
used congestion control module. Parameters of both the DCCP and congestion
control modules are set by variables exported from the dccp ccid lin module and
the basic dccp module. This method enables (re)configuration of kernel module
parameters at runtime.
The basic data needed for proper working of the dccp lin module are stored
in the ccidlin hc tx sock structure. The structure contains, for example, current
sending rate (tx x), receive rate (tx x recv), current loss event rate (tx p), mean
packet size, expressed in bytes (tx s), estimate of current round trip time (tx rtt),
target bit rate of transmitted multimedia stream (tx tbr).
At the very beginning the current sending rate tx x must be set to the tx tbr
value. The tx tbr can be set as one of the kernel module parameters or by
the additional socket option. During transmission, when the DCCP packet is
processed, the function ccidlin hc tx update x is called. This function updates
the current sending rate tx x. If the transmission is inactive for idle period (more
than 2*RTT or more than an Application-Limited Periods [6]) then the current
3
A group of internet protocols in the Linux system.
 Light-Weight Congestion Control for the DCCP Protocol for Real-Time 57

sending rate tx x is set to the initial sending rate. If errors occur, the current
sending rate tx x is modified according to the formula (2).

4 Test Environment
Experiments were carried out using a mixed environment, depicted in Fig. 1,
where real fragments of a test network are combined with the emulated one.
The emulated fragment of the test network is marked in gray in Fig. 1. As the
network emulator, the Berkeleys ns-2 simulator [4] working in emulation mode
was used. The choice of the emulator is guided by its light-weight packet pro-
cessing methodology (only chosen header information is processed in emulated
nodes), which is characteristic of simulators. Fast, light-weight packet processing
allows the ns-2 for emulation of both more network nodes and more high-speed
connections than typical emulators, such as the ns-3, using the same emulation
server. For the emulation server, a dual processor machine, equipped with two
Intel Xeon processors and six Gigabit Ethernet interfaces, was used. The origi-
nal ns-2 software has been supplemented by extension [3,14], which allows the
ns-2 to better emulate real-time multimedia traffic, as well as by extension [15],
designed to use an external switch (switches S1 and S2 in Fig. 1.) as a traf-
fic expander. Standard DCCP protocol, implemented in the Linux kernel, was
extended with improvements described in the Sect. 3, which enable usage of the
linear throughput equation.

Fig. 1. Topology of test network

58 R. R. Chodorek and A. Chodorek

Experiments were performed using a single-bottleneck topology. Real frag-

ments of the test network are connected to the emulation server using Gigabit
Ethernet technology. Almost every link of emulated fragment of the test network
had throughput of 1 Gbps and propagation delay of 1 µs. The only exception is
the bottleneck link, which connects routers R2 and R3. Parameters of this link
are is assumed to be 100 Mbps of throughput and 3 ms of propagation delay.
This topology makes the router R2 the congested node in most of experiments
carried out.
Variable Bit Rate (VBR) video stream was transmitted between SM and RM
end-systems and the target bit rate of the stream was equal to 40 Mbps (the
maximum for the Blu-ray), i.e. the network is well-dimensioned for multimedia.
In all experiments, a collection of eight High Definition Television (HDTV) video
sequences, encoded to the H.264 standard and publicly available at [19], were
used. Each clip belonging to the sequence lasts for 19 s and includes 1920 x
1080 native video, captured at 30 frames per second [12]. These video sequences
are owned by NTIA/ITS, an agency of the U.S. Federal Government, and were
created under Project Number 3141012-300, Video Quality Research, in 2008.
The media server (SM) was build using the VLC [20] software tool, working
under the control of the Linux operating system. Some bug fixes and improve-
ments of standard vlc to enable proper co-operation with the DCCP were made.
Real-time video transmissions, which generates foreground traffic, were carried
out using following variants of the DCCP protocol:

– the DCCP with TFRC congestion control (CC) mechanism, in other words
the DCCP working in the standard CCID 3 mode (curves labeled DCCP
TFRC CC in Figs. 2 and 3),
– the DCCP with light-weight congestion control mechanism, which use linear
throughput equation (curves labeled DCCP light-weight CC in Figs. 2 and 3),
– the DCCP with TCPs congestion control mechanism, i.e. the DCCP working
in CCID 2 mode (curves labeled DCCP TCP’s CC in Figs. 2 and 3).

For the sake of comparison, transmissions with the use of typical RTP/UDP
protocol stack also were carried out (curves labeled RTP in Figs. 2 and 3).
As a background traffic, a number of TCP transmissions are carried out with
the use of the iPerf tool [11], also working under the control of the Linux system.
Senders of background traffic (from ST CP1 to ST CPK in Fig. 1) are connected
to the router R1 using the traffic expander S1, and receivers of TCP traffic
(RT CP1 to RT CPK ) are connected to router R3 through the traffic expander S2.
Transmissions are performed between the pair of nodes ST CPi and RT CPi , i =
0, ..., K. If the total number of TCP flows K is close to 0, the network will not
be congested. The growth of number of flows causes growth of congestion.

5 Results
During all of the experiments throughputs achieved for video and bulk data
transmissions were measured and the number of packet drops were recorded.
 Light-Weight Congestion Control for the DCCP Protocol for Real-Time 59

The number of background TCP flows were changed from 0 to 10. The number
of foreground video streams was equal to one, but (to avoid the influence of
individual video clips on overall results) the transmitted stream was made of
clips randomly chosen from sequences [19], and the transmission of the currently
chosen clip started from a randomly chosen video frame. Each experiment was
repeated over 10 times and the results were averaged.

Fig. 2. Mean throughput of video stream

Figures 2 and 3 presents throughput of both the foreground video stream and
the background TCP flows as a function of the number of TCP flows K. K equal
to zero denotes that the bottleneck link was dedicated to the video transmission
(the video stream did not have to share this link with any background TCP
flow). Because real-time video transmission is rate-limited (transport protocol
cannot send more data than the amount of data generated in real-time), the
throughput of the video transmission achieved for K = 0, i.e. 63.5 Mbps, is the
maximum.
As is depicted in Fig. 2, the presence of background trafficreduces the
throughput of the video stream transmitted by the RTP protocol working over
the UDP. In conditions as described in the previous Section, one competing
TCP flows reduces mean video throughput by 0.5 Mbps (less than 1%), two
TCP flows by 1.5 Mbps (about 2.5%), three by 3.5 Mbps (more than 5%), and
ten competing TCP flows reduces mean video throughput by 14.5 Mbps (23%).
The mean throughput of the video stream transmitted with the use of the
DCCP protocol heavily depends on the applied method of congestion control.
The DCCP that works in CCID 2 mode (exact implementation of the TCP’s
CC) is typical for the TCP fair bandwidth allocation. The throughput of the
60 R. R. Chodorek and A. Chodorek

bottleneck link is divided amongst all foreground and background flows and
streams that share this link. As a result, the DCCP is not able to preserve the
real-time character of the video stream even in the case of a lightly congested
bottleneck link. Even one competing TCP flow was already enough to reduce
the mean throughput of the video stream by more than 10 Mbps (to 51 Mbps,
which gives 80% of the mean throughput of the video stream in the dedicated
link, K = 0). Two background flows competing for bandwidth with one video
stream reduces the video throughput by another 15 Mbps, and the video stream
achieves throughput of 35.5 Mbps (56% of 63.5 Mbps obtained for K = 0). In
the case of K = 10, the throughput of the video stream collapses to 12.5 Mbps
(20% of value measured for K = 0). It is worth mentioning here that CCID 2 is
not recommended for multimedia, and the results are only comparative.
The DCCP congestion control mode CCID 3, which implements TFRC con-
gestion control, is intended for multimedia transmission. The replacement of
the exact implementation of TCP’s congestion control by the approximation of
its behaviour, given by the formula (1), which causes “reasonable fairness” of
the TFRC competing for bandwidth with TCP flows, improves behaviour of the
DCCP protocol during transmission of video streams. One TCP flow that shares
the bottleneck link with the DCCP working in mode 3 is able to reduce the mean
throughput of the video by only 3.5 Mbps (instead of 12.5 Mbps observed during
the transmission with the use of CCID 2). However, it is still much worse than
in the case of the RTP transmission, where a reduction of 3.5 Mbps was only
seen when K = 3. Initially the rate of the descent of the throughput curve is
smaller than in the case of the CCID 2, but when congestion grows the rate of
descent also grows and curves plotted for CCID 2 and CCID 3 are close to each
other. Generally, the condition of reasonability is satisfied. Throughput of the
video stream observed for CCID 3 is within the range of 1 ∗ T2 (K) to 2 ∗ T2 (K),
with a median of 1.58 ∗ T2 (K = 8) and two mode values (1.48 ∗ T2 (K), K = 2
and K = 9; and 1.64 ∗ T2 (K), K = 3 and K = 10, where T2 (K) is a throughput
of the video stream observed for CCID 2 when the number of competing TCP
flows is K. The biggest difference between throughput of CCID 3 and CCID 2
were observed for K = 4 (the ratio between throughputs of CCID 3 and CCID
2 achieves 1.8), K = 5 (a ratio of 1.73) and K = 6 (a ratio of 1.65).
Video transmissions are rate-limited, and (to achieve real-time conditions of
transmission) videos transfer rates must not exceed their rate limits. Fairness,
as well as reasonable fairness toward competing flows, means that the work in
the real-time regime is only possible to a limited extent. As a result, the DCCP
working in congestion control mode CCID 3 is able to replace the UDP in the
RTP/UDP protocol stack only if a network is lightly congested. Replacement
of the TCP throughput Eq. (1) by the linear RTP’s Eq. (2) allows congestion
control mechanisms to have a more aggressive behaviour and for the resignation
of equality, especially problematic for multimedia.
An effect of the use of the light-weight congestion control based on the linear
throughput Eq. (2) is a flat, quasi-linear curve of video throughput shown in
Fig. 2 (the curve labeled DCCP light-weight CC). In the case of non-congested
 Light-Weight Congestion Control for the DCCP Protocol for Real-Time 61

(K = 0) and lightly congested (K = 1) networks, throughput of RTP over

DCCP video transmission is exactly the same as throughput obtained when the
RTP over UDP protocol stack was used. From K = 2, the rate of descent of
the RTP/DCCP throughput curve (from 0.1 to 0.4 Mbps per additional TCP
flow; median: 0.3, mode: 0.2) is significantly smaller than the rate of descent of
the RTP/UDP throughput (typically 1–2 Mbps per additional TCP flow). Only
in the last case, K = 10, the heavily congested network caused a reduction of
video throughput comparable with that observed for the RTP/UDP (0.8 Mbps
vs. 1 Mbps). However, in the case of K = 10, the value of the throughput of
the video stream transmitted by the DCCP that used the light-weight CC is
60 Mbps, which means that 10 TCP flows have reduced the video throughput
only by 3.5 Mbps (5.5%). The same reduction of throughput (by 3.5 Mbps) was
observed for the RTP over DCCP video transmission when K = 3 and for the
DCCP working in congestion control mode CCID 3 when K = 1.

Fig. 3. Overall throughput of K TCP’s flows

The mean throughput of the transmitted video (Fig. 2) determines the band-
width available for background traffic. Thus, it has a major impact on the over-
all throughput of TCP flows (Fig. 3). As was to be expected, the largest overall
throughput of TCP flows were observed when the classic TCP’s congestion con-
trol mechanism was implemented, with its key feature of fair bandwidth allo-
cation. The overall throughput of the TCP ranges from 40 Mbps (K = 1) to
78.5 Mbps (K = 10). The TCP-friendly DCCP congestion control mode CCID
3 (TFRC) also achieves good results, although (because of its worse, from the
TCP point of view, “reasonable” fairness) not as good as pure TCP congestion
control (CCID 2). If congestion increases, the gap between them closes slowly
62 R. R. Chodorek and A. Chodorek

from 15 Mbps (K = 2), through 12.5 Mbps (K = 3) to 11.5 Mbps (K = 4 and

K = 5). If K is larger than or equal to 6, the curves of throughput plotted for
the two DCCP’s TCP-friendly congestion controls are close to each other. The
gap between TCP’s CC curve and the TFRC CC curve is reduced to 3 Mbps
(K = 6 and K = 7), 1.2 Mbps (K = 9), and, finally, to 0.1 Mbps (K = 10).
Initially mean throughput of a video stream transmitted with the use of
the RTP/UDP protocol stack and the RTP/DCCP protocol stack, where the
DCCP uses the light-weight CC, is comparable (Fig. 2). As a result, the gap
between throughputs of TCP background traffic, observed for two RTP-based
transmissions (Fig. 3), is very small (less than 1 Mbps: 0.5 for K = 1 and 0.8 for
K = 2). If congestion increases, this gap opens slowly from 2.7 Mbps (K = 2),
through 3.8 and 5.6 Mbps (K = 5 and K = 6), and finally exceeds 10 Mbps
(10.8 Mbps for K = 10 and 11.1 Mbps for K = 10).

6 Conclusions

The DCCP protocol works in different congestion control modes, two of which
(CCID 3 and CCID 4) are intended for multimedia. Although DCCP’s CCID 3
is recommended for transmission of large streaming media, such as videos, this
congestion control mode is modelled on the behaviour of the TCP protocol. Thus,
properties of the DCCP working in mode 3 are close to the TCP rather than
to the properties of typical real-time transport protocols, such as the UDP or
RTP/UDP protocol suite. The use of the linear throughput equation, proposed
by the Authors in their previous work, models the DCCP’s congestion control
on the behaviour of the RTP working on top of the UDP.
As was shown in the paper, the linear equation deals with two problematic
issues, which are the protocol’s equality towards competing flows and the result-
ing bandwidth constraints imposed by congestion control mechanism. Real-time
transmission is rate-sensitive and equality enforced at the level of the transport
protocol (instead of, for example, the sending application or codec) and signifi-
cantly and needlessly reduces the bit rate of the transmitted stream. Experiments
shows that our solution of light-weight congestion control for the DCCP, imple-
mented in the Linux kernel, allows the DCCP to send video data in a real-time
regime and kept the sending stream congestion controlled. Throughput of the
video steam was reduced by no more than 5.5% when competing with 10 TCP
flows, and the same reduction of throughput was observed for only 1 stream
transmitted by the DCCP working in standard CCID 3 mode. As a result, the
proposed mechanism is aggressive enough to compete for bandwidth with TCP
flows and not so aggressive as to cause the collapse of the competing TCP traffic.

Acknowledgment. The work was supported by the contract 11.11.230.018.

 Light-Weight Congestion Control for the DCCP Protocol for Real-Time 63

References
1. Chodorek, A., Chodorek, R.R.: Streaming video over TFRC with linear throughput
equation. Adv. Electron. Telecommun. 1(2), 26–29 (2010)
2. Chodorek, R.R., Chodorek, A.: ECN-capable TCP-friendly layered multicast mul-
timedia delivery. In: Proceedings of UKSim 2009: 11th International Conference
on Computer Modelling and Simulation, 25–27 March 2009, Cambridge, England,
pp. 553–558 (2009)
3. Chodorek, R.R., Chodorek, A.: Expanding the Ns-2 emulation environment with
the use of flexible mapping. In: Gaj, P., Kwiecień, A., Stera, P. (eds.) CN 2016.
CCIS, vol. 608, pp. 22–31. Springer, Cham (2016). https://doi.org/10.1007/978-3-
319-39207-3 2
4. Fall, K., Vradhan, K.: The ns Manual (2014). http://www.isi.edu/nsnam/doc/ns
doc.pdf
5. Floyd, S., Kohler, E.: Profile for datagram congestion control protocol (DCCP)
congestion control ID 2: TCP-like congestion control. RFC 4341 (2006)
6. Floyd, S., Kohler, E., Padhye, J.: Profile for Datagram Congestion Control Protocol
(DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC). RFC 4342
(2006)
7. Floyd, S., Handley, M., Widmer, J.: TCP Friendly Rate Control (TFRC): Protocol
Specification. IETF RFC 5348 (2008)
8. Floyd, S., Kohler, E.: Profile for datagram congestion control protocol (DCCP)
congestion ID 4: TCP-friendly rate control for small packets (TFRC-SP). RFC
5622 (2009)
9. Fujikawa, T., Takishima, Y., Ujikawa, H., Ogura, K., Katto, J., Izumikawa, H.:
A hybrid TCP-friendly rate control for multimedia streaming. In: Proceedings of
18th International Packet Video Workshop (PV), pp. 134–141 (2010)
10. Holmer, S., et al.: A Google Congestion Control Algorithm for Real-Time Com-
munication. Internet-Draft draft-alvestrand-rmcat-congestion-03 (2015)
11. iPerf - The TCP, UDP and SCTP network bandwidth measurement tool. https://
iperf.fr/. Accessed Mar 2018
12. Parameter values for the HDTV standards for production and international pro-
gramme exchange. Recommendation ITU-R BT.709-6 06/2015 (2015)
13. Kohler, E., Handley, M., Floyd, S.: Datagram Congestion Control Protocol
(DCCP). RFC 4340 (2006)
14. Mahrenholz, D., Svilen, I.: Real-time network emulation with ns-2. In: Proceedings
of the 8th IEEE International Symposium on Distributed Simulation and Real
Time Applications, Budapest, Hungary, pp. 29–36 (2004)
15. Mahrenholz, D., Ivanov, S.: Adjusting the ns-2 emulation mode to a live network.
In: Müller, P., Gotzhein, R., Schmitt, J.B. (eds.) Kommunikation in Verteilten
Systemen (KiVS). Informatik aktuell, pp. 205–217. Springer, Heidelberg (2005).
https://doi.org/10.1007/3-540-27301-8 17
16. Shiang, H.P., van der Schaar, M.: Quality-centric TCP-friendly congestion control
for multimedia transmission. IEEE Trans. Multimedia 14(3), 896–909 (2012)
17. Singhal, N., Sharma, R.M.: Survey on TCP friendly congestion control for unicast
and multicast traffic. Int. J. Comput. Appl. 26(1), 23–30 (2011)
18. Stevens, W., Allman, M., Paxson, S.: TCP congestion control. RFC 2581 (1999)
19. VQEG: VQEG HDTV TIA Source Test Sequences. ftp://vqeg.its.bldrdoc.gov/
HDTV/NTIA source/. Accessed Mar 2018
20. VideoLAN - Official page for VLC media player, the Open Source video framework!
http://www.videolan.org/vlc/. Accessed Mar 2018
 On Improving Communication System
Performance in Some Virtual
Private Networks

Tomasz Malinowski(B) and Jan Chudzikiewicz(B)

Faculty of Cybernetics, Military University of Technology,

ul. Gen. Witolda Urbanowicza 2, 00-908 Warszawa, Poland
{tomasz.malinowski,jan.chudzikiewicz}@wat.edu.pl
http://www.wat.edu.pl/

Abstract. The paper presents the procedure for determining the opti-
mal set of hubs and spokes and thus the collection of tunnels in hub-
and-spoke network. The subject of the study was a multi-departmental
network, with security of transmission requirement, so DMVPN tech-
nology with IPSec-protected tunnels were used. The optimization of the
hub/spoke set was intended to improve inter-departmental communica-
tion efficiency, which was to be confirmed by the analysis of simulation
results. In the simulation studies, the quality of the chosen service (VoIP)
was checked for the different structures of tunnel connections. Simulation
tests were prepared and implemented in Riverbed Modeler environment.

Keywords: Optimal communication structure · Routing protocols

Dynamic tunneling in VPN

1 Introduction

This article is a continuation of the considerations on improving the reliability

and performance of transmission in the networks based on hub-and-spoke log-
ical architecture. The procedure for monitoring and maintaining a network of
dynamic VPN tunnels was introduced in [1]. The idea of reconfiguration was
intended to use a diagnostic theory to test the interoperability of branch bound-
ary routers, which act as a tunnel brokers for other routers, to communicate
branches networks using dynamic IPSec tunnels. The basis for this discussion
was Cisco DMVPN technology.
The authors of this article focus on the method of centralized monitoring
of communication parameters in DMVPN network with scattered departments
and on calculation of the optimal set of hubs and spokes. Network structures in
which inter-departmental communication takes place through hub routers and is
secured by IPSec are considered. The task is to determine optimal set of border
routers (single router can act as hub or spoke) and thus a minimal set of VPN
tunnels.
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 64–73, 2018.
https://doi.org/10.1007/978-3-319-92459-5_6
 On Improving Communication System 65

This task belongs to the wide domain of determining the optimal alloca-
tion of resources and determining the optimal communication structure and is
raised in many research works focused on improving reliability, performance,
and usability of transmission systems (multiprocessor systems, military com-
puter networks - wired and wireless networks of stationary or mobile nodes). A
lot of research focuses on the problems of optimization of the hypercube struc-
ture and on the problems with location and relocation of network resources
([2–8]). In the era of IoT (Internet of Things), results of research on optimal and
“energy-efficient” communication structures, prolonging the life time of the net-
work with battery-powered nodes, are particularly important [9]. The research is
focused on developing new routing protocols, efficient medium access protocols,
selecting of nodes collecting and processing information from other nodes (sink
nodes) and on indicating nodes of the meeting points (rendezvous points) or
nodes acting as coordinators ([9–12]).
In our area of interest, i.e. dynamic tunneling in VPNs, research is focused
on testing of the network performance in cases of utilization of various routing
protocols [13].
In this paper we introduce a procedure for determining the optimal set of hubs
and spokes in specific communication structure. We assume arbitrarily that the
dynamic routing protocol, used for broadcasting of prefixes of branch network
addresses, is OSPF (Open Shortest Path First). The result of the procedure
is the graph of logical VPN connections between departmental border routers.
Based on the graph we will be able to distinguish spoke and hub/spoke routers.
We assumed that such structure of VPN tunnels will enable efficient and secure
exchange of information between branches. We were looking for confirmation of
assumptions in the results of the simulation studies.
This paper firstly presents short description and basic DMVPN problems.
In Sect. 3, the structure of the analyzed network, the assumptions and formal
description of the problem are given. Section 3 also deals with the procedure
for determining the best tunneling structure between the border routers of our
network. The last section shows the model of simulated network and results of
simulation tests.

2 DMVPN Characteristics and Main Transmission Issues

DMVPN (Dynamic multipoint VPN) is a great technology to create scal-
able VPN. It is based on Multipoint Generic Routing Encapsulation protocol
(mGRE), IPSec and Next Hop Resolution Protocol (NHRP). It makes possible
build a communication structure connecting branches of the company through
secure tunnels over WAN. Some of the tunnels are permanent, some of them
are dynamically built-up, as needed, so using DMVPN makes it unnecessary
to create and to manage large numbers of tunnel connections in big multi-site
networks.
DMVPN consists border routers that function as hubs or spokes. In basic
DMVPN form, inter-branch communication via hub nodes is offered (DMVPN
66 T. Malinowski and J. Chudzikiewicz

Phase-1) and is called spoke-hub-spoke communication. Another variant is the

communication between boundary branch routers through dynamic tunnels,
which are established after reconciling of tunnel parameters with the tunnel
broker. Spoke is the reconciliation node, and hub is tunnel broker (DMVPN
Phase-2, where branches are directly connected). In both cases it is possible to
protect the tunnels by IPSec. Implementation of direct communication between
branches with secured tunnels is DMVPN Phase-3 (spoke-to-spoke connections
with IPSec).
The general shape of DMVPN was shown in Fig. 1.

Fig. 1. DMVP with one HUB (a) and backup NHS server (b)

For reliability DMVPN can contain primary and backup hub (structure b on
Fig. 1). Regardless of DMVPN structure, each spoke has to register itself in the
primary hub or additionally in backup hub, which are called Next Hop Servers
(NHS).
DMVPN technology has many advantages, but in various studies the short-
comings and problems that occur in networks with this solution are signaled. For
example, for spoke-to-spoke communication (DMVPN Phase-3) a hub failure can
directly impact spoke-to-spoke connectivity in those DMVPN networks where
spokes can’t establish direct IPSec sessions (due to NAT or other limitations).
Another example might be the problem discussed in the article [1]. The
authors point out the fact, that the primary condition of successful tunneling is
proper functioning of the spoke in hub registration mechanism, the polling mech-
anism about physical addresses of the final points of tunnels, but also mechanism
of call’s disconnecting in case of hub failure (connection with hub can be tem-
porary loss, hub can be overloaded, hub’s response time can be too long, etc.).
In some cases of tunnel connections protected by IPSec, it is necessary to track
hub’s availability and to remove IPSec session after a period of temporary hub’s
unavailability (cleaning of IPSec Security Associations) [1].
Despite the fact that DMVPN technology is developed and improved over the
years, it is still possible to indicate the situations in which network management
procedures in situations of malfunction are useful.
 On Improving Communication System 67

3 Determining of Optimal VPN Communication

Structure

Our considerations will be focused on the VPN and the network structure graph
G1 , shown in the Fig. 2.

Fig. 2. Structure of potential VPN connections in a specific network

We assume that the analyzed structure of tunnel connections results from

some technical limitations of border routers, which means that not every router
can act as a hub. All routers, however, can be a spoke. Thus, the initial struc-
ture is not the structure of full-mesh tunnel connections but partial-mesh. Such
a structure will be a subject of optimization, because we want to minimize the
number of the tunnel connections.
The procedure for determining the optimal structure will be implemented
centrally by the network management station. The assignation of such structure
will involve uploading of the appropriate configuration to the border routers of
DMVPN branches.
The network structure is described by graph G = <E, U >, for E – set of
network nodes, and U – set of communication links (corresponding to DMVPN
tunnels).
In the example network, nodes e0 to e8 are departmental border routers. Red
lines (in Fig. 2) between nodes are potential IPSec tunnels. Graph G1 shows VPN
connections in a simpler form.
VPN topology in Fig. 2 are redundant connections structure, but not full-
meshed. Graph G1 is a subgraph of four-dimensional hypercube It is a redundant
structure with high degree of redundancy, fulfilling the stringent requirements
imposed on some networks. The issue of determining such subgraphs was dis-
cussed in [7].
Our first goal was to implement a procedure of acquiring by management
station information about the quality of the transmission channels between nodes
e0 − e8 . Because Cisco routers are the border routers of our network, we use IP
SLA probes. IP SLA is a great tool and is an embedded agent in Cisco IOS,
designed to measure and monitor common network performance metrics like
68 T. Malinowski and J. Chudzikiewicz

jitter, delay, and packet loss. IP SLA has two components: the source and the
target. The source generates packets, and the target functions as responder.
Simple IP SLA probe may look as follows:
ip sla 1
udp-jitter 10.0.0.1 codec g729a
frequency 40
ip sla schedule 5 life forever start-time now
On the recipient’s side, we just turn on the responder using the command:
ip sla responder
Statistics given by the probe is listed below (some lines are omitted).
WA#show ip sla statistics
Latest RTT: 192 milliseconds
Source to Destination Latency Min/Avg/Max: 2/75/244 milliseconds
Destination to Source Latency Min/Avg/Max: 2/214/423 milliseconds
Source to Destination Jitter Min/Avg/Max: 0/13/209 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/23/314 milliseconds
Packet Loss Values:
Loss Source to Destination: 0
Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 19
Packet Late Arrival: 0 Packet Skipped: 1
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 14
MOS score: 4.00
We assume that the probes will be running on border routers, that can set up
tunnels as in Fig. 2. The probes will assess the “quality of the tunnel connection”.
This parameter will be the key to determining the best communication structure
of our network.
Because it is communication structure with permanent tunnels (DMVPN
Phase-1), our intent is to choose “optimal minimum set” of hubs and spokes (in
our case, providing the best VoIP service performance).
In general, let d (e, e |G ) be the distance between nodes e and e in a coherent
graph G. This is the length of the shortest chain (in the graph G) connecting
node e with the node e .
max
Nodes of the structure G are characterized by a radius. Let r (e |G ) =e ∈E(G)
d ((e, e ) |G ) be the radius of a node. In the Table 1 radius for all nodes of G1
were presented.
A basis for determining the communication structure is a dendrite, which
provides the minimum number of communication lines.
Let T = <E, U ∗ > be the dendrite i.e. such coherent acyclic partial graph of
G that:

∃ e , e  ∈ U ⇒ e , e  ∈ U ∗ ⇔ [(d (e∗ , e ) = d (e∗ , e )) ∧ d (e , e ) = 1]
 On Improving Communication System 69

Table 1. The radius values for G1

e ∈ E (G1 ) r (e |G1 )
e0 3
e1 2
e2 4
e3 3
e4 3
e5 4
e6 3
e7 4
e8 4

for
r (e∗ ) =e∈E(G) r (e)
max

The algorithm for dendrite T determining was presented in [7]. The procedure
described there gives, in the first step, a set of dendrites, illustrated in the Fig. 5.
For simplicity of calculation, it was assumed that distance between e and e ,
which are connected via VPN tunnel, is 1, but you can use all or some of the
characteristics returned by the IP SLA probes and assign a metric according to
your preferences. In a real network environment, we assume continuous (periodic)
checking of various SLA parameters, and using them as a metric of inter-nodes
tunnels.
The optimal structure is a dendrite determined for a node with minimal
radius. For the structure G1 the node e1 (Table 1) has a minimal radius. The
structure TOP T , shown in Fig. 3, was chosen as the optimal communication struc-
ture for the G1 . Thus, the nodes e2 , e5 , e6 , e7 , e8 are spokes, and the nodes
e0 , e1 , e3 , e4 are hubs.
After determining the optimal communication structure, the management
station can perform appropriate reconfiguration of the boundary routers.

Fig. 3. The optimal communication structure TOP T for the G1

70 T. Malinowski and J. Chudzikiewicz

4 The Results of Simulation Studies

The procedure for determining the set of hubs, spokes and tunnels was verified by
simulation tests. The study was conducted in the Riverbed Modeler simulation
environment. The simulation model of our network is shown in the Fig. 4.

Fig. 4. Simulation model of DMVPN

There were nine branches attached to the WAN by border routers R0 – R8.
The single branch was modeled as a LAN with 10 workstations and one http
server. Branch workstations can communicate through WAN over VoIP and http
(treated as background traffic). The observed service, as especially important for
us, was VoIP.
The conducted simulation tests certainly do not serve to verify the design
of any network. The tests were to authenticate the procedure for determining
the optimal VPN communication structure. Therefore, we only took care of
the homogeneity of links and network devices. What was important for us is
that in the randomness of generating network streams and the randomness of
client-server connections, the simulation results confirm the correctness of the
theoretical arguments.
We were interested in the value of important VoIP service parameters like
end-to-end delay and delay variation Network services have used the standard
application models, available at Riverbed Modeler (“Heavy Browsing” http
model and “PCM Quality Speech” voice model). Routers were connected to
WAN over T1 links.
Simulation scenarios corresponded to the structures from Fig. 5. It was
expected that the results of the simulations will confirm the choice of optimal
hubs, spokes and tunnels collections (Fig. 2). Some interesting results Voice
 On Improving Communication System 71

Fig. 5. Set of G1 ’s dendrites

End-to-End Delay and Voice Delay Variation, confirming the correctness of the
procedure for determining the optimal VPN structure are shown in the figures
below. End-to-End Delay is “average delay in seconds for all network nodes
communicating each other under VoIP” and Voice Delay Variation is “average
variance in seconds (for all voice workstations) among end to end delays for voice
packets. It is measured from the time packet is created to the time it is received”
[14]. Low values of these parameters are desirable.

Fig. 6. Average values of Voice End-to-End Delay and Delay Variation

72 T. Malinowski and J. Chudzikiewicz

Complete set of results, in the form of a bar chart, for all G1 ’s dendrites are
presented in Fig. 6. The highlighted bar refers to the best structure t (e1 ) (TOP T
from Fig. 3).

5 Conclusions and Future Work

Correctness of developed method and its usefulness was confirmed by simulation
results. We are satisfied with the simulation results, as considered structures were
rather simple and very similar to each other and we did not expect such unequiv-
ocal results, which would confirm the correctness of the analytical procedure for
determining the optimal VPN structure.
Our next step is the practical implementation of the VPN connection man-
agement system. Despite the confirmation of usefulness of our procedure in a sim-
ulation environment, it will be interesting to implement and test the effects of
continuous monitoring of VPN transmission channels and changing the configu-
ration of routers in a real network environment.

References
1. Malinowski, T., Arciuch, A.: The procedure for monitoring and maintaining a
network of distributed resources. In: Annals of Computer Science and Information
Systems, Proceedings of the 2014 Federated Conference on Computer Science and
Information Systems, vol. 2, 7–10 September 2014, Warsaw, Poland (2014)
2. AlBdaiwia, B.F., Bose, B.: On resource placements in 3D tori. J. Parallel Distrib.
Comput. 63, 838–845 (2003)
3. AlBdaiwia, B.F., Bose, B.: Quasi-perfect resource placements for two-dimensional
toroidal networks. J. Parallel Distrib. Comput. 65, 815–831 (2005)
4. Bae, M.M., Bose, B.: Resource placement in torus-based networks. IEEE Trans.
Comput. 46(10), 1083–1092 (1997)
5. Imani, N., Sarbazi-Azad, H., Zomaya, A.Y.: Resource placement in Cartesian prod-
uct of networks. J. Parallel Distrib. Comput. 70, 481–495 (2010)
6. Moinzadeh, P., Sarbazi-Azad, H., Yazdani, N.: Resource placement in cube-
connected cycles. In: The International Symposium on Parallel Architectures, Algo-
rithms, and Networks, pp. 83–89. IEEE Computer Society (2008)
7. Chudzikiewicz, J., Zieliński, Z.: On some resources placement schemes in the
4-dimensional soft degradable hypercube processors network. In: Zamojski, W.,
Mazurkiewicz, J., Sugier, J., Walkowiak, T., Kacprzyk, J. (eds.) Proceedings of the
Ninth International Conference on Dependability and Complex Systems DepCoS-
RELCOMEX. June 30 – July 4, 2014, Brunów, Poland. AISC, vol. 286, pp. 133–
143. Springer, Cham (2014). https://doi.org/10.1007/978-3-319-07013-1 13
8. Chudzikiewicz, J., Malinowski, T., Zieliński, Z.: The method for optimal server
placement in the hypercube networks. In: Proceedings of the 2015 Federated Con-
ference on Computer Science and Information Systems. ACSIS, vol. 2, pp. 947–954
(2015). https://doi.org/10.15439/2014F159
9. Brindha, L., Muthaiah, U.: Energy efficient mobile sink path selection using a
cluster based approach in WSNs. Int. J. Innovative Res. Comput. Commun. Eng.
3(3) (2015)
 On Improving Communication System 73

10. Erzin, A.I., Plotnikov, R.V.: Using VNS for the optimal synthesis of the commu-
nication tree in wireless sensor networks. In: Electronic Notes in Discrete Mathe-
matics, vol. 47. Elsevier (2015)
11. Ghotra, A., Soni, N.: Performance evaluation of ant colony optimization based
rendezvous leach using for mobile sink based WSNs. Int. J. Eng. Res. Dev. 11(07)
(2015)
12. Baby, S., Soman, M.: Rendezvous based techniques for energy conservation in
wireless sensor networks - a survey. J. Netw. Commun. Emerg. Technol. (JNCET),
3(3) (2015)
13. Bahnasee, A., Kamoun, N.E.: Study and analysis of a dynamic routing protocols’
scalability over a dynamic multi-point virtual private network. Int. J. Comput.
Appl. (0975-8887), 123(2) (2015)
14. Sethi, A.S., Hnatyshin, V.Y.: The Practical OPNET User Guide for Computer
Network Simulation. Chapman and Hall/CRC (2012)
 New SDN-Oriented Authentication
and Access Control Mechanism

Fahad Nife1,2(B) and Zbigniew Kotulski1

1
Faculty of Electronics and Information Technology,
Warsaw University of Technology, Warsaw, Poland
[email protected], [email protected]
2
Faculty of Science, Al-Muthanna University, Muthanna, Iraq

Abstract. Software-Defined Network (SDN) is recognized as one of the

most important future networking area. SDN architecture is a revolution-
ary new idea that, moving the traditional network to be software-based,
provides more flexibility, high degree of automation and shorter provision
time. SDN architecture dynamically separates the control plane from the
data (forwarding) plane of the network, which provides centralized view
of the entire network and makes it easier for managing and for monitor-
ing the network’s resources. However, the initial design of the SDN, with
its centralized point of control, does not consider sufficiently the security
requirements, which makes the security issues additional challenges. In
this paper we propose a new access control system for the SDN architec-
ture, working as a controller application used to verify the identity of a
host upon connection to the network. The proposed mechanism, which
denies the access attempts from unauthorized hosts and defines different
levels of privileges for each host, according to its authentication creden-
tials, is implemented using a POX controller. Our approach neither needs
a support of new protocols, nor requires additional configuration of hosts
or routers.

Keywords: Software-Defined Networking · IEEE 802.1x

Port-based authentication · Network security · Radius

1 Introduction

Software-Defined Networking (SDN) is a new framework which comes to facili-

tate the network management and to improve the overall network’s performance
and monitoring by physical decoupling the packets forwarding process of the net-
work (considered as the Data Plane, DP) from the routing process (performed in
the Control Plane, CP) [1]. SDN centralizes the network’s intelligence in one com-
ponent called Controller, which has a comprehensive view of the entire network
and which is responsible for taking the forwarding decisions for the DP (switches
and routers) that just performs basic packet forwarding [2]. To provide more eli-
gibility and scalability to the network, the network applications that provide
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 74–88, 2018.
https://doi.org/10.1007/978-3-319-92459-5_7
 New SDN-Oriented Authentication and Access Control Mechanism 75

network’s services are abstracted into a separate plane (Application Plane, AP).
In SDN, the centralized controller (representing the network’s operating system),
the switches (network resources) and the applications (network consumers) can
communicate in real-time [3] through the NorthBound Interface (NBI) and the
SouthBound Interface (SBI). The Application Plane utilizes the NBI, which is
a programmable API, to communicate with the Controller. Typically, there are
no standard Northbound Interfaces defined, and the applications should provide
their own APIs. The Controller uses the Southbound Interface (e.g. OpenFlow)
to communicate with the underlying Data Plane. OpenFlow is a standard pro-
tocol (standardized by the Open Networking Foundation (ONF) [4]), widely
used for the Southbound interface in SDN Networks [5]. It is typically used for
the communication between the Controller and the switches under its control.
OpenFlow can provide encrypted communications between the Controller and
the underlying infrastructure, using Transport Layer Security (TLS), which is
considered as an optional feature, and unprotected communications using clear
Transmission Control Protocol (TCP).

Fig. 1. Software-Defined Network abstraction.

Such centralized intelligence and programmability of SDN give an advantage

of providing the Controller with a global view of the entire network, as well
76 F. Nife and Z. Kotulski

as deploying additional network applications to perform some important ser-

vices (such as: firewalls, intrusion detection engines and QoS), instead of using
proprietary devices [6]. However, in addition to the security threats and vulnera-
bilities known in the traditional network, this centralized intelligence and direct
programmability have their own drawbacks concerning security, scalability, and
elasticity. Moreover, the original design of an SDN network is lacking any built-
in protection instrument or even basic security mechanism (e.g. authentication
and authorization of entities), what has become more and more problematic [7].
Nevertheless, securing the SDN network is very important and is a key feature
of a new network idea success, so we cannot consider a secure network without
an access control mechanism applied to prevent unauthenticated clients to gain
access to the network, or to avoid unauthorized users getting access to sensi-
tive resources of the network [8]. In this paper, we are taking the advantages
of the centralized controller with its global view of the network, the flexibility,
and the programmability of SDN, to propose a new Network Access Control
System and a Policy Enforcement Solution for SDN networks, which will work
as an application based on API provided by the Controller, see Fig. 1. Our pro-
posal is based on IEEE 802.1x, i.e., Extensible Authentication Protocol (EAP)
over LAN encapsulation and a RADIUS authentication protocol. The Authen-
ticator is centralized and maintains a database of currently active users, as an
introduced solution for the stateless property of RADIUS, by keeping records
of currently authenticated users to limit concurrent sessions. Such a central-
ized Authenticator and Controller architecture could easily help in providing
authenticated-client mobility inside the network by relating a user/host with its
data flows. Since the Controller is the most important entity in the SDN network,
which is usually considered as the main goal for attackers, we decided to separate
it from, both, the Policy Information Point (PIP), where the users’ identities are
stored, and the Policy Enforcement Point (PEP), where the policies are enforced
(e.g., switch or router). Thus, there is no possibility for any client to reach the
Controller. Our proposed solution does not need any additional supporting pro-
tocol and does not require new configuration of hosts or routers. The rest of the
paper is structured as follows: Sect. 2 presents known authentication solutions in
traditional networks, Sect. 3 gives an overview of related works concerning SDN
security, Sect. 4 presents the proposed authentication system’s design: the new
access control method and its data flow policy, Sect. 5 shows the outline of the
experiment implementation and the estimated performance of the system, while
the last Sect. 6 presents the conclusions and the future work.

2 Network Authentication for Traditional Networks

In today’s world, network administrators make a huge effort to secure enterprise
networks, which often contain sensitive information and important resources.
Regardless of the policies and measures they use, such networks are still vul-
nerable due to the accidental applications’ bugs, user carelessness, or even from
insider threats. Access to networks should be simple, however uncontrolled and
 New SDN-Oriented Authentication and Access Control Mechanism 77

unauthorized access is generally not attractive. Identifying users and devices

connected to a network is a key part of network’s security; it is called Network
Access Control and sometimes is referred as Port-based access control. There is a
standard technology called IEEE 802.1x [9] which defines a Port-based Network
Access Control mechanism for Ethernet networks. IEEE 802.1x is a framework
that defines a method for encapsulating EAP (Extensible Authentication Proto-
col [10]) messages to be sent over a Local Area Network (LAN). This encapsu-
lation is known as EAP over LAN (EAPOL). The idea of such a solution is that
before one can access the network through a switch port, he or she must first be
authenticated using his or her credentials. So, nobody can directly enter the net-
work. For authentication purposes, IEEE 802.1x relies on EAP protocol, which
allows using different authentication procedures like EAP-MD5, EAP-IKE v2,
EAP-TLS, and many more. The standard specification of 802.1x includes three
major components, which are: the Supplicant (host), the Authenticator, and the
Authentication Server, see Fig. 2.

Fig. 2. IEEE 802.1x framework.

The Supplicant is an agent of the service running on a device that is ready to

access the network. It responds to the requests coming from switches. Authen-
ticator acts as a proxy between the Supplicant and the Authentication Server.
It controls the access to the network based on the authentication status of the
Supplicant. It requests the Supplicant identity information, verifies this informa-
tion with the Authentication Server, and releases the authentication response to
the Supplicant. The Authenticator performs the RADIUS client functionality,
encapsulates and decapsulates the EAP frames and interacts with the Authen-
tication RADIUS server, see [11]. The Authenticator’s physical port can be logi-
cally defined either as a controlled port (which permits full access to the network
78 F. Nife and Z. Kotulski

resources) or as an uncontrolled port (which provides access only for EAPOL

traffic between the Supplicant and the Authentication Server), which give two
virtual access points. Before the Supplicant is authenticated, the uncontrolled
port is the only open port in the Authenticator, but after the Supplicant is
successfully authenticated, the controlled port is opened. The third major com-
ponent of the framework is the Authentication Server, which performs the actual
authentication to the Supplicant. The Authentication Server is, generally, a host
running software supporting the RADIUS and the EAP protocols. Its role is to
validate the identity of the Client and to notify the Authenticator, if the Client
is authorized to access the network or not. All authentication and authorization
policies are stored on the Authentication Server and, depending on the access
level of the user, the specific policies are applied. The Authentication Server and
the Authenticator utilize such protocols as RADIUS (Remote Authentication
Dial in User Service) protocol [11] or Diameter protocol [12] to transport and
exchange EAP frames.

Fig. 3. Messages exchanged during authentication.

The steps of the authentication procedure are the following. The Supplicant
initiates the communication when it detects a change of the link state from down
to up, while the port remains in the unauthorized mode during the authentica-
tion process. The Authenticator sends EAP-Request/Identity frame to the Sup-
plicant, asking for its identity or the credentials. Once the Supplicant receives
the request, it responds with the EAP-Response/Identity frame containing the
credentials. Now, the Authenticator begins its role as a proxy between the Sup-
plicant and the Authentication Server; it passes the EAP frames between them
 New SDN-Oriented Authentication and Access Control Mechanism 79

until the validation is successful or it fails. If the authentication is successful, the

port is authorized and then the user can access the network. In Fig. 3 are shown
the messages exchanged between the components. It is a little bit complicated
process, but it ensures that only the permitted clients can access the network’s
resources.

3 SDN-Dedicated Network Authentication Systems

Meeting the need of protecting the SDN networks, recently different dedicated
security solutions have been presented, for instance, IDS [13], IPS [14], State-
less Firewall [15], Stateful Firewall [16], reactive Firewall [17], and Distributed
Firewall [18]. In this section, we give an overview of several known Network
Access Control Systems for SDN networks and then compare them with our
proposed solution. Thus, the Ethan project [19] relies on defining a global pol-
icy for the centralized controller architecture and a strong binding between the
users’ attributes, their machines and their traffic (IP, MAC, and Ports) to pro-
vide network access control system based on user’s identity. Ethane argues that
all users, hosts, and switches must be registered and authenticated before any
communication. The hosts are authenticated by their registered MAC addresses,
the users are authenticated by presenting their usernames and passwords to a
website end of the Kerberos server, and the switches use certificates to authen-
ticate themselves to the controller through an SSL secure channel. Resonance
[20] extends the Ethane to allow the dynamic network policy based on the real-
time monitoring. In Resonance, each device connected to switch has, both, the
“Security Class” that transcribes, how the traffic flows to the resources, and the
“State”, that determines which Security Class should be applied at that time.
Like in Ethan, the user is redirected to a website to submit his credentials to
be authenticated. The solutions presented in [21,22], AuthFlow [23], FlowNAC
[24], and FlowIdentity [25] attempt to provide authentication and access control
systems for SDN networks using IEEE 802.1x with the RADIUS Authentication
Server, but they differ, basically, with how the host/end user is authenticated,
and with how the RADIUS Client is used as the Authenticator. The authors in
[21,22] have proposed a Network Access Control System for an OpenFlow-based
SDN network, which is compatible with the traditional network infrastructure.
In this solution, newly connected hosts are directed to the authentication web-
site with an integrated RADIUS Client to provide their credentials. The website
is ending to RADIUS Authentication Server. Similarly to Ethane [19], their way
of host authentication is based on tight binding the host to the port on the
switch. However, the captive portal is the common background in these propos-
als; it requires Layer 3 configuration (e.g. DHCP) or even ephemeral private IP
address to access the website. Moreover, these approaches require an HTTPS-
capable Web browser installed in the host to be able to authenticate, which is
a problem for virtual machines or some network devices, like printers, scanners,
phones, or even some servers that do not support the web browser. In contrast,
our proposed solution does not utilize a website; instead, it uses a hostapd [26] as
80 F. Nife and Z. Kotulski

Authenticator and adopts the standard 802.1x that does not need an IP address
assignment before the authentication process. AuthFlow [23] authenticates hosts
directly at Layer 2 (based on MAC addresses), then it provides different privi-
leges for users, based on their credentials. AuthFlow extends the RADIUS Client
authenticator hostapd to communicate with the controller through an SSL-based
secure channel. AuthFlow differs with our proposed system; it only provides
the Access Control system for SDN networks, while our solution provides the
Access Control system and introduces a mechanism for the stateless property
limitation of RADIUS protocol, by enforcing the Authenticator to maintain a
local database of the authenticated active users. FlowNAC [24] proposes a Flow-
Based Network Access Control for SDN networks, in which the flows are associ-
ated to services; the services are uniquely identified, and the decisions are based
on, both, the user’s identity and the requested services. FlowNAC enforces the
extended centralized policy (e.g., target service identifier) to be implemented
in a proactive manner. FlowNAC implement IEEE 802.1x standard, however,
to provide the user with the ability to access multiple services simultaneously,
the EAPoL in EAPoL encapsulation has been introduced, which in turn needs
the extension and updating the protocols, entities’ exchanged information, and
data models. FlowIdentity [25] present an SDN authentication solution using
IEEE 802.1x standard with authorization (policy enforcement) through a role-
based firewall. This proposal does not change the traditional 802.1x port-based
authentication; however, the defined policy can be dynamically updated and
directly enforced. Both, FlowNAC and FlowIdentity, argue to provide a service-
based authentication, which differs only in the way that the policy enforcement
is achieved. FlowNAC and FlowIdentity are differing from our solution; they are
implementing the service-based authentication. FlowIdentity differentiates the
service using the role-based firewall, while FlowNAC employs EAPoL in EAPoL
encapsulation and utilizes the predefined rules as a set of rules per service. In con-
trast, our proposed solution is the identity-based authentication, it does not need
any additional supporting protocols or does not require new encapsulation, which
might lead to additional unrequired overhead. In the paper [27], the authors have
suggested SEaaS (Security as a Service) model, which provides mutual authen-
tication mechanism between an application and the controller in SDN networks.
It provides an additional security service for Southbound SDN API (i.e. REST
API), which is not supported by an existing protocol. SEaaS is focused on pro-
viding the authentication between the controller and the applications that run
above it, while our proposed work is identity-based authentication between the
controller and client/users who try to access the network. The authors of [28]
have implemented an authentication and authorization module, which is a net-
work application maintaining a wide-session database. It has been implemented
with two different modes: pass-throw mode and authentication server mode. The
main difference between this solution and our proposed work is the place where
the Authenticator is located. In [28] the Authenticator has been integrated with
the Controller, which may lead to increase the load on the controller and make
the solution vulnerable to attacks on the controller, like SYN flooding, which
 New SDN-Oriented Authentication and Access Control Mechanism 81

may finally destruct the whole network. We implement the Authenticator as a

separate entity, which helps to isolate the Controller from an unrequired access.
The main aim of our proposed solution is to build an Access Control system
for securing the SDN network by employing the 802.1x standard with RADIUS
server to authenticate, both, the users and hosts, which is based on the Cen-
tralized Authenticator separated from the Controller. Moreover, it introduces a
solution for the stateless property of the RADIUS protocol by modifying the
Centralized Authenticator to maintain a local database used to keep records of
currently authenticated users and to limit the concurrent sessions. Every new
authentication request is compared against this database before forwarding it to
the Authentication Server.

4 System Architecture
4.1 Architecture Overview
The main objective of this work is to design and develop a network access control
and authorization mechanism for an SDN network. The proposed architecture’s
overview is shown in Fig. 4, in which the 802.1x standard is adopted for SDN
networks, as it does not enforce any changes on the host sides. The architecture
is composed of four components, which are: the OpenFlow-enabled switches,
the Controller, the Authenticator, and the Authentication Server. The policy is
enforced in a reactive mode (based on the first packet), what keeps the data plane
flow table small, instead of filling it with unmatched rules. However, only two
entries should be installed in advance in the switch’s flow table, to enforce the
switch forwarding all EAPOL (Ethernet type set to 0x88E) to the Authenticator,
while dropping all other packets. The Centralized Authenticator is the modified
version of the hostapd. It is separated from the controller for security reasons
(to isolate the controller for protecting the network from presumably the most
extreme threats on SDN networks, where such vulnerabilities and attacks on the
Controller will lead to compromise the whole network, see [29,30]). The Authen-
ticator is implemented as a RADIUS Client. It receives the EAPOL frames from
the switches, decapsulates the EAP frame, compares its contents with a local
database of currently active users and, in case of no match, re-encapsulates it
in the RADIUS frame and forwards it to the RADIUS Authentication Server.
The reply from the Authentication Server, whether it succeeds or fails, is for-
warded to the controller via a secure encrypted channel using SSL 3.0 standard
established between the Controller and the Authenticator. The Authentication
Server (RADIUS) basically performs the actual authentication process by vali-
dating the identity of the Client and notifying the Authenticator if the Client is
authorized to access the network or not.

4.2 Authentication Process

The authentication process starts when a new 802.1x-aware Client (Suppli-
cant) connects to the network. The authentication messages exchange between
82 F. Nife and Z. Kotulski

Fig. 4. Proposed architecture.

the Supplicant and the Authenticator starts either when the Supplicant is
sending EAPOL-Start frame to the edge switch, or when the Authenticator
detects state changes in one of its ports and, alternatively, when it receives a
packet on a specific port, with a source MAC address not included in its flow
table, see Fig. 5. The switch is proactively instructed to forward EAPOL-start
frames to the Centralized Authenticator. The Authenticator responds with EAP-
Request/Identity, asking for the Supplicant credentials. The Supplicant answers
with EAP-Response/Identity packet providing its credentials (user name that
uniquely defines this request for the Client). Then, the Authenticator decapsu-
lates the message and compares its contents against a local database of currently
active users. In case the match occurs, the Authenticator informs the Controller
application. Otherwise, it will encapsulate the message and will forward it to
the Authentication Server. The Authentication Server responds with RADIUS
Access/Challenge to be forwarded to the Supplicant. After that, the Suppli-
cant provides its identifying credentials using EAP-Response/Identity. Then the
RADIUS server verifies the received credentials and transmits either an EAP-
Success (Access-Accept) Packet, if the Client is successfully authenticated and
authorized to gain access to the network, or EAP-Reject (Access-Accept) packet
what means the access is denied and the port is kept blocked. The Authenti-
cator will update its active-user database and will forward the final decision to
the Controller, which accordingly may install new entry on the corresponding
switch’s flow table and apply the predefined policy group for that Client.

4.3 Authorization Process

Typically, authentication and authorization are coupled together. After success-

ful authentication we know “who can access”, while authorization means “who
 New SDN-Oriented Authentication and Access Control Mechanism 83

Fig. 5. Authentication process.

can access what” in the network. This procedure concerns users, devices, and
network services. So, when the Supplicant is correctly authenticated, the Authen-
tication Server returns an EAP-Success (Access-Accept) Packet, which includes
a list of attribute-value pairs (user privileges) that describes the parameters to
be used for the current session. Then, the modified hostapd authenticator for-
wards these messages to the application running on the top of the Controller to
inform about the success of authentication and the identity of the Supplicant
(its MAC address). Such parameters may include: the service type, the protocol
type, the access list to apply, or just the static route to be installed in the Open-
Flow table. Finally, the application running over the Controller translates these
parameter into flow rules to be installed in the responsible switch and applied
on the corresponding port. In such a way, the switch can easily find correlation
between the Supplicant and its flow.

4.4 Database
A Centralized Database with dynamic capacity is maintained to provide means
for fine-grained network access control system and to keep states of currently
authenticated active users, which leads to limiting the concurrent sessions for each
authenticated user. This Database is located at the Authenticator side and is used
to store information about all currently active users. For each successfully authen-
ticated user, a new entry is added. This Database should be searched first for
every authentication request before fetching information from the Authentication
Server. The port-down event messages sent from the switch to the Controller are
a good sign to remove the corresponding entry from the Database.
84 F. Nife and Z. Kotulski

5 Implementation and Functional Validation

5.1 Implementation

The Network Access Control solution, proposed in Sect. 4, has been validated
at the functional level. A proof-of-concept solution has been implemented and
several experiments have been designed and performed. In Fig. 6 we present
a draft view of the validation environment that has been used to prove the
functional viability of our proposal. We have built up our testbed that includes
the following virtual machines:

– Authentication Server: Ubuntu Server 16.04.3 LTS VM to run the FreeRA-

DIUS [31] server v2.1.12., with MySQL database to store the authentication
and authorization resources.
– Authenticator: Ubuntu Server 16.04.3 LTS VM to run the modified version
of the open-source 802.1x hostapd [26]. It is modified to be able to maintain
a local database as well as to establish a secure channel with the Controller.
– Controller: Ubuntu Server 16.04.3 LTS VM to run the POX [32] Controller
along with two applications, forwarding.l2 learning module and our own
application, which is responsible for installing or removing entries in the
switch, based on the results of authentication and authorization processes,
collected from the Authenticator, via the SSL channel.
– Switch: Ubuntu Server 16.04.3 LTS VM to run the Mininet [33] network
emulator used to create the Open vSwitch [34] switch establishing connections
between different entities, for testing purpose.
– Supplicant: Ubuntu Desktop 16.04.3 LTS VM installed wpa-supplicant for
Network Clients. In the testbed there are two Supplicants (Client-1 and
Client-2), one server (providing different services to the network’s devices),
the Centralized Authenticator (maintaining a local database of active authen-
ticated clients), the Authentication Server (storing the users’ credentials), and
the Controller (running the proposed application).

5.2 Validation

To test the correct behavior of our proposed solution and, next, to estimate
its effectiveness, different test and experiment scenarios have been designed and
(partially) implemented. The first test is to show the efficiency of allowing the
authenticated user’s traffic while dropping an unauthorized traffic. For this test,
Client-1 is correctly authenticated and therefore the Controller installs entries in
the switch’s OpenFlow table, which explicitly reflect the client’s privileges. So,
Client-1 can access the network resources, while the other host, Client-2, is an
unauthorized host, so its access request is rejected and no its OpenFlow entries
installed, so the switch refuses all its attempts to access the network resources.
The second experiment is to show “who can access what” in the network. The
simple match-action paradigm offered by the OpenFlow protocol can give a great
 New SDN-Oriented Authentication and Access Control Mechanism 85

Fig. 6. Experiment testbed.

utility of traffic control by giving an ability to filter packets, based on the proto-
col, source and/or destination IP addresses, and source and/or destination port
numbers. For instance, it blocks an address from the accessing HTTP session of
a specific server, while it allows its other services. In fact, using TCP and UDP
ports makes it possible to support or suppress higher level applications. Gener-
ally, the port numbers are associated with applications, so allowing or denying
the access to a specific port number determines, which application can be used,
and which devices can access the port. This allows setting up the network to
carry only certain types of traffic, for instance, the FTP (File Transfer Protocol)
packets or POP3 mail. In this test, the authenticated Client-1 is allowed to start
an HTTP Sessions, while it is forbidden to access Telnet sessions. So, some of the
entries installed are allowed any request to TCP port (80/8080) and are denied
any request to TCP port equal to 23. The last experiment designed is to validate
the solution for the stateless property of RADIUS by testing the Authenticator
database with two scenarios. In the first scenario, we unlimited the ability to use
the same user’s credentials, in which, both, Client-1 and Client-2 successfully
authenticate themselves using the same credentials. Then (the second scenario),
we limit such a possibility to only one session at a time. Therefore, only the first
authentication request can be verified successfully. The above tests have been
implemented and they confirmed correctness of the protocol, as the protocol
worked according to the proposed scenarios. Now, all these tests must be exten-
sively carried out with different environmental constraints to estimate practical
performance of the protocol and its resistance to external disturbance. After
presentation and discussion of our solution, let us summarize security functions
86 F. Nife and Z. Kotulski

and specific functionalities of the SDN-dedicated network authentication sys-

tems, collecting together basic properties of the known solutions (what has been
already presented in Sect. 3). In Table 1 we compare the proposed approach with
some systems known from the literature.

Table 1. Comparison of the proposed approach with other SDN-based Access Control
solutions

Publication Authenticator Layer based Behavior Capabilities required

Ethane [19] Captive portal Layer 3 Reactive Web Browser Support
Resonance [20] Captive portal Layer 3 Reactive Web Browser Support
AuthFlow [23] Captive portal Layer 3 Reactive Web Browser Support
FlowNAC [24] Hostapd Layer 2 Proactive EAPoL in EAPoL
encapsulation
FlowIdentity [25] Hostapd Layer 2 Reactive No
Proposed solution Hostapd Layer 2 Reactive No

6 Conclusions and Future Work

In this paper, we have intended to introduce a new authentication and access con-
trol mechanism for OpenFlow-based SDN networks, by adopting the 802.1x stan-
dard. The proposed solution provides authentication and authorization mecha-
nisms for SDN networks in such a way, that it neither enforces changes to the
SDN paradigm in term of the network’s design or behavior, nor it requires any
support of new supplementary protocols or even it needs no additional configu-
ration of hosts and routers. Another advantage of our solution is that it intends
to overcome the stateless property of the 802.1x protocol by maintaining a cen-
tralized active-user database for the fine-grained network access control system,
which keeps records of currently authenticated users and which limits the concur-
rent sessions. In this solution, the security policy is centralized and dynamically
enforced to the switches. We have chosen to implement the proposed solution
with a reactive mode, to gain an advantage of keeping the data plane’s flow tables
small. For the future enhancements, we reclaim to implement, both, reactive and
proactive modes to improve the overall system’s performance. We also plan to
deploy our prototype in a real network environment to confirm its functionality
and its strength against active attackers.
 New SDN-Oriented Authentication and Access Control Mechanism 87

References
1. Pujolle, G.: Software Networks Virtualization, SDN, 5G and Security. ISTE Ltd.
and Wiley, London and New York (2015)
2. Kreutz, D., Ramos, F.M.V., Verissimo, P.E., Rothenberg, C.E., Azodolmolky, S.,
Uhlig, S.: Software-defined networking: a comprehensive survey. Proc. IEEE 103,
14–76 (2015)
3. Astuto, B.N., Mendonca, M., Nguyen, X.N., Obraczka, K., Turletti, T.: A survey of
software-defined networking: past, present, and future of programmable networks.
IEEE Comm. Surv. Tutor. 16, 1617–1634 (2014)
4. The Open Networking Foundation, OpenFlow Switch Specification (2015).
https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-
v1.5.1.pdf
5. Hu, F., Hao, Q., Bao, K.: A survey on software-defined network and OpenFlow:
from concept to implementation. IEEE Commun. Surv. Tutor. 16(4), 2181–2206
(2014)
6. Lara, A., Kolasani, A., Ramamurthy, B.: Network innovation using OpenFlow: a
survey. IEEE Comm. Surv. Tutor. 16, 493–512 (2014)
7. Ahmad, I., Namal, S., Ylianttila, M., Gurtov, A.: Security in software defined
networks: a survey. IEEE Commun. Surv. Tutor. 17(4), 2317–2346 (2015)
8. Alsmadi, I., Xu, D.: Security of software defined networks: a survey. Comput. Secur.
53, 79–108 (2015)
9. Local and Metropolitan Area Networks’ Port-Based Network Access Control, IEEE
Standard 802.1x (2010)
10. Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., Levkowetz, H.: Extensible Authen-
tication Protocol (EAP), RFC 3748 (Proposed Standard) (2004). http://www.ietf.
org/rfc/rfc3748.txt
11. Rigney, C., Willens, S., Rubens, A., Simpson, W.: Remote Authentication Dial In
User Service (RADIUS), RFC 2865 (Draft Standard) (2000). http://www.ietf.org/
rfc/rfc2865.txt
12. Fajardo, V., Arkko, J., Loughney, J., Zorn, G.: Diameter Base Protocol, RFC 6733
(Proposed Standard) (2012). http://www.ietf.org/rfc/rfc6733.txt
13. Jeong, C., Ha, T., Narantuya, J., Lim, H., Kim, J.: scalable network intrusion
detection on virtual SDN environment. In: 2014 IEEE 3rd International Conference
on Cloud Networking (CloudNet), pp. 264–265, Luxembourg (2014)
14. Francois, J., Aib, I., Boutaba, R.: Firecol: a collaborative protection network for the
detection of flooding DDoS attacks. IEEE/ACM Trans. Netw. (TON) 20, 1828–
1841 (2012)
15. Yoon, C., Park, T., Lee, S., Kang, H., Shin, S., Zhang, Z.: Enabling security func-
tions with SDN: a feasibility study. Comput. Netw. 85(1389–1286), 19–35 (2015)
16. Nife, F., Kotulski, Z.: Multi-level stateful firewall mechanism for software defined
networks. In: Gaj, P., Kwiecień, A., Sawicki, M. (eds.) CN 2017. CCIS, vol. 718,
pp. 271–286. Springer, Cham (2017)
17. Zerkane, S., Espes, D., Le Parc, P., Cuppens, F.: Software defined networking
reactive stateful firewall. In: Hoepman, J.-H., Katzenbeisser, S. (eds.) SEC 2016.
IAICT, vol. 471, pp. 119–132. Springer, Cham (2016). https://doi.org/10.1007/
978-3-319-33630-5 9
18. Pena, J.G., Yu, W.E.: Development of a distributed firewall using software defined
networking technology. In: 4th IEEE International Conference on Information Sci-
ence and Technology, pp. 449–452, Shenzhen, China (2014)
88 F. Nife and Z. Kotulski

19. Casado, M., Freedman, M.J., Pettit, J., Luo, J., McKeown, N., Shenker, S.: Ethane:
taking control of the enterprise. In: ACM SIGCOMM, Kyoto, Japan, pp. 1–12
(2007)
20. Nayak, A., Reimers, A., Feamster, N., Clark, R.: Resonance: dynamic access con-
trol for enterprise networks. In: Workshop: Research on Enterprise Networking
(WREN), Barcelona, Spain (2009)
21. Dangovas, V., Kuliesius, F.: SDN-driven authentication and access control sys-
tem. In: The International Conference on Digital Information, Networking, and
Wireless Communications (DINWC). Society of Digital Information and Wireless
Communication, pp. 20–23 (2014)
22. Kuliesius, F., Dangovas, V.: SDN enhanced campus network authentication and
access control system. In: 2016 Eighth International Conference on Ubiquitous and
Future Networks (ICUFN), pp. 894–899 (2016)
23. Mattos, D.M.F., Ferraz, L.H.G., Duarte, O.C.M.B.: AuthFlow: authentication and
access control mechanism for software defined networking. Ann. Telecommun.
71(11), 607–615 (2016). https://doi.org/10.1007/s12243-016-0505-z. ISSN 0003–
4347
24. Matias, J., Garay, J., Mendiola, A., Toledo, N., Jacob, E.: FlowNAC: flow-based
network access control. In: Third European Workshop on Software-Defined Net-
works (EWSDN), Budapest, Hungary, pp. 79–84 (2014)
25. Yakasai, S.T., Guy, C.G.: Flowidentity: software-defined network access control.
In: IEEE Conference on Network Function Virtualization and Software Defined
Network, pp. 115–120 (2015)
26. Malinen, J.: Hostapd: IEEE 802.11 AP, IEEE 802.1x/WPA/WPA2/EAP/RADIUS
Authenticator. https://w1.fi/hostapd/
27. Green, K., Junghyun, A., Keecheon, K.: A study on authentication mechanism in
SEaaS for SDN. In: IMCOM 2017, Beppu, Japan (2017)
28. Hauser, F., Schmidt, M., Menth, M.: Establishing a session database for SDN using
802.1x and multiple authentication resources. In: IEEE ICC 2017 SAC Symposium
SDN & NFV Track, pp. 1–7 (2017)
29. Heller, B. Sherwood, R., McKeown, N.: The controller placement problem. In:
First Workshop on Hot Topics in Software Defined Networks, ser. HotSDN 2012,
pp. 7–12. ACM, New York (2012)
30. Kreutz, D., Ramos, F.M., Verissimo, P.: Towards secure and dependable software-
defined networks. In: Second ACM SIGCOMM Workshop on Hot Topics in Soft-
ware Defined Networking, ser. HotSDN 2013, pp. 55–60. ACM, New York (2013)
31. FreeRADIUS, FreeRADIUS project. https:freeradius.org/
32. POX Controller, POX wiki. https://openflow.stanford.edu/display/ONL/POX+
Wiki
33. Mininet: An Instant Virtual Network on your Laptop (or another PC). http://
mininet.org
34. O.vSwitch, Open vSwitch - Production Quality, Multilayer Open Virtual Switch.
http://openvswitch.org/
 Full Network Coverage Monitoring
Solutions – The netBaltic System Case

Damian Karpowicz, Tomasz Gierszewski(B) , and Krzysztof Nowicki

Faculty of ETI, Gdańsk University of Technology, Gdańsk, Poland

[email protected]
https://eti.pg.edu.pl/

Abstract. This paper defines the problem of monitoring a specific net-

work, and more precisely – part of reporting process, which is responsible
for the transport of data collected from network devices to station man-
agers. The environment requires additional assumptions, as a specific
network related to the netBaltic Project is to be monitored. Two new
monitoring methods (EHBMPvU and EHBMPvF) are proposed, which
priority is full network coverage. Both are based on employing addi-
tional IPv6 headers. Methods have been ana-lyzed in dedicated simula-
tion environment and compared to classic monitoring solution – SNMP.
The results show, that one of the proposed solutions outperform the
current standard, but depend on traffic characteristics of the network.

Keywords: Network monitoring · IPv6 · netBaltic · Extension headers

1 Introduction
Network monitoring is a term used to describe [1] systematic, continuous con-
trol the behavior of the network and all elements included in this network. The
process of monitoring network consists of five logical parts [2]: data collection,
data representation, reporting, data analysis and presentation of the results. Net-
work monitoring is the key process in the implementation of network manage-
ment tasks and supports, among other things like network functioning analysis,
problem and defects identification and the correctness of network configuration
changes verification.
By collecting data more frequently and gathering more and more various
types of data, more problems can be identified, but it also increases the network
load. This problem becomes more significant with the increasing bandwidth con-
sumption, rising IPv6 protocol popularity and the popularity of the Internet in
general [2] due to network traffic growth – and the volume of measurement
data grows with it. New system solutions for network monitoring should evolve
towards better scalability and performance provision [3], and this is why orga-
nizations are still developing better network monitoring systems.
One way to reduce both the consumption of network bandwidth and computa-
tional overhead in management stations (centers) is to increase the intelligence in
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 89–102, 2018.
https://doi.org/10.1007/978-3-319-92459-5_8
90 D. Karpowicz et al.

devices, which gather monitoring data [4–6]. The first concept is to do some pre-
liminary analysis just in the data collecting devices. In this way these devices send
the partially analyzed data to management stations, instead of the entire set of
monitoring information. The increased intelligence refers also to replacing peri-
odical information sending with reporting performed only upon predefined events
occurrence [2].
Along with the mentioned device intelligence increase, changes in the way
of collected data reporting are also being proposed. An example of such a solu-
tion is the method of Intrinsic monitoring [7–9]. Its major feature is that it
can significantly reduce the generated network traffic [7]. The principle of this
method involves the use of an additional IPv6 header and the transfer function-
ality to decide about sending measurement data to network devices. Their task
is to make autonomous decisions in order to send the measurement data, e.g.
through the use of existing traffic (packets) in the network.
Section 2 describes the character of network monitoring, which is carried out
within the framework of netBaltic project [10,11]. The essence of this network
is that wireless links with a relatively low bit rates and high error rate are the
only available. Section 3 contains a description of analyzed solutions about how
to transport the collected monitoring data. In this section also the EHBMPvU
and EHBMPvF methods are presented. Section 4 is devoted to the comparison
of the developed methods and the classic solution to transport monitoring data.
Finally, Sect. 5 presents the results of the analysis along with the indicators when
and in what conditions should the particular method of reporting be used.

2 The Problem of Monitoring Specific Mesh Network

Topology

The netBaltic Project can be characterized as a heterogeneous, wireless, self-

organizing network with multi-hop transmission. In general there are wireless
links with relatively low bitrates and high error rates mainly due to wavy water
surface interacting with electromagnetic waves. Therefore, an important element
is to ensure the least possible bandwidth.
Reporting of measurements, that is, transporting of the collected data via the
network to the management stations, requires an additional traffic, which affects
the behavior of the network. In case of netBaltic system, it is important that the
monitoring system should provide supervision of all the network elements. This
means that the entire network should be monitored. Another important thing
is that the monitoring solution implementation should pose the least possible
overhead. Such assumptions stem from the nature of the network.
The aim of the netBaltic Project is to develop innovative mechanisms for self-
organizing heterogeneous wireless networks, allowing possibly fast data transfer
between vessels, ships and centers of storage and data processing, as well as the
public Internet access. Wireless data transmission at sea will improve the safety
of navigation through the realization of e-navigation services [10]. This project
 Full Network Coverage Monitoring Solutions – The netBaltic System Case 91

is being implemented by a consortium whose leader is Gdansk University of

Technology. The netBaltic system is intended to provide constant connectivity
with ships and vessels from the Internet. In case this is not possible, to provide
certain services operating in delay tolerant mode (e.g. maps updates, weather
forecast delivery, e-mail). It is important that the construction of the network
structure will be based on IPv6 protocol.
Due to the nature of the network and the characteristics of sea physics it
is essential to employ appropriate mechanisms for routing between nodes. The
priority is to minimize the consumption of bandwidth resources by both the
signaling (routing) and user data selection strategy, to avoid unnecessary trans-
mission. Hence, each netBaltic system node functions as a specialized router.
The routing solution proposed by the netBaltic Project consortium, is to use
two complementary routing protocols, i.e. proactive: TBRP (Tree-Based Rout-
ing Protocol) [12] and reactive: RM-AODV (Radio Metric Ad-hoc On Demand
Distance Vector) [12]. This combination of two complementary types of routing
can be called a hybrid routing. Such combination, known from the IEEE 802.11s
standard [13], is called Hybrid Wireless Mesh Protocol. TBRP routing protocol
employs a tree structure and does not provide full knowledge about the network
topology to each node. When TBRP routing does not guarantee knowledge of
the route between nodes, it is necessary to use the RM-AODV method, which
is a reactive routing protocol, used on demand.

3 Network Monitoring System Proposal

The bandwidth of NetBaltic system is extremely valuable and should be used

reasonably. For this purpose, this paper contains two different proprietary solu-
tions, both based on the mechanism of the additional IPv6 headers.
The first proposal for the monitoring system is called EHBMPvF (Extension
Header Based Monitoring Protocol version Forced), while the second proposal
is EHBMPvU (Extension Header Based Monitoring Protocol version Unforced).
Both solutions of transport monitoring data guarantee full network coverage [14].

3.1 EHBMPvF Method

EHBMPvF monitoring works by sending special monitoring packets, which aim is

to visit specified list of nodes in a predefined sequence. The last address in the list
is the node from which the monitoring packet was sent. Single so-prepared package
allows to collect data from a certain number of nodes, depending on the data link
layer payload size and the size of monitoring data acquired from each node.
Monitoring messages can be sent at a specified time interval or on demand.
Monitoring is initiated from the network node that is monitoring center. The prin-
ciple of monitoring EHBMPvF is based on the additional routing header (type 0)
available in IPv6. This type of additional header, employing IPv6 addresses, allows
to define which network nodes packet has to traverse along its route.
92 D. Karpowicz et al.

The mechanism of formatting lists of nodes’ addresses for packet monitoring

works in a similar way to the BFS (Breadth-First Search) tree (graph) – first the
nodes closest to the monitoring center are visited. As the TBRP proactive routing
protocol produces routing tables with just the number of hops to reach each node
(network prefix in general), this information is used to prepare the list of nodes to
visit in the specified order – from the closest to the most distant ones.
All of these routers’ addresses in the header must be visited in the specified
order, but other nodes may be visited on the way. To specify the list of nodes,
through which a monitoring packet is expected to traverse, it is necessary to use
information kept by the node that is the root of the tree, as it has information
about how to get to all the nodes assigned to it.
When a node receives such packet, it takes action aimed at checking whether
the node is the recipient of this message, i.e. the IPv6 datagram’s destination
address.
If it is not, the package is sent further, according to the route determined by
the routing mechanism. As there is the possibility that the node would not know
the route to the next node specified, the reactive routing protocol RM-AODV is
used to find the route.
If the receiving node belongs to the list of specified addresses, it adds own
monitoring data to the received packet. The data is structured as in Fig. 1 and
belongs to the datagram payload.

Fig. 1. The data structure placed in a package by the monitored node. In parentheses
is the length of the data fields in bits.

The fields’ meaning is the following:

– TimeStamp – this field contains the time of transmitted data. Using a 32-bit
the information about the year (12 bits), month (4 bits), day (5 bits), hour
(5 bits) and minutes (6 bits) can be stored;
– Fragment Length – length in bytes of Data field (16 bits);
– Fragment ID – this is a field informing that the Data field carries only part
of the whole monitoring information. The value identifies the number of the
fragment. The value of 0 indicates that the data placed in the structure is not
fragmented (16 bits)
– Data – contains the collected data from a single node.

Along path traversal each such structure is added, successively one after another,
reflecting the order of nodes along the path specified in the header.
 Full Network Coverage Monitoring Solutions – The netBaltic System Case 93

Changing Network Conditions Mitigation. The EHBMPvF monitoring

uses the information contained in the TBRP root’s routing table of the tree,
which is updated in discrete time periods. Therefore there is possible situation
in which the node being on the list to visit, either loses the possibility to com-
municate, or fails completely, leading to the loss of even indirect communication
with off-shore infrastructure. This means that both the TBRP and RM AODV
protocols won’t be able to find the route. In such situation a modification of the
routing header should be made, by removing the node from the list and sending
the packet to the next node in the list.
Another undesirable situation that may occur, is when one of the nodes loses
packet with monitoring data as a result of an accident. To overcome this, the
TCP protocol is used for sending the monitoring packets for reliability. In case of
damaged link used in the created TBRP tree, besides using tree reconstruction
mechanisms, the other option is to perform RM AODV routing.
All these mechanisms are employed to ensure that the EHBMPvF monitor-
ing solution is resistant to changes in the network, i.e. upon a node failure, or
topology change, the monitoring will continue reacting to current conditions.

Network Coverage in EHBMPvF. Each special packet sent by the monitor-

ing EHBMPvF contains the list of nodes to visit and to collect data from. The
network transfers this packet until each node listed adds its monitoring data,
and then the packet sent back to the monitoring center. The TCP protocol is
used for each step, which ensures that the transfer of packet is successful. In this
way the monitoring center obtains data from the specified part of the network
– the number of nodes is equal to the size of the address list.
Therefore, using the rule of deduction, it can be concluded that if one packet
allows for partial coverage of the network, then sending P packets with unique
node addresses on the list, the full network coverage can be achieved. This num-
ber is determined by the following formula:
 
x
P = w , (1)
z

where:
P – the required number of monitoring packets,
x – total number of nodes to be monitored (value representing the size of the
routing table TBRP at the root of the tree),
w – the maximum size of payload data in the application layer of a single data-
gram in bytes,
z – the size of data collected from each node in bytes (the size should be shared
by all the nodes).

The P value is calculated based on the current number of available network

nodes, taken from the routing table. Hence, the full network monitoring coverage
by the EHBMPvF method can be obtained, if and only if the monitoring center
sends P special packages.
94 D. Karpowicz et al.

3.2 EHBMPvU Method

Collecting data from the nodes in the network using the EHBMPvU monitoring
method involves the use of existing users’ packets as the mean of transport. The
packet have to be addressed to the monitoring center’s IP address. One packet
allows to collect data from a certain number of nodes, depending on the size of
the data itself and available application layer payload space.
The rate of sending data depends on the frequency of nodes’ applications
communication. Monitoring is initiated by each node independently. The princi-
ple of operation in monitoring EHBMPvU is based on an additional new header,
named Monitoring Header, which aims to transport the data required for moni-
toring.
Adding data to the package is possible if and only of the three conditions
are met:

– packet must have a valid recipient. To reach the target data, it can only be
added to a packet, which will meet on its path the monitoring center node;
– the packet have enough space to add an additional header structure either
with the data or the data itself, if the header has been added by some previous
node along route;
– there must be the need to send monitoring data.

Monitoring Header and method of its placement in the packet is shown in Fig. 2.

Fig. 2. Additional Monitoring Header and scheme of placing it in the datagram. In

parentheses is the lengths of the fields in bits.

The proposed Monitoring Header, which is shown in Fig. 2 has the four fol-
lowing fields:

– Next Header – identifies the next header following just after the Monitoring
Header. This field allows for compliance with the mechanism of the additional
headers in IPv6 (8 bits);
– Segments Count – determines the number of nodes, which added data to the
Monitoring Header. When adding data, increase this value (8 bits);
 Full Network Coverage Monitoring Solutions – The netBaltic System Case 95

– Reserved – field that was introduced to take into account possible future
modifications to this header. Currently it is being skipped during processing
(16 bits);
– Payload – field in which structure are added – contain data added by the
node, including monitoring data.
Figure 3 shows the data structure which is placed in the Monitoring Header.
Each new structure is included consecutively one by one.

Fig. 3. The structure of the data placed in the Monitoring Header by the node. In
parentheses is the length of the data fields in bits.

Meaning of the fields of this structure is similar to the structure shown

in Fig. 1 used by the EHBCMPvF method. There is an additional IPv6 Node
Address field at the beginning in the length of a single IPv6 address (128 bits),
which is used to identify the origin of the data. This field contains the IPv6
address of the node which added the data to the packet.
After adding the collected data to the packet, the node sends it towards the
monitoring center. Each packet which has an additional header can carry the
monitoring data from at least one node. The size of monitoring data depends on
meeting the three previously described conditions.

Changing Network Conditions Mitigation. The EHBMPvU monitoring

method is resistant to changes in the network, i.e. when a node failure occurs,
or it loses even indirect communication with offshore infrastructure, monitoring
will continue without this node. This is due to the fact that a damaged node has
no influence on the monitoring process of the other nodes in the network.
The only undesirable situation that may occur is when one of the interme-
diate nodes on the packet route towards the monitoring center lose packet with
monitoring data as a result of an accident. Such situation, however, is addressed
by the use of only TCP application protocol for piggybacking purposes. In case
of damaged link used in the created TBRP tree, besides using tree reconstruction
mechanisms, the other option is to perform RM AODV routing.

Network Coverage in EHBMPvU. Each node in the network operating

the EHBMPvU monitoring method is obligated to make an attempt to send
monitoring data in preconfigured periods of time. Prior sending the data all the
required datagram conditions have to be met, especially the destination address
and the available payload space.
96 D. Karpowicz et al.

The use of just TCP segments ensures that the transfer of packet between
the nodes will be reliable. Finally, the packet reaches the target and monitoring
center receives monitoring data from at least one node. Using the rule of deduc-
tion, it may be concluded that if each node in the network behaves as described
above, full network coverage can be achieved. The worst case scenario requires
using the number of application packets equal to the number of nodes in the
network. The necessary number of packets can be specified as follows:

P ≤x (2)

where:
P – required number of monitoring packets,
x – the number of nodes in the network.

4 Comparison of the Presented Methods with the Classic

Method of Monitoring

In order to determine the efficiency of two proposed methods for the netBaltic
system, the simulations was performed by using the devoted simulator [14] and
the results were compared to the typical monitoring use case – namely the SNMP
protocol. The latter was assumed to work in the send request and wait for
response mode of operation. Scalability, security and the overhead were taken
under consideration in the evaluation.

Fig. 4. Comparing the amount of data generated by the methods EHBMPvF, EHBM-
PvU and SNMP (classic method).
 Full Network Coverage Monitoring Solutions – The netBaltic System Case 97

The experiment was performed on the data collected from the AIS system
by Baltica ship, dated on 6th June, 2014 [15]. The simulation was performed
for snapshots of ships’ positions taken in one hour intervals. Summary, which
provides information about numbers of nodes and links, as well as the sizes of
the root’s arrays of the trees (obtained by the TBRP protocol) for particular
hours, are shown in Table 1. The data for hours 19, 20 and 23 was unavailable,
because the node selected for the root of a tree in TBRP routing, did not contain
any record in its routing table. This is due to the fact that the data collected
by the AIS system by Baltica ship does not necessarily show all the ships in the
Baltic Sea region, because this system has limited range.
For each network snapshot, 15 iterations of the simulation were run during
which data transport methods used for monitoring were analyzed. The results,
which represent the total amount of generated data on all links of the network
are shown in Fig. 4.

Table 1. Hourly summary for number of vessels (nodes in the network) that have been
registered by the AIS.

Time Number Number The size of root’s

(hour) of nodes of links routing table
0 124 3024 99
1 120 2604 116
2 121 3079 112
3 136 3427 134
4 135 3566 134
5 138 3382 136
6 139 3613 130
7 133 2559 126
8 75 685 67
9 60 352 54
10 57 237 47
11 68 339 58
12 64 306 58
13 70 395 64
14 63 281 55
15 59 253 52
16 60 268 45
17 50 200 38
18 54 279 47
21 58 271 47
22 66 371 59
98 D. Karpowicz et al.

To perform monitoring using EHBMPvF method, the reactive routing RM-

AODV was used, due to the fact that the TBRP routing did not provide the
knowledge about the whole structure of connections in the network available at
each node. Therefore, the results of EHBMPvF should be considered together
with the RM AODV overhead.
The evaluation of EHBMPvF monitoring just without taking into account
the effect of RM-AODV protocol resulted in generating about 354% more data
on average in related to the EHBMPvU method. Comparing it with the classic
method gave on average about 61% more data. On the other hand, the classic
method generated on average about 233% more data comparing to the EHBM-
PvU method. Worth mentioning here is the fact, that typically SNMP monitoring
requires several send/receive operations for each OID separately. In our case it
was assumed to be a single request and single bulk response in the size of 128
bytes with monitoring data, which was equal for the other methods too.
The results taking into consideration the amount of data generated also by
the RM-AODV routing, it can be concluded that the EHBMPvF monitoring
required to generate on average about 17,600% of the data compared to the
EHBMPvU method and 4290% to the classic one. These are the worst case
values, because in typical scenario the network would also employ the RM-AODV
for application data routing, so it would reduce the number of on demand routing
calls dedicated purely to monitoring requests, thereby reducing the total amount
of data generated.
Scalability is a very important feature, which allows to assess whether the
future system expansion has a chance to succeed or fail. Analyzing the results
obtained in simulation environment, it was agreed that the EHBMPvU scales
much better than EHBMPvF monitoring. The classic method for network moni-
toring, known as send a request and wait for the response, is a popular solution,
but for the tested networks, it generated on average about 230% more data
compared to the EHBMPvU.
The actual, precise time consumed for collecting data from the whole network
(using presented monitoring methods) is impossible to determine, because of
multitude of factors that may run in parallel in the real system. However, this
time can be estimated.
In the case of EHBMPvF implementation, the duration of the monitoring
process consists of the time required for propagation of special data packets over
the network and delays related to the need for on demand RM-AODV routing.
The more times the RM-AODV on demand routing is called, the more total time
is required for EHBMPvF monitoring.
However, in the EHBMPvU method, besides the time associated with the
propagation of packets from a node to the monitoring center, significant influence
has the time to wait for the right TCP packet. The probability of occurrence an
appropriate packet (which can be used to transport the collected measurement
data) at the node at time T after the occurrence of the request specifying the
need to send the collected data can be represented by the equation:
 T  R
P (A) = P (Y ) p(x)dx h(z)dz (3)
0 1
 Full Network Coverage Monitoring Solutions – The netBaltic System Case 99

where:
P (A) – the probability of an event A, the occurrence of the proper packet;
P (Y ) – the empirical probability of (derived from statistical surveys) the event
y, where y event states that the packet is either addressed to the monitoring
center or has it along its route;
p(x) – empirical probability distribution, which specifies the possibility of passing
through or sending the packet by the node, where x is the packet arrival time;
T – time in which the proper packet occurs;
h(z) – empirical probability distribution which define the probability of a packet
that has a specified size of data field of link layer protocol, where z is the size of
the data field;
R – maximum size of the data field, decreased by size of added monitoring data.
The monitoring time in the classic version of the monitoring depends only on
the delay associated with the propagation of data packets from the monitoring
center to a node, and then back to the monitoring center.
The proposed EHBMPvU monitoring mechanism is not transparent to the
devices in the network, as it requires all devices to support the use of the proposed
additional IPv6 header mechanism. If all the nodes in the network have to be moni-
tored, this means that all the nodes must be able to recognize and process the addi-
tional monitoring header. Otherwise the packet is discarded by the router, because
the node will not know what to do with such header. In case of the EHBMPvF
mechanism, these issues looks different, because the Routing Header (Type 0) is
described in IPv6 [16], but for safety reasons, in the year 2007, the Routing Header
(Type 0) was withdrawn and marked by status of disapproval (deprecated) [17].
Therefore, it may not be supported by the routers. This is due to the fact that this
header can be used to perform DoS (Denial of Service) attacks. The issue has been
solved by introducing Routing Header Type II [18].
In the context of the necessary requirements to perform monitoring, one
should keep in mind the resources of devices in the network. The described
monitoring solutions require the ability to parse, process and send monitoring
data, so routers must have sufficient processing power to perform these tasks,
along with the other functions implemented in router. The busiest router is node
which is the monitoring center, because it collects data from all nodes in the
network. In the EHBMPvF method it is also responsible for sending requests
for collecting data. To send such packets, the router must perform additional
calculations associated with the optimization of the number of required packets
and must allocate a list of addresses to visit for each packet. The EHBMPvF
mechanism uses the RM-AODV on demand routing, which generates additional
traffic in the network and load to the nodes.
Hardware requirements for the classic method of monitoring are similar to
what EHBMPvU requires – the processing of monitoring data.
Security of collected data is also important as they should be kept confidential
and integral. To ensure these requirements, the use of IPsec (Internet Protocol
Security [19–21]) security suite is recommended in the netBaltic Project.
100 D. Karpowicz et al.

5 Summary
To summarize the presented characteristics in Table 2, one can come to the
conclusion that the best solution is to use EHBMPvU monitoring, which is well
scalable, provides full coverage in a short time, has small requirements and is
secured by the means for confidentiality and authenticity. The only problem
which may occur is the case when the application traffic characteristics would
a node require to wait long for the correct data packet. In the extreme case
where the traffic would be strictly limited or the total lack of it, the realization
of EHBMPvU monitoring would not be possible.
Knowing the characteristics of the traffic the probability of sending monitor-
ing data by each node can be estimated – after an event triggering this process
(at certain time or in the response to the identified event in the network).
EHBMPvU method should be used in networks where the characteristics of
the existing traffic does not cause unacceptable delays in providing data used for
monitoring. Longer delays may cause that the transmitted data can be regarded
as outdated.
The classic method of monitoring is the best choice if the network to be
monitored has an unacceptable traffic characteristics to use by the EHBMPvU
solution.

Table 2. Comparison of the characteristics of the analyzed monitoring methods.

EHBMPvF EHBMPvU Classic

monitoring
Scalability n=1 n = 1, 2, 3, 4, 5 n = 1, 2, 3, 4
rating
(10n nodes)
Full network Yes Yes Yes
coverage
Real time to From a few From a few From a few to
complete milliseconds to several milliseconds to several hundreds of
network minutes, hours – minutes, hours – milliseconds,
coverage depending on the depending on the depending on
characteristics of the characteristics of the the size of the
existing network existing network network
traffic traffic
Hardware Support monitoring Support monitoring Support
requirements traffic and RM-AODV traffic monitoring
(the number traffic
of operations
performed)
The security Yes Yes Yes
of transmitted
data
 Full Network Coverage Monitoring Solutions – The netBaltic System Case 101

Alternatively, you can use a hybrid solution using the classic method of mon-
itoring wherever the characteristics of traffic does not allow for acceptable time
to provide data to the monitoring center and EHBMPvU where the time is
acceptable.
The choice of monitoring method for netBaltic system requires testing the
characteristics of mobility. Then and only then it will be possible to unambigu-
ously identify the best monitoring method for this type of network. However,
yet at this early stage of testing, the EHBMPvF method can be rejected due to
very large overhead related to monitoring.

Acknowledgments. This work has been partially supported by the Applied Research
Program under the Grant: ID PBS3/A3/20/2015, founded by the National Centre for
Research and Development.

References
1. Silvestri, S., Urgaonkar, R., Zafer, M., Ko, B. J.: An online method for minimizing
network monitoring overhead. In: 2015 IEEE 35th International Conference on
Distributed Computing Systems (ICDCS), pp. 268–277. IEEE (2015)
2. Lee, S., Levanti, K., Kim, H.S.: Network monitoring: present and future. Comput.
Netw. 65, 84–98 (2014)
3. Mahkonen, H., Manghirmalani, R., Shirazipour, M., Xia, M., Takacs, A.: Elastic
network monitoring with virtual probes. In: 2015 IEEE Conference on Network
Function Virtualization and Software Defined Network (NFV-SDN), pp. 1–3. IEEE
(2015)
4. Prieto, A.G., Stadler, R.: A-GAP: an adaptive protocol for continuous network
monitoring with accuracy objectives. IEEE Trans. Netw. Serv. Manage. 4(1), 2–12
(2007)
5. Dilman, M., Raz, D.: Efficient reactive monitoring. IEEE J. Sel. Areas Commun.
20(4), 668–676 (2002)
6. Jiao, J., Naqvi, S., Raz, D., Sugla, B.: Toward efficient monitoring. IEEE J. Sel.
Areas Commun. 18(5), 723–732 (2000)
7. Höfig, E., Coşkun, H.: Intrinsic monitoring using behaviour models in IPv6 net-
works. In: Strassner, J.C., Ghamri-Doudane, Y.M. (eds.) MACE 2009. LNCS, vol.
5844, pp. 86–99. Springer, Heidelberg (2009). https://doi.org/10.1007/978-3-642-
05006-0 7
8. Shi, L., Davy, A., Muldowney, D., Davy, S., Höfig, E., Fu, X.: Intrinsic monitoring
within an IPv6 network: mapping node information to network paths. In: 2010
International Conference on Network and Service Management (CNSM), pp. 370–
373. IEEE (2010)
9. Shi, L., Davy, A.: Intrinsic monitoring within an ipv6 network: relating traffic flows
to network paths. In: 2010 IEEE International Conference on Communications
(ICC), pp. 1–6. IEEE (2010)
10. Hoeft, M., Gierlowski, K., Nowicki, K., Rak, J., Woźniak, J.: netBaltic: enabling
non-satellite wireless communications over the baltic sea. IEEE Commun.
Mag. 5 (2016). http://gcn.comsoc.org/netbaltic-enabling-non-satellite-wireless-
communications-over-baltic-sea
11. Woźniak, J., Hoeft, M.: Aim and main research tasks of the netBaltic project (in
Polish). Telecommun. Rev. Telecommun. 12, 1301–1303 (2016)
102 D. Karpowicz et al.

12. Institute of Electrical and Electronics Engineers: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications. 802.11-2012 (2012)
13. Institute of Electrical and Electronics Engineers: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications - Amendment 10: Mesh
Networking. 802.11-2011 (2011)
14. Karpowicz, D., Nowicki, K.: Implementation of database API for archival large-
scale AIS data retrieval for netBaltic Project simulation purposes (in Polish). Sci-
entific report, Gdańsk (2016)
15. Lewczuk, M., Hoeft, M., Cichocki, P., Woźniak, J., Nowicki, K.: Systems of AIS
data acquisition, processing and visualization for the netBaltic project (in Polish).
Telecommun. Rev. Telecommun. News 12, 1326–1329 (2016)
16. Deering, S., Hinden, R.: RFC 2460, Internet Protocol, Version 6 (IPv6) Specifica-
tion. Internet Engineering Task Force (1998)
17. Neville-Neil, G., Savola, P., Abley, J.: RFC 5095, Deprecation of Type 0 Routing
Headers in IPv6 (2007)
18. Johnson, D.B., Arkko, J., Perkins, C.E.: RFC 6275, Mobility Support in IPv6
(2015)
19. Seo, K., Kent, S.T.: RFC 4301, Security Architecture for the Internet Protocol
(2005)
20. Kent, S.T.: RFC 4303, IP Encapsulating Security Payload (ESP) (2005)
21. Gierszewski, T.: Transport security mechanisms for netBaltic system (in Polish).
Telecommun. Rev. Telecommun. News 8–9, 813–816 (2017)
 A Novel Auction Based Scheduling
Algorithm in Industrial Internet
of Things Networks

Mike Ojo1 , Stefano Giordano1 , Davide Adami1,2 , and Michele Pagano1(B)

1
Department of Information Engineering, University of Pisa,
Via Caruso 16, 56122 Pisa, Italy
[email protected], {s.giordano,m.pagano}@iet.unipi.it
2
CNIT Research Unit, Galleria Gerace 18, 56100 Pisa, Italy
[email protected]

Abstract. Enabling low data losses and ensuring reliability are essen-
tial requirements to guarantee Quality of Service in Industrial Internet
of Things (IIoT) applications. This can be achieved by the adoption
of various architectures and standards, the most promising of which is
IEEE 802.15.4 Time Slotted Channel Hopping mode. However, there are
still several open issues, such as providing effective scheduling scheme in
the standard. In this paper, we propose a novel auction based schedul-
ing mechanism that uses a first-price sealed bids auction to solve the
throughput maximizing scheduling problem. We considered a central-
ized IIoT network where the gateway makes frequency allocations and
time slot assignment. Simulation results show that the proposed algo-
rithm yields a very close throughput performance to the optimal one
obtained through CPLEX with a much lower complexity.

Keywords: Industrial Internet of Things · TSCH · Auctions

IEEE 802.15.4-2015 · Centralized scheduling · Resource allocation

1 Introduction
The notion of the Industrial Internet of Things (IIoT) has moved beyond its hype
of becoming the next wave of innovation, and today we are seeing a rapid increase
in deployment of IIoT in many application areas, such as smart farming, smart
grids, building automation. IIoT relies on low-cost, low power wireless sensor
and actuator devices with constrained computational capabilities that are con-
nected to the internet through wireless communication technologies [1,2]. The
deployment of such devices has led to the convergence of operational technolo-
gies (i.e., industrial networks) and information technologies (i.e., internet). The
principle of IIoT has also fostered the concept of Industry 4.0, where it is aimed
to provide automation and information domain for services and people [3].
The increasing usage of wireless technologies in industrial environments has
become appealing to many types of applications. This has introduced flexibil-
ity and a cost-effective solution in the network approach, but has also added
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 103–114, 2018.
https://doi.org/10.1007/978-3-319-92459-5_9
104 M. Ojo et al.

numerous challenges, such as means to achieve wired-like reliability, security,

performance guarantees, low power consumption, just to mention a few. The
challenges of using wireless technologies in performing different industrial tasks
is being addressed by standards such as IEEE 802.15.4.
IEEE 802.15.4 is one of the leading standard in IIoT and it defines the physi-
cal (PHY) and the Medium Access Control (MAC) layers for low power, low rate
wireless personal area networks. The third revision of the standard called IEEE
802.15.4-2015 [4] was released to address the limitations of its previous releases.
IEEE 802.15.4-2015 presents Time Slotted Channel Hopping (TSCH), which
provides high reliability by mitigating the effects of interference and multipath
fading through channel hopping, and ensures low power consumption through
time synchronization to various industrial applications running in harsh environ-
ments. IEEE 802.15.4-2015 TSCH mechanism has been adopted into the indus-
trial wireless standards such as ISA.100.11a [5] and WirelessHART [6]. Figure 1
shows the architecture of the proposed IEEE/IETF standardized IIoT.
The standard defines the mechanism of how TSCH executes a schedule, how-
ever, it does not mandate a specific scheduling mechanism, which is open to dif-
ferent implementations from the industry. In this paper, we propose an auction
theory based scheduling method to address the throughput optimal scheduling
problem formulated in [7]. The scheduling model in [7] was slightly modified by
introducing multiple antennas, improving communication reliability. The pro-
posed scheduling model is aimed at accomplishing many tasks at the same time
such as frequency, time slot, data rate allocation in a heterogeneous multi-user
and multi-channel environment. The scheduler, which is executed by the gateway,
maximizes the total throughput of the nodes in the service area while ensuring
that each node is assigned at least one time slot in any scheduling period, with
no collisions occurring among the nodes.
The remainder of this paper is organized as follows: Sect. 2 discusses the
basic concept about TSCH Mechanism and the related work. Section 3 introduces
the system model and the problem formulation. Then, Sect. 4 proposes a novel
scheduling approach based on auctioning. We discusses about the simulation
results in Sect. 5 and finally in Sect. 6, we conclude the paper with some final
remarks.

2 Background and Related Works

2.1 IEEE 802.15.4-2015 TSCH Concept

All nodes are synchronized in TSCH networks and communication occurs at

well-defined times within a time slot. A typical time slot is sufficient to transmit
a single frame and receive an acknowledgement. A slot frame is a group of time
slots that repeats over time and can also be described as time-frequency offset
channel distribution unit (CDU), where each cell represents a fixed time slot in
a specific channel offset. Each node in the network only cares about the cell it
participates in.
 A Novel Auction Based Scheduling Algorithm in IIoT Networks 105

Fig. 1. IEEE/IETF standardised IIoT architecture

TSCH communication is orchestrated by a scheduler, where a schedule is

defined by the time slot and channel on which a node should communicate with
its neighbours. TSCH schedule can be represented by a 2-D slot frame-channel
offset matrix as shown in Fig. 2. The two nodes at either end of the link communi-
cate periodically once in every slot frame. To improve communication reliability,
TSCH proposes to implement channel hopping, with frequency diversity to mit-
igate the effect of narrow-band interference and multipath fading. The channel
offset is translated into a frequency f (i.e., a actual channel) using the following
frequency translation function

f = FM AP (ASN + channeloffset)modNch (1)

where ASN (Absolute Slot Number) counts the number of time slots since the
beginning of the network operation, FM AP is the mapping function to find the
frequency from a channel lookup table and Nch indicates the number of avail-
able physical channels (e.g., 16 when using IEEE 802.15-4 compliant radios at
2.4 GHz).

2.2 Related Works

Several schedule-based MACs have been proposed in the wireless networking
literature, but they can not be applied to the TSCH MAC. Nonetheless, TSCH
paradigm brings this topic into the focus of research again due to the following
reasons: (a) IEEE 802.15.4-2015 standard defines the mechanism for a TSCH
node to communicate, but the standard does not specify how to build an opti-
mized schedule and to construct a schedule is policy specific; and (b) TSCH
brings new opportunities and challenges because of its time synchronization mul-
tiplexed in frequency to improve reliability.
Only few works have focused on scheduling in TSCH networks. The pioneer-
ing work [8] proposed by Palattella et al. focused on a centralized approach based
on matching and colouring of graph theory to plan the distribution of time slot
106 M. Ojo et al.

Fig. 2. Time Slotted Channel Hopping (TSCH) slot-channel matrix with a simple
topology

and channel offset. A distributed scheduling approach [9] was also proposed to
construct optimum multi-hop schedules based on neighbour-to-neighbour sig-
nalling. Another non-graph approach for scheduling is Orchestra [10], a solution
for autonomous scheduling of TSCH in IPv6 Routing Protocol for Low-Power
and Lossy Networks (RPL). Orchestra runs without any central entity, nor any
negotiation, but allocates the slots in such a way that it can be automatically
installed or removed as the RPL topology evolves. In [11], the authors proposed a
scheduling scheme to maximize the energy efficiency, while [12] addresses latency
issues.
In this paper, we focus on a centralized scheduling method based on auc-
tioning to maximize the total throughput in an interference-aware system, since
a centralized approach have been proven to be more effective in practice [13].
The major novelty of our work is that we provide a much more general and
complete scheduling model that achieves frequency, time slot, data rate alloca-
tion in a heterogeneous multi-user and multi-channel environment. Our auction
procedure uses a first-price sealed-bid mechanism [14] to address the throughput
scheduling problem in IEEE 802.15.4-2015 TSCH networks. In first-price sealed-
bid auctions, all bidders simultaneously submit sealed bids (hidden from other
bidders) to the auctioneer. The bidder with the highest bid wins the auction.
Auction based mechanism have been applied to other networks such as cog-
nitive radio networks [15] cellular networks device to device communication sys-
tems [16] peer to peer networks [17], but to the best of our knowledge, this is
the first work that addresses scheduling in IEEE 802.15.4-2015 TSCH networks
using auction based mechanism.
 A Novel Auction Based Scheduling Algorithm in IIoT Networks 107

Fig. 3. Time Slotted Channel Hopping (TSCH) slot-channel matrix where each nk
maintains a link with the gateway (GW ) for both frequency f and time slot t, where
k ∈ {1, ...N }; f ∈ {1, ..., F }, t ∈ {1, ..., T }

3 System Model and Problem Formulation

We consider a time-slotted IEEE 802.15.4-2015 network, where the nodes are
managed by the gateway in a centralized manner as shown in Fig. 3. The network
consists of static nodes, and their locations are assumed to be known. Each
node is equipped with a radio with a communication range Rf and the radio is
assumed to transmit at a fixed transmission power. In addition, different channels
can support different link capacities and transmission ranges. We are given a set
of nodes nk where k ∈ {1, ..., N }, characterized by its frequency f ∈ {1, ..., F }
and its time slot t ∈ {1, ..., T }. A communication graph G(V, E) is used to model
the network, where every node k ∈ V corresponds to a device in the network,
and there is a link e = (u, v) ∈ E if there exists a common channel available
for between u and v. Transmission is successful if the distance between them
u − v ≤ Rf condition is satisfied.
108 M. Ojo et al.

At the beginning of the slot frame, each node nk calculates the transmission
capacity of the channel for each available frequency, and transmits this infor-
mation to the gateway in addition to the number of packets in its buffer (Qk ).
In this way, the gateway constructs a matrix U = [Uk,f,t ], where Uk,f,t is the
number of packets that can be transmitted by node k using frequency f . Upon
collection of all state information such as topology information, traffic generated
by each node etc., the scheduler decides on the frequency assignment with the
goal of maximizing the throughput.
Let Ck,f,t denote the Shannon’s capacity of the link between nk and the
gateway GW at frequency f . Ck,f,t is a function of the signal-to-noise ratio
SN Rk,f,t and represents the theoretical upper bound. In the calculation of Ck,f,t ,
only the background noise is considered as we focus on an orthogonal frequency
assignment. The number of packets that can be sent during a slot frame duration,
Mk,f,t , equals Ck,f,t T where T is the slot frame duration. Accordingly, Uk,f,t
becomes min(Mk,f,t , Qk ).
Considering the binary variable Xk,f,t defined as:
⎧
⎨ 1 if node nk transmits using frequency f in time slot t;
Xk,f,t =
⎩
0 otherwise;

x = [Xk,f,t , k ∈ {1, ...N }; f ∈ {1, ...F }; t ∈ {1, ...T }] is the scheduling decision
vector with elements Xk,f,t . Note that Xk,f,t is a function of the information
available to nk . We calculate the total throughput in TSCH network as

N 
F 
T
C= Uk,f,t Xk,f,t (2)
k=1 f =1 t=1

Interference and spectrum availabilities are constrained in the derivation of the

formula for Uk,f,t . For instance, if a node k is very close to a node i that uses
frequency f in time slot t, then node k cannot use frequency f in the same time
slot, i.e., Uk,f,t = 0. Uk,f,t value quantifies the slot availabilities (i.e., the higher
the Uk,f,t value is, the higher the data rate node k can have if it uses frequency
f in time slot t). Uk,f,t values are input variables for the optimization problem
in this paper. In the following, Uk,f is used instead of Uk,f,t because we assume
that all parameters are to remain constant for each time-slot t of the slot frame
period. The slot frame period is a time duration in which the network conditions
remain fairly stable. For instance, in voice applications, the value of T tends to
be fairly large.
The binary integer linear programming is as follows:

N 
F 
T
Uk,f Xk,f,t
k=1 f =1 t=1 (3)
s.t

F 
T
Xk,f,t ≥ 1; ∀k ∈ {1, ..., N } (4)
f =1 t=1
 A Novel Auction Based Scheduling Algorithm in IIoT Networks 109

Xk,f,t + Xk ,f,t ≤ 1; ∀k, k  ∈ N, k = k  , ∀f, ∀t (5)


Xk,f,t ≤ ak ∀k; ∀t (6)
f

Xk,f,t ∈ {0, 1}; ∀k ∈ N ; ∀f ∈ F ; ∀t ∈ T (7)

In the problem formulation, the objective function in (3) maximizes the total
throughput of all the nodes in TSCH network governed by the gateway. The
constraint in (4) ensures that each node is assigned at least one time slot and
hence provides temporal notion of fairness. The constraint in (5) is used to avoid
collision, by guaranteeing that at most one user can transmit in a certain slot
and frequency offset. Constraint in (6) indicates that node k cannot transmit
at the same time using more frequencies than the number of its transceivers
(antennas) ak because each transceiver can tune to at most one frequency at a
time, and finally (7) indicates a binary decision variable.
We assume in the simulations part of this work that the buffers of the nodes
are continuously backlogged; i.e., there are always enough packets to be transmit-
ted with the data rate determined by the scheduling algorithm. This is necessary
in order to effectively evaluate the scheduling process performance by avoiding
the possible influence of the traffic arrival process. The above formulation does
not assert a minimum throughput guarantee for a node’s transmission, however
it can be extended by simply adding the following constraint for each node and
frequency pair: Umin Xk,f,t ≤ Uk,f , where Umin is the minimum throughput.

4 Auction Based Mechanism Scheduler

In this section, we propose an auction based scheduling algorithm to address the
optimization problem formulated in (3)–(7). Our motivation for using a first-
price sealed-bid auction in designing suboptimal scheduler for the throughput
maximizing scheduler is manifold. First, Uk,f values of any node k are indepen-
dent from other nodes’ values, and each node knows only its own Uk,f , namely
its bid value. Since the bid values do not affect each other, the auctions are held
in a sealed bid fashion. Secondly, in order to maximize the network throughput,
first price auctions are used in our algorithm and an auctioned frequency time
resource pair (F T RP ) is assigned to a node whose bid is greater than all other
bids. The result of an auction related to an F T RP does not impact another
auction which is held simultaneously.
In our TSCH model, we assume that all nodes managed by the same gateway
have the same number of transceivers. The auctioning procedure requires three
main identifiers which are (1) The auctioned resources (r) (2) The bidders (3)
The auctioneer. We indicate the auctioned resources as F T RP ; the bidders as
the nodes in the network; and lastly the auctioneer as the gateway (where the
scheduler resides).
If we ignore constraint (4), (6) and (7), the optimal solution is achieved when
a F T RP is assigned to the node k that has the maximum Uk,f value for the
frequency f (of this resource r). The aim is to assign at least one F T RP to each
110 M. Ojo et al.

node, and to avoid any starving node at the end of the algorithm. A starving
node is indicated as the node that has not been assigned any time slot during any
stage of the algorithm. Our proposed scheduling algorithm is explained through
steps 1 to 6 below.
STEP 1: For each frequency f , find the node who transmits the maximum
number of packets using that frequency. Assign the frequency to that node for
all time slots of the slot frame period. In other words, assign f to node k where
k = argmaxk Uk,f . We denote wk the number of frequencies assigned to node k
at the end of step 1.
STEP 2: If every node is assigned at least one F T RP and wk ≤ ak , ∀k, end.
Otherwise, each node that is assigned more than one frequency sorts its frequen-
cies according to their Uk,f values. If any node k has wk greater than ak , go to
step 4 and 5, else go to step 6.
STEP 3: Do we have a starving node? if yes, go to step 4, otherwise go to
step 5.
STEP 4: Any node k whose wk ≥ ak auctions all time slots of wk − ak of
its frequencies which have the smallest Uk,f values. The F T RP s are auctioned
simultaneously. The starving node bids to the F T RP , whose corresponding Uk,f
value is the greatest one. When the starving node gets a F T RP , it is removed
from the auction procedure. The auctions continue until all the starving node
gets a F T RP or when no F T RP remains. At the end of the auctioning proce-
dure, if we still have F T RP that are not assigned to any node, they are auctioned
out to the nodes that have available transceivers. Otherwise, if there still exists
a starving node and all resources are assigned, then go to step 6.
STEP 5: Any node k whose wk ≥ ak takes ak of its frequencies with the largest
Uk,f values. The F T RP s which belong to the remaining wk − ak frequencies are
assigned greedily to the nodes who have available transceivers.
STEP 6: Any node k that is assigned more than one frequency auctions wk − 1
number of its frequencies which have the smallest Uk,f values until either no
starving node remains or the auctioned F T RP run out. When all nodes have
at most a single frequency, if any starving node exists they auction out their
remaining frequencies.

5 Performance Evaluation
A simulation based study was carried out in order to evaluate the performance of
the proposed algorithm. We consider a TSCH network consisting of sensor nodes
randomly placed over a square area of 100 m × 100 m and a gateway located in
the center. The x and y coordinates of each node follow a uniform distribution.
Every node is equipped with a radio that has a transmission range of 30 m. Uk,f
values are different owing to the changing network conditions and are obtained
for 3000 slot frame periods in each set of simulations where the average is consid-
ered. Each slot frame period consists of 30 time slot, where each time slot has a
 A Novel Auction Based Scheduling Algorithm in IIoT Networks 111

duration of t = 10 ms. We then solve for the throughput maximizing scheduling

problem in (3)–(7). using ILOG-CPLEX [18]. We compare the proposed auction
heuristic scheduler with the optimal result obtained through ILOG-CPLEX.
Figure 4 highlights how the average network throughput is affected by varying
the number of nodes and frequencies. Fopt indicate the number of frequencies
used in the ILOG-CPLEX simulations, whereas Fauc indicates the number of
frequencies used in our proposed auction based heuristic algorithm. It can be
seen that the performance of our heuristic is very close to the optimum value in
all cases. Moreover, it can also be seen that the average network throughput is
almost invariant for varying the number of nodes when F is small (i.e. F = 3) in
both cases. This is because the number of frequencies available for the nodes is
small, which makes no much difference to have increasing number of nodes in the
system because almost all of the resources are already occupied by all nodes even
when the number of nodes is small. As the number of frequencies increases, the
average network throughput grows with the number of nodes. This behaviour
does not change up to a threshold where network throughput saturates.
We also point out in Fig. 5 how the number of frequencies and antennas
affects the performance of the throughput maximization scheduler as shown.
We can notice that increasing the number of antennas of each node in the net-
work only makes sense when there is a certain number of frequencies in the
system. For instance, having only one antenna i.e., a = 1 has the performance as
having multiple antennas i.e., a > 1 when the number of frequencies is small
(when F < 8). On the other hand, there is a significant difference in the through-
put when we increase the number of antennas from 1 to 2 if the frequencies are
between 8 and 16. The reason for this behaviour is highlighted by constraint (4),
where each node is assigned at least one F T RP . In order to comply with this
constraint, the scheduler which resides at the gateway tends to assign some fre-
quency to the first antenna of each node, and then continue to assign frequencies
to other antennas. For instance, in Fig. 5, we assume that N = 8, and until the
point where N = F , the scheduler assigns the frequencies to the first antennas
of each node. Increasing the number of antennas has similar effect on the total
throughput as increasing the number of nodes. Moreover, between F = N and
F = 2N , the scheduler assigns the frequencies to the second antenna of each
node.

5.1 Computational Complexity

In this section, we compute the computational complexity of our algorithm. At
the end of step 1, assigning a F T RP to each node has a complexity of O(N F )
because for each frequency, we determine the maximum number of packets Uk,f .
This is the best case scenario, when every node is assigned at least one fre-
quency. In the worst case scenario, when all the frequencies are assigned to only
one node which in practice is very unlikely. We need to take into account the
additional complexity of steps 2–6. In step 2, the frequencies are sorted out and
the complexity is O(F log F ). Since we have N − 1 starving nodes to bid for the
frequencies, it will require O((N − 1) log (N − 1)) time to sort out their bids
112 M. Ojo et al.

100

90
F =3
auc
F =3
opt
80 F =9
auc
Throughput (Packets/time-slot)

F =9
opt
F =16
70 auc
F =16
opt

60

50

40

30

20
2 4 6 8 10 12 14 16
Nodes

Fig. 4. Comparison of the proposed scheduling algorithm with the optimum results
obtained through CPLEX simulations

100

90

80
Throughput (Packets/time-slot)

70
a=1 antenna
60 a=2 antenna
a=3 antenna

50

40

30

20

10
2 4 6 8 10 12 14 16
Frequencies (F)

Fig. 5. Average total network throughput for the throughput maximization scheduling
problem by varying the number of antennas and frequencies
 A Novel Auction Based Scheduling Algorithm in IIoT Networks 113

according to N − 1 starving node. Therefore the total computational complexity

of the algorithm is O(N F ) + O(F log F ) + (N − 1) × O((N − 1) log (N − 1)),
that simplifies it to O((N F ) + N 2 logN ).

6 Conclusions
In this paper, we formulated the throughput maximization scheduling problem
for IIoT-TSCH based networks in a centralized way. In more detail, we proposed
a novel heuristic scheduling algorithm based on first-price sealed bid auction
mechanism to solve the problem. The performance of our sub-optimal scheduler
is close to the optimal one obtained through ILOG-CPLEX. We observed that
having many antennas, (i.e., a > 2) does not increase the average throughput.
Moreover, the computational complexity for the best case scenario is O(N F )
while for the worst case scenario is O((N F ) + N 2 logN ).
In our future work, we plan to design approximation algorithms, which have
theoretically provide performance guarantee for the throughput maximization
scheduling problem.

References
1. Willig, A.: Recent and emerging topics in wireless industrial communications: a
selection. IEEE Trans. Ind. Inf. 4(2), 102–124 (2008). https://doi.org/10.1109/
TII.2008.923194
2. Li, X., Li, D., Wan, J., Vasilakos, A.V., Lai, C.-F., Wang, S.: A review of industrial
wireless networks in the context of industry 4.0. Wirel. Netw. 23(1), 23–41 (2017).
https://doi.org/10.1007/s11276-015-1133-7
3. Kagermann, H., Helbig, J., Hellinger, A., Wahlster, W.: Recommendations for
implementing the strategic initiative INDUSTRIE 4.0: Securing the future of Ger-
man manufacturing industry; final report of the Industrie 4.0 Working Group.
Forschungsunion (2013)
4. IEEE Standard for Low- Rate Wireless Networks: IEEE Std 802.15.4-2015 (Revi-
sion of IEEE Std 802.15.4-2011), April 2016
5. ISA-100.11a-2011: Wireless Systems for Industrial Automation: Process Control
and Related Applications. ISA.100.11a-2011 (2011)
6. Chen, D., Nixon, M., Han, S., Mok, A.K., Zhu, X.: Wirelesshart and IEEE
802.15.4e. In: 2014 IEEE International Conference on Industrial Technology
(ICIT), pp. 760–765. IEEE (2014). https://doi.org/10.1109/ICIT.2014.6895027
7. Ojo, M., Giordano, S.: An efficient centralized scheduling algorithm in IEEE
802.15.4e TSCH networks. In: 2016 IEEE Conference on Standards for Communi-
cations and Networking (CSCN), pp. 1–6. IEEE (2016). https://doi.org/10.1109/
CSCN.2016.7785164
8. Palattella, M.R., Accettura, N., Dohler, M., Grieco, L.A., Boggia, G.: Traffic aware
scheduling algorithm for reliable low- power multi-hop IEEE 802.15.4e networks.
In: 2012 IEEE 23rd International Symposium on Personal Indoor and Mobile Radio
Communications (PIMRC), pp. 327–332. IEEE (2012). https://doi.org/10.1109/
PIMRC.2012.6362805
114 M. Ojo et al.

9. Accettura, N., Palattella, M.R., Boggia, G., Grieco, L.A., Dohler, M.: Decentralized
traffic aware scheduling for multi- hop low power Lossy networks in the Internet
of Things. In: 2013 IEEE 14th International Symposium and Workshops World of
Wireless, Mobile and Multimedia Networks (WoWMoM), pp. 1–6. IEEE (2013).
https://doi.org/10.1109/WoWMoM.2013.6583485
10. Duquennoy, S., Al Nahas, B., Landsiedel, O., Watteyne, T.: Orchestra: robust
mesh networks through autonomously scheduled TSCH. In: Proceedings of the
13th ACM Conference on Embedded Networked Sensor Systems, pp. 337–350.
ACM (2015). https://doi.org/10.1145/2809695.2809714
11. Ojo, M., Giordano, S., Portaluri, G., Adami, D., Pagano, M.: An energy efficient
centralized scheduling scheme in TSCH networks. In: 2017 IEEE International
Conference on Communications Workshops (ICC Workshops), pp. 570–575. IEEE
(2017). https://doi.org/10.1109/ICCW.2017.7962719
12. Hosni, I., Théoleyre, F., Hamdi, N.: Localized scheduling for end-to-end delay
constrained low power Lossy networks with 6TiSCH. In: 2016 IEEE Symposium
on Computers and Communication (ISCC), pp. 507–512. IEEE (2016). https://
doi.org/10.1109/ISCC.2016.7543789
13. Palattella, M.R., Accettura, N., Grieco, L.A., Boggia, G., Dohler, M., Engel, T.: On
optimal scheduling in duty-cycled industrial IOT applications using IEEE802.15.4e
TSCH. IEEE Sens. J. 13(10), 3655–3666 (2013). https://doi.org/10.1109/JSEN.
2013.2266417
14. Krishna, V.: Auction Theory. Academic Press (2009)
15. Dong, M., Sun, G., Wang, X., Zhang, Q.: Combinatorial auction with time-
frequency flexibility in cognitive radio networks. In: INFOCOM, 2012 Proceed-
ings IEEE, pp. 2282–2290. IEEE (2012). https://doi.org/10.1109/INFCOM.2012.
6195615
16. Xu, C., Song, L., Han, Z., Zhao, Q., Wang, X., Cheng, X., Jiao, B.: Efficiency
resource allocation for device-to-device underlay communication systems: a reverse
iterative combinatorial auction based approach. IEEE J. Sel. Areas Commun.
31(9), 348–358 (2013). https://doi.org/10.1109/JSAC.2013.SUP.0513031
17. Shneidman, J., Parkes, D.C.: Rationality and self-interest in peer to peer networks.
In: Kaashoek, M.F., Stoica, I. (eds.) IPTPS 2003. LNCS, vol. 2735, pp. 139–148.
Springer, Heidelberg (2003). https://doi.org/10.1007/978-3-540-45172-3 13
18. IBM ILOG CPLEX: V12. 1: Users manual for CPLEX. Int. Bus. Mach. Corpora-
tion 46(53), 157 (2009)
 A New Approach for SDN Performance
Enhancement

Madhukrishna Priyadarsini(B) and Padmalochan Bera

IIT Bhubaneswar, Bhubaneswar, India

{mp18,plb}@iitbbs.ac.in

Abstract. Traditional networks are incapable of reconfiguration to

serve heterogeneous traffic and are potentially error-prone. Software
Defined Network (SDN) has evolved as an assuring solution to serve a
good deal of heterogeneous traffic with varying requirements. The basis
of SDN lies on separation of dataplane from the control programs pro-
viding flexibility to reconfigure the controller with change in network
demands such as varying throughput, response time. On the other hand,
it also introduces certain challenges towards scalability and performance,
security hardening, cross-layer communication.
This work presents an efficient traffic scheduling architecture for SDN
controllers. The basis of the scheduling architecture is driven by simula-
tion based performance analysis of different state-of-art controllers. Our
scheduling algorithm is designed over NOX, POX, Beacon and Flood-
Light controllers based on their response to different traffic. The schedul-
ing decisions are taken after checking the contextual information from
the OpenFlow packet header and the existing traffic load on the con-
troller. The proposed solution can be realized in the hypervisor which
can effectively schedule the traffic to different controllers.
On the other hand, we have also used multi-threaded execution of net-
work functions in the controllers that provides significant enhancement in
response time. The efficacy of our proposed packet scheduler is reported
with experimental results that justify the effective inter-controller com-
munication among various SDN domains.

Keywords: Software Defined Network (SDN) · Performance

Controller · NOX · POX · Beacon · FloodLight · Packet scheduler
Inter communication

1 Introduction
The recent trends of data digitization in large scale call for significant changes in
the communication technologies and network platforms. In traditional network,
computing infrastructure, and protocol stack may not be suitable to provide ade-
quate solutions to such growing and heterogeneous demands. This leads towards
a divergent approach in network systems architecture, called Software Defined
Network (SDN). Software Defined Networking is a layered network framework
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 115–129, 2018.
https://doi.org/10.1007/978-3-319-92459-5_10
116 M. Priyadarsini and P. Bera

that provides unprecedented programmability, automation, and networks con-

trol by ramifying the control plane and the data plane of the network. In SDN
architecture, network intelligence and states are logically centralized, and the
underlying network infrastructure is abstracted for network applications. Net-
work architectonics, where the control plane is separated from the data plane
has been gaining popularity with scope of research and developments. One of the
major features of this approach is that it provides a more structured software
environment for developing network-wide abstractions while potentially simpli-
fying the data plane. A generic architecture of SDN is shown in Fig. 1.

Fig. 1. Software Defined Network architecture

SDN offers various prevalence, such as centralized and decentralized control

of multiple cross-vendor network elements, mainly data plane platforms with a
common API abstraction layer for all SDN-enabled equipment. It dwindles the
complexity of network configuration and operation that is achieved by automa-
tion of high level configuration and forwarding behaviour of network elements [7].
SDN acquiesces easy deployment of new protocols and network-services which
leads towards high operation abstraction. SDN framework can adjust to the
specific user application running on it through control plane, which abundantly
improves the user experience [14].
Performance enhancement in SDN is a prerequisite for its usage in real life
implications. Explicitly an initial estimation of the performance of openflow net-
works is crucial for network architects and designers [2]. The added flexibility and
functionality require additional overhead on the equipment, and as a result there
are performance forfeiture in terms of processing speed and throughput [5]. This
is not suggesting that the overall performance is necessarily decreasing; many
network services and tasks that were executed by the end-nodes or by the control
layers of the network systems can be executed by the SDN-enabled equipment
in a simpler and quicker way [8]. In addition to above mentioned issues, it also
 A New Approach for SDN Performance Enhancement 117

leads to create a green environment, which we can call as Green ICT. Basically
performance enhancement reduces energy consumption through out the network,
mainly in data centers which leads to a green environment. SDN performance is
evaluated considering following network parameters: Throughput, Latency, Jit-
ter, Bandwidth, Response Time. In this paper, we evaluated the performance
of SDN controllers based on the above mentioned parameters and reported the
applicability of the various controllers in heterogeneous traffic scenarios. This
comparison drives us to design a logical decision making module, called packet
scheduler that schedules the traffic in different controllers with varying require-
ments. The scheduler can be implemented inside the SDN hypervisor. It has
been observed that the performance of controller improves significantly based
on our proposed controller architecture with appropriate inter SDN controller
communication.
The rest of the paper is organized as follows. Section 2 presents the motivation
and objectives of the work. We describe a study of different SDN controllers
like NOX, POX, Beacon, Floodlight along with simulation results without our
proposed packet scheduler algorithm in Sect. 3. Section 4 states about the packet
scheduler inside the hypervisor, its functionality and its communication with the
controller, also inter controller communication between various SDN domains.
We conclude in Sect. 5 with further proceedings.

2 Motivation and Objectives

Now-a-days, large number of heterogeneous applications are being executed in
the backbone networks of any organizations or publicly accessible networks [1].
On the other hand, the requirements of the organizations are becoming hetero-
geneous and stringent in terms of cost and QoS. In such scenarios, the increase
in traffic and the varying requirements normally cause degradation in network’s
bandwidth, response time, throughput and SDN controllers’ response time [19].
In order to maintain and enhance the performance of a network, the analysis
of these parameters of SDN controllers in heterogeneous and live networks with
varying network input is necessary. Analysis discloses relevant traffic for each
controller. This analysis helps in bringing out a logical module which helps in
forwarding the openflow packet to its appropriate controller.
The main objectives of this work are as follows:

1. To analyze the performance of SDN controllers, the network devices and to

extract a comprehensive report with recommendations towards maintaining
performance parameters.
2. To improve the existing network function execution and scheduling algorithms
of controllers.
3. To design new algorithms for enhancement of SDN controllers performance
and reduce energy, time consumption by the whole network and build a green
environment.
118 M. Priyadarsini and P. Bera

3 Simulation of SDN Controllers

Controller is the crux of SDN, which regulates flow control to enable well-
informed networking. It lies between network devices at one edge and appli-
cations at another edge. Any communication between applications and devices
have to pass through the controller [12]. SDN controllers are hinged on protocols
that concedes servers to reveal switches where to forward packets. Controllers
make it possible to control the entire network from a single console. Here we
considered 5 controllers with their working procedures, architectures, implemen-
tations and outcomes.

3.1 Overview of Controllers

(1) NOX: It was initially developed side-by-side with OpenFlow and was the first
OpenFlow controller. It uses the concept of single threading and virtualiza-
tion [20]. NOX is the basic level controller for performance enhancement.
NOX’s network view encompasses the switch level topology; the locations
of users, hosts, middleboxes, and other network elements, and the services
(e.g., HTTP or NFS) being granted. It also incorporates all bindings between
names and addresses, but does not include the current state of network traf-
fic. There exists multithreaded successor of NOX which is known as NOX-
MT. NOX-MT uses well-known optimization techniques (e.g., I/O batching)
to promote the threshold performance.
(2) NOX-MT: NOX-MT, a marginally modified multi- threaded successor of
NOX, to show that with simple tease NOX’s throughput and response time
is significantly improved. The techniques used to optimize NOX are utterly
well-known including: I/O batching to minimize the overhead of I/O, port-
ing the I/O handling harness to Boost Asynchronous I/O (ASIO) library
(which simplifies multi-threaded operation), and used a fast multiprocessor-
aware malloc implementation that scales well in a multi-core machine [20]. It
does not address many of NOX’s performance deficiencies, including: heavy
use of dynamic memory allocation and redundant memory copies on a per
request basis. Addressing these issues would significantly improve NOX’s
performance.
(3) POX: POX is an OpenFlow networking software platform written in Python.
POX started life as an OpenFlow controller, but now functions as an Open-
Flow switch, and also be useful for writing networking software. POX pro-
vides OpenFlow interface and reusable components for path selection, topol-
ogy discovery, etc. POX, which enables rapid development and prototyping,
is becoming more commonly used than NOX.
(4) Beacon: Beacon is a fast, cross-platform, Java-based OpenFlow controller
that supports both event-based and threaded operation [18]. Beacon runs on
many platforms, from high end multi-core Linux servers to Android phones.
Beacon architecture includes event handling, reading openflow messages,
writing openflow messages to enhance performance.
 A New Approach for SDN Performance Enhancement 119

(5) Floodlight: The Floodlight is an enterprise-class, Apache-licensed, Java-

based OpenFlow Controller. It is supported by a community of develop-
ers including a number of engineers from Big Switch Networks. Floodlight
can handle mixed OpenFlow and non-OpenFlow networks [17]. Floodlight
is designed to work with the thriving number of switches, routers, virtual
switches, and access points that support the OpenFlow standard. It peaks
that the link between switch and controller is of primary importance for the
gross performance of the network. If there is some problem in the link then
directly it affects the performance of the controller. Also it cites that high
latency is another cause of degradation of network performance [7].

3.2 Simulation Based Performance Analysis

For the purpose of performance analysis and evaluation, we have simulated four
SDN controllers, namely, NOX, POX, Beacon, Floodlight and represented the
results with necessary recommendations for SDN implementation and deploy-
ment in enterprise network. We have used following environments for our
simulation.

Simulation Environment: Mininet 2.2.2.

SDN Controller Implementation: NOX, POX, Beacon, Floodlight.
Network Performance Tools: Cbench, iperf.
Operating System: Ubuntu 14.04 LTS-64 bit.

For network performance evaluation, we have done extensive simulation by

varying network size from 5–100 nodes (hosts) with 10–20 OpenFlow switches,
number of controllers are varying from 2–15. We also verified the following net-
work parameters dynamically such as bandwidth, throughput, response time,
latency and jitter. The throughput and latency of the controllers have been
observed in both TCP and UDP mode using iPerf and Cbench tools. On the
other hand, we calculated the network jitter in UDP mode. Each host generates
heterogeneous traffic(both VBR and CBR) randomly. The performance varia-
tion in both client (host) and server (controller) systems have been observed.
The simulation results are reported as comparison of throughput, latency and
response time of the controllers. Figures 2, 3 and 4 show throughput, latency,
packet drop ratio of 4 controllers respectively. POX provides better throughput
and high latency than NOX. Beacon controller uses multi-threaded implemen-
tation along with event handling concept which is suitable for all types of traffic
flows. Floodlight can handle both OpenFlow and non-OpenFlow traffic, so use
of Floodlight controller brings maximum performance for the network. Overall
findings of our simulation results are presented in Table 1, where all parameters
values (no. of packets) are considered per second in average.
120 M. Priyadarsini and P. Bera

Table 1. Performance comparison of various controllers

Parameters CBR traffic VBR traffic

NOX POX Beacon Floodlight
Throughput 1180 7569 30230 31615
Latency 1200 2100 3000 3200
PDR 13 8 4 2

Fig. 2. Throughput comparison of controllers before introduction of packet scheduler

Fig. 3. Latency of controllers before introduction of packet scheduler

4 Maneuver of Packet Scheduler

This section describes the functionality of our proposed packet scheduler real-
ized inside SDN hypervisor. Considering the results from previous section we
designed a packet scheduler algorithm which schedules the network traffic
 A New Approach for SDN Performance Enhancement 121

Fig. 4. PDR comparison of controllers before introduction of packet scheduler

efficiently and enhances the performance of the network than the existing ones.
The proposed SDN architecture is shown in Fig. 5. The scheduler receives open
flow packets from switches (Application Layer) and schedules the traffic to its
appropriate controller. We discussed the performance of different controllers in
the last section in terms of bandwidth, latency, jitter, throughput and response
time. The scheduling algorithm is developed based on the performance result of
the controllers. Whenever packet comes from the OpenFlow network, the module
fetches features of incoming packets and forwards accordingly to the pertinent
controller. It is important that, the presence of packet scheduler is nontranspar-
ent to the controller under consideration.

4.1 Implementation of Packet Scheduler

In this subsection, we describe the workflow of the packet scheduler.

First, it creates listener threads that checks for various events. The events are
PacketIN, FlowMod, Error etc. Then, the listener thread forwards the packet to
the specific segment that listens to the particular event. The packet scheduler
consists of a Master Thread which maintains a queue of events as per their
arrival.
In case of the event “new switch connection”, the scheduler creates two sub-
sequent threads and a new Socketchannel which performs READ and WRITE
operations with the target controller. The SocketChannel is shared by both the
threads and it is responsible for READ and WRITE operations from/to the
switch and the target controller. The tuple of the packet along with the port is
stored in the ControllerPort Class.
First Thread (Thread1) consumes packets and address of the target con-
troller from the queue and sends it to the specified controller till the queue is
not empty. Second thread (Thread2) reads data from the shared SocketChannel
and writes data into the switch. Two threads are created for each new switch
122 M. Priyadarsini and P. Bera

Fig. 5. Proposed SDN architecture

connections as shown in Fig. 6. The tuple of the packet along with the port is
stored in the ControllerPort Class. First Thread (Thread1) consumes packets
and address of the target controller from the queue and sends it to the speci-
fied controller till the queue is not empty. Second thread (Thread2) reads data
from the shared SocketChannel and writes data into the switch. For creation of
packet scheduler, we used multi-threaded implementation concept of Floodlight
controller (Netty API for network I/O operations). The threads are terminated
as the corresponding switch is disconnected.

Fig. 6. Architecture of packet scheduler

The packet scheduler schedules the traffic depending upon following two
metrics.
 A New Approach for SDN Performance Enhancement 123

1. Load on the destined controller Lcurrent depends upon two network parame-
ters, total message arrival rate (I) to the controller from switches and round
trip time from each switch to controller (R). The round trip time (R) is mea-
sured by the number of hops present between controller and packet scheduler.
If the load exceeds the predefined threshold (T hr) value, then the packet
scheduler assumes that controller as heavily loaded and calculates load of
other controllers present inside the network. The controller which is lightly
loaded becomes the destination controller for that packet.

Lcurrent = I ÷ R (1)

2. Load on the path λij is considered, depending upon link utilization Uij and
link capacity Cij of each path exists between packet scheduler and the destina-
tion controller. Among all the paths, which ever is having less load, the packet
will follow that path. Packet scheduler sets new destination port Dportnew
according to the traffic type and load of controller and path.

λij = Uij ∗ Cij (2)

The pseudo code of packet scheduler is outlined in Algorithm 1.

Algorithm 1. Scheduling Algorithm of Packets

1 Procedure PacketSchedule (packet(pi ))
Input : Stream of packtes pi
Output: Processed Packets to the source port Sport
2 Read packets from the switch and store them in a queue
3 Tdif f = arrival time difference between any two packets .
4 Thread List T L = Φ
5 for each packet Pi do
6 create threads T1 , T2
7 T L = T1 ∪ T2
8 Extract packet header information Pi <Sport , Dport , length, data>
9 Calculate Lcurrent = I ÷ R and λij = Uij ∗ Cij
10 if (Lcurrent <Threshold) then
11 Set Dportnew considering Tdif f , Lcurrent , λij
12 Thread T1 : Connect (Dportnew );
13 Send();
14 Thread T2 : Connect (Dportnew );
15 Send(Sport );
16 end
17 Return Pi <Sport , data>
18 end Procedure
124 M. Priyadarsini and P. Bera

4.2 Inter Controller Communication

One SDN controller manages one large scale network, termed as SDN domain.
For greater scalability, security, performance, utilization of network resources
efficiently, exchange of information, co-ordination of decision, multiple SDN con-
trollers need to communicate with each other [15].
Requisite of Inter-SDN Controller Communication:
(1) Isolated Controllers for various networks: In order to fulfill customer
demand, SDN controllers across different networks communicate among
themselves and provide services with change in requirements. Occasionally
requests come for data centers present in different networks, in these situa-
tions controllers from various networks communicate with each other.
(2) Content delivery networks: For particular content delivery requirement dis-
tinct SDN controllers communicate, in order to maintain load and serve the
customer. Here is one example to explain this: a cricket match broadcast in
India is being viewed by many fans. As more fans turn on their IP TVs or
come on line to view the game, the load on the server increases, and the
performance of the server decreases. In this situation, it is better to have
customers get data from a server located elsewhere, let’s in Europe, which
has underused capacity.
(3) Bandwidth on demand: A network with single SDN controller, processes a
request for bandwidth change instantaneously. However, when the network
resources are distributed among multiple SDN domains, controllers from
each domain have to communicate with the other SDN controller to share
information on parameters like QoS, bandwidth availability, and so on. This
enables the SDN controllers of each domain to confirm and process the band-
width requirement. Without communication with SDN controllers of various
domains, the processing of requests like bandwidth-on-demand will not pos-
sible.
Inter-SDN controller communication can be implemented in 2 ways: Vertical
or Horizontal approach. Here for our implementation we considered the Hor-
izontal approach. Horizontal approach uses the concept of peer-to-peer com-
munication as shown in Fig. 7. Each controller communicates with its peer for
connection establishment and information accession, that is SDN controller from
other domain in the network.
Connection Between SDN Controllers: Implementation of multiple SDN
domains leads to the matter of exchanging information between these domains.
When SDN is deployed in a distributed large scale networks, our expectation is
to visualize that deployment to a limited portion of the large networks. In other
words, the large network is divided in to numerous SDN domains (a small por-
tion of the large network), where each one is connected with another. These SDN
domains are connected by means of the controllers present inside their regions. It
leads to flexible provisioning of the networks, successive deployment and contin-
uous evaluation, which extends to performance enhancement of the network.
 A New Approach for SDN Performance Enhancement 125

Fig. 7. Horizontal approach for inter-SDN controller communication

A session must be initiated between two controllers using either BGP (Border
Gateway Protocol) or SIP (Session Initiation Protocol). Here we considered BGP
connection over TCP for our better appliances [15]. Controllers need to exchange
information such as:

(i) Reachability Update: During inter controller communication in SDN rout-

ing information need to be exchanged. This allows a single flow to traverse
multiple SDN domains and each controller can select the most appropriate
path in the network.
(ii) Flow setup and update Requests: Controllers exchange flow setup requests
which contains path requirements, QoS among different SDN domains.
(iii) Capability Update: Controllers exchange network capability related infor-
mation such as bandwidth, QoS, software and hardware capabilities avail-
able inside various SDN domains.

Steps involved in Inter controller communication is shown in Fig. 8. As the SDN

controllers are in different SDN domains, they need to setup as BGP speak-
ers. When the controllers are up, they triggered a BGP-Start event. The SDN
controller establish a TCP connection with its neighbour. if there is problem
in connection establishment (e.g. TCP time out or BGP message time expiry)
BGP speaker has to establish connection with another neighbour. BGP uses
TCP as its Transport layer protocol. Once the TCP connection is established,
message sent by both controllers to each other. Once the BGP session is estab-
lished, the BGP update messages are exchanged. Reachability data is exchanged
between SDN controllers to expedite inter SDN routing. Bandwidth information
is exchanged between SDN controllers through BGP UPDATE messages. QoS
information is also carried in the BGP UPDATE message. As the two controllers
are BGP speakers, the reachability data is preserved in the RIB table of each con-
troller. All these information are converted into flows in the OpenFlow switches.
Route selection depends upon BGP process decision when more than one path
is accessible. Packets can traverse successfully once path is established between
two SDN domains, and data exchange can take place through the BGP OPEN
and UPDATE messages [15].
Throughput and latency of NOX, POX, Beacon, Floodlight controller are
calculated after introducing the packet scheduler with inter SDN controller com-
munication.
126 M. Priyadarsini and P. Bera

Fig. 8. Inter controller communication

The Figs. 9, 10 and 11 show throughput, latency and PDR comparison

of NOX, POX, Beacon, FloodLight Controller respectively after introduction
of proposed scheduling algorithm. The results show hike in performance, as
throughput, latency value increased and also packet drop ratio (PDR) decreased
with the packet. The comparison results of different network parameters with
and with out packet scheduler is shown in Table 2, where all the values are
presented as no. of packets per second in an average.
Based on the simulation results, We observed that the introduction of our
proposed packet scheduler enhances performance of all controllers and also a
polished communication takes place between different SDN domains. A higher
increase in throughput and a decrease in PDR have been noticed in the network,
which are clear indicative of controller’s performance enhancement. Proposed
packet scheduler is different from FlowVisor as it not only directs the network
traffic but also calculates the controller and path load, which indicates better
traffic management, load balancing with respect to performance enhancement
of the whole network. Our proposed packet scheduler also reduces energy con-
sumption by the network as well as takes less time for traffic management and
flow, which has indirect impact on the environmental growth. Less energy con-
sumption leads to less CO2 emission and maintain a green environment, which
can be expressed in terms of green ICT.
 A New Approach for SDN Performance Enhancement 127

Fig. 9. Throughput comparison of controllers after introducing packet scheduler

Fig. 10. Latency comparison of controllers after introducing packet scheduler

Table 2. Network parameter values of different controllers before and after introduc-
tion of packet scheduler

Network parameters Before introduction of After introduction of

packet scheduler packet scheduler
Throughput Latency PDR Throughput Latency PDR
Nox 1800 1650 15 3000 2000 7
POX 5000 2800 9 3100 5500 5
Beacon 30000 4300 6 38700 5800 3
FloodLight 33000 4800 4 40000 6000 2
128 M. Priyadarsini and P. Bera

Fig. 11. PDR comparison of controllers after introduction of packet scheduler

5 Conclusion and Future Scope

The performance of controller is one of the major parameters in deploying SDN
in real life implementation and applications. There is a need of developing novel
SDN controller architecture towards serving a large amount of heterogeneous
traffic with security guarantees. In this paper, we present a performance driven
packet scheduler for SDN controllers. In one hand, the scheduler distributes load
to different controllers and thereby achieves higher throughput and less latency.
On the other hand, the scheduler directs the traffic to appropriate controller by
checking the traffic type and parameters. If there is a need of inter controller
communication, then it takes place through controllers of various SDN domains
and thereby reducing the response time and jitter. We have observed significant
performance enhancement in NOX, POX, Beacon and FloodLight controller.
The future scope of this work are as follows:

– We will work on the integration of packet scheduler with the Openflow

switches towards achieving secure implementation and processing of the pack-
ets.
– In addition, we will work on developing controller algorithm and architec-
tures for performance enhancement and ensuring end-to-end security of SDN
controller.

References
1. Salman, O., Elhajj, I.H., Kayssi, A., Chehab, A.: SDN controllers: a compara-
tive study. In: Proceedings of the 18th Mediterranean Electrotechnical Conference
MELECON 2016, Limassol, Cyprus, 18–20 April 2016
2. Chen-xiao, C.: Research on load balance method in SDN. Int. J. Grid. Distrib.
Comput. 9(1), 25–36 (2016)
 A New Approach for SDN Performance Enhancement 129

3. Rao, S.: A Guide for Running Multiple Controllers in Software Defined Networks,
An Article on “TheNewStack”, 21 March 2016
4. Bampal, R.: Cbench Data to Graph (2016). https://github.com/Rhnbmpl/cbench-
data-graph
5. Bholebawa, I.Z., Jha, R.K., Dalal, U.D.: Performance analysis of proposed network
architecture: OpenFlow vs. traditional network. Int. J. Comput. Sci. Inf. Secur.
(IJCSIS) 14(3), 943–958 (2016)
6. Hasan, H., et al.: Improvement of performance of EIGRP network by using a
supervisory controller with smart congestion avoidance algorithm. In: International
Conference on Telecommunications and Multimedia (TEMU) (2016)
7. Zhao, Y., Iannone, L., Riguidel, M.: On the performance of SDN controllers: a real-
ity check. In: IEEE Conference on Network Function Virtualization and Software
Defined Network (NFV-SDN) (2015)
8. Samociuk, D.: Secure communication between OpenFlow switches and controllers.
In: The Seventh International Conference on Advances in Future Internet AFIN
(2015)
9. Benamrane, F., Ben mamoun, M., Benaini, R.: Performances of OpenFlow-based
software- defined networks: an overview. J. Netw. 10(6), 329–337 (2015)
10. Ganesh, S., Ranjani S.: Dynamic load balancing using software defined networks.
In: International Conference on Current Trends in Advanced Computing (ICC-
TAC) (2015). Int. J. Comput. Appl
11. Xia, W., Wen, Y., Foh, C.H., Niyato, D., Xie, H.: A survey on software-defined
networking. IEEE Commun. Surv. Tutorials 17(1), 27–51 (2015)
12. Khattak, Z.K., Awais, M., Iqbal, A.: Performance evaluation of OpenDaylight SDN
controller. In: 20th IEEE International Conference on Parallel and Distributed
Systems (ICPADS) (2014)
13. Shin, S., et al.: Rosemary: a Robust, secure, and high-performance network oper-
ating system. In: CCS 2014, Arizona, USA, 3 November 2014
14. Chilwan, A., et al.: On modeling controller-switch interaction in Openflow based
SDN. Int. J. Comput. Netw. Commun. (IJCNC) 6(6) (2014)
15. Jahan, R., Gupta, D.: White Paper Inter-SDN Controller Communica-
tion using BGP (2014). http://docplayer.net/5817317-Telecom-white-paper-inter-
sdncontroller-communication-using-border-gateway-protocol.html. Accessed July
2017
16. Braun, W., Menth, M.: Software-defined networking using openflow: protocols,
applications and architectural design choices. Future Internet 6(2), 302–336 (2014).
https://doi.org/10.3390/fi6020302
17. Shah, S.A., Faiz, J., M., Farooq, J., Shafi, A., Mehdi, S.A.: An architectural evalu-
ation of SDN controllers. IEEE International Conference on Communications, pp.
3504–3508. IEEE (2013)
18. Erickson, D.: The Beacon OpenFlow controller. In: HotSDN 2013, Hong Kong,
China, 16 August 2013
19. Gelberger, A., Yemini, N., Giladi, R.: Performance analysis of software defined
networking (SDN). In: IEEE 21st International Symposium on Modeling, Analysis
and Simulation of Computer and Telecommunication Systems (2013)
20. Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., Shenker,
S.: NOX: towards an operating system for networks. ACM SIGCOMM Comput.
Commun. Rev. 38(3), 105–110 (2008)
 Quantum Coherence Measures
for Quantum Switch

Marek Sawerwain1(B) and Joanna Wiśniewska2

1
Institute of Control and Computation Engineering, University of Zielona Góra,
Licealna 9, 65-417 Zielona Góra, Poland
[email protected]
2
Institute of Information Systems, Faculty of Cybernetics,
Military University of Technology, Gen. W. Urbanowicza 2, 00-908 Warsaw, Poland
[email protected]

Abstract. We suppose that a structure working as a quantum switch

will be a significant element of future networks realizing transmissions
of quantum information. In this chapter we analyze a process of switch’s
operating – especially in systems with a noise presence. The noise is
caused by a phenomenon of quantum decoherence, i.e. distorting of quan-
tum states because of an environmental influence, and also by some
imperfections of quantum gates’ implementation. In the face of men-
tioned problems, the possibility of tracing the switch’s behavior during
its operating seems very important. To realize that we propose to utilize
a Coherence measure which, as we present in this chapter, is sufficient
to describe operating of the quantum switch and to verify correctness
of this process. It should be also stressed that the value of Coherence
measure may be estimated by a quantum circuit, designed especially for
this purpose.

Keywords: Quantum information transfer · Quantum switch

Quantum coherence

1 Introduction

A field of quantum computing [23,24] called quantum communication [5,12,13,

25] is a dynamically growing research area of network science [11,16]. Quantum
communication deals, inter alia, with processing of quantum information. The
concept of information transmission/switching in a quantum channel is one of
the basic issues connected with quantum communication. In case of quantum
information its transmission and switching are non-trivial problems because of
non-cloning theorem [15,27] and decoherence [9].
A definition of quantum switch, realizing swapping information between
channels A and B, was presented in [20]. A significant issue is to trace the oper-
ating of quantum switch, especially when distortions (caused by an influence of
external environment) of quantum information occur. Correctness of the process
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 130–141, 2018.
https://doi.org/10.1007/978-3-319-92459-5_11
 Quantum Coherence Measures for Quantum Switch 131

may be, for example, verified with use of quantum entanglement phenomenon –
some basic information concerning this method was contained in [4,22]. In this
chapter we suggest utilizing the Coherence measure [3] to evaluate the correct-
ness of switch’s operating. Furthermore, following the results described in [10]
we propose of a quantum circuit that estimates of Coherence measure value for
a quantum switch. It should be stressed that estimating the value of Coherence
measure allows to trace the behavior of quantum system and clearly points out
if it works properly.
The chapter is organized as follows. In Sect. 2 the basic information concern-
ing the quantum switch was presented. This section contains description of the
switch as a Hamiltonian and as a time-dependent unitary operation. There is
also an example of distortions modeled with use of Dzyaloshinskii-Moriya inter-
action [7,19]. Sect. 3 contains definitions of Coherence measure, its properties
and two examples of popular realizations.
A description of measures in context of the switch are presented in Sect. 4. We
showed direct analytical formulas expressing Coherence measure for the switch
during its operating. Conducted numerical experiments demonstrate changes in
value of Coherence measure for systems with and without noise. We calculated
also an analytical formula describing a difference between the values of Coherence
measure for systems without presence of noise and with distortions modeled as
Dzyaloshinskii-Moriya interaction.
The summary and plans for further work are presented in Sect. 5. A list of
references to other works ends this chapter.

2 Quantum Switch
A quantum switch, analyzed in this chapter, is a system of three qubits denoted
as: A, B, C. The states of qubits A and B are unknown:

|A = αA |0 + βA |1, |B = αB |0 + βB |1. (1)

The state of C is known and preserves only two possible alternatives: |C = |0
or |C = |1.
A main task of the quantum switch is swapping an unknown states between
qubits A and B. This operation is performed conditionally: if the state of qubit
|C is |0 then there is no action; but if the state of qubit |C is |1 then the
values of quantum states are exchanged between qubits A and B:

|AB0 → |AB0, |AB1 → |BA1. (2)

The quantum switch may be depict as a circuit built of three quantum gates:
two CNOT gates and one Toffoli gate. The conditional swapping of quantum
states, realized by the mentioned circuit, is presented at Fig. 1.
Utilizing the circuit, shown at Fig. 1, we can denote a matrix form (also
shown at Fig. 1 – case (c)) of an operator realizing the operation performed
by the quantum switch describes the complete process of information switching
132 M. Sawerwain and J. Wiśniewska

Fig. 1. An exemplary circuit presenting the action performed by the quantum switch.
If the state of third qubit is |0 (case (a)) the switch does not swap the states of first
two qubits. When the state of the last qubit is expressed as |1 (case (b)) the circuit
swaps states |A and |B. Case (c) depicts the matrix form of unitary operator which
performs action of quantum switch

without details concerning particular steps of the process. Calculating a time-

dependent unitary operation will allow to present the flow of information through
the quantum switch during its operating time. To obtain this unitary operation
we need to compute a Hamiltonian describing the dynamics of information flow
in a quantum register:
⎛ ⎞
00000000
⎜0 0 0 0 0 0 0 0⎟
⎜ ⎟
⎜0 0 0 0 0 0 0 0⎟
⎜ ⎟
⎜0 0 0 0 0 1 0 0⎟
Hqs = |011101| + |101011| = ⎜ ⎜ ⎟. (3)
⎟
⎜0 0 0 0 0 0 0 0⎟
⎜0 0 0 1 0 0 0 0⎟
⎜ ⎟
⎝0 0 0 0 0 0 0 0⎠
00000000
The operator Hqs is Hermitian, so introducing a variable t we may obtain
a time-dependent unitary operation:
⎛ ⎞
100 0 0 0 00
⎜0 1 0 0 0 0 0 0⎟
⎜ ⎟
⎜0 0 1 0 0 0 0 0⎟
⎜ ⎟
⎜ 0 0 0 i cos(t) 0 sin(t) 0 0 ⎟
Uqs (t) = e−itHqs , Ûqs (t) = ⎜
⎜0 0 0
⎟. (4)
⎜ 0 1 0 0 0⎟⎟
⎜ 0 0 0 sin(t) 0 i cos(t) 0 0 ⎟
⎜ ⎟
⎝0 0 0 0 0 0 1 0⎠
000 0 0 0 01

The operation Uqs (t) causes the change of local phase therefore using the phase-
flip gate allows to obtain operator Ûqs (t) which, naturally, does not introduce
any change of local phase into the system.
Both, shown above, forms of unitary operation Uqs (t) let to trace the process
of switch’s operating according to time t. If the switch acts on a state |AB1 and
 Quantum Coherence Measures for Quantum Switch 133

there is no correction of the local phase then the final state is a pure quantum
state: ⎛ ⎞
0
⎜ α0 α1 ⎟
⎜ ⎟
⎜ 0 ⎟
⎜ ⎟
⎜ cos(t)α0 β1 − i sin(t)α1 β0 ⎟
Uqs (t)|Ψqs  = |Ψqs
t
=⎜
⎜
⎟,
⎟ (5)
⎜ 0 ⎟
⎜ cos(t)α1 β0 − i sin(t)α0 β1 ⎟
⎜ ⎟
⎝ 0 ⎠
β0 β1
where t ∈ 0, π2 .
And representation of this operation as a density matrix ρ is also given:
†
ρ(t) = Uq s(t)|Ψqs
t
Ψqs
t
|Uqs (t). (6)

In Sect. 4 we are going to present the values of Coherence measure with

the presence of noise. To do that the following Hamiltonian, describing
Dzyaloshinskii-Moriya (DM) interaction [7,19], will be used:
y y
HDM = Dz · (σA
x
⊗ σB − σA ⊗ σB
x
) (7)

The notation of operator σA

x
informs us that the Pauli operator X is used on
y
the qubit A and similarly σB means that the Pauli operator Y is used on the
qubit B. The symbol Dz represents the vector of process intensity. A Hamiltonian
HT OT joins the switch and DM interaction:

HTOT = t · Hqs + Dz · HDM , Uqs

DM
(t, Dz ) = e−i(t·Hqs +Dz ·HDM ) . (8)

where UqsDM
stands for the unitary operation. It should be stressed that for Dz
we obtain the Hamiltonian describing only the quantum switch’s operating.
A state of quantum register including an influence of DM interaction may be
expressed as:
⎛ ⎞
0
⎜ α0 α1 ⎟
⎜ ⎟
⎜ 0 ⎟
⎜ ⎟
⎜ (2Dz −it) sinh(γ)α1 β0 + cosh (γ) α β ⎟
U DM
(t) ⎜ 0 1 ⎟
Uqs
DM
(t)|Ψqs  = |Ψqsqs =⎜ γ
⎟ , (9)
⎜ 0 ⎟
⎜ (2Dz +it) sinh(γ)α0 β1 ⎟
⎜ cosh (γ) α1 β0 − ⎟
⎜ γ ⎟
⎝ 0 ⎠
β0 β1

and γ = −4Dz2 − t2 . And also as a density matrix ρ:

ρ(t, Dz ) = U (t, Dz )|Ψqs Ψqs |U † (t, Dz ). (10)

134 M. Sawerwain and J. Wiśniewska

3 Quantum Coherence Measures

Introducing the notion of Coherence needs to point the incoherent quantum
states. This approach is similar to the measures of quantum entanglement where
a set of separable states has to be specified. For a d-dimensional Hilbert space H
we have to define a computational basis, for example the standard computational
basis: {|i}, for i = 0, 1, 2, 3, . . . , d.. The Coherence measure is basis-dependent,
i.e. we consequently use the standard computational basis in this chapter.
Incoherent states I and maximally coherent state |φd  are defined as:
d−1 d−1
1
I = {δ|δ = δi |ii|}, |φd  = √ eiφi |i, (11)
d=0
d i=0

where φi represents a phase of basis element |i.

Operations performed on states described as density matrices ρ are termed
as Incoherent Operations (IO) if for a Complete Positive and Trace Preserving
†
Kn ρKn† we observe that
Kn δKn
(CPTP) projection Λ(ρ) = n Tr[Kn δKn†
]
∈ I for every
value of n and δ ∈ I. A set of these operations may be denoted as Λ(δ) ∈ I for
each δ ∈ I and it is called Maximal Incoherent Operations (MIO). Naturally:
IO ⊆ M IO.
The Coherence measure for ρ is defined by a real-valued function C(ρ). The
function C(ρ) has to fulfil the following properties:
(P1) C(ρ) ≥ 0, ∀ρ and C(δ) = 0 if and only if δ ∈ I,
(P2) monotonicity – the coherence measure C cannot increase its value if refers
to an operation included in IO or MIO represented by channel Λ: C(Λ(ρ)) ≤
C(ρ),
(P3) strong monotonicity with post-selection – for any channel Λ ∈ IO, with
given set of Kraus operators {Kn }, the coherence measure C cannot
increase its average value under the post-selection:
pn C(ρn ) ≤ C(ρ), where ρn = Kn ρKn† Tr[Kn ρKn† ],
n

(P4) convexity – the value of coherence measure C cannot be increased by mixing

quantum states: C( n pn ρn ) ≤ n pn C(ρn ).
Generally, if the measure C fulfils the condition P1 and P2 or P3 then it is a
monotone function and in this case the measure is very useful. Nowadays, the
most widely use Coherence measures are: l1 -norm coherence (Cl1 ) and relative
entropy of coherence (Cre ). These both measures fulfill the above-mentioned
properties.
A significant advantage of both specified measures is their relative simplicity.
The l1 -norm coherence is presented as a sum of all off-diagonal elements of den-
sity matrix and the relative entropy of coherence measure is defined as entropy
difference:
Cl1 (ρ) = |ρi,j |, Cre (ρ) = S(ρdiag ) − S(ρ). (12)
i,j
i=j
 Quantum Coherence Measures for Quantum Switch 135

where S(·) stands for von Neumann entropy and ρdiag denotes a density matrix
without the off-diagonal elements.

4 Coherence Measures for Quantum Switch

The Coherence measures will be utilized to assess the correctness of quantum

switch operating. To do it we need to calculate values of these measures for two
situations: when analyzed quantum state contains noise and without it.
If a quantum state is free from noise, we examine states of two first qubits
A and B. After a partial trace operation, which aim is to remove a state of
controlling qubit C, we obtain a reduced density matrix:

TrC (ρABC ) = ρAB , (13)

where the states |A and |B are unknown. Utilizing measure (12) and carrying
out some necessary transformations allows to calculate the following formula:

Cl1 (ρAB ) = 2 |α0 α1 β0 β1 | + |α0 α1 (cos(t)α0 β1 − i sin(t)α1 β0 )|

+ |β0 β1 (cos(t)α0 β1 − i sin(t)α1 β0 )| + (|α0 α1 | + |β0 β1 |

+ |cos(t)α0 β1 − i sin(t)α1 β0 |) |cos(t)α1 β0 − i sin(t)α0 β1 | . (14)

A value of Coherence measure Cl1 depends on time and states of qubits.

However, if the second qubit |B = |0, we can use (14) and compute:

Cl1 (ρA0 ) = 2 |sin(t)α0 β0 | + 2 |cos(t)α0 β0 | + 2 cos(t) sin(t)β02 (15)

As we can see the value of this measure depends only on time elapsing during
the switch’s operating. Basing on the fact that the quantum state is normalized,
we can directly indicate the constraint concerning the value of Cl1 measure for
the state |A0:

Cl1 (ρA0 ) < (ε + (|sin(t)| + |cos(t)| + |cos(t) sin(t)|)) , (16)

where the state |A is unknown and the constant ε ∈ R.

Generally, the changes of Cl1 value allow to trace the work of switch because
at the beginning of operating, when t = 0, the value of Cl1 is minimal, then in
the middle of the process, that is when t = π/4, the value of Cl1 is maximal.
When the switch finishes operating in a moment t = π/2 the value of Cl1 is the
same as in the moment t = 0. Figure 2 depicts the changes of Cl1 measure for
quantum states:
√ √
1 9 9 1
|A = √ |0 + √ |1, |B = √ |0 + √ |1. (17)
10 10 10 10
136 M. Sawerwain and J. Wiśniewska

and, more generally, for the states described as:

π π
|A = sin(a)|0 + cos(a)|1, |B = sin( − a)|0 + cos( − a)|1 (18)
2 2
where a ∈ 0, π2 .
Remark 1. If the time of switch’s operating is extended, for example, to t = π
and the value of the parameter a is increased to π, we will observe a periodic
character in changes of Cl1 value.
The Cl1 measure, utilized in quantum systems without presence of noise,
offers also the direct possibility of checking if states A and B are the same –
that is if the switch operates on state |AA1.
Theorem 1. For the quantum switch defined as operation Uqs , like in (4), the
value of Cl1 for state |AA1 remains unchanged in time t.
Proof. The above theorem may be proofed by calculating the value of Cl1 for
the state |AA1. After some transformations of Eq. (14) we obtain:
 
Cl1 (ρAA ) = 4|α0 β0 | |α0 |2 + |α0 β0 | + |β0 |2 . (19)

A consequence described by Theorem 1 may be observed at Fig. 2 in case (b)

where the top of the chart is flatten for a = π/4.
If the noise modelled by DM interaction is present in the system, the Cl1
measure shows the distortions’ influence on a quantum state:

ClDM
1
(ρAB ) = 2 |(ξα1 β0 + ηα0 β1 ) (ζα1 β0 + ξα0 β1 )|
+ 2 |α0 α1 (ζα1 β0 + ξα0 β1 )| + 2 |β0 β1 (ζα1 β0 + ξα0 β1 )|
+ 2 |α0 α1 (ξα1 β0 + ηα0 β1 )| + 2 |β0 β1 (ξα1 β0 + ηα0 β1 )| + 2 |α0 α1 β0 β1 | (20)

where the following denotations were used:

1 √ 2 2 1 √ 2 2
ξ = e− −4Dz −t + e −4Dz −t
2√ 2 √
2 2 2 2
e −4Dz −t (−2Dz − it) e− −4Dz −t (−2Dz − it)
η=  − 
2 −4Dz2 − t2 2 −4Dz2 − t2
√ 2 2
√ 2 2
e −4Dz −t (2Dz − it) e− −4Dz −t (2Dz − it)
ζ=  − 
2 −4Dz2 − t2 2 −4Dz2 − t2
We can observe that time t and the level of noise Dz directly affect a quantum
state by modelling its amplitudes. Naturally, these modifications cause changes
of the Cl1 measure value.
Utilizing the definitions of states given in (17) and (18) we present an exem-
plary process of Cl1 value’s changes when the noise is generated by DM inter-
action, what is depicted at Fig. 2. The given characteristic was calculated for
Dz = 0.5.
 Quantum Coherence Measures for Quantum Switch 137

Fig. 2. The changes in value of Cl1 measure: (a) for some exemplary states A and B
given in (17); (b) for a generalized case given in (18). Plots (c) and (d) present the
changes in value of Coherence measure Cl1 when the noise, generated by DM interaction
with intensity Dz = 0.5, is present: (c) for some exemplary states A and B given in
(17); (d) for a generalized case given in (18). The changes in value of relative entropy
measure Cre : (e) for some particular states; (f) for states A and B given in Eq. (18).
Plots (g) and (h) show the changes in value of Cre measure when the noise, generated
by DM interaction with intensity Dz = 0.5, is present: (g) for states given in (17); (h)
for states A and B given in (18)
138 M. Sawerwain and J. Wiśniewska

The properties (P1)–(P4) indicate that the values of relative entropy of coher-
ence measure Cre also correctly depict the differences in a system’s operating
without and with presence of the DM interaction. For quantum states given in
Eqs. (17) and (18) values of relative entropy measure Cre are shown at Fig. 2.
Additionally, Fig. 2 demonstrates values of Cre measure with distortions gener-
ated by DM interaction.
Naturally, the Theorem 1 may be also based on relative entropy measure. It
may be observed that the value of this measure is:
   
2 2 2 2
Cre (ρAA ) = −2 |α0 | |β0 | log |α0 | |β0 |

4 4
+2 |α0 | (log |α0 |) + 2 |β0 | (log |β0 |) , (21)

and again the value of time t is not used.

Regardless the measure, we can observe the difference between values of Cl1
in systems with and without noise. If the difference were always equal zero that
implies the distortions are impossible to detect.
Proposition 1. For the switch’s states ρAB and ρDM
AB we denote the value of
difference based on the Cl1 measure:

ClΔ1 (ρAB , ρDM

AB ) = −2 |ζα1 β0 + ξα0 β1 | (|ξα1 β0 + ηα0 β1 | + |α0 α1 | + |β0 β1 |)
1
− 2 (|α0 α1 | + |β0 β1 |) |ξα1 β0 + ηα0 β1 | + (α1 β0 + α0 β1 ) 2
2
−e4it (α1 β0 − α0 β1 ) 2 + 2 (|α0 α1 | + |β0 β1 |) (|cos(t)α0 β1 − i sin(t)α1 β0 |
+ |cos(t)α1 β0 − i sin(t)α0 β1 |) , (22)
where ξ, η, ζ are denoted as in Eq. (20).
Utilizing Proposition 1 we can directly present an exemplary values of errors
occurring during the switch’s operating what is depict at Fig. 3. It should be
stressed that the value of difference for exemplary plots at Fig. 3 equals zero
only for two points of time t.
An analysis of works [6,8] shows that it is possible to design a quantum
circuit for an estimation of Coherence measure value. Figure 3 depicts a circuit
built to realize this task. The circuit takes an advantage on quantum states
overlapping to estimate a value of Coherence measure – it is approximated with
use of quadratic functional estimation of given density operator.
A significant task is to calculate the values of input states |αpi  and to denom-
inate the form of gate πi , which usually is the SWAP gate. In [10] it was presented
that using the circuit shown at Fig. 3 we can estimate the value of Coherence
measure utilizing the Wigner-Yanase-Dyson skew information [26].
We would like to stress that the estimation of Coherence measure’s value for
states |A and |B may be calculated by a measurement, for example, of state
|αp0 , what was shown in [8]. The probability that |αp0  = |0 may be estimated
as:
Tr (ρA ρB ) = π0 = 2P0 − 1 (23)
 Quantum Coherence Measures for Quantum Switch 139

where ρA = |AA|, ρB = |BB| and P0 is measure projector, whereas π0

represents estimated value of coherence. The value of this probability estimates
also functionals values, including the values of Coherence measure. An accuracy
evaluation of the circuit (Fig. 3) is under the analysis in currently prepared paper
[21].

Fig. 3. The changes in value of absolute difference ClΔ1 : (a) for states given in (17);
(b) for states A and B given in (18). The parameter Dz = 0.5. Figure (c) represents a
quantum circuit for estimation of Coherence measure

5 Conclusions
In this chapter we discussed utilizing the Coherence measure to trace and evalu-
ate the correctness of quantum switch’s operating. First, we described the switch
with use of a Hamiltonian to be able to analyze the evolution of quantum sys-
tem processed by the circuit shown at Fig. 1. We chose the Dzyaloshinskii-Moriya
interaction as a source of noise, which was also modeled as a Hamiltonian. Then
the numerical simulations were performed to evaluate a behavior of the circuit.
As a tool to capture the differences between the switch operating, simulated
140 M. Sawerwain and J. Wiśniewska

with noise or without it, two Coherence measures were used: l1 -norm coherence
(Cl1 ) and relative entropy of coherence (Cre ).
We can observe the difference of Cl1 and Cre values if the system works
with and without a noise. This shows that the Coherence measures allow to
state if the switch operates properly. In addition, an interesting behavior of the
system was observed when the switch worked on an initial state |AA1. The
experiment showed that the value of Cl1 was constant during the simulation –
for other states |AB1, where A = B, the value of measure evaluates in some
characteristic periodic way. This implies that we can also check if the states are
the same with use of Cl1 measure and quantum switch.
Unfortunately, we also observed that for the systems without and with dis-
tortions, modeled as DM interaction, the differences in Coherence measure value
are significant even if their intensity Dz is quite low. It is inconvenient if we would
like to capture the evolution of the system with the different levels of noise.
We presented a quantum circuit which estimates the value of Coherence
measure. Nowadays, technical solutions based on quantum optics [1,2,17] and
also physical implementations of qubits allow to build this kind of circuits with
use of beam splitters, phase shifters and mirrors [14,18].

Acknowledgments. We would like to thank for useful discussions with the Q-INFO
group at the Institute of Control and Computation Engineering (ISSI) of the University
of Zielona Góra, Poland. We would like also to thank to anonymous referees for useful
comments on the preliminary version of this chapter. The numerical results were done
using the hardware and software available at the ”GPU µ-Lab” located at the Institute
of Control and Computation Engineering of the University of Zielona Góra, Poland.

References
1. Abubakar, M.Y., Jung, L.T., Foong, O.M.: Two channel quantum security mod-
elling focusing on quantum key distribution technique. In: 5th International Con-
ference on IT Convergence and Security (ICITCS), Kuala Lumpur, Malaysia, pp.
1–5 (2015)
2. Aguado, A., Lopez, V., Martinez-Mateo, J., Szyrkowiec, T., Autenrieth, A., Peev,
M., Lopez, D., Martin, V.: Hybrid conventional and quantum security for software
defined and virtualized networks. IEEE/OSA J. Opt. Commun. Netw. 9(10), 819–
825 (2017)
3. Baumgratz, T., Cramer, M., Plenio, M.B.: Quantifying coherence. Phys. Rev. Lett.
113, 140401 (2014)
4. Bruß, D., Macchiavello, C.: Multipartite entanglement in quantum algorithms.
Phys. Rev. A 83, 052313 (2011)
5. Cariolaro, G.: Quantum Communications. Springer International Publishing,
Heidelberg (2015)
6. D’Ariano, G.M., Perinotti, P.: Efficient universal programmable quantum measure-
ments. Phys. Rev. Lett. 94, 090401 (2005)
7. Dzyaloshinskii, I.: A thermodynamic theory of “weak” ferromagnetism of antifer-
romagnetics. J. Phys. Chem. Solids 4(4), 241–255 (1958)
 Quantum Coherence Measures for Quantum Switch 141

8. Ekert, A.K., Moura Alves, C., Oi, D.K.L.: Direct estimations of linear and nonlinear
functionals of a quantum state. Phys. Rev. Lett. 88, 217901 (2002)
9. Gawron, P., Klamka, J., Winiarczyk, R.: Noise effects in the quantum search algo-
rithm from the viewpoint of computational complexity. Int. J. Appl. Math. Com-
put. Sci. 22(2), 493–499 (2012)
10. Girolami, D.: Observable measure of quantum coherence in finite dimensional sys-
tems. Phys. Rev. Lett. 113, 170401 (2014)
11. Goścień, R., Walkowiak, K.: A column generation technique for routing and spec-
trum allocation in cloud-ready survivable elastic optical networks. Int. J. Appl.
Math. Comput. Sci. 27(3), 591–603 (2017)
12. Imre, S., Gyongyosi, L.: Advanced Quantum Communications: An Engineering
Approach. Wiley, Hoboken (2012)
13. Li, Y.H., Zhou, Z.Y., Xu, Z.H., Xu, L.X., Shi, B.S., Guo, G.C.: Multiplexed entan-
gled photon sources for all fiber quantum networks. Phys. Rev. A 94, 043810 (2016)
14. Lloyd, S.: Any nonlinear gate, with linear gates, suffices for computation. Phys.
Lett. A 167(3), 255–260 (1992)
15. Jozsa, R.: A stronger no-cloning theorem, arXiv: preprint quant-ph/0204153v2
(2002)
16. Markowski, M.: Heuristic algorithms for joint optimization of unicast and anycast
traffic in elastic optical network-based large-scale computing systems. Int. J. Appl.
Math. Comput. Sci. 27(3), 605–622 (2017)
17. Mehic, M., Fazio, P., Voznak, M., Chromy, E.: Toward designing a quantum key
distribution network simulation model. Adv. Electr. Electron. Eng. 14(4), 413–420
(2016)
18. Milburn, G.J.: Quantum optical Fredkin gate. Phys. Rev. Lett. 62(18), 2124–2127
(1989)
19. Moriya, T.: Anisotropic superexchange interaction and weak ferromagnetism. Phys.
Rev. 120(1), 91–98 (1960)
20. Ratan, R., Shukla, M.K., Oruc, A.Y. : Quantum switching networks with clas-
sical routing. In: 41st Annual Conference on Information Sciences and Systems,
Baltimore, pp. 789–793 (2007)
21. Sawerwain, M., Wiśniewska, J.: Quantum circuit for estimation of quantum coher-
ence during work of quantum switch, in preparation
22. Sawerwain, M., Wiśniewska, J.: The entanglement level and the detection of quan-
tum data transfer correctness in short qutrit spin chains. Wirel. Pers. Commun.
96(4), 5437–5452 (2017)
23. Wegrzyn,
 S., Bugajski, S., Klamka, J.: Foundation of quantum computing. Part 1
Archiwum Informatyki Teoretycznej i Stosowanej 1(2), 97–142 (2001)
24. Wegrzyn,
 S., Bugajski, S., Klamka, J.: Foundation of quantum computing. Part 2
Archiwum Informatyki Teoretycznej i Stosowanej 14(2), 93–106 (2002)
25. van Meter, R.: Quantum Networking. Wiley, Hoboken (2014)
26. Wigner, E.P., Yanase, M.M.: Information contents of distributions. Proc. Natl.
Acad. Sci. USA 49(6), 910–918 (1963)
27. Wootters, W.K., Zurek, W.H.: A single quantum cannot be cloned. Nature 299,
802–803 (1982)
 Performance Evaluation of Web Sites
Using HTTP/1.1 and HTTP/2

Michal Druzgala1 and Ziemowit Nowak2(B)

1
brightONE Sp. z o.o.,
ul. Piotra Skargi 3, 50-082 Wroclaw, Poland
[email protected]
2
Faculty of Computer Science and Management,
Wroclaw University of Science and Technology,
Wybrzeże Wyspiańskiego 27, 50-370 Wroclaw, Poland
[email protected]

Abstract. Introduction into the problem matter of the chapter.

Overview of similar work (literature). Presentation of techniques of
improving the performance of websites used in the HTTP/1.1 protocol
and the problems they can generate in the context of the new possi-
bilities of the HTTP/2 protocol. Description of the research stand and
experiments. Discussion of the results of measurements of the speed of
downloading websites using various techniques. Formulation of conclu-
sions. The directions for further research were pinpointed.

Keywords: Domain sharding · Resource inlining · Concatenation

Minification

1 Introduction
When designing a website, one can influence how the site will be processed on
the target user’s side through a properly designed structure of HTML, CSS or
JavaScript code, as well as by the proper preparation of the resources that make
up the site in terms of structure as well as location. As a result, an important
aspect of website’s design is its performance.
When designing an efficient website, i.e. one that will be quickly processed
and displayed on the client’s side, it is possible to influence its reception, the
general feeling of smoothness and convenience of using the website. A number
of techniques, or proven methods are helpful here that in a universal way fit
into the concept of shortening the loading times. They are based, inter alia,
on the knowledge of the principles of the HTTP protocol, its limitations and
disadvantages [1].
Currently, however, the use of some techniques is questionable in view of the
increasing share of the new version of the HTTP – HTTP/2 protocol, which
offers improvements resulting from the growing demand for efficient websites [2].
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 142–157, 2018.
https://doi.org/10.1007/978-3-319-92459-5_12
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 143

Due to the lack of a full understanding of the impact of the techniques used
so far on HTTP/2 performance, there appeared a need to analyse the classic
rules developed for the HTTP/1.1 protocol, in terms of their further relevance
in view of the prospect of a significant increase in the new version of the protocol.

2 Related Works
Liu et al. [3] conducted a study of the effectiveness of the HTTP/2 protocol
in terms of displaying a site on a mobile device. Using copies of the 200 most
popular sites according to the Alexa rankings on the local server, they conducted
a comparative analysis of HTTPS and HTTP/2 protocols for the impact of
factors such as Round-Trip Time (RTT), bandwidth, packet loss rate and size of
resources. The research showed the advantage of the HTTP/2 protocol, among
others in situations when there was a need to download many smaller objects
and the low rate of packet loss. The authors also noted the possible undesirable
effects associated with the use of good practices derived from the previous version
of the protocol, such as domain sharding, concatenation or inlining.
Corbel et al. [4] examined Page Load Time (PLT) using an unencrypted
version of the HTTP/1.1 and HTTP/2 protocols for the prepared “average site”,
consisting of various types of resources stored on several different domains. The
measurement scenarios assumed several separate delay profiles and the loss rate
of the packet. The analysis showed the advantage of the HTTP/2 protocol in
each scenario. The authors stressed the need to extend the research with the
new mechanisms available in the HTTP/2 protocol and scenarios taking into
account the size of the TCP window at the client’s.
de Saxc’e et al. [5] analysed the impact of the HTTP/1.1 protocol change
on the HTTP/2 protocol in the context of web site load performance. The 20
most popular sites according to the Alexa rankings were used for the purposes
of the research and they were adapted to the needs of the local measurement
environment and the environment similar to network realities (a dedicated HTTP
server located outside the local network). PLT was determined as a measure of
the loading performance of the websites. Measuring scenarios took into account
various pre-defined network conditions (including ADSL and 3G). The research
consisted of a number of scenarios using the new HTTP/2 protocol: compression,
multiplexing, server push and prioritization. As a result of the research, the
authors found the advantage of the new version of the protocol. They noted,
however, worse performance in 3G network conditions (significant vulnerability
to packet loss).
Varvello et al. [6] developed a measurement platform to track the use of
the HTTP/2 protocol among the million most popular websites according to
the Alexa ranking. Their research showed, inter alia, that the owners of most
sites that adopted the new version of the protocol retained techniques developed
for the purposes of the HTTP/1.1 protocol. Among those inlining or domain
sharding can be mentioned. About 80% of registered sites supporting the new
version of the protocol obtained better PLT. The best results were recorded for
3G networks in Europe.
144 M. Druzgala and Z. Nowak

Zarifis et al. [7] performed PLT analysis after switching to the new version of
the HTTP protocol. For research, they used data from the Resource Timing API
for approximately 280,000 visits by Akamai CDN users. Based on the modelling
of the HTTP/2 server behaviour, using the collected visits measurements for
Akamai servers (HTTP/1.1), they tried to analyse the theoretical decreases in
PLT times. The authors showed that theoretically, the use of new techniques
offered by HTTP/2 (server push, prioritization) would have a positive impact
on the final loading times of websites.
Stepniak and Nowak [8] examined the impact of the new version of the pro-
tocol on web applications of the Single Page type (SPA) using different types
of techniques to accelerate the loading of the site (concatenation, compression,
minification). In the context of the HTTP/2 protocol use, they also examined
the capabilities of the server push technique. The research showed a significant
advantage of the HTTP/2 protocol in the event of having to download many
smaller resources. The only aspect that had a negative impact on the loading
times of the site was the use of the server push mechanism.
Rosen et al. [9] analysed the potential benefits of using the server push tech-
nique available for the new version of HTTP from the mobile clients’ perspective.
Their research involved 50 sites from among the top 500 of the most popular
according to Alexa’s ranking, adapted to the local conditions. As a result, they
found measurable benefits stemming from the use of the new technique. Still they
pointed to reduced efficiency of the technique for sites that use multiple servers
to store resources, and in the case of a scenario involving a mobile client with a
device inferior in performance, which may negatively affect the final processing
time of the site (longer download times of the HTML file).
Kim et al. [10] carried out research on the efficiency of loading sites that
use multiple domains to store resources in the context of the HTTP/2 protocol.
They performed PLT measurements for typical Korean sites (which usually use
multiple domains in their structure), copied to the local machine to be analysed.
To construct the research environment, they used a server natively supporting
the HTTP/2 protocol. The research showed increased PLT in all the adopted
scenarios.
Seemakhupt and Piromsopa [11] analyzed scenarios in which the use of stream
multiplexing using the HTTP/2 protocol brings the greatest benefits and may
lead to a deterioration in site loading efficiency. They adopted two scenarios in
the research. In the first one, the client individually queried the HTTP server
for the resources of the site. In the other, an additional client was burdening the
link. The results showed that the use of the HTTP/2 protocol using multiplexing
performs better under low load conditions. However, under load conditions, the
new protocol version performs worse than the HTTP/1.1 protocol.
Prokopiuk and Nowak [12] examined the impact of the new version of HTTP
on the performance of the site from the perspective of the end user (User-
Perceived Web Application Performance). They used WebPagetest tool to mea-
sure the performance of the examined websites, installed on the local client
machine. The tool allowed them to acquire a number of measurements that are
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 145

relevant to the user displaying the site. Network conditions were simulated by
the authors with the help of the Dummynet tool. As a result of the research, the
authors found a beneficial effect of the server push mechanism in almost every
scenario. The greatest benefit came from attaching CSS files and a background
image.

3 Review of Issues Related to the Use of Old Techniques

for the New Protocol

With the introduction of the new version of the protocol, some of the techniques
used for the HTTP/1.1 protocol no longer bring time benefits or – even worse –
negatively affect the total loading times of sites. This section presents problems
resulting from preserving the old solutions after switching to the new version of
the HTTP protocol and suggestions of the new approaches when designing sites
using the HTTP/2 protocol [1,2].

3.1 Domain Sharding

With the development of websites, the need for parallel processing of resources
increased. In the context of the HTTP/1.1 protocol, this meant using additional
TCP connections, even within the same domain. Due to the overhead gener-
ated by additional connections, browser developers established internal limits of
maximum connections within the domain in order to eliminate the risk of pos-
sible overloads of the system. For example, for Google Chrome, the maximum
connection limit is 6. In many cases, the connection limits were too low, which
motivated the creation of a new technique - domain sharding.
The idea of the technique is simple. In order to “cheat” the browser, some
resources are shown in another, additionally created domain, which in fact points
to the same server. Thanks to the use of the technique, it is possible to exceed
the set limits and increase the parallel processing of resources in a browser-
independent manner.

Formulating the Problem. From the perspective of the new mechanism and
message exchange structure for the HTTP/2 protocol, technical improvements
cease to be improvements. The HTTP/2 protocol natively supports full paral-
lelization and multiplexing of messages within a single TCP connection.
The use of domain sharding for the HTTP/2 protocol generates overhead
associated with, among other things, the creation of new TCP connections, while
there is no need to do so. It is not possible either to use the full potential
of mechanisms for prioritizing and controlling the flow of messages due to the
additional TCP connections created. To some extent, the header compression
mechanism also suffers, as it must operate in this situation separately for each
connection, introducing a certain degree of redundancy.
146 M. Druzgala and Z. Nowak

Suggested Solution. Domain sharding is the first technique whose discontin-

uation should be strictly considered. It avoids constraints that no longer exist in
the new version of the protocol (the problem of new TCP connections and the
limited parallelism of resource processing).
Direct cancellation of the technique shall have a positive impact on the site’s
performance, which after the change will use the minimum number of TCP
connections. In addition, it should be taken into account that in order to effec-
tively implement the prioritization and flow control mechanism, transmission of
flows within the minimum number of TCP connections is required. An impor-
tant advantage is also the correct operation of the HTTP header compression
mechanism (the header context is remembered within a single TCP connection).

3.2 Concatenation of Resources

In 2007, the total processing time of the site was only 10÷20%, which included
the time to download the HTML document itself [13]. The remaining time was
devoted to the processing of additional resources appearing as references in the
HTML structure. Due to the growing number of HTTP requests, the overhead
associated with performing an increased number of resource queries became more
and more important from the performance perspective.
A technique of concatenation, i.e. joining resources of one kind in order to
reduce the number of queries, came to the rescue. Merged resources that have
been downloaded must be logically processed to reach their condition from before
the connection. For merged images (sprites) CSS styles are created that “cut”
the one that is needed on the site. There is no need for additional steps for CSS
and JavaScript resources.
Merged resources are readable by the browser in this form. The use of the con-
catenation technique is able to reduce the loading times of sites by up to 50% [13].

Formulating the Problem. In the context of the HTTP/1.1 protocol, the use
of concatenation is beneficial by reducing the problem of simultaneous processing
of many smaller resources. The HTTP/2 protocol reveals its full potential in the
scenario of high resource granulation. The mechanism of multiplexing streams
within a single TCP connection is able to handle single resources in the case of
parallel processing.
The use of the concatenation technique in the context of the HTTP/2 proto-
col creates the problem of a longer wait for a specific resource due to its connec-
tion with others. Another issue is cache management. The smallest change in the
merged resource forces makes it necessary to reprocess the whole (redundancy
of data transfer).

Suggested Solution. The concatenation technique is designed, among other

things, to reduce separate requests to the server, which has a positive impact on
performance in the context of the HTTP/1.1 protocol. Another effect of applying
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 147

the technique is also an increase in compression efficiency for related resources,

which is a positive aspect also in the new version of the protocol.
Due to the above, this technique should not be completely abandoned, but
should not be overused either. One should look for the “golden mean”.

3.3 Resource Inlining

The resource inlining technique allows one to achieve the effect of directly down-
loading resources along with an HTML document in a single HTTP response.
The selected resources are “embedded” (inlined) directly in the HTML docu-
ment, forcing the transfer of the resource along with the structure of the site as
a result.
Embedding a resource may look different depending on the type of resource.
In the case of CSS styles or JavaScript scripts, it is enough to place the content
directly in the HTML structure between relevant tags. In the case of multimedia,
it is possible to attach encoded content in Base64 directly in the HTML tag.
This is another way to reduce the number of queries to the server and in a
way to prioritize some resources (the embedded resources naturally receive the
highest priority). Increased loading times of the base HTML structure should be
borne in mind, however, which delay the start of sending requests for external
resources.

Formulating the Problem. The resource inlining technique offers measurable

benefits in the context of the HTTP/1.1 protocol due to its contribution to
solving the problem of parallel processing of many resources and the reduction
of excess RTT times caused by the processing of separate resources.
The different characteristics of the HTTP/2 protocol mean that the approach
has a negative impact on the website’s loading performance due to a breach of
the concept of multiplexing and prioritizing the transfer of resources that must
be separately identified in the structure of the HTML document. There is also
the problem of data duplication in the case of multiple use of the same resource.
As well as the problem with the effective use of the cache control mechanism.

Suggested Solution. The new HTTP/2 mechanism, server push, provides

an alternative to resource inlining in terms of query reduction. Even the most
naive strategy adopted by the server is better than the direct embedment of the
resource, over the downloading of which the client has no control.

3.4 Minification

Another aspect of shortening transmission times is the reduction of the direct

content of the transferred resource. In the case of resources containing CSS or
JavaScript code, this can be achieved using a technique called minification (and
obfuscation).
148 M. Druzgala and Z. Nowak

Minification involves reducing the white characters used in the code to

improve its readability in the course of its development. White characters are
reduced to a minimum while maintaining the semantic correctness of a given
code. As a result, the resource should not differ from its predecessor in terms
of functionality. Such a modified resource should be included in the document
in order to send a request for an already identified resource (one-off overhead
related to the preparation of the resource).
Obfuscation (darkening) goes a step further, modifying to the minimum the
names given to all programming entities (variables, functions and others) while
maintaining syntactic and semantic correctness with the original. The yield in
relation to the version of the modified resource is noticeable [13].
The experiment [13] carried out on the modified and obscured JavaScript
resources showed a time gain of 17 ÷ 31% (depending on the size of the resource).

4 Analysis of the Speed of Websites Operation Using

Various Techniques
4.1 Research Assumptions
When analyzing the impact of changing the protocol on the performance of the
site, the main measure of performance was the size of PLT [14], the time mea-
sured between the start of navigation to the site and the moment indicating the
completion of processing all additional resources associated with the examined
site.
The user perceived performance aspects were not subject to the study, which
means that information about the speed and order of rendering resources by a
particular browser was not collected and analysed.
The following profiles of the clients visiting the website were adopted:
– desktop client with Google Chrome 59,
– desktop client with Mozilla Firefox 53 browser,
– mobile client (Android) with Google Chrome 59.
As a source of data on the speed of loading the site, only the target client’s
site (supported browser) was determined.
Bearing in mind the assumptions regarding the site’s performance measure-
ment, the decision was made to use the Resource Timing API. It is a JavaScript
programming interface that enables one to obtain precise, high-resolution time
information (parts of milliseconds) for all resources that are part of the site.
Through this interface, it is possible to access information about all HTTP
request components about the resource [15,16].
Jetty 9.4 server was chosen to handle HTTP/2 requests. For the proper func-
tioning of the server, it was required to use an additional ALPN (Application-
Layer Protocol Negotiation) library, allowing the negotiation of the protocol used
at the application layer.
As a basis for the preparation of websites in the simulation environment, a
partially configured Spring Boot demo project with the Jetty server was used
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 149

[17]. The project was modified to support multiple ports, implementation of the
server push mechanism for explicitly defined resources that were part of the
selected site and implementation of the mechanism for capturing and recording
measurement results.
In order to examine the performance of sites using each protocol individually,
a solution was chosen involving the selection of the protocol version by using
appropriately assigned ports:

– port 8080: using the HTTP/1.1 protocol,

– port 8443: using the HTTP/2 protocol.

In both cases, connection encryption was used.

Taking into account the variability of network conditions on a larger scale
over time, the decision was made to conduct measurements in an isolated local
area network where only one server with the examined site was located at the
time of measurement, and one client querying server resources.
Being aware of the fact that it is the first visit that is the key from the per-
spective of the user visiting the site, the decision was made to focus on analysing
only the first visit to the site. It means that all techniques that primarily use the
cache mechanism will not work in a simulation environment, so they were not
taken into account. In order to simulate the continuous effect of the first visits,
it was decided to use developer tools in the browsers, and more specifically, the
option to disable the cache.
In an isolated environment, reflecting the reality of conditions in terms of
bandwidth and prevailing delays while maintaining these conditions unchanged,
a bandwidth control and server-side latency mechanism was adopted. Taking into
account the possible discrepancy in the effectiveness of the techniques used in
terms of network conditions, the following two network profiles were determined
subject to separate measurements:

– DSL profile: 2 Mbit/s bandwidth, 5 ms delay,

– 3G profile: 750 Kbit/s bandwidth, 100 ms delay.

Dummynet [18] was used to simulate the established profiles. It is a tool that
allows one to emulate specific network conditions in real time. Originally created
for FreeBSD, it is now also available for Linux, OSX and Windows distributions.
The tool uses ipfw firewall software. Ipfw allows communicating with Dummynet
via the command line and setting traffic restrictions that ultimately are ipfw
firewall rules. Installed as a service on a network card in Windows, it is able to
capture traffic and subject it to various modifications, including bandwidth and
delays.

4.2 Research Stand

In order to meet the research assumptions and to ensure precise research results,
a dedicated simulation environment was developed (Fig. 1).
150 M. Druzgala and Z. Nowak

The HTTP server was a PC computer with the following parameters:

– Intel Core i5 processor,

– 8 GB RAM,
– Windows 7 32-bit operating system.

The server software was installed on the computer along with the sites to be
examined. On its network card, the Dummynet and ipfw drivers were installed
and, as a result, it was possible to properly manipulate network conditions from
the level of the desktop console.

Fig. 1. Schematic drawing of the research stand.

The HTTP client was based on the Dell Latitude E6440 laptop with the
following parameters:

– Intel Core i5 processor,

– 8 GB RAM,
– Windows 7 32-bit operating system.

On the HTTP client laptop, Google Chrome and Mozilla Firefox were
installed. In both browsers, developer tools and private mode were launched
and activated.
The OnePlus One smartphone was used to examine the mobile version of
Google Chrome using the following parameters:

– Qualcomm Snapdragon 801 processor,

– 3 GB of RAM,
– Android 6 (Marshmallow) operating system.

During the research, the smartphone-client HTTP connected to the router

using Wi-Fi technology in the 802.11n standard.
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 151

4.3 Sites Examined

According to the adopted assumption regarding the separation of the applied

techniques, in order to carry out measurements for each technique individually,
it was necessary to construct separate sites for each technique separately with
the division into the “raw” version (without using any technique) and the version
using the chosen technique. To minimize the need for additional queries, scripts
analysing website load times and any CSS style sheet sources were placed directly
in the HTML code.

Concatenation. The main part of the page under investigation for the tech-
nique of concatenation were six resources in the form of images in the PNG
format. As a raw state, six separate resources defined in the HTML code were
determined for the purpose of rendering six images, which involved their com-
plete separation. As a result of such defining the structure of the site, it was
necessary to download each resource separately.
After applying the concatenation technique, the resources were merged into
one larger resource, which was later logically separated on the client’s side into
individual resources using the CSS styles attached to the HTML structure.
Due to the concatenation technique, only one graphic resource was referenced,
and then its logical “cutting” into individual images took place. As a result, the
HTML object code rendered the images by appropriate references to the CSS
classes.

Inlining. Six resources in the form of images in PNG format were reused for
the purposes of the inlining technique. Also, the “raw” state was determined by
the need to download all other additional resources.
Following the application the inlining technique, resources became an integral
part of the HTML document. References to additional resources were replaced
with references to resources encoded directly in the document using Base64
encoding.
With the “raw” version of the site, a solution utilizing the server push mech-
anism, available in the new version of the protocol, was also analysed. Due to the
architecture of the measurement system, an additional version of the site was
created for the purpose of proper site selection on the backend side. On the side
of the HTML document, the structure did not change with respect to the “raw”
version. Additional graphic resources still had to be downloaded. The difference
was due to the use of the server push mechanism on the backend side using the
explicit resource selection.

Domain Sharding. A separate site was prepared for the domain shard-
ing research purposes. It contained in its body references to twenty graphics
resources that constituted components of a certain graphics composition.
152 M. Druzgala and Z. Nowak

Queries to additional resources were made in a standard way, by including

HTML graphics elements. As a result of establishing such structure of the HTML
document, it was necessary to query the server for each element separately.
When using the HTTP/1.1 protocol, the limits of simultaneous connections
within a single domain had a significant impact on the performance of such
a solution. Thus, additional “virtual” domains were used, entered for the pur-
poses of research into the hosts file. Instead of twenty queries for one domain,
queries were divided into four additional domains, allocating a maximum of six
resources per domain. Behind the additional domains there was exactly the same
IP address from which the HTML document was downloaded.
Due to the need to fully use the HTTP/2 protocol, a third version of the site
was created, having the same structure, differing only in the port number (8443
instead of 8080), used for queries for additional graphics resources.

Minification. For the purpose of analysing the effectiveness of the minification

technique, an appropriate website was also prepared. In the raw document struc-
ture there were three references to additional resources in the form of JavaScript
libraries and CSS libraries with a significant size in relation to the rest of the
site’s resources. In the version using the minification technique, three references
to additional resources were also used, but this time their internal structure was
changed to reduce their size.

4.4 Methodology

Every possible scenario of the user’s visit was subject to a separate measurement
series. The scenario should be understood as a set of the following factors:

– network profile,
– application of the techniques (or the lack thereof),
– protocol version,
– type of browser (along with the type of HTTP client device).

The measurement series consisted of twenty visits, which were individually

recorded in the database as one measurement. Each subsequent visit to the
resource page, being an element of a single measurement, proceeded in a sequen-
tial manner. Each subsequent measurement was started only at the end of the
previous one. Between each individual measurement, a time window of one sec-
ond was established.
The next step was the data cleansing phase, which consisted of the following
activities:

– removal of outliers and measurements with a gross error,

– verification of areas of component values of measurements,
– verification of the correctness of writing to the database.
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 153

After cleaning the collected data, each case was analysed in detail. His-
tograms of purified data were examined to establish the distribution, which
directly affected the decision regarding the adopted measurements.
As a result of the analysis, it was decided that the median values from the
measurement series would be used as the measure of central tendency for the
representation of the results of individual scenarios. The use of median is justified
due to the fact that most of the histograms of the measurement series for the
determined scenarios had a skewed distribution.

4.5 Results of the Analysis and Conclusions

The lists of average PLT times are presented in four tables. In the case of scenar-
ios that differ from the “raw” scenario for the HTTP/1.1 protocol, the percentage
gain (PLT) of the PLT time in relation to this scenario is also given.
Taking into account the current trends in the context of users’ preferences
regarding web browsers and the continuous increase in the share of mobile clients,
after a thorough analysis of the interpreted results, the following conclusions can
be drawn regarding the use of selected techniques in conditions that take into
account the potential use of HTTP/2 for sites with similar of character in relation
to the examined websites.

Concatenation. When deciding on changes in the context of applying the con-

catenation technique, several factors should be taken into account (Table 1). The
trends regarding the website’s clients in terms of used browsers and platforms
(mobile/desktop) should be examined.

Table 1. Comparison of Page Load Time for concatenation scenarios.

Concatenation HTTP/1.1 HTTP/2.0

raw active raw active
PLT [ms] PLT [ms] Gain [%] PLT [ms] Gain [%] PLT [ms] Gain [%]
DSL Chrome PC 148.0 152.0 −2.70% 141.0 4.73% 149.0 −0.68%
Firefox 232.0 184.0 20.69% 192.5 17.03% 181.0 21.98%
Chrome mobile 272.0 276.0 −1.47% 267.5 1.65% 268.5 1.29%
3G Chrome PC 453.0 446.5 1.43% 647.0 −42.83% 647.0 −42.83%
Firefox 1893.0 1278.0 32.49% 1489.0 21.34% 1605.5 15.19%
Chrome mobile 636.0 613.5 3.54% 757.0 −19.03% 769.5 −20.99%

If the majority of users of the site are desktop users with a constant Internet
connection using the Mozilla Firefox browser, it is recommended to continue
using the concatenation technique (17.03% gain PLT for the “raw” version and
21.98% gain for the “active” version).
Otherwise, what is meant by a larger share of mobile clients or using the
Google Chrome browser, it is discouraged to continue using the technique due to
154 M. Druzgala and Z. Nowak

better PLT results without using the technique in the context of the new version
of the protocol (higher gain of the “raw” version compared to the “active” version
by up to 6.15 pp).

Inlining. In the inlining technique, the current trends may also influence the
decision regarding its further use (Table 2).

Table 2. Comparison of Page Load Time for inlining scenarios.

Inlining HTTP/1.1 HTTP/2.0

raw active raw active Server push
PLT [ms] PLT [ms] gain [%] PLT [ms] Gain [%] PLT [ms] Gain [%] PLT [ms] Gain [%]
DSL Chrome PC 148.0 149.0 −0.68% 139.0 6.08% 147.0 0.68% 134.0 9.46%
Firefox 238.5 173.0 27.46% 171.5 28.09% 154.5 35.22% 175.0 26.62%
Chrome mobile 287.5 246.5 14.26% 272.0 5.39% 244.0 15.13% 268.0 6.78%
3G Chrome PC 449.0 426.0 5.12% 645.0 −43.65% 428.5 4.57% 624.0 −38.98%
Firefox 1889.0 1233.0 34.73% 1497.0 20.75% 1427.5 24.43% 1444.0 23.56%
Chrome mobile 850.0 509.5 40.06% 850.0 0.00% 508.5 40.18% 683.0 19.65%

If 3G users make up a significant share of the website, it is highly recom-

mended to adhere to the technique (the highest PLT gain for the “active” ver-
sion, the biggest difference visible for Chrome PC: −32.65% gain for the “raw”
version, 4.57% for the “active” version, −38.98% for the “server push” version).
With increased participation of users with permanent Internet access and
using Google Chrome browser, consider switching to the server push technique
(increase by 8.78 pp in relation to the “active” version and 3.38 pp in relation
to the “raw” version).

Domain Sharding. The domain sharding technique only worked in the 3G

user scenario, equipped with the Google Chrome browser (40.07% PLT gain for
the “active” version, 14.34% gain for the “raw” version) (Table 3).

Table 3. Comparison of Page Load Time for sharding scenarios.

Domain sharding HTTP/1.1 HTTP/2.0

raw active raw active
PLT [ms] PLT [ms] Gain [%] PLT [ms] Gain [%] PLT [ms] Gain [%]
DSL Chrome PC 251.0 257.0 −2.39% 215.0 14.34% 255.0 −1.59%
Firefox 345.5 406.5 −17.66% 347.5 −0.58% 505.0 −46.16%
3G Chrome PC 1078.0 478.0 55.66% 1047.5 2.83% 646.0 40.07%
Firefox 2118.0 1830.0 13.60% 1703.0 19.59% 2256.0 −6.52%

If user participation is largely composed of this type of profile, applying the

technique may be considered. Otherwise, it is recommended to abandon the
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 155

technique for the use of a single domain (gain decreases of up to 45.58 pp in

relation to the “raw” version).

Minification. The situation with the use of minification is clear (Table 4). It
is strongly recommended to continue using the technique to reduce the size of
resources, which in each scenario yields a positive result in the context of PLT
(gain increase of 79.52 pp compared to the “raw” version for the DSL profile
and 143.97 pp in relation to the “raw” version for the 3G profile).

Table 4. Comparison of Page Load Time for minification scenarios.

Minification HTTP/1.1 HTTP/2.0

raw active raw active
PLT [ms] PLT [ms] Gain [%] PLT [ms] Gain [%] PLT [ms] Gain [%]
DSL Chrome PC 7181.5 1727.5 75.95% 7464.0 −3.93% 1753.0 75.59%
Firefox 7211.5 1766.5 75.50% 7531.0 −4.43% 1876.0 73.99%
Chrome mobile 7581.0 2073.0 72.66% 7866.0 −3.76% 2014.5 73.43%
3G Chrome PC 8411.0 1518.5 81.95% 15915.5 −89.22% 3806.0 54.75%
Firefox 11121.0 3337.0 69.99% 17922.0 −61.15% 4970.0 55.31%
Chrome mobile 9246.0 1902.0 79.43% 16496.0 −78.41% 4074.5 55.93%

5 Summary and Directions of Further Work

Properly designed, isolated simulation environment allowed to perform precise
performance measurements of the websites examined in terms of the speed of
loading the site during the first visit. Based on a precise analysis of the cleaned
measurement data, it was possible to draw conclusion concerning the benefits of
using classic techniques for designing efficient websites, including the HTTP/2
protocol. Based on these conclusions, a number of proposals were formulated
regarding changes in the approach to already designed sites in terms of efficient
charging using the old version of the protocol.
It turns out that not all techniques used in the context of the HTTP/1.1 pro-
tocol are beneficial after switching to the new version of the protocol. However,
the recipients of the site should also be taken into account. Depending on the
browser used or the available internet connection, the performance result may
be different, as shown by many examples of specific visit scenarios.
For the concatenation technique, the only scenario convincing one to stick to
it was the DSL scenario using the Firefox browser. In all other cases, the results
were worse compared to the version without using the technique.
In the resource inlining scenarios using the 3G network proved to be benefi-
cial. In the case of DSL networks, the use of the Google Chrome browser in the
desktop version showed better results when using the alternative technique for
resource inlining, i.e. server push.
156 M. Druzgala and Z. Nowak

The domain sharding technique proved to be useful only for a 3G user profile
using the Google Chrome browser. Any other scenario indicated resignation from
the technique as a beneficial step to increase efficiency.
The minification confirmed its “evergreen solution” title. The use of the tech-
nique did not lose its meaning after changing the protocol version to HTTP/2.
To sum up, when planning changes to the site design motivated by the use
of the new version of the HTTP protocol, it is necessary to consider the nature
of the site and who its recipient is, as it can have a significant impact on the
final decision.
In the course of designing the simulation environment, the adoption of find-
ings regarding the method of measuring size, the characteristics of visits, the
interpretation of data, a number of aspects were found that can be subjected to
improvements or changes. After their application, it shall be possible to conduct
even more valuable substantive research and to draw new conclusions from them.
One of the aspects is to move the server environment to the cloud to examine
real conditions. It would be necessary to conduct a larger number of measure-
ments in the longer term, due to the fluctuations associated with the real network
environment.
Another aspect is to examine a greater number of classic techniques that
reveal their properties and benefits only in real network conditions.
The final suggestion for further work would be to further broaden the sce-
narios with new client profiles (browsers, devices) as well as network profiles (for
example 4G, LTE and the like).

References
1. Grigorik, I.: High Performance Browser Networking. What Every Web Devel-
oper Should Know About Networking and Web Performance. O’Reilly Media,
Sebastopol (2013)
2. Grigorik, I.: HTTP/2: A New Excerpt from High Performance Browser Networking.
O’Reilly Media, Sebastopol (2015)
3. Liu, Y., Liu, X., Huang, G.: Can HTTP/2 really help web performance on smart-
phones? In: 2016 IEEE International Conference on Services Computing (2016)
4. Corbel, R., Stephan, E., Omnes, N.: HTTP/1.1 pipelining vs HTTP2 in-the-clear:
performance comparison. In: 3th International Conference on New Technologies
for Distributed Systems (2016)
5. de Saxcé, H., Oprescu, I., Chen, Y.: Is HTTP/2 Really Faster Than HTTP/1.1?
In: 18th IEEE Global Internet Symposium (2015)
6. Varvello, M., Schomp, K., Naylor, D., Blackburn, J., Finamore, A., Papagiannaki,
K.: Is the Web HTTP/2 Yet? In: 17th International Conference Of Passive and
Active Measurement, PAM 2016 (2016)
7. Zarifis, K., Holland, M., Jain, M., Katz-Bassett, E., Govindan, R.: Modeling
HTTP/2 speed from HTTP/1 traces. In: 17th International Conferenceof Passive
and Active Measurement, PAM 2016 (2016)
 Performance Evaluation of Web Sites Using HTTP/1.1 and HTTP/2 157

8. Stepniak,
 W., Nowak, Z.: Performance analysis of SPA web systems. In: Borzemski,
L., Grzech, A., Światek,
 J., Wilimowska, Z. (eds.) Information Systems Architec-
ture and Technology: Proceedings of 37th International Conference on Information
Systems Architecture and Technology – ISAT 2016 – Part I. AISC, vol. 521, pp.
235–247. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-46583-8 19
9. Rosen, S., Han, B., Hao, S., Morley Mao, Z., Qian, F.: Push or request: an inves-
tigation of HTTP/2 server push for improving mobile performance. In: The 26th
International Conference (2017)
10. Kim, H., Lee, J., Park, I., Kim, H., Yi, D., Hur, T.: The upcoming new stan-
dard HTTP/2 and its impact on multi-domain websites. In: Asia-Pacific Network
Operations and Management Symposium (2015)
11. Seemakhupt, K., Piromsopa, K.: When should we use HTTP2 multiplexed stream?
In: 13th International Joint Conference on Computer Science and Software Engi-
neering (2016)
12. Prokopiuk, J., Nowak, Z.: The influence of HTTP/2 on user-perceived Web appli-
cation performance. Studia informatica, vol. 38, no. 3(132). Silesian University of
Technology Press, Gliwice (2017)
13. Souders, S.: High Performance Web Sites. Essential Knowledge for Front-End Engi-
neers. O’Reilly Media, Sebastopol (2007)
14. Ndegwa, A.: What is Page Load Time? MaxCDN One (2016). https://www.
maxcdn.com/one/visual-glossary/page-load-time/
15. Dutton, S.: Measuring page load speed with navigation timing, blog HTML5 rocks
(2011). https://www.html5rocks.com/en/tutorials/webperformance/basics/
16. Grigorik, I.: Measuring network performance with resource timing API, blog
Google developers (2013). https://developers.googleblog.com/2013/12/measuring-
network-performance-with.html
17. Trosien, O.: HTTP2 w/ Spring Boot+Jetty. GitHub (2017). https://github.com/
otrosien/demo-http2
18. Rizzo, L.: The Dummynet Project. University of Pisa (2015). http://info.iet.unipi.
it/∼luigi/dummynet/
Teleinformatics and
Telecommunications
 Modified OMP Algorithm
for Compressible Channel Impulse
Response Estimation

Grzegorz Dziwoki(B) , Marcin Kucharczyk, and Jacek Izydorczyk

Institute of Electronics, Silesian University of Technology, Gliwice, Poland

{grzegorz.dziwoki,marcin.kucharczyk,jacek.izydorczyk}@polsl.pl

Abstract. Wireless communication link at the physical layer can be

described as a signal transmission over multiple propagation paths which
are different in the gain and the delay. But in reality there are only a
few significant paths responsible for the most signal energy transmission
between transmitter and receiver. Such a sparse nature of the propaga-
tion environment promotes the use of the compressed sensing methods
for channel impulse response estimation in the receiver. Unfortunately,
a typical band-limited transmission violates the strict channel sparsity
making the impulse response reconstruction more complex. The paper
presents an analysis of channel impulse response estimation with the
Orthogonal Matching Pursuit algorithm. A modification of the classical
OMP method is proposed in order to improve both the channel estima-
tion and the data transmission qualities in case of a weak condition of
the impulse response sparsity. This proposition is numerically evaluated
for the general case of the OFDM transmission over a sixth path urban
channel model. The results are compared to the ones obtained for the
strict sparse impulse response instance.

Keywords: Channel estimation · Compressible impulse response

Compressive Sensing · Greedy methods · Orthogonal Matching Pursuit

1 Introduction
Wireless propagation channel consists of paths that carry signals from transmit-
ter to receiver. Many experimental measurements of the wireless channels show
that the vast majority of signal energy is delivered to the receiver only over a
few isolated propagation paths, which are usually distant from each other in
time [1,2]. This phenomenon can manifest afterwards in the recovered Chan-
nel Impulse Response (CIR) as a sparsity feature. The wider spectrum band-
width of the transmitted signals, the more sparse pattern of the channel impulse
response can be detected in the receiver. In case of the strict sparsity (a frequent
assumption in many simulation analysis [3–6]) only several CIR taps are con-
sidered nonzero, making the Compressive Sensing (CS) processing effective in
their estimation. For example, the greedy methods, such as Orthogonal Matching
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 161–170, 2018.
https://doi.org/10.1007/978-3-319-92459-5_13
162 G. Dziwoki et al.

Pursuit (OMP) [7] and Compressive Sampling Matching Pursuit (CoSaMP) [8]
(both methods with their many modifications), are the popular CS algorithms
that implementation is analyzed in many applications [9]. They work iteratively,
making selection of a single impulse response element (or more in case of the
CoSaMP) in each iteration step. Next, within the same iteration, the selected
impulse response time index is merged with the ones found previously and all
the taps amplitude that correspond to them are estimated by the Least Square
(LS) algorithm simultaneously.
The above assumption about the strict CIR sparsity is quite uncertain in
reality. A band-limited transmission due to the use of electronic filters in the
transceivers, and some synchronization issues disperse the transmitted energy
across the almost all taps of the impulse response. Consequently, many medium-
and low-amplitude elements beside a few main ones appear in CIR. Such a signal
structure, which represents the impulse response, is called compressible according
to the compressed sensing terminology [10].
The channel compressibility reduces efficiency of the classic CS methods.
The positions of nonzero elements, especially those with low amplitude can be
incorrectly determined due to the noise presence and the insufficient number of
measurement samples. Additionally, including a poor effect of the noise averaging
on the CIR amplitude estimation, a final quality of the channel reconstruction
may decrease.
The paper proposes a modification of the OMP method in case of compress-
ible CIR reconstruction. The COST-207 TU6 channel model [1] was picked as
a test environment in the simulation analysis. Channel estimation performance
was evaluated in terms of Minimum Square Error (MSE), whereas transmission
quality as Bit Error Rate (BER). The results obtained by the proposed solution
were compared with the ones by other methods based on the OMP. Efficiency of
the proposed modification in case of strict impulse response sparsity was tested
as well.
The reminder of this paper is organized as follows. A comparison between
sparse and compressible channel impulse responses with an explanation of the
source of the compressibility is presented in Sect. 2. Section 3 depicts the CS
processing with OMP method in relation to channel identification problem with
a description of the proposed modification. Section 4 presents a simulation envi-
ronment and the performance analysis of the proposed solution.

2 Sparse Channel vs Compressible Channel

Transmitter and receiver filters, including respectively, ones, transform a sparse

propagation environment into a continuous-time channel impulse response. The
resultant CIR of the transmission link can be described in baseband as:

L
h(t) = al g(t − τl ) (1)
l=1
 Modied OMP Algorithm for Compressible Channel 163

Fig. 1. Sparse channel impulse response (a) vs. compressible channel impulse
response (b)

where a complex function g(t) represents the joint impulse response of the trans-
mitter and receiver linear processing blocks and al denotes complex gain of the
lth propagation path that is delayed by time τl . L is the total number of the
resolvable paths. Because the receiver samples incoming signal with period TS ,
it is more convenient for processing purposes to present the CIR in discrete-time
domain (hk = h(kTS )) using a vector notation:

h = [h0 , h1 , . . . , hk , . . . , hK−1 ]T (2)

where k is a discrete-time index and K corresponds to the maximum delay spread

Δmax = KTS of the channel impulse response.
If all the path delays τl are consistent with the sampling period i.e. τl = kTS
and g(t) is a Nyquist filter, then h can be kept exactly as sparse as the propaga-
tion environment provided that appropriate time synchronization is maintained.
But real-life situations are more complex and there are usually much more non-
zero elements (often even all of them) in h due to a cumulative influence of the
synchronization issues and the path delays combination. Consequently, the high
amplitude elements of h form clusters at the positions related to delays which
are in the close vicinity to the delays attributed to the actual propagation paths.
On the other hand, due to time domain shape of g(t), the amplitudes within the
clusters tend to decrease as the time span from the actual propagation delays
increases. An example of compressible CIR for a sparse propagation environment
is depicted in Fig. 1b. The sparse counterpart is presented in Fig. 1a.

3 CIR Identification Using the OMP Nethod

3.1 The Classic Approach

Consider a discrete-time baseband transmission system that is described with

matrix notation. A M × 1 complex measurement vector z ∈ CM contains signal
164 G. Dziwoki et al.

samples of the transmission channel output collected within a single acquisi-

tion period (e.g. a training period). It is linearly related to the channel impulse
response h ∈ CK via convolution operation:

z = X h + v, (3)

where X is a M × K complex Toeplitz measurement matrix and v denotes a

complex vector with samples of the system noise. The elements xm,k of the
measurement matrix X come from a randomly generated training signal with
good autocorrelation property. The training signal is known at the receiver.
According to the sparsity property, the channel impulse response h is an
unknown S-sparse vector i.e. no more than S of its components have nonzero
values. The OMP method (like any other CS algorithm) uses sparsity to detect
nonzero path amplitudes in the channel impulse response. It is essential, because
if M < K than the system of linear equations:

z = X ĥ, (4)

is underdetermined, so the estimator ĥ of the channel impulse response cannot

be directly determined using the LS estimation method [11]. A solution is to
go through successive iterations of the CS procedure. In a single iteration loop,
the OMP algorithm finds approximation of one of the current path delays using
following maximization:
H
l= arg max ε(j) X . (5)
l∈{0,1...,K−1}

where j is the iteration number and ε(j) is the residual error in the j-th iteration
that is updated according to the formula:
(j)
ε(j) = z − X ĥ . (6)

In every iteration loop the effective size of X is only M × j with M > j because
(j)
K −j elements in the ĥ are zero. In that case the Moore-Penrose pseudoinverse
of X(M ×j) can be determined and the LS estimation of channel impulse response
is:
(j) −1 H
ĥ(j×1) = (X(M
H
×j) X(M ×j) ) X(M ×j) z (7)
(j) (j)
where ĥ(j×1) is a concise representation of ĥ , i.e. only nonzero values of the
estimated channel impulse response are represented in the vector.
The OMP procedure stops after predefined number of iterations (if the spar-
sity S is known) or when a stopping condition is met. The value of ĥ in the
last iteration is the valid estimate of the channel impulse response, which can
be used for further signal processing in the receiver. Detailed description of the
OMP processing steps can be found in [7].
 Modied OMP Algorithm for Compressible Channel 165

Compressed sensing theory establishes a suggested minimum amount M of

measurement samples z that are required if high probability of sparse signal esti-
mation is expected. This value is proportionally related to the following expres-
sion:
M ∝ S ln K. (8)
If M increases then the higher precision of the paths delay approximation and
noise suppression are obtained reducing the MSE error, which is defined as fol-
lows:
MSE = ||ĥ − h||22 . (9)

3.2 A Modification for Compressible CIR

The noise v enhances ambiguity of the channel reconstruction by the OMP.
Among all the impulse response taps, those of them with low amplitudes, in
particular, are the most prone to estimation errors. In many cases the OMP
algorithm can not assign their correct time index positions due to a masking
effect of the channel noise. Consequently, contrary to the expectations, the cur-
rent MSE value can rather grow than go down. To minimize the probability of
the incorrect CIR estimation, a two-threshold stopping criterion was proposed
in [12,13]. It measures energies of the residual error ε and of the difference
between successive ones, and compares them to a predefined thresholds. When
the residual error ε does not change significantly through the consecutive itera-
tions due to incorrect tap identification, the OMP procedure can be interrupted.
This stopping moment can be described mathematically as follows:

⎧
⎨ j > Smax , any  ε(j) 22 ,  ε(j) − ε(j−1) 22
STOP if  ε  < aM σ ,
(j) 2 2
any  ε(j) − ε(j−1) 22 (10)
⎩ (j) 2 (j−1) 2
ε −ε 2 < bσ , aM σ 2 ≤ ε(j) 22 < caM σ 2
2

where a, b and c are some scaling factors which should be chosen according to
specific conditions of the recovered channel, j is the current iteration step and
σ 2 is noise power.
The above-mentioned control mechanism works fine for sparse channels (sig-
nals) [13]. But in case of compressible ones, there is a danger that the iterative
procedure can stop too early (see a discussion of the simulation results for details
in the next section) before some crucial taps with medium and low amplitude
are recovered. They are necessary for preserving transmission quality. Their posi-
tions are clearly indicated by the channel compressibility pattern which is related
to g(t). Unfortunately, the classic OMP procedure does not use this knowledge
to control how to select the time index of the next element in the recovered
channel impulse response.
The aim of the paper is to propose a solution that improves quality of CIR
reconstruction by using the compressibility pattern as an additional guideline
to control the OMP algorithm. No information about the shape of g(t) is pro-
vided. The proposed modification combines the two-threshold stopping criterion
166 G. Dziwoki et al.

Fig. 2. Step-by-step reconstruction by the modified OMP with l = 1

approach with a block CS processing idea [14]. Two phases can be distinguished
in it. Initially after the start of the estimation procedure, the consecutive CIR
elements are recovered according to the classic OMP. This coarse recovery stage
is valid until the energy of the residual error falls below the predefined threshold.
When the condition ||ε(j) ||22 < caM σ 2 is met, the fine stage of reconstruction
begins. From that moment, new elements of the reconstructed impulse response
are selected in each next iteration step using an additional selection rule besides
the classical one. The OMP algorithm stops ultimately when ||ε(j) ||22 < aM σ 2
or ||ε(j) − ε(j−1) ||22 < bσ 2 .
The detailed description of the iteration step in the fine stage is as follows:

– find a new time index of the CIR element according to Eq. (5);
– supplement the set of the time indices that have been already found in the
current