ES2381392T3 - Procedimiento de provisión a un terminal visitador de un acceso de emergencia sobre una WLAN - Google Patents
Procedimiento de provisión a un terminal visitador de un acceso de emergencia sobre una WLAN Download PDFInfo
- Publication number
- ES2381392T3 ES2381392T3 ES06360015T ES06360015T ES2381392T3 ES 2381392 T3 ES2381392 T3 ES 2381392T3 ES 06360015 T ES06360015 T ES 06360015T ES 06360015 T ES06360015 T ES 06360015T ES 2381392 T3 ES2381392 T3 ES 2381392T3
- Authority
- ES
- Spain
- Prior art keywords
- emergency
- terminal
- ssid
- data packets
- lan
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/20—Selecting an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/50—Connection management for emergency connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/73—Access point logical identity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/12—WLAN [Wireless Local Area Networks]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Emergency Management (AREA)
- Environmental & Geological Engineering (AREA)
- Public Health (AREA)
- Business, Economics & Management (AREA)
- Health & Medical Sciences (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Alarm Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Un procedimiento de provisión a un terminal (10) de un acceso de emergencia sobre una WLAN (2) a una LAN (3) que comprende uno o más puntos de acceso (20) y una función (21) de control de acceso la cual admite paquetes de datos procedentes de usuarios (70 a 73) de la WLAN (2) asociados con un primer SSID (7) hacia la LAN (3), comprendiendo el procedimiento las etapas de: la definición de uno o más SSIDs de emergencia (8) dedicados a hacer posible el acceso a una LAN (2) en un caso de emergencia; el inicio de una llamada de emergencia mediante el envío de paquetes de datos desde un terminal (10) asociados con un SSID (8) de emergencia seleccionado hacia uno de los uno o más puntos de acceso (20), por medio de lo cual los paquetes de datos son dirigidos por el terminal (10) hacia una dirección de destino recibida por el terminal (10) por medio de una respuesta de DHCP; la admisión, mediante la función (21) de control de acceso, de los paquetes de datos procedentes del terminal (10) asociados con el SSID (8) de emergencia seleccionado hacia la LAN (3); y el encaminamiento de los paquetes de datos asociados con el SSID (8) de emergencia seleccionada, después de la admisión en la LAN (3), hacia un punto (60) de contestación de emergencia, por medio de lo cual el procedimiento comprende las etapas adicionales de la solicitud por el terminal (10) de una opción concreta del DHCP que proveerá al terminal (10) de una dirección de IP de un gestor de llamadas (40) responsable para la gestión del establecimiento de una llamada de emergencia hacia el punto (60) de contestación de emergencia y un punto de conexión sobre el cual el gestor de llamadas (40) escucha; la recepción, por el terminal (10), de la dirección de IP del gestor de llamadas (40) y el punto de conexión sobre el cual el gestor de llamadas (40) escucha por medio del DHCP desde un servidor del DHCP; y el direccionamiento de los paquetes de datos hacia el terminal (10) asociados con la SSID (8) de emergencia seleccionada con la dirección de IP recibida del gestor de llamadas (40) y el punto de conexión sobre el cual el gestor de llamadas (40) está escuchando.
Description
Procedimiento de provisión a un terminal visitador de un acceso de emergencia sobre una WLAN
La presente invención se refiere a un procedimiento de provisión a un terminal de un acceso de emergencia sobre una LAN inalámbrica (= WLAN), y a un sistema de comunicación para ejecutar dicho procedimiento (LAN = Red de Area Local [Local Area Network].
Las WLANs se están convirtiendo en unas redes de acceso que cada vez encuentran más favorable acogida, tanto en áreas públicas, como por ejemplo hoteles, aeropuertos, estaciones ferroviarias, instalaciones para conferencias, así como en áreas comerciales, como por ejemplo edificios de empresas. Las empresas instalan las WLANs en sus locales para permitir la libertad de movimientos de su personal proporcionando al tiempo un ancho de banda relativamente alto en comparación con las redes inalámbricas heredadas, como por ejemplo el GSM (= Sistema Global de Comunicaciones Móviles) [Global System for Mobile Communication].
Otro avance producido en los últimos años ha sido el uso creciente de las redes de datos basados en IP para la transmisión de datos en tiempo real, como por ejemplo voz y vídeo (IP = Protocolo Internet) [Internet Protocol]. Se han introducido diversos estándares que manejan aplicaciones VoIP, como por ejemplo los estándar códec G.711 y G.719, y el protocolo de transmisión RTP (VoIP = Voz sobre IP; códec = codificación / descodificación; RTP = protocolo de transporte en tiempo real) [Real Time Transport Protocol]
Hasta hace poco, los abonados utilizaban únicamente, aplicaciones no en tiempo real, por ejemplo, para conectar su buscador a Internet. Sin embargo, las WLANs actuales se encuentran con el reto de manejar, así mismo, aplicaciones en tiempo real, por ejemplo, la VoWLAN (= Voz sobre WLAN). Después de todo, los abonados una solución VoWLAN esperan las mismas calidad de voz, fiabilidad y funcionalidad que con su teléfono heredado PSTN (= Red Telefónica General de Conmutación [Public Switched Telephone Network]) o su teléfono móvil del GSM.
El documento US 2006/0068799 A1, el cual se considera como la técnica anterior más próxima, describe un sistema de acceso inalámbrico de “anfitrión abierto” que incluye un punto de acceso (AP) inalámbrico que identifica el SSID a partir de una solicitud de conexión con la WLAN. Un proveedor de servicios inalámbricos (WSP) está asociado con el SSID. El AP está acoplado a un conmutador de demarcación situado dentro del sistema de acceso. El conmutador de demarcación incluye una serie de puntos de conexión, de forma que uno o más puntos de conexión están asociados con un WSP determinado. Un WSP puede conectar un equipamiento, como por ejemplo un encaminador, con su punto o puntos de conexión asociados. El AP abre una VLAN al punto o puntos de conexión designados para establecer conexiones con el equipamiento de los WSPS en base al SSID. El WSP proporciona unas asignaciones de dirección de IP y una autenticación como un proceso nativo sobre la red, de tal manera que la experiencia del usuario puede ser personalizada por cada WSP. Pantallas de inicio de sesión y procedimientos de autenticación exclusivos pueden ser empleados por cada WSP. El sistema de acceso inalámbrico no está relacionado con el establecimiento de una llamada de emergencia . En particular, este sistema no comprende el inicio de una llamada de emergencia mediante el envío de un paquete de datos desde un terminal asociado con un SSID de emergencia seleccionado hasta uno o más puntos de acceso, de forma que los paquetes de datos son dirigidos hacia el terminal hacia una dirección de destino recibida por el terminal por medio de una solicitud del DHCP.
El documento US 2004/0066756 A1 describe un procedimiento para un equipamiento de usuario (UE) residente en una red de acceso inalámbrico (WLAN) para acceder a al menos otra red. El procedimiento incluye el almacenamiento de la identificación (SSID) de al menos otra red (PLMNs) 1 - 3 visitadas y PLMNs 4 y 5 domésticas) dentro del equipamiento de usuario. La transmisión desde el equipamiento de usuario de una solicitud para la conexión con una de la al menos otra red; lo cual incluye una identificación de al menos una de al menos otra red, con la red de acceso inalámbrica; y en respuesta a la recepción por la red de acceso inalámbrica de la identificación, el equipamiento de usuario es conectado a la al menos otra red identificada a través de la red de acceso inalámbrica. Este procedimiento no está relacionado con el establecimiento de una llamada de emergencia .
El documento US 2005/0185626 A1 describe un procedimiento para asociar una WSTA a un conjunto de servicios, en el que el conjunto de servicios es configurable en el AP. Cada conjunto de servicios es un agrupamiento arbitrario de uno o más parámetros de servicios de red, y está típicamente configurado para ya sea una LAN o bien para un anfitrión de IP de anfitrión de IP de móvil operado. Cuando una estación inalámbrica desea asociarse con un punto de acceso, el mensaje contiene el SSIP, el punto de acceso, entonces, sitúa en correspondencia el SSID con un conjunto de servicios y asocia la WSTA ya sea o bien con una subred doméstica o con una VLAN en base al SSID. Mediante la configuración local del conjunto de servicios, la VLAN por defecto y el subconjunto doméstico para una WSTA pueden ser diferentes en cada AP que la WSTA encuentra. Un servidor de seguridad está configurado con una lista de SSIDs autorizados para cada estación inalámbrica para impedir un acceso no autorizado a una VLAN o a una subred doméstica.
El documento US 2004/0181692 A1 describe un sistema de comunicación de una red de área local inalámbrica (WLAN) que incluye un punto de acceso en comunicación con una estación móvil y al menos un servidor de Autenticación, Autorización y Contabilización (AAA) proporciona un procedimiento de autenticación por medio del cual un usuario de la estación móvil puede seleccionar un proveedor de servicios de la WLAN entre uno o más proveedores de servicios de la WLAN y / o uno o más proveedores de servicios de 3GPP antes de ser autenticados y, así mismo, para adoptar una decisión para abonarse a los servicios del proveedor de servicios seleccionados en base a la información de los servicios de la red, distintos de o además de un Identificador de Red Inalámbrica (SSID), asociado con el proveedor de servicios seleccionados. El sistema no utiliza el DHCP.
Stefano M. Faccin: “Propuesta WiNOT TGu para el Requisito de los Servicios de Emergencia” [“WiNOT TGu Proposal for Emergency Services Requirement “] IEEE 802.11 – 06/0288R1, 6 de marzo de 2006 (). páginas 1 a 9, XP0024118839 IEEE P802.11 LANs Inalámbricas especifica una propuesta para hacer frente al requisito de los servicios de emergencia en los requisitos de agrupamiento genéricos para el estándar IEEE 802.11
u.
Hepworth et al.: “Propuesta Tgu para el soporte E911” [“Tgu Proposal for E911 support”], IEEE 802.11 – 06/280R0, 17 de febrero de 2006 () páginas 1 a 12, XP002418840 IEEE P Nos. 802.11 LANs Inalámbricas propone, como en una red celular, que un usuario puede hacer uso del servicio de llamadas de emergencia ya sea utilizando las credenciales existentes, ya sea utilizando un mecanismo de acceso autenticado. Uno de los problemas relacionados con la seguridad es que el usuario autenticado no debe ser capaz de interferir con el tráfico difundido de los demás usuarios, pero necesita contar con un soporte de difusión (para el DHCP, el ARP, etc.). La solución a ello es que el servicio de emergencia necesita ser suministrado sobre un AP virtual separado. Esto significa que el tráfico de difusión de los usuarios de emergencia está separado de los usuarios normales ( y el usuario autenticado no necesita su clave de grupo). En concreto, la solución debe asegurar que los usuarios de emergencia no autenticados no puedan interferir con el tráfico difundido (como por ejemplo el DHCP, el ARP) de los demás usuarios autenticados. No se describe el uso de un “SSID de emergencia”.
Stephenson, Dave: “Solicitud de Ancho de Banda Acelerada” [“Expedited Bandwidth Request”] IEEE 802.11 – 06/0268RO, 17 de febrero de 2006 () páginas 1 a 21, XP002418841 IEEE 802.11 describe lo que puede considerarse como una propuesta completa para el requisito R911. Esta propuesta se divide en dos partes. Parte 1: la señalización desde una QSTA a un QAP para identificar la información adicional acerca de la naturaleza de la solicitud de ancho de banda (incluyendo si es una llamada de emergencia). Parte 2: la propuesta para suministrar un servicio 911 a clientes que presenten únicamente credenciales de seguridad públicas.
Hepworth, Montemurro, Rudolf: “Propuesta para el Soporte de Servicios de Emergencia” [“Proposal for Emergency Service Support”] IEEE 802.11 – 06/0450RO, 6 de marzo de 2006 (), páginas 1 a 13, XP002418842 IEEE
802.11 da respuesta al requisito R911 define la funcionalidad del IEEE802.11 que se requeriría para soportar y un servicio de Llamadas de Emergencia como parte de una solución multinivel global.
El documento US 2005/0181805 A1 describe un procedimiento y un sistema para la localización de un abonado de acceso móvil sin licencia (UMA). El procedimiento permite que sea localizado un usuario de una estación móvil que comprende un aparato telefónico o dispositivo similar que soporta un acceso de voz y datos por medio tanto de unos espectros de voz con licencia como sin licencia. De acuerdo con ello, se puede acceder a servicios que requieren una información de localización, como por ejemplo servicios 911 al operar la estación móvil con arreglo a sesiones tanto UMA como de redes inalámbricas con licencia (por ejemplo celulares).
El documento US 2005/0190892 A1 describe que, con el fin de que los vehículos de servicios de emergencia puedan ser despachados al destino correcto de forma inmediata, se necesita una información precisa acerca del emplazamiento del llamante. Otro problema se refiere a las llamadas de emergencia de encaminamiento al destino correcto. Para las llamadas de emergencia se utiliza un código universal, como por ejemplo el 911 en Norteamérica y el 112 en Europa. Este código universal no puede ser utilizado para identificar el destino de la llamada. Estos problemas son particularmente acuciantes en sistemas de comunicaciones erráticos, como por ejemplo respecto de redes de comunicaciones de protocolos de voz sobre Internet. Esto se debe a que los terminales de los usuarios cambian el emplazamiento de la red. Estos problemas se resuelven haciendo posible que el emplazamiento geográfico del llamante de emergencia sea determinado por entidades situadas dentro de una red a base de paquetes sin necesidad de modificar la infraestructura existente de la red de servicios de emergencia.
El documento US 6 714 536 B1 describe unos procedimientos y unos aparatos para hacer posible el establecimiento de una conexión de paquetes de datos mediante el envío de una indicación de una dirección de red a través de una vía telefónica. En una primera forma de realización, una pila de protocolos inicia el establecimiento de una conexión con Internet mediante el envío de un segmento de datos a través de una vía telefónica de una red telefónica general de conmutación (PSTN) y, a continuación, opera y mantiene la conexión con Internet en una conexión de paquetes separada. Los dígitos de marcación son utilizados para indicar la dirección de una computadora remota o de un dispositivo inalámbrico a través de la vía telefónica. La presente invención permite, así mismo, llamadas telefónicas multimedia mezcladas PSTN / Internet. En una forma de realización ejemplar, cuando se establece una conexión telefónica de PSTN punto a punto, automáticamente aparece una pantalla de información en uno o ambos extremos de la conexión vía Internet.
Constituye el objetivo de la presente invención garantizar a un terminal visitador el acceso a los servicios de comunicación para fines de emergencia.
El objetivo de la presente invención se obtiene mediante un procedimiento de provisión a un terminal de un acceso de emergencia sobre una WLAN a una LAN que comprenda uno o más puntos de acceso y una función de control de acceso la cual admite paquetes de datos procedentes de usuarios de la WLAN asociados con un primer SSID a la LAN, en el que el procedimiento comprende las etapas de: la definición de uno o más SSIDs de emergencia dedicados a posibilitar el acceso a la LAN en un caso de emergencia; el inicio de una llamada de emergencia mediante el envío de un paquete de datos a un terminal asociado con un SSID de emergencia seleccionado a uno de los uno o más puntos de acceso de forma que los paquetes de datos son dirigidos por el terminal hacia una dirección de destino recibida por el terminal por medio de una respuesta del DHCP; la admisión, por medio de la función de control de acceso, de los paquetes de datos desde el terminal asociado con el SSID de emergencia seleccionado hacia la LAN; y el encaminamiento de los paquetes de datos asociados con el SSID de emergencia seleccionado, después de la admisión en la LAN, hacia un punto de respuesta de emergencia, en el que el procedimiento comprende las etapas adicionales de: la solicitud por el terminal de una opción de DHCP particular que provea al terminal de una dirección de IP de un gestor de llamadas responsable de la gestión del establecimiento de una llamada de emergencia hacia el punto de respuesta de emergencia y un punto de conexión sobre el cual el gestor de llamadas está escuchando; la recepción, por el terminal, de la dirección de IP del gestor de llamadas y del punto de conexión sobre el cual el gestor de llamadas está escuchando por medio del DHCP desde un servidor del DHCP; y el direccionamiento de los paquetes de datos al terminal asociado con el SSID de emergencia seleccionado con la dirección de IP recibida del gestor de llamadas y el punto de conexión sobre el cual está escuchando el gestor de llamadas (SSID = Identificador de Red Inalámbrica [Service Set Identifier]).
La asociación de un terminal con un SSID significa que el terminal notifica dentro de la comunicación sobre la interfaz aérea de la WLAN dicho SSID. De modo preferente, el SSID es notificado dentro de la parte del nivel de MAC de la comunicación sobre la interfaz aérea. Eso significa que el terminal señaliza, durante la comunicación sobre la interfaz aérea un SSID al punto de acceso, el SSID que está asociado con el terminal.
De acuerdo con la presente invención, los paquetes de datos desde el terminal asociado con el SSID de emergencia seleccionado son encaminados, después de la admisión en la LAN, hacia un punto de respuesta de emergencia.
La presente invención ofrece un procedimiento sencillo de la forma de proveer a un terminal – tanto a un terminal visitador como a un terminal autorizado – de un acceso fiable y seguro sobre una WLAN a una LAN en el caso de una emergencia.
Un usuario de un terminal móvil no está limitado a las LANs públicamente accesibles para establecer una llamada de emergencia sino que puede, así mismo, utilizar LANs corporativas o comerciales, por ejemplo una red corporativa universitaria. De esta manera, incluso un terminal visitador, el cual normalmente no estaría autorizado a acceder a una red con derechos de acceso restringidos, puede establecer una llamada de emergencia a través de la red.
Así mismo, la presente invención contribuye de manera significativa a la aceptación futura de la técnica VoWLAN, dado que la presente invención provee a una WLAN de unos medios para ofrecer conectividad y fiabilidad en el caso de una emergencia. En los EE..UU., la Comisión Federal de Comunicaciones (= FCC) requiere que los proveedores de los servicios VoIP aseguren que todas las llamadas VoIP interconectadas proporcionan una total capacidad respecto del número 9 – 1 – 1, siendo el 9 – 1 – 1 el número de emergencia oficial nacional en los EE.UU. y Canadá. Similares requisitos se contemplan en muchos países europeos en los que el número de emergencia nacional oficial es el 1 – 1 – 2, por ejemplo. Por medio de la presente invención, cualquier llamante que marca el número de emergencia central 9 – 1 – 1 y / o 1 – 1 - 2 puede estar seguro de ser transferido de manera fiable hacia un PSAP (= Punto Contestador de Seguridad Pública [Public Safety Answering Point]) desde el cual se organizará la ayuda.
Para el encaminamiento de paquetes de datos relacionados con la llamada de emergencia, existen disponibles diversos procedimientos. Por consiguiente, un procedimiento adecuado puede ser elegido dependiendo de la situación efectiva y de las circunstancias, como por ejemplo la infraestructura, la carga de tráfico, etc., disponibles.
Otras ventajas se obtienen mediante las formas de realización de la invención indicadas por las reivindicaciones dependientes.
De acuerdo con la invención, el terminal que desea iniciar una llamada de emergencia, recibe, por medio de una indagación del DHCP, una dirección de destino a la que enviar los paquetes de datos correspondientes (DHCP = Protocolo de Configuración Dinámica de Servidores [Dynamic Host Configuration Protocol]). Por consiguiente, el terminal dirige los paquetes de datos desde el terminal asociado con el SSID de emergencia seleccionado con la dirección de destino recibida a través de la solicitud del DHCP.
El concepto DHCP puede ser realizado por medio de un servidor del DHCP el cual es, de modo preferente, implementado como un duende y espera en el punto de conexión 67 del UDP las solicitudes de clientes (UDP = Protocolo de Datagramas de Usuario [User Datagram Protocol]). Un archivo de configuración del servidor del DHCP comprende la información acerca de la batería de direcciones que van a ser distribuidas así como los datos adicionales acerca de los parámetros relevantes de la red. Por consiguiente, un terminal con emplazamientos a menudo cambiantes puede prescindir de una preconfiguración de propensión al error. El terminal simplemente establece una conexión con la WLAN y solicita todos los parámetros relevantes del servidor del DHCP.
A continuación, los paquetes de datos procedentes del terminal asociado con el SSID de emergencia seleccionado son enviados por el terminal a la dirección de IP y al punto de conexión de un gestor de llamadas el cual encaminará los paquetes de datos relacionados con la llamada de emergencia hacia un PSAP. El terminal recibe la dirección relacionada con los datos del gestor de llamadas procedentes del servidor del DHCP.
El terminal solicita una opción particular del DHCP que provea al terminal de la dirección de destino, esto es, una dirección de IP del gestor de llamadas. El terminal puede enviar un mensaje asociado con el procedimiento del DHCP a un servidor del DHCP para solicitar una dirección de destino a la que enviar los paquetes de datos de la llamada de emergencia. Después de la recepción de la dirección de destino procedente del servidor del DHCP, el terminal asociado con el SSID de emergencia seleccionado establece la dirección de IP recibida como dirección de destino de los paquetes de datos desde el terminal asociado con el SSID de emergencia seleccionado. La dirección de destino comprende la dirección de IP del gestor de llamadas y un punto de conexión sobre el que está escuchando el gestor de llamadas.
En otra forma de realización preferente, la señalización de las llamadas de acuerdo con la presente invención está en conformidad con todo tipo de clientes de gestión de llamadas, como el SIP, el H.323, etc. (SIP = Protocolo de Inicio de Sesión [Session Initiation Protocol]). El procedimiento actual es totalmente un protocolo agnóstico. El terminal solo tiene que enviar paquetes de RTP al gestor de llamadas. No hay ningún códec ni ninguna negociación de entramado.
De acuerdo con una forma de realización preferente de la invención, los paquetes de datos desde un terminal asociado con un SSID de emergencia son encaminados, una vez que han sido admitidos en una red LAN, hacia un servicio de emergencia o hacia un punto de respuesta de emergencia, por ejemplo un PSAP. De modo preferente, el encaminamiento es ejecutado por una PBX o por el gestor de llamadas. Una vez que el gestor de llamadas recibe una llamada de emergencia, el gestor de llamadas establece una llamada relativa al área geográfica de la llamada original. Todos los paquetes de datos asociados con el terminal asociado por SSID de emergencia que entran en la LAN son encaminados hacia el servicio de emergencia del punto de llamada de emergencia, de modo preferente, con carácter independiente con respecto de la dirección de destino originalmente indicada de los paquetes de datos. Los paquetes de datos procedentes de un terminal asociado con un SSID de emergencia tienen acceso garantizado a la LAN solo a los fines de establecer una llamada de emergencia.
En línea con la invención dicha LAN puede ser una LAN accesible por medio de dos o más WLANs. Cada una de las WLANs pueden servir como una red de acceso al entorno LAN y estar asociada con un SSID separado. Entonces, la LAN puede ser accesible a través de una primera WLAN por medio de un primer SSID, por ejemplo un SSID normal, y accesible a través de una segunda WLAN por medio de un segundo SSID, por ejemplo un SSID de emergencia.
De forma correspondiente, la invención presenta, así mismo, un procedimiento para proporcionar acceso a una LAN accesible por medio de al menos dos WLANs, para una pluralidad de terminales de usuario que comprenda terminales de usuarios autorizados, por ejemplo, usuarios pertenecientes a una corporación, así como terminales de usuarios visitadores. Dicha primera WLAN proporciona acceso a la LAN para paquetes de datos asociados con un primer SSID. Los paquetes de la primera WLAN son filtrados utilizando un procedimiento de encriptación para permitir solo paquetes de datos adecuadamente encriptados desde terminales de usuarios autorizados hacia la LAN y descartar paquetes de datos procedentes de otros terminales. Así mismo, al menos una segunda WLAN proporciona acceso a la LAN para paquetes de datos procedentes de terminales de todos los usuarios y asociados con un segundo SSID. Los paquetes de datos procedentes de la segunda WLAN son filtrados para permitir solo paquetes de datos que incorporen llamadas de emergencia de VoID.
Dado que los clientes asociados con un SSID de emergencia pueden ser usuarios visitadores, no puede establecerse la encriptación o la autenticación. Para impedir ataques a o un uso no autorizado del SSID de emergencia, pueden establecerse diversos medios de seguridad.
Una información importante con la que contar en un servicio de emergencia es la localización de un usuario que inicia una llamada de emergencia. Con la ayuda de un rastreador del DHCP y con el uso de los servicios web albergados en un servidor de localización, esta información puede ser transmitida al PSAP.
En una forma de realización preferente, se definen los SSIDs de emergencia específicos para llamadas de emergencia, junto con capacidades específicas, como por ejemplo códec. Cada uno de los SSIDs de emergencia definidos está asociado con diferentes capacidades, por ejemplo un códec diferente. Por tanto, pueden ser configurados diversos SSIDs de emergencia dependiendo de los parámetros que serán utilizados para la llamada, por ejemplo, un SSID de emergencia para el G.711 y otro SSID de emergencia para el G.729. El usuario del terminal
o la inteligencia del terminal puede seleccionar un SSID de emergencia dependiendo de las capacidades asociadas. La información acerca de las capacidades asociadas con un SSID de emergencia específico puede ser extraída de la difusión de un SSID de emergencia. La información acerca de las capacidades puede estar contenida en el propio SSID o puede ser recuperada de un elemento de información separado de la LAN. El gestor de llamadas recibe la información acerca del procesamiento de los paquetes de datos en la cabecera del RTP.
De modo preferente, una llamada de emergencia se inicia mediante el envío de paquetes de datos asociados con una llamada telefónica de VoWLAN. La VoWLAN permite VoIP en un entorno móvil. Se basa en unas WLANs basadas en el estándar 802.11 del IEEE, en la mayoría de los casos dentro de edificios. La VoWLAN comprende la integración de sistemas tales como el VoIP en base a los protocolos de señalización de llamadas, como por ejemplo el SIP o el H.323, y la WLAN de acuerdo con el estándar 802.11 del IEEE en la versión de 802.11e el cual soporta la Calidad de Servicio (= QoS). Así mismo, una conexión directa con las redes del UMTS es posible y, por tanto, la expansión de los servicios VoWLAN fuera del alcance de las LANs basadas en radio.
De acuerdo con otra forma de realización preferente de la invención, el terminal usa un procedimiento estándar 802.11e o WMM para indicar que el flujo de datos relacionado con la llamada de emergencia tiene una prioridad de emergencia de voz (WMM = WiFi Multi Media; WiFi = Fidelidad Inalámbrica [Wirless Fidelity]). El control de admisión de las llamadas a una red es negociado por el uso de la TSPEC (= Especificación de Tráfico [Traffic Specification}). Una estación, en este caso el terminal, especifica sus requisitos de flujo de tráfico (tasa de transmisión de datos, límites de retardo, tamaño de los paquetes, y otros) y solicita un QAP (= Punto de Acceso a QoS [QoS Access Point]) para crear una TPSC mediante el envío de la trama de acción de gestión de la ADDTS ( = TSPEC adicionales [ADD TSPEC]). El QAP calcula la carga existente en base al conjunto actual de TSPECs emitidos. En base a las condiciones actuales, el QAP puede aceptar o denegar la nueva solicitud de TSPEC. Si la TSPEC es denegada, no se permite la categoría de acceso de alta prioridad dentro de la Estación de QoS (= QSTA) para utilizar los parámetros de acceso de esta prioridad, pero en su lugar debe utilizar los parámetros de nivel de QoS.
Así mismo, puede ser utilizado el desalojo para favorecer una llamada de emergencia. Cuando un usuario del terminal marca un número prioritario, como por ejemplo un número de emergencia, la parte que llama puede esperar que la WLAN procese la llamada urgente con una prioridad más elevada que una conversación normal de un abonado. El AP y / o el gestor de llamadas reconoce el estado de prioridad de la llamada de emergencia y desaloja los recursos asignados de llamadas de prioridad menor que la llamada de emergencia a favor de la llamada de emergencia. En general, los mecanismos de desalojo y de TSPEC pueden ser utilizados para garantizar una QoS específica a los paquetes de datos asociados con una llamada de emergencia.
De modo preferente, el terminal comprende una unidad de representación como por ejemplo, una pantalla, donde un símbolo específico, por ejemplo las letras “SOS” o un icono que represente una luz de una patrulla de policía, puede mostrarse sobre una pantalla blanda (Sfotscreen) o sobre un tablero de móvil, cuando el terminal detecta que está disponible un SSID de emergencia. Como alternativa, una señal acústica, como por ejemplo un tintineo o un sonido específico, es reproducido desde un altavoz del terminal en el caso de que se encuentre disponible un SSID de emergencia. Un archivo de datos que comprenda iconos o el sonido específicos puede estar almacenado en una memoria del terminal y puede ser recuperado de la memoria y generado de salida en el terminal para informar a un usuario del terminal de que se encuentra disponible un acceso de emergencia a la WLAN.
De acuerdo con otra forma de realización de la invención, al menos uno de los uno o más puntos de acceso difunden los uno o más SSIDs. El terminal detecta al menos uno de los uno o más SSIDs de emergencia difundidos y selecciona un SSID de emergencia entre el al menos un SSID de emergencia detectado.
El objetivo de la presente invención se consigue, así mismo, mediante un sistema de comunicación para proveer a un terminal de un acceso de emergencia sobre una WLAN a una LAN, comprendiendo el sistema de comunicación una función de control de acceso la cual admite paquetes de datos procedentes de usuarios de la WLAN asociados con el primer SSID en la LAN, en el que el sistema de comunicación comprende una interfaz adaptada para recibir paquetes de datos procedentes de un terminal apropiado con un SSID de emergencia seleccionado entre el al menos un SSID de emergencia detectado, una unidad de control adaptada para reenviar los paquetes de datos recibidos desde el terminal asociado con el SSID de emergencia seleccionado hacia la función de control de acceso, de forma que la función de control de acceso permite los paquetes de datos procedentes del terminal asociado con el SSID de emergencia seleccionado hacia la LAN, y en el que el sistema de comunicación está adaptado para encaminar los paquetes de datos desde el terminal asociado con el SSID de emergencia seleccionado, después de la admisión en la LAN, hacia un punto contestador de emergencia de forma que dichos paquetes transportan una dirección de destino recibida en el terminal procedente del sistema de comunicación por medio de una respuesta del DHCP, y de forma que el sistema de comunicación comprende así mismo un gestor de llamadas responsable de la gestión del establecimiento de una llamada de emergencia hacia el punto contestador de emergencia y un servidor del DHCP adaptado para proveer, en respuesta a una solicitud del terminal respecto de una opción correspondiente concreta del DHCP, al terminal de una dirección IP del gestor de llamadas y un punto de conexión sobre el cual está escuchando el gestor de llamados por medio del DHCP para direccionar los paquetes de datos al terminal asociado con el SSID de emergencia seleccionado con la dirección IP recibida del gestor de llamadas y el punto de conexión sobre el cual está escuchando el gestor de llamadas.
El sistema de comunicación está adaptado para encaminar los paquetes de datos procedentes de un terminal asociado con el SSID de emergencia seleccionado cuando los paquetes de datos han sido dirigidos al terminal con una dirección de destino recibida en el terminal por medio de una solicitud del DHCP.
De modo preferente, el sistema de comunicación comprende así mismo un emisor adaptado para difundir uno o más SSIDs de emergencia dedicados para posibilitar el acceso a la LAN en un caso de emergencia hacia el terminal.
Las referidas, así como otras características distintivas y ventajas de la invención se apreciarán en mayor medida mediante la lectura de la descripción detallada subsecuente tomada en combinación con los dibujos que se acompañan, en los cuales:
La Figura 1 es un diagrama de bloques de un terminal que accede a una LAN de acuerdo con una forma de realización de la invención.
La Figura 2 es una secuencia de flujo de mensajes que muestra un terminal que accede a una LAN de acuerdo con una forma de realización de la invención.
Las Figuras 3a a c son secuencias de flujo de mensajes que muestran opciones de encaminamiento.
La Figura 4 es un diagrama de bloques de terminales que acceden a una LAN de acuerdo con otra forma de realización de la invención.
La Figura 5 es otro diagrama de bloques de terminales que acceden a una LAN de acuerdo con otra forma de realización más de la invención.
Las Figuras 6a a d son secuencias de flujo de mensajes que muestran opciones relacionadas con la localización.
La Figura 1 muestra un sistema de comunicación 1 que comprende una WLAN 2, una LAN 3, una red 5, un gestor de llamadas 40, y un PSAP 60. Un usuario 100 de un terminal 10 quiere conectarse por medio de una llamada de emergencia con un PSAP 60. El terminal 10 está situado dentro del área de cobertura de un punto de acceso 20 el cual pertenece a la LAN 3. La LAN 3 comprende así mismo una función 21 de control de acceso, un servidor 30 del DHCP, un servidor de localización 31, y un gestor de llamadas 40. La Red 5 conecta con el gestor de llamadas 40 y con el PSAP 60. La segunda red 5 puede ser una red telefónica ordinaria, como por ejemplo una red PSTN.
El terminal 10 puede ser un dispositivo móvil para establecer una llamada de telecomunicación por medio de una red de acceso. Puede ser, por ejemplo, un teléfono móvil o una computadora portátil que comprenda un cliente de VoIP con una interfaz de WLAN. El terminal 10 comprende una unidad de detección 101, una unidad de control 102 y una interfaz de usuario 103. La interfaz de usuario 103 comprende unos medios para posibilitar que el usuario 100 provea al terminal 10 de una entrada y para recibir la salida procedente del terminal 10. De modo preferente, la interfaz de usuario 103 comprende un teclado con unas teclas de entrada, un micrófono, una pantalla y un altavoz.
El punto de acceso 20 de la LAN 3 es un dispositivo hardware o un software informático que actúa como un concentrador de comunicaciones para que el terminal 10 conecte con la WLAN 2. El AP 20 comprende un remitente 201, un modulo de interfaz 202 con una interfaz con la WLAN 2 y una interfaz con la LAN 3, y una unidad de control
203. La interfaz con la WLAN 2 es capaz de enviar y recibir, esto es intercambiar, datos con los terminales de la WLAN, la interfaz con la LAN 3 es capaz de enviar y recibir, esto es, intercambiar, datos con los elementos de red de la LAN 3.
El remitente 201 difunde uno o más SSIDs de emergencia dedicados para permitir el acceso a la LAN 3 en un caso de emergencia. La interfaz 202 recibe los paquetes de datos enviados por el terminal 10 a través de la interfaz aérea con la LAN 3. La unidad de control 203 proporciona una función de control e inteligencia con el punto de acceso 20.
La WLAN 2 puede estar representada por los terminales situados dentro del área de cobertura del remitente, la interfaz con la WLAN 2, y el medio que acarrea el intercambio de datos entre los terminales y la interfaz con la WLAN 2, esto es la interfaz aérea.
Un SSID identifica una red de radio en base al estándar 802.11 del IEEE. El SSID, conocido también como nombre de red porque esencialmente es un nombre que identifica una red, es una cadena sensible a un supuesto unívoco de hasta 32 caracteres alfanuméricos. Todos los dispositivos inalámbricos de una WLAN deben emplear el mismo SSID con el fin de comunicarse entre sí. El SSID está configurado en un AP de una WLAN y se establece por todos los clientes que desean acceder a la WLAN a través del AP. El SSID sobre los clientes inalámbricos puede establecerse ya sea de forma manual, introduciendo el SSID en las configuraciones de red del cliente o bien de manera automática, dejando el SSID sin especificar o en blanco.
La función 21 de control de acceso, proporciona un acceso a la LAN 3. La función 21 de control de acceso puede llevarse a cabo como un controlador de la WLAN, de modo preferente como un dispositivo autónomo, o puede ser integrado en la funcionalidad dispuesta por el AP 20 y / o por el dispositivo AP. La funcion 21 de control de acceso comprende una unidad de control 204 para el control de la función 21 de control de acceso y la aplicación, a los paquetes de datos que llegan a los bordes de la WLAN 2, las normas de control de acceso almacenadas en un módulo de memoria 205. La función 21 de control de acceso filtra los paquetes de datos que llegan antes de admitirlos a las redes 2 y 3.
La WLAN 2 está conectada al servidor 30 del DHCP, al servidor 31 de localización, y al gestor de llamadas 40 por medio de la red 3, la cual es una red de IP, por ejemplo una LAN o Internet por medio de una función de retransmisión del DHCP. El servidor 30 del DHCP asigna direcciones de IP dinámicas a los dispositivos que acceden a la LAN. Con un direccionamiento dinámico, un dispositivo puede tener una dirección de IP diferente cada vez que se conecta a una red. En algunos sistemas la dirección de IP de un dispositivo puede incluso cambiar mientras sigue estando conectada. El DHCP soporta, así mismo, una mezcla de direcciones IP estáticas y dinámicas.
El servidor 35 de localización alberga servicios, de modo preferente servicios web, para localizar la disposición del terminal 10. Esto puede conseguirse extrayendo información de los datos recibidos del terminal 10. Toda la información adaptada para proporcionar todos los datos del terminal 10 se resumen mediante el término “información de localización”. La información de localización puede ser útil para localizar el terminal 10.
El gestor de llamadas 40 es responsable para gestionar un establecimiento de llamadas de emergencia mediante el PASP 60. El gestor de llamadas 40 está compuesto por una o varias computadoras entrelazadas, esto es, una plataforma hardware, una plataforma software basada en la plataforma hardware y varios programas de aplicación ejecutados por la plataforma del sistema formados por la plataforma software y hardware. Las funcionalidades del gestor de llamadas 40 se suministran mediante la ejecución de estos programas de aplicación. Los programas de aplicación o una parte seleccionada de estos programas de aplicación constituyen un producto de software informático que proporciona un servicio de gestor de llamadas tal y como se describe a continuación, cuando es ejecutado en la plataforma del sistema. Así mismo, dicho producto de software informático está constituido por un medio de almacenamiento que almacena estos programas de aplicación o dicha parte seleccionada de los programas de aplicación.
La Figura 2 muestra una secuencia de mensajes entre el terminal 10, el punto de acceso 20 de la LAN 2, el servidor 30 del DHCP, el gestor de llamadas 40 y el PSAP 60 de acuerdo con una primera forma de realización de la invencion. En una primera etapa 901, dos SSIDs de emergencia dedicados a un servicio de emergencia son difundidos por el AP 20 de una forma en la que el terminal 10 pueda detectar los SSIDs de emergencia por medio de una unidad de detección. Después de la detección de los SSIDs de emergencia difundidos por el terminal 10, un modelo de icono es representado sobre una unidad de representación del terminal en acción 902 para informar a un usuario del terminal 10 que el servicio de emergencia está disponible en la actual localización. Como alternativa, el usuario puede ser informado acerca de la disponibilidad del servicio de emergencia por medio del mecanismo de información.
Para solicitar el servicio de emergencia indicado, el usuario del terminal 10 puede, en la etapa 903, marcar, en un teclado del terminal 10, un número de servicio de emergencia asociado con un servicio de emergencia, por ejemplo el número 9-1-1 en Norteamérica o el número 1-1-2 en Europa, o presionar una tecla programable dedicada al servicio de emergencia dispuesto sobre el terminal 10. La tecla programable es una tecla situada por debajo del panel de representación final del terminal que lleva a cabo funciones especiales.
Desencadenado por la acción 903, el terminal 10 selecciona un SSID de emergencia entre el conjunto de SSIDs de emergencia detectados. Como alternativa, el usuario del terminal es inducido a elegir un SSID de emergencia de acuerdo con sus preferencias y a indicar su elección introduciéndola por medio de una tecla. De la manera correspondiente, el terminal 10 se asocia con el SSID de emergencia seleccionado en la etapa 904. El códec utilizado para la llamada de emergencia puede ser el G.711, de acuerdo con el SSID de emergencia seleccionado. Si el terminal 10 estuvo originariamente asociado con otro SSID, el terminal 10 debe desasociarse del antiguo SSID y asociarse con el SSID de emergencia. En la etapa siguiente 905, el terminal 10 envía un mensaje DHCP DISCOVER, al servidor 30 del DHCP.
El servidor 30 del DHCP contesta a la solicitud del DHCP con un mensaje 906, por ejemplo un mensaje DHCP OFFER, enviado al terminal 10 en el que el mensaje 906 comprende una dirección de IP y un punto de conexión del gestor de llamadas 40 y una dirección de IP del terminal 10. El terminal puede escoger la oferta, enviar otra solicitud al servidor del DHCP y recibir un mensaje de confirmación. De esta manera, el terminal 10 es habilitado para enviar un flujo 907 de RTP que comprenda paquetes de datos en el estándar códec G.711 al destino especificado, esto es, el gestor de llamadas 40. Dado que los paquetes de datos enviados del flujo 907 de RTP están asociados con el SSID de emergencia seleccionado, la función 21 de control de acceso los deja pasar.
Todos los paquetes de datos que entran en la LAN 3 a través del AP 20 deben pasar la función 21 de control de acceso la cual puede ser implementada como un servidor de control de acceso autónomo dedicado. El servidor de control de acceso puede estar compuesto por una o varias computadoras entrelazadas, esto es, una plataforma hardware, una plataforma software en base a la plataforma hardware y varios programas de aplicación ejecutados por la plataforma del sistema formados por la plataforma software y hardware. La función 21 de control de acceso es suministrada por la ejecución de estos programas de aplicación. Los programas de aplicación o una parte asociada con estos programas de aplicación constituyen un producto de software informático que proporciona un servicio de control de acceso de acuerdo con lo descrito más adelante, cuando son ejecutados en la plataforma del sistema. Así mismo, dicho producto de software informático está constituido por un medio de almacenamiento que almacena dichos programas de aplicación o una parte seleccionada de dichos programas de aplicación.
Así mismo, es posible que la función 21 de control de acceso sea implementada en un elemento de red de la LAN 3 como una tarea adicional, por ejemplo, en un conmutador, centralita o encaminador de la LAN 3. Así mismo, es posible que la función 21 de control de acceso esté incluida dentro del AP 20. En el caso de que la función 21 de control de acceso sea implementada en un elemento de red convencional de la LAN 3, la función 21 de control de acceso puede estar incluida dentro de un módulo específico que proporcione la funcionalidad de control de acceso en cooperación con otros módulos y unidades del elemento de red.
La función 21 de control de acceso lee la cabecera de cada paquete de datos que llega, en particular el SSID comprendido dentro de la cabecera, y controla si el SSID está autorizado en la LAN 3. Por ejemplo, la función 21 de control de acceso está configurada para admitir todos los paquetes de datos asociados con el primer SSID utilizado por usuarios autorizados de la LAN 3 y cualquiera de los SSIDs de emergencia difundidos. Con este fin, la función 21 de control de acceso puede tener almacenado en la memoria 205 un archivo de datos que comprenda una lista de control de acceso con una lista de SSIDs que estén aprobados. A continuación, la función 21 de control de acceso consulta la lista de control de acceso y compara el SSID de un paquete de datos llegado con los SSIDs de dicha lista de control de acceso. Dependiendo del resultado, el paquete de datos es admitido en la LAN 3 o rechazado. De manera similar, el procedimiento de la ACL mencionado con anterioridad puede ser llevado a cabo por medio de la función 21 de control de acceso (ACL = Lista de Control de Acceso [Access Control List]).
Otra forma de controlar el acceso a la LAN 3 puede ser asignar, mediante la función 21 de control de acceso un ancho de banda limitado a un cliente que envía paquetes de datos asociados con un SSID de emergencia. De modo preferente, la función 21 de control de acceso concluye un contrato con cada cliente que envía paquetes de datos asociados con un SSID de emergencia. Este contrato limita el ancho de banda aceptado por un cliente. De esta manera, los paquetes de datos enviados por el terminal que excedan del ancho de banda asignado son simplemente descolgados por la función 21 de control de acceso. Esto disminuye el peligro de que un usuario utilice su acceso a la WLAN para enviar otros paquetes de datos distintos de los paquetes de datos relacionados con una llamada de emergencia.
La función 21 de control de acceso, puede, así mismo, filtrar los paquetes de datos asociados con un SSID de emergencia de acuerdo con el protocolo y con las direcciones de IP de origen y con las direcciones de IP de destino utilizadas. Por ejemplo, es posible permitir solo paquetes de datos que acarreen comunicación de voz. En general, es posible solo filtrar los paquetes de datos con respecto al servicio / protocolo y / o ancho de banda y / u origen y / o destino.
Aparte del terminal 10 y su asignación a una dirección de IP por medio de una solución del DHCP, el terminal 10 puede, así mismo, recibir una dirección de IP por otros procedimientos conocidos en el campo de la conexión en red de las telecomunicaciones.
El procedimiento por medio del cual los paquetes de datos asociados con la llamada de emergencia son transmitidos al gestor de llamadas 40 como una primera estación, es totalmente independiente del protocolo asociado. Para asegurar una transmisión fiable y rápida, todas las modificaciones que son propensas a errores, como por ejemplo la codificación y la descodificación, entramado, etc. se omiten. Los paquetes de datos son simplemente transferidos, por ejemplo, como paquetes RTP, desde el terminal 10 hasta el gestor de llamadas 40 el cual siempre escucha una solicitud del servicio de emergencias sobre un punto de conexión específico.
Desde el gestor de llamadas 40, los paquetes de datos relacionados con la llamada de emergencia son encaminados, a través de una red PSTN, hacia el PSAP 60. Por consiguiente, la marcación 903 de un número del servicio de emergencia rápidamente conecta el terminal 10 con un despachador situado en un PSAP entrenado para encaminar la llamada de emergencia hacia los organismos sanitarios, antincendios y de seguridad de emergencia locales.
En el centro 60 de llamadas, del PSAP, un operador verifica la localización de la llamada, determina la naturaleza de la emergencia y decide cuales son los equipos de la emergencia que deben ser notificados. El despachador de la emergencia utiliza la información de la localización suministrada por los LBS para dirigir al personal de seguridad pública que responde a la emergencia para asegurar un tiempo de respuesta de la emergencia lo más corto posible (LBS = Servicios Basados en la Localización {[Location Based Services]). Algunas veces un solo PSAP primario contestará para una zona entera. En la mayoría de los casos, el llamante es transferido a un PSAP secundario desde el cual se enviará ayuda. Los PSAPs secundarios están algunas veces situados en oficinas de avisos de incendios, cuarteles generales de policía municipal o en centros de envío de ambulancias. Una vez que la llamada ha sido procesada, el operador PSAP o el centro de despacho alerta al equipo de respuesta de la emergencia apropiado, ya se trate de un incendio, un rescate o de un asunto de la policía.
Dado que no es conocido que el terminal 10 sea accesible a la LAN 3 por medio del AP 20, no puede utilizar la encriptación. Sin embargo, hay varias formas de proteger a la LAN 3 de la piratería y / o de ataques.
El principal riesgo para la seguridad es la negación del servicio (= DoS). Un ataque de DoS es un ataque a un anfitrión (servidor) con el fin de paralizar uno o más de sus servicios. Normalmente, esto se consigue porsobrecarga. Típicamente los ataques DoS no se llevan a cabo a mano sino con un programa subrepticio el cual se propaga de manera independiente hacia otros anfitriones de una red. De esta manera, el atacante tiene anfitriones adicionales asumiendo la ejecución para sus ataques DoS. En una infraestructura del estándar 802.11, como por ejemplo la LAN 3, las normas de protección de seguridad pueden ser aplicadas para conseguir una cierta protección contra los ataques. Solo los paquetes del DHCP y del RTP son flujos autorizados para un anfitrión específico de la LAN 3. Si se utilizan otros protocolos, el usuario puede ser preterido y no se puede asociar con el AP 20 durante un periodo de tiempo configurable.
Como alternativa, puede ser implementada una aplicación de detección y defensa de DoS y Hombre en el Medio (= MITM) sobre la LAN 3. Un ataque MITM tiene su origen en un atacante situado física o lógicamente en el medio de los copartícipes en las comunicaciones. En esta posición, el atacante MITM tiene un control total sobre el tráfico de datos entre los dos o más abonados de la red y puede ver o incluso manipular a voluntad la información intercambiada.
Otra forma más de proteger la LAN 3 contra los ataques sería proporcionar solo un ancho de banda limitado para los usuarios: Esto puede ayudar a que el sistema se defienda contra los ataques DoS. Así mismo, es posible que la NAT de destino utilizada para impedir el ataque sea dirigida contra otros servicios (NAT = Traducción de Direcciones de Red [Network Address Traslation]).
En otra forma de realización más, una asociación de todos los usuarios visitantes puede ser utilizada en una red de área local virtual (= VLAN) dedicada a ellos con el fin de aplicar la ACL por cada VLAN. Una VLAN sobre una red es un dominio de radiodifusión. Todos los anfitriones dispuestos sobre esa VLAN pueden comunicar con los demás miembros de la misma VLAN. Una VLAN privada (= PVLAN) permite que el tráfico sea segmentado como nivel de enlace de datos (nivel 2) del modelo OSI, limitando el tamaño del dominio de radiodifusión (OSI = Interconexión de Sistemas Abiertos [Open Systems Interconnection]). La ACL está configurada, por ejemplo, en un encaminador el cual puede excluir el acceso de clientes específicos a la LAN 3 por medio de su dirección de IP.
La protección contra los ataques puede, así mismo, ser implementada sobre conmutadores y encaminadores. Una posibilidad es configurar el entorno PVLAN para el aislamiento del nivel 2. Una PVLAN ofrece una subdivisión adicional dentro de una VLAN existente, haciendo posible que los puntos de conexión individuales sean separados de otros compartiendo al tiempo la misma subred de IP. Esto permite que se produzca la separación entre los dispositivos sin que se requiera una subred de IP separada para cada dispositivo. En su forma más simple, las PVLANs soportan puntos de conexión aislados y puntos de conexión promiscuos. Los puntos de conexión aislados pueden únicamente comunicarse con puntos de conexión promiscuos mientras que los puntos de conexión promiscuos pueden comunicarse con cualquier punto de conexión. En este despliegue, los miembros de una subred son puntos de conexión aislados, y el dispositivo de pasarela está conectado a un punto de conexión promiscuo. Esto permite que los anfitriones de una subred no atiendan las solicitudes de los miembros de la misma subred.
Otra posibilidad sería que la característica de la VLAN visitadora privada del estándar 802.1x extendiera una VLAN visitadora del estándar 802.1x hacia el entorno de la PVLAN para el aislamiento del nivel 2. La VLAN visitadora privada del estándar 802.1x ofrece un acceso a red limitado a través de una PVLAN secundaria visitadora a los usuarios sin un suplicante del 802.1x.
Otro procedimiento, bastante directo, sería utilizar una técnica de ACL o simplemente restringir un número mínimo de direcciones de MAC a las VLANs dispuestas sobre un punto de conexión troncal.
La presente invención da soporte a diversas formas de impedir las asociaciones inapropiadas sin intención lesiva. Por ejemplo, cada terminal que se asocia con un SSID de servicio de emergencia debe enviar una TSPEC para requerir la emergencia dentro de un determinado periodo de tiempo, de lo contrario es desasociado y / o preterido por el AP 20. Como alternativa el SSID puede estar oculto y es obligatorio un escaneo activo para asociarlo al SSID de emergencia.
La llamada de servicio de emergencia puede ser priorizada mediante el desencadenamiento del terminal 10 del uso de una especificación de tráfico TSPEC para indicar que el flujo del RTP tiene una prioridad de emergencia de voz. Así mismo, es posible que pueda ser utilizado un procedimiento de desalojo para favorecer una llamada de emergencia con respecto a llamadas de menor prioridad.
Las Figuras 3a a 3c muestran tres ejemplos diferentes relacionados con el encaminamiento de paquetes de una llamada de emergencia. En cada una de las figuras 3a a 3c, se transmite una secuencia de mensajes entre el terminal 10, el punto de acceso 20 de la LAN 3, un servidor 22 de l NAT asociado con el punto de acceso 20, el servidor 30 del DHCP, el gestor de llamadas 40 y el PSAP 60.
La Fig. 3a muestra una secuencia de flujo de mensajes relacionada con un encaminamiento de paquetes en base a un procedimiento del DHCP. Con este procedimiento del DHCP un cliente pide – al solicitar una dirección de IP – una opción concreta del DHCP que proporcione al cliente la dirección de IP del gestor de llamadas. En una primera etapa del procedimiento, el terminal 10 envía un mensaje 210 DHCP DISCOVER. Para que el terminal 10 sea capaz de utilizar el servidor 30 del DHCP, ambos servicios deben estar situados dentro de la misma red de IP a menos que se utilice un retransmisor del DHCP. Si ambos dispositivos no están dentro de la misma red de IP, puede ser utilizado un dispositivo de asistencia del DHCP, como por ejemplo una unidad de retransmisión del DHCP o una unidad de ayuda del DHCP la cual retransmita y / o reenvíe los mensajes relacionados con el DHCP hacia la red en la que el servidor del DHCP está situado.
El mensaje 210 DHCP DISCOVER enviado por el terminal 10 llega al servidor 30 del DHCP. Esto puede conseguirse mediante el envío del mensaje 210 DHCP DISCOVER en radiodifusión si el terminal 10 y el servidor 30 del DHCP están en la misma red, por ejemplo una VLAN, o a través de un ayudante del DHCP. Por medio del mensaje 210 DHCP DISCOVER, el terminal 10 solicita una dirección de IP del servidor 30 del DHCP. De modo preferente, el mensaje 210 DHCP DISCOVER comprende una dirección de MAC del terminal 10 (MAC = Control de Acceso al Medio {[Media Access Control}]). La dirección de MAC, conocida también como dirección LAN, ID de Ethernet o ID de aeropuerto, es la dirección hardware de un dispositivo de red la cual sirve para la identificación única del dispositivo existente en la red.
De modo preferente, el terminal 10 envía el mensaje 210 DHCP DISCOVER como una retransmisión de red a todos los servidores disponibles del DHCP. Es posible que varios servidores del DHCP estén situados dentro de la misma subred de IP. El mensaje 210 de radiodifusión DHCP DISCOVER puede acarrear como dirección de IP de remitente
0.0.0.0 y puede ser dirigido a la dirección de destino 255.255.255.255, dado que el terminal 10 de envío no posee una dirección de IP, todavía, y dirige la solicitud a todos los servidores alcanzables del DHCP.
El servidor 30 del DHCP recibe el mensaje 210 DCHP DISCOVER y contesta con un mensaje 211 DHCP OFFER el cual comprende una oferta de una dirección de IP para el terminal 10 solicitante. El mensaje 211 DHCP OFFER comprende así mismo un ID del servidor que identifica el servidor 30 remitente del DHCP y una dirección de IP y un punto de conexión del gestor de llamadas 40. Es posible que el terminal 10 reciba más de un mensaje de oferta procedente de servidores del DHCP diferentes. De esta manera, el terminal puede escoger entre las ofertas recibidas. Después de seleccionar una de las una o más ofertas propuestas, el terminal contacta, por medio de un mensaje 212 DHCP REQUEST, con el servidor 30 apropiado del DHCP el cual es identificado por medio del correspondiente ID de servidor. De modo preferente, el mensaje 212 DHCP REQUEST es difundido.
En respuesta, el servidor 30 del DHCP transmite un mensaje 213 DHCP ACK (= acknowledge) al terminal solicitante
10. El mensaje 213 DHCP ACK comprende una dirección de IP del terminal 10, la dirección de IP del gestor de llamadas 40 y un punto de conexión sobre el cual el gestor de llamadas 40 está constantemente escuchando, y los datos adicionales relevantes.
De esta manera, en la etapa 214, el terminal 10 tiene su propia dirección de IP, la dirección de IP del gestor de llamadas 40 y el punto de conexión 0 sobre el cual está escuchando el gestor de llamadas 40. El terminal 10 dirige los paquetes relacionados con la llamada de emergencia con la dirección de destino y con el punto de conexión con el gestor de llamadas 40 y envía los paquetes dirigidos al gestor de llamadas 40. Se establece un flujo 215 del RTP entre el terminal 10 y el gestor de llamadas 40. El gestor de llamadas 40 recibe los paquetes relacionados con la llamada de emergencia, inicia un establecimiento de llamada 216 hacia el PSAP relevante 60 y reenvía los paquetes al SPAP 60.
La Fig. 3b muestra una secuencia de flujo de mensajes relacionados con un encaminamiento de paquetes basado en una NAT de destino. Con este procedimiento de la NAT de destino, un cliente puede enviar paquetes a cualquier dirección de destino una vez que ha recibido una dirección de IP. Un servidor 22 de la NAT modificará esta dirección en una del gestor de llamadas 30. Las etapas 220 a 224 de la Fig. 3b se corresponden con las etapas 210 a 214 mostradas en la Fig. 3a. La única diferencia con respecto al procedimiento ilustrado en la Fig. 3a es que el mensaje 221 DHCP OFFER y el mensaje 223 DHCP ACK no comprenden la dirección de IP y el punto de conexión del gestor de llamadas 40.
Es, así mismo, posible que el terminal 10 reciba una dirección de IP para unirse a la LAN 3 por medio de otro procedimiento distinto del de a través del DHCP.
En la etapa 224, el terminal 10 solo recupera su dirección de IP. El terminal 10 dirige los paquetes relacionados con la llamada de emergencia con cualquier dirección de IP como dirección de destino y envía los paquetes dirigidos al servidor 22 de la NAT asociado con el AP 20. Se establece un flujo 225 del RTP entre el terminal 10 y el servidor 22 de la NAT. El servidor 22 de la NAT recibe los paquetes procedentes del terminal 10 y traduce la dirección de destino a la dirección de IP del gestor de llamadas 40. Se establece un flujo 226 del RTP entre el servidor 22 de la NAT y el gestor de llamadas 40. El gestor de llamadas 40 recibe la información relacionada con la llamada de emergencia en forma de paquete o en forma de flujo, inicia un establecimiento de llamada 227 hacia el PSAP relevante 60 y reenvía los paquetes al PSAP 60.
La Fig. 3c muestra una secuencia de flujo de mensajes relacionada con un encaminamiento de paquetes en base a un procedimiento de multidifusión. Con este procedimiento de multidifusión, un cliente – una vez que ha recibido una dirección de IP – envía los paquetes a una dirección de multidifusión bien conocida situada en un punto de conexión predefinido sobre el cual el gestor de llamadas 40 está escuchando. Las etapas 230 a 234 de la Fig. 3c se corresponden con las etapas 210 a 214 mostradas en la Fig. 3a. La única diferencia con respecto al procedimiento ilustrado en la Fig. 3a es que el mensaje 231 DHCP OFFER y el mensaje 233 DHCP ACK no comprenden la dirección de IP y el punto de conexión del gestor de llamadas 40.
Es, así mismo, posible que el terminal 10 reciba una dirección de IP para unirse a la LAN 3 por medio de otro procedimiento distinto del de a través del DHCP.
En la etapa 234, el terminal 10 solo recupera su dirección de IP. El terminal 10 dirige los paquetes relacionados con la llamada de emergencia con una dirección de IP de multidifusión como dirección de destino y envía los paquetes dirigidos al gestor de llamadas 40. Se establece un flujo 235 del RTP entre el terminal 10 y el gestor de llamadas 40. El gestor de llamadas 40 recibe la información (en forma de paquete / flujo) relacionada con la llamada de emergencia, inicia un establecimiento de llamada 236 hacia el PSAP relevante 60 y reenvía los paquetes al PSAP
60.
La Figura 4 muestra un grupo 700 de usuarios autorizados de la WLAN 2 que comprende los terminales 70 a 73. El grupo 700 de usuarios autorizados es capaz de acceder a la LAN 3 con una llamada no de emergencia mediante la utilización de un primer SSID 7. Al mismo tiempo los miembros del grupo 700 son también miembros de un grupo abierto 800. El grupo abierto 800 comprende tanto los usuarios autorizados de los terminales 70 a 73 como los usuarios no autorizados de la WLAN 2 con los terminales 10 a 13. Solo el grupo 700 de usuarios autorizados está legitimado para acceder a la LAN 3 con una llamada de no emergencia utilizando un primer SSID 7. Sin embargo, tanto los miembros del grupo 700 como los miembros del grupo 800 están habilitados para acceder a la LAN 3 con una llamada de emergencia mediante la utilización de un SSID de emergencia 8, dado que el grupo 800 está situado dentro del área de cobertura del punto de acceso 20. Cualquier terminal del grupo 700 o del grupo 800 puede acceder a la LAN 3 por medio del punto de acceso 20 utilizando el SSID de emergencia 8, por ejemplo, el terminal 10 o el terminal 71.
Por consiguiente, cualquier terminal del área de cobertura o del punto de acceso 20 puede acceder a la LAN 3 en caso de una emergencia mediante la utilización del SSID de emergencia 8. En el caso de una llamada no de emergencia, solo los terminales del grupo autorizado 700 que comprende los usuarios autorizados de la WLAN 2 pueden acceder a la LAN 3 por medio del punto de acceso 20. Aunque las llamadas asociadas con el SSID de emergencia 8 serán encaminadas hacia el PSAP 60, una llamada no de emergencia, por ejemplo originada en el terminal 70, puede ser encaminada hacia otro asociado 90 de la comunicación en un procedimiento, tal y como es conocido en la técnica anterior.
Con el fin de imponer el control de acceso, la función 21 de control de acceso puede – además de restringir el acceso a la LAN 3 a los paquetes de datos procedentes de un terminal asociado con un SSID autorizado – aplicar reglas adicionales a los paquetes de datos entrantes. Es posible que cada usuario que envía paquetes de datos desde un terminal asociado con un SSID de emergencia hacia la LAN 2 pueda tener asignado un ancho de banda limitado que sea suficiente para establecer la llamada de emergencia con el PSAP 60 pero que no sea lo suficientemente ancho para establecer otras llamadas. Este mecanismo de control de acceso puede funcionar dado que una llamada de emergencia puede estar más bien restringida con respecto a la cantidad de datos.
Estrechamente relacionada con este mecanismo de control de acceso es la técnica de admitir solo tráfico de voz en la LAN 3. De esta manera, los paquetes de datos relacionados con aplicaciones que consumen ancho de banda como vídeo, son rechazados por la LAN 3 si los paquetes de datos intentan entrar en la LAN 3 mediante la utilización de un SSID de emergencia.
La Figura 5 muestra una red 400 para la transmisión de paquetes de IP y dos redes de acceso inalámbricas 401, 402 para proporcionar acceso a la red 400. La red de acceso corporativo 401 es una red de acceso corporativo solo accesible mediante terminales de usuario autorizados 701, 702, mientras que la red de acceso de emergencia 402 es accesible para fines de emergencia por cualquier terminal de usuario móvil dentro del área de servicio de la red de acceso de emergencia 402, esto es, tanto por los terminales de usuario autorizados 701, 702 como por los terminales de usuario visitadores 801 a 803.
Los terminales autorizados 701, 702 pueden comprender unos módulos de encriptación 7010, 7020 que permitan que los terminales 701, 702 encripten de manera apropiada paquetes de datos antes de transmitirlos a la red de acceso 4012.
Cada red de acceso 401, 402 difunde, por medio de un remitente, por ejemplo por medio de un AP, un SSID específico a la red de acceso respectiva. La red de acceso corporativa 401 difunde un SSID corporativo asociado con la red de acceso corporativo 401, y la red de acceso de emergencia 402 difunde un SSID de emergencia asociado con la red de acceso de emergencia 401. Los SSIDs difundidos pueden ser recibidos por cualquier terminal existentes en el área de cobertura de las redes de acceso 401, 402.
La red de acceso corporativa 401 comprende una función 4011 de control de acceso y, de manera similar, la red de acceso de emergencia 402 comprende una función 4021 de control de acceso. Las funciones 4011, 4012 de control de acceso son implementadas como servidores autónomos que comprenden unas normas de control de acceso almacenadas en un módulo de memoria. Cada una de las funciones 4011,4021 de control de acceso filtra los paquetes de datos entrante antes de admitirlos en las redes de acceso 401, 402.
Los paquetes de datos procedentes de un terminal asociado con el SSID de emergencia asociado con la red de acceso de emergencia 402 tienen un acceso garantizado por la función 4021 de control de acceso a la red de acceso de emergencia 402. Solo los terminales de usuario autorizados 701, 702 pueden ser capaces de encriptar de manera adecuada paquetes de datos por medio de los módulos de encriptación 7010, 7020. Los paquetes de datos que llegan a la función 4011 de control de acceso deben proceder de un terminal asociado con el correspondiente SSID corporativo asociado con la red de acceso corporativa 401 y pueden ser encriptados de manera adecuada para ser admitidos en la red de acceso 401. Por medio de una técnica de encriptación, la función 4011 de control de acceso filtra los paquetes de dato entrantes y descarta los paquetes de datos que no proceden de terminales de usuario autorizados. La función 4011 de control de acceso recupera los datos relevantes para el proceso de filtrado y examen a partir de una base de datos 4012.
El terminal de usuario visitador 801 ha tomado nota del SSID corporativo y utiliza el SSID corporativo para acceder a la red de acceso corporativa 401. Es posible que un administrador de la red de red de acceso corporativo 401 configure un SSID corporativo público que se establezca sobre un punto de acceso de la red de acceso corporativa 401 difundida a todos los dispositivos inalámbricos en cobertura. De esta manera, la SSID corporativa ha sido difundida abiertamente por la red de acceso corporativa 401 y el terminal de usuario visitador 801 ha recibido el SSID corporativo recogiendo el SSID corporativo difundido.
Sin embargo, también es posible que el terminal 801 de usuario visitador esté asociado con un escuchón el cual quiere utilizar los servicios de comunicaciones ofrecidos por la red de acceso corporativa 401 de una forma no autorizada. Imaginemos que el administrador de la red de la red de acceso corporativo 401 ha inhabilitado el elemento característico de difusión automática del SSID en una tentativa por mejorar la seguridad de la red cuando la difusión pública del SSID corporativo puede plantear un riesgo para la seguridad. Sin embargo, la protección ofrecida por la desactivación de una difusión de la SSID puede ser fácilmente sorteada por el escuchón en cuanto el SSID puede ser rastreada en texto no cifrado a partir de un paquete de datos enviado por un terminal autorizado 701, 702 a la red de acceso corporativa 401.
Sin embargo, el terminal de usuario visitador 801 que ha recibido el SSID corporativo, se asocia con el SSID corporativa y envía un flujo 301 de paquetes de datos a la red de acceso corporativa 401. Cuando el terminal 801 del usuario visitador carece de medios para encriptar de forma adecuada los paquetes de datos 301, el examen desarrollado por la función 4011 de control de acceso sobre el flujo 301 de paquetes de datos se traduce en un rechazo de paquetes de datos.
Por otro lado, el terminal 701 del usuario autorizado que comprende el módulo de encriptación 7010 envía unos paquetes de datos 1001 a la red de acceso corporativa 401, los cuales están dispuestos de forma que proceden de un terminal asociado de la SSID corporativa así como están adecuadamente encriptados. De esta manera, el proceso de examen en la función 4011 de control de acceso se traduce en la admisión a la red de acceso. Así mismo, los paquetes de datos 1002 procedentes del otro terminal 702 del usuario autorizado son, así mismo, admitidos en la red de acceso corporativa 401.
Cuando el terminal 702 del usuario autorizado envía los paquetes de datos 502 desde un terminal asociado con el SSID de emergencia a la función 4021 de control de acceso, los paquetes de datos 502 son emitidos en la red de acceso de emergencia 402. El terminal 802 del usuario visitador envía un flujo 501 de paquetes de datos relacionado con el SSID de emergencia hacia la red de acceso corporativa 401 pero no es admitido en la red de acceso corporativa 401, dado que el flujo 501 de paquetes de datos ni procede de un terminal asociado con el SSID apropiado ni está encriptado de forma apropiada. Sin embargo, cuando el terminal 802 del usuario visitador asociado con el SSID de emergencia envía un flujo 502 de paquetes de datos hacia la red de acceso de emergencia 402, el flujo 502 de paquetes de datos es admitido en la red de acceso de emergencia 402 por la función 4021 de control de acceso dado que los paquetes de datos 503 proceden de un terminal asociado con el SSID de emergencia.
Cuando el terminal 803 del usuario visitador asociado con el SSID corporativo envía los paquetes de datos 302 a la red de acceso de emergencia 402, el flujo 302 de paquetes de datos es rechazado por la función 4021 de control de acceso. La función 4021 de control de acceso solo admite paquetes de datos procedentes de un terminal asociado con el SSID de emergencia.
Después de entrar en la red de acceso corporativa 401, los flujos de datos 1001 y 1002 son reenviados como flujos de datos 601 y 602 a la red 400 y encaminados hacia un elemento de red 4001, por ejemplo un encaminador o un conmutador, el cual encamina o conmuta los flujos de datos 601 y 602 de acuerdo con las direcciones de destino de ID indicadas en los paquetes de datos de los flujos de datos 601 y 602.
Por ejemplo, cuando el usuario del terminal 701 del usuario autorizado marca el número de teléfono VoIP de un copartícipe de comunicación corporativo, un agente usuario del VoIP del terminal 701 del usuario autorizado dirige en la medida correspondiente los paquetes de datos 1001, 601 con la dirección correspondiente, y el flujo 601 de los paquetes de datos es encaminado por el elemento de red 4001 hacia otro elemento de red 4002 el cual es responsable de la dirección. El establecimiento de una conexión requiere un intercambio de mensajes de señalización y control para el encaminamiento apropiado y el establecimiento de la llamada. Así mismo, los paquetes de datos 1002 son encaminados a través del elemento de red 4002 hacia otro elemento de red 4003. No hay ningún encaminamiento preestablecido, sino que cada salto siguiente en la red 400 se determina por cada elemento de red, de forma individual, para cada paquete de datos de acuerdo con la dirección indicada de un paquete de datos.
Por otro lado, los flujos de datos 502, 503 que llegan y son admitidos en la red de acceso de emergencia 402 son encaminados a un gestor de llamadas 4001, por ejemplo, una PBX, la cual encamina los paquetes de datos hacia un punto contestador 60 de servicios de emergencia, por ejemplo un PASP (PBX = Centralita [Private Branch Exchange]). El encaminamiento es ejecutado sobre una conexión sin necesidad de ningún tráfico de señalización y control.
Así mismo, es posible que, con independencia de la dirección efectiva del paquete de datos, la dirección de destino original del paquete de datos admitidos en la red de acceso de emergencia de la red 402 puede ser eliminado de los paquetes de datos sustituidos por una dirección estándar preestablecida asociada con el servicio de emergencia, por ejemplo, una red de IP y un punto de conexión del gestor de llamadas 4001. Mediante este sistema estandarizado y preestablecido, resulta posible una respuesta de las llamadas de emergencia rápida y fiable.
Las Figuras 6a a 6d muestran cuatro ejemplos diferentes relacionados con la localización de un terminal que inicia una llamada de emergencia. En cada una de las Figuras 6a a 6d, una secuencia de mensajes es transmitida entre el terminal 10, el punto de acceso 20 de la LAN 3, el servidor 30 del DHCP, un servidor de localización 35, el gestor de llamadas 40 y el PSAP 60. El servidor de localización 35 alberga unos servicios web que proporcionan la transmisión de la información de localización al PSAP.
La Fig. 6a muestra una secuencia de flujo de mensajes determinada por la localización del terminal 10 de acuerdo con una primera alternativa. En una primera etapa del procedimiento, el terminal 10 después de la asociación con una SSID de emergencia, envía un mensaje 510 de difusión activa a través del AP 20 al servidor de localización 35 (SOAP = Protocolo de Acceso de Objetos Simples [Simple Object Access Protocol]). El mensaje 510 de difusión activa del SOAP comprende una información de localización del terminal 10, por ejemplo un BSSID del AP 10 a través del cual el terminal tiene acceso a la VLAN (BSSID = Identificador de Conjuntos de Servicios Básicos [Basic Service Set Identifier]). El BSSID es un identificadr único de un AP en una LAN. La especificación de la LAN Inalámbrica del estándar 802.11 1999 del ZEGE define un BSSID como una dirección de MAC que identifica una estación (STA) de un AP en un modo de infraestructura. De esta manera, el BSSID identifica de forma unívoca cada AP lo cual es indispensable para distinguir los APs con un SSID idéntico.
El servidor de localización 35 responde una contestación 511 la cual actúa como una confirmación de la solicitud
510. Si el terminal 10 no recibe ninguna respuesta dentro de un periodo de tiempo determinado después del envío del mensaje 510 de solicitud del SOAP, el terminal 10 puede reenviar el mensaje 510 de solicitud del SOAP.
Tan pronto como el gestor de llamadas 40 advierte una llamada de emergencia, el gestor de llamadas comienza a sondear de forma regular el servidor de localización 35 mediante el envío de un mensaje de sondeo 512 al servidor
35. El mensaje de sondeo 512 provoca que el servidor de localización 35 informe al gestor de llamadas 40 de cualquier información de actualización relacionada con la información de localización del terminal 10. El servidor de localización 35 siempre responde con una información de localización. El servidor de localización 35 responde al mensaje de sondeo 512 mediante el envío de una respuesta 513. La respuesta 513 comprende, o bien una información de actualización relativa a la localización del terminal, o bien una indicación de que no se encuentra disponible ninguna actualización de localización. El gestor de llamadas 40 simplemente reenviará la información de localización recuperada en forma de mensaje 514 al PSAP 60 o procesará la información de localización recuperada y, a continuación, enviará la información de localización procesada en forma de mensaje 514 al PSAP 60.
Por ejemplo, el servidor de localización 35 puede traducir el BSSID del AP de la información de localización a coordenadas de geográficas, por ejemplo en forma de una base de datos que comprenda los BSSIDs y las correspondientes localizaciones de los APs de la LAN. El gestor de llamadas enviará entonces las coordenadas geográficas al PSAP 60 donde una asistencia será enviada a la localización geográfica indicada.
La Fig. 6b muestra una secuencia de flujo de mensajes relacionada con la localización del terminal 10 de acuerdo con una segunda alternativa. Las etapas 520 a 521 se corresponden con las etapas 510 a 511 descritas con referencia a la Fig. 6a. La descripción correspondiente ofrecida con anterioridad se aplica, así mismo, a la Fig. 6b.
Después de que el servidor de localizaci`´on 35 ha recibido la información de localización o una actualización de la información de localización desde el terminal 10 y, de modo preferente, ha enviado una respuesta 521 al terminal 10, el servidor de localización 35 difunde de forma activa la información de localización hacia el gestor de llamadas 40 por medio del mensaje 522. En respuesta al mensaje 522, el gestor de llamadas 40 envía un mensaje de respuesta 523 de confirmación al servidor de localizador 35.
El gestor de llamadas 40 simplemente reenviará la información de localización recuperada al PSAP 60 en forma de mensaje 524 o procesará la información de localización recuperada y a continuación, enviará la información de localización procesada en forma de mensaje 524 al PSAP 60, de acuerdo con lo descrito con anterioridad con referencia a la Fig. 6a.
La Fig. 6c muestra una secuencia de flujo de mensajes relacionada con la localización del terminal 10 de acuerdo con una tercera alternativa. En una primera etapa del procedimiento el terminal 10, después de su asociación con un SSID de emergencia, envía un mensaje 530 de solicitud de SOAP a través del AP 20 al gestor de llamadas 40. El mensaje 510 de solicitud de SOAP comprende la información de localización del terminal 10, por ejemplo, un BSSID del AP 10 a través del cual el terminal tiene acceso a la LAN.
El gestor de llamadas 40 responde con una contestación 531 la cual actúa como confirmación de la solicitud 530. Si el terminal 10 no recibe ninguna respuesta dentro de un periodo de tiempo determinado después del envío del mensaje 530 de la solicitud de SOAP, el terminal 10 puede reenviar el mensaje 530 de solicitud de SOAP al gestor de llamadas 40.
Después de que el gestor de llamadas 40 ha recibido la información de localización o una actualización de la información de localización desde el terminal 10 y, de modo preferente, haya enviado una respuesta 531 al terminal 10, el gestor de llamadas 40 simplemente reenviará la información de localización recuperada a modo de mensaje 532 al PSAP 60 o procesará la información de localización recuperada, y a continuación, enviará la información de localización presentada en forma de mensaje 532 al PASP 60,de acuerdo con lo descrito con anterioridad con referencia a la Fig. 6a.
La Fig. 6d muestra una secuencia de flujo de mensajes relacionada con la localización del terminal 10 de acuerdo con una cuarta alternativa. En una primera etapa del procedimiento, el terminal 10, después de su asociación con un SSID de emergencia, envía una solicitud 540 de renovación de DHCP al servidor 30 de DHCP. La solicitud 540 de renovación de DHCP comprende la información de localización del terminal 10, por ejemplo un BSSID del AP 10 a través del cual el terminal tiene acceso a la LAN.
Para seguir avanzando en el procedimiento, tenemos dos opciones. El servidor 30 del DHCP o bien envía un mensaje 541 de SOAP al servidor de localización 35 o envía un mensaje 546 de SOAP al gestor de llamadas 40.
En el primer caso, la información de localización puede ser transmitida al gestor de llamadas 40 o bien mediante un, de modo preferente regular, mensaje de sondeo 542 procedente del gestor de llamadas y la contestación correspondiente 543 procedente del servidor de localización 35, de acuerdo con lo descrito con anterioridad, o mediante la difusión de forma activa de la información de localización por medio de un mensaje 544 procedente del servidor de localización 35 hacia el gestor de llamadas 40 tan pronto como el servidor de localización 35 ha recibido el mensaje 541 de SOAP. De nuevo aquí, el gestor de llamadas 40 puede responder al mensaje 544 con una contestación de confirmación 545.
Después de que el gestor de llamadas 40 ha recibido la información de localización procedente del servidor de localización 35, el gestor de llamadas 40 simplemente reenviará la información de localización recuperada en forma de mensaje 547 al PSAP 60 o procesará la información de localización recuperada y, a continuación, enviará la información de localización procesada en forma de mensaje 547 al PSAP 60, de acuerdo con lo descrito con anterioridad con referencia a la Fig. 6a.
En este último caso, cuando el servidor 30 del DHCP envíe el mensaje 546 de SOAP directamente hacia el gestor de llamadas 40, el gestor de llamadas 40 reenviará de nuevo la información de localización original recuperada o una información de localización procesada en forma de mensaje 547 al PSAP 60.
Claims (5)
- REIVINDICACIONES1.- Un procedimiento de provisión a un terminal (10) de un acceso de emergencia sobre una WLAN (2) a una LAN(3) que comprende uno o más puntos de acceso (20) y una función (21) de control de acceso la cual admite paquetes de datos procedentes de usuarios (70 a 73) de la WLAN (2) asociados con un primer SSID (7) hacia la LAN (3), comprendiendo el procedimiento las etapas de:la definición de uno o más SSIDs de emergencia (8) dedicados a hacer posible el acceso a una LAN (2) en un caso de emergencia;el inicio de una llamada de emergencia mediante el envío de paquetes de datos desde un terminal (10) asociados con un SSID (8) de emergencia seleccionado hacia uno de los uno o más puntos de acceso (20), por medio de lo cual los paquetes de datos son dirigidos por el terminal (10) hacia una dirección de destino recibida por el terminal (10) por medio de una respuesta de DHCP;la admisión, mediante la función (21) de control de acceso, de los paquetes de datos procedentes del terminal (10) asociados con el SSID (8) de emergencia seleccionado hacia la LAN (3); yel encaminamiento de los paquetes de datos asociados con el SSID (8) de emergencia seleccionada,después de la admisión en la LAN (3), hacia un punto (60) de contestación de emergencia,por medio de lo cualel procedimiento comprende las etapas adicionales dela solicitud por el terminal (10) de una opción concreta del DHCP que proveerá al terminal (10) de una dirección de IP de un gestor de llamadas (40) responsable para la gestión del establecimiento de una llamada de emergencia hacia el punto (60) de contestación de emergencia y un punto de conexión sobre el cual el gestor de llamadas (40) escucha;la recepción, por el terminal (10), de la dirección de IP del gestor de llamadas (40) y el punto de conexión sobre el cual el gestor de llamadas (40) escucha por medio del DHCP desde un servidor del DHCP; yel direccionamiento de los paquetes de datos hacia el terminal (10) asociados con la SSID (8) de emergencia seleccionada con la dirección de IP recibida del gestor de llamadas (40) y el punto de conexión sobre el cual el gestor de llamadas (40) está escuchando.
- 2.- El procedimiento de acuerdo con la reivindicación 1,caracterizado porqueel procedimiento comprende las etapas adicionales de:la asociación de dos o más SSIDs (8) de emergencia con diferentes capacidades, de modo preferente con códecs y entramados diferentes; y la selección de un SSID (8) de emergencia en base a la información extraída de la difusión de uno o másSSIDs (8) de emergencia. 3.- El procedimiento de acuerdo con cualquiera de las reivindicaciones precedentescaracterizado porqueel procedimiento comprende la etapa adicional de: la priorización de la llamada de emergencia mediante la utilización de un procedimiento de especificación del tráfico o de un procedimiento de desalojo.4,- El procedimiento de acuerdo con cualquiera de las reivindicaciones precedentes,caracterizado porqueel procedimiento comprende las etapas adicionales de:la difusión de uno o más SSIDs (8) de emergencia desde al menos uno de los uno o más puntos de acceso (20); la detección, por el terminal (10), de al menos uno de los uno o más SSIDs (8) de emergencia difundidos;la selección de un SSID (8) de emergencia a partir del al menos un SSID de emergencia detectado;la asociación, por el terminal (10), con el SSID (8) de emergencia seleccionado.
- 5.- El procedimiento de acuerdo con cualquiera de las reivindicaciones precedentes,caracterizado porqueel procedimiento comprende la etapa adicional de:la generación de salida, después de la detección del al menos uno de los uno o más SSIDs (8) de emergencia, de una notificación en el terminal (10) para informar a un usuario (100) del terminal (10) que se encuentra disponible un acceso de emergencia en la WLAN (2).
- 6.- Un sistema de comunicación (1) para proveer a un terminal (10) de un acceso de emergencia sobre una WLAN
- (2)
- a una LAN (3) comprendiendo el sistema de comunicación una función (21) de control de acceso la cual admite paquetes de datos procedentes de unos usuarios (70 a 73) de la WLAN (2) asociados con un primer SSID (7) en la LAN (3), en el que el sistema de comunicación comprende una interfaz (202) adaptada para recibir paquetes de datos de un terminal (10) asociados con un SSID (8) de emergencia seleccionado entre el al menos un SSID (8) de emergencia seleccionado, una unidad de control (203) adaptada para reenviar los paquetes de datos recibidos del terminal (10) asociados con el SSID (8) de emergencia seleccionado hacia la función (21) de control de acceso, por medio de lo cual la función (21) de control de acceso admite los paquetes de datos procedentes del terminal (10) asociados con el SSID (8) de emergencia seleccionado en la LAN (3), y en el que el sistema de comunicación está adaptado para encaminar los paquetes de datos desde el terminal (10) asociados con el SSID (8) de emergencia seleccionado, después de su admisión en la LAN (2), hacia un punto (60) contestador de emergencia, por medio de lo cual dichos paquetes de datos acarrean una dirección de destino recibida en el terminal (10) a partir del sistema de comunicación (1) por medio de una respuesta del DHCP, y por medio de lo cual
el sistema de comunicación (1) comprende así mimo un gestor de llamadas (40) responsable de la gestión de una configuración de llamadas de emergencia con respecto al punto (60) de contestación de emergencia, y un servidor- (30)
- del DHCP adaptado para proveer, en respuesta a una solicitud procedente del terminal (10) para una correspondiente opción del DHCP concreta, al terminal (10) de una dirección de IP del gestor de llamadas (40) y un punto de conexión sobre el que el gestor de llamadas (40) está escuchando, por medio del DHCP para dirigir los paquetes de datos situados en el terminal (10) asociados con el SSID (8) de emergencia seleccionados con la dirección de IP recibida del gestor de llamadas (40) y con el punto de conexión sobre el que el gestor de llamadas
- (40)
- está escuchando.
- 7.- Un sistema de comunicación de acuerdo con la reivindicación 6,caracterizado porqueel sistema de comunicación comprende así mismo un remitente (201) adaptado para difundir uno o más SSIDs (8) de emergencia dedicados a autorizar al terminal (10) a acceder a la LAN (3) en un caso de emergencia.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP06360015A EP1850532B1 (en) | 2006-04-29 | 2006-04-29 | Method of providing a guest terminal with emergency access over a WLAN |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2381392T3 true ES2381392T3 (es) | 2012-05-25 |
Family
ID=36780758
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES06360015T Active ES2381392T3 (es) | 2006-04-29 | 2006-04-29 | Procedimiento de provisión a un terminal visitador de un acceso de emergencia sobre una WLAN |
Country Status (9)
Country | Link |
---|---|
US (1) | US7877785B2 (es) |
EP (1) | EP1850532B1 (es) |
JP (1) | JP4913209B2 (es) |
KR (1) | KR101226042B1 (es) |
CN (1) | CN101064655B (es) |
AT (1) | ATE551799T1 (es) |
ES (1) | ES2381392T3 (es) |
PL (1) | PL1850532T3 (es) |
WO (1) | WO2007124987A1 (es) |
Families Citing this family (96)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8682279B2 (en) * | 2004-05-07 | 2014-03-25 | Interdigital Technology Corporation | Supporting emergency calls on a wireless local area network |
CN101296509B (zh) * | 2007-04-28 | 2012-12-12 | 华为技术有限公司 | 紧急通信业务实现方法、系统及其相关设备 |
US20080281696A1 (en) | 2007-05-11 | 2008-11-13 | Verizon Services Organization Inc. | Systems and methods for using dns records to provide targeted marketing services |
JP2009219076A (ja) * | 2008-03-13 | 2009-09-24 | Nec Corp | Ip電話システムにおけるゲートウェイルータおよび緊急呼の優先制御方法 |
DE102008017136B4 (de) * | 2008-04-03 | 2013-01-31 | Siemens Aktiengesellschaft | Vorrichtung zum Bereitstellen eines Dienstes für ein mobiles Endgerät über eine WLAN-Verbindung |
US9148769B2 (en) | 2008-05-07 | 2015-09-29 | Qualcomm Incorporated | System, apparatus and method to enable mobile stations to identify calls based on predetermined values set in a call header |
CN105468963A (zh) * | 2008-08-20 | 2016-04-06 | 韦尔普罗有限责任公司 | 用于生成密码的数据包发生器 |
US20100115127A1 (en) * | 2008-11-05 | 2010-05-06 | Appsware Wireless, Llc | Method and system for securing data from a non-point of sale device over a lan |
US8966610B2 (en) * | 2008-11-05 | 2015-02-24 | Apriva, Llc | Method and system for securing data from a non-point of sale device over an external network |
US20100114723A1 (en) * | 2008-11-05 | 2010-05-06 | Appsware Wireless, Llc | Method and system for providing a point of sale network within a lan |
US20100115599A1 (en) * | 2008-11-05 | 2010-05-06 | Appsware Wireless, Llc | Method and system for securing data from a point of sale device over an external network |
US20100115624A1 (en) * | 2008-11-05 | 2010-05-06 | Appsware Wireless, Llc | Method and system for securing data from a point of sale device over a lan |
US20100115600A1 (en) * | 2008-11-05 | 2010-05-06 | Appsware Wireless, Llc | Method and system for securing data from an external network to a point of sale device |
US8732813B2 (en) * | 2008-11-05 | 2014-05-20 | Apriva, Llc | Method and system for securing data from an external network to a non point of sale device |
EP2384032A4 (en) * | 2008-12-26 | 2016-01-20 | Nec Corp | COMMUNICATION SYSTEM, FEMTO BASE STATION, CALL STATUS CONTROL SERVER, HOME SUBSCRIBER SERVER, COMMUNICATION METHOD, AND PROGRAM |
CN101730038A (zh) * | 2009-04-29 | 2010-06-09 | 中兴通讯股份有限公司 | 紧急业务的实现方法及家用基站 |
CN101931954B (zh) * | 2009-06-22 | 2013-02-27 | 南京中兴软件有限责任公司 | 一种基于业务区分改进无线局域网中实时业务QoS的方法 |
CN102118372B (zh) * | 2009-12-31 | 2013-07-10 | 深圳市多尼卡电子技术有限公司 | 提供非实时互联网服务的系统和方法 |
US8955054B2 (en) * | 2010-01-06 | 2015-02-10 | Qualcomm Incorporated | Method and apparatus for providing simultaneous support for multiple master keys at an access point in a wireless communication system |
EP2405678A1 (en) | 2010-03-30 | 2012-01-11 | British Telecommunications public limited company | System and method for roaming WLAN authentication |
EP2373075A1 (en) | 2010-03-30 | 2011-10-05 | British Telecommunications public limited company | System and method for WLAN traffic monitoring |
US9689988B1 (en) * | 2010-06-03 | 2017-06-27 | 8X8, Inc. | Systems, methods, devices and arrangements for emergency call services and emergency broadcasts |
RU2564251C2 (ru) * | 2010-09-16 | 2015-09-27 | Нокиа Корпорейшн | Динамическое создание аккаунта в защищенной сети с беспроводной точкой доступа |
CN102457907B (zh) * | 2010-10-25 | 2015-07-29 | 上海贝尔股份有限公司 | 集中式无线局域网中识别客户端类型的方法和装置 |
US9763140B2 (en) * | 2010-11-02 | 2017-09-12 | Cisco Technology, Inc. | Resource reservation on networks comprising wireless and wired segments |
JP2012182743A (ja) * | 2011-03-02 | 2012-09-20 | Toshiba Tec Corp | 電子機器、通信システムおよびプログラム |
JP5655672B2 (ja) * | 2011-03-31 | 2015-01-21 | 富士通株式会社 | プログラム、情報通信機器および連携方法 |
US8869259B1 (en) * | 2011-05-19 | 2014-10-21 | Zscaler, Inc. | Cloud based inspection of secure content avoiding man-in-the-middle attacks |
KR101453521B1 (ko) | 2011-05-20 | 2014-10-24 | 주식회사 케이티 | 무선 액세스 포인트 장치 및 비인가 무선 랜 노드 탐지 방법 |
WO2012161386A1 (ko) * | 2011-05-20 | 2012-11-29 | 주식회사 케이티 | 무선 액세스 포인트 장치 및 비인가 무선 랜 노드 탐지 방법 |
US8769023B2 (en) * | 2011-08-03 | 2014-07-01 | Juniper Networks, Inc. | Disaster response system |
US8856290B2 (en) * | 2011-10-24 | 2014-10-07 | General Instrument Corporation | Method and apparatus for exchanging configuration information in a wireless local area network |
MY161907A (en) * | 2011-12-23 | 2017-05-15 | Telekom Malaysia Berhad | System and method for providing multiple identifiers in a single access point |
KR101918040B1 (ko) * | 2012-02-20 | 2019-01-29 | 삼성전자주식회사 | 스크린 미러링 방법 및 그 장치 |
CN103379586B (zh) * | 2012-04-24 | 2018-09-28 | 华为终端(东莞)有限公司 | 一种发现接入点的方法及站点、接入点 |
CN102821355A (zh) * | 2012-05-15 | 2012-12-12 | 扬州易游物联网络科技有限公司 | 一种简便的利用无线局域网进行用户定位的方法 |
US10129751B2 (en) * | 2012-05-25 | 2018-11-13 | Comcast Cable Communications, Llc | Wireless gateway supporting public and private networks |
CN103517383B (zh) * | 2012-06-18 | 2017-04-12 | 华为终端有限公司 | 移动终端接入家庭网络的方法和设备 |
JP5912913B2 (ja) * | 2012-06-26 | 2016-04-27 | アルパイン株式会社 | 車載機器 |
US9565622B2 (en) * | 2012-07-05 | 2017-02-07 | Qualcomm Incorporated | Detecting services provided by a wireless node before device discovery and connection establishment |
US10708121B2 (en) * | 2012-11-05 | 2020-07-07 | Comcast Cable Communications, Llc | Intelligent network |
EP2934027A4 (en) * | 2012-12-13 | 2015-12-23 | Fujitsu Ltd | WIRELESS COMMUNICATION SYSTEM |
US8930044B1 (en) | 2012-12-28 | 2015-01-06 | Google Inc. | Multi-part navigation process by an unmanned aerial vehicle for navigating to a medical situatiion |
US8909391B1 (en) | 2012-12-28 | 2014-12-09 | Google Inc. | Responsive navigation of an unmanned aerial vehicle to a remedial facility |
US9051043B1 (en) | 2012-12-28 | 2015-06-09 | Google Inc. | Providing emergency medical services using unmanned aerial vehicles |
US8983682B1 (en) | 2012-12-28 | 2015-03-17 | Google Inc. | Unlocking mobile-device and/or unmanned aerial vehicle capability in an emergency situation |
US8948935B1 (en) | 2013-01-02 | 2015-02-03 | Google Inc. | Providing a medical support device via an unmanned aerial vehicle |
GB2511313A (en) | 2013-02-27 | 2014-09-03 | Sony Corp | A relay device, method and computer program |
EP2824973A1 (en) * | 2013-07-09 | 2015-01-14 | Orange | Network architecture enabling a mobile terminal to roam into a wireless local area network |
CN104427587A (zh) * | 2013-08-23 | 2015-03-18 | 联想移动通信科技有限公司 | 一种无线局域网接入点的连接方法及移动设备 |
US9386148B2 (en) | 2013-09-23 | 2016-07-05 | Ooma, Inc. | Identifying and filtering incoming telephone calls to enhance privacy |
US9686819B2 (en) | 2013-09-24 | 2017-06-20 | Xiaomi Inc. | Methods, devices and systems for router access control |
CN103501482A (zh) * | 2013-09-26 | 2014-01-08 | 小米科技有限责任公司 | 网络接入方法、装置及终端 |
DE102014202758A1 (de) * | 2014-02-14 | 2015-08-20 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Verfahren, Vorrichtung und Drahtlosnetzwerkumgebung zum Austausch von Daten |
JP6330445B2 (ja) * | 2014-04-17 | 2018-05-30 | 株式会社バッファロー | 通信システム |
US10239638B1 (en) | 2014-05-10 | 2019-03-26 | Wing Aviation Llc | Home station for unmanned aerial vehicle |
US10769931B2 (en) | 2014-05-20 | 2020-09-08 | Ooma, Inc. | Network jamming detection and remediation |
US9633547B2 (en) | 2014-05-20 | 2017-04-25 | Ooma, Inc. | Security monitoring and control |
US10553098B2 (en) * | 2014-05-20 | 2020-02-04 | Ooma, Inc. | Appliance device integration with alarm systems |
US11330100B2 (en) | 2014-07-09 | 2022-05-10 | Ooma, Inc. | Server based intelligent personal assistant services |
CN105451188B (zh) * | 2014-08-08 | 2018-11-16 | 阿里巴巴集团控股有限公司 | 实现信息推送的方法、服务器、共享者客户端、第三方客户端 |
JP5915712B2 (ja) * | 2014-09-30 | 2016-05-11 | 富士通株式会社 | 制御プログラム、制御装置、および、制御方法 |
US12081453B2 (en) | 2015-01-30 | 2024-09-03 | Comcast Cable Communications, Llc | Provisioning and managing resources |
US9923814B2 (en) * | 2015-02-17 | 2018-03-20 | Huawei Technologies Co., Ltd. | Media access control address resolution using internet protocol addresses |
US20160295386A1 (en) * | 2015-04-03 | 2016-10-06 | Qualcomm Incorporated | Techniques to support emergency services |
US10771396B2 (en) | 2015-05-08 | 2020-09-08 | Ooma, Inc. | Communications network failure detection and remediation |
US10911368B2 (en) | 2015-05-08 | 2021-02-02 | Ooma, Inc. | Gateway address spoofing for alternate network utilization |
US10009286B2 (en) | 2015-05-08 | 2018-06-26 | Ooma, Inc. | Communications hub |
US11171875B2 (en) | 2015-05-08 | 2021-11-09 | Ooma, Inc. | Systems and methods of communications network failure detection and remediation utilizing link probes |
JP6627314B2 (ja) | 2015-08-03 | 2020-01-08 | 株式会社リコー | 通信システム、通信方法、通信装置およびプログラム |
US10104665B2 (en) | 2015-08-10 | 2018-10-16 | Network Performance Research Group Llc | Method and apparatus for providing dynamic frequency selection spectrum access in peer-to-peer wireless networks |
US9832791B2 (en) | 2015-08-04 | 2017-11-28 | Network Performance Research Group Llc | Method and apparatus for use of simultaneous multiple channels in the dynamic frequency selection band in wireless networks |
US9439197B1 (en) | 2015-08-10 | 2016-09-06 | Planetary Network Technologies, Inc. | Method and apparatus for directed adaptive control of dynamic channel selection in wireless networks |
US9807625B2 (en) | 2015-08-10 | 2017-10-31 | Network Performance Research Group Llc | Method and apparatus for using time shifted analysis based on gathering non-encrypted information from packets |
US20170048728A1 (en) * | 2015-08-10 | 2017-02-16 | Network Performance Research Group Llc | Method and apparatus for directed adaptive control of access point-to-client interaction in wireless networks |
US9924518B2 (en) | 2015-08-10 | 2018-03-20 | Network Performance Research Group Llc | Method and apparatus for dynamic channel selection device |
CN105263099B (zh) * | 2015-08-28 | 2018-10-12 | 小米科技有限责任公司 | 发送位置信息的方法和装置 |
FR3041842A1 (fr) * | 2015-09-30 | 2017-03-31 | Orange | Systeme de restauration de services fournis par une passerelle residentielle |
US10368247B2 (en) | 2015-11-25 | 2019-07-30 | Network Performance Research Group Llc | Cloud DFS super master detector location systems and methods |
US9839038B2 (en) | 2015-11-25 | 2017-12-05 | Network Performance Research Group Llc | System, method, and apparatus for setting a regulatory operating mode of a device |
US9930670B2 (en) | 2015-11-25 | 2018-03-27 | Network Performance Research Group Llc | System, method, and apparatus for setting device geolocation via location proxies |
US10716168B2 (en) * | 2015-12-09 | 2020-07-14 | Hewlett-Packard Development Company, L.P. | Data transmissions without connections |
WO2018017480A1 (en) * | 2016-07-20 | 2018-01-25 | Level 3 Communications, Llc | Dynamic service provisioning system and method |
CN106130866A (zh) * | 2016-08-01 | 2016-11-16 | 浪潮(苏州)金融技术服务有限公司 | 一种基于udp实现的局域网设备自主接入方法 |
US10604252B2 (en) | 2016-11-22 | 2020-03-31 | Wing Aviation Llc | Landing and payload loading structures |
US9867217B1 (en) * | 2016-12-30 | 2018-01-09 | T-Mobile Usa, Inc. | Emergency call setup in wireless networks |
PL3379790T3 (pl) * | 2017-03-22 | 2020-03-31 | Deutsche Telekom Ag | Sposób ulepszonej obsługi połączenia alarmowego z komutacją pakietów wewnątrz sieci telekomunikacyjnej i/lub udoskonalonej obsługi informacji o lokalnej służbie ratunkowej przez urządzenie użytkownika, system, urządzenie użytkownika i program |
US10691142B2 (en) | 2017-12-21 | 2020-06-23 | Wing Aviation Llc | Anticipatory dispatch of UAVs to pre-staging locations |
HUE051099T2 (hu) * | 2017-12-22 | 2021-03-01 | Deutsche Telekom Ag | Vészhelyzeti hálózati szelet és eljárás és hozzáférési hálózati entitás vészhelyzeti kommunikáció feldolgozására csomagkapcsolt kommunikációs hálózatban |
CN109729151B (zh) * | 2018-12-06 | 2022-05-03 | 浙江大学宁波理工学院 | 一种车载终端数据传输系统及方法 |
CN112040424B (zh) * | 2019-06-04 | 2022-04-05 | 成都鼎桥通信技术有限公司 | 一种紧急抢占话权的方法和系统 |
CN111586145B (zh) * | 2020-04-30 | 2023-06-30 | 深圳市元征科技股份有限公司 | 一种车辆诊断方法、系统及电子设备和存储介质 |
US11667402B2 (en) | 2020-09-08 | 2023-06-06 | Wing Aviation Llc | Landing pad with charging and loading functionality for unmanned aerial vehicle |
CN113747413B (zh) * | 2021-11-04 | 2022-02-22 | 北京百瑞互联技术有限公司 | 多网络多模车载紧急呼叫方法、系统及介质 |
US20230156448A1 (en) * | 2021-11-12 | 2023-05-18 | Charter Communications Operating, Llc | Method and System for Supporting Emergency Voice Services Over Wireless Local Area Network (WLAN) Using Dynamic SSID Deployment |
US11876866B2 (en) * | 2021-11-29 | 2024-01-16 | Industrial Technology Research Institute | Method for assisting unregistered user device to access end-to-end call service of private network and communication system |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6714536B1 (en) | 1998-07-21 | 2004-03-30 | Eric M. Dowling | Method and apparatus for cosocket telephony |
US6950628B1 (en) | 2002-08-02 | 2005-09-27 | Cisco Technology, Inc. | Method for grouping 802.11 stations into authorized service sets to differentiate network access and services |
US7835317B2 (en) | 2002-10-08 | 2010-11-16 | Nokia Corporation | Network selection in a WLAN |
US7369859B2 (en) | 2003-10-17 | 2008-05-06 | Kineto Wireless, Inc. | Method and system for determining the location of an unlicensed mobile access subscriber |
US7885644B2 (en) * | 2002-10-18 | 2011-02-08 | Kineto Wireless, Inc. | Method and system of providing landline equivalent location information over an integrated communication system |
CN1802812A (zh) * | 2003-01-09 | 2006-07-12 | 汤姆森许可贸易公司 | 对多个接入点进行联合的方法和设备 |
US20040181692A1 (en) | 2003-01-13 | 2004-09-16 | Johanna Wild | Method and apparatus for providing network service information to a mobile station by a wireless local area network |
US7177399B2 (en) | 2004-02-27 | 2007-02-13 | Nortel Network Limited | Determining the geographical location from which an emergency call originates in a packet-based communications network |
KR100842548B1 (ko) * | 2004-03-05 | 2008-07-01 | 삼성전자주식회사 | 긴급 호출 시스템 및 그 제어 방법 |
US8145182B2 (en) * | 2004-05-07 | 2012-03-27 | Interdigital Technology Corporation | Supporting emergency calls on a wireless local area network |
US20060068799A1 (en) | 2004-09-27 | 2006-03-30 | T-Mobile, Usa, Inc. | Open-host wireless access system |
JP2006101421A (ja) * | 2004-09-30 | 2006-04-13 | Toshiba Corp | 映像信号処理回路 |
US7433673B1 (en) * | 2004-12-17 | 2008-10-07 | Sprint Spectrum L.P. | Method and system for providing location information for a wireless local area network (WLAN) |
US7496182B2 (en) * | 2005-04-15 | 2009-02-24 | Verizon Business Global Llc | Handling emergency service calls originating from internet telephony |
US20060274729A1 (en) * | 2005-06-03 | 2006-12-07 | Michael Self | Apparatus and method for connecting a voice over IP telephone subscriber to the 911 emergency network |
-
2006
- 2006-04-29 EP EP06360015A patent/EP1850532B1/en active Active
- 2006-04-29 PL PL06360015T patent/PL1850532T3/pl unknown
- 2006-04-29 ES ES06360015T patent/ES2381392T3/es active Active
- 2006-04-29 AT AT06360015T patent/ATE551799T1/de active
-
2007
- 2007-03-26 JP JP2009508276A patent/JP4913209B2/ja active Active
- 2007-03-26 WO PCT/EP2007/052843 patent/WO2007124987A1/en active Application Filing
- 2007-03-26 KR KR1020087026559A patent/KR101226042B1/ko active IP Right Grant
- 2007-04-05 US US11/697,288 patent/US7877785B2/en active Active
- 2007-04-29 CN CN2007101077689A patent/CN101064655B/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
PL1850532T3 (pl) | 2012-10-31 |
WO2007124987A1 (en) | 2007-11-08 |
JP4913209B2 (ja) | 2012-04-11 |
EP1850532A1 (en) | 2007-10-31 |
US20080016556A1 (en) | 2008-01-17 |
CN101064655B (zh) | 2013-04-24 |
KR101226042B1 (ko) | 2013-01-24 |
KR20090008302A (ko) | 2009-01-21 |
CN101064655A (zh) | 2007-10-31 |
EP1850532B1 (en) | 2012-03-28 |
JP2009535948A (ja) | 2009-10-01 |
ATE551799T1 (de) | 2012-04-15 |
US7877785B2 (en) | 2011-01-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2381392T3 (es) | Procedimiento de provisión a un terminal visitador de un acceso de emergencia sobre una WLAN | |
US9826376B2 (en) | Supporting emergency calls on a wireless local area network | |
JP4820346B2 (ja) | ワイヤレス・ローカル・エリア・ネットワークにおける緊急呼のサポート | |
US20080009262A1 (en) | Method and apparatus for supporting an emergency call in a wireless metropolitan area network |