dmr

Ejemplo de red de transporte DMR

dmr-logo

 

Desde hace un año aproximadamente tenemos un caso practico real de uso de hamnet como red de transporte de datos para otros servicios como DMR y Fusion  .

El colega EA8EE José, muy activo en hamnet, DMR , la red brandmeister ( http://www.spain-dmr.es ) , etc.

Tiene en marcha el repetidor ED8ZAB de DMR ( 438.500mhz ), Fusion ( frecuencias 438.725 mhz ), conectados a internet a través de un enlace Hamnet   RF en la frecuencia de  ( 5.685MHz ) punto a punto con el QTH de EA8AQI para poder enlazar estos servicios con el resto de su red ( enlaces a la conferencia echolink EA8SPAIN, también en analógico en 29.610 FM y 50.580 FM ToNo 88.5. En ED8ZAB-R #1017,  el tg de DMR 9108, el canal , así como el canal Cello ,  http://zello.com/dmr , y el resto del mundo.

El enlace ocupa las ips 44.133.156.65 y 44.133.206.10, mas info en http://hamnetdb.net/index.cgi?q=ed8zab

De esta manera no es necesario tener un acceso internet en la torre del repetidor que puede resultar costoso, no siempre disponible de cobertura, y en caso de emergencias no depender de la red del proveedor ISP.

Un ejemplo claro de aplicación de hamnet . Tecnología de radioaficionados para radioaficionados.

Por otro lado estamos haciendo pruebas de una pasarela DMR en una subsala de nuestro servidor de conferencias de voz IP mumble en ea4gpz.es.ampr.org. Con el Talk Group TG 9108, pero por problemas en el enlace hamnet de José, que estamos mirando aun no conseguimos que este operativo 100%, Iremos informando si conseguimos resultados positivos.

Integración DMR y Hamnet

dmr-logo

En hamnet tuvimos un hilo en la lista de correo  que creo que puede ser interesante poner aquí para abrir debate con los miembros de este foro.

La idea es que el direccionamiento BGP que se usa en hamnet de 16 bits, se vio que quedaba pequeño y en otros países se están pasando al direccionamiento de 32 bits que permite más direccionamiento. Estudiando el tema para hacerlo aquí en EA, se planteó la cuestión de integrarlo teniendo en cuenta la red DMR para que hubiera integración entre ambos sistemas.

Corte y pego los correos más interesantes:

 

parte de la discusión
se llevó en las listas de correo alemanas. Creo que la propuesta más
popular (aunque no sé si fue aceptada por todos) fue la siguiente:

“Usar el esquema

42<mcc>xxxxx

donde <mcc> son los tres dígitos de código MCC del país
(http://www.mcc-mnc.com/) y xxxxx son 5 dígitos para administrar por
cada país según se considere oportuno. Observar que algunos países
tienen varios códigos MCC según su tamaño.

En España el MCC es 214 y en Portugal 268.”

Sobre cómo asignar los 5 dígitos en España, tengo la siguiente
propuesta: Usar el código postal
https://es.wikipedia.org/wiki/C%C3%B3digo_postal_espa%C3%B1ol

Los primeros dos dígitos del código postal indican la provincia.
Ejemplo: Madrid es el 28. Además, el código 28000 (o xx000) no se usa,
por lo que si se quiere emplear un único AS para toda una provincia, se
puede usar este código postal.

Si se quiere asignar un AS distinto a cada sitio Hamnet (es lo que
estamos haciendo ahora utilizando confederaciones), se puede emplear el
código postal del municipio. Por ejemplo, mi estación está en Tres
Cantos, código postal 28760.

Dentro de cada provincia, los códigos xx070, xx071 y xx080 están
reservados por correos para usos especiales, por lo que también se les
puede dar algún uso especial en Hamnet de ser necesario.

Finalmente, los dos primeros dígitos del código van de 01 a 52. De esta
manera, quedan los dígitos 00 y 53-99 para emplear otro esquema de
asignación distinto.

¿Qué os parece esta propuesta? ¿Propuestas alternativas?

Estaría interesante llegar a un esquema de asignación en España y
empezar a usarlo.

73,

Dani.

 

me parece un sistema genial.

Los dígitos 00 y 53-99 podrían ser para lo que ahora estamos usando los 655xx

 

Luis

Entiendo que están asignando prefijos al estilo de los DMRID, MCC – zona – usuario

 

Luis

Luis, ¿puedes contarnos cómo se usan estos códigos? Oigo que en DMR y
demás se están usando asignaciones similares, pero no sé los detalles
por no estar activo en estos modos.

Estaría bien ver si se pueden compatibilizar de algún modo estas
asignaciones con las asignaciones Hamnet (quizá como propones tú).

Dani

La verdad es que sería lo suyo. Unificar la identificación de los hams con un modelo único.

En su momento ya planteé unifirmar la VoIP interna a MCCYXXX en vez de como se hace ahora.

 

Así tendríamos una id única para identificarnos en los nuevos sistemas

Además el actual sistema de VoIP a mi entender no es muy escalable.

 

Alex

en DMR se usar MCC – número de región – id

siendo id un número secuencial que te dan cuando te registras, yo fuí el número 14 en registrarme por EA5

así yo soy EA5IDN -> EA = 214, 5, 014 -> 2145014

 

Este número se usa en las redes DMR-MARC, DMR+ y BrandMeister

 

Luis

En mi opinión bastaría con tener un AS por distrito y de ahí un “edge router” que intercambiase rutas BGP con el resto de AS de la red.

Internamente en un distrito bastaría con tener OSPF y no sería necesario utilizar BGP.

 

Este “edge router” podría sumarizar las rutas de ese distrito y así ahorrar espacio en las tablas ARP

Es una propuesta que, como digo la llevo escrita desde hace tiempo

 

Alex

tres opiniones/reflexiones:

– Yo dejaría lo que está tal y como está, ya que ambas numeraciones coexisten perfectamente

– Vamos a ver cómo lo están haciendo los que ya han migrado antes de inventarnos nada

– Molaría tener un último dígito propio para poder inventarnos 9 ASs y poder jugar sin necesidad de complicar mucho las cosas (como funcionan los APRS SSID)

 

Luis

Pues la verdad que si se pudiera hacer compatible como indica Luis y además con el sistema de los modos DMR y demás, seria la bomba.

 

Pero no se si tanta integración será posible.

 

Miguel

Unificar las identidades sería algo genial.

¿posible? Si se logra coordinacion entiendo que si. Pero como vengo diciendo desde hace mucho tiempo. La radioafición ha cambiado y ahora ya no vale con “improvisar” crear aquí ,deshacer allí. Hay que tratar estas cosas de forma más seria.

 

En mi presentación del año pasado de Iberradio ya lo comentaba (ver www.slideshare.net/ssppcc) hay que planificar, diseñar y escrbir antes de pasar a la acción.

 

He visto otros proyectos en los que los “amos” (aka sysadmins) hacen y deshacen a su antojo sin:

 

– Comunicar nada a los usuarios

– Sin documentar la infraestructura

– Sin dejar opinar a los usuarios

 

Consecuencias:

 

– El usuario está perdido

– El usuario un día le funciona una cosa y al día siguiente no

– Malestar, disputas, etc…

 

No hay que llegar al extremo de tratar esto como si de un proyecto empresarial se tratase pero, lo que estamos montando requiere de mayor planificación que antaño, y requiere de tareas de las que el “radioaficionado de a pie” no está acostumbrado

 

Ya no vale improvisar, ahora hay que planificar y documentar.

 

 

Perdón por el “toston”.

 

Alex

Esta propuesta tiene sentido si cada distrito implementa esta
arquitectura de red. Tiene sus ventajas e inconvenientes. El primer
inconveniente que veo es que el distrito depende de que su edge router
no se caiga.

También, y lo que creo que es más importante, creo que hay que dejar
abierta la posibilidad de que el que lo decida pueda experimentar con
cualquier tipo de protocolos y sistemas de routing. Con esta propuesta,
fuerzas a todo el distrito a estar en una misma red OSPF.

De todas formas, tu propuesta es válida y compatible con todo lo demás.
En Austria usan algo parecido (creo, mi Alemán no da para tanto). Si un
distrito quiere establecer una red OSPF para todo el distrito, se puede
usar 00×000, con x el número del distrito. Por supuesto, esto no obliga
a que todos los sitios del distrito participen en esta red, pudiendo
usar otros protocolos de enrutamiento. También se puede hacer una red
OSPF para una provincia, usando el código xx000, donde xx es el código
de la provincia.

 

Dani

 

El 18/05/16 a las 11:15, n0p [Luis Bernal] escribió:
> tres opiniones/reflexiones:
> – Yo dejaría lo que está tal y como está, ya que ambas numeraciones
> coexisten perfectamente
> – Vamos a ver cómo lo están haciendo los que ya han migrado antes de
> inventarnos nada

Completamente de acuerdo. Esto de los AS de 32 bits salió hace meses y
yo decidí dejarlo como está porque es menos trabajo y de momento no nos
hacen falta en EA. Además, el soporte en HamnetDB no era bueno (ahora
parece que no hay problemas).

Parece que los que más se están moviendo a 32 bits, que son los
Holandeses, lo hacen por razones “políticas” (las relaciones entre
Holanda y Alemania a veces no son demasiado buenas en estos temas de 44net).

Discutir esto ahora es porque ha salido el tema y para tener algunas
ideas creadas de cara al futuro.

Dani