Protocolos de comunicación ligeros punto a punto

1

Estoy trabajando en el diseño de un enlace de comunicaciones punto a punto para un cubesat . Solo quiero confirmar algo de mi comprensión.

En mi opinión, solo es necesario tener la capa física y la funcionalidad de capa de enlace de datos. ¿Por qué necesitaríamos una dirección IP o una capa de transporte para un enlace punto a punto único? Pero tal vez hay problemas que no conozco. Entiendo que debemos poder realizar un seguimiento de los paquetes que llegan desordenados o que no llegan a todos. Obviamente, este es un problema extremadamente difícil para una red grande como Internet, pero para un enlace punto a punto único, parece razonable implementar un esquema simple de reensamblado de paquetes para nosotros mismos.

Nuestra misión es monitorear el hielo marino ártico usando datos de reflectometría GNSS de señales GPS reflejadas desde la superficie de la tierra. Cuantos más datos podamos bajar, mejor. Por lo tanto, estamos motivados a usar protocolos con la menor sobrecarga posible.

Nuestro transceptor es un transceptor microhard n290 , que ha sido lanzado en satélites en el pasado. No es compatible con las estaciones satelitales amateurs existentes, no tuvimos la intención de interactuar con estas redes existentes. Proporciona FEC en hardware y una velocidad de hasta 1.2 Mbps de enlace ascendente o descendente.

Sabemos que necesitamos un protocolo que nos exponga una "interfaz de paquete". 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 reensamblar los paquetes de datos en el orden correcto y solicitar retransmisiones. ¿Es posible poner algo como TCP directamente en la parte superior de la capa de enlace y cortar la IP? Aunque esto todavía me parece una exageración. Nuestros datos de telemetría y estado se ajustarán a un solo paquete. En cuanto a los datos de carga útil, AFAICT todo lo que necesitamos hacer es dividirlos, etiquetarlos y proporcionar un campo de pedido. ¿Hay alguna razón para no hacer esto nosotros mismos? No parece una tarea difícil. Lo he hecho en Python utilizando búferes de protocolo de Google: puedo serializar un archivo, mezclar el orden y luego volver a ensamblarlo. Debería poner solicitudes repetidas sobre esto, pero todo lo demás debe ser manejado por la capa de enlace.

He estado buscando en el protocolo Saratoga ( enlace ), pero es la capa de transporte. Por lo tanto, no parece ser una buena opción.

El

protocolo punto a punto ( enlace ) parece ser la manera más sensata de hacerlo. ¿Derecha? Es tan ligero como se obtiene.

Gracias por cualquier orientación :)

    
pregunta RJTK

3 respuestas

4

¿Por qué no pretende utilizar un protocolo existente?

AFAICT, hay un montón de protocolos en uso, desarrollados durante muchos años, que han resuelto muchos de los problemas, basados en la investigación y la experiencia. Así que usaría algo que funciona y se ha depurado a menos que esté haciendo una investigación. 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 funcionar en el espacio. Es un proceso caro, especializado y lento. Por lo tanto, ahorrar costos y tiempo utilizando algo que ya se sabe que funciona de manera confiable tiene incluso más sentido que los proyectos de ingeniería habituales de la Tierra.

¿Esto es para un proyecto comercial, de investigación o de aficionados?

Sé que los aficionados han construido el equivalente de una red global de estaciones terrestres, que se transfiere a la siguiente estación a medida que el satélite orbita (un poco como la red de estaciones terrestres de la NASA u otras agencias espaciales, pero usa equipo puesto a disposición por partes de un día [los propietarios del equipo también lo usan, ellos mismos, para sus propios fines] por aficionados entusiastas). ¿Estás tratando de resolver ese problema?

En este caso, podría no ser una única comunicación punto a punto. Puede tratarse de múltiples estaciones terrestres que intentan hablar con el mismo satélite. O puede tratarse de múltiples estaciones terrestres que intentan hablar con múltiples satélites.

Si es un proyecto amateur, contáctese directamente con los grupos. El UK Amateur Satellite group es amigable, y los miembros colaboraron con colegas en AMSAT-NL, en la creación del software y la red para aficionados. Red internacional de estaciones terrestres. 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 continuó influyendo en Ethernet e Inmarsat. Entonces, por ejemplo, algunas de las ideas exitosas pueden ser retenidas de ese trabajo. Mientras funcione, no tiene desventajas significativas, se ha demostrado que funciona en el espacio y tiene hardware disponible, que se ha probado y el espacio está "certificado", ¿qué motivación hay para cambiar?

Editar:

Hay algunos documentos sobre alta latencia, e incluso una pregunta de stackoverflow Networking con latencia extremadamente alta lo que podría dar un poco de inspiración.

Hay protocolos antiguos con implementaciones depuradas. Tienen el beneficio de ser tan viejas que las máquinas en las que se ejecutaron tenían pocos recursos, por lo que pueden ser adecuadas para 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 la solución de 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 tuvo implementaciones en C. Por lo tanto, es posible que pueda obtener la fuente y transferirla. Kermit se ejecutó en máquinas con menos de 64 mil direcciones. Por lo que podría encajar en su hardware.

Incluso si Kermit no es una buena opción, recomendaría ver los protocolos e implementaciones anteriores (alrededor de los 80) porque las restricciones de la máquina pueden ser comparables a las restricciones de su hardware en vuelo; incluso si su hardware está menos restringido que en la década de 1980, su presupuesto de energía podría ser ayudado por una implementación de protocolo de bajos recursos.

    
respondido por el gbulmer
1

TIENES una red, lo reconozcas o no. El suyo no será el único cubo en órbita, ni es probable que sea el único en su canal asignado. De alguna manera, los mensajes de su cubesat deben ser identificables por parte de otros, y confiar en los datos de efemérides (los suyos deben ser elevados sobre ... ahora ...) es frágil.

Ditto the groundstation. Especialmente si desea manejar grandes volúmenes de datos, deseará 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 al desvanecimiento, ¡genial! Pero probablemente solo desee que su propia estación terrestre controle el satélite, por lo que necesita identificar estaciones terrestres y satélites.

Puede resolver todos estos problemas creando su propio protocolo ... con su propio sistema de direccionamiento ... pero la reutilización de uno probablemente sea menos trabajoso y aumente la cooperación con otros.

Pienso que necesitarás más que PPP, quizás TCP (sin IP) sea un buen candidato.

    
respondido por el Brian Drummond
0

tftp? - Pequeño, ligero y conocido.

Las técnicas de compresión

(simples) pueden ahorrar suficiente longitud de paquete para hacer posible la propiedad intelectual 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 se hayan probado completamente utilizando las pilas existentes.

    
respondido por el ChrisR

Lea otras preguntas en las etiquetas