Is Your Terminal Ready for a Private Network Survey? A Complete Domain-by-Domain Readiness Guide
A 20-question, six-domain diagnostic — over-water and crane-affected coverage, power and backhaul, TOS and crane integration, maritime security and spectrum, and stakeholder survey logistics — surfaces the gaps that turn a routine RF survey into a wasted quayside visit or a costly mid-deployment respecification
Port and terminal environments carry RF challenges that don’t show up on a generic industrial site survey checklist: over-water propagation from the quayside, large metal vessel hulls acting as dynamic obstructions that arrive and depart on a shipping schedule, crane superstructures blocking coverage, and stacked container fields that change height and position daily. Commissioning an RF survey before that dynamic obstruction picture — along with TOS/crane connectivity specifications and maritime security clearance — is actually captured is one of the more expensive sequencing mistakes a port private network programme can make. TeckNexus has launched a Private Network Site Survey Readiness Checklist for ports, a 20-question diagnostic across six domains that generates a ports-specific checklist, required documents list, and field validation sequence before a formal survey is commissioned.
Site profile: TOS/crane vendor engagement and PFSO sign-off set the baseline
Beyond four standard context questions — terminal type (container, bulk, RoRo/multipurpose, inland, or multi-terminal complex), deployment stage, in-scope use cases, and programme urgency — the checklist asks two questions specific to port risk. Whether TOS and crane OEM connectivity specifications have been confirmed and documented, or whether neither vendor has been engaged at all, matters because the Terminal Operating System is the operational brain of the terminal, and real-time connectivity between TOS, cranes and yard equipment is the highest-priority, most latency-sensitive use case in the deployment — specifications need to be obtained before RF design begins, not negotiated alongside it.
The second baseline question addresses ISPS Code applicability and Port Facility Security Officer engagement directly. Terminals subject to the ISPS Code require PFSO approval before any new communications infrastructure is installed in ISPS-designated areas. Terminals where the ISPS Code applies but the PFSO hasn’t been engaged are flagged as a direct blocker: approval is required before installation, and the PFSO needs to be engaged before survey planning proceeds, not once it’s already underway.
Domain A — Physical environment: where coverage failures actually originate
The physical environment domain is explicit about what makes ports unusual: over-water propagation, large metal vessel hulls, crane superstructures, and stacked container fields that change daily all combine to make capturing the full dynamic obstruction picture essential before survey design, not an afterthought during it. Accurate site maps or CAD drawings, validated against field reality, remain the foundation for RF propagation modelling — surveys proceeding on manual field measurement alone carry materially higher design risk, particularly given how much of a container terminal’s obstruction profile changes week to week as stacks are built and cleared.
RF propagation environment is scored from open through mixed, dense industrial, to extreme — a scale that, at a port, maps onto everything from open quayside to a fully stacked container yard with severe RF shadowing. Dynamic obstructions matter acutely here: moving yard vehicles and large moving machinery like quay cranes and RTGs create coverage variability that static RF surveys routinely underestimate, and terminals with both significant vehicle movement and crane operations happening simultaneously need the most conservative design margin. Known interference sources — dense existing Wi-Fi, industrial machinery, TETRA systems already in use for port operations, and adjacent radar or microwave systems (a category with particular relevance given vessel-borne radar) — round out the domain.
Domain B — Power and backhaul: the most common deployment blocker
Power and backhaul availability at planned radio locations is named as one of the most common deployment blockers, and terminal environments carry this risk across a genuinely large physical footprint — quayside, yard, gate complex, and administrative buildings can each have very different infrastructure ownership and availability. Mains power within 5 metres of all planned locations sits at the strong end of the spectrum; multiple locations with no nearby power source sits at the other, directly determining whether additional civil work is required. Backhaul follows the same logic — fibre or Ethernet within 20 metres of every planned location is the target, but running new cable across a live, operating terminal is very often the longest-lead item in the programme, meaning terminals with significant gaps need wireless backhaul designed in from the start.
Domain C — TOS and crane systems: the most operationally critical domain
TOS and crane system integration is described as the most operationally critical aspect of any terminal private network deployment. Terminal Operating System platforms (Navis, SPARCS, CATOS or equivalent) requiring real-time connectivity to crane and yard equipment, crane control and automation systems (STS crane PLCs, RTG/RMG automation, remote crane cabins), yard vehicle and GSE management, video management systems covering gate OCR and quay/yard surveillance, and gate management and OCR systems each carry specific connectivity and latency requirements that have to be defined before survey design begins.
Device inventory status matters independently of raw count — a documented inventory of device types, quantities and locations changes the design conversation materially compared to an estimated count with no formal record. And SLA requirements — latency, throughput, availability, handover — need to be defined specifically for the most demanding use case, since crane control and yard vehicle coordination carry distinct, often very tight performance requirements that shape the entire RF design.
Domain D — Spectrum and maritime compliance: what shapes vendor selection
Spectrum selection at ports has to account for maritime radio frequency coexistence, vessel-borne radar interference at quayside, and port authority frequency coordination — status ranges from licensed spectrum already secured through CBRS with SAS registration not yet initiated to spectrum options not yet evaluated at all. Maritime security and compliance requirements — the ISPS Code, NIS2 for the maritime sector, IMO Maritime Cyber Risk Management guidelines, IEC 62443 for OT/crane cybersecurity, and customs and border control data requirements like C-TPAT or AEO — directly affect infrastructure access and approval timelines, and need to be confirmed before RF design is finalised.
Domain E — Survey logistics: what actually wastes a quayside visit
Port survey logistics require coordination across port authority, terminal operator, stevedore and security teams simultaneously — a level of stakeholder complexity most industrial sites don’t carry. Quayside access specifically requires vessel schedules to be confirmed and ISPS security clearance to be in place before the survey team can access berth areas at all. The checklist treats every access and security requirement as needing confirmation before the survey team arrives on site, since a technically well-prepared terminal still produces a wasted visit if vessel schedules or ISPS clearance weren’t coordinated in advance.
From readiness diagnosis to field-ready checklist
The output translates all six domains into what a deployment partner needs before mobilising: a ports-specific site survey checklist, required documents list, and field validation sequence — sequenced so that TOS/crane vendor engagement, PFSO approval, dynamic obstruction assessment, and multi-stakeholder access are resolved before the RF survey team is commissioned.
Port authorities, terminal operators and technology teams planning a private network deployment can take the free, vendor-neutral readiness checklist directly and receive a complete readiness report across all six domains.
Related Tool: AI Use Case Prioritiser (Ports & Logistics)
Once site readiness is confirmed, prioritise which port AI use cases — crane automation, gate OCR, yard vehicle coordination — to deploy first based on operational impact and feasibility.
