When an IoT Platform registers with the MEC platform via the MEC 033 API, the `mep-iot` service acts as an application and registers itself to the IoT Platform (oneM2M CSE) by sending an Application Entity (AE) Creation Request (`OneM2M_create`). Currently, the `mep-iot` service dynamically maps the `iotPlatformId` provided in the registration payload directly to the Resource Name (`rn`) attribute of the new AE it attempts to create. ### **Expected Behavior** The `iotPlatformId` is the unique global identifier of the IoT Platform itself (e.g., a centralized cloud CSE). The AE created on the CSE represents the MEC platform's presence (the MEC application), not the IoT Platform. If multiple edge nodes (e.g., MEP1, MEP2) connect to the same centralized CSE, they act as independent Applications and should create uniquely named AEs representing themselves (e.g., `mep1-iot-service`). The `iotPlatformId` should remain constant for the centralized CSE. ### **Actual Behavior** Because `mep-iot` explicitly sets the AE's `rn` to the `iotPlatformId`: 1. When MEP1 verifies the platform, it successfully creates an AE on the CSE named after the `iotPlatformId`. 2. When MEP2 attempts to verify the same platform using the same `iotPlatformId`, the CSE rejects the AE creation request with a `409 Conflict` (`attribute 'rn' is duplicated`). This architectural mismatch prevents centralized IoT platforms from registering simultaneously with multiple MEC edge nodes without applying improper workarounds (like modifying the IoT Platform to advertise a different `iotPlatformId` per MEP). *** Let me know when you've raised it and are ready for me to proceed with our local patch!