von der Ohe

Co-Founder, CEO


You come across an opportunity to positively impact societies around the globe maybe once in your lifetime. An opportunity to truly make a difference. Our unique approach to autonomous driving gives us this chance: redefining how people move in a better way. Building and shipping a product with this great team is what drives me day and night.


Launched Zoox’ first self-driving vehicle on public streets as leading Technical Program Manager in Silicon Valley, launched Amazon’s first Echo as leading Technical Program Manager on Device Software, Founded two (funded) mobility companies. M. Sc. Management Science and Engineering, Stanford University.


Co-Founder, VP Engineering


Building products together with an amazing team based on cutting-edge technology to serve a greater purpose and solve problems – for the people, for our planet.


Manager of an engineering team in Silicon Valley to build autonomous shuttles, built teams and various mobility products: electric race cars, e-motorcycles, light electric vehicles, electric passenger vehicles, including one of the most successful electric delivery vehicles in Germany. RWTH Aachen, Imperial College London.


Co-founder, Director Teledrive Experience


Vay is aiming to launch the first vehicle without a safety driver on public roads in Europe. This involves exciting engineering challenges, many of which have never been worked on before, ranging from autonomous vehicle technology, cybersecurity, backend, machine learning and safety-critical SW. Coming up with engineering solutions to these topics is something that I’m super excited to work on at Vay.


Team Lead at Microsoft, Senior Software Engineer at Skype. M. Sc. in Computer Science from Belgrade University.


Director of Engineering Operations


Working closely with people from different cultures and professional backgrounds (hardware, software, operations, etc.) gives me the chance to learn new ways of approaching projects, structuring teams, and setting up processes every day. The results of this incredible teamwork are hugely rewarding, and visible in each step of our product.


Part of the management circle at AUDI AG, responsible for the implementation of prototypes at early development stages of new products (innovation vehicles, concept and pre-series vehicles, show cars, design models, testing single parts, PoCs, 3D-printing)


Director of Safety


All my professional life I have been working for the protection and safety of people and the environment. I want to further provide safe and user-friendly automation systems for our future mobility needs.


25+ years experience in system safety at Conti., Mando, Bosch. Led the VDA working group in Germany to create ISO 26262 and influenced worldwide safety standardization. Author of several text books on functional safety.


VP - Business & Corporate Development


What drives me is to work on goals that have a big impact on society. Additionally, I wanted to work with the smartest and most innovative people in the tech world. That’s better at Vay than any other company I’ve spoken to recently.


Was CEO and chief growth officer at Quirk. Began his professional life at Morgan Stanley as a fixed income trader after studying economics and finance. Built the first startup incubator in Africa in 2002 and has been mentoring founders of technology startups for over ten years. He is an angel investor in software technology and holds board positions in some of these companies.


VP - Product Design and Brand


Building the future of mobility, which is sustainable and truly serving the needs of people, by creating a holistic experience, a relatable brand and shaping services that are going to make a difference to how we move within and between cities.


Head of Global Design at N26, Senior Lead Designer at IDEO, in-car interactions for Volkswagen.


Senior Principal Software Engineer


After having worked in autonomous robotics research for a long time in the Silicon Valley, I am thrilled to be working at a company that is finally bringing this technology into people’s everyday lives.


Tech Lead at Google Tango in Mountain View, Research Engineer at Willow Garage, yoga instructor since 2018.


Director of Software Engineering


Helping engineers to do their best and most important work. Elegance in software. Bringing ideas from books to real life and from one domain to another. Going from A to B fast.


Software Generalist. Maps and Mobility Geek (Lon, Lat not Lat, Lon). High Load at Yandex, Geo Analytics and Last Mile at HERE Maps, Mobility Platform at Daimler. Conway’s Law Enthusiast.




A car enthusiast, driven by cars, driving and technology.


Nursery school teacher. Driver at Skoda’s start-up Caredriver.

Deep Dive: How to Break the Congestion Barrier – Achieving low latency with high throughput for safe teledriving

As the world becomes increasingly connected, the demand for fast and reliable internet connectivity has never been greater. From streaming high-definition video to cloud gaming, remote surgery and of course teledriving, there are countless applications that require high bandwidth and low latency (in the order of tens of milliseconds). Maintaining low latency is especially challenging when the network is congested. 

Congestion control algorithms are a crucial part of internet transport protocols and determine how the sending applications adapt the rate of data sent into the network based on indicators of congestion such as packet loss and/or delay. It is desirable to maximize link utilization while keeping latency low. In loss-based congestion control algorithms, packet loss is used as a signal for congestion control to reduce the sending rate. A later extension to TCP/IP called Explicit Congestion Notification (ECN) [1] does not rely on packet loss and indicates congestion by marking certain bits in the IP header. It was standardized in the early 2000s but found limited deployment on the internet [2][3]. As a follow-up of ECN, the internet Engineering Task Force (IETF) came up with L4S.

What is L4S?

L4S is short for Low Latency, Low Loss, and Scalable throughput. In January 2023, the IETF approved a publication called RFC9330 [4] that explains how to achieve low latency even when dealing with high-throughput applications, such as video streaming. It repurposes the bits in the IP header that are used for ECN. The goal is to make sure that this method is compatible with existing internet congestion control mechanisms.
Before L4S, current Active Queue Management (AQM) algorithms in network devices may still result in latencies of several 100ms [4], which is not desirable in applications such as online gaming, conversational video applications and teledriving. It is crucial to highlight that L4S can be applied to any network, not just mobile networks.

How does L4S work?

L4S builds on top of ECN. Once the latency of L4S enabled queues in the Radio Access Network (RAN) exceeds a predefined threshold (typically a value of 4ms is used), packets are gradually marked with Congestion-Experienced (CE) markings indicating the early onset of congestion. The probability of packets that are marked increases until the queue delay reaches an upper threshold, where all packets are marked. The CE markings are received by the receiver application and this information is sent back to the sender over transport protocol feedback such as RTCP [7] so that the sender can adapt the sending bitrate accordingly. Failure to do so may result in additional delay, which depending on the application may need to be avoided.

Mobile Networks & L4S

Mobile network infrastructure is usually designed for achieving high download rates, while uploads are traditionally less important. In the past couple of years, live streaming services such as Twitch and Youtube live have become more prevalent, and these types of services also have high upload rate requirements. One of the main sources of jitter variation in mobile networks occurs in the RAN either due to congestion or some other factor characterized by RAN such as scheduling jitter, or handover [5]. This is why it is becoming increasingly important for mobile network operators to  provide a more reliable network. The L4S approach provides finer-grained congestion information allowing the application to react and adapt its bit rate accordingly.

Teledriving and mobile network requirements

One core component of any teledriving technology is the video streaming over mobile networks. A good teledriving experience requires certain video quality and latency. While 4G and 5G already support the video quality or latency required for teledriving (Vay has already received permission to drive on public roads without a person inside the car []), L4S helps deal with network congestion events and increases the quality of the video stream thanks to the explicit feedback of buffer build up at the radio interface, which is usually the bottle neck in mobile applications. Eventually, L4S may also reduce the number of redundant networks without jeopardizing safety.  

Vay, Deutsche Telekom, Ericsson & L4S

In the joint work with Deutsche Telekom and Ericsson, Vay explored the benefits of managed latency using L4S and the SCReAM congestion control algorithm [6] for teledriving. SCReAM is a congestion control algorithm standardized for real-time conversational video. The SCReAM implementation is based on the open source code available from [9].

Vay’s technology stack uses multiple mobile networks to handle potential connectivity problems that might occur in practice: if one network fails, the signal can still be received via another mobile network. Furthermore, the connection between the vehicle and the teledriver is continuously monitored and if issues occur which trouble safe control of the vehicle by the teledriver, the vehicle automatically conducts a so-called Minimum Risk Manoeuvre (MRM).

For the showcase with Deutsche Telekom and Ericsson, Vay explored driving on a single mobile network, but using the L4S technology to be able to detect congestion early.

The result of the collaboration was showcased at the 2023 Mobile World Congress, where a car was teledriven in our testing center in Tegel (part of the Urban Tech Republic facilities in Berlin) from Barcelona. The data traffic was routed via Sweden and London amounting to a total of about 5000 kms between Barcelona and Berlin. The benefits of using L4S were strongly evident: 

  1. The overall latency was low and stable even after adding background traffic to the cell that simulated the presence of other users of the mobile network, e.g. downloading or streaming movies or having video calls. 
  2. In spite of the distance between the car and the teledriver (over 5000 kms), teledriving was feasible.
  3. L4S decreased the level of network redundancy.

Results of teledriving using L4S and SCReAM at MWC

This section will dive into the details and analyze the results of teledriving with one mobile network from Barcelona in Berlin, via Sweden and London (5000 kms apart), with and without L4S. (Due to the large distances involved, the results presented in this article are not representative of what Vay experiences during daily operations.)

For this analysis the focus is on two key elements:

  • Video frame latency: it is defined as the latency from the time an image is captured by the camera sensor until it is rendered on the screen for the teledriver. The higher the frame latency or the greater the variation in image latency, the more difficult it is for the teledriver to operate the vehicle remotely. 
  • Queue delay: it represents the amount of time the packets are buffered in the network. It is estimated by SCReAM.

Figure 1 shows the frame latency measured at the receiver during queue delay build up which is shown in figure 2. Without L4S, denoted in blue, it can be observed that the queues contain more than one second of delay, even though the SCReAM algorithm has been designed to detect congestion in the network and adapt the bitrate accordingly. This is because SCReAM uses over the top heuristics to adapt the bitrate unlike L4S which is part of the network. In Vay’s teledriving application, such latency spikes would trigger an MRM, as it is no longer safe to operate the vehicle remotely.

In contrast, the red line in figure 1 shows the video frame latency measured when the network supports L4S. Here, it can be observed that the frame latency never exceeds 200ms. That there are no spikes, and that the frame latency variation is much smaller. 

Figure 1: video frame latency during queuing in the base station

Figure 2: queueing delay estimated by SCReAM

In Figure 2, the red line also shows how the queuing delay is kept in a controlled, much smaller range, whereas without L4S the queueing delay often exceeds a second. The SCReAM algorithm, with the support of the network i.e. L4S is able to detect congestion earlier and can therefore make swifter and more accurate rate adjustments to maintain a low latency.

Challenges ahead and next steps

Beyond the advantages of L4S, presented in this article, it is the time to look at the future and how L4S can be broadly used in commercial networks.

For a massive adoption of L4S, it is important that all the networking equipment in the path does not clear (also known as bleaching) the ECN bits in the IP packets. Bleaching effectively prevents the adoption of L4S. According to [8] the clearing of the ECN bits amounts to 10.8%. The silver lining is that service providers and mobile network operators are in control of this and can prevent it.

Additionally, not all the networking equipment in the path needs to implement L4S, i.e. to toggle the ECN bits when congestion is detected, it is sufficient to implement L4S in the bottleneck node, which is likely on the RAN.

Beyond SCReAM, other congestion control algorithms that already support L4S and will further boost the ecosystem are TCP prague [10], Apple QUIC [11] or BBRv2 (Bottleneck. Bandwidth and Round-trip time) [12].

As outlined in this article, L4S is a promising technology that can improve the performance of real-time applications such as gaming or remote driving that require reliable and low-latency connectivity. With ongoing research and development, L4S is expected to become more widely available and adopted, opening up new opportunities for innovation and growth in various industries. Overall, L4S represents a significant step forward in the evolution of the internet.


[1] , K. Ramakrishnan, S. Floyd and D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC3168, 2001

[2] B. Trammell, M. Kühlewind, D. Boppart, I. Learmonth,  G. Fairhurst and R. Scheffenegger. (2015). “Enabling Internet-Wide Deployment of Explicit Congestion Notification”. 8995. 193-205. 10.1007/978-3-319-15509-8_15.

[3] A. M. Mandalari, A. Lutu, B. Briscoe, M. Bagnulo and O. Alay, “Measuring ECN++: Good News for ++, Bad News for ECN over Mobile,” in IEEE Communications Magazine, vol. 56, no. 3, pp. 180-186, March 2018, doi: 10.1109/MCOM.2018.1700739.

[4] B. Briscoe, K. De Schepper, M. Bagnulo and G. White, “Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture”, RFC9330, 2023

[5] Deutsche Telekom and Ericsson, “Enabling time-critical applications over 5G with rate adaptation”, White Paper, 2021

[6] I. Johansson and Z Sarker, Self-Clocked Rate Adaptation for Multimedia, RFC8298, 2017

[7] , M. Westerlund,  I. Johansson, C. Perkins, P. O’Hanlon and K. Carlberg, Explicit Congestion Notification (ECN) for RTP over UDP, RFC6679, 2012

[8] Hyoyoung Lim, Seonwoo Kim, Jackson Sippe, Junseon Kim, Greg White, Chul-Ho Lee, Eric Wustrow, Kyunghan Lee, Dirk Grunwald and Sangtae Ha, A fresh look at ECN Traversal in the Wild, 2022


[10] Bob Briscoe, Koen De Schepper, Olivier Tilmans, Mirja Kuhlewind, Joakim Misund, Olga Albisser and Asad Sajjad Ahmed, Implementing the ’Prague Requirements’, for Low Latency Low Loss Scalable Throughput (L4S)

[11] Reduce networking delays for a more responsive app, 

[12] BBR2, 

Related Stories

Deep Dive: How Design shapes the Future of a Tech-driven Product (Part 2)

Meet Caleb Varner, our US General Manager!

Deep Dive: How to hire successfully