The pace at which new security threats are being introduced and propagated online has reached exponential levels, gaining speed with each passing year. Organizations have more locations and devices to protect, and threats are using many different ports to try to gain access or exfiltrate data. Security teams are often understaffed and struggle with complex, siloed systems that do not integrate or share intelligence in a programmatic way. These teams need solutions that are easy to deploy, simple to manage, can scale exponentially, and can integrate with other tools.
Securing your wireless users from malicious attacks — particularly these “DNS blind spots” that exist in many networks and are exploited by 97% of advanced malware — is of paramount importance. Unfortunately, recent surveys indicate that 75% of organizations do not actively monitor and apply security for DNS.
It is within this context that we are excited to announce support for integration between Meraki MR wireless access points (APs) and Cisco Umbrella (formerly OpenDNS).
Umbrella is the industry’s first secure internet gateway, a cloud-delivered first line of defense against threats like malware, ransomware, and phishing. Umbrella enforces security at the DNS layer by identifying requested web domains hosting nasty stuff — malware, phishing, etc. — and block end user access to them. Umbrella also enables more secure DNS querying through a tool called DNSCrypt, which automatically encrypts DNS queries between your network and Umbrella’s servers, effectively eliminating the chance that your queries will be the victim of eavesdropping or man-in-the-middle (MITM) attacks. This secures the “last mile” of a client’s internet connection, which is often left exposed and vulnerable.
There is no additional cost or charge for taking advantage of this integration (which is available to all Meraki wireless customers who have upgraded to our latest MR26.x firmware), but Meraki wireless customers who wish to integrate with Umbrella will need a separate Umbrella license and account with that service.
Enabling Umbrella integration
So, what does this mean for admins of Meraki wireless networks? This integration with Umbrella enables Meraki admins who obtain Umbrella licenses (WLAN, Professional, Insights, or Platform) to seamlessly assign DNS filtering via Meraki group policy or SSID to specific subsets of wireless clients, or to them all.
Enabling Umbrella integration takes only a few steps. First, the Meraki and Umbrella dashboards must be linked via the Umbrella Network Devices API key. Once this API key is generated from within the Umbrella dashboard, it needs to be copied into the Meraki dashboard by navigating to Network-wide > General.
Enabling Meraki + Umbrella integration within the Meraki dashboard.
Once the Meraki and Umbrella dashboards have been configured, linking a Meraki SSID or group policy to an Umbrella security policy is easy (note: Meraki group policies must be set to use ‘Custom SSID Firewall & Shaping Rules’ to link an Umbrella policy to them). After this initial setup, a unique identifier is generated behind the scenes for the specified Meraki SSID or group policy and is used by Umbrella to determine how to evaluate traffic from that Meraki network moving forward.
To link a Meraki SSID to an Umbrella policy, navigate to the Wireless > Configure > Firewall & Traffic Shaping section of the Meraki dashboard. There, you will find a button to link Umbrella policies.
Linking an Umbrella policy to a Meraki SSID.
By default, the last policy physically listed in the Umbrella dashboard’s ordered policy list will be inherited by a Meraki SSID unless a different policy is selected from the dropdown list.
To link a Meraki group policy to an Umbrella security policy, navigate to the Network > Configure > Group policies page in the Meraki dashboard and choose the specific Meraki group policy that you want to link. Under the ‘Layer 7 firewall rules’ section of that policy, you’ll be able to choose which Umbrella policy you’d like to apply.
Applying an Umbrella DNS policy to the Meraki ‘VIP Umbrella Clients’ group policy.
Once a Meraki SSID or group policy has been successfully linked to an Umbrella security policy, clients connecting to that SSID or who have been applied that group policy will have their DNS queries encrypted (if the AP supports 802.11ac) and verified against the corresponding Umbrella policy. Encrypting DNS queries between Meraki APs and Umbrella DNS endpoints helps secure the ‘last mile’ of client web browsing and protects against devastating MITM attacks or packet snooping that can reveal which websites client devices are browsing.
An example Umbrella policy may prohibit access to known malicious web domains or websites that host specific types of content, like gambling or peer-to-peer domains. If the client’s request for access to a given website is allowed, Umbrella will return an encrypted DNS response with the appropriate IP address. If the request is denied, then an encrypted DNS response pointing to the Umbrella block page will be returned instead.
Taken together, Meraki wireless and Umbrella integration provide a significantly more robust security framework for IT admins looking to protect clients from web threats in a more proactive way. Instead of waiting for a malicious site to infect a machine and then using tools like antivirus to detect and remediate, Meraki MR customers can rest easy knowing that they are protected from ever reaching harmful sites in the first place.
Interested customers should contact Meraki Support to have this feature enabled. This feature requires an early-release MR firmware version that can be enabled with Meraki support assistance.
Early in 2012, a startup company beginning to make waves in the networking industry introduced a new feature for their line of access points. This startup was called Meraki, and the feature launched was Air Marshal. At the time, the functionality satisfied the security requirements of a typical wireless network: automatic containment of rogue APs seen on the LAN, keyword containment of SSIDs, scheduled Air Marshal scanning, and the ability to configure additional APs as Air Marshal sensors for round-the-clock protection.
With the introduction of the MR34 in 2013, Cisco Meraki introduced the dedicated scanning radio and this took the Wi-Fi industry by storm! No longer would admins have to choose between performance or security. With the dedicated scanning radio, the MR was now capable of servicing clients while simultaneously listening to the entire RF spectrum, protecting clients from malicious rogue APs.
The constant surveillance of wireless networks continues to be important, but recent trends in cybersecurity and the growth of Internet of Things (IoT) requires added flexibility when it comes to securing wireless networks.
The Blacklist
No, James Spader won’t be lending his hand to protect your wireless network. But, much like his character on the popular TV show, Air Marshal will work to eliminate (or contain) all SSIDs found on “the list.” TV shows aside, Air Marshal traditionally made it simple to automate containment of rogue SSIDs that are seen on the LAN, or contain SSIDs that matched a keyword.
However, some environments may have a network comprised of multiple vendors, or may be a part of a collaboration workspace where numerous companies may feature their own WLANs, connecting to the same wired network infrastructure. In this instance, automatic containment of rogues seen on LAN won’t work, as the non-Meraki APs would cease to function for their clients.
But administrators no longer have to forfeit their security capabilities. With Air Marshal’s new SSID Blacklist table, rogue SSIDs won’t be automatically contained, but security rules can be configured to match on a variety of conditions allowing for an accessible network to be locked down with finely tuned security controls.
Security rules may match on four different conditions: exact matches, MAC address matches, keyword matches, and wildcard matches. The rules defined in the SSID blacklist table will match against SSIDs that are seen on LAN, as well as Other SSIDs that are “heard” by the Meraki APs but are not found on the LAN. Any matches will result in the MRs within the vicinity of the rogue or other SSID to actively contain the SSID, rendering the offending SSID useless for clients who wish to connect. Exact matches will match on the SSID seen (whether the SSID is seen on the LAN or not), while keyword rules will ignore surrounding characters and match on just the keyword specified. BSSIDs (MAC addresses used to identify a Wi-Fi network) can be matched against if specific radios (2.4 GHz or 5 GHz, for example) that are broadcasting need to be contained.
The wildcard match provides the greatest amount of flexibility. Wildcards can be used to substitute a string of characters with a single *, or a single character with a single ?. For example, an SSID Blacklist wildcard rule may match the following text: ‘*12345’. If the MR detects an SSID broadcasting ‘Guest-12345’, then that SSID will be contained. If the rule is configured to match on ‘Guest-12?45’ and the MR detects an SSID broadcasting ‘Guest-12345’ or ‘Guest-12Z45’, then that SSID will also be contained.
Merely containing the SSID isn’t enough, though. Administrators often want to be cognizant of the rogue SSIDs that are being detected and secured by their MR access points. As such, if the administrator has configured email alerts or syslog in their Meraki Dashboard, they’ll stay apprised of their security rules in action.
Good News, You’re on the (White)List
Seemingly every other day, a new company is featured in the media as being the latest victim of a cybersecurity attack. Wireless networks are often considered the edge of the network infrastructure, the first line of defense in many cases. As a result, many administrators and security teams alike want to automatically contain rogue SSIDs seen on the LAN. While this grants the highest level of security enforcement, interoperability issues may arise when factoring in how often wireless display adapters and IoT devices connect to the network.
In the modern enterprise, HDMI cables are being replaced with Wi-Fi Direct adapters to make screen sharing and video streaming simple and intuitive. In the majority of instances, these Wi-Fi Direct devices (an adapter and client device, such as a PC, printer or remote) will often communicate on their own, freshly created wireless network. Sounds easy enough… except for one slight issue. This isn’t an SSID that’s broadcast by your MR access points, and in no time at all, deauthentication frames are being sent over the air in an effort to protect your devices from the suspected intruder. While the security team is rejoicing, the network administrator is still working to find a way to whitelist these devices so that security can be maintained with just enough flexibility for day-to-day employee operations. Enter the SSID Whitelist table:
The newly familiar faces are all here when it comes to the way that SSIDs can be matched to whitelist from containment. Exact matches, keyword, MAC, and wildcard can all be used. However, unlike the SSID Blacklist table, the whitelist table will not send email alerts or syslog messages when SSIDs are matched.
Alert, but Don’t Touch
There may be instances where administrators wish to be alerted when certain SSIDs are “seen” on the LAN or “heard” in the air, without taking any specific blacklist or whitelist actions. Using the same match conditions available for the SSID Blacklist and SSID Whitelist tables, alerting security rules may also be configured. These alerts will be sent via email and syslog alerts, if configured.
In With the New
Security has been at the forefront of Meraki since the introduction of Air Marshal in 2012. With the latest enhancements made to Air Marshal, new security rules can be configured to match on a variety of conditions, enabling administrators to implement granular security policies that are flexible for the modern workplace. These new Air Marshal features encompass the rapid innovation made possible by the Meraki dashboard. The new Air Marshal enhancements are available free of charge for existing MR customers as part of a seamless Dashboard update. For the SSID whitelist and SSID alerting functionality, the MR network must be set to MR25.9 firmware or higher. Visit our documentation for more information on configuring Air Marshal.
As we mentioned earlier this week in our latest launch blog post, we’re thrilled to announce some new features that are coming soon toall Cisco Meraki wireless customers: Wireless Health and RF Profiles (including customizable Rx-SOP settings, which help mitigate co-channel interference in high-density environments).
These features are critical for today’s wireless deployments. We increasingly depend on wireless for our network connection, so it’s imperative that administrators have insights into end users’ experience. It’s also paramount that wireless settings be quickly tailored to different coverage scenarios and that these settings can be pushed across a number of APs.
Wireless Health
Wireless Health helps IT teams verify that client devices can access the network as expected and that they have a fast, reliable experience. It does this by looking at all the steps necessary to provide a seamless experience — from associating to an AP, to network authentication, to obtaining an IP address, to hostname resolution via DNS — and displays metrics and anomaly data about each. This allows network administrators to rapidly identify where in this chain of events something is going wrong and to more quickly remedy the issue.
Wireless Health illuminates problematic steps in a client’s path to network connectivity.
There are many, many root causes of problematic connectivity. Among other things, authentication failures can happen when client credentials aren’t accepted by a RADIUS server, when the wrong pre-shared key is used for a given wireless network, or when a misconfiguration or an overloaded server prevents requests from getting through. DHCP failures can occur when a client device doesn’t receive an IP address — either because the DHCP server fails to respond or because there are no more available addresses to hand out. DNS failures can happen if a DNS server doesn’t respond to a client request for hostname resolution. And finally, success is measured not only by whether a client can successfully connect to a network, but also by whether that client can then pass traffic — so Wireless Health also details traffic failure rates.
Once a client has successfully connected, Wireless Health displays detailed metrics about network latency, identifying which types of traffic are showing performance problems at various thresholds of performance (measured in milliseconds).
Quickly identify which types of network traffic are experiencing the worst latency problems.
Network administrators can drill down and get granular metrics on latency across their network at the AP level and at the device type level, helping them quickly identify the worst-performing APs and clients.
Latency at the AP level.
Latency by client device type.
These metrics and anomalies are synthesized into a holistic, network-level view that allows administrators to quickly identify networks with problems that require attention.
Wireless Health provides network-level statistics on latency and connectivity.
RF Profiles
Each wireless network is a snowflake: it faces its own unique coverage challenges, configuration, and design — no two are exactly alike. It’s common for IT administrators to deploy several APs configured for a specific RF scenario (for example, a large, crowded auditorium) in one location, while needing to configure networked APs elsewhere for a different RF profile (like a small lobby or guest area). The radio settings for these two groups of APs can look quite different even though all of the access points are on the same network.
Enter RF Profiles. This feature allows network administrators to easily customize RF characteristics by deployment and manage diverse MR installations through the configuration of templated radio settings. These settings (which comprise a profile) can then be applied, en masse, to groups of APs. RF Profiles will include predefined templates for typical auditoriums, open offices, and outdoor coverage scenarios to help IT quickly configure wireless settings for maximum performance.
RF Profiles allows radio settings to be easily deployed to all the APs applied a given profile.
The radio settings that can be configured within a given RF Profile include:
Dual band and single band support for both 5 GHz and 2.4 GHz radios
Minimum mandatory data rates
Minimum and maximum transmit (TX) power levels
Receive sensitivity via Rx-SOP/CCA (801.11ac Wave 2 only)
Rx-SOP
RF Profiles includes a new setting that can be configured: Rx-SOP (Receive Start of Packet). Rx-SOP helps mitigate co-channel interference (when two or more radios use the same channel) in extremely dense environments by allowing an AP to disregard transmissions that do not meet a specified signal strength threshold.
In high density environments with many client devices trying to connect to a wireless network, IT admins typically deploy more APs to increase overall capacity. But adding more APs introduces interference, since the odds that two APs within earshot of each other use the same channel increases. By ignoring signals that don’t meet a certain threshold strength, Rx-SOP allows an AP to ignore clients on neighboring access points who are using the same channel — mitigating their ability to interfere.
RF Profiles (including RX-SOP) will be rolled out as a free and seamless update for all Meraki wireless customers sometime near the end of February of this year. Wireless Health will also be rolled out as a free update for all wireless customers, and a generally available beta will make its debut next month.
As always, we’re keen to hear your thoughts and feedback, so please drop us a line on social media or leave a comment in our Meraki Community. You can also check out our wireless webinars or visit us at meraki.cisco.com for more information.
As we mentioned earlier this week in our latest launch blog post, we are thrilled to announce a slew of new wireless access points (APs) and antennas that will be orderable and will begin shipping February 13th, 2018. Let’s dig a little deeper into the details and use cases of each.
Indoor access points with external antennas
In the wireless world, one-sized coverage does not fit all indoor scenarios. Although our access points easily satisfy the coverage needs of many — if not most — indoor wireless deployments, they come with built-in omni-directional antennas that can’t always satisfy the requirements of specific situations: high-density auditoriums or stadiums, focused coverage down long hallways, or warehouses with high, 25-foot-and-beyond ceilings, for example. For these situations, indoor APs with specialized antennas are required.
With this in mind, we’re thrilled to announce the addition of two new, indoor access points that support external antennas to the Meraki MR portfolio: the MR53E and MR42E.
The MR53E (left) and the MR42E (right) wireless access points.
Both are 802.11ac Wave 2 access points leveraging the traditional Meraki quad-radio architecture: a 2.4 GHz radio, a 5 GHz radio, a dedicated dual-band radio for security scanning and automatic RF optimization, and a dedicated Bluetooth Low Energy (BLE) radio. The MR53E delivers a 4×4:4-stream MU-MIMO architecture and support for multigigabit — with dual-aggregate radio speeds up to 2.5 Gbps. The MR42E has a 3×3:3-stream architecture with a dual-aggregate radio speeds up to 1.9 Gbps.
The MR53E is ideal for high-density deployments that require the utmost levels of performance or that are mission critical in nature. Think: critical care hospitals, stadiums, lecture halls, auditoriums. The MR53E will deliver the highest quality indoor RF coverage because its extra radio chain offers better signal strength, resulting in higher throughput and message integrity. The MR53E also offers extra flexibility and future-proofing with multigigabit support for the highest throughput over existing cabling — which saves money and time in the long run.
The MR42E is ideal for more average-density, general-purpose wireless installations that require focused coverage (e.g. down long hallways) or the flexibility of external antennas, which allow an AP to be repurposed for different wireless scenarios since you can purchase the right antennas for the new coverage map you are deploying.
Smart antennas
To support these APs, we’ve designed six new antenna families, most of which have smart technology allowing the MR53Es and MR42Es to automatically detect and classify the antennas — eliminating the need for manual configuration and guaranteeing the automatic selection of compliant transmit (Tx) power. Depending on the family, there may be options to buy packs of one, five, or six antennas — or else to purchase antennas with either five or six connectors.
New Meraki antennas for the MR53E and MR42E access points.
The new antenna options include:
Straight and bendable dipole antennas for omnidirectional coverage
Panel omnidirectional antennas for low-ceiling installations where aesthetics matter
Panel downtilt omnidirectional for higher (25 feet or above) ceilings and medium-density deployments
Wide patch antennas for wide angles of coverage in medium-density scenarios
Narrow patch antennas for very high-density environments like stadiums and auditoriums or for deployments requiring narrowly-focused coverage (i.e., down hallways).
Basic indoor wireless and rapid outdoor deployments
Some installations require wireless coverage for a small number of devices, where there are no plans to leverage location-aware services that require mobile app integrations and Bluetooth. For these customers, we’re excited to announce two new access points, the MR70 and MR20.
The MR70 (left) and the MR20 (right) wireless access points.
These APs are designed for lower density deployments, and have neither the dedicated third scanning/security radio nor the dedicated Bluetooth Low Energy (BLE) radio found in our other APs. This means that security and RF scanning are opportunistic — i.e., when the AP is not communicating with clients, and there is no support for BLE-based app integration. However, both the MR70 and the MR20 support Meraki’s built-in wireless Location Analytics.
The MR70 sports a 2×2:2-stream MU-MIMO architecture designed for those looking to rapidly deploy ruggedized wireless outdoors. Thanks to its integrated omnidirectional antennas (it does not support external antennas), the MR70 can be deployed quickly in the field. The MR70 supports Meraki’s self-healing, automatic mesh capability and is IP67-rated for dust, moisture, shock, and vibration.
The MR20 is an indoor model designed for basic, very low-density wireless coverage. It also sports a 2×2:2-stream MU-MIMO architecture, and, like the MR70, supports only opportunistic security and RF scanning. It’s ideal for SOHO and ultra-small business networks which service around twenty or fewer clients and that want the visibility and control of the Meraki dashboard, but are interested primarily in basic wireless coverage.
These new APs and antennas round out our robust portfolio of wireless access points, and enable IT administrators to make smart hardware decisions that fit the needs of specific deployments — whether entry-level or extremely challenging. Please check out our wireless webinars or visit us at meraki.cisco.com for more information. As always, we’re keen to hear your thoughts and feedback, so please drop us a line on social media or leave a comment in our Meraki Community.
When Stephen Stanton, VP of IT at A Wireless, was told about upcoming plans to acquire 370 stores across the United States, he didn’t think it would be possible. Stanton knew the company would not be able to scale at that rate with their legacy networking solution. But that was four years ago. Today, A Wireless, a full-service Authorized Verizon Retailer, has about 1,170 stores across 46 states—an almost tenfold increase in store locations.
On Thursday, February 9th at 10 AM PT, Stanton will join us in a live conversation to share how A Wireless evaluated and decided on Cisco Meraki as their solution of choice for national expansion.
As A Wireless acquired new stores, they also acquired a mix of IT networking solutions and vendor products. They found themselves with a network built on varying technologies, configurations, and management systems. Implementing a standardized network and centralized management was essential for their continued success.
Over a 3-year period, A Wireless have saved in excess of 80% in the total cost of ownership of the network, compared to a more traditional networking solution.
A Wireless TCO Cost Savings
Over 670 stores already fitted with a full suite of Meraki solutions, including MX Security Appliances, MR Access Points, MS Switches, and even a few MC Phones. Now, Stanton and his team are ready to deploy the next 500 locations with the same products and by the final deployment, all 1,170 stores will be full Meraki shops without any other network vendor solutions.
View a recording of this webinar, A Wireless, A Verizon Premium Retailer: Scaling Nationally with Meraki, here: [Link]
Systems Manager Sentry offers a range of features that make the life of IT administrators easier. By providing simple, automatic security that is context aware, Sentry dramatically simplifies previously complex configurations. To be able to take advantage of Sentry functionality, devices need to be enrolled in Systems Manager. There are a variety of ways this can be done, but one of the simplest is by using Sentry enrollment.
Sentry enrollment is available with Meraki MR Access Points (AP) and not only automates deployment of Systems Manager, but ensures policy compliance by requiring Systems Managers installation. Sentry enrollment is an option within the wireless access control page of the Meraki dashboard. By choosing the radio button that enables Systems Manager Sentry enrollment, all devices connecting to this SSID will be checked for Systems Manager.
With Sentry enrollment enabled and a Systems Manager network selected, the administrator then has a couple of options to choose from. The strength option allows the level of compliance to be tailored to suit your environment. With the strength set to ‘Focused’, only the system types you have chosen will be forced to enrol in Systems Manager. A good example of why this may be desirable, is if you only want mobile Apple devices such as iPhones and iPads under management, not Windows laptops. This can be achieved by choosing ‘Focused’ and selecting iOS as the only system type you wish to force to enroll.
When a user connects to an SSID with Sentry enrollment, they must have Systems Manager to be able to access the network. If a user removes Systems Manager from their device, they will be forced to install it again if they want to access the network. Watch the video below for a full dashboard and end user demonstration of this feature in action.
Users are guided through the enrollment process with the necessary settings pre-configured for them. This eliminates the need to pre-stage devices before they are delivered to users and allows enrollment as and when devices connect. Think of it as your fast lane to pervasive mobile device management.
Sentry features highlight the power and simplicity of the Meraki cloud architecture that provides native integration between different product families. Typically such enrollment or onboarding processes require additional servers, appliances, or licences. Even if this is not needed, integration between the MDM and the network (often from different vendors) can be complex to configure. With Meraki, enrollment becomes a couple of clicks and a matter of moments to enable. Find out more by attending one of our focused webinars covering the Sentry features of Systems Manager in further detail.
All Meraki wireless products offer out–of–the–box, easy to use location features as part of Cisco’s location analytics technology, Connected Mobile Experiences (CMX). With CMX location analytics it’s possible to determine important business metrics such as how many people enter your location, how long they stay, and how frequently they visit.
Adding no additional cost, thanks to the Meraki all-inclusive licensing model, this data has become available to many organizations that could not typically justify deploying when there was an additional cost. This has led to innovative uses of the location data that has enabled smart city initiatives, and allowed educators to understand student movements.
An important component of empowering this creative use of CMX location analytics was the release of an Application Programming Interface (API). This lets organizations have access to the raw data used by the Meraki dashboard. With access to the raw data there are some major benefits. The first is that no data is summarized and full device identities are included, facilitating lookup by other applications, like CRM. The second is that the data is provided offered with only a short delay between it being created and presented to the API.
Thus the API allows for highly advanced software systems to be developed that are location and identity aware. User identity can be linked to devices, location awareness becomes bound only by the geographical dispersion of your access points (AP), and software systems can make decisions within a time span that is relevant to a device’s location.
One of the downsides of providing raw data is that it can be complex to manipulate for the application developer. For this reason, the engineering team at Meraki developed a second generation API and open source example code. The version two CMX API can be selected in the Meraki dashboard and offers X,Y coordinates and latitude and longitude values. With the first API, radio signal strength values are provided for trilateration of a devices location. Further details on what is available in the API can be found in the documentation here.
To hear more about the development of the location API, and possible uses of the source code, then you can do so by listening to the above podcast with George Bentinck (Solutions Architect) and Nathan (Member of Meraki technical staff).
If you are interested in building an application with Meraki location information, then it is worth checking out our example code on GitHub here. This provides a great way of getting started with the CMX API and can form the base of your future projects. You can try an application based on this code, with live data from the Meraki offices in San Francisco, by following this link, or by viewing example output data here.
Cisco Meraki customers can easily future proof their networks for the needs of their business with the new Meraki MR32 and MR72 802.11ac access points (AP) that include built-in Bluetooth Low Energy beacon technology. These APs can be integrated seamlessly into any standard WLAN deployment, while giving customers a Bluetooth Low Energy beacon-enabled network, ready for the future. We see this being especially important in retail where iBeacons and other customer Bluetooth engagement technologies are rapidly growing in adoption.
What are Bluetooth Low Energy Beacons?
Bluetooth Low Energy is a recent enhancement to the Bluetooth standard which allows for the wireless protocol to be applied to new use cases which were previously not feasible. This is primarily due to the energy saving techniques implemented in Bluetooth Low Energy which reduce power consumption when compared to previous Bluetooth standards.
With the ability to efficiently utilize limited power sources, Bluetooth Low Energy is now used in a number of devices which need to communicate small amounts of data over wireless. It is now possible to have devices with battery life measured in months and years rather than days or weeks, while also making them smaller.
This has led to the development of beacon technology and its application in a number of situations. Beacons are very simple Bluetooth Low Energy messages which are transmitted or heard by compatible devices. This device could be a computer, a phone, a wireless AP, or a tag, to name just a few possible devices.
This message has three basic components:
Universally Unique Identifier (UUID)
Major
Minor
These components of the beacon can be configured with information the operator wants to communicate to other Bluetooth Low Energy-compatible devices. Typically this is in a non-human friendly form but it can be interpreted by a listening device. For example, in a retail environment it could be interpreted as:
Retail Brand (UUID)
Shop Location (Major)
Product Category (Minor)
When a compatible device hears one of these messages, a user-installed app which is beacon aware can interpret the information in the UUID, Major, and Minor identifiers. This could be used to trigger functionality in that app, for example it could display information relevant to a particular product in that shop, a discount to be redeemed at purchase, or a customer service interaction.
Is it worth using Bluetooth Low Energy Beacons?
Bluetooth Low Energy beacons are a simple way to provide mobile apps with location awareness that is specific to your organization. The low energy features allow mobile devices to use this functionality with minimal impact on battery life. The benefit of this is that apps can enable Bluetooth on devices with little negative side effects and a positive experience to end users.
The downside for organizations wishing to implement Bluetooth Low Energy beacon devices is the scale at which they could be deployed creates a significant administrative burden. With a thousand, or ten thousand of these devices, even a year long battery life would lead to a large number being replaced every week.
It also means that when it comes to configuration, it can require extensive pre-staging and visits to site. Should this need to be updated in the future to meet new business needs, the costs of doing this may outweigh the benefits of making the change.
Meraki has solved the physical and configuration challenges of implementing beacon technology by integrating it into the new MR32 and MR72 APs. These APs have fully integrated Bluetooth Low Energy radio chipsets that works in parallel to the three WLAN radios that are inside.
Bluetooth Low Energy and beacon compatible Meraki MR32 and MR72 APs
Hear from Adam Weiss, one of the Meraki engineers responsible for the development of the Bluetooth Low Energy functionality in the APs, on the possible uses cases of this technology and the importance of an integrated solution.
By integrating the Bluetooth Low Energy technology into the PoE compatible MR32 and MR72 APs, the problems associated with maintaining a widely distributed inventory of battery powered beacons is completely eliminated.
The unique cloud-managed architecture of the Meraki MR32 and MR72 means that they can be remotely deployed and configured for zero-touch deployments. The APs can broadcast Bluetooth Low Energy Beacons with a configured UUID, Major, and Minor that is only set once for a whole network of APs. If these identifiers need to be updated, it can be done quickly and remotely through the Meraki dashboard for all APs, all sites, or even different countries.
The rapid software development cycle of the Meraki cloud management solution means that as and when new Bluetooth Low Energy Beacon features are needed, these can be delivered seamlessly at no cost to existing deployments. This ensures your investment in APs can provide the greatest value for the longest period of time.
The end goal of any site survey is to ensure the most optimal configuration of the wireless network for the given requirements. These requirements can differ from physical location to physical location and can even vary within different areas of a location. Often the requirements have to be balanced against each other to reach the most optimal outcome. The requirements can include:
Specific support for high density or real-time applications like voice
Location services and positioning
Outdoor coverage
Minimization of interference with other networks or RF signals
Budget
Designers of wireless networks have a number of tools in their armory to meet these requirements. Some of the areas a designer can control are:
The location of the APs
The number of APs
The transmit power of the APs
The channel the APs use
Site Survey – a Designer’s Best Friend
Due to the nature of radio waves, it can often be hard to visualize how aspects of your design will work when viewed as a collection of numbers and PDF specifications. The physical environment also has a major impact on how you design the deployment and how the APs will work. Enter the site survey and fantastic site survey tools such as Ekahau’s Site Survey and Fluke Networks AirMagnet.
These applications and others like them, allow you to visualize your WLAN deployment before, during, and after its deployment. Invisible radio waves become easy to understand with colorful heatmaps. Site surveys can be divided into three types that are typically carried out in order; predictive, pre, and post site surveys.
Predictive surveys use floor plans, estimates of building materials, and advanced algorithms to predict how the wireless network will look. This is based on the number of APs, their location, and their configuration.
Pre-site surveys allow the wireless designer to accurately record the reality of the physical environment where the WLAN will be deployed. This can then be used to prove, or disprove the validity of the design that is often created by a predictive site survey. The pre-site survey is typically carried out by placing an access point of the model you wish to use, with the configuration you think is appropriate, in different locations in the building. At each location the wireless is surveyed by taking readings using the site survey software. This then uses the information to update its model of the design.
Finally a post-site survey repeats the measurements taken by the pre-site survey but this time with all the APs for the final deployment in place. This survey is used to prove the design is correct or help identify adjustments that need to be made.
Although it is not essential to carry out all types of site surveys, it is generally recommended that at a minimum, a pre-site survey is carried out for any location with more than a handful of APs.
Listen to Ryan, a support engineer in the Meraki San Francisco office talk about the importance of surveying for your WLAN.
ap.meraki.com
To perform a site survey with an AP, desired settings are typically configured before, then moving it between the locations that are being surveyed. The AP is often attached to a tripod or other type of stand to simulate the physical position it would have when deployed e.g. wall mounted or ceiling mounted. To make the movement of the AP easier, it is not normally attached to AC power and is instead powered by a portable battery pack.
Before the introduction of the dedicated site survey mode on the Meraki APs, it was necessary to include an additional equipment beyond just power. The reason for this was that the self healing auto mesh functionality built into every Meraki AP would try and repair the AP’s connection to the LAN. It does this by scanning for other mesh APs to communicate with when it can’t see a gateway. When this happened, it meant that site survey tools were not able get a reading.
The new site survey mode allows network admins to turn an AP into a dedicated device for site surveys. When enabled the AP will broadcast an open SSID named “site_survey-” followed by its MAC address. The AP can then have the channels and transmit power set for both 2.4Ghz and 5Ghz radios.
To access the site survey mode, wirelessly connect to the desired AP and enter ap.meraki.com into your web browser. Alternatively you can access the same page by entering the LAN IP address of the AP into your web browser.
This local management page on the AP is used for basic setup, troubleshooting, or for when a specific manual configuration is required. Choose the ‘Configure’ tab and enter the credentials requested by the login box. Once logged in, you can access the settings for the site survey mode.
Summary
Completing a site survey is often an essential step on the path to an efficient, high performance WLAN. Ensuring your deployment is right from the start can save many hours of troubleshooting and associated costs later on. The new Meraki site survey mode will help make this process simpler and easier for anyone going through this activity.
Not content with just announcing two new 802.11ac access points (APs) in time for the holidays, the team here at Meraki have developed new software features, soon to be available on all APs. These are:
Flexible Bitrate selection
Site Survey Mode
Flexible Bitrate Selection
We’re adding the ability to configure the supported association bitrates. When an AP is advertising its services to clients it will let them know the lowest possible speed (association rate) it will accept a connection at. This is important as a client would like the highest possible association rate, but this is dependant on how well it can hear the signal. As clients move further away from APs they will often get a lower strength signal and so a lower association rate.
Because of the shared nature of wireless transmissions, clients with low association rates can slow the whole network down. This is particularly important in high density environments such as public areas, lecture halls or conferences. By allowing the network administrator to choose the lowest association rate an AP will allow, the administrator can prevent clients slowing the network down. Setting a higher association rate can force clients to move to an AP which has a better signal and thus can support the higher mandated association rate.
Site Survey Mode
Planning, designing, and deploying wireless networks often requires important but time consuming wireless site surveys. To help reduce the amount of time and complexity involved in completing a wireless site survey using Meraki APs, we are introducing a new site survey mode. This will help ensure that it is easier to complete high quality surveys and consequentially install a high performance network.
The new site survey mode is accessed from the local management page on the AP and allows for important parameters to be configured, such as the radio channels and transmit power. Once this survey mode is enabled, the AP will no longer need a connection to the Meraki cloud and will not try to mesh with other Meraki APs. Once you have completed your survey, you can easily revert the AP to its normal mode of operation.
When and how it will come to your network
Both features are currently in beta and will become available to customers over the coming weeks. As with all software updates to Meraki products, this is a staggered roll out and will be automatically delivered to you at the time and day you select. Make sure to check your ‘Firmware Upgrades’ settings in your Meraki dashboard to choose when you would like your upgrade to happen.
