ES2960061T3

ES2960061T3 - Métodos, dispositivos y sistemas de cobro

Info

Publication number: ES2960061T3
Application number: ES21189580T
Authority: ES
Inventors: Xiaoqian Chai
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2017-06-30
Filing date: 2018-04-20
Publication date: 2024-02-29
Anticipated expiration: 2038-04-20
Also published as: CN111211913A; EP3634016A4; US10715680B2; EP3968664C0; EP3968664A1; EP3634016B1; US20220247868A1; CN109218032A; CN114500126A; US20200169639A1; WO2019001109A1; CN109218032B; CN111211913B; EP3634016A1; US20200288021A1; US11811965B2; US11330113B2; EP3968664B1

Abstract

Las realizaciones de esta aplicación proporcionan un método de cobro, que incluye: determinar, mediante una función de gestión de sesión SMF, un flujo de datos enrutado por cada función UPF del plano de usuario y una clave de cobro del grupo de clasificación correspondiente al flujo de datos; para cada UPF, enviar, por parte de la SMF a un sistema de tarificación en línea OCS, una solicitud de cuota de al menos una clave de tarificación que no tiene cuota disponible en la UPF, recibir, por parte de la SMF, una cuota concedida por la OCS a al menos una clave de cobro en la UPF, y entrega, por parte del SMF, de la cuota otorgada a la UPF; recibir, por parte de la SMF, información sobre el uso de cuotas que corresponda a al menos una cuota y que sea reportada por al menos una UPF; y enviar, por la SMF al OCS, un mensaje de informe de cobro generado en base a la información de uso de cuota correspondiente a al menos una cuota. Esto resuelve un problema de cobro en línea en una arquitectura de red que tiene una pluralidad de planos de usuario. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Métodos, dispositivos y sistemas de cobro

Campo técnico

Esta solicitud se relaciona con el campo de las comunicaciones y, en particular, con un método de cobro realizado por una función de gestión de sesiones (SMF), un dispositivo de cobro de SMF, un método de cobro realizado por un sistema de cobro en línea (OCS), un dispositivo de OCS, un sistema de cobro que comprende los dispositivos SMF y OCS y un método de sistema de cobro para realizar las etapas de método correspondientes de la SMF y el OCS.

Antecedentes

Actualmente, un mecanismo básico de cobro en línea es el siguiente: Se aplica una función de activación de cobro (Charging Trigger Function, CTF) para reservar una cuota de un grupo de calificación (Rating Group) de un sistema de cobro en línea (Online Charging System, OCS), el OCS otorga una cuota, y la CTF realiza la gestión de cuotas, el uso de cuotas y la recopilación de información de cobro, y cuando detecta que se cumple una condición de informe de cobro (condición de activación), informa la información de cobro recopilada al sistema de cobro.

En una red 4G, una función de cumplimiento de cobros y políticas (Policy and Charging Enforcement Function, PCEF) en una puerta de enlace es una CTF. La PCEF determina un modo de cobro (cobro en línea o cobro fuera de línea), un método de recopilación de estadísticas (tráfico, duración o similar), un grupo de calificación (Rating Group, denominado clave de cobro en esta solicitud), una granularidad de informes, y similares según una política de cobro suministrada por una función de reglas de cobros y políticas (Policy and Charging Rules Function PCRF). Una granularidad de cobro incluye service_identifier_level o rating_group_level. Si la granularidad de cobro es rating_group_level, la PCEF necesita informar información de cobro para cada grupo de calificación. Si la granularidad de cobro es service_identifier_level, la PCEF necesita informar información de cobro para cada grupo de calificación y cada identificador de servicio.

El drástico aumento del tráfico de datos plantea nuevos desafíos a las redes móviles. Para hacer frente a los desafíos, aparece una arquitectura de red de datos móviles evolucionada que separa un plano de control de un plano de usuario. En la arquitectura, solo el control se realiza en el plano de control y la implementación puede centralizarse; y un flujo de datos pasa a través del plano de usuario y se distribuye la implementación. Un usuario puede acceder a un plano de usuario cercano, para reducir la distancia de transmisión de datos de la red y el retraso de la red y mejorar la eficiencia de la red.

Actualmente, la arquitectura de red que separa un plano de control de un plano de usuario ya está extendida en una red 4G, y el cobro se puede implementar hasta cierto punto en la arquitectura de red que separa un plano de control de un plano de usuario. En la arquitectura, la proporción entre una cantidad de planos de control y una cantidad de planos de usuario es de 1:1. Como se muestra en la FIG. 1, una puerta de enlace de servicio C, una puerta de enlace de PDN C y una TDF-C son planos de control, y una puerta de enlace de servicio U, una puerta de enlace de PDN U y una TDF-U son planos de usuario. Un plano de control es un punto de activación de cobro y realiza una función de activación de cobro, y un plano de usuario es un punto de recopilación de cobros y realiza una función de recopilación de cobros.

Sin embargo, en una arquitectura de red de nueva generación, para reducir el retraso de la red y mejorar la eficiencia de la red en un proceso de movimiento de un usuario, el plano de usuario puede cambiarse mientras el plano de control permanece sin cambios. Además, un usuario puede utilizar simultáneamente un servicio local (por ejemplo, un servicio de operador como realizar una llamada o enviar un mensaje SMS) y un servicio externo (por ejemplo, acceso a internet). Para mejorar la eficacia de acceso, el usuario puede conectarse simultáneamente a una pluralidad de planos de usuario, donde cada plano de usuario procesa un escenario de servicio diferente.

En este caso, existe un mismo grupo de calificación en diferentes planos de usuario. En un mecanismo de control de crédito en línea actual, una cuota otorgada por un OCS se distribuye a diferentes planos de usuario para su uso, pero el uso de la cuota de servicio en los diferentes planos de usuario difiere mucho (por ejemplo, en la velocidad). Esto afecta seriamente la eficiencia, los costes y la precisión de la gestión de cuotas.

El documento "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Study on charging aspects of 5G system architecture Phase 1 (Release 15)", de 3GPP STANDARD; INFORME TÉCNICO; 3GPP TR 32.899, PROYECTO DE ASOCIACIÓN DE 3a GENERACIÓN (3GPP), CENTRO DE COMPETENCIA MÓVIL; 650, RUTA DES LUCIOLES; F-06921 SOPHIA-ANTIPOLIS CEDEX; FRANCIA, vol. SA WG5, n.° V0.2.0, páginas 1 a 40, 15 de junio de 2017, estudia la arquitectura, principios y funcionalidades de cobro para un Sistema 5G.

Compendio

Los objetos mencionados anteriormente se resuelven mediante las características de las reivindicaciones independientes. Las realizaciones y aspectos que no están cubiertos por la invención deben considerarse como ejemplos útiles para entender la invención.

Realizaciones de esta solicitud proporcionan un método de cobro realizado por una función de gestión de sesiones (SMF), un dispositivo de cobro de SMF, un método de cobro realizado por un sistema de cobro en línea (OCS), un dispositivo de OCS, un sistema de cobro que comprende los dispositivos de SMF y OCS y un método de sistema de cobro para realizar las etapas de método correspondientes de la SMF y el OCS, para resolver un problema de cobro en línea en una arquitectura de red que tiene una pluralidad de planos de usuario.

Según un primer aspecto, se proporciona un método de cobro que incluye: determinar, mediante una función de gestión de sesiones SMF, un flujo de datos enrutado por cada función de plano de usuario UPF y una clave de cobro correspondiente al flujo de datos; para cada<u>P<f>, enviar, por parte de la SMF a un sistema de cobro en línea OCS, una solicitud de cuota de al menos una clave de cobro sin cuota disponible para la UPF, recibir, por parte de la SMF, una cuota otorgada por el OCS a la por lo menos una clave de cobro para la UPF, y entregar, por parte de la SMF, la cuota otorgada a la UPF; recibir, por parte de la SMF, información de uso de cuota que corresponda a por lo menos una cuota y que sea informada por al menos una UPF; y enviar, por la SMF al OCS, un mensaje de informe de cobro generado en función de la información de uso de cuota correspondiente a la al menos una cuota. Se distinguen diferentes UPF para otorgar y gestionar cuotas correspondientes a claves de cobro, para mejorar la precisión del control de autorización de créditos y la eficiencia de la red, y resolver un problema de cobro en línea en una arquitectura de red con una pluralidad de planos de usuarios.

Con referencia al primer aspecto, en una primera implementación posible del primer aspecto, cada solicitud de cuota incluye un identificador de una UPF correspondiente y una clave de cobro correspondiente, la SMF añade cada solicitud de cuota a un mismo mensaje de solicitud de cuota enviado al OCS, y el mensaje de solicitud de cuota lleva una solicitud de cuota de al menos una UPF.

Con referencia al primer aspecto o la primera implementación posible del primer aspecto, en una segunda implementación posible, la SMF envía el mensaje de solicitud de cuota al<o>C<s>para cada UPF, cada mensaje de solicitud de cuota incluye un identificador de cobro de una UPF correspondiente e incluye una solicitud de cuota de al menos una clave de cobro para la UPF correspondiente, y cada solicitud de cuota incluye una clave de cobro correspondiente.

Las dos maneras diferentes anteriores de solicitud de cuotas se pueden seleccionar según los requisitos reales, de modo que la solución se implemente de manera más flexible.

Con referencia a cualquiera del primer aspecto o las implementaciones posibles primera y segunda del primer aspecto, en una tercera implementación posible, la SMF recibe un mensaje de respuesta de cuotas, y el mensaje de respuesta de cuotas incluye la cuota otorgada a la por lo menos una clave de cobro en cada UPF, y un identificador de la UPF correspondiente a la cuota.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a tercera del primer aspecto, en una cuarta implementación posible, la SMF recibe por separado mensajes de respuesta de cuotas correspondientes a diferentes UPF, y el mensaje de respuesta de cuotas incluye un identificador de cobro de una UPF correspondiente y una cuota otorgada a al menos una clave de cobro para la UPF correspondiente.

Para las dos maneras diferentes de solicitud de cuota, esta realización de esta solicitud también proporciona dos maneras de devolución de cuota otorgada.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a cuarta del primer aspecto, en una quinta implementación posible, el mensaje de informe de cobro incluye la información de uso de cuota correspondiente a la al menos una cuota, y además incluye un identificador de una UPF correspondiente a la cuota y una clave de cobro correspondiente, y el mensaje de informe de cobro lleva información de uso de cuota de la al menos una UPF.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a quinta del primer aspecto, en una sexta implementación posible, la SMF envía el mensaje de informe de cobro al OCS para cada UPF, y el mensaje de informe de cobro incluye un identificador de cobro de una UPF correspondiente, e incluye información de uso de cuota correspondiente a al menos una cuota de la UPF correspondiente.

Para las dos maneras diferentes de solicitud y otorgación de cuotas, esta realización de esta solicitud también proporciona dos maneras de comunicar la información de uso de cuota.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a sexta del primer aspecto, en una séptima implementación posible, la SMF determina, según una política entregada o activada por una PCF, la clave de cobro correspondiente al flujo de datos enrutado por cada UPF.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a séptima del primer aspecto, en una octava implementación posible, antes de que la SMF determine el flujo de datos enrutado por cada UPF y la clave de cobro correspondiente al flujo de datos, la SMF recibe una solicitud de establecimiento de sesión de PDU de sesión de usuario.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a octava del primer aspecto, en una novena implementación posible, antes de que la SMF reciba la cuota otorgada por la OCS, la SMF inicia, al OCS, una solicitud de establecer una sesión de cobro en línea correspondiente a una sesión de PDU.

Con referencia a cualquiera del primer aspecto o de la primera a la novena implementaciones posibles del primer aspecto, en una décima implementación posible, antes de que la SMF determine el flujo de datos enrutado por cada UPF y la clave de cobro correspondiente al flujo de datos, la SMF realiza la selección de UPF o la reselección de UPF.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a décima del primer aspecto, en una undécima implementación posible, la<s>M<f>realiza la selección de UPF cuando establece la sesión de PDU, y la SMF realiza la reselección de UPF cuando se añade o elimina una UPF de anclaje para la sesión de PDU, o ajusta un flujo de datos de un servicio entre UPF.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a undécima del primer aspecto, en una duodécima implementación posible, la UPF es una UPF que realiza una política de control entregada por la función de control de políticas PCF, o la UPF es un clasificador o un punto de ramificación.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a undécima del primer aspecto, en una decimotercera implementación posible, cuando la UPF es un clasificador o un punto de ramificación, la SMF recibe información de uso de cuota informada por el clasificador o el punto de ramificación y los anclajes de UPF se distinguen entre sí para la información de uso de cuota.

Con referencia a cualquiera del primer aspecto o de las implementaciones posibles primera a decimotercera del primer aspecto, en una decimocuarta implementación posible, la SMF determina, en función de al menos uno de un tipo de servicio, carga de UPF y una política de control configurada en la SMF o recibida de la PCF, el flujo de datos enrutado por cada UPF.

Según un segundo aspecto, se proporciona un método de cobro que incluye: recibir, por un sistema de cobro en línea OCS desde una función de gestión de sesiones SMF, una solicitud de cuota, de cada función de plano de usuario UPF, para al menos una clave de cobro sin cuota disponible; enviar, por el OCS a la SMF, una cuota otorgada a la al menos una clave de cobro sin cuota disponible; y recibir, por parte del OCS, un mensaje de informe de cobro procedente de la SMF, donde el mensaje de informe de cobro incluye información de uso de cuota correspondiente a al menos una cuota.

Se distinguen diferentes UPF para otorgar y gestionar cuotas correspondientes a claves de cobro, para mejorar la precisión del control de autorización de créditos y la eficiencia de la red, y resolver un problema de cobro en línea en una arquitectura de red con una pluralidad de planos de usuarios.

Con referencia al segundo aspecto, en una primera implementación posible del segundo aspecto, cada solicitud de cuota incluye un identificador de una UPF que solicita cuota y una clave de cobro correspondiente, la solicitud de cuota se lleva en un mensaje de solicitud de cuota, y el mensaje de solicitud de cuota lleva una solicitud de cuota de al menos una UPF.

Con referencia al segundo aspecto o la primera implementación posible del segundo aspecto, en una segunda implementación posible, una solicitud de cuota de cada UPF se lleva en un mismo mensaje de solicitud de cuota, las solicitudes de cuota de diferentes UPF se llevan en diferentes mensajes de solicitud de cuota, y cada mensaje de solicitud de cuota incluye un identificador de cobro de una UPF correspondiente e incluye una solicitud de cuota de al menos una clave de cobro para la UPF correspondiente.

Con referencia a cualquiera del segundo aspecto o las implementaciones posibles primera y segunda del segundo aspecto, en una tercera implementación posible, el OCS devuelve un mensaje de respuesta de cuotas a la SMF, y el mensaje de respuesta de cuotas incluye la cuota otorgada a la por lo menos una clave de cobro en cada UPF, y un identificador de la UPF correspondiente a la cuota.

Con referencia a cualquiera del segundo aspecto o de las implementaciones posibles primera a tercera del segundo aspecto, en una cuarta implementación posible, el OCS envía por separado mensajes de respuesta de cuotas correspondientes a diferentes UPF a la SMF, y el mensaje de respuesta de cuotas incluye un identificador de cobro de una UPF correspondiente y una cuota otorgada a al menos una clave de cobro para la UPF correspondiente.

Con referencia a cualquiera del segundo aspecto o de las implementaciones posibles primera a cuarta del segundo aspecto, en una quinta implementación posible, el mensaje de informe de cobro incluye la información de uso de cuota correspondiente a la al menos una cuota, y además incluye un identificador de una UPF correspondiente a la cuota y una clave de cobro correspondiente, y el mensaje de informe de cobro lleva información de uso de cuota de la al menos una UPF.

Con referencia a cualquiera del segundo aspecto o de las implementaciones posibles primera a quinta del segundo aspecto, en una sexta implementación posible, la información de uso de cuota de cada UPF se lleva en un mismo mensaje de informe de cobro, la información de uso de cuota de diferentes UPF se lleva en diferentes mensajes de notificación de cobro, y cada mensaje de información de cobros incluye un identificador de cobro de una UPF correspondiente e incluye información de uso de cuota correspondiente a al menos una cuota de la UPF correspondiente.

Con referencia a cualquiera del segundo aspecto o de las implementaciones posibles primera a sexta del segundo aspecto, en una séptima implementación posible, antes de que el OCS otorgue la cuota a la SMF, el OCS recibe, de la SMF, una solicitud de establecer una sesión de cobro en línea correspondiente a una sesión de PDU.

Según un tercer aspecto, se proporciona un método de cobro, que incluye: recibir, por una función de plano de usuario UPF, una cuota otorgada desde una función de gestión de sesiones SMF; recibir, por parte de la UPF, una pluralidad de flujos de datos, donde la cuota se utiliza para la pluralidad de flujos de datos, y recopilar, de manera diferenciada en función de anclajes de UPF correspondientes a la pluralidad de flujos de datos, estadísticas sobre información de uso de cuota correspondientes a la cuota; y enviar, por parte de la UPF, la información de uso de cuota correspondiente a la cuota a la SMF, donde la información de uso de cuota incluye valores de uso de cuota para los que se distinguen anclajes de UPF y un identificador de una UPF de anclaje correspondiente.

Con referencia al tercer aspecto, en una primera implementación posible del tercer aspecto, la UPF es un clasificador o un punto de ramificación.

Según un cuarto aspecto, se proporciona un dispositivo informático que incluye un procesador, una memoria, un bus y una interfaz de comunicaciones, donde la memoria se configura para almacenar una instrucción ejecutable por dispositivo informático, el procesador se conecta a la memoria utilizando el bus, y cuando el dispositivo informático funciona, el procesador ejecuta la instrucción ejecutable por ordenador almacenada en la memoria, de modo que el dispositivo informático realiza el método según cualquiera del primer aspecto o las implementaciones posibles del primer aspecto.

Según un quinto aspecto, se proporciona un dispositivo informático que incluye un procesador, una memoria, un bus y una interfaz de comunicaciones, donde la memoria se configura para almacenar una instrucción ejecutable del dispositivo informático, el procesador se conecta a la memoria mediante el bus, y cuando el dispositivo informático funciona, el procesador ejecuta la instrucción ejecutable por ordenador almacenada en la memoria, de modo que el dispositivo informático realiza el método según cualquiera del segundo aspecto o las implementaciones posibles del segundo aspecto.

Según un sexto aspecto, se proporciona un dispositivo informático que incluye un procesador, una memoria, un bus y una interfaz de comunicaciones, donde la memoria se configura para almacenar una instrucción ejecutable del dispositivo informático, el procesador se conecta a la memoria mediante el bus, y cuando el dispositivo informático funciona, el procesador ejecuta la instrucción ejecutable por ordenador almacenada en la memoria, de modo que el dispositivo informático realiza el método según cualquiera del tercer aspecto o las implementaciones posibles del tercer aspecto.

Según un séptimo aspecto, se proporciona un soporte de almacenamiento legible por ordenador, que almacena código de programa ejecutable, donde el código de programa se usa para implementar el método según cualquiera del primer aspecto o las implementaciones posibles del primer aspecto.

Según un octavo aspecto, se proporciona un soporte de almacenamiento legible por ordenador, que almacena código de programa ejecutable, donde el código de programa se usa para implementar el método según cualquiera del segundo aspecto o las implementaciones posibles del segundo aspecto.

Según un noveno aspecto, se proporciona un soporte de almacenamiento legible por ordenador, que almacena código de programa ejecutable, donde el código de programa se usa para implementar el método según cualquiera del tercer aspecto o las implementaciones posibles del tercer aspecto.

Según un décimo aspecto, se proporciona un aparato de cobro que incluye módulos configurados para realizar el método según cualquiera del primer aspecto o las implementaciones posibles del primer aspecto.

Según un undécimo aspecto, se proporciona un aparato de cobro que incluye módulos configurados para realizar el método según cualquiera del segundo aspecto o las implementaciones posibles del segundo aspecto.

Según un duodécimo aspecto, se proporciona un aparato de cobro que incluye módulos configurados para realizar el método según cualquiera del tercer aspecto o las implementaciones posibles del tercer aspecto. Según las soluciones técnicas proporcionadas en las realizaciones de esta solicitud, se distinguen diferentes UPF para otorgar y gestionar cuotas correspondientes a claves de cobro, mejorar la precisión del control de autorización de créditos y la eficiencia de la red, y resolver un problema de cobro en línea en una arquitectura de red con una pluralidad de planos de usuarios.

Breve descripción de los dibujos

Para describir más claramente las soluciones técnicas en las realizaciones de esta solicitud o en la técnica anterior, a continuación, se describen brevemente los dibujos adjuntos requeridos para describir las realizaciones o la técnica anterior.

La FIG. 1 es un diagrama esquemático de una arquitectura de red en la que un plano de control y un plano de usuario están separados en la técnica anterior;

la FIG. 2 es un diagrama esquemático de una arquitectura de red según una realización de esta solicitud; la FIG. 3 es un diagrama esquemático de una estructura de hardware de un dispositivo informático 300 según una realización de esta solicitud;

la FIG. 4 es un diagrama de flujo ilustrativo de un método de cob 4ro00 según una realización de esta solicitud; la FIG. 5 es un diagrama de flujo ilustrativo de un método de cob 5ro00 según una realización de esta solicitud; la FIG. 6 es un diagrama de flujo ilustrativo de un método de cob 6ro00 según una realización de esta solicitud; la FIG. 7 es un diagrama de flujo ilustrativo de un método de cob 7ro00 según una realización de esta solicitud; la FIG. 8 es un diagrama de flujo ilustrativo de un método de cob 8ro00 según una realización de esta solicitud; la FIG. 9 es un diagrama estructural esquemático de un dispositivo de carga 900 según una realización de esta solicitud; y

La FIG. 10 es un diagrama estructural esquemático de un sistema de cobro 1000 según una realización de esta solicitud.

Descripción de realizaciones

Los nombres de elementos de red descritos en las realizaciones de esta solicitud no constituyen una limitación para los dispositivos. Específicamente, el nombre de una función de gestión de sesiones no constituye una limitación para un dispositivo, y puede ser otro nombre en la práctica, por ejemplo, un gestor de sesiones (Session Manager). El nombre de una función de control de políticas no constituye una limitación para un dispositivo y, en la práctica, puede ser otro nombre, por ejemplo, un controlador de políticas (Policy Controller). El nombre de una función de plano de usuario no constituye una limitación para un dispositivo, y puede ser otro nombre en la práctica, por ejemplo, una entidad de función de plano de usuario (User Plane Function Entity). El nombre de un sistema de cobro en línea no constituye una limitación para un dispositivo y, en la práctica, puede ser otro nombre, por ejemplo, un sistema de cobro u otro nombre. Esto se describe colectivamente en esta memoria, y ya no se describe a continuación en detalle.

Las soluciones en las realizaciones de esta solicitud pueden aplicarse a sistemas 5G y otros futuros.

La FIG. 2 es un diagrama esquemático de una arquitectura de red según una realización de esta solicitud. Una SMF es una función de gestión de sesiones (Session Management Function), una PCF es una función de control de políticas (Policy Control Function), una UPF es una función de plano de usuario (User Plane Function), un OCS es un sistema de cobro en línea (Online Charge System), y UE es equipo de usuario (user equipment). La SMF se comunica con la PCF a través de una interfaz N7, la SMF se comunica con la UPF a través de una interfaz N4 y las diferentes UPF se comunican entre sí a través de una interfaz N9.

Las funciones de la SMF incluyen: gestión, como establecimiento, modificación y liberación, de una sesión (Session) de unidad de datos de protocolo (Protocol Data Unit, PDU), protocolo de internet (Internet Protocol, IP), asignación de direcciones del UE, selección de UPF, configuración de la política de enrutamiento de la UPF, obtención de una política de control de la PCF y ejecución de una parte de plano de control de la política de control, y determinación de un modo de continuidad de servicio y sesión (Service and Session Continuity, SSC) (denominado modo SSC) de la sesión de PDU bajo un tipo de IP.

Las funciones de la UPF incluyen: completar una función de anclaje de interacción con una red de datos externa (una UPF que tiene una función de anclaje se denomina UPF de anclaje), enrutamiento y reenvío de paquetes de datos, detección de paquetes de datos y ejecución de una parte de plano de usuario de una política de control activada por la PCF.

Las funciones de la PCF incluyen la generación y entrega de una política, o la activación de una política configurada estáticamente en la SMF, y el control, mediante el uso de una política, de QoS, control de entrada, cobro y similares de un flujo de datos de servicio enrutado por una UPF. La SMF puede determinar, según la política entregada por la PCF, si establecer una sesión de cobro en línea con el OCS y determinar una clave de cobro correspondiente al flujo de datos del servicio.

Las funciones del OCS incluyen realizar la otorgación de cuotas según una solicitud de la SMF y realizar la deducción o devolución de saldos en función de la información de uso de cuota informada por la SMF.

El UE es un dispositivo que tiene una identidad permanente de abonado (Subscriber Permanent Identity, SUPI) o una identidad de abonado móvil internacional (International Mobile Subscriber Identity Number, IMSI), o puede ser un teléfono móvil con una SIM/eSIM, una tableta, un ordenador, un dispositivo IoT u otro dispositivo que pueda estar conectado a una red 5G. La SMF, el OCS y la UPF pueden implementarse en forma de dispositivo informático. La FIG. 3 es un diagrama esquemático de una estructura de hardware de un dispositivo informático 300 según una realización de esta solicitud. Como se muestra en la FIG. 3, el dispositivo informático 300 incluye un procesador 302, una memoria 304, una interfaz de comunicaciones 306 y un bus 308. El procesador 302, la memoria 304 y la interfaz de comunicación 306 están en una conexión de comunicación entre sí utilizando el bus 308.

El procesador 302 puede ser una unidad central de procesamiento (Central Processing Unit, CPU) de propósito general, un microprocesador, un circuito integrado de aplicación específica (Application Specific Integrated Circuit, ASIC) o uno o más circuitos integrados, para ejecutar un programa relacionado para implementar las soluciones técnicas de las realizaciones de esta solicitud.

La memoria 304 puede ser una memoria de solo lectura (Read Only Memory, ROM), un dispositivo de almacenamiento estático, un dispositivo de almacenamiento dinámico o una memoria de acceso aleatorio (Random Access Memory, RAM). La memoria 304 puede almacenar un sistema operativo 3041 y otro programa de aplicación 3042. Cuando las soluciones técnicas proporcionadas en las realizaciones de esta solicitud se implementan mediante el uso de software o firmware, el código de programa utilizado para implementar las soluciones técnicas proporcionadas en las realizaciones de esta solicitud se almacena en la memoria 304 y es ejecutado por el procesador 302. La interfaz de comunicaciones 306 usa un aparato transceptor, por ejemplo, pero sin limitarse a un transceptor, para implementar la comunicación con otro dispositivo o una red de comunicaciones.

El bus 308 puede incluir un canal para transferir información entre componentes (por ejemplo, el procesador 302, la memoria 304 y la interfaz de comunicaciones 306).

Cuando el dispositivo informático 300 es una SMF, el procesador 302 ejecuta el código de programa almacenado en la memoria 304 para implementar las soluciones técnicas proporcionadas en las realizaciones de esta solicitud, para implementar los métodos proporcionados en las realizaciones que se muestran en la FIG. 4 a la FIG. 8.

Cuando el dispositivo informático 300 es un OCS, el procesador 302 ejecuta el código de programa almacenado en la memoria 304 para implementar las soluciones técnicas proporcionadas en las realizaciones de esta solicitud, para implementar los métodos proporcionados en las realizaciones que se muestran en la FIG. 4 a la FIG. 8.

Cuando el dispositivo informático 300 es una UPF, el procesador 302 puede ejecutar además el código de programa almacenado en la memoria 304 para implementar las soluciones técnicas proporcionadas en las realizaciones de esta solicitud, para implementar los métodos proporcionados en las realizaciones que se muestran en la FIG. 4 a la FIG. 8.

En esta realización de esta solicitud, se distinguen diferentes UPF para solicitar y otorgar una cuota, de manera que cuando diferentes UPF tienen una misma clave de cobro, la eficiencia y la precisión en la gestión de cuotas no se reducen por una diferencia de uso de cuotas en las diferentes UPF, y se puede mejorar la precisión del control de autorización de crédito y la eficiencia de la red.

A continuación se describe un proceso de distinción entre diferentes UPF para realizar la gestión de cuotas con referencia a implementaciones específicas.

La FIG. 4 es un diagrama de flujo ilustrativo de un método de cobro 400 según una realización de esta solicitud. A continuación, se describe cómo identificar diferentes UPF para realizar la gestión de cuotas con referencia a etapas específicas. El método de cobro 400 puede ser realizado por la SMF, el OCS y la UPF que se muestran en la FIG. 2.

S401: Una SMF recibe una solicitud de establecimiento de sesión de PDU del UE e inicia, a un OCS, para establecer una sesión de cobro en línea correspondiente a la sesión de PDU.

La sesión de PDU se establece entre el UE y una red de datos (Data Network, DN) que proporciona un servicio de conexión de PDU. Una UPF se conecta a la DN. Por lo tanto, en otras palabras, la sesión de PDU se establece entre el UE y la UPF. Debido a que el establecimiento de la sesión de PDU es controlado por la SMF, el UE envía la solicitud de establecimiento de sesión de PDU a la SMF, y la SMF selecciona una UPF que establece una conexión con el UE.

La sesión de cobro en línea se establece entre la SMF y el OCS. Para cobrar en línea un servicio usado, el OCS establece una sesión de cobro en línea correspondiente para cada sesión de PDU. La solicitud y otorgación de cuotas, y el informe de información de cobro, incluido el uso de cuotas, se realizan utilizando la sesión de cobro en línea establecida para la sesión de PDU.

Después de recibir la solicitud de establecimiento de sesión de PDU, la SMF solicita una política de control de una PCF. La política de control incluye información como una clave de cobro, control de calidad de servicio (Quality of Service, QoS), control de acceso y detección de aplicaciones. La SMF determina, según la política de control, la sesión de cobro en línea que debe establecerse para la sesión de PDU. La política de control puede ser entregada por la PCF a la SMF, o puede estar preconfigurada en la SMF y ser activada mediante la entrega de una instrucción de la PCF a la SMF.

Un mensaje de solicitud que envía la SMF al OCS para establecer la sesión de cobro en línea lleva un identificador de un usuario. Debido a que el UE tiene una pluralidad de direcciones IP, para evitar el desorden de gestión en el OCS, el usuario se identifica utilizando una SUPI o una IMSI.

A continuación se utiliza un protocolo Diameter como ejemplo para presentar el mensaje de solicitud para establecer la sesión de cobro en línea. Cabe señalar que el protocolo Diameter se utiliza simplemente como un ejemplo en esta memoria, un formato de mensaje no está limitado en esta solicitud, y se puede utilizar alternativamente otro formato de mensaje como REST API.

<CCR>

Session-Id // Identificador de sesión

Origin-Host // Host de origen

Origin-Realm // Reino de origen

Destination-Realm // Reino de destino

Auth-Application-Id // Identificador de aplicación

Service-Context-Id // Identificador de contexto de servicio

CC-Request-Type // Tipo de solicitud

CC-Request-Number //Número de secuencia del mensaje

Destination-Host // Host de destino

Suscription-Id //Identificador de usuario

S402: La SMF selecciona una UPF.

La SMF puede seleccionar una UPF en función de al menos una de las siguientes informaciones: una política de control, una carga dinámica de UPF, una capacitancia directa de UPF estática relativa que admita un mismo nombre de red de datos (Data Network Name, DNN), una ubicación de UPF disponible en la SMF, información de ubicación de UPF, una capacidad UPF y una función requerida por una sesión especial de UE, un nombre de red de datos, un tipo de sesión de PDU, un modo SSC seleccionado para una sesión de PDU, un perfil de suscripción de usuario en la gestión de datos de usuario (User Data Management, UDM), un destino de enrutamiento de tráfico e información relacionada con el segmento de red.

Además de la selección de UPF, la SMF determina además una UPF que necesita realizar una función de recopilación de estadísticas de cobros. En la aplicación real, las UPF seleccionadas por la SMF pueden incluir una UPF que realiza una política de control y una UPF que no realiza una política de control. La SMF determina la UPF que realiza una política de control como punto de recopilación de cobros para realizar una función de recopilación de estadísticas de cobros. En esta realización, las UPF seleccionadas por la SMF son UPF que realizan una política de control. Por lo tanto, las UPF seleccionadas por la SMF realizan una función de recopilación de estadísticas de cobros. Cuando la SMF selecciona solo una UPF, la UPF realiza la política de control y la función de recopilación de estadísticas de cobros.

S403: La SMF determina un flujo de datos enrutado por cada UPF y una clave de cobro correspondiente al flujo de datos.

La SMF puede determinar, según una política de control, un tipo de servicio, carga de UPF y similares, el flujo de datos enrutado por cada UPF.

Por ejemplo, un flujo de datos de un servicio (por ejemplo, un servicio de vídeo) puede asignarse a una UPF cerca del UE, un flujo de datos de un servicio que tiene un requisito de ancho de banda de QoS alto puede asignarse a una UPF que tiene un ancho de banda mayor, y si una UPF tiene excesiva carga, se asigna un flujo de datos a una UPF que tiene menor carga.

La SMF podrá determinar, según la política de control entregada o activada por la PCF, la clave de cobro correspondiente al flujo de datos. La política de control entregada o activada por la PCF incluye una plantilla de flujo y una clave de cobro correspondiente. La SMF determina la clave de cobro correspondiente en función de la UPF determinada y un estado de distribución de flujo de datos de la UPF y en función de una correspondencia entre un flujo de datos y una clave de cobro en la política de control.

S404: Para cada UPF, la SMF envía al OCS una solicitud de cuota de al menos una clave de cobro sin cuota disponible para la UPF, recibe una cuota otorgada por el OCS a la por lo menos una clave de cobro para la UPF, y entrega la cuota otorgada a la UPF.

Una operación de cada UPF se describe específicamente usando los siguientes S4041, S4042 y S4043.

S4041: La SMF envía al OCS la solicitud de cuota de la al menos una clave de cobro sin cuota disponible para la UPF.

No todas las claves de cobro necesitan usar una cuota, y la SMF solicita una cuota solo para una clave de cobro que necesita usar una cuota.

La clave de cobro sin cuota disponible incluye dos casos: primero, antes de que se solicite una cuota inicial de la clave de cobro, la clave de cobro no tiene cuota disponible; y segundo, para la clave de cobro, se solicita previamente una cuota, pero no hay ninguna cuota correspondiente a la clave de cobro disponible en la SMF porque la cuota se agota, caduca o similar.

Debido a que los flujos de datos enrutados por diferentes UPF pueden usar una misma clave de cobro, para evitar que el uso de cuotas de la misma clave de cobro de las diferentes UPF interfiera entre sí durante la gestión de cuotas, la SMF solicita por separado una cuota del OCS para la misma clave de cobro de las diferentes UPF.

De manera similar, los flujos de datos enrutados por una misma UPF pueden usar diferentes claves de cobro, y la SMF solicita cuotas separadas del OCS para las diferentes claves de cobro de la misma UPF.

La SMF podrá solicitar una cuota a la OCS en los dos métodos siguientes.

Método 1: SMF añade un identificador de una UPF correspondiente y una clave de cobro correspondiente a la solicitud de cuota, donde se utilizan identificadores de diferentes<u>P<f>para identificar solicitudes de cuota de diferentes UPF. La SMF envía un mensaje de solicitud de cuota al OCS utilizando la sesión de cobro en línea establecida para la sesión de PDU en S401.

Específicamente, las solicitudes de cuota de una pluralidad de claves de cobro en una misma UPF y las solicitudes de cuota de claves de cobro en diferentes UPF de la sesión de PDU pueden llevarse en un mismo mensaje de solicitud de cuota enviado al OCS. Es decir, un mensaje de solicitud de cuota puede llevar solicitudes de cuota de una o más UPF, y las solicitudes de cuota de diferentes UPF pueden tener una misma clave de cobro o claves de cobro diferentes.

A continuación se utiliza un protocolo Diameter como ejemplo para presentar el mensaje de solicitud de cuota en el método 1. Cabe señalar que el protocolo Diameter se utiliza simplemente como ejemplo en esta memoria, un formato de mensaje no está limitado en esta solicitud y se puede utilizar alternativamente otro formato de mensaje como REST API.

<CCR>

Session-Id // Identificador de sesión

Subscription-Id // Identificador de usuario

Multiple-Services-Credit-Control // Solicitud de cuota de una clave de cobro 1 para una UPF1 Requested-Service-Unit // Cuota solicitada

Service-Identifier 1 // Identificador de servicio

Clave de cobro 1 (Charging Key 1) // Grupo de calificación

UPF1 // Identificador de la UPF1

Multiple-Services-Credit-Control // Solicitud de cuota de una clave de cobro 2 para la UPF1

Requested-Service-Unit // Cuota solicitada

Clave de cobro 2 (Charging Key 2) // Grupo de calificación

UPF1 // Identificador de la UPF1

Multiple-Services-Credit-Control // Solicitud de cuota de la clave de cobro 2 para la UPF2

Requested-Service-Unit // Cuota solicitada

Clave de cobro 2 (Charging Key 2) // Grupo de calificación

UPF2 // Identificador de la UPF2

En este ejemplo, el mensaje de solicitud de cuota incluye tres solicitudes de cuota: una solicitud de cuota de la clave de cobro 1 para la UPF1, una solicitud de cuota de la clave de cobro 2 para la UPF1 y una solicitud de cuota de la clave de cobro 2 para la UPF2. Cada solicitud de cuota incluye una clave de cobro correspondiente, una cuota solicitada para la clave de cobro correspondiente y un identificador de una UPF correspondiente. La solicitud de cuota de la clave de cobro 1 para la UPF1 incluye además un identificador de servicio Service-Identifier 1, que indica que un servicio cuyo identificador de servicio es Service-Identifier 1 usa exclusivamente la clave de cobro 1 y otro servicio no puede usar la clave de cobro 1.

Método 2: La SMF envía un mensaje de solicitud de cuota al OCS para cada UPF, donde cada mensaje de solicitud de cuota incluye un identificador de cobro de la UPF correspondiente e incluye una solicitud de cuota para al menos una clave de cobro para la UPF correspondiente, y cada solicitud de cuota incluye una clave de cobro correspondiente.

El identificador de cobro de la UPF aquí se usa para indicar que el mensaje de solicitud de cuota se usa para cobro de una UPF particular. El identificador de cobro de la UPF puede ser un identificador de una subsesión de cobro en una sesión de cobro de una sesión de PDU correspondiente a una UPF particular, u otro identificador. La SMF almacena una correspondencia entre el identificador de cobro de la UPF y la UPF.

La SMF divide la sesión de cobro en línea establecida para la sesión de PDU en S401 en una pluralidad de subsesiones de cobro y asigna una subsesión de cobro a cada UPF. Específicamente, la SMF puede asignar un identificador de subsesión de cobro a cada UPF. Cada subsesión de cobro es utilizada por una sola UPF. La cantidad de subsesiones de cobro es la misma que la de las UPF, y cada subsesión de cobro y una UPF están en una correspondencia uno a uno. Cada subsesión de cobro tiene un identificador de sesión único, y la SMF almacena una correspondencia entre una UPF y una subsesión de cobro. El OCS gestiona una cuota de manera distinguida en función de diferentes subsesiones de cobro. Las solicitudes de cuota de una pluralidad de claves de cobro en una misma UPF se llevan en un mismo mensaje de solicitud de cuota enviado al OCS, y las solicitudes de cuota de diferentes UPF no se pueden llevar en un mismo mensaje de solicitud de cuota. El mensaje de solicitud de cuota de cada UPF se transmite al OCS utilizando la subsesión de cobro correspondiente a la UPF.

A continuación se utiliza un protocolo Diameter como ejemplo para presentar el mensaje de solicitud de cuota en el método 2. Cabe señalar que el protocolo Diameter se utiliza simplemente como ejemplo en esta memoria, un formato de mensaje no está limitado en esta solicitud y se puede utilizar alternativamente otro formato de mensaje como REST API.

<CCR> // Mensaje CCR correspondiente a una UPF1, donde el mensaje CCR puede llevar una solicitud de cuota de una o más claves de cobro solo para la UPF1

Session-Id

CC-Sub-Session-Id 1 // Identificador de cobro de la UPF1

Subscription-Id

Multiple-Services-Credit-Control // Solicitud de cuota de una clave de cobro 1 para la UPF1

Requested-Service-Unit

Service-Identifier 1

Clave de cobro 1 (Charging Key 1)

Requested-Service-Unit

Clave de cobro 2 (Charging Key 2)

<CCR> // Mensaje CCR correspondiente a una UPF2, donde el mensaje puede llevar una solicitud de cuota de una o más claves de cobro solo para la UPF2

Session-Id

CC-Sub-Session-Id 2 // Identificador de cobro de la UPF2

Subscription-Id

Multiple-Services-Credit-Control // Solicitud de cuota de una clave de cobro 2 para la UPF2

Requested-Service-Unit

Clave de cobro 2 (Charging Key 2)

En este ejemplo, el mensaje de solicitud de cuota correspondiente a la UPF1 incluye dos solicitudes de cuota: la solicitud de cuota de la clave de cobro 1 y la solicitud de cuota de la clave de cobro 2. El mensaje de solicitud de cuota correspondiente a la UPF2 incluye una solicitud de cuota: la solicitud de cuota de la clave de cobro 2. El mensaje de solicitud de cuota correspondiente a la UPF1 incluye el identificador de cobro CC-Sub-Session-Id 1 de la UPF1, y el mensaje de solicitud de cuota correspondiente a la UPF2 incluye el identificador de cobro CC-Sub-Session-Id 2 de la UPF2. Cada solicitud de cuota incluye una clave de cobro y una cuota solicitada para la clave de cobro correspondiente.

Cabe señalar que en esta realización de esta solicitud, el mensaje de solicitud de cuota es un mensaje, como un CCR de Diameter, enviado por la SMF al OCS para solicitar una cuota. La solicitud de cuota es información de solicitud de una clave de cobro. La información de solicitud puede ser multiple-services-credit-control. La solicitud de cuota se incluye en el mensaje de solicitud de cuota.

Una cuota de una clave de cobro se puede solicitar de dos maneras. De una manera, se envía una cuota solicitada al OCS. De la otra manera, sólo se envía a la OCS una solicitud que no lleva una cuota específica, y la OCS determina una cuota otorgada.

S4042: La SMF recibe la cuota otorgada por el OCS a la al menos una clave de cobro de la UPF.

La al menos una clave de cobro para la UPF en esta etapa corresponde a la al menos una clave de cobro sin cuota disponible para la UPF en la etapa S4041.

Para los dos métodos para solicitar la cuota del OCS en S4041, el OCS también devuelve la cuota otorgada al SMF en dos métodos.

Para el método 1 en S4041, el OCS devuelve la cuota otorgada a la SMF en el siguiente método.

El OCS añade una cuota otorgada de al menos una clave de cobro en una misma UPF y cuotas otorgadas de claves de cobro en diferentes UPF de la sesión de PDU a un mismo mensaje de respuesta de cuotas devuelto a la SMF. El OCS identifica las cuotas otorgadas de diferentes UPF utilizando identificadores de las UPF, y añade, al mensaje de respuesta de cuotas, los identificadores de UPF correspondientes respectivamente a las cuotas otorgadas. El OCS envía el mensaje de respuesta de cuota a la SMF utilizando la sesión de cobro en línea establecida para la sesión de PDU en S401.

A continuación se utiliza un protocolo Diameter como ejemplo para presentar el mensaje de respuesta de cuota correspondiente al método 1. Cabe señalar que el protocolo Diameter se utiliza simplemente como ejemplo en esta memoria, un formato de mensaje no está limitado en esta solicitud y se puede utilizar alternativamente. otro formato de mensaje como REST API.

<CCA>

Session-Id

Multiple-Services-Credit-Control

Granted-Service-Unit // Cuota otorgada 1

Service-Identifier 1

Clave de cobro 1 (Charging Key 1)

UPF1 // Identificador de la UPF1

Multiple-Services-Credit-Control

Granted-Service-Unit // Cuota otorgada 2

Clave de cobro 2 (Charging Key 2)

UPF1 // Identificador de la UPF1

Multiple-Services-Credit-Control

Granted-Service-Unit // Cuota otorgada 3

Clave de cobro 2 (Charging Key 2)

UPF2 // Identificador de la UPF2

Para el método 2 en S4041, el OCS devuelve la cuota otorgada a la SMF en el siguiente método.

El OCS devuelve el mensaje de respuesta de cuotas para cada UPF. Cada mensaje de respuesta de cuotas incluye un identificador de cobro de una UPF correspondiente y una cuota otorgada a al menos una clave de cobro para la UPF correspondiente. El OCS añade, a un mismo mensaje de respuesta de cuotas, cuotas otorgadas a una pluralidad de claves de cobro sobre una misma UPF, y añade, a diferentes mensajes de respuesta de cuotas, cuotas otorgadas a diferentes UPF. El mensaje de respuesta de cuotas devuelto para cada UPF se transmite a la SMF mediante una subsesión de cobro correspondiente a la UPF.

A continuación se utiliza un protocolo Diameter como ejemplo para presentar el mensaje de respuesta de cuota en el método 2. Cabe señalar que el protocolo Diameter se utiliza simplemente como ejemplo en esta memoria, un formato de mensaje no está limitado en esta solicitud y se puede utilizar alternativamente otro formato de mensaje como REST API.

<CCA> // Mensaje CCA correspondiente a la UPF1, donde el mensaje puede llevar únicamente una cuota otorgada a una o más claves de cobro en la UPF1

Session-Id

CC-Sub-Session-Id 1 // Identificador de cobro de la UPF1

Multiple-Services-Credit-Control

Granted-Service-Unit // Cuota otorgada 1

Service-Identifier 1

Clave de cobro 1 (charging key 1) // Grupo de calificación 1 de la UPF1

Multiple-Services-Credit-Control

Granted-Service-Unit // Cuota otorgada 2

Clave de cobro 2 (charging key 2) // Grupo de calificación 2 de la UPF1

<CCA> // Mensaje CCA correspondiente a la UPF2, donde el mensaje puede llevar únicamente una cuota otorgada a una o más claves de cobro en la UPF2

Session-Id

CC-Sub-Session-Id 2 // Identificador de cobro de la UPF2

Multiple-Services-Credit-Control

Granted-Service-Unit // Cuota otorgada 3

Clave de cobro 2 (charging key 2) // Grupo de calificación 2 de la UPF2

S4043: La SMF entrega la cuota otorgada a la UPF.

La SMF entrega la cuota otorgada a la UPF correspondiente en función de una correspondencia entre la cuota y la UPF. En el método 1, la SMF entrega la cuota otorgada a la UPF correspondiente en función de la correspondencia entre la cuota otorgada y el identificador de la UPF. En el método 2, la SMF entrega la cuota otorgada a la UPF correspondiente en función de la correspondencia entre el identificador de cobro de la UPF y la UPF.

Según el ejemplo de la S4042, la SMF entrega a la UPF1 las cuotas 1 y 2 otorgadas por el OCS, y entrega la cuota 3 otorgada a la UPF2.

S405: La SMF recibe información de uso de cuota que corresponde a al menos una cuota y que es informada por al menos una UPF.

El uso de cuotas de diferentes claves de cobro en una misma UPF es independiente entre sí. El uso de cuotas de diferentes UPF también es independiente entre sí, independientemente de si las claves de cobro son las mismas.

La información de uso de cuota se informa cuando se cumple una condición de activación. Diferentes claves de cobro en una misma UPF pueden tener la misma condición de activación o pueden tener diferentes condiciones de activación. La misma clave de cobro en diferentes UPF pueden tener la misma condición de activación o pueden tener diferentes condiciones de activación. El informe de uso de cuotas de diferentes claves de cobro en una misma UPF es independiente entre sí. El informe de uso de cuotas de diferentes UPF también es independiente entre sí, independientemente de si las claves de cobro son las mismas. La condición de activación incluye que se agote una cuota, que caduque, que se cumpla una condición de informe especificada por el OCS (por ejemplo, un cambio de QoS, un cambio de ubicación o un cambio de tipo de acceso) y que se libere una sesión de PDU.

Se supone que se agota la cuota 1 de la clave de cobro 1 en la UPF1, y se agota la cuota 3 de la clave de cobro 2 en la UPF2. En este caso, se cumple la condición de activación, la UPF1 informa la información de uso de cuota de la clave de cobro 1 a la SMF, y la UPF2 informa la información de uso de cuota de la clave de cobro 2 a la SMF.

S406: La SMF envía, al OCS, un mensaje de informe de cobro generado en función de la información de uso de cuota correspondiente a la al menos una cuota.

La SMF determina, en función de la información de uso de cuota de cada cuota, una UPF correspondiente de la cuota y una clave de cobro correspondiente, y envía la información de uso de cuota de la cuota, la UPF correspondiente y la clave de cobro correspondiente al OCS mediante el uso de la mensaje de informe de cobro.

Para el método 1 en S4041, la SMF envía la información de uso de cuota al OCS usando el siguiente método. La SMF añade información de uso de cuota de una pluralidad de cuotas de una misma UPF, e información de uso de cuota de las cuotas de diferentes UPF en la sesión de PDU al mismo mensaje de informe de facturación enviado al OCS. La SMF distingue la información de uso de cuota de diferentes UPF mediante el uso de identificadores de UPF. La SMF envía el mensaje de informe de cobreo al OCS utilizando la sesión de cobro en línea establecida para la sesión de PDU en S401.

A continuación se utiliza un protocolo Diameter como ejemplo para presentar el mensaje de informe de cobro en el método 1. Cabe señalar que el protocolo Diameter se utiliza simplemente como ejemplo en esta memoria, un formato de mensaje no está limitado en esta solicitud y se puede utilizar alternativamente otro formato de mensaje como REST API.

En este ejemplo, suponiendo que la cuota 1 de la clave de cobro 1 en la UPF1 y la cuota 3 de la clave de cobro 2 en la UPF2 cumplen la condición de activación, el mensaje de cobro informado es el siguiente:

<CCR>

Session-Id

Multiple-Services-Credit-Control

Used-Service-Unit // información de uso de cuota de la cuota 1

Requested-Service-Unit // Cuota recientemente solicitada de la clave de cobro 1 en la UPF1

Clave de cobro 1 (Charging Key 1)

UPF1 // Identificador de la UPF1

Multiple-Services-Credit-Control //

Used-Service-Unit // información de uso de cuota de la cuota 3

Requested-Service-Unit // Cuota recientemente solicitada de la clave de cobro 2 en la UPF2

Clave de cobro 2 (Charging Key 2)

UPF2 // Identificador de la UPF2

En este ejemplo, el mensaje de informe de cobro incluye dos piezas de información de uso de cuota: la información de uso de cuota de la cuota 1 en la UPF1 y la información de uso de cuota de la cuota 3 en la UPF2. El mensaje de información de cobros incluye una clave de cobro correspondiente a la cuota 1 y un identificador de UPF correspondiente a la cuota 1, es decir, la clave de cobro 1 y la UPF1; incluye una clave de cobro correspondiente a la cuota 3 y un identificador de UPF correspondiente a la cuota 3, es decir, la clave de cobro 2 y la UPF2; e incluye además una cuota recién solicitada de una clave de cobro correspondiente. Cuando un servicio no finaliza, se solicita una nueva cuota mientras se informa la información de uso de cuota. Para el método 2 en S4041, la SMF envía la información de uso de cuota al OCS usando el siguiente método. La SMF envía el mensaje de informe de cobro al OCS para cada UPF, donde cada mensaje de informe de cobro incluye un identificador de cobro de una UPF correspondiente e incluye información de uso de cuota correspondiente a al menos una cuota de la UPF. La SMF añade información de uso de cuota de una pluralidad de cuotas de una misma UPF a un mismo mensaje de cobro enviado al OCS, y añade información de uso de cuota de las cuotas de diferentes UPF a diferentes mensajes de informe de cobro. El mensaje de informe de cobro para cada UPF se transmite al OCS utilizando una subsesión de cobro correspondiente a la UPF. A continuación se utiliza un protocolo Diameter como ejemplo para presentar el mensaje de informe de cobro en el método 2. Cabe señalar que el protocolo Diameter se utiliza simplemente como ejemplo en esta memoria, un formato de mensaje no está limitado en esta solicitud y se puede utilizar alternativamente otro formato de mensaje como REST API.

<CCR>

Session-Id

CC-Sub-Session-Id 1 // Identificador de cobro de la UPF1

Multiple-Services-Credit-Control

Used-Service-Unit // información de uso de cuota de la cuota 1

Clave de cobro 1 (Charging Key 1)

<CCR>

Session-Id

CC-Sub-Session-Id 2 // Identificador de cobro de la UPF2

Multiple-Services-Credit-Control

Used-Service-Unit // información de uso de cuota de la cuota 3

Clave de cobro 2 (Charging Key 2)

El OCS cobra según el grupo de calificación y la información de uso de cuota después de recibir el mensaje de informe de cobro.

Cuando la sesión de PDU debe liberarse posteriormente, si el usuario deja de usar el servicio, la SMF instruye a todas las UPF involucradas en la sesión de PDU para que informen la información de uso de cuota, la SMF genera el mensaje de informe de cobro basado en la información de uso de cuota, envía el mensaje de informe de cobro al OCS, y libera la sesión de cobro en línea establecida para la sesión de PDU. Para una manera de enviar el mensaje de informe de cobro por la SMF al OCS, consúltese las dos maneras en S406, y los detalles no se describen en esta memoria nuevamente.

Una secuencia de las tres etapas de S401, S402 y S403 puede cambiar. El establecimiento de la sesión de cobro en línea y la solicitud de la cuota se pueden combinar en un solo mensaje. Por ejemplo, durante el establecimiento de la sesión de cobro en línea, la clave de cobro correspondiente al flujo de datos ya está determinada, y la solicitud de cuota puede llevarse en el mensaje de solicitud para establecer la sesión de cobro en línea.

Según la solución técnica proporcionada en esta realización de esta solicitud, se distinguen diferentes UPF para otorgar y gestionar cuotas correspondientes a claves de cobro, mejorar la precisión del control de autorización de créditos y la eficiencia de la red, y resolver un problema de cobro en línea en una arquitectura de red con una pluralidad de planos de usuarios. La FIG. 5 es un diagrama de flujo ilustrativo de un método de cobro 500 según una realización de esta solicitud. A diferencia de la realización de la FIG. 4, en la realización de la FIG. 5, una UPF seleccionada por una SMF incluye un clasificador (Classifier) o un punto de ramificación (Branching Point). La SMF determina el clasificador o el punto de ramificación como un punto de recopilación de cobros para realizar una función de recopilación de estadísticas de cobros. Si la SMF determina una UPF que realiza una política de control como un punto de recopilación de cobros, para realizar una función de recopilación de estadísticas de cobros, cuando el clasificador o el punto de ramificación realiza la política de control, se utiliza el método en la realización de la FIG. 5; o cuando una UPF de anclaje realiza la política de control, se utiliza el método en la realización de la FIG. 4. Un flujo de datos de enlace ascendente desde el UE pasa primero por el clasificador o el punto de ramificación, y el clasificador o el punto de ramificación divide el flujo de datos en diferentes anclajes de UPF. Un flujo de datos de enlace descendente primero pasa a través de diferentes anclajes de UPF y luego pasa a través del clasificador o el punto de ramificación, y el clasificador o el punto de ramificación combina flujos de datos de enlace descendente y entrega un flujo de datos de enlace descendente combinado al UE.

S501: Una SMF recibe una solicitud de establecimiento de sesión del UE e inicia, a un OCS, para establecer una sesión de cobro en línea correspondiente a la sesión de PDU.

Para contenido específico, consúltese S401 en la realización de la FIG. 4, y los detalles no se describen en esta memoria nuevamente.

S502: La SMF determina un clasificador como UPF que realiza una función de recopilación de estadísticas de cobros.

El clasificador o un punto de ramificación se usa para dividir un flujo de datos de enlace ascendente en un plano de usuario (dividir un flujo de datos del UE a diferentes anclajes de UPF) y combinar flujos de datos de enlace descendente (combinar flujos de datos de diferentes anclajes de UPF en un flujo de datos y entregar un flujo de datos combinado al UE). El clasificador o el punto de ramificación es también una UPF por la que pasan todos los flujos de datos. Por lo tanto, el clasificador o el punto de ramificación se puede utilizar como punto de recopilación de cobros.

Debido a que la ejecución de una política de control afecta la precisión de cobro, por ejemplo, una operación de control de compuerta de la política de control puede resultar en una pérdida de paquetes, el clasificador o el punto de ramificación pueden no realizar realmente la política de control. En este caso, si el cobro se realiza en función de todos los paquetes de datos que pasan por el clasificador o el punto de ramificación, las tarifas deducidas son mayores que los costes de uso reales. Por lo tanto, para garantizar la precisión del cobro, todas las políticas de control activadas por una PCF se configuran en el clasificador o el punto de ramificación, y el clasificador o el punto de ramificación recopila información de cobro después de simular la ejecución de una política de control, para garantizar que la información de cobro recopilada sea coherente con la información de cobro generada después de que la UPF realice la política de control.

Por ejemplo, suponiendo que hay una UPF1, una UPF2 y un clasificador para una sesión de PDU, la SMF determina el clasificador como una UPF que realiza una función de recopilación de estadísticas de cobros. Se supone que una política de control realizada por la UPF1 es la siguiente:

Regla de política 1

{

Flujo 1: descartar;

}

Regla de política 2

{

Flujo 2+Flujo 3: Clave de cobro 1, donde una prioridad es 1;

}

Regla de política 3

{

Flujo 3+Flujo 4: Clave de cobro 2, donde la prioridad es 2

}

La política de control también se entrega al clasificador. Si el clasificador detecta un paquete de datos perteneciente a un flujo 1, se simula la ejecución de la regla de política de política de control 1. Debido a que la regla de política 1 indica el descarte del paquete de datos, no se realiza la recopilación de estadísticas de cobros (en este caso, el clasificador en realidad no descarta el paquete de datos y, en cambio, la UPF que ejecuta la regla de política 1 realiza una operación de descarte). Si el clasificador detecta un paquete de datos perteneciente a un flujo 3, se simula la ejecución de la regla de política. El flujo 3 puede estar cubierto tanto por la clave de cobro 1 como por la clave de cobro 2. Sin embargo, según las prioridades de las dos claves de cobro, el flujo de datos del flujo 3 se compara con la clave de cobro 1. Por lo tanto, el clasificador o el punto de ramificación recopila estadísticas sobre el flujo de datos del flujo 3 mediante el uso de la clave de cobro 1. S503: La SMF determina un flujo de datos enrutado por el clasificador y una clave de cobro correspondiente al flujo de datos.

En esta realización, una pluralidad de UPF se involucran en la sesión de PDU, y la pluralidad de UPF incluye un clasificador o un punto de ramificación. Dado que todos los flujos de datos pasan por el clasificador o el punto de ramificación, la SMF determina un flujo de datos enrutado por el clasificador o el punto de ramificación y una regla de división. La regla de división se determina para determinar un camino de enrutamiento del flujo de datos, para transmitir el flujo de datos. Por ejemplo, UPF1, UPF2 y UPF3 se involucran en la sesión de PDU, donde UPF3 es un clasificador que realiza una función de recopilación de estadísticas de cobros y no realiza una política de control. La SMF determina un flujo de datos enrutados por la UPF3, y determina, según la regla de división, flujos de datos enrutados por la UPF1 y la UPF2.

S504: SMF envía una solicitud de cuota para una clave de cobro sin cuota disponible en el clasificador al OCS. Debido a que el clasificador realiza la función de recopilación de estadísticas de cobros y tiene la política de control, el clasificador almacena las claves de cobro correspondientes respectivamente a los flujos de datos. Para un proceso específico de solicitud de una cuota, consúltese S4041 en la realización de la FIG. 4, y los detalles no se describen en esta memoria nuevamente.

S505: La SMF recibe una cuota otorgada por el OCS a la clave de cobro sin cuota disponible en el clasificador. Para un proceso específico de devolución de una cuota otorgada por el OCS, consúltese S4042 en la realización de la FIG. 4, y los detalles no se describen en esta memoria nuevamente.

S506: La SMF entrega la cuota otorgada al clasificador.

En esta realización, el clasificador realiza la función de recopilación de estadísticas de cobros y la SMF entrega cada cuota otorgada al clasificador. El clasificador simula la ejecución de la política de control para generar información de uso de cuotas.

S507: La SMF recibe información de uso de cuota que corresponde a al menos una cuota y que es del clasificador. El clasificador identifica las UPF al informar cuotas de diferentes UPF. Cuando el clasificador envía información de uso de cuota correspondiente a una cuota a la SMF, la información de uso de cuota incluye el valor de uso de cuota para los anclajes de UPF identificados y un identificador de una UPF de anclaje correspondiente.

Se supone que se agota una cuota 1 de la clave de cobro 1 en la UPF1, y se agota una cuota 3 de la clave de cobro 2 en la UPF2. En este caso, se cumple una condición de activación y la UPF3 informa la información de uso de cuota de la cuota 1 en la UPF1 y la información de uso de cuota de la cuota 3 en la UPF2 a la SMF. Para un proceso específico, consúltese S407 en la realización de la FIG. 4.

S508: La SMF envía, al OCS, un mensaje de informe de cobro generado en función de la información de uso de cuota.

Para un proceso específico, consúltese S406 en la realización de la FIG. 4.

Diferentes UPF se otorgan y gestionan cuotas correspondientes a claves de cobro por separado, para mejorar la precisión del control de autorización de créditos y la eficiencia de la red, y resolver un problema de cobro en línea en una arquitectura de red con una pluralidad de planos de usuarios.

En la aplicación real, puede haber los siguientes tres escenarios:

(1) Se migra un flujo de datos de la UPF1 a la UPF2.

(2) Se añade una UPF a la sesión de PDU.

(3) Se elimina una UPF de la sesión de PDU.

A continuación se describe el primer escenario con referencia a la FIG. 6.

La SMF establece la sesión de cobro en línea para la sesión de PDU y solicita usando la sesión de cobro en línea cuotas para las claves de cobro utilizadas por el flujo de datos de la UPF1 y la UPF2. Para un proceso específico, consúltese de S401 a S404 en la realización de la FIG. 4.

S601: La SMF determina que al menos un flujo de datos de UPF1 debe migrarse a UPF2.

Específicamente, la SMF puede realizar la determinación en función de la información para la selección de UPF en S402 en la realización de la FIG. 4.

S602: La SMF o la UPF2 determina si hay una cuota disponible para una clave de cobro correspondiente al por lo menos un flujo de datos en la UPF2 actual, donde si hay una cuota disponible, el al menos un flujo de datos en la UPF2 utiliza la cuota disponible para la clave de cobro de la UPF2, o si no hay cuota disponible para la clave de cobro correspondiente a alguno de los al menos un flujo de datos en la UPF2, la SMF envía una solicitud de cuota al OCS, para solicitar una cuota de la clave de cobro correspondiente a algunos flujos de datos de la UPF2.

De manera similar, si no hay cuota disponible para una clave de cobro en la UPF, la SMF también solicita una cuota para la clave de cobro sin cuota disponible en la UPF1 y envía una solicitud de cuota a la OCS.

Para conocer una manera específica de solicitar una cuota por parte de la SMF, consúltese S4041 en la realización de la FIG. 4.

Por ejemplo, los flujos de datos enrutados por UPF1 incluyen un flujo de datos 1, un flujo de datos 2 y un flujo de datos 3, y las claves de cobro correspondientes son una clave de cobro 1, una clave de cobro 2 y una clave de cobro 3 respectivamente. El flujo de datos 1 y el flujo de datos 2 deben migrarse a la UPF2. Si la SMF o la UPF1 determina que hay cuota disponible para la clave de cobro 3 en la UPF, la SMF no solicita cuota al OCS para la clave de cobro 3 en la UPF1. La s Mf o la UPF2 determina que hay una cuota disponible para la clave de cobro 1 en la UPF2 y no hay cuota disponible para la clave de cobro 2. En este caso, el flujo de datos 1 utiliza la cuota disponible para la clave de cobro 1 en la UPF2, y la SMF no solicita una cuota al OCS para la clave de cobro 1 en la UPF2, y solicita una cuota para la clave de cobro 2 en la UPF2 al OCS.

S603: El OCS envía a la SMF una cuota otorgada a una clave de cobro correspondiente a unos flujos de datos en la UPF2.

Asimismo, el OCS también otorga una cuota para la clave de cobro sin cuota disponible en la UPF1.

Para un proceso específico, consúltese S4042 en la realización de la FIG. 4.

S604: La SMF envía la cuota otorgada a la UPF2.

Similarmente, la SMF también envía la cuota otorgada a la clave de cobro sin cuota disponible en la UPF1. S605: Migrar el al menos un flujo de datos a la UPF2.

S606: La UPF1 o la UPF2 informa la información de uso de cuota correspondiente a al menos una cuota a la SMF.

Para un proceso específico, consúltese S405 en la realización de la FIG. 4.

S607: La SMF envía, al OCS, un mensaje de informe de cobro generado en función de la información de uso de cuota.

Para un proceso específico, consúltese S406 en la realización de la FIG. 4.

Según la solución técnica proporcionada en esta realización de esta solicitud, a diferentes UPF se les otorga y gestiona una cuota correspondiente a una clave de cobro por separado, lo que simplifica un proceso de procesamiento durante el traspaso de flujo de datos entre diferentes UPF y mejora la eficiencia de la red. A continuación se describe el segundo escenario con referencia a la FIG. 7.

La SMF establece la sesión de cobro en línea para la sesión de PDU y solicita, utilizando la sesión de cobro en línea, una cuota para una clave de cobro correspondiente a un flujo de datos de la UPF1. Para un proceso específico, consúltese de S401 a S404 en la realización de la FIG. 4.

S701: La SMF determina que se debe añadir UPF2 para enrutar el flujo de datos.

S702: La SMF determina un flujo de datos de la UPF2 y una clave de cobro correspondiente.

Para un proceso específico, consúltese S403 en la realización de la FIG. 4.

S703: La SMF envía una solicitud de cuota de cada clave de cobro de la UPF2 al OCS.

Cabe señalar que en esta realización, antes de que se añada la UPF2, la sesión de PDU no involucra a la UPF2. Por tanto, no hay cuota disponible para la clave de cobro correspondiente al flujo de datos, de la sesión de la PDU, en la UPF2. Por tanto, la SMF solicita una cuota por cada clave de cobro de la UPF2.

Para un proceso específico, consúltese S4041 en la realización de la FIG. 4.

S704: El OCS envía a la SMF una cuota otorgada a cada clave de cobro para la UPF2.

Para un proceso específico, consúltese S4042 en la realización de la FIG. 4.

S705: La SMF envía la cuota otorgada a la UPF2.

S706: La UPF1 o la UPF2 informa la información de uso de cuota correspondiente a al menos una cuota a la SMF.

Para un proceso específico, consúltese S405 en la realización de la FIG. 4.

Se supone que la UPF1 enruta corrientes de datos de una corriente 1 y una corriente 2, donde la corriente 1 usa la clave de cobro 1 y la corriente 2 usa la clave de cobro 2. La UPF2 enruta una corriente de datos de una corriente 3, donde la corriente 3 utiliza la clave de cobro 2. Cuando se cumple una condición de activación correspondiente a la clave de cobro 1 en la UPF1, y se cumple una condición de activación correspondiente a la clave de cobro 2 en la UPF2, la UPF1 informa la información de uso de cuota de la clave de cobro 1 a la SMF, y la UPF2 informa la información de uso de cuota de la clave de cobro 2 a la SMF.

S707: La SMF envía, al OCS, un mensaje de informe de cobro generado en función de la información de uso de cuota.

Para un proceso específico, consúltese S406 en la realización de la FIG. 4.

En S703 a S705, si la UPF1 tiene una clave de cobro sin cuota disponible, la SMF también solicita una cuota para la UPF1, y los detalles no se describen en esta memoria nuevamente.

En esta realización, la UPF2 recién añadida puede ser un clasificador o un punto de ramificación. En este caso, el clasificador o el punto de ramificación es un punto de recopilación de cobros que realiza una función de recopilación de estadísticas de cobros. Todos los flujos de datos pasan por el clasificador o el punto de ramificación, y el clasificador o el punto de ramificación simula la ejecución de la política de control para cada flujo de datos. Por lo tanto, en este caso, en S706, la UPF2 (es decir, el clasificador o el punto de ramificación) envía la información de uso de cuota a la SMF y la UPF1 no envía la información de uso de cuota a la SMF.

Por ejemplo, se supone que la UPF1 enruta corrientes de datos de una corriente 1 y una corriente 2, donde la corrientes 1 usa la clave de cobro 1 y la corriente 2 usa la clave de cobro 2. La UPF2 recién añadida es el clasificador, la UPF2 enruta la corriente 1 y la corriente 2 y además enruta una corriente de datos de una corriente 3, donde la corriente 3 usa la clave de cobro 2. Cuando se cumple la condición de activación correspondiente a la clave de cobro 1, el clasificador informa la información de uso de cuota de la tecla de cobro 1 al SMF. Cuando se cumple la condición de activación correspondiente a la clave de cobro 2, el clasificador informa la información de uso de cuota de la clave de cobro 2 a la SMF. La UPF1 no envía la información de uso de cuota de la clave de cobro 1 y la clave de cobro 2 a la SMF.

Según la solución técnica proporcionada en esta realización de esta solicitud, a diferentes UPF se les otorga y gestiona una cuota correspondiente a una clave de cobro de manera diferente, lo que simplifica el procesamiento de la información de cobro cuando la UPF se añade por primera vez a la sesión de PDU y mejora la eficiencia de la red.

A continuación se describe el tercer escenario con referencia a la FIG. 8.

La SMF establece la sesión de cobro en línea para la sesión de PDU y solicita, utilizando la sesión de cobro en línea, cuotas para claves de cobro correspondiente a flujos de datos de la UPF1 y de la UPF2. Para un proceso específico, consúltese de S401 a S404 en la realización de la FIG. 4.

S801: La SMF determina que se debe eliminar la UPF2.

Al determinar que es necesario eliminar la UPF2, la SMF determina que la UPF2 ya no enruta un flujo de datos y que ya no existe una clave de cobro que originalmente correspondía al flujo de datos de la UPF2.

Específicamente, la SMF determina, en función de un modo SSC (por ejemplo, para cambiar una UPF, primero se establece una nueva UPF y se elimina una antigua UPF después de que todos los flujos de datos de servicio migren a la nueva UPF), otra regla SMF, o similar, que la UPF se debe eliminar.

La SMF determina el flujo de datos y la clave de cobro de la UPF1, por ejemplo, determina si añadir un flujo de datos nuevamente y determina una clave de cobro del flujo de datos añadido recientemente. Posteriormente, la SMF solicita además una cuota para una clave de cobro sin cuota disponible en la UPF1. Para conocer detalles, consúltese S404 en la realización de la FIG. 4, y los detalles no se describen en esta memoria nuevamente.

S802: La SMF instruye la UPF2 que informe la información de uso de cuota de cada cuota en la UPF2.

S803: La UPF2 informa la información de uso de cuota de cada cuota en UPF2 a la SMF.

Se supone que las corrientes de datos de la UPF2 son una corriente 1 y una corriente 2, la corriente 1 corresponde a la clave de cobro 1 y la corriente 2 corresponde a la clave de cobro 2. Al recibir una notificación de la SMF para informar cada cuota información de uso, la UPF2 informa la información de uso de cuota de la clave de cobro 1 y la clave de cobro 2 a la SMF.

S804: La SMF envía, al OCS, un mensaje de informe de cobro generado en función de la información de uso de cuota.

Para un proceso específico, consúltese S406 en la realización de la FIG. 4.

Después de que la SMF elimine la UPF2, las cuotas para cada clave de cobro para la UPF1 no se ven afectadas y aún se pueden usar.

En esta realización, la UPF2 eliminada puede ser un clasificador o un punto de ramificación. En este caso, el clasificador o el punto de ramificación informa la información de uso de cuota de cada cuota a la SMF. Debido a que el clasificador o el punto de ramificación almacena una clave de cobro correspondiente a cada flujo de datos enrutado por cada UPF, en esta realización, el clasificador o el punto de ramificación informa la información de uso de cuota de una cuota de cada clave de cobro para la UPF1 y la UPF2.

Según la solución técnica proporcionada en esta realización de esta solicitud, a diferentes UPF se les otorga y gestiona una cuota correspondiente a una clave de cobro por separado, lo que simplifica el procesamiento de la información de cobro cuando la UPF se eliminar de la sesión de PDU y mejora la eficiencia de la red.

Cabe señalar que determinar un flujo de datos enrutado por una UPF y una clave de cobro correspondiente al flujo de datos no necesariamente da como resultado un cambio del flujo de datos enrutado por la UPF y la clave de cobro correspondiente al flujo de datos.

En esta realización de esta solicitud, todas las UPF realizan la función de recopilación de estadísticas de cobros, y la función de recopilación de estadísticas de cobros aquí es una función de recopilación de estadísticas de cobros en línea.

La FIG. 9 es un diagrama estructural esquemático de un dispositivo de carga 900 según una realización de esta solicitud. El dispositivo de cobro 900 incluye un módulo de procesamiento 902, un módulo de envío 904 y un módulo de recepción 906. El dispositivo de cobro 900 es la SMF de la FIG. 2, el dispositivo informático en la realización de la FIG. 3, y la SMF en la realización de la FIG. 4 a la FIG. 8. El módulo de procesamiento 902 puede configurarse para realizar S402 y S403 en la realización de la FIG. 4, S502 y S503 en la realización de la FIG. 5, S601 y S602 en la realización de la FIG. 6, S701 y S702 en la realización de la FIG. 7, y S801 en la realización de la FIG. 8. El módulo de recepción 906 puede configurarse para realizar S401, S4042 y S405 en la realización de la FIG. 4, S501, S505 y S507 en la realización de la FIG. 5, S603 en la realización de la FIG.

6, S704 y S706 en la realización de la FIG. 7, y S803 en la realización de la FIG. 8. El módulo de envío 904 puede configurarse para realizar S4041, S4043 y S406 en la realización de la FIG. 4, S504, S506 y S508 en la realización de la F<i>G. 5, S602, S604 y S607 en la realización de la FIG. 6, S703, S705 y S707 en la realización FIG. 7, y S802 y S804 en la realización de la FIG. 8.

La FIG. 10 es un diagrama estructural esquemático de un sistema de cobro 1000 según una realización de esta solicitud. El sistema de cobro 1000 incluye un módulo de recepción 1002 y un módulo de emisión 1004.

El sistema de cobro 1000 es el OCS de la FIG. 2, el dispositivo informático en la realización de la FIG. 3, y el OCS en la realización de la FIG. 4 a la FIG. 8. El módulo de recepción 1002 puede configurarse para realizar S4041 y S406 en la realización de la FIG. 4, S504 y S508 en la realización de la FIG. 5, S602 y S607 en la realización de la FIG. 6, S703 y S707 en la realización de la FIG. 7, y S804 en la realización de la FIG. 8. El módulo de envío 1004 puede configurarse para realizar S4042 en la realización de la FIG. 4, S505 en la realización de la FIG. 5, S603 en la realización de la FIG. 6, y S704 en la realización de la FIG. 7.

El "módulo" en las realizaciones de la FIG. 9 y la FIG. 10 puede ser un circuito integrado de aplicación específica (Application Specific Integrated Circuit, ASIC), un circuito electrónico, un procesador para ejecutar uno o más programas de software o firmware y una memoria, un circuito lógico integrado u otro componente que proporcione las funciones anteriores. Opcionalmente, el dispositivo de cobro y el sistema de cobro se implementan en forma de un dispositivo informático. El módulo de recepción y el módulo de emisión pueden implementarse utilizando un procesador, una memoria y una interfaz de comunicaciones del dispositivo informático. El módulo de procesamiento puede implementarse utilizando el procesador y la memoria del dispositivo informático.

Cabe señalar que, aunque en el dispositivo informático 300 en la FIG. 3 solo se muestra el procesador 302, la memoria 304, la interfaz de comunicaciones 306 y el bus 308, en un proceso de implementación específico, un experto en la técnica debe entender que el dispositivo de cobro y el sistema de cobro incluyen además otros dispositivos necesarios para implementar el funcionamiento normal. Además, según un requisito específico, un experto en la técnica debe entender que el dispositivo de cobro y el sistema de cobro pueden incluir además un dispositivo de hardware para implementar otra función adicional. Además, un experto en la técnica debe entender que el dispositivo de cobro y el sistema de cobro pueden incluir alternativamente solo los dispositivos necesarios para implementar las realizaciones de esta solicitud, y no necesariamente incluyen todos los dispositivos que se muestran en la FIG. 3.

Además, las unidades funcionales en las realizaciones de esta solicitud se pueden integrar en una unidad de procesamiento, o cada una de las unidades puede existir sola físicamente, o dos o más unidades se pueden integrar en una unidad. La unidad integrada se puede implementar en forma de hardware, o puede implementarse en forma de unidad funcional de software.

Cuando la unidad integrada se implementa en forma de unidad funcional de software y se comercializa o se usa como producto independiente, la unidad integrada se puede almacenar en un soporte de almacenamiento legible por ordenador. Basándose en un entendimiento de este tipo, las soluciones técnicas de esta solicitud, esencialmente, o la parte que contribuye a la técnica anterior, o todas o algunas de las soluciones técnicas, se pueden implementar en forma de producto de software. El producto de software informático se almacena en un soporte de almacenamiento e incluye varias instrucciones para dar instrucciones a un dispositivo informático (que puede ser un ordenador personal, un servidor, un dispositivo de red o similar) o un procesador (processor) para realizar todas o algunas de las etapas de los métodos descritos en las realizaciones de esta solicitud. El soporte de almacenamiento incluye: cualquier medio que pueda almacenar código de programa, por ejemplo, una unidad de memoria USB, un disco duro extraíble, una memoria de solo lectura (ROM, Read-Only Memory), una memoria de acceso aleatorio (RAM, Random Access Memory), un disco magnético o un disco compacto.

Las descripciones anteriores son simplemente implementaciones específicas de esta solicitud, pero no pretenden limitar el alcance de protección de esta solicitud. El alcance de la invención se representa por las reivindicaciones adjuntas.

Claims

REIVINDICACIONES

1. Un método de cobro, que comprende las siguientes etapas:

determinar (403, 503), mediante una función de gestión de sesiones, un flujo de datos en una primera función de plano de usuario, y una clave de cobro correspondiente al flujo de datos, caracterizada por comprender: determinar (602), por parte de la función de gestión de sesiones, que no hay cuota disponible para la clave de cobro correspondiente al flujo de datos en la primera función de plano de usuario;

enviar (S4041, S504, S602, S703), por parte de la función de gestión de sesiones a un sistema de cobro en línea, una solicitud de cuota para la clave de cobro que no hay cuota disponible, en donde la clave de cobro que no hay cuota disponible corresponde al flujo de datos en la primera función de plano de usuario, y la solicitud de cuota comprende un identificador de la primera función de plano de usuario y la clave de cobro correspondiente al flujo de datos en la primera función de plano de usuario;

recibir (S4042, S505, S603, S704), por parte de la función de gestión de sesiones, el identificador de la primera función de plano de usuario y una cuota otorgada por el sistema de cobro en línea a la clave de cobro que no hay cuota disponible; y

entregar (S4043, S506, S604, S705), por parte de la función de gestión de sesiones, la cuota otorgada para la clave de cobro para la que no hay cuota disponible para la primera función de plano de usuario.

2. El método según la reivindicación 1, en donde un mensaje de solicitud de cuota lleva la solicitud de cuota de la primera función de plano de usuario.

3. El método según la reivindicación 1, en donde recibir (S4042, S505, S603, S704), por la función de gestión de sesiones, el identificador de la primera función de plano de usuario y una cuota otorgada por el sistema de cobro en línea a la clave de cobro que no hay cuota disponible comprende:

recibir, por parte de la función de gestión de sesiones, un mensaje de respuesta de cuotas, y el mensaje de respuesta de cuotas comprende la cuota otorgada a la clave de cobro de que no hay cuota disponible, y el identificador de la primera función de plano de usuario correspondiente a la cuota.

4. El método según una cualquiera de las reivindicaciones 1 a 3, que comprende además:

recibir, por parte de la SMF, información de uso de cuota que corresponde a la cuota y que es informada por la primera función de plano de usuario; y

enviar (S406, S508, S607, S707, S804), por parte de la función de gestión de sesiones al sistema de cobro en línea, un mensaje de informe de cobro generado en función de la información de uso de cuota correspondiente a la cuota.

5. El método según la reivindicación 4, en donde el mensaje de informe de cobro comprende la información de uso de cuota correspondiente a la cuota para la clave de cobro, y comprende además el identificador de la primera función de plano de usuario correspondiente a la cuota y la clave de cobro.

6. El método según cualquiera de las reivindicaciones 1 a 5, en donde antes de que la función de gestión de sesiones determine el flujo de datos en la primera función de plano de usuario y la clave de cobro correspondiente al flujo de datos, el método comprende además:

realizar, por parte de la función de gestión de sesiones, la selección de función de plano de usuario o la reselección de función de plano de usuario.

7. El método según cualquiera de las reivindicaciones 1 a 6, que comprende además: determinar (601), por parte de la función de gestión de sesiones, que al menos un flujo de datos de la primera función de plano de usuario debe migrarse a una segunda función de plano de usuario, en donde la primera función de plano de usuario y la segunda función de plano de usuario se involucran en una sesión de unidad de datos de protocolo; determinar (602), por parte de la función de gestión de sesiones, que no hay una cuota disponible para launa clave de cobro correspondiente al por lo menos un flujo de datos en la segunda función de plano de usuario; enviar (602), por parte de la función de gestión de sesiones, una segunda solicitud de cuota al sistema de cobro en línea, para solicitar una cuota para la clave de cobro correspondiente al por lo menos un flujo de datos en la segunda función de plano de usuario;

recibir (603), por parte de la función de gestión de sesiones, una cuota otorgada a una clave de cobro correspondiente al por lo menos un flujo de datos en la segunda función de plano de usuario y el identificador de la segunda función de plano de usuario;

enviar (604), por parte de la función de gestión de sesiones, la cuota otorgada a la clave de cobro correspondiente al por lo menos un flujo de datos en la segunda función de plano de usuario a la segunda función de plano de usuario.

8. El método según una cualquiera de las reivindicaciones 1 a 6, que comprende además:

determinar (701), por parte de la función de gestión de sesiones, que es necesario añadir una segunda función de plano de usuario para enrutar el flujo de datos;

determinar (702), por parte de la función de gestión de sesiones, que un flujo de datos en la segunda función de plano de usuario y una clave de cobro correspondiente al flujo de datos en el segundo plano de usuario; enviar (703), por parte de la función de gestión de sesiones, una segunda solicitud de cuota de la clave de cobro para la segunda función de plano de usuario, en donde la segunda solicitud de cuota comprende un identificador de la segunda función de plano de usuario;

recibir (704), por parte de la función de gestión de sesiones, una cuota otorgada a la clave de cobro para la segunda función de plano de usuario y el identificador de la segunda función de plano de usuario; enviar (705), por parte de la función de gestión de sesiones, la cuota otorgada a la clave de cobro a la segunda función de plano de usuario.

9. El método según cualquiera de las reivindicaciones 1 a 6, que comprende además:

determinar (801), por parte de la función de gestión de sesiones, que una segunda función de plano de usuario debe eliminarse de una sesión de unidad de datos de protocolo, en donde la primera función de plano de usuario y la segunda función de plano de usuario se involucran en la sesión de unidad de datos de protocolo; instruir (802), por parte de la función de gestión de sesiones, a la segunda función de plano de usuario para que informe la información de uso de cuota en la segunda función de plano de usuario.

10. El método según cualquiera de las reivindicaciones 1 a 6, en donde una pluralidad de funciones de plano de usuario se involucran en la sesión de unidad de datos de protocolo, y la primera función de plano de usuario es una función de plano de usuario de la pluralidad de funciones de plano de usuario.

11. Un método de cobro, que comprende las siguientes etapas:

recibir (S4041, S504, S602, S703), por parte de un sistema de cobro en línea desde una función de gestión de sesiones, una solicitud de cuota para una clave de cobro de que no hay cuota disponible,

en donde la clave de cobro que no hay cuota disponible corresponde a un flujo de datos en una primera función de plano de usuario, la solicitud de cuota comprende un identificador de la primera función de plano de usuario y la clave de cobro correspondiente al flujo de datos en la primera función de plano de usuario;

enviar (S4042, S505, S603, S704), por parte del sistema de cobro en línea a la función de gestión de sesiones, el identificador de la primera función de plano de usuario y una cuota otorgada a la clave de cobro que no hay cuota disponible.

12. El método según la reivindicación 11, en donde la solicitud de cuota se lleva en un mensaje de solicitud de cuota, y el mensaje de solicitud de cuota lleva una solicitud de cuota de la primera función de plano de usuario.

13. El método según la reivindicación 12, en donde enviar (S4042, S505, S603, S704), por parte del sistema de cobro en línea a la función de gestión de sesiones, el identificador de la primera función de plano de usuario y una cuota otorgada a la clave de cobro que no hay cuota disponible comprende:

devolver, por parte del sistema de cobro en línea un mensaje de respuesta de cuotas a la función de gestión de sesiones, el mensaje de respuesta de cuotas comprende la cuota otorgada a la clave de cobro de que no hay cuota disponible y el identificador de la primera función de plano de usuario correspondiente a la cuota.

14. El método según cualquiera de las reivindicaciones 12 a 13, que además comprende:

recibir (S406, S508, S607, S707, S803), por el sistema de cobro en línea, un mensaje de informe de cobro de la función de gestión de sesiones, en donde el mensaje de informe de cobro comprende información de uso de cuota correspondiente a la cuota otorgada para la clave de cobro de que no hay cuota disponible.

15. El método según la reivindicación 14,

en donde el mensaje de información de cobros comprende la información de uso de cuota correspondiente a la cuota otorgada para la clave de cobro, y el identificador de la primera función de plano y la clave de cobro correspondiente a la cuota.

16. Un dispositivo de cobro (900), que comprende un módulo de procesamiento, un módulo de envío y un módulo de recepción, en donde:

el módulo de procesamiento (902) se configura para determinar un flujo de datos en una primera función de plano de usuario, y una clave de cobro correspondiente al flujo de datos; caracterizado por:

determinar que no hay cuota disponible para la clave de cobro correspondiente al flujo de datos en la primera función de plano de usuario;

el módulo de envío (904) se configura para: enviar, a un sistema de cobro en línea una solicitud de cuota para la clave de cobro que no hay cuota disponible, en donde la clave de cobro que no hay cuota disponible corresponde al flujo de datos en la primera función de plano de usuario, la solicitud de cuota comprende un identificador de la primera función de plano de usuario y la clave de cobro correspondiente al flujo de datos en la primera función de plano de usuario,

el módulo de recepción (906) se configura para recibir el identificador de la primera función de plano de usuario y una cuota otorgada por el sistema de cobro en línea a la clave de cobro para la primera función de plano de usuario, y

el módulo de envío (906) se configura además para entregar la cuota otorgada a la primera función de plano de usuario.

17. El dispositivo de cobro según la reivindicación 16, en donde el dispositivo de cobro se configura además para realizar el método de cualquiera de las reivindicaciones 2 a 10.

18. Un sistema de cobro (1000), que comprende un módulo de recepción y un módulo de envío, en donde el módulo de recepción (1002) se configura para recibir, de una función de gestión de sesiones, una solicitud de cuota de al menos una clave de cobro de que no hay cuota disponible, caracterizado por:

en donde la clave de cobro que no hay cuota disponible corresponde a un flujo de datos en una primera función de plano de usuario, la solicitud de cuota comprende un identificador de la primera función de plano de usuario y la clave de cobro correspondiente al flujo de datos en la primera función de plano de usuario; y el módulo de envío (1004) se configura para enviar, el identificador de la primera función de plano de usuario y una cuota otorgada a la clave de cobro que no hay cuota disponible.

19. El sistema de cobro (1000) según la reivindicación 18, en donde la solicitud de cuota se lleva en un mensaje de solicitud de cuota, y el mensaje de solicitud de cuota lleva una solicitud de cuota de la primera función de plano de usuario.

20. Un sistema de red, que comprende el dispositivo de cobro según cualquiera de las reivindicaciones 16-17, un sistema de cobro según cualquiera de las reivindicaciones 18 a 19.

21. Un método de cobro de sistema, que comprende las etapas de método de la función de gestión de sesiones, SMF, de la reivindicación 1 y las etapas de método del sistema de cobro en línea, OCS, de la reivindicación 11.