ES2828720T3 - Aparato y procedimiento para implementar políticas de gestión de recursos configurables - Google Patents

Abstract

Un aparato de gestión de recursos de radio (325.335.345.360) adaptado para implementar políticas comunes de gestión de recursos de radio, "CRRM", para la gestión de recursos de radio de un sistema de radiocomunicación (205.210.215.220), dichos recursos de radio son susceptibles de ser asignados a entidades que solicitan servicios de comunicación al sistema de radiocomunicación, el aparato de gestión de recursos de radio comprende: - una interfaz de configuración (405) adaptada para recibir datos de configuración de gestión de recursos de radio de un usuario, donde dichos datos de configuración incluyen una lógica de decisión de gestión de recursos de radio adaptada para especificar una política de gestión de recursos de radio; - un conjunto de implementación de política de gestión de recursos de radio (410) que responde a las solicitudes de servicio de comunicación de las entidades solicitantes y está adaptada para administrar la asignación de los recursos de radio del sistema de radiocomunicación a las entidades solicitantes en función de una lógica de decisión de gestión de recursos de radio, donde dicha interfaz de configuración está adaptada para recibir, y dicho conjunto de implementación de política de gestión de recursos de radio está adaptada para administrar las lógicas de decisión de gestión de recursos de radio estructuradas como un conjunto de una o más reglas de decisión, donde cada regla de decisión comprende: una descripción de al menos una solicitud de servicio de comunicación destinada a regirse por dicha regla de decisión; una descripción del estado del sistema de radiocomunicación respecto al cual se pretende aplicar la regla de decisión; y una acción a tomar por el aparato en caso de que se aplique la regla de decisión, donde: dichos datos de configuración incluyen al menos una tabla de valores, donde al menos una regla de decisión de una lógica de decisión de gestión de recursos de radio recibida a través de la interfaz de configuración incluye referencias a al menos una tabla, donde dicho conjunto de implementación de política de gestión de recursos de radio se adapta para buscar en al menos una tabla en función de las referencias incluidas en al menos una regla de la lógica de decisión de gestión de recursos de radio.

Description

DESCRIPCIÓN

Aparato y procedimiento para implementar políticas de gestión de recursos configurables

Antecedentes de la invención

Campo de la invención

[0001] La presente invención generalmente se refiere a la gestión de recursos de sistema que se asignarán a entidades que soliciten servicios del sistema. En particular, aunque no taxativamente, la invención se refiere a la gestión de recursos, particularmente recursos de radio, en sistemas de radiocomunicaciones como redes de telefonía móvil. Específicamente, la invención se refiere a un aparato para implementar políticas configurables de gestión de recursos.

Descripción de la técnica relacionada

[0002] En el ámbito de las redes de radiocomunicaciones, coexisten varias tecnologías y normas diferentes. Las redes de radiocomunicaciones de segunda generación (las llamadas redes "2G", como las que cumplen con el estándar GSM - Sistema Global de Comunicaciones Móviles, del inglés Global System for Mobile communications), que hoy en día son las más desplegadas, y son en su mayoría adecuadas para habilitar las comunicaciones de voz, estarán en los próximos años cada vez más al lado de redes de radiocomunicaciones de nueva generación, como redes de tercera generación ("3G") (como las que cumplen con el estándar UMTS - Sistema Universal de Telecomunicaciones Móviles, del inglés Universal Mobile Telecommunications System) y redes de cuarta generación (aún en procedimiento de estandarización), diseñadas para soportar, además de comunicaciones de voz simples, intercambio de datos y servicios multimedia (por ejemplo, videotelefonía, radiodifusión televisiva y similares), así como redes de comunicaciones de datos de banda ancha del tipo Wireless LAN (WLAN).

[0003] Una estrategia común en el despliegue de redes no es reemplazar completamente las redes 2G que ya están en funcionamiento con redes de nueva generación, sino integrar los diferentes tipos de redes. La integración entre las redes de radiocomunicaciones de nueva generación y las redes 2G es posible gracias a las nuevas normas de redes, que se definen específicamente de tal manera que permitan la integración de las redes. Por ejemplo, en las especificaciones 3GPP (Proyecto Asociación de Tercera Generación, Third Generation Partnership Project), que establecen las características del UMTS, se definen varios procedimientos que permiten la interoperación ("interworking") con redes GSM (todos los documentos de especificación 3GPP citados en esta descripción se pueden descargar del sitio de internet www.3GPP.org). En particular, en el Informe Técnico 3GPP (TR - Technical Report) 25.881 titulado "Improvement of RRM across RNS and RNS/BSS, Release 5", y en el 3G^p P TR 25.891 titulado "Improvement of ^r R^m across RNS and RNS/BSS, Release 6", los modelos funcionales y las arquitecturas de red se definen donde se pueden aplicar las políticas de Gestión de Recursos Comunes de Radio (CRRM - Common Radio Resource Management).

[0004] Una tendencia conocida del mercado es la de utilizar, en determinadas zonas geográficas denominadas "puntos críticos (hot spots)", tecnologías WLAN, a fin de que los usuarios que se encuentren en esas zonas puedan disfrutar de un acceso de banda ancha a una serie de servicios de comunicaciones de datos como el acceso a internet. Las tecnologías WLAN también pueden integrarse en una red de telefonía móvil, particularmente en el segmento de redes de acceso. Por esta razón, también se están definiendo mecanismos de interoperación que permitan a las tecnologías WLAN (por ejemplo, cumpliendo con la familia de normas IEEE 802.11, o con la norma ETSI conocida como HIPERLAN2) interoperar con redes de telefonía móvil 3G para permitir el acceso a la red de transporte de las mismas. Por ejemplo, el 3G^pP TR 23.934, titulado "3GPP system to Wireless Local Area Network (WLAN) interworking functional and architectural definition, Release 6" especifica los requisitos funcionales que deben cumplir las arquitecturas de red que incluyen los accesos WLAN IEEE 802.11 en la red UMTS. Del mismo modo, el ETSI TR 101.957, titulado "Broadband Radio Access Networks (BRAN): HIPERLAN Type 2; Requirements and architectures for interworking between HIPERLAN/2 and 3rd generation cellular systems", especifica los mecanismos de interoperación de las WLAN HIPERLAN2 con la red UMTS.

[0005] Los sistemas de radiocomunicaciones que integran dos o más Tecnologías de Acceso por Radio se denominan sistemas "multi-RAT".

[0006] Los llamados terminales de telecomunicaciones móviles "multimodo" ya están disponibles en el mercado (como teléfonos celulares, palmtops, asistentes digitales personales (PDA), tarjetas periféricas para ordenadores personales (PC), etc.) que pueden conectarse a redes que cumplen con diferentes normas, como GSM, UMTS, IEEE 802.11b/g/a WLAN. Por ejemplo, los teléfonos móviles de modo dual pueden funcionar tanto en sistemas GSM como en sistemas UMTS.

[0007] En las solicitudes internacionales WO 2005/101880 y WO 2005/101889 se proponen soluciones al problema de las decisiones que debe adoptar la red en cuanto al tipo de acceso de radio que debe asignarse a las solicitudes de servicios entrantes.

[0008] La solicitud de patente publicada en los EE. UU. US 2005/0026616, titulada "Common radio resource management method in a multi-RAT cellular phone network", describe qué información debe intercambiarse entre las diferentes entidades de sistema para permitir una política de CRRM eficiente.

[0009] Generalmente, las políticas de CRRM se implementan mediante algoritmos de CRRM que se ejecutan en equipos de red específicos, como por ejemplo los Controladores de Red de Radio (RNC - Radio Network Controllers) de una red UMTS, o los Controladores de Estación Base (BSC - Radio Network Controllers) de una red GSM, y que, al recibir solicitudes de servicio de los usuarios, las asignan en la mejor reserva de recursos de radiocomunicaciones, dependiendo de una serie de factores como la naturaleza del servicio solicitado, el estado de carga de la red en el momento en que se recibe la solicitud de servicio, los recursos de radio generales disponibles.

[0010] P. Chandra y col, "Darwin: Custornizable Resource Management for Value-Added Network Services, "Network Protocols, 1998, Proceedings Sixth International Conference, 1998, describe un conjunto de mecanismos de gestión de recursos personalizables que apoyan los servicios de valor añadido. D. Casadevall y col., "Overview of the EVEREST Project",13TH IST MOBILE & WIRELESS COMMUNICATIONS SUMMIT 2004, describe estrategias de Gestión de Recursos de Radio (RRM - Radio Resource Management) para cumplir con los requisitos de calidad de servicio (QoS - Quality of Service) previamente acordados, como un concepto de Corredor de Ancho de Banda. Resumen de la invención

[0011] El Solicitante ha observado que cada operador de red puede estar interesado en diseñar sus propios algoritmos de CRRM, implementando políticas de CRRM propias que mejor se adapten a las necesidades y deseos de ese operador de red. Sin embargo, las implementaciones actuales de las políticas de CRRM no permiten o al menos no favorecen este tipo de estrategia.

[0012] De hecho, las normas esencialmente no dicen nada sobre los detalles de implementación de algoritmos de CRRM, por lo que cada fabricante de equipos de red ha desarrollado sus propios algoritmos de CRRM.

[0013] Por lo tanto, actualmente un operador de red que desea definir e implementar algoritmos de CRRM específicos y personalizados tiene que pedir al fabricante del equipo de red que personalice el equipo de red: esto tiene un impacto en los costos del equipo de red. Además, las políticas de CRRM pueden variar en el tiempo, para que se correspondan con los cambios en la configuración de la red o en las solicitudes de servicio provenientes de los usuarios; también en estos casos, el operador de red no puede hacer nada más que pedir al fabricante del equipo de red que actualice los algoritmos de CRRM implementados.

[0014] Por consiguiente, la implementación actual de políticas de CRRM es bastante rígida.

[0015] Así pues, el Solicitante ha abordado el problema de cómo flexibilizar la implementación de las políticas de CRRM, al menos desde el punto de vista del operador de red.

[0016] El Solicitante ha encontrado que, al separar la implementación de hardware/software del equipo de red de los algoritmos de CRRM que tienen que ser implementados y ejecutados por ellos, es posible que el operador de red diseñe e implemente directamente algoritmos de CRRM definidos a la medida, así como modificarlos cuando sea necesario o se desee, sin la necesidad de rediseñar el equipo de red, es decir, sin la necesidad de ninguna intervención del fabricante del equipo de red.

[0017] Esencialmente, la presente invención establece un aparato que, en lo que respecta a las políticas de gestión de recursos, es configurable, por ejemplo, por el operador de red; gracias a la presente invención, el operador de red queda así libre para configurar el equipo que rige el funcionamiento de su sistema (por ejemplo, equipos de red como los BSC, los RNC u otros dispositivos que rigen el funcionamiento de redes de radiocomunicaciones, particularmente de tipo multi-RAT) con el fin de elegir, definir, implementar y, posiblemente, variar, después de la implementación, los algoritmos deseados para administrar los recursos del sistema, por ejemplo, recursos de radio de un sistema multi-RAT, y la política de asignación de dichos recursos de sistema a entidades solicitantes, como usuarios de terminales de comunicaciones móviles.

[0018] Una lógica de decisión estructurada como (un) conjunto(s) de una o más reglas de decisión garantiza un alto grado de flexibilidad. Las reglas de decisión son libremente definibles por el usuario, por ejemplo, el operador de red, simplemente respetando una sintaxis predeterminada. Por lo tanto, es relativamente fácil construir varias lógicas de decisión diferentes, definiendo diferentes reglas, para implementar políticas diferenciadas de gestión de recursos. La invención se define por las reivindicaciones independientes adjuntas. Las reivindicaciones dependientes definen realizaciones preferidas.

Breve descripción de los dibujos

[0019] Las características y las ventajas de la presente invención se harán evidentes mediante la siguiente descripción detallada de una realización de la misma, proporcionada simplemente a modo de ejemplo no limitativo, descripción que se realizará haciendo referencia, para mejor claridad, a los dibujos adjuntos, donde:

La Figura 1 muestra esquemáticamente un escenario ilustrativo donde la presente invención es aplicable;

La Figura 2 muestra esquemáticamente, en términos de bloques funcionales, la estructura de una red de comunicaciones multi-RAT ilustrativa que refleja el escenario de la Figura 1;

La Figura 3 muestra esquemáticamente, aún en términos de bloques funcionales, pero con mayor detalle, una arquitectura de la red multi-RAT de la Figura 2;

La Figura 4A muestra esquemáticamente, en términos de bloques funcionales, una estructura ilustrativa de un sistema según una realización de la presente invención, adaptada para permitir configurar y a continuación implementar algoritmos de CRRM personalizados;

La Figura 4B muestra, en términos de un diagrama de flujo esquemático, las etapas principales de una fase de configuración para configurar un algoritmo de CRRM personalizado, según una realización de la presente invención; La Figura 5 muestra esquemáticamente una tabla ilustrativa de un conjunto de tablas que implementan las reglas de una lógica de decisión de CRRM, en una realización de la presente invención;

La Figura 6 muestra esquemáticamente otra tabla ilustrativa del conjunto de tablas que implementan las reglas de una lógica de decisión de CRRM, en una realización de la presente invención;

La Figura 7 muestra, en términos de un diagrama de flujo esquemático, el flujo principal de funcionamiento del algoritmo de CRRM, en una realización de la presente invención;

La Figura 8 muestra, en términos de un diagrama de flujo esquemático, las etapas principales de una operación incluida en el diagrama de flujo de la Figura 7 de escaneo de la tabla lógica de decisión de CRRM de la Figura 5; Las Figuras 9A y 9B muestran, en términos de un diagrama de flujo esquemático, las etapas principales de una operación incluida en el diagrama de flujo de la Figura 7 de escaneo de la tabla lógica de decisión de CRRM de la Figura 6, en una realización de la presente invención;

La Figura 10 representa un despliegue esquemático de células de un sistema GSM y una red UMTS usadas en un ejemplo proporcionado en la descripción;

La Figura 11 muestra una tabla lógica de decisión de CRRM utilizada en dicho ejemplo.

Descripción detallada de la(s) realización(es) preferida(s) de la invención

[0020] A continuación de la presente descripción, se hará referencia, simplemente a modo de ejemplo no limitativo, a los tipos conocidos actualmente de redes de radiocomunicaciones, a saber, el GSM, el GPRS (General Packet Radio Service - Servicio de Radio de Paquete General), el EDGE (Enhanced Data rate for GSM Evolution -Velocidad de Datos Mejorada para Evolución de GSM), el UMTS (Universal Mobile Telecommunications System -Sistema Universal de Telecomunicaciones Móviles), la WLAN, y a los algoritmos de CRRM que se utilizan para la interoperación y la cooperación de dichas redes. Sin embargo, se apreciará que la presente invención tiene una aplicabilidad más general.

[0021] Según la presente invención, los aparatos que implementan políticas de gestión de recursos se adaptan para permitir la definición de categorías de recursos que deben ser administradas; tales categorías se denominarán en lo sucesivo "reservas" de recursos. En general, para los fines de la presente invención, una reserva de recursos es un conjunto de uno o más recursos pertenecientes al sistema considerado, que pueden tener propiedades homogéneas (la propiedad o propiedades específicas pueden variar según las necesidades del operador de red), o simplemente que, por alguna razón, el operador de red desea considerar como homogéneos

[0022] En el ejemplo considerado en la presente descripción, se identifican las siguientes reservas de recursos de red (radio) (esta subdivisión en categorías es meramente ilustrativa: se pueden considerar diferentes subdivisiones):

- recursos de radio pertenecientes a los diferentes RAT, por ejemplo, recursos de radio GERAN (GPRS/EDGE Radio Access Network), recursos de radio UTRAN (UMTS Terrestrial Radio Access Network), recursos de radio BRAN (Broadband Radio Access Network)/ WLAN;

- recursos de radio pertenecientes a diferentes estructuras celulares jerárquicas (HCS - Hierarchical Cellular Structures), como por ejemplo una capa macrocelular y una capa microcelular que comparten una misma portadora dentro de UTRAN;

- recursos de radio pertenecientes a diferentes capas de frecuencia (por ejemplo, las capas de 900 MHz y 1800 MHz en GSM); y

- recursos de radio UTRAN basados en diferentes modalidades y técnicas, como por ejemplo recursos de radio de UTRAN según la versión 99 de la norma, y recursos de radio basados en la Versión 5 de HSDPA (High Speed Downlink Packet Access).

[0023] Para cada una de las reservas de recursos ilustrativas enumeradas anteriormente, las normas definen mecanismos de interacción específicos que permiten la gestión integrada de los mismos; ejemplos de tales mecanismos son:

- mecanismos de camping inter-RAT o inter-frecuencia, que se implementan a nivel de terminal de radiocomunicaciones y que permiten al terminal seleccionar inicialmente una célula entre las pertenecientes a diferentes RAT o diferentes frecuencias (estos mecanismos se especifican, por ejemplo, en el 3GPP TS 25.304); - mecanismos de reselección de células entre RAT o entre frecuencias, que se implementan a nivel de terminal de radiocomunicaciones y que permiten al terminal seleccionar una célula de las pertenecientes a diferentes RAT o diferentes frecuencias (como se especifica en el citado 3GPP TS 25.304);

- mecanismos de reintento dirigidos inter-RAT, que se refieren a un procedimiento controlado por la red para mover los canales de señalización utilizados por un usuario genérico de la red GSM a la red UMTS, o viceversa (como se especifica en el 3GPP TS 25.331);

- mecanismos de transferencia inter-RAT, que se refieren a un procedimiento controlado por la red para mover una llamada de un usuario genérico de la red GSM a la red UMTS, o viceversa (como se especifica en el citado 3GPP TS 25.331);

- mecanismos comunes de medición, que se refieren a un procedimiento para el intercambio de valores de carga de célula entre el RNC y el BSC (como se especifica en el 3GPP TS 25.423);

- mecanismos de reintento dirigidos entre frecuencias, que se refieren a un procedimiento controlado por la red para mover los canales de señalización utilizados por un usuario genérico de una frecuencia de la UTRAN a otra frecuencia UTRAN diferente (como se especifica en el 3GPP TS 25.331); y

- mecanismos de transferencia entre frecuencias, que se refieren a un procedimiento controlado por la red para mover una llamada de un usuario genérico de una frecuencia UTRAN a otra frecuencia UTRAN (como se especifica en el 3GPP TS25.331).

[0024] Entre los algoritmos de CRRM que se dirigen a la gestión conjunta y sinérgica de los recursos de radio pertenecientes a diferentes reservas de recursos, como las reservas de recursos enumeradas anteriormente, son particularmente importantes aquellos algoritmos que asignan tráfico en función de las solicitudes de servicio de los usuarios. Estos algoritmos permiten que el tráfico de red se dirija a diferentes reservas de recursos, dependiendo de las preferencias del operador de red (reducción de costos, aumento de la calidad del servicio percibido por los usuarios, maximización de ingresos, etc.).

[0025] La Figura 1 ilustra un escenario posible donde se puede aplicar la presente invención. Se supone que un área geográfica de interés, denominada 105, es atendida por una red GSM; se supone que una porción 110 del área 105 también está servida por una red UMTS (por lo tanto, el área 110 está servida tanto por la red GSM como por la red UMTS); en una porción 115 del área 110, también se asume que existe cobertura por una red WLAN. Este escenario, aunque no limitativo para la presente invención, es bastante fiel a la realidad, porque supone que las redes GSM (u otras redes 2G), hoy en día ampliamente difundidas, en algunas áreas (por ejemplo, en áreas urbanas o a lo largo de autopistas) trabajan codo a codo con las redes UMTS (u otras redes 3G), que actualmente no están tan ampliamente desplegadas como las redes 2G, y además que, en porciones limitadas del territorio (por ejemplo, dentro de hoteles o estaciones de servicio a lo largo de las autopistas), hay puntos críticos WLAN que permiten una conexión de banda ancha a, por ejemplo, internet (el hecho de que, en el escenario considerado, los puntos críticos 115 están contenidos dentro del área 110 cubierta por el UMTS no debe considerarse limitativo, pero es, sin embargo una suposición razonable, porque los puntos críticos WLAN generalmente se colocan en áreas caracterizadas por una alta concentración de usuarios con baja movilidad que requieren servicios de comunicaciones de datos de banda ancha).

[0026] La Figura 2 muestra esquemáticamente, en términos de bloques funcionales, la estructura de una red de comunicaciones multi-RAT ilustrativa que refleja el escenario de la Figura 1. La red multi-RAT comprende en particular un GERAN 205, utilizado por terminales Gs M/GPRS/EDGE para acceder a la red, un UTRAN 210, utilizado por terminales UMTS para acceder a la red, y un BRAN 215 utilizado por terminales WLAN para acceder a la red. Una red central 3G 220 forma el segmento de transporte de la red multi-RAT.

[0027] La arquitectura de red en la Figura 2 se muestra con mayor detalle en la Figura 3; la red central 220 está conectada al GERAN 205 a través de una interfaz 305, por ejemplo, la interfaz llamada interfaz "A" o interfaz "Gb", dependiendo del dominio de red central, al UTRAN 210 a través de una interfaz 310, por ejemplo, correspondiente a la interfaz "/u", y al BRAN 215 a través de una interfaz 315 (por ejemplo, la interfaz a veces denominada interfaz "tipo lu").

[0028] El GERAN 205 comprende, de una manera conocida per-se en la técnica, subsistemas de estación base (BSS - Base Station Subsystems), que incluyen estaciones transceptoras base (BTS - Base Transceiver Stations) 320 y BSC 325. El UTRAN comprende, también de una manera conocida per-se en la técnica, subsistemas de red de radio (RNS - Radio Network Subsystems), que incluyen los nodos B 330 y RNC 335. El BRAN 215 comprende, aún de una manera conocida per-se en la técnica, puntos de acceso (AP - Access Points) 340 y controladores de puntos de acceso (APC - Access Points Controllers) 345.

[0029] Los BSC 325, los RNC 335 y los APC 345 pueden intercambiar información a través de la red central 220 o, cuando se proporcionan interfaces adecuadas 350 (correspondientes a la interfaz "lur-g") y 355 (también denominada interfaz "tipo lur"), pueden comunicarse directamente entre sí.

[0030] Algoritmos de CRRM pueden, por ejemplo, residir y ejecutarse mediante los BSC 325, los RNC 335 y los APC 345. Alternativamente, se puede proporcionar una entidad de red, denominada 360 en el dibujo y en lo sucesivo denominada "servidor de CRRM", dedicada a la gestión común e integrada de los recursos de la red multi-RAT. El servidor de CRRM 360 puede conectarse a los BSC 325 a través de una interfaz 365, a los RNC 335 a través de una interfaz 370 y a los APC a través de una interfaz 375. El servidor de CRRM 360 puede solicitar a los BSC 325 información sobre el estado de las células de red GSM, así como también puede solicitar a los RNC 335 información sobre el estado de las células de la red UMTS; de manera similar, el servidor de CRRM puede solicitar a los APC 345 información sobre el estado de los puntos críticos de WLAN.

[0031] En función de la naturaleza específica, cualquier servicio soportado por la red multi-RAT puede asignarse en una o más redes de acceso de radio; por ejemplo, se puede ofrecer un servicio de comunicación de voz a través del GSM o la red UMTS, mientras que un servicio de intercambio de datos específico (por ejemplo, una videollamada) solo se puede proporcionar a través de la red UMTS o la WLAN. Los algoritmos de CRRM que se ejecutan en los BSC 325, los R ⁿ C 335 y los APC 345, o, alternativamente, en el servidor de CRRM 360 determinan, en función del estado actual de la red, si aceptar o no las solicitudes de servicio de los usuarios, y qué red de acceso de radio usar para proporcionar el servicio, si este último es aceptado.

[0032] Según una realización de la presente invención, un operador de red puede, sin rediseñar los BSC 325, los RNC 335 y los APC 345, o, alternativamente, del servidor de CRRM 360, configurar estos aparatos de red para que implementen algoritmos de CRRM definidos a la medida. A continuación se describirán en detalle realizaciones no limitativas de la invención.

[0033] Las normas existentes prescriben que, para cada célula de las redes GSM y UMTS, es posible definir diferentes tipos de listas de células adyacentes; estas listas se utilizan típicamente en una fase de configuración de las mediciones de radio que los terminales de comunicaciones móviles pueden realizar, por ejemplo, para evaluar la oportunidad de pasar de una célula a otra con el fin de obtener una mejor cobertura (ver, por ejemplo, 3GPP TS 25.215).

[0034] Por ejemplo, según el 3GPP TS 25.331, a cada célula de la UTRAN se asocian las siguientes listas de adyacencia:

- lista de adyacencias intra-frecuencia, es decir, la lista de las células de la UTRAN que son adyacentes a la célula UTRAN considerada y que usan la misma frecuencia portadora;

- lista de adyacencias inter-frecuencias, es decir, la lista de las células de la UTRAN que son adyacentes a la célula UTRAN considerada y que utilizan diferentes frecuencias portadoras;

- lista de adyacencias GSM inter-RAT, es decir, la lista de las células de la red GSM (GERAN) que son adyacentes a la célula UTRAN considerada.

[0035] Según el 3GPP TS 04.18, a cada célula del GSM (GERAN) se asocian las siguientes listas de adyacencia:

- lista de células vecinas GSM, que contiene la lista de células de la red GSM (GERAN) adyacente a la célula GSM (GERAN) a la que está acampado el terminal móvil;

- lista de células vecinas 3G, que contiene una lista de células de la red UMTS adyacente a la célula GSM (GERAN) a la que está acampado el terminal móvil.

[0036] La especificación 3GPP (3GPP TS 25.214) prescribe que el terminal móvil mide la calidad de radio de la señal piloto transmitida por las células que están adyacentes a la célula a la que está acampado el terminal.

[0037] Las especificaciones 3GPP también establecen varias realizaciones para hacer que los BSC y los RNC conozcan las características funcionales de los terminales móviles (denominadas "capacidades de terminal").

[0038] Por ejemplo, la red UMTS puede obtener las características funcionales del terminal cuando se configura la conexión RRC (Radio Resource Control): cuando un terminal establece la conexión con la red, se puede crear un contexto de usuario dentro del RNC, donde se almacena la información relacionada con las capacidades del terminal.

[0039] En el GERAN, la solicitud de las capacidades de terminal puede realizarse mediante un mensaje llamado "CLASS- MARK ENQUIRY (CONSULTA DE MARCA DE CLASE)" (como se especifica en el 3GPP TS 04.18); en el caso de un terminal multi-RAT, el terminal móvil proporciona al GERAN también las capacidades relacionadas con el UTRAN.

[0040] Los algoritmos de CRRM pueden utilizar la información anterior para tomar las decisiones más apropiadas según las capacidades del terminal. Las reservas de recursos que un terminal puede utilizar, de hecho, dependen tanto de la cobertura de radio como de las capacidades del terminal.

[0041] Una estructura de un aparato según una realización de la presente invención que está configurada para implementar un algoritmo de CRRM definido a medida se representa esquemáticamente en la Figura 4A en términos de módulos funcionales; el aparato puede ser, por ejemplo, el servidor de CRRM 360, o los BSC 325, los RNC 335, los APC 345 y, en general, cualquier equipo de red destinado a implementar políticas de CRRM; los módulos funcionales representados pueden ser, por ejemplo, módulos de software de un software instalado y ejecutado por el equipo de red que está destinado a implementar las políticas de CRMM. El aparato de implementación de políticas CRRM configurable comprende un módulo de configuración de algoritmo de CRRM 405 y un módulo de implementación de algoritmo de CRRM 410. El módulo de configuración 405 incluye un módulo de configuración de servicios 415, un módulo de configuración de reservas de recursos 420, una lista de células en el módulo de configuración de superposición 425, un módulo 430 para la definición de criterios de medición que se utilizarán en la definición de las reservas de recursos disponibles, un módulo 435 para la definición del modo de determinación (elección) de reservas alternativas de recursos, un módulo 440 para la definición de contadores de eventos 455, un módulo 445 para la definición de tablas de búsqueda 460, un módulo 450 para la definición de una lógica de decisión CRRM; la lógica de decisión, en una realización de la presente invención (descrita en detalle más adelante) puede adoptar la forma de un conjunto (por ejemplo, uno o más) de tablas 465, cuyo ejemplo se describirá más adelante. El módulo de implementación de algoritmo de CRRM 410 incluye los contadores 455, las tablas de búsqueda 460, la lógica de decisión CRRM, por ejemplo implementada como el conjunto de tablas 465, y un módulo de escáner de tablas lógicas de decisión CRRM 470, adaptado para escanear el conjunto lógico de decisión CRRM de tablas 465 en respuesta a eventos correspondientes a solicitudes de servicio recibidas. También se proporciona un módulo de actualización del contador de eventos 475, adaptado para actualizar selectivamente los contadores de eventos 455 en función de los eventos recibidos. Según la presente invención, el módulo de configuración de algoritmo de CRRM 405, particularmente el módulo 450 para la definición de una lógica de decisión CRRM, y el módulo de implementación de algoritmo de CRRM 410, particularmente el módulo de escáner de tablas lógicas de decisión CRRM 470, están estructurados de tal manera que administran lógicas de decisión que se estructuran como conjuntos de una o más reglas de decisión que tienen una estructura homogénea, como se describirá con mayor detalle en lo siguiente.

[0042] Las funciones de los módulos mostrados en la Figura 4A se explicarán a continuación en relación con la descripción del funcionamiento del aparato configurable de implementación de políticas de CRRM.

[0043] Según una realización de la presente invención, para configurar el equipo de red con el fin de implementar un algoritmo de CRRM deseado, se lleva a cabo un procedimiento de configuración. Las etapas principales del procedimiento de configuración según la realización ilustrativa de la invención considerada en esta invención se representan en el diagrama de flujo esquemático de la Figura 4B, y se describirán en detalle en lo siguiente.

- Fase de configuración: definición de los servicios

[0044] En esta etapa (bloque 490), el operador de red (o, en general, cualquier persona a quien, en nombre del operador de red, se le confíe la tarea de definir las políticas de CRRM a implementar) define qué solicitudes de servicio deben ser consideradas y gestionadas por el algoritmo de CRRM a implementar. Esto se puede hacer, por ejemplo, asociando un identificador único a cada servicio que el operador de red desea que sea gestionado por el algoritmo de CRRM. Por ejemplo, en caso de que el algoritmo de CRRM tenga que permitir la interoperación entre sistemas 2G y 3G, por ejemplo, la interoperación entre GERAN y UTRAN, los servicios que serán administrados por el algoritmo de CRRM deben ser identificados, a nivel de BSC y RNC, por los mismos identificadores de servicio correspondientes.

[0045] Desde el lado BSC, un servicio en el dominio de conmutación de paquetes (PS) puede identificarse, por ejemplo, mediante los parámetros de calidad de servicio (QoS) definidos en la versión 99 de las especificaciones 3GPP; con referencia al 3GPP TS 23.107, estos parámetros de QoS incluyen, por ejemplo, un parámetro de clase de tráfico, un parámetro de Velocidad de bits máxima, y así sucesivamente. Estos parámetros de QoS están asociados con la solicitud de configuración de contexto PDP (Packet Data Protocol) (como saben los expertos en la materia, un contexto PDP es una asociación lógica que se crea entre un terminal móvil y una red de datos basada en paquetes que se ejecuta a través de la red GPRS o UMTS y define aspectos como enrutamiento, facturación, seguridad, etc.). Los contextos PDP que tienen un perfil de QoS igual o similar pueden agruparse en un mismo PFC (Packet Flow Context - Contexto de Flujo de Paquetes). En la versión 99 del estándar GPRS, un SGSN (Serving GPRS Support Node, una de las entidades del sistema GPRS) puede proporcionar al BSS (Sistema de Estación Base, compuesto por un BSC y por los BTS que están controlados por dicho BSC) información relacionada con la transmisión de datos del usuario en curso en términos de un BSS PFC. Estos se utilizan para describir las características de QoS para la transmisión de datos para los terminales móviles, y se identifican en términos de su PFI (Packet Flow Identity -Identidad de Flujo de Paquetes).

[0046] Los parámetros de QoS asociados con cada PFC se comunican a continuación al BSC en forma agregada (ABQP - Parámetros de QoS de BSS agregados), como se ejemplifica en la siguiente tabla:

que es un ejemplo de los valores de los ABQP para un servicio de streaming a través de GPRS/EGPRS (G B R ^{d l} y G B R ^{u l} representan la Tasa de Bits Garantizada en enlace descendente y enlace ascendente, respectivamente).

[0047] Cada PFC es identificado por la PFI; según una realización de la presente invención, la definición de qué servicios pretende gestionar el algoritmo de CRRM en el BSC puede realizarse explotando la PFI, por ejemplo, mapeando las PFI en identificadores únicos de los servicios, para ser utilizados por el algoritmo de CRRM que se está configurando; la tabla a continuación proporciona un ejemplo de definición de los servicios mediante la asignación de los respectivos identificadores únicos (IDs^1) a las PFI.

[0048] Desde el lado RNC, una solicitud de servicio se traduce en una solicitud correspondiente para configurar un portador de acceso de radio (RAB) con una QoS específica. Por lo tanto, los diferentes servicios se pueden identificar de forma unívoca, por ejemplo, teniendo en cuenta los siguientes parámetros asociados con el perfil de QoS de RAB:

{<class>, <transferDelay>, <UL_guaranteedBitRate>, <UL_maximumBitRate>, <DL_guaranteedBitRate>, <DL_maximumBitRate>}

que están asociados con el servicio solicitado y representan respectivamente la clase de tráfico (que puede ser conversacional, streaming, interactivo o en segundo plano), el retraso máximo de transferencia de los paquetes de datos, la tasa de bits promedio que se garantizará en enlace ascendente y descendente, la tasa de bits máxima en enlace ascendente y descendente. La siguiente tabla proporciona un ejemplo de definición de los identificadores únicos de los servicios (IDs^1) en RNC, basado en los parámetros RAB:

[0049] Cabe destacar que se pueden usar identificadores iguales o diferentes para servicios similares en BSC y en RNC. El identificador debe ser único en la tabla que hace referencia a BSC y en la tabla que hace referencia a RNC. En las tablas ilustrativas anteriores, por ejemplo, en cada tabla no hay identificadores replicados, pero en ambas tablas el servicio de voz se identifica mediante IDs=1.

- Fase de configuración: definición de reservas de recursos para los CNR y los CSB

[0050] En esta etapa (bloque 491), el operador de red define, para cada RNC y cada BSC, entidades denominadas "reservas de recursos". Como se mencionó anteriormente, en general, para los fines de la presente invención, una reserva de recursos es un conjunto de uno o más recursos pertenecientes al sistema considerado, que pueden tener propiedades homogéneas (la propiedad o propiedades específicas pueden variar según las necesidades del operador de red), o simplemente que, por alguna razón, el operador de red desea considerar como homogéneo. En lo anterior se proporcionan ejemplos de reservas de recursos que pueden definirse en el caso considerado en esta invención de una red de telefonía móvil multi-RAT. Según una realización de la presente invención, una reserva de recursos se caracteriza por una lista de células que están asociadas con esta (como suposición de trabajo, se asume que cada célula en la lista de células asociadas con la reserva de recursos pertenece a una sola reserva, pero esto no debe considerarse limitativo).

[0051] La definición del número de reservas de recursos y de las células asociadas a cada reserva de recursos es realizada por el operador de red, y es susceptible de ser modificada. En esta etapa de la fase de configuración, el operador de red define el número N^p de reservas de recursos para el algoritmo de CRRM específico que se está configurando, con 1 < N^p. En la tabla a continuación se ofrece un ejemplo de definición de reservas comunes de recursos:

- Fase de configuración: definición de solapamientos entre células

[0052] En esta etapa (bloque 492), el operador de red define, para cada célula, qué otras células, que pertenecen a reservas de recursos diferentes de aquella a la que pertenece la célula considerada, se solapan con la célula considerada. Como se mencionó en lo anterior, las especificaciones 3GPP ya permiten asociar a cada célula diferentes listas de células adyacentes (por ejemplo, intra-frecuencia, inter-frecuencia, adyacencia inter-RAT). Estas listas son utilizadas normalmente por la red para gestionar la movilidad de los usuarios y para garantizar la continuidad de los servicios cuando un usuario se mueve. Según una realización de la presente invención, se define una información más específica, para ser explotada por el algoritmo de CRRM, que consiste en las listas de superposiciones definidas en esta fase de configuración, que especifican qué células, pertenecientes a diferentes reservas de recursos, cubren un área común o porción de área: los usuarios que están ubicados en áreas atendidas por diferentes células pueden, por ejemplo, utilizar cualquiera de las reservas de recursos disponibles. Basándose en la definición de los solapamientos de las células, el algoritmo de CRRM puede elegir, entre las diferentes alternativas posibles, la reserva de recursos que permitan optimizar el funcionamiento de la red.

[0053] La siguiente tabla proporciona un ejemplo de definición de solapamientos entre las células:

- Fase de configuración: definición de los criterios de medición

[0054] De manera similar a lo previsto por las especificaciones (3GPP TS 25.331 y TS 05.08) con respecto a las células adyacentes, en esta etapa (bloque 493), el operador de red define, célula por célula y dependiendo de las capacidades de los terminales móviles, qué mediciones deben realizarse por los terminales móviles en las células superpuestas con la célula considerada.

- Fase de configuración: definición del modo de determinación de las reservas alternativas de recursos

[0055] En esta etapa (bloque 494), el operador de red define, para cada célula, la modalidad mediante la cual se realiza la determinación (elección) de las posibles reservas alternativas de recursos. En particular, según una realización de la presente invención, se puede definir cualquiera de dos modos: un modo "ciego" y un modo "basado en mediciones". En el modo "ciego", cuando se solicita un servicio a través de una determinada célula, las alternativas para la selección de la reserva de recursos más apropiada se determinan de manera única a partir de la lista de células que se solapan con la célula considerada. En el modo "basado en mediciones", los terminales móviles realizan mediciones en las células adyacentes y proporcionan los resultados de las mediciones a la red; por lo tanto, cuando se solicita un servicio a una determinada célula, las alternativas para la selección de la reserva de recursos más apropiada se determinan a partir de la lista de células que se solapan con la célula considerada, teniendo en cuenta solo las células que son adecuadas desde un punto de vista de cobertura de radio (según la medición realizada por el terminal móvil).

[0056] En particular, en una realización de la presente invención, la definición del modo de determinación de las reservas alternativas de recursos se realiza célula por célula; la tabla a continuación ofrece un ejemplo de definición:

- Fase de configuración: definición de contadores de eventos

[0057] En esta etapa (bloque 495), el operador de red puede definir uno o más contadores de eventos correspondientes a solicitudes de servicio; contar los eventos es útil para el algoritmo de CRRM para tomar la decisión más apropiada.

[0058] según una realización de la presente invención, un evento genérico, correspondiente a una solicitud de servicio, puede caracterizarse, dentro de la red, por un número n de parámetros que comprenden, por ejemplo, los siguientes elementos:

continuación

[0059] La siguiente tabla proporciona un ejemplo de evento, bajo el supuesto de que Np = 4, que una nueva solicitud de servicio (es decir, no una entrega) se recibe a través de una célula que pertenece a la reserva de recursos IDp = 1, y que la red evalúa que la solicitud de servicio puede ser satisfecha también por las reservas de recursos IDp = 3 e IDp = 4, pero no por la reserva de recursos IDp = 2:

[0060] Sea N^c el número de contadores de eventos distintos definidos por el operador de red, esto es 0 < N^c.

[0061] Según una realización de la presente invención, el contador de eventos genérico puede definirse como de tipo entero o de tipo real.

[0062] Cada contador de eventos de tipo entero está asociado con un evento correspondiente: la ocurrencia de dicho evento hace que el valor del contador se incremente.

[0063] Los contadores de tipo real se definen como la relación de dos contadores de tipo entero, especificada por el operador de red; por lo tanto, cada contador de eventos de tipo real se ha asociado con dos contadores de tipo entero, uno para el numerador y el otro para el denominador.

[0064] Para cada contador definido por el operador de red, la red realiza un seguimiento de los valores del contador para cada célula (es decir, un contador de eventos genérico tiene múltiples instancias, una por cada célula), y cada contador de eventos en una célula se incrementa solo para eventos relacionados con esa célula.

[0065] El contador genérico, ya sea de tipo entero o de tipo real, se identifica mediante un identificador de contador respectivo ID^c, donde ID^c s 1 e ID^c < N^c.

[0066] Dado que el mismo ID^c se refiere a muchos contadores (uno para cada célula), los contadores se referenciarán de la siguiente manera:

____________

[0067] Cabe señalar que el contador de eventos asociado con una reserva de recursos (segunda fila de la tabla anterior) debe interpretarse como una notación compacta para representar cada una de las instancias del contador de eventos asociado a las células pertenecientes a la reserva de recursos; en otras palabras, no es un contador único asociado a todas las células de la reserva de recursos, sino que es una pluralidad de contadores.

[0068] Se definen dos tipos de contadores: contadores de tipo entero y contadores de tipo real.

[0069] En particular, los contadores de tipo entero se definen como se ejemplifica en la siguiente tabla:

[0070] Se observa que el campo origen del evento no se toma explícitamente en consideración porque, como se mencionó anteriormente, cada contador de eventos en una célula se incrementa solo para eventos relacionados con esa célula.

[0071] En la definición de un contador de eventos, cualquier campo de la descripción del evento puede reemplazarse por un comodín, por ejemplo, un "*", para especificar que el campo puede tomar cualquier valor.

[0072] Un contador de eventos genérico también puede estar asociado con dos o más eventos diferentes (en tal caso, en la tabla ilustrativa anterior, se proporcionarán dos o más filas para ese contador, donde cada fila especifica un evento diferente que hace que el valor del contador se altere, particularmente se incremente). De manera similar, un mismo evento puede estar asociado con dos o más contadores diferentes.

[0073] El operador de red puede especificar contadores de tipo real, como en la siguiente tabla ilustrativa:

[0074] Cabe señalar que cada contador con un identificador específico ID^c puede ser entero o real, no tanto entero como real al mismo tiempo; en otras palabras, esto significa que el mismo identificador no puede estar presente en ambas tablas (contadores enteros y contadores reales) al mismo tiempo.

[0075] A modo de ejemplo, las siguientes dos tablas se utilizan para definir tres contadores (N^c = 3); la primera tabla define dos contadores de tipo entero con identificador ID^c = 1 e ID^c = 2 (el primer contador se incrementa cada vez que se produce una solicitud de servicio con ID^s = 2 o ID^s=8, mientras que el segundo contador se incrementa cada vez que se produce una solicitud de servicio con ID^s = 5) y la segunda tabla define un contador de tipo real con identificador ID^c = 3 como la relación entre el primero (ID^c=1) y el segundo contador (ID^c=2),

- Fase de configuración: definición de tablas de búsqueda

[0076] En esta etapa (bloque 496), el operador de red puede definir una o más tablas de búsqueda, en cada una de las cuales un número predeterminado (por ejemplo, 256) de, por ejemplo, valores reales se puede insertar. La tabla de búsqueda genérica se identifica con un identificador único IDⁱ, con 1 < IDⁱ < Nⁱ donde Nⁱ es el número de tablas de búsqueda definidas por el operador de red; el elemento genérico de la tabla de búsqueda genérica se identifica mediante un índicej (con, en el ejemplo considerado, 0<j<255).

[0077] La tabla a continuación proporciona un ejemplo de una tabla de búsqueda que puede definirse según una realización de la presente invención:

[0078] Las tablas de búsqueda pueden ser utilizadas por el algoritmo de CRRM en el procedimiento de decidir qué recurso se dedica a satisfacer una solicitud de servicio, como se describirá con mayor detalle más adelante. Se puede acceder a una tabla de búsqueda genérica con IDⁱ = i mediante la siguiente invocación:

búsqueda[i,j] donde i y j son números enteros o reales (en este último caso, están truncados). Si no se han definido tablas de búsqueda, la invocación devuelve 0,0. Si i < 1, se accede a la tabla de búsqueda con IDⁱ = 1; si i > Nⁱ, se considera la tabla de búsqueda con IDⁱ = N. Si j < 0, se considera el elemento de tabla de búsqueda en la posición 0; si j > 255, se considera el elemento en la posición 255.

- Fase de configuración: definición de la lógica de decisión (política) de CRRM

[0079] En esta etapa (bloque 497), el operador de red define la lógica de decisión del algoritmo de CRRM a implementar.

[0080] Según la presente invención, para permitir la configurabilidad flexible de las políticas de CRRM que los aparatos tienen que implementar, se gestiona la lógica de decisión estructurada como conjuntos de una o más reglas de decisión. El operador de red puede definir libremente las reglas de decisión, siempre que se respete una sintaxis predeterminada; como se describe en detalle a continuación, la sintaxis de la regla de decisión es tal que la regla de decisión genérica incluye:

- una descripción de uno o más eventos, es decir, una o más solicitudes de servicios a las que se pretende aplicar la regla de decisión;

- una descripción del estado del sistema, por ejemplo de la red,

- una acción que debe llevarse a cabo en caso de que se cumpla la regla.

[0081] La aplicación de la lógica de decisión requiere la comprobación de las reglas de decisión, basada en una comparación entre una descripción de una solicitud de servicio recibida y las descripciones de las solicitudes de servicio especificadas en las reglas de decisión, y una comparación entre una descripción del estado actual del sistema en el momento en que se recibe la solicitud de servicio y las descripciones del estado del sistema incluidas en las reglas de decisión.

[0082] Los controladores de recursos de radio, es decir, los BSC y los RNC, además del conocimiento completo del estado de carga de las células que gestionan directamente, también pueden recibir indicaciones sobre el estado de carga de las células pertenecientes al RAT alternativo. Según las especificaciones 3GPP (3GPP TS 25.423), el intercambio de valores de carga de células entre los RNC y los BSC puede tener lugar explotando un procedimiento llamado "Mediciones Comunes" (a través de la interfaz lur-g, si se proporciona, o a través de la interfaz A y la interfaz lu con la red central; en este último caso, la red central transfiere de manera transparente la información que intercambian UTRAN y GERAN).

[0083] En un sistema multi-RAT, GERAN/UTRAN, las cantidades que los RNC y los BSC pueden intercambiar están relacionadas con la carga de las células. Las especificaciones establecen la posibilidad de que un parámetro llamado "Carga de Célula" se estime independientemente para el enlace ascendente y el enlace descendente (posiblemente, el tráfico en tiempo real - "Carga RT" - y el tráfico en tiempo no real - "Carga NRT" - pueden tratarse de forma independiente). En particular, el valor para la Carga Celular puede variar de 0 a 100, definido como el porcentaje de la carga total soportada por la célula genérica en el instante genérico con respecto a la capacidad celular máxima planificada. Mediante este convenio, la Carga Celular es un parámetro independiente del RAT específico, por lo que puede utilizarse en un entorno multiproveedor y/o multi-RAT (en este último caso, se respetarán las equivalencias adecuadas entre los diferentes RAT, teniendo en cuenta las proporciones en términos de recursos de radio disponibles y capacidad de las diferentes redes de acceso de radio).

[0084] En particular, el valor para la Carga RT puede variar de 0 a 100, definido como el porcentaje de la carga generada por el tráfico asociado con los servicios en tiempo real con respecto a la máxima capacidad celular planificada; la Carga NRT indica en su lugar la carga celular generada por el tráfico asociado con los servicios en tiempo no real, y puede, por ejemplo, tomar valores "bajo", "medio", "alto" y "sobrecargado".

[0085] Los valores de los parámetros de carga celular son dinámicos, por lo tanto, para un correcto funcionamiento de los algoritmos de CRRM, las mediciones necesarias para calcularlos se repiten con una periodicidad adecuada.

[0086] En otras palabras, el estado de la red generalmente no es conocido de manera transparente por todos los equipos de la red; por ejemplo, un RNC solo tiene un conocimiento parcial del estado de carga de las células no controladas directamente por él: un BSC/RNC tiene un conocimiento completo del estado de carga de las células que controla, pero en lo que respecta a las células controladas por otras BSC/RNC, su conocimiento puede limitarse a la carga celular.

[0087] según una realización de la presente invención, el estado de la red se expresa mediante un conjunto de variables de estado, como se especifica en la tabla a continuación:

[0088] Cabe señalar que las variables asociadas a una reserva de recursos (las últimas tres filas de la tabla anterior, es decir, RTLU[reserva=/D^p ], RTLD[reserva=/D^p ] y N[reserva=/D^p ,/D^s]) deben interpretarse como una notación compacta para representar instancias individuales de las variables de estado, una para cada célula que pertenece a la reserva de recursos; no son variables globales asociadas a todas las células de la reserva de recursos, como se describirá con mayor detalle más adelante.

[0089] Dado que, como se mencionó, un BSC/RNC puede no tener visibilidad completa del estado de las células controladas por diferentes BSC/RNC, considerados los BSC/RNC genéricos, no todas las variables de estado definidas anteriormente tendrán en general un valor atribuido a las mismas; la situación que se encuentra en general en el BSC/RNC X genérico se da en la tabla a continuación:

[0090] Según una realización de la presente invención, la lógica de decisión del algoritmo de CRRM que se implementará se expresa en forma de un conjunto de tablas 465, donde cada entrada de tabla corresponde a una regla de decisión, que a su vez corresponde a una determinada acción de CRRM que se debe tomar cuando se aplica una combinación respectiva de evento, valores de contador, estado de red.

[0091] Cada tabla del conjunto de tablas se identifica a través de un identificador ID de tabla respectiva^ donde 1< IDt <Nt, siendo Nt el número de las tablas.

[0092] En particular, según una realización de la presente invención, el conjunto de tablas que expresan la lógica de decisión del algoritmo de CRRM incluye dos tipos diferentes de tablas: un primer tipo de tablas se denomina "tabla para células", y un segundo tipo de tablas se denomina "tabla para reservas".Se utiliza una "tabla para células" para especificar las reglas de CRRM a nivel de las células individuales, mientras que una "tabla para reservas" se utiliza para especificar reglas de CRRM más generales para las cuales es suficiente considerar reservas de recursos, no siendo necesario considerar las células individuales. Por ejemplo, para implementar una regla de CRRM del tipo "todas las llamadas de voz originadas por el UMTS tienen que desviarse al GSM", no es necesario considerar las células individuales, siendo suficiente considerar las reservas de recursos GSM y las reservas de recursos UMTS (cada equipo de red que tenga que implementar el algoritmo de CRRM, como los BSC y los RNC, traducirá y aplicará la regla general expresada en términos de reserva de recursos a las células específicas involucradas). El uso de estos dos tipos de tablas puede simplificar la definición de las reglas de CRRM (de lo contrario, serían necesarios varias tablas del primer tipo para especificar una regla general CRRM); sin embargo, la adopción de esta estructura de tabla no es per se limitativa, y son posibles estructuras alternativas.

[0093] Una "tabla para células" ilustrativa está estructurada como se representa en la Figura 5, mientras que la Figura 6 representa la estructura de una "tabla para reserva" ilustrativa.

[0094] Con referencia a la Figura 5, una "tabla para células" 465-c incluye el identificador de tabla IDt 501 y una lista 502 de un número L > 1 de células consideradas en esa tabla (es decir, las células a las que pertenecen las reglas de CRRM especificadas en la tabla); en el ejemplo en cuestión, se asume que la tabla IDt = 6 se refiere a la célula GSMTO1 de la red GSM y la célula UMTSTO3 de la red UMTS.

[0095] La tabla incluye un número n de filas de tabla RW1, RW2, RW3 RWn, y un número de columnas de tabla/grupos de columnas 505, 510, 520 y 590. En particular, el grupo de columnas 520 incluye un subgrupo de columnas respectivo para cada célula en la lista 502, como los subgrupos de columnas 520a y 520b para la célula GSMT01 y UMTST03, respectivamente (otros subgrupos similares a los subgrupos 520a y 520b pueden estar presentes si la lista 502 contiene otros elementos; La Figura 5 describe por simplicidad el caso de dos elementos solamente).

[0096] Considerando la fila de la tabla genérica, que corresponde a una regla de decisión de la lógica de decisión de CRRM, el elemento de tabla en la columna 505 puede contener una expresión, con la semántica descrita a continuación; los elementos de tabla del grupo de columnas 510 están adaptados para contener una descripción de evento, es decir, una descripción de una solicitud de servicio a la que se pretende aplicar la regla de decisión, según la definición de evento proporcionada anteriormente, es decir, los elementos de tabla en el grupo de columnas 510 están adaptados para contener valores para los parámetros s, tipo, origen, dest(1), ...,dest(Np) que caracterizan los eventos.

[0097] El grupo de columnas 520 contiene una descripción del estado de la red. El subgrupo genérico de columnas 520a, 520b, relacionado con una célula respectiva de la lista 502, comprende un grupo de columnas 521 y un grupo de columnas 522.

[0098] Los elementos de tabla en el grupo de columnas 521 relacionados con una determinada célula en la lista 502, todos de tipo entero, se adaptan para contener una descripción del estado de la célula correspondiente, es decir, se adaptan para contener valores para las variables de estado definidas anteriormente RTLU[<cell>], RTLD[<cell>] y N[<cell>,IDs]. Los elementos de tabla en el grupo de columnas 522 relacionados con una determinada célula en la lista 502, de tipo entero o real, se adaptan para contener valores de los contadores definidos, durante la fase de configuración, para la célula correspondiente.

[0099] El elemento de tabla de la columna 590 está adaptado para contener un identificador de una acción de CRRM que debe emprenderse; en particular, el identificador de acción de CRRM puede ser un identificador "Rej", que indica que la solicitud de servicio tiene que ser rechazada, o puede ser una etiqueta de una célula.

[0100] Con referencia a la Figura 6, una "tabla para reservas" 465-p incluye un identificador de tabla IDt 601.

[0101] La tabla para reservas tiene un número m de filas de tabla RWP1, RWP2, RWP3 RWPm, cada una correspondiente a una regla de decisión, y un número de columnas de tabla/grupos de columnas 605, 610, 621, 622, 640, 651, 652 y 690.

[0102] Considerando la fila de tabla genérica, de manera similar a la "tabla para células" descrita anteriormente, el elemento de tabla en la columna 605 puede contener una expresión, con la semántica descrita a continuación; los elementos de tabla en el grupo de columnas 610 se adaptan para contener una descripción de evento.

[0103] Los elementos de tabla en el grupo de columnas 621, todos de tipo entero, son adecuados para contener una descripción del estado de la célula de origen donde se originó la solicitud de servicio, es decir, son adecuados para contener valores para las variables de estado definidas anteriormente RTLU[<cell>], RTLD[<cell>] y N[<cell>,ID^s] para la célula donde se originó la solicitud de servicio.

[0104] Los elementos de tabla en el grupo de columnas 622, de tipo entero o real, son adecuados para contener valores de los contadores definidos, durante la fase de configuración, con respecto a la célula de origen donde se originó la solicitud de servicio.

[0105] El elemento de tabla en la columna 640 es adecuado para contener un identificador de una reserva de recursos.

[0106] Los elementos de tabla en el grupo de columnas 651, todos de tipo entero, son adecuados para contener una descripción del estado de una célula genérica que pertenece a la reserva especificada en la columna 640, es decir, adecuada para contener valores para las variables de estado RTLU[<cell>], RTLD[<cell>] y N[<cell>ID^s] para una célula genérica de la reserva especificada en la columna 640.

[0107] Los elementos de tabla en el grupo de columnas 652, de tipo entero o real, son adecuados para contener valores predeterminados de contadores de eventos definidos durante la fase de configuración, que en funcionamiento deben coincidir con los valores de los contadores de eventos definidos para la célula genérica de la reserva especificada en la columna 640.

[0108] El elemento de tabla en la columna 690 es adecuado para contener un identificador de una acción de CRRM a emprender; en particular, el identificador de acción de CRRM puede ser "Rej" (que indica que la solicitud de servicio tiene que ser rechazada) o un valor entero que es el identificador de una reserva de recursos.

[0109] En particular, en ambas tablas, los elementos de tabla de tipo entero (int) o de tipo real (real), además de tomar valores específicos, también pueden tomar los siguientes valores:

* indica cualquier valor

< n indica cualquier valor inferior a un número n

< n indica cualquier valor inferior o igual a un número n

> n indica cualquier valor mayor que un número n

]m,n[ indica cualquier valor comprendido entre los números m y n (extremos excluidos)

[m, n] indica cualquier valor comprendido entre los números m y n (extremos incluidos)

[m,n[ indica cualquier valor comprendido entre los números m y n (excluido el extremo n)

]m, n] indica cualquier valor comprendido entre los números m y n (excluido el extremo m)

[0110] Los valores de los elementos de tabla de tipo booleano (tipo bool) pueden tomar, además de valores específicos (Verdadero, Falso), también el valor "*", para indicar cualquier valor.

[0111] Los elementos de tabla en la columna 505 de la "tabla para células" genérica o en la columna 605 de la "tabla para reservas" genérica son como se menciona adaptados para contener una expresión (tipo expr), que puede definirse de la siguiente manera:

expr:

operando

expr operador expr búsqueda[expr,expr]

!expr

(expr)

donde:

!expr denota la negación lógica;

(expr) significa que la sintaxis de una expresión puede incluir una expresión entre paréntesis; operador denota: (suma u O lógico)

* (multiplicación o Y lógico)

/ (división de números reales)

>

>=

<

<=

<> (que significa "diferente") operando puede ser: real_number

integer_number

variable

T (Valor booleano Verdadero, tratado como 1 en la evaluación de expresiones)

F (Valor booleano Falso, tratado como 0 en la evaluación de expresiones) puede ser:

s

tipo

origen

dest

cont

estado

donde s denota un identificador de servicio, tipo denota el tipo de solicitud de servicio (0 para una nueva llamada o 1 para entrega), origen denota la reserva de la célula donde se originó la solicitud de servicio. dest puede ser:

dest(1)

dest(A/^p)

cont puede ser:

cy[<cell>]

cw^c[<cell>]

cj[origen]

cwc[origen]

cy[reserva]

Cwc[reserva]

donde c^,[origen] denota el contador con identificador ID^c=/ de la célula donde se originó la solicitud de servicio y c^,[reserva] denota el contador con identificador ID^c=/ de una célula de la reserva especificado en la columna 640. estado puede ser:

RTLU[<cell>]

RTLD[<cell>]

N[<cell>, /nteger_number] RTLU[origen]

RTLD[origen]

N[origen, /nteger_number] RTLU[reserva]

RTLD[reserva]

N[reserva, /nteger_niumber]

donde RTLU[origen], RTLD[origen] y N[origen, /nteger_number] se refieren a la célula donde se originó la solicitud de servicio y RTLU [reserva], RTLD[reserva] y N[reserva,/nteger_number] se refieren a una célula de la reserva especificada en la columna 640.

[0112] según una realización de la presente invención, el resultado de una expresión genérica es un valor booleano.

[0113] Una expresión ilustrativa es:

(c^s [GSMTO1]<7.4) * (búsqueda[4,RTLU[UMTSTO3]]>=búsqueda[5,N[GSMTO1,2]]) que ha de interpretarse como una lógica Y entre las dos condiciones siguientes:

- el valor del contador de eventos con ID^c=5 en la célula GSMTO1 tiene que ser inferior a 7,4; y

- el valor asumido por la tabla de búsqueda con ID^/=4, del elemento de tabla especificado por la carga de célula de enlace ascendente para la célula UMTSTO3 debe ser igual o superior al valor asumido por la tabla de búsqueda con ID^/=5, del elemento de tabla especificado por el número de conexiones en curso en la célula GSMTOl con respecto al servicio con ID^s=2.

[0114] Otra expresión ilustrativa es:

(^{C 5}[GSMTO1]<7,4) * (búsqueda[4,RTLU[reserva]]>=búsqueda[5ⁱ N[origen, 2]]) que ha de interpretarse como una lógica Y entre las dos condiciones siguientes:

- el valor del contador de eventos con ID^c=5 en la célula GSMTO1 tiene que ser inferior a 7,4; y

- el valor, en la tabla de búsqueda con IDⁱ=4, del elemento de tabla especificado por la carga de célula para una célula de la reserva especificada en la columna 640 debe ser igual o superior al valor, en la búsqueda con IDⁱ=5, del elemento de tabla especificado por el número de conexiones continuas en la célula donde se originó la solicitud de servicio con respecto al servicio con ID^s=2.

[0115] Aprovechar el conjunto de tablas 465 que expresan la lógica de decisión del algoritmo de CRRM, de la manera descrita a continuación, las entidades de red (o, alternativamente, la entidad de red) que implementan el algoritmo de CRRM, por ejemplo, los BSC 325, los RNC 335 y los APC 345 (o, alternativamente, el servidor de CRRM 360), puede tomar las decisiones apropiadas en cuanto a la forma en que se debe gestionar una solicitud de servicio genérica. En el ejemplo mostrado, un valor de acción "Ref significa que la solicitud de servicio debe bloquearse.

[0116] Con la definición de la lógica de decisión de CRRM, finaliza la fase de configuración.

[0117] Una vez que el algoritmo de CRRM ha sido completamente configurado, de la manera descrita anteriormente, está listo para ser implementado. La implementación del algoritmo de CRRM (mediante el módulo de implementación 410, explotando el conjunto lógico de decisión de las tablas 465) se describe a continuación, haciendo referencia a los diagramas de flujo de las Figuras 7, 8, 9A y 9B, en una realización de la presente invención.

[0118] El algoritmo de CRRM espera (bloque 703) la ocurrencia de un evento correspondiente a una solicitud de servicio con respecto a un servicio que, en la fase de configuración (bloque 490 en la Figura 4B), se ha especificado que es uno de los servicios gestionados por el algoritmo de CRRM. Supongamos que se recibe una solicitud de servicio (evento 705): se crean los n parámetros que, como se describe en lo anterior, caracterizan el evento ocurrido, asignando valores propios a cada parámetro (identificador s del servicio solicitado, tipo de solicitud, origen de la solicitud de servicio, etc.) (bloque 707). Si en la fase de configuración (bloque 495) se han definido uno o más contadores cuyo valor se ve afectado por la ocurrencia del evento considerado, se actualizan los contadores (bloque 709).

[0119] A continuación, el módulo de escáner de tablas 470 escanea el conjunto de tablas lógicas de decisión de CRRM 465 (en particular, como se explicará a continuación, se escanea una "tabla para células" 465-c o una "tabla para reservas" 465-p), hasta que se encuentre la primera tabla y fila (es decir, la primera regla de decisión) que es compatible con el evento ocurrido, como se detallará en lo siguiente. El módulo de escáner 470 selecciona la primera de las tablas lógicas de decisión N^t CRRM (bloque 710); la forma en que se escanea la tabla seleccionada depende de si es una "tabla para células" (bloque 715) o una "tabla para reservas" (717). Si no se encuentra ninguna fila compatible en la tabla seleccionada (la forma en que se evalúa la compatibilidad de una fila se describe posteriormente, en relación con las Figuras 8 y 9A, 9B), se selecciona la siguiente tabla (bloque 719 y lazo de vuelta al punto 711) y se repite la comprobación; cuando no hay más tablas (bloque 712), no se puede aplicar ninguna política de CRRM a la solicitud, y el algoritmo vuelve al bloque 703, a la espera de la próxima ocurrencia de una solicitud de servicio; si en su lugar se encuentra una tabla donde se encuentra una fila de tabla compatible, las operaciones esquematizadas por los bloques 715 o 717 también incluyen calcular la célula candidata C^t;

si la acción de CRRM resultante de las operaciones esquematizadas por el bloque 715 o el bloque 717 es "Rej", a continuación la solicitud de servicio tiene que ser rechazada (723) y el algoritmo vuelve al bloque 703, esperando la siguiente ocurrencia de una solicitud de servicio; de lo contrario, se acepta el servicio solicitado y se intenta asignarlo a la célula C^t determinada (bloque 727).

[0120] El flujo de operación vuelve al estado de solicitud de espera para el servicio (bloque 703).

[0121] A continuación se describirá un procedimiento mediante el cual el módulo escáner de tablas 470 escanea la "tabla para células" 465-c del conjunto lógico de decisión de CRRM de las tablas 465, haciendo referencia al diagrama de flujo esquemático de la Figura 8.

[0122] En primer lugar, se lee la lista de células involucradas 502 que especifica las células involucradas en la "tabla de células" que se está escaneando (bloque 801); sean CI¹,..., CI^l las células L de la lista 502 (en el ejemplo de la Figura 5, Ch=GSMTO1 y Ch=UMTSTO3).

[0123] Se calcula una variable vectorial S (bloque 802) en función de la caracterización del evento (los n parámetros s, tipo, origen, etc.), los contadores y el estado de todas las células CI¹,..., CI^l en la lista 502: S = {s, tipo, origen, dest(1),..., dest(W^p), contadores y estado de las células CI¹,..., CI^l}.

[0124] Por lo tanto, la variable vectorial S contiene la descripción del evento ocurrido, los valores de los contadores y el estado de las células en el momento en que ocurrió el evento.

[0125] La "tabla para células" 465-c se escanea fila por fila, comenzando desde la primera fila; un contador de filas i puede usarse para rastrear el escaneo de las filas de la tabla; el contador de filas se establece inicialmente en, por ejemplo, 1 (bloque 803), y se aumenta, por ejemplo, en 1, cada vez que el escaneo pasa a la siguiente fila (bloque 805), hasta que se escanea la última fila de la tabla (bloque de decisión 807, rama de salida Sí): en este último caso, no se encuentra ninguna fila de tabla compatible (bloque 809).

[0126] Para la fila de tabla genérica que se está escaneando, es decir, para la regla de decisión genérica en evaluación, el módulo de escáner de tablas 470 lee los valores de los elementos almacenados en la tabla en la fila seleccionada; la expresión en el elemento en la columna 505 se coloca en una variable Expn, la acción en el elemento en la columna 590 se asigna a una variable Acciónⁱ, y los valores de los otros elementos se asignan a una variable vectorial Dⁱ (bloque 811):

Dⁱ={sⁱ, tipoⁱ, origenⁱ, dest(1)ⁱ,..., dest(WP)^¡, (Contadores de células 1,..., L)ⁱ, (Estado de las células 1,..., L)ⁱ}.

[0127] A continuación, se comprueba si el modo de determinación de las reservas alternativas de recursos establecidos en la fase de configuración (bloque 494 en la figura 4) para el origen de la célula de origen i está "basado en mediciones" o "ciego" (bloque 813); en caso de que el modo sea "ciego", el procedimiento continúa comprobando si las variables vectoriales S y Dⁱ coinciden (bloque 816); si en su lugar el modo está "basado en mediciones", a continuación también se comprueba (bloque 815) si la célula cuyo identificador se especifica por el valor de la variable Acciónⁱ es adecuada, desde un punto de vista de cobertura de radio; si no, a continuación se considera la siguiente fila (bloque 805).

[0128] Si, como se mencionó, se ha establecido el modo "ciego", o, en caso de modo "basado en mediciones", la célula especificada por el valor de la variable Acciónⁱ es adecuada desde el punto de vista de cobertura de radio, se comprueba si las dos variables vectoriales S y Dⁱ son iguales. Si no, a continuación se considera la siguiente fila (bloque 805), de lo contrario, el procedimiento continúa verificando si el elemento en la columna 505 de la fila de tabla seleccionada contiene una expresión: en el caso afirmativo, el módulo de escáner de tablas 470 calcula el valor de expresión (posiblemente, para hacer esto, el módulo de escáner de tablas puede acceder a una o más de las tablas de búsqueda 460 que se han definido en la fase de configuración).

[0129] A continuación se evalúa el resultado de la expresión calculada (bloque 817). Si el resultado del cálculo de la expresión contenida en el elemento en la columna 505 es "Falso", el escaneo continúa con la siguiente fila de la tabla, de lo contrario (es decir, si el resultado de la expresión es "Verdadero") se ha encontrado una fila compatible y el contenido de la variable Acciónⁱ se toma como la acción de CRRM a realizar (el valor se asigna a una variable C^t que se utiliza para especificar la acción (bloque 819).

[0130] Si, en el cálculo del valor de expresión, se encuentra una excepción o error, el escaneo continúa con la siguiente fila de la tabla (si corresponde). Ejemplos de excepciones que pueden encontrarse son una división entre cero, la referencia, en la expresión, a una célula no existente, la referencia a una variable de estado de red a la que no se ha asignado un valor; una condición diferente de "*" en el elemento de tabla que corresponde a una variable de estado de red a la que no se ha asignado un valor. Preferentemente, todas las excepciones/errores encontrados se almacenan en un archivo de registro, de modo que el operador de red pueda identificar y corregir fácilmente posibles errores en, por ejemplo, la lógica de decisión de CRRM.

[0131] A continuación se describirá un procedimiento mediante el cual el módulo escáner de tablas 470 escanea la "tabla para reserva" genérica 465-p del conjunto lógico de decisión CRRM de tablas 465, haciendo referencia al diagrama de flujo esquemático de las Figuras 9A y 9B.

[0132] Se utiliza una variable C, y a la variable C se le asigna el valor del identificador de la célula de origen donde se originó la solicitud de servicio (bloque 901).

[0133] La "tabla para reservas" se escanea fila por fila, comenzando por ejemplo desde la primera fila, es decir, desde la primera regla de decisión de la tabla; un contador de filas i puede usarse para rastrear el escaneo de las filas de la tabla; el contador de filas se establece inicialmente en, por ejemplo, 1 (bloque 903), y se aumenta, por ejemplo, en 1, cada vez que el escaneo pasa a la siguiente fila (bloque 905), hasta que se escanea la última fila de la tabla (bloque de decisión 907, rama de salida Sí): en este último caso, no se encuentra ninguna fila de tabla compatible (bloque 909).

[0134] Para la fila genérica de la tabla que se está escaneando, el módulo de escáner de tablas 470 lee los valores de los elementos almacenados en la tabla en la fila seleccionada y los asigna (bloque 911) a una variable Expn (tomando el contenido leído del elemento en la columna 605), a una variable Pⁱ (tomando el contenido leído del elemento en la columna 640), a una variable Acciónⁱ (tomando el contenido leído del elemento en la columna 690); el contenido de los elementos restantes de la fila se asigna a una variable vectorial Dⁱ:

D¡={^s¡, tipoⁱ, origenⁱ, dest(1)ⁱ,..., dest(WP)ⁱ, (Estado de la célula de origen)ⁱ, (Contadores de la célula de origen)ⁱ, (Estado de la célula de la reserva)ⁱ, (Contadores de la célula de la reserva)ⁱ}.

[0135] En el caso del valor ^p ¡="*" (bloque 913) el algoritmo salta (puente J1) a una rutina que se describirá más adelante en relación con la Figura 9B, de lo contrario, las células Q pertenecientes a la reserva Pⁱ especificadas en el elemento en la columna 640 se reordenan mediante la calidad de nivel de señal de radio descendente (en el caso de que el modo "basado en mediciones" se estableció para la célula de origen en la fase de configuración) o se mantienen en el mismo orden que se indican en la definición de reserva de recursos (en el caso de que se seleccionó el modo "ciego" para la célula de origen). Los nombres de las células ordenadas como se describe se asignan a las variables CP¹, ... CP^q (bloque 915).

[0136] Las células especificadas por los nombres asignados a las variables CP¹, ... CP^q se escanean una por una, comenzando desde la célula CP¹; se puede usar un contador de filas j para rastrear el escaneo de las células; el contador de filas se establece inicialmente en, por ejemplo, 1 (bloque 920), y se incrementa, por ejemplo, en 1, cada vez que el escaneo pasa a la siguiente célula (bloque 930), hasta que se escanea la última célula (bloque de decisión 925, rama de salida Sí): en este último caso, se debe considerar una nueva fila de tabla (bloque 905).

[0137] Para la célula genérica CP^j que se está escaneando, el módulo de escáner de tablas 470 calcula una variable vectorial S (bloque 935) en función de la caracterización del evento ocurrido, excluyendo el campo de origen (es decir, los parámetros considerados son s, tipo, dest(1), ..., dest(N^p)), sobre los valores actuales de los contadores y los estados de las células C (es decir, la célula de origen) y CP^j S={s, tipo, C, dest(1),..., dest(N^pmax), (Estado de la célula C), (Contadores de la célula C), (Estado de la célula CP^j ), (Contadores de la célula CP^j )}.

[0138] También se calcula un valor VExpr, aplicando a la expresión contenida en el elemento en la columna 605) las siguientes sustituciones (bloque 940):

ci[origen] c1[C] ci[reserva] _c1[CPj]

cNc[origen] — cNc[C] cNc[reserva] — cNc[CPj]

RTLU[origen] RTLU[reserva

— RTLU[C] ] - RTLU[CPj]

RTLD[origen] RTLD[reserva

— RTLD[C] ] - RTLD[CPj]

N[origen,*] — N[C,*] N[reserva,*] — N[CPj,*].

[0139] En otras palabras, la expresión se calcula con respecto a la célula de origen C y de la célula considerada de la reserva especificada para la fila de la tabla que se está escaneando.

[0140] A continuación se comprueba si tanto S=Di como el valor VExpr son Verdaderos; si no es así (bloque de decisión 945, rama de salida No), a continuación se considera la siguiente célula CPj (volver al bloque 930).

[0141] A continuación, se comprueba si Acción i=origeni; en el caso afirmativo (bloque de decisión 950, rama de salida Sí), la variable Ct toma el valor de C (bloque 955) y el procedimiento finaliza con una fila compatible encontrada (bloque 970).

[0142] De lo contrario, se comprueba si Acciónⁱ=Pⁱ; en el caso afirmativo (bloque de decisión 960, rama de salida Sí), C^t toma el valor de CP^j (bloque 965) y el procedimiento finaliza con una fila compatible encontrada (970).

[0143] Si ninguno de los dos controles anteriores tiene éxito, hay dos posibilidades (bloque 975), dependiendo de si para la célula de origen C se especificó el modo "ciego" o el modo "basado en mediciones" en la fase de configuración; en el primer caso (bloque 980), C^t toma el valor de la primera célula en la lista de células pertenecientes a la reserva indicada por la Acción en el segundo caso (bloque 985) C^t toma el valor de la primera célula en la lista de células pertenecientes a la reserva indicada por la Acciónⁱ reordenada disminuyendo la calidad de la señal de radio.

[0144] El procedimiento finaliza con una fila compatible encontrada (990).

[0145] El caso del elemento en la columna 640 toma el valor "*" (en el bloque 913), es decir, de una fila de la "tabla de reservas" que no especifica ninguna reserva particular de recursos, se describe en la Figura 9B:

Algunos elementos de la fila i-ésima se utilizan para calcular una variable vectorial DDⁱ (bloque 991):

DDⁱ={sⁱ, tipoⁱ, origenⁱ, dest(1)ⁱ,..., dest(N^p)ⁱ, (Estado de la célula de origen)ⁱ, (Contadores de la célula de origen)ⁱ}.

[0146] Se puede ver que la variable vectorial DDi es la misma que la variable vectorial Dⁱ del bloque 911, pero no contiene elementos dependiendo de (células de) la reserva Pⁱ.

[0147] A continuación se calcula una variable vectorial SS (bloque 992) de la siguiente manera:

S^s ={^s, tipo, C, dest(1),..., dest(N^p), (Estado de la célula C), (Contadores de célula C)}.

[0148] Se puede observar que la variable vectorial S se calcula de la misma manera que la variable vectorial S en el bloque 935, pero no contiene elementos que dependan de la reserva Pi.

[0149] A continuación se evalúa un valor VVExpr (bloque 993), de la siguiente manera:

VVExpr = Expri contenido en el elemento de la columna 605 evaluado aplicando las siguientes sustituciones:

ci[origen] c1[C]

cNc[origen] ^ CNc [C]

RTLU[origen] ^ RTLU[C]

RTLD[origen] ^ RTLD[C]

N[origen,*] ^ N[C,*]

[0150] Por lo tanto, el valor VVExpr se calcula de la misma manera que VExpr en el bloque 940, pero no contiene referencias al estado de una célula de la reserva, de lo contrario se plantea una excepción.

[0151] A continuación se comprueba si tanto SS= DDi como VVExpr son verdaderos (bloque 994); si no es así (bloque de decisión 994, rama de salida No), a continuación se considera la siguiente fila (volver al bloque 905 a través del puente J3); de lo contrario, el procedimiento continúa (a través del puente J2) con la verificación del bloque 950.

[0152] En lo adelante, se presentará un ejemplo de aplicación del procedimiento y sistema descrito anteriormente.

[0153] El escenario considerado en el ejemplo que se presenta es el de una red de radiocomunicaciones móvil capaz de proporcionar servicios de intercambio de voz y datos, donde:

- el servicio de voz lo ofrecen tanto una red GSM como una red UMTS;

- el servicio de intercambio de datos es ofrecido por la red UMTS;

- la red GSM incluye dos células GSM1 y GSM2, y la red UMTS incluye dos células UMTS1 y UMTS2, con cobertura respectiva como se representa en la Figura 10;

- las células GSM1 y GSM2 están controladas por un mismo BSC;

- las células UMTS1 y UMTS2 están controladas por un mismo RNC.

[0154] Se asume que se conoce el mapeo de la capacidad de UMTS en la variable de carga celular definida en lo anterior: por ejemplo, la tabla a continuación proporciona los valores de carga celular en enlace descendente versus el número de usuarios de voz y datos activos:

continuación

[0155] Se supone que la capacidad de la red GSM es de 10 canales de voz; la tabla a continuación ejemplifica los valores de carga celular en enlace descendente versus el número de usuarios de voz activos:

[0156] Las dos tablas anteriores son útiles para comprender la carga máxima permitida en las células. La primera tabla indica la carga celular dada la cantidad de llamadas de voz y datos en una célula de UMTS. Dado que la carga celular no puede ser mayor que 100, está claro, por ejemplo, que si se están ejecutando 10 llamadas de voz, a continuación no se pueden aceptar más de 4 llamadas de datos. La segunda tabla se refiere a GSM donde, en este ejemplo, solo son posibles llamadas de voz.

[0157] Como se describió anteriormente, en la fase de configuración del algoritmo de CRRM, el operador de red define los servicios de red que se someterán al algoritmo de CRRM; en el presente ejemplo, se consideran dos servicios en tiempo real, a saber, un servicio de voz y un servicio de intercambio de datos, como se ejemplifica en la tabla a continuación, que se identifican como ID^s=1 e ID^s=2, respectivamente, y se caracterizan como se describe en lo anterior sobre la base de los parámetros de QoS.

[0158] Además, en la fase de configuración se define la reserva de recursos; en el ejemplo considerado, se supone que se han definido dos reservas de recursos, una que agrupa las células GSM y la otra que agrupa las células UMTS:

[0159] La etapa de definición de los solapamientos de células, basado en el ejemplo de la Figura 9, proporciona:

[0160] En cuanto a la definición de los criterios para las mediciones de radio en las células vecinas, se supone que la red está configurada de tal manera que los terminales móviles de modo dual (es decir, GSM y UMTS) ubicados en una célula realizan mediciones en la célula superpuesta que pertenece al otro sistema.

[0161] Esta configuración de medición permite establecer la modalidad "basada en mediciones" en la siguiente etapa de la fase de configuración: en el ejemplo considerado, se asume que en las células GSM1 y UMTS1 se selecciona la modalidad "ciega", mientras que en las células GSM2 y UMTS2 se selecciona la modalidad "basada en mediciones".

[0162] En el ejemplo considerado, los eventos (solicitudes de servicio) se caracterizan por 5 de la forma: s, tipo, origen, dest(1), dest(2)

donde s = 1 identifica las solicitudes de servicio de voz, s = 2 identifica las solicitudes de servicio de datos, tipo = 0 para una nueva solicitud, tipo = 1 para una solicitud procedente de una entrega, origen = 1 si el terminal móvil está acampado en la red UMTS, origen = 2 si el terminal móvil está acampado en la red GSM, dest(1) = Verdadero si es posible asignar la solicitud a la red UMTS, dest(1) = Falso en caso contrario, y dest(2) = Verdadero si la solicitud de servicio puede asignarse al GSM, dest(2) = Falso en caso contrario.

[0163] También se asume que un contador de eventos de tipo entero está definido para contar todas las llamadas de voz, y otro contador de eventos de tipo entero está definido para contar las llamadas de voz que se pueden asignar tanto al GSM como a las redes UMT^s . Los dos contadores se definen de la siguiente manera:

[0164] Además, se supone que se ha definido un contador real, como una relación entre los dos contadores anteriores:

[0165] También se supone que una tabla de búsqueda con IDⁱ=1 se define en la fase de configuración para especificar, según la capacidad ilustrativa de la red UMTS indicada anteriormente, el número máximo de llamadas de voz que pueden ser aceptadas por una célula UMTS en función del número de conexiones de datos en curso:

continuación

[0166] Se asume que el estado de la red se describe mediante las variables de estado enumeradas en la siguiente tabla, donde para cada variable se especifica si es visible para el RNC, para el BSC o para ambos:

[0167] Se puede apreciar que todas las variables de estado relacionadas con la carga en tiempo real son visibles tanto para el RNC como para el BSC; las variables de estado relacionadas con el número de conexiones activas para los servicios de voz o datos solo son visibles para el controlador de la célula correspondiente.

[0168] Se supone que la lógica de decisión de CRRM se especifica en la tabla de la Figura 11, con identificador IDt=1; la tabla corresponde en principio a la tabla de la Figura 5.

[0169] Se puede apreciar que:

Fila 1 de la tabla:

Especifica que las solicitudes de servicio del tipo de datos solo pueden ser satisfechas por la red UMTS;

Filas 2 y 3 de la tabla:

Especifican que las solicitudes de servicios de voz de HO se mantienen en el RAT a la que están siendo transferidas por la HO; Fila 4 de la tabla:

Especifica que una nueva solicitud de un servicio de voz que solo puede ser atendido por la red UMTS se asigna a la Red UMTS;

Fila 5 de la tabla:

Especifica que una nueva solicitud de un servicio de voz que solo puede ser atendido por la red GSM se asigna a la red GSM;

Fila 6 de la tabla:

Especifica que una nueva solicitud de servicio de voz recibida por el RNC, que puede ser atendida tanto por la red UMTS como por la red GSM, se asigna a la red GSM (suponiendo que exista suficiente capacidad para ello); Fila 7 de la tabla:

Especifica que, si no es posible asignar una nueva llamada de voz en la red UMTS, se rechaza la solicitud de servicio; esta comprobación se realiza explotando la tabla de búsqueda ID/=1 definida anteriormente: la expresión tiene el siguiente significado:

(Número de llamadas de voz en la célula de la reserva UMTS) > (número máximo de llamadas de voz admisibles cuando hay un número (N[reserva,1]) de llamadas de datos presentes en la célula de la reserva

UMTS)

Fila 8 de la tabla:

Especifica que si en la célula donde se originó la solicitud de llamada de voz el contador c3 > 0,7, a continuación la llamada se acepta en la fila 9 de la red UMTS de la tabla:

Especifica que, de lo contrario, la llamada se rechaza

Fila 10 de la tabla:

Especifica que una nueva solicitud de servicio de voz recibida por el BSC, que puede ser atendida tanto por el GSM como por las redes UMTS, se asigna al GSM, si todavía hay espacio para ello;

Fila 11 de la tabla:

Especifica que, si no es posible asignar más llamadas de voz en la red UMTS, se rechaza la solicitud de servicio; Fila 12 de la tabla:

Especifica que si en la célula donde se originó la solicitud de llamada de voz el contador c3 > 0,7, a continuación la llamada se acepta en la fila 13 de la red UMTS de la tabla:

Especifica que, de lo contrario, la llamada será rechazada.

[0170] El funcionamiento del algoritmo de CRRM, en el ejemplo considerado, se describe a continuación.

[0171] Supongamos que un terminal móvil, conectado a la célula UMTS1, solicita realizar una nueva llamada de voz; también se asume que el terminal es capaz de modo dual. El evento se caracteriza en este caso por:

s=1 (llamada de voz)

tipo=0 (nueva llamada de voz, no HO)

origen=1 (el terminal está conectado a la red UMTS)

dest(1)=T (el terminal podría conectarse a la red UMTS)

dest(2)=T (el terminal podría conectarse a la red GSM)

[0172] Según el procedimiento descrito en detalle en lo anterior, el contador de llamadas de voz y el contador de las llamadas de voz que pueden ser manejadas tanto por el GSM como por las redes UMTS se incrementan en la célula UMTS1.

[0173] Las filas de la tabla lógica de decisión CRRM ID= 1 son escaneadas por el módulo de escáner de la tabla 470, buscando una fila compatible con el evento ocurrido. El escaneo es el específi

ya que el IDt de la tabla =1 es de este tipo.

[0174] En particular:

Se considera que la fila 1 no es compatible, porque el servicio solicitado no es un servicio de datos;

Se considera que las filas 2 y 3 no son compatibles porque la solicitud de servicio es para una nueva llamada, no una HO;

Se considera que las filas 4 y 5 no son compatibles, ya que se refieren a terminales que solo pueden utilizar uno de los RAT, es decir, el GERAN o el UTRAN;

La fila 6 se caracteriza por un valor diferente de "*" en la columna "reserva", por lo que la reserva 2 debe expandirse en todas sus células, a saber, la célula GSM1 y GSM2. Dado que la célula de origen (UMTS1) se caracteriza por el modo "ciego", las células de la reserva se mantienen en el mismo orden que en la definición de la reserva, es decir, {GSM1, GSM2}.

[0175] S se calcula considerando la primera célula (GSM1) como la célula de la reserva: S={1, 0, UMTS1, T, T, (Estado de la célula UMTS1), (Contadores de la célula UMTS1), (Estado de la célula GSM1), (Contadores de la célula UMTS1)}. VExpr es Verdadero y se debe verificar la compatibilidad entre S y Dⁱ. La parte del evento es compatible; la parte restante es toda "*", aparte de la columna RTLD del estado de la célula de la reserva (que se refiere a GSM1) donde la condición es inferior o igual a 90. Suponiendo que se cumple la condición RTLD[GSM1]<90, se verifica con éxito si la Acciónⁱ = 2, por lo tanto C^t=GSM1 y el escaneo de la tabla terminan con una fila compatible encontrada y la célula GSM1 tiene que usarse para aceptar la solicitud de llamada de voz.

[0176] En una realización alternativa de la invención, la lógica de decisión no se define en términos de una tabla, como se describió anteriormente, sino que el operador de red puede ingresar un algoritmo de decisión que implementa una política de CRRM deseada. En particular, el algoritmo se puede especificar como un código de programa informático compilado, generado a partir de un código fuente escrito por el operador de red. También en este caso, la lógica de decisión se estructura como un conjunto de una o más reglas de decisión, que tienen la sintaxis homogénea descrita en lo anterior. El algoritmo puede estructurarse como uno o más procedimientos o funciones con entradas y una salida; cada una de ellas corresponde a una regla de decisión; las entradas a la función pueden ser la caracterización del evento ocurrido (por ejemplo, en términos de n parámetros descritos en lo anterior), y del estado de la red (según lo especificado por las variables de estado descritas en lo anterior), incluyendo valores específicos para los contadores definidos durante la fase de configuración. La salida de función puede ser un identificador de una acción a realizar.

[0177] Por ejemplo, se puede proporcionar una interfaz en lenguaje de programación C (o similar) del tipo: int CRRM(int s, int type, int origin, boolean* dest, int*integercounter, double* realcounter, tState* networkstate) {

//Código escrito por el operador de red

return ... //Devuelve el iD de una acción a realizar

}

donde tState* es un tipo de estructura de datos adecuada para contener el estado de la red.

[0178] El procedimiento o función de decisión CRRM se invoca cada vez que se produce un evento que requiere el algoritmo de CRRM para decidir cómo se tiene que manejar (estos eventos se especifican en la fase de configuración). Basado en la salida de la función, la red realiza la acción correspondiente. Los errores o excepciones encontrados durante la determinación de la acción a tomar pueden conducir a acciones predeterminadas.

[0179] Gracias a la presente invención, el operador de red tiene la posibilidad de definir e implementar las políticas de CRRM preferidas que mejor se adapten al contexto específico de la red, posiblemente variándolas en el tiempo, sin la necesidad de pedir a los productores de equipos de red que los personalicen.

[0180] La presente invención se puede aplicar en general a cualquier red de telecomunicaciones, ya sea de radio (es decir, inalámbrica) o no, donde, para satisfacer las solicitudes de servicio de los usuarios, los recursos de red (por ejemplo, recursos de radiocomunicaciones) tienen que asignarse a los usuarios, donde los recursos de red asignados se pueden seleccionar entre diferentes reservas de recursos de red, y la selección se realiza en función de las políticas de selección de recursos, implementadas por algoritmos que se ejecutan por equipos de red, que tienen en cuenta la solicitud de servicio y el estado de la red.

[0181] Incluso de manera más general, la presente invención se puede aplicar en cualquier sistema donde se desee o sea útil implementar políticas de gestión de recursos de sistema, especificando la forma en que los recursos de sistema se asignan a las entidades solicitantes cuando estas últimas solicitan servicios al sistema.

[0182] Aunque en la descripción siempre se ha asumido que el algoritmo de CRRM gestiona las solicitudes de servicio de los usuarios, esto no debe interpretarse de forma limitativa: la solicitud de servicio puede ser activada por la propia red, por ejemplo, para ofrecer un determinado servicio a los usuarios.

[0183] La presente invención se puede implementar en hardware o como una combinación de hardware y software. Se puede usar cualquier lenguaje de programación y cualquier interfaz gráfica de usuario (GUI - Graphical User Interface), particularmente cualquier lenguaje que pueda ser interpretado por microprocesadores incluidos en el equipo de red. Los conjuntos específicos de instrucciones, así como el número de variables utilizadas en el programa, pueden diferir, según la implementación específica.

[0184] La presente invención se ha descrito en esta invención haciendo referencia a una realización ilustrativa y no limitativa de la misma. Los expertos en la materia reconocerán que se pueden realizar varias modificaciones a las realizaciones descritas, por ejemplo, para satisfacer necesidades contingentes, así como varias otras realizaciones son posibles, sin apartarse del alcance de protección establecido en las reivindicaciones adjuntas.

Claims (14)

REIVINDICACIONES

1. Un aparato de gestión de recursos de radio (325.335.345.360) adaptado para implementar políticas comunes de gestión de recursos de radio, "CRRM", para la gestión de recursos de radio de un sistema de radiocomunicación (205.210.215.220), dichos recursos de radio son susceptibles de ser asignados a entidades que solicitan servicios de comunicación al sistema de radiocomunicación, el aparato de gestión de recursos de radio comprende:

- una interfaz de configuración (405) adaptada para recibir datos de configuración de gestión de recursos de radio de un usuario, donde dichos datos de configuración incluyen una lógica de decisión de gestión de recursos de radio adaptada para especificar una política de gestión de recursos de radio;

- un conjunto de implementación de política de gestión de recursos de radio (410) que responde a las solicitudes de servicio de comunicación de las entidades solicitantes y está adaptada para administrar la asignación de los recursos de radio del sistema de radiocomunicación a las entidades solicitantes en función de una lógica de decisión de gestión de recursos de radio, donde dicha interfaz de configuración está adaptada para recibir, y dicho conjunto de implementación de política de gestión de recursos de radio está adaptada para administrar las lógicas de decisión de gestión de recursos de radio estructuradas como un conjunto de una o más reglas de decisión, donde cada regla de decisión comprende:

una descripción de al menos una solicitud de servicio de comunicación destinada a regirse por dicha regla de decisión; una descripción del estado del sistema de radiocomunicación respecto al cual se pretende aplicar la regla de decisión; y

una acción a tomar por el aparato en caso de que se aplique la regla de decisión, donde:

dichos datos de configuración incluyen al menos una tabla de valores, donde al menos una regla de decisión de una lógica de decisión de gestión de recursos de radio recibida a través de la interfaz de configuración incluye referencias a al menos una tabla, donde dicho conjunto de implementación de política de gestión de recursos de radio se adapta para buscar en al menos una tabla en función de las referencias incluidas en al menos una regla de la lógica de decisión de gestión de recursos de radio.

2. El aparato de la reivindicación 1, donde dichos datos de configuración incluyen:

una definición de al menos dos grupos de los recursos de radio del sistema de radiocomunicación, y

una definición de tipos de solicitudes de servicio de comunicación con respecto a las cuales el aparato tiene que gestionar la asignación de recursos de radio del sistema pertenecientes a uno de al menos dos grupos de recursos de radio del sistema de radiocomunicación.

3. El aparato de la reivindicación 2, donde dicha acción a ser tomada por el aparato en caso de que se aplique la regla de decisión respectiva incluye una indicación de si una solicitud de servicio de comunicación debe asignarse al recurso de radio de un sistema que pertenece a uno u otro de los al menos dos grupos, o debe ser rechazada.

4. El aparato de la reivindicación 2 o 3, donde dicha descripción de al menos una solicitud de servicio de comunicación incluye una indicación del tipo del servicio de comunicación solicitado, una indicación del grupo de recursos de radio del sistema al que pertenece el recurso de radio del sistema a través del cual se recibe la solicitud de servicio de comunicación, una indicación de la posibilidad de reasignar la solicitud de servicio de comunicación en otro grupo de recursos de radio del sistema de dichos al menos dos grupos.

5. El aparato de la reivindicación 4, donde el conjunto de implementación de política de gestión de recursos de radio se adapta para gestionar la asignación de los recursos de radio del sistema de radiocomunicación en respuesta a una solicitud de servicio de comunicación recibida en función de una comparación entre una descripción de la solicitud de servicio de comunicación recibida y las descripciones de las solicitudes de servicio de comunicación incluidas en al menos una regla de decisión de una lógica de decisión de gestión de recursos de radio recibida a través de dicha interfaz de configuración.

6. El aparato de cualquiera de las reivindicaciones anteriores, donde el conjunto de implementación de la política de gestión de recursos de radio se adapta para gestionar la asignación de los recursos de radio del sistema de radiocomunicación en respuesta a una solicitud de servicio de comunicación recibida en función de una comparación entre una descripción de un estado actual del sistema de radiocomunicación en el momento en que se recibe la solicitud de servicio de comunicación y las descripciones del estado del sistema de radiocomunicación incluidas en al menos una regla de decisión de una lógica de decisión de gestión de recursos de radio recibida a través de la interfaz de configuración.

7. El aparato de cualquiera de las reivindicaciones anteriores, donde dicha descripción de un estado del sistema de radiocomunicación con respecto al cual se pretende aplicar la regla de decisión incluye al menos un valor de conteo de eventos correspondientes a solicitudes de servicio de comunicación recibidas.

8. El aparato de la reivindicación 7, donde dichos datos de configuración incluyen una definición de al menos un contador de eventos que se asociará con eventos específicos correspondientes a solicitudes de servicio de comunicación de las entidades solicitantes, donde dicho al menos un contador de eventos es administrado por el conjunto de implementación de la política de gestión de recursos de radio.

9. El aparato de la reivindicación 8, donde el conjunto de implementación de la política de gestión de recursos de radio se adapta para gestionar la asignación de los recursos de radio del sistema en respuesta a una solicitud de servicio de comunicación recibida en función de una comparación entre un valor actual del al menos un contador de eventos y un valor de conteo especificado en la descripción del estado del sistema de radiocomunicación incluido en al menos una regla de decisión.

10. El aparato de cualquiera de las reivindicaciones anteriores, donde dicho sistema de radiocomunicación está estructurado en células, y dichas descripciones de un estado del sistema de radiocomunicación incluyen una indicación de carga de dichas células que incluye:

- una indicación de la carga celular en enlace ascendente para servicios en tiempo real relacionados con el genérico de las células;

- una indicación de la carga celular en enlace descendente para servicios en tiempo real relacionados con el genérico de las células;

- una indicación de una serie de conexiones activas para el servicio genérico relacionado con el genérico de las células.

11. El aparato de la reivindicación 10, según la reivindicación 2, donde dichos al menos dos grupos de recursos de radio del sistema son grupos de células, y donde dichos datos de configuración incluyen, para cada una de dichas células:

una definición de una lista de otras células que se solapan a la misma y que pertenecen a un grupo diferente de recursos de radio del sistema, y

una indicación de una modalidad de determinación de un recurso de radio de un sistema alternativo admisible susceptible de ser utilizado para satisfacer la solicitud de servicio de comunicaciones.

12. El aparato de la reivindicación 11, donde dicha indicación de modalidad incluye una indicación de si la determinación tiene que basarse en medidas de radio realizadas por las entidades solicitantes.

13. El aparato de la reivindicación 10 según la reivindicación 3, donde dicha descripción de al menos una solicitud de servicio de comunicación incluye una indicación del tipo de solicitud de servicio de comunicación, dicho tipo de solicitud de servicio de comunicación incluye una indicación de si se trata de una nueva solicitud de servicio de comunicación o una entrega.

14. Un procedimiento para implementar políticas comunes de gestión de recursos de radio, "CRRM", para la gestión de recursos de radio de un sistema de radiocomunicación, dichos recursos de radio son susceptibles de ser asignados a entidades que solicitan servicios de comunicación al sistema de radiocomunicación, el procedimiento comprende:

- proporcionar a un aparato de gestión de recursos de radio (325.335.345.360), a través de una interfaz de configuración (405) de este, datos de configuración de gestión de recursos de radio, donde dichos datos de configuración incluyen una lógica de decisión de gestión de recursos de radio adaptada para especificar una política de gestión de recursos de radio;

- hacer que el aparato de gestión de recursos de radio gestione la asignación de los recursos de radio del sistema de radiocomunicación a las entidades solicitantes en respuesta a las solicitudes de servicio de comunicación recibidas basadas en la lógica de decisión de gestión de recursos de radio;

donde dichas lógicas de decisión de gestión de recursos de radio se estructuran como un conjunto de una o más reglas de decisión, donde cada regla de decisión comprende:

una descripción de al menos una solicitud de servicio de comunicación destinada a regirse por dicha regla de decisión; una descripción del estado del sistema de radiocomunicación respecto al cual se pretende aplicar la regla de decisión; y

una acción a tomar por el aparato en caso de que se aplique la regla de decisión, donde: dichos datos de configuración incluyen al menos una tabla de valores, la al menos una regla de decisión de una lógica de decisión de gestión de recursos de radio recibida a través de la interfaz de configuración que incluye referencias a dicha al menos una tabla, donde dicho aparato de gestión de recursos de radio gestiona la asignación de los recursos de radio del sistema de radiocomunicación que comprende buscar en la al menos una tabla en función de las referencias incluidas en la al menos una regla de la lógica de decisión de gestión de recursos de radio.