When the `meep-iot` service registers itself to a oneM2M IoT Platform (CSE), it creates an Application Entity (AE). The CSE responds with a `201 Created` and assigns an AE-ID (`aei`) to the MEC platform. _According to the oneM2M standard_, all subsequent requests from the MEC platform to the CSE (Discovery, Update, Delete) must use this assigned `aei` as the Originator (`X-M2M-Origin` header). Currently, `meep-sss-mgr` completely ignores the assigned `aei`. Instead, it blindly hardcodes the `iotPlatformId` (or the string `"Admin"`) as the request Originator. _(See inline comments like `// FIXME FSCOM How to get it` inside `onem2m-mgr.go`)._ ### **Expected Behavior** `meep-sss-mgr` should extract the `aei` from the `OneM2M_create` response, store it within its internal state (or return it to `meep-iot-mgr` to store in `registeredIotPlatformsAEMap`), and dynamically inject it into the `from:` field of all subsequent requests made to that CSE. ### **Actual Behavior** Because `iotPlatformId` is hardcoded as the Originator: 1. When MEP1 registers, the CSE records that the Originator matching `iotPlatformId` belongs to MEP1's AE. 2. When MEP2 attempts to register using the exact same `iotPlatformId`, the CSE rejects the AE creation request with a `403 Forbidden` (`attribute 'aei' is duplicated`) or `Originator has already registered`. This breaks multi-MEP registration to a centralized CSE unless fragile workarounds (like forcefully altering the `iotPlatformId` per MEP) are employed.