DIGINET-PS

DIGINET-PS

LTE SDN access to APs
- NFV?
- AP 4: infrastructure.
- cisco dms, vorhabenbeschreibung, ap übersicht_zeitplan
  - Sahin wants new antrag.
- AP: arbeit, hardware, risiko
  - about car communication, ITS 5G,
  - tactile
  - –> write inputs
    - 14PM Nemo
DIGINET Meeting 03/02/17
APs relationship
- AP 1: coordination
- AP 2: sys analysis
- AP 3.1: Access, network, transport: sensor data related? in car system.
  - 3.2 - data integration, analysis
  - 3.3 - application
  - 4.1: Access, network, transport –> Transportnetwork (TU network?)
  - 4.2: Data integration, data analysis –> Datacenter
  - 4.3: –> road Sensor partners
  - AP 4.4: Cisco Management CDP AP (smart city sensor management), avoid CDP as product.
  - AP 5: sicherheit Cisco + DAI
  - AP 5: security im auto
  - AP 6: Open reference architecture, 3rd application integration. Alle.
    - UAP 6.1 -
    - …
    - UAP 6.5
  - AP 7: tüv prüfrichtlinien
  - AP 8: Dissemination EMO
  - 15. final deadline.
  - 1st deadline Freitag
  - check quality next week
  - AP aufwand includes –> (teil-projekt TP)
  - Unter AP
    - 6 PM tasks –> APs
  - APs beschreibungen müssen flüßig (technisch + concept, buzzwords,..) Axel
  3.1 Network input
  
  Question:
We have to do in car part? suppose yes
Other partners do sensor data analysis, application integration –

> in car (network/PC platform) infrastructure should support this

Inputs

This UAP (3.1) focuses on access technologies in mobile vehicle, which is a counter part to network and data analysis platforms of city infrastructure. In-car mobile computing platform must support seamless integration vehicular technologies and applications with city infrastructure, creating a harmonized traffic system. In which, enabling mobile data communication specifically designed for innovative vehicular applications plays an important role.

AP (Task) 3.1.1 - Carpc gateway with a fancy name - vehicular technologies integration point

support sensor network provided by other patners
support integration of application provided by other partners
support vehicle data communication
AP (Task) 3.1.2 - Realization of Adaptive flow-based network with delegated control

DC is a promising data flow control mechanism, whose characteristics directly address network requirements for hyper dynamic environment created by autonomous driving: i) constant low latency data flow in spite of , ii) intermittent connectivity, iii) heterogeneous wireless technologies, e.g., DSRC, WiFi, Broadband, iv) heterogeneous on-demand QoS classes. DC enables autonomic forward control with global network context, where there is absence of connectivity with centralized controller. Intelligent real-time decision making is pre-computed and embedded in forwarding protocols, which still allows essential data flows among mobile vehicles in case infrastructure network connectivity becomes unstable. Such unreliability in infrastructure networks is caused by their designs, leading to quick decrease in QoS in peek demand, e.g., high latency, congestion, retransmision, computing demand during emergency situations. Given high dynamic requirement of mobile vehicles, small increase in delay may has great impact on their computing platform, which can be self-healed with DC.

AP (Task) 3.1.3 - Enabling flow based packet switching with heterogeneous wireless technologies

To enable DC in vehicular platform, flow based packet switching capability is required for dynamic control of flow through heterogeneous wireless interfaces, i.e., DSRC, WiFi, LTE. Unfortunately, current flow based switches only support transport networks, which operate mainly on wired technology. In this AP OpenFlow protocol and its implementation OpenVSwitch are extended to enable handling of wireless packets. Additionally, the switch is extended to support the envisioned DC paradigm.

Table of Contents

DIGINET-PS

DIGINET Meeting 03/02/17

3.1 Network input

CarPC Hardware

NVIDIA DRIVE PX 2 AI Computing Platform