This article provides guidance on configuring Ruckus Unleashed wireless networks to ensure compatibility and reliable performance with RTI remotes. It explains how to limit the RTI SSID to a single access point, create custom AP groups, and adjust advanced settings to prevent connectivity issues. The document also covers deployment considerations for larger installations, recommended diagnostic adjustments, optional SSH commands for optimization, and notes on observed remote behavior during use.
Download link for full article: Ruckus Wireless Config for RTI Remote
A. Prerequisites
• Administrator access to the Ruckus Unleashed Web UI
• Existing SSID for RTI remotes (e.g., Remotes)
• Identification of the access point (AP) closest to the RTI remote docking station
B. Procedure
1. Log in to the Ruckus Unleashed Web Interface
• Access the Web UI using the system IP address or hostname in a browser.
2. Navigate to Access Point Group Configuration
• Go to Access Points in the main menu.
• Click the icon showing two stacked squares to enter AP Group Mode.
• By default, all access points and SSIDs are assigned to the System Default AP group, which
broadcasts all SSIDs on all APs. This assignment must be rewritten, as explained next.
3. Create a Custom AP Group
• Select the option to create a new AP Group.
• Assign a descriptive name (e.g., Non-Remote Broadcast Group).
4. Assign Access Points to the Group
• Select the APs that should not broadcast the RTI remote SSID.
• Use the arrow keys to move them into the new group.
• Click Next to continue.
5. Assign SSIDs to the Group
• Select only the SSIDs that should be available on the selected APs.
• Do not include the RTI remote SSID in this group.
• Click Next to continue.
6. Configure Radio Settings (Optional)
• Assign radio bands and channels as required for the group.
• Optionally, disable WLAN service to turn off SSID broadcasting entirely on specific radios.
7. Finalize the Group Configuration
• Review the settings and click Finish to complete the group setup.
8. Verify SSID Placement
• Ensure that the Remote's SSID is assigned only to the AP closest to the RTI docking location
(e.g., Living Room R510).
• Confirm that other APs in the network are not broadcasting the Remote's SSID.
C. Deployment Considerations
In large deployments (e.g., 20 RTI remotes with 30 APs), individual SSIDs and AP groups may need to be
created per remote. While this adds setup complexity, it ensures reliable performance by isolating
remote traffic to a single AP per device.
RTI remotes may exhibit connectivity issues (e.g., disconnection after 30 minutes of inactivity) when the
Remotes' SSID is broadcast across multiple APs. Limiting SSID broadcast to a single AP has been observed
to mitigate this issue.
D. Advanced Diagnostics
To optimize wireless performance and ensure stable communication with RTI ISR-4 remotes, it is
recommended to adjust the following Ruckus features:
Feature Impact on ISR Action
Directed Multicast Inhibits Communication Disabled
Airtime Fairness Deprioritizes ISR Disabled
Smart Roam Causes Premature Disconnection Disabled
E. SSH Configuration Commands:
To apply advanced WLAN settings that optimize RTI remote connectivity, use the following SSH
commands:
Procedure:
1. SSH into the Ruckus Unleashed system using port 22.
2. Log in using your Web UI administrator credentials (admin, <username>, <password>).
3. Enter the following configuration commands:
enable
config
wlan <WLAN_NAME>
directed-threshold 1
smart-roam
end
ap-group "<SSID_GROUP_NAME>" (or "System Default")
no radio 2.4 admission-control
end
F. Observed Behavior
It has been reported that RTI remotes do not experience full system crashes (i.e., loss of variables or
control); however, a noticeable delay occurs when sending the first command after a period of inactivity.
Typically, the second button press executes immediately. This behavior has primarily been observed
when controlling streaming services such as Disney+. It is currently unclear whether the issue is related
to the streaming app or the remote itself.
There have been reports of similar behavior. While the system is generally stable, the intermittent
nature of the delay means it is not frequently reported as a critical issue.