Estoy trabajando en el diseño de un enlace de comunicaciones punto a punto para un cubesat . Sólo quiero confirmar algo de mi entendimiento.
En mi opinión solo es necesario tener funcionalidad de capa física y capa de enlace de datos. ¿Por qué necesitaríamos una dirección IP o una capa de transporte para un único enlace punto a punto? Pero tal vez hay problemas de los que no estoy al tanto. Entiendo que necesitamos poder realizar un seguimiento de los paquetes que llegan desordenados o que no llegan. Obviamente, este es un problema extremadamente desafiante para una red grande como Internet, pero para un solo enlace punto a punto, parece razonable implementar un esquema simple de reensamblaje de paquetes para nosotros.
Nuestra misión es monitorear el hielo marino del Ártico utilizando datos de reflectometría GNSS de señales GPS reflejadas en la superficie de la tierra. Cuantos más datos podamos descargar, mejor. Por lo tanto, estamos motivados para utilizar protocolos con la menor sobrecarga posible.
Nuestro transceptor es un transceptor microhard n290 , que se ha volado en satélites en el pasado. No es compatible con las estaciones satelitales de aficionados existentes, no teníamos intención de interactuar con estas redes existentes. Proporciona FEC en hardware y una tasa de enlace ascendente o descendente de hasta 1,2 Mbps.
Sabemos que necesitamos un protocolo que nos expondrá una "interfaz de paquetes". Es decir, necesitamos un protocolo de capa de enlace para empaquetar el flujo de datos en serie.
Como no tenemos ningún tipo de red, no necesitamos una capa IP. En cuanto a una capa de transporte, necesitamos poder volver a ensamblar los paquetes de datos en el orden correcto y solicitar retransmisiones. ¿Es posible poner algo como TCP directamente encima de la capa de enlace y eliminar IP? Sin embargo, esto todavía me parece excesivo. Nuestros datos de telemetría y estado caben en un solo paquete. En cuanto a los datos de carga útil, AFAICT todo lo que tenemos que hacer es dividirlos, etiquetar los datos y proporcionar un campo de pedido. ¿Hay alguna razón para no hacerlo nosotros mismos? No parece una tarea difícil. Lo hice en Python usando los búferes del protocolo de Google: puedo serializar un archivo, mezclar el orden y luego volver a ensamblarlo. Tendría que poner solicitudes repetidas además de esto, pero todo lo demás debe ser manejado por la capa de enlace.
He estado mirando el protocolo Saratoga ( http://saratoga.sourceforge.net/ ), pero es una capa de transporte. Por lo tanto, no parece una buena opción.
El protocolo punto a punto ( https://en.wikipedia.org/wiki/Point-to-Point_Protocol ) parece ser la forma más sensata de hacerlo. ¿Bien? Es tan ligero como se pone.
Gracias por cualquier orientación :)
¿Por qué no tiene la intención de utilizar un protocolo existente?
AFAICT, ya hay un montón de protocolos en uso, desarrollados durante muchos años, que han resuelto muchos de los problemas, basados en investigación y experiencia. Así que usaría algo que funcione y haya sido depurado a menos que esté investigando. Si se trata de una investigación, debe describir el caso de uso completo y no solo algunas características específicas del caso de uso.
Los protocolos antiguos pueden sobrevivir simplemente porque la tecnología de los satélites no solo tiene que funcionar, sino que también debe probarse, caracterizarse y "certificarse" para que funcione en el espacio. Ese es un proceso costoso, especializado y lento. Por lo tanto, ahorrar costos y tiempo mediante el uso de algo que ya se sabe que funciona de manera confiable tiene incluso más sentido que los proyectos de ingeniería terrestres habituales.
¿Es esto para un proyecto comercial, de investigación o amateur?
Sé que los aficionados han construido el equivalente a una red global de estaciones terrestres, que pasan a la siguiente estación a medida que el satélite orbita (un poco como la red de estaciones terrestres que tienen la NASA u otras agencias espaciales, pero utilizando equipos disponibles para partes de un día [los propietarios del equipo también lo utilizan, ellos mismos, para sus propios fines] por aficionados entusiastas). ¿Estás tratando de resolver ese problema?
En cuyo caso podría no ser una única comunicación punto a punto. Pueden ser varias estaciones terrestres, cada una de las cuales intenta comunicarse con el mismo satélite. O pueden ser varias estaciones terrestres que intentan comunicarse con varios satélites.
Si se trata de un proyecto amateur, contacta directamente con los grupos. El grupo UK Amateur Satellite es amigable, y los miembros colaboraron con colegas en AMSAT-NL, en la creación del software y la red para la red internacional de estaciones terrestres basada en radioaficionados. También construyeron el hardware de radio de bajo costo utilizado para rastrear su FUNCube CubeSat.
Una de las primeras redes inalámbricas de paquetes, ALOHnet , influyó en Ethernet e Inmarsat. Entonces, por ejemplo, algunas de las ideas exitosas pueden conservarse de ese trabajo. Mientras funcione, no tenga desventajas significativas, se haya probado que funciona en el espacio y tenga hardware disponible, que esté probado y 'certificado' en el espacio, ¿qué motivación hay para cambiar?
Editar:
Hay algunos documentos sobre la latencia alta, e incluso una pregunta sobre el desbordamiento de la pila Redes con una latencia extremadamente alta que podría servir de inspiración.
Hay protocolos antiguos con implementaciones depuradas. Estos tienen la ventaja de que son tan antiguos que las máquinas en las que se ejecutaban tenían pocos recursos y, por lo tanto, pueden adaptarse bien a su aplicación.
Por ejemplo, el Protocolo Kermit . Ese artículo de wikipedia dice que "el software Kermit se ha utilizado para tareas que van desde tareas simples de estudiantes hasta resolver problemas de compatibilidad a bordo de la Estación Espacial Internacional". Así que tiene un pedigrí útil :-)
Admite un ' protocolo de ventana deslizante ' que admite la retransmisión selectiva. Eso debería ayudar a recuperarse de los errores y volver a ensamblar los flujos de datos dañados.
Es de código abierto y tenía implementaciones en C. Por lo tanto, es posible que pueda obtener la fuente y portarla. Kermit se ejecutó en máquinas con menos de 64k de espacio de direcciones. Así que podría encajar en su hardware.
Incluso si Kermit no encaja bien, recomendaría mirar los protocolos e implementaciones antiguos (alrededor de 1980) porque las restricciones de la máquina pueden ser comparables a las restricciones de su hardware en vuelo; incluso si su hardware está menos limitado que en la década de 1980, su presupuesto de energía podría verse favorecido por una implementación de protocolo de bajos recursos.
TIENES una red, ya sea que la reconozcas o no. El suyo no será el único cubesat en órbita, ni es probable que sea el único en su canal asignado. De alguna manera, los mensajes de su cubesat deben ser identificables de los demás, y confiar en datos de efemérides (los suyos deberían estar sobrecargados sobre... ahora...) es frágil.
Lo mismo ocurre con la estación terrestre. Especialmente si desea manejar grandes volúmenes de datos, necesitará más de una estación de tierra. Los Cubesats a menudo usan una red de estaciones terrestres de aficionados, y si alguien en Woomera o Yakutsk recogió los paquetes que perdiste debido a la decoloración, ¡genial! Pero probablemente solo desee que su propia estación terrestre controle el satélite, por lo que debe identificar las estaciones terrestres además de los satélites.
Puede resolver todos estos problemas creando su propio protocolo... con su propio sistema de direccionamiento... pero es probable que reutilizar uno sea menos laborioso y aumente la cooperación con los demás.
Creo que necesitará más que PPP; quizás TCP (sin IP) sería un buen candidato.
tftp? - pequeño, ligero y bien conocido.
Las técnicas de compresión (simples) pueden ahorrar suficiente longitud de paquete para que IP sea factible y permitirle reasignar mano de obra a partes más interesantes del proyecto.
Vuelva a la eliminación de IP una vez que el protocolo, el dispositivo y la aplicación estén funcionando y probados por completo con las pilas existentes.
Stefan Merfu
RJTK
viejo contador de tiempo
viejo contador de tiempo
gbulmer