nOversight
  • nOversight Tutorial
    • nOversight iOS log analysis
      • Getting Started with Analysing Log Data
      • Download and Install
      • nOversight Overview
      • Live Captures & Recordings
        • Sysdiagnose offline logs
      • Control Panel
        • Managing recording files
        • Zooming in on the time of interest
        • Exporting Reports
        • Settings
      • nOversight Wi-Fi Analysis
        • The Timeline Slider
        • Live View (Top screen)
        • Analysis Views (Bottom half)
          • Session Timeline
          • Session Explorer
          • Network Overview
          • Scores and Advisories
          • Connection Monitor
      • nOversight Wi-Fi Reports
      • nOversight Wi-Fi Map
Powered by GitBook
On this page
  • The Session List
  • The Session Flow
  • Additional Detail
  1. nOversight Tutorial
  2. nOversight iOS log analysis
  3. nOversight Wi-Fi Analysis
  4. Analysis Views (Bottom half)

Session Explorer

The session explorer is used to navigate through each session and go into the detail.

PreviousSession TimelineNextNetwork Overview

Navigating through the sessions is as easy as selecting a session in the Session List, or sliding through the Session Cards. The Timeline Slider shows a yellow overlay over the timeline corresponding to the currently selected session.

The Session List

This area lists the sessions in chronological order (first session captured at the top). It provides an 'at-a-glance' approach to understanding where a poor session might be experienced.

Signals

The colored signal column quickly informs how well a particular session met the design criteria for received signal strength. It shows how well the signals have met the secondary RSSI threshold (the lower of the two).

The format is: % Signals < Secondary RSSI (Minimum recorded RSSI for the Session)

Sessions with a significant number of RSSI measurements below the secondary RSSI threshold could be considered to be part of a concern where the device is unable to find an AP with suitable signal strength.

The coloring is calculated as follows

  • Green: < 10% measurements below secondary RSSI

  • Amber: 10 – 20% measurements below secondary RSSI

  • Red: > 20% measurements below secondary RSSI

Indicators

There are 4 indicators to allow easy identification of issues.

  • Beacons Lost. This will have a check mark in it if this session reported beacons lost. When this shows it is a good indication that the device has gone out of range of the connected AP and did not manage to roam in time

  • Short Session. This indicates that the session length was less than the session threshold configured in settings. Sometimes this is fine, but in many case it can indicate instability. In the worst scenarios you will see a lot of bouncing between APs when this flag happens

  • Medium Busy. This indicates that a session was determined to be busy according to the thresholds you configured in settings. This network is working hard but it is coping - quite normal for high density environments such as stadia

  • Medium Congested. This indicates the medium is utilised more than your upper threshold (e.g., 80%) and it would be expected to have very poor performance. A lot of sessions like this are likey to indicate an unusable environment.

An example of what you might see in a congested environment

The Session Flow

The session flow is where the main roaming analysis takes place.The objective is to determine if roaming

  1. Happens at the right time and is quick

  2. Is effective in finding the next AP

  3. Is triggered for the right reasons.

The session flow is made up of a card per session. Each card provide the following

  • Details of the connected network equipment (AP, Cell Tower) and the environment

  • The signals specific to this session

  • A roaming table

    • How much of the session was spent attempting to roam

    • A chronological list of the roaming events to understand the decisions the device logic went through to arrive at the final outcome

Roaming analysis uncovers a lot of information which is not available anywhere else.

The internal device logic cannot be seen anywhere except the device. This is not usually reported to the controller (however there are some recent vendor announcements indicating that this may change for some vendor-client relationships)

What is interesting is looking at why roams happen.

  • Most roam attempts will have the reason "Low RSSI" which is where the internal signal strength triggers start the roaming process.

  • You can observe AP initiated roams for band steering and load balancing. These are BTM - BSS Transition Management which allow an AP to request a station to transition to a specific AP, or suggest a set of preferred APs, due to network load balancing or termination of the connection with the current AP. This helps the station identify the best AP from the list of candidates sent. The AP does not always follow the request though!

Look out for the different roam reasons when you do your testing

Additional Detail

The additional detail gives 3 areas of additional information for each session

  1. A histogram of RSSI for the session. Useful to quickly identify if the session was dragging on weak signal

  1. A list of APs the device was specifically looking for in the scan (not always made available in the log)

  1. The reasons for all roam attmepts within this session.

Yellow highlight indicates signals in selected session
Overview of the Session Explorer