5 Product service profiles

5.1 Introduction

The clause defines Product Profiles. Product may be Implementations of oneM2M specification. The Implementation is claimed to comply with one or multiple Product Profiles. Each profile is defined with fundamental feature set and extendable feature set. Fundamental feature set includes Features that shall be implemented if the Implementation under test needs to be certified against the profile. Extendable feature set includes features that are recommanded to be implemented for optimization purpose. The features in the extendable feature set may be tested based on the requirement. The features in the clause are defined in TR-0032[i.2]. Each profile is also composed of a profile description and a profile example. The profile description is the definition of profile and describes the suitable products that should comply to this profile. The profile example gives some real market product examples as well as the usage and scenarios of the product.

Each of the Profile contains the following Features as common Features.

Table 5.1‑1: Fundamental feature sets for all Profiles

5.2 Constrained sensor as ADN

5.2.1 Profile description

The profile defines constraint sensor that is powered by battery and intended to be used for years after deployment without any human interference for maintenance. Therefore, the function of constraint sensor need to be very limited.

A sensor is intended to be reporting sensed data to the CSE periodically or according to some other period. Everytime the sensor reports data, it sends one message to the CSE. In order to save battery, the sensor can be sleeping before and after the reporting of sensed data.

For the successful report of data, there is needed some context resource architecture like the AE resource, the container resource etc. The resource architecture can be pre-configured in order to minimize the complexity of the constraint sensor.

5.2.2 Profile usage examples

The profile applies to constraint sensors that report periodically sensed data. Some example of this kind of product include:

Electricity, water, gas meters that report consumed amount of electricity, water or gas to the CSE. The meters are deployed inside houses and are powered by battery.

Temperature, humidity sensors that are deployed in the open air for environment monitoring. The sensors can be deployed in places that are hardly reachable for people that the sensor's need to be working without human inference for years powered with battery.

5.2.3 Fundamental feature sets

For constrained sensors, the features in the fundamental feature sets assume that the registration relationship between the ADN and the registrar CSE has been pre-configured before hand. The

Table 5.2.3‑1: Fundamental feature sets for constrained sensor as ADN

5.3 Constrained actuator as ADN

5.3.1 Profile description

The profile defines constraint actuator that is powered by battery and intended to be used fro years after deployment without any human interference for maintenance. Therefore, the function of constraint actuator need to be very limited.

An actuator is intended to be receiving control command from CSE via notification or other means. The actuator then actuates according to the control command.

The actuator need to receive control command. As a result, the actuator need to be request reachable to receive notification or be able to start a polling channel.

5.3.2 Profile usage examples

Swithes deployed along the street light to switch on or off the street light remotely.

5.3.3 Fundamental feature sets

Table 5.3.3‑1: Fundamental feature sets for constrained sensor as ADN

5.3.4 ADN1-requestReachable

Table 5.3.4‑1: Notification feature sets for constrained actuator as ADN

5.3.5 ADN1- pollingChannel

Table 5.3.5‑1: Polling Channel feature sets for constrained actuator as ADN

5.4 ADN profile 3

5.4.1 Profile description

This profile defines features for normal sensor devices or software components that desire to implement oneM2M sensing services. The sensing services such as monitoring temperature, detecting illumination, collection of location information etc are characterized with collecting and uploading measurement data into a destination e.g. a repository. The scope of normal sensor devices cover those that are powered by electricity power or by battery that can be easily changed when the battery is off and have rich resources compared to resource-constraint sensor devices.

The sensing service profile defines a set of features required to implement sensing functionalities including creation and update of

5.4.2 Profile usage examples

This profile applies to normal sensors deployed in non critial environments have relative rich resources and are powered by electricity power or by battery that can be easily changed. This profile can also apply to software components that implements sensing services.

Taking smart socket as an example, when a manufacturer-A decides to design a smart socket with oneM2M sensing service, he can refer to the Sensing Service Profile to check the fundamental features that are required to implement. The fundamental features for Sensing Service Profile are defined in Section 7.4.3 Feature Set. When another manufacturer-B also designs a smart socket complying with the Sensing Service Profile, these two smart sockets produced from two different manufacturers are interoperable potentially to work together to implement complex tasks.

5.4.3 Fundamental feature sets

Container is used for storing the measurements of sensing device and whenever there is data measured from the sensing device, the data will be sent to the CSE for storage by sending a

oneM2M sensing service profile consists of minimum features to implement Data Management for Container and ContentInstance functionality shown in Table 7.4.3‑1.

Table 5.4.3‑1: Fundamental feature set for ADN profile 3

5.4.4 Extendable feature sets

5.5 ADN Profile 4

5.5.1 Profile description

oneM2M provides serveral logical entity concepts called 'Node' to explain oneM2M Architecture in TS-0001. And from the descriptions about the node types indicates some examples that particular node could match with pyshical oneM2M devices (e.g. ADN -> constrainted oneM2M Device). But for the oneM2M device developers, may require more detail information to design and implement physical devices.

This ADN Profile 1 defines set of common features which could be used for small originator device types of oneM2M services.

5.5.2 Profile usage examples

ADN Profile 1 could be the basic profile of oneM2M devices like sensor, actuator etc. And also this profile could be used independently when developers want to implement oneM2M device with special functions.

5.5.3 Fundamental feature sets

Table 5.5.3‑1Table 5.5.3‑1: Feature set for ADN Profile 4 GEN: Feature set for ADN Profile 4 GEN

Table 5.5.3‑2Table 5.5.3‑2: Feature set for ADN Profile 4 REG: Feature set for ADN Profile 4 REG

Table 5.5.3‑3Table 5.5.3‑3: Feature set for ADN Profile 4 DMR: Feature set for ADN Profile 4 DMR

5.6 IN Profile

5.6.1 Profile description

oneM2M provides serveral logical entity concepts called 'Node' to explain oneM2M Architecture in TS-0001. And from the descriptions about the node types indicates some examples that particular node could match with pyshical oneM2M devices (e.g. ADN -> constrainted oneM2M Device). But for the oneM2M device developers, may require more detail information to design and implement physical devices.

This IN Profile 1 defines set of common features which could be used for server device type of oneM2M services.

5.6.2 Profile usage examples

IN Profile 1 could be the common profile of oneM2M devices like service server etc. And also this profile could be used independently when developers want to implement oneM2M device with special functions.

5.6.3 Fundamental feature sets

Table 5.6.3‑1: Fundamental feature set for IN Profile GEN

Table 5.6.3‑2Table 5.6.3‑2: Fundamental feature set for IN Profile REG: Fundamental feature set for IN Profile REG

Table 5.6.3‑3Table 5.6.3‑3: Fundamental feature set for IN Profile DMR: Fundamental feature set for IN Profile DMR

Table 5.6.3‑4Table 5.6.3‑4: Fundamental feature set for IN Profile SUB: Fundamental feature set for IN Profile SUB

Table 5.6.3‑5Table 5.6.3‑5: Fundamental feature set for IN Profile SEC: Fundamental feature set for IN Profile SEC

Table 5.6.3‑6Table 5.6.3‑6: Fundamental feature set for IN Profile GMG: Fundamental feature set for IN Profile GMG

Table 5.6.3‑7Table 5.6.3‑7: Fundamental feature set for IN Profile DIS: Fundamental feature set for IN Profile DIS

Table 5.6.3‑8Table 5.6.3‑8: Fundamental feature set for IN Profile PCH: Fundamental feature set for IN Profile PCH

5.7 Constrained actuator as ASN

5.7.1 Profile description

The profile defines constraint actuator that is powered by battery and intended to be used for years after deployment without any human interference for maintenance. Therefore, the function of constraint actuator need to be very limited.

An actuator is intended to be receiving control command from CSE via notification or other means. The actuator then actuates according to the control command.

The actuator need to receive control command. As a result, the actuator need to be request reachable to receive notification or be able to start a polling channel.

The features described in this profile are features of CSE as the ASN exposes Mcc reference point outside. There are internal AEs of the ASN to synchronize the actual device state with the resource hosted by the ASN-CSE. However, in this profile, the ASN-AE is not sending information to the other CSE's, it's not necessary to include the oneM2M defined AE Features in this profile.

5.7.2 Profile usage examples

Swithes deployed along the street light to switch on or off the street light remotely.

5.7.3 Fundamental feature sets

The fundamental feature set assumes that the resource id of the

Table 5.7.3‑1: Fundamental feature sets for constrained sensor as ASN GEN

Table 5.7.3‑2: Fundamental feature sets for constrained sensor as ASN REG

Table 5.7.3‑3: Fundamental feature sets for constrained sensor as ASN DMR

5.7.4 ASN-requestReachable

Table 5.7.4‑1: Notification feature sets for constrained actuator as ASN

5.7.5 ASN- pollingChannel

Table 5.7.5‑1: Polling Channel feature sets for constrained actuator as ASN

5.8 Gateway as MN

5.8.1 Profile description

The profile defines gateways that may support multiple different area network technologies and connect devices from the corresponding area networks. The devices may be oneM2M defined ADNs, ASNs or NoDNs which are not defined by oneM2M. The gateway hosts resources to enforce common services that devices in the area network may utilize the enable local services without the dependency of the platform and the wide area network.

5.8.2 Profile usage examples

Home gateways deployed in the home for smart home:

Sensors, actuators and home appliances are connected with the home gateway. Applications can be connected through the platfrom to access the smart home service as well as applications can be directly connected with the gateway to do the same thing.

Head unit in connected vehicles:

Sensors and actuators in the car are connected with the head unit. The sensed data and control command are reported to delivered through the head unit. Applications may access the head unit and monitor the car state via the platform. Applications may also access the head unit once connected directly with the head unit via area network such as Wifi or Bluetooth.

5.8.3 Fundamental feature sets

Table 5.8.3‑1: Fundamental feature sets for gateway as MN GEN

Table 5.8.3‑2: Fundamental feature sets for gateway as MN REG

Table 5. 8 .3- 3 : Fundamental feature sets for gateway as M N DMR

Table 5. 8 .3- 4 : Fundamental feature sets for gateway as M N SUB

Table 5. 8 .3- 5 : Fundamental feature sets for gateway as M N SEC

5.9 Field configurable oneM2M Entity Hosted on a 3GPP Device

5.9.1 Profile description

The profile defines the features required for a oneM2M entity hosted on a 3GPP device. This profile is intended to add required features to those specified in other profiles. For example, a temperature sensor hosted on an CIoT device would required the features described in this section plus the features described for a Constrained Sensor device.

5.9.2 Profile usage examples

The profile applies to CIoT devices that can receive trigger messages via a 3GPP core network. The trigger messages are used provision the device with enrolment credentials, register the device to a oneM2M CSE and re-establish a connection to the Registrar CSE.

5.9.3 Fundamental feature sets

Table 5.2.3‑1: Fundamental feature sets for oneM2M entity hosted on a 3GPP Device

Table 2: Mapping of feature to Test Purposes for AEA sensor is intended to be reporting sensed data to the CSE periodically or according to some other period. Every time the sensor reports data, it sends one message to the CSE. In order to save battery, the sensor can be sleeping before and after the reporting of sensed data.