Inclusive Edge Safety is an inclusive pedestrian safety support scenario for pedestrians who are uncomfortable walking, designed to address the following issues arising from existing urban transportation environments:
- Disparity in service provision due to transportation and location infrastructure separated by local governments.
- Difficulties in Linkage between Transportation Infrastructure and Public Services
- Cloud-based services increase latency during congestiomn
To solve this problem, it is a standard-based structure that guarantees interoperability oneM2M–MEC interworking architecture was designed.oneM2M is a global standard for data exchange between IoT devices, MEC is a distributed computing structure that processes data without delay at the network edge.
Inclusive Edge Safety leverages the interoperability of these two standards pedestrian location monitoring, vehicle proximity alarm, fall and collision recognition are handled in real time at the edge, it provides an integrated service that delivers it to guardians and local governments.
The service structure consists of three layers:
Device layer (ADN-AE): Collect shock, IMU, GPS sensor data from pedestrian smart aids
Edge layer (MN-CSE / MEC Host / MN-AE): Analyze collected data at the edge and notify caregivers
Cloud layer (IN-CSE / IN-AE): Manage cumulative data and provide personalized services from local governments or public portals
2. PrerequisitesA conceptual architectural proposal based on oneM2M Technical Specification and MECgsmec documents. The structure and interface were designed by referring to the standard documents below.
ETSI MEC standard docs: GS MEC 003 (Framework), GS MEC 011 (App Enablement), GS MEC 013 (Location API), GS MEC 021 (Application Mobility Service), GS MEC 033 (IoT API), GS MEC 040 (Federation)
oneM2M standard docs: TS-0001 (Functional Architecture), TS-0004 (Service Layer Core), TS-0010 (Security), TR-0008 (Interworking with other systems)
ESTIMED Hackathon Reference: GRMEC-DEC 050 Document-Based System Structure
3. download the projectOur team only participated in Track #1 and #2, so the code does not exist. Instead, I attached a pdf file at the bottom that summarizes the entire architecture of the scenario and how each element interacts and works.
4. Start oneM2M Platrform instanceIn the Inclusive Edge Safety scenario, the oneM2M platform is deployed as follows:
- Cloud layer: IN-CSEs are deployed in the central cloud to manage overall data
- Edge layer: MN-CSEs are deployed in app form for each MEC host to serve as edge-by-edge IoT platforms. At this time, the MEC Platform registers the MN-CSE as an IoT platform, and the device (ADN-AE) is registered so that the MEC Host can receive the data and deliver the MN-CSE.
This structure allows MEC Host to quickly process data from geographically close terminals and ensure service continuity through association with the cloud.
5. connect your iot deviceThe pedestrian's device acts as an ADN-AE. The device senses the user's location and status information, establishes a session with a nearby MEC Host (MN-CSE) via Proxy, and sends and receives data.
The ADN-AE also receives messages from the connected MEC Host in the form of Notification and can deliver immediate feedback to the user(ADN-AE), such as vehicle proximity alerts and collision warnings
6. connect your iot applicationInclusive Edge Safety has three main applications:
Infra IPE: Located inside the MEC host, it delivers information received through multiple APIs to the MN-CSE in oneM2M format.
MN-AE (Caregiver Application): Receives events (collisions, location fluctuations, etc.) transmitted by MEC hosts in real time and provides information to the Guardian through the interface.
IN-AE (local goverment application): Utilizes accumulated data in the cloud (IN-CSE) to provide personalized walking safety services such as high-risk zone advance notice based on individual movement patterns.
7. demonstrationThe conceptual flow of the Inclusive Edge Safety scenario is as follows:
Infra Configuration Steps: As mentioned earlier, there are multiple Edge MEC hosts in the edge layer, where there is a proxy so that the ADN-AE can connect with the appropriate MEC. In addition, the MN-CSEs inside each MEC are created with the same AE-ID as the resource tree required for ADN-AE operation to enable data transmission and reception as soon as the session is connected. The device is also registered with each MEC as devices connected to the MN-CSEs
Initial setup stage: When the user receives the device and powers it up, the request is sent to the fixed address proxy, which connects the session to the most appropriate MEC and is ready to start the service.
This allows the user to receive the following services while user moves:
- Real-time Location Monitoring: The ADN-AE periodically sends location information, and the MEC Host's MN-CSE provides a real-time location to the Protector (MN-AE) based on this.
- Vehicle proximity alert: The MEC Host detects the approach of the surrounding vehicle via the MEC Location API and sends this information to the device to generate voice and vibration alerts via the ADN-AE's speakers.
- Collision Detection Alert: When an IMU/impact sensor detects a fall or collision, the ADN-AE sends data to the MN-CSE, which immediately sends a notification to the Caregiver Application (MN-AE), which is also sent to the IN-CSE for other services at the same time.
- Mobility and Handover(1): When the user reaches the boundary between MEC hosts as they move, the connection to the existing MEC host is lost and the service is transferred to the MEC of the nearest neighbor MEC host.(based on MEC-021 Application Mobility Service)
- Mobility and Handover(2): When moving beyond host to another city, the fedator intervenes in the proxy address information of that city and the registration of a device and the creation of a resource tree to provide services.(based on MEC-040 Federation)
- Personalization Services: IN-AE provides personalization services such as advance notice of risk areas based on heatmaps that analyze long-term data stored in IN-CSE to analyze user movement patterns.
The figure below shows the structure in which oneM2M components are deployed in an Inclusive Edge Safety scenario.
The IN-CSE is located in the cloud and is responsible for storing the entire data management.The MN-CSEs are distributed in the form of apps to each MEC Host and are registered on the MEC Platform as IoT platforms (based on IoT APIs).When the ADN-AE is registered as a device with the MEC, the MEC forwards the device request to the MN-CSE and the Infra IPE converts the data obtained through the MEC API, such as Location/V2X, into oneM2M format.The MN-AE receives this data in the form of Notification, and the data transmitted from the MN-CSE is accumulated in the IN-CSE, where the IN-AE performs personalization services.This structure is designed based on option C among the deployment models of the ETSI GR MEC-DEC 050 document.
9. Custom parts and enclosuresThe ADN-AE (user device) is a portable smart assistant with the following components: a wheelchair, a cane, or a simple portable form. The configuration is as follows:
- IMU or impact detection sensor capable of detecting/judging collisions
- Raspberry Pi 5 as device board
- Speakers and vibration modules (for neighborhood alarms and danger zone warnings)
- Battery pack and wireless communication module (wifi/lte/etc...)
Configures Device (ADN-AE) → Proxy -> Edge (MN-CSE / MEC App) → Cloud (IN-CSE / IN-AE) structure.
Comments