基于B/S架构的卫星地球站远程维护方案设计

奚炜弘　李晴飞

摘要：随着卫星通信技术的发展，卫星通信终端得到了大量的普及和应用，这也使得远程维护成为卫星通信系统的一个重要细成部分。文章通过对网桥、B/S架构的分析研究，设计了一种基于B/S架构的卫星地球站远程维护方案。

关键词：卫星通信；B/S；网桥

随着空间技术和电子技术的发展，卫星通信技术得到了不断的发展，移动卫星通信系统开始受到TM门广泛的关注和应用。卫星通信以其覆盖区域大、通信距离远、机动灵活、不受陆地灾害影响等众多优势，开始进入各个领域，并在其中占据了重要的份额。在大量卫星终端的普及和应用的同时，终端的维护方式也必然开始成为卫星通信系统的一个重要研究方向。

传统的卫星地球站现场维护方式，通常是当客户的设备产生故障之后，通知设备厂家，此时设备厂家才会派出工程师到现场为客户解决问题。这样的方式会引起客户的设备长时间无法使用，从而降低客户满意度，并且耗费大量的人员时间和出差费用。

本文通过对卫星链路转地面网络的方式和维护平台系统架构的分析研究，设计了一种基于B/S架构的卫星地球站远程维护方案，该方案可大幅度降低维护成本，减少用户损失。

1.卫星链路转地面网络设计

在卫星地球站远程维护方案的设计中，需要将卫星链路转换为地面网络，在转换的过程中，需要注意以下几点。

（1）不能改变收到的帧的内容和格式，也不能在帧的外部添加任何内容。每一个要传输的帧应该是简单地从卫星链路中复制出来，并原封不动地送给地面网络，反之亦然；（2）需要有足够的缓存空间以满足峰值的需要；（3）具有数据过滤功能，解决循环回路。

通过上述分析可以发现使用网桥模式是最优的选择。在卫星通信中，网桥的功能是将从地面网络接收到的数据帧进行缓存，分析该帧的目的MAC地址，如果MAC地址属于另一端网络时，则通过卫星链路进行转发。如图1所示，同样当接收到卫星链路的数据帧时，将数据帧进行缓存，分析该帧的目的MAC地址，如果MAC地址属于本端网络，则转发到本地网络。

在对卫星通信中网桥工作原理进行分析后，发现可以利用libnet和libpcap的编程接口以软件的方式来实现。libnet和libpcap都是Unix/Linux平台下用c语言实现的API library，它们都拥有很高的可移植性，可以移植到VxWorks，Windows等平台下使用。其中libnet提供了数据包的构造和发送功能，libpcap则提供了数据包捕获的功能。

实现网桥功能，libnet库需要调用以下函数：

（1）初始化。

libnet_t*libnet_init（int injection_type，char*device，char*err_buf）；

（2）数据包发送。

mt hbnet wnte（hbnet_t*）；

（3）資源释放。

void libnet_destroy（libnet_t*）；

libpcap库需要调用以下函数：

（4）初始化。

pcap_t*pcap_open_live（const char*device，intsnaplen，int promisc，int to_ms，char*errbuf）；

（5）数据包捕获。

int pcap_loop（pcap_t*p，int cnt，pcap_handlercallback u_char*user）；

（6）资源释放。

void pcap_close（pcap_t*p）；

当卫星链路建立后，通过调用libnet和libpcap的编程接口函数将卫星链路转换为地面网路，以网桥的方式将两个使用相同MAC协议的局域网相连，最终达到维护平台远程登陆维护的目的。

2.维护平台系统架构选择

目前，主流体系架构为B/S和C/S两种。B/S架构的全称为Browser/Server，即浏览器/服务器架构。Browser指的是web浏览器，极少数事务逻辑在前端实现，主要事务逻辑在服务器端实现，由Browser客户端，WebApp服务器端和DB端构成三层架构。C/S架构是一种典型的两层架构，其全称是Client/Server，即客户端/服务器端架构。其客户端包含一个或多个在用户的电脑上运行的程序，而服务器端建立数据库服务器或Socket服务器，允许客户端通过数据库连接访问服务器端的数据；或客户端通过与服务端的Socket通信获取数据。

在本远程维护方案中，选择B/S架构拥有以下几个优势：

（1）采用分布式系统设计，安全性更高。从程序运行安全角度考虑，在卫星地球站中，通信App和维护App是两个独立的程序，两个App的运行互不干扰，实现了运行的隔离。从数据调用角度考虑，通信hpp和维护App所使用的数据在不同的内存中，实现数据的隔离。运行的隔离和数据的隔离保证了卫星地球站的使用更加可靠和安全。

（2）操作灵活便利。B/S架构的特点决定了只需要一个卫星地球站和普通计算机，就可以在任何地方进行远程维护，无需为计算机安装任何客户端，也不需要考虑计算机的硬件配置。

（3）开发成本低。在B/S架构中只需要开发服务器端的WebApp，无需像C/S架构一样开发服务器端的App和客户端的App，这样节约了开发成本。

（4）共享性好。B/S架构允许多个Browser客户端同时登陆服务器端，可以对卫星地球站出现的故障问题进行会诊。

3.方案总体设计

卫星地球站远程维护方案模型由3部分组成，如图2所示。

卫星：提供转发功能，实现两个地球站卫星链路建立的功能。

维护平台：由一台卫星地球站和一台普通计算机组成。卫星地球站用来与故障设备建立卫星链路，并提供卫星链路转网络链路的功能；普通计算机通过网络与卫星地球站相连，通过Web浏览器登录故障设备。

故障设备：故障设备与维护平台的连接支持两种方式，一是直接通过卫星链路建立连接，二是使用地面网络通过中继设备建立连接。

这种设计方案支持以下两种情况的远程维护。

（1）当故障设备卫星通信链路正常时，维护平台可以远程登陆设备进行维护。例如：当卫星地球站B需要进行远程维护并且卫星通信链路正常时，在卫星地球站A与卫星地球站B之间建立卫星通信维护链路，将卫星链路转换成地面网络，通过维护平台登陆卫星地球站B，对卫星地球站B进行设备运行监控、参数设置和版本升级等操作，以达到远程维护的目的。

（2）当故障设备出现卫星通信路故障时，可以将一台卫星通信链路正常的设备和故障设备组成网络，以卫星通信链路正常的设备作为为中继，让维护平台可以远程登陆故障设备进行维护。例如：卫星地球站C2星通信链路故障，卫星地球站B卫星通信链路正常。将卫星地球站C和卫星地球站B相连组成网络，卫星地球站A与卫星地球站B之间建立卫星通信维护链路，以卫星地球站B为中继，通过维护平台登陆卫星地球站C，对卫星地球站C进行远程维护。

通过上述研究可以发现，本方案的设计拥有以下几个优点：

（1）实时监控：定期与客户建立卫星通信维护链路，实时掌握客户设备的使用情况，远程修改客户设备的不合适配置参数，保证客户设备可以得到最优的运行，降低故障出现的概率。

（2）软件版本控制：通過与客户建立卫星通信维护链路，掌握客户设备中的软件系统版本，可以远程对客户设备中的软件系统进行升级，避免了派专人去现场为用户升级的情况。

（3）中继功能：即使客户设备出现卫星通信链路故障，也可以通过使用一台正常的设备作为中继，完成远程维护功能。

4.结语

随着卫星通信终端的大量普及，传统的现场维护方式不仅影响了用户的体验，也造成了公司维护成本的不必要开销。本文设计了一种基于B/S架构的卫星地球站远程维护方案。在该方案中，B/S架构的应用，充分利用了分布式系统的特点，保证了程序运行和数据的独立与安全，并且维护手段也更加方便灵活；远程维护的应用，则使工程师不需要再亲临现场，在本地就可以对远端的卫星地球站进行维护，并根据维护的结果，判断是否需要再进行现场维护。该方案的设计实现了一种新的高效率、低成本的服务方式。