ESTIMED_Hackathon1_FSCOM

# Vulnerable Road User (VRU) Detection Use Case — ETSI MEC / 5G / oneM2M

[Project location](https://www.hackster.io/garciayann/estimed-hackathon1-fscom-72e903)

# Table of content

1. [Introduction](#1-introduction)

2. [The whole picture](#2-the-whole-picture)

3. [Requirements](#3-requirements)

4. [Sensors and Data Sources](#4-sensors-and-data-sources)

5. [Use case story](#5-use-case-story)

6. [MEC/oneM2M Edge Architecture](#6-meconem2m-edge-architecture)

7. [Core component description](#7-core-component-description)

8. [Deployment overview](#8-deployment-overview)

9. [Telecom infrastructure overview](#9-telecom-infrastructure-overview)

## 1. Introduction

This project provides the materials submitted to ETSI STF 685 Hackathon #1 which occurs remotely from 28th to 30th October 2025.

This project describes a use case scenario for Vulnerable Road User (VRU) detection in a ETSI MEC/5G environment. It leverages ETSI MEC Release 3 capabilities for edge computing, ETSI C-ITS Release 2 for cooperative intelligent transport systems, and oneM2M Release 4 for machine-to-machine communication standardization.

This use case demonstrates how real-time VRU detection and notification can significantly enhance road safety by enabling vehicles, infrastructure, and pedestrians to collaborate in identifying and alerting about vulnerable users such as pedestrians, cyclists, and motorcyclists in near real-time.

For the ETSI MEC Sandbox application, I have selected a major intersection in Monaco at the junction of Avenue des Papalins and Quai Jean-Charles Rey as the basis for practical examples (43.7384°N, 7.4246°E).

**NOTE:** Security and Trust is out of scope of this project

## 2. The whole picture

A smart city intersection is equipped for vulnerable user detection. The environment contains:

• Connected vehicles (e.g. cars);
• Pedestrians with smart devices;
• RSUs placed at major crossings.

All components communicate using ETSI C-ITS Release 2 V2X protocols, and share data through a oneM2M Release 4 service layer operating on the edge using ETSI MEC Release 3.

## 3. Requirements

• Real-time VRU detection and tracking (< 100ms latency)
• Integration of multiple sensor types (e.g. sensors, cameras, lidars, V2X communications)
• Standards-compliant data exchange (oneM2M, C-ITS)
• Federated MEC and service handover architecture for geographical coverage
• Multi-hop communication for extended coverage
• AI-powered risk analysis and prediction

## 4. Sensors and data sources

• Vehicular Sensors: Vision-based cameras, LIDAR, radar, GPS - in vehicles for position, speed, and object detection
• Pedestrian Devices: GNSS, motion sensors (oneM2M-compliant)
• RSU Sensors:
• - Environmental (air quality, noise),
• - Vision: radar, lidar, camera
• - V2X radio: C-ITS CAM/DENM/VRU

## 5. Use case story

### 5.1. Overview

When a vulnerable user (e.g. pedestrians, cyclists) approaches an intersection:

• On-board sensors collect GNSS, inertial, and camera data;
• RSUs detect presence via radar, LIDAR, and camera;
• Cars provide proximity detection through on-board LIDAR and V2X radios;
• Data is offloaded to MEC hosts where fusion and AI-based risk analysis is performed in real-time.
• oneM2M mediates information sharing and semantic query between multi-vendor RSUs, vehicles, and applications;
• Critical alerts (potential collision, high-risk crossing) are broadcast with millisecond latency (V2X 5G slicing) to nearby (vehicles and to the pedestrian's device).

### 5.2. The user story

1. Car, pedestrian, and RSU broadcast C-ITS messages (CAM, DENM, VRU);

2. RSU sensors use radar/camera for VRU presence detection and relay all V2X message types;

3. V2X Data Aggregator on MEC platform collects, preprocesses, and fuses these multimodal streams;

4. VRU Fusion Service aggregates real-time VRU events (including from oneM2M IoT endpoints);

5. Risk Analytics AI Engine assesses collision threats and generates warnings;

6. MEC Federation ensures context and alert sharing across multiple operator's MEC environments;

7. Notifications reach mobile apps, in-vehicle displays, and RSU signals to warn all relevant parties;

8. oneM2M platform acts as IoT resource manager for sensor data sharing and API exposure across MEC and RSUs.

Based on the user story above, the following actors and stakeholders can be defined:

• Actors: Car, Road Side Unit (RSU), Pedestrian/Cyclist (VRU);
• Stakeholders: Telecom operators, City of Monaco, Traffic Operator / Traffic Control Center.

The following components can be defined:

• V2X Data Aggregator: Processes CAM/DENM/VRU messages and sensor streams, time-syncs, enriches, maps to oneM2M resource tree;
• VRU Fusion Service: Combines multiple detections or observations of the same VRU;
• Risk Analytics AI Engine: Computes short-term trajectory prediction, risk scoring, intent detection, decision logic to trigger warnings/DENMs;
• Notification Broker / oneM2M CSE: Publishes oneM2M notifications, manages subscriptions, handles access control.

### 5.3. Sequence diagram

The figure below shows the sequence diagram:


### 5.4. MEC/oneM2M Edge Architecture

The "VRU Fusion Service" accesses data via oneM2M semantic queries/APIs.

The architecture allows multi-domain federation, scalable to city-wide deployments.

## 6. MEC/oneM2M Edge Architecture

### 6.1 High-Level Architecture

The system comprises three main layers:

• Edge Layer: MEC platforms deployed at network edge (RAN component or gNodeBs);
• Infrastructure Layer: Roadside Units (RSUs), sensors, and traffic management systems;
• Device Layer: Connected vehicles, VRU devices, smartphones.

### 6.2 Technology stacks

• ETSI MEC Release 3: MEC platform services (ETSI GS MEC 003)
• ETSI MEC 040: MEC federation enablement
• ETSI C-ITS Release 2: Cooperative awareness and VRU protection
• oneM2M Release 4: IoT data management and interoperability
• 3GPP Release 16: 5G NR with uRLLC (Ultra Reliable and Low Latency Communications) and network slicing

### 6.3 Protocols

• oneM2M TS-0001 v4: Functional Architecture
• oneM2M TS-0004 v4: Service layer Core Protocol
• oneM2M TS-0033 v4: Interworking Framework
• ETSI GS MEC 011: Edge platform application enablement
• ETSI GS MEC 021: Mobility Service API
• ETSI GS MEC 028: WLAN information API
• ETSI GS MEC 030: V2X information service API
• ETSI GS MEC 040: Federation Enablement API
• ETSI TS 103 900: Cooperative Awareness Message (CAM)
• ETSI TS 103 831: Decentralized Environmental Notification Message (DENM)
• ETSI TS 103 300-3: VRU Awareness Message (VAM)
• ETSI TS 122 186: Sidelink & Uu Interfaces
• ITS-G5: IEEE 802.11p/OCB for V2X communication

## 7. Core components description

### 7.1. Component V2X Data Aggregator

The main purposes of the V2X Data Aggregator component are:

• To collect, normalize, pre-process V2X messages and sensor streams;
• To perform time synchronization and initial filtering; publish normalized state to oneM2M resources and to local MEC apps.

### 7.2. VRU Fusion Service

The main purposes of the VRU Fusion Service component are:

• To combine multiple sensor modalities into coherent VRU tracks with uncertainty models;
• To resolve occlusions;
• To associate VRU IDs to physical tracks.

### 7.3. Risk Analytics AI Engine

The main purposes of the Risk Analytics AI Engine component are:

• To compute short-term trajectory predictions;
• To compute collision probability and risk score;
• To generate alerts (local WARNs, DENM generation);
• To provide operator-level reports.

### 7.4. oneM2M Role & Integration

The main purposes of the of oneM2M platform are:

• To provide CSE (Common Services Entity) at the edge (co-located with MEC) to hold normalized VRU/track resources;
• To offer AE (Application Entities) for VRU Fusion Service, V2X Aggregator, Risk Engine, dashboards;
• To manage Subscriptions: operator dashboards or other MEC apps subscribe to oneM2M resources for contentInstance updates;
• To exploit oneM2M resources map: containers for sensors, containers for fused VRU tracks, containers for DENM events, etc.

**Note:** Access control and oneM2M's security features are out of scope of this use case.

## 8. Deployment overview


## 9. Telecom Infrastructure overview

A RAN component groups the gNodeBs around the intersection and hosts the MEC platform for this area.

These requirements below are extracted from (5G-IANA)[#13-references] and (5G-PPP)[#13-references] projects (real 5G deployments):

• Latency: <100 ms (detection-to-warning) for most critical flows; aim for 20–50 ms local processing if RAN slicing supports it;
• Availability: 99.99% for edge detection service in the intersection;
• Scalability: handle peak pedestrian density (~100 VRUs within intersection) + tens of vehicles.

## 11. Deployment Context: Monaco Intersection

This example of deployment are derived from (ETSI MEC Sandbox)[#13-references] scenario, mainly.

### 11.1 Geographic location

Intersection: Avenue des Papalins / Quai Jean-Charles Rey

Coordinates: 43.7384°N, 7.4246°E

Zone Type: Urban coastal intersection with mixed traffic

Traffic Volume: ~15, 000 vehicles/day, ~3, 000 pedestrians/day

Risk Factors:

Blind corners near port buildings

Tourist pedestrian traffic

Delivery vehicle congestion

Cyclist traffic along coastal road

### 11.2 Telecom infrastructure deployment

#### 11.2.1 gNodeB-1 (Primary Coverage)

Location: Rooftop at 2 Avenue des Papalins

Coordinates: 43.7386°N, 7.4244°E

Height: 35m above sea level

Frequency: n78 (3.5 GHz) + n1 (2.1 GHz)

Coverage: 300m radius, primary intersection coverage

MEC Platform: Integrated MEC host (Monaco-MEC-01)

#### 11.2.2 gNodeB-2 (Secondary/Handover)

Location: Building at 15 Quai Jean-Charles Rey

Coordinates: 43.7382°N, 7.4248°E

Height: 28m above sea level

Frequency: n78 (3.5 GHz)

Coverage: 250m radius, port area coverage

MEC Platform: Integrated MEC host (Monaco-MEC-02)

#### 11.2.3 gNodeB-3 (Backup/Capacity)

Location: Port Authority Building

Coordinates: 43.7378°N, 7.4252°E

Height: 45m above sea level

Frequency: n1 (2.1 GHz) for extended coverage

MEC Platform: Integrated MEC host (Monaco-MEC-03)

### 11.3 V2X infrastructure deployment

#### 11.3.1 RSU-1 (Northwest Corner)

Location: Traffic signal pole at northwest corner

Coordinates: 43.7385°N, 7.4245°E

Height: 5m

Coverage: ITS-G5 (5.9 GHz)

Sensors:

4K stereo camera

79 GHz mmWave radar

Thermal imaging camera

Connectivity: 5G NR (gNodeB-1)

#### 11.3.1 RSU-1 RSU-2 (Southeast Corner)

Location: Street lighting pole at southeast corner

Coordinates: 43.7383°N, 7.4247°E

Height: 5m

Coverage: ITS-G5 (5.9 GHz)

Sensors:

4K stereo camera

24 GHz traffic radar

LiDAR

Connectivity: 5G NR (gNodeB-2)

#### 11.3.1 RSU-3 (Pedestrian Crossing)

Location: Mid-block crosswalk on Avenue des Papalins

Coordinates: 43.7384°N, 7.4243°E

Height: 3.5m

Coverage: ITS-G5 (5.9 GHz)

Sensors:

4K camera

Ultrasonic sensor array

Pressure-sensitive mat under crosswalk

Connectivity: 5G NR (gNodeB-1)

Additional Sensor Infrastructure

Environmental Sensors

Weather station on RSU-1 (rain, wind, temperature, visibility)

Air quality sensors on all RSUs

Road surface temperature sensors (4 locations)

Smart Infrastructure

Connected traffic lights (4 intersections)

Variable message signs (2 units)

Emergency vehicle detection system

## 12. Conclusion

This architecture ensures rapid detection, notification, and response for vulnerable users in complex 5G and V2X environments, aligned with the latest ETSI and oneM2M standards.

Protocols and Standards Mapping

| Protocol | Entity | Message Type | Purpose | Data Examples |

+----------+-----------------+--------------+--------------------------------+---------------------------------+

| CAM | Vehicle/VRU | Awareness | Share position, heading, speed | Lat, long, speed, intent |

| DENM | RSU/MEC/Vehicle | Event | Alert, warning, incident | Danger type, location, time |

| VRU | VRU Device | Event/Intent | Detailed VRU state, intention | Crossing, waiting, fast motion |

| oneM2M | All | Resource API | Data modeling, notifications | Context, device ID, correlation |

## 13. References