Identifi - Mobility

This article describe the components that make up the Mobility Domain, why Mobility is important in a Routed VNS environment, and Centralized Mobility

Controllers share Client session  (up to 12) for seamless roaming, and this requires NTP and same software code

The wireless system allows multiple Wireless Controllers (up to 12) to discover to each other and exchange information about a client session for true mobility. This feature enables a wireless device to roam seamlessly between different wireless APs on different Wireless Controllers.  Mobility is especially important in a routed environment where the user will be able to roam and continue to use the original IP address that it received from its Home Controller.

The wireless device retains its Role assignment (access control, IP address, rate profiles and filtering rules) it received from its home Wireless Controller - the Wireless Controller that it first connected to.  The VNS components on each Wireless Controller must have the same SSID and RF privacy parameter settings so that it can be supported in a Local or Branch Office Setting and it easy to deploy on an existing IP network.

The goal of Mobility is to provide the user with a seamless mobility experience in a Multiple Controller deployments by sharing session registration information.

There are two components in mobility.

Mobility Manager – manages the state of the mobility domain

Mobility Agent – processes & provides  client session updates

The solution introduces the concept of a Mobility Manager and Mobility Agents.  One Wireless Controller within the network is designated as the Mobility Manager and all others are designated as Mobility Agents.

The Mobility Manager is a single system identified by the administrator that will manage the state of the mobility domain.  Once identified, the Manager will accept Mobility Control session connection attempts from Mobility Agents.  The Manager is responsible for the management, aggregation and distribution of client session information to all Agents.

Once configured, the Mobility Agent will locate the Manager either using SLP Unicast or a static configuration and will establish a Mobility Control session (TCP port 60606) with the Manager.  The Agent also processes the client session updates provided in the regular heartbeat messages sent by the controller so that it can build a complete list of controllers in the mobility domain by membership/location. The Backup Mobility Manager runs as an agent, but monitors the Mobility Control Session to the manager status.

Once the Mobility Session is established the Agent will then retrieve the list of all other controllers in the domain and proceed to set up the mobility data network by initiating a Data Tunnel (13910/UDP) to each one of its peers.  This data network will become a full-mesh once the mobility domain is up and will be used as a tunnel to forward a roaming client’s packets between the foreign and home controller.

Mobility: Intra-controller Roaming

In an Intra-Controller Roaming scenario, when a user roams on the same SSID across APs on the same Controller, the control plane simply updates the Mobile Unit (MU) session referencing the new AP or Radio Unit (RU).  All the session information such as VNS, authentication, IP address, and Role remains intact. The Intra-Controller roaming latency is measured at around 8ms.

Mobility: Inter-controller Roaming

In addition to managing roaming activity across APs associated to a single controller, mobility extends this service to multi-Controller deployments or the Inter-Controller Mobility scenario.

When a MU (MU1) starts a new session with a mobility domain, the first controller it connects to is identified as its “Home” Controller (Controller1).

When an Mobility Agent (Controller 2) receives a new MU/wireless association request, it will first check in its local table to determine if the MU already has a session and then determines whether this client belongs to a controller within the mobility domain and determines its Home Controller.  If a session does exist, the Mobility Agent accepts the client and then updates the Mobility Manager with the new whereabouts over the Mobility Control Session tunnel and begins tunneling the client’s data to and from its Home Controller over the CTP tunnel that is established between the Controllers.

The WLAN client/MU will continue to maintain its network point of presence and all of its session properties (VNS, IP, authentication state) and all traffic will flow through the Home Controller.

Mobility: Limitation & Requirements

•Controllers must be running the same version of Controller Software

•Controllers must be using a common source of time (NTP)

Because of the tight interaction between the Mobility Controllers, different versions of software are NOT supported. This means that all Wireless Controllers in the mobility domain must be running the same Wireless Convergence Software release and the Controllers in the Mobility Domain should also be using a common source for time synchronization (an NTP server).