Review: Motorola Mobility Services Platform (MSP) (RF Management Suite, Part 3 of 4)
Page 1 of 3
Motorola Mobility Services Platform, RF Management Edition
Price: from $ 6,500 for 50 APs
Pros: Scalable config and software management, enabler for RFMS monitoring
Cons: Jam-packed GUI, overlapping events, no per-user resource views
Motorola's Mobility Services Platform (MSP) provides single-point "care and feeding" for distributed WLANs composed of Motorola switches, access points, and clients. This Java-based console enables centralized execution of common management tasks, including configuration, maintenance, and monitoring.
Although these operations can be aimed at individual devices, the MSP excels at performing them on tens, hundreds, or even thousands of devices, grouped by site or type. The MSP's goal is to reduce total cost of operation for "enterprise mobility domains" by automating repetitive tasks, detecting unexpected changes, summarizing overall health, and calling attention to critical faults.
We tested the MSP RF Management Edition: a software bundle that combines MSP configuration/fault management with RFMS performance management. In this review, we focus on the MSP and its lynchpin role in Motorola's RF Management Suite. RFMS, also sold separately, is reviewed in part 4 of this series, coming next month. (Click here for parts 1 and 2.)
An MSP license lets you manage 50 APs ($6,500), up to 2,000 APs ($35,595). However, the number of devices (switches, APs, clients) a single MSP can monitor effectively depends on server horsepower and load factors like SNMP poll interval. Originally, the MSP was sold as two appliances: Lite (up to 100 devices) and Enterprise (up to 5,000 devices). Today, Motorola also sells MSP software for RedHat, SUSE, and Debian Linux. We tested v2.9 DCP 0500 MSP software running on a 3 GHz Pentium 4 laptop VMware session.
One MSP easily managed several small sites during our review (albeit with occasional VMware glitches), but large enterprise WLANs require more than one server. In that case, a central Master MSP can provide event aggregation from and single sign-on to Subsidiary MSPs distributed throughout a mobility domain. For example, an enterprise WLAN might be segmented geographically, deploying regional MSPs to maintain devices, listen for traps, and poll data, while forwarding events to one central MSP for enterprise-wide monitoring.
MSP users are granted role-based access to resources (e.g., read-only guests, read/write mobile client admins, read/write network admins). But to our surprise, every device managed by an MSP is visible to every user account. During our tests, Motorola admins had access to our test sites and vice versa. In an enterprise-class product like this, we'd prefer to control admin access at group or site level (expected in the next release).
Availability can also be critical for large enterprises. Redundancy is accomplished by installing a cold-standby MSP with access to scheduled FTP backups generated by an active MSP. If the cold-standby cannot simply assume the failed server's IP address, all managed devices would need to send traps to both active and cold-standby MSPs. While not as efficient as active-active HA, this scheme supplies the policies and data needed to continue non-real-time management tasks during an MSP server outage.
Portals and Portlets
In enterprise management consoles, the trick is to somehow meld power with simplicity. The MSP GUI takes a valiant stab at this goal, with room for improvement.
For example, the MSP "Home Portal" provides a wealth of summary data. From this one console, NOC staff can eyeball the entire domain by asset headcount, health status, management job status, data collection statistics, and a list of recently-discovered APs. These and many other data nuggets are presented through a plethora of "Portlets" that can be customized to fit each MSP user's job and personal preferences.
Figure 1. MSP Home Portal. (Click image for larger version.)
Customizable summaries are nice, but the devil is in the detail. We found the Home Portal far too busy, yet its summaries were too superficial. Beneath this "eye candy" lay many other Portals and Portlets, jam-packed with functionality. We almost always clicked right past the Home Portal, heading for screens where management tasks take placetypically the Mobile Infrastructure Portal. However, the sheer number of parameters found on many Portlets can be overwhelming. In our opinion, this GUI alternates between overly simple and intensely complex and would benefit from more comfy middle ground.
To its credit, this GUI is capable of administering every device in a Motorola WLAN. (To ensure this, all WLAN firmware updates are tested with the MSP prior to release.) We used the MSP to manage Motorola Wireless Next Generation (WiNG) infrastructureincluding stand-alone "fat" APs and switches with "thin" APs (in Moto-speak, access ports). The MSP can also manage Motorola/Symbol mobile units (MUs) and legacy Symbol APs (non-WiNG devices). This breadth is excellentalthough it understandably stops short of third-party APs.
However, squeezing diverse devices into one console inevitably adds complexity. For example, APs and MUs are provisioned very differently, albeit through the same Portalsadmins must learn which Portlets, tasks, and options apply to each. Stats collected about fat and thin APs are presented entirely differentlyadmins must learn where to look for each.
In short, the MSP does an admirable job of gluing together Motorola's broad product line, but it cannot hide all the seams. Users managing diverse devices (e.g., retailers) will benefit the most from this all-under-one-roof approach, while those with relatively homogenous WLANs (e.g., carpeted offices) get more knobs than they really need.