# Scalable OneM2M IoT Open-Source Platform Evaluated in an SDN Optical Network Controller Scenario +
## 3 The OneM2M IoT Platform and Proposed Implementation for Optical Network Control
### The OneM2M Platform for an Optical Network
#### 3.3.2 Implementation of the Second Use Case  
In the second experiment, the implemented application identifies \(M\) out of the \(N\) nodes to be configured to receive updates regarding the status of the connections with other devices (e.g., ROADM cross-connections). These nodes make a subscription with the Mobius OneM2M platform and receive messages every time the network controller detects a change in the link status. In this experiment, we measured the time \(T_{C}\) experienced between the moment when the configuration is enforced at the Mobius Controller and the moment when all configuration messages are received by the subscribed ROADM agents interested in the update.  
In this second experiment, it was also necessary to build a model of the optical cross-connections among nodes for the OneM2M server. Figure 5 shows this model. The structure follows the OpenROADM model hierarchy. More specifically, the configured optical cross-connection is enabled from the input Network Media Channel, configured on degree 1, to the output Network Media Channel, configured on degree 3, using the frequency 193.6 THz and setting as launch power 0 dBm. The bandwidth allocation to the optical signal is configured both at Media Channel and Network Media Channel levels (respectively sent for configuring logical interfaces for both input and output ports).  
The working scenario is more elaborate in this second use case: we considered a network of ROADM devices where each device knows the other neighbour devices. In this perspective, each ROADM agent can subscribe to the OneM2M server to receive updates regarding the status of the connections that concern it. Listing 2 shows the modified pseudo-code for the ROADM agents.  
{  \"config\": {  \"xmlns:xc\": \"urn:ietf:params:xml:ns:netconf:base:1.0\",  \"org-penroadm-device\": {  \"xmlns\": \"http://org/openroadm/device\",  \"road-connections\": {  \"connection-name\": \"NMC-CTP-DEG1-RX-193.6-to-NMC-CTP-DEG3-TX-193.6\",  \"opticalControlMode\": \"off\",  \"target-output-power\": 0,  \"source\": {  \"src-if\": \"NMC-CTP-DEG1-RX-193.6\"  },  \"destination\": {  \"src-if\": \"NMC-CTP-DEG3-TX-193.6\"  }  }  }  }  }  }  } ```  
**Listing 2**Pseudo-code of one of the \(M\) ROADM agents.  
The controller can exploit the information collected from the ROADM agents sending periodic updates. The controller has become more complex: depending on the status of the ports of an ROADM device and which is the port that transmits or receives power, it knows which connections can still be used. It publishes updates on the OneM2M server about the malfunctioning links, and all the interested ROADM agents receive notifications. In this way, the ROADM devices can decide how to tune the functioning parameters according to the updates they receive through the agents. Listing 3 shows the pseudo-code for the controller. The Unified Modeling Language (UML) sequence diagram in Figure 6 shows the interactions among the different components of the system, assuming that ROADM Agent 1 is connected to ROADM Agent 2 through Connection \(A\) and the controller detects a malfunctioning of ROADM Agent 2.  
Figure 5: JSON model of a connection between ROADM devices.