ES2333791T3 - Metodo y dispositivo para gestionar recursos compartidos por diferentes operadores en un sistema de comunicacion. - Google Patents
Metodo y dispositivo para gestionar recursos compartidos por diferentes operadores en un sistema de comunicacion. Download PDFInfo
- Publication number
- ES2333791T3 ES2333791T3 ES03768440T ES03768440T ES2333791T3 ES 2333791 T3 ES2333791 T3 ES 2333791T3 ES 03768440 T ES03768440 T ES 03768440T ES 03768440 T ES03768440 T ES 03768440T ES 2333791 T3 ES2333791 T3 ES 2333791T3
- Authority
- ES
- Spain
- Prior art keywords
- resources
- operator
- access request
- threshold
- communication system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 76
- 238000004891 communication Methods 0.000 title claims description 46
- 238000005259 measurement Methods 0.000 claims description 4
- 230000001419 dependent effect Effects 0.000 claims description 2
- 238000012360 testing method Methods 0.000 abstract description 2
- 238000007726 management method Methods 0.000 description 28
- 238000013459 approach Methods 0.000 description 17
- 230000007246 mechanism Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000013468 resource allocation Methods 0.000 description 3
- 238000001228 spectrum Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012913 prioritisation Methods 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000012356 Product development Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008094 contradictory effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/11—Identifying congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/245—Traffic characterised by specific attributes, e.g. priority or QoS using preemption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/29—Flow control; Congestion control using a combination of thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/745—Reaction in network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/821—Prioritising resource allocation or reservation requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
- H04W16/02—Resource partitioning among network components, e.g. reuse partitioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/26—Resource reservation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
- Computer And Data Communications (AREA)
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.
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.
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.
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.
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.
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;
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.
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:
si están disponibles suficientes
recursos, la siguiente determinación se refiere a la
desigualdad:
donde T_{c} es un primer umbral.
El umbral T_{c} es seleccionado en una realización preferida
como:
y es seleccionado en otra
realización preferida
como:
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:
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:
y es seleccionado en otra
realización preferida
como:
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:
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:
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:}
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:
donde T^{s}_{j} es
un umbral asociado con el umbral de congestión blando
\alpha_{j}, preferiblemente por la
relación:
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
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.
[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 (21)
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.
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).
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/SE2003/001922 WO2005057978A1 (en) | 2003-12-09 | 2003-12-09 | Method and device for managing resources shared by different operators in a communication system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2333791T3 true ES2333791T3 (es) | 2010-03-01 |
Family
ID=34676087
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03768440T Expired - Lifetime ES2333791T3 (es) | 2003-12-09 | 2003-12-09 | Metodo y dispositivo para gestionar recursos compartidos por diferentes operadores en un sistema de comunicacion. |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US8155072B2 (es) |
| EP (1) | EP1695581B1 (es) |
| CN (1) | CN100508641C (es) |
| AT (1) | ATE444662T1 (es) |
| AU (1) | AU2003291799A1 (es) |
| CA (1) | CA2544727C (es) |
| DE (1) | DE60329537D1 (es) |
| ES (1) | ES2333791T3 (es) |
| TW (1) | TWI374629B (es) |
| WO (1) | WO2005057978A1 (es) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7490325B2 (en) | 2004-03-13 | 2009-02-10 | Cluster Resources, Inc. | System and method for providing intelligent pre-staging of data in a compute environment |
| US8782654B2 (en) | 2004-03-13 | 2014-07-15 | Adaptive Computing Enterprises, Inc. | Co-allocating a reservation spanning different compute resources types |
| US7689490B2 (en) * | 2004-05-28 | 2010-03-30 | Morgan Stanley | Matching resources of a securities research department to accounts of the department |
| US7734517B2 (en) * | 2004-05-28 | 2010-06-08 | Morgan Stanley | Systems and method for determining the cost of a securities research department to service a client of the department |
| US7769654B1 (en) | 2004-05-28 | 2010-08-03 | Morgan Stanley | Systems and methods for determining fair value prices for equity research |
| US20070266388A1 (en) | 2004-06-18 | 2007-11-15 | Cluster Resources, Inc. | System and method for providing advanced reservations in a compute environment |
| US8176490B1 (en) | 2004-08-20 | 2012-05-08 | Adaptive Computing Enterprises, Inc. | System and method of interfacing a workload manager and scheduler with an identity manager |
| US7752103B2 (en) * | 2004-09-10 | 2010-07-06 | Morgan Stanley | Systems and methods for auctioning access to securities research resources |
| US8271980B2 (en) | 2004-11-08 | 2012-09-18 | Adaptive Computing Enterprises, Inc. | System and method of providing system jobs within a compute environment |
| JPWO2006059673A1 (ja) * | 2004-12-01 | 2008-06-05 | 松下電器産業株式会社 | 無線ネットワーク制御装置、無線ネットワーク制御方法および通信システム |
| US8863143B2 (en) | 2006-03-16 | 2014-10-14 | Adaptive Computing Enterprises, Inc. | System and method for managing a hybrid compute environment |
| EP1866767B1 (en) | 2005-03-16 | 2018-04-18 | III Holdings 12, LLC | Automatic workload transfer to an on-demand center |
| US9015324B2 (en) | 2005-03-16 | 2015-04-21 | Adaptive Computing Enterprises, Inc. | System and method of brokering cloud computing resources |
| US9231886B2 (en) | 2005-03-16 | 2016-01-05 | Adaptive Computing Enterprises, Inc. | Simple integration of an on-demand compute environment |
| US8782120B2 (en) | 2005-04-07 | 2014-07-15 | Adaptive Computing Enterprises, Inc. | Elastic management of compute resources between a web server and an on-demand compute environment |
| CA2603577A1 (en) | 2005-04-07 | 2006-10-12 | Cluster Resources, Inc. | On-demand access to compute resources |
| US8031603B1 (en) * | 2005-06-30 | 2011-10-04 | Cisco Technology, Inc. | Technique for reducing resources allocated to an existing reservation in a data network |
| US7953652B1 (en) | 2006-06-12 | 2011-05-31 | Morgan Stanley | Profit model for non-execution services |
| JP4913502B2 (ja) * | 2006-08-16 | 2012-04-11 | 株式会社エヌ・ティ・ティ・ドコモ | 通信制御方法、無線基地局及び無線制御局 |
| US8380880B2 (en) * | 2007-02-02 | 2013-02-19 | The Mathworks, Inc. | Scalable architecture |
| US8229346B2 (en) * | 2007-05-15 | 2012-07-24 | Nvidia Corporation | Method and apparatus for providing multimedia broadcasting multicasting services |
| CN102647660B (zh) * | 2007-09-19 | 2016-03-02 | 华为技术有限公司 | 在共享无线接入网络中实现业务功能的方法、系统和rnc |
| US8041773B2 (en) | 2007-09-24 | 2011-10-18 | The Research Foundation Of State University Of New York | Automatic clustering for self-organizing grids |
| CN101184042B (zh) * | 2007-12-12 | 2011-04-13 | 华为技术有限公司 | 一种资源管理方法及装置 |
| CN101459597A (zh) * | 2007-12-14 | 2009-06-17 | 华为技术有限公司 | 一种使用逻辑资源的方法和系统 |
| CN101267651B (zh) * | 2008-04-01 | 2012-01-04 | 华为技术有限公司 | 一种多运营商共享载频资源的方法及装置 |
| US8547910B2 (en) | 2008-06-26 | 2013-10-01 | Qualcomm Incorporated | Fair resource sharing in wireless communications |
| FR2934447A1 (fr) * | 2008-07-23 | 2010-01-29 | France Telecom | Procede de communication entre une pluralite de noeuds, les noeuds etant organises suivant un anneau |
| CN101815319B (zh) * | 2009-02-20 | 2013-01-23 | 中国移动通信集团公司 | 一种家庭基站的接入控制方法及装置 |
| BRPI0925347A2 (pt) | 2009-03-25 | 2016-08-23 | Nokia Siemens Networks Oy | sistema de gestão de rede |
| CN101883380B (zh) * | 2009-05-04 | 2012-11-28 | 中兴通讯股份有限公司 | 一种拥塞处理时选择终端的方法及装置 |
| CN101908999A (zh) * | 2009-06-02 | 2010-12-08 | 华为技术有限公司 | 一种网络中资源委托调整的方法、装置及系统 |
| US8516101B2 (en) * | 2009-06-15 | 2013-08-20 | Qualcomm Incorporated | Resource management for a wireless device |
| GB2471486A (en) * | 2009-06-30 | 2011-01-05 | Nokia Corp | Apparatus and method for resolving resource contention using access priority. |
| CN101674602B (zh) * | 2009-09-16 | 2012-07-18 | 中兴通讯股份有限公司 | 一种共享网络的资源分配方法和装置 |
| US10877695B2 (en) | 2009-10-30 | 2020-12-29 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| US11720290B2 (en) | 2009-10-30 | 2023-08-08 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| WO2011075919A1 (zh) * | 2009-12-25 | 2011-06-30 | 中兴通讯股份有限公司 | 共享abis资源的方法及装置 |
| CN101764711B (zh) | 2010-01-18 | 2012-04-25 | 上海华为技术有限公司 | 共享网元上资源的操控方法、一种共享网元及相关设备 |
| US8285574B2 (en) * | 2010-03-11 | 2012-10-09 | International Business Machines Corporation | Constrained resource management |
| US9294895B2 (en) * | 2010-10-22 | 2016-03-22 | International Business Machines Corporation | Caching at the wireless tower with remote charging services |
| EP2652907B1 (en) * | 2010-12-16 | 2014-11-19 | Nokia Solutions and Networks Oy | Key performance indicator for operator performance evaluation in communication network resource sharing |
| US8787159B2 (en) * | 2011-04-14 | 2014-07-22 | Alcatel Lucent | Mechanism for wireless access networks to throttle traffic during congestion |
| US9781656B2 (en) * | 2011-08-26 | 2017-10-03 | Alcatel Lucent | Method and apparatus for modifying call admission control thresholds |
| US10159012B2 (en) * | 2011-11-14 | 2018-12-18 | Alcatel Lucent | Baseband signal processing cluster |
| CN102378186B (zh) * | 2011-11-21 | 2018-08-07 | 南京中兴软件有限责任公司 | 一种基站资源共享系统及方法 |
| WO2013097169A1 (zh) * | 2011-12-30 | 2013-07-04 | 华为技术有限公司 | 移动负载均衡方法及接入网设备 |
| EP2839714B1 (en) * | 2012-04-16 | 2016-06-08 | Telefonaktiebolaget LM Ericsson (publ) | Method and radio network node for managing radio resources |
| KR101515594B1 (ko) * | 2012-05-21 | 2015-04-28 | 주식회사 케이티 | 디지털 신호 처리 장치, 무선 신호 처리 장치 및 신호 처리 시스템 |
| CN102724760A (zh) * | 2012-06-18 | 2012-10-10 | 中兴通讯股份有限公司 | 共享资源处理方法及装置 |
| CN104025645B (zh) * | 2012-08-08 | 2018-05-29 | 华为技术有限公司 | 一种管理共享网络的方法及装置 |
| US9116744B2 (en) | 2012-09-07 | 2015-08-25 | International Business Machines Corporation | Resource management within a process via iterative negotiation |
| CN105764118B (zh) * | 2012-12-24 | 2019-12-13 | 华为技术有限公司 | Mocn小区通信方法及装置 |
| CN106937334B (zh) * | 2012-12-26 | 2020-07-21 | 华为技术有限公司 | 共享无线接入网的方法、发送端和接收端 |
| GB2510345A (en) | 2013-01-30 | 2014-08-06 | Nec Corp | Sharing base station resources among plural network operators |
| GB2512900A (en) * | 2013-04-10 | 2014-10-15 | Nec Corp | Communication system |
| US9413666B2 (en) * | 2013-10-02 | 2016-08-09 | Cisco Technology, Inc. | Reporting radio access network congestion information in a network sharing environment |
| EP3024263B1 (en) * | 2013-10-08 | 2017-09-20 | Huawei Technologies Co., Ltd. | Resource configuration method, network device, and base station |
| US9717031B2 (en) * | 2014-01-31 | 2017-07-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Management of resources amongst parties sharing the same radio access network |
| CN104980935A (zh) * | 2014-04-03 | 2015-10-14 | 中兴通讯股份有限公司 | 一种共享网络的方法、装置和系统 |
| CN105589750B (zh) * | 2015-07-07 | 2019-01-25 | 新华三技术有限公司 | 一种cpu资源调度方法和服务器 |
| US10637919B2 (en) * | 2017-03-23 | 2020-04-28 | Microsoft Technology Licensing, Llc | Autonomous resource governor in distributed systems for protecting shared resources |
| CN109429335B (zh) * | 2017-08-21 | 2022-08-23 | 成都鼎桥通信技术有限公司 | 集群语音用户跨运营商抢占方法及设备 |
| CN112312402A (zh) * | 2019-07-31 | 2021-02-02 | 中国移动通信有限公司研究院 | 资源配置方法、装置及设备 |
| CN113939029A (zh) * | 2021-09-22 | 2022-01-14 | 中国联合网络通信集团有限公司 | 一种网络切片的生成方法、装置、设备及存储介质 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0795202A (ja) * | 1993-09-20 | 1995-04-07 | Fujitsu Ltd | システム間での定義情報の共用方式 |
| US5805633A (en) * | 1995-09-06 | 1998-09-08 | Telefonaktiebolaget L M Ericsson | Method and apparatus for frequency planning in a multi-system cellular communication network |
| US6356546B1 (en) * | 1998-08-11 | 2002-03-12 | Nortel Networks Limited | Universal transfer method and network with distributed switch |
| EP1037484B1 (en) | 1999-03-15 | 2009-01-14 | Motorola, Inc. | Time sharing of communications resources in cellular communications systems |
| FR2809904B1 (fr) * | 2000-05-30 | 2005-04-29 | Cit Alcatel | Procede de synchronisation du fonctionnement d'au moins deux interfaces |
| EP1220557A1 (en) | 2000-12-29 | 2002-07-03 | Motorola, Inc. | Communication system and method of sharing a communication resource |
| US6631269B1 (en) * | 2002-05-23 | 2003-10-07 | Interdigital Technology Corporation | Signaling connection admission control in a wireless network |
| AU2002314429A1 (en) * | 2002-06-28 | 2004-01-19 | Nokia Corporation | A method and a system of sharing resources |
| US7489903B2 (en) * | 2003-04-29 | 2009-02-10 | Nokia Corporation | Method and system for exchanging the capacity reports in a radio access network |
| US6922564B2 (en) * | 2003-05-30 | 2005-07-26 | Motorola Inc. | Admitting data flows to a multiple access network |
| US7305251B2 (en) * | 2003-10-07 | 2007-12-04 | Motorola Inc. | Method for selecting a core network |
-
2003
- 2003-12-09 AU AU2003291799A patent/AU2003291799A1/en not_active Abandoned
- 2003-12-09 WO PCT/SE2003/001922 patent/WO2005057978A1/en active Application Filing
- 2003-12-09 CA CA2544727A patent/CA2544727C/en not_active Expired - Lifetime
- 2003-12-09 US US10/581,999 patent/US8155072B2/en not_active Expired - Fee Related
- 2003-12-09 CN CNB2003801107966A patent/CN100508641C/zh not_active Expired - Fee Related
- 2003-12-09 ES ES03768440T patent/ES2333791T3/es not_active Expired - Lifetime
- 2003-12-09 AT AT03768440T patent/ATE444662T1/de not_active IP Right Cessation
- 2003-12-09 EP EP03768440A patent/EP1695581B1/en not_active Expired - Lifetime
- 2003-12-09 DE DE60329537T patent/DE60329537D1/de not_active Expired - Lifetime
-
2004
- 2004-11-11 TW TW093134544A patent/TWI374629B/zh not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| WO2005057978A1 (en) | 2005-06-23 |
| DE60329537D1 (de) | 2009-11-12 |
| EP1695581A1 (en) | 2006-08-30 |
| ATE444662T1 (de) | 2009-10-15 |
| TWI374629B (en) | 2012-10-11 |
| TW200534635A (en) | 2005-10-16 |
| CN1879441A (zh) | 2006-12-13 |
| US20070264986A1 (en) | 2007-11-15 |
| CN100508641C (zh) | 2009-07-01 |
| EP1695581B1 (en) | 2009-09-30 |
| CA2544727C (en) | 2012-08-07 |
| AU2003291799A1 (en) | 2005-06-29 |
| CA2544727A1 (en) | 2005-06-23 |
| US8155072B2 (en) | 2012-04-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2333791T3 (es) | Metodo y dispositivo para gestionar recursos compartidos por diferentes operadores en un sistema de comunicacion. | |
| ES2908270T3 (es) | Método y dispositivo para movimiento entre sistemas de comunicación | |
| US9936458B2 (en) | Battery power management for a mobile device | |
| JP2022538720A (ja) | サービス通信プロキシにおけるプロデューサネットワーク機能サービスインスタンス・ワイドエグレスレート制限のための方法、システムおよびコンピュータ可読媒体 | |
| US8542584B2 (en) | Partitioning entity and method for partitioning capacity | |
| ES2435472T3 (es) | Método y aparato para gestionar una prioridad de retención y de asignación evolucionada | |
| US8614951B2 (en) | Guaranteed bandwidth sharing in a traffic shaping system | |
| ES2353140T3 (es) | Procedimiento de gestión de recursos de radio en una red de acceso de radio de tipo utran. | |
| ES2556598T3 (es) | Red de comunicaciones para móviles | |
| US20110305137A1 (en) | Admission control for shared lte network | |
| ES2347747B1 (es) | Procedimiento y sistema para acceder a capacidad de transporte en redes de acceso de radio compartidas. | |
| ES2347748A1 (es) | Procedimiento y sistema para asignar capacidad en redes de acceso de radio compartidas. | |
| US20180234885A1 (en) | Resource control in a shared ran | |
| ES2292741T3 (es) | Metodo par adaptar el ancho de banda de un conexion en una red de telecomunicaciones. | |
| US20020114279A1 (en) | Telecommunications systems | |
| ES2240265T3 (es) | Esquema de umbral adaptable, para un acceso diferenciado a los recursos del sistema. | |
| US11792692B2 (en) | Personalized data throttling in a residential wireless network | |
| Aboelaze | A call admission protocol for cellular networks that supports differentiated fairness | |
| WO2016131327A1 (zh) | 一种多系统聚合的方法及相应的功能组件 | |
| WO2024066623A1 (zh) | 调度策略的确定方法及相关装置 | |
| Aboelaze et al. | Performance Evaluation of a Call Admission Control Protocol for Cellular Networks. | |
| EP2930993A1 (en) | Determining priority for signalling | |
| ES2441264A2 (es) | Procedimiento para la optimización del reconocimiento de movilidad en redes móviles |