Review: Motorola RF Management Software v2.0 (RF Management Suite Part 4)

Motorola RF Management Software v2.0


www.motorola.com


Price: From $ 4,595 for 50 APs
Pros:   Strong visuals enable at-a-glance status and detailed performance analysis.
Cons: Multiple conflicting task methods; little historical reporting.


RFMS-icon.gif


 


When we took Motorola’s four-piece RF Management Suite out for a test drive, we used the integrated RF Management Software v2.0 (RFMS) component to visualize real-time status, current health, and recent performance. RFMS is a Java-based console designed to facilitate monitoring and troubleshooting of RF networks composed of Motorola APs, switches, and clients. By recording and analyzing the performance data collected from all of those devices, RFMS turns what you cannot otherwise see into colorful charts and graphs that convey both current status and statistical insights.


 


RFMS v2.0 can be deployed as a stand-alone monitor by purchasing a “base pack” (starting at $4,595 for 50 APs, maximum 2000 devices). But we tested RFMS v2.0 bundled with Motorola’s Mobility Services Platform (MSP) RF Management Edition ($ 6,500 for 50 APs). When deployed in this fashion, there is no need to buy a separate RFMS license. However, RFMS then depends upon the MSP to collect site asset and performance data using SNMP (see part 3 of this series for our in-depth MSP review).


 


Getting started with RFMS


 


RFMS v2.0 runs on a Windows XP SP2 PC with at least a 3.2 GHz dual-core CPU, 2GB RAM, and 80GB of disk storage. All output is delivered through the included Apache Tomcat Web server and presented to users via Firefox 1.5, IE 6.0, Mozilla 1.7, or Netscape 7.2 browsers, equipped with JRE 1.4 or later.


 


As described in part 1 of this series, we tested RFMS v2.0 and MSP v2.9 servers that Motorola had installed on their own 3GHz laptop, which we accessed via RDP. With the integrated suite, both servers must run on the same PC. However, this review laptop was a bit under-powered, resulting in sluggish page refreshes and occasional hung sessions. We have no doubt that RFMS is more responsive and reliable on beefier PCs, but this GUI is also chock full of rapidly refreshing Java and Flash graphics. As a result, we recommend that RFMS users plan to meet or beat Motorola’s minimum platform specs.


 


After stand-alone RFMS installation, Web user accounts must be configured, using one or two access levels: Admin users can access RFMS planning pages, while Support users are limited to troubleshooting pages. Integrated MSP RF Edition installations can skip this step, because MSP users are permitted to access RFMS Web pages with a single sign-on. MSP users just click on the RFMS button on MSP-displayed Site and Event pages to launch a new RFMS browser window that monitors that single Site.


 

Fig41-ManualPlan_sm.jpg


Figure 4.1 – A plan drawn within RFMS, using manual placement. Click to enlarge.


 


These modeling parameters are not as detailed as those used by the LAN Planner—for instance, they only define two-dimensional coverage areas. However, RFMS really must have a good grasp on RF barriers to generate useful heat maps. If you don’t add realistic barriers (or import a LAN Plan that includes them), RFMS will just end up displaying roughly circular coverage bands and RSSI-based locationing will be inaccurate.


 


With auto-placement, those barriers and coverage areas are used to suggest where APs belong. Specifically, RFMS will create and place your specified number of APs to satisfy coverage needs. Our simple remote office WLAN did not really give this feature a good workout, nor will many small WLANs. Customers with large, multi-story or distributed WLANs are likely to use the full-blown LAN Planner. As a result, auto-placement felt like an intriguing, but evolutionary step in RFMS development, surpassed by recently-added LAN Planner integration.


 


In fact, LAN Planner integration was so new that we ran into a few hiccups during import. We had to install a newer version of LAN Planner, then patch the MSP/RFMS, before we could export zip files from LAN Planner and import them into RFMS, one floor per Site. When we updated and re-imported LAN Planner output, the Site’s old background continued to be displayed until we cleared our browser’s cache.


 


Fig42-ImportedPlan_sm.jpg


 


Figure 4.2 – A plan imported from LAN Planner and populated by the MSP. Click to enlarge.


 


Our biggest plan import gripe turned out to be a “works as designed” feature. With the integrated MSP/RFMS, the MSP automatically populates each Site in RFMS by putting all discovered switches and APs in the upper-left corner of the floor plan. Here again, kudos for avoiding duplicate data entry. However, the background image generated by LAN Planner shows intended AP locations using “target” symbols and text labels. The RFMS administrator must drag and drop each MSP-created APs onto those targets. We found it all too easy to place the wrong AP on each target—in a larger WLANs, this would clearly be tedious and error-prone. We hope that future versions of RFMS will automatically place MSP-discovered onto imported plan targets.


 


Go to page 3.

Real-time Status: Are you there now?


 


After Sites have been associated with floor plans and populated with devices, the RFMS Presence tab can be used to visualize their current status, coverage, and location. All of this information is displayed by RFMS in near-real-time, reflecting the latest SNMP poll results.


 


For example, the Devices page lets you easily see which switches, APs, and/or clients are currently up or down. Clients—called Mobile Units (MUs)—are displayed in the Site list only when actively associated to an AP. “Access Points” (thick APs) and “Access Ports” (thin APs adopted by switches) are persistently displayed both in the Site list and on your floor plan, along with a green or red marker indicating current status (up or down).


 


RFMS also summarizes Site status by presenting total MU, AP up, and AP down counts. These counts are handy and intuitive for thick APs, but we found them confusing for thin APs. “AP up” grows whenever a thin AP is adopted by a switch. But if that AP is disconnected, “AP down” count does not change. If someone steals an Access Port or yanks its Ethernet cable loose, that thin AP simply disappears from RFMS. That reflects current status and simplifies map maintenance when thin APs are relocated (e.g., for load balancing across switches), but we think it impedes troubleshooting.


 


Fig43-RFCover.jpg


Figure 4.3 – RF coverage heat map


 


Coverage and Spectrum pages can be used to eyeball your Site’s 11a or 11b/g RF footprints in real-time. The Coverage page generates a heat map—red hot areas surrounding each AP, gradually diminishing to orange and yellow as signal strength falls due to distance and attenuation. Hover your mouse over this map to display the RSSI that a client might currently experience at that location, based on RFMS’s understanding of that Site’s RF environment, active devices, and recently-polled performance attributes. Spectrum takes a somewhat broader perspective, helping you visualize per-channel coverage, plotted across your entire floor plan in a similar fashion.


 


Near-real-time up/down status and heat maps like these are aimed at WLAN help desks responsible for trouble-shooting user connectivity issues from a central location. By the time you can send someone to a user’s location, RF coverage may have changed—help desks need to see these kinds of measurements in real-time, and RFMS lets you do so without requiring the user to run client-side diagnostic tools.


 


Device locationing: Where are you?


 


These status tools become more powerful when combined with near-real-time locationing. RFMSv2.0 can take a snapshot of currently-active MU or rogue AP locations, plotting them on your floor plan.


 


Specifically, the Presence / Locate MUs page can be used to request the location of one, some, or all currently active client devices. Two locationing methods are available for MUs: RSSI triangulation or fingerprinting.


 



  • MU fingerprinting requires at least three APs near the target MU, which must itself be configured to respond to AP probes. Fingerprinting compares real-time RSSI reports to earlier readings, taken at specified coordinates. To fingerprint a site, an administrator performs a site walk-through, using a laptop or PDA to record RSSI values using the RFMS Fingerprint page. Later, when you want to plot an MU’s current location, the Locate MUs page tells APs to probe a specified MU so that RFMS can compare stored RSSI values to AP-reported RSSI values.

 



  • MU triangulation also uses real-time RSSI readings, but estimates a “rogue” client’s current location by computing probable distance from at least three nearby APs to identify their intersection. According to RFMS documentation, both methods are accurate to within ten meters—but RF fingerprinting based on good reference samples can be more precise than triangulation. Due to our test bed set-up, we could not test fingerprinting. However, triangulation for MUs between our three APs was fairly accurate.

 


RFMSv2.0 also provides two mutually exclusive methods of rogue AP detection: standard and enhanced.


 



  • Standard rogue AP detection relies upon observations made by Motorola switches, configured to overhear nearby APs and report them via SNMP. In this case, RFMSv2.0 simply aggregates all reported rogues into one Security / Rogue AP table, using charts to help you visualize rogue RSSI and channel distribution. Although Motorola APs can be configured to recognize (and ignore) selected APs, RFMS does not let you tag or remove neighbors from its rogue AP list.

 



  • Enhanced rogue AP detection lets RFMS locate rogue APs using RSSI-based triangulation (similar to MU triangulation). Standard detection must be disabled and Enhanced detection enabled for each switch, specifying rogue scan interval, scan duration, and scanned channel list. Thereafter, the RFMS Security / Rogue AP table will be empty. However, the RFMS Presence / Locate Rogues page can now be used to generate a current snapshot of active rogue APs, mapped in relationship to your own APs on your Site floor plan.

 


 Fig44-StdRogue_sm.jpg


Click to enlarge.


 


 


Fig45-AdvRogue_sm.jpg


Figure 4.4 (above) and 4.5 – Standard vs. Enhanced rogue AP detection. Click to enlarge.


 


In our experience, Standard detection worked well, but Enhanced detection results for each rogue AP varied quite a bit. Our APs may not have been separated enough: three AP-300s were placed as far apart as we could in a 200 x 100-foot area. In larger WLANs, locationing can also be strengthened by RFID readers, which we did not test.


 


Alternatively, rogue AP detection and locationing can be performed by the Motorola (AirDefense) Wireless IPS—a fourth member of the RF Management Suite. Customers that deploy the entire suite can dynamically convert any AP-300 into a full-time WIPS sensor, then use the WIPS console to view rogue AP alerts and locations. Given Motorola’s recent acquisition of AirDefense, we expect to see this part of RFMS evolve as the WIPS, MSP, and RFMS become more tightly integrated.


 


Go to page 4.

Performance monitoring: How are you feeling right now?


 


Statistical analysis is the biggest value-add that RFMS brings to the RF Management Suite. As described in part 3 of this series, the MSP can collect performance data from all devices throughout an enterprise WLAN, but it defers to RFMS to make sense of that data. RFMS steps up to the plate by delivering over 200 statistics that can help administrators visualize and optimize WLAN availability and performance.


 


In a stand-alone deployment, RFMS Statistics start with an All Sites summary table that lists per-Site device/radio up/down counts, active MU and rogue AP counts, and average RF signal strength. This table is accompanied by a few overall summary charts, such as the percentage of sites falling into five RFMS-defined RF coverage categories.


 


Detailed stats begin at the individual Site level, reached by selecting a node on the Site tree (as when RFMS is launched from the MSP). Here, extensive per-Site stats are organized into two categories: Network Utilization and Infrastructure.


 


Network utilization aggregates performance data collected for all devices at a single Site, producing graphs and trend lines covering Key Performance Indicators (KPIs), signal strength, AP/MU/WLAN utilization, and service interruptions.


 


For example, KPIs weight RF coverage, load balancing, security, redundancy, and network utilization on a “spider web” that plots current versus best value for each. The KPI page also displays average retries and bitspeed per radio and MU, presented as bar graphs (covering the last 30 seconds and hour) or trend lines (showing how polled values changed over time).


 


Fig46-KPI_sm.jpg     


  


  Fig47-Trend_sm.jpg


Figure 4.6 (above) and 4.7 – Key Performance Indicator Graph and Trend Line. Click to enlarge.


 


These and other utilization graphs are intended to convey network health at-a-glance, giving operators the ability to quickly determine if and where performance problems lie, backed by raw data. But stats—even roll-up stats like KPIs—are not always intuitive. RFMS addresses this by providing an “expert view” for each network utilization page that suggests potential problems and resolutions.


 


Fig48-Signal_lg.jpg


 


Figure 4.8 – Signal Strength Graph and corresponding Expert View


 


These RFMS graphs and expert views offer a lot of promise. Frankly, we could not judge stat accuracy—these variables change too quickly. But we did try to use network utilization pages to spot and diagnose simulated problems. Usually, RFMS stats reflected the problems we (intentionally) caused. However, we did not gain as much insight as we’d hoped from expert views—or mouse-over “quick tips.” These more advanced outputs will no doubt be augmented as RFMS matures.


 


Finally, Infrastructure pages drill into data collected about individual entities (APs, switches, radios, MUs, and SSIDs) within a single Site.


 


For example, Access Point graphs plot signal, noise, utilization, and LAN/WAN packets for any AP-5131 or AP-5181. These graphs are displayed by selecting a desired AP from the table summarizing all APs discovered at (or created for) a single Site. If you don’t immediately see the AP you’re looking for, a search tool can be used to find it by name, IP address, or MAC address. Once you’ve spotted a potential problem, further detail can be obtained in two ways: (1) by using the Raw Data panel to view recent stats or (2) by connecting to the AP itself via Telnet or HTTP. A nice addition here would be a button that brings you back to the corresponding device in the MSP console.


 


Fig49-Radios_sm.jpg      Fig49-Radios_sm.jpgFig410-MUs_sm.jpg


Figure 4.9 (left) and 4.10 – Infrastructure stats for Radios and Raw Data for MUs. Click to enlarge.


 


A conceptually similar Infrastructure panel plots signal, noise, utilization, and bitspeed for any WS-2000, 5100, or 7000 switch—but RFMS does not show stats for individual thin APs. If you want to drill down further, go to the Radios panel, which displays similar stats for each radio (whether housed by a thick or thin AP). Or ask RFMS to slice the pie differently, displaying stats for each SSID (WLAN) at the selected Site.


 


These are real-time graphs, displayed for entities that are currently active, plotted over 30-second and one-hour look-back periods. As a result, stats can only be seen for MUs that are actively associated—or for SSIDs currently carrying traffic. This approach is sensible for dynamic entities—just think of how many MUs would accumulate over time! But it did complicate troubleshooting for disconnected thin APs and even one switch that went AWOL due to a firmware bug. Overall, we found the currency of these pages very helpful, but we also like the ability to zoom out to longer periods and/or adjust graph refresh rates.


 


Reporting: How have you been?


 


Even though RFMS tends to “live in the moment,” there are a couple of ways that you can record this information for posterity. First, many of the individual tables displayed by RFMS can be exported to .CSV files. Second, RFMS can generate six canned PDF reports on demand: Service Interruptions, Planning, Security, AP Utilization, KPI, and Signal Strength.


 


For example, the Service Interruptions report identifies the most recent off-line event for each device, including reboots, excessive retries when attempting to poll the device, or inability to reach the device. The Planning report prints a Site floor plan, including configured device locations. The Security report enumerates all previously-detected rogue MUs and rogue APs. And so on.


 


Fig411-RFMS-Report.jpg


Figure 4.11 – Example RFMS Reports


 


RFMS reports are not as visual as RFMS graphs—in fact, the ability to freeze and export or print graphs would be a nice addition. More importantly, RFMS reports are not really historical performance reports—they are raw data tables, printed to PDF instead of being exported to CSV. RFMS has access to historical data; we would love to print the same report for last week or last month, so that we could compare past and current stats.


 


Conclusion


 


We found RFMSv2.0 to be a highly visual WLAN monitoring and troubleshooting tool, focused on centralized analysis and display of near-real-time status and performance. Help desk staff and administrators for Motorola WLANs can certainly benefit from RFMSv2.0 today. But expert views hint at how RFMS could mature into a more powerful tool over time.


 


On the other hand, multiple ways of accomplishing the same tasks make RFMS more complex—examples include standard vs. enhanced rogue detection and manual vs. automated vs. imported AP placement. Some older methods could potentially be retired if RFMS can depend more heavily on other RF Management Suite products to perform functions, such as planning and locationing.


 


As discussed in part 1, the RF Management Suite touches on all aspects of wireless management, from planning to maintenance, from fault surveillance to security and performance monitoring. Now that these pieces live under one roof, Motorola can start to polish the seams that are visible between products originally developed by Motorola, Symbol, Wireless Valley, and AirDefense. In fact, after we completed our tests, Motorola released an updated RF Management Suite v3 with tighter WIPS integration. Clearly, this entire suite will continue to evolve—including support for new Motorola 802.11n devices and incorporation of wireless technologies that go beyond Wi-Fi.


 


Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies.

News Around the Web