Edge Sat-Terrestrial Access: LNB/BUC Control, Modem ASIC, Crypto
← Back to: 5G Edge Telecom Infrastructure
A practical engineering view of sat-to-terrestrial edge access nodes: what the device owns (ODU control loops, modem ASIC budgets, Ethernet/timing/crypto integration) and what must be proven with measurable KPIs in the field.
H2-1 · Definition & Boundary: what Edge Sat-Terrestrial Access is (and is not)
Edge Sat-Terrestrial Access refers to an edge gateway/terminal that converts a satellite RF link into a terrestrial handoff with explicit responsibilities: ODU control (LNB/BUC power, lock, alarms), modem ASIC data-path behavior (ACM/FEC/buffering), and operationally secure delivery of Ethernet with timing and crypto integration.
OwnsODU controlBudgetsTelemetrySecure handoff
- Hardware split: IDU (indoor unit) + ODU (outdoor unit), or a consolidated all-in-one enclosure depending on site constraints.
- Deliverable mindset: not “satellite theory,” but a repeatable handoff with defined KPIs, alarms, and recovery behavior.
- Field reality: link conditions fluctuate; the device must degrade predictably (ACM steps, buffering limits, TX mute policy) and leave evidence.
Device form factors and ownership split
ODU typically contains the LNB (receive chain) and BUC (transmit chain). It is where lock status,
temperature/power alarms, and “TX enable/mute” safety behavior must be enforced.
IDU typically contains the modem ASIC/baseband pipeline, control MCU, crypto insertion (inline or sidecar),
Ethernet handoff, and timing I/O. It is where budgets are enforced and reported.
Interfaces that define scope (what must be unambiguous)
| Interface | What it carries | What must be proven | Common failure pattern |
|---|---|---|---|
| ODU ⇄ IDU IF / control / alarms |
IF/L-band (or equivalent), LO/lock detect, TX enable/mute, AGC/ALC readings, temperature & current alarms, ODU power delivery and supervision. | Deterministic state transitions: LOCK_PENDING → LOCKED → DEGRADED → MUTE; alarms map to explicit actions; loss of control defaults to safe TX mute. | “Link looks up then drops,” thermal-triggered mute loops, lock flapping, or silent TX when lock detect/enable semantics are unclear. |
| Ethernet handoff L2/L3 + QoS |
Service port(s) with VLAN/QinQ, traffic classes, rate shaping, and optional management/OAM separation. | Measured throughput and p95/p99 latency under burst + weak-link ACM dynamics; predictable drop policy and queue limits. | “Average latency OK, app stalls,” tail-latency blow-ups caused by buffers, or throughput collapse during ACM oscillation. |
| Timing I/O 1PPS/10MHz/ToD |
Frequency/time references in/out, holdover status, and alarms for reference loss. (Algorithmic timing distribution is out of scope here.) | Clear, testable promises: frequency lock status, ToD validity, holdover alarms, and degradation policy when references are lost. | “Timing alarm storms,” ambiguous validity flags, or unrealistic expectations of precision through a variable satellite path. |
| Crypto insertion inline/sidecar |
Inline encryption/decryption or sidecar security module, secure boot chain, key provisioning, and session status telemetry. | Fast-path vs slow-path identification, predictable session recovery after reboot, and auditable key lifecycle actions (inject/rotate/revoke). | “Ping works but service dead,” throughput drops due to slow-path crypto, or intermittent post-reboot outages due to key/session desync. |
What this page deliberately does not cover
This page does not expand into satellite orbital concepts, core network slicing/UPF functions, detailed grandmaster/boundary-clock algorithms, PoE/PDU hot-swap design, or secure vault/log retention systems. Those belong to sibling pages; here they appear only as boundary references.
Figure F1 — Boundary map: ODU/IDU ownership and handoff interfaces
H2-2 · Use-Case & KPI Budgets: turning satellite reality into measurable acceptance
A sat-terrestrial edge node is successful only if service experience remains predictable under variable link conditions. That requires budget thinking: where throughput is lost, where tail-latency is created, and what recovery times are acceptable for lock, ACM convergence, and secure session establishment.
Use-cases that drive budgets (keep the list short and testable)
Emergency backhaulRemote site accessPop-up edge node
- Emergency backhaul: prioritize deterministic recovery and controllable tail-latency over peak headline throughput.
- Remote site access: long-duration stability, explicit downgrade behavior, and “evidence first” telemetry for supportability.
- Pop-up edge node: fast bring-up: ODU lock time + secure session time + service readiness time must be contractual.
Throughput budget (make losses measurable, not abstract)
Effective Throughput ≈ PHY Rate × (1 − Protocol Overhead) × ACM Duty Factor × (1 − Loss/Recovery Penalty)
| Budget term | What it means (measurable) | How to measure | Typical pitfall |
|---|---|---|---|
| PHY Rate | Nominal waveform rate at the modem/PHY under a chosen ACM mode. | Read modem ACM/MCS state and nominal rate counters. | Assuming the highest MCS is the “real” rate in variable conditions. |
| Protocol overhead | Encapsulation, framing, FEC parity, management/control channels, crypto headers. | Compare payload counters vs air-interface counters; document the breakdown. | Only quoting “air rate,” ignoring payload efficiency and headers. |
| ACM duty factor | Time distribution across ACM modes (how long each mode is active). | Histogram of ACM states over fixed windows (e.g., 5 min / 30 min / 24 h). | ACM oscillation that looks fine on average but ruins application QoE. |
| Loss/recovery penalty | Effective throughput loss due to drops, retries, resequencing, rekey/rehandshake, or deep buffering. | Packet loss, reorder counters, queue depth, session resets; correlate with traffic bursts. | Crypto slow-path or buffer bloat creating “invisible” throughput collapse. |
Latency & jitter budget (acceptance must use p95/p99, not averages)
Average latency can look healthy while user experience fails. Acceptance should specify at least: p95/p99 latency, jitter distribution, and a fixed test window that includes weak-link periods and burst traffic. Satellite propagation is not the only contributor; the largest avoidable contributors are usually buffering and reprocessing paths.
| Component | Contribution | Knobs that move it | Evidence to log |
|---|---|---|---|
| Propagation | Baseline delay of the satellite path; may vary by routing, beam, and scheduling. | Not directly controllable; only bounded by system configuration. | Timestamped RTT samples and route/beam identifiers (when available). |
| FEC / interleaver | Stabilizes error performance but can inflate tail-latency when depth is high. | Interleaver depth, FEC profile, ACM aggressiveness. | ACM state + FEC stats + interleaver depth history per window. |
| Queue / jitter buffer | Absorbs burst and link variability; the most common source of p99 blow-ups. | Buffer limits, drop policy, QoS shaping, queue discipline. | Queue depth histogram, drop reason counters, per-class latency samples. |
| Crypto processing | Inline/sidecar crypto adds fixed + variable delay; slow paths create heavy tails. | Fast-path enablement, session mode, packet size sensitivity. | Session state, fast/slow path counters, rekey events correlated to QoE dips. |
Availability & recovery budget (contractual behaviors)
Bring-upDegradeRecover
- ODU lock time: power-on → lock detect stable (include thermal conditions).
- ACM convergence time: first link → stable mode distribution (avoid “forever hunting”).
- Secure session readiness: boot → keys available → crypto session established → service allowed.
- Degrade policy: explicit thresholds for “degrade” vs “mute,” and guaranteed safe behavior on control loss.
Figure F2 — Budget map: where throughput is lost and where p99 latency is created
H2-3 · RF Outdoor Unit Control: LNB/BUC power, protection, and alarm-driven actions
Outdoor-unit (ODU) control is a safety-critical closed loop, not a “power on and forget” interface. A field-ready design must enforce clear semantics for TX enable/mute, lock detect, thermal/current protection, and a deterministic alarm-to-action policy that defaults to safe behavior.
LNB control: supply, polarization switching, and AGC as a health signal
- Supply & polarization: define switching mechanisms (e.g., voltage level, 22 kHz tone, or control line) and require a measurable settling window after switching.
- AGC usage: treat AGC as a trend signal for attenuation and pointing changes; avoid treating AGC as an absolute SNR substitute across different LNBs.
- Evidence: log polarization state, AGC trend, and switching timestamps to correlate with link drops and reacquisition behavior.
BUC control: TX enable/mute, ALC power loop, lock detect, and hard protections
| Control / signal | Meaning in a field device | Acceptance criteria | Typical failure mode |
|---|---|---|---|
| TX enable | Permission to transmit, not proof of “safe to transmit.” Must be gated by lock/thermal/current and control-link health. | TX enable is asserted only when preconditions are met; on control loss, TX transitions to mute within a bounded time. | Unclear semantics cause accidental emission or silent no-TX behavior during partial fault states. |
| MUTE | Failsafe output state that must be reachable from any state and must dominate “enable.” | MUTE overrides enable; hard-fault or heartbeat loss forces MUTE; reason codes are latched and logged. | Flapping enable/mute loops caused by missing hysteresis or ambiguous fault latching. |
| ALC (power loop) | Closed-loop power control with saturation; temperature and supply variation change gain and may cause loop stress. | Power setpoint tracking within tolerance across temperature; saturation triggers “degraded” state and limits, not unstable hunting. | Power hunting or saturation creates bursty EIRP and link instability; “looks OK” on average but fails at p99. |
| Lock detect | Lock validity signal must be debounced and interpreted with context (transient unlock vs sustained unlock). | Lock is declared only after a stability window; sustained unlock transitions to degraded/mute with logged timestamps. | False lock causes TX under invalid LO; unlock chatter triggers repeated reacquisition and service drops. |
| Over-temp / over-current | Hard protections to prevent thermal runaway and power stage damage; must map to deterministic actions. | Hard fault forces mute; soft threshold limits power or forces modulation downgrade; alarms are tiered and latched. | Thermal cycling creates periodic mutes; missing tiering causes either unsafe TX or unnecessary outages. |
Control ownership & fail-safe policy (who is the master)
Control ownership
Define a single master for ODU commands (MCU/FPGA/modem-side control), and specify which side owns state transitions and fault latching. Avoid multi-master “last writer wins” ambiguity.
Fail-safe on loss-of-control
When heartbeat/control link is lost, the required behavior is default mute, with a bounded timeout. Recovery must be explicit: re-acquire lock, re-validate thresholds, then re-enable TX.
Deterministic lock state machine and tiered alarms (the engineering difference)
LOCK_PENDING
LOCKED
DEGRADED
MUTE
- State machine: transitions are based on debounced lock detect, thermal/current thresholds, and control-link health; every transition logs a reason code and snapshot counters.
- Alarm tiering: hard faults force MUTE (over-temp, over-current, sustained unlock, heartbeat loss). soft degradations limit power or trigger modem downgrade (near-limit temperature, ALC saturation, AGC trend).
- Field evidence: without time-stamped transitions + reason codes, “link drops” cannot be explained or prevented.
Figure F3 — ODU control state machine and Alarm → Action mapping
H2-4 · Modem ASIC Data Path: ACM, FEC/interleaver, buffering—meeting throughput without destroying p99 latency
A modem ASIC must be treated as a measurable pipeline. Performance claims are credible only when each stage has counters, test windows, and knobs with known trade-offs. The most frequent field failures are not “insufficient compute,” but mis-tuned ACM behavior, overly deep interleaving, and unbounded buffers that inflate tail latency.
Pipeline view (forward and return)
- Forward path: Framer/Encap → Scheduler → FEC/Interleaver → Buffer/Jitter handling → PHY.
- Return path: PHY → Deinterleave/Decode → Reorder/Buffer → Scheduler → Decap.
- Rule: each block must expose at least one “proof counter” (drops, queue depth, FEC stats, ACM state time histogram).
ACM behavior: trigger inputs, convergence time, and oscillation control
- Trigger inputs: SNR/BER/ESNO are inputs, but acceptance should focus on mode distribution over time (how long each mode stays active).
- Convergence time: define a measurable “settle window” after link acquisition or a fade event; repeated hunting is a service killer even if the average rate looks high.
- Stability controls: hysteresis and minimum dwell time reduce oscillation, but can reduce short-term peak throughput—this trade-off must be explicit.
FEC/interleaver and buffers: the three-knob model
| Knob | Primary benefit | Cost / risk | Most affected KPI |
|---|---|---|---|
| Interleaver depth | Stronger resilience to burst errors; smoother error performance under fades. | Increases tail latency; can create “long tails” during decode/reorder under stress. | p99 latency / jitter |
| Buffer limits | Absorbs burst and variability; reduces short-term drops. | Buffer bloat inflates tail latency; hides congestion until the user experience collapses. | p99 latency (most common) |
| ACM step rate | Tracks link changes; improves average payload throughput across varying conditions. | Fast stepping without hysteresis causes oscillation and throughput volatility. | Average throughput / volatility |
Acceptance method: prove p95/p99, not just headline rate
Acceptance should lock a test window and require distribution metrics: p95/p99 latency, throughput over time, queue depth histogram, and ACM mode histogram. Without these, “meets Gbps” can coexist with unusable tail latency.
Figure F4 — Modem pipeline with measurable points (ACM/FEC/buffer) and KPI linkage
H2-5 · Ethernet Handoff & QoS: turning satellite uncertainty into a ground-side SLA
The service handoff port is the contract boundary. The goal is not to describe switch internals, but to define how business traffic is delivered with predictable behavior when satellite capacity and latency vary. A field-ready handoff must make classification, shaping, and drop rules explicit.
Service port modes: what is handed off (and where the boundary is)
- Physical: 1/10/25G service ports (copper/fiber) with explicit link policy (auto vs fixed) and MTU statement.
- Encapsulation: VLAN or QinQ for multi-tenant separation; keep the scope at “handoff model,” not a protocol tutorial.
- L2 vs L3 handoff: document responsibility (who owns routing/ARP/ND, who owns NAT, who owns MTU/PMTUD), and keep it stable across deployments.
Why shaping matters more on satellite: avoid volatility and tail-latency collapse
- High RTT: congestion feedback is slow; excess buffering turns into long tails even when average throughput looks fine.
- ACM-driven capacity changes: the link rate can step down during fades; unshaped bursts become persistent queues.
- Satellite-aware SLA: shaping at handoff “packages” satellite variability into predictable service classes.
QoS building blocks: classification → queue → shaping → satellite bearer
Keep the number of classes small (2–4). The objective is operational clarity: protect control/OAM, preserve interactive experience, and allow bulk traffic to absorb losses during congestion.
| Traffic class | How to classify | Queue & shaping intent | Congestion & drop policy |
|---|---|---|---|
| Control / OAM mgmt, health, key control |
Dedicated VLAN, DSCP/PCP marking, or explicit ACL list | Highest priority queue; reserve minimum bandwidth; strict cap to prevent abuse | Protect first: avoid drop; if forced, drop lowest-importance control (never kill keepalives/telemetry) |
| Interactive voice, low-latency apps |
DSCP/PCP class + optional 5-tuple filters | Priority queue with bounded depth; shaping to reduce burstiness; keep queueing delay predictable | Bound tails: drop early when queue delay exceeds target; prevent buffer bloat |
| Business general user traffic |
Default VLAN/DSCP, per-tenant policies | Weighted queue; per-tenant shaping; enforce fair share when ACM steps down | Fair loss: drop proportionally under congestion; avoid starving interactive/control |
| Bulk cache fill, backups |
Lowest DSCP/PCP, explicit bulk ports | Lowest priority queue; aggressive shaping; allow satellite to prioritize other classes | Drop first: primary loss bucket during fades; acceptable to throttle heavily |
Acceptance method: define SLA with distributions, not single numbers
p95/p99 latency
throughput over time
queue depth histogram
class drop counters
ACM mode histogram
- During fade / ACM step-down: control and interactive traffic must remain usable and measurable, even if bulk collapses.
- During burst: shaping must prevent “hidden queues” that inflate tail latency.
- During congestion: drop policy must match the class mapping; counters must prove it.
Figure F5 — QoS mapping template and simplified queue/shaper handoff
H2-6 · Timing Integration: defining timing I/O, validity, and safe downgrade behavior
Timing in a satellite access box should be defined as interfaces and guarantees: what signals exist, what “valid” means, and how alarms drive downgrade behavior. Deep PTP/SyncE theory is out of scope here; the focus is on timing I/O semantics and acceptance points.
Timing I/O checklist (signals, validity, alarms)
| Interface | Role in this device | Validity states | Alarm / action expectation |
|---|---|---|---|
| 1PPS | Time pulse input/output for coarse alignment and event marking | VALID / HOLDOVER / INVALID | Source loss → HOLDOVER; timeout/expired holdover → INVALID + alarm |
| 10 MHz | Frequency reference input/output for frequency alignment | LOCKED / HOLDOVER / UNLOCKED | Unlock → alarm; frequency alignment must report state transitions with timestamps |
| ToD | Time-of-day output (reference/marking), not a promise of nanosecond phase precision | VALID / DEGRADED / INVALID | Degraded indicates reduced trust; invalid indicates “do not use as truth” |
| Sync in/out | External timing coordination interface with explicit status and alarms | SYNC OK / LOSS | Loss triggers alarms and forces explicit downgrade policy (no silent failures) |
Satellite reality: define what can be promised (and what cannot)
- Variable delay: queuing, ACM changes, and link re-acquisition introduce time variability.
- Asymmetry: uplink/downlink paths can behave differently; “one-way time” is hard to guarantee.
- Operational rule: treat time as reference/marking/alignment unless strict conditions for one-way measurement exist.
Commitment tiers: interfaces and acceptance points (no unrealistic promises)
Tier A: Time-of-Day alignment
Tier B: Frequency alignment
Tier C: Precise phase
- Tier A (ToD alignment): provide ToD output with a validity flag and event logs for state changes.
- Tier B (frequency alignment): provide 10 MHz output with lock/holdover states and holdover duration acceptance.
- Tier C (precise phase): expose ports and alarms, but keep detailed phase-distribution guarantees out of this page.
Alarm-driven downgrade: REF loss → HOLDOVER → EXPIRED → INVALID
The most important deliverable is deterministic behavior: when the time source degrades or disappears, outputs must change state explicitly and alarms must guide safe operation. No silent “looks valid” output under invalid conditions.
Figure F6 — Timing I/O panel, validity states, and downgrade ladder
H2-7 · Crypto Modules & Secure Boot: encryption is a deliverable chain, not just an algorithm
A deployable satellite access node needs a security chain that is auditable, repeatable in production, and deterministic during failures. This section defines module boundaries (embedded vs external), the minimum secure/measured boot loop, key provisioning lifecycle, and symptom-driven troubleshooting.
Module forms and responsibility boundaries
| Form | Typical role | Interfaces & control points | Must expose (evidence) |
|---|---|---|---|
| Embedded crypto engine (SoC/ASIC/SmartNIC) |
Low-latency, high-throughput datapath offload | Policy table, session setup, key handles, counters | Offload hit rate, session state, drop reasons, fast/slow-path indicator |
| External inline module (bump-in-the-wire) |
Retrofit encryption without redesigning internal datapath | Inline port pair, bypass policy, link-health, negotiation state | Negotiation reason codes, bypass/fail mode state, link sync vs secure sync |
| TPM | Device identity, measured boot anchors, key wrapping | Attestation/measurement registers, sealed objects, PCR policies | Measured values, boot verdict, monotonic counters used by policy |
| HSM | High-assurance key custody, multi-tenant separation, provisioning control | Provisioning API, rotation/revocation workflows, audit hooks | Key lifecycle logs, policy enforcement flags, failure reason codes |
Minimum secure boot loop: ROM → bootloader → firmware → configuration
- Chain of trust: immutable root (ROM or RoT) validates the next stage, stage by stage, until the runtime image is verified.
- Measured boot: record boot measurements and expose a readable verdict (VALID / DEGRADED / INVALID) for operations.
- Configuration integrity: configuration is versioned and integrity-checked; policy updates must not silently change key state.
Key provisioning & lifecycle: inject → rotate → revoke (keys separated from configuration)
Factory inject
Field rotation
Revocation
Dual keyslot
Counters/versioning
- Factory inject: deterministic identity binding, traceable injection record, post-inject self-test that proves “present but not readable.”
- Rotation: dual keyslot (A/B) with explicit cutover window; rollback rules must be documented and observable.
- Revocation: policy-driven invalidation with version/counter discipline; avoid “config change = key wipe” incidents by design.
Three failure symptoms and fastest isolation paths
These patterns reduce MTTR. Each symptom is mapped to evidence (counters / reason codes) and a minimal isolation test.
| Symptom | Most likely causes | Evidence to check | Fast isolation test |
|---|---|---|---|
| Link sync OK but user traffic drops secure negotiation mismatch |
Policy mismatch, negotiation failure, wrong peer identity, replay window mismatch | Negotiation reason codes, session state machine, secure-drop counters | Controlled bypass/clear-text test to prove datapath works, then re-check policy/identity |
| Throughput below spec slow path engaged |
Offload miss, CPU fallback, extra copies, per-packet overhead on control path | Offload hit rate, CPU usage, queue depth, fast/slow-path indicator | Reduce parallel sessions / change packet size to see if offload engages and counters shift |
| Intermittent outage after reboot keyslot/counter desync |
Keyslot version mismatch, monotonic counter drift, stale policy pointer, partial provisioning | Keyslot active ID, counter/version snapshots, boot verdict changes across reboots | Force single keyslot (controlled), reset replay window (controlled), confirm stability then re-enable A/B |
Figure F7 — Root-of-Trust to crypto datapath chain with audit/alarms (production-ready view)
H2-8 · Power / Thermal / Environment: engineering the conditions for stable field operation
Field stability is a device-level contract: input envelope, brownout behavior, restart policy, thermal derating, and environment-driven symptoms must be measurable and tied to deterministic actions. This section stays inside the device (not site-level power panels).
Power input envelope and brownout behavior (device view)
- Input range: define the supported voltage window and the protection posture (surge/UV/OV) as a measurable capability.
- Brownout policy: specify whether the unit derates, performs an orderly shutdown, or hard-resets when input dips.
- Restart strategy: deterministic retry timing and retry limits; avoid uncontrolled reboot loops.
- Configuration retention: define what survives power loss (identity, policy pointers, provisioning state, safe defaults).
Thermal behavior: BUC heat → controlled derating (power/modulation) instead of surprise failures
temperature zones
TX power limit
modulation downshift
mute / cool-down
fan fault
- Hot spots: BUC power amplifier and nearby regulators are the first-order thermal drivers.
- Derating curve: temperature triggers graduated actions (limit TX power, reduce modulation, cap burst throughput) with hysteresis to prevent oscillation.
- Evidence: thermal state + action must be logged as reason codes so “why throughput dropped” is explainable on site.
Environment: outdoor stress, vibration, and EMI show up as link/timing symptoms
Avoid theory. Focus on symptoms and monitors: lock jitter, re-acquisition bursts, error counters, and sensor snapshots at the moment of degradation.
- Vibration / loose interconnect: intermittent lock detect toggles, AGC swings, re-acquisition counters rising.
- EMI stress: sporadic errors, unexplained resets, and “looks fine on average but fails in bursts.”
- Monitoring approach: sensor snapshots (VIN/TEMP/FAN/VIB/ERR) tied to alarms and state transitions.
Action table: temperature/voltage → deterministic downgrade steps (copy-ready policy)
| Trigger | Primary action | Recovery condition | Evidence (must log) |
|---|---|---|---|
| Input UV (warning) | Cap burst throughput; protect control/OAM; prevent deep queues | Voltage returns above threshold + dwell time | VIN min, duration, class drop counters, reason code |
| Input UV (critical) | Orderly shutdown or controlled restart; avoid flash/policy corruption | Stable VIN + restart delay + retry limit | restart count, brownout cause code, last-known state snapshot |
| OT (warning) | Reduce TX power; step down modulation; enforce derating curve | TEMP below clear threshold + dwell time | temp peak, derate level, modem/BUC state, timestamps |
| OT (critical) | Force mute + cool-down; protect hardware and stable recovery path | Cooldown complete + clear threshold + operator policy | mute reason, cool-down timer, fan status, recovery verdict |
| Fan fault / thermal runaway | Immediate derate; escalate alarms; optionally safe shutdown | Fan restored + stable temperature | fan tach, OT events, derate steps, alarm escalation state |
| EMI/vibration symptom burst | Capture snapshot; raise alarm; protect critical classes; avoid reboot loops | Error counters normalize for a window | ERR counters, VIB reading, lock toggles, event snapshot |
Figure F8 — Device monitoring loop: sensors → monitor MCU → alarms → derating actions
H2-9 · Management & Telemetry: remote operations must be evidence-first
Remote support cost drops only when the device can answer, within minutes, what changed and why. This section defines a management-plane boundary, a minimal telemetry set, and an evidence bundle that enables a 5-minute forensic replay without guessing.
Management-plane boundary (local rescue vs remote fleet operations)
- Local (CLI / Web): bring-up, rescue mode, offline diagnosis, and “last resort” recovery.
- Remote (REST / NETCONF / private): bulk configuration, image rollout with rollback, health polling, and alarm handling.
- Operational boundary: management access is isolated from user traffic; privilege is role-based; every change is traceable by reason code.
Minimal telemetry set (grouped by evidence domains)
“More metrics” does not equal “more operable.” Each field must map to a diagnostic question (RF health, ACM/FEC behavior, queueing cause of p99, ODU control state, timing status, crypto session/offload state).
| Evidence domain | Minimal fields (examples) | Suggested sampling | Answers (diagnostic question) |
|---|---|---|---|
| RF / link health | SNR/ESNO, AGC (if available), link state, reacquire count | 1–5 s + max/5min | Is the degradation driven by the air interface or by internal bottlenecks? |
| ACM / FEC | ACM mode, step change rate, convergence timer, FEC corrected/uncorrectable | 1–10 s + Δcounters/5min | Is throughput variation caused by ACM oscillation or by error correction load? |
| Queues / buffering | Queue depth, tail drop count, burst limiter hit, shaping rate | 1 s + p95/p99/5min | Why is p99 latency bad even when the average looks fine? |
| ODU control | BUC power cmd/actual, BUC temp, TX mute, lock detect, alarm level | 1–10 s + event-driven | Is the outdoor chain stable, and which state transition triggered muting/derating? |
| Timing status | time source state (LOCK/HOLDOVER/UNSYNC), input/output status, alarms | 10–60 s + events | Is time a trustworthy reference for logs and SLA evidence right now? |
| Crypto chain | session state, negotiation reason codes, offload hit rate, fast/slow-path indicator | 1–10 s + Δcounters | Is traffic dropped due to policy/negotiation, or due to slow-path fallback? |
Logs: events vs counters (forensic replay without guesswork)
Event
Reason code
Before/After state
ΔCounter
Snapshot
- Event logs: lock/unlock, re-negotiate, degrade/restore, restart cause, policy change. Each event includes before/after state + reason code.
- Counter logs: FEC corrected/uncorrectable, retransmit, drops, queue overflow, negotiation failures. Counters must support time-window deltas (Δ/5min, Δ/1h).
The 5-minute forensic bundle (mandatory fields)
- Time anchor: device timestamp + time-source state (LOCK/HOLDOVER/UNSYNC).
- Context: interface/port ID, service class (VLAN/flow class), session ID (crypto if applicable).
- State snapshot: ACM mode, FEC Δcounters, queue depth/p99, BUC power/temp, mute/lock status.
- Cause: degrade reason, negotiation failure code, reset reason (WDT/BOR/manual), alarm severity.
Figure F9 — Telemetry model: metrics → sampling/aggregation → thresholds → alarms/actions → snapshot bundle
H2-10 · Validation & Production Checklist: proving delivery with windows, samples, and p95/p99
“Pass” must mean repeatable evidence: link establishment, ACM convergence, throughput and p95/p99 latency, power-loss recovery, thermal derating behavior, and security chain integrity. This section provides a three-layer checklist (engineering, production, field acceptance) with practical test windows and sample-size rules.
Rules that prevent “average value” deception
p95/p99 required
windowed deltas
min duration
repeat cycles
snapshot on alarms
- Latency: report p95/p99 with a defined window; do not accept “avg only.”
- Recovery: validate with repeated cycles (cold start, warm restart, brownout restart) using the same pass/fail thresholds.
- Degradation: include at least one controlled “bad period” (weak signal/thermal stress) and verify deterministic downgrade actions.
Three-layer checklist (Engineering → Production → Field)
| Layer | What to prove (evidence) | How to measure (bench + points) | Window / samples |
|---|---|---|---|
| Engineering | Link establishment time (ODU lock + ACM stable + crypto ready); ACM convergence without oscillation; throughput + p95/p99 latency; power-loss recovery; thermal derating curve; secure boot verdict + keyslot behavior. | Traffic generator with timestamps; queue depth counters; RF/ACM/FEC counters; ODU power/temp; crypto hit rate & reason codes. |
Latency: ≥30 min window or ≥1e6 packets (stricter wins). Recovery: ≥30 cycles mixed (cold/warm/brownout). |
| Production | Fast pass/fail self-tests: ODU control (mute/enable, lock detect), crypto self-test, Ethernet throughput/loss, timing I/O status, sensor sanity; generate “birth record” snapshot. | Automated jig; loopback where applicable; fixed scripts; stable pass/fail reason codes; store version/counter baselines. | Short deterministic windows (seconds to minutes) but strict thresholds; repeat on a sample rate per lot. |
| Field acceptance | Weak-signal / rain-fade behavior (ACM/FEC degrade predictably); long-run stability; remote upgrade + rollback; alarm-to-snapshot closed loop; explainable throughput/latency under controlled stress. | Remote telemetry collector; long-run counter deltas; controlled traffic patterns; verify action tables (derate/mod down/mute). | Stability: 24–72 h trend. Stress: at least 3 degradation cycles (up/down + random disturbance). |
Copy-ready “test window & sample size” guidance (practical baseline)
- Latency window: 30 minutes minimum, plus p95/p99 per 5-minute segment.
- Throughput stability: 5-minute segments with Δcounter correlation (FEC, drops, queue overflow).
- Recovery: 30 cycles minimum; include at least 10 brownout events (not only clean power cuts).
- ACM behavior: cover at least 3 fade cycles; record step rate and convergence time per cycle.
Figure F10 — Validation bench and measurement points (traffic, timestamps, environment, ODU power/lock)
H2-11 · Failure Modes & Debug Playbook (Evidence-First)
What this section delivers
Field issues are solved fastest when troubleshooting starts from state bits + counters + event timestamps, not from packet capture. The playbook below maps each high-frequency symptom to: likely causes (ranked), fast verification (exact evidence to read), and safe mitigations (reversible actions that preserve service and safety).
- Start with 3 readings
- Correlate in a 5–10 min window
- Prefer counters over anecdotes
- Mitigate first, then root-cause
30-second triage: start from 3 readings
ODU / RF
ODU Lock State
- LOCKED / DEGRADED / REACQUIRE / MUTE
- Recent transitions (count + timestamp)
MODEM / Link
ACM Stability
- Current ACM MODCOD
- Switch count in last 5 minutes
- Convergence time after step change
SECURITY
Crypto Session State
- UP/DOWN + failure reason code
- Fast-path offload hit/miss indicator
Queue / SLA
Tail-latency evidence
- p99 latency (vs p50)
- Queue depth / watermark
- Drop / shaper-hit counters
Rule of thumb:
If Lock is unstable → investigate ODU control / power / thermal first. If Lock is stable but
ACM oscillates → investigate ACM/FEC/interleaver knobs. If Crypto is down → read reason codes
before changing network settings. If all are stable but apps stall → investigate queues/shaping and p99.
Playbook table: Symptom → Cause → Evidence → Safe mitigation
The “Fast verification” column is intentionally concrete (which state/counter/event to read and what it means), so remote support can converge within minutes.
| Symptom (ticket-style) | Likely causes (ranked) | Fast verification (evidence to read) | Safe mitigation (reversible) |
|---|---|---|---|
|
ODU
Link flaps immediately after power-on
|
|
|
|
|
QUEUE MODEM
High throughput “on paper” but apps stutterp99 latency spikes |
|
|
|
|
QUEUE
Average latency OK, jitter is extreme
|
|
|
|
|
SECURITY
Ping works, but user traffic is fully down
|
|
|
|
|
TIMING
Timing port drift alarms appear intermittently
|
|
|
|
Tip: keep troubleshooting windows consistent (5–10 minutes) so counters, events, and symptoms align without “average value” illusions.
Example instrumentation & protection BOM (specific part numbers)
The part numbers below are common building blocks used to make the required “evidence signals” measurable and reportable. They are examples (not endorsements); final selection depends on rail voltage/current, temperature range, and compliance needs.
| What must be measured/controlled | Example part numbers | Why it helps H2-11 troubleshooting |
|---|---|---|
| LNB supply + 13/18V + 22kHz tone |
|
Provides controlled LNB power + diagnostic bits; makes “lock flaps after power-on” evidence-driven (UV/OC/OT reporting). |
| ODU / BUC rail current/voltage telemetry |
|
Turns “maybe power issue” into timestamped V/I events that correlate with lock, mute, and reset loops. |
| eFuse / inrush limiting / short protection |
|
Enables safe mitigations like soft-start/inrush limiting and provides protection events for repeated boot flapping cases. |
| Board temperature sensing for derate |
|
Supports “temperature → action” derate rules and explains BUC mute/DEGRADED transitions with real data. |
| Watchdog and controlled recovery |
|
Allows deterministic reboot strategy and clean reset-reason attribution (WDT/BOR), avoiding blind power-cycling. |
| Secure element for device identity / keys |
|
Helps prevent “reboot then intermittent crypto failure” by anchoring key storage and provisioning flows. |
| TPM 2.0 for measured boot / attestation |
|
Enables auditable secure boot chain and measurable “why crypto datapath is down” evidence (attestation logs). |
| Jitter attenuation / clock conditioning |
|
Improves timing I/O robustness and reduces nuisance drift alarms; makes timing-state transitions interpretable. |
Figure F11 — 3-reading diagnostic flow tree (evidence-first)
Figure F11 — Start from Lock / ACM / Crypto, then branch by evidence
ALT: Diagnostic flow tree for Edge Sat-Terrestrial Access, branching from ODU lock, ACM stability, and crypto session state into evidence-based debug paths.
Request a Quote
H2-12 · FAQs ×12
Each answer stays inside this device boundary (ODU control, modem behavior, Ethernet handoff, timing I/O, crypto chain, power/thermal, telemetry, validation, and on-box debug evidence). Each includes: state + counter + time window, so field support can converge fast.
1) LNB readings look normal, but the link is still unstable—what status bits should be checked first?
Start with the ODU lock state machine (LOCK_PENDING/LOCKED/DEGRADED/MUTE) and its transition count in a 5–10 minute window. Next read the BUC mute/derate reason code and any “unlock” flags, then correlate with reset reasons (BOR/WDT) and rail V/I events. If an LNB supply/controller is used (e.g., ST LNBH25), check its OC/OT indicators rather than relying only on AGC.
2) The BUC frequently mutes or derates—what alarms most commonly trigger it?
Most frequent triggers are over-temperature, over-current, PA rail undervoltage, synthesizer unlock, or a safety policy forcing TX inhibit. Verify by reading the exact mute reason code and matching timestamps to temperature and rail-current telemetry (e.g., TMP117 + INA238). If the input rail is protected by an eFuse (e.g., TPS25982), check trip/retry counters. Mitigate with a staged re-enable and a derate curve before chasing “RF causes.”
3) Why does ACM keep switching MODCOD, making throughput swing up and down?
First quantify ACM stability: switch count, dwell time, and convergence time over a 10–30 minute window, then correlate with SNR/ESNO variance and FEC deltas (corrected vs uncorrectable). If MODCOD switches faster than the channel actually changes, the control loop is too aggressive. Use only device-side knobs: minimum dwell, hysteresis, and slower step rate. Then confirm that queue/shaper settings are not creating bursty “self-induced” congestion.
4) Is a deeper interleaver always “more stable”? Why can it explode p99 latency?
A deeper interleaver can improve burst-error tolerance but adds deterministic delay and worsens tail latency when combined with buffering and retransmission bursts. Validate with an A/B run: log interleaver depth, p50/p95/p99 latency, and uncorrectable FEC deltas in the same 30-minute window. Choose depth by a p99 target, not by “average throughput.” If p99 jumps while FEC improves, the device is trading user experience for robustness.
5) How should Ethernet shaping/queues be configured so the satellite link doesn’t “self-excite” congestion?
Treat the satellite bearer as a variable-rate service and make bursts predictable. Map traffic classes to queues, enforce per-class minimums for control/real-time flows, and apply token-bucket shaping so egress bursts match the bearer’s sustainable rate. Validate with shaper-hit counters, queue watermarks, and drop-by-queue counters aligned to p99 latency. If queue depth spikes without drops, it is bufferbloat; reduce burst size and tighten thresholds.
6) Average latency looks great, but user experience is terrible—what test window proves it?
Average hides tail behavior. Use a 30–60 minute test with 5-minute bins and report p95/p99 latency, jitter, and loss alongside queue watermark and ACM state transitions. Keep the traffic profile constant (rate + burst) and isolate background flows; otherwise, the distribution is not comparable. A “good average” with a wide (p99−p50) gap is the signature of buffering, ACM oscillation, or retransmission bursts—not a clean network.
7) “Ping works but traffic is dead”—how to quickly decide if it’s crypto-session or RF/link?
Use a 30-second triage: (1) ODU lock state stable? (2) ACM stable? (3) crypto session UP with a clear reason code? If lock and ACM are stable but the crypto session is DOWN or renegotiating, focus on policy/key state, not RF. Check offload hit rate vs CPU load to detect slow-path. If the design anchors identity/keys with secure hardware (e.g., ATECC608B or TPM SLB9670VQ2.0), verify boot measurements and key-version consistency before changing network settings.
8) Throughput drops sharply after enabling encryption—what slow path is most common?
The most common slow paths are: offload disabled/unavailable, MTU/fragmentation pushing packets into a software path, or frequent rekey/SA churn. Verify by comparing offload counters (hit/miss), CPU utilization, and queue build-up location in the same 10-minute window. If CPU spikes and offload hit rate collapses, it is not “the satellite”; it is the crypto datapath. Mitigate by locking cipher-suite/policy to the accelerator’s fast path and stabilizing rekey intervals.
9) How should Timing I/O be accepted without surprises? Which promises are unrealistic?
Define acceptance by interface behavior, not theory: 1PPS/10MHz/ToD in/out validity, lock/holdover state transitions, and alarm debounce/hysteresis. Split deliverables into tiers: Time-of-Day alignment, frequency alignment, and phase alignment—do not promise nanosecond-grade phase under asymmetric/variable satellite delay. If a jitter cleaner is used (e.g., Si5341), verify its lock/holdover indicators and counters during source loss/recovery tests. Record evidence with timestamps and configuration versions.
10) What are the 10 most important telemetry metrics, and how to choose sampling periods?
A minimal set is: ESNO/SNR, ACM MODCOD, ACM switch count, corrected/uncorrectable FEC deltas, queue watermark, shaper-hit/drop-by-queue, BUC mute reason + TX power, BUC temperature, ODU lock state transitions, crypto session state + offload hit rate. Sample “fast” metrics (queues/session) every 1–5s, “medium” (ACM/FEC) every 10–30s, and “slow” (thermal/rail health) every 60s. Implement rail/thermal sensing with parts like INA238 and TMP117, and tag event logs with timestamps.
11) After power loss/reboot it sometimes fails—more often config retention or key-state?
Decide with evidence, not guesswork: read reset reason (BOR/WDT), boot measurement/secure-boot verdict, and the running config version hash. If crypto failures appear only after reboot, check keyslot/counter synchronization and session rebuild reason codes. If failures correlate with rail droops, capture V/I telemetry (e.g., INA238) and any eFuse retry events (e.g., TPS25982). Mitigate with atomic config updates (CRC + rollback), delayed service bring-up until keys and policies are consistent, and explicit resync procedures for key-state.
12) How to reproduce rain-fade/weak-signal issues and produce traceable evidence?
Build a repeatable evidence package: keep traffic profile fixed, lock configuration versions, and log ESNO/SNR, ACM track over time, FEC deltas, queue watermark, shaper hits/drops, and p99 latency in aligned 5-minute bins across a 30–60 minute window. During natural rain-fade, mark event timestamps; during lab/field reproduction, use controlled attenuation and keep thermal/power stable. The goal is a “timeline” that explains service degradation using counters and state transitions, not narratives.
