The Sapphire Eye of RF

7signal came from the mobile phone provider side providing metrics for service assurance and performance optimization such as quality of experience, key performance indicators, service level agreements and end to end user view. This helps the end user experience to ensure success rates, throughput latency, packet loss, jitter, and MOS. There are 3 elements in their solution: sensors (eyes), sonar which is the software test endpoint, and the carat which manages eyes, provides reports, alarms and analyzer. One eye unit can cover 4 – 8 access points. The eye unit can do both active and passive tests. Sapphire data covers all layers, 1 – 7. For example:
[list_3]

  • Synthetic tests (L1-L7) – End to end view at application layer, data and voice quality measurements
  • Traffic Analysis (L2) – Radio frame header analysis for traffic flow between clients and access points, KPIs for each client, SSID, AP band, and antenna beam
  • RF Analysis (L1-L2) – AP settings and capabilities, signal levels, channels, noise
  • Troubleshooting Tests (L1-L7) – Remote testing. Scheduled tests without interfering

[/list_3]
Carat and Sonar run on Linux servers, CentOS or RedHat. They can be either virtual servers or dedicated servers. The software runs from a IBM DB2 database which is scalable and expandable. There is a test scheduler which can be used to setup jobs to run. The engine software provides the alarm generation, report generation, and analyzer. The solution allows for multiple level user administration as well as multi-tenant.

The Eye sensor is a PowerPC based linux computer with an Atheros based WLAN. It’s an array of high gain patch antennas each having a 7.5 dB gain with a front back ratio of 15-20 dB and -3dB bandwidth of 60-75%.This approach allows low amount of sensors but still providing a high level of performance.

The idea behind their product is to be more proactive about the network and eliminate help desk calls by allowing admins to know of a problem before the user does. The problem with this is that while it sounds like a great idea, it’s not practical. The Eye could report a quality network but a bad driver will kill a client. While I appreciate the historical data most of the time I care about what is happening now and what an easy way to view that data. Creating a report, having it generate, then review is not optimal. Mobility happens so fast that we need fast access to data.

I think their solution could work for more MSP style organizations but like George Stefanick mentioned on twitter trying to be so proactive with alerts and what not introduces a potential for a lot of false positives which deter from the real alerts. I think the most interesting aspect of what they had to offer was the teaser about portable units running on the Raspberry Pi, I wish we would have had more time to discuss that solution.

Leave a Reply