@@ -548,6 +548,28 @@ In the following table, we will consider all the relevant operational requiremen
### 6.4.6 Industrial Digital Twins
#### 6.4.6.1 Use case Driven Deployment
The “Industrial Digital Twin” use case requires tight integration between oneM2M and MEC to support low-latency analytics, real-time control, and dynamic migration of digital twin services across production zones. The IN-CSE is deployed in the cloud to manage global digital twin state and analytics, while MN-CSEs are instantiated on MEC nodes located near industrial assets.
MEC hosts edge applications (e.g., quality inspection, anomaly detection) that interact with MN-CSEs. As mobile assets like AGVs move, the MEC, MN-CSE and IN-CSE coordinate handovers and synchronize twin states across MN-CSEs, ensuring seamless operation and minimal downtime.
In the following table, we will consider all the relevant operational requirement for this use case.
##### Table 6.4.x.1-1 – Operational Requirements and Platform Support for Industrial Digital Twins
| Operational Requirement | Support in MEC | Support in oneM2M |
| IoT platform deployment | Not directly required | Supported: oneM2M IN-CSE can be deployed at cloud or control center
Registration of Industrial devices (Digital Twin (DT)) | Not required | Supported: oneM2M enables registration of industrial sensors, actuators, controllers as either IN-AEs or ADN-AE via standardized resource structures and CSFs using \<flexContainer> data
Registration of Industrial applications | Not required | Supported: oneM2M enables registration of industrial
Applications as AEs via standardized resource structures and CSFs
Real-time data ingestion from factory floor (sensors, robots, AGVs) | Not required | Supported via oneM2M’s CSF and Mca interfaces
Instantiate of MN-CSE on Edge Node | MEC provides the infrastructure to host oneM2M as a service producing MEC application using Mp1 interface. Can provide support to integrate a new MEC IoT service (MEC 0xx to be defined later) inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (MEC033) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a CSF to integrate with the MEC platform
Instantiate of AE (e.g., AGV controller, sensor manager, analytics & controller) on Edge Node (Edge Digital Twin) | AE can be instantiated as MEC Application on MEC Host | Supported: oneM2M platform needs to include a CSF to instantiate an AE as MEC application
Low-latency control for AGVs and asset tracking | Supported: MEC Apps handle time-sensitive operations with minimal delay | Supported: MN-CSE enables fast coordination through subscriptions, notifications, and data routing
Offloading low latency tasks of IoT Platform for real time data processing | Not required. But MEC IoT API (MEC033) enables minimal registration and discovery of IoT platforms. | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms.
Service continuity during AGV zone transitions | Supported via MEC013 Location API (tracks UE movement) and MEC040 (supports MEC Federation and cross-MEP orchestration) | Supported: oneM2M handles session handover and task migration to a new edge (MN-CSE) instance coordinated by IN-CSE
Synchronization of Digital Twin state between edge and cloud | Not required | oneM2M ensures data consistency and context synchronization between MN-CSE (edge) and IN-CSE (cloud) whereas DT state plays vital role
### 6.4.7 Assisted Manoeuvring for Autonomous Ships
