====== Other watch ======
===== Pipeline =====
* SoTA technologies: AWS DevOps Python
* soyba.org, suckhoetoandan.com, mangyba.com, theodoisuckhoe.net, ybacanhan.com
====== Publications ======
* http://localhost/~dang/wiki/doku.php?id=01_publication_watchlist
====== - TODOs ======
* Current pjs:
* 5G-MOBIX: http://localhost/~dang/wiki/doku.php?id=work_dai_labor:projects:5g_mobix:0_meetings:29190114_telco#t100429_0000
===== Watch =====
* Publication:
* 30/11 TDö Journal paper from Access/Comnet paper.
* 30/11 ISCO paper
* DOING: move DS relatedwork up
* 30/11 WONS conference
* OF extension paper,
* Service model & architecture. Contribution: models, commonsense reasoning, learning, architecture.
* DOING: reading Furbach paper.
* Dev
* NKB service API
* PhD core work: planner, QoE TOPSIS, ontology description
* AP7.2 working plan, tasks: Tacker orchestration implementation, agent
* AP7.2: ODL project, SFC, Tacker installation.
* PhD
* core work development
* commonsense reasoning, learning
* Architecture, implementation network manager.
* planner?
* SD
* Orchestrator: ONAP
* Huawei HIRP account
* user: sahin.albayrak
* password: Dai*Labor1234GT-ARC
* phone: MK 17668161075
===== - Proposals =====
==== 5G AI ====
* https://www.bmbf.de/foerderungen/bekanntmachung-2022.html
* Deadline 20th Jan.
*
===== - GT-ARC activities =====
==== ISCO ====
* Wrapup
* ccn-lite + java tunnel: Cem's student
* icn cache allocation
* final report
* demo
* GUI
* Planner
* **ISCO paper - till 21/08**
* improve arche section
* extend, component figure, ISCO concepts (proposal, deliverable)
* ISCO new proposal
* network orchestration, fog+cloud (TD)
* agent cloud (TD/CK)
* Smart contract / trust- reliability (TD)
* ICN (TD)
* /home/dang/data/mydirectory/mywork/dailabor/00--current/00_dai_pjs_actual/01_acquisition/02_abductive_reasoning
==== CHARIOT ====
* Present ICN cache concept/algorithm 12/september
* Update task
==== JiAC ====
* Research: AOSE, Cognition, Planning, Reinforcement learning, coordination (self-*), optimization, human-Agent- robot interaction
* Application: transport, I40, smart living, smart energy, civil safety, autonomous network
*
===== - 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
===== - TODOs =====
==== Procurement ====
* Dimention Data BOM
* Cisco transport
* Our Transport
* Netgear OVS Router
==== Deployment Plan ====
* RSU + Building: https://binged.it/2eSVrsm
* RSU Only:
* Sensors + Building + RSU: https://binged.it/2eTOZ4h
* RSU + Sensors: https://binged.it/2eTUAaV
==== RSU Deployment ====
* MK and Doruk
* 1) A-H 4th floor where current smart city sensor was deployed
* Contact building admin for permission
* Contract SSM
* Contact TU-Bit Network + Power Installation
* Identify place inside the building for router, etc
* not dependent on casing
* 2) TC-6th floor (optional)
* Contract SSM, survey deployment option (replace the windows)
* note: a term for minor/additional deployment (sonsors) after RSU was deployed.
* not dependent on casing
* 2*) H4001
* Contact SSM for deployment details
* 3) VWS guilding
* 4th 6th floor has some deployments by SSM
* TU-Bit has no info.
* Microware Siklu 600T?
* March Str 4th floor (corridor)
* Survey with Tubit SSM Building
* BHN (Optional)
* Survey this site
===== - Events =====
==== - Tentative deployment position discusison ====
* Candidate RSU
* HHI or MAR
* TEL or A-F
* H4001 is preferred over H roof and TC
* V-WS
* 5 RSUs up to BB-Tor
* Other less favourable
* A- high building bocks signal to the north
* Sensors
* KiWi (Traffic camera)
* TC
* MA
* H-roof
* H4001
* 8 around siegessaule
* 2 at BB-Tor
* CleverCiti (Parking camera)
* TC
* H-Roof
* H4001
* 2x upto siegessaule (co-located with RSU)
* Luft
* Will propose location, close to the street
* Weather
* Available lamppole before A-high building
* 1x colocated with RSU at Siegessaule
* 1x colocated with RSU at BB-Tor
* Environment (Erika)
* 1st floor TC-building
* lamppole infront of C building
* EB-right
* 1 colocated with RSU btw S-bahn and siegessaule
* Need distance between sensors? difficult, they need calibration.
* Need comfirmation
==== - Fluidmesh call 24-07-2017 ====
* MK shortly covered TUB Site survey
* Need Fluidmesh inputs for deployment beyond Charlottenburg Gate
* Fluidmesh:
* Wi-Fi, MPLS, 0.3 sec latency/ node
* High gain antenna, 4km?
* Back2back hop-2-hop using fluidmesh radios (2x per RSU), 500 Mbps
* Requirement:
* Fokus latency? no strong requirement e.g., 10ms, 200Mbps
* Fluidmesh ask for RSU locations & LoS to provide recommendation.
*
==== - Davra call after TF meeting ====
* Davra:
* Open to support various sensors, quick adaptation of any protocols
* May be to integrate sensors partners that are not compatible/ certified by Cisco
* Management & Fog seem to depend on Cisco IOX
*
==== - TF meeting 18/07/2017 ====
Cisco:
* Cisco bestellung
* RSU?
* DAI bestellt an Cisco
* Cisco introduces Davra (scripting management for rsu devices)
* Cisco needs contact with sensors provider for integration with CDP (nicht sensor partners)
* Fokus / FZG TF
* Test RSU + Vehicle bei Fokus
* 21/07 Testdrive?
* Vehicle architecture
* Fokus fzg, DCAIT fzg, DAI n/a
* Possible upgrade LIDAR sensor
* DAI fzg: Martin, Anon
* Bus model: Merc, passat VW (must translate CAN Matrix protocol)
* LSA prototype
* with RSU
* RSU test (MK4)
* By Fokus ~500m coverage
* Light
* concept, use-case
* SA: todo select models, how to installation (denkmalshutz, etc) until Siegessaule.
* eMO
* new video content with focus on project goals, stakeholders, use-case, not too much interviews.
* DAI (MK)
* Planning & Deployment
* Site survey building plan
* Ask Facility mgmt about reconstruction of MA / considering MA
* Type of sensors, requirements (power, ..)
* RSU physical dimension,
* Cisco takes care of RSU demo equipment.
* What interfaces supported by IR 829, datasheet
* Sensor list
* Collect data about category, types of sensor, requirements, etc
* Drive test
* Identify position of RSUs
* Input for fluidmesh solution. Cisco setups meeting with Fluidmesh for discussion.
* Monthly meeting
* MK prepare agenda, track progress
* 9th August (Oliver, Mico are absent)
==== - Ciscso procurement ====
* Process to involve Davra (call for proposal).
==== - 13-07 Davra telco ====
* Fluidmesh results from Manuel tomorrow.
*
==== - Infras DAI-Cisco ====
* Manuel meet with fluidmesh & Cisco uk for cisco mesh project updates tomorrow.
* MB consults Cisco team working with Fluidmesh.
* through put, deployment time
* connectivity with IR 829: co-location, wireless, ethernet
==== - Consortium Meeting 04-07-2017 ====
* Next meeting in 2 weeks 18-07-2017 14:00, key people from all partners
* **Fixed Deadline** for digitalize up to Charlottenburger tor:
* Sensors,
* Vehicle
* RSUs: concept & quote for devices
* Jan coordinates presentation of APs on exhibitions.
* Command & control on 15. floor
* TU-B Bauabteilung for building access
==== - Events timeline ====
* January 18: Cisco telco, Cohdar wireless RSU
* April 24: Diginet Kickoff
* April 27: Cisco telco: Back-haul options, Cisco's WiFi Mesh
* 17 May 2017: Infrastructure TF: Back-haul data communication requirement and solutions (LTE)
* May: Contact Nokia
==== - Kickoff Meeting ====
* in 4 weeks, HW, SW task force requirement specs for e.g., fahrzeuge, ..
==== - Infrastructure Requirement ====
* Use-case, Command, control in backend requires all data
* Latency requirement for each use-case, sensor
* Car2car
* DCAITI, Davra, looks for car positioning latency requirements (100ms)
* Martin cross-road use-case not clear --> DSRC ( 100m range), RSU-RSU locally at certain location, need to be in C&C backend?
* Sensor communication
* Video: in car, road side
* Parking
* Lightning
* Environment
* Mgmt
* Management RSU -> Davra Ruban
==== - 07-06-2017 TF JF (?) ====
MK presentation:
* prof: frequency application will be available in 4 weeks.
* Arrange meeting with nokia, telecom for the cost discussion
* China company is pleased to provide resources
Jan K. presentation:
* prof: features / functionalities definition for software components in vehicle, infrastructure to support scrum methodology.
* prof: next friday 1st result: document, design
* what components are needed for auto driving, cost?
* prof: we can get 5. level autonomous for TU-north, south campus.
Martin Berger:
* prof: which components, cost, for each level of autonomous. Able to catch up with prof. Müller's team.
* what are SoTA implementation, components, e.g., audi+nvidia
* Identify transition to upper autonomous level, our enabling components (DIGINET PS platform: software, learning, hw...).
* Full group research, intern+extern
==== Backhaul telco ====
* Mitnutzen vorhandene infra (UWE)
* Wifi (Manuell) + ISR (MEC)
* LTE RDN (MK)
====== Chariot ======
==== Meeting 22/05/2017: Chariot use-case ====
* SA: (discussed with bmbf) focus on middleware that covers whole spectrum of devices. Developing runtime env, tools,
* different devices with communication, compute capability: sensors,
* Quality requirement for stakeholders
* CA: present chariot objectives / network layer
* SA: middleware based on JiaC + iolite++
* CA: main focus on iolite, but able to integrate ROS, etc for I4.0
* SA: how can we enhance iolite?: abstraction, e.g., integration of ros, kura under ONE (iolite) bus?
* CA: it's possible but with limitation
* SA: new SINGLE BUS (iolite++) high efficiency, flexibility to integrate all things.
* FS, SA: identify challenges
* Gr: it depending on the requirements, e.g., ROS may have direct communication.
* Gr: the focus should be on integration on data model level
* SA: IoT bus to be foundation for future works
* Gr: iolite driver is like protocol plugin, usable for smarthome and smart grid, ...
* SA: a generic approach for device integration
* CA Semantic, orchestration
* also in ISCO
* CA learning framework
* SA: pluggable learning (aaS?) engine as component to the agent that provides learning capability.
* CA API and dev tools
* SA: high expectation from bmbf
* SA: intensive discussion with the responsible people for clear result objective e.g, irml for learning (Christian Giessler),
* identify expert group: Semantic Service (Nils, Tobias Küster, ), Device abstraction (iolite),
* CA urban factory use-case
* Production scenario
* SA: prepare slides to show with prof Lukas, bmbf (Dr. Seifert?). We should not compete with others and define focus on our strength.
* SA organize meeting (with German smart factory I4.0 Hr. van der Wittenstein, urbane produktion. Will visit us on 21/07), we discuss testbed und scenario.
* FS: we try to avoid the complexity of factory with urban use-case using 3D printing.
* SA: back to high level
* **identify experts from DAI to support project as expectation is very high**.
* What are the output and quality of results.
* Device abstraction / communication layer: Gregoz + Cem + Doruk
* Gr: Check and fix focus changes in the proposal
* SA: We identify different runtime so we need unique bus (easy to argument).
* FS, CA device list
* SA: make more sense to talk with Hr. Wittenstein. We identify future testbed.
====== - ISCO Current ======
===== - Timeline =====
* **Task #15049: AP 5.1: Smart City PPP ---> 01/12/2016 - 31/08/2017**
* Task #15050: AP 5.1.1: Konzept Smart City PPP **Deliverable** Details about PPP concept
* Task #15051: AP 5.1.2: Implementierung Smart City PPP **Deliverable** Extension of JIAC Agent Communication
* Task #15052: AP 5.2: Verzeichnisdienst ---> 01/12/2016 - 28/02/2018
* Task #15053: AP 5.2.1: Konzept Verzeichnisdienst **Deliverable** Details about concept
* Task #15054: AP 5.2.2: Implementierung Verzeichnisdienst **Deliverable** Implementation
* **Task #14509: AP 7.2: Policy Description Engine ---> 01/12/2016 - 31/08/2017**
* Task #15015: Literature Review In Progress **Deliverable** Details about policy based network managment.
* Task #15016: Create a policy editor interface
* Task #15017: Design and implement policy translator (mapper)
* Task #15067: Literature research on related architectures
* Task #15068: Literature research on methods and approaches of service ...
==== - Status ====
* Slow start AP 5.1, 5.2
* High level concept done
* TODO: detailed architecture as guideline for implementation
* AP 7.1
* Finalizing policy based network management survey, combined with team's work on autonomous network management research.
* TODO: detailed architecture as guideline for implementation
===== - WP5: =====
* ontology vs knowledge graph vs search
* https://www.quora.com/How-can-I-convert-an-ontology-into-knowledge-graph#
* https://www.opensemanticsearch.org/connector/rdf
* https://www.quora.com/How-do-you-build-and-maintain-a-knowledge-graph
*
==== - Done ====
* Discuss AP5.1 plan with team & sent to ACT
* AP5.1 Meeting - **21th Mar**
* Sent mail asking ACT about AP5.1
===== WP8 =====
* Gradle vs Maven: https://gradle.org/maven-vs-gradle
* Migration: https://guides.gradle.org/migrating-from-maven/
* to be or not: http://softwareyoga.com/10-reasons-why-we-chose-maven-over-gradle/
* However, due to the lack of standard project structure, lifecycle and plugin execution binding, I really consider Gradle as a regression compared to Maven: it’s more an Ant-like for my point of view, and we all know that an Ant build file is barely unmaintainable within a team (and even when you’re alone on your project it could be very difficult).
* https://www.reddit.com/r/java/comments/5eoxxp/gradle_vs_maven_current_thoughts/
===== WP7: =====
* Deliverable 7.1 is complete
* IoT gateway -Kura into RaspberryPI the next task
* 7.3 --> Resource Allocation and Mobility --> making the scenario more concrete
* Discussions on Simulation Tool / Network Tool howTo / whatTo simulate
* TODO: We need to check the Surveillance App promises in the Use-Case document !!!
==== 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: ====
* finalized Policy architecture - **next week 20th Mar**
* GUI, SLA / Policy translation, Policy Enforcement - Policy Editor - ODL communication, Policy Description Language (PDL): check the semantics that describe policy & literature review, Policy Information Base (PIB)
* Found survey paper and some related / guiding paper. Idea seem to be complete.
Others:
* ?? large scale service planning
* dynamic composition of web services using efficient planner in large-sclae service repository.
* ?? Cisco IoT:
* meraki router support detect users mobility???
* persistence, hadoop as data engine: device engine, data -> data model -> data engine
===== ISCO progress 29 June =====
* Apply IoLite software development framework
* Assign key person for device abstraction task in RE, learn from IoLite bus
* Adapt IoLite bus concept to create Chariot specific RE.
* For GT-ARC / DAI-Lab software development approach.
* 21 July Wittenstein visits us then we visit them in Stutgart
* September GT-ARC steering committee all project status meeting: coda, isco, chariot
===== MA Sudarson =====
* https://www.reddit.com/r/userexperience/comments/3z9v95/help_with_generating_a_thesis_topic_for_uxui/
* https://brage.bibsys.no/xmlui/handle/11250/253319
* https://wwwmatthes.in.tum.de/pages/10mvmvv60zxxk/Master-s-Thesis-Sebastian-Froehlich
* http://ki.se/sites/default/files/developing_juan_feng.pdf
* http://www.ssw.uni-linz.ac.at/Teaching/Lectures/DiplSem/GuidelinesThesis.html
* http://www.aot.tu-berlin.de/index.php?id=813&dID=287
* https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=60&ved=0ahUKEwijvomXvsTTAhXGBBoKHaMPBGU4MhAWCFowCQ&url=http%3A%2F%2Fmunin.uit.no%2Fbitstream%2Fhandle%2F10037%2F7719%2Fthesis.pdf%3Fsequence%3D2&usg=AFQjCNG6k6zr-Hw6nNkfmsMDhF3VCuIebg&sig2=bk3OA6hWmEL6mVWBrqAbIg&cad=rja
*
===== Workflow =====
* Assign Adnan to study SSM, VSDT: Cem's documents.
===== Intern tasks =====
* Monitoring and control app:
* Simulation tools: map visualize services, create services
* network tools: ?
* monitoring tools:
* Surveillance app
===== Important =====
* Usecase slide 6: Planner will need current sensor data for the planning. Current design will require transfer of sensor data to Planner. This will be broken down to monitoring from sensor to Agent and reporting interface from Agent to Planner component.
===== ISCO Done =====
==== AP products ====
* 2 APs one out-door - Next week
* Put link, offer on wiki
* Meraki detect people
* http://www.edge-core.com/solution-inquiry.php?cls=5&id=8
*
* Finalizing HW
* list of item to buy, preferred amazon, reichelt
* Finish zwischenbericht
==== Related ====
* Related development
* http://www.zeetta.com/netos/
====== - Research ======
===== - reading =====
* http://ieeexplore.ieee.org/document/7469866/
* http://www.sciencedirect.com/science/article/pii/S1084804517300644
* http://www.sciencedirect.com/science/article/pii/S1084804517301431
* http://www.sciencedirect.com/science/article/pii/S1084804517301261
* http://www.sciencedirect.com/science/article/pii/S1084804517301509
===== - Paper ideas =====
==== - 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]
* extension of OF for 3GPP and PIF for implementation
**Related:**
* extension of OF for WSN: T. Luo, H.-P. Tan, and T. Q. S. Quek, ‘‘Sensor OpenFlow: Enabling software-defined wireless sensor networks,’’ Commun. Lett., vol. 16, no. 11, pp. 1896–1899, Nov. 2012
==== - Policy ====
* Ontology policy + planning
* QoS mapping with TOPSIS
* Learning / heuristics
* tacker
==== - 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**
===== - Survey of survey paper =====
* create new paper from iMoveFAN up to section 3
* What to extend the survey with? Meet MK, CA on 9 Mar
Outline:
* Introduction (Tutorial style, giving background)
* SDN
* NFV
* ETSI architecture
* Autonomous NM in context of SDN, NFV
* Mention Agent in modified ETSI NFV Arche
* Survey
* Generate similar taxonomy like SDN for NFV and Autonomous SDN,NFV
*
* Challenges (section3 sdnized wireless netwokr)
* update with challenges for SDN, NFV, Autonomous
* Proposal
TODOs
* search for survey on NFV
* create taxonomy
*
===== - DONE Network MM paper =====
TODO:
* **Write Ontology survey**
* Service matching
* http://www.nokia.com/en_int/news/releases/2016/12/05/nokia-cloudband-open-templating-system-enables-automation-of-virtualized-network-function-lifecycle-management
* Venues
* http://www.guide2research.com/journals/network-communication
* http://ieeexplore.ieee.org/xpl/aboutJournal.jsp?punumber=4275028 (impact 1.2)
* http://ieeexplore.ieee.org/xpl/aboutJournal.jsp?punumber=65 (impact 2.8)
* http://ieeexplore.ieee.org/xpl/aboutJournal.jsp?punumber=35 (impact 5.1)
* http://ieeexplore.ieee.org/xpl/aboutJournal.jsp?punumber=6287639 (impact 1.2) http://ieeeaccess.ieee.org/
* Feasible venues:
* http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190 http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190/homepage/special_issues.htm (ipact 0.6)
* https://mailman.stanford.edu/pipermail/openflow-discuss/attachments/20160806/756f66df/attachment-0001.pdf
* J. Strassner
==== - Old tasks ====
==== 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.
* toward autonomic network managment: researh on future (ieee tutorial survey 2009)
==== Project Evolution ====
Our approach:
* choice of right abstraction layer
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
* MAS (Tomorrow)
* Go over literature, evolution part, ?? with Doruk (after thursday or earlier)
* Discuss with Basti
Doruk
* Finish monitoring measurement (tomorrow)
* Link adaptation? (Friday)
* project: ??
Basti
* Project: focal, self-net, univerSelf, selfnet (Thursday)
Manzoor:
* projects: Socrate, semafour (thursday)
Thuy:
* ontology: (wednesday)
* projects: efipsans, auto-I (thursday)
ALL:
* Update parts in the new structures (TODOs, Refs, etc)
* Discuss next papers next Monday.
==== meeting 20 jan 2017 ====
Doruk
* Control loop
* with Denis Probabilistic model (Mürzel paper with Manzoor)
* Lead control loop section
Denis
* Lead literature sections (readability, completion).
Sebastian
* Create new section under learning adaptation to put read papers
* Learning on user mobility: http://ieeexplore.ieee.org/document/7763208/
* Lead Project evolution section
Thuy:
* Description of hierarchical layers
* Translation function concept
* Functional blocks
* Lead use-case, functional blocks...
All:
* enrich Challenges section,
* Self-x Network mgmt design goal section
* Proposed self-x
==== Task Status ====
* task: objective function - DONE route optimization MPLS, CAC - TODO: S1 HO, MME LB
* task: ontology - DONE busines layer - TODO cluster, cell, translation
* task: project evollution efipsans, auto I - NOT STARTED
===== - 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 =====
* mvn download bower
* test data deployment
====== Imovefan ======
======= ------------------------------- =======
===== IMoveFAN - acquisition =====
OpenNF
* 3GPP + NFV
* Start with POCs (Check the website of ETSI for PoCs + other sources)
* Select the best fitting ones (discusses more on NF control and management)
* Understand what is meant by the network functions in 3GPP context
* Finalize a use case for the proposal... Not done
* What we want to achieve?
* Mobility management in vEPC (NFV)
* What are the network functions?:
* From PoC: MME is a network function
* 3GPP+NFV architecture (TS 32.842): Network Element (e.g., MME) contains NFs
* Use-case: Efficient MM based on Application requirements in IoT
* Dynamic deployment with MEC: 3GPP + Pico cell
* TODO: go over SA5 group activities (SP)
* TODO: load balancing of MME in 3GPP (SP)
* TODO: look into realization of dynamically deployable pico, small-cells and MM therein by the MME in MEC
* NFV
* TODO: common issues of NFV and status update: lifcycle mgmt, configuration mgmt, fault mgmt, performance mgmt. (TD)
* superfluidity paper may have usecase & requirements for NFV (TD)
* Can we compliment the use case with what we have?
* SDN test bed / know how
* JIAC
* Agenda for Tomorrow's meeting
* Discuss the POCs
* (Pre-)Finalize the Use case for the proposal?
===== Research =====
* Network management paper:
* DFG Proposal:
* Doruk: physical layer approaches: modulation, game theory, etc.. for demand attentive stadium usecase.
* physical
* Sebastian: spliting control domain with learning algorithm
* auto network managmeent
* Network management 10 pages to put on open access.
* GT-ARC Middleware
* 3GPP contribution
* how to read 3gpp spec: https://www.quora.com/What-are-the-good-resources-to-learn-about-3G-HSPA-UMTS-LTE-and-other-related-technologies
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:
* Dr. Heitmann: workout the aspects discussed (inhalt mässig) and exchange with us to speed up the process to final Antrag.
* Prof.: We make teilplan to improve each content.
* Prof.: next Do. we send new version.
* Dr Heitmann: There must not be a deadline, just send the finished version to avoid incomplete work.
* Pro.f: we want to finish before 8. Aug.
====== 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 =====
* Stream voice instead of video --> hard to recognize by human. the eyes are faster
* disable buffer
* patent: connect AP with SDN core, compare to the LTE stack. Change to the running system.
* sw to sw: produce paper out of the idea. Change OF protocol -> extension.
* conceptual + good reason + performance
*
===== ISCO update =====
===== beyond 5G Section 5 =====
===== Headline =====
====== Industrie 4.0 ======
* Text, speech based QA System.
* Chat agent t-mobile.at tinka
* Vorschlage emotional data with dialog. but user model not avail. far away
* Data: forum, tinka chat history, FAQ --> combine with agent answers
* categorization
* ontology
Theme B Human robot interaction. Still no plan to discuss yet.
* Motion control
===== Human Robot =====
* Security gateway b/w robot and parties want to communicate with the robot
* develop showcase
* implement security box, opc-ua software stack, Ros
* Security gateway: cubie board, virtualization on that board
* option for co-operation:
* cubie board engineering
* implement Realtime linux, put opc-ua server (c++/java ROS), access control systems.
* other realtime linux
* U-bot, identify objects, matching model, operation on objects (so the robot recognize): kinex
* some usecase: reasoning property of the object: dirty,
* my idea: detect material
* ohan idea: detect human with camera
* OpenNI framework restriction can detect only full-human body. We can extend here.
* remote processing outside the robot / Cloud robotics (tactile internet: extremely low delay) --> interesting
===== ICC paper =====
* linear topology
TODO: 1
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 =====
* Main focus:
* multicast
* switch to switch coordination
* Learning and decide next BS,
* cluster of possible next BSs
* multicast to the cluster.
* cluster building based on learning
* the parameters in the learning algorithm
* how to get the parameter from SDN Network..., do we need to extend SDN?
==== Call for book chapter ====
* 5G RAN, 31st July 2015, http://www.ittoday.info/5G_Radio_Access_Network_%28RAN%29_CFP.htm
* http://wwww.ittoday.info/bookproposalform.htm
* http://www.igi-global.com/publish/call-for-papers/?dt=complete-listing
* Interesting book:
* Call for Chapters: Handbook of Research on Scholarly Communication and the Publish or Perish Pressures of Academia
*
===== IMA =====
* **zwischen bericht für jan bis juni. todo bis 26. June**
==== 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
* NFC lib and client on OpenWRT
* NFC Android app
* ibrdtn and DTN Sensor App on OpenWRT. DTN Android App
* Integration DTN, Olsrd - Theory
* Network manager + Olsrd
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
* ibr-DTN on RSU
* DTN to IP routing App
* IMA ODL controller
TODO: ICN Kommunikation + Virtual Pufferspeicher
* Setup OpenWRT RSU
* Install ICN Router as VM on Laptop / Cloud
* Script to setup data path
* ODL control usecase
(D4) Bereitstellung von Schnittstellen für die Dienstinfrastruktur SW 30.06.2015 90%?
Items done: GPS Agent übermittelt Sensor Data an IMA-Platform.
* GPS Agent on IMA platform
* Tested GPS usecase
TODO: ICN-basierte kommunikation an Platform-seite
* CCN Agent on IMA platform
* CCN Agent as Traffic data provider and sample traffic data consumer.
===== IMA-Cebit 2015 =====
* 12/03/2015 Packing.
* DTN Demo
* 1 Node User UI Handy --> installation DTN
* 1 Node is the NFC-demo handy.
* Reduce power of CarPC WiFi to avoid interference
* NFC
* Check!
===== IMA Zwischenbericht =====
* ON - Naming strategy
* DEMO - Local network communication --> DTN phone to phone to AP to web
* 1. phone to phone in ad-hoc network.
* 2. phone to AP in other network
* 3. Display data (map/web)
* django app with map
* icn cache visualization
* radius/monitoring plugin. something like that in SDN?
* using ICN data?
* Work-log: http://localhost/wiki/doku.php?id=work_dai_labor:projects:ima:ima_ws:dtn:ima_dtn&#section20141121
* DEMO - Cloud management
* Installation of network components: APs VMs
* Mobility management: using SDN? integration openstack ODL
* How IMA use the network infrastructure.
* upload data
* **Must be done:**
* Offloading upload & download
* Server app & Android app
IMA einkaufen
* 5x nfc TG
* 2x usb2serial
* 1x multi card reader
* 3x alix
DTN-CCN
* Test CCNx network
* ICN and IMA presentation.
Auctions
* put publisching areas
* adhoc inactive.
SEMA
* setup dev env: http://localhost/wiki/doku.php?id=projects:semadict:semadict_devop
==== IMA ====
* Zwischen bericht Feb. 2015
* Prices for semperlink
* Justification for server/laptop: to send Fikret & Jan
* Detailed tasks in relation with deliverables
* prepare ideas for deliverable documents
* Research topics for mobile adhoc: topic based data dissemination, routing strategies
* Research topcis for Offloading network: SDN..
Laptop - Done
* https://www.pro-com.org/de/lehreundforschung-produkte/lehreundforschung-lenovo/lehreundforschung-notebooks/lehreundforschung-thinkpad-mit-us-keyboard/produkte/lenovo/notebooks/thinkpad-mit-us-keyboard/lenovo-thinkpad-t440p-modell-20aw-s2af-us
*
====== Watchlist ======
==== Civil Sicherheit ====
http://localhost/wiki/doku.php?id=work_dai_labor:projects:zivilen_sicherheit:0_zs_initiation
===== IMA =====
{{tag>watch ima}}
[[work_dai_labor:projects:ima:pj_master_plan|PJ IMA master plan]]
[[http://localhost/wiki/doku.php?id=work_dai_labor:projects:ima:ima_ws:car_pc:carpc_working_log|Carpc working log]]
===== Thesis =====
http://localhost/wiki/doku.php?id=work_dai_labor:research:horizon_x:thesis&#topicdata_offloading_biz
===== no time for these =====
* vn owrt dev
* making one working version.
* you know at least somepeople is working on it.
* creating group with vfoss.org
===== Emobility C++ =====
* svn: https://cvs.dai-labor.de/svn/emobility/charging-station/lsd2/
===== ALC =====
* - 13. May
* test papino with file transfer: correct file transfer??
* ns3
===== Netty - NIO=====
[[programming:network_programming:java_network:netty_project:netty_watch_list|Netty watchlist]]
===== JavaEE - deltaspike=====
====== Weekend Project ======
* Maxo36: http://localhost/wiki/doku.php?id=projects:maxo36:worklog&#section20160105