Guest

Cisco Mobility Services Engine

Connected Mobile Experiences Design and Implementation Guide

Contents

1. Introduction

1.1 Technology Overview

2. Connected Mobile Experiences Solutions

3. Scope

3.1 Solution Components

4. Mobile Concierge

4.1 Mobile Concierge: Device Integration

4.2 Mobile Concierge: Application Integration

4.3 Mobile Concierge SDK (Powered by Meridian)

4.4 Implementing Mobile Concierge (Application Based)

4.4.1 Creating Coverage Areas and Zones

4.4.2 Enabling Mobile Concierge Services

4.4.3 MSE Services

5. Location Analytics

5.1 Implementing Location Analytics

5.1.1 Enabling Location Analytics Using Cisco Prime Infrastructure

5.2 Getting Information About Your Network

5.3 Performance Impact on Cisco MSE

5.4 Viewing Location Analytics in 3D

5.4.1 Configuring 3D

5.4.2 Exploring Location Analytics 3D

5.4.3 Analysis Control Panel

5.4.4 Choosing an Analysis Type

5.4.5 Selecting a Building

5.4.6 Using the Auxiliary Information Window

5.4.7 Performing Typical Location Analysis

5.4.8 Performing Typical Path Analysis

5.4.9 Using Reports

5.5 Location Update Events

5.6 Containment Events

5.7 Generic Northbound Notifications


1. Introduction

Ten billion mobile devices will populate our planet by 2016, and this proliferation in mobility is promoting the need for wireless connectivity. In addition, the wireless infrastructure has evolved from a mere connectivity vehicle to a platform to deliver innovative user services and enhance the customer experience.
The Cisco® Mobility Services Engine (MSE) platform provides a centralized and scalable way to deliver the following mobility services:

• Cisco MSE Location Services increases visibility into the network by capturing and consolidating crucial information about the radio-frequency (RF) spectrum, sources of RF interference, and devices and users on the network. Cisco MSE Location Services also enables a comprehensive set of real-time location services (RTLS).

• Cisco MSE Advanced Location Services enables enterprises and service providers to deliver customized location-based mobile services to end users and use Location Analytics to gain insights into end-user behavior while in their venues.

• Cisco Adaptive Wireless Intrusion Prevention System (wIPS) protects the network from wireless threats, rogue wireless devices, and denial-of-service (DoS) attacks to improve security and meet compliance objectives.

1.1 Technology Overview

Designed as an open platform, Cisco MSE supports mobility services software in a modular fashion, with configuration options based on network topology and the types of services required. The true value of Cisco MSE is delivered through the mobility services applications (Figure 1).

Figure 1. Wireless Architecture Overview

Cisco Connected Mobile Experiences is built on new capabilities that are part of Cisco MSE. Cisco MSE Advanced Location Services enables businesses to use Wi-Fi networks to engage consumers with value-added and personalized mobile user experiences.

2. Connected Mobile Experiences Solutions

The Cisco Connected Mobile Experiences solution consists of three main components:
1. Mobile Concierge: Mobile Concierge enables businesses to engage with customers in a targeted, contextual manner through their mobile devices in specific venues. Customer can now use their mobile devices to navigate a store, receive relevant information based on their location, interact with personnel, and enhance their overall experience. Mobile Concierge can be implemented using different application layers:

a. Mobile Concierge Software Developer's Kit (SDK): This developer's kit, powered by Meridian, provides an easy-to-use tool for developing applications and services that use the location intelligence from Cisco MSE.

b. Mobility Services Advertising Protocol (MSAP) service discovery: This function enables service discovery through the Layer 2 MSAP. It allows service discovery without the need to associate with to the network and without requiring a mobile app on a smartphone. This function will be available on Android phones shipping in CY13 with the Snapdragon silicon from Qualcomm Atheros.

2. Billboard: Available in an upcoming release, this application layer enables engagement with customers through their web browsers and does not entail a specific mobile application.
3. Location Analytics: Built on the ThinkSmart technology recently acquired by Cisco, Location Analytics captures and analyzes historical trends to provide greater visibility into customer movements and patterns. You can use these analytics to examine network utilization, track customer movement through your venue, and better understand the ways that customers behave.

Figure 2. New and Advanced Location Services in Cisco MSE

3. Scope

This document provides an overview of how and what analytical data on Cisco MSE can be accessed and used for various purposes. The scope of the architecture discussed here is limited to the necessary functional components that are relevant to this use case for the Cisco Connected Mobile Experiences solution. This guide assumes the following:

• An existing Cisco wireless network infrastructure with the minimum requirements listed in the "Solution Components" section is in place.

• An existing Cisco wireless network is configured using Cisco best practices.

• Location statistics depend on proper access-point density and placement; mobile clients must be enabled with Wi-Fi (turned on, but actual connection is not required).

• Refer to any additional references required or suggested in this document: location-based services deployment guides, etc.

3.1 Solution Components

The following components and minimum code versions are required for Mobile Concierge and location analytics:

• Cisco Wireless LAN Controller:software version 7.2 or later

• Cisco 802.11n access points: software version 7.2 or later

• Cisco Prime Infrastructure: software version 1.3 or later

• Cisco MSE (virtual or physical appliance): Cisco MSE software version 7.4 or later

4. Mobile Concierge

Mobile Concierge is a primary feature of Cisco MSE that allows engagement of users through a native application on a smartphone. It also includes the Mobile Concierge SDK, a developer's kit that provides an easy-to-use approach to developing applications and services that use Cisco MSE and provide content that is highly personalized for the individual and the context. The application partner ecosystem can use these APIs to provide access to applications and services developed by third parties for use with Cisco MSE. The Mobile Concierge SDK allows end users to receive push notifications sent transparently to the Wi-Fi network and to receive personalized services.

4.1 Mobile Concierge: Device Integration

Mobile Concierge also enables service discovery through the Layer 2 Mobility Services Advertising Protocol (MSAP). This protocol allows service discovery without the need to associate with the network and without requiring a mobile app on the smartphone. This capability will be available on Android phones shipping in CY13 with the Snapdragon chipset.

4.2 Mobile Concierge: Application Integration

Third-party mobile application servers use the location update and containment events from Cisco MSE described earlier to show the location of a mobile device in a mobile app and to deliver push notifications. Figure 3 shows how Cisco MSE, when deployed in a Cisco wireless network, can send location update and containment events to the mobile app servers. The mobile app servers use the containment events to deliver push notifications to mobile devices and show the device location using the location update events. In addition, these servers provide an online content management system to create place marks, mobile app content, and routing for turn-by-turn navigation.

Figure 3. Mobile Concierge Architecture with Meridian SDK

4.3 Mobile Concierge SDK (Powered by Meridian)

Meridian provides a mobile app and SDK for Apple iOS and Google Android devices. Figure 4 shows push notifications and indoor location in the Meridian mobile app on the Apple iPhone.

Figure 4. Push Notifications and Indoor Location Services

4.4 Implementing Mobile Concierge (Application Based)

The following sections explain how to configure Mobile Concierge services (Meridian) using Cisco Prime Infrastructure and Cisco MSE. Cisco MSE and Cisco Prime Infrastructure must be on a routed network so they can access and resolve Domain Name Service (DNS) entries for the host at http://www.meridianapp.com and Cisco MSE can push all the Cisco MSE context-aware service (CAS) notifications using port 80 http to the Meridian App cloud server.

4.4.1 Creating Coverage Areas and Zones

To have user location changes triggered in the Meridian app, coverage area zones must be configured. Configuration is needed for all zones that require a notification to be sent to the client device.
Follow the steps shown here to configure the coverage areas and zones.

Step 1. Choose Monitor > Site Maps.

Step 2. Click the floor on which you want to draw the zone and coverage area.

Step 3. Click Map Editor in the Floor View toolbar.

Step 4. After the Map Editor loads, click Coverage Areas under Floor Settings on the left to enable coverage areas.

Step 5. Click the Draw Coverage Area icon in the Map Editor toolbar.

Step 6. Type a name for the coverage area.

Step 7. After you enter a name, click OK.

Step 8. Start drawing the coverage area by clicking a point at the corner of a coverage area.

Step 9. Click each corner of the area.

Step 10. When you are finished, double-click the last corner.

Step 11. The coverage area is created.

Step 12. Click Save to save the coverage area.

4.4.2 Enabling Mobile Concierge Services

Cisco MSE Version 7.4 and later includes Meridian integration that provides single-step configuration to enable Meridian services. When integration is enabled, Cisco MSE sends the floor and map information for all the floors synchronized to Meridian. Location update events and containment events (if enabled) are autoconfigured to be sent to Meridian.
Before enabling Meridian integration, add controllers to Cisco Prime Infrastructure, create floors and coverage areas and zones, and position access points on the floors.

Step 1. Choose Services > Mobility Services Engine.

Step 2. Click Cisco Mobility Services Engine under the device name.

Step 3. Check the box next to Location Analytics; then click Save to save your configuration.

Step 4. Choose Design > Mobile Concierge.

Step 5. Click App Integration and then click Mobile App Enablement.

Step 6. Click the MSE for Meridian integration. Select the Enable Mobile App Integration.

Step 7. Enter a name for the location, the approximate street address of the location, and the email address for access to Meridian online editor and SDK. Meridian will create an account for the email address entered and a welcome email will be sent to that address automatically.

Step 8. Click Advanced.

Step 9. If zone notifications are preferred, select Enable Zone Notifications for Zones.

Step 10. Open the drop-down to select zones.

Step 11. The drop-down menu displays a list of all the floors and zones added to Cisco Prime Infrastructure and synchronized to Cisco MSE. Select the zones for which you want notifications. Multiple zones can be selected. Then click OK.

Step 12. Click Save.

Step 13. The Location Name entry corresponds to the name that appears in the Meridian app. The street address helps ensure that the location name appears when you click Nearby in the Meridian app.

Step 14. Go to edit.meridianapps.com and log in with the email address specified earlier.

a. Verify that the Location Name entry appears under Organizations.

b. Verify that all campus names appear under Apps.

4.4.3 MSE Services

Follow the steps listed here to synchronize Cisco MSE services.

Step 1. Choose Services > Mobility Services Engines.

Step 2. Click the Cisco MSE to which the event groups were synchronized.

Step 3. Click Context Aware Service.

Step 4. Click Notification Statistics.

Step 5. Verify the destination status for the destination you have defined.

5. Location Analytics

Location Analytics provides real-time location details alongside historical trends, enabling greater visibility into customer movements and patterns through trending data. IT can use analytics to determine network utilization, peak use, and the number and types of devices on the network. Lines of business can better understand how customers behave while onsite by tracking Wi-Fi signals within their venues, documenting customer movements throughout facilities, and using this comprehensive, context-aware data for engaging with customers more effectively.
The basic data is in the form of MAC addresses, time, coordinates, etc., which when analysed in location analytics produces information and knowledge about the movement and behavior patterns of the people using the tracked devices in that building. A "building" can be a shop, mall, airport, or city center, provided that it has a network of wireless access points enabling devices moving within that space to be located.
The full analysis comprises six processes: data cleaning, tagging, filtering, clustering, parameter estimation, and behavior mining. Figure 5 shows the overall architecture of the system within which location analytics fits.

Figure 5. Location Analytics Architecture

5.1 Implementing Location Analytics

Location service takes all input from Cisco MSE. It is installed as part of the Cisco MSE installation, but it needs to be explicitly enabled, by selecting Locational Analytics in the list of enabled services in Cisco Prime Infrastructure. If the user wants to use only data from specific parts of a network, then the user needs to edit the mse.properties file (opt/mse/analytics/intellify/tools/MSEclient/mse.properties) to select the network, building, and floor to be analyzed. If the default configuration is used, then the entire network is available for analysis.
Location analytics requires both floor plans and coverage areas inserted through Cisco Prime Infrastructure for the visualization and reporting functions to work. For each floor plan, you also need floor numbers. Floors on the same level should have the same number; higher-level floors should have higher numbers. The coverage areas correspond to the zones for which the user wants reports. Therefore, if the end user wants to know what is happening in location A, then an area delineating that location should be made in Cisco Prime Infrastructure and named as such. Zones, and hence areas, can overlap.

5.1.1 Enabling Location Analytics Using Cisco Prime Infrastructure

Follow the steps listed here to enable Location Analytics.

Step 1. Choose Services > Mobility Services Engine.

Step 2. Click MSE under Device Name.

Step 3. Check the box in front of Location Analytics Service to enable location analytics; then click Save to save your configuration.

5.2 Getting Information About Your Network

The process of downloading and creating the device and path database is automatic. If the installation is fresh, then the collection of data will start immediately and then continue to download incremental data every 15 minutes. If the installation is an upgrade of an existing Cisco MSE that has already been collecting data, then location analytics will download the last three days of data, process it, and continue polling every 15 minutes.

5.3 Performance Impact on Cisco MSE

Cisco MSE performance is affected by two Location Analytics processes: data polling and analytics processing. Tests have shown that the effect of data polling is negligible with a polling frequency of every 15 minutes. Analytics processing does have some impact on Cisco MSE, with it running on the same processor, and some additional provisions may have to be made. The analytics themselves have been optimized to work on only a sample of the data if the data set being requested is very large.

5.4 Viewing Location Analytics in 3D

You can view the results of location analytics in a three-dimensional (3D) environment. The 3D view gives the user an improved understanding of results, especially with multiple floor paths or when dwell times are calculated throughout a multistory building. The 3D environment presents the same information as the 2D version and is primarily for alternative visualization. The 2D view is currently obtained by enforcing a bird's-eye view in the interface control.

5.4.1 Configuring 3D

As of Cisco MSE Release 7.4, location analytics supports 3D only for building representations using WebGL. This advanced feature requires graphics capabilities (later releases will introduce 2D views based on OpenStreetMaps).
Not all browsers support WebGL on all devices. Check devices and browsers by following these setup suggestions:

Step 1. Test your browser for suitability at http://get.webgl.org/. If the test is successful, you should see a WebGL rotating cube. If the test is not successful, you may be able to update your video driver.

• For Chrome, see http://support.google.com/chrome/bin/answer.py?hl=en&answer=1220892.

• For Firefox, choose Help >Troubleshooting Information and then scroll down to Graphics and WebGL Renderer. Here you will see whether your system can support WebGL, and if it cannot, what is recommended.

• Other web browsers such as Maxthon have also been successful in running WebGL.

Ideally, the hardware should have a 3D graphics card to help ensure compatibly with WebGL. Most current Macs have graphics cards sufficiently configured to work with Safari. On PCs, the Chrome browser has been the most successful.

5.4.2 Exploring Location Analytics 3D

Follow the steps listed here to use Location Analytics 3D tools.

Step 1. Before exploring location analytics 3D tools, be sure that your system meets these criteria:

• The location analytics feature is installed and configured.

• Sufficient points and devices are present in the device and path database.

• Zones have been defined and overlays supplied.

Step 2. Log in using your credentials

Step 3. A Location Analytics window appears, divided into two areas.

• The left pane represents the controls for the analysis.

• The right pane shows the results in 3D.

Figure 6. Opening Analytics Screen with Default Building

5.4.3 Analysis Control Panel

The Analysis control panel (Figure 7) allows the user to define the type of analysis to perform and the subset of devices: for example, you can analyze the date, time, zone, etc.

Figure 7. Settings and Rules for Analysis

Different sets of analysis rule types are contained in collapsible areas, accessed by clicking their name or the arrow (Figure 8).

Figure 8. Settings and Rules for Analysis

Click to Invoke the Selected Analysis Type
The Analysis control panel is divided into sections identifying the subsets of devices for consideration and the types of analyses to be performed. These parts are described in the following sections.

5.4.3.1 Top Bar

The top bar of the interface (Figure 9) allows the user to switch modules, between analytics and reporting. The arrow at the right allows the Analysis control panel to be moved off screen, thus allowing greater space for the view. A similar arrow then allows the window to be restored.

Figure 9. Top Bar in Analysis Control Panel

5.4.3.2 Rules

The Rules section allows the user to identify the specific set of devices to which the analytics are to be applied. To describe the subset of this data, parameterized rule types have been created. Therefore, the rule for Date presents the user with valid dates of devices in the database. The Time rule allows the user to specify any hour and minute within 24 hours that a device was detected. Path rules identify devices with possible start, finish, and intermediate points on a path. A number of rules together constitute a rule set. These can be saved and loaded using the disk (save) icons shown in Figure 10.

Figure 10. Loading and Saving Rule Sets

The rules types are divided into five sections: Date/Time, Path, Annotations, Zones, and Filters.

5.4.3.3 Date/Time

The Date rule allows the user to select sets of dates. These can be either specific days or ranges of days. The calendar allows only valid dates to be selected, depending on the availability in the database (Figure 11).

Figure 11. Selecting a Date Range

The Time rules allow the user to select times of day in hours and minutes using temporal relations such as "before." "after," and "between" (Figure 12). A Time rule can be combined with a Date rule to focus the analysis on particular times across multiple days. If a Date rule is not set, analysis by default is performed for all days.

Figure 12. Selecting a Time Period for Analysis

5.4.3.4 Path

The Path rule (Figure 13) allows the user to select devices that have followed a particular path through predefined zones. You can choose the zone in which the device starts in (first detected), the zone in which it finishes (last detected), and any intermediate zones it passes through.

Figure 13. Selecting the Types of Paths for Analysis

5.4.3.5 Zones

The Zones option allows the user to constrain the analysis to selected zones. Therefore, if only one part of a building is of interest, then results will be shown for that zone only. In the case of typical location analysis, all areas will appear in that zone. For typical paths; these will be truncated to appear only within the zone. Zones are often hierarchical, and so the user can view results for large areas or for smaller areas. Figure 14 shows analysis and results restricted to one floor.

Figure 14. Restricting Analysis and Results to the Whole of Floor 1

5.4.3.6 Filters

Detected devices have intrinsic characteristics related to the quantity and quality of information around them. For example, a device may poll only twice and then disappear, which can result in a very low dwell time. Other devices may have many observations available for analysis, providing greater certainty about where they were and how their time was used. In other words, quantity influences the quality of the results. The Filters rules allow users to select the quality of the data on which to base any analysis.
The Length rule restricts the analysis to those paths within the sum of the straight-line distances between points. Duration restricts the analysis to the entire duration from the first and the last points on the path. Hops measures the number of location observations made on a path.
Figure 15 shows quantitative measures related to the paths detected.

Figure 15. Quantitative Constraints on Paths for Analysis

5.4.3.7 Point Duration

In estimating the dwell time for a point, it is common to allocate the duration between points at which a device has appeared consecutively at both. However, when consecutive points are in close proximity, it is assumed that the device is stationary, and therefore the points are collapsed and the durations are summed. This total is considered the actual duration, with a high level of confidence. When Actual Duration is selected, the analysis is performed only on points whose dwell times have high certainty; however, there are typically fewer of these than there are estimated values. Figure 16 shows constraint selections for different dwell-time calculations.

Figure 16. Constraints on Points with Different Dwell-Time Calculations

5.4.4 Choosing an Analysis Type

The Analysis Type options allow the user to apply fundamentally different analyses to the devices passing through a building or environment. The two types of analysis available are as follows:

• Typical Locations creates and analyzes different areas of the building or city and measures the behavior of people within each. The types of behavioral measurements available are dwell time, crowding, and number of devices. These parameters are described later in this document. The analysis starts with a mathematical point clustering process, which segments the total location space into representative areas based on where people have been detected.

• Typical Paths analyzes the behavior of people as they move through the building. Again, this analysis uses mathematical path clustering, which aggregates the paths into sets that are equivalent. Each resulting set is represented by an actual representative path and shown graphically by a set of observed points linked by straight edges.

5.4.5 Selecting a Building

The user may have configured a number of buildings within a network map in Cisco MSE and be collecting data on them. Typically, these buildings will not be adjacent, and they may be in different parts of the country. The Building Selection option allows the user to focus on each building that is available for analysis (Figure 17).

Figure 17. Building Selection

5.4.6 Using the Auxiliary Information Window

At the top right of the results window (Figure 18) is the auxiliary information menu, which provides access to the 3D navigation and visible overlays on the building and area.

Figure 18. 3D Navigation

After any analysis has been performed, this window also contains the legend for the results, as shown in Figure 19, which displays the median dwell times for a location analysis. It also provides (at the bottom) a results view control that allows the user to toggle the various nodes in the results (either locations or points on a path).

Figure 19. 3D Navigation and Information Panel

5.4.7 Performing Typical Location Analysis

Locational analysis is a way of segmenting all the points detected into representative areas on which parameters can be calculated. In this way, the analysis shows the changes in dwell time, number of devices, etc. across a whole building. The process initially clusters all the filtered devices into areas determined by the mathematical layout of the observations. Each point is allocated to an area, and each area is represented by a center point, which is shown. After the set of areas has been established, parameters associated with each area can then be calculated, reflecting the movement of users through that part of the building. Note that the concepts of areas and zones are different, but areas and zones are used together. Consider the following:

• A zone is a user-defined space with a name and can be used for reporting or for path-rule purposes.

• Zones can be overlapping and need not cover all the building.

• Areas are defined by mathematical clustering on the observable Wi-Fi points.

• Cluster areas can be used when there are no known zones established or to help ensure that all parts of the location space covered.

The parameters available for typical locations are:

• Dwell time

• Crowding index

• Number of devices detected

The results of location analysis are a set of areas represented by center points indicating the spread of device parameters. Each area has associated with it a set of behavioral parameters, each represented by icons.
Figure 20 shows a pattern of dwell time icons across a single floor of a shopping mall for early morning on a particular day. The areas of low dwell time, shown in yellow, correspond to locations in which people are moving more quickly, in contrast to the red areas, which show restaurants and offices, in which people are waiting.

Figure 20. Distribution of Average Dwell Times Across One Floor

In Figure 21, the number of devices is shown for the same locations. The menu allows each parameter to be selected and displayed so that users can switch between parameters.

Figure 21. Distribution of Devices Across One Floor

Floors can be visualized together (Figure 22), and the navigation buttons can be used to move around these floors. Location analytics also supports panning with the "w," "a," "s," and "d" keys or the arrow keys.

Figure 22. Distribution of Average Dwell Times across Multiple Floors

Clicking one of the points (Figure 23) displays a summary of the various parameters in that area in a pop-up balloon; the selected point turns green. This summary can also be obtained by using the Location Selection Counter (Figure 24). Notice that the scales are not absolute, but always relative to the selected points. Thus, you should not compare a low (yellow) reading from one set of results to a high (red) reading from another. At any time, the user can choose Bird's-Eye View to see any floor in 2D.

Figure 23. Visualization of Location Parameters

Figure 24. Visualization of Location Parameters

The parameters currently available are:

• Dwell time: This is an estimate of the time that a device is in an area or near a location. It indicates the elapsed time along the device path while the device was in that area.

• Crowding: This is a relative measure across all areas, normalized to the range 0 to 1. It is derived from the number of observed devices in that area and the size of that area.

• Number of devices passing: This parameter indicates the number of unique MAC addresses identified in that area and defined by the user filter conditions. The number of visits can also be calculated. Within a long time window, a device may reappear in the area after an elapsed time; this reappearance is then counted as a second visit.

The same type of location analysis can be performed on a single user-defined zone, if the user wants to focus on that part of the building. This analysis is performed through the rules by focusing on one zone and asking for one cluster in the Advanced options.
A more detailed analysis of the distribution of dwell times and other parameters can be obtained through the graph icons in the pop-up balloons (see Figure 24). This analysis provides a detailed view into the data for each parameter value (Figures 25 and 26).

Figure 25. Average Dwell Time by Number of Devices

Figure 26. Number of Devices Recorded During the Selected Time Period

5.4.7.1 Advanced Options

Associated with each type of analysis are a number of Advanced options, including Number of Locations (Figure 27). This setting indicates the number of locations or paths shown in the analysis results. A large number of locations for Typical Locations analysis will result in a dense concentration of markers across an area. With Typical Paths, it results in a greater range of possible paths.

Figure 27. Advanced Options for Typical Location and Path Analysis

5.4.8 Performing Typical Path Analysis

Path analysis presents the user with a set of typical paths taken and the parameters associated with them. There are usually too many paths to be easily viewed. Therefore, the paths are grouped into sets of similar geographical routes taken; these are called typical paths. Location analytics rules also allow you to focus in on certain types of values, such as the date, time, or location. Figure 28 shows one typical path across a shopping mall for a particular day and time window. The observed points on the path are shown and linked with a straight line. The color of the line indicates the relative speed (red being fastest) of the person. Paths can also go between floors (Figure 29), which is displayed well in 3D.

Figure 28. Typical Path Across One Floor

Figure 29. Typical Path Between Floors

Each path has parameter information associated with it, either on a node or edge. In Figure 30, the parameter balloon associated with the start point of a path is shown. This point is obtained either by clicking the node or using the location selector at the right. In the balloon, information is provided for the whole path.

Figure 30. Visualization of Path Parameters

This information includes:

• The number of paths in the cluster

• The distance traveled overall in a straight line (in meters)

• The number of point observations recorded along this path

• The time taken to complete this path

• The average speed along the path (in kilometers per hour)

• Date and time of the first recorded point on the path

• Date and time of the last recorded point on the path

For a particular point, the parameters are,

• Arrival date and time

• Zones in which the point is located

• Any tags associated with this point

For a particular edge, the parameters are:

• The direct distance between the two points that the edge joins

• The difference in time between the two points

• The estimated speed between the two points

Because the device movement is known only at discrete points, it is difficult to predict how the user actually spent time between observations. This time can be shown in two ways on the path:

• All the time is attributed to the node. This approach assumes that the device stays at the node and quickly moves to the next node.

• All the time is attributed to the edge. This approach assumes that the device is continually moving and never halts.

Reality is likely to be somewhere between these two extremes. However, when sequential points are close to each other, it is assumed that the device is stationary, and the dwell time can be attributed to that group of nodes. In location analytics, these nodes are replaced automatically by a single node.

5.4.9 Using Reports

The reporting facility in location analytics software provides a more regular, manager-oriented set of information. Typically, the online analytics provides the mechanism for comprehensive impromptu investigation of behavior patterns, and reports are used for common, repeated analyses. For instance, an operator or planner would use the information provided by the online analytics to investigate special circumstances. The manager would expect only higher-level information in an easily viewable format daily or weekly, for example. Reporting nevertheless provides comprehensive analytic insight and provides a degree of flexibility in the types of parameters used in the reports. The report generator used in this release is Birt (http://www.eclipse.org/birt).
The reporting function can be accessed through the top-level icons or through the Reporting tab in the online Analytics view. Five report templates are available in this release.

5.4.9.1 Snapshot

The Snapshot report (Figure 31) breaks the selected day into predefined time windows, and within each window gives the number of devices that have been observed in each zone of the building. In addition, each device is separated according to its dwell time (< 5 minutes, or >= 5 minutes), to distinguish people passing through the zone and people staying a significant time in the zone.

Figure 31. Snapshot Report

5.4.9.2 Movement

The Movement report (Figure 32) allows the user to nominate a reference zone and to then understand which other zones people come from and go to from that reference zone. This analysis is specified within a time window across a continuous set of days.

Figure 32. Movement Report

5.4.9.3 Number of Devices and Dwell

The Number of Devices and Dwell report (Figure 33) allows the user to compare the same time window across consecutive days for a particular zone in terms of number of devices, categorized by dwell time. The dwell-time ranges provided in this report template are:
1. Less than 5 minutes (passing through)
2. 5 to 45 minutes (short-term customers)
3. 45 minutes to 2 hours (long-term customers)
4. Greater than 2 hours (staff)
5. All devices detected
The ranges are meant to reflect the different levels of interaction by the customers in that zone.

Figure 33. Number of Devices and Dwell Report

5.4.9.4 Daily Dwell Time

The Daily Dwell Time report (Figure 34) provides the average dwell time in 15-minute segments for any time window for a specified day and a specified zone. This report template filters out devices with very short dwell times (for example, people passing through the zone in less than 5 minutes) and very long dwell times (for example, people actually working in that zone).

Figure 34. Daily Dwell Time Report (15 Minutes)

5.4.9.5 Frequently Seen Devices

The Frequently Seen Devices report (Figure 35) allows the user to select a date and time window and request the top N devices seen in that period. The results provide the IDs of the N devices as well as the frequency distribution of those devices.

Figure 35. Frequently Seen Devices Report

Appendix

The context-aware service in Cisco MSE can detect and track the location of wireless devices. As long as Wi-Fi is turned on in a wireless device, Cisco MSE can detect the device (even if the device is not associated with a wireless network). Cisco MSE has an open API to get location and history information for different wireless devices as well as to configure various parameters on Cisco MSE.
A main feature of Cisco MSE is its capability to broadcast a real-time stream of events to a destination. Cisco MSE can generate and send multiple types of events, but for the purposes of this document, the events of interest are:
1. Location update events
2. Containment events
3. Generic northbound notifications

5.5 Location Update Events

Location update events are configurable events that can direct Cisco MSE to generate notifications whenever a wireless device moves a certain distance. This feature can be enabled using the API and requires the following information:

• URL of the event receiver

• Movement distance

• Message protocol: XML or text

• Destination type: Simple Object Access Protocol (SOAP), Simple Network Management Protocol (SNMP), or syslog

• Device type: client, rogue, tag, or interferer

• MAC address filter

Every location update event that is sent by Cisco MSE includes the MAC address of the device, the floor on which the device is located, and the x, y coordinates of the device on the floor, among other information.

5.6 Containment Events

Containment events are configurable events that can direct Cisco MSE to generate notifications whenever a wireless device enters or exits a particular zone or area on a floor. This feature can be enabled using the API and requires the following information:

• URL of the event receiver

• Zone or area of interest

• Location: inside or outside

• Message protocol: XML or text

• Destination type: SOAP, SNMP, or syslog

• Device type: client, rogue, tag, or interferer

• MAC address filter

Every containment event that is sent by Cisco MSE includes the MAC address of the device, the zone or area in which the device was detected, and information indicating whether the device was inside or outside the zone.

5.7 Generic Northbound Notifications

Cisco MSE can send a real-time stream of all the activity for all clients to a destination. These notifications are a superset of the location update events. This feature can be enabled using the API and requires the following information:

• URL of the event receiver

• Device type: client

• Trigger type: location change or presence

• Notification contents: location, custom key-value pair, and secure system ID (SSID)