Today, most of the safety and efficiency features in vehicles are supported by on-board sensors, which are limited to visual line-of-sight. Connectivity offers a good complement to the on-board sensors by extending the vision and detection range even when visual line-of-sight is not available, while deploying Cooperative, Connected and Automated Mobility (CCAM) services.
To extend sensor capabilities in a CCAM scenario, each connected car subscribes to the topics of interest and gets the information when an update is available. Thus, it is expected that many flows requiring low-capacity and, optionally, low-latency (for mission-critical applications) will be generated. The scenarios are even more challenging in Beyond 5G (B5G) networks. The main idea is to take full advantage of the sensors deployed in a vehicle to collect and analyse telematics and driver behavioural data to ensure the vehicle’s performance, efficiency, and safety. This translates in about 25 gigabytes of data per vehicle sent to the cloud every hour.
The huge scale and diversity of CCAM services imposes three main requirements for transport services: low-latency, high-capacity, and massive flow management. The generation of large numbers of flows or huge aggregated volumes of data from the edge of the network to the core to make use of the cloud services will pose a challenge to the network. To overcome this scalability issue, a key solution element is to also deploy computing and storage resources at the edge of the network, i.e., Multi-access Edge Computing (MEC), and distribute the functionalities between the MEC and the core cloud, located in the core network. Moreover, it will be important to target flow management schemes that lower complexity and aim to keep real-time state information to a level that is cost effective and manageable, considering both technical and business aspects.
Recent posts
When looking at the deployment of CCAM services over a distributed edge and cloud infrastructure, several challenges need to be overcome.
- First, we need unified management of computing, storage, and networking resources. In this respect, the TeraFlowSDN Controller will be able to deploy integrated services (i.e., to provision cloud and edge computing resources, and connectivity between them) and optimize the cloud and network resources (i.e., packet/optical) in a concurrent way.
- Second, we need to address the multi-domain aspects of the problem, where resources need to be assigned in each domain and then combined in an end-to-end fashion. In this respect, the TeraFlowSDN Controller will deploy several per-domain instances and compose them to create end-to-end connectivity services.
- Finally, the different domains involved might belong to different network operators. This calls for methods to keep private the internal network details. In this respect, the TeraFlowSDN Controller will be equipped with a Distributed Ledger Technology (DLT) component, based on blockchain technologies, to preserve the confidentiality of the data exchanged between the per-domain TeraFlowSDN instances.
At the infrastructure layer, the envisioned CCAM scenario, comprises several packet and optical transport networks for the metro and the core segments providing connectivity to the distributed cloud and edge computing infrastructure. CCAM services can be deployed in micro-DCs at the edge nodes (e.g., cell sites, street cabinets, lampposts), small-DCs (e.g., in a central office) for low/moderate-computation capacity and low response time, and core-DCs in the core network for high-computational capacity and moderate response time. Transport and cloud infrastructures are administratively partitioned into different domains, each controlled by a TeraFlowSDN Controller instance. In addition to selected uplink-heavy and latency-sensitive scenarios, the intention is to focus on a broadcasting application, such as Over-the-Air (OTA) updates, which are software improvements that a car company sends wirelessly to vehicles.
The inter-domain scenario complements the Autonomous Network B5G scenario by incorporating multi-domain and DLT functionalities. The DLT component is used as a gateway to interconnect different TeraFlowSDN instances, and the Inter-domain component enables to orchestrate the interdomain interactions between TeraFlowSDN instances.
This scenario will also be used to validate a number of standard protocols defined in different SDOs, such as the IETF drafts for Transport Network Slices and the ETSI Permissioned Distributed Ledger (PDL) drafts to interconnection the DLT components.
TeraFlow Testbed
The testbed envisioned for the Inter-domain scenario comprise two domains controlled by two different instances of TeraFlowSDN Controller deployed in multiple partners and facilities.
- The ADRENALINE testbed® at CTTC premises provides an SDN/NFV packet/optical transport network and edge/core cloud infrastructure for 5G and IoT services. Besides, it provides a Kubernetes-based environment to deploy the TeraFlowSDN controller, and a TAPI-enabled OLS controller together with the underlying optical transport network infrastructure.
- NEC contributes with the blockchain infrastructure and runtime providing the means to interconnect different instances of the TeraFlowSDN controller for the different domains.
- Finally, Telenor contributes with a server running TeraFlowSDN controller instance responsible for whiteboxes.