martes, 26 de febrero de 2013

Puntos extras - NS-2


Tema: Traffic Pattern Based Performance Comparison of Two Reactive Routing Protocols for Ad Hoc Networks Using NS2

Investigación echa por Suresh Kumar, R K Rathy y Diwakar Pandey.

Introducción

Ad-hoc es una colección de nodos inalambricos móviles formando una red temporal sin cable con infraestructura wire-line.

La comunicación entre los nodos se basa en radio a radio multi-hoping.

Ad-hoc son redes caracterizado por el cambio de topología frecuente debido a la movilidad de nodos. Los nodos pueden unirse y abandonar la red en cualquier momento.

Los sistemas inalambricos de la red han ganado importancia en los últimos años años mediante la combinación de la potencia de un gran número de ordenadores situados en lugares diferentes.

Todos los nodos de dichas redes se comportan como routers y tomar parte en el descubrimiento y mantenimiento de rutas a los otros nodos en la red.

De modo que el algoritmo de enrutamiento debe ser dinámico y debe ser adaptable a los cambios en la topología frecuentes debido a la movilidad del nodo.

Muchos algoritmos fueron propuestos en el documento que se puede utilizar en redes ad-hoc para la búsqueda de rutas.


En este artículo presentamos comparación de rendimiento de dos protocolos: protocolo DSR, protocolo de enrutamiento y el protocolo AODV, para llevar a cabo sus méritos relativos.

Ambos están en los protocolos de gran demanda y e inician sus actividades de enrutamiento sólo cuando sea necesario.

La motivación de esta comparación es entender su mecanismo interno de trabajo y poner de manifiesto las situaciones en que uno es preferible de usar que el otro.




Configuración de simulación 

Para la simulación se utilizo NS-2 y se cuento con el apoyo para la simulación de múltiples redes inalámbricas.

El protocolo mantenía un buffer de envío de paquetes de 64, contenía todos los paquetes de datos en espera de una ruta, tales como paquetes de descubrimiento de ruta.

Todos los paquetes de datos enviados por la capa de enrutamiento se ponen en cola en la cola de la interfaz hasta que la capa MAC puede transmitir.

La cola de la interfaz tenia un tamaño máximo de 50 paquetes y se mantiene como una cola de prioridad con dos prioridades en orden FIFO.

Los paquetes de enrutamiento obtienen mayor prioridad que los paquetes de datos.

Se generaron 50 escenarios (5 para cada tiempo de pausa) y cuatro patrones de tráfico con diferente número de fuentes para cada tipo de tráfico (CBR y TCP).

La simulación se ejecuto utilizando los anteriores escenarios y los patrones de tráfico para ambos protocolos.

Para superar el efecto de la aleatoriedad en la salida hemos tomado las medias de los resultados a obtener sus valores reales.

El objetivo de la simulación era evaluar las diferencias en el rendimiento de estos dos protocolos reactivos de encaminamiento.

Las simulaciones se llevaron a cabo variando el número de fuentes de tráfico como 10 y 40.

El tiempo de pausa era variado de 0 sec (alta movilidad) a 900 sec (sin movilidad) en un intervalo de 100 sec.

Los resultados de la simulación mostraron algunas diferencias importantes entre las características de los protocolos de enrutamiento.

La presencia de una gran movilidad implico frecuentes fallos de enlaces y cada protocolo de enrutamiento reacciona de manera diferente durante los fallos de enlace.

Los diferentes mecanismos básicos de trabajo interno llevaron a las diferencias de rendimiento en los protocolos.


Conclusión


La observación general de la simulación es que, por aplicación métricas orientadas tales como la fracción de entrega de paquetes y el retardo, AODV supera DSR en situaciones de estrés (carga alta y / o de alta movilidad), con aumento de las diferencias de rendimiento con el estrés en aumento (más carga y, de alta movilidad).

En resumen, se puede decir que para un escenario robusto la movilidad es alta, el área es grande, la cantidad de tráfico de red es más y es para un período más largo, AODV funciona mejor.

En las situaciones normales en las que una red es de carácter general, con tráfico moderado y movilidad moderada, el protocolo DSR sería la elección correcta para las aplicaciones UDP, ya que ofrece más paquetes en el destino con más bajos los gastos generales de enrutamiento.

Para las aplicaciones TCP AODV se encuentra para ser una mejor opción, además se encontró que para los resultados son comparables con los obtenidos por DSR para el tráfico CBR.

Los resultados dan vista mucho más cerca del rendimiento de los protocolos para la fracción de entrega de paquetes, el retardo promedio, y las métricas de pérdida de paquetes que por ellos.



Referencia

lunes, 25 de febrero de 2013

Reporte - Experimento de QoS

En este reporte, hice un experimento de QoS (Calidad de Servicio) donde mi utilizare mi Red para monitorear la calidad.

Para lo siguiente, utilice la herramienta de Wireshark: 
(En la entrada anterior trabaje con la herramienta y mencione algunas cosas fundamentales para utilizarlo y esta es la entrada: Reporte - sniffer: monitorear contenido)


Primero, que es QoS? 

QoS o Calidad de Servicio, son las tecnologías que garantizan la transmisión de cierta cantidad de información en un tiempo dado. 
Es especialmente importante para ciertas aplicaciones tales como la transmisión de vídeo o voz.

Ahora, la aplicación para realizar el experimento de QoS sera DailyMotion

Nota*: Mi red fue el medio de conexión para realizar el reporte.


Experimento de QoS.

Primero que nada, para este análisis utilice Dailymotion para capturar los paquetes perdidos (Packet loss), retardo en las entregas (Delay) y el ancho de banda (Band width).

Verificando paquetes perdidos:

Entramos al programa y primero que nada, usamos el filtro TCP (En este caso, para recibir paquetes de Daily Motion), debemos de tener lo siguiente: 

Después, nos aparece todos los paquetes recibidos al momento de ver un vídeo en Dailymotion, también nos aparece cuando se hace la conexión a la pagina, etc, muestra lo siguiente:

Ahora, para saber cuantos paquetes perdidos (Packet loss), checamos el IO Graph y aplicamos los filtros (tcp.analysis.lost_segment y tcp.analysis.duplicate_ack) nos muestra una pequeña linea de los paquetes perdidos y los paquetes duplicados, se muestra lo siguiente:

Como interpretamos esto?

La linea rosa, nos muestra una gran cantidad de paquetes duplicados y eso significa que hubo varios paquetes perdidos como lo muestra la linea roja, se muestra en un tiempo de 8 segundos.


Verificando el retardo de entrega de paquetes (Delay)

Ahora, para mostrar el tiempo que tardan el flujo de paquetes, para esto, debemos de seleccionar Time-Secuence Graph (tcptrace) , y nos aparecen dos ventanas, como las siguientes:
Nos vamos a la opción Cross y lo aplicamos, ahora, podremos dar click a los paquetes que se capturaron y nos muestra el tiempo cuando fue capturado, tenemos lo siguiente:

Con los círculos (color rojo) se muestra el paquete seleccionado, se da click sobre el punto de la gráfica y nos enseña que paquete se selecciono y abajo nos muestra en que segundo se capturo.

En la siguiente imagen se muestra que un paquete después de casi 6 segundos se capturo el siguiente paquete:
Verificamos que hubo un cierto retraso al momento de capturar los paquetes.

Verificando el Ancho de Banda (Band width)

Para mostrar el ancho de banda, nos vamos a la opción de Follow Graph y veremos lo siguiente:
Como se interpreta esto?
Se muestra el paquete y el flag ACK, muestra el total de Bytes y muestra el ancho de banda, que es el siguiente:

En el circulo amarillo nos muestra el ancho de banda y que es el numero 1024, es una estimación ya que no son datos exactos que proporciona Wireshark.

Conclusiones:

No existe (Bueno, al menos no encontré) una herramienta formal para tener un resultado exacto sobre QoS y para esto, tuve que interpretar los datos que nos muestra Wireshark y así mostrar gráficas y resultados cuando se realizo el experimento en la red.

Calidad de Servicio 

 Hubo algunas perdidas de paquetes en el transcurso que se abrió la pagina, se visualizo el vídeo y se cerro la pagina.

En  el retardo de entrega de paquetes hubo problemas en ese aspecto, hubo algo de tiempo prolongado  al capturar los paquetes.

Y en el ancho de banda, el dato no es tan exacto, así que el resultado es normal.

Referencias:

domingo, 24 de febrero de 2013

Laboratorio - Medidas de QoS

En esta entrada explicare algunas medidas de Calidad de Servicio que utilice para mi entrada sobre el QoS.

(Enlace de mi entrada sobre experimento de QoS: Reporte - experimento QoS).

Ancho de banda (bandwidth)

El ancho de banda es la medida de datos y recursos de comunicación disponible o consumida expresados en bit/s o múltiplos de él (ciento setenta y dos, Mbit/s, entre otros).


El uso de herramientas, como Wireshark, son útiles para el calculo del ancho de banda, no proporcionan datos extremadamente certeros, solo sirven como comprobación y comparación con las mediciones realizadas.

Una idea para calcular el ancho de banda, puede ser de la siguiente manera:

Transferimos un archivo de tamaño conocido, mediante el sniffer (Wireshark) y calculamos el tiempo en que tarda en transferirse completamente y haciendo la siguiente cuenta obtenemos el ancho de banda de la siguiente manera:

W (Bps) = carga útil (Bytes) / tiempo de transmisión (seg)


Retardo (delay)

Puede ocurrir que los paquetes tomen un largo período en alcanzar su destino, debido a que pueden permanecer en largas colas o tomen una ruta menos directa para prevenir la congestión de la red. En algunos casos, los retardos excesivos pueden inutilizar aplicaciones tales como VoIP o juegos en línea

Como se verifica en Wireshark?

Dentro del menú Statistics > TCP Stream Graphs, nos encontramos con un tipo de gráficas basado en el número de secuencia respecto al tiempo.

Este tipo de gráfica es el Time-Secuence Graph (tcptrace).

Una vez seleccionado un segmento cualquiera de la conexión TCP que nos interese de la lista de paquetes, llamamos a las gráficas de TCP para mostrar los resultados deseados.



Pérdida de paquetes (packet loss)

Paquetes sueltos

Los rute-adores pueden fallar en liberar algunos paquetes si ellos llegan cuando los buffers ya están llenos. Algunos, ninguno o todos los paquetes pueden quedar sueltos dependiendo del estado de la red, y es imposible determinar que pasará de antemano. La aplicación del receptor puede preguntar por la información que será retransmitida posiblemente causando largos retardos a lo largo de la transmisión.


Entrega de paquetes fuera de orden

Cuando un conjunto de paquetes relacionados entre sí son encaminados a Internet, los paquetes pueden tomar diferentes rutas, resultando en diferentes retardos. Esto ocasiona que los paquetes lleguen en diferente orden de como fueron enviados.

Este problema requiere un protocolo que pueda arreglar los paquetes fuera de orden a un estado isócrono una vez que ellos lleguen a su destino.

Esto es especialmente importante para flujos de datos de vídeo y VoIP donde la calidad es dramáticamente afectada tanto por latencia y pérdida de sincronía.

Errores

A veces, los paquetes son mal dirigidos, combinados entre sí o corrompidos cuando se encaminan. El receptor tiene que detectarlos y justo cuando el paquete es liberado, pregunta al transmisor para repetirlo así mismo.


Como se verifica en Wireshark?




Partiendo de una captura cualquiera y llamando a IO Graph mediante Statistics > IO Graphs, se puede aplicar una serie de filtros y que nos muestre lo siguiente:


Los filtros que se pueden utilizar para verificar lo anterior, son los siguientes:

  • tcp.analysis.lost_segment: Filtro para perdida de paquetes o segmentos.
  • tcp.analysis.retransmission: Mecanismo de rentransmision.
  • tcp.analysis.fast.retransmission: Mecanismo de rentransmision rápida.
  • tcp.analysis.duplicate_ack: Análisis de ACKs duplicados.

Para interpretar los datos dados por la grafica es facil, podemos decir que:

Si se reciben tres o más ACKs duplicados, se asume la pérdida de un segmento o paquete lost_segment esto desencadenala retransmisión de dicho segmento perdido fast.retransmission.



Referencias:

martes, 19 de febrero de 2013

Laboratorio - Cobertura de redes

Para esta semana se encargo realizar un mapa sobre las coberturas de red Wifi que estuvieran a nuestro alcance en un espacio publico, y demostrarlo con ayuda de Google Maps

*Nota: Trabaje en Windows y con el programa WirelessMon

Primero que nada, primero con la ayuda del programa antes mencionado, detecte las señales de los routers que estaban cerca del área, después detecte la fuerza de señal de las redes Wifi detectadas.

Lo que detecto el programa fue lo siguiente:

*Nota:
El programa detecta como color azul en donde estoy conectado a la red, de color verde los disponibles, y los de color rojo no disponibles, pero aun así detectaba la fuerza de señal que emiten.


Aquí una imagen donde mostraba la fuerza de red donde estaba conectado:

Ahora, lo que sigue es mostrar la fuerza de señal con ayuda de Google Maps, donde mostrare con colores la fuerza de señal.

Quedo de la siguiente manera:

Colores:

El color azul, es la red que estaba conectado y donde la fuerza era mayor, los colores como el naranja o negro eran las mas cercas.

Los otros colores muestran las demás redes que estaba cercas, lógico, la señal era mas débil.

lunes, 18 de febrero de 2013

Reporte - Sniffer: Monitorear Contenido Ilegal

Para esta entrada explicare lo que logre al momento de sniffear con Wireshark en windows.

En esta investigacion, el ataque es sobre estar informado cuando alguien quiera entrar a paginas de contenido par adultos o paginas con contenido ilegal, y para esto, utilice Wireshark:

Primero que nada, para que sirve Wireshark:

Este programa (Para Windows) permite examinar datos de una red viva o de un archivo de captura salvado en disco.

Se puede analizar la información capturada, a través de los detalles y sumarios por cada paquete.

Wireshark incluye un completo lenguaje para filtrar lo que queremos ver y la habilidad de mostrar el flujo reconstruido de una sesión de TCP.


Tutorial:

Por si apenas inician con Wireshark:

Video: Analizando Trafico de Red con Wireshark - Techdays.com.ar


Usando programa y atacando: 

Nota*: Para monitorear los datos, utilice mi propia red y no utilice otra red de personas no conocidas.

Para esta actividad utilice mi computadora para monitorear el contenido y cuando alguien entrara alguna pagina ilegal o con contenido para adultos.

Para esto, primero que nada entramos al programa, tenemos algo como lo siguiente:

Antes que nada, elegimos la red a la que vamos a monitorear (Vamos a Capure/Options/ y seleccionamos a la red que vamos a monitorear).

Después, elegimos el filtro para monitorear y capturar todo tipo de datos o paquetes que se envíen por la red, elegí HTTP:

Iniciamos el chequeo con el filtro HTTP (le damos aplicar al filtro) y se visualizan todos los datos y paquetes que pasan por mi red, y se muestra lo siguiente:

Importante: Para esta prueba, utilice la pagina de Poringa. (PRECAUCIÓN: Pagina con contenido para adultos, si no es necesario, no entre).

Ahora, cuando el usuario entra a la pagina, por medio del filtro, solo nos aparecen los datos capturados con el protocolo HTTP, y aparece lo siguiente:

Cuando el usuario entre a la pagina "Poringa", aparece esta informacion: "HTTP (text/html)".

Si elegimos click derecho a ese paquete y seleccionamos "Follow TCP Stream", nos mostrara la informacion  de la pagina que se visita, horario, fecha, etc.

Robando Contraseñas:

Por ejemplo:

Si el usuario esta registrado y entra a la pagina, hace Login y pone lo siguientes datos:
Nota*: para los datos como usario y contraseña son datos inventados.

Cuando el usuario quiere hacer Login a la pagina, nos aparece la información con la palabra "Registro/Login-submit":

Volvemos a repetir el paso de dar click derecho y seleccionar "Follow TCP Stream", mostrara lo mas importante:

Lo anterior, son los datos que usa el usuario para entrar a la pagina de "Poringa.com" y nos muestra su usuario y contraseña, que son el nick = rene y pass = 123.

Evitar uso de paginas con contenido para adulto o contenido ilegal: 

Con lo siguiente, podremos bloquear paginas con la ayuda de algún programa en Windows, ya que existen una gran variedad de herramientas y asi evitar ver contenido no apto para menores.

Ventajas:

También, sniffear es de mejor utilidad, si su uso es para detectar personas desconocidas conectadas a tu red, para monitorear el ancho de banda que se consume, para un análisis completo de tu red, etc.

martes, 12 de febrero de 2013

Reporte - Implementación de Protocolo

Para esta entrada explicare un poco lo que consta mi programa donde se trabajo con protocolos.

Pasos de programa:

Entramos al servidor:

Iniciamos con el servidor con un “port” (En mi caso, entro con 8080) y el programa espera la conexión del cliente.

Imagen:

Entramos al cliente:

Ahora, iniciamos con el cliente, entramos con el “nombre” y con el “port” (En mi caso, entro con Rene, 8080) y se inicia la ventana del juego.

Imagen:

Funcionamiento de juego:

Ahora que ya estamos en el juego, inicia la ventana,  y ahora, en la Terminal, escribimos “crea” y se crea la pelota en la ventana.

Imagen:

Código de Cliente

Código de Servidor

sábado, 2 de febrero de 2013

Resumen - Protocolo RFC

Protocolo RFC 3556 
Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

En este resumen se define la extensión para el Protocolo de Descripción de Sesión (SDP) para especificar dos modificadores adicionales para el atributo de ancho de banda.

Estos modificadores pueden utilizarse para especificar el ancho de banda permitido para RTP Control Protocol (RTCP) paquetes en una sesión Real-time Transport Protocol (RTP).

Introducción

El Protocolo de Transporte en Tiempo Real (RTP), RFC 3550, incluye un protocolo de control, el RTCP; este protocolo proporciona información de sincronización de los remitentes de los datos enviados  y la información de retroalimentación de los receptores de datos.

Normalmente, la cantidad de ancho de banda asignado al RTCP en una sesión de RTP es el 5% del ancho de banda de la sesión.

El uso de un parámetro independiente permite aplicaciones de frecuencia adaptativa para configurar un ancho de banda RTCP consistente con un ancho de banda de datos que es menor que el ancho de banda máximo especificado por el parámetro de ancho de banda para la sesión.

Eso permite que el ancho de banda del RTCP debe mantenerse bajo 5% de la anchura de banda de datos cuando la tasa se ​​ha adaptado a la baja.

Por otro lado, puede haber aplicaciones que envían datos a tasas muy bajas pero necesitan comunicar información del RTCP extra, tales como paquetes de APP.

Estas aplicaciones puede ser necesario especificar el ancho de banda RTCP que es mayor que 5% de la anchura de banda de datos.


El RTP permite un perfil para especificar que el ancho de banda del RTCP, pueden ser divididos en dos parámetros de la sesión por separado para los participantes que son emisores de datos y las que no lo son.

El uso de dos parámetros permite que los informes del RTCP se apaguen completamente para una sesión en particular mediante el establecimiento del ancho de banda del RTCP para los no remitentes de datos a cero, manteniendo el ancho de banda del RTCP para los remitentes de datos distintos de cero para que los informes de remitentes pueden enviarse por inter-sincronización.

La desactivación de informes del RTCP no es recomendable, ya que son necesarios para las funciones enumeradas en la especificación de RTP, sobre todo retroalimentación calidad de la recepción y el control de la congestión.

SDP

El Protocolo de Descripción de Sesión ( SDP ) es un formato para la descripción de Streaming Media parámetros de inicialización.


El SDP está pensado para describir multimedia sesiones de comunicación para los fines de anuncio de sesión, invitación de sesión, y la negociación de parámetros.

No entrega los medios de comunicación en sí, sino que se utiliza para la negociación entre los puntos extremos de tipo de papel, el formato, y todas las propiedades asociadas. El conjunto de propiedades y los parámetros son a menudo llamado un perfil de sesión .

Está diseñado para ser extensible para soportar nuevos tipos de medios y formatos, comenzó como un componente del Protocolo de Anuncio de Sesión (SAP), pero encontró otros usos en relación con el Protocolo de transporte en tiempo real (RTP), en tiempo real Streaming Protocol (RTSP), Session Initiation Protocol (SIP) e incluso como un formato independiente para la descripción de multidifusión sesiones.


El SDP incluye un ancho de banda opcional atribuyen con la siguiente sintaxis:

b=<modifier>:<bandwidth-value>

Donde <modifier> es una sola palabra alfanumérica que da el significado de la figura ancho de banda, y en donde las unidades predeterminadas para <bandwidth-value> son kilobits por segundo.

Este atributo especifica el ancho de banda propuesto para ser utilizado por la sesión o medios de comunicación.

Un uso típico es con el modificador "AS" (para aplicaciones específicas) que puede ser utilizado para especificar el ancho de banda total para medios individuales de un sitio.

Este memo define dos modificadores adicionales de ancho de banda:

b = RS: <bandwidth-value>

b = RR: <bandwidth-value>

Donde "RS" indica el ancho de banda asignado a el RTCP para remitentes de datos activos (tal como se define por la especificación RTP) y "RR" indica el ancho de banda asignado a el RTCP para otros participantes en la sesión de RTP (es decir, receptores).

El comportamiento exacto inducida mediante la especificación de estos modificadores de ancho de banda depende del algoritmo utilizado para calcular el intervalo de informe RTCP.

Referencias:

Laboratorio - Actividad 1 - Estándares

En esta entrada, hablare un poco sobre los problemas de estandarización o normalización, que han tenido las  empresas fabricantes con sus productos.

Existen muchos ejemplos sobre las normas que se aplican a los productos, podemos ver desde cargadores para celulares, memorias de USB, cargadores para laptops, conexión celular - automóvil, etc.

Los usuarios son los que piden comúnmente la normalización de dichos productos para tener un uso mas cómodo.

Algunos ejemplos sobre problemas de estandarización en telefonía móvil: 

Industria de celulares a estandarizar conectores a micro-USB

A principios del 2009, la GSM Association que rige los estándares de celulares GSM (es decir, los que utilizan un chip o SIM), junto a 17 otras empresas fabricantes y operadoras de celulares, llegaron a un acuerdo en donde decían que se estandarizarán en un conector universal para celulares, específicamente el micro-USB.

Micro-USB es un conector aun mas pequeño que el mini-USB que se utiliza en la mayoría de las cámaras digitales, y obviamente mucho mas pequeño que el USB estándar de nuestras PCs y laptops.

La idea era poder conectar cualquier celular a cualquier PC/laptop con un micro-USB, sin necesidad de buscar cables especializados y propietarios (como famosamente lo hace Apple con el iPhone y el iPod).

Esto no solo era abaratar estos cables, sino que evitará que tengamos que tener varios cables diferentes para todos nuestros dispositivos (aunque eventualmente estos cables también serán inútiles ya que todo se hará inalámbricamente en los próximos años), y además simplificaría el proceso para el usuario final.


Apple podría ignorar la estandarización de los cargadores de móvil

A principios del 2009, se supo que todas las compañías se han puesto de acuerdo para estandarizar un tipo específico de cargador de móvil que aparecería el primer día del año 2012 para así colaborar con el medio ambiente y unir todos los tipos de cargador en uno solo, el microUSB.

Es decir, con un solo cargador, podríamos cargar cualquier móvil.
cargador iphone
Prácticamente todas las compañías estábab conformes con esta acción, pero Apple no se ha pronunciado al respecto.

Muchos creen que Apple no querían estandarizar sus cargadores para no tener que eliminar de repente el clásico conector de 30 pines que desde hace ya una década carga nuestros iPod e iPhones.

De todos modos, se pronosticaba que para el 2012 el cargador de móviles universal estuviera presente en muchas compañías, pero no en todas.

Apple tendría que ver cómo reaccionaba el mercado ante este movimiento y actuar en consecuencia, manteniendo sus cargadores propios o verse en la necesidad de la estandarización.


Cargadores de baterías: ¡Normalización, por favor!

A principios del 2010, por parte de los fabricantes de terminales móviles para celulares, se planeaba unificar los cargadores y clavijas para una sola conexión.

Esto también podría ser utilizado por los diseñadores o fabricares de cargadores para cámaras fotográficas.

Planeaban cuales serian los detalles para lo que se aproximaba, planteaban cual seria el color de la batería cuando ya estuviera cargada, durante la carga o que ritmos nos indicaría su estado de carga, etc.

Pero, en cuanto las baterías  no se tenia la compatibilidad, era legal que cada fabricante encargaba el diseño para optimizar el tamaño y ergonomía de cada uno de sus modelos de celulares que tenian a la venta.

Ejemplo de cargador universal para cámaras digitales:
El cargador universal Ansmann era bastante original para su manejo.


El problema de carga de móviles y más gadgets: estandarización + tecnología.

A mediados del 2010, se mostraban los problemas sobre la estandarización.

Se mostraba el problema de transportar un montón de cargadores, incompatibles entre sí en su mayoría, y que no hacen sino añadir complejidad en una muestra clara de ineficiencia: por cada nuevo cacharro se adquiere un nuevo cargador, que aumenta el coste y tiene impacto medioambiental.

Al final se mostraba que lo normal es que una familia se vea con varios móviles, alguna cámara, tal vez un portátil y, en algunos casos, hay que sumar el libro electrónico o el tablet.

Ante esto hay dos vías de desarrollo de soluciones, la estandarización en las conexiones de los cargadores y el desarrollo de soluciones basadas en nuevos dispositivos.

En el primer frente teníamos la decisión de la Unión Europea de que Micro-USB sea la conexión de cargador para móviles única en 2012.

Lo anterior nos llevaba a que a medio plazo podíamos tener un mercado razonable en el que teléfono y cargador se venden de forma separada, con ahorro de costes y de impacto en el medio ambiente.

A corto plazo probablemente los precios no sólo no bajarían sino que subirían: varios son los fabricantes que tendrán que invertir en adaptar sus modelos al estándar Micro-USB.

En el otro lado de las posibles soluciones, llevo unas semanas probar el Duracell Mygrid, una especie de “plancha” para “tostar teléfonos” cuyo mayor valor es disminuir la complejidad de carga de móviles en los hogares.
La idea era poder cargar hasta cuatro terminales a la vez por el proceso de conducción eléctrica, simplemente dejándolos sobre la tostadora.

Como la mayoría de móviles y dispositivos no estában pensados para ser recargados de esta forma (por ejemplo, la Palm Pre sí que lo está), al Duracell Mygrid le acompañaban una serie de fundas adaptadoras que funcionan con iPhone y con algunos modelos de Blackberry, así como de adaptadores para modelos con Mini-Usb y MicroUSB.

Funcionaba bastante bien, aunque en términos de precio se dispara con la diversidad: eran unos 30 euros por cada adaptador por los 40 euros que costaba la “tostadora”.


Los primeros cargadores universales para teléfonos móviles estarán en el mercado a comienzos de 2011.

A principios del 2011, ya se tenia una respuesta a la demanda de los ciudadanos de poder disponer de un cargador universal para todos los teléfonos móviles y no tener que cambiar de cargador cada vez que adquieren un nuevo teléfono, la Comisión Europea solicitó a la industria que llegara a un acuerdo acerca de la solución técnica para hacer compatibles los cargadores de diferentes marcas.

Como resultado de esta solicitud, en junio de 2009 los principales productores mundiales de telefonía móvil se comprometieron a garantizar la compatibilidad de los teléfonos móviles para datos, que se espera sean predominantes en el mercado dentro de dos años, sobre la base del conector micro-USB.

El Memorando de Entendimiento con respecto a la armonización del dispositivo de carga para teléfonos móviles que se obtuvo como resultado, fue firmado por Apple, Emblaze Mobile, Huawei Technologies, LGE, Motorola Mobility, NEC, Nokia, Qualcomm, RIM, Samsung, Sony Ericsson, Texas Instruments y Atmel el 5 de junio de 2009.

Posteriormente, la Comisión emitió un mandato a los organismos europeos de normalización CEN-CENELEC y ETSI en diciembre de 2009, solicitando el desarrollo de normas europeas armonizadas para un cargador común.

Estas dos organizaciones han presentado ya las normas que permitirán la interoperabilidad de estos dispositivos, lo que significa que el nuevo cargador común será ahora compatible con teléfonos móviles de diferentes marcas.

Estas normas tienen también en cuenta los riesgos de seguridad y las emisiones electromagnéticas, y aseguran que los cargadores comunes disponen de suficiente inmunidad a las interferencias externas.

Se esperaba que la primera generación de cargadores comunes y teléfonos móviles compatibles con las nuevas normas lleguara al mercado europeo en los primeros meses de 2011.


Otros ejemplos sobre problemas de estandarización: 

La estandarización de conectividad entre automóviles y teléfonos, en marcha
La estandarización de conectividad entre automóviles y teléfonos, en marcha
Hoy en día, los smartphones son casi ordenadores en miniatura, que nos permiten hacer multitud de tareas tales como aplicaciones de ocio o productividad, música, fotos, navegación GPS o permitirnos estar conectados permanentemente a internet.
Y si los teléfonos son cada vez más inteligentes, ¿no deberían serlo también los coches?.

La conectividad entre teléfonos y automóviles será cada vez mayor, y dado que también cada vez hay mayor variedad de dispositivos móviles se hará necesaria una cierta estandarización: solo con imaginarse los modelos de teléfonos y automóviles distintos que deberán ser compatibles entre sí.

Por ello, con vistas al futuro, algunos de los fabricantes de automóviles más importantes del mundo, como Daimler, GM, Honda, Hyundai, Toyota y Volkswagen han creado el “Car Connectivity Consortium” junto a algunos fabricantes de telefonía de importancia, como Nokia, LG o Samsung.

A este “Consorcio de Conectividad” también pertenecen firmas de car audio como Alpine o Panasonic, que tienen mucho que decir al respecto en este tema, y se espera que se unan, en las próximas semanas, nuevos fabricantes de importancia.

Se pronostica un problema en todo esto, y es que contar con los fabricantes de hardware de telefonía más importantes es imprescindible, pero también lo es contar con los fabricantes del software, del sistema operativo que supone el verdadero corazón de cada smartphone.

Y por ultimo hubo grandes ausencias en ese acuerdo de colaboración: Google con Android y Apple con su iOS tendrían mucho que decir, puesto que son los dos ecosistemas más importantes y con más proyección futura, así que si esta alianza tecnológica no cuenta con estos dos actores principales la viabilidad de futuro de esta propuesta.

Para principios del 2011, la conectividad entre automóvil y teléfono era relativamente limitada.

La interacción más común entre ambos suele ser el manos libres por bluetooth, para efectuar llamadas con seguridad, la navegación por GPS con nuestro teléfono, conexión Bluetooth de streaming de audio o conexiones USB o Dock de 30 pines mediante cable para poder escuchar toda nuestra música en el equipo de sonido del coche.

Referencias: