A video analytics architecture designed around the camera, not a separate analytics appliance

Traditional enterprise CCTV designs commonly separate image capture, recording, management and analytics into different layers. Cameras send streams to an NVR or video-management server; a separate analytics server may then process those streams; storage arrays may be needed for retention; and remote users often depend on the central recorder being available. Meraki MV takes a different architectural approach. Supported cameras include compute resources for machine-learning functions and, on most models, integrated solid-state video storage. Centralized configuration, user administration and device health are handled through the Meraki cloud-management model.

That architecture matters because analytics can be produced close to the scene. People or vehicle detections do not require raw video to be continuously transported to a central AI server merely to identify activity. The result can reduce the amount of infrastructure that must be installed at each site, while still allowing authorized users to access cameras from a central interface. It also changes the buyer’s planning priorities. Instead of sizing a large recorder around aggregate incoming video bitrate, a Meraki design focuses more strongly on choosing the right camera, storage/retention profile, uplink readiness, license structure, and user-access model.

This does not mean the network becomes irrelevant. Every camera still needs reliable power and network connectivity for management and normal remote workflows. Upload traffic becomes especially important where cloud archive is enabled, where remote viewers frequently stream video, where exported clips are transferred, or where API and integration traffic is used at scale. The difference is that continuous raw video recording can remain associated with the camera rather than requiring an always-on central recorder for the standard MV architecture.

For a Dubai buyer, this architecture is often most useful in distributed estates: branch offices, retail chains, campuses, warehouses, logistics facilities and hospitality properties where operational teams want one management experience across many locations. The design can be equally effective for a single high-value facility, but the commercial case should still be based on the required viewing, retention and analytics outcomes rather than on architectural simplicity alone.

What the analytics layer can actually do

A practical Meraki video analytics project starts by separating three different needs: security investigation, live situational awareness and business analytics. They may use the same camera estate, but they are not the same requirement. Security teams may care most about rapidly finding a person or vehicle moving through a defined scene. Facilities teams may care more about how many people occupy a queue, meeting area or entrance. Developers may want structured detection data for another application. Treating these as separate outcomes prevents a buyer from assuming that one generic “AI camera” specification automatically satisfies every use case.

Choose the camera around the scene and analytical goal

Cisco Meraki offers multiple MV form factors rather than a single universal smart camera. Indoor mini-domes can suit offices and controlled interior areas; outdoor models are designed for harsher conditions; varifocal domes allow a project to tune coverage for entrances, corridors, loading areas or other scenes; fisheye models provide broad overhead coverage and are particularly relevant to people-counting designs; and multi-sensor platforms address very wide areas. Model selection should therefore begin with the required scene, not the camera’s maximum resolution.

For presence analytics, Cisco documentation specifically identifies third-generation fisheye models such as MV33 and MV93 as preferred options for accurate people-counting workflows when the advanced people-counter mode is used and installation geometry is appropriate. That recommendation is significant. A high-resolution camera mounted at an oblique angle may be excellent for identification and still be the wrong instrument for a precise doorway count. Conversely, a ceiling-mounted fisheye optimized for counting may not give the facial detail or distant scene coverage expected from a varifocal security view. The right architecture can therefore use different camera types in the same site.

A site survey should also confirm environmental factors that are easy to miss in a desk-based bill of materials: backlighting through glass entrances, reflective floors, changing sunlight, shelving that blocks views, high ceilings, vibration, heat exposure, conduit requirements, permissible mounting positions and the availability of PoE switching. These are not secondary installation details. They determine whether the image entering the analytics engine is suitable for the business outcome.

Investigation workflow: from alert or question to relevant footage

Analytics are valuable only if operators can move from an event to evidence quickly. Meraki Vision is Cisco Meraki’s camera-viewing portal for core physical-security workflows. It provides an interface for navigating cameras, viewing live or historical video, running motion search, retrieving and sharing footage, and creating video walls. Current Cisco documentation also makes an operational distinction that buyers should understand: camera settings, configuration, troubleshooting and analytics administration remain in the Meraki Dashboard, while the Vision Portal is focused on viewing and investigation workflows.

That separation can work well when user roles are designed deliberately. A security guard may need a clean viewing experience and access only to specific sites or camera walls. A security administrator may need to manage camera settings and export evidence. An IT administrator may need device health, network context and organization-level controls. Senior management may need selected analytics without unrestricted access to sensitive footage. The project should define these roles before deployment rather than giving every user the same dashboard permissions.

Motion search is especially useful where a question is spatial: “When did someone enter this stock room?” or “When did a vehicle appear near this loading bay?” An operator can focus on activity rather than manually scrubbing hours of footage. Object-detection metadata can further help surface periods in which people or vehicles were observed. These tools improve investigation speed, but they do not remove the need for camera coverage design. If the subject is too small, obscured, backlit or outside the required field of view, sophisticated search cannot reconstruct missing visual evidence.

For larger estates, the buyer should also define naming, network structure and camera placement metadata. A portal is only as usable as the logical organization behind it. Consistent site names, floor references, camera labels and ownership rules make cross-site searches and incident handovers faster. This governance work is inexpensive compared with hardware and is often one of the strongest determinants of long-term operator satisfaction.

Video retention is a design decision, not a storage-size assumption

Retention is one of the most misunderstood parts of smart-camera procurement. The useful question is not simply “How many gigabytes are in the camera?” It is “How many days of usable footage do we need, at what quality, under what scene activity, and must a copy exist away from the camera?” Meraki MV models use onboard storage in the standard architecture, with retention affected by model, video-quality settings and the amount and type of motion in the scene. Cisco also provides Smart Retention on eligible cameras to make retention behavior more predictable by handling event and continuous streams differently.

Smart Retention is designed to preserve higher-fidelity footage for motion events while retaining a lower-resolution continuous stream for periods without motion, subject to the camera model and configured quality. This can increase the practical retention available for security-relevant activity without treating every quiet minute exactly the same as an active scene. It is especially useful in environments such as corridors, storage rooms, entrances after hours and controlled areas where activity occurs intermittently.

However, the expected retention must still be checked for the chosen model and scene. A busy retail entrance, continuous conveyor line, road-facing outdoor view or warehouse aisle with constant movement can behave very differently from an office corridor. Lighting, camera angle, object size and background motion can also influence how much motion the camera registers. FourTeck therefore recommends tying the required retention period to a named operational or compliance requirement and validating that requirement against the actual camera configuration.

When Cloud Archive enters the design

Cisco Meraki also offers Cloud Archive for supported MV models when an organization needs continuous cloud backup for a defined period. Current Cisco documentation lists archive durations including 7, 30, 90, 180 and 365 days for supported cameras and notes that Cloud Archive is licensed per camera. The archive option adds upload-bandwidth considerations and model compatibility checks; it should not be assumed to work identically across every MV product. For example, current documentation specifically states that MV44X and MV84X are not supported for Cloud Archive at this time. A buyer considering wide multi-sensor cameras should therefore separate the requirement for local Smart Retention from the requirement for cloud backup.

Cloud Archive can also have data-location implications because the organization’s Meraki data region influences the archival region. UAE organizations with legal, contractual or internal data-residency requirements should validate the available region and approval path before procurement. Do not assume that “cloud archive” means footage is stored in the UAE. The appropriate compliance decision depends on the organization, industry and chosen Meraki region.

A useful retention specification should therefore state the required number of days, whether the requirement is continuous or motion-oriented, the minimum acceptable playback quality, whether off-camera backup is mandatory, who needs export rights and how long exported incident evidence must be governed separately. That specification produces a much more reliable quotation than asking for “30-day recording” without defining the quality and architecture.

Licensing: separate the camera entitlement from optional analytics and archive requirements

Every Meraki camera requires a valid camera license to operate. The exact commercial model and term should be aligned with the organization’s Meraki licensing mode and procurement policy. Cisco documentation currently lists MV camera licenses and identifies Cloud Archive and MV Sense as add-on options. This means a bill of materials should not treat “video analytics license” as a single universal line item. Some analytics are built into supported camera functionality, while developer-oriented MV Sense capabilities and cloud archive have separate licensing considerations.

Presence analytics is a good example of why the distinction matters. Cisco documentation describes line-crossing and area-occupancy analytics on supported cameras as edge capabilities and notes that these presence features can be used without an additional fee on supported models. MV Sense, by contrast, is intended to expose camera machine-learning outputs through APIs so developers can build custom business solutions. If a customer only needs a dashboard-based people count, the requirements differ from a customer that needs to feed detection events into a building-management application, queue dashboard, workflow engine or data warehouse.

License duration also affects procurement timing and total ownership cost. Buyers should decide whether they prefer a shorter term for budget flexibility or a longer term aligned with the expected hardware lifecycle. Where Cloud Archive is required, each selected camera should be checked for model compatibility, archive duration and associated bandwidth. If only a subset of cameras needs off-camera backup—such as cash handling points, high-value storage or critical entrances—it may be more economical to apply archive only where policy requires it rather than to every camera.

Because Cisco licensing programs can evolve, quotation approval should include the current license SKU, term, quantity and licensing mode rather than relying on an old project template. That is particularly important when expanding an existing Meraki organization where the customer already has camera licenses, different expiration dates or subscription arrangements.

Network and PoE planning for a reliable analytics deployment

A smart camera project is still a network project. Each camera needs stable connectivity to reach Meraki cloud management and support normal remote operations. The physical design therefore has to confirm Ethernet runs, PoE availability, switching capacity, uplink resilience, VLAN policy, firewall reachability and WAN performance. These checks become more important when the same facility is also carrying voice, wireless, application and building-management traffic across shared switching infrastructure.

PoE budgeting should be performed by exact camera model and switch port rather than by counting cameras. Different camera families and accessories can have different power requirements, and an existing switch may have enough free ports while still lacking sufficient remaining PoE budget. Outdoor enclosures, heaters or special accessories can further influence the electrical design. Where a customer plans a large camera expansion, it is often sensible to reserve switch and UPS capacity for growth rather than filling the current power budget to its limit.

WAN planning depends on how the cameras will be used. The edge-storage architecture can reduce the need to send continuous recording streams across the WAN for ordinary local retention, but remote live viewing, clip export, management traffic and cloud archive still consume uplink capacity. Cisco’s current Cloud Archive guidance describes upload requirements that can reach several megabits per second per camera depending on the archive workflow. A site with many archived cameras should therefore be sized using the expected simultaneous upload profile, not the normal low-bandwidth management state.

Resilience requirements should be explicit. During an internet outage, local camera behavior and recording can differ from what remote operators can access. If a security operations center must maintain live visibility during a WAN failure, the project needs a resilient connectivity plan rather than assuming edge storage alone solves remote access. Dual uplinks, suitable Meraki security appliances, redundant switching, UPS capacity and escalation procedures may be appropriate depending on site criticality.

FourTeck can review the camera project together with the wider LAN and security design through Firewall Dubai by FourTeck, helping customers avoid a common deployment problem: excellent cameras connected to an underpowered or poorly segmented network.

Security, privacy and governance need their own workstream

Video contains sensitive operational information even when the analytics layer is only classifying generic objects such as people or vehicles. A secure deployment therefore needs more than encrypted transport. It needs identity governance, least-privilege access, retention policy, export control, incident-handling rules and documented responsibility for camera placement. Meraki’s cloud-managed model can centralize permissions, but the customer still decides who is authorized to view or export footage and how those privileges are reviewed.

One important boundary is identity recognition. Standard MV object-detection analytics should not be described as facial recognition. Detecting that a person is present and identifying who that person is are different technical and privacy functions. Buyers should avoid writing requirements that casually conflate them. If a project has a separate biometric or identity-recognition requirement, it needs its own technology, legal and integration assessment rather than an assumption that ordinary people detection provides identity.

Camera placement also affects privacy. A technically possible view may not be an appropriate view. Offices, employee areas, healthcare environments, accommodation, changing spaces and neighboring properties can create legal or employee-relations concerns. UAE organizations should align camera placement, signage, access, retention and any analytics use with their internal policies and applicable legal advice. FourTeck can design the technical controls, but the customer should define the lawful purpose and organizational policy for surveillance and analytics.

Export governance deserves special attention because an exported clip can leave the normal platform controls. Decide who can create exports, how files are shared, whether incident references are required, where evidence is stored and when it should be deleted. The more useful a camera system becomes for day-to-day investigations, the more important it is to prevent ad-hoc copying from becoming the organization’s default evidence workflow.

Finally, cloud-data location should be reviewed when Cloud Archive is part of the design. Cisco documents archive behavior by Meraki organization data region. If the customer has a contractual requirement for a specific jurisdiction, that requirement should be verified against the current Cisco region options before licensing is purchased.

MV Sense, APIs and MQTT: when analytics must feed another system

The strongest business case for video analytics sometimes sits outside the video interface. A retailer may want store-entry counts in an operations dashboard. A facilities team may want occupancy data sent to a building-management platform. A logistics operation may want a workflow triggered when activity is detected in a defined area. A software team may want historical aggregate information for trend reporting. Meraki supports developer-oriented access to analytics outputs so these types of solutions can be built without treating the video stream itself as the integration payload.

MV Sense is the Meraki capability associated with exposing machine-learning-derived camera data for custom business solutions. Cisco documentation describes API access to analytics information and also documents MQTT-based retrieval of detection outputs. MQTT is useful when an application wants event-oriented data in near real time through a broker architecture. API approaches can be more appropriate for configuration, historical retrieval or application-driven queries. The correct choice depends on the use case, expected event volume, integration security and the system that will consume the data.

The integration should be defined before licenses are purchased. Ask what object or count is required, how quickly the consuming application needs it, whether the application needs camera identifiers and timestamps, how many sites are involved, what happens if the broker or API consumer is unavailable, and whether the customer needs raw event data or summarized metrics. Without these decisions, a project can buy an analytics license and still lack a usable integration design.

Security teams should also decide whether integrations are read-only analytics consumers or whether they will influence physical workflows. An occupancy dashboard is low risk compared with a workflow that triggers access-control actions. Cisco now documents integrations between Meraki Vision and physical-access-control events, but the availability, supported systems and exact feature set should be validated for the customer’s environment. Any automated response should include authentication, authorization, audit logging and failure-mode design.

For custom integrations that involve business applications, data platforms or managed support, FourTeck IT Services UAE can be considered alongside the camera deployment so the project has one documented path from physical event to application outcome.

Practical Dubai and UAE use cases

The same Meraki MV platform can support different operational outcomes, but each use case should be designed separately. The examples below illustrate how buyers can convert a broad “video analytics” requirement into a measurable project statement.

Site survey and camera placement: where analytics projects succeed or fail

Video analytics depends on the quality and geometry of the image entering the model. This makes the site survey more important, not less important, than in a conventional CCTV project. A survey should record the purpose of every proposed camera, the area that must be visible, expected subject distance, mounting height, preferred lens behavior, daytime and nighttime lighting, environmental exposure, network path and any restrictions on drilling, conduit or ceiling access.

For people counting, the survey should trace the actual walking path rather than using architectural drawings alone. Doors may open in ways that create occlusion; queue barriers may change how people cross a line; promotional displays may be installed under the ideal camera position; and high decorative ceilings may put the lens too far from the subjects. A test view can reveal these conditions before the final camera and mount are ordered.

For outdoor analytics, consider heat, dust, moisture, glare, headlights, sun angle and nighttime illumination. A person or vehicle detection feature can only work with the visible scene the camera captures. A low sun directly into the lens or a distant vehicle occupying only a small number of pixels may reduce useful detection and evidence. If the security requirement includes number plates or detailed identification, that should be specified separately; generic vehicle detection does not automatically deliver reliable plate capture.

For wide internal spaces, one camera may provide broad coverage while several focused cameras provide better evidential detail. The most cost-effective design is not always the fewest cameras. A single extremely wide view can reduce hardware count but leave operators with insufficient detail at the edges. Conversely, installing many narrow views increases port count, license count and maintenance overhead. The survey should balance coverage, analytics quality and total lifecycle cost.

A final survey deliverable should therefore identify camera purpose, approximate view, mounting method, cable path, switch location, PoE port, retention requirement and any analytics zone. That document becomes the bridge between the business requirement, installation team and final configuration.

Recommended implementation journey

A staged deployment reduces risk because analytics quality can be validated before a large camera quantity is committed. The journey below is suitable for many Dubai and UAE projects, although critical facilities may require additional design and acceptance steps.

Migrating from an existing CCTV or NVR platform

Replacing a legacy camera system is not merely a camera swap. Existing estates may have analog cameras, ONVIF IP cameras, dedicated NVRs, centralized VMS servers, long-retention storage arrays and established monitoring procedures. Meraki MV introduces a different operating model, so the migration plan should decide which legacy components will remain temporarily, what historical footage must stay accessible and whether monitoring teams need to use both platforms during a transition period.

The first migration question is coverage equivalence. Existing camera positions may have been designed around older lens characteristics or lower resolution. A new smart camera can provide a better image but still need a different angle for analytics. Reusing every existing mounting point can save installation cost while compromising the very capability that justified the migration. Survey critical entrances, cash points, loading areas and counting locations as new analytical scenes, not simply as old camera numbers.

The second question is cabling and power. Existing IP-camera cabling may be reusable if it meets the required standard and test results, but switch capacity and PoE budget should still be checked. Analog estates typically need more substantial cabling and switching change. If the current NVR sits in a server room with a UPS and redundant power, moving storage to cameras changes where resilience is needed. Edge cameras and their access switches now become part of the recording path, so cabinet power and UPS design deserve attention.

The third question is evidence continuity. A customer may need to retain access to legacy recordings for an established period after new cameras go live. The old NVR should not be decommissioned until that retention obligation and export process are understood. Some organizations keep the legacy recorder isolated and read-only until the final historical period expires.

Finally, retrain operators around the new workflow. The value of motion search, object analytics and centralized navigation is lost if guards continue using manual playback habits from the old VMS. A short operational playbook covering live view, historical search, export, escalation and permissions often delivers more value than adding another camera to the bill of materials.

Where Cisco Meraki MV may not be the best fit

A balanced design should identify cases where a different platform deserves comparison. Meraki MV is compelling when cloud-managed operations, simplified edge architecture and built-in analytics align with the customer’s priorities. It may be less suitable when the customer has a hard requirement for an existing third-party VMS architecture, specialized video analytics that are not supported by the MV feature set, a mandatory local recorder design, unusual camera form factors outside the MV portfolio, or data-governance rules that conflict with the required cloud-management or archive model.

Large projects should also evaluate the economics of license terms and any optional cloud archive across the full lifecycle. A lower-cost camera with a traditional recorder may appear cheaper in hardware but require more server, storage and maintenance infrastructure. Conversely, an organization that already owns a mature VMS and storage environment may not realize the same simplification benefit from replacing everything. Compare total operational model, not only unit camera prices.

Specific analytical requirements can be decisive. If the requirement is high-accuracy automatic number-plate recognition, advanced biometric identity, industrial thermal analytics or another specialized computer-vision function, the project should confirm native support or integration feasibility before assuming a general smart-camera platform covers it. People/vehicle detection and presence analytics are useful capabilities, but they should not be marketed as substitutes for every specialist analytical system.

A proof of concept is especially valuable when the business outcome depends on analytics accuracy in a difficult scene. It is better to validate one loading bay, entrance or queue before buying dozens of cameras than to treat the word “AI” as an accuracy guarantee.

Procurement guidance for an accurate Cisco Meraki video analytics quotation

A useful quotation should be structured around views and outcomes. “Twenty cameras for a warehouse” is not enough information to select correct models, mounts, licenses and retention. A better input identifies which views are indoor or outdoor, which require varifocal adjustment, which are intended for people counting, which need wide multi-sensor coverage, and which must preserve footage for a defined period.

Quantity also affects network scope. If the site has an existing PoE switch, provide its model and available port/PoE budget. If the switch is part of the new supply, the quotation should account for the correct port count, power capacity, uplinks and rack/UPS needs. New cabling should include route assumptions and access requirements. Outdoor cameras may require conduit, junction hardware, poles or wall arms that are not obvious from a camera-only list.

For licensing, state whether the organization already has a Meraki Dashboard organization, which licensing model is in use, the desired term and whether the procurement team wants all camera licenses to align with a common renewal period. For Cloud Archive, identify exactly which cameras need it and for how many days. For MV Sense or custom analytics integration, describe the intended consuming application and whether FourTeck is expected to provide integration services or only the camera/API platform.

For compliance, state the required retention period, whether off-camera backup is mandatory, who is allowed to export video and any known data-residency requirements. These inputs influence both technical design and approval. If a customer simply requests “maximum retention,” the project may overbuy storage or archive relative to the actual policy.

Organizations comparing Meraki cameras with broader network or cybersecurity projects can also use FourTeck as a wider infrastructure reference while maintaining the UAE-specific commercial engagement through the local team.

Frequently asked buyer questions

UAE sourcing, installation and ongoing operations

A successful smart-camera project needs local coordination between procurement, installation, network configuration and operational ownership. FourTeck can structure the Dubai/UAE project from initial site survey through camera and license selection, PoE/network review, physical installation, Meraki organization configuration and handover. Where customers already use Meraki switching, wireless or security products, the camera deployment can be planned within the same broader operational environment rather than treated as an isolated CCTV island.

For UAE project coordination and related infrastructure, buyers can review FourTeck UAE. For organizations with regional or international technology estates, FourTeck global provides a broader company reference. These links complement, rather than replace, a solution-specific design discussion.

Availability, lead time and final license SKUs should be confirmed at quotation because camera families and Cisco commercial programs evolve. The purpose of the design is to lock the buyer’s requirements first so current hardware can be selected against them without weakening the security or analytics objective.

Decision recap: six points that should be settled before purchase

What FourTeck needs for a precise quotation

Design the Meraki analytics outcome before ordering the cameras

The right Cisco Meraki video analytics solution is a combination of view geometry, camera family, retention, licensing, PoE/network capacity, operator workflow and governance. FourTeck can turn those requirements into a practical Dubai/UAE bill of materials and deployment plan, including a pilot for analytics-critical scenes where validation is sensible.