ES2379127T3

ES2379127T3 - Método y aparatos para influir en la invocación de un servicio proporcionado por un servidor de aplicaciones a un equipo de usuario

Info

Publication number: ES2379127T3
Application number: ES08719294T
Authority: ES
Inventors: Maria Luisa Mas Rosique; Nuria Esteban Vares
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2007-06-26
Filing date: 2008-03-13
Publication date: 2012-04-23
Anticipated expiration: 2028-03-13
Also published as: CN101690126B; US20100189017A1; WO2009001177A1; EP2330800A1; CN101690126A; EP2171984A1; ATE537654T1; US8175038B2; EP2171984B1; EP2330800B1

Abstract

Un servidor local de abonado (102, 302) en adelante "HSS", que comprende:una base de datos (103, 303) que almacena un perfil de servicio (116) para un usuario-equipo de usuario, en que el perfil de servicio tiene una serie de criterios de filtro (406) en donde al menos uno incluye: un primer punto desencadenador (410) y al menos un primer desencadenador de punto de servicio (418) que incluye una o más condiciones a ser descargadas a una función de control remoto (108, 110) para comprobar allí dentro si se satisfacen las condiciones antes de que un servicio se invoque para el usuario-equipo de usuario; y un segundo punto desencadenador de servicios (414) y al menos un segundo desencadenador de punto de servicios (416); el servidor local de abonado (302) caracterizado porque: una o más condiciones de prefiltro se especifican en el segundo punto desencadenador (414); y el HSS está adaptado para comprobar las condiciones de prefiltro frente a los datos almacenados internamente (303) asociados con el usuario-equipo de usuario, para determinar aquellos criterios de filtro (406) que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio a ser descargado a la función de control remoto (308, 310) para comprobar allí dentro si se satisfacen las condiciones antes de que se invoque un servicio para el usuario-equipo de usuario.

Description

Método y aparatos para influir en la invocación de un servicio proporcionado por un servidor de aplicaciones a un equipo de usuario.

CAMPO TÉCNICO La presente invención se refiere al campo de las comunicaciones y, en particular, a un servidor (por ejemplo, HSS) y un método para permitir al servidor influir la invocación de un servicio (por ejemplo, el servicio IMS) proporcionado por un servidor de aplicaciones (por ejemplo, el servidor de aplicaciones IMS) a un equipo de usuario (UE).

ANTECEDENTES Las siguientes abreviaturas se definen en la presente, al menos alguna de las cuales se relaciona dentro de la siguiente descripción de la técnica anterior y la presente invención.

3GPP: Proyecto de Cooperación de 3A Generación

CAMEL: Aplicaciones Personalizadas para Lógica Mejorada de Redes Móviles

CS: Circuito Conmutado

CSCF: Función de Control de Sesión de Llamada

GUP: Perfil de Usuario Genérico

HSS: Servidor Local de Abonado

IP: Protocolo de Internet

IP-CAN: Red de Acceso de Conectividad IP

IM: Multimedia IP

IMS: Subsistema Multimedia IP

LTE: Arquitectura de Largo Plazo

PS: Paquete Conmutado

PPA: Respuesta de Perfil de Transmisión Automática

PPR: Petición de Perfil de Transmisión Automática

SAA: Respuesta de Asignación del Servidor

SAR: Petición de Asignación del Servidor

S-CSCF: CSCF de Servicio

SDP: Protocolo de Descripción de Sesiones

SIP: Protocolo de Inicio de Sesiones

UE: Equipo de Usuario

UML: Lenguaje de Modelado Unificado

URI: Identificador de Recursos Uniforme

WLAN: Red de �?rea Local Inalámbrica

Con referencia a la FIGURA 1 (TÉCNICA ANTERIOR), hay un diagrama que ilustra una red 3GPP 100 que tiene un HSS 102 tradicional que se acopla a un dominio de CS 104, un dominio de PS 106 y un subsistema IM CN 108. La red 3GPP 100 se describe en detalle dentro de la TS 29.228 V7.5.0 del 3GPP titulada “Proyecto de Cooperación de 3A Generación; Red Central y Terminales del Grupo de Especificación Técnica; Interfaces Cx y Dx del Subsistema Multimedia IP (IM); Flujos de Señalización y Contenidos de Mensaje (Publicación 7)”, fechada en marzo de 2007 (los

contenidos de la cual se incorporan por referencia aquí dentro). Por lo tanto, aquellos expertos en la técnica están familiarizados con la arquitectura y la funcionalidad de esta red 3GPP 100 particular. De esta manera, por claridad, solamente el HSS 102 y el subsistema IM CN 108 (en particular una CSCF 110 y un servidor de aplicaciones 112) las cuales son relevantes para la presente discusión se tratan en detalle aquí dentro mientras que otros componentes bien conocidos como el GMSC, MSC/VLR, SGSN, GGSN, OSA SCS, IM-SSF etc. no se tratan en detalle dentro de este documento. La CSCF 110 es la entidad dentro del subsistema IM CN 108 que está implicada en el establecimiento de llamada/sesiones de usuario con los UE 114 (solamente se muestra uno). El servidor de aplicaciones 112 es la entidad dentro del subsistema IM CN 108 que proporciona un servicio IMS al UE 114.

El HSS 102 tiene una base de datos maestra 103 la cual almacena información relacionada con los usuarios y sus UE 114 respectivos en la red 3GPP 100. En aras de la simplicidad, el usuario y el equipo de usuario se conocen generalmente como el mismo y a menudo se han identificado como el UE 114 en todo el presente documento, de manera que la información almacenada en la base de datos maestra 103 en forma de usuario se conoce generalmente como los datos de usuario independientemente de si tales datos están asociados con el usuario o su respectivo equipo de usuario. Por ejemplo, el HSS 102 incorpora las funciones del HLR de la red Central 2G/3G además de otras funciones relacionadas con los accesos como las funciones del Subsistema Multimedia IP (IM) de control de usuario, las funciones de CS, las funciones de PS, las funciones WLAN etc… En particular, el HSS 102 soporta las siguientes funciones: (1) gestión de movilidad; (2) generaciones de información de seguridad de usuario;

(3): soporte de seguridad de usuario; (4) soporte de suministro de servicio; (5) soporte de establecimiento de llamadas/sesión; (6) repositorio de datos GUP; (7) manejo de identificación; (8) soporte de autorización de servicio;

(9): autorización de acceso; (10) soporte de servicios de aplicaciones; y (11) soporte de servicios CAMEL. Básicamente, el HSS 102 ha llegado a ser un punto privilegiado en la red 3GPP 100 en que muchos accesos distintos se satisfacen.

El HSS 102 tradicional también tiene múltiples tareas y una de esas tareas es manejar el perfil de servicio 116 para el IMS UE 114 que recibe un servicio IMS desde el servidor de aplicaciones IM 112. Por ejemplo, el HSS 102 descarga el perfil de servicio 116 a una CSCF de servicio 110 (en adelante S-CSCF y en particular la S-CSCF 110) asignada para servir al UE 114 cuando el UE 114 se registra con el subsistema IM CN 108. La S-CSCF 110 entonces usa el perfil de servicio 116 para invocar el servicio IMS para el UE 114. El HSS 102 también descargaría el perfil de servicio 116 a la S-CSCF 110 siempre que un operador cambia administrativamente los datos relacionados con el UE 114. Una discusión acerca de los contenidos del perfil de servicio 116 tradicional se proporciona próximo pero para una discusión más detallada acerca del perfil de servicio tradicional 116 se hace referencia al Anexo B en la TS 29.228 V7.5.0 del 3GPP anteriormente mencionada.

Con referencia a la FIGURA 2A (TÉCNICA ANTERIOR), hay un diagrama que ilustra un esbozo de un modelo UML para el perfil de servicio tradicional 116 que se especifica actualmente en la TS 29.228 V7.5.0 del 3GPP. Como se muestra, el perfil de servicio tradicional 116 tiene lo siguiente: (1) una clase de Identificación Pública 202; (2) una clase de Autorización de Servicio de Red Central 204; (3) una clase de Criterios de Filtro Inicial 206; y (4) una clase de Conjunto de IFC Compartido 208. La clase IFC 206 es relevante para la presente discusión porque contiene los mecanismos que se usan por la S-CSCF 110 para invocar el servicio IMS para el UE 114. De esta manera, la clase IFC 206 se describe en detalle más adelante mientras la clase de identificación Pública 202, la clase de Autorización de Servicio de Red Central 204, y la clase de Conjunto de IFC Compartido 208 no se tratarán en detalle dentro de este documento.

Con referencia a la FIGURA 2B (TÉCNICA ANTERIOR), hay un diagrama que ilustra un esbozo del modelo UML de la clase IFC 206 especificada actualmente en la TS 29.228 V7.5.0 del 3GPP. La clase IFC 206 tiene de cero a n casos IFC 206’ (se muestra uno) cada uno de los cuales se compone de cero o un caso de una clase de Punto Desencadenador 210 y un caso de una clase de Servidor de Aplicaciones 212. Cada IFC 206’ tiene un atributo de priority que indica la prioridad de los criterios del filtro en que cuanto más alto sea el número de prioridad entonces menor es la prioridad de los criterios de filtro. Por ejemplo, un IFC 206’ con un valor más alto del número de prioridad se evaluaría después de que el IFC 206’ con un número de prioridad más pequeño ha sido evaluado. Además, cada IFC 206’ tiene un atributo ProfilePartIndicator que es un tipo enumerado, con valores posibles “REGISTERED y UNREGISTERED”, que indica si el filtro respectivo es una parte del perfil de servicio de usuario registrado o no registrado 116.

La clase de Punto Desencadenador 210 describe los puntos desencadenadores que se comprueban por la S-CSCF 110 para encontrar si el servidor de aplicaciones indicado 112 (por ejemplo) se debería contactar o no para proporcionar un servicio IMS al UE 114. Cada punto desencadenador 210 se compone de 1 a n casos de clase Desencadenadora del Punto de Servicio 214 (a continuación SPT o clase SPT). Además, cada punto desencadenador 210 es una expresión booleana en forma Normal Conjuntiva o Disyuntiva (CNF de DNF). En particular, cada punto desencadenador 210 tiene un atributo ConditionTypeCNF que define cómo se expresa el conjunto de las SPT 214correspondientes, es decir o bien un conjunto OR de conjuntos AND de declaraciones de SPT o bien un conjunto AND de conjuntos OR de declaraciones. Estas combinaciones se denominan, respectivamente, Forma Normal Disyuntiva (DNF) y Forma Normal Conjuntiva (CNF). Se pueden usar ambas formas DNF y CNF. En ausencia de una clase de punto desencadenador 210, esta indicaría un desencadenamiento

incondicional del servidor de aplicaciones 112 indicado.

La clase de Servicio de Aplicaciones 212 indica al servidor de aplicaciones 112 (por ejemplo), que es contactado, si se cumplen los puntos desencadenadores 210 y las SPT 214. La clase de Servidor de Aplicaciones 212 tiene un atributo ServerName el cual contiene el SIP URL del servidor de aplicaciones 112 (por ejemplo). La clase del Servidor de Aplicaciones 212 también tiene un atributo de Manejo por Defecto que indica si el diálogo con el UE 114 se debería liberar si el servidor de aplicaciones 112 no pudiera ser alcanzado. El atributo de Manejo por Defecto se enumera y puede tomar los valores: SESSION_CONTINUED o SESSION_TERMINATED. Además, la clase de Servidor de Aplicaciones 212 contiene cero o un caso de una clase de Información de Servicio 216. La clase de Información de Servicio 216 tiene un atributo ServiceInfo y permite la descarga de información a la S-CSCF 110 en que la información descargada va a ser transferida transparentemente a un servidor de aplicaciones 112 cuando los puntos desencadenadores 210 de la IFC 206’ correspondiente se satisfacen.

Con referencia a la FIGURA 2C (TÉCNICA ANTERIOR), hay un diagrama que ilustra un esbozo de un modelo UML de la clase SPT 214 especificado actualmente en la TS 29.228 V7.5.0 del 3GPP. La clase SPT 214 tiene de uno a n casos de SPT 214’ (se muestra uno) en que cada SPT 214’ tiene un atributo Group que permite el agrupamiento de las SPT que configurarán las subexpresiones dentro de una expresión CNF o DNF. Por ejemplo, en la siguiente expresión CNF (A+B) • (C+D), A+B y C+D corresponderían a grupos distintos. En la CNF, el atributo Group identifica los conjuntos OR de casos SPT 214’. Si la SPT 214’ pertenece a distintos conjuntos OR, entonces esa SPT 214’ puede tener más de un valor Group asignado. Al menos un Group está asignado para cada SPT 214’. En la DNF, el atributo Group identifica los conjuntos AND de casos SPT 214’. Si la SPT 214’ pertenece a distintos conjuntos AND, entonces esa SPT 214’ puede tener más de un valor Group asignado. Al menos un Group se asigna para cada caso SPT 214’. Además, cada SPT 214’ también tiene un atributo ConditionNegated que define si el caso correspondiente se niega (es decir la expresión lógica NO). Además, cada SPT 214’ tiene un atributo RegistrationType que es relevante solamente para el Método SIP 216 (tratado más adelante) que tiene un valor de “REGISTER” (nota: el soporte del atributo RegistrationType es opcional en el HSS 102 y en la S-CSCF 110).

Además, cada SPT 214’ incluye lo siguiente: (1) Clase de Petición URI 218; (2) clase de Método SIP 216; (3) clase de Cabecera SIP 220; (4) clase Caso de Sesión 222; y (5) clase de Descripción de Sesión 224. La clase de Petición URI 218 contiene un atributo RequestURI y define una SPT para la Petición URI. La clase Método SIP 216 contiene un atributo Method y define una SPT para el método SIP. La clase Cabecera SIP 220 contiene un atributo Header y un atributo Content que definen una SPT para la presencia o ausencia de cualquier cabecera SIP o para el contenido de cualquier cabecera SIP. La clase Caso de Sesión 222 es un tipo enumerado con valores posibles “Originating”, “Terminating_Registered”, “Terminating_Unregistered”, “Originating_Unregistered” que indican si se debería usar el filtro por la S-CSCF 110 que maneja el Originating, Terminating para un usuario final registrado 114, Terminating para un usuario final no registrado 114, u Originating para un usuario final no registrado 114. La clase de Información de Descripción de Sesión 224 tiene un atributo Line y un atributo Content los cuales definen una SPT para el contenido de cualquier campo SDP dentro del conjunto de un Método SIP.

En vista de las FIGURAS 2A-2C (TÉCNICA ANTERIOR), se puede ver que el perfil de servicio 116 tiene uno o más IFC 206’ que son el mecanismo que se descarga a y luego se usa por la S-CSCF 110 en el Núcleo IMS 108 para invocar un servicio IMS para el UE 114 (solamente se muestra uno). Básicamente, los IFC 206’ identifican el servidor de aplicaciones IMS 112 particular que tiene que ser invocado por la S-CSCF 110 y que se debe hacer si ese servidor de aplicaciones IMS 112 particular no está disponible. Además, los IFC 206’ incluyen uno o más SPT 214 que especifica bajo qué condiciones el servidor de aplicaciones IMS 112 identificado se implicará en una sesión SIP de manera que el servicio IMS se puede invocar para el UE 114 particular.

En particular, la S-CSCF 110 cuando maneja una petición SIP para el UE 114 (o el servidor de aplicaciones IMS 112 en nombre del UE 114) va a través de la lista de los IFC 206 priorizados y las SPT 214 correspondientes dentro del perfil de servicio 106. Y, cuando las condiciones en los IFC 206 y las SPT 214 correspondientes se satisfacen de acuerdo con la información en la petición SIP entonces la S-CSCF 110 contacta al servidor de aplicaciones IMS 112 que se indicó en la clase del Servidor de Aplicaciones 212 para invocar la petición SIP. En términos generales, los IFC 206 se relacionan con los mensajes SIP y los procedimientos SIP y, consecuentemente, las condiciones especificadas en las SPT 214 correspondientes también se relacionan con los contenidos de los mensajes SIP y los procedimientos SIP. Esto se puede ver por el hecho de que las SPT 214 que han sido estandarizadas hasta la fecha incluyen la Petición URI 218, el Método SIP 216 (por ejemplo INVITE), la Cabecera SIP (para la presencia o ausencia de cualquier cabecera SIP o para el contenido de cualquier cabecera SIP), el Caso de Sesión 222 (un tipo enumerado, con valores posibles “Originating”, “Terminating_Registered”, “Terminating_Unregistered”, “Originating_Unregistered”), y la Descripción de Sesiones 224 (para el contenido de cualquier campo SDP situado dentro del conjunto de un Método SIP) (nota: SDP es un formato para describir los parámetros de iniciación de medios de difusión en forma continua y se trata en detalle dentro de la RFC 4566 de la IETF).

No obstante, hay un alto interés hoy día para tener en cuenta otra información y no solamente la información SIP que se relaciona con la petición SIP específica que se recibe por la S-CSCF 110 para invocar un servicio IMS para el UE 114. Por ejemplo, hoy en día no es posible tener en cuenta el estado de CS (GSM agregado, etc…) del UE 114

para decidir si un servidor de aplicaciones IMS 112 u otro servidor de aplicaciones IMS se debería implicar en la petición SIP. Por consiguiente, ha sido y es una necesidad abordar este defecto y otros defectos con la última tecnología actual invocando un servicio IMS para un UE particular. Esta necesidad y otras necesidades se satisfacen por la presente invención.

SUMARIO En un aspecto, la invención proporciona un servidor que incluye una base de datos que almacena un perfil de servicio para el usuario, en que el perfil de servicio tiene una serie de criterios de filtro, en el que al menos uno incluye: (1) un primer punto desencadenador y al menos un primer desencadenador de punto de servicio que especifica una o más condiciones que cuando se satisfacen se descargarán a y comprobarán por una función de Control remoto antes de que un servicio se invoque para el usuario-equipo de usuario; y (2) un segundo punto desencadenador y al menos un segundo desencadenador de punto de servicio que especifica una o más condiciones que se comprueban frente a los datos almacenados internamente (por ejemplo, datos no relacionados con SIP) asociadas con el usuario-equipo de usuario y que necesitan ser satisfechas antes de que el perfil de servicio con criterios de filtro que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio se descargue a y compruebe por la función de control remoto para invocar el servicio para el usuario-equipo usuario. Este esquema es deseable dado que el servidor puede usar información no relacionada con SIP almacenada internamente cuando se invoca un servicio para el usuario-equipo de usuario. Además, este esquema es deseable dado que el servidor puede influir la invocación del servicio usando el segundo punto desencadenador y los datos no relacionados con SIP almacenados internamente para determinar si el primer punto desencadenador se debería descargar en el primer lugar a la función de control remoto que entonces puede invocar el servicio para el usuario-equipo de usuario.

En otro aspecto, la presente invención proporciona un método para permitir a un servidor influir una invocación de un servicio a un usuario-equipo de usuario. El método que comprende los pasos de: (a) crear un perfil de servicio para el usuario-equipo de usuario, en que el perfil de servicio tiene una serie de criterios de filtro, en el que al menos uno incluye: (1) un primer punto desencadenador y al menos un primer desencadenador de punto de servicio que especifica una o más condiciones que tienen que ser satisfechas antes de que una función de control remoto pueda invocar el servicio para el usuario-equipo de usuario; y (2) un segundo punto desencadenador y al menos un segundo desencadenador de punto de servicio que especifica una o más condiciones que se comprobarán frente a los datos almacenados internamente que está asociada con el usuario-equipo de usuario; (b) prefiltrar los criterios de filtro determinando si hay una coincidencia entre la una o más condiciones en el al menos un segundo desencadenador de punto de servicio y los datos almacenados internamente que se asocian con el usuario-equipo de usuario; (c) si hay una coincidencia, entonces descargar el perfil de servicio con los criterios de filtro que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio para la función de control remoto, en donde la función de control remoto entonces necesita confirmar que la una o más condiciones del al menos un primer desencadenador de punto de servicio se satisfacen antes de invocar el servicio para el usuarioequipo de usuario; y (d) si no hay una coincidencia, entonces impedir la descarga del perfil de servicio con los criterios de filtro que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio para la función de control remoto.

Aún en otro aspecto, la presente invención proporciona una red 3GPP que incluye un HSS, una S-CSCF, y un Servidor de Aplicaciones IMS, en la que el HSS influye una invocación de un servicio IMS proporcionado por dicho Servidor de Aplicaciones IMS a un usuario-equipo de usuario mediante: (a) la creación de un perfil de servicio para el usuario-equipo de usuario, en que el perfil de servicio tiene unos Criterios de Filtro Iniciales (IFC) que incluye: (1) un primer punto desencadenador y al menos un primer desencadenador de punto de servicio que especifica una o más condiciones que tienen que ser satisfechas antes de que la S-CSCF pueda invocar el servicio IMS para el usuario-equipo de usuario; y (2) un segundo punto desencadenador y al menos un segundo desencadenador de punto de servicio que especifica una o más condiciones que se comprobarán frente a datos almacenados internamente que está asociados con el usuario-equipo de usuario; (b) prefiltrar los IFC mediante la determinación de si hay una coincidencia entre la una o más condiciones en el al menos un segundo desencadenador de punto de servicio y los datos almacenados internamente que están asociados con el usuario-equipo de usuario; (c) si hay una coincidencia, entonces descargar el perfil de servicio con los IFC incluyendo el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio a la S-CSCF, en el que la S-CSCF entonces tiene que confirmar que la una o más condiciones del al menos un primer desencadenador del punto de servicio se satisfacen antes de invocar al Servidor de Aplicaciones IMS para proporcionar el servicio IMS para el usuario-equipo de usuario; y (d) si no hay una coincidencia, entonces impedir la descarga del perfil de servicio con los IFC que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio a la S-CSCF.

Aspectos adicionales de la invención se establecerán en adelante, en parte, en la descripción detallada, las figuras y cualesquiera reivindicaciones que siguen, y en parte se derivará de la descripción detallada, o se puede aprender por la práctica de la invención. Se tiene que entender que tanto la descripción general anteriormente mencionada como la descripción detallada siguiente son ejemplares y explicativas solamente y no son restrictivas de la invención según se revela.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Una comprensión más completa de la presente invención se puede obtener por referencia a la siguiente descripción detallada cuando se toma en conjunto con los dibujos anexos:

La FIGURA 1 (TÉCNICA ANTERIOR) es un diagrama que ilustra una red 3GPP que tiene un HSS tradicional acoplado a un dominio de CS, un dominio de CS y un subsistema IM CN según se especifica actualmente en la TS 29.228 V7.5.0 del 3GPP. Las FIGURAS 2A-2C (TÉCNICA ANTERIOR) son diagramas que ilustran un esbozo de un modelo UML para el perfil de servicio tradicional que se especifica actualmente en la TS 29.228 V7.5.0 del 3GPP. La FIGURA 3 es un diagrama que ilustra una red 3GPP que tiene un HSS mejorado que se acopla a un dominio de CS, un dominio de PS y un subsistema IM CN de acuerdo con la presente invención; Las FIGURAS 4A-4C son tres diagramas que ilustran un esbozo de un modelo UML para un perfil de servicio ejemplar que se configura de acuerdo con la presente invención; La FIGURA 5 es un diagrama de flujo de señal que ilustra cómo se puede usar el HSS mejorado durante el registro de un UE de acuerdo con la presente invención; La FIGURA 6 es un diagrama de flujo de señal que ilustra cómo se puede usar el HSS mejorado durante una sesión de terminación hacia un UE de acuerdo con la presente invención; y La FIGURA 7 es un diagrama de flujo de señal que ilustra cómo el HSS mejorado se puede usar cuando hay un cambio en los datos para el UE de acuerdo con la presente invención.

DESCRIPCIÓN DETALLADA Con referencia a la FIGURA 3, hay un diagrama que ilustra una red 3GPP 300 que tiene un HSS mejorado 302 que está acoplado a un dominio de CS 304, un dominio de PS 306 y un subsistema IM CN 308 de acuerdo con la presente invención. El HSS mejorado 302 tiene una base de datos maestra 303 para los UE 314 (solamente se muestra uno) que soporta las funciones del HLR así como la descripción relacionada con el IMS y los datos de abonado. El HSS mejorado 302 también maneja un perfil de servicio 316 para cada IMS UE 314 y, durante el registro de un UE dado 314, presenta el perfil de servicio correspondiente 316 hacia una S-CSCF 310 (situada en el subsistema IM CN 308) que se asigna para servir al UE dado 314. En aras de la simplicidad, el usuario y el equipo de usuario se conocen generalmente como el mismo y a menudo se han identificado como el UE 314 en todo el presente documento, de manera que la información almacenada en la base de datos maestra 303 en forma de usuario generalmente se conoce como los datos de usuario independientemente de si tales datos se asocian con el usuario o su respectivo equipo de usuario.

Como en el pasado, el HSS mejorado 302 aún maneja un perfil de servicio 316 que incluye los IFC tradicionales que se usan por la S-CSCF 310 para invocar los servicios IMS ejecutados en un Servidor de Aplicaciones IMS 312 para el usuario y su respectivo UE 314. Cada IFC tradicional, en un perfil de servicio 316 para un UE dado 314, incluye una pluralidad de SPT que especifican las condiciones que necesitan ser satisfechas antes de que la S-CSCF 310 implique a un servidor de aplicaciones IMS 312 en la invocación de los servicios IMS para el UE dado 314. Los IFC tradicionales se relacionan con los mensajes SIP y los procedimientos SIP y, consecuentemente, las condiciones especificadas por las SPT correspondientes también se relacionan con los contenidos de los mensajes SIP y los procedimientos SIP. No obstante, el perfil de servicio 316 también se ha cambiado de manera que otra información y no solamente la información SIP que se relaciona con una petición SIP específica recibida por la S-CSCF 110 se puede tener en cuenta para influir la invocación de un servicio IMS para un UE dado 314. Por ejemplo, la otra información puede incluir datos tales como si el estado de CS está activo o no para el UE dado 314, la IP-CAN donde el UE dado 314 ha accedido a la red IMS 208, el tipo de red PS 306 accedida por el UE dado 314 etc. El HSS mejorado 302 ha accedido a esta información no relacionada con SIP dado que es la base de datos maestra para la red 3GPP 300.

En particular, el HSS mejorado 302 de acuerdo con la presente invención proporciona un perfil de servicio 316 que tiene un paquete de IFC mejorado que, en adición a los IFC tradicionales (que incluyen las SPT relacionadas con SIP), además incluye los que son llamados aquí dentro como Puntos Desencadenadores HSS (HSS-TP). Cada HSS-TP incluye condiciones de prefiltro que se comprueban por el HSS mejorado 302 frente a los datos de abonado relevantes (por ejemplo, la información no relacionada con SIP) para determinar que si se descargará cualquiera de los IFC configurados para el UE dado 314 y además evaluará por la S-CSCF asignada 310. Se proporciona una descripción detallada más adelante para explicar cómo el perfil de servicio 316 se expande para incluir los nuevos HSS-TP y entonces se proporciona una discusión para explicar cómo el HSS mejorado 302 funciona para influir la invocación de un servicio IMS para un UE dado 314 mediante el uso de los nuevos HSS-TP para determinar cuáles IFC en el perfil de servicio 316 se descargarán para la S-CSCF 310 asignada.

Con referencia a las FIGURAS 4A-4C, hay tres diagramas que ilustran un esbozo de un modelo UML para un perfil de servicio ejemplar 316 que se configura de acuerdo con la presente invención. La FIGURA 4A ilustra un alto nivel del perfil de servicio ejemplar 316 que tiene lo siguiente: (1) una clase de Identificación Pública 402; (2) una clase de Autorización de Servicio de Red Central 404; (3) una clase de Criterios de Filtro Inicial mejorada 406; y (4) una clase de Conjunto de IFC Compartidos 408. El perfil de servicio 316 incluye la clase de IFC mejorada 406 que se describe en detalle más adelante y también usa la clase de Identificación Pública previamente estandarizada 402, la clase de

Autorización de Servicio de Red Central 404, y la clase de Conjunto de IFC Compartidos 408 (comparar con la FIGURA 2A).

La FIGURA 4B es un diagrama que ilustra un esbozo del modelo UML de la clase IFC mejorada 406 de acuerdo con la presente invención. La clase IFC mejorada 406 tiene de cero a n casos IFC 406’ (se muestra uno) cada uno de los cuales tiene un atributo de prioridad que indica la prioridad de los criterios de filtro en que cuanto mayor sea el número de prioridad entonces menor es la prioridad de los criterios del filtro. Por ejemplo, un IFC 406’ con un valor de número de prioridad más alto se evaluaría después que los IFC 406’ con un número de prioridad más pequeño se han evaluado. Además, cada IFC 406’ tiene un atributo ProfilePartIndicator que es un tipo enumerado, con valores posibles “REGISTERED” y “UNREGISTERED”, que indica si el filtro respectivo es una parte del perfil de servicio 316 registrado o sin registrado.

Además, cada caso IFC 406’ se compone de cero o un caso de una clase de Punto Desencadenador 410, un caso de una clase de Servidor de Aplicaciones 412, y un caso de un punto desencadenador HSS 414 que incluye una o más STP de propiedad del HSS 416. En particular, cada IFC 406’ tiene la clase de Punto Desencadenador estandarizada 410 (que incluye la SPT correspondiente 418), la clase de Servidor de Aplicaciones estandarizado 412 (que incluye la Información de Servicio correspondiente 417), y el nuevo punto desencadenador HSS 414 que tiene las SPT de propiedad HSS correspondiente 416 (comparar con la FIGURA 2B). La SPT 418 tiene de uno a n casos SPT 418’ uno de los cuales se muestra en detalle en la FIGURA 4C e incluye lo siguiente: (1) la clase de Petición URI 420; (2) la clase de Método SIP 422; (3) la clase de Cabecera SIP 424; (4) la clase de Caso de Sesión 426; y (5) la clase de Descripción de Sesión 428 (comparar con la FIGURA 2C).

Como se muestra en la FIGURA 4B, el punto desencadenador HSS 414 se compone de 1 a n casos de las SPT de propiedad del HSS 416. Además, cada punto desencadenador HSS 414 es una expresión booleana en forma Normal Conjuntiva o Disyuntiva (CNF o DNF). Más específicamente, cada punto desencadenador HSS 414 tiene un atributo ConditionTypeCNF que define cómo se expresa el conjunto de las SPT de propiedad del HSS 416, es decir

o bien un conjunto OR de conjuntos AND de declaraciones de SPT o bien un conjunto AND de conjuntos OR de declaraciones. Estas combinaciones se denominan, respectivamente, Forma Normal Disyuntiva (DNF) y Forma Normal Conjuntiva (CNF). Ambas formas DNF y CNF se pueden usar.

En funcionamiento, el HSS mejorado 302 durante el registro del UE 314 (por ejemplo) comprueba cada IFC 406’ y su punto desencadenador HSS 414 correspondiente y las SPT de propiedad del HSS asociadas 416 para determinar si la clase de punto Desencadenador correspondiente 410 y la clase de Servicio de Aplicaciones 412 se descargará a la S-CSCF 310. En particular, el HSS mejorado 302 tiene un proceso de evaluación que comprueba las condiciones fijadas en las SPT de propiedad del HSS 416 frente a los datos de usuario no relacionados con SIP almacenados internamente. Si hay una coincidencia, entonces el HSS mejorado 302 descarga el perfil de servicio 316 con el IFC correspondiente 406’ (ausente el punto desencadenador del HSS 414 y las SPT de propiedad del HSS asociadas 416) a la S-CSCF 310. Si no hay una coincidencia, entonces el HSS mejorado 302 descarga el perfil de servicio 316 sin el IFC correspondiente 406’ a la S-CSCF 310. Tras recibir el perfil de servicio 316, la S-CSCF 310 va a través de los IFC recibidos 406’ y sus SPT correspondientes 418 y cuando las condiciones en los IFC 406’ y las SPT correspondientes 418 se satisfacen de acuerdo con la información en una petición SIP pendiente entonces la S-CSCF 310 contacta el servidor de aplicaciones IMS adecuado 312 para invocar la petición SIP y proporciona el servicio IMS al UE 314. En este sentido, el HSS mejorado 302 es capaz de influir la invocación del servicio IMS proporcionado por un servidor de aplicaciones IMS 312 al UE 314.

Como se puede ver, el HSS mejorado 302 incluye en cada IFC 406’ una combinación de un nuevo tipo de las SPT llamadas SPT de propiedad del HSS 416 que no se descargan a la S-CSCF 310 pero en su lugar primero se evalúan en el HSS mejorado 302. En este proceso de evaluación, el HSS mejorado 302 determina si se satisfacen las condiciones en las SPT de propiedad del HSS 416 en vista de la información no relacionada con SIP y si es así entonces los IFC correspondientes 406’ se descargarán a la S-CSCF 310 y si no es así entonces las IFC correspondientes 406’ no se descargarán a la S-CSCF 310. En una posible aplicación, suponemos de acuerdo con las SPT de propiedad del HSS 416 de un IFC 406’ que el UE 314 necesita estar en el estado CS=GSM agregado para ese IFC 406’ para aplicar, entonces solamente si ese es el caso, que ese IFC 406’ se enviará abajo a la S-CSCF 310. Si el UE 314 no es GSM agregado, entonces desde la perspectiva del núcleo IMS 308 ese IFC 406’ particular nunca fue parte del perfil de servicio de usuario 316. Algunos ejemplos adicionales de datos no relacionados con SIP que se pueden usar para comprobar las condiciones en las SPT de propiedad del HSS 416 incluyen los datos de usuario relacionados con una IP-CAN accedidos por el UE 314, la red PS 106 accedida por el UE 314, la ubicación del usuario sobre distintos accesos etc. Es importante remarcar que el HSS mejorado 302 es un punto privilegiado en la red 3GPP 300 en que se cumplen los muchos distintos accesos, y así ya almacena mucha información valiosa (información no relacionada con SIP) acerca del UE 314 que se podría usar en el proceso de evaluación.

El comportamiento del HSS mejorado 302 en que las SPT de propiedad del HSS 416 se evalúan usando la información no relacionada con SIP es beneficioso en muchos procedimientos IMS diferentes. Varios ejemplos de los cuales son los siguientes:

! En el registro de usuario: los IFC 406’ que tienen las SPT de propiedad del HSS 416 se evaluarán por el HSS mejorado 302, y descargarán a la S-CSCF 310 solamente si se cumplen sus condiciones de acuerdo con el conocimiento del HSS del UE 314 (ver la FIGURA 5).

! En una sesión de terminación hacia un usuario no registrado: La respuesta del HSS mejorado 302 a una petición de información de ubicación será tal que la asignación de la S-CSCF 310 procederá solamente si hay al menos un IFC 406’ dejado que es aplicable al “estado no registrado” del usuario después de que han sido evaluadas las SPT de propiedad del HSS (ver la FIGURA 6).

! En un cambio de los datos dinámicos de usuario relevantes para las SPT de propiedad del HSS 416 o en un cambio del perfil de servicio de usuario 316 mediante el suministro de: La evaluación del HSS mejorado 302 de las SPT de propiedad del HSS 416 puede conducir a la descarga del perfil de servicio 316 a la S-CSCF 310 solamente si hay algunos cambios cuando se compara con el perfil de servicio de usuario previamente descargado 316 (ver la FIGURA 7).

Con referencia a la FIGURA 5, hay un diagrama de flujo de señal que ilustra cómo el HSS mejorado 302 se puede usar durante el registro de un UE 314 de acuerdo con la presente invención. Los pasos son como sigue:

1.El UE 314 (UE A) usa el VMSC para registrarse en CS con el HSS mejorado 302.

2.El UE 314 (UE A) comienza una petición de registro IMS con la S-CSCF 310.

3.La S-CSCF 310 envía un mensaje SAR al HSS mejorado 302.

4.El HSS mejorado 302 usa la información no relacionada con SIP para evaluar (o prefiltrar) las SPT de propiedad del HSS 416 en el perfil de servicio 316 asociado con el UE 314. En este caso, el estado de registro del UE 314 en el acceso de CS se tendrá en cuenta durante la evaluación de las SPT de propiedad del HSS 416 en el perfil de servicio 316.

5.El HSS mejorado 302 descarga un mensaje SAA (que incluye el perfil de servicio 316 del UE 314 con los IFC 406’ aplicables en base al resultado del paso 4) a la S-CSCF 310.

6.El UE 314 (UE A) se registra con la S-CSCF 310.

Con referencia a la FIGURA 6, hay un diagrama de flujo de señal que ilustra cómo el HSS mejorado 302 se puede usar durante una sesión de terminación hacia el UE 314 de acuerdo con la presente invención. Los pasos son los siguientes:

1.El UE 314 (UE A) usa el VMSC para registrarse en CS con el HSS mejorado 302.

2.El UE B envía un SIP INVITE a la S-CSCF 310 para establecer una sesión con el UE 314. Más precisamente, este mensaje SIP INVITE no se presenta directamente desde el UE B hacia la S-CSCF 310 sino que se presenta más bien a través de otros nodos de red que no se han representado en aras de la simplicidad, dado que no son relevantes para la presente discusión.

3.La S-CSCF 310 envía un mensaje SAR al HSS mejorado 302. En este momento, el UE 314 no está registrado en el IMS pero se agrega a CS (paso 1)

5.El HSS mejorado 302 descarga un mensaje SAA (que incluye el perfil de servicio 316 del UE 314 con los IFC 406’ aplicables en base al resultado del paso 4) a la S-CSCF 310. Este perfil de servicio 316 se usará para establecer una sesión entre el UE B y el UE 314.

Nota: Hay otro posible resultado en este caso de sesión de terminación el cual es que, después de que se han evaluado las SPT de propiedad del HSS (paso 4), no hay incluso un IFC 406’ dejado que sea aplicable al UE 314 cuando está en “estado no registrado”. Si este es el caso, entonces la respuesta del HSS mejorado 302 a la petición recibida (paso 5) indicará esto y el establecimiento de la sesión no progresará.

Con referencia a la FIGURA 7, hay un diagrama de flujo de señal que ilustra cómo el HSS mejorado 302 se puede usar cuando hay un cambio en los datos para el UE 314 de acuerdo con la presente invención. Los pasos son los

siguientes:

1.El UE 314 (UE A) usa el VMSC para registrarse en CS con el HSS mejorado 302.

2.El UE 314 (UE A) comienza una petición de registro IMS con la S-CSCF 310 asignada.

3.La S-CSCF 310 envía un mensaje SAR al HSS mejorado 302.

6.El UE 314 (UE A) se registra con la S-CSCF 310.

7.El UE 314 (UE A) se separa de CS lo cual significa que el estado del UE 314 ha cambiado respecto al estado de CS que fue almacenado en el HSS mejorado 302 y usado en el paso 4.

8. El HSS mejorado 302 vuelve a evaluar las SPT de propiedad del HSS 416 en el perfil de servicio 316 del UE 314 porque el estado del UE 314 respecto a la fijación de CS ha cambiado del CS agregado al CS separado.

9.El HSS mejorado 302 descarga un mensaje PPR (que incluye el perfil de servicio 316 del UE 314 con los IFC aplicables 406’ (en su caso) en base al resultado del paso 8) a la S-CSCF 310.

10. La S-CSCF 310 responde enviando un mensaje PPA de vuelta al HSS mejorado 302.

En una realización alternativa, el mecanismo es que se añaden nuevas SPT a las SPT existentes 418 de manera que los puntos desencadenadores 410 incluyen las condiciones relacionadas con la información de usuario almacenada del HSS, y que, en lugar de evaluar estas nuevas SPT en el HSS mejorado 302 (como se describió anteriormente), la S-CSCF 310 recibe toda esta información en descarga en tiempo real desde el HSS mejorado

302. En particular, el HSS mejorado 302 descargaría a la S-CSCF 310 todos los IFC y toda la información de usuario no relacionada con SIP (por ejemplo, el estado de CS del usuario), de manera que esta información SIP no relacionada se puede considerar por la S-CSCF 310 durante la evaluación de IFC. No obstante, esta realización alternativa tendría algunas desventajas:

1.Requeriría parámetros adicionales tanto en el perfil de servicio de usuario 316 pero también en el Cx (ver la FIGURA 3), lo cual implica un esfuerzo elevado para obtener esta realización particular estandarizada.

2.Los operadores lo más probable querrán hacer uso de otra información relacionada con el estado de usuario y la ubicación en otros accesos y no solo para el acceso IMS. Si esto ocurre, entonces esta realización particular también necesitaría un esfuerzo de estandarización para cada uno de estos diferentes accesos.

3.La realización particular no está optimizada para la señalización Cx o el almacenamiento de la S-CSCF 310 porque (por ejemplo):

! El HSS 302 estaría, en algunos casos, informando a la S-CSCF 310 sobre los datos de usuario y los cambios de los datos de usuario que no son aplicables a un usuario específico.

! El HSS 302 estaría, en algunos casos, descargando los IFC a la S-CSCF 310 que no puede aplicar en absoluto durante la vida del registro del usuario.

! Los datos de usuario no relacionados con SIP almacenados en el HSS 302 tendrían que ser duplicados, ya que ahora necesitarían ser descargados y sincronizados en la S-CSCF 310.

En comparación, la primera realización de la presente invención en que el HSS mejorado 302 no descarga el SIP no relacionado con la S-CSCF 310 se considera una mejor solución dado que el núcleo del IMS 308 todavía tiene en cuenta la información de usuario almacenada del HSS aunque indirectamente para la invocación del servicio mientras que al mismo tiempo se optimiza el uso tanto de la interfaz de señalización Cx como el almacenamiento de datos (capacidad de memoria) en la S-CSCF 310. Además, es deseable la primera realización de la presente invención dado que los estándares 3GPP actuales especifican qué información de propiedad del HSS necesitan los proveedores para soportar fijar el cumplimiento con una publicación específica. De esta manera, la primera realización de la presente invención permite la diferenciación del proveedor en que proveedores concretos pueden crear sus propias SPT de propiedad del HSS 416 sin problemas de interoperabilidad y sin ninguna estandarización adicional dado que las SPT de propiedad del HSS 416 solamente se conocerían para el HSS mejorado 302.

En resumen, se debería apreciar que la primera realización de la presente solución tratada aquí dentro proporciona un mecanismo eficiente y extensible que permite que la información de usuario almacenada del HSS (tanto la dinámica del usuario sino también los datos suministrados de usuario) sea tenida en cuenta durante el proceso de evaluación IFC, y en este sentido influir los servicios invocados para el usuario correspondiente. El HSS mejorado

10 hace esto añadiendo las SPT de propiedad del HSS a la información de los IFC y realizando un prefiltro de los IFC en sí mismos en base a los datos de usuario no relacionados con SIP que también se almacenan en el HSS. Como resultado de este paso de prefiltro, el IFC se descargará o no a la S-CSCF. En este sentido, el HSS es capaz de influir los servicios de IMS invocados que se proporcionan a un usuario usando los datos de usuario almacenados.

15 Aunque se han ilustrado varias realizaciones de la presente invención en los Dibujos anexos y descritas en la Descripción Detallada anteriormente mencionada, se debería entender que la invención no se limita a las realizaciones reveladas, sino en su lugar también es capaz de numerosas readaptaciones, modificaciones y sustituciones sin salirse del alcance de la invención según se establece en adelante y se define por las siguientes reivindicaciones.

Claims

REIVINDICACIONES

1. Un servidor local de abonado (102, 302) en adelante “HSS”, que comprende:

una base de datos (103, 303) que almacena un perfil de servicio (116) para un usuario-equipo de usuario, en que el perfil de servicio tiene una serie de criterios de filtro (406) en donde al menos uno incluye:

un primer punto desencadenador (410) y al menos un primer desencadenador de punto de servicio

(418) que incluye una o más condiciones a ser descargadas a una función de control remoto (108, 110) para comprobar allí dentro si se satisfacen las condiciones antes de que un servicio se invoque para el usuario-equipo de usuario; y un segundo punto desencadenador de servicios (414) y al menos un segundo desencadenador de punto de servicios (416);

el servidor local de abonado (302) caracterizado porque:

una o más condiciones de prefiltro se especifican en el segundo punto desencadenador (414); y el HSS está adaptado para comprobar las condiciones de prefiltro frente a los datos almacenados internamente (303) asociados con el usuario-equipo de usuario, para determinar aquellos criterios de filtro (406) que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio a ser descargado a la función de control remoto (308, 310) para comprobar allí dentro si se satisfacen las condiciones antes de que se invoque un servicio para el usuario-equipo de usuario.
2.

El HSS de la Reivindicación 1, en el que dicho al menos un primer desencadenador de punto de servicio además incluye:

un Indicador de Recursos Uniforme (URI) de petición; un Método del Protocolo de Inicio de Sesiones (SIP); una Cabecera del Protocolo de Inicio de Sesiones (SIP); un Caso de Sesión; o una Descripción de Sesión
3.

El HSS de la Reivindicación 1, en el que dichos datos almacenados internamente son datos relacionados con protocolos distintos de un Protocolo de Inicio de Sesiones (SIP), dichos datos que incluyen:

un estado de Circuito Conmutado (CS) de un usuario-equipo de usuario; una Red de Acceso de Conectividad IP (IP-CAN) accedida por el usuario-equipo de usuario; o un tipo red de Paquetes Conmutados (PS) accedida por el usuario-equipo de usuario.
4.

El HSS de la Reivindicación 1, en el que el segundo punto desencadenador (414) tiene una expresión booleana en Forma Normal Conjuntiva, CNF, o en Forma Normal Disyuntiva, DNF, que especifica la una o más condiciones de prefiltro que van a ser comprobadas frente a los datos almacenados internamente asociados con el usuario-equipo de usuario.
5.

Un método para permitir a un HSS (302) influir una invocación de un servicio para un usuario-equipo de usuario (314), dicho método que comprende los pasos de:

crear un perfil de servicio para el usuario-equipo de usuario en el HSS, en que el perfil de servicio tiene una serie de criterios de filtro en el que al menos uno incluye:

un primer punto desencadenador y al menos un primer desencadenador de punto de servicio que especifica una o más condiciones que tienen que ser satisfechas en una función de control remoto antes de que dicha función de control remoto pueda invocar el servicio para el usuario-equipo de usuario; y un segundo punto desencadenador y al menos un segundo desencadenador de punto de servicio;

el método caracterizado por:

especificar en el segundo punto desencadenador (414) una o más condiciones de prefiltro para comprobar en el HSS; prefiltrar (paso 4, paso 8) en el HSS los criterios del filtro determinando si hay una coincidencia entre la una o más condiciones de prefiltro y los datos almacenados internamente en el HSS asociados con el usuarioequipo de usuario; si hay una coincidencia, entonces descargar (paso 5, paso 9) el perfil de servicio con los criterios del filtro que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio a la función de control remoto, en el que la función de control remoto entonces necesita confirmar que la una o más condiciones del al menos un primer desencadenador de punto de servicio se satisfacen antes de invocar el servicio para el usuario-equipo de usuario; y si no hay una coincidencia cuando se comprueban las condiciones de prefiltro, entonces impedir la descarga

5 del perfil de servicio con los criterios de filtro que incluyen el primer punto desencadenador y el al menos un primer desencadenador de punto de servicio a la función de control remoto.
6.

El método de la Reivindicación 5, en el que dicho paso de prefiltrado se realiza en el HSS cuando el usuarioequipo de usuario se registra con la función de control remoto.
7.

El método de la Reivindicación 5, en el que dicho paso de prefiltrado se realiza en el HSS cuando otro usuarioequipo de usuario intenta terminar una sesión con el usuario-equipo de usuario.
8. El método de la Reivindicación 5, en el que dicho paso de prefiltrado se realiza en el HSS después de 15 suministrar el perfil de servicio del usuario-equipo de usuario.
9. El método de la Reivindicación 5, en el que dicho paso de prefiltrado se realiza en el HSS después de un cambio en los datos almacenados internamente asociados con el usuario-equipo de usuario.

20 10. El método de la Reivindicación 5, en el que el criterio de filtro es un Criterio de Filtro Inicial, IFC, que se usa dentro de la red 3GPP.
11. El método de la Reivindicación 5, en el que dicha función de control remoto es una Función de Control de Sesión de Llamada de Servicio, S-CSCF, que se usa dentro de una red 3GPP.
12. El método de la Reivindicación 5, en el que dicho al menos un primer desencadenador de punto de servicio además incluye:

un Indicador de Recursos Uniforme (URI) de petición;

30 un Método del Protocolo de Inicio de Sesiones (SIP); una Cabecera del Protocolo de Inicio de Sesiones (SIP); un Caso de Sesión; o una Descripción de Sesión

35 13. El método de la Reivindicación 5, en el que dichos datos almacenados internamente son datos relacionados con protocolos distintos de un Protocolo de Inicio de Sesiones (SIP), dichos datos que incluyen:

un estado de Circuito Conmutado (CS) del usuario-equipo de usuario; una Red de Acceso de Conectividad IP (IP-CAN) accedida por el usuario-equipo de usuario; o 40 un tipo red de Paquetes Conmutados (PS) accedida por el usuario-equipo de usuario.
14. El método de la Reivindicación 5, en el que el segundo punto desencadenador (414) tiene una expresión booleana en Forma Normal Conjuntiva, CNF, o en Forma Normal Disyuntiva, DNF, que especifica la una o más condiciones de prefiltro que van a ser comprobadas frente a los datos almacenados internamente asociados con el

45 usuario-equipo de usuario.