ES2240910T3 - Aparato y metodo para optimizar el trafico de red. - Google Patents

Aparato y metodo para optimizar el trafico de red.

Info

Publication number
ES2240910T3
ES2240910T3 ES03100141T ES03100141T ES2240910T3 ES 2240910 T3 ES2240910 T3 ES 2240910T3 ES 03100141 T ES03100141 T ES 03100141T ES 03100141 T ES03100141 T ES 03100141T ES 2240910 T3 ES2240910 T3 ES 2240910T3
Authority
ES
Spain
Prior art keywords
server
program
message
request
local
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.)
Expired - Lifetime
Application number
ES03100141T
Other languages
English (en)
Inventor
Frederic Vignaud
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Societe Francaise du Radiotelephone SFR SA
Original Assignee
Societe Francaise du Radiotelephone SFR SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Societe Francaise du Radiotelephone SFR SA filed Critical Societe Francaise du Radiotelephone SFR SA
Application granted granted Critical
Publication of ES2240910T3 publication Critical patent/ES2240910T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58Message adaptation for wireless communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/289Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62Establishing a time schedule for servicing the requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Road Signs Or Road Markings (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procedimiento de optimización de un tráfico (103) de red que comprende un cliente (101) móvil y un servidor (115) de servicio. Este procedimiento abarca las siguientes etapas: - una aplicación (108) cliente, ejecutada por el cliente móvil, emite (201) una primera petición destinada al servidor de servicio, - un programa (109) servidor local, ejecutado por el cliente móvil, intercepta (202) la primera petición destinada al servidor de servicio, se caracteriza también el procedimiento por abarcar las siguientes etapas: - el programa servidor local, dirigido por un servidor controlador de red, produce (202) un mensaje de inicialización a partir del contenido de la primera petición. Este mensaje de inicialización contiene datos que permiten a un servidor controlador hacerse pasar por la aplicación cliente. Estos datos incluyen el identificador (111) y una contraseña (112). El mensaje de inicialización también contiene datos (113) acerca de un servidor de servicio al que se consultará, como su dirección en la red y su tipo, - el programa servidor local emite (202) el mensaje de inicialización destinado al servidor (122) controlador, - el servidor controlador de red recibe (204) el mensaje de inicialización y se programa (204) en función del contenido de dicho mensaje para emitir (209) peticiones destinadas al servidor de servicio.

Description

Aparato y método para optimizar el tráfico de red.
El invento tiene por objeto un procedimiento de optimización de un tráfico de red y dispositivos de puesta en práctica asociados. El invento se inscribe dentro del ámbito de las redes de telecomunicaciones y de los servicios accesibles a través de dichas redes. Más concretamente, el invento se inscribe dentro del ámbito del acceso a servicios, a través de las redes, utilizando clientes móviles. Un cliente móvil es un aparato inteligente capaz de iniciar un programa de comunicación para acceder a una o varias redes de telecomunicaciones y, de esta forma, conectarse a un servidor correspondiente a un servicio al que el usuario del cliente móvil está abonado.
Una finalidad del invento consiste en reducir el flujo de datos que recibe y emite el cliente móvil para acceder a los distintos servicios a los que está abonado su usuario.
Otra finalidad del invento es la de reducir la actividad radioeléctrica de un cliente móvil.
Otra finalidad del invento es la de reducir el consumo de energía de un cliente móvil.
En el estado de la técnica, se conocen distintos métodos para tratar de resolver estos problemas. Un primer método se conoce por la denominación de "optimización de los protocolos de enrutamiento". Un protocolo de enrutamiento, o un protocolo en general, define unos formatos para los intercambios de datos entre dos aparatos que se comunican a través de una red. Un protocolo define principalmente cuáles son los datos que se transmiten a través de las tramas o de los mensajes. La optimización de un protocolo, en el estado de la técnica, resulta en la reducción del tamaño de las tramas emitidas. Se trata en realidad de una racionalización de los datos transmitidos. Se intenta asegurar que se dejen de transmitir datos redundantes o superfluos en el contexto de emisión del mensaje o la trama.
Otra solución que se aplica es la utilización de memoria caché. Una memoria caché es una memoria que conserva el rastro de las operaciones más recientes que ha realizado el usuario del aparato donde se encuentra instalada dicha memoria. De este modo, si el usuario efectúa dos veces la misma petición, no es necesario volver a buscar la respuesta para dicha petición en la red, puesto que ésta ya se encuentra en la memoria caché. Esta solución no resulta adecuada, ya que la respuesta para una petición puede depender del momento en que se realiza la consulta. En la medida en que las memorias caché no están actualizadas, y con el objetivo de limitar el flujo de red, las respuestas a peticiones idénticas no siempre son pertinentes. Esta situación resulta especialmente cierta en aplicaciones de mensajería electrónica, por ejemplo. Un cliente, o una aplicación cliente, realiza consultas de forma regular para saber si se han recibido mensajes nuevos. La petición siempre es la misma, pero la respuesta no tiene por qué serlo. Por consiguiente, esta respuesta no puede guardarse en una memoria caché. Estas consultas periódicas se conocen también por el nombre de "polling".
Una tercera solución consiste en reducir el flujo comprimiendo los datos transmitidos. No obstante, con esta técnica se mantiene una actividad radioeléctrica y una ocupación de red elevadas. Además, origina cálculos suplementarios, puesto que es necesario comprimir y descomprimir los datos que se emiten y se reciben. Desde esta perspectiva, se gana algo en lo referente a la saturación de la red, pero en este caso, se pierde autonomía para un cliente móvil, puesto que las operaciones de compresión y descompresión requieren un elevado tiempo de ciclo en el microprocesador y, por consiguiente, consumen energía.
En el estado de la técnica, se conoce también el documento GB 2 327 829 A, que revela un procedimiento de gestión de las comunicaciones de un dispositivo móvil. Este método transforma estas comunicaciones sin reducirlas.
De las tres soluciones existentes en el estado de la técnica, ninguna reduce de forma significativa la actividad de red de un cliente, sobre todo de un cliente móvil, ninguna resuelve un problema relacionado con una consulta frecuente a un servidor y, por consiguiente, ninguna resuelve el problema del consumo.
Así, el problema que persiste en numerosos protocolos de redes es que el cliente envía de forma periódica al servidor peticiones para que se le informe de la modificación de un contexto en el servidor. Este flujo periódico de peticiones resulta costoso en términos de banda pasante y un objetivo esencial del invento consiste precisamente en reducir dicho flujo de red.
En el invento, estos problemas se resuelven controlando el flujo de red generado por el cliente con destino a un servidor de servicio mediante un programa servidor local, también conocido como "proxy", integrado en el aparato cliente y dirigido a su vez por un servidor controlador de red. El programa servidor local se encuentra instalado en el aparato cliente e intercepta todo el tráfico emitido / recibido por el aparato cliente.
Así, por una parte, el programa servidor local permite controlar el tráfico. Dicho control puede consistir en un modo de retransmisión mediante el cual, el programa servidor local transmite el mensaje iniciado por el cliente a un servidor sin realizar ningún otro tipo de procesamiento. El programa servidor local también puede funcionar en un modo de bloqueo, mediante el cual, bloquea los mensajes iniciados por el cliente con destino al servidor. En el modo de bloqueo, el programa servidor local responde al cliente que no se puede acceder al servidor de servicio o que éste se encuentra ocupado. Por último, el programa servidor local puede funcionar en un modo de inicialización en el que intercepta los mensajes iniciados por el cliente y los transmite a un servidor controlador de red, sin transmitirlos al servidor de servicio al que iba dirigido el mensaje en un principio.
Por otra parte, el programa servidor local cuenta con una función de comunicación con el servidor controlador de red. Dicha función permite intercambiar mensajes con el servidor controlador de red, lo que a su vez permite al servidor controlador de red accionar el modo de funcionamiento del programa servidor local.
El servidor controlador de red es un aparato conectado a la red y tiene principalmente dos funciones. La primera es una función de comunicación con un programa servidor local. La segunda es una función de consulta a un servidor de servicio, por ejemplo, consulta a un servidor de mensajería.
El principio del invento es el siguiente. En un primer momento, el programa servidor local se encuentra en un modo de inicialización. En este modo, intercepta los primeros mensajes emitidos por el cliente. Estos mensajes están destinados inicialmente a un servidor de servicio. El programa servidor local retransmite entonces dichos mensajes al servidor controlador de red. Al recibir estos mensajes, el servidor controlador de red se programa para poder establecer comunicación con el servidor de servicio en lugar de la aplicación cliente. Los mensajes recibidos por el servidor controlador durante la fase de inicialización incluyen de forma especial un identificador o "login" del usuario del aparato cliente, así como una contraseña que corresponde a la cuenta de dicho usuario en el servidor de servicio. Asimismo, los mensajes recibidos incluyen una indicación acerca de la frecuencia a la que se debe consultar al servidor de servicio. Por tanto, el servidor controlador está en disposición de programarse para efectuar las tareas de consulta de la aplicación cliente.
Después de la fase de inicialización, el programa servidor local pasa a modo de bloqueo. El programa servidor local permanece en modo de bloqueo hasta que recibe un mensaje del servidor controlador indicándole un cambio de contexto en el servidor de servicio. En este caso, el programa de servidor local pasa a modo de retransmisión y el cliente se encuentra en disposición de consultar al servidor de servicio. Un contexto incluye, por ejemplo, el número de mensajes no leídos, o mensajes nuevos, en un buzón electrónico.
Por consiguiente, el invento tiene por objeto un procedimiento de optimización de un tráfico de red que comprende un cliente móvil y un servidor de servicio. Este procedimiento se caracteriza por abarcar las siguientes etapas:
- una aplicación cliente, ejecutada por el cliente móvil, emite una primera petición destinada al servidor de servicio,
- un programa de servidor local, ejecutado por el cliente móvil, intercepta la primera petición destinada al servidor de servicio,
- el programa de servidor local produce un mensaje de inicialización a partir del contenido de la primera petición. Este mensaje de inicialización contiene datos que permiten a un servidor controlador hacerse pasar por la aplicación cliente, preferentemente un identificador y una contraseña. El mensaje de inicialización también contiene datos acerca de un servidor de servicio al que se consultará, preferentemente su dirección en la red y su tipo,
- el programa de servidor local emite el mensaje de inicialización destinado al servidor controlador,
- el servidor controlador recibe el mensaje de inicialización y se programa en función del contenido de dicho mensaje para emitir peticiones destinadas al servidor de servicio.
El invento también tiene por objeto un dispositivo cliente que se comunica a través de una red y que se caracteriza por contener una memoria de programa que incluye a su vez códigos de instrucción correspondientes a una aplicación cliente que emite peticiones a un servidor de servicio. La memoria de programa también incluye códigos de instrucción correspondientes a un programa de servidor local para interceptar y procesar mensajes emitidos por la aplicación cliente y para recibir y procesar mensajes emitidos por un servidor controlador.
El invento tiene asimismo por objeto un dispositivo servidor controlador que se comunica a través de una red y se caracteriza por contener una memoria de configuración para registrar datos de un mensaje de inicialización. El dispositivo servidor controlador también contiene una memoria de programa que incluye códigos de instrucción para emitir peticiones al servidor de servicio en función del contenido de la memoria de configuración. La memoria de programa contiene a su vez códigos de instrucción para emitir un mensaje de apertura y/o de estado a un programa de servidor local en función de la respuesta a una petición.
El invento se entenderá mejor después de leer la descripción siguiente y tras examinar las ilustraciones que le acompañan. Éstas se presentan a título indicativo y en modo alguno suponen una limitación del invento. Las ilustraciones muestran:
- ilustración 1: ilustración de medios útiles para la puesta en práctica del procedimiento según el invento.
- ilustración 2: ilustración de las etapas del procedimiento según el invento.
- ilustración 2bis: ilustración de las etapas del procedimiento según el invento.
La ilustración 1 muestra un aparato 101 cliente, o cliente 101, móvil. En la descripción, se considera que el cliente 101 móvil es un teléfono 101 móvil. El teléfono 101 incluye una antena 102 que le permite efectuar una conexión 103 radioeléctrica con una red 104 celular. El detalle de la red 104 no se muestra. Para la descripción, se considera que la red 104 incluye todos los elementos necesarios que permiten, por ejemplo, al teléfono 101 conectarse a Internet. De este modo, la red 104 comprende, entre otros elementos, una estación base a la que se conecta el teléfono 101 así como todos los dispositivos que permiten conectar la estación base a Internet.
El teléfono 101 incluye también unos circuitos electrónicos 105 conectados por una parte a la antena 102 y por otra, a un bus 106 interne del teléfono 101. La función de los circuitos 105 consiste en asegurar la interfaz de radio entre el teléfono 101 y la red 104. En la descripción, se ha elegido la norma GSM, pero podría tratarse perfectamente de otra norma, como la PCS, DCS, UMTS o cualquier otra norma radioeléctrica existente y/o futura.
En la descripción, las acciones se atribuyen a aparatos o a programas, lo que significa que estas acciones son ejecutadas por un microprocesador de dicho aparato o del aparato que contiene el programa. Por tanto, el microprocesador está accionado por códigos de instrucción registrados en una memoria del aparato. Estos códigos de instrucción permiten poner en práctica los medios del aparato y, por consiguiente, realizar la acción emprendida.
El teléfono 101 contiene un microprocesador 107 conectado al bus 106, así como las memorias 108 y 109 de programa. Las memorias 108 y 109 se representan separadas, aunque al igual que el resto de memorias del aparato, pueden unificarse en un único componente.
La memoria 108 contiene códigos de instrucción correspondientes a una aplicación cliente. Una aplicación de este tipo es, por ejemplo, un programa informático de mensajería electrónica. Este programa informático permite al teléfono 101 consultar una mensajería electrónica, es decir, un servidor de servicio, siendo la mensajería electrónica el servicio.
La memoria 109 se divide en varias zonas, cada una de las cuales corresponde a una función o a un modo de funcionamiento del programa de servidor local o "proxy". Por tanto, la memoria 109 corresponde en realidad al código de instrucción del programa de servidor local. Una zona 109a contiene códigos de instrucción para interceptar una consulta emitida, por ejemplo, por la aplicación 108 cliente. La zona 109b contiene códigos de instrucción correspondientes al funcionamiento en modo de inicialización. Una zona 109c contiene códigos de instrucción correspondientes al funcionamiento en modo de comunicación con el servidor controlador de red. Una zona 109d corresponde al funcionamiento del programa de servidor local en modo de retransmisión.
Las memorias 108 y 109 están conectadas al bus 106.
El teléfono 101 contiene también otras memorias de configuración. Una memoria 110 permite registrar uno o varios identificadores / direcciones del teléfono 101 para sus comunicaciones con un servidor controlador de red o un servidor de servicio. Un identificador / dirección es, por ejemplo, una dirección de Internet IPv4 (protocolo de Internet versión 4) o una dirección de Internet IPv6. También puede ser un número de teléfono que permita identificar el teléfono 101 en la red celular a la que está abonado el usuario del mismo. Este último identificador / dirección se utiliza, por ejemplo, en comunicaciones a través de mensajes cortos.
Una memoria 111 permite registrar un identificador del usuario al conectarse a un servidor de servicio. Un identificador 111 está asociado a una contraseña 112 registrada en la memoria 112. Una memoria 113 permite registrar la dirección de un servidor de servicio. Una dirección de este tipo es, o bien una dirección de Internet según un protocolo IP o una dirección URL para Universal Resource Locator (Localización Universal de Recursos). Por último, una memoria 114 permite registrar una frecuencia de consulta a un servidor de servicio.
Las memorias 110 a 114 están conectadas al bus 106.
En la práctica, las memorias 110 a 114 permiten registrar los parámetros de la aplicación 108 cliente. La aplicación 108 precisa de la dirección 113 para emitir peticiones a un servidor de servicio, así como un identificador 111 y una contraseña 112 para ser reconocida en dicho servidor de servicio. También necesita una dirección 110 para que el servidor de servicio pueda responder a la petición de la aplicación 108.
La ilustración 1 muestra también un servidor 115 de servicio. El servidor 115 está conectado a la red 104 a través de los circuitos 116 de interfaz de conexión. Por otra parte, los circuitos 116 están conectados a un bus 117 interno del servidor 115 de servicio. El servidor 115 de servicio contiene además un microprocesador 118 y una memoria 119 de programa. El servidor 115 contiene también una memoria 120 de almacenamiento para registrar mensajes electrónicos y una memoria 121 de identificación para identificar a las personas que se conectan al servidor 115. Los elementos 118 a 121 se conectan al bus 117.
La memoria 119 contiene códigos de instrucción que permiten al servidor 115 gestionar las peticiones que recibe por parte de distintos clientes, especialmente de las aplicaciones cliente como la aplicación 108.
Por ejemplo, la memoria 121 está estructurada en una tabla 121. Cada línea de la tabla 121 correspondía a una persona, mientras que cada columna de la tabla 121 correspondería a un dato acerca de dicha persona. Así, la memoria 121 contiene una columna 121a que corresponde a una dirección electrónica, una columna 121b que corresponde a un identificador o "login" y una columna 121c que corresponde a una contraseña.
La ilustración 1 muestra también un servidor 122 controlador de red. El servidor 122 está conectado a la red 104 a través de los circuitos 123 de interfaz de red. Por otra parte, los circuitos 123 están conectados a un bus 124 interno del servidor 122 controlador de red.
El servidor 122 controlador de red contiene un microprocesador 125, una memoria 126 de programa y una memoria 127 de configuración. Los elementos 125 a 127 están conectados al bus 124.
La memoria 126 contiene códigos de instrucción que dirigen el microprocesador 125. Una zona 126a contiene los códigos de instrucción que permiten al servidor 122 consultar a un servidor de servicio como el servidor 115. Una zona 126b contiene códigos de instrucción que permiten al servidor 122 comunicarse con el programa 109 servidor local. Una zona 126c contiene códigos de instrucción que corresponden a la gestión de mensajes de inicialización emitidos por un programa servidor local.
La memoria 127 de inicialización está estructurada en la tabla 127. Por ejemplo, cada columna corresponde a una persona, mientras que cada línea corresponde a un dato acerca de dicha persona. La memoria 127 contiene una línea 127a que corresponde a un identificador de una persona, por ejemplo, un número de teléfono o una dirección de Internet. Una línea 127b corresponde a un identificador como el de la memoria 111. Una línea 127c corresponde a una contraseña, una línea 127d corresponde a la dirección de un servidor de servicio y una línea 127e corresponde a una frecuencia de consulta a un servidor de servicio.
El conjunto de los elementos de la ilustración 1 se pone en práctica mediante el procedimiento según el invento.
La ilustración 2 demuestra que las etapas del procedimiento según el invento se llevan a cabo en varios aparatos. Los tres aparatos que intervienen son, por una parte, un cliente 101 móvil, un servidor 122 controlador de red y un servidor 115 de servicio. Para la descripción de las etapas del procedimiento según el invento, se ha elegido un servidor de mensajería electrónica. Cada uno de estos aparatos lleva a cabo determinadas acciones.
La ilustración 2 muestra también que en el cliente 101, o teléfono 101, móvil coexisten dos aplicaciones, cada una de las cuales lleva a cabo a su vez etapas del procedimiento según el invento. En el teléfono 101 móvil, se distingue por tanto una aplicación cliente, por ejemplo, una aplicación que sirve para consultar a un servidor de mensajería electrónica y una aplicación, o programa, servidor local conocido también con el nombre de "proxy". Por consiguiente, estos dos programas ponen en práctica las etapas del procedimiento según el invento.
La ilustración 2 muestra una primera etapa preliminar 201 de emisión de una petición inicial de consulta por parte de la aplicación 108 cliente. Dicha petición se establece según un protocolo de mensajería electrónica. Un ejemplo de estos protocolos son POP e IMAP. Estas peticiones de consulta contienen un identificador del servidor al que van dirigidas, el identificador de la persona que emite la petición, una contraseña de esta persona y un identificador para responder a la petición. Se trata en realidad de los parámetros de configuración de la aplicación 108. En nuestro ejemplo, la dirección del servidor de servicio corresponde a la dirección del servidor 115 y es una dirección de Internet. El identificador de la persona corresponde al contenido de la memoria 111 y la contraseña, al contenido de la memoria 112. La dirección para la respuesta puede estar incluida en el protocolo de enrutamiento, si se trata del protocolo IP, o bien presente de forma expresa en la petición.
Una vez establecida, la petición se emite. En este punto, en la etapa 201, por "se emite" hay que entender que se somete al microprocesador con la instrucción de emitirla a través de los medios radioeléctricos 105 y 102.
No obstante, el microprocesador también está dirigido por el programa 109 servidor local. Así pues, el microprocesador sabe que debe interceptar todas las peticiones y demás mensajes que han de ser emitidos por medios radioeléctricos. De este modo, se pasa a una etapa 202 de producción y de emisión de un mensaje de inicialización. En esta etapa 202, los códigos de instrucción de la zona 109a dirigen el microprocesador 107. Esto permite al programa 109 servidor local interceptar la petición emitida por la aplicación 108. El programa 109 servidor local determina entonces que se trata de la emisión de una primera petición. Esta detección resulta relativamente sencilla. Por ejemplo, basta con utilizar una memoria semáforo que permita memorizar si una petición ya ha sido emitida o no por la aplicación 108. Si la memoria semáforo indica que no se ha emitido ninguna petición, el programa 109 servidor local sabe que se trata de una fase de inicialización, por lo que lleva a cabo dicha reinicialización y valida la memoria semáforo. En caso contrario, el programa 109 servidor local sabe que no se trata de una fase de inicialización.
En la etapa 202, el microprocesador también está dirigido por los códigos de instrucción de la zona 109b. En la etapa 202, el microprocesador 107 establece un mensaje de inicialización que contiene la petición 101. Este mensaje de inicialización se emite entonces con destino al servidor 122 controlador de red. En la etapa 202, "emisión" significa que el mensaje de inicialización se difunde de forma radioeléctrica por los medios radioeléctricos del teléfono 101.
De la etapa 202 se pasa, por una parte, a una etapa 203 de respuesta a la primera petición, y por otra parte, a una etapa 204 de programación del servidor 122 controlador de red.
La etapa 203 la lleva a cabo el programa 109 servidor local. En la etapa 203, el microprocesador 107 elabora entonces una respuesta para la petición emitida en la etapa 201 por la aplicación 108. Se trata de una respuesta estándar definida por el protocolo empleado, ya sea POP o IMAP y que indica, por ejemplo, que no se puede acceder al servidor 115 de servicio o que éste se encuentra ocupado. Esta respuesta también puede indicar que no hay ningún mensaje nuevo. El propósito de esta respuesta consiste en engañar a la aplicación 108. Ésta debe pensar que ha establecido una comunicación con el servidor 115 de servicio. Una vez elaborada la respuesta para la petición 1, ésta se emite en el mismo sentido que la emisión de la etapa 201, es decir, que dicha respuesta no saldrá nunca del teléfono 101. De la etapa 203, se pasa a una etapa 205 de recepción de respuesta a la primera petición. En la etapa 205, la aplicación 108 recibe una respuesta formateada según el protocolo empleado para emitir la petición en la etapa 201. Esta respuesta se ajusta a lo que espera la aplicación 108, que procesa dicha respuesta como si hubiera sido emitida por el servidor 115.
En la etapa 204, el servidor 122 controlador de red recibe un mensaje de inicialización. Este mensaje de inicialización permite al microprocesador 125 actualizar la memoria 127 de configuración. En la etapa 204, el microprocesador 125 está dirigido por los códigos de instrucción de las zonas 126b y 126c. En la etapa 204, el microprocesador 125 utiliza los datos contenidos en el mensaje de inicialización para actualizar la memoria 127. Dicha actualización consiste en la creación de una nueva columna y en la indicación de los campos / líneas de la nueva columna.
La información de frecuencia de consulta bien se obtiene gracias al intervalo de tiempo que separa las dos primeras peticiones emitidas por la aplicación 108 o bien es leída directamente en la memoria 114 por el programa 109 servidor local. Esta frecuencia de consulta se inserta en el mensaje de inicialización de la etapa 202.
Los campos completados son los mismos que ya se expusieron anteriormente para las etapas 201, 202 y en la descripción de los medios puestos en práctica por el procedimiento según el invento.
Las etapas 201 a 205 constituyen una fase de inicialización del procedimiento según el invento. Durante esta fase, el programa servidor local 109 funciona en modo de inicialización.
De la etapa 205, la aplicación 108 pasa a una etapa 206 donde se emite una segunda petición de consulta al servidor 115 de servicio. Esta segunda petición es idéntica a la que se emitió durante la etapa 201. Por consiguiente, dicha petición se emite de la misma forma que en la etapa 201. Desde el punto de vista de la aplicación 108, la etapa 206 es idéntica a la etapa 201. Se pasa entonces a una etapa 207 puesta en práctica por el programa 109 servidor local.
En la etapa 207, el programa 109 intercepta la segunda petición de la misma forma que en la etapa 202. Emite entonces una respuesta a la segunda petición, simulando de este modo que el servidor 115 está ocupado, que no se puede tener acceso a él o, por ejemplo, que no hay ningún mensaje nuevo. Se pasa así a una etapa 208, puesta en práctica por la aplicación 108, de recepción de la respuesta a la segunda petición. La etapa 208 es idéntica a la etapa 205.
En la práctica, el intervalo de tiempo que separa la etapa 201 de la etapa 206 está regido por el contenido de la memoria 114 correspondiente a la frecuencia de consulta, por parte de la aplicación 108, al servidor 115 de servicio.
Las etapas 206 a 208 muestran el funcionamiento del programa 109 servidor local en modo de bloqueo. En este modo de bloqueo, el programa 109 intercepta todos los mensajes emitidos por la aplicación 108 y le transmite una respuesta indicándole que no existe ningún cambio de contexto en el servidor 115. En el modo de bloqueo, no tiene lugar ninguna emisión radioeléctrica como consecuencia de una consulta al servidor 115.
De la etapa 204, el servidor 122 controlador de red pasa a una etapa 209 de consulta a los servidores de servicios.
En la etapa 209, el microprocesador 125, dirigido por los códigos de instrucción de la zona 126a, examina la tabla 127 para determinar el servidor de servicio al que debe consultar. Esta decisión se realiza con respecto a un reloj interno, no representado, del servidor 122 y con respecto a los datos de frecuencia de consulta de la línea 127e.
Cuando el microprocesador 125 encuentra, en la tabla 127, una consulta que realizar, éste emplea los datos de la columna en cuestión para emitir una petición de consulta al servidor de servicio. Para elaborar esta petición, utiliza los datos incluidos en la columna, en concreto, el identificador 127b, la contraseña 127c y la dirección 127d del servidor de servicio. La petición de consulta al servidor 115 de servicio elaborada en la etapa 209 por el controlador 122 de red es idéntica a la petición de consulta elaborada en las etapas 201 y 206, salvo que la dirección de respuesta para el servidor 115 de servicio es la del servidor 122 controlador de red.
Para la consulta a un servidor de mensajería, el protocolo utilizado es preferentemente IMAP. Este protocolo permite emitir peticiones para obtener información acerca del número de mensajes nuevos presentes en un buzón electrónico. Esto permite aligerar las comunicaciones entre el servidor 122 y el servidor 115.
Las peticiones de consulta emitidas por el servidor 122 circulan a través de la red 104 hasta el servidor 115. Se pasa de una etapa 209 a la etapa 210 de respuesta del servidor 115 de servicio.
En la etapa 210, el servidor 115 recibe una petición de consulta para conocer el estado de un buzón electrónico. Este buzón electrónico está identificado por un "login" 127b/111 y una contraseña 127c/112. Estos datos permiten al microprocesador 118 determinar una línea dentro de la tabla 121 y, por consiguiente, una cuenta de mensajería. Esta dirección permite al microprocesador 118 localizar los mensajes correspondientes en la memoria de almacenamiento 120. Posteriormente, el servidor 115 elabora una respuesta a la petición de consulta emitida en la etapa 209. Dicha respuesta se envía a la dirección del servidor que haya emitido la petición, es decir, a la dirección del servidor 122. De la etapa 210, se pasa a una etapa 211 de análisis de la respuesta del servidor 115 por parte del servidor 122.
En la etapa 211, el microprocesador 125 determina si existen nuevos mensajes en el buzón consultado. Esta determinación se lleva a cabo en función del contenido de la respuesta del servidor 115 a la petición emitida en la etapa 209. Se trata de una petición según el protocolo IMAP para conocer el número de mensajes nuevos contenidos en un buzón electrónico. La respuesta contiene así un número de mensajes nuevos. Si dicho número es 0, significa que no hay ningún mensaje nuevo. En caso de no haber mensajes nuevos, se pasa otra vez a la etapa 209 y las consultas se suceden. Si hay al menos un mensaje nuevo, se pasa a una etapa 212 de apertura del "proxy".
En la etapa 212, el microprocesador 125 elabora un mensaje para abrir el "proxy". El destinatario de este mensaje se determina gracias al contenido de la memoria 127. Así pues, a partir de un identificador 127b y de una contraseña 127c, el microprocesador 125 es capaz de determinar un identificador 127a de un teléfono 101. Dicho identificador es, o bien una dirección de Internet o, por ejemplo, un número de teléfono que permite la emisión de un mensaje corto.
El mensaje de apertura del "proxy" es, por tanto, un simple mensaje dirigido al programa 109 servidor local que contiene un código de instrucción que indica la necesidad de cambiar el modo de funcionamiento del programa 109 servidor local. Se pasa entonces a una etapa 213 de apertura del "proxy".
En la etapa 213, el programa 109 servidor local recibe el mensaje emitido en la etapa 212. En este caso, el programa 109 servidor local sabe que ya no debe bloquear los mensajes emitidos por la aplicación 108. El programa 109 servidor local pasa entonces a modo de retransmisión.
De la etapa 208, la aplicación 108 pasa a una etapa 214 donde se emite una tercera petición. Para la descripción, se considera que la etapa 214 es posterior a la etapa 213. Es decir, que en el momento en que tiene lugar la etapa 214, el programa 109 se encuentra en modo de retransmisión. La etapa 214 es idéntica a las etapas 201 y 206. De la etapa 214, se pasa a una etapa 215 de retransmisión de la petición. La etapa 215 la pone en práctica el programa 109 servidor local. En esta etapa, el programa 109 servidor local se comporta como la aplicación 108, es decir, que emite, esta vez de forma radioeléctrica, la petición de consulta. Se pasa entonces a una etapa 216 de respuesta del servidor 115 de servicio.
Cuando se comporta en modo de retransmisión, el programa 109 del servidor local ya no desvía las peticiones emitidas por la aplicación 108 hacia el servidor 122 controlador de red. Se comporta más bien como un simple intermediario en el despacho de los mensajes y deja de intervenir en su contenido y su destinatario. En la etapa 216, el servidor 115 recibe una petición de consulta de un buzón electrónico clásico y responde a ella de la forma conocida. Esta respuesta es interceptada, en la etapa 217, por el programa 109 servidor local. Una vez más, el programa 109 se encuentra en modo de retransmisión, por lo que vuelve a transmitir la respuesta del servidor 115 directamente a la aplicación 108. Es la etapa 218 del procesamiento, por parte de la aplicación 108, de la respuesta del servidor 115 a la petición emitida en la etapa 214. Se trata de una etapa clásica y conocida.
De la etapa 217, el programa 109 servidor local pasa también a una etapa 219 que consiste en que comienza a funcionar de nuevo en modo de bloqueo, tal y como ya se ha descrito para las etapas 206 a 208.
La ilustración 2bis muestra que la etapa 209 también puede ir seguida de una etapa 220 en la que se emite un mensaje de estado. En realidad, la etapa 220 puede llevarla a cabo en cualquier momento el servidor 122 controlador de red. Se trata de la emisión de un mensaje de estado destinado al programa 109 servidor local. La etapa 220 aparece, en condiciones óptimas, en intervalos regulares. Un mensaje de estado tiene la finalidad de indicar a un programa servidor local que el servidor 122 continúa consultando al servidor 115. De la etapa 220, se pasa a una etapa 221 en la que la aplicación 109 servidor local recibe el mensaje de estado. En la etapa 221, el programa 109 determina si es necesario seguir consultando o no al servidor 115. En caso afirmativo, se pasa a una etapa 222 donde se prosigue la consulta. La etapa 222 consiste en dar una respuesta positiva al mensaje de estado. El programa 109 servidor local emite entonces una respuesta de continuación de la consulta destinada al servidor 122 controlador de red. Si no es necesaria la respuesta, se pasa a una etapa 223 de fin de la consulta.
En la etapa 223, no se emite ninguna respuesta al mensaje de estado. En este caso, el controlador 122 de red detecta que no se ha recibido ninguna respuesta a su mensaje de estado y actualiza su configuración. Es la etapa 224.
La etapa 224 consiste en borrar una columna de la memoria 127. Dicha columna corresponde al identificador 127a, para el cual no se ha recibido ninguna respuesta a un mensaje de estado. En la práctica, se puede considerar que un mensaje de apertura de "proxy" es un mensaje de estado, pero no se trata del único mensaje de estado posible.
Un mensaje de estado también puede contener información según la cual no se ha recibido ningún mensaje nuevo desde el último mensaje de estado.
En la práctica, el cambio de modo de funcionamiento del programa 109 servidor local también puede estar provocado al vencimiento de un plazo. Por ejemplo, si hace un determinado tiempo que el programa 109 servidor local no recibe un mensaje de estado por parte del servidor 122, el programa 109 servidor local puede considerar que el servidor 122 controlador de red ya no se encuentra activo. En este caso, el propio programa 109 servidor local pasa a modo de retransmisión. En modo de retransmisión, el programa 109 servidor local ya no responde a los mensajes de estado del servidor 122 controlador de red.
El paso de un modo a otro puede forzarlo también el usuario del teléfono 101.
Con la puesta en práctica del invento, se observa que las conexiones efectivas entre los teléfonos 101 y el servidor 115 de servicio sólo tienen lugar cuando resultan realmente útiles, es decir, cuando hay mensajes nuevos para consultar en el ámbito de un servidor de mensajería.
Se puede trasladar fácilmente el método del invento a todas las comunicaciones con un cliente móvil antes de consultar periódicamente a un servidor para detectar un cambio de contexto en el mismo. En este caso, las consultas periódicas las realiza el servidor 122 controlador de red y no el teléfono 101. De esta forma, se evita sobrecargar la parte de radiofrecuencia de la red y desperdiciar inútilmente la energía del teléfono 101 móvil.
En una variante del invento, cuando el servidor 122 detecta un cambio de contexto en el servidor 115, el servidor 122 restablece este nuevo contexto, por ejemplo, los mensajes nuevos en el servidor 122. El restablecimiento de los mensajes al teléfono 101 no se produce entonces entre el teléfono 101 y el servidor 115, sino entre el teléfono 101 y el servidor 122.
Se pueden contemplar perfectamente protocolos de comunicación distintos entre, en primer lugar, la aplicación 108 y el servidor 115 y, en segundo lugar, entre el programa 109 servidor local y el servidor 122 controlador de red. Así pues, el servidor 122 controlador de red es inducido a emitir mensajes al teléfono 101, que no se encuentra conectado a Internet permanentemente, sobre todo en la norma IPv4. Esto significa que el teléfono 101 no dispone de una dirección de Internet válida de forma permanente. En ese caso, se puede utilizar el protocolo de mensajes cortos, por ejemplo, para establecer una comunicación entre el teléfono 101 y el servidor 122. El resto de comunicaciones del teléfono 101 son todas de salida, por lo que pueden efectuarse tras una conexión a Internet del teléfono 101 iniciada por éste último.

Claims (9)

1. Procedimiento de optimización de un tráfico (103) de red que comprende un cliente (101) móvil y un servidor (115) de servicio. Este procedimiento abarca las siguientes etapas:
- una aplicación (108) cliente, ejecutada por el cliente móvil, emite (201) una primera petición destinada al servidor de servicio,
- un programa (109) servidor local, ejecutado por el cliente móvil, intercepta (202) la primera petición destinada al servidor de servicio,
se caracteriza también el procedimiento por abarcar las siguientes etapas:
- el programa servidor local, dirigido por un servidor controlador de red, produce (202) un mensaje de inicialización a partir del contenido de la primera petición. Este mensaje de inicialización contiene datos que permiten a un servidor controlador hacerse pasar por la aplicación cliente. Estos datos incluyen el identificador (111) y una contraseña (112). El mensaje de inicialización también contiene datos (113) acerca de un servidor de servicio al que se consultará, como su dirección en la red y su tipo,
- el programa servidor local emite (202) el mensaje de inicialización destinado al servidor (122) controlador,
- el servidor controlador de red recibe (204) el mensaje de inicialización y se programa (204) en función del contenido de dicho mensaje para emitir (209) peticiones destinadas al servidor de servicio.
2. Procedimiento según la reivindicación 1, caracterizado por abarcar las siguientes etapas:
- la aplicación cliente emite (206) una segunda petición destinada al servidor de servicio,
- el programa servidor local intercepta (207) la segunda petición e interrumpe su despacho,
- el programa servidor local produce y emite (207) una respuesta a la aplicación cliente,
- la aplicación cliente recibe (208) la respuesta del programa servidor local.
3. Procedimiento según una de las reivindicaciones 1 ó 2, caracterizado por abarcar las siguientes etapas:
- el servidor controlador emite (209) una petición al servidor de servicio haciéndose pasar por la aplicación cliente,
- el servidor de servicio recibe (210) la petición del servidor controlador y responde a ella (210),
- el servidor controlador recibe la respuesta y emite (212) un mensaje de apertura destinado al programa servidor local,
- el programa servidor local recibe (213) el mensaje de apertura y se programa en consecuencia,
- la aplicación cliente emite (214) una tercera petición destinada al servidor de servicio,
- el programa servidor local intercepta (215) la tercera petición y la retransmite hacia el servidor de servicio,
- el servidor de servicio recibe y procesa (216) la tercera petición.
4. Procedimiento según la reivindicación 3, caracterizado porque el programa servidor local bloquea (207) las peticiones de la aplicación cliente hasta que el programa servidor local recibe un mensaje de apertura por parte del servidor controlador.
5. Procedimiento según una de las reivindicaciones 1 a 4, caracterizado porque el programa servidor local bloquea las peticiones de la aplicación cliente hasta el vencimiento de un periodo de tiempo predefinido.
6. Procedimiento según una de las reivindicaciones 1 a 5, caracterizado por abarcar las siguientes etapas:
- el servidor controlador emite (220) un mensaje de estado al programa servidor local,
- el servidor controlador interrumpe (224) la emisión de petición hacia el servidor de servicio si no recibe ninguna respuesta, correspondiente al mensaje de estado, por parte del programa servidor local.
7. Procedimiento según una de las reivindicaciones 1 a 6, caracterizado porque la aplicación cliente es una aplicación cliente de mensajería electrónica y el servidor de servicio es un servidor de mensaje-
ría.
8. Dispositivo cliente, para la comunicación a través de una red y la puesta en práctica de las etapas del procedimiento según una de las reivindicaciones 1 a 7. El dispositivo cliente contiene una memoria (108) de programa que incluye a su vez códigos de instrucción correspondientes a una aplicación cliente que emite peticiones a un servidor de servicio. La memoria (109) de programa también incluye códigos de instrucción correspondientes a un programa servidor local para interceptar y procesar mensajes emitidos por la aplicación cliente. Se caracteriza porque la memoria de programa incluye igualmente códigos de instrucciones para recibir y procesar mensajes emitidos por un servidor controlador de red. Éste último dirige además el programa servidor
local.
9. Dispositivo servidor controlador, para la comunicación a través de una red y para la puesta en práctica de las etapas del procedimiento según una de las reivindicaciones 1 a 7. Se caracteriza por contener una memoria (127) de configuración para registrar datos de un mensaje de inicialización. El dispositivo servidor controlador también contiene una memoria (126) de programa que incluye códigos de instrucción para emitir peticiones al servidor de servicio en función del contenido de la memoria de configuración. La memoria de programa contiene a su vez códigos de instrucción para emitir un mensaje de apertura y/o de estado a un programa servidor local en función de la respuesta a una petición. El programa servidor local está dirigido entonces por el servidor controlador de red.
ES03100141T 2002-03-05 2003-01-23 Aparato y metodo para optimizar el trafico de red. Expired - Lifetime ES2240910T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0202806 2002-03-05
FR0202806A FR2837042B1 (fr) 2002-03-05 2002-03-05 Procede d'optimisation d'un trafic reseau et dispositif de mise en oeuvre associe

Publications (1)

Publication Number Publication Date
ES2240910T3 true ES2240910T3 (es) 2005-10-16

Family

ID=27741446

Family Applications (1)

Application Number Title Priority Date Filing Date
ES03100141T Expired - Lifetime ES2240910T3 (es) 2002-03-05 2003-01-23 Aparato y metodo para optimizar el trafico de red.

Country Status (8)

Country Link
US (1) US7228330B2 (es)
EP (1) EP1343291B1 (es)
AT (1) ATE292351T1 (es)
DE (1) DE60300432T2 (es)
DK (1) DK1343291T3 (es)
ES (1) ES2240910T3 (es)
FR (1) FR2837042B1 (es)
PT (1) PT1343291E (es)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060195595A1 (en) * 2003-12-19 2006-08-31 Mendez Daniel J System and method for globally and securely accessing unified information in a computer network
US7305700B2 (en) 2002-01-08 2007-12-04 Seven Networks, Inc. Secure transport for mobile communication network
US7627679B1 (en) * 2003-12-30 2009-12-01 At&T Intellectual Property Ii, L.P. Methods and systems for provisioning network services
US7856493B1 (en) * 2004-03-17 2010-12-21 Cisco Technology, Inc. Method and apparatus providing device-initiated network management
DE502005000586D1 (de) * 2005-02-11 2007-05-24 1 2 Snap Ag Client mit Speicher zum selbstständigen Ablaufen einer Applikation unabhängig vom Server
US8438633B1 (en) 2005-04-21 2013-05-07 Seven Networks, Inc. Flexible real-time inbox access
WO2006136660A1 (en) 2005-06-21 2006-12-28 Seven Networks International Oy Maintaining an ip connection in a mobile network
US20070027669A1 (en) * 2005-07-13 2007-02-01 International Business Machines Corporation System and method for the offline development of passive simulation clients
US8805425B2 (en) 2007-06-01 2014-08-12 Seven Networks, Inc. Integrated messaging
US9002828B2 (en) 2007-12-13 2015-04-07 Seven Networks, Inc. Predictive content delivery
US8107921B2 (en) 2008-01-11 2012-01-31 Seven Networks, Inc. Mobile virtual network operator
US8862657B2 (en) 2008-01-25 2014-10-14 Seven Networks, Inc. Policy based content service
US20090193338A1 (en) 2008-01-28 2009-07-30 Trevor Fiatal Reducing network and battery consumption during content delivery and playback
US8909759B2 (en) 2008-10-10 2014-12-09 Seven Networks, Inc. Bandwidth measurement
US7974194B2 (en) * 2008-12-12 2011-07-05 Microsoft Corporation Optimizing data traffic and power consumption in mobile unified communication applications
US8645660B2 (en) 2009-12-10 2014-02-04 Microsoft Corporation Automatic allocation of data replicas
WO2012024030A2 (en) 2010-07-26 2012-02-23 Seven Networks, Inc. Context aware traffic management for resource conservation in a wireless network
GB2510493B (en) * 2010-07-26 2014-12-24 Seven Networks Inc Mobile application traffic optimization
WO2013015835A1 (en) 2011-07-22 2013-01-31 Seven Networks, Inc. Mobile application traffic optimization
WO2012018477A2 (en) * 2010-07-26 2012-02-09 Seven Networks, Inc. Distributed implementation of dynamic wireless traffic policy
US11595901B2 (en) 2010-07-26 2023-02-28 Seven Networks, Llc Optimizing mobile network traffic coordination across multiple applications running on a mobile device
US9043433B2 (en) 2010-07-26 2015-05-26 Seven Networks, Inc. Mobile network traffic coordination across multiple applications
US8838783B2 (en) 2010-07-26 2014-09-16 Seven Networks, Inc. Distributed caching for resource and mobile network traffic management
WO2012018556A2 (en) * 2010-07-26 2012-02-09 Ari Backholm Mobile application traffic optimization
US8769299B1 (en) 2010-10-13 2014-07-01 The Boeing Company License utilization management system license wrapper
US9563751B1 (en) * 2010-10-13 2017-02-07 The Boeing Company License utilization management system service suite
WO2012060995A2 (en) 2010-11-01 2012-05-10 Michael Luna Distributed caching in a wireless network of content delivered for a mobile application over a long-held request
US8843153B2 (en) 2010-11-01 2014-09-23 Seven Networks, Inc. Mobile traffic categorization and policy for network use optimization while preserving user experience
GB2500327B (en) 2010-11-22 2019-11-06 Seven Networks Llc Optimization of resource polling intervals to satisfy mobile device requests
GB2501416B (en) 2011-01-07 2018-03-21 Seven Networks Llc System and method for reduction of mobile network traffic used for domain name system (DNS) queries
GB2505103B (en) 2011-04-19 2014-10-22 Seven Networks Inc Social caching for device resource sharing and management cross-reference to related applications
US20120278431A1 (en) 2011-04-27 2012-11-01 Michael Luna Mobile device which offloads requests made by a mobile application to a remote entity for conservation of mobile device and network resources and methods therefor
US8621075B2 (en) 2011-04-27 2013-12-31 Seven Metworks, Inc. Detecting and preserving state for satisfying application requests in a distributed proxy and cache system
WO2013015995A1 (en) 2011-07-27 2013-01-31 Seven Networks, Inc. Automatic generation and distribution of policy information regarding malicious mobile traffic in a wireless network
TWI434595B (zh) * 2011-11-09 2014-04-11 Quanta Comp Inc 網路系統之連線建立管理方法及其相關系統
EP2789138B1 (en) 2011-12-06 2016-09-14 Seven Networks, LLC A mobile device and method to utilize the failover mechanisms for fault tolerance provided for mobile traffic management and network/device resource conservation
US8918503B2 (en) 2011-12-06 2014-12-23 Seven Networks, Inc. Optimization of mobile traffic directed to private networks and operator configurability thereof
US9277443B2 (en) 2011-12-07 2016-03-01 Seven Networks, Llc Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol
GB2498064A (en) 2011-12-07 2013-07-03 Seven Networks Inc Distributed content caching mechanism using a network operator proxy
WO2013090212A1 (en) 2011-12-14 2013-06-20 Seven Networks, Inc. Mobile network reporting and usage analytics system and method using aggregation of data in a distributed traffic optimization system
US9832095B2 (en) * 2011-12-14 2017-11-28 Seven Networks, Llc Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic
EP2801236A4 (en) 2012-01-05 2015-10-21 Seven Networks Inc DETECTION AND MANAGEMENT OF USER INTERACTIONS WITH FRONT PANEL APPLICATIONS ON A MOBILE DEVICE IN DISTRIBUTED CACHE STORES
US8812695B2 (en) 2012-04-09 2014-08-19 Seven Networks, Inc. Method and system for management of a virtual network connection without heartbeat messages
US10263899B2 (en) 2012-04-10 2019-04-16 Seven Networks, Llc Enhanced customer service for mobile carriers using real-time and historical mobile application and traffic or optimization data associated with mobile devices in a mobile network
KR101380072B1 (ko) 2012-07-02 2014-04-01 닉스테크 주식회사 로컬 프락시를 이용한 정보 유출 방지 시스템
US8775631B2 (en) 2012-07-13 2014-07-08 Seven Networks, Inc. Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications
US9161258B2 (en) 2012-10-24 2015-10-13 Seven Networks, Llc Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion
US9307493B2 (en) 2012-12-20 2016-04-05 Seven Networks, Llc Systems and methods for application management of mobile device radio state promotion and demotion
US9271238B2 (en) 2013-01-23 2016-02-23 Seven Networks, Llc Application or context aware fast dormancy
US8874761B2 (en) 2013-01-25 2014-10-28 Seven Networks, Inc. Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
US9326185B2 (en) 2013-03-11 2016-04-26 Seven Networks, Llc Mobile network congestion recognition for optimization of mobile traffic
US10216549B2 (en) 2013-06-17 2019-02-26 Seven Networks, Llc Methods and systems for providing application programming interfaces and application programming interface extensions to third party applications for optimizing and minimizing application traffic
WO2014204995A1 (en) * 2013-06-17 2014-12-24 Seven Networks, Inc. Methods and systems for providing application programming interfaces and application programming interface extensions to third party applications for optimizing and minimizing application traffic
US9065765B2 (en) 2013-07-22 2015-06-23 Seven Networks, Inc. Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network
US10664833B2 (en) 2014-03-05 2020-05-26 Mastercard International Incorporated Transactions utilizing multiple digital wallets

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5673322A (en) * 1996-03-22 1997-09-30 Bell Communications Research, Inc. System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks
US5948066A (en) * 1997-03-13 1999-09-07 Motorola, Inc. System and method for delivery of information over narrow-band communications links
GB9715966D0 (en) * 1997-07-30 1997-10-01 Ibm Data communications management for use with networking applications and for mobile communications environments
US20020002615A1 (en) * 1998-09-18 2002-01-03 Vijay K. Bhagavath Method and apparatus for switching between internet service provider gateways
US6507867B1 (en) * 1998-12-22 2003-01-14 International Business Machines Corporation Constructing, downloading, and accessing page bundles on a portable client having intermittent network connectivity
GB2366163A (en) * 2000-08-14 2002-02-27 Global Knowledge Network Ltd Inter-network connection through intermediary server
US6895444B1 (en) * 2000-09-15 2005-05-17 Motorola, Inc. Service framework with local proxy for representing remote services
US6895425B1 (en) * 2000-10-06 2005-05-17 Microsoft Corporation Using an expert proxy server as an agent for wireless devices
JP4409788B2 (ja) * 2001-05-10 2010-02-03 富士通株式会社 無線データ通信網切替装置と無線データ通信網切替処理用プログラム
US20030149720A1 (en) * 2002-02-06 2003-08-07 Leonid Goldstein System and method for accelerating internet access

Also Published As

Publication number Publication date
EP1343291B1 (fr) 2005-03-30
FR2837042A1 (fr) 2003-09-12
PT1343291E (pt) 2005-06-30
DE60300432D1 (de) 2005-05-04
EP1343291A1 (fr) 2003-09-10
ATE292351T1 (de) 2005-04-15
FR2837042B1 (fr) 2005-04-08
DE60300432T2 (de) 2006-02-16
US7228330B2 (en) 2007-06-05
US20030172112A1 (en) 2003-09-11
DK1343291T3 (da) 2005-05-30

Similar Documents

Publication Publication Date Title
ES2240910T3 (es) Aparato y metodo para optimizar el trafico de red.
US8707406B2 (en) Always-on virtual private network access
JP4846398B2 (ja) 通信システム
ES2296163T3 (es) Sistema y procedimiento de control de equipos a distancia con la ayuda de comandos at, dispositivo, modulo de radiocomunicacion y programa correspondientes.
EP1553499B8 (en) Communication system, relay device, and communication control method
US11057158B2 (en) Delegation of management of acknowledgements and of transmission of frames
CN108924165A (zh) 一种内网远程访问方法及其装置及内网网关
KR100388592B1 (ko) 가변 길이 응답으로 트랜잭션 요청을 지원하는 무선프로토콜 방법 및 장치
CN106792694B (zh) 一种接入认证方法,及接入设备
GB9914418D0 (en) Computer network payment system
KR100954815B1 (ko) 제 2 위치 요청 처리 장치로의 재전송을 위해 홈레지스터(hlr)에서 제 1 위치 요청 처리장치(게이트웨이 이동 위치 센터)에 의한 위치 요청 처리
US20160029214A1 (en) Home control gateway and home control network connection method thereof
ES2294913A1 (es) Sistema de mensajeria y metodo para el mismo.
JP4322879B2 (ja) 通信機器用の接続装置
CN101326764A (zh) 用于创建反向隧道的方法、系统和装置
ES2202264T3 (es) Procedimiento de gestion de un modulo de comunicacion y dispositivo que comprende un modulo de este tipo.
US20220053309A1 (en) Apparatus, Method and Program for Transmitting and Receiving Data to and From IOT Device
ES2366783T3 (es) Sistema y procedimiento de gestión de una red de telecomunicaciones-arquitectura dedicada, en una terminal.
WO2017138850A1 (en) Method for keeping connection path alive, proxy device and coap compliant end point device
KR100667732B1 (ko) 외부에서 사설망 내부와 통신하는 인터넷 통신 장치 및 방법
RU2005133191A (ru) Способ и система регулировки уровня громкости
US20060282523A1 (en) System and method for non-obtrusive monitoring and control of remote services and control gateways
JP4903909B2 (ja) 通信システム
ES2266583T3 (es) Sistema y procedimiento para la emision de datos de un aparato, especialmente de un aparato de automatizacion a traves de una interfaz normalizada con sustitucion de variables a traves de un eco servidor.
JP5105755B2 (ja) 通信機器用の接続装置。