Enterprise customers need easy ways to onboard, authorize, and control IoT devices onto a single unified infrastructure. The Cisco Spaces Connect addresses this by providing a set of interfaces to:

• Onboard devices into the infrastructure.

• Control and receive events from the devices.

To accomplish this, the Cisco Spaces Connect leverages the following interfaces between the network and applications:

1. Onboarding Interface: This interface is used to onboard a device to a network.

2. Control Interface: This interface is used for bi-directional communication with a non-IP device.

3. Telemetry Interface: This interface is used for streaming telemetry from a non-IP device.

The IoT Orchestrator is a Cisco IOx container that is an integral part of the Cisco Spaces Connect solution. You can deploy the IoT Orchestrator on the Cisco Catalyst 9800 Wireless Controllers.

The IoT Orchestrator exposes APIs that allow applications to:

• Introduce devices to enterprise networks

• Control devices

• Receive telemetry from those devices

Note	Device control and data reception are not required for IP-based end points because the devices can communicate directly using their IP address.

The IoT Orchestrator exposes the following APIs:

• Provisioning Interface:

  • Leverages the IETF System for Cross-Domain Identity Management (SCIM) API, specifically the SCIM for devices model.

    For information on the Device Schema Extensions to the SCIM model, see https://datatracker.ietf.org/doc/draft-ietf-scim-device-model/.

    Note

    The SCIM has a hierarchical schema with a core device schema and extensions. The SCIM allows an application to: Send a SCIM object to a SCIM server (gateway) to create, update, and delete devices in networks. For information on the System for Cross-domain Identity Management (SCIM) API, see RFC7643 and RFC7644.

• Control Interface:

  • Allows an application to connect to a non-IP device.

  • Enables data exchange with the device.

  • Register topics for streaming telemetry. The IETF draft for this protocol is called the Non-IP Control (NIPC).

• Telemetry Interface:

  • A streaming data interface with publisher sub-topics of different types, such as:

    • Device broadcasts

    • Device streaming data, or

    • Device connection state.

The Cisco Catalyst 9800 Wireless Controller and APs support interfaces as mentioned in the Introduction to Cisco Spaces Connect APIs for BLE devices.

The IoT Orchestrator has two internal components:

• Gateway

• BLE Controller

These components are collocated in a single containerized application.

The IoT Orchestrator works in conjunction with a BLE daemon in the Cisco Catalyst APs. The controller unclears the AP infrastructure to the application and ensures that the device is connected to the most appropriate AP. This means that the application can communicate with a single Gateway and does not have to manage the network topology.

To communicate with or receive data from a BLE device, an application needs to first onboard the device by creating a SCIM object and send it to the SCIM server (the gateway). The SCIM object uses the device schema and has a BLE extension. If the SCIM call is successful, the gateway generates a unique Device ID and returns the complete SCIM object as registered with the Device ID.

Subsequently, the application uses the Device ID and leverages the control interfaces to communicate with the device or execute a specific NIPC operation.

The NIPC API covers the following types of APIs:

• Connectivity: Connect or disconnect, and pair BLE operations.

• Data: Read or write, start notifications or indications, discover.

• Registrations: Register data application, register topic (either advertisement or connection state).

• Bulk: API that allows for bulk operations (multiple operations in one API call).

The Internet of Things present a management challenge in many dimensions. One of them being the ability to onboard and manage large number of devices. There are many models to bootstrap trust between devices and network deployments.

The System for Cross Identity Management (SCIM) defines a protocol and a schema to provision users. However, the SCIM is extended to provision devices. The protocol and core schema are designed to allow such extensions.

There is a need for non-IP devices to support processes in manufacturing, healthcare, retail, home, and office. Similarly, wireless access points are deployed nearly everywhere, many of which have radios that can transmit and receive different frame types (such as BLE). To integrate both these use cases to leverage a single wireless infrastructure and avoid the need of parallel infrastructure, you need a non-IP device gateway function.

The non-IP device gateway provides the following functions:

• Authenticate and authorize application clients to communicate with devices.

• APIs that allow an application to set up a connection with a device.

• APIs that allow an application to exchange data with a device.

• APIs that allow a device to create registrations in the network.

All these APIs along with the onboarding API (SCIM for devices) allows application to perform a complete set of operations in non-IP devices.

The following are the supported API tags:

The NIPC is extensible in two ways:

• Protocol Extensions: This allows for extensions to the schema to integrate new non-IP communication protocols.

• Interface Extensions: This allows for defining extensions, such as publish/subscribe interface or data streaming interface.

All RESTful and MQTT interfaces in the Gateway are TLS secured. You will need to configure a server certificate in the Gateway.

Client authentication can be done either using an API key or a certificate. For more information, see the Uploading Certificate and Key to Open HTTP Server and Listen for APIs section in the Cisco Spaces Connect for IoT Services Configuration Guide, Release 1.0.0.