Nile Mesh on Nile APs

1\ overview nile mesh lets you extend wi‑fi coverage using wireless backhaul instead of running ethernet to every access point (ap) it is ideal for outdoor areas (parking lots, plazas, walkways) large campuses and warehouses temporary spaces and events locations where cabling is difficult or costly in a nile mesh deployment one or more root aps are wired to the network switch and nile service block one or more mesh aps (mesh points) connect wirelessly to a root ap and serve client ssids, just like wired aps nile mesh is designed to preserve end‑user experience and throughput maintain centralized visibility and control in the nile portal integrate with the existing nile access service (no separate controllers or overlays) 2\ core concepts 2 1 roles in a mesh network root ap has a wired ethernet connection to a nile access switch acts as the anchor for mesh aps provides both client access (user ssids) wireless backhaul to mesh aps mesh ap (mesh point) has no wired uplink in steady state (powered typically by poe) connects wirelessly to a root ap (or, in advanced topologies, to another mesh ap) serves the same user ssids as wired aps, so clients see a single, unified wlan from the client’s perspective, a mesh ap behaves like any other nile ap; the mesh backhaul is transparent 3\ when to use nile mesh use nile mesh when you need coverage beyond the wired footprint of your switches pulling cable is costly, disruptive, or impractical you want to quickly expand coverage to parking areas and outdoor seating new wings or temporary buildings remote corners of large facilities mesh is not meant to replace traditional high‑capacity, fully wired indoor deployments long‑distance point‑to‑point wireless bridges between buildings think of mesh as a short‑to‑medium distance extension of your existing nile access service, with careful rf planning 4\ high‑level architecture at a high level, nile mesh works as follows root aps are wired to the nile access switch and nile service block mesh aps use a dedicated internal uplink radio to connect back to root aps over wi‑fi mesh aps receive a management ip like any other ap the required information to reach nile cloud (headends, cloud services) client traffic from a client on a mesh ap is encapsulated and carried over the wireless mesh link traverses the wired network to the nile service block, just as if it originated on a wired ap control and visibility all mesh and root aps continue to be managed via nile portal topology, health, alerts, and upgrades remain fully centralized the system ensures bidirectional ip reachability between mesh aps, root aps, and the nile service block automatic path updates when mesh aps move (roam) between root aps 5\ planning a mesh deployment 5 1 site planning and rf considerations before enabling mesh in production, plan for distances typical recommended spacing between root ap and mesh ap 50–80 ft in open or semi‑open spaces for best throughput up to 100 ft may be possible with clear line of sight and modest throughput needs line of sight (los) aim for los or near‑los between root and mesh aps avoid or account for thick concrete or metal structures heavy foliage or moving obstructions mounting height and tilt mount outdoor aps at consistent heights when possible ensure antennas are aligned for the intended coverage zone interference consider nearby wi‑fi, radar (dfs), and other rf sources perform or review a predictive rf survey to validate channel and power plans 5 2 capacity and performance keep in mind a mesh ap shares its radio resources between backhaul (root ↔ mesh ap) and client access (mesh ap ↔ devices) throughput on a mesh ap will generally be lower than on a wired ap on the same channel and band , due to airtime sharing for performance‑sensitive areas (dense offices, large classrooms) prefer wired aps use mesh primarily to reach fringe or hard‑wired locations where absolute peak throughput is not critical 6\ roles and behavior (customer‑facing view) 6 1 root ap behavior a root ap operates as a standard nile ap for clients additionally advertises a mesh‑capable beacon used by mesh aps to discover and attach only accepts mesh uplink associations from mesh‑enabled aps , not from end‑user devices virtual sensors or packet capture agents this design preserves airtime for mesh backhaul and client traffic avoids unintended associations that could degrade performance 6 2 mesh ap behavior a mesh ap boots and looks for a root ap (or a configured mesh parent) using its internal uplink interface once connected obtains a management ip address registers with nile cloud via the root ap and wired network then brings up its client ssids (same as the rest of your nile network) starts serving user devices if the mesh ap loses its root ap (for example, hardware failure or power loss) it will automatically search for alternative root aps within range re‑attach to the best available root ap if one exists 7\ activation and configuration (conceptual) note exact ui labels and workflows in the nile portal may evolve this section focuses on concepts and what you, as a customer, should expect 7 1 root aps in a typical deployment select aps to act as root aps these are aps with reliable wired backhaul and poe they are usually located closer to your core wiring closets enable mesh root role from nile portal (or via a nile support workflow), mark selected aps as root aps after this, those aps continue to serve normal client ssids also advertise themselves as mesh‑capable for mesh aps validate confirm in nile portal that the ap now shows a mesh role of root (naming may vary slightly in ui) ensure it remains online and healthy before bringing up mesh aps that depend on it 7 2 mesh aps there are three main patterns customers will encounter pre‑staged mesh aps (recommended for early deployments) aps are configured as mesh points (mesh aps) before shipping or during a staging phase in the field, installers primarily mount and power them via poe validate that they connect to the designated root aps field activation via ble / local process an installer uses a mobile app or local connection to turn an ap into a mesh ap trigger a reboot so it begins searching for root aps useful when the exact ap role (root vs mesh) depends on final in‑field decisions automatic mesh (roadmap behavior) over time, nile may adopt more automated behaviors, such as aps that power on without a wired link for a sustained period can automatically adopt the mesh role aps that regain a suitable wired connection revert to acting as regular/root aps as appropriate your nile se/solutions architect will help you decide which activation model is best for your environment ensure replacement units (rma) can be smoothly swapped into existing mesh roles 8\ monitoring and troubleshooting 8 1 what you see in nile portal for each ap, you can expect mesh role root ap or mesh ap (mesh point) parent/children information for a root ap list of associated mesh aps for a mesh ap its current root ap (and, for multi‑hop, possibly its upstream mesh parent) link health indicators signal strength (rssi) between mesh ap and root ap channel utilization or load on the mesh path alerts mesh ap unreachable or mesh link down weak mesh signal (e g , mesh ap connected to a root ap with poor rssi) missing or inconsistent routing for mesh aps 8 2 common symptoms and what to check a mesh ap is offline or unreachable symptoms mesh ap shows as down or unreachable in the portal users behind that mesh ap lose connectivity checklist power and cabling verify the poe injector or poe switch port is delivering power check the led status on the ap rf reachability confirm the mesh ap is within the planned range of its root ap verify there are no new obstructions (temporary structures, vehicles, dense foliage) root ap status ensure the root ap is online and healthy still configured as a root (mesh role not changed) alerts in nile portal review mesh‑related alerts (mesh link down, weak root ap connection, missing mesh route) follow the recommended remediation or share details with nile support b clients connected to a mesh ap are slow symptoms clients can connect and pass traffic, but speeds are lower than expected checklist distance and alignment validate that the mesh ap ↔ root ap distance is within the planned range (e g , 50–80 ft) check mounting and orientation of aps channel and interference review channel utilization for the root and mesh ap high utilization may indicate too many clients on the same channel rf interference (other wlans, radar, etc ) number of mesh hops if using multi‑hop throughput drops with each hop due to shared airtime consider re‑positioning aps to reduce hop count or convert additional aps into root aps where cabling becomes feasible c mesh ap intermittently changes parent symptoms mesh ap roams between different root aps or upstream mesh aps, causing brief interruptions checklist signal ratios if two candidate root aps have similar rssi, a mesh ap may roam between them slightly adjust power or placement so there is a clear best root ap topology design avoid placing too many root aps at similar power/coverage overlapping the same mesh ap use rf planning guidelines from nile to fine‑tune placement 9\ best practices and recommendations plan mesh as an exception, not the norm use mesh to reach where you cannot or should not pull cable always perform (or request) a predictive survey especially for outdoor and long‑corridor deployments provide redundancy where important have at least two potential root aps covering critical mesh aps, so they can fail over limit hop count prefer single‑hop mesh where possible; multi‑hop chains are more sensitive to rf and topology changes treat mesh links as shared resources avoid overloading mesh aps with very high client density or sustained heavy traffic (e g , bulk backups, large media transfers) unless specifically planned 10\ frequently asked questions q1 do end‑user devices know they are connected through a mesh ap? no from the client’s perspective, a mesh ap is just another nile ap with the same ssids and security policies mesh backhaul is transparent q2 can i mix mesh aps and wired aps on the same ssid? yes wired aps and mesh aps can broadcast the same ssids clients roam between them following standard wi‑fi roaming behavior q3 what happens during a root ap failure? if another root ap is in range mesh aps attempt to re‑attach to the alternate root ap client sessions may experience a brief disruption, then resume if no alternate root ap is in range, mesh aps lose backhaul and clients will lose connectivity until a suitable root ap is available again q4 how many mesh hops are supported? the underlying architecture supports multiple hops, but nile recommends minimizing hop count and focuses the customer offer on short mesh paths for predictable performance your nile team can help design within the current validated limits q5 can i convert a mesh ap back to a wired root/regular ap later? yes once you provide a wired connection and update its role in nile portal (or via support), the ap can operate as a normal wired or root ap again 11\ working with nile for production mesh deployments, nile strongly recommends engaging your nile solutions architect / se early for design review (topology, distances, expected capacity) root/mesh ap role planning rf validation and predictive survey sign‑off using nile support if mesh links show recurring alerts or performance issues you are planning significant changes (new buildings, large outdoor expansions) nile mesh is designed to be a managed, predictable extension of the nile access service with proper planning, it provides robust coverage in places where wires can’t easily go—without sacrificing the simplicity and assurance model that nile is known for