ES2268319T3 - Metodo para descargar software con soporte de movilidad de sesion en sistemas de comunicacion moviles. - Google Patents
Metodo para descargar software con soporte de movilidad de sesion en sistemas de comunicacion moviles. Download PDFInfo
- Publication number
- ES2268319T3 ES2268319T3 ES03425328T ES03425328T ES2268319T3 ES 2268319 T3 ES2268319 T3 ES 2268319T3 ES 03425328 T ES03425328 T ES 03425328T ES 03425328 T ES03425328 T ES 03425328T ES 2268319 T3 ES2268319 T3 ES 2268319T3
- Authority
- ES
- Spain
- Prior art keywords
- session
- download
- server
- software
- level
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
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/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- 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/14—Session management
-
- 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
- H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Abstract
Método de descarga de software en tiempo no real en un sistema de comunicación móvil basado en protocolo de Internet, IP, con tecnologías de acceso heterogéneas, en el que se establecen y se gestionan sesiones de descarga de software utilizando el protocolo de inicialización de sesión, SIP, de modo que las aplicaciones de agente de usuario (CL) y los servidores (PX1, RG1¿PX3, RG3) proxy y de registro se facilitan en el equipamiento de usuario (UE) y dentro de las redes (RAT1, RAT2, CN) de acceso y centrales respectivamente para manejar los procesos SIP, caracterizado porque para la recuperación de la descarga en caso de un traspaso entre una primera (RAT1) y una segunda (RAT2) red de acceso que emplean diferentes tecnologías de acceso mientras que una sesión de descarga de software está en curso, el agente de usuario (CL) SIP asociado a un equipamiento (UE) de usuario para el traspaso, al recibir una nueva dirección IP y un nuevo URL en la segunda red (RAT2) de acceso, envía sin liberar lasesión en curso un mensaje de petición de transferencia ¿Refer¿ a un servidor (PX1) proxy SIP que se ha establecido y está gestionando actualmente la sesión de descarga, conteniendo dicho mensaje ¿Refer¿ información sobre la dirección y el URL en la primera red (RAT1) de acceso, el nuevo URL, la identidad de sesión y el último paquete de software que se ha recibido con éxito, informándose por tanto a dicho servidor (PX1) proxy de este modo de que la sesión ha de transferirse al agente de usuario (CL) en el nuevo URL e iniciarse las operaciones necesarias para establecer una nueva sesión con el agente de usuario (CL) en el nuevo URL bajo el control de un servidor (PX3) proxy al que se le confía la tarea de gestionar la nueva sesión, y la descarga se reanuda desde dicho último paquete recibido.
Description
Método para descargar software con soporte de
movilidad de sesión en sistemas de comunicación móviles.
La presente invención se refiere a
comunicaciones móviles basadas en protocolo de Internet (IP), y más
particularmente se refiere a un método de descarga de software con
soporte de movilidad de sesión en sistemas de comunicación móviles,
y a un sistema de comunicación móvil que emplea el método.
\vskip1.000000\baselineskip
Los futuros sistemas de comunicación móvil más
allá de la tercera generación (3G) se caracterizarán por la
coexistencia de una pluralidad de tecnologías de acceso tales como
celular (de diferentes generaciones, en particular la segunda y la
tercera generación), sin cable, red de área local inalámbrica
(WLAN), sistemas de radiodifusión, sistemas por cable, etc. Estos
sistemas se integrarán en una plataforma común que les permitirá
complementarse entre sí de manera óptima y satisfacer diferentes
requisitos de servicio. Los diversos sistemas de acceso se
conectarán a una red central IP común, flexible y fluida.
Considerando el creciente uso de aplicaciones de
datos móviles similares a Internet en las redes celulares
existentes, una posible evolución de tales redes se dirige hacia la
definición de una capa de transporte común bada en el protocolo IP.
La motivación de esta elección puede resumirse brevemente en los
siguientes puntos:
- -
- la red central y la red de acceso por radio presentan la misma capa de transporte;
- -
- las estaciones de base desde diferentes tecnologías de acceso por radio (RAT) pueden conectarse al controlador de red de radio empleando el mismo protocolo de transporte (IP);
- -
- la red celular e Internet usan el mismo protocolo de transporte, ayudando de este modo a la integración de red y dominios de aplicación.
Siguiendo este enfoque, resulta necesario
utilizar mecanismos IP para gestionar la movilidad del terminal y
también para tener un conjunto común de funciones de movilidad capaz
de gestionar la movilidad del terminal independientemente de la
tecnología de acceso por radio y de una manera integrada con
respecto a la red central. Este enfoque puede seguirse empleando
mecanismos de IP móvil (MIP, Mobile IP) e Ipv6 pero no parecen ser
apropiados para la gestión de la micro-movilidad o
pico-movilidad. Se prevé que deberían integrarse una
solución jerárquica (HMIP) y la aplicación de diferentes mecanismos
para resolver diferentes escenarios de movilidad.
Por motivos de claridad se recuerda en la
presente memoria algunas definiciones sobre diferentes tipos de
movilidad:
- -
- Movilidad de terminal: la capacidad del terminal para cambiar de ubicación y seguir siendo capaz de comunicar. La movilidad de terminal puede ser:
- -
- Movilidad de terminal discreta: la capacidad del terminal para realizar cambios discretos mientras no se estén intercambiando datos de usuario y de permanecer localizable para las llamadas entrantes. En el contexto celular quiere decir el soporte de procedimientos de roaming (itinerancia) y de paging (localización).
- -
- Movilidad de terminal continua: la capacidad de cambiar de ubicación mientras que el intercambio de datos de usuario puede estar en proceso. En el contexto celular significa el soporte del procedimiento de handover (traspaso). Se llama transparente si la QoS (calidad de servicio) no se degrada debido al retardo o la pérdida de datos durante el traspaso.
- -
- Movilidad personal: La capacidad de los usuarios finales para originar y recibir llamadas en cualquier terminal en cualquier ubicación (es decir, desde diferentes tecnologías de acceso) cubierta por su suscripción. Significa que la ubicación se realiza basándose en el usuario en lugar de basándose en el termi-nal.
- -
- Movilidad de sesión: la capacidad de un usuario de cambiar el terminal.
Puede dividirse en las siguientes
categorías:
- -
- Movilidad de sesión discreta: la capacidad de cambiar terminales mientras que no se esté realizando ningún intercambio de datos de usuario y de permanecer localizable para una llamada entrante. En el contexto celular significa poder reasignar la sesión a un nuevo terminal y a una nueva ubicación de red.
- -
- Movilidad de sesión continua: la capacidad de cambiar terminales mientras están intercambiando datos de usuario.
Para completar el escenario, también puede
definirse:
- -
- Movilidad de servicio: la capacidad del usuario para ejecutar los servicios a los que se ha abonado sin tener en cuenta la ubicación del usuario y del terminal utilizado.
La nueva red celular podrá proporcionar nuevos
servicios de valor añadido, procedentes probablemente del mundo de
Internet y que se suministrarán al usuario mediante una
multiplicidad de diferentes tecnologías de acceso por radio (por
ejemplo 3G, WLAN, etc.). El terminal podrá admitir cualquier tipo de
acceso, es decir será un terminal multimodal, y preferiblemente
reconfigurable. En este escenario, la red implementará todas las
funciones necesarias para admitir la reconfiguración del terminal
empleando de manera eficiente los recursos de radio. Está claro que
cuando se pasa de una tecnología de acceso por radio a otra (es
decir, cuando se realiza un denominado "traspaso vertical" o
VHO (vertical handover)), un terminal multimodal o reconfigurable se
comporta como un terminal diferente, de manera que el problema de
admitir las características de movilidad pertinentes para el cambio
de terminal debe asegurarse
por la red.
por la red.
Entre los nuevos servicios puede mencionarse la
descarga de software y la red debe poder definir y ejecutar la
estrategia óptima para realizarla. La industria móvil está a punto
de introducir la descarga de objetos de medios de estilo de Internet
a gran escala, independiente del tipo de medio. Una de las áreas de
desarrollo para esta tecnología es el comercio electrónico. Los
objetos con más probabilidad de iniciar el negocio son tonos de
llamada, salva-pantallas, juegos y midlets de
Java.
En el escenario descrito, puede ocurrir que un
usuario con un terminal multimodal inicie una descarga de un
software y durante el proceso de descarga deba realizar una traspaso
vertical, por ejemplo, desde GPRS (servicio general de
radiocomunicación por paquetes) a UTMS (sistema universal de
telecomunicaciones móviles) o desde una red celular a una WLAN por
cualquier motivo (fuera de cobertura, necesidad de acelerar el
proceso, etc.).
La descarga de software presenta por lo general
un requisito de tiempo no real. Por tanto, en el caso del traspaso
vertical surge un grave problema. El soporte de gestión de movilidad
durante la descarga de software lo asegura el operador de red
mediante el procedimiento clásico de reubicación SGSN (nodo de
soporte GPRS de servicio) que encamina la información a la nueva
ubicación del terminal. También este procedimiento gestiona la
movilidad de sesión durante los traspasos horizontales en los que el
terminal cambia de ubicación bajo la mima tecnología de acceso por
radio (RAT). En el caso del traspaso vertical todavía no se ha
implementado un mecanismo para administrar este tipo de
reasignación. En este caso, la descarga del software debería
abortarse y, después de la identificación de la nueva posición del
terminal, la descarga del software ha de empezar de nuevo desde el
principio.
Cuando el tamaño del software es pequeño este
proceso tiene un ligero impacto en la calidad de servicio y en la
carga extra de la red (es decir, más recursos de red a gastar para
la retransmisión del software). Si el tamaño del software es muy
grande, la implementación de los mecanismos capaces de evitar la
retransmisión resulta crucial para ahorrar recursos de radio y
acelerar el proceso de descarga. Además es posible que una clase de
software deba descargarse e instalarse con prioridad alta (por
ejemplo, nuevos sistemas operativos, nuevas cadenas de transmisión
por radio, nuevas pilas de protocolo,...). Para esta clase de
software también es importante evitar la retransmi-
sión.
sión.
Por tanto está claro que en poco tiempo la
arquitectura de red ha de incluir todas las funcionalidades que
pueden admitir la reconfiguración de manera eficiente y la descarga
de software en un contexto de acceso por radio
hete-
rogéneo.
rogéneo.
Para el establecimiento y la gestión de una
sesión IMS (subsistema de multimedia IP), es decir para los
servicios orientados a paquetes que no presentan limitaciones de
tiempo real, 3GPP (sociedad de proyecto de tercera generación) ha
propuesto el protocolo de inicialización de sesión (SIP, Session
Initiation Protocol) como un protocolo de referencia (véase por
ejemplo la especificación 3GPP TS 23.228). El protocolo SIP es un
protocolo (señalización) de capa de aplicación para crear, modificar
y finalizar sesiones con uno o más participantes para sesiones de
unidifusión (unicast) y multidifusión (multicast) y se ha
estandarizado dentro del Internet Engineering Task Force (grupo de
trabajo en ingeniería de Internet) (véase por ejemplo la norma IETF
RFC 3261 que es el objeto del documento "SIP: Session Initiation
Protocol" de J.Rosenberg y H. Schulzrinne disponible en la página
http://www.ietf.org/rfc.html).
Ya se ha considerado el uso de tal protocolo
para ayudar a la adaptación de aplicación para las aplicaciones IP
durante un traspaso vertical, véase por ejemplo el documento
"End-to-end SIP Based Real Time
Application Adaptation During Unplanned Vertical Handovers" de
P.A. Pangalos et al., GLOBECOM’01, IEEE Conferencia de
telecomunicaciones globales, San Antonio (Texas, EE.UU.
25-29 de noviembre de 2001), tomo 6 páginas
3488-3493. Ese documento describe pruebas prácticas
y la evaluación de este uso para el traspaso vertical de móviles que
están involucrados en una llamada de audio en tiempo real. Como se
sabe, el tráfico en tiempo real presenta rigurosas restricciones de
retardo de tiempo, pero admite la pérdida de algunos paquetes
durante el traspaso. Por tanto, las sugerencias que contiene el
documento no son adecuadas para la descarga de software que no se
realiza en tiempo real en la que no puede admitirse la pérdida de
paquetes y puede dar como resultado la necesidad de retransmitir
todo el software que está descargándose. Además, las propuestas del
documento se basan en el uso del denominado proceso de
"Re-invite" (nueva invitación). Sin embargo,
tal procedimiento aspira a establecer una nueva sesión una vez que
el usuario ha completado el traspaso y por tanto no es adecuado para
resolver los problemas de interés.
\vskip1.000000\baselineskip
El principal objetivo de la presente invención
es superar los inconvenientes de la técnica conocida y garantizar la
movilidad de sesión durante un proceso de descarga de software que
no se realiza en tiempo real en un esquema de acceso por radio
heterogéneo, en particular en una situación de traspaso
vertical.
\vskip1.000000\baselineskip
En un primer aspecto, la invención proporciona
un método de descarga de software que no se realiza en tiempo real
en un sistema de comunicación móvil basado en un protocolo de
Internet (IP) con tecnologías de acceso heterogéneas, en el que las
sesiones de descarga de software se establecen y gestionan
utilizando el protocolo de inicialización de sesión (SIP). Para una
recuperación de descarga en el caso de un traspaso entre una primera
red de acceso y una segunda red de acceso que emplean diferentes
tecnologías de acceso mientras se está realizando una sesión de
descarga de software, el agente de usuario SIP asociado a un
equipamiento de usuario de traspaso, al recibir una nueva dirección
IP y un nuevo URL en la segunda red de acceso envía sin liberar la
sesión en curso, un mensaje de petición de transferencia (mensaje
"refer") a un servidor proxy SIP que se ha establecido y está
administrando actualmente la sesión de descarga, conteniendo dicho
mensaje información sobre la dirección y el URL en la primera red de
acceso, el nuevo URL, la identidad de sesión y el último paquete de
software que se ha recibido con éxito, informándose por tanto a
dicho servidor proxy de que la sesión ha de transferirse al agente
de usuario en el nuevo URL e iniciarse las operaciones necesarias
para establecer una nueva sesión con el agente de usuario en el
nuevo URL, bajo el control de un servidor proxy al que se confía la
administración de la nueva sesión, y la descarga se reanuda desde
dicho último paquete recibido.
En un segundo aspecto, la invención
proporcionaba un sistema de comunicación móvil basado en protocolo
de Internet (IP) con tecnologías de acceso heterogéneas a una red
central que incluye al menos un centro de conmutación móvil de
pasarela y de servicio y nodos de soporte GPRS
(S-MSC/SG-SN y
G-MSC/GGSN) en los que se realiza una descarga de
software en tiempo no real mediante el método anterior. En tal
sistema, al menos algunos de los usuarios tienen acceso a
instalaciones de descarga de software en tiempo no real y tienen un
equipamiento que permite la conexión al sistema a través de una
pluralidad de dichas tecnologías de acceso, estando equipados dicho
equipamiento de usuario y el acceso al sistema y las redes centrales
con medios que comprenden aplicaciones de agente de usuario y
servidores proxy y de registro, para establecer y administrar
sesiones de descarga de software a través del protocolo de
inicialización de sesión. Para la recuperación de la descarga en
caso de un traspaso entre una primera red de acceso y una segunda
red de acceso que emplean tecnologías de acceso diferentes mientras
está realizándose una sesión de descarga de software, se dispone el
agente de usuario SIP asociado con un equipamiento de usuario de
traspaso, al recibir una nueva dirección IP y un nuevo URL en la
segunda red de acceso y sin liberar la sesión en curso, para enviar
un mensaje de petición de transferencia a un servidor proxy SIP que
se ha establecido y actualmente se encarga de la sesión de descarga,
conteniendo dicha petición de transferencia información sobre la
dirección y el URL en la primera red de acceso, el nuevo URL, la
identidad de sesión y el último paquete de software que se ha
recibido con éxito, informándose por tanto a dicho servidor proxy de
que la sesión ha de transferirse al agente de usuario en el nuevo
URL y estando dispuesto para iniciar operaciones para establecer una
nueva sesión con el agente de usuario en el nuevo URL, bajo el
control de un servidor proxy al que se confía la administración de
dicha nueva sesión, y la descarga se reanuda desde dicho último
paquete recibido.
\vskip1.000000\baselineskip
La invención se entenderá mejor a partir de la
siguiente descripción de una realización preferida, dada a modo de
ejemplo no limitativo, con referencia a los dibujos adjuntos, en los
que:
la figura 1 muestra un escenario de referencia
de la aplicación de la invención.
la figura 2 es un diagrama de bloques que
muestra más detalladamente las unidades implicadas en la
reconfiguración y la gestión de descarga de software,
la figura 3 es un diagrama de bloques
simplificado que muestra las rutas de los mensajes SIP para la
descarga de software en un primer ejemplo de aplicación de la
invención;
la figura 4 es un gráfico del flujo de
señalización para la descarga mostrada en la figura 3;
las figuras 5 y 6 son un diagrama de bloques y
un gráfico similar a las figuras 3 y 4 respectivamente, relevantes
para la descarga de software en un segundo ejemplo de aplicación de
la invención,
las figuras 7 y 8 son un diagrama de bloques y
un gráfico correspondiente a las figuras 3 y 4, y muestran la
recuperación de la descarga de software considerada en las figuras 3
y 4, y
las figuras 9 y 10 son un diagrama de bloques y
un gráfico similar a las figuras 7 y 8 respectivamente, y muestran
la recuperación de la descarga de software considerada en las
figuras 5 y 6.
\vskip1.000000\baselineskip
La figura 1 muestra esquemáticamente un sistema
de comunicación móvil en el que puede aplicarse la presente
invención. Un terminal UE, que puede ser un terminal multimodal o
reconfigurable, puede tener acceso al sistema a través de una
pluralidad de diferentes tecnologías de acceso por radio y por tanto
a través de diferentes redes RATa, RATb... RATn de acceso por radio.
La parte de sistema independiente de la técnica de acceso se
denomina red central, empleando la terminología de 3GPP, y se indica
en la presente memoria mediante CN.
A modo ejemplo, el dibujo muestra redes RATa,
RATb de acceso por radio de sistemas celulares de tercera y segunda
generación respectivamente y una red RATn de área local inalámbrica
(WLAN o punto caliente "hot spot"). Dentro de cada bloque RATi
(i= a...n), las unidades convencionales del sistema móvil respectivo
se indican mediante sus nombres o acrónimos habituales,
concretamente Nodo B y control de red por radio RNC (radio network
control) para la red RATa de tercera generación, sistema transceptor
de base BTS (base transceiver system) y controlador de estación de
base BSC (base station controller) para la red RATb de segunda
generación, punto de acceso AP (access point) y unidad de
interfuncionamiento IWU (interworking unit) para la red RATn LAN
inalámbrica. Estas unidades no necesitan una descripción específica.
Dos unidades de nodo B, NB1 y NB2, se muestran en RATa. De manera
similar, el registro de posiciones base HLR (home location register)
convencional y los centros de conmutación móvil de pasarela y de
servicio y los nodos de soporte GPRS, S-MSC/SGSN y
G-MSC/GGSN respectivamente, se muestran dentro de la
red CN central. Para simplificar se considera una única unidad SGSN
dentro de CN. Sin embargo se indica la conexión de esa unidad a
otras SGSN así como las conexiones de la red CN central a un entorno
de Internet fijo (a través de GGSN) y a otras redes centrales (a
través de SG-SN).
Se supone que el terminal UE se conecta al
sistema a través de NB2 en RATa, tal como se muestra por la flecha
de línea continua, con la posibilidad de realizar traspasos
horizontales (a NB1 en la misma red RATa de acceso) y traspasos
verticales (a RATb, RATn, tal como se muestra por las flechas de
línea a rayas).
Para admitir la reconfiguración de terminal y la
descarga de software, las redes RAT1, RATn de acceso por radio
comprenden además las unidades de gestión de descarga y
reconfiguración, PRMa, PRMb...PRMn (Proxy Reconfiguration Managers,
gestores de reconfiguración de proxy) que pueden asociarse a o
incluirse en RNC, BSC o IWU respectivamente. La red CN central (la
red base para el terminal UE mostrado en el dibujo) está equipada
con unidades de nivel más alto SRM (serving reconfiguration manager,
gestor de reconfiguración de servicio) y HRM (home reconfiguration
manager, gestor de reconfiguración de base) que pueden asociarse a o
incluirse en unidades S-MSC/SGSN y HLR
respectivamente. Mediante "reconfiguración" se indica en la
presente memoria la totalidad de las funciones que permiten a un
terminal pasar de una técnica de acceso por radio a otra,
independientemente de si el terminal es multimodal o reconfigurable.
Ha de observarse que los terminales podrían descargar el software
necesario para la reconfiguración, incluyendo las técnicas de acceso
por radio, a través de la red.
Las unidades PRMi (i= a...n), SRM y HRM forma
una estructura distribuida jerárquica de tres niveles siendo HRM el
nivel superior y PRMi el nivel inferior que abarca diferentes
dominios de red. Una estructura distribuida jerárquica minimiza la
carga de red y acelera la descarga de software.
Las funciones de las unidades PRM, SRM, HRM para
la reconfiguración y la descarga de software en un sistema del tipo
descrito en la figura 1 se discuten en los documentos
"Requirements on Network and Security Architecture and Traffic
Management Schemes for Download Traffic based on IP principles in
Cellular and Ad Hoc Networks" (IST proyecto "SCOUT",
documento D4.1.1) disponible en la página web
www.ist-scout.org, y en el documento
"Reconfigurable SDR Equipment and Supporting Networks Referente
Models and Architectures", White Paper of Wireless World Research
Forum (WWRF, foro de investigación del entorno inalámbrico) grupo de
trabajo 3 (2002). Sin embargo, para facilitar la comprensión,
algunas de las funciones de las unidades PRM1, SRM, HRM se describen
brevemente en el presente documento.
Para tal descripción se hace referencia también
a la figura 2. En ésta, por motivos de sencillez, se tienen en
cuenta solamente dos redes de acceso por radio, por ejemplo una red
RAT1 UMTS (también etiquetada como "celular") y una WLAN RAT2
("punto caliente"). Las entidades de reconfiguración se
incluyen aquí en RNC, IWU, SGSN y HKR respectivamente y se asocian a
unidades SP1, SP2, SS, SH1, SH2 de memoria adecuadas que se
describirán más detalladamente más adelante. Para la consistencia
con la figura 1, ambas redes RAT1, RAT2 incluyen un gestor PRM1,
PRM2 de reconfiguración proxy respectivo, incluso si una red WLAn
como RAT2 pudiera basarse en el gestor de reconfiguración de proxy
de la red celular. Dado que PRM1, PRM2 están conectados a la misma
unidad SRM en la red CN central, se dice que las redes RAT1, RAT2
pertenecen a una misma área de servicio de reconfiguración de
terminal indicada por el bloque TRSA de línea a rayas. La
descripción de la figura 2 tratará básicamente los aspectos que se
refieren a la descarga de software.
Las unidades PRMi (i = 1, 2) son los puntos de
contacto para cada terminal unido a redes RATi de acceso por radio.
Tales unidades están implicadas principalmente en las funciones de
monitorización de modo, negociación de modo, conmutación de modo y
descarga de software. Para los procesos de información y
negociación, el tráfico de control se transmite a y desde PRMi,
mientras que en el caso de la descarga de software los paquetes de
datos de software apropiados se transportan a través de PRMi. Tales
unidades pueden dividirse en dos partes que representan las
funciones planas de usuario (bloques SPREi en la figura 2, siendo
SPRE el acrónimo de Software Download and Profile Repository,
repositorio de perfil y descarga de software) y las funciones planas
de control (bloque SDRC en la figura 2, siendo SDRC el acrónimo de
Software Download and Reconfiguration Controller, controlador de
reconfiguración y descarga de software). Los bloques SPREi reúnen
todos los perfiles y la información necesaria para realizar la
reconfiguración y la descarga de software. Además, tales bloques han
de obtener los módulos de software desde la unidad de memoria
respectiva o repositorio SPi y reenviarlos al terminal. SPi es
generalmente una memoria caché para el software solicitado con
frecuencia (software de reconfiguración para los terminales de su
RAT u otro software) almacenado en niveles superiores, pero podría
también almacenar algún software que pueda haber. Al tener el
software solicitado con frecuencia en el PRMi se reduce
considerablemente el tiempo para realizar la descarga y también
libera a la red de gran parte del tráfico permitiendo un uso más
eficiente de los recursos de red. El bloque SDRC, como es evidente
por su nombre, alberga las funciones de control para la
reconfiguración y la descarga. Particularmente, controlará el
servicio de la petición de descarga para módulos de software
presentes en la memoria SPi asociada y reenviará la petición a los
niveles superiores si el software no está presente
en SPi.
en SPi.
La unidad SRM está conectada a todas las
unidades PRMi en su TRSA y está asociada a medios SS de memoria,
almacenando entre otros el software de reconfiguración para todas
las técnicas de acceso por radio en dicho TRSA. SS incluye una base
de datos del software real y puede incluir también una memoria caché
para el software procedente de niveles superiores. Como las unidades
PRMi, SRM también puede subdividirse en dos bloques
C-SRM y U-SRM a los que se confían
las funciones planas de usuario y de control respectivamente.
La funcionalidad C-SRM plana de
control tiene esencialmente dos tareas:
- -
- gestionar el intercambio de mensajes de control apropiado entre el terminal (a través de PRM, y más en particular a través de SDRC) y las entidades que gestionan los procesos AAA (autentificación, autorización y contabilidad) en la red del operador, si el usuario desea realizar un traspaso o descargar una parte de software que requiere autorización;
- -
- actualizar la ubicación (o función de macromovilidad): el SRM almacena la ubicación de cada terminal controlado en su TRSA, por ejemplo si está esperando una actualización masiva, el SRM debe saber a qué PRM ha de enviarse el módulo de software.
A la funcionalidad U-SRM plana
de usuario del SRM se le confía esencialmente la función de
aprovisionamiento de descarga SW, mediante la recepción de
peticiones para el software que no está ubicado ni en la unidad PRMi
de la red RATi actualmente utilizada ni en los PRMs vecinos. La
U-SRM servirá el software solicitado al PRM, si está
almacenado en SS, de lo contrario la U-SRM
redirecciona posteriormente la petición al HRM y envía el software
al PRM una vez que se ha obtenido.
La unidad HRM ha de proporcionar todo el
software no presente en niveles inferiores, que incluye nuevas
actualizaciones de software de las que se ha informado por los
proveedores, y puede conectarse a muchas unidades SRM. En el caso de
una actualización, el HRM informa al SRM sobre la disponibilidad del
software nuevo y lo reenvía al SRM cuando sea necesario. Si una
petición para una descarga de software llega al HRM, también es
responsable de la autorización del terminal siempre que el software
tenga licencia, y de cobrar al usuario por la descarga del software.
En este caso, el HRM usa un repositorio de pago que se actualiza si
el software en cuestión se descarga. El bloque SH1 muestra la
totalidad de las bases de datos del software accesibles por el HRM a
través de servidores del fabricante respectivo, mostrados en su
totalidad mediante el bloque MS, y SH2 muestra el repositorio de
pago (o servidor AAA). Este último servidor también está conectado a
la parte plana de control C-SRM del SRM.
Según la invención, las sesiones de descarga de
software se gestionan mediante el protocolo SIP de tal manera que
admiten la movilidad de sesión. SIP es un protocolo de texto
cliente-servidor modelado tras el protocolo simple
de transferencia de correo (SMTP) y el protocolo de transferencia de
hipertexto (HTTP). Como en cualquier otro protocolo de texto
cliente-servidor, el cliente emite peticiones y el
servidor devuelve las respuestas. Para facilitar la comprensión, se
recuerdan ahora algunas definiciones de componentes y funciones SIP
utilizadas en la inven-
ción:
ción:
- -
- "User agent client" (cliente de agente de usuario) (en lo sucesivo denominado simplemente "cliente SIP") es el agente de usuario que llama, es decir una aplicación de cliente que inicia la petición SIP;
- -
- "proxy" (o "servidor proxy") es un programa intermediario que actúa como un servidor y un cliente con el propósito de realizar peticiones en nombre de otros clientes; las peticiones se sirven internamente o se pasan a otros servidores, posiblemente después de la traducción;
\newpage
- -
- "Registrar" (servidor de registro) es un servidor que acepta las peticiones de registro y que se ubica normalmente al lado de un servidor proxy;
- -
- "Invite" (invitar) es el procedimiento utilizado para establecer una llamada;
- -
- "Register" (registro) es el procedimiento que permite a un usuario transportar la información de ubicación a un servidor, para que el servidor pueda asociar (map) una dirección entrante a una dirección saliente que alcanzará ese usuario;
- -
- "bye" es el procedimiento para terminar una sesión.
Para garantizar la movilidad de sesión, la
presente invención también emplea el método "Refer". Este
método es una extensión de SIP recientemente estandarizada que
habilita muchas aplicaciones, incluyendo la transferencia de
llamada. El método "Refer" indica que el destinatario del
mensaje de petición de transferencia identificado por el URI
(identificador de recurso universal) de petición debería contactar
con una tercera parte utilizando la información de contacto
proporcionada en la petición. El método "Refer" se describe en
la norma IETF RFC 2315 que es el objeto del documento "The SIP
Refer Method" de R. Sparks disponible en la página
http://www.ietf.org/rfc.html.
El establecimiento de una sesión para la
descarga de software y su recuperación en caso de traspaso vertical
se describirá ahora con referencia a los diagramas de bloques y los
gráficos de las figuras 3 a 10. Se supone que el terminal UE está
conectado a RAT1 cuando comienza la descarga y realiza un traspaso
vertical a RTA2 durante la descarga.
Los diagramas de bloques en las figuras 3, 5 7 y
9 muestran los componentes SIP relacionados con la invención y las
rutas de los mensajes SIP, estas últimas indicadas por líneas de
trazo grueso. En particular, las líneas a rayas se usan para los
mensajes de "register", las líneas continuas para los mensajes
"invite" y "ok" (unidos en una única flecha
bidireccional); las líneas a puntos y rayas para los mensajes
"refer". Una flecha de línea a puntos indica la descarga y una
doble flecha con líneas a rayas indica las comprobaciones con los
repositorios. Las unidades mostradas también en las figuras 1 y 2 se
indican mediante los mismos símbolos de referencia. Por motivos de
simplicidad de los dibujos se han omitido las unidades estándar del
sistema de comunicación móvil en los diagramas de bloques y
solamente se indican las unidades de gestión de descarga de software
y de reconfiguración dado que son entidades que alojan los
componentes SIP. Por otro lado, se ha ilustrado la ubicación de
tales unidades de gestión con respecto a las unidades del sistema de
comunicación móvil con referencia a las figuras 1 y 2. También se
han omitido por simplificación la unidad SH2 de memoria y el
servidor MS del fabricante.
Los diagramas de bloques muestran claramente
que, según la invención, se propone una estructura jerárquica de
servidores proxy SIP para desarrollar una solución flexible y que
pueda escalarse. En particular:
- -
- el terminal UE alberga un cliente SIP (CL) que ha de iniciar la fase de registro y la sesión cuando se activa la petición de descarga por el propio terminal;
- -
- las unidades PRM1, PRM2 y SRM albergan servidores proxy SIP PX1, PX2, PX3 respectivamente (que son el primer punto de contacto para el cliente SIP y realizan el establecimiento y la gestión de la sesión) y servidores RG1, RG2 y RG3 de registro que realizan el registro del terminal en la red.
Como ya se ha mencionado anteriormente, se
considera una única unidad SGSN enlazada con RAT1 y RAT2 y, a modo
de ejemplo, se describe el caso de la descarga de software presente
en SP1 (figuras 3, 4 y 7, 8) o en SS (figuras 5, 6 y 9, 10). Por
tanto solamente se muestran dos niveles en la estructura SIP. La
solución propuesta está en cualquier caso abierta a una arquitectura
extendida, por ejemplo, al caso de RATs conectadas a diferentes
SGSNs. De hecho, el método es escalable y puede aplicarse con éxito
a arquitecturas más complejas.
En los gráficos, se emplean los siguientes
identificadores para los componentes SIP:
- Dirección inicial del terminal (cliente SIP):
user@rat1.core.net.
- Dirección del cliente SIP después de
desplazarse: user@rat2.core.net.
- PX1: prm1@rat1.core.net.
- PX2: prm2@rat2.core.net.
- PX3: srm@core.net
Con referencia ahora a las figuras 3, 4, el
proceso de establecer una sesión para la descarga de software desde
PRM1 es como sigue:
\newpage
- 1.
- El cliente SIP (terminal UE) realiza el registro en el proxy SIP PX1 en PRM1;
- 2.
- El mensaje REGISTER se almacena en RG1 y se reenvía al servidor PX3 de nivel más alto en SRM. La identidad de UE se almacena entonces en el nivel SRM en el registro RG de SIP.
- 3.
- El cliente SIP envía un mensaje INVITE al PRM1 para iniciar la sesión SIP. El mensaje (por lo que respecta a la información de interés para la presente invención) podría parecer de la siguiente manera:
- INVITE prm1@rat1.core.net
- Via [prm1@rat1.core.net]
- From user1@rat1.core.net
- To prm1@rat1.core.net
- Call ID xyz123
- 4.
- El PRM1 comprueba si el software está en su repositorio SP1. La respuesta es positiva.
- 5.
- Se envía un mensaje de OK desde el PX1 a UE de manera que la sesión se establece y la descarga de software comienza de manera adecuada hacia el UE.
La descarga de software tiene lugar con las
reglas expuestas mediante SIP. Ha de observarse que el PX1 no
almacena el software que está descargándose si bien se proporciona
algún almacenamiento intermedio para adaptar el tráfico que entra y
que sale de PX1. La flecha ``descarga de software en el diagrama de
señalización se extiende desde el proxy al cliente dado que se
refiere a la señalización de control y no a los paquetes de software
reales.
En el mensaje anterior, así como en el mensaje
mencionado en conexión con las figuras 6, 8 y 10, no se ha hecho
referencia explícita a la estructura del mensaje (línea de petición,
cabecera, cuerpo) dado que la estructura está definida por las
normas del protocolo SIP y no se ve afectada por la presente
invención. Tan sólo se recuerda que el cuerpo incluye un número de
parámetros (conocidos como parámetros SDP, en el que SDP significa
Protocolo de Descripción de Sesión, Session Desription Protocol) que
contienen información, entre otras, sobre las características de
sesión, información de tiempo e información sobre los medios a los
que concierne la sesión. Aquí no es necesario incluir la lista de
tales parámetros dado que están definidos en la norma IETF RFC
2327, que puede encontrarse en el sitio IETF mencionado
anteriormente. Uno de los parámetros que describen las
características de sesión (por ejemplo parámetro s = nombre de
sesión, o parámetro i = información de sesión) indicará que la
sesión se refiere a la descarga del módulo de software deseado.
Además, dado que la invención pretender recuperar una descarga de
software desde el último paquete recibido en el momento del traspaso
vertical, será necesario rastrear el número pktn progresivo
de los paquetes descargados: las líneas de atributo de sesión
opcional (parámetro a) pueden usarse para este objetivo. De los dos
parámetros SDP anteriores, solamente el parámetro "número de
paquete" se indica explícitamente (en los mensajes que se
refieren a la fase de recuperación).
Cuando la descarga tiene lugar desde SRM
(figuras 5, 6), el usuario inicia una sesión con PRM1, como antes, y
repite las etapas 1-4 anteriores. Los mensajes
"register" y el mensaje "invite" a PX1 ya no se muestran
en la figura 5 para la claridad del dibujo. En este caso, la
comprobación de la existencia del software solicitado en SP1 en la
etapa 4 tiene un resultado negativo. Entonces se realizan las
siguientes etapas:
5. Cuando PRM1 detecta que el software que va a
descargarse no está presente en SP1, envía a UE un mensaje
"refer", para transferir la sesión existente al proxy SIP de
nivel superior (por ejemplo SRM). PRM1 ("referred by", referido
por) dice a UE (usuario1) que la sesión existente (ID de llamada) ha
de transferirse a SRM ("refer to", referir a). El mensaje
"refer" puede aparecer de la siguiente manera:
\vskip1.000000\baselineskip
- REFER user1@rat1.core.net
- Via [prm1@rat1.core.net]
- From prm1@rat1.core.net
- To user1@rat1.core.net
- Call ID xyz123
- Refer to srm@core.net
- Referred by prm1@rat1.core.net
\newpage
6. Al recibir el mensaje "refer", el UE
envía un nuevo mensaje INVITE a PX3 en SRM. El mensaje NEW INVITE
aparece de la siguiente manera:
- INVITE srm@core.net
- Via [prm1@rat1.core.net][srm@core.net]
- From user1@rat1.core.net
- To srm@core.net
- Call ID xyz123
7. Suponiendo que la presencia del software en
SS se conozca previamente, se vuelve a enviar un mensaje de OK al
UE. La sesión se establece y comienza la descarga del software. En
el caso de que la presencia del software en SS no se conozca
previamente, el mensaje 6 INVITE estará seguido de una línea de
comprobación como la de la etapa 4 (la comprobación se indica en la
figura 5).
En ambos casos, la sesión se cierra al final de
la descarga (a través de un mensaje BYE no mostrado en los gráficos)
si el terminal UE está todavía bajo la cobertura de radio de
RAT1.
Se apreciará que incluso cuando tiene lugar la
descarga en el nivel PRM, el mensaje "Register" se reenvía a
todos los servidores de registro de nivel superior de manera que los
niveles superiores conozcan también la ubicación del terminal. Esto
es ventajoso para hacer frente a la recuperación de la descarga tal
como se verá más adelante.
Ahora se describirá el caso en el que el
terminal UE pasa de la ubicación de UE (1) bajo la cobertura de
radio de RAT1 a la ubicación de UE(2) (en líneas
discontinuas) bajo la cobertura de RAT2 durante la descarga. En el
caso de que el software esté descargándose desde un repositorio SP1
del PRM1 (figuras 7 y 8) se supone que tal software también está
almacenado en el repositorio SS de SRM. Los mensajes indicados en
las figuras 3 y 5 ya no se muestran en las figuras 7 y 9. El
software iniciado en RAT1 todavía se indica, aunque en líneas más
delgadas.
En la figura 8, la descarga en progreso y el
traspaso vertical se muestran en las etapas 1, 2. Bajo la cobertura
de RAT2, el UE consigue una nueva dirección IP y también un nuevo
URL, en este caso user1@rat2.core.net. La movilidad del
terminal se trata según los mecanismos MIP (IPv6). Estos mecanismos
son convencionales y no necesitan describirse en la presente
memoria.
Después de conseguir la nueva dirección IP, el
UE es consciente de estar bajo una subred diferente e intenta
recuperar la sesión de descarga. Entre otros parámetros SIP, el UE
ha almacenado la identidad de la sesión previamente en curso (ID de
llamada), el número de secuencia del último paquete recibido
correctamente (parámetro SDP "pktn") y su antiguo URL. El UE
envía un mensaje "Refer" a PX1 (etapa 3 en la figura 8) para
transferir la sesión en curso a su nuevo URL. El mensaje contiene,
entre otras cosas, el antiguo URL (campo referido a) y puede
aparecer de la siguiente manera:
- REFER user1@rat2.core.net
- Via [prm2@rat2.core.net] ][srm@core.net]
- From user1@rat2.core.net
- To prm1@rat1.core.net
- Call ID xyz123
- Refer to user1@rat2.core.net
- Referred by user1@rat1.core.net
- SDP: Pktn: 1453
PX1 está configurado para no responder al
mensaje "refer"; simplemente ignora el mensaje pero consigue el
nuevo URL del UE, el ID de llamada y la referencia al último paquete
recibido correctamente (etapa 4 en la figura 8).
Después, PX1 envía un mensaje "refer"
adicional (mensaje "refer" nº 5) provocado por el mensaje
"refer" nº 3) al SRM para transferir la sesión previamente
establecida con el antiguo URL. El nuevo mensaje "refer" tiene
la posibilidad de hacer que el SRM sea consciente de que ha de
iniciarse una sesión identificada mediante el parámetro ID de
llamada hacia el UE en su nuevo URL, y que SRM debe tomar el mismo
software desde su repositorio e iniciar la descarga desde el paquete
indicado. Ese segundo mensaje "refer" aparece de la siguiente
manera:
- REFER user1@rat2.core.net
- Via [srm@core.net]
- From prm1@rat1.core.net
- To srm@core.net
- Call ID xyz123
- Refer to user1@rat2.core.net
- Referred by user1@rat1.core.net
- SDP: Pktn: 1453
SRM envía un mensaje INVITE al UE en su nuevo
URL (user1@rat2.core.net):
- INVITE user1@rat2.core.net
- Via [prm2@rat2.core.net]
- From srm@core.net
- To user1@rat2.core.net
- Call ID xyz123
- SDP: Pktn: 1453
El UE acepta la nueva sesión enviando de vuelta
un mensaje de OK (etapa 7 en la figura 8). La descarga de software
se recupera desde SS y se reinicia desde el paquete en el que se
interrumpió (es decir, el paquete 1453); una vez establecida la
nueva sesión adecuadamente; la antigua sesión pendiente se
cierra.
Las figura 7 y 8 muestran que, incluso si la
sesión se ha iniciado en el nivel PRM (mediante PRM1), la
recuperación se gestiona mediante el nivel inmediatamente superior,
es decir, mediante SRM y no mediante el nivel igual PRM2 en RAT2.
Esta selección se ha realizado por motivos de simplicidad de
señalización, considerando que sería necesaria una señalización muy
intensa para transferir la gestión de descarga a PRM2. Por otro
lado, el traspaso vertical se producirá generalmente muy pocas veces
de manera que la carga en SRM no aumenta en exceso. Además, esta
elección produce una mejora de las características de retardo,
aunque no es particularmente importante dado que se considera un
tráfico en tiempo no real.
En el caso de la recuperación del software que
está descargándose desde SRM (figuras 9 y 10) el procedimiento es
similar: naturalmente no tiene lugar ninguna intervención de PRM1
durante la recuperación. En particular, el UE envía ahora un mensaje
"refer" a SRM para transferir la sesión en curso a su nuevo
URL:
- REFER user1@rat2.core.net
- Via [prm2@rat2.core.net]
- From srm@.core.net
- To prm1@rat2.core.net
- Call ID xyz123
- Refer to user1@rat2.core.net
- Referred by user1@rat1.core.net
- SDP: Pktn: 1453
y SRM envía al UE el mensaje de "invite"
como antes. La operación continúa como en el caso anterior.
Tal como se ha dicho anteriormente, la
invitación está basada en una estructura que puede expandirse
jerárquicamente de los servidores SIP. Por tanto, si los terminales
tienen la posibilidad o necesitan descargar módulos de software de
SH1, el HRM alojará también un proxy y un servidor de registro; en
tal caso, al menos cuando la ubicación del software no se conozca
previamente, el mensaje Register se reenviará a HRM. En el caso de
que la gestión de descarga de software requiera la intervención del
HRM, claramente la recuperación también requerirá la intervención
del
HRM.
HRM.
En general puede decirse que una sesión de
descarga establecida por los proxies de nivel más bajo se recuperará
mediante un proxy en el nivel inmediatamente superior (PX3),
mientras que una sesión establecida mediante un proxy de nivel
superior puede recuperarse mediante el mismo proxy por el que se ha
establecido.
En el caso de que la técnica de acceso por radio
objetivo RAT2 esté conectada a un SGSN diferente a un SGSN conectado
a RAT1, se aprovecha preferiblemente la organización jerárquica al
hacer que la recuperación se gestione por el HRM (es decir, mediante
el nivel jerárquico superior). En tal caso, el mensaje "refer"
a SRM (3 ó 5 según el caso) activará un mensaje "refer" a HRM,
si la descarga de software estaba teniendo lugar desde SRM o PRM1,
mientras que el mensaje "refer" se enviará directamente por el
cliente a HRM, si la descarga de software estaba teniendo lugar
desde HRM. El HRM envía entonces el mensaje INVITE al cliente en su
nuevo URL.
El SGSN "antiguo" podría solicitar
directamente la intervención del "nuevo" SGSN que enviaría el
mensaje INVITE al cliente, aunque esta sea una alternativa menos
preferida.
Es evidente que la descripción anterior se ha
proporcionado solamente a modo ejemplo no limitativo y que los
cambios y modificaciones son posibles sin desviarse del alcance de
la invención tal como se define en las reivindicaciones
adjuntas.
De esta manera, aunque la presente invención se
haya descrito con referencia a un sistema de comunicación móvil
"convencional", aunque de una generación futura. Dado que la
invención está basada en el uso del protocolo SIP podría también
emplearse como una aplicación de una plataforma IMS o en general
como un medio para la integración de funcionalidades reconfigurables
en una arquitectura IMS.
Claims (22)
1. Método de descarga de software en tiempo no
real en un sistema de comunicación móvil basado en protocolo de
Internet, IP, con tecnologías de acceso heterogéneas, en el que se
establecen y se gestionan sesiones de descarga de software
utilizando el protocolo de inicialización de sesión, SIP, de modo
que las aplicaciones de agente de usuario (CL) y los servidores
(PX1, RG1...PX3, RG3) proxy y de registro se facilitan en el
equipamiento de usuario (UE) y dentro de las redes (RAT1, RAT2, CN)
de acceso y centrales respectivamente para manejar los procesos SIP,
caracterizado porque para la recuperación de la descarga en
caso de un traspaso entre una primera (RAT1) y una segunda (RAT2)
red de acceso que emplean diferentes tecnologías de acceso mientras
que una sesión de descarga de software está en curso, el agente de
usuario (CL) SIP asociado a un equipamiento (UE) de usuario para el
traspaso, al recibir una nueva dirección IP y un nuevo URL en la
segunda red (RAT2) de acceso, envía sin liberar la sesión en curso
un mensaje de petición de transferencia "Refer" a un servidor
(PX1) proxy SIP que se ha establecido y está gestionando actualmente
la sesión de descarga, conteniendo dicho mensaje "Refer"
información sobre la dirección y el URL en la primera red (RAT1) de
acceso, el nuevo URL, la identidad de sesión y el último paquete de
software que se ha recibido con éxito, informándose por tanto a
dicho servidor (PX1) proxy de este modo de que la sesión ha de
transferirse al agente de usuario (CL) en el nuevo URL e iniciarse
las operaciones necesarias para establecer una nueva sesión con el
agente de usuario (CL) en el nuevo URL bajo el control de un
servidor (PX3) proxy al que se le confía la tarea de gestionar la
nueva sesión, y la descarga se reanuda desde dicho último paquete
recibido.
2. Método según la reivindicación 1,
caracterizado porque al aceptar el agente de usuario (CL)
dicha nueva sesión, la sesión establecida bajo la cobertura de la
primera red (RAT1) de acceso se libera.
3. Método según la reivindicación 1 o 2, en el
que el software puede descargarse desde una pluralidad de
repositorios (SP1, SP2, SS, SH1) de software accesibles a través de
unidades (PRM1, PRM2, SRM, HRM) de gestión de descarga en diferentes
niveles de una estructura de gestión de descarga dispuesta
jerárquicamente, estando asociadas las unidades de gestión de
descarga en un nivel intermedio de dicha estructura a medios (SGSN)
que controlan servicios de paquetes en el sistema,
caracterizado porque el método comprende las etapas de:
organizar una estructura jerárquica y modularmente escalable de
dichos servidores SIP (PX1, RG1...PX3, RG3) y albergar los
servidores en cada nivel de dicha estructura (PX1, RG1...PX3, RG3)
de servidor jerárquica en unidades (PRM1, PRM2, SRM, HRM) de gestión
de descarga en un nivel dado de la estructura (PRM1, PRM2, SRM, HRM)
de gestión de descarga, estableciéndose de esta manera una
correspondencia entre las dos estructuras jerárquicas.
4. Método según la reivindicación 3, que
comprende una fase de registro de un usuario (CL) que desea
establecer una sesión de descarga, caracterizado porque el
registro del correspondiente agente de usuario se realiza con
servidores (RG1...RG3) de registro en todos los niveles jerárquicos
de la estructura de servidor, independientemente del nivel
jerárquico en el que puede accederse al software que va a
descargarse, de modo que la información sobre la ubicación del
usuario está disponible en todos los niveles de la estructura
jerárquica del servidor.
5. Método según la reivindicación 3 o 4,
caracterizado porque las sesiones de descarga se establecen
mediante servidores (PX1, PX3) en el mismo nivel jerárquico que el
de las unidades (PRM1, PRM2, SRM, HRM) de gestión de descarga a
través de las cuales puede accederse al software que va a
descargarse.
6. Método según cualquiera de las
reivindicaciones 3 a 5, caracterizado porque el
establecimiento de una sesión se solicita inicialmente con el
servidor (PX1, PX2) de nivel más bajo y, en caso de que el software
que va a descargarse no esté presente en el repositorio (SP1, SP2)
accesible en dicho nivel más bajo, se envía una petición de
transferencia de sesión mediante dicho servidor (PX1, PX2) de nivel
más bajo al agente de usuario (CL) para informarle de la necesidad
de establecer la sesión con un nivel superior, repitiéndose la
petición de establecimiento y el envío de la petición de
transferencia a y en cada uno de los niveles progresivamente
superiores hasta que la petición de establecimiento alcanza el nivel
en el que está disponible el software.
7. Método según cualquiera de las
reivindicaciones 3 a 6, caracterizado porque los repositorios
(SS, SH1) de software accesibles a través de las unidades (SRM, HRM)
de gestión de descarga en niveles superiores a los asociados con el
nivel de servidor (PX1, PX2) más bajo almacenan también software
contenido en repositorios (SP1, SP2) accesibles a través de las
unidades (PRM1, PRM2) de gestión de descarga en niveles
inferiores.
8. Método cualquiera de las reivindicaciones 3 a
7, caracterizado porque dicha etapa de albergar incluye el
albergar servidores (PX3) proxy en un nivel inmediatamente superior
al nivel más bajo en las unidades (SRM) de gestión de descarga
asociadas a dichos medios (SGSN) que controlan los servicios de
paquetes, y porque la transferencia a la segunda red (RAT2) de
acceso de una sesión de descarga establecida en la primera red
(RAT1) de acceso mediante un servidor (PX1, PX2) proxy en el nivel
más bajo de la estructura de servidor se gestiona mediante un
servidor (PX3) en un nivel inmediatamente superior, si las dos redes
de acceso se conectan a un mismo medio (SGSN) de control de
servicios de paquetes.
9. Método según las reivindicaciones 1 y 8,
caracterizado porque dicho mensaje de petición de
transferencia enviado por el cliente al servidor (PX1, PX2) activa,
en dicho servidor (PX1, PX2) de gestión, un segundo mensaje de
transferencia al servidor (SRM) en el nivel inmediatamente superior,
al recibir dicho mensaje de transferencia, y dicho servidor (SRM) de
nivel superior establece la sesión nueva.
10. Método según cualquiera de las
reivindicaciones 3 a 7, caracterizado porque la transferencia
a la segunda red (RAT2) de acceso de una sesión de descarga
establecida en la primera red (RAT1) de acceso mediante un servidor
(PX1, PX2) proxy en un nivel de la estructura de servidor superior
al nivel más bajo se gestiona por el mismo servidor que ha
establecido la sesión si las dos redes de acceso están conectadas a
un mismo medio (SGSN) de control de servicios de paquete.
11. Método cualquiera de las reivindicaciones 3
a 7, caracterizado porque las redes de acceso primera y
segunda están conectadas a un medio (SGSN) de control de servicios
de paquete diferente, y porque la transferencia de sesión se
gestiona mediante un servidor en un nivel jerárquico superior
independientemente del nivel jerárquico del servidor que ha
establecido la sesión en la primera red (RAT1) de acceso.
12. Sistema de comunicación móvil basado en el
protocolo de Internet y que permite tecnologías de acceso
heterogéneas a una red central que incluye al menos un centro de
conmutación móvil de pasarela y de servicio y nodos de soporte GPRS
(S-MSC/SGSN y G-MSC/GGSN), en el que
al menos algunos de los usuarios tienen acceso a instalaciones de
descarga de software en tiempo no real y presentan un equipamiento
(UE) que permite la conexión a una red de sistema a través de una
pluralidad de dichas tecnologías de acceso, estando equipados dicho
equipamiento de usuario (UE) y la red (RAT1, RAT2, CN) del sistema
con medios (CL, PX1, RG1...PX3, RG3) que comprenden aplicaciones
(CL) de agente de usuario y servidores (PX1, RG1...PX3, RG3) proxy y
de registro para establecer y gestionar sesiones de descarga de
software a través del protocolo de inicialización de sesión (SIP),
caracterizado porque para la recuperación de descarga en caso
de un traspaso entre una primera (RAT1) y una segunda (RAT2) red de
acceso que emplean diferentes tecnologías de acceso mientras una
sesión de descarga de software está en curso, el agente de usuario
(CL) SIP asociado a un equipamiento de usuario (UE) para el traspaso
se dispone, al recibir una nueva dirección IP y un nuevo URL en la
segunda red (RAT2) de acceso, y sin liberar la sesión en curso,
enviar un mensaje de petición de transferencia a un servidor (PX1)
proxy SIP que está actualmente encargado de la sesión de descarga,
contiendo dicha petición de transferencia información sobre la
dirección y el URL en la primera red (RAT1) de acceso, el nuevo URL,
la identidad de sesión y el último paquete de software que se ha
recibido con éxito, informándose por tanto a dicho servidor (PX1)
proxy de que la sesión ha de transferirse al agente de usuario (CL)
en el nuevo URL y estando dispuesto para iniciar las operaciones
para establecer una nueva sesión con el agente de usuario (CL) en el
nuevo URL bajo el control de un servidor (PX3) proxy al que se le
confía la tarea de gestionar dicha nueva sesión, y la descarga se
reanuda desde dicho último paquete recibido.
13. Sistema según la reivindicación 12,
caracterizado porque dicho servidor (PX3) proxy al que se le
confía la gestión de dicha nueva sesión se dispone, al aceptarse
dicha nueva sesión por el agente de usuario (CL), para proporcionar
la liberación de la sesión establecida bajo la cobertura de la
primera red (RAT1) de acceso.
14. Sistema según la reivindicación 12 o 13, que
comprende una estructura jerárquica y distribuida de unidades (PRM1,
PRM2, SRM, HRM) de gestión de descarga y una pluralidad de
repositorios (SP1, SP2, SS, SH1) de software accesibles, para la
descarga de software, a través de niveles jerárquicos diferentes de
dicha estructura de unidades (PRM1, PRM2, SRM, HRM) de gestión de
descarga, estando asociadas las unidades de gestión de descarga en
uno de dichos niveles a medios (SGSN) que controlan los servicios de
paquetes en el sistema, caracterizado porque dichos
servidores (PX1, RG1...PX3, RG3) SIP están organizados en una
estructura jerárquica en la que cada nivel está asociado a un nivel
de la estructura (PRM1, PRM2, SRM, HRM) de gestión de descarga en el
que se crean los niveles correspondientes en las dos estructuras,
albergando cada unidad (PRM1, PRM2, SRM, HRM) de gestión de descarga
en cualquiera de dichos niveles correspondientes un servidor
(PX1...PX3) proxy y un servidor (RG1...RG3) de registro.
15. Sistema según la reivindicación 14,
caracterizado porque los servidores (RG1, RG3) de registro en
todos los niveles jerárquicos de la estructura de servidor se
disponen para almacenar la identidad de agentes de usuario (CL) que
registran una sesión de descarga independientemente del nivel
jerárquico en el que puede accederse al software que va a
descargarse.
16. Sistema según la reivindicación 14 o 15,
caracterizado porque los servidores (PX1...PX3) proxy en un
nivel jerárquico dado de la estructura de servidor se disponen para
establecer sesiones concernientes al software presente en los
repositorios (SP1, SP2, SS, SH1) de software accesibles a través de
las unidades (PRM1, PRM2, SRM, HRM) de gestión de descarga por las
cuales se albergan dichos servidores.
17. Sistema que incluye al menos un centro de
conmutación móvil de pasarela y de servicio y nodos de soporte GPRS
(S-MSC/SGSN y G-MSC/GGSN) según
cualquiera de las reivindicaciones 14 a 16, caracterizado
porque un agente de usuario (CL) se dispone para solicitar
inicialmente el establecimiento de una sesión de descarga con el
servidor (PX1, PX2) de nivel más bajo, y en caso de que el software
que va a descargarse no esté presente en el repositorio (SP1, SP2)
accesible a través de una unidad (PRM1, PRM2)de gestión de
descarga en dicho nivel más bajo, dicho servidor (PX1, PX2) de nivel
más bajo está dispuesto para enviar una petición de transferencia de
sesión al agente de usuario (CL) que le informa de la necesidad de
establecer una sesión con un nivel superior, repitiéndose la
petición de establecimiento y la transmisión de la petición de
transferencia a y respectivamente en cada uno de los niveles
progresivamente superiores hasta que la petición de establecimiento
alcance el nivel en el que el software está disponible.
\newpage
18. Sistema según cualquiera de las
reivindicaciones 14 a 17, caracterizado porque los
repositorios (SS, SH1) de software accesibles a través de las
unidades (SRM, HRM) de gestión de descarga en niveles superiores a
los asociados con el nivel (PX1, PX2) más bajo de la estructura de
servidor almacenan también el software contenido en los repositorios
(SP1, SP2) de software accesibles a través de unidades (PRM1, PRM2)
de gestión de descarga en niveles inferiores.
19. Sistema según cualquiera de las
reivindicaciones 14 a 18, caracterizado porque los servidores
(PX3) proxy en un nivel inmediatamente superior a uno más bajo se
albergan en las unidades (SRM) de gestión de descarga asociadas a
dichos medios (SGSN) que controlan servicios de paquetes, y, en el
caso de un traspaso entre redes (RAT1, RAT2) de acceso conectadas a
un mismo medio (SGSN) de control de servicio de paquetes, dicho
servidor (PX3) proxy está dispuesto en un nivel inmediatamente
superior al nivel más bajo para gestionar la transferencia a la
segunda red (RAT2) de acceso de una sesión de descarga establecida
en la primera red (RAT1) de acceso mediante un servidor (PX1, PX2)
proxy en el nivel jerárquico más bajo.
20. Sistema según las reivindicaciones 12 y 19,
caracterizado porque dicho servidor (PX1, PX2) en el nivel
jerárquico más bajo se dispone para reaccionar a la recepción del
mensaje de petición de transferencia enviando un segundo mensaje de
petición de transferencia a dicho servidor (PX3) proxy de nivel
inmediatamente superior, y dicho servidor (PX3) proxy de nivel
inmediatamente superior se dispone para establecer la nueva sesión
en la segunda red (RAT2) de acceso al recibir dicho mensaje de
petición de transferencia y para liberar la sesión antigua pendiente
en la primera red (RAT1) de acceso.
21. Sistema según cualquiera de las
reivindicaciones 14 a 18, caracterizado porque los servidores
(PX3) proxy en niveles superiores al más bajo se disponen para
gestionar la transferencia a la segunda red (RAT2) de acceso de
sesiones de descarga que se han establecido en la primera red (RAT1)
de acceso en el caso de un traspaso entre redes (RAT1, RAT2) de
acceso conectadas a un mismo medio (SGSN) de control de servicio de
paquetes.
22. Sistema según cualquiera de las
reivindicaciones 14 a 18, caracterizado porque un servidor
proxy en un nivel jerárquico superior se dispone para gestionar la
recuperación de descarga en el caso de traspaso entre redes (RAT1,
RAT2) de acceso conectadas a diferentes medios (SGSN) de control de
servicio de paquetes independientemente del nivel del servidor proxy
que ha establecido la sesión de descarga en la primera red (RAT1) de
acceso.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP03425328A EP1480408B1 (en) | 2003-05-21 | 2003-05-21 | Method of software download with session mobility support in mobile communication systems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2268319T3 true ES2268319T3 (es) | 2007-03-16 |
Family
ID=33041155
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03425328T Expired - Lifetime ES2268319T3 (es) | 2003-05-21 | 2003-05-21 | Metodo para descargar software con soporte de movilidad de sesion en sistemas de comunicacion moviles. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7346027B2 (es) |
| EP (1) | EP1480408B1 (es) |
| CN (1) | CN1574838B (es) |
| AT (1) | ATE333182T1 (es) |
| DE (1) | DE60306754T2 (es) |
| ES (1) | ES2268319T3 (es) |
Families Citing this family (68)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1276620C (zh) * | 2003-01-10 | 2006-09-20 | 华为技术有限公司 | 一种为无线局域网用户提供定位业务的方法 |
| CN1549634A (zh) * | 2003-05-09 | 2004-11-24 | �ʼҷ����ֵ��ӹɷ�����˾ | 用于在无线广域网与无线局域网之间无缝漫游的系统和方法 |
| US20040242246A1 (en) * | 2003-05-30 | 2004-12-02 | Lee Chinmei Chen | Short message service request employment by application server component to obtain one or more mobile device short message service reports |
| US20060008256A1 (en) | 2003-10-01 | 2006-01-12 | Khedouri Robert K | Audio visual player apparatus and system and method of content distribution using the same |
| US20130097302A9 (en) | 2003-10-01 | 2013-04-18 | Robert Khedouri | Audio visual player apparatus and system and method of content distribution using the same |
| EP1531645A1 (en) * | 2003-11-12 | 2005-05-18 | Matsushita Electric Industrial Co., Ltd. | Context transfer in a communication network comprising plural heterogeneous access networks |
| US7568059B2 (en) | 2004-07-08 | 2009-07-28 | Asocs Ltd. | Low-power reconfigurable architecture for simultaneous implementation of distinct communication standards |
| KR100709799B1 (ko) * | 2004-10-20 | 2007-04-23 | 주식회사 팬택 | 듀얼모드 이동통신단말기에서의 연속적인 패킷 데이터서비스 제공 방법 |
| US20060120171A1 (en) * | 2004-11-12 | 2006-06-08 | Samy Touati | Seamless handoff of mobile terminal |
| US7551585B2 (en) * | 2004-12-03 | 2009-06-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Seamless handoff for multimedia services |
| GB2421156A (en) * | 2004-12-10 | 2006-06-14 | Ericsson Telefon Ab L M | Maintaining session across network address/port translation firewall in the event of an address change with a session manager |
| WO2006065025A1 (en) * | 2004-12-13 | 2006-06-22 | Electronics And Telecommunications Research Institute | Mobile communication system based on ip and session initiation method thereof |
| US20060159047A1 (en) * | 2005-01-18 | 2006-07-20 | Interdigital Technology Corporation | Method and system for context transfer across heterogeneous networks |
| JP2006237996A (ja) * | 2005-02-24 | 2006-09-07 | Nec Infrontia Corp | 遠隔保守・メンテナンスシステム、ｓｉｐ搭載機器、保守・メンテナンス機器および方法 |
| US20090327546A1 (en) * | 2005-03-03 | 2009-12-31 | Gaby Guri | System for and method of hand-off between different communication standards |
| US7921196B2 (en) | 2005-04-07 | 2011-04-05 | Opanga Networks, Inc. | Adaptive file delivery with transparency capability system and method |
| US7882176B2 (en) * | 2005-05-27 | 2011-02-01 | Microsoft Corporation | Establishing a multiparty session by sending invitations in parallel |
| US7660850B2 (en) * | 2005-05-27 | 2010-02-09 | Microsoft Corporation | Supporting a serial and a parallel invitation protocol |
| US7574212B2 (en) * | 2005-06-22 | 2009-08-11 | Sprint Spectrum L.P. | Method and system for managing communication sessions during multi-mode mobile station handoff |
| US20060291481A1 (en) * | 2005-06-27 | 2006-12-28 | Matsushita Electric Industrial Co., Ltd. | Application session resumption in mobile environments |
| US8315227B2 (en) * | 2005-09-27 | 2012-11-20 | Telefonaktiebolaget L M Ericsson (Publ) | GTP for integration of multiple access |
| US7536184B2 (en) * | 2005-09-29 | 2009-05-19 | Sun Microsystems, Inc. | Seamless mobility management with service detail records |
| CN101346634B (zh) * | 2005-11-04 | 2012-10-24 | 甲骨文国际公司 | 用于通信网络中的网守的系统和方法 |
| US7586878B2 (en) * | 2005-12-01 | 2009-09-08 | Industrial Technology Research Institute | Vertical handoff method and system in WLAN/3G integrated networks |
| US8214827B2 (en) * | 2005-12-05 | 2012-07-03 | Flash Networks, Ltd | Method and system for improving user confidence and experience in content purchasing via a service provider premises |
| DE602006000816T2 (de) * | 2006-01-03 | 2008-07-03 | Alcatel Lucent | Verfahren zur Bereitstellung von nahtlose mobile Sitzung |
| DE602006000347T2 (de) * | 2006-01-05 | 2008-12-04 | Alcatel Lucent | Verfahren zum Herstellen einer Kommunikationssitzung und Kommunikationsnetzwerk |
| US9094947B2 (en) * | 2006-01-16 | 2015-07-28 | Nokia Corporation | Combining IP and cellular mobility |
| US20070218902A1 (en) * | 2006-02-09 | 2007-09-20 | Darek Smyk | System and method for adaptive seamless mobility of multimedia communication sessions |
| EP1821488B1 (en) * | 2006-02-15 | 2012-08-08 | Alcatel Lucent | Method and apparatus for providing session mobility |
| SE0600564L (sv) * | 2006-03-15 | 2007-03-06 | Teliasonera Ab | Automatisk positionering av utrustning ansluten till ett tele-och datakommunikationssystem |
| GB2437343B (en) * | 2006-04-21 | 2008-04-23 | Motorola Inc | Handover between radio networks |
| US8001250B2 (en) * | 2006-05-16 | 2011-08-16 | Oracle International Corporation | SIP and HTTP convergence in network computing environments |
| US8171466B2 (en) * | 2006-05-16 | 2012-05-01 | Oracle International Corporation | Hitless application upgrade for SIP server architecture |
| US8112525B2 (en) * | 2006-05-16 | 2012-02-07 | Oracle International Corporation | Engine near cache for reducing latency in a telecommunications environment |
| US8219697B2 (en) | 2006-05-17 | 2012-07-10 | Oracle International Corporation | Diameter protocol and SH interface support for SIP server architecture |
| US8209434B2 (en) * | 2006-06-22 | 2012-06-26 | Sony Ericsson Mobile Communications Ab | Continued transfer or streaming of a data file after loss of a local connection |
| US8468131B2 (en) * | 2006-06-29 | 2013-06-18 | Avaya Canada Corp. | Connecting devices in a peer-to-peer network with a service provider |
| US20080002710A1 (en) * | 2006-06-29 | 2008-01-03 | Motorola, Inc. | System and method for routing communications to mobile stations |
| US8290819B2 (en) * | 2006-06-29 | 2012-10-16 | Microsoft Corporation | Electronic commerce transactions over a peer-to-peer communications channel |
| CN102148857A (zh) * | 2006-07-20 | 2011-08-10 | 桑迪士克股份有限公司 | 内容分布系统 |
| JP2008067311A (ja) * | 2006-09-11 | 2008-03-21 | Ntt Docomo Inc | 移動通信端末及びダウンロード再開制御方法 |
| US8130733B2 (en) * | 2006-10-30 | 2012-03-06 | The Boeing Company | Providing ad-hoc interoperability among network nodes |
| US8725890B2 (en) * | 2006-10-31 | 2014-05-13 | Thomson Licensing | Data recovery in heterogeneous networks using peer's cooperative networking |
| US8923852B2 (en) | 2006-11-01 | 2014-12-30 | Seven Networks, Inc. | System, method, and computer-readable medium for user equipment decision-making criteria for connectivity and handover |
| US8014767B1 (en) * | 2006-11-06 | 2011-09-06 | Sprint Communications Company L.P. | Wireless communication network with software update monitoring and notification |
| CN101193442B (zh) * | 2006-11-23 | 2010-12-08 | 华为技术有限公司 | 一种实现多媒体呼叫移动性的系统、方法及装置 |
| CN101622846B (zh) * | 2007-03-01 | 2013-02-27 | 艾利森电话股份有限公司 | 下载的多媒体文件的比特流组合 |
| US8010093B2 (en) * | 2007-03-08 | 2011-08-30 | Infineon Technologies Ag | Communication network unit and method for exchanging capability information |
| US7983218B2 (en) * | 2007-03-29 | 2011-07-19 | Intel Corporation | Techniques to support seamless mobility of electronic devices engaged in a session initiation protocol (SIP) session |
| KR101417001B1 (ko) | 2007-08-21 | 2014-08-06 | 삼성전자주식회사 | 위치 정보 제공 시스템 및 그 방법 |
| US20090150562A1 (en) * | 2007-12-07 | 2009-06-11 | Research In Motion Limited | Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity |
| KR101611168B1 (ko) * | 2008-10-09 | 2016-04-12 | 삼성전자주식회사 | 파일 다운로드 또는 스트리밍 과정에서 핸드오버 또는 로밍을 위한 장치 및 방법 |
| US9137026B1 (en) * | 2009-04-23 | 2015-09-15 | Sprint Communications Company L.P. | Seamless service transitions for dual-network mobile devices |
| US8467786B2 (en) * | 2009-05-04 | 2013-06-18 | Motorola Mobility Llc | Communication devices and methods for providing services to communication devices in a communication system including a private cell |
| US8902853B2 (en) * | 2011-05-27 | 2014-12-02 | Empire Technology Development Llc | Maintaining service priority for mobile devices during network handoffs |
| SG187286A1 (en) * | 2011-07-29 | 2013-02-28 | Smart Communications Inc | System and method for activating a mobile device to initiate a communication |
| CN102307362B (zh) * | 2011-09-06 | 2015-06-17 | 北京傲天动联技术股份有限公司 | 用于实现功能配置的终端设备和控制设备及其网络系统 |
| GB2511562B (en) * | 2012-03-02 | 2015-08-12 | Seven Networks Inc | Providing data to a mobile application accessible at a mobile device via different network connections without interruption and mobile device which hands over |
| US10164857B2 (en) * | 2013-11-14 | 2018-12-25 | Eric P. Vance | System and method for machines to communicate over the internet |
| EP3103245B1 (en) * | 2014-02-05 | 2019-06-19 | Seon Design (USA) Corp. | Uploading data from mobile devices |
| CN104320490B (zh) * | 2014-11-12 | 2018-07-24 | 博康云信科技有限公司 | 一种基于sip的断点续传的可靠数据传输方法和系统 |
| US10341923B2 (en) * | 2016-01-29 | 2019-07-02 | Google Llc | Techniques for minimizing user disruption during network connection switching |
| CN107484225B (zh) * | 2017-07-05 | 2020-10-16 | 宇龙计算机通信科技(深圳)有限公司 | 一种网络接入控制方法、装置及用户终端 |
| US11553354B2 (en) * | 2020-06-29 | 2023-01-10 | At&T Intellectual Property I, L.P. | Apparatuses and methods for enhancing network controls based on communication device information |
| CN112184172B (zh) * | 2020-10-12 | 2022-08-09 | 北京美络克思科技有限公司 | 电子档案在线移交、接收方法及移交接收系统 |
| CN115119154A (zh) * | 2021-03-17 | 2022-09-27 | 深圳市万普拉斯科技有限公司 | 数据连接管理方法、装置、电子设备和可读存储介质 |
| US11943836B1 (en) | 2021-05-06 | 2024-03-26 | T-Mobile Usa, Inc. | Service-based architecture for internet protocol multimedia subsystem |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3529621B2 (ja) * | 1997-05-12 | 2004-05-24 | 株式会社東芝 | ルータ装置、データグラム転送方法及び通信システム |
| EP1150521A1 (en) * | 2000-04-25 | 2001-10-31 | Alcatel | Method for setting up a session between a host of a data network and a mobile terminal of a mobile network and device for performing such method |
| TW532040B (en) * | 2000-10-20 | 2003-05-11 | Koninkl Philips Electronics Nv | Method and system for transferring a communication session |
-
2003
- 2003-05-21 DE DE60306754T patent/DE60306754T2/de not_active Expired - Lifetime
- 2003-05-21 EP EP03425328A patent/EP1480408B1/en not_active Expired - Lifetime
- 2003-05-21 AT AT03425328T patent/ATE333182T1/de not_active IP Right Cessation
- 2003-05-21 ES ES03425328T patent/ES2268319T3/es not_active Expired - Lifetime
-
2004
- 2004-05-17 US US10/846,589 patent/US7346027B2/en not_active Expired - Fee Related
- 2004-05-20 CN CN2004100458548A patent/CN1574838B/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1480408B1 (en) | 2006-07-12 |
| DE60306754T2 (de) | 2007-07-12 |
| US20040233866A1 (en) | 2004-11-25 |
| US7346027B2 (en) | 2008-03-18 |
| EP1480408A1 (en) | 2004-11-24 |
| DE60306754D1 (de) | 2006-08-24 |
| ATE333182T1 (de) | 2006-08-15 |
| CN1574838A (zh) | 2005-02-02 |
| CN1574838B (zh) | 2010-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2268319T3 (es) | Metodo para descargar software con soporte de movilidad de sesion en sistemas de comunicacion moviles. | |
| US8315227B2 (en) | GTP for integration of multiple access | |
| KR100970955B1 (ko) | 무선 근거리 네트워크(ｗｌａｎ) 및 선택된 공공 육상 이동 네트워크(ｐｌｍｎ)와의 통신 방법 | |
| US7280505B2 (en) | Method and apparatus for performing inter-technology handoff from WLAN to cellular network | |
| US8644247B2 (en) | Inter-system handoffs in multi-access environments | |
| EP2276286B1 (en) | WLAN radio access network to UMTS radio access network handover with network requested packet data protocol context activation | |
| JP5227960B2 (ja) | プロキシ・モバイルｉｐ向けパケット転送 | |
| US8644249B2 (en) | Telecommunication system and method for controlling switching of user terminal between two networks | |
| EP2194686A1 (en) | Secure tunnel establishment upon attachment or handover to an access network | |
| EP1605662A2 (en) | Mobile terminal, server, and method of controlling routing path for voice-over-IP service | |
| US20110255409A1 (en) | Control station, mobile station and mobile communication system | |
| JPWO2006109462A1 (ja) | 無線通信システムおよび無線通信方法 | |
| JP2010213357A (ja) | ２つの無線ネットワークのインターフェースを確立する方法 | |
| JP2010539838A (ja) | マルチアクセス環境におけるシステム間ハンドオフ | |
| TWM294789U (en) | Apparatus and system for interworking of cellular networks and wireless local area networks | |
| JP2007336113A (ja) | 通信システム、動作制御方法、位置管理サーバ及びプログラム | |
| CN101534496A (zh) | 一种用户获得家乡链路信息的方法 | |
| EP1224819B1 (en) | Packet data service in a mobile communications system | |
| Atayero et al. | Heterogeneous wireless networks: A survey of interworking architectures | |
| Salkintzis et al. | 4.4 Mobile Internet | |
| Sengodan et al. | Wireless and mobility issues in IP telephony |