ES2700970T3 - Agregación de información de congestión - Google Patents

Agregación de información de congestión Download PDF

Info

Publication number
ES2700970T3
ES2700970T3 ES17166093T ES17166093T ES2700970T3 ES 2700970 T3 ES2700970 T3 ES 2700970T3 ES 17166093 T ES17166093 T ES 17166093T ES 17166093 T ES17166093 T ES 17166093T ES 2700970 T3 ES2700970 T3 ES 2700970T3
Authority
ES
Spain
Prior art keywords
pcrf
message
congestion
rcaf
congestion information
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
Application number
ES17166093T
Other languages
English (en)
Inventor
György Miklos
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 ES2700970T3 publication Critical patent/ES2700970T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/41—Flow control; Congestion control by acting on aggregated flows or links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/18—Commands or executable codes
    • 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/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0205—Traffic management, e.g. flow control or congestion control at the air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0247—Traffic management, e.g. flow control or congestion control based on conditions of the access network or the infrastructure network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método de envío en una Función de Conciencia de Congestión de Red de Acceso vía Radio, RCAF (200), para enviar, a una Función de Políticas y Reglas de Cargas, PCRF (100, 100-1 - 100-3), de una red (1) de comunicaciones móviles, información (415) de congestión para una pluralidad de entidades móviles, UE (400-5 1 - 400-8), estando conectado cada uno de la pluralidad de UE (400-1 - 400-8) a una red (10) de acceso vía radio respectiva de la red (1) de comunicaciones móviles y asociado con la PCRF (100, 100-1 - 100-3), indicando la información (415) de congestión la congestión de la red (10) de acceso vía radio respectiva, comprendiendo el método: - enviar un mensaje (501) de solicitud para transmitir información de congestión de una UE (400-1 - 400-8) dado a una PCRF (100, 100-1 - 100-3), incluyendo información (415) de congestión y una identidad (414) de la UE (400-1 - 400-8) dado de la pluralidad de UEs (400-1 - 400-8), en donde el mensaje (501) de solicitud es encaminado por un Agente de Encaminamiento Diameter, DRA (600) a la PCRF (100, 100-1 - 100-3), y - recibir un mensaje (502) de respuesta que incluye una identidad (413) de la PCRF (100, 100-1 - 100-3) asociada con la UE (400-1 - 400-8) dado, - agregar la información (415) de congestión para al menos alguno de la pluralidad de UE (400-1 - 400-8) basado en las UEs (400-1 - 400-8) respectivos que están asociados con la PCRF (100, 100-1 - 100-3), y - enviar un mensaje (411-1 - 411-3) que incluye la información (415) de congestión agregada a la PCRF (100, 100-1 - 100-3), en donde dicho envío del mensaje (411-1 - 411-3) emplea la identidad (413) recuperada de la PCRF (100, 100-1 - 100-3) para encaminar el mensaje (411-1 - 411-3) a la PCRF (100, 100-1 - 100-3).

Description

DESCRIPCIÓN
Agregación de información de congestión
Campo técnico
La aplicación se refiere a técnicas de envío de información de congestión agregada desde una unidad de monitorización de la congestión a un controlador de políticas de una red de comunicaciones móviles. La aplicación se refiere además a un programa informático, a un producto del programa informático y a un soporte correspondiente que contiene el programa informático.
Antecedentes
El tráfico de paquetes de datos está creciendo muy rápidamente en las redes de comunicaciones móviles o redes de operadores móviles; en muchos casos, crece más rápido que una tasa a la que los operadores pueden ampliar su capacidad de red. Esto conduce a apariciones más frecuentes de congestión de una red de acceso vía radio (RAN). La congestión puede ocurrir cuando el tráfico de datos excede una capacidad de tráfico de datos de la RAN. También, aparecen nuevos servicios que pueden conducir a una situación en la que se debe introducir un nuevo requisito de Calidad de la Experiencia en la red. En esta situación, los operadores necesitan herramientas eficientes y flexibles para que puedan controlar el compartir el cuello de botella de la capacidad de la RAN para incrementar la Calidad de la Experiencia.
Recientemente, en el contexto del elemento de trabajo de gestión de la congestión del plano de Usuario (UPCON) del Proyecto de Asociación de Tercera Generación (3GPP), se ha presentado una nueva solución que utiliza la retroalimentación de la congestión de la RAN a la CN (Red Central), véase el Informe Técnico (TR) 23.705 del 3GPP, versión 0.10.0 de mayo del 2014, sección 6.1. Cuando la RAN indica congestión a la CN, la CN puede tomar medidas para mitigar la congestión, como limitar algunas clases de tráfico o solicitar retrasar algunas otras clases de tráfico.
Los sistemas de Operación y Mantenimiento (OAM) de la RAN normalmente proporcionan información basándose en que un operador puede derivar cuando se produce la congestión. Tal información puede incluir, por ejemplo, una cantidad de pérdida de paquetes, de retraso de paquetes, de rendimiento del tráfico, de utilización de la interfaz aérea, un número de usuarios conectados, un número de usuarios conectados con memorias temporales no vacías, etc. Un operador puede configurar umbrales en una de estas métricas o en una combinación de estas métricas para determinar cuándo se considera un estado de congestión, es decir, cuando la congestión se hace significativa. También es posible para un operador definir múltiples niveles de congestión utilizando una combinación de estas métricas de modo que las medidas para la mitigación de la congestión puedan basarse en el nivel de congestión.
Los sistemas actuales de OAM de la RAN operan en un nivel por celda o incluso en granularidad espacial inferior. Es decir, determinar la congestión puede realizarse en una base por celda o puede realizarse para un grupo de celdas, como las celdas pertenecientes al mismo eNodoB (Nodo B evolucionado) para las redes de comunicaciones móviles según el estándar de Evolución a Largo Plazo (LTE) según lo especificado por el 3GPP, o las celdas pertenecientes a la misma Área de Servicio para las redes de comunicaciones móviles según el estándar del Sistema Universal de Telecomunicaciones Móviles (UMTS) según lo especificado por el 3GPP. Para que la CN adopte una medida de mitigación apropiada, la CN normalmente necesita determinar que entidades móviles (UEs) están situadas en una celda dada. Por lo tanto, necesita determinarse la lista de UEs afectados para las celdas que se consideran congestionadas basándose en los datos de OAM.
Se documenta una solución para la información de congestión basada en OAM en la solución 1.5.5 (también llamada solución fuera de trayecto) en la sección 6.1.5.5 del TR 23.705 del 3GPP, versión 0.10.0 de mayo del 2014 que sugiere la interfaz Nq para este propósito. Se define la interfaz Nq entre una entidad de red denominada Función de Conciencia de Congestión de la RAN (RCAF) y la Entidad de Gestión de la Movilidad (MME). La RCAF recibe un informe de congestión que incluye los datos relacionados con la congestión de la RAN del sistema de OAM de la RAN en una granularidad espacial por celda o en una granularidad inferior. Entonces, utilizando la interfaz Nq, la RCAF consulta a la MME para suministrar la lista de UEs por celda.
Se sugiere un enfoque similar para el caso de UMTS, utilizando la interfaz Nq' desde la RCAF al Nodo de Soporte del Servicio GRPS (SGSN). Sin embargo, hay una diferencia para UMTS dado que la RAN ya puede ser consciente de las identidades de los UEs como, por ejemplo, la Identidad Internacional del Abonado Móvil (IMSI) puede ser enviada al Controlador de la Red de Radio (Rn C). El OAM de la RAN recoge estos IMSIs y luego el Oa M de la RAN suministra la lista de UEs identificados por la IMSI que están afectados por la congestión a la RCAF. Por lo tanto, en tal escenario UMTS, la lista de UEs afectados por la congestión es conocida por la RCAF sin contactar al SGSN sobre la interfaz Nq'.
Una vez que el nodo de la RCAF ha recogido la información sobre el conjunto de UEs afectados por la congestión, notifica a la Función de Políticas y Reglas de Carga (PCRF) sobre el nivel de congestión de los UEs afectados enviando la información de congestión. Aquí, los UEs se pueden identificar por un identificador del UE como la IMSI. La interfaz Np se define entre la RCAF y la PCRF para este propósito. Según lo descrito en el TR 23.705 del 3GPP, versión 0.10.0 de mayo del 2014, sección 6.1.6, la PCRF puede entonces tomar medidas para mitigar la congestión, por ejemplo, limitar el tráfico en un nodo de ejecución como una Pasarela de la Red de Paquetes de Datos (PGW) o una Función de Detección de Tráfico (TDF), o notificar a la Función de Aplicación (AF) para limitar o retrasar el tráfico, etc.
La contribución del 3GPP S2-131610 de China Telekom et. al. “RPPF based Solution for Operator Controlled Offpath Congestion Awareness and Notification” en la conferencia #S2-97 del SA WG2, del 27 al 31 de mayo del 2013, propone una solución para la conciencia de congestión del plano de usuario de la RAN introduciendo una nueva función lógica RPPF que interactúa con la MME/SGSN para recoger la información de congestión de la RAN y además informar/notificar a la PCRF para proporcionar conciencia de la congestión.
Las técnicas actuales normalmente requieren un número comparativamente grande de mensajes que incluyen la información de congestión a enviar desde la RCAF a la PCRF a través de la interfaz Np. Esto puede producir, por sí mismo, un tráfico significativo en la interfaz Np. En el caso de que una celda dada se congestione, normalmente un mayor número de UEs conectados a esta celda se ven afectados por la congestión; a su vez, un estado de congestión para este número de UEs normalmente cambia en conjunto. Por lo tanto, un tráfico de señalización excesivo en la interfaz Np puede resultar, que requiere actualizaciones caras y complejas de la PCRF y/o de la RCAF, para manejar tales situaciones. Una señalización excesiva en la interfaz Np puede hacer que el funcionamiento de la red de comunicaciones móviles sea inestable, especialmente cuando una parte significativa de la red de comunicaciones móviles sufre de congestión.
Compendio
Por lo tanto, hay una necesidad de técnicas avanzadas de señalización de la información de congestión. En particular, hay una necesidad de tales técnicas de señalización de la información de congestión que impongan cantidades comparativamente pequeñas de tráfico en la interfaz respectiva.
De acuerdo con un aspecto, se ha proporcionado un método de envío en una Función de Conciencia de Congestión de Red de Acceso vía Radio, RCAF, a una Función de Políticas y Reglas de Carga, PCRF, de una red de comunicaciones móviles, información de congestión para una pluralidad de entidades móviles, UEs. Estando cada una de la pluralidad de UEs conectada a una red de acceso vía radio respectiva de la red de comunicaciones móviles y asociada con la PCRF. La información de congestión indica la congestión de la red de acceso vía radio respectiva. El método comprende enviar un mensaje de solicitud para transmitir información de congestión desde una UE dada a una PCRF, que incluye información de congestión y una identidad de la UE dada de la pluralidad de UEs, en donde el mensaje de solicitud es encaminado por un Agente de Encaminamiento de Diameter, d Ra a la PCRF. El método comprende además recibir un mensaje de respuesta que incluye una identidad de la PCRF asociada con la UE dada. El método comprende además agregar la información de congestión para al menos alguna de la pluralidad de UE basada en las UEs respectivas que están asociadas con la PCRF, y enviar un mensaje que incluye la información de congestión agregada a la PCRF, en donde dicho envío del mensaje emplea la identidad recuperada de la PCRF para encaminar el mensaje a la PCRF.
De acuerdo con un aspecto adicional, se ha proporcionado una Función de Conciencia de Congestión de Red de Acceso vía Radio, RCAF. La RCAF está configurada para enviar, a una Función de Políticas y reglas de Cargas, PCRF, de una red de comunicaciones móviles, información de congestión para una pluralidad de entidades móviles, UEs. Cada una de la pluralidad de UEs está conectada a una red de acceso vía radio respectiva de la red de comunicaciones móviles y asociada con la PCRF. La información de congestión indica la congestión de la red de acceso vía radio respectiva. La RCAF comprende un procesador configurado para agregar la información de congestión para al menos alguna de la pluralidad de UEs basado en las UEs respectivas que están asociadas con la PCRF. La RCAF comprende además un procesador configurado para controlar una interfaz para enviar un mensaje de solicitud para transmitir información de congestión de una entidad móvil dada a una PCRF que incluye información de congestión y la identidad de la UE dada de la pluralidad de UEs a un Agente de Encaminamiento de Diameter, DRA. El mensaje de solicitud es encaminado por el DRA a la PCRF. El procesador está además configurado para controlar la interfaz para recibir, desde el DRA, un mensaje de respuesta que incluye una identidad de la PCRF asociada con la UE dada. La RCAF comprende además una interfaz configurada para enviar un mensaje que incluye la información de congestión agregada a la PCRF. La interfaz está además configurada para enviar el mensaje empleando la identidad recuperada de la PCRF para encaminar el mensaje a la PCRF.
De acuerdo con un aspecto adicional, se ha proporcionado un método en una Función de Políticas y Reglas de Cargas, PCRF, para recibir información de congestión para una pluralidad de entidades móviles, UE, desde una Función de Conciencia de Congestión de Redes de Acceso vía Radio, RCAF, de una red de comunicaciones móviles. Cada una de la pluralidad de UEs está conectada a una red de acceso vía radio respectiva de la red de comunicaciones móviles y asociada con una PCRF. La información de congestión indica la congestión de la red de acceso vía radio respectiva. El método comprende recibir un mensaje de solicitud procedente de la RCAF para transmitir la información de congestión de una UE dada a la PCRF, encaminado por un Agente de Encaminamiento de Diameter, DRA. El mensaje de solicitud incluye información de congestión y una identidad para la UE dada. El método comprende además en respuesta a dicha recepción del mensaje de solicitud, el envío de un mensaje de respuesta que incluye una identidad de la PCRF, y la recepción, desde la RCAF de un mensaje que incluye la información de congestión agregada para al menos alguna de la pluralidad de UE asociada con la PCRF.
De acuerdo con un aspecto adicional, se ha proporcionado una Función de Políticas y Reglas de Cargas, PCRF. La PCRF está configurada para recibir información de congestión para una pluralidad de entidades móviles, UE, procedente de una Función de Conciencia de Congestión de Red de Acceso vía Radio, RCAF. Cada una de la pluralidad de UE está conectada a una red de acceso vía radio respectiva de la red de comunicaciones móviles, indicando la información de congestión la congestión de la red de acceso vía radio respectiva. La PCRF comprende una interfaz configurada para recibir un mensaje de solicitud procedente de la RCAF, encaminado por un Agente de Encaminamiento de Diameter, DRA. El mensaje de solicitud es para transmitir la información de congestión de una UE dada a una PCRF, incluyendo la información de congestión y una identidad de la UE dada, en el que, en respuesta a dicha recepción del mensaje de solicitud. La interfaz está configurada además para enviar un mensaje de respuesta que incluye una identidad de la PCRF y para recibir un mensaje procedente de la RCAF, incluyendo el mensaje información de congestión agregada para al menos alguna de la pluralidad de UE asociada con la PCRF.
Los detalles de tales realizaciones y de realizaciones adicionales serán evidentes a partir de la siguiente descripción detallada de las realizaciones.
Breve descripción de los dibujos
La Figura 1 muestra una realización de una arquitectura de sistema que incorpora las características de la invención incluyendo una RCAF y una PCRF que interactúan para indicar la información de congestión. La Figura 2 ilustra esquemáticamente una realización de la PCRF con mayor detalle.
La FIGURA 3 ilustra esquemáticamente una realización de un Agente de Encaminamiento de Diámetro (DRA) que puede facilitar la interacción de la RCAF y de la PCRF.
La FIGURA 4 ilustra esquemáticamente una realización de la RCAF con mayor detalle.
La FIGURA 5 ilustra una realización de una pluralidad de UEs, cada UE estando asociado con una de una pluralidad de PCRFs, y además ilustra una realización de un mensaje que incluye la información de congestión para al menos alguno de los UEs asociados con una PCRF dada.
La FIGURA 6 es un diagrama de señalización que ilustra una realización de la señalización de un mensaje que incluye la información de congestión agregada entre la RCAF y la PCRF.
La FIGURA 7 es un diagrama de señalización que ilustra una realización de la señalización de un mensaje que incluye la información de congestión agregada entre la RCAF y la PCRF, siendo facilitada la señalización por el DRA.
La FIGURA 8 es un diagrama de flujo de un método de envío de un mensaje según varias realizaciones. La FIGURA 9 es un diagrama de flujo de un método de recepción de un mensaje según varias realizaciones. La FIGURA 10 es un diagrama de flujo de un método de proporción de la identidad de una PCRF según varias realizaciones.
Descripción detallada
En lo que sigue, los conceptos según las realizaciones se explicarán con mayor detalle haciendo referencia a los dibujos adjuntos. Los conceptos ilustrados se refieren a técnicas de envío de la información de congestión agregada. Específicamente, los conceptos se refieren al envío de un mensaje desde una unidad de monitorización de la congestión de una red de comunicaciones móviles a una unidad de control de políticas de una red de comunicaciones móviles, incluyendo el mensaje la información de congestión agregada. La red de comunicaciones móviles puede, por ejemplo, estar basada en la tecnología LTE especificada por el 3GPP y en una información de congestión basada en OAM según lo descrito en el TR 23.705 del 3GPP de mayo del 2014, sección 6.1.5.5. Sin embargo, se debe entender que la red de comunicaciones móviles podría implementar también otras tecnologías, por ejemplo, UMTS o el Sistema Global para la Comunicación Móvil (GSM) en conexión con el Servicio General de Paquetes vía Radio (GPRS).
En los conceptos como se ilustra en lo que sigue, una unidad de monitorización de la congestión envía información de congestión agregada a una unidad de control de políticas de la red de comunicaciones móviles. La información de congestión agregada puede indicar un nivel de congestión para una pluralidad de UEs que están asociados con la unidad de control de políticas. Por ejemplo, el nivel de congestión puede indicarse en una base por UE o puede indicarse para un grupo de UEs. La unidad de control de políticas controla la implementación de políticas para el tráfico de datos hacia y desde los UEs asociados con ella. Es posible que la ejecución de las políticas de la unidad de control de políticas se base en la información de congestión recibida.
Mediante tales técnicas, se hace posible reducir una cantidad del tráfico de señalización en una interfaz respectiva entre la unidad de monitorización de la congestión y la unidad de control de políticas, es decir, en el caso de la tecnología LTE la interfaz Np entre una RCAF y una PCRF. En particular, dado que es posible incluir la información de congestión para una pluralidad de UEs en un único mensaje (agregación), es posible reducir el tráfico de señalización aproximadamente por la relación de agregación, es decir, un número de piezas de información de congestión por mensaje. Además, la sobrecarga necesaria para la señalización de la información de congestión puede reducirse reutilizando una cabecera de datos del mensaje para una pluralidad de piezas de información de congestión cuando se agregan.
La Figura 1 muestra una arquitectura de una red 1 de comunicaciones móviles según la tecnología LTE en la que una unidad de monitorización de la congestión, en la forma de una RCAF 200, determina los niveles de congestión de los UEs (no mostrados en la FIGURA 1) en una RAN 10. La RCAF 200 es capaz de determinar una congestión del plano de usuario de la RAN que se produce cuando la demanda de recursos de la RAN excede la capacidad disponible de la RAN para suministrar datos del usuario por un período de tiempo. La congestión del plano de usuario de la RAN puede conducir, entre otros, a caídas o retrasos de paquetes. La RCAF 200 normalmente recupera un informe de congestión sobre el estado de funcionamiento del plano de usuario de la RAN en curso a nivel de celda de la unidad 11 de OAM de la RAN; este informe de congestión es normalmente analizado y evaluado antes de reportarlo como información de congestión a una unidad de control de políticas implementada en el escenario de la FIGURA 1 como una PCRF 100. Para la comunicación de la información de congestión entre la RCAF 200 y la PCRF 100, se proporciona la interfaz Np.
Es posible implementar y facilitar la comunicación entre la RCAF 200 y la PCRF 100 a través de una entidad de base de datos de encaminamiento (no mostrada en la FIGURA 1) como un Agente de Encaminamiento de Diámetro (DRA). Tales técnicas permiten enviar un mensaje, por ejemplo, de la RCAF 200 a la PCRF 100, a través del DRA empleando un nombre lógico de la PCRF 100 en lugar de una dirección del Protocolo de Internet (IP) y/o un nombre del Sistema de Nombres de Dominio (DNS) de la PCRF 100. Sin embargo, es posible que la RCAF 200 recupere una identidad de la PCRF 100, en donde la identidad de la PCRF 100 es al menos una de la dirección IP o del nombre de DNS. Alternativamente o adicionalmente, es entonces posible enviar un mensaje que incluye la información de congestión agregada de la RCAF 200 a la PCRF 100 encaminando directamente el mensaje a la PCRF 100, es decir, haciendo innecesario emplear el DRA.
La RCAF 200 está además conectada a través de una interfaz Nq a la MME. En el caso de la tecnología UMTS (no mostrada en la FIGURA 1), la RCAF 200 está conectada a través de la interfaz Nq' al SGSN 20. Los datos del plano de usuario para los cuales se controla la congestión se transmiten desde la RAN 10 a través de una pasarela 30 de servicio (SGW) que encamina y envía los paquetes de datos de usuario a una pasarela 40 de la Red de Paquetes de Datos (PDN GW o PGW). Desde la PDN gW 40, los datos de usuario se transmiten a través de una TDF 50 a la Red 60 de Paquetes de Datos (PDN). Esto corresponde a la dirección del enlace ascendente. También es posible que los datos de usuario se transmitan en la dirección del enlace descendente, es decir, hacia la RAN 10.
La siguiente descripción se centra en la RCAF 200 y la PCRF 100 y la interacción entre la RCAF 200 y la PCRF 100. La RCAF 200 utiliza un informe de congestión proporcionado por la 11 de OAM de la RAN que incluye información tal como la cantidad de pérdida de paquetes de datos, de retraso de paquetes, de rendimiento del tráfico, de utilización de la interfaz aérea o el número de usuarios conectados para determinar, por ejemplo, basándose en umbrales que se pueden configurar, un estado de congestión de un área determinada. La RCAF 200 determina que UEs están afectados por un estado de congestión en un área determinada utilizando la información proporcionada por la MME 20.
En la FIGURA 1, se muestra una única PCRF 100. Sin embargo, puede haber una pluralidad de PCRFs 100 en la red 1 de comunicaciones móviles. Una RCAF 200 dada puede ser capaz de comunicarse selectivamente con una dada de una pluralidad de PCRFs 100. Normalmente, un UE dado está estáticamente asociado con/asignado a una PCRF 100 particular que actúa como un anclaje de la movilidad para el UE dado. La PCRF 100 maneja una sesión de la Red de Acceso de Conectividad IP (IP CAN) del UE dado. La PCRF 100 implementa las políticas de manejo del tráfico de datos para los UEs asociados controlando la TDF 50 y/o la PDN GW 40 que implementan una Función de Ejecución del Control de Políticas (PCEF) a través de las interfaces Sd y Gx, respectivamente.
En general, es posible que un UE dado esté asociado con una única PCRF. También es posible, que un UE dado esté asociado con una pluralidad de PCRFs 100. Por ejemplo, el UE dado puede tener múltiples conexiones de PDN a diferentes PDNs 60 (no mostrados en la FIGURA 1). Las PDNs pueden identificarse por sus Nombres del Punto de Acceso (APNs). Para cada APN, en general, es posible que haya una PCRF 100 diferente. Por ejemplo, un UE puede estar simultáneamente conectado a una primera p Dn y a una segunda PDN, en donde la primera PDN 60 está identificada por un primer APN y en donde la segunda p Dn 60 está identificada por un segundo APN. Para el tráfico de datos entre el UE y la primera PDN 60, el UE puede asociarse con una primera PCRF 100. Para el tráfico de datos entre el UE y la segunda PDN 60, el UE puede asociarse con una segunda PCRF 100.
La RCAF 200 se configura para agregar la información de congestión para al menos alguno de una pluralidad de UEs basada en los respectivos UEs que están asociados con la PCRF 100. Es decir, la información de congestión relativa a un nivel de congestión de un UE dado asociado con una PCRF 100 dada (con una PCRF diferente de la PCRF 100 dada), se incluye (se excluye) de la agregación en un mensaje dado. La RCAF 200 envía entonces el mensaje que incluye la información de congestión agregada a la PCRF 100. La PCRF 100 se configura para recibir el mensaje de la RCAF 200, incluyendo el mensaje la información de congestión agregada para una pluralidad de UEs asociados con la PCRF 100. La PCRF 100 puede responder con un mensaje de resultado. En el mensaje de resultado, es posible dar un único código de éxito o de error para un mensaje completo que incluye la información de congestión agregada. Alternativamente o adicionalmente, los códigos de éxito o de error se pueden dar individualmente para cada información de congestión incluida en el mensaje.
Es posible que el mensaje y/o el mensaje de resultado se codifiquen según el protocolo de Diámetro, véase la Solicitud Para Cambios (RFC) 6733 del Grupo de Trabajo de Ingeniería de Internet (IETF).
Enviando el mensaje que incluye la información de congestión agregada, el tráfico de datos en la interfaz Np se puede reducir. En particular, no es necesario enviar un único mensaje para cada información de congestión para cada UE. Recogiendo la información de congestión para una pluralidad de UEs que están todos asignados a una y la misma PCRF 100, se hace posible reducir una relación de sobrecarga por señalización, reduciendo así aún más el tráfico impuesto en la interfaz NP, y reduciendo los requisitos de procesamiento en los nodos de la PCRF y de la RCAF.
Para implementar efectivamente la agregación de información de congestión, normalmente tanto la RCAF 200 como la PCRF 100, necesitan soportar los esquemas de agregación respectivos. Puede ser posible que la arquitectura de la red 1 de comunicaciones móviles incluya la agregación de información de congestión como una característica opcional. En un escenario simple, la PCRF 100 y/o la RCAF 200 pueden confiar en una configuración local predefinida de las capacidades de la otra unidad respectiva para determinar si la agregación de información de congestión está soportada o no; el envío del mensaje que incluye la información de congestión agregada puede entonces ser selectivamente ejecutado dependiendo de esta configuración local. Sin embargo, puede ser deseable implementar técnicas de negociación entre la RCAF 200 y la PCRF 100 para establecer dinámicamente un apretón de manos allí entre las capacidades de indicación de agregación de mensajes. Para facilitar la negociación de la capacidad, la RCAF 200 puede indicar, por ejemplo, mediante un indicador o de otra manera, en un mensaje de control de la RCAF 200 a la PCRF 100 que la agregación de información de congestión está soportada. Alternativamente o adicionalmente, la PCRF 100 puede indicar, por ejemplo, mediante un indicador o de otra manera, en un mensaje de control de la PCRF 100 a la RCAF 200 si está soportada o no la agregación de información de congestión; es posible incluir la identidad de la PCRF 100 en dicho mensaje de control facilitando el encaminamiento directo de mensajes adicionales de la RCAF 200 a la PCRF 100. Generalmente, la negociación de la agregación de información de congestión puede ser activada por la PCRF 100 y/o la RCAF 200. De tal manera, la PCRF 100 y la RCAF 200 pueden ser notificadas si el otro nodo respectivo 100, 200 soporta la agregación de información de congestión y, por ejemplo, aplicar selectivamente la agregación de información de congestión únicamente cuando ambos nodos indican el soporte.
Es posible negociar parámetros de agregación adicionales - más allá de la mera capacidad para soportar la agregación de información de congestión - entre la PCRF 100 y la RCAF 200. Por ejemplo, es posible que la RCAF 200 y la PCRF 100 negocien al menos uno de una latencia o de un tamaño máximo de un mensaje que incluye la información de congestión agregada. Por ejemplo, es posible que se limite un tamaño máximo del mensaje que incluye la información de congestión agregada - respectivamente un número máximo de información de congestión por mensaje - en la RCAF 200 y/o la PCRF 100, por ejemplo, debido a restricciones técnicas o consideraciones de tráfico. Esto pude imponer una limitación cuando la RCAF 200 agrega la información de congestión; la agregación debe ser abortada una vez que se ha alcanzado el tamaño máximo. En un escenario simple, es posible que el tamaño máximo del mensaje esté estáticamente pre-configurado en la RCAF 200. También, no obstante, es posible que la PCRF 100 indique el tamaño máximo del mensaje explícitamente o implícitamente a la RCAF 200. Esta indicación puede hacerse como parte de la negociación, respectivamente el apretón de manos entre la RCAF 200 y la PCRF 100. Si, por ejemplo, los tamaños máximos de mensaje soportados difieren entre la PCRF 100 y la RCAF 200, la RCAF 200 debe emplear la limitación más estricta.
Para reducir aún más el tráfico de señalización impuesto en la interfaz Np, es posible que la RCAF 200 emplee esquemas de compresión antes de enviar la información de congestión agregada a la PCRF 100. Esto puede reducir el tamaño del mensaje que incluye la información de congestión agregada; de este modo, la entrega del mensaje puede lograrse más rápido y posiblemente con mayor fiabilidad. El tipo particular de la técnica de compresión de mensajes aplicada no está limitada. Por ejemplo, las técnicas de compresión de mensajes pueden variar desde la agrupación de la información de congestión de los UEs dependiendo de un nivel de congestión indicado por la información de congestión respectiva; mediante la sustitución del APN común particular por un símbolo más corto; hasta esquemas de compresión más complejos como, por ejemplo, la codificación de la longitud de ejecución o la codificación de la entropía.
Puede ser deseable implementar una entrega confiable de mensajes que incluyen la información de congestión agregada. Esto puede lograrse empleando un protocolo de transporte confiable o semi-confiable para entregar los mensajes, por ejemplo, el Protocolo de Control de Transmisión (TCP) o el Protocolo de Transmisión de Control de Flujo (SCTP). Alternativamente o adicionalmente, se pueden emplear esquemas de acuse de recibo. Puede ser posible implementar el acuse de recibo de la PCRF 100 a la RCAF 200 para disminuir una probabilidad de fallos de transmisión. Los acuses de recibo de la PCRF 100 a la RCAF 200 también se pueden utilizar para transportar el resultado del mensaje que procesa y que indica un código de éxito o de error, es decir, que incluye el mensaje de resultado.
La FIGURA 2A es una ilustración esquemática de la PCRF 100. La PCRF 100 incluye una interfaz 110, una base de datos 130, y un procesador 120. La interfaz 110 se puede configurar para comunicarse con varias entidades de la red 1 de comunicaciones móviles mediante el envío y/o la recepción de datos. Por ejemplo, la interfaz 110 se puede configurar para comunicarse con la RCAF 200 a través de la interfaz Np (véase la FIGURA 1). El procesador 120 de la PCRF 100 se puede configurar para ejecutar varias tareas en relación con la desagregación del mensaje recibido que incluye la información de congestión agregada para una pluralidad de UEs asociados con la PCRF 100; y que determina las políticas para los UEs particulares asociados con la PCRF 100, por ejemplo, dependiendo de la información de congestión respectiva. La base de datos 130 puede almacenar información diversa relacionada con los UEs asociados con la PCRF 100. Por ejemplo, la base de datos 130 puede almacenar información de congestión previamente recibida a través de la interfaz 110 para un UE dado. En la base de datos 130, también se puede proveer un mapeo entre varias RCAFs 200 desplegadas a lo largo de la red 1 de comunicaciones móviles y los UEs asociados. Se pueden proveer varias políticas para un UE dado en la base de datos 130. Se proporciona además una memoria 140 que puede ser una memoria de sólo lectura, una memoria flash de sólo lectura, una memoria de acceso aleatorio, un almacenamiento masivo, un disco duro, o similar. La memoria 140 incluye códigos de programa adecuados para ser ejecutados por el procesador 120 para implementar las funcionalidades descritas anteriormente. El procesador 120 puede entonces generar los comandos que son necesarios para llevar a cabo los procedimientos discutidos anteriormente en los que está implicada la PCRF 100, en particular desagregación de mensajes y/o control de la implementación de políticas de tráfico de datos a/y desde un UE dado asociado con la PCRF y/o negociación de capacidades de agregación y parámetros de agregación para la agregación de la información de congestión.
En la FIGURA 2B, se muestra el DRA 600 que comprende una interfaz 610, un procesador 620, una base de datos 630, y una memoria 640. La interfaz 610 se puede configurar para recibir datos y/o transmitir datos a/y desde otras entidades de la red 1 de comunicaciones móviles. La base de datos 630 puede almacenar entradas, por ejemplo, que enlazan una identidad de un UE con una identidad de una PCRF 100. De este modo, cuando se recibe un mensaje a través de la interfaz 610 que incluye la identidad de un UE, basándose en la entrada respectiva en la base de datos 630, el procesador 620 se puede configurar para determinar la identidad de la PCRF 100 respectiva con la que está asociado el UE y, por ejemplo, indicar esta identidad a otra entidad y/o reenviar el mensaje recibido a la PCRF 100 respectiva. Además, la base de datos 630 puede comprender entradas que enlazan un nombre lógico de una PCRF 100 dada con una dirección IP de la PCRF 100 dada y/o con el nombre de DNS de la PCRF 100 dada. La memoria 640 puede ser una memoria de sólo lectura, una memoria flash de sólo lectura, una memoria de acceso aleatorio, una memoria de almacenamiento masivo, un disco duro o similar. La memoria 640 incluye códigos de programa adecuados para ser ejecutados por el procesador 620 para implementar las funcionalidades descritas anteriormente. El procesador 620 puede entonces generar los comandos que son necesarios para llevar a cabo los procedimientos discutidos anteriormente en los que está implicado el DRA 600. Tales procedimientos incluyen en particular: recuperar, de la base de datos 630, una identidad de una PCRF 100 dada asociada con el UE particular basándose en una identidad del UE.
En general, el DRA 600 es un nodo que puede encaminar de manera flexible mensajes individuales de diámetro al destino correcto. Los DRAs 600 se definen en los RFC 3588 y 6733 del IETF del protocolo base de Diámetro, sección 2.8 del IETF. El DRA 600 es útil para encaminar los mensajes individuales de diámetro basándose en un número de criterio. El DRA 600 puede ocultar la topología del encaminamiento de diámetro de los puntos finales, aquí la RCAF 200 y la PCRF 100. De este modo, el DRA 600 permite hacer la gestión de la red 1 de comunicaciones móviles más fácil para el operador. El DRA 600 también puede soportar funciones avanzadas, como el balanceo de carga entre nodos. El mensaje Np de encaminamiento a través de un DRA 600 se describe, por ejemplo, en el TS 23.705 del 3GPP, versión 0.11.0 de mayo del 2014, sección 6.1.5.5.2.4.
En la FIGURA 3, se muestra la RCAF 200 con mayor detalle. La RCAF 200 comprende una interfaz 210, un procesador 220, una base de datos 230, y una memoria 240. La interfaz 210 se configura para transmitir datos a varias entidades de la red 1 de comunicaciones móviles y para recibir datos de varias entidades de la red de comunicaciones móviles. En particular, se puede enviar un mensaje que agrega la información de congestión de la RCAF 200, empleando la interfaz 210 a través de la interfaz Np, a la PCRF 100. Además, la base de datos 230 se puede configurar para incluir varias entradas que enlazan la identidad de un UE dado con la identidad de una PCRF 100 con la que está asociado el UE; tal entrada puede ser parte de un llamado contexto del UE que puede referirse a datos mantenidos en una base por UE. Un contexto del UE puede incluir más información. Entonces es posible, antes de enviar el mensaje que incluye la información de congestión agregada a la PCRF 100 a través de la interfaz 210, añadir de manera selectiva la información de congestión para el UE dado al mensaje, dependiendo de la entrada respectiva de la base de datos 230.
La memoria 240 puede ser una memoria de sólo lectura, una memoria flash de sólo lectura, una memoria de acceso aleatorio, un almacenamiento masivo, un disco duro o similar. La memoria 240 incluye códigos de programa adecuados para ser ejecutados por el procesador 220 para implementar la funcionalidad descrita anteriormente. El procesador 220 puede entonces generar los comandos que son necesarios para llevar a cabo los procedimientos discutidos anteriormente en los que está implicada la RCAF 200. Tales procedimientos incluyen, en particular: agregar la información de congestión para al menos alguno de la pluralidad de UEs basándose en los UEs respectivos que están asociados con la PCRF 100; negociar, con la PCRf 100, una capacidad de la PCRF 100 para soportar la agregación de la información de congestión; agregar la información de congestión para el mensaje.
Mientras que en las Figuras 2A, 2B, 3 se muestra un único procesador 120, 220, 620, también es posible emplear un procesador de múltiples núcleos y/o múltiples procesadores que interactúan adecuadamente entre sí; el procesamiento distribuido es posible. Por ejemplo, puede ser posible incluir un identificador de sesión para cualquier comunicación dirigida a la PCRF 100, dirigiéndose el identificador de sesión o identificador de balanceo de carga a uno particular de los múltiples procesadores 120 de la PCRF 100. Así, se pueden implementar técnicas de balanceo de carga. La PCRF 100 puede negociar previamente los identificadores de sesión disponibles con la RCAF 200 y/o el DRA 600. En particular, la PCRF 100 puede notificar a la RCAF 200 de un identificador de sesión particular utilizado para enviar información de congestión agregada para uno o más UEs. Es decir, en general, es posible que la RCAF 200 se configure para agregar información de congestión basándose en un identificador de sesión recibido de la PCRF 100. Además, mientras que en las Figuras 2A, 2B, 3, se muestra una base de datos local 130, 230, 630, es posible implementar la base de datos como una entidad funcional que reside lógicamente, por ejemplo, en un servidor de datos o similar.
En la FIGURA 4, la agregación de la información 415 de congestión se muestra esquemáticamente. En la FIGURA 4, un total de tres PCRFs 100-1, 100-2, 100-3 se despliegan a lo largo de la red 1 de comunicaciones móviles. Los UEs 400-1, 400-2, 400-3 están asociados con la primera PCRF 100-1. El UE 400-4 está asociado con la segunda PCRF 100-2. Los UEs 400-5, 400-6, 400-7, 400-8 están asociados con la tercera PCRF 100-3. La agregación de información de congestión para varios UEs 400-1 — 400-8 se ilustra mediante las flechas verticales en la FIGURA 4. Para la PCRF 100-1, se genera un primer mensaje 411-1 que incluye la información 414 de congestión agregada para los UEs 400-1, 400-2, 400-3. Para la PCRF 100-2, se genera un segundo mensaje 411-2 que incluye la información 450 de congestión para el UE 400-4; como el segundo mensaje 411-2 solamente incluye la información 450 de congestión para el único UE 400-4, este es un mensaje no agregado. Para la tercera PCRF 400-3, se genera un tercer mensaje 411-3 que incluye la información 415 de congestión agregada para los UEs 400-5, 400-6, 400-7, 400-8. En el escenario de la FIGURA 4, la información 415 de congestión se incluye en los mensajes 411-11 — 411­ 13 de manera individual para cada UE 400-1 — 400-8, es decir, en un base por UE. La información 415 de congestión especifica un nivel de congestión para cada UE 400-1 — 400-8. Por ejemplo, el nivel de congestión puede relacionarse con un valor numérico que indica una gravedad de la congestión en una escala predefinida. Sin embargo, en general, es posible que la información 415 de congestión se relacione con un indicador binario que indica congestión o no congestión. Para proporcionar la información 415 de congestión de manera individual para cada UE 400-1 — 400-8, los mensajes 411-1 — 411-3 incluyen además las identidades 440 de los UEs 400-1 — 400-8 para cada información 415 de congestión. Además, los mensajes 411-1 — 411-3 incluyen una identidad 413 de la PCRF 100-1 — 100-3 respectiva a la que se dirige el mensaje 411-1 — 411-3.
Mientras que en la FIGURA 4 se ilustra un escenario donde cada mensaje 411-1 — 411-3 incluye la información 415 de congestión para cada uno de los UEs 400-1 — 400-8 asociados con la PCRF 100-1 — 100-3 respectiva, también es posible que los mensajes 411-1 — 411-3 incluyan la información 415 de congestión sólo para alguno de los UEs 400-1 — 400-8 asociados con la PCRF 100-1 — 100-3 respectiva. En otras palabras, puede ser prescindible incluir la información 415 de congestión para todos los UEs 400-1 — 400-8 que están asociados con una PCRF 100-1 — 100-3 dada. Por ejemplo, la agregación de la información 415 de congestión puede - además de la identidad 413 de la PCRF 100-1 — 100-3 - estar basada además en una latencia entre la recepción de un informe de congestión respectivo y/o un tamaño máximo de mensaje del mensaje 411-1 — 411-3.
Volviendo a la FIGURA 5, se ilustra un escenario mediante un diagrama de señalización donde la RCAF 200 indica la información 415 de congestión a la PCRF 100. En el paso S501, la RCAF 200 recibe un informe 510 de congestión, por ejemplo, de la 11 de OAM de la RAN (véase la FIGURA 1). El informe 510 de congestión puede referirse a la información de congestión del plano de usuario de la RAN (RUCI), véase el TS 23.705 del 3GPP, versión 0.10.0 de mayo del 2014. Por ejemplo, el informe 510 de congestión puede permitir determinar si un UE 400­ 1 — 400-8 dado está afectado por la congestión de la RAN 10 respectiva. En detalle, el informe 510 de congestión puede indicar si un eNB de la RAN 10 está afectado por la congestión. Basándose en una lista de UEs 400-1 — 400­ 8 asociados con el eNB, la RCAF 200 puede determinar que un UE 400-1 — 400-8 dado está afectado por la congestión de la RAN 10. Por ejemplo, la lista de UEs 400-1 — 400-8 asociados con el eNB puede recibirse de la MME 20 a través de la interfaz Nq - para la tecnología UMTS a través de la interfaz Nq' de la SGSN, respectivamente.
En otras palabras, la RCAF 200 determina si el UE 400-1 — 400-8 dado está afectado por la congestión de la RAN 10 respectiva. La recuperación de la identidad de la PCRF 100 es en respuesta a la recepción del informe 510 de congestión.
En un escenario simple, la RCAF 200 ya tiene conocimiento de la identidad 413 de la PCRF 100 con la que el UE 400-1 — 400-8 dado está asociado. Por ejemplo, tal información puede proveerse en la base de datos 230. La identidad 413 de la PCRF 100 puede entonces recuperarse fácilmente de la base de datos 230. En tal escenario, es posible que la RCAF 200 agregue la información de congestión del UE 400-1 — 400-8 dado, basándose en la identidad 413 de la PCRF 100, en un mensaje 411-1 — 411-3 respectivo dirigido a la PCRF 100.
En general, es posible que el envío del mensaje 411-1 — 411-3 emplee la identidad 413 recuperada de la PCRF 100 para encaminar el mensaje 411-1 — 411-3 a la PCRF 100. El encaminamiento puede producirse directamente, por ejemplo, empleando el nombre de DNS y/o la dirección IP de la PCRF 100 como la identidad 413. Cuando se emplea el nombre de DNS de la PCRF 100, es posible ejecutar una búsqueda de DNS para mapear el nombre de DNS de la PCRF 100 a una dirección IP respectiva de la PCRF 100. El encaminamiento también puede producirse indirectamente a través del DRA 600, por ejemplo, empleando un nombre lógico de la PCRF 100 como la identidad 413. También es posible emplear un nombre lógico de la PCRF 100 para encaminar el mensaje 411-1 — 411-3 directamente a la PCRF 100. En tal escenario, es posible almacenar de manera local, por ejemplo, en la base de datos 230, una tabla de mapeo que puede ser utilizada por la RCAF 200 para mapear el nombre lógico a una dirección de encaminamiento de la PCRF 100 como el nombre de DNS y/o la dirección IP. Alternativamente, también es posible en tal escenario emplear el DRA 600 para encaminar el mensaje a la PCRF 100.
En todos estos escenarios, es posible añadir un identificador de sesión a la identidad 413 de la PCRF 100 utilizada por los mensajes 411-1 — 411-3. En otras palabras, es posible que la PCRF 100 configure múltiples sesiones para el envío de los mensajes 411-1 — 411-3 de la RCAF 200 a la PCRF 100. Una razón para esto podría ser utilizar técnicas de balanceo de carga en la PCRF 100. Podría ser posible que una PCRF 100 dada se estructure en múltiples unidades de procesamiento y sea más eficiente para la PCRF 100 utilizar diferentes identificadores de sesión para diferentes unidades de procesamiento. Basándose en el identificador de sesión de un mensaje entrante 411-1 — 411-3 que incluye la información 415 de congestión agregada, es posible para la PCRF 100 dirigir el mensaje 411-1 — 411-3 a la unidad de procesamiento apropiada. También, múltiples identificadores de sesión pueden ayudar a implementar el procesamiento paralelo del mensaje 411-1 — 411-3 en la PCRF 100.
En el escenario de la FIGURA 5, se asume que la RCAF 200 tiene conocimiento previo de la identidad 413 de la PCRF 100 con la que el UE 400-1 — 400-8 dado está asociado. Incluso en tal caso, puede ser necesario negociar la capacidad de agregación y/o los parámetros de agregación con la PCRF 100. A este respecto, como se ilustra en la FIGURA 5, la RCAF 200 se puede configurar para enviar un mensaje 501 de solicitud (paso S502) que incluye un indicador respectivo que indica la capacidad de la RCAF 200 para agregar la información 415 de congestión. El mensaje 501 de solicitud puede incluir la identidad 414 del UE 400-1 — 400-8 dado. Después, en el paso S503, la RCAF 200 se puede configurar para recibir un mensaje 502 de respuesta que incluye el identificador 413 de la PCRF 100 que está asociada con el UE 400-1 — 400-8 dado. Además, se puede incluir una indicación de que la PCRF 100 también soporta la agregación de la información 415 de congestión. En el escenario de la FIGURA 5, la RCAF 200 se configura para enviar el mensaje 501 de solicitud en el paso S502 directamente a la PCRF 100 y se configura además para recibir el mensaje 502 de respuesta en el paso S503 directamente de la PCRF 100. Esto puede hacerse, porque la RCAF 200 tiene conocimiento previo de la identidad 413 de la PCRF 100. No hay necesidad de emplear el DRA 600 como un agente de encaminamiento.
En un escenario donde la RCAF 200 no tiene conocimiento previo de la identidad 413 de la PCRF 100, puede ser necesario recuperar la identidad 413 de la PCRF 100 antes de enviar el mensaje 411-1 — 411-3 desde otra entidad de la red 1 de comunicaciones móviles. En principio, hay varios escenarios concebibles para implementar la recuperación de la identidad 413 de la PCRF 100 desde otra entidad de la red de comunicaciones móviles. En particular, haciendo referencia al escenario de la FIGURA 6, es posible que la RCAF 200 se configure para enviar el mensaje 501 de solicitud al DRA 600 (paso S602) y recibir el mensaje 502 de respuesta que incluye la identidad 413 de la PCRF 100 del DRA 600 (paso S603). En tal escenario, no es necesario implicar a la PCRF 100 en la recuperación de la identidad 413 de la PCRF 100. Aquí, el DRA 600 trabaja en el llamado modo de redireccionamiento. También sería posible que el DRA 600 trabaje en el llamado modo procurador. Aquí, el DRA 600 reenviará el mensaje 501 de solicitud o un mensaje basado en el mensaje 501 de solicitud a la PCRF 100. La PCRF 100 podría entonces enviar el mensaje 502 de respuesta que incluye la identidad 413 de la PCRF 100 a través del DRA 600 a la RCAF 200. Mientras que, en tal escenario, un propósito del mensaje 501 de solicitud es recibir el mensaje 502 de respuesta que incluye la identidad 413 de la PCRF 100, además es posible negociar las capacidades de agregación y/o los parámetros de agregación que emplea el mensaje 501 de solicitud y/o el mensaje 502 de respuesta. En S604, la identidad 413 recuperada de la PCRF 100 se almacena en la base de datos 230 de la RCAF 200. Una vez que se reciba otro informe 510 de congestión para el UE 400-1 — 400-8 dado por la RCAF 200 (no mostrado en la FIGURA 6), es posible recuperar la identidad 413 de la PCRF 100 de la base de datos 230 de una manera como se ha explicado anteriormente en vista de la FIGURA 5; en particular, en tal caso puede no ser necesario enviar el mensaje 501 de solicitud y/o recibir el mensaje 502 de respuesta, haciendo así más eficiente el envío del mensaje 411-1 — 411-3 que incluye la información de congestión para el UE 400-1 — 400-8 dado.
En los escenarios de, ambas, las Figuras 5 y 6, en los pasos S504, S604, se agrega la información 415 de control. En los pasos S505, S605, se envía el mensaje 411-1 — 411-3 a la PCRF 100. Este mensaje incluye la información 415 de congestión para el UE 400-1 — 400-8 dado derivada del informe 510 de congestión de los pasos S501, S601. Agrega información 415 de congestión adicional. Como se desprende de una comparación de las Figuras 5 y 6, mientras que en el paso S505 de la FIGURA 5 el mensaje 411-1 — 411-3 se envía directamente a la PCRF 100, es decir, no emplea el DRA 600, también es posible emplear el DRA 600 cuando se envía el mensaje 411-1 — 411­ 3 (paso S605, FIGURA 6). Por ejemplo, si se recupera un nombre lógico de la PCRF 100 como la identidad 413, una tabla de mapeo configurada de manera local provista en la base de datos 230 puede ser utilizada por la RCAF 200 para mapear el nombre lógico en la dirección IP y/o el nombre de DNS de la PCRF 100. En tal caso, se puede emplear el encaminamiento directo del mensaje 411-1 — 411-3 a la PCRF 100 (véase la FIGURA 5). Alternativamente o adicionalmente, se puede emplear el DRA 600 para encaminar el mensaje 411-1 — 411-3 a la PCRF 100 basándose en el nombre lógico.
En la FIGURA 6, se ilustra además el paso opcional S606. En el paso S606, la PCRF 100 envía el mensaje 620 de resultado a la RCAF 200. El mensaje 620 de resultado se puede utilizar para confirmar la recepción con éxito del mensaje 411-1 — 411-3 por la PCRF 100. El mensaje 620 de resultado se puede emplear, adicionalmente o alternativamente, para transportar el resultado del procesamiento del mensaje 411-1 — 411-3 por el procesador 120 de la PCRF 100; por ejemplo, puede incluirse un éxito de la desagregación y/o un código de error. Los códigos de éxito y/o de error pueden dirigirse a todo el mensaje 411-1 — 411-3, es decir, a toda la información 415 de congestión incluida en el mensaje 411-1 — 411-3; también es posible que los códigos de éxito o de error se dirijan a la información 415 de congestión individual de un UE 400-1 — 400-8 dado.
Además con referencia a la FIGURA 6 donde se muestra el escenario del DRA 600 proporcionando la identidad 413 de la PCRF 100 a la RCAF 200. Tal escenario se describe en las Especificaciones Técnicas (TS) 29.213 del 3GPP, Lanzamiento 12, versión 12.4.0, sección 7.3.4.1. El cliente, aquí la Rc AF 200, recibe la identidad 413 de la PCRF 100 en el Par-Valor-Atributo (AVP) del host de re-direccionamiento de la respuesta de re-direccionamiento, como se define en las TS 29.213 del 3GPP, sección 7.3.4.1 cuando el DRA 600 está trabajando en el modo de redireccionamiento. La RCAF 200 recibe la identidad 413 de la PCRF 100 en el AVP del host de origen de la respuesta de diámetro como se define en las TS 29.213 del 3GPP, sección 7.4.1.1 cuando el DRA 600 está trabajando en el modo procurador. La RCAF 200 almacena la identidad 413 de la PCRF 100 en la base de datos 230. Entonces es posible recuperar la identidad 413 de la base de datos 230 más tarde y emplear la identidad 413 como el AVP del host de destino en mensajes 411-1 — 411-3 posteriores. Puede ser posible que los mensajes 411­ 1 — 411-3 posteriores incluyan información de congestión agregada a la PCRF 100, evitando así al DRA 600 como se define en la RFC 6733 del IETF del protocolo base de Diámetro del IETF y en las TS 29.213 del 3GPP, Figura 7.4.1.1.11. Normalmente, el AVP del host de destino incluye una entidad de diámetro que identifica el host en la forma de un Nombre de Dominio Completo (FQDN). Si un nodo de diámetro tiene varios FQDNs, se selecciona uno de ellos.
Como se muestra arriba, en general, es posible que el mensaje 501 de solicitud enviado por la RCAF 200 incluya la identidad 414 del UE 400-1 — 400-8 dado; igualmente es posible que el mensaje 502 de respuesta recibido por la RCAF 200 incluya la identidad 413 de la PCRF 100 asociada con el UE 400-1 — 400-8 dado. Opcionalmente, también es posible que el mensaje 501 de solicitud incluya un indicador que indica una capacidad de la RCAF 200 para enviar el mensaje 411-1 — 411-3 que incluye la información 415 de congestión agregada para la pluralidad de UEs 400-1 — 400-8. Igualmente, es posible que el mensaje 502 de respuesta incluya un indicador que indica una capacidad de la PCRF 100 para recibir el mensaje 411-1 — 411-3 que incluye la información 415 de congestión agregada. Por tales medios, es posible negociar previamente una capacidad tanto de la RCAF 200 como de la PCRF 100 para soportar la información 415 de congestión agregada.
Mientras que en las Figuras 5 y 6 como se muestra arriba, el mensaje 501 de solicitud y el mensaje 502 de respuesta se emplean principalmente para, en primer lugar, recuperar la identidad 413 y, en segundo lugar, negociar las capacidades y/o parámetros de la agregación, se explica a continuación una realización adicional relativa al mensaje 501 de solicitud y al mensaje 502 de respuesta. Se considera un caso donde la RCAF 200 no tiene, a priori, conocimiento sobre la identidad 413 de la PCRF 100 con la que está asociado un UE 400-1 — 400-8 dado. Entonces, en respuesta a la recepción del informe 510 de congestión para el UE 400-1 — 400-8 dado, es posible que la RCAF 200 incluya la información 415 de congestión en el mensaje 501 de solicitud. Es decir, el mensaje 501 de solicitud se emplea, en tercer lugar, para transmitir la información 415 de congestión para un UE 400-1 — 400-8 para el que no se dispone de conocimiento de una identidad 413 respectiva de la PCRF 100 asociada. Por ejemplo, el DRA 600 puede encaminar el mensaje 501 de solicitud a la PCRF 100 apropiada basándose en la identidad 414 del UE 400-1 — 400-8 dado como el IMSI y/o el APN. En general, si hay múltiples PCRFs 100 asociadas con el UE 400-1 — 400-8 dado, es posible encaminar el mensaje 501 de solicitud a la PCRF 100 apropiada dependiendo del APN.
A continuación, como se ha explicado anteriormente, es posible que la PCRF 100 responda enviando el mensaje 502 de respuesta que incluye la identidad 413 de la PCRF 100. Esta identidad 413 de la PCRF 100 puede ser empleada más tarde por la RCAF 200 para, en primer lugar, controlar la agregación de la información 415 de congestión para el UE 400-1 — 400-8 dado y, en segundo lugar, para encaminar el mensaje 411-1 — 411-3 que incluye la información 415 de congestión agregada a la PCRF 100. La información 415 de congestión posterior para el u E 400-1 — 400-8 dado se agrega entonces en el mensaje 411-1 — 411-3. Para este propósito, la RCAF 200 se configura para almacenar la identidad 413 de la PCRF 100 en la base de datos 230. Como puede verse, en el escenario propuesto, el mensaje inicial, es decir, el mensaje 501 de solicitud, que incluye la información 415 de congestión para un UE 400-1 — 400-8 dado se envía en una forma no agregada. Es decir, el mensaje inicial, aquí el mensaje 501 de solicitud, no incluye ninguna información 415 de congestión para otros UEs 400-1 — 400-8 que el UE 400-1 — 400-8 dado. El mensaje 501 de solicitud es encaminado por el DRA 600 a la PCRF 100 apropiada, cuya identidad 413 es a priori desconocida para la RCAF 200. Una vez que se encuentra la PCRF 100, la RCAF 200 es notificada sobre la identidad 413 de la PCRF 100 en uso y la RCAF 200 almacena la identidad 413 en el contexto respectivo del UE 400-1 — 400-8 dado. Los mensajes posteriores de la RCAF 200 a la PCRF 100 que incluyen la información 415 de congestión para el UE 400-1 — 400-8 dado se agregan y preferiblemente se encaminan directamente a la PCRF 100 utilizando la identidad 413 almacenada en el contexto del UE 400-1 — 400-8 dado.
En la FIGURA 7, se ilustra un diagrama de flujo de un método de envío de información 415 de congestión a una pluralidad de UEs 400-1 — 400-8 asociados con una PCRF 100 particular. En el paso S701, la información 415 de congestión se agrega para al menos alguno de la pluralidad de UEs 400-1 — 400-8. Esto ocurre dependiendo de los UEs 400-1 — 400-8 que están asociados con la PCRF 100 dada. Es decir, si se determina que un UE dado está asociado (no asociado) con la PCRF 100 dada, la información 415 de congestión respectiva para el UE 400-1 — 400-8 dado puede ser incluida (no incluida) en el mensaje 411-1 — 411-3.
Después, en el paso S702, el mensaje 411-1 — 411-3 que incluye la información 415 de congestión agregada para al menos alguno de la pluralidad de UEs 400-1 — 400-8 se envía a la PCRF 100.
En la FIGURA 8, un diagrama de flujo ilustra un método de recepción del mensaje 411-1 — 411-3 que incluye la información 415 de congestión agregada. En el paso S801, la PCRf 100 se configura para recibir el mensaje 411-1 — 411-3. La PCRF 100 puede entonces desagregar el mensaje 411-1 — 411-3, accediendo así a la información 415 de congestión individual para los diversos UEs 400-1 — 400-8. Opcionalmente, la PCRF 100 puede enviar el mensaje 620 de resultado a la RCAF 200.
En la FIGURA 9, se muestra un diagrama de flujo de un método de envío de la información 415 de congestión para una pluralidad de UEs 400-1 — 400-8 según diversas realizaciones. El método empieza con el paso S901. Primero, se recibe el informe 510 de congestión para un UE 400-1 — 400-8 dado en el paso S901. Después, se recupera la identidad 413 de la PCRF respectiva 100 asociada con el UE 400-1 — 400-8 dado en el paso S902. Es posible incluir la información 415 de congestión relativa al informe 510 de congestión recibido en el paso S901 como parte de un mensaje 501 de solicitud enviado durante el paso S902 de la RCAF 200 a la PCRF 100.
Después, en el paso S903, se agrega la información 515 de congestión para los UEs 400-1 — 400 -8 asociados con la PCRF 100. Esto incluye agregar la información 415 de congestión para el UE 400-1 — 400-8 dado. Después, en el paso S904, el mensaje 411-1 — 411-3 que incluye la información 415 de congestión agregada del paso S903 se envía de la RCAF 200 a la PCRF 100.
En la FIGURA 10, el paso S903, es decir, el paso de agregar la información 415 de congestión para una PCRF 100 particular dada se muestra con mayor detalle. En particular, como se ha mencionado anteriormente, es posible que la agregación de la información 415 de congestión se base además en al menos uno de los siguientes: una latencia entre la recepción del informe 510 de congestión y el envío del mensaje 411-1 — 411-3; y un tamaño máximo del mensaje 411-1 — 411-3. El método empieza en el paso S1001. Después, en el paso S1002, se comprueba si se recibe un nuevo informe 510 de congestión para un Ue 400-1 — 400-8 dado. El informe 510 de congestión permite a la RCAF 200 preparar la información 415 de congestión respectiva para el UE 400-1 — 400-8 dado. Si se recibe un informe 510 de congestión respectivo en el paso S1002, el método comienza con el paso S1004. En el paso S1004, se comprueba si el UE 400-1 — 400-8 dado, para el que se recibe el informe 510 de congestión, está asociado con la PCRF 100 dada. Para esto, el procesador 220 de la RCAF 200 se puede configurar para acceder a la base de datos 230 para comprobar si en el contexto del UE 400-1 — 400-8 dado está provista una identidad 413 de la PCRF 100 asociada con el UE 400-1 — 400-8. Se comprueba entonces si esta identidad 413 coincide con la identidad 413 de la PCRF 100 dada. Si este es el caso, en el paso S1005, se añade la información 415 de congestión a la cola regulada de agregación de información de congestión. De lo contrario, el método termina con el paso S1008; en tal caso, para otras PCRFs 100 diferentes a la PCRF 100 dada, el método respectivo puede ser re-ejecutado.
En el paso S1006, se comprueba si la información de congestión agregada excede un umbral predefinido. En otras palabras, en el paso S1006, se comprueba si se alcanza un tamaño máximo del mensaje 411-1 — 411-3 para el que se proporciona la información 415 de congestión regulada. Si este es el caso, en el paso S1007, se envía el mensaje 411-1 — 411-3 a la PCRF 100. Si, no obstante, el tamaño máximo del mensaje 411-1 — 411-3 no se ha alcanzado en el paso S1006, el método comienza con el paso S1002.
En el paso S1003, se comprueba si la latencia de la información 415 de congestión regulada (véase el paso S1005) excede un tiempo de umbral predefinido. Si este es el caso, entonces el mensaje 411-1 — 411-3 se envía en el paso S1007. Normalmente, la información 415 de congestión regulada más antigua activará el envío del mensaje a través de los pasos S1003, S1007. No obstante, en principio, es posible que diferentes UEs 400-1 — 400-8 estén asociados con diferentes tiempos de latencia. De lo contrario, el método comienza con el paso S1002.
Implementando las técnicas según la FIGURA 10, es posible implementar un intercambio entre el mayor tamaño del mensaje y la mayor latencia en el envío de la información 415 de congestión en el lado de la mano; y el número reducido de mensajes enviados a través de la interfaz NP entre la RCAF 200 y la PCRF 100 en el otro lado de la mano. Como se desprende de lo anterior, la RCAF 200 puede utilizar el conocimiento sobre la identidad 413 de una PCRF 100 asociada con un UE 400-1 — 400-8 dado para agregar la información 415 de congestión respectiva en un único mensaje 411-1 — 411-3 (véase el paso S1004 en el paso S1005 de la FIGURA 10). La RCAF 200 selecciona la información 415 de congestión que está destinada a una PCRF 100 dada basándose en la identidad 413 de la PCRF 100 respectiva. En general, no es necesario, sin embargo, que toda la información 415 de congestión asociada con la misma identidad 413 de una PCRF 100 dada se agregue en un único mensaje 411-1 — 411-3. Una razón podrían ser las limitaciones de tamaño del mensaje (compare el paso S1006 de la FIGURA 10) como se ha descrito anteriormente, lo que puede conducir a múltiples mensajes.
Una razón adicional para que la RCAF 200 envíe múltiples mensajes podría ser limitar el retraso. Los datos de OAM, es decir, el informe 510 de congestión, pueden llegar periódicamente a la RCAF 200 y los datos para ciertas celdas o eNBs pueden llegar en una fase anterior que para otros eNBs. De manera similar, la información acerca de un conjunto de UEs 400-1 — 400-8 para la celda o eNB también puede llegar periódicamente a la RCAF 200 y venir en diferentes fases. La RCAF 200 puede configurarse con un período máximo de tiempo para el que se ejecuta la agregación de la información 415 de congestión en un único mensaje 411-1 — 411-3 (compare el paso S1003 en la FIGURA 10). Esto evita que la RCAF 200 provoque demasiado retraso adicional y que envíe la información 415 de congestión por el bien de la agregación. Un caso particular es que la RCAF 200 agregue la información 415 de congestión sólo para una única celda o eNB. Una vez que la información para una única celda o eNB ha sido compilada en un mensaje 411-1 — 411-3, ese mensaje 411-1 — 411-3 se envía, evitando cualquier retraso adicional debido a la agregación del mensaje. En general, es posible que la agregación de la información 415 de congestión se base además en una asociación entre los UEs 400-1 — 400-8 y una celda de la RAN.
Como se apreciará, se han mostrado las técnicas anteriores que permiten agregar la información 415 de congestión para varios UEs 400-1 — 400-8 asociados con una PCRF 100 dada. Ya que los UEs 400-1 — 400-8 normalmente se mantienen unidos a la red 1 de comunicaciones móviles por períodos de tiempo más largos y en muchos casos la RCAF 200 es típico que esté sin cambios también por períodos de tiempo más largos, puede haber muchos cambios de nivel de congestión si el UE 400-1 — 400-8 se mantiene unido a una RCAF 200 dada. Ya que este enfoque según técnicas, como se ha explicado anteriormente, puede introducir optimización de señal en el primer o segundo cambio del nivel de congestión del UE 400-1 — 400-8 dado, es decir, una vez que se conoce la identidad 413 de la PCRF 100 asociada a la RCAF 200, las técnicas permiten reducir significativamente la carga de señalización en la interfaz Np. Al mismo tiempo, es posible reutilizar la funcionalidad del DRA 600 para encontrar la PCRF 100 asociada con un UE 400-1 — 400-8 dado. Esto último simplifica el funcionamiento de la red 1 de comunicaciones móviles y mejora la flexibilidad de despliegue.
Aunque la invención se ha mostrado y descrito con respecto a ciertas realizaciones preferidas, equivalentes y modificaciones se les ocurrirán a los expertos en la técnica tras la lectura y comprensión de la especificación. La presente invención incluye todos estos equivalentes y modificaciones.
Anteriormente, se han tratado fundamentalmente escenarios en los que hay una unidad de control de política asociada con una entidad móvil dada. En general, es también posible que haya una pluralidad de unidades de control de política asociadas con una entidad móvil dada. En tal caso, puede ser posible que la unidad de vigilancia de congestión recupere para una entidad móvil múltiples identidades de unidades de control de política, por ejemplo, una por unidad de control de política; y emplee una particular de las múltiples identidades para el envío del mensaje que incluye la información de congestión agregada. Por ejemplo, puede ser posible que para diferentes puntos de acceso a los que puede ser conectada la entidad móvil, diferentes entidades de control de política estén asociadas con la entidad móvil. En tal caso, puede ser posible que el informe de congestión incluya además una indicación del punto de acceso, por ejemplo el nombre del punto de acceso, y que la identidad de la unidad de control de política asociada respectiva sea recuperada basándose en la indicación del nombre del punto de acceso.
Por ejemplo, puede concebirse que la unidad de vigilancia de congestión agregue información de congestión para una pluralidad de entidades móviles en un único mensaje. La unidad de vigilancia de congestión puede entonces enviar el mensaje agregado a la totalidad o a un grupo de unidades de control de política en la red de comunicaciones móviles. Una unidad de control de política particular sólo necesita actuar sobre un mensaje que incluye información de congestión para tales entidades móviles que están asociadas con la PRCF dada. De tal modo, es posible reducir significativamente la carga de señalización. La unidad de control de política respectiva necesita filtrar información de los mensajes recibidos. En particular, en escenarios donde solamente hay desplegadas unas pocas unidades de control de política a lo largo de toda la red de comunicaciones móviles, esto podría probar una opción factible.
En otro escenario, es posible que la unidad de vigilancia de congestión agregue información de congestión para una pluralidad de entidades móviles en un único mensaje. La unidad de vigilancia de congestión envía el mensaje agregado a una entidad de base de datos de encaminamiento. La entidad de base de datos de encaminamiento divide el mensaje en múltiples mensajes y encamina los mensajes divididos a unidades de control de política particulares asociadas con información de congestión de las entidades móviles respectivas. En tal escenario, cada unidad de control de política recibe sólo la parte particular del mensaje agregado que incluye información de congestión para las UE asociadas con la unidad de control de política respectiva. En tal escenario, la carga de señalización puede ser reducida significativamente y la funcionalidad de una entidad de base de datos de encaminamiento tal como un DRA puede ser empleada para evitar que unidades de control de política de la red de comunicaciones móviles reciban información irrelevante. En particular, para escenarios en los que las entidades de base de datos de encaminamiento poseen recursos computacionales significativos, tal escenario puede ser factible de implementar.

Claims (13)

REIVINDICACIONES
1. Un método de envío en una Función de Conciencia de Congestión de Red de Acceso vía Radio, RCAF (200), para enviar, a una Función de Políticas y Reglas de Cargas, PCRF (100, 100-1 - 100-3), de una red (1) de comunicaciones móviles, información (415) de congestión para una pluralidad de entidades móviles, UE (400-1 - 400-8), estando conectado cada uno de la pluralidad de UE (400-1 - 400-8) a una red (10) de acceso vía radio respectiva de la red (1) de comunicaciones móviles y asociado con la PCRF (100, 100-1 - 100-3), indicando la información (415) de congestión la congestión de la red (10) de acceso vía radio respectiva, comprendiendo el método:
- enviar un mensaje (501) de solicitud para transmitir información de congestión de una UE (400-1 - 400-8) dado a una PCRF (100, 100-1 - 100-3), incluyendo información (415) de congestión y una identidad (414) de la UE (400-1 - 400-8) dado de la pluralidad de UEs (400-1 - 400-8), en donde el mensaje (501) de solicitud es encaminado por un Agente de Encaminamiento Diameter, DRA (600) a la PCRF (100, 100-1 - 100-3), y - recibir un mensaje (502) de respuesta que incluye una identidad (413) de la PCRF (100, 100-1 - 100-3) asociada con la UE (400-1 - 400-8) dado,
- agregar la información (415) de congestión para al menos alguno de la pluralidad de UE (400-1 - 400-8) basado en las UEs (400-1 - 400-8) respectivos que están asociados con la PCRF (100, 100-1 - 100-3), y
- enviar un mensaje (411-1 - 411-3) que incluye la información (415) de congestión agregada a la PCRF (100, 100-1 - 100-3), en donde dicho envío del mensaje (411-1 - 411-3) emplea la identidad (413) recuperada de la PCRF (100, 100-1 - 100-3) para encaminar el mensaje (411-1 - 411-3) a la PCRF (100, 100-1 - 100-3).
2. El método de la reivindicación 1, en el que dicha identidad (414) de la UE (400-1 - 400-8) dado es la Identidad Internacional de Abonado Móvil, IMSI.
3. El método de la reivindicación 1 o 2, en el que el mensaje (501) de solicitud comprende además un Nombre de Punto de Acceso, APN; de una Red de Datos por Paquetes, PDN (60) asociada con la PCRF (100, 100-1 - 100-3).
4. El método según cualquiera de las reivindicaciones 1 a 3, en el que la identidad (413) de la PCRF (100, 100-1 - 100-3) es al menos uno de una dirección de Protocolo Internet, IP, o de un nombre de Sistema de Nombres de Dominios (DNS), en el que dicho envío del mensaje (411-1 - 411-3) incluye encaminar el mensaje (411-1 - 411-3) directamente a la PCRF (100, 100-1 - 100-3) basado en al menos uno de la dirección IP o del nombre de Dn S de la PCRF (100, 100-1 - 100-3).
5. Una Función de Concienciación de Congestión de Red de Acceso vía Radio, RCAF (200), configurada para enviar, a una Función de Política y Cobros, PCRF (100, 100-1 - 100-3), de una red (1) de comunicaciones móviles, información (415) de congestión para una pluralidad de entidades móviles, UE (400-1 - 400-8), estando conectado cada uno de la pluralidad de UEs (400-1 - 400-8) a una red (10) de acceso vía radio respectiva de la red (1) de comunicaciones móviles y asociado con la PCRF (100, 100-1 - 100-3), indicando la información (415) de congestión la congestión de la red (10) de acceso vía radio respectiva, comprendiendo la RCAF (200):
- un procesador (220) configurado para agregar la información (415) de congestión para al menos alguno de la pluralidad de UE (400-1 - 400-8) basado en las UEs (400-1 - 400-8) respectivos que están asociados con la PCRF (100, 100-1 - 100-3)
- un procesador (220) configurado para controlar una interfaz (210) para enviar un mensaje (501) de solicitud para transmitir información de congestión de una entidad móvil (400-1 - 400-8) dada a una PCRF (100, 100-1 -100-3) que incluye información (415) de congestión y la identidad (414) de la UE (400-1 - 400-8) dado de la pluralidad de UE (400-1 - 400-8) a un Agente de Encaminamiento de Diameter, DRA (600), en el que el mensaje (501) de solicitud es encaminado por el DRA (600) a la PCRF (100, 100-1 - 100-3) y para recibir, procedente del DRA (600), un mensaje (502) de respuesta que incluye una identidad (413) de la Pc RF (100, 100-1 - 100-3) asociada con la UE (400-1 - 400-8) dado,
- una interfaz (210) configurada para enviar un mensaje (411-1 - 411-3) que incluye la información (415) de congestión agregada a la PCRF (100, 100-1 - 100-3), en donde la interfaz (210) está además configurada para enviar el mensaje (411-1 - 411-3) empleando la identidad (413) recuperada de la PCRF (100, 100-1 - 100-3) para encaminar el mensaje a la PCRF (100, 100-1 - 100-3).
6. La RCAF de la reivindicación 5, en la que dicha identidad (414) de la UE (400-1 - 400-8) dado es la Identidad Internacional de Abonado Móvil, IMSI.
7. La RCAF de las reivindicaciones 5 o 6, en la que el mensaje (501) de solicitud comprende además un Nombre de Punto de Acceso, APN; de una Red de Datos por Paquetes, PDN (60) asociada con la PCRF (100, 100-1 - 100-3).
8. La RCAF según una cualquiera de las reivindicaciones 6 - 7, en la que la identidad (413) de la PCRF (100, 100-1 -100-3) es al menos uno de una dirección de Protocolo Internet, IP, o un nombre de Sistema de Nombres de Dominio, DNS, en el que dicho envío del mensaje (411-1 - 411-3) incluye encaminar el mensaje (411-1 - 411-3) directamente a la PCRF (100, 100-1 - 100-3) basado en al menos uno de la dirección IP o del nombre de DNS de la PCRF (100, 100-1
9. Un método en una Función de Política y Cobros, PCRF (100, 100-1 - 100-3), para recibir información (415) de congestión para una pluralidad de entidades móviles, UE (400-1 - 400-8), procedente de una Función de Concienciación de Congestión de Redes de Acceso vía Radio, RCAF, (200), de una red (1) de comunicaciones móviles, estando conectado cada uno de la pluralidad de UEs (400-1 - 400-8) a una red (10) de acceso vía radio respectiva de la red (1) de comunicaciones móviles y asociado con una PCRF (100, 100-1 - 100-3), indicando la información (415) de congestión la congestión de la red (10) de acceso vía radio respectiva, comprendiendo el método:
- recibir un mensaje (501) de solicitud procedente de la RCAF (200) para transmitir la información de congestión de un UE (400-1 - 400-8) dado a la pCr F (100, 100-1 - 100-3), encaminado por un Agente de Encaminamiento de Diameter, DRA (600). Incluyendo el mensaje (501) de solicitud información (415) de congestión y una identidad (414) para el UE (400-1 - 400-8) dado,
- en respuesta a dicha recepción del mensaje (501) de solicitud, enviar un mensaje (502) de respuesta que incluye una identidad (413) de la PCRF (100, 100-1 - 100-3),
- recibir, procedente de la RCAF (200), un mensaje (411-1 - 411-3) que incluye la información de congestión (415) agregada para al menos alguno de la pluralidad de UEs (400-1 - 400-8) asociado con la PCRF (100, 100-1 - 100-3).
10. Una Función de Política y Cobros, PCRF (100, 100-1 - 100-3), configurada para recibir información (415) de congestión para una pluralidad de entidades móviles, UE (400-1 - 400-8), procedente de una Función de Concienciación de Congestión de Red de Acceso vía Radio, RCAF (200), estando conectado cada uno de la pluralidad de UEs (400-1 -400-8) a una red (10) de acceso vía radio respectiva de la red (1) de comunicaciones móviles, indicando la información (415) de congestión la congestión de la red (10) de acceso vía radio respectiva, comprendiendo la PCRF (100, 100-1 -100-3):
- una interfaz (110) configurada para recibir un mensaje (501) de solicitud procedente de la RCAF (200), encaminado por un Agente de Encaminamiento de Diameter, DRA (600), el mensaje (501) de solicitud es para transmitir la información de congestión de una UE (400-1 - 400-8) dado a una PCRF (100, 100-1 - 100-3), que incluye la información (415) de congestión y una identidad (414) de la UE (400-1 - 400-8) dado, en el que, en respuesta a dicha recepción del mensaje (501) de solicitud, la interfaz (110) está configurada además para enviar un mensaje (502) de respuesta que incluye una identidad (413) de la PCRF (100, 100-1 - 100-3) y para recibir un mensaje (411-1 - 411-3) procedente de la RCAF (200), incluyendo el mensaje (411-1 - 411-3) información (415) de congestión agregada para al menos alguno de la pluralidad de UEs (400-1 - 400-8) asociado con la PCRF (100, 100-1 - 100-3).
11. Programa de ordenador, que comprende instrucciones que, cuando son ejecutadas en al menos un procesador (120, 220, 320), hacen que al menos el procesador (120, 220, 320) lleve a cabo el método de acuerdo con cualquiera de las reivindicaciones 1 - 4.
12. Producto de programa de ordenador que comprende un programa de ordenador según la reivindicación 11.
13. Un portador que contiene el programa de ordenador de la reivindicación 11, en el que el portador es uno de entre una señal eléctrica, una señal óptica, una señal de radio, o una cinta magnética.
ES17166093T 2014-06-30 2015-04-23 Agregación de información de congestión Active ES2700970T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201462018731P 2014-06-30 2014-06-30

Publications (1)

Publication Number Publication Date
ES2700970T3 true ES2700970T3 (es) 2019-02-20

Family

ID=53015787

Family Applications (2)

Application Number Title Priority Date Filing Date
ES15719189.1T Active ES2639742T3 (es) 2014-06-30 2015-04-23 Agregación de información de congestión
ES17166093T Active ES2700970T3 (es) 2014-06-30 2015-04-23 Agregación de información de congestión

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES15719189.1T Active ES2639742T3 (es) 2014-06-30 2015-04-23 Agregación de información de congestión

Country Status (9)

Country Link
US (2) US10728793B2 (es)
EP (2) EP3214801B1 (es)
DK (1) DK3214801T3 (es)
ES (2) ES2639742T3 (es)
PL (2) PL3214801T3 (es)
PT (1) PT3214801T (es)
RU (1) RU2661785C1 (es)
WO (1) WO2016000842A1 (es)
ZA (1) ZA201607933B (es)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014193475A1 (en) * 2013-05-31 2014-12-04 Intel IP Corporation Hybrid digital and analog beamforming for large antenna arrays
US9485685B2 (en) * 2014-06-13 2016-11-01 Telefonaktiebolaget Lm Ericsson (Publ) Congestion monitoring of mobile entities
PL3214801T3 (pl) * 2014-06-30 2019-02-28 Telefonaktiebolaget Lm Ericsson (Publ) Agregacja informacji o przeciążeniach
US9560549B2 (en) * 2014-09-05 2017-01-31 Cisco Technology, Inc. Reporting of aggregated RAN congestion information
CN105897608B (zh) * 2015-01-26 2020-03-13 中兴通讯股份有限公司 一种拥塞信息的管理方法和装置
US9661529B2 (en) * 2015-03-05 2017-05-23 Cisco Technology, Inc. Congestion mitigation for roamers
US10321496B2 (en) * 2015-06-03 2019-06-11 Parallel Wireless, Inc. Inter-PGW handover architecture
US11019151B2 (en) * 2016-06-30 2021-05-25 Intel Corporation Message schema control
CN107734544B (zh) * 2016-08-11 2021-05-07 上海诺基亚贝尔股份有限公司 用于拥塞控制的方法和设备
US10142886B2 (en) 2016-09-30 2018-11-27 Cisco Technology, Inc. System and method to facilitate group reporting of user equipment congestion information in a network environment
US10284420B2 (en) * 2017-02-19 2019-05-07 Cisco Technology, Inc. System and method to facilitate network element failure detection and session restoration in a network environment
US11055411B2 (en) * 2018-05-10 2021-07-06 Acronis International Gmbh System and method for protection against ransomware attacks
US10674395B2 (en) * 2018-06-26 2020-06-02 Verizon Patent And Licensing Inc. Method and system for RAN-aware multi-access edge computing traffic control
CN109286683A (zh) * 2018-11-16 2019-01-29 四川长虹电器股份有限公司 基于mes系统的多线程信息采集上报方法
US11350306B2 (en) * 2019-10-15 2022-05-31 Verizon Patent And Licensing Inc. Dynamically prioritizing users during network congestion
US12273270B2 (en) 2020-01-28 2025-04-08 Intel Corporation Congestion management techniques
US12301476B2 (en) 2020-12-26 2025-05-13 Intel Corporation Resource consumption control
CN115529636B (zh) * 2021-06-25 2026-01-02 华为技术有限公司 一种策略控制的方法、装置和系统
WO2023048925A1 (en) * 2021-09-23 2023-03-30 Intel Corporation Network resource monitoring
US12463912B2 (en) * 2023-02-28 2025-11-04 Verizon Patent And Licensing Inc. Systems and methods for host responsiveness monitoring for low-latency, low-loss, scalable-throughput services

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7733770B2 (en) * 2004-11-15 2010-06-08 Intel Corporation Congestion control in a network
US8392602B2 (en) * 2005-09-30 2013-03-05 Rockwell Automation Technologies, Inc. Embedding controllers and devices with data to facilitate up-to-date control and configuration information
US7796632B2 (en) * 2006-09-29 2010-09-14 Motorola, Inc. Transmission channel bandwidth selection for communications between multi-bandwidth nodes
EP2056570A1 (en) * 2007-10-29 2009-05-06 Nokia Siemens Networks Oy Session and media binding to common control
US9380460B2 (en) * 2007-11-01 2016-06-28 Telefonaktiebolaget L M Ericsson (Publ) Method and system for correlating authentication, authorization and accounting sessions
CN101499919B (zh) * 2008-01-28 2012-12-12 华为技术有限公司 策略决策实体的管理方法、管理网元及网络系统
US8249551B2 (en) * 2008-06-05 2012-08-21 Bridgewater Systems Corp. Long-term evolution (LTE) policy control and charging rules function (PCRF) selection
CN102055570B (zh) 2009-11-10 2014-12-17 华为技术有限公司 半静态调度数据的传输方法及装置
EP2507964A1 (en) * 2009-11-30 2012-10-10 Nokia Siemens Networks Oy Method and network device establishing a binding between a plurality of separate sessions in a network
US8615237B2 (en) * 2010-01-04 2013-12-24 Tekelec, Inc. Methods, systems, and computer readable media for policy and charging rules function (PCRF) node selection
WO2012071739A1 (zh) * 2010-12-03 2012-06-07 华为技术有限公司 不同网络间寻址的实现方法、路由代理网元及系统
US8724467B2 (en) * 2011-02-04 2014-05-13 Cisco Technology, Inc. System and method for managing congestion in a network environment
EP2658202B1 (en) * 2012-04-24 2017-10-11 Telefonaktiebolaget LM Ericsson (publ) Identification of an ip-can session in a policy and charging control apparatus
CN202647490U (zh) * 2012-07-24 2013-01-02 京东方科技集团股份有限公司 背光模组及显示装置
KR20140018089A (ko) * 2012-07-25 2014-02-12 삼성전자주식회사 무선 통신 시스템에서 혼잡을 고려한 트래픽 오프로딩 방법 및 장치
WO2014037047A1 (en) * 2012-09-07 2014-03-13 Nokia Siemens Networks Oy Usage control for subscriber group
EP2912796B1 (en) * 2012-10-26 2023-03-29 Apple Inc. Physical uplink control channel (pucch) resource allocation (ra) for a hybrid automatic retransmission re-quest-acknowledge (harq-ack) transmission
US9351183B2 (en) * 2013-02-26 2016-05-24 Google Technology Holdings LLC Apparatus and method for measuring and using congestion in a wireless communication system
US9554416B2 (en) * 2013-04-26 2017-01-24 Intel IP Corporation Shared spectrum reassignment in a spectrum sharing context
WO2014185987A1 (en) * 2013-05-14 2014-11-20 Zte (Usa) Inc. Congestion management for non-roaming and roaming subscribers
US20140379835A1 (en) * 2013-06-21 2014-12-25 Jeffrey R. Foerster Predictive pre-caching of content
EP2819455A1 (en) * 2013-06-28 2014-12-31 Alcatel Lucent Off-path notification of RAN congestion information in an EPS network
KR20150073825A (ko) * 2013-12-20 2015-07-01 삼성전자주식회사 이동 통신 시스템에서 음성 호 설정 시간을 단축시키는 방법 및 장치
WO2015093912A1 (ko) * 2013-12-20 2015-06-25 삼성전자 주식회사 이동 통신 시스템에서 혼잡 제어 방법 및 장치
US9485685B2 (en) * 2014-06-13 2016-11-01 Telefonaktiebolaget Lm Ericsson (Publ) Congestion monitoring of mobile entities
PL3214801T3 (pl) 2014-06-30 2019-02-28 Telefonaktiebolaget Lm Ericsson (Publ) Agregacja informacji o przeciążeniach
US9560549B2 (en) * 2014-09-05 2017-01-31 Cisco Technology, Inc. Reporting of aggregated RAN congestion information
CN105897608B (zh) * 2015-01-26 2020-03-13 中兴通讯股份有限公司 一种拥塞信息的管理方法和装置

Also Published As

Publication number Publication date
WO2016000842A1 (en) 2016-01-07
PT3214801T (pt) 2018-12-03
ES2639742T3 (es) 2017-10-30
US20150382230A1 (en) 2015-12-31
US10728793B2 (en) 2020-07-28
US12279148B2 (en) 2025-04-15
EP3214801B1 (en) 2018-09-05
EP3103227A1 (en) 2016-12-14
EP3103227B1 (en) 2017-06-07
PL3214801T3 (pl) 2019-02-28
DK3214801T3 (en) 2018-12-17
EP3214801A1 (en) 2017-09-06
US20200336933A1 (en) 2020-10-22
ZA201607933B (en) 2018-05-30
RU2661785C1 (ru) 2018-07-19
PL3103227T3 (pl) 2017-11-30

Similar Documents

Publication Publication Date Title
ES2639742T3 (es) Agregación de información de congestión
US20250039986A1 (en) Multi Access Protocol Data Unit Session
EP3718335B1 (en) Methods and network nodes of packet aggregation in a session management function, smf.
AU2018289655B2 (en) User equipment, communication control method of user equipment, core network device, communication control method of core network, SMF, and communication control method of SMF
JP6139001B2 (ja) モバイル・ネットワークを通じたユーザ・プレーン・トランザクションのサポート
EP3644647B1 (en) Pdu session establishment and rejection procedure
AU2018289916B2 (en) Terminal apparatus and core network device
EP2667551A2 (en) Method and system for setting up a bearer
US11284320B2 (en) User equipment
CN114710975B (zh) 一种用于多域间传输多传输网络上下文标识的方法、基站、网元及装置
EP3739955A1 (en) User equipment
US11259242B2 (en) User equipment
EP3991365B1 (en) Transporting mtnc-id over srv6-enabled dataplane for 5g transport
CN107534608B (zh) 用于在无线通信网络中处理数据流的方法和装置
AU2017355827B2 (en) Terminal device, core network device, communication system, and communication control method
EP3395024A1 (en) Method and nodes for handling bearers
US9877258B2 (en) Method and device for transferring data traffic
WO2018167254A1 (en) Unique qos marking ranges for smfs in a 5g communications network
EP3537772B1 (en) Terminal device, core network device, communication system, and communication control method
CN105359573A (zh) 用于在无线通信系统中卸载数据业务的方法和装置
WO2019096393A1 (en) A client device, an access network device, a method and a computer program for establishing a data radio bearer
KR20140134998A (ko) 통신 시스템에서 음성 서비스 성능 향상을 위한 방법 및 장치
WO2015139729A1 (en) Configuration of backhaul bearers
ES2653420T3 (es) Procedimiento y nodo para seleccionar una bandeja de mensajes
WO2017200478A1 (en) Method performed in radio network nodes for efficient handling of sctp based communcation