When MV12 launched back in February, wireless functionality was mentioned, but the specifics were promised for later in the year. Today, the wait is over, as wireless functionality on all MV12 models is now available.
But why wireless anyway? It’s a great question, and the answer is rooted in the architecture of analog camera deployments.
Looking at the back of an analog camera, there are two inputs: data and power. Power for analog cameras traditionally comes from low voltage power supplies—the very same that are hooked up to badge access systems, powered doors, and other facilities infrastructure. Data is transmitted using coaxial cable.
Cabling for an analog camera system.
IP cameras, on the other hand, typically receive data and power via Ethernet, from a PoE-enabled switch.
Users looking to upgrade from analog to IP often realize that after including labor, downtime, and the recabling itself, the process may end up being cost prohibitive, especially at smaller or remote site locations. Consequently, it may not be surprising that these locations are often where VHS-based NVRs can still be found.
A new approach, and a new accessory
Realizing that a recabling requirement can often derail an entire project, we wanted to find a better approach. Utilizing over ten years of Meraki’s wireless experience, MV12 security cameras have been built to be able to connect to any industry standard WiFi network as a wireless client. This means data no longer has to travel via that Ethernet cable.
So how to solve the power dilemma? Starting today, a new Meraki power adapter is available, converting those low voltage power supplies (12VDC/24VAC) into PoE. Installers can simply unplug the power wires from an analog camera, connect them to the terminals in the power adapter in either order (the accessory figures this, and the input voltage, out for you, so no guesswork is required), and an Ethernet cable plugged into the RJ45 port will deliver PoE to a camera.
What about the data? SSID authentication information can be entered in the dashboard. After downloading this configuration through the LAN, cameras can be powered on with this new accessory within range of a wireless access point (it doesn’t have to be a Meraki AP, though centralized management of APs and cameras is a bonus if it is!). And that’s it—the coax cable can simply be left in the wall and will no longer serve a purpose.
This process is quicker, less expensive, and less disruptive than the typical recabling process, and will enable more customers to take advantage of MV12’s advanced analytics, easy-to-use interface, and centralized management.
1:00 pm: Students trickle back into class after a well-deserved lunch break. Eager to get started with their next lesson, they grab their school-issued laptop out of their emptying backpack, log on, and start their next assignment while patiently waiting for the teacher to bring attention to the front of the room. Unbeknownst to the students and teachers actively participating in classroom activities, the network deployment team paces the halls, double checking that each new access point has a home, and that each switch will be comfortable in its new closet.
3:30 pm: The bell rings. Students rejoice; jumping, dancing, and skipping out of the building, excited to get to their study group, sports practice, or friend’s house. Some stay behind to attend an after-school course, work on homework, or attend a teacher’s office hours. Behind the scenes, the deployment team sneaks inside empty classrooms and offices, unmounting old access points and seamlessly swapping them for brand new, inconspicuous access points to take their place. From the gym to the cafeteria, no space can be left unconnected. With great attention to detail and swift hanging capabilities, the team goes room by room, replacing and adding APs, making sure no classroom is left behind.
4:30 pm: The last of the students head home for the day, with tired eyes, full brains, and superb stories. Once everyone has left the campus, and the school buildings start humming in their normal emptied silence, the real fun begins. Operation: the complete switchover. The deployment team speeds through the remaining AP installation. They move onto the closets, and in a sea of cables, sweat, and servers, they unrack and uninstall the legacy switches, tossing them into a corner of their already forgotten memory. Installing the new switches is faster than a cheetah lapping the school, with an organized, lit up rack of switches foreseeable on the other end.
5:00 pm: Testing. Testing. 1, 2, 3, testing. The devices are online. The computers are connecting. The tablets are connecting. Even the phones are connecting! The intrusion detection system is working. The security cameras are on. We are a go! Network complete.
This nonfiction tale tells the story of Orange County Public Schools (OCPS), the 9th largest school district in the United States, with around 208,000 students spread across 200 schools. And yes, they continue to flip schools left and right in four hours, moving them off of their legacy equipment and onto a Meraki network of MR access points and MS switches. Originally a project that David Overton, Senior Director of Information Security, thought would take several years to finish, is on pace to finish in under two years, with the deployment team transitioning three schools a week. And, for the schools that have already moved onto Meraki, not only has student learning through their 1:1 device program continued to work without a hitch, but the simplified management through the Meraki dashboard has been a lifesaver for the IT team.
To learn more about OCPS and their Meraki deployment, watch a webinar recording with David and a Meraki product specialist. They discussed why David chose Meraki, how they are able to install a new network in 4 hours, and why a robust network is imperative to supporting their 1:1 device program. Watch here!
This is the sixth in a series of blog posts that focus on wireless technology and security at Cisco Meraki.
The frequency spectrum that wireless networks operate in are shared frequency spectra; this is one of the reasons that Wi-Fi networks are so polite with one another. However, there are many more potential sources of interference, such as Bluetooth and microwave ovens in the 2.4GHz spectrum or medical scanners and radar in the 5GHz spectrum.
These sources of interference can have a detrimental effect on the usability of wireless networks. Meraki Auto RF is a powerful and automated RF optimization solution that ensures that Meraki APs create the best possible environment for the clients served.
Listen and Learn
Auto RF is able to do this because all Meraki APs have a dedicated security radio that also provides visual spectrum analysis. The Meraki APs also share this data with the Auto RF algorithm to determine the optimal channel plan and transmit power appropriately. In addition to this, Meraki network administrators can also get access to real-time channel utilization scans from the live tools section of each and every AP, as shown below:
This gives the administrator both instantaneous and historical data about interference sources seen by that particular AP. This listening radio can also be accessed to provide information in an industry-standard format too, which has traditionally only been available on dedicated spectrum analysis tools.
For customers with older Meraki APs without dedicated listening radios, it is possible to configure the access radios so that they periodically stop serving clients and start listening to the RF.
Auto channel is enabled by default on Meraki networks but can be turned off if desired. When enabled, the Meraki dashboard follows best practice for channel use, meaning that only the three non-overlapping channels in the 2.4GHz spectrum are available. In the 5GHz spectrum, the channels available to the AP depends on both the country and hence regulatory domain that the AP is installed in and the type of AP, i.e. indoor or outdoor. Additionally the network administrator can choose to exclude DFS channels, which will prevent the AP from having to roam away from a channel if a radar signal is detected. Finally, administrators can also select the default channel width for transmission in the 5GHz band, as 802.11n supports channel widths of 40 MHz and 802.11ac supports channel widths of 80 MHz and up to 160 MHz, although 160 MHz is not suitable for enterprise deployments or supported in the Meraki dashboard.
In order to tune the transmit channel, the APs track the following three things:
Usage Demand – APs within the dashboard network are monitored for their usage demand, i.e. the number of clients and amount of traffic being served by the AP. These values are mathematically combined so that each AP has a weighted value. This value is then used to ensure that the cleanest channels are utilized in the most demanding areas.
Airtime Availability – Each access point listens to the contention and airtime availability, i.e. free time in the medium, for each channel and bandwidth combination. When this data is aggregated it can be used to maximize the available airtime for all APs in the network, also known as the Basic Service Set (BSS), and also minimizes contention and improves client roaming performance. All visible APs — even neighboring APs — are considered in this metric, with Meraki APs being weighted higher to optimize roaming and airtime usage distribution. As opposed to just being polite (i.e. presuming they have as high a priority to the airtime as the Meraki AP and they’re clients) with respect to neighboring networks and APs, this metric ensures that the AP and its clients also have ample airtime availability.
Channel Utilization – This metric includes both 802.11 and non-802.11 (Bluetooth, microwave ovens, etc.) sources of spectrum utilization. These external sources of interference are detected and accounted for within this metric.
The dashboard uses this information to tell the APs to move to a different channel if, say, a new AP is added, a channel becomes jammed, or the network administrator clicks the “Update Auto Channels” button.
Channel moves can also be triggered by the “Steady State” process, which runs every 15 minutes. The Steady State process will instruct the AP to move channels if a better channel, based on the above criteria exists. However, the Steady State process is aware when a channel is being used for point-to-point communications and it will not change the channels of APs acting as a gateway AP.
Auto Tx Power
Auto Tx Power operates by sampling the signal-to-noise ratio of neighboring APs in the same network. These readings are compiled into neighbor reports that are sent to the dashboard for processing. All AP neighbor reports are then aggregated and the dashboard leverages that aggregated data to determine each AP’s direct neighbors — APs that clients being served by the AP are likely to roam to — and how much each AP should adjust its transmit power to optimize cell coverage. The dashboard completes this calculation and instructs the APs to adjust their respective transmit power once every 20 minutes.
As with Auto Channel, Auto Tx Power is mesh-aware and the same Steady State process/algorithm prevents power adjustments for APs that are acting as a gateway for an active mesh repeater.
Meraki’s Auto RF technology auto-tunes the RF for all but the most particular RF environments, and it does so without any need for additional appliances, services or licenses, by leveraging the power of the power.
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.
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.
This is the fifth in a series of blog posts that focus on wireless technology and security at Cisco Meraki.
Meraki APs are known for their ability to form ad hoc wireless mesh links to one another and then route across those links. This functionality automatically works over large distances and allows customers to extend their LANs.
One might naively think that all that would be required for this type of connection to work is line of sight between the two transmitters. However the physics of electromagnetic wave propagation make this a little more complicated than that. Luckily, a French physicist named Augustin Jean Fresnel (pronounced Fre-nell) worked this out in the early 19th century. In this post we will explain why this is the case.
Ya’ canna change the laws of Physics (Captain)
In order to understand how this works we first have to understand the true nature of the radio waves we use in Wi-Fi. They look like this:
Image credit: NASA
As we can see, all radio waves take the form of a sinusoidal wave that we’re all (hopefully) familiar with from high school mathematics. These radio waves will move in a straight line from the transmitter to the receiver.The problem arises when radio waves that emanate from the transmitter spread out at an angle, creating an effect known as diffusion. This can be seen in the 5GHz radio profile of the Cisco AIR-ANT2513P4M-N antenna, which is compatible with Meraki’s outdoor access points and used in highly direction use cases, as shown below:
Taken from – https://www.cisco.com/c/en/us/td/docs/wireless/antenna/installation/guide/ant2513p4mn.html
If no obstacles are encountered by the radio waves then they will just keep going until they run out of energy. However, in an urban environment they are likely to encounter a surface, which can reflect the radio wave in such a way that it is received at the receiver but is “out of phase” with the original radio wave. So that if the reflected radio wave is half a wavelength (or a multiple of half a wavelength) behind the original unreflected radio wave. This can reduce the power of the received signal and is called “phase cancellation.” It works like this:
This results in a loss of signals because the two waves combine with one another, as illustrated below:
What Monsieur Fresnel did was calculate how out of phase the signals would be for an elliptical area (kind of like a sausage shape) between the transmitter and receiver. There are infinite zone sequences, but for the purposes of point-to-point radio, and hence Wi-Fi signals, only the first three are important. These zones are illustrated below:
The first and third zones have the cancellation effect shown above, whereas the second zone actually has an additive effect. This simply means that in order to maximize the signal we need to keep the first Fresnel zone as clear from any sources of obstruction and reflection as possible. The most widely accepted guidance is that the first Fresnel zone must be 60% clear of obstructions, i.e., an obstruction can’t protrude more than 40% into the zone from the direct line of sight at any point between the transmitter and receiver, like this:
If you need to calculate what the Fresnel zone would be for your point-to-point Meraki wireless connection then all you need is this, or if you have a few hours to spare you can derive the equations from first principles.
As long we follow this pretty simply rule for point-to-point links then it’s all smooth sailing then, right? Well, there is one more thing to consider — and this may come as a shock to Kyrie Irving (even though he was just trolling) — but the curvature of the earth can also be an obstacle.
When a length point-to-point link is over 7 miles, the curvature of the earth will impede into 60% boundary we discussed above and shown below:
In order to mitigate this effect the height of the transmitter and receiver become very important, especially when you are trying to enable network service in remote areas without cellular service for interesting use cases.
Even though Meraki APs will automatically create point-to-point links with one another, we still need to be careful when implementing the service. Meraki magic still has to obey the laws of physics.
This is the fourth in a series of blog posts that focus on wireless security and technology at Cisco Meraki.
Wireless networks underpin most of our day-to-day activities, all while sharing the same relatively small frequency spectrum. As such, the protocols that dictate how these networks work are exceptionally polite by design, and for good reason. This is because wireless networks, like humans, are half-duplex, meaning only one station or person can talk at anyone time.
However, this politeness can also be used against such networks by potential “bad actors.” This post will detail how Cisco Meraki access points help our users’ networks from being excessively impacted by such malicious (intentional or otherwise) devices.
How can broadcasting be bad?
You may be asking “why would a network broadcast be a bad thing? On my wired network, protocols use broadcasts all the time,” and you would be correct that broadcasts are seldom a problem on the wired side of network (but not always). However, as we have previously discussed, wireless is a shared access medium, so if someone was continually talking (packet flood discussed below), we would have to wait for them to stop. More importantly, when an access point transmits to a client on a wireless network, it has to transmit at a speed that the client can understand. For a broadcast frame, this speed is actually the slowest supported data rate of the BSSID and is often a basic data rate.
This means that when transmitting broadcast (and management) traffic, the access point can only talk as fast as the slowest data rate at which the BSSID will accept a client association. If the default settings for minimum bit rate have not been changed, then an access point will send the broadcast frames out at up to 150 times slower than it could do (though this isn’t something Meraki recommends).
This can render the 802.11 network unusable, as the access points are always busy transmitting or waiting for the malicious broadcast traffic (if another AP or client is broadcasting). This behavior is often weaponized by bad actors into a DoS attack against wireless networks.
Meraki APs help minimize excessive broadcast traffic from entering the wireless medium from the wired network by enabling Proxy ARP. This means that an access point currently serving a wireless client responds to an ARP request from the wired portion of a network on behalf of the wireless client, which would have otherwise been sent as a broadcast.
Additionally, Air Marshal can alert Meraki network administrators to malicious broadcast traffic that has been seen by the access points in their network, as shown below:
Then, the administrator can investigate the local environment to ascertain and mitigate the source of the malicious broadcasts.
What is a packet flood?
In a similar manner to misusing broadcast traffic, a client or AP could send out large amounts of 802.11 management (beacon, association, and authentication) frames, knowing that an access point is bound by protocol to process and, where appropriate, respond to them. This is akin to an inquisitive toddler peppering their parent with questions, without waiting for a response, over and over again.
As any teacher or parent will know, working in this kind of environment requires either the patience of a saint or the unconditional love of a parent. Alas, for 802.11 networks, access points, whilst being very polite, lack both of these things! As such, when a client behaves in this manner, it is detrimental to the performance of the overall wireless network in much the same way as excessive broadcast traffic.
As with malicious broadcast traffic, Air Marshal will alert the administrator that the access points within their network are seeing this potentially nasty behavior and display the frame type, as shown below:
Then, the administrator can investigate the local environment to ascertain and mitigate the source of the malicious broadcasts.
Other things to consider…
Finally, one other type of network-level transmission that can cause issues in 802.11 networks is multicast traffic. Unlike wired networks, wireless networks typically send multicast traffic flows over the wireless medium as broadcast traffic. In order to alleviate this potential issue, Meraki access points enable IGMP by default. This has the effect of converting the multicast stream into (potentially multiple) unicast transmissions that are likely to be transmitted at much higher speeds.
This is essential in classroom environments, where students could be watching a multicast HD video stream as illustrated above.
Similar to the “evil twin” attack discussed in the previous blog post, there is nothing that can be done to mitigate these risks while still complying with the 802.11 network standard. However, the power of the Meraki dashboard and access points provide instant visibility into threats in an organization.
For more information on Air Marshal and spoofs please see the following additional references:
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 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.
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)
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.
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.
On February 9th we announced the launch of the latest access point (AP) to join the Meraki wireless portfolio, the flagship MR42. The MR42 is a 3×3:3 802.11ac Wave 2 AP that ushers in a new era of high performance, more efficient WiFi thanks to the inclusion of Multi User – Multiple Input Multiple Output (MU-MIMO).
In addition to this, the MR42 continues our strategy of completely integrated beacon and Bluetooth Low Energy (BLE) functionality. This sees the MR42 becoming our most technology advanced wireless platform, with four integrated radios and the latest 802.11 wireless standard, yet all in a sleek low profile design.
MU-MIMO allows wireless networks to more efficiently service the increasing numbers of phones, tablets, and other personal mobile devices. MU-MIMO does this by allowing the AP to communicate with multiple devices concurrently, rather than consecutively.
With Single User MIMO (SU-MIMO) the AP can use the multiple spatial streams to send a large amount of data to clients that can receive all these streams. Devices such as laptops could support two or sometimes three streams, allowing for high speed connections. Unfortunately smaller mobile devices like phones can typically support only one stream, and thus can’t take advantage of this capability.
MU-MIMO solves the problem of devices being unable to use all these spatial streams. The AP can use the individual spatial streams to send separate transmissions to distinct clients simultaneously. This increases the total network performance and improves the end user experience, especially when large numbers of devices are connected.
The addition of MU-MIMO complements Single User MIMO (SU-MIMO) rather than replacing it. An AP can choose the best way to transmit: simultaneously to multiple devices as efficiently as possible, or consecutively to individual devices as fast as possible. It is now time to wave goodbye to slow WiFI.
Are you looking for a next generation wireless solution that can future proof your network against the growing demands of your users? Then there is now one clear choice, the cloud managed Meraki MR42 AP. To find out more details you can visit the product page or listen to one of our launch webinar recordings.
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.