ES2315888T3 - Procedimiento para procesar notificacion push en servicios de mensajes multimedia. - Google Patents
Procedimiento para procesar notificacion push en servicios de mensajes multimedia. Download PDFInfo
- Publication number
- ES2315888T3 ES2315888T3 ES05766712T ES05766712T ES2315888T3 ES 2315888 T3 ES2315888 T3 ES 2315888T3 ES 05766712 T ES05766712 T ES 05766712T ES 05766712 T ES05766712 T ES 05766712T ES 2315888 T3 ES2315888 T3 ES 2315888T3
- Authority
- ES
- Spain
- Prior art keywords
- field
- push notification
- short message
- bytes
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
- H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Un procedimiento para procesar una notificación PUSH en un servicio de mensajes multimedia, que comprende: colocar campos no comprimibles de la notificación PUSH en la notificación PUSH (301), comprimir un campo de ContenidoTipo que indica el tipo de mensaje y un campo de X-Mms-Transacción-identificación, X-Mms-Transacción- ID, de la ID Interna, colocando el campo de ContenidoTipo comprimido y el campo de X-Mms-Transacción-ID en la notificación PUSH (302); determinar si la notificación PUSH puede ser portada en un mensaje corto (303); si la notificación PUSH puede ser portada en un mensaje corto, obtener la notificación PUSH portada en un mensaje corto (304); si la notificación PUSH no puede ser portada en un mensaje corto, obtener la notificación PUSH portada en dos mensajes cortos (305); determinar si existen bytes no ocupados en el mensaje corto (306); si existen bytes no ocupados en el mensaje corto, determinar si debe disponerse un campo Desde que indique un iniciador del mensaje en la notificación PUSH de acuerdo con el número de bytes no ocupados en el mensaje corto (308), y determinar si debe comprimirse un campo Sujeto así como colocar el campo Sujeto en la notificación PUSH de acuerdo con el número de bytes no ocupados en el mensaje corto (308); si el campo Desde ha sido ya dispuesto en el mensaje corto, siempre que no existan bytes suficientes en el mensaje corto para contener el campo Sujeto, desechar el campo Sujeto; si existen bytes no ocupados en el mensaje corto, pero el campo Desde no puede ser mantenido en el mensaje corto, desechar el campo Desde y el campo Sujeto que no estén colocados en la notificación PUSH (308).
Description
Procedimiento para procesar notificación PUSH en
servicios de mensajes multimedia.
La presente invención se refiere a tecnología de
comunicación de información multimedia, y más en particular a un
procedimiento para notificación PUSH en servicios de mensajes
multimedia.
El Servicio de Mensajes Multimedia (MMS) es el
desarrollo ulterior del Servicio de Mensajes Cortos (SMS) y de
transferencia de información gráfica, que asegura que se puede
transferir el contenido plenamente funcional y la información que
contiene gráficos, información de audio, información de video, datos
y texto. Los MMS pueden transferir la información multimedia al
instante de terminal a terminal de teléfono móvil, y también entre
teléfonos móviles e internet. El Centro de Servicio de Mensajes
Multimedia (MMSC) es el elemento de red que sirve para suministrar
mensajes multimedia a las redes.
La Versión 1.2 de Open Mobile Alliance
Multimedia Messaging Service Encapsulation Protocol Candidate,
OMA-MMS-ENC-V1_2-20040323-C
forma parte de la especificación serie OMA MMS, y cumple con los
requisitos y con las descripciones de comportamiento de servicio,
descritos en las especificaciones técnicas de Partnership Project de
3ª Generación (3GPP) y de Partnership Project2 de 3ª Generación
(3GPP2). Éstas incluyen los aspectos de servicio de MMS y la
descripción funcional de MMS, que están contenidos en [TS23140]
para la 3GPP y en [XS0016200] para la 3GPP2.
El documento EP 1 361 712 A describe un
procedimiento y un equipo para la comunicación de mensajes de datos,
tales como mensajes MMS, a un equipo de comunicación electrónica
direccionado. De acuerdo con la invención, solamente los mensajes
notificados por un MMSC conocido e identificado, son descargados en
el equipo. Esto se consigue debido a que se compara un
identificador de centro de mensaje, almacenado en el equipo, con un
identificador de centro de mensaje comprendido en la notificación.
Si se emparejan los identificadores, el cuerpo del mensaje puede
ser descargado.
En el proceso de transferencia del mensaje
multimedia, el MMSC activa el flujo de entrega cuando el MMSC recibe
un mensaje multimedia enviado por el terminal MMS, por el Proveedor
de Servicio de Valor Añadido (VASP) o por un servidor de correo. El
flujo emitido incluye dos fases: proceso de notificación PUSH y
proceso de recuperación de mensaje. El proceso de notificación PUSH
del MMS se refiere principalmente a que el MMSC tiene la
notificación PUSH portada en uno o en una pluralidad de
mensaje(s) corto(s) y transfiere la notificación al
terminal receptor, siendo la información asociada del mensaje
multimedia portada en la notificación PUSH: la información de
direccionamiento requerida por el terminal de recepción para
recuperar el mensaje multimedia, el ID del suministrador, el Sujeto
del mensaje multimedia, y la información de direccionamiento del
terminal de recepción, de los que la información de
direccionamiento porta la dirección del MMSC y la ID única del
mensaje multimedia en el MMSC. El terminal de recepción activa el
proceso de recuperación de mensaje cuando el terminal de recepción
recibe los mensajes cortos y los combina en la notificación PUSH,
es decir, el terminal de recuperación inicia una petición de
recuperación de mensaje al MMSC que salva los mensajes multimedia de
acuerdo con la información de direccionamiento portada por la
notificación PUSH, y recupera los mensajes multimedia.
En las especificaciones estándar
internacionales, el mensaje de notificación PUSH incluye:
(1) TID: identificación de transacción, cuya
longitud es de 1 byte;
(2) Tipo: que indica el tipo de mensaje; el Tipo
indica que el mensaje es una notificación PUSH cuando el valor es
de 0x06, y la longitud del Tipo es de 1 byte;
(3) EncabezadorLen: que indica la longitud del
encabezador del mensaje; el EncabezadorLen adopta códigos uintvar,
cuya longitud es de 1 byte;
(4) ContenidoTipo: que indica el tipo común del
mensaje; en el caso de la notificación PUSH de MMS, existen dos
formas de expresión: una forma consiste en la aplicación de cadena
de caracteres/vnd.wap.mms-mensaje que ocupa 32
bytes, y la otra forma se expresa con códigos binarios 0x3E que
ocupan 1 byte; con preferencia el ContenidoTipo adopta la forma de
expresión de cadena de caracteres en la mayor parte de los
casos.
(5) Encabezadores: que indican el contenido de
la cabecera de mensaje; la longitud del Encabezador es igual a la
diferencia entre el valor del campo EncabezadorLen y la longitud del
campo ContenidoTipo;
(6)
X-Mms-Mensaje-Tipo:
que indica el tipo de unidad de datos de protocolo del MMS; el valor
del mensaje de notificación PUSH es 130, cuya longitud es de 1
byte;
\newpage
(7)
X-Mms-Transacción-ID:
la ID interna asignada por el MMSC para asegurar que la parte
receptora está capacitada para recuperar el mensaje multimedia
correctamente; cuyas reglas de longitud y codificación son asignadas
e identificadas por el MMSC; y siendo la longitud variable;
(8)
X-Mms-MMS-Versión:
que indica la versión de MMS, cuya longitud es de 2 bytes;
(9) Desde: que indica el iniciador del mensaje
multimedia, cuya longitud mínima es de 4 bytes;
(10) Sujeto: que indica el Sujeto del mensaje
multimedia; una vez que el mensaje multimedia ha sido codificado
mediante UTF-8, la longitud mínima de Sujeto es de 6
bytes cuando la longitud del mensaje multimedia es mayor que, o
igual a, 31 bytes; en otro caso, la longitud mínima de Sujeto es de
5 bytes;
(11)
X-Mms-Mensaje-Clase:
que indica la clase del mensaje multimedia; por ejemplo, si el
mensaje multimedia pertenece a un individuo, a publicidad o a
alguna clase de información; la longitud de
X-Mms-Mensaje-Clase
es de 2 bytes;
(12)
X-Mms-Mensaje-Tamaño:
que indica la longitud del mensaje multimedia, cuya longitud es de 5
ó 6 bytes después de adoptar códigos enteros largos;
(13)
X-Mms-Caducidad: que indica el
período de validez de un mensaje multimedia, cuya longitud es de 7 u
8 bytes;
(14)
X-Mms-Contenido-Posición:
que indica la dirección de Identificación de Recurso Unitario (URI)
para un mensaje multimedia, que incluye al menos la dirección del
MMSC y la ID de la transacción del mensaje multimedia, de las que
la dirección del MMSC puede ser una dirección de IP y un número de
puerto, o un nombre de dominio cuya longitud sea variable, y siendo
también variable la longitud de esta parte.
La notificación PUSH procesada con el formato
anterior, es enviada a la parte receptora por la parte iniciadora
del mensaje multimedia, a través de una pluralidad de enlaces
intermedios. Y la notificación PUSH incluye el proceso de
recuperación de mensaje con anterioridad a que se realice la entrega
de un mensaje multimedia. Los procesos de entrega de un mensaje
multimedia son similares en GSM, GPRS, WCDMA, CDMA95, CDMA2000, y
otras redes, por lo que se ha tomado el proceso de entrega de un
mensaje multimedia en GSM como ejemplo para la descripción de la
solución técnica.
La notificación PUSH de mensaje multimedia puede
ser entregada a través de Acceso de Aplicación Inalámbrica (WAPGW)
o por el MMSC directamente.
La Figura 1 ilustra el proceso en el que la
parte iniciadora, tal como un terminal MMS, un VASP o un servidor
de correo, envía un mensaje multimedia que adopta la notificación
PUSH del formato existente para la parte receptora a través de
WAPGW, que incluye:
Etapas 11\sim12: la parte iniciadora del
mensaje multimedia presenta el mensaje multimedia que va a ser
suministrado al MMSC; una vez recibido el mensaje multimedia, el
MMSC activa el flujo de notificación PUSH para emitir la
notificación PUSH hasta el terminal MMS de recepción.
El proceso específico para emitir la
notificación PUSH incluye:
Etapa 1201: El MMSC envía a la WAPGW un
mensaje-push portador de la notificación PUSH, y
registra las veces que ha de ejecutar esta etapa.
Etapa 1202: La WAPGW devuelve una
respuesta-push al MMSC después de que la WAPGW ha
recibido el mensaje-push.
Etapa 1203: La WAPGW adopta el protocolo de
interfaz entre la WAPGW y el sistema de mensajes cortos para
empaquetar la notificación PUSH del mensaje-push en
un mensaje corto, envía un mensaje de presentación presentar_sm al
sistema de mensajes cortos, y registra las veces que se ha de
ejecutar esta etapa.
El sistema de mensajes cortos incluye en este
caso el Centro de Servicio de Mensajes Cortos (SMSC) y el acceso de
mensajes cortos. El protocolo de interfaz entre la WAPGW y el
sistema de mensajes cortos puede ser el Protocolo
Punto-a-Punto de Mensajes Cortos
(SMPP), el Protocolo Universal de Ordenador (UCP), el Protocolo de
Entrega de Mensaje de Interfaz de Ordenador (CIMD), u otros
protocolos del mismo tipo.
Etapa 1024: El sistema de mensajes cortos
devuelve un mensaje de respuesta presentar_sm_resp a la WAPGW
después de que el sistema de mensajes cortos recibe el de
presentar_sm.
A continuación, el sistema de mensajes cortos
emite un mensaje corto al terminal MSC/MMS de la parte
receptora.
\newpage
Etapa 1205: El sistema de mensajes cortos
determina la dirección del Registro de Posición Local (HLR) del
terminal MMS de recepción de acuerdo con la información de dirección
de la parte receptora portada en la notificación PUSH de
presentar_sm, envía un mensaje map_sri_for_req de petición de
enrutador al HLR, y registra el número de veces que ha de ejecutar
esta etapa.
Etapa 1206: Habiendo recibido el
map_sri_for_sm_req, el HLR devuelve al sistema de mensajes cortos un
mensaje map_sri_for_sm_resp de respuesta de enrutador, que porta la
dirección del Centro de Conmutación Móvil (MSC) en el que la parte
de recepción está situada actualmente.
Etapas 1207\sim108: El sistema de mensajes
cortos envía mediante un mensaje corto a la parte receptora, una
petición map_mt_fwd_sm_req para que emita un mensaje corto que
porte la notificación PUSH de acuerdo con la información de
enrutador portada por el mensaje de respuesta map_sri_for_sm_resp, y
la parte receptora devuelve al sistema de mensajes cortos una
mpa_mt_fwd_sm_resp, indicando si la notificación PUSH ha sido
emitida con éxito. A continuación, la parte receptora determina si
el SMSC ha recibido, en un tiempo preestablecido, la
map_mt_fwd_sm_resp portadora de la información indicadora de que la
notificación PUSH ha sido emitida con éxito; en caso afirmativo,
lleva a cabo la Etapa 1209; en otro caso, el sistema de mensajes
cortos elige si debe re-emitir la notificación y el
momento de la re-emisión de acuerdo con la
estrategia de re-emisión interna; el sistema de
mensajes cortos determina si las veces que se ha ejecutado la Etapa
1205 han excedido el valor preestablecido cuando el sistema de
mensajes cortos está a punto de re-emitir la
notificación, y si las veces que se ha ejecutado la Etapa 1205 han
excedido las veces preestablecidas, el sistema de mensajes cortos
determina que la emisión de la notificación PUSH ha fallado y lleva
a cabo la Etapa 1209; si las veces que se ha ejecutado la Etapa 1205
no han excedido las veces preestablecidas, el sistema de mensajes
cortos adopta la estrategia de re-emisión y retorna
a la Etapa 1205.
Hasta ahora, se ha ejecutado el flujo en el que
el sistema de mensajes cortos emite un mensaje corto al terminal
MSC/MMS de la parte receptora.
Etapas 1209\sim1210: El sistema de mensajes
cortos envía a la WAPGW uno de entregar_sm, indicando si la
notificación PUSH ha sido emitida con éxito. Al recibir
entregar_sm, la WAPGW devuelve al sistema de mensajes cortos una
respuesta entregar_sm_resp de informe de entrega, y determina si la
notificación PUSH ha sido emitida con éxito de acuerdo con
entregar_sm; en caso afirmativo, avanza a la Etapa 1211; en otro
caso, la WAPGW determina si ha de re-emitir la
notificación de acuerdo con la estrategia de
re-emisión interna; la WAPGW determina si las veces
que se ha ejecutado la Etapa 1203 han excedido el valor
preestablecido cuando la WAPGW está a punto de
re-emitir la notificación, y si las veces que se ha
ejecutado la Etapa 1203 han excedido las veces preestablecidas, la
WAPWG determina que la notificación PUSH ha fallado y lleva a cabo
la Etapa 1211; si las veces que se ha ejecutado la Etapa
1203
no han excedido las veces preestablecidas, la WAPGW adopta la estrategia de re-emisión y retorna a la Etapa 1203.
no han excedido las veces preestablecidas, la WAPGW adopta la estrategia de re-emisión y retorna a la Etapa 1203.
Etapas 1211\sim1212: La WAPGW envía al MMSC un
mensaje resultadonotificación-mensaje de
notificación de resultado, que indica si la notificación PUSH ha
sido emitida con éxito. El MMSC devuelve a la WAPGW un mensaje de
respuesta resultadonotificación-respuesta después
de que el MMSC ha recibido el mensaje de notificación de resultado,
y determina si la notificación PUSH ha sido emitida con éxito de
acuerdo con el mensaje recibido; en caso afirmativo, el MMSC
termina el flujo de la notificación PUSH; en otro caso, el MMSC
selecciona si ha de re-emitir la notificación y el
momento de la re-emisión de acuerdo con la
estrategia de re-emisión interna; el MMSC determina
si las veces que se ha ejecutado la Etapa 1201 han excedido el valor
preestablecido cuando el MMSC está a punto de
re-emitir la notificación, y si las veces que se ha
ejecutado la Etapa 1201 han excedido las veces preestablecidas, el
MMSC determina que la emisión de la notificación PUSH ha fallado,
termina el flujo de entrega de la notificación PUSH, y lleva a cabo
la Etapa 17; si las veces que se ha ejecutado la Etapa 1201 no han
excedido las veces preestablecidas, el MMSC adopta la estrategia de
re-emisión y retorna a la Etapa 1201.
Hasta ahora, se ha completado el flujo de la
notificación PUSH.
Etapas 13\sim16: El MMSC interactúa con el
terminal MSC/MMS de recepción para recuperar el mensaje.
Etapa 17: El MMSC envía a la parte iniciadora un
informe de estado de entrega de mensaje multimedia, indicando si la
parte receptora ha recibido con éxito el mensaje multimedia.
Cuando la emisión de la notificación PUSH ha
sido completada, la parte iniciadora y la parte receptora recuperan
el mensaje multimedia de acuerdo con el flujo de recuperación de
mensaje desde la Etapa 13 hasta la Etapa 17, para realizar la
entrega del mensaje multimedia.
Lo que antecede constituye el flujo para emitir
un mensaje multimedia a través de la WAPWG, y lo que sigue es el
flujo para emitir un mensaje multimedia directamente por el
MMSC.
La Figura 2 ilustra el proceso para emitir un
mensaje multimedia que adopta la notificación PUSH del formato
saliente directamente por el MMSC hasta la parte receptora, que
incluye:
Etapa 21\sim22: La parte iniciadora del
mensaje multimedia presenta el mensaje multimedia al MMSC. Al
recibir el mensaje multimedia, el MMSC activa el proceso de
notificación PUSH, y emite la notificación PUSH a la parte
receptora.
El proceso de notificación PUSH incluye en este
caso:
Etapa 2201: El MMSC adopta el protocolo de
interfaz que es susceptible de comunicar con el sistema de mensajes
cortos para empaquetar la notificación PUSH en un mensaje corto,
envía mediante el protocolo de interfaz al sistema de mensajes
cortos un mensaje de presentación presentar_sm portador de la
notificación PUSH, y registra el número de veces que se ha de
ejecutar esta etapa.
Etapa 2202: El sistema de mensajes cortos
devuelve al MMSC un mensaje de respuesta presentar_sm_resp tras la
recepción de presentar_sm.
A continuación, el sistema de mensajes cortos
emite un mensaje corto a la parte receptora.
Etapa 2203: El sistema de mensajes cortos
determina la dirección de HLR de la parte receptora de acuerdo con
la información de dirección de la parte receptora portada en la
notificación PUSH de presentar_sm, envía un mensaje
map_sri_for_sm_req de petición de enrutador al HLR, y registra el
número de veces que se va a ejecutar esta etapa.
Etapa 2204: Al haber recibido el
map_sri_for_sm_req, el HLR devuelve al sistema de mensajes cortos un
mensaje map_sri_for_sm_resp de respuesta de enrutador, indicando la
dirección del MSC en el que se encuentra situada actualmente la
parte receptora.
Etapas 2205\sim2206: El sistema de mensajes
cortos envía, mediante un mensaje corto a la parte receptora, un
mensaje de petición map_mt_fwd_sm_req para emitir un mensaje corto
portador de la notificación PUSH de acuerdo con la información de
enrutador portada en el mensaje de respuesta map_sri_for_sm_resp, y
la parte receptora devuelve al sistema de mensajes cortos uno de
map_mt_fwd_sm_resp, indicando si la notificación PUSH ha sido
emitida con éxito. A continuación, el sistema de mensajes cortos
determina en un momento preestablecido, si el sistema de mensajes
cortos ha recibido el map_mt_fwd_sm_resp portador de la información
indicativa de que la notificación PUSH ha sido emitida con éxito;
en caso afirmativo, avanza hasta la Etapa 2207; en otro caso, el
sistema de mensajes cortos elige si ha de re-emitir
la notificación y el momento de la re-emisión de
acuerdo con la estrategia de re-emisión interna; el
sistema de mensajes cortos determina si las veces que se ha
ejecutado la Etapa 2203 han excedido el valor preestablecido cuando
el sistema de mensajes cortos está a punto de
re-emitir la notificación, y si las veces que se ha
ejecutado la Etapa 2203 han excedido las veces preestablecidas, el
sistema de mensajes cortos determina que la emisión de la
notificación PUSH ha fallado, y lleva a cabo la siguiente etapa; si
las veces que se ha ejecutado la Etapa 2203 no han excedido las
veces preestablecidas, el sistema de mensajes cortos adopta la
estrategia de re-emisión, y retorna a la Etapa
2203.
Hasta ahora, se ha ejecutado el flujo en el que
el sistema de mensajes cortos emite el mensaje corto a la parte
receptora.
Etapas 2207\sim2208: El sistema de mensajes
cortos envía al MMSC un mensaje entregar_sm de informe de entrega,
que indica si la notificación PUSH ha sido emitida con éxito. Con la
recepción de entregar_sm, el MMSC devuelve al sistema de mensajes
cortos una respuesta entregar_sm_resp de informe de entrega, y
determina si la notificación PUSH ha sido emitida con éxito de
acuerdo con el mensaje de informe de entrega. En caso afirmativo,
termina el flujo de notificación PUSH; en otro caso, el MMSC
selecciona si ha de re-emitir la notificación y el
instante de la re-emisión de acuerdo con la
estrategia de re-emisión interna, determinando si
las veces que se ejecutado la Etapa 2201 han excedido el valor
preestablecido cuando el MMSC va a re-emitir la
notificación, y si las veces que se ha ejecutado la Etapa 2201 han
excedido las veces preestablecidas, el MMSC determina que la emisión
de la notificación PUSH ha fallado y termina el flujo de entrega
del mensaje multimedia, y determina que la entrega del mensaje
multimedia ha fallado y lleva a cabo la Etapa 27; si las veces que
se ha ejecutado la Etapa 2201 no han excedido las veces
preestablecidas, el MMSC adopta la estrategia de
re-emisión y retorna a la Etapa 2201.
Hasta ahora, se ha completado el flujo de
notificación PUSH.
Etapas 23\sim26: el MMSC interactúa con el
terminal MSC/MMS de recepción para recuperar el mensaje.
Etapa 27: El MMSC envía a la parte iniciadora un
informe del estado de entrega del mensaje multimedia, indicando si
la parte receptora ha recibido el mensaje multimedia con éxito.
Cuando se ha completado la emisión de la
notificación PUSH, la parte iniciadora y la parte receptora
recuperan el mensaje multimedia de acuerdo con el flujo de
recuperación de mensaje de la Etapa 23 a la Etapa 27 para llevar a
cabo la entrega del mensaje multimedia.
Las GSM, GPRS, WCDMA, CDMA95, CDMA2000 y otras
redes fijas y móviles, pueden adoptar todas el modo de operación en
red ilustrado en la Figura 2, es decir, el MMSC adopta el protocolo
de interfaz asociado para llevar a cabo la comunicación con los
sistemas de mensajes cortos de diversas redes móviles o redes fijas
para realizar directamente la entrega del mensaje multimedia; por
ejemplo, en la red CDMA, el MMSC puede conectar directamente con el
centro (MC) de mensajes cortos de la CDMA para realizar la entrega
del mensaje multimedia.
\newpage
Los dos flujos mencionados en lo que antecede
indican que la notificación PUSH es crítica para la tarea global
del MMS, y constituye un requisito esencial para asegurar que la
parte receptora obtiene información normalmente. Cuando el
contenido de la notificación PUSH excede la longitud máxima que un
mensaje corto puede contener, la WAPGW o el sistema de mensajes
cortos pueden dividir la notificación PUSH en una pluralidad de
mensajes cortos para ser emitidos. Cuando la notificación PUSH es
dividida por la WAPGW, las etapas 1203\sim1210 que anteceden
serán ejecutadas muchas veces para completar la entrega de la
notificación PUSH; y cuando la notificación PUSH es dividida por el
sistema de mensajes cortos, los procesos 1205\sim1208 que
anteceden, o los procesos 2203\sim2206 que anteceden, serán
ejecutados muchas veces para completar la entrega de la notificación
PUSH.
Más en concreto, de acurdo con el procedimiento
para procesar la notificación PUSH de la técnica anterior, puesto
que la longitud máxima de un mensaje corto es de 140 bytes, siempre
que la longitud total de la notificación PUSH exceda de 140 bytes,
una notificación PUSH puede ser dividida en una pluralidad de
mensajes cortos para su entrega, y la parte receptora deberá
esperar la llegada de todos los mensajes cortos portadores de la
misma notificación PUSH antes de que la parte receptora los
ensamble en una notificación PUSH completa.
Ello conduce a enlaces complejos y
multitudinarios en el flujo de notificación PUSH para adoptar la
pluralidad de mensajes cortos portadores de una notificación PUSH.
Adicionalmente, si la entrega de un mensaje corto falla, es difícil
coordinar los mecanismos de re-emisión del MMSC y de
la WAPGW con la existencia de la WAPGW, y resulta imposible
determinar de manera precisa el mensaje corto que debe ser
re-emitido, por lo que, la proporción de éxito de
la notificación PUSH es baja y la calidad del servicio del negocio
de mensajes multimedia se ve seriamente afectada.
La división de una notificación PUSH en una
pluralidad de mensajes cortos conduce a una multiplicidad de enlaces
intermedios y a un alto coste operativo.
En vista de lo anterior, las realizaciones de la
presente invención proporcionan un procedimiento para procesar una
notificación PUSH que acorta el retardo de tiempo entre la emisión y
la recepción de la notificación PUSH.
El procedimiento incluye:
colocar campos no comprimibles de la
notificación PUSH en la notificación PUSH, comprimiendo un campo de
ContenidoTipo que indica el tipo de mensaje, un campo de
X-Mms-Transacción-identificación,
(X-Mms-Transacción-ID)
de ID Interna, y colocar el campo de ContenidoTipo comprimido y el
campo de
X-Mms-Transacción-ID
comprimido en la notificación PUSH;
determinar si la notificación PUSH puede ser
portada en un mensaje corto; si la notificación PUSH puede ser
portada en un mensaje corto, disponer que la notificación PUSH sea
portada en un mensaje corto; si la notificación PUSH no puede ser
portada en un mensaje corto, disponer que la notificación PUSH sea
portada en dos mensajes cortos;
determinar si existen bytes no ocupados en el
mensaje corto; si existen bytes no ocupados en el mensaje corto,
determinar si se coloca un campo Desde indicativo de un iniciador
del mensaje en la notificación PUSH de acuerdo con el número de
bytes no ocupados en el mensaje corto, y determinar si se comprime
un campo Sujeto, así como colocar el campo Sujeto en la
notificación PUSH de acuerdo con el número de bytes no ocupados en
el mensaje corto; si el campo Desde ha sido ya dispuesto en el
mensaje corto, mientras no existan bytes suficientes en el mensaje
corto para mantener el campo Sujeto, desechar el campo Sujeto; si
existen bytes no ocupados en el mensaje corto, pero el campo Desde
no puede ser mantenido en el mensaje corto, desechar el campo Desde
y el campo Sujeto que no estén situados en la notificación PUSH.
Los campos no comprimibles de la notificación
PUSH colocados en la notificación PUSH, incluyen: 10 campos con
excepción del campo de ContenidoTipo indicativo del tipo de mensaje,
el campo de
X-Mms-Transacción-ID
indicativo de la ID interna, el campo Desde indicativo del
iniciador, y el campo Sujeto indicativo de un Sujeto del
mensaje.
El procedimiento de compresión del campo
ContenidoTipo indicativo del tipo de mensaje, incluye: expresar el
campo ContenidoTipo indicativo del tipo de mensaje con códigos
binarios que ocupan 1 byte.
El procedimiento de comprimir el campo
X-Mms-Transacción-ID
de la ID interna, incluye:
desechar una ID central del servicio de mensajes
multimedia en la ID interna, y expresar la parte de tiempo en
segundos;
desechar la ID central en el campo de la ID
interna, expresar la parte de tiempo con segundos, y convertir el
campo de la ID interna en códigos de sistema numérico de base
64.
El procedimiento de determinar si la
notificación PUSH puede ser portado por un mensaje corto, incluye:
determinar si la longitud de la notificación PUSH es más corta de
140 bytes; si la longitud de la notificación PUSH es más corta de
140 bytes, la notificación PUSH puede ser portada en un mensaje
corto; en caso contrario, la notificación PUSH no puede ser portada
en un mensaje corto.
El procedimiento de determinar si se coloca el
campo Desde del iniciador en la notificación PUSH y si se comprime
el campo Sujeto y se coloca el campo Sujeto en la notificación PUSH,
incluye:
determinar si los bytes no ocupados del mensaje
corto son suficientes para mantener el campo Desde; si los bytes no
ocupados en le mensaje corto no son suficientes para mantener el
campo Desde, desechar el campo Desde y el campo Sujeto, y terminar
los procesos de la notificación PUSH; en caso contrario, situar el
campo Desde en la notificación PUSH;
determinar si el campo Sujeto puede adoptar un
modo de conjunto de caracteres o un modo de codificación con el que
se tenga una longitud de codificación del campo Sujeto que sea más
corta; si el campo Sujeto puede adoptar el modo conjunto de
caracteres o el modo de codificación que tenga una longitud de
codificación del campo Sujeto más corta, adoptar el modo conjunto
de caracteres o el modo de codificación de longitud de codificación
más corta para expresar el campo Sujeto; en otro caso, adoptar el
modo de conjunto de caracteres o el modo de codificación utilizado
originalmente;
determinar si los bytes no ocupados en el
mensaje corto que contienen el campo Desde, son suficientes para
mantener el modo de conjunto de caracteres o el modo de codificación
del campo Sujeto y los códigos correspondientes a al menos un
carácter de un código de cadena de caracteres del campo Sujeto; si
los bytes no ocupados en el mensaje corto que mantienen el campo
Desde son suficientes para mantener el modo de conjunto de
caracteres o el modo de codificación del campo Sujeto y los códigos
correspondientes a al menos un carácter del código de cadena de
caracteres del campo Sujeto, colocar el modo de conjunto de
caracteres o el modo de codificación en la notificación PUSH, y
colocar los códigos correspondientes a un carácter individual del
código de cadena de caracteres en la notificación PUSH en secuencia
de acuerdo con los bytes no ocupados del mensaje corto; en caso
contrario, desechar el campo Sujeto y terminar el proceso de la
notificación PUSH.
El procedimiento de colocar los códigos
correspondientes a los caracteres individuales de la parte de los
códigos de cadena de caracteres en la notificación PUSH en
secuencia, incluye:
determinar los bytes ocupados por los códigos
para expresar un carácter visualizable en el modo de codificación
existente;
calcular el número m de caracteres visualizables
que el mensaje corto puede contener de acuerdo con los bytes no
ocupados del mensaje corto que contienen el modo de conjunto de
caracteres o el modo de codificación y los bytes de codificación
determinados de acuerdo con el modo de codificación existente;
colocar los códigos correspondientes a los
caracteres, desde el primero hasta m de la parte de codificación de
cadena de caracteres del campo Sujeto, en la notificación PUSH en
secuencia.
Un Centro de Servicio de Mensajes Multimedia
(MMSC) para procesar una notificación PUSH en servicios de mensajes
multimedia, incluye:
una primera unidad, para colocar campos no
comprimibles de la notificación PUSH en la notificación PUSH;
una segunda unidad, para comprimir un campo de
ContenidoTipo indicativo del tipo de mensaje, y situar el campo de
ContenidoTipo comprimido en la notificación PUSH;
una tercera unidad, para comprimir un campo de
X-Mms-Transacción-Identificación
(X-Mms-Transacción-ED)
de la ID Interna y situar el campo
X-Mms-Transacción-ID
comprimido en la notificación PUSH, en la que el campo
X-Mms-Transacción-ID
de la ID interna se está utilizado para asegurar la recepción
correcta de un mensaje multimedia por una parte receptora;
una cuarta unidad, para determinar si la
notificación PUSH puede ser portada en un mensaje corto; si la
notificación PUSH puede ser portada en un mensaje corto, disponer
que la notificación PUSH sea portada en un mensaje corto; si la
notificación PUSH no puede ser portada en un mensaje corto, disponer
que la notificación PUSH sea portada en dos mensajes cortos;
una quinta unidad, para determinar si existen
bytes no ocupados en el mensaje corto; si existen bytes no ocupados
en el mensaje corto, determinar si se ha de situar el campo Desde
indicativo del iniciador del mensaje en la notificación PUSH de
acuerdo con el número de bytes no ocupados en el mensaje corto, y
determinar si se debe comprimir el campo Sujeto, así como colocar
el campo Sujeto en la notificación PUSH de acuerdo con el número de
bytes no ocupados en el mensaje corto; si el campo Desde ha sido ya
dispuesto en el mensaje corto, siempre que no existan bytes
suficientes en el mensaje corto para contener el campo Sujeto,
desechar el campo Sujeto; si existen bytes no ocupados en el
mensaje corto, pero el campo Desde no puede ser mantenido en el
mensaje corto, desechar el campo Desde y el campo Sujeto que no
estén colocados en la notificación PUSH.
La tercera unidad incluye:
una primera sub-unidad, para
desechar una ID central del servicio de mensajes multimedia de la ID
interna, y expresar la parte de tiempo en segundos;
una segunda sub-unidad, para
convertir el campo de la ID interna que ha sido procesado por la
primera sub-unidad, en códigos de sistema numérico
de base 64.
La cuarta unidad incluye:
una tercera sub-unidad, para
determinar si la longitud de la notificación PUSH es más corta de
140 bytes; si la longitud de la notificación PUSH es más corta de
140 bytes, la notificación PUSH puede ser portada por un mensaje
corto; en caso contrario, la notificación PUSH no puede ser portada
en un mensaje corto.
La quinta unidad incluye:
una cuarta sub-unidad, para
determinar si los bytes no ocupados en el mensaje corto son
suficientes para mantener el campo Desde; si los bytes no ocupados
del mensaje corto no son suficientes para mantener el campo Desde,
desechar el campo Desde y el campo Sujeto, y terminar los procesos
de la notificación PUSH; en otro caso, colocar el campo Desde en la
notificación PUSH;
una quinta sub-unidad, para
determinar si el campo Sujeto puede adoptar un modo de conjunto de
caracteres o un modo de codificación para hacer que la longitud de
codificación del campo Sujeto sea más corta; si el campo Sujeto
puede adoptar el modo de conjunto de caracteres o el modo de
codificación para hacer que la longitud de codificación del campo
Sujeto seta más corta, adoptar el modo de conjunto de caracteres o
el modo de codificación de longitud de codificación más corta para
expresar el campo Sujeto; en otro caso, adoptar el modo de conjunto
de caracteres o el modo de codificación utilizado originalmente;
una sexta sub-unidad, para
determinar si los bytes no ocupados en el mensaje corto que
contienen el campo Desde son suficientes para mantener el modo de
conjunto de caracteres o el modo de codificación del campo Sujeto y
los códigos correspondientes a al menos un carácter del código de
cadena de caracteres del campo Sujeto; si los bytes no ocupados del
mensaje corto que contienen el campo Desde son suficientes para
contener el modo de conjunto de caracteres o el modo de
codificación del campo Sujeto y los códigos correspondientes a al
menos un carácter del código de cadena de caracteres del campo
Sujeto, una séptima sub-unidad dispone el modo de
conjunto de caracteres o el modo de codificación en la notificación
PUSH, y una octava sub-unidad dispone los códigos
correspondientes a un carácter individual del código de cadena de
caracteres en la notificación PUSH en secuencia, de acuerdo con los
bytes no ocupados en el mensaje corto; en otro caso, una novena
sub-unidad desecha el campo Sujeto y termina el
proceso de la notificación PUSH.
La octava sub-unidad
incluye:
un primer módulo, para determinar bytes ocupados
por los códigos para expresar un carácter visualizable en el modo
de codificación existente;
un segundo módulo, para calcular el número m de
caracteres visualizables que el mensaje corto puede contener de
acuerdo con los bytes no ocupados del mensaje corto que contiene el
modo de conjunto de caracteres y el modo de codificación, y los
bytes de codificación determinados de acuerdo con el modo de
codificación existente;
un tercer módulo, para disponer los códigos
correspondientes a los caracteres, desde el primero hasta el m, de
la parte de codificación de cadena de caracteres del campo Sujeto en
la notificación PUSH, en secuencia.
Las realizaciones de la presente invención se
aplican para comprimir alguno de los campos de la notificación
PUSH, de modo que pueden ocupar menor número de bytes; por lo tanto,
una notificación PUSH puede ser mantenida con dos mensajes cortos
en la mayor parte de los casos para su entrega. Algunas
realizaciones de la presente invención tienen las ventajas que
siguen.
Algunas realizaciones de la presente invención
aseguran que incluyen los 10 campos no comprimibles, así como los
campos de ContenidoTipo y
X-Mms-Transacción-ID
de la notificación PUSH, con el fin de garantizar la integridad de
la información clave de la notificación PUSH.
Puesto que los campos comprimibles de la
notificación PUSH son expresados con menos bytes, algunas
realizaciones de la presente invención disminuyen la longitud total
de la notificación PUSH, y con ello una notificación PUSH puede ser
portada en dos mensajes a lo sumo, por lo que el procedimiento
descrito mediante las realizaciones de la presente invención reduce
la cantidad de datos que se han de transferir, acorta el retardo
temporal, y eleva la eficacia de la transferencia.
Puesto que una notificación PUSH puede ser
mantenida con dos mensajes cortos a lo sumo, algunas realizaciones
de la presente invención disminuyen las veces que se ha de ejecutar
el flujo de emisión de mensaje corto en el proceso de entrega de
los mensajes multimedia, acortan el tiempo de ejecución de los
enlaces intermedios, y rebajan el coste operativo.
Puesto que una notificación PUSH puede ser
mantenida con un mensaje corto o con dos, algunas realizaciones de
la presente invención pueden determinar fácilmente el mensaje corto
que debería ser re-emitido cuando falla la entrega
del mensaje corto.
La Figura 1 es un diagrama de flujo que ilustra
el flujo tradicional de emisión de un mensaje multimedia a través
de la WAPGW;
la Figura 2 es un diagrama de flujo que ilustra
el flujo tradicional de emisión de un mensaje multimedia a través
del MMSC directamente;
la Figura 3 es un diagrama general de flujo que
ilustra el procedimiento para procesar la notificación PUSH de
acuerdo con una realización de la presente invención, y
la Figura 4 es un diagrama de flujo que ilustra
el flujo para comprimir el campo Sujeto de acuerdo con una
realización de la presente invención.
Con el fin de hacer que la solución técnica de
la presente invención resulte más clara, se proporciona en lo que
sigue una descripción detallada de la presente invención, con
referencia a los dibujos y realizaciones anexos.
Las realizaciones de la presente invención
proporcionan un procedimiento para procesar la notificación PUSH en
servicios de mensajes multimedia, y su idea clave es: elegir algunos
campos que sean opcionales o de longitud variable en la
notificación PUSH y comprimirlos, de modo que la notificación PUSH
pueda ser portada en dos mensajes cortos a lo sumo.
Se proporciona en lo que sigue una descripción
del procedimiento para procesar la notificación PUSH en las
realizaciones, estando los procesos ilustrados en la Figura 3 y en
la Figura 4.
Según se muestra en la Figura 3, una realización
del procedimiento para procesar la notificación PUSH en servicios
de mensajes multimedia de acuerdo con la presente invención,
incluye:
Etapa 301: situar los campos no comprimibles en
la notificación Push.
En las especificaciones estándar
internacionales, la notificación PUSH incluye 14 campos. Aparte de
los campos de ContenidoTipo,
X-Mms-Transacción-ID,
Desde y Sujeto, los otros 10 campos no pueden cambiar sus modos de
expresión, y sus bytes ocupados no pueden ser comprimidos. Por lo
tanto, en el procesamiento de la notificación PUSH, el MMSC coloca
los 10 campos no comprimibles en la notificación PUSH durante este
proceso.
Etapa 302: comprimir los campos de ContenidoTipo
y
X-Mms-Transacción-ID
y colocarlos en la notificación PUSH.
En la especificación estándar internacional,
existen dos formas de expresar el campo de ContenidoTipo en la
notificación PUSH: una forma consiste en expresar el campo con una
aplicación de cadena de caracteres de 32
bytes/vnd.wap.mms-mensaje, y la otra forma consiste
en expresar el campo ContenidoTipo con códigos binarios 0x3E que
ocupan 1 byte. En este proceso, el campo se expresa con códigos
binarios que ocupan 1 byte para ahorrar 31 bytes.
La estructura de la
X-Mms-Transacción-ID
consiste en general: tiempo + ID de la central de servicio de
mensajes multimedia (MMSCID) + número de serie del mensaje (MSG) +
número de cola del terminal + número de serie de la sesión. De los
que, las funciones y los bytes ocupados por cada parte son,
respectivamente:
Tiempo: que indica el tiempo de entrega del
mensaje multimedia; su formato es: mmddHHMMSS, y el campo Tiempo
ocupa 10 bytes;
MMSCID: para identificación del MMSC, y el campo
MMSCID ocupa 6 bytes;
Número de serie MSG: el número de serie del
mensaje, y el campo de número de serie MSG ocupa 5 bytes;
Número de cola de Terminal: los dos últimos
dígitos del número de teléfono móvil, utilizados para comprobar la
legalidad, y el campo de número de cola de Terminal ocupa 2
bytes;
Número de serie de Sesión: los recursos internos
asignados por el MMSC al mensaje multimedia, y el número de serie
de Sesión ocupa 5 bytes.
La longitud total de las cinco partes
mencionadas anteriormente es de 28 bytes.
X-Mms-Transacción-ID
es utilizado principalmente por el personal técnico en su trabajo
de investigación; por lo tanto, este campo puede ser comprimido con
la siguiente estrategia:
a. Desechar MMSCID: cuando se recibe un mensaje
multimedia, el terminal obtiene un nombre de dominio y puede
encontrar el MMSC de acuerdo con el nombre del dominio, por lo que
esta parte puede ser omitida.
b. Convertir el formato de tiempo del mmddHHMMSS
que ocupa 10 bytes en un valor entero de 8 bytes de longitud, es
decir, expresar el tiempo en segundos. El tiempo se renueva el 1 de
Enero de cada año, por lo tanto, el valor máximo es: 24 horas x 60
minutos x 60 segundos x 366 días = 31622400 segundos.
Después de la operación anterior, la estructura
de la
X-Mms-Transacción-ID
es: tiempo (8 bytes) + número de serie de MSG (5 bytes) + número de
cola de terminal (2 bytes) + número de serie de sesión (5 bytes) =
20 bytes. Convirtiendo los 20 bytes mencionados anteriormente en un
número entero, y siendo el valor máximo de
10^{20}-1, los 20 bytes ocupan 18 bytes cuando se
adoptan códigos hexadecimales, y 12 bytes cuando la
X-Mms-Transacción-ID
se convierte en un sistema numérico de base 64. Por lo tanto, el
sistema numérico de base 64 ahorra 16 bytes tras la compresión.
Etapa 303: determina si la longitud de la
notificación PUSH es más corta de 140 bytes; en caso afirmativo,
avanza a la Etapa 304; en caso contrario, avanza a la Etapa 305;
Puesto que un mensaje corto puede contener 140
bytes a lo sumo, esta etapa pretende determinar si la notificación
PUSH puede ser contenida en un mensaje corto.
Etapa 304: El MMSC tiene la notificación PUSH
portada en un mensaje corto, entonces lleva a cabo la Etapa
306.
Etapa 305: El MMSC tiene la notificación PUSH
portada en dos mensajes cortos.
En este proceso, los campos son colocados en el
primer mensaje en primer lugar, y después en el segundo mensaje una
vez que se ha llenado el primer mensaje.
Etapas 306\sim307: determinar si existen
algunos bytes no ocupados en el mensaje corto; en caso afirmativo,
avanzar a la Etapa 308; en caso contrario, desechar los campos que
no están colocados en la notificación PUSH y terminar el flujo de
compresión de la notificación PUSH.
Si la notificación PUSH puede ser portada en un
mensaje corto, el procedimiento de este proceso para determinar si
existe algún byte no ocupado en el mensaje corto, consiste en:
determinar si el total de bytes ocupados por los 10 campos no
comprimibles y por los campos de ContenidoTipo y
X-Mms-Transacción-ID
comprimidos son más cortos de 140 bytes; en caso afirmativo,
determinar si existe(n) algún(os) byte(s) no
ocupado(s) en el mensaje corto; en caso contrario,
determinar que no existe ningún byte no ocupado en el mensaje
corto.
Cuando la notificación PUSH es portada por dos
mensajes cortos, si existe algún byte no ocupado en el segundo
mensaje corto será determinado mediante este proceso.
Etapa 308: comprimir los campos Desde y Sujeto
de acuerdo con los bytes no ocupados en el mensaje corto.
En este proceso, el MMSC determina si se han de
colocar los campos Desde y Sujeto en el mensaje, y el modo de
compresión del campo Sujeto de acuerdo con los bytes no ocupados en
el mensaje corto. De manera más concreta, cuando los bytes no
ocupados son suficientes para contener el campo Desde, el MMSC
coloca el campo en la notificación Push, y comprime el campo Sujeto
de acuerdo con el resto de bytes no ocupados; en otro caso, terminar
el flujo de compresión de la notificación PUSH.
Según se muestra en la Figura 4, el proceso para
comprimir los campos Desde y Sujeto incluyen específicamente:
Etapas 401\sim403: El MMSC determina si los
bytes no ocupados en el mensaje corto son suficientes para contener
el campo Desde; en caso afirmativo, el MMSC coloca el campo Desde en
la notificación PUSH; en caso contrario, el MMSC desecha el campo
Desde y el campo Sujeto y termina el flujo de compresión de los
campos de Desde y de Sujeto.
Cuando los bytes no ocupados en el mensaje corto
son suficientes para contener el campo completo de Desde, el MMSC
puede colocar el campo en la notificación Push. El MMSC elige
desechar el campo Desde en otros casos.
Etapas 404\sim405: decidir si el campo Sujeto
puede adoptar otro modo de conjunto de caracteres o modo de
codificación que haga que la longitud de codificación sea más corta
que la longitud de codificación del campo Sujeto que adopta el modo
de conjunto de caracteres o el modo de codificación ya utilizado; en
caso afirmativo, se adoptará el modo de conjunto de caracteres o el
modo de codificación de longitud de codificación más corta para
comprimir el campo Sujeto, y se lleva a cabo la Etapa 406; en caso
contrario, se lleva a cabo la Etapa 406.
El formato del campo Sujeto es: modo de código
de cadena de caracteres/codificación de conjunto de caracteres. El
campo puede adoptar una pluralidad de conjuntos de caracteres y de
modos de codificación para expresar su contenido específico, y los
números de bytes ocupados por los diferentes modos de conjuntos de
caracteres y modos de codificación son también diferentes. Por lo
tanto, la realización del procedimiento en este proceso para
comprimir el campo Sujeto es: bajo la condición previa de que los
contenidos expresados del campo no han cambiado, convertir los
modos de conjuntos de caracteres o modos de codificación que ocupen
más bytes en los que ocupan menos bytes. Por ejemplo, convertir los
caracteres de código UTF-8 que ocupan 6 bytes en
caracteres de código GB 2312 que ocupan 2 bytes.
Etapas 406\sim408: decidir si los bytes no
ocupados en el mensaje corto son suficientes para contener el modo
de codificación de conjunto de caracteres del campo Sujeto y los
códigos correspondientes a al menos un carácter del Sujeto; en caso
afirmativo, colocar el campo de modo de conjunto de caracteres o
modo de codificación, así como los códigos correspondientes a los
caracteres individuales que sirven para expresar contenidos de
texto del campo Sujeto, en la notificación PUSH en forma secuencial
de acuerdo con el número de bytes no ocupados en el mensaje corto;
en caso contrario, desechar el campo Sujeto y terminar el flujo de
compresión se los campos Desde y Sujeto.
La idea clave en esta realización para comprimir
el campo Sujeto, consiste en truncar el campo de modo que se acorte
su longitud. Para ser más concreto, el modo de codificación de
conjunto de caracteres del campo Sujeto sirve para expresar el modo
de conjunto de caracteres y el modo de codificación adoptados por
los códigos de los contenidos de texto del Sujeto, y esta parte
puede mantenerse completa en vez de ser truncada como ahorro. La
parte de los códigos de cadena de caracteres constituye el contenido
específico del campo Sujeto, y la parte de los códigos de cadena de
caracteres adopta el modo de conjunto de caracteres y el modo de
codificación especificado en la parte del modo de codificación de
conjunto de caracteres. Si el conjunto de caracteres adoptado
consiste en códigos de N-bytes, cada código de
N-bytes expresa un carácter visualizable. Por
ejemplo, cada carácter adopta códigos de 1 byte en un conjunto de
caracteres ANSI, y códigos UTF-8 de 6 bytes en el
conjunto de caracteres Unicode.
Cuando los bytes no ocupados en el mensaje corto
son suficientes para contener el modo de codificación de conjunto
de caracteres del campo Sujeto y los códigos correspondientes a al
menos un carácter, el MMSC coloca la parte de modo de codificación
de conjunto de caracteres en la notificación PUSH en primer lugar, a
continuación coloca los códigos correspondientes a cada carácter en
la notificación PUSH en secuencia a partir del primer carácter de
acuerdo con los bytes no ocupados en el mensaje corto. Si los bytes
no ocupados pueden contener el modo de conjunto de caracteres o el
modo de codificación y no son suficientes para contener los códigos
completos del primer carácter, el campo Sujeto será descartado. La
razón consiste en que: sin ningún código que indique el contenido
de Sujeto, el modo de conjunto de caracteres o el modo de
codificación es incluso inútil si existe el modo de conjunto de
caracteres o el modo de codificación del campo Sujeto; si los bytes
no ocupados no son suficientes para contener el modo de codificación
de conjunto de caracteres, el campo Sujeto será desechado y
terminará el flujo de compresión de los campos Desde y Sujeto.
Se debe apreciar que, puesto que cada código de
N-bytes expresa un carácter visualizable, se puede
asegurar que los códigos de cadena de caracteres colocados en la
notificación PUSH deben ser un múltiplo entero de N bytes, es
decir, los últimos N bytes colocados en la notificación PUSH pueden
ser el código del mismo carácter original. Si los códigos del
último carácter original no pueden estar contenidos por completo,
todos los bytes de codificación del carácter son desechados. Por
ejemplo, cuando existen K bytes no ocupados en el mensaje corto, el
MMSC lleva a cabo una operación de redondeo sobre el cociente de K
por N; si el resultado del redondeo es m, los códigos
correspondientes a los caracteres desde uno hasta m de la parte de
codificación de cadena de caracteres del campo Sujeto, serán
colocados en la notificación PUSH.
En el procedimiento para procesar la
notificación PUSH de acuerdo con la notificación, cuando se
proporciona un mensaje multimedia a través de la WAPGW, el campo
del ContenidoTipo es comprimido por la WAPGW, y los otros campos
son comprimidos por el MMSC; cuando el mensaje multimedia es
entregado al sistema de mensajes cortos directamente por el MMSC,
todos los campos son comprimidos por el MMSC.
Con la notificación PUSH en el servicio de
mensajes multimedia procesada con el procedimiento de la realización
conforme a la invención, el procedimiento acorta de manera efectiva
la longitud global y disminuye los bytes ocupados, y con ello
simplifica el flujo de entrega de los mensajes multimedia. En el
caso de una notificación PUSH comprimida del mensaje multimedia,
las Etapas 1203\sim1210 ilustradas en la Figura 1 serán ejecutadas
dos veces a lo sumo para completar la entrega de una notificación
PUSH cuando el mensaje multimedia es suministrado a través de la
WAPGW, y ejecuta las Etapas 1205\sim1208 ilustradas en la Figura 1
o las Etapas 2203\sim2206 de la Figura 2 dos veces para completar
la entrega de la notificación PUSH cuando el mensaje multimedia es
suministrado al sistema de mensajes cortos directamente.
Las GSM, GPRS, WCDMA, CDMA95, CDMA2000, y otras
redes móviles y fijas, proporcionan todas ellas servicio de
mensajes multimedia; por lo tanto, todas las notificaciones PUSH de
las redes mencionadas anteriormente pueden ser procesadas con el
procedimiento de las realizaciones de la invención.
Claims (12)
1. Un procedimiento para procesar una
notificación PUSH en un servicio de mensajes multimedia, que
comprende:
colocar campos no comprimibles de la
notificación PUSH en la notificación PUSH (301), comprimir un campo
de ContenidoTipo que indica el tipo de mensaje y un campo de
X-Mms-Transacción-identificación,
X-Mms-Transacción-ID,
de la ID Interna, colocando el campo de ContenidoTipo comprimido y
el campo de
X-Mms-Transacción-ID
en la notificación PUSH (302);
determinar si la notificación PUSH puede ser
portada en un mensaje corto (303); si la notificación PUSH puede
ser portada en un mensaje corto, obtener la notificación PUSH
portada en un mensaje corto (304); si la notificación PUSH no puede
ser portada en un mensaje corto, obtener la notificación PUSH
portada en dos mensajes cortos (305);
determinar si existen bytes no ocupados en el
mensaje corto (306); si existen bytes no ocupados en el mensaje
corto, determinar si debe disponerse un campo Desde que indique un
iniciador del mensaje en la notificación PUSH de acuerdo con el
número de bytes no ocupados en el mensaje corto (308), y determinar
si debe comprimirse un campo Sujeto así como colocar el campo
Sujeto en la notificación PUSH de acuerdo con el número de bytes no
ocupados en el mensaje corto (308); si el campo Desde ha sido ya
dispuesto en el mensaje corto, siempre que no existan bytes
suficientes en el mensaje corto para contener el campo Sujeto,
desechar el campo Sujeto; si existen bytes no ocupados en el
mensaje corto, pero el campo Desde no puede ser mantenido en el
mensaje corto, desechar el campo Desde y el campo Sujeto que no
estén colocados en la notificación PUSH (308).
2. El procedimiento de acuerdo con la
reivindicación 1, en el que los campos no comprimibles de la
notificación PUSH colocados en la notificación PUSH, comprenden: 10
campos con excepción del campo de ContenidoTipo que indica el tipo
de mensaje, del campo de
X-Mms-Transacción-ID
que indica la ID interna, del campo Desde que indica el iniciador
del mensaje, y del campo Sujeto que indica un Sujeto del
mensaje.
3. El procedimiento de acuerdo con la
reivindicación 1, en el que el proceso de comprimir el campo de
ContenidoTipo que indica el tipo de mensaje (302), comprende:
expresar el campo de ContenidoTipo que indica el tipo de mensaje
con códigos binarios que ocupan 1 byte.
4. El procedimiento de acuerdo con la
reivindicación 1, en el que el proceso de comprimir el campo de
X-Mms-Transacción-ID
de la ID interna (302), comprende:
desechar una ID central del servicio de mensajes
multimedia en la ID interna, y expresar la parte de tiempo en
segundos;
desechar la ID central del campo de la ID
interna, expresar la parte de tiempo en segundos, y convertir el
campo de la ID interna en códigos de sistema numérico de base
64.
5. El procedimiento de acuerdo con la
reivindicación 1, en el que el proceso de determinar si la
notificación PUSH puede ser portada en un mensaje corto (303),
comprende: determinar si la longitud de la notificación PUSH es más
corta que 140 bytes; si la longitud de la notificación PUSH es más
corta que 140 bytes, la notificación PUSH puede ser portada en un
mensaje corto; en otro caso, la notificación PUSH no puede ser
portada en un mensaje corto.
6. El procedimiento de acuerdo con la
reivindicación 1, en el que el proceso de determinar si ha de
colocarse el campo Desde del iniciador en la notificación PUSH y si
ha de comprimirse el campo Sujeto y colocar el campo Sujeto en la
notificación PUSH (308), comprende:
determinar si los bytes no ocupados en el
mensaje corto son suficientes para contener el campo Desde; si los
bytes no ocupados en el mensaje corto no son suficientes para
contener el campo Desde, desechar el campo Desde y el campo Sujeto,
y terminar el proceso de la notificación PUSH; en otro caso, colocar
el campo Desde en la notificación Push;
determinar si el campo Sujeto puede adoptar un
modo de conjunto de caracteres o un modo de codificación para hacer
que la longitud de codificación del campo Sujeto sea más corta; si
el campo Sujeto puede adoptar el modo de conjunto de caracteres o
un modo de codificación que haga que la longitud de codificación sea
más corta, adoptar el modo de conjunto de caracteres o el modo de
codificación de longitud más corta para expresar el campo Sujeto;
en otro caso, adoptar el modo de conjunto de caracteres o el modo de
codificación utilizado originalmente;
determinar si los bytes no ocupados en el
mensaje corto que contiene el campo Desde son suficientes para
mantener el modo de conjunto de caracteres o el modo de
codificación del campo Sujeto y los códigos correspondientes a al
menos un carácter de un código de cadena de caracteres del campo
Sujeto; si los bytes no ocupados en el mensaje corto que contiene
el campo Desde son suficientes para mantener el modo de conjunto de
caracteres o el modo de codificación del campo Sujeto y los códigos
correspondientes a al menos un carácter del código de cadena de
caracteres del campo Sujeto, colocar el modo de conjunto de
caracteres o el modo de codificación en la notificación PUSH, y
colocar los códigos correspondientes a un carácter individual del
código de cadena de caracteres en la notificación PUSH en secuencia
de acuerdo con los bytes no ocupados en el mensaje corto; en otro
caso, desechar el campo Sujeto y terminar el proceso de la
notificación PUSH.
7. El procedimiento de acuerdo con la
reivindicación 6, en el que el proceso de colocar los códigos
correspondientes a los caracteres individuales de la parte de los
códigos de cadena de caracteres en la notificación PUSH en
secuencia, comprende:
determinar los bytes ocupados por los códigos
para expresar un carácter visualizable en el modo de codificación
existente;
calcular el número m de caracteres visualizables
que el mensaje corto puede mantener de acuerdo con los bytes no
ocupados del mensaje corto que contiene el modo de codificación de
conjunto de caracteres y los bytes de codificación determinados de
acuerdo con el modo de codificación existente;
colocar los códigos correspondientes a los
caracteres, desde el primero hasta el m, de la parte de codificación
de cadena de caracteres del campo Sujeto en la notificación PUSH,
en secuencia.
8. Un Centro de Servicio de Mensajes Multimedia,
MMSC, para procesar una notificación PUSH en el servicio de
mensajes multimedia, que comprende:
una primera unidad, para situar campos no
comprimibles de la notificación PUSH en la notificación PUSH
(301);
una segunda unidad, para comprimir un campo de
ContenidoTipo que indica el tipo de mensaje, y situar el campo de
ContenidoTipo comprimido en la notificación PUSH (302);
una tercera unidad, para comprimir un campo de
X-Mms-Transacción-Identificación,
X-Mms-Transacción-ID,
de la ID Interna, y colocar el campo de
X-Mms-Transacción-ID
comprimido en la notificación PUSH (302), en el que el campo
X-Mms-Transacción-ID
de la ID interna se utiliza para asegurar la recepción correcta de
un mensaje multimedia por la parte receptora;
una cuarta unidad, para determinar si la
notificación PUSH puede ser portada en un mensaje corto (303); si
la notificación PUSH puede ser portada en un mensaje corto, disponer
la notificación PUSH portada en un mensaje corto (304); si la
notificación PUSH no puede ser portada en un mensaje corto, disponer
la notificación PUSH portada en dos mensajes cortos (305);
una quinta unidad, para determinar si existen
bytes no ocupados en el mensaje corto (306); si existen bytes no
ocupados en el mensaje corto, determinar si se ha de disponer un
campo Desde que indique un iniciador del mensaje en la notificación
PUSH de acuerdo con el número de bytes no ocupados en el mensaje
corto (308), y determinar si se ha de comprimir un campo Sujeto así
como si se ha de colocar el campo Sujeto en la notificación PUSH de
acuerdo con el número de bytes no ocupados en el mensaje corto
(308); si el campo Desde ha sido ya puesto en el mensaje corto,
siempre que no existan bytes suficientes en el mensaje corto para
contener el campo Sujeto, desechar el campo Sujeto; si existen
bytes no ocupados en el mensaje corto, pero el campo Desde no puede
ser mantenido en el mensaje corto, desechar el campo Desde y el
campo Sujeto que no estén colocados en la notificación PUSH
(308).
9. El MMSC de acuerdo con la reivindicación 8,
en el que la tercera unidad comprende:
una primera sub-unidad, para
desechar una ID central del servicio de mensajes multimedia de la ID
interna. Y expresar la parte de tiempo en segundos;
una segunda sub-unidad, para
convertir el campo de la ID interna que ha sido procesado por la
primera sub-unidad, en códigos de sistema numérico
de base 64.
10. El MMSC de acuerdo con la reivindicación 8,
en el que la cuarta unidad comprende:
una tercera sub-unidad, para
determinar si la longitud de la notificación PUSH es más corta de
140 bytes (303); si la longitud de la notificación PUSH es más
corta de 140 bytes, la notificación PUSH puede ser portada en un
mensaje corto (304); en otro caso, la notificación PUSH no puede ser
portada en un mensaje corto (305).
11. El MMSC de acuerdo con la reivindicación 8,
en el que la quinta unidad comprende:
una cuarta sub-unidad, para
determinar si los bytes no ocupados en el mensaje corto son
suficientes para mantener el campo Desde; si los bytes no ocupados
en el mensaje corto no son suficientes para mantener el campo Desde,
desechar el campo Desde y el campo Sujeto (307), y terminar los
procesos de la notificación PUSH; en otro caso, disponer el campo
Desde en la notificación Push;
una quinta sub-unidad, para
determinar si el campo Sujeto puede adoptar un modo de cadena de
caracteres o un modo de codificación que haga que la longitud de
codificación del campo Sujeto sea más corta; si el campo Sujeto
puede adoptar un modo conjunto de caracteres o un modo de
codificación que haga que la longitud de codificación del campo
Sujeto sea mas corta, adoptar el modo de conjunto de caracteres o el
modo de codificación de longitud de codificación más corta para
expresar el campo Sujeto; en otro caso, adoptar el modo de conjunto
de caracteres o el modo de codificación utilizado originalmente;
una sexta sub-unidad, para
determinar si los bytes no ocupados en el mensaje corto que contiene
el campo Desde son suficientes para mantener el modo de conjunto de
caracteres o el modo de codificación del campo Sujeto y los códigos
correspondientes a al menos un carácter de un código de cadena de
caracteres del campo Sujeto (308); si los bytes no ocupados en el
mensaje corto que contiene el campo Desde son suficientes para
mantener el modo de conjunto de caracteres o el modo de
codificación del campo Sujeto y los códigos correspondientes a al
menos un carácter del código de cadena de caracteres del campo
Sujeto, una séptima sub-unidad dispone el modo de
conjunto de caracteres o el modo de codificación en la notificación
PUSH, y una octava sub-unidad dispone los códigos
correspondientes a un carácter individual del código de cadena de
caracteres en la notificación PUSH en secuencia de acuerdo con los
bytes no ocupados en el mensaje corto; en otro caso, una novena
sub-unidad desecha el campo Sujeto y termina los
procesos de la notificación PUSH.
12. El MMSC de acuerdo con la reivindicación 11,
en el que la octava sub-unidad comprende:
un primer módulo, para determinar los bytes
ocupados por los códigos para expresar un carácter visualizable en
el modo de codificación existente;
un segundo módulo, para calcular el número m de
caracteres visualizables que el mensaje corto puede contener de
acuerdo con los bytes no ocupados del mensaje corto que contiene el
modo de codificación de conjunto de caracteres y los bytes de
codificación determinados de acuerdo con el modo de codificación
existente;
un tercer módulo, para disponer los códigos
correspondientes a los caracteres, desde el primero hasta el m de
la parte de codificación de cadena de caracteres del campo Sujeto,
en la notificación PUSH en secuencia.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100697036A CN100349474C (zh) | 2004-07-09 | 2004-07-09 | 一种多媒体消息业务中推送通知的处理方法 |
| CN200410069703 | 2004-07-09 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2315888T3 true ES2315888T3 (es) | 2009-04-01 |
Family
ID=35783514
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05766712T Active ES2315888T3 (es) | 2004-07-09 | 2005-07-07 | Procedimiento para procesar notificacion push en servicios de mensajes multimedia. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7899476B2 (es) |
| EP (1) | EP1781048B1 (es) |
| CN (1) | CN100349474C (es) |
| AT (1) | ATE415788T1 (es) |
| BR (1) | BRPI0513198A (es) |
| DE (1) | DE602005011304D1 (es) |
| ES (1) | ES2315888T3 (es) |
| RU (1) | RU2339185C1 (es) |
| WO (1) | WO2006005252A1 (es) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100455053C (zh) * | 2006-07-04 | 2009-01-21 | 华为技术有限公司 | 提供mms服务的方法 |
| CN101136837A (zh) * | 2007-09-21 | 2008-03-05 | 华为技术有限公司 | 推送消息的控制方法、装置和系统 |
| KR100979202B1 (ko) * | 2007-11-21 | 2010-09-01 | 한국전자통신연구원 | 메시지 서비스 방법 및 메시지 서비스 시스템 |
| US8521809B2 (en) * | 2009-07-31 | 2013-08-27 | Z2Live, Inc. | Mobile device notification controls system and method |
| US9439057B2 (en) * | 2009-09-30 | 2016-09-06 | Alcatel Lucent | Registration notification for SMS over LTE |
| CN101695057A (zh) * | 2009-10-20 | 2010-04-14 | 中兴通讯股份有限公司 | 多媒体消息发送方法、发送设备和域名解析服务器 |
| CN101674548B (zh) * | 2009-10-21 | 2014-12-17 | 中兴通讯股份有限公司 | 一种投递报告的分配方法及系统 |
| US8763089B2 (en) * | 2010-01-12 | 2014-06-24 | Microsoft Corporation | Flexible authentication and authorization mechanism |
| CN102123359B (zh) * | 2011-03-31 | 2014-12-10 | 中兴通讯股份有限公司 | 彩信的转发方法、装置、系统及彩信接收装置 |
| US8970400B2 (en) | 2011-05-24 | 2015-03-03 | Verna Ip Holdings, Llc | Unmanned vehicle civil communications systems and methods |
| US10769923B2 (en) | 2011-05-24 | 2020-09-08 | Verna Ip Holdings, Llc | Digitized voice alerts |
| US8265938B1 (en) | 2011-05-24 | 2012-09-11 | Verna Ip Holdings, Llc | Voice alert methods, systems and processor-readable media |
| CN103139724B (zh) * | 2011-11-30 | 2015-10-14 | 中国联合网络通信集团有限公司 | 媒体业务推送方法、多媒体交换网和多媒体交换网设备 |
| CN103139176B (zh) * | 2011-11-30 | 2016-02-17 | 中国联合网络通信集团有限公司 | 媒体业务推送方法、多媒体交换网和多媒体交换网设备 |
| US20150205464A1 (en) * | 2014-01-22 | 2015-07-23 | Microsoft Corporation | Updating a user interface to a service |
| CN107666430B (zh) * | 2016-07-27 | 2021-04-06 | 中兴通讯股份有限公司 | 一种电子邮件发送方法、装置及终端 |
| CN106991108A (zh) | 2016-09-27 | 2017-07-28 | 阿里巴巴集团控股有限公司 | 一种信息的推送方法及装置 |
| TWM547218U (zh) * | 2017-06-13 | 2017-08-11 | Hsiang-Che Kung | 訊息傳播系統 |
| KR102079222B1 (ko) * | 2018-10-12 | 2020-02-19 | 주식회사 케이티 | 멀티미디어 메시지의 통지 메시지를 최적화하는 방법 및 그 장치 |
| CN114157598B (zh) * | 2021-12-13 | 2023-04-07 | 百果园技术(新加坡)有限公司 | 一种消息转发方法、系统、电子设备及存储介质 |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5719918A (en) * | 1995-07-06 | 1998-02-17 | Newnet, Inc. | Short message transaction handling system |
| US7209955B1 (en) * | 1998-05-29 | 2007-04-24 | Research In Motion Limited | Notification system and method for a mobile data communication device |
| US6400942B1 (en) * | 1998-11-09 | 2002-06-04 | Telefonaktie Bolaget Lm Ericsson (Publ) | Method and system for broadcasting large short messages |
| KR100296049B1 (ko) * | 1999-03-19 | 2001-07-28 | 윤종용 | 단문메시지서비스를 통한 디지털 휴대용 단말기의 사용자 정보 송수신장치 및 그 방법 |
| US6947738B2 (en) * | 2001-01-18 | 2005-09-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Multimedia messaging service routing system and method |
| DE10104713A1 (de) * | 2001-02-02 | 2002-08-08 | Siemens Ag | Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten |
| US6707801B2 (en) * | 2001-03-28 | 2004-03-16 | Qualcomm Incorporated | Method and apparatus for data transport in a wireless communication system |
| DE10117895A1 (de) * | 2001-04-10 | 2002-10-17 | Siemens Ag | Benachrichtigung im Multimedia Messaging Service (MMS) |
| EP1361712B1 (en) * | 2002-05-07 | 2006-03-29 | Sony Ericsson Mobile Communications AB | Method for communicating messages to an electronic communication equipment |
| DE10237131A1 (de) * | 2002-08-13 | 2004-02-26 | Siemens Ag | Verfahren sowie Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten |
| WO2004034651A1 (en) * | 2002-09-30 | 2004-04-22 | Nokia Corporation | Routing data packets in a compressed-header domain |
| KR20040041943A (ko) * | 2002-11-12 | 2004-05-20 | 한국전자통신연구원 | 푸쉬기반 멀티미디어 메시징 서비스 방법 |
| EP1597646A2 (en) * | 2003-02-04 | 2005-11-23 | Canonline Global Media, Inc. | Method and apparatus for converting objects between weakly and strongly typed programming frameworks |
| US8732239B2 (en) * | 2003-10-02 | 2014-05-20 | Hong Kong Applied Science And Technology Research Institute Co., Ltd. | System and method for providing multimedia wireless messages across a broad range and diversity of networks and user terminal display equipment |
-
2004
- 2004-07-09 CN CNB2004100697036A patent/CN100349474C/zh active Active
-
2005
- 2005-07-07 DE DE602005011304T patent/DE602005011304D1/de active Active
- 2005-07-07 WO PCT/CN2005/001000 patent/WO2006005252A1/zh active Application Filing
- 2005-07-07 RU RU2007102820/09A patent/RU2339185C1/ru not_active IP Right Cessation
- 2005-07-07 ES ES05766712T patent/ES2315888T3/es active Active
- 2005-07-07 EP EP05766712A patent/EP1781048B1/en not_active Not-in-force
- 2005-07-07 BR BRPI0513198-7A patent/BRPI0513198A/pt not_active Application Discontinuation
- 2005-07-07 AT AT05766712T patent/ATE415788T1/de not_active IP Right Cessation
-
2007
- 2007-01-04 US US11/619,757 patent/US7899476B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1781048B1 (en) | 2008-11-26 |
| CN1719912A (zh) | 2006-01-11 |
| RU2339185C1 (ru) | 2008-11-20 |
| DE602005011304D1 (de) | 2009-01-08 |
| CN100349474C (zh) | 2007-11-14 |
| BRPI0513198A (pt) | 2008-04-29 |
| EP1781048A1 (en) | 2007-05-02 |
| US7899476B2 (en) | 2011-03-01 |
| EP1781048A4 (en) | 2007-11-21 |
| WO2006005252A1 (fr) | 2006-01-19 |
| RU2007102820A (ru) | 2008-08-20 |
| US20070180037A1 (en) | 2007-08-02 |
| ATE415788T1 (de) | 2008-12-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2315888T3 (es) | Procedimiento para procesar notificacion push en servicios de mensajes multimedia. | |
| ES2618074T3 (es) | Servicios de conmutación de circuito a través de redes SAE/LTE | |
| ES2558020T3 (es) | Método de transmisión de mensaje de protocolo Internet (IP), capacidad de economía de ancho de banda negociada y economía de ancho de banda de red | |
| ES2368211T3 (es) | Un procedimiento de sincronización iniciado por servidor en un sistema de sincronización donde el mensaje de solicitud del servidor tiene un tamaño máximo. | |
| RU2330384C2 (ru) | Преобразование коротких сообщений между различными форматами для систем беспроводной связи | |
| ES2313435T3 (es) | Aparatos y procedimientos de servicios de telecomunicaciones. | |
| ES2607958T3 (es) | Método y dispositivo para transmitir un mensaje corto desde un sistema de paquetes evolucionado a un equipo de usuario | |
| ES2401476T3 (es) | Servicio de intercambio de mensajes en una red de comunicaciones inalámbricas | |
| ES2376171T3 (es) | Método y aparato para entrega de servicios de base de datos/voz sobre picorredes y lans inal�?mbricas (wlans) acopladas a dispositivos 3gpp que incluyen elementos de arquitectura e información de protocolo relativos a un servicio de mensajes cortos (sms) sobre wlans. | |
| ES2547716T3 (es) | Método para prevenir la entrega de un mensaje basura del servicio de mensajes cortos | |
| US20100323725A1 (en) | Individualized retry configurations for messages having failed delivery | |
| FI111503B (fi) | Sanomien lähettäminen pakettiradioverkon käsittävässä tietoliikennejärjestelmässä | |
| ES2265178T3 (es) | Sistema de comunicaciones moviles que transmite mensajes cortos. | |
| ES2821652T3 (es) | Procedimiento de transmisión de datos y dispositivo de reenvío | |
| RU2003136092A (ru) | Способ предоставления услуги передачи пакетных данных в системе беспроводной свя зи | |
| AR022876A1 (es) | Sistema y metodo destinado a la entrega de mensajes breves entre redes gsm y tdma | |
| ES2383105T3 (es) | Método, aparato y sistema para informar del estado de transmisión | |
| JP4357495B2 (ja) | 携帯端末機の時間設定方法 | |
| ES2294282T3 (es) | Procedimiento de retransmision de mensajes entre diferentes centros de mensajes multimedia. | |
| ES2362028T3 (es) | Sistema de mensajería y procedimiento para el mismo. | |
| ES2247498T3 (es) | Inclusion de un identificacior de servicio segmentado en un mensaje de llamada para un grupo de llamadas de servicio. | |
| ES2539474T3 (es) | Sistema y método de telecomunicaciones | |
| ES2273274T3 (es) | Seleccion de un metodo de transferencia de datos. | |
| CN101175302B (zh) | 永远在线类型业务保持方法和装置 | |
| ES2425560T3 (es) | Procedimiento para gestión de peticiones de servicio en una red de telecomunicaciones móviles |