Typical Starting Point
Metal surfaces, high ceilings, moving equipment and high endpoint density in production and warehouse areas can create Wi-Fi coverage and roaming issues. Backbone capacity may also become insufficient.
Technical Solution Approach
The physical environment, existing cabling, switch infrastructure and wireless client density are analyzed. Fiber backbone and access-switch topology are planned; access point locations, channel plan, roaming and VLAN structures are designed using RF site survey / heatmap data.
Technical Components in Project Scope
- Fiber backbone and rack / patch-panel planning
- Cat6 / Cat6A endpoint cabling
- PoE switch capacity
- RF survey and heatmap
- Corporate / guest / production SSID separation
- VLAN, WPA3/802.1X and roaming
What Is This Architecture Intended to Achieve?
The objective is to create more predictable wireless coverage, controlled network segmentation and a physical network backbone that can support growth across production and warehouse areas.
Related Services and Solutions
Architecture and operating model
Fibre backbone and Wi-Fi access are separate engineering layers. Fibre design considers routes, optical loss budget, transceiver compatibility, cabinet power and redundancy. Wireless measurements include noise, airtime, client capability, channel planning and roaming alongside signal strength. A fast backbone cannot correct poor RF design.
Metal racks, moving stock, forklifts, machinery and high ceilings affect measurements. Survey with actual terminals, operating height and movement routes. AP count cannot be determined by floor area alone. Too many co-channel APs and slow clients can increase airtime consumption. Test RADIUS, certificate and time dependencies for enterprise authentication separately.
A mobile terminal retaining connectivity and completing an application transaction without disruption are different outcomes. Evaluate roaming against both client and infrastructure support. Separate camera, terminal and guest data/management policies, and observe client application behavior during a fiber-path transition.
- 1Fibre path and optical budget
- 2AP and channel design
- 3Terminal route measurement
- 4Transaction acceptance under failure
Design parameters
- Optical and RF budgets
- Calculate fiber loss and wireless airtime separately; one does not resolve the other’s bottleneck.
- Actual route
- Represent terminal height, stocked racks, motion and shift load in route tests.
- Production dependency
- Record PLC, SCADA, HMI, MES, ERP, identity and time dependencies. Booted systems do not prove safe production readiness.
- Zones and communication
- Derive required sources, destinations, protocols and directions from actual production flows. Separate management, user and control traffic.
- Maintenance and safety
- Coordinate scanning, updates and failure tests with production owners. Device support and safety requirements affect sequencing.
- Recovery access
- Back up programs, recipes, configuration, licensing and hardware dependencies separately. Identify technical and operational acceptance owners.
Worked example
Run route tests with ten terminals during a shift with stocked racks. Record connection setup, roaming duration, failed ERP transactions and packet loss for each route. During fiber failover, AP management may remain available while a terminal transaction fails; measure application outcomes separately. Change AP placement or channels one variable at a time and repeat measurements.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Terminal stays connected but transactions fail | Roaming, identity dependencies or backbone transitions may affect the application. | Correlate RF events with ERP outcomes and uplink transitions. |
| IT systems are restored but production cannot start | Recipes, control programs, time or field connectivity may be missing. | Compare the dependency list with actual line-startup procedures. |
| New policy interrupts production traffic | Protocol, direction or device behavior may have been modelled incorrectly. | Validate flows using approved observation data; roll back under production-owner approval. |
| Backup exists but field system cannot recover | Hardware, version, licensing or programming-tool dependencies may exist. | Test program and recipe recovery on representative spare equipment. |
Acceptance checks
- Evaluate coverage using actual terminals, stocked racks and a backbone-failure scenario.
- Exercise the cutover plan with production and safety owners in an approved test.
- Validate required production flows at application and field levels.
- Reject unauthorized IT-to-OT access in a controlled test.
- Record production restart order with owners and durations.
- Test access to backups, programs, recipes and licensing without the main system.
Related concepts
Radio capacity and airtime
Wireless clients share a radio medium; link rate is not useful application throughput. Channel width, interference, client capabilities, slow devices and retransmissions change airtime consumption. Adding access points on the same channel can increase contention. RSSI and SNR measure different things; a strong signal does not prove low interference or sufficient capacity. Validate with intended clients, operating machinery and peak traffic, including roaming and application latency.
Bandwidth and useful throughput
Link capacity differs from useful application throughput. Protocol headers, encryption, retransmissions, small files and storage waits reduce net transfer speed. Keep bits and bytes distinct: 1 Gbit/s corresponds to a theoretical 125 MB/s, not an application performance guarantee. Estimate transfer time as data size divided by measured useful throughput. Observe the network, source reads and destination writes together to locate the bottleneck. Consider temporary slowdowns and competing workloads as well as average speed.
Latency distribution
Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.
IT/OT security zones
A zone groups assets with similar operational and security requirements; communications between zones should traverse controlled conduits. An accessible OT device is not necessarily safe to scan or update. Control latency, safety, vendor support and maintenance windows influence decisions. Observe actual PLC and SCADA flows rather than copying IT policies unchanged. Define identity, duration, approval and logging requirements for remote support, and coordinate active tests and cutovers with production owners.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, rather than only a list of equipment. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Primary documentation
How This Scenario Was Prepared
Doz Teknoloji Technical Team
This illustrative technical scenario is based on evaluation criteria used by Doz Teknoloji when planning enterprise IT and infrastructure projects.
About Doz TeknolojiTechnical Criteria + Primary Sources
Wired and wireless access, industrial Wi-Fi, fiber backbone and hierarchical network design were reviewed against current Cisco manufacturing and campus design guidance.
Improve Decision Quality
To frame factory Wi-Fi and fiber decisions around scalability and operational resilience, not only coverage or port counts.
Content and primary sources were reviewed again.
Related Next Steps
Continue with the relevant technical guide, product/licensing page or project scenario.
Related Enterprise Solutions
Explore the related service and solution pages to plan implementation.
Would You Like to Evaluate a Similar Infrastructure?
Share your current infrastructure, critical systems and project objectives so we can define an appropriate technical scope after a requirements assessment.