ES2333791T3

ES2333791T3 - Metodo y dispositivo para gestionar recursos compartidos por diferentes operadores en un sistema de comunicacion.

Info

Publication number: ES2333791T3
Application number: ES03768440T
Authority: ES
Inventors: Wiliam Warrillow; Sean Murphy
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2003-12-09
Filing date: 2003-12-09
Publication date: 2010-03-01
Anticipated expiration: 2023-12-09
Also published as: TWI374629B; CA2544727A1; US8155072B2; EP1695581B1; US20070264986A1; CA2544727C; DE60329537D1; EP1695581A1; AU2003291799A1; CN1879441A; CN100508641C; ATE444662T1; TW200534635A; WO2005057978A1

Abstract

Método para gestionar recursos en un sistema de comunicación (10) que tiene recursos compartidos por al menos dos operadores (12, 14), que comprende las etapas de: recibir una petición de acceso para un primer operador de los al menos dos operadores (12, 14); y ejecutar una primera determinación si hay suficiente cantidad de recursos libres disponibles en el sistema de comunicación (10), caracterizado por las otras etapas de: ejecutar una segunda determinación si una cantidad total de los citados recursos compartidos por al menos dos operadores en uso en el sistema de comunicación (10) excede un primer umbral; ejecutar una tercera determinación si una cantidad total de los citados recursos compartidos por al menos dos operadores en uso para el primer operador excede un segundo umbral; y decidir sobre aceptar la petición de acceso basándose en los resultados de las determinaciones primera, segunda y tercera.

Description

Método y dispositivo para gestionar recursos compartidos por diferentes operadores en un sistema de comunicación.

Campo técnico

La presente invención se refiere en general a redes de comunicaciones y a métodos de gestión de recursos de redes de comunicaciones, y en particular a tales redes y métodos que gestionan recursos compartidos por diferentes operadores.

Antecedentes

Las redes de comunicaciones de telefonía móvil están evolucionando rápidamente en la actualidad. Diferentes operadores compiten en el mercado, cada uno de los cuales tiene que proporcionar una cobertura de red lo más completa posible. La inversión en hardware de red es uno de los mayores costes cuando se establecen redes de comunicaciones de telefonía móvil. Tradicionalmente, cada operador ha proporcionado su propio hardware de red. Recientemente, se ha propuesto compartir la infraestructura de red como medio para permitir que varios operadores de red minimicen los costes asociados con el despliegue de las redes. Se han propuesto varios planteamientos diferentes para compartir recursos de red, tales como: redes compartidas geográficas, compartir instalaciones, UTRAN compartida y red compartida común. Más detalles en la arquitectura de los diferentes planteamientos para compartir están disponibles en [1].

En redes compartidas, uno o más operadores comparten al menos algo de infraestructura para proporcionar servicios a los usuarios. Por lo tanto, los recursos son compartidos en la parte de la infraestructura que es compartida para proporcionar los servicios deseados. En algunas situaciones, pueden compartirse recursos restringidos. Compartir tales recursos limitados requiere pensar un poco y es necesario idear un planteamiento para compartir estos recursos que sea adecuado para todos los operadores involucrados pero que además maximice la utilización del recurso
restringido.

Las redes compartidas son un concepto relativamente nuevo y aún no han alcanzado el status de despliegue. Se han hecho algunas modificaciones a las normas para facilitar el desarrollo de las redes compartidas. Por ejemplo, ha sido necesario modificar normas para facilitar el que se comparta una red geográficamente de manera tal que una única infraestructura pueda parecer más de una infraestructura. El desarrollo del producto hasta la fecha se ha focalizado en modificar las soluciones existentes, que fueron desarrolladas para contextos de no-compartir, con el fin de operar en un contexto de red compartida. Así, se han añadido pocas funcionalidades o características extra al entorno de red compartida.

En relación con los asuntos específicos asociados con la gestión de recursos restringidos en redes compartidas, no se conocen soluciones de la técnica anterior. No obstante, un planeamiento simple para gestionar los recursos es ignorar el hecho de que la infraestructura está siendo compartida y asignar los recursos tal como son solicitados si hay suficientes recursos disponibles. No obstante, esto puede provocar una desigual distribución de recursos. Por ejemplo, si dos operadores están compartiendo los recursos, cada uno de los cuales paga el 50% de los costes de despliegue de la red. Asúmase que existe un acuerdo entre los operadores de que los dos tienen derecho al 50% de los recursos durante períodos de congestión. Si, por alguna razón, hay mayor demanda de servicio entre los clientes de un operador, este operador puede obtener una fracción de los recursos mayor del acordado 50%.

En el documento EP 1 220 557 se describe un sistema de comunicación y un método de compartir un recurso de comunicación. Un sistema de comunicación inalámbrica incluye un recurso de comunicación que tiene un número de operadores proporcionando comunicación sobre el recurso de comunicación. Una primera porción del recurso de comunicación está dedicada a un primer operador y una segunda porción del recurso de comunicación está dedicada como recursos compartidos para su uso compartido entre al menos dos operadores dentro del sistema de comunicación. Se describe también un método de enterrar un recurso de comunicación. Esto permite compartir frecuencias, entre frecuencias propietaria y compartida, controlando dinámicamente un conjunto de umbrales ajustables para la admisión y terminación de llamadas, lo que resulta en que se comparte un espectro flexible y se aumenta la eficiencia del espectro. Tal mecanismo para proporcionar una asignación de espectro flexible se alcanza moviendo umbrales y/o mediante una instrucción desde un controlador central.

Resumen

Un problema general con gestionar recursos restringidos en un contexto de red compartida de acuerdo con la técnica anterior es que un uso maximizado global de los recursos es difícil de alcanzar, mientras que los recursos apenas son asignados a los operadores. Además, funcionalidades adicionales como renegociaciones de tamaños de recursos, el uso de niveles o situaciones de prioridad muy diferentes en cuanto a los tamaños de recurso solicitados hacen que la situación sea aún más complicada.

Un objeto de la presente invención es así proporcionar métodos y dispositivos para la gestión de recursos proporcionando una elevada utilización de recursos aun proporcionando una adecuada asignación entre los diferentes operadores. Otro objeto es integrar el uso de niveles de prioridad en tales métodos y dispositivos de gestión. Otro objeto más es proporcionar negociaciones de recursos dentro del mismo esquema de gestión. Otro objeto es reducir la influencia de las llamadas que solicitan grandes recursos en ocasiones cercanas a la congestión.

Los objetos anteriores se alcanzan mediante métodos y dispositivos de acuerdo con las reivindicaciones de patentes adjuntas. En general, se toma una decisión de aceptar o rechazar una petición de acceso recibida basándose en al menos tres comparaciones. La primera comparación es entre la cantidad total de recursos libres disponibles en el sistema de comunicación que puede usarse para el acceso y la cantidad de recursos solicitados. La segunda comparación se hace entre una cantidad total de recursos ocupados si la petición de acceso fuese aceptada y un primer umbral. El umbral corresponde a algún tipo de umbral de nivel de congestión. La tercera comparación es si una cantidad total de recursos utilizados por el operador en cuestión si la petición de acceso fuese aceptada excedería un segundo umbral. Este segundo umbral es una porción de los recursos totales que está asignada al operador en cuestión. La petición de acceso es preferiblemente aceptada si la primera comparación muestra que hay recursos disponibles y si la segunda comparación indica que no existe congestión. La petición de acceso puede también preferiblemente ser aceptada si la segunda comparación indica que existe una congestión, pero el operador no ha utilizado todavía su porción asignada de los recursos totales.

En una realización de la presente invención, se lleva a cabo una llamada congestión blanda, en la cual las peticiones de acceso que requieren una gran cantidad de recursos son gradualmente discriminadas cuando el sistema se aproxima a la congestión. En otra realización de la presente invención, las prioridades de peticiones de acceso que no son aceptadas inmediatamente son comprobadas, y si hay posibilidades de pre-vaciar llamadas en curso con una prioridad menor para alcanzar suficientes recursos libres, tal pre-vaciado es llevado a cabo basándose en el grado de utilización de los recursos comparados con la porción asignada. En otra realización más, se manejan renegociaciones de llamadas en curso para aumentar la cantidad de recursos requerida como peticiones de acceso adicionales para la diferencia entre recursos pedidos y usados en ese momento.

La ventaja con la presente invención es que procedimientos relativamente simples pueden alcanzar una gestión de recursos limitados adecuada y eficiente. Además, los procedimientos pueden ser implementados en dispositivos, que son fácilmente integrados en o con el hardware existente en la actualidad.

Breve descripción de los dibujos

La invención, junto con otros objetos y ventajas adicionales de la misma, se puede comprender mejor haciendo referencia a la siguiente descripción tomada junto con los dibujos que se acompañan, en los cuales:

la Fig. 1 es un diagrama de bloques de un sistema de comunicaciones de telefonía móvil en el cual más de un operador comparte hardware dentro de la UTRAN (Universal mobile telecommunication system Terrestrial Radio Access Network - Red de Acceso por Radio Terrestre mediante un sistema de telecomunicación de telefonía móvil universal);

la Fig. 2 es un diagrama que ilustra la asignación y uso de recursos en un sistema de recursos compartidos;

la Fig. 3 es un diagrama de flujo que ilustra las principales etapas de un método de acuerdo con una realización de la presente invención;

la Fig. 4 es una parte de un diagrama de flujo que ilustra otra realización de la presente invención que soporta niveles de prioridad;

la Fig. 5 es un diagrama de flujo que ilustra una parte de la realización de la Fig. 4;

la Fig. 6 es un diagrama de flujo que ilustra otra parte de la realización de la Fig. 4;

la Fig. 7 es una parte de un diagrama de flujo que ilustra otra realización de la presente invención que soporta renegociaciones de recursos;

Fig. 8 es un diagrama que ilustra niveles de umbral en un sistema de congestión blanda de acuerdo con la presente invención;

la Fig. 9 es un diagrama de flujo que ilustra las principales etapas de un método de acuerdo con una realización de la presente invención que utiliza discriminación de congestión blanda;

la Fig. 10 es un diagrama de flujo que ilustra una parte de la realización de la Fig. 9; y

la Fig. 11 es un diagrama de bloques que ilustra una realización de una implementación de un dispositivo de acuerdo con la presente invención;

Descripción detallada

En la presente descripción, se considera una red de comunicaciones de telefonía móvil, en la cual más de un operador comparte algunos recursos de comunicación. Se asume en este contexto que a cada operador que está usando el recurso compartido se le asigna alguna proporción de los recursos. Esto ocurriría mediante algún acuerdo entre los operadores. Estas proporciones pueden ser configuradas en un elemento de red usando un sistema de gestión, por ejemplo.

Un ejemplo de una red de comunicaciones de telefonía móvil 10 con recursos compartidos se ilustra en la Fig. 1. Una red de núcleo 12 de un primer operador es conectada físicamente a un RNC (Radio Network Controller - Controlador de Red por Radio) 22 de una UTRAN 20. Asimismo una red de núcleo 14 de un segundo operador es conectada físicamente al RNC 22. La UTRAN 20 comprende también una estación de base por radio o Nodo B 25, físicamente conectado al RNC. El RNC 22 es un único dispositivo, pero sirve a ambos operadores de una manera más o menos independiente. La UTRAN 20 es así una UTRAN compartida.

En un plano lógico, el establecimiento tendrá un aspecto diferente. La parte asociada con el plano lógico está dibujada con líneas de trazos en la Fig. 1. En el plano lógico, la red de núcleo 12 del primer operador está conectada a un RNC lógico 23. La red de núcleo 14 está asimismo conectada a un RNC lógico 24 separado del RNC lógico 23. Cada RNC lógico 23, 24 tiene entonces nodos B lógicos 26, 27. Estos nodos B lógicos 26, 27 sirven entonces a las celdas 30 de los diferentes operadores. En el plano lógico, las redes de los dos operadores están separadas. No obstante, en la realización física, muchos dispositivos de hardware son usados en común, y también los recursos de comunicación disponibles pueden ser compartidos.

Cuando se administran los recursos compartidos, se deben considerar objetivos de alguna manera contradictorios. En primer lugar, puesto que los recursos compartidos en la mayoría de los casos están limitados en algún sentido, es altamente deseable que los recursos disponibles se usen lo más eficientemente posible. Si los recursos disponibles se dividen entre los diferentes operadores de una manera estricta, donde cada operador obtiene sus propios recursos y no puede utilizar ningún otro recurso, la eficiencia no está maximizada en un sentido global. Si uno de los operadores en una cierta ocasión requiere más recursos que su porción asignada y a otro operador al mismo tiempo le queda algún recurso de reserva, no sería posible "pedir prestados" temporalmente algunos recursos. La eficiencia global no está así maximizada. Por otro lado, si los recursos son gestionados juntos sin preocuparse de qué operador usa qué recurso, se puede terminar en una situación de congestión en la que a un operador se le deniegan recursos a pesar del hecho de que todavía no ha utilizado completamente su porción asignada. Es deseable tener control sobre cómo usan los recursos disponibles los diferentes operadores, particularmente en o cerca de situaciones de
congestión.

La idea básica de la presente invención es un planteamiento, que puede efectuar un control sobre la utilización de recursos entre los dos casos extremos. Para maximizar la eficiencia global, todas las conexiones son aceptadas durante situaciones de no congestión. Si está disponible un exceso de recursos, deben usarse, independientemente de para qué operador. Esto significa que un operador puede exceder la proporción acordada cuando los recursos son abundantes. No obstante, en o cerca de la congestión, definida de alguna manera, deben aplicarse otras reglas. De acuerdo con la presente invención, sólo se aceptan nuevas conexiones durante períodos de congestión si la proporción acordada del operador no se ha excedido.

El estado de congestión puede ser determinado de una manera sencilla. Si la utilización del recurso agregado excede algún valor, entonces el recurso está abocado a estar en congestión para los propósitos de la gestión del recurso compartido. Tal umbral de congestión es un parámetro configurable. Éste puede ser un parámetro estático que se configura usando un sistema de gestión, por ejemplo. No obstante, el umbral de congestión podría depender también de algunos otros parámetros, por ejemplo la hora del día, el día de la semana, una utilización media del recurso por los operadores etc.

Con el fin de proporcionar un ejemplo del comportamiento de un sistema de acuerdo con la presente invención, la Fig. 2 ilustra esquemáticamente los recursos compartidos de un sistema ficticio como un rectángulo. El área del rectángulo corresponde a los recursos totalmente disponibles C. En este ejemplo, tres operadores comparten los recursos. En un acuerdo entre los operadores, al operador 1 se le asigna una porción p1 de los recursos totales, es decir una cantidad de recursos C\cdotp1 está prevista para el operador 1. Asimismo, al operador 2 se le asigna una porción p2 de los recursos totales, es decir C\cdotp2. Finalmente, el operador 3 ha acordado utilizar sólo una cantidad de recursos correspondiente a C\cdotp3.

Se configura un umbral de congestión \beta. Por encima de este umbral, el sistema está en un estado de congestión, y deben realizarse acciones especiales con el fin de utilizar los recursos restantes de una manera ajustada. Con el fin de proporcionar otro ejemplo de la invención, se considera una situación de tráfico particular. Los recursos compartidos son utilizados por los tres operadores en diferentes cantidades, u_{1}, u_{2} y u_{3}, respectivamente. El rectángulo de la Fig. 2 está rayado de una manera correspondiente. Todavía queda disponible una cantidad de recursos libres \Delta. Se puede apreciar aquí que el operador 1 en este mismo momento excede su porción de los recursos acordada, puesto que u_{1} es mayor que C\cdotp_{1}. El operador 2 usa una cantidad de recursos menor que la proporción acordada y el operador 3 tiene una utilización del recurso que es aproximadamente igual a la porción acordada.

Considérense cuatro casos diferentes. En el primer caso, llega una nueva petición de acceso Ra para un cliente que utiliza servicios proporcionados por el operador 1. La petición de acceso requiere una cantidad de recursos correspondiente a r_{a}. r_{a} es menor que \Delta, así que hay suficientes recursos disponibles en el sistema total para manejar la nueva petición. No obstante, la petición de acceso utilizará una porción de los recursos tan grande que la utilización total excede el umbral de congestión \beta. Puesto que la petición de acceso viene desde el operador 1, que ya usa más de su porción de recursos asignada, los restantes recursos \Delta deben por el contrario estar "reservados" para el operador 2. La petición de acceso Ra es por lo tanto de acuerdo con la presente invención denegada.

En un segundo caso, llega una nueva petición de acceso Rb para un usuario conectado al operador 2. La petición de acceso requiere una cantidad de recursos correspondiente a r_{b}, que es igual a r_{a}. También aquí, r_{b} es menor que la cantidad de recursos libres \Delta, pero conduce a todo el sistema a un estado de congestión, puesto que el umbral de congestión se sobrepasará si la petición de acceso es aceptada. No obstante, el operador 2 no ha utilizado todavía toda su porción asignada de los recursos totales, y debe tener preferencia para los recursos restantes. La nueva petición de acceso es así aceptada, y el sistema va hacia un estado de congestión.

En un tercer caso, llega una nueva petición de acceso Rc para un usuario conectado al operador 2. La petición de acceso requiere una cantidad de recursos correspondiente a r_{c}, que es mayor que r_{b}. Aquí, r_{c} es también mayor que la cantidad de recursos libres \Delta, lo que significa que no hay posibilidades de aceptar la petición de acceso a menos que se lleve a cabo cualquier otra priorización y pre-vaciado de otras llamadas. En una versión básica de la presente invención, la petición de acceso es denegada.

En un cuarto caso, llega una nueva petición de acceso Rd para un usuario conectado al operador 1. La petición de acceso requiere una cantidad de recursos correspondientes a r_{d}, que es menor que r_{a}. r_{d} es por supuesto menor que la cantidad de recursos libres \Delta, y es también suficientemente pequeña para no llevar a todo el sistema a un estado de congestión. Incluso si la petición de acceso Rd es aceptada, la cantidad total de recursos utilizados está por debajo del umbral de congestión \beta. Con el fin de maximizar la eficiencia global, la petición de acceso es aceptada, aunque el operador 1 ya ha excedido su porción asignada.

La Fig. 3 ilustra un diagrama de flujo de las principales etapas en una realización de un método de acuerdo con una realización de la presente invención; El procedimiento empieza en la etapa 200. En la etapa 202, se recibe una petición de acceso desde un cierto operador. La petición de acceso tiene una cantidad de recursos requerida asociada. Alternativas de esta etapa se explican también más adelante. En la etapa 204, se determina si la cantidad de recursos requerida asociada de la petición de acceso es menor que la cantidad de recursos libres totales en el sistema. Si la cantidad de recursos requerida es demasiado grande, el procedimiento continúa hasta los procedimientos de rechazo (etapa 212) descritos con más detalle a continuación. Si por el contrario hay suficientes recursos libres, el procedimiento continúa hacia la etapa 206.

En la etapa 206, se lleva a cabo una segunda determinación, donde se comprueba si el sistema estará congestionado o no. En una realización, se comprueba si los recursos totales utilizados serán mayores que el umbral de congestión si la petición de acceso es aceptada. La comprobación es así una comprobación de una situación después de una aceptación asumida de la petición de acceso. Si la utilización es suficientemente baja, lo que significa que una considerable cantidad de recursos está disponible, en esta realización todas las peticiones de acceso serán aceptadas, y el proceso por lo tanto continúa hacia la etapa 210. No obstante, si el sistema está cerca de la congestión y la cantidad total de recursos utilizados incluyendo el nuevo acceso propuesto excede el umbral de congestión, entran en acción otras reglas de selección. El procedimiento por lo tanto continúa hacia la etapa 208.

En otra realización, la comprobación de congestión se lleva a cabo sin considerar el efecto de la presente petición de acceso, es decir si el sistema ya está congestionado, como se define por el umbral de congestión. La comprobación es así una comprobación de una situación antes de una aceptación asumida de la petición de acceso. Resulta evidente que para tal planteamiento, el umbral debe establecerse menor que el nivel de congestión con el fin de alcanzar un comportamiento correspondiente como en la primera realización descrita anteriormente, para una cantidad correspondiente a la cantidad de recursos requeridos. Si se desea evitar el uso de diferentes umbrales para diferentes llamadas, el umbral podría por ejemplo ser establecido esencialmente igual al nivel de congestión menos un tamaño medio de las cantidades de recursos requeridas para peticiones de acceso.

Cuando se llega a la etapa 208, es evidente que no hay suficientes recursos disponibles sino que el sistema va hacia la congestión si la petición de acceso es aceptada o ya está en congestión (como se define por el umbral). En tal situación, los operadores que no hayan usado completamente su porción asignada de los recursos totales deben tener preferencia para la restante pequeña cantidad de recursos. En la etapa 208 está por lo tanto en una realización determinada si el operador en cuestión excede su porción de recursos si la petición de acceso es aceptada. La determinación es así una determinación de una situación después de una aceptación asumida de la petición de acceso. Si ese es el caso, la petición de acceso será un objeto para el procedimiento de rechazo de la etapa 212 y los recursos restantes serán ahorrados en un caso típico para ser usados para operadores que tienen un menor grado de utilización de sus recursos asignados. Si la determinación encuentra que el operador tiene recursos restantes hasta su porción asignada, la conexión será aceptada y el procedimiento continúa de este modo hacia la etapa 210.

En otra realización, la determinación de la utilización es llevada a cabo sin considerar el efecto de la presente petición de acceso, es decir si el operador ya ha excedido el nivel de utilización acordado, tal como se define por la porción asignada. La determinación es de este modo una determinación de una situación antes de cualquier aceptación asumida de la petición de acceso. Si se desea lograr exactamente las mismas propiedades que anteriormente, el valor de umbral debe ajustarse para la cantidad de recursos requerida. El umbral podría también ser ajustado por ejemplo igual a la porción de recursos asignada al operador en cuestión menos una cantidad de recursos requerida media para peticiones de acceso.

Cualquier experto se da cuenta de que el comportamiento de la gestión del recurso puede ser finamente ajustado ajustando los umbrales. El primer umbral, es decir correspondiente al nivel de congestión proporciona la principal dependencia. Un alto umbral de congestión favorecerá una eficiente utilización a costa de la adecuación de la división del recurso entre los operadores. Un bajo umbral de congestión por el contrario aumentará la importancia de mantener a cada operador dentro de la porción acordada y reducirá la importancia de la eficiencia global. El segundo umbral, es decir el umbral asociado con cada operador individual puede ser también pre-sintonizado. Utilizar el primer planteamiento de determinación de utilización con conexión entrante dará más peso a mantener la utilización estrictamente por debajo del nivel acordado, mientras que el segundo planteamiento sólo de determinación de utilización permitirá exceder la porción acordada, pero sólo con menos de una llamada aceptada. Estableciendo una diferencia del umbral con respecto al nivel de utilización acordado, puede conseguirse también aquí una sintonización fina.

En la etapa 210, la petición de acceso es aceptada. Al mismo tiempo, todos los valores de utilización almacenados son actualizados de acuerdo con ella. El procedimiento se finaliza entonces en la etapa 299.

En la etapa 212 se lleva a cabo un procedimiento de rechazo. En sistemas sin niveles de prioridad para las peticiones de acceso, la petición de acceso es simplemente rechazada y el procedimiento finaliza entonces en la etapa 299. No obstante, si se aplica la prioridad de llamada, deben aplicarse procedimientos adicionales. Ejemplos de tales procedimientos se presentan en realizaciones alternativas a continuación.

Las líneas de trazos indican posibles rutas de flujo para realizaciones alternativas descritas a continuación.

La realización del método de acuerdo con la Fig. 3 puede también expresarse en términos más matemáticos. Sea C la cantidad total de recursos y r la cantidad de los recursos requeridos por la conexión que está solicitando acceso a la red. Asúmase además que hay n operadores compartiendo la red. u_{i}(t) \in [0,1] denota la fracción del recurso total que está en uso por el operador i en el tiempo t. p_{i} \in [0,1] es la proporción de recursos asignada al operador i, y en un caso típico 1.

Finalmente \beta \in [0,1] es el umbral de congestión. El procedimiento puede describirse como sigue:

Una conexión entrante o petición de acceso desde el operador i es recibida. La petición de acceso requiere r unidades de los recursos disponibles. Una primera determinación es llevada a cabo si se cumple la siguiente desigualdad:

2

si están disponibles suficientes recursos, la siguiente determinación se refiere a la desigualdad:

3

donde T_{c} es un primer umbral. El umbral T_{c} es seleccionado en una realización preferida como:

4

y es seleccionado en otra realización preferida como:

5

El umbral puede ser también seleccionado de otras maneras, ajustando finamente las propiedades de la gestión de recursos. Se concluye que el sistema está en congestión si se cumple la desigualdad (1). Si se concluye que el sistema no está en congestión, la petición de acceso es aceptada; si no, se evalúa una tercera desigualdad:

6

donde T_{i} es un segundo umbral para el operador en cuestión. El umbral T_{i} es seleccionado en una realización preferida como:

7

y es seleccionado en otra realización preferida como:

8

Pueden usarse también otros valores de T_{i}, preferiblemente entre los dos presentados aquí anteriormente, para sintonizar adecuadamente el comportamiento de la gestión de recursos.

Puesto que las cantidades u_{i}(t) se usan frecuentemente, son almacenadas preferiblemente entre diferentes peticiones de acceso. Estas cantidades tienen así que ser actualizadas cuando el uso del recurso cambia. Si la petición de acceso es aceptada, la u_{i}(t) es actualizada como:

9

Preferiblemente, también la cantidad 10 es almacenada y también es actualizada cuando se acepta una petición de acceso.

La utilización u_{i}(t) almacenada está también influenciada por otras actividades. Cuando una conexión que pertenece al operador i que utiliza r unidades de recursos se libera, el grado de utilización debe ser adaptado de acuerdo con:

11

Los procedimientos anteriores operan bien para situaciones en las cuales la asignación de recursos es lineal o casi lineal. No obstante, cuando la no-linealidad de la asignación de recursos en un sistema aumenta, los procedimientos básicos descritos anteriormente deben ser ligeramente modificados. En tal caso, puede aplicarse un mecanismo de actualización de acuerdo con una realización preferida de la presente invención. El modelo de asignación de recursos lineal descrito anteriormente puede así utilizarse para modelizar los esquemas de asignación que son no lineales en algunos casos. El rendimiento del sistema puede ser mejorado si hay comunicación entre el módulo descrito anteriormente y otro módulo que puede mantener una medida más exacta de la utilización del recurso no lineal.

Asúmase que un módulo opera de acuerdo con un modelo lineal, aunque, el sistema actual tiene un comportamiento ligeramente no lineal. Asúmase también que hay otro módulo, externo al módulo que incorpora la gestión del recurso compartido, que puede obtener información de utilización del recurso más exacta. Tal información puede ser obtenida de diferentes partes de una red. Al módulo de base se le proporciona esta información de recurso actualizada y se le incluye también esta información para maximizar la eficiencia y la adecuación. Considérese un caso, en el que el módulo de gestión de recursos recibe información de que el número de unidades de todos los recursos disponibles actualmente es C'

\hbox{cuando el módulo de base lo percibe como C. En este caso,
la utilización   u _{i}  ( t ) debe ser actualizada
como:}

12

para cada operador i.

En muchas redes de comunicaciones de telefonía móvil, las llamadas están a menudo asociadas a diferentes niveles de prioridad. Una llamada de una prioridad alta debe tener preferencia frente a llamadas de menor prioridad. Existe un número bastante grande de planteamientos diferentes para gestionar conexiones de prioridad en diferentes sistemas, algunos de los cuales son bastante complejos. Además, los mecanismos de prioridad pueden ser configurados de diferentes maneras, dependiendo de cómo elija el operador la red.

Un método y dispositivo para gestionar recursos de acuerdo con la presente invención puede ser fácilmente modificado para incorporar también manejo de prioridad. Se describirá aquí a continuación una realización, que permite peticiones de conexión de alta prioridad para acceder a los recursos a costa de conexiones de menor prioridad, si es necesario. Puesto que esto puede implicar un pre-vaciado de llamadas, es útil integrar esto con las funciones que detectan la naturaleza compartida de los recursos con el fin de tratar de asegurar que los recursos son compartidos de acuerdo con la política acordada por los operadores. La decisión más importante que es necesario tomar en este caso es determinar qué llamada o llamadas necesitan ser finalizadas prematuramente. Específicamente, puede ser deseable diferenciar entre conexiones basándose en a qué operador están asociadas.

Mientras que la intención aquí es permitir compartir mecanismos para ser introducidos en un esquema de priorización de una manera razonablemente genérica, debe observarse que se han hecho algunas asunciones en el diseño de esta realización lo que significa que no es arbitrariamente flexible. Estas asunciones se han hecho para minimizar el acoplamiento entre los mecanismos de compartir y de prioridad y también asegurar que el sistema no resulta demasiado complejo.

El esquema propuesto en la presente realización está diseñado para un entorno en el cual hay una pequeña cantidad de conexiones de prioridad, es decir la mayoría de las conexiones tienen la misma prioridad con unas pocas excepciones que tienen una prioridad más alta. Este es el caso en la mayoría de las redes de telefonía móvil hoy en día. Es de gran importancia que las peticiones de conexión de prioridad ganen acceso a la red - típicamente hay un uso de emergencia - y por lo tanto puedan pre-vaciar llamadas de menor prioridad.

El planteamiento extendido para el control de la admisión que es aplicable en el caso de conexiones de prioridad sigue el diagrama de flujo básico de la Fig. 3, no obstante, incluyendo la ruta del flujo entre las etapas 212 y 210 (que se ilustraba mediante una línea de trazos en la Fig. 3). El manejo de las cuestiones de prioridad se incorpora en el procedimiento de rechazo de la etapa 212. Una parte detallada del diagrama de flujo de la etapa 212 se ilustra en la Fig. 4. La principal etapa 212 se ilustra aquí como una caja abierta y comprende varias sub-etapas. El flujo del procedimiento entra en la etapa 212 desde la etapa 204 ó 208 en la Fig. 3. (También puede alcanzarse desde una etapa 207, explicada también a continuación.) En la primera sub-etapa, la etapa 213, se concluye si la petición de acceso es de la menor prioridad. En tal caso, ningún procedimiento de pre-vaciado resulta útil y la petición de acceso debe rechazarse en la etapa 218. Si la prioridad no es la más baja, el procedimiento continúa a la etapa 214, en la que todos los recursos de una prioridad más baja que la prioridad de la nueva petición de acceso ocupados actualmente se suman, y todos los recursos libres se añaden a este suma. Esto proporciona una cantidad de recursos disponibles total que puede ser usada por la petición de acceso. En la etapa 216, se comprueba si esta suma es mayor que la cantidad de recursos requerida de la nueva petición de acceso. Si ese no es el caso, cualquier pre-vaciado resulta inútil y la petición de acceso tiene que ser rechazada en la etapa 218 a pesar de la alta prioridad. Si el pre-vaciado resolviese el problema de la falta de recursos, un procedimiento de pre-vaciado se lleva a cabo en la etapa 220 y el flujo del procedimiento continuará entonces hacia la etapa 210 de la Fig. 3 para finalizar la aceptación de la petición de acceso, puesto que ahora hay recursos disponibles.

El diagrama de flujo anterior puede expresarse también como sigue. En el caso de conexiones de prioridad, no es suficiente determinar si hay suficiente capacidad no usada en el sistema o no como criterio para determinar si el sistema puede albergar la nueva petición de conexión o no. Podría darse el caso de que haya insuficiente capacidad libre en el sistema para la conexión entrante, pero debido a que es una conexión de prioridad alta, debería ser aceptada para el sistema. Así, si la prueba inicial para capacidad libre devuelve un resultado negativo, se lleva a cabo una comprobación para ver si la capacidad agregada usada por las conexiones de menor prioridad es menor que la capacidad solicitada por la conexión entrante. Si lo es, entonces es posible aceptar la conexión de prioridad mayor entrante pre-vaciando algunas conexiones de prioridad menor. El planteamiento para determinar la capacidad agregada consumida por las conexiones de prioridad menor se puede realizar de manera bastante sencilla. Una realización de esta parte de la etapa se ilustra en la Fig. 5.

El flujo del procedimiento llega desde la etapa 213. En la etapa 230, se inicia una suma a cero y se establece un parámetro de prioridad a la prioridad más baja. En la etapa 232, la cantidad de recursos ocupados por conexiones que tienen una prioridad igual al parámetro de prioridad es añadida a la suma. El parámetro de prioridad es incrementado a continuación un paso en la etapa 234. En la etapa 236, se investiga si el parámetro de prioridad es igual a la prioridad de la petición de acceso. Si ese no es el caso, el flujo vuelve a la etapa 232 para añadir más recursos. Si la prioridad de la petición de acceso se alcanza, el procedimiento continúa hacia la etapa 238, en la que todos los recursos libres son añadidos a la suma. El procedimiento continúa entonces con la etapa 216 de la Fig. 4.

Si la capacidad usada por las conexiones de prioridad menor es menor que la capacidad requerida para la conexión entrante, entonces la petición de conexión entrante no puede ser albergada. Si, no obstante, lo contrario es cierto, entonces la petición de conexión entrante puede ser aceptada si algunas conexiones existentes son rechazadas desde el sistema.

En la etapa 220 de la Fig. 4, se lleva a cabo un procedimiento para determinar qué conexiones deben ser eliminadas del sistema. Una realización de esta etapa se ilustra en la Fig. 6. El flujo del procedimiento llega desde la etapa 216. En la etapa 222, se inicia una suma como la cantidad de recursos libres en el sistema, y un parámetro de prioridad P es puesto a la prioridad de la petición de acceso. En la etapa 224, se determina qué operador de entre los operadores que tienen algunas conexiones o llamadas de prioridad menor que P que exceden en mucho su porción asignada o utilización de recursos de objetivo acordada. Se selecciona una llamada desde este operador, preferiblemente del nivel de prioridad más bajo posible, en la etapa 226. En la etapa 228, esta conexión es liberada y la cantidad de recursos liberados es añadida a la suma. En la etapa 229, se determina entonces si el pre-vaciado llevado a cabo es suficiente o si deben llevarse a cabo otras acciones de pre-vaciado. Cuando se logran suficientes recursos libres, el procedimiento continúa hacia la etapa 210 de la Fig. 3.

Cualquier experto se da cuenta de que pueden considerarse aquí diferentes variantes de procedimientos. La realización anterior es una, que intenta mantener el equilibrio de carga apropiado entre los operadores cuando determina qué conexiones eliminar del sistema. El procedimiento funciona para determinar qué operador sobrepasa en mucho su utilización de objetivo. Este operador debe hacer sitio para la conexión entrante eliminando una de sus conexiones del sistema. Puede elegirse cualquier regla para esto, pero una regla razonable usada en la presente realización es rechazar una conexión con la prioridad lo más baja posible. Una alternativa podría ser buscar una conexión que utilice justo la capacidad suficiente para permitir la llamada de prioridad alta. Este procedimiento se repite, siendo cada vez eliminada una conexión hasta que hay suficiente capacidad disponible para la conexión entrante.

Debe observarse que este planteamiento no garantiza asegurar que los recursos son compartidos de acuerdo con la política definida, puesto que llamadas de una prioridad más alta pueden pre-vaciar llamadas de una prioridad más baja de otros operadores. Tómese, por ejemplo, la situación extrema en la que un operador genere sólo llamadas de prioridad alta y las otras conexiones de prioridad baja durante algún período de tiempo. Si las velocidades de llegada son suficientemente altas, el operador que está generando las conexiones de prioridad alta consumirá finalmente todos los recursos.

Esta fue una decisión de diseño en la realización anterior. Puesto que se asumió que la frecuencia de las llamadas de prioridad alta sería bastante baja, no es necesario tener un mecanismo muy complejo, que integre los dos recursos de compartir y de prioridad.

En algunos casos, un terminal o la red pueden desear renegociar la cantidad de recursos asignada a una conexión particular. Las funciones de asignación de recursos compartidos deben ser capaces de tratar con esta eventualidad. En un primer planteamiento, la gestión de la asignación de los recursos compartidos no influye en la decisión de ajustar los recursos asignados a la conexión. Se asume entonces que tales ajustes son típicamente raros y son en general relativamente pequeños. En tal caso, los ajustes simplemente se llevan a cabo.

No obstante, podría haber problemas cuando el sistema alcanza las condiciones de congestión. Por lo tanto, se describe aquí una realización de un procedimiento para tratar con esto dentro del marco de los recursos compartidos. Las funciones de asignación de recursos compartidos influyen entonces en la decisión de ajustar los recursos asignados a la conexión.

Esta realización puede ser vista como una variante de la realización de la Fig. 3, en la que la etapa 202 está provista de algunas características adicionales. La ruta del flujo entre la etapa 202 y la etapa 299 resulta entonces útil. La etapa 202 de acuerdo con la realización de renegociación se ilustra en la Fig. 7. En la etapa 240, se calcula la diferencia entre la capacidad de recursos presente de la conexión y la solicitada. Si la renegociación implica una disminución del tamaño, como se determina en la etapa 242, no influirá en el resto del procedimiento de los recursos compartidos. La conexión es entonces actualizada en la etapa 244 y el procedimiento continúa directamente hacia la etapa 299 (Fig. 3). No obstante, si se solicita una mayor cantidad de recursos, debe tomarse una decisión en la misma dirección como para una nueva conexión. En la etapa 246, se proporciona una petición de una solicitud de acceso adicional, que tiene requisitos de recurso iguales a la diferencia entre el tamaño solicitado y el presente. Esta petición de acceso adicional es tratada a continuación mediante los procedimientos normales, como se ilustra en la Fig. 3.

Los principios están bastante claros. Si la velocidad de bits de una conexión particular debe ser reducida, entonces los parámetros de utilización simplemente son actualizados. Si la velocidad de bits de un canal particular debe ser aumentada, entonces es necesario ejecutar los principios de asignación de recurso compartido siendo la velocidad de diferencia la velocidad de entrada. Se toma una decisión con respecto a si el incremento de la utilización de recursos está permitido o no. Los parámetros de utilización son adaptados de acuerdo con esto añadiendo \Deltar/C=(r'-r)/C a la utilización actual para el operador apropiado, donde r' es la cantidad de recursos requerida por la conexión renegociada y r es la cantidad de recursos usada por la conexión original.

En la realización de la presente invención descrita junto con la Fig. 3, el umbral de congestión puede describirse como un umbral duro. Esto es porque hasta el punto de congestión una conexión de cualquier tamaño será aceptada por cualquier operador. Esto, no obstante, significa que un operador puede ocupar una gran porción de los recursos disponibles cuando se acerca una congestión dura, que puede contrarrestar la intención de seguir la división de recursos acordada en la congestión. En otra realización de la presente invención, se introduce un concepto de umbral de congestión blando. La congestión blanda es un umbral que es menor que el valor de la congestión dura. Cuando se excede el umbral de congestión blando, no todas las peticiones de acceso son rechazadas, sólo las más grandes. En otras palabras, sólo son aceptadas las conexiones hasta un cierto tamaño. Pueden establecerse varios umbrales de congestión blandos. Para cada umbral, también se configura el tamaño de la conexión más grande permitida. Estos parámetros son preferiblemente estáticos y pueden ser definidos por un sistema de gestión.

La Fig. 8 ilustra los principios básicos de los umbrales de congestión blandos. En el rectángulo que representa la cantidad total de recursos, el umbral de congestión duro \beta está todavía presente, relativamente cerca al máximo. No obstante, se ilustran también tres umbrales de congestión de filtro \alpha_{1}, \alpha_{2} y \alpha_{3} adicionales. Para cada uno de estos umbrales, se establece un tamaño máximo \xi_{1}, \xi_{2} y \xi_{3} aceptado respectivamente. Si el grado de utilización total excede el umbral \alpha3, sólo son aceptadas peticiones de acceso de tamaños menores de \xi_{3}. De manera similar, si el grado de utilización total excede el umbral \alpha_{2}, sólo son aceptadas peticiones de acceso de tamaños menores de \xi_{2}, y si el grado de utilización total excede el umbral \alpha_{1}, sólo son aceptadas peticiones de acceso de tamaños menores de \xi_{1}.

Estos umbrales de congestión blandos pueden ser incorporados en un diagrama de flujo, ilustrado en la Fig. 9. Las etapas, que están en común con la Fig. 3 son básicamente las mismas no se explican más. La principal diferencia es la etapa 207. Si se concluye que no existe congestión en la etapa 206, el flujo continúa hacia la etapa 207. En esta etapa, se lleva a cabo una discriminación de tamaño de acuerdo con los principios de la congestión blanda. Si el tamaño requerido de la petición de acceso es demasiado grande, la petición de acceso se convierte en el objeto de un procedimiento de rechazo (etapa 212). Si la petición de acceso es suficientemente pequeña, la petición de acceso será aceptada y el procedimiento continúa hacia la etapa 210.

En la Fig. 10, se ilustran los detalles de la etapa 207. En la etapa 250, se determina una clase de umbral para el sistema, que en principio denota que umbral de congestión blando \alpha_{n} va a usarse. Cada clase de umbral está asociada con un coste máximo \xi_{n}, que expresa el tamaño máximo que va a ser aceptado. Si el coste de la conexión, es decir el tamaño de la petición de acceso, se determina en la etapa 252 que es mayor que el máximo coste para esa clase de umbral particular, la petición de acceso es rechazada (etapa 212). De lo contrario la petición de acceso es aceptada (etapa 210).

En una descripción más matemática, donde m>0 es el número total de umbrales de congestión blandos, j \in 1...m son los identificadores de clase de umbral, \alpha_{j} \in [0,1] son los valores de umbral de congestión blando para la clase de umbral j, \xi_{j} es la mayor conexión permisible cuando está en un estado de congestión blanda para la clase de umbral j, y donde los valores de congestión blanda son clasificados como \alpha_{k} < \alpha_{j} para k < j, k \in 1...m, los umbrales de congestión blandos son menores que los umbrales de congestión duros \alpha_{j} < \beta. Se recibe una petición de acceso y en las etapas 204 y 206, se concluye que hay suficientes recursos libres y el sistema no está muy congestionado. El inicio con j = m y la disminución con una etapa en el momento hasta que se cumple la siguiente condición:

13

donde T^{s}_{j} es un umbral asociado con el umbral de congestión blando \alpha_{j}, preferiblemente por la relación:

14

si se cumple la condición, entonces j se encuentra (de otra modo la petición de acceso es aceptada directamente). Ahora determínese si esta conexión está permitida para la clase de umbral j. Si

15

Entonces el coste de conexión excede el máximo coste permitido para la clase de umbral j y la petición de acceso es rechazada. De lo contrario, la petición de acceso es aceptada.

Los métodos explicados anteriormente pueden ser implementados de diferentes maneras en el sistema de comunicaciones móviles. En un sistema que tiene una UTRAN compartida, es, no obstante, preferido implementar el planteamiento en la conexión de RNC con las funcionalidades de gestión de recursos del Nodo B.

En una UTRAN compartida, cada operador tiene su propio ancho de banda y celdas de frecuencia. Cada operador comparte entonces sitio, transmisión, hardware, software, manejo de alarmas y situación tanto para la Estación de Base de Radio (Nodo B) como para el Radio Network Controller (RNC - Controlador de Red de Radio), como se ilustra en la Fig. 1. Un Nodo B compartido puede tener celdas de más de un operador. Los recursos de banda de base del Nodo B son un recurso restringido, que puede ser compartido entre todas las celdas del Nodo B. La Fig. 11 ilustra un Nodo B 25 y un RNC 22 de un sistema de recursos compartidos. La gestión de la conexión entre el Nodo B 25 y un teléfono móvil, es decir la interfaz Ue, se lleva a cabo en una unidad de gestión de la conexión en una Ue 40 en el Nodo B 25. La asignación de los recursos de la banda de base por una función de gestión de la capacidad 42 en el RNC 22.

El Nodo B 25 informa sobre los recursos disponibles como el número total de créditos al RNC 22. El Nodo B 25 informa también sobre el coste de asignación de un canal de radio con un factor de propagación particular en términos de un número de los llamados créditos. Se informa de este coste a todos los factores de propagación disponibles. Esta información puede ser utilizada por el RNC 22 para tomar decisiones de gestión de capacidad. El RNC 22 mantiene una imagen de la utilización de recursos del Nodo B 25 basada en el número de créditos usados. Esta imagen puede desviarse del uso de recursos real y el Nodo B 25 puede informar al RNC 22 para enviar valores nuevos para los costes totales de los factores de propagación y crédito. Esto se define en el 3G TS 25:433 NBAP Signalling Protocol Standard, secciones 8.7.7, 8.2.15, 9.2.1.9A, y 9.2.1.20A [2].

El problema de la gestión de los recursos compartidos descrito anteriormente mapea el problema de gestionar los recursos de banda de base en un Nodo B 25. En la UTRAN, la gestión de recursos del hardware del Nodo B 44 se realiza ampliamente en el RNC 22. Un diseño de RNC 22 típico de hoy en día incluiría algunas funciones de gestión de la capacidad del Nodo B, pero éstas habrían estado diseñadas para el caso del operador único. Para gestionar los recursos en el entorno compartido, deben suministrarse funciones adicionales para gestión de recursos compartidos 46, bien como una parte integrada de la gestión de recursos de hardware 44 o bien como una funcionalidad adicional. Cuando el Nodo B necesita una nueva conexión, se envía una nueva petición de conexión o petición de acceso al RNC. El RNC utiliza las funciones 44 y 46 y proporciona una respuesta de nuevo al Nodo B.

Hay dos pre-requisitos que han de cumplirse antes de aplicar los procedimientos de la presente invención. Se informa al Nodo B de la información de crédito total por enlace ascendente y por enlace descendente separadamente. El Nodo B informa sobre la información de crédito total para un grupo de celdas, puesto que los procedimientos están diseñados para compartir recursos en el grupo de celdas.

Si la figura de la utilización de recursos del RNC difiere de la del Nodo B, el Nodo B puede notificarla al RNC. El procedimiento de actualización descrito anteriormente puede ser invocado cada vez que el RNC recibe tal actualización. El procedimiento de renegociación descrito anteriormente puede ser invocado siempre que sea necesario renegociar la capacidad de una conexión, si es iniciada por la red o por el terminal. Finalmente la solución de la congestión blanda es opcional y puede ser introducida como parte del mecanismo si se desea.

La invención es un planteamiento para gestionar recursos compartidos en redes compartidas. Por ello, es aplicable en cualquier caso donde haya un planteamiento lineal o no lineal para la asignación de recursos usada en un contexto de red compartida.

El planteamiento puede ser aplicado directamente en el escenario concreto de gestionar recursos de banda de base del Nodo B compartidos en una UTRAN compartida. Esto se realiza en el RNC y la explicación anterior describe cómo interactúan las nuevas funciones con las funciones de gestión de la capacidad existentes para efectuar un control sobre recursos compartidos.

Los expertos comprenderán que pueden hacerse varias modificaciones y cambios a las realizaciones preferidas presentadas anteriormente sin separarse del ámbito de la invención, que está definida únicamente por las reivindicaciones dependientes.

Referencias

[1] Shared Networks for WCDMA, Solution Description, Abril de 2003, URL:http://productselector.ericsson.se

[2] 3 GPP TS 25:433; 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN lub interface NBAP signalling (versión 5), secciones 8.2.7, 8.2.15, 9.2.1.9A, y 9.2.1.20A.

Claims

1. Método para gestionar recursos en un sistema de comunicación (10) que tiene recursos compartidos por al menos dos operadores (12, 14), que comprende las etapas de:

recibir una petición de acceso para un primer operador de los al menos dos operadores (12, 14); y

ejecutar una primera determinación si hay suficiente cantidad de recursos libres disponibles en el sistema de comunicación (10),

caracterizado por las otras etapas de:

ejecutar una segunda determinación si una cantidad total de los citados recursos compartidos por al menos dos operadores en uso en el sistema de comunicación (10) excede un primer umbral;

ejecutar una tercera determinación si una cantidad total de los citados recursos compartidos por al menos dos operadores en uso para el primer operador excede un segundo umbral; y

decidir sobre aceptar la petición de acceso basándose en los resultados de las determinaciones primera, segunda y tercera.

2. Método de acuerdo con la reivindicación 1, caracterizado porque la etapa de ejecutar la segunda determinación se lleva a cabo sólo si la primera determinación muestra que hay suficientes recursos libres disponibles en el sistema de comunicación (10).

3. Método de acuerdo con la reivindicación 1 ó 2, caracterizado porque la petición de acceso es aceptada si la segunda determinación muestra que la cantidad total de recursos en uso en el sistema de comunicación (10) no excede el primer umbral.

4. Método de acuerdo con la reivindicación 1 ó 2, caracterizado por la discriminación de tamaño basada en la capacidad pedida por la conexión entrante dependiente de la cantidad total de recursos en uso en el sistema de comunicación (10) si la segunda determinación muestra que la cantidad total de recursos en uso en el sistema de comunicación (10) no excede el primer umbral.

5. Método de acuerdo con la reivindicación 4, caracterizado porque la discriminación de tamaño comprende las etapas de:

determinación de una clase de umbral dependiente de la cantidad total de recursos en uso en el sistema de comunicación (10);

comparar una cantidad de recursos requerida por la petición de acceso con un tamaño aceptado máximo (\xi_{1}, \xi_{2}, \xi_{3}) asociado con la clase de umbral determinada;

aceptar la petición de acceso si la cantidad de recursos (r_{a}-r_{d}) requerida por la petición de acceso es menor que o igual al tamaño aceptado máximo (\xi_{1}, \xi_{2}, \xi_{3}); y

rechazar la petición de acceso si la cantidad de recursos (r_{a}-r_{d}) requerida por la petición de acceso es mayor que el tamaño aceptado máximo (\xi_{1}, \xi_{2}, \xi_{3}).

6. Método de acuerdo con cualquiera de las reivindicaciones 2 a 5, caracterizado porque la etapa de ejecutar la tercera determinación se lleva a cabo sólo si la segunda determinación muestra que la cantidad total de recursos en uso en el sistema de comunicación excede el primer umbral.

7. Método de acuerdo con la reivindicación 6, caracterizado porque la petición de acceso es aceptada si la tercera determinación muestra que la cantidad total de recursos en uso para el primer operador no excede el segundo
umbral.

8. Método de acuerdo con cualquiera de las reivindicaciones 1 a 7, caracterizado porque el primer umbral es igual a un umbral de congestión (\beta) pre-determinado.

9. Método de acuerdo con cualquiera de las reivindicaciones 1 a 7, caracterizado porque el primer umbral es igual a un umbral de congestión (\beta) pre-determinado menos la cantidad de recursos (r/C) requerida por la petición de acceso.

10. Método de acuerdo con cualquiera de las reivindicaciones 1 a 9, caracterizado porque el segundo umbral es igual a una porción de los recursos totales pre-determinada asignada al primer operador (p_{1}, p_{2}, p_{3}).

11. Método de acuerdo con cualquiera de las reivindicaciones 1 a 9, caracterizado porque el segundo umbral es igual a una porción de los recursos totales pre-determinada asignada al primer operador (p_{1}, p_{2}, p_{3}) menos la cantidad de recursos (r/C) requerida por la petición de acceso.

12. Método de acuerdo con cualquiera de las reivindicaciones 1 a 11, caracterizado por almacenar una medición respectiva (u_{i}) de la fracción de recursos actualmente en uso por cada uno de los citados al menos dos operadores (12, 14), siendo la citada medición (u_{i}) para el primer operador actualizada cuando se acepta la petición de acceso o cuando una conexión para el primer operador se termina.

13. Método de acuerdo con la reivindicación 12, caracterizado por actualizar las respectivas mediciones (u_{i}) por medio de la información sobre la utilización de recursos desde una fuente externa.

14. Método de acuerdo con cualquiera de las reivindicaciones 1 a 13, caracterizado porque la petición de acceso es rechazada si la primera determinación muestra que no hay suficientes recursos libres disponibles en el sistema de comunicación (10) o si la tercera determinación muestra que la cantidad total de recursos en uso para el primer operador excede el segundo umbral.

15. Método de acuerdo con cualquiera de las reivindicaciones 1 a 13, caracterizado por una etapa de evaluar una prioridad de la petición de acceso si la primera determinación muestra que no hay suficientes recursos libres disponibles en el sistema de comunicación (10) o si la tercera determinación muestra que la cantidad total de recursos en uso para el primer operador excede el segundo umbral.

16. Método de acuerdo con la reivindicación 15, caracterizado porque la etapa de evaluar la prioridad comprende las etapas de:

ejecutar una cuarta determinación si la suma de los recursos libres disponibles en el sistema de comunicación (10) y un cantidad total de recursos que están ocupados por tráfico que tiene una prioridad menor que la prioridad de la petición de acceso para el primer operador es menor que la cantidad de recursos requerida por la petición de acceso para el primer operador;

rechazar la petición de acceso si la cuarta determinación muestra que la suma de los recursos libres disponibles en el sistema de comunicación (10) y la cantidad total de recursos que están ocupados por tráfico que tiene una prioridad menor que la prioridad de la petición de acceso para el primer operador es menor que la cantidad de recursos requerida por la petición de acceso para el primer operador; y

pre-vaciar suficiente tráfico en curso para permitir la petición de acceso para el primer operador si la cuarta determinación muestra que la suma de los recursos libres disponibles en el sistema de comunicación (10) y la cantidad total de recursos que están ocupados por tráfico que tienen una prioridad menor que la prioridad de la petición de acceso para el primer operador es igual a o mayor que la cantidad de recursos requeridos para la petición de acceso para el primer operador, y aceptar la petición de acceso.

17. Método de acuerdo con la reivindicación 16, caracterizado porque la etapa de pre-vaciar comprende a su vez las etapas de:

determinar qué operador de los al menos dos operadores (12, 14) que actualmente exceden más su utilización de recursos de objetivo;

seleccionar una conexión del operador de los al menos dos operadores (12, 14) que actualmente exceden más su utilización de recursos de objetivo que tienen una prioridad menor que la prioridad de la petición de acceso para el primer operador;

liberar la conexión seleccionada;

determinar si los recursos requeridos para la petición de acceso es mayor que los recursos libres disponibles en el sistema de comunicación (10); y

repetir las etapas previas si los recursos requeridos para la petición de acceso son mayores que los recursos libres disponibles en el sistema de comunicación (10);

18. Método de acuerdo con cualquiera de las reivindicaciones 1 a 17, caracterizado porque la etapa de recibir una petición de acceso para el primer operador a su vez comprende las etapas de:

recibir una petición de renegociación para una llamada en curso desde el primer operador;

proporcionar una petición de acceso suplementaria para el primer operador que tiene un tamaño de petición de acceso correspondiente a la diferencia entre un tamaño solicitado y un tamaño presente de la llamada en curso, si el tamaño solicitado es mayor que el tamaño presente; y

llevar a cabo un cambio de utilización de recursos para la llamada en curso, si el tamaño presente es mayor que el tamaño solicitado.

19. Disposición que es o que comprende un dispositivo para gestionar recursos en un sistema de comunicación (10), teniendo el sistema de comunicación (10) recursos compartidos por al menos dos operadores (12, 14), comprendiendo el dispositivo:

medios para recibir una petición de acceso para un primer operador de los al menos dos operadores (12, 14); y

medios para ejecutar una primera determinación si hay suficiente cantidad de recursos libres disponibles en el sistema de comunicación (10),

caracterizado por

medios para ejecutar una segunda determinación si una cantidad total de los citados recursos compartidos por al menos dos operadores en uso en el sistema de comunicación (10) excede un primer umbral;

medios para ejecutar una tercera determinación si una cantidad total de los citados recursos compartidos por al menos dos operadores en uso para el primer operador excede un segundo umbral; y

medios para decidir sobre aceptar la petición de acceso basándose en los resultados de las determinaciones primera, segunda y tercera.

20. Disposición de acuerdo con la reivindicación 19, caracterizada porque la disposición es una red de acceso por radio terrestre de un sistema de telecomunicación de telefonía móvil universal compartida y el dispositivo está comprendido en un controlador de red de radio.

21. Disposición de acuerdo con la reivindicación 19, caracterizada porque la disposición es el sistema de comunicación (10).