ES2367122T3

ES2367122T3 - Control de servicios en tiempo real.

Info

Publication number: ES2367122T3
Application number: ES07736098T
Authority: ES
Inventors: Mark Greening; Nicholas Jones; Simon Smith; David Spann; Ralph Woodman
Original assignee: Markport Ltd
Current assignee: Markport Ltd
Priority date: 2006-04-07
Filing date: 2007-03-30
Publication date: 2011-10-28
Anticipated expiration: 2027-03-30
Also published as: ATE515130T1; WO2007116385A1; AU2007237047A1; EP2005670B1; EP2005670A1; US20090276386A1

Abstract

Un sistema de supervisión y control del suministro de servicios en tiempo real que comprende: un administrador de datos (104) que comprende medios para el mantenimiento de datos de los recursos de cuantas asociadas con cada una de una pluralidad de cuentas de recursos con uno o más servicios, en los que al menos una cuenta se asocia con una pluralidad de servicios y un administrador de sesión (102) que comprende: funciones para la interfaz con una pluralidad de entidades de suministro de servicio; funciones para el procesamiento de solicitudes desde dichas entidades para el establecimiento de recursos de mantenimiento de sesiones de suministro de servicio; funciones para la supervisión de sesiones concurrentes en tiempo real; una base de reglas (103) para, en tiempo real, reasignar los recursos de dichas cuentas (104) a las sesiones concurrentes de acuerdo con el uso del servicio y funciones para notificar a las entidades de suministro de servicios la reasignación de los recursos, en el que el administrador de sesión (110) comprende medios para la generación de un mensaje para una entidad de servicio para o bien solicitar recursos adicionales para la cuenta si estima que los recursos se agotarán durante una sesión actual o bien para informar a la entidad de una nueva cuota de recursos; en el que el administrador de sesión (102) comprende medios para la interfaz con una entidad de suministro de servicios para la negociación de la asignación de recursos; en el que el administrador de datos (104) comprende medios para el mantenimiento de al menos un fondo para cada cuenta y en el que cada fondo se asocia con una unidad de recursos; en el que las unidades incluyen el tiempo, volumen de bytes, número de mensajes y número de descargas de programas o contenido; en el que el administrador de sesión (102) comprende medios para la determinación de las prioridades para la asignación de recursos y para el uso de las prioridades para determinar el orden en el que se han de agotar los fondos de acuerdo con la prioridad; en el que el administrador de datos (104) comprende medios para la asociación de una prioridad con cada fondo; en el que el administrador de sesión (102) comprende medios para la denegación de una solicitud de servicio si determina que hay insuficientes recursos para satisfacer a todas las sesiones y en el que el administrador de datos (104) comprende medios para la modificación de modo dinámico de las cuentas durante las sesiones que extraen recursos de dichas cuentas.

Description

Introducción

Campo de la invención

La invención se refiere al control en tiempo real de diferentes casos (o “sesiones”), particularmente sesiones de comunicación aunque también otros tales como por ejemplo el uso de energía. En esta especificación el término “sesión” significa no solamente la provisión de un servicio durante un periodo de tiempo tal como una llamada de voz o una descarga de datos o vídeo, sino también casos de servicios instantáneos tales como el envío de un SMS o cualquier otro caso de servicio que involucre un requerimiento para el cargo por recursos desde una cuenta.

Explicación de técnicas anteriores

Los sistemas de redes inteligentes (IN) de prepago actuales para el control del prepago/pago posterior de crédito limitado, tales como el JAIN o una aplicación Parlay, controlan el comportamiento del servicio de comunicación con relación al abonado final (prepago), por ejemplo:

 para reproducir un mensaje de bienvenida la primera vez que el abonado realiza una llamada en la red,  para reproducir un mensaje del saldo del abonado previamente a la llamada o  para enviar un SMS al final de la llamada para anunciar el coste de la llamada.

También realizan un proceso de valoración y de cargo simple que calcula cuánto del tiempo de enlace por aire disponible para abonados está reservado y cuánto dinero han gastado en cada llamada y mantienen una cuenta para el abonado. Este proceso se realiza antes, durante y después de que se realice (por ejemplo) una llamada de voz. Tal proceso se describe también en el documento US-A1-2005/021713.

Lo siguiente resume algunos de los escenarios que surgen en los sistemas de comunicación actuales.

Modelo de Cargo/Reembolso. En algunos servicios del sistema adquiridos por el usuario (SMS, MMS, etc.) se cargan contra una cuenta de prepago. Si no se proporciona el servicio a continuación tiene lugar un reembolso en la cuenta para devolver al usuario los fondos por el servicio que falló. Por ejemplo, con los servicios SMS un fallo en la entrega del SMS en un periodo de 7 días puede dar como resultado que se reembolse la entrega fallada.

Modelo de Reserva/Captura. En este modelo un ordenador cliente solicita una reserva de una cantidad de crédito o tiempo u otra unidad de cargo. Una vez se ha proporcionado el servicio el ordenador cliente captura a continuación la cantidad que se ha usado, que puede incluir un recálculo de la tasa en base al uso medido. Si ocurriese un fallo en el servicio entonces se libera la reserva.

Servicios escalares, también conocidos como servicios de transmisión continua. Estos servicios son sesiones en tiempo real de actividad en la que normalmente el final de la sesión no es conocido. Por ejemplo una llamada de voz telefónica es un servicio escalar y no es conocido en que instante del tiempo durante la llamada colgará el usuario y por ello la duración final de la llamada. Por lo tanto se han de realizar tentativas durante la llamada para asegurarse que la llamada no pueda continuar más tiempo del que el usuario tiene fondos para el pago de la llamada.

Servicios de eventos. Estos servicios son eventos de una vez simples como un SMS o MMS en el que es conocida toda la información necesaria para evaluar y cargar a un usuario por el servicio y se puede garantizar a partir de un evento simple.

Se usan estos términos a todo lo largo de este documento.

La mayor parte de los sistemas actuales solamente permiten reservas estáticas de crédito en la que se usa una cantidad fija para cada solicitud de reserva. Para servicios escalares tales como llamadas de voz, esto produce una sobrecarga en el rendimiento de la red significativo. Esto se debe a clientes que requieren múltiples solicitudes de reservas más pequeñas para dar un mejor uso del crédito para múltiples servicios. Estas solicitudes múltiples a menudo dan como resultado mayores requerimientos de la CPU del servidor de la red. Puede dar como resultado también tiempos de respuesta más largos si no está dimensionado el hardware para adaptarse a la demanda.

Otro problema en la actualidad es la denegación del servicio debido a un crédito insuficiente incluso aunque haya crédito disponible. Algunos sistemas de cargo asignan todo el crédito disponible a un único servicio tal como una llamada de voz, impidiendo el suministro de servicios en competencia/concurrentes.

El documento US6.741.686 describe un enfoque que permite balances negativos (una “rebaja”) para permitir que tengan lugar servicios concurrentes, conduciendo a una contabilidad imprecisa. La denegación del servicio se realiza entonces después de que ya se haya permitido que se realice el servicio pasando el límite de crédito mediante el bloqueo del servicio en la red.

El documento US2004/0017905 describe un sistema para permitir la supervisión concurrente de sesiones de

5 comunicación. Sin embargo la supervisión es compleja debido al requerimiento al dispositivo del usuario para que realice solicitudes y comunique con sistemas de facturación. Por ejemplo, el sistema necesita solicitar de un primer dispositivo de acceso a la red cuánto crédito espera usar y el sistema usa esta información para calcular el crédito disponible para un segundo dispositivo de acceso a la red. Si no hay crédito suficiente se rechaza el acceso del segundo dispositivo. El sistema necesita también intercambiar actualizaciones entre los dispositivos.

10 El documento US6.115.613 describe un sistema y método para el manejo de una llamada por un miembro de un grupo, siendo apartada la llamada y conectada o desconectada posteriormente.

En general, los sistemas actuales son inadecuados para la gestión de sesiones concurrentes, tales como el uso de

15 teléfonos que permiten la descarga en segundo plano mientras están activas llamadas de voz, particularmente en el contexto de cuentas de grupos en las que múltiples usuarios pueden acceder todos a un única cuenta de prepago.

Glosario Resumen de la invención

CDR: Registro de Detalles de Llamadas

CORBA: Arquitectura del Agente de Solicitud de Objetos Comunes

CPU: Unidad Central de Procesamiento

EDR: Registro de Detalles de Eventos

FIFO: Primero en Entrar, Primero en Salir

GGSN: Nodo de Soporte GPRS de Pasarela

GSN: Nodos de Soporte GPRS

HTTP: Protocolo de Transferencia de Hipertexto

IC: Cargador Inteligente

IMS: Subsistema Multimedia por IP

IN: Red Inteligente

IP: Protocolo de Internet

JAIN: API Java para Redes Inteligentes

MMS: Servicio de Mensajería Multimedia

MP3: Audio MPEG-1 Capa 3

MSC: Centro de Conmutación de Servicios Móviles

OA&M: Operaciones, Administración y Mantenimiento

Contexto PDP: Estructura de datos GPRS que contiene información en relación a una sesión activa (GPRS) de un abonado.

PSA: El Agente de Servicio Previo a la Entrega LogicaCMG

PSTN: Red Telefónica Conmutada Pública

SCP: Punto de Control del Servicio

SDP: Punto de Datos del Servicio

SGSN: Nodo de Soporte GPRS en Servicio

SMS: Servicio de Mensajes Cortos

SNMP: Protocolo Simple de Administración de Red

SOAP: Protocolo Simple de Acceso a Objetos

SSP: Punto de Conmutación de Servicio

TCP/IP: Protocolo de Control de Transmisión/ Protocolo de Internet

TV: Televisión

imagen1

De acuerdo con la invención, se proporciona un sistema de supervisión y control del suministro de servicios en tiempo real como se establece en la reivindicación 1.

En una realización, las entidades de suministro de servicio son entidades de la red de comunicación y el servicio se usa en sesiones de comunicación.

En una realización, el administrador de datos mantiene cuentas para recursos escalares y basados en eventos.

En una realización adicional, el administrador de la sesión mantiene una estimación de la ejecución de los recursos totales para sesiones concurrentes y asigna recursos a cada sesión para minimizar el número de solicitudes para recursos nuevos.

En una realización, el administrador de sesión genera una estimación de solicitudes de recursos tras el comienzo de una nueva sesión.

En una realización, el administrador de sesión comprende medios para el uso de datos históricos para el cálculo de una asignación de recursos inicial para una sesión.

En una realización, los datos históricos son por abonado y el administrador de sesión calcula la asignación de recursos iniciales tras la detección de la identidad del abonado.

En una realización, los datos históricos son por servicio y el administrador de sesión calcula la asignación de recursos iniciales de acuerdo con el servicio.

En una realización, se asocia al menos un fondo por el administrador de la sesión con una pluralidad de tipos de servicios.

En una realización, el administrador de sesión asocia una cuenta de recursos con un grupo de abonados.

En una realización, el administrador de sesión reasigna todas las sesiones concurrentes de acuerdo con una política que determina un tiempo de finalización objetivo para las sesiones.

En una realización adicional, el administrador de sesión reasigna todas las sesiones concurrentes de acuerdo con una política que determina los objetivos de volúmenes de datos para las sesiones.

En una realización, la reasignación se realiza en base a que todas las sesiones concurrentes finalizan aproximadamente al mismo tiempo.

En una realización, el administrador de sesión comprende medios para la interfaz con las entidades de suministro de servicios de acuerdo con un esquema de reserva-captura.

En una realización, el administrador de sesión comprende medios para el marcado de los recursos que están disponibles para modificación para su reasignación.

En una realización adicional, el administrador de sesión no marca algunas descargas de software como que están disponibles para modificación ya que son de naturaleza atomizada.

En una realización, el administrador de sesión comprende medios para la interfaz con las entidades de servicio en paralelo.

En una realización, el administrador de sesión comprende un objeto controlador de sesión enlazado con un objeto de política de reasignación de recursos que tiene al menos un algoritmo, método de reasignación, y el objeto controlador de sesión tiene métodos para llamar al objeto de política de reasignación para la toma de decisiones en la reasignación de recursos.

En una realización, el objeto controlador de sesión contiene una pluralidad de objetos de sesión, en el que cada uno contiene al menos un objeto de ficha de reserva y el objeto controlador de sesión realiza dinámicamente la reasignación de recursos mediante la instrucción a un objeto de sesión para modificar un objeto de ficha de reserva contenido.

En una realización el objeto de sesión modifica el objeto de ficha de reserva mediante la modificación de un atributo del objeto de ficha de reserva.

En una realización, el administrador de sesión comprende una interfaz para la modificación de los atributos de los objetos del controlador de sesión y política para implementar ajustes de configuración.

En otro aspecto, la invención proporciona un medio que pueda leer un ordenador que comprende código de software para la realización de operaciones como se establecen en la reivindicación 17.

Descripción detallada de la invención

Breve descripción de los dibujos

La invención se comprenderá más claramente a partir de la siguiente descripción de algunas realizaciones de la misma, dadas solamente a modo de ejemplo con referencia los dibujos adjuntos en los que:

la Figura 1 es un diagrama de bloque y de flujo combinados que muestra la arquitectura y el funcionamiento de un sistema de supervisión y control de servicios en tiempo real (de aquí en adelante “sistema de control”) de la invención;

la Figura 2 es un diagrama que muestra la interfaz del sistema de control con las entidades de suministro de servicio;

la Figura 3 es un diagrama que ilustra la arquitectura de un administrador de sesión del sistema de control;

la Figura 4 es un diagrama de flujo que ilustra las etapas que se plantean cuando se procesa una solicitud para un cargo;

la Figura 5 es un diagrama que muestra cómo interactúa el sistema de control con un cliente y

la Figura 6 muestra cómo realiza el sistema de control un cargo de un servicio concurrente con una solicitud de nueva reserva.

Descripción de las realizaciones

Con referencia a la Figura 1, un sistema de control 101 de la invención funciona en una red de móviles. A veces se hace referencia a él en la especificación como un “Cargador Inteligente”. El sistema 101 comprende un administrador de sesión 102 que interactúa con entidades de servicio múltiple 110, que incluyen en esta realización:

un SCP de datos 111, a su vez enlazado con una sonda IP 112 y un xGSN 113,

un SCP de mensajes 115, enlazado su vez con un MMSC 116 y un SMSC 117 y

un SCP de voz 118, enlazado con un MSC 119.

Como se muestra en la Figura 2, la interfaz con los SCP es a través del protocolo Diameter Ro. Los SCP a su vez tienen una interfaz con entidades de red tales como el MSC 119 a través de INAP (o CAMEL en otra realización, por ejemplo), que a su vez tienen una interfaz con una PSTN 134 a través del SS7. El administrador de sesión 102 usa sus protocolos para comunicar con las entidades de servicio 111-119 de acuerdo con el modelo de reserva/captura. Se puede usar alternativamente el protocolo Parlay Charging. Las entidades de servicio 111-119 funcionan como clientes del administrador de sesión 102. Cada cliente realiza una reserva de recursos usando el administrador de sesión (102) y el administrador de sesión ajusta las reservas y notifica a los clientes en consecuencia.

El sistema de control 101 comunica también con una variedad de elementos de red que incluyen en esta realización un servidor de aplicaciones (“APP”) 130 y un una pasarela de aplicaciones (“Pasarela APP”) 131. El sistema de control 101 realiza una “cargo inteligente” con mantenimiento de múltiples fondos y comunicación bidireccional con varios elementos de red como se describe con más detalle a continuación.

En general, la interfaz entre el administrador de sesión 102 y las diversas entidades de servicio se realiza en base a que las entidades de servicio son clientes del administrador de sesión.

El administrador de sesión 102 comprende funciones de administración de sesión que comunican con una regla base de evaluación y cargo 103 para que un administrador de datos persistente 104 gestione múltiples cuentas y fondos de recursos. Las interfaces 105 comunican con sistemas externos para actividades tales como operaciones, administración y mantenimiento.

El administrador de sesión 102 supervisa las sesiones en tiempo real, con decisiones tomadas dentro de una duración del tiempo de menos de 0,5 seg. y típicamente menos de 50 ms. Supervisa las sesiones y tiene interfaz con las reglas 103, que deciden cómo reasignar los recursos mantenidos en las cuentas del administrador de datos 104.

El administrador de datos 104 gestiona múltiples cuentas, algunas de las cuales se usan para proporcionar recursos para diferentes tipos de sesión. Algunas cuentas tienen múltiples fondos, cada uno de los cuales se asocia con un tipo de recursos. Esto se describe con más detalle a continuación.

Con referencia a la Figura 3, el administrador de sesión 102 es un componente de software que comprende objetos que controlan las sesiones de cargo en nombre de los clientes de cargo conectados, tal como un SCP de voz heredado. La estructura del objeto comprende una clase del controlador de sesión 135 enlazada con una clase de política de redistribución 136. Las clases hijas de la clase del controlador de sesión 135 incluyen una clase de sesión de cargo 139, que su vez contiene una clase de ficha de reserva 140. Una clase de administrador de cuenta 137 es una clase padre de una clase de datos de cuentas de abonado 138. Los objetos instanciados a partir de las clases 139 y 137 activan las reglas 103, durante el funcionamiento.

El administrador de sesión 102 asegura que los recursos de cuentas se comparten uniformemente a través de todas las sesiones activas a las que son aplicables los recursos disponibles. Las sesiones se administran en base a un tipo por abonado, por grupo (de abonados) o por servicio. Adicionalmente, los recursos se puedan aplicar a tipos de servicio especificados, por ejemplo, los minutos de voz no se pueden gastar en un SMS.

Tras la recepción de una solicitud de recursos, el objeto controlador de sesión 135 usa el objeto administrador de cuenta 137 para adquirir los datos de la cuenta de abonado que contienen los recursos de crédito no reservados. Si el crédito no es suficiente para la solicitud de cargo, el objeto controlador de sesión 135 recupera un conjunto de las sesiones de cargo actuales para el abonado especificado de la base de datos local.

Iterando a través del conjunto de sesiones de cargo para el abonado especificado, el objeto controlador de sesión 135 intenta redistribuir los objetos de ficha de reserva disponibles 140 de acuerdo con una política predefinida (mantenida en el objeto de políticas de redistribución 136) entre las sesiones de cargo restantes. Esto involucra la evaluación del servicio para intentar asignar recursos de crédito (como se ha definido por la política) a la sesión. Si el controlador de sesión redistribuye unos objetos de ficha de reserva 140 de la sesión de cargo existente, se debe notificar a los clientes a los que se va a cargar. El mecanismo para la redistribución de recursos involucra la modificación de atributos de los objetos de ficha de reserva 140.

Algunas sesiones de cargo no se pueden alterar una vez que han comenzado ya que se refieren a un coste fijo, por ejemplo, el pago por una descarga de un video o de un juego Java.

La Figura 4 ilustra un método 150 de etapas 151-160 realizadas para procesar una solicitud de cargo. Tras una nueva solicitud de cargo (151), el administrador de sesión 102 y las reglas 103 determinan (152) todos los fondos válidos para el tipo de servicio y determinan (153) si hay sesiones existentes para el usuario especificado. Si no hay ninguna sesión existente, evalúan y realizan la reserva en consecuencia (154) (o bien calculan la cuota de asignación óptima en base al uso histórico o simplemente usan valores por omisión para el tipo de servicio). Si hay sesiones existentes, determinan (158) qué recursos son aplicables al tipo de servicio y qué recursos tienen crédito suficiente para dar servicio a la solicitud. Si hay un crédito restante insuficiente el administrador 102 reasigna (155) los recursos de la cuenta restantes a las sesiones existentes y envía notificaciones a las entidades de servicio (lo que puede dar como resultado que se envíen notificaciones a los dispositivos de usuario de acuerdo con la política/capacidad de la entidad de servicio y la política/capacidad de la infraestructura global de la red). Algunas sesiones serán fijas bien porque el cliente de cargo no puede alterar las reservas o porque las reservas son fijas (como en el caso de una descarga de un juego). El administrador 102 reevalúa las reservas existentes en base a los atributos tales como el tipo de servicio, coste del servicio, ritmo de consumo actual y asegura que todas las sesiones finalizan en el mismo instante de tiempo (para sesiones basadas en el tiempo). En otras realizaciones el administrador 102 no planifica todas las sesiones para que finalicen en el mismo instante de tiempo, sino que en su lugar proporciona una asignación diferente de acuerdo con el algoritmo del objeto de política 136.

En el caso en que el administrador 102 ha alterado la reserva y hay un crédito suficiente (156) notifica (157) al cliente (entidad de servicio), que a su vez lo notifica al dispositivo de usuario de acuerdo con su política.

El sistema de control 101 realiza un cargo de servicios concurrente, aplicando un conjunto de reglas de cargo en el momento de, y durante, cada uso del servicio para determinar de dónde vienen los recursos para ese servicio y cómo se consumen esos recursos a través de los múltiples servicios, algunos de los cuales se pueden ejecutar concurrentemente. Hay por lo tanto una supervisión concurrente en tiempo real en donde al menos una cuenta es para servicios múltiples. Hay una reasignación dinámica de recursos de la cuenta a través de servicios múltiples que se usan concurrentemente. Al menos algunas cuentas tienen un cierto número de “fondos”, siendo cada fondo para un tipo particular de unidad de recursos. Los ejemplos primarios de unidades de recursos son tiempo y bytes o paquetes.

El sistema de control 101 implementa las reglas de cargo 103 en relación a dos tipos principales de actividad. En primer lugar, qué fondos están disponibles para cada servicio cuando se dedica a un abonado. En segundo lugar, cómo se distribuyen, retiran, recalculan y controlan los recursos disponibles totales para todos los servicios (lo que puede involucrar la suma de las cantidades en múltiples fondos) entre los múltiples servicios, algunos de los cuales se ejecutan simultáneamente. No todos los fondos están disponibles para todos los servicios. Un recurso es lo que se paga por el servicio y puede ser un valor en moneda o cualquier otra ficha que se pueda usar para la compra de un servicio, por ejemplo una cantidad de tiempo, un número de “vidas” en un juego o el número de megabytes de contenido.

Los recursos incluyen típicamente una cantidad de prepago tradicional a la que se accede antes de que se conecte un servicio, o una cantidad de pago posterior que representa un establecimiento de una disposición de crédito entre el abonado y el operador (como es normal en sistemas de pago posterior) o una cantidad de prepago especial disponible solamente para algunos servicios o una cantidad de promoción que consiste en mensajes SMS libres o tiempo de conversación o un instrumento de pago externo como un enlace a un sistema de tarjeta de crédito de nuevo establecido solamente para algunos servicios. Las cuentas se pueden conectar juntas en una estructura de grupos para permitir a múltiples abonados extraer recursos monetarios de múltiples fondos en una cuenta de grupo.

Los sistemas de atención al cliente interactúan con el sistema de control 101 por medio de las interfaces 105 para controlar y ver los registros del cliente. Los sistemas de aprovisionamiento permiten la creación/borrado y modificación de los detalles del abonado. Los sistemas de O., A. y M. interactúan con el sistema de control por medio del SNMP.

El sistema 101 produce CDR (Registros de Detalles de Llamada) que detallan qué servicios se han usado (por ejemplo llamadas de voz, SMS, MMS, una sesión GPRS). Puede haber también EDR (Registros de Detalle de Eventos) que detallan eventos importantes que podrían suceder en una cuenta de abonado (tal como una expiración de la cuenta o un evento se recarga).

Esta invención permite al operador ofrecer a sus abonados una multitud de instrumentos de pago para el pago por los servicios, no solamente el prepago, sino una mezcla de prepago y pago posterior y otros tipos, por ejemplo el pago contra una tarjeta de crédito o una tarjeta de fidelidad. El sistema 101 mantiene un saldo preciso, en tiempo real, de las cantidades prepagadas, evita los problemas de fraude de “facturación en caliente” y elimina el problema de denegación de un servicio no válido cuando un servicio reserva más de un crédito que realmente usa a expensas de un segundo servicio concurrente cuyo servicio se deniega como resultado de la primera sobreasignación al primer servicio.

El sistema de control 101 ejecuta las reglas de cargo de servicio concurrente 103 a través de todos los servicios dentro de una red y todos los clientes interactúan con el sistema para solicitar la asignación de recursos y para estar informados de cualquier cambio. Los recursos (o “cuotas”) puestos a disposición de la sesión particular se recalculan en cada momento en que se realiza una asignación de cuotas y ese cálculo se basa en dos cosas: el uso global del servicio en ese momento y las diversas reglas de cargo que están en vigor. Un ejemplo de esto se da en la Figura 1, que ilustra el papel del sistema 101 cuando procesa una llamada de voz, un mensaje SMS y una sesión GPRS simultáneamente. El sistema 101 determina dinámicamente las asignaciones de recursos de acuerdo con todos los servicios concurrentes que tienen lugar en ese momento y las reglas de cargo. Esto puede requerir que las entidades de servicio existentes sean informadas de que ha cambiado su asignación de cuotas de recursos.

La expresión “uso global del servicio” significa que una función de calculador de cuota del administrador de sesión 102 analiza los requisitos existentes de todos los servicios tales como voz, SMS, eventos de cargo para servicios de aplicación y solicitudes de cargo GPRS cuando realiza sus cálculos. Esto permite al cargador inteligente 101 hacer balance de las solicitudes de cargo para todos los servicios en una forma que es consistente con la política de redistribución 136, más que en base a un FIFO.

El administrador de sesión (102) usa los datos históricos para un abonado dado o servicio para calcular el valor de una reserva. Por ejemplo, si un SCP de voz siempre solicita una reserva de 60 segundos pero el sistema puede ver a partir de los datos históricos que el abonado tiene un promedio de 130 segundos de duración de llamada, se puede usar esto entonces para la reserva. Esto debería optimizar de modo efectivo el proceso de reservas dado que el SCP en este ejemplo sólo hace la reserva una vez a diferencia de las tres veces. Esta capacidad se puede realizar tanto por abonado como por servicio.

La cuota de recursos disponible total en un momento dado se determina por el administrador de sesión 102 automáticamente examinando un número de parámetros, como sigue.

a) Estructura de cuentas dentro del administrador de datos persistente 104. Una cuenta puede existir dentro de una estructura de cuentas que a su vez representa un grupo de abonados, por ejemplo una familia o un negocio. La cuenta de grupo está disponible para todos los miembros de esa estructura de cuenta a menos que se excluyan explícitamente en un modo abonado a abonado. Es posible que un abonado extraiga de múltiples cuentas simultáneamente. Por ejemplo el abonado puede desear cargar su sesión GPRS a su propia cuenta pero todas las llamadas de voz han de llegar de una cuenta del grupo, negocio.

b) Estructura de fondos, tipo de servicio recursos. Una cuenta puede tener uno o muchos fondos. La mayoría de los fondos están limitados de alguna manera a un uso particular. Es posible que un abonado extraiga de múltiples fondos dentro de una cuenta simultáneamente. Cada fondo se relaciona con uno o muchos servicios, por ejemplo, un fondo de minutos para GPRS y voz que son servicios basados en el tiempo, un fondo solamente para SMS que podría contener algunos SMS libres promocionales o una asignación de un grupo de SMS, un fondo de “caja de arena” para servicios de contenido específico que limitan las unidades que se pueden cargar (dinero, número de mensajes, megabytes, etc.) para su uso por un servicio particular. Típicamente, no todos los fondos se pueden usar para todos los servicios, pero algunos fondos se pueden usar a través de múltiples servicios. En relación a los recursos de fondos, un fondo puede representar un valor monetario prepagado o representar un establecimiento de una disposición de crédito entre el abonado y el operador (pago posterior) o un crédito limitado de pago posterior (por ejemplo “en línea” o una mezcla de los dos) o representar un enlace a un sistema de pago externo tal como una cuenta bancaria o una cuenta de tarjeta de crédito o puede representar un valor de un recurso no monetario tal como minutos o número de mensajes. Cada fondo tiene una y sólo una unidad de recursos asociada con él. Ejemplos de estas unidades son: moneda interna, tiempo (segundos), volumen (bytes), número de mensajes y moneda externa (para promociones), disparos (para un juego) y descargas MP3 (para una promoción). Se realiza una comprobación de consistencia entre el tipo de servicio del fondo y las unidades. Cada fondo dentro de la cuenta tiene una prioridad única que se usa por el administrador 102 para determinar el orden en el que se acaban los fondos. Este orden de prioridad podría ser diferente por tipo de servicio (voz/SMS/MMS, etc.) o basarse en algún otro criterio tal como la hora del día, por ejemplo. Otro ejemplo es que se puede usar un fondo de fidelidad antes de que se use el fondo de prepago. Esto podría ser posible también para que fondos que tengan el mismo orden de prioridad se usen primero en el orden en que expiran las cantidades de los fondos. c) Prioridad de servicio. Cada servicio tiene una priorización única en relación a otros servicios. En casos de competición entre dos servicios se usa la prioridad de servicio para determinar qué servicio se deniega y qué servicio obtiene la cuota. Por ejemplo, cuando las cantidades disponibles totales se aproximan a cero, las sesiones activas con una prioridad más baja se terminarán primero antes que el servicio con una prioridad más alta. Puede haber también servicios agrupados que permitan que se asignen cuotas de tal manera que aseguren que cada sesión finalizará su cuota simultáneamente. En otras realizaciones, las prioridades de sesión se determinan por un número de mecanismos implementados por las funciones 102. La configuración permitirá que se configuren sesiones de modo que sean capaces de ser “reducidas”, por ejemplo no se puede reducir las descargas de un video de un tamaño específico. La configuración puede establecer también que las llamadas de voz o cualquier otra sesión podría “reducir” su duración permitiendo que cualquier saldo menor restante sea asignado a una llamada que pueda estar en progreso. Se pueden determinar también las prioridades a partir de señales de control que se presentan en el momento de la solicitud de sesión desde la entidad de suministro del servicio. Serán capaces de establecer que tienen una sesión importante que debe tener una cantidad de tiempo o una cantidad de datos que no se puede interrumpir. El administrador será capaz de controlar qué entidades de suministro de servicios son capaces de realizar solicitudes de servicio de calidad más alta y para qué servicios están habilitados para hacer esto. Con referencia de nuevo a la Figura 3, se establecen las configuraciones mediante el cambio de atributos del controlador de sesión 135 y del objeto de política 136. Esta es una forma particularmente efectiva de efectuar los ajustes de configuración dado que se propagan a todos los objetos interesados en el administrador de sesión 102. d) Marcador de esfuerzo del mejor servicio. Para algunos servicios es positivo asignar una cuota para menos de lo que fue solicitado, por ejemplo voz. Para otros servicios no lo es dado que son de naturaleza atomizada, por ejemplo una descarga de un programa de software. Si se establece este parámetro para el servicio, sucederá una asignación del mejor esfuerzo en el caso de bajas cantidades. e) Evaluación heurística. Para mejorar el rendimiento, el sistema 101 mantiene una estimación corriente del uso más probable de los recursos totales para cada sesión. De esta forma, el sistema 101 intenta asignar un uso típico de recursos para cada sesión para minimizar el número de solicitudes de nuevos recursos para esa sesión, mientras que también maximiza la cuota disponible total para otras sesiones. Se realiza una comprobación de consistencia entre (d) y (e) en el administrador 102. f) Cargo escalar concurrente. Un cargo escalar es cuando los recursos totales requeridos para una sesión son desconocidos al comienzo de la sesión, por ejemplo, una llamada de voz o una sesión GPRS. Por otro lado, para un cargo por evento, el cargo total es conocido por adelantado, por ejemplo un SMS o una descarga de un juego Java. En el caso en el que dos sesiones de cargo escalar estén compitiendo por una cuota restante, por ejemplo la realización de una llamada de voz mientras que se continúa con una sesión GPRS, es posible que parte de la cuota asignada a una sesión sea retirada y entregada a la otra sesión. Esto ocurre en el caso en el que el ritmo de consumo de una sesión es mayor que el otro, o en el que una nueva sesión se une a un conjunto de sesiones existente (por ejemplo una descarga de alta prioridad llega durante una llamada de voz o una sesión GPRS).

Esto evita una denegación no valida del servicio para el servicio de consumo más rápido. Este aspecto del cargador inteligente 101 garantiza que a pesar de los múltiples escenarios de carga escalar, el abonado puede gastar todo su crédito disponible. g) Cada fondo puede ser rellenado de diferentes formas. El fondo puede ser recargado simplemente como en un sistema de prepago típico o puede ser recargado mediante reglas de la base de reglas 3 dentro del cargador inteligente 101 que asigna crédito de acuerdo con una política definida por un operador, por ejemplo un pago de fidelidad en tiempo real como resultado de un cierto uso del servicio. Cada fondo se puede recargar en una o varias formas. La recarga puede suceder en mitad del servicio y debido a que el cargador inteligente 101 realiza potencialmente múltiples cálculos de cuota y asignaciones por uso de servicio, las cantidades de la recarga pueden estar disponibles para actividades en curso tales como llamadas. En una forma similar, una consulta de saldo en cualquier momento durante el uso del servicio dará una imagen mucho más precisa del saldo que en un sistema prepago tradicional. Finalmente, se puede activar también un fondo o desactivar por el sistema 101 durante una actividad: por ejemplo la banda de tiempos de un fondo se convierte en irrelevante o se alcanza la fecha de caducidad de un fondo de promociones.

Como se ha indicado anteriormente, a diferencia de los sistemas de prepago actuales la gestión de la cuota no se distribuye en el cliente (el punto de control del servicio) sino que se mantiene localmente en el cargador inteligente

101. Éste es el caso para todas las sesiones y todas las unidades de fondos excepto de volumen, que en algunos casos se gestiona localmente por el cliente. Todos los otros temporizadores (para tiempo) y contadores se mantienen dentro del administrador 102. En algunos casos con la cuota de volumen, se realiza un cargo escalar concurrente mediante la solicitud de alguna cuota devuelta procedente del cliente para reasignarla a otras sesiones. Esta capacidad depende de la cooperación del cliente.

El sistema 101 permite que se realice una solicitud de lo que ha usado el usuario actualmente durante la asignación de cuota actual. Entonces se podrá actualizar la cuota conociendo que es físicamente imposible que se haya suministrado en el tiempo tomado para que la respuesta llegue de vuelta y para que se envíe una nueva asignación de cuota. Si el usuario no está en un escenario de crédito bajo permitirá al sistema “recuperar” la cuota asignada desde la red incluso si llega una llamada de voz. Por ejemplo, si el GPRS se basa en el tiempo y no en el volumen será posible de nuevo “recuperar” el tiempo de las redes de datos tan fácilmente como para la voz.

Con referencia de nuevo a la Figura 1, ésta ilustra la responsabilidad y función del Cargador Inteligente 101. Los siguientes son los mensajes ilustrados:

1.: El MSC envía una solicitud inicial para el establecimiento de una llamada al SCP de voz.

2.: El SCP de voz solicita la cuota del cargador inteligente (“IC”) 101.

3.: El IC 101 maneja la solicitud a través del administrador de sesión.

4.: El administrador de sesión en el IC 101 solicita de las reglas de evaluación y cargo 103 la cuota disponible para llamadas de voz que satisfacen todos los parámetros del contexto (hora del día y así sucesivamente).

5.: Las reglas de evaluación y cargo 103 determinan una asignación de cuota. Este será el punto en el que por ejemplo el IC 101 enviará una reserva de cuota de recursos.

6.: El administrador de sesión 102 establece un temporizador y (7) envía un evento para iniciar la llamada a través del SCP.

7.: Véase (6).

8.: Se envía una respuesta al MSC 119 para decirle que encamine la llamada.

9.: Según progresa la llamada, se envía una solicitud para un cargo de evento de un SMS al IC.

10.: Ese evento se maneja por el administrador de sesión 102.

11.: El administrador de sesión 102 solicita una cuota para ese SMS.

12.: El IC 101 aplica sus reglas de evaluación y cargo 103 para asignar una cuota fija para esta sesión. El escenario presentado aquí es un modelo de cargo-reembolso, pero podría ser fácilmente un modelo de reserva-captura.

13.: No se establece ningún temporizador para este servicio. El evento se pasa al sistema de mensajería para su proceso (14).

14.: Véase (13).

15.: Mientras continúa la llamada y mientras el cargo de la sesión se está procesando para el SMS, se solicita un GPRS en contexto PDP para el abonado. El SCP de datos 111 inicia un evento en el IC 101 para solicitarla cuota para proceder. Ésta podría haber sido igualmente un GPRS en contexto PDP para un abonado diferente que sea parte del mismo grupo que el abonado original en 1 a 14 anteriores y como parte de ese grupo tanto este abonado como el previo hacen uso de una cuenta de grupo, es decir un fondo para un recurso que se puede usar para el pago por servicios por cualquier miembro del grupo.

16.: El administrador de sesión 102 toma el control del evento.

17.: El administrador de sesión 102 solicita de las reglas 103 una cuota para este contexto PDP.

18.: La reglas 103 se aplican para establecer una cuota de segundos (tiempo) para este GPRS en contexto PDP ya que ésta es la forma en la que esto se configura por el operador. Casi toda la cuota restante para sesiones basadas en el tiempo se usa en el establecimiento de este contexto PDP. El abonado en el IC está por lo tanto ahora en un escenario de bajo crédito.

19.: Se establece la cuota de tiempo en el administrador de sesión 102 y se envía (20) un evento al sistema GPRS para indicar al SCP de datos que permita el establecimiento de la sesión.

20.: Véase (19).

21.: En este punto la cuota de tiempo asignada a la sesión de voz en (1)-(8) está llegando cerca de su agotamiento. Se envía un evento a la reglas de evaluación y cargo 103 para rellenar este temporizador.

22.: Las reglas de evaluación y cargo 103 en este caso determinan que éste es un escenario de crédito bajo y por ello el IC 101 solicita (cuota restante – 15 s) de todas las sesiones que están usando fondos en relación a voz.

23.: Se envían los detalles del temporizador GPRS a las reglas de evaluación y cargo 103. Continúa con el almacén intermedio de 15 s (que se puede configurar).

24.: La suma de todas las cuotas restantes y todas las cuotas devueltas se divide de acuerdo con las reglas de cargo 103 entre las sesiones en competición. Por ejemplo, se divide uniformemente. Esta cuota se reasigna a la sesión GPRS (24) y a la sesión de voz (25).

25.: Véase (24).

26.: Se repiten las etapas 2-25 hasta que la cuota devuelta es cero. Esto es, no haya cuota disponible en cualquiera de los fondos dentro de la cuenta. En este punto la sesión envía un aviso de crédito bajo al servicio para instruir al SCP para que reproduzca un aviso (27) o introduzca en una página HTML para avisar al abonado para que recargue. Una vez que se ha reproducido este anuncio, cualquier solicitud para devolver la cuota restante a los componentes de evaluación y cargo se rechaza (es decir se devuelve cero). Esto mantiene una experiencia del abonado consistente.

27.: Véase (26).

Se requiere el envío de un mensaje al cliente o clientes que se hayan visto afectados por el registro de una nueva sesión con el administrador de sesión. Esto puede ser o bien un mensaje definido como parte de una interfaz existente, es decir un mensaje dentro de Diameter o bien otra relacionada con la interfaz de cargo. Alternativamente, puede ser un nuevo protocolo definido para transmitir el mensaje de que el cliente ya no tiene acceso a la reserva de crédito que se le daba anteriormente y que esto será hasta que el cliente soporte este nuevo protocolo. El nuevo protocolo o los protocolos existentes se ejecutarán más probablemente por medio de un protocolo de transporte talcomo TCP/IP para permitir la comunicación en red entre múltiples clientes y el administrador de sesión. Ésta puede ser una comunicación de bajo nivel en base a la conexión y una definición de mensajes propietaria o podía ser un mecanismo de comunicación entre procesos de alto nivel, es decir un mecanismo de devolución con solicitudes CORBA, Llamada de Procedimiento Remoto, SOAP o HTTP.

La Figura 5 muestra cómo el cargo de servicios concurrentes introduce una interacción con el cliente para actualizar la cuota de crédito/tiempo que se envió en primer lugar. En este diagrama sucede lo siguiente:

1.: El cliente pide al sistema 101 una reserva de crédito.

2.: El sistema 101 o bien acepta o bien deniega la reserva.

3.: Otro cliente pide al sistema 101 una reserva de crédito, en este punto el administrador de sesión 102 decide qué parte del saldo deberían tener el primer cliente y el segundo cliente e informa a ambos clientes de cuál es la decisión. Esto puede suceder para servicios basados en el tiempo, sin embargo para servicios basados en el volumen se pueda requerir una o más solicitudes al cliente para determinar cuánto volumen se ha usado hasta ese punto en el tiempo.

4.

4a. Se devuelve una respuesta al segundo cliente. 4b. Se envía un mensaje al primer cliente para informarle que la reserva que había solicitado ha cambiado.

5.: El primer cliente vuelve con otra solicitud de cargo en el momento que se basa en la reserva cambiada que se recibió en 4b.

6.: Se devuelve una respuesta que establece cuánto tiempo se permite ahora que suceda.

Es ventajoso que 4b se introduzca como un mensaje a los clientes del servicio y es también ventajoso que el sistema de control tenga la capacidad para actualizar todas las reservas que sucedan en un saldo compartido o un saldo único compartido por múltiples sesiones en curso concurrentes.

En donde un cliente no sea capaz de aceptar un cambio en una reserva se envía un nuevo mensaje que informa al cliente que debe volver y pedir una nueva reserva.

Con referencia a la Figura 6, la diferencia principal en este diagrama es que 4b es una solicitud para que el cliente pida una nueva reserva y 4c y 4d son los flujos de esta solicitud. Sin embargo ésta difiere de técnicas anteriores en que 4a y 4b pueden tener lugar en paralelo de modo que no se retrasa al segundo cliente hasta que el primer cliente realice su nueva solicitud de reserva.

La invención está limitada a las realizaciones descritas pero pueden variar en construcción y detalles. Por ejemplo, se puede aplicar a otros entornos tal como el suministro simultáneo de múltiples servicios de energía. Los servicios son sesiones de comunicación concurrentes, sin embargo, podrían alternativamente ser otros tipos de casos de servicios concurrentes. Los ejemplos de servicios no de comunicación son pagos por aparcamiento, cargos de congestión de tráfico, uso de energía y cargo de peajes. En el campo de comunicaciones, la invención se puede aplicar a redes tales como redes IMS y las sesiones puede ser de cualquier otro tipo tales como SMS, MMS, voz enriquecida o e-mail. La base de datos del sistema de control puede comprender una memoria o dispositivos de almacenamiento permanentes.

También, el fondo de uso puede residir físicamente dentro del sistema de control 101 o se puede mantener en un sistema externo tal como un sistema de facturación externo o un sistema financiero.

También, en otra realización, la cuota que se asigna cuando la entidad de red comunica en primer lugar con el sistema de control se puede basar en la información histórica de lo que se ve típicamente en un emplazamiento específico. Un algoritmo de seguimiento de uso realiza este procesamiento. Por ejemplo, se puede determinar y usar la duración de llamada promedio de un operador cuando se determina cuál debería ser la primera asignación. Esto reducirá las posibilidades de que el fondo de crédito sea sobreasignado cuando suceden otros servicios concurrentemente y se reduce la posibilidad de que se haya de extender la reserva original.

Teniendo la evaluación de todos los servicios controlados por el sistema, un operador será capaz de realizar una valoración a través de los servicios de procesamiento de la fidelidad. Por ejemplo, el precio para las llamadas de voz podría quedar afectado por el número de SMS o MMS que ha enviado un abonado.

Adicionalmente, en otra realización, el sistema de control tiene una interfaz con una entidad de suministro de servicios tal como una entidad de red de móviles para la negociación de la asignación de recursos. Esto se puede realizar inicialmente al comienzo de las sesiones o dinámicamente en respuesta a eventos. Por ejemplo, el sistema puede interactuar con los SCP y el SCP de datos tal como el PSA (Agente de Suministro Previo de Servicios). Los SCP de datos controlan típicamente los SMS, MMS y el uso de GPRS. En el futuro los servidores MSC, servidores de aplicaciones y otras entidades de red IMS comunicarán con el IC. En otras realizaciones, el sistema puede tener una interfaz con cualquier elemento de cálculo que esté controlando el suministro de un servicio, por ejemplo decodificador para TV de prepago o medidor de electricidad inteligente que sea capaz de comunicar a través de TCP/IP u otras redes para determinar si un abonado ha pagado su consumo eléctrico.

Claims

REIVINDICACIONES

1. Un sistema de supervisión y control del suministro de servicios en tiempo real que comprende:

un administrador de datos (104) que comprende medios para el mantenimiento de datos de los recursos de cuantas asociadas con cada una de una pluralidad de cuentas de recursos con uno o más servicios, en los que al menos una cuenta se asocia con una pluralidad de servicios y

un administrador de sesión (102) que comprende:

funciones para la interfaz con una pluralidad de entidades de suministro de servicio;

funciones para el procesamiento de solicitudes desde dichas entidades para el establecimiento de recursos de mantenimiento de sesiones de suministro de servicio;

funciones para la supervisión de sesiones concurrentes en tiempo real;

una base de reglas (103) para, en tiempo real, reasignar los recursos de dichas cuentas (104) a las sesiones concurrentes de acuerdo con el uso del servicio y

funciones para notificar a las entidades de suministro de servicios la reasignación de los recursos,

en el que el administrador de sesión (110) comprende medios para la generación de un mensaje para una entidad de servicio para o bien solicitar recursos adicionales para la cuenta si estima que los recursos se agotarán durante una sesión actual o bien para informar a la entidad de una nueva cuota de recursos;

en el que el administrador de sesión (102) comprende medios para la interfaz con una entidad de suministro de servicios para la negociación de la asignación de recursos;

en el que el administrador de datos (104) comprende medios para el mantenimiento de al menos un fondo para cada cuenta y en el que cada fondo se asocia con una unidad de recursos;

en el que las unidades incluyen el tiempo, volumen de bytes, número de mensajes y número de descargas de programas o contenido;

en el que el administrador de sesión (102) comprende medios para la determinación de las prioridades para la asignación de recursos y para el uso de las prioridades para determinar el orden en el que se han de agotar los fondos de acuerdo con la prioridad;

en el que el administrador de datos (104) comprende medios para la asociación de una prioridad con cada fondo;

en el que el administrador de sesión (102) comprende medios para la denegación de una solicitud de servicio si determina que hay insuficientes recursos para satisfacer a todas las sesiones y

en el que el administrador de datos (104) comprende medios para la modificación de modo dinámico de las cuentas durante las sesiones que extraen recursos de dichas cuentas.
2.

Un sistema de acuerdo con la reivindicación 1, en el que las entidades de suministro de servicio son entidades de redes de comunicación y el servicio se usa en sesiones de comunicación en el que el administrador de datos comprende medios para el mantenimiento de cuentas para recursos escalares y basados en eventos.
3.

Un sistema de acuerdo con las reivindicaciones 1 ó 2, en el que el administrador de sesión (102) comprende medios para el mantenimiento de una estimación corriente de los recursos totales para sesiones concurrentes y comprende medios para la asignación de recursos a cada sesión para minimizar el número de solicitudes de nuevos recursos.
4.

Un sistema de acuerdo con la reivindicación 3, en el que el administrador de sesión (102) comprende medios para la generación de una estimación de requisitos de recursos tras el comienzo de una nueva sesión.
5.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende medios para el uso de datos históricos para el cálculo de una asignación inicial de recursos para una sesión.
6.

Un sistema de acuerdo con la reivindicación 5, en el que el administrador de sesión comprende medios para el cálculo, usando datos históricos por abonado, de la asignación de recursos inicial tras la detección de la identidad del abonado.
7.

Un sistema de acuerdo con cualquiera de las reivindicaciones 5 ó 6, en el que el administrador de sesión comprende medios para el cálculo, usando datos históricos por servicio, de la asignación de recursos iniciales de acuerdo con el servicio.
8.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que al menos se asocia un fondo por el administrador de sesión (102) con una pluralidad de tipos de servicios.
9.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende medios para la asociación de una cuenta de recursos con un grupo de abonados.
10.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende medios para la reasignación de todas las sesiones concurrentes de acuerdo con una política que determina una hora de finalización objetivo para las sesiones.
11.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende medios para la reasignación de todas las sesiones concurrentes de acuerdo con una política que determina los volúmenes de datos objetivo para las sesiones y en el que la reasignación se realiza en base a que todas las sesiones concurrentes finalicen aproximadamente al mismo tiempo.
12.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende medios para la interfaz con las entidades de suministro de servicios de acuerdo con un esquema de reserva-captura.
13.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende medios para el marcado de los recursos que están disponibles para modificación para la reasignación y en el que el administrador de sesión (102) no marca algunas descargas de software como que están disponibles para modificación ya que son de naturaleza atomizada.
14.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende medios para la interfaz con las entidades de servicios en paralelo.
15.

Un sistema de acuerdo con cualquier reivindicación precedente, en el que el administrador de sesión (102) comprende un objeto controlador de sesión (135) enlazado con un objeto de política de reasignación de recursos

(136) que tiene al menos un algoritmo, método de reasignación y el objeto controlador de sesión (135) tiene métodos para llamar al objeto de política de reasignación (136) para la toma de decisiones de reasignación de recursos.
16.

Un sistema de acuerdo con la reivindicación 15, en el que el objeto controlador de sesión (135), tiene una pluralidad de objetos de sesión (139), conteniendo cada uno al menos un objeto de fichas de reserva (140) y el objeto controlador de sesión (135) realiza dinámicamente la reasignación de recursos mediante instrucciones al objeto de sesión (139) para la modificación de un objeto de fichas de reserva (140) contenido y en el que el objeto de sesión (139) modifica el objeto de fichas de reserva (140) mediante la modificación de un atributo del objeto de ficha de reserva (140) en el que el administrador de sesión (102) comprende una interfaz para la modificación de los atributos de los objetos controlador de sesión (135) y política (136) para implementar los ajustes de configuración.
17.

Un medio que pueda leer un ordenador que comprende código de software para la realización de las operaciones de un sistema de supervisión y control de suministro de servicios en tiempo real, cuando se ejecuta en el procesador del ordenador que incluye las etapas de:

mantenimiento de datos de los recursos de cuentas que asocian cada una de una pluralidad de cuentas de recursos con uno o más servicios, en los que al menos una cuenta se asocia con una pluralidad de servicios y

como administrador de sesión (102):

la interfaz con una pluralidad de entidades de suministro de servicio;

el procesamiento de solicitudes desde dichas entidades para establecer y mantener sesiones de suministro de servicio;

la supervisión de sesiones concurrentes en tiempo real;

como una base de reglas (103), la reasignación de los recursos de dichas cuentas (104) a las sesiones concurrentes de acuerdo con el uso del servicio y la notificación a las entidades de suministro de servicios de la reasignación de los recursos;

como administrador de sesión (102), la generación de un mensaje para una entidad de servicio para o bien solicitar recursos adicionales para la cuenta si estima que los recursos se agotarán durante una sesión actual

o bien para informar a la entidad de una nueva cuota de recursos;

como administrador de sesión (102), la interfaz con una entidad de suministro de servicios para la negociación de la asignación de recursos;

como administrador de datos (104), el mantenimiento de al menos un fondo para cada cuenta y en el que cada fondo se asocia con una unidad de recursos;

en el que las unidades incluyen el tiempo, volumen de bytes, número de mensajes y número de descargas de programas o contenido;

como administrador de sesión (102), la determinación de las prioridades para la asignación de recursos y para el uso de las prioridades para determinar el orden en el que se han de agotar los fondos de acuerdo con 5 la prioridad;

como administrador de datos (104), la asociación de una prioridad con cada fondo;

como el administrador de sesión (102), la denegación de una solicitud de servicio si determina que hay insuficientes recursos para satisfacer a todas las sesiones y

como administrador de datos (104), la modificación de modo dinámico de las cuentas durante las sesiones 10 que extraen recursos de dichas cuentas.