ES2353877T3

ES2353877T3 - Procedimiento para configurar un terminal de radio mediante una red de comunicación por radio, red asociada y programa informático a este efecto.

Info

Publication number: ES2353877T3
Application number: ES04790938T
Authority: ES
Inventors: Enrico TELECOM ITALIA S.p.A. BURACCHINI; Paolo Telecom Italia S.p.A. GORIA; Alessandro Telecom Italia S.p.A. TROGOLO
Original assignee: Telecom Italia SpA
Current assignee: Telecom Italia SpA
Priority date: 2004-10-28
Filing date: 2004-10-28
Publication date: 2011-03-07
Anticipated expiration: 2024-10-28
Also published as: CN101077024A; ATE483334T1; US9031550B2; BRPI0419171A; KR101111141B1; EP1806015A1; EP1806015B1; JP2008518528A; US20090067367A1; CN101077024B; KR20070074637A; WO2006045334A1; DE602004029403D1; BRPI0419171A8

Abstract

Una red de comunicación operativa de acuerdo con un sistema de comunicación, incluyendo dicha red de comunicación una capa de protocolos de recursos de radio, que incluye primeros mensajes de una pila de protocolos correspondiente al sistema de comunicación y que presenta - por lo menos un terminal de radio reconfigurable, configurado para gestionar el intercambio de información dentro de dicha red de comunicación utilizando dicho sistema de comunicación, - por lo menos un nodo de dicha red de comunicación, configurado para gestionar el intercambio de información con dicho por lo menos un terminal de radio reconfigurable mediante una conexión over-theair inalámbrica, utilizándose dichos primeros mensajes para gestionar dicha conexión over-the-air inalámbrica, presentando dicho por lo menos un nodo una entidad servidor configurada para usar dicha capa de protocolos de recursos de radio de dicha red de comunicación y presentando un conjunto de módulos de software operativo configurados para implementar por lo menos un conjunto de elementos de dicha pila de protocolos, estando adaptado dicho conjunto de elementos para configurar dicho por lo menos un terminal de radio reconfigurable; y - dicho por lo menos un terminal de radio reconfigurable, presentando una entidad cliente, configurada para usar una respectiva capa de protocolos de recursos de radio correspondiente a dicha capa de protocolos de dicha entidad servidor, y - dichas entidades servidor y cliente, dotadas de respectivos módulos de software over-the-air, capaces de gestionar un proceso de descarga over-the-air entre dicho por lo menos un terminal de radio reconfigurable y dicho por lo menos un nodo, utilizando dicha capa de protocolos de recursos de radio para descargar por lo menos un módulo de dicho conjunto de módulos de software operativo para configurar por lo menos en parte dicho por lo menos un terminal de radio reconfigurable, caracterizado porque, - dicha entidad servidor y dicha entidad cliente incluyen, respectivamente, por lo menos un conjunto de segundos mensajes de dicha capa de protocolos de recursos de radio, y porque - dicho conjunto de segundos mensajes asociados respectivamente a dicha entidad servidor y a dicha entidad cliente está configurado para gestionar dicho proceso de descarga over-the- air.

Description

Campo de la invención

La presente invención se refiere en general a redes de comunicación por radio y a terminales de radio 5 reconfigurables usando una red de comunicación por radio.

Más en particular, la presente invención hace referencia a la reconfiguración de un terminal de radio, realizándose la reconfiguración instalando en el terminal de radio un software operativo descargado over-the-air (OTA) desde la red de comunicación por radio.

Antecedentes de la invención 10

De la bibliografía (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) se sabe que los sistemas reconfigurables, como terminales, estaciones base y nodos de red, son equipamientos cuyo modo de funcionamiento operativo puede reconfigurarse. Por ejemplo, un terminal de radio reconfigurable capaz de funcionar con un sistema de segunda generación (2G), como 15 GSM/GPRS (Global System for Mobile Communication/General Packet Radio Service), puede reconfigurarse para poder funcionar con un sistema de tercera generación (3G), como los sistemas UMTS (Universal Mobile Telecommunication System) o CDMA 2000 (Code Division Multiple Access 2000), con DVB-T (Digital Video Broadcasting Terrestrial) o con WLAN (Wireless Local Area Network) y así sucesivamente. Según la presente invención, el término "sistema" se entiende como una pluralidad 20 de elementos coordinados entre sí según criterios predeterminados, es decir, coordinados según un "estándar", para llevar a cabo una función específica, 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 y así sucesivamente, cumpliendo cada uno de ellos un estándar 25 correspondiente.

Para llevar a cabo la reconfiguración de un terminal, según la bibliografía mencionada anteriormente, es necesario que las funciones operativas del terminal se realicen con una tecnología que sea reconfigurable. A este respecto, los terminales o dispositivos reconfigurables están dotados de un hardware reprogramable constituido, por ejemplo, por una pluralidad de FPGAs (Field Programmable 30 Gate Arrays), DSPs (Digital Signal Processors) y microprocesadores: las distintas funcionalidades del dispositivo, incluso al nivel más bajo, son realizadas por un código de software. Como consecuencia, para reconfigurar un dispositivo reprogramable, basta con sustituir el software operativo que gestiona el hardware del propio dispositivo.

Por el término "software operativo" debe entenderse, en la presente descripción, el software, organizado 35 en librerías, que define tanto la interfaz de radio (p. ej. L1, L2, L3) como las capas superiores (p. ej. L4 hasta 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 40 agrupadas en planos funcionales representados en forma de pila.

Cada capa de la pila de protocolos proporciona servicios a la capa inmediatamente superior, siendo los servicios a su vez mejoras de los servicios proporcionados por la capa inmediatamente inferior.

La capa más baja (capa 1) por lo general tiene el propósito de transmitir físicamente la información.

De acuerdo con la especificación OSI, el número estándar de capas es 7: respectivamente las capas 45 física, conexión, red, transporte, sesión, presentación y aplicación. Cada sistema, p. ej. GSM/GPRS, UMTS, etc., implementa la parte necesaria de la pila de protocolos OSI. Si consideramos un terminal de radio, los beneficios proporcionados al usar un hardware reconfigurable son muchos, pero un beneficio es evidentemente inmediato: el terminal de radio puede reconfigurarse según el sistema que cubre el área en la que se encuentra el terminal (área de funcionamiento). Por lo tanto, si el terminal se usa en un 50 área cubierta por un sistema de segunda generación, como GSM/GPRS, el terminal puede

reconfigurarse para poder recibir dicho sistema; del mismo modo, en un área cubierta por un sistema de tercera generación, como UMTS, el terminal puede configurarse consecuentemente.

De la bibliografía (AA.W. "Software Radio: The Challenges for Reconfigurable Terminals", Annals of telecommunications - jul/ago 2002, GET Hermes y E. Buracchini "The Software Radio Concept") se sabe que un código de software puede transferirse o descargarse a un terminal por lo menos de tres formas 5 diferentes:

- mediante una smart card (tarjeta inteligente) utilizando un SIM (Subscriber Identity Module) que hay que insertar dentro del terminal móvil de radio;

- mediante una conexión externa utilizando por ejemplo un enlace con un ordenador personal mediante un puerto de infrarrojos/de serie/USB (Universal Serial Bus); 10

- mediante radio o over-the-air (OTA) utilizando un canal de radio específico.

En relación con la descarga de software, los pasos fundamentales de un protocolo genérico que permite gestionar la descarga de un software a un terminal se han definido en el marco del Software Defined Radio Forum (foro SDR), que puede consultarse en la URL www.sdrforum.org.

El protocolo definido por el SDRF es del tipo cliente-servidor, conocido en sí mismo. Los pasos del 15 protocolo de descarga son los siguientes:

- inicio de la descarga: paso durante el cual el terminal comunica al servidor, en el que reside un software que se desea descargar, la intención de comenzar una descarga de software;

- autenticación mutua; el terminal y el servidor deben autentificarse entre sí;

- intercambio de capacidad: el servidor comunica la información sobre capacidad relativa al software que 20 hay que descargar, y el terminal verifica si el software puede cargarse en la memoria del terminal, instalarse en la misma y funcionar;

- aceptación de la descarga: el servidor comunica al terminal las opciones de descarga, instalación y facturación; el terminal decide si las indicaciones proporcionadas por el servidor son aceptables o no;

- comprobación de descarga e integridad: durante la descarga de software, debe probarse el código 25 recibido; el terminal solicita que se vuelvan a transmitir los bloques de radio recibidos incorrectamente;

- instalación: durante el paso de instalación, el servidor proporciona las condiciones de facturación y licencia del software,

- comprobaciones in situ: antes de iniciar el software, el terminal lleva a cabo algunas comprobaciones con la ayuda de vectores de comprobación descargados junto con el código de software; 30

- intercambio de no rechazo: una vez instalado y comprobado el código de software, el terminal confirma al servidor que la instalación se ha realizado con éxito para iniciar el proceso de facturación.

Del estado de la técnica anterior, p. ej. E. Buracchini, "The Software Radio Concept", IEEE Communications Magazine, septiembre de 2000, se sabe que la descarga de software mediante radio o OTA prevé que el terminal utilice un canal de radio. Según la bibliografía mencionada anteriormente, se 35 conoce la descarga del código de software de dos modos diferentes, dependiendo de la tipología del canal de radio:

- modo "fuera de banda": por medio de un canal "universal" independiente del sistema actual, cuando el terminal se enciende, se sintoniza automáticamente a ese canal y lleva a cabo la descarga del software operativo relativo al sistema que opera en el área de funcionamiento; 40

- modo "en banda": utilizando los canales de radio de los sistemas celulares estándar de segunda y tercera generación, como GSM/GPRS y UMTS respectivamente, este modo prevé que el terminal, que ya opera en uno de estos canales, puede recibir el software operativo relativo a un sistema diferente del que se está usando en la actualidad; por ejemplo, un terminal reconfigurable que opera con un sistema de segunda generación, como GSM/GPRS, puede llevar a cabo la descarga de un sistema de tercera 45 generación, como UMTS, utilizando el canal de radio de segunda generación según el cual esté funcionando.

Un ejemplo de descarga de software "fuera de banda" se describe por ejemplo en la solicitud de patente japonesa nº 2001061186. Este documento describe un sistema y un procedimiento para descargar

contenido de software over-the-air. Cuando se enciende un terminal de radio, éste busca en un canal universal cuál es el sistema actual en el área de funcionamiento y lleva a cabo la descarga de software relativa al sistema indicado.

Considerando el modo "fuera de banda", según el estado de la técnica anterior, es necesario implementar un canal de radio dedicado y por lo tanto equipos dedicados en la red para su 5 implementación.

Un ejemplo de descarga de software "en banda" se describe por ejemplo en la solicitud de patente estadounidense nº 2003/0163551. Este documento describe un sistema y un procedimiento para descargar software over-the-air utilizando canales dedicados durante los pasos de negociación entre servidor y terminal (intercambio de capacidad, autenticación, facturación, etc.), y utilizando canales 10 comunes compartidos durante el proceso de descarga para proporcionar el servicio de descarga al mayor número de usuarios posible de forma simultánea, sin plantear un inconveniente en los recursos de radio disponibles.

Al considerar el modo de descarga "en banda", los documentos AA.VV., "Architecture Of IP Based Network Elements Supporting Reconfigurable Terminals", SCOUT Workshop, 16 de septiembre de 2003, 15 y IST-2001-34091 SCOUT, D4.1.1 "Requirements on network and security architecture and traffic management schemes for download traffic based on IP principles in cellular and ad hoc networks" sugieren modificar profundamente algunos protocolos y algunos nodos de red, p. ej. los nodos de acceso de radio y/o los nodos de Redes Básicas basados en la edición 5 y siguientes de UMTS, en la que la Red Básica se basa completamente en IP (Internet Protocol) para hacer posible la gestión de la 20 descarga del software operativo.

Dichas modificaciones implican un esfuerzo considerable para los fabricantes de los equipos y para los operadores de red y tienen un impacto dramático en los estándares de los sistemas celulares existentes.

Por lo tanto, las técnicas "en banda" conocidas presentan el límite de que, cuando se desea añadir a una red celular ya existente, como por ejemplo GSM/GPRS o UMTS, la gestión de la descarga de 25 software operativo para terminales reconfigurables, son necesarias grandes modificaciones de los protocolos y de los nodos de red.

El solicitante señala que el estado de la técnica anterior conocido tanto en caso del modo "en banda" como del modo "fuera de banda" prevé una profunda modificación de algunos protocolos y algunos nodos de red. 30

Otro problema del estado anterior de la técnica conocido es la gestión del handover entre sistemas, que según el presente estándar, se define como:

- handover desde un sistema GSM/GPRS a un sistema UMTS;

- handover desde un sistema UMTS a un sistema CDMA 2000;

- handover desde un sistema UMTS a un sistema GSM/GPRS; 35

- handover desde un sistema CDMA 2000 a un sistema UMTS.

Según el estándar conocido, el handover entre sistemas requiere terminales multimodo, es decir, terminales que soporten toda la pila de protocolos de cada sistema celular utilizando tecnología ASIC (Application Specific Integrated Circuit).

Véase, por ejemplo, la figura 1, que muestra un terminal multimodo que presenta una pila de protocolos 40 de radio completa del sistema GSM/GPRS, llamada RAT GSM/GPRS, un pila de protocolos de radio completa del sistema UMTS, llamada RAT UMTS, y una pila de protocolos de radio completa del sistema CDMA 2000, llamada RAT CDMA 2000. La solución conocida posee algunas desventajas, como un alto consumo de energía, el gran tamaño del dispositivo y elevados costes de implementación.

En resumen, el solicitante señala que el estado anterior de la técnica conocido 45

– no resuelve el problema de descargar software sin una gran modificación de los nodos de red, p. ej. la adición de nuevos nodos e interfaces, y modificar los datos señalando y transfiriendo protocolos definidos por el estándar, que podría implicar un uso ineficaz de los recursos de radio; y

– no puede usar terminales reconfigurables para gestionar el handover entre sistemas.

La US 2004/0176129 A1 da a conocer un sistema de comunicación con un tronco inalámbrico para conectar múltiples líneas telefónicas a un teléfono móvil mediante enlaces de comunicación inalámbricos. Un interruptor central de teléfonos o CPE, como un PBX o sistema de teclas, se conecta a una unidad de comunicación de acceso inalámbrico mediante uno o más troncos. La unidad de comunicación inalámbrica proporciona al CPE uno o más canales de comunicación inalámbricos a una 5 red celular. Las llamadas pueden ser enrutadas de forma selectiva por el CPE mediante líneas fijas a una red o, en su lugar, a la unidad de comunicación de acceso inalámbrico, desviando así las líneas fijas. Múltiples unidades de comunicación de acceso inalámbrico en un área geográfica pueden comunicarse con una única estación base de la red celular, siempre y cuando la capacidad de la estación base y la carga de tráfico actual lo permitan. Además, la unidad de comunicación de acceso 10 inalámbrico posee múltiples interfaces de tronco para conectarse a un CPE y un transceptor de radio para establecer uno o más enlaces de comunicación inalámbricos a una red celular. Cada interfaz de tronco está conectada a una tarjeta de línea que consta de un codificador de voz y una interfaz de suscriptor. Un controlador interconecta las tarjetas de línea con el transceptor de radio y ayuda a convertir datos desde un formato adecuado para la transmisión inalámbrica a un formato adecuado para 15 la transmisión mediante el tronco CPE, y viceversa.

La US 6,577,614 B1 da a conocer un sistema que presenta una red de datos, un servidor, y una estación base. El servidor se comunica con la red de datos y está configurado para enviar un parámetro de actualización. La estación base se comunica con la red de datos y está configurada para recibir el parámetro de actualización del servidor. La estación base también está configurada para establecer un 20 canal de datos de acceso múltiple por división de código (CDMA) entre el cliente móvil y la estación base. La estación base también está configurada para enviar el parámetro de actualización al cliente móvil por medio del canal de datos de acuerdo con un estándar de interfaz aérea CDMA y también de acuerdo con un estándar de canal de datos para servicios de datos.

Resumen de la invención 25

Por lo tanto, un objeto de la presente invención es un procedimiento y una red de comunicación para la descarga de un software operativo para configurar un terminal de radio sin una gran modificación de los nodos de red y los protocolos asociados.

Otro objeto de la presente invención es un procedimiento y una red de comunicación para gestionar de forma eficaz un proceso de descarga de software para configurar terminales de radio reconfigurables. 30

Es además objeto de la presente invención un procedimiento y una red de comunicación para permitir procesos de handover entre sistemas utilizando terminales configurables.

Los objetos anteriores se logran gracias al procedimiento y la red de comunicación reivindicados en las reivindicaciones adjuntas al presente.

Además, los objetos de la presente invención se consiguen por medio de un producto de programa 35 informático o un conjunto de productos de programas informáticos, que pueden cargarse en la memoria de por lo menos un ordenador y que incluyen partes de código de software para llevar a cabo los pasos del procedimiento de la invención cuando el producto se ejecuta en un ordenador tal y como se reivindica. Tal y como se usa en la presente, la referencia a dicho producto de programa informático pretende ser equivalente a la referencia a un medio legible por ordenador que contiene instrucciones 40 para controlar un sistema informático con el fin de coordinar el rendimiento del procedimiento de la invención. Con la referencia a "por lo menos un ordenador" se pretende evidentemente destacar la posibilidad de implementar la presente invención de forma modular distribuida.

En una realización preferida, la descarga del software operativo para reconfigurar el terminal de radio se consigue permitiendo modificar, únicamente, una capa de la pila de protocolos de radio en el terminal 45 y en por lo menos un nodo de la red con respecto al estándar, por ejemplo en un controlador de radio como un BSC (Base Station Controller) o un RNC (Radio Network Controller) de la red. Según la invención, el protocolo en la capa modificada es coherente con las recomendaciones proporcionadas por el foro SDR.

Según una realización preferida de la invención, el Servidor desde el que es posible descargar el 50 software operativo reside en el controlador de radio, p. ej. BSC o RNC, de la red.

Según otra realización de la presente invención, segundos mensajes adicionales capaces de gestionar

un proceso de descarga de software over-the-air que se implementa al mismo nivel o capa de protocolo del protocolo de recurso de radio RR se añaden a primeros mensajes capaces de gestionar interfaces de radio existentes, como las interfaces de radio GSM/UMTS estándar, de tal modo que cooperan con las mismas.

Entre las posibles ventajas de la invención se encuentran: 5

- el servicio de descarga de software es transparente, y la red lo considera como cualquier otro flujo de datos de señalización y tráfico;

- se explotan por completo todas las características de los estándares existentes y futuros, permitiendo por lo tanto un uso eficaz y flexible de los recursos de radio;

- es posible, por ejemplo durante una llamada de circuito, establecer una conexión de paquete para 10 descargar el software operativo sin interrumpir la llamada;

- es posible distinguir entre diferentes flujos de datos y gestionar la prioridad de los mismos (p. ej. voz, datos y descarga de software); por ejemplo, si la prioridad de las llamadas de voz es mayor que la prioridad de la descarga de software, es posible interrumpir temporalmente la descarga de dicho software para continuar la descarga posteriormente. 15

Además, la invención prevé el uso de terminales reconfigurables para gestionar el handover entre sistemas.

De hecho, según la realización preferida de la invención, es suficiente que sólo las funcionalidades mínimas para llevar a cabo mediciones en los sistemas soportados se implementen en la capa física del terminal. 20

Por ejemplo, consideremos un terminal configurado para operar con el sistema GSM/GPRS y listo para gestionar el handover entre sistemas al sistema UMTS: según la presente invención, el terminal, configurado con toda la pila de protocolos de la interfaz de radio del sistema GSM/GPRS, posee sólo las funcionalidades mínimas de la capa física para llevar a cabo las mediciones de energía en el sistema UMTS. 25

El handover entre sistemas se gestiona descargando todo el software operativo UMTS en el terminal mediante un canal de radio GSM/GPRS, reconfigurando el terminal según el sistema UMTS y proporcionando las funcionalidades mínimas de la capa física para llevar a cabo las mediciones de energía en el sistema GSM/GPRS.

Breve descripción de los dibujos 30

A continuación, la invención se describe con referencia a los dibujos adjuntos de realizaciones preferidas pero no limitativas de la misma, en los que:

- la figura 1 representa un terminal multimodo según el estado de la técnica anterior;

- la figura 2 ilustra la arquitectura de una red del sistema GSM/GPRS, según una realización de la presente invención; 35

- la figura 3 representa un terminal reconfigurable para la arquitectura de la figura 1;

- la figura 4 es un diagrama de estado de los pasos de protocolo realizados por el cliente en el lado del terminal de radio;

- la figura 5 es un diagrama de estado de los pasos de protocolo realizados por el servidor en el lado del controlador de la estación base; 40

- las figuras 6 a 17 ilustran la estructura de los mensajes de protocolo intercambiados entre el servidor y el cliente;

- la figura 18 ilustra un proceso de handover entre sistemas desde GSM a UMTS para una llamada de circuito;

- la figura 19 ilustra en detalle un proceso de descarga de software para reconfigurar un terminal de 45 radio;

- la figura 20 ilustra el proceso de descarga del software operativo en caso de reselección de células.

Se han usado las mismas referencias en todas las figuras para indicar componentes iguales o que implementan funciones sustancialmente equivalentes.

Descripción detallada de la invención

Con referencia a la figura 2, se muestra la arquitectura de una red del sistema GSM/GPRS que presenta un terminal o estación móvil MS reconfigurable, una estación base transceptora BTS o nodo 5 BTS y un controlador de la estación base BSC o nodo BSC.

La red también presenta, por ejemplo, nodos de red básica, como centros de conmutación móviles (MSC) y/o nodos de soporte GPRS servidor (SGSN) y/o nodos de soporte GPRS pasarela (GGSN), que no aparecen en la figura 2.

El terminal MS está conectado, mediante una interfaz de radio, al nodo BTS, que está conectado al 10 nodo BSC.

Según la realización preferida de la invención, el terminal MS presenta una primera entidad llamada Cliente OTA y una segunda entidad, de tipo conocido, llamada protocolo de recurso de radio RR; el Cliente OTA está al mismo nivel o capa de protocolo y coopera con el protocolo de recurso de radio RR.

La entidad RR funciona, por ejemplo, de acuerdo con el estándar GSM/GPRS ETSI 04.18 y presenta 15 funcionalidades, que se explicarán más adelante, para comunicarse con el Cliente OTA y una entidad RR correspondiente en el controlador de la estación base BSC.

El Cliente OTA presenta un módulo de software capaz de gestionar completamente el proceso de descarga de todo el software operativo o parte del mismo desde una entidad OTA correspondiente en el controlador de la estación base BSC, llamado servidor OTA. 20

El BSC presenta una primera entidad llamada servidor OTA y una segunda entidad, de tipo conocido, llamada protocolo de recurso de radio RR.

El servidor OTA está al mismo nivel de protocolo y coopera con el protocolo de recurso de radio RR.

La entidad RR funciona, por ejemplo, de acuerdo con el estándar GSM/GPRS ETSI 04.18 y presenta funcionalidades, que se explicarán más adelante, para comunicarse con el servidor OTA y la entidad RR 25 correspondiente en el terminal móvil MS.

El servidor OTA presenta un módulo de software capaz de gestionar completamente el proceso de descarga de todo el software operativo o parte del mismo al Cliente OTA.

El servidor OTA también presenta el software operativo o puede recuperarlo. La arquitectura del Servidor OTA proporciona un contexto llamado Contexto de Cliente para cada Cliente OTA que posee 30 una sesión de descarga activa, como se explicará más adelante.

La figura 3 muestra un ejemplo de un terminal MS configurado según la presente invención.

El terminal MS presenta capas superiores e inferiores del protocolo GSM/GPRS. Las capas inferiores se denominan RAT (Radio Access Technology) GSM/GPRS y presentan las entidades OTA cliente, el recurso de radio RR y las capas físicas (L1) y DL (Data Link) (L2) según el estándar GSM/GPRS. 35

El terminal MS también presenta una capa física (L1U) según otro estándar, p. ej. el estándar UMTS, que incluye por lo menos funcionalidades para ejecutar mediciones en la capa 1 conformes al otro estándar.

El terminal MS según se da a conocer puede reconfigurarse descargando el software operativo de otro estándar, como se explicará más adelante. 40

El software operativo, tal y como se considera en la realización preferida de la invención, presenta un conjunto de módulos de software operativo, preferiblemente una pluralidad de módulos de software para configurar el terminal MS según un sistema de comunicación predeterminado.

La invención prevé la descarga de todos los módulos de software operativo que constituyen una pila de protocolos empleados para configurar el terminal de radio MS según, por ejemplo, otro sistema de 45 comunicación predeterminado. Como podrá apreciar un experto en la materia, también es posible, según otras realizaciones de la presente invención, descargar módulos de software que constituyen sólo una parte de la pila de protocolos correspondientes al sistema de comunicación en uso o al otro sistema de comunicación.

Estas otras realizaciones podrían ser útiles con la finalidad, por ejemplo, de insertar nuevas funcionalidades, actualizaciones o reparar defectos en el terminal MS.

Con referencia a la figura 4, se representa el diagrama de estado del Cliente OTA en el terminal MS.

Los términos usados para designar los estados son meramente indicativos, aunque es significativo el comportamiento correspondiente tal como se describe. 5

Según una realización preferida de la presente invención, los estados y las transiciones relativas del Cliente OTA son los siguientes:

- estado INACTIVO: el Cliente OTA se encuentra en este estado cuando no hay activo ningún proceso de descarga de software; el Cliente OTA vuelve a este estado si el proceso termina correctamente o si ocurre un fallo; 10

- estado INICIO DE LA DESCARGA: cuando la red requiere iniciar un proceso de descarga de software operativo, el Cliente OTA entra en este estado y pone en marcha un temporizador T100; el temporizador T100 se detiene en caso de una transición de estado; si el temporizador T100 expira antes de una transición de estado, el Cliente OTA vuelve al estado INACTIVO;

- estado AUTENTICACIÓN MUTUA: en este estado, el Cliente OTA lleva a cabo la autenticación mutua 15 con el Servidor OTA; el Cliente OTA entra en este estado cuando una solicitud de autenticación llega desde el Servidor OTA; el Cliente OTA pone en marcha un temporizador T200; el temporizador T200 se detiene en caso de una transición de estado; si el temporizador T200 expira antes de una transición de estado o la autenticación falla, el Cliente OTA vuelve al estado INACTIVO;

- estado SOLICITUD DE CAPACIDAD: en este estado, el Cliente OTA proporciona su capacidad al 20 Servidor OTA; el Cliente OTA entra en este estado cuando el Servidor OTA solicita su capacidad; el Cliente OTA pone en marcha un temporizador T300; el temporizador T300 se detiene en caso de una transición de estado; si el temporizador T300 expira antes de una transición de estado, el Cliente OTA vuelve al estado INACTIVO;

- estado ACEPTACIÓN DE LA DESCARGA: en este estado, el Cliente OTA determina si continúa la 25 descarga según la información recibida por el Servidor OTA; el Cliente OTA entra en este estado cuando recibe del Servidor OTA el perfil de descarga a llevar a cabo; si el perfil recibido se rechaza, el Cliente OTA vuelve al estado INACTIVO;

- estado DESCARGA DEL SOFTWARE: en este estado, el Cliente OTA lleva a cabo la descarga de software; el Cliente OTA entra en este estado si el perfil de descarga se acepta; el Cliente OTA pone en 30 marcha un temporizador T400; el temporizador T400 se pone a cero y se reinicia en cada bloque de software recibido del Servidor OTA; el temporizador T400 se detiene en caso de una transición de estado; si el temporizador T400 expira antes de una transición de estado o la descarga falla o el software descargado no cumple la capacidad, el Cliente OTA vuelve al estado INACTIVO;

- estado INSTALACIÓN: en este estado, el Cliente OTA envía una solicitud de licencia al Servidor OTA e 35 instala el software operativo; el Cliente OTA entra en este estado al final de la descarga; el Cliente OTA pone en marcha un temporizador T500; el temporizador T500 se detiene en caso de un cambio de estado; si el temporizador T500 expira antes de un cambio de estado o la licencia no se acepta, el Cliente OTA vuelve al estado INACTIVO;

- estado COMPROBACIONES IN SITU: en este estado, el Cliente OTA realiza algunas comprobaciones 40 en el software descargado utilizando algunos vectores de comprobación recibidos por el Servidor OTA; el Cliente OTA entra en este estado cuando el software operativo se ha instalado; una vez finalizadas las comprobaciones, el Cliente OTA vuelve al estado INACTIVO.

Con referencia a la figura 5, se representa el diagrama de estado del Contexto de Cliente gestionado por 45 el Servidor OTA.

Como se ha señalado anteriormente, los términos usados para nombrar los estados son meramente indicativos, aunque es significativo el comportamiento correspondiente tal como se describe. Los estados y las transiciones relativas del Contexto de Cliente son los siguientes:

- estado INACTIVO: el Contexto de Cliente OTA gestionado por el Servidor OTA se encuentra en este 50

estado cuando no hay activo ningún proceso de descarga de software; el Contexto de Cliente OTA vuelve a este estado si un proceso termina correctamente o si ocurre un fallo;

- estado INICIO DE LA DESCARGA: en este estado, el Contexto de Cliente OTA ordena al Cliente OTA a llevar a cabo una descarga; cuando es necesario realizar la descarga del software operativo, el Contexto de Cliente OTA entra en este estado y pone en marcha un temporizador T101; el temporizador 5 T101 se detiene antes de una transición de estado; si el temporizador T101 expira antes de una transición de estado, entonces el Contexto de Cliente OTA vuelve al estado INACTIVO;

- estado AUTENTICACIÓN MUTUA: en este estado, el Contexto de Cliente OTA se autentica a sí mismo y solicita al Cliente OTA que se identifique; el Contexto de Cliente OTA entra en este estado cuando recibe del Cliente OTA la confirmación de la descarga; el Contexto de Cliente OTA pone en marcha un 10 temporizador T201; el temporizador T201 se detiene en caso de una transición de estado; si el temporizador T201 expira antes de una transición de estado o la autenticación falla, el Contexto de Cliente OTA vuelve al estado INACTIVO;

- estado SOLICITUD DE CAPACIDAD: en este estado, el Contexto de Cliente OTA solicita al Cliente OTA su capacidad; el Contexto de Cliente OTA entra en este estado cuando se completa la 15 autenticación; el Contexto de Cliente OTA pone en marcha un temporizador T301; el temporizador T301 se detiene en caso de una transición de estado; si el temporizador T301 expira antes de una transición de estado o la capacidad no permite la descarga, el Contexto de Cliente OTA vuelve al estado INACTIVO;

- estado ACEPTACIÓN DE LA DESCARGA: en este estado, el Contexto de Cliente OTA comunica al 20 Cliente OTA el perfil de descarga; el Contexto de Cliente OTA entra en este estado cuando recibe la capacidad del terminal y se acepta esta capacidad; el Contexto de Cliente OTA pone en marcha un temporizador T302; el temporizador T302 se detiene en caso de una transición de estado; si el temporizador T302 expira antes de una transición de estado o el Cliente OTA rechaza la descarga propuesta, el Contexto de Cliente OTA vuelve al estado INACTIVO; 25

- estado DESCARGA DEL SOFTWARE: en este estado, el Contexto de Cliente OTA lleva a cabo la descarga del software hacia el Cliente OTA; el Contexto de Cliente OTA entra en este estado si el perfil de descarga es aceptado por el Cliente OTA; el Contexto de Cliente OTA pone en marcha un temporizador T401; el temporizador T401 se pone a cero y se reinicia en cada señal de reconocimiento Ack recibida del cliente; el temporizador T401 se detiene en caso de una transición de estado; si el 30 temporizador T401 expira antes de una transición de estado o la descarga falla, el Contexto de Cliente OTA vuelve al estado INACTIVO;

- estado INSTALACIÓN: en este estado, el Contexto de Cliente OTA comunica al Cliente OTA los términos de la licencia y espera hasta que el Cliente OTA lleva a cabo la instalación y las comprobaciones del software descargado; el Contexto de Cliente OTA entra en este estado cuando 35 finaliza la descarga; el Contexto de Cliente OTA pone en marcha un temporizador T501; el temporizador T501 se detiene en caso de una transición de estado; si el temporizador T501 expira antes de una transición de estado o la licencia no ha sido aceptada por el Cliente OTA, el Contexto de Cliente OTA vuelve al estado INACTIVO; si el Contexto de Cliente OTA recibe una señal de reconocimiento referente a la instalación con éxito por parte del Cliente OTA, vuelve al estado INACTIVO. 40

En el caso de GSM/GPRS, en la realización preferida de la invención, el protocolo RR se modifica introduciendo nuevos mensajes de protocolo y campos asociados intercambiados entre el Servidor OTA y el Cliente OTA, que se describirán a continuación en detalle con referencia a las figuras 6-17.

En caso de diferentes sistemas, el protocolo de recurso de radio, por ejemplo el RRC (Radio Resource Control) en el sistema UMTS se modifica de un modo similar, como podría entender un experto en la 45 materia.

A continuación, los términos usados para designar los mensajes y campos asociados son meramente indicativos, aunque es significativa la definición correspondiente tal y como se describe.

Con referencia a la figura 6, se describe la estructura del mensaje Solicitud de descarga de paquete. Este mensaje es enviado desde el recurso de radio RR en el lado del controlador de la estación base 50 BSC al recurso de radio RR en el lado del terminal MS. Con este mensaje, el Servidor OTA ordena al Cliente OTA que comience una sesión de descarga.

Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Solicitud de descarga de paquete);

- ID del Cliente OTA: identifica el Cliente OTA hacia el que se realiza la solicitud;

- PDCH (Packet Data Channel): especifica los canales asignados por la red en los que se llevará a cabo la descarga de software; 5

- RRBP (periodo de bloqueo reservado relativo): especifica el bloque de radio en el que responderá el recurso de radio RR en el lado del terminal MS, como ya se ha definido en el estándar GPRS;

- Descarga solicitada: este elemento contiene una cadena de descripción y un identificador numérico de la descarga solicitada por la red.

Con referencia a la figura 7, se describe la estructura del mensaje Ack descarga de paquete. Este 10 mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA comunica al Servidor OTA la confirmación para comenzar una sesión de descarga.

- Tipo de mensaje: identifica el tipo de mensaje enviado (Ack descarga de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje; 15

- Número de desafío del Cliente OTA, es un número aleatorio que el Servidor OTA encriptará con su propia clave y un algoritmo de codificación adecuado, por ejemplo el algoritmo AES (Advanced Encryption Standard), para llevar a cabo el primer paso de la autenticación mutua.

Con referencia a la figura 8, se describe la estructura del mensaje Nack descarga de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA comunica al 20 Servidor OTA que no puede comenzar una sesión de descarga. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Nack descarga de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje.

Con referencia a la figura 9, se describe la estructura del mensaje Solicitud de autenticación de paquete. 25 Este mensaje se envía desde el Servidor OTA al Cliente OTA. Con este mensaje, el Servidor OTA comunica sus credenciales al Cliente OTA y solicita que el Cliente OTA se identifique. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Solicitud de autenticación de paquete);

- ID del Cliente OTA: identifica el Cliente OTA al que se envía el mensaje; 30

- Número de respuesta del Servidor OTA, es un número encriptado por el Servidor OTA con su propia clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, que concluye el primer paso de la autenticación mutua;

- Número de desafío del Servidor OTA es un número aleatorio que el Cliente OTA encriptará con su propia clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, para llevar a 35 cabo el segundo paso de la autenticación mutua;

- RRBP: especifica el bloque de radio en el que responderá el recurso de radio RR en el lado del terminal MS, como ya se ha definido en el estándar GPRS.

Con referencia a la figura 10, se describe la estructura del mensaje Respuesta de autenticación de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente 40 OTA comunica sus credenciales al Servidor OTA, que ya ha autenticado al Servidor OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Respuesta de autenticación de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje;

- Número de respuesta del Cliente OTA identifica un número encriptado por el Cliente OTA con su propia 45 clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, que concluye el

segundo y último paso de la autenticación mutua.

Con referencia a la figura 11, se describe la estructura del mensaje Solicitud de capacidad de paquete. Este mensaje se envía desde el Servidor OTA al Cliente OTA. Con este mensaje, el Servidor OTA solicita al Cliente OTA sus opciones de reconfigurabilidad. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 5

- Tipo de mensaje: identifica el tipo de mensaje enviado (Solicitud de capacidad de paquete);

- ID del Cliente OTA: identifica el Cliente OTA al que se envía el mensaje;

Con referencia a la figura 12, se describe la estructura del mensaje Respuesta de capacidad de paquete. 10 Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA informa al Servidor OTA sobre sus opciones de reconfigurabilidad. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Respuesta de capacidad de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje; 15

- Capacidad del Cliente OTA: describe las opciones de reconfigurabilidad del terminal.

Con referencia a la figura 13, se describe la estructura del mensaje Descripción de descarga de paquete. Este mensaje se envía desde el Servidor OTA al Cliente OTA. Con este mensaje, el Servidor OTA informa al Cliente OTA sobre los datos relativos a la descarga. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 20

- Tipo de mensaje: identifica el tipo de mensaje enviado (Descripción de descarga de paquete);

- ID del Cliente OTA: identifica el Cliente OTA al que se envía el mensaje;

- Lista de descargas: presenta un elemento para cada descarga seleccionada por el Cliente OTA, incluyendo este campo los siguientes campos:

- Número de bloques de descarga: es el número de bloques de radio en el que se segmentará el 25 software operativo antes de ser transmitido al Cliente OTA;

- Criterios de facturación: son los criterios relativos a la posible facturación de la descarga;

- Criterios de instalación: son los criterios relativos a la instalación del software.

- RRBP: especifica el bloque de radio en el que responderá el recurso de radio RR en el lado del terminal MS, como ya se ha definido en el estándar GPRS. 30

De nuevo con referencia a la figura 8, se describe la estructura del mensaje Aceptar descarga de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA confirma la descarga. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Aceptar descarga de paquete); 35

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje.

De nuevo con referencia a la figura 8, se describe la estructura del mensaje Rechazar descarga de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA rechaza la descarga. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 40

- Tipo de mensaje: identifica el tipo de mensaje enviado (Rechazar descarga de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje.

De nuevo con referencia a la figura 8, se describe la estructura del mensaje Solicitud de licencia de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA solicita al Servidor OTA la clave para desencriptar el software operativo descargado y para 45 instalarlo. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los

siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Solicitud de licencia de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje.

Con referencia a la figura 14, se describe la estructura del mensaje Respuesta de licencia de paquete. Este mensaje se envía desde el Servidor OTA al Cliente OTA. Con este mensaje, el Servidor OTA 5 comunica al Cliente OTA la clave para desencriptar el software operativo descargado y para instalarlo. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Respuesta de licencia de paquete);

- ID del Cliente OTA: identifica el Cliente OTA al que se envía el mensaje;

- Clave de desencriptación: es la clave usada para desencriptar el software operativo. 10

De nuevo con referencia a la figura 8, se describe la estructura del mensaje Aceptar licencia de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA indica al Servidor OTA que el software operativo descargado se ha desencriptado correctamente. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Aceptar licencia de paquete); 15

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje.

De nuevo con referencia a la figura 8, se describe la estructura del mensaje Fallo de licencia de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA informa al Servidor OTA de que el software operativo descargado no se ha desencriptado correctamente. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 20

- Tipo de mensaje: identifica el tipo de mensaje enviado (Fallo de licencia de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje.

Con referencia a la figura 15, se describe la estructura del mensaje Descripción de comprobaciones de paquete. Este mensaje se envía desde el Servidor OTA al Cliente OTA. Con este mensaje, el Servidor OTA indica al Cliente OTA las comprobaciones a realizar en el software operativo descargado antes de 25 iniciarlo. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Descripción de comprobaciones de paquete);

- ID del Cliente OTA: identifica el Cliente OTA al que se envía el mensaje;

- Lista de comprobaciones: presenta un elemento para cada comprobación a realizar e incluye a su vez 30 el campo:

- Vector de comprobación: presenta la descripción de comprobaciones.

De nuevo con referencia a la figura 8, se describe la estructura del mensaje Paquete instalado con éxito. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente OTA indica al Servidor OTA que la comprobación del software operativo descargado ha tenido éxito. Los campos 35 proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Paquete instalado con éxito);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje.

De nuevo con referencia a la figura 8, se describe la estructura del mensaje Fallo de instalación de paquete. Este mensaje se envía desde el Cliente OTA al Servidor OTA. Con este mensaje, el Cliente 40 OTA informa al Servidor OTA de que la comprobación del software operativo descargado no ha tenido éxito. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Fallo de instalación de paquete);

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje. 45

El software operativo es transmitido desde el Servidor OTA al Cliente OTA utilizando, en la realización

preferida, un protocolo de ventana de tipo conocido basado, por ejemplo, en dos Unidades de Datos de Protocolos básicas, o PDUs, llamadas Block y Ack, como se describirá más adelante.

Con referencia a la figura 16, se describe la estructura de un bloque de radio Block en el que se ha segmentado el software operativo. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 5

- Tipo de mensaje: identifica el tipo de bloque;

- Número de bloque identifica el número secuencial del bloque de radio; este número secuencial es usado por el Cliente OTA para reensamblar todo el software operativo;

- Datos: este es el campo que contiene algunas porciones de todo el software operativo.

Con referencia a la figura 17, se describe la estructura del mensaje Ack usado para indicar el estado de 10 recepción del terminal. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Tipo de mensaje: identifica el tipo de mensaje enviado (Ack);

- Mapa de bits Ack: es una máscara de bits con un tamaño igual al número total de bloques de radio en los que se ha segmentado el software operativo; para cada bloque de radio, se pone en "1" si el bloque 15 se ha recibido con éxito, y se pone en "0" si el bloque se ha recibido pero se ha corrompido o si no se ha recibido.

Las modificaciones del protocolo RR previstas por la realización preferida de la invención se basan en la introducción de primitivas entre el Cliente OTA y el recurso de radio RR en el lado del terminal MS y en la introducción de primitivas entre el Servidor OTA y el recurso de radio RR en el lado del controlador de 20 la estación base BSC.

Los términos usados para designar a las primitivas y los campos asociados son meramente indicativos, aunque es significativa la definición correspondiente tal y como se describe.

En primer lugar se describen las primitivas entre el Cliente OTA y los recursos de radio RR en el lado del terminal MS. 25

La primitiva Ind. solicitud de descarga se envía desde el recurso de radio RR en el lado del terminal MS al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Descarga solicitada: este elemento contiene una cadena de descripción y un identificador numérico de 30 la descarga solicitada por la red.

La primitiva Ind Ack de descarga es enviada por el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados en esta primitiva son los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Número de desafío del Cliente OTA: es un número aleatorio que el Servidor OTA encriptará con su 35 propia clave y un algoritmo de codificación adecuado, por ejemplo el algoritmo AES, para llevar a cabo el primer paso de la autenticación mutua.

La primitiva Ind Nack de descarga se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 40

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Sol. de autenticación se envía desde el recurso de radio RR en el lado del terminal MS al Cliente OTA. Los campos proporcionados en esta primitiva son los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Número de respuesta del Servidor OTA: es un número encriptado por el Servidor OTA con su propia 45 clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, que concluye el primer paso de la autenticación mutua;

- Número de desafío del Servidor OTA: es un número aleatorio que el cliente encriptará con su propia clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, para llevar a cabo el segundo paso de la autenticación mutua;

La primitiva Rsp. de autenticación se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de 5 los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Número de respuesta del Cliente OTA: identifica un número encriptado por el Cliente OTA con su propia clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, que concluye el segundo y último paso de la autenticación mutua. 10

La primitiva Sol. de capacidad se envía desde el recurso de radio RR en el lado MS al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rsp. de capacidad se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de 15 los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA que envía el mensaje;

La primitiva Sol. de descripción de descarga se envía desde el recurso de radio RR en el lado del terminal MS al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos 20 un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Lista de descargas: presenta un elemento para cada descarga seleccionada por el Cliente OTA, que a su vez incluye los siguientes campos:

La primitiva Cnf. de aceptación de la descarga se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un 30 conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rech. de aceptación de la descarga se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 35

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Sol. de licencia se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva. 40

La primitiva Rsp. de licencia se envía desde el recurso de radio RR en el lado del terminal MS al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Clave de desencriptación: es la clave usada para desencriptar el software operativo. 45

La primitiva Cnf. de la licencia se envía desde el Cliente OTA al recurso de radio RR en el lado del

terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rech. de la licencia se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de 5 los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Sol. de descripción de comprobaciones se envía desde el recurso de radio RR en el lado del terminal MS al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 10

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Lista de comprobaciones: presenta un elemento para cada comprobación a realizar e incluye a su vez el campo:

- Vector de comprobación: presenta la descripción de comprobaciones.

La primitiva Cnf. de la instalación se envía desde el Cliente OTA al recurso de radio RR en el lado del 15 terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rech. de la instalación se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de 20 los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Ind. de datos se envía desde el recurso de radio RR en el lado del terminal MS al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 25

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Uno de los bloques de radio en los que se ha segmentado el software operativo.

La primitiva Sol. de datos se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 30

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Bloque de radio de Ack.

A continuación se describen las primitivas intercambiadas entre el Servidor OTA y el recurso de radio RR en el lado del controlador de la estación base BSC.

La primitiva Ind. de inicio de la descarga se envía desde el Cliente OTA al recurso de radio RR en el lado 35 del controlador de la estación base BSC. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Descarga solicitada: este elemento contiene una cadena de descripción y un identificador numérico de la descarga solicitada por la red. 40

La primitiva Ind. Ack de descarga es enviada por el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Número de desafío del Cliente OTA: es un número aleatorio que el Servidor OTA encriptará con su 45 propia clave y un algoritmo de codificación adecuado, por ejemplo el algoritmo AES, para llevar a cabo el

primer paso de la autenticación mutua.

La primitiva Ind Nack de descarga se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva. 5

La primitiva Sol. de autenticación se envía desde el Cliente OTA al recurso de radio RR en el lado del controlador de la estación base BSC. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Número de respuesta del Servidor OTA: es un número encriptado por el Servidor OTA con su propia 10 clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, que concluye el primer paso de la autenticación mutua;

- Número de desafío del Servidor OTA: es un número aleatorio que el Cliente OTA encriptará con su propia clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, para llevar a cabo el segundo paso de la autenticación mutua; 15

La primitiva Rsp. de autenticación se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Número de respuesta del Cliente OTA: identifica un número encriptado por el Cliente OTA con su 20 propia clave y un algoritmo de codificación adecuado, como por ejemplo el algoritmo AES, que concluye el segundo y último paso de la autenticación mutua.

La primitiva Sol. de capacidad se envía desde el Cliente OTA al recurso de radio RR en el lado del controlador de la estación base BSC. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 25

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rsp. de capacidad se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- Cliente OTA ID: identifica el Cliente OTA que envía el mensaje; 30

La primitiva Sol. de descripción de descarga se envía desde el Cliente OTA al recurso de radio RR en el lado del controlador de la estación base BSC. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva; 35

- Número de bloques de descarga: es el número de bloques de radio en el que se segmentará el software operativo antes de ser transmitido al Cliente OTA;

- Criterios de facturación: son los criterios relativos a la posible facturación de la descarga; 40

La primitiva Cnf. de aceptación de la descarga se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva. 45

La primitiva Rech. de aceptación de la descarga se envía desde el recurso de radio RR en el lado del

controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Sol. de licencia se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo 5 menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rsp. de licencia es enviada por el Cliente OTA al recurso de radio RR en el lado del controlador de la estación base BSC. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 10

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Clave de desencriptación: es la clave usada para desencriptar el software operativo.

La primitiva Cnf. de la licencia se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 15

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rech. de la licencia se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva. 20

La primitiva Sol. de descripción de comprobaciones se envía desde el Servidor OTA al recurso de radio RR en el lado del controlador de la estación base BSC. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Lista de comprobaciones: presenta un elemento para cada comprobación a realizar e incluye a su vez 25 el campo:

- Vector de comprobación: presenta la descripción de comprobaciones.

La primitiva Cnf. de la instalación se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes: 30

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva.

La primitiva Rech. de la instalación se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Cliente OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva. 35

La primitiva Sol. de datos se envía desde el Servidor OTA al recurso de radio RR en el lado del controlador de la estación base BSC. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Uno de los bloques de radio en los que se ha segmentado el software operativo. 40

La primitiva Ind. de datos se envía desde el recurso de radio RR en el lado del controlador de la estación base BSC al Servidor OTA. Los campos proporcionados, en el caso de GSM/GPRS, son por lo menos un conjunto de los siguientes:

- ID del Cliente OTA: identifica el Cliente OTA relacionado con la primitiva;

- Bloque de radio de Ack. 45

Con referencia a las figuras 4 y 5, se describirán las interacciones de proceso entre el Cliente OTA y el Servidor OTA indicando, para cada primitiva recibida por el respectivo RR, el comportamiento relativo según el estado en el que se encuentren el Cliente OTA o el Contexto de Cliente.

El comportamiento del Cliente OTA y el Servidor OTA son independientes del sistema.

Las primitivas intercambiadas entre el Cliente OTA o el Servidor OTA y el respectivo RR dependen del 5 sistema, y según el presente ejemplo, están referenciadas al sistema GSM/GPRS.

En la siguiente descripción, no se describen las acciones de inicio/detención del temporizador, ya que están asociadas a los estados en los que se encuentran las entidades, como se ha descrito anteriormente.

Con referencia a la figura 4, ahora se describe el comportamiento del Cliente OTA. 10

En general, si el campo ID del Cliente OTA no coincide con el identificador del Cliente OTA que recibe una primitiva, esta primitiva se ignora.

Cuando el Cliente OTA recibe la primitiva Ind. solicitud de descarga:

- si el estado es INACTIVO, el Cliente OTA pasa a INICIO DE LA DESCARGA;

- si el estado no es INICIO DE LA DESCARGA, entonces la primitiva se ignora y el proceso no continúa; 15 - si el terminal puede llevar a cabo la descarga:

- se extrae y se almacena un número aleatorio RNUM;

- se envía la primitiva Ind Ack de descarga, que contiene el valor del número RNUM extraído en el campo Número de desafío del Cliente OTA;

- si el terminal no puede llevar a cabo la descarga, se envía la primitiva Ind Nack de descarga y el 20 Cliente OTA vuelve al estado INACTIVO.

Cuando el Cliente OTA recibe la primitiva Sol. de autenticación:

- si el estado no es INICIO DE LA DESCARGA, la primitiva se ignora y el proceso no continúa;

- si el número aleatorio RNUM almacenado no es válido, el proceso no continúa;

- el Cliente OTA pasa al estado AUTENTICACIÓN MUTUA: 25

- el valor del número aleatorio RNUM almacenado se encripta con la clave interna CIK utilizando el algoritmo de codificación seleccionado, p. ej. el algoritmo AES;

- si el valor encriptado en el paso anterior no coincide con el valor del campo Número de respuesta del Servidor OTA, el Cliente OTA pasa al estado INACTIVO y el proceso no continúa;

- el valor del campo Número de desafío del Servidor OTA se encripta con la clave interna CIK (Client 30 Identity Key) utilizando el algoritmo de codificación seleccionado, p. ej. el algoritmo AES;

- la primitiva Rsp. de autenticación se envía con valor encriptado en el paso anterior en el campo Número de respuesta del Cliente OTA.

Cuando el Cliente OTA recibe la primitiva Sol. de capacidad:

- si el estado no es AUTENTICACIÓN MUTUA, la primitiva se ignora y el proceso no continúa; 35

- el Cliente OTA pasa al estado SOLICITUD DE CAPACIDAD;

- se envía la primitiva Respuesta de capacidad.

Cuando el Cliente OTA recibe la primitiva Sol. de descripción de descarga:

- si el estado no es SOLICITUD DE CAPACIDAD, la primitiva se ignora y el proceso no continúa;

- el Cliente OTA pasa al estado ACEPTACIÓN DE LA DESCARGA; 40

- si el terminal puede instalar el software:

- se envía la primitiva Cnf. de aceptación de la descarga;

- si el terminal no puede instalar el software:

- se envía la primitiva Rech. de aceptación de la descarga;

- el Cliente OTA pasa al estado INACTIVO.

Cuando el Cliente OTA recibe la primitiva Resp. de la licencia:

- si el estado no es INSTALACIÓN, la primitiva se ignora y el proceso no continúa;

- el software descargado se desencripta utilizando la clave indicada en el campo Clave de 5 desencriptación;

- si la desencriptación tiene éxito:

- se envía la primitiva Cnf. de la licencia;

- se almacena el software operativo descargado;

- si la desencriptación no tiene éxito: 10

- se envía la primitiva Rech. de la licencia:

- el proceso pasa al estado INACTIVO.

Cuando el Cliente OTA recibe la primitiva Sol. de descripción de comprobaciones:

- el Cliente OTA pasa al estado COMPROBACIONES IN SITU; 15

- las comprobaciones recibidas se llevan a cabo en el software operativo almacenado previamente;

- si todas las comprobaciones han tenido éxito:

- se envía la primitiva Cnf. de la instalación;

- se instala y se inicia el nuevo software operativo;

- si por lo menos una comprobación no tiene éxito: 20

- se envía la primitiva Rech. de la instalación;

- la software operativo de descarga se borra de la memoria;

- el Cliente OTA pasa al estado INACTIVO.

De nuevo con referencia a la figura 5, ahora se describe el comportamiento del Servidor OTA.

En general, en cada primitiva recibida se analiza el campo ID del Cliente OTA y se considera el Contexto 25 de Cliente OTA relativo a dicho identificador; si no hay presente ningún Contexto de Cliente OTA para el identificador recibido, la primitiva se ignora.

Cuando el Servidor OTA recibe la primitiva Ind. Ack de descarga:

- si el estado del Contexto de Cliente OTA no es INICIO DE LA DESCARGA, la primitiva se ignora y el proceso no continúa; 30

- el Contexto de Cliente OTA pasa al estado AUTENTICACIÓN MUTUA;

- se extrae y se almacena un número aleatorio;

- el valor del campo Número de desafío del Cliente OTA se encripta con la clave interna SIK (Server Identity Key) utilizando el algoritmo de codificación seleccionado, p. ej. el algoritmo AES;

- la primitiva Sol. de autenticación se envía al Cliente OTA con el valor encriptado en el paso anterior en 35 el campo Número de respuesta del Servidor OTA y con el valor del número extraído en el campo Número de desafío del Servidor OTA.

Cuando el Contexto de Cliente OTA recibe la primitiva Ind. Nack de descarga:

- si el estado del Contexto de Cliente OTA no es INICIO DE LA DESCARGA, la primitiva se ignora y el proceso no continúa; 40

- el Contexto de Cliente OTA pasa al estado INACTIVO.

Cuando el Contexto de Cliente OTA recibe la primitiva Rsp. de autenticación:

- si el estado del Contexto de Cliente OTA no es AUTENTICACIÓN MUTUA, la primitiva se ignora y el proceso no continúa;

- el valor del número aleatorio almacenado se encripta con la clave interna SIK utilizando el algoritmo de codificación seleccionado, p. ej. el algoritmo AES; 5

- si el valor encriptado en el paso anterior no coincide con el valor del campo Número de respuesta del Cliente OTA, el Contexto de Cliente OTA pasa al estado INACTIVO y no continúa;

- el Servidor OTA pasa al estado SOLICITUD DE CAPACIDAD;

- se envía la primitiva Sol. de capacidad.

Cuando el Contexto de Cliente OTA recibe la primitiva Rsp. de capacidad: 10

- si el estado del Contexto de Cliente OTA no es SOLICITUD DE CAPACIDAD, la primitiva se ignora y el proceso no continúa;

- si la capacidad contenida en la primitiva no es compatible con el software a descargar, el Contexto de Cliente OTA pasa al estado INACTIVO;

- si la capacidad contenida en la primitiva es compatible con el software a descargar, el Contexto de 15 Cliente OTA pasa al estado ACEPTACIÓN DE LA DESCARGA y se envía la primitiva Sol. de descripción de descarga.

Cuando el Contexto de Cliente OTA recibe la primitiva Cnf. de aceptación de la descarga:

- si el estado del Contexto de Cliente OTA no es ACEPTACIÓN DE LA DESCARGA, la primitiva se ignora y el proceso no continúa; 20

- el Contexto de Cliente OTA pasa al estado DESCARGA DEL SOFTWARE;

- comienza la descarga de software.

Cuando el Contexto de Cliente OTA recibe la primitiva Rech. de aceptación de la descarga:

- si el estado del Contexto de Cliente OTA no es ACEPTACIÓN DE LA DESCARGA, la primitiva se ignora y el proceso no continúa; 25

- el Contexto de Cliente OTA pasa al estado INACTIVO.

Cuando el Contexto de Cliente OTA recibe la primitiva Sol. de licencia:

- si el estado del Contexto de Cliente OTA no es DESCARGA DEL SOFTWARE, la primitiva se ignora y el proceso no continúa;

- el proceso pasa al estado INSTALACIÓN; 30

- se envía la primitiva del protocolo Rsp. de licencia, que contiene la clave de desencriptación.

Cuando el Contexto de Cliente OTA recibe la primitiva Cnf. de la licencia:

- si el estado del Contexto de Cliente OTA no es INSTALACIÓN, la primitiva se ignora y el proceso no continúa;

- se envía la primitiva Sol. de descripción de comprobaciones. 35

Cuando el Contexto de Cliente OTA recibe la primitiva Rech. de la licencia:

- el Contexto de Cliente OTA pasa al estado INACTIVO.

Cuando el Contexto de Cliente OTA recibe la primitiva Cnf. de la instalación: 40

- el Contexto de Cliente OTA pasa al estado INACTIVO.

Cuando el Contexto de Cliente OTA recibe la primitiva Rech. de la instalación:

- el Contexto de Cliente OTA pasa al estado INACTIVO.

A continuación se describe la operación del protocolo de ventana según la cual los datos se transfieren 5 del Servidor OTA al Cliente OTA.

Desde el punto de vista del Servidor OTA, cuando la descarga de software comienza, el software operativo se encripta, por ejemplo, con una clave de encriptación y con un algoritmo de encriptación de tipo conocido, p. ej. el algoritmo AES.

El software operativo encriptado se segmenta en bloques, por ejemplo con un tamaño limitado, p. ej. 1-2 10 kBytes. Se asigna una máscara de bits BITMASK con un número de bits igual al número de bloques de radio en los que se ha segmentado el software operativo, y para cada bit se pone el valor "0"; cada bit de la máscara corresponde al bloque de radio cuyo número es igual a la posición del bit, es decir, el primer bit corresponde al primer bloque de radio, el segundo bit al segundo bloque de radio y así sucesivamente. Se envían los primeros N bloques de radio BLOCK que constituyen el software 15 operativo. El temporizador T401 se pone en marcha. Al recibir cada mensaje Ack:

- el temporizador T401 se reinicia;

- para cada valor "1" existente en el mapa de bits del mensaje Ack, se pone a "1" el valor de la máscara BITMASK asignada en la posición correspondiente;

- como máximo se envían los primeros N bloques de radio BLOCK que en la máscara BITMASK 20 corresponden al valor "0", considerando primero los bloques no enviados todavía;

- la descarga termina cuando todos los bits de la máscara BITMASK poseen un valor igual a "1".

Desde el punto de vista del Cliente OTA, cuando empieza la descarga de software, se asigna una máscara de bits BITMASK igual al número de bloques de radio en los que se ha segmentado el software, y el valor de cada bit se pone a "0"; cada bit de la máscara corresponde al bloque de radio 25 cuyo número es igual a la posición del bit, es decir, el primer bit corresponde al primer bloque de radio, el segundo bit al segundo bloque de radio y así sucesivamente. A continuación se pone en marcha el temporizador T400. Al recibir cada bloque de radio BLOCK:

- el temporizador T400 se reinicia;

- el bit de la máscara BITMASK correspondiente al Número de Bloque del bloque de radio recibido se 30 pone a "1";

- se envía un mensaje Ack con el mapa de bits correspondiente a la máscara BITMASK;

- la descarga termina cuando todos los bits de la máscara BITMASK poseen el valor "1 ".

En resumen, según el ejemplo, el comportamiento funcional del cliente OTA y el servidor OTA es el siguiente: 35

- el proceso de descarga se inicia, por ejemplo, al recibir el mensaje de protocolo Comando de Handover enviado por el MSC (Centro de conmutación móvil) al controlador de la estación base BSC;

- la autenticación mutua entre el Cliente OTA y el Servidor OTA tiene lugar, por ejemplo, según el procedimiento "desafío-respuesta";

- el software operativo a descargar se envía en un canal de tráfico, p. ej. el canal de tráfico GPRS; 40

- el software operativo a descargar es segmentado por el Servidor OTA en bloques con un tamaño reducido (p. ej. 1 o 2 kBytes);

- la transferencia del software operativo es gestionada por un protocolo de ventana sencillo, en el que el tamaño de la ventana coincide con el número de bloques en el que se ha segmentado el software operativo; 45

- el software operativo descargado puede encriptarse y, en este caso, se necesita una clave para su desencriptación e instalación;

- antes de iniciar el software operativo, el Cliente OTA lo verifica con comprobaciones adecuadas sugeridas, por ejemplo, por el Servidor OTA.

Con referencia a la figura 18, se ilustra un ejemplo de aplicación del proceso de handover entre sistemas desde GSM a UMTS para una llamada de circuito, tal y como define el estándar, dentro del cual se ha introducido el proceso de descarga del software operativo capaz de reconfigurar el terminal 5 MS.

Con referencia a la figura 19, se explica cómo funciona este proceso de descarga de software, señalando las interacciones entre las distintas entidades existentes en la red.

1. El Cliente OTA y el Contexto de Cliente OTA relativo al Cliente OTA considerado y presente en el Servidor OTA están en el estado INACTIVO. 10

2. Al recibir el mensaje de protocolo Comando de Handover desde el centro de conmutación móvil (MSC), el Contexto de Cliente OTA pasa del estado INACTIVO al estado INICIO DE LA DESCARGA, pone en marcha el temporizador T101 y envía la primitiva Ind. de inicio de la descarga al recurso de radio RR al mismo tiempo que indica la descarga solicitada.

3. El recurso de radio RR recibe la primitiva Ind. de inicio de la descarga. El recurso de radio RR solicita 15 a la gestión de recursos de radio RRM los recursos de enlace descendente necesarios para poder llevar a cabo la descarga de software.

a. Si los recursos están disponibles, el recurso de radio RR envía en el canal de control FACCH (canal de control asociado rápido) el mensaje de protocolo Solicitud de descarga de paquete al recurso de radio RR del terminal MS, en el que indica los canales PDCH en los que el terminal llevará a cabo la descarga, 20 el periodo de bloqueo reservado relativo RRBP y la descarga solicitada.

b. Si los recursos no están disponibles, el recurso de radio RR envía la primitiva Ind Nack de descarga al Contexto de Cliente OTA.

4. El recurso de radio RR del terminal MS recibe el mensaje de protocolo Solicitud de descarga de paquete, configura los canales PDCH y envía la primitiva Ind. solicitud de descarga. 25

5. El Cliente OTA recibe la primitiva Ind. solicitud de descarga. Si el terminal puede llevar a cabo la descarga, el Cliente OTA pasa del estado INACTIVO al estado INICIO DE LA DESCARGA, pone en marcha el temporizador T100 y envía la primitiva Ind Ack de descarga, en la que especifica al recurso de radio RR su propio identificador. El recurso de radio RR almacena localmente el identificador del Cliente OTA. 30

6. El recurso de radio RR recibe la primitiva Ind Ack de descarga y envía en el PACCH (canal de control de paquete asociado) en el tiempo especificado por el periodo de bloqueo reservado relativo RRBP el mensaje de protocolo Ack de descarga de paquete al recurso de radio RR del controlador de la estación base BSC, en el que indica el identificador del Cliente OTA.

7. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Ack de 35 descarga de paquete y envía la primitiva Ind Ack de descarga al Contexto de Cliente OTA, en el que especifica el identificador del Cliente OTA.

8. El Contexto de Cliente OTA recibe la primitiva Ind Ack de descarga; el Contexto de Cliente OTA detiene el temporizador T101 y pasa del estado INICIO DE LA DESCARGA al estado AUTENTICACIÓN MUTUA, al mismo tiempo que pone en marcha el temporizador T201; la primitiva Sol. de autenticación 40 se envía al recurso de radio RR.

9. El recurso de radio RR recibe la primitiva Sol. de autenticación y envía en el canal de control PACCH el mensaje de protocolo Sol. de autenticación de paquete al recurso de radio RR del terminal MS, en el que se indica el RRBP.

10. El recurso de radio RR del terminal MS recibe el mensaje de protocolo Sol. de autenticación de 45 paquete y envía la primitiva Sol. de autenticación al Cliente OTA.

11. El Cliente OTA recibe la primitiva Sol. de autenticación, detiene el temporizador T100 y pasa al estado AUTENTICACIÓN MUTUA, al mismo tiempo que pone en marcha el temporizador T200; en esta etapa, se lleva a cabo la autenticación del Servidor OTA:

a. Si el Servidor OTA no se autentica, el Cliente OTA detiene el temporizador T200 y vuelve al estado INACTIVO.

b. Si el Servidor OTA se autentica, el Cliente OTA envía la primitiva Rsp. de autenticación al recurso de radio RR.

12. El recurso de radio RR recibe la primitiva Rsp. de autenticación y envía en el PACCH en el tiempo 5 especificado por el periodo de bloqueo reservado relativo RRBP el mensaje de protocolo Respuesta de autenticación de paquete al recurso de radio RR del controlador de la estación base BSC.

13. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Respuesta de autenticación de paquete y envía la primitiva Rsp. de autenticación al Contexto de Cliente OTA. 10

14. El Contexto de Cliente OTA recibe la primitiva Rsp. de autenticación y verifica la autenticación del Cliente OTA:

a. Si el Cliente OTA no se autentica, el temporizador T201 se interrumpe y el Contexto de Cliente OTA vuelve al estado INACTIVO.

b. Si el Cliente OTA se autentica, el temporizador T201 se interrumpe y el Contexto de Cliente OTA pasa 15 al estado SOLICITUD DE CAPACIDAD, al mismo tiempo que pone en marcha el temporizador T301. El Contexto de Cliente OTA envía al recurso de radio RR la primitiva Sol. de capacidad.

15. El recurso de radio RR recibe la primitiva Sol. de capacidad y envía en el canal de control PACCH el mensaje de protocolo Sol. de capacidad de paquete al recurso de radio RR del terminal MS, en el que se especifica el RRBP. 20

16. El recurso de radio RR del terminal MS recibe el mensaje de protocolo Sol. de capacidad de paquete y envía la primitiva Sol. de capacidad al Cliente OTA.

17. El Cliente OTA recibe la primitiva Sol. de capacidad, detiene el temporizador T200 y pasa al estado SOLICITUD DE CAPACIDAD, al mismo tiempo que pone en marcha el temporizador T300; el Cliente OTA envía la primitiva Rsp. de capacidad al recurso de radio RR. 25

18. El recurso de radio RR recibe la primitiva Rsp. de capacidad y envía en el PACCH en el tiempo especificado por el RRBP el mensaje de protocolo Respuesta de capacidad de paquete al recurso de radio RR del controlador de la estación base BSC.

19. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Respuesta de capacidad de paquete y envía la primitiva Rsp. de capacidad al Contexto de Cliente OTA. 30

20. El Contexto de Cliente OTA recibe la primitiva Rsp. de capacidad y verifica la capacidad del terminal:

a. Si la capacidad no es compatible con la descarga de software, el temporizador T301 se interrumpe y el Contexto de Cliente OTA vuelve al estado INACTIVO.

b. Si la capacidad es compatible con la descarga de software, el temporizador T301 se interrumpe y el Contexto de Cliente OTA pasa al estado ACEPTACIÓN DE LA DESCARGA, al mismo tiempo que pone 35 en marcha el temporizador T302 y envía al recurso de radio RR la primitiva Sol. de descripción de descarga, en la que se indica la información relativa a la operación de descarga (número de bloques de radio a descargar, facturación, instalación y así sucesivamente).

21. El recurso de radio RR recibe la primitiva Sol. de descripción de descarga y envía en el canal de control PACCH el mensaje de protocolo Descripción de descarga de paquete al recurso de radio RR del 40 terminal MS, en el que se especifica el RRBP.

22. El recurso de radio RR del terminal MS recibe el mensaje de protocolo Descripción de descarga de paquete y envía la primitiva Sol. de descripción de descarga al Cliente OTA.

23. El Cliente OTA recibe la primitiva Sol. de descripción de descarga, detiene el temporizador T300 y pasa al estado ACEPTACIÓN DE LA DESCARGA; el Cliente OTA verifica la información recibida: 45

a. Si la descarga no se acepta, el Cliente OTA envía la primitiva Rech. de aceptación de la descarga al recurso de radio RR y vuelve al estado INACTIVO.

b. Si la descarga se acepta, el Cliente OTA envía la primitiva Cnf. de aceptación de la descarga al

recurso de radio RR y pasa al estado DESCARGA DEL SOFTWARE, al mismo tiempo que pone en marcha el temporizador T400.

24. El recurso de radio RR recibe la primitiva Cnf. de aceptación de la descarga y envía en el PACCH en el tiempo especificado por el RRBP el mensaje de protocolo Aceptación de descarga de paquete al recurso de radio RR del controlador de la estación base BSC. 5

25. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Aceptación de descarga de paquete y envía la primitiva Cnf. de aceptación de la descarga al Contexto de Cliente OTA.

26. El Contexto de Cliente OTA recibe la primitiva Cnf. de aceptación de la descarga, detiene el temporizador T302 y el Contexto de Cliente OTA pasa al estado DESCARGA DEL SOFTWARE, al 10 mismo tiempo que activa el temporizador T400; el Contexto de Cliente OTA inicia la descarga y, enviando primitivas Sol. de datos al recurso de radio RR, comienza a transmitir los diversos bloques del software a descargar. La transferencia de los bloques de radio tiene lugar por medio de un protocolo de ventana tradicional. Los bloques de radio se transmiten en el canal PDTCH (canal de tráfico de datos de paquete). 15

27. El Cliente OTA recibe cada bloque de radio mediante la recepción de primitivas Ind. de datos desde el recurso de radio RR; en cada bloque recibido, el temporizador T400 se reinicia; periódicamente, el Cliente OTA envía al Contexto de Cliente OTA una señal de reconocimiento Ack enviando la primitiva Sol. de datos al recurso de radio RR. El recurso de radio RR envía el Ack en el canal de control asociado PACCH. Cuando el Cliente OTA envía el Ack relativo al último bloque de radio a descargar, detiene el 20 temporizador T400 y pasa al estado INSTALACIÓN, al mismo tiempo que pone en marcha el temporizador T500; la primitiva Sol. de licencia se envía al recurso de radio RR.

28. El Contexto de Cliente OTA recibe los diversos mensajes Ack mediante la recepción de primitivas Ind. de datos desde el recurso de radio RR; en cada Ack recibido, el temporizador T401 se reinicia. Cuando el Contexto de Cliente OTA recibe el Ack relativo al último bloque de radio, detiene el 25 temporizador T401 y pasa al estado INSTALACIÓN, al mismo tiempo que pone en marcha el temporizador T501.

29. El recurso de radio RR recibe la primitiva Sol. de licencia y envía en el canal de control asociado PACCH el mensaje de protocolo Solicitud de licencia de paquete al recurso de radio RR del controlador de la estación base BSC. 30

30. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Solicitud de licencia de paquete, y envía la primitiva Sol. de licencia al Contexto de Cliente OTA.

31. El Contexto de Cliente OTA recibe la primitiva Sol. de licencia y envía al recurso de radio RR la primitiva Rsp. de licencia, al mismo tiempo que indica la clave para llevar a cabo la desencriptación del software. 35

32. El recurso de radio RR recibe la primitiva Rsp. de licencia y envía en el canal de control asociado PACCH el mensaje de protocolo Respuesta de licencia de paquete al recurso de radio RR del terminal MS.

33. El recurso de radio RR del terminal MS recibe el mensaje de protocolo Respuesta de licencia de paquete y envía la primitiva Rsp. de licencia al Cliente OTA. 40

34. El Cliente OTA recibe la primitiva Rsp. de licencia y desencripta el software con la clave recibida:

a. Si la operación de desencriptación tiene éxito, el Cliente OTA envía la primitiva Cnf. de la licencia al recurso de radio RR.

b. Si la operación de desencriptación no tiene éxito, el Cliente OTA envía la primitiva Rech. de la licencia al recurso de radio RR, detiene el temporizador T500 y vuelve al estado INACTIVO. 45

35. El recurso de radio RR recibe la primitiva Cnf. de la licencia y envía en el canal de control asociado PACCH el mensaje de protocolo Aceptación de licencia de paquete al recurso de radio RR del controlador de la estación base BSC.

36. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Aceptación de licencia de paquete, y envía la primitiva Cnf. de la licencia al Contexto de Cliente OTA. 50

37. El Contexto de Cliente OTA recibe la primitiva Cnf. de la licencia y envía al recurso de radio RR la primitiva Sol. de descripción de comprobaciones, al mismo tiempo que indica la información relativa a las comprobaciones a realizar.

38. El recurso de radio RR recibe la primitiva Sol. de descripción de comprobaciones y envía en el canal de control asociado PACCH el mensaje de protocolo Descripción de comprobación de paquete al 5 recurso de radio RR del terminal MS.

39. El recurso de radio RR del terminal MS recibe el mensaje de protocolo Descripción de comprobación de paquete y envía la primitiva Sol. de descripción de comprobaciones al Cliente OTA.

40. El Cliente OTA recibe la primitiva Sol. de descripción de comprobaciones, detiene el temporizador T500 y pasa al estado COMPROBACIONES IN SITU. El Cliente OTA lleva a cabo la comprobación en el 10 software descargado como indica el Contexto de Cliente OTA.

a. Si la comprobación no tiene éxito, el Cliente OTA envía la primitiva RECH. DE LA INSTALACIÓN al recurso de radio RR y vuelve al estado INACTIVO.

b. Si la comprobación tiene éxito, el Cliente OTA envía la primitiva Cnf. de instalación al recurso de radio RR, inicia el nuevo software y vuelve al estado INACTIVO. 15

41. El recurso de radio RR recibe la primitiva CNF. DE LA INSTALACIÓN y envía en el canal de control asociado PACCH el mensaje de protocolo Aceptación de instalación de paquete al recurso de radio RR del controlador de la estación base BSC y reconfigura la interfaz de radio del terminal MS.

42. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Aceptación de instalación de paquete, envía la primitiva Cnf. de la instalación al Contexto de Cliente 20 OTA, inicia el proceso de emisión de los recursos tal y como determina el estándar, y una vez terminado dicho proceso, continúa el proceso de handover tal y como determina el estándar.

43. El Contexto de Cliente OTA recibe la primitiva Cnf. de la instalación y vuelve al estado INACTIVO.

El proceso que se da a conocer en la figura 19 se refiere al proceso de descarga del software operativo. 25

El proceso puede insertarse, como podrá apreciar un experto en la materia, en el proceso de handover entre sistemas desde GSM a UMTS para una llamada de circuito, tal y como define el estándar.

En particular, la inserción puede realizarse en la capa RR, entre la recepción desde el MSC del mensaje COMANDO DE HANDOVER del protocolo de parte de aplicación del subsistema de estaciones base (BSSAP) y la transmisión al MS del mensaje COMANDO DE HANDOVER ENTRE SISTEMAS A UTRAN 30 del protocolo RR.

La invención puede generalizarse a todos los procesos posibles de handover entre sistemas especificados por los estándares actuales.

Por ejemplo, el proceso puede insertarse, como podrá apreciar un experto en la materia, en el proceso de handover entre sistemas desde UMTS a GSM para una llamada de circuito, tal y como define el 35 estándar. En particular, la inserción puede realizarse en la capa de control de recursos de radio (RRC), entre la recepción desde el MSC del mensaje COMANDO DE REUBICACIÓN del protocolo parte de aplicación de radio acceso de red (RANAP) y la transmisión al equipo del usuario (UE) del mensaje HANDOVER DESDE COMANDO UTRAN del protocolo control de recursos de radio (RRC).

La invención también puede generalizarse a procesos de handover entre sistemas todavía no 40 estandarizados, como por ejemplo procesos de handover entre sistemas entre International Mobile Telecommunication 2000 (IMT 2000) y sistemas WLAN o IEEE 802.16 o IEEE 802.20.

Como resulta evidente para un experto en la materia, la invención permite, en caso de una llamada de voz, en particular una llamada de tipo circuito, llevar a cabo la descarga del software operativo sin interrumpir la llamada; esto es posible, en el caso por ejemplo de GSM/GPRS, asignando uno o más 45 canales de paquete, p. ej. canales PDTCH GPRS, en paralelo al canal de tipo circuito, p. ej. canal GSM TCH (Traffic Channel), usado para la comunicación de circuito.

Esta característica puede permitir gestionar la prioridad entre voz, datos y descarga de software.

La invención se ha dado a conocer manteniendo como referencia un sistema GSM/GPRS y el uso de

los canales de radio del sistema mencionado anteriormente, pero, como podrá apreciar un experto en la materia, la invención puede aplicarse utilizando, por ejemplo, un canal “universal”.

Un posible ejemplo de uso de un canal “universal” podría ser la utilización de un canal “universal”, tal y como define la bibliografía, para el proceso de descarga de software operativo desde el Servidor OTA al Cliente OTA. 5

En caso de handover entre sistemas, la implementación de usar un canal “universal” podría prever mantener la conexión activa en los canales de radio del sistema activo p. ej. el sistema GSM/GPRS, al mismo tiempo que el proceso de descarga de software operativo desde el Servidor OTA al Cliente OTA se explota simultáneamente en el canal “universal” mencionado anteriormente, adoptando por ejemplo el proceso que se da a conocer en la figura 18. 10

El canal "universal" puede usarse para todo el proceso de descarga de software operativo o sólo una parte del mismo, por ejemplo la transmisión del software operativo desde el Servidor OTA al Cliente OTA.

En caso de un uso parcial del canal “universal”, la parte restante del proceso de descarga de software operativo puede implementarse utilizando los canales de radio del sistema activo. 15

La adopción del canal "universal" permite cargar de un modo más eficaz los recursos de radio relacionados con el sistema activo, dejándolos a disposición de otros usuarios, y llevar a cabo el proceso de descarga de software operativo de forma mucho más rápida, ya que el canal “universal” es un canal dedicado a este tipo de operación.

Otra realización de la invención prevé la posibilidad de gestionar también un proceso de reselección de 20 células, como es conocido por un experto en la materia, cuando el terminal se encuentra, por ejemplo, en el estado INACTIVO entre dos sistemas, p. ej. desde GSM/GPRS a UMTS.

Como se ha observado anteriormente, los términos utilizados para designar a las primitivas y campos asociados son meramente indicativos, aunque es significativa la correspondiente definición tal y como se describe. 25

Esta extensión prevé la introducción de la siguiente primitiva entre el Cliente OTA y el recurso de radio RR en el lado del terminal MS:

- Sol. de inicio de descarga: este mensaje se envía desde el Cliente OTA al recurso de radio RR en el lado del terminal MS.

Los campos proporcionados en esta primitiva, en el caso de GSM/ GPRS, son por lo menos un conjunto 30 de los siguientes:

ID de Cliente OTA: identifica el Cliente OTA que lleva a cabo la solicitud;

y de la siguiente primitiva entre el Servidor OTA y el recurso de radio RR en el lado del controlador de la estación base BSC:

- Solicitar ind. de inicio de la descarga: este mensaje se envía desde el recurso de radio RR en el lado 35 del controlador de la estación base BSC al Cliente OTA.

Los campos proporcionados en la primitiva, en el caso de GSM/ GPRS, son por lo menos un conjunto de los siguientes:

ID de Cliente OTA: identifica el Cliente OTA que lleva a cabo la solicitud.

A continuación se indica el comportamiento del contexto relativo al terminal MS del Contexto de Cliente 40 OTA al recibir la primitiva Solicitar ind. de inicio de la descarga:

- si el estado del Contexto de Cliente OTA no es INACTIVO, la primitiva se ignora y el proceso no continúa;

- el Contexto de Cliente OTA pasa al estado INICIO DE LA DESCARGA;

- la primitiva Ind. de inicio de la descarga se envía al Cliente OTA, al mismo tiempo que indica las 45 diversas posibles descargas.

Con referencia a la figura 19, se ilustra el funcionamiento del proceso de descarga de software operativo en caso de reselección de células, señalando las interacciones entre las distintas entidades presentes en

la red. A continuación se describe, en detalle, el funcionamiento de la primera fase del proceso, ya que el resto del proceso en sí mismo es idéntico a la descripción de la figura 18.

I. El Cliente OTA y el Contexto de Cliente OTA relativo al Cliente OTA considerado están en el estado INACTIVO.

II. Al recibir el comando de reselección de células que procede de la capa física, el Cliente OTA pasa del 5 estado INACTIVO al estado INICIO DE LA DESCARGA, pone en marcha el temporizador T100 y envía la primitiva Sol. de inicio de la descarga, en la que especifica su propio identificador al recurso de radio RR. El recurso de radio RR almacena localmente el identificador del Cliente OTA.

III. El recurso de radio RR recibe la primitiva Sol. de inicio de la descarga. El recurso de radio RR envía en el canal de acceso aleatorio al paquete PRACH el mensaje de protocolo Solicitud de canal de 10 paquete proporcionado por el estándar, en el que especifica la solicitud de descargar el software operativo por parte del usuario y el identificador del Canal OTA. En caso de que la configuración GPRS instalada por el operario no prevea el canal maestro constituido por el canal de control de emisión de paquete PBCCH y por el canal de control común del paquete PCCCH, el proceso descrito sigue siendo válido mapeando los dos primeros mensajes del propio proceso en el canal de acceso aleatorio RACH y 15 en el canal de concesión de acceso AGCH del GSM en lugar del canal de acceso aleatorio al paquete PRACH y el canal de concesión de acceso al paquete PAGCH tal y como se describen.

IV. El recurso de radio RR del controlador de la estación base BSC recibe el mensaje de protocolo Solicitud de canal de paquete. Puesto que éste se reconoce como una solicitud de descarga de software, envía la primitiva Solicitar ind. de inicio de la descarga al Contexto de Cliente OTA, en el que 20 se especifica el identificador del Cliente OTA leído por el mensaje recibido.

V. El Servidor OTA recibe la primitiva Solicitar ind. de inicio de la descarga y verifica en qué estado se encuentra el Contexto de Cliente OTA relativo al Cliente OTA indicado:

a. Si el estado es INACTIVO, el Contexto de Cliente OTA pasa al estado INICIO DE LA DESCARGA, pone en marcha el temporizador T101 y envía la primitiva Ind. de inicio de la descarga al recurso de 25 radio RR, al mismo tiempo que indica la descarga solicitada.

b. Si el estado no es INACTIVO, el mensaje se ignora.

VI. El recurso de radio RR recibe la primitiva Ind. de inicio de la descarga. El recurso de radio RR solicita a la gestión de recursos de radio RRM los recursos de enlace descendente necesarios para poder llevar a cabo la descarga de software: 30

a. Si los recursos están disponibles, el recurso de radio RR envía en el canal de control PAGCH el mensaje de protocolo Solicitud de descarga de paquete al recurso de radio RR del terminal MS, en el que indica los canales PDCH en los que el terminal llevará a cabo la descarga, el RRBP y la descarga solicitada.

b. Si los recursos no están disponibles, el recurso de radio RR envía la primitiva Ind. Nack de descarga 35 al Contexto de Cliente OTA.

VII. El recurso de radio RR del terminal MS recibe el mensaje de protocolo Solicitud de descarga de paquete, configura los canales PDCH y envía la primitiva Ind. solicitud de descarga.

VIII. El Cliente OTA recibe la primitiva Ind. solicitud de descarga. Si el terminal puede llevar a cabo la descarga, el Cliente OTA envía la primitiva Ind. Ack de descarga, en la que especifica su propio 40 identificador. El recurso de radio RR almacena localmente el identificador del Cliente OTA.

El proceso continúa realizando las etapas a partir del número 6 del proceso descrito con referencia a la figura 18.

La arquitectura y el procedimiento descritos según la presente invención se han dado a conocer manteniendo como referencia la red de acceso del sistema GSM/GPRS. 45

La invención también puede aplicarse a la red de acceso de UMTS, UTRAN (UMTS Terrestrial Radio Access Network) o cualesquiera otras redes de acceso, p. ej. WLAN, IEEE 802.16, IEEE 802.20.

Por ejemplo, en caso de UTRAN, la invención puede implementarse insertando el Cliente OTA y el Servidor OTA y los procesos, primitivas y mensajes de protocolo asociados en la capa RRC del sistema

UMTS.

La invención se ha dado a conocer utilizando la red de acceso y las correspondientes capas de protocolos tanto en el lado de la red como en el lado del terminal. La invención también puede implementarse utilizando la red básica y las correspondientes capas de protocolos tanto en el lado de la red como en el lado del terminal. 5

En este caso, considerando por ejemplo la red básica conmutada del paquete de GSM/GPRS y los sistemas UMTS, la invención puede implementarse insertando el Cliente OTA y el Servidor OTA y los procesos, primitivas y mensajes de protocolo asociados en la capa gestión de movilidad GPRS (GMM) respectivamente del terminal y del nodo de soporte GPRS servidor (SGSN) de la red básica.

Más en particular, en el caso de GSM/GPRS, la capa gestión de movilidad GPRS (GMM) se modifica 10 introduciendo nuevos mensajes de protocolo y campos asociados intercambiados entre el Servidor OTA y el Cliente OTA. El mismo planteamiento podría aplicarse para el sistema UMTS.

La invención se ha dado a conocer considerando la descarga y la activación de un software operativo durante un proceso de handover entre sistemas.

Como podrá resultar evidente para un experto en la materia, el software operativo puede descargarse y 15 almacenarse en el terminal, en lugar de instalarse y ejecutarse de inmediato.

Según esta otra realización, es posible instalar y ejecutar el software operativo tras una solicitud procedente de la red o del usuario. Si el terminal de radio UE/MS posee memoria y capacidad de procesamiento suficientes, el software operativo descargado puede almacenarse e instalarse junto con el sistema ya existente que funciona en ese momento. 20

Esta opción es útil para permitir un funcionamiento multimodo del terminal UE/MS. Dicho de otro modo, esta opción hace que el terminal pueda cambiar de un modo operativo a otro sin la necesidad de descargar el software operativo.

En resumen, gracias a la invención, es posible obtener por lo menos las siguientes ventajas:

- se minimiza el impacto sobre los protocolos y nodos existentes en las redes de segunda y tercera 25 generación, ya que no se añaden nodos ni interfaces físicas a los ya existentes;

- se minimiza la ocupación de los recursos de radio, ya que la fase de señalización del proceso emplea los mismos canales de señalización proporcionados por el estándar, al mismo tiempo que los canales de datos se asignan sólo para el proceso de descarga de software;

- no es necesario esperar a futuras versiones de UMTS basadas en IP, como las mencionadas en el 30 estado de la técnica anterior, puesto que la invención se basa en las redes de segunda y tercera generación ya existentes.

En particular, en el caso de usar la red de acceso y las correspondientes capas de protocolos tanto en el lado de la red como en el lado del terminal, the red puede controlar totalmente el proceso de descarga de software y los recursos de radio relativos, ya que el protocolo RR (recurso de radio) se ha integrado 35 con algunas modificaciones que permiten al terminal descargar el nuevo software operativo, que puede implemente, por ejemplo, un sistema celular de segunda generación, como GSM/GPRS, IS95, PDC (Phone Digital Cellular) o un sistema celular de tercera generación, perteneciente por ejemplo a la familia IMT2000.

40

REFERENCIAS CITADAS EN LA DESCRIPCIÓN

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 5 declina cualquier responsabilidad en este respecto.

Documentos de patente citados en la descripción

• JP 2001061186 B 10

• US 20030163551 A

• US 20040176129 A1

• US 6577614 B1

Documentos de la patente no citados en la descripción 15

• J. Mitola. The Software Radio Architecture. IEEE

Communications Magazine, May 1995

• E. Buracchini. The Software Radio Concept. IEEE

Communications Magazine, September 2000 20

• Architecture Of IP Based Network Elements Supporting

Reconfigurable Terminals. SCOUT Workshop, 6 September 2003

Claims

REIVINDICACIONES

1. Una red de comunicación operativa de acuerdo con un sistema de comunicación, incluyendo dicha red de comunicación una capa de protocolos de recursos de radio, que incluye primeros mensajes de una pila de protocolos correspondiente al sistema de comunicación y que presenta

- por lo menos un terminal de radio reconfigurable, configurado para gestionar el intercambio de 5 información dentro de dicha red de comunicación utilizando dicho sistema de comunicación,

- por lo menos un nodo de dicha red de comunicación, configurado para gestionar el intercambio de información con dicho por lo menos un terminal de radio reconfigurable mediante una conexión over-the-air inalámbrica, utilizándose dichos primeros mensajes para gestionar dicha conexión over-the-air inalámbrica, presentando dicho por lo menos un nodo una entidad servidor configurada para usar dicha 10 capa de protocolos de recursos de radio de dicha red de comunicación y presentando un conjunto de módulos de software operativo configurados para implementar por lo menos un conjunto de elementos de dicha pila de protocolos, estando adaptado dicho conjunto de elementos para configurar dicho por lo menos un terminal de radio reconfigurable; y

- dicho por lo menos un terminal de radio reconfigurable, presentando una entidad cliente, configurada 15 para usar una respectiva capa de protocolos de recursos de radio correspondiente a dicha capa de protocolos de dicha entidad servidor, y

- dichas entidades servidor y cliente, dotadas de respectivos módulos de software over-the-air, capaces de gestionar un proceso de descarga over-the-air entre dicho por lo menos un terminal de radio reconfigurable y dicho por lo menos un nodo, utilizando dicha capa de protocolos de recursos de radio 20 para descargar por lo menos un módulo de dicho conjunto de módulos de software operativo para configurar por lo menos en parte dicho por lo menos un terminal de radio reconfigurable,

caracterizado porque,

- dicha entidad servidor y dicha entidad cliente incluyen, respectivamente, por lo menos un conjunto de segundos mensajes de dicha capa de protocolos de recursos de radio, y porque 25

- dicho conjunto de segundos mensajes asociados respectivamente a dicha entidad servidor y a dicha entidad cliente está configurado para gestionar dicho proceso de descarga over-the- air.
2. Una red según la reivindicación 1, que presenta

- una red de acceso de radio y una red básica; y en la que

- dicha capa de protocolos de recursos de radio es una capa de protocolos de dicha red básica. 30
3. Una red según la reivindicación 1, que presenta

- una red de acceso de radio y una red básica; y en la que

- dicha capa de protocolos de recursos de radio es una capa de protocolos de dicha red de acceso de radio.
4. Una red según la reivindicación 3, en la que 35

- dicha red de acceso de radio presenta un controlador de radio; y en la que

- dicha capa de protocolos de recursos de radio es una capa de protocolos de dicho controlador de radio.
5. Una red según la reivindicación 2, en la que dicha red de acceso de radio es operativa de acuerdo con una red de segunda generación.
6. Una red según la reivindicación 2, en la que dicha red de acceso de radio es operativa de acuerdo con 40 una red de tercera generación.
7. Una red según la reivindicación 1, en la que dicha conexión over-the-air inalámbrica se establece por medio de un canal universal de dicha red de comunicación.
8. Una red según la reivindicación 1, en la que dicha conexión over-the-air inalámbrica se establece por medio de un canal de radio de dicha red de comunicación. 45
9. Una red según la reivindicación 1, en la que dicho sistema de comunicación está configurado para gestionar prioridades entre una llamada de voz, una transmisión de datos y la descarga de dicho por lo

menos un módulo de dichos módulos de software operativo.
10. Una red según la reivindicación 1, en la que dichos módulos de software over-the-air están configurados para descargar dicho por lo menos un módulo de dichos módulos de software operativo durante una llamada de voz.
11. Una red según la reivindicación 1, en la que dicho conjunto de módulos de software operativo es 5 adecuado para reconfigurar, por lo menos en parte, dicho terminal de radio con otro sistema de comunicación.
12. Una red según la reivindicación 11, en la que

- dicho terminal de radio presenta una capa de pilas de protocolos para llevar a cabo por lo menos mediciones en dicho otro sistema de comunicación. 10
13. Un procedimiento para configurar por lo menos un terminal de radio reconfigurable perteneciente a una red de comunicación operativa de acuerdo con un sistema de comunicación, presentando dicha red de comunicación una capa de protocolos de recursos de radio que incluye primeros mensajes de una pila de protocolos correspondientes a dicho sistema de comunicación, en el que el por lo menos un terminal de radio reconfigurable está configurado para intercambiar información con por lo menos un 15 nodo de dicha red de comunicación mediante una conexión over-the-air inalámbrica, y dichos primeros mensajes se usan para gestionar dicha conexión over-the-air inalámbrica, constando el procedimiento de los pasos de:

- asociar a dicho por lo menos un nodo de dicha red de comunicación una entidad servidor, configurada para usar dicha capa de protocolos de recursos de radio, e incluyendo un conjunto de módulos de 20 software operativo para implementar por lo menos un conjunto de elementos de dicha pila de protocolos, estando dicha pila de protocolos para reconfigurar dicho por lo menos un terminal de radio reconfigurable;

- asociar a dicho por lo menos un terminal de radio reconfigurable una entidad cliente, configurada para usar una respectiva capa de protocolos de recursos de radio correspondientes a dicha capa de 25 protocolos de dicha entidad servidor;

- establecer un proceso de descarga over-the-air utilizando dicha capa de protocolos de recursos de radio;

- descargar por lo menos un módulo de dicho conjunto de módulos de software operativo desde dicho servidor a dicho por lo menos un terminal de radio reconfigurable para configurar, por lo menos en parte, 30 dicho por lo menos un terminal de radio reconfigurable utilizando dicho proceso de descarga over-the-air;

caracterizado porque dicho establecimiento de un proceso de descarga over-the-air presenta un conjunto de pasos de protocolo que incluye, para cada uno de dichos pasos de protocolo, el intercambio de segundos mensajes de protocolo de dicha capa de protocolos de recursos de radio.
14. Un procedimiento según la reivindicación 13, en el que dicho intercambio de los segundos mensajes 35 de protocolo presenta mensajes de intercambio que incluyen respectivamente

- un conjunto de los siguientes campos,

- un primer campo que identifica el tipo del mensaje,

- un segundo campo que identifica el por lo menos un terminal de radio reconfigurable al que se refiere el mensaje; y 40

- un tercer campo que contiene información de datos.
15. Un procedimiento según la reivindicación 14, en el que dicho conjunto de pasos de protocolo incluye por lo menos uno de los siguientes pasos:

a) realizar una solicitud para descargar dicho por lo menos un módulo de software operativo;

b) autentificar mutuamente dicho cliente y dicho servidor; 45

c) comprobar la capacidad de dicho por lo menos un terminal de radio reconfigurable para aceptar dicho por lo menos un módulo de software operativo descargable de dicho servidor;

d) proporcionar una información relativa a las opciones de descarga;

e) segmentar dicho por lo menos un módulo de software operativo en bloques;

f) transmitir dichos bloques desde dicho servidor al dicho por lo menos un terminal de radio reconfigurable;

g) reensamblar dichos bloques para reconstituir dicho por lo menos un módulo con un conjunto de elementos de una pila de protocolos y probar dicho conjunto de elementos; 5

h) instalar el conjunto de elementos en dicho por lo menos un terminal de radio reconfigurable.
16. Un procedimiento según la reivindicación 15, en el que dicho conjunto de pasos de protocolo incluye el paso de:

- controlar la estructura de dichos bloques descargados a dicho por lo menos un terminal de radio reconfigurable. 10
17. Un procedimiento según la reivindicación 15, en el que dicho conjunto de pasos de protocolo incluye el paso de:

- gestionar un conjunto de temporizadores (T100, T200, T300, T400, T500, T101, T201, T301, T302, T401, T501) que limitan el tiempo autorizado para llevar a cabo el proceso de descarga over-the-air.
18. Un procedimiento según la reivindicación 15, en el que dicho conjunto de pasos de protocolo incluye 15 el paso de:

- asignar a cada paso de protocolo por lo menos un par de temporizadores, un primer temporizador para controlar los pasos de protocolo efectuados por dicho por lo menos un terminal de radio reconfigurable y un segundo temporizador para controlar los pasos de protocolo efectuados por dicho servidor, iniciándose cada uno de dichos temporizadores cuando se empieza un paso de protocolo y 20 deteniéndose cuando se ha llevado a cabo dicho un paso de protocolo.
19. Un procedimiento según la reivindicación 15, en el que el paso de autenticación mutua se basa en un procedimiento "desafío-respuesta".
20. Un procedimiento según la reivindicación 15, en el que dicho paso de segmentar dicho por lo menos un módulo en bloques incluye el paso de segmentar en bloques con un tamaño de entre 1 y 2 kBytes y 25 en el que el paso de transmitir dichos bloques incluye gestionar un protocolo de ventana en el que un tamaño de ventana coincide con el tamaño de los bloques en los que se ha segmentado dicho por lo menos un módulo de software operativo.
21. Un procedimiento según la reivindicación 15, en el que, antes de instalar dicho conjunto de elementos en dicho por lo menos un terminal de radio reconfigurable, se requiere una licencia. 30
22. Un procedimiento según la reivindicación 13, en el que dicho por lo menos un módulo de software operativo, antes de descargarse en dicho por lo menos un terminal de radio reconfigurable, se encripta con una clave.
23. Un procedimiento según la reivindicación 13, que presenta además el paso de almacenar por lo menos dos conjuntos de módulos de software operativo en dicho por lo menos un terminal de radio 35 reconfigurable.
24. Un procedimiento según la reivindicación 13, en el que dicho paso de descargar dicho por lo menos un módulo del conjunto incluye el paso de

- descargar un conjunto de módulos de software operativo adecuados para configurar, por lo menos en parte, dicho por lo menos un terminal de radio reconfigurable con otro sistema de comunicación. 40
25. Un terminal de radio reconfigurable, que presenta medios para llevar a cabo los pasos del procedimiento según una cualquiera de las reivindicaciones de la 13 a la 24.
26. Un nodo de red que presenta una entidad servidor para llevar a cabo los pasos del procedimiento según una cualquiera de las reivindicaciones de la 13 a la 24.
27. Producto de programa informático o conjunto de programas informáticos de productos de programas 45 informáticos que pueden cargarse en la memoria de por lo menos un ordenador y que presentan partes de código de software para llevar a cabo los pasos de cualquiera de las reivindicaciones de la 13 a la 24.