Pepwave AP One under Peplink WLAN Roaming


#1

We are in bidding phase for one project to provide Mall Wireless Coverage. We plan to bid using Peplink LB-380 as WLAN controller with Pepwave AP-One wireless access points. One important project requirement is to support roaming between different Pepwave AP. Once a user with handheld wireless device (mostly it will be a Smart Phone or a cisco IP phone) is moving from the connected AP towards another AP, the wireless system should hand him off between the two AP smoothly without getting his wireless connection dropped (especially important for the ip phone voice conversation). Is there any documentation on this scenario to describe more technical aspects of roaming (if supported)? Also, we need to know more about the protocols and ports used in WLAN controller to AP communication, since in between there will be networking devices possibly filtering/blocking some protocols and ports. Please advise on best practices to cover this project requirement. Thanks


#2

Yes! Roaming between APs are supported by our AP One and Balance Controller. The best practice of the deployment will be keeping all the AP One in the same subnet. This will allow the client device, such as smart phone, to maintain the same IP address before and after roaming from AP to AP. This will allowed the phone to roam seamlessly and maintain the VOIP session.

To allow best roaming time, open authentication mode may be used. This can help to phone to minimize the handshake between AP and phone to achieve better roaming time.

The roaming timing is taken care by the smart phone and IP phone themselves. Good IP phone will have short roaming time and roaming algorithm to minimize the delay and prevent the call drop. Using the same channel across different APs could help the IP phone to roam smoother.

So, if possible, you can deploy the network with following best practice:

  • deploying the AP One in the same subnet, same layer 2 network
  • use open security mode
  • try to set all the AP One in the same channel to help the roaming of the IP phone

Will check about the protocol and ports and get back to your later

Hope this help!


#3

Thank you Sam,
All APs are set to the same radio channel. All are connected to the same VLANs (each VLAN mapped to the corresponding SSID). However, due to the fact that at some points the traffic has to pass through a Core Switch, which applies Multicast Traffic Filtering, we want to know how will this affect the Client Roaming between APs. In the case the LB WLAN controller uses multicast communication to control APs and communicate the client roaming hand-off information to the APs, it will get affected by the Network Layout. Just to update you, we have setup a demo using LB-380 and 5x AP One access points, configured with 4x SSID, and all placed to the same radio channel. The customer was comparing our setup with a previous Cisco setup, and he complained about slow roaming between APs. From your reply post, I understand this has nothing to do with the AP and WLAN settings, but rather with the client device settings (sensitivity to signal level changes and rapid decisions to start roaming). I think this will be a challenging project, since there will be a lot of parameters to change (AP spacing, AP Power adjustment, Client IP Phone roaming aggressiveness settings). We want to achieve the best “Communication Experience” to the client with the minimum required changes on the user/client device part. Any more directions?


#4

Hi Mohamed, I have filed a ticket so our engineering team to better assist you in this situation. There are various factor that may affect the roaming performance and our team will need more information from the AP (debug dump) and network diagram to further assist you. Please help to get the debug dump of the APs and enabling remote assistance. We will also need the serial number of the APs to enter the remote assistance service.

Please let me know if you didn’t see the ticket. It should be sent to your gmail address :slight_smile:


#5

Many thanks Sam,
Actually a lot has happened since my last post. Just to update you: The location to cover is a big space mall. Customer wants to cover all the mall to provide following services: Free Internet Access to guests (No encryption, Open, captive portal used to steer the guests towards the mall web page at first connection). 2- Wireless Access for Cisco IP phone (encryption key used on non-broadcast SSID). Project challenges: 1- Restriction on AP location: here the customer is restricting AP locations to specific predefined locations. 2- Interference from other wireless access points in all the channels: The radio environment is uncontrolled. 3- Cisco IP Phone roaming support: Mall staff wants to wander around the mall carrying cisco wifi IP phone, so wireless network infrastructure should provide smooth handoff of cisco device with minimum delay (Unfortunately the voice SSID is encrypted and AP One does not support any enterprise AP fast roaming features).


#6

I would like to continue this thread by e-mail to discuss more private details


#7

This is incorrect advice, and a common misconception of WiFi. APs should never all be set on the same channel to ‘aid in client roaming’ (unless you are Meru, or more recently Ubiquiti). By setting the APs to the same channels you are only causing the APs to ‘fight’ for the RF spectrum.

Mohamed, client roaming is 95% a client feature. You can have two APs from competing vendors -eg Cisco and Peplink- and clients will roam just fine. The only requirement for WiFi clients to roam is that the SSID and security settings are the same. Channels should be different to minimse the amount of self-interference.

the other 5% is where an infrastructure can assist client roaming (note that I don’t say it will enable or disable roaming, just assist it). This is done by using technologies like PMK Caching, 802.11r and 802.11k. These technologies either make the infrastructure respond more quickly to the client roam event (PMK-C), or they give more information to the client to enable it to make better roaming decisions (802.11r, 802.11k).

Don’t be surprised that you are having issues with roaming of VoIP WiFi devices. VoIP-over-WiFi is the #1 most difficult protocol to make work properly, because the fundamental design of WiFi goes against the requirements of VoIP (unscheduled, best effort, ‘polite’ protocol in unlicensed, shared RF bands). This is why most vendors -especially Cisco- tend to create many proprietary protocols just to make VoIP work better on WiFi. There are also many public protocols to help VoIP, but these need to be supported by the VoIP handset and the infrastructure, which is not very common.

Maybe Peplink can chime in on what protocols are supported by the AP One family.


#8

Actually, Sam Yeung was our engineer, and the suggestion was based on the question of the best roaming performance. It is not about generic scenario. However, I’d still like to thank you Airnetworks for posting your comments here. Our discussion has made the topic more clear.

In addition, we support PMK caching with AP Controller.


#9

Sorry to revive a dead thread, but it already gets an inevitable discussion about client roaming being primarily a client feature out of the way by jumping on this thread. The observations we have had with our Pepwave AP One Enterprise devices have shown the same behavior additionally described here with Apple devices. Android devices roam just fine between our AP’s, but our Apple OSX and iOS devices hang-on to their current AP no matter how bad the signal quality gets, even if there is another AP with the same Profile broadcasting closer nearby. I have tried to overcome this problem by tweaking “Client Signal Strength Threshold”, but setting it to any value other than 0 causes our Apple OSX and iOS devices to fail to associate with the AP’s.


#10

Hi Matthew,

We had tested the RTS & “Client Signal Strength Threshold” for the AP & AP controller, the settings is working fine.

Below are the test settings:

  1. “Client Signal Strength Threshold”: 20 (-75 dBm)
  2. RTS: 100
  3. IOS version: Iphone 6s (9.3.2)

Can you share us the settings that you defined for the RTS & “Client Signal Strength Threshold” that causes the Apple OSX and iOS devices fail to associate with the AP’s ? Beside that, do you have the WIFI analyzer scanner for your WIFI network ? Can you share us the scan reports ?

Thank You


#11

Hey Sit,

  1. I had tried 40 (as suggested to another user here) and 20 for “Client Signal Strength Threshold” respectively. After realizing each caused our OSX devices to fail to associate with the AP’s, I iterated through in multiples of 20 until the input validation on the AP Controller complained (I believe 1 and 255 were the validation limits if I remember correctly). If a value of 20 is equal to ‘-75dBm’ what value of measurement is being provided? Is that value in picowatts?
  2. I tried setting RTS to ‘500’ as another user had successfully applied in their environment here. After realizing it was preventing our OSX devices from associating with the AP’s, I backed out the setting.
  3. I personally don’t have an iOS device that I can test with (although other users here do)–but I know for sure it is a problem with OSX wireless clients (both Mac Mini and MacBook Pro devices fail to associate with the AP’s when those values are changed).

I do not have a certified WIFI analyzer, but have been using “Wifi Analyzer” from Google Play using a mobile Samsung Galaxy S6, as well as the “Wireless Diagnostics Utility” provided with Apple OSX via several stationary Mac Mini’s and a mobile MacBook Pro. Let me know what information you are wanting to see from each of those utilities and I can see if I can grab a screenshot and/or log dump for you.


#12

For “Client Signal Strength Threshold”, the allowed define value is from 0 to 94.

The simple calculation is using the below method:

“Client Signal Strength Threshold” + (-95dBm) = Minimum client signal strength to connect

Example:

Defined “Client Signal Strength Threshold” = 30
30 + (-95dBm) = -65 dBm

Note:
Client Signal Strength will be verify when associate to the APs base on the “Minimum client signal strength to connect”. Client signal strength -65 dBm and above will allow to associate to the APs.

Tested using the RTS 500, no issue for the IOS/OSX to connect.

Do you tested the RTS value together with “Client Signal Strength Threshold” ? You have to make sure client devices having WIFI signal strength above the defined value in-order the devices able to successful associated to the AP.

Do open a support tickethere, if you still fail to get the settings work.

Thank You