¿Cómo diseñar una antena terrestre para enviar y recibir desde un satélite?

¡Esta es una pregunta interesante! Hay (al menos) dos problemas de comunicación a considerar. Uno es la intensidad de la señal sobre la que se hace la pregunta, el otro es la latencia o el retraso. Pero el tl;dr es que esto no funcionará con WiFi estándar o equipo de datos móviles porque la antena tendría que tener el tamaño de un kilómetro y los retrasos son incompatibles con los protocolos.

Un cálculo del presupuesto del enlace (que puede ver en esta respuesta ) mostraría que una antena terrestre más pequeña funcionaría, pero aún tendría que modificar el protocolo para lidiar con velocidades de datos bajas y latencia prolongada, y eso significa hardware especializado en su estación satelital y terrestre en lugar de COTS WiFi o celular.

Intensidad de señal

Una forma muy rápida de estimar aproximadamente el tamaño del área de recolección necesaria sería tomar proporciones simples. Elijamos 2 GHz como frecuencia de trabajo aproximada. La longitud de onda correspondiente de$\lambda = c/f$es 3E+08 ms^-1 / 2E+09 s^-1 o 15 centímetros. Se puede suponer que una antena dipolo WiFi tiene un área de recepción efectiva de aproximadamente 1 longitud de onda al cuadrado, o 0,02 m ^ 2, y una antena de torre de telefonía celular de aproximadamente 1 x 10 longitudes de onda o 0,2 m ^ 2.

Digamos, para números aproximados y redondos, que el rango WiFi normal en el espacio libre (sin obstrucciones) es de 100 metros, y el rango útil de datos móviles de alta velocidad es de 3 km. Los teléfonos móviles pueden recibir datos a una distancia de hasta 30 km, pero para transmitir datos a alta velocidad, el alcance será menor.

Su distancia es de 3.000 km. Dado que la señal cae como$1/r^2$aquellos requieren áreas de antena que aumentan en factores de 10 ^ 9 y 10 ^ 6 respectivamente. Eso significa antenas terrestres con un área de 2E+07 y 2E+05 m^2, o tamaños de 4 km y 400 metros, respectivamente.

¡Estos son enormes! En otras palabras, si mantiene todo sobre el equipo igual y trata de abordar la gran distancia simplemente escalando el tamaño de la antena basada en la Tierra, no va a funcionar. Square Kilometer Array es un ejemplo de un proyecto en el que el área total de todas las antenas juntas es de aproximadamente 1 km x 1 km, y ese es un proyecto de clase mundial.

El plato más grande utilizado en el sistema Deep Space Network tiene solo 70 metros de diámetro y, sin embargo, puede comunicarse a distancias de miles de millones de kilómetros. ¿Por qué? Las velocidades de datos a estas distancias son mucho, mucho más lentas que las velocidades de datos mínimas para Wi-Fi comercial estándar o datos móviles. Utilizan protocolos especiales para vencer las señales débiles y el gran ruido a estas distancias. De hecho, puede rastrear el desarrollo de algunos protocolos de datos inalámbricos comerciales directamente desde la tecnología de comunicaciones del espacio profundo por personas que trabajaron en CSIRO . Consulte [Historial WiFi]. 6 También utilizan longitudes de onda más cortas (mejorando la ganancia) y extremos frontales del receptor criogénicos (enfriados) para profundizar en el ruido.

Latencia

La forma en que los canales comerciales de voz y datos de los teléfonos celulares y las comunicaciones del enrutador WiFi funcionan normalmente, primero deben establecer comunicaciones bidireccionales antes de comenzar a enviar datos. A grandes distancias, el retraso de tiempo debido a la velocidad finita de la luz confundirá las comunicaciones de datos celulares y WiFi comercial. Por ejemplo, GSM tiene un corte total a los 35 km debido al cambio de tiempo máximo permitido en el protocolo. A los 3.000 km el retraso es de DIEZ milisegundos , y para datos de alta velocidad, ¡eso es para siempre!

TL; DR: Debería ser posible crear una conexión confiable entre una estación terrestre y un satélite en teoría , dadas todas las suposiciones en esta publicación. Sin embargo, prácticamente el hecho de que los satélites LEO se mueven con bastante rapidez y la necesidad de rastrearlos con una antena motorizada, significa que habrá "brechas" en el enlace, cuando la antena necesite reposicionarse al siguiente satélite.

Como especifica "Wifi" o "GSM" en su pregunta, supongamos que quiere decir tener una aplicación para el "mercado de consumo"... por ejemplo, "Internet por satélite"

Entonces queremos "intercambiar" información digitalizada, y para hacerlo podemos usar un modelo conceptual como las 7 capas del modelo OSI

Estaríamos particularmente interesados ​​en las Capas 1 a 3, las llamadas "Capas de Medios".

• Capa-1: capa física: aquí es donde bitsse transfieren
• Capa 2: capa de enlace de datos: aquí es donde framesse transfieren
• Capa 3: Capa de red: aquí es donde packetsse transfieren

Múltiples bitshacen un frame, uno o más frameshacen unpacket

Ahora comencemos a desglosar esto relevante para su pregunta. Voy a saltar en esas capas.

Capa-3

La capa 3 en este caso es muy simple, y para la conectividad a Internet, aquí es donde vive IP( Protocolo de Internet ). IPes la parte del término bien conocido TCP/IP, sin embargo, técnicamente hablando, la TCPparte es un protocolo de capa 4. Nos estamos concentrando en IP, Layer-3. Y con eso, concentrémonos para este ejemplo en IPv4

La mayor preocupación para la comunicación a larga distancia es la restricción dentro de la especificación del protocolo con respecto a la latencia y los tiempos de espera.

Porque IPv4no hay un tiempo de espera definido para el protocolo, pero en el encabezado del marco de datos hay un campo TTL( Tiempo de vida ) en offset 8, bits 0-7.

Este campo es un "contador decreciente de segundos" y, por lo tanto, tenemos un máximo de 255 segundos para que viva el marco de datos. Prácticamente, este contador disminuye cada vez que el marco de datos "golpea" un "enrutador" y los tiempos de subsegundos se redondean a un segundo, por lo que disminuye más rápidamente que 255 segundos.

De cualquier manera; por elegir IPv4como nuestro protocolo de capa 3, podemos concluir con seguridad que este protocolo es lo suficientemente robusto para la distancia que necesitamos salvar. Prueba de ello es el internet actual. Todos trabajamos con servidores de todo el mundo con 1-500ms de latencia sin ningún problema. De hecho, es probable que esta misma publicación que está leyendo le sea entregada desde cierta distancia.

Conclusión para la capa 3: al elegir el protocolo correcto, podemos salvar de manera confiable la distancia desde la tierra hasta el satélite LEO, el protocolo de ejemplo sería IPv4.

Genial, así que no hay problemas en nuestra Capa-3 si elegimos IPv4. Veamos otra capa:

Capa-1

Bien, esta es la capa física, la "bomba" que solo necesita "bombear bits"... perfecto, estamos hablando de tierra a satélite, así que estamos hablando de "ondas de radio".

Como se detalla en muchas publicaciones en este sitio y en otros, debe calcular algo llamado Presupuesto de enlace .

Para este ejemplo, tomemos la fórmula del presupuesto del enlace tal como se describe en el artículo vinculado. Hay cálculos mucho más complejos que son mejores y tendrán en cuenta varios factores ambientales y el ancho de banda. Si está interesado, aquí hay un artículo de muestra .

Primero vamos a hacer algunas suposiciones, para obtener algunos números de muestra con los que trabajar:

• Esta es una aplicación de consumo, por ejemplo, "Internet de Satélite"
• Debe ser un equipo de consumo a un precio razonable para la estación terrestre.
• Debe ser un equipo con una forma razonable para la estación terrestre.

En base a esto, vamos a poner algunos números por ahí:

• Plato de 150 cm de diámetro, Ganancia de 30 dBi a 2,4 GHz
• Computadora/rotor/software necesario para apuntar y rastrear el plato
• Puente "WiFi" 802.11g, piso de ruido de -110 dB, SINAD de 20 dB
• Potencia de salida de 1W

Tenga en cuenta que la potencia de salida de 1 vatio, con un plato de 30 dBi, es unas 10 000 veces el máximo legislado en la mayoría de los países (100 mW ERP)

Bien, comencemos con los cálculos del enlace ascendente. La fórmula para la pérdida de trayectoria es:

PL(db) = 20log(d) + 20log(f) + 32,44 - Gtx - Grx

Supongamos una distancia desde el suelo hasta el satélite a 3000 km según OP:

PL = Pérdida de trayectoria en dB d = Distancia en km f = Frecuencia en MHz Gtx = Ganancia de la antena transmisora ​​en dBi Grx = Ganancia de la antena receptora en dBi

Conecta los números:

PL = 20*log(3000) + 20*log(2400) - 30 - Grx

PL = 107 - Grx

Con un receptor de especificaciones similares en el extremo del satélite (-110 dB de ruido // 20 db SINAD), necesitamos una señal de -90 dBm para recibir la señal de forma fiable.

Conectando algunos números más, especialmente la potencia de salida de 1 vatio (30dBm), obtienes:

Rseñal = Psalida - PL + Grx = 30 - 107 + Grx = -77 dBm + Grx.

Entonces, incluso una antena de recepción modesta con una ganancia de 0 dBi servirá para el enlace ascendente. ¡Aquí no tenemos problemas!

Pasemos al enlace descendente y calculemos la potencia de salida y la ganancia de la antena TX del satélite necesarios para mantener un enlace confiable.

La pérdida de ruta es la misma, es la misma distancia, el Gtx de la estación terrestre ahora se convertirá en el Grx del enlace descendente. El cálculo es el mismo.

Con un transmisor modesto en el Satélite y una antena modesta, con un plato motorizado de 150 cm en la estación terrestre, rastreando el satélite, puede establecer una conexión de manera confiable.

Conclusión para la capa 1 : ciertamente es posible construir una estación terrestre modesta que pueda enviar/recibir señales de radio desde un satélite, dado el equipo correcto. Y a velocidades cercanas a la velocidad de la luz, no esperaríamos más de 10-20 ms de latencia unidireccional en este enlace.

¡Perfecto, tenemos la Capa-1 y la Capa-3 ordenadas!

Una capa más para mirar:

Capa-2

Bueno, como hemos determinado que estamos trabajando con equipos de "grado de consumo", nos ceñiremos a un protocolo de consumo para esta capa: el conocido Wifi 802.11g .

Aqui es donde se pone complicado.

Las implementaciones modernas de 802.11 utilizan algo llamado OFDM ( multiplexación por división de frecuencia ortogonal ), que en la práctica para 802.11g son 48 portadoras de datos y 4 portadoras piloto, que abarcan un ancho de banda de 22 MHz, de los cuales en realidad se utilizan 16,6 MHz (debido a la huecos de espacio entre los portadores). Esto significaría que es posible que necesitemos más potencia en nuestra Capa 1, ya que la potencia del transmisor ahora se divide en este ancho de banda necesario de 16,6 MHz. Entonces, esa sería una función integral "bajo la curva de ancho de banda resumida" para calcular nuestra referencia de dBm para el piso de ruido y SINAD. Solo por el bien de este ejemplo, dejemos eso y continuemos con esto en teoría, asumiendo que la Capa-1 está bien.

El verdadero problema es la forma en que este protocolo está estructurado con respecto al protocolo de "espaciado de tiempo" o como se les llama Guard Interval

En los protocolos 802.11, normalmente se establecen en -0,8 microsegundos. Estos 0,8 microsegundos lo harán muy propenso a errores. Puede obtener un software personalizado (de código abierto) para ejecutarlo en su equipo Wifi, lo que le permite ajustar aún más estas configuraciones, y se sabe que algunos lo configuran en 3.2 microsegundos.

A una velocidad de datos de 24 Mbps (aproximadamente la mitad del rendimiento máximo de 802.11g), una trama tarda 566 microsegundos + 3,2 microsegundos. lo que significa que en un enlace de 3000 km con un retraso de 10 milisegundos, tendrá 17 tramas "en tránsito" en un enlace completamente cargado.

En ese enlace de 10 milisegundos, con esos 17 cuadros, a una velocidad de datos de 24 Mbps, hay un promedio de 254.658 bytes "en tránsito" entre tierra y satélite o viceversa.

por lo tanto, si tiene ciclos RTS/CTS ( Solicitud para enviar/Limpiar para enviar ) cada vez que el marco enviado supera los 2346 bytes (un valor predeterminado común), intercalará una gran cantidad de paquetes RTS/CTS en ese enlace, que no son aún reconocido. Cuando se envía un RTS pero no se confirma con un CTS, la transmisión se detendrá hasta que se reciba un CTS.

Este RTS/CTS, que es probablemente el mayor obstáculo en "Wifi de largo alcance" para aplicaciones de gran ancho de banda.

Dado el software Wifi de código abierto personalizado, es posible que pueda modificar esta configuración. Incluyendo el envío de tramas más pequeñas, por debajo del umbral RTS/CTS configurado. Esta fragmentación de paquetes, por supuesto, influirá significativa y negativamente en el rendimiento y el ancho de banda del enlace.

La realidad es que el tráfico se "detendrá" con bastante frecuencia, lo que le dará un "patrón de ráfagas" en lo que respecta al rendimiento. Esto tendrá un efecto en el tipo de aplicación (capa 4 y superior) que se ejecuta en el enlace. Esto significaría que los protocolos sensibles al tiempo (como VoIP) no serían adecuados, pero otros (como FTP) no serían un problema, aunque con un ancho de banda reducido.

Conclusión para la capa 2: esta capa presentará la mayoría de los desafíos en lo que respecta a un enlace estable. Pero dada la variedad de software de código abierto disponible y la suposición de que los temporizadores/umbrales se pueden ajustar, debería ser posible establecer un enlace de 3000 km. Sin embargo, el ancho de banda/rendimiento de los mismos se vería significativamente obstaculizado por las operaciones internas del protocolo Layer-2.

Conclusión general:

En teoría, debería ser posible crear una conexión confiable entre una estación terrestre y un satélite, dados todos los supuestos en esta publicación. Sin embargo, prácticamente el hecho de que los satélites LEO se mueven con bastante rapidez y la necesidad de rastrearlos con una antena motorizada, significa que habrá "brechas" en el enlace, cuando la antena necesite reposicionarse al siguiente satélite.

Sería interesante hacer los mismos cálculos con una antena de estación terrestre omnidireccional, como una antena Quadrifilar-Helix o Lindenblad, que no tendría que apuntarse para rastrear un satélite en particular. Dada la longitud de onda de Wifi a 2,4 GHz, probablemente sería un conjunto de múltiples antenas. Sería bueno hacer una investigación adicional para encontrar protocolos alternativos de Capa 2 más adecuados para largo alcance que 802.11, tal vez algo como 802.16 u 802.20. Esta sería otra pregunta y estaría fuera del alcance de esta respuesta.