[go: up one dir, main page]

ES2458295T3 - Disposición, nodos y método en relación con acceso a servicios sobre un sistema de comunicación - Google Patents

Disposición, nodos y método en relación con acceso a servicios sobre un sistema de comunicación Download PDF

Info

Publication number
ES2458295T3
ES2458295T3 ES05716144.0T ES05716144T ES2458295T3 ES 2458295 T3 ES2458295 T3 ES 2458295T3 ES 05716144 T ES05716144 T ES 05716144T ES 2458295 T3 ES2458295 T3 ES 2458295T3
Authority
ES
Spain
Prior art keywords
identity
mobile user
billing
user station
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES05716144.0T
Other languages
English (en)
Inventor
Krister Boman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2458295T3 publication Critical patent/ES2458295T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H04L12/1407—Policy-and-charging control [PCC] architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Una disposición en un sistema de comunicaciones que participa en procedimientos de solicitud de y/o de acceso a servicios de estación de usuario, y que comprende una serie de nodos de soporte de datos en paquetes (GGSN; CGSN; TPF; 10; 10B; 10C), una serie de nodos de gestión de facturación y/o de políticas (CRF; TPF; PCCN; 30; 30A; 30B; 30C) y una serie de funciones de aplicación (AF; P, S, ICSCF; 20; 20B; 20C) que administran la gestión de movilidad y el control de llamadas de estaciones de usuario móviles (UE; 1) que solicitan y/o acceden a servicios, caracterizada por que el nodo o nodos de soporte de datos en paquetes (10; 10B; 10C) comprenden medios adoptados para enviar una primera información relativa a la identidad de la estación de usuario móvil (UE; 1) sobre una primera interfaz (Gx, Gy; Gx/Gy) a un nodo de gestión de facturación y/o de políticas (CRF; PDF; PCCN; 30; 30A; 30B; 30C), a la recepción de una solicitud de servicios de portador procedente de una estación de usuario móvil (UE; 1) por que la función o funciones de aplicación (AF; P, S, ICSCF; 20; 20B; 20C) comprenden medios para, a la recepción de una solicitud de una sesión de servicio SIP procedente de una estación de usuario móvil (UE; 1), enviar una segunda información relativa a la identidad de la estación de usuario móvil al nodo de gestión de facturación y/o de políticas (CRF; PDF; PCCN; 30; 30A; 30B; 30C), sobre una segunda interfaz (Rx, Rx/Gq), y por que el nodo (CRF; PDF; PCCN; 30; 30A; 30B; 30C) de gestión de políticas y/o de facturación comprende medios de verificación (32, 32A) adaptados para determinar si la solicitud de un servicio de portador al nodo de soporte de datos en paquetes (10; 10B; 10C) y la solicitud de un servicio de sesión a la función de aplicación (AF; P/S/I-CSCF; 20; 20B; 20C) están originadas en una única estación de usuario móvil (UE; 1).

Description

Disposición, nodos y método en relación con acceso a servicios sobre un sistema de comunicación
Campo de la invención
La presente invención se refiere a una disposición en un sistema de comunicaciones que participa en procedimientos de acceso a, o solicitud de, servicios de estación de usuario y comprende una serie de nodos de soporte de datos en paquetes, una serie de nodos de gestión de facturación y/o de políticas y una serie de funciones de aplicación que administran la gestión de movilidad y el control de llamadas de estaciones de usuario móviles que solicitan servicios o acceden a los mismos. La invención se refiere asimismo a un nodo en un sistema de comunicaciones que soporta datos en paquetes, que está dispuesto para comunicar con una función de aplicación y un nodo de soporte de datos en paquetes.
La invención se refiere además a un método involucrado en la solicitud de/el acceso a servicios, en un sistema de comunicaciones que soporta comunicación de datos en paquetes y que comprende una serie de nodos de datos en paquetes, una serie de nodos de gestión de facturación y/o de políticas y una serie de funciones de aplicación que administran la gestión de movilidad y el control de llamadas de estaciones de usuario móviles que solicitan/acceden a servicios.
Estado de la técnica
Los denominados servicios IM (Internet IP Multimedia, multimedia IP por internet) son cada vez más atractivos y se utilizan ya ampliamente. Los subsistemas IMS (IP Multimedia Subsystems, subsistemas multimedia IP) 3GPP proporcionan una capacidad de control de sesión basada en IP que se basa en el protocolo SIP (Session based Initiation Protocol, protocolo de inicio basado en sesiones). IMS puede utilizarse por ejemplo para la prestación de servicios tales como pulsar para hablar, mensajería instantánea, presencia y conferencia. IMS en UMTS (Universal Mobile Telecommunication System, sistema universal de telecomunicaciones móviles) soportará aplicaciones multimedia IP tales como video, audio y conferencias multimedia. Tal como se ha mencionado anteriormente, 3GPP utilizará SIP, protocolo de inicio de sesiones, como el protocolo de señalización para crear y finalizar sesiones multimedia, véase por ejemplo el documento IETF RFC (Request For Comments) 3261, que trata sobre cómo se protege la señalización SIP entre el abonado y el IMS, cómo se autentica el abonado y cómo el abonado autentica el IMS.
La arquitectura de seguridad actual para IMS está especificada en 3GPP TS 33.203. Sin embargo, existe un problema en el hecho de que existirán implementaciones de los servicios mencionados anteriormente que no sean totalmente compatibles con IMS 3GPP. IMS 3GPP, por ejemplo, utiliza exclusivamente IPv6 (Internet Protocol version 6, protocolo de internet versión 6) aunque pueden seguir existiendo implementaciones IMS basadas en IPv4. Sin embargo, la utilización de IPv4 en lugar de IPv6 es solamente una de las diferencias entre las implementaciones IMS "precoces" y las implementaciones plenamente compatibles con IMS 3GPP. Se ha reconocido que la no compatibilidad con características de seguridad 3GPP TS 33.203 producirá principalmente problemas en el equipo de usuario (UE) debido a la ausencia potencial de soporte de la interfaz USIM/ISIM, en particular para estaciones de usuario compatibles solamente con 2G. Por lo tanto, se ha comprendido que para dichas implementaciones IMS "precoces", se requieren mecanismos de protección contra las amenazas de seguridad más significativas.
Una solución temporal de este tipo para las implementaciones IMS "precoces" se propone en 3GPP TR 33.878. El enfoque de este documento es que el GGSN (Gateway GPRS Support Node, nodo de soporte de pasarela GPRS) deberá enviar MSISDN y la dirección IP de una estación de usuario (UE equipo de usuario) hacia un servidor Radius sobre la interfaz Gi. El servidor Radius transfiere a continuación la MSISDN y la dirección IP al HSS (Home Subscriber Server, servidor propio de abonado). Cuando la estación de usuario, o el UE, envía una solicitud de registro SIP hacia una función de control de sesión/llamada de servicio (S-CSCF, Serving-Call/Session Control Function), que incluye la identidad privada IM (IP Multimedia, multimedia IP), la S-CSCF consultará al HSS el cual, basándose en la identidad IMS puede identificar la MSISDN y la dirección IP coincidentes del UE y devolver la dirección IP a la S-CSCF. La S-CSCF comprobará la dirección IP almacenada en la S-CSCF para ver si coincide con la dirección IP recibida desde el UE. Si las dos direcciones IP son iguales, la S-CSCF puede avanzar al procedimiento de registro, pero si no son iguales, presumiblemente debido a un ataque en curso, se finaliza la sesión. Esto proporciona la posibilidad de evitar ciertos ataques, tales como por ejemplo un atacante que utiliza identidades IMS de una víctima, lo que puede tener como consecuencia que el usuario atacado tenga que pagar el servicio al que ha accedido el atacante.
Un operador corre asimismo el riesgo de que el atacante no pague por el portador, por ejemplo un portador conversacional, debido al hecho de que, por ejemplo, está implementada FBC (Flow Based Charging, facturación basada en flujo) y la facturación al portador es cero. Esto significa que en algunos casos de utilización, un atacante podría utilizar ciertos servicios gratis.
El documento 3GPP TR 33.878 asume que durante una solicitud de contexto-PDP hacia el IMS, el GGSN deberá enviar un mensaje de "Radius Accounting-Request-Start" (iniciar solicitud de contabilización Radius) a un servidor Radius acoplado al HSS. Esto puede llevar a suponer que un operador utiliza un APN (Access Point Name, nombre
de punto de acceso) IMS específico o que el UE utiliza un contexto PDP de señalización. Sin embargo, se considera que la hipótesis relativa a la utilización de un APN IMS específico es demasiado restrictiva desde el punto de vista del diseño. El documento 3GPP TS 23.228 estipula que "cuando el UE utiliza acceso GPRS para servicios IMS, deberá ser capaz de establecer un contexto PDP de señalización dedicado para la señalización relacionada con el subsistema IM o utilizar un contexto PDP de propósito general para el tráfico de señalización del subsistema IM". Por lo tanto, no existe ninguna garantía de que el UE utilice un contexto PDP de señalización para IMS, lo que puede conducir a la conclusión de que el GGSN debería enviar entonces la dirección IP de un UE hacia un servidor Radius para todos los servicios. Además, un UE puede tener varias direcciones IP hacia un mismo GGSN y parece necesario que, en tal caso, el GGSN tenga que enviar todas estas direcciones IP hacia el servidor Radius. Además, en el caso general un UE puede estar acoplado a más de un GGSN o puede tener activada más de una conexión de red IP. Dichos escenarios no se discuten en el documento 3GPP TR 33.878.
Además, la solución descrita en este documento sugiere la introducción de un denominado "temporizador de reposo" en GGSN. Esto tiene un impacto sobre cómo son asignadas o liberadas las direcciones IP hacia un UE, y cómo una dirección IP puede ser reutilizada para un usuario cuando se produce el restablecimiento de un contexto PDP en una etapa posterior. Aparentemente, la razón para la introducción del temporizador de reposo es reducir la carga sobre la HSS y, cuando no existe contexto PDP disponible entre el GGSN y el UE, el GGSN almacena o reserva la dirección IP asignada para un UE específico durante un tiempo que es igual al periodo del tiempo establecido en el temporizador de reposo. Esto significa que el GGSN, tras la terminación de todos los portadores, no envía una detención de solicitud de contabilización hasta que ha expirado el temporizador de reposo. Por lo tanto, el temporizador de reposo no se ha introducido por razones de seguridad si no para reducir la comunicación hacia el HSS que es responsable de la creación de los vectores de autenticación, y por lo tanto la intención es reducir la comunicación con el HSS, o para no permitir más comunicación con el HSS que la necesaria a efectos de evitar que resulte sobrecargado, lo cual puede tener la consecuencia de que se verían perjudicados otros servicios, por ejemplo voz. La utilización del temporizador de reposo es inconveniente, por ejemplo, debido a que existirá un mayor riesgo de conflictos entre direcciones IP asignadas dinámicamente. Además, se mantienen más recursos de los necesarios.
La solución propuesta es asimismo inconveniente porque se envía cada vez más información desde el GGSN sobre la interfaz Gi, la cual está cada vez más sobrecargada. Es asimismo una desventaja que se requiera un servidor Radius para verificar las direcciones IP y, tal como se ha mencionado anteriormente, no se tengan en cuenta diseños generales tales como cuando, por ejemplo, un UE está acoplado a más de un GGSN y/o ha activado más de una conexión de red IP, etc.
El documento WO 191446 da a conocer un método para unificar facturación basada en servicios y facturación basada en recursos, mediante la utilización del identificador común.
Compendio de la invención
Por lo tanto, tal como se ha mencionado inicialmente, es necesaria una disposición mediante la cual pueda proporcionarse seguridad IMS de manera directa y sencilla. En particular, se necesita una disposición mediante la cual pueda proporcionarse la denominada seguridad IMS "precoz", es decir, en redes que aún no son "completamente" compatibles con la Versión 5 del 3GPP TS 33.203. En particular, se requiere una disposición mediante la cual puedan detectarse e impedirse ataques y, en particular, mediante la cual pueda aumentarse la seguridad para usuarios finales así como para operadores, por ejemplo, de tal modo que se impida que un atacante utilice estos servicios gratis o haciendo que los pague otra persona, y que un ataque pueda detectarse lo antes posible, lo cual es extremadamente importante para el usuario final así como para el operador.
En particular, se necesita una disposición que sea flexible y que pueda adaptarse a diferentes entornos de red, tal como por ejemplo los denominados entornos de red consciente ("aware network"). Además, se requiere una disposición que tenga en cuenta y aproveche el desarrollo dentro de sistemas, por ejemplo, 3GPP o similares. Asimismo, se requiere una disposición mediante la cual la cantidad de información enviada sobre una denominada interfaz Gi desde nodos de soporte pasarela GPRS o similares pueda reducirse en lugar de aumentarse. Más específicamente, se requiere una disposición mediante la cual no se requiera la introducción de nodos adicionales y, más en general, mediante la cual el número de nodos implicados y afectados pueda mantenerse lo más bajo posible. Se requiere asimismo una disposición que reduzca o incluso elimine los inconvenientes e impactos sobre la asignación o liberación de direcciones IP hacia un UE, que surgen mediante la introducción de un denominado temporizador de reposo en un GGSN.
Se requiere asimismo una disposición que pueda utilizarse en un diseño general y que tenga en cuenta situaciones, tales como por ejemplo cuando un equipo de usuario está acoplado a más de un GGSN (o CGSNs en otras pasarelas) y/o cuando un equipo de usuario ha activado más de una conexión de red IP. Adicionalmente, se requiere un nodo que ayude a la consecución de uno o varios de los objetivos mencionados anteriormente. Se requiere asimismo un método mediante el cual puedan conseguirse uno o varios de los objetivos mencionados anteriormente.
Por lo tanto, tal como se ha mencionado inicialmente, se da a conocer una disposición en la que uno o varios nodos de soporte de datos en paquetes comprenden medios adaptados para enviar una primera información relativa a la identidad de estación de usuario móvil sobre una primera interfaz (Gx, Gy; Gx/Gy) a un nodo de gestión de
facturación y/o de políticas, a la recepción de una solicitud para servicios de portador desde una estación de usuario móvil, la función o funciones de aplicación comprenden medios para, a la recepción de una solicitud para una sesión de servicio (SIP) desde una estación de usuario móvil (UE), enviar una segunda información relativa a la identidad de estación de usuario móvil al nodo de gestión de facturación y/o de políticas, sobre una segunda interfaz (Rx, Rx/Gq), y en la que el nodo de gestión de políticas y/o facturación comprende medios de verificación adaptados para determinar si la solicitud para un servicio de portador al nodo de soporte de datos en paquetes y la solicitud para una sesión de servicio a la función de aplicación (AF; P/S/I-CSCF) están originadas en una única estación de usuario móvil (UE). En particular, la primera información relativa a la identidad de la estación de usuario móvil comprende uno o varios de la MSISDN, la IMSI y dirección IP de la estación de usuario móvil, y la segunda información relativa a la identidad de la estación de usuario móvil comprende la identidad privada IMS (IMPI) y/o la identidad pública IMS (IMPU), o la IMSI y/o la MSISDN, por ejemplo obtenidas de una identidad privada o pública IMS (IMPI, IMPU), o estando adaptada cada función de aplicación para obtener dicha información externamente, por ejemplo de un HSS.
En particular, las direcciones IP se reciben en, o se obtienen a partir de, la primera información relativa a la estación de usuario móvil y la segunda información relativa a la identidad de la estación de usuario móvil, y los medios de verificación están adaptados para comparar la dirección IP obtenida de la función de aplicación (AF) con la dirección IP obtenida del nodo de soporte de datos en paquetes. En una realización, los medios de verificación están adaptados para, si se requiere, establecer y, utilizando la IMSI y/o la MSISDN de dichas primera y segunda informaciones relativas a la identidad de las estaciones de usuario móviles respectivamente, comparar las direcciones IP asociadas. El nodo de gestión de facturación y/o de políticas puede estar adaptado asimismo para deducir la IMSI y/o la MSISDN a partir de una identidad de usuario privada y/o pública IMS (IMPI/IMPU).
En una realización ventajosa, el nodo de gestión de facturación y/o de políticas está adaptado para construir una identidad de usuario privada utilizando la IMSI de una estación de usuario móvil, por ejemplo, cuando no está implementada ninguna aplicación ISIM, y además está adaptado particularmente para identificar e instalar normas de facturación a aplicar a la recepción de una solicitud de las mismas desde un nodo de soporte de datos en paquetes.
Según la invención, si la primera y la segunda informaciones relativas a la identidad están originadas en una única estación de usuario móvil, el nodo de gestión de facturación y/o de políticas se adapta en particular para implementar las normas de facturación proporcionadas. Por otra parte, si la primera y la segunda informaciones relativas a la identidad no están originadas en una única estación de usuario móvil, el nodo de gestión de facturación y/o de políticas puede adaptarse para rechazar las normas de facturación y/o desactivar normas de facturación implementadas y desechar el tráfico de flujo de IP relacionado, y además para informar a la función de aplicación (AF) de que no está disponible un contexto PDP.
Alternativamente, si la primera y la segunda informaciones relativas a la identidad no están originadas en una única estación de usuario móvil, el nodo de gestión de facturación y/o de políticas puede ser adaptado para seleccionar si desactiva las normas de facturación en el nodo de soporte de datos en paquetes, o las mantiene activas (o las activa). En una realización particular, el nodo de soporte de datos en paquetes comprende un nodo que gestiona funciones para el plano del tráfico (TPF, Traffic Plane Functions), por ejemplo un GGSN que implementa TPF o un CGSN que implementa TPF. Alternativamente, puede comprender un nodo independiente o un nodo de pasarela que gestione TPF, o TPF y ejecución de políticas (PEP).
De acuerdo con diferentes realizaciones, el nodo de gestión de facturación y/o de políticas comprende una CRF, una PDF o un PCCN. En particular, la primera interfaz es Gx o Go/Gx fusionada con Gy si el nodo de gestión de facturación y/o de políticas está fusionado con un OCS, y la segunda interfaz comprende Rx o Rx fusionada con Gq.
Se da a conocer asimismo un nodo (funcional, lógico o físico) en un sistema de comunicación, tal como se ha mencionado inicialmente, que está adaptado para recibir la primera información relativa a la identidad de la estación de usuario móvil desde un nodo de soporte de datos en paquetes, en relación con una solicitud de servicio de portador para una estación de usuario móvil, o a la recepción de una solicitud para un servicio de portador procedente de una estación de usuario móvil (UE) en el nodo de soporte de datos en paquetes, para recibir la segunda información relativa a la identidad de la estación de usuario móvil desde una función de aplicación en relación con una sesión de servicio o a la recepción de una solicitud de una sesión de servicio en el mismo, y comprende medios de verificación para determinar si la solicitud para un servicio de portador (al nodo de soporte de datos en paquetes) y la solicitud para una sesión de servicio (a la función de aplicación) están originadas en la misma estación de usuario móvil. En particular, la primera información relativa a la identidad de la estación de usuario móvil comprende uno o varios de la MSISDN, la IMSI y la dirección IP de la estación de usuario móvil. En mayor detalle, la segunda información relativa a la identidad de la estación de usuario móvil comprende la identidad privada IMS (IMPI) y/o la identidad pública IMS (IMPU) de la estación de usuario móvil o la IMSI, y/o el nodo de gestión está adaptado para obtener la IMSI y/o la MSISDN a partir de la IMPI y/o la IMPU, y/o está adaptado para solicitar dichas IMSI y/o MSISDN a la función de aplicación.
Preferentemente, los medios de verificación están adaptados para comparar la dirección IP correspondiente a, o incluida en la primera información relativa a la identidad de la estación de usuario móvil, y la dirección IP correspondiente a, o incluida en la segunda información relativa a la identidad de la estación de usuario móvil, y en
particular, si se requiere establecer y utilizar la IMSI y/o la MSISDN de dichas primera y segunda informaciones relativas a la identidad de las estaciones de usuario móviles, para comparar las direcciones IP asociadas. Alternativamente, éstos están adaptados para derivar la IMSI y/o la MSISDN a partir de una identidad de usuario pública y/o privada IMS (IMPI/IMPU) recibida. En particular, el nodo de gestión de facturación y/o de políticas está adaptado para construir una identidad de usuario privada utilizando la IMSI de una estación de usuario móvil, por ejemplo cuando no está implementada ninguna aplicación IMSI.
Éste puede estar adaptado asimismo para identificar e instalar normas de facturación a aplicar a la recepción de una solicitud de las mismas desde un nodo de soporte de datos en paquetes. En particular, está adaptado para identificar e instalar normas de facturación a aplicar a la recepción de una solicitud de las mismas desde un nodo de soporte de datos en paquetes, y si la primera y la segunda informaciones relativas a la identidad están originadas en una única estación de usuario móvil, para implementar las normas de facturación proporcionadas, y si la información relativa a la identidad del primer y el segundo usuario no están originadas en una única estación de usuario móvil, para rechazar las normas de facturación y/o desactivar las normas de facturación implementadas y desechar el tráfico de flujo de IP relacionado, para informar a la función de aplicación (AF) de que no está disponible un contexto PDP, o para seleccionar si desactiva las normas de facturación en el nodo de soporte de datos en paquetes, o las mantiene activas, si ya lo estaban. En particular, éste comprende una CRF, una PDF o un PCCN o un nodo con una funcionalidad similar.
Además, se da a conocer un método, tal como se ha mencionado inicialmente, que comprende las etapas de recibir una solicitud de servicios de portador desde una estación de usuario móvil en un nodo de soporte de datos en paquetes; enviar, desde el nodo de soporte de datos en paquetes, la primera información relativa a la identidad de estación de usuario móvil, de la estación de usuario móvil, a un nodo de gestión de facturación y/o de políticas; recibir a continuación, antes o sustancialmente al mismo tiempo, una solicitud de una sesión de servicio procedente de la estación de usuario móvil en una función de aplicación; enviar, desde la función de aplicación, la segunda información relativa a la identidad de la estación de usuario móvil al nodo de gestión de facturación y/o de políticas; y establecer, en el nodo de gestión de facturación y/o de políticas, si la solicitud para un servicio de portador al nodo de soporte de datos en paquetes y la solicitud para un servicio de sesión a la función de aplicación están originadas en una única estación de usuario móvil.
Tal como se ha mencionado anteriormente, en particular la primera información relativa a la identidad de la estación de usuario móvil comprende una o varias de la MSISDN, la IMSI y la dirección IP de la estación de usuario móvil, y la segunda información relativa a la identidad de la estación de usuario móvil comprende la identidad privada IMS (IMPI) y/o la identidad pública IMS (IMPU), o la segunda información relativa a la identidad de usuario comprende la IMSI y/o la MSISDN, por ejemplo obtenidas a partir de la identidad privada o pública IMS (IMPI, IMPU), o la función de aplicación está adaptada para extraer dicha información de un HSS. En particular, el método comprende además las etapas de: establecer o encontrar la IMSI y/o la MSISDN de dichas primera y segunda informaciones relativas a la identidad de las estaciones de usuario móviles, comparar por lo menos parte de dichas primera y segunda informaciones relativas a la identidad de las estaciones de usuario móviles entre sí, y más específicamente comparar las direcciones IP de dichas primera y segunda informaciones relativas a la identidad de las estaciones de usuario móviles y/u obtener la IMSI y/o la MSISDN a partir de las identidades de usuario pública y/o privada IMS (IMPI/IMPU) recibidas, y/o construir, en el nodo de gestión de facturación y/o de políticas, una identidad de usuario privada utilizando la IMSI de la estación de usuario móvil, por ejemplo cuando no está implementada ninguna aplicación ISIM.
Ventajosamente, comprende asimismo la etapa de: identificar e instalar normas de facturación y/o de políticas aplicables, a la recepción de una solicitud procedente de un nodo de soporte de datos en paquetes. De manera más concreta, el método comprende además las etapas de: si la primera y la segunda informaciones relativas a la identidad de las estaciones de usuario móviles están originadas en una única estación de usuario móvil, implementar las normas de facturación y/o las normas de políticas proporcionadas, en el nodo de gestión de facturación y/o de políticas, de lo contrario, desechar el tráfico de flujo de IP relacionado; o seleccionar si mantener activas o desactivar las normas de facturación. En implementaciones preferidas, el nodo de soporte de datos en paquetes comprende un nodo que gestiona funciones en el plano de tráfico, y es un nodo independiente, o un GGSN o un CGSN o un nodo pasarela que gestiona la TPF y la ejecución de políticas (PEP), y el nodo de gestión de facturación y/o de políticas comprende una CRF, una PDF o un PCCN, o un nodo con una funcionalidad similar.
Breve descripción de los dibujos
A continuación se describirá en mayor medida la invención, de manera no limitativa, y haciendo referencia a los dibujos adjuntos, en los cuales:
la figura 1 muestra una solución del "estado de la técnica",
la figura 2 es un diagrama de bloques esquemático que muestra una disposición según la presente invención,
la figura 3 es un diagrama secuencial simplificado que muestra la disposición de la primera información relativa a la identidad de estación de usuario móvil a un nodo de gestión de facturación y/o de
políticas,
la figura 4 es un diagrama secuencial simplificado que incluye el procedimiento en el que se proporciona la
segunda información relativa a la identidad de estación de usuario móvil al nodo de gestión de
facturación y/o de políticas,
la figura 5 es un diagrama secuencial que muestra un procedimiento a modo de ejemplo, de la prestación de
la segunda información relativa a la identidad de estación de usuario móvil y la verificación de la
misma,
la figura 6A es un diagrama secuencial que describe una implementación a modo de ejemplo, y en el que el resultado de la verificación es positivo,
la figura 6B es un diagrama secuencial que describe la primera implementación a modo de ejemplo de la figura 6A, pero en el que el resultado de la verificación es negativo,
la figura 7 es un diagrama de bloques esquemático que muestra el concepto inventivo implementado en un diseño general,
la figura 8A muestra otro diseño general en el que puede ser implementado el concepto inventivo,
la figura 8B muestra otro diseño en el que puede ser implementado el concepto inventivo, y
la figura 9 es un diagrama de flujo que describe el procedimiento acorde con una realización de la presente invención.
Descripción detallada de la invención
La figura 1 muestra la solución del estado actual de la técnica, descrita anteriormente, en la aplicación para proporcionar seguridad para accesos IMS, en particular para implementaciones precoces de IMS no compatibles aún con los requisitos de 3GPP TS 33.203. Dicha solución se describe entre otras en el documento 3GPP TR
33.878. Se supone que un UE 10 solicita un portador al GGSN 100. Se establecen los contextos PDP de manera convencional, dependiendo principal o secundariamente de cuál sea el procedimiento relevante. El equipo de usuario UE 10 puede tener varias direcciones IP, una dirección IP por cada conexión de red IP. El GGSN comprende un temporizador de reposo 110 mediante cuya utilización puede reutilizarse una dirección IP para un usuario cuando se reestablece un contexto PDP en una etapa posterior. No existe APN (nombre de punto de acceso) de IMS específico y el GGSN no puede asumir la utilización de un contexto PDP de señalización. Conociendo de la manera convencional la MSISDN y la dirección IP del UE 10, el GGSN 100 envía la MSISDN y la dirección IP sobre la interfaz Gi hacia el servidor Radius 300, es decir se envían todas las direcciones IP y MSISDN del UE. El temporizador de reposo utilizado en el GGSN 100 está destinado aparentemente, principalmente a reducir la carga sobre el HSS. Se propone que esté trabajando del orden de horas, de manera que cuando no existe un contexto PDP disponible entre el GGSN y UE, el GGSN almacena o reserva la dirección IP asignada para un UE específico durante un período de tiempo que corresponde al tiempo establecido en el temporizador de reposo. Esto significa que el GGSN, tras la terminación de todos los portadores, no envía ninguna detención de solicitud de contabilización hasta que haya terminado realmente el temporizador de reposo. Este temporizador de reposo influye sobre cómo son asignadas o liberadas las direcciones IP hacia el UE.
El servidor Radius 300 transmite la información, es decir la MSISDN y la dirección IP, al HSS 400. Todas las direcciones IP del UE y la MSISDN se envían según el temporizador de reposo 110 en el GGSN 100, es decir, generalmente el envío se ralentizará, o retardará, hasta que expire el temporizador de reposo.
A continuación, se envía una solicitud de un registro SIP (SIP REGISTER) desde el UE 10 a la S-CSCF, y la S-CSCF envía la identidad IMS sobre el HSS 400. El HSS 400 devuelve una respuesta a la S-CSCF con la dirección IP registrada de vuelta a la S-CSCF 200. La S-CSCF 200 comprende un medio de verificación 210 o una funcionalidad para llevar a cabo una verificación mediante verificar que la dirección IP procedente del HSS 400 es la misma que la dirección IP almacenada en la S-CSCF. Si no son iguales, la sesión se finaliza debido a que se asume que se está produciendo un ataque.
Los inconvenientes de dicha solución se han descrito anteriormente en la solicitud.
La figura 2 muestra una disposición acorde con una implementación del concepto inventivo según el cual se utiliza un diseño FBC (facturación basada en flujo). El problema que se resuelve mediante la disposición consiste en la provisión de un mecanismo que asegura que la red está capacitada para verificar que la dirección IP de un equipo de usuario UE 1 y la identidad IMS del UE 1 en el servidor SIP corresponden al mismo usuario al nivel de portador. De acuerdo con la invención, los nodos involucrados o funciones son el GGSN 10 que gestiona la función para el plano de tráfico TPF, (según el concepto inventivo, ésta es la función para el plano de tráfico que se utiliza, y puede obtenerse como un nodo independiente, dispuesto en un GGSN o en un CGSN o en cualquier nodo que incluya por lo menos la funcionalidad TPF), un nodo 30 de gestión de facturación y/o de políticas que en esta realización está
implementada como una CRF (Charging Rules Functionality, funcionalidad de normas de facturación) y una función de aplicación AF 20 que puede estar implementada como una S-CSCF, una P-CSCF o similar, y el equipo de usuario UE 1 relacionado. La CRF 30 comprende medios de almacenamiento, por ejemplo, una tabla para almacenar la primera información relativa a la identidad del equipo de usuario tal como se explica a continuación, y medios de verificación 32 para verificar si por lo menos una parte dada de una primera información relativa a la identidad del UE corresponde a la segunda información relativa a la identidad del UE, por ejemplo, mediante comparar por lo menos partes de dichas primera y segunda informaciones relativas a la identidad, respectivamente. "Por lo menos parte de" significa que puede no ser necesario comparar toda la información en función de las implementaciones, tal como se describirá asimismo a continuación. Sin embargo, en la figura 2 se supone que el UE 1 envía una solicitud para un establecimiento de servicios de portador (I) a la TPF 10, que puede estar implementada en un GGSN. A continuación la TPF 10, por ejemplo una implementación basada en CRF, tal como en la figura 2, solicita normas de facturación (II) CRF 30. La primera información relativa a la identidad del UE acompaña la solicitud. La primera información relativa a la identidad del UE puede ser proporcionada por el UE o por la TPF 10 (por ejemplo, si se refiere a una solicitud de contexto PDP secundaria). Cómo se realice o consiga esto, no tiene importancia para el funcionamiento de la presente invención, siendo la cuestión principal que la primera información relativa a la identidad del UE esté disponible en la TPF 10. La primera información relativa a la identidad del UE que acompaña las normas solicitud de normas de facturación se almacena a continuación en la tabla 31 de la CRF 30, utilizando la CRF 30 entre otras la primera información relativa a la identidad del UE y posiblemente otra información, por ejemplo información de QoS acerca de la función de aplicación, etc., identifica cuáles son las normas de facturación pertinentes a instalar, y a continuación proporciona las normas de facturación a la TPF 10 (III). La TPF 10 lleva a cabo las acciones de las normas de facturación pertinentes o proporciona la implementación de las normas de facturación suministradas, y envía un mensaje de aceptación en relación con el establecimiento de la solicitud de servicio del portador (IV) al UE 1.
Una vez que se ha establecido un portador, el UE 1 envía una solicitud para una sesión de servicio utilizando SIP,
(V) a la AF 20. En los sistemas GPRS, y desde el punto de vista de una FBC, la CFCS intermediaria y/o una CFCS de servicio y/o una CSCF de interrogación pueden, en función de la configuración del operador, actuar como una AF que maneja la interfaz Rx y/o la interfaz Gq. En la solicitud que utiliza el protocolo SIP, está incluida la segunda información relativa a la identidad de usuario, de la solicitud. La AF 20 envía a continuación información de facturación del flujo de la aplicación/del servicio, que incluye la segunda información relativa a la identidad del UE, a la CRF 30 (VI). Por ejemplo, si una S-CSCF actúa como una AF, puede, antes de proceder a una sesión de registro, transferir de manera no solicitada la identidad de usuario privada junto con la dirección IP del UE sobre Rx, hacia la CRF 30. En la activación del contexto PDP, la FBC asume que la dirección IP del UE y la IMSI (o MSISDN) se envían hacia la CRF 30 sobre la interfaz Gx. Basándose en las hipótesis anteriores, la CRF 30 está entonces en conocimiento de las IMSI procedentes tanto de la AF 20, en particular de la S-CSCF, como de la TPF 10, en particular del GGSN, y de las direcciones IP correspondientes y por lo tanto está capacitada, en el medio de verificación 32, para comprobar si las direcciones IP coinciden con, o están originadas en un único usuario (en la figura 1, de hecho ambas están originadas en el mismo UE, a saber el UE 1). Si no se corresponden, o no están originadas en un único usuario final, es decir, si no existe coincidencia entre las direcciones IP, la CRF 30 (en este caso, debería estar claro que para la gestión de políticas el nodo podría ser una PDF, pero puede ser asimismo un PCCN para gestionar políticas y/o facturación) notifica a la AF 20, en particular a la S-CSCF, a efectos de proporcionar una terminación de la sesión SIP, y la CRF 30 debería desactivar cualesquiera norma o normas correspondientes en la TPF 10.
Por supuesto, debería asimismo ser opcional si la sesión debe o no finalizarse, y opcionalmente esto puede ser controlado por el operador, de manera que bajo ciertas circunstancias, por ejemplo, un operador puede desear localizar o realizar el seguimiento del atacante y, por lo tanto, permitiría que continúe la sesión. También por otras razones, un operador puede permitir la sesión bajo ciertas condiciones, etc. La invención no se limita a la adopción de ningunas medidas particulares, sino que es fundamental que se proporcione una vigilancia en relación con la correspondencia entre direcciones y posibles ataques o similares.
La segunda información relativa a la identidad de usuario enviada desde la AF 20 a la CRF 30 puede contener, por ejemplo, la IMPI (identidad privada IMS), la IMPU (identidad pública IMS) y la dirección IP. Alternativamente, la AF 20 puede enviar la IMSI o la MSISDN directamente. Esto puede obtenerse a partir de la identidad privada o bien alternativamente a partir de la AF, por ejemplo, la S-CSCF puede contactar con el HSS para identificar la IMSI con la MSISDN.
Por ejemplo, si el UE no contiene un ISIM (pero sí, por ejemplo, un USIM) la IMPI se puede obtener y la identidad de usuario privada debería adoptar la forma de un NAI y deberá tener la forma de username@realm, tal como se especifica en IETF RFC 2486, cláusula 3.
Puede contenerse una representación de la IMSI dentro del NAI, para la identidad privada.
Si no existe una aplicación ISIM, la identidad de usuario privada no se conoce y puede entonces obtenerse de la IMSI. La identidad de usuario privada puede considerarse exterior a la IMSI mediante utilizar las cadenas completas de dígitos como parte del nombre de usuario de la identidad de usuario privada, y mediante transformar los dígitos principales de la IMSI, es decir MNC y MCC, en un nombre de dominio.
El resultado será una identidad de usuario privada, de la forma:
"<IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org". Por ejemplo: si la IMSI es 234150999999999 (MCC=234, MNC=15), la identidad de usuario privada adoptará la forma 234150999999999@ims.mnc015.mcc234.3gppnetwork.org.
Por lo tanto, la CRF/PDF (PCCN) está capacitada, en base a la recepción de la IMPI, es decir, la identidad privada IMS, o incluso de la IMPU, la identidad de usuario pública, y de la dirección IP procedente de una AF, por ejemplo una CSCF tal como P-CSCF, S-CSCF, o I-CSCF, sobre Rx o Gq o Rx fusionadas con Gq, para obtener la IMSI (o la MSISDN) del UE. Debe observarse que una AF puede, alternativamente, enviar la MSISDN y/o la IMSI directamente sobre Rx/Gq, tal como se ha indicado anteriormente.
Además, dado que la TPF, en este caso la TPF implementada en un GGSN, deberá tener la capacidad de enviar la IMSI o la MSISDN a la CRF/PDF/PPCN (sobre Gx o Gx/Gy si están fusionadas), la CRF/PDF puede comparar las IMSI (o las MSISDN) procedentes de la CRF y de la TPF (en este caso, el GGSN) con las direcciones IP respectivas, es decir, la CRF 30 es capaz de encontrar la IMSI (MSISDN), en este caso, a partir del GGSN y la AF y comprueba si se trata de la misma dirección IP asociada. Si existe una coincidencia, la CRF implementa preferentemente, en este caso, normas de facturación tal como se especifica en el documento 3GPP TS 23.125. Por otra parte, si la dirección IP no está originada en un único UE, la CRF puede decir no implementar las normas de facturación, o desactivar normas de facturación ya implementadas, tal como se ha mencionado anteriormente, y por lo tanto puede desecharse el tráfico para el flujo IP afectado. La CRF informa a continuación a la AF, por ejemplo una P-CSCF/S-CSCF, de que no existe un contexto PDP disponible.
Alternativamente, en ciertas situaciones, mencionadas asimismo anteriormente, un operador puede desear permitir el tráfico, por ejemplo para rastrear a un atacante. Por lo tanto, puede existir una opción para que el nodo de gestión de facturación y/o de políticas 30 mantenga las normas en la TPF 10 activas, o para desactivarlas.
En algunas implementaciones, la TPF está implementada en un GGSN (o CGSN), pero, tal como se ha mencionado anteriormente, la TPF puede estar implementada en un nodo independiente o función, o asignada a cualquier otro elemento diferente a un GGSN/CGSN, siendo la cuestión principal que la función para el plano del tráfico TPF es la que está involucrada, de acuerdo con el concepto inventivo, dado que es la TPF la que hace funcionar la Gx hacía la CRF/PDF (o el PCCN) (o Gx/Gy cuando están fusionadas).
La invención funciona para identidades de usuario públicas de manera similar a como lo hace para identidades de usuario privadas. El documento GPP TS 23.003 especifica que cuando no se utiliza ISIM, la identidad de usuario pública temporal debería adoptar la forma de "user@domain", y por lo tanto debería ser igual a la identidad de usuario privada. Por lo tanto, es posible utilizar una identidad de usuario pública en lugar de la identidad privada en la capa SIP. Entonces la AF, por ejemplo la S-CSCF, puede solicitar, por ejemplo, una IMSI al HSS en base a la identidad de usuario pública, obtener la IMSI a partir de la identidad de usuario pública o enviar la identidad de usuario pública hacia la CRF/PDF/PCCN que obtiene la IMSI, o enviar una solicitud a un repositorio de perfiles de suscripción, si está implementado, ver la figura 5, para obtener la IMSI o la MSISDN.
La figura 3 es un diagrama secuencial esquemático que muestra la mensajería entre un UE, una TPF y, en este caso, una CRF. Debería estar claro que, tal como se ha mencionado anteriormente, la TPF puede disponerse como un nodo independiente, en un GGSN, en un CGSN o en cualquier otro nodo o medio de funcionamiento que proporcione por lo menos la funcionalidad TPF. Debería estar claro asimismo que, en lugar de que una CRF gestione normas de facturación, podría ser asimismo una PDF que gestione normas de políticas o un nodo combinado o funcionalidad que gestione, por ejemplo, políticas y facturación. Por lo tanto, se supone que el UE, de manera convencional, envía una solicitud para establecimiento de un servicio de portador, 1, por ejemplo, a un GGSN que proporciona la funcionalidad TPF. En una activación de contexto PDP, primera o principal, el GGSN, en este caso, enviará identidades de terminal, tales como una o varias de las dirección IP, la MSISDN y la IMSI hacia la CRF sobre la interfaz Gx en una solicitud de normas de facturación, 2, es decir, la primera información relativa a la identidad de equipo de usuario acompaña la solicitud de normas de facturación. La CRF almacena la primera información relativa a la identidad del UE recibida, 3, e identifica cuáles son las normas de facturación que son aplicables y deberían ser instaladas, 4. A continuación, se proporcionan las normas de facturación a la TPF, 5. La TPF, a la recepción de las normas de facturación, lleva a cabo la acción o acciones de las normas de facturación, 6, y envía al UE un mensaje de aceptación del establecimiento del servicio de portador, 7.
Debería resultar evidente que, tal como se mencionó anteriormente, la CRF puede estar fusionada con una PDF. De manera más específica, la CRF (y/o la PDF o el PCCN) puede estar fusionada con un sistema de facturación en línea OCS, en cuyo caso la Gx puede estar fusionada con la Gy. Estas interfaces están definidas en el documento TS 23.125, y, por ejemplo, en una realización pueden basarse ambas en control de crédito Diameter (Diameter Credit Control).
La figura 4 es un diagrama secuencial esquemático que muestra el procedimiento mediante el cual se proporciona a la CRF (por ejemplo) la segunda información relativa a la identidad del UE, de manera que puede llevarse a cabo una verificación según el concepto inventivo.
En este caso, se supone que cuando el UE envía una solicitud para una sesión de servicio utilizando el protocolo SIP, 8, a la AF que puede comprender, por ejemplo, una P-CSCF o una S-CSCF o una I-CSCF actuando como una AF, aquella incluye enviar identidades de usuario a la CRF sobre la Rx, lo que se describe el documento 3GPP TS 23.228, que se incorpora al presente documento como referencia. En otras palabras, el UE establece un registro SIP hacia la red IMS. Por lo tanto, cuando se envía una solicitud de sesión de servicio, registro SIP, 8, a la AF, la AF proporciona a la CRF información de facturación del flujo de datos de aplicación/servicio que incluye la segunda información relativa a la identidad del UE, por ejemplo, la IMPI, la IMPU, la dirección IP, 9. La CRF, habiendo almacenado la primera información relativa a la identidad del UE en un medio de almacenamiento, extrae dicha primera información relativa a la identidad del UE y la compara con la segunda información relativa a la identidad del UE recibida de la AF, 10. En este caso, se supone que la primera y la segunda informaciones relativas a la identidad del UE se originan respectivamente en un único UE, y por lo tanto se envía un acuse de recibo, 11, a la AF y el servicio se establece implementando las normas de facturación pertinentes, o similares.
Debería estar claro que la interfaz Rx puede estar fusionada con Gq, y la AF puede funcionar por lo tanto sobre Rx/Gq. En realizaciones particulares, Rx y Gq pueden estar ambas basadas en Diameter Nasreq.
Debería resultar evidente que, como una alternativa para enviar la IMPI y la IMPU, es decir, la identidad privada y la pública del IMS, respectivamente, tal como se describe en los documentos TS 23.228 y TS 23.003, la AF, o cualquier CSCF, pueden enviar la IMSI o la MSISDN directamente a la CRF. La IMSI o la MSISDN se pueden obtener a partir de la identidad privada, o puede ser necesaria una comunicación con el HSS para la identificación de la IMSI o la MSISDN. Esto se ha descrito anteriormente haciendo referencia a la figura 2.
La CRF comprende particularmente una tabla de traducción entre la IMPI y la IMSI.
La figura 5 es un diagrama secuencial que muestra el procedimiento en el que se proporciona la segunda información relativa a la identidad del UE, por ejemplo, a una CRF o a un PCCN, etc., donde, en este caso, se realiza una verificación satisfactoria. En este caso, se supone que se establece un contexto PDP, y que la primera información relativa a la identidad del UE está disponible en la CRF, el PCCN, etc. Se supone que el UE está en una red visitada y envía un registro SIP, 80, con la ID de usuario pública, la ID de usuario privada y la dirección IP del UE a la P-CSCF. El registro SIP se envía desde la P-CSCF a la I-CSCF de la red propia del UE, 81. La I-CSCF envía un mensaje Cx-Query/Cx-Select-Pull Diameter (en esta realización particular), 82, al HSS, que devuelve la respuesta correspondiente, 83, relativa a identidades IMS. A continuación, el registro SIP con la ID de usuario pública, la ID de usuario privada, la dirección IP del UE, se envía desde la I-CSCF a la S-CSCF, 84. En esta realización específica, se supone que la S-CSCF actúa como una AF. En realizaciones alternativas, una P-CSCF o una I-CSCF pueden actuar como una AF. Deberá estar claro que en este caso, la TPF y el repositorio de información de suscripciones no son visibles.
Las etapas 85, 86 se refieren a la disposición de parámetros de seguridad, dirección IP de aplicación, etc., lo cual, no obstante, no tiene relevancia para el concepto inventivo.
A continuación, se supone que la segunda información relativa a la identidad del UE, la ID de usuario pública, la ID de usuario privada, y la dirección IP del UE se proporcionan a la CRF (PCCN, etc.), 87, y después de la verificación (que, en este caso, se supone afirmativa) con la primera información relativa a la identidad del UE (que no se muestra en este caso), se envía un acuse de recibo a la S-CSCF, 88. La S-CSCF envía un mensaje de verificación positivo 2XX OK a la I-CSCF, 89, la cual lo transfiere a la P-CSCF, 90, la cual a su vez lo transfiere al UE, 91.
La figura 6A muestra un ejemplo de la implementación en la que se supone que la primera y la segunda informaciones relativas a la identidad del UE pueden ser verificadas positivamente (es decir, existe correspondencia) y en la que se utiliza el protocolo Diameter.
Por lo tanto, el primer UE envía (en este caso) una solicitud de activar contexto PDP (en este caso) a un SGSN, 11. De la manera convencional, el SGSN envía una solicitud de crear contexto PDP al GGSN, 21, que en este caso utiliza un cliente Radius para obtener direcciones IP de UEs.
En esta realización, se supone que se utiliza el protocolo Diameter (ver el documento 3GPP TS 29.210), y el GGSN envía una solicitud de normas, en este caso una Diameter CCR (Credit Control Request, solicitud de control de crédito) con IMSI, MSISDN, dirección IP, sobre Gx a la CRF (o al PCCN, etc.), 31. La CRF responde con una Diameter CCA (Credit Control Answer, respuesta de control de crédito) con normas de facturación sobre la Gx, 41, al GGSN, el cual envía una respuesta de crear contexto PDP al SGSN, 51. El SGSN envía aceptar activar contexto PDP al UE 61, con la dirección PDP (dirección IP) asignada. Tal como se ha descrito anteriormente, se supone que el UE envía un registro SIP al GGSN, 71, el cual comprueba si hay suplantación de dirección IP (es decir, comprueba que el UE no ha cambiado la dirección IP que se le ha proporcionado, es decir, que no utiliza otra diferente). Cuando se comprueba que el UE utiliza la dirección IP "correcta", se envía un registro SIP a la P-CSCF, 81, que lo envía a la I-CSCF, 91. A continuación, la I-CSCF envía el registro SIP a la C-CSCF (que, en este caso, actúa como AF), 101.
En esta realización, se supone que la S-CSCF envía un mensaje Diameter (aplicación Nasreg) AAR a la CRF, 111, sobre la Rx y que contiene la ID de usuario pública del UE, y la ID de usuario privada y la dirección IP del UE. La CRF mapea la identidad de usuario pública y/o privada a la MSISDN y/o a la IMSI para recuperar la dirección IP
asociada. A continuación, la CRF lleva a cabo la verificación, es decir comprueba si la información recibida desde el GGSN (ver la etapa 31) es la misma, y acusa recibo de que la verificación ha sido (en este caso) satisfactoria sobre Rx a la S-CSCF en una respuesta AAA, 121.
Finalmente, se envía un mensaje SIP 2XX OK desde la S-CSCF al UE, 131.
La figura 6B es similar a la figura 6A con la diferencia de que el mapeo en la CRF no es satisfactorio. Por lo tanto las etapas 11-111 son similares a las etapas 11-111 de la figura 6A, y por ello mantienen los mismos numerales de referencia.
Tras establecerse en la CRF que el mapeo no es satisfactorio, es decir, que la primera y la segunda informaciones relativas a la identidad de UE no son iguales, se envía un mensaje de error sobre la Rx (Diameter) a la S-CSCF, 122. Finalmente, la CRF puede enviar a continuación un mensaje Diameter CCA sobre la Gx al GGSN, 132, indicando que las normas de facturación pertinentes deberían eliminarse. El GGSN confirma a continuación a la CRF la eliminación, 142 y (en cualquier caso, independientemente de si se implementan o no las etapas 132, 142) se envía un mensaje de error desde la S-CSCF o UE, por ejemplo, un SIP 4XX Forbidden, 152.
Debería resultar evidente que el concepto inventivo no se limita la utilización de Diameter. Puede utilizarse asimismo Radius o cualquier otro protocolo adecuado. Tal como se ha mencionado anteriormente, el flujo será asimismo diferente si se utiliza un CGGN, en lugar de un GGSN y un SGSN lo cual, no obstante, no se muestra explícitamente dado que en las variaciones serían obvias.
Tal como se ha mencionado también anteriormente, no tienen por qué actuar la S-CSCF como una AF, y en lugar de la CRF puede ser, por ejemplo, un PDF, PCCN, etc.
La figura 7 muestra una realización particular en la que el nodo de gestión de facturación y/o de políticas comprende un PCCN 30A (nodo de control de políticas y facturación). El PCCN 30A comunica con el control 36A de crédito basado en flujo de datos de servicio o, de forma más general, con el OCS. Si, por ejemplo, el PCCN 30A recibe una identidad IMS, por ejemplo la IMPI, desde una AF (no mostrada), éste puede solicitar la IMSI al repositorio de perfiles de suscripción 35 sobre el punto de referencia Sp (o, en particular, la interfaz Sp). De manera más general, si el PCCN 30A recibe una identidad IMS, puede consultar el repositorio de perfiles de suscripción 35 a efectos de obtener una conexión entre la identidad IMS (IMPI o IMPU) y la MSISDN o la IMSI recibida de la TPF, por ejemplo, en el GGSN. Esto es ventajoso porque cubre asimismo casos en que los usuarios utilizan un ISIM que puede tener otra estructura para la IMPI, que por ejemplo no esté basada en la IMSI o la MSISDN. En otra realización (no mostrada) el PCCN (o la PDF 33A o la CRF 34A en el PCCN, como alternativa a un PCCN), puede solicitar el control de crédito 36A basado en flujo de datos de servicio, a efectos de obtener una conexión entre la identidad IMS y la MSISDN/IMSI recibida desde la TPF.
La figura 8A muestra esquemáticamente otra arquitectura en la que es aplicable el concepto inventivo. Dicho diseño se da a conocer, por ejemplo, en el documento TR 23.803. En este caso, el nodo de gestión de facturación y/o de políticas comprende un PCCN 30B con una PDF 33B y una CRF 34B en comunicación con una AF 20B sobre una interfaz Rx/Gq fusionada. En este caso, el nodo de soporte de datos en paquetes que incluye la funcionalidad TPF 11 comprende una pasarela 10B que, además de la funcionalidad TPF 11, incluye asimismo una funcionalidad PEP (Policy Enforcement Point, punto de ejecución de políticas), 12. La comunicación entre el PCCN 30B y la pasarela GW 10B tiene lugar sobre la interfaz fusionada Go/Gx. El PCCN 30B comunica con el OCS (Online Charging System, sistema de facturación en línea) 36B con un Camel SCP 37B y con medios 38B de control de crédito basados en flujo de datos de servicio, sobre la interfaz Ry. La GW 10B comunica con el OSC 36B sobre la interfaz Gy. La GW 10B comunica asimismo con una función 15B1 de pasarela de facturación y una función 15B2 de cobro de facturación, sobre la interfaz Gz.
La figura 8B muestra otra realización similar a la de la figura 8A, pero con la diferencia de que el OSC y la PCCN están fusionados en un nodo 30C, que comunica con la GW 10C sobre una interfaz fusionada que comprende las interfaces Gy/Go/Gx fusionadas entre ellas. En otros aspectos, la figura 8B es similar a la figura 8A y el OCS/PCCN 30C comunica sobre una interfaz fusionada Gq/Rx con la AF 20C, y la GW 10C comunica sobre la Gz con la función 15C1 de pasarela de facturación y la función 15C2 de cobro de facturación.
Debería estar claro que estas figuras se muestran solamente para presentar algunos ejemplos adicionales sobre diseños en los que puede aplicarse el concepto inventivo.
Por lo tanto, según la invención, mediante solamente una leve adición a los diseños FBC existentes o similares, puede proporcionarse seguridad para IMS precoz. Los operadores que utilizan FBC para servicios no basados en IMS que migran a IMS reciben la oportunidad de simplemente actualizar la FBC en lugar de HSS y un servidor Radius, lo cual es muy ventajoso. El concepto inventivo no implica limitaciones, por ejemplo, sobre un diseño GGSN, por ejemplo asignación o liberación de direcciones IP, tal como es el caso con la propuesta proporcionada en el documento TR 33.878, y tampoco existe la necesidad de introducir un temporizador de reposo en el GGSN. Según la invención, las identidades del IMS pueden estar en conexión, por ejemplo, con identidades basadas en GPRS mediante la utilización de las interfaces Rx y Gx.
La figura 9 es un diagrama de flujo que describe una implementación del concepto inventivo. En este caso, se supone que un UE solicita a la TPF un establecimiento de servicio de portador, 100. En la solicitud, el UE incluye la primera información relativa a la identidad del UE, o si se trata de una solicitud de contexto PDP secundario, la primera información relativa a la identidad del UE está ya almacenada en el nodo que gestiona la TPF. No obstante,
5 esto es conocido en la técnica.
La TPF envía a continuación una solicitud de normas de facturación y/o de políticas a la CRF o la PDF, o a un PCCN, en función de la implementación aplicable, que incluye dicha primera información relativa a la identidad del UE, 101. La CRF/PDF (o el PCCN) almacena la primera información relativa a la identidad del UE en medios de almacenamiento, por ejemplo una tabla, 102. A continuación, la CRF/PDF (o el PCCN) identifica e instala, utilizando 10 dicha primera información relativa a la identidad del UE y posiblemente otra información tal como se ha mencionado anteriormente, las normas pertinentes de facturación y/o de políticas, 103. A continuación la CRF/PDF (o el PCCN) proporciona las normas de facturación y/o de políticas a la TPF, 104. A continuación se envía un mensaje de aceptación de establecimiento de servicio de portador desde la TPF al UE, 105. Una vez que se ha establecido un servicio de portador, se supone que el UE envía un mensaje SIP o una solicitud SIP, por ejemplo una invitación SIP, 15 a una función de aplicación AF, 106. A continuación, puede comprobarse si la identidad de usuario privada se conoce a partir del mensaje SIP, 107. Si no, ésta puede obtenerse de alguna manera en la AF o bien en comunicación con algún otro nodo o función, tal como se ha descrito anteriormente, 107A. A continuación, así como si la identidad de usuario privada se conocía de hecho a partir del mensaje SIP o de la solicitud SIP, se envía la segunda información relativa a la identidad del UE a la CRF/PDF o al PCCN, 108. De esta manera, en la CRF/PDF o 20 el PCCN se examina a continuación si la primera información relativa a la identidad del UE y la segunda información relativa a la identidad del UE se han originado en un único UE, 109. Si no, se comprueba si las normas de gestión de facturación y/o de políticas han de ser desactivadas, 109A, y si es así, se desactivan y/o se desecha el tráfico pertinente, 109B. Sin embargo, si en la etapa 109A se selecciona la opción de que las normas no han de ser desactivadas, así como si la primera y la segunda informaciones relativas a la identidad del UE están originadas
25 respectivamente en un único UE, se implementan las normas de facturación y/o de políticas, 110.
Debería resultar evidente que la invención no se limita a las realizaciones mostradas específicamente, sino que puede variarse de muchas formas dentro del alcance de las reivindicaciones adjuntas.

Claims (21)

  1. REIVINDICACIONES
    1. Una disposición en un sistema de comunicaciones que participa en procedimientos de solicitud de y/o de acceso a servicios de estación de usuario, y que comprende una serie de nodos de soporte de datos en paquetes (GGSN; CGSN; TPF; 10; 10B; 10C), una serie de nodos de gestión de facturación y/o de políticas (CRF; TPF; PCCN; 30; 30A; 30B; 30C) y una serie de funciones de aplicación (AF; P, S, ICSCF; 20; 20B; 20C) que administran la gestión de movilidad y el control de llamadas de estaciones de usuario móviles (UE; 1) que solicitan y/o acceden a servicios,
    caracterizada
    por que el nodo o nodos de soporte de datos en paquetes (10; 10B; 10C) comprenden medios adoptados para enviar una primera información relativa a la identidad de la estación de usuario móvil (UE; 1) sobre una primera interfaz (Gx, Gy; Gx/Gy) a un nodo de gestión de facturación y/o de políticas (CRF; PDF; PCCN; 30; 30A; 30B; 30C), a la recepción de una solicitud de servicios de portador procedente de una estación de usuario móvil (UE; 1)
    por que la función o funciones de aplicación (AF; P, S, ICSCF; 20; 20B; 20C) comprenden medios para, a la recepción de una solicitud de una sesión de servicio SIP procedente de una estación de usuario móvil (UE; 1), enviar una segunda información relativa a la identidad de la estación de usuario móvil al nodo de gestión de facturación y/o de políticas (CRF; PDF; PCCN; 30; 30A; 30B; 30C), sobre una segunda interfaz (Rx, Rx/Gq),
    y por que el nodo (CRF; PDF; PCCN; 30; 30A; 30B; 30C) de gestión de políticas y/o de facturación comprende medios de verificación (32, 32A) adaptados para determinar si la solicitud de un servicio de portador al nodo de soporte de datos en paquetes (10; 10B; 10C) y la solicitud de un servicio de sesión a la función de aplicación (AF; P/S/I-CSCF; 20; 20B; 20C) están originadas en una única estación de usuario móvil (UE; 1).
  2. 2. Una disposición según la reivindicación 1,
    caracterizada
    por que la primera información relativa a la identidad de la estación de usuario móvil comprende una o varias de la MSISDN, la IMSI y la dirección IP de la estación de usuario móvil (UE; 1).
  3. 3. Una disposición según la reivindicación 1 ó 2,
    caracterizada
    por que la segunda información relativa a la identidad de la estación de usuario móvil comprende la identidad privada IMS (IMPI) y/o la identidad pública IMS (IMPU).
  4. 4. Una disposición según la reivindicación 1 ó 2,
    caracterizada
    por que la segunda información relativa a la identidad de la estación de usuario móvil comprende la IMSI y/o la MSISDN, por ejemplo, obtenida a partir de la identidad privada o pública IMS (IMPI, IMPU), o por que la función de aplicación (20; 20B; 20C) está adaptada para extraer dicha información externamente, por ejemplo, de un HSS.
  5. 5. Una disposición según cualquiera de las reivindicaciones anteriores,
    caracterizada
    por que las direcciones IP se reciben, o se obtienen a partir de la primera información relativa a la estación de usuario móvil y de la segunda información relativa a la identidad de la estación de usuario móvil, y por que los medios de verificación (32, 32A) están adaptados para comparar la dirección IP obtenida a partir de la función de aplicación (20; 20B; 20C) con la dirección IP obtenida a partir del nodo de soporte de datos en paquetes.
  6. 6. Una disposición según la reivindicación 4,
    caracterizada
    por que el nodo de gestión de facturación y/o de políticas (30; 30A; 30B; 30C) está adaptado para deducir la IMSI y/o la MSISDN a partir de la identidad de usuario privada y/o pública IMS (IMPI/IMPU).
  7. 7. Una disposición según cualquiera de las reivindicaciones anteriores,
    caracterizada
    por que el nodo de gestión de facturación y/o de políticas (30; 30A; 30B; 30C) está adaptado para identificar e instalar normas de facturación a aplicar a la recepción de la solicitud de las mismas desde un nodo de soporte de datos en paquetes (10; 10B; 15B1, 15B2; 10C).
  8. 8. Un usuario según cualquiera de las reivindicaciones anteriores,
    caracterizado
    por que el nodo de soporte de datos en paquetes comprende un GGSN (10) o un CGSN que gestiona opciones para el plano de tráfico.
  9. 9. Una disposición según cualquiera de las reivindicaciones anteriores,
    caracterizada
    por que el nodo de soporte de datos en paquetes comprende un nodo independiente o un nodo de pasarela (10B; 10C) que gestiona funciones para el plano de tráfico, o funciones para el plano de tráfico y ejecución de políticas (PEP).
  10. 10. Una disposición según cualquiera de las reivindicaciones anteriores,
    caracterizada
    por que la segunda interfaz comprende Rx o Rx fusionadas con Gq.
  11. 11. Un nodo de gestión de facturación y/o de políticas (30; 30A; 30B; 30C) en un sistema de comunicaciones que soporta comunicación de datos en paquetes y está dispuesto para comunicar con una función de aplicación (20; 20B; 20C) y un nodo de soporte de datos en paquetes (10; 10B; 10C),
    caracterizado
    por que está adaptado para recibir una primera información relativa a la identidad de la estación de usuario móvil procedente del nodo de soporte de datos en paquetes (10; 10B; 10C) a la recepción de una solicitud de un servicio de portador procedente de una estación de usuario móvil (UE; 1) en el nodo de soporte de datos en paquetes (10; 10B; 10C), para recibir una segunda información relativa a la identidad de la estación de usuario móvil procedente de la función de aplicación a la recepción de una solicitud de una sesión de servicio en la misma, y por que comprende medios de verificación (32, 32A) para determinar si la solicitud de un servicio de portador al nodo de soporte de datos en paquetes (10; 10B; 10C) y la solicitud de un servicio de sesión a la función de aplicación (20; 20B; 20C) están originadas en una única estación de usuario móvil (UE; 1).
  12. 12. Un nodo de gestión de facturación y/o de políticas según la reivindicación 11,
    caracterizado
    por que la primera información relativa a la identidad de la estación de usuario móvil comprende uno o varios de la MSISDN, la IMSI y la dirección IP de la estación de usuario móvil.
  13. 13. Un nodo de gestión de facturación y/o de políticas según cualquiera de las reivindicaciones 11 a 12,
    caracterizado
    por que los medios de verificación (32, 32A) están adaptados para comparar la dirección IP correspondiente a, o incluida en la primera información relativa a la identidad de la estación de usuario móvil, y la dirección IP correspondiente a, o incluida en la segunda información relativa a la identidad de la estación de usuario móvil.
  14. 14. Un nodo de gestión de facturación y/o de políticas según cualquiera de las reivindicaciones 11 a 13,
    caracterizado
    por que está adaptado para identificar e instalar normas de facturación a aplicar, a la recepción de una solicitud de las mismas desde un nodo de soporte de datos en paquetes (10; 10B; 10C), y si la primera y la segunda informaciones relativas a la identidad de usuarios están originadas en una única estación de usuario móvil (1), está adaptado para implementar las normas de facturación proporcionadas, y si la primera y la segunda informaciones relativas a la identidad de usuario no están originadas en una única estación de usuario móvil,
    está adaptado para rechazar las normas de facturación y/o para desactivar normas de facturación implementadas y desechar el tráfico de flujo IP correspondiente, informar a la función de aplicación (20; 20B; 20C) de que no está disponible un contexto PDP, o seleccionar si desactivar las normas de facturación en el nodo de soporte de datos en paquetes (10; 10B; 10C) o mantenerlas activas.
  15. 15. Un método de control de acceso a servicios, en un sistema de comunicación que soporta comunicación de datos en paquetes y comprende una serie de nodos de datos en paquetes, una serie de nodos de gestión de facturación y/o de políticas y una serie de funciones de aplicación que administran gestión de movilidad y control de llamadas de servicios de solicitud/acceso de estaciones de usuario móviles, que comprende las etapas de:
    -
    recibir una solicitud de servicios de portador desde una estación de usuario móvil en un nodo de soporte de datos en paquetes,
    -
    enviar, desde el nodo de soporte de datos en paquetes, una primera información relativa a la identidad de estación de usuario móvil, de la estación de usuario móvil, a un nodo de gestión de facturación y/o de políticas,
    -
    recibir, a continuación, antes o sustancialmente al mismo tiempo, una solicitud de una sesión de servicio procedente de la estación de usuario móvil en una función de aplicación,
    -
    enviar, desde la función de aplicación, una segunda información relativa a la identidad de la estación de usuario móvil al nodo de gestión de facturación y/o de políticas,
    -
    establecer, en el nodo de gestión de facturación y/o de políticas, si la solicitud de un servicio de portador al nodo de soporte de datos en paquetes y la solicitud de una sesión de servicio a la función de aplicación se originan en una única estación de usuario móvil.
  16. 16.
    Un método según la reivindicación 15,
    en el que la primera información relativa a la identidad de la estación de usuario móvil comprende una o varias de la MSISDN, la IMSI y la dirección IP de la estación de usuario móvil, y en el que la segunda información relativa a la identidad de la estación de usuario móvil comprende la identidad privada IMS (IMPI) y/o la identidad pública IMS (IMPU), o la segunda información relativa a la identidad de usuario comprende la IMSI y/o la MSISDN, por ejemplo obtenidas a partir de la identidad privada o pública IMS (IMPI, IMPU), o la función de aplicación está adaptada para extraer dicha información de un HSS.
  17. 17.
    Un método según la reivindicación 15 ó 16, que comprende además las etapas de:
    -
    establecer o encontrar la IMSI y/o la MSISDN de dichas primera y segunda informaciones relativas a la identidad de la estación de usuario móvil,
    -
    comparar entre sí por lo menos parte de dichas primera y segunda informaciones relativas a la identidad de la estación de usuario móvil.
  18. 18. Un método según la reivindicación 15, 16 ó 17, que comprende la etapa de:
    -
    comparar las direcciones IP de dichas primera y segunda informaciones relativas a la identidad de la estación de usuario móvil.
  19. 19.
    Un método según cualquiera de las reivindicaciones 15 a 18, que comprende la etapa de: - obtener la IMSI y/o la MSISDN a partir de identidades de usuario públicas y/o privadas IMS (IMPI/IMPU) recibidas.
  20. 20.
    Un método según cualquiera de las reivindicaciones 15 a 19, que comprende la etapa de:
    -
    construir, en el nodo de gestión de facturación y/o de políticas, una identidad de usuario privada utilizando la IMSI de la estación de usuario móvil.
  21. 21. Un método según cualquiera de las reivindicaciones 15 a 20 que comprende la etapa de:
    -
    identificar e instalar normas aplicables de facturación y/o de políticas, a la recepción de una solicitud procedente de un nodo de soporte de datos en paquetes,
    -
    si la primera y la segunda informaciones relativas a la identidad de la estación de usuario móvil se originan en una única estación de usuario móvil,
    -
    implementar las normas de facturación y/o de políticas proporcionadas aplicables, en el nodo de gestión de facturación y/o de políticas, o bien,
    -
    desechar el tráfico de flujo IP correspondiente, o
    -
    seleccionar si activar o desactivar las normas de facturación.
ES05716144.0T 2004-11-10 2005-03-17 Disposición, nodos y método en relación con acceso a servicios sobre un sistema de comunicación Expired - Lifetime ES2458295T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US62669104P 2004-11-10 2004-11-10
US626691P 2004-11-10
PCT/EP2005/002837 WO2006050758A1 (en) 2004-11-10 2005-03-17 An arrangement, nodes and a method relating to services access over a communication system

Publications (1)

Publication Number Publication Date
ES2458295T3 true ES2458295T3 (es) 2014-04-30

Family

ID=34961847

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05716144.0T Expired - Lifetime ES2458295T3 (es) 2004-11-10 2005-03-17 Disposición, nodos y método en relación con acceso a servicios sobre un sistema de comunicación

Country Status (4)

Country Link
US (1) US7843860B2 (es)
EP (1) EP1810474B1 (es)
ES (1) ES2458295T3 (es)
WO (1) WO2006050758A1 (es)

Families Citing this family (97)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1303781C (zh) * 2004-04-01 2007-03-07 华为技术有限公司 一种分组数据业务的计费控制方法
US8325905B2 (en) * 2005-07-29 2012-12-04 Verizon Patent And Licensing Inc. Routing calls in a network
DE102005037868A1 (de) * 2005-08-10 2007-02-15 Siemens Ag Verfahren und Anordnung zur Vergebührung und Zugangskontrolle in einem Kommunikationsnetzwerk
US8191116B1 (en) * 2005-08-29 2012-05-29 At&T Mobility Ii Llc User equipment validation in an IP network
CN1984207B (zh) * 2006-03-07 2010-05-12 华为技术有限公司 一种PoC业务的计费方法及设备
CN101047988B (zh) * 2006-05-30 2010-12-01 华为技术有限公司 一种用户漫游状态下的策略及计费控制方法
DE102006026929B4 (de) * 2006-06-09 2008-03-06 Siemens Ag Verfahren zur mehrfachen Registrierung eines multimodalen Kommunikationsendgerätes
US20080219241A1 (en) * 2007-03-09 2008-09-11 Nokia Corporation Subscriber access authorization
US10171998B2 (en) 2007-03-16 2019-01-01 Qualcomm Incorporated User profile, policy, and PMIP key distribution in a wireless communication network
CN101110766B (zh) * 2007-03-23 2010-04-21 华为技术有限公司 一种信令ip流承载事件上报的控制方法和功能实体
CN101291233B (zh) 2007-04-20 2011-04-20 华为技术有限公司 一种实现事件检测的方法及系统
US9681336B2 (en) * 2007-06-13 2017-06-13 Qualcomm Incorporated Quality of service information configuration
EP2007098A1 (en) * 2007-06-18 2008-12-24 Nokia Siemens Networks Oy Methods, apparatuses and computer program product for user equipment authorization based on matching network access technology specific identification information
CN101720546B (zh) * 2007-06-22 2015-11-25 艾利森电话股份有限公司 通过ip多媒体子系统电信网络中的用户设备单元提供服务的方法，包括所述方法使用的用户数据库服务器、服务策略服务器和应用服务器
WO2009021555A1 (en) * 2007-08-15 2009-02-19 Telefonaktiebolaget Lm Ericsson (Publ) Early ims security
CN101399699B (zh) * 2007-09-30 2011-10-05 华为技术有限公司 策略判决功能实体的寻址方法、网元设备及网络系统
EP2056570A1 (en) * 2007-10-29 2009-05-06 Nokia Siemens Networks Oy Session and media binding to common control
WO2009064574A1 (en) * 2007-11-15 2009-05-22 Airwalk Communications, Inc. System, method, and computer-readable medium for processing call originations by a femtocell system
EP2232819B1 (en) 2007-12-28 2015-08-26 Telefonaktiebolaget L M Ericsson (publ) Method of access provision
CN101217794B (zh) * 2008-01-09 2012-05-09 中兴通讯股份有限公司 一种获知承载业务类型及完成承载网切换的方法
US20090190471A1 (en) * 2008-01-10 2009-07-30 Mahendran Arungundram C Method and Apparatus for Optimized Session Setup with Network-Initiated QoS Policy Control
CN101471797B (zh) * 2008-03-31 2012-05-30 华为技术有限公司 决策方法及系统和策略决策单元
CN101335703B (zh) * 2008-05-30 2011-08-10 中兴通讯股份有限公司 端到端的服务质量保证方法
US8391834B2 (en) 2009-01-28 2013-03-05 Headwater Partners I Llc Security techniques for device assisted services
US8898293B2 (en) 2009-01-28 2014-11-25 Headwater Partners I Llc Service offer set publishing to device agent with on-device service selection
US8635335B2 (en) 2009-01-28 2014-01-21 Headwater Partners I Llc System and method for wireless network offloading
US8924469B2 (en) 2008-12-18 2014-12-30 Headwater Partners I Llc Enterprise access control and accounting allocation for access networks
US8675507B2 (en) 2009-01-28 2014-03-18 Headwater Partners I Llc Service profile management with user preference, adaptive policy, network neutrality and user privacy for intermediate networking devices
US8832777B2 (en) 2009-03-02 2014-09-09 Headwater Partners I Llc Adapting network policies based on device service processor configuration
US8346225B2 (en) 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US8626115B2 (en) 2009-01-28 2014-01-07 Headwater Partners I Llc Wireless network service interfaces
US8548428B2 (en) 2009-01-28 2013-10-01 Headwater Partners I Llc Device group partitions and settlement platform
US8725123B2 (en) 2008-06-05 2014-05-13 Headwater Partners I Llc Communications device with secure data path processing agents
US8406748B2 (en) 2009-01-28 2013-03-26 Headwater Partners I Llc Adaptive ambient services
US8589541B2 (en) 2009-01-28 2013-11-19 Headwater Partners I Llc Device-assisted services for protecting network capacity
US8275830B2 (en) 2009-01-28 2012-09-25 Headwater Partners I Llc Device assisted CDR creation, aggregation, mediation and billing
US8340634B2 (en) 2009-01-28 2012-12-25 Headwater Partners I, Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US8924543B2 (en) 2009-01-28 2014-12-30 Headwater Partners I Llc Service design center for device assisted services
US8402111B2 (en) 2009-01-28 2013-03-19 Headwater Partners I, Llc Device assisted services install
EP2161897A1 (en) * 2008-09-04 2010-03-10 Alcatel, Lucent A method for IP address assignment for access to IP services via WiMAX or 3GPP access network
US8788678B2 (en) * 2008-10-15 2014-07-22 Telefonaktiebolaget Lm Ericsson (Publ) IP multimedia subsystem user identity handling
US20100175122A1 (en) * 2009-01-08 2010-07-08 Verizon Corporate Resources Group Llc System and method for preventing header spoofing
US9706061B2 (en) 2009-01-28 2017-07-11 Headwater Partners I Llc Service design center for device assisted services
US9647918B2 (en) 2009-01-28 2017-05-09 Headwater Research Llc Mobile device and method attributing media services network usage to requesting application
US10492102B2 (en) 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US8606911B2 (en) 2009-03-02 2013-12-10 Headwater Partners I Llc Flow tagging for service policy implementation
US10264138B2 (en) 2009-01-28 2019-04-16 Headwater Research Llc Mobile device and service management
US8745191B2 (en) 2009-01-28 2014-06-03 Headwater Partners I Llc System and method for providing user notifications
US8351898B2 (en) 2009-01-28 2013-01-08 Headwater Partners I Llc Verifiable device assisted service usage billing with integrated accounting, mediation accounting, and multi-account
US10484858B2 (en) 2009-01-28 2019-11-19 Headwater Research Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US8793758B2 (en) 2009-01-28 2014-07-29 Headwater Partners I Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US10715342B2 (en) 2009-01-28 2020-07-14 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US11985155B2 (en) 2009-01-28 2024-05-14 Headwater Research Llc Communications device with secure data path processing agents
US11218854B2 (en) 2009-01-28 2022-01-04 Headwater Research Llc Service plan design, user interfaces, application programming interfaces, and device management
US9980146B2 (en) 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US10783581B2 (en) 2009-01-28 2020-09-22 Headwater Research Llc Wireless end-user device providing ambient or sponsored services
US9565707B2 (en) 2009-01-28 2017-02-07 Headwater Partners I Llc Wireless end-user device with wireless data attribution to multiple personas
US9955332B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Method for child wireless device activation to subscriber account of a master wireless device
US10057775B2 (en) 2009-01-28 2018-08-21 Headwater Research Llc Virtualized policy and charging system
US9253663B2 (en) 2009-01-28 2016-02-02 Headwater Partners I Llc Controlling mobile device communications on a roaming network based on device state
US9571559B2 (en) 2009-01-28 2017-02-14 Headwater Partners I Llc Enhanced curfew and protection associated with a device group
US10326800B2 (en) 2009-01-28 2019-06-18 Headwater Research Llc Wireless network service interfaces
US11973804B2 (en) 2009-01-28 2024-04-30 Headwater Research Llc Network service plan design
US9578182B2 (en) 2009-01-28 2017-02-21 Headwater Partners I Llc Mobile device and service management
US12432130B2 (en) 2009-01-28 2025-09-30 Headwater Research Llc Flow tagging for service policy implementation
US9572019B2 (en) 2009-01-28 2017-02-14 Headwater Partners LLC Service selection set published to device agent with on-device service selection
US12388810B2 (en) 2009-01-28 2025-08-12 Headwater Research Llc End user device that secures an association of application to service policy with an application certificate check
US10064055B2 (en) 2009-01-28 2018-08-28 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US12166596B2 (en) 2009-01-28 2024-12-10 Disney Enterprises, Inc. Device-assisted services for protecting network capacity
US12452377B2 (en) 2009-01-28 2025-10-21 Headwater Research Llc Service design center for device assisted services
US9351193B2 (en) 2009-01-28 2016-05-24 Headwater Partners I Llc Intermediate networking devices
US10798252B2 (en) 2009-01-28 2020-10-06 Headwater Research Llc System and method for providing user notifications
US9954975B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Enhanced curfew and protection associated with a device group
US10248996B2 (en) 2009-01-28 2019-04-02 Headwater Research Llc Method for operating a wireless end-user device mobile payment agent
US10779177B2 (en) 2009-01-28 2020-09-15 Headwater Research Llc Device group partitions and settlement platform
US9270559B2 (en) 2009-01-28 2016-02-23 Headwater Partners I Llc Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow
US9392462B2 (en) 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US9755842B2 (en) 2009-01-28 2017-09-05 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US9858559B2 (en) 2009-01-28 2018-01-02 Headwater Research Llc Network service plan design
US10200541B2 (en) 2009-01-28 2019-02-05 Headwater Research Llc Wireless end-user device with divided user space/kernel space traffic policy system
US8893009B2 (en) 2009-01-28 2014-11-18 Headwater Partners I Llc End user device that secures an association of application to service policy with an application certificate check
US10237757B2 (en) 2009-01-28 2019-03-19 Headwater Research Llc System and method for wireless network offloading
US9557889B2 (en) 2009-01-28 2017-01-31 Headwater Partners I Llc Service plan design, user interfaces, application programming interfaces, and device management
US10841839B2 (en) 2009-01-28 2020-11-17 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US12389218B2 (en) 2009-01-28 2025-08-12 Headwater Research Llc Service selection set publishing to device agent with on-device service selection
EP2406928B1 (en) 2009-03-10 2017-01-04 Telefonaktiebolaget LM Ericsson (publ) Traffic control by ip multimedia subsystem
WO2011063853A1 (en) * 2009-11-30 2011-06-03 Nokia Siemens Networks Oy Method and network device establishing a binding between a plurality of separate sessions in a network
CN101790247A (zh) * 2010-02-26 2010-07-28 华为技术有限公司 一种被叫接续处理方法、装置和系统
WO2011159679A2 (en) * 2010-06-15 2011-12-22 Zte Corporation Method and system for integrating policy control and charging support in wimax voice services for prepaid and hotlining
US9154826B2 (en) 2011-04-06 2015-10-06 Headwater Partners Ii Llc Distributing content and service launch objects to mobile devices
CN103002592B (zh) 2011-09-16 2015-08-19 华为技术有限公司 一种回收逆向授予中传输机会控制权的方法及装置
WO2013113363A1 (en) * 2012-01-30 2013-08-08 Telefonaktiebolaget L M Ericsson (Publ) Methods and nodes for managing network resources as well as a corresponding system and computer program
WO2014094228A1 (en) * 2012-12-18 2014-06-26 Telefonaktiebolaget L M Ericsson(Publ) Method and device for handling dropped data packets
WO2014159862A1 (en) 2013-03-14 2014-10-02 Headwater Partners I Llc Automated credential porting for mobile devices
KR101414231B1 (ko) 2013-08-28 2014-07-01 한국인터넷진흥원 비정상 호 탐지 장치 및 방법
US20160221463A1 (en) * 2013-10-25 2016-08-04 Nec Corporation Charger, charging system, and charging method
CN103701954B (zh) * 2014-01-03 2017-05-24 中国联合网络通信集团有限公司 一种域名寻址方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6445922B1 (en) * 1999-12-15 2002-09-03 Lucent Technologies Inc. Method and system for support of overlapping IP addresses between an interworking function and a mobile IP foreign agent
US8699472B2 (en) * 2000-05-24 2014-04-15 Nokia Corporation Common charging identifier for communication networks
WO2002003217A1 (en) * 2000-06-30 2002-01-10 Net2Phone System, method, and computer program product for resolving addressing in a network including a network address translator
US7031314B2 (en) * 2001-05-16 2006-04-18 Bytemobile, Inc. Systems and methods for providing differentiated services within a network communication system
KR100450973B1 (ko) * 2001-11-07 2004-10-02 삼성전자주식회사 무선 통신시스템에서 이동 단말기와 홈에이전트간의인증을 위한 방법
US7120148B1 (en) * 2002-02-12 2006-10-10 Cisco Technology, Inc. System and method for providing source awareness in a wireless application protocol network environment
US7574735B2 (en) * 2002-02-13 2009-08-11 Nokia Corporation Method and network element for providing secure access to a packet data network
TWI231900B (en) * 2002-08-19 2005-05-01 Ntt Docomo Inc Communication terminal providing function against connection with specific website and method thereof and memory media memorizing the program
US7545762B1 (en) * 2002-08-20 2009-06-09 Sprint Spectrum L.P. Method and system for network presence notification
US7616647B1 (en) * 2003-03-11 2009-11-10 Sprint Spectrum L.P. Method and system for wireless local number portability
WO2005015875A1 (en) * 2003-07-31 2005-02-17 T-Mobile Deutschland Gmbh Transparent access authentication in gprs core networks
US7668145B2 (en) * 2003-12-22 2010-02-23 Nokia Corporation Method to support mobile IP mobility in 3GPP networks with SIP established communications

Also Published As

Publication number Publication date
US7843860B2 (en) 2010-11-30
EP1810474A1 (en) 2007-07-25
EP1810474B1 (en) 2014-03-12
US20080198845A1 (en) 2008-08-21
WO2006050758A1 (en) 2006-05-18

Similar Documents

Publication Publication Date Title
ES2458295T3 (es) Disposición, nodos y método en relación con acceso a servicios sobre un sistema de comunicación
JP5016359B2 (ja) Ｉｐマルチメディアサブシステムへのアクセスを与える方法
US7836487B2 (en) Apparatus and method for authenticating a user when accessing to multimedia services
ES2371109T3 (es) Sistema y aparato para usuarios de cs móvil para acceder a la red de ims y el método de registro para el acceso.
CN111147421B (zh) 一种基于通用引导架构gba的认证方法及相关设备
US7647493B2 (en) Communication system and method
US9264411B2 (en) Methods, apparatuses and computer program product for user equipment authorization based on matching network access technology specific identification information
US7526642B2 (en) Controlling delivery of certificates in a mobile communication system
US20080198861A1 (en) Method for the routing and control of packet data traffic in a communication system
EP2218270A2 (en) System and method for authenticating a context transfer
ES2351102T3 (es) Procedimiento para el autoaprovisionamiento de datos de abonado en el subsistema multimedia ip (ims).
US20100169950A1 (en) Policy management in a roaming or handover scenario in an ip network
CN101252770A (zh) Ims的终端接入认证的方法、通信系统及相关设备
US7770216B2 (en) Transparent access authentication in GPRS core networks
WO2004034671A1 (en) Controlling delivery of certificates in a mobile communication system
CN101083838B (zh) Ip多媒体子系统中的http摘要鉴权方法
RU2337504C2 (ru) Устройство и способ для аутентификации пользователя при доступе к мультимедийным службам
SB et al. „Diameter-based Protocol in the IP Multimedia Subsystem “
KR20050088988A (ko) 통신 단말장치의 식별 방법