As IT is being asked to do more with less — or at least with the same tools/resources/structure that they have today — WLAN technologies need to do a better job of fitting in. For most organizations, Wireless LAN started out as a pet project or a “nice to have.”

As is typical with these semi-half-baked deployments that are for “playing around with”, they become mission critical overnight and IT is asked (OK, demanded) to maintain and operate them with the same level of service as every other piece on infrastructure on the network. In most organizations this has meant that the poor network engineer who designed the initial deployment now has to figure out “Phase 2″ as well as keep the existing set-up in place and operational. This typically means moving to a controller-based design that automates much of the manual processes involved in tuning and updating wireless devices. This new architecture solved some of the short term issues around RF management and centralization of traffic.

Now comes phase 3: figuring out how to take this wireless LAN and truly fold it into the entire network operations environment and provide a scalable way to support it (aka ITIL).

The first step in this process involves organizations looking at how to tie in the WLAN with their existing event correlation and helpdesk systems. As an example, many organizations are using Remedy for trouble ticketing and EMC SMARTS for event correlation (there are obviously lots of other solutions on the market, these are just common systems that I run into in the field). Support for the WLAN needs to come in 2 directions, pro-active and re-active. Pro-active where the network itself tells you there is a problem and creates a process for resolution; re-active is where users call in and tell IT that there is something wrong.

For the pro-active model, IT can set up their WLAN infrastructure to send traps to SMARTS as well as all the other network components (switches, routers, authentication servers, etc.) AirWave can also send traps to SMARTS based on more intelligent WLAN events than you get from the WLAN devices themselves (too many users, too much bandwidth over x amount of time, too many authentication failure, rogue devices, etc). SMARTS is able to correlate all of this information and then generate tickets within Remedy for the IT organization to go out and solve. For WLAN specific issues this can include going in to the AirWave console to troubleshoot and resolve those problems.

For the re-active model, IT can generate a ticket directly within Remedy and then tie in WLAN specific information from AirWave (AirWave now integrated with Remedy). The helpdesk can post information about the condition of the WLAN on the spot with very little understanding of wireless LAN specific issues. If the issues needs to be escalated then all of the time relevant information gets passed on to the level 2/3 teams to resolve.

By tying these 3 systems together, the IT organization can leverage their existing investments, processes, and tool sets to now manage the WLAN.