ES2377506T3 - Procedimiento y dispositivo para transmitir información desde un servidor de información a un aparato terminal móvil y aparato terminal móvil - Google Patents

Procedimiento y dispositivo para transmitir información desde un servidor de información a un aparato terminal móvil y aparato terminal móvil Download PDF

Info

Publication number
ES2377506T3
ES2377506T3 ES06012551T ES06012551T ES2377506T3 ES 2377506 T3 ES2377506 T3 ES 2377506T3 ES 06012551 T ES06012551 T ES 06012551T ES 06012551 T ES06012551 T ES 06012551T ES 2377506 T3 ES2377506 T3 ES 2377506T3
Authority
ES
Spain
Prior art keywords
information
mobile terminal
server
transmission
terminal apparatus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES06012551T
Other languages
English (en)
Inventor
Bruno Rodrigues
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.)
Vodafone Holding GmbH
Original Assignee
Vodafone Holding GmbH
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 Vodafone Holding GmbH filed Critical Vodafone Holding GmbH
Application granted granted Critical
Publication of ES2377506T3 publication Critical patent/ES2377506T3/es
Anticipated expiration legal-status Critical
Active legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procedimiento para transmitir información desde un servidor de información a un aparato terminal móvil mediante una red de radiotelefonía móvil, con las siguientes etapas: - envío de información de un servicio del servidor de información mediante, al menos, un canal de radiodifusión celular,- recepción de una solicitud de alta de un aparato terminal móvil para transmitir información del servicio como paquetes de datos según el protocolo IP, - extracción, a partir de la solicitud de alta, de una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil, - comparación de la información del servicio recibida en último lugar en el aparato terminal móvil con la información almacenada en el servidor de información y - transmisión, como paquetes de datos según el protocolo IP, de los mensajes generados tras la información del servicio recibida en último lugar en el aparato terminal móvil.

Description

Procedimiento y dispositivo para transmitir información desde un servidor de información a un aparato terminal móvil y aparato terminal móvil
La presente invención se refiere a un procedimiento para transmitir información desde un servidor de información, a un servidor de información, a un protocolo de comunicación, a un aparato terminal móvil y a un procedimiento para gestionar información.
Para transmitir información, como mensajes, ofertas o publicidad, se conoce ya la utilización de mensajes de difusión celular, que en lo sucesivo denominaremos también mensajes de radiodifusión celular (Cell Braodcast, abreviadamente referido como CB), en redes de radiotelefonía móvil. En esta variante del servicio de mensajes cortos SMS se envía una información a un grupo determinado dentro de un área regional. El área en la que deben enviarse los mensajes puede fijarla el proveedor de la información. Una vez fijada, todos los equipos terminales móviles del sistema de comunicación que se hallen en esta área reciben los mensajes emitidos.
El servicio de radiodifusión celular debe estar soportado, por una parte, por el portador, es decir el portador utilizado para la transmisión, y por el operador de la red de radiotelefonía móvil y, por otra parte, por el aparato terminal móvil.
Estas condiciones previas no se dan siempre para todos los usuarios de un sistema de comunicación a los que ha de enviarse información.
En la norma (ETSI TS 123 246 V6.6.0 (2005-03)) se revela la arquitectura y la descripción funcional de UMTS y Difusión de multimedios / Servicios de multidifusión. Sin embargo, en este documento no se aborda la problemática de una falta de disponibilidad de señales de radiodifusión celular y una alternativa para la transmisión de información desde un servidor de información.
Por este motivo, un objetivo de la presente invención es permitir una transmisión regular de información a, al menos, un aparato terminal móvil, que pueda garantizarse con fiabilidad.
La invención se basa en el conocimiento de que este objetivo puede lograrse creando una transmisión alternativa de la información, que sea compatible con los tipos de transmisión ya existentes y pueda realizarse fácilmente.
Según un primer aspecto, el objetivo se logra mediante un procedimiento para transmitir información desde un servidor de información a un aparato terminal móvil mediante una red de radiotelefonía móvil, con las siguientes etapas:
•
Envío de información de un servicio del servidor de información mediante, al menos, un canal de radiodifusión celular.
•
Recepción de una solicitud de alta de un aparato terminal móvil para transmitir de información del servicio como paquetes de datos según el protocolo IP.
•
Extracción, a partir de la solicitud de alta, de una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil.
•
Comparación de la información del servicio recibida en último lugar en el aparato terminal móvil con la información almacenada en el servidor de información y transmisión, como paquetes de datos según el protocolo IP, de los mensajes generados tras la información del servicio recibida en último lugar en el aparato terminal móvil.
Según el procedimiento para transmitir información desde un servidor de información a un aparato terminal móvil mediante un servicio de una red de radiotelefonía móvil conmutado por paquetes, la transmisión se realiza al menos por momentos de acuerdo con un protocolo IP y el procedimiento comprende al menos la etapa de recepción de una solicitud de alta al servidor de información y la transmisión de información almacenada en el servidor de información al aparato terminal móvil.
A través del alta del aparato terminal móvil en el servidor de información puede establecerse una conexión, como un contexto PDP, mediante la cual se hace posible la transmisión de paquetes de datos según el protocolo IP. De este modo se crea un tipo de transmisión adicional a la transmisión mediante radiodifusión celular ya conocida, que puede utilizarse simultáneamente o también como alternativa a la transmisión por radiodifusión celular.
El procedimiento comprende la etapa de extracción, a partir de la solicitud de alta, de una indicación sobre la información recibida en último lugar en el aparato terminal móvil, de la comparación de la información recibida en último lugar en el aparato terminal móvil con la información almacenada en el servidor de información y de la transmisión al aparato terminal móvil de la información almacenada tras la información recibida en último lugar en el aparato terminal móvil. Mediante estas etapas se hace posible una actualización de la información en el aparato terminal móvil, si éste no ha recibido durante cierto tiempo ninguna información del servidor de información.
Adicionalmente, el procedimiento puede comprender la etapa de extracción, a partir de la solicitud de alta, de, al menos, una indicación de canales de información. Mediante esta indicación, el servidor de información puede decidir qué información debe transmitirse al aparato terminal móvil. A los canales de información, que corresponden a los canales de radiodifusión celular, se les puede asignar información de distintas categorías. Por ejemplo puede asignarse a un canal información relativa a deportes y a otro canal información relativa a cultura. Mediante la indicación de para qué canales debe transmitirse información al aparato terminal móvil puede reducirse el gasto de supervisión y transmisión para la actualización constante del aparato terminal móvil, ya que los demás canales pueden desatenderse.
El procedimiento puede comprender la etapa de extracción, a partir de la solicitud de alta, de una indicación sobre la información recibida en último lugar en el aparato terminal móvil en al menos un canal de información incluido en la solicitud de alta, de la comparación de la información recibida en último lugar en el aparato terminal móvil en este canal de información con la información almacenada en el servidor de información y de la transmisión al aparato terminal móvil de la información almacenada en este canal de información tras la información recibida en último lugar en el aparato terminal móvil. La indicación que se extrae de la solicitud de alta respecto de a la información recibida en último lugar en el aparato terminal móvil, es en particular el instante de recepción de esta información en el aparato terminal móvil. Mediante esta indicación, el servidor de información puede comprobar el estado de actualización de la información en el aparato terminal móvil y detectar la información que falta. Ésta puede transmitirse entonces al aparato terminal móvil en una serie de paquetes de datos.
El procedimiento comprende preferentemente la etapa de verificación de la transmisión al aparato terminal móvil de toda la información detectada en la comparación con la que esté almacenada en el servidor de información pero aún no recibida por el aparato terminal móvil, la etapa de generación de un mensaje final y de la transmisión del mensaje final al aparato terminal móvil. Mediante este mensaje final, cuyo contenido, consiste en que no hay más mensajes en el servidor de información, se indica al equipo terminal que está actualizado y que la información recibida posteriormente puede procesarse de forma correspondiente. Tras la transmisión del mensaje final, la nueva información generada en el servidor de información se transmitirá al equipo terminal. Esto puede realizarse de forma asincrónica en cada caso después de generarse cada mensaje.
El procedimiento puede comprender además la etapa de recepción de una solicitud de baja del aparato terminal móvil y la etapa de baja del aparato terminal móvil. Con la baja ya no pueden transmitirse al equipo terminal más paquetes de datos según el protocolo IP hasta la siguiente alta en el servidor.
El procedimiento puede comprender además la transmisión de información mediante radiodifusión celular a, al menos, dos equipos terminales móviles. Este tipo de transmisión puede realizarse simultáneamente a la transmisión mediante un portador IP. De este modo, si un aparato terminal móvil recibe información mediante el portador IP, otros equipos terminales móviles pueden continuar recibiendo la información en forma de mensajes de radiodifusión celular.
La transmisión de la información de acuerdo con el protocolo IP se realiza preferentemente mediante una transmisión de punto a punto (point-to-point), de multidifusión (Multicast) o de radiodifusión (Broadcast). Especialmente en el caso de una transmisión de punto a punto, puede utilizarse para la transmisión la técnica Push y llevar así la información directamente al aparato terminal móvil.
Según otro aspecto, el objetivo se logra mediante un servidor de información para una red de radiotelefonía móvil, que se distingue porque presenta al menos una unidad de recepción, que sirve al menos para la recepción de solicitudes transmitidas según un protocolo IP, y al menos una unidad de procesamiento para procesar la o las solicitudes recibidas, que comprende una unidad de extracción para extraer de la solicitud recibida una indicación sobre la información del servicio recibida en último lugar en un aparato terminal móvil, porque el servidor de información presenta una unidad de comparación para comparar la información recibida en último lugar en el aparato terminal móvil con la información almacenada en el servidor y porque el servidor de información comprende al menos una unidad de salida para transmitir mensajes a un aparato terminal móvil, estando la unidad de salida diseñada para la transmisión de mensajes de radiodifusión celular y la transmisión de paquetes de datos según un protocolo IP y transmitiendo la unidad de salida mediante el protocolo IP los mensajes generados tras la información del servicio recibida en último lugar en el aparato terminal móvil.
La unidad de procesamiento puede comprender en particular una unidad de extracción para extraer indicaciones a partir de las solicitudes recibidas. El servidor de información puede comprender además una unidad de generación de mensajes, para generar al menos un mensaje, y al menos una unidad de salida para transmitir mensajes a un aparato terminal móvil. En la unidad de generación de mensajes puede por ejemplo ponerse en el formato de un paquete UDP la información que haya de transmitirse a un aparato terminal móvil. En la unidad de generación de mensajes pueden generarse también instrucciones y respuestas a solicitudes del aparato terminal móvil.
El servidor de información presenta preferentemente una unidad de memoria para almacenar información y la unidad de generación de mensajes está conectada, al menos por momentos, a la unidad de memoria. De este modo pueden obtenerse de la unidad de memoria indicaciones e información necesarias para la generación de mensajes.
El servidor de información presenta preferentemente una unidad de comparación para comparar la información recibida con la información almacenada en el servidor y la unidad de comparación está conectada, al menos por momentos, a la unidad de memoria del servidor de información.
La unidad de salida está diseñada para la transmisión de mensajes de radiodifusión celular y la transmisión de paquetes de datos según un protocolo IP. Además, la unidad de salida puede presentar un mecanismo de adición que permita añadir la transmisión de paquetes de datos según el protocolo IP a la transmisión de mensajes de radiodifusión celular.
Según otro aspecto, la invención se refiere a un procedimiento para recibir, de un servidor de información, información de un servicio en un aparato terminal móvil de una red de radiotelefonía móvil, ejecutándose las siguientes etapas en el aparato terminal móvil:
•
supervisión de, al menos, un canal de radiodifusión celular,
•
si se detecta la ausencia de información en el o los canales de radiodifusión celular, ejecución de las siguientes etapas:
•
generación de una solicitud de alta que incluye una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil,
•
transmisión de la solicitud de alta al servidor de información y
•
recepción en forma de paquetes de datos según el protocolo IP de información generada tras la información del servicio recibida en último lugar en el aparato terminal móvil.
Puede utilizarse un protocolo de comunicación para la transmisión de información mediante paquetes de datos de acuerdo con un protocolo IP, que se distingue porque los paquetes de datos se transmiten según el protocolo de datagramas de usuario UDP y, para iniciar la transmisión de datos, está prevista al menos una solicitud de alta, que es enviada por un aparato terminal móvil a un servidor de información y que incluye al menos una indicación sobre el momento de recepción de la información recibida en último lugar en el aparato terminal móvil.
La solicitud de alta puede incluir, al menos, una indicación sobre la información que ha de recibir el aparato terminal móvil. Esta indicación de la información que ha de recibir el aparato terminal móvil puede comprender al menos una indicación sobre un canal de transmisión. El canal de transmisión corresponde al canal de información, o canal de radiodifusión celular. Según el protocolo de comunicación, al recibir la solicitud de alta el servidor de información puede transmitir al aparato terminal móvil información almacenada en el servidor de información, en función de la indicación de la información recibida en último lugar en el aparato terminal móvil. También es posible, según el protocolo de comunicación, que el servidor de información envíe un mensaje final al aparato terminal móvil si no hay información nueva en el servidor de información. Según el protocolo de comunicación, al generar una nueva información el servidor de información puede enviar ésta al o a los equipos terminales móviles.
Según el protocolo de comunicación, el aparato terminal móvil puede darse de baja mediante el envío de un mensaje de baja al servidor de información.
En el protocolo de comunicación se utilizan para la comunicación entre el servidor de comunicación y el o los equipos terminales móviles preferentemente cuatro tipos de mensajes. Un tipo de mensaje puede ser una notificación, otro tipo de mensaje una solicitud de alta, otro tipo de mensaje una solicitud de baja y otro tipo de mensaje una transmisión de información. Los distintos tipos de mensajes se identifican preferentemente mediante una indicación en la línea de inicio del mensaje. A través de la diferenciación de estas categorías o tipos de mensajes, éstos pueden tener una estructura, en particular una longitud, adecuada al fin respectivo. De este modo puede minimizarse el tráfico de datos necesario para la comunicación entre el servidor de información y el equipo terminal. El objetivo que sirve de base a la presente invención se logra además mediante un aparato terminal móvil para la utilización en una red de radiotelefonía móvil que está diseñado para la recepción y la transmisión de paquetes de datos mediante un protocolo IP, presentando este equipo terminal una unidad de gestión que está diseñada para la recepción de información mediante, al menos, dos tipos diferentes de transmisión y para la supervisión de la recepción de información, supervisándose al menos un canal de radiodifusión celular, que sirve para transmitir información desde un servidor de información, y, si se detecta la ausencia de información en el canal de radiodifusión celular, generándose una solicitud de alta destinada a ser transmitida a un servidor de información para efectuar el alta en el servidor de información para transmitir información, incluyendo la solicitud de alta una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil y estando la unidad de gestión diseñada para recepción según el protocolo IP, los mensajes generados tras una información del servicio recibida en último lugar en el aparato terminal móvil. En lo que sigue, la unidad de gestión se denominará también ‘cliente’ y el aparato terminal móvil se denominará también ‘terminal’.
La unidad de gestión puede estar diseñada para el almacenamiento y la indicación de información recibida. La unidad de gestión puede además decidir sobre el tipo de transmisión entre el servidor de información y el aparato terminal móvil. Especialmente con este fin, la unidad de gestión está diseñada para supervisar la recepción de información. Si, por ejemplo, no se reciben mensajes de radiodifusión celular en la unidad de gestión, ésta puede conmutar a un tipo de transmisión alternativo.
La unidad de gestión puede estar diseñada además para la supervisión del estado de funcionamiento del aparato terminal móvil. Se denomina estado de funcionamiento, por ejemplo, el estado de reposo del aparato terminal móvil, en el que por regla general se apaga la iluminación de la pantalla, o el, así llamado, modo inactivo (Idle), en el que el usuario no utiliza ninguna aplicación de forma activa pero el aparato terminal móvil no se halla en el estado de reposo.
La unidad de gestión del aparato terminal móvil puede estar diseñada además para la generación de mensajes.
Por último, la presente invención se refiere a un procedimiento para gestionar información en un aparato terminal móvil de una red de radiotelefonía móvil. En particular, el procedimiento se refiere a un procedimiento para recibir, de un servidor de información, información de un servicio en un aparato terminal móvil de una red de radiotelefonía móvil, ejecutándose las siguientes etapas en el aparato terminal móvil:
•
supervisión de, al menos, un canal de radiodifusión celular,
•
si se detecta la ausencia de información en el o los canales de radiodifusión celular, ejecución de las siguientes etapas:
•
generación de una solicitud de alta que incluye una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil,
•
transmisión de la solicitud de alta al servidor de información y
•
recepción en forma de paquetes de datos según el protocolo IP de información generada tras la información del servicio recibida en último lugar en el aparato terminal móvil.
El procedimiento comprende la etapa de supervisión de, al menos, un canal de transmisión que sirve para transmitir información desde un servidor de información. Si se detecta la ausencia de información en el o los canales de transmisión, el procedimiento comprende la etapa de generación de un mensaje de alta para la transmisión a un servidor de información.
El procedimiento puede comprender además la etapa de supervisión del estado de funcionamiento del aparato terminal móvil. Al detectarse el cambio del estado de funcionamiento del aparato terminal móvil, el procedimiento puede comprender la etapa de generación y transmisión de un mensaje de baja a un servidor de información.
Las unidades del servidor de información y del aparato terminal móvil arriba descritas pueden también estar reunidas, al menos parcialmente. Las unidades se hallan preferentemente en forma de programas y/o circuitos.
Las características y ventajas descritas con relación a un objeto de la invención son también válidas análogamente, y siempre que sean aplicables, para los demás objetos de la invención; incluso si en caso dado no se describen éstas en relación con los mismos.
A continuación se explica de nuevo la invención detalladamente.
En un aparato terminal móvil, que en lo que sigue se denomina también ‘terminal’, se instala una unidad de gestión para la comunicación con el servidor de información. Esta unidad de gestión se denomina en lo que sigue también ‘cliente’.
En el servidor de información se crea regularmente información nueva, que ha de transmitirse a los terminales que desean recurrir a este servicio. La información se almacena en el servidor de información. El almacenamiento se realiza preferentemente indicando el momento de la generación.
La información se emite mediante canales de radiodifusión celular. Los distintos canales pueden tener asignadas categorías de información. En el cliente está prevista una funcionalidad, en particular un menú de usuario, mediante la cual el usuario puede seleccionar los canales que considere importantes. Una vez ajustados los canales en el equipo terminal, el cliente supervisará los canales CB correspondientes. Si se detecta un mensaje CB en uno de los canales, la información contenida en el mensaje se hace visible para el usuario en el terminal, en particular en una pantalla de presentación. Si a continuación se recibe otro mensaje CB, éste puede sustituir en la pantalla a la información antes recibida o presentarse adicionalmente a esta última.
El cliente realiza la comprobación en cuanto a mensajes disponibles (en el aire) en los canales correspondientes periódicamente y según reglas predefinidas. Si durante la supervisión de los canales se detecta que no hay mensajes CB disponibles, esto constituye un indicio de que, al menos temporalmente, la radiodifusión celular no está disponible como portadora. En la radiodifusión celular se transmite un flujo constante de mensajes, en el que cada mensaje se transmite al menos dos veces y se mantiene al menos una hora. Por lo tanto, siempre hay mensajes ‘en el aire’, aunque sean mensajes anticuados. Así pues, el cliente puede detectar si la transmisión CB está disponible como portadora si detecta mensajes en los canales, aunque éstos estén anticuados. El cliente detecta preferentemente los mensajes antiguos como tales y en consecuencia no los sigue procesando. Si la CB no está disponible como portadora, el cliente probará métodos de transmisión alternativos.
Si se detecta la ausencia o la no disponibilidad de mensajes CB, el cliente probará los métodos de transmisión alternativos en un orden predefinido. En cuanto uno de los métodos de transmisión tenga éxito, el cliente puede almacenarlo y recurrir a este método de transmisión directamente en una prueba de conexión posterior, apartándose del orden predefinido. Sin embargo, también en este caso se da siempre la preferencia a la transmisión mediante radiodifusión celular. En cuanto la CB está disponible se utiliza este tipo de transmisión, ya que es la que ocasiona los menores gastos. También, si durante la utilización de un método de transmisión alternativo se detecta que hay de nuevo mensajes CB disponibles, se interrumpe el método de transmisión alternativo y se recurre a la transmisión CB. Sin embargo, en algunos casos, antes de interrumpir el método de transmisión alternativo puede terminarse en primer lugar un proceso de transmisión ya empezado.
Como métodos de transmisión alternativos, el cliente puede utilizar en particular transmisiones basadas en IP en forma de transmisión de paquetes. Para ello puede elegirse una difusión IP, una multidifusión IP o también una transmisión de punto a punto. En el caso de la transmisión mediante multidifusión IP e IP-P2P, el cliente debe darse de alta en el servidor de información para esa transmisión. El usuario no percibe el tipo de transmisión. Por consiguiente, independientemente del método de transmisión, para él no existe ninguna diferencia en el uso.
Así pues, el cliente ejecutará las siguientes etapas para poder garantizar la transmisión de la información. En primer lugar se comprueba la existencia de mensajes CB en los canales seleccionados por el usuario y en canales especiales. Si hay mensajes CB, éstos se procesan de acuerdo con reglas predefinidas. Si, por el contrario, no hay ningún mensaje CB después de un periodo predefinido, se prueba un método de transmisión alternativo. Dado que los métodos de transmisión alternativos requieren una conexión IP, el cliente debe acceder en primer lugar a la red IP, o entrar en línea. Si en el terminal ya se está utilizando otra aplicación para la que se haya establecido una conexión a la red IP, en determinadas condiciones, que se explicarán más abajo con mayor detalle, este contexto PDP ya existente puede ser utilizado por el servidor de información para la transmisión de mensajes y no es necesario establecer una conexión por separado (contexto PDP).
Una vez establecido el contexto PDP se puede comprobar en primer lugar la presencia de mensajes de difusión IP y, si existen, procesarlos correspondientemente y presentarlos en el terminal. Si no hay mensajes de difusión IP, el cliente puede darse de alta para la transmisión mediante multidifusión IP. Si esta alta tiene éxito, la información puede recibirse en el terminal mediante este método de transmisión. Si no está disponible la multidifusión IP, el cliente puede darse de alta en el servidor de información para una conexión P2P y recibir la información mediante esta portadora.
En la transmisión P2P, la transmisión puede realizarse mediante la, así llamada, técnica Push, en la que la transmisión se realiza desde el servidor. Esta transmisión resulta ventajosa, ya que la recepción y el procesamiento de información pueden realizarse de forma asincrónica, es decir siempre que haya nueva información disponible. En comparación con una transmisión que sólo se realiza a demanda del cliente, en la transmisión Push puede reducirse tanto el uso de recursos como el tiempo de espera. En esta técnica, el servidor puede decidir, de acuerdo con el grado de utilización y otros parámetros de la red, cuándo y si se transmite información. De este modo, el servidor controla y optimiza el uso del ancho de banda. La indicación del cliente al servidor con la que deja ver que está disponible o ya no lo está supone un tráfico de datos muy pequeño, de modo que, en esta técnica, la mayor parte del tráfico de datos se produce del servidor al cliente. Además, esta técnica resulta fácil de implementar. El MIDP (mobile information device profile [perfil de dispositivo de información móvil]) para el terminal es de poca extensión y puede tener bastante con aproximadamente 10 líneas.
A continuación se describe más detalladamente el protocolo de comunicación utilizado para la transmisión mediante P2P y el formato de los paquetes de datos transmitidos.
Para el registro, el cliente envía una solicitud de registro al servidor. En respuesta a esta solicitud, el servidor envía un mensaje al cliente, en el que bien se confirma el registro o bien se comunica al cliente información adicional para que el registro se realice con éxito. Si el cliente no recibe ninguna respuesta del servidor en un intervalo de tiempo que puede predefinirse, envía una nueva solicitud de registro.
El paquete de datos que el cliente envía al servidor para el registro incluye indicaciones sobre los canales seleccionados por el usuario. Este paquete de datos incluye además preferentemente una indicación sobre el momento en que se ha recibido el último mensaje CB. Una vez recibidas estas indicaciones, el servidor envía un paquete de datos para cada información generada en el servidor desde la información recibida en último lugar en el terminal. En el servidor están depositadas preferentemente reglas que limitan la cantidad de paquetes de datos. Por ejemplo, puede estar depositada la regla de que sólo deba transmitirse un número determinado de paquetes de datos, por ejemplo 100 ó 150, o de que sólo deban enviarse paquetes de datos para la información que no tenga una antigüedad mayor que, por ejemplo, unas horas o un día. Estas reglas pueden diferir en función del contenido de la información a través de la asignación de canales. Así, por ejemplo, la información general, como las nuevas fuentes de información disponibles en una página de inicio (homepage), puede enviarse al cliente durante un espacio de tiempo mayor que la información de tiempo crítico, como los partes meteorológicos o los avisos de atasco.
En cuanto el servidor ha transmitido al cliente todos los mensajes antiguos, envía al cliente un mensaje correspondiente. En vista de ello, el cliente sabe que todo paquete de datos con información recibido a partir de ese momento transmite información nueva y ésta puede procesarse correspondientemente.
Si se presentan problemas durante el alta en el servidor, éste informa al cliente correspondientemente. Tales problemas pueden ser, por ejemplo, el traslado/volcado del servidor de información a otro ordenador, la falta de tiempo para el registro y similares.
Si se ha desplazado el servidor de información a otro lugar, el servidor diferencia en la indicación hecha al cliente entre un desplazamiento temporal y un desplazamiento permanente del servidor de información. En ambos casos, el servidor transmite al cliente, en respuesta a la solicitud de registro, la indicación de que el servidor ha sido desplazado e indica también la nueva posición del servidor en el que, a partir de ese momento, el cliente debe intentar registrarse. Este proceso puede realizarse en uno o en varios paquetes de datos.
El servidor puede indicar además al cliente que el tiempo para el registro no ha sido suficiente. En este caso, el servidor indicará al cliente también cuándo debe enviarse una nueva solicitud de registro.
Por último, durante el registro el servidor puede enviar al cliente también la indicación de que no está permitido el acceso. Esto indica que el cliente debe dejar de utilizar el servidor en cuestión para posteriores registros, a no ser que se reinicie el terminal. Esta respuesta puede enviarla el servidor por ejemplo en los casos en que haya de excluirse el método de transmisión alternativo al Push.
En cuanto se den condiciones que hagan necesario terminar el Push de información, por ejemplo la disponibilidad de mensajes CB, el cliente envía un mensaje de baja al servidor. Tras la recepción de este mensaje y el envío de una confirmación de baja al cliente, el servidor deja de enviar a este último información o paquetes de datos. Por regla general, la confirmación de baja no se continúa procesando en el cliente. Esto es especialmente aplicable si se ha apagado el terminal o éste se halla en el estado de reposo.
El servidor puede también cursar automáticamente una baja del cliente si, en respuesta a la transmisión de un paquete de datos, recibe de la red una indicación ICMP (Internet control message protocol [protocolo de mensajes de control de Internet]) en cuanto a que el cliente ya no está accesible.
El cliente utiliza un puerto aleatorio (estándar de sistema operativo) para establecer una conexión con un puerto predefinido en el servidor. El servidor responderá al puerto original del cliente desde el puerto indicado. El cliente vigila el puerto UDP utilizado para el registro en el servidor.
Si existe un registro en un servidor, éste, tras la transmisión de mensajes antiguos efectuada en caso dado una sola vez inicialmente, transmite al cliente en cada caso un paquete de datos al generarse una nueva información en el servidor. En esta transmisión, además de la carga útil de los mensajes que constituye la información real, el servidor indica el número de canal, el número de serie, la codificación de los datos y la longitud del contenido de la información. Si la transmisión de un mensaje se realiza con éxito, el cliente envía al servidor una confirmación en cuanto a que se ha aceptado la información recibida. Por regla general, esta confirmación se envía sólo si el servidor la ha solicitado al transmitir el paquete de datos. Además de esta transmisión asincrónica de la información cada vez que se genera una información nueva, el servidor también puede almacenar la información generada y transmitirla al cliente de una vez en un orden de transmisión (ráfaga). Por ejemplo, en lugar de enviar una información cada 10 segundos, es posible poner en fila los mensajes y enviar 3 mensajes cada 30 segundos. El cliente puede aprovechar este orden de transmisión si, al recibir el mensaje de que ya no hay más información, espera antes de actualizar la presentación en el terminal.
Durante la existencia del registro del cliente en el servidor pueden además intercambiarse otras indicaciones. Elservidor puede por ejemplo enviar al cliente una instrucción de mantenimiento de conexión. Ésta puede utilizarse si es necesaria una conexión activada entre el servidor y el cliente debido a configuraciones de la red. Sin embargo, el servidor puede utilizar esta instrucción también para comprobar si el cliente aún está disponible. El cliente responderá a esta instrucción con un mensaje que indica que aún está disponible.
Otro mensaje del servidor al cliente es el mensaje ya descrito anteriormente, en cuanto a que ya no quedan más mensajes antiguos en el servidor. Por regla general, el cliente no responde a este mensaje. Los mensajes obtenidos a partir de entonces pueden estar provistos de una identificación, en particular una bandera, que indique que estos mensajes son nuevos. Esta bandera puede ponerse en función de un número de actualización. Si el número de actualización es diferente (mayor o menor) al de un mensaje recibido previamente, se pone la bandera.
Un mensaje que puede enviar el cliente al servidor durante la existencia del registro consiste también en una instrucción de mantenimiento de conexión. Ésta puede utilizarse si es necesaria una conexión activada entre el servidor y el cliente debido a configuraciones de la red. Sin embargo, el cliente puede utilizar esta instrucción también para comprobar si el servidor aún está disponible. Si el cliente no recibe ningún mensaje en respuesta a esta instrucción, el cliente intentará de nuevo darse de alta en el servidor. Si el servidor recibe la instrucción de mantenimiento de conexión, envía al cliente una confirmación de que aún está accesible. Como alternativa, el servidor puede enviar al cliente un mensaje de error, que de acuerdo con el procedimiento de registro arriba mencionado puede constituir un mensaje de error 4xx ó 5xx.
Además, son posibles mensajes con los que servidor indica al cliente que no se ha entendido el paquete enviado o que actualmente el servicio no está disponible. Si es inminente una caída, un servidor puede enviar este mensaje de error a todos los clientes.
Para transmitir información de acuerdo con la presente invención se utilizan preferentemente paquetes de datos UDP, es decir paquetes según el protocolo de datagramas de usuario. Mediante la utilización de paquetes UDP, especialmente teniendo en cuenta el protocolo de comunicación según la invención, puede ponerse a disposición una buena alternativa a la radiodifusión celular. El gasto para ello puede mantenerse pequeño y es posible lograr un tiempo de espera corto. En comparación con la utilización de WAP, el planteamiento según la invención permite impedir una congestión de datos. Dado que el número de terminales es alto, el servidor de información operará preferentemente en la red interna del operador de red con el fin de evitar una congestión en el lado de la red, por ejemplo de las tablas NAT. El planteamiento de la transmisión en paquetes UDP según un protocolo IP también presenta ventajas considerables en comparación con la transmisión en paquetes TCP. En la transmisión TCP, la transferencia está limitada a 65 K por IP. Gracias a las reglas de comunicación propuestas en el protocolo de comunicación propuesto, es posible compensar una eventual pérdida de paquetes de datos, que por ejemplo también se presenta en la transmisión mediante CB. La transmisión mediante UDP presenta además la ventaja de que no tiene estados y únicamente requiere el envío de paquetes de datos en una y otra dirección. UDP no utiliza recursos en el lado del servidor, excepto la recepción y el procesamiento de paquetes y el envío de paquetes. Además, si se utiliza UDP pueden realizarse también servicios como la multidifusión IP y la difusión IP, lo que no es posible con paquetes según el estándar TCP.
La transmisión según un protocolo IP resulta además ventajosa porque la red puede configurarse fácilmente de tal modo que sea un puerto UDP o también un puerto TCP como portador de datos sin cargo de costes. El establecimiento adicional de contextos PDP en caso dado necesario para la transmisión de paquetes de datos supone un coste en tráfico relativamente pequeño. El volumen de tráfico puede minimizarse además mediante la utilización de UDP como portador y unas sencillos encabezamientos (Header) en el protocolo de comunicación.
El tamaño de la información en una carga útil UDP, o tras la vinculación de todas las páginas CB y antes de la decodificación de 7 bits, debe constituir un múltiplo de 82 octetos, ya que en un mensaje CB no existe ningun encabezamiento para definir el tamaño de página real. El formato de la información transmitida es independiente del portador utilizado para la transmisión. Según la invención pueden utilizarse preferentemente formatos XHTML-MP, XHTML-MP Snippet y Multipart.
A continuación se explican detalladamente el formato de los paquetes de datos, los encabezamientos utilizados según el protocolo propuesto y los valores asignados a los encabezamientos.
Según esta invención, la información se envía preferentemente en un formato UDP. Como carga útil máxima se definen 1.283 octetos. Esta carga útil se utiliza en la transmisión de mensajes CB. Dado que este tamaño cabe óptimamente en sólo un paquete UDP, que por regla general tiene una MTU (maximum transmission unit [unidad de transmisión máxima]) de 1.500, no es necesario enlazar o generar de nuevo la información. Cada información transmitida mediante CB corresponde en el caso del Push UDP exactamente a un paquete UDP.
Al igual que en el protocolo HTTP o SIP, en el protocolo de comunicación según la invención se interpreta preferentemente sólo el comienzo del encabezamiento, que contiene el servicio y el número de versión del servicio, así como la indicación sobre el tipo de mensaje. En particular, aparte del servicio y del número de versión, se interpreta sólo la identificación numérica del mensaje, por ejemplo sólo la parte “LC/1.0 XXX”, y se ignora el texto subsiguiente. Por ejemplo: “LC/1.0 200 OK”, “LC/1.0 200” ó “LC/1.0 200 Everything’s well in the World [todo bien globalmente]” se interpretan todos como mensaje “200 OK”.
Los mensajes transmitidos según la invención son mensajes de solicitud y respuesta, enviados bien por el servidor o bien por el cliente. Los mensajes de solicitud y respuesta utilizan aquí el formato indicado en RFC 822 (Standard for the format of ARPA Internet text messages [norma para formato de mensajes de texto de Internet ARPA]) para transmitir la carga útil del mensaje. Ambos tipos de mensaje comprenden como envoltura (Wrapper) una línea de inicio, una o varias etiquetas de cabecera, una línea en blanco y, en caso dado, un cuerpo de mensaje, en el que puede estar contenida la información en sí. En el caso de una solicitud, la línea de inicio consta de un testigo de método (Method-Token), que indica la acción, una cadena predefinida, que puede ser por ejemplo el nombre del servicio, la indicación de la versión del protocolo de transmisión utilizado y un cambio de línea. En el caso del mensaje de respuesta, la línea de inicio consta de una indicación sobre la versión del protocolo, seguida de un código de estado numérico y el texto asignado al mismo.
En el protocolo de comunicación empleado se utilizan especialmente los siguientes testigos de método, que indican la acción realizada, estando algunos disponibles sólo en una dirección de comunicación, es decir del servidor al cliente (método de servidor), o en la dirección opuesta (método de terminal), o en ambas direcciones (método general). A continuación se ofrecen ejemplos de esto, en los que | sustituye a “o”.
El código de estado es preferentemente una expresión entera de tres dígitos, con la que se expresa el intento de 5 entender y procesar la solicitud. El texto asignado a la misma sirve al usuario para una mejor comprensión, siempre que permita que se le muestre.
El primer número del código de estado indica la clase de respuesta, utilizándose por regla general cuatro valores:
• 2xx: Éxito (Success) -La acción se ha recibido, entendido y aceptado con éxito.
• 3xx: Desvío (Redirection) -Deben ejecutarse otras acciones antes de que pueda realizarse la solicitud. 10 • 4xx: Error de cliente (Client Error) -La solicitud contiene una sintaxis incorrecta o no puede ejecutarse.
• 5xx: Error de servidor (Server Error) -El servidor ha fracasado en el intento de satisfacer una solicitud
manifiestamente válida. A continuación se ofrecen ejemplos de los códigos de estado, en los que | sustituye a “o”, que se explicarán más adelante con mayor detalle haciendo referencia a la comunicación entre el servidor y el cliente.
15 Status-Code [codigo-estado]= General-Status [estado-general] | Terminal-Status [estado-terminal]| Server-Status [estado-servidor] General-Status[estado-general] = "200" ; "OK" | "400" ; "Bad Request [solicitud errónea]" | "500" ; "Server Error" [error de servidor]
20 Terminal-Status [estado-terminal] = "202" ; "Accepted [aceptado]" Server-Status [estado-servidor] = "301"; "Moved Permanently [permanentemente movido]" | "302" ; "Moved Temporarly [temporalmente movido]" | "403" ; "Forbidden [prohibido]" | "423" ; "Interval Too Brief [intervalo demasiado corto]"
25 Reason-Phrase [frase-razón]= TEXT [texto] | "503" ; "Service Unavailable [servicio no disponible]" Los encabezamientos utilizados según la invención se muestran a modo de ejemplo en la lista siguiente, en la que | sustituye a “o” y SP representa un espacio. Encabezamiento de mensajes = Field-Name [nombre-campo]":" Field-Value [valor-campo]
30 Identificador de campo (Field-Name [nombre-campo]) = General-Header [general-encabezamiento] | Request-Header [encabezamiento-solicitud] | Response-Header [encabezamiento-respuesta] Valor de campo (Field-Value) = *SP TEXT *SP Encabezamiento general (General-Header) = "seq"
35 | XXX Encabezamiento solicitud (Request-Header) = "ch"; Channels [canales]
(ch) Header [encabezamiento]
| "lm" ; Last-Message [ultimo-mensaje] (lm) Header [encabezamiento]
| "f" ; From [desde] (f) Header [encabezamiento]
| "aid" ; AreaID (aid [ayuda]) Header [encabezamiento]
| "cid" ; CellID [célula](cid) Header
| "mc" ; Mobile-Code [móvil-código](mc) Header [encabezamiento]
| "ua" ; User-Agent [usuario-agente] (ua) Header [encabezamiento]
| "cn" ; Channel Number [número cabal] (cn) Header (encabezamiento]
| "sn" ; Serial Number [número serie] (sn) Header [encabezamiento]
| "dc" ; Data-Coding [datos-codificación] (dc) Header [encabezamiento]
| "1" ; Content-Length [contenido-longitud] (1) Header [encabezamiento]
| "dr" ; Deliver-Report (dr) [entregar-informe] Header [encabezamiento]
Encabezamiento de respuesta (Response-Header) = "lo" ; Location [localización]
(lo) Header [encabezamiento]
| "ra" ; Repeat-After [repetir-después] (ra) Header [encabezamiento]
| xxx A continuación se explican de nuevo las distintas etiquetas de cabecera, sus valores y su significado. Alta (cliente a servidor): Para el registro del cliente en el servidor, el cliente envía un mensaje con, por ejemplo, el siguiente formato: REG livecast LC/1.0 seq: x ch: 1,3,6,43,66 lm: 20040101120000
f: +491xxxxxxxxx
ua: live!cast/1.0 Platform/x.0 OS/y.0 Vendor/z.0
El encabezamiento CSeq (seq) contiene un número secuencial que se aumenta de forma incremental para cada paquete. De este modo es posible correlacionar la solicitud y la respuesta pertenecientes a un paquete de datos. El encabezamiento de canales [Channels Header] (ch) contiene una lista de los canales en los que el usuario se ha dado de alta. En la norma 3GPP 23.041, que describe la realización técnica de servicios de radiodifusión celular, los canales se denominan “Message Identifier [identificador de mensaje]”. La indicación de los canales está separada en cada caso por una coma, eligiéndose para la designación de los canales las mismas designaciones que las utilizadas para una transmisión CB sencilla. Así, por ejemplo, la indicación
ch: 1,7,15
corresponde a los canales CB reales: 0xA001, 0xA007 y 0xA00F.
El encabezamiento Last-Message [ultimo-mensaje] (lm) incluida opcionalmente en el mensaje contiene el momentode la información recibida en último lugar. Ésta puede comprender la fecha y, en caso dado, una indicación de las horas y los minutos y presentar, por ejemplo, el siguiente formato: (YYYYMMDDHHMMSS[{+|-}HH[MM]]).
El encabezamiento From [desde] (f), incluida también opcionalmente en el mensaje, contiene el MSISDN del usuario.
Por último, el mensaje del paquete de datos de registro enviado por el cliente al servidor puede incluir opcionalmente un encabezamiento User-Agent [usuario-agente] (ua), que indica en forma de cadena el software que se utiliza para el servicio de transmisión, la marca y el modelo del terminal u otra información importante.
Así pues, las indicaciones necesarias en la envoltura (Wrapper) de la solicitud de registro son, además de la indicación de que se trata de una solicitud de registro (REG), las indicaciones de un número secuencial y los canales seleccionados por el usuario. Adicionalmente pueden estar incluidas indicaciones sobre el mensaje recibido en último lugar, la dirección del cliente y el agente del usuario. Por lo tanto, la envoltura se mantiene muy corto. En este mensaje no existe un cuerpo de carga útil, es decir una información o un contenido.
Como reacción a este mensaje se espera una respuesta que indique uno de los siguientes estados de respuesta (Response-Status): “200”, “301”, “302”, “400”, “403”, “423”, “500” Alta (servidor a cliente): Las respuestas del servidor a una solicitud de registro pueden comprender los siguientes encabezamientos: En caso de éxito en el registro, el servidor envía la indicación LC/1.0 200 OK
seq: x e indica con ello que el servidor acepta la conexión y va a enviar al cliente la información antigua, es decir generada antes del momento Lm. El cliente esperará a la recepción de un mensaje final que indique que ya no quedan más mensajes antiguos en el servidor. Tras este mensaje, el cliente puede permanecer en el estado activo o pasar al estado de reposo. Para este mensaje, el cliente interpretará un 200xx como un mensaje 200 OK.
La indicación en el encabezamiento CSeq (seq) contendrá el mismo valor que este encabezamiento del paquete de
datos de la solicitud de registro enviada por el cliente. Si, por el contrario, no es posible realizar el registro y el servidor quiere que el cliente se dé de alta en un nuevo servidor y siga utilizando este último hasta que se reinicie el terminal, el servidor envía, en lugar de la confirmación de registro, un mensaje 301 Moved permanently [movido permanentemente] con la forma siguiente
LC/1.0 301 Moved Permanently seq: x lo: 1.2.3.4:5678
El encabezamiento Location (lo) incluye aquí la dirección IP del nuevo servidor y el puerto en el que el terminal debe darse de alta. Si el puerto no está disponible, el cliente utilizará el mismo puerto que el configurado originalmente y la nueva dirección IP.
Si el cliente debe utilizar otro servidor sólo de forma temporal, el servidor en el que se ha recibido la solicitud de registro envía un mensaje 302 Moved Temporarily [temporalmente movido] con la forma siguiente: LC/1.0 302 Moved Temporarily seq: x
lo: 1.2.3.4:5678 También en este caso el encabezamiento Location indica la dirección IP y el puerto del nuevo servidor. A continuación, el cliente se dará de alta sólo una vez en el nuevo servidor y en el alta siguiente accederá de nuevo al servidor estándar.
Si el intervalo para el registro ha sido demasiado corto, el servidor envía un mensaje de error 423 Interval Too Brief con la forma siguiente: LC/1.0 423 Interval Too Brief seq: x
ra: 7200 Esto indica que el terminal debe intentar de nuevo un registro transcurridos x segundos, que se especifican en un encabezamiento Retry-After. El encabezamiento Retry-After (ra) contiene el número mínimo de segundos que el cliente debe esperar antes de iniciar un nuevo intento de registro.
Por último, en respuesta a la solicitud de registro, el servidor puede enviar también el mensaje de error 403 Forbidden [prohibido] en el formato siguiente: LC/1.0 403 Forbidden
seq: x Esto significa que el servidor ya no quiere recibir más solicitudes de registro del cliente hasta que se reinicie el terminal. Este mensaje de error puede utilizarse por ejemplo para desconectar métodos de transmisión alternativos.
Si se envía otro mensaje de error 4xx al cliente, éste ignorará el mensaje de error. Si el servidor envía un mensaje 5xx, transcurridos un par de segundos el cliente intentará de nuevo darse de alta y aumentará este tiempo exponencialmente mientras se reciban errores 5xx del servidor. Preferentemente se considera un valor máximo de, por ejemplo, un día.
Baja (cliente a servidor):
Para darse de baja de un servidor, el cliente envía al servidor un mensaje de baja, que tiene el formato siguiente: UNREG livecast LC/1.0 seq: x
De este modo se indica al servidor que el cliente no quiere recibir más información asincrónica. Éste es el caso por
ejemplo cuando el terminal pasa al estado de reposo. Así pues, la indicación necesaria en el mensaje de baja es la indicación del número secuencial, además de la indicación de que se trata de un mensaje de baja (UNREG). En este caso no están previstos ni etiquetas de cabecera opcionales ni un cuerpo de carga útil, es decir una información o un contenido.
Como reacción a este mensaje se espera una respuesta que indique uno de los siguientes estados de respuesta (Response-Status): “200”, “400”, “500”
Baja (servidor a cliente): Como respuesta a esta baja del cliente, el servidor puede enviar a este último una confirmación de la baja. Este mensaje de confirmación puede presentar el formato siguiente:
LC/1.0 200 OK seq: x
Por regla general, el cliente no continúa procesando este paquete de datos, porque, por ejemplo, el terminal se encuentra ya en el estado de reposo. Transmisión de información (servidor a cliente): El paquete de datos para la transmisión de información puede presentar el siguiente envoltura:
MSG livecast LC/1.0 seq: x cn: <channel_number> sn: <serial_number> dc: <data_coding>
1: 123 dr: true <div><div id="ti">Title</div>...</div>
Aquí deben aparecer las indicaciones sobre el número de canal, el número de serie, el número secuencial, la codificación de los datos, la longitud del contenido y la carga útil del mensaje. El encabezamiento del informe de entrega es opcional.
El encabezamiento Channel-Number (cn) contiene el canal de mensajes en forma de un número decimal, por ejemplo “1” ó “200”, que se refiere a la banda 0xA000-0xAFFF. Los valores de este encabezamiento corresponden a los indicados en el registro con relación a los canales. Por ejemplo:
ch: 1,7,15
se refieren a los canales CB reales: 0xA001, 0xA007 y 0xA00F.
El encabezamiento Serial-Number (sn) contiene un número correlativo o número de serie del mensaje y sirve para que sea posible reconocer mensajes enviados por duplicado. El número de serie puede utilizarse además para dotar a un mensaje de una bandera que lo identifique como mensaje nuevo, si el número de serie del mensaje actual difiere del de un mensaje recibido con anterioridad, es decir que es mayor o menor. El número de serie se indica en forma de un número decimal entre 0 y 65.535 (0x0000 a 0xFFFF).
El valor del encabezamiento Data-Coding (dc) se envía en forma de un número decimal correspondiente al valor entre 0 y 255 especificado para una transmisión CB y puede ser, por ejemplo, 15. El valor se basa en el Data Coding Scheme [esquema de codificación de datos] definido en la norma 3GPP 23.038, utilizándose según la invención tanto mensajes de 7 bits como mensajes de 8 bits.
En el encabezamiento Content-Length (l), el valor del tamaño de la carga útil se indica en octetos en forma decimal. Si este valor difiere del valor real del tamaño de la carga útil, debe rechazarse el mensaje. Dado que el tamaño debe corresponder al de un mensaje CB, los mensajes con un valor mayor que 1.230 octetos deben rechazarse.
Con el encabezamiento Delivery-Report (dr) utilizada opcionalmente, se invita al cliente a enviar de vuelta un paquete de informe de entrega. El valor de este encabezamiento es booleano y puede ser, por ejemplo, “0”/”1” ó “True”/”False [verdadero/falso]” ó “Yes/No [si/no]”, para lo que preferentemente no se distingue entre mayúsculas y minúsculas.
El encabezamiento Message Payload o carga útil del paquete de datos de la información corresponde a la de un mensaje CB.
Así pues, las indicaciones necesarias en la solicitud de mensajes son, además de la indicación de que se trata de una solicitud de mensajes (MSG), las indicaciones del número secuencial, el número de canal, el número de serie, la codificación de los datos y la longitud del contenido del mensaje, es decir la carga útil. Un encabezamiento opcional puede ser una invitación al envío de un informe de entrega.
Como reacción a este mensaje no se espera ninguna respuesta o bien se espera una respuesta que indique uno de los siguientes estados de respuesta (Response-Status): “202”.
Transmisión de información (cliente a servidor):
Si el servidor ha pedido un informe de entrega, el cliente envía un paquete con el formato siguiente:
LC/1.0 202 ACCEPTED
seq: x
Esto permite al servidor asegurarse de que se ha entregado el paquete de datos y el proveedor del servicio de información puede decidir utilizar esta información si se detecta un gran número de paquetes de datos caídos y éstos han de enviarse de nuevo. Una alternativa al envío de un informe de entrega es el envío múltiple de una información. Esto sería posible, ya que, preferentemente también en el caso del Push UDP, al igual que en el caso de la transmisión CB, se cumple el requisito de ignorar información enviada por duplicado. Una forma de realizarlo es, por ejemplo, mediante el número de serie asignado al mensaje.
Notificaciones (servidor a cliente):
Las notificaciones del servidor al cliente tienen preferentemente el formato siguiente:
NOT livecast LC/1.0
not: <notification_code>
seq: x
1: xxx
A este encabezamiento puede seguirle en caso dado un texto.
La envoltura debe comprender un encabezamiento Notification Code (not) [notificación código (no)] y un encabezamiento CSeq (seq) y puede incluir opcionalmente una carga útil. Si está prevista una carga útil, debe estar incluida un encabezamiento de longitud de contenido (Content-Length (I)), que puede suprimirse si no hay carga útil.
Una posible notificación puede ser 100 (Keep Alive [mantener activa]). Ésta puede utilizarse para mantener la conexión si es necesario debido a una configuración de red. El servidor puede utilizar esta notificación también para comprobar si el cliente aún está disponible. El cliente acepta esta notificación e informa al servidor de que aún está disponible con una notificación 200 OK. Esta notificación tiene el formato siguiente:
LC/1.0 200 OK
seq: x Otra notificación que puede enviar el servidor es la notificación 101 (No More Messages [no más mensajes]). Ésta se utiliza para informar al cliente de que se ha transmitido toda la información antigua y el terminal puede permanecer
en el estado activo hasta la recepción de mensajes nuevos o puede darse de baja, si el terminal pasa al estado de reposo. Como reacción a esta notificación no es necesaria ninguna respuesta del cliente. Notificaciones (cliente a servidor) El cliente puede enviar al servidor notificaciones con el formato siguiente:
NOT livecast LC/1.0
not: <notification_code>
seq: x
1: xxx
A este encabezamiento puede seguirle en caso dado un texto.
La envoltura debe comprender un encabezamiento Notification Code (not) y un encabezamiento CSeq (seq) y puede incluir opcionalmente una carga útil. Si está prevista una carga útil, debe estar incluida un encabezamiento de longitud de contenido (Content-Length (I)), que puede suprimirse si no hay carga útil.
Una posible notificación puede ser 100 (Keep Alive). Ésta puede utilizarse para mantener la conexión si es necesario debido a una configuración de red. El cliente puede utilizar esta notificación también para comprobar si la conexión con el servidor aún está disponible. Si el cliente no recibe ninguna respuesta a esta notificación, intentará nuevamente darse de alta en el servidor. Si el servidor está disponible, aceptará la notificación y responderá con una notificación 200 OK, para informar al cliente de que aún está disponible. Sin embargo, el servidor puede responder también con un código de error 4xx ó 5xx, después de lo cual el cliente llevará a cabo los pasos mencionados en la descripción del proceso de registro.
LC/1.0 200 OK
seq: x
Otros códigos de respuesta:
El servidor puede enviar por ejemplo una respuesta 400 Bad-Request [petición errónea] si un paquete enviado por el cliente no se entiende. El mismo mensaje puede enviarse también en el caso opuesto, en el que el cliente no entiende un paquete recibido.
LC/1.0 400 Bad Request
seq: x
Un mensaje 503 Service Unavailable [servidor no disponible] se envía, siempre que sea posible, cuando se producen irregularidades en el servidor. Si es posible, el servidor envía este mensaje a todos los clientes antes de fallar. Al recibir un cliente este mensaje, intentará darse nuevamente de alta transcurridos un par de segundos.
LC/1.0 503 Service Unavailable
seq: x
Con el fin de poder optimizar aun más la experiencia del usuario y el consumo de corriente, y con ello la solicitación de la batería en el terminal, pueden tenerse en cuenta en la transmisión propuesta según la invención las reglas siguientes.
Para la transmisión mediante uno de los métodos de transmisión alternativos, así como para la recepción y el procesamiento de los mensajes CB recibidos, se tiene especialmente en cuenta el estado en el que se halla el terminal.
Si el terminal se halla en el estado de reposo, en el que las funciones del terminal están reducidas a un mínimo para minimizar el consumo de batería, según la presente invención la transmisión se realizará de la siguiente manera. Al pasar al estado de reposo se desactivan los canales CB. En este estado de reposo se despierta al terminal y se activan los canales CB automáticamente a intervalos regulares de, por ejemplo, unos minutos. Se recibe la información nueva y los canales se desactivan de nuevo después de un tiempo predefinido. La información recibida durante el estado de reposo puede presentarse inmediatamente o en el momento en que el usuario accione el terminal sacándolo de su estado de reposo. Si se recibe una información nueva, la serie de mensajes se actualiza con la nueva información y una variable interna se actualiza con el momento del mensaje CB recibido en último lugar.
Si el terminal se halla en estado de reposo y no hay mensajes CB disponibles, no se emplea ninguno de los métodos de transmisión alternativos. Hasta que no despierta el terminal no se lleva a cabo la etapa de actualización arriba descrito, con el que se transmite al cliente toda la información generada desde el mensaje CB recibido en último lugar. Sin embargo, este paso de actualización se realiza sólo si no hay ninguna otra aplicación activa cuya visualización en la pantalla sea importante para el usuario. Esto se explicará más abajo con mayor detalle.
Además del hecho de si el terminal se halla en estado de reposo, preferentemente se comprueba también si el terminal está siendo utilizado actualmente por el usuario. Si la visualización del terminal se halla en la pantalla inactiva (Idle-Screen), puede partirse de que el usuario no está utilizando actualmente el terminal. En este estado puede realizarse tanto la transmisión de información como su visualización en la pantalla. Si se despierta a un terminal y éste pasa al estado inactivo, se inicia un temporizador, por ejemplo a 5 segundos. Si el temporizador ha terminado y el terminal continúa aún en el modo inactivo o si el usuario solicita de forma activa la información más reciente, por ejemplo navegando en un menú que pone a disposición el cliente, puede iniciarse el método de transmisión alternativo, en particular el Push UDP, y el contenido de la información se actualiza regularmente. Antes de iniciar el Push UDP, el cliente comprobará en primer lugar si el último mensaje CB recibido es más antiguo que un valor de tiempo predefinido y sólo si es éste el caso se inicia el Push UDP. Una vez iniciado el Push UDP, la información se recibe de forma asincrónica y está a disposición del usuario en tiempo real.
También después de encenderse el terminal, el cliente esperará un intervalo de tiempo predefinido y sólo una vez transcurrido este intervalo de tiempo sin haberse recibido ningún mensaje CB recurrirá a uno de los métodos de transmisión alternativos.
Además se comprueba preferentemente si en el terminal se está ejecutando una aplicación. Si la aplicación se trata por ejemplo de la navegación a través de campos puestos a disposición por el cliente, se parte de que el usuario también está interesado en ese momento en recibir la información más reciente y, por lo tanto, se procede como se ha descrito más arriba para el modo inactivo (Idle). Especialmente si el usuario acciona una tecla o un campo mediante la cual o el cual se solicite la recepción de los mensajes más recientes, se inicia inmediatamente el Push UDP.
Si, por el contrario, la aplicación ejecutada actualmente es una aplicación distinta, el Push UDP no se activa en la etapa del modo inactivo al modo de aplicación. Hasta que el usuario no pone el terminal de nuevo en el modo inactivo o navega por el menú del cliente no se activa el UDP. En cambio, si el terminal ya está conectado a la red para el Push UDP, al iniciarse una aplicación distinta se observan las reglas siguientes. Si la aplicación iniciada requiere una conexión a la red IP y puede utilizar el mismo contexto PDP que el ya establecido para el Push UDP, la aplicación lo utiliza. Una vez terminada la aplicación se mantiene el contexto PDP. Como alternativa puedeestablecerse un contexto PDP adicional para la aplicación. Éste puede ser el caso, por ejemplo, si la aplicación utiliza el mismo APN (access point name) que el Push UDP, pero no es posible una utilización conjunta de la conexión. Este contexto PDP adicional o paralelo puede abandonarse sin influir en el Push UDP al terminar la aplicación. Si la aplicación es una aplicación que requiera una conexión a la red IP pero admita sólo un contexto PDP, se abandona el contexto PDP para el Push UDP y se establece un contexto PDP propio, que se abandona al terminar la aplicación. Es preferible que al terminar la aplicación el Push UDP no se inicie de nuevo automáticamente.
Si el cliente detecta que la conexión IP ha caído, se dará nuevamente de alta. Si, por ejemplo, una conexión 3G es mala y el terminal cambia a una conexión 2G, el terminal puede separarse automáticamente del contexto PDP para 3G, conectarse de nuevo mediante un contexto PDP para 2G y obtener una nueva conexión IP. El cliente detectará si este nuevo contexto PDP está activado y se dará nuevamente de alta en el servidor. Si el contexto PDP para 2G no se activa automáticamente, el cliente tendrá en cuenta las condiciones arriba indicadas para decidir si debe establecerse una conexión. En particular puede tenerse en cuenta la disponibilidad de mensajes CB o el estado de funcionamiento del terminal y el uso de un alta distinta.
El usuario puede activar en el terminal una presentación, o abrir una ventana, en la que puede seleccionar los canales que le interesen. Si durante la existencia de un registro en un servidor para un Push UDP se modifica esta ventana de selección de canales abierta, el cliente se dará de baja en el servidor y luego nuevamente de alta para actualizar la lista de canales. En el cliente puede estar depositada una lógica según la cual pueda detectarse si realmente se han modificado los canales y poder evitar así una nueva alta si la lista de canales no ha sufrido cambios.
La información enviada al cliente puede incluir hipervínculos relativos. Éstos se enlazan en el cliente con un URL base para generar un hipervínculo absoluto. En la transmisión CB, el hipervínculo debería depender del país. En cambio, en la transmisión UDP el hipervínculo debería ser siempre el hipervínculo del país de origen y no debería sustituirse el país.
Dado que si se utiliza el Push UDP en un escenario de itinerancia (Roaming) pueden generarse tasas, puede estar prevista en un menú de ajuste para el cliente la opción de desactivar el portador de Push UDP en caso de itinerancia. El ajuste por defecto de esta opción es preferentemente ‘desactivada’. Si el usuario se conecta a la red IP y el cliente utiliza durante la itinerancia un método de transmisión alternativo, puede estar prevista una lógica que permita transmitir sólo una pequeña cantidad de información o sólo información seleccionada relacionada con el lugar en el que se halla el usuario, como por ejemplo partes meteorológicos o información del tráfico.
Para realizar el protocolo de comunicación descrito y el procedimiento según la invención debería estar soportado preferentemente por radiodifusión celular como método de transmisión en todos los canales de acceso a radiotelefonía (2G y 3G) que soporte el terminal o aparato terminal móvil.
La unidad de gestión o el cliente del terminal debería soportar preferentemente todos los canales entre 0 y 4.095, correspondientes a OxA000 en CB, y también poder funcionar independientemente del servicio de radiodifusión celular. En el cliente pueden almacenarse preferentemente al menos 150 informaciones y éstas se procesan preferentemente según el método FIFO (First in first out [primero en entrar primero en salir]), lo que significa que la información recibida en primer lugar es también la primera en ser borrada de la memoria. El cliente soporta preferentemente al menos 128 canales simultáneos.
Con la presente invención se hace posible iniciar una comunicación Push UDP sólo cuando ésta sea realmente necesaria y mantenerla a continuación tanto como sea posible sin perjudicar a otras aplicaciones ejecutadas en el aparato terminal móvil y permitiendo además la conmutación del aparato terminal móvil a un estado de reposo, con lo que se aumenta la vida útil de la batería.

Claims (19)

  1. REIVINDICACIONES
    1. Procedimiento para transmitir información desde un servidor de información a un aparato terminal móvil mediante una red de radiotelefonía móvil, con las siguientes etapas:
    -
    envío de información de un servicio del servidor de información mediante, al menos, un canal de radiodifusión celular,
    -
    recepción de una solicitud de alta de un aparato terminal móvil para transmitir información del servicio como paquetes de datos según el protocolo IP,
    -
    extracción, a partir de la solicitud de alta, de una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil,
    -
    comparación de la información del servicio recibida en último lugar en el aparato terminal móvil con la información almacenada en el servidor de información y
    -
    transmisión, como paquetes de datos según el protocolo IP, de los mensajes generados tras la información del servicio recibida en último lugar en el aparato terminal móvil.
  2. 2.
    Procedimiento según la reivindicación 1, caracterizado porque comprende la etapa de extracción, a partir de la solicitud de alta, de al menos una indicación de canales de información.
  3. 3.
    Procedimiento según la reivindicación 2, caracterizado porque comprende la etapa de extracción, a partir de la solicitud de alta, de una indicación sobre la información recibida en último lugar en el aparato terminal móvil en al menos un canal de información incluido en la solicitud de alta, de la comparación de la información recibida en último lugar en el aparato terminal móvil en este canal de información con la información almacenada en el servidor de información y de la transmisión al aparato terminal móvil de la información almacenada en este canal de información tras la información recibida en último lugar en el aparato terminal móvil.
  4. 4.
    Procedimiento según una de las reivindicaciones 1 a 3, caracterizado porque comprende la etapa de verificación de la transmisión al aparato terminal móvil de toda la información detectada en la comparación que esté almacenada en el servidor de información pero aún no recibida en el aparato terminal móvil, de la generación de un mensaje final y de la transmisión del mensaje final al aparato terminal móvil, transmitiéndose al aparato terminal móvil, opcionalmente, tras la transmisión del mensaje final, la información nueva generada en el servidor de información.
  5. 5.
    Procedimiento según una de las reivindicaciones 1 a 4, caracterizado porque comprende la etapa de recepción de una solicitud de baja del aparato terminal móvil y la etapa de baja del aparato terminal móvil.
  6. 6.
    Procedimiento según una de las reivindicaciones 1 a 5, caracterizado porque la transmisión de la información de acuerdo con el protocolo IP se realiza mediante una transmisión de punto a punto, de multidifusión o de radiodifusión.
  7. 7.
    Procedimiento para recibir, desde un servidor de información, información de un servicio en un aparato terminal móvil de una red de radiotelefonía móvil, ejecutándose, en el aparto terminal móvil, las siguientes etapas:
    -
    supervisión de al menos un canal de radiodifusión celular,
    -
    si se detecta la ausencia de información en el o los canales de radiodifusión celular, ejecución de las siguientes etapas:
    -
    generación de una solicitud de alta que incluye una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil,
    -
    transmisión de la solicitud de alta al servidor de información y
    -
    recepción en forma de paquetes de datos según el protocolo IP de información generada tras la información del servicio recibida en último lugar en el aparato terminal móvil.
  8. 8.
    Procedimiento según la reivindicación 7, caracterizado porque comprende la etapa de verificación de datos almacenados en el aparato terminal móvil.
  9. 9.
    Procedimiento según una de las reivindicaciones 7 u 8, caracterizado porque comprende la etapa de supervisión del estado de funcionamiento del aparato terminal móvil, comprendiendo el procedimiento opcionalmente, al detectarse el cambio del estado de funcionamiento del aparato terminal móvil, la etapa de generación y transmisión de un mensaje de baja al servidor de información.
  10. 10.
    Procedimiento según una de las reivindicaciones 1 a 9, caracterizado porque la información se transmite en paquetes de datos según el protocolo de datagramas de usuario UDP.
  11. 11.
    Procedimiento según una de las reivindicaciones 1 a 10, caracterizado porque la solicitud de alta incluye al menos una indicación sobre el momento de recepción de la información recibida en último lugar en el aparato terminal móvil.
  12. 12.
    Procedimiento según una de las reivindicaciones 1 a 11, caracterizado porque para la comunicación entre el servidor de información y el o los equipos terminales móviles se utilizan cuatro tipos de mensajes, constituyendo opcionalmente un tipo de mensaje una notificación, un tipo de mensaje una solicitud de alta, un tipo de mensaje una solicitud de baja y un tipo de mensaje una transmisión de información e identificándose además opcionalmente los distintos tipos de mensajes mediante una indicación en la línea de inicio del mensaje.
  13. 13.
    Servidor de información para una red de radiotelefonía móvil, caracterizado porque dicho servidor de información comprende:
    al menos una unidad de recepción, que sirve al menos para recepción de solicitudes transmitidas según el protocolo IP, y
    al menos una unidad de procesamiento para procesar la o las solicitudes recibidas, que comprende una unidad de extracción para extraer de las solicitudes recibidas una indicación sobre la información del servicio recibida en último lugar en un aparato terminal móvil,
    porque el servidor de información presenta una unidad de comparación para comparar la información recibida en último lugar en el aparato terminal móvil con información almacenada en el servidor y
    porque el servidor de información comprende al menos una unidad de salida para transmitir mensajes a un aparato terminal móvil, estando la unidad de salida diseñada para transmitir mensajes de radiodifusión celular y transmitir paquetes de datos según un protocolo IP y transmitiendo la unidad de salida mediante el protocolo IP, los mensajes generados tras la información del servicio recibida en último lugar en el aparato terminal móvil.
  14. 14.
    Servidor de información según la reivindicación 13, caracterizado porque comprende una unidad de generación de mensajes para generar al menos un mensaje, comprendiendo dicho servidor de información, opcionalmente, una unidad de memoria para almacenar información, estando la unidad de generación de mensajes conectada, al menos temporalmente, a la unidad de memoria y estando la unidad de comparación conectada, al menos temporalmente, a la unidad de memoria del servidor de información.
  15. 15.
    Servidor de información según una de las reivindicaciones 13 ó 14, caracterizado porque la unidad de salida presenta un mecanismo de adición que permite añadir la transmisión de paquetes de datos según el protocolo IP a la transmisión de mensajes de radiodifusión celular.
  16. 16.
    Aparato terminal móvil para utilizar en una red de radiotelefonía móvil que está diseñado para recibir y transmitir paquetes de datos mediante un protocolo IP, caracterizado porque dicho equipo terminal tiene una unidad de gestión que está diseñada para recibir información mediante, al menos, dos tipos diferentes de transmisión y para la supervisión de la recepción de información, supervisándose al menos un canal de radiodifusión celular, que sirve para transmitir información desde un servidor de información, y, si se detecta la ausencia de información en el canal de radiodifusión celular, generándose una solicitud de alta destinada a ser transmitida al servidor de información para efectuar el alta en el servidor de información para la transmisión de información, incluyendo la solicitud de alta una indicación sobre la información del servicio recibida en último lugar en el aparato terminal móvil y estando la unidad de gestión diseñada para recepción según el protocolo IP de los mensajes generados tras una información del servicio recibida en último lugar en el aparato terminal móvil.
  17. 17.
    Aparato terminal móvil según la reivindicación 16, caracterizado porque la unidad de gestión está diseñada para almacenar y presentar información recibida.
  18. 18.
    Aparato terminal móvil según la reivindicación 16 ó 17, caracterizado porque la unidad de gestión decide sobre el tipo de transmisión entre el servidor de información y el aparato terminal móvil.
  19. 19.
    Aparato terminal móvil según una de las reivindicaciones 16 a 18, caracterizado porque la unidad de gestión está diseñada para supervisar el estado de funcionamiento del aparato terminal móvil y/o para generar mensajes.
ES06012551T 2005-06-20 2006-06-19 Procedimiento y dispositivo para transmitir información desde un servidor de información a un aparato terminal móvil y aparato terminal móvil Active ES2377506T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005028496 2005-06-20
DE102005028496A DE102005028496A1 (de) 2005-06-20 2005-06-20 Verfahren zur Übermittlung von Informationen von einem Informationsserver, Informationsserver, Kommunikationsprotokoll, mobiles Endgerät und Verfahren zur Verwaltung von Informationen

Publications (1)

Publication Number Publication Date
ES2377506T3 true ES2377506T3 (es) 2012-03-28

Family

ID=36940668

Family Applications (1)

Application Number Title Priority Date Filing Date
ES06012551T Active ES2377506T3 (es) 2005-06-20 2006-06-19 Procedimiento y dispositivo para transmitir información desde un servidor de información a un aparato terminal móvil y aparato terminal móvil

Country Status (4)

Country Link
EP (2) EP1737195B1 (es)
AT (1) ATE536692T1 (es)
DE (1) DE102005028496A1 (es)
ES (1) ES2377506T3 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103442011A (zh) * 2013-09-02 2013-12-11 北京网秦天下科技有限公司 移动终端、服务器和方法
CN106656753B (zh) * 2016-12-08 2020-02-21 北京五八信息技术有限公司 一种im历史消息排序的方法、装置及终端

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6119003A (en) * 1996-09-09 2000-09-12 Nokia Mobile Phones Limited Methods and apparatus for performing automatic mode selection in a multimode mobile terminal
US20040078814A1 (en) * 2002-03-29 2004-04-22 Digeo, Inc. Module-based interactive television ticker
US20050076369A1 (en) * 2003-10-06 2005-04-07 Zhijun Cai Method and apparatus for assigning temporary mobile group identity in a multimedia broadcast/multicast service

Also Published As

Publication number Publication date
EP1737195A3 (de) 2007-01-03
ATE536692T1 (de) 2011-12-15
DE102005028496A1 (de) 2006-12-28
EP1737195B1 (de) 2011-12-07
EP2352270A2 (de) 2011-08-03
EP2352270A3 (de) 2011-08-24
EP1737195A2 (de) 2006-12-27

Similar Documents

Publication Publication Date Title
Stanford-Clark et al. Mqtt for sensor networks (mqtt-sn) protocol specification
CN106686561B (zh) 支持移动终接短消息递送的方法和装置
US6839562B2 (en) Intelligent delivery agent for short message distribution center
CA2905889C (en) Systems and methods for delivering multimedia information to mobile devices
FI111595B (fi) Järjestely multimediasanomanvälityksen toteuttamiseksi
US20100323725A1 (en) Individualized retry configurations for messages having failed delivery
US20080090599A1 (en) Location Specific Broadcast System and Receiver
CN100438433C (zh) 用于同步imps客户端状态信息的方法
JP2007500891A (ja) メッセージ処理
US8484370B1 (en) Method and system for efficient extended data communications using GPRS
US20050235046A1 (en) System and method for implementing a wireless access protocol push
US11706590B1 (en) Method and system to facilitate media-content delivery
KR20240099420A (ko) 하나의 ue의 다중 세션에 대한 동일한 이벤트 구독을 위한 방법 및 장치
AU2005201570B2 (en) System and method for implementing a wireless access protocol push
US12526610B2 (en) Message transmission in a multi-terminal context
US11576013B2 (en) Proxy gateway mediated internet-enabled data consumption over unstructured supplementary service data
WO2006050751A1 (en) Provision of a multimedia message
EP1737195B1 (de) Verfahren und Vorrichtung zur Übermittlung von Informationen von einem Informationsserver zu einem mobilen Endgerät und ein mobiles Endgerät
US20260089470A1 (en) Mobile Terminated Short Message Service for Non-terrestrial Network Short Message Service Delivery
EP3288297A1 (en) Support of group based message delivery in a mobile system
KR20050011783A (ko) Ｍｍｓ 전송 대리 서버를 이용한 ｍｍｓ 메시지 전송시스템 및 방법
CN111788779A (zh) 用于向多个接收器广播数字数据的系统和方法
HK1084260A (en) System and method for implementing a wireless access protocol push