PaperlayerView exact revision on arXiv

Source-linked AI summary

SafeLink-Agent: Agentic Maintenance for Adaptive Bitrate Controllers over Dynamic Starlink Networks

Hongjun Xie, Bowen Zhang, Genke Yang, Pengcheng Luo

arXiv:2608.28194v1eess.SY

TL;DR

Dynamic Starlink links expose ABR controllers to changing network conditions, while controllers designed or trained for specific conditions are difficult to maintain after deployment. SafeLink-Agent mines failures, proposes LLM-generated patches, and commits only patches that pass replay verification. On real Starlink traces, it reduces severe-session risk for rule-based and learned controllers under the reported maintenance workflows.

  • Problem

    Dynamic Starlink profiles can differ substantially from original design conditions, while deployed rule-based and learned ABR controllers are difficult to adjust when new profiles expose severe stalls or QoE regression.

  • Method

    SafeLink-Agent mines replay evidence, uses an LLM-based agentic patch proposer to generate candidate controller patches, and commits them after target-profile and regression-memory replay verification.

  • Results

    Verified maintenance reduces severe-session risk across rule-based and learned controllers, including RobustMPC's severe-session ratio falling from 2.60% to 0.40% and learned-controller average risk falling from 39.01% to 9.79%.

  • Takeaways & Limitations

    Agentic maintenance can turn newly observed Starlink failures into verifiable controller updates while preserving previously acceptable behavior through regression checks.

Abstract

from arXiv · show

Low Earth orbit (LEO) satellite broadband, represented by Starlink, is making high-resolution video streaming feasible beyond fixed terrestrial coverage. However, Starlink access links change across time and regions, exposing adaptive bitrate (ABR) streaming to shifting throughput tails, latency, volatility, and handover conditions. Existing ABR controllers are usually designed, tuned, or trained for specific network conditions, making it difficult to handle newly exposed hard Starlink profiles. This paper proposes SafeLink-Agent, an agentic maintenance framework for ABR controllers over dynamic Starlink networks. SafeLink-Agent summarizes exposed failures and uses a large language model (LLM)-based agentic patch proposer to generate candidate patches, while replay verification determines whether each patch can be safely committed. The framework supports both rule-based controllers and learned controllers under the same maintenance workflow. Experiments on real Starlink networks show that SafeLink-Agent reduces the severe-session ratio of RobustMPC from 2.60% to 0.40% and reduces cumulative severe sessions from 45 to 7 in rolling maintenance. For learned controllers, verified adaptive auditing lowers the average severe-session ratio from 39.01% to 9.79%. These results demonstrate that agentic maintenance can improve ABR robustness under dynamic Starlink access conditions.

I. INTRODUCTION

Dynamic Starlink access exposes ABR controllers to changing throughput, latency, volatility, and handovers, while static designs struggle to balance severe-stall avoidance against QoE. SafeLink-Agent reframes post-deployment adaptation as verified maintenance for both rule-based and learned controllers.

  • Motivation: Starlink access conditions vary across regions, time, latency, and handovers, exposing ABR streaming to diverse operating profiles.These include stable, low-tail, high-volatility, high-latency, and handover-heavy conditions.
  • Motivation: Existing rule-based and learned ABR controllers are difficult to adjust after deployment when newly observed profiles expose failures.Rule-based controllers use fixed rules or parameters, while learned controllers fix policy parameters after training.
  • Motivation: Static high-QoE control can cause severe stalls on hard profiles, whereas conservative control can sacrifice resolution on stable profiles.The deployment gap is therefore a tradeoff between severe-session risk and video quality.
  • SafeLink-Agent: SafeLink-Agent mines replay evidence, summarizes failures, proposes localized patches with an LLM-based agent, and commits them only after replay verification.Verification checks target-profile improvement without unacceptable regression.
  • SafeLink-Agent: SafeLink-Agent provides a unified patch-and-verify workflow for rule-based and learned ABR controllers.It produces profile-conditioned configuration patches for BOLA and RobustMPC, and verified runtime-auditing patches for SABR, Pensieve, and Comyco.
  • Evaluation: Experiments evaluate agentic maintenance across diverse controller types and newly observed real-Starlink profile scenarios.The reported results show reduced severe-session failures while avoiding QoE loss.

C. Organization

The paper reviews dynamic-network ABR and LLM-based system maintenance before formulating Starlink ABR as a replay-based controller-maintenance problem. Starlink profiles summarize measured operating conditions, while regression memory preserves previously acceptable behavior for later checks.

  • II. RELATED WORK: Related work covers ABR control under dynamic networks and LLM agents for system maintenance and program repair.The two lines motivate SafeLink-Agent's application domain and maintenance approach.
  • II. RELATED WORK: Existing ABR research mainly designs, trains, or generalizes controllers before deployment rather than repairing deployed policies after hard profiles appear.Chunk-level online adaptation typically does not repair the controller's rules, policy, or safety mechanism.
  • II. RELATED WORK: ABR maintenance requires constrained controller changes evaluated on newly exposed failures and previously stable playback behavior.A patch may mitigate failures on one profile while reducing QoE or introducing stalls elsewhere.
  • III. FORMULATION: The formulation defines Starlink profiles, replay-based evaluation, controller updates, and verifier constraints for deciding patch commitment.These components specify what SafeLink-Agent can change and how candidate patches are judged.
  • A. Starlink Profiles: A Starlink profile groups measured replay sessions sharing recurring operating conditions or failure modes, including low-tail, high-volatility, high-latency, and frequent-handover cases.Each profile is represented as a set of measured replay sessions and summarized by metadata.
  • A. Starlink Profiles: Profile metadata include mean throughput, 5th-percentile throughput, throughput volatility, mean latency, and handover intensity.These descriptors help distinguish the environments in which controllers are replayed.
  • A. Starlink Profiles: Regression memory retains representative sessions from previously validated profiles so later maintenance decisions can protect stable playback behavior.It records previously acceptable behavior for comparison during subsequent updates.

B. Replay-Based Controller Evaluation

Replay evaluation measures controller behavior on measured Starlink sessions, exposing both playback outcomes and diagnostic logs for maintenance. The resulting interface supports profile-level comparison and versioned controller updates across rule-based, learned, and risk-aware controllers.

  • Replay evaluation executes a controller over a measured Starlink throughput sequence and returns session-level outcomes.The interface exposes aggregate QoE and logs needed for failure mining and regression checking.
  • QoE, cumulative rebuffering, and replay logs capture playback quality, stall duration, controller actions, buffer states, and diagnostic signals.
  • Profile-level replay aggregates session outcomes to compare controller behavior on newly exposed profiles and regression memory.
  • Controller maintenance represents updates as versioned patches while retaining the current controller as the reference.Controllers may be rule-based, learned, or risk-aware, and patches are applied within an admissible patch space.
  • Patches can alter configurations, add profile-conditioned rules, attach auditors, introduce fallbacks, or update constrained training settings.Patch complexity is limited to keep repairs interpretable and verifiable.

D. Risk Metrics and Verifier Constraints

SafeLink-Agent evaluates patches using severe-session risk, worst-tail rebuffering, QoE cost, regression behavior, and patch complexity. A patch is committed only when replay verification confirms target-profile improvement without unacceptable regression.

  • The verifier first measures severe-session risk and worst-tail rebuffering, then checks target-profile improvement against regression effects.
  • The severe-session ratio counts sessions whose cumulative rebuffering exceeds the severe-stall threshold.
  • Worst-tail rebuffering is computed over the worst α fraction of sessions ranked by cumulative rebuffering within a profile.
  • Verifier constraints require lower severe-session risk and worst-tail rebuffering on the newly exposed profile while limiting its QoE cost.
  • Regression-memory constraints limit new severe-session risk and QoE loss on previously stable profiles, while a final constraint limits patch complexity.Patch commitment occurs only when the candidate satisfies the full constraint set Γ.

IV. SAFELINK-AGENT MAINTENANCE

SafeLink-Agent turns replayed Starlink failures into structured maintenance context, proposes controller patches with an LLM assistant, and relies on replay verification before commitment. The workflow applies to both rule-based and learned controllers while preserving behavior recorded in regression memory.

  • IV. SAFELINK-AGENT MAINTENANCE: Maintenance proceeds through failure summarization, candidate patch generation, schema validation, and verified patch commitment.
  • A. Profile and Failure Mining: Profile and failure mining detects whether a newly observed profile requires maintenance and summarizes failures, hard sessions, and behavior to preserve.
  • A. Profile and Failure Mining: Trigger checks run after replay and use severe-session ratio or worst-tail rebuffering thresholds, with visible QoE regression as auxiliary evidence.
  • A. Profile and Failure Mining: The maintenance context records Starlink properties including throughput tail, volatility, latency, and handover intensity, alongside aggregate controller failure evidence.
  • A. Profile and Failure Mining: Detailed replay logs identify severe-stall and worst-tail session sets for inspection by the proposer and later verification.
  • B. Agentic Patch Proposer: An LLM-based proposer maps profile summaries, failure evidence, patch history, and controller metadata to structured patches with bounded operations and parameters.

C. Patch Schema Validation

Schema validation filters candidate patches before replay verification, which separately tests target-profile repair and preservation of previously validated behavior. The process evaluates patches on identical measured traces to isolate their behavioral effects.

  • C. Patch Schema Validation: Candidate patches may contain unsupported types, unknown fields, invalid activation conditions, or out-of-range parameters.
  • C. Patch Schema Validation: Schema validity requires matching the controller-specific schema, approved operation and activation fields, admissible parameter ranges, and the complexity bound.
  • C. Patch Schema Validation: Invalid candidates produce schema-violation records stored in Patch History, while valid candidates proceed to replay verification.
  • D. Replay Verification and Patch Commit: Replay verification uses target-profile replay to test repair and regression-memory replay to test preservation of validated behavior.
  • D. Replay Verification and Patch Commit: A lightweight target-profile probe can screen ineffective proposals, but only full target replay proceeds to the complete verification checks.
  • D. Replay Verification and Patch Commit: Full replay evaluates current and patched controllers on the same target traces, checking reductions in severe-session risk and worst-tail rebuffering while limiting QoE cost.

2) Regression-Memory Replay:

Regression-memory replay checks whether a candidate patch improves the newly exposed profile without damaging previously acceptable playback behavior. SafeLink-Agent validates, replays, and either commits or rejects patches using explicit verifier checks.

  • Regression-Memory Replay: Regression-memory replay tests candidate patches on profiles whose playback behavior should be preserved, distinguishing local repair from global retuning.A patch can reduce stalls on the target profile yet be rejected if it worsens QoE or severe-session risk in regression memory.
  • Regression-Memory Replay: The verifier limits both severe-session risk increases and QoE regression on regression-memory profiles.These checks instantiate the regression-memory block of the verifier constraints.
  • Maintenance Procedure: SafeLink-Agent accepts a patch only after schema validation, target-profile replay, and regression-memory replay satisfy the verifier constraints.Rejected patches are retained in Patch History with machine-readable reasons, while accepted patches update the controller version.
  • Maintenance Procedure: The maintenance procedure outputs the updated controller version and a replay-verifier report.If no maintenance trigger occurs or validation fails, the current controller is retained.

2) Starlink Profile Construction:

The evaluation organizes replayable Starlink traces into profiles that represent deployment stages and hard access conditions. Controllers are compared under static, conservative, and verified profile-conditioned maintenance variants for both rule-based and learned ABR systems.

  • Starlink Profile Construction: A Starlink profile is a batch of replay sessions grouped by region, time, throughput tail, volatility, latency, and satellite-change metadata.Profiles include initial, calibration, future-test, high-volatility, low-tail, and high-latency conditions.
  • Starlink Profile Construction: Regression memory contains stable traces and representative sessions whose previously acceptable playback behavior should remain protected during later maintenance.It is checked only to detect damage to previously safe operating conditions.
  • Controllers and Variants: SafeLink-Agent selects verified profile-conditioned patches, whereas static variants apply one default or conservative configuration across profiles.The rule-based branch includes BOLA and RobustMPC; the learned branch includes SABR, Pensieve, and Comyco.
  • Controllers and Variants: Learned-controller maintenance attaches a policy-agnostic runtime auditor after the learned policy and compares No auditor, Static auditor, and Adaptive auditor modes.The Adaptive auditor conditions its guard on failure context such as low buffer or high-risk link states.
  • Verifier Constraints: Rule-based patches require target-profile risk reduction and bounded QoE loss, while learned auditor patches impose severe-risk, tail-risk, QoE-cost, and audit-rate constraints.The rule-based target QoE loss bound is 8%; learned-controller bounds are 3% for SABR and 5% for Pensieve and Comyco.

4) Evaluation Metrics:

The evaluation measures average QoE, cumulative rebuffering, severe-session risk, worst-tail rebuffering, QoE loss, audit rate, and verifier decisions across static and maintained controllers. Results show profile-conditioned maintenance reduces severe risk while limiting QoE regressions, with learned adaptive auditing adding a risk–QoE–audit tradeoff.

  • Evaluation Metrics: Severe-session risk is the fraction of replay sessions whose cumulative rebuffering exceeds 10 s.The evaluation also reports average QoE and mean cumulative rebuffering.
  • Rule-Based Controller Maintenance: RobustMPC’s severe-session ratio falls from 2.60% to 0.40% with SafeLink-Agent, while target-profile QoE loss falls from 2.35% to 1.68% versus Static conservative tuning and regression-memory QoE loss reaches 0.00%.SafeLink-Agent achieves 92.8% of Static conservative tuning’s severe-risk reduction.
  • Learned Controller Maintenance: Learned-controller severe-session ratios decrease under Adaptive auditing to 11.01% for SABR, 10.13% for Pensieve, and 8.22% for Comyco.Adaptive auditing usually lowers severe-session risk and mean rebuffering, but can increase audit rate and reduce QoE relative to Static auditing.
  • Rolling Maintenance: Rolling maintenance ends with seven cumulative severe sessions for SafeLink-Agent versus 45 for Static default and four for Static conservative.SafeLink-Agent remains close to the verifier upper bound of nine severe sessions while using profile-conditioned patches.

E. Handover-Heavy Starlink Stress Test

Handover-heavy Starlink periods amplify severe-session risk, while SafeLink-Agent reduces that risk without the regression cost of a globally conservative controller. Verification and regression memory jointly determine whether proposed repairs are safe to commit.

  • Handover-heavy split: 521 handover-heavy sessions and 1213 normal sessions are identified using the top 30% of non-regression sessions by primary candidate-satellite changes.Candidate-satellite changes serve as a proxy for serving-satellite changes.
  • Stress-test result: 4.22% severe-session ratio on handover-heavy sessions versus 1.90% on normal sessions shows that mobility-heavy periods amplify RobustMPC’s severe-session tail.The comparison uses the Static default controller.
  • Stress-test result: 0.96%: SafeLink-Agent reduces the handover-heavy severe-session ratio from 4.22%, while the Static conservative baseline reaches 0.58% at lower QoE.The handover-heavy QoE operating points are 93.39 for SafeLink-Agent and 92.84 for the Static conservative baseline.
  • Regression protection: SafeLink-Agent keeps regression-memory QoE loss at zero, unlike the Static conservative configuration, which introduces QoE loss on previously stable profiles.The maintenance patch therefore avoids turning the entire controller into a globally conservative version.
  • Replay verification: Full replay rejects RobustMPC patches that pass a small probe when severe-session ratios remain above verifier constraints on high-latency and low-tail profiles.The probe passes on all four profiles, but full replay changes the decision.
  • Regression memory: Regression memory changes the accepted patch: for BOLA, a target-only patch cuts target risk from 0.63% to 0.23% but causes 8.05% QoE regression on memory profiles.SafeLink-Agent instead accepts a less aggressive memory-aware patch that retains target improvement and zero memory QoE loss.
  • Acceptance logic: Removing full replay verification or regression-memory replay can produce unsafe or unnecessarily regressive patch acceptance.Both checks affect the final maintenance decision rather than serving only as reporting mechanisms.

G. Hard Trace Mechanism Case Study

A hard low-tail learned-controller trace shows how verified auditing changes bitrate and buffer behavior without replacing the underlying policy. Adaptive auditing stays below the severe-session threshold and improves session-level outcomes relative to static auditing.

  • Case-study setup: The case study compares the original learned controller, a verified Static auditor, and SafeLink-Agent’s Adaptive auditor on one low-tail OSN trace.The original policy produces repeated large rebuffering events on the selected hard session.
  • Capacity estimation: Both auditors identify a long mid-session low-capacity interval and a second late capacity drop, which make high bitrate admissions risky.The safe-capacity estimates expose the conditions associated with severe rebuffering.
  • Buffer trajectory: Audited rollouts build more buffer before the early hard interval, keeping cumulative rebuffering much lower than the unaudited rollout at the same chunks.The unaudited rollout remains near startup-buffer level during the early difficult period.
  • Rebuffering outcome: 4.19 s: the Adaptive auditor ends below the 10-s severe-session threshold, versus 13.26 s for Static auditing and 44.85 s without auditing.The Adaptive auditor turns the same hard trace into a non-severe session.
  • Session metrics: 33.33% intervention rate and 4.19 s total rebuffering: Adaptive auditing improves over Static auditing’s 29.17% and 13.26 s, respectively.Maximum single-chunk rebuffering falls from 7.25 s to 2.59 s, while QoE rises from 1969.76 to 2224.30.
  • Mechanism: The learned-controller patch acts as a targeted runtime auditor, preserving the original policy while correcting a small set of risky decisions.The auditor uses low buffer or low safe capacity to identify risky bitrate requests.
  • Robustness across thresholds: 39.01% to 9.79%: verified Adaptive auditing lowers the learned controllers’ average severe-session ratio at the 10-s threshold.The ordering remains stable when the severe-session threshold varies from 5 s to 15 s and the worst-tail fraction from 1% to 10%.
  • Aggregate results: SafeLink-Agent reduces RobustMPC’s severe-session ratio from 2.60% to 0.40% and cumulative severe sessions from 45 to 7 in rolling maintenance.The conclusion reports corresponding improvement for learned controllers from 39.01% to 9.79%.

A. Structured Prompt Context

The structured prompt context supplies compact replay, controller, patch, verifier, regression-memory, and history information to an agentic proposer. The template constrains proposals to bounded, approved, localized patches returned in a structured record.

  • A. Structured Prompt Context: Structured prompt context combines compact replay statistics, controller metadata, patch schemas, verifier constraints, regression memory, and Patch History.Patch History is updated with accepted or rejected patches and verifier feedback across proposal rounds.
  • B. Prompt Template: DeepSeek-V4-Pro receives a system instruction, structured context, patch schema, verifier constraints, and output-format requirement in each proposal round.The same template is reused while Patch History supplies prior replay-verification feedback.
  • B. Prompt Template: The system instruction limits the proposer to schema-allowed candidate patches and excludes per-chunk bitrate actions.This defines the proposer as a maintenance component rather than a direct bitrate-action generator.
  • B. Prompt Template: The task asks for one patch that reduces severe sessions on a new Starlink profile while avoiding QoE regression on memory profiles.The requested output is a maintenance proposal grounded in replay evidence.
  • B. Prompt Template: Proposal constraints require approved patch types, bounded parameters, target-profile risk and QoE limits, regression-memory limits, and localized repairs.The proposer must also explain expected target improvement and risk.
  • B. Prompt Template: The proposer returns one candidate patch and rationale, rather than a sequence of per-chunk control actions.The output format keeps generation aligned with controller maintenance.
  • C. Patch Records: The JSON-like patch record names the controller, activation condition, allowed operation, and bounded parameters.The record structure is used across the controller classes considered in the paper.
  • C. Patch Records: Malformed RobustMPC records, unsupported operations, or parameter-bound violations are rejected before replay.Required fields are validated before a candidate reaches replay verification.
Loading 2608.28194v1…