DE102020206967A1

DE102020206967A1 - Computer-implementiertes Verfahren, Computerprogramm und Kommunikationseinrichtung für ein Fahrzeug

Info

Publication number: DE102020206967A1
Application number: DE102020206967.0A
Authority: DE
Inventors: Matthias Priebe
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2020-06-04
Filing date: 2020-06-04
Publication date: 2021-12-09

Abstract

Die vorliegende Erfindung bezieht sich auf ein computer-implementiertes Verfahren, ein Computerprogramm sowie auf eine Kommunikationseinrichtung für ein Fahrzeug. Das Verfahren wird durch eine Software-Zwischenschicht, die auf einem Prozessor des Fahrzeugs ausgeführt wird, durchgeführt. Das Verfahren umfasst ein Erhalten (110) von Daten zum Übermitteln an ein oder mehrere weitere Fahrzeuge. Das Verfahren umfasst ferner ein Bestimmen (120) einer Qualitätsanforderung für die Übermittlung der Daten. Das Verfahren umfasst ferner ein Auswählen (150) eines Übertragungswegs einer Mehrzahl von Übertragungswege basierend auf der Qualitätsanforderung für die Übermittlung der Daten, wobei sich die Mehrzahl von Übertragungswege bezüglich der auf dem Übertragungsweg genutzten Übertragungstechnologie oder bezüglich der auf dem Übertragungsweg genutzten Zwischenschritte unterscheiden. Das Verfahren umfasst ferner ein Weitergeben (160) der Daten an ein Sende-Empfängermodul des Fahrzeugs, das mit dem ausgewählten Übertragungsweg assoziiert ist, zum Übermitteln der Daten über den ausgewählten Übertragungsweg.

Description

Die vorliegende Erfindung bezieht sich auf ein computer-implementiertes Verfahren, ein Computerprogramm sowie auf eine Kommunikationseinrichtung für ein Fahrzeug.
Moderne Fahrzeuge verfügen mittels Connected Car Units (wörtlich: Verbundene Fahrzeuge-Einheiten, Kommunikationseinheiten zur Kommunikation eines Fahrzeugs) über vielfältige Netzzugangsmöglichkeiten. Zum einen werden Modems für die lokale Funkübertragung (etwa über ein drahtloses lokales Netzwerk nach IEEE (Institute of Electrical and Electronics Engineers Institut für Elektrotechnik und Elektronik-Ingenieure)-Standard 802.11p), zum anderen für großflächige Übertagung (durch Nutzung der zellulären Mobilfunkstandards Long Term Evolution (LTE) oder dem Standard der 5. Generation (5G)) in intelligenten Fahrzeugen verbaut. Eine Nutzung aller zur Verfügung stehenden Kommunikationstechnologien bietet signifikante Vorteile bei der Übertragung von Daten. So können höhere Datenraten durch die Bündelung der verschiedenen Übertragungsmedien erreicht, Latenzen verringert sowie die Ausfallsicherheit erhöht werden.
Um mehrere Funkübertragungswege (auch „Pfade“ genannt) gleichzeitig nutzen zu können, benötigt das Fahrzeug eine Funktionalität, das die zu übermittelenden Daten auf die unterschiedlichen Pfade verteilt und/oder entscheidet, welcher Pfad für welche Übertragung zu wählen ist. Im Allgemeinen wird diese Funktionalität von einem dafür vorgesehenen Hardware-Modul übernommen, etwa von einem sogenannten Bonding-Server (Dienstcomputer zum zusammenfassen von Pfaden). Ein solcher Ansatz ist beispielsweise in WO 2018/211488 A1 oder WO 2018/64179 A1 gezeigt.
Es besteht der Bedarf, ein verbessertes Konzept bereitzustellen, um eine Mehrwegekommunikation in einem Fahrzeug bereitzustellen.
Diesem Bedarf wird durch den Gegenstand der unabhängigen Ansprüche Rechnung getragen.
Die vorliegende Erfindung basiert auf der Erkenntnis, dass die Implementierung einer Mehrwegekommunikation über ein Hardware-Modul einerseits dazu führt, dass die Kosten für die Unterstützung der Technologie im Fahrzeug steigen. Andererseits ist solche eine Lösung inflexibel, da Änderungen an der Funktionalität der Hardware Begrenzungen unterliegen. Um diese Nachteile zu überwinden wird in Ausführungsbeispielen der vorliegenden Offenbarung die Funktionalität für die Mehrwegekommunikation von dem zentralistischen Ansatz, wie er der Hardware-Implementierung zugrunde liegt, in einen verteilten Ansatz überführt. In Ausführungsbeispielen wird die Funktionalität zur Mehrwege- (engl. Multipath- oder Multilink-) Kommunikation von einer Software-Zwischenschicht, etwa einer Software-Bibliothek, bereitgestellt, die auf Anwendungsebene mit der Anwendung verbunden ist, die über die Mehrwege-Kommunikation kommunizieren möchte. Dabei ist der Zugriff auf die Mehrwege-Kommunikation für die Anwendung transparent, diese wird von der Software-Zwischenschicht abstrahiert. Dadurch können einerseits die zuvor genannten Einschränkungen des zentralistischen Hardware-Ansatzes überwunden werden. Andererseits kann eine Mehrwege-Kommunikation bereitgestellt werden, die genauer auf die Bedürfnisse jeder Anwendung angepasst werden kann, die auf einer Ende-zu-Ende-Messung der relevanten Eigenschaften der verschiedenen Pfade basiert (wie etwa Umlaufzeit, Durchsatz oder Fehlerrate), und die flexibel auf verschiedene Geräte und Anwendungen portiert werden kann.
Ausführungsbeispiele der vorliegenden Offenbarung schaffen ein computer-implementiertes Verfahren für ein Fahrzeug. Das Verfahren wird durch eine Software-Zwischenschicht, wie etwa eine Software-Bibliothek, die auf einem Prozessor des Fahrzeugs ausgeführt wird, durchgeführt. Das Verfahren umfasst ein Erhalten von Daten zum Übermitteln an ein oder mehrere weitere Fahrzeuge. Das Verfahren umfasst ferner ein Bestimmen einer Qualitätsanforderung für die Übermittlung der Daten. Das Verfahren umfasst ferner ein Auswählen eines Übertragungswegs einer Mehrzahl von Übertragungswege basierend auf der Qualitätsanforderung für die Übermittlung der Daten. Die Mehrzahl von Übertragungswege unterscheiden sich bezüglich der auf dem Übertragungsweg genutzten Übertragungstechnologie oder bezüglich der auf dem Übertragungsweg genutzten Zwischenschritte. Das Verfahren umfasst ferner ein Weitergeben der Daten an ein Sende-Empfängermodul des Fahrzeugs, das mit dem ausgewählten Übertragungsweg assoziiert ist, zum Übermitteln der Daten über den ausgewählten Übertragungsweg. Dabei kann die Software-Zwischenschicht beispielsweise die Aufgabe eines sogenannten Schedulers (eines Planers zur Vergabe von Kommunikationsressourcen) übernehmen, der die Daten den einzelnen Übertragungswegen zuweist. Somit lässt sich eine Implementierung einer Mehrwege-Kommunikation schaffen, die die zuvor genannten Vorteile aufweist.
Beispielsweise können die Daten als Datenpaket oder Sequenz von Datenpaketen erhalten werden. Für Daten, die für das gleiche Fahrzeug bestimmt sind und der gleichen Sequenz von Datenpaketen entstammen, kann der gleiche Übertragungsweg ausgewählt werden. Hiermit kann vermieden werden, dass durch die Übertragung über verschiedene Übertragungswege Verzögerungen beim Empfänger erzeugt werden (etwa durch Neuordnung von Daten, die in der falschen Reihenfolge ankommen).
Beispielsweise kann zumindest einer der Übertragungswege auf einer Übertragung über mehrere Zwischenschritte basieren (auch engl. Multi-Hop). In anderen Worten können Daten entweder direkt, über einen zentralen Zwischenschritt (etwa über eine sogenannte Edge-Cloud, wörtliche Übersetzung „Rand-Wolke“, ein abstrahierter Server, der in der Nähe der kommunizierenden Fahrzeuge angeordnet ist, etwa in einer Mobilfunk-Basisstation) oder über mehrere Zwischenschritte (etwa im Multi-Hop-Verfahren über ein oder mehrere Fahrzeuge über direkte Fahrzeug-zu-Fahrzeug-Kommunikation) übertragen werden.
Beispielsweise kann zumindest einer der Übertragungswege auf einer Übertragung über eine Edge-Cloud basieren. Beispielsweise kann zumindest einer der Übertragungswege auf einer Übertragung über einen Internetdienst basieren. Eine Übertragung über eine Edge-Cloud oder über einen Internetdienst kann beispielsweise genutzt werden, um die direkte Fahrzeug-zu-Fahrzeug-Kommunikation zu entlasten oder wenn die direkte Fahrzeug-zu-Fahrzeug-Kommunikation nicht zur Verfügung steht. Dabei kann die Übertragung über den Internetdienst mit einer größeren Wahrscheinlichkeit zur Verfügung stehen, während die Übertragung über die Edge-Cloud eine geringere Latenz aufweist und den Vorteil hat, dass die Edge-Cloud gegebenenfalls Kenntnis darüber hat, welche anderen Fahrzeuge sich in der Umgebung befinden.
In verschiedenen Ausführungsbeispielen werden die Daten als Datenpaket oder Sequenz von Datenpaketen erhalten. Das Datenpaket oder die Sequenz von Datenpaketen kann auf dem Quick User Datagram Protocol Internet Connections-Protokoll basieren. Dieses Protokoll ermöglicht Effizienzgewinne gegenüber dem Transmission Control Protocol (TCP, Protokoll zur Übertragungssteuerung).
Beispielsweise können die Daten von ein oder mehreren Fahrzeugdiensten zur Koordination von Fahrzeugen stammen. Jedem Fahrzeugdienst kann eine Qualitätsanforderung zugewiesen sein. Die Qualitätsanforderung für die Übermittlung der Daten kann basierend auf der Qualitätsanforderung, die dem jeweiligen Fahrzeugdienst, von dem die Daten stammen, zugewiesen ist, bestimmt werden. So können die Qualitätsanforderungen für die einzelnen Fahrzeugdienste in die Mehrwegeplanung einbezogen werden.
In manchen Fällen kann das Erhalten der Daten ein Empfangen zumindest eines Teils der Daten von einem weiteren Fahrzeug umfassen. So kann das Fahrzeug beispielsweise als Relais (Weiterleitungsknoten) einer Multi-Hop-Kommunikation verwendet werden.
Dabei können die empfangenen Daten bis zu einem vordefinierten Zeitpunkt gültig sein. Die empfangenen Daten können weitergeleitet werden, falls die Daten nach dem Übermitteln der Daten über den ausgewählten Übertragungsweg voraussichtlich noch gültig sind. Damit können Übertragungen vermieden werden, die von dem Empfänger verworfen würden.
Beispielsweise kann die Software-Zwischenschicht eine Software-Bibliothek zur Nutzung in einer Kommunikationseinrichtung eines Fahrzeugs sein. Eine solche Software-Bibliothek kann beispielsweise in verschiedene Anwendungen integriert werden, die von der Kommunikationseinrichtung (oder beispielsweise einem Endgerät eines Nutzers) ausgeführt werden, und auf verschiedene Arten von Geräten portiert werden.
Zusätzlich zur Mehrwege-Kommunikation kann die Software-Bibliothek ferner einer Funktionalität zur „Gruppierung“ und „Kodierung“ von Daten bereitstellen. In der Gruppierung von Daten werden Daten, die dem gleichen Ziel bereitgestellt werden sollen und gleiche (oder ähnliche) Qualitätsanforderungen aufweisen zusammengefasst. Durch Kodierung können die gruppierten Daten nun zusammengefasst werden, so dass, beispielsweise zur Übertragung einer Mehrzahl von kleinen Dateneinheiten, lediglich ein großes Paket benötigt wird, das die kleinen Dateneinheiten umfasst. Das Verfahren kann ferner ein Gruppieren der Daten gemäß der Qualitätsanforderung und gemäß einem Ziel der Daten umfassen. Das Verfahren kann ferner ein Kodieren der Daten gemäß der Gruppierung der Daten. Daten einer Gruppe werden zusammen kodiert. Die kodierten Daten werden an das Sende-Empfängermodul des Fahrzeugs weitergegeben. Damit können beispielsweise Daten, die von dem Fahrzeug ausgehen, und Daten, die von einem anderen Fahrzeug empfangen wurden, durch Gruppierung und Kodierung kombiniert werden und zusammen übertragen werden.
Beispielsweise können die Daten basierend auf einer linearen Netzwerk-Kodierung kodiert werden. Eine solche lineare Netzwerk-Kodierung wird beispielsweise von der Internet Engineering Task-Force (IETF, Internetentwicklungs-Arbeitsgruppe) diskutiert.
Beispielsweise können die Daten so dem Sende-Empfängermodul des Fahrzeugs weitergegeben werden, dass Daten, die zusammen gruppiert und kodiert wurden, zusammen über den gleichen Übertragungsweg übermittelt werden. Auch hier kann das Ziel verfolgt werden, auf Empfängerseite Verzögerungen zu vermeiden.
Ausführungsbeispiele schaffen ferner ein Programm mit einem Programmcode zum Durchführen des Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
Ausführungsbeispiele schaffen ferner eine Kommunikationseinrichtung für ein Fahrzeug. Die Kommunikationseinrichtung umfasst eine Schnittstelle zur Kommunikation mit ein oder mehreren Sende-Empfängermodulen des Fahrzeugs. Die Kommunikationseinrichtung umfasst ein oder mehrere Prozessoren, ausgebildet zum Ausführen des Verfahrens durch Bereitstellen der Software-Zwischenschicht.
Weitere vorteilhafte Ausgestaltungen werden nachfolgend anhand der in den Zeichnungen dargestellten Ausführungsbeispiele, auf welche Ausführungsbeispiele generell jedoch nicht insgesamt beschränkt sind, näher beschrieben. Es zeigen:

1a zeigt ein Flussdiagramm eines computer-implementierten Verfahrens für ein Fahrzeug;
1b zeigt ein Blockdiagramm einer Kommunikationseinrichtung für ein Fahrzeug;
2a zeigt ein Diagramm eines allgemeinen Aufbaus eines beispielhaften Connected Car-Schedulers;
2b zeigt ein Diagramm eines Beispiels einer Zustandsmaschine eines Connected Car Schedulers;
3a zeigt ein schematisches Diagramm eines Beispiels für Connected Car Multipath Scheduling als Software-Bibliothek;
3b zeigt ein Beispiel für multikriterielles Scheduling;
3c zeigt ein schematisches Diagramm einer Nutzung einer Connected Car Multipath Bibliothek durch verschiedene Anwendungen;
3d zeigt einen schematischen Überblick einer Multipath-Architektur;
3e zeigt Details einer beispielhaften Implementierung der Multipath-Architektur;
3f zeigt Details einer beispielhaften Implementierung der Multipath-Architektur;
3g zeigt eine beispielhafte Implementierung eines QUIC-Multipath-Schedulers als Software-Bibliothek;
3h eine weitere beispielhafte Implementierung eines QUIC-Multipath-Schedulers als Software-Bibliothek;
3i zeigt ein schematisches Diagramm eines Datenflusses zwischen verschiedenen Komponenten einer Connected Car-Anwendung;
3j zeigt ein schematisches Diagramm eines beispielhaften Datenflusses zwischen einer Connected Car-Anwendung und der Connected Car Multipath-Bibliothek auf Sendeseite;
3k zeigt ein schematisches Diagramm eines beispielhaften Datenflusses zwischen einer Connected Car-Anwendung und der Connected Car Multipath-Bibliothek auf Empfangsseite;
4a zeigt ein Diagramm eines allgemeinen Aufbaus eines beispielhaften Connected Car-Bibliothek mit Unterstützung für Gruppierung und Kodierung;
4b zeigt einen beispielhaften Aufbau einer Datenübertragung über Multipath-TCP;
4c zeigt ein Flussdiagramm einer Vorgehensweise bei der Übermittlung von Daten über eine Software-Bibliothek, die Connected Car Multipath Kodierung und Gruppierung bereitstellt;
4d zeigt ein schematisches Diagramm eines Beispiels einer Datenübermittlung über eine (Edge-) Cloud und V2X;
5a zeigt ein Diagramm eines allgemeinen Aufbaus eines beispielhaften Connected Car-Schedulers mit Unterstützung für Gruppierung und Kodierung;
5b zeigt ein schematisches Diagramm eines Beispiels für Verbindungs-Aggregation, die von einer Software-Bibliothek implementiert ist;
5c zeigt ein beispielhaftes Diagramm der Nutzung einer Multipath-Zugriffs-Software-Bibliothek zum Hochladen von Dateien in vernetzten Fahrzeugen;
6a zeigt eine schematische Übersicht einer Nutzung einer Automotive (Edge-)Cloud und zellulären Netzen zur Entlastung von lokalen Fahrzeugübertragungstechnologien;
6b zeigt eine Einschränkung in der Kommunikation zwischen Fahrzeugen in einer zellularen Fahrzeugumgebung;
6c zeigt ein beispielhaftes Flussdiagramm einer Auslagerung von V2X-Kommunikation mit Hilfe einer Edge Cloud; und
6d zeigt ein Beispiel einer Software-Bibliothek mit Mehrwege-Zugriff für einen Datei-Upload in vernetzten Fahrzeugen.

Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
Bei der nachfolgenden Beschreibung der beigefügten Figuren, die lediglich einige exemplarische Ausführungsbeispiele zeigen, können gleiche Bezugszeichen gleiche oder vergleichbare Komponenten bezeichnen. Ferner können zusammenfassende Bezugszeichen für Komponenten und Objekte verwendet werden, die mehrfach in einem Ausführungsbeispiel oder in einer Zeichnung auftreten, jedoch hinsichtlich eines oder mehrerer Merkmale gemeinsam beschrieben werden. Komponenten oder Objekte, die mit gleichen oder zusammenfassenden Bezugszeichen beschrieben werden, können hinsichtlich einzelner, mehrerer oder aller Merkmale, beispielsweise ihrer Dimensionierungen, gleich, jedoch gegebenenfalls auch unterschiedlich ausgeführt sein, sofern sich aus der Beschreibung nicht etwas anderes explizit oder implizit ergibt.
Obwohl Ausführungsbeispiele auf verschiedene Weise modifiziert und abgeändert werden können, sind Ausführungsbeispiele in den Figuren als Beispiele dargestellt und werden hierin ausführlich beschrieben. Es sei jedoch klargestellt, dass nicht beabsichtigt ist, Ausführungsbeispiele auf die jeweils offenbarten Formen zu beschränken, sondern dass Ausführungsbeispiele vielmehr sämtliche funktionale und/oder strukturelle Modifikationen, Äquivalente und Alternativen, die im Bereich der Erfindung liegen, abdecken sollen. Gleiche Bezugszeichen bezeichnen in der gesamten Figurenbeschreibung gleiche oder ähnliche Elemente.
Man beachte, dass ein Element, das als mit einem anderen Element „verbunden“ oder „verkoppelt“ bezeichnet wird, mit dem anderen Element direkt verbunden oder verkoppelt sein kann oder dass dazwischenliegende Elemente vorhanden sein können. Wenn ein Element dagegen als „direkt verbunden“ oder „direkt verkoppelt“ mit einem anderen Element bezeichnet wird, sind keine dazwischenliegenden Elemente vorhanden. Andere Begriffe, die verwendet werden, um die Beziehung zwischen Elementen zu beschreiben, sollten auf ähnliche Weise interpretiert werden (z.B., „zwischen“ gegenüber „direkt dazwischen“, „angrenzend“ gegenüber „direkt angrenzend“ usw.).
Die Terminologie, die hierin verwendet wird, dient nur der Beschreibung bestimmter Ausführungsbeispiele und soll die Ausführungsbeispiele nicht beschränken. Wie hierin verwendet, sollen die Singularformen „einer,” „eine”, „eines” und „der, die, das“ auch die Pluralformen beinhalten, solange der Kontext nicht eindeutig etwas anderes angibt. Ferner sei klargestellt, dass die Ausdrücke wie z.B. „beinhaltet“, „beinhaltend“, „aufweist“, „umfasst“, „umfassend“ und/oder „aufweisend“, wie hierin verwendet, das Vorhandensein von genannten Merkmalen, ganzen Zahlen, Schritten, Arbeitsabläufen, Elementen und/oder Komponenten angeben, aber das Vorhandensein oder die Hinzufügung von einem bzw. einer oder mehreren Merkmalen, ganzen Zahlen, Schritten, Arbeitsabläufen, Elementen, Komponenten und/oder Gruppen davon nicht ausschließen.
Solange nichts anderes definiert ist, haben sämtliche hierin verwendeten Begriffe (einschließlich von technischen und wissenschaftlichen Begriffen) die gleiche Bedeutung, die ihnen ein Durchschnittsfachmann auf dem Gebiet, zu dem die Ausführungsbeispiele gehören, beimisst. Ferner sei klargestellt, dass Ausdrücke, z.B. diejenigen, die in allgemein verwendeten Wörterbüchern definiert sind, so zu interpretieren sind, als hätten sie die Bedeutung, die mit ihrer Bedeutung im Kontext der einschlägigen Technik konsistent ist, und nicht in einem idealisierten oder übermäßig formalen Sinn zu interpretieren sind, solange dies hierin nicht ausdrücklich definiert ist.
1a zeigt ein Flussdiagramm eines computer-implementierten Verfahrens für ein Fahrzeug. Das Verfahren wird durch eine Software-Zwischenschicht, die auf einem Prozessor des Fahrzeugs ausgeführt wird, durchgeführt (ausgeführt). Das Verfahren umfasst ein Erhalten 110 von Daten zum Übermitteln an ein oder mehrere weitere Fahrzeuge. Das Verfahren umfasst ferner ein Bestimmen 120 einer Qualitätsanforderung für die Übermittlung der Daten. Optional umfasset das Verfahren ferner ein Gruppieren 130 der Daten gemäß der Qualitätsanforderung und gemäß einem Ziel der Daten. Optional umfasst das Verfahren ferner ein Kodieren 140 der Daten gemäß der Gruppierung der Daten, wobei Daten einer Gruppe zusammen kodiert werden. Beispielsweise umfasst das Verfahren ferner ein Auswählen 150 eines Übertragungswegs einer Mehrzahl von Übertragungswege basierend auf der Qualitätsanforderung für die Übermittlung der Daten. Die Mehrzahl von Übertragungswegen unterscheiden sich bezüglich der auf dem Übertragungsweg genutzten Übertragungstechnologie oder bezüglich der auf dem Übertragungsweg genutzten Zwischenschritte. Werden die Daten gruppiert und kodiert, so kann das Auswählen 150 des Übertragungswegs auf der Qualitätsanforderung der jeweiligen Gruppe, basieren. Das Verfahren umfasst ferner ein Weitergeben 160 der Daten an ein Sende-Empfängermodul des Fahrzeugs. Beispielsweise können die kodierten Daten an das Sende-Empfängermodul des Fahrzeugs weitergegeben 160 werden, zum Übermitteln der kodierten Daten an die ein oder mehreren Fahrzeuge. Wurde ein Übertragungsweg ausgewählt, so können die Daten an ein Sende-Empfängermodul des Fahrzeugs weitergegeben 160 werden, das mit dem ausgewählten Übertragungsweg assoziiert ist, zum Übermitteln der Daten über den ausgewählten Übertragungsweg. In anderen Worten können die kodierten Daten an ein Sende-Empfängermodul des Fahrzeugs, das mit dem ausgewählten Übertragungsweg assoziiert ist, weitergegeben werden.
1b zeigt ein Blockdiagramm einer entsprechenden Kommunikationseinrichtung 10 für ein Fahrzeug 100. Die Kommunikationseinrichtung umfasst eine Schnittstelle 12 zur Kommunikation mit den ein oder mehreren Sende-Empfängermodulen 16 des Fahrzeugs. Die Kommunikationseinrichtung umfasst ferner ein oder mehrere Prozessoren 14, ausgebildet zum Ausführen des Verfahrens durch Bereitstellen der zuvor genannten Software-Zwischenschicht. 1b zeigt ferner das Fahrzeug umfassend die Kommunikationseinrichtung. In zumindest manchen Ausführungsbeispielen kann beispielsweise auch ein Server, etwa ein Edge-Cloud-Server oder ein mobiles Endgerät, wie etwa ein Smartphone (ein programmierbares Telefonat) die Kommunikationseinrichtung umfassen oder einen Prozessor umfassen, der die Software-Bibliothek ausführt. Entsprechend können in diesen Fällen die ein oder mehreren Sende-Empfängermodule Sende-Empfängermodule des jeweiligen Geräts sein.
Die folgende Beschreibung bezieht sich sowohl auf das Verfahren von 1a als auch auf die entsprechende Kommunikationseinrichtung von 1b sowie auf ein entsprechendes Computerprogramm.
Ausführungsbeispiele der vorliegenden Offenbarung beziehen sich auf ein computer-implementiertes Verfahren, auf ein Computerprogramm sowie auf eine (computerimplementierte) Kommunikationseinrichtung, die, beispielsweise, in einem Fahrzeug (oder in einem Server oder einem mobilen Endgerät) genutzt werden kann, um eine Kommunikation mit einem anderen Gerät, etwa einem anderen Fahrzeug, zu unterstützen. Dabei wird die Funktionalität von einer Software-Zwischenschicht bereitgestellt. Diese Software-Zwischenschicht kann einerseits anwendungsübergreifend genutzt werden, das heißt, die Software-Zwischenschicht kann verschiedenen Anwendungen, die auf dem Prozessor ausgeführt werden, zur Verfügung stehen. Andererseits kann sie unabhängig von einem Betriebssystem des jeweiligen Geräts, etwa der Kommunikationseinrichtung, sein. Beispielsweise kann die Software-Zwischenschicht eine Software-Bibliothek zur Nutzung in einer Kommunikationseinrichtung eines Fahrzeugs sein. Anwendungen, die von dem jeweiligen Gerät (Fahrzeug, Server, mobiles Endgerät, Kommunikationseinrichtung des jeweiligen Geräts etc.) ausgeführt werden, können auf die Software-Bibliothek zugreifen, oder die Software-Bibliothek integrieren. In anderen Worten kann das Verfahren ein Ausführen von ein oder mehreren Anwendungen (durch den Prozessor) umfassen, wobei die ein oder mehreren Anwendungen über die Software-Bibliothek kommunizieren. Dabei kann die Software-Bibliothek ihre Funktionalität jeder Anwendung beispielsweise unabhängig von anderen Anwendungen bereitstellen, so dass beispielsweise jede Anwendung auf eine separate Instanz der Software-Bibliothek zugreift. Alternativ können verschiedene Anwendungen auf die gleiche Instanz der Software-Bibliothek zugreifen.
Das Verfahren umfasst das Erhalten 110 der Daten zum Übermitteln an ein oder mehrere weitere Fahrzeuge. Dabei können grundsätzlich zwei Arten von Daten unterschieden werden - Daten, die von Anwendungen stammen, die von dem Fahrzeug/Gerät selbst ausgeführt werden, und Daten, die von anderen Fahrzeugen/Geräten stammen. In anderen Worten kann zumindest ein Teil der Daten von Anwendungen stammen, die von dem Fahrzeug/Gerät selbst ausgeführt werden. Ein anderer Teil der Daten kann von anderen Fahrzeugen/Geräten stammen. Entsprechend kann das Erhalten der Daten ein Empfangen 112 zumindest eines Teils der Daten von einem weiteren Fahrzeug/Gerät umfassen (etwa über die ein oder mehreren Sende-Empfängermodule). Sind diese empfangenen Daten kodiert, so können sie dekodiert werden und dann anschließend weiterverarbeitet werden. Beispielsweise kann das Erhalten zumindest eines Teils der Daten ein Empfangen 112 einer kodierten Fassung des Teils der Daten von einem weiteren Fahrzeug/Gerät und ein Dekodieren 114 des empfangenen Teils der Daten umfassen. In diesem Fall (der Kodierung) werden die Daten im Allgemeinen auch gruppiert. Daher können die dekodierten Daten gemäß der Gruppierung erneut kodiert 140 werden (nach erneuter Gruppierung). Im Allgemeinen können die Daten, zumindest wenn sie von anderen Fahrzeugen/Geräten erhalten werden, aber auch wenn sie von Anwendungen des Geräts/Fahrzeugs stammen, als Datenpaket oder Sequenz von Datenpaketen erhalten werden. Dabei kann das Datenpaket oder die Sequenz von Datenpaketen auf dem Quick User Datagram Protocol (UDP, Benutzer-Datagramm-Protokoll) Internet Connections (QUIC, Schnelle UDP-Internet-Verbindungen)-Protokoll basieren. Doch auch andere Protokolle sind denkbar. In manchen Ausführungsbeispielen kann das Datenpaket oder die Sequenz von Datenpakten nicht auf dem Transmission Control Protocol basieren. Beispielsweise können die Daten, im Zusammenhang mit den 2a bis 6d, als „Anwendungsdaten“ bezeichnet werden.
Werden die Daten von einem anderen Fahrzeug/Gerät empfangen und sollen weitergeleitet werden, so stellt sich im Allgemeinen die Frage, ob sie von dem Empfänger weiterhin benötigt werden. Dies ist möglicherweise nicht immer der Fall, da in einer Multi-Hop-Kommunikation eine deterministische Bestimmung der Übertragungszeit nicht zuverlässig möglich ist. Daher können die Daten an dieser Stelle erst darauf geprüft werden, ob es sich lohnt, diese weiterleiten. Beispielsweise können die empfangenen Daten bis zu einem vordefinierten Zeitpunkt gültig sein. Eine Information über diesen vordefinierten Zeitpunkt kann in den jeweiligen Daten umfasst sein, etwa als Zeitstempel. Die empfangenen Daten können weitergeleitet werden, falls die Daten nach dem Übermitteln der Daten über den ausgewählten Übertragungsweg voraussichtlich noch gültig sind. Entsprechend kann zu jedem Übertragungsweg eine Information über eine voraussichtliche Übermittlungsdauer (zu einem Ziel von Daten) vorliegen und/oder ermittelt werden.
Das Verfahren umfasst ferner das Bestimmen 120 der Qualitätsanforderung für die Übermittlung der Daten. Dabei kann es sich bei der Qualitätsanforderung um sogenannte Quality of Service (Qualität des Dienstes)-Parameter handeln, also beispielsweise (minimal-) Anforderungen an ein oder mehrere Parameter (Latenz, Datenrate, Fehlerrate etc.) der Übermittlung der Daten. Dabei sind mehrere Varianten denkbar. Einerseits kann die Qualitätsanforderung für die Übermittelung der Daten aus der Art der Daten hervorgehen. So können beispielsweise Videoübertragungen andere Qualitätsanforderungen haben als Daten, die zur Koordination eines kooperativen Fahrmanövers ausgetauscht werden. Daher kann das Bestimmen der Qualitätsanforderung für die Übermittlung der Daten ein Bestimmen der Qualitätsanforderung basierend auf einer Art (oder Typ) der Daten umfassen. Alternativ kann die Qualitätsanforderung aus einer Quelle oder einem Ziel der Daten hervorgehen. Beispielsweise können die Daten von ein oder mehreren Anwendungen stammen, etwa von ein oder mehreren Fahrzeugdiensten zur Koordination von Fahrzeugen stammen. Dabei können die ein oder mehreren Fahrzeugdienste beispielsweise einen kooperativen Spurwechselassistenten, einen Fahrzeugdienst zur Koordination an einer Kreuzung und/oder einen Fahrzeugdienst für das Fahren in einer Gruppe von Fahrzeugen (auch engl. Platooning) umfassen. Jeder Anwendung, etwa jedem Fahrzeugdienst, kann eine Qualitätsanforderung zugewiesen sein. Die Qualitätsanforderung für die Übermittlung der Daten kann basierend auf der Qualitätsanforderung, die dem jeweiligen Fahrzeugdienst, oder der jeweiligen Anwendung, von dem die Daten stammen, zugewiesen ist, bestimmt werden. Als dritte Möglichkeit können die Daten selbst eine Information über die jeweilige Qualitätsanforderung umfassen, oder die jeweilige Anwendung/Fahrzeugdienst kann die Information über die jeweilige Qualitätsanforderung bereitstellen. Dies ist im Zusammenhang mit den 2a bis 6d als „Priorisierungsinformationen“ oder „Kontrollinformationen“ beschrieben.
In manchen Ausführungsbeispielen umfasst das Verfahren ferner das Gruppieren 130 der Daten gemäß der Qualitätsanforderung und gemäß dem Ziel der Daten. Dabei können beispielsweise Daten, die die gleiche oder ausreichend ähnliche Qualitätsanforderung haben, und das gleiche Ziel (oder zumindest einen gleichen Zwischenschritt, bei einer Multi-Hop-Übertragung), zusammen gruppiert werden. Dabei kann das „Gruppieren“ bedeuten, dass die Daten gesammelt werden, um anschließend zusammen kodiert oder zumindest zusammengefasst in einer geringeren Anzahl von Paketen übermittelt zu werden.
So kann das Verfahren ferner das Kodieren 140 der Daten gemäß der Gruppierung der Daten umfassen. Dabei werden Daten einer Gruppe zusammen kodiert. Durch die Kodierung werden die Daten gemäß den Gruppen zusammengefasst, und können so zusammen zu ihrem Ziel übermittelt werden. Beispielsweise kann ein Kodieralgorithmus, der für die Kodierung verwendet wird, abhängig von der Anwendung, von der die Daten stammen, ausgewählt sein, oder abhängig von der Qualitätsanforderung. Ein Beispiel dafür ist in 4d gezeigt, wo die Daten von einer Edge-Cloud gruppiert und zusammen kodiert werden. Die kodierten Daten können an das Sende-Empfängermodul des Fahrzeugs weitergegeben werden. Dabei können die Daten beispielsweise basierend auf einer linearen Netzwerk-Kodierung (engl. linear network coding) kodiert werden. Beispielsweise kann zu der Implementierung der Kodierung auf die Vorschläge zurückgegriffen werden, die in der IETF diskutiert werden, unter dem Titel „Coding for QUIC“.
Das Verfahren umfasst, in zumindest einigen Ausführungsbeispielen, das Auswählen 150 des Übertragungswegs der Mehrzahl von Übertragungswege basierend auf der Qualitätsanforderung für die Übermittlung der Daten. Dabei kann es sich bei dem Auswählen des Übertragungswegs um ein sogenanntes Scheduling (Planen einer Ressource eines Kommunikationsnetzwerks) handeln. Entsprechend werden weitere mögliche Details und Implementierungen in den 2a bis 6d unter dem Stichwort „Scheduling“ oder „Scheduler“ gegeben. Dabei stellt die Software-Zwischenschicht die Funktionalität eines Multipath- (oder Multilink-) Schedulers bereit. Das Auswählen 150 des Übertragungsweges kann mit der Zielsetzung erfolgen, einen Übertragungsweg auszuwählen, der (voraussichtlich) die Qualitätsanforderung für die Übermittlung der Daten erfüllt. Andererseits können auch andere Kriterien berücksichtigt werden, wie etwa, eine Konzentration der Datenübertragung über einen störanfälligen Pfad (etwa direkte V2X-Kommunikation) zu vermeiden.
Dabei unterscheiden sich die Mehrzahl von Übertragungswege bezüglich der auf dem Übertragungsweg genutzten Übertragungstechnologie oder bezüglich der auf dem Übertragungsweg genutzten Zwischenschritte. Beispielsweise kann die Mehrzahl von Übertragungswegen auf ein oder mehreren (drahtlosen) Übertragungstechnologien basieren, wie etwa auf ein oder mehreren verschiedenen zellulären Mobilfunksystemen und/oder auf ein oder mehreren verschiedenen Übertragungstechnologien zur direkten Geräte-zu-Geräte-Kommunikation (engl. Device-to-Device, D2D), wie etwa direkte V2X-Kommunikation (ohne Nutzung einer Basisstation oder eines Relais). Dabei kann die V2X-Kommunikation beispielsweise Fahrzeug-zu-Fahrzeug-Kommunikation (Vehicle-to-Vehicle, V2V) umfassen und/oder Fahrzeug-zu-Infrastruktur-Kommunikation (Vehicle-to-Infrastructure, V2I). Die ein oder mehreren zellulären Mobilfunksysteme können beispielsweise eine oder mehrere Mobilfunksysteme der Gruppe von Global System for Mobile telecommunications (GSM), General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE), Universal Mobile Telecommunication System (UMTS), Long Term Evolution (LTE), Long Term Evolution Advanced (LTE-A), und ein Mobilfunksystem der 5. Generation (5G) umfassen. Beispielsweise können die ein oder mehreren Sende-Empfängermodule dazu geeignet oder ausgebildet sein, um über (direkte) V2X-Kommunikation und/oder über ein zelluläres Mobilfunksystem zu kommunizieren.
Zudem können sich die Übertragungswege bezüglich der (ein oder mehreren) genutzten Zwischenschritte unterscheiden. Auch hier sind mehrere Szenarien möglich. So können manche Übertragungswege keinen Zwischenschritt aufweisen, also eine direkte Übertragung ermöglichen. Manche Übertragungswege können einen vordefinierten Zwischenschritt aufweisen, etwa eine Edge-Cloud (der beispielsweise mit einer Basisstation eines zellulären Mobilfunksystems oder mit einer Infrastruktur am Straßenrand gekoppelt ist) oder einem Internetdienst (der über das Internet zugänglich ist, wobei die Daten über eine Basisstation und das Internet zu dem Internetdienst, und von dem Internetdienst über das Internet und über eine Basisstation zu dem Ziel der Übertragung übermittelt werden). Entsprechend kann zumindest einer der Übertragungswege auf einer Übertragung über eine Edge-Cloud basieren. Alternativ oder zusätzlich kann zumindest einer der Übertragungswege auf einer Übertragung über einen Internetdienst basieren. Manche Übertragungswege können auch auf mehreren Zwischenschritten basieren, etwa, wenn über die direkte V2X-Kommunikation eine Multi-Hop-Übertragung durchgeführt wird. Beispielsweise kann zumindest einer der Übertragungswege auf einer Übertragung über mehrere Zwischenschritte (also auf einer Multi-Hop-Übertragung) basieren. Dabei können Übertragungswege über unterschiedliche Multi-Hop-Zwischenschritte auch als unterschiedliche Übertragungswege im Sinne der Offenbarung gelten.
Auch eine Kombination verschiedener Übertragungstechnologien und unterschiedlicher Zwischenschritte ist möglich.
In manchen Ausführungsbeispielen kann bei der Auswahl des Übertragungswegs auf verschiedene Vorgaben geachtet werden. Zum einen können die gewählten Übertragungswege „sticky“ (klebrig) sein, das heißt, die Übertragung der Daten zu einem gegebenen Ziel mit einer gegebenen Qualitätsanforderung kann (immer) der gleiche Übertragungsweg gewählt werden. Beispielsweise kann für Daten, die für das gleiche Fahrzeug bestimmt sind und der gleichen Sequenz von Datenpaketen entstammen, der gleiche Übertragungsweg ausgewählt werden. Auch können Daten, die zusammen gruppiert und kodiert wurden, über den gleichen Übertragungsweg übertragen werden. In anderen Worten können die Daten so dem Sende-Empfängermodul des Fahrzeugs weitergegeben werden, dass Daten, die zusammen gruppiert und kodiert wurden, zusammen über den gleichen Übertragungsweg übermittelt werden. Folglich kann für die Daten der Übertragungsweg so ausgewählt werden, dass Daten, die zusammen gruppiert und kodiert wurden, zusammen über den gleichen Übertragungsweg übermittelt werden. Auch eine Auswahl durch die jeweilige Anwendung, die die Daten bereitstellt, kann berücksichtigt werden.
Das Verfahren umfasst ferner das Weitergeben 160 der kodierten Daten an ein Sende-Empfängermodul des Fahrzeugs, zum Übermitteln der kodierten Daten an die ein oder mehreren Fahrzeuge. Dabei können die Daten an das jeweilige Sende-Empfängermodul des Fahrzeugs, das mit dem ausgewählten Übertragungsweg assoziiert ist, weitergegeben werden.
Die Software-Zwischenschicht kann dabei beispielsweise die Daten in einem Paketformat weitergeben, oder die Daten können von dem jeweiligen Sende-Empfängermodul, oder von einer intermediären Verarbeitungseinheit in ein Paketformat überführt werden. Beispielsweise kann das Paketformat ein QUIC-Paketformat sein. In anderen Worten können die Daten basierend gemäß dem QUIC-Protokoll oder in einem QUIC-Paketformat weitergegeben werden.
Die zumindest eine Schnittstelle 12 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
In Ausführungsbeispielen können die ein oder mehreren Prozessoren 14 (etwa der Prozessor des Fahrzeugs/Geräts) einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise können die ein oder mehreren Prozessoren 14 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern können die ein oder mehreren Prozessoren 14 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung der ein oder mehreren Prozessoren 14 denkbar.
In Ausführungsbeispielen können die ein oder mehreren Sendeempfänger-Module 16 typische Sender- bzw. Empfängerkomponenten enthalten. Darunter können beispielsweise ein oder mehrere Antennen, ein oder mehrere Filter, ein oder mehrere Mischer, ein oder mehrere Verstärker, ein oder mehrere Diplexer, ein oder mehrere Duplexer, usw. fallen.
Mehr Details und Aspekte des Verfahrens, der Kommunikationseinrichtung und des Computerprogramms werden in Verbindung mit dem Konzept oder Beispielen genannt, die vorher oder nachher, etwa in den 2a bis 6d, beschrieben werden. Die Kommunikationseinrichtung, das Verfahren und/oder das Computerprogramm kann ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben wurden.
Im Folgenden werden weitere konkrete Beispiele für die Funktionalität der Software-Zwischenschicht, die im Zusammenhang mit den 1a bis 1b eingeführt wurden, gegeben. Dabei kann die Software-Zwischenschicht beispielsweise ein oder mehrere der nachfolgend genannten Merkmale oder Funktionalitäten implementieren oder die zuvor genannten Funktionalitäten konkretisieren. Insbesondere kann die Software-Zwischenschicht genutzt werden, um den nachfolgend genannten Connected Car Scheduler und/oder die nachfolgend genannte Connected Car Gruppierung und Kodierung bereitzustellen.
Ausführungsbeispiele der vorliegenden Offenbarung befassen sich im Allgemeinen Connected Car (wörtlich: „vernetztes oder verbundenes Fahrzeug“, ein Konzept zur kommunikativen Vernetzung von Fahrzeugen) Multipath- (Mehrwege-) Scheduling (wörtlich: Planung, hier Planung einer Nutzung von Kommunikationsressourcen)-Entwicklungen mit der 5. Generation OCU (OnBoard Communication Unit, Bordeigene Kommunikationseinheit), die V2X (Vehicle-to-Everything, Fahrzeug-zu-Allem, eine Oberbegriff für eine Kommunikation zwischen einem Fahrzeug und anderen Fahrzeugen oder Infrastruktur) und zelluläre Funktechnologien beinhalten. Ausführungsbeispiele bauen dabei beispielsweise auf Multipath-TCP (Transmission Control Protocol, Protokoll zur Übertragungssteuerung) oder Multipath-QUIC (Quick UDP (User Datagram Protocol) Internet Connection) auf.
Multipath-TCP bietet keine einfache Möglichkeit, die Übertragung durch die Anwendung zu steuern. Die Einbindung auf Geräten stellt sich als komplex heraus, da in bisherigen Konzepten ein entsprechendes Kernelmodul benötigt wird. Multipath-QUIC befindet sich in der Entwicklung und weist einen auf Ideen von Multipath-TCP basierenden Scheduler (wörtlich: Planer, hier Planer zur Verteilung von Kommunikationsressourcen) auf. Ein solcher Scheduler ist gegebenenfalls nicht im V2X-Umfeld mit Multipath-QUIC anwendbar. Zudem wurde in früheren Konzepten lediglich sogenannte Single Hop-Kommunikation (Kommunikation ohne Zwischenstationen) betrachtet.
In der Literatur werden Ansätze diskutiert, die versuchen den Scheduler von Multipath-TCP so anzupassen, dass über Register eigene Scheduling-Bedingungen vorgegeben werden können. Dies ist aufgrund der beschränkten Möglichkeiten, einen Kernel im Nachhinein zu beeinflussen allerdings gegebenenfalls instabil und ermöglicht nur sehr rudimentäre Eingriffsmaßnahmen. Multipath-QUIC wird bisher auf dem Gebiet der V2X-Kommunikation nicht eingesetzt, daher gibt es dort keine Möglichkeiten eine Priorisierung vorzunehmen. Multi-Hop Betrachtung findet ebenfalls weder in Multipath-TCP noch Multipath-QUIC statt.
Im Folgenden wird ein Scheduling-Algorithmus zur intelligenten Aufteilung der Daten erläutert. Der Connected Car Scheduler bietet eine Möglichkeit über mehrere sogenannte Sockets (wörtlich: Steckdosen, im eigentlichen Sinne aber logische Zugänge auf Software-Ebene) und damit physikalische Übertragungsmedien eine Datenübertragung herzustellen. Um die Aufteilung an die verschiedenen Eigenschaften von Connected Car-Anwendungen anzupassen, kann eine Tabelle genutzt werden, in der verschiedene Services (Fahrzeugdienste), mit verschiedenen Anforderungsklassen (Qualitätsanforderungen) definiert werden können. Zusätzlich ist es möglich eine Ausprägung von Prioritäten vorzugeben, die anschließend vom Scheduler für die Verteilung der Daten genutzt werden (bspw. niedrige Latenz, höchste Datenrate etc.). So lassen sich einfache bis komplexe Verteilungsstrategien abbilden. Zur besonders einfachen Steuerung des Datenflusses ist es möglich eine Service ID zu hinterlegen. Mithilfe der Service ID kann dann aus einer Tabelle die Ausprägung der verschiedenen Kriterien entnommen werden und aufgrund dieser eine Entscheidung für den besten Übertragungsweg berechnet werden. Die zu verwendeten Übertragungsmedien sind dabei transparent für die Anwendung. So können beliebig viele physikalische Übertragungsmedien in verschiedenster Ausprägung genutzt werden, ohne dass an der eigentlichen Anwendung Änderungen vorgenommen werden müssen. Durch Vorgabe der Parameter Datenrate, Latenz und Fehlertoleranz können Anwendungen eine selbstspezifizierte Priorisierung der Daten vornehmen. Als feste Entscheidungsmöglichkeit ist es möglicherweise außerdem möglich, direkt eine bestimmte physikalische Schnittstelle (etwa ein Sende-Empfängermodul) vorzugeben. Dieser Fall ermöglicht es den Scheduling Algorithmus in der Anwendung selbst zu integrieren.
Des Weiteren können empfangene Daten in Zwischenknoten, die weitergeleitet werden sollen, untersucht werden untersucht. Aufgrund ihres Dienste-Identifikators (ID) kann ein Zwischenknoten (wie etwa eine Automotive Cloud, ein abstrakter Serververbund zur Anwendung im Zusammenhang mit Fahrzeugen) Entscheidungen darüber treffen, ob ein Paket weitergeleitet oder verworfen werden sollte. Hierzu werden für einzelne Dienste (oder Pakete) eine Maximum Time to Live (wörtlich: maximale Lebenszeit) festgelegt. Wird diese Zeit überschritten, so wird das Paket gegebenenfalls nicht weitergeleitet. Durch die Kenntnis der Latenz der Übertragungspfade kann diese Entscheidung in den einzelnen Knoten getroffen werden. Dies ermöglicht mithilfe einer Automotive Cloud oder einer Edge Cloud eine Gerät-zu-Gerät (engl. Device-to-Device, D2D)-Anbindung in zellulären Netzen. Durch die Überprüfung kann sichergestellt werden, dass keine Daten übertragen werden, die für den Empfänger aufgrund ihrer Laufzeit nicht mehr relevant sind.
Zusammengefasst bietet dieses Verfahren eine intelligente Steuerung des Datenflusses im Umfeld von Connected Cars, die über multiple Netzzugangstechnologien verfügen. Ausführungsbeispiele stellen eine Steuerung des Datenflusses auf mehreren Übertragungswegen aufgrund von Informationen über die physikalischen Übertragungswege bereit. Zumindest einige Ausführungsbeispiele schaffen zudem eine Multi-Hop Betrachtung in zellulären Netzen. Dadurch kann eine Automotive Cloud als Weiterleitung für V2- Daten genutzt werden. Beispielsweise können die Daten, die im Zusammenhang mit den 1a und/oder 1b thematisiert werden, V2X-Daten sein, also Daten, die zwischen Fahrzeugen ausgetauscht werden.
2a zeigt ein Diagramm eines allgemeinen Aufbaus eines beispielhaften Connected Car-Schedulers. In diesem Beispiel stellen Connected Car-Anwendungen Anwendungsdaten sowie Priorisierungs-/Kontrollinformationen dem Connected Car Scheduler (etwa der Software-Zwischenschicht) bereit. Dieser teilt die Anwendungsdaten auf physikalische Schnittstellen (Sende-Empfängermodulen) Phy 1 bis Phy N auf, und leitete die jeweils relevanten Anwendungsdaten über die sogenannten Sockets 1 bis N an die jeweiligen physikalischen Schnittstellen 1 bis N weiter. Die Physikalischen Schnittstellen stellen dem Scheduler wiederum Informationen über die Umlaufzeit (auch engl. Round Trip Time, RTT), den Durchsatz und/oder die Paketfehlerrate bereit, die von dem Scheduler genutzt werden können, um die Scheduling-Entscheidungen zu treffen.
2b zeigt ein Diagramm eines Beispiels einer Zustandsmaschine (auch engl. State Machine) des Connected Car Schedulers. Hier ist wiederum abgebildet, wie die Connected Car-Anwendung die Anwendungsdaten und Prioritätsinformationen einer Connected Car Scheduling-Schnittstelle (des Schedulers) bereitstellt. Ist eine direkte Zuweisung zu einer physikalischen Schnittstelle in den von der Anwendung übermittelten Informationen enthalten, so wird diese physikalische Schnittstelle genutzt. Ansonsten wird überprüft, ob der Knoten (etwa das Fahrzeug, das den Scheduler ausführt) ein Zwischenknoten ist. Ist dies der Fall, so wird die maximale Lebensdauer der Anwendungsdaten überprüft, und die Daten werden verworfen, falls die maximale Lebensdauer erreicht ist. Falls die maximale Lebensdauer erreicht ist, oder falls das Fahrzeug kein Zwischenknoten für diese Daten ist, so berechnet der Scheduler den besten Pfad basierend auf der Priorität. Dazu kann der Scheduler aus einer Tabelle verfügbarer Schnittstellen Information über die Verbindungs-Charakteristiken (wie etwa Durchsatz, Umlaufzeit etc.) abrufen. Ist der beste Pfad bestimmt, so wird der entsprechende Socket ausgewählt und werden die Daten über die entsprechende physikalische Schnittstelle übermittelt.
Dies schafft in vielen Fällen eine einfache Anwendbarkeit für beliebige Anwendungen, da die Implementierung selbst, als Bibliothek oder Schnittstellenanwendung für Connected Car Anwendungen genutzt werden kann. Außerdem bietet sie eine bedarfsgerechte Verteilung der Daten, basierend auf den Anforderungen der Anwendung.
In vielen anderen System ist das Multilink-Scheduling (Planung von Kommunikationsressourcen über mehrere Verbindungen) häufig zentralisiert, was Störungen verursacht und gegebenenfalls keine Entscheidungen pro Paket auf Anwendungsebene ermöglicht. Multilink-Scheduling wird zudem häufig als Hardware-Erweiterung durchgeführt. Ein solches Scheduling ist häufig nicht in der Lage, aus den Übertragungen von Anwendungen zu „lernen“ und sich an Änderungen dieser Übertragungen anzupassen. Die Nutzung eines einzelnen Schedulings führt zudem möglicherweise dazu, dass sich verschiedene Anwendungen gegenseitig stören. Auch ist zur Unterstützung der Multilink-Fähigkeit meist zusätzliche Hardware-Erweiterungen erforderlich. Auch ist häufig eine Koordination zwischen verschiedenen Geräten erforderlich (z.B. Smartphone, Tablets oder ECUs (Electronic Control Units, Elektronische Steuereinheiten)), so dass ein entsprechender Agent auf jedem Gerät vorgesehen ist. Auch sind Ende-zu-Ende-Übertragungsparameter (z.B. Datenrate, Latenz) auf Anwendungsebene meist nicht nachvollziehbar.
Um diese Nachteile zu vermeiden, kann das Connected Car Multipath Scheduling als Software-Bibliothek implementiert werden. 3a zeigt ein schematisches Diagramm eines Beispiels für Connected Car Multipath Scheduling als Software-Bibliothek. In diesem Beispiel sendet der Sender Daten an einen Empfänger, dieser bestätigt den Empfang von Daten. Daraus kann der Sender die Datenrate und Latenz bestimmen, und diese Daten dem Scheduling-Algorithmus bereitstellen. Zusammen mit einem Satz von Übertragungsparametern (wie etwa Datenrate oder Latenz) von zu übertragenden Daten kann der Scheduling-Algorithmus ein Equilibrium zwischen den gewünschten Parametern bestimmen und die beste (oder zumindest eine angemessene) Verbindung aussuchen. Diese Verbindung kann nun genutzt werden, um die Anwendungsdaten dem Empfänger zu senden.
3b zeigt ein Beispiel für multikriterielles Scheduling. In dem Beispiel werden vier Kriterien berücksichtigt - Redundanz, Latenz, Datenrate und Sicherheit. Zudem werden zwei Anwendungen betrachtet, Anwendung A und Anwendung B. Beispielanwendung A erzeugt hochempfindliche Echtzeit-Sensordaten. Die Übertragung der Daten muss eine kleinstmögliche Latenzzeit und höchstmögliche Sicherheit aufweisen, während Datenrate und Redundanz nicht wichtig sind. Beispielanwendung B erzeugt Video-Streaming-Daten. Die Übertragung der Daten erfordert hohe Datenraten, um eine hohe Streaming-Qualität aufrechtzuerhalten, während andere Parameter nicht wichtig sind. Hier kann nun das Connected Car Multipath Scheduling genutzt werden, um verschiedene Übertragungs-Merkmalskombinationen gemeinsam zu berücksichtigen.
Dabei bietet die Nutzung einer Software-Bibliothek für das Multipath-Scheduling verschiedene Vorteile. So ist sie, beispielsweise ohne Hardware-Änderungen, auf verschiedene Geräte übertragbar. Jede Anwendung kann die erforderlichen Übertragungsparameter individuell festlegen. Der Scheduling-Algorithmus kann beispielsweise aus früheren Übertragungen lernen (falls der Algorithmus als evolutionärer Algorithmus implementiert ist). Das Scheduling kann auf der Anwendungsschicht durchgeführt werden, um ermöglichen, dass keine zusätzliche Latenz eingeführt wird. Zudem entfällt beispielsweise die Notwendigkeit einer komplexen Synchronisation zwischen verschiedenen Einheiten im Fahrzeug. Diese Eigenschaften können beispielsweise ausschließlich mit einer Software-Bibliothek realisierbar sein, da ein zentralisierter Ansatz nicht auf der Basis einer einzelnen Anwendung messen kann.
In anderen Systemen kann der Multilink-Zugriff mit zusätzlicher Hardware zur Aggregation durchgeführt werden. Diese zusätzliche Hardware bedeutet jedoch zusätzliche Kosten und keine Portabilität. Zudem bedingt eine solche Implementierung ein komplexes Abrufen von Link-Informationen mit zusätzlichen Messungen der physikalischen Bedingungen. Zudem sind solche Systeme zentralisiert, was zu Störungen zwischen verschiedenen Benutzern führen kann. Zudem benötigt eine fahrzeuginterner Server eine Verbindung zu dem Hardware-Scheduler. Dem Benutzer der Anwendung kann zudem keine Rückmeldung über die aktuelle Verbindungssituation gegeben werden.
3c zeigt ein schematisches Diagramm einer Nutzung einer Connected Car Multipath (Scheduling)-Bibliothek durch verschiedene Anwendungen (Connected Car Anwendungen 1 bis N). Diese übergeben die zu sendenden Anwendungsdaten jeweils an die Connected Car Multipath (Scheduling)-Bibliothek, in der Anwendungsschicht (engl. application layer). Die Connected Car Multipath (Scheduling)-Bibliothek wiederum überspannt die Schichten (des ISO/OSI Referenzmodells) 7 (Anwendungsschicht) bis 4 (Transportschicht). Dabei ist die Connected Car Multipath (Scheduling)-Bibliothek transparent für die einzelnen Anwendungen. Sie stellt einen verbesserten Ansatz für ein Multipath/Multilink-Scheduling, insbesondere im V2X-Kontext, bereit.
3d zeigt einen schematischen Überblick einer Multipath-Architektur. Dabei werden drei verschiedene Entitäten unterschieden - ein Fahrzeug 300, ein mobiles Endgerät 310, und Backend-Dienste in der Cloud 320 (Dienste, die von nachgeschalteten Rechnern in der Cloud bereitgestellt werden. Die Backend-Dienste 320 umfassen Fahrzeug-Netzwerk-Dienste 1 bis N, die jeweils auf die Multipath-Bibliothek zugreifen. Fahrzeug-Netzwerk-Anwendungen 1 bis N auf dem ECU des Fahrzeugs greifen ebenfalls auf die Multipath-Bibliothek zu, ebenso wie Fahrzeug-Netzwerk-Anwendungen, die auf dem Endgerät ausgeführt werden. Die drei Entitäten kommunizieren beispielsweise über drahtlose Multilinks über das Internet. Dabei wird einerseits ein Ende-zu-Ende-Ansatz zur Kommunikation zwischen den Fahrzeug-Netzwerk-Diensten und den Fahrzeug-Netzwerk-Anwendungen eingesetzt. Andererseits wird eine Unabhängigkeit von der Gerätekonfiguration erreicht.
3e zeigt Details einer beispielhaften Implementierung der Multipath-Architektur. Dabei wird insbesondere der drahtlose Multilink von 3d konkretisiert. Hier ist zu sehen, wie verschiedene Funk-Netzwerke 1 bis N zur Kommunikation zwischen dem Fahrzeug 300 oder dem Endgerät und dem Internet 310 genutzt werden, wobei die verschiedenen Funk-Netzwerke entsprechend verschiedene Pfade 1 bis N bereitstellen. Dabei wird hierbei eine Unterstützung des drahtlosen Multilinks individuell für die einzelnen Anwendungen bereitgestellt. Dabei kann beispielsweise eine Verwendung des Internet-Kommunikationsprotokolls der nächsten Generation „Quick UDP Internet Connections“ (QUIC) als Mehrwegprotokoll (engl. multipath protocol) für verbundene Fahrzeuge auf der der Anwendungsschicht vorgesehen werden. Ein Scheduling-Algorithmus für vernetzte Fahrzeuge für (Multipath)-QUIC kann bereitgestellt werden, mit einer einfachen Integration in jede Anwendung über die Software-Bibliothek. Dies ermöglicht gegebenenfalls eine direkte Kontrollmöglichkeit und Rückmeldemöglichkeiten für einzelne Anwendungen. Dabei kann ein Ende-zu-Ende-Ansatz verfolgt werden, wobei Messungen aus der Datenübertragung abgerufen können (so dass keine zusätzlichen Ressourcen/Komponenten erforderlich sind). Dabei kann in manchen Ausführungsbeispielen ein Multipath-Zugriff (engl. multipath access) mit Netzwerk-Kodierung (engl. network coding) und QUIC-Verbesserungen verwendet werden (beispielsweise für HTTP-Anfragen). Auch ein nahtloser Connected Car Cloud-Zugriff und eine Verbindungsmigration ohne zusätzliche Komponenten (unter Nutzung eines virtuellen SIM-Managements, wie etwa in US20190037349A1 beschrieben) kann verwendet werden. Dabei ist beispielsweise keine Anpassung für zukünftige Technologien erforderlich (5G etc.), da die unteren Schichten für die Bibliothek in der Anwendungsschicht transparent sind
3f zeigt weitere Details einer beispielhaften Implementierung der Multipath-Architektur. Zusätzlich der Kommunikation über das Internet steht nun eine Gerät-zu-Gerät (Device-to-Device)-Kommunikation zur Verfügung, etwa zwischen zwei Fahrzeugen, zwei mobilen Endgeräten, oder einem Fahrzeug und einem mobilen Endgerät. Dabei wird ein erstes Endgerät 330a gezeigt, das eine Anwendung A ausführt, und ein zweites Endgerät 330b, das eine Anwendung B ausführt. Dabei kann das erste und/oder das zweite Gerät jeweils ein Fahrzeug oder ein mobiles Endgerät sein (das beispielsweise im Fahrzeug mitgeführt wird). Dabei ist beispielsweise keine direkte Verbindung zwischen dem Endgerät und dem Fahrzeug, in dem es mitgeführt wird, notwendig. Eine Rekombination von Paketen in der Multipath-Bibliothek erlaubt es, den Verkehr von Gerät 330a zu Gerät 330b und den zellularen Verkehr zu kombinieren, um Übertragungen zu sparen. Im Folgenden wird ein Beispiel ausgeführt. In dem Beispiel benötigt Anwendung A Informationen vom Fahrzeug-Netzwerk-Dienst (der auf dem Backend 320 ausgeführt wird) und von Anwendung B. Dabei ist der Wireless Multilink 1 zwischen Gerät 330a und dem Internet langsam. In einem solchen Szenario kann die Multipath-Bibliothek von Anwendung B Pakete mit Netzwerkcodierung vom Backend mit eigenen Informationen kombinieren, um die Übertragung zu beschleunigen.
Im Unterschied zu anderen Ansätzen wird das Multipath-Scheduling durch eine Software-Bibliothek ohne Bedarf an zusätzlicher Hardware (wie etwa einen Bonding-Server oder einen Multilink-Codierer in der MAC (Media Access Control, Medienzugriffskontroll-)-Schicht) bereitgestellt werden. Durchsatz, Latenzzeit (Hin- und Rücklaufzeit) und Verlustraten können von Algorithmen zur Datenstau-Kontrolle (auch engl. congestion control) ohne zusätzliche Rechenkomplexität (oder Komponenten) abgerufen werden. Ein auf diesen Ende-zu-Ende-Statistiken basierende Scheduling ermöglicht eine präzise Entscheidungsfindung, verglichen mit Unzulänglichkeiten bei Messungen auf den unteren Schichten (beispielsweise gibt das Signal-Rausch-Verhältnis keine Auskunft über den Durchsatz der Anwendungsschicht). Die Software-Bibliothek kann dabei beispielsweise auf verschiedene Geräte portiert werden, das mindestens zwei Netzzugangsgeräte (Sende-Empfängermodule) besitzt, ohne Änderungen an der Hardware zu benötigen. Beispielsweise kann die Software-Bibliothek von Anwendungen auf einem Steuergerät genutzt werden, mit Tethering (Anbindung über ein mobiles Endgerät) und Modem als Pfade. Damit können Anwendungen beide Schnittstellen mit einem einfachen Software-Update (Aktualisierung) nutzen (durch Integration der Bibliothek). Zudem ist kein Zwischenknoten (wie etwa ein Bonding-Server) für die Verbindung erforderlich, was die Latenzzeit erhöhen würde. Zudem wird die Verbesserung einer Endgeräte oder Steuergeräte-Anwendung unabhängig von der Systemarchitektur (LINUX, Windows, Android usw.) oder Kodiersprache (Python, C++, Java usw.) ermöglicht. Die Software-Bibliothek kann zudem zur Verbesserung der Benutzerfreundlichkeit von Connected Car Anwendungen auf Geräten wie Smartphones (programmierbaren Telefonen) und Tablet-Computern verwendet werden. Zumindest manche Ausführungsbeispiele stellen ferner eine Implementierung des Internet-Protokolls der nächsten Generation QUIC als Multipath-Kommunikationsbibliothek mit Erweiterungen für die Nutzung von Connected Car zur Verfügung. Eine solche Bibliothek kann für digitale Großunternehmen von Interesse sein, hierbei jedoch nicht im Zusammenhang mit der Nutzung von Fahrzeugen. Zudem sind, verglichen mit anderen Ansätzen, keine oder wenige Änderungen im Empfang von Daten notwendig (aufgrund der Netzwerk-Kodierung).
Grundsätzlich können die von QUIC eingebrachten Verbesserungen auch für Connected Car-Anwendungen von Vorteil sein: Niedrige Latenz, schneller Verbindungsaufbau (0-Umlaufzeit Kryptographie-Handshake, wörtlich: Händeschütteln), verschlüsselte Verbindungen, Verbesserungen für drahtlose Umgebungen. QUIC kann mit Connected Car Multipath Scheduling und Kodierung erweitert werden. Dies ermöglicht beispielsweise eine Bandbreiten-Aggregation, eine latenzbewusste (engl. latency-aware) Kommunikation, einen Abhörschutz durch „Security by Obscurity“ (Sicherheit durch Geheimhaltung, da die Netzwerk-Codierung von Daten den vollständigen Empfang aller Pakete benötigt, um alle Informationen zu entschlüsseln), eine Robustheit ohne zusätzliche Redundanz, ein adaptives Multikriterienoptimiertes Scheduling und/oder einen auswechselbaren Scheduling- und Datenstaukontroll-Algorithmus. Die Bereitstellung des Multipath-Scheduling als Software-Bibliothek kann eine einfache Bereitstellung ermöglich, eine Notwendigkeit für Systemänderungen vermeiden, eine breite Verwendung ermöglichen sowie die Flexibilität erhöhen.
3g zeigt, als beispielhafte Konkretisierung von 3a, eine beispielhafte Implementierung eines QUIC-Multipath-Schedulers als Software-Bibliothek. Dabei kann eine Sender-Connected Car-Anwendung Anwendungsdaten der Connected Car Multipath-Bibliothek bereitstellen. Diese kann wiederum QUIC nutzen, und einen Connected Car Multipath Scheduler für QUIC bereitstellen. Dabei stehen UDP-Verbindungen 1 bis N zur Verfügung, die über Datenstau-Kontroll-Blöcke 1 bis N von dem Scheduler mit Daten versorgt werden. Parameter wie Umlaufzeit, Bandbreite und Verlust (Paketverlust) werden von den Datenstau-Kontroll-Blöcken dem Scheduler zurückgemeldet. Hierbei wird eine optimierte/verbesserte Implementierung von QUIC für Connected Car-Anwendung bereitgestellt.
3h zeigt, als weitere beispielhafte Konkretisierung von 3a und/oder 3g, eine weitere beispielhafte Implementierung eines QUIC-Multipath-Schedulers als Software-Bibliothek. Verglichen mit 3f wird dabei ein weitere funktionaler Block Connected Car Gruppierung und Kodierung eingefügt, der eine Gruppierung und (Re-)-Kodierung der Anwendungsdaten vornimmt. Hierbei können die Parameter wie Umlaufzeit, Bandbreite und Verlust (Paketverlust) von den Datenstau-Kontroll-Blöcken dem Connected Car Gruppierung und Kodierungs-Block zurückgemeldet werden.
3i zeigt ein schematisches Diagramm eines Datenflusses zwischen verschiedenen Komponenten einer Connected Car-Anwendung (und Scheduling-Bibliothek), beispielsweise in dem System von 3h. In Empfangsrichtung werden die Daten über den Medienzugriff- und niedrigere Schichten 340 empfangen und in UDP-Ströme 1 bis N 342 aufgeteilt. In Empfangsrichtung werden die Daten dann einem QUIC-Strom-Kontrollblock 344 übergeben, der die Daten einem Dekodierungs- und Degruppierungsblock 346 übergibt, der wiederum die Anwendungsdaten 348 für die Connected Car-Anwendung bereitstellt. In Senderichtung werden Anwendungsdaten 350 einem Gruppierungsblock 352 übergeben, der die Daten in Gruppen 1 bis N 354 aufteilt. Diese werden jeweils von Netzwerk-Kodierungsblöcken 356 kodiert und einem Multipath-QUIC-Block 358 übergeben. Dieser steht im Austausch mit dem QUIC Strom-Kontrollblock 344, welcher die Daten dem Connected Car Multipath Scheduler 360 übergibt. Dieser erhält beispielsweise die oben genannten Parameter von den Datenstau-Kontrollblöcken 1 bis N 362 der UDP-Ströme 1 bis N 342, und leitet die Daten den jeweiligen UDP-Strömen 342 zur Weiterleitung über die Medienzugriff- und niedrigere Schichten 340 weiter. Der Gruppierungs-Block 352 erhält dabei Informationen von dem Connected Car Multipath Scheduler 360.
3j zeigt ein schematisches Diagramm eines beispielhaften Datenflusses zwischen einer Connected Car-Anwendung und der Connected Car Multipath-Bibliothek auf Sendeseite. Bei der Initialisierung der Connected Car-Anwendung werden die Kommunikationsparameter konfiguriert und der Bibliothek übergeben, welche den Scheduling-Algorithmus berechnet. Die Bibliothek berechnet die Umlaufzeit, Bandbreite und den Verlust basierend auf Bestätigungen von Kommunikationsdaten und berechnet die optimale Pfad-Verteilung. Dabei wird Datenstau-Kontroll-Information zum Scheduling im Connected Car-Umfeld eingesetzt. Will die Connected Car-Anwendung Daten senden, so gruppiert und kodiert die Bibliothek die Daten, wählt den QUIC-Pfad über den Scheduling-Algorithmus aus und übermittelt die kodierten Kommunikationsdaten.
3k zeigt ein schematisches Diagramm eines beispielhaften Datenflusses zwischen einer Connected Car-Anwendung und der Connected Car Multipath-Bibliothek auf Empfängerseite. Werden kodierte Kommunikationsdaten von einem anderen Gerät empfangen, so weist die Software-Bibliothek den Empfangspfad zu und sendet eine Bestätigung über die empfangenen Daten. Zudem entgruppiert und dekodiert die Software-Bibliothek die Daten, welche nun von der Software-Bibliothek empfangen werden können.
Im Folgenden wird genauer auf das Konzept des Gruppierens und Kodierens eingegangen. Zumindest manche Ausführungsbeispiele stellen eine Connected Car Multipath Kodierung und Gruppierung bereit.
Eine Nutzung aller zur Verfügung stehenden Kommunikationstechnologien bietet signifikante Vorteile bei der Übertragung von Daten. So können höhere Datenraten durch die Bündelung der verschiedenen Übertragungsmedien erreicht, Latenzen verringert sowie die Ausfallsicherheit erhöht werden. Eine Möglichkeit zur Verteilung der Daten ist mit dem Connected Car Scheduling gegeben, um die Robustheit der Übertragung in heterogenen Netzen zu erhöhen, bietet es sich zudem an die Daten mit einem ressourcenschonenden Kodier-Algorithmus zu versehen. Dieser wird im Folgenden erläutert. Die Connected Car Kodierung & Gruppierung basiert auf dem sogenannten Network Layer Coding (Netzwerkschicht-Kodierung) für QUIC, wie es von der IEFT (Internet Engineering Task Force, Internet-Entwicklungs-Arbeitsgruppe). Dabei existieren in zumindest manchen Entwürfen Anforderungen, die für ein Kodier-Schema erfüllt werden müssen. Dabei wird beispielsweise definiert, dass die Komplexität und der Overhead (die Gemeinkosten) gering sein sollten. Des Weiteren sollten Zwischenknoten dazu fähig sein, neu kodierte Symbole zu erzeugen. Die Kodierung kann die Eigenschaften des Protokolls für Multipath Übertragungen verbessern. Dabei können die Vorteile der Kodierung für Connected Cars verwendet werden. Die oben genannten Punkte sind ebenso für einen Connected Car-Einsatz für ein Multipath-QUIC vorteilhaft. Dazu kommt, dass Daten, die über ein heterogenes Multipfad Connected Car Netz versendet werden auf zum Teil sehr heterogene Pfade treffen. Daher kann die Datencodierung auf die unterschiedlichen Übertragungspfade und Anwendungen angepasst werden. Je nachdem welche Anforderungen eine Anwendung an die Datenübertragung stellt, ist es sinnvoller eine Gruppe von Paketen über einen bestimmten (Multi-)Pfad zu übertragen. Um dieser Anforderung gerecht zu werden kann es vorteilhaft sein, der Kodierung eine Gruppierung hinzuzufügen, die mit V2X und den entsprechenden Anwendungen die Grundlagen für eine intelligente Gruppen-Kodierung legt.
Mit Hilfe der Gruppierung können etwaige Laufzeitunterschiede zwischen Übertragungsmedien effizient ausgeglichen werden. Außerdem kann Redundanz für Daten hinzugefügt werden, die von der Anwendung als besonders wichtig markiert worden sind. Des Weiteren wird im Zusammenspiel mit der Verwendung des Connected Car Schedulings in der Automotive Cloud ein Recoding (eine Neukodierung) ermöglicht. Dies ermöglicht beispielsweise eine intelligente Zusammenführung von verschiedenen empfangenen Daten von Connected Cars.
Während im Entwurf der IETF von Zwischenknoten aufgrund von Sicherheitsbestimmungen keine erneute Kodierung unterstützt wird, kann eine Automotive (Edge-) Cloud als Endpunkt angesehen werden. Daher können die Daten hier entschlüsselt und auf diesem Wege erneut zusammengeführt werden und in einer erneuten Ende-Zu-Ende Übertragung verschickt werden. Befinden sich mehrere Fahrzeuge in einem Gebiet, die die gleichen Informationen einer Automotive (Edge-) Cloud benötigen, können so durch die Zusammenführung von Daten über die Kodierung Synergie Effekte entstehen und Übertragungskapazitäten eingespart werden. Aufgrund der Bestimmungen im Entwurf der IETF werden im Folgenden nur die Gruppierungs- und Redundanz Algorithmen, basierend auf Connected Car-Anwendungen, Gegenstand sein. Bei den zugrunde liegenden Kodierungsalgorithmen kann auf den Entwurf der IETF zurückgegriffen werden. Algorithmen nicht Inhalt des Schreibens sein sollen. Information über die Kodierung können daher von der IETF bezogen werden, unter dem Titel „Coding for QUIC“.
Verschiedene Ausführungsbeispiele schaffen somit eine Steuerung des Datenflusses auf mehreren Übertragungswegen aufgrund von Informationen der physikalischen Übertragungswege. Ausführungsbeispiele können ferner eine Multi-Hop Betrachtung in zellulären Netzen vornehmen. Dadurch kann eine Automotive Cloud als Weiterleitung für V2X Daten genutzt werden.
4a zeigt ein Diagramm eines allgemeinen Aufbaus eines beispielhaften Connected Car-Bibliothek mit Unterstützung für Gruppierung und Kodierung. Connected Car-Anwendungen stellen hierbei, ähnlich wie in 2a gezeigt, Anwendungsdaten und Priorisierungs-/Kontrollinformationen bereit. In 4a werden dieser Daten und Informationen jedoch einem Connected Car-Gruppierungsblock übergeben, der die Anwendungsdaten den unterschiedlichen Gruppen 1 bis N zuweist. Die Daten der einzelnen Gruppen werden zusammen kodiert, und die kodierten Daten werden über die QUIC-Sender 1 bis N bereitgestellt. Dabei werden Parameter wie die Umlaufzeit und der Durchsatz dem Connected Car Gruppierungsblock bereitgestellt.
4b zeigt, im Vergleich dazu, einen beispielhaften Aufbau einer Datenübertragung über Multipath-TCP. Dabei werden die Anwendungsdaten einer Anwendung dem Multipath-TCP-Block übergeben, von diesem werden die Daten einem Gruppierungsblock und danach einem Netzwerkkodierungsblock übergeben, von dem die kodierten Daten bereitgestellt werden. Multipath-TCP (B4.) benötigt Kernel Implementierungen, daher ist eine Anpassung an die Anwendung nicht möglich, außerdem sind die Änderungen systemweit, während die vorgeschlagene Erweiterung von Multipath QUIC. die Möglichkeit bietet, für jede Anwendung eine perfekte Gruppierung zu erzeugen.
Dabei bietet die Implementierung als Software-Bibliothek eine einfache Anwendbarkeit für beliebige Anwendungen, da die Implementierung selbst, als Bibliothek oder Schnittstellenanwendung für Connected Car-Anwendungen genutzt werden kann. Außerdem bietet sie eine bedarfsgerechte Verteilung der Daten, basierend auf den Anforderungen der Anwendung. Heterogene Kanaleigenschaften können bei der Multilink Übertragung abgefangen werden, Redundanzen können hinzugefügt werden. Zudem können Zwischenknoten Pakete zusammenführen.
In anderen Systemen erfolgt die Multilink-Kodierung meist in Hardware. Dabei sind zur Unterstützung der Codierung zusätzliche Hardware-Erweiterungen erforderlich. Auch kann die Kodierung nur über die Geräte erfolgen, die auf der Plattform verfügbar sind (in einer Edge-Cloud (einer abstrakten Server-Instanz, die räumlich nahe zu den zu verarbeitenden Daten angeordnet ist) gibt es typischerweise nur eine Kommunikationsschnittstelle, nämlich eine Netzwerkkarte). Eine Kodierung auf Anwendungsebene ist hier im Allgemeinen nicht möglich, da die Hardware feststehend ist und eine Anpassung an die Anforderungen der Anwendung kompliziert ist. Diese Nachteile können über die Bereitstellung der Connected Car Multipath Kodierung und Gruppierung als Software-Bibliothek überwunden werden.
4c zeigt ein Flussdiagramm einer Vorgehensweise bei der Übermittlung von Daten über eine Software-Bibliothek, die Connected Car Multipath Kodierung und Gruppierung bereitstellt. In dem Beispiel sollen Anwendungsdaten zu einem anderen Fahrzeug gesendet werden. Die Daten werden gruppiert, so dass sie am besten für die verschiedenen Übertragungspfade kodiert werden können. Danach kann der beste Kodieralgorithmus für den Datentyp ausgesucht werden, und die Daten können über die Multilink-Bibliothek übertragen werden. Dabei können die Daten einerseits auf einem direkten Pfad zu dem anderen Fahrzeug übermittelt werden, oder die Daten können zu einer (Edge-) Cloud übermittelt werden, wo sie zusammen mit den Daten von anderen Fahrzeugen in der Umgebung kombiniert werden können und dem Fahrzeug übermittelt werden können. Das andere Fahrzeug kann die (direkt oder über die (Edge-) Cloud) empfangenen Daten dekodieren.
4d zeigt ein schematisches Diagramm eines Beispiels einer Datenübermittlung über eine (Edge-) Cloud und V2X. In dem Beispiel senden zwei Fahrzeuge A und B Daten an ein Zielfahrzeuge Fahrzeug über (Edge-)Cloud und V2X. In dem Beispiel ist die Annahme, dass Fahrzeug A und Fahrzeug B 5 Pakete in die Cloud übertragen können. Im gleichen Zeitrahmen können beide Fahrzeuge 3 bzw. 2 Pakete auf dem direkten Weg senden. Die (Edge)Cloud fasst die 5 empfangenen Pakete zusammen und sendet sie an das Zielfahrzeug. Das Zielfahrzeug kann aus allen empfangenen 5 A-Paketen und 5 B-Paketen entschlüsseln. Dadurch kann die Übertragung weniger Zeit in Anspruch nehmen, da davon ausgegangen wird, dass dies alles im gleichen Zeitfenster geschehen kann. Fahrzeug A übertrug 2 Pakete weniger auf V2X-Kanal, und Fahrzeug B übertrug 3 Pakete weniger auf dem V2X-Kanal. Dadurch können Ressourcen geschont werden, und die Übertragungszeit kann verkürzt werden.
Grundsätzlich bietet die Implementierung einer Mehrwege-Kodierung durch eine Software-Bibliothek weitere Vorteile. So kann die Software-Bibliothek auf verschiedene Geräte portiert werden, so dass die Cloud-Codierung problemlos mit der Fahrzeug-Codierung zusammenarbeitet. Zudem kann jede Anwendung zwischen verschiedenen Kodierungsschemata wählen. In Kombination mit einem Scheduling-Algorithmus können Anwendungsdaten zur Optimierung der Übertragung für die Codierung gruppiert werden. Zudem kann eine (Edge) Cloud in der Lage sein, Pakete über die Kodierung zu kombinieren, um die Übertragung zu verbessern (die Kodierung kann sogar in die Cloud ausgelagert werden, um Rechenleistung auf dem Fahrzeug zu sparen). Diese Vorteile sind in vielen Fällen nur mit einer Software-Bibliothek erreichbar, da nur so eine bequeme Möglichkeit besteht, ein voneinander abhängiges Kodierungssystem zu haben, das in der Lage ist, intelligente Kodierung in der (Edge-)Cloud und im Fahrzeug durchzuführen
Im Folgenden wird der Fokus auf Connected Car Multipath Access gelegt. Der im Folgenden beschriebene Connected Car Multipath Access basiert auf der Überlegung, eine einfache Möglichkeit für Anwendungen im Connected Car Umfeld eine Multipath Umgebung bereitzustellen und diese anhand der benötigten Kapazitäten zu parametrisieren. Der Connected Car Multipath Access basiert auf den Entwürfen der IETF für Multipath QUIC. Dabei existieren Anforderungen die für ein Multipath-Schema erfüllt werden müssen.
Um keinen weiteren Standard neben (Multipath-)QUIC und (Multipath-)TCP zu etablieren sollen die hier präsentierten Überlegungen auf den Prinzipien der IETF von Multipath QUIC basieren. Multipath QUIC bietet gegenüber Multipath TCP viele Vorteile, da es aus den Problemen von TCP für Multipath Übertragungen gelernt hat und seine Grundprinzipien an die Gegebenheiten der neuen Netzgenerationen mit heterogenen Netzen angepasst hat. Zusätzlich werden die Scheduling Algorithmen mithilfe des Connected Car Schedulings in einem Connected Car Umfeld erweitert, so dass sich eine Möglichkeit der Anwendung in diesem kommunikationskritischen Szenario ergibt. Des Weiteren ergeben sich mit dem Zusammenschluss von Connected Car Kodierung & Gruppierung weitere Synergieeffekte für eine Multipath Übertragung im Connected Car-Umfeld. Zusätzlich zu dem zuvor thematisierten Connected Car Kodierung & Gruppierung, kann eine Schedulingschnittstelle bereitgestellt werden, welche es ermöglicht, neben üblichen Scheduling-Methoden wie Round-Robin (Ringmodell), ein speziell für Connected Car-Anwendungen priorisiertes Scheduling durchzuführen, wie es zuvor im Zusammenhang mit Connected Car Scheduling vorgestellt wurde. Verschiedene Scheduler können als Module eingebunden werden. In Verbindung mit der einfachen Connected Car Kodierung & Gruppierung kann es eine verbesserte Übertragung über mehrere Pfade bieten. Auch die Gruppierung & Kodierung kann als Modul eingebunden werden, so dass es leicht ersetzt werden kann für andere Einsatzgebiete. In einer Empfangseinheit können die Daten der verschiedenen Pfade empfangen, dekodiert und an die Empfangsanwendung zurückgegeben werden. Die Anzahl der physikalischen Schnittstellen, sowie die zu Grunde liegende Übertragungstechnologie sind dabei transparent für den Connected Car Multipath-Zugriff. Dabei kann beispielsweise als Basis auf den Entwurf der „Multipath Extension for QUIC“ (Multipath-Erweiterung für QUIC) zurückgegriffen wird, wie er im Rahmen des IETF diskutiert wird.
Ausführungsbeispiele können eine Steuerung des Datenflusses auf mehreren Übertragungswegen aufgrund von Informationen der physikalischen Übertragungswege bereitstellen, sowie eine Multi-Hop Betrachtung in zellulären Netzen. Dadurch kann eine Automotive Cloud als Weiterleitung für V2X Daten genutzt werden.
5a zeigt ein Diagramm eines allgemeinen Aufbaus eines beispielhaften Connected Car-Schedulers mit Unterstützung für Gruppierung und Kodierung. Dabei kann der Scheduler von 5a als eine Kombination der Konzepte der 2a und 4a gesehen werden. Connected Car-Anwendungen stellen hierbei, ähnlich wie in 2a und 4a gezeigt, Anwendungsdaten und Priorisierungs- /Kontrollinformationen bereit, in diesem Fall einem Connected Car Multipath-Zugriffs-Block, welcher einen Unterblock für die Gruppierung und Kodierung und einen Unterblock für den Connected Car Scheduler umfasst. QUIC-Sender 1 bis N stellen die kodierten Anwendungsdaten den physikalischen Schnittstellen 1 bis N bereit, und geben Parameter wie die Umlaufzeit und den Durchsatz dem Unterblock für die Gruppierung und Kodierung und dem Unterblock für den Connected Car Scheduler bereit.
Die Kombination der beiden Konzepte in einer Software-Bibliothek ermöglicht eine einfache Anwendbarkeit für beliebige Anwendungen, da die Implementierung selbst, als Bibliothek oder Schnittstellen-Anwendung, für Connected Car Anwendungen genutzt werden kann. Außerdem bietet sie eine bedarfsgerechte Verteilung der Daten, basierend auf den Anforderungen der Anwendung.
In anderen Konzepten erfolgt der Multilink-Zugriff meist mit zusätzlicher Hardware für die Link-Aggregation. Diese zusätzliche Hardware führt meist zu zusätzlichen Kosten, und dass der Multilink-Zugriff nicht auf ein Gerät oder eine ECU übertragbar ist. Zudem lässt sich so nicht eine Software schaffen, die auf verschiedenen Steuergeräten eingesetzt werden kann. Zudem sind Messungen auf Hardware-Ebene häufig nicht präzise, da sie nicht Ende-zu-Ende gemessen sind (von der Cloud-Anwendung zu der Geräte-Anwendung oder umgekehrt) sind.
Diese Nachteile lassen sich durch eine Link (Verbindungs)-Aggregations mittels einer Software-Bibliothek für vernetzte Fahrzeuge (Connected Cars) überwinden. 5b zeigt ein schematisches Diagramm eines Beispiels für Verbindungs-Aggregation, die von einer Software-Bibliothek implementiert ist. Dabei werden auf der Senderseite Anwendungsdaten der Software-Bibliothek übergeben. Die Daten werden in Gruppen aufgeteilt und anschließend kodiert. Die kodierten Daten werden Übertragungs-Strömen (engl. transmission streams) zugewiesen, und eine angemessene Verbindung (engl. link) für die Daten wird von dem Scheduler ausgewählt. Die Daten werden über UDP übertragen, und von Seiten der Cloud über UDP empfangen. Die Daten werden von der Cloud dekodiert und verarbeitet.
5c zeigt ein beispielhaftes Diagramm der Nutzung einer Multipath-Zugriffs-Software-Bibliothek zum Hochladen (engl. upload) von Dateien in vernetzten Fahrzeugen. Dabei wird eine Datei (die in dem Beispiel 3 Megabyte groß ist) einem Gruppierungs-Block übergeben. Dort wird die vollständige Datei aufgeteilt (in jeweils 1 Megabyte) und drei Gruppen (1 bis 3) zugewiesen. In einem nachfolgenden Kodierungs-Block werden die Daten jeder Gruppe kodiert und in Pakete aufgeteilt. Damit werden die Daten unabhängig von dem Empfangspfad gemacht. In einem nachfolgenden Scheduler-Block wird ein Link gemäß den Anforderungen, wie etwa maximale Datenrate, ausgewählt. Dabei sind mögliche Kriterien beispielsweise die maximale Datenrate, die niedrigste Latenz, die höchste Sicherheit oder die geringste Versagensrate (engl. failure rate). Dabei können mehrere Links verwendet werden, um die Daten in die Cloud zu übertragen, so dass deren Datenraten (etwa 5 MBit/s und 5 MBit/s) aufaddiert werden können (auf 10 MBit/s).
Die Nutzung einer Software-Bibliothek für Multipath-Zugriff hat verschiedene Vorteile. So ist der Multipath-Zugriff ohne Hardware-Änderungen auf verschiedene Geräte übertragbar. Zudem fallen keine Zusatzkosten für spezielle Hardware an. Die Bibliothek ist verwendbar in verschiedenen Anwendungen (etwa im Auto, in der Cloud und auf dem Smartphone). Die Software-Bibliothek kann für jede Anwendung genau konfiguriert werden. Zudem sind keine zusätzlichen Messungen erforderlich und vorausgesetzt, die Messungen sind Ende-zu-Ende-Messungen (d.h. die Messungen basieren genau auf den Übertragungsparametern, denen eine Anwendung ausgesetzt sein wird). Diese Vorteile sind beispielsweise (nur) mit einer SoftwareLösung erreichbar, da Hardware nicht portiert werden kann und keine Ende-zu-Ende-Parameter messen kann.
Im Folgenden liegt der Fokus auf Connected Car Cellular Device to Device (Gerät-zu-Gerät)-Datenübertragungen.
Zelluläre Netzinfrastrukturen, wie etwa Mobilfunk, besitzen Filterregeln, die eine Kommunikation zwischen Geräten nur erschwert zulassen. Dies bedeutet, dass für eine Gerät-zu-Gerät-Kommunikation über zelluläre Netze eine Anpassung der Filterregeln durch den Netzbetreiber nötig sein kann. Mit der Verwendung von Netzen neuerer Generationen ist die Latenz über zelluläre Netze immer weiter gesunken und für 5G Netze werden Latenzen anvisiert, die Echtzeitanwendungen zulassen. Mithilfe von Automotive (Edge-)Clouds können diese Art von Zugangsnetzen für Gerät-zu-Gerät-Kommunikation ohne Änderung der Filterregeln durch Netzbetreiber genutzt werden. Zu diesem Zweck können Daten an eine Automotive (Edge-)Cloud Übertragen und weitergeleitet werden. Das hierzu verwendete Protokoll kann in der Cloud anhand von Priorisierungsdaten entscheiden ob eine Weiterleitung sinnvoll ist und welche Fahrzeuge die empfangenen Daten benötigen (etwa als Uni- oder Multicast-Übertragungen). Durch die Verwendung von GPS in Connected Car-Einheiten ist eine genaue Bestimmung der einzelnen Fahrzeuge und damit die Entscheidung über die Relevanz der in der Cloud empfangenen und weiterzuleitenden Daten möglich. Durch die Verwendung von Connected Car Multipath Access in einer Automotive (Edge-) Cloud ist es somit möglich V2X Daten anhand einer Priorisierung zu übertragen und über die Weiterleitung zu entscheiden. Die Kodierungsmöglichkeiten des Protokolls erlauben es außerdem die direkte Kommunikation zwischen den Fahrzeugen zu verbessern, da neu kodierte Datenpakete in Verbindung mit dem Empfang von lokalen Daten zusätzliche Informationen übertragen können. Dieses Verfahren entlastet gegebenenfalls lokale Fahrzeugübertragungstechnologien wie beispielsweise IEEE 802.11 p, da diese ebenfalls über zelluläre Netze ausgetauscht und weitergeleitet werden können.
6a zeigt eine schematische Übersicht einer Nutzung einer Automotive (Edge-)Cloud und zellulären Netzen zur Entlastung von lokalen Fahrzeugübertragungstechnologien wie beispielsweise IEEE 802.11 p. Dabei kann etwa die Connected Car-Einheit von 5a verwendet werden, um Daten an die Automotive (Fahrzeug-) Edge-Cloud zu übertragen. Auch dort kann ein Connected-Car Multipath-Zugriff über eine Software-Bibliothek bereitgestellt werden, um Daten den vernetzten Fahrzeugen bereitzustellen, mit einem Block für die Connected Car Gruppierung und Kodierung sowie einem Block für den Connected Car Scheduler und einem Block für den QUIC-Sender. Dabei kann eine Dienst-Identifikation, GPS-Daten und die Umlaufzeit (letzteres von dem QUID-Sender) als Parameter von dem Connected Car Scheduler verwendet werden. Dabei können WLAN Mesh Ideen in ein V2X Umfeld portiert werden.
6b zeigt eine Einschränkung in der Kommunikation zwischen Fahrzeugen in einer zellularen Fahrzeugumgebung. Die Kommunikation zwischen zwei Fahrzeugen ist in einer zellularen Fahrzeugumgebung (aufgrund von Provider-Einstellungen) häufig nicht möglich, im Gegensatz zu der direkten V2X-Kommunikation.
Dabei kann die Kommunikation zwischen zwei Fahrzeugen in einer zellularen Fahrzeugumgebung vorteilhaft sein. V2X-Verkehr kann so auf das Mobilfunknetz ausgelagert werden. Das Auslagern des V2X-Verkehrs mit der richtigen Priorisierung ermöglicht es, Ressourcen in der V2X-Umgebung freizusetzen und gleichzeitig die V2X-Kommunikation selbst zu verbessern (durch Erhöhung der Datenrate, Senkung der Latenz etc.) Dies ist besonders vorteilhaft in überfüllten Umgebungen, in denen die V2X-Ressourcen durch Staus auf Autobahnen oder in Städten stark belastet sind.
Um diese Vorteile nutzen zu können, kann die V2X-Kommunikation mit Hilfe einer (Edge-)Cloud-Umgebung auf das zellulare Netz ausgelagert (engl. offloading) werden. 6c zeigt ein beispielhaftes Flussdiagramm einer Auslagerung von V2X-Kommunikation mit Hilfe einer Edge Cloud. In dem Beispielsind V2X zu einem anderen Fahrzeug übermittelt werden. Dabei können empfangene Daten einerseits kodiert werden und direkt zu anderen Fahrzeugen in der Umgebung übermittelt werden. Andererseits können die Daten zu einer (Edge-) Cloud übermittelt werden. Die (Edge-) Cloud die anderen vernetzten (verbundenen) Fahrzeuge, kodiert die empfangenen Daten, und leitet die Daten zu den Fahrzeugen in der Umgebung weiter. Die Fahrzeuge in der Umgebung dekodieren die über die beiden Wege empfangenen Daten.
6d zeigt ein Beispiel einer Software-Bibliothek mit Mehrwege-Zugriff für einen Datei-Upload in vernetzten Fahrzeugen. In dem Beispiel sind vier Fahrzeuge vertreten, Fahrzeuge A bis D. Fahrzeug A kommuniziert mit den anderen Fahrzeugen über direkte V2X-Kommunikation und über ein zelluläres Mobilfunksystem und die (Edge-)Cloud. Sensordaten von Fahrzeug A werden direkt an andere umgebende Fahrzeuge übertragen. Die Bibliothek der (Edge) Cloud verwaltet die Kommunikation zwischen Fahrzeug A und umliegenden Fahrzeugen im Mobilfunknetz. Auch hier hat die Nutzung einer Software-Bibliothek für die zellulare Fahrzeug-zu-Fahrzeug-Kommunikation Vorteile. So ist die Software-Bibliothek möglicherweise ohne Hardware-Änderungen auf verschiedene Geräte übertragbar, so dass keine Zusatzkosten für spezielle Hardware entstehen. Kodierungsalgorithmen, die als Software implementiert sind, sind hochgradig anpassungsfähig und können in der (Edge-)Cloud und im Fahrzeug verwendet werden. Die Entscheidungsfindung (Kommunikation über die Edge-Cloud oder nicht) kann auf Anwendungsebene entschieden werden. Zudem können intelligente Kodierungsalgorithmen in der (Edge-)Cloud oder im Fahrzeug zur Verbesserung der Kommunikation durch Bündelung von Daten eingesetzt werden. Eine Ende-zu-Ende-Verfolgung der Übertragungsparameter (z.B. Latenz, Datenrate) ist wünschenswert, um zu ermöglichen, dass das Offloading gut funktioniert. Dies bedeutet, dass der gesamte Übertragungsweg verfolgt werden sollte (Fahrzeug -> (Edge-)Cloud -> Fahrzeug). Dies ist (nur) mit einer Softwarelösung zu erreichen, die im Fahrzeug und in der Cloud die gleichen Codierungs- und Multilink-Scheduling-Algorithmen bereitstellt, um zu ermöglichen, dass die Bereitstellung einfach und portabel ist und den Ende-zu-Ende-Übertragungsweg verfolgt.
Grundsätzlich lassen sich die zuvor vorgestellten Konzepte auch auf andere Geräte und Szenarien anwenden, etwa auf die Verbesserung von loT (Internet of Things, Internet der Dinge)-Anwendungen wie ferngesteuerte Roboter.
Ein weiteres Ausführungsbeispiel ist ein Computerprogramm zur Durchführung zumindest eines der oben beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor oder einer programmierbaren Hardwarekomponente abläuft. Ein weiteres Ausführungsbeispiele ist auch ein digitales Speichermedium, das maschinen- oder computerlesbar ist, und das elektronisch lesbare Steuersignale aufweist, die mit einer programmierbaren Hardwarekomponente so zusammenwirken können, dass eines der oben beschriebenen Verfahren ausgeführt wird.
Die in der vorstehenden Beschreibung, den nachfolgenden Ansprüchen und den beigefügten Figuren offenbarten Merkmale können sowohl einzeln wie auch in beliebiger Kombination für die Verwirklichung eines Ausführungsbeispiels in ihren verschiedenen Ausgestaltungen von Bedeutung sein und implementiert werden.
Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar.
Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-Ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einer programmierbaren Hardwarekomponente derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird.
Eine programmierbare Hardwarekomponente kann durch einen Prozessor, einen Computerprozessor (CPU = Central Processing Unit), einen Grafikprozessor (GPU = Graphics Processing Unit), einen Computer, ein Computersystem, einen anwendungsspezifischen integrierten Schaltkreis (ASIC = Application-Specific Integrated Circuit), einen integrierten Schaltkreis (IC = Integrated Circuit), ein Ein-Chip-System (SOC = System on Chip), ein programmierbares Logikelement oder ein feldprogrammierbares Gatterarray mit einem Mikroprozessor (FPGA = Field Programmable Gate Array) gebildet sein.
Das digitale Speichermedium kann daher maschinen- oder computerlesbar sein. Manche Ausführungsbeispiele umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem oder einer programmierbare Hardwarekomponente derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird. Ein Ausführungsbeispiel ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Programm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Programm, Firmware, Computerprogramm oder Computerprogrammprodukt mit einem Programmcode oder als Daten implementiert sein, wobei der Programmcode oder die Daten dahin gehend wirksam ist bzw. sind, eines der Verfahren durchzuführen, wenn das Programm auf einem Prozessor oder einer programmierbaren Hardwarekomponente abläuft. Der Programmcode oder die Daten kann bzw. können beispielsweise auch auf einem maschinenlesbaren Träger oder Datenträger gespeichert sein. Der Programmcode oder die Daten können unter anderem als Quellcode, Maschinencode oder Bytecode sowie als anderer Zwischencode vorliegen.
Ein weiteres Ausführungsbeispiel ist ferner ein Datenstrom, eine Signalfolge oder eine Sequenz von Signalen, der bzw. die das Programm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom, die Signalfolge oder die Sequenz von Signalen kann bzw. können beispielsweise dahin gehend konfiguriert sein, um über eine Datenkommunikationsverbindung, beispielsweise über das Internet oder ein anderes Netzwerk, transferiert zu werden. Ausführungsbeispiele sind so auch Daten repräsentierende Signalfolgen, die für eine Übersendung über ein Netzwerk oder eine Datenkommunikationsverbindung geeignet sind, wobei die Daten das Programm darstellen.
Ein Programm gemäß einem Ausführungsbeispiel kann eines der Verfahren während seiner Durchführung beispielsweise dadurch umsetzen, dass dieses Speicherstellen ausliest oder in diese ein Datum oder mehrere Daten hinein schreibt, wodurch gegebenenfalls Schaltvorgänge oder andere Vorgänge in Transistorstrukturen, in Verstärkerstrukturen oder in anderen elektrischen, optischen, magnetischen oder nach einem anderen Funktionsprinzip arbeitenden Bauteile hervorgerufen werden. Entsprechend können durch ein Auslesen einer Speicherstelle Daten, Werte, Sensorwerte oder andere Informationen von einem Programm erfasst, bestimmt oder gemessen werden. Ein Programm kann daher durch ein Auslesen von einer oder mehreren Speicherstellen Größen, Werte, Messgrößen und andere Informationen erfassen, bestimmen oder messen, sowie durch ein Schreiben in eine oder mehrere Speicherstellen eine Aktion bewirken, veranlassen oder durchführen sowie andere Geräte, Maschinen und Komponenten ansteuern.
Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein funktionales Merkmal, ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden funktionalen Merkmals, Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar.
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.
Bezugszeichenliste

10: Kommunikationseinrichtung
12: Schnittstelle
14: Ein oder mehrere Prozessoren
100: Fahrzeug
110: Erhalten von Daten
112: Empfangen eines Teils der Daten
114: Dekodieren der empfangenen Daten
120: Bestimmen einer Qualitätsanforderung
130: Gruppieren der Daten
140: Kodieren der Daten
150: Auswählen eines Übertragungswegs
160: Weitergeben der Daten
300: Fahrzeug
310: Mobiles Endgerät
320: Backend
330a; 330b: Geräte
340: Medienzugriff- und tiefere Schichten
342: UDP-Ströme
344: QUIC-Strom-Kontrollblock
346: Dekodierungs- und Degruppierungsblock
348: Anwendungsdaten
350: Anwendungsdaten
352: Gruppierungs-Block
354: Gruppen
356: Netzwerk-Kodierungsblöcke
358: Multipath-QUIC-Block
360: Connected Car Multipath Scheduler
362: Datenstau-Kontrollblöcke

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 2018/211488 A1 [0003]
WO 2018/64179 A1 [0003]
US 20190037349 A1 [0065]

Claims

Computer-implementiertes Verfahren für ein Fahrzeug, wobei das Verfahren durch eine Software-Zwischenschicht, die auf einem Prozessor des Fahrzeugs ausgeführt wird, durchgeführt wird, das Verfahren umfassend: Erhalten (110) von Daten zum Übermitteln an ein oder mehrere weitere Fahrzeuge; Bestimmen (120) einer Qualitätsanforderung für die Übermittlung der Daten; Auswählen (150) eines Übertragungswegs einer Mehrzahl von Übertragungswege basierend auf der Qualitätsanforderung für die Übermittlung der Daten, wobei sich die Mehrzahl von Übertragungswege bezüglich der auf dem Übertragungsweg genutzten Übertragungstechnologie oder bezüglich der auf dem Übertragungsweg genutzten Zwischenschritte unterscheiden; und Weitergeben (160) der Daten an ein Sende-Empfängermodul des Fahrzeugs, das mit dem ausgewählten Übertragungsweg assoziiert ist, zum Übermitteln der Daten über den ausgewählten Übertragungsweg.
Das Verfahren gemäß Anspruch 1, wobei die Daten als Datenpaket oder Sequenz von Datenpaketen erhalten werden, wobei für Daten, die für das gleiche Fahrzeug bestimmt sind und der gleichen Sequenz von Datenpaketen entstammen, der gleiche Übertragungsweg ausgewählt wird.
Das Verfahren gemäß einem der Ansprüche 1 oder 2, wobei zumindest einer der Übertragungswege auf einer Übertragung über mehrere Zwischenschritte basiert.
Das Verfahren gemäß einem der Ansprüche 1 bis 3, wobei zumindest einer der Übertragungswege auf einer Übertragung über eine Edge-Cloud basiert.
Das Verfahren gemäß einem der Ansprüche 1 bis 4, wobei zumindest einer der Übertragungswege auf einer Übertragung über einen Internetdienst basiert.
Das Verfahren gemäß einem der Ansprüche 1 bis 5, wobei die Daten als Datenpaket oder Sequenz von Datenpaketen erhalten werden, wobei das Datenpaket oder die Sequenz von Datenpaketen auf dem Quick User Datagram Protocol Internet Connections-Protokoll basiert.
Das Verfahren gemäß einem der Ansprüche 1 bis 6, wobei die Daten von ein oder mehreren Fahrzeugdiensten zur Koordination von Fahrzeugen stammen, wobei jedem Fahrzeugdienst eine Qualitätsanforderung zugewiesen ist, wobei die Qualitätsanforderung für die Übermittlung der Daten basierend auf der Qualitätsanforderung, die dem jeweiligen Fahrzeugdienst, von dem die Daten stammen, zugewiesen ist, bestimmt wird.
Das Verfahren gemäß einem der Ansprüche 1 bis 7, wobei das Erhalten der Daten ein Empfangen (112) zumindest eines Teils der Daten von einem weiteren Fahrzeug umfasst.
Das Verfahren gemäß Anspruch 8, wobei die empfangenen Daten bis zu einem vordefinierten Zeitpunkt gültig sind, wobei die empfangenen Daten weitergeleitet werden, falls die Daten nach dem Übermitteln der Daten über den ausgewählten Übertragungsweg voraussichtlich noch gültig sind.
Das Verfahren gemäß einem der Ansprüche 1 bis 9, wobei die Software-Zwischenschicht eine Software-Bibliothek zur Nutzung in einer Kommunikationseinrichtung eines Fahrzeugs ist.
Das Verfahren gemäß einem der Ansprüche 1 bis 10, ferner umfassend Gruppieren (130) der Daten gemäß der Qualitätsanforderung und gemäß einem Ziel der Daten, und Kodieren (140) der Daten gemäß der Gruppierung der Daten, wobei Daten einer Gruppe zusammen kodiert werden, wobei die kodierten Daten an das Sende-Empfängermodul des Fahrzeugs weitergegeben werden.
Das Verfahren gemäß Anspruch 11, wobei die Daten basierend auf einer linearen Netzwerk-Kodierung kodiert werden.
Das Verfahren gemäß einem der Ansprüche 11 oder 12, wobei die Daten so dem Sende-Empfängermodul des Fahrzeugs weitergegeben werden, dass Daten, die zusammen gruppiert und kodiert wurden, zusammen über den gleichen Übertragungsweg übermittelt werden.
Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß einem der vorhergehenden Ansprüche, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
Kommunikationseinrichtung (10) für ein Fahrzeug (100), die Kommunikationseinrichtung umfassend: eine Schnittstelle zur Kommunikation mit ein oder mehreren Sende-Empfängermodulen (16) des Fahrzeugs; und ein oder mehrere Prozessoren (14), ausgebildet zum Ausführen des Verfahrens gemäß einem der Ansprüche 1 bis 13 durch Bereitstellen der Software-Zwischenschicht.