LCB ONE — Unified Truck Queue & Gate Orchestration Platform

Executive summary

Laem Chabang Port's truck congestion is a system-design problem, not an adoption problem. The Port Authority (ทลฉ) is already mid-rollout of a mandate for 100% electronic Truck Queue booking, with MOU milestones from its own planning slides running through October 2025. That mandate standardizes who books electronically. It does not fix how the booking system allocates time — and today's allocation logic is a primary driver of the jam.

This proposal, LCB ONE, is a shared booking, pricing, and visibility layer that sits above every terminal's existing system — using the same API pattern one terminal (B4, operated by TIPS Co., Ltd.) already exposes as the integration contract, so no terminal has to rip out what it runs today. It replaces flat, 60-minute, capacity-blind slots with a dynamic engine, activates the payment/penalty step the port's own process diagram already labels "Next Phase," and gives the Port Authority a single, national view of queue health it does not currently have.

Current-state assessment

Three source materials informed this assessment: the Port Authority's own Truck Queue stakeholder and rollout slides, the B4 terminal's public API documentation (v1.1, operated by TIPS Co., Ltd.), and operation and swimlane diagrams for the shipper/LSP trade-document platform describing the freight-forwarder-facing trade-document and booking flow. Real terminal operator names and the basin layout below were independently verified against public port and operator sources.

2.1 Stakeholders

The port's own materials identify seven stakeholder groups split into two roles. Users of the queue: cargo owners (เจ้าของสินค้า), importers/exporters (ผู้นำเข้า-ส่งออก), shipping lines (สายเรือ), and trucking operators (ผู้ประกอบการขนส่ง). Providers of the queue: customs (ศุลกากร), terminal operators (ผู้ประกอบการท่าเทียบเรือ), and the Port Authority itself (ทลฉ). A related but distinct group is the industry associations — including the Bangkok Shipowners and Agents Association (BSAA), the Federation of Thai Industries, the Thai Chamber of Commerce, and the Thai National Shippers' Council (TNSC) — who sit at the MOU table as advocates, not as terminal operators.

2.2 The real terminal landscape

Laem Chabang has two harbour basins. Basin 1 (14 m depth, north) holds eleven terminals including seven container berths; Basin 2 (16 m depth, dredged deeper to serve larger mainline vessels, immediately south of Basin 1) holds seven terminals. A Phase 3 expansion (E0–E2, F1–F2) is planned but not yet operational.

2.3 Three systems, hand-stitched

2.4 The rollout mandate

The Port Authority's planning slides show a staged rollout toward 100% electronic queuing: IT-department and operator meetings (completed, Mar–Apr 2025), stakeholder meetings with BSAA, the Thai Chamber of Commerce, and TNSC (planned May 2025), MOU drafting (Jun–Jul 2025), MOU approval (Aug 2025), MOU signing (Sep 2025), and full 100% launch (Oct 2025).

Root-cause analysis

Six mechanisms, each traceable to a specific gap in the current design, combine to produce road-level congestion even when trucks are individually "doing the right thing" by booking a slot:

1. Flat, hourly quota with no intra-hour smoothing.
2. No live payment or penalty.
3. Terminal silos.
4. Slow, manual document chain upstream.
5. No virtual holding.
6. No driver feedback loop.
7. Import likely bypasses slot booking entirely.

Proposed solution — LCB ONE

LCB ONE is positioned as the layer the mandate needs, not a replacement for it. Every terminal keeps its own yard and gate operations; LCB ONE becomes the shared appointment, pricing, and visibility layer that all of them — and every booking channel — read and write through.

Scope note: every component below applies to import and export equally, not export alone. The dynamic slot engine allocates one shared pool of gate/yard capacity across both directions; the reservation ledger, payment step, and reliability score work identically regardless of which way the container is moving. Section §6 gives the mirrored import endpoint alongside the existing export one.

4.1 Booking & payment policy

Confirmed with stakeholders: the LSP (or shipper acting directly) is always the party that reserves the queue slot and prepays the port fee, matching the existing trade-document and payment flow exactly — this is not a new process, just the first time it will be enforced consistently in software. The LSP already knows which truck will execute the trip (coordinated with its trucking subcontractor beforehand) and submits the plate together with the reservation, matching the truck_license field the terminal API already requires at reserve time.

The trucking company's role in LCB ONE is therefore execution, not booking: confirming which named driver operates the already-reserved plate (mirroring the driver-name and phone-for-SMS fields already present in the port's own current booking manual), and receiving the virtual-queue "leave now" notification. A trucking company never sees a payment step in this design.

Same policy, both directions. For export, the "LSP" is the freight forwarder handling the shipper's outbound booking. For import, the equivalent role is the consignee's customs broker / LSP: they clear customs, receive the Delivery Order (D/O) from the shipping line, and are the ones who reserve and pay for the import queue slot — the trucking company's role is identical either way, confirming a driver against an already-paid reservation. The eligibility trigger just differs: export unlocks on shipping instruction / VGM (§6.4); import unlocks once customs release / D/O is confirmed (§6.4).

System architecture

Per your direction, LCB ONE is designed as a complete, independent platform — its own data model and API come first; any one terminal's existing system (TIPS-style or otherwise) is just one adapter target among several, not the shape the whole platform is built around. Four layers:

• Channels — the Truck Q driver app (mobile-first), an LSP/customs-broker reservation portal (standalone, with an optional embed into the LSP's own trade-document platform), a Port Authority control tower, and a terminal operations console.
• LCB ONE core services — dynamic slot engine, reservation ledger (§5.2), payment & penalty, reliability scoring, notification hub, control-tower analytics. Event-driven microservices behind LCB ONE's own OAuth2 gateway.
• External integrations — bank/PromptPay for payment; a direct feed from e-Customs / Thailand's National Single Window for import release status, so import eligibility (§6.4) rests on the authoritative customs record rather than a downstream copy of it; LINE Official Account for driver notification.
• Terminal layer — one adapter per operator with an existing system (B4/TIPS, B2/Evergreen, C1–C2/Hutchison, B5 & C3/LCIT, B3/ESCO, B1 & D1–D3/LCB Container Terminal 1), translating LCB ONE's canonical reservation events into each one's native calls; for a terminal with no system of its own, LCB ONE's gate console (§6) is the terminal system — no adapter needed.

Under load, slot capacity is decremented through short-lived distributed locks (e.g. Redis) to prevent the double-booking race conditions that a flat-file or single-database-row counter would allow during burst traffic; reservation and gate events flow through a message queue (Kafka/RabbitMQ) so terminal adapters, notifications, and analytics can each consume independently without blocking the booking path itself.

5.1 Canonical data model

Five entities cover both directions — there is no separate import/export schema, only a direction field and a different eligibility trigger (§6.4):

5.2 Reservation lifecycle

One state machine, both directions — only the transition into ELIGIBLE differs (§6.4):

DRAFT → ELIGIBLE → RESERVED → PAID → DRIVER_CONFIRMED → EN_ROUTE → AT_GATE → COMPLETED
                                                                            ↘ NO_SHOW
   (any state before AT_GATE) → CANCELLED

  DRAFT              container known, not yet eligible to book
  ELIGIBLE           export: SI+VGM confirmed, or full B/L
                      import: customs released + D/O issued  (§6.4)
  RESERVED           LSP/broker picked a slot — hold_expires_at set
  PAID               payment webhook confirmed (§6.3)
  DRIVER_CONFIRMED   trucking company attached driver name + phone
  EN_ROUTE           virtual-queue "leave now" sent, GPS tracking active
  AT_GATE            GateEvent(check_in) received
  COMPLETED          GateEvent(check_out) received
  NO_SHOW            window closed with no check_in — reliability_score impact

5.3 Live location & fleet tracking

This is the mechanism behind the driver app's "leave now" alert and the control tower's live fleet map — it only runs while it needs to, and only while the driver has agreed to it.

• Tracking window, not always-on. The driver app only sends LocationPings while a reservation is EN_ROUTE (§5.2) — from the moment the driver acknowledges the job until AT_GATE. No tracking before that, none after. This is a deliberate privacy and battery boundary, not just an engineering shortcut — and it's the honest answer if a driver or union asks "is this app watching me all day."
• Ping interval: 30–60 seconds, adaptive — closer to 30s inside the last 5 km of a route (where timing precision matters most for the gate handoff), backing off toward 60s further out to save battery and data. Each ping is small (lat, lon, speed, heading, timestamp) — cheap even on a 3G rural connection.
• ETA engine. A background service consumes each LocationPing, compares it against the known route to the reserved terminal, and recomputes ETA. That single number drives three screens at once: the driver's own "leave now / hold / running behind" banner, the Port Authority control tower's live fleet map and table (mockup, PAT view), and the destination terminal's "Incoming trucks" panel (mockup, Terminal view) — one calculation, three audiences, so nobody is working from a stale or different number.
• Anomaly detection, two kinds. Stalled: no meaningful position change for >10 minutes while still EN_ROUTE — flags the reservation and raises a control-tower alert (this is exactly the "Truck 91-8823" example in the mockup). Off-route: the ping falls outside a buffered corridor around the expected road route — flags for review rather than auto-acting, since a real detour is common and legitimate.
• Closing the loop: contact, not just visibility. A flagged truck isn't just a dot on a map — the control tower and terminal console can act on it directly through the same reservation record: a mock/real phone connect, or a push/SMS/LINE alert using a short set of pre-approved message templates (the mockup's "Contact driver" panel). Templates, not free text, so the message reaching a driver mid-route stays short and unambiguous.
• Offline gaps are expected, not exceptional. Rural stretches and industrial areas around the port have real dead zones. The driver app queues pings locally and flushes them when connectivity returns rather than failing silently; the control tower shows a "last known position, N minutes ago" state instead of guessing — an honest gap reads very differently from a false "on time."

LCB ONE canonical API

This is LCB ONE's own contract — designed from the data model in §5.1, not derived from any single terminal's existing endpoints. One resource shape serves both directions; the direction field picks which document set gates eligibility (§6.4).

6.1 Capacity

GET /v1/capacity/{terminal_code}?date=2026-09-18&granularity=15
> 96 fifteen-minute slots per direction, one shared capacity
> pool split by the dynamic slot engine (formula in §6.5).

{
  "terminal_code": "B4",
  "date": "2026-09-18",
  "slot_minutes": 15,
  "slots": [
    { "start": "08:00", "export_qty": 14, "export_reserved": 9,
      "import_qty": 8,  "import_reserved": 5, "capacity_basis": "yard_occupancy" },
    { "start": "08:15", "export_qty": 16, "export_reserved": 6,
      "import_qty": 9,  "import_reserved": 3, "capacity_basis": "yard_occupancy" }
  ]
}

6.2 Reservations

POST /v1/reservations
{
  "direction": "export",
  "terminal_code": "B4",
  "containers": [
    { "container_no": "TCLU3963656", "iso_type": "22G1",
      "vessel_name": "ONE HAMBURG", "voyage": "123E" }
  ],
  "truck_license": "79-6041",
  "window_date": "2026-09-18",
  "window_start": "08:15",
  "carrier_id": "CARR-0042"
}
> 201 { "reservation_id": "R-20260918-0041", "status": "RESERVED",
>       "payment_required": true, "hold_expires_at": "2026-09-18T08:05:00+07:00" }

POST /v1/reservations   (import — same endpoint, different fields)
{
  "direction": "import",
  "terminal_code": "B4",
  "containers": [
    { "container_no": "MSKU4471203", "ticket_number": "TCK-20260918-0042",
      "bl_shore_number": "SHORE-88192", "do_number": "DO-2026-7718" }
  ],
  "truck_license": "82-4417",
  "window_date": "2026-09-18",
  "window_start": "09:30",
  "carrier_id": "CARR-0091"
}

POST /v1/reservations/{id}/driver        driver_name, phone → DRIVER_CONFIRMED
POST /v1/reservations/{id}/cancel        → CANCELLED
GET  /v1/reservations/{id}               current status, full lifecycle history (§5.2)

6.2b Slot auto-assignment logic

The system uses a hybrid model, not a pure first-available rule. The reservation is for the gate check-in window, not the terminal yard arrival time. When the LSP submits a booking, the platform evaluates every feasible 15-minute gate window, filters out windows that violate constraints, scores the remaining windows by capacity slack, balancing effect, vehicle conflict risk, and fairness, and assigns the highest-scoring candidate. The final assigned window is stored on the reservation and shown back to the user as the active gate slot. If the LSP prefers a different choice, the user may override the suggestion from the filtered shortlist, but the system still validates the final slot against live capacity and conflict rules.

candidate_windows = feasible_slots(capacity_snapshot, terminal_rules, vehicle_conflicts)
filtered = [w for w in candidate_windows if is_valid(w)]
scored = [score_window(w, capacity_slack, balance_score, fairness_score, vehicle_conflict_risk) for w in filtered]
assigned_window = max(scored, key=lambda w: w.score)

// Important: the reservation's window is the gate check-in window.
// Users should plan travel to reach the gate inside the assigned window;
// arrivals that are early should hold outside the terminal unless the terminal permits otherwise.

Example reason shown to user:
"Recommended gate window: 14:15–14:30 because it has the highest capacity slack,
avoids a vehicle conflict, and improves overall demand balancing across the terminal."

This policy intentionally avoids the failure mode of simple earliest-slot assignment: a system that selects the first open window will repeatedly cluster trucks at the start of the day, even though the real objective is to smooth the approach road and gate flow. The UI therefore shows both the assigned or recommended slot and a short reason, so LSPs understand why a particular window was chosen and can still override when operationally necessary.

6.3 Payment and gate events

POST /v1/webhooks/payment          from the bank/PromptPay gateway → PAID
POST /v1/gate-events                from Main Gate Check-in (or a terminal adapter)
{ "reservation_id": "R-20260918-0041", "event_type": "check_in", "lane": 1 }
> check_in → AT_GATE, check_out → COMPLETED, window-close-with-no-check_in → NO_SHOW

GET  /v1/reliability/{carrier_id}   score, tier, 8-week history — same score, both directions

6.4 Eligibility & the customs integration

POST /v1/reservations only succeeds once the container reaches ELIGIBLE (§5.2). Export checks this against the trade-document platform's shipping-instruction/VGM or B/L status, as designed in §4. Import is the part this proposal designs independently: rather than trusting a do_number string alone, LCB ONE should hold a direct feed from Thailand's e-Customs / National Single Window release status as the authoritative source — the do_number field above should resolve against that feed, not sit as an unverified string. Where that integration isn't available yet, the fallback is the shipping line's own D/O record via the existing trade-document platform, flagged lower-trust until the direct feed is live (see Risks, §9).

6.5 Dynamic capacity formula

The number a capacity slot actually returns, made concrete rather than left as a black box:

slot_capacity = min(
  gate_lanes_open × trucks_per_lane_per_15min,
  yard_free_teu / avg_teu_per_truck,
  crane_moves_per_hour × 0.25 × teu_per_move
) − safety_buffer

Example, B4 at 14:00 on a normal day:
  gate_lanes_open=3, trucks_per_lane_per_15min=6        → 18
  yard_free_teu=340, avg_teu_per_truck=1.6               → 212
  crane_moves_per_hour=88, teu_per_move=1.4, ×0.25       → 31
  slot_capacity = min(18, 212, 31) − 2 (safety_buffer)   = 16

> The binding constraint here is gate lanes, not yard space —
> which is exactly the kind of signal a flat hourly number
> can't express, and exactly what the control tower (§4) uses
> to recommend opening a 4th lane instead of just rejecting demand.

6.6 Terminal adapter example — B4 (TIPS)

For a terminal that already runs its own booking backend, the adapter is the only piece that speaks that terminal's native shape — everything upstream of it (channels, core services, reservation lifecycle) stays canonical. B4's adapter, for instance, translates POST /v1/reservations into its existing POST /exp_truck_q/reserve call:

LCB ONE canonical                    B4 (TIPS) native, via adapter
─────────────────────────────────    ─────────────────────────────
direction: "export"                  (implicit — exp_truck_q only)
containers[0].container_no      →    container1
containers[0].iso_type          →    iso1
truck_license                   →    truck_license
window_date, window_start       →    reserve_date, reserve_slot   (hour-rounded)
                                      export_queue_no  ←  returned, stored on
                                                            the canonical Reservation

> A terminal with no existing system skips this table entirely —
> its staff just use the Terminal Operator Console (mockup) directly
> against the canonical API, with no native call to translate to.

6.7 Live location & driver messaging

Two lightweight endpoints implement §5.3: a high-frequency write for the driver app, and a low-frequency, template-only write for the control tower and terminal console to push a message back.

POST /v1/reservations/{id}/location      (driver app → LCB ONE, every 30–60s, EN_ROUTE only)
{ "lat": 13.0827, "lon": 100.8833, "speed_kmh": 62, "heading": 134, "recorded_at": "2026-09-18T13:52:10+07:00" }
> Rejected once status leaves EN_ROUTE — closes the tracking
> window automatically, no client-side trust required.
> Response includes the recomputed eta_minutes and status:
> "on_time" | "at_risk" | "stalled" | "off_route" — the same
> field the driver banner, PAT map, and terminal panel all read.

POST /v1/reservations/{id}/message       (control tower / terminal console → driver, on demand)
{ "template_id": "TPL-LANE-CHANGE", "channel": "line" }
> Body is a template_id, not free text — keeps in-cab messages
> short. channel falls back push → SMS → LINE by driver preference.

GET  /v1/fleet?terminal_code=B4&window=en_route   (control tower / terminal console)
> Backs the mockup's "Live truck tracking" / "Incoming trucks"
> tables and the map dots — one read, every connected screen.

Roadmap & milestones

7.1 AI & intelligence layer

Every rule-based component in Phases 1–4 above is designed to work correctly on day one with zero historical data. The eight capabilities below are the intelligence upgrade path once each phase has been live long enough to accumulate real data — deliberately sequenced this way rather than promising AI from launch, which would either be false or would silently fall back to the same rules anyway.

Stakeholder business case

Port Authority (ทลฉ)

Completes the electronic-queue mandate with a system engineered to reduce congestion rather than just digitize the existing paper process. Delivers the single national view of queue health that no current system provides, plus levers to rebalance capacity proactively instead of reacting after a jam has formed on the road.

Terminal operators

No forced migration — LCB ONE adapts to the TIPS-style API pattern already in production. Fewer trucks arriving off-schedule at the gate; quota finally reflects real yard and crane capacity instead of a fixed guess; best-behaved carriers are automatically identified and prioritized through the reliability score.

LSP / shipper

One reservation surface instead of a separate login per terminal. Ability to reserve — and pay — as soon as shipping instruction and VGM are ready, rather than scrambling at cutoff. Full visibility into which driver was confirmed against each paid reservation.

Trucking industry

No payment exposure — the LSP carries the port-fee cost. One app to confirm a driver against a reservation and receive "leave now" timing instead of idling at the gate, cutting fuel burn and driver overtime. A good track record compounds into priority slot access for the LSPs that route bookings through this carrier.

Risks & assumptions

• Assumption: "Truck Q" is intended as the shared, port-wide booking front end (it appears as its own actor, referenced by the THLCH UN/LOCODE, in the trade-document platform's swimlane diagram, distinct from each terminal's own backend). If each terminal instead intends a fully independent public booking UI, LCB ONE's channel layer would need to be positioned as an optional alternative front end rather than the default one.
• Assumption: terminals are willing to expose (or already compute) yard/gate/crane throughput signals for the dynamic slot engine's capacity function. Where a terminal cannot yet provide this, Phase 2 can fall back to a scheduled-static capacity curve until the signal is available.
• Risk: payment activation (Phase 2) touches bank/QR integration and likely requires coordination beyond engineering — financial and legal sign-off should be sequenced early, not left to the end of the phase.
• Risk: Phase 4's marshalling-yard concept requires physical space and traffic-management coordination alongside the software — it is the one phase not achievable through engineering alone.
• Risk: live location (§5.3) depends on driver-app permissions, battery, and rural connectivity that LCB ONE doesn't control. Design for the gap — offline queueing, a "last known position, N minutes ago" state, and never presenting a stale ping as a confirmed live one — rather than assuming continuous coverage. This also touches driver consent and labor relations with trucking companies; the EN_ROUTE-only tracking window (§5.3) should be confirmed with carriers as an acceptable boundary before Phase 1, not assumed.
• Assumption: the import model in §4.1 and §6.4 (customs broker/LSP reserves and pays once the D/O is issued) is this proposal's design, inferred from the export pattern and the gate's documented data requirements — none of the source material actually documents an end-to-end import booking process today. This needs to be validated against whatever import process (formal or informal) the pilot terminal and its customs brokers currently follow, before Phase 1 locks the import data model.
• Risk: the direct e-Customs / National Single Window feed proposed in §6.4 is the strongest way to verify import eligibility, but it requires agency-level coordination well beyond this platform's control and is not guaranteed on any particular timeline — Phase 1–2 should ship against the D/O record fallback described in §6.4 and treat the direct feed as a Phase 3+ upgrade, not a blocking dependency.

Next steps

1. Select one terminal and one gate for a 4–6 week Phase 1 pilot on top of its existing API.
2. Instrument gate wait time and arrival clustering as the baseline, then re-measure after dynamic slotting goes live in Phase 2.
3. Use pilot results to bring the remaining terminal operators and industry associations onto the shared platform under the existing MOU process.