Meraki MV Cameras - Introduction and Features
This article goes through basic camera industry terminology and an introduction on MV features. The following is an explanation of some terminology you may come across when deploying, designing, or installing security camera networks.
The focal length is a technical measurement of a camera lens and affects the Field of View (FoV). The longer the focal length (typically measured in millimeters), the more zoomed in the picture will be.
A camera with a variable focal length, sometimes called varifocal, can be adjusted to optically magnify (or zoom) to enhance detail of distance objects.
A camera with a fixed lens cannot have its focal length adjusted. Cameras with fixed lens are most common in indoor, multi-imager, or fisheye cameras, although some outdoor cameras have fixed focal lengths as well.
Meraki MV cameras have various models that have Varifocal and Fixed lenses.
The focal length of the MV12N is longer than the focal length of the MV12W and therefore the MV12N has a more narrow field of view.
Field of View
Field of View (FOV) is the term used to describe how much of a scene a camera can see. A narrow FOV (in layman’s terms, when the lens is more zoomed in) will show only a small part of a scene, e.g. the door entrance to the room. A wide FoV will show a large part of a scene, e.g. the entire room and not just the entrance door. FoV is often broken into parts Horizontal and Vertical and expressed in terms of degrees.
Depth of Field
Depth of field refers to the range of distance where objects appear acceptably sharp in an image. It varies depending on camera type, aperture and focusing distance. In security camera applications, it is almost always preferable to have as much of the image within the depth of field as possible. Cameras that are placed to cover both near and distant objects must reduce the aperture, softening the image due to diffraction (see circle of confusion for more information).
The aperture describes the iris or hole that lets light into the camera’s sensor. The larger the hole, the more light can enter the camera. The more light that can enter the camera, the better it can see in poor light and the brighter the picture will be. The higher the aperture (less light) means an increase in depth of field. The lower the aperture (more light) means a decrease in the depth of field.
The lux (symbol: lx) is the SI derived unit of illuminance and luminous emittance, measuring luminous flux per unit area. It is equal to one lumen per square meter. In photometry, this is used as a measure of the intensity, as perceived by the human eye, of light that hits or passes through a surface. It is analogous to the radiometric unit watt per square meter, but with the power at each wavelength weighted according to the luminosity function, a standardized model of human visual brightness perception. In English, "lux" is used as both the singular and plural form.
A dome camera is a form factor of security cameras that are a dome or half a sphere. The benefits of this form factor are that it can be easily and discreetly installed in many locations.
An Ingress Protection rating (or IP rating) is a standardized measure of a device’s ability to withstand water and dust. An IP66 rating means the device is weatherproof. The official terminology states that it is completely protected from ingress of solid objects and water projected in powerful jets (12.5mm nozzle) against the camera from any direction, which covers rain. More information about IP Codes can be found at https://en.wikipedia.org/wiki/IP_Code.
The Meraki MV71 camera is IP66 rated.
An IK rating is a standardized measure of a device’s impact resistance. IK ratings fall between 0 and 10+. It provides a means for specifying the capacity of an enclosure to protect its contents from external impacts. More information on IK ratings can be found at https://en.wikipedia.org/wiki/EN_62262.
The Meraki MV71 has the second highest level of protection—IK10—and is protected against a 5kg object dropped from 40cm in height.
PTZ, or pan-tilt-zoom, describes a type of camera that allows the user to adjust the camera lens along three axes remotely. Panning a camera moves its field of view back and forth along a horizontal axis. Tilting commands move it up and down the vertical axis. Zooming a camera affects how close objects appear in the field of view.
An image sensor or imaging sensor (also: imager) is a sensor that detects and conveys the information that constitutes an image. It does so by converting the variable attenuation of light waves (as they pass through or reflect off objects) into signals, small bursts of current that convey the information. The waves can be light or other electromagnetic radiation. Image sensors are used in electronic imaging devices of both analog and digital types, which include digital cameras, camera modules, medical imaging equipment, night vision equipment such as thermal imaging devices, radar, sonar, and others. As technology changes, digital imaging tends to replace analog imaging.
Early analog sensors for visible light were video camera tubes. Currently, used types are semiconductor charge-coupled devices (CCD) or active pixel sensors in complementary metal–oxide–semiconductor (CMOS) or N-type metal-oxide-semiconductor (NMOS, Live MOS) technologies. Analog sensors for invisible radiation tend to involve vacuum tubes of various kinds. Digital sensors include flat panel detectors.
Shutter speed describes how long the shutter stays open, allowing the camera to collect light when it is taking a picture. As video is a series of pictures (frames), this setting applies to the video frames. The longer the camera collects light, the better it can see in low light.
Meraki MV shutter speed is automatically controlled by the camera and can be between 1/5th and 1/32,000th of a second.
Infrared (IR) Illuminators
Infrared (IR) illuminators are lights to illuminate dark scenes. The infrared range of wavelengths on the electromagnetic spectrum are invisible to the human eye but can be seen by cameras. Infrared illuminators allow cameras to see in the dark when humans cannot.
Meraki MV infrared illuminators are powerful for their size, with a range of up to 30 meters (or 98 feet) with the MV21/MV71 and up to 15 meters with the MV12.
Some security camera designs call for external IR illumination, especially where large or distant scenes need to be captured. In these cases, separate IR “flood lights” are used to illuminate the scene.
Solid State Storage
Solid state storage is storage memory that has no physical moving parts. Some examples of solid state storage are the memory in a modern smartphone, flash memory on a thumb drive, or the SD card in a digital camera. The opposite of solid state storage would be magnetic storage; an example is a traditional hard disc with a spinning magnetic disc. Solid state storage is faster and more reliable than traditional spinning hard disks.
High endurance refers to integrity of a camera’s storage over an extended period of time and a large number of write cycles. Solid state storage wears out over time each time it is rewritten with new data. To ensure cameras can reliably store video, the MV uses a state-of-the-art, high-endurance and high capacity solid state memory technology. Other vendors’ cameras sometimes offer swappable memory; however, users will often replace factory memory with consumer-grade storage, which has not been designed for high frequency use (P/E cycles) and is more prone to failure.
Video resolution is the number of distinct pixels in each dimension that can be displayed. It is usually quoted as width x height with the units in pixels (example, 1920x1080 means the width is 1920 pixels and the height is 1080 pixels). Resolution directly influences the amount of bandwidth consumed by the video surveillance traffic. Image quality (a function of the resolution) and frame rate are functions of the amount of bandwidth required. As image quality and frame rate increase, so do bandwidth requirements.
Analog Video Resolutions
Video surveillance solutions use a set of standard resolutions. The National Television System Committee (NTSC) and Phase Alternating Line (PAL) are the two prevalent analog video standards. PAL is used mostly in Europe, China, and Australia and specifies 625 lines per-frame with a 50-Hz refresh rate. NTSC is used mostly in the United States, Canada, and portions of South America and specifies 525 lines per-frame with a 59.94-Hz refresh rate. These video standards are displayed in interlaced mode, which means that only half of the lines are refreshed in each cycle. Therefore, the refresh rate of PAL translates into 25 complete frames per second and NTSC translates into 30 (29.97) frames per second.
Digital Video Resolutions
User expectations for resolution of video surveillance feeds are increasing rapidly partially due to the introduction and adoption of high-definition television (HDTV) for consumer broadcast television. A 4CIF resolution, which is commonly deployed in video surveillance, is a 4/10th megapixel resolution. The HDTV formats are megapixel or higher.
Digital Video Surveillance Resolutions (in pixels)
While image quality is influenced by the resolution configured on the camera, the quality of the lens, sharpness of focus, and lighting conditions also come into play. For example, harshly lit areas may not offer a well-defined image, even if the resolution is very high. Bright areas may be washed out and shadows may offer little detail. Cameras that offer wide dynamic range processing, an algorithm that samples the image several times with different exposure settings and provides more detail to the very bright and dark areas, can offer a more detailed image.
As a best practice, do not assume the camera resolution is everything in regards to image quality. For a camera to operate in a day-night environment, (the absence of light is zero lux), the night mode must be sensitive to the infrared spectrum.
Video Compression Codecs
A codec is a device or program that performs encoding and decoding on a digital video stream. In IP networking, the term frame refers to a single unit of traffic across an Ethernet or other Layer-2 network. In this guide, however, frame primarily refers to one image within a video stream. A video frame can be made up of multiple IP packets or Ethernet frames.
A video stream is fundamentally a sequence of still images. In a video stream with fewer images per second, or a lower frame rate, motion can be perceived as choppy or broken. At higher frame rates up to 30 frames per second, the video motion appears smoother; however, 15 frames per second video may be adequate for viewing and recording purposes.
Some of the most common digital video formats include the following:
Motion JPEG (MJPEG) is a format consisting of a sequence of compressed Joint Photographic Experts Group (JPEG) images. These images only benefit from spatial compression within the frame; there is no temporal compression leveraging change between frames. For this reason, the level of compression reached cannot compare to codecs that use a predictive frame approach.
MPEG-1 and MPEG-2 formats are Discrete Cosine Transform-based with predictive frames and scalar quantization for additional compression. They are widely implemented, and MPEG-2 is still in common use on DVD and in most digital video broadcasting systems. Both formats consume a higher level of bandwidth for a comparable quality level than MPEG-4. These formats are not typically used in IP video surveillance camera deployments.
MPEG-4 introduced object-based encoding, which handles motion prediction by defining objects within the field of view. MPEG-4 offers an excellent quality level relative to network bandwidth and storage requirements. MPEG-4 is commonly deployed in IP video surveillance but will be replaced by H.264 as it becomes available. MPEG-4 may continue to be used for standard definition cameras.
H.264 is a technically equivalent standard to MPEG-4 part 10, and is also referred to as Advanced Video Codec (AVC). This emerging new standard offers the potential for greater compression and higher quality than existing compression technologies. It is estimated that the bandwidth savings when using H.264 is at least 25 percent over the same configuration with MPEG-4. The bandwidth savings associated with H.264 is important for high definition and megapixel camera deployments.
H.265, also known as MPEG-H Part 2, is a video compression standard, one of several potential successors to the widely used AVC (H.264 or MPEG-4 Part 10). In comparison to AVC, HEVC offers about double the data compression ratio at the same level of video quality, or substantially improved video quality at the same bit rate. It supports resolutions up to 8192×4320, including 8K UHD. H.265 is more efficient than H.264, but its benefits are most often seen with higher resolution video, such as 4K.
As of October 2018, Meraki MV cameras use the H.264 codec.
HTTP Live Streaming (HLS) is a protocol originally developed by Apple for streaming media. It works by creating a continuous collection of small files which are downloaded by the web browser and played back seamlessly. Video delivered this way is simple for a browser to interpret and removes the need for special software or browser plugins that can show the video. HLS provides superb video quality and solves an issue with video buffering seen in other protocols by using chunks to make streaming playback seamlessly. The trade off for seamless playback is a few seconds of latency for video feeds caused by distribution, encoding, decoding, and default playback buffers.
Meraki MV cameras use HLS streaming to provide frictionless viewing of live and recorded video within a browser.
Video is made up of still images played back quickly in quick succession. Each still image is known as a frame and the number of frames played in a second (FPS) will dictate how smooth the motion in the video is. The higher the frame rate the smoother moving things will appear. TV shows are typically 30fps, movies 24fps, and security cameras are variable between 1fps and 30fps. For motion JPEG sources, the play rate is the number of frames-per-second or fps. For MPEG sources, the play rate is the number of megabits-per-second or Mbps and kilobits per second or Kbps.
Frame rate control is a feature of some cameras that varies the frame rate depending on movement within the image. Thus, when movement is detected, the frame rate is increased.
Bit rate is the amount of data used to store one second of video. This is measured in bits per second and is typically measured in kilobits or megabits.
The bit rate determines the total amount of information that can be stored in one second. This is then divided by how many frames are in a second. The lower the frame rate for a given bit rate, the higher the quality each frame will be.
Constant Bit Rate
Constant bit rate (CBR) recording means that no matter what happens in the scene, the camera will encode video to satisfy the configured data bitrate.
Variable Bit Rate
With variable bitrate recording (VBR) a camera (or VMS) can adjust the amount of data in the bitrate to more efficiently record video. A target bitrate is normally chosen to serve as an average the camera will try to achieve. When the scene is empty or nothing is happening, the camera can reduce the bitrate. When a lot is happening in the scene, the camera can increase the bitrate.
Meraki MV cameras use CBR.
Dynamic Range (Wide and High)
High and wide dynamic range are camera techniques for capturing the same image at different exposures and then merging those images together to form a single image. This is particularly useful where the image consists of very light and very dark areas (e.g., an indoor camera that faces a window to outside).
High dynamic range (HDR) is performed in software, and can be problematic in scenes with fast moving objects. Wide dynamic range (WDR) is a term more commonly used in the CCTV industry. Most often, HDR and WDR solve the problem of lack of detail in dark areas of an otherwise bright image and/or lack of detail in the bright areas of an image.
Meraki MV cameras uses HDR in the generation 2 (MV12, introduced 2018) and later cameras. Generation 1 cameras (MV21, MV71, introduced 2016) are 69dB which is typical of a camera with standard dynamic range.
By using a wide-angle lens, the camera can span a much wider field of view than normal cameras (some camera lens designs even cover a full 360 degrees). Immersive imaging facilitates digital PTZ. The result is the ability to pan, tilt, and zoom digitally within a frame, even though the camera itself does not move.
“Intelligent video” is an industry-adopted term that refers to a camera solution analyzing an image and performing an action or actions based on what it “sees.” At Meraki this can refer to the MV family’s motion analytics, dynamic retention policies, or object counting/detection abilities.
In motion based recording, a camera only records when it detects motion in a frame. Typically, recording is triggered by the amount of motion in the scene, e.g. a person walking through the door. Motion based recording allows for longer video retention than continuous recording using the same quantity of storage; however, this technology is prone to false negatives (and a subsequent loss of video data) when the minimum motion threshold is not triggered by an event.
Motion based retention differs from motion-based recording in that, instead of recording only when motion is detected, footage is deleted from the camera (using software) when there is no motion detected in the historical footage. This allows the camera to keep a few days of the most recent footage in its entirety, before removing older footage that does not contain motion, thus extending storage durations.
In direct streaming (or local streaming), an MV camera sends video directly to a user's browser over the local network. This uses no WAN bandwidth when the user and camera are local to one another. No manual configuration is needed to enable this functionality. The benefit is it is quicker and more efficient than cloud proxy streaming.
Cloud proxy is used to stream video when dashboard automatically determines that a user’s device has no direct connection to an MV camera in the LAN. The video stream is then proxied through Meraki’s cloud infrastructure, allowing a user to view live and historical video. This uses WAN bandwidth and is slower to load than local streaming.
The video wall is a dynamic video interface for viewing a collection of tiled camera feeds. It can show both live and historical video in a user's web browser, without the need for any software or browser plugins. All video tiles in a single video wall will remain synchronized throughout the process of reviewing historical footage (even while using the Motion Search tool).
Adaptive Bitrate Streaming
Depending on configured resolution and quality settings, streaming video from a MV camera can consume up to ~3 Mbps per camera. Adaptive Bitrate Streaming (ABS) reduces the overall bandwidth consumption by selectively streaming a lower-quality bitrate stream when the size of the video element is below 540p, or full quality when above. With ABS, the bandwidth required to stream a video wall with 16 high-quality 1080p cameras is reduced by ~40 Mbps!
Security and Architectures
Cyber attacks have become more and more prevalent, with attackers leveraging any insecure means of entry into the network. Recent attacks have used poorly secured security cameras and NVRs as the path into the network. As such, these devices should have the same level of security as traditional network devices.
By simplifying the architecture and making many best practice security features enabled by default, Meraki’s MV security cameras offer extensive security out of the box.
Let’s compare traditional camera systems to the Meraki MV Camera solution.
Traditional systems typically rely on an onsite network video recorder (NVR) or server-based recording solution. Additionally, proprietary software packages requiring manual download and configuration are often necessary. These additional moving parts all need to be securely configured, and managed, and require continuous security patching and software updates for the life of the system if network security is a priority. A greater number of devices on the network also means more possible entry points for attackers if these devices are not properly secured and kept up to date.
Security patches are required and must be manually managed and deployed for the below:
OS and OS modules like IIS, MS DB app like MS access
Meraki MVs simplified architecture completely removes the need for a network video recorder (NVR), a video management system (VMS), servers and other proprietary software by storing and processing video at the edge, on the camera itself (not in the cloud). No NVR means one less point of vulnerability since the NVR/DVR is the second most targeted piece of the networking stack during cyber attacks. In conjunction with local storage, cloud management allows cameras to be configured and monitored from anywhere in the world with an internet connection. Metadata, thumbnails, and configuration data are stored in the cloud though video data is not.
Security patch management is automatically handled and deployed by the Meraki dashboard. This means MV cameras are always up to date with the latest security fixes and new features. As a Meraki security camera solution does not require additional servers, software, or devices, there is no need to update or maintain other systems.
With regard to our data centers, the Meraki service is colocated in tier-1 data centers with certifications such as SAS70 type II / SSAE16 and ISO 27001. These data centers feature state of the art physical and cyber security and highly reliable designs. All Meraki services are replicated across multiple independent data centers. This means services fail over rapidly in the event of a catastrophic data center failure. More information about our data centers can be found on our Cisco Meraki data centers information page.
Passwords and Administrators
With a traditional camera system, passwords are required for the NVR/DVR, cameras, VMS, and server operating systems. Typically, no central repository exists for managing all of these passwords. Therefore, many administrators opt to keep the default password or create very simple, easy to guess passwords, like “password.” Also, as employees leave the organization, the lack of centralized password management makes it difficult to ensure those who should no longer have access are removed from the system. Traditional systems do have the ability to create admin and user accounts with varying levels of permissions. If site administrators do decide to implement this security best practice, the lack of a central repository for account credentials means distributed environments with multiple NVR/DVRs must manage accounts by connecting to each NVR/DVR in their deployment. The pitfalls of traditional security camera deployments’ password and administrator access follow:
Often have a default username/password which can be found online
Weak passwords - no complex password enforcement
No central repository for system password management
The Meraki dashboard makes centrally managing administrator accounts very simple, while still providing the most secure options for password management. Unlike traditional systems, multiple passwords are not needed for the different devices and servers on the network. Each administrator uses his/her unique credentials to access dashboard. This offers visibility and control of the camera they have permission to manage. The inherent centralized management capabilities of the dashboard mean that access and permissions are easily audited, and administrators are easy to add and remove from the system. The dashboard supports SAML integration with existing databases to enable use of a directory service for usernames and passwords.
Dashboard has advanced security options like two-factor authentication, strong password requirements, and password expirations that can be configured to meet an organization’s security policy. Two-factor authentication adds an extra layer of security to an organization's network. After an administrator enters his/her username and password, a one time passcode is sent via SMS that must be entered to complete the log in. In the event that a hacker guesses or learns an administrator's password, they still will not be able to access the organization's account, as the hacker does not have the administrator's phone.
Below are the security options built into the Meraki dashboard.
Role-based administration allows for the creation of administrators for certain subsets of an organization. These roles can be furthered customized with specific levels of access that an admin should have on the network. Role-based administration reduces the chance of accidental or malicious misconfiguration, and restricts errors to isolated parts of the network.
When a network admin with camera-only privileges logs into the dashboard, their view is restricted in terms of both devices and functionality. The menu is simplified for easy access to the cameras. Camera-only admins have view-only rights, so they are unable to make changes to the image settings, including focus and zoom, or quality and retention settings.
Camera-only admins are frequently used to allow an individual access to only specific cameras. A person could be given access to view live video footage of cameras on the building’s 5th floor. This allows them to see who is walking on this floor before admitting them into certain parts of the building. In this scenario, camera-only admin settings for the person “Daisy Leg” would be view live footage, for cameras with the "5th_floor" tag.
Secured Access and Encryption
Traditional Access and Encryption Solutions
With traditional solutions, a camera continuously streams footage to an NVR for recording. This data stream is typically unencrypted and not secured. The default accessibility for local access to view recorded video from the GUI is via unencrypted HTTP ports. Enabling secure HTTPS access requires deploying and managing certificates. This is often beyond the knowledge or skill set of many administrators, so data traversing the network is left unencrypted.
Remote access with traditional camera solutions is not available out of the box and requires additional VPN and/or complex firewall configuration. If an organization chooses to use VPN, a head-end VPN device needs to be deployed and configured on-site. VPN software must be installed and configured on all administrators’ devices that will be used for remote access. Devices without VPN configurations will not be able to remotely access the system.
If remote access is set up through port forwarding or 1:1 NAT, then SSL/TLS certificates must be used to ensure encrypted access to the system. This requires managing, deploying, and renewing certificates for the camera system. Managing certificates can be complex, and proper configuration and management require specific knowledge and skill sets. With port forwarding this can expose systems to known vulnerabilities. Examples include things such as hardcoded root username/passwords (set by vendors) that cannot be changed.
With traditional solutions, end-to-end encryption and security tend to be treated as optional. Some manufacturers have specific cameras and solutions with these features built in; they label them as “Cyber Secure” options.
End-to-end encryption is not always possible, as it requires that all components of a solution support this functionality. With traditional deployments, the cameras, NVRs, and VMS tend to be from different manufacturers. Collaboration between manufacturers is required to implement an encryption solution integrated into all components.
Companies that support in-transit encryption from the NVR to the viewer offer it as an optional feature that is not enabled by default. If enabled, the encryption key needs to be managed and installed on all devices that will be used to to view the cameras locally or remotely. Because of the need for manual installation and management, encryption in transit from the NVR to the user is rarely used.
Finally, with regard to encryption at rest, most manufactures do not have a solution to encrypt data stored on NVR/DVRs. If unauthorized users obtain to the drives, they may be able to access and view recorded footage.
The Meraki Access and Encryption Solution
MV cameras are easily accessed through any modern web browser (without downloading of plug-ins) at dashboard.meraki.com. The Meraki dashboard intelligently determines if the viewing computer is on the same local network as the cameras or not. If it is, video traffic will stream directly and securely over the LAN, saving WAN bandwidth. If not, the dashboard will proxy video through the cloud to a remote client.
If the client has an IP route to the private IP address of the camera, a secure connection will be established between the two. This occurs when the client is either on the LAN, over site-to-site VPN or client VPN. In the LAN scenario, no WAN bandwidth is used for the video streaming. Direct streaming is indicated by a green check mark in the bottom left corner of the video stream.
No special configuration (VPNs, port forwarding etc) is needed for remote access. Dashboard is accessible anywhere with internet access. If the client does not have an IP route to the private IP address of the camera, the dashboard will automatically send video via cloud proxy. Cloud proxy streaming is indicated by a cloud symbol in the bottom left corner of the video stream. Meraki can detect if SSL inspection is occurring upstream or potential ‘Man in the Middle’ attacks. Since Meraki only trusts certificates from the Meraki CA (certificate authority) we will not establish any connections if a certificate is injected in the chain. Another layer of protection for customers data.
Whether viewing cameras remotely or locally, access to the Meraki dashboard is only available by HTTPS. This ensures all communications between an administrator’s browser, the MV management interface, and camera is always encrypted.
Upon initial boot up, the MV camera goes through a full disk encryption process. This ensures all footage on the camera is encrypted at rest. Additionally, each camera automatically purchases, provisions, and renews their own publicly-signed SSL certificates. The result is that all footage is encrypted in transit between the camera and browser. Lastly, management data is encrypted using our Meraki secured mtunnel technology. All of this is enabled by default, and cannot be turned off, ensuring access to cameras and the dashboard are always encrypted and secured, regardless of an organization’s security expertise.
The direct streaming certificate is very secure and is a popular format used by Google, Facebook, Yahoo, and others. It allows for high throughput without compromising on security
Technical breakdown of certificates and encryption:
Hashing algorithm is SHA256
Signing algorithm is RSA2048
Key parameters are secp384r1
Key exchange is Diffie-Hellman 2048
Cipher is AES128
Encryption at rest:
Hashing algorithm is SHA256
Key size is 256 bit
Cipher is AES256
Alerts and Logging
Traditional Alerts and Logging Solutions
In traditional systems, alerting requires integration of the NVR/DVR and/or VMS with an email server. This integration adds additional complexity and requires technical skills to deploy. If an organization has multiple NVRs/DVRs, this integration must be configured on all devices. As alerts originate from the NVR/DVR, alerting is usually only available for camera status. This means that alerting will not function if an NVR/DVR goes offline, and organizations may not know that there are issues with cameras or storage until there is a need to pull footage.
The Meraki Solution
The Meraki dashboard can send email alerts when network configuration changes are made, enabling the entire IT organization to stay abreast of new policies. Change alerts are particularly important with large or distributed IT organizations. Knowing when a camera is malfunctioning or offline is crucial. Alerts can be set to be proactive in system maintenance and monitoring.
The Login Attempts page displays historical login information for the Dashboard Organization. A login event will be generated any time any of the current Organization or Network Administrators attempts to login to the Dashboard. This includes regular Dashboard login attempts and SAML logins. These events will record the following information about the login attempt:
Email: the email address that was used for the login attempt
IP Address: the IP address that sourced the login attempt
Location: approximate Geo-location of the IP that sourced the login attempt
Type: type of login attempt, either 'Login' (normal Dashboard login) or 'SAML'
Status: displays the success or failure of the login attempt
Timestamp: the timestamp of the login attempt
Additionally, Meraki provides a searchable configuration change log, which indicates what configuration changes were made, who they were made by, and which part of the organization the change occurred in. Auditing configuration and login information provides greater visibility into your network.
Designing Meraki MV Security Camera Solutions
There are a number of ways to design an IP surveillance system. The most important part of the design is identifying areas of security concern and positioning cameras to cover those areas. There are a variety of ways to design camera coverage for the same building. Too many designs are primarily built with the cost of installation in mind, instead of looking at the system as an investment in protecting assets and/or people. A good IP surveillance system should be focused on protecting people and assets. The first steps to building such a system are analyzing the building or facility and conducting a site survey.
Conducting a site survey helps provide an understanding of the security needs of a building/facility, and determines the requirements to address those needs. At the conclusion of a site survey, there should be a clear understanding of what needs to be monitored, the materials/parts needed, labor required, total number and locations of cameras to be installed, and an estimated cost for deploying the solution.
Pre-site Survey Requirements
The list below is a starting point to identifying deployment needs, and will help ensure a better site survey outcome:
Acquire to-scale floor plans of the building(s)
A purpose of the site survey is to determine the mounting locations of cameras to be installed. Having floor plans helps the site administrator and the installer both fully understand the intent of the design and requirements. If outdoor camera coverage is also required, try to obtain external building plans as well.
Locate all network equipment closets
During the site survey it is necessary to understand existing network equipment, as the cameras will most likely be powered by and connected to the network. Identifying these locations beforehand is necessary.
Ask the simple questions:
Why is an IP video surveillance system needed?
What purpose does the system serve?
What are the requirements the system MUST have and why MUST the deployment have them?
When does the project need to be done?
Where is camera coverage required?
Who and/or what needs to be protected?
Are there any restrictions around mounting cameras to walls and/or ceilings?
Are there any restrictions around running CAT5e/6/7 cabling throughout the building/facility?
Get keys and access to ALL parts of the building/facility
This may be difficult as some companies/entities have high levels of security. Be sure to coordinate with management/security/facilities, and explain the purpose of and requirements for survey.
Schedule and treat the site survey like a project
Coordination and communication is key to making the site survey a success. Identifying things in the pre-site survey meeting can save a lot of time during the site survey.
Understand and know the County/State/Local regulations around cameras/surveillance for each facility to be surveyed
Conducting a Site Survey
The site survey determines where to place the cameras. It may also uncover additional suggestions or recommendations that were not initially considered.
Site Survey Checklist
Have a system to take extensive notes and make recommendations
Have several copies of the floor plans handy for marking where cameras should be installed
Take lots of pictures! Pictures can help convey design a lot more easily and are extremely helpful for documentation.
Consider the following to determine placement for each camera:
Take into consideration camera position and areas of high contrast - bright natural light and shaded darker areas.
It is HIGHLY recommended to have at least two (2) vantage points on each ingress and egress point. Having multiple cameras covering the same area is a GOOD thing, as it creates redundancy for backup.
Consider the following areas as examples:
Entrances, exits, loading, and/or delivery entrances to the building(s)
Any gateway(s) or parking areas/lots where employees/guests park vehicles
Cashier, ATM, and other locations handling monetary transactions
Highly used areas such as lunch rooms, reception areas, break rooms, waiting areas, hallways, etc.
Perimeter coverage of building, including walkways, fences, patio, and outdoor accessible areas used by employees, guests, and others
High value items and areas where security and visibility are a necessity
The closer a camera is positioned with a narrow field of view, the easier things are to detect and recognize. General purpose coverage provides overall views.
Will camera placement require a man lift for installation?
How difficult and high is the mount? This may affect future maintenance.
What mounting equipment is required for each camera and how will they be mounted?
Height of installation
Distance to targets
Angle of placement
Mounting style and mounts (ceiling vs. wall)
Determine if new cable runs are required and the distance of the cable run to the nearest networking closet
If vandalism of cameras is a concern, position the IP66 rated vandal resistant cameras offered in the Meraki portfolio
When it comes to audio recording be aware of local laws
Determine if existing networking equipment is adequate for new security cameras
Are there enough ports on the switch(es)?
Are additional network switches required?
Are these ports PoE and does the equipment have adequate PoE budget to compensate for security cameras?
Is the UPS adequate enough to handle the additional power draw and meet company policy standards for run time when down?
Are power injectors required?
Create network diagrams and document internet connections
What is the WAN design and LAN uplink connections and are they adequate to support the necessary streaming?
Are there dedicated computers for video surveillance?
What are the specifications of these computers and do they meet the minimum requirements to run a dedicated video wall?
Which employees have access now and who will require access to the new security camera system?
Other notable considerations:
Use tools such as IPVM.com as resources for determining proper placement for cameras and illustrating the outcome of an installation could look like
Consider using a live camera on a stick connected to Meraki MX65 (or similar device with PoE ports and access to internet via USB Cell provider) and UPS on a rolling cart (similar to an Active Wireless site survey) [This is very time consuming but provides examples of what camera footage will look like after installation. Would require at least a MV21, MV12N, and/or MV12W (different optics in each of these models)]
Post-Site Survey Report and Deliverables
The site survey process starts with information gathering, then the actual on-site survey, and is concludes with documentation of the results and findings. The site survey report should be presented in a format that clearly shows the recommendations and design for the security system. This ensures all parties fully understand the requirements and deliverables for implementation. Below are recommendations of what should be included in the final report from a site survey:
A full write-up on findings, obstacles, and recommendations
Explain in detail needs from network
Additional network cable drops
A floor plan indicating locations of all networking closets and recommendations on camera locations
LAN/WAN diagrams and information about Internet connection
Show ports and cable types connecting all network devices
Document VLANs, ACLs, Routing
Complete equipment/materials list necessary to complete design
Configuration details of existing network equipment
Is QoS adequate?
Will a new VLAN schema need to be built out?
Do firewall ports need to be opened to the Meraki cloud?
Is the existing security system computer adequate to handle video streams?
Designing a Meraki MV Security System Best Practices
Meraki MV cameras are designed to simplify deployment and enable the more efficient implementation of a security system. Many people are fully capable of installing an MV camera without needing a site survey, and there are many instances in which a site survey may not be necessary. This may include smaller installations with fewer than 10-15 cameras, or replacing an existing system. However, it is always a good idea to have a plan, determine the scope of the project, and think through how a security system will perform and interact before deploying. This section covers best practices for developing and implementing a new physical security system.
Build a Physical Security System Requirements Plan
A physical security system requirements plan (PSSRP) is developed by an organization or company to outline requirements for a security system. Borrowing ideas from plans of other entities is okay, as long as they meet the security requirements for the organization installing the system. The goal of a PSSRP is to ensure consistency across multiple buildings, which helps with network security and accessibility.
Define a Network Layout in the Meraki Dashboard
A network in the Meraki dashboard is a logical separation of devices managed in a single container. A network can be defined in a number of ways, but many Meraki customers divide networks up geographically so that each building/location can be managed independently of other locations. There are many ways to divide up networks, and some customers may choose to create only one. When planning the network design within the Meraki dashboard, it is helpful to think about users may need access to the system and which parts they will need to access. Within the dashboard, a user can be given rights at an organization or network level; separating each location into its own network makes it easy to grant an individual access to just the location they are responsible for. In addition to organization and network-wide administrators, the dashboard also allows a number of camera-only admin capabilities, as shown below.
Create a Naming and Tagging Schema for Cameras Being Installed
By default, the Meraki MV apply the MAC address given to the device as the name for each camera. This helps identify each camera initially, but it is not easy to remember which camera is represented by which 12 characters. Naming and tagging become even more important the larger the deployment. Make it a point to apply a name to each camera that makes sense, is logical, and is easily understood when looking at a list of cameras. Tags are applied to cameras to help group them with other like cameras. Multiple tags can be applied to a single camera. Tags are useful to sort or find a group of cameras and apply features or administrative rights to a group of cameras.
Design a VLAN Schema, Determine QoS Policies, and Apply Network Security
Creating layer 3 VLAN boundaries has been common in network security for years, as network administrators use VLAN separation to help protect devices and data. Creating a separate VLAN for security cameras only is highly recommended. Make sure this port is configured as an access port (trunk is not needed). This gives the ability to create access control lists on the layer 3 SVI to specify what can access to those devices specifically. It also enables the use of QoS on a VLAN basis throughout the campus/building network. The QoS marking recommendation is DSCP of 40 (CS5 - Broadcast Video). Be sure to have a QoS network policy in place, as this is needed throughout the network. Analyze all aspects of the routed traffic, including switches and routers. The Meraki MV automatically tags for QoS and the upstream network devices only need to trust the tag.
Determine Administrative Access to the System
As mentioned previously, administrative access is important in considering and designing an organization or network schema. Organizational-level administrators have access to the entire dashboard, all networks, and organization-wide pages, including licensing, inventory, creating/deleting networks, etc. Network-level administrators have the ability to access and manage everything within a network in an organization. This means they can see and modify general settings. Organization and network-level admins can be given read or write access. Camera-only admins have only access to cameras. Access can be granted to all cameras, individual cameras by name, or groups of cameras by tags. Permissions can be set to allow the user to view/export all footage, view all footage, or view only live footage.
Determine Quality and Retention for Each Camera
It is important to create a policy for video quality and retention for each camera. Policies may differ based on camera location, purpose, and what is being recorded. It is possible that all cameras may have the same policy, but there may be different needs for different groups of cameras.
In most cases, having at least some amount of recorded video is recommended. However, some locations and/or countries have very specific privacy laws; if this is the case, it is important to configure cameras to adhere to these laws. By default, Meraki cameras are set to always record footage, and delete only when space runs out (files follow a first-in-first-out, or FIFO, methodology). When needed, cameras can be set to record based on a schedule, and delete footage after a certain period of time. Example configurations for footage deletion and recording schedules can be seen below:
Motion-based retention can be enabled when feasible to extend the storage capacity for each camera. When enabled, the camera will always retain the most recent 72 hours of continuous footage recorded. After three days, video clips which do not contain any motion are automatically deleted, allowing the camera to store only footage of interest and increase retention. Motion-based retention is disabled by default.
Video resolution isn’t a big mystery: the larger number in 1080p vs 720p means that there are more lines in the frame of video being displayed. Higher resolution means higher bandwidth and storage requirements. The same holds true in frame rates or fps. Estimated retention is automatically calculated for each camera based on its current settings. These settings include 24x7, scheduled, or motion-based retention, along with video resolution and quality. Higher video resolution and quality is recommended, but isn’t always necessary in all deployments.
Some Meraki MV cameras, like the MV12, can record audio. Audio recording is disabled by default. Determine if recording audio is a requirement and if so, if it is legal. Privacy laws vary from country to country, and not adhering to laws can result in serious repercussions.
Night Mode Configuration
When ambient light falls below certain thresholds, the cameras can switch to night mode, allowing them to be more sensitive to infrared illumination. By default night mode is set to “auto” and the built-in infrared illuminators of the Meraki MV cameras are set to “on during night mode.” For first generation cameras, “Transition thresholds” can be adjusted to fine tune night (and day) mode. By default, the transition thresholds are configured at 0.5 lux for night and 3.0 lux for day. Keeping default settings is recommended.
Second generation cameras will automatically transition in and out of night mode based on optimal transition thresholds. 2nd gen cameras will prefer night mode in low light environments as it provides a much higher video quality in regards to physical security. Night mode allows for easier detection and classification of objects in the scene when video is reviewed for security purposes.
Motion alerts send notifications via email when motion is detected either within the frame or a selected region of a camera. These can be extremely useful in monitoring areas where tracking motion is important. Motion alerts can be configured to be sent always, or only during a certain schedule. Scheduling motion alerts is useful when monitoring an area after hours. Motion alerts are disabled by default.
Create an Inventory List for All Cameras
This is multifaceted as it will help with pre-installation setup and deployment as well as help with post-installation documentation. Having something as simple as an excel spreadsheet listing a camera by model number, serial number, name, MAC address, location description, and other details in the PSSRP is a big plus when coordinating efforts with multiple hands. This can easily be done with the CSV export tool within the Meraki Dashboard from a network or organization inventory.
Define Necessary Video Walls for Monitoring Feeds
Video walls can be configured to allow for simultaneous viewing of multiple camera feeds. It may not be possible to determine all video wall needs prior to implementation, as customers may not know what they want or need. However, it is useful to have some basic video wall needs defined, as it is helpful in conveying how the system can operate/what it can do.
Determine which Users Need Alerts
A big advantage of the Meraki MV system is that the camera device (node) functions in relationship to other equipment in the dashboard. This enables alerting/notification of administrators in the event that the system goes offline. In many other systems, the security cameras, video management system, and storage solutions operate independently in silos. If one part of the system fails, there may not be a process to alert or notify administrators of the failure. This results in many administrators not knowing that a camera or storage system is offline until there is a need to pull footage. As part of the deployment, determine which users should be notified of issues, and configure alerts to be sent in the event of operational disruptions.
Dedicated Security or Monitoring Station(s)
Monitoring stations are common in instances that security guards need to watch multiple areas of a facility or campus. The Meraki dashboard can be configured with video walls to view up to 16 simultaneous camera streams at once per browser. System requirements for machines running video walls are available in our Hardware Guidelines for MV Streaming Workstations document.
Implementation and Installation of Meraki MV Cameras
Pre-Install Preparation for MV Cameras
MV Cameras are powered by Power over Ethernet (PoE) via the ethernet cable. The consumption for MV12 and MV21 is within the 802.3af standard (PoE). The outdoor camera MV71 requires 802.3at (PoE+).
A vital part of a security camera system is time synchronisation for each camera. This is done automatically through the Meraki dashboard. No local NTP server necessary.
Assigning IP Addresses
Like any other network device, the MV camera requires an IP Address. MV units must be added to a subnet that uses DHCP and has available DHCP addresses to operate correctly. At this time, the MV cameras do not support static IP assignment.
Check and Conﬁgure Firewall Settings
If a ﬁrewall is in place, it MUST allow outgoing connections on particular ports to the Meraki dashboard. The most current list of outbound ports and IP addresses for your particular organization can be found here.
Each MV will generate a unique domain name to allow for secured direct streaming functionality. These domain names resolve an A record for the private IP address of the camera. Any public recursive DNS server will resolve this domain. If using an on site DNS server, please allow *.devices.meraki.direct or configure a conditional forwarder so that local domains are not appended to *.devices.meraki.direct and these domain requests are forwarded to Google public DNS.
Conﬁguring a Network in Dashboard
All dashboard configurations should be done prior to installing any cameras. This allows the camera to associate with the correct organization/network in dashboard and download its configuration.
The following is a brief overview of the steps required to add an MV to your network. For detailed instructions on creating, conﬁguring and managing Meraki Camera networks, refer to the online documentation (https://documentation.meraki.com/MV).
Login to http://dashboard.meraki.com. If this is your ﬁrst time, create a new account.
Find the network you want to add your cameras to, or create a new network.
Add your cameras to your network. You will need your Meraki order number (found on your invoice) or the serial number of each camera, in an “xxxx-xxxx-xxxx” format, located on the bottom of the unit.
Verify that the camera is now listed under Cameras > Monitor > Cameras.
For an easy way to view and configure, install the Meraki App on your smartphone or tablet.
Note: During first-time setup, MV cameras will automatically update to the latest stable firmware. Some features may be unavailable until this automatic update is completed. This process may take up to 10 minutes, as it also includes whole-disk encryption. If you view cameras in dashboard during the setup, you may see the error message “Could not reach camera" while attempting autofocus. You will need to wait until the camera finishes upgrading to the latest stable firmware to use this feature. Please do not unplug cameras until they fully complete the upgrade process.
Installing and Configuring MV Cameras
Note: Leave the plastic film cover on all lenses until installation is complete. Take photos of installed cameras for reference. Add a name and physical address to each camera.
Depending on your camera model, please follow the installation instructions in the respective Installation Guide.
Adjust and focus the camera.
Configure various video settings based on your design principles (see Design section):
Restrict the video viewing and export permissions for administrators as described here.
Post-Implementation and Troubleshooting
Run Dark Mode
Run dark disables the LED lights on all MVs. This feature is useful in situations where the lights may be annoying, distracting, or overly conspicuous. For example, the LEDs can be disabled to prevent outdoor MVs from drawing attention at night. To enable dark mode, add the tag “run_dark” to the camera. More details can be found in our Dark Mode documentation.
Troubleshooting IR Reflections
All Meraki MVs, with the exception of the MV32, are equipped with infrared (IR) illuminators. These can be turned on in night mode and used to provide an illuminated view. If the picture appears too blurry, please follow this Video Quality Troubleshooting guide.