ES2913209T3 - Métodos, dispositivos y sistemas para implementar redes de auto organización inalámbricas híbridas centralizadas - Google Patents

Métodos, dispositivos y sistemas para implementar redes de auto organización inalámbricas híbridas centralizadas Download PDF

Info

Publication number
ES2913209T3
ES2913209T3 ES15814672T ES15814672T ES2913209T3 ES 2913209 T3 ES2913209 T3 ES 2913209T3 ES 15814672 T ES15814672 T ES 15814672T ES 15814672 T ES15814672 T ES 15814672T ES 2913209 T3 ES2913209 T3 ES 2913209T3
Authority
ES
Spain
Prior art keywords
client
server
servers
data
client device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES15814672T
Other languages
English (en)
Inventor
Tyler Reynolds
Stephen Hall
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Trinity Mobile Networks Inc
Original Assignee
Trinity Mobile Networks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Trinity Mobile Networks Inc filed Critical Trinity Mobile Networks Inc
Application granted granted Critical
Publication of ES2913209T3 publication Critical patent/ES2913209T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/122—Shortest path evaluation by minimising distances, e.g. by selecting a route with minimum of number of hops
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/04—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources
    • H04W40/10—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources based on available power or energy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/12—Communication route or path selection, e.g. power-based or shortest path routing based on transmission quality or channel quality
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método implementado en ordenador, operable en un dispositivo de telecomunicaciones en un sistema que comprende uno o más servidores, en donde dicho dispositivo es un dispositivo de cliente en dicho sistema, comprendiendo dicho método: proporcionar un estado de configuración de cliente para dicho dispositivo de cliente a dicho uno o más servidores, en donde el estado de configuración de cliente para el dispositivo de cliente incluye o se basa en información de identificación acerca del dispositivo de cliente o en información acerca de otros dispositivos con los que el cliente puede comunicarse en al menos una dirección, o ambas; obtener de dicho uno o más servidores una primera configuración de subred, comprendiendo dicha primera configuración de subred al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente, estando dicha primera configuración de subred basada en dicho estado de configuración de cliente y en al menos otro estado de configuración de cliente de al menos otro dispositivo de cliente, en donde dicha al menos una trayectoria comprende uno o más clientes intermedios, y en donde el dispositivo de cliente usa la al menos una trayectoria especificada en dicha primera configuración de subred para obtener al menos un recurso a través de dicho uno o más servidores.

Description

DESCRIPCIÓN
Métodos, dispositivos y sistemas para implementar redes de auto organización inalámbricas híbridas centralizadas
Campo de la invención
Esta invención se refiere a redes de auto organización inalámbricas híbridas y, más particularmente, para redes de auto organización inalámbricas híbridas que incluyen dispositivos de comunicaciones inalámbricas móviles.
Antecedentes
Los dispositivos de telecomunicaciones inalámbricos tales como teléfonos inteligentes, teléfonos móviles y similares se han generalizado. Tales dispositivos ya no se usan única o esencialmente para comunicaciones por voz (por ejemplo, llamadas telefónicas por voz), en su lugar son esencialmente dispositivos informáticos portables y se usan para toda clase de comunicación de datos incluyendo navegación web y similares.
El auge en el uso de dispositivos de telecomunicaciones inalámbricos, junto con la naturaleza de su uso ha provocado un aumento exponencial en la demanda de datos y servicios móviles. Sin embargo, la correspondiente infraestructura requerida no ha mantenido el nivel de esta demanda. Los dispositivos de telecomunicaciones inalámbricos se conectan a fuentes de datos esencialmente a través de redes celulares, y las portadoras celulares (es decir, los operadores de las redes celulares) no han sido capaces de soportar la demanda de datos y servicios móviles a través de solo la red celular.
Los usuarios de dispositivos de telecomunicaciones inalámbricos, tales como teléfonos inteligentes, a menudo se encuentran con problemas cuando demasiados usuarios están intentando usar muy pocos recursos de red. Por ejemplo, el tráfico de internet puede volverse lento y congestionado si existen demasiados usuarios solicitando canales de una estación base celular. Para evitar las limitaciones y costes asociados con la telefonía celular, muchos usuarios de dispositivo de telecomunicaciones inalámbrico conmutan a WiFi u otros protocolos de conexión no celulares cuando es posible. Este tipo de conmutación se hace habitualmente por un usuario que tiene que tomar medidas activas para usar protocolos de conexión no celulares (por ejemplo, elegir una red WiFi por nombre). Aunque el servicio WiFi actualmente es más barato que el servicio celular, en cualquier ubicación particular una red WiFi puede verse superada por la demanda de los usuarios. El acceso WiFi habitualmente no es gratis, y los costes asociados con tal acceso pueden hacer que el uso de la red WiFi pueda ser subóptimo, tanto con respecto a velocidad como coste. Debería apreciarse que como se usa en el presente documento el término "coste" puede referirse a cualquier coste y puede o no incluir un coste financiero.
Una solución al problema de congestión es el uso de una red en malla en la que los dispositivos de los usuarios se comunican directamente entre sí en lugar de a través de una red celular. En un sistema de este tipo, el tráfico puede pasarse desde un dispositivo de usuario a otro hasta que los datos se transmiten finalmente a una conexión disponible y rápida a la internet, y viceversa (desde pasarelas a dispositivos de petición).
Las redes en malla sufren problemas graves, siendo uno de los mayores que los dispositivos de usuario tienen problema determinando una ruta que deberían usar en la malla. Un enfoque de red en malla requiere esencialmente dispositivos para inundar la red con peticiones para construir rutas o fuerza a cada dispositivo a actualizar las conexiones de toda la red. Ambas de estas soluciones provocan una gran ineficiencia, tanto en términos de rendimiento de transmisión (conexiones inestables o caudal bajo) y agotan rápidamente la batería de dispositivos de red. La Solicitud de Patente del Reino Unido GB2507161 publicada el 23.4.2014 divulga sistemas y métodos para proporcionar mejora de rendimiento de carga y/o descarga basándose en información de realimentación de cliente y/o servidor, en donde el método divulgado detecta que un evento de transferencia de datos está a punto de producirse y basándose en un conjunto de características asociadas con el evento de transferencia de datos, selecciona un anfitrión de un grupo de anfitriones como una trayectoria para transferir datos asociados con el evento de transferencia de datos para optimizar rendimiento de transferencia de datos. La Solicitud de Patente de Estados Unidos US2009/0245243 publicada el 1.10.2009 divulga un método de envío de un paquete desde un nodo de origen a un nodo de destino en el mismo dominio de difusión, en donde el paquete se asocia con un flujo de tráfico dirigido desde el nodo de origen al nodo de destino. El nodo de origen se conecta con el nodo de destino a través de una primera y una segunda trayectoria de comunicación. Se mide un criterio basándose en un atributo del flujo de tráfico para cada una de las trayectorias de comunicación. Una trayectoria se selecciona entre la primera y segunda trayectorias de comunicación basándose en el criterio medido y la trayectoria de comunicación seleccionada se asigna al flujo de tráfico asociado. El paquete se envía a continuación a través de la trayectoria de comunicación seleccionada.
Existe una necesidad de superar los problemas provocados por múltiples dispositivos de telecomunicaciones inalámbricos que intentan usar recursos de red limitados. También existe una necesidad de superar estos problemas de una manera automática y transparente, haciendo buen uso de los recursos disponibles. También existe una necesidad de dar servicio a toda la red de forma tan buena como sea posible dadas estas restricciones.
Breve sumario de la invención
La invención se define en general por las reivindicaciones independientes. Realizaciones ventajosas se definen en las reivindicaciones dependientes.
En un primer aspecto, la invención proporciona un dispositivo de telecomunicaciones de acuerdo con la reivindicación independiente 11. Dicha al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente puede determinarse basándose en uno o más factores, incluyendo: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicha al menos una trayectoria puede comprender al menos una pasarela, que puede conectarse a la internet. Dicha primera configuración de subred para dicho dispositivo también puede basarse en configuraciones de cliente de múltiples otros dispositivos de cliente. Dicha al menos una trayectoria puede comprender una trayectoria híbrida. Dicha trayectoria híbrida puede contener segmentos de trayectoria usando interfaces de comunicación distintas. Dicha al menos una trayectoria puede comprender uno o más dispositivos de cliente intermedios. La al menos una trayectoria puede comprender al menos dos pasarelas. La primera configuración de subred puede basarse en una configuración de red satisfactoria conocida anterior. Dicho dispositivo de cliente puede obtener dicho al menos un recurso, al menos en parte, a través de una porción de dicha al menos una trayectoria. Dicha al menos una trayectoria puede comprender al menos un primer dispositivo distinto de dicho dispositivo de cliente. Dicho al menos un primer dispositivo en dicha trayectoria puede asumirse por dicho uno o más servidores para tener una copia de al menos parte de dicho al menos un recurso. Dicha al menos una trayectoria puede comprender al menos dos pasarelas y en donde dicho dispositivo de cliente obtiene dicho al menos un recurso a través de dichas al menos dos pasarelas. Dichas al menos dos pasarelas pueden seleccionarse de: pasarelas celulares, pasarelas inalámbricas no celulares y pasarelas por satélite. Dichas al menos dos pasarelas pueden incluir al menos una pasarela usando un protocolo distinto de al menos otra pasarela. Dichas pasarelas híbridas pueden comprender una primera pasarela y una segunda pasarela, y en donde dicha primera pasarela y dicha segunda pasarela son híbridas. Dicha primera pasarela puede comprender un dispositivo de pasarela celular y en donde dicha segunda pasarela comprende una pasarela no celular. Dicha segunda pasarela puede comprender una pasarela WiFi. Dicho dispositivo de cliente puede obtener dicho al menos un recurso a través de dichas al menos dos pasarelas en una relación determinada por dicho uno o más servidores. Dicha relación puede basarse en uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicho dispositivo puede obtener dicho al menos un recurso a través de dichas al menos dos pasarelas de una manera intercalada. Dicho al menos un recurso puede comprender una primera porción y una segunda porción, siendo dicha segunda porción distinta de dicha primera porción, y en donde dicho dispositivo de cliente obtiene dicha primera porción, al menos en parte, a través de dicha primera pasarela y en donde dicho dispositivo de cliente obtiene dicha segunda porción, al menos en parte, a través de dicha segunda pasarela. Dicha al menos una trayectoria especificada en dicha primera configuración de subred puede comprender múltiples subtrayectorias, incluyendo una primera subtrayectoria y una segunda subtrayectoria distinta de dicha primera subtrayectoria, y dicho dispositivo de cliente puede obtener dicho al menos un recurso a través de dicha primera subtrayectoria y dicha segunda subtrayectoria. Dicha primera subtrayectoria puede incluir una primera pasarela y dicha segunda subtrayectoria puede incluir una segunda pasarela distinta de dicha primera pasarela. Dicho dispositivo de cliente puede obtener una primera porción de dicho al menos un recurso a través de dicha primera subtrayectoria y obtiene una segunda porción de dicho al menos un recurso a través de dicha segunda subtrayectoria. Dicha primera porción puede ser distinta de dicha segunda porción. Dicho dispositivo de cliente puede obtener dicho al menos un recurso en respuesta a una petición desde dicho dispositivo de cliente a dicho uno o más servidores. Dicha petición puede comprender una petición de HTTP o HTTPS. Dicho al menos un recurso puede comprender un recurso de difusión en continuo. Dicho dispositivo puede construirse y adaptarse adicionalmente para: en respuesta a una instrucción desde dicho uno o más servidores, proporcionar un estado de configuración de cliente actualizado para dicho dispositivo de cliente a dicho uno o más servidores. Dicho dispositivo puede construirse y adaptarse adicionalmente para: determinar información acerca de otros dispositivos con los que puede comunicarse el dispositivo de cliente. Dicho dispositivo puede determinar dicha información acerca de otros dispositivos en respuesta a una instrucción desde dicho uno o más servidores. Dicho dispositivo puede construirse y adaptarse adicionalmente para: obtener desde dicho uno o más servidores una configuración de subred modificada distinta de dicha primera configuración de subred. Dicha configuración de subred modificada puede haberse determinado basándose en información de configuración de cliente desde al menos un dispositivo en dicha al menos una trayectoria de dicha primera configuración de subred. Al menos un dispositivo del cual se obtiene información de configuración de cliente puede incluir dicho dispositivo de cliente. Dicha configuración de subred modificada puede incluir al menos una nueva trayectoria que no está en dicha primera configuración de subred. Dicha al menos una nueva trayectoria puede seleccionarse basándose en uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicha primera subred puede comprender una red en malla. Al menos algunos de dicho uno o más servidores pueden coubicarse con al menos una pasarela. Dicha al menos una pasarela puede comprender unas torres celulares. Dichos al menos algunos de dicho uno o más servidores y dicha torre celular pueden operarse por un operador de red móvil (MNO). Al menos algunos de dicho uno o más servidores pueden coubicarse con un punto de acceso inalámbrico o un encaminador. Dicho estado de configuración de cliente para dicho dispositivo de cliente puede incluir o puede basarse en uno o más de: (i) la potencia de batería restante del dispositivo de cliente, (ii) si el dispositivo de cliente se alimenta externamente, (iii) si el dispositivo de cliente tiene una conexión de internet estable, (iv) la dirección IP del dispositivo de cliente, (v) la ubicación del dispositivo de cliente, (vi) la orientación del dispositivo de cliente, (v) el estado de movimiento del dispositivo de cliente, (vi) información acerca de otros dispositivos con los que puede comunicarse el dispositivo de cliente en al menos una dirección; y (vii) un estado del hardware del cliente. Dicha al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente puede comprender una pseudo pasarela. Dicho dispositivo de cliente puede tener una conexión directa a al menos una pasarela. Dicho dispositivo de cliente puede tener una conexión directa a al menos una pasarela celular. Dicho dispositivo puede ser o puede comprender un dispositivo de telecomunicaciones inalámbrico. Dicha al menos una trayectoria puede haberse seleccionado para favorecer uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente.
De acuerdo con un segundo aspecto, la invención proporciona un método implementado por ordenador de acuerdo con la reivindicación independiente 1. Dicha primera configuración de subred para dicho cliente puede basarse en configuraciones de cliente de múltiples otros dispositivos de cliente. Dicha al menos una trayectoria puede comprender una trayectoria híbrida. Dicha trayectoria híbrida puede contener segmentos de trayectoria usando interfaces de comunicación distintas. Dicha al menos una trayectoria puede haberse seleccionado para favorecer uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicha al menos una trayectoria puede comprender al menos una pasarela. La al menos una trayectoria puede comprender al menos dos pasarelas. Dicha al menos una trayectoria puede comprender al menos una pseudo pasarela. La primera configuración de subred puede basarse en una configuración de red satisfactoria conocida anterior. Dicho dicho dispositivo de cliente puede obtener dicho al menos un recurso, al menos en parte, a través de una porción de dicha al menos una trayectoria. Dicha al menos una trayectoria puede comprender al menos un primer dispositivo distinto de dicho dispositivo de cliente. Dicho al menos un primer dispositivo en dicha trayectoria puede asumirse por dicho uno o más servidores para tener una copia de al menos parte de dicho al menos un recurso. Dicha al menos una trayectoria puede comprender al menos dos pasarelas y en donde dicho cliente obtiene dicho al menos un recurso a través de dichas al menos dos pasarelas. Dichas al menos dos pasarelas pueden seleccionarse de: pasarelas celulares y pasarelas WiFi. Dichas al menos dos pasarelas pueden incluir al menos una pasarela usando un protocolo distinto de al menos otra pasarela. Dicha primera pasarela puede comprender una pasarela celular y en donde dicha segunda pasarela comprende una pasarela no celular. Dicha segunda pasarela puede comprender una pasarela WiFi. Dicho cliente puede obtener dicho al menos un recurso a través de dichas al menos dos pasarelas en una relación determinada por dicho uno o más servidores. Dicha relación puede basarse en uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicho dispositivo puede obtener dicho al menos un recurso a través de dichas al menos dos pasarelas de una manera intercalada. Dicho al menos un recurso puede comprender una primera porción y una segunda porción, siendo dicha segunda porción distinta de dicha primera porción, y dicho dispositivo de cliente puede obtener dicha primera porción, al menos en parte, a través de dicha primera pasarela y dicho dispositivo de cliente puede obtiene dicha segunda porción, al menos en parte, a través de dicha segunda pasarela. Dicho dispositivo de cliente puede obtener dicho al menos un recurso en respuesta a una petición desde dicho dispositivo de cliente a dicho uno o más servidores. Dicha petición puede comprender una petición de HTTP o HTTPS. Dicho al menos un recurso puede comprender un recurso de difusión en continuo. Dicho método puede comprender adicionalmente: en respuesta a una instrucción desde dicho uno o más servidores, proporcionar un estado de configuración de cliente actualizado para dicho dispositivo de cliente a dicho uno o más servidores. Dicho método puede comprender adicionalmente: en respuesta a una instrucción desde dicho uno o más servidores, determinar información acerca de otros dispositivos con los que el cliente puede comunicarse, en donde dicho estado de configuración de cliente actualizado incluye o se basa en dicha información acerca de otros dispositivos con los que el cliente puede comunicarse en al menos una dirección. Dicho método puede comprender adicionalmente: obtener de dicho uno o más servidores una configuración de subred modificada distinta de dicha primera configuración de subred. Dicha configuración de subred modificada puede haberse determinado basándose en información de configuración de cliente desde al menos un dispositivo en dicha al menos una trayectoria de dicha primera configuración de subred. Al menos un dispositivo del cual se obtiene información de configuración de cliente puede incluir dicho dispositivo de cliente. Dicha configuración de subred modificada puede incluir al menos una nueva trayectoria que no está en dicha primera configuración de subred. Dicha configuración de subred modificada puede haberse determinado basándose en información acerca de otros dispositivos con los que el cliente puede comunicarse. Dicha al menos una nueva trayectoria puede seleccionarse para favorecer uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicha primera subred puede comprender una red en malla. Al menos algunos de dicho uno o más servidores pueden coubicarse con al menos una pasarela. Al menos algunos de dicho uno o más servidores pueden coubicarse con un punto de acceso inalámbrico o un encaminador. Dicha al menos una pasarela puede comprender una torre celular. Dichos al menos algunos de dicho uno o más servidores y dicha torre celular pueden operarse por un operador de red móvil (MNO). Dicho estado de configuración de cliente para dicho dispositivo de cliente puede incluir o puede basarse en uno o más de: (i) la potencia de batería restante del cliente, (ii) si el cliente se alimenta externamente, (iii) si el cliente tiene una conexión de internet estable, (iv) la dirección IP del cliente, (v) la ubicación del cliente, (vi) la orientación del cliente y (v) el estado de movimiento del cliente, (vi) información acerca de otros dispositivos con los que puede comunicarse el dispositivo de cliente y (vii) un estado del hardware del cliente. El estado de configuración de cliente para el dispositivo de cliente puede incluir o puede basarse en información de identificación acerca del dispositivo de cliente. El estado de configuración de cliente para el dispositivo de cliente puede incluir o puede basarse en información acerca de otros dispositivos con los que el cliente puede comunicarse. Dicha al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente puede comprender una pseudo pasarela. Dicho dispositivo de cliente puede tener una conexión directa a al menos una pasarela celular. Dicho dispositivo de cliente puede tener una conexión directa a al menos una pasarela. Dicho dispositivo de cliente puede actuar como una pseudo pasarela para otros dispositivos de cliente. Dicho dispositivo de cliente puede ser un dispositivo de telecomunicaciones inalámbrico. Dicha trayectoria especificada en dicha primera configuración de subred puede comprender múltiples subtrayectorias, incluyendo una primera subtrayectoria y una segunda subtrayectoria distinta de dicha primera subtrayectoria, y en donde dicho dispositivo de cliente obtiene dicho al menos un recurso a través de dicha primera subtrayectoria y dicha segunda subtrayectoria. Dicha primera subtrayectoria puede incluir una primera pasarela y dicha segunda subtrayectoria incluye una segunda pasarela distinta de dicha primera pasarela. Dicho dispositivo de cliente puede obtener una primera porción de dicho al menos un recurso a través de dicha primera subtrayectoria y obtiene una segunda porción de dicho al menos un recurso a través de dicha segunda subtrayectoria. Dicha primera porción puede ser distinta de dicha segunda porción. Dicha al menos una pasarela puede conectarse a la internet. El método de acuerdo con el primer aspecto de la invención puede comprender adicionalmente: obtener al menos un recurso a través de dicho uno o más servidores y al menos una porción de una trayectoria especificada en dicha primera configuración de subred.
En un tercer aspecto, la invención comprende además un producto de programa informático de acuerdo con la reivindicación independiente 10.
En un cuarto aspecto, la invención comprende además un método implementado por ordenador de acuerdo con la reivindicación independiente 2. Dicha al menos una trayectoria puede seleccionarse para favorecer uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicha al menos una trayectoria puede comprender al menos un dispositivo de pasarela. La al menos una trayectoria puede comprender al menos dos dispositivos de pasarela. La primera configuración de subred puede basarse en una configuración de red satisfactoria conocida anterior. El método de acuerdo con el cuarto aspecto de la invención puede comprender adicionalmente: en respuesta a una petición desde dicho dispositivo de cliente, provocar que se proporcione al menos un recurso a dicho dispositivo de cliente, en donde dicho al menos un recurso puede proporcionarse a dicho dispositivo de cliente, al menos en parte, a través de una porción de dicha al menos una trayectoria. Dicha al menos una trayectoria puede comprender al menos un primer dispositivo distinto de dicho dispositivo de cliente. Puede conocerse que dicho al menos un primer dispositivo en dicha trayectoria tiene una copia de al menos parte de dicho al menos un recurso. Dicha al menos una trayectoria puede comprender al menos dos dispositivos de pasarela y en donde dicho al menos un recurso puede proporcionarse a dicho dispositivo de cliente a través de dichos al menos dos dispositivos de pasarela. Dichos al menos dos dispositivos de pasarela pueden seleccionarse de: dispositivos de pasarela celular y dispositivos de pasarela WiFi. Dichos al menos dos dispositivos de pasarela incluyen dispositivos de pasarela híbridos. Dichos dispositivos de pasarela híbridos pueden comprender un primer dispositivo de pasarela y un segundo dispositivo de pasarela, y en donde dicho primer dispositivo de pasarela y dicho segundo dispositivo de pasarela son híbridos. Dicho primer dispositivo de pasarela puede comprender un dispositivo de pasarela celular y en donde dicho segundo dispositivo de pasarela puede comprender un dispositivo de pasarela no celular. Dicho segundo dispositivo de pasarela puede comprender un punto de acceso inalámbrico o encaminador. Dicho al menos un recurso puede proporcionarse a dicho dispositivo de cliente a través de dichos al menos dos dispositivos de pasarela en una relación determinada por dicho uno o más servidores. Dicha relación puede favorecer uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. Dicho al menos un recurso puede proporcionarse a dicho dispositivo de cliente a través de dichos al menos dos dispositivos de pasarela de una manera intercalada. Dicho al menos un recurso puede comprender una porción inicial y una porción restante, siendo dicha porción restante distinta de dicha porción inicial, y en donde dicha porción inicial puede proporcionarse a dicho dispositivo de cliente, al menos en parte, por dicho primer dispositivo de pasarela y en donde dicha porción restante puede proporcionarse a dicho dispositivo de cliente, al menos en parte, por dicho segundo dispositivo de pasarela. Dicha petición de dicho cliente puede comprender una petición para dicho al menos un recurso. Dicha petición puede comprender una petición de HTTP o HTTPS. Dicho al menos un recurso puede comprender un recurso de difusión en continuo. Al menos un dispositivo del cual se obtiene información de configuración de cliente incluye dicho dispositivo de cliente. Dicha información de configuración de cliente se obtuvo desde dicho dispositivo de cliente en respuesta a una petición desde dicho uno o más servidores a dicho dispositivo de cliente para proporcionar dicha información de configuración de cliente. Dicha configuración de subred modificada incluye al menos una nueva trayectoria que no está en dicha primera configuración de subred. Dicha al menos una nueva trayectoria puede seleccionarse para favorecer uno o más de: (a) un conjunto específico de portadoras; (b) conexiones WiFi; (c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación; (e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente. El método de acuerdo con el cuarto aspecto de la invención puede comprender adicionalmente: en respuesta a una segunda petición desde dicho dispositivo de cliente, provocar que un segundo al menos un recurso se proporcione a dicho dispositivo de cliente, en donde dicho segundo al menos un recurso puede proporcionarse a dicho dispositivo de cliente, al menos en parte, a través de una porción de dicha al menos una nueva trayectoria. Dicho segundo al menos un recurso puede ser distinto de dicho primero al menos un recurso. El método de acuerdo con el cuarto aspecto de la invención puede comprender adicionalmente: supervisar aspectos de dicha configuración de subred; y modificar dicha configuración de subred basándose al menos en parte en dicha supervisión. Dicha subred puede comprender una red en malla. Al menos algunos de dicho uno o más servidores se coubican con al menos un dispositivo de pasarela. Dicho al menos un dispositivo de pasarela puede comprender una torre celular. Dichos al menos algunos de dicho uno o más servidores y dicha torre celular pueden operarse por un operador de red móvil (MNO). Al menos algunos de dicho uno o más servidores pueden coubicarse con un encaminador. Dicho estado de configuración de cliente para dicho dispositivo de cliente puede incluir uno o más de: (i) la potencia de batería restante del cliente, (ii) si el cliente puede alimentarse externamente, (iii) si el cliente tiene una conexión de internet estable, (iv) la dirección IP del cliente, (v) la ubicación del cliente, (vi) la orientación del cliente y (v) el estado de movimiento del cliente y (vii) un estado del hardware del cliente. El estado de configuración de cliente para el dispositivo de cliente puede incluir información de identificación acerca del dispositivo de cliente. El estado de configuración de cliente para el dispositivo de cliente puede incluir información acerca de otros dispositivos con los que el cliente puede comunicarse. Dicha al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente puede comprender una pseudo pasarela. Dicho dispositivo de cliente puede tener una conexión directa a al menos una pasarela celular. El método de acuerdo con el cuarto aspecto de la invención puede comprendiendo adicionalmente: registrar dicho dispositivo de telecomunicaciones con dicho sistema como dicho dispositivo de cliente. Dicho dispositivo de cliente puede soportar al menos dos protocolos de comunicación. Dicho dispositivo de cliente puede comprender un dispositivo de telecomunicaciones inalámbrico.
Breve descripción de los dibujos
Otros objetos, prestaciones y características de este documento así como los métodos de operación y funciones de los elementos relacionados de estructura, y la combinación de partes y economías de fabricación, serán más evidentes tras la consideración de la siguiente descripción y las reivindicaciones adjuntas con referencia a los dibujos adjuntos, todos los cuales forman parte de esta memoria descriptiva. Ninguno de los dibujos está a escala a no ser que se indique específicamente lo contrario.
La Figura 1 representa un sistema/marco de acuerdo con las realizaciones ilustrativas de este documento;
Las Figuras 2(A)-2(B) representan organizaciones lógicas de una instalación central de acuerdo con las realizaciones ilustrativas de este documento;
La Figura 3 representa una organización lógica de un dispositivo de acuerdo con las realizaciones ilustrativas de este documento;
Las Figuras 4(A)-4(E) representan aspectos de comunicación entre componentes del sistema de la Figura 1; Las Figuras 5(A)-5(E) son diagramas de flujo que muestran aspectos de operación ilustrativa de realizaciones de este documento;
Las Figuras 6(A)-6(X) y 7 representan aspectos de operación de acuerdo con las realizaciones ilustrativas de este documento; y
La Figura 8 representa aspectos de un sistema informático de acuerdo con las realizaciones ilustrativas de este documento.
Descripción detallada de las realizaciones ilustrativas actualmente preferidas
Glosario y abreviaturas
Como se usa en el presente documento, a no ser que se usen de otra manera, los siguientes términos o abreviaturas tienen los siguientes significados:
AP significa punto de acceso (que hace referencia en general a un dispositivo que permite o soporta dispositivos que se conectan a una red, por ejemplo, usando Wi-Fi, o normas relacionadas);
API significa interfaz de programación de aplicación;
BATMAN significa "Mejor Enfoque para Redes Móviles Ad-hoc", un protocolo de encaminamiento para redes en malla descentralizadas;
Bonjour se refiere la implementación de red de configuración cero de Apple, un grupo de tecnologías que incluye descubrimiento de servicio, asignación de direcciones y resolución de nombre de anfitrión;
GPS significa Sistema de Posicionamiento Global;
GSM, Sistema Global para Comunicaciones Móviles;
Radio Ham se refiere a radio amateur;
HTTP significa Protocolo de Transferencia de Hipertexto;
HTTPS significa Protocolo de Transferencia de Hipertexto Seguro;
IMEI significa Identidad de Equipo Móvil Internacional;
IoT significa Internet de las Cosas;
IP significa Protocolo de Internet;
LAN significa red de área local;
LTE significa Evolución a Largo Plazo, una norma de red celular de cuarta generación;
MAC significa Control de Acceso al Medio;
MNO significa operador de red móvil;
MSO significa operador de múltiples sistemas u operador multisistema;
MVNO significa operador de red virtual móvil;
NIC significa tarjeta de interfaz de red;
OEM significa fabricante de equipo original;
OLSR significa Encaminamiento de Estado de Enlace Optimizado;
OSI significa Interconexión de Sistemas Abiertos;
RAM significa memoria de acceso aleatorio;
RF significa frecuencia de radio;
SIM significa módulo de identidad de abonado o módulo de identificación de abonado;
SON significa red de auto organización;
SSID significa Identificador de Conjunto de Servicios;
TCP/IP significa el Protocolo de Control de Transmisión/Protocolo de Internet;
VPN significa red privada virtual; y
WLAN significa red de área local inalámbrica.
Un "mecanismo" se refiere a cualquier dispositivo o dispositivos, proceso o procesos, rutina o rutinas, servicio o servicios, módulo o módulos, o una combinación de los mismos. Un mecanismo puede implementarse en hardware, software, firmware, usando un dispositivo de fin especial o cualquier combinación de los mismos. Un mecanismo puede integrarse en un único dispositivo o puede distribuirse en múltiples dispositivos. Los diversos componentes de un mecanismo pueden coubicarse o distribuirse. El mecanismo puede formarse a partir de otros mecanismos. En general, como se usa en el presente documento, el término "mecanismo" puede considerarse, por lo tanto, que es una abreviatura para el término dispositivo o dispositivos y/o proceso o procesos y/o servicio o servicios.
VISTA GENERAL
Con referencia al dibujo en la Figura 1 se describe un sistema o marco 100 de acuerdo con las realizaciones ilustrativas de este documento. Múltiples dispositivos 102-1, 102-2, 102-3... 102-n (indicados en general 102) pueden conectarse a una instalación central 104 (descrita en mayor detalle a continuación), a través de una o más pasarelas 106-1, 106­ 2... (indicadas en general 106) y una más redes 108. Los dispositivos que se registran en la instalación central se denominan clientes.
Los dispositivos 102 son dispositivos de telecomunicaciones inalámbricos. Como se usa en el presente documento, un dispositivo de telecomunicaciones inalámbrico (o WTD) se refiere a cualquier dispositivo o entidad o aparato con capacidad de transmisión de datos y recepción. Ejemplos no limitantes de dispositivos de telecomunicaciones inalámbricos incluyen teléfonos móviles (tales como teléfonos celulares, teléfonos inteligentes y similares). El término dispositivo de telecomunicaciones inalámbrico no se limita por los protocolos de comunicación o sistemas usados o por el tipo de datos. Los datos pueden incluir o representar datos de voz, datos de imagen, datos de texto, datos, datos de vídeo, etc.
La instalación central 104 comprende uno o más servidores centrales 110 (denominados en general servidor o servidores centrales 110 o servidor o servidores 110) y una o más bases de datos 112 (denominados en general en el presente documento como base o bases de datos 112). El servidor o servidores centrales 110 pueden comprender un único ordenador, una red de ordenadores o un sistema distribuido. Debería apreciarse que los términos "central" con respecto a "instalación 104" y/o "servidor o servidores 110" se usa para los propósitos de descripción y pretende implicar una relación lógica entre elementos del sistema 100, y no se concibe para implicar o imponer ninguna relación física entre los componentes. Por lo tanto, no existe ningún requisito de que diversos componentes de la instalación central 104 se coubiquen o que el servidor o servidores centrales 110 se coubiquen. Tampoco existe ningún requisito de que la base o bases de datos 112 se coubiquen con el servidor o servidores 110 o entre sí.
Como se describe en el presente documento, la instalación central es un componente o colección de componentes con capacidad de uno o más de: virtualizar una red, determinar una topología de red, determinar trayectorias de transmisión, optimización de trayectoria, temporización de transmisión, canal de transmisión, comunicación de recursos remota, comunicación con dispositivos de cliente, resolución de errores de comunicación, modificación de una configuración de estado de cliente o combinaciones de los mismos.
El servidor o servidores 110 pueden comunicarse con una o más fuentes de contenido 114 (por ejemplo, servidores web remotos o similares).
Cada dispositivo 102 incluye al menos dos mecanismos de comunicación 116, incluyendo, por ejemplo, mecanismos para comunicaciones inalámbricas/RF tales como celular, WiFi, Bluetooth, satélite, etc.
Cada dispositivo 102 en el sistema 100 incluye una aplicación 118 (descrita en mayor detalle a continuación).
Los diversos dispositivos de cliente 102 y pasarelas 106 pueden formar o comprender una o más redes o subredes híbridas. Como se usa en el presente documento, una subred de dispositivos 102 se refiere a un conjunto de dispositivos en los que cada dispositivo está en alcance de transmisión o recepción de al menos otro dispositivo en el conjunto.
Estas redes o subredes se consideran híbridas en que que pueden operar a través de múltiples tipos de transmisión inalámbrica, incluyendo, por ejemplo, celular, WiFi, Bluetooth, satélite, etc. La pertenencia y topología/conectividad de red de estas una o más redes variará con el paso del tiempo. La una o más redes/subredes híbridas pueden considerarse como una red híbrida que puede tener componentes no conectados.
Puede haber una trayectoria entre dos cualesquiera nodos en una red o subred. Se considera que una trayectoria tiene una dirección, de modo que, para dos cualesquiera nodos N1 y N2 en una red o subred, la trayectoria desde N1 a N2 (en ocasiones indicadas "N1, N2") no es necesariamente la misma que la trayectoria desde N2 a N1 ("N2 , N1"). La dirección de una trayectoria habitualmente corresponde a una dirección de transmisión. Puede haber, por ejemplo, una trayectoria desde N1 a N2 pero no desde N2 a N1. Por lo tanto, por ejemplo, el nodo N1 puede ser capaz de comunicarse con el nodo N2 , pero no viceversa. Como se usa en el presente documento, se considera que una trayectoria es híbrida (es decir, una trayectoria híbrida) si contiene segmentos de trayectoria usando diferentes interfaces de comunicación. Por ejemplo, considérese una trayectoria "N1, N2 , N3" desde el nodo N1 al nodo N3. Si el segmento de trayectoria "N1, N2" usa un protocolo o interfaz diferente del segmento de trayectoria "N2 , N3", entonces la trayectoria "N1, N2 , N3" se considera híbrida. Cuando dos dispositivos pueden comunicarse usando múltiples interfaces (por ejemplo, WiFi y Zigbee), entonces cada interfaz corresponde a su propia trayectoria. Por ejemplo, si el nodo N1 puede comunicarse con el nodo N2 a través de WiFi y Zigbee, entonces se consideran dos trayectorias desde N1 a N2 , en concreto la trayectoria WiFi y la trayectoria Zigbee.
En general, si existe un segmento de trayectoria en una trayectoria que usa un protocolo o interfaz diferente de otro segmento de trayectoria en esa trayectoria, entonces la trayectoria se considera híbrida.
En una red o subred, se dice que dos nodos están conectados directamente si existe una trayectoria entre los mismos que no contiene ningún nodo intermedio. Como antes, la presencia de una conexión directa desde el nodo N1 al nodo N2 no significa necesariamente que existe una conexión directa desde el nodo N2 al nodo N1.
Como se explica en mayor detalle a continuación, preferentemente la instalación central 104 determina y mantiene una representación virtual de la red o redes híbridas de los dispositivos de cliente 102 y las pasarelas 106. Esta representación virtual incluye preferentemente uno o más de: las interfaces inalámbricas físicas de cada cliente registrado, ubicaciones de cliente, ubicaciones y capacidades de pasarela, la duración de la batería de los dispositivos, conexiones potenciales entre clientes, conexiones potenciales entre clientes y pasarelas, y conexiones potenciales entre pasarelas.
En la Figura 2(A) se muestra en mayor detalle una instalación central 104' ilustrativa, en la que la base o bases de datos 112' pueden incluir base o bases de datos de topología 200, base o bases de datos de información de cliente 202, base o bases de datos de información de dispositivo 204, base o bases de datos de información local 206, base o bases de datos de recursos 208, base o bases de datos de interfaces 210 y bases de datos misceláneas/auxiliares 212. El servidor o servidores centrales 110 incluyen preferentemente mecanismo o mecanismos de base de datos 214 que incluyen mecanismo o mecanismos de acceso a base de datos 216 y mecanismo o mecanismos de mantenimiento de base de datos 218, respectivamente para acceder y mantener las diversas base o bases de datos 112'. Debería apreciarse que el sistema 100 no está limitado por las clases o la organización o implementación de las base o bases de datos 112' o por la manera en la que se mantienen y/o acceden. Algunas bases de datos pueden necesitar ser accedidas más rápidamente que otras, y partes de tales bases de datos pueden almacenarse localmente en el servidor o servidores 110, por ejemplo, en memoria rápida tal como RAM o similar. Por ejemplo, la base o bases de datos de topología 200 pueden usarse para almacenar y mantener información acerca de la representación virtual de la red, y tal información puede necesitar ser accedida y actualizada rápidamente (en sustancialmente tiempo real).
Los mecanismos en el servidor o servidores centrales 110 de la instalación central 104 pueden realizar o comprender uno o más de los siguientes: (i) agregación y mantenimiento de representaciones virtuales de interfaces en la red particular, (ii) agregación y mantenimiento de conexiones virtuales potenciales en la red, (iii) generación de trayectoria óptima para transmisiones de datos y rutas activas, (iv) servicios de encaminamiento de datos, (v) servicios de fiabilidad de datos, (vi) servicios de petición de datos remotos y (vii) servicios de seguridad.
La instalación central 104' ilustrativa también incluye preferentemente mecanismo o mecanismos (solucionador) de análisis/determinación de trayectorias 220, mecanismo o mecanismos de gestor de trayectorias 222, mecanismo o mecanismos de gestor de datos 224, mecanismo o mecanismos de manejo de recursos 226, mecanismo o mecanismos de mantenimiento de dispositivo 228, mecanismo o mecanismos de interfaz/paquete 230, mecanismo o mecanismos de topología 232, mecanismo o mecanismos de autenticación 234 y otros mecanismo o mecanismos misceláneos/auxiliares 236.
La instalación central 104' ilustrativa se muestra únicamente a modo de ejemplo, y los expertos en la materia apreciarán y entenderán, tras la lectura de esta descripción, que pueden usarse diferentes y/u otras organizaciones y elementos.
La Figura 2(B) muestra un ejemplo de la instalación central de la Figura 2(A), que muestra algunos ejemplos de conexión entre componentes.
El servidor o servidores 110 son preferentemente capaces de comunicarse con los dispositivos 102 en el sistema 100, o bien a través de conexiones directas (por ejemplo, a través de celular, WiFi, etc.) desde una pasarela 106 o estableciendo conexiones a través de una pseudo pasarela. Como se usa en el presente documento, una pseudo pasarela se refiere a un dispositivo de cliente en la red que tiene una conexión de enlace ascendente directo a una pasarela. Una pseudo pasarela puede usar su conexión al servidor central (a través de una pasarela) para retransmitir datos de petición para otro dispositivo o dispositivos que no tienen una conexión directa a una pasarela. Debería apreciarse que, en la práctica, no todo dispositivo de cliente con una conexión de enlace ascendente directo a una pasarela se elegirá para actuar como una pseudo pasarela. Análogamente, cada cliente 102 tiene preferentemente capacidad de comunicación con el servidor o servidores centrales 110, o bien a través de conexión directas o a través de una pasarela o pseudo pasarela. Una pseudo pasarela debería tener una conexión al cliente para el que está retransmitiendo datos de petición o bien directa o bien indirectamente a través de otro cliente al que la pseudo pasarela tiene una conexión directa.
Una realización ilustrativa preferible del servidor o servidores centrales 110 comprende una o más internet conectadas (por ejemplo, un servidor web o series de servidores web) que proporcionan las funciones descritas anteriormente en una combinación de software y hardware. En tales implementaciones, el servidor o servidores web pueden recibir datos a través de la Internet desde una fuente de red de retorno (por ejemplo, una conexión de cable de fibra óptica a un ISP). El servidor o servidores 110 pueden comunicarse directamente con las pasarelas 106, los dispositivos de cliente 102 y servidores web remotos, por ejemplo, a través de redes de TCP/IP. Otras realizaciones ilustrativas del sistema pueden implicar una red distribuida de dispositivos que cooperan para realizar estas funciones. Un ejemplo puede implicar una serie de encaminadores WiFi inteligentes que se comunican usando la Internet y coordinan sus transmisiones inalámbricas.
Debería apreciarse que cada servidor puede ser o comprender o implementarse en un dispositivo informático. A continuación se analizan los dispositivos informáticos en mayor detalle.
Independientemente de su implementación, una responsabilidad primaria de la instalación central 104 es coordinar el flujo de datos en la red combinando al menos alguno de: datos de topología proporcionados por los clientes, transmisiones de paquetes anteriores y errores de transmisión, y otros datos que pueden obtenerse/usarse por la instalación central 104 para tomar decisiones de encaminamiento informadas.
En la Figura 3 se muestra una estructura lógica de un dispositivo de cliente 102 ilustrativo e incluye las aplicaciones de cliente (o software de cliente) 336 (que corresponden, al menos en parte, a las aplicaciones 118 en la Figura 1) y el almacenamiento de cliente 338. Las aplicaciones de cliente 336 son mecanismos, implementados preferentemente, al menos esencialmente, en software, que se ejecutan en el dispositivo 102. Las aplicaciones de cliente 336 puede incluir aplicaciones de sistema/administrativas 340, una aplicación 342 (también denominada "APP" 342) que implementa aspectos de este documento, y otras aplicaciones misceláneas/auxiliares 344. El almacenamiento de cliente 338 puede ser parte del almacenamiento en el dispositivo de cliente 102 o puede ser almacenamiento de fin especial para las aplicaciones de cliente 336. El almacenamiento de cliente 338 puede incluir almacenamiento de datos de sistema/administrativos 346 para su uso por las aplicaciones de sistema/administrativas 336, almacenamiento de datos de APP 348 para su uso por la APP 338, y almacenamiento de datos misceláneos/auxiliares 350 para su uso por aplicaciones misceláneas/auxiliares 344. Debería apreciarse que la denominación y organizaciones lógicas de las aplicaciones y almacenamiento descrito en el presente documento se proporcionan únicamente a modo de ejemplo, y que en el presente documento son posibles y se contemplan diferentes y/u otros nombres y estructuras organizativas.
Con referencia de nuevo a la Figura 1, preferentemente cada dispositivo 102 comprende un dispositivo de telecomunicaciones inalámbrico tal como un teléfono inteligente, tableta, portátil, Asistente Digital Personal (PDA) u otro dispositivo que tiene la capacidad de enviar y/o recibir datos. El software de red de auto organización (SON) de lado de cliente se integra preferentemente con el sistema operativo del dispositivo y el hardware del dispositivo para detectar y utilizar las interfaces de red por cable e inalámbricas del dispositivo a través de uno o más controladores de dispositivo usando uno o más protocolos, tales como WiFi Directo, Bluetooth, Zigbee o LTE Directa. Debería apreciarse que en el presente documento pueden usarse y se contemplan diferentes y/u otros protocolos.
El software de lado de cliente preferido (por ejemplo, la APP 342) puede gestionar estas interfaces inalámbricas, detectar y gestionar una colección de pasarelas vecinas y dispositivos vecinos, y mantener una tabla de encaminamiento interna de instrucciones para comunicarse con estas pasarelas y pares.
Como se ha indicado anteriormente, cada dispositivo 102 incluye preferentemente al menos dos mecanismo o mecanismos de comunicación 116. Estos pueden incluir mecanismos que expanden múltiples bandas de frecuencia inalámbricas y protocolos/normas inalámbricas. Estas frecuencias o normas pueden incluir, sin limitación, las IEEE 802.1 1a, b, g, n, ac, ad, h, p, j, ah, y y normas que operan en las bandas de 2,4 GHz y 5 GHz, bandas GSM celular, LTE, 3GPP, radio Ham y APRS, Zigbee 400 MHz WiFi, bandas de comunicación vehicular de 5,9 GHz, y cualquier otra frecuencia para los expertos en la materia.
Debería apreciarse que cada dispositivo 102 puede ser o comprender o implementarse en un dispositivo informático. A continuación se analizan los dispositivos informáticos en mayor detalle.
Con referencia a la Figura 4(A), un dispositivo 102' (o D1) puede incluir n mecanismos de comunicación que expanden n bandas de frecuencia inalámbricas y/o protocolos inalámbricos. Cada banda de frecuencia/protocolo inalámbrico proporciona comunicación inalámbrica a través de un correspondiente alcance particular (indicados R1, R2, R3... Rn en el dibujo en la Figura 4(A)). En este y en dibujos posteriores, para simplificar los dibujos, los dispositivos pueden mostrarse con formas de diamante, con o sin referencias. Aunque los diversos alcances se muestran como círculos, debería apreciarse que el alcance de cualquier banda de frecuencia/protocolo inalámbrico particular puede no ser uniforme y puede verse afectado por diversos factores, incluyendo objetos físicos (incluyendo una persona que sujeta el dispositivo). Debería apreciarse también que un dispositivo particular puede tener diferentes alcances de envío y recepción para la misma banda de frecuencia/protocolo inalámbrico. En aras de las explicaciones en el presente documento, no se muestran estas diferencias.
Los diversos dispositivos 102 pueden ser capaces de comunicarse directamente entre sí usando múltiples banda de frecuencia/protocolos inalámbricos. Durante el resto de esta descripción, una combinación de una banda de frecuencia y protocolo inalámbrico se denominará como un protocolo. En el ejemplo en la Figura 4(B), el dispositivo D1 puede comunicarse a través de un primer protocolo con un alcance R1, a través de un segundo protocolo con un alcance R2, a través de un tercer protocolo con un alcance R3 y a través de un cuarto protocolo con un alcance R4. El dispositivo D2 puede comunicarse a través del primer protocolo con un alcance R1', a través del segundo protocolo con un alcance R2' y a través del tercer protocolo con un alcance R3'. El dispositivo D2 está dentro de los alcances R2, R3 y R4 del dispositivo D1. El dispositivo D1 está dentro de los alcances R1' y R2' del dispositivo D2. Dado que el dispositivo D2 no soporta comunicación del cuarto protocolo, los dispositivos D1 y D2 pueden ser capaces de comunicarse a través del primer, segundo o tercer protocolos. Sin embargo, en particular, en este ejemplo, el dispositivo D1 no está dentro del alcance R3' del dispositivo D2, por tanto aunque los dispositivos D1 y D2 comparten la interfaz para el tercer protocolo, el dispositivo D2 puede recibir comunicaciones desde el dispositivo D1 en el tercer protocolo, pero el dispositivo D1 no puede recibir comunicaciones desde el dispositivo D2 usando el tercer protocolo. En otras palabras, la trayectoria de comunicación entre los dispositivos D1 y D2 usando el tercer protocolo es una trayectoria unidireccional. De manera similar, la comunicación entre D2 y D1 es unidireccional desde D2 a D1 usando el primer protocolo ya que D2 no está dentro del alcance de R1. Una trayectoria de comunicaciones puede ser posible desde D1 a D2 usando el segundo y tercer protocolos. Una trayectoria de comunicaciones puede ser posible desde D2 a D1 usando el primer y segundo protocolos.
Las trayectorias de comunicación en una red incluyen una dirección. Por lo tanto, solo porque puede haber una trayectoria desde el dispositivo D1 al dispositivo D2 (con cualquier protocolo particular), esto no significa que existe una trayectoria en la otra dirección (desde D2 a D1), y viceversa. Dos dispositivos pueden comunicarse usando un primer protocolo en una dirección y un segundo protocolo diferente en la otra dirección. Por ejemplo, dos dispositivos Da y Db pueden comunicarse usando protocolo P i desde Da a Db y usando un protocolo P2 diferente desde Db a Da .
Las Figuras 4(C) y 4(D) muestran un ejemplo en el que tres dispositivos (D1, D2 y D3) pueden comunicarse a través de diversos protocolos. Una flecha desde un dispositivo a otro (por ejemplo, desde D1 a D2) significa que el dispositivo D2 puede recibir transmisiones desde el dispositivo D1 en uno o más protocolos. Por ejemplo, los dispositivos D1 y D2 pueden estar en alcance entre sí de modo que D2 puede recibir comunicación desde D1 usando Bluetooth, WiFi, LTE y Zigbee. Los dispositivos D1 y D3 pueden estar en alcance entre sí de modo que D1 puede recibir transmisiones desde D3 únicamente en WiFi.
La Figura 4(E) muestra un ejemplo de tres dispositivos (D1, D2, D3) que se comunican entre sí. El dispositivo D1 se comunica con el servidor o servidores 110 de la instalación central 104 a través de la pasarela 106. Obsérvese que cada dispositivo potencialmente tiene la capacidad de conectarse a la instalación central 104 a través del sistema celular (por ejemplo, a través de la torre 152). En la Figura 4(E) se muestran diversos protocolos y tasas de transmisión de ejemplo por medio únicamente de ejemplo.
Realizaciones preferidas de este documento son agnósticas a la conexión. La instalación central 104, que tiene información en tiempo real completa o casi completa acerca de la topología de la red, demanda y disponibilidad de espectro, disponibilidad de red de retorno y conexiones potenciales para áreas en la red, y hace el encaminamiento y decisiones de conexión que expanden múltiples bandas de frecuencia inalámbricas y protocolos inalámbricos. Estas frecuencias o normas pueden incluir, sin limitación, las IEEE 802.11a, b, g, n, ac, ad, h, p, j, ah, y y normas que operan en las bandas de 2,4 GHz y 5 GHz, bandas GSM celular, LTE, 3GPP, radio Ham y a Pr S, Zigbee 400 MHz WiFi, bandas de comunicación vehicular de 5,9 GHz, y cualquier otra frecuencia para los expertos en la materia. Las decisiones de transmisión de servidores centrales incluyen, pero sin limitación, la elección de canal o canales en los que se transmiten datos, la temporización de las transmisiones de datos, el conjunto y orden de dispositivos a través de los que se envían los datos, el ancho de banda de canal, la potencia en la que deberían difundirse los datos y/u otros factores.
Una realización preferible de este documento resuelve un número de problemas en redes inalámbricas actuales. Estos problemas incluyen ubicaciones de mala cobertura en el área de servicio, agotamiento de batería ineficiente, coordinación de malla de múltiples saltos, optimización de red, facturación eficiente en una red de múltiples saltos y decisiones con referencia a cómo y cuándo los dispositivos se conectan con otros dispositivos y pasarelas. Por ejemplo, realizaciones de este documento pueden intentar minimizar el agotamiento de batería total a través de parte o todo el sistema para cualquier transmisión dada.
Aunque se describe una instalación central 104 en este punto, los expertos en la materia comprenderán y apreciarán, tras la lectura de esta descripción, que múltiples instalaciones centrales pueden estar presentes en un sistema o marco. Por ejemplo, un MNO puede soportar múltiples instalaciones centrales y coubicar una o más instalaciones centrales en diversas torres celulares. En tales casos el alcance o cobertura de cada instalación central individual correspondería, al menos en parte, al alcance de la torre celular en la que se ubica. En otro ejemplo, una instalación central 104 puede ubicarse en un encaminador o dispositivo similar.
OPERACIÓN DEL SISTEMA
La operación del sistema 100 se describe en este punto. En algunos casos la operación de clientes y servidor o servidores centrales se describen de forma separada. Aunque el servidor o servidores centrales 110 pueden comprender más de un servidor, la siguiente descripción usa el singular "servidor 110" para referirse a los mismos y su operación, individual o colectivamente.
Dispositivos y clientes
Como se usa en el presente documento, un dispositivo se refiere a una entidad tal como un dispositivo de telecomunicaciones inalámbrico - WTD (por ejemplo, un teléfono inteligente, tableta, dispositivo de telecomunicaciones inalámbrico, dispositivo de IoT, repetidor WiFi o dispositivo informático o similar) con capacidad de transmisión, recepción de datos, mientras que un cliente se refiere a un dispositivo registrado en la instalación central 104.
Fase de arranque
Arranque de cliente
Preferentemente el cliente (es decir, el software de cliente, por ejemplo, la APP 142) se inicia automáticamente en los dispositivos. El sistema operativo (SO) del dispositivo, cargador de arranque, núcleo, o una aplicación de espacio de usuario inicia el software de cliente en el que se ejecuta preferentemente en segundo plano mientras el dispositivo está encendido.
Los dispositivos preferentemente proporcionan una o más interfaces inalámbricas físicas en hardware (por ejemplo, como el mecanismo o mecanismos de comunicación 116). Tales interfaces pueden incluir una interfaz de radio HAM, una interfaz celular compatible con LTE, una interfaz WiFi y/o una interfaz de satélite. El sistema operativo de cada dispositivo descubre y registra el hardware de cada dispositivo con el sistema operativo y hace el mismo disponible al software que se ejecuta en el dispositivo.
Tras cargar el software de cliente, el software de cliente (por ejemplo, la APP 142) consulta el sistema operativo del dispositivo en busca de interfaces de radio inalámbricas físicas y sus capacidades. Estas interfaces y capacidades se gestionan habitualmente por el sistema operativo del dispositivo como interfaces inalámbricas y exponen controladores, protocolos y capacidades a programas de software que se ejecutan en el dispositivo. Esta información se hace accesible al software de cliente. Ejemplos de tales interfaces incluyen una interfaz WiFi, una interfaz celular, una interfaz de radio HAM y una interfaz de satélite.
La interfaz de software de cliente también puede mantener, por ejemplo, en la memoria del dispositivo, una lista de interfaces sintéticas que exponen capacidades adicionales del dispositivo o su hardware. Un ejemplo es una interfaz de control que utiliza la conexión de internet por defecto de un dispositivo para encaminar paquetes. Otro ejemplo es una interfaz de GPS que se interconecta con un receptor de GPS conectado al dispositivo. Las interfaces sintéticas podrían limitarse o restringirse por las capacidades del hardware del dispositivo. En estas situaciones, el software de cliente también puede mantener un registro (por ejemplo, un registro de software) de interfaces físicas y sintéticas y el hardware físico que virtualizan. Por ejemplo, tanto la interfaz WiFi como la interfaz de internet por defecto pueden usar el hardware WiFi del dispositivo. El sistema operativo del dispositivo o el software de cliente puede realizar un seguimiento de estas dependencias y notificar opcionalmente las mismas al servidor central.
Usando la lista de interfaces inalámbricas potenciales, el software de cliente identifica interfaces que tienen capacidad de comunicación fiable y/o accesibilidad al servidor o servidores centrales 110. Estas interfaces pueden marcarse internamente como con capacidad de actuar como conexiones directas al servidor o servidores centrales 110.
El software de cliente también puede mantener un número de métricas específicas de dispositivo que puede notificarse al servidor o servidores 110 si/cuando sea necesario. Estas métricas podrían incluir la potencia de batería restante del cliente, si el cliente se alimenta externamente, si el cliente tiene una conexión de internet estable, la dirección IP del cliente, ubicación, orientación y/o movimiento, u otras métricas. El software de cliente también puede mantener información de identificación tal como un número de serie, nombre y modelo de dispositivo, versión de software o identificador único específico del fabricante, u otros identificadores. Esta información puede proporcionarse al servidor o servidores 110 para que determinen información acerca del dispositivo y sus capacidades.
Arranque de servidor
En realizaciones preferidas actualmente, se inicia un servidor central 110 y crea o se conecta a una serie de estructuras de datos o bases de datos iniciales (por ejemplo, las bases de datos 112) y hace las mismas accesibles. Estas bases de datos pueden incluir, información de sesiones anteriores (por ejemplo, de la última sesión ejecutada), las ubicaciones y otras métricas de zonas de acceso WiFi, estaciones base celulares, y otras pasarelas en el área de servicio del servidor, una base de datos de clientes eligibles, e información de cuenta y de facturación de los clientes.
Dependiendo de su configuración, un servidor puede iniciar, a continuación, una serie de conexiones remotas a bases de datos externas (por ejemplo, algunas de la base o bases de datos 112) o servidores y puede obtener información adicional no almacenada o recuperable localmente. Una realización típica implica el servidor consultando y almacenando en caché desde bases de datos remotas (por ejemplo, las bases de datos de información de dispositivo 124 y las bases de datos de información locales 126) que contienen los números de serie, direcciones de MAC de zonas de acceso o dispositivos, MMC (Tarjeta Multimedia), IMEI o información de clientes relacionada con SIM almacenada localmente, o un número de otras métricas necesarias para restaurar el estado del servidor o inicializar la funcionalidad del servidor dentro del área de servicio.
El servidor 110 también puede establecer una o más estructuras de registro en hardware o software para realizar seguimiento de su propio rendimiento, el rendimiento de red o el rendimiento de clientes conectados.
Finalmente, el servidor central 110 comienza a alojar una o más interfaces de escucha para recibir datos desde clientes. Un ejemplo típico comprende un servidor web de TCP/IP que comienza a escuchar en busca de conexiones de TCP/IP en un puerto de control particular del servidor web.
FASE 1 - Inicio, registro, autenticación
Los dispositivos que ejecutan el software de cliente comprueban periódicamente su accesibilidad a la instalación central 104 o a la internet para interfaces con capacidad de conectarse al servidor o servidores centrales 110. El software de cliente (por ejemplo, la APP 342) puede usar servicios de sistema proporcionados por un sistema operativo del dispositivo para ayudar en la determinación de la conectividad de red. Por ejemplo, en un dispositivo basado en Android, puede usarse el servicio de Gestor de Conectividad de Android. En microteléfonos iOS, los servicios de accesibilidad de CFNetworking pueden usarse para este propósito.
Estos servicios pueden usar servicios de descubrimiento de red preexistentes tales como la red Bonjour de Apple, tramas de baliza u otras técnicas para alcanzar el servidor o servidores 110 y/o la pasarela o pasarelas 106 que se conectan al servidor o servidores. Las interfaces o dispositivos que no proporcionan actualizaciones de accesibilidad pueden interrogarse periódicamente para determinar su accesibilidad o pueden intentarse conexiones en estas interfaces con un cierto tiempo de espera. La planificación de interrogación puede almacenarse en el software de cliente y habitualmente incluye una frecuencia de interrogación y/o tiempo de espera en segundos. Cuando se intentan conexiones en interfaces orientadas sin conexión, un dispositivo puede transmitir uno o más paquetes periódicamente desde la interfaz de acuerdo con una planificación predeterminada y esperar una respuesta desde el servidor para comenzar el proceso de registro.
Independientemente del tipo de interfaz, el software de cliente preferentemente simultáneamente intenta conexiones en todas las interfaces elegibles al servidor o servidores centrales 110 de acuerdo con la planificación de conexión de cada interfaz. Esta información puede transmitirse usando una interfaz de conexión de internet por cable, una interfaz de enlace de radio preestablecida (tal como una conexión celular a una portadora), a través de una interfaz de satélite, a través de una interfaz de frecuencia de largo alcance (tal como radio AM/FM), a través de una interfaz de red con capacidad de establecer una conexión directa con otro dispositivo o malla, o a través de una interfaz conectada a internet tal como celular o WiFi. Durante tales conexiones, en el caso de un intermediario, tal como un proveedor de satélite o una portadora celular, se supone que puede establecerse una conexión fiable entre ese intermediario y el servidor o servidores 110, y el intermediario aparece como una única conexión tanto al dispositivo como al servidor o servidores 110. En aplicaciones típicas, estas suposiciones se satisfacen mediante conexiones celulares o WiFi que implementan un protocolo basado en IP.
Cuando un servidor central 110 recibe una petición de conexión (por ejemplo, como un paquete) compara información de identificación contenida en la petición con la lista de conexiones activas gestionadas por clientes registrados. Si el paquete de petición está malformado, es inválido o ilegible, el paquete se descarta.
Si el paquete de petición es desde un dispositivo desconocido, se supone que un dispositivo no registrado se ha conectado al servidor 110. El servidor 110 puede emitir y almacenar, a continuación, un testigo de autenticación temporal para este dispositivo no registrado y responder con un paquete de respuesta de autenticación que incluye el testigo de autenticación. Si la conexión es desde un dispositivo conocido, el paquete puede encaminarse internamente a la interfaz coincidente en la representación virtual de la red.
El testigo de autenticación puede ser, por ejemplo, una cadena de caracteres, números o bits de longitud variable. El testigo también puede establecerse para expirar después de un cierto tiempo de espera por propósitos de seguridad.
Un cliente posible recibe el paquete de respuesta de autenticación desde el servidor y extrae el testigo de autenticación del paquete. El cliente actualiza el estado de conexión de la interfaz en la lista de interfaz del dispositivo a "pendiente". El cliente crea, a continuación, un paquete de confirmación de autenticación y registra la interfaz de conexión usando el testigo de registro y espera una segunda confirmación de respuesta desde el servidor central. Tras la confirmación, el dispositivo solicitante identifica este dispositivo inalámbrico como una interfaz de control conectada a servidor que puede enviar y recibir ahora información de control de forma fiable. Si esta es la primera interfaz de ese dispositivo a registrar con el servidor central 110, entonces la interfaz se designa como una interfaz de control primaria.
Cuando un dispositivo de encaminamiento se registra satisfactoriamente en el servidor o servidores 110 a través de un enlace ascendente directo a un servidor, se convierte un cliente del servidor o servidores 110. Aunque es preferible que un dispositivo tenga un enlace ascendente directo a un servidor/instalación central, los dispositivos pueden registrarse en el servidor usando una pseudo pasarela. El software que se ejecuta en el cliente (por ejemplo, la APP 342) a continuación recupera y compila las capacidades de cada interfaz de radio y de red inalámbrica dentro del dispositivo y transmite esta información, u otras métricas tales como identificadores que proporcionan la misma información, al servidor a través de la interfaz de control primaria. El proceso para una cierta interfaz puede facilitarse pasando en su lugar el número de serie de una Tarjeta de Interfaz de Red (NIC) del dispositivo, a partir de la que podrían determinarse todas las capacidades físicas a partir de las especificaciones de un fabricante, o el cliente puede notificar información similar usando cualquier número de codificaciones.
Los clientes pueden notificar al servidor radios inalámbricas y direcciones disponibles, direcciones IP locales, y cualquier pasarela cercada o conectada (si se conoce) junto con esta información de registro para proporcionar un estado de configuración inicial de cada interfaz en la representación virtual del servidor central de cada interfaz.
El estado de configuración de un cliente, inicial o de otra manera, se refiere a la configuración actual de ese cliente al contrario que su configuración potencial.
En este punto, puede requerirse que los clientes proporcionen un ID único y/o una clave de cifrado pública con el servidor o servidores 110 antes de que el servidor registra los mismos completamente. Este ID o clave puede almacenarse, por ejemplo, en la tarjeta SIM del dispositivo, el microteléfono móvil, en memoria de sólo lectura (ROM) o introducirse como un nombre de usuario y contraseña de cuenta por el usuario. Cuando un cliente no notifica su identificador, puede asignarse un identificador al cliente para futuras comunicaciones o el servidor podría rechazar la autenticación del dispositivo. Puede intercambiarse un intercambio adicional de información de control entre el cliente y el servidor según fuera necesario para un experto en la materia.
Fase 2 - Ejecución estándar
Se supone que uno o más clientes se conectan de forma asíncrona al servidor 110 usando el proceso de registro descrito anteriormente y a medida que los clientes se conectan, el servidor 110 realiza el registro para cada cliente potencial de forma separada de cada cliente anteriormente registrado. El servidor 110 puede limitar o priorizar qué clientes pueden conectarse estrangulando selectivamente el proceso de registro basándose en dispositivo, nivel de seguridad, ubicación, o cualquiera de las métricas de dispositivo notificadas. Una vez que los clientes han registrado sus interfaces, se almacenan y mantienen por la representación virtual universal de la red.
Bucle de ejecución de servidor
En el diagrama de flujo en la Figura 5(A) se describe un bucle de ejecución ilustrativo de un servidor 110. Como se ha indicado anteriormente, como parte de su inicio, el servidor o servidores centrales 110 comienzan a alojar una o más interfaces de escucha para recibir datos desde clientes. El servidor central espera de forma constante nuevas peticiones de datos desde dispositivos. Las peticiones de datos desde clientes registrados deberían incluir alguna información que permita que el servidor o servidores 110 determinen que la interfaz de cliente está registrada. Un ejemplo de tal información puede ser la dirección IP de origen o dirección de MAC de origen de los datos. Cuando se reciben datos, el dispositivo de origen notificado en el encabezamiento del paquete de los datos se compara contra la lista de interfaces de clientes registrados en la representación virtual de la red.
Con referencia ahora a los diagramas de flujo ilustrativos en las Figuras 5(B)-5(C), si la interfaz no está registrada en la representación virtual del servidor de la red, el servidor intenta registrar el cliente. El proceso de registro puede tomar cualquier forma y puede requerir la identificación del usuario, identificación del dispositivo y otra información. Si la interfaz está registrada para un cliente particular, los datos se pasan al proceso de manejo de datos de interfaz descrito en la Figura 5(C). En este manejador, la información de cliente registrado se recupera usando la interfaz. El servidor primero carga la información del cliente registrado usando la interfaz y valida la petición de datos. Si la petición de datos no es válida, el servidor carga la interfaz de enlace descendente directo del cliente desde la representación virtual de la red y envía una indicación (por ejemplo, un paquete) de que se recibió un paquete no válido a esa interfaz a través de la conexión directa.
Si el paquete de datos es válido, el servidor determina a partir del tipo del paquete de datos cómo manejar los datos entrantes. En una realización ilustrativa típica, actualizaciones de topología, confirmaciones de trayectoria, actualizaciones de interfaz y actualizaciones de dispositivos usan la información contenida en el paquete para actualizar las bases de datos del servidor, solicitan opcionalmente información desde ubicaciones remotas, y planifican trabajo de cálculo que hay que realizar por el servidor tal como optimización de trayectoria y resolución de ruta de adicional.
Peticiones de datos desde clientes
El servidor 110 identifica el dispositivo 102 para el que se destinan los datos solicitados. El servidor, a continuación, pone en cola la petición e identifica la ubicación de los datos solicitados. Los datos solicitados pueden alojarse, por ejemplo, en un servidor remoto, alojarse localmente dentro del servidor y/o alojarse en un dispositivo de cliente separado en la red. Si los datos solicitados están en un servidor remoto, el servidor 110 recupera los datos solicitados. Una vez que el servidor 110 recibe los datos solicitados, ya sea desde un origen remoto o local, el servidor determina una ruta a través de la que enviar los datos solicitados al dispositivo de destino. Si los datos solicitados se alojan en un cliente en la red, el servidor determina una ruta desde el cliente que aloja los datos solicitados al dispositivo de destino. Los expertos en la materia comprenderán y apreciarán, tras la lectura de esta descripción, que esto permite la creación de subredes seguras y habilita una red de distribución de contenidos (CDN) basada en la nube usando la información almacenada en caché almacenada en dispositivos en la red. Debería apreciarse que el sistema puede almacenar/almacenar en caché proactivamente datos en dispositivos en la red, formando de este modo una CDN activa.
La instalación central también determina una planificación para cada cliente que hay que procesar en la red virtual y realiza trabajo de cálculo para cada cliente cuando sea necesario. Realizaciones ilustrativas típicas de este documento comprueban constantemente si necesitan enviar a un cliente nuevas rutas generadas como resultado de peticiones de datos de dispositivos vecinos y si los clientes tienen respuestas a sus peticiones en cola desde servidores remotos.
Crear vista unificada de red
Una vista unificada de la topología de toda la red se crea como se indica a continuación:
1) Cada dispositivo determina el otro dispositivo o dispositivos desde los que puede recibir paquetes. Los paquetes difundidos tienen información de tanto desde dónde (es decir, qué dispositivo) viene un paquete como para quién se destina, ya sea para retransmitir o consumo. Por lo tanto, independientemente de para quién se destina el paquete, los dispositivos que reciben un paquete pueden registrar qué otros dispositivos pueden escuchar en un momento dado. Como debería apreciarse, un dispositivo particular puede ser capaz de escuchar y recibir paquetes desde otros dispositivos que no son clientes del sistema.
2) Cada dispositivo envía al servidor o servidores centrales una lista de dispositivos que puede escuchar y el momento en que se recibió un paquete desde esos dispositivos. Para dispositivos sin una conexión directa a una pasarela, tendrán que usar protocolos descentralizados u otros protocolos de forma que pueden conectarse a una pseudo pasarela a través de una conexión directa a una pseudo pasarela o a través de una cadena de otros dispositivos que se conectan a una pseudo pasarela.
3) El servidor central compila todos los mapas de topología individuales para crear una vista unificada. El servidor central empareja la indicación de tiempo cuando el paquete se recibió con la ubicación del dispositivo que difunde para informar del mapa de topología histórico.
Optimizar trayectorias activas
El servidor 110 puede optimizar el rendimiento de las trayectorias de transmisión activas de cada cliente. Manteniendo una vista unificada de la topología de red completa, compilada a través de la agregación de la topología individual de clientes, el servidor puede usar algoritmos que optimizan el rendimiento de toda la red. Esto puede incluir optimizaciones que maximizan el flujo y caudal, minimizan costes de transmisión, minimizan la cantidad de batería necesaria para completar transmisiones, reducen congestión y colisiones, reducen interferencia y usan de forma eficiente canales disponibles que pueden usarse por los clientes, como se indica por sus tarjetas de interfaz de red y el número de antenas disponibles, en un área. Estas optimizaciones pueden producirse de forma asíncrona en tiempo real supervisando trayectorias activas y reconfigurando estas trayectorias como nueva información, tal como actualizaciones a la topología local, costes de transmisión, número de dispositivos y cambio de demanda de datos. Las trayectorias también pueden sustituirse de forma asíncrona cuando hay disponibles nuevas soluciones o más óptimas.
El servidor puede aprovechar bases de datos locales o remotas para generar estas optimizaciones. El servidor puede incluir información tal como demanda de datos de red actual, ubicaciones de cliente, e información remota tal como ubicaciones de torres celulares, ubicaciones de zona de acceso WiFi y ubicaciones de otras pasarelas cuando se calcula la mejor ruta o rutas a través de la que enviar datos. Por ejemplo, el servidor puede consultar los servidores de una portadora celular para obtener la información de precios local para transmisiones en un área dada en un momento dado.
Precálculo
Las rutas pueden calcularse por la instalación central 104 en tiempo real a medida que los clientes en la red hacen peticiones de datos. Como alternativa, en un esfuerzo para reducir la latencia, la instalación central 104 puede precalcular rutas basándose en la topología en tiempo real de la red. Si un cliente o clientes en la red solicitan datos, entonces puede elegirse una ruta precalculada determinada adecuada para transmisión de entre el conjunto de rutas precalculadas. El precálculo de rutas puede planificarse/usarse para extender la demanda para procesar rutas para extender la demanda de procesamiento de rutas de tal forma que si existe una avalancha repentina de peticiones de rutas con capacidad de procesamiento limitada, las peticiones que se pueden servir con una ruta o rutas precalculadas adecuadas puede reducir la demanda situada en el servidor. Como se apreciará, mientras el sistema puede evitar realmente que se produzca una avalancha repentina de peticiones de ruta en el servidor, el sistema puede prepararse para tales casos teniendo una o más rutas precalculadas fácilmente disponibles para peticiones entrantes. De esta manera el sistema puede evitar petición que experimenta un exceso de latencia mientras se forma una cola de peticiones de encaminamiento. El precálculo también puede ser bueno para reducir la latencia. En casos en los que existe una potencia de cálculo excesiva, puede proporcionarse más rápido una ruta suficiente sin recurrir a ninguna latencia asociada con el procesamiento. En casos en los que existe una cola de peticiones de encaminamiento, que tienen rutas precalculadas y un mapa de transmisión histórico pueden reducir el tamaño de la cola. Las rutas precalculadas también pueden expirar en un entorno dinámico o, en un esfuerzo para reducir costes operativos, pueden necesitarse únicamente que se hagan cuando el servidor detecta una latencia inaceptable para uno o más clientes.
Los datos pueden ponerse en cola en el servidor o servidores para enviarse a clientes. Los datos en cola se envían preferentemente en tiempo real, pero pueden retardarse como resultado de límites de servidor. Los datos en cola se envían preferentemente a cada cliente a través de una ruta resuelta. Las rutas resueltas pueden utilizar un enlace descendente directo (por ejemplo, enviar el paquete a través de una conexión celular o WiFi directa), un enlace descendente indirecto (por ejemplo, enviar el paquete a través de la parte par a par de la red), o ambos simultáneamente.
Bucle de ejecución de cliente
Los dispositivos que han completado un registro en el servidor o servidores centrales 110 se convierten en clientes del servidor central o servidores centrales. El software de cliente ejecuta operaciones de acuerdo con el procedimiento mostrado en la Figura 5(D).
Solicitar datos
Un cliente registrado solicita datos a través de una interfaz de enlace ascendente directo que se registró en el servidor central 110. Las peticiones de datos pueden originarse en el software de cliente, el sistema operativo del dispositivo o la interfaz de usuario del dispositivo. Un ejemplo típico sería un teléfono móvil que abre un explorador web y que intenta cargar una página web.
Un dispositivo (o cliente) sin un enlace ascendente directo al servidor o servidores 110 pueden denominarse en el presente documento como un dispositivo o cliente descentralizado. Estos dispositivos sin un enlace ascendente directo se consideran descentralizados porque sus transmisiones no pueden coordinarse directamente por la instalación central 104. Un conjunto de dispositivos o clientes descentralizados puede formar una subred descentralizada.
Las peticiones desde dispositivos/clientes descentralizados en subred descentralizada pueden encaminarse usando la subred descentralizada a una pseudo pasarela que tiene una conexión de enlace ascendente directo al servidor o servidores 110, por ejemplo, usando protocolos de transmisión descentralizados tales como BATMAN, OLSR y similares. La pseudo pasarela puede reenviar, a continuación, estas peticiones al servidor o servidores 110.
Cuando se produce una petición de este tipo, el software de cliente intercepta la petición de datos salientes desde el núcleo del dispositivo o la aplicación de espacio de usuario y encamina la petición de datos a través del software de cliente. El software de cliente identifica la interfaz directa primaria u óptima y encamina la petición de datos al servidor central a través de la interfaz directa usando cualquier instrucción de encaminamiento proporcionada por el servidor para solicitar datos en esa interfaz.
Petición de búsqueda (en el servidor desde a entidad remota)
En realizaciones actualmente preferidas, las peticiones de datos se encaminan a través de un enlace ascendente directo a la internet. Las peticiones se retransmiten a la instalación central 104, preferentemente a través de la internet. El servidor 110 puede proporcionar una ruta de enlace ascendente por defecto a cada cliente en la red para coordinar este enlace ascendente, o clientes pueden usar la interfaz directa registrada primaria como un enlace ascendente directo para encaminar sus peticiones de datos.
En algunos casos la instalación central puede determinar que, en lugar de hacer que el cliente solicitante cargue los datos a través de una conexión de enlace ascendente directo, que sería más óptimo cargar los datos o petición de datos a través de una trayectoria indirecta. Ejemplos de tales casos incluyen dónde está intentando un cliente cargar un archivo grande, o dónde existe una cogestión significativa en el canal de enlace ascendente, o por otras razones. En tales casos, la instalación central puede determinar una trayectoria de enlace ascendente indirecto que el cliente de carga podría usar para encaminar los datos. En realizaciones preferidas de este documento, estas instrucciones de encaminamiento pueden enviarse al cliente de carga a través de un enlace descendente directo, aunque, como alternativa, estas instrucciones de encaminamiento podrían comunicarse a través de una trayectoria indirecta.
Independientemente de si es más o menos eficiente que cargar datos a través de un enlace ascendente directo, un cliente de carga puede solicitar que el servidor envíe una ruta (por ejemplo, trayectoria, canal, temporización, alcance, etc.) de tal forma que puede cargar los datos a través de una conexión indirecta. Puede hacerse una petición de este tipo si el cliente desea crear una transmisión de subred segura de tal forma que los datos cargados no necesitan recibirse por y procesarse a través del servidor o servidores centrales 110.
La Figura 5(E) muestra un flujo de trabajo típico en el servidor 110 cuando los clientes en la red solicitan datos (por ejemplo, un recurso). El recurso puede ser o comprender o representar cualquier clase de datos, y el sistema no está limitado por la clase de recurso o datos o lo que el recurso o datos pueden representar. Ejemplos de recursos incluyen, sin limitación, páginas web, imágenes, vídeos, texto, audio y similares. Los recursos pueden ser estáticos o dinámicos (por ejemplo, generados sobre la marcha para cada petición particular). Los recursos pueden incluir recursos de difusión en continuo (por ejemplo, difundir en continuo contenido de audio y/o vídeo). El servidor determina si el destino objetivo o recurso es local, remoto u otro cliente registrado. Si la petición es remota, el recurso se busca usando la internet u otra conexión disponible para el recurso remoto. Si el recurso es local, el servidor busca el recurso localmente. Si el receptor previsto es también un cliente, el servidor puede establecer rutas de carga y realizar una petición para recuperar los datos solicitados desde el cliente objetivo.
En algunos casos, por ejemplo cuando múltiples clientes solicitan el mismo recurso, el servidor puede almacenar en caché esa información localmente para intentar evitar una serie de descargas remotas de la información. Por ejemplo, si un recurso se vuelve muy popular, el sistema puede sacar muchas copias a dispositivos que tienen una conexión directa a una pasarela, tal como una zona de acceso WiFi. A continuación, si otro dispositivo que no está cerca del dispositivo que ha almacenado en caché esa información solicita ese recurso, el servidor central puede informar a ese dispositivo de caché que envíe el mismo al dispositivo solicitante. El servidor también puede establecer una conexión con un proveedor de contenido (por ejemplo, la fuente de contenido 114) para servir de forma eficiente a un número de clientes. Un sistema de este tipo podría ser el de un proveedor de contenido de vídeo desde el que múltiples clientes difunden en continuo datos simultáneamente.
Proporcionar a un servidor remoto información de ruta/trayectoria/dispositivo para ajustar los datos
En algunos casos, cada uno de múltiples dispositivos de petición 102 puede solicitar un recurso de difusión en continuo tal como un vídeo desde un proveedor/servidor de contenido remoto (por ejemplo, una fuente de contenido 114 tal como Netflix o similar). El servidor central 110 puede proporcionar al proveedor de contenido remoto información acerca de la red. Esta información podría incluir las ubicaciones de los clientes, sus capacidades, o información de sincronización. El servidor 110 también puede proporcionar los resultados de cálculos de encaminamiento tales como la probabilidad de una ruta satisfactoria, y cómo se está transmitiendo la información. El servidor remoto puede usar esta información para determinar qué contenido se proporciona al servidor de encaminamiento. Cuando se difunde en continuo vídeo, por ejemplo, el servidor de encaminamiento puede comunicar la congestión en la red, y el proveedor de contenido remoto puede proporcionar un flujo de vídeo de tasa de bits más baja a medio camino a través de la transferencia. Cambiar la tasa de bits (o proporcionar un vídeo de tasa de bits más baja) durante una transferencia se demuestra útil cuando el servidor detecta un entorno de tasa de errores alta, el cliente está a punto de hacer un traspaso, o la latencia de una conexión es mala, conmutar a un flujo de tasa de bits más baja permite mantener el vídeo de difusión en continuo sin forzar una desconexión o pérdida de fotogramas del vídeo.
Subredes virtuales
Puede haber situaciones en las que los clientes desean cambiar datos directamente entre sí. Un primer cliente puede solicitar un recurso almacenado en el segundo cliente, un primer cliente puede querer abrir un túnel de comunicaciones con otro cliente, o los clientes pueden desear cambiar datos de forma segura y/o anónima entre sí. Un cliente también puede solicitar un recurso del servidor sin tener conocimiento de dónde está ubicado el recurso. En cualquiera de estos escenarios, el servidor puede usarse para facilitar el proceso de creación de una subred virtual entre uno o más clientes, ubicar el recurso solicitado, y proporcionar un recurso solicitado desde otro dispositivo en la red al cliente solicitante. Un beneficio para utilizar el servidor para crear las subredes virtuales permite que los dispositivos excluidos de la subred virtual encaminen datos de forma segura para otros dispositivos en la red segura. Planificar las transmisiones par a par con el servidor también mitiga problemas de interferencia que podrían surgir cuando coexisten transmisiones par a par con transmisiones de red de pasarela a dispositivo o de pasarela a múltiples saltos. Finalmente, el mapa de topología del servidor proporciona una forma segura y anónima para que los dispositivos descubran otros dispositivos y sus recursos. En este punto el servidor funciona como un facilitador de conexiones para dispositivos, que maneja opcionalmente la seguridad, encaminamiento de trayectoria y resolución de errores.
Se produce una aplicación para este procedimiento cuando un primer cliente solicita un recurso (tal como una imagen, vídeo, archivo, etc.) y la instalación central 104 puede consultar un segundo cliente para acceder al recurso solicitado. El servidor central puede generar, a continuación, una trayectoria desde el recurso al cliente solicitante usando el mapa de topología actual. En algunas situaciones, la trayectoria puede encaminar datos a través de una o más pasarelas, a través de uno o más clientes y, opcionalmente, a través del servidor. Si se prefiere por los dispositivos, sus usuarios, o el mapa de topología, el servidor genera una trayectoria que evita que los datos viajen a través de la internet o a través del servidor. Hacer eso puede aumentar la privacidad de la transmisión y reducir la latencia del viaje de ida y vuelta. Adicionalmente, si el recurso solicitado es grande, evitar un enlace ascendente directo congestionado encaminando la información a través de una red par a par puede mejorar el rendimiento de la red local.
Una segunda aplicación para este procedimiento implica contenido en tiempo real generado por el usuario en un entorno móvil. Los clientes pueden generar flujos de vídeo en vivo, tomar fotografías, tomar parte en una llamada de voz o tomar parte en una actividad común tal como un videojuego. En tales situaciones, el servidor puede unir estos dispositivos en una subred virtual de tal forma que los datos pueden difundirse en continuo entre clientes en la subred virtual, eludiendo el servidor o servidores. No existe ningún requisito de que el primer cliente y el segundo cliente estén físicamente cerca entre sí. El único requisito para establecer una comunicación entre dos o más clientes en la red es que una ruta puede crearse de tal forma que pueda transmitirse el recurso solicitado.
Para generar y mantener estas subredes virtuales, el servidor utiliza el mapa de topología y sus trayectorias activas de comunicación a clientes. Cuando los clientes solicitan unirse, crear o dejar las subredes virtuales, el servidor mantiene el estado de cada subred virtual y los clientes pertenecientes a cada red en una o más bases de datos. Las rutas entre dispositivos de cliente se mantienen como trayectorias de transmisión y se planifican a lo largo de otras trayectorias activas en la red. Los clientes utilizan trayectorias de transmisión proporcionadas por el servidor cuando transmiten datos a otros clientes en la subred virtual. Los clientes excluidos de la subred virtual pueden incluirse en la ruta de transmisión que se conecta a la subred virtual. Cuando la ruta de transmisión incluye dispositivos que no son miembros de la subred virtual, los datos enviados en la subred virtual pueden cifrarse de tal forma que únicamente los miembros de la subred virtual pueden descifrar los datos.
Cuando se solicita o requiere la seguridad de transmisiones, el servidor puede facilitar el intercambio de claves de cifrado entre clientes para asegurar la comunicación. Como alternativa, el servidor puede funcionar como una VPN para ambos clientes, y encaminar datos entre clientes como si fueran parte de una VPM compartida.
Cuando se solicita o requiere el anonimato de transmisiones, el servidor puede proporcionar únicamente trayectorias locales de tal forma que los datos nunca viajan a través de la internet. Como se usa en este punto, "anonimato" se refiere a algún grado de anonimato de los clientes y/o los datos que envían o reciben. Como alternativa, por ejemplo, cuando los dispositivos no están físicamente ubicados cerca entre sí, el servidor puede proporcionar trayectorias de forma anónima a través de la internet de tal forma que los datos nunca pasan a través del servidor.
Cada vez que un cliente solicita unirse, dejar, crear o modificar los parámetros de una subred virtual, el servidor puede elegir permitir o no permitir la modificación a la red. El servidor también puede mediar un intercambio de información entre el dispositivo de cliente y la subred virtual. Un ejemplo típico de esto sería solicitar al usuario de un dispositivo que escriba una contraseña antes de unirse a la subred virtual. Como otro ejemplo, que no requiere la intervención de usuario, el servidor puede pedir a un cliente que firme criptográficamente un mensaje. Esta contraseña y metadatos adicionales de la petición puede proporcionarse al servidor en el que puede autenticar al usuario. El servidor puede notificar opcionalmente mensajes de errores o confirmación a dispositivos para indicar el éxito o fallo de ciertas operaciones.
En la formación y unión de subredes virtuales, el servidor puede proporcionar a dispositivos información desde el mapa de topología universal para ayudar en el proceso. Esto puede ayudar con el descubrimiento de dispositivos cercanos. En este punto cuando los dispositivos están fuera del alcance de transmisión del dispositivo de búsqueda, y existe una trayectoria a través de otros clientes de vuelta a ese dispositivo, el servidor puede notificar al dispositivo de búsqueda la existencia de otro dispositivo que es alcanzable a través de otro dispositivo.
Cola de datos salientes
Los datos recibidos desde un recurso remoto pueden estar incompletos, pueden ser parte de un flujo de datos mayor o pueden necesitar buscarse en su totalidad. Para al menos estas razones, el servidor 110 mantiene una cola de salida a tales clientes. Cuando se destinan nuevos datos para un cliente los datos se insertan en la cola de datos. Cuando se resuelve una nueva trayectoria, se elimina una cierta cantidad de datos, como se determinan por el tamaño de paquete en la trayectoria, de la memoria intermedia, el paquete de datos se planifica para enviarse al cliente, y el siguiente artículo en la cola se mueve a la parte frontal de la posición de cola.
Mediante la extensión de las capacidades de la memoria intermedia de cliente analizadas anteriormente, cuando se reciben nuevos datos desde un recurso remoto, se resuelve una nueva trayectoria, o cuando se reenvían datos después de una transferencia incompleta, es posible modificar los datos con información de encaminamiento o parámetros de transmisión actualizados e insertar la información de vuelta en la memoria intermedia. Esto permite que el servidor central priorice de nuevo los datos almacenados en memoria intermedia. Por ejemplo, cuando una nueva pasarela se vuelve disponible y se resuelve una nueva trayectoria usando esa pasarela, puede aumentarse el tamaño de paquete de cada transmisión. El servidor puede reorganizar la memoria intermedia del cliente para acomodar este nuevo tamaño de paquete. De manera similar, el servidor puede determinar que, mientras transmite, la calidad de la conexión entre dos dispositivos ha aumentado o que dos dispositivos que anteriormente podrían no comunicarse son capaces ahora de comunicarse. Este cambio en topología de red puede provocar que el servidor modifique la ruta de transmisión para optimizar el flujo de red.
Resolución de trayectoria
La instalación central 104 usa preferentemente su mapa de interfaz virtual para determinar la intensidad de señal unidireccional y/o calidad de enlace entre dos cualesquiera interfaces (por ejemplo, WiFi, célula, etc.) en la red. El servidor central 100 determina habitualmente la calidad de comunicación entre dos cualesquiera interfaces midiendo o de otra manera determinando la intensidad de señal, calidad de enlace, número de conexiones a otros dispositivos, canales disponibles, alcance de emisión, uso de espectro, coste monetario de transmisiones, batería estimada gastada para completar la transmisión y otras métricas. Agregando la calidad de conexiones y creando un gráfico conectado que incluye únicamente conexiones que se determinan que están por encima de un umbral, el servidor central puede ejecutar algoritmos de encaminamiento, para optimizar transmisiones a través de la red virtual que pueden usarse para informar decisiones de encaminamiento. Debido a que el servidor central tiene un registro de toda la comunicación anterior a través de la red así como comunicación que se pone en cola o que está sucediendo actualmente, el servidor puede determinar las trayectorias de enlace descendente y enlace ascendente óptimas disponibles para cualquier transmisión. El servidor central calcula y mantiene un registro de enlaces ocupados en momentos específicos y a través de qué canales.
Las trayectorias de múltiples saltos se calculan y distribuyen usando la representación virtual del servidor central de la red. En algunos casos la trayectoria completa nunca se transmite dentro de la red en malla y existe únicamente en la representación virtual del servidor de la red. Este sería el caso en el que las instrucciones de encaminamiento se retransmiten a cada dispositivo en la trayectoria de transmisión a través de una conexión directa (probablemente celular). En casos en los que los dispositivos reciben instrucciones de encaminamiento a través de una trayectoria indirecta, los dispositivos conocerán generalmente toda la trayectoria de encaminamiento.
Se usan algoritmos selectivamente para gestionar y buscar la representación virtual de la red. Algoritmos de búsqueda ilustrativos que pueden usarse para tomar decisiones de encaminamiento incluyen, pero sin limitación: algoritmo voraz que varía con el tiempo, consumo de batería mínimo que varía con el tiempo, saltos mínimos que varían con el tiempo, uso de espectro mínimo que varía con el tiempo, flujo máximo que varía con el tiempo, trayectoria rápida que varía con el tiempo, coste de transmisión mínimo que varía con el tiempo y fiabilidad máxima que varía con el tiempo. En algunas realizaciones, los algoritmos de encaminamiento pueden configurarse para favorecer dispositivos que están enchufados en un enchufe eléctrico, tienen niveles altos de potencia de batería restante, etc.
En algunas realizaciones, la instalación central puede realizar seguimiento de cuántos datos se han pasado a través de cada cliente en relación con cuántos datos ha solicitado y recibido cada cliente. La instalación central puede encaminar datos para favorecer datos de encaminamiento a través de dispositivos que han solicitado más datos de los que han pasado para otros dispositivos. A los dispositivos que han pasado más datos en nombre de otros dispositivos de los que han recibido pueden proporcionarse un estado de transmisión prioritario, transmisiones gratis 0 un crédito en el sistema que puede canjearse.
En algunas realizaciones el sistema puede recompensar a los usuarios por pasar datos para otros. Estas recompensas pueden ser en términos de dinero o créditos para recibir datos adicionales. Esto alentaría que los emprendedores construyan una red de transmisión inalámbrica a través de la que el sistema puede encaminar datos.
Pueden usarse múltiples algoritmos de encaminamiento como algoritmos que pueden optimizarse para ciertas situaciones. Por ejemplo, algoritmos usados para encaminar datos entre clientes en áreas densamente ocupadas, tales como estadios deportivos y similares, pueden ser sustancialmente diferentes que algoritmos usados para encaminar información en áreas escasamente ocupadas. En el primer caso, los algoritmos especializados pueden enfatizar un caudal de red total mientras, en el último caso, los algoritmos especializados pueden enfatizar una conectividad universal.
El servidor central 110 puede determinar si es más rápido enviar datos a través de conexiones de enlace ascendente y/o enlace descendente directos o indirectamente a través de la red par a par de clientes. Ambos sistemas pueden trabajar en conjunción cuando se crea una ruta para entregar un único recurso. Realizaciones preferidas de este documento pretenden ser aditivas a las redes inalámbricas existentes. El operador de la instalación central puede elegir enviar únicamente información a través de un método indirecto (es decir, a través de la parte de par a par de la red) cuando es más rápido, más seguro, más eficiente o de otra manera mejor que otros métodos.
Múltiples pasarelas
Como se muestra en la Figura 6(A), el servidor central puede decidir usar múltiples pasarelas, que pueden ser del mismo o diferente tipo (por ejemplo, una pasarela celular y una pasarela WiFi o dos pasarelas WiFi) para enviar el recurso solicitado o cuando se calcula una ruta que debería usar un cliente para cargar un recurso. Si el servidor elige usar múltiples pasarelas, entonces el servidor dividirá apropiadamente el recurso y enviará la parte o partes designadas a cada una de las pasarelas y separará las instrucciones de encaminamiento a cada dispositivo implicado en cada trayectoria.
Transmisiones de única pasarela y múltiples nodos
En algunos casos una pasarela puede tener dos o más dispositivos directamente conectados a la misma. La pasarela puede enviar un recurso dividido a dispositivos conectados como se determina por el servidor en el que las partes del recurso se retransmiten al cliente de destino. Por ejemplo, como se muestra en la Figura 6(B), la pasarela se conecta a los clientes 1 y 2. Supóngase que un recurso se destina para uno de los clientes 3, 6 o 7. La pasarela (basándose en instrucciones de servidor) puede enviar partes del recurso a través del cliente 1 (a través de la trayectoria "1, 3, etc."), y partes del recurso a través del cliente 2 (a través de la trayectoria "2, 4, 5, 3, etc."). Este enfoque es útil cuando la pasarela tiene mayores capacidades de caudal que cualquier único nodo conectado, que puede deberse a muchos problemas diferentes que incluyen, pero sin limitación a, intensidad de conexión, número de antenas, etc. Como debería apreciarse, la pasarela puede usar diferentes protocolos para sus conexiones e interacciones con los clientes 1 y 2.
Múltiples pasarelas, múltiples nodos
En el caso general, una transmisión desde el servidor o servidores a un cliente puede usar múltiples pasarelas y múltiples nodos. Es decir, una transmisión puede usar cualquier combinación de las transmisiones de múltiples pasarelas/múltiples nodos. Un ejemplo de esto se muestra en la Figura 6(E), en el que una trayectoria al cliente 7 puede usar simultáneamente las pasarelas G1 y G2 (múltiples pasarelas), en donde la pasarela G1 puede usar simultáneamente las trayectorias "1, 3, 6, 7" y "2, 4, 5, 3, 6, 7".
Historial de transmisiones - optimización de flujos de datos para métricas dadas
El servidor puede supervisar de forma continua métricas relacionadas con cada cliente individual en tiempo real y registrar el historial de transmisiones asociado con cada cliente en la red. Tales métricas pueden incluir, pero sin limitación, la ubicación de un cliente, los otros clientes desde los que un cliente puede recibir datos, las interfaces de red disponibles en el cliente, el número de antenas disponibles, los canales en los que un cliente puede enviar o recibir datos y la batería restante tanto en kilojulios restantes como el tiempo operativo estimado restante. El historial de transmisiones registrado puede incluir, pero sin limitación, la cantidad de batería consumida pasando datos para otros clientes, y la cantidad de batería que otros clientes han consumido pasando datos para un cliente individual, transmisiones recibidas satisfactoriamente anteriores y transmisiones enviadas satisfactoriamente anteriores. El servidor puede usar estas métricas e historial de transmisiones para determinar rutas de transmisión eficientes y fiables entre clientes en la red.
Adicionalmente, el servidor 110 puede compilar un historial de transferencia satisfactorias o no satisfactorias entre dispositivos. Un historial de este tipo puede proporcionar información adicional útil cuando se calculan y precalculan rutas.
Para determinar cómo deberían enviarse los datos al cliente, el servidor calcula rutas a partir del origen de los datos, habitualmente el servidor central, al destino y estima la velocidad, fiabilidad, demandas de recursos y otros factores que consumirían diferentes rutas. El servidor pondera todos estos factores y determina la mejor ruta o rutas a través de las que el recurso debería enviarse.
Mientras el historial de transmisiones es importante para cada dispositivo en la red, otra vista de historial de transmisiones no es por cada dispositivo, sino por cada punto atravesado en la red.
El servidor central puede considerar el mapa de topología como un conjunto de puntos. Cuando se ubican dispositivos en un punto, el servidor central registra las métricas de las transmisiones en ese punto a través de muchos dispositivos. Por consiguiente, después de que el servidor central ha creado un mapa de topología histórico adecuado, puede tener un buen entendimiento de la topología de la red simplemente conociendo las ubicaciones de dispositivos en la red. Cuando el servidor central toma decisiones de encaminamiento usando el mapa de topología histórico y una ubicación de dispositivo o dispositivos, esto significa que existe menos tráfico en la red ya que los dispositivos no necesitarían buscar direcciones de internet de dispositivo cercanos tan a menudo y la duración de la batería de los dispositivos se incrementa ya que sus radios pueden estar apagadas durante periodos de tiempo más largos. Esta clase de mapa de topología histórico es muy útil cuando se precalculan rutas.
Ejemplo:
La Figura 6(B) muestra una red de múltiples saltos de ejemplo coordinada por el servidor a través de una pasarela. Se supone que cada cliente tiene una conexión de enlace ascendente y enlace descendente directos de vuelta al servidor que no se muestra en el diagrama. En este ejemplo, la red física consiste en 7 clientes numerados 1 a 7 en una cierta área física. La información de topología notificada al servidor permite que el servidor compile un mapa de la red que combina las ubicaciones físicas de los clientes y qué clientes son capaces de recibir transmisiones desde otros clientes.
Un enfoque ilustrativo por el servidor es como se indica a continuación:
1. El servidor crea una representación virtual de esta red.
2. El servidor identifica todas las pasarelas dentro de una cierta distancia del cliente solicitante, expandiendo el radio de búsqueda de pasarela hasta que exista al menos una pasarela.
3. Para cada pasarela encontrada dentro del radio de búsqueda de pasarela, el servidor usa múltiples algoritmos de encaminamiento, incluyendo, pero sin limitación, el algoritmo voraz, flujo máximo que varía con el tiempo, duración mínima de la batería consumida que varía con el tiempo, trayectoria rápida que varía con el tiempo, coste de transmisión mínimo que varía con el tiempo, espectro mínimo que varía con el tiempo usado, menos saltos que varían con el tiempo, fiabilidad máxima que varía con el tiempo, etc., para determinar una ruta o rutas desde la pasarela al cliente de destino.
4. El servidor asigna canal e instrucciones de temporización a cada transmisión.
5. Usando estas asignaciones de canal e instrucciones de temporización, el servidor estima la velocidad que completará cualquier descarga.
6. Tan pronto como una ruta tenga una velocidad estimada por encima de un cierto umbral, normalmente la velocidad que podría conseguirse usando un enlace descendente directo, el servidor elige esa ruta y envía la información de la ruta seleccionada.
7. Si no puede encontrarse ninguna ruta que usa esa pasarela o no puede encontrarse ninguna ruta que usa esa pasarela que es más rápida que el umbral y/o excede otras métricas predeterminadas tales como coste de transmisión, fiabilidad o seguridad, el alcance de búsqueda de pasarela se expande. Si el servidor no puede encontrar una ruta que se completa más rápido que un enlace descendente directo dentro de un cierto tiempo, el servidor puede elegir enviar los datos a través del enlace descendente directo. En algunas realizaciones, los dispositivos pueden ordenar al servidor central de condiciones de no compromiso que debe tener una ruta seleccionada. Por ejemplo, un dispositivo puede querer únicamente recibir datos si la transmisión está libre y puede esperar de otra manera indefinidamente hasta que pueda cumplirse una condición de este tipo. En un caso de este tipo, el servidor central puede detener el procesamiento de la petición después de una cierta cantidad de tiempo buscando. En un caso de este tipo, el dispositivo puede continuar haciendo peticiones al servidor central, pero el servidor central puede reconsiderar únicamente una petición de este tipo después de una cierta cantidad de tiempo pasada la petición inicial. Un experto en la materia apreciará que pueden aplicarse condiciones de no compromiso cuando un cliente está haciendo una carga o petición de datos. Por ejemplo, un cliente con una interfaz tanto celular como WiFi puede elegir no hacer una conexión directa con el servidor central a través de la conexión celular si la conexión celular es cara. El cliente puede esperar hasta que pueda establecer una conexión descentralizada a una pseudo pasarela, que puede ser menos cara. Sin embargo, el cliente puede elegir crear una conexión directa usando la interfaz celular si no se ha conectado al servidor o internet después de un cierto periodo de tiempo (por ejemplo, 24 horas) o si debe enviarse una petición más urgente.
Para una petición dada, por ejemplo, en referencia con la red en la Figura 6(B), una lista de rutas potenciales que el servidor podría calcular podría ser la de la Tabla 1 (Figura 6(C)).
Fin del Ejemplo
Usando este método de encaminamiento generalizado, el servidor puede usar un número de métricas, algoritmos de encaminamiento y umbrales para encaminar cada paquete de datos apropiadamente. Adicionalmente, una vez que se elige una trayectoria, el servidor puede continuar calculando otras rutas que tienen en consideración los recursos usados en rutas determinadas anteriormente para crear rutas complementarias para reducir el tiempo de transmisión total.
En la presente invención, existen dos categorías de tipos de ruta, directa e indirecta. Las rutas directas son las que se completan habiendo solicitado que se envíen datos a través de un enlace descendente directo desde una pasarela al dispositivo de destino. Las rutas indirectas son las que se completan encaminando datos solicitados a pasarelas que envían los datos solicitados a dispositivos retransmisores que usan conexiones con otros dispositivos para retransmitir la información al dispositivo de destino.
Virtualización de trayectoria de múltiples "pasarelas"
Los tipos de trayectorias sintéticas también son soluciones posibles cuando se generan trayectorias desde la representación virtual de la red y requieren una atención especial. Las trayectorias sintéticas usan combinaciones de trayectorias para producir una nueva trayectoria. Las trayectorias pueden incorporar múltiples pasarelas simultáneamente para aumentar la robustez de la transmisión. Una segunda trayectoria sintética podría implicar múltiples clientes que retransmiten datos a un único cliente para aumentar la robustez de las transmisiones. Finalmente, combinaciones lineales de los tipos de trayectoria descritos listados también pueden representar trayectorias sintéticas. Esto podría incluir una trayectoria de múltiples pasarelas y una conexión directa simultáneamente.
Enviar a múltiples vecinos directamente, a continuación enviar a destino
En algunas realizaciones ilustrativas de este documento, el servidor puede determinar que es "mejor" dividir un recurso o flujo dado destinado para un único cliente, tal como un archivo o flujo, y enviar a todos los clientes vecinos alrededor del cliente usando uno o más enlaces descendentes directos, cuando sea posible (como se muestra en la Figura 6(D)). Esto puede ser porque un dispositivo individual tiene una conexión directa mala o inexistente al servidor central, o puede elegirse para disminuir la latencia de una descarga particular. Después de que los dispositivos vecinos han recibido el recurso o fracciones del mismo, cada dispositivo puede enviar los datos al cliente (1) en el momento apropiado usando una norma de transmisión diferente que usa para recibir los datos a través del enlace descendente directo. El servidor puede elegir este esquema de encaminamiento ya que puede reducir el tiempo de transmisión total y aumentar el caudal de red total.
Por ejemplo, si el cliente solicitante, el cliente (1), y sus vecinos tienen múltiples interfaces de red con diferentes alcances, los datos pueden transmitirse más rápidamente si todas las interfaces se emplean simultáneamente. Por ejemplo, si el cliente (1) tiene tanto una radio de célula como una radio WiFi, parte del recurso solicitado puede enviarse directamente al cliente (1) a través del enlace descendente directo y la otra parte del recurso solicitado podría enviarse a los vecinos del cliente (1) a través del enlace descendente directo. Los vecinos del cliente (1) podrían enviar, a continuación, el recurso solicitado al cliente (1) a través de la norma WiFi de alcance más corto mientras el cliente (1) simultáneamente recibe información desde un enlace descendente directo. Esto emplearía ambas interfaces de red y reduciría el tiempo de transmisión total.
Este escenario podría suceder también si el sistema determina que existe una capacidad de exceso momentánea en el sistema. Reduciendo el tiempo de transmisión total, no solo la descarga se completa más rápidamente desde el punto de vista del cliente de destino, sino que la red también se beneficia ya que aumenta el caudal de red total. Las transmisiones no continúan usando recursos de red que pueden usarse repentinamente mejor en otra transmisión.
Combinaciones lineales, rutas que cambian con el tiempo y traspasos de interfaz de protocolo/red (por ejemplo, comenzar en celular y pasar a WiFi)
Si una única pasarela tiene la capacidad de hacer múltiples transmisiones simultáneas sin experimentar una degradación de transmisión significativa, el servidor puede determinar que es más rápido o de otra manera más eficiente enviar parte del recurso solicitado al primer cliente a través de una conexión de enlace descendente directo y hace que los datos restantes se envíen simultáneamente al cliente solicitante usando conexiones de par a par.
Usando el método anterior, el servidor central 110 puede garantizar sustancialmente una cierta calidad de servicio a todos los clientes. En una realización típica, el servidor enviará primero un flujo de paquetes de datos a través de un enlace descendente directo al cliente tal como una conexión celular. Esto asegura una latencia dominante débil con cualquier sistema existente, con la condición de que todas las interfaces de red se registren en el servidor porque el servidor elegirá primero la trayectoria con menor latencia que es una conexión directa. Con el paso del tiempo, las trayectorias se optimizan de forma continua, y otras trayectorias que son más baratas, más rápidas y tienen una latencia aceptable pueden usarse de forma más intensa a lo largo de todo el curso de una descarga. El caso de uso primario para esto es cuando un vídeo podría iniciar la descarga a través de LTE de baja latencia para proporcionar una buena experiencia de usuario, y el resto del vídeo alcanzará el dispositivo solicitante a través de red o redes de múltiples saltos con origen de pasarela WiFi menos caras pero con mayor latencia. Como se usa en el presente documento, el término "traspaso" se refiere a un proceso de mantener una conexión mientras se conmutan interfaces (por ejemplo, WiFi a celular o viceversa).
El servidor también tiene la opción de enviar datos desde ambas pasarelas a través de múltiples trayectorias. Por ejemplo, en la Figura 6(E), el cliente 7 puede recibir simultáneamente paquetes desde el mismo flujo desde la pasarela G1 a través de la trayectoria [1,3,6,7] y desde la pasarela G2 a través de la trayectoria [8,7].
Cuando el servidor determina los clientes incluidos en una trayectoria, el tiempo de transmisión a través de cada enlace, los canales usados, y la interfaz o interfaces que cada cliente debería usar para enviar y recibir datos, el servidor envía información de encaminamiento crítica acerca del envío y recepción de transmisiones a cada cliente en la trayectoria a través de un enlace descendente directo. Estas instrucciones pueden incluir, pero sin limitación, la ventana de tiempo en la que deberían esperar recibir datos, el canal en el que recibirán datos, el canal en el que deberían enviar datos, la ventana de tiempo dentro de la que deberían enviar datos, la tarjeta de interfaz de red que deberían usar para la transferencia, la cantidad de potencia que deberían usar para difundir los datos (cuando sea aplicable), un identificador actualizado para el paquete, la información que identifica el siguiente cliente en la trayectoria de transmisión, el protocolo usado para enviar los datos, el hardware o antenas para transmitir los datos a través, claves de cifrado y otras métricas de transmisión importantes.
Se informa a cada cliente elegido por el servidor para estar en la trayectoria de transmisión que son parte de una ruta de transmisión por el servidor a través de un enlace descendente directo y se proporcionan instrucciones de transmisión sobre cómo encaminar datos en la red. Como alternativa, los dispositivos podrían recibir instrucciones desde el servidor indirectamente a través de una conexión en malla. En este escenario, los dispositivos pueden conocer toda la ruta de transmisión.
Enviar datos a clientes
Envío almacenado en memoria intermedia
Los clientes pueden hacer múltiples peticiones al servidor antes de que el servidor pueda satisfacer estas peticiones. Esto puede producirse, por ejemplo, cuando un servidor remoto se retrasa y no proporciona la información solicitada antes de que el cliente solicite más información. Una memoria intermedia de datos que el servidor mantiene para cada cliente registrado puede resolver este problema. Cuando la información debe encaminarse de vuelta a un cliente, el servidor añadirá de forma similar la información a una memoria intermedia de salida para el cliente. El servidor también puede almacenar la ubicación y longitud de los datos que hay que transmitir, si el servidor necesitara recalcular la trayectoria antes de que la información se envíe desde el servidor.
Por ejemplo, como se muestra en la Figura 6(F), el servidor puede mantener una cola de salida al cliente (1). Cuando se destinan nuevos datos para el cliente (1), los datos se insertan en la cola de datos. Cuando se resuelve una nueva trayectoria, los datos se eliminan de la memoria intermedia, los datos se envían al cliente, y el siguiente artículo en la cola se mueve a la posición superior.
Antes de que los datos almacenados en memoria intermedia se envíen al cliente, el servidor puede modificar información, en la cola, eliminar información, o reordenar la información según sea necesario. Por ejemplo, reordenar la prioridad de información saliente puede producirse cuando la red notifica un error. En este caso, los datos faltantes se priorizarían a través de otro tráfico en cola en la red. La modificación de los datos puede producirse cuando el encabezamiento de los datos salientes contiene una planificación de transmisiones que deben actualizarse como resultado de nueva información de topología.
Cifrar datos salientes
Una realización ilustrativa facilita comunicaciones seguras a través del uso de cifrado simétrico y asimétrico. Si un dispositivo de cliente solicitante 102 en la red desea o requiere comunicaciones cifradas, el dispositivo de cliente solicitante 102 puede generar un par de claves asimétricas (por ejemplo, usando Privacidad Bastante Buena (PGP)) y puede cargar la clave pública en el servidor central 110. Una clave o claves de cifrado pueden intercambiarse entre el servidor y el cliente durante el procedimiento de registro inicial descrito anteriormente. Como alternativa, las claves pueden intercambiarse cuando se desea un cambio en nivel de seguridad sobre una base por petición. El dispositivo de cliente solicitante 102 también puede recibir la clave pública del servidor 110. Puede generarse una clave simétrica o bien en el servidor 110 o bien en el dispositivo de cliente solicitante 102 y tal clave simétrica puede transmitirse a la otra parte cifrando la misma con la clave pública de la otra parte y enviar la información cifrada a través de un enlace directo o indirecto.
Enviar y recibir datos en la red física de dispositivos
El servidor 110 es capaz de comunicarse con una o más pasarelas 106 para alcanzar las interfaces registradas. Una función primaria de una pasarela 106 en el contexto del sistema 100 es proporcionar contenido desde otra red o subred (tal como internet por cable) a clientes inalámbricos, y viceversa. Un ejemplo de una pasarela 106 o puente de red es un encaminador WiFi estándar que conecta una línea de datos por cable (por ejemplo, como se proporciona por un Proveedor de Servicio de Internet) a una red de área local inalámbrica (LAN). Como alternativa, la pasarela podría difundir inmediatamente datos directamente desde el servidor a través de su radio inalámbrica que hay que recibir por clientes inalámbricos o de acuerdo con una planificación de transmisión. Una pasarela 106 puede usar encabezamientos en los datos proporcionados por un servidor 110 para determinar cómo transmitir los datos (canal, tasa, interfaz) y transmitir usando estos ajustes, o puede usar métodos de transmisión normalizados por defecto tales como protocolos de LTE, HSPA, Zigbee, Ethernet o IP antes de recibirse por un cliente. Realizaciones típicas de este documento usan encaminadores WiFi basados en IEEE 802.11 que se ejecutan en modo de punto de acceso (Modo AP) para comunicarse con dispositivos que se ejecutan en modo de estación (Modo STA). Podría parchearse o mejorarse el software de un encaminador inalámbrico estándar para interpretar nuevos paquetes de Ethernet, red o capa de transporte desde el servidor. Estos mensajes podrían incluir el cliente inalámbrico, información de transmisión tal como frecuencia y temporización o potencia de transmisión.
La pasarela tiene dos métodos de transmisión de datos a los clientes inalámbricos. Puede usar su método estándar de comunicación (tal como una tabla de encaminamiento para un encaminador WiFi) para transmitir tráfico de internet para comunicación. Esto permitiría que el cliente inalámbrico reciba información desde el servidor a través de una conexión de internet estándar y establecimiento de encaminador. Este sistema es compatible hacia atrás con normas de red actuales en que los datos transmitidos desde el servidor se encapsulan en paquetes de Ethernet y Protocolo de Internet estándar, y se recibe como tráfico de internet por el cliente inalámbrico.
Clientes que reciben datos (sin procesar)
Los clientes en la red pueden estar escuchando de forma pasiva en busca de paquetes inalámbricos en sus interfaces inalámbricas. En realizaciones preferidas de este documento, los dispositivos están escuchando pasivamente en busca de todos los datos transmitidos independientemente de si el dispositivo es o no el receptor previsto de los datos. Esto se hace de modo que los dispositivos pueden determinar sus vecinos (es decir, dispositivos vecinos), permitiendo que cualquier transmisión desde un dispositivo sirva tanto como una forma de enviar datos y como una forma de determinar la calidad de enlace unidireccional que no son el receptor previsto. Esto puede habilitarse como una funcionalidad no estándar en la mayoría de tarjetas de interfaz de red (NIC), sin embargo puede habilitarse a través de modificaciones al firmware, controlador de software o hardware. Algunas implementaciones proporcionan medios fácilmente disponibles para esta funcionalidad, tal como es el caso con radios definidas por software.
Cuando los clientes reciben datos en sus radios inalámbricas, cada una de las radios de los clientes recibe tráfico en esa banda de frecuencia o canal particular. Los paquetes recibidos por los dispositivos hardware se envían habitualmente a los controladores del dispositivo y la pila de redes. En realizaciones preferidas de este documento, los paquetes se pasan al módulo de software de cliente.
En realizaciones preferidas, los datos transmitidos por cada dispositivo son agnósticos de conexión y protocolo, justo como la virtualización del servidor es agnóstico de conexión. Esto significa que pueden usarse múltiples interfaces de red, normas inalámbricas, protocolos inalámbricos o frecuencias inalámbricas en cualquier transmisión a lo largo de la trayectoria y puede manejarse usando las mismas operaciones de encaminamiento de datos. Esto es distinto a sistemas actuales (convencionales) en los que las tarjetas de interfaz de red se especializan para realizar detección y transmisión de paquetes para un tipo de paquete o protocolo particular. En realizaciones de este documento, el software de cliente hace recepción de trama de múltiples interfaces reconfigurable y dinámica. Por ejemplo, en algunas realizaciones de este documento, el hardware puede leer los protocolos de capa física (802.11, 3GPP, etc. para las interfaces WiFi y celulares como ejemplos) entonces un módulo de software puede usar protocolos de capa de Ethernet reconfigurable (capa 2), red (capa 3) y transporte (capa 4) dependiendo de qué paquetes sin procesar proceden del hardware.
El mismo hardware puede conmutar protocolos basándose en las instrucciones del servidor central.
Una realización preferida de este documento utiliza funcionalidad de supervisión y transmisión de trama sin procesar habitualmente no implementada en las NIC WiFi, sus controladores o el sistema operativo anfitrión. La supervisión de trama sin procesar puede proporcionar métricas útiles al software de cliente tal como la frecuencia de paquetes de acuse de recibo ACK en un área dada que podría notificarse al servidor y usarse para determinar una densidad de velocidad de descarga de dispositivo estimada en un área particular.
Si el protocolo del paquete recibido fuera un protocolo basado en conexión (tal como TCP a través de WiFi), el cliente receptor se comunicaría bidireccionalmente con la pasarela para completar la transferencia de datos.
Una vez que los datos han llegado, el cliente realiza comprobaciones para determinar la integridad de datos, si el paquete se destina para sí mismo, y cómo encaminar el paquete. La integridad de datos puede verificarse usando el método típico de suma de control de los datos contenidos en el paquete y comparación del resultado con la suma de control del paquete. Si el paquete se destina para el primer cliente, los encabezamientos añadidos por el servidor se eliminan y el paquete se pasa a la pila de redes del cliente. El siguiente pseudocódigo demuestra cómo un cliente maneja los nuevos datos recibidos en todas las interfaces inalámbricas. Este código puede implementarse en software o como instrucciones en hardware embebido tal como la NIC inalámbrica.
Pseudocódigo de paquete de proceso
function InterfaceReceivedPacket(interface, packet) {
TopologyNewPacket(packet);
if (packetIsIncomplete(packet)) {
// Paquete está malformado. Notificar a servidor y descartar.
ReportPacketFragment(interface, packet);
return;
}
switch (packet.packetType) {
case PACKET_TYPE_PATH: {
AddPathAndReportConfirmation(packet.path);
break;
}
case PACKET_TYPE_INTERFACE_COMMAND: {
targetInterface =
InterfaceWithID(packet.targetInterface);
InterfaceSendCommand(targetlnterface, packet.command);
break;
}
case PACKET_TYPE_LOCATION_UPDATE: {
SetLocationParameters(packet.data);
break;
}
case PACKET_TYPE_DATA: {
RoutePacket(packet);
break;
}
}
}
Notificar fragmentos de paquete, errores de paquete incompleto
Para protocolos basados en conexión, o protocolos con una estructura de paquete definida tal como datos de 802.11 y tramas de gestión o tramas de Ethernet, los errores de transmisión pueden notificarse al servidor. Estos errores pueden provocarse, por ejemplo, mediante interferencia física o desde colisiones de paquetes. En el caso de interferencia física, el servidor puede reconocer una serie de transmisiones fallidas como interferencia física, y eliminar el enlace de posibles trayectorias. Si los errores persisten como resultado de colisiones de paquetes, el servidor puede usar una conexión fiable a los clientes interferentes para modificar parámetros de transmisión. Esto podría incluir cambiar la radio inalámbrica, la transmisión o la tasa de transmisión. Los errores notificados al servidor ayudan a informar a la red virtual del servidor y soluciones de trayectoria acerca de dónde se ubican áreas o dispositivos propensos a errores en la red.
Clientes que descubren topología local
Cuando los clientes en la red notifican información de transmisión unidireccional al servidor 110, el servidor puede construir un mapa virtual de todas las posibilidades de transmisión que pueden usarse para transferir datos. Como se ha analizado anteriormente, puede haber más de un enlace o trayectoria unidireccional entre dos clientes, representando múltiples interfaces de red, canales y/o direcciones de transmisión a través de los que podrían comunicarse. Dos clientes pueden tener, cada uno, uno o más enlaces unidireccionales hacia el otro, aunque esto puede no siempre ser cierto.
Para mantener un mapa en tiempo real preciso de todas las posibles conexiones en la red, el servidor puede ordenar a uno o más clientes que escuchen en busca de difusiones en una o más interfaces mientras dice simultáneamente a otros clientes que difundan datos en una interfaz o interfaces específicas. Este método también puede usarse para mejorar información de topología limitada o potencialmente desactualizada, o para descubrir la topología en nuevas áreas.
En muchos casos, la información de ubicación se enviará también al servidor desde clientes junto con la información de topología. Esto permite que el servidor registre la ubicación de dónde se recibieron las transmisiones. Combinar esta información con la ubicación de otros clientes conocidos crea un mapa más informado de toda la red. El servidor puede mantener un mapa de la red que puede usarse para mejorar decisiones de encaminamiento. El mapa puede basarse en datos históricos y/o en tiempo real. El mapa puede incluir un registro de transmisiones satisfactorias y no satisfactorias, tiempos y temporización asociados con esas transmisiones, y las ubicaciones de los clientes comunicantes e interfaz o interfaces usadas para comunicar. Agregando estos registros de transmisión, el servidor puede tener un mapa informado de las conexiones en tiempo real en la red simplemente haciendo que los dispositivos en un área con un mapa histórico fiable notifiquen su ubicación. Además de proporcionar mejores decisiones de encaminamiento, el mapa puede limitar la cantidad que los clientes deben difundir para determinar la topología y limitar la cantidad de tiempo que los clientes deben mantener sus tarjetas de interfaz alimentadas para recibir tales paquetes, conservando de este modo la duración de la batería de clientes y reduciendo la congestión de red. Cuando el servidor central determina que un mapa histórico local está suficientemente detallado para las interfaces disponibles de clientes locales que están dentro de los límites del mapa histórico, el servidor central puede ordenar a los clientes que reduzcan la frecuencia en la que los clientes difunden para determinar la topología. A medida que los clientes continúan notificando su ubicación al servidor central, el servidor central puede estimar la topología en tiempo real de la red local y la intensidad de conexión entre clientes combinando el mapa de topología histórico con la ubicación en tiempo real de clientes.
Cuando un cliente está en un modo descentralizado, el servidor central puede elegir enviar los mapas de topología de cliente para ayudar al cliente descentralizado a hacer mejores decisiones de conexión y de encaminamiento. Por ejemplo, un mapa de topología del registro de transmisiones histórico superpuesto con un mapa de topología que lista la ubicación, interfaces disponibles y claves de cifrado de dispositivos locales presentes pueden aumentar la calidad de servicio del cliente en modo descentralizado.
Los clientes pueden notificar la intensidad de señal con la que se recibió un paquete desde un cliente vecino y otras métricas específicas de interfaz tales como la relación señal a ruido SNR de la transmisión, la tasa de datos, tasa de transmisión, ancho de banda, promedios de estas métricas u otras métricas de capa física. Las radios cognitivas y otras radios "inteligentes" pueden ser capaces de notificar otras métricas útiles al servidor tales como bandas de frecuencia disponibles o interferencia a través de bandas. Esta información puede incorporarse en una base de datos de topología local en el software de cliente y en actualizaciones de topología al servidor central.
Clientes que reciben rutas
En una realización típica, los clientes reciben periódicamente información de ruta desde el servidor central a través de un enlace descendente directo. Sin embargo, también puede enviarse información de encaminamiento a clientes a través de un enlace indirecto. La información de ruta puede incluir un identificador, una interfaz de transmisión desde el conjunto de las interfaces registrada del cliente, un identificador para el siguiente dispositivo a usar cuando se reciba una transmisión, e instrucciones de transmisión y/o planificación para datos de encaminamiento. Las instrucciones de ruta sirven como reglas dinámicas y reconfigurables para permitir que los dispositivos participen en múltiples trayectorias de transmisión simultáneamente.
Esta arquitectura basada en trayectoria también proporciona anonimato en transmisiones de datos. El cliente de origen y destino en cada transmisión se identifica únicamente por el identificador de ruta en una transmisión particular.
Las trayectorias recibidas desde el servidor se almacenan en una base de datos local dentro del software de cliente. Las trayectorias pueden clasificarse y buscarse dinámicamente permitiendo que los dispositivos participen en transmisiones de múltiples trayectorias sin realizar decisiones de encaminamiento en el propio dispositivo.
Clientes que reciben operaciones de interfaz
Periódicamente el servidor central puede emitir un paquete de control a un cliente registrado que se concibe para realizar una operación en una interfaz específica. Tales operaciones de interfaz podrían incluir instrucciones para explorar en busca de pasarelas tales como redes WiFi, encender o apagar la radio de la interfaz, o cambiar canal, frecuencia, ancho de banda, escuchar direcciones, crear un grupo directo de WiFi, unirse a un grupo directo de WiFi u otras operaciones. Diferentes interfaces pueden responder a comandos de interfaz de forma diferente sobre una base de por dispositivo, por interfaz.
Un caso de uso típico para comandos de interfaz se produce cuando un cliente notifica una transmisión corrupta, posiblemente el resultado de interferencia producida desde paquetes que colisionan. El servidor puede determinar que un cliente retransmisor debería aumentar su potencia de transmisión para mejorar las oportunidades de transmisión satisfactoria. Como alternativa, el servidor podría ordenar a un cliente interferente que disminuya su potencia de transmisión. Esta menor potencia de transmisión podría comunicarse como una nueva trayectoria si el hardware del dispositivo puede estrangular la potencia de transmisión con latencia limitada o como una operación de interfaz asíncrona a través del enlace descendente directo antes de que se emita un comando. Podrían usarse los mismos procedimientos para cambiar el canal o temporización de transmisiones para evitar colisiones de paquetes con otras partes de la red.
Encaminamiento de paquetes
El software de cliente maneja el encaminamiento de datos para todas las interfaces inalámbricas del cliente. Una función de encaminamiento de datos prototípica es la que se muestra a continuación:
function RoutePacket(packet) {
route = 0;
routeID = packet.id;
route = routeWithID(routeID);
if (!path && packet.headerContainsRoute) {
path = RouteWithHeader(packet.header);
store path
}
// Ignorar paquete sin trayectoria
if (route) {
if (route.destination == self) {
ReceivePacket(packet);
} else {
packet.id = route.nextRouteID;
nextInterface =
InterfaceWithRouteID(route.nextInterface);
transmissionDetails = route.transmissionDetails;
ScheduleTransmission(nextInterface, packet,
transmissionDetails);
}
}
}
Cuando el software de cliente recibe datos, el identificador de ruta en el encabezamiento de los datos recibidos se compara contra la base de datos de ruta local. Si no se encuentra ninguna trayectoria, el software determinará si los propios datos contienen instrucciones de encaminamiento desde el servidor, y construirá y almacenará una representación de ruta local usando la información de encabezamiento.
Los datos recibidos por cualquier cliente en la red pertenecen a una de tres categorías: datos para sí mismo, datos que hay que encaminar y datos para los que el cliente no debería hacer ninguna acción. Si no está disponible ninguna trayectoria, el paquete se descarta, como sería el caso cuando un dispositivo recibe datos desde un dispositivo en el que los datos ya han alcanzado el nodo de destino. El cliente no debería hacer ninguna acción adicional encaminando el paquete a un destino.
Paquetes que hay que encaminar
Debido a que la ruta para un paquete de datos dado se ha predeterminado por el servidor central, cuando se reciben datos por un cliente que no están previstos para el propio cliente, pero una trayectoria está disponible en la lista de trayectorias, el paquete se retransmitirá de acuerdo con la transmisión y/o detalles de planificación contenidos en la trayectoria. Debería observarse que las trayectorias podrían reutilizarse de modo que una única instrucción de trayectoria desde el servidor podría servir miles de paquetes de datos en cualquier momento. El servidor determina el tiempo de expiración para cada ruta en la red y bajo qué condiciones es válido y mantiene esa información en su representación virtual de la red. Esta información se transmite también como información de control a clientes cuando sea necesario.
Paquetes para sí mismos
Una tercera posibilidad de encaminamiento es que un paquete recibido por el cliente se destinó para este cliente particular. Cuando un ID de ruta para los datos entrantes coincide con una ruta en la tabla de rutas del cliente, y la ruta identifica el destino como el propio cliente, el cliente consume el paquete. En algunos casos, el paquete recibido corresponde a un protocolo sin conexiones. En este escenario, el software de cliente elimina la información de encabezamiento de encaminamiento y control desde los datos y pasa los datos a la pila de redes del dispositivo.
Manejo de datos secuenciados/sincronizados - agrupamiento de flujos de datos
Este proceso puede producirse en múltiples capas de la pila de redes. "Datos" y "memorias intermedias" en este punto se refieren a datos enviados recibidos entre los puntos de extremo, en concreto la capa 4 en el modelo OSI o más alta, mientras que "paquetes" se encuadran dentro de capa 3 de OSI y por debajo. El servidor maneja ambos casos de paquetes. En esta sección, estamos expandiendo en la funcionalidad de capa 4 o más alta en el cliente ya que difiere de enviar datos a la pila de redes del dispositivo.
Habitualmente, se usa un protocolo fiable para solicitar y recibir datos. Un protocolo fiable (tal como TCP/IP) está orientado preferentemente a conexión y asegura el orden correcto y la integridad de los datos intercambiados entre un servidor remoto y el dispositivo solicitante.
En un protocolo basado en conexión de este tipo, los errores son comunes y requieren la corrección de errores y mecanismos de reordenación. Estos errores podrían incluir colisiones, sincronización inexacta o imprecisa de antenas de recepción y transmisión, interferencia, o potencia de transmisión insuficiente o amplificación de recepción. La presente invención puede hacer uso de protocolos de resolución de errores existentes (tales como los usados en redes TCP/IP). Este proceso implica enviar paquetes de acuse de recibo (ACK) al servidor o directamente a un servidor remoto usando la conexión de enlace ascendente directo. Además este proceso podría implicar retransmitir los paquetes de ACK desde el dispositivo de recepción de vuelta a través de la red en malla al servidor u otro servidor remoto.
Realizaciones preferidas de este documento emplean transmisiones sin conexiones entre dispositivos en la red, en la que únicamente el cliente receptor es consciente de una transmisión de datos completa. Cuando se requiere una comunicación orientada a conexión, el servidor puede mantener la sesión de conexión en nombre de los clientes en la red, o permite que los clientes gestionen la sesión con un servidor remoto. Cuando el servidor gestiona la sesión de conexión entre el cliente y un servidor remoto, el servidor proporciona una solución novedosa para resolver errores en un entorno sin conexiones. Los errores y/o transmisiones de datos completadas pueden sincronizarse y resolverse usando el servidor.
Usar números de secuencia para garantizar integridad
Un posible esquema de organizar tales transacciones es mantener un número de secuencia para cada cliente que se sincroniza con el servidor. Esta sincronización puede suceder cuando los clientes se conectan inicialmente al servidor o periódicamente a través de paquetes de control intercambiados con el servidor. Usando este método, cuando la información se transmite desde el servidor, el número de secuencia de ese cliente virtual se actualiza por el servidor internamente por la cantidad de datos que hay que enviar. Los datos se envían, a continuación, del servidor de acuerdo con una trayectoria resuelta al cliente de destino. Cuando el cliente recibe los datos, el desplazamiento de sincronización de datos y longitud de paquete contenidos en el encabezamiento de paquete permiten que el cliente ordene los datos y compruebe datos faltantes.
Ejemplo
Un ejemplo de un sistema de este tipo se muestra en la Figura 6(G) en el que el cliente (1) está dentro del alcance de transmisión de la pasarela 1, y el cliente (2) está dentro del alcance de transmisión del cliente (1) en la misma o diferente interfaz inalámbrica, pero no está en el alcance de la pasarela 1. También se supone para este ejemplo que el cliente (1) y el cliente (2) tienen una segunda interfaz inalámbrica a través de la que pueden alcanzar la pasarela 2 que puede comunicarse con el servidor central.
Un ejemplo concreto de un sistema de este tipo mostrado en la Figura 6(G) es una zona de acceso WiFi que actúa como la pasarela 1, y una torre celular que actúa como la pasarela 2. El cliente (1) y el cliente (2) son dispositivos móviles que contienen tanto radios celulares como WiFi. Se supone para este ejemplo que el servidor se comunica con cada pasarela a través de la internet (usando líneas de cable de fibra u otra fuente de red de retorno).
En este ejemplo, los errores de transmisión pueden producirse en cualquiera de los enlaces A, B, C, D, E o F en el diagrama. Se supone para este ejemplo, sin embargo, que los enlaces A y D son enlaces bidireccionales por cable para los que un protocolo de resolución de errores podría implementarse si fuera necesario. Protocolos de internet estándar que implican TCP/IP y sus opciones de extensión de tamaño de ventana podrían resolver estos errores con latencia insignificante.
Usando el sistema de comunicación descrito en las secciones, se supone que el segundo cliente es capaz de recibir información desde el servidor a través del primer cliente. Esta transmisión utiliza la trayectoria "A, B, E" como se genera por el servidor.
Supóngase, en aras de ejemplo, que el servidor emite tres paquetes previstos para el segundo cliente (2) y transmite los mismos usando la pasarela a través del enlace A (Figuras 6(H)-6(I)). Supóngase que el primer cliente (1) recibe los paquetes {1,3} pero no recibe el paquete {2}. Cuando el primer cliente (1) no recibe el paquete {2}, el cliente genera un error. El cliente construye una petición o indicación de error que hay que enviar al servidor. Como un mínimo, la petición o indicación de error debería identificar el tipo de error. En algunas realizaciones de este documento, la petición o indicación de error también puede indicar la ubicación de inicio del intervalo y la longitud de los datos faltantes. El cliente notifica al servidor el error a través de la trayectoria "C, D" usando su conexión de enlace ascendente directo. El servidor puede determinar, a continuación, cómo resolver este error. Tras recibir la notificación de error desde el primer cliente, el servidor calcula una nueva trayectoria y reenvía el paquete {2} a través de esta nueva trayectoria. La nueva trayectoria puede ser la trayectoria original "A, B" u otra, por ejemplo, la trayectoria "D, C" (Figuras 6(J)-6(K)).
Se produce un segundo escenario posible si el segundo cliente (2) no recibe los paquetes {1} o {3} (Figuras 6(L)-6(M)). En el escenario de ejemplo en la Figura 6(L), el cliente (2) puede notificar al servidor a través del enlace F que no recibió los paquetes {23}. El servidor calcula una nueva trayectoria para transferir los paquetes {23} al cliente (2), que puede ser la trayectoria original "A, B, E" o la trayectoria alternativa "D, F".
En algunas realizaciones, el primer cliente no necesita tener información sobre el número de paquetes o el orden de los paquetes, aunque un sistema de este tipo puede requerir que el segundo cliente (el cliente de recepción previsto) tenga información sobre el número de paquetes y el orden de los paquetes. En otras palabras, en algunos casos, el cliente 1 no requiere ninguna información acerca de los paquetes distinta de dónde enviar los mismos, y el cliente 2 solo puede notificar errores y hacer que se resuelvan. Como debería apreciarse, si el cliente 1 también notifica un error, esto beneficiaría a la red porque en trayectorias de múltiples saltos el sistema podría determinar el segmento de trayectoria a través del cual fallaron los paquetes.
Esta información puede transmitirse de forma más fiable usando la conexión directa a través de la pasarela 2, empleando las trayectorias "D, C" y "D, F" para sincronizar los dispositivos en la red para el número y tamaño de paquetes que deberían esperar.
En algunas realizaciones, los propios paquetes pueden contener información de sincronización que podría usarse para validar el orden y número de paquetes recibidos. En un cliente dado, puede emplearse una memoria intermedia de recepción que mantiene un registro de la información recibida desde el servidor central, por ejemplo, como se muestra en la Figura 6(N).
Cuando el primer cliente recibe un paquete de datos, el paquete puede contener un desplazamiento de sincronización y longitud de los datos que se transmiten. El primer cliente mantiene una enumeración local de la cantidad de datos recibidos desde el servidor, y puede incrementar su desplazamiento de recepción por la longitud del paquete recibido. En el ejemplo en la Figura 6(N), el intervalo de sincronización 1 sigue al intervalo 0; por lo tanto, el dispositivo ha recibido todos los datos hasta el nuevo desplazamiento.
A medida que el primer cliente recibe información, el intervalo de datos {2} y el intervalo de datos {4} no se reciben y generan errores en la cuenta de sincronización del primer cliente. Estos errores provocan fragmentos en los datos transmitidos por el servidor, resultando en fragmento A y fragmento B. Pequeños paquetes de datos {B, C, D, E} así como el paquete {G} llegan satisfactoriamente y pueden pasarse inmediatamente la pila de redes del primer cliente. Los intervalos de datos faltantes {2, 4} generan errores, que el primer cliente notifica de vuelta al servidor.
Generalizando el método anterior a más de dos clientes, pueden implementarse algunas posibilidades de resolución de errores adicionales. Si múltiples trayectorias al cliente de destino están disponibles y se produce un error en una trayectoria dada, los datos faltantes pueden retransmitirse usando la segunda trayectoria.
Cuando el primer cliente recibe el paquete {3}, el desplazamiento de sincronización y longitud dejan un hueco en la memoria intermedia de recepción del primer cliente, como se muestra en la Figura 6(O). El primer cliente puede calcular, a continuación, el intervalo faltante de datos usando el desplazamiento actual y la longitud de datos faltantes, y notificar esta información al servidor para su resolución.
Este método permite recepción y consumo de datos asíncronos y no ordenados. Un único flujo de datos puede proporcionar datos solicitados por protocolos de nivel superior siempre que esos datos se vuelven disponibles. Por ejemplo, un vídeo almacenado en memoria intermedia cuyos paquetes se reciben fuera de orden o con error podría entregar fotogramas recibidos al usuario en trozos. Esto podría ser más eficiente y experimentar una latencia menor que otros métodos de entrega cuando, por ejemplo, un usuario está buscando rápidamente a través de un archivo de vídeo.
Notificar finalizaciones
Los diversos clientes y la pasarela pueden elegir notificar individualmente la finalización de transmisiones de datos al servidor y métricas de dispositivo actualizadas (incluyendo RSSI, duración de la batería, etc.). Sin embargo, cada cliente y/o pasarela notificará errores de transmisión de datos cuando se está proporcionando una conexión fiable. Los errores de transmisión se determinan cuando los clientes no han recibido un paquete esperado dentro de la ventana de tiempo como se indica por la planificación de encaminamiento enviada por el servidor a través del enlace descendente directo. Esto proceso puede producirse a lo largo de toda la transmisión inalámbrica usando una diversidad de diferentes enlaces al servidor.
Tratamiento de errores - retransmisión de paquetes
Cuando se notifican errores por la red y necesitan resolverse mediante la retransmisión, el servidor puede usar sus datos almacenados en memoria caché para facilitar la resolución de errores. El servidor envía el Intervalo de Datos 0 al cliente, avanza el desplazamiento de envío y, a continuación, reciben un error para el Intervalo de Datos 0. Aunque el desplazamiento de envío permanece en el Intervalo de Datos 1, el servidor usa el Intervalo de Datos 0 almacenado en memoria intermedia, que aún reside en memoria, para reenviar la información sin tener que buscar los datos de nuevo.
La información acerca de la llegada del paquete de datos en el primer cliente puede notificarse al servidor junto con información de sincronización o confirmación de la llegada del paquete. No recibir esta confirmación provocará que el servidor registre un error a través de esa trayectoria particular, y puede resultar en el reenvío de los datos por el servidor a la pasarela o a través de otra trayectoria al cliente de destino.
Considérese un caso en el que un primer cliente se asocia con la pasarela (en este punto un punto de acceso WiFi) y el segundo cliente no está asociado con el punto de acceso WiFi pero está dentro del alcance de transmisión desde el punto de acceso WiFi.
En este ejemplo, tanto el primer cliente como el segundo cliente reciben el paquete A desde la pasarela. El primer cliente reconoce el destino del paquete como sí mismo y el origen del paquete. El paquete se reenvía, a continuación, a la pila de redes. El segundo cliente recibe simultáneamente el paquete A y también reconoce que el paquete se destinó para el primer cliente. En lugar de descartar el paquete, el segundo cliente ahora registra las características de transmisión del paquete A enviado por la pasarela tal como el origen, relación señal a ruido, canal, tasa e información de protocolo. Sin asociación, el segundo cliente ahora se ha dado cuenta de su capacidad de recibir datos desde la pasarela. La calidad puede determinarse por la intensidad de señal recibida de la transmisión, o simplemente el número de paquetes o la tasa de paquetes recibidos desde la pasarela. El procedimiento descrito anteriormente es muy similar a cómo los puntos de acceso WiFi difunden nombres de red usando tramas de baliza. Un punto de acceso hace uso de la dirección difundida o tramas de datos de gestión para notificar a los clientes potenciales una disponibilidad de red y la intensidad de señal relativa cuando se conectan a esa red. Este procedimiento de difusión puede extenderse a los propios dispositivos de tal forma que un dispositivo puede ser consciente de su capacidad de recibir datos desde otros dispositivos recibiendo transmisiones de forma pasiva.
Resolución de errores a través de último cliente satisfactorio
Ya que realizaciones preferidas de este documento describen un método sin conexiones para pasar datos, este procedimiento puede usarse para resolver errores directamente entre pares que han encaminado anteriormente los datos. Por ejemplo, si un primer dispositivo de cliente necesita transmitir información a un segundo dispositivo de cliente el servidor 110 se notifica a través del enlace ascendente directo que el primer dispositivo de cliente 102 necesita comunicarse con el segundo dispositivo de cliente 102. El servidor 110 considera los enlaces de radio y conexiones de internet disponibles de los clientes, y determina una trayectoria o serie de trayectorias desde el primer cliente al segundo cliente a través de cualquier combinación de interfaces de red o radios inalámbricas.
Considérese un escenario en el que otro cliente (por ejemplo, un tercer cliente) descarga información desde el servidor a través de la pasarela y almacena la información descargada en memoria. El servidor ha descargado y almacenado preventivamente contenido en el tercer cliente que hay que usar en un momento posterior.
En un momento posterior cuando otro cliente (por ejemplo, un cuarto cliente) solicita datos desde el servidor, el servidor puede enviar esos datos en tiempo real desde la red, utilizando una transmisión entre el tercer cliente y el cuarto cliente como se describe en el sistema anteriormente. Sin embargo, debido a que el tercer cliente ya recibió algunos datos desde la internet, si el cuarto cliente solicitó un subconjunto de estos datos, entonces, el servidor podría usar la caché local de datos descargados en el tercer cliente. El servidor podría notificar de forma segura al tercer cliente que el cuarto cliente está solicitando datos almacenados en su caché, y podría ordenar al tercer cliente que difunda datos al cuarto cliente usando la trayectoria de transmisión disponible.
Considérese el ejemplo de la Figura 6(P), en el que el cliente (7) ha solicitado datos desde el servidor, y el servidor ha enviado el paquete de respuesta A a través de la trayectoria "1, 3, 6, 7". Aunque cada cliente (1, 3, 6) recibió y reenvió un paquete A, se produjo un error cuando el cliente (6) transmitió la información al cliente (7). El cliente (7) notificará al servidor el error y el servidor determinará una trayectoria para reenviar los datos.
Aunque las trayectorias "2, 4, 5, 3, 6, 7", "1, 3, 6, 7" y la pasarela de ancho de banda bajo son todas trayectorias candidatas, la trayectoria más eficiente es "6, 7". Usando la conexión de ancho de banda bajo (en este punto, la red celular) el servidor ordena al cliente (6) retransmitir el paquete A al cliente (7) como en la Figura 6(Q). El cliente (3), el cliente (1) o incluso la pasarela podría usarse para retransmitir los datos.
Esta estrategia puede generalizarse adicionalmente a cualquier trayectoria de ramificación en la red como se muestra en las Figuras 6(R)-6(S). Cuando una transmisión falla entre el cliente (2) y el cliente (4) como en la Figura 6(R), el cliente (1) puede usarse como un cliente satisfactorio pasado para transmitir el paquete A a través de la nueva subtrayectoria "1, 3, 4". Cuando los clientes son capaces de almacenar en caché información, cualquier cliente que ha recibido la información satisfactoriamente puede usarse para retransmitir los datos adicionalmente al destino. El tamaño de la caché puede variar por cliente y podría modificarse por el servidor en áreas propensas a errores.
FASE 3 - CIERRE
El software de cliente y el servidor central software finalizan preferentemente fácilmente el registro de un cliente. Cuando se corta la conexión primaria de enlace ascendente directo de un cliente, posiblemente debido a una pérdida de servicio celular, el software de cliente intentará reconectarse al servidor central usando la misma u otra interfaz. Si la conexión no puede restablecerse, tal como sucedería cuando un dispositivo se apaga o se queda sin batería, el servidor detecta la conexión cortada a través de un tiempo de espera o a través de errores de conexión notificados por otros dispositivos que dependen del cliente desconectado. El cliente desconectado no está registrado en la representación virtual de la red. Cualquier trayectoria que implica el cliente como un dispositivo de retransmisión se invalidará, y cualquier trayectoria activa se solucionará de nuevo. El software de cliente se registrará de nuevo con el servidor de encaminamiento central cuando el dispositivo se encienda de nuevo.
Comunicación con dispositivos remotos/bases de datos/servidores
La comunicación con dispositivos remotos y bases de datos puede lograrse a través de una diversidad de métodos. Siempre que la información pueda proporcionarse al servidor, puede almacenarse y usarse para actualizar topología y de este modo mejorar el encaminamiento. Los recursos remotos también pueden proporcionar contenido que hay que encaminar a clientes, que es el uso primario de tal funcionalidad. Cuando los clientes solicitan información desde el servidor, a menudo la información no reside localmente en el servidor. Cuando la información solicitada se almacena localmente en el servidor, puede entregarse directamente cuando se solicite.
Cuando la información no reside en el servidor, debe obtenerse desde un sitio remoto, tal como un servidor remoto o cliente que aloja la información solicitada, y se proporciona al cliente o clientes solicitantes. En algunas situaciones, esta información se solicita directamente desde un servidor remoto a través de un protocolo de red estándar tal como HTTP, FTP, AFP, SMB o protocolos similares. Cuando el sitio remoto proporciona el recurso solicitado, el recurso se encamina a través del servidor central al cliente solicitante. Donde sea preferible, el servidor puede optar por segmentar el recurso en paquetes y proporcionar el recurso en varios trozos, parte de memoria intermedia o todo el recurso, o enviar el recurso al cliente como un flujo de paquetes.
Cuando un recurso representa una conexión a una ubicación remota, los paquetes recibidos desde un cliente solicitante pueden reenviarse directamente al sitio remoto. Esto se produce habitualmente cuando un cliente solicita una conexión de TCP a un servidor remoto que hay que usar con datos de difusión en continuo. En este escenario, los paquetes de IP y/o TCP se reenvían al servidor remoto como si el servidor fuera una VPN. A continuación, se encaminan paquetes de respuesta desde el servidor remoto a los clientes. En algunos escenarios, puede requerirse una modificación a los encabezamientos de TCP/IP. Esta funcionalidad se maneja por el servidor antes de que los datos se encaminen al cliente o al sitio remoto.
Encaminamiento
En una realización ilustrativa de este documento, la instalación central 104 determina una ruta y trayectoria entre clientes. Una transmisión entre dos clientes puede producirse cuando la instalación central determina la necesidad de una transmisión entre clientes después de examinar la demanda y topología de red, a continuación determinar que un segmento de trayectoria debería incluirse en una trayectoria. Como tal, un único segmento de trayectoria entre dos clientes puede o no usarse en cualquier ruta dada y puede o no usarse cuando se envía información adicional al mismo cliente de destino. Un sistema que elimina una jerarquía entre clientes permite muchas más posibles conexiones entre clientes en un área que un sistema que implementa una jerarquía entre nodos. Por consiguiente, existen muchas más trayectorias a través de las que pueden fluir datos. Ya que la instalación central tiene información completa o casi completa en tiempo real acerca de la red, incluyendo topología y demanda de red, puede elegir la ruta o rutas (por ejemplo, trayectoria, canal, temporización, alcance de emisión, etc.) más adecuada para conseguir los datos al cliente solicitante para cada paquete de datos transmitido.
FLUJO DE RED
Una instalación central o servidor es responsable de regular el flujo de datos a través de la red. El servidor realiza combinaciones de uno o más de los siguientes: mantiene un mapa de la topología de red total; mantiene un registro de transmisión anterior y en cola para todos los clientes en la red; optimiza flujos de datos de red individuales y totales usando métricas que incluyen, pero sin limitación a, disponibilidad de canal, temporización, tasa de transmisión, interfaz de red, potencia de transmisión, antena, trayectoria, dirección, memoria disponible y tiempo de procesamiento; se comunica con dispositivos remotos y servidores y recupera datos solicitados; determina instrucciones de encaminamiento para cada cliente en la red; comunicación unidireccional o bidireccional con dispositivos; proporciona información de encaminamiento a clientes; y resuelve errores de transmisión.
Información almacenada
Otra capacidad del servidor central es la gestión de una base de datos de información de cliente pertinente. Esta información puede proporcionarse por clientes en la red, utilizar el historial pasado de la red, o proporcionarse de forma local o remota al servidor. Los clientes pueden proporcionar información al servidor directamente tal como su número de modelo, número de serie, el número de interfaces de red, hardware de radio, dirección de red (por ejemplo, IP, MAC), duración de la batería restante, si el cliente se alimenta externamente y el espacio de almacenamiento disponible entre otras métricas.
Además de la información proporcionada por los clientes, el servidor también puede buscar de forma local o remota información que hay que usar en el cálculo de trayectorias o crear el mapa de topología. La información local puede incluir una tabla de consulta para el alcance de transmisión de diferentes radios inalámbricas por número de serie y configuración de antena. Como alternativa, la base de datos puede incluir configuraciones para diferentes modelos del cliente u otra información miscelánea/auxiliar. Por ejemplo, una base de datos de terceros puede proporcionar las especificaciones para cada teléfono inteligente y las capacidades (por ejemplo, Bluetooth, WiFi, etc.) de un cliente, de forma que no se requeriría a los clientes que proporcionen esta información al servidor a través del enlace de control. Adicionalmente, el servidor puede supervisar y realizar seguimiento de cómo los clientes del mismo modelo han funcionado en la red para hacer decisiones de encaminamiento más precisas. Información almacenada en el servidor puede usarse a medida que se vuelve disponible para informar la decisión de encaminamiento hecha por el servidor.
Actualizaciones coordinadas por servidor
Aunque el servidor se diseña para facilitar descargas de ancho de banda alto y cargas relativamente pequeñas, el servidor puede soportar funcionalidad de carga cuando no es posible por el enlace ascendente directo. Un ejemplo sería un cliente que puede recibir transmisiones de radio ham de largo alcance, pero no es capaz de transmitir de vuelta a la fuente. El servidor puede aún hacer uso de radio de largo alcance para coordinar canales, frecuencias, y sincronizar todos los clientes en la red. Adicionalmente, el servidor podría coordinar trayectorias de carga para transportar datos usando el enlace de control. Como alternativa, si una red celular no tenía el ancho de banda para realizar la carga, una trayectoria de carga podría notificarse a través de un enlace descendente directo a todos los clientes en la trayectoria que realiza la carga.
Con referencia, por ejemplo, a los dibujos en la Figura 6(T), si el cliente (5) solicita una carga de datos y la conexión de ancho de banda bajo no puede servir la petición, el servidor central puede notificar a los clientes (1, 3 y 5) que formarán parte de una trayectoria de carga, y el servidor puede ordenar al cliente (5) que transmita a lo largo de la trayectoria "5, 3, 1" de vuelta a la pasarela. El servidor puede coordinar la carga al igual que la descarga, y planificar la trayectoria junto con otras descargas para evitar interferencia. Los errores pueden resolverse de forma similar usando la inversa del procedimiento analizado anteriormente. Técnicas aplicables podrían incluir resolver errores usando un cliente anteriormente satisfactorio o ajustar las características de transmisión para mitigar errores de transmisión.
Resolución de errores (último cliente satisfactorio)
Otro método para resolver errores en la red aprovecha las capacidades anteriores con instrucciones adicionales desde el servidor. Cuando el servidor recibe un error que resulta desde una trayectoria de datos indirecta (es decir, una trayectoria de datos que no usa una conexión directa), el servidor puede usar el último cliente satisfactorio para resolver el error. En este escenario, el servidor no envía los datos solicitados a la pasarela una segunda vez. Puede ordenarse a los clientes que han recibido los datos satisfactoriamente que redifundan los datos. Dependiendo de cambios en topología de red y otros factores, el servidor central puede elegir cambiar la ruta y trayectoria desde el último nodo satisfactorio al dispositivo de destino en lugar de elegir hacer que los dispositivos en la trayectoria intenten redifundir los datos. De manera similar, el servidor central puede determinar enviar los datos solicitados a través de un enlace descendente directo si una nueva ruta y trayectoria no pueden determinarse desde el último nodo satisfactorio al dispositivo de destino.
Considérese, por ejemplo, la red en la Figura 6(P), en la que el cliente (7) ha solicitado datos desde el servidor, y el servidor ha enviado el paquete de respuesta A a través de la trayectoria "1, 3, 6, 7". Aunque cada uno de los clientes (1,3,6) recibió y reenvió el paquete A, se produjo un error cuando el cliente (6) transmitió la información al cliente (7). El cliente (7) notificará al servidor el error y el servidor determinará una trayectoria para reenviar los datos. Aunque las trayectorias "2, 4, 5, 3, 6, 7", "1, 3, 6, 7" y la pasarela de ancho de banda bajo son todas trayectorias candidatas, la trayectoria más eficiente es simplemente "6, 7". Usando la conexión de ancho de banda bajo (en este punto la red celular) el servidor ordena al cliente (6) que retransmita el paquete A al cliente (7), como se muestra en la Figura 6(Q). Naturalmente, el cliente (3), el primer cliente o incluso la pasarela podría usarse para retransmitir los datos.
Facilitar red de entrega de contenido
Cuando los clientes son capaces de almacenar en caché información, cualquier cliente que ha recibido la información satisfactoriamente puede usarse para retransmitir los datos adicionalmente al destino. Naturalmente, el tamaño de la caché puede variar por cliente y podría modificarse por el servidor en áreas propensas a errores.
En este punto, aunque el servidor considera la trayectoria al cuarto cliente a través de la pasarela, porque el tercer cliente ya tiene los datos solicitados por el cuarto cliente, únicamente es necesaria una transmisión para proporcionar al cuarto cliente los datos solicitados.
Aunque no es aplicable a todos los escenarios, este procedimiento es muy eficiente cuando el mismo contenido se transfiere periódicamente entre los mismos clientes. Por ejemplo, cuando múltiples clientes inalámbricos cargan el mismo recurso de vídeo desde la internet, los datos se descargan únicamente por la pasarela desde la internet una vez. Cada vez que un nodo servido por la pasarela solicita el recurso de vídeo, el servidor puede ordenar a otro cliente que ya ha descargado el vídeo transmitir los datos localmente.
Esta estrategia junto con las capacidades de encaminamiento del servidor central puede generalizarse adicionalmente a cualquier trayectoria de ramificación en la red cuando los clientes registrados también pueden actuar como nodos en una red en malla descentralizada.
PUENTE CENTRALIZADO - DESCENTRALIZADO
En un escenario en donde un cliente no tiene un enlace ascendente directo para hacer peticiones a la instalación central, los clientes con enlaces ascendentes directos pueden marcarse o registrarse como pseudo pasarelas. Los clientes sin un enlace ascendente directo a la instalación central pueden usar esquemas de encaminamiento descentralizado estándar (es decir, encaminamiento proactivo o reactivo) y algoritmos o protocolos de encaminamiento (por ejemplo, OLSR o BATMAN) para enviar sus peticiones de carga a un cliente con un enlace ascendente directo a la instalación central. Si se usa un esquema de encaminamiento proactivo, los mapas de topología de la red en malla descentralizada pueden cargarse al servidor central a través de una pseudo pasarela conectada a servidor en alcance de un cliente que se ejecuta únicamente como un miembro de la red en malla descentralizada. Una vez que un cliente conectado a servidor con un enlace ascendente directo recibe una petición de carga a través de un cliente sin un enlace de carga directo, puede retransmitir inmediatamente la petición a través de su propio enlace ascendente directo a la instalación central. La instalación central puede elegir, a continuación, enviar los datos de respuesta de vuelta al cliente solicitante a través de clientes o pasarelas con una conexión directa al servidor. Aunque el servidor puede tener información de topología de red menos completa acerca de la red descentralizada, los datos pueden encaminarse de tal forma que se dirige hacia el cliente solicitante. Los clientes intermediarios con un enlace ascendente directo pueden notificar información de finalización a medida que el paquete pasa a través de trayectorias en la red descentralizada, proporcionando información al servidor acerca de la recepción satisfactoria o no satisfactoria del paquete. Este escenario ilustrativo se ilustra en la Figura 6(U).
En un escenario en el que un cliente no puede crear un enlace ascendente directo al servidor, tal como los dispositivos 2-6 representados en la Figura 6(U), o un escenario en el que se alcanza el servidor 110 a través de una serie de clientes, puede compartirse la capacidad de enlace ascendente para proporcionar peticiones al servidor 100. En el caso más sencillo, un dispositivo de cliente conectado (inalámbricamente o de otra manera) a un segundo dispositivo de cliente puede usar su propia conexión de enlace ascendente para reenviar peticiones al servidor en nombre del primer dispositivo de cliente.
Como se muestra en la Figura 6(V), un dispositivo de cliente 1 está fuera del área de cobertura de una conexión de enlace ascendente directo, pero dispositivo de cliente 2 es capaz de una conexión directa al servidor 110. El dispositivo de cliente 1 es ordenado por el servidor o puede reenviar automáticamente peticiones en nombre del cliente 2, al servidor. Estas peticiones incluyen actualizaciones a información de topología y ubicación, información de nivel de batería y peticiones de datos, notificaciones de errores o cargas de datos. Aunque el servidor no puede registrar totalmente el cliente en la red, ni puede coordinar directamente su transmisión de datos, puede usar los datos proporcionados por el cliente 1 cuando compila información de topología y mapea uso de espectro. Adicionalmente, el servidor registra el dispositivo de cliente para recibir datos, pero entiende que los datos pueden no alcanzar el destino. El servidor también puede asignar una prioridad más alta o más baja en términos de procesamiento de ruta, uso de espectro, u otros recursos de red a clientes que no puede gestionar directamente. Como debería apreciarse, esto cubre casos en los que la malla descentralizada es realmente la mejor opción.
Los dispositivos de encaminamiento pueden establecer un enlace de enlace ascendente directo y/o enlace descendente directo al servidor central. Los dispositivos de encaminamiento con un enlace ascendente directo también pueden reenviar peticiones al servidor 110 en nombre de otros dispositivos que no pueden establecer un enlace ascendente directo por sí mismos. Los dispositivos de encaminamiento inician conexiones al servidor para traer los mismos a la red, y el servidor inicia una serie de comunicaciones de asociación para registrar el dispositivo de encaminamiento para la red usando el dispositivo 102 como una pasarela en la red en malla. Durante la fase de asociación, se intercambian claves de seguridad, certificados, números de modelo y serie, versión e información de protocolo con el dispositivo 102 a través de la red en malla descentralizada en puente por el cliente para validar la integridad del dispositivo de encaminamiento y comunicaciones futuras seguras. El proceso de registro es similar al procedimiento usado para clientes con una conexión de enlace ascendente directo, pero puede incluir información adicional acerca de la red descentralizada tal como el identificador de Conjunto Básico de Servicios Independiente (IBSS) o el desplazamiento de función de sincronización de temporización.
Este marco puede extenderse adicionalmente al escenario mostrado en la Figura 6(U) en el que se producen una serie de conexiones fuera del área de cobertura de enlace ascendente directo. En este escenario, podría desplegarse una red en malla estándar entre los clientes (1-6) en los que el primer cliente es capaz de encaminar información desde la red en malla descentralizada al servidor. El primer cliente puede registrar la red descentralizada con el servidor, o registrar clientes individuales en la red. El primer cliente también notificará al servidor su capacidad para encaminar información en la red y también puede notificar qué clientes puede alcanzar. En esencia, el primer cliente asume simultáneamente la funcionalidad de una pasarela a la red en malla y un cliente al servidor central. Debería apreciarse que permitir que un dispositivo funcione tanto como un miembro de la red en malla, como una pasarela, y como el cliente de una pasarela inalámbrica puede requerir un número de restricciones de hardware, tales como operación en el mismo canal, se requieren para que este comportamiento de múltiples funciones sea completamente compatible. Los dispositivos pueden elegir conmutar rápidamente canales para preservar sus múltiples funciones en una topología de red dada, y el servidor puede usarse para facilitar los desafíos de temporización y coordinación de canal cuando se pregunta a los clientes que se unan a múltiples redes. En ciertas otras soluciones, múltiples antenas para una interfaz inalámbrica dada pueden mitigar estos problemas, permitiendo que una interfaz dada envíe y reciba datos en múltiples canales, anchos de banda o tasas de datos simultáneamente. A menudo sin embargo, estos casos requerirán una atención especial en el controlador y núcleo de dispositivo anfitrión para garantizar conexiones estables en ambas redes.
Naturalmente, el servidor puede encaminar datos a un cliente que no tiene un enlace ascendente directo usando el método sin conexiones descrito en las secciones anteriores, siempre que la topología de red proporcione una trayectoria al destino. En casos en los que no existe ningún enlace ascendente o enlace descendente directo desde el servidor central a un cliente, pueden enviarse indirectamente instrucciones de encaminamiento a través de la parte de par a par de la red desde el servidor central. Se espera que la latencia de coordinación de servidor de una ramificación de red en malla descentralizada a través de un único cliente introducirá problemas de latencia y rendimiento inadecuados para la mayoría de clientes. El conocimiento de la red descentralizada por el servidor central beneficiará sin embargo la representación virtual del servidor de la red. Por ejemplo, el conocimiento de una red en malla en una cierta área podría indicar una probabilidad creciente de errores de transmisión en el área descentralizada debido a colisiones de paquetes.
Por ejemplo, como se muestra en la Figura 6(W), si el cliente (1) se conecta a una zona de acceso WiFi como su pasarela, el cliente (2) tiene tanto una NIC WiFi como un chip celular, y el tercer cliente tiene un chip celular, el tercer cliente puede recibir paquetes de internet desde la pasarela a través de los clientes (1) y (3).
El beneficio de este esquema de red (como se representa en la Figura 6(W)) es hacer disponible la red de retorno conectada a la pasarela y accesible a través del primer cliente a los clientes (2) y (3). En este escenario, el cliente (2) también opera como un puente de red, recibiendo paquetes WiFi desde el primer cliente y retransmitiendo los mismos como paquetes celulares al tercer cliente.
Incluso cuando una conexión de enlace ascendente está disponible, algunos clientes pueden elegir gestionar sus propias conexiones. Como debería apreciarse, esto cubre grupos de WiFi Directa que tienen algunos estados de conexión descentralizada que se ejecutan a lo largo de las transmisiones centralizadas. Considérese, por ejemplo, el ejemplo mostrado en la Figura 6(X). En este ejemplo, los dispositivos (1-5) están todos dentro del área de cobertura de enlace ascendente, pero únicamente el cliente (1) y el cliente (5) se están comunicando a través del enlace ascendente directo. También existen conexiones bidireccionales entre el dispositivo (4) y el cliente (5), el dispositivo (3) y el cliente (5), y el cliente (1) y el dispositivo (2). En este punto, el cliente (5) puede participar simultáneamente en la subred que consta de los dispositivos (35) y la red coordinada por servidor. Asimismo, la conexión bidireccional entre el cliente (1) y el dispositivo (2) puede producirse sin coordinación de servidor. Aunque el servidor no puede coordinar los dispositivos (24) directamente, el cliente (1) y el cliente (5) pueden notificar al servidor sus conexiones bidireccionales, la presencia de la subred de conexiones, y cualquier métrica utilizable de la subred tal como la frecuencia que se usa o la ubicación física de cada dispositivo en la red. El servidor puede usar esta información para coordinar de forma inteligente clientes en la red y proporcionar información a través del cliente (1) y el cliente (5) a la subred.
Incluso cuando los clientes eligen gestionar sus propias conexiones, pueden aún notificar información de topología y rutas de servicio a otros clientes. Un ejemplo es un encaminador inalámbrico que tanto aloja su propia red inalámbrica como puede elegir si participar en la red de auto organización. Tales clientes pueden implementar subconjuntos de la funcionalidad de clientes típicos, y el servidor usará cualquier información y capacidades publicadas por el cliente para informar mejor su representación virtual de la red. Un ejemplo típico sería un encaminador WiFi inteligente que tanto aloja su propia red WiFi en modo AP, notifica información de topología al servidor central basándose en su propia red, como acepta comandos de operación de interfaz desde el servidor que interpreta como sugerencias sobre cómo manejar sus clientes. El encaminador también puede encaminar paquetes a través de su propia subred sin exponer sus clientes registrándose en nombre de los clientes en su propia red. Este método ofrecería seguridad y anonimato mejorados mientras proporciona al servidor central información de topología para esa área particular.
Funcionalidad típica del servidor o servidores
Cada servidor 110 en la instalación central 104 es un sistema informático tal como el sistema informático 800 descrito a continuación.
Funcionalidad típica de los dispositivos
Cada dispositivo de comunicación 102 es un sistema informático tal como el sistema informático 800 descrito a continuación. El dispositivo de comunicación 102 incluye preferentemente una o más interfaces inalámbricas (por ejemplo, un componente Bluetooth, un componente WiFi, un componente 3G/4G, etc.) y un procesador de banda base (para control de radio).
Los clientes son capaces de recibir los datos alrededor de los mismos. Ya sea directamente en el hardware del cliente o indirectamente a través de la NIC inalámbrica, los clientes pueden recibir transmisiones inalámbricas desde dispositivos inalámbricos vecinos. Los clientes pueden facilitar la recepción de datos en múltiples canales, posiblemente a través de múltiples antenas, simultáneamente.
En escenarios en los que se transmite un paquete de datos a un cliente, y otro cliente está en la vecindad, el cliente no objetivo puede interceptar e interpretar los fragmentos de datos. Registrando esta transmisión recibida y notificando la misma al servidor, el servidor puede determinar mejor la calidad de enlace a ese cliente. El cliente podría usar información de encabezamiento contenida en los datos y almacenar esta información o notificar esta al servidor. Por ejemplo, en una red inalámbrica en la que muchos clientes se conectan en el mismo canal a un punto de acceso, un cliente podría interceptar un paquete de datos de 802.11 desde el punto de acceso destinado para otro cliente. Dentro del encabezamiento de datos de 802.11 está contenida la dirección de MAC de destino y de origen de cada cliente implicado en la transferencia. El cliente de supervisión no implicado en la transferencia puede recibir el paquete de datos, identificar las direcciones de MAC de emisor y receptor, y notificar al servidor que el cliente de supervisión es capaz de recibir paquetes transmitidos desde el punto de acceso. Este proceso puede producirse sin ninguna comunicación entre el cliente de supervisión y el punto de acceso.
Una capacidad de dispositivo adicional podría ser estrangular potencia de transmisión para una radio inalámbrica dada. El cliente podría ajustar la potencia de transmisión dependiendo del tipo de transmisión o instrucción desde el servidor.
Las radios inalámbricas también pueden alternar su canal de recepción en tiempo para escuchar en busca de datos en múltiples frecuencias. También pueden emplearse radios cognitivas para identificar frecuencias o canales en los que existen una gran o pequeña cantidad de tráfico, especialmente si existe una gran cantidad de datos que se transmiten en canales públicos por dispositivos cuyas transmisiones no se están coordinando por el servidor. Estos datos pueden compilarse en el cliente y comunicarse al servidor.
Las radios inalámbricas o antenas, múltiples radios, o antenas pueden usarse simultáneamente para comunicación de datos. Tal agrupación de canales o agrupación de interfaces puede manejarse automáticamente por el hardware del dispositivo (como es el caso para muchas NIC inalámbricas) o puede tratarse como múltiples radios que operan con restricciones. Por ejemplo, una NIC inalámbrica podría usar múltiples antenas simultáneamente para transmitir el mismo flujo de datos a un segundo cliente con múltiples antenas de recepción. Una vez recibidos, los flujos podrían combinarse para formar el flujo de datos final proporcionado al cliente. Como alternativa, el cliente podría anunciar las múltiples antenas de la NIC independientemente, y el cliente podría notificar al servidor que las antenas se originan desde la misma NIC.
De acuerdo con una aplicación ilustrativa, los dispositivos no pueden comunicarse directamente entre sí en un sistema jerárquico. La jerarquía se elimina a través de la introducción del servidor central, que permite un aumento general en eficiencia para el espectro inalámbrico de una cierta área.
Recepción de paquete Interfaces virtuales
La implementación de lado de cliente del sistema en su forma más general puede resumirse mediante cinco operaciones:
1) Interfaz Transmitir paquete/datos - esta función toma una cantidad de datos arbitraria como un argumento y entrega los mismos a la antena inalámbrica;
2) Interfaz Enviar paquete/datos - esta función recibe una cantidad de datos arbitraria y entrega los mismos al software de cliente;
3) Interfaz Conseguir parámetro - esta función consulta una interfaz virtual para capacidades o ajustes actuales (tales como canal, o la unidad de transmisión máxima (MTU) de la interfaz inalámbrica;
4) Interfaz Establecer parámetro - esta función establece un parámetro particular en una interfaz virtual (tal como cambiar el canal inalámbrico);
5) Interfaz Encaminar datos - esta función examina datos entrantes en forma de un paquete y determina el destino final de los datos. Si el paquete estaba previsto para este cliente particular, se consumen los datos. Si no, se retransmite el paquete. Juntas, estas operaciones, y cualquier otras obvias a un experto en la materia, constituyen una interfaz virtual para un cliente dado. Cada interfaz virtual puede diferir en cómo se transmiten y reciben datos, la unidad de transmisión mínima y máxima (MTU), y las capacidades del hardware subyacente tales como canal, tasa, frecuencia, trama o agregación de encabezamiento u otras características similares. Tras el registro en el servidor, se establecen las capacidades de la interfaz virtual, y puede ejecutarse el dispositivo inalámbrico. Es importante observar que un dispositivo de cliente puede tener múltiples interfaces virtuales operando simultáneamente. Implementar tal comportamiento puede ser desafiante, aunque es necesario para una experiencia fluida.
Desafortunadamente, en la actualidad pocos dispositivos inalámbricos tienen soporte total para este tipo de funcionalidad. Aunque el hardware inalámbrico es capaz de tales características en todos los casos, a menudo existen limitaciones en la pila de redes que evitan esta funcionalidad. Como resultado, el soporte de interfaz del software de cliente puede depender de la arquitectura y/o puede requerir implementar estas cinco capacidades en un dispositivo de cliente particular. Pueden usarse tres métodos comunes para implementar esta funcionalidad 1) hardware personalizado 2) modificaciones de firmware y 3) modificaciones de controlador. Los expertos en la materia comprenderán y apreciarán, tras la lectura de esta descripción, que pueden usarse diferentes y/u otros métodos de implementación.
Los dispositivos móviles tales como teléfonos inteligentes a menudo utilizan una tarjeta de interfaz de red inalámbrica que ejecuta un pequeño sistema operativo para transmitir y recibir datos inalámbricos. El sistema operativo puede ejecutar un pequeño programa que simplifica la transmisión y recepción de paquetes de protocolo estándar (tales como tramas de 802.11 o paquetes de 3GPP/LTE). En el caso de un dispositivo móvil de este tipo, el programa de firmware responsable para la recepción y transmisión de paquetes inalámbricos se modificará preferentemente para soportar comunicación desde un dispositivo a otro dispositivo. Esta es una funcionalidad no estándar de tales tarjetas de red. El firmware a menudo está precompilado y es propietario. Usando herramientas de ingeniería inversa, es posible aplicar ingeniería inversa a tal firmware y modificar sus programas para conseguir recepción y transmisión personalizadas de información.
Recepción de paquetes sin procesar
Los dispositivos móviles tales como teléfonos inteligentes utilizan tarjetas de interfaz de red inalámbrica que a menudo ejecutan un pequeño sistema operativo para transmitir y recibir datos inalámbricos. El sistema operativo puede ejecutar un pequeño programa que simplifica la transmisión y recepción de paquetes estándar (tales como tramas de 802.11 o paquetes de 3GPP/LTE).
Por ejemplo, como se muestra en la Figura 7, en una realización típica, cuando se reciben los paquetes A, B, C y D por una tarjeta de interfaz de red inalámbrica ("NIC") dentro del dispositivo de cliente, una NIC inalámbrica es responsable de ensamblar paquetes recibidos a través del aire. A medida que se reciben los paquetes A, B, C y D por la NIC inalámbrica, se descarta como incompleto cualquier fragmento incompleto que no pasa la validación por una suma de control u otra métrica de calidad.
A continuación, la NIC típica o el software del cliente aplica un filtro de capa de Control de Acceso al Medio (MAC) al destino y origen de cada paquete y compara los mismos con el cliente. De acuerdo con un escenario ilustrativo, el cliente procesa únicamente paquetes enviados desde un origen conocido y que coinciden con la tabla de trayectoria del cliente. Estos paquetes son los concebidos para el cliente para su reenvío o consumo (el destino). Esto es un sistema robusto para evitar que se propaguen errores de transmisión a la pila de redes de un cliente, y también permite que múltiples clientes compartan el mismo canal sin procesar erróneamente información de procesamiento no prevista para ese cliente.
Los paquetes recibidos en una NIC del cliente desde el servidor central o un dispositivo vecino proporcionan el destino, origen y un identificador. Esto puede ser la dirección IP de origen del emisor, la dirección de MAC de origen o una dirección de Zigbee del dispositivo de transmisión. Esta información se compara contra las tablas de encaminamiento locales del cliente y los paquetes se consumen, retransmiten o descartan. La información desde el paquete, incluyendo el origen, destino, identificador y longitud, e integridad puede examinarse y registrarse en una tabla local para su posterior notificación al servidor.
Una limitación potencial en algunas de estas implementaciones es preservar la concurrencia de la pila de redes inalámbricas y las nuevas modificaciones. La mayoría de API de red no se diseñaron para conectarse simultáneamente a puntos de acceso y transmitir datos "a través del aire" porque sin instrucciones de encaminamiento correctas esto puede conducir a interferencia para otros dispositivos o una batería agotada. WiFi directa es una modificación de este tipo a firmware, controlador y la pila de redes inalámbricas de espacio de núcleo en muchas API que permiten conexiones de par a par entre dispositivos. Aunque tramas sin procesar no pueden transmitirse, WiFi directa no expone una API de transmisión/recepción entre dispositivos pares. Desafortunadamente, en algunas implementaciones la norma de WiFi directa no se escribió para acomodar dispositivos pares mientras asocia simultáneamente con una o más redes WiFi. Como resultado, el núcleo a menudo descarta la conexión al punto de acceso en favor del dispositivo par, visualizando a menudo mensajes de error a los usuarios de dispositivo, alentando a los mismos que se desconecten. Esto limita mucho la capacidad de descargar datos desde una red WiFi a pares. La funcionalidad de múltiples funciones WiFi se añade preferentemente a través de la modificación de la implementación de WiFi directa por defecto al sistema operativo o controladores de un dispositivo. Esta funcionalidad puede interactuar, a continuación, con el software de cliente.
El servidor central también puede determinar dónde existen problemas de concurrencia, y donde sea posible, realizar rutas que usan tarjetas de interfaz diferentes para tener una concurrencia efectiva si fuera necesario. Por ejemplo, el servidor puede utilizar tanto LTE Directa y WiFi Directa cuando encamina a través de un cliente particular. El cliente puede usar tanto su hardware celular como hardware WiFi al mismo tiempo ocupando diferentes bandas de frecuencia. Como resultado, la red de retorno WiFi de un cliente se hace disponible a múltiples clientes a través del uso de múltiples interfaces simultáneamente.
Transmisión de paquetes sin procesar
Para redifundir paquetes desde la tarjeta inalámbrica, la tarjeta debería configurarse preferentemente para transmitir paquetes a dispositivos arbitrarios sin una conexión preestablecida. Preferentemente, la tarjeta inalámbrica tendrá capacidad de transmitir o inyectar tramas de paquete personalizadas a través del aire sin asociación con un punto de acceso. Esto también puede requerir una modificación al sistema operativo anfitrión y/o núcleo anfitrión así como al controlador. Esto también puede requerir que el cliente o el servidor determine desplazamientos de temporización o funciones para las transmisiones basándose en el protocolo que se use. Estos cambios pueden ser necesarios para implementar transmisiones personalizadas desde un dispositivo a otro dispositivo sin que el dispositivo esté asociado o de otra manera conectado al dispositivo receptor. Pueden ser necesarias modificaciones adicionales para cambiar la tasa, canal u otros atributos de modo físicos basándose en una instrucción desde el servidor.
En el caso de un dispositivo móvil de este tipo, el programa de firmware responsable para la recepción de paquetes inalámbricos se modificará preferentemente para soportar transmisión de tramas sin procesar desde un dispositivo a otro dispositivo. Esta es una funcionalidad no estándar de algunas tarjetas de red. El firmware de NIC en dispositivos móviles a menudo está precompilado y es propietario. Usando herramientas de ingeniería inversa, es posible aplicar ingeniería inversa a tal firmware y modificar sus programas para conseguir transmisión personalizada de información.
Modificaciones de controlador/firmware
En algunas situaciones, esta funcionalidad de supervisión y difusión sin procesar debe habilitarse mediante un parche al controlador de la tarjeta inalámbrica y/o el núcleo del sistema operativo anfitrión. Esta técnica es efectiva para tarjetas inalámbricas que notifican todos los paquetes al sistema operativo anfitrión independientemente de su destino u origen. Los dispositivos en ocasiones incluyen un "modo de supervisión" usado en situaciones de depuración para diagnosticar problemas de red, y la mayoría de tarjetas estándar tienen esta capacidad de depuración. En algunas situaciones, el núcleo del sistema operativo anfitrión también necesitará una modificación o cambios en los ajustes para notificar al dispositivo que la tarjeta inalámbrica está recibiendo todas las transmisiones en el canal actual. Estos cambios también requieren que el dispositivo anfitrión no filtre los paquetes entrantes basándose en la dirección de destino u origen, y en su lugar reenvíe todos los paquetes a la pila de redes o a software personalizado para uso de topología o malla.
En el caso de que un dispositivo móvil de este tipo, el programa de firmware responsable para la recepción de paquetes inalámbricos se modificará preferentemente para soportar recepción de tramas sin procesar desde un dispositivo a otro dispositivo. Esta es una funcionalidad no estándar de tales tarjetas de red. El firmware a menudo está precompilado y es propietario. Usando herramientas de ingeniería inversa, es posible aplicar ingeniería inversa a tal firmware y modificar sus programas para conseguir recepción personalizada de información.
Un método de reprogramación del firmare de una NIC es para identificar el conjunto de chips y desmontar el binario de firmware con una herramienta tal como IDA. Usando las instrucciones (de ensamblaje) a nivel de máquina, pueden identificarse funciones comunes, y funciones personalizadas implementadas usando las funciones comunes creadas en el firmware. Después de identificar las funciones de manipulación de memoria comunes así como las funciones de transmisión, recepción y creación de paquetes usadas por el software de las tarjetas de red, pueden programarse una serie de funciones personalizadas a lo largo de las operaciones de tiempo de ejecución estándar del dispositivo. Estas funciones redirigen paquetes entre el dispositivo anfitrión y la radio inalámbrica de tal forma que todas las transmisiones recibidas por el dispositivo se reenvían al anfitrión, y paquetes personalizados enviados por el anfitrión se transmiten por la antena de la NIC. Esta solución alternativa consigue un soporte total de supervisión e inyección sin interferir con el conjunto estándar de operaciones de la NIC.
Implementación y rendimiento
WiFi y WiFi Directa de Android en Motorola G (1a Generación)
En ciertas situaciones, las normas IEEE 802.11 (a, b, g, n, ac, ad, etc.) junto con la extensión de WiFi directa de estas normas proporcionan otra forma de implementar la funcionalidad prevista de los clientes. Hemos probado cómo funciona el sistema en estos casos, específicamente en dispositivos Android con raíz. Estos dispositivos personalizados ejecutan una versión modificada del núcleo de Android basado en Linux en el que la pila WiFi de nivel bajo se ha modificado para encaminar tráfico de red a través del software de cliente. Modificaciones adicionales al subsistema WiFi habilitaron funcionalidad de WiFi y WiFi directa concurrente, demostrando de este modo las oportunidades de descarga de múltiples saltos reivindicadas en esta realización. Aunque únicamente ciertos microteléfonos soportan el software en la actualidad, estos microteléfonos constituyen una gran porción del mercado móvil. El procedimiento también puede extenderse a otros microteléfonos basados en Android y proporcionar un paso hacia la implementación de un control de trama total en el controlador del dispositivo.
Modo de supervisión en iPhone
Transmisiones personalizadas a través de normas de IEEE 802.11.
El software de encaminamiento escrito en C/C++ podría optimizarse adicionalmente para el hardware de un dispositivo particular. Para demostrar esto, nuestro código formalizó nuevas estructuras de paquetes necesarias para la comunicación entre dispositivos, comunicarse con el servidor de encaminamiento, e integrar creación de interfaz virtual y lógica de encaminamiento en una librería de software general.
El controlador implementó su propia funcionalidad de "conseguir parámetro" y "establecer parámetro" para cambiar el comportamiento de transmisión del hardware en forma de llamadas de IOCtl (control de entrada/salida). Las funciones personalizadas modificaron esta funcionalidad para incluir funciones de transmisión y recepción sin procesar que podrían llamarse desde un programa de espacio de usuario. La huella general de esta modificación fue menos de 100 líneas de código ensamblador.
Como resultado de la modificación de firmware, el firmware notificó todas las tramas de datos recibidas al programa de cliente de espacio de usuario a petición. Estas incluyeron paquetes no previstos para el propio dispositivo, incluyendo tramas de gestión y control usadas para unirse a redes, solicitar información de transmisión o realizar sincronización. Adicionalmente, un programa de espacio de usuario podría inyectar tramas sin procesar a través del aire. En combinación con un proceso en segundo plano de espacio de usuario y UI que ejecutan la lógica de encaminamiento desde la implementación 1, se consiguieron las 5 funciones de núcleo.
Con las modificaciones de firmware, el microteléfono móvil preservó sus capacidades inalámbricas de exploración y unión a redes inalámbricas, pero añadió la funcionalidad para enviar y recibir información personalizada. Esto se verificó satisfactoriamente enviando datos de prueba entre dispositivos en los canales 1, 6 y 11 en la banda de 2,4 GHz. En un entorno de WiFi densa mientras los dispositivos se conectaron simultáneamente a una red, tres dispositivos fueron capaces de pasar datos en forma de tramas sin procesar en una tasa de aproximadamente 500 kbps. Estas velocidades se miden enviando una cadena predecible de caracteres de longitud fija docenas de veces entre microteléfonos idénticos con las mismas modificaciones. Finalmente, con las modificaciones de firmware y formato de paquete de tramas de 802.11, estos dispositivos fueron capaces de realizar seguimiento de dispositivos vecinos por sus direcciones de Control de Acceso al Medio (MAC). El programa de espacio de usuario podría pedir a la interfaz virtual, por lo tanto, los vecinos en la actualidad en alcance de transmisión.
Estos resultados constituyeron un sistema totalmente funcional que satisface todos los requisitos de dispositivo anteriores. La funcionalidad añadida podría describirse mejor como un modo de supervisión concurrente con capacidades de inyección de paquetes. El modo de supervisión se demostró recibiendo paquetes de ACK y tramas de gestión desde la NIC, mientras que la inyección de paquetes se demostró elaborando tramas de baliza que difunden un SSI de red (Identificador de Conjunto de Servicios) que no existía y visualizando esa red en dispositivos no modificados.
Dispositivos/encaminadores de Internet de las Cosas
Realizaciones de este documento son útiles para uso con/en dispositivos de IoT (Internet de las Cosas). Muchos dispositivos de IoT son únicamente económicos si tienen una conectividad barata. Esto significa que para muchos dispositivos, no es económicamente viable pagar por acceder a una red que proporcionaría al dispositivo de IoT una conexión de enlace ascendente o enlace descendente directo a la internet, tal como una conexión celular o por satélite. Adicionalmente, el dispositivo de IoT puede colocarse en un área en la que, a menudo debido a razones de red de retorno, económicas o legales, no es razonable desplegar un punto de acceso tal como una zona de acceso WiFi que permitiría que el dispositivo de IoT tuvieran una conexión directa barata a la internet. Encaminadores y dispositivos de IoT pueden programarse para usar protocolos de encaminamiento descentralizados como BATMAN, OLSR, etc. para conectarse con clientes cercanos hasta que establece una conexión con una pseudo pasarela. En este escenario, el dispositivo de IoT actúa como un cliente sin un enlace ascendente directo. Este método a menudo proporcionará la conectividad barata necesaria para hacer un dispositivo de IoT económico. En otra implementación del sistema descrito, desplegar software de dispositivos de IoT que permiten a los mismos registrarse en el servidor y hacer conexiones descentralizadas con dispositivos cercanos pueden permitir que un grupo de dispositivos de IoT hagan uso de menos conexiones de enlace ascendente directo. Desplegando el software descrito en los dispositivos de IoT, únicamente uno de los dispositivos de IoT en el grupo necesitaría tener una interfaz que proporciona una capacidad de enlace ascendente directo y una suscripción para usar dicho enlace ascendente directo.
Beaglebone
Una realización usa el transceptor inalámbrico de 2,4 GHz de Nordic Semiconductors (nRF24L01) y un Beagle Bone (microcontrolador basado en Linux). El nRF24L01 expone una API para transmitir y recibir tramas de datos y establecer y conseguir parámetros del dispositivo tales como el canal de transmisión actual. Debido a limitaciones en el firmware del dispositivo, ciertos parámetros deseables, sin embargo, podrían no modificarse. La API expone poco control de la política de acuse de recibo (ACK) de las transmisiones, el tamaño de trama, tasa de transmisión o potencia de transmisión. El tiempo de respuesta del dispositivo cuando transmite datos en el orden de 1 Mb fue en cierto modo impredecible cuando se implementó. Adicionalmente, como un medio de control para errores, el firmware API requirió un esquema de direccionamiento no óptimo con direcciones limitadas que únicamente aproximó la funcionalidad de recepción prevista. Para realizar encaminamiento, se instaló un programa de encaminamiento de espacio de usuario en el Beaglebone escrito en C/C++ que definió un formato de paquete prototipo para transmisiones personalizadas. El formato de paquete incorporó información de encaminamiento (como una secuencia de saltos desde el dispositivo inicial), canal e información de temporización en el encabezamiento de cada paquete. La longitud de carga útil de cada paquete también se almacenó. Cada paquete también contenía una carga útil de datos de longitud variable que permite transmisiones de datos entre dispositivos. Cuando se probó, el sistema transfirió datos sin errores a una tasa de aproximadamente 40 kbps. Esta velocidad representó una eficiencia del 30-50 % del máximo teórico de 112,5 kbps. La eficiencia limitada y máximo caudal se debió en gran medida al cableado del sistema, el protocolo de transferencia usado entre el nRF24L01 y el procesador de Beaglebone.
iOS Multipar
Se construyó otro sistema de cliente prototipo usando las API MultipeerKit de iOS proporcionado por Apple en el SDK de iOS. La funcionalidad de nivel alto de MultipeerKit permite a los desarrolladores usar conexiones de par a par entre dispositivos de iOS a través de conexiones WiFi y Bluetooth gestionadas por sistema. El MultipeerKit permite una operación de Bluetooth y WiFi concurrente y permite conexiones de par a par mientras se conecta simultáneamente a una red WiFi.
El presente sistema se probó con un servidor central conectado a través de una conexión LAN a una red WiFi a nivel de empresa. Un iPhone 6 se conectó a la red WiFi de ancho de banda alto mientras otros dos teléfonos se llevaron a "Zona Muertas WiFi" conocidas dentro del área de prueba. Una red WiFi de largo alcance de ancho de banda ancho se conectó por cable directamente al servidor; proporcionó un enlace de control adecuado de vuelta al servidor aislado de la red WiFi de empresa. Con esta configuración, cada dispositivo tenía una conexión directa al servidor, pero únicamente el dispositivo cercano a la red empresarial experimentó velocidades de descarga sin procesamiento superiores de 20 Mbps.
Los dos dispositivos de cliente de ancho de banda bajo se llevaron fuera de alcance de la red empresarial a la misma ubicación, pero entre 6 a 30,48 metros (20 a 100 pies) desde el iPhone 6 retransmisor conectado a la red empresarial.
Usando el servidor central, se habilitó una trayectoria de malla para uno de los dispositivos de ancho de banda bajo mientras que el otro dispositivo actuó como un control.
A través de este sistema de salto único, el cliente habilitado en malla vio un aumento de más de 10 Mbps en velocidades de datos en ciertas ubicaciones en exteriores en comparación con el control y también permaneció conectado incluso cuando el dispositivo de control ya podría comunicarse con la pasarela de control. Las velocidades de malla máximas registradas a más de 15,24 metros (50 pies) del dispositivo en malla fueron superiores a 15 Mbps. Se mostró un aumento promedio de aproximadamente 7 Mbps usando las técnicas de múltiple saltos centralizadas después de probar en diversas ubicaciones en edificios y calles en ciudades urbanas.
Controlador/encaminador
La implementación preferida es una transmisión semi personalizada a través de normas de IEEE 802.11. En esta tercera implementación del sistema, el conocimiento de los primeros tres prototipos se combina en un sistema más integrado. Varios controladores inalámbricos en Linux, especialmente las tarjetas inalámbricas Atheros, dependen en gran medida de una API de SoftMAC conocida como mac80211. Ciertas tarjetas inalámbricas, en concreto el hardware basado en Atheros exponen una Capa de Abstracción de Hardware (HAL) que permite una funcionalidad similar a las modificaciones de firmware para propósitos de prueba. Usando el marco de mac80211, la transmisión de enlace-capa de paquetes puede configurarse para ejecutarse en el controlador permitiendo que un software de núcleo-espacio modifique y cree tramas que abandonan el dispositivo. Para algunas NIC inalámbricas, puede soportarse una funcionalidad de modo de supervisión completa configurando el hardware para pasar todas las tramas al núcleo. A su vez, el núcleo proporciona filtrado y encaminamiento en software en lugar de hardware.
CÁLCULO
Las aplicaciones, servicios, mecanismos, operaciones y actos mostrados y descritos anteriormente se implementan, al menos en parte, mediante software que se ejecuta en uno o más componentes o sistemas informáticos o dispositivos de usuario (por ejemplo, los dispositivos 102 y el servidor o servidores 110 en la Figura 1). Debería apreciarse que cada dispositivo de usuario es, o comprende, un sistema informático.
Programas que implementan tales métodos (así como otros tipos de datos) pueden almacenarse y transmitirse usando una diversidad de medios (por ejemplo, medios legibles por ordenador) de un número de formas. Puede usarse circuitería por cable o hardware personalizado en lugar de, o en combinación con, algunas o todas de las instrucciones de software que pueden implementar los procesos de diversas realizaciones. Por lo tanto, diversas combinaciones de hardware y software pueden usarse en lugar de software únicamente.
Un experto en la materia apreciará y entenderá fácilmente, tras la lectura de esta descripción, que los diversos procesos descritos en el presente documento pueden implementarse mediante, por ejemplo, ordenadores de fin general programados apropiadamente, ordenadores de fin especial y dispositivos informáticos. Uno o más de tales ordenadores o dispositivos informáticos pueden denominarse como un sistema informático.
La Figura 8(A) es un diagrama esquemático de un sistema informático 800 en el que pueden implementarse y efectuarse realizaciones de la presente divulgación.
De acuerdo con el presente ejemplo, un sistema informático 800 puede incluir un bus 802 (es decir, interconectar), uno o más procesadores 804, una memoria principal 806, memoria de sólo lectura 808, medios de almacenamiento extraíbles opcionales 810, un almacenamiento masivo 812, uno o más puertos de comunicaciones 814, dispositivo o dispositivos de ubicación 816 y uno o más sensores 818. El puerto o puertos de comunicación 814 pueden conectarse a una o más redes (por ejemplo, redes informáticas, redes celulares, etc.) por medio de las que el sistema informático 800 puede recibir y/o transmitir datos. El dispositivo o dispositivos de ubicación 815 pueden incluir dispositivos GPS y similares que pueden usarse para determinar una ubicación del dispositivo.
Como se usa en el presente documento, un "procesador" significa uno o más microprocesadores, unidades de procesamiento central (CPU), dispositivos informáticos, microcontroladores, procesadores de señales digitales o dispositivos similares o cualquier combinación de los mismos, independientemente de su arquitectura. Un aparato que realiza un proceso puede incluir, por ejemplo, un procesador y esos dispositivos tales como dispositivos de entrada y dispositivos de salida que son apropiados para realizar el proceso.
El procesador o procesadores 804 pueden ser (o incluir) cualquier procesador conocido, tal como, pero sin limitación a, un procesador o procesadores de Intel® Itanium® o Itanium 2®, procesador o procesadores de AMD® Opteron® o Athlon MP®, o líneas de Motorola® de procesadores y similares. El puerto o puertos de comunicaciones 814 pueden ser cualquiera de un puerto RS-232 para su uso con conexión telefónica basada en módem, un puerto de 10/100 Ethernet, un puerto de Gigabit que usa cobre o fibra, o un puerto USB y similares. El puerto o puertos de comunicaciones 814 pueden elegirse dependiendo de una red tal como una Red de Área Local (LAN), una Red de Área Extensa (WAN), una Red de Distribución de Contenidos (CDN), o cualquier red a la que se conecta el sistema informático 800. El sistema informático 800 puede estar en comunicación con dispositivos periféricos (por ejemplo, la pantalla de visualización 822, el dispositivo o dispositivos de entrada 824) a través del puerto de Entrada/Salida (E/S) 820. Algunos o todos de los dispositivos periféricos pueden integrarse en el sistema informático 800, y el dispositivo o dispositivos de entrada 818 pueden integrarse en la pantalla de visualización 822 (por ejemplo, en el caso de una pantalla táctil).
El dispositivo o dispositivos de ubicación 816 pueden incluir un conjunto de chips de GPS. El uno o más sensores 818 pueden incluir un acelerómetro y otros sensores para determinar información acerca del dispositivo.
La memoria principal 806 puede ser Memoria de Acceso Aleatorio (RAM), o cualquier otro dispositivo o dispositivos de almacenamiento dinámico comúnmente conocidos en la técnica. La memoria de sólo lectura 808 puede ser cualquier dispositivo o dispositivos de almacenamiento estático tales como chips de Memoria de Sólo Lectura Programable (PROM) para almacenar información estática tal como instrucciones para el procesador o procesadores 804. El almacenamiento masivo 812 puede usarse para almacenar información e instrucciones. Por ejemplo, pueden usarse discos duros tales como la familia de Adaptec® de controladores de Interfaz en Serie de Ordenadores Pequeños (SCSI), un disco óptico, una matriz de discos tales como Matriz Redundante de Discos Independientes (RAID), tal como la familia de Adaptec® de controladores de RAID, o cualquier otro dispositivo de almacenamiento masivo.
El bus 802 acopla comunicativamente el procesador o procesadores 804 con los otros bloques de memoria, almacenamiento y comunicaciones. El bus 802 puede ser una PCI/PCI-X, SCSI, un bus de sistema basado en Bus Serial Universal (USB) (u otros) dependiendo de los dispositivos de almacenamiento usados y similares. Los medios de almacenamiento extraíbles 810 pueden ser cualquier clase de discos duros externos, Memoria de Sólo Lectura de Disco Compacto (CD-ROM), Disco Compacto Regrabable (CD-RW), Memoria de Sólo Lectura de Disco Versátil Digital (DVD-ROM), etc.
Realizaciones en el presente documento pueden proporcionarse como uno o más productos de programa informático, que pueden incluir un medio legible por máquina que tiene almacenado en el mismo instrucciones, que pueden usarse para programar un ordenador (u otros dispositivos electrónicos) para realizar un proceso. Como se usa en el presente documento, el término "medio legible por máquina" se refiere a cualquier medio, una pluralidad de los mismos, o una combinación de diferentes medios, que participan en la provisión de datos (por ejemplo, instrucciones, estructuras de datos) que pueden leerse por un ordenador, un procesador o un dispositivo similar. Un medio de este tipo puede tomar muchas formas, incluyendo, pero sin limitación, medios no volátiles, medios volátiles y medios de transmisión. Medios no volátiles incluyen, por ejemplo, discos ópticos o magnéticos y otra memoria persistente. Medios volátiles incluyen memoria de acceso aleatorio dinámica, que habitualmente constituye la memoria principal del ordenador. Los medios de transmisión incluyen cables coaxiales, alambre de cobre y fibras ópticas, que incluyen los alambres que comprenden un bus de sistema acoplado al procesador. Medios de transmisión pueden incluir o transmitir ondas acústicas; ondas de luz y emisiones electromagnéticas, tales como aquellas generadas durante comunicaciones de datos de radiofrecuencia (RF) y de infrarrojos (IR).
El medio legible por máquina puede incluir, pero sin limitación, discos flexibles, discos ópticos, CD-ROM, disco magneto-ópticos, ROM, RAM, memorias de sólo lectura programables borrables (EPROM), memorias de sólo lectura eléctricamente programables borrables (EEPROM), tarjetas ópticas o magnéticas, memoria flash u otro tipo de medios/medio legible por máquina adecuado para almacenar instrucciones electrónicas. Además, realizaciones en el presente documento también pueden descargarse como un producto de programa informático, en donde el programa puede transferirse desde un ordenador remoto a un ordenador solicitante por medio de señales de datos incorporados en una onda portadora u otro medio de propagación a través de un enlace de comunicación (por ejemplo, módem o conexión de red).
Diversas formas de medios legibles por ordenador pueden estar implicadas en transportar datos (por ejemplo, secuencias de instrucciones) a un procesador. Por ejemplo, los datos pueden (i) entregarse desde RAM a un procesador; (ii) transportarse a través de un medio de transmisión inalámbrica; (iii) formatearse y/o transmitirse de acuerdo con numerosos formatos, normas o protocolos; y/o (iv) encriptarse en cualquiera de una variedad de formas bien conocidas en la técnica.
Un medio legible por ordenador puede almacenar (en cualquier formato adecuado) esos elementos de programa que son apropiados para realizar los métodos.
Como se muestra, la memoria principal 806 se codifica con la aplicación o aplicaciones 822 que soporta o soportan la funcionalidad como se analiza en el presente documento (una aplicación 822 puede ser una aplicación que proporciona parte o toda la funcionalidad de uno o más de los mecanismos descritos en el presente documento). La aplicación o aplicaciones 822 (y/u otros recursos como se describe en el presente documento) pueden incorporarse como código de software tal como datos y/o instrucciones lógicas (por ejemplo, código almacenado en la memoria o en otro medio legible por ordenador tal como un disco) que soporta una funcionalidad de procesamiento de acuerdo con diferentes realizaciones descritas en el presente documento.
Por ejemplo, como se muestra en la Figura 2(A), la aplicación o aplicaciones 822 pueden incluir aplicación o aplicaciones de servidor. En el caso del dispositivo, como se muestra en la Figura 3, la aplicación o aplicaciones 822 pueden incluir las aplicaciones 136.
Durante la operación de una realización, el procesador o procesadores 804 acceden a la memoria principal 806, por ejemplo, a través del uso del bus 802 para lanzar, efectuar, ejecutar, interpretar o realizar de otra manera las instrucciones lógicas de la aplicación o aplicaciones 822. La ejecución de la aplicación o aplicaciones 822 produce una funcionalidad de procesamiento del servicio o servicios o mecanismo o mecanismos relacionados con la aplicación o aplicaciones. En otras palabras, el proceso o procesos 824 representan una o más porciones de la aplicación o aplicaciones 822 que se realizan dentro de o en el procesador o procesadores 804 en el sistema informático 800.
Por ejemplo, el proceso o procesos 824 pueden incluir proceso o procesos de dispositivos que corresponden a una o más de la aplicación o aplicaciones de dispositivo 822.
Debería observarse que, además del proceso o procesos 824 que efectúan operaciones como se analiza en el presente documento, otras realizaciones en el presente documento incluyen la aplicación 822 (es decir, las instrucciones y/o datos lógicos no ejecutados o que no funcionan). La aplicación 822 puede almacenarse en un medio legible por ordenador (por ejemplo, un repositorio) tal como un disco o en un medio óptico. De acuerdo con otras realizaciones, la aplicación 822 también puede almacenarse en un sistema de tipo de memoria tal como en firmware, memoria de sólo lectura (ROM) o, como en este ejemplo, como código ejecutable dentro de la memoria principal 806 (por ejemplo, dentro de la Memoria de Acceso Aleatorio o RAM). Por ejemplo, la aplicación 822 también puede almacenarse en los medios de almacenamiento extraíbles 810, la memoria de sólo lectura 808 y/o el dispositivo de almacenamiento masivo 812.
Los expertos en la materia entenderán que el sistema informático 800 puede incluir otros procesos y/o componentes de software y hardware, tales como un sistema operativo que controla la asignación y uso de recursos de hardware.
Como se analiza en el presente documento, realizaciones de la presente invención incluyen diversas etapas u operaciones. Una diversidad de estas etapas puede realizarse mediante componentes de hardware o pueden incorporarse en instrucciones ejecutables en máquinas, que pueden usarse para provocar que un procesador de fin general o fin especial programado con las instrucciones realice las operaciones. Como alternativa, las etapas pueden realizarse por una combinación de hardware, software y/o firmware. El término "módulo" se refiere a un componente funcional autocontenido, que puede incluir hardware, software, firmware o cualquier combinación de los mismos.
Un experto en la materia apreciará y entenderá fácilmente, tras la lectura de esta descripción, que realizaciones de un aparato pueden incluir un ordenador/dispositivo informático operable para realizar parte (pero no necesariamente todo) el proceso descrito.
Realizaciones de un medio legible por ordenador que almacenan un programa o estructura de datos incluyen un medio legible por ordenador que almacena un programa que, cuando se ejecuta, puede provocar que un procesador realice (pero no necesariamente todo) el proceso descrito.
Donde se describe un proceso en el presente documento, los expertos en la materia apreciarán que el proceso puede operar sin ninguna intervención de usuario. En otra realización, el proceso incluye alguna intervención humana (por ejemplo, se realiza una etapa por o con la asistencia de un humano).
Tiempo real
Los expertos en la materia comprenderán y entenderán, tras la lectura de esta descripción, que, como se usa en el presente documento, el término "tiempo real" significa casi tiempo real o suficientemente en tiempo real. Debería apreciarse que existen retardos intrínsecos en comunicación basada en red (por ejemplo, basándose en tráfico de red y distancias), y estos retardos pueden provocar retardos en datos que alcanzan diversos componentes. Retardos intrínsecos en el sistema no cambian la naturaleza de tiempo real de los datos. En algunos casos, el término "datos en tiempo real" puede referirse a datos obtenidos en tiempo suficiente para hacer los datos útiles para su propósito previsto.
Aunque el término "tiempo real" puede usarse en este punto, debería apreciarse que el sistema no está limitado por este término o por cómo se toma realmente el tiempo. En algunos casos, cálculo en tiempo real puede referirse a un cálculo en línea, es decir, un cálculo que produce su respuesta o respuestas a medida que llegan datos y, generalmente, continúa con datos que llegan de forma continua. El término cálculo "en línea" se compara con un cálculo "fuera de línea" o "en lote".
Como se usa en esta descripción, el término "porción" significa parte o todo. Por tanto, por ejemplo, "Una porción de X" puede incluir parte de "X" o todo "X". En el contexto de una conversación, el término "porción" significa parte o toda la conversación.
Como se usa en el presente documento, incluyendo en las reivindicaciones, la expresión "al menos algunos" significa "uno o más", e incluye el caso de únicamente uno. Por lo tanto, por ejemplo, la expresión "al menos algunos ABC" significa "uno o más ABC", e incluye el caso de únicamente un ABC.
Como se usa en el presente documento, incluyendo en las reivindicaciones, la expresión "basándose en" significa "basándose en parte en" o "basándose, al menos en parte, en", y no es exclusiva. Por lo tanto, por ejemplo, la expresión "basándose en el factor X" significa "basándose en parte en el factor X" o "basándose, al menos en parte, en el factor X". A no ser que se indique específicamente mediante el uso de la palabra "únicamente", la expresión "basándose en X" no significa "basándose únicamente en X".
Como se usa en el presente documento, incluyendo en las reivindicaciones, la expresión "usando" significa "usando al menos", y no es exclusiva. Por lo tanto, por ejemplo, la expresión "usando X" significa "usando al menos X". A no ser que se indique específicamente por el uso de la palabra "únicamente", la expresión "usando X" no significa "usando únicamente X".
En general, como se usa en el presente documento, incluyendo en las reivindicaciones, a no ser que la palabra "únicamente" se use específicamente en una expresión, no debería leerse en esa expresión.
Como se usa en el presente documento, incluyendo en las reivindicaciones, la expresión "distinto" significa "al menos parcialmente distinto". A no ser que se indique específicamente, distinto no significa totalmente distinto. Por lo tanto, por ejemplo, la expresión "X es distinta de Y" significa que "X es al menos parcialmente distinta de Y", y no significa que "X es totalmente distinta de Y". Por lo tanto, como se usa en el presente documento, incluyendo en las reivindicaciones, la expresión "X es distinta de Y" significa que X difiere de Y de al menos alguna forma.
Como se usa en el presente documento, incluyendo en las reivindicaciones, una lista puede incluir únicamente un artículo y, a no ser que se indique de otra manera, una lista de múltiples artículos no necesita estar ordenada de ninguna manera particular. Una lista puede incluir artículos duplicados. Por ejemplo, como se usa en el presente documento, la expresión "una lista de XYZ" puede incluir uno o más "XYZ".
Debería apreciarse que las palabras "primero", "segundo", "tercero" y similares, en la descripción y reivindicaciones, se usan para distinguir o identificar, y no para mostrar una limitación en serie o numérica. De manera similar, el uso de letras o etiquetas numéricas (tales como "(a)", "(b)", o "(i)", "(ii)" y similares) se usan para ayudar a distinguir y/o identificar, y no para mostrar ninguna limitación u orden en serie o numérico.
No se implica ningún orden por cualquiera de las cajas etiquetadas en cualquiera de los diagramas de flujo a no ser que se muestre e indique específicamente. Cuando se muestran cajas desconectadas en un diagrama, las actividades asociadas con esas cajas pueden realizarse en cualquier orden, incluyendo total o parcialmente en paralelo.
Mientras la invención se ha descrito en conexión con lo que se considera actualmente como los aspectos más prácticos, debe apreciarse que la invención se define mediante las reivindicaciones independientes adjuntas. Realizaciones preferidas de la invención se definen mediante las reivindicaciones dependientes adjuntas.

Claims (12)

REIVINDICACIONES
1. Un método implementado en ordenador, operable en un dispositivo de telecomunicaciones en un sistema que comprende uno o más servidores, en donde dicho dispositivo es un dispositivo de cliente en dicho sistema, comprendiendo dicho método:
proporcionar un estado de configuración de cliente para dicho dispositivo de cliente a dicho uno o más servidores, en donde el estado de configuración de cliente para el dispositivo de cliente incluye o se basa en información de identificación acerca del dispositivo de cliente o en información acerca de otros dispositivos con los que el cliente puede comunicarse en al menos una dirección, o ambas;
obtener de dicho uno o más servidores una primera configuración de subred, comprendiendo dicha primera configuración de subred al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente, estando dicha primera configuración de subred basada en dicho estado de configuración de cliente y en al menos otro estado de configuración de cliente de al menos otro dispositivo de cliente,
en donde dicha al menos una trayectoria comprende uno o más clientes intermedios, y
en donde el dispositivo de cliente usa la al menos una trayectoria especificada en dicha primera configuración de subred para obtener al menos un recurso a través de dicho uno o más servidores.
2. Un método implementado en ordenador, operable en un sistema que comprende uno o más servidores, comprendiendo dicho uno o más servidores software en conjunto con hardware, incluyendo dicho hardware al menos un procesador y una memoria, comprendiendo el método:
obtener un estado de configuración de cliente para un dispositivo de cliente, siendo dicho dispositivo de cliente un dispositivo de telecomunicaciones registrado en dicho sistema, en donde el estado de configuración de cliente para el dispositivo de cliente incluye o se basa en información de identificación acerca del dispositivo de cliente o en información acerca de otros dispositivos con los que el cliente puede comunicarse en al menos una dirección, o ambas;
basándose en dicho estado de configuración de cliente, determinar una primera configuración de subred para dicho cliente, comprendiendo dicha primera configuración de subred al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente; en donde dicha al menos una trayectoria comprende uno o más clientes intermedios; y
proporcionar dicha primera configuración de subred a dicho dispositivo de cliente.
3. El método de una cualquiera de las reivindicaciones 1 o 2, en donde dicha primera configuración de subred para dicho cliente se basa en configuraciones de cliente de múltiples otros dispositivos de cliente.
4. El método de una cualquiera de las reivindicaciones anteriores, en donde dicha al menos una trayectoria comprende una trayectoria híbrida.
5. El método de la reivindicación 4, en donde dicha trayectoria híbrida contiene segmentos de trayectoria usando interfaces de comunicación distintas.
6. El método de una cualquiera de las reivindicaciones anteriores, en donde dicha al menos una trayectoria comprende al menos una pasarela.
7. El método de una cualquiera de las reivindicaciones anteriores, en donde se seleccionó dicha al menos una trayectoria para favorecer uno o más de:
(a) un conjunto específico de portadoras;
(b) conexiones WiFi; y
(c) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente.
8. El método de una cualquiera de las reivindicaciones anteriores, en donde se seleccionó dicha al menos una trayectoria para favorecer uno o más de:
(d) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente;
(e) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación;
(f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; y (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente.
9. El método de una cualquiera de las reivindicaciones anteriores, en donde dicha al menos una trayectoria se selecciona para favorecer uno o más de:
(h) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente;
(i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; y
(j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente.
10. Un producto de programa informático que tiene instrucciones legibles por ordenador almacenadas en medios legibles por ordenador no transitorios, incluyendo las instrucciones legibles por ordenador instrucciones para implementar un método implementado por ordenador, comprendiendo dicho método operable en un dispositivo de telecomunicaciones inalámbrico en un sistema uno o más servidores,
comprendiendo el método: el método de una cualquiera de las reivindicaciones 1 a 9.
11. Un dispositivo de telecomunicaciones, operable en un sistema que comprende uno o más servidores, siendo dicho dispositivo un dispositivo de cliente en dicho sistema, dicho dispositivo construido y adaptado para:
proporcionar un estado de configuración de cliente para dicho dispositivo de cliente a dicho uno o más servidores, en donde el estado de configuración de cliente para el dispositivo de cliente incluye o se basa en información de identificación acerca del dispositivo de cliente o en información acerca de otros dispositivos con los que el cliente puede comunicarse en al menos una dirección, o ambas; y
obtener desde dicho uno o más servidores una primera configuración de subred, comprendiendo dicha primera configuración de subred al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente, estando dicha primera configuración de subred basada en dicho estado de configuración de cliente y en al menos otro estado de configuración de cliente de al menos otro dispositivo de cliente,
en donde dicha al menos una trayectoria comprende al menos una pasarela, y
en donde el dispositivo usa la al menos una trayectoria especificada en dicha primera configuración de subred para obtener al menos un recurso a través de dicho uno o más servidores.
12. El dispositivo de la reivindicación 11, en donde dicha al menos una trayectoria desde dicho uno o más servidores a dicho dispositivo de cliente se determinó basándose en uno o más factores, incluyendo:
(a) un conjunto específico de portadoras;
(b) conexiones WiFi;
(c) un estado de potencia de dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente;
(d) dispositivos de cliente en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente que se conectan a una fuente de alimentación;
(e) un coste de transmisión en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente;
(f) uso de espectro en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente; (g) agotamiento de batería esperada en clientes en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente;
(h) un número de saltos/retransmisiones en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente;
(i) fiabilidad esperada o tasa de errores o calidad de servicio para posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente;
(j) velocidad de transmisión esperada en posibles trayectorias desde dicho uno o más servidores a dicho dispositivo de cliente.
ES15814672T 2014-07-01 2015-06-29 Métodos, dispositivos y sistemas para implementar redes de auto organización inalámbricas híbridas centralizadas Active ES2913209T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462019545P 2014-07-01 2014-07-01
US201562185717P 2015-06-28 2015-06-28
PCT/US2015/038251 WO2016003868A1 (en) 2014-07-01 2015-06-29 Methods, devices, and systems for implementing centralized hybrid wireless self-organizing networks

Publications (1)

Publication Number Publication Date
ES2913209T3 true ES2913209T3 (es) 2022-06-01

Family

ID=55019866

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15814672T Active ES2913209T3 (es) 2014-07-01 2015-06-29 Métodos, dispositivos y sistemas para implementar redes de auto organización inalámbricas híbridas centralizadas

Country Status (4)

Country Link
EP (1) EP3164968B1 (es)
KR (1) KR20170029540A (es)
ES (1) ES2913209T3 (es)
WO (1) WO2016003868A1 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10142444B2 (en) 2014-07-01 2018-11-27 Trinity Mobile Networks, Inc. Methods, devices, and systems for implementing centralized hybrid wireless self-organizing networks
US10542476B2 (en) 2017-07-13 2020-01-21 Nokia Solutions And Networks Oy Selecting communication paths for application server queries of devices
EP3731369B1 (en) * 2019-04-24 2023-08-02 Hitachi Energy Switzerland AG Determining a network map defining a structure of a network
CN111478802B (zh) * 2020-03-30 2023-04-28 芯海科技（深圳）股份有限公司 配网处理方法、装置、系统、计算机设备和存储介质
CN113873678A (zh) * 2020-09-10 2021-12-31 华为技术有限公司 传输数据的方法和电子设备

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7844687B1 (en) * 1999-10-06 2010-11-30 Gelvin David C Method for internetworked hybrid wireless integrated network sensors (WINS)
US7941157B2 (en) * 2005-11-15 2011-05-10 Robert Bosch Gmbh Hybrid localization in wireless networks
US7966650B2 (en) * 2008-02-22 2011-06-21 Sophos Plc Dynamic internet address assignment based on user identity and policy compliance
US8223649B2 (en) * 2008-03-25 2012-07-17 Intel Corporation Method and apparatus for sending a packet from a source node to a destination node in the same broadcast domain
EP2710857B1 (en) * 2011-05-20 2021-07-07 Apple Inc. Apparatus and methods for client server interaction in hybrid network environments
GB2507161B (en) * 2012-08-19 2014-11-12 Box Inc Enhancement of upload and/or download performance based on client and/or server feedback information
US20150304411A1 (en) * 2012-09-20 2015-10-22 Telcordia Technologies, Inc. Self-Organizing Distributed Service Overlay for Wireless Ad Hoc Networks
US9113352B2 (en) * 2012-09-25 2015-08-18 Parallel Wireless, Inc. Heterogeneous self-organizing network for access and backhaul

Also Published As

Publication number Publication date
WO2016003868A1 (en) 2016-01-07
EP3164968B1 (en) 2022-02-16
EP3164968A1 (en) 2017-05-10
KR20170029540A (ko) 2017-03-15
EP3164968A4 (en) 2017-12-27

Similar Documents

Publication Publication Date Title
US10375213B2 (en) Centralized hybrid wireless self-organizing networks
US9432990B2 (en) Hybrid mesh network
US9686369B2 (en) System and method for multihop service discovery with member station proxy service advertisements
US7965671B2 (en) Dynamic channel sharing using bandwidth metrics
US8060017B2 (en) Methods and systems for a mobile, broadband, routable internet
ES2913209T3 (es) Métodos, dispositivos y sistemas para implementar redes de auto organización inalámbricas híbridas centralizadas
ES2564960T3 (es) Transmisión de información a través de una red de comunicaciones
US20090122753A1 (en) Dynamic data link segmentation and reassembly
TW200904211A (en) Backhaul network for femto base stations
JP2012253750A (ja) ＭｉＡＮ及びＭｉＡＮ帯域幅集約方法並びに集約システム
US11050671B2 (en) Mobile wireless communication unit and method for content transfer
Castignani et al. Urban 802.11 community networks for mobile users: Current deployments and prospectives
Alubady et al. Internet protocol MANET vs named data MANET: A critical evaluation
Braun et al. Multihop wireless networks
Veni et al. Mobile ad hoc network
US11785522B1 (en) Path selection between wireless mesh network devices
US20230261994A1 (en) System for Reducing Rerouting Time in MANET Using Virtual Buffer Zone Technique
Paul et al. Adaptive path selection for high throughput Heterogeneous Wireless Mesh Networks
Plymoth et al. Common opportunistic routing and forwarding
Biswash et al. A Device Centric Communication System for 5G Networks
Jin Open networking infrastructure: boosting wireless networks in the era of cloud
Abdalla Scalable Wireless Mesh Networks
Radunovic et al. On downlink capacity of cellular data networks with wlan/wpan relays
Nwup et al. Evaluation of the pre IEEE 802.11 s RFC
Nwup et al. Evaluation of the pre IEEE 802.11 s RFC: Aspects of the Design and Implementation of the Mesh Station with RA-OLSR in the C-Core