38、容迟网络路由方法比较

容迟网络路由方法比较

在容迟网络(DTN)中,路由决策面临着诸多挑战,尤其是在不确定的环境下。本文将介绍两种基于马尔可夫决策过程(MDP)的路由方法:RUCoP 和 LSS,并对它们在不同网络拓扑中的性能进行评估。

1. 网络通信假设

在 DTN 中,我们假设发送节点能够确定传输是否成功。若成功,发送节点会删除已传输的副本;若失败,则保留副本。这种方式被称为确认通信(acknowledged communication),确保网络中副本数量符合预期,在低地球轨道(LEO)星座中较为常见。另一种是完全不可靠通信,传输失败时副本会丢失,常用于深空通信。

2. 全局和局部信息

对于 MDP 描述的系统,最大化调度器可描述最优路由决策,但它基于全局信息,要求分布式节点随时知晓网络中所有副本的位置,这在高度分区的 DTN 中难以实现。因此,节点通常需基于局部知识进行决策,这种问题被称为分布式调度。

3. 不确定 DTN 中的路由方法
3.1 RUCoP

RUCoP(routing under uncertain contact plans)为不确定接触计划下的路由决策提供了分析解决方案,以优化 SDP(Scheduled Delivery Probability)。其主要步骤如下:
1. 构建无环 MDP :由于状态中包含当前时隙值,不确定接触计划的 MDP 是无环的。RUCoP 从目标状态(如 t5 时刻 D 至少有一个副本的状态)开始,根据贝尔曼方程反向构建“最优”部分的 MDP。
2. 处理循环 :考虑到多个节点在一个时隙内相互传输可能产生循环,但循环传输会降低 SDP,因此 RUCoP 会打破所有循环,保持 MDP 无环。
3. 计算复杂度 :完整的 RUCoP 算法时间复杂度为 2 - EXPTIME,运行时间与节点数量呈指数关系,与副本数量呈双指数关系,对时间和内存要求较高。
4. 内存优化 :RUCoP 采用动态构建 MDP 的方式,并将不再需要的信息写入磁盘,仅保留当前时隙的状态用于计算前一个时隙的状态和最优转移。

为了获得基于局部信息的调度器,可使用 L - RUCoP(local RUCoP)。它通过构建表格 T(N, c, ti),为每个节点 N 在时间 ti 持有 c 个副本时提供基于局部知识的最佳决策。

3.2 LSS

LSS(Lightweight scheduler sampling)是一种基于统计模型检查(SMC)的方法,可用于估计 MDP 中可达性问题的概率。其主要步骤如下:
1. 随机选择调度器 :随机选择一组 m 个调度器,每个调度器由一个固定大小的整数(如 32 位)标识。
2. 选择最优调度器 :使用启发式方法(如智能采样)选择似乎能诱导最高概率的调度器 σmax。
3. 估计可达性概率 :对 MDP|σmax 进行标准 SMC 分析,提供 Pr max s0(reach(B)) 的估计值。

LSS 的关键在于将调度器表示为 32 位整数,实现了恒定的内存使用。通过修改输入,LSS 还可适用于局部信息调度器,即 L - LSS。

为了提高 LSS 的性能,我们对其进行了以下改进:
1. 仅保留有用的接触 :分析接触图,去除无用的接触,减少 MDP 中的决策数量和调度器采样空间。
2. 强制发送 :在节点的最后一个有用接触时,强制发送所有可用副本。
3. 强制接收 :省略接收节点忽略传入消息的选项,进一步减少调度器采样空间。
4. 跳过空时隙 :省略空时隙的“时钟滴答”动作,直接跳到下一个有接触的时隙,提高模拟运行时间。

4. 评估

为了评估 RUCoP 和 LSS 的性能,我们创建了包含三种用例的基准集:随机网络、二项式网络和环形道路网络。

4.1 基准集
  • 随机网络 :使用 10 个具有 8 个节点、时长为 100 秒的随机拓扑,时间离散为 10 秒的时段,接触密度参数为 0.2,采用全对全流量模式。
  • 二项式网络 :采用二项式拓扑的接触计划,通过增加树的级别来评估拓扑复杂度对路由算法的影响。
  • 环形道路网络 :使用从高精度轨道传播器导出的现实卫星拓扑,考虑 16 颗低地球轨道卫星组成的 Walker 星座,采用全对一流量模式,场景跨度为 24 小时,划分为 1440 个时隙。
4.2 分析

我们从 SDP 和计算资源(处理时间和内存消耗)两个方面对 RUCoP 和 LSS 进行评估,以单副本 CGR 作为基线。

  • 随机网络 :随着接触计划不确定性增加,RUCoP 和 LSS 方案的 SDP 逐渐优于 CGR。增加采样调度器数量(从 1000 到 10000)对 SDP 的提升有限。L - LSS 在 SDP 方面平均比 L - RUCoP 差 3%(1000 个调度器)和 1%(10000 个调度器)。所有技术在随机网络中的处理时间均小于 20 秒,内存使用小于 20 MB。
技术 SDP 表现 处理时间 内存使用
RUCoP 优于 CGR < 20s < 20MB
LSS - 1000 逐渐优于 CGR < 20s < 20MB
LSS - 10000 略优于 LSS - 1000 < 20s < 20MB
L - RUCoP 优于 L - LSS < 20s < 20MB
L - LSS - 1000 略差于 L - RUCoP < 20s < 20MB
L - LSS - 10000 略差于 L - RUCoP < 20s < 20MB
  • 二项式网络 :在二项式网络中,CGR 基线与 RUCoP - 1 相同。LSS 在使用 10000 个调度器时,SDP 与 RUCoP 接近。随着拓扑复杂度增加(树级别超过 7),RUCoP 会耗尽内存,而 LSS 能以最小的运行时间和内存占用提供有效解决方案。
graph LR
    A[开始] --> B[设置链路失败概率为 0.1]
    B --> C[变化树级别从 4 到 8]
    C --> D[评估 RUCoP 和 LSS 性能]
    D --> E[分析 SDP、处理时间和内存使用]
    E --> F[结束]
  • 环形道路网络 :在环形道路网络中,接触计划越长,RUCoP 和 LSS 的差异越明显。L - RUCoP 在 2 小时和 3 小时的计划中明显优于 L - LSS。LSS 和 L - LSS 在大型调度中表现不如 CGR 基线,表明 LSS 的无信息采样策略可能不适用于现实环形道路拓扑,需要进一步改进。
网络拓扑 技术 SDP 表现 处理时间 内存使用
随机网络 RUCoP 优于 CGR < 20s < 20MB
随机网络 LSS - 1000 逐渐优于 CGR < 20s < 20MB
随机网络 LSS - 10000 略优于 LSS - 1000 < 20s < 20MB
二项式网络 RUCoP 高复杂度下内存耗尽 最长 28min 最高 1GB
二项式网络 LSS - 1000 接近 RUCoP < 10s < 100MB
二项式网络 LSS - 10000 接近 RUCoP 1min < 100MB
环形道路网络 RUCoP 长时间计划表现优 最长 20min 最高 600MB
环形道路网络 LSS - 1000 不如 CGR 基线 < 1min 约 100MB
环形道路网络 LSS - 10000 略优于 LSS - 1000 < 1min 约 100MB

综上所述,RUCoP 在 SDP 方面表现较好,但对时间和内存要求较高;LSS 内存占用小,运行时间短,在简单拓扑中表现接近 RUCoP,但在复杂拓扑中需要进一步改进采样策略。在实际应用中,应根据网络拓扑的复杂度和资源限制选择合适的路由方法。

容迟网络路由方法比较

5. 方法性能总结

为了更清晰地对比 RUCoP 和 LSS 在不同网络拓扑中的性能,我们将上述评估结果总结如下表:
| 网络拓扑 | 技术 | SDP 表现 | 处理时间 | 内存使用 | 适用场景 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| 随机网络 | RUCoP | 优于 CGR,略优于 LSS | < 20s | < 20MB | 对 SDP 要求较高,资源充足 |
| 随机网络 | LSS - 1000 | 逐渐优于 CGR | < 20s | < 20MB | 资源有限,对 SDP 要求不是极高 |
| 随机网络 | LSS - 10000 | 略优于 LSS - 1000 | < 20s | < 20MB | 资源有限,希望进一步提升 SDP |
| 二项式网络 | RUCoP | 低复杂度接近最优,高复杂度内存耗尽 | 最长 28min | 最高 1GB | 低复杂度拓扑,对 SDP 要求极高 |
| 二项式网络 | LSS - 1000 | 接近 RUCoP | < 10s | < 100MB | 高复杂度拓扑,资源受限 |
| 二项式网络 | LSS - 10000 | 接近 RUCoP | 1min | < 100MB | 高复杂度拓扑,希望在资源受限下接近最优 SDP |
| 环形道路网络 | RUCoP | 长时间计划表现优 | 最长 20min | 最高 600MB | 长时间接触计划,对 SDP 要求高 |
| 环形道路网络 | LSS - 1000 | 不如 CGR 基线 | < 1min | 约 100MB | 短时间接触计划,资源受限 |
| 环形道路网络 | LSS - 10000 | 略优于 LSS - 1000 | < 1min | 约 100MB | 短时间接触计划,希望在资源受限下提升 SDP |

从这个表格中可以看出,不同的网络拓扑和资源条件下,RUCoP 和 LSS 各有优劣。在选择路由方法时,需要综合考虑网络的特点和实际需求。

6. 选择合适路由方法的流程

为了帮助用户根据实际情况选择合适的路由方法,我们设计了以下流程图:

graph TD
    A[开始] --> B{网络拓扑复杂度}
    B -->|低| C{资源是否充足}
    B -->|高| D{接触计划时长}
    C -->|是| E[选择 RUCoP]
    C -->|否| F[选择 LSS]
    D -->|短| G{对 SDP 要求高吗}
    D -->|长| H[选择 RUCoP]
    G -->|是| I[增加采样数量使用 LSS]
    G -->|否| J[选择 LSS]

这个流程图展示了选择路由方法的决策过程:
1. 首先判断网络拓扑的复杂度。如果复杂度低,接着考虑资源是否充足。若资源充足,选择 RUCoP 以获得更好的 SDP;若资源有限,选择 LSS。
2. 如果网络拓扑复杂度高,再判断接触计划的时长。若时长较长,选择 RUCoP;若时长较短,根据对 SDP 的要求来决定。对 SDP 要求高时,增加采样数量使用 LSS;要求不高时,直接选择 LSS。

7. 未来研究方向

虽然 RUCoP 和 LSS 为容迟网络的路由问题提供了有效的解决方案,但仍有一些方面值得进一步研究:
- LSS 采样策略优化 :在复杂拓扑中,LSS 的无信息采样策略表现不佳。未来可以研究更智能的采样策略,例如基于网络拓扑特征的采样,以提高 LSS 在复杂网络中的性能。
- 混合路由方法 :可以考虑将 RUCoP 和 LSS 的优点结合起来,设计一种混合路由方法。例如,在网络拓扑相对简单的部分使用 RUCoP 进行精确计算,在复杂部分使用 LSS 进行快速估计。
- 动态路由调整 :现有的方法大多是离线计算路由决策,而容迟网络的环境是动态变化的。未来可以研究如何实现动态路由调整,根据网络状态的实时变化及时调整路由策略。

8. 结论

本文详细介绍了容迟网络中两种基于 MDP 的路由方法:RUCoP 和 LSS,并通过三种不同的网络拓扑对它们的性能进行了评估。评估结果表明,RUCoP 在 SDP 方面表现出色,但对时间和内存要求较高;LSS 内存占用小,运行时间短,在简单拓扑中表现接近 RUCoP,但在复杂拓扑中需要改进采样策略。

在实际应用中,我们可以根据网络拓扑的复杂度、接触计划的时长、资源限制以及对 SDP 的要求,使用本文提供的决策流程来选择合适的路由方法。同时,未来的研究可以朝着优化采样策略、设计混合路由方法和实现动态路由调整等方向发展,以进一步提高容迟网络的路由性能。

总之,选择合适的路由方法对于容迟网络的高效运行至关重要。通过对 RUCoP 和 LSS 的深入研究和比较,我们可以为不同的网络场景找到更合适的解决方案,推动容迟网络技术的发展。

**项目名称:** 基于Vue.js与Spring Cloud架构的博客系统设计与开发——微服务分布式应用实践 **项目概述:** 本项目为计算机科学与技术专业本科毕业设计成果,旨在设计并实现一个采用前后端分离架构的现代化博客平台。系统前端基于Vue.js框架构建,提供响应式用户界面;后端采用Spring Cloud微服务架构,通过服务拆分、注册发现、配置中心及网关路由等技术,构建高可用、易扩展的分布式应用体系。项目重点探讨微服务模式下的系统设计、服务治理、数据一致性及部署运维等关键问题,体现了分布式系统在Web应用中的实践价值。 **技术架构:** 1. **前端技术栈:** Vue.js 2.x、Vue Router、Vuex、Element UI、Axios 2. **后端技术栈:** Spring Boot 2.x、Spring Cloud (Eureka/Nacos、Feign/OpenFeign、Ribbon、Hystrix、Zuul/Gateway、Config) 3. **数据存储:** MySQL 8.0(主数据存储)、Redis(缓存与会话管理) 4. **服务通信:** RESTful API、消息队列(可选RabbitMQ/Kafka) 5. **部署与运维:** Docker容器化、Jenkins持续集成、Nginx负载均衡 **核心功能模块:** - 用户管理:注册登录、权限控制、个人中心 - 文章管理:富文本编辑、分类标签、发布审核、评论互动 - 内容展示:首页推荐、分类检索、全文搜索、热门排行 - 系统管理:后台仪表盘、用户与内容监控、日志审计 - 微服务治理:服务健康检测、动态配置更新、熔断降级策略 **设计特点:** 1. **架构解耦:** 前后端完全分离,通过API网关统一接入,支持独立开发与部署。 2. **服务拆分:** 按业务域划分为用户服务、文章服务、评论服务、文件服务等独立微服务。 3. **高可用设计:** 采用服务注册发现机制,配合负载均衡与熔断器,提升系统容错能力。 4. **可扩展性:** 模块化设计支持横向扩展,配置中心实现运行时动态调整。 **项目成果:** 完成了一个具备完整博客功能、具备微服务典型特征的分布式系统原型,通过容器化部署验证了多服务协同运行的可行性,为云原生应用开发提供了实践参考。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值