ES2331999T3 - Procedimiento y arquitectura de red para configurar un terminal de radio, un terminal de radio, un nodo de red y un producto de programa de ordenador para el mismo. - Google Patents
Procedimiento y arquitectura de red para configurar un terminal de radio, un terminal de radio, un nodo de red y un producto de programa de ordenador para el mismo. Download PDFInfo
- Publication number
- ES2331999T3 ES2331999T3 ES04790941T ES04790941T ES2331999T3 ES 2331999 T3 ES2331999 T3 ES 2331999T3 ES 04790941 T ES04790941 T ES 04790941T ES 04790941 T ES04790941 T ES 04790941T ES 2331999 T3 ES2331999 T3 ES 2331999T3
- Authority
- ES
- Spain
- Prior art keywords
- ota
- client
- radio terminal
- message
- download
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
- H04W8/24—Transfer of terminal data
- H04W8/245—Transfer of terminal data from a network towards a terminal
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
- Transceivers (AREA)
Abstract
Arquitectura de red que comprende una red de comunicación que es operativa según un sistema de comunicación predeterminado y que comprende al menos un terminal de radio (UE/MS) que pertenece a dicha red de comunicación y que comprende módulos para gestionar un intercambio de información en el interior de dicha red de comunicación utilizando dicho sistema de comunicación predeterminado, - estando dicha arquitectura caracterizada por - al menos un nodo (Servidor OTA), conectado a dicha red de comunicación y que comprende - un conjunto de módulos de programa operativo configurados para implementar al menos un conjunto de elementos de una pila de protocolos para configurar dicho terminal de radio (UE/MS), y por el hecho de que - dicho terminal de radio y dicho nodo están provistos de módulos de programa hertzianos respectivo configurados para gestionar una conexión hertziana entre dicho terminal de radio (UE/MS) y dicho nodo (Servidor OTA) a través de dicha red de comunicación y para descargar de manera transparente en dicha red de comunicación al menos un módulo de dicho conjunto de módulos de programa operativo para configurar al menos en parte a dicho terminal de radio (UE/MS).
Description
Procedimiento y arquitectura de red para
configurar un terminal de radio, un terminal de radio, un nodo de
red y un producto de programa de ordenador para el mismo.
La presente invención se refiere en general a
las redes de comunicación por radio y a los terminales de radio
reconfigurables que emplean una red de comunicación radio.
Más específicamente, la presente invención se
refiere a la configuración de un terminal de radio reconfigurable,
siendo dicha configuración llevada a cabo instalando en dicho
terminal de radio un programa operativo descargado por ondas de
radio (OTA) desde la red de comunicación radio.
Ya es conocido de la literatura (J. Mitola,
"The Software Radio Architecture", IEEE Communications
Magazine, Mayo de 1995 y E. Buracchini, "The Software Radio
Concept", IEEE Communications Magazine, Septiembre de 2000) que
los sistemas reconfigurables como los terminales, estaciones base y
nodos de la red, son equipos cuyo funcionamiento operativo se puede
configurar a voluntad. Por ejemplo, un terminal de radio
reconfigurable capaz de funcionar con un sistema de segunda
generación (2G), como el GSM/GPRS (Global System for Mobile
communication/General Packet Radio Service), puede ser
reconfigurado para volverse capaz de funcionar con sistemas de
tercera generación (3G), como el sistema UMTS (Universal Mobile
Telecommunication System) o el sistema CDMA 2000 (Code Division
Multiple Access 2000), o el sistema WI-FI (WIrless
FIdelity) o el sistema DVB-T (Digital Video
Broadcasting Terrestrial) y así sucesivamente.
Debe entenderse por "sistema" una
pluralidad de elementos coordinados entre sí según criterios
predeterminados, es decir coordinados según un "Estándar",
para realizar una función específica que es, por ejemplo, la de
operar como una red de comunicación.
En el presente documento ejemplos de sistemas
son el sistema GSM, el sistema GPRS, el sistema UMTS, el sistema
WLAN (Wireless Local Area Network) y así sucesivamente, cada uno de
los cuales satisface el Estándar correspondiente.
Para llevar a cabo la reconfiguración de un
terminal, es necesario que las funciones operativas del terminal se
realicen con una tecnología también reconfigurable. Referente a
esto, los terminales o dispositivos reconfigurables están provistos
de hardware reprogramable constituido, por ejemplo, por una
pluralidad de FPGAs (Field Programmable Gate Array), DSPs (Digital
Signal Processor) y microprocesadores: las funcionalidades
individuales del dispositivo, incluso en el nivel más bajo, son
realizadas por un código de programa. Como consecuencia, para
reconfigurar un dispositivo reprogramable, basta con sustituir el
programa operativo que gestiona el hardware del propio
dispositivo.
dispositivo.
Por el término "programa operativo" debe
entenderse en la presente descripción el programa, organizado en
librerías, que define tanto a la interfaz de radio o las capas
inferiores (por ejemplo L1, L2, L3) como a las capas superiores
(por ejemplo de L4 a L7) de la pila de protocolos de un sistema
considerado, como por ejemplo GSM/GPRS, UMTS y así
sucesivamente.
Como es sabido, en el sector de las
telecomunicaciones, el procedimiento más empleado para obtener un
agrupamiento funcional es el modelo OSI (Open System
Interconnection). Las funcionalidades están agrupadas en planos
o capas funcionales representados en forma de pila de capas.
Cada capa suministra servicios a la capa
inmediatamente superior, siendo dichos servicios a su vez mejoras
de los servicios suministrados por la capa inmediatamente
inferior.
La capa más baja (capa 1) está en general
destinada a transmitir la información físicamente.
Según la especificación OSI, el número de capas
de estándares es 7: respectivamente capas física, de conexión, de
red, de transporte, de sesión, de presentación y de aplicación. Cada
sistema, por ejemplo GSM/GPRS, UMTS y así sucesivamente, implementa
la parte necesaria de dicha pila de estándares.
Al considerar un terminal de radio, los
beneficios proporcionados al emplear hardware reconfigurable
hardware son varios, pero uno de ellos es inmediatamente evidente:
el terminal de radio puede ser reconfigurado según el sistema que
cubre el área donde está localizado el terminal (área funcional).
Por lo tanto, sí el terminal se emplea en un área cubierta por un
sistema de segunda generación, como el GSM/GPRS, el terminal puede
ser reconfigurado para ser capaz de recibir a dicho sistema;
igualmente, en un área cubierta por un sistema de tercera
generación, como el UMTS, el terminal puede ser configurado en
conformidad.
\newpage
Es conocido que un código de programa puede ser
transferido o descargado a un terminal al menos de tres formas
diferentes:
- a través de una tarjeta inteligente utilizando
un SIM (Subscriber Identity Module) que debe ser insertado
en el interior del terminal de radio móvil;
- a través de una conexión externa utilizando
por ejemplo un enlace con un ordenador personal a través de un
puerto infrarrojo/ serie/USB;
- por vía radio o hertziana (OTA) utilizando un
canal de radio específico. Referente a la descarga de programas,
las etapas fundamentales de un protocolo genérico que permite
gestionar la descarga de programas a un terminal se han definido en
el marco del programa Defined Radio Forum (Foro SDR) que
puede consultarse en la URL siguiente: www.sdrforum.org.
\vskip1.000000\baselineskip
El protocolo, tal como se ha definido en el foro
SDR, es de tipo servidor tipo cliente.
Las etapas del protocolo de descarga son las
siguientes:
- inicio de descarga: etapa durante la cual el
terminal comunica al servidor, en el cual reside el programa a
descargar, la intención de empezar una descarga de programa;
- autenticación mutual: el terminal y el
Servidor se autentican entre sí;
- intercambio de capacidad: el Servidor comunica
la información de capacidad relativa al programa a descargar y el
terminal verifica si el programa puede ser cargado en la memoria del
terminal, instalado y ejecutado;
- aceptación de descarga: el Servidor comunica
al terminal la descarga, instalación y opciones de facturación; el
terminal decide si las indicaciones suministradas por el Servidor
son o no aceptables;
- comprobación de descarga e integridad: durante
la descarga de programas, el código recibido es comprobado; el
terminal solicita la retransmisión de los bloques radio recibidos
incorrectamente;
- instalación: durante la etapa de instalación,
las condiciones de licencia y de facturación del programa son
proporcionados por el Servidor;
- comprobación in-situ:
antes de empezar el programa, el terminal lleva a cabo algunas
comprobaciones con ayuda de vectores de comprobación descargados
junto con el código de programa;
- intercambio de no rechazo: una vez instalado y
comprobado el código de programa, el terminal confirma al Servidor
que la instalación ha sido exitosa para iniciar, por ejemplo, el
proceso de facturación.
\vskip1.000000\baselineskip
Es conocido del estado de la técnica, por
ejemplo de E. Buracchini, "The Software Radio Concept", IEEE
Communications Magazine, Septiembre de 2000, que la descarga de
programas vía radio o hertziana prevé el empleo por parte del
terminal de un canal de radio. Asimismo es conocido que la descarga
de código de programa puede realizarse de dos maneras, dependiendo
de la tipología del canal de radio:
- de manera "fuera de banda": mediante un
canal "universal" independiente del sistema actual, por ejemplo
cuando se enciende el terminal, que se ajusta automáticamente a
dicho canal y realiza la descarga del programa operativo relativo
al sistema que opera en el área funcional;
- de manera "en band": utilizando los
canales radio de los sistemas de telefonía móvil estándar de segunda
y tercera generación, como los sistemas GSM/GPRS y UMTS
respectivamente, lo cual perite que el terminal, que ya opera en
uno de esos canales, reciba el programa operativo relativo al
sistema diferente del que se está utilizando actualmente; por
ejemplo, un terminal reconfigurable que opera con un sistema de
segunda generación, como el GSM/GPRS, puede realizar la descarga de
un sistema de tercera generación, como el UMTS, utilizando el canal
de radio de segunda generación con el cual opera.
\vskip1.000000\baselineskip
Un ejemplo de programa de descarga "fuera de
banda" se describe por ejemplo en la solicitud de patente
japonesa Nº. 2001061186. Este sistema describe un sistema y un
procedimiento para descargar contenidos de programa vía radio.
Cuando se enciende un terminal de radio, busca en un canal universal
cual es el sistema actual en el área de funcionamiento y lleva a
cabo la descarga de programas relativos al sistema indicado.
\newpage
Un ejemplo de descarga de programas "en
banda" se describe por ejemplo en la solicitud de patente
americana Nº 2003/0163551. Este documento describe un sistema y un
procedimiento para descargar software vía radio
empleando:
empleando:
- canales dedicados durante las etapas de
negociación entre el servidor y el terminal (intercambio de
capacidad, autenticación, facturación y así sucesivamente), y
- canales comunes compartidos durante el proceso
de descarga para proporcionar el servicio de descarga a tantos
usuarios como sea posible simultáneamente, sin imponer restricciones
a los recursos de radio disponibles.
\vskip1.000000\baselineskip
Al considerar la manera de descargar "en
banda", el documento AAW, "Architecture of IP based Network
Elements Supporting Reconfigurable Terminals", SCOUT Workshop 16
de Septiembre de 2003 sugiere modificar profundamente algunos
protocolos y algunos nodos de la red, por ejemplo los nodos de
acceso de radio y/o los nodos de red centrales, para hacer posible
la gestión de la descarga de un programa operativo.
Estas modificaciones implican un esfuerzo
considerable para los fabricantes de equipos para la red de
operadores e impacta considerablemente en los estándares de los
sistemas de telefonía móvil existentes. Por lo tanto, las técnicas
conocidas presentan la limitación de que, cuando se desea añadir a
la red de telefonía móvil existente, como por ejemplo GSM/GPRS o
UMTS, el programa operativo de gestión de descargas para terminales
reconfigurable, son necesarias amplias modificaciones en los
protocolos y en los nodos de la red.
Un procedimiento para la gestión de programas de
descarga para un terminal reconfigurable en un sistema inalámbrico
también se describe en "Design of software download management
for reconfigurable terminals in a WCDMA system" de Jijun Lou
y otros, IEEE, 2002.
Considerando la manera fuera de banda, según el
estado de la técnica, se necesario implementar un canal de radio
dedicado y por lo tanto equipos de red o nodos de red dedicados en
la red para su implementación.
En resumen, el Solicitante destaca que en el
estado de la técnica la descarga de programas tanto "en banda"
como en "fuera de banda" implica modificar profundamente
algunos protocolos y algunos nodos de la red para configurar un
terminal de radio reconfigurable.
Es por lo tanto un objeto de la presente
invención gestionar la descarga de un programa operativo para
reconfigurar un terminal de radio sin modificar la arquitectura ni
los protocolos de los nodos de la red.
El mencionado objeto de la presente invención se
alcanza a través de un procedimiento, una arquitectura de red y un
producto de programa de ordenador como los reivindicados en las
reivindicaciones adjuntas.
Según la invención se proporcionan una
arquitectura, un procedimiento y un producto de programa de
ordenador o conjunto productos de programas de ordenador
relacionados, cargable en la memoria de al menos un ordenador y que
comprende partes de código de programa para llevar a cabo las etapas
consistentes en el procedimiento de la invención cuando se ejecuta
el programa en un ordenador. Tal como se emplea aquí, la referencia
a un tal producto de programa de ordenador debe entenderse como
equivalente a la referencia a un medio legible por un ordenador que
contiene instrucciones para controlar un sistema de ordenador para
coordinar la realización del procedimiento de la invención. Con la
referencia a "al menos un ordenador" se pretende evidentemente
destacar la posibilidad de implementar la presente invención de
forma modular y distribuida. Específicamente, según la presente
invención se proporcionan, según una realización preferida, una
arquitectura y un procedimiento según los cuales el terminal puede
realizar por vía radio la descarga de un programa operativo mediante
el cual es posible reconfigurar la terminal de radio móvil, sin
siendo intrusivos ni la arquitectura ni el procedimiento; en
particular, la descarga se puede implementar de una manera
transparente al sistema de acceso radio de telefonía móvil empleado
que puede ser de segunda generación, como el GSM/GPRS, el IS95
(Interim Standard 95) o el PDC (Phone Digital
Cellular), o de tercera generación (por ejemplo los sistemas de
acceso radio de la familia IMT 2000 - International Mobile
Telecommunications
2000).
2000).
Según la invención, la arquitectura está
provista de un nodo conectado a la red capaz de gestionar la
descarga de un programa operativo por ondas de radio, sin afectar a
los protocolos de red ya existentes.
Según una realización preferida de la invención,
el producto de programa de ordenador explota el protocolo TCP/IP
(Transport Control Protocol/Internet Protocol) que está
soportado tanto por los sistemas de segunda como de tercera
generación.
Según la invención, el protocolo propuesto es
coherente con las recomendaciones proporcionadas por el Foro
SDR.
Según la invención, el programa de descarga
hertziano es transparente a la red de acceso y a la red
central.
Según la invención, la arquitectura es
independiente del sistema considerado y se puede implementar en
cualquier sistema presente o futuro, tal como los sistemas de
segunda generación, como por ejemplo el GSM/GPRS, sistemas de
tercera generación, como UMTS, y otros, como por ejemplo DVB, WLAN,
802.16, etc.
Según la invención, se proporciona un nodo de
tipo servidor en el que reside el programa operativo y que está
conectado a la red y es capaz de realizar la descarga del programa
operativo en el terminal de radio. Además, según la invención, el
procedimiento empleado para reconfigurar el terminal de radio no es
intrusivo y puede explotar todas las características de la red que
le da soporte.
La invención se describirá a continuación con
referencia a las figuras adjuntas de realizaciones de la invención
preferidas aunque no limitativas, en las cuales:
- La figura 1 ilustra una realización de la
invención implementada en una red GPRS o UMTS genérica;
- La figura 2 es un diagrama de estado de las
etapas de protocolo llevadas a cabo por un producto de programa de
ordenador en el lado terminal de radio;
- La figura 3 es un diagrama de estado de las
etapas de protocolo llevadas a cabo por un servidor en el lado de
red;
- Las figuras 4a a 4k ilustran la estructura de
los mensajes de protocolo intercambiados entre un terminal de radio
móvil y el Servidor;
- Las figura 5a a 5j son diagramas de flujo que
muestran en detalle el proceso de descarga de un programa operativo
a instalar en un terminal de radio móvil;
- La figura 6 ilustra un diagrama secuencial del
proceso de descarga que muestra en particular la apertura de la
conexión radio entre un terminal de radio móvil y el Servidor.
A lo largo de toda la descripción se han
empleado en las figuras las mismas referencias para indicar los
mismos componentes o que implementan funciones sustancialmente
equivalentes.
Con referencia a la figura 1, se representa una
realización de la invención implementada en un sistema de segunda
(2G) y tercera (3G) generación. En particular, se representa una
arquitectura de red o arquitectura que comprende una red (Red) GPRS
genérica, una red UMTS genérica y un servidor (Servidor OTA) o nodo
conectado a la red.
La red también comprende un terminal
reconfigurable UE/MS (Equipo de Ususario/Estación Móvil), una red
de acceso de radio GERAN (red de acceso de radio GSM EDGE) de un
sistema GPRS y una UTRAN (Red de acceso de radio terrestre UMTS) de
un sistema UMTS y la red central de dominio de paquetes,
constituida, por ejemplo, por los nodos SGSN (Nodo de Soporte de
servicio GPRS) y GGSN (Nodo de Soporte de pasarela GPRS). El nodo
GGSN está conectado, por ejemplo, a través de un servidor PROXY
(PROXY), a una red de tipo Internet (Internet).
El terminal UE/MS está provisto, según una
realización preferida de la presente invención, de una aplicación
de programa, llamada Cliente OTA, que es capaz de gestionar la
descarga de un programa operativo desde el Servidor OTA
directamente conectado, por ejemplo, al nodo GGSN de la red central.
El Servidor OTA, como sabrá apreciar un experto en la materia,
también puede estar conectado indirectamente a la red central, por
ejemplo a través de uno o más dispositivos de comunicación de tipo
conocido.
La aplicación de programa de Cliente OTA y el
nodo Servidor OTA correspondiente emplean, por ejemplo, el
protocolo de transporte TCP/IP.
La arquitectura del Servidor OTA proporciona un
contexto a cada Cliente OTA con el cual está activa la sesión de
descarga. El funcionamiento de la aplicación de programa proporciona
un diagrama de estado para cada cliente OTA y para el contexto
correspondiente definido como Contexto de Cliente gestionado por el
Servidor OTA.
Según una realización preferida, el programa
operativo comprende un conjunto de módulos de programa operativos,
preferentemente una pluralidad de módulos de programa. La invención
permite la descarga de módulos de programa operativo que
implementan al menos un conjunto de elementos de una pila de
protocolos empleados en la red para reconfigurar un terminal de
radio UE/MS.
Como podrá apreciar un experto en la materia,
también es posible descargar un módulo de programa operativo para
actualizar una o más capas de protocolo o una parte de una capa
específica de la pila de protocolos con la finalidad de insertar
nuevas funcionalidades, actualizaciones o programas de ajuste.
\newpage
Con referencia a la figura 2, se representa el
diagrama de estado de la aplicación de programa Cliente OTA
instalada en el terminal UE/MS (lado Terminal).
Los términos empleados para denominar a los
estados son puramente indicativos, aunque es significativo el
comportamiento correspondiente tal como se describe.
Según una realización preferida de la presente
invención, los estados y las transiciones relativas del cliente
OTA, son las siguientes:
- estado IDLE: el Cliente OTA o Cliente está en
este estado cuando no hay activo ningún proceso de descarga de
programas; el Cliente vuelve a este estado sí el proceso termina
correctamente o sí ocurre un fallo;
- estado DOWNLOAD INITIATION: cuando es
necesario realizar la descarga del programa operativo, por ejemplo
cuando lo solicita el usuario o está controlado por la red, el
Cliente entra en este estado y se inicia un temporizador T100; el
temporizador T100 se para en caso de cambio de estado; sí el
temporizador T100 expira antes de un cambio de estado, el Cliente
vuelve al estado IDLE;
- estado MUTUAL AUTENTICACIÓN: en este estado el
Cliente realiza la autenticación mutua con el Servidor OTA; el
Cliente entra en este estado cuando una solicitud de autenticación
llega desde el Servidor; el Cliente inicia un temporizador T200; el
temporizador T200 se para en caso de cambio de estado; sí el
temporizador T200 expira antes de un cambio de estado o falla la
autenticación, el Cliente vuelve al estado IDLE;
- estado SOLICITUD DE CAPACIDAD: en este estado
el Cliente proporciona al servidor su capacidad; el Cliente entra
en este estado cuando el Servidor solicita su capacidad; el Cliente
inicia un temporizador T300; el temporizador T300 se para en caso
de cambio de estado; sí el temporizador T300 expira antes de un
cambio de estado, el Cliente vuelve al estado IDLE;
- estado DOWNLOAD ACCEPTANCE: en este estado el
Cliente determina sí continua la descarga según la información
recibida por el Servidor; el Cliente entra en este estado cuando
recibe desde el Servidor el perfil de descarga a realizar; sí el
perfil recibido es rechazado, el Cliente vuelve al estado IDLE;
- estado SOFTWARE DOWNLOAD: en este estado el
Cliente realiza la descarga del programa; el Cliente entra en este
estado sí el perfil de descarga es aceptado; el Cliente inicia un
temporizador T400; el temporizador T400 es puesto a cero y
reiniciado en cada bloque de programa recibido por el Servidor; el
temporizador T400 se para en caso de cambio de estado; sí el
temporizador T400 expira antes de un cambio de estado o la descarga
falla o los programas descargados no cumplen con la capacidad, el
Cliente vuelve al estado IDLE;
- estado INSTALLATION: en este estado el Cliente
envía una solicitud de licencia al Servidor e instala el programa
operativo; el Cliente entra en este estado al final de la descarga;
el Cliente inicia un temporizador T500; el temporizador T500 se
para en caso de cambio de estado; sí el temporizador T500 expira
antes de un cambio de estado o la licencia no es aceptada, el
Cliente vuelve al estado IDLE;
- estado IN-SITU TESTING:
en este estado el Cliente realiza algunas comprobaciones en los
programas descargados utilizando algunos vectores de comprobación
recibidos por el Servidor; el Cliente entra en este estado cuando
el programa operativo se ha instalado; una vez finalizadas las
comprobaciones, el Cliente vuelve al estado IDLE.
\vskip1.000000\baselineskip
Con referencia a la figura 3, se representa el
diagrama de estado de un Contexto de Cliente gestionado por un
servidor OTA (Lado Terminal).
Como se ha destacado previamente, los términos
utilizados para nombrar a los estados son puramente indicativos,
aunque sí es significante el comportamiento correspondiente tal como
se describe.
Los estados y las transiciones relativas del
Contexto-Cliente se describen a continuación:
- estado IDLE: el Contexto de Cliente gestionado
por el Servidor OTA está en este estado cuando no hay proceso de
descarga de programas activo alguno; el Contexto de Cliente vuelve a
este estado sí un proceso termina correctamente o sí ocurre un
fallo;
- estado DOWNLOAD INITIATION: en este estado el
Contexto-Cliente o Servidor OTA ordena al Cliente
OTA realizar una descarga; cuando es necesario realizar la descarga
del programa operativo, cuando por ejemplo dicha descarga es
solicitada por el cliente OTA o está programada según una
actualización periódica, el Contexto de Cliente entra en este
estado y se inicia un temporizador T101; el temporizador T101 se
para antes de un cambio de estado; sí el temporizador T101 expira
antes de un cambio de estado, entonces el Contexto de Cliente vuelve
al estado IDLE;
- estado MUTUAL AUTENTICACIÓN: en este estado el
Servidor se autentica y solicita el Cliente OTA que se identifique;
el Servidor OTA entra en este estado cuando recibe del Cliente la
confirmación de descarga; el Servidor OTA inicia un temporizador
T201; el temporizador T201 se para en caso de cambio de estado; sí
el temporizador T201 expira antes de un cambio de estado o falla la
autenticación, el Contexto de Cliente vuelve al estado IDLE;
- estado SOLICITUD DE CAPACIDAD: en este estado
el Servidor OTA solicita al Cliente OTA su capacidad; el Servidor
OTA entra en este estado cuando se completa la autenticación; el
Servidor OTA inicia un temporizador T301; el temporizador T301 se
para en caso de cambio de estado; sí el temporizador T301 expira
antes de un cambio de estado o la capacidad no permite la descarga,
el Contexto de Cliente vuelve al estado IDLE;
- estado DOWNLOAD ACCEPTANCE: en este estado el
Servidor OTA comunica al Cliente OTA el perfil de descarga; el
Servidor OTA entra en este estado cuando recibe la capacidad del
terminal y dicha capacidad es aceptada; el Servidor OTA inicia un
temporizador T302; el temporizador T302 se para en caso de cambio de
estado; sí el temporizador T302 expira antes de un cambio de estado
o el Cliente OTA rechaza la descarga propuesta, el Contexto de
Cliente vuelve al estado IDLE;
- estado SOFTWARE DOWNLOAD: en este estado el
Servidor OTA realiza la descarga del programa hacia el Cliente OTA;
el Servidor OTA entra en este estado sí el perfil de descarga es
aceptado por el Cliente OTA; el Cliente inicia un temporizador
T401; el temporizador T401 es puesto a cero y se reinicia en cada
señal de reconocimiento Ack recibida por el Cliente; el
temporizador T401 se para en caso de cambio de estado; sí el
temporizador T401 expira antes de un cambio de estado o la descarga
falla, el Contexto de Cliente vuelve al estado IDLE;
- estado INSTALLATION: en este estado el
Servidor OTA comunica al Cliente OTA los términos de la licencia y
espera hasta que el Cliente realiza la instalación y las
comprobaciones de los programas descargados; el Servidor OTA entra
en este estado cuando finaliza la descarga; el Servidor OTA inicia
un temporizador T501; el temporizador T501 se para en caso de
cambio de estado; sí el temporizador T501 expira antes de un cambio
de estado o la licencia no ha sido aceptada por el Cliente OTA, el
Cliente OTA vuelve al estado IDLE; sí el Servidor OTA recibe una
señal de reconocimiento referente a la instalación exitosa por el
Cliente OTA, vuelve al estado IDLE.
\vskip1.000000\baselineskip
La estructura de los mensajes de protocolo
intercambiados entre el Servidor OTA y el Cliente OTA se
describirán a continuación en detalle con referencia a las figuras
4a-4k.
Los términos empleados para denominar los
mensajes y los campos relacionados son puramente indicativos,
auqnue es significativa la definición correspondiente tal como se
describe.
Con referencia a la figura 4a, se describe la
estructura del mensaje Solicitar Inicio de Descarga. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Con este
mensaje el terminal solicita el Servidor empezar una sesión de
descarga. En general, cada sesión de descarga es controlada por el
Servidor OTA.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Solicitar Inicio de Descarga);
- OTA-Client_ID:
identifica al Cliente OTA que realiza la solicitud.
\vskip1.000000\baselineskip
Con referencia a la figura 4b, se describe la
estructura del mensaje Solicitud de Descarga. Este mensaje
es enviado desde el Servidor OTA al Cliente OTA. Mediante este
mensaje el Servidor ordena al Cliente empezar una sesión de
descarga. Los campos suministrados en este caso son al menos un
conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Solicitud de Descarga);
- OTA-Client_ID:
identifica al Cliente OTA hacia el que se hace la solicitud;
- Available_Download(s): comprende
la lista de las posibles descargas; cada elemento contiene una
cadena de descripción y un identificador numérico; el número de
elementos presentes en la lista es variable.
\vskip1.000000\baselineskip
Con referencia a la figura 4c, se describe la
estructura del mensaje Reconocimiento de Descarga. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente OTA comunica al Servidor OTA el
consentimiento para empezar una sesión de descarga.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Reconocimiento de Descarga);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje;
\newpage
- Selected_Download(s): comprende
la lista de las descargas seleccionadas por el usuario; cada
elemento contiene una cadena de descripción y un identificador
numérico; el número de elementos presentes en la lista es
variable;
-
OTA-Client_Challenge_Number: es un número
aleatorio que el Servidor OTA encriptará con su propia llave y un
algoritmo de encriptada adecuado, por ejemplo un algoritmo AES
(Advanced Encryption Standard), para realizar la primera
etapa de la autenticación mutua.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Rechazo de Descarga. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente OTA comunica al Servidor OTA que no puede
empezar una sesión de descarga.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Rechazo de Descarga);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
Con referencia a la figura 4d, se describe la
estructura de la solicitud de autenticación mensaje. Este mensaje
es enviado desde el Servidor OTA al Cliente OTA. Mediante este
mensaje el Servidor OTA comunica sus credenciales al Cliente OTA y
solicita que el Cliente OTA se identifique.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Solicitud de Autenticación);
- OTA-Client_ID:
identifica al Cliente OTA al que se envía el mensaje;
-
OTA-Server_Response_Number: es un número
encriptado por el Servidor OTA con su propia llave y un algoritmo
de encriptado adecuado, como por ejemplo AES, que concluye la
primera etapa de la autenticación mutua;
-
OTA-Server_Challenge_Number: es un número
aleatorio que el Cliente encriptará con su propia llave y un
algoritmo de encriptado adecuado, como por ejemplo AES, para
realizar la segunda etapa de la autenticación mutua.
\vskip1.000000\baselineskip
Con referencia a la figura 4e, se describe la
estructura del mensaje Respuesta de Autenticación. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente comunica sus credenciales al Servidor OTA,
que ya ha autenticado el Servidor.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Respuesta de Autenticación);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje;
-
OTA-Client_Response_Number: identifica un
número encriptado por el Cliente OTA con su propia llave y un
algoritmo de encriptado adecuado, como por ejemplo AES, que concluye
la segunda y última etapa de la autenticación mutua.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Fallo de Autenticación.
Este mensaje es enviado desde el Servidor OTA al Cliente OTA.
Mediante este mensaje el Servidor OTA/Cliente OTA comunica al
Cliente OTA/Servidor OTA que el Servidor OTA no ha autenticado el
Cliente OTA o vice versa.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Fallo de Autenticación);
- OTA-Client_ID:
identifica al Cliente OTA que envía/ recibe el mensaje.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Solicitud de Capacidad. Este
mensaje es enviado desde el Servidor OTA al Cliente OTA. Mediante
este mensaje el Cliente OTA solicita al Servidor OTA sus opciones
de reconfigurabilidad.
\newpage
\global\parskip0.900000\baselineskip
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Solicitud de Capacidad);
- OTA-Client_ID:
identifica al Cliente OTA al que se ha enviado el mensaje.
\vskip1.000000\baselineskip
Con referencia a la figura 4f, se describe la
estructura del mensaje Respuesta de Capacidad. Este mensaje
es enviado desde el Cliente OTA al Servidor OTA. Mediante este
mensaje el Cliente OTA informa al Servidor OTA acerca de sus
opciones de reconfigurabilidad.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Respuesta de Capacidad);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje;
- OTA-Client_Capability:
describe las opciones de reconfigurabilidad del terminal.
\vskip1.000000\baselineskip
Con referencia a la figura 4g, se describe la
estructura del mensaje Descripción de Descarga. Este mensaje
es enviado desde el Servidor OTA al Cliente OTA. Mediante este
mensaje el Servidor OTA informa al Cliente OTA sobre los datos
relativos a la descarga.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Descripción de descarga);
- OTA-Client_ID:
identifica al Cliente OTA al que se ha enviado el mensaje;
- Downloads_list: comprende un elemento
para cada descarga seleccionada por el Cliente, que comprende a su
vez los siguientes campos:
- Download_Block_Number: es el número de
bloques radio en que se segmentará el programa operativo antes de
ser transmitido al Cliente;
- Billing_criteria: son los criterios
referentes a las posibilidades de facturación de la descarga;
- Installation_criteria: son los
criterios referentes a la instalación de programas. De nuevo con
referencia a la figura 4a, se describe la estructura del mensaje
Aceptar Descarga. Este mensaje es enviado desde el Cliente
OTA al Servidor OTA. Mediante este mensaje el Cliente OTA confirma
la(s) descarga(s) seleccionadas.
\vskip1.000000\baselineskip
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Aceptar Descarga);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Rechazo de Descarga. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente OTA renuncia a las descarga(s)
seleccionada(s).
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Rechazo de Descarga);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Fallo de Descarga. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente OTA informa al Servidor OTA de que hay un
fallo en el proceso de descarga de programas.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Fallo de Descarga);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Solicitud de Licencia.
Este mensaje es enviado desde el Cliente OTA al Servidor OTA.
Mediante este mensaje el Cliente solicita al Servidor la clave para
desencriptar los programas de explotación descargados y para
instalarlos.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Solicitud de Licencia);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
Con referencia a la figura 4h, se describe la
estructura del mensaje Respuesta de Licencia. Este mensaje
es enviado desde el Servidor OTA al Cliente OTA. Mediante este
mensaje el Servidor OTA comunica al Cliente OTA la clave para
desencriptar los programas de explotación descargados y para
instalarlos.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Respuesta de Licencia);
- OTA-Client_ID:
identifica al Cliente OTA al que se ha enviado el mensaje;
- Decrypt_key: es la clave empleada para
desencriptar el programa operativo.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Aceptar Licencia. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente OTA indica al Servidor OTA que los
programas de explotación descargados han sido desencriptados
correctamente.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Aceptar Licencia);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Fallo de Licencia. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente OTA informa al Servidor OTA de que los
programas de explotación descargados no se han desencriptado
correctamente.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Fallo de Licencia);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
Con referencia a la figura 4i, se describe la
estructura del mensaje Descripción de Comprobaciones. Este
mensaje es enviado desde el Servidor OTA al Cliente OTA. Mediante
este mensaje el Servidor OTA indica al Cliente OTA las
comprobaciones a llevar a cabo en los programas de explotación
descargados antes de iniciarlos.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Descripción de Comprobaciones);
- OTA-Client_ID:
identifica al Cliente OTA al que se ha enviado el mensaje;
- Test_list: comprende un elemento para
cada comprobación a realizar y comprende a su vez el campo:
- Test_vector: comprende la Descripción
de Comprobaciones.
\vskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Instalación Exitosa. Este
mensaje es enviado desde el Cliente OTA al Servidor OTA. Mediante
este mensaje el Cliente OTA indica al Servidor OTA que la
comprobación de los programas de explotación descargados ha sido
exitosa.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Instalación Exitosa);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\global\parskip1.000000\baselineskip
De nuevo con referencia a la figura 4a, se
describe la estructura del mensaje Fallo de Instalación.
Este mensaje es enviado desde el Cliente OTA al Servidor OTA.
Mediante este mensaje el Cliente OTA informa al Servidor OTA de que
la comprobación de los programas de explotación descargados no ha
sido exitosa.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Fallo de Instalación);
- OTA-Client_ID:
identifica al Cliente OTA que envía el mensaje.
\vskip1.000000\baselineskip
El protocolo de ventana empleado para transmitir
el programa operativo desde el Servidor al Cliente se basa en dos
Unidades de Datos de Protocolos, o PDUs, llamados Block y
Ack.
Con referencia a la figura 4j, se describe la
estructura de un bloque radio Bloque en que se ha segmentado
el programa operativo.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
bloque;
- Block_Number: identifica el número
secuencial del bloque radio, empleándose dicho número secuencial
cuando el Cliente OTA reensambla todo el programa operativo;
- Data: Están contenidos en el bloque
radio, y estos datos tienen típicamente un tamaño de unos
1-2 kBytes.
\vskip1.000000\baselineskip
Con referencia a la figura 4k, se describe la
estructura del mensaje Ack utilizado para indicar el estado
de recepción del terminal.
Los campos suministrados en este caso son al
menos un conjunto de los siguientes:
- Message_Type: identifica el tipo de
mensaje enviado (Ack);
- Bitmask_Client: es una máscara de bit
que tiene un tamaño igual al número total de bloques radio en que
se ha segmentado el programa operativo; para cada bloque radio block
se pone a "1" sí el bloque ha sido recibido con éxito y
permanece en "0" sí el bloque ha sido recibido pero se ha
corrompido o no se ha recibido.
\vskip1.000000\baselineskip
En resumen, según el ejemplo, el comportamiento
funcional del Cliente OTA y el Servidor OTA es el siguiente:
- se inicia el proceso de descarga, por ejemplo,
por el Servidor OTA: el Cliente OTA puede solicitar la activación
del proceso de descarga;
- se realiza la autenticación mutua entre
Cliente y Servidor, por ejemplo, según el procedimiento
"desafío-respuesta";
- el programa operativo a descargar, por
ejemplo, es segmentado en bloques de tamaño reducido, por ejemplo
en el rango de 1 a 2 kBytes;
- la transferencia del programa operativo es
gestionada, por ejemplo, por un protocolo de ventana simple en el
que el tamaño de ventana coincide con el número de bloques en que se
ha segmentado el programa operativo;
- los programas de explotación descargados se
pueden encriptar y, por ejemplo, puede ser necesaria una clave para
su desencriptado e instalación;
- antes de empezar el programa operativo, el
Cliente puede comprobarlo con comprobaciones adecuadas sugeridas
por el Servidor.
\vskip1.000000\baselineskip
Ahora, con referencia a las figuras
5a-5j, se describirán las interacciones de proceso
entre el Cliente OTA y el Servidor OTA indicando para cada mensaje
de protocolo recibido el comportamiento relativo según el estado en
que se encuentren el Cliente OTA o el Contexto de Cliente. Las
Figuras 5a-5j muestran un ejemplo de todas las
interacciones de proceso posibles.
Para facilitar la comprensión, se recuerda que
los temporizadores se inician/paran cuando el Cliente OTA o el
Contexto de Cliente pasa de uno a otro estado, tal como se describió
más arriba.
Con referencia a la figura 5a, cuando no se
lleva a cabo operación alguna, el Cliente OTA y el Contexto de
Cliente relativo al Cliente OTA considerado y gestionado por el
Servidor OTA están en el estado IDLE (etapa 100).
Cuando el usuario, o la red, decide realizar la
descarga de un nuevo programa operativo (etapa 102), se abre una
conexión radio (etapa 104) y se inicia el temporizador T100. La
conexión radio se ilustrará con más detalles más adelante con
referencia a la figura 6.
En esta etapa, el Cliente OTA puede empezar el
proceso de descarga de programas enviando el mensaje de protocolo
Solicitar Inicio de Descarga al Servidor OTA (etapa 106),
estando indicado en el mensaje el identificador que identifica al
Cliente OTA. Por regla general, sí el identificador del Cliente OTA
no se corresponde con el identificador del cliente OTA que recibe
el mensaje de protocolo, se ignora el mensaje.
Entonces el Servidor OTA recibe el mensaje
Solicitar Inicio de Descarga (etapa 108): sí el estado del
Contexto de Cliente no es IDLE (etapa 110), se ignora el mensaje y
se para el proceso (etapa 112); sí no, el Contexto de Cliente pasa
del estado IDLE al estado DOWNLOAD INITIATION (etapa 114), inicia el
temporizador T101, y envía al Cliente el mensaje de protocolo
Solicitud de Descarga indicando las distintas descargas
posibles (etapa 116). El Cliente OTA recibe el mensaje Solicitud
de Descarga (etapa 118): sí el estado del cliente OTA es IDLE
(etapa 120), el Cliente OTA pasa del estado IDLE al estado DOWNLOAD
INITIATION (etapa 124); sí no, se ignora el mensaje y se para el
proceso (etapa 122).
Con referencia ahora a la figura 5b, se le
propone entonces al usuario la selección de las descargas
disponibles indicadas en el mensaje Solicitud de Descarga
(etapa 126). Sí el usuario selecciona al menos una descarga (etapa
128), el Cliente OTA extrae un número aleatorio RNUM1 y lo almacena
(etapa 142), y envía al Servidor OTA el mensaje Reconocimiento
de Descarga que contiene en el campo
OTA-Client_Challenge_Number el valor del número
extraído RNUM1 (etapa 144).
Sí el usuario no selecciona descarga alguna
(etapa 128), el Cliente OTA envía al Contexto de Cliente el mensaje
Rechazo de Descarga (etapa 130) y vuelve al estado IDLE (etapa 132).
Entonces el Servidor OTA recibe el mensaje Rechazo de Descarga
(etapa 134). Sí el estado del Contexto de Cliente no es DOWNLOAD
INITIATION (etapa 136), entonces se ignora el mensaje y se para el
proceso (etapa 138); sí no, el Contexto de Cliente vuelve al estado
IDLE (etapa 140).
Cuando el Servidor OTA recibe el mensaje
Reconocimiento de Descarga (etapa 146): sí el estado del
Contexto de Cliente no es DOWNLOAD INITIATION (etapa 148), se ignora
el mensaje y se para el proceso (etapa 150); sí no el Contexto de
Cliente para el temporizador T101 y pasa del estado DOWNLOAD
INITIATION al estado MUTUAL AUTENTICACIÓN (etapa 152), e inicia el
temporizador T201.
Entonces un número aleatorio RNUM2 es extraído
por el Servidor OTA y almacenado (etapa 154). El valor del campo
OTA-Client_Challenge_Number es encriptado con la
clave interna del Servidor OTA utilizando el algoritmo de
encriptado seleccionado, como por ejemplo AES (etapa 156).
El Servidor OTA envía al Cliente OTA el mensaje
de protocolo Solicitud de Autenticación con el valor
encriptado en la etapa 156 escrito en el campo
OTA-Server_Response_Number y con
el valor del número extraído RNUM2 en el campo Servidor OTA
Challenge_Number (etapa 158).
Entonces, con referencia a la figura 5c, el
Cliente OTA recibe el mensaje solicitud de autenticación (etapa
160) y para el temporizador T100: sí el Cliente OTA no está en el
estado DOWNLOAD INITIATION (etapa 162), se ignora el mensaje y se
para el proceso (etapa 164); sí no, el Cliente OTA pasa del estado
DOWNLOAD INITIATION al estado MUTUAL AUTENTICACIÓN (etapa 166) e
inicia el temporizador T200.
Sí el número aleatorio almacenado RNUM1 no es
válido (etapa 168), el mensaje Fallo de Autenticación es
enviado por el Cliente OTA al Contexto de Cliente (etapa 170) y el
Cliente OTA pasa del estado MUTUAL AUTENTICACIÓN al estado IDLE
(etapa 172) y se para el temporizador T200. Entonces el Contexto de
Cliente recibe el mensaje Fallo de Autenticación (etapa 174)
y para el temporizador T201; sí el Contexto de Cliente está en el
estado MUTUAL AUTENTICACIÓN (etapa 176), el Contexto de Cliente
pasa del estado MUTUAL AUTENTICACIÓN al estado IDLE (etapa 180); sí
no, se para el proceso (etapa 178).
Sí el valor almacenado RNUM1 es válido (etapa
168), el valor del número aleatorio almacenado RNUM1 es encriptado
con la clave interna del Cliente OTA utilizando el algoritmo de
encriptado seleccionado, como por ejemplo AES (etapa 182). Sí el
valor encriptado en la etapa 182 no coincide con el valor contenido
en el campo Response_Number del Servidor OTA (etapa 184), el
proceso vuelve a la etapa 170 y se llevan cabo las etapas 170 a
180, ya descritas.
Sí el valor encriptado en la etapa 182 coincide
con el valor contenido en el campo Response_Number del
Servidor OTA (etapa 184), el valor del campo Challenge_Number
del Servidor OTA es encriptado con la clave interna del Cliente OTA
utilizando el algoritmo de encriptado seleccionado, como por ejemplo
AES (etapa 186). Entonces el mensaje Respuesta de Autenticación que
contiene el valor encriptado en la etapa 186 en el campo
Response_Number del Cliente OTA es enviado (etapa 188) por el
Cliente OTA al Contexto de Cliente.
Entonces el Servidor OTA recibe el mensaje
Respuesta de Autenticación (etapa 190): con referencia a la figura
5d, sí el estado del Contexto de Cliente no es MUTUAL AUTENTICACIÓN
(etapa 192), se ignora el mensaje y se para el proceso (etapa 194);
sí no, el valor del número aleatorio almacenado RNUM2 es encriptado
con la llave interna del Servidor OTA utilizando el algoritmo de
encriptado seleccionado, como por ejemplo AES (etapa 196).
Sí el valor encriptado en la etapa 196 no
coincide con el valor del campo Response_Number del Cliente OTA
(etapa 198), el mensaje Fallo de Autenticación es enviado por
el Contexto de Cliente al Cliente OTA (etapa 200) y el Contexto de
Cliente pasa del estado MUTUAL AUTENTICACIÓN al estado IDLE (etapa
202). Entonces el Cliente OTA recibe el mensaje Fallo de
Autenticación (etapa 204): sí el Cliente OTA está en el estado
MUTUAL AUTENTICACIÓN (etapa 206), el Cliente OTA pasa del estado
MUTUAL AUTENTICACIÓN al estado IDLE (etapa 210); sí no, se para el
proceso (etapa 208).
Sí el valor encriptado en la etapa 196 coincide
con el valor del campo Response_Number del Cliente OTA
(etapa 198), el Contexto de Cliente para el temporizador T201, pasa
del estado MUTUAL AUTENTICACIÓN al estado SOLICITUD DE CAPACIDAD
(etapa 212) y activa el temporizador T301. Entonces el mensaje de
protocolo Solicitud de Capacidad es enviado por el Contexto
de Cliente al Cliente OTA (etapa 214) y es recibido por el Cliente
OTA (etapa 216) que para el temporizador T200: sí el estado del
cliente OTA no es MUTUAL AUTENTICACIÓN (etapa 218), se ignora el
mensaje y se para el proceso (etapa 220); sí no, el Cliente OTA pasa
del estado MUTUAL AUTENTICACIÓN al estado SOLICITUD DE CAPACIDAD
(etapa 222) e inicia el temporizador T300. Entonces el Cliente OTA
envía al Contexto de Cliente el mensaje Respuesta de
Capacidad (etapa 224) y el Contexto de Cliente lo recibe (etapa
226).
Con referencia a la figura 5e, sí el estado del
Contexto de Cliente no es SOLICITUD DE CAPACIDAD (etapa 228), se
ignora el mensaje y se para el proceso (etapa 230); sí no, sí la
capacidad contenida en el mensaje no es compatible con el programa
a descargar (etapa 232), el Contexto de Cliente pasa del estado
RESPUESTA DE CAPACIDAD al estado IDLE (etapa 234) y el temporizador
T301 se para. Sí la capacidad es compatible con el programa a
descargar (etapa 232), el temporizador T301 se para, el Contexto de
Cliente pasa del estado SOLICITUD DE CAPACIDAD al estado DOWNLOAD
ACCEPTANCE (etapa 236) e inicia el temporizador T302 y envía al
Cliente OTA el mensaje Descripción de Descarga (etapa 238).
Entonces el Cliente OTA recibe el mensaje Descripción de Descarga
(etapa 240) y para el temporizador T300: sí el Cliente OTA no está
en el estado SOLICITUD DE CAPACIDAD (etapa 242), se ignora el
mensaje y se para el proceso (etapa 244); sí no, el Cliente OTA pasa
del estado SOLICITUD DE CAPACIDAD al estado DOWNLOAD ACCEPTANCE
(etapa 246). Las opciones de descarga como la facturación, la
instalación y demás son propuestas al usuario (etapa 248). Con
referencia a la figura 5f, sí el usuario rechaza la descarga (etapa
250), el Cliente OTA envía el mensaje Rechazo de Descarga al
Contexto-Cliente (etapa 252) y pasa del estado
DOWNLOAD ACCEPTANCE al estado IDLE (etapa 254). Además, el Contexto
de Cliente recibe el mensaje Rechazo de Descarga (etapa 256);
sí el estado del Contexto de Cliente no es DOWNLOAD ACCEPTANCE
(etapa 258), se ignora el mensaje y se para el proceso (etapa 260);
sí no, el Contexto de Cliente pasa del estado DOWNLOAD ACCEPTANCE
al estado IDLE (etapa 262).
Sí el usuario acepta la descarga (etapa 250),
entonces el Cliente OTA envía al Contexto de Cliente el mensaje
Aceptar Descarga (etapa 264) y el Cliente OTA pasa del estado
DOWNLOAD ACCEPTANCE al estado SOFTWARE DOWNLOAD (etapa 266).
Entonces el Contexto de Cliente recibe el
mensaje Aceptar Descarga (etapa 268) y para el temporizador
T302: sí el estado del Contexto de Cliente no es DOWNLOAD ACCEPTANCE
(etapa 270), se ignora el mensaje y se para el proceso (etapa 272);
sí no, el Contexto de Cliente pasa del estado DOWNLOAD ACCEPTANCE al
estado SOFTWARE DOWNLOAD (etapa 274), e inicia el temporizador
T400, y comienza la descarga de programa (etapa 276).
Sí la descarga de programas no es exitosa (etapa
278), entonces el Cliente OTA/Contexto de Cliente envía al Contexto
de Cliente/Cliente OTA el mensaje Fallo de Descarga (etapa
280) y el Cliente OTA/Contexto de Cliente pasa del estado DOWNLOAD
SOFTWARE al estado IDLE (etapa 282). La descarga de programas (etapa
276) se explicará con más detalle más adelante.
Sí la descarga es exitosa (etapa 278), entonces
el Cliente OTA pasa del estado SOFTWARE DOWNLOAD al estado
instalación (etapa 284). con referencia a la figura 5g, el Cliente
OTA envía al Contexto de Cliente el mensaje Solicitud de
Licencia (etapa 286) y el Servidor OTA lo recibe (etapa 288). Sí
el estado del Contexto de Cliente no es SOFTWARE DOWN LOAD (etapa
290), entonces se ignora el mensaje y se para el proceso (etapa
292); sí no, el proceso de Contexto de Cliente pasa del estado
SOFTWARE DOWNLOAD al estado instalación (etapa 294), e inicia el
temporizador T500, y envía al Cliente OTA el mensaje Respuesta de
Licencia que contiene a la clave para desencriptar el programa
operativo (etapa 296).
El Cliente OTA recibe el mensaje Respuesta de
Licencia (etapa 298): sí el Cliente OTA no está en el estado
instalación (etapa 300), se ignora el mensaje y se para el proceso
(etapa 302); sí no, el Cliente OTA desencripta los programas
descargados utilizando la clave indicada en el campo Llave de
desencriptación (etapa 304). Con referencia a la figura 5h, sí el
desencriptado no tiene éxito (etapa 306), el Cliente OTA envía el
mensaje Fallo de Licencia al Contexto de Cliente (etapa 308),
para el temporizador T500, y pasa del estado instalación al estado
IDLE (etapa 310). Además, el Contexto de Cliente recibe el mensaje
Fallo de Licencia (etapa 312): sí el Contexto de Cliente no
está en el estado SOFTWARE DOWNLOAD (etapa 314), se para el proceso
(etapa 316); sí no el Contexto-Cliente pasa del
estado instalación al estado IDLE (etapa 318).
Sí el desencriptado no tiene éxito (etapa 306),
los programas de explotación descargados son almacenados en el
Cliente o terminal (etapa 320).
El Cliente OTA envía el mensaje Aceptar
Licencia al Contexto de Cliente (etapa 322) y el Servidor OTA
lo recibe (etapa 324): sí el estado del
Contexto-Cliente no es INSTALACIÓN (etapa 326), se
ignora el mensaje y se para el proceso (etapa 328); sí no, el
Contexto de Cliente envía el mensaje de protocolo Descripción de
Comprobaciones al Cliente OTA (etapa 330) y el Cliente OTA lo
recibe (etapa 332). Sí el Cliente OTA no está en el estado
INSTALACIÓN (etapa 334), se ignora el mensaje y se para el proceso
(etapa 336); sí no, el Cliente OTA para el temporizador T500 y pasa
del estado instalación al estado IN-SITU TESTING
(etapa 338) donde las comprobaciones recibidas son realizadas en el
programa operativo previamente almacenado (etapa 340).
Con referencia a la figura 5i, sí al menos una
comprobación no tiene éxito (etapa 342), entonces el Cliente OTA
borra el programa operativo de la memoria (etapa 344), envía el
mensaje Fallo de Instalación (etapa 346) al Contexto de
Cliente, y pasa del estado IN-SITU TESTING al estado
IDLE (etapa 348). Además, el Contexto de Cliente recibe el mensaje
Fallo de Instalación (etapa 350): sí el estado del Contexto
de Cliente no es INSTALACIÓN (etapa 352), se ignora el mensaje y se
para el proceso (etapa 354): sí no, el
Contexto-Cliente pasa del estado instalación al
estado IDLE (etapa 356). sí todas las comprobaciones realizadas
sobre el programa operativo son exitosas (etapa 342), entonces el
nuevo programa operativo es instalado e iniciado en el Cliente OTA
(etapa 358). El Cliente OTA envía el mensaje Insta- lación
Exitosa al Contexto de Cliente (etapa 360) y pasa del estado
IN-SITU TESTING al estado IDLE (etapa 362).
El Servidor OTA recibe el mensaje Instalación
Exitosa (etapa 364): sí el estado del
Contexto-Cliente no es INSTALACIÓN (etapa 366), se
ignora el mensaje y se para el proceso (etapa 368); sí no, el
Contexto de Cliente pasa del estado instalación al estado IDLE
(etapa 370), completando así todo el proceso (etapa 372).
Con referencia a la figura 5j, se describirán a
continuación con mayor detalle, el proceso de descarga de la etapa
276. El programa operativo es encriptado con una clave de encriptado
y mediante un algoritmo de encriptado, como por ejemplo AES (etapa
400). Entonces el encriptado del programa operativo es segmentado
en bloques de tamaño reducido de aproximadamente 1 a 2 kBytes (etapa
402).
Se asignan una máscara de bit
Bitmask_Server y una máscara de bit Bitmask_Client
igual al número de bloques radio en que se ha segmentado el
programa y para cada bit de máscara se pone el valor "0"; cada
máscara de bit corresponde al bloque radio cuyo número es igual a la
posición bit, es decir el primer bit corresponde al primer bloque
radio, el segundo bit al segundo bloque radio y así sucesivamente
(etapa 404 y etapa 408).
En la etapa 406 se actualiza el
Bitmask_Server según el contenido del Bitmask_Client.
Más especialmente, sí un bit de Bitmask_Client se ha puesto
a 1, entonces también se pone a uno el bit correspondiente de
Bitmask_Server (etapa 406). Al ejecutar el proceso de
descarga por primera vez, esta etapa no tiene significado puesto
que todos los bits de Bitmask_Client y de
Bitmask_Server se ponen a 0.
En la etapa 412, se verifica si todos los bits
de la máscara de bit Bitmask_Server son iguales a 1. En caso
positivo, la descarga del programa operativo ha finalizado y todos
los bloques han sido recibidos correctamente (etapa 410); sí no,
aún no ha finalizado la descarga y el Servidor OTA envía al Cliente
OTA todos los bloques i para los cuales Bitmask_Server (i) =
0 (etapa 414). Obviamente, al ejecutar el proceso por primera vez,
todos los N bloques en que se ha segmentado el programa operativo
son enviados al Cliente.
Entonces el Cliente OTA recibe N bloques (etapa
416); para cada bloque recibido se reinicia el temporizador T400.
Cada vez que se recibe correctamente un bloque (etapa 418), entonces
el bit correspondiente de la máscara de bit Bitmask_Client
(i) se pone a 1. Cuando todos los N bloques han sido enviados, el
Cliente OTA envía al Servidor OTA un mensaje Ack que
contiene a la máscara de bit Bitmask_Client en el que el bit
i correspondiente a un bloque recibido correctamente es puesto a 1.
Cuando se recibe un mensaje Ack, se reinicia el temporizador
T401.
Entonces el proceso vuelve a la etapa 406 donde
se actualiza la máscara de bit Bitmask_Server.
Cuando los programas de explotación se han
descargado y almacenado en el terminal, en lugar de instalarlo y
ejecutarlo inmediatamente, es posible instalarlo y ejecutarlo
sucesivamente según una solicitud proveniente de la red o del
usuario. Sí el terminal de radio UE/MS tiene suficiente memoria y
capacidad de procesamiento, los programas de explotación
descargados pueden ser almacenados e instalados concurrentemente con
el sistema de funcionamiento ya existente. Esta opción es útil para
permitir un funcionamiento multimodal del terminal UE/MS, en otras
palabras esta opción permite que el terminal sea capaz de pasar de
un modo operativo a otro sin necesidad de descargar el programa
operativo.
Con referencia a la figura 6, se describirá a
continuación con más detalle la apertura de la conexión radio
realizada en la etapa 104.
En el terminal se consideran los siguientes
módulos: la aplicación Cliente OTA, el protocolo TCP/IP, el módulo
Non Access Stratum NAS y el módulo Access Stratum AS. Los
dispositivos de acceso de radio GSM/ GPRS (GERAN) y UMTS (UTRAN) se
consideran en su totalidad. El mismo razonamiento se aplica a los
nodos de la red central. El nodo Servidor OTA está conectado a la
red central. El funcionamiento detallado en caso de una
Solicitud de Descarga proveniente del terminal UE/MS se
describe a continuación:
- el Cliente OTA solicita el protocolo TCP/IP
para abrir una conexión en un puerto X;
- el TCP/IP, antes de establecer la conexión,
necesita un canal de radio y por lo tanto envía una solicitud
correspondiente a los protocolos NAS del terminal;
- los protocolos NAS del terminal solicitan al
módulo AS del terminal la apertura de una conexión radio;
- los protocolos AS del terminal abren la
conexión radio con la red de acceso de radio GSM/GPRS (GERAN) o
UMTS (UTRAN) y confirman la apertura al nivel NAS;
- el módulo NAS activa el contexto PDP;
- en el caso del sistema UMTS, la red central
activa el Soporte de Acceso Radio RAB (Siglas de Radio Access
Bearer) para el transporte;
- el módulo NAS confirma la apertura del canal
de transporte al TCP/IP;
- el protocolo TCP/IP abre la conexión y
confirma la apertura al Cliente OTA.
\vskip1.000000\baselineskip
En general, la gestión de la descarga de
programas mediante una capa de aplicación también puede ser llevada
a cabo con un procedimiento alternativo en el que el sistema radio
es empleado para difusión y multidifusión.
En particular, esta variante se puede
implementar, por ejemplo, de la manera siguiente:
- el terminal UE/MS está provisto de una
aplicación capaz de gestionar la descarga de los programas de
explotación OTA explotando Capacidades de difusión/ multidifusión,
por ejemplo, el servicio MBMS (siglas de Multimedia
Broadcast/Multicast Service) como se especifica en la versión 6
del Estándar 3GPP; en este caso, utilizando las Capacidades de
difusión/ multidifusión de la red, es posible descargar el programa
operativo a una pluralidad de terminales;
- la capa de aplicación capa lleva a cabo la
autenticación según el Estándar 3GPP;
- desde el punto de vista de la red de acceso y
de la red central, el servicio de descarga de programas es
transparente y se considera como cualquier otro servicio MBMS, por
ejemplo con la identificación "Descarga de Programa";
- Es posible explotar todas las características
de la red considerada, como por ejemplo Calidad de Servicio (QoS,
Quality of Service) para garantizar una determinada
fiabilidad de descarga;
- la arquitectura es independiente de la red de
acceso considerada (GERAN/UTRAN);
- los usuarios que desean realizar la descarga
pueden ellos mismos registrase en el Servidor;
- la descarga ocurre simultáneamente hacia todos
los usuarios registrados.
\vskip1.000000\baselineskip
Otra variante de la invención consiste en
descargar el programa OTA utilizando un canal universal. También en
este caso es posible aplicar la invención para llevar a cabo la
descarga del programa operativo sin modificar intrusivamente la
arquitectura de red que gestiona a dicho canal universal. Como
alternativa, la descarga ocurre a través de un canal de radio de la
red de comunicación.
La invención se ha descrito en detalle para
sistemas de segunda y tercera generación. Sin embargo, se puede
implementar en cualquier otro tipo de redes, por ejemplo una Red
Local Inalámbrica (WLAN, Wireless Local Area Network), DVB,
etc.
De hecho, la solución propuesta según la
presente invención proporciona un servidor OTA externo al sistema
empleado y, por lo tanto, es tal que no modifica el sistema
empleado.
Además, según una realización preferida de la
presente invención, se proporciona emplear el protocolo TCP/IP, el
cual, como sabe un experto en la materia, es de uso extendido en
muchas redes y sistemas.
Según otras realizaciones de la presente
invención, también es posible utilizar un protocolo de transporte
diferente del TCP/IP, como por ejemplo el UDP (User Datagram
Protocol), sin afectar a la arquitectura de la presente
invención.
\vskip1.000000\baselineskip
Esta lista de referencias citadas por el
solicitante está prevista únicamente para ayudar al lector y no
forma parte del documento de patente europea. Aunque se ha puesto
el máximo cuidado en su realización, no se pueden excluir errores u
omisiones y la OEP declina cualquier responsabilidad en este
respecto.
\bullet JP 2001061186 B [0017]
\bullet US 20030163551 A [0018]
\bullet J. Mitola. The Software Radio
Architecture. IEEE Communications Magazine, May 1995
[0003]
\bullet E. Buracchini. The Software
Radio Concept. IEEE Communications Magazine, September 2000
[0003] [0016]
Claims (30)
1. Arquitectura de red que comprende una red de
comunicación que es operativa según un sistema de comunicación
predeterminado y que comprende al menos un terminal de radio (UE/MS)
que pertenece a dicha red de comunicación y que comprende módulos
para gestionar un intercambio de información en el interior de dicha
red de comunicación utilizando dicho sistema de comunicación
predeterminado, - estando dicha arquitectura caracterizada
por - al menos un nodo (Servidor OTA), conectado a dicha red de
comunicación y que comprende - un conjunto de módulos de programa
operativo configurados para implementar al menos un conjunto de
elementos de una pila de protocolos para configurar dicho terminal
de radio (UE/MS), y por el hecho de que - dicho terminal de radio y
dicho nodo están provistos de módulos de programa hertzianos
respectivo configurados para gestionar una conexión hertziana entre
dicho terminal de radio (UE/MS) y dicho nodo (Servidor OTA) a través
de dicha red de comunicación y para descargar de manera
transparente en dicha red de comunicación al menos un módulo de
dicho conjunto de módulos de programa operativo para configurar al
menos en parte a dicho terminal de radio (UE/MS).
2. Arquitectura según la reivindicación 1, en la
que dicha red de comunicación comprende una red de acceso de radio
y una red central y en la que dicho nodo está conectado a dicha red
central.
3. Arquitectura según la reivindicación 2 en la
que dicha red de acceso de radio opera según un sistema de
comunicación de red de segunda generación (GERAN).
4. Arquitectura según la reivindicación 2, en la
que dicha red de acceso de radio opera según un sistema de
comunicación de red de tercera generación (UTRAN).
5. Arquitectura según la reivindicación 2, en la
que dicha red central comprende un dominio paquetes.
6. Arquitectura según la reivindicación 5, en la
que dicho dominio paquetes comprende al menos un nodo de tipo de
soporte de servicio GPRS (SGSN) y al menos un nodo de soporte de
tipo pasarela GPRS (GGSN) y en la que dicho no-
do (Servidor OTA) está directamente conectado a dicho al menos un nodo de soporte de tipo pasarela GPRS (GGSN).
do (Servidor OTA) está directamente conectado a dicho al menos un nodo de soporte de tipo pasarela GPRS (GGSN).
7. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que dicha conexión hertziana se
establece a través de un canal universal de dicha red de
comunicación.
8. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que dicha conexión hertziana se
establece a través de un canal de radio de dicha red de
comunicación.
9. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que dicho terminal de radio
está provisto de una memoria capaz de almacenar al menos dos
programas de explotación y por el hecho de que dicho terminal de
radio comprende módulos de funcionamiento multimodo para conmutar
entre dichos al menos dos programas de explotación.
10. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que dicho terminal de radio
está configurado como un cliente (Cliente OTA) y dicho nodo
(Servidor OTA) está configurado como un servidor.
11. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que dicha información comprende
al menos dichos módulos de programa operativo.
12. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que - dicha red de comunicación
está provista de Capacidades de difusión/ multidifusión, - dicho al
menos un terminal de radio está provisto de una aplicación capaz de
gestionar dichas Capacidades de difusión/ multidifusión, mediante
las cuales dicha red de comunicación está configurada para permitir
una descarga en multidifusión de dicho al menos un módulo de dicho
conjunto a dicho al menos un terminal de radio.
13. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que para establecer dicha
conexión hertziana entre dicho al menos un terminal de radio y
dicho nodo, se emplea el protocolo TCP/IP.
14. Arquitectura según la reivindicación 1,
caracterizada por el hecho de que dicho conjunto de módulos
de programa operativo es apto para reconfigurar al menos en parte
dicho terminal de radio (MS) con otro sistema de comunicación.
15. Procedimiento para configurar al menos un
terminal de radio reconfigurable (UE/MS) que pertenece a una red de
comunicación que es operativa según un sistema de comunicación
predeterminado y capaz de intercambiar información en el interior
de dicha red de comunicación utilizando dicho sistema de
comunicación predeterminado, caracterizado por las etapas
consistentes en:
- conectar a dicha red de comunicación al menos
un nodo (Servidor OTA) que comprende un conjunto de módulos de
programa operativo para configurar dicho terminal de radio (UE/MS)
con al menos un conjunto de elementos de una pila de
protocolos;
- establecer una conexión hertziana (OTA) entre
dicho terminal de radio (UE/MS) y dicho nodo (Servidor OTA) a
través de dicha red de comunicación;
- descargar de manera transparente a dicha red
de comunicación al menos un módulo de dicho conjunto de módulos de
programa operativo desde dicho nodo (Servidor OTA) a dicho terminal
de radio reconfigurable (UE/MS) para configurar al menos en parte
dicho terminal de radio (UE/MS).
\vskip1.000000\baselineskip
16. Procedimiento según la reivindicación 15,
caracterizado por el hecho de que dicho establecimiento de
una conexión hertziana (OTA) comprende intercambiar mensajes de
protocolo llevando a cabo al menos un conjunto de las etapas
siguientes:
- realizar una solicitud para descargar dicho al
menos un módulo;
- autentificar mutuamente dicho al menos un
terminal de radio (UE/MS) y dicho nodo (Servidor OTA);
- verificar la capacidad de dicho terminal de
radio para aceptar dicho al menos un módulo descargable desde dicho
nodo;
- suministrar una información referente a las
opciones de descarga;
- segmentar dicho al menos un módulo en
bloques;
- transmitir dichos bloques desde dicho nodo
(Servidor OTA) a dicho al menos un terminal de radio (UE/MS);
- reensamblar dichos bloques para reconstituir
dicho al menos un módulo para configurar dicho terminal de radio
(UE/MS) con un conjunto de elementos de una pila de protocolos y
verificar dicho conjunto de elementos;
- instalar dicho conjunto de elementos en dicho
terminal de radio.
\vskip1.000000\baselineskip
17. Procedimiento según la reivindicación 16,
caracterizado por el hecho de que dicho intercambio de
mensajes de protocolo también comprende la etapa consistente
en:
- monitorizar la estructura de dichos bloques
descargados a dicho terminal de radio (UE/MS).
\vskip1.000000\baselineskip
18. Procedimiento según la reivindicación 16,
caracterizado por el hecho de que dicho intercambio de
mensajes de protocolo también comprende la etapa consistente en -
gestionar un conjunto de temporizadores (T100, T200, T300, T400,
T500, T101, T201, T301, T302, T401, T501) que limitan el tiempo
permitido para llevar a cabo una conexión hertziana (OTA).
19. Procedimiento según la reivindicación 16,
caracterizado por el hecho de que dicho intercambio de
mensajes de protocolo también comprende la etapa consistente en -
asignar para cada etapa de protocolo al menos un par de
temporizadores, un primer temporizador para monitorizar las etapas
de protocolo realizadas por dicho terminal de radio (UE/MS) y un
segundo temporizador para monitorizar las etapas de protocolo
realizadas por dicho nodo (Servidor OTA), iniciándose cada uno de
dichos temporizadores cuando se inicia una etapa de protocolo y
finalizando cuando se ha realizado se ha realizado dicha etapa de
protocolo.
20. Procedimiento según la reivindicación 16,
caracterizado por el hecho de que dicha etapa de
autenticación mutua se basa en un procedimiento de
"desafío-respuesta".
21. Procedimiento según la reivindicación 16,
caracterizado por el hecho de que dicha etapa de segmentación
de dicho al menos un módulo de programa operativo en bloques
comprende la etapa de segmentación en bloques que tienen un tamaño
de 1 a 2 kBytes y por el hecho de que la etapa de transmitir dichos
bloques comprende gestionar un protocolo de ventana en el que un
tamaño de ventana corresponde al tamaño de los bloques en los
cuales se ha segmentado el al menos un módulo de programa
operativo.
22. Procedimiento según la reivindicación 16,
caracterizado por el hecho de que antes de instalar dicho
conjunto de elementos en dicho terminal de radio, se requiere una
licencia.
23. Procedimiento según la reivindicación 15,
caracterizado por el hecho de que dicho al menos un módulo de
programa operativo, antes de ser descargado en dicho terminal de
radio, se encripta con una clave.
24. Procedimiento según la reivindicación 15,
caracterizado por el hecho de que para establecer dicha
conexión hertziana entre dicho al menos un terminal de radio
(UE/MS) y dicho nodo (Servidor OTA), se emplea el protocolo
TCP/IP.
25. Procedimiento según la reivindicación 15,
caracterizado por comprender la etapa adicional de almacenar
al menos dos programas de explotación en dicho terminal de radio
reconfigurable (UE/MS).
26. Procedimiento según la reivindicación 15,
caracterizado por el hecho de que dicha etapa de descargar
dicho al menos un módulo de dicho conjunto comprende la etapa de -
descargar un conjunto de módulos de programa operativo apto para
reconfigurar al menos en parte dicho terminal de radio (MS) con otro
sistema de comunicación.
27. Procedimiento según la reivindicación 15,
caracterizado por el hecho de que dicha etapa de descargar
dicho al menos un módulo de dicho conjunto comprende la etapa de -
instalar y ejecutar dicho al menos un módulo de dicho conjunto
según una solicitud proveniente desde dicho terminal de radio
(UE/MS) o de dicha red de comunicación.
28. Terminal de radio (UE/MS) que comprende
medios para llevar a cabo el procedimiento reivindicado en las
reivindicaciones 15 a 27.
29. Nodo de red (Servidor OTA) para configurar
una terminal de radio configurable (UE/MS) llevando a cabo el
procedimiento reivindicado en las reivindicaciones 15 a 27.
30. Producto de programa de ordenador o conjunto
de programas de ordenador que pueden ser descargados en la memoria
de la menos un ordenador y que comprende partes de código de
programa para llevar a cabo las etapas según cualquiera de las
reivindicaciones 15 a 27.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2004/012168 WO2006045335A1 (en) | 2004-10-28 | 2004-10-28 | A method and a network architecture for configuring a radio terminal, radio terminal, network node and a computer program product therefor |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2331999T3 true ES2331999T3 (es) | 2010-01-22 |
Family
ID=34959021
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04790941T Active ES2331999T3 (es) | 2004-10-28 | 2004-10-28 | Procedimiento y arquitectura de red para configurar un terminal de radio, un terminal de radio, un nodo de red y un producto de programa de ordenador para el mismo. |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US8081596B1 (es) |
| EP (1) | EP1806016B1 (es) |
| JP (1) | JP4668276B2 (es) |
| KR (1) | KR101131520B1 (es) |
| CN (1) | CN101077023B (es) |
| AT (1) | ATE439747T1 (es) |
| BR (1) | BRPI0419170A (es) |
| DE (1) | DE602004022599D1 (es) |
| ES (1) | ES2331999T3 (es) |
| WO (1) | WO2006045335A1 (es) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| BRPI0419170A (pt) | 2004-10-28 | 2008-03-11 | Telecom Italia Spa | arquitetura de rede, método para configurar pelo menos um terminal de rádio reconfigurável, terminal de rádio configurável, nó de rede e produto de programa de computação |
| US9031550B2 (en) | 2004-10-28 | 2015-05-12 | Telecom Italia S.P.A. | Method for configuring a radio terminal through a radio communication network, related network and computer program product therefor |
| KR101213285B1 (ko) * | 2006-01-04 | 2012-12-17 | 삼성전자주식회사 | 이동통신 시스템에서 아이들모드 단말기의 세션 설정 프로토콜 데이터를 전송하는 방법 및 장치 |
| CN100550766C (zh) * | 2006-01-24 | 2009-10-14 | 华为技术有限公司 | 预定任务执行方法和管理任务执行方法、及其终端设备 |
| US8437751B2 (en) | 2006-04-25 | 2013-05-07 | Core Wireless Licensing S.A.R.L. | Method, apparatus and computer program product for providing confirmed over-the-air terminal configuration |
| DE102006024634B4 (de) * | 2006-05-26 | 2012-08-23 | Audi Ag | Aktivierung der Empfangsbereitschaft eines Fahrzeugnetzwerks |
| JP2008035272A (ja) * | 2006-07-28 | 2008-02-14 | Canon Inc | 情報処理システム及び当該システムにおけるデータ通信方法 |
| US8776037B2 (en) * | 2007-01-04 | 2014-07-08 | International Business Machines Corporation | Apparatus and method to update multiple devices disposed in a computing system |
| KR100840904B1 (ko) * | 2007-06-22 | 2008-06-24 | 주식회사 케이티프리텔 | Ｏｔａ 서비스를 제공하기 위한 시스템 및 그 방법 |
| KR20080112914A (ko) * | 2007-06-22 | 2008-12-26 | 삼성전자주식회사 | 이벤트 메시지 수신 방법, 이벤트 메시지 전송 방법,피제어 장치 및 제어 포인트 |
| US8649783B2 (en) * | 2010-09-22 | 2014-02-11 | Nuance Communications, Inc. | No-cost mobile device messaging, such as for provisioning an application on a mobile device |
| CN102123146A (zh) * | 2011-03-02 | 2011-07-13 | 成都四方信息技术有限公司 | 移动支付交易密钥远程下载工作方法 |
| JP5632315B2 (ja) * | 2011-03-17 | 2014-11-26 | 株式会社オプティム | 端末のリモート操作システム、リモート操作方法 |
| CN102307362B (zh) * | 2011-09-06 | 2015-06-17 | 北京傲天动联技术股份有限公司 | 用于实现功能配置的终端设备和控制设备及其网络系统 |
| JP6001843B2 (ja) * | 2011-11-15 | 2016-10-05 | 任天堂株式会社 | 情報処理装置、情報処理システム、情報処理方法およびプログラム |
| US8873466B2 (en) | 2012-10-12 | 2014-10-28 | Freescale Semiconductor, Inc. | Timing event generation circuit for mobile communication device |
| WO2016195640A1 (en) * | 2015-05-29 | 2016-12-08 | Nokia Technologies Oy | Support of flexible radio protocol in 5g radio access network |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0852448A1 (en) | 1997-01-02 | 1998-07-08 | Nokia Mobile Phones Ltd. | User terminal for mobile communications |
| US6208627B1 (en) | 1997-12-10 | 2001-03-27 | Xircom, Inc. | Signaling and protocol for communication system with wireless trunk |
| US6463055B1 (en) | 1998-06-01 | 2002-10-08 | Telefonaktiebolaget L M Ericsson (Publ) | Integrated radio telecommunications network and method of interworking an ANSI-41 network and the general packet radio service (GPRS) |
| US6577614B1 (en) | 1999-05-27 | 2003-06-10 | Qwest Communications International Inc. | System and method for OTA over CDMA data channel |
| JP3669619B2 (ja) * | 1999-09-06 | 2005-07-13 | 富士通株式会社 | 無線端末装置のソフトウェア更新方法及びその装置 |
| FI109320B (fi) | 1999-11-02 | 2002-06-28 | Nokia Corp | Signalointimenetelmä |
| JP4011808B2 (ja) * | 1999-12-24 | 2007-11-21 | 株式会社東芝 | 移動通信システムとその管理装置及び移動局装置 |
| US20020012329A1 (en) | 2000-06-02 | 2002-01-31 | Timothy Atkinson | Communications apparatus interface and method for discovery of remote devices |
| US7035932B1 (en) | 2000-10-27 | 2006-04-25 | Eric Morgan Dowling | Federated multiprotocol communication |
| GB0028463D0 (en) | 2000-11-22 | 2001-01-10 | Univ Surrey | Reconfiguration management architectures |
| US6799203B2 (en) | 2000-12-29 | 2004-09-28 | Nokia Mobile Phones Ltd. | WTA based over the air management (OTAM) method and apparatus |
| GB0101205D0 (en) * | 2001-01-17 | 2001-02-28 | Koninkl Philips Electronics Nv | Telecommunications system and a method of operating the system |
| GB0103903D0 (en) * | 2001-02-16 | 2001-04-04 | Radioscape Ltd | An open digital interface between sdr baseband processors and rf |
| EP1257141B1 (en) * | 2001-05-10 | 2007-01-03 | Nortel Networks Limited | System and method for communication redirection between mobile telecommunication networks with different radio access technologies |
| US7215648B2 (en) | 2001-05-11 | 2007-05-08 | Varitek Industries, Inc. | Apparatus and method for efficient live webcasting and network connectivity |
| JP3645510B2 (ja) * | 2001-09-26 | 2005-05-11 | 株式会社東芝 | 無線基地局、無線端末及び通信制御方法 |
| US20030084165A1 (en) * | 2001-10-12 | 2003-05-01 | Openwave Systems Inc. | User-centric session management for client-server interaction using multiple applications and devices |
| WO2003039175A1 (de) * | 2001-10-16 | 2003-05-08 | Siemens Aktiengesellschaft | Rekonfigurationsverfahren für mobile kommunikationsgeräte |
| US7054628B2 (en) * | 2001-12-07 | 2006-05-30 | Qualcomm Incorporated | Apparatus and method of using a ciphering key in a hybrid communications network |
| US7743115B2 (en) | 2002-02-27 | 2010-06-22 | Motorola, Inc. | Software content downloading methods in radio communication networks |
| JP2003304235A (ja) | 2002-04-10 | 2003-10-24 | Sony Corp | 無線通信装置、およびプログラム・ダウンロード方法、並びにコンピュータ・プログラム |
| US20040098715A1 (en) | 2002-08-30 | 2004-05-20 | Parixit Aghera | Over the air mobile device software management |
| EP1401224A1 (en) * | 2002-09-17 | 2004-03-24 | Motorola, Inc. | Software download to software definable radio by intermediate communication unit |
| US20040120281A1 (en) * | 2002-12-24 | 2004-06-24 | Gazzard Daryl R. | Remote node access in wireless telecommunication systems |
| CN1275480C (zh) * | 2003-07-31 | 2006-09-13 | 上海贝尔阿尔卡特股份有限公司 | 一种多标准软件无线电(sdr)基带处理方法 |
| US20050033829A1 (en) | 2003-08-04 | 2005-02-10 | Nokia Corporation | System and method for wireless multicast downloading |
| US8201191B2 (en) * | 2004-06-30 | 2012-06-12 | Time Warner Cable Inc. | Apparatus and methods for implementation of network software interfaces |
| US9031550B2 (en) | 2004-10-28 | 2015-05-12 | Telecom Italia S.P.A. | Method for configuring a radio terminal through a radio communication network, related network and computer program product therefor |
| BRPI0419170A (pt) | 2004-10-28 | 2008-03-11 | Telecom Italia Spa | arquitetura de rede, método para configurar pelo menos um terminal de rádio reconfigurável, terminal de rádio configurável, nó de rede e produto de programa de computação |
-
2004
- 2004-10-28 BR BRPI0419170-6A patent/BRPI0419170A/pt not_active Application Discontinuation
- 2004-10-28 US US11/666,439 patent/US8081596B1/en active Active
- 2004-10-28 JP JP2007538273A patent/JP4668276B2/ja active Active
- 2004-10-28 CN CN2004800445796A patent/CN101077023B/zh active Active
- 2004-10-28 EP EP04790941A patent/EP1806016B1/en active Active
- 2004-10-28 ES ES04790941T patent/ES2331999T3/es active Active
- 2004-10-28 WO PCT/EP2004/012168 patent/WO2006045335A1/en active Application Filing
- 2004-10-28 DE DE602004022599T patent/DE602004022599D1/de active Active
- 2004-10-28 AT AT04790941T patent/ATE439747T1/de not_active IP Right Cessation
- 2004-10-28 KR KR1020077011989A patent/KR101131520B1/ko active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006045335A1 (en) | 2006-05-04 |
| ATE439747T1 (de) | 2009-08-15 |
| KR101131520B1 (ko) | 2012-04-04 |
| US8081596B1 (en) | 2011-12-20 |
| JP4668276B2 (ja) | 2011-04-13 |
| DE602004022599D1 (de) | 2009-09-24 |
| EP1806016B1 (en) | 2009-08-12 |
| BRPI0419170A (pt) | 2008-03-11 |
| KR20070074643A (ko) | 2007-07-12 |
| CN101077023B (zh) | 2012-01-11 |
| EP1806016A1 (en) | 2007-07-11 |
| JP2008518529A (ja) | 2008-05-29 |
| CN101077023A (zh) | 2007-11-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2353877T3 (es) | Procedimiento para configurar un terminal de radio mediante una red de comunicación por radio, red asociada y programa informático a este efecto. | |
| ES2331999T3 (es) | Procedimiento y arquitectura de red para configurar un terminal de radio, un terminal de radio, un nodo de red y un producto de programa de ordenador para el mismo. | |
| Lee et al. | Internet of things security-multilayered method for end to end data communications over cellular networks | |
| US10064047B2 (en) | Method and apparatus for profile download of group devices | |
| ES2647088T3 (es) | Procedimientos y dispositivos para la gestión de suscripciones OTA | |
| FI108769B (fi) | Liityntäpisteen liittäminen langattomassa tietoliikennejärjestelmässä | |
| KR100693201B1 (ko) | 무선 통신 단말기를 동작시키는 방법, 무선 통신 시스템, 및 무선 통신 단말기 | |
| US10277587B2 (en) | Instantiation of multiple electronic subscriber identity module (eSIM) instances | |
| JP7423744B2 (ja) | 指定ペイロードコンテナタイプを使用する通信システムにおける制御プレーン経由のユーザデータ伝送 | |
| KR20220030319A (ko) | Nas 메시지의 보안 보호를 위한 시스템 및 방법 | |
| MX2008013772A (es) | Metodo y sistema para proporcionar comunicaciones seguras asistidas por celular de una pluralidad de dispositivos ad hoc. | |
| BRPI0407821B1 (pt) | Wlan signal connection solution | |
| JP2022511606A (ja) | ユーザ機器に供給された構成パラメータのセキュアな更新のためのシステム及び方法 | |
| ES2392968T3 (es) | Procedimiento y sistema de datos para conectar una red local inalámbrica a una estación terminal UMTS | |
| US8422428B1 (en) | Device management for a wireless communication device having and invalid user identifier | |
| WO2022253083A1 (zh) | 一种公私网业务的隔离方法、装置及系统 | |
| MXPA05001738A (es) | Disposiciones de definiciones operativas en un sistema de comunicacion inalambrico. | |
| ES2288667T3 (es) | Sistema y metodo para gestionar el registro seguro de un dispositivo movil de comunicaciones. | |
| JP5420604B2 (ja) | 無線通信ネットワークと関連ネットワークおよびそのコンピュータ・プログラム生成物を介して無線端末を設定する方法 | |
| WO2024114742A1 (zh) | 通信方法及装置 | |
| EP4156574A1 (en) | Ip-based ue aggregation | |
| Gultchev et al. | Provisioning of reconfiguration services between different access networks |