ANPR & Barrier Gate Network Design: PoE, VLAN and IP Planning

Quick answer: an ANPR lane is a small IT installation. Every vehicle entrance has one or two LPR cameras, a lane controller, the barrier operator's own electronics, a loop detector, a payment or intercom terminal and a guard-post workstation — and every one of those devices depends on cabling, power and addressing that are decided before the concrete is poured. Fix the device list per lane, the PoE budget per switch, the IP and VLAN plan, the cable routes and the offline behaviour first; then choose the hardware.

When an ANPR lane underperforms, the camera is usually blamed first. In practice the fault is more often found further down the stack: a PoE switch running at its limit that power-cycles the camera at the busiest hour, a run of cable routed alongside a motor supply, a camera still holding a lease that changed after a switch reboot, or an uplink sized for plate events that is suddenly carrying full video streams.

This guide is written for the people who have to make a car park or industrial entrance actually work: integrators, parking operators, facility managers and the IT or security team who inherit the system afterwards. It covers the decisions that belong to the network and power layer, not the plate-recognition algorithm. The interface between camera and barrier — relays, RS-485, TCP/IP, MQTT and API calls — is covered in our LPR and barrier gate integration guide, and the lane-by-lane equipment counts in our multi-lane ANPR access control guide. This article picks up where those end.

Why the network layer decides whether the lane works

A barrier gate triggered by a remote control or a loop detector works with no network at all. The moment the lane is expected to recognise a plate, check a whitelist, charge a tariff or log an event, availability stops being a mechanical question and becomes an infrastructure question. Three consequences follow, and each one shows up somewhere different in the project:

• Downtime at the lane is a network problem more often than a hardware failure. If the switch feeding the entry camera shares a cabinet and an earth with the gate motor supply, one surge event can take out the camera, the controller and the intercom together.
• Reinstatement is expensive. Replacing a camera is an hour's work. Opening a trench again because the duct was full, or because the run should have been fibre rather than copper, is a project.
• Commissioning stalls without documentation. An integrator who cannot hand over an IP map, a VLAN table and a PoE budget leaves the operator with a system nobody can extend or repair.

None of this calls for a data-centre design. A single-lane entrance needs a compact, well-documented, robustly powered edge — and the discipline to specify it before the gate is ordered.

Step 1: inventory every device in the lane

Before choosing a switch, write down what has to be connected and powered at each lane. The table below is the working list from a typical single-lane entrance with paid parking. Adjust it for your site; the point is that the counts, not the brand names, drive the switch, the uplink and the cabinet size.

Device in the lane	Network interface	How it is powered	What it needs from the design
LPR / ANPR camera (one per direction)	Ethernet, with PoE on PoE-capable models	PoE from the lane switch, or a local supply	A port of the right PoE class, a short cable run, a reserved IP, a reachable time source
Lane controller / access controller	Ethernet, plus dry contacts or RS-485 to the gate	Local 12 V or 24 V supply in the cabinet	Fixed IP, UPS-backed power, documented relay map
Barrier gate operator electronics	None by default — it is triggered by volt-free contacts	The gate's own internal supply (our barrier range uses an AC 24 V supply inside the cabinet)	Trigger pair from the controller, safety device inputs, surge protection
Loop detector or radar sensor	Wired to the controller, often with no Ethernet	From the controller or a local supply	Screened cable in its own duct, loop tails terminated in the cabinet
Face recognition or card terminal	Ethernet, Wiegand or RS-485	Typically 12 V DC; a 15 W class device	A short run, a weatherproof entry, the credential list or server reachable
Payment kiosk or autopay unit	Ethernet, sometimes mobile data as a fallback	Local supply, UPS preferred	A segregated segment, card-data scope kept small, a dedicated uplink
Intercom or help point	Ethernet with PoE on many models	PoE or a local supply	Voice traffic prioritised, cable to the guard post
Guard-post workstation	Ethernet (a typical engineering PC has two Gigabit ports)	Mains supply; the unit ships with an AC 110–220 V adapter	A desk position, a monitor, a UPS, physical access control to the room

Two notes on the equipment a factory supplies, because they change the network plan. First, a 5-megapixel AI LPR camera that recognises the plate on board and forwards events and snapshots to a cloud platform needs a fraction of the bandwidth of a camera that streams continuous video to a server — and with a cloud platform there is no local server to rack, power and patch. Second, a guard-post engineering PC (Linux, dual Gigabit LAN, RS-232/485 serial ports, rated from −20 °C to 60 °C) is the on-site machine for a site that prefers local software over cloud. Deciding cloud or local before you design the cabinet is what keeps the lane cabinet small.

Step 2: calculate the PoE budget before choosing the switch

This is the most common design error in parking lanes: the switch is chosen by port count, and the total power budget is read as an afterthought. A PoE budget is shared across all ports, not granted per port.

• IEEE 802.3af (PoE) provides up to 15.4 W at the port and 12.95 W at the device.
• IEEE 802.3at (PoE+) provides up to 30 W at the port and about 25.5 W at the device.
• A 24-port PoE+ switch with a 370 W budget cannot feed 24 devices at 30 W each; the arithmetic stops long before the port count does.

Add up the real draw of every PoE device in the lane, then add 20–30 percent headroom for a camera heater on a cold morning, for a PTZ or 4K unit, and for the device you will add in year two. An undersized PoE budget does not fail loudly: the switch throttles power, cameras reboot at unpredictable intervals, and the ticket reads "intermittent fault" for months. Two further points decide whether the switch survives in the field.

• Where the switch lives. A lane cabinet is hot, humid and dusty in summer and cold in winter. Use an industrial switch with a wide temperature rating and DIN-rail mounting for lane cabinets, and keep the managed switch in the equipment room, where it can also do VLANs, monitoring and per-port PoE reporting.
• Surge protection. Outdoor runs, long cable reaches and a cabinet shared with motor-driven equipment make surge protection on the network port a design item, not an accessory.

Step 3: an IP addressing and VLAN plan you can hand over

Give every lane device a planned address, and keep the parking operation off the office network. The plan does not have to be complex; it has to be written down.

• Separate VLANs. One VLAN for parking operational technology (cameras, controllers, kiosks, intercoms), one for the building or office IT, and — where card payments are in scope — a separate segment for payment devices, so the card-data environment stays small and auditable.
• Static addresses or reservations. Cameras, controllers and gateway devices should not depend on a lease that a switch reboot can reassign. The one device allowed to take a dynamic address is the technician's laptop during commissioning.
• An example scheme, from a site with a two-lane entrance. The lane VLAN sits on 192.168.50.0/24: cameras at .21–.29, lane controllers at .31–.39, kiosks at .41–.49, the industrial edge switch at .2 and the gateway at .254. Whatever scheme you pick, the rule is one line per device, with its physical location and switch port beside it.
• Time, DNS and the platform. Cameras and controllers need a reachable time source and a working DNS resolver, or event timestamps drift and dispute handling becomes guesswork.

Step 4: cabling — the part that cannot be redone cheaply

Two facts decide most cabling decisions. First, a copper Ethernet channel is specified to 100 m — and in a car park the practical limit is shorter, because PoE voltage drops over distance and the longest runs are usually the ones routed past noisy equipment. Keep most camera runs under roughly 60–70 m and place the edge switch so that this is achievable.

Second, cable is part of the measurement chain, both for the loop detector and for the camera. Run data cable in its own duct, separated from mains and motor supply cable, use screened cable where it must cross power circuits, and use outdoor-rated cable and glands at the cabinet entry. For multi-storey structures and remote lanes, fibre is the correct backbone: it ignores the 100 m copper limit and it is immune to the electrical noise that lifts, motors and lighting inject into a garage. Whichever medium you use:

• Label both ends of every cable with the lane, the device and the switch port.
• Leave a service loop at the camera and in the cabinet — future adjustment is the norm, not the exception.
• Record loop-tail and duct routes on the as-built drawing, including the depth of buried loops, so the next contractor knows where not to dig.

Step 5: uplink and bandwidth sizing

Bandwidth planning in a parking lane comes down to one question: does video leave the camera, or does only the result? The two architectures have very different appetites.

• Recognition at the edge (plate events only). The camera recognises the plate and sends an event, a snapshot and a small record. Per-lane demand stays low and the lane keeps working over a modest uplink — a 4G router is a workable fallback for a remote site. This is the architecture our 5-megapixel AI LPR camera is built around: the camera performs the recognition and the cloud platform holds the records, so no local server is required.
• Streaming video to a server or VMS. Typical figures are in the region of 4–8 Mbps per 1080p stream with H.264, with H.265 roughly halving that at equivalent quality, and 4K or multi-sensor units going considerably higher. Multiply by the cameras per floor, add client and management traffic, and size the uplink for peak rather than average.

Two rules apply to both architectures. Plan for roughly twice the measured peak on the camera segment, and never let the parking VLAN and the office network share a saturated uplink that carries general internet traffic. If you also record video, storage follows from bandwidth: bitrate × hours × retention days, plus a margin for motion peaks. Work that out before buying disks, not afterwards.

Step 6: decide what happens when the link drops

Every parking system loses its uplink eventually: a fibre is cut, a switch dies, a cloud service is unreachable for an hour. The design question is not whether it happens but what the lane does when it does.

• Keep a local decision list. Season-ticket, tenant and staff plates can be held on the camera or in the controller as an offline list, so the barrier still opens for the people who use the lane every day.
• Buffer the events. The camera or controller should queue events and snapshots locally and forward them when the link returns; if it does not, revenue and dispute evidence are lost silently.
• Agree the failure mode at the arm. Keeping the arm available for local triggers keeps traffic moving; failure at the arm on power loss is a separate decision from a network outage, and both are covered in our barrier gate battery backup guide.
• Write the fallback procedure. Who is called, how the lane is switched to manual release, and how the queue is managed until the link returns.

Step 7: power design for the lane cabinet

Network and power decisions are made at the same moment, in the same cabinet, and one mistake in the earthing can undo both. The essentials:

• Separate circuits. Give the lane equipment its own circuit instead of sharing a socket with the workshop or the gate motor starter, and protect it with the correct breaker and residual-current device for the local wiring rules.
• UPS on the IT layer, battery on the gate. A small UPS keeps the switch, the camera and the controller alive through a short outage, which preserves recognition and logging. If the gate itself must keep cycling during an outage, that is a battery-backed or solar barrier decision rather than a UPS one.
• Surge protection and earthing. External runs, overhead arms, intercom posts and loop cables all attract transients. Bond the cabinet earth properly, protect the network port and the mains input, and keep signal earth and power earth working as one system under the local regulations.
• Size the supply to the devices you listed. Our barrier series draws from an AC 24 V supply inside the cabinet with a 100–200 W class motor; a face recognition terminal is a 12 V DC, 15 W class device; the guard-post engineering PC uses an external AC 110–220 V adapter. Those numbers, multiplied by the lane count, tell you what the circuit and the cabinet have to support — before anyone orders equipment.

Step 8: security and data hygiene on a camera network

Access control and ANPR networks are attractive targets and they also process personal data, so a few habits belong in the specification from the start.

• Change every default password and administrator account on cameras, controllers, switches and the platform before handover, and keep a credentials inventory with a rotation date.
• Do not expose cameras to the internet by port forwarding. Remote maintenance goes over a VPN, with named accounts that are disabled when the job ends.
• Update firmware on a planned cycle, with a staged rollout so that a bad update stops at one lane instead of every entrance.
• Keep the parking VLAN off guest Wi-Fi and off the tenant network, and give the platform only the ports it needs.
• Treat plate data as personal data: define a retention period, restrict exports to the people who need them, and post signage telling drivers that plate recognition is in use. Follow the data-protection rules that apply in your market.

Step 9: commissioning tests for the IT layer

Commissioning is where a network design is proved. Run these tests with the integrator present and record the results in the handover pack.

• Ping or trace every device on the lane plan and confirm that nothing answers on the wrong VLAN.
• Read the switch's PoE consumption per port, compare it with the worksheet, and confirm the switch still has headroom with every port active.
• Read plates in daylight and at night, with headlights on, from a stopped and a moving vehicle, and check the event, the snapshot and the timestamp that reach the platform.
• Measure the event round-trip from plate read to barrier opening command and confirm it matches the lane's design expectation.
• Unplug the uplink and verify the offline behaviour: the local decision list, the buffering, and the lane's declared failure mode at the arm.
• Check time synchronisation against the platform, then restart the switch and the controller and confirm the lane returns without a site visit.
• Leave the system under normal traffic for 48–72 hours and review the logs before accepting the lane.

The handover pack should contain the IP map with physical locations and switch ports, the VLAN table, the PoE budget worksheet, credentials and their rotation schedule, the relay and trigger map between controller and gate, and the as-built cable route. Without those documents, the next change to the lane starts from zero.

What to send a supplier for a factory-direct quotation

Barrier gates, LPR cameras and access control terminals are usually bought together for a project, so a supplier that understands the IT layer can save the integrator a redesign. Send the following with the enquiry:

• A device schedule per lane: cameras, controllers, terminals, kiosks, intercoms and switches, with quantities.
• Distances from each lane to the nearest equipment room, and whether fibre is available.
• Available power at each cabinet, and whether a UPS or battery backup is required.
• Your IT rules: VLAN scheme, static or reserved addressing, and the approved remote-access method.
• The required offline behaviour: local list, buffering, and the failure mode at the arm.
• Climate and environment at the lane — coastal, tropical, alpine or covered basement — because it changes the IP rating and temperature class you should be quoted.
• Site drawings, cabinet positions and the lane numbering you will use in the documentation.

With those inputs, a factory can return a bill of materials that matches the lane instead of a product list that has to be reconciled on site. Our LPR camera series, access control terminals and barrier ranges are specified for exactly this kind of mixed lane, and the detection side is covered in the vehicle loop detector guide.

Conclusion: design the network with the lane, not after it

An ANPR entrance is a mechanical system with an IT system wrapped around it. The mechanical half — arm length, spring balance, motor type, safety devices — has mature buying guides; start with the parking lot access control guide if you are still choosing hardware. The IT half is where projects quietly fail: an undersized PoE budget, a trench without duct, an address plan nobody wrote down, and an offline behaviour nobody agreed.

Get the five decisions right — device list, PoE budget, addressing and VLANs, cable routes, offline behaviour — and the lane will keep working through the failures that are normal in a car park. If you would like the barrier gates, LPR cameras, terminals and lane hardware specified as one package, send the lane plan to our engineers with the checklist above and ask for a lane bill of materials.

FAQ

How much PoE power does a typical ANPR lane need?

A single-lane entrance usually carries one or two PoE cameras, an intercom or terminal and a lane controller that is powered locally. Cameras are typically in the 5 to 25 W range depending on resolution and whether a heater is fitted, so a small PoE+ switch is usually enough — but the switch's total PoE budget, not the port count, is the number to check.

Can an LPR camera and a barrier gate share one network switch?

Yes. The gate itself is not a network device: it is triggered through volt-free contacts or RS-485 from the lane controller. Keep camera and controller on the parking VLAN, feed the switch from its own circuit, and protect the network port against the surges that motor loads can introduce.

Static IP addresses or DHCP for parking cameras and controllers?

Fixed addresses or DHCP reservations. A lease that changes after a switch restart breaks integrations silently. Leave dynamic addressing to the technician's laptop during commissioning.

Cat5e or fibre for a multi-storey car park?

Copper is fine for runs up to 100 m, but keep camera runs under roughly 60 to 70 m because PoE voltage drops over distance and long runs pick up noise from motors and lighting. Use fibre for the backbone between floors and equipment rooms, where copper distance and interference become the limiting factors.

What should the lane do when the network goes down?

Open for the plates on a local offline list, buffer events and snapshots for forwarding when the link returns, and follow the failure mode agreed for the arm — with a written fallback procedure and a named contact for the operator.

Does a cloud LPR platform need a local server?

Not necessarily. A camera that recognises plates on board and forwards events to a cloud platform works without a local server, which removes a machine to power, patch and cool. A local engineering PC is only needed by sites that prefer on-premise software.