Mobility
Express Capability is exhibited only by Wave 2 Access points from Cisco. These
are primarily called as COS APs.
The
predecessor of COS APs were the IOS APs which can support only the Autonomous
AP capability. Though both Autonomous and ME APs do not require an AP license
and the controller, however ME APs are more advantagous in a sense that the ME
AP attains the role of a controller (referred as master AP) and can terminate
upto 100 APs (referred to as sub-ordinate APs) while the autonomous AP just act
as a single independent AP with no posibility of co-ordination with other APs
in the network.
(Similar
concept exists in Aruba for the APs exhibiting controller capability and they
refer it as IAP. Every model of Aruba AP comes in two forms, either Aruba AP or
Aruba Instant AP. When ordered as Aruba Instant AP, it can be converted back to
normal AP but when ordered as Aruba AP, it cannot be converted back to Aruba
Instant AP. Thus care should be taken while placing the order )
Pre-requisites
Cisco Wave 2
Access Point
Laptop / PC
with ethernet interface
Configuring the Windows Network Adaptor to
connect on to the ME AP
Go to Network & Internet Settings
Click on “Change adapter options”
Click on “Ethernet adaptor” which is connected
to the Access Point’s Ethernet port
(In my case it is the 5G Port of 4800 Access
Point)
Assign an IPV4 address on your PC / Laptop
Determining the Com Port In use by Console Cable
Connect the console to the AP and determine the corresponding COM port
Devmgmt.msc à
Ports (COM & LPT) will list the USB serial port in use
Configuring the AP for Conversion to Mobility Express
(Optional) If AP has previously existing configuration delete it (capwap ap erase all)
Login into the AP and assign a static IP address
Syntax: capwap ap ip <ap ip>
<mask> <gateway>
capwap ap ip 192.168.1.11 255.255.255.0
192.168.1.10
In this example we are assigning the AP an IP
of 192.168.1.11
Verify the AP’s wired 0 interface has taken up
the configured IP addresses
Since the AP has two Ethernet interfaces, two
wired interfaces could be found listed viz: wired0 & wired1
Open the TFTP application and give the ME image
path
Supply in the command in AP cli to download the
ME image
Syntax: ap-type mobility-express
tftp://<tftp IP address>/<ME AP image>.tar
Once the AP comes up after manual reload, wait
for couple of minutes
After
couple of minutes, it will again go a second subsequent reload on its own and
comes up as ME Controller
Configure the AP via the installation wizard
ME Controller comes up after reloading with initial configuration
Configuring the internal DHCP for the ME express
The internal AP inside the ME will not come up
until:
The ME is connected to a switch and it obtains
the DHCP IP from it
Or an internal DHCP server is configured.
Since for RF
coverage testing scenarios (AP on a stick), we won’t be having the AP connected
on to the switch, lets first connect the ME on a switch to let it obtain a DHCP
and have its internal AP up and running.
Often we would be require to get the Over the Air captures in
order to understand and troubleshoot the Wi-Fi behavior. The generally assumed easiest
choices for getting the wireless sniffer trace / OTA is either a Mac Laptop or
a Wireless Access Point in sniffer mode. These options have a limitation that
they won’t be able to obtain OTA over all the channels, specifically the UNII-3
Channels.
For instances as these, the Kali linux tool along with
Proxim wireless adaptor would come in handy. The reason for me specifically pointing
to the Proxim adaptor is its ease of availability with Wireless Network
Engineers. Most of the wireless network engineers will be running the Airmagnet
/ Ekahau application license mapped against the Proxim adaptor. A proxim adaptor
though may not be able to simulate an AP on all the channels but when it comes
to sniffing it would be able to sniff on all the channels. For instance, in my
case the proxim adaptor is not able to simulate as an AP on UNII-3 Channels,
however it still can be set in monitor mode on UNII-3 Channels.
Prerequisites:
Wifi Adaptor which supports monitor mode. ( I am
using Proxim 8494-WD)
Kali Linux
Steps:
Connect the Wifi-Adaptor and Open the Kali Linux
application.
Obtain the name of the Wireless Interface.
Issuing “iwconfig” will fetch us
the wireless interface name. In our case, it is found to be “wlan0”
Verify whether the WiFi adaptor is capable of
supporting the “monitor” mode.
Issuing “iw list” will list all
wireless devices and their capabilities.
Under the “Supported Interface
Mode”, you should be able to see monitor
Stop network managers then kill interfering
processes left
Issue the command “airmon-ng check kill”
It is very important to kill the network managers before
putting a card in monitor mode!
Create a monitoring mode wifi-interface by
issuing the command “airmon-ng start wlan0”
Verify that the interface is being set to
“Monitor” mode and its operating channel
Note that the frequency would be in GHz,
you will have to determine its corresponding channel number.
Configure the monitoring on the appropriate
channel of choice
Start the wireshark by issuing the command
“wireshark”
The Project planning in Wireless Deployments is often
broken down into following phases and the same in illustrated in sections
below:
Identifying the customer requirement
Identifying the customer requirement either by directly
obtaining the information from the customer or by self-assessment is the most
important part in any successful Wi-Fi deployment. The requirement of two
different business types may not necessarily be the same. Even the requirement of
same business type could be unique across the projects.
Following are the compressive list of generally found
Business types and are the ones that I had personally dealt with:
Schools
Universities
Shopping Malls
Airports
Sea Ports
Bus Stations / Metro Stations
Casinos
Hotels
Service Apartments
Stadiums
Exhibitions
Determining the deployment model that suits the customer requirement
High-Density
Specific Wi-Fi Deployment Model:
High-Density Wi-Fi deployments are generally warranted when we anticipate large
number of WiFi devices operate in a relatively smaller area. High-Density
specific Wi-Fi Deployment model would require us to take into consideration the
following:
Maximum
expected user density in any given area.
Identifying
the devices and applications that will be used.
Delay
sensitivity the applications can withstand while using the WLAN services.
Location specific Wi-Fi
deployments are generally warranted when the customer is more interested in
tracking the movement of visitors in their venue. This is also required to facilitate
people in indoor navigations wherein the Wi-Fi deployments are integrated with
SDKs for Indoor Navigation.
Though the indoor navigation
would have an additional requirement of app installation on visitor devices,
but it comes at an unique advantage of indoor navigation wherein GPS fails
miserably.
Location Specific Wi-Fi
Deployment Model would require us to take into consideration the following:
a. Area of interest wherein we expect greater location accuracy to be obtained.
This area should be having the wireless access points deployed in a convex hull
fashion.
b. Wireless Access Points that
supports Hyperlocation. There are certain Cisco Access Points having integrated
antennas to support Hyperlocation for example the 4800 series Access Point.
Also the modular access points with the option of Hyperlocation module could be
considered.
c. Mounting height of the
Wireless Access Points. Generally it is recommended that for location specific
deployments the wireless access points are mounted not higher than 4.5 meters.
Application
Specific/ Wireless VoIP Wi-Fi deployment model.
While taking into
consideration the Application specific deployment model, the Wireless VoIP deployment
model can be most thought of as a solution, since wireless VoIP deployment
model will warrant strict design considerations. This includes:
Preference
to 5 GHz only SSID.
Lesser
number of SSIDs in the venue to enhance the airtime fairness.
Design
to guarantee atleast -65 dBm signal strength and a SNR better than 20 dBm
Disabling
of Lower data rates.
Sufficient
channel overlap to facilitate smooth roaming
Understanding the application and services the customer
is intending to use is lot more vital in successful deployment of WiFi.
While few of the customers will be technically competent
to understand their requirement in entirely and develop a “Specification
Document” thus mandating it for the integrators to full fill all their project
requirements.
However there are as well few customers who may not be in
a position to completely understand their current requirement and / or forecast
their future requirement. For such customers, it should be the moral
responsibility for the integrators to help them understand in full their
current and future requirement and develop a “Specification Document”.
Developing the Specification Document
Specification document generally helps us capture the
customer requirement covering their current and future needs and the obligation
of the integrator in meeting those requirements.
In most of the cases, the Specification Document is
developed by the customer or the customer appointed consultant. However in
scenarios wherein the specification document is not available from customer,
integrator should go ahead and prepare one for the customer. This shall help to
agree and set right expectations that needs to be validated during project
closure.
Specification Document
should at-least include the following:
Scope of Work
Minimum Qualification of Managers, Engineer
& Technicians working on the project.
Submittals that has to developed and shared with
customer during the course of project execution. This includes:
List of Design Documents and Drawings.
Material Approval Requests
Material Samples
Datasheets of products.
Supplier and Manufacturer Details
Method Statements detailing the installation
process of each individual component
Design documents and drawings at different
stages of the project for customer’s review and approval.
Generally no design could get completed in
one go and it is always advisable for large projects that their design is
broken into different phases as follows:
Stage 1: 30 % Design Documents and Drawings.
Stage 2: 60 % Design Documents and Drawings.
Stage 3: 90 % Design Documents and Drawings.
Stage 4: 100 % Design Document and Drawings
Once the Design reaches Stage 4 and is completely reviewed
by customer or the customer appointed consultant, the physical installation of
the equipment could begin.
Predictive Site Survey Design Documents.
Predictive site survey shall be performed that is modeling
the facilities and RF environment in order to predict the WLAN requirements
(access point types, location, channel utilization, signal to noise ratios,
channel interference, etc.)
On-Site Site Survey Design Documents
The predictive site surveys being simulator based would aid
only for the purposes of developing the initial BOQ. However this in no way are
the substitute for actual onsite site survey with actual model of Wireless
Access Points. On-Site site survey are all about mounting the specific models
of Wireless Access Points with specific antennas on typical locations and then
studying the resultant coverage pattern by tweaking in the Tx Power to develop
the optimal AP placement with right model of Access Point / Antenna.
Post deployment site survey documents and drawings
Final site survey shall be performed after the WLAN system is
online to compare the design and specification requirements with the actual
performance values. This shall held the integrator’s responsibility to rectify
any issues of non-compliance with the requirements.
Interface Control Documents
In large scale deployments, wireless will not be operational
as a standalone system and needs to get integrated with different systems and
subsystems. ICDs in such cases shall help us determine the validating
parameters to conclude the integration is successful.
Installation, Operation and Maintenance manuals.
Operation and Maintenance Manuals shall help the customer once
the project is handed over to maintain the deployment.
Developing the compliance matrix document
Compliance matrix summarizes compliance or non-compliance
with each specification component.
