Categoría: Telemática

Para la gestión de la localización en GPRS interviene la red fija y la interfaz radio.

En la red fija está el SGSN Location Register (SLR) (SGSN = Serving GPRS Support Node) y el Visitor Location Register (VLR) y en una jerarquía superior, el GPRS Register (GR) que actúa como una extensión del HLR de GSM.

A nivel de celda, existen las Location Areas (LA) de GSM y a también las Routing Areas (RA) propias de GPRS. Una LA contiene varias RA.gprs_mob

El VLR y el MSC controlan las Location Areas (LA), que son entidades de área propias de GSM. Por otro lado, el SLR y el SGSN guardan información acerca de las Routing Areas (RA).

Por tanto, solo cuando hay un cambio de RA el SLR/SGSN es informado y solo cuando hay un cambio de LA el VLR/MSC es informado.

En GSM la localización se realizar a nivel de la red fija y de la interfaz radio.

A nivel de la red fija existe el Home Location Register (HLR) y el Visitor Location Register. Por una parte, el HLR guarda información sobre los usuarios que pueden acceder a la red. Por la otra parte, el VLR tiene información acerca de los usuarios que han entrado en la zona de cobertura de una Mobile Switching Center (MSC) y se han conectado.

A nivel del acceso radio, se crea la entidad de Location Area (LA). Una LA está formada por varias celdas, de manera que la red fija enruta una llamada a una LA y son las estaciones base quienes localizan mediante paging a un usuario.

location_arealoc_manag_GSM

En telefonía móvil existe el problema de la gestión de la movilidad. Cuando un usuario cambia de ubicación se debe garantizar la continuidad del servicio (handover management) así como registrar el cambio de ubicación (location management). Para ello necesitamos de tráfico de señalización que tiene que soportar la interfaz radio y la core network.
Un terminal puede estar en dos estados:

  • Idle: el terminal de usuario no está realizando ninguna llamada ni recibiendo datos.
  • Active: el terminal sí está recibiendo datos y por lo tanto al cambiar de área se debe garantizar la continuidad del servicio.

Gestión de la localización en modo idle

Para la gestión de la localización intervienen tanto la parte radio como la core network.

La interfaz radio de una estación se encarga de:

      1. Recibir actualizaciones localización del móvil (location update, LU) que envía a la core network para ser registradas. Es el terminal móvil quien realiza este envío.
      2. Buscar terminales móviles en su zona de servicio por petición de la core network (paging).

Por otra parte la core network se encarga de:

      1. Actualizar las bases de datos (database update) de localización en base a lo recibido en la location update (LU).
      2. Interrogar a la base de datos de localización para encontrar la ubicación de un usuario.

A la hora de guardar cuál es la posición de un usuario y a qué estación base está conectado, es necesario realizar un Location Update (LU) y una actualización de las bases de datos de localización de la core network.

Location update (LU)
Location update (LU)

A la hora de entregar una llamada a un usuario, se debe realizar una interrogación a las bases de datos de localización para saber en qué zona está el destino y luego las estaciones base de la zona realizarán una búsqueda en sus zonas de cobertura (paging).

call_deliveryGestión de la localización en modo activo

Cuando se está transmitiendo datos a un usuario y esté va a cambiar de celda, es necesario llevar a cabo una serie acciones para asegurar que no se va a cortar el servicio. Por ejemplo, cuando vamos en coche hablando por móvil, asegurar que la llamada no se corta. Este proceso consistente en cambiar de un canal radio a otro se conoce como handover. Es proceso se produce a nivel de celda y la core network interviene poco.

Hay varias clasificaciones de handovers:

  1. En función de cómo se lleva a cabo la conexión:
    1. Hard handover o break-before-make. Primero se corta la conexión con una estación y a continuación se establece conexión con la nueva.
    2. Soft handover o make-before-break. Durante un corto periodo de tiempo coexisten dos conexiones simultaneas, con la estación que va a desconectarse y la nueva.
  2. En función de quien intervenga:
    1. NCHO (Network Controlled Handover), en 1G.
    2. MAHO (Mobile Assisted Handover), en 2G y 3G.
    3. MCHO (Mobile Controlled Handover), en DECT.
  3. En función de la implicación de la red fija:
    1. Intracelular. El móvil cambia a otro canal radio dentro de la misma celda.
    2. Intercelular. El móvil cambio a otro canal radio que pertence a otra celda.

Para evitar congestión de celdas se suele utilizar el handover directo. Las zonas de cobertura entre dos celdas contiguas se superponen. El handover directo consiste en apurar al máximo estas zonas en las que hay cobertura de dos estaciones base de manera que si la celda a la que se está más próximo está muy saturada se evitará conectarse y se permanecerá en la más lejana pero menos saturada. Sin embargo, esto solo es válido en la zona de superposición de cobertura de dos celdas. Cuando se pasa a una zona donde solo hay cobertura de una celda, se tendrá que conectar a esa estación base.

Existen varias estrategias para actualizar la localización de un terminal de usuario. Una es realizar una actualización cada x segundos, otra es actualizar al pasar por x estaciones base diferentes o finalmente al haber recorrido x distancia.

Dependiendo del primer byte de una dirección IP es posible identificar de qué clase se trata:

  • Clase A: diseñada para dar cabida a redes extremadamente grandes. El primer bit de un dirección de Clase A es siempre un 0. Puede soportar 16 777 214 (\(2^{24} -2\) ) direcciones de host únicas, siendo el rango desde la 1.0.0.0 a la 126.0.0.0. Utiliza el primer byte para definir la red y los tres restantes para el host. Teóricamente la 127.0.0.0 también es una dirección clase A pero está reservada para la dirección de loopback.
  • Clase B: para redes de tamaño moderado a grande. Los dos primeros bits de un dirección de Clase B son 10, por tanto van desde las direcciones 128.0.0.0 a la 191.0.0.0. Al utilizar los dos primeros bytes como campo de red, da cabida para 65 534 hots (\(2^{16}-2\) ) y pueden definirse 16 382 redes diferentes (\(2^{14} -2\) ).
  • Clase C: para muchas redes y pequeñas. Los tres primeros bits de una dirección de clase C son 110, por tanto parten de la dirección 192 (128+64). El rango de redes va de 192.0.1.0 a 223.255.254.0.
Clase Primeros bits Bytes red Rango Número de redes Número de hosts
A 0 A.x.x.x 1.0.0.0 – 126.0.0.0 126 16777214
B 10 A.B.x.x 128.0.0.0 – 191.0.0.0 16 382 65 534
C 110 A.B.C.x 192.0.1.0 – 223.255.254.0 2 097 150 254

Gracias a los bots de Telegram, es sencillo interaccionar entre Telegram y una Raspberry. La idea es la siguiente:
Telegram-Raspberry
Desde la aplicación de Telegram, enviaremos un comando al servidor de Telegram. Se puede configurar mediante webhooks que redireccione este mensaje a un servidor propio con SSL, tal y como expliqué en una entrada anterior.. Este servidor con SSL reenviará la información a otro servidor montado sobre la Raspberry. En la Raspberry, recibiremos las notificaciones enviadas por el usuario. Para conseguir que el que el servidor con cifrado SSL consiga enviar a nuestra Raspberry la información, será necesario configurar la Raspberry con un IP estática y utilizar un servidor de DNS dinámicas, configurar nuestro router de casa para redireccionar todas las peticiones provinientes del exterior (de Internet) en el puerto 80 al puerto 80 de nuestra Raspberry. Este paso quizá sea el más complicado debido a la cantidad de pasos que hay que hacer, sin embargo es posible.

Sería posible utilizar un solo servidor para entregar el comando de Telegram directamente sobre la Raspberry. Sin embargo, es necesario que el servidor de la Raspberry cuente con un certificado SSL. La API de Telegram permite utilizar certificados autofirmados, sin embargo yo no lo he probado ya que disponía en el servidor de un certificado SSL de Let’s Encrypt.

En el servidor con SSL el código del archivo PHP es:

<?php
 
$bottoken = "myToken";
$website = "https://api.telegram.org/bot".$bottoken;
 
$update = file_get_contents('php://input');
$update = json_decode($update, TRUE);
 
$chatId = $update["message"]["chat"]["id"];
$message = $update["message"]["text"];
 
switch($message) {
        case "/radio":
		$result = file_get_contents('http://raspberryLocation/test.php');
		if(!strcmp($result, "Encendido"))
			sendMessage($chatId, "Enchufando radio");
		else
			sendMessage($chatId, "Apagando radio");
                break;
        case "/temperatura1":
                sendMessage($chatId, "La temperatura es de 18 ºC");
                break;
        default:
                sendMessage($chatId, "default");
}
 
function sendMessage ($chatId, $message) {
 
        $url = $GLOBALS['website']."/sendMessage?chat_id=".$chatId."&text=".urlencode($message);
        file_get_contents($url);
 
}
 
?>

Para interactuar con los pines GPIO de la Raspberry, es necesario utilizar la librería WiringPi. El principal problema que existe con esta librería es que se necesitan permisos de super usuario para poder utilizarla. Para hacer una prueba rápida, le he dado permisos de superusuario al usuario www-data, que es el que ejecuta los archivos PHP. Sin embargo, esto es potencialmente peligroso. En cuanto encuentre una solución la subiré.

En mi prueba, he hecho que al enviar un comando desde Telegram, ponga a nivel alto o bajo un pin GPIO. El script que corre en el servidor de la Raspberry cuenta de dos partes. Una escrita en C que se encarga de interaccionar con la libreria WiringPi y otra en PHP que ejecuta el programa en C propio para cada comando.

La parte de PHP es la siguiente (archivo test.php que es llamado por el servidor con SSL):

<?php
	exec("sudo ./switch", $return);
	echo($return[0]);
?>

El programa en C es el que se ejecuta con la instrucción exec() es el siguiente:

#include <stdio.h>    // Used for printf() statements
#include <wiringPi.h> // Include WiringPi library!
#include <fcntl.h>  //File management
#include <unistd.h>  //File checker
 
// Pin number declarations. We're using the Broadcom chip pin numbers.
const int radioPin = 4; // Radio pin
 
char radio[] = "radio";
 
int main(void)
{
 
    wiringPiSetupGpio(); // Initializa wiringPi -- utilizando los números de pines de Broadcom
    pinMode(radioPin, OUTPUT);
    FILE *fp;
    if(access(radio, F_OK) != -1){
    // file exists
        printf("Apagado");
        remove(radio);
        digitalWrite(radioPin, LOW);
    } else {
    // file doesn't exist
        printf("Encendido");
        fp = fopen(radio, "w+");
        fclose(fp);
        digitalWrite(radioPin, HIGH);
    }
        return 0;
}

Este programa es muy sencillo y simplemente comprueba que exista un archivo llamado radio en la carpeta donde se encuentra. Si el archivo existe, entonces quiere decir que la radio estaba encendida y por tanto elimina el archivo y apaga la radio. Si el archivo no existe, la radio estaba apagada y enciende la radio poniendo el pin a nivel alto y crea el archivo radio.

Para compilar este programa es necesario utilizar la siguiente instrucción:

gcc -Wall -o switch switch.c -lwiringPi

Es posible que sea necesario ejecutar el compilador gcc como superusuario añadiendo sudo si estáis en la carpeta del servidor (es decir /var/www).

De esta manera, es posible encender y apagar un relé, por ejemplo, si conectamos el pin en cuestión a la Raspberry. Por tanto, estaríamos controlando una lampara, una luz o una radio.

El resultado es el siguiente:

Desde el año pasado, Telegram permite crear bots para poder interaccionar con un servidor de manera automática.

La manera de crear un bot se realiza a través del BotFather, un bot de Telegram que permite crear el tuyo propio. Una vez hayamos creado nuestro bot, BotFather nos dará un token. Este token es un identificador único que solo debes saber tú ya que te dará acceso a realizar cualquier acción sobre tu bot.

Una vez creado el bot, podemos enviarle mensajes, sin embargo, nadie contestará. Existen dos maneras para acceder a los mensajes que se hayan enviado por un usuario. La primera es mediante el método getUpdates, que básicamente consiste en una escucha activa mediante un bucle para detectar que alguien nos ha enviado un mensaje. Para comprobar rápidamente que los mensajes no están llegando, podemos pegar esta URL en el navegador, cambiando MYTOKEN por nuestro token real:

https://api.telegram.org/botMYTOKEN/getUpdates

De esta manera podremos ver qué mensajes están pendientes de ser respondidos.

Para responder desde el navegador, podemos utilizar el método sendMessage:

https://api.telegram.org/botMYTOKEN/sendMessage?chat_id=CHATID&text=TEXTO

En el que tendremos que cambiar MYTOKEN por nuestro token, CHATID por el ID del chat al cual queramos respondes y que habremos obtenido del método getUpdates (ver captura anterior), y TEXT por el texto que queramos enviar.

Sin embargo, con este método ya se ve que no es demasiado cómodo utilizar un bot de Telegram.

La mejor opción es utilizar un webhook. Un webhook es un archivo PHP (o cualquier otro lenguaje que podamos correr en nuestro servidor como Python, Ruby o Java) en el que cada vez que alguien envíe un mensaje a nuestro bot, Telegram hará una llamada automática a este archivo.

De esta manera podremos automatizar totalmente la interacción con nuestro bot.
Para decirle a Telegram dónde se encuentra nuestro webhook, es necesario ejecutar la siguiente URL:

https://api.telegram.org/botMYTOKEN/setWebhook?url=https://example.com/folder/file.php

Es muy importante que nuestro servidor tenga cifrado SSL para poder hacer peticiones HTTPS sobre él. Si no dispones de uno, te recomiendo que instales el certificado de Let’s Encrypt, el cual permite crear un certificado SSL de manera totalmente gratuita. Si por el contrario tienes un certificado autofirmado, Telegram te explica como enviarles tu clave pública del certificado.

El código PHP que he utilizado para mi bot es el siguiente:

<?php
 
$bottoken = "MYTOKEN";
$website = "https://api.telegram.org/bot".$bottoken;
 
$update = file_get_contents('php://input');
$update = json_decode($update, TRUE);
 
$chatId = $update["message"]["chat"]["id"];
$message = $update["message"]["text"];
 
switch($message) {
        case "/comando1":
                sendMessage($chatId, "Has enviado el comando 1");
                break;
        case "/comando2":
                sendMessage($chatId, "Has enviado el comando 2");
                break;
        default:
                sendMessage($chatId, "default");
}
 
function sendMessage ($chatId, $message) {
 
        $url = $GLOBALS['website']."/sendMessage?chat_id=".$chatId."&text=".urlencode($message);
        file_get_contents($url);
 
}
 
?>

De esta manera, podemos responder a cada comando que hayamos definido en el BotFather de manera personalizada.

En las redes de transporte de Internet, para poder enviar grandes cantidades de información se utilizan unos protocolos especiales. Uno de ellos es SDH.

Synchronous Digital Hierarchy (SDH)

Una trama de SDH tiene una duración de 125 μs. Dentro de estos 125 μs se puede añadir información de muchos tributarios (usuarios). El número de tributarios que es posible añadir está estandarizado, de manera que las tasas binarias en SDH son:

Tasa binaria SDH Interfaz óptico Tasa binaria
STM-1 OC-3 155 Mbps
STM-4 OC-12 622 Mbps
SMT-16 OC-48 2.5 Gbps
STM-64 OC-192 10 Gbps
STM-256 OC-768 40 Gbps

Capas SDH

En el protocolo SDH existen 4 capas:

  1. Path Layer: establece conexiones end-to-end.
  2. Multiplex Section Layer: tareas de multiplexado, sincronización y protección.
  3. Regeneration Section Layer: genera las tramas y mantenimiento de la sección. Introduce o extrae los Virtual Containers.
  4. Photonic Layer: interfaz óptico por donde viaja la información

sdh_layerLas tramas de 125 μs están construidas por el contenedor básico llamado STM (Synchronous Transport Module), en el que cada uno equivale a 64 kbps.

stm

El STM-1 tiene una tasa binaria de:
\[270 \cdot 1 \cdot 9 \cdot 64~kbps = 155~Mbps\]
El STM-4:
\[270 \cdot 4 \cdot 9 \cdot 64~kbps = 622~kbps\]
La trama SDH está formada por la cabecera y la payload.
trama
Cabecera

  • Puntero con información de señalización y monitorización.
  • Información APS (Automatic Protection Switching).
  • Información sobre la estructura de la traba

Payload

También tiene una cabecera para señalización y medida de errores.
El container es la unidad básica de empaquetamiento.
Cabecera (llamada POH) + Container = Virtual Container
Los VC pueden ser de orden alto (alta velocidad) o de orden bajo (baja velocidad).
Hay containers de diferente tamaño que se tienen que encajar dentro del espacio de la payload (C2, C12, C11).
Los VC pueden ser creados por elementos no bien sincronizados, por lo que no se podrán añadir a tiempo dentro de la trama STM.

La cabecera estaba formada por un hueco llamado pointer. Este puntero se rellena con información que junto con un VC forma la unidad administrativa.
Todo el bloque de puntero + Todas las unidades administrativas = Grupo de unidad administrativa
¿Qué pasa con el tráfico de baja velocidad? ¿Cómo se puede poner dentro de la trama STM?
Con unidades tributarias = puntero + VC de bajo orden.
Varias unidades tributarias generan un grupo de unidades tributarias.

La unidad tributaria es igual que la unidad administrativa pero más pequeña. Son de VC de bajo orden.

Por orden de tamaño ascendente:

  1. Container
  2. Virtual container (VC): POH + C-n
  3. Unidad tributaria (TU): puntero + VC de bajo orden
  4. Unidad administrativa (AU): puntero + VC de alto orden
  5. Grupo de unidades tributarias (TUG): n · TU
  6. Grupo de unidades administrativas (AUG): n · AU
  7. STM-N: SOH + AUG

sdh_2

Generic Frame Procedure (GFP)
Para poder añadir información de diferentes protoclos (Ethernet, Fibre Channel, …) en una trama SDH se utiliza un procedimiento de entramado genérico. De esta manera SDH puede transportar cualquier protocolo sin importar su procedencia.
Concatenación SDH

Cuando se quiere transportar información mayor que la unidad básica, se pueden combinar varios contenedores. Por ejemplo añadir 599.04 Mbps utilizando 4 VC-4c. Sin embargo, de esta manera se desperdicia mucho espacio. Por eso, dos contenedores se enlazan mediante código y no físicamente contiguos. Esto se conoce como Virtual Concatenation Group (VCG).

Existe un método conocido como Link Capacity Adjustment Scheme (LCAS) que varía dinámicamente el ancho de banda de los contenedores de una concatenación virtual sin afectar al servicio.

Optical Transport Network (OTN)

Es un protocola (más bajo que SDH) para interconectar distintas redes de transporte. Al principio, cada fabricante lo hacía de manera diferente y por tanto no se podían interconectar entre sí.

OTN Tasa binaria Equivalente SDH
OTU-1 2.5 Gbps STM-16
OTU-2 10 Gbps STM-64
OTU-3 40 Gbps STM-256
OTU-4 100 Gbps –

Esquemas de protección

En SDH, el tiempo máximo de recuperación por un fallo del sistema sin afectar al funcionamiento de este es de 60 ms: 50 ms para la conmutación de protección y 10 ms para detectar el fallo.

Conceptos básicos
Tipos de protección

  • Protección dedicada: cada conexión activa tiene asignado su propio ancho de banda para reencaminar el tráfico en caso de fallo.
  • Protección compartida: un ancho de banda de protección para múltiples conexiones activas.

También pueden considerarse:

  • No reversibles: la conmutación de vuelta al camino activo original una vez se ha reparado un fallo es manual
  • Reversibles: cuando se detecta que el falo ha sido reparado, se conmuta automáticamente a la fibra original.

Otras taxonomías:
tax
a) Uso normal b) Unidireccional c) Bidireccional

Para notificar fallos en la red se utiliza el protocolo APS (Automatic Protection Switching).

Tipos de conmutación

conm

  1. Camino activo normal
  2. Conmutación de camino (path-switching): la conmutación de caminos se hace a nivel de path, de manera que la conexión se establece por un camino alternativo de punto a punto.
  3. Span protection: existe un camino replicado y paralelo al que ha dejado de funcionar.
  4. Conmutación de anillo. Solo se redirecciona en los nodos cuyo enlace no funciona. A diferencia del path-switching, este reencaminamiento no es punto a punto, sino que solo se da en el momento en el que el siguiente enlace no funciona.

1+1: el tráfico se transmite simultaneamente sobre dos fibras separadas.
1:1: hay 2 fibras pero el tráfico solo se envía por una. Se conmuta en caso de fallo y se notifica mediante APS (Automatic Protection Switching).
1:N: N fibras comparten un único camino de protección.

Anillos autoreparables, arquitecturas
SNCP: subnetwork connection protection
Anillo unidireccional. La fibra de protección se transmite en otro sentido. No necesita protocolo de señalización.

MS-SPRing: Multiplex Section Shared Protection Ring
El enrutamiento se realiza por el camino más corto. Hay 2 ó 4 fibras de protección.
Hay reutilización espacial: mientras la fibra auxiliar no falle, se puede aprovechar entre múltiples conexiones. Son anillos bidireccionales.

En MS-SPRing/4 hay 4 fibras. Si falla el enlace en una dirección hay una de reserva.
En MS-SPRing/2 hay 2 fibras. Cada una utiliza la mitad del ancho de banda. En caso de fallo todo el tráfico va por la otra (los dos sentidos de transmisión por la misma fibra).

Mobile IP es un estándar de protocolo comunicación diseñado para permitir a usuarios de dispositivos móviles moverse entre redes manteniendo la misma dirección IP.

Se definen dos tipos de movilidad:

  1. Macro movilidad: el desplazamiento de un móvil se produce entre dos dominios de redes diferentes.
  2. Micro movilidad: el desplazamiento de un móvil se produce entre dos subredes de un mismo dominio administrativo.

Mobile IP está definida en el marco de macro movilidad.

En el estándar Mobile IP se añaden tres nuevas entidades funcionales:

  1. Mobile Node (MN): terminal que cambia de ubicación.
  2. Home Agent (HA): router de la home network que coge los datagramas destinados al Mobile Node y los entrega a través de la care-of address. También almacena información sobre la posición actual del MN.
  3. Foreign Agent (FA): router de una red visitada que ofrece servicios de enrutado al MN mientras el MN es registrado.

MIPMobile IP permite enrutar datagramas IP independientemente de la localización del dispositivo. Cada Mobile Node (MN) es identificado por su Home Address sin importar su ubicación. Mientras está fuera de la home network, se asocia una care-of address al MN que identifica su ubicación actual y la Home Address a la cual está asociado el extremo del tunel de encapsulamiento que conecta con el Home Agent.

En Mobile IP (MIP) se utilizan dos tipos de IP: estáticas y dinámicas.

La estática es la Home Address la que le proporciona la Home Network al dispositivo. Es la IP que siempre va a tener aun cuando el dispositivo salga de la Home Network, por tanto la dirección IP permanente.

La dinámica es la care-of address, la cual es proporcionada por la Foreign Network (FN) de manera que el Home Agent pueda seguir comunicándose con el dispositivo, por tanto la dirección IP temporal.

Por tanto recapitulando, el MN tiene una IP que lo identifica en internet: la Home Address. Sin embargo, cuando el MN cambia a una red externa a la cual tenía asociada la Home Address se le tiene que asignar una IP provisional que le permita al Home Agent reenviarle los datagramas IP que el MN tiene que recibir o transmitir. Por tanto, el Foreign Agent al cual está conectado le proporciona una care-of address. Con esta care-of address el MN se comunica directamente (mediante un encapsulamiento tunel) con el Home Agent. De esta manera, aun cuando el dispositivo no está conectado en la red original se simula que la dirección IP del MN no ha cambiado, ya que el Home Agent está haciendo de proxy.

Otro forma es que no exista exista el Foreign Agent, de manera que el túnel se establece directamente entre el MN y el HA. De esta manera el MN se le asigna una co-located care-of address.Mobile IP

 

Modo de funcionamiento

  1. El MN es el encargado de descubrir si está conectado a su Home Network o se ha movido a una Foreign Network. No son los únicos responsables en este proceso sino que también intervienen la Foreign Agent y el Home Agent. Este proceso se denomina Agent Discovery. Para esto se utiliza una extensión del protocolo ICMP.
  2. El siguiente paso es registrarse en la Foreign Network para obtener la care-of address. Este proceso intervienen tanto el MN, el FA así como el HA, que debe conocer la care-of address del MN registrado es un Home Network. El proceso de registro está formado por dos mensajes, una petición de registro y una respuesta a la petición. De esta manera se informa al HA de la CoA del MN.
  3. Una vez ya están las direcciones asignadas se puede transferir información a través del túnel que conecta el Home Agent y el Foreign Agent.

perfm

Proceso de registro
Proceso de registro

Si el túnel IP solo es unidireccional se crea un problema en el que hay un enrutado triangular que no permite que la IP del Mobile Node sea la misma para recibir que para transmitir. Haciendo el túnel bidireccional se soluciona el problema.

ip_triangular_problemtriangular_problem_solution

Proceso completo de Agent Discovery, Registro y transferencia de datos
Proceso completo de Agent Discovery, Registro y transferencia de datos

Algunas desventajas del Mobile IP es que es necesario incorporar el nodo de Foreign Agent en todas las redes visitadas. También sobrecarga la red al necesitar de peticiones constantes si el MN se mueve. Otra desventaja es que es necesario implementar procesos de autentificación entre el MN y el FA y entre el FA y el HA.

En GPRS y UMTS (2.5G y 3G), GGSN (Gateway GPRS Support Node) actúa como Home Agent y el SGSN (Serving GPRS Support Node) actúa como Foreign Agent.

En 4G el P-GW (Packet data network Gateway) actúa como Home Agent y el SGW (Serving Gateway) actúa como Foreign Agent.

Mobile IPv6

Hasta ahora, todo lo referente a Mobile IP aplicaba para IPv4. Para Mobile IPv6 existen ciertas diferencias.

Por ejemplo, en Mobile IPv6 no existe la entidad de Foreign Agent (FA) ya que ha sido sustituida por el Access Router (AR).

En IPv6 existen 3 entidades funcionales, el Home Agent (HA), el Mobile Node (MN) y el Correspondent Node (CN) que es la dirección de destino de los datos.

En IPv6 el Home Agent sigue haciendo de proxy para evitar el problema del tunelado triangular que hemos explicado anteriormente.

Sin embargo, existe un modo de operación llamado Route Optimization que establece un tunel directo entre el MN alojado en una Visited Network y el CN sin pasar por el Home Agent.

mipv6