SAREF4DMGT ontology and semantics

Introduction and overview

The objective of SAREF4DMGT is to extend the SAREF ontology (see ETSI TS 103 264 [1]) for the Device Management (DM) domain. Clause 4.1 of the present document shortly introduces a high-level view of the envisioned SAREF4DMGT semantic model, with the retained concepts (i.e. classes) and their relations.

The Device Management (DM) domain consists in the remote administration of devices for an operator, such as a service provider or device manufacturer.

The proposal for an ontology for standardization in Device Management is motivated by the need to address challenges arising from the evolution of DM and the emergence of the Internet of Things (IoT).

Initially, DM was introduced by manufacturers and telecommunication operators to ensure the proper functioning of devices like gateways and set-top boxes, focusing on firmware management due to the high replacement costs of these devices. Over time, the scope of DM expanded to include configuration and customer care, enabling Telcos to configure value-added services, improve Quality of Service, and reduce costs.

With the rise of the IoT, the DM landscape has shifted significantly. The proliferation of heterogeneous IoT devices and the temptation to produce disposable devices have highlighted the need for remote management for economic and ecological reasons. However, existing DM solutions face challenges due to the scale and diversity of IoT devices, as well as the prevalence of proprietary protocols and siloed solutions from various manufacturers. This has created issues with heterogeneity in device capabilities, DM protocols, and management solutions.

Standardization becomes essential to simplify device integration and DM operations, benefiting both operators and manufacturers.

The proposed IoT Device Management Ontology provides an abstract semantic model of DM domain-specific concepts, enabling cross-system data interoperability and knowledge enrichment through reasoning. This ontology aims to unify and streamline IoT DM practices, overcoming the limitations of existing approaches.

Therefore, the SAREF4DMGT ontology shall allow:

• The representation of the device management capabilities of a device, with their associated functions and commands.
• The representation of the information needed to select which command to execute on a device for a targeted function.
• The representation of the information retrievable from the device and exposed by the DM server.

The SAREF4DMGT extension has been specified and formalized by investigating Device Management standard protocols, such as BBF CWMP [4], BBF USP [5], oneM2M [6] or OMA LwM2M [7].

SAREF4DMGT mainly reuses the SAREF ontology (see ETSI TS 103 264 [1]) and is developed according to the SAREF Developmebt Framework and Workflow (see ETSI TS 103 673 [3]). The SAREF4DMGT ontology is fully specified and formalized in Clause 4.2 of the present document. Figure 1 presents the high-level view of the envisioned model of SAREF4DMGT ontology. In Figure 1, classes directly imported from the SAREF ontology are in yellow, classes specifically developed for SAREF4DMGT are in blue.

Within Figure 1, as well as within all the figures that are depicted in clause 4 of the present document, the following conventions are used:

• arrows are used to represent properties between classes and to represent some RDF, RDF-S and OWL constructs, more precisely:
  • plain arrows with white triangles represent the rdfs:subClassOf relation between two classes. The origin of the arrow is the class to be declared as subclass of the class at the destination of the arrow;
  • dashed arrows between two classes indicate a local restriction in the origin class, i.e. that the object property can be instantiated between the classes in the origin and the destination of the arrow. The identifier of the object property is indicated within the arrow;
  • dashed arrows with no identifier are used to represent the rdf:type relation, indicating that the element in the origin of the arrow is an instance of the class in the destination of the arrow;
• datatype properties are denoted by rectangles attached to the classes, in an UML-oriented way. Dashed boxes represent local restrictions in the class, i.e. datatype properties that can be applied to the class they are attached to;
• individuals are denoted by rectangles in which the identifier is underlined.

SAREF4DMGT is extending the SAREF ontology for the Device Management domain and thus shall logically mainly model the following concepts (i.e. classes within Figure 1):

• Manageable Device: A tangible object that has at least one Device Management Function. This class extends the saref:Device class, it is a Feature of Interest by definition.
• Server: A DM Server is the software entity which is responsible for performing DM operations on a fleet of Devices. It exposes the set of available operations to an entity that needs to trigger an operation, such as a manufacturer or a Customer Care service. The DM Server is a endpoint, generally secured, with which DM Clients communicate. The protocol used between Server and Client is not in the scope of this ontology. It can follow a DM standard such as CWMP or LwM2M, or be completely proprietary.
• Client: Software entity which represents a Device by exposing its DM Functions to one or more DM Server(s). It is responsible for the triggering of the DM Functions when a Command targeting the represented Device is received by the Server. The Client is also responsible for the reporting of the results of the Function execution to the Server. The Client has an identifier that is unique only relatively to each Server it is connected to.
• Device Management Capabilities: these capabilities are represented through categories of saref:Function and saref:Command. These capabilities rely on a set of high-level DM-specific device resources, namely the identity, firmware, packages, and modules. These resources can be manipulated through lower-level representations, namely the Supported Datamodel, and the Datamodel Parameters.
  • Device Management Function Category: Category of saref:Function corresponding to the capabilities of the Device to perform its own diagnostics, maintenance, configuration, monitoring and control.
  • Device Management Command Category: Category of saref:Command associated to Device Management Functions.
• Management Service: A saref:Service that represents functions or functions of interest of the Device Management Function Category. The Management Service for a function only exists when a Management Connection connects a Client and a Server that can expose this function.
• Management Connection : Abstract representation of the connection between a DM Client and a DM Server. It does not necessarily imply that a persistent connection is established between the entities, such as a TCP connection. It represents the link and the capability of the Server to interact with the Client. For instance, the Client has been authenticated by the Server with a certificate, and/or the client has received a configuration for access rights to its functions for the Server.

SAREF4DMGT

Introduction

As already introduced in clause 4.1 of the present document, SAREF4DMGT is an OWL-DL ontology that describes the domain of Device Management. To this end, multiple concepts need to be introduced.

First, SAREF4DMGT relies on a set of SAREF-defined concepts, which are saref:Function, saref:Command, and saref:Service. The Function is specialized to represent DM-specific capabilities, while the Command enables the representation of the exposition of these DM-specific capabilities. Finally, the Service is instantiated with a DM Service, that encompasses the set of functions related to DM.

These base concepts allow the representation of Device Management specific entities, which were extracted from the analysis of the major standards used for Device Management by Telecommunication Operators. For the purpose of the present document, the following standards were analyzed:

• BBF CWMP: The Customer Premises Equipment Wide Area Network Management Protocol [4] was created by the BroadBand Forum to address the Device Management requirement of Telecommunication Operators, with a specialization on gateway fleets management. While the protocol itself is defined in the Technical Report 069, the datamodel of devices is described in the Technical Report 181 [5].
• BBF USP: The User Services Platform [6] is the direct evolution of CWMP at the BroadBand Forum. The core principles are updated to allow a decentralized architecture compared to CWMP, with shared management through Access Control Lists.
• OMA LwM2M: The LightWeight Machine-to-Machine protocol [7] from the Open Mobile Alliance is a standardized protocol for remote device management, telemetry, and secure communication in IoT ecosystems. LwM2M enforces interoperability through standardized capabilities with registries [i.1] promoting the reuse of resources across vendors and manufacturers.
• oneM2M: oneM2M [8] brings together all components in the IoT solution stack. It avoids reinvention in favor of reusing existing technology components and standards. oneM2M’s architecture defines a common middleware technology in a horizontal layer between devices and communications networks and IoT applications. This standardizes links between connected devices, gateways, communications networks and cloud infrastructure. For the purpose of the present document, the following specifications were explored: "Management enablement (OMA)" [9], "Management enablement (BBF)" [10], "LwM2M Interworking" [11], and "SDT based Information Model and Mapping for Vertical Industries, section 5.8 Device Management" [12].

The SAREF4DMGT ontology represents the set of physical and software entities involved in Device Management, such as Manageable Device, Client, Server, Connection and Service.

The SAREF4DMGT ontology also models the following specific device capabilities to operate Device Management: Identity, Firmware, Package, Module, Device Control.

Finally, the SAREF4DMGT ontology models the technical representation of these capabilities in the different protocols. These capabilites are exposed as datamodels, hierarchical and technical data structures exposing parameters with their related types and available operations, represented as primitives. Thus, two concepts are introduced: Supported Datamodel, and Datamodel Parameters.

Domain resources

General overview

The Device Management domain involves the following entities: Manageable Device, Client, Server, Connection and Service. They are necessary to enable the discovery and control of Management functions remotely for a Device Management Operator.

The architecture of Device Management systems consists in a client/server architecture, where the client is responsible for the local activation of functions, while the server is the remote, secure endpoint that enables the connection with the Information System of the operator. The representation of this connection relies on the SAREF4SYST patterns [2].

Devices are managed as fleets as well as individuals, whether for fleet-wide campaigns such as firmware upgrades, or specific actions, e.g. diagnostics destined to Customer Care.

While this architecture used to be centralized with a single server managing every device of the fleet, for instance with CWMP, newer standard protocols introduce shared management of devices, with multiple actors, servers, and access rights for each resource.

Manageable Device

Specialization of saref:Device, the s4dmgt:ManageableDevice is a saref:FeatureOfInterest that consists in a device that supports at least one Device Management function, exposed through a command.

Client

The client of a device is a s4syst:System which exposes the DM Functions of this device to one or more DM Servers. The relationship linking a s4dmgt:Client to the s4dmgt:Device is the s4dmgt:representsDevice object property, and its inverse s4dmgt:isRepresentedBy. A client is responsible for a single device, while a device may be managed through multiple clients.

Server

The s4dmgt:Server is a s4syst:System, hosted in the network, which is the secured endpoint with which any s4dmgt:Client communicate. The Server is responsible for performing fleet-wide operations. The Server is the entity that exposes the set of available commands to DM Operators of manufacturers, telecommunication operators, or Customer Care services.

Management Connection

The s4dmgt:ManagementConnection is a s4syst:Connection that is the abstract representation of the connection between a s4dmgt:Client and a s4dmgt:Server. The s4dmgt:Connection can also provide metadata on the existing link between client and server, such as specific authentication or encryption schemes shared by these two entities.

These metadata are freely extensible to any implementation requirements. For instance, Connections are not limited to direct Client-to-Server connections, but also include broker-based architectures such as message-oriented middlewares.

A s4dmgt:Client may be connected to multiple s4dmgt:Server, with the restriction of a single s4dmgt:ManagementConnection for any pair s4dmgt:Server/s4dmgt:Client.

Management Service

A saref:Service that represents functions or functions of interest of the Device Management Function Category.

The s4dmgt:ManagementService exposes these functions through a Connection, between a Client and a Server.

s4dmgt:ManagementService and s4dmgt:ManagementConnection are linked through two object properties, s4dmgt:enablesManagementService and its inverse s4dmgt:hasConnection, which underline the fact that a Management Service only exists through its underlying Management Connection.

DM Capabilities

General overview

The list of DM capabilities comprises the following entities: Identity, Firmware, Package, Module, Device Control. Each resource is described in detail in this clause.

Following the SAREF pattern [1], capabilities are each modeled as a specific saref:Function which specializes the s4dmgt:DeviceManagementFunctionCategory.

Their related properties are each modeled as an individual of a saref:Property which specializes a single property, e.g. DeviceIdentityProperty, through a skos:narrower object property.

All Device Management related commands specialize the s4dmgt:DeviceManagementCommandCategory. In particular, the commands related with a capability are each modeled as a specific saref:Command which specializes their dedicated command category, e.g. s4dmgt:DeviceIdentityCommandCategory.

Identity

The s4dmgt:DeviceIdentityFunction corresponds to the capability of a device to expose a set of resources allowing the identification of that specific device among a fleet of devices. This identification can rely on a set of parameters combined to guarantee uniqueness.

A property associated with the s4dmgt:DeviceIdentityFunction function has a relationship skos:narrower with the property s4dmgt:DeviceIdentityProperty. The list of identified properties comprises the following individuals: s4dmgt:Manufacturer, s4dmgt:HardwareVersion, s4dmgt:ModelName, s4dmgt:ModelNumber, and s4dmgt:SerialNumber. This list is not exhaustive and is meant to be extended depending on the requirements of the Device Management Operator and their fleet.

The commands associated with the s4dmgt:DeviceIdentityFunction specialize the s4dmgt:DeviceIdentityCommandCategory, and comprise the following individual: s4dmgt:DeviceInfoRetrievalCommand.

Firmware

The s4dmgt:FirmwareManagementFunction (see Figure 3) enable the management of the firmware for a device, i.e. the program embedded within that device, loaded and executed at startup, which enables hardware access and control, enabling any device service.

A property associated with the s4dmgt:FirmwareManagementFunction function has a relationship skos:narrower with the property s4dmgt:FirmwareProperty. The list of identified properties comprises the following individual: s4dmgt:FirmwareVersion.

The commands associated with the s4dmgt:FirmwareManagementFunction specialize the s4dmgt:FirmwareManagementCommandCategory, and comprise the following individuals: s4dmgt:FirmwareInformationRetrievalCommand, and s4dmgt:FirmwareUpdateCommand.

Package

The s4dmgt:PackageManagementFunction (see Figure 4) enables the management of packages for a device. A s4dmgt:DevicePackage is a saref:FeatureOfInterest that represents an archive file that may contain resource files, code, libraries or executable files.

This resource follows its own lifecycle (see Figure 5), with the following states that specialize the s4dmgt:DevicePackageState: s4dmgt:DevicePackageInitialized, s4dmgt:DevicePackageDownloading, s4dmgt:DevicePackageDownloaded, s4dmgt:DevicePackageValidated, s4dmgt:DevicePackageInstalling, s4dmgt:DevicePackageInstalled, s4dmgt:DevicePackageUninstalling, s4dmgt:DevicePackageUninstalled.

A property associated with the s4dmgt:PackageManagementFunction function has a relationship skos:narrower with the property s4dmgt:PackageProperty. The list of identified properties comprises the following individual: s4dmgt:PackageName, s4dmgt:PackageVersion.

The commands associated with the s4dmgt:PackageManagementFunction specialize the s4dmgt:PackageManagementCommandCategory, and comprise the following individuals: s4dmgt:PackageInformationRetrievalCommand, s4dmgt:PackageCreationCommand, s4dmgt:PackageDeletionCommand, s4dmgt:PackageDiscoveryCommand, s4dmgt:PackageUpdateCommand, s4dmgt:PackageDownloadCommand, s4dmgt:PackageInstallCommand, s4dmgt:PackageUninstallCommand.

Module

The s4dmgt:ModuleManagementFunction (see Figure 6) enables the management of modules for a device. A s4dmgt:DeviceModule is a saref:FeatureOfInterest that represents an executable software entity on the device. The Device Module implements specific Functions that are available to the Device when the Device Module is activated. It may result from a package installation: deleting the corresponding Device Package will in turn remove the Device Module and its related Functions. This dependency is represented through the object properties s4dmgt:enablesDeviceModule, and its inverse s4dmgt:hasDevicePackage.

This resource follows its own lifecycle, with the following states that specialize the s4dmgt:DeviceModuleState: s4dmgt:DeviceModuleActivated, s4dmgt:DeviceModuleDeactivated.

A property associated with the s4dmgt:ModuleManagementFunction function has a relationship skos:narrower with the property s4dmgt:ModuleProperty. The list of identified properties comprises the following individual: s4dmgt:ModuleName, s4dmgt:ModuleVersion.

The commands associated with the s4dmgt:ModuleManagementFunction specialize the s4dmgt:ModuleManagementCommandCategory, and comprise the following individuals: s4dmgt:ModuleInformationRetrievalCommand, s4dmgt:ModuleDiscoveryCommand, s4dmgt:ModuleActivationCommand, s4dmgt:ModuleDeactivationCommand.

Device Control

The s4dmgt:DeviceControlFunction enables the control the global state of the device, e.g. its power state through the Reboot function, or the global configuration through the Reset function.

No property is associated to this function.

The commands associated with the s4dmgt:DeviceControlFunction specialize the s4dmgt:DeviceControlCommandCategory, and comprise the following individuals: s4dmgt:RebootCommand, and s4dmgt:ResetCommand. This list is not exhaustive and is meant to be extended depending on the requirements of the Device Management Operator and their fleet.

Datamodels, technical representation of capabilities

General overview

The Datamodel is a commonly adopted solution to represent and manipulate device capabilities for Device Management protocols. For instance, CWMP and USP rely on the Technical Report 181 (TR-181 [5]), while LwM2M specifies its own datamodel, split into objects defined in the LwM2M Registries [i.1].

Datamodels are hierarchical structures composed of parameters, coherently grouped through objects and/or tables. Two aspects can be defined for a datamodel: the Supported Datamodel, which represents the abstract capabilities of the device, and allows their discovery; and the Datamodel Parameters, which contain the current state of the device, and enables the manipulation of parameters and their values.

Datamodels are the basis for the representation of capabilities during the exchanges between Server and Client. Each of the parameters contained with a datamodel support a set of Primitives, i.e. the basic operations that are available for their manipulation. These primitives will for instance include the basic "Create", "Read", "Update", "Delete" operations and their corresponding names in the different protocols. Other identified primitives are the "Operate" primitive, which exclusively targets parameters representing executable functions; and "Subscribe", enabling automatic notifications, e.g. for value changes of a parameter.

For instance, to retrieve the value for the "Manufacturer" property of the Device Identity, the parameter path will be defined hierarchically for both USP and LwM2M. For USP, it is retrieved through a "Get" Request targeting the path "Device.DeviceInfo.Manufacturer", to retrieve a string with a maximum length of 64. In that case, "Device" is the root object containing the whole datamodel, "DeviceInfo" is an object containing the parameters related to the Device Identity, and "Manufacturer" is a string-valued parameter within this "DeviceInfo" object. For LwM2M, this value is retrieved through a "Get" Request targeting the path "/3/0/0". "/" is the root of the datamodel, "/3" represents the "Device" object, "/3/0" represents the first and unique instance of the "Device" object, and "/3/0/0" represents the first parameter, whose name is "Manufacturer".

The Ontology defines both the s4dmgt:SupportedDatamodelFunction and the s4dmgt:DatamodelParameterFunction to represent this low-level manipulation of resources.

Supported datamodel

The s4dmgt:SupportedDatamodelFunction (see Figure 7) enables the manipulation of the supported datamodel of a Device. This represents the supported capabilities of that device, i.e. the available parameters and operations on these parameters.

A property associated with the s4dmgt:SupportedDatamodelFunction function has a relationship skos:narrower with the property s4dmgt:SupportedDatamodelParameterProperty. The list of identified properties comprises the following individual: s4dmgt:SupportedDatamodelParameterName, s4dmgt:SupportedDatamodelParameterType, and s4dmgt:SupportedDatamodelParameterPrimitives.

The commands associated with the s4dmgt:SupportedDatamodelFunction specialize the s4dmgt:SupportedDatamodelCommandCategory, and comprise the following individuals: s4dmgt:SupportedDatamodelRetrievalCommand.

Datamodel parameters

The s4dmgt:DatamodelParameterFunction (see Figure 8) enables the manipulation of the datamodel parameter instances of a Device. The datamodel parameter instances represent the current state of each device capability and their configurations.

A property associated with the s4dmgt:DatamodelParameterFunction function has a relationship skos:narrower with the property s4dmgt:DatamodelParameterInstanceProperty. The list of identified properties comprises the following individual: s4dmgt:DatamodelParameterInstanceName, s4dmgt:DatamodelParameterInstanceValue.

The commands associated with the s4dmgt:DatamodelParameterFunction specialize the s4dmgt:DatamodelParameterCommandCategory, and comprise the following individuals: s4dmgt:DatamodelParameterCreationCommand, s4dmgt:DatamodelParameterDeletionCommand, s4dmgt:DatamodelParameterRetrievalCommand, s4dmgt:DatamodelParameterUpdateCommand, s4dmgt:DatamodelParameterOperateCommand.

References

Normative references

• [0] ETSI TS 103 410-8 (V1.1.1): "DATA; Extension to SAREF; Part 15: Device Management Domain".
• [1] ETSI TS 103 264: "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".
• [2] ETSI TS 103 548: "SmartM2M; SAREF reference ontology patterns".
• [3] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions".
• [4] BBF TR-069 Amendment 6 Corrigendum 1: "Broadband Forum, CPE WAN Management Protocol".
• [5] BBF TR-181 Issue 2 Amendment 20 Corrigendum 1: "TR-181 Device Data Model for CWMP Endpoints and USP Agents".
• [6] BBF TR-369 Issue 1 Amendment 4 Corrigendum 2: "Broadband Forum, The User Services Platform".
• [7] OMA-TS-LightweightM2M_Core-V1_2_2-20240613-A: "Lightweight Machine to Machine Technical Specification: Core".
• [8] oneM2M TS-0001: "Functional Architecture".
• [9] oneM2M TS-0005: "Management enablement (OMA)", v4.0.3.
• [10] oneM2M TS-0006: "Management enablement (BBF)", v4.0.1.
• [11] oneM2M TS-0014: "LwM2M Interworking", v4.0.1.
• [12] oneM2M TS-0023: "SDT based Information Model and Mapping for Vertical Industries", v5.7.0, section 5.8 Device Management.

Informative references

• [i.1] LwM2M Registries, objects and resources. Available at https://www.openmobilealliance.org/specifications/registries

Acknowledgements