ES2965185T3

ES2965185T3 - Método, aparato, programa informático y sistema de cobro

Info

Publication number: ES2965185T3
Application number: ES21154943T
Authority: ES
Inventors: Xiaoqian Chai
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2017-08-03
Filing date: 2018-07-04
Publication date: 2024-04-11
Anticipated expiration: 2038-07-04
Also published as: EP3588846A4; US20210152989A1; EP3588846B1; WO2019024645A1; US10674330B2; US10945104B2; US20200045514A1; EP3883180A1; EP3588846A1; CN110519069A; CN112865985B; CN109391475A; EP3883180B1; US20200228942A1; CN110519069B; CN112865985A; CN109391475B; US11671802B2

Abstract

Un método de cobro incluye: determinar, mediante una entidad de función del plano de control CP, que un flujo de datos que se transmite por el equipo de usuario UE en una primera sesión de datos necesita migrarse a una segunda sesión de datos, donde la primera sesión de datos es una sesión de datos. entre el UE y una entidad funcional del primer plano de usuario UP, la segunda sesión de datos es una sesión de datos entre el UE y un segundo UP, el primer UP y el segundo UP son UP correspondientes al CP, y la primera sesión de datos y la segunda la sesión de datos corresponde a una misma sesión de PDU; cargar, por parte del CP, el flujo de datos en el primer UP a través de una primera sesión de carga entre el CP y un sistema de carga; obtener, por parte del CP, información de tarificación del flujo de datos antes de la migración que es contabilizada por el primer UP; y determinar, por parte del CP, una cuota que se utiliza para el flujo de datos después de la migración que es necesario entregar al segundo UP, y entregar la cuota al segundo UP, cobrando así un flujo de datos de servicio de un usuario en un caso de migración entre planos de usuario cuando un plano de usuario de una sesión de PDU cambia o cuando una sesión de PDU tiene una pluralidad de planos de usuario. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método, aparato, programa informático y sistema de cobro

Campo técnico

Esta solicitud se refiere al campo de las tecnologías de comunicaciones y, en particular, a un método, aparato, programa informático y sistema de cobro.

Antecedentes

Actualmente, un mecanismo básico de cobro en línea es el siguiente: una función de activación de cobro (función de activación de cobro, CTF) se aplica a un sistema de cobro en línea (sistema de cobro en línea, OCS) para reservar una cuota de una grupo de tarificación (grupo de tarificación). El OCS otorga la cuota, y el CTF gestiona la cuota, usa la cuota y recopila información de cobro, y notifica la información de cobro recopilada al sistema de cobro cuando detecta que se cumple una condición de notificación de cobro (una condición de activación).

En una red 4G, una función de cumplimiento de política y cobro (función de cumplimiento de política y cobro, PCEF) ubicada en una pasarela es una CTF, y la PCEF determina un modo de cobro (cobro en línea o cobro fuera de línea), un método de cómputo (un volumen, duración o similar), un grupo de tarificación (grupo de tarificación, denominado clave de cobro en esta solicitud), una granularidad de notificación, y similares según una política de cobro entregada por una función de reglas de política y cobro (función de reglas de política y cobro, PCRF). Una granularidad de cobro incluye NIVEL_IDENTIFICADOR_DE_SERVICIO (SERVICE_IDENTIFIER_LEVEL) o NIVEL_GRUPO_DE_TARIFICACIÓN (RATING_GROUP_LEVEL). Si la granularidad de cobro es RATING_GROUP_LEVEL, la PCEF debe notificar información de cobro para cada grupo de tarificación. Si la granularidad de cobro es SERVICE_IDENTIFIER_LEVEL, la PCEF debe notificar información de cobro para cada grupo de tarificación y cada identificador de servicio.

Con un aumento espectacular en el volumen de datos, se plantea un nuevo desafío para una red móvil. Para hacer frente al desafío, se ha desarrollado una arquitectura de red de datos móviles en la que un plano de control y un plano de usuario están separados. En esta arquitectura, solo se realiza control en los planos de control, y los planos de control pueden desplegarse de manera centralizada; los flujos de datos pasan a través de planos de usuarios y los planos de usuarios se despliegan de manera distribuida. Un usuario puede acceder a un plano de usuario cercano para acortar una distancia de transmisión de datos en una red, reducir un retardo de la red y mejorar la eficiencia de la red.

Actualmente, se ha extendido en la red 4G una arquitectura de red en la que un plano de control y un plano de usuario están separados, para implementar, en cierta medida, el cobro en la arquitectura de red en la que el plano de control y el plano de usuario están separados. Como se muestra en la FIG. 1, una pasarela C de servicio, una pasarela C de PDN y una TDF-C son planos de control, y una pasarela U de servicio, una pasarela U de PDN y una TDF-U son planos de usuario. Generalmente, 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 cobro y realiza una función de recopilación de cobro. En esta arquitectura, una cantidad de planos de control y una cantidad de planos de usuario en un estado de ejecución están en una proporción de 1:1.

Sin embargo, con un aumento espectacular del volumen de móviles, un aumento espectacular de la cantidad de dispositivos de acceso y una mejora de los requisitos de un servicio en cuanto a ancho de banda, retardo y similares, se ha desarrollado una arquitectura de red relativamente compleja para hacer frente a los requisitos de un servicio futuro. Por ejemplo, con el movimiento de un usuario, la presión sobre un plano de usuario y un requisito especial de un servicio del usuario, los planos de usuario a los que accede el usuario pueden conmutarse con relativa frecuencia. Alternativamente, un usuario puede tener una pluralidad de planos de usuario al mismo tiempo, y un flujo de datos de servicio del usuario se migra entre diferentes planos de usuario. Un mecanismo de cobro actual no puede implementar un procesamiento de cobro preciso en un escenario de este tipo. El documento de la técnica anterior D1 (TR 32.899 V0.2.0 de 3GPP) describe un método y una arquitectura para el cobro en línea. La SMF solicita una cuota del OCS según la política activada por la PCF, la SMF puede solicitar una cuota en el establecimiento de la sesión de PDU o durante una sesión de PDU, la gestión de cuota solo funciona por clave de cobro, es decir, la SMF solicita una cuota para cada clave de cobro. El documento de la técnica anterior D2 (US 2013/0091281), describe la comunicación entre un dispositivo de pasarela y una PCRF. El dispositivo de pasarela realiza control de políticas sobre un flujo de datos y acumula el tráfico del flujo de datos, notifica la información de tráfico acumulada a la PCRF. La PCRF deduce la información de tráfico acumulada notificada de la cuota de uso del tráfico total. Si el servicio necesita continuar y una cuota de uso de tráfico total después de la deducción es mayor que cero, se considera que es necesario entregar una nueva cuota de uso al dispositivo de pasarela, la PCRF genera de nuevo una política de control de flujo de datos de servicio.

Compendio

Las realizaciones de esta solicitud proporcionan un método de cobro, principalmente para resolver el procesamiento de cobro en un caso de migración de un flujo de datos de servicio de un usuario entre planos de usuario cuando un plano de usuario de una sesión de PDU conmuta o cuando una sesión de PDU tiene una pluralidad de planos de usuario en una arquitectura en la que el control de la red y el reenvío del flujo de datos están separados.

La presente invención se define por las reivindicaciones independientes adjuntas. Las reivindicaciones dependientes constituyen realizaciones de la invención. A continuación, las partes de la descripción y los dibujos que se refieren a realizaciones que no están cubiertas por las reivindicaciones no se presentan como realizaciones de la invención, sino como ejemplos útiles para comprender la invención.

Breve descripción de los dibujos

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 la presente solicitud;

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

La FIG. 4 es un diagrama de flujo ilustrativo de un método 400 de cobro según una realización de esta solicitud

La FIG. 5 es un diagrama de flujo ilustrativo de un método 500 de cobro según una realización de esta solicitud

La FIG. 6 es un diagrama de flujo ilustrativo de un método 600 de cobro según una realización de esta solicitud

La FIG. 7 es un diagrama de flujo ilustrativo de un método 700 de cobro según una realización de esta solicitud

La FIG. 8 es un diagrama de flujo ilustrativo de un método 800 de cobro según una realización de esta solicitud

La FIG. 9 es un diagrama de flujo ilustrativo de un método 900 de cobro según una realización de esta solicitud

La FIG. 10 es un diagrama de flujo ilustrativo de un método 1000 de cobro según una realización de esta solicitud;

La FIG. 11 es un diagrama de flujo ilustrativo de un método 1100 de cobro según una realización de esta solicitud;

La FIG. 12 es un posible diagrama estructural esquemático de un dispositivo 1200 de cobro según una realización de esta solicitud; y

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

Descripción de las realizaciones

Los nombres de los elementos de red en las realizaciones de esta solicitud no constituyen una limitación para un dispositivo. Específicamente, un nombre de una función de gestión de sesiones no constituye una limitación para el dispositivo. En la práctica, la función de gestión de sesiones puede tener otro nombre. Por ejemplo, un nombre de una función del plano de usuario UP (plano de usuario) no constituye una limitación para el dispositivo. En la práctica, la función del plano de usuario puede tener otro nombre, por ejemplo, una entidad de función del plano de usuario (entidad de función del plano de usuario). Un nombre de un sistema de cobro en línea no constituye una limitación para el dispositivo. En la práctica, el sistema de cobro en línea puede tener otro nombre, por ejemplo, sistema de cobro u otros nombres. En la presente memoria se proporcionan descripciones unificadas y los detalles no se describen de nuevo a continuación.

Una red 5G se usa como un ejemplo en las soluciones de las realizaciones de esta solicitud, pero el alcance de la solicitud no se limita a la red 5G. Las soluciones también pueden aplicarse a algunas redes 4G o una red de transición de una red 4G a una red 5G, o pueden aplicarse a otro posible futuro sistema de comunicaciones o cobro. Siempre que exista un escenario en el que un flujo de datos de servicio de un usuario se migre entre planos de usuario cuando un plano de usuario de una misma sesión de PDU (o una conexión de datos similar) conmute o cuando una sesión de PDU tenga una pluralidad de planos de usuario, las soluciones de realizaciones relacionadas de la presente invención se pueden usar para un método de cobro correspondiente.

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 (función de gestión de sesiones), una PCF es una función de control de políticas (función de control de políticas), una UPF es una función del plano de usuario (función del plano de usuario), un OCS es un sistema de cobro en línea (sistema de cobro en línea), y UE es equipo de usuario (equipo de usuario). 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 diferentes UPF se comunican entre sí a través de una interfaz N9.

Las funciones de la SMF incluyen: gestión, tal como establecimiento, modificación y liberación de una sesión (sesión) de una unidad de datos de protocolo (unidad de datos de protocolo, PDU), asignación de dirección de protocolo de Internet (protocolo de Internet, IP) del UE; selección de UPF, configuración de política de enrutamiento de UPF, obtención de una política de control de la PCF y ejecución de un plano de control que forma parte de la política de control, y determinación de un modo de continuidad de servicio y sesión (continuidad de servicio y sesión, SSC) (denominado modo de SSC) de la sesión de PDU bajo un tipo de IP. Específicamente, una sesión de PDU tiene tres modos de SSC: un modo 1 de SSC, un modo 2 de SSC y un modo 3 de SSC. Modo 1 de SSC: en este modo, después de que un terminal establece una sesión de PDU, independientemente de qué área o qué tecnología de acceso se mueva el terminal, se usa un elemento de red UPF de la sesión de PDU como anclaje para dar servicio al terminal. Para ser específicos, la sesión de PDU no se interrumpe de ninguna forma debido al movimiento del terminal. Modo 2 de SSC: en este modo, después de que un terminal establece una sesión de PDU, cuando el terminal se mueve, si el terminal abandona un área de servicio de un elemento de red UPF, o debido a razones tales como un fallo o carga excesiva del elemento de red UPF, una red puede volver a seleccionar un elemento de red UPF para la sesión de PDU del terminal y hacer que el terminal establezca una sesión de PDU después de que se vuelva a seleccionar el elemento de red UPF y se migre un servicio de un usuario de una UPF original a una nueva UPF. En este modo, se puede considerar que el elemento de red UPF tiene un área de servicio particular. Cuando el terminal se mueve en la zona de servicio, el elemento de red UPF da servicio al terminal. Si el terminal abandona el área de servicio, una red puede determinar que el elemento de red UPF no puede dar servicio al terminal, se interrumpe una sesión de PDU original establecida usando el elemento de red UPF y se establece una sesión de PDU entre el terminal y una nueva UPF. Modo 3 de SSC: en este modo, después de que un terminal establece una sesión de PDU, un área de servicio de un elemento de red UPF tiene un alcance. Después de que el terminal abandona el área de servicio del elemento de red UPF, una red selecciona un nuevo elemento de red UPF para que el terminal dé servicio al terminal, y el terminal establece una sesión de PDU usando el nuevo elemento de red UPF y un elemento de red DN original. Sin embargo, este modo difiere del modo 2 SSC en que una conexión de una sesión de PDU establecida por el terminal usando un elemento de red UPF antiguo puede no liberarse temporalmente, aunque se libera después de que se completa el establecimiento de la nueva sesión de PDU.

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 anclaje UPF), enrutamiento y reenvío de paquetes de datos, detección de paquetes de datos, y ejecución de un plano de usuario que forma parte 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, usando una política, de calidad de servicio (QoS), la limitación, el 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 concesión de cuota según una solicitud de la SMF y realizar la deducción o devolución del saldo en función de la información de uso de cuota notificada por la s Mf .

El UE es un dispositivo que tiene una identidad permanente de abonado (identidad permanente de abonado, SUPI) o una identidad de abonado móvil internacional (número de identificación de abonado móvil internacional, IMSI), o puede ser un teléfono móvil que tiene una SIM/eSIM, una tableta, un ordenador, un dispositivo IoT u otro dispositivo que pueda estar conectado a una red 5G u otras redes.

En esta solicitud, una interfaz de notificación de información de aplicación, asignación y cobro de cuota puede ser una interfaz de protocolo de Diámetro (Diameter) o una interfaz basada en servicios. La interfaz basada en servicios es, por ejemplo, Restful. En una manera de usar la interfaz basada en servicios, no se establece una sesión de cobro entre un CP y un sistema de cobro, sino que el CP y el sistema de cobro interactúan entre sí directamente usando un mensaje basado en servicios. El mensaje basado en servicios (por ejemplo, Restful) es un mensaje sin estado.

En esta solicitud, el protocolo Diámetro se usa principalmente como un ejemplo para la descripción. Sin embargo, un formato de mensaje no está limitado en esta solicitud y, alternativamente, se pueden usar otros formatos, tales como una API Restful.

Algunos conceptos en esta solicitud se describen con más detalle a continuación:

Plano de control: el plano de control realiza funciones tales como gestión de sesión de PDU, asignación de dirección IP y selección del plano de usuario. El plano de control se denomina CP o entidad de función CP en esta solicitud y corresponde a una SMF en una red central 5G.

Plano de usuario: el plano de usuario realiza el enrutamiento y reenvío de paquetes de datos, la detección de paquetes de datos y similares. El plano de usuario se denomina UP o entidad de función UP en esta solicitud y corresponde a una UPF en una red central 5G.

Sesión de PDU: una sesión de PDU (una sesión de PDU es similar a una sesión IP-CAN en una red 4G o una red de transición 4G/5G, y en descripciones posteriores, una sesión de PDU se usa uniformemente para representar un concepto relacionado o similar) se establece entre el UE y una red de datos (red de datos, DN) que proporciona un servicio de conexión de PDU. Una UPF está conectada a la DN. Por tanto, en otras palabras, la sesión de PDU se establece entre el UE y la UPF. El establecimiento de la sesión de PDU está controlado por la SMF. Por lo tanto, el UE envía una 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. Una sesión de PDU puede tener/corresponder a una pluralidad de entidades UPF.

El CP, el OCS y el UP pueden implementarse en forma de dispositivo informático. La FIG. 3 es un diagrama esquemático de una estructura de hardware de un dispositivo 300 informático según una realización de esta solicitud. Como se muestra en la FIG. 3, el dispositivo 300 informático incluye un procesador 302, una memoria 304, una interfaz 306 de comunicaciones y un bus 308. El procesador 302, la memoria 304 y la interfaz 306 de comunicaciones están en una conexión de comunicación entre sí usando el bus 308.

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

La memoria 304 puede ser una memoria de solo lectura (memoria de solo lectura, ROM), un dispositivo de almacenamiento estático, un dispositivo de almacenamiento dinámico o una memoria de acceso aleatorio (memoria de acceso aleatorio, RAM). La memoria 304 puede almacenar un sistema operativo 3041 y otro programa 3042 de aplicación. Cuando las soluciones técnicas proporcionadas en las realizaciones de esta solicitud se implementan usando software o firmware, el código de programa usado para implementar las soluciones técnicas proporcionadas en las realizaciones de esta solicitud se almacena en la memoria 304 y se ejecuta mediante el procesador 302.

La interfaz 306 de comunicaciones usa un aparato transceptor, por ejemplo, pero no limitado 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 306 de comunicaciones).

Cuando el dispositivo 300 informático es un CP, el procesador 302 ejecuta el código de programa que se usa para implementar las soluciones técnicas proporcionadas en las realizaciones de esta solicitud y que se almacena en la memoria 304, para implementar métodos mostrados en realizaciones de la FIG. 4 a la FIG. 11.

Cuando el dispositivo 300 informático es un OCS/OFCS, el procesador 302 ejecuta el código de programa que se usa para implementar las soluciones técnicas proporcionadas en las realizaciones de esta solicitud y que se almacena en la memoria 304, para implementar métodos mostrados en realizaciones de la FIG. 4 a la FIG.

10.

En las realizaciones de esta solicitud, un servicio de datos se puede cobrar con precisión en un caso de migración de un flujo de datos de servicio de un usuario entre planos de usuario cuando un plano de usuario de una sesión de PDU conmuta o cuando una sesión de PDU tiene una pluralidad de planos de usuario, mejorando así la eficiencia de la red y la experiencia del usuario.

La FIG. 4 es un diagrama de flujo ilustrativo de un método 400 de cobro según una realización de esta solicitud. El método 400 de cobro puede ser realizado por la SMF (el CP), el OCS o la UPF (el UP) mostrado en la FIG.

2.

S401: la entidad de función del plano de control CP determina que un flujo de datos que se transmite por el UE en una primera sesión de datos necesita migrarse a una segunda sesión de datos, donde la primera sesión de datos es una sesión de datos que está establecida por el CP y que es entre el UE y un primer UP (un UP 1), la segunda sesión de datos es una sesión de datos entre el UE y un segundo UP (un UP 2), el primer UP y el segundo UP son UP correspondientes al CP, y la primera sesión de datos y la segunda sesión de datos corresponden a una misma sesión de PDU; y el<C p>cobra el flujo de datos en el primer UP usando una primera sesión de cobro entre el CP y un sistema de cobro.

La transmisión de flujo de datos entre el UE y una red de datos se implementa a través de una sesión de PDU establecida. La sesión de PDU se establece entre el UE y una red de datos (red de datos, DN) que proporciona un servicio de conexión de PDU. El establecimiento de la sesión de PDU está controlado por la entidad de función del plano de control CP, por ejemplo, la SMF. Por lo tanto, el UE envía una solicitud de establecimiento de sesión de PDU al CP y el CP selecciona un UP para establecer una conexión con el UE. Hay un caso en el que un flujo de datos de servicio de un usuario se migra entre planos de usuario cuando un plano de usuario de una sesión de PDU conmuta o cuando una sesión de PDU tiene una pluralidad de planos de usuario. Una sesión de PDU entre el UE y el plano de usuario se migra a un plano de usuario diferente o se establece en dos o más planos de usuario al mismo tiempo. Sin embargo, en un proceso de migración, dos o más UP corresponden al mismo CP y la sesión de PDU permanece sin cambios. La sesión de PDU "que permanece sin cambios" o es la "misma" en la presente memoria significa que para la sesión de PDU, el plano de control básicamente permanece sin cambios en un proceso de cambio de los UP. Específicamente, un ID de sesión, una dirección IP y un punto de acceso (DNN) del UE permanecen sin cambios.

S402: el CP obtiene información de cobro del flujo de datos antes de la migración que es contabilizada por el primer UP.

Debido a que implica la conmutación entre planos de usuario, cuando el flujo de datos del servicio se migra al segundo UP, también cambia un punto de recopilación de cobro. Este cambio incluye, pero no se limita a: el punto de recolección de cobro se migra del primer UP al segundo UP, y el segundo UP se usa como un punto de recolección de cobro único después de la migración; o tanto el primer UP como el segundo UP se usan como puntos de recopilación de cobro después de la migración. El CP obtiene la información de cobro del primer UP antes de completar la migración (incluida la información de cobro del primer UP en el proceso de migración). Si sigue existiendo una conexión de datos entre el UE y el primer UP después de la migración, el CP puede obtener continuamente la información de cobro del primerpara la gestión de cuota durante o después de la migración, asegurando así la continuidad y precisión de un proceso de cobro.

Una manera específica de obtener la información de cobro es la siguiente: el primer UP informa activamente la información de cobro, o el CP envía una solicitud de obtención al primer UP para obtener la información de cobro. Puede haber una pluralidad de implementaciones para una manera de activación. Por ejemplo, la ocurrencia de una migración (decisión de migración u ocurrencia de migración real, por ejemplo, se libera una sesión del primer UP) activa al primer UP para que notifique activamente la información de cobro, o el CP puede solicitar al primer UP que notifique la información de cobro tras detectar que el segundo UP comienza a transmitir el flujo de datos del servicio. Específicamente, la información de cobro se puede obtener configurando una condición de activación (activación) relacionada en el CP o el UP.

S403: el CP determina una cuota que se usa para el flujo de datos después de que la migración es necesario que sea entregada al segundo UP, y entrega la cuota al segundo UP.

En un caso de cobro en línea, el CP necesita determinar la cuota a entregar al segundo UP, para garantizar que un volumen generado en el segundo UP pueda contabilizarse y cobrarse.

Específicamente, dependiendo de si el OCS detecta la migración, el CP puede determinar de forma autónoma la cuota a entregar al segundo UP (el OCS no detecta la migración entre UP) o solicitar al OCS una nueva cuota (el OCS detecta la migración entre UP y la cuota debe volver a entregarse debido a la migración).

Según la solución técnica proporcionada en esta realización de esta solicitud, después de decidir realizar la migración entre UP, el CP obtiene información de cobro de un UP antes de la migración y determina además una cuota que debe entregarse a un UP objetivo después de la migración y entrega la cuota, para implementar el cobro tras la migración entre planos de usuario en un escenario de separación de CU en el que un plano de control corresponde a una pluralidad de planos de usuario, asegurando así la continuidad y precisión del cobro.

A continuación se describe un proceso de procesamiento de cobro en un caso en el que se cambia un UP que transporta el flujo de datos con referencia a implementaciones más específicas. En esta realización de la presente invención, el flujo de datos es un flujo de datos de una sesión de PDU. En un proceso de migración, la sesión de PDU permanece sin cambios, el primer UP (el UP 1) es un UP antes de la migración y el segundo UP (el UP 2) es un UP después de la migración. Que el UP que transporta el flujo de datos cambie incluye uno de los siguientes casos:

Caso A: el CP primero elimina una conexión entre el UE y el UP 1 y luego establece una conexión entre el UE y el UP 2. En otras palabras, una sesión de PDU corresponde a un solo UP. Un caso del modo 2 de SSC pertenece al caso A.

Caso B: el CP establece una conexión entre el UE y el UP 2 pero no elimina una conexión entre el UE y el UP 1. En otras palabras, una sesión de PDU corresponde a una pluralidad de UP al mismo tiempo. El CP puede eliminar la conexión entre el UE y el UP 1 después de que todos los flujos de datos de servicio se migren al UP 2 (se migren todos los flujos de datos de la sesión de PDU); o la conexión entre el UE y el UP 1 no se elimine pero la conexión del UP 2 se use para transportar una parte de un volumen de servicio (se migren algunos flujos de datos de la sesión de PDU). Un caso del modo 3 de SSC pertenece al caso B.

En los dos casos A y B anteriores, el CP, usado como la CTF, interactúa con el sistema de cobro y establece una sesión de cobro para una sesión de PDU, y el UP notifica la información de cobro recopilada al CP.

En el caso A, el CP finaliza una sesión de PDU entre el UE y el UP 1 y luego establece una sesión de PDU entre el UE y el UP 2. En este caso, se cambia el UP del flujo de datos. Un método de procesamiento de cobros en el caso A se describe en detalle a continuación dependiendo de si el OCS detecta la migración del flujo de datos entre los UP:

A1: para un método de procesamiento de cobros proporcionado cuando el OCS detecta la migración de un flujo de datos entre los UP, consulte la FIG. 5.

Etapa 501: el CP determina un UP cuyo flujo de datos necesita cambiarse, y el CP termina una sesión de PDU entre el UE y el UP 1 y establece una sesión de PDU entre el UE y el UP 2 (un UP que recopila cambios en la información de cobro).

Etapa 502: el CP inicia la terminación de la sesión de PDU en el UP 1 y recibe información de cobro notificada por el UP 1. Específicamente, el CP inicia la liberación de la sesión de PDU en el UP 1 y establece la sesión de PDU en el UP 2. Un procedimiento de liberación de sesión de PDU en el UP 1 activa el UP 1 para notificar la información de cobro al CP.

La información notificada del UP 1 incluye un motivo de notificación (es decir, una condición de activación para activar la notificación). El motivo de notificación en la presente memoria es la liberación de sesión de PDU.

Ejemplo de un formato de la información notificada:

Etapa 503: el CP genera, en función de la información de cobro notificada por el UP 1, información de cobro a notificar al OCS; notifica la información de cobro al OCS y solicita una nueva cuota para el flujo de datos en el segundo UP, donde un motivo de notificación indica que el UP cambia;

La información notificada transporta la información del UP 1 (por ejemplo, una dirección IP).

Ejemplo de un formato de notificación: un formato de Diámetro

Unidad-Servicio-Usado

Motivo-Notificación (que indica un motivo de notificación: UP cambiado)

Cambio-Tiempo-Tarifa

Tiempo-CC

Octetos- Total-CC

Octetos-Entrada-CC

Octetos-Salida-CC

Grupo-Tarificación

Si el formato de notificación es un formato Restful, un ejemplo de mensaje es el siguiente:

POST https://{Raízservidor}/cobro/unidadesservicio

Tipo-contenido: aplicación/json

{

“id": 12358,

unidadesusadas": {

“motivo": “UP cambiado",

“unidades": 256728,

“"unidadesenlaceascendente": 226326

“"unidadesenlacedescendente": 30402,

},

“grupotarificación": 1

Etapa 504: el OCS entrega, al CP, una nueva cuota concedida para el flujo de datos en el segundo UP. Etapa 505: el CP genera, en función de la nueva cuota, información a entregar al UP 2, donde la información transporta la información correspondiente de la nueva cuota; y entrega la información generada al UP 2, para que el UP 2 use la nueva cuota para un flujo de datos posterior.

Cuando se establece la sesión de PDU en el UP 2, o antes de completar el establecimiento de la sesión de PDU en el UP 2 y transmitir el flujo de datos, el CP entrega, al UP 2, información que se genera en función de la nueva cuota concedida por el OCS.

La información entregada incluye una regla de detección del flujo de datos e información de umbral correspondiente a la nueva cuota, e información de asociación de la regla de detección del flujo de datos y la información de umbral.

En la solución de esta realización de la presente invención, en una arquitectura en la que el control de red y el reenvío de flujo de datos están separados, el procesamiento de cobro se implementa cuando un plano de usuario de una sesión de PDU conmuta. Después de que se libere la sesión de PDU entre el UE y el UP 1, el UP 1 se activa para notificar la información de cobro al CP, el CP notifica además la información de cobro del UP 1 al OCS y solicita la nueva cuota para el UP 2. El motivo de notificación indica que el UP cambia, implementando así el procesamiento de cobros cuando el OCS puede detectar la migración del flujo de datos entre los UP. Debido a que el OCS detecta la migración del flujo de datos entre los UP, el OCS puede usar y ejecutar diferentes tarifas de cobro para los flujos de datos de servicio en diferentes UP para soportar un cobro más flexible y adecuado y aliviar la carga para que el CP participe en la gestión de cuota.

A2: se proporciona un método de procesamiento de cobro cuando el OCS no detecta la migración de un flujo de datos entre los UP, consulte la FIG. 6. Las etapas específicas se describen a continuación:

Etapa 601: el CP determina un UP cuyo flujo de datos necesita cambiarse (un UP que recopila información de cobro cambia), y el CP finaliza una sesión de PDU entre el UE y el UP 1 y establece una sesión de PDU entre el UE y el UP 2.

Etapa 602: el CP inicia la terminación de la sesión de PDU en el UP 1 y recibe información de cobro notificada por el UP 1.

Específicamente, el CP inicia la liberación de la sesión de PDU en el UP 1 y establece la sesión de PDU en el UP 2. Un procedimiento de liberación de sesión de PDU en el UP 1 puede activar el UP 1 para notificar la información de cobro al CP.

La información notificada del UP 1 incluye un motivo de notificación (es decir, una condición para activar la notificación). El motivo de notificación en la presente memoria es la liberación de sesión de PDU.

Etapa 603: el CP determina una cuota disponible restante en función de la información de cobro del flujo de datos que notifica al UP 1, y genera, en función de la cuota disponible restante, información a entregar al UP 2. La información transporta información de la cuota disponible restante.

Un método para determinar, por el CP, la cuota disponible restante en función de la información de cobro notificada por el UP 1 es uno de los siguientes:

Si el CP almacena en caché la información de la cuota al entregar la cuota al UP 1, el UP 1 notifica solo información de uso de la cuota, y el CP deduce la información de uso de la cuota notificada por el UP 1 de la información de la cuota almacenada en caché, para obtener la cuota disponible restante.

Ejemplo de un formato de la información notificada:

Si el CP no almacena en caché la información de la cuota cuando entrega la cuota al UP 1, el UP 1 notifica tanto la información de uso de la cuota como un valor de cuota restante, y el CP usa el valor de cuota restante recibido notificado por el UP 1 como cuota disponible restante.

Ejemplo de un formato de la información notificada:

Después de obtener la cuota disponible restante, el CP determina además si se cumple una condición para notificar al OCS, y la determinación se realiza en función de una condición de activación entregada por el OCS. Por ejemplo, si la cuota restante es ligeramente inferior a un umbral especificado por el OCS, se cumple la condición para notificar al OCS. Si se cumple la condición, la información a notificar al OCS se genera en función de la notificación realizada por el UP 1, y el CP normalmente notifica la información al OCS y solicita una nueva cuota. Un motivo de notificación indica que se cumplió la condición de activación. Si no se cumple la condición de notificación al OCS, la información a entregar al UP 2 se genera en función de la cuota disponible restante. La información transporta información de la cuota disponible restante.

Etapa 604: el CP entrega la información que transporta la cuota disponible restante al UP 2, para que el UP 2 use la cuota disponible restante para un flujo de datos posterior.

Cuando se establece la sesión de PDU en el UP 2, o antes de completar el establecimiento de la sesión de PDU en el UP 2 y transmitir el flujo de datos, el CP entrega, al UP 2, información que se genera en función de la cuota disponible restante.

El CP procesa, usando cualquiera de los siguientes métodos, la información de cobro notificada por el UP 1:

a. El CP almacena en caché la información de uso notificada por el UP 1.

b. El CP entrega la información notificada por el UP 1 al UP 2, y el UP 2 contabiliza continuamente en función de la información notificada.

Etapa 605: el CP recibe información de uso que es notificada por el UP 2 cuando se cumple una condición de notificación, genera, en función de la información de uso notificada por el UP 1 y la información de uso notificada por el UP 2, información a notificar al OCS, y notifica la información generada al OCS.

Específicamente, si el CP almacena en caché la información de cobro notificada por el UP 1, el CP fusiona la información de uso notificada por el UP 2 y la información de uso en caché notificada por el UP 1 para generar la información de cobro a notificar al<o>C<s>, y notifica la información de cobro generada al<o>C<s>. Si el CP previamente también entrega la información notificada por el UP 1 al UP 2, el UP 2 continúa realizando acumulación en función de la información de uso notificada por el UP 1 y realiza fusión y notificación. El CP genera, en función de la información de cobro notificada por el UP 2, la información de cobro a notificar al OCS, y notifica la información de cobro generada al OCS.

En la solución de esta realización de la presente invención, en una arquitectura en la que el control de red y el reenvío de flujo de datos están separados, el procesamiento de cobro se implementa cuando un plano de usuario de una sesión de PDU conmuta. Después de que se libera la sesión de PDU entre el UE y el UP 1, se activa el UP 1 para notificar la información de cobro al CP, el CP procesa de forma autónoma, en función de la información de cobro notificada por el UP 1, el uso de una cuota restante después de que el flujo de datos se migra. El OCS no detecta la migración entre UP, para que cuando el OCS no necesite realizar procesamiento de cobro en función del UP, se reduzca una cantidad de señalización notificada al OCS y se alivie la carga del OCS.

A3: el CP puede determinar, según lo indicado por el OCS, usar un método de cobro relacionado en la realización anterior de A1 o A2. Específicamente, el OCS puede entregar, en función de una decisión del OCS o en una configuración del operador, una condición de activación (activación) que indica un cambio del UP solo o junto con la cuota cuando la cuota se entrega al CP. La condición de activación indica al CP que inicie la reautorización al OCS cuando cambie el UP que usa la cuota. Las etapas específicas se describen a continuación:

Etapa 1: el CP determina un UP cuyo flujo de datos necesita ser modificado (un UP que realiza cambios de cobro), y el primer CP termina una sesión de PDU entre el UE y el UP 1 y establece una sesión de PDU entre el UE y el UP 2.

Etapa 2: el CP inicia la terminación de la sesión de PDU en el UP 1 y recibe información de cobro notificada por el UP 1. Un procedimiento de liberación de sesión de PDU en el UP 1 activa el UP 1 para notificar la información de cobro al CP. La información notificada del UP 1 incluye un motivo de notificación (es decir, una condición para activar la notificación). El motivo de notificación en la presente memoria es la liberación de sesión de PDU.

Etapa 3: si el OCS entrega, para la cuota, una condición de activación que indica un cambio del UP, la notificación realizada por el UP 1 hace que se cumpla la condición de activación, para que el CP realice las etapas 503 a 505 de A1; o si el OCS no entrega, para la cuota, una condición de activación que indique un cambio del UP, el CP realiza las etapas 603 a 605 de A2.

El OCS entrega la cuota al CP. El OCS entrega, en función de una decisión del OCS o en una configuración del operador, la condición de activación que indica el cambio del UP junto con la cuota. Por lo tanto, se puede mejorar la flexibilidad de cobro y la autonomía del OCS. Cuando es necesario usar y ejecutar diferentes tarificaciones de cobro para los flujos de datos de servicio en los diferentes UP para soportar un cobro más flexible y adecuado, el OCS indica al CP que notifique la migración del flujo de datos entre los UP. Cuando el OCS no necesita realizar procesamiento de cobro en función de los UP, el OCS indica al CP que no notifique la migración del flujo de datos entre los UP, para reducir la señalización.

A continuación se describe el caso B: el CP establece una sesión de PDU entre el UE y el UP 2 pero no elimina una conexión entre el UE y el UP 1. En otras palabras, una sesión de PDU corresponde a una pluralidad de UP al mismo tiempo. En este caso, el UP del flujo de datos cambia y el procesamiento se realiza en dos casos:B1: después de que se establece la sesión de PDU entre el UE y el UP 2, si se migra un flujo de datos de servicio en el UP 1 al UP 2, y el flujo de datos de servicio en el UP 1 usa una clave de cobro (CK) como una granularidad. Se incluye un caso en el que todos los flujos de datos en el UP 1 se migran al UP 2, como se muestra en un ejemplo en la Tabla 1.

Tabla 1

Además, se incluye un caso en el que los flujos de datos correspondientes a una clave de cobro (por ejemplo, una CK 2) en el UP 1 se migran al UP 2, como se muestra en un ejemplo en la Tabla 2.

Tabla 2

El CP puede determinar, durante o después de la migración, si un flujo de datos correspondiente a una clave de cobro cruza los UP; o puede considerar, cuando entrega una tabla de enrutamiento, si un flujo de datos correspondiente a una clave de cobro cruza los UP. Para ser específicos, controlar, usando la tabla de enrutamiento cuando se genera una política de enrutamiento, si el flujo de datos correspondiente a la clave de cobro cruza los UP. Un método específico puede ser el siguiente: el CP determina, en función de tablas de enrutamiento generadas por el CP para el UP 1 y el UP 2 y una plantilla de flujo correspondiente a una clave de cobro entregada por la PCF, si el contenido cubierto por la plantilla de flujo correspondiente a la clave de cobro se distribuye a las tablas de enrutamiento del UP 1 y el UP 2, para determinar si un flujo de datos correspondiente a la clave de cobro cruza los UP.

En esta realización, cuando el CP determina que el flujo de datos de servicio cruza los UP usando la CK como una granularidad, un método de cobro específico es el siguiente:

B11: para un método de procesamiento de cobro proporcionado cuando el OCS detecta migración de un flujo de datos entre los UP, consulte la FIG. 7.

Etapa 701: el CP determina un UP cuyo flujo de datos necesita cambiarse (un UP que realiza cambios de cobro).

Etapa 702: el CP inicia el establecimiento de una sesión de PDU en el UP 2.

Etapa 703: después de que el establecimiento de la sesión de PDU en el UP 2 tenga éxito, la SMF notifica al UE, y el UE inicia la migración, un flujo de datos de enlace ascendente enviado por el UE a la sesión de PDU en el UP 2. Cuando se recibe el flujo de enlace ascendente, el UP 2 activa un evento de inicio de SDF (inicio del flujo de datos de servicio) y notifica el evento al CP.

Etapa 704: después de recibir el evento de inicio de SDF notificado por el UP 2, el CP envía, al UP 1, un mensaje para solicitar notificar información de cobro, y recibe la información de cobro notificada por el UP 1. La información notificada del UP 1 incluye un motivo de notificación (es decir, una condición para activar la notificación). El motivo de notificación en la presente memoria es la liberación de sesión de PDU.

Ejemplo de un formato de la información notificada:

Etapa 705: el CP genera, en función de la información de cobro notificada por el UP 1, información de cobro a notificar al OCS; notifica la información de cobro al OCS, donde el motivo de notificación indica que el UP cambia; y solicita una nueva cuota.

Ejemplo de un formato de notificación:

Unidad-Servicio-Usado

Motivo-Notificación (que indica un motivo de notificación: UP cambiado)

Cambio-Tiempo-Tarifa

Tiempo-CC

Octetos- Total-CC

Octetos-Entrada-CC

Octetos-Salida-CC

Grupo-Tarificación

Etapa 706: el OCS entrega la nueva cuota al CP.

Etapa 707: el CP genera, en función de la nueva cuota, información a entregar el UP 2, donde la información transporta la información correspondiente de la nueva cuota; y entrega la información generada al UP 2, para que el UP 2 use la nueva cuota para un flujo de datos posterior.

Posteriormente, después de recibir un evento de terminación de SDF desde el UP 1, el CP activa la liberación de la sesión de PDU entre el UE y el UP 1.

B12: en la FIG. 8 se muestra un método de procesamiento de cobro proporcionado cuando el OCS no detecta la migración de un flujo de datos entre los UP. Las etapas específicas se describen como sigue:

Etapa 801: el CP determina un UP cuyo flujo de datos necesita ser cambiado (un UP que realiza cambios de recopilación de cobro).

Etapa 802: el CP inicia el establecimiento de una sesión de PDU en el UP 2.

Específicamente, el CP inicia un procedimiento de establecimiento de sesión de PDU del UP 2.

Etapa 803: después de que el establecimiento de la sesión de PDU en el UP 2 tenga éxito, el UE migra un flujo de datos de enlace ascendente enviado por el UE a la sesión de PDU en el UP 2. Cuando recibe el flujo de enlace ascendente, el UP 2 activa un evento de inicio de SDF y notifica el evento de inicio de SDF al CP. Etapa 804: después de recibir el evento de inicio de SDF notificado por el UP 2, el CP envía, al UP 1, un mensaje para solicitar notificar información de cobro, y recibe la información de cobro notificada por el UP 1. La información notificada del UP 1 incluye un motivo de notificación (es decir, una condición para activar la notificación). El motivo de notificación en la presente memoria es la liberación de sesión de PDU.

Etapa 805: el CP determina una cuota disponible restante en función de la información de cobro del flujo de datos que notifica al UP 1, y genera, en función de la cuota disponible restante, información a entregar al UP 2. La información a entregar al UP 2 transporta información de la cuota disponible restante.

Un método para determinar, por el CP, la cuota restante en función de la información de cobro notificada por el UP 1 es uno de los siguientes:

a. Si el CP almacena en caché la información de la cuota cuando entrega la cuota al UP 1, el UP 1 notifica la información de uso de la cuota, y el CP deduce la información de uso de la cuota notificada por el UP 1 de la información de la cuota almacenada en caché, para obtener la cuota disponible restante.

Ejemplo de un formato de la información notificada:

b. Si el CP no almacena en caché la información de la cuota cuando entrega la cuota al UP 1, el UP 1 notifica tanto la información de uso de la cuota como un valor de cuota restante, y el CP usa el valor de cuota restante recibido notificado por el UP 1 como la cuota disponible restante.

Después de obtener la cuota disponible restante, el CP determina además si se cumple una condición para notificar al OCS. La determinación se realiza en función de una condición de activación proporcionada por el OCS. Por ejemplo, si la cuota restante es ligeramente inferior a un umbral especificado por el OCS, se cumple la condición de notificación al OCS. Si se cumple la condición, la información a notificar al OCS se genera en función de la notificación realizada por el UP 1, y el CP normalmente notifica la información generada a notificar al OCS al OCS y solicita una nueva cuota. Un motivo de notificación indica que se cumple la condición de activación. Si no se cumple la condición de notificación al OCS, la información a entregar al UP 2 se genera en función de la cuota disponible restante. La información generada a entregar al UP 2 transporta la información correspondiente de la cuota disponible restante.

Etapa 806: el CP entrega la información generada al UP 2, donde la información a entregar al UP2 transporta la cuota disponible restante, para que el UP 2 use la cuota disponible restante para un flujo de datos posterior.

- El CP almacena en caché la información de uso notificada por el UP 1.

- El CP entrega la información notificada por el UP 1 al UP 2, y el UP 2 contabiliza continuamente en función de la información notificada.

Etapa 807: el CP recibe información de uso notificada por el UP 2 cuando se cumple una condición de notificación, genera, en función de la información de uso notificada por el UP 1 y la información de uso notificada por el UP 2, información a notificar al OCS, y notifica la información generada al OCS.

Específicamente, si el CP almacena en caché la información de cobro notificada por el UP 1, el CP fusiona la información de uso notificada por el UP 2 y la información de uso en caché notificada por el UP 1 para generar la información de cobro a notificar al<o C s ,>y notifica la información de cobro generada al<o C s .>Si el CP previamente también entrega la información notificada por el UP 1 al UP 2, el UP 2 acumula continuamente en función de la información de uso notificada por el UP 1 y realiza fusión y notificación. El CP genera, en función de la información de cobro notificada por el UP 2, la información de cobro a notificar al OCS, y notifica la información de cobro al OCS.

En las soluciones de las realizaciones B11 y B12 de la presente invención, el CP usa el evento de inicio de SDF notificado por el UP 2 como un indicador que indica el establecimiento con éxito de la sesión de PDU en el UP 2 y el inicio de transmisión de datos, para activar el envío al UP 1, de un mensaje para solicitar notificar la información de cobro, implementando así el cobro cuando una sesión de PDU corresponde a una pluralidad de UP, y un flujo de datos correspondiente a una misma clave de cobro no cruza los UP. En las soluciones de B11 y B12, se distinguen aún más las maneras de procesamiento en las que el OCS detecta y no detecta la migración, para que el procesamiento de cobro sea más flexible.

B13: el CP determina usar el método en B11 o B12 como lo indica el OCS.

Cuando se entrega la cuota al CP, en función de una decisión del OCS, el OCS puede entregar, junto con la cuota, una condición de activación que indica un cambio del UP; o puede no entregar la condición de activación.

La condición de activación indica al CP que inicie la reautorización al OCS cuando cambie el UP que usa la cuota. Las etapas específicas se describen a continuación:

Etapa 1: el CP determina un UP cuyo flujo de datos necesita cambiarse (un UP que realiza cambios de cobro).

Etapa 2: el CP inicia el establecimiento de una sesión de PDU en el UP 2.

Etapa 3: el UE migra un flujo de datos de enlace ascendente enviado por el UE a la sesión de PDU en el UP 2. Cuando se recibe el flujo de enlace ascendente del UE, el UP 2 activa un evento de inicio de SDF y notifica el evento al CP.

Etapa 4: después de recibir el evento de inicio de SDF notificado por el UP 2, el CP envía al UP 1 un mensaje para solicitar notificar información de cobro y recibe la información de cobro notificada por el UP 1. La información notificada del UP 1 incluye un motivo de notificación (es decir, una condición para activar la notificación), y el motivo de notificación en la presente memoria es la liberación de sesión de PDU.

Etapa 5: si el OCS entrega, para la cuota, una condición de activación que indica un cambio de UP, la notificación realizada por el UP 1 hace que se cumpla la condición de activación, para que el CP realice las etapas 705 a 707 de B11; o si el OCS no entrega, para la cuota, una condición de activación que indique un cambio del UP, el CP realiza las etapas 805 a 807 de B12.

En la solución de la realización B13 de la presente invención, cuando se entrega la cuota al CP, el OCS entrega, en función de una decisión del OCS o una configuración del operador, la condición de activación que indica el cambio del UP junto con la cuota. Para mejorar la flexibilidad de carga y mejorar la autonomía del OCS. El OCS da instrucciones al CP para que informe de la migración del flujo de datos entre los UP cuando sea necesario usar y ejecutar diferentes tarifas de cobro para los flujos de datos de servicio en las diferentes UP para soportar un cobro más flexible y adecuado. Y el OCS da instrucciones al CP para que no informe de la migración del flujo de datos entre los UP para reducir la señalización, cuando el OCS no necesita realizar el procesamiento de cobro basado en los UP.

B2: después de que se establece la sesión de PDU en el UP 2, si un flujo de datos de servicio en el UP 1 se migra al UP 2, y un flujo de datos de servicio correspondiente a una clave de cobro cruza los UP, en otras palabras, dentro de un período de tiempo (generalmente, después de que el UP 2 envíe el evento de inicio de SDF y antes de que el UP 1 envíe el evento de terminación de SDF), existe un flujo de datos de servicio correspondiente a una misma clave de cobro tanto en el UP 1 como en el UP 2 al mismo tiempo, como se ilustra en la Tabla 3:

Tabla 3

El CP puede determinar, después de la migración, si un flujo de datos de una clave de cobro cruza los UP; o controlar, usando una tabla de enrutamiento cuando se genera una política de enrutamiento, si un flujo de datos de una clave de cobro cruza los UP. Un método específico puede ser el siguiente: el CP determina, en función de tablas de enrutamiento generadas por el CP para el UP 1 y el UP 2 y una plantilla de flujo correspondiente a una clave de cobro entregada por la PCF, si el contenido cubierto por la plantilla de flujo correspondiente a la clave de cobro se distribuye a las tablas de enrutamiento del UP 1 y el UP 2, para determinar si un flujo de datos correspondiente a la clave de cobro cruza los UP. En el ejemplo de la Tabla 3, el flujo de datos SF 1 correspondiente al CK 1 cruza los UP. Un método de procesamiento específico para el cobro es el siguiente:

B21: el CP gestiona una cuota, que incluye el control de uso de la cuota y la notificación de la cuota.

Para una manera de usar una interfaz de protocolo basada en servicios (por ejemplo, Restful), el CP y el OCS pueden interactuar directamente entre sí usando un mensaje basado en servicios.

Para una interfaz de protocolo de Diámetro, se usa una sesión de cobro para una sesión de PDU. En otras palabras, no se añade ninguna nueva sesión de cobro debido a la migración de un flujo de datos. Haciendo referencia a la FIG. 9, cabe señalar que en las siguientes etapas, las partes no relacionadas con la interacción entre el CP y el OCS también son aplicables a la manera de usar la interfaz de protocolo basada en servicios. Las etapas específicas se describen a continuación:

Etapa 901: el CP determina un UP que recopila información de cobro.

Debido a que existe un flujo de datos de servicio correspondiente a una misma clave de cobro tanto en el UP 1 como en el UP 2 cuando se migra un flujo de datos, el CP necesita determinar el UP que recopila la información de cobro. Específicamente, el CP determina, en función de una política enviada y activada por la PCF, el UP que recopila la información de cobro. El UP 1 y el UP 2 en la presente memoria son puntos de recopilación de cobro determinados por el CP. Un momento en el que el CP determina el UP que recopila la información de cobro y un momento en el que el CP determina que el flujo de datos correspondiente al CK cruza los UP no tienen una relación de secuencia temporal estricta.

Etapa 902: el CP procesa una cuota otorgada por el OCS.

La cuota otorgada por el OCS en la presente memoria incluye: una cuota recientemente otorgada por el OCS (el CP se aplica al OCS para la cuota en función de la clave de cobro) o una cuota disponible que no se use en el UP 1 y que obtiene el CP.

Debido a que una pluralidad de UP son lógicamente independientes, el CP necesita controlar por separado una cuota para cada UP, incluyendo: entrega de la cuota y notificación de información de uso. Debido a que las políticas que entrega la PCF para diferentes UP usan la misma clave de cobro, y el OCS asigna la cuota en función de la clave de cobro, la cuota que recibe el CP y que asigna el OCS puede ser una cuota de UP cruzada. Para evitar que la cuota asignada por el OCS cruce los UP o garantizar el uso normal de una cuota cruzada, un método específico es el siguiente:

Etapa 9021: el CP solicita al OCS una cuota de una clave de cobro independientemente de si la clave de cobro cruza los UP.

Etapa 9022: después de recibir la cuota asignada por el OCS y cuando se genera una regla a entregar al UP, el CP determina si la cuota es compartida por una pluralidad de UP. Específicamente, el CP puede determinar, en función de si los flujos de datos correspondientes a la clave de cobro correspondiente a la cuota se distribuyen en diferentes UP, si la cuota es compartida por la pluralidad de UP. Si los flujos de datos correspondientes a la clave de cobro se distribuyen en la pluralidad de UP, la cuota es compartida por la pluralidad de UP.

Etapa 9023: si el CP detecta que una cuota cruza los UP, el CP divide la cuota en cuotas pequeñas, asigna una cuota pequeña para cada UP y luego genera, usando las cuotas pequeñas, una regla a entregar al UP, y entrega la regla alpara su ejecución. El CP registra una correspondencia entre estas pequeñas cuotas obtenidas mediante división y los UP.

Etapa 9024: el CP recibe datos de cobro que son notificados por cualquier UP (por ejemplo, el UP 1) cuando la cuota se agota o cuando se cumple una condición de notificación, el CP envía a otros UP en función de la correspondencia almacenada entre las cuotas pequeñas y los UP, una solicitud para solicitar notificar la información de uso de la cuota, y el CP puede realizar el siguiente procesamiento después de recibir la información de uso de la cuota que devuelven todos los UP:

El CP fusiona los información de uso de la cuota que notifican todos los UP en un mensaje y notifica el mensaje al OCS. La información de uso de cada UP en el mensaje se usa como un contenedor independiente. Un contenedor correspondiente a la información notificada por el UP 1 incluye un activador que se cumple y un identificador de Up correspondiente. Un contenedor correspondiente a la información notificada por otra UP incluye información que indica que la notificación es causada por otra notificación. Específicamente, se puede transportar un activador relacionado en el contenedor, o un valor de un motivo de notificación indica una notificación relacionada, y se transporta en un identificador UP correspondiente.

Ejemplo de un formato de notificación:

Mensaje CCA

Grupo-Tarificación Correspondiente a una clave de cobro

Unidad-Servicio-Usada Correspondiente al UP 1

Motivo-Notificación (que indica un motivo de notificación: cumple activación)

Cambio-Tiempo-Tarifa

Tiempo-CC

Octetos- Total-CC

Octetos-Entrada-CC

Octetos-Salida-CC

Unidad-Servicio-Usada Correspondiente al UP 2

Motivo-Notificación (que indica un motivo de notificación: notificación relacionada)

Cambio-Tiempo-Tarifa

Tiempo-CC

Octetos-Total-CC

Octetos-Entrada-CC

Octetos-Salida-CC

Alternativamente, la información de uso notificada por todos los UP se fusiona y se usa un contenedor para notificar la información de uso fusionada. Si existe Cambio_Tiempo_Tarifa (Tariff-Time-Change), durante la fusión, se fusionan las partes anteriores al Tariff-Time-Change en la información notificada de cada UP, y las partes posteriores al Tariff-Time-Change en la información notificada de cada UP.

El mensaje notificado puede transportar además un motivo de notificación, y el motivo es: notificación causada por un UP.

Ejemplo de un mensaje:

Mensaje CCA

Grupo-Tarificación Correspondiente a una clave de cobro

Unidad-Servicio-Usada Fusionada con información de uso del UP1 y del UP2

Motivo-Notificación (que indica un motivo de notificación: notificación causada por un UP)

Cambio-Tiempo-Tarifa

Tiempo-CC

Octetos-Total-CC

Octetos-Entrada-CC

Octetos-Salida-CC

El CP almacena en caché la información de uso notificada por los UP (la información se notifica al OCS cuando se realiza la notificación al OCS la próxima vez), calcula las cuotas disponibles restantes no usadas y luego vuelve a dividir las cuotas disponibles restantes no usadas en cuotas pequeñas (se asigna una cuota pequeña a cada UP) y entrega las cuotas pequeñas a los UP para su uso posterior.

Uno de (a) y (b) puede seleccionarse para la implementación.

Alternativamente, se pueden implementar tanto (a) como (b). Si se implementan tanto (a) como (b), el CP debe realizar una determinación adicional: si se cumple una condición para notificar al OCS (la condición de notificación puede ser una condición de activación de reautorización entregada por el OCS o una condición de limitación de uso de la cuota, por ejemplo, la cuota vence), se realiza (a); en caso contrario, se realiza (b).

En la solución de la realización B21 de la presente invención, el CP controla el uso de la cuota en la pluralidad de UP, para coordinar el intercambio de la cuota entre la pluralidad de UP y proteger el impacto de la complejidad de uso de la cuota en el OCS, mejorando así la eficiencia del OCS.

B22: para un caso en el que cuando el CP interactúa con el sistema de cobro usando el protocolo Diámetro, el CP establece una nueva sesión de cobro en línea para el UP 2, consulte la FIG. 10.

Etapa 1001: el CP determina un UP que recopila información de cobro.

Si hay una pluralidad de UP, el CP necesita determinar el UP que recopila la información de cobro. Específicamente, el CP recibe una política activada por la PCF y determina, en función de la política, el UP que recopila la información de cobro. El UP 1 y el UP 2 son puntos de recopilación de información de cobro.

Etapa 1002: el CP determina que un flujo de datos de servicio correspondiente a una clave de cobro de la sesión de PDU cruza los UP, y el CP inicia al OCS para establecer una nueva sesión de cobro en línea dedicada a UP 2 para un UP que se crea y que necesita realizar el cómputo de los cobros en línea. La figura es solo un ejemplo. Cabe señalar que un momento en que el CP determina el UP que recopila la información de cobro y un momento en que el CP determina que el flujo de datos correspondiente a la CK cruza los UP no tienen una relación de secuencia temporal estricta.

Específicamente, el CP determina un modo de SSC actual. Si el modo de SSC es un modo 3 de SSC, se supone que un flujo de datos de servicio correspondiente a una clave de cobro particular puede cruzar los UP, se inicia el establecimiento de una nueva sesión de cobro para el UP 2.

Alternativamente, si el modo de SSC es el modo 3 de SSC, en función de la información de enrutamiento asignada, hay un flujo de datos de servicio correspondiente a una clave de cobro particular que cruza e UP 1 y el UP 2, y se inicia el establecimiento de una nueva sesión de cobro para el UP 2.

Si el CP añade un BP o CL de UL para la sesión de PDU, después de que se determina el UP que necesita realizar el cómputo de cobros en línea, también se realiza la determinación anterior. Si hay un flujo de datos de servicio correspondiente a una clave de cobro particular que cruza el UP 1 y el2, se inicia el establecimiento de una nueva sesión de cobro para el UP 2 o el BP o CL de UL que va a realizar una función de cobro en línea.

El CP almacena una correspondencia entre el UP y la sesión de cobro.

En este caso, el CP solicita por separado una cuota, gestiona el uso de la cuota y notifica información de uso de la cuota para el UP 2 en la nueva sesión de cobro.

Etapa B1003: cuando se elimina la sesión de PDU en el UP 1 o cuando no hay flujo de datos en el UP 1, el CP determina iniciar al OCS para eliminar una sesión de cobro correspondiente al UP 1.

Cuando o antes de que se elimine la sesión de cobro correspondiente al UP 1, la información de uso de cuota recopilada en el UP 1 se notifica al OCS.

Además, si el CP elimina una sesión de PDU en un UP particular, las etapas se muestran en la FIG. 11 y son los siguientes:

Etapa 1101: el CP determina eliminar una sesión de PDU en el UP 1.

Etapa 1102: el CP entrega información al UP 1 y elimina la sesión de PDU.

Etapa 1103: el CP recibe información de cobro notificada por el UP 1.

Etapa 1104: el CP inicia, en función de la correspondencia almacenada entre el UP 1 y una sesión de cobro correspondiente al UP 1, una solicitud de finalización de la sesión de cobro al OCS. La solicitud de finalización transporta la información de uso notificada por el UP 1.

Las sesiones de cobro en línea de otros UP no se ven afectadas por el final de la sesión de PDU en el UP 1 y no se ven afectadas por el final de la sesión de cobro en línea correspondiente al UP 1.

En la solución de la realización B22 de la presente invención, el CP establece una sesión de cobro independiente para cada UP, reduciendo así la complejidad de implementación del CP y el OCS, y el CP no necesita coordinar el uso de un cuota entre una pluralidad de UP.

Solución C: una realización de la presente invención proporciona además un método de cobro. El método describe la interacción entre un CP, dos UP correspondientes al CP y un sistema de cobro desde una perspectiva estática, y completa la recopilación y notificación de información de cobro y un proceso de aplicación y entrega de cuota.

El método incluye: obtener, por una entidad de función del plano de control CP de una entidad de función de primer plano de usuario UP y un segundo UP, información de cobro de un flujo de datos en una sesión de PDU correspondiente al CP, donde el primer UP y el segundo UP son UP correspondientes al CP; y dividir, por el CP, una cuota que se entrega mediante un sistema de cobro en una pluralidad de subcuotas y entregar la pluralidad de subcuotas al primer UP y al segundo UP.

Normalmente, el flujo de datos que usa una misma clave de cobro existe en el primer UP y en el segundo UP. El CP obtiene información de cobro del flujo de datos tanto del primer UP como del segundo UP. En el caso de usar una interfaz de protocolo de Diámetro, el CP cobra el primer UP y el segundo UP a través de una sesión de cobro entre el CP y el sistema de cobro.

La división, por el CP, de una cuota que es entregada por un sistema de cobro en una pluralidad de subcuotas y la entrega de la pluralidad de subcuotas a los UP incluye: dividir, por el CP, una cuota que es entregada por el sistema de cobro para la clave de cobro en una pluralidad de subcuotas y entregar por separado la pluralidad de subcuotas al primer UP y al segundo UP.

El método incluye además: después de que se agote una subcuota en cualquier UP y se notifique la información de cobro correspondiente a la subcuota, obtener, por el CP, información de cobro correspondiente a las subcuotas que se contabilizan por otros UP; y fusionar, por el CP, la información de cobro correspondiente a las subcuotas, y notificar la información de cobro al sistema de cobro.

El método incluye además: después de que se agote una subcuota en cualquier UP y se notifique la información de cobro correspondiente a la cuota, obtener, por el CP, información de cobro correspondiente a las subcuotas que se contabilizan por otros UP; y almacenar en caché, por el CP, información de cobro correspondiente a las cuotas que notifican todos los UP, determinar las cantidades restantes disponibles de las subcuotas, reasignar las cantidades restantes disponibles de las subcuotas y entregar las cantidades restantes disponibles de las subcuotas al primer UP y al segundo UP; y cuando las cuotas se agotan o las cantidades restantes disponibles de las subcuotas alcanzan un umbral de notificación, fusionar, por el CP, la información de cobros almacenada en caché correspondiente a las cuotas, y notificar la información de cobros fusionada al sistema de cobro.

Cabe señalar que para la solución C, se puede hacer referencia al contenido relacionado de las etapas en las realizaciones A y B anteriores, especialmente, un caso de la realización B21, en función de la correlación de los mismos, y detalles no se describen de nuevo en la presente memoria. Según las soluciones técnicas descritas en esta realización, el CP puede cobrar flujos de datos generados en dos UP correspondientes al CP al mismo tiempo.

El sistema de cobro incluye un sistema de cobro en línea OCS y un sistema de cobro en línea OFCS. El cobro fuera de línea se relaciona solo con la recopilación y notificación de información de cobro (incluida una condición de activación de notificaciones), y el cobro en línea incluye además la concesión de cuota, la gestión de uso de cuota (incluida la supervisión de una condición de uso de cuota), un activador dinámico (una condición de activación activada por el OCS) y notificaciones de información de uso de cuota, además de recopilación y notificaciones de información de cobros similares a los de los cobros fuera de línea. A menos que se describa especialmente en esta solicitud, las notificaciones de cobro se aplican a las notificaciones de cobro en línea y a las notificaciones de cobro fuera de línea, pero la aplicación de cuota de cobro, la gestión de uso de cuota y un activador dinámico se aplican solo al cobro en línea. Hay varios métodos para el cobro fuera de línea, entre ellos: una CTF notifica la información del cobro en tiempo real; la CTF notifica un CDR después de generar el CDR; y la CTF notifica directamente un archivo CDR después de generar el archivo CDR. Las granularidades de recopilación de la información de cobro, las condiciones de activación para activar las notificaciones o escribir el CDR en tiempo real y similares son todas iguales en las varias maneras. Por lo tanto, esta realización de esta solicitud se describe solo usando un ejemplo en el que la CTF notifica la información de cobro en tiempo real.

Para el caso A en las realizaciones anteriores, es decir, el CP primero elimina una conexión entre el UE y el UP 1 y luego establece una conexión entre el UE y el UP 2, se describe brevemente un método de cobro fuera de línea como sigue. Para conocer los detalles relacionados, consulte las realizaciones anteriores. Los detalles no se describen de nuevo en la presente memoria.

Etapa 1: el CP determina un UP cuyo flujo de datos necesita ser cambiado (un UP que realiza cambios de cobro), y el primer CP termina una sesión de PDU entre el UE y el UP 1 y establece una sesión de PDU entre el UE y el UP 2.

Etapa 2: el CP inicia la terminación de la sesión de PDU en el UP 1 y recibe información de cobro notificada por el UP 1.

Una sesión de PDU termina el procedimiento en el UP 1 activa el UP 1 para notificar la información de cobro al CP. La información notificada del UP 1 incluye un motivo de notificación (es decir, una condición para activar la notificación). El motivo de notificación en la presente memoria es la liberación de sesión de PDU.

Etapa 3 (el sistema de cobro detecta la conmutación entre los UP): el CP notifica la información de cobro a una CDF/CGF/BS, donde un motivo de notificación es "UP cambiado".

Etapa 3' (el sistema de cobro no detecta la conmutación entre los UP): el CP almacena en caché la información de uso notificada por el UP 1 y espera a que el UP 2 notifique la información de uso, y después de recibir la información de uso notificada por el UP 2, el CP fusiona la información de uso notificada por el UP 2 y la información de uso en caché notificada por el UP 1 y notifica información fusionada a la CDF/CGF/BS.

Para el caso B, es decir, el CP establece una conexión entre el UE y el UP 2 pero no elimina una conexión entre el UE y el UP 1, un método de cobro fuera de línea se describe brevemente a continuación:

Etapa 1: el CP determina un UP cuyo flujo de datos necesita cambiarse (un UP que realiza cambios de cobro), y el CP primero establece una sesión de PDU entre el UE y el UP 2, y finaliza una sesión de PDU entre el UE y el UP 1 después de que el flujo de datos se transfiera al2.

Etapa 2: el CP inicia el establecimiento de una sesión de PDU en el UP 2.

Etapa 3: el UE migra un flujo de datos de enlace ascendente enviado por el UE a la sesión de PDU en el UP 2. Cuando se recibe el flujo de enlace ascendente, el UP 2 activa un evento de inicio de SDF y notifica el evento al CP.

Etapa 4: después de recibir el evento de inicio de SDF notificado por el UP 2, el CP envía, al UP 1, un mensaje para solicitar notificar información de cobro, y recibe la información de cobro notificada por el UP 1.

Etapa 5 (el sistema de cobro detecta la conmutación entre los UP): el CP notifica la información de cobro a una CDF/CGF/BS, donde un motivo de notificación es "UP cambiado".

Etapa 5' (el sistema de cobro no detecta la conmutación entre los UP): el CP almacena en caché la información de uso notificada por el UP 1 y espera a que el UP 2 notifique la información de uso, y después de recibir la información de uso notificada por el UP 2, el CP fusiona la información de uso notificada por el UP 2 y la información de uso en caché notificada por el UP 1 y notifica la información fusionada a la CDF/CGF/BS.

En la solución fuera de línea de esta realización de la presente invención, en un escenario relativamente complejo en el que un plano de control y un plano de usuario están separados, por ejemplo, cuando un plano de usuario de una sesión de PDU conmuta o cuando una sesión de PDU tiene una pluralidad de planos de usuario, un flujo de datos de servicio de un usuario se cobra en un caso de migración entre planos de usuario, para que el cobro fuera de línea puede soportar un menor retardo de extremo a extremo de un servicio, y la eficiencia de la red se mejora usando un despliegue óptimo, cobrando así con precisión un servicio de datos en el despliegue óptimo y mejorando la eficiencia de la red y la experiencia del usuario.

Lo anterior describe principalmente las soluciones proporcionadas en las realizaciones de esta solicitud desde una perspectiva de interacción entre elementos de red. Se puede entender que para implementar las funciones anteriores, el CP, UP u OCS/OFCS incluye estructuras de hardware y/o módulos de software para realizar las funciones. Un experto en la técnica debería saber fácilmente que, con referencia a los ejemplos de unidades y etapas de los algoritmos que se describen en las realizaciones descritas en esta memoria descriptiva, esta solicitud puede implementarse mediante hardware o una combinación de hardware y software informático. Si una función se realiza mediante hardware o hardware accionado por software informático depende de aplicaciones y restricciones de diseño particulares de las soluciones técnicas. Un experto en la técnica puede usar diferentes métodos para implementar las funciones descritas para cada aplicación particular, pero no debe considerarse que la implementación va más allá del alcance de esta solicitud.

En esta realización de esta solicitud, los módulos funcionales del CP y OCS/OFCS pueden dividirse en función de los ejemplos de métodos anteriores. Por ejemplo, los módulos funcionales se pueden dividir en función de las funciones correspondientes, o dos o más funciones se pueden integrar en un módulo de procesamiento. El módulo integrado se puede implementar en forma de hardware, o se puede implementar en forma de un módulo funcional de software. Cabe señalar que en esta realización de esta solicitud, la división en módulos es un ejemplo y es simplemente una división en funciones lógicas. En una implementación real, se puede usar otra manera de división.

Por ejemplo, cuando las funciones correspondientes se usan para dividir los módulos funcionales, la FIG. 12 es un posible diagrama estructural esquemático del CP en las realizaciones anteriores usado como un dispositivo 1200 de cobro.

El dispositivo 1200 de cobro incluye un módulo 1202 de determinación, un módulo 1206 de obtención y un módulo 1208 de procesamiento. El módulo 1202 de determinación está configurado para determinar que un flujo de datos que se transmite por el equipo de usuario UE en una primera sesión de datos necesita migrarse a una segunda sesión de datos, donde la primera sesión de datos es una sesión de datos entre el UE y una entidad de función de primer plano de usuario UP, la segunda sesión de datos es una sesión de datos entre el UE y un segundo UP, el primer UP y el segundo UP son UP correspondientes al dispositivo de cobro, y la primera sesión de datos y la segunda sesión de datos corresponden a una misma sesión de PDU. El módulo 1206 de obtención está configurado para obtener información de cobro del flujo de datos antes de la migración que contabiliza el primer UP. El módulo 1208 de procesamiento está configurado para: determinar una cuota que se usa para el flujo de datos que después de la migración es necesario que sea entregada al segundo UP, y entregar la cuota al segundo UP.

Una interfaz de notificación de información de cobro puede ser una interfaz de protocolo de Diámetro o una interfaz basada en servicios. En una manera de usar una interfaz basada en servicios, no se establece una sesión de cobro entre un CP y un sistema de cobro, sino que el CP y el sistema de cobro interactúan entre sí directamente usando un mensaje basado en servicios. El mensaje basado en servicios (por ejemplo, Restful) es un mensaje sin estado. Cada mensaje transporta información completa. En el caso de usar la interfaz del protocolo Diámetro, es necesario establecer una sesión de cobro entre el CP y el sistema de cobro.

Opcionalmente, el dispositivo de cobro incluye además un módulo 1204 de sesión, configurado para: establecer una primera sesión de cobro al sistema de cobro y cobrar el flujo de datos en el primer UP usando la primera sesión de cobro, donde el módulo 1202 de determinación está configurado además para determinar que no existe ningún otro flujo de datos que use una clave de cobro que corresponda al flujo de datos en el primer UP después de que el flujo de datos se migre desde el primer UP al segundo UP, y el módulo 1204 de sesión está configurado además para cobrar el flujo de datos en el segundo UP usando la primera sesión de cobro.

Opcionalmente, el módulo 1206 de obtención está configurado para: recibir información de cobro del flujo de datos antes de la migración que notifica el primer UP, notificar la información de cobro al sistema de cobro usando el módulo 1204 de sesión, y solicitar una cuota para el flujo de datos para el segundo UP; el módulo 1204 de sesión está configurado para recibir una cuota entregada por el sistema de cobro; y el módulo 1208 de procesamiento está configurado para generar, en función de la cuota entregada por el sistema de cobro, la cuota a entregar al segundo UP.

Opcionalmente, el módulo 1208 de procesamiento está configurado para: determinar una cuota disponible restante en función de la información de cobro obtenida del flujo de datos antes de la migración que es contabilizada por el primer UP, y generar, en función de la cuota disponible restante, la cuota a entregar al segundo UP.

Opcionalmente, el módulo 1206 de obtención está configurado para recibir información de cobro que es notificada por el primer UP usando la activación de interrupción de la primera sesión de datos.

Opcionalmente, el módulo 1206 de obtención está configurado para: después de que se detecta un evento de inicio de flujo de datos correspondiente al flujo de datos que notifica el segundo UP, obtener la información de cobro del flujo de datos antes de la migración que se contabiliza por el primer UP.

Opcionalmente, el módulo 1202 de determinación está configurado para determinar que otro flujo de datos que usa una clave de cobro que corresponde al flujo de datos existe en el primer UP después de que el flujo de datos se migre desde el primer UP al segundo UP; y el módulo 1206 de obtención está configurado además para obtener la información de cobro del flujo de datos tanto del primer UP como del segundo UP.

Opcionalmente, el módulo 1202 de determinación está configurado además para determinar que otro flujo de datos que usa una clave de cobro que corresponde al flujo de datos existe en el primer UP después de que el flujo de datos se migre desde el primer UP al segundo UP; el módulo 1204 de sesión está configurado además para: establecer una segunda sesión de cobro con el sistema de cobro para la segunda sesión de datos en la que se transmite el flujo de datos en el segundo UP, y solicitar al sistema de cobro una cuota para el segundo Uusando el segunda sesión de cobro; y el módulo 1208 de procesamiento está configurado además para entregar la cuota aplicada al segundo UP.

Cabe señalar que para las descripciones funcionales de los módulos funcionales correspondientes, se puede hacer referencia a todo el contenido relacionado de las etapas en las realizaciones de métodos anteriores. Los detalles no se describen de nuevo en la presente memoria.

Cuando los módulos funcionales se dividen de una manera integrada, la FIG. 13 es un posible diagrama estructural esquemático de un sistema 1300 de cobro en las realizaciones anteriores. El sistema 1300 de cobro incluye un módulo 1302 de entrega y un módulo 1304 de recepción.

El módulo 1302 de entrega está configurado para entregar información de indicación a una entidad de función del plano de control CP, donde la información de indicación se usa para: después de que una entidad de función del plano de usuario UP correspondiente al CP conmuta de un primer UP a un segundo UP, dar instrucciones al CP para que notifique la información de cobro del primer Up antes de la conmutación al OCS; y el módulo 1304 de recepción está configurado para recibir la información de cobro antes de la conmutación que notifica el CP y que contabiliza el primer UP.

Opcionalmente, el sistema de cobro es un sistema de cobro en línea OCS, y la información de indicación se entrega junto con una cuota entregada por el OCS al CP.

Opcionalmente, el OCS entrega una nueva cuota al CP después de recibir la información de cobro notificada por el CP.

Opcionalmente, después de recibir la información de cobro notificada por el CP, el OCS entrega una cuota para el segundo UP al CP o entrega tanto una cuota para el primer UP como una cuota para el segundo UP al CP.

Cabe señalar que para las descripciones funcionales de los módulos funcionales correspondientes, se puede hacer referencia a todo el contenido relacionado de las etapas realizadas por el sistema de cobro en las realizaciones de métodos anteriores. Los detalles no se describen de nuevo en la presente memoria.

El "módulo" en las realizaciones de la FIG. 12 y FIG. 13 puede ser un circuito integrado de aplicación específica (circuito integrado de aplicación específica, 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 están implementados en forma de un dispositivo informático. El módulo de recepción y el módulo de envío pueden implementarse usando un procesador, una memoria y una interfaz de comunicaciones del dispositivo informático. El módulo de procesamiento puede implementarse usando el procesador y la memoria del dispositivo informático.

Cabe señalar que aunque solo el procesador 302, la memoria 304, la interfaz 306 de comunicaciones y el bus 308 se muestran en el dispositivo 300 informático en la FIG. 3, en un proceso de implementación específico, un experto en la técnica debe comprender 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 comprender 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 comprender 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 mostrados 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 se puede implementar en forma de unidad de función de software.

Cuando la unidad integrada se implementa en forma de unidad de función de software y se comercializa o se usa como un producto independiente, la unidad integrada se puede almacenar en un medio de almacenamiento legible por ordenador. En función de 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 (procesador) para realizar todas o algunas de las etapas de los métodos descritos en las realizaciones de esta solicitud. El soporte de almacenamiento anterior incluye cualquier soporte que pueda almacenar código de programa, por ejemplo, una unidad flash USB, un disco duro extraíble, una memoria de solo lectura (ROM, memoria de solo lectura), una memoria de acceso aleatorio (RAM, memoria de acceso aleatorio), un disco magnético o un disco compacto.

Claims

REIVINDICACIONES

1. Un método de cobro, en donde el método comprende:

determinar (401,601), por una entidad de función del plano de control, que un flujo de datos transmitido por un equipo de usuario UE en una primera sesión de datos necesita migrarse a una segunda sesión de datos, en donde la primera sesión de datos es una sesión de datos entre el UE y una entidad de función del primer plano de usuario, la segunda sesión de datos es una sesión de datos entre el UE y una entidad de función del segundo plano de usuario, la entidad de función del primer plano de usuario y la entidad de función del segundo plano de usuario son seleccionadas por la entidad de función del plano de control; el método caracterizado por: obtener (402, 602, 603), por la entidad de función del plano de control, información de cobro del flujo de datos antes de la migración, en donde la información de cobro fue contabilizada por la entidad de función del primer plano de usuario y se notifica a la entidad de función del plano de control por la entidad de función del primer plano de usuario, la información de cobro comprende información de uso; y

determinar (603, 805), por la entidad de función del plano de control, en función de la información de cobro, que fue contabilizada por la entidad de función del primer plano de usuario, del flujo de datos y en función además de una primera cuota, una cuota disponible restante de la primera cuota; y

entregar (604, 806), por la entidad de función del plano de control, una segunda cuota a entregar a la entidad de función del segundo plano de usuario a la entidad de función del segundo plano de usuario en función de la cuota disponible restante;

almacenar en caché (604, 806), por la entidad de función del plano de control, la información de cobro notificada por la entidad de función del primer plano de usuario;

generar (605, 807), por la entidad de función del plano de control, en función de la información de uso notificada por la entidad de función del primer plano de usuario y la información de uso notificada por la entidad de función del segundo plano de usuario, información a notificar al sistema de cobro;

notificar (605, 807), por la entidad de función del plano de control, la información generada al sistema de cobro.

2. El método según la reivindicación 1, en donde el método comprende, además:

cobrar, por la entidad de función del plano de control, el flujo de datos en la entidad de función del primer plano de usuario usando una primera sesión de cobro entre la entidad de función del plano de control y un sistema de cobro;

determinar, por la entidad de función del plano de control, que no existe ningún otro flujo de datos usando una clave de cobro que corresponda al flujo de datos en la entidad de función del primer plano de usuario después de que el flujo de datos se migre desde la entidad de función del primer plano de usuario a la entidad de función del segundo plano de usuario; y

cobrar, por la entidad de función del plano de control, el flujo de datos en la entidad de función del segundo plano de usuario usando la primera sesión de cobro.

3. El método según una cualquiera de las reivindicaciones 1 y 2, en donde el método comprende además: generar (603), por la entidad de función del plano de control, la segunda cuota a entregar a la entidad de función del segundo plano de usuario en función de la cuota disponible restante.

4. El método según una cualquiera de las reivindicaciones 1-2, en donde la generación, por la entidad de función del plano de control, en función de la información de uso notificada por la entidad de función del primer plano de usuario y la información de uso notificada por la entidad de función del segundo plano de usuario, la información a notificar al sistema de cobro comprende:

fusionar (605), por la entidad de función del plano de control, la información de uso notificada por la entidad de función del segundo plano de usuario y la información de uso almacenada en caché notificada por la entidad de función del primer plano de usuario, y notificar información de uso fusionada al sistema de cobro.

5. El método según una cualquiera de las reivindicaciones 1 a 4, en donde la obtención, por la entidad de función del plano de control, de información de cobro del flujo de datos antes de la migración que es contabilizada por la entidad de función del primer plano de usuario comprende:

recibir, por la entidad de función del plano de control, la información de cobro que es notificada por la entidad de función del primer plano de usuario a través de la activación de la interrupción de la primera sesión de datos.

6. El método según una cualquiera de las reivindicaciones 1 a 3, en donde la obtención, por la entidad de función del plano de control, de información de cobro del flujo de datos antes de la migración que es contabilizada por la entidad de función del primer plano de usuario comprende:

obtener, por la entidad de función del plano de control después de detectar un evento de inicio de flujo de datos correspondiente al flujo de datos notificado por la entidad de función del segundo plano de usuario, la información de cobro del flujo de datos antes de la migración que es contabilizada por la entidad de función del primer plano de usuario.

7. El método según la reivindicación 1, en donde el procedimiento comprende además:

cobrar, por la entidad de función del plano de control, el flujo de datos en la entidad de función del primer plano de usuario usando una primera sesión de cobro entre la entidad de función del plano de control y el sistema de cobro;

determinar, por la entidad de función del plano de control, que existe otro flujo de datos que usa una clave de cobro que corresponde al flujo de datos en la entidad de función del primer plano de usuario después de que el flujo de datos se migre de la entidad de función del primer plano de usuario a la entidad de función del segundo plano de usuario;

cobrar, por la entidad de función del plano de control, el flujo de datos en la entidad de función del segundo plano de usuario usando la primera sesión de cobro; y

obtener, por la entidad de función del plano de control, la información de cobro del flujo de datos tanto de la entidad de función del primer plano de usuario como de la entidad de función del segundo plano de usuario.

8. El método según una cualquiera de las reivindicaciones 1-6, en donde el método comprende además:

iniciar (502), por la entidad de función del plano de control, la liberación de la primera sesión de datos en la entidad de función del primer plano de usuario;

establecer (502), por la entidad de función del plano de control, la segunda sesión de datos entre el UE y la entidad de función del segundo plano de usuario.

9. El método según una cualquiera de las reivindicaciones 1-8, en donde la primera sesión de datos y la segunda sesión de datos corresponden a una misma sesión de unidad de datos de protocolo.

10. El método según la reivindicación 9, que comprende además:

eliminar, por la entidad de función del plano de control, la primera sesión de datos después de que todo el flujo de datos transmitido en la primera sesión de datos se migre a la función del segundo plano de usuario.

11. El método según la reivindicación 9, en donde la primera conexión de datos entre el UE y la función del primer plano de usuario no se elimina, la segunda sesión de datos entre el UE y la función del segundo plano de usuario se usa para transportar una parte del volumen de servicio.

12. Un dispositivo de cobro, que comprende un módulo (1202) de determinación, un módulo (1206) de obtención, un módulo (1208) de procesamiento y un módulo (1204) de sesión, en donde

el módulo (1202) de determinación está configurado para determinar que un flujo de datos que es transmitido por el equipo de usuario UE en una primera sesión de datos necesita migrarse a una segunda sesión de datos, en donde la primera sesión de datos es una sesión de datos entre el UE y una entidad de función del plano de usuario de la entidad de función del primer plano de usuario, la segunda sesión de datos es una sesión de datos entre el UE y una entidad de función del segundo plano de usuario, la entidad de función del primer plano de usuario y la entidad de función del segundo plano de usuario son seleccionadas por una entidad de función del plano de control; en donde el dispositivo de cobro se caracteriza por:

el módulo (1206) de obtención está configurado para obtener información de cobro del flujo de datos antes de la migración, en donde la información de cobro que es contabilizada por la entidad de función del primer plano de usuario y es notificada a la entidad de función del plano de control por la entidad funcional del primer plano de usuario, la información de cobro comprende información de uso; y

el módulo (1208) de procesamiento está configurado para: determinar, en función de la información de cobro, que fue contabilizada por la entidad de función del primer plano de usuario, del flujo de datos y además en función de una primera cuota, una cuota disponible restante de la primera cuota, y entregar una segunda cuota a entregar a la entidad de función del segundo plano a la entidad de función del segundo plano de usuario en función de la cuota disponible restante;

en donde módulo (1208) de procesamiento está configurado además para: almacenar en caché la información de cobro notificada por la entidad de función del primer plano de usuario, generar, en función de la información de uso notificada por la entidad de función del primer plano de usuario y la información de uso notificada por la entidad de función del segundo plano de usuario, información a notificar al sistema de cobro;

el módulo de sesión está configurado para: notificar la información generada al sistema de cobro.

13. El dispositivo de cobro según la reivindicación 12, en donde el módulo (1206) de obtención está configurado para recibir la información de cobro que notifica la entidad de función del primer plano de usuario a través de la activación de la interrupción de la primera sesión de datos.

14. El dispositivo de cobro según la reivindicación 12, en donde el módulo (1206) de obtención está configurado para: después de que se detecta un evento de inicio de flujo de datos correspondiente al flujo de datos que notifica la entidad de función del segundo plano de usuario, obtener la información de cobro del flujo de datos antes de la migración que contabiliza el primer UP.

15. El dispositivo de cobro según una cualquiera de las reivindicaciones 12-14, en donde el módulo (1208) de procesamiento genera, en función de la información de uso notificada por la entidad de función del primer plano de usuario y la información de uso notificada por la entidad de función del segundo plano de usuario, la información a notificar al sistema de cobro comprende:

el módulo (1208) de procesamiento fusiona la información de uso notificada por la entidad de función del segundo plano de usuario y la información de uso almacenada en caché notificada por la entidad de función del primer plano de usuario, y notifica la información de uso fusionada al sistema de cobro.

16. El dispositivo de cobro según una cualquiera de las reivindicaciones 12-13, en donde el módulo (1206) de obtención obtiene información de cobro del flujo de datos antes de la migración que es contabilizada por la entidad de función del primer plano de usuario comprende:

recibir la información de cobro que es notificada por la entidad de función del primer plano de usuario a través de la activación de la interrupción de la primera sesión de datos.

17. El dispositivo de cobro según una cualquiera de las reivindicaciones 12-14, en donde el módulo de procesamiento está configurado además para realizar el método según una cualquiera de las reivindicaciones 3, 8-11.

18. Un dispositivo informático, que comprende un procesador (302), una memoria (304), un bus (308) y una interfaz (306) de comunicaciones, en donde la memoria (304) está configurada para almacenar una instrucción ejecutable del dispositivo informático, el procesador (302) está conectado a la memoria (304) a través del bus (308), y cuando el dispositivo informático opera, el procesador (302) ejecuta la instrucción ejecutable del dispositivo informático almacenada en la memoria (304), para que el dispositivo informático realice el método según una cualquiera de las reivindicaciones 1 a 11.

19. Un sistema de red, que comprende el dispositivo de cobro según una cualquiera de las reivindicaciones 10-15, una entidad de función del primer plano de usuario y una entidad de función del segundo plano de usuario,

en donde la entidad de función del primer plano de usuario está configurada para notificar información de cobro del flujo de datos antes de la migración al dispositivo de cobro,

la entidad de función del segundo plano de usuario está configurada para recibir una segunda cuota desde el dispositivo de cobro.

20. Un método de cobro, el método que comprende el método según una cualquiera de las reivindicaciones 1 11, en donde el método comprende además:

notificar, por la entidad de función del primer plano de usuario, información de cobro del flujo de datos antes de la migración al dispositivo de cobro;

recibir, por la entidad de función del segundo plano de usuario, la segunda cuota de la entidad de función del plano de control.

21. El método según la reivindicación 20, que comprende además:

recibir, por el sistema de cobro, información generada desde la entidad de función del plano de control.