PaperlayerView exact revision on arXiv

Source-linked AI summary

SFC-Aware Online Aggregated Data-Link Orchestration for SDN/NFV-Enabled SAGINs

Ziyang Guo, Bing Du

arXiv:2608.26559v1cs.NI

TL;DR

Civil aviation SAGINs need online access orchestration across dynamic heterogeneous A2A, A2G, and A2S links while meeting SFC-aware service requirements. The paper combines spatial bearer allocation with TEMP in a four-action lexicographic rolling model and develops MRSAR as a lower-cost approximation. Simulations show MRSAR stays close to Gurobi-MILP in service success, outperforms two greedy baselines, controls failures, and offers a favorable quality-complexity tradeoff.

  • Problem

    Dynamic heterogeneous A2A, A2G, and A2S links make request-level SFC-aware access orchestration nontrivial, while full-chain remapping is costly for online control.

  • Method

    The paper jointly orchestrates aggregated bearer resources and TEMP using a four-action lexicographic rolling model and MRSAR risk-scarcity refinement.

  • Results

    MRSAR remains close to the Gurobi-MILP reference in service success, outperforms arrival-order and delay-myopic greedy baselines, controls REJECT and DROP failures, and achieves a favorable quality-complexity tradeoff.

  • Takeaways & Limitations

    TEMP acts as a managed temporal resource, while model-induced risk and scarcity signals support interpretable rolling orchestration at lower computational cost than direct MILP solving.

Abstract

from arXiv · show

Civil aviation space-air-ground integrated networks (SAGINs) are expected to support heterogeneous cockpit and cabin services over dynamic air-to-air (A2A), air-to-ground (A2G), and air-to-satellite (A2S) data links. This paper studies service function chain (SFC)-aware online access-side aggregated data-link orchestration for civil aviation SAGINs enabled by software-defined networking and network function virtualization (SDN/NFV). We jointly orchestrate spatial bearer resources and temporal elasticity enabled by temporal elastic mapping and parking (TEMP). A rolling-slot model is developed with four request-level actions: NOW, TEMP, REJECT, and DROP, under a lexicographic objective that prioritizes service success, then normalized access-orchestration delay, and finally residual TEMP-related risk. To avoid exhaustive search over the full binary action space, we propose Model-Induced Risk and Scarcity-Aware Refinement (MRSAR), which derives deferred-realization risk from the success-prioritized objective and resource-scarcity signals from data-link and TEMP buffer constraints. These signals guide valuation-based feasible construction and bounded neighborhood refinement. Simulation results show that MRSAR remains close to the Gurobi-MILP reference in service success, outperforms arrival-order and delay-myopic greedy baselines, controls REJECT and DROP failures, and achieves a favorable quality-complexity tradeoff for rolling online orchestration.

I. INTRODUCTION

The paper frames civil aviation SAGIN access orchestration as a request-level problem over heterogeneous A2A, A2G, and A2S links, combining immediate service with temporally deferred realization. It formulates a success-prioritized rolling model and proposes MRSAR to make online decisions without exhaustive search.

  • Civil aviation SAGINs must support heterogeneous services over rapidly varying A2A, A2G, and A2S links.
  • The paper focuses on SFC-aware access orchestration: selecting an access anchor, aggregated bearer mode, and request action rather than remapping complete service chains.
  • TEMP treats onboard storage as a schedulable temporal resource so requests may exploit future link opportunities within delay budgets.
  • The rolling optimization chooses NOW, TEMP, REJECT, or DROP under constraints covering bearer capacity, TEMP buffering, residence, future realization, and QoS delay.
  • MRSAR derives risk and scarcity signals from the optimization model to construct feasible actions and refine them in bounded neighborhoods at lower cost than exhaustive solving.
  • Simulation results show MRSAR remains close to Gurobi-MILP in QoS success, beats arrival-order and delay-myopic baselines, controls REJECT and DROP failures, and scales better.

B. SDN/NFV-Enabled SFC Orchestration

The framework uses SDN/NFV to abstract heterogeneous communication opportunities into unified anchor–bearer candidates for SFC-aware access decisions. It preserves service awareness while avoiding repeated full-chain remapping in dynamic rolling control.

  • Full SFC remapping is costly for fine-grained civil aviation control, so the paper targets the access-side bottleneck before service-domain entry.
  • The controller collects topology, link, capacity, delay, and TEMP states, then translates rolling decisions into configurations for selected anchors and bearer modes.
  • A2A, A2G, and A2S opportunities are represented as aggregated bearer resources rather than isolated physical technologies.
  • An anchor–bearer pair jointly identifies the selectable SFC access anchor and the A2A/A2G/A2S bearer mode used for admission.
  • Candidate states are screened for reachability, service compatibility, capacity, availability, and access-delay feasibility.
  • Service templates or preconfigured domains maintain the function-chain sequence while online orchestration selects the access entry point.

C. TEMP-Assisted Rolling Access Orchestration

The rolling orchestration process jointly allocates current spatial bearer resources and preserves temporally promising requests. Each pending request receives one of four actions subject to request type, feasibility, capacity, and residence constraints.

  • TEMP provides controlled temporal elasticity for requests that lack an immediate bearer but may become feasible after mobility, visibility, or contention changes.
  • At each slot, newly arrived and carried-over requests form the active set, and each receives exactly one action from NOW, TEMP, REJECT, or DROP.
  • The model couples heterogeneous bearer allocation with TEMP decisions governed by look-ahead opportunities, residence limits, and buffer pressure.
  • NOW realizes feasible requests immediately, while TEMP carries them forward with updated residence state for possible future realization.
  • Current candidate feasibility depends on reachability, service compatibility, and access-orchestration delay, alongside shared bearer-capacity competition.
  • REJECT applies to newly arrived requests, whereas DROP releases carried-over TEMP requests that can no longer be legally preserved.

B. Deferred-Realization Action: TEMP

TEMP defers realization over a finite look-ahead window using predicted future anchor–bearer opportunities and their realization probabilities. Its expected completion delay is evaluated conditionally on successful realization and is omitted when realization is infeasible.

  • TEMP retains a request for future service when a suitable anchor–bearer opportunity is predicted within its access-delay budget.
  • The prediction window contains the future slots t + 1 through t + Wpred.
  • Future candidate sets contain anchor–bearer pairs predicted to be reachable and service-compatible at each future slot.
  • Predicted TEMP completion delay combines accumulated residence and waiting with future queueing, transmission, and propagation delays.
  • Conditional realization probabilities are set to zero when delay or predicted residual-capacity conditions are violated.
  • TEMP realization probability aggregates single-slot and first-realization probabilities across the look-ahead window, while zero probability makes TEMP infeasible.

C. Decision Variables

The model encodes four mutually exclusive request actions and enforces feasibility across access capacity, TEMP buffering, realization probability, and residence limits.

  • Binary encoding: NOW assignments are represented by anchor–bearer variables, while TEMP, REJECT, and DROP use separate request-level indicators.The auxiliary NOW indicator represents deterministic realization under the action and feasibility constraints.
  • Request actions: Each request selects exactly one action: NOW, TEMP, REJECT, or DROP.NOW serves immediately; TEMP preserves a request for future realization; REJECT applies to new requests, and DROP releases carried-over TEMP requests.
  • Resource constraints: NOW consumes current anchor–bearer capacity, whereas TEMP consumes buffer space and relies on future bearer opportunities.REJECT and DROP consume neither current data-link bearer capacity nor immediate bearer resources.
  • TEMP feasibility: TEMP is allowed only when predicted realization probability and residence-time requirements are satisfied.The constraints use a minimum acceptable realization probability and a request-specific maximum TEMP residence limit W_max_r.
  • Resource constraints: TEMP occupancy on each aircraft cannot exceed its buffer capacity.The capacity parameter M_i denotes aircraft i’s TEMP buffer capacity.

E. Lexicographic Service Objective

The service objective uses lexicographic priorities: maximize expected realization first, minimize normalized access-orchestration delay second, and control residual TEMP-related risk third.

  • Objective hierarchy: The model first maximizes expected service realization, then optimizes delay and risk without degrading higher-priority objectives.The three layers are optimized sequentially, preserving the optimal value of each preceding layer.
  • First layer: realization: The first layer combines deterministic NOW realization with probability-weighted TEMP realization benefit.NOW contributes deterministic realization, while TEMP contributes according to its realization probability.
  • Second layer: delay: The second layer minimizes expected normalized access-orchestration delay after expected service realization is fixed.Normalization makes requests with different delay budgets comparable, while the priority ordering prevents delay reduction from sacrificing realization.
  • Third layer: risk: The third layer controls DROP, TEMP residence urgency, and post-decision TEMP buffer utilization.It targets residual risks from dropped requests, prolonged residence, and buffer pressure after the first two layers are protected.
  • Computational implication: The resulting formulation is a lexicographic MILP, but repeated full action-space optimization is computationally expensive for rolling online control.The model jointly represents spatial bearer opportunities and temporal elasticity through TEMP.

V. MRSAR ALGORITHM

MRSAR approximates the lexicographic MILP by deriving request-risk and resource-scarcity signals from its objective and constraints, then using them in bounded refinement.

  • Algorithm overview: MRSAR constructs feasible rolling-slot solutions through ranked NOW and TEMP candidates followed by bounded, feasibility-preserving neighborhood search.This avoids directly solving the full MILP at every slot while retaining its objective hierarchy and feasibility structure.
  • Risk signals: Deferred-realization risk comes from the difference between deterministic NOW benefit and probability-weighted TEMP benefit in the first objective layer.A larger request-risk value indicates greater potential loss if service is deferred rather than provided through NOW.
  • Algorithm inputs: TEMP realization probability and conditional expected delay are precomputed inputs to MRSAR.Residual bearer and buffer capacities are updated during construction and refinement after initial scarcity computation.
  • Risk signals: TEMP residence urgency increases as postponement becomes less desirable after another preserved slot.Residence urgency is combined with deferred-realization risk to form a broader request-risk signal.
  • Scarcity signals: Data-link and TEMP-buffer scarcity indicators measure opportunity costs created by shared capacity and limited onboard storage.Data-link scarcity rises when more requests share a resource or when less capacity remains; buffer scarcity is computed for each aircraft.

B. Candidate Action Valuation and Feasible Solution Construction

MRSAR converts model-derived risk and scarcity into candidate valuations, builds a feasible solution in NOW-first order, and then permits bounded local improvements.

  • Candidate valuation: NOW valuation rewards postponement risk reduced per unit of scarce bearer resource while accounting for normalized access-orchestration delay.The delay coefficient α_d controls the NOW delay component.
  • Candidate valuation: TEMP valuation favors promising future realization, limited buffer occupation, moderate expected delay, and sufficient remaining residence time.The TEMP delay and residence-urgency coefficients are β_d and β_h.
  • Feasibility preservation: Valuations estimate relative candidate merit but do not replace the lexicographic objective or feasibility constraints.Assignments remain subject to delay, capacity, residence, buffer, and request-type checks.
  • Feasible construction: MRSAR ranks feasible NOW candidates by descending valuation, accepts capacity-feasible assignments, and updates residual bearer capacity.Unassigned requests retain their remaining candidate options only until an assignment is accepted.
  • Feasible construction: After NOW construction, remaining TEMP-feasible requests are ranked by TEMP valuation and retained when residual aircraft buffer capacity is sufficient.Unassigned new requests become REJECT, while unassigned carried-over TEMP requests become DROP.
  • Initialization and refinement: NOW is prioritized during initialization because it provides deterministic realization, although refinement may replace it when a local modification improves the hierarchy-weighted gain.The construction produces a complete feasible solution without enumerating the full binary action space.

C. Model-Structured Neighborhood Refinement

MRSAR refines feasible request assignments through coordinated Rescue, Rebind, and Exchange moves while preserving the model’s lexicographic objective hierarchy. It accepts only feasible, positively improving moves within a bounded neighborhood.

  • Neighborhood structure: MRSAR organizes each request’s NOW, TEMP, REJECT, and DROP variables as a mutually exclusive action block.Shared bearer-capacity and TEMP-buffer constraints couple these request blocks.
  • Move types: Rescue moves promote TEMP, REJECT, or DROP assignments to feasible NOW actions, or REJECT/DROP assignments to feasible TEMP actions.
  • Move types: Rebind replaces a NOW request’s anchor–bearer pair, while Exchange jointly modifies two assignments to resolve shared-resource competition.Only moves satisfying all model constraints enter the feasible neighborhood.
  • Objective-guided refinement: The move gain preserves lexicographic priorities by rewarding service-realization improvement and penalizing normalized delay and DROP/TEMP-related risk.Hierarchy weights Ω1 ≫ Ω2 ≫ 1 approximate the objective ordering.
  • Selection and termination: At each iteration, MRSAR selects the highest-gain feasible move and terminates when no feasible move remains or the best gain is nonpositive.The bounded iteration process yields a locally improved feasible solution.

D. Overall MRSAR Procedure

The overall online procedure combines precomputed TEMP look-ahead quantities with online risk, scarcity, valuation, feasible construction, and bounded refinement. This replaces repeated full MILP solving with a lower-cost rolling decision process whose complexity is analyzed in terms of active requests, candidates, moves, and feasibility checks.

  • Online procedure: MRSAR uses precomputed TEMP realization quantities and performs request-risk, scarcity, valuation, feasible-construction, and neighborhood-refinement steps online.The initial construction applies a NOW-first rule, a smaller-data-volume tie breaker, and explicit feasibility checking.
  • Complexity parameters: The procedure retains at most amax NOW candidates per request and evaluates at most mv neighborhood moves per refinement iteration.The incremental cost of checking one local move is denoted cloc.
  • Complexity analysis: Candidate valuation and sorting contribute the construction cost, with TEMP candidate sorting bounded by O(nact(t) log nact(t)).
  • Complexity analysis: Incremental maintenance of residual capacities, buffer occupancies, actions, and objective components supports feasibility and gain evaluation during refinement.
  • Scope of analysis: The complexity analysis excludes TEMP look-ahead computation because those quantities are treated as precomputed inputs.MRSAR instead replaces repeated full MILP solving with valuation, feasibility-preserving construction, and bounded local refinement.

VI. SIMULATION EVALUATION

The evaluation uses a trace-driven rolling simulation of a high-density trans-Atlantic civil-aviation SAGIN with dynamic heterogeneous links, services, loads, and compared orchestration methods. Results assess success, delay, failures, TEMP utilization, scalability, and related behavior across traffic conditions.

  • Experimental setting: The simulation models 513 commercial aircraft, 66 Iridium satellites, and 20 ground gateways with regenerated A2A, A2G, and A2S connectivity.
  • Experimental setting: Traffic includes delay-sensitive cockpit services and bandwidth-intensive cabin services over low-rate safety and broadband data-link technologies.Examples include VoIP-Safety, CPDLC, ADS-B/C, passenger VoIP, Web, and video sessions.
  • Experimental setting: The 500-slot simulation uses 0.2-second slots, excludes a 20-slot warm-up, evaluates outcomes over 10-slot arrival windows, and varies load from 0.6 to 1.4.Success requires eventual delivery within the QoS deadline.
  • QoS success: MRSAR remains close to Gurobi-MILP in QoS success and consistently outperforms FCFS-Greedy and MinDelay-Greedy, especially at medium and high loads.The reported success-ratio trend attributes this behavior to model-induced risk and scarcity signals.
  • Delay performance: MRSAR keeps normalized delay near Gurobi-MILP while increasing from about 0.007 to about 0.011 as load rises from ρ = 0.6 to ρ = 1.4.FCFS-Greedy rises from about 0.009 to nearly 0.019 over the same range.
  • Failure decomposition: MRSAR maintains failure levels close to Gurobi-MILP and below both greedy baselines while controlling REJECT and DROP components under increasing load.The failure ratio increases for all algorithms as data-link contention intensifies.
  • TEMP-assisted orchestration: MRSAR’s TEMP utilization rises from about 0.011 to nearly 0.027 as load increases, following Gurobi-MILP more closely than the greedy baselines.Together with controlled failures, this indicates effective deferred realization rather than uncontrolled buffering.

E. Near-Optimality and Runtime Scalability

MRSAR preserves orchestration quality close to the Gurobi-MILP reference while scaling more effectively as request volume grows. Its performance depends strongly on TEMP and bounded risk-scarcity refinement, with finite look-ahead providing diminishing returns.

  • Near-optimality: MRSAR keeps the QoS success-rate gap below about 2 percentage points across request scales, reaching nearly 1–1.3 percentage points in larger cases.
  • Runtime scalability: MRSAR runtime rises from about 0.7 s to 3.2 s as active requests increase, compared with Gurobi-MILP growth from approximately 2.6 s to 10.6 s.
  • Runtime scalability: 3.5–4.0× speedup over Gurobi-MILP is achieved by MRSAR across evaluated request scales, while greedy baselines trade higher speedups for larger QoS-success gaps.
  • Ablation study: Removing TEMP causes the largest ablation degradation, while removing Rescue, Rebind, or Exchange also reduces performance but generally less.
  • TEMP sensitivity: Increasing the TEMP look-ahead window improves the success-oriented objective until gains saturate, while longer windows increase computational overhead.
  • Overall assessment: MRSAR achieves a favorable balance among QoS success, delay control, failure reduction, near-optimality, and runtime scalability by treating TEMP as a schedulable temporal resource.
Loading 2608.26559v1…