Cisco Spaces Asset Tracking Runbook (Cisco Validated)

OVERVIEW

This Cisco Validated runbook is designed only as a follow on from the Spaces OS Runbook. It provides a comprehensive guide on asset tracking using Cisco Spaces. It includes an overview of asset tracking, recommended prerequisites, wireless infrastructure setup for both Catalyst and Meraki systems, AP density and placement guidelines, Spaces infrastructure requirements, implementation steps for Catalyst and Meraki, and the configuration of IoT services. Additionally, it covers the requirements for asset tags and detailed instructions for setting up the Spaces Connector and integrating with WLC.

Lack of real-time Asset tracking solutions can add critical bottleneck to the supply chain operations and in the healthcare industry, cause life-threatening delays.

Spaces native apps can track all devices connected to the network in real time and with a host of partner apps & BLE devices, which can monitor and manage all critical or high value assets in the campuses

• Track all devices connected to the network

• Access to industry-leading applications with the App marketplace

• Easy deployment of third-party apps & devices with additional gateways

• Scale & manage IoT devices & partner apps

Use Cases:

• Healthcare: Manage  medical equipment in real-time and improve operational efficiency

• Retail & Hospitality: Track high value assets and equipment within the campuses

• Workspaces: Locate all devices connected to the network on a map interface for real-time tracking

• Manufacturing: Track the location of high value assets

SUPPORT & ONBOARDING INFO

Please follow the link below to find out about the different ways to get support for Cisco Spaces.

Support Info Link

PREREQUISITES

This runbook should only be used as a follow on from the Spaces OS Runbook. If that runbook has not been completed, go back and validate the deployment against that first.

Catalyst

Within Catalyst AP environment, we are aiming for 2 key requirements; BLE support, and IOX Container support on the AP. APs providing both of these requirements will allow the use of Advanced IOT Gateway support. Those only providing BLE, will show as Base. APs not included on the following list, are not supported APs for Asset Tracking use cases, but may be supported for other use cases, such as occupancy.

Advanced Gateway - Recommended

The Cisco Spaces Advanced IOT Gateway allows us to gather extra data from IOX compatible devices found from the Spaces IOT Device Marketplace.

This is particularly relevant for asset tracking, as we can capture battery life of tags through this extra data, meaning tags don’t just drop off the network, and we can manage replacing tags when needed.

The advanced gateway leverages both the IOT radio, and the IOX container capability, and as a result, a smaller subset of AP's are supported.

To manage the IOX container functionality, these AP's are required to be managed by a 9800 WLC, all are supported. Suggested for code versions is 17.9.x (latest). There have been significant improvements in IOT Services on 9800 since 17.9.5, so lowest recommended is 17.9.6 - See 9800 Known IOX Issues for more details.

Base Gateway

Base gateway functionality purely collects RSSI from tags, meaning we only need access to the BLE radio on the AP, not IOX. As a result, the list is more extensive, but the use cases are limited.

For particular note within asset tracking, we will not be able to receive the battery level of IOT tags, whether they are from the IOT Marketplace or not. This will serve difficult in maintenance of the solution, as tags may simply drop off without warning.

Even for the base gateway, 9800 is still utilised, and 17.9.6 is still the minimum recommended code version.

Base gateway functionality is not recommended where advanced gateways can be used, it often serves a inferior solution, and provides less expandability for future use cases.

Meraki

For Meraki deployments, we have no such feature as the IOX container, meaning we simply leverage the BLE radio on the AP directly. This means the use case is easier to deploy, but comes with some limitations.

We can only leverage Eddystone or iBeacon formats, and cannot collect any 'extra data; that we can with the advanced gateway. In summary, on Meraki deployments we can deliver base gateway functionality only - See Base Gateway.

Due to the fact we only leverage the BLE radio for Meraki deployments, the pre-requisites are less stringent.

In summary, we support any Meraki AP Wave 2 and onwards, on firmware version 29 and above (latest is suggested).

AP Density

General guidance for designing for location services has not changed over the years, and we still follow 4 main guidelines

4 guidelines for designing for location services:

• AP’s should be around the perimeter (aiming to surround any client with AP's on all sides)

• Clients should be heard by 3 or more AP's, at -75dBm or better

• AP's should be spaces 12-21 meters (39-67 ft) apart

• AP's should be deployed at 6 meters (20 ft) or less

AP Placement Check

With AP Auto Location access points on a Digital Map can be automatically located in Cisco Spaces. By improving device location accuracy and reducing troubleshooting efforts caused by incorrect AP placement, AP Auto Location helps streamline deployments, reduce complexity, save time, and minimize costs associated with verifying and placing APs on maps.

• Cisco Catalyst 9800 Series Wireless Controllers must be connected to the Cisco Spaces: Connector and both must be available in the Cisco Spaces cloud account.

• Digital maps must be available for the floors to place the AP. Use the Locations & Maps feature to add digital maps. For more information, see Setting up Locations and Maps.

• Site tags are mandatory for the floors. Use the Cisco Catalyst 9800 Series Wireless Controllers GUI to create site tags. The APs that are being placed in Cisco Spaces must be associated with the site tags. For more information about configuring site tags, see "Configuring a Site Tag" in the Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide.

Generating ranging data for default site tags is not supported in Cisco Spaces.

AP Auto Locate is also being implemented for both Meraki Dashboard, and Catalyst Center. This would allow automatic placement of APs in respective management platforms, and then ingestion of AP placement into Spaces.

AP Auto Locate - Meraki

AP Auto Locate - Catalyst Center (Currently not available).

For an in-depth guide for AP Auto Locate please refer to the Configuration Guide.

Asset Tags

Choosing asset tags is a core part of implementing a good asset tracking solution.

There are a number of core fundamentals to consider when choosing physical tags for a solution:

• Price

• Compatibility

• Form factor

• Battery life

• Extra features (e.g. temperature or button press)

The Spaces IOT Device Marketplace is a page dedicated to providing this information, and connecting buyers to sales teams from the respective tag supplier.

The marketplace also offers a list of tags that have been validated to work with the advanced gateway setup, meaning we will be able to gather battery life (as well as the option of other data), along side delivering location.

The platform is also capable of supporting any iBeacon or Eddystone tag, delivering just base location functionality, and no other data.

These tags may be more appropriate for a base gateway solution.

IMPLEMENTATION

To complete these steps, an admin will require read/write permissions within Spaces for IOT Services and IOT Explorer

Given the above prerequisites have been met, its now time to implement our asset tracking use cases.

For each stack (Catalyst or Meraki), we will cover whats needed to add these stacks to Spaces, how to enable IOT services, then how to deliver outcomes.

This implementation section is particularly focused towards our use case of asset tracking, but many steps are matched for other use cases, so it may be necessary to skip, or just verify some steps.

Configuring IOT Services

Now all infrastructure and hierarchy is setup, IOT Services can be enabled. This will push configuration to our controller, as well as push the IOX container to the AP, enabling BLE and creating a telemetry stream for the data.

1. Navigate to About IoT Services page on the left-hand side of the Menu > IoT Services.

2. On Day 0 of the IoT Services Activation an Amber Banner will be at the top that signals the deployment hasn't started yet.

3. Once all the prerequisites are met, click Activate button on the Amber Banner. Alternatively, click on Activate IoT Services to begin.

4. Select Wireless and click on Next.

5. After the Prerequisite Check Screen it progresses to Activation Screen that shows how many Connectors and Controllers are up.

6. Post Activation Summary Screen, there are two ways to deploy IoT services.

7. Here, click either Activate to enable IOT Services everywhere, or click Click here for customization to only enable IOT Services on selected connectors, controllers or AP's.

Following this process, will enable all compatible AP's to be advanced gateways (as dictated above), and all other AP's will be enabled as base gateways.

Claim and Configuring Asset Tags

We now have everything ready to start tracking our asset tags, but first, we should claim the beacons and push any configuration.

First, lets claim our beacons.

Click here for a video guided demo

1. Under IOT Services > Device Management, click the blue button in the middle of the screen labelled Onboard Devices.

2. Select Floor Beacons.

3. Fill out the order ID. This is usually sent by the tag manufacturer by email at point of ordering, and/or will be included in the packaging of the tags themselves. Then hit Add to Inventory.

Now we can go ahead and push out any config changes needed to our claimed beacons.

Click here for video guided demo

1. Configure claimed beacons by navigating to IoT Services > Device Management > Devices > Claimed Beacons.

2. Click the Configure Beacons link which will open the beacon configuration portal.

3. Identify the beacon via its Unique ID in the Device Inventory as well as printed on the physical device.

4. Make any configurations changes as needed, and when ready to apply the changes, click the SAVE CHANGES button. Test this out by enabling telemetry on a beacon via the beacon configuration page, then verify this operation was a success by clicking on an individual beacon in the Device Inventory and selecting Telemetry.

5. Verify in Device Management > Devices > Claimed Beacons that the changes have been applied by selecting the beacon and viewing its request history and viewing its updated settings, such as UUID, Major, Minor, Transmission Power, Transmission Frequency, as well as telemetry and location data.

Spaces Apps

Spaces delivers a number of use cases (known as apps) within the platform. These cover a great range of use cases, but here we will deep dive on the implementation and usability of the apps particularly focused on delivering asset tracking outcomes. For more information on other Cisco Spaces outcomes, please see the outcome store.

IoT Explorer - Preferred

IoT Explorer is an application designed to cater to specific use case needs. Deploy and create use cases effortlessly, including asset tracking, temperature monitoring, and presence detection, all in one centralized dashboard.

Centralize/Consolidate asset tracking process and obtain live insights into the location and usage of assets globally. Tailor notifications according to personalized guidelines and receive prompt alerts for significant shifts in asset behaviour and whereabouts.

Value Delivered: Increase operational efficiency to save time & cost, gain insights from historic trends to enhance decision-making, and deliver real-time visibility to stakeholders.

Useful to: Operations, Facilities, IT, Security

Lets create our first asset tracking use case within IoT Explorer.

Click here for a video guided demo

1. Head into IoT Explorer > Asset Tracking, then select Get Started.

2. Enter a Use Case Name and also a Description for the use case.

3. Now under Configure > Manage Assets > Import Assets, we can select our assets to import. This can either be done by setting up existing device filters, or through a CSV bulk import. If the beacons are already claimed, use the Existing Device Filter Criteria.

4. Assets should now be visible to locate within the Locator tab, and also in a list view within the Assets tab. In both of these tabs, clicking a given asset can provide more info, history, battery life etc. Searching for given assets here makes it easier to narrow down specific assets.

5. We can now generate rules for these assets within Rules > Add Rule.

   1. Configure a Rule Name at the top of the screen.

   2. Start by adding in a Rule element from the right hand pane. Note: Only one rule element can be configured per rule.

   3. Next drag in and configure some Condition elements. These conditions can be combined to generate more or less complex ruling setups.

   4. Now, add in Actions to determine what happens when the rule is triggered and matches the set conditions. Note: The action ‘Log the event’ is set by default and cannot be removed. It is recommended to configure these logs by clicking the action and adding context.

   5. Finally, hit Save & Publish to put the new rule into practice.

6. Now that a rule is in place, take a look in the Events tab, and see if any of the rules have been triggered. Events can also be exported here for compliance use cases.

REFERENCE

Connector IP Requirements

9800 Known IOX Issues

Cisco Spaces Connector Ports Used