Automated Valet Parking: Telekom und BMW testen 5G Network Slicing beim Parken

Nicolas La Rocco
39 Kommentare
Automated Valet Parking: Telekom und BMW testen 5G Network Slicing beim Parken
Bild: Deutsche Telekom

Bei der Deutschen Telekom in Berlin haben der Netzbetreiber, BMW, Valeo, Ericsson und Qualcomm erfolgreich eine automatisierte Fahrfunktion demonstriert, die im 5G-Standalone-Netz das Network Slicing mit einer kontrollierten Netzqualität (QoS) nutzte. Die Funktionen kamen für das Automated Valet Parking (AVP) zum Einsatz.

Das Automated Valet Parking ist ein Vorgang des automatisierten und fahrerlosen Parkens, das in Berlin in einem Parkhaus der Telekom in der Winterfeldtstraße durchgeführt wurde. Grundsätzlich neu ist diese automatisierte Fahrfunktion nicht, haben doch bereits 2017 Mercedes-Benz und Bosch ein System dieser Art getestet und 2019 eine Zulassung dafür im Parkhaus des Stuttgarter Mercedes-Benz Museums erhalten.

5G Standalone noch in der Erprobung

Die Demonstration von Telekom, BMW, Valeo, Ericsson und Qualcomm soll allerdings die weltweit erste ihrer Art gewesen sein, bei der die Datenübertragung im 5G-Standalone-Netz samt Quality of Service unter Verwendung der noch frischen API „Quality on Demand“ und der Funktion „User Equipment Route Selection Policy“ (URSP) durchgeführt wurde. Die Telekom betreibt ihr 5G-Standalone-Netz (5G SA) derzeit testweise, hat es aber noch nicht für Endverbraucher geöffnet. Bei 5G SA wird kein LTE-Anker mehr für die Einwahl ins Netz benötigt, alle Dienste laufen demnach über 5G ab. Vodafone ist einen Schritt weiter und bietet 5G SA bereits für Endkunden an.

5G Non-Standalone im Vergleich zu 5G Standalone
5G Non-Standalone im Vergleich zu 5G Standalone (Bild: Deutsche Telekom)

Network Slicing für mehrere logische Netze

Das Network Slicing ist eine für 5G entwickelte Funktion, mit deren Hilfe sich ein physisches Netz in mehrere logische Netze, die sogenannten Slices, unterteilen lässt, in denen sich dann garantierte Zusagen etwa für Geschwindigkeit, Latenz oder Verfügbarkeit machen lassen. Bei einem autonomen Fahrzeug kann das Feature zum Beispiel für komplementäre Funktionen genutzt werden, etwa wie in diesem Szenario für das Automated Valet Parking. Ein autonomes Fahrzeug muss das Fahren auf der Straße allerdings auch ohne Internet beherrschen können, um dem Namen gerecht zu werden.

Quality on Demand in Aktion

Wie die Telekom erklärt, konnte sich das Auto im Rahmen der Demonstration über die URSP-Funktion dynamisch mehrere Slices gleichzeitig auswählen und sich mit diesen verbinden. Über die API „Quality on Demand“ erfolgte der Zugang zu Netzwerk-Eigenschaften, um ein definiertes QoS-Level vom Netzwerk anzufordern. Diese Netzwerk-API wurde im Februar dieses Jahres parallel zur erstmaligen Vorstellung des AVP-Projekts zum MWC angekündigt und im Vorfeld bereits erfolgreich für das Automated Valet Parking getestet. Quality on Demand ist außerdem die erste Schnittstelle, die innerhalb der CAMARA-Initiative standardisiert wurde, die von der GSMA ebenfalls zum MWC angekündigt wurde, und die Netzwerk-APIs weltweit standardisieren soll.

Zusätzlicher Slice für kritische Datenübertragung

Konkret wurde bei der Datenübertragung für das automatisierte Parken zunächst eine Ad-hoc-Anfrage zur Leistungsverbesserung in einem Enhanced Mobile Broadband (eMBB) Slice angefragt. Kurze Erklärung: eMBB ist der normale, für jedermann zugängliche öffentliche Datenkanal in einem 5G-Netz. Die URSP-Funktion ermöglicht die Auswahl von Slices auf der Geräteseite entsprechend der Verfügbarkeit von Slices auf der Netzwerkseite. Das eigentliche Network Slicing fand anschließend über die Zuweisung kritischer Daten an einen hochwertigen Slice und nicht kritischer Daten an den regulären eMBB-Slice statt. Die Messergebnisse sollen laut Telekom ergeben haben, dass die automatisierte Fahrfunktion durchweg mit den erforderlichen Bandbreitenressourcen versorgt wurde. Das habe auch unter überlasteten Bedingungen funktioniert, bei denen sich viele Nutzer die begrenzten Ressourcen des Mobilfunknetzes teilen.

25 Jahre ComputerBase!
Im Podcast erinnern sich Frank, Steffen und Jan daran, wie im Jahr 1999 alles begann.