ES2320368T3 - Procedimiento y sistema para imponer directivas adecuadas al trafico de datos en una red de comunicacion inalambrica. - Google Patents
Procedimiento y sistema para imponer directivas adecuadas al trafico de datos en una red de comunicacion inalambrica. Download PDFInfo
- Publication number
- ES2320368T3 ES2320368T3 ES06006444T ES06006444T ES2320368T3 ES 2320368 T3 ES2320368 T3 ES 2320368T3 ES 06006444 T ES06006444 T ES 06006444T ES 06006444 T ES06006444 T ES 06006444T ES 2320368 T3 ES2320368 T3 ES 2320368T3
- Authority
- ES
- Spain
- Prior art keywords
- unit
- crf
- ggsn
- directive
- 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.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
-
- 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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/66—Policy and charging system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/80—Rating or billing plans; Tariff determination aspects
- H04M15/8016—Rating or billing plans; Tariff determination aspects based on quality of service [QoS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/82—Criteria or parameters used for performing billing operations
- H04M15/8214—Data or packet based
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
- H04W8/20—Transfer of user or subscriber data
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- 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/08—Access security
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
- Circuits Of Receivers In General (AREA)
Abstract
Procedimiento para imponer directivas adecuadas para el tráfico de datos en un sistema de radiocomunicación, que comprende al menos un equipo terminal móvil (UE) y al menos una red de servicios (IMS) con al menos un nodo de entrada y al menos una unidad de directivas (CRF/PDF) y al menos un elemento de aplicación (AF), caracterizado porque en la unidad de directivas (CRF/PDF) se almacena al menos una parte (dirección IP, MSISDN) de los datos de usuario de los usuarios a los que presta servicio la unidad de directivas (CRF/PDF), para su utilización en una comprobación de competencia de la unidad de directivas (CRF/PDF).
Description
Procedimiento y sistema para imponer directivas
adecuadas al tráfico de datos en una red de comunicación
inalámbrica.
La presente invención se refiere a un
procedimiento y un sistema para imponer directivas adecuadas para
el tráfico de datos en un sistema de radiocomunicación.
En los sistemas de radiocomunicación modernos es
posible conectar un equipo terminal móvil a una red central por
medio de una red de acceso. La red de acceso puede ser una red GPRS
(General Packet Radio Service [servicio general de
radiocomunicaciones por paquetes) o una red UMTS. En la red central
puede estar integrada una red de servicios (por ejemplo un
subsistema multimedia IP (IMS)).
En el tráfico de datos de una red de
radiocomunicación de este tipo han de aplicarse distintas directivas
(policies). Éstas pueden afectar por ejemplo a la tarificación del
tráfico de datos o a la calidad del servicio (Quality of Service
(QoS)). Estas directivas están almacenadas en unas funciones
correspondientes de la red de comunicación. Estas directivas pueden
estar almacenadas por ejemplo en una Charging Rule Function [Función
relacionada con la carga] (CRF) y/o una Policy Decision Function
[función de decisión de directiva] (PDF) o en una combinación de
tales funciones. Tanto una función de aplicación almacenada en la
IMS, que puede constituir por ejemplo una función de control de
servicios, por ejemplo una Call Session control function [función de
control de sesión de llamada] (CSCF), como el nodo de acceso
(Gateway GPRS support node [nodo de soporte de pasarela GPRS
(GGSN)) que se ocupa de la conexión de la red central a su IMS han
de acceder a las funciones de directivas para ejecutar las tareas
que les han sido asignadas.
En 3RD GENERATION PARTNERSHIP PROJECT 3GPP
"3^{rd} Generation Partnership Project; Technical Specification
Group Services and System Aspects; Evolution of Policy Control
Charging (entrega 7)"(3GPP TR 23.803 V0.3.0, 24 de marzo de
2005) se describe entre otras cosas, en el capítulo 4.2.0, página 7,
una arquitectura para directivas locales basadas en flujo y en
servicios. Como se desprende de esta descripción, si se utiliza un
testigo de autorización y un identificador de flujo se garantiza el
acceso a una unidad de directivas CRF tanto desde el TPF (como
parte del GGSN) como desde una función de aplicación (AF). Por parte
del TPF, el acceso a la CRF se realiza por medio de la red
conectada, por ejemplo del Access Point Name [nombre de punto de
acceso](APN). Por parte de la AF, el contacto con la CRF se
establece sobre la base de la dirección IP del usuario final.
Para enlazar el portador IP a servicios se
propone la utilización de la dirección IP del equipo terminal, así
como de un filtro, en particular un filtro TFT, con el fin de elegir
las reglas relativas a directivas y tarificación para un contexto
PDP secundario especial.
En el documento WO2004/100466 A se describe
además un procedimiento, sistema y elemento de red para la
autorización de una transmisión de datos. Cuando se inicializa un
enlace de comunicación se pide a una unidad de control de
directivas una autorización para los parámetros de conexión de los
servicios, decidiendo la unidad de control de directivas sobre los
parámetros de conexión a autorizar y sobre el tipo de servicios que
pueden ponerse a disposición para el enlace de comunicación.
Dado que el acceso de la AF y el acceso del GGSN
se realizan uno independientemente del otro y, por regla general,
con diferencia de tiempo, puede darse el caso de que uno de los
componentes acceda a una función de directivas y el otro a otra
función de directivas. Esto significa que se impondrían directivas
en caso dado distintas, o bien no adaptadas unas a otras, para el
mismo tráfico de datos. Los documentos del estado actual de la
técnica no tienen en cuenta este problema.
El objetivo de la presente invención es por lo
tanto tener en cuenta este problema. En particular se ha de
garantizar una asignación fiable de las funciones de directivas
adecuadas a componentes de un sistema de comunicación.
La invención se basa en el conocimiento de que
este objetivo puede lograrse si las funciones de directivas
almacenan información sobre los equipos terminales a los que prestan
servicio y transmiten esta información a otros componentes del
sistema de comunicación.
El objetivo se logra mediante un procedimiento
con las características según la reivindicación 1 y un sistema con
las características según la reivindicación 15.
Las ventajas y características descritas en
relación con el procedimiento serán correspondientemente válidas
-siempre que sean aplicables- para el sistema según la invención y
viceversa.
Por lo tanto, según un primer aspecto, el
objetivo se logra mediante un procedimiento para imponer directivas
adecuadas para el tráfico de datos en un sistema de
radiocomunicación, que comprende al menos un equipo terminal móvil
(UE) y al menos una red de servicios (IMS) con al menos un nodo de
acceso de red de transporte (GGSN) y al menos una unidad de
directivas (CRF/PDF) y al menos un elemento de aplicación (AF). El
procedimiento se distingue porque en la unidad de directivas
(CRF/PDF) se almacena al menos una parte (dirección IP, MSISDN) de
los datos de usuario de los usuarios a los que presta servicio la
unidad de directivas (CRF/PDF), para su utilización en una
comprobación de competencia de la unidad de directivas
(CRF/PDF).
Mediante el almacenamiento de datos de usuario
se determina en la unidad de directivas a qué usuarios presta
actualmente servicio la unidad de directivas en cuestión. Esta
información se utilizará en posteriores peticiones de registro para
determinar a qué unidad de directivas compete la unidad que efectúa
la petición.
En la unidad de directivas (CRF/PDF) puede
realizarse en particular, al recibir una petición de conexión de
una unidad del sistema de comunicación (GGSN, AF), una comparación
en cuanto a los datos de usuario almacenados (dirección IP, MSISDN)
para verificar si la unidad de directivas (CRF/PDF) presta servicio
al usuario al que se refiere la petición de conexión actual. La
información no tiene importancia sólo en la función de directivas
para la asignación de directivas adecuadas, sino que puede ser
importante también para el funcionamiento de otros componentes del
sistema de comunicación.
Para transmitir esta información sobre si una
unidad de directivas presta servicio a un usuario puede enviarse al
menos a la unidad que efectúa la petición (GGSN, AF) un mensaje de
respuesta adecuado en función del resultado de la comparación.
Un nodo de red de entrada, en particular el nodo
de acceso de red de transporte (GGSN), puede tener asignada una
tabla de selección para una unidad de directivas (CRF/PDF), que en
lo que sigue se denomina también tabla de selección de unidad de
directivas, o tabla de selección, y que incluye al menos una entrada
de una unidad de directivas (CRF/PDF), en particular una dirección
de unidad de directivas. De este modo, al establecerse la conexión
con un equipo terminal móvil, por ejemplo en caso de que éste no
competa a una unidad de directivas o no sea posible acceder a esta
última, el nodo de entrada puede ponerse en contacto con otra unidad
de directivas para un control de crédito, por ejemplo, enviando una
petición de control de crédito (Credit Control Request
(CCR)).
(CCR)).
En al menos un elemento (AF) de la red de
servicios (IMS) está almacenada también una tabla de selección de
unidad de directivas. Ésta presentará al menos dos entradas de
directivas, que coinciden con dos entradas de la tabla de selección
de unidad de directivas en el nodo de red de entrada (GGSN).
La tabla de selección de unidad de directivas
almacenada en el elemento (AF) de la red de servicios (IMS) es
preferentemente idéntica a la tabla de selección almacenada en el
nodo de red de entrada, en particular en el nodo de acceso de red
de transporte (GGSN). De este modo es posible, con un puro recorrido
de la tabla, asegurarse de que el elemento (AF) y el nodo de red de
entrada (GGSN) accedan, o sean conectados, a la misma unidad de
directivas. Al mismo tiempo, no es necesario ningún mecanismo de
emergencia, como el que debería estar previsto si las entradas de
las tablas no fueran idénticas para el caso de que el nodo de red de
entrada (GGSN) hubiese seleccionado una unidad de directivas no
existente en la tabla del elemento AF.
La unidad que efectúa la petición (GGSN, AF), al
recibir un mensaje de respuesta negativo ("too busy (demasiado
ocupado)", "IP adress not served (dirección IP no
atendida)"), enviará preferentemente una petición a una unidad
de directivas (CRF/PDF) alternativa, seleccionada de acuerdo con una
identidad de usuario y la tabla de selección de unidad de
directivas. Mediante la selección en función de la identidad de
usuario, que por ejemplo puede estar determinada por la dirección
IP del UE, se minimiza el número de direcciones de directivas
posibles y se acorta el proceso de selección y un paso en caso dado
subsiguiente de comprobación de competencia por otra unidad que
efectúe una petición.
Las entradas de la tabla de selección de unidad
de directivas pueden estar asignadas a un grupo de equipos
terminales móviles (UE) o ser válidas para toda la red.
Según la invención, también es posible asignar
las entradas de la tabla de selección de unidad de directivas a un
equipo terminal móvil (UE) de forma dinámica.
Para la selección dinámica de una unidad de
directivas (CRF/PDF) puede realizarse una consulta con una ventana
que comprenda al menos dos entradas de la lista o tabla de
selección. La selección dinámica permite realizar un reparto de la
carga mediante las funciones de directivas almacenadas en la
tabla.
La ventana puede determinarse en particular
mediante una división módulo de los datos de usuario y el número de
entradas de la lista o tabla de selección. De este modo se obtiene
siempre un valor al que puede dirigirse la ventana. A partir del
valor obtenido mediante la división módulo, que remite a una función
de directivas, puede o pueden reunirse por ejemplo la entrada
siguiente o varias entradas siguientes como la ventana en la que
éstas están asignadas a un equipo terminal. En la asignación
dinámica se utiliza el mismo tamaño de ventana en el nodo de red de
entrada y en el elemento AF.
\newpage
La división módulo puede realizarse, para una
tabla de selección con n entradas, por medio de una de las
siguientes ecuaciones:
- \quad
- (dirección IP del UE) Mod n; {}\hskip0.3cm ó
- \quad
- (MSISDN del UE) Mod n
El resto que queda tras la división de los
valores correspondientes constituye el resultado. El primer
elemento se selecciona como unidad de directivas primaria, mientras
que el segundo elemento se utiliza como unidad de directivas
secundaria.
Como datos de usuario se utiliza preferentemente
la dirección IP del equipo terminal móvil (UE). Dado que estos
datos de usuario han de ser accesibles tanto para el nodo de red de
entrada como para el elemento AF, este dato resulta ideal. Como
alternativa puede utilizarse el número MSISDN (Número RDSI de
abonado móvil). Sin embargo, en este caso se ha de tener en cuenta
la portabilidad (portability) del número, que en caso dado podría
causar problemas.
En la unidad de directivas pueden estar
almacenadas directivas sobre tarificación y/o directivas sobre
calidad de servicio para tráfico de datos y aplicaciones u otras
directivas locales basadas en servicios (Service based Local Policy
[Servicio basado en directiva local](SBLP)).
Según otro aspecto, la invención se refiere a un
sistema para imponer directivas adecuadas para el tráfico de datos
en un sistema de radiocomunicación, que comprende al menos un equipo
terminal móvil (UE) y al menos una red de servicios (IMS) con al
menos un nodo de red de entrada, en particular un nodo de acceso de
red de transporte (GGSN), y al menos una unidad de directivas
(CRF/PDF) y al menos un elemento de aplicación (AF). El sistema se
distingue porque la unidad de directivas (CRF/PDF) presenta una
unidad de memoria en la que, al establecerse una conexión con un
equipo terminal móvil (UE), se almacena al menos una parte de los
datos de usuario del equipo terminal móvil (UE) para su utilización
en una comprobación de competencia de la unidad de directivas
(CRF/PDF).
La unidad de directivas (CRF/PDF) comprende
además preferentemente al menos una unidad de comparación, que
puede comparar los datos de usuario recibidos con datos de usuario
almacenados.
Al menos en el nodo de acceso de red de
transporte (GGSN) está almacenada una tabla de selección para la
selección de una unidad de directivas (CRF/PDF) adecuada.
El sistema según la invención está diseñado para
la realización del procedimiento según la invención.
A continuación se explica la invención de nuevo
detalladamente.
En un entorno 3GPP (3rd Generation Partnership
Project [Proyecto de asociación 3ª generación]), en el que las
CRF/PDF están implementadas con fines de tarificación en función del
volumen de datos transmitido (Flow bearer charging [carga de
portador de flujo]) y en función de la directiva local basada en
servicios, los nodos de red de entrada GGSN y la función de
aplicación (Application Function [función de aplicación](AF)) han
de seleccionar, por medio de la interfaz Gq/Rx (basada en diámetro)
y la interfaz Go/Gx (basada en diámetro) combinada, la misma
CRF/PDF real y establecer con ésta un enlace de comunicación con el
fin de asegurar que los datos de información de directivas que han
de aplicarse para un usuario para una sesión de aplicación actual
puedan localizarse e imponerse para el nodo de red de entrada
GGSN.
Para ello existen dos posibles topologías. Por
una parte, la CRF/PDF puede estar dispuesta junto con el AF, siendo
así especialmente en el caso de una P-CSCF
(Proxy-Call-Session-Controll-Function
[función de control de sesión de llamada]) de una IMS. Por otra
parte puede utilizarse una CRF/PDF autónoma.
En el caso de una CRF/PDF y
P-CSCF (para IMS) conjunta, el mecanismo de
selección de CRF/PDF debería asegurar que la dirección de CRF/PDF
seleccionada corresponda realmente a la elegida por el UE.
Se supone que se ha configurado una dirección
P-CSCF1 y una dirección P-CSCF2 para
el UE, con el fin de crear una redundancia geográfica (por ejemplo
reenviadas por la red o configuradas localmente). En este caso, el
UE seleccionará la primera dirección de la lista y enviará a ésta
mensajes específicos de aplicación, como por ejemplo en particular
un mensaje SIP-REGISTER. Si no es posible establecer
contacto con la P-CSCF1, o si ésta ha generado una
respuesta de error, el UE selecciona ahora la segunda entrada de la
lista. El UE puede conectarse con éxito a la
P-CSCF2.
De ello puede deducirse que hasta que no se
establece la conexión con la IMS no se sabe qué
P-CSCF seleccionará el UE. Es posible que la
CRF/PDF, que está dispuesta junto con la P-CSCF1,
haya respondido con éxito a la petición de directivas del GGSN, con
lo que el GGSN es conducido a una CRF/PDF errónea. La petición de
directivas puede ser la petición de tarificación, de SBLP (Service
Based Local Policy [servicio basado en directiva local]) o
ambas.
Algo similar ocurre en el caso de una CRF/PDF
autónoma. Se supone que se ha configurado una CRF/PDF1 y una
CRF/PDF2 para la ID del UE (por ejemplo dirección IP), tanto en el
GGSN como en el AF (por ejemplo P-CSCF de la IMS).
En este caso, el GGSN selecciona CRF/PDF1 y establece con éxito una
conexión con la misma. El AF recibe una petición específica de
aplicación del UE (por ejemplo SIP INVITE) e intenta establecer una
conexión válida con la CRF/PDF1, pero no puede establecer contacto
con ésta, por ejemplo debido a un error de conexión en la ruta a la
CRF/PDF1 o porque la CRF/PDF1 está sobrecargada. En vista de ello,
el AF selecciona la segunda entrada de la lista (CRF/PDF2) y
establece con éxito una conexión con ésta. El resultado es que los
AF seleccionados por el GGSN y por el UE conducen a CRF/PDF
distintas y el error no se detecta.
La ventaja de la presente invención consiste en
que la selección y localización de la CRF/PDF puede asegurar la
selección de la CRF/PDF adecuada y se hace posible un manejo de
errores tanto de la topología reunida/dispuesta conjuntamente como
de la topología autónoma.
En el estado actual de la técnica, el GGSN se
utiliza como un cliente de diámetro por medio de una interfaz Go/Gx
combinada, mientras que la CRF/PDF actúa de servidor de diámetro. El
AF (por ejemplo P-CSCF de la IMS) actúa de cliente
de diámetro mediante la interfaz Gp/Rx combinada, mientras que la
CRF/PDF actúa de servidor de diámetro. En el estándar IETS RFC 3588
se dan a conocer procedimientos de diámetro para el reconocimiento
de servidores y la protección contra fallos.
La desventaja de estos procedimientos ya
conocidos consiste en que el mecanismo de diámetro ya conocido para
la selección de servidor está basado en consultas de DNS NAPTR y
SRV, deduciéndose el ámbito por la NAI (Network Access Identity)
del usuario o a partir de configuraciones (manuales) estáticas. El
DNS NAPTR y el SVR son dinámicos y no pueden garantizar que dos
clientes diferentes lleven realmente para un mismo usuario al mismo
servidor si, por ejemplo, se utiliza un algoritmo Round Robin para
repartir la carga. La configuración local manual en el cliente no
está especificada y por lo tanto no puede asegurar que GGSN y AF
lleven para un mismo usuario a la misma CRF/PDF. Los mecanismos de
diámetro existentes para la protección contra fallos en lo
referente a un segundo servidor están definidos en RFC 3588.
Los mecanismos existentes no enfocan
suficientemente el problema arriba mencionado, por lo que existe la
necesidad de una mejora.
En la invención, al menos el GGSN está equipado
con una tabla de selección de CRF/PDF. En el caso de la
configuración autónoma de la CRF/PDF, también el AF está equipado
con dicha tabla de selección. Se configuran al menos dos
direcciones CRF/PDF, que pueden estar asignadas a un ámbito de ID de
UE o ser aplicables en toda la red. La ID utilizada ha de ser
accesible tanto para el GGSN como para el AF. Por este motivo, la
dirección IP del UE resulta ideal. Como alternativa también es
posible que la ID sea el MSISDN. Sin embargo, esto puede constituir
un desafío en lo que se refiere a la reutilización del número de
móvil. Una CRF/PDF presta servicio a todos los UE dentro del ámbito
de dirección IP asignada. De este modo es posible repartir la carga
para lograr una escalabilidad necesaria.
Si la CRF/PDF está dispuesta junto con la
P-CSCF (en el caso de la IMS), puede utilizarse la
tabla de selección de CRF/PDF durante proceso de reconocimiento de
P-CSCF basado en la conexión PDP
(PDP-Context based [basada en contexto]), para
asegurarse de que el GGSN transmite la dirección
P-CSCF adecuada al UE. Análogamente, el servidor
DHCP (Dynamic Host Configuration Protocol [protocolo de
configuración dinámica del anfitrión]) encargado de adjudicar
direcciones IP ha de estar configurado de modo que reproduzca las
mismas direcciones P-CSCF que las direcciones
configuradas para el mismo ámbito de direcciones IP de UE en el GGSN
o un GGSN mejorado (eGGSN, que en lo que sigue se denominará
también IPC (Intelligent Packet Core [núcleo de paquete
inteligente])). Si es posible establecer contacto con la CRF/PDF,
que está dispuesta junto con la P-CSCF, se espera
que también sea posible establecer contacto con la
P-CSCF y que funcione correctamente.
En el caso de una CRF/PDF autónoma, las tablas
de selección de P-CSCF y CRF/PDF son independientes
entre sí. Deberían configurarse las mismas dos CRF/PDF para un
ámbito de direcciones IP de UE tanto en el GGSN como en la
P-CSCF o el AF, con lo que se asegura que tanto el
GGSN como la P-CSCF o el AF lleven a la misma
CRF/PDF para un UE dado.
En la primera activación de contexto PDP, el
GGSN selecciona, como se ha descrito más arriba, la CRF/PDF a la
que ha de enviarse la petición de directivas. La petición de
directivas incluye la dirección IP del UE. Tras la recepción de la
primera petición de directivas, la CRF/PDF almacena la dirección IP
del UE y envía una respuesta de éxito al GGSN. Ésta constituye
desde este momento la CRF/PDF asignada al usuario (serving
CRF/PDF). En el caso de que no sea posible establecer contacto con
la CRF/PDF seleccionada, o en el caso de que ésta indique un error,
se selecciona la segunda CRF/PDF y ésta se convierte en la CRF/PDF
asignada al usuario.
Si un AF recibe del usuario una petición
específica de aplicación, el AF seleccionará la CRF/PDF sobre la
base de la dirección IP del UE. A continuación, el AF enviará a la
CRF/PDF una petición para el envío de datos específicos de
aplicación (por ejemplo deducidos de SIP/SDP). Esta petición incluye
la dirección IP del UE. En cuanto se ha recibido la petición con
los datos específicos de aplicación, la CRF/PDF comprueba si la
dirección IP de UE presentada recibe servicio. Si esta dirección IP
de UE recibe servicio, la CRF/PDF confirma el éxito de la petición.
Si esta dirección IP de UE no recibe servicio, la CRF/PDF envía un
mensaje de error "IP adress not served [dirección IP no
atendida]", que hará que el AF envíe la petición a otra CRF/PDF
a la que también esté conectado el GGSN para el mismo usuario. Si no
es posible establecer contacto con la CRF/PDF que realmente presta
servicio al UE, el AF puede decidir aceptar la sesión de aplicación
sobre la base de la directiva de operador o rechazarla (por ejemplo
sesión IMS).
En el caso de la IMS, donde las CRF/PDF pueden
estar implementadas junto con la P-CSCF, la CRF/PDF
envía, en caso de fallar la solicitud, cuando un error impide que el
UE lo intente de nuevo con una segunda dirección
P-CSCF (por ejemplo 500, 503 o error interno), una
notificación de diámetro para informar al GGSN de que la dirección
IP del UE no recibe servicio y envía un mensaje de diámetro con el
que se informa al GGSN de que la dirección IP del UE no recibe
servicio e inicia el desbloqueo de la sesión de diámetro Go/Gx. Un
mensaje de este tipo puede ser un mensaje RSR
(Re-Auth-Request) de diámetro, que
daría lugar a un mensaje de aplicación especial Go/Gx (por ejemplo
Credit Control-Request). La CRF/PDF enviaría
entonces un mensaje de error "IP adress not served" al GGSN.
Al recibir un mensaje de error "IP adress not served", el GGSN
establece una conexión con la otra CRF/PDF, que está dispuesta
junto con la segunda P-CSCF, con la que el UE
eventualmente se registra con éxito en la IMS.
A continuación se describe de nuevo la invención
por medio de las figuras adjuntas:
Muestran:
- Figura 1: un escenario en el desarrollo del
proceso según una forma de realización de la presente invención
(selección CRF/PDF);
- Figura 2: otro escenario en el desarrollo del
proceso según una forma de realización de la presente invención
(nueva selección de CRF/PDF con una P-CSCF dispuesta
conjuntamente);
- Figura 3: otro escenario en el desarrollo del
proceso según una forma de realización de la presente invención
(nueva selección de CRF/PDF por AF); y
- Figura 4: la disposición esquemática de
algunos componentes de red.
En el escenario representado en la figura 1 se
ejecutan los pasos siguientes:
1. El UE activa un contexto PDP para realizar un
registro de IMS.
2. Acto seguido, el GGSN (en este caso el eGGSN)
selecciona la CRF/PDF a seleccionar de acuerdo con la dirección IP
correspondiente al UE.
3. El GGSN envía una notificación de inicio de
CCR (Credit-Control-Request) a la
CRF/PDF seleccionada, indicándose la dirección IP del UE.
4. Aunque aún no existe ninguna sesión de
aplicación, la CRF/PDF autoriza la activación del contexto PDP
mediante el envío de una notificación de inicio de CCA con el
código de resultado AVP (Attribute value pair [pareja de valores de
atributo]) puesto en éxito (SUCCESS). La CRF/PDF puede poner límites
de QoS para el contexto PDP, por ejemplo la clase de tráfico máxima
para interactivo o fondo, y puede enviar reglas de tarificación
predeterminadas de acuerdo con la directiva de operador.
5. El IPC/GGSN activa el contexto PDP.
6/7. Si la aplicación es una aplicación IMS y la
CRF/PDF y la P-CSCF están dispuestas juntas, el UE
se registra con éxito en la IMS por medio de
P-CSCF1. El GGSN envía peticiones Go/Gx ulteriores a
la CRF/PDF1 seleccionada.
En el escenario representado en la figura 2 se
ejecutan los pasos siguientes:
1. El UE activa un contexto PDP para realizar un
registro de IMS.
2. Acto seguido, el GGSN selecciona la CRF/PDF a
seleccionar de acuerdo con la dirección IP correspondiente al UE.
Aquí se selecciona CRF/PDF1 (P-CSCF1).
3. El GGSN envía una notificación de inicio de
CCR- Request (petición CCR) a la CRF/PDF seleccionada, indicándose
la dirección IP del UE.
4. Aunque aún no existe ninguna sesión de
aplicación, la CRF/PDF autoriza la activación del contexto PDP
mediante el envío de una notificación de inicio de CCA con el
código de resultado AVP puesto en éxito (SUCCESS). La CRF/PDF puede
poner límites de QoS para el contexto PDP, por ejemplo la clase de
tráfico máxima para interactivo o fondo, y puede enviar reglas de
tarificación predeterminadas de acuerdo con la directiva de
operador.
5. El IPC/GGSN activa el contexto PDP y envía la
lista de direcciones P-CSCF (P-CSCF1
y 2).
6. El UE se registra en la IMS mediante el envío
de un mensaje SIP REGISTER a P-CSCF 1 (la primera en
la lista de dos de las direcciones P-CSCF
retornadas).
7. La P-CSCF 1 está
temporalmente no disponible y envía un "500 Server Internal Error
[error interno servidor]" o "503 Service Unavailable [servicio
no disponible]".
8. La P-CSCF 1 indica el error a
la unidad CRF/PDF dispuesta conjuntamente, indicándose todos los
errores que hacen que el UE envíe el mensaje de registro a otra
dirección P-CSCF.
9-13. La CRF/PDF inicia un
desbloqueo de sesión de diámetro Go/Gx. El código de argumentación
para el desbloqueo indica que la dirección IP no recibe servicio
("IP-address-not-served").
14-15. El UE selecciona una
segunda P-CSCF de la lista (P-CSCF
2) y se registra con éxito en la IMS.
16. Después de que la CRF/PDF 1 haya
desbloqueado la sesión Go/Gx indicando
("IP-adress-not-served"),
el GGSN selecciona la CRF/PDF secundaria (CRF/PDF2) y envía un
mensaje de inicio de CCR, que indica la dirección IP del UE.
17. Aunque no existe ninguna sesión IMS, la
E-PDF 2 autoriza la activación del contexto PDP
primario mediante el envío de un mensaje de inicio de CCA con el
código de resultado AVP puesto en SUCCESS. La CRF/PDF puede poner
límites de QoS para el contexto PDP (por ejemplo la clase de tráfico
máxima para interactivo o fondo) y envía reglas de tarificación
previamente configuradas de acuerdo con la directiva de operador. El
GGSN enviará peticiones Go/Gx ulteriores a la CRF/PDF 2
seleccionada.
En el escenario representado en la figura 3 se
ejecutan los pasos siguientes:
1. El UE activa un contexto PDP.
2. El GGSN selecciona la CRF/PDF a seleccionar
de acuerdo con la dirección IP asignada al UE. Aquí se selecciona
CRF/PDF1.
3. El GGSN envía una notificación de inicio de
CCR- Request (petición CCR) a la CRF/PDF seleccionada, indicándose
la dirección IP del UE.
4. La CRF/PDF está temporalmente no disponible y
responde con una notificación de error.
5. El GGSN envía una notificación de inicio de
CCR a la CRF/PDF secundaria.
6. Aunque aún no existe ninguna sesión de
aplicación, la CRF/PDF autoriza la activación del contexto PDP
mediante el envío de una notificación de inicio de CCA con el
código de resultado AVP puesto en éxito (SUCCESS). La CRF/PDF puede
poner límites de QoS para el contexto PDP, por ejemplo la clase de
tráfico máxima para interactivo o fondo, y puede enviar reglas de
tarificación predeterminadas de acuerdo con la directiva de
operador.
7. El GGSN activa el contexto PDP.
8. El UE envía una petición específica de
aplicación (por ejemplo SIP INVITE) al AF.
9. El AF selecciona la CRF/PDF con la que se ha
de establecer contacto en función de la dirección IP del UE. Se
selecciona CRF/PDF 1.
10. El AF envía un mensaje Gq/Rx (por ejemplo
AAA) a la CRF/PDF seleccionada con datos específicos de aplicación
e incluye la dirección IP del UE.
11. La CRF/PDF responde con
"IP-address-not-served".
12. El AF envía el mensaje Gq/Rx a la CRF/PDF
secundaria.
13. La dirección IP del UE recibe servicio de la
CRF/PDF. La CRF/PDF responde al AF con éxito. Tanto el GGSN como el
AF llevan a la misma CRF/PDF y la sesión de aplicación puede
continuar.
La invención puede emplearse especialmente en
aplicaciones para implementaciones de GGSN/AF, con el fin de
garantizar la selección/nueva selección de una CRF/PDF (Charging
Rule Function/Policy decision Function Charging [Función
relacionada con la carga/función de decisión de directiva]) adecuada
y poner a disposición un manejo de errores adecuado.
\vskip1.000000\baselineskip
La lista de referencias citada por el
solicitante lo es solamente para utilidad del lector, no formando
parte de los documentos de patente europeos. Aún cuando las
referencias han sido cuidadosamente recopiladas, no pueden
excluirse errores u omisiones y la OEP rechaza toda responsabilidad
a este respecto.
WO 2004100466 A (0006)
Claims (18)
1. Procedimiento para imponer directivas
adecuadas para el tráfico de datos en un sistema de
radiocomunicación, que comprende al menos un equipo terminal móvil
(UE) y al menos una red de servicios (IMS) con al menos un nodo de
entrada y al menos una unidad de directivas (CRF/PDF) y al menos un
elemento de aplicación (AF), caracterizado porque en la
unidad de directivas (CRF/PDF) se almacena al menos una parte
(dirección IP, MSISDN) de los datos de usuario de los usuarios a
los que presta servicio la unidad de directivas (CRF/PDF), para su
utilización en una comprobación de competencia de la unidad de
directivas (CRF/PDF).
2. Procedimiento según la reivindicación 1,
caracterizado porque en la unidad de directivas (CRF/PDF), al
recibirse una petición de conexión de una unidad del sistema de
comunicación (GGSN, AF), se realiza una comparación en cuanto a los
datos de usuario almacenados (dirección IP, MSISDN) para verificar
si la unidad de directivas (CRF/PDF) presta servicio al usuario al
que se refiere la petición de conexión actual.
3. Procedimiento según la reivindicación 2,
caracterizado porque, en función del resultado de la
comparación, se envía al menos a la unidad que efectúa la petición
(GGSN, AF) un mensaje de respuesta adecuado.
4. Procedimiento según una de las
reivindicaciones 1 a 3, caracterizado porque el nodo de red
de entrada (GGSN) tiene asignada una tabla de selección para una
unidad de directivas (CRF/PDF), que incluye al menos una entrada de
una unidad de directivas (CRF/PDF).
5. Procedimiento según la reivindicación 4,
caracterizado porque la entrada de la tabla de selección para
una unidad de directivas representa una dirección de unidad de
directivas.
6. Procedimiento según una de las
reivindicaciones 1 a 5, caracterizado porque en al menos un
elemento (AF) de la red de servicios (IMS) está almacenada una
tabla de selección para una unidad de directivas.
7. Procedimiento según la reivindicación 6,
caracterizado porque la tabla de selección para una unidad de
directivas almacenada en el elemento (AF) de la red de servicios
(IMS) es idéntica a la tabla de selección para una unidad de
directivas almacenada en el, al menos uno, nodo de red de entrada
(GGSN).
8. Procedimiento según las reivindicaciones 3 a
7, caracterizado porque la unidad que efectúa la petición
(GGSN, AF), al recibir un mensaje de respuesta negativo
("demasiado ocupado", "dirección IP no atendida"), envía
una petición a una unidad de directivas (CRF/PDF) alternativa,
seleccionada de acuerdo con una identidad de usuario y la tabla de
selección para una unidad de directivas.
9. Procedimiento según una de las
reivindicaciones 4 a 8, caracterizado porque las entradas de
la tabla de selección para una unidad de directivas están asignadas
a un grupo de equipos terminales móviles (UE).
10. Procedimiento según una de las
reivindicaciones 4 a 9, caracterizado porque las entradas de
la tabla de selección para una unidad de directivas se asignan
dinámicamente a un equipo terminal móvil (UE).
11. Procedimiento según una de las
reivindicaciones 1 a 10, caracterizado porque la dirección IP
o el número MSISDN (número RDSI de abonado móvil) del equipo
terminal móvil (UE) sirve de datos de usuario.
12. Procedimiento según una de las
reivindicaciones 10 u 11, caracterizado porque, para la
selección dinámica de una unidad de directivas (CRF/PDF), se
realiza una consulta con una ventana que comprende al menos dos
entradas de la tabla de selección para una unidad de directivas.
13. Procedimiento según la reivindicación 12,
caracterizado porque la ventana se determina mediante una
división módulo de los datos de usuario y el número de entradas en
la lista de la tabla de selección para una unidad de
directivas.
14. Procedimiento según una de las
reivindicaciones 1 a 13, caracterizado porque en la unidad de
directivas están almacenadas directivas de tarificación y/o
directivas de calidad de servicio para tráfico de datos y
aplicaciones.
15. Sistema para imponer directivas adecuadas
para el tráfico de datos en un sistema de radiocomunicación, que
comprende al menos un equipo terminal móvil (UE) y al menos una red
de servicios (IMS) con al menos un nodo de red de entrada (GGSN) y
al menos una unidad de directivas (CRF/PDF) y al menos un elemento
de aplicación (AF), caracterizado porque la unidad de
directivas presenta una unidad de memoria en la que, al establecerse
una conexión con un equipo terminal móvil (UE), se almacena al
menos una parte de los datos de usuario del equipo terminal móvil
(UE) para su utilización en una comprobación de competencia de la
unidad de directivas (CRF/PDF).
16. Sistema según la reivindicación 15,
caracterizado porque la unidad de directivas (CRF/PDF)
comprende al menos una unidad de comparación, que puede comparar
los datos de usuario recibidos con datos de usuario
almacenados.
\newpage
17. Sistema según una de las reivindicaciones 15
ó 16, caracterizado porque al menos en el nodo de red de
entrada (GGSN) está almacenada una tabla de selección para una
unidad de directivas (CRF/PDF).
18. Sistema según una de las reivindicaciones 15
a 17, caracterizado porque está diseñado para la realización
del procedimiento según una de las reivindicaciones 1 a 14.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102005014480 | 2005-03-30 | ||
| DE102005014480A DE102005014480A1 (de) | 2005-03-30 | 2005-03-30 | Verfahren und System zur Durchsetzung geeigneter Richtlinien für Datenverkehr in einem Funk-Kommunikationssystem |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2320368T3 true ES2320368T3 (es) | 2009-05-21 |
Family
ID=36581879
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06006444T Active ES2320368T3 (es) | 2005-03-30 | 2006-03-28 | Procedimiento y sistema para imponer directivas adecuadas al trafico de datos en una red de comunicacion inalambrica. |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1708434B1 (es) |
| AT (1) | ATE415760T1 (es) |
| DE (2) | DE102005014480A1 (es) |
| ES (1) | ES2320368T3 (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008083621A1 (fr) * | 2007-01-09 | 2008-07-17 | Huawei Technologies Co., Ltd. | Procédé et système de traitement de flux de service ainsi que procédé et système d'association d'une prise en charge |
| CN101222413B (zh) * | 2007-01-09 | 2012-05-23 | 华为技术有限公司 | 业务流程中的处理方法及系统 |
| CN101472301B (zh) * | 2007-12-27 | 2012-04-25 | 华为技术有限公司 | 一种业务流授权关联的方法和装置 |
| CN106688256B (zh) | 2014-10-08 | 2019-10-25 | 华为技术有限公司 | 一种背景流量下载方法、设备及系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7826353B2 (en) * | 2003-05-05 | 2010-11-02 | Nokia Corporation | Method, system and network element for authorizing a data transmission |
-
2005
- 2005-03-30 DE DE102005014480A patent/DE102005014480A1/de not_active Withdrawn
-
2006
- 2006-03-28 EP EP06006444A patent/EP1708434B1/de active Active
- 2006-03-28 AT AT06006444T patent/ATE415760T1/de active
- 2006-03-28 DE DE502006002155T patent/DE502006002155D1/de active Active
- 2006-03-28 ES ES06006444T patent/ES2320368T3/es active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP1708434A1 (de) | 2006-10-04 |
| DE502006002155D1 (de) | 2009-01-08 |
| EP1708434B1 (de) | 2008-11-26 |
| ATE415760T1 (de) | 2008-12-15 |
| DE102005014480A1 (de) | 2006-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5158387B2 (ja) | サーバー発見を実行するメカニズム | |
| US9661082B2 (en) | Token related apparatuses for deep packet inspection and policy handling | |
| ES2235065T3 (es) | Metodo y sistema para gestionar multiples registros. | |
| US8041837B2 (en) | Method and devices for filtering data packets in a transmission | |
| ES2360110T3 (es) | Método y dispositivos para instalar filtros de paquetes en una transmisión de datos. | |
| US9560162B2 (en) | Quality of service support for machine-to-machine applications including e-health | |
| ES2744824T3 (es) | Encaminador de Diameter de IMS con equilibrio de carga | |
| US9438522B2 (en) | Service processing method and system, and policy control and charging rules function | |
| ES2619423T3 (es) | Método, aparatos y programa informático para configurar dinámicamente una función de control de sesión de llamada proxy del subsistema multimedia IP desde un servidor de reglas de control de política | |
| US8195811B2 (en) | Policy co-ordination in a communications network | |
| ES2374089T3 (es) | Método y aparato para su uso en una red de comunicaciones. | |
| TWI423634B (zh) | 用於通訊系統遞交期間轉換資訊的方法 | |
| ES2401301T3 (es) | Método y aparato para su uso en una red de comunicaciones | |
| US8126459B2 (en) | Controlling registration in a communication system | |
| US7136635B1 (en) | Proxy SIP server interface for session initiation communications | |
| BRPI0810914B1 (pt) | método de controle de política em uma rede, aparelho que opera para agir como uma entidade de função de aplicativo, método de operação de aparelho e aparelho para operar como uma entidade de função de aplicativo, método de operação de um aparelho para operar como uma entidade de controle de política e sistema de controle de política | |
| US9992239B2 (en) | Method and apparatus for an I-CSCF to assign to a user equipment a S-CSCF server in an IMS system | |
| ES2320368T3 (es) | Procedimiento y sistema para imponer directivas adecuadas al trafico de datos en una red de comunicacion inalambrica. | |
| CN110140368A (zh) | 在长期演进(lte)或后代网络中提供端到端优先级服务的方法、系统和计算机可读介质 | |
| US10326604B2 (en) | Policy and charging rules function (PCRF) selection | |
| JP5841468B2 (ja) | ＶｏＬＴＥサービスの通信規制方法およびシステム | |
| ES2322283T3 (es) | Aplicacion de directrices apropiadas para el trafico de datos en un sistema de radiocomunicacion. | |
| KR100462026B1 (ko) | 이동 멀티미디어 서비스를 위한 프록시 서버 장치 및폴리시 제어 방법 |