TRABAJOS DE INVESTIGACIÓN

Protocolos y formatos para la diseminación de datos GNSS (Global Navigation Satellite System): una revisión

Protocols and formats for the dissemination of GNSS data (Global Navigation Satellite System): a review

 

Alfredo H. Herrada^{1, 2}, Silvia A. Miranda¹

¹ Instituto Geofísico Sismológico "Fernando S. Volponi". FCEFN. UNSJ. San Juan. Argentina.
² Facultad de Ingeniería. UNSJ. San Juan. Argentina.
E-mail: aherrada@unsj.edu.ar

---

RESUMEN

El Instituto Geográfico Nacional de Argentina (IGN), en concordancia con la tendencia internacional y conjuntamente con diversas instituciones públicas nacionales, generó en el año 1998 un proyecto consistente en la instalación de estaciones GPS/GNSS (Global Positioning System/Global Navigation Satellite System) permanentes en el territorio nacional. En la actualidad, la Red Argentina de Monitoreo Satelital Continuo (RAMSAC) está conformada por 64 Estaciones Continuas GNSS (EC) que materializan el Marco de Referencia Geodésico ITRF-2005 (Época 2006, 632).
El desarrollo sostenido y la confiabilidad de la red RAMSAC, junto con la evolución de las aplicaciones y posibilidades asociadas a internet, particularmente las técnicas de transmisión de datos a través del protocolo IP (Internet Protocol) mediante la división de datos en tamaños apropiados, han posibilitado la implementación de un sistema de correcciones en tiempo real basado en los datos provistos por las Estaciones (EC). La metodología aplicada, se basa en el desarrollo elaborado por la Agencia Federal de Cartografía y Geodesia de la República Federal de Alemania (Federal Agency for Cartography and Geodesy, BKG), difundida bajo la denominación de Networked Transport of RTCM via Internet Protocol (NTRIP), que permite la obtención en tiempo real de coordenadas (latitud, longitud y altura) a múltiples usuarios con niveles de precisión sub-métrica.
Este artículo sintetiza los diversos modos de entrega de datos GNSS en tiempo real, en términos de protocolos de transmisión, formatos de datos, vínculos de comunicación, estructura de mensajes y contenidos entre las diversas versiones de formatos RTCM SC-104 (Radio Technical Commission for Maritime Services- Special Committee 104), incluyendo enmiendas recientes.

Palabras claves: GNSS; Transmisión de datos; Protocolos; Formatos.

ABSTRACT

In 1998, in line with the international trend, the National Geographic Institute of Argentina (IGN) in partnership with various national public institutions initiated a project for the installation of a series of GPS/GNSS (Global Positioning System/Global Navigation Satellite System) permanent stations across their national territory. At the present time, this Argentine Network of Continuous Satellite Monitoring (RAMSAC) is composed of 64 Continuous Stations (EC) that materialize the Geodetic Reference Frame ITRF-2005 (Epoch 2006.632).
The sustainable development and the reliability of this RAMSAC network, along with the evolution of applications and possibilities associated with the Internet (particularly the techniques of data transmission via the Internet Protocol through the division of data into appropriate sizes) have enabled the implementation of a real-time correction system based on the data provided by these Continuous Stations. The methodology applied is based on the development elaborated by the Federal Agency for Cartography and Geodesy of the Federal Republic of Germany (BKG) broadcast under the name Networked Transport of RTCM via Internet Protocol (NTRIP). It allows multiple users to obtain, in real-time, coordinates (latitude, longitude and height) with sub-meter accuracy levels.
This article summarizes the various modes of real-time GNSS data delivery in terms of transmission protocols, data formats, links of communication, structure of messages, and content between different versions of the RTCM SC-104 formats (Radio Technical Commission for Maritime Services - Special Committee 104), including recent amendments.

Keywords: GNSS; Data transmission; Protocols; Formats.

---

 

INTRODUCCIÓN

Las técnicas de posicionamiento DGNSS (Differential Global Navigation Satellite System) y RTK (Real-Time Kinematic) han sido desarrolladas para satisfacer necesidades de georreferenciamiento preciso. La transmisión de correcciones o datos crudos desde una o más estaciones de referencia a un receptor remoto es la clave del posicionamiento diferencial. La mayoría de los fabricantes de receptores GNSS han desarrollado y mantenido sus propios formatos de datos. Aunque los protocolos propietarios son eficientes y confiables, frecuentemente se requieren otros estándares a fin de establecer la interoperabilidad en la administración de redes de estaciones de referencia compuestas por marcas y tipos diferentes de receptores GNSS. El formato RINEX (Receiver INdependent Exchange) fue introducido para intercambiar datos GNSS mediante un archivo de formato estándar, sin embargo no es aplicable en la transmisión de datos en tiempo real. La organización internacional RTCM a través del comité 104 (RTCM SC-104), ha establecido formatos y protocolos que son actualmente aceptados como estándares internacionales. Los protocolos de datos han evolucionado significativamente incorporando nuevos tipos de mensajes. Por otra parte, el protocolo Networked Transport of RTCM via Internet Protocol (NTRIP) fue desarrollado como protocolo de transporte en red para diseminar datos GNSS vía internet (Weber, 2004).
En vista de la variedad y las características particulares, en este artículo, se resumen los distintos mecanismos de entrega de datos GNSS hoy disponibles.

INTERCAMBIO DE DATOS GNSS Y TIPOS DE SERVICIO

Dos alternativas son posibles para intercambiar datos GNSS a saber. En primer lugar, el formato RINEX en el ámbito de las operaciones diferenciales con pos-procesamiento. RINEX, estándar internacional, fue introducido por el Astronomical Institute of the University of Berne, Switzerland a fines de 1980 para intercambio de datos GPS en archivos de formato ASCII, para aplicaciones científicas y geodésicas. La mayoría de los fabricantes de receptores proveen utilidades para convertir desde su formato patentado de datos a RINEX. Típicamente, los datos horarios o diarios de Estaciones de Referencia Continua se archivan en formato RINEX y están disponibles desde un servidor vía FTP (File Transfer Protocol). Variadas prácticas emplean la técnica de pos-procesamiento con archivos RINEX, entre ellas Agrimensura y GIS, Ciencias de la Atmósfera, Geodesia y Geofísica, que requieren períodos largos de datos. Sin embargo, RINEX no es aplicable en transmisión de datos en tiempo real. Se han practicado varias enmiendas de RINEX, siendo la última versión la 3.0.
Una segunda opción son los protocolos de tiempo real, para la cual existen dos alternativas: el formato propietario del receptor y el formato estándar internacional. Aunque un formato patentado por un fabricante de receptores GNSS puede ser más conveniente para algunas aplicaciones específicas, los formatos estándar son necesariamente requeridos para garantizar interoperabilidad, es decir operaciones entre distintas marcas y tipos de receptores.

SUMINISTRO DE DATOS GNSS EN TIEMPO REAL

A fin de suministrar información GNSS en tiempo real, tres componentes son necesarias: el protocolo de transmisión, el formato de los datos y el link de comunicación de los datos.
El protocolo de transmisión administra la entrega de datos a través de una red y debe proveer mecanismos confiables de control del flujo de datos. El formato de datos es un acuerdo o especificación para traducir la secuencia de „bit‟ transmitidos en información significativa. El vínculo de comunicación de datos es el medio para transportar la información desde un lugar a otro y generalmente hay dos tipos de nexos de datos: unidireccional y bidireccional.  

Protocolos de transmisión
Dos protocolos para diseminar datos GNSS vía Internet son los más divulgados, Networked Transport of RTCM via Internet Protocol (NTRIP) y Real-Time IGS (RTIGS, 2008). NTRIP fue desarrollado por la Federal Agency for Cartography and Geodesy (BKG) y la Universidad de Dortmund (Alemania) utilizando principios de la tecnología internet radio a fin de difundir datos GNSS en tiempo real utilizando internet. NTRIP es un protocolo genérico basado en el Hypertext Transfer Protocol HTTP/1.1. Pocos años atrás el Comité RTCM aceptó NTRIP versión 1.0 como un estándar para comunicaciones (RTCM, 2004b). NTRIP versión 1.0 utiliza un Protocolo de Control de Transmisión y el Protocolo de Internet (TCP/IP) para obtener una entrega confiable de datos. La versión 2.0 de NTRIP está bajo evaluación para una total compatibilidad HTTP y para uso optativo del User Datagram Protocol e IP (UDP/IP), además de TCP/IP. NTRIP puede utilizarse no sólo como portador de datos en formato RTCM, sino también otros formatos patentados de datos GNSS. El Grupo de trabajo Real-Time IGS introdujo el protocolo RTIGS para difundir datos GNSS en internet. RTIGS está basado en UDP/IP y usa el formato de datos denominado SOC diseñado por el Jet Propulsion Laboratory (JPL) para transportar datos de observaciones GPS con un mínimo ancho de banda, siendo de uso menos difundido que NTRIP.

Formatos de datos GNSS
NMEA 0183 es un estándar para la comunicación de datos desarrollada por el U.S. Nacional Marine Electronics Association (NMEA), para evitar incompatibilidades entre datos y formatos de mensajes entre dispositivos electrónicos marinos. NMEA es fundamentalmente usado para la transmisión de datos entre un receptor GPS/GNSS y otros dispositivos. Es un formato ASCII fácilmente legible, pero menos compacto que un formato binario. Aunque la mayoría de los receptores GNSS generan mensajes NMEA 0183, éstos se limitan a información de navegación y no contienen datos de observación, por lo que no puede ser utilizado para operaciones Diferenciales o RTK.
La Radio Technical Commission for Maritime Services (RTCM) fue instituida en el año 1947 como un comité consejero del Departamento de Estado de EE.UU. Actualmente, es una organización independiente integrada por agencias de gobierno, fabricantes y proveedores de servicios. Las fuertes demandas de las aplicaciones DGPS en Tiempo Real condujeron al establecimiento del RTCM Special Committee 104, a fin de normalizar un formato industrial estándar para los mensajes de corrección. El formato actual es el bien conocido RTCM versión 2.x y se ha actualizado a la versión 3.x. Debido a una estructura ineficiente, el formato RTCM versión 2.x, requiere un ancho de banda relativamente alto. Como resultado no era favorable para operaciones RTK, consecuentemente la firma Trimble Navigation Ltd. (2005) desarrolló un formato compacto alternativo para transmisión de datos que fue adoptado ampliamente como un estándar de la industria. El formato es conocido como Compact Measurement Record (CMR) y resulta muy apropiado para transmitir datos GNSS a una velocidad de transmisión en baudios inferior. El formato CMR mejorado se refiere como CMR+. Muchos fabricantes de receptores GNSS han implementado el formato CMR/CMR+ en sus productos desde entonces.

Vínculos para comunicación de datos
Un vínculo de comunicación de datos es obviamente esencial para posicionamiento relativo en tiempo real. Desde hace muchos años, correcciones de datos DGPS o RTK han sido transmitidas vía VHF (Very High Frequency) o UHF (Ultra High Frequency). Con el desarrollo de las tecnologías de comunicación inalámbrica, internet es actualmente el medio alternativo preferido de transmisión de correcciones GPS. Existen diferentes tipos de nexos inalámbricos disponibles para comunicaciones bidireccionales, entre ellas GSM (Global System for Mobile communications), GPRS (General Packed Radio Service) y UMTS (Universal Mobile Telecommunications System). Conexiones por medio de GSM son típicamente tarifadas por tiempo de conexión, mientras que GPRS es tasado por cantidad de datos transmitidos.

EL ESTÁNDAR RTCM SC-104 VERSIÓN 2.X

Estructura del mensaje
El diseño del formato RTCM versión 2 fue realizado en base a la estructura del Mensaje de Navegación GPS, ya que tamaño de palabras, algoritmos de paridad y formato son idénticos. El Mensaje de Navegación GPS es transmitido a un valor de 50 Hz, y una palabra consiste de 30 bits. Cada Telemetry Word y Handover Word tienen treinta bits de longitud y son la primera y segunda palabra en cada página. Cada palabra en cada frame o marco contiene seis bits de paridad.
Similarmente, en el mensaje RTCM versión 2 las primeras dos palabras de cada mensaje contienen información de cabecera, tal como preámbulo, tipo de mensaje, identificación de la estación (ID), etc. Dentro de los treinta bits, 24 llevan datos y 6 se destinan al chequeo de paridad. El tamaño de palabra y el algoritmo de comprobación de paridad son idénticos a los empleados en el Mensaje de Navegación GPS.
Después del mensaje de cabecera, hay una longitud variable de mensajes. La longitud del mensaje es determinado por el número de campos de las palabras de datos en el mensaje de cabecera. La longitud del mensaje es definido por tipos particulares de mensajes especificados en el documento RTCM versión 2. Un vínculo de datos o link lleva la información desde una estación de referencia a un receptor rover o remoto. El receptor de referencia produce datos GNSS y los convierte en un formato apropiado para transmitir y modular los datos en una portadora que emite al equipamiento de un usuario móvil. Según la especificación del formato RTCM versión 2.3, los estándares X3.15 y X3.16 del American National Standards Institute (ANSI) la transferencia de datos consecutivos está gobernada por una estructura de ocho bits. Como resultado, palabras de treinta bits deben representarse en un formato de ocho bits. En la versión 2 de RTCM, un formato especial "6 de 8" se usa; cada byte contiene 6 bits de palabras GPS, permaneciendo 2 bits remanentes como marcando y espaciando respectivamente (1 y 0).

Tipos de mensajes y contenidos
RTCM versión 2.0 fue definida el 1 de enero de 1990 para correcciones de pseudos-range a efectos de apoyar aplicaciones DGPS con diferentes tipos de mensajes (RTCM, 1990). El Tipo 1 contiene información de correcciones diferenciales tales como corrección para Pseudo-Range (PRC) y Range-Rate Correction (RRC), Issue Of Data (IOD) y User Differential Range Error (UDRE). El mensaje Tipo 2 porta correcciones diferenciales GPS, es decir la diferencia en pseudo-range y correcciones de range-rate resultantes de un cambio en datos de navegación del satélite. El Tipo 3 contiene la ubicación en el sistema Earth-Centred, Earth-Fixed (ECEF) de la estación de referencia. El tipo 59 es un mensaje propietario para la transmisión de cualquier dato. RTCM versión 2.0 (1990) no soporta información de apoyo desde una Red de Estaciones de Referencia. En 1992, el grupo de trabajo de comunicaciones de portadora de fase fue establecido a fin de enmendar el estándar RTCM versión 2 (RTCM, 1992). Como resultado, cambios en el estándar para datos de portadora de fase fueron recomendados (RTCM, 1992). RTCM versión 2.0 se actualizó a la versión 2.1 en 1994 con mensajes RTK portadora de fase y pseudo-range transmitidos como información de mediciones crudas no corregidas (Tipos 18 y 19) o como correcciones (Tipos 20 y 21) (RTCM, 1994). RTCM versión 2.2 (RTCM, 1997) se liberó en 1998, introduciendo correcciones diferenciales del sistema satelital Ruso GLONASS (Tipo 31). El Tipo 31 es equivalente al Tipo 1 de las correcciones DGPS. Sin embargo, los Tipos 18-21 no son totalmente compatibles con la versión previa. RTCM versión 2.3 (RTCM, 2001) se especificó en el año 2001 agregando más tipos de mensajes, tales como descripción de antena, número de serie de antena (Tipo 23) y coordenadas del punto de referencia de antena (ARP) en la estación de referencia (ECEF X, Y, Z), y opcionalmente altura de antena (Tipo 24). En definitiva, varios mensajes nuevos se introdujeron para mejorar RTK.
La versión RTCM 2.3 ha sido adoptada por todos los fabricantes de receptores y es aún ampliamente usada en operaciones DGPS y RTK, sin embargo presenta limitaciones. Ante todo, cada palabra contiene 24 bits de datos y 6 bits de paridad. Esta estructura desaprovecha ancho de banda, además el cálculo de paridad incluye bits desde la palabra previa. Como resultado cada mensaje no es independiente desde una palabra a la próxima. Finalmente, RTCM versión 2.3 no es suficientemente flexible para incluir nuevas señales como L2C y L5 (GPS) y otras futuras de Sistemas GNSS como GALILEO y COMPASS.

LA VERSIÓN ESTÁNDAR RTCM SC-104 VERSION 3.0

Estructura del Mensaje
RTCM SC-104 introdujo un nuevo estándar conocido como RTCM SC104 versión 3.0 (o simplemente RTCM versión 3, RTCM, 2004a) a fin de superar desventajas y mejorar las operaciones RTK. Su estructura renovada beneficia operaciones RTK y soporta redes RTK debido al eficaz ancho de banda usado durante la emisión. RTCM versión 3.0 supera limitaciones anteriores por la reestructuración del formato. Todos los mensajes RTCM 3.0 (RTCM, 2004b) comienzan con una secuencia fija de 8 bit seguidos por 6 bits reservados. Cada longitud de mensaje es variable y depende del tipo de mensaje.
El mensaje RTCM Tipo 1003 es un mensaje de dual frecuencia GPS RTK basado en mediciones crudas de pseudorange y portadora de fase. El mensaje Tipo 1003 consiste de 64 bits de información de cabecera GPS-RTK y 101 bits de cuerpo por satélite. RTCM versión 3.0 divide la corrección L1 y L2 en componentes dispersiva y no dispersiva: Ionospheric Carrier Phase Correction Difference (ICPCD) y Geometric Carrier Phase Correction Difference (GCPCD). Esto posibilita una reducción adicional en el ancho de banda por la transmisión separada hasta un 80%.

Tipos de Mensajes y Contenidos
RTCM versión 3.0 es un formato flexible desde una perspectiva operacional. Los tipos de mensaje se han organizado en grupos diferentes y cada grupo de mensajes contienen informaciones similares. Por ello, los tipos de mensajes pueden mezclarse y hay una economía en la emisión. Por ejemplo, se puede seleccionar el mensaje Tipo 1001 desde el grupo de observaciones para simple frecuencia (L1), o el mensaje Tipo 1004 para dual frecuencia (L1 y L2). Esto es así también para otros grupos tal como el punto de referencia de la antena estacionaria, descripción de antena como así también observaciones GLONASS. Aunque RTCM versión 3 supera limitaciones de RTCM versión 2, ambas no son compatibles.

RTCM SC104 VERSIÓN 3.1

Mensajes RTCM Red - RTK
El uso de la técnica Red-RTK, en lugar de simple base RTK, aumenta no sólo la distancia entre receptores, sino también la confiabilidad. El modelado de los errores sistemáticos a través de la red de Estaciones de Referencia es la clave para lograr alta precisión. Hay actualmente tres soluciones comercialmente disponibles basadas en red: FKP, VRS y MAC. FKP (Flächen Korrektur Parameter) es una técnica basada en la transmisión de parámetros de corrección desde una red de Estaciones de Referencia Continua. VRS (Virtual Reference Station), como su nombre indica, crea una estación de referencia virtual cerca del receptor remoto e interpola correcciones desde una red de Estaciones de referencia continua. Las medidas virtuales se transmiten al usuario, codificadas en el Mensaje Tipo 18/19 en el formato RTCM versión 2.3, y Mensajes Tipo 1001-1004 en RTCM versión 3.0.
Leica Geosystems y Geo++ conjuntamente propusieron una nueva solución de red basada en RTK conocida como Master Auxiliary Concept (MAC) basada en RTCM 3.0. Se ha demostrado que MAC ofrece confiabilidad y precisión más alta que FKP o VRS. El formato RTCM versión 3.1 se difundió en el año 2006 (RTCM, 2006), contiene nuevos mensajes para operaciones de red, MAC y datos de efemérides GPS/GLONASS, como así también para mensajes de texto arbitrario.

RESUMEN DE TIPOS DE MENSAJES EN DISTINTAS VERSIONES RTCM

Los tipos de mensajes que pueden ser utilizados en aplicaciones de posicionamiento diferencial en cada versión RTCM y su contenido se sintetizan en las Tablas 1 a 3.

Tabla 1. Tipos de mensajes en distintas versiones RTCM.
Table 1. Types of messages in different RTCM versions.

Tabla 2. Cuatro grupos RTCM 3.0 de mensajes GNSS RTK (RTCM, 2004).
Table 2. Four groups of RTCM 3.0 GNSS RTK messages (RTCM, 2004).

Tabla 3. Tipos de mensajes en el receptor móvil y en la estación de referencia.
Table 3. Types of messages in rover receiver and reference station.

Mensaje Tipo 1: contiene datos de todos los satélites electrónicamente visibles desde una estación de referencia. Los datos incluyen la información siguiente: correcciones diferenciales GPS (pseudo-range máximo 12 satélites) y su variación en el tiempo época a época para los satélites recepcionados, y finalmente, la estimación de la corrección en términos de multipath y la relación señal/ruido.
Mensaje Tipo 2: contiene las diferencias entre pseudorange y las correcciones desde una estación de referencia a todos los satélites electrónicamente visibles entre dos sucesivos mensajes de navegación.
Mensaje Tipo 3: incluye las coordenadas de la estación de referencia en el marco de Referencia Earth-Centred, Earth-Fixed (X, Y, Z).
Mensajes Tipo 18 y 19: contienen datos crudos de portadora de fase (Tipo 18) y pseudorang (Tipo 19) observados en la estación de referencia.
Mensajes Tipo 20 y 21: proveen correcciones de portadora de fase (Tipo 20) y pseudorange (Tipo 21).
Mensaje Tipo 23: define el tipo de antena usada, siguiendo las convenciones IGS y Tipo 24 contiene coordenadas WGS84 o PE90 del Punto de Referencia de la Antena. Mensaje Tipo 31 es similar al Mensaje Tipo 1, proveyendo correcciones diferenciales GLONASS.
Mensaje Tipo 59: es un mensaje propietario, utilizado por diferentes proveedores.

Los Mensajes Tipo 1001, 1003, 1005, 1007, 1009 y 1011 contienen información mínima requerida para proveer el servicio, mientras que los Mensajes Tipo 1002, 1004, 1006, 1008, 1010 y 1012 contienen información adicional para mejorar el desempeño del servicio diferencial.

CONCLUSIONES Y FUTURAS ENMIENDAS DE RTCM SC-104

Los estándares RTCM SC-104 actuales soportan datos GPS y GLONASS para operaciones DGNSS y RTK. La modernización del Sistema GPS provee nuevas señales, específicamente L2C y L5 y una mezcla de mediciones de fase desde señales diferentes que estarán disponibles próximamente. Sin embargo, RTCM versión 2.3 tiene limitaciones respecto de las nuevas señales GNSS y necesita extensiones para la inclusión de dichas señales. RTCM versión 3 tiene un Indicador para el código C/A en L2, bajo la suposición que ningún satélite transmitirá ambos códigos C/A y L2C sobre la señal portadora L2 simultáneamente. Por lo tanto, RTCM versión 3 puede soportar modos de traqueo de señales para código C/A en L1, código P (Y) en L1, código P (Y) en L2 y L2C.
Las señales del sistema GALILEO estarán disponibles en un futuro próximo y RTCM SC-104 versión 3 tiene flexibilidad para acomodar datos e información asociada a sus observables.

REFERENCIAS

1. ANSI X3.15-1976, (1976). American National Standard for Bit Sequencing of the American National Standard Code for Information Interchange in Serial by-Bit Data Transmission (ANSI X3.15-1976 revision of X3.15-1966). American National Standards Institute. 1430 Broadway, New York, New York 10018.         [ Links ]

2. RINEX V2 y V3. The Receiver Independent Exchange Format, [online] ftp://ftp.unibe.ch/aiub/rinex/         [ Links ]

3. RTCM, The Radio Technical Commission for Maritime Services [online] http://www.rtcm.org         [ Links ]

4. RTCM, (1990). RTCM Recommended Standards for Differential NAVSTAR GPS Service, Version 2.0.         [ Links ]

5. RTCM, (1992) Recommendations of the Carrier Phase Communications Working Group to RTCM         [ Links ]

6. Special Committee 104 (SC-104), RTCM Paper 170-92/SC-104-92, Radio Technical Commission for Maritime Services, Post Office Box 19087, Washington DC 20036, August 10, 1992.         [ Links ]

7. RTCM, (1994). Recommended Standards For Differential Navstar GPS Service, V2.1, RTCM Paper 194-93/SC104-STD, January 3, 1994.         [ Links ]

8. RTCM, (2001). Radio Technical Commission for Marine Services. RTCM Recommended Standards for Differential GNSS (Global Navigation Satellite Systems) Service, Version. 2.3.         [ Links ]

9. RTCM, 2004a. RTCM Recommended Standards for Differential GNSS (Global Navigation Satellite Systems) Service, Version 3.0, RTCM Paper 30-2004/SC104-STD.         [ Links ]

10. RTCM, (2004a). RTCM Recommended Standards for Differential GNSS (Global Navigation Satellite Systems) Service, Version 3.0, RTCM Paper 30-2004/SC104-STD.         [ Links ]

11. RTCM, (2004b). RTCM Recommended Standards for Network Transport of RTCM via Internet Protocol (NTRIP), Version 1.0, RTCM Paper 200-2004/SC104-STD.         [ Links ]

12. RTCM, (2006). RTCM Standard 10403.1 - Differential GNSS (Global Navigation Satellite Systems) Services - Version 3. Arlington, USA: Radio Technical Commission for Maritime Services.         [ Links ]

13. RTIGS: IGS Real Time Working Group, (2008). RT-IGS Prototype Network Station Information [online] http://www.rtigs.net/station.php.         [ Links ]

14. Trimble Navigation Ltd., (2005). Support of network formats by Trimble GPSNet network RTK solutions, Trimble Navigation Ltd. White paper, [online] http://trl.trimble.com/         [ Links ] Helvetica, sans-serif">15. Weber, G., (2004). Networked Transport of RTCM via Internet Protocol Version 1.0. [online], http://igs.bkg.bund.de/root_ftp/NTRIP/documentation/NtripDocumentation.pdf.         [ Links ]

Recibido: 11-8-2013
Aceptado: 18-12-2013