天地一体化网络是未来通信体系的重要方向，它把高轨（GEO）卫星、低轨（LEO）卫星与地面系统串联成一个整体。高轨卫星站得高、看得远，单颗星就能覆盖近三分之一的地球表面，但往返时延动辄几百毫秒；低轨卫星离地面近，时延可以压到几十毫秒以内，可它的运动速度快，对一个地面站的可见时间往往只有几分钟。这种互补特性决定了协同传输调度的价值：把时延敏感的业务交给低轨，把持续性强、带宽需求稳定的业务放在高轨上。本文用R语言来搭建一个仿真框架，把这个问题从建模到求解完整走一遍。
一、问题建模：从卫星可见性到链路指标
做调度之前，首先要回答两个基础问题：某个时刻哪些卫星对地面站可见，以及每条可用链路的时延和容量是多少。可见性在仿真层面可以简化为仰角判断，给定地面站经纬度和卫星轨道根数，计算出卫星相对地面站的仰角，大于某个门限（通常取10度）即认为链路可用。
在R中，用数据框来组织这些信息非常自然。我们可以把每个仿真时隙内所有可用链路列成一张表，每一行代表一条候选链路，包含卫星类型、时延、可用容量等字段。这种长格式的数据结构后续可以直接用dplyr进行筛选和聚合，比用嵌套列表管理要清爽得多。
下面是一段生成基础链路数据的示例代码，高轨链路时延固定，低轨链路时延随可见窗口内的几何距离变化：
library(dplyr)
set.seed(42)
slots <- 1:60 # 仿真时隙，每时隙10秒
# 低轨卫星可见性窗口：假设3颗低轨星，每颗有若干可见窗口
leo_windows <- data.frame(
sat = rep(c("LEO-1", "LEO-2", "LEO-3"), each = 20),
start = c(1, 25, 45, 5, 30, 50, 10, 35, 55),
end = c(18, 40, 60, 22, 46, 60, 30, 52, 60)
)
gen_links <- function() {
do.call(rbind, lapply(seq_len(nrow(leo_windows)), function(i) {
w <- leo_windows[i, ]
t <- w$start:w$end
# 时延随窗口推进先降后升，模拟距离变化
delay <- 20 + 15 * abs(t - (w$start + w$end) / 2) / ((w$end - w$start) / 2)
data.frame(slot = t, sat = w$sat, type = "LEO",
delay_ms = round(delay, 1), capacity_mbps = 200)
}))
}
geo_links <- data.frame(slot = slots, sat = "GEO-1", type = "GEO",
delay_ms = 280, capacity_mbps = 500)
links <- rbind(gen_links(), geo_links) %>% arrange(slot, type)
head(links)这段代码的核心思路是把时变的链路状态离散化到时隙上。实际项目中，如果你有真实的轨道数据（比如TLE文件），可以用asteRisk包做轨道递推，把上面手工构造的窗口换成真实计算结果，整个调度框架不需要改动。
二、调度模型：多目标权衡的形式化表达
有了链路数据，调度问题就可以形式化了。设业务流集合为F，每个业务流有到达速率、时延要求和持续时长；设时隙集合为T，链路集合为L。决策变量x(f,t,l)取1表示时隙t内业务流f使用链路l。目标函数通常是加权形式：最大化总吞吐量，同时惩罚切换次数和时延超标。切换指的是相邻时隙之间业务流更换服务卫星，低轨窗口结束被迫切到高轨属于正常行为，但频繁在两颗低轨星之间来回倒换则是需要抑制的。
约束条件主要有三类：一是容量约束，同一时隙同一链路上所有业务流的速率之和不能超过链路容量；二是唯一性约束，一个业务流在一个时隙只能使用一条链路；三是业务约束，比如话音类业务要求单时隙时延不超过50毫秒，这意味着它在多数时刻只能选低轨链路或者干脆缓存等待。
写成数学形式如下：
max Σ_f Σ_t Σ_l w1 * r(f) * x(f,t,l)
- w2 * Σ_f Σ_t switch(f,t)
- w3 * Σ_f Σ_t Σ_l delay(l) * x(f,t,l)
s.t. Σ_f r(f) * x(f,t,l) <= cap(l,t) ∀ t, l
Σ_l x(f,t,l) <= 1 ∀ f, t
delay(l) * x(f,t,l) <= D_max(f) ∀ f∈话音, t, l
x(f,t,l) ∈ {0, 1}这是一个整数规划问题，规模一大就很难精确求解。在实际仿真中，更常用的做法是贪心启发式：每个时隙开始时，先给时延敏感的业务分配低轨链路，剩余容量给尽力而为的业务，如果低轨容量不够则溢出到高轨。这种方法虽然不保证全局最优，但计算复杂度是多项式级的，适合做大规模场景的对比实验。
三、贪心求解的R实现与结果可视化
下面给出贪心调度的完整实现。函数的输入是前文构造的链路表和业务流表，输出是逐时隙的分配结果。代码中用dplyr的管道操作把筛选、排序、容量扣减串起来，逻辑清晰且容易扩展新的业务类型。
flows <- data.frame(
flow = c("voice-1", "voice-2", "video-1", "besteffort-1"),
rate_mbps = c(2, 2, 50, 120),
delay_req_ms = c(50, 50, 150, 600), # 时延上限
stringsAsFactors = FALSE
)
schedule_greedy <- function(links, flows) {
result <- list()
for (t in unique(links$slot)) {
avail <- links %>% filter(slot == t)
remaining <- avail$capacity_mbps
names(remaining) <- avail$sat
# 时延要求紧的业务优先分配
prio <- flows %>% arrange(delay_req_ms)
picks <- c()
for (i in seq_len(nrow(prio))) {
f <- prio[i, ]
cand <- avail %>% filter(delay_ms <= f$delay_req_ms)
if (nrow(cand) == 0) next
# 优先选时延最低的可用链路
cand <- cand %>% arrange(delay_ms)
ok <- FALSE
for (j in seq_len(nrow(cand))) {
s <- cand$sat[j]
if (remaining[s] >= f$rate_mbps) {
remaining[s] <- remaining[s] - f$rate_mbps
picks <- rbind(picks, data.frame(slot = t, flow = f$flow, sat = s))
ok <- TRUE; break
}
}
if (!ok) next # 本时隙丢弃，统计为未满足需求
}
result[[as.character(t)]] <- picks
}
do.call(rbind, result)
}
alloc <- schedule_greedy(links, flows)
table(alloc$flow, alloc$sat)从输出的交叉表可以直观看到，两条话音业务几乎全程占用低轨链路，视频业务在低轨容量富余时用低轨、窗口间隙切换到高轨，而尽力而为业务大部分时间在高轨上跑。这正是我们期望的协同行为。
可视化方面，用ggplot2画一张甘特式的调度图效果最好，横轴是时隙，纵轴是业务流，颜色区分服务卫星。再配合一条高轨低轨切换次数的折线，就能定量评估w2这个惩罚权重取值对切换行为的影响。做参数扫描时，建议用purrr包的map函数把不同权重组合批量跑一遍，整理成数据框后画热力图，比手动循环优雅得多。
library(ggplot2)
ggplot(alloc, aes(x = slot, y = flow, fill = sat)) +
geom_raster() +
scale_fill_manual(values = c("GEO-1" = "#E69F00",
"LEO-1" = "#56B4E9",
"LEO-2" = "#009E73",
"LEO-3" = "#CC79A7")) +
labs(x = "时隙", y = "业务流", fill = "服务卫星") +
theme_minimal()四、方法局限与改进方向
贪心方案的短板在于缺乏前瞻性。低轨可见窗口是提前可以预测的，如果某个业务流马上要遭遇窗口结束，理想的做法是提前几个时隙就开始向高轨预热，而不是等到断链那一刻才仓促切换。改进思路是把决策窗口拉长，做滚动时域优化：每K个时隙求解一次小规模的整数规划，可以用ompr包配合GLPK求解器实现，规模可控时求解时间完全可接受。
另一个值得投入的方向是把R的仿真结果与真实系统联动。R擅长的是快速原型和统计实验设计，可以先用它跑清楚调度策略的参数空间，再用性能语言重写策略引擎。整个流程中R负责的部分——数据处理、模型验证、结果可视化——恰恰是它的强项，这也是为什么在天地一体化网络这类研究型项目中，R仍然是值得优先考虑的工具。此外，如果业务到达具有随机性，还可以在R里用队列模型叠加随机到达过程，评估不同负载水平下的丢包率和时延分位数，让仿真结论更接近实际部署场景。