6.1 Use case

The example scenario describes a clothes-washing machine and an application to monitor and control the IoT enabled product. This clause will show three different oneM2M resource tree models of the clothes washing machine and the call flows to create those models. The logic and call flows necessary for a client application to control and monitor the status of the clothes-washing machine is also described. In the next clause the washing machine capabilities are described using the SAREF ontology so that the client application can discover the washing machines. Additionally, the oneM2M Base Ontology describes how to use the device and commands that these clothes washing machines offer so that the client application can control any of them without regard to which resource tree model represents them.

This simplified clothes-washing machine has enough features to demonstrate the difference between the different modelling approaches supported in oneM2M. The concepts shown here can be applied to a full featured clothes-washing machine or any other IoT enabled device for that matter. The features and capabilities that are modelled are:

• The washing machine has been produced by manufacturer XYZ.
• XYZ describes this type of washing machine as "Very cool Washing Machine".
• The model of the type of washing machine is XYZ_Cool.
• The state of the washing machine can take the values "WASHING" or "STOPPED" or "ERROR".
• The washing machine supports three commands: ON, OFF, Toggle
• The washing machine is in My_Bathroom.

Figure 3: Functional Architecture for Smart Clothes Washing Machine

The clothes-washing machine is modelled as a non-oneM2M device (nodn) for all three models. However, everything in this guide applies equally if these were modelled as native oneM2M devices. There is no difference in the model or the call flows for everything to the right of the Interworking Proxy Element (IPE) shown in the figure below. Figure 4 shows a generic set of oneM2M call flow for the clothes washing machine (and the IPE) and the client application communicating through the oneM2M CSE. The level of detail provided here applies to all the different modelling approaches for the clothes washing machine. Differences in the call flows that are dependent on the model used, shown in blue shading, are further detailed where the specific models are described.

Figure 4: Generic oneM2M Call Flows

The messages shown in Figure 4 are further described here:

• Register the AE/IPE. In oneM2M an IPE is a type of AE that is intended to communicate with nodn's. The IPE is responsible for registering itself and creating the appropriate resources in a oneM2M CSE to model the nodn as if it were a oneM2M device. The result is that a washing machine that is native oneM2M and a washing machine that is non-oneM2M can be modelled the same way and the client applications cannot tell the difference.
• Create Polling Channel. A <pollingChannel> resource is used by applications or devices that are not reachable from the CSE that need to receive notification requests. This happens when, for example, the device is in a home with a firewall that prevents direct requests to the device from outside the local network in the home. [It is also appropriate for IoT devices that communicate using cellular networks].
• Create Information Model. The IPE creates all the resources needed to provide the status and enable control of the clothes washing machines. These messages (in almost all cases multiple resources are used) will be described with the details relevant to the specific model in later sub-clauses. This includes creating subscriptions to the resources that are used to enable the application to control the clothes washing machines.
• Register Client application AE. Client applications are also modelled as <AE> resources and register in the oneM2M CSE.
• Discover Washing Machine. An application designed to control the clothes washing machines produced by manufacturer XYZ will be able to discover them using a-priori knowledge of labels that are used to identify those washing machines. Later we will see how using the semantics capabilities of oneM2M and the SAREF ontology the same application can discover and control clothes washing machines from any manufacturer.
• Retrieve clothes washing machine resources. The client application generally has a user interface to show the status and allow control of the clothes washing machine. The client application will retrieve the specific resources that it needs to provide that capability. The application may have more features than a given washing machine model supports or, similarly the clothes washing machine model may expose more features than the client application needs. This step will use SPARQL queries to dynamically determine what resources are needed by the client application.
• Subscribe to resources. The client application is made aware of changes in the state of a clothes washing machine by receiving notifications of the changes. The client application first subscribes to the resources that contain information that it needs.
• Update the model resources. When the state of the clothes washing machine changes, the change in state will be reflected in the oneM2M CSE.
• Notification of state changes. When resources in the oneM2M CSE are created or updated the CSE will send notifications to applications that are subscribed to the resources. A client application that receives a notification can present this information to users or take some other actions.
• Send commands to clothes washing machine. The client application exposes to a user features or capabilities of the clothes washing machine. The client application sends the appropriate oneM2M primitives, based on the model, to use those features or capabilities.
• Generate notification for clothes washing machine. When the client application sends a oneM2M primitive to a resource that controls the clothes washing machine, a notification is generated (assuming notifications were created). In our scenario, since the clothes washing machine and the IPE are behind a firewall and therefore not reachable, the notification for the IPE are stored in the CSE and made available to the IPE via the long polling process.
• Poll for notifications. Because the IPE cannot receive notifications directly, it must use the long polling procedure to retrieve its notifications from the CSE. The IPE processes notifications by sending commands to the clothes washing machine using the API of the clothes washing machine.