Table of Contents

Other watch

Pipeline

Publications

TODOs

Watch

1. Proposals

5G AI

2. GT-ARC activities

ISCO

CHARIOT

* Present ICN cache concept/algorithm 12/september
* Update task

JiAC

3. Research

* **WIP** SDN NFV Survey: read papers 15th Mar 2017.
  * Write NFV part

DIGINET

http://localhost/~dang/wiki/doku.php?id=work_dai_labor:projects:diginet_ps

1. TODOs

Procurement

Deployment Plan

RSU Deployment

2. Events

2.1 Tentative deployment position discusison

2.2 Fluidmesh call 24-07-2017

2.3 Davra call after TF meeting

Cisco:

2.7 Infras DAI-Cisco

2.8 Consortium Meeting 04-07-2017

2.9 Events timeline

2.10 Kickoff Meeting

2.11 Infrastructure Requirement

2.12 07-06-2017 TF JF (?)

MK presentation:

Jan K. presentation:

Martin Berger:

Backhaul telco

Chariot

Meeting 22/05/2017: Chariot use-case

ISCO Current

1. Timeline

1.1 Status

2. WP5:

2.1 Done

* Discuss AP5.1 plan with team & sent to ACT * AP5.1 Meeting - 21th Mar

WP8

WP7:

AP7.1

 
* Display device data in a Kura application
* 6lowPAN Kura Integration - Doruk - Ipv6 does not work in Kura node (reload the image?)
  * MQTT over 6lowPAN / IPv6 - Cem
  * MQTT subscriber / publisher implementation
  * RestAPI - Kura integration - Cem
  * Netatmo - Kura integration - Cem
  * Image deployment - Doruk 
  * Thuy is the reviewer for all tasks in 7.1

AP7.2:

Others:

ISCO progress 29 June

MA Sudarson

Workflow

Intern tasks

Important

ISCO Done

AP products

Research

1. reading

2. Paper ideas

2.1 PIF

The software could also form part of a virtual network function (VNF) running on a server, interacting with a virtual switch running on the server's CPU or on a smart NIC in the server. The interfaces between the software and the datapath need to support the performance required by the use case, for example, high packet rates and flow update rates might be required, therefore callable interfaces must be considered to avoid the overhead associated with a protocol based interface like the existing OpenFlow. The intent is to create open and standardized interfaces to enable a broader range of software interaction with datapaths and to enable the software to be supplied by new ecosystem players. [ONF SDN Evolution]

Related:

2.2 Policy

2.3 ANM

* https://www.researchgate.net/publication/235123875_Delegation_Management

Paper idea

’policy continuum’ [97] has been intro- duced to define the possible abstraction levels of policies, including business, system, administrator, device, and instance perspectives. Ultimately the policy continuum should enable a translation of policies from business level to device level, which in a follow-up paper [98] is described as a mapping from one policy abstraction level to another with the help of a translation table. Given this approach, if an operator aims at modifying its offered services based on the methodology of translating policies, it becomes apparent that the end-to-end network management behavior implemented by the constituent policy levels of the policy continuum is hard coded into the policy framework. As a result, the use of policies for all the abstraction levels available may enable the translation of business goals into low-level device configuration. However, the resulting tight coupling of different network management aspects results in a hard-to-change and thus change-averse representation of network management features.

> Ontology implementation of the Policy Continuum model. **Done in UniverSelf project**

=

2.4 Survey of survey paper

Outline:

TODOs

3. DONE Network MM paper

TODO:

Discussion on Ontology: Thuy

Use of ontologies for network management. Different approaches, advantages and disadvantages. Discuss minimum 2-3 approaches from research literature + any work from standardization body (2-3 pages). Support your section by tables / figures / comparative analysis.

Ontology for translation of global objective function to local objective functions. On the coordinator level we are using ontologies for translating the global into local objectives. On other levels, based on level specific objective function, we use it to abstract the information.

Project Evolution

Our approach:

Global to Local Objective Function translation

technology agnostic / fitting all technologies

agent / cognitive control loop

Heterogeneous learning framework (hierarchical layers)

self-X Learning (Meta Learning)

Introduction / Focus areas / technologies / key selling points of related projects in contrast to our envisioned approach

Manzoor: socrates semafour

Thuy:

efipsans

auto I

Meeting 17 Jan

Denis

Doruk

Basti

Manzoor:

Thuy:

ALL:

meeting 20 jan 2017

Doruk

Denis

Sebastian

Thuy:

All:

Task Status

4. PhD proposal MK

Headline

Software defined networking (SDN) and Network Function Virtualization (NFV) are the emerging 5G enabling technologies. SDN decouples the control plane from data plane and concentrates the network control in a centralized entity (SDN controller), which allows more agile network configuration and policy enforcement. With SDN, 5G is aiming at achieving the required abstraction of network functionality that realizes the technology agnostic control vision. NFV on the other hand decouples the network functions from proprietary hardware and hence enables the virtualization of network functions. Although the two technologies have evolved separately, they complement each other in realizing the fitting network management system for the envisioned future mobile networks.

Major objectives of this research work will be:

i. Design and develop an integrated and unifying SDN-NFV platform – inspired by the design of 3GPP and ETSI reference architecture proposals, the thesis will workout a functional architecture of a NFV orchestrator with SDN control capabilities.
ii. Core and transport network functions tailored to different application scenarios of smart cities will be design and developed

iii. Enabling the multi-operator and multi-technologies control and orchestrator environment – Given that core is SDN enabled, within the scope of this objective, we will work with east, west, north, south interfaces between different orchestrators and controllers to implement the policies.

iv. To implant the network intelligence, we will design and develop game-theory based learning algorithms, which will be implemented by JIAC agents.

Auvegos

Done

Imovefan

IMoveFAN - acquisition

OpenNF

Research

https://www.ericsson.com/res/docs/whitepapers/wp-cloud-security.pdf

Meeting protocols

DAI: Prof. Albayrak, Dr. Fikret Sivrikaya, Dr. Marco Luetzenberger, Til Plumbaum, Xuan-Thuy Dang, Christian Glied

DLR: Dr. Heitmann, Hr. Mader, Fr. Seifert

A - Problem, Zeil, Lösung
* A1:
  * Fr. Seifert: The objective is there and rounded but should be more concentrated, and easier to capture.
  * Prof.: We will bring the outcome concrete at the beginning. Outcome of the project will be a prototype, which allows future solutions and application to base on. 
* A2: 
  * Prof.: we will details bandwidth problem and solution in next version of the proposal, in concrete domain e.g., industry 4.0
  * Hr. Mader: specify feasibility of network infrastructure, otherwise the basis for the project is weak
  * Prof.: We will detail the physical communication in a specific domain.
* A3: security
  * Prof.: We will connect data access aspect with concrete domain. 
  * Dr. Heitmann: in the skizze we should show how the solution in concrete domain is applied.
  * Prof.: According to earlier agreement about the skizze structure, we keep it generic and scenario is omitted. Also it is generic because this is vorlauf forschung project.
  * Dr. Heitmann: Although this is basis research project but we should show the concrete starting point (technologies, domain).
  * Prof.: the solution is generic but we will begin with a first domain, where the solution is applied.
  * Marco: We concrete specified what features are there for developing software application on the platform: protoocls, ..
  * Fr. Seifert: the description is too complex and over the limit of this project. We should show concrete example, what is realized in the project.
* A4: 
  * ML: Because of limited scope of the project, we only create prototype which integrates software representation.
* A5: Why multi-agent
  * Prof.: Autonomy characteristics of Agent.
  * Marco: We motivated by the complexity of IoT, that multi-agent is needed as a unique solutions. Other solutions focus on partial solution (annotation, etc). We combine all features needed by the middleware solution.
  * Hr. Mader: other solutions are short but still should be 
* B - Arbeitsplan:
  * Dr. H: all details will be provided in the next Antrag-phase.
* C1: Verwertung
  * Prof.: We want to cooperate with Turkey, organize workshops to get feedbacks and make the solution applicable in practice.
  * Fikret: Ad-hoc meetings can also take place and formally in form of workshop.
  * Hr. Mader: Cooperation of both sides is encouraged. How should that be done?
  * Dr. Heitmann: though this is independent research activity on both side, but exchanges is needed.
  * Fikret show Dr Heitmann updated number of workshops.
  * Dr. Heitmann: Verwertung is also how the resutls can be used. 
  * Prof.: We will describe 'verwertung' 1) What is the outcome the project 2) Coming application projects that based on the results.
  * Dr. H: Also details the applications in civil domain, e.g., security, privacy, surveillance. 

Conclusion:

Old

Huawei Review

2016-06-09

  1. Demonstrator * Agentda item 3 * work on slideset to support live demo: * problem, solution, roadmap, result for each delay component. * Result of all delay components * discussion / selling point * 1. Delay component, propagation: * Unknow impact of DAI network on Ctrl-sw link. solution: try with switch, compare result with one from DAI cloud. * next step: * 2. Delay component, computation at Ctrl: * define load on controller: * t: time b/w packet-in, generator ms * n packet-in type 1:10 * 1: pseudo calc path b/w 2 Hosts. * 2-10: sleep for n sec. * Generate 2 dimention graph and discuss it * 3. Delay component - flow setup delay: * Impacted by the ctrl-sw link. * roadmap: load on switch & increase network topology. * propose topology, physical sw. * Agenda item 4 * Agenda item 5

imovefan F2F

ISCO update

beyond 5G Section 5

Headline

Industrie 4.0

  • Motion control
  • Human Robot

    ICC paper

    Adapt introduction

    Proactive and learning based mobility management.

    TODO 2: Section 2 adapted, section 3 remove completely

    A new control plane…' (I already mentioned you that paper) [12:52:03 PM] Manzoor Ahmed Khan: The paper, as I see the current version, should evolve towards only explaining this learning details, its pros and cons and giving details of performance. So the text you wrote below should in extended and more elaborate form find its way to the paper. The architecture part should be removed.

    [12:52:47 PM] Manzoor Ahmed Khan: Yet, even though clear, this contribution is still small. A possible way to make things better is in my opinion this: Give motivation for learning, i.e. explain/plot/calculate/compare costs associated with fully learnt and learning. E.g. flow table size grow too large if you deploy proactive rules to all possible next hops.

    Proposal

    IPR

    Aparatus: module in AP to collect measurement and protocol to transfer measurement to controller (support realtime).

    Method:

    The patent is more valuable if its violation is easy to detect.

    No performance evaluation needed: but details of feasibility of the approach (how to get the needed data?), specific how the components exactly work, specific operation and interface.

    Details the functionality of the entities.

    Create a new system, change one module or part of the existing system (interface, …). What are the claims?. If it's a component, show specific how the component works. How the system looks.

    If the claim is a method, specific about the method. Start with one usecase, show how the method works for that usecase. Identify the logic, behavior of the system (infringement detection).

    Is that the only/ best way to realize new behavior? can it be avoided by others.

    Disruptive Call

    imovefan

    Call for book chapter

    IMA

    IMA Deliverable

    (D1) Konzept für die Einbindung verschiedener lokaler und globaler Kommunikationsmechanismen in die Gesamtlösung DOC 30.06.2015 50%? Konzept für gesamte Kommumikationssystem vorhanden. TODO: schreiben

    This document is similar to iMoveFAN architecture deliverable. Finish the deliverable soon and adapt it for IMA.

    (D2) Umsetzung der kooperativen Kommunikationsmechanismen auf den Nutzergeräten und in den fahrzeuggestützten Systemen SW 30.08.2015 100%?

    Items done: Adhoc-DTN kommunikations auf alle Geräte + NFC

    TODO: Forwarding Strategie mit NS3 Simulation

    (D3) Entwicklung von Gateways zur Unterstützung der kooperativen Datennutzung SW 30.06.2015 80%?

    Items done: Central-Steuerung von RSU + Cloud Infrastruktur

    TODO: ICN Kommunikation + Virtual Pufferspeicher

    (D4) Bereitstellung von Schnittstellen für die Dienstinfrastruktur SW 30.06.2015 90%?

    Items done: GPS Agent übermittelt Sensor Data an IMA-Platform.

    TODO: ICN-basierte kommunikation an Platform-seite

    IMA-Cebit 2015

    IMA Zwischenbericht

  • 5x nfc TG
  • 2x usb2serial
  • 1x multi card reader
  • 3x alix
  • DTN-CCN

    Auctions

    SEMA

    IMA

    Laptop - Done

    Watchlist

    Civil Sicherheit

    http://localhost/wiki/doku.php?id=work_dai_labor:projects:zivilen_sicherheit:0_zs_initiation

    IMA

    watch ima

    PJ IMA master plan

    Carpc working log

    Thesis

      http://localhost/wiki/doku.php?id=work_dai_labor:research:horizon_x:thesis&#topicdata_offloading_biz

    no time for these

    Emobility C++

    ALC

    Netty - NIO

    Netty watchlist

    JavaEE - deltaspike

    Weekend Project