ES2810866T3 - Gestión de calidad de servicio (QoS) en redes inalámbricas - Google Patents

Gestión de calidad de servicio (QoS) en redes inalámbricas Download PDF

Info

Publication number
ES2810866T3
ES2810866T3 ES17712890T ES17712890T ES2810866T3 ES 2810866 T3 ES2810866 T3 ES 2810866T3 ES 17712890 T ES17712890 T ES 17712890T ES 17712890 T ES17712890 T ES 17712890T ES 2810866 T3 ES2810866 T3 ES 2810866T3
Authority
ES
Spain
Prior art keywords
qos
qos policy
data
session
policy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17712890T
Other languages
English (en)
Inventor
Stefano Faccin
Gavin Bernard Horn
Soo Bum Lee
Haris Zisimopoulos
Lenaig Genevieve Chaponniere
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2810866T3 publication Critical patent/ES2810866T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un procedimiento de gestión de la calidad de servicio, QoS, en una red de datos, comprendiendo el procedimiento: recibir (2302) en un nodo de red de acceso, AN, en una AN (204, 504), desde una red central, CN, (206, 506) información de política de QoS, comprendiendo la información de política de QoS uno o más parámetros de QoS y uno o más descriptores de sesión de datos (310); obtener una política de QoS basándose en al menos una parte de la información de la política de QoS; almacenar una o más políticas de QoS y uno o más descriptores de sesión de datos (310) en un mapa de QoS que vincula la una o más políticas de QoS con el uno o más descriptores respectivos; y aplicar (2316) la política de QoS a un flujo entre la CN (206, 506) y un equipo de usuario, UE, (202, 502) cuando un descriptor en un paquete en el flujo corresponde a la política de QoS; en el que la obtención de la política de QoS comprende: seleccionar, del mapa de QoS, la política de QoS que está vinculada al descriptor en el paquete; y seleccionar recursos de AN para el flujo basándose en la política de QoS.

Description

DESCRIPCIÓN
Gestión de calidad de servicio (QoS) en redes inalámbricas
CAMPO TÉCNICO
[0001] La tecnología que se discute a continuación se refiere, en general, a sistemas de comunicación inalámbrica, y más particularmente, a mecanismos para la gestión de la calidad de servicio (QoS) en redes de comunicación inalámbrica. Ciertos modos de realización pueden habilitar y proporcionar técnicas flexibles para gestionar rasgos característicos de la QoS que ayudan a la conexión de red a través de comunicación rápida, control de latencia, control de autorización y baja sobrecarga de la red.
INTRODUCCIÓN
[0002] En una red de comunicación inalámbrica, se puede proporcionar una calidad de servicio (QoS) a los usuarios de la red, como se describe, por ejemplo, en los documentos US 2014/341017 A1, US 2006 (045128 A1, WO 2006/020105 A1 y NTT DOCOMO: "Flexibility of QoS parameter setting in eNB [Flexibilidad de configuración de parámetros de QoS en eNB]". Un mecanismo de QoS controla, en general, los parámetros de la red inalámbrica, como su rendimiento, confiabilidad y facilidad de uso. Estos parámetros pueden determinarse de acuerdo con ciertas métricas, como la cobertura y la accesibilidad de la red, y su calidad de llamada (especialmente la calidad de audio y vídeo).
[0003] La autorización de flujos de datos y el establecimiento de un mecanismo de QoS adecuado pueden introducir una cierta cantidad de latencia dentro de una red inalámbrica. A medida que la demanda de acceso móvil de banda ancha continúa incrementándose, la investigación y el desarrollo continúan evolucionando las tecnologías de comunicación inalámbrica, no solo para satisfacer la demanda creciente de acceso móvil de banda ancha, sino también para evolucionar y potenciar la experiencia del usuario con las comunicaciones móviles, incluyendo el control de latencia que ayuda a las reducciones de latencia para varios aspectos del sistema.
BREVE EXPLICACIÓN DE ALGUNOS EJEMPLOS
[0004] El objetivo de la presente invención se logra mediante los rasgos característicos de las reivindicaciones independientes adjuntas.
[0005] A continuación se ofrece una explicación simplificada de uno o más aspectos de la presente divulgación, para proporcionar un entendimiento básico de dichos aspectos. Esta explicación no es una visión general extensiva de todos los rasgos característicos contemplados de la divulgación y no pretende identificar elementos clave o críticos de todos los aspectos de la divulgación ni delimitar el alcance de algunos, o todos, los aspectos de la divulgación. Su único propósito es presentar algunos conceptos de uno o más aspectos de la divulgación de manera simplificada como preludio de la descripción más detallada que se presenta posteriormente.
[0006] Varios aspectos de la presente divulgación prevén el establecimiento y distribución de una política de calidad de servicio (QoS) en un sistema de comunicación inalámbrica. Se puede implementar una política de QoS con respecto a las sesiones de red de datos (DN) así como a las sesiones de datos. Para cada sesión de DN o sesión de datos, se puede aplicar una política de QoS por petición explícita o implícita, y las sesiones de datos pueden, en algunos ejemplos, utilizar políticas de QoS autorizadas previamente sin la necesidad de solicitar una QoS.
[0007] En un ejemplo, se divulga un procedimiento de gestión de la calidad de servicio (QoS) en una red de datos. El procedimiento incluye recibir en un nodo de red de acceso (AN) en una AN, desde una red central (CN), información de la política de QoS, comprendiendo la información de la política de QoS uno o más parámetros de QoS. El procedimiento incluye, además, determinar una política de QoS basada en al menos una parte de la información de la política de QoS. El procedimiento incluye, además, aplicar la política de QoS a un flujo entre la CN y un equipo de usuario (UE) cuando un descriptor en un paquete en el flujo corresponde a la política de QoS.
[0008] En otro ejemplo más, se divulga un nodo de AN dentro de una AN, configurado para gestionar la QoS en una red de datos. El nodo de AN incluye un procesador, una memoria acoplada comunicativa mente al procesador, un transceptor acoplado comunicativamente al procesador y configurado para la comunicación inalámbrica con un UE, y una interfaz de CN acoplada comunicativamente al procesador y configurada para la comunicación con una CN. El procesador y la memoria están configurados para recibir, desde la CN, información de la política de QoS, comprendiendo la información de la política de QoS uno o más parámetros de QoS; determinar una política de QoS basándose en al menos una parte de la información de la política de QoS; y aplicar la política de QoS a un flujo entre la CN y el UE cuando un descriptor en un paquete en el flujo corresponde a la política de QoS.
[0009] En otro ejemplo más, se divulga un nodo de AN dentro de una AN y configurado para gestionar la QoS en una red de datos. El nodo de AN incluye medios para recibir, desde una CN, información de la política de QoS, comprendiendo la información de la política de QoS uno o más parámetros de QoS; medios para determinar una política de QoS basándose en al menos una parte de la información de la política de QoS; y medios para aplicar la política de QoS a un flujo entre la CN y un UE cuando un descriptor en un paquete en el flujo corresponde a la política de QoS.
[0010] En otro ejemplo más, se divulga un medio legible por ordenador que almacena código ejecutable por ordenador. El código ejecutable por ordenador incluye instrucciones para hacer que un nodo de AN dentro de una AN reciba, desde una CN, información de la política de QoS, comprendiendo la información de la política de QoS uno o más parámetros de QoS; determine una política de QoS basándose en al menos una parte de la información de la política de QoS; y aplique la política de QoS a un flujo entre la CN y un UE cuando un descriptor en un paquete en el flujo corresponde a la política de QoS.
[0011] Estos y otros aspectos de la invención se entenderán más completamente tras una revisión de la descripción detallada, que sigue. Otros aspectos, rasgos característicos y modos de realización de la presente invención resultarán evidentes para los expertos en la técnica, después de revisar la siguiente descripción de modos de realización específicos, a modo de ejemplo, de la presente invención junto con las figuras adjuntas. Si bien los rasgos característicos de la presente invención se pueden analizar con respecto a determinados modos de realización y figuras a continuación, todos los modos de realización de la presente invención pueden incluir uno o más de los rasgos característicos ventajosos analizados en el presente documento. En otras palabras, si bien se pueden analizar uno o más modos de realización como que tienen determinados rasgos característicos ventajosos, también se pueden usar uno o más de dichos rasgos característicos de acuerdo con los diversos modos de realización de la invención analizados en el presente documento. De manera similar, si bien los modos de realización a modo de ejemplo se pueden analizar a continuación como los modos de realización del dispositivo, sistema o procedimiento, se debe entender que dichos modos de realización a modo de ejemplo se pueden implementar en diversos dispositivos, sistemas y procedimientos.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0012]
La FIG. 1 es un diagrama conceptual que ilustra un ejemplo de una red de acceso.
La FIG. 2 es un diagrama de bloques que ilustra ciertos aspectos de una arquitectura para una red de comunicación inalámbrica de próxima generación (por ejemplo, quinta generación o 5G).
La FIG. 3 es una ilustración esquemática de una estructura de paquetes en una sesión de datos.
La FIG. 4 es un diagrama de bloques que ilustra un ejemplo de comunicación que utiliza la arquitectura descrita anteriormente e ilustrada en la FIG. 2.
La FIG. 5 es un diagrama de bloques que ilustra ciertos aspectos de un modelo de calidad de servicio (QoS), tal como se puede implementar en una red de próxima generación (por ejemplo, 5G) utilizando la arquitectura descrita anteriormente e ilustrada en las FIG. 2 y 3.
La FIG. 6 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una sesión de red de datos (DN) y, al mismo tiempo, establecer una sesión de datos o una sesión de unidad de datos de protocolo (PDU).
La FIG. 7 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una sesión de datos o sesión de PDU posterior al establecimiento de una sesión de DN.
La FIG. 8 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para que una red central (CN) establezca una política de calidad de servicio (QoS) que responda o sea activada por una solicitud de un servidor de aplicaciones externo (AS) o función de aplicación (AF).
La FIG. 9 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS que responde o es activada por la detección de un flujo de datos no clasificado desde un equipo de usuario (UE).
La FIG. 10 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS que responde o es activada por una solicitud de UE explícita para la política de QoS.
La FIG. 11 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS que responde o es activada por una solicitud de UE explícita para la política de QoS.
La FIG. 12 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS con respecto a una sesión de DN en el momento del establecimiento de la sesión de DN, sin el establecimiento de la sesión de datos.
La FIG. 13 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS autorizadas previamente en el momento del establecimiento de una sesión de DN, antes de que se haya establecido una sesión de datos.
La FIG. 14 es un diagrama de flujo de llamada que ilustra otro proceso a modo de ejemplo para el establecimiento de políticas de QoS autorizadas previamente en el momento del establecimiento de una sesión de DN, antes de que se haya establecido una sesión de datos.
Las FIG. 15-17 son diagramas de flujo de llamada que ilustran procesos a modo de ejemplo para manejar el rechazo de una red de acceso (AN) a una política de QoS.
La FIG. 18 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS y el establecimiento de tokens de enlace ascendente/enlace descendente (UL/DL) utilizando señalización de plano de control.
La FIG. 19 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS y el establecimiento de tokens de UL/DL implícitos utilizando señalización de plano de usuario.
La FIG. 20 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS y el establecimiento de tokens de UL/DL explícitos que utiliza señalización de plano de usuario.
La FIG. 21 es un diagrama de bloques que ilustra un ejemplo de una implementación de hardware para un UE que emplea un sistema de procesamiento.
La FIG. 22 es un diagrama de bloques que ilustra un ejemplo de una implementación de hardware para un nodo de red de acceso que emplea un sistema de procesamiento.
La FIG. 23 es un diagrama de flujo que ilustra un proceso a modo de ejemplo para la gestión de QoS operable en un nodo de red de acceso.
La FIG. 24 es un diagrama de flujo que ilustra un proceso a modo de ejemplo para la gestión de QoS operable en un UE.
DESCRIPCIÓN DETALLADA
[0013] La descripción detallada expuesta a continuación, en relación con los dibujos adjuntos, pretende ser una descripción de diversas configuraciones y no pretende representar las únicas configuraciones en las que se pueden llevar a la práctica los conceptos descritos en el presente documento. La descripción detallada incluye detalles específicos con el propósito de proporcionar un entendimiento exhaustivo de diversos conceptos. Sin embargo, resultará evidente a los expertos en la técnica que estos conceptos se pueden llevar a la práctica sin estos detalles específicos. En algunos casos, se muestran estructuras y componentes bien conocidos en forma de diagrama de bloques para no complicar dichos conceptos.
[0014] Los diversos conceptos presentados a lo largo de la presente divulgación se pueden implementar a través de una amplia variedad de sistemas de comunicación, arquitecturas de red y estándares de comunicación. Se pueden implementar modos de realización específicos en cualquier red de acceso adecuada, ya sea por cable o inalámbrica. Con referencia ahora a la FIG. 1, como un ejemplo ilustrativo sin limitación, se proporciona una ilustración esquemática de una red de acceso por radio inalámbrica 100.
[0015] La región geográfica cubierta por la red de acceso 100 puede dividirse en varias regiones celulares (células). Esto puede incluir, por ejemplo, las macrocélulas 102, 104 y 106, y una célula pequeña 108, cada una de las cuales puede incluir uno o más sectores. Las células pueden definirse geográficamente (por ejemplo, por área de cobertura) y/o pueden definirse de acuerdo con una frecuencia, código de codificación, etc. En una célula que se divide en sectores, los múltiples sectores dentro de una célula pueden estar formados por grupos de antenas siendo cada antena responsable de la comunicación con dispositivos móviles en una parte de la célula.
[0016] En general, un aparato transceptor de radio sirve a cada célula. Un aparato transceptor de radio se denomina normalmente estación base (BS) en muchos sistemas de comunicación inalámbrica, pero también puede ser denominado por los expertos en la técnica como estación base transceptora (BTS), estación base de radio, transceptor de radio, función transceptora, conjunto de servicios básicos (BSS), conjunto de servicios extendidos (ESS), punto de acceso (AP), un nodo B, un eNodo B o con alguna otra terminología adecuada.
[0017] En la FIG. 1, se muestran dos estaciones base de alta potencia 110 y 112 en las células 102 y 104; y se muestra una tercera estación base de alta potencia 114 que controla una cabeza de radio remota (RRH) 116 en la célula 106. En este ejemplo, las células 102, 104 y 106 se pueden denominar macrocélulas, ya que las estaciones base de alta potencia 110, 112 y 114 admiten células que tienen un tamaño grande. Además, se muestra una estación base de baja potencia 118 en la célula pequeña 108 (por ejemplo, una microcélula, picocélula, femtocélula, estación base doméstica, Nodo B doméstico, eNodo B doméstico, etc.) que se puede superponer con una o más macrocélulas. En este ejemplo, la célula 108 se puede denominar una célula pequeña, ya que la estación base de baja potencia 118 admite una célula que tiene un tamaño relativamente pequeño. El dimensionamiento de las células se puede realizar de acuerdo con el diseño del sistema, así como con las limitaciones de los componentes. Se debe entender que la red de acceso 100 puede incluir cualquier número de estaciones base inalámbricas y células. Las estaciones base 110, 112, 114, 118 proporcionan puntos de acceso inalámbrico a una red central para cualquier número de aparatos móviles.
[0018] La FIG. 1 incluye, además, un cuadricóptero o dron 120, que se puede configurar para funcionar como una estación base. Es decir, en algunos ejemplos, una célula puede no ser necesariamente estacionaria, y el área geográfica de la célula puede desplazarse de acuerdo con la ubicación de la estación base móvil, tal como el cuadricóptero 120.
[0019] En algunos ejemplos, las estaciones base pueden estar interconectadas entre sí y/o con una o más estaciones base o nodos de red (no se muestran) en la red de acceso 100 a través de diversos tipos de interfaces de retorno, tales como una conexión física directa, una red virtual o similar utilizando cualquier red de transporte adecuada.
[0020] La red de acceso 100 se ilustra admitiendo comunicación inalámbrica para múltiples aparatos móviles. Un aparato móvil se denomina comúnmente equipo de usuario (UE) en los estándares y especificaciones promulgados por el Proyecto de Colaboración de Tercera Generación (3GPP), pero los expertos en la técnica lo pueden denominar también estación móvil (MS), estación de abonado, unidad móvil, unidad de abonado, unidad inalámbrica, unidad remota, dispositivo móvil, dispositivo inalámbrico, dispositivo de comunicación inalámbrica, dispositivo remoto, estación de abonado móvil, terminal de acceso (AT), terminal móvil, terminal inalámbrico, terminal remoto, móvil, terminal, agente de usuario, cliente móvil, cliente o con alguna otra terminología adecuada.
[0021] En el presente documento, un aparato "móvil" no necesariamente tiene que tener la capacidad de desplazarse, y puede ser estacionario. Algunos ejemplos no limitativos de un aparato móvil incluyen un teléfono móvil, un teléfono celular (móvil), un teléfono inteligente, un teléfono con protocolo de inicio de sesión (SIP), un ordenador portátil, un ordenador personal (PC), un notebook, un netbook, un libro inteligente, una tableta y un asistente digital personal (PDA). Un aparato móvil también puede ser un dispositivo de "Internet de las cosas" (IoT) como un automóvil u otro vehículo de transporte, una radio satelital, un dispositivo de sistema de posicionamiento global (GPS), un controlador de logística, un dron, un multicóptero, un cuadricóptero, un dispositivo inteligente de energía o seguridad, un panel solar o conjunto solar, iluminación municipal, agua u otra infraestructura; automatización industrial y dispositivos empresariales; dispositivos de consumo y ponibles, como gafas, una cámara ponible, un reloj inteligente, un rastreador de salud o estado físico, un dispositivo implantable en mamíferos, un dispositivo médico, un reproductor de audio digital (por ejemplo, reproductor de MP3), una cámara, una consola de juegos, etc.; y dispositivos digitales domésticos o inteligentes para el hogar, como dispositivos de audio, vídeo y multimedia para el hogar, un electrodoméstico, un sensor, una máquina expendedora, iluminación inteligente, un sistema de seguridad para el hogar, un medidor inteligente, etc.
[0022] En la red de acceso 100, las células pueden incluir UE que pueden estar en comunicación con uno o más sectores de cada célula. Por ejemplo, los UE 122 y 124 pueden estar en comunicación con la estación base 110; los UE 126 y 128 pueden estar en comunicación con la estación base 112; los UE 130 y 132 pueden estar en comunicación con la estación base 114 por medio de la RRH 116; el UE 134 puede estar en comunicación con la estación base de baja potencia 118; y el UE 136 puede estar en comunicación con la estación base móvil 120. Aquí, cada estación base 110, 112, 114, 118 y 120 se puede configurar para proporcionar un punto de acceso a una red central (no mostrada) para todos los UE en las células correspondientes.
[0023] En otro ejemplo, el cuadricóptero 120 se puede configurar para funcionar como un UE. Por ejemplo, el cuadricóptero 120 puede funcionar dentro de la célula 102 comunicándose con la estación base 110.
[0024] La interfaz aérea en la red de acceso 100 puede utilizar uno o más algoritmos de multiplexación y de acceso múltiple para permitir la comunicación simultánea de los diversos dispositivos. Por ejemplo, se puede proporcionar acceso múltiple para transmisiones de enlace ascendente (UL) o enlace inverso desde los UE 122 y 124 a la estación base 110 utilizando Acceso Múltiple por División del Tiempo (TDMA), Acceso Múltiple por División de Código (CDMA), Acceso Múltiple por División de Frecuencia (FDMA), Acceso Múltiple por División Ortogonal de Frecuencia (OFDMA), Acceso Múltiple con Códigos Dispersos (SCMA) u otros esquemas adecuados de acceso múltiple. Además, el multiplexado de las transmisiones de enlace descendente (DL) o enlace directo desde la estación base 110 a los UE 122 y 124 se puede proporcionar utilizando Multiplexado por División del Tiempo (TDM), Multiplexado por División de Código (CDM), Multiplexado por División de Frecuencia (FDM), Multiplexado por División Ortogonal de Frecuencia (OFDM), Multiplexado por Códigos Dispersos (SCM) u otros esquemas de multiplexación adecuados.
[0025] En una red de acceso 100, durante una llamada con una entidad de planificación, o en cualquier otro momento, un UE puede supervisar diversos parámetros de una señal de su célula de servicio, así como diversos parámetros de células vecinas. Además, dependiendo de la calidad de estos parámetros, el UE puede mantener la comunicación con una o más de las células vecinas. Durante este tiempo, si el UE se mueve de una célula a otra, o si la calidad de la señal de una célula vecina excede la de la célula de servicio durante un período de tiempo dado, el UE puede realizar una transferencia o traspaso desde la célula de servicio a la célula vecina (de destino). Por ejemplo, el UE 124 puede desplazarse desde el área geográfica correspondiente a su célula de servicio 102 al área geográfica correspondiente a la célula vecina 106. Si la intensidad o calidad de la señal de la célula vecina 106 excede la de su célula de servicio 102 durante un período de tiempo determinado, el UE 124 puede transmitir un mensaje de notificación a su estación base de servicio 110 indicando esta condición. En respuesta, el UE 124 puede recibir un comando de traspaso, y el UE puede experimentar un traspaso a la célula 106.
Arquitectura de referencia
[0026] La FIG. 2 es un diagrama de bloques que ilustra ciertos aspectos de una arquitectura para una red central (CN) en una red de comunicación inalámbrica de próxima generación (por ejemplo, quinta generación o 5G). Las características pueden incluir un UE 202 en comunicación con una red central 206 por medio de una red de acceso 204. En esta ilustración, así como en las FIG. 3 y 4, se supone que cualquier ruta de señal entre un UE y una CN debe pasar entre estas entidades mediante una red de acceso, como se representa mediante una ruta de señal ilustrada que atraviesa la red de acceso. Aquí, la red de acceso 204 puede ser la red de acceso 100 descrita anteriormente e ilustrada en la FIG. 1. En otro ejemplo, la red de acceso 204 puede corresponder a una red LTE (eUTRAN), una red de acceso por cable, una combinación de las anteriores, o cualquier otra red o redes de acceso adecuadas. En la descripción que sigue, cuando se hace referencia a la red de acceso (AN) o a acciones realizadas por la AN, se puede entender que dicha referencia se refiere a uno o más nodos de red en la AN que está o están conectados de forma comunicativa con la CN, por ejemplo, por medio de una conexión de retorno. Como un ejemplo no limitativo, por claridad de la descripción, dicha referencia a la AN se puede entender como una referencia a una estación base. Sin embargo, los expertos en la técnica comprenderán que este no siempre es el caso, por ejemplo, como en determinadas RAN 3G donde las estaciones base están bajo el control o dirección de controladores de red de radio centralizados dentro de su AN.
[0027] El UE 202 tiene funcionalidad de plano de usuario (UP) y de plano de control (CP) (y puede tener características de UE analizadas, en general, en el presente documento). En las FIG. 2-4, la señalización del CP se indica con líneas discontinuas, y la señalización del UP se indica con líneas continuas. La red de acceso (AN) 204 también incluye algunas funcionalidades del CP, ilustradas con el bloque 203 de CP en la AN 204, pero la mayoría de la funcionalidad del CP está en la CN 206. Específicamente, la CN 206 incluye una función de gestión de movilidad del plano de control (CP-MM) 208 y una función de gestión de sesión del plano de control (CP-SM) 210.
[0028] La CP-MM 208 establece y mantiene el contexto de gestión de movilidad para un dispositivo (por ejemplo, el UE 202) que se conecta a la CN 206 a través de una o más tecnologías de acceso. La CP-SM 210 establece, mantiene y finaliza sesiones de red de datos (DN) y sesiones de datos en la arquitectura del sistema de próxima generación, incluido el establecimiento de estas sesiones a demanda. La CP-SM 210 decide, además, la calidad del servicio (QoS) (es decir, realiza la conformación de QoS, que se analiza más adelante) para un UE, para una sesión de DN y/o una sesión de datos.
[0029] Un bloque de función de política (PF)/servidor de autentificación, autorización y contabilización (AAA) 212 actúa como un repositorio de perfiles y un servidor de autentificación. El bloque de función de política/AAA 212 puede almacenar un perfil de abonado y credenciales de abonado, y puede almacenar y tomar decisiones sobre políticas (por ejemplo, una política de QoS) para aplicar a un UE para una sesión de DN y/o una sesión de datos.
[0030] Una entidad de infraestructura de plano de usuario (UP) 214 representa cualquier infraestructura de comunicación adecuada en la CN 206 que entrega datos entre la AN 204, una pasarela de plano de usuario (UP-GW) 216 y una red de datos externa 218. La UP-GW 216 puede estar acoplada comunicativamente con la CP-SM 210 para configurar la conexión de UP a través de la CN 206. La red de datos externa puede ser cualquier red de datos adecuada, que incluye, entre otros, Internet, una red de subsistemas multimedia IP (IMS), etc.
[0031] En la presente divulgación, cuando se hace referencia a una red central o CN, se puede suponer que dicha referencia tiene la intención de significar cualquiera de los nodos dentro de la CN, a menos que se haga referencia específica a un nodo particular.
Sesiones de datos y sesiones de DN
[0032] Cuando el UE 202 establece conectividad con la CN 206, en general, se pueden establecer dos tipos diferentes de sesiones: una sesión de red de datos y una sesión de datos. En algunos ejemplos, una sesión de datos se puede denominar de manera equivalente una sesión de unidad de datos en paquetes (PDU).
[0033] Una sesión de red de datos (DN) es un contexto lógico, o un conjunto de información de contexto en varias entidades que proporciona un marco para la conectividad entre un punto final local en el UE 202 (por ejemplo, un navegador web) y un punto final remoto en la red de datos externa 218 (por ejemplo, una red IMS, Internet, redes dedicadas, un servidor web en un host remoto, etc.). La sesión de DN contiene información de estado relacionada con diversas entidades, como el UE, la AN, la CN, pasarelas, etc., y puede ser atendida por múltiples UP-GW en una o más CN. Una sesión de DN puede contener una o más sesiones de datos.
[0034] Una sesión de datos (también denominada sesión de unidad de datos de protocolo (PDU), flujo de datos o flujo) es un contexto lógico en un UE que permite la comunicación entre un punto final local en el UE (por ejemplo, un navegador web) y un punto final remoto en la red de datos externa 218 (por ejemplo, un servidor web en un host remoto). La FIG. 3 es una ilustración esquemática de un flujo 302 (por ejemplo, una sesión de datos) que incluye una serie de PDU. Una sesión de datos puede ser una sesión de protocolo de Internet (IP) o una sesión que no sea IP (por ejemplo, tráfico de Ethernet). Dentro de la presente divulgación, cualquier referencia a paquetes o PDU (unidades de datos de protocolo) son intercambiables y pretenden referirse a un paquete IP o una PDU no IP.
[0035] La sesión de datos puede considerarse un flujo de paquetes de datos, cada paquete de datos tiene un descriptor común y una correlación de cabecera específica, por ejemplo, una cabecera IP, cabecera de protocolo de transporte, etc. En la FIG. 3, se expande una sola PDU 304 para ilustrar que las PDU incluyen una cabecera 306 y una carga útil 308. La cabecera 306 se expande adicionalmente para ilustrar, conceptualmente, parte de la información que puede aparecer en dicha cabecera de paquete de acuerdo con algunos aspectos de la presente divulgación. Por supuesto, los expertos en la técnica comprenderán que el orden o la secuencia de la información, o su inclusión, puede variar de una implementación a otra.
[0036] Cuando una entidad en la CN necesita asociar cierta información (por ejemplo, información de QoS) con una sesión de datos específica, puede identificar la sesión de datos con un descriptor de sesión de datos 310. Aquí, un descriptor de sesión de datos o un descriptor de flujo de datos es el conjunto de información transportada en cada paquete (por ejemplo, en las cabeceras o en una etiqueta adjunta a las cabeceras), que puede ser identificada por la red sin requerir una inspección profunda de paquetes (DPI).
Ejemplo de comunicación a modo de ejemplo
[0037] La FIG. 4 es un diagrama de bloques que ilustra un ejemplo de comunicación que utiliza la arquitectura descrita anteriormente e ilustrada en la FIG. 2. En este ejemplo, un UE 202 puede tener múltiples sesiones de DN con la CN 206. Como se ve en la FIG. 4, el UE 202 a modo de ejemplo tiene dos sesiones de d N 402a y 402b con la CN 206. Como se describió anteriormente, cada sesión de DN puede corresponder a múltiples direcciones IP. Como se ve aquí, el UE 202 tiene dos sesiones de datos o sesiones de PDU dentro de cada sesión de DN ilustrada, y cada una de las sesiones de datos puede tener una dirección IP diferente.
[0038] En un aspecto de la divulgación, cada sesión de DN 402a, 402b puede resolverse a cualquier número adecuado de una o más UP-GW en una o más CN. En el ejemplo ilustrado, dentro de la primera sesión de DN 402a, dos sesiones de datos (que tienen direcciones IP etiquetadas como IP1 e IP2) son atendidas por la misma UP-GW: es decir, una primera UP-GW 216a. Sin embargo, dentro de la segunda sesión de DN 402b, dos UP-GW diferentes dan servicio a dos sesiones de datos (que tienen direcciones IP etiquetadas como IP3 e IP4): a saber, una segunda UPGW 216b y una tercera UP-GW 216c.
[0039] El contexto de gestión de sesión (por ejemplo, aprovechando las redes definidas por software (SDN) y el encaminamiento de señalización) para la primera sesión DN 402a y la segunda sesión DN 402b se proporciona en la CP-SM 210. El contexto del plano de usuario (por ejemplo, QoS, túneles, etc.) para la primera sesión de DN 402a puede proporcionarse en la primera UP-GW 216a, mientras que el contexto del plano de usuario para la segunda sesión de DN 402b puede proporcionarse tanto en la segunda UPGW 216b como en la tercera UP-GW 216c.
[0040] En una CN convencional, una aplicación se comunica con una red de datos en paquetes (PDN) como Internet o una red de subsistemas multimedia IP (IMS) haciendo referencia a un nombre de punto de acceso (APN). El APN puede funcionar como un nombre DNS, que se traduce a la dirección IP de una pasarela de red de datos en paquetes (PDN) (P-GW). En consecuencia, una aplicación está vinculada al APN, que determina la P-GW a través de la cual se realiza una conexión PDN. Sin embargo, en un aspecto de la divulgación, las aplicaciones pueden estar vinculadas no a un nombre de punto de acceso (APN), sino que, en cambio, pueden estar vinculadas a una sesión de datos específica. Es decir, para cada conexión, puede haber una ruta de datos o una sesión de datos establecida en la CN 206. Por ejemplo, una sesión de datos puede ser un túnel de protocolo de Internet (IP), encaminamiento configurado por red definida por software (SDN), etc.
Modelo de QoS: descripción general
[0041] La FIG. 5 es un diagrama de bloques que ilustra ciertos aspectos de un modelo de calidad de servicio (QoS) tal como puede implementarse mediante una red central de próxima generación (por ejemplo, 5G) que utiliza la arquitectura descrita anteriormente e ilustrada en las FIG. 2 y 4. En esta ilustración, solo se ilustran algunos de los nodos en la CN para mayor claridad. Se puede suponer que el UE 502, la AN 504, la CN 506 y la red de datos externa 518 son como se describió anteriormente en relación con las FIG. 2 y 4.
[0042] En una red de comunicación inalámbrica, se puede proporcionar una calidad de servicio (QoS) a los usuarios de la red. El mecanismo de QoS controla, en general, los parámetros de la red inalámbrica, como su rendimiento, confiabilidad y facilidad de uso. Estos parámetros pueden determinarse de acuerdo con ciertas métricas, como la cobertura y la accesibilidad de la red, y su calidad de llamada (especialmente la calidad de audio y vídeo). Específicamente, una política de QoS que puede implementarse de acuerdo con ciertos aspectos de la divulgación puede contener parámetros de QoS que incluyen, entre otros, una velocidad de transferencia de bits máxima para un UE, una velocidad de transferencia de bits máxima de enlace ascendente para una sesión de DN específica, una velocidad de transferencia de bits máxima de enlace descendente para una sesión de DN, una velocidad de transferencia de bits garantizada (GBR) para una sesión de datos/PDU, información de filtrado de paquetes, prioridad de portador, etc. En consecuencia, un nodo de AN puede aplicar una política de QoS a un flujo, una sesión de datos o una sesión de DN para controlar parámetros de un flujo, como una velocidad de transferencia de bits de enlace ascendente o descendente, una GBR, filtrado de paquetes (por ejemplo, determinar permitir o bloquear paquetes en función de su contenido), priorizar un flujo, etc.
[0043] Como se usa en el presente documento, el término red de acceso heredada, red central heredada o tecnología de acceso por radio heredada (RAT) puede referirse a una red o RAT que emplea una tecnología de comunicación inalámbrica de segunda generación (2G), tercera generación (3G) o cuarta generación (4G). Por ejemplo, una RAT 2G puede estar basada en un conjunto de estándares que cumplan con el Estándar provisional 95 (IS-95) o cdmaOne, el Sistema Global para Móviles (GSM), el Servicio General de Paquetes por Radio (GPRS) o las Velocidades de transferencia de Datos Mejoradas para Evolución del GSM (EDGE). Una RAT 3G puede ser una basada en un conjunto de estándares que cumplan con las especificaciones de Telecomunicaciones Móviles Internacionales-2000 (IMT-2000), incluyendo, entre otras, ciertos estándares promulgados por el Proyecto de Colaboración de 3a Generación (3GPP) y el Proyecto de Colaboración de 3a Generación 2 (3GPP2). Una RAT 4G puede ser una basada en un conjunto de estándares que cumplan con las especificaciones de Telecomunicaciones Móviles Internacionales Avanzadas (ITU-Advanced), que incluyen, entre otras, ciertos estándares promulgados por 3GPP.
[0044] Algunos ejemplos de estándares 3G definidos por 3GPP incluyen el Sistema Universal de Telecomunicaciones Móviles (UMTS), el Acceso Universal por Radio Terrestre (UTRA), el Acceso a Paquetes de Alta Velocidad (HSPA) y HSPA+. Algunos ejemplos de estándares 3G definidos por 3GPP2 incluyen CDMA2000 y Evolución de datos optimizados (EV-DO). Algunos ejemplos de estándares 4G definidos por 3GPP incluyen el acceso por radio terrestre universal evolucionado (eUTRA), la evolución a largo plazo (LTE), LTE Avanzada y el sistema de paquetes evolucionado (EPS). Otros ejemplos de estándares que emplean tecnología de comunicación inalámbrica 3G/4G incluyen el estándar iEe E 802.16 (WiMAX) y otros estándares adecuados.
[0045] Como se usa adicionalmente en el presente documento, el término red de acceso de próxima generación, red central de próxima generación o RAT de próxima generación se refiere, en general, a una red o RAT que emplea tecnologías de comunicación inalámbrica en continua evolución. Esto puede incluir, por ejemplo, una tecnología de comunicación inalámbrica de quinta generación (5G) basada en un conjunto de estándares. Los estándares pueden cumplir con directrices establecidas en el libro blanco de 5G publicado por la Alianza de Redes Móviles de Próxima Generación (Next Generation Mobile Networks, NGMN) el 17 de febrero de 2015. Por ejemplo, los estándares que puede definir el 3GPP después de LTE Avanzada o el 3GPP2 después de CDMA2000 pueden cumplir el libro blanco de 5G de la Alianza de NGMN. Los estándares también pueden incluir esfuerzos previos a 3GPP especificados por el Foro Técnico de Verizon (www.vztgf) y Korea Telecom SIG (www.kt5g.org).
[0046] En redes heredadas, anteriores o existentes (por ejemplo, 3G y 4G), la QoS es compatible con túneles específicos. En particular, con referencia a un sistema de paquetes evolucionado 4G (EPS), se pueden establecer uno o más portadores EPS para una conexión PDN, donde un portador EPS se considera un túnel entre el UE y una P-GW. Puede haber uno de esos túneles para cada nivel de QoS, para cada UE. Es decir, la QoS puede aplicarse en función de este túnel, que se identifica mediante una ID de portador. Desde la perspectiva del UE, se establece un túnel entre dos entidades del plano de usuario de la CN (por ejemplo, una UP-GW y una AN) para cada nivel de QoS para cada dirección IP. Es decir, los paquetes transportados en la red pueden tratarse, desde un punto de vista de QoS, en un túnel particular, mientras que los paquetes que requieren un tratamiento diferente pueden colocarse en túneles diferentes y separados. Por otro lado, en una red de próxima generación (por ejemplo, 5G), la CN puede utilizar un modelo de QoS sin portador. En tal modelo de QoS sin portador, los túneles separados pueden no existir necesariamente específicamente para el propósito de la diferenciación de QoS. Una red de próxima generación (por ejemplo, 5G) puede en algunos ejemplos utilizar un túnel para cada flujo de datos, para cada UE. En otros ejemplos, la red 5G puede usar un túnel para cada sesión de DN para cada UE. Aquí, el túnel puede ser independiente de la QoS de los flujos de datos correspondientes a la sesión de DN. En otros ejemplos más, la red 5G puede usar un túnel para cada sesión de DN, para cada UE, para cada punto de anclaje (es decir, una PDN GW o UP-GW, dependiendo de la naturaleza de la red). Es decir, a diferencia de una red heredada, aquí, una única sesión de DN puede estar anclada en múltiples pasarelas. Tenga en cuenta que una CN 506 puede usar túneles para encaminar los paquetes y para propósitos de continuidad de sesión/IP. Sin embargo, en un aspecto de la presente divulgación, la QoS puede ser ortogonal e independiente de cualquier mecanismo de encaminamiento que adopte la CN 506.
[0047] De acuerdo con un aspecto de la divulgación, la CN 506 (por ejemplo, la CP-SM 510, el bloque AAA/PF 512 u otro nodo de CN adecuado que tenga una funcionalidad similar) puede ser la entidad que toma decisiones sobre la QoS. Esto puede incluir las decisiones de aprovisionamiento, configuración o ajuste de la CN 506 sobre qué QoS asignar a los datos de tráfico en función del perfil de suscripción, políticas, requisitos de servicio, etc. Esto puede denominarse conformación de QoS en algunos escenarios. Aquí, la información de la política de QoS obtenida puede distribuirse usando señalización de plano de control fuera de banda desde la CN 506 a una AN 504, un UE 502, y a una o más UP-GW 516. Esto se distingue de la identificación y autorización de tráfico, que en general se realiza dentro de banda.
Etiquetado de flujo
[0048] En virtud de este modelo de QoS, se puede evitar la inspección profunda de paquetes (DPI) para cada paquete individual. Para determinar los servicios o aplicaciones a los que corresponde un paquete de datos, las redes heredadas realizan, en general, DPI para analizar un paquete. Sin embargo, aquí, debido a que la CN 506 instala y distribuye la política de QoS, las diversas entidades en la red pueden analizar cada paquete sin realizar DPI, sino más bien, haciendo coincidir los paquetes con su descriptor como se describió anteriormente.
[0049] La AN 504 puede no tener conocimiento relacionado con la aplicación del modelo de QoS. Específicamente, la información de QoS se puede distribuir a las diversas AN a través de un mecanismo de acceso independiente. Si bien la información de QoS puede contener parámetros específicos para las diversas tecnologías de acceso, cada AN puede usar solo los parámetros relevantes para esa AN (es decir, la AN puede identificar los parámetros dentro de la política de QoS que se aplican a esa AN específica).
[0050] La CN 506 puede implementar QoS utilizando el etiquetado de flujo para etiquetar cada sesión o flujo de datos. Es decir, la CN 506 puede etiquetar toda la información relacionada con la QoS en los paquetes, y la CN 506 puede detectar un descriptor de sesión de datos 310 dentro de un paquete para determinar cómo tratar ese paquete desde un punto de vista de QoS. La CN 506 puede aplicar la etiqueta a los paquetes de enlace descendente (DL) destinados al UE 502, y el UE 502 puede aplicar la etiqueta a los paquetes de enlace ascendente (UL) destinados a la CN 506. Con referencia a la FIG. 3, se ilustra una etiqueta de flujo de QoS 312 a modo de ejemplo como parte de la cabecera de paquete 306.
[0051] En general, la AN 504 correlaciona las etiquetas de flujo (es decir, cualquier etiqueta que se aplique a un paquete) con parámetros o información (como una política de QoS) que la AN 504 recibe de la CN 506. En funcionamiento, la AN 504 recibe información de QoS de la CN 506 y recibe paquetes de datos del UE 502 o de la CN 506. Luego, la AN 504 hace coincidir el paquete (en función de su etiqueta de flujo o descriptor) con la información de QoS que recibe de la CN 506, y en función de esta información, determina cómo tratar los paquetes. Por ejemplo, en el caso de una red de acceso por radio (RAN), esto puede incluir determinar cómo correlacionar los paquetes con los portadores de radio apropiados.
Autorización de flujo
[0052] En general, puede haber dos etapas relacionadas con la QoS después de establecer una sesión o flujo de datos. Una es autorizar el flujo: es decir, verificar que el UE 502 está autorizado o se le permite transmitir los datos en ese flujo. Entonces, la política de QoS puede definirse para el flujo. La autorización de flujo puede, en algunos ejemplos, ser proporcionada explícitamente por la CN 506. Por ejemplo, cuando se crea una sesión de datos, la CN 506 puede decidir sobre la autorización del flujo y puede generar la política de QoS y luego distribuir esta política, como se describió anteriormente. Sin embargo, en otro ejemplo, la aplicación de una política de QoS a un flujo dentro de la AN 504 puede ser autorizada previamente por la CN 506 por UE para algunas sesiones de datos.
[0053] En general, la AN 504 puede estar al tanto de cierta información con respecto a los paquetes proporcionados por la CN 506. Es decir, la AN 504 es consciente del nivel de flujo. En consecuencia, la AN 504 puede hacer coincidir ciertos paquetes en un flujo dado con su descriptor, y puede aplicar políticas de QoS apropiadas. La AN 504 luego determina cómo manejar esos paquetes, por ejemplo, mediante la distribución de múltiples flujos de CN en diferentes portadores de radio de datos.
[0054] El conocimiento de la aplicación en la AN 504 puede ser por flujo y por abonado en ciertos escenarios. Basándose en, por ejemplo, características asistidas por UE, preferencias y/o información preconfigurada en la AN 504, etc., la AN 504 puede realizar un manejo inteligente de los datos del usuario. Por ejemplo, la AN 504 puede realizar la entrega de datos localmente en caché o las operaciones locales de interrupción y conmutación local por servicio, de acuerdo con la preferencia del servicio del usuario, la popularidad del servicio, etc. En general, puede no haber detección de aplicaciones o servicios en la AN 504, sino solo coincidencia de flujo. Es decir, la AN 504 puede suponer finalmente que la unión se define por flujo antes de que los paquetes entren en el protocolo de convergencia de datos en paquetes (PDCP), y la AN 504 puede definir qué significa un portador de radio y el tratamiento que recibe.
[0055] De esta manera, al proporcionar información de política de QoS a la AN 504, el manejo y etiquetado de flujos desde la CN 506 a la AN 504 puede ser independiente de la aplicación y puede ser independiente de la tecnología de acceso por radio (RAT) utilizada por la AN 504. Es decir, al correlacionar la AN 504 los paquetes con el portador de radio apropiado de acuerdo con la política de QoS, la CN 506 no necesita preocuparse por estos detalles de la AN 504.
[0056] Como se analizó en general anteriormente, la CN 506 puede entregar información de QoS a otras entidades, incluyendo la AN 504, la UP-GW 516 y el UE 502. Por lo tanto, en una interacción CN a AN, la CN 506 (por ejemplo, la CP-SM) puede entregar políticas de QoS a la AN 504 (por ejemplo, la entidad del plano de control en la AN). Estas políticas de QoS pueden incluir una correlación de paquetes de DL con una QoS de la AN; una correlación de una QoS de AN con paquetes de DL; filtrado de tráfico; etc. Estas políticas de QoS pueden describir adicionalmente el comportamiento basado en ciertos descriptores de sesión de datos.
[0057] En un aspecto de la presente divulgación, la información relacionada con la política de QoS proporcionada por la CN 506 a la AN 504 puede incluir una o más posibles políticas de QoS autorizadas previamente que se utilizarán para el establecimiento de futuras sesiones de datos. Estas políticas de QoS autorizadas previamente pueden ser autorizadas previamente independientemente de cualquier tráfico actual o en curso. Es decir, la CN 506 puede proporcionar a la AN 504 un conjunto de políticas de QoS para sesiones de datos que el UE 502 puede establecer posteriormente, sin requerir autorización explícita de la CN 506. Por ejemplo, supóngase que un UE 502 establece una sesión de DN (por ejemplo, la sesión de DN 302a en la FIG. 3), aunque cualquier sesión de datos o sesiones de PDU puede no establecerse necesariamente. Aquí, la CN 506 puede recibir un paquete del UE 502 antes del establecimiento de una sesión de datos. La CN 506 puede decidir, basándose, por ejemplo, en las políticas del perfil de suscripción de un usuario, o en base a un descriptor en el paquete recibido del UE 502, que ciertas sesiones de datos están autorizadas previamente, por lo que no hay necesidad de autorización adicional. En consecuencia, la AN 504 puede desplegar una sesión de datos en el futuro, correspondiente a la sesión de DN de acuerdo con la autorización previa.
[0058] Aun así, la AN 504 puede tener características adicionales establecidas por sesión. Por ejemplo, la CN 506 puede desencadenar el establecimiento de QoS en la AN 504. Dependiendo de la tecnología de la AN y el modelo QoS de la AN, esto puede resultar en el establecimiento de recursos dedicados (por ejemplo, portadores dedicados en una RAN) o modificación de la prioridad de recursos (mayor, menor u otras alternativas). Aún más, la CN 506 puede proporcionar información para los tokens de DL y UL a la AN 504.
[0059] Con respecto a la interacción CN a UP-GW (por ejemplo, entre la CP-SM y la UP-GW), la CN 506 puede entregar información de conformación de QoS a la UP-GW 516, y puede configurar cierto establecimiento de recursos en la UPGW 516, permitiendo que la UP-GW filtre paquetes y proporcione QoS. Además, la CN 506 puede proporcionar a la UP-GW 516 información para los tokens de DL y UL.
[0060] Con respecto a la interacción de CN con UE (por ejemplo, entre la CP-SM y el UE), la CN 506 puede proporcionar al UE 502 políticas explícitas por UE/abonado que son independientes de cualquier sesión de datos existente. Esta información de la CN 506 puede incluir adicionalmente información relacionada con las sesiones de datos autorizadas previamente descritas anteriormente. Además, la CN 506 puede proporcionar al UE 502 información actualizada de QoS correspondiente a una sesión de datos recién creada que involucra a la CP-SM 510. Esto puede incluir toda la información que el UE 502 requiere cuando comienza la sesión de datos, de modo que el UE 502 puede determinar cómo manejar los paquetes en esa sesión de datos. Aún más, la CN 506 puede proporcionar al UE 502 información relacionada con el marcado de paquetes de transmisiones de UL desde el UE 502. Por ejemplo, esto puede incluir información relacionada con un token de UL.
Compatibilidad
[0061] En algunas implementaciones, uno o más parámetros de QoS de redes heredadas (por ejemplo, redes 3G y/o 4G) aún pueden ser necesarios para permitir el interfuncionamiento con esas redes de acceso heredadas, como un traspaso hacia/desde dichas redes de acceso heredadas. La política de QoS divulgada en el presente documento puede incluir dichos parámetros de QoS heredada, que pueden ser distribuidos por la CN 506. Es decir, los parámetros de QoS dentro de una política de QoS pueden incluir uno o más parámetros de QoS correspondientes a una red diferente, que no sea la red que implementa la política de QoS. Sin embargo, estos parámetros de QoS heredada en general se usarán solo cuando el UE 502 esté conectado a dicha AN heredada.
Establecimiento de sesión de datos
[0062] Como se describió anteriormente, el establecimiento de una sesión de datos puede implicar la autorización del flujo y el establecimiento de políticas de QoS para el flujo. En un aspecto de la divulgación, la CN 506 puede realizar la conformación de QoS (incluida la autorización de tráfico), y la CN 506 puede enviar la información de política de QoS a la UP-GW 516, la AN 504 y el UE 502.
[0063] Las FIG. 6 y 7 son diagramas de flujo de llamada que ilustran ejemplos básicos de establecimiento de sesión de datos de acuerdo con algunos aspectos de la divulgación. En estas figuras, y en todos los diagramas de flujo de llamada que siguen, la comunicación entre los nodos ilustrados se ilustra mediante flechas entre líneas que se extienden desde los nodos respectivos, en secuencia, con el tiempo avanzando hacia abajo. Otros modos de realización pueden tener otras acciones de secuencia u órdenes de implementación variados según se desee.
[0064] La FIG. 6 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una sesión de DN y, al mismo tiempo, el establecimiento de una sesión de datos o sesión de PDU. En el ejemplo ilustrado, una política de QoS se establece simultáneamente en asociación con la sesión de DN y la sesión de datos.
[0065] Después de que se establece un contexto de gestor de movilidad (MM) entre el UE 502 y la AN 504, el UE 502 puede solicitar el establecimiento de una sesión de DN transmitiendo una solicitud de establecimiento de sesión de DN a la CN 506 (es decir, a la CP-SM 510). (En otro ejemplo, la CN puede ser capaz de desencadenar el establecimiento de una sesión de DN). El plano de control de la CN 506 define una política de QoS correspondiente a la solicitud de establecimiento de sesión de DN del UE 502, y proporciona la política de QoS a la AN 504 y a la UP-GW 516. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. La CN 506 luego transmite una respuesta de establecimiento de DN al UE 502 correspondiente a la política de QoS.
[0066] La FIG. 7 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una sesión de datos o sesión de PDU posterior al establecimiento de una sesión de DN. Aquí, se establece una política de QoS en asociación con la sesión de datos.
[0067] Después de que se establece un contexto de MM entre el UE 502 y la AN 504, se puede establecer una sesión de DN entre el UE 502 y la CN 506 (por ejemplo, utilizando el proceso descrito anteriormente e ilustrado en la FIG. 6). El establecimiento de la sesión de DN puede o no tener una política de QoS asociada, y puede incluir o no el establecimiento de una o más sesiones de datos. El UE 502 puede entonces transmitir una solicitud de establecimiento de sesión de datos o de sesión de PDU a la CN 506 (es decir, a la CP-SM 510). El plano de control de la CN 506 define una política de QoS correspondiente a la solicitud de establecimiento de sesión de datos del UE 502, y proporciona la política de QoS a la AN 504 y a la UP-GW 516. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. La CN 506 luego transmite una respuesta de establecimiento de datos al UE 502 correspondiente a la política de QoS.
[0068] Este ejemplo en la FIG. 7 es solo un ejemplo de las posibles formas en que se puede establecer una política de QoS para una nueva sesión de datos. De acuerdo con varios aspectos de la presente divulgación, se puede utilizar cualquiera de una variedad de opciones para establecer una sesión de datos. Estas opciones incluyen un establecimiento de sesión de datos activado por la función de aplicación (AF), una solicitud de UE implícita para una sesión de datos y una solicitud de UE explícita para una sesión de datos.
[0069] El establecimiento de sesión de datos activado por la AF se utiliza en redes de núcleo de paquetes evolucionados (EPC) actuales (por ejemplo, LTE). Una AF 522 dentro de una red de datos externa 518 puede, por ejemplo, estar asociada con un servidor IMS u otra aplicación externa. La AF 522 es externa a la CN 506 y puede desencadenar el establecimiento de la sesión de datos al proporcionar información a la CN 506 para que la CN 506 pueda determinar a continuación que se ha establecido una nueva sesión o flujo de datos (UL y/o DL).
[0070] La FIG. 8 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para que una CN 506 establezca una política de QoS que responda o sea activada por una solicitud de un servidor de aplicaciones o función de aplicación (AF) 522 externos.
[0071] Al igual que con los ejemplos anteriores, se establece un contexto de MM entre el UE 502 y la AN 504, se establece una sesión de DN entre el UE 502 y la CN 506, y se establece una sesión de datos asociada entre el UE 502 y la UP-GW 516. En este ejemplo, una AF 522 externa que requiere QoS puede transmitir una solicitud de establecimiento de QoS al plano de control de la CN 506. El plano de control de la CN 506 define una política de QoS correspondiente a la solicitud de establecimiento de QoS y proporciona la política de QoS a la AN 504 y a la UP-GW 516. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. Los recursos adecuados se establecen a continuación en el UE 502 y la CN 506 en función de los recursos de la AN y la política de QoS. En este punto, la sesión de datos clasificada por QoS puede comenzar en el plano de usuario en las direcciones de UL y DL entre el UE 502 y la UP-GW 516.
[0072] En otro ejemplo, el UE 502 puede funcionar para iniciar una sesión de datos. De acuerdo con un aspecto de la presente divulgación, se pueden utilizar dos opciones diferentes para que el UE 502 inicie una sesión de datos y solicite una QoS adecuada para esa sesión de datos: con una solicitud de QoS explícita, o implícitamente, cuando la CN 506 detecta un flujo de UL enviado por el UE 502.
[0073] Con respecto a una solicitud de QoS implícita del UE 502, puede producirse un establecimiento de sesión de datos activado por el UE cuando el UE 502 se conecta a una aplicación o servicio que no tiene una función de aplicación (AF) 522 que interactúa con la CN 506. Aquí, una aplicación en el UE 502 puede solicitar conectividad y, en consecuencia, el UE 502 puede transmitir paquetes de UL utilizando un flujo no clasificado, en términos de QoS, utilizando la entrega de mejor esfuerzo. Como saben los expertos en la técnica, la entrega de mejor esfuerzo puede referirse a la entrega donde una red no garantiza la entrega de los datos, no garantiza ninguna QoS en particular y no garantiza ninguna prioridad a un flujo. Cuando estos datos entran desde el UE 502 en la dirección de UL, la CN 506 puede detectar que el UE 502 ha iniciado la transmisión de un flujo no clasificado (por ejemplo, sus paquetes carecen de un descriptor de sesión de datos 310), y la CN 506 puede realizar la clasificación de estos datos, por ejemplo, basándose en la inspección profunda de paquetes (DPI). Si los datos están autorizados, la CN 506 puede definir una política de QoS que luego puede entregarse al UE 502, la AN 504 y la UP-GW 516.
[0074] La FIG. 9 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS que responde o es activada por la detección de un flujo de UL no clasificado desde el UE 502. Este proceso corresponde a la solicitud de QoS implícita descrita anteriormente.
[0075] Al igual que con los ejemplos anteriores, se establece un contexto de MM entre el UE 502 y la AN 504, se establece una sesión de DN entre el UE 502 y la CN 506, y se establece una sesión de datos asociada entre el UE 502 y la UP-GW 516. En este ejemplo, el UE 502 puede transmitir un flujo de datos no clasificado (por ejemplo, no indicado explícitamente como perteneciente a una aplicación o servicio particular) en el enlace ascendente correspondiente a la política de QoS recibida por el UE en el establecimiento de la sesión de DN. Un ejemplo típico de dicha transmisión de flujo de datos sin clasificar puede corresponder a una solicitud de una sesión de TCP para un navegador web u otra aplicación. En el ejemplo ilustrado, la UP-GW 516 detecta que el UE 502 ha transmitido un nuevo flujo que no ha sido clasificado y transmite una indicación de flujo de datos desconocido detectado al plano de control de la CN 506. Como otro ejemplo (no ilustrado), la AN 504 puede detectar que el UE 502 ha transmitido un nuevo flujo de UL no clasificado y puede transmitir una indicación de flujo de datos desconocido detectado al plano de control de la CN 506. El plano de control de la CN 506 define una política de QoS correspondiente a una o más características del flujo no clasificado y proporciona la política de QoS a la AN 504 y a la UP-GW 516. El plano de control de la CN 506 proporciona a continuación la política de QoS a la AN 504. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. Los recursos adecuados se establecen a continuación en el UE 502 y la CN 506 en función de los recursos de la AN y la política de QoS. En este punto, la sesión de datos clasificados de QoS puede comenzar en el plano de usuario en las direcciones de UL y DL entre el UE 502 y la UP-GW 516. Aquí, el UE 502 puede utilizar marcado de paquetes y QoS según lo indicado por la política de QoS para transmisiones de UL del flujo de datos anteriormente no clasificado. Por ejemplo, esto puede incluir información relacionada con un token de UL, que se describe a continuación.
[0076] Con respecto a una solicitud de QoS explícita, la solicitud del UE 502 puede incluir un conjunto de uno o más parámetros de QoS para que la CN 506 los aplique a una sesión de datos, incluidos, entre otros, una velocidad de transferencia de bits garantizada (GBR) solicitada, una velocidad de transferencia de bits específica, etc. (Por ejemplo, la FIG. 21 ilustra un UE 502 con un conjunto de parámetros de QoS 2152 almacenados en la memoria 2105). Aquí, pueden existir dos opciones diferentes: una solución basada en el plano de control (plano C) y una solución basada en el plano de usuario (plano U). En la solución del plano C, un agente de aplicación, que puede iniciarse cuando se inicia una aplicación en el UE 502, puede provocar que el UE 502 transmita una solicitud de QoS para solicitar una nueva QoS o modificar la QoS. Es decir, el UE 502 puede utilizar una interfaz de programación de aplicación (API) 2164 para solicitar la QoS. Aquí, la aplicación puede solicitar explícitamente la QoS a través de la API 2164. Aquí, el UE 502 puede controlar la solicitud de QoS para esa aplicación en base a las políticas proporcionadas previamente al UE 502 por una red de operador. En otro ejemplo, la aplicación puede no ser capaz de generar una solicitud de QoS explícita, o puede requerir un tratamiento de datos especial con respecto a la QoS. Por ejemplo, la red del operador puede configurar ciertas políticas de QoS en el UE 502 para correlacionarlas con una QoS específica, y esto puede ser desconocido para la aplicación. En consecuencia, el UE 502 puede configurarse con políticas de QoS proporcionadas al UE 502 por la red del operador, de modo que el UE 502 pueda determinar los requisitos explícitos de QoS de una aplicación. De esta manera, el UE 502 puede correlacionar en consecuencia una solicitud de conectividad de la aplicación de la aplicación con una solicitud de QoS que transmite a la CN 506. En este caso, cuando la aplicación genera tráfico o solicita conectividad, el UE 502 puede solicitar una QoS adecuada de la CN 506.
[0077] En la solución del plano U, cuando el UE 502 transmite datos (por ejemplo, utilizando un flujo de mejor esfuerzo), el UE 502 puede proporcionar una indicación o una solicitud de QoS en banda. Aquí, la indicación puede ser una etiqueta en una cabecera IP (en el caso de datos IP) que indica que se trata de un nuevo flujo/sesión. La indicación también puede proporcionar opcionalmente requisitos para la QoS y los identificadores de la aplicación/servicio correspondiente. De esta manera, cuando los datos alcanzan la UPGW 516, la UP-GW 516 puede activar la funcionalidad del plano C para detectar la indicación, puede realizar la detección de la aplicación/servicio y puede verificar/autorizar el flujo en colaboración con la función de política de QoS, la CP-SM 510 y una función de aplicación (AF) 522 correspondiente al servidor con el que se relaciona el tráfico de datos.
[0078] La FIG. 10 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS que responde o es activada por una solicitud de UE explícita para la política de QoS. Este proceso corresponde a la solución basada en el plano de control para manejar una solicitud de QoS explícita del UE 502, descrita anteriormente. El lector puede reconocer que este proceso es similar al proceso a modo de ejemplo descrito anteriormente e ilustrado en la FIG. 7 para el establecimiento de sesión de datos posterior al establecimiento de sesión de DN, con la adición de la solicitud de QoS explícita del UE 502.
[0079] Al igual que con los ejemplos anteriores, se establece un contexto de MM entre el UE 502 y la AN 504, se establece una sesión de DN entre el UE 502 y la CN 506, y se establece una sesión de datos asociada entre el UE 502 y la UP-GW 516. En este ejemplo, el UE 502 transmite una solicitud de QoS explícita utilizando señalización de CP fuera de banda. La solicitud explícita de QoS puede incluir los requisitos de QoS, una ID de aplicación, etc., como se describe anteriormente. El plano de control de la CN 506 define una política de QoS correspondiente a la solicitud de establecimiento de QoS y proporciona la política de QoS a la AN 504 y a la UP-GW 516. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. Los recursos adecuados se establecen a continuación en el UE 502 y la CN 506 en función de los recursos de la AN y la política de QoS. En este punto, la sesión de datos clasificados de QoS puede comenzar en el plano de usuario en las direcciones de UL y DL entre el UE 502 y la UP-GW 516. Aquí, el UE 502 puede utilizar marcado de paquetes y QoS según lo indicado por la política de QoS para transmisiones de UL del flujo de datos anteriormente no clasificado. Por ejemplo, esto puede incluir información relacionada con un token de UL, que se describe a continuación.
[0080] La FIG. 11 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS que responde a, o es activada por, una solicitud de UE explícita para la política de UE. Este proceso corresponde a la solución basada en el plano de usuario para manejar una solicitud de QoS explícita del UE 502 cuando se inicia una sesión de datos, descrita anteriormente.
[0081] Al igual que con los ejemplos anteriores, se establece un contexto de MM entre el UE 502 y la AN 504, se establece una sesión de DN entre el UE 502 y la CN 506, y se establece una sesión de datos asociada entre el UE 502 y la UP-GW 516. El UE 502 transmite un flujo de UL no clasificado en el plano del usuario a la UP-GW 516. En este ejemplo, los datos del plano de usuario se marcan, utilizando la señalización del plano de usuario en banda, con una indicación de una nueva solicitud de QoS que puede incluir los requisitos de QoS, una ID de aplicación, un identificador del flujo de datos o la QoS del flujo de datos basándose en la política de QoS sobre la Política de QoS que el UE recibió de la CN 506, etc., como se describió anteriormente. En el ejemplo ilustrado, en respuesta, la UPGW 516 transmite información relacionada con la solicitud de QoS a la CN 506. En otro ejemplo (no ilustrado), la AN 504 puede detectar la transmisión del flujo de UL no clasificado marcado con la indicación de la nueva solicitud de QoS, y en respuesta, la AN 504 puede transmitir información relacionada con la solicitud de QoS a la CN 506. El plano de control de la CN 506 define una política de QoS correspondiente a la solicitud de QoS y proporciona la política de QoS a la AN 504 y a la UP-GW 516. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. Los recursos adecuados se establecen a continuación en el UE 502 y la CN 506 en función de los recursos de la AN y la política de QoS. En este punto, la sesión de datos clasificados de QoS puede comenzar en el plano de usuario en las direcciones de UL y DL entre el UE 502 y la UP-GW 516. Aquí, el UE 502 puede utilizar marcado de paquetes y QoS según lo indicado por la política de QoS para transmisiones de UL del flujo de datos anteriormente no clasificado. Por ejemplo, esto puede incluir información relacionada con un token de UL, que se describe a continuación.
Política de QoS con respecto a sesiones de DN y sesiones de datos
[0082] En las redes 3GPP heredadas, se define QoS para cada sesión de datos. Cuando se utiliza la arquitectura de CN descrita en la presente divulgación, también es posible establecer una política de QoS por sesión de datos, como en una red heredada. Un ejemplo de esta estrategia se ha descrito anteriormente y se ilustra en la FIG. 7. En este ejemplo, tras el establecimiento de una sesión de datos correspondiente a una sesión de DN, según los requisitos del UE proporcionados en una solicitud de establecimiento de sesión de datos, el perfil de suscripción del UE asociado con la sesión de DN correspondiente y las políticas de red, se puede establecer una política de QoS que se aplica específicamente a esa sesión de datos.
[0083] Sin embargo, en otro aspecto de la presente divulgación, la política de QoS puede determinarse y puede variar entre cada sesión de DN.
[0084] Como se describió anteriormente (por ejemplo, véase la FIG. 4), un UE 502 puede establecer una o más sesiones de DN 402a y/o 402b, cada una de las cuales puede tener un conjunto de una o más sesiones de datos o sesiones de PDU. Cada una de las sesiones de datos o sesiones de PDU puede tener su propia dirección IP o, en otros ejemplos, puede estar basada en una comunicación que no sea IP y puede tener un direccionamiento distinto.
[0085] En un aspecto de la presente divulgación, la QoS puede establecerse para cada sesión de DN, actuando como una especie de política general de QoS que se aplica a todas las sesiones de datos que pueden establecerse, que están asociadas con esa sesión de DN. Es decir, cuando se establece una sesión de DN entre un UE 502 y una Cn 506, el UE 502 puede transmitir una solicitud de QoS que incluye un conjunto de parámetros o requisitos de QoS. Según la solicitud de QoS, las credenciales que el UE 502 puede usar para establecer la sesión de DN y las políticas de red, la CN 506 puede establecer una política de QoS que se aplique a todas las sesiones de datos que se puedan establecer correspondientes a la sesión de DN. Aquí, esta política de QoS sería independiente de las direcciones IP asignadas a diferentes sesiones de datos IP que pueden crearse posteriormente, e independiente de qué UP-GW está dando servicio al UE 502.
[0086] En este ejemplo, la política de QoS correspondiente a esa sesión de DN se puede proporcionar a la AN 504 y a una o más UP-GW, incluso antes de que se establezca una sesión de datos en asociación con esa sesión de DN. La política de QoS puede proporcionarse adicionalmente al UE 502 tras la creación de la sesión de DN, de modo que pueda aplicarse a todas las sesiones de datos futuras que pertenezcan a esa sesión de DN.
[0087] La política de QoS aplicada a la sesión de DN puede contener uno o más descriptores de sesión de datos, que para la QoS asociada con la sesión de DN puede contener un subconjunto de los campos típicos del descriptor de sesión de datos para permitir que la política de QoS se aplique a una o más sesiones de datos. Por ejemplo, en el caso de una sesión de datos IP, el descriptor de la sesión de datos en la política de QoS puede contener todos los campos del descriptor de la sesión de datos, excepto la dirección IP de origen y de destino, ya que se asignarán más adelante cuando la sesión de datos está realmente establecida. En otro ejemplo correspondiente al caso de una sesión de datos IP, el descriptor de la sesión de datos en la política de QoS puede contener solo el tipo de protocolo de transporte (por ejemplo, TCP) y/o el número de puerto para las sesiones de transporte IP. De esta manera, se puede establecer una sesión de datos correspondiente a ese tipo de protocolo y/o número de puerto independientemente de la dirección IP de origen y destino.
[0088] La FIG. 12 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de una política de QoS en conexión con una sesión de DN. En este ejemplo, no se establece una sesión de datos en el momento en que se establece la sesión de DN, aunque se entenderá que este no es necesariamente el caso (por ejemplo, véase la FIG. 6).
[0089] Al igual que con los ejemplos anteriores, se establece un contexto de MM entre el UE 502 y la AN 504. En este ejemplo, el UE 502 transmite una solicitud de establecimiento de sesión de DN a la CN 506 (es decir, a la CP-SM 510), que incluye información de solicitud de QoS. En respuesta, el plano de control de la CN 506 define una política de QoS correspondiente a la solicitud de QoS y transmite un descriptor, que puede incluir información de política de QoS, a la AN 504. La AN 504 puede utilizar esta información para correlacionar con sus recursos como se describió anteriormente para la provisión de QoS a futuras sesiones de datos, o esta correlación se puede realizar más adelante en el establecimiento de la sesión de datos. Además, la CN 506 transmite una respuesta de establecimiento de sesión de DN al UE 502, que incluye información de política de QoS. De esta manera, el UE 502 puede utilizar esta política de QoS para sesiones de datos asociadas con la sesión de DN.
Función de AN
[0090] Como se describió anteriormente, la AN 504 puede en algunos ejemplos realizar la detección de una nueva sesión de datos utilizando descriptores de sesión de datos, y sin conocimiento explícito de los servicios o aplicaciones. Para el DL, estos descriptores pueden correlacionarse con la QoS de AN y los recursos de AN dedicados (por ejemplo, portadores de radio dedicados). Para el UL, la AN 504 puede tener sesiones de datos autorizadas previamente establecidas por la CN 506 por UE. Esto difiere de una red heredada típica, donde la AN recibe políticas de QoS correspondientes a cada sesión de datos en particular.
[0091] En otro aspecto, no es necesario realizar una inspección profunda de paquetes (DPI) en la AN 504. Es decir, puede no necesitarse inspección de tráfico adicional más allá de una cantidad limitada de inspección del descriptor de sesión de datos 310 para hacer coincidir el descriptor de sesión de datos. Esto puede incluir la coincidencia de marcas adicionales en banda opcionales, como una etiqueta de flujo de QoS 312.
[0092] La flexibilidad del descriptor de sesión de datos 310 utilizado en la AN 504, y la correlación de políticas en la AN 504, depende de la CN 506. Por ejemplo, una QoS por flujo versus el uso de un comodín para uno o más de los campos de descriptor de sesión de datos/flujo de datos para identificar un servicio o una clase de prioridad.
[0093] La AN 504 puede realizar la detección de sesión de datos de UL con respecto a la información de política de QoS. Cuando esto no sea posible, si está configurada para hacerlo, la AN 504 puede habilitar el reenvío de PDU de UL a la UP-GW 516 correspondiente en la QoS de mejor esfuerzo, para permitir sesiones de datos no detectadas iniciadas por UE que serán procesadas, autorizadas y controladas en la UP-GW 516.
Detección/Conocimiento de aplicaciones
[0094] En un aspecto de la presente divulgación, similar a la funcionalidad de un sistema heredado, la CN 506 puede detectar y autorizar sesiones de datos con respecto a la aplicación o servicio al que corresponde la sesión de datos. Por ejemplo, la detección de una sesión de datos se puede realizar analizando un paquete (por ejemplo, mediante DPI), o en virtud de una función de aplicación (AF) 522 que puede solicitar a la CN 506 el transporte de un cierto tipo de flujo de datos con una QoS específica. Una vez que se detecta y autoriza la sesión de datos, la información de QoS resultante de la detección puede distribuirse a la An 504, la UP-Gw 516 y el UE 502. La AN 504 puede identificar aplicaciones o servicios utilizando la correlación de tuplas IP configuradas a través de información/políticas. Estas aplicaciones o servicios se pueden entregar dinámicamente a la AN 504 por UE/por abonado, para permitir la itinerancia.
[0095] La detección de las sesiones de datos puede estar respaldada, además, por la información que el UE 502 proporciona a la CN 506. Como se analizó anteriormente en relación con una transmisión explícita de una solicitud de QoS del UE 502 (véanse las FIG. 10-11 y su descripción asociada), el UE 502 puede conocer los requisitos de QoS relacionados para al menos algunas aplicaciones o servicios, y en consecuencia, puede transmitir una solicitud de QoS explícita, ya sea utilizando señalización de plano de usuario o señalización de plano de control. Con respecto a la solicitud explícita de QoS que utiliza la señalización del plano de control, el UE 502 puede proporcionar un identificador de aplicación en la señalización del CP a la CN 506 con el fin de establecer una sesión de datos. Con respecto a la solicitud de QoS explícita que utiliza la señalización del plano de usuario, el UE 502 puede proporcionar un identificador de aplicación en banda con el tráfico de datos para permitir que la UP-GW 516 active la detección de aplicación en la CN 506.
Solicitudes explícitas de CN a AN
[0096] Un objetivo para una CN 506 de acuerdo con algunos aspectos de la divulgación es que la CN 506 sea lo más independiente posible de la tecnología de acceso. Es decir, idealmente, la CN 506 funcionaría de la misma manera para todas las AN, sin conocer los detalles de la AN. Sin embargo, debido a diferencias en las AN y preocupaciones de seguridad, esto puede no ser posible de implementar. Por consiguiente, algunos aspectos de la presente divulgación prevén que la CN 506 esté habilitada para proporcionar a la AN 504 una solicitud de QoS específica de AN. De esta manera, cada AN puede recibir un tratamiento de QoS diferente de acuerdo con los detalles de la AN o los detalles de la aplicación que utiliza una sesión de datos sobre la AN.
[0097] Por ejemplo, cuando una CN 506 solicita una configuración de QoS en una AN 504 para una nueva sesión de datos para un UE 502 dado, el UE 502 puede haber establecido múltiples sesiones de DN hacia, por ejemplo, diferentes proveedores de servicios (por ejemplo, redes de datos). Puede ocurrir que las sesiones de datos que pertenecen a diferentes proveedores de servicios requieran ser manejadas por recursos dedicados en la AN 504, recursos que no deberían compartirse con sesiones de DN no asociadas con esa sesión de datos. Por ejemplo, un requisito para una sesión de datos particular puede ser que esté cifrada con claves de seguridad que pueden generarse cuando el UE 502 se conecta a un servidor de aplicaciones particular. Además, una sesión de datos correspondiente a un servidor de aplicaciones diferente puede asegurarse con diferentes claves de seguridad que se generan cuando el UE 502 se conecta a ese servidor de aplicaciones. Es decir, en el caso de una RAN con portadores dedicados, puede ser necesario que el DRB que transporta el tráfico para una sesión de DN esté cifrado con claves distintas del DRB para una sesión de DN diferente. Como se ilustra en la FIG. 21, un UE puede almacenar en consecuencia una o más claves 2151 en la memoria 2105.
[0098] Por lo tanto, de acuerdo con un aspecto de la presente divulgación, cuando la CN 506 proporciona una política de QoS para una sesión de datos a la AN 504, la CN 506 puede tener la capacidad de transmitir a la AN 504 una indicación específica de que se necesitan recursos dedicados y separados (por ejemplo, un portador de radio dedicado) para esa sesión de datos. Dentro de esta solicitud, la CN 506 puede proporcionar, además, parámetros o valores adicionales, tales como cifrado separado o seguridad requerida (además de las claves correspondientes que se usarán), QoS separada requerida, etc. De esta manera, la AN 504 puede tomar en consideración tales requisitos en la decisión de cómo asignar recursos dedicados para la sesión de datos.
[0099] Para las sesiones de datos existentes, la solicitud de los recursos dedicados puede proporcionarse en un mensaje de solicitud de "modificación de conectividad de AN" o "modificación de QoS" o "modificación de correlación de sesión de datos" desde la CN 506 a la AN 502, que también contiene un identificador de la sesión de DN/datos existente correspondiente. Para nuevas sesiones de datos, la solicitud de los recursos dedicados puede proporcionarse en un mensaje de solicitud de "establecimiento de conectividad de AN" o "establecimiento de QoS" o "establecimiento de correlación de sesión de datos" desde la CN 506 a la AN 504, que también contiene un identificador de la correspondiente nueva sesión de DN/datos.
[0100] En respuesta, la AN 504 puede asignar los recursos dedicados separados. Por ejemplo, en el caso de una RAN, la RAN puede asignar un portador de radio dedicado para esa sesión de datos.
Política de QoS autorizada previamente
[0101] Si el UE 502 tiene una o más aplicaciones que son críticas para la latencia, o el UE 502 necesita enviar paquetes lo antes posible, la autorización previa de QoS para una sesión de datos en la que esos datos pueden transmitirse puede ser bastante útil. En consecuencia, como se analizó anteriormente, varios aspectos de la presente divulgación proporcionan un mecanismo para permitir dicha autorización previa de QoS para sesiones de datos.
[0102] Con más detalle, se puede establecer una sesión de DN y, según el perfil de suscripción del UE y las políticas de CN, la CN 506 puede establecer una política de QoS (conformación de QoS). Aquí, la CN 506 puede proporcionar a la AN 504 un conjunto de políticas de QoS para sesiones de datos que el UE 502 puede establecer posteriormente sin requerir autorización explícita por parte de la CN 506 (es decir, tales sesiones de datos están autorizadas previamente). Esta autorización previa no requiere necesariamente la creación de recursos dedicados en la AN 504. Por ejemplo, con respecto a una red de acceso por radio (RAN), puede ser necesaria alguna forma de recursos dedicados, como un portador de radio dedicado (DRB). De acuerdo con algunos aspectos de la presente divulgación, en el momento de la transmisión de un flujo de datos de UL utilizando una política de QoS autorizada previamente, no es necesario que se establezca ningún portador de radio dedicado. Es decir, la AN 504 puede recibir un paquete de un UE 502 antes del establecimiento de una sesión de datos que utiliza la política de QoS autorizada previamente. Aquí, la AN 504 puede mirar un descriptor de paquete en el paquete y, en consecuencia, puede determinar que el paquete corresponde a la política de QoS autorizada previamente y manejar el paquete en consecuencia.
[0103] Sin embargo, en otros ejemplos, la AN 504 puede establecer dichos recursos dedicados para futuras sesiones de datos. Por lo tanto, las PDU correspondientes a sesiones de datos autorizadas previamente pueden transportarse en función de la información autorizada previamente que se ha proporcionado al UE 502, por ejemplo, utilizando un portador de radio "predeterminado" o de "mejor esfuerzo" o, si está admitido y definido en la RAN, a través de un portador dedicado ya establecido para otras sesiones de datos. Si la sesión de datos está autorizada y requiere recursos dedicados en la AN 504, la CN 506 puede entregar información de política de QoS a la AN 504 que puede reservar recursos dedicados (por ejemplo, un portador dedicado en la RAN) para transportar los datos.
[0104] Como se debe reconocer por lo anterior, dicha autorización previa de QoS es una forma de acelerar efectivamente el tiempo de inicio de una sesión de datos sin sacrificar la seguridad.
[0105] Si bien lo anterior describe el comportamiento de la AN 504 para dicha QoS autorizada previamente, otra consideración es el comportamiento de la CN 506. En un ejemplo, la CN 506 puede seleccionar una UP-GW predeterminada y puede proporcionar a la AN 504, en la política de QoS, la dirección (por ejemplo, una dirección IP) de una UP-GW predeterminada para usar en las sesiones de datos autorizadas previamente. En otro ejemplo, sin embargo, no es necesario definir ninguna UP-GW por defecto. Aquí, la CN 506 puede proporcionar a la AN 504, en la política de QoS, información para permitir que la AN 504 seleccione una UP-GW 516 adecuada cuando se establecen tales sesiones de datos autorizadas previamente.
[0106] Los descriptores que la CN proporciona a diferentes nodos para describir la política de QoS pueden incluir información adecuada para los respectivos nodos con respecto a las sesiones de datos autorizadas previamente. Por ejemplo, la política de QoS puede incluir información que identifica los descriptores de sesión de datos, que contiene un subconjunto de los campos del descriptor de sesión de datos que permiten que la política de QoS se aplique a una o más sesiones de datos.
[0107] Como un ejemplo particular, en el caso de una sesión IP, los descriptores para el tráfico de UL pueden contener todos los campos descriptores de la sesión de datos menos la dirección IP de destino, y los descriptores para el tráfico de DL pueden contener todos los campos descriptores de la sesión de datos menos la dirección IP de origen, dado que en la creación de la sesión de DN, es posible que aún no se conozca la dirección del punto final (por ejemplo, el servidor de aplicaciones).
[0108] Como otro ejemplo particular, en el caso de la sesión IP, los descriptores para el tráfico de UL y DL pueden contener todos los campos del descriptor de sesión de datos en una cabecera de PDU de sesión de datos, menos la dirección IP de origen y destino, ya que en la creación de la sesión de DN, la dirección asignada al UE 502 y la dirección del punto final (por ejemplo, el servidor de aplicaciones en una red de datos externa 518) aún no se conocen.
[0109] Cuando el UE 502 genera una sesión de datos, basada en las dos opciones descritas anteriormente (tener una dirección IP predeterminada para la UP-GW 516, o no tener una dirección IP predeterminada y permitir que la AN 504 seleccione una UP-GW adecuada), el UE puede tener dos cursos de acción diferentes.
[0110] En la primera opción, correspondiente a tener definida una dirección IP predeterminada, cuando el UE 502 genera tráfico de UL que coincide con la política de QoS autorizada previamente, la dirección IP predeterminada se asocia con la sesión de datos y las PDU se envían a un punto final específico seleccionado por el UE 502. Aquí, tanto el UE 502 como la AN 504 aplican la política de QoS correspondiente.
[0111] En la segunda opción, que corresponde a ninguna dirección IP predeterminada, al establecer la sesión de DN, el UE 502 puede determinar enviar las PDU de plano de usuario correspondientes a una política de QoS autorizada previamente recibida de la CN 506. Aquí, la asignación de recursos de transporte se puede lograr de dos maneras. En una alternativa, el UE 502 puede activar la asignación de recursos de transporte, por ejemplo, a través de la señalización de estrato de acceso (AS) a la AN 504. Aquí, un UE 502 puede solicitar recursos de transporte para una nueva sesión de datos, y el UE 502 puede proporcionar la información correspondiente a la sesión de datos que se está estableciendo (por ejemplo, un descriptor de sesión de datos parcial para la sesión de datos y que coincida con la política de QoS autorizada previamente). En otra alternativa, para una sesión de datos IP, el UE 502 puede transmitir una solicitud para una asignación de dirección IP (por ejemplo, una solicitud de asignación de dirección IP) que contiene la información correspondiente a la sesión de datos que se está estableciendo. Por ejemplo, esta solicitud puede utilizar DHCP para la asignación de direcciones IP, y la AN 504 puede actuar como un proxy DHCP.
[0112] En cualquier caso, la AN 504 verifica la información recibida del UE 502 en la solicitud con respecto a la política de QoS autorizada previamente. Si coinciden, la AN 504 puede usar la información en la política de QoS autorizada previamente para seleccionar una UP-GW 516 (si la CN 506 no proporcionó ninguna en la política de QoS). Además, para sesiones de datos IP, la AN 504 puede solicitar una dirección IP para el UE 502 desde la UP-GW 516. El procedimiento también puede establecer un túnel entre la AN 504 y la UP-GW 516 para el encaminamiento de las PDU.
[0113] Si el establecimiento de la sesión de datos es exitoso, la AN 504 puede confirmar al UE 502 el establecimiento de los recursos de transporte. Para sesiones IP, esto puede incluir devolver la dirección IP al UE 502. El UE 502 puede transmitir PDU de UL que coincidan con la política de QoS autorizada previamente.
[0114] Si bien lo anterior ha analizado un procedimiento explícito para establecer una sesión de datos utilizando una política de QoS autorizada previamente, en otro aspecto de la divulgación, se puede utilizar un procedimiento implícito para el establecimiento de sesiones de datos. Aquí, cuando el UE 502 detecta que tiene datos para enviar que coinciden con una de las políticas de QoS autorizadas previamente, si el UE 502 tiene una dirección IP o recursos de AN dedicados que la AN 504 ha creado al entregar la política de QoS autorizada previamente, el UE 502 puede simplemente utilizar esos recursos. Sin embargo, si el UE 502 no tiene una dirección IP a la que enviar esos paquetes, el UE 502 puede transmitir sus PDU de UL a través de algún portador predeterminado o portador de mejor esfuerzo a la AN 504. Cuando la AN 504 detecta el tráfico de UL correspondiente a una política de QoS autorizada previamente que requiere recursos dedicados en la AN 504, la AN 504 puede establecer los recursos dedicados. Una vez que se establecen dichos recursos, tanto el UE 502 (para PDU de UL) como la AN 504 (para PDU de DL) pueden usar los recursos dedicados para PDU que coinciden con la política de QoS autorizada previamente.
[0115] La FIG. 13 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS autorizadas previamente en el momento del establecimiento de una sesión de DN, antes de que se haya establecido una sesión de datos. Este proceso ilustra la primera opción descrita anteriormente, en la que se establece una dirección IP predeterminada para la UP-GW para la sesión de datos autorizada previamente.
[0116] Al igual que con el ejemplo anterior, se establece un contexto de MM entre el UE 502 y la AN 504, el UE 502 transmite una solicitud de establecimiento de sesión de DN a la CN 506 que incluye información de solicitud de QoS, la CN 506 define una política de QoS autorizada previamente correspondiente a la solicitud de QoS y la CN 506 transmite un descriptor, que puede incluir información de política de QoS, a la AN 504. En este ejemplo, la CN 506 transmite adicionalmente una respuesta de establecimiento de sesión de DN al UE 502 en respuesta a la solicitud de establecimiento de sesión de DN, incluida la información de política de QoS, así como una dirección (por ejemplo, una dirección IP) de una UP-GW 516 predeterminada para flujos de datos autorizados previamente.
[0117] Cuando el UE 502 tiene datos para transmitir utilizando una nueva sesión de datos que coincide con una política de QoS autorizada previamente, el UE 502 puede comenzar la transmisión de los datos en un flujo de datos clasificado, marcado de acuerdo con una política de QoS autorizada previamente. La transmisión del UE puede ser dirigida o encaminada a la UP-GW 516 predeterminada identificada en la información de política de QoS para sesiones de datos autorizadas previamente. La AN 504 puede luego aplicar la política de QoS autorizada previamente al flujo de datos y dirigir el flujo a la UP-GW 516 predeterminada, que puede aplicar adicionalmente la política de QoS autorizada previamente para la comunicación con el UE 502.
[0118] La FIG. 14 es un diagrama de flujo de llamada que ilustra otro proceso a modo de ejemplo para el establecimiento de políticas de QoS autorizadas previamente en el momento del establecimiento de una sesión de DN, antes de que se haya establecido una sesión de datos. Este proceso ilustra la segunda opción descrita anteriormente, en la que no se establece ninguna UP-GW predeterminada, pero la AN 504 está provista de información que le permite seleccionar una UP-GW 516 adecuada.
[0119] Al igual que con el ejemplo anterior, se establece un contexto de MM entre el UE 502 y la AN 504, el UE 502 transmite una solicitud de establecimiento de sesión de DN a la CN 506 que incluye información de solicitud de QoS, la CN 506 define una política de QoS autorizada previamente correspondiente a la solicitud de QoS y la CN 506 transmite un descriptor, que puede incluir información de política de QoS, a la AN 504. En este ejemplo, la CN 506 transmite adicionalmente una respuesta de establecimiento de sesión de DN al UE 502 en respuesta a la solicitud de establecimiento de sesión de DN, incluida la información de la política de QoS.
[0120] Cuando el UE 502 tiene datos para transmitir utilizando una nueva sesión de datos que coincide con una política de QoS autorizada previamente, como se analizó anteriormente, hay dos posibilidades diferentes, ilustradas dentro de un cuadro de línea discontinua. En una opción, el UE 502 puede transmitir una solicitud de recursos de transporte del estrato de acceso (AS) a la AN 504 para solicitar recursos de transporte para una transmisión de UL. En la otra opción, el UE 502 puede transmitir una solicitud de asignación de dirección IP para solicitar la asignación de una dirección IP.
[0121] En respuesta, se pueden implementar dos posibilidades diferentes en la AN 504, ilustradas dentro de otro cuadro de línea discontinua. En una opción, la AN 504 puede seleccionar una UP-GW adecuada y establecer los recursos. En la otra opción, la AN 504 puede interactuar con la funcionalidad del plano de control de la CN 506 y, por lo tanto, seleccionar una UP-GW 516 adecuada y establecer los recursos. El UE puede entonces comenzar la transmisión de los datos en un flujo de datos clasificados, marcados de acuerdo con una política de QoS autorizada previamente. La transmisión del UE puede ser encaminada o dirigida a la UP-GW 516 seleccionada identificada en la información de política de QoS para sesiones de datos autorizadas previamente. La AN 504 puede luego aplicar la política de QoS autorizada previamente al flujo de datos y dirigir el flujo a la UP-GW 516 seleccionada, que además puede aplicar la política de QoS autorizada previamente para la comunicación con el UE 502.
Rechazo de la AN de una política de QoS
[0122] Anteriormente, se han analizado las políticas de QoS en las que la CN 506 toma una decisión relacionada con la política de QoS y distribuye esta política de QoS a la AN 504, el UE 502 y la UP-GW 516. Aquí, se ha supuesto esencialmente que todo va bien, y los respectivos nodos aplican la QoS de acuerdo con la determinación realizada por la CN 516.
[0123] Sin embargo, en algunos casos, como cuando una AN carece de recursos para satisfacer los requisitos de QoS, o cuando la AN tiene políticas locales que le prohíben permitir los requisitos de QoS (por ejemplo, basados en condiciones en tiempo real como la carga, la congestión, etc.), la AN 504 puede rechazar la política de QoS para una sesión de datos (una nueva sesión de datos o la modificación de QoS para una sesión de datos existente). Típicamente, si la AN 504 rechaza la política de QoS, la AN 504 simplemente no proporciona la QoS. En algunos casos, esto puede provocar que una sesión de datos no se conecte. De acuerdo con diversos aspectos de la presente divulgación, se pueden emplear tres opciones para manejar estos casos.
[0124] Una primera opción se ilustra en el diagrama de flujo de llamada de la FIG. 15. Aquí, una CN 506 puede definir una política de QoS y transmitir un descriptor que incluye información de política de QoS a una AN 504. Cuando la AN 504 rechaza la política de QoS, en este ejemplo, la AN 504 transmite una indicación del rechazo de la política de QoS a la CN 506. Aquí, la CN 506 puede simplemente no aplicar la QoS, y un flujo entre el UE 502 y la Cn 506 puede transportarse como mejor esfuerzo. En consecuencia, la CN 506 puede indicar a la UP-GW 516 que entregue tráfico de DL utilizando el mejor esfuerzo. Además, la AN 504 y el UE 502 pueden entregar tráfico de UL como mejor esfuerzo. La CN 506 puede necesitar negociar con un servidor de aplicaciones o el UE 502 con respecto a la decisión (donde la negociación puede ser solo una notificación).
[0125] Una segunda opción se ilustra en un diagrama de flujo de llamada de la FIG. 16. Aquí, una CN 506 puede definir una política de QoS y transmitir un descriptor que incluya información de política de QoS a una AN 504. Cuando la AN 504 rechaza la política de QoS, en este ejemplo, la AN 504 puede transmitir opcionalmente una indicación del rechazo de la política de QoS a la CN 506. Aquí, la AN 504 puede buscar encontrar una ruta alternativa para el tráfico. Por ejemplo, en el caso en que la AN 504 es una red de acceso por radio (RAN), el UE 502 en general puede realizar la caracterización de canal o ruta, por ejemplo, midiendo otras células vecinas en esa RAN o en otras RAN de acuerdo con las capacidades del UE. En consecuencia, el UE 502 puede proporcionar información relacionada con la caracterización del canal o la ruta a la AN 504. Según la información de la ruta, como estas mediciones realizadas por el UE 502, la AN 504 puede seleccionar una ruta alternativa, por ejemplo, entregando el UE 502 a otra célula o tecnología de acceso y, en consecuencia, la AN 504 puede transmitir información sobre la ruta seleccionada al UE 502. Dependiendo de la configuración de la AN 504, la AN 504 puede cambiar la sesión de datos a otra célula o tecnología de acceso que pueda cumplir con el requisito. En consecuencia, se puede establecer un flujo clasificado entre el UE 502 y la CN 506 sobre la ruta alternativa seleccionada. Si la AN 504 elige activar el traspaso a otra tecnología, la AN 504 puede activar una solicitud de traspaso a la CN 506 y, tras una preparación de traspaso exitosa, la AN 504 le indica a la CN 506 que la AN objetivo puede satisfacer la QoS solicitada.
[0126] Una tercera opción se ilustra en un diagrama de flujo de llamada de la FIG. 17. Aquí, la CN 506 puede saber que el UE 502 está conectado a múltiples AN 504a y 504b (por ejemplo, diferentes RAN celulares, o una RAN celular y una red Wi-Fi, etc.) para, por ejemplo, diferentes sesiones de datos. La CN 506 puede definir una política de QoS y transmitir un descriptor que incluya información de la política de QoS a la AN1 504a. Cuando la AN1 504a rechaza la política de QoS, la AN1 504a puede transmitir una indicación del rechazo de la política de QoS a la CN 506. Cuando la CN 506 recibe un rechazo de la AN1 504a para la QoS solicitada, la CN 506 puede activar el establecimiento de QoS en otra AN que el UE 502 está utilizando (por ejemplo, la AN2 504b) en función de las políticas locales que definen qué sesión de datos puede transportarse con qué tecnología de acceso. La CN 506 puede transmitir entonces una indicación al UE 502 para mover la sesión de datos a otra AN2 504b. La información de la CN 506 al UE 502 puede transmitirse en señalización de AS (si hay alguna presente, proporcionando la CN 506 primero la información a la AN1 504a que rechazó la solicitud de QoS), o en señalización de NAS. Esta señalización puede indicar qué sesiones de datos y/o la nueva QoS para las sesiones de datos existentes se utilizarán sobre la nueva AN2 504b (es decir, para que el UE 502 mueva las sesiones de datos a la nueva AN). En consecuencia, se puede establecer una sesión de datos clasificados utilizando la nueva AN2504b.
Etiqueta de token
[0127] Una política de QoS, en general, se define en función de un perfil de abonado (perfil de suscripción de usuario). Se identifican los flujos o sesiones de datos a los que se aplicará la política de QoS, y la CN 506 activa la conformación de QoS y crea una política de QoS. Si un UE 502 tiene múltiples sesiones de datos o flujos de datos con diferentes requisitos de QoS, la CN 506 puede necesitar establecer un número suficiente de políticas de QoS y puede identificar sesiones de datos que requieren un tratamiento especial. Típicamente, esto se logra pasando cada paquete enviado hacia/desde el UE 502 a través de filtros de plantilla de flujo de tráfico (TFT) o de función de datos de servicio (SDF).
[0128] Sin embargo, se puede utilizar un token para lograr estos mismos objetivos, pero de una manera mucho más simple. Es decir, un token puede proporcionar información que permita a una entidad como la CN 506 identificar que un paquete IP pertenece a un flujo particular, pero sin crear portadores y filtros, como se describió anteriormente.
[0129] A cada flujo se le puede asignar un token. Aquí, en lugar de aplicar los filtros, descritos anteriormente, la entidad que necesita identificar el paquete como perteneciente a un determinado flujo puede simplemente verificar el token determinando si el contenido del token coincide con la información en una tabla. El uso del token de esta manera puede ser muy rápido, y cuando el token se genera criptográficamente, puede proporcionar una seguridad sólida. El uso del token permite además la identificación en banda de los flujos, en lugar de filtrar el flujo en la CN 506.
[0130] Puede haber dos tipos de token: un token de DL y un token de UL. El token de DL es aplicable al tráfico de datos proveniente de un servidor de aplicaciones que genera el tráfico, que puede mejorarse para admitir el token de DL. Por ejemplo, si un UE 502 está conectado a un servicio de transmisión de vídeo, el servidor correspondiente puede aplicar un token de DL a los paquetes para que cuando los paquetes lleguen a la UPGW 516 el token se correlacione con la QoS para aplicarlo a ese flujo.
[0131] La CN 506 define un token de UL y proporciona el token al UE 502. Como se ilustra en la FIG. 21, el token 2153 puede almacenarse en la memoria 2105 en el UE 502. De esta manera, el UE 502 puede aplicar el token de UL a los paquetes en el UL. El token de UL se puede usar cuando el servidor de aplicaciones no puede enviar un token o no se ha modificado para aplicar los tokens a los paquetes. Debido a que la mayoría de las sesiones son iniciadas por el UE 502, el UE 502 enviará paquetes para esa sesión con el token de UL. La UP-GW 516 identificará el token y determinará que puede manejar los paquetes de acuerdo con la política de QoS, y puede determinar que los paquetes están autorizados y, en consecuencia, los paquetes de DL que coinciden con la información en esos paquetes de UL pueden autorizarse automáticamente gracias a la presencia del token de UL.
[0132] El token de UL, si se usa solo, podría funcionar para la autorización y vigilancia de los flujos de datos. Es decir, el token de UL puede considerarse un token reflectante, en el que el hecho de que haya un token en el UL que autorice el tráfico significa que el tráfico de DL correspondiente está autorizado. En este caso, se puede suponer que el tráfico de DL está desactivado por defecto hasta que la UPGW 516 detecta un token de UL, lo que confirma que el tráfico de DL correspondiente a él está autorizado.
[0133] El uso de un token de UL y un token de DL resuelve los problemas que pueden surgir cuando se utiliza un token de UL solo, y también permite una mejor diferenciación/procesamiento más fácil para el tráfico de SP específicos.
[0134] Más específicamente, la CN 506 puede crear una etiqueta de token y transmitir el token al UE 502 en función del perfil de suscripción, los requisitos de servicio/aplicación y las políticas de red, donde cada etiqueta de token está asociada con una sesión de datos que pertenece a una determinada política de QoS. La asignación de etiquetas de token no necesita hacerse durante la sesión de DN o el establecimiento de la sesión de datos; en su lugar, el UE 502 puede hacerlo a demanda. En algunos ejemplos, una etiqueta de token puede incluir parámetros de QoS (por ejemplo, QCI si se usa en una CN 5G).
[0135] Una sesión de datos o flujo de datos puede definirse en varias granularidades, por ejemplo, IP de origen y destino, 5-tuplas de IP o IP de origen y prefijo de destino, etc. La CN 506 proporciona la etiqueta de token a la UP­ GW 516 correspondiente junto con la política de QoS y cualquier otra política para el tratamiento de PDU. Cuando la UP-GW 516 recibe una PDU de UL del UE 502 que contiene una etiqueta de token, la UP-GW 516 (en colaboración con las entidades del plano de control en la CN 506) verifica la etiqueta del token, autoriza el paquete y aplica la QoS/aplica políticas basadas en la etiqueta del token.
[0136] Para las PDU de DL que contienen una etiqueta de token (por ejemplo, agregada a las PDU por el punto final de origen, como un servidor de aplicaciones), la UP-GW 516 (en colaboración con entidades de plano de control en la CN 506) verifica la etiqueta del token, autoriza el paquete, y aplica la QoS/aplica políticas basadas en la etiqueta del token. La UP-GW 516 puede dejar la etiqueta de token en la PDU para su procesamiento en la AN 504. La CN 506 proporciona, además, la etiqueta de token de UL al UE 502 con el descriptor de sesión de datos asociado para correlacionar con diferentes sesiones de datos. Para las PDU de UL, el UE 502 identifica la etiqueta de token correspondiente a la PDU en función del descriptor de sesión de datos proporcionado e incrusta la etiqueta en el paquete.
[0137] La CN 506 puede proporcionar la etiqueta de token de UL y/o la etiqueta de token de DL a la AN 504. Para las PDU de UL, si se proporciona una etiqueta de token correspondiente a un descriptor de sesión de datos de PDU, la AN 504 verifica la etiqueta de token, autoriza el paquete y aplica la QoS y/o aplica políticas basadas en la etiqueta de token. Para las PDU de UL, si se proporciona una etiqueta de token correspondiente a un descriptor de sesión de datos de PDU, la AN 504 correlaciona la etiqueta de token con los recursos de AN necesarios para transportar la PDU sobre la AN 504.
[0138] Las FIG. 18-20 ilustran varios ejemplos de establecimiento de políticas de QoS y establecimiento de tokens, ya que pueden implementarse de acuerdo con ciertos aspectos de la divulgación.
[0139] La FIG. 18 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS y el establecimiento de tokens de UL/DL utilizando señalización de plano de control.
[0140] Se establece un contexto de MM entre el UE 502 y la AN 504, se establece una sesión de DN entre el UE 502 y la CN 506, y se establece una sesión de datos asociada entre el UE 502 y la UPGW 516. En este ejemplo, el UE 502 transmite una solicitud de QoS explícita utilizando señalización de CP fuera de banda. La solicitud de QoS explícita puede incluir los requisitos de QoS, una ID de aplicación, etc. El plano de control de la CN 506 identifica la aplicación o servicio correspondiente a la ID de la aplicación, define una política de QoS correspondiente a la solicitud de establecimiento de QoS y crea un token de UL y un token de DL. La CN 506 luego proporciona la política de QoS a la AN 504 y la UP-GW 516, y opcionalmente entrega el token de DL a un servidor de aplicaciones en una red externa. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. Los recursos adecuados se establecen a continuación en el UE 502 y la CN 506 en función de los recursos de la AN y la política de QoS. En este punto, la sesión de datos clasificados de QoS puede comenzar en el plano de usuario en las direcciones de UL y DL entre el UE 502 y la UP-GW 516. Aquí, el UE 502 puede utilizar marcado de paquetes y QoS según lo indicado por la política de QoS para transmisiones de UL del flujo de datos anteriormente no clasificado. Por ejemplo, esto puede incluir información relacionada con un token de UL.
[0141] La FIG. 19 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS y el establecimiento de tokens de UL/DL implícitos utilizando señalización de plano de usuario. Como con el ejemplo anterior, se establece un contexto de MM entre el UE 502 y la AN 504, se establece una sesión de DN entre el UE 502 y la CN 506, y se establece una sesión de datos asociada entre el UE 502 y la UP-GW 516. En este ejemplo, el UE 502 puede transmitir un flujo de datos no clasificados (por ejemplo, no indicado explícitamente como perteneciente a una aplicación o servicio particular) en el enlace ascendente. Un ejemplo típico de dicha transmisión de flujo de datos sin clasificar puede corresponder a una solicitud de una sesión de TCP para un navegador web u otra aplicación. La UP-GW 516 detecta que el UE 502 ha transmitido un nuevo flujo que no ha sido clasificado y transmite una indicación de flujo de datos desconocido detectado al plano de control de la CN 506. El plano de control de la CN 506 identifica la aplicación o servicio en función de la ID de la aplicación, define una política de QoS correspondiente a una o más características del flujo no clasificado y proporciona la política de QoS a la AN 504 y a la UP-GW 516, y crea un token de UL y un token de DL. El plano de control de la Cn 506 proporciona a continuación la política de QoS a la AN 504 y opcionalmente entrega el token de DL al servidor de aplicaciones correspondiente a la aplicación identificada. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. Los recursos adecuados se establecen a continuación en el UE 502 y la CN 506 en función de los recursos de la AN y la política de QoS. En este punto, la sesión de datos clasificados de QoS puede comenzar en el plano de usuario en las direcciones de UL y DL entre el UE 502 y la UP-GW 516. Aquí, el UE 502 puede utilizar marcado de paquetes y QoS según lo indicado por la política de QoS para transmisiones de UL del flujo de datos anteriormente no clasificado. Por ejemplo, esto puede incluir información relacionada con un token de UL, que se describe a continuación.
[0142] La FIG. 20 es un diagrama de flujo de llamada que ilustra un proceso a modo de ejemplo para el establecimiento de políticas de QoS y el establecimiento de tokens de UL/DL explícitos utilizando señalización de plano de usuario. Al igual que con los ejemplos anteriores, se establece un contexto de MM entre el UE 502 y la AN 504, se establece una sesión de DN entre el UE 502 y la CN 506, y se establece una sesión de datos asociada entre el UE 502 y la UP-GW 516. El UE 502 transmite un flujo de UL no clasificado en el plano de usuario a la UP-GW 516. En este ejemplo, los datos del plano de usuario se marcan, utilizando la señalización del plano de usuario en banda, con una indicación de una nueva solicitud de QoS que puede incluir los requisitos de QoS, una ID de aplicación, etc., como se describió anteriormente. En respuesta, la UP-GW 516 transmite información relacionada con la solicitud de QoS a la CN 506. El plano de control de la CN 506 identifica la aplicación correspondiente a la ID de la aplicación, define una política de QoS correspondiente a la solicitud de QoS y crea un token de UL y un token de DL. El plano de control de la CN 506 proporciona entonces la política de QoS a la AN 504 y la UP-GW 516, y opcionalmente entrega el token de DL al servidor de aplicaciones en la red externa. La AN 504 correlaciona la política de QoS con los recursos en la AN 504 como se describió anteriormente, por ejemplo, identificando un subconjunto de parámetros de QoS (algunos o todos los parámetros de QoS) dentro de la política de QoS que se aplica a esa AN 504, y aplicando la política de QoS de acuerdo con ese subconjunto. Los recursos adecuados se establecen a continuación en el UE 502 y la CN 506 en función de los recursos de la AN y la política de QoS. En este punto, la sesión de datos clasificados de QoS puede comenzar en el plano de usuario en las direcciones de UL y DL entre el UE 502 y la UP-GW 516. Aquí, el UE 502 puede utilizar marcado de paquetes y QoS según lo indicado por la política de QoS para transmisiones de UL del flujo de datos anteriormente no clasificado. Por ejemplo, esto puede incluir información relacionada con un token de UL, que se describe a continuación.
[0143] La FIG. 21 es un diagrama de bloques que ilustra un ejemplo de una implementación de hardware para un UE 502 que emplea un sistema de procesamiento 2114. Por ejemplo, el UE 502 puede ser el UE descrito anteriormente e ilustrado en una cualquiera o más de las FIG. 1, 2 y 4-20.
[0144] El UE 502 puede implementarse con un sistema de procesamiento 2114 que incluye uno o más procesadores 2104. Los ejemplos de los procesadores 2104 incluyen microprocesadores, microcontroladores, procesadores de señales digitales (DSP), matrices de puertas programables in situ (FPGA), dispositivos de lógica programable (PLD), máquinas de estados, lógica de puertas, circuitos de hardware discretos y otro hardware adecuado configurado para realizar la diversa funcionalidad descrita a lo largo de esta divulgación. En varios ejemplos, el UE 502 puede estar configurado para llevar a cabo una cualquiera o más de las funciones descritas en el presente documento. Es decir, el procesador 2104, tal como se utiliza en un UE 502, se puede usar para implementar uno cualquiera o más de los procesos descritos en el presente documento e ilustrados en las FIG. 6-20, 23 o 24.
[0145] En este ejemplo, el sistema de procesamiento 2114 se puede implementar con una arquitectura de bus, representada en general por el bus 2102. El bus 2102 puede incluir un número cualquiera de buses y puentes de interconexión dependiendo de la aplicación específica del sistema de procesamiento 2114 y de las restricciones de diseño globales. El bus 2102 conecta comunicativamente diversos circuitos, que incluyen uno o más procesadores (representados en general por el procesador 2104), una memoria 2105 y medios legibles por ordenador (representados en general por el medio legible por ordenador 2106). El bus 2102 puede enlazar también otros circuitos diversos, tales como fuentes de temporización, dispositivos periféricos, reguladores de tensión y circuitos de gestión de potencia, que son bien conocidos en la técnica y, por lo tanto, no se describirán en mayor detalle. Una interfaz de bus 2108 proporciona una interfaz entre el bus 2102 y un transceptor 2110. El transceptor 2110 proporciona un medio para la comunicación con otros diversos aparatos a través de un medio de transmisión. En algunos ejemplos, el transceptor 2210 puede ser un transceptor inalámbrico para la comunicación con una red de acceso por radio (RAN). Dependiendo de la naturaleza del aparato, también se puede proporcionar una interfaz de usuario 2112 (por ejemplo, un teclado, una pantalla, un altavoz, un micrófono, una palanca de mando).
[0146] El procesador 2104 es responsable de gestionar el bus 2102 y el procesamiento general, incluyendo la ejecución de software almacenado en el medio legible por ordenador 2106. El software, cuando se ejecuta mediante el procesador 2104, hace que el sistema de procesamiento 2114 realice las diversas funciones descritas a continuación para cualquier aparato particular. El medio legible por ordenador 2106 y la memoria 2105 se pueden usar también para almacenar datos que son manipulados por el procesador 2104 cuando ejecuta software.
[0147] El procesador 2104 puede incluir un circuito de caracterización de canal/ruta 2141 configurado para caracterizar un canal o ruta con el fin de ayudar a la AN 504 a encontrar una ruta alternativa para el tráfico. Por ejemplo, en el caso en que la AN 504 es una red de acceso por radio (RAN), el circuito de caracterización de canal/ruta 2141 en general puede realizar la caracterización de canal o ruta, por ejemplo, midiendo otras células vecinas en esa RAN o en otras RAN de acuerdo con las capacidades del UE. El circuito de caracterización de canal/ruta 2141 puede operar en coordinación con el software de caracterización de canal/ruta 2161.
[0148] El procesador 2104 puede incluir, además, circuitos de solicitud de QoS 2142 configurados para solicitar una QoS adecuada para una sesión de datos, utilizando una solicitud de QoS explícita o una solicitud de QoS implícita donde la CN 506 detecta un flujo de UL enviado por el UE 502. El circuito de solicitud de QoS 2142 puede funcionar en coordinación con el software de solicitud de QoS 2162 y/o una interfaz de programa de aplicación (API) 2164 configurada para solicitar explícitamente una QoS.
[0149] El procesador 2104 puede incluir, además, circuitos de etiquetado de flujo 2143 configurados para aplicar una etiqueta de flujo adecuada a los paquetes. De esta manera, la gestión de QoS puede habilitarse sin necesidad de que los nodos realicen una inspección profunda de paquetes (DPI). Los circuitos de etiquetado de flujo 2143 pueden funcionar en coordinación con el software de etiquetado de flujo 2163.
[0150] Uno o más procesadores 2104 en el sistema de procesamiento pueden ejecutar software. Se deberá interpretar ampliamente que software quiere decir instrucciones, conjuntos de instrucciones, código, segmentos de código, código de programa, programas, subprogramas, módulos de software, aplicaciones, aplicaciones de software, paquetes de software, rutinas, subrutinas, objetos, módulos ejecutables, hilos de ejecución, procedimientos, funciones, etc., independientemente de que se denominen software, firmware, middleware, microcódigo, lenguaje de descripción de hardware o de otro modo. El software puede residir en un medio legible por ordenador 2106. El medio legible por ordenador 2106 puede ser un medio no transitorio legible por ordenador. Un medio legible por ordenador no transitorio incluye, a modo de ejemplo, un dispositivo de almacenamiento magnético (por ejemplo, un disco duro, un disco flexible, una cinta magnética), un disco óptico (por ejemplo, un disco compacto (CD), un disco versátil digital (DVD)), una tarjeta inteligente, un dispositivo de memoria flash (por ejemplo, una tarjeta, una memoria o un dispositivo USB), una memoria de acceso aleatorio (RAM), una memoria de solo lectura (ROM), una ROM programable (PROM), una PROM borrable (EPROM), una PROM borrable eléctricamente (EEPROM), un registro, un disco extraíble y cualquier otro medio adecuado para almacenar software y/o instrucciones a los que pueda acceder y que pueda leer un ordenador. El medio legible por ordenador 2106 puede residir en el sistema de procesamiento 2114, ser externo al sistema de procesamiento 2114 o distribuirse a través de múltiples entidades que incluyan el sistema de procesamiento 2114. El medio legible por ordenador 2106 puede incorporarse en un producto de programa informático. A modo de ejemplo, un producto de programa informático puede incluir un medio legible por ordenador en materiales de embalaje. Los expertos en la técnica reconocerán cómo implementar de la mejor manera la funcionalidad descrita presentada a lo largo de esta divulgación dependiendo de la aplicación particular y de las limitaciones de diseño globales impuestas en el sistema global.
[0151] La FIG. 22 es un diagrama conceptual que ilustra un ejemplo de una implementación en hardware para un nodo de red de acceso 504 que emplea un sistema de procesamiento 2214. De acuerdo con diversos aspectos de la divulgación, un elemento, o cualquier parte de un elemento, o cualquier combinación de elementos, puede implementarse con un sistema de procesamiento 2214 que incluya uno o más procesadores 2204. Por ejemplo, el nodo de red de acceso 504 puede ser una estación base u otro nodo en una red de acceso (AN) como se ilustra en una cualquiera o más de las FIG. 1,2 o 4-20.
[0152] El sistema de procesamiento 2214 puede ser sustancialmente el mismo que el sistema de procesamiento 2114 ilustrado en la FIG. 21, que incluye una interfaz de bus 2208, un bus 2202, una memoria 2205, un procesador 2204 y un medio legible por ordenador 2206. Además, el nodo de red de acceso 504 puede incluir una interfaz de usuario 2212 y un transceptor 2210 sustancialmente similar a los descritos anteriormente en la FIG. 21. El nodo de red de acceso 504 puede incluir, además, una interfaz de comunicación de CN 2216 (por ejemplo, una interfaz de retorno) configurada para la comunicación con una CN 506. Es decir, el procesador 2204, tal como se utiliza en el nodo de red de acceso 504, se puede usar para implementar uno cualquiera o más de los procesos descritos en el presente documento e ilustrados en las FIG. 6-20, 23 o 24.
[0153] El procesador 2204 puede incluir circuitos de manejo de QoS heredada 2241 configurados para la gestión de QoS de un flujo que utiliza parámetros de QoS heredada (por ejemplo, parámetros correspondientes a una red distinta de la red que implementa la política de QoS) en los casos en que el UE 502 está conectado a una AN heredada. Los circuitos de manejo de QoS heredada 2241 pueden funcionar en coordinación con el software de manejo de QoS heredada 2261.
[0154] El procesador 2204 puede incluir, además, circuitos de selección de ruta de UE 2242 configurados para encontrar una ruta adecuada para el tráfico correspondiente a una política de QoS. En algunos ejemplos, el circuito de selección de ruta de UE 2242 puede buscar una ruta alternativa para el tráfico de acuerdo con la información de caracterización de canal o ruta de un UE 502, y seleccionar una ruta alternativa, por ejemplo, entregando el UE 502 a otra célula o tecnología de acceso. Los circuitos de selección de ruta de UE 2242 pueden funcionar en coordinación con el software de selección de ruta de UE 2262.
[0155] El procesador 2204 puede incluir, además, circuitos de detección de sesión de datos 2243 configurados para detectar nuevas sesiones de datos usando descriptores de sesión de datos. Los circuitos de detección de sesión de datos 2243 pueden funcionar en coordinación con el software de detección de sesión de datos 2263.
[0156] El procesador 2204 puede incluir, además, circuitos de correlación de QoS/portador 2244 configurados para correlacionar etiquetas de flujo o descriptores con parámetros o información tal como una política de QoS. Los circuitos de correlación de QoS/portador 2244 pueden funcionar en coordinación con el software de correlación de QoS/portador 2264.
[0157] El procesador 2204 puede incluir, además, un circuito de etiquetado de flujo 2245 configurado para aplicar etiquetas de flujo a los paquetes. Los circuitos de etiquetado de flujo 2245 pueden funcionar en coordinación con el software de etiquetado de flujo 2265.
[0158] El procesador 2204 puede incluir, además, el circuito de determinación de UP-GW 2246 configurado para seleccionar una UP-GW para su uso por un nuevo flujo autorizado previamente. La UP-GW seleccionada puede ser una UP-GW predeterminada identificada por la CN 506 en la información de la política de QoS, o una UP-GW adecuada seleccionada en función de la PDU de la sesión de datos y la información proporcionada por la CN 506 en la política de QoS. Los circuitos de determinación de UP-GW 2246 pueden funcionar en coordinación con el software de determinación de UP-GW 2266.
[0159] El procesador 2204 puede incluir, además, circuitos de QoS 2247 configurados para aplicar una política de QoS a un flujo entre una CN 506 y un UE 502. Por ejemplo, los circuitos de QoS pueden aplicar una política de QoS controlando uno o más parámetros de un flujo basándose en la política de QoS, que incluye, entre otros, una velocidad de transferencia de bits de enlace ascendente o descendente, una velocidad de transferencia de bits garantizada, filtrado de paquetes (por ejemplo, determinar permitir o bloquear paquetes en función de su contenido), priorizar un flujo, etc. Los circuitos de QoS 2247 pueden funcionar en coordinación con el software de QoS 2267.
[0160] La FIG. 23 es un diagrama de flujo que ilustra un proceso 2300 a modo de ejemplo para gestionar la QoS en una red de datos. En algunos ejemplos, el proceso 2300 puede implementarse mediante el nodo de red de acceso 504 (por ejemplo, una estación base en una red de comunicación inalámbrica) descrito anteriormente e ilustrado en las FIG. 1, 2, 4-20 o 22. En algunos ejemplos, el proceso 2300 puede ser implementado por el procesador 2204 y/o el sistema de procesamiento 2214 descritos anteriormente e ilustrados en la FIG. 22. En otros ejemplos, el proceso 2300 puede ser implementado por cualquier aparato o medio adecuados para realizar las funciones descritas.
[0161] En el bloque 2302, la AN 504 recibe, desde una CN 506 (por ejemplo, utilizando el transceptor 2210), información de política de QoS que incluye uno o más parámetros de QoS, y opcionalmente, uno o más parámetros de QoS heredada (por ejemplo, uno o más parámetros de QoS correspondientes a una red que no sea la red que implementa la política de QoS). La información de la política de QoS incluye, además, uno o más descriptores de sesión de datos y, opcionalmente, una indicación de que una política de QoS es una política de QoS autorizada previamente aplicable a un flujo futuro que aún no se ha iniciado.
[0162] En el bloque 2304, la AN 504 identifica un subconjunto de parámetros de QoS que se aplican a la AN 504 dentro del uno o más parámetros de QoS recibidos en la información de política de QoS. Por ejemplo, la AN 504 puede referirse a los parámetros relevantes de QoS 2253 almacenados en la memoria 2205.
[0163] En el bloque 2306, la AN 504 almacena la política de QoS determinada y el uno o más descriptores de sesión de datos en un mapa de QoS 2251 en la memoria 2205. El mapa de QoS 2251 vincula una o más políticas de QoS con uno o más descriptores respectivos.
[0164] En el bloque 2308, la AN 504 determina una política de QoS (por ejemplo, utilizando los circuitos de correlación de QoS/portador 2244) basándose en la información de política de QoS seleccionada, del mapa de QoS 2251, la política de QoS que está vinculada a un descriptor en un paquete y seleccionando recursos de AN para el flujo en función de la política de QoS determinada.
[0165] En el bloque 2310, la AN 504 puede determinar (por ejemplo, utilizando circuitos de manejo de QoS heredada 2241) si el UE 502 se está volviendo a seleccionar con una AN heredada. Si se vuelve a seleccionar, entonces en el bloque 2312, la AN 504 puede aplicar una política de QoS correspondiente a los parámetros de QoS heredada al flujo. Si no se vuelve a seleccionar, entonces en el bloque 2314, la AN 504 puede determinar si la información de la política de QoS indica que la política de QoS es una política de QoS autorizada previamente aplicable a un flujo futuro que aún no se ha iniciado en el momento de la determinación de la política de QoS. Si no se trata de una política de QoS autorizada previamente, entonces en el bloque 2316, la AN 504 puede aplicar la política de QoS determinada a un flujo entre la CN 506 y un UE 502 cuando un descriptor en un paquete en el flujo corresponde a la política de QoS determinada.
[0166] Si se trata de una política de QoS autorizada previamente, entonces en el bloque 2318 la AN 504 puede determinar (por ejemplo, utilizando los circuitos de detección de sesión de datos 2243) si un descriptor en un paquete corresponde a la política de QoS autorizada previamente. Si no es así, entonces en el bloque 2320, la AN 504 no aplica la política de QoS autorizada previamente al flujo. Sin embargo, si corresponde a la política de QoS autorizada previamente, entonces en el bloque 2322, la AN 504 determina (por ejemplo, utilizando el circuito de determinación UP-GW 2246) una UP-GW a la cual transmitir el flujo basándose en la información de política de QoS, y aplica la política de QoS autorizada previamente al flujo cuando un descriptor en un paquete en el flujo corresponde a la política de QoS.
[0167] La FIG. 24 es un diagrama de flujo que ilustra un proceso 2400 a modo de ejemplo para gestionar la QoS en una red de datos. En algunos ejemplos, el proceso 2400 puede ser implementado por el UE 502 descrito anteriormente e ilustrado en la FIG. 1,2, o 4-21. En algunos ejemplos, el proceso 2400 puede ser implementado por el procesador 2104 y/o el sistema de procesamiento 2114 descrito anteriormente e ilustrado en la FIG. 21. En otros ejemplos, el proceso 2400 puede ser implementado por cualquier aparato o medio adecuado para realizar las funciones descritas.
[0168] En el bloque 2402, el UE 502 puede transmitir (por ejemplo, utilizando el transceptor 2110 en coordinación con circuitos de solicitud de QoS 2142) información que indica una solicitud para establecer una sesión de datos. Por ejemplo, el UE 502 puede transmitir un flujo de enlace ascendente no clasificado utilizando la entrega de mejor esfuerzo, que representa una solicitud implícita; o el UE 502 puede transmitir una solicitud de QoS explícita utilizando señalización CP o señalización UP.
[0169] En el bloque 2404, el UE 502 recibe de una CN 506 (por ejemplo, utilizando el transceptor 2110), información de política de QoS. En el bloque 2406, el UE 502 recibe (por ejemplo, utilizando el transceptor 2110) una indicación de un recurso para comunicarse con la CN 506 utilizando la sesión de datos, en el que la sesión de datos utiliza una política de QoS basada en la información de política de QoS. Finalmente, el UE 502 se comunica (por ejemplo, utilizando el transceptor 2110) con la CN 506 utilizando la sesión de datos establecida.
[0170] Se han presentado varios aspectos de una red de comunicación inalámbrica con referencia a una implementación a modo de ejemplo. Como los expertos en la técnica apreciarán fácilmente, diversos aspectos descritos a lo largo de la presente divulgación se pueden extender a otros sistemas de telecomunicaciones, arquitecturas de red y estándares de comunicación.
[0171] A modo de ejemplo, se pueden implementar varios aspectos dentro de otros sistemas definidos por el 3GPP, tal como la Evolución a Largo Plazo (LTE), el Sistema de Paquetes Evolucionado (EPS), el Sistema Universal de Telecomunicaciones Móviles (UMTS) y/o el Sistema Global de Comunicaciones Móviles (GSM). Diversos aspectos también pueden extenderse a los sistemas definidos por el Proyecto de Colaboración de Tercera Generación 2 (3GPP2), tales como CDMA2000 y/o la Evolución de Datos Optimizados (EV-DO). Se pueden implementar otros ejemplos dentro de los sistemas que emplean IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Banda Ultra Ancha (UWB), Bluetooth y/u otros sistemas adecuados. El estándar de telecomunicaciones, la arquitectura de red y/o el estándar de comunicación concretos empleados dependerán de la aplicación específica y de las limitaciones de diseño globales impuestas en el sistema.
[0172] Dentro de la presente divulgación, la expresión "a modo de ejemplo" se usa para significar que "sirve de ejemplo, caso o ilustración". Cualquier implementación o aspecto descrito en el presente documento como "a modo de ejemplo" no se debe interpretar necesariamente como preferente o ventajoso con respecto a otros aspectos de la divulgación. Asimismo, el término "aspectos" no requiere que todos los aspectos de la divulgación incluyan el rasgo característico, ventaja o modo de funcionamiento analizados. El término "acoplado" se usa en el presente documento para referirse al acoplamiento directo o indirecto entre dos objetos. Por ejemplo, si el objeto A toca físicamente el objeto B, y el objeto B toca el objeto C, entonces los objetos A y C todavía se pueden considerar acoplados entre sí, incluso si no se tocan físicamente entre sí directamente. Por ejemplo, un primer objeto puede estar acoplado a un segundo objeto incluso aunque el primer objeto nunca esté físicamente en contacto directo con el segundo objeto. Los términos "circuito" y "circuitos" se usan ampliamente, y pretenden incluir tanto implementaciones en hardware de dispositivos eléctricos como conductores que, cuando se conectan y configuran, posibilitan el cumplimiento de las funciones descritas en la presente divulgación, sin limitación en cuanto al tipo de circuitos electrónicos, así como implementaciones en software de información e instrucciones que, cuando son ejecutadas por un procesador, posibilitan el cumplimiento de las funciones descritas en la presente divulgación.
[0173] Uno o más de los componentes, etapas, características y/o funciones ilustradas en las FIG. 1-24 se pueden reorganizar y/o combinar en un solo componente, etapa, rasgos característicos o función o incorporarse en diversos componentes, etapas o funciones. También se pueden añadir elementos, componentes, etapas y/o funciones adicionales sin apartarse de las características novedosas divulgadas en el presente documento. El aparato, dispositivos y/o componentes ilustrados en las FIG. 1-22 se pueden configurar para realizar uno o más de los procedimientos, rasgos característicos o etapas descritos en el presente documento. Los algoritmos novedosos descritos en el presente documento también se pueden implementar eficazmente en software y/o integrarse en hardware.
[0174] Se entenderá que el orden o jerarquía específicos de las etapas en los procedimientos divulgados es una ilustración de procedimientos a modo de ejemplo. En base a las preferencias de diseño, se entiende que se puede reorganizar el orden o jerarquía específicos de las etapas en los procedimientos. Las reivindicaciones adjuntas del procedimiento presentan elementos de las diversas etapas en un orden de muestra y no prevén limitarse al orden o jerarquía específico presentados a menos que se mencione específicamente en las mismas.

Claims (10)

REIVINDICACIONES
1. Un procedimiento de gestión de la calidad de servicio, QoS, en una red de datos, comprendiendo el procedimiento:
recibir (2302) en un nodo de red de acceso, AN, en una AN (204, 504), desde una red central, CN, (206, 506) información de política de QoS, comprendiendo la información de política de QoS uno o más parámetros de QoS y uno o más descriptores de sesión de datos (310);
obtener una política de QoS basándose en al menos una parte de la información de la política de QoS; almacenar una o más políticas de QoS y uno o más descriptores de sesión de datos (310) en un mapa de QoS que vincula la una o más políticas de QoS con el uno o más descriptores respectivos; y aplicar (2316) la política de QoS a un flujo entre la CN (206, 506) y un equipo de usuario, UE, (202, 502) cuando un descriptor en un paquete en el flujo corresponde a la política de QoS;
en el que la obtención de la política de QoS comprende:
seleccionar, del mapa de QoS, la política de QoS que está vinculada al descriptor en el paquete; y seleccionar recursos de AN para el flujo basándose en la política de QoS.
2. El procedimiento según la reivindicación 1, en el que los parámetros de QoS incluyen parámetros de QoS correspondientes a una segunda red distinta de la red de datos, comprendiendo el procedimiento, además: aplicar los parámetros de QoS correspondientes a la segunda red al flujo cuando el UE (202, 502) vuelve a seleccionarse entre la AN (204, 504) y una red de acceso heredada que utiliza los parámetros de QoS correspondientes a la segunda red.
3. El procedimiento según la reivindicación 1, que comprende, además:
recibir, dentro de la información de la política de QoS, información que indica que la política de QoS es una política de QoS autorizada previamente aplicable a un flujo futuro que aún no se ha iniciado en el momento de obtener la política de QoS.
4. El procedimiento según la reivindicación 3, que comprende, además:
recibir el paquete del UE (202, 502) antes de establecer una sesión de datos que utiliza la política de QoS autorizada previamente; y
determinar que el descriptor en el paquete corresponde a la política de QoS autorizada previamente.
5. El procedimiento según la reivindicación 3, que comprende, además:
determinar una pasarela de plano de usuario, UP-GW, a la que transmitir el flujo en función de la información de la política de QoS, ya sea seleccionando una UP-GW predeterminada identificada en la información de la política de QoS, o seleccionando la UP-GW basándose en la información de la política de QoS.
6. El procedimiento según la reivindicación 1, que comprende, además:
recibir el paquete en una transmisión de enlace ascendente desde el UE (202, 502), en el que el descriptor es aplicado al paquete por el UE (202, 502); o
recibir el paquete en una transmisión de enlace descendente desde la CN (206, 506), en el que el descriptor es aplicado al paquete por la CN (206, 506).
7. El procedimiento según la reivindicación 1, en el que la obtención de la política de QoS comprende obtener la política de QoS con respecto a una sesión de red de datos, DN;
en el que un conjunto de una o más sesiones de datos está asociado con la sesión de DN; y
en el que el flujo es una sesión de datos dentro del conjunto de una o más sesiones de datos asociadas con la sesión de DN,
comprendiendo el procedimiento, además, aplicar la política de QoS, obtenida con respecto a la sesión de DN, a cada sesión de datos dentro del conjunto de una o más sesiones de datos asociadas con la sesión de DN.
8. El procedimiento según la reivindicación 1, que comprende, además:
recibir, dentro de la información de la política de QoS, información que indica que se necesita un recurso dedicado y separado para una sesión de datos que utiliza la política de QoS; y
asignar el recurso separado y dedicado para la sesión de datos,
en el que el recurso dedicado y separado comprende al menos uno de un portador de radio dedicado, cifrado separado o una QoS separada.
9. Un nodo de red de acceso, AN, dentro de una AN (204, 504) y configurado para gestionar la calidad de servicio, QoS, en una red de datos, comprendiendo el nodo de AN:
medios configurados para recibir desde una red central, CN, (206, 506) información de política de QoS, comprendiendo la información de la política de QoS uno o más parámetros de QoS y uno o más descriptores de sesión de datos (310);
medios configurados para obtener una política de QoS basándose en al menos una parte de la información de la política de QoS; medios configurados para almacenar una o más políticas de QoS y el uno o más descriptores de sesión de datos (310) en un mapa de QoS que vinculan la una o más políticas de QoS con el uno o más descriptores respectivos; y
medios configurados para aplicar la política de QoS a un flujo entre la CN (206, 506) y un equipo de usuario, UE, (202, 502) cuando un descriptor en un paquete en el flujo corresponde a la política de QoS;
en el que los medios configurados para obtener la política de QoS comprenden, además:
medios configurados para seleccionar del mapa de QoS, la política de QoS que está vinculada al descriptor en el paquete; y
medios configurados para seleccionar recursos de AN para el flujo en función de la política de QoS.
10. Un medio legible por ordenador que almacena código ejecutable por ordenador que comprende instrucciones para hacer que un nodo de red de acceso, AN, dentro de una AN (204, 504) realice las etapas de un procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 8.
ES17712890T 2016-04-04 2017-03-03 Gestión de calidad de servicio (QoS) en redes inalámbricas Active ES2810866T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662318150P 2016-04-04 2016-04-04
US15/275,170 US10277515B2 (en) 2016-04-04 2016-09-23 Quality of service (QOS) management in wireless networks
PCT/US2017/020744 WO2017176399A1 (en) 2016-04-04 2017-03-03 Quality of service (qos) management in wireless networks

Publications (1)

Publication Number Publication Date
ES2810866T3 true ES2810866T3 (es) 2021-03-09

Family

ID=59959908

Family Applications (2)

Application Number Title Priority Date Filing Date
ES17712890T Active ES2810866T3 (es) 2016-04-04 2017-03-03 Gestión de calidad de servicio (QoS) en redes inalámbricas
ES19180659T Active ES2893238T3 (es) 2016-04-04 2017-03-03 Gestión de calidad de servicio (QoS) en redes inalámbricas

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES19180659T Active ES2893238T3 (es) 2016-04-04 2017-03-03 Gestión de calidad de servicio (QoS) en redes inalámbricas

Country Status (11)

Country Link
US (2) US10277515B2 (es)
EP (2) EP3440868B1 (es)
KR (2) KR102038792B1 (es)
CN (2) CN113452626B (es)
AU (1) AU2017247128B2 (es)
BR (1) BR112018070319A2 (es)
CA (1) CA3016549A1 (es)
ES (2) ES2810866T3 (es)
SG (2) SG10202013154PA (es)
TW (1) TWI730059B (es)
WO (1) WO2017176399A1 (es)

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10277515B2 (en) 2016-04-04 2019-04-30 Qualcomm Incorporated Quality of service (QOS) management in wireless networks
ES2940614T3 (es) * 2016-04-08 2023-05-09 Nokia Technologies Oy Método y aparato para el mapeo de flujo de subservicio de plano U
US11444850B2 (en) * 2016-05-02 2022-09-13 Huawei Technologies Co., Ltd. Method and apparatus for communication network quality of service capability exposure
WO2018029930A1 (ja) 2016-08-10 2018-02-15 日本電気株式会社 無線アクセスネットワークノード、無線端末、コアネットワークノード、及びこれらの方法
JP6665937B2 (ja) 2016-08-10 2020-03-13 日本電気株式会社 無線アクセスネットワークノード、無線端末、及びこれらの方法
JP6777451B2 (ja) * 2016-08-10 2020-10-28 株式会社Ｎｔｔドコモ 基地局
CN114025395A (zh) 2016-08-10 2022-02-08 日本电气株式会社 无线接入网节点、无线终端及其方法
CN109526252B (zh) 2016-08-10 2021-09-17 日本电气株式会社 无线接入网节点、无线终端、核心网节点及其方法
CN107889171B (zh) * 2016-09-30 2023-10-20 华为技术有限公司 无线通信方法、用户设备和接入网设备
KR20180038716A (ko) 2016-10-07 2018-04-17 삼성전자주식회사 단말의 시그널링 메시지를 Network Function 간 전달하는 방안
US10862810B2 (en) * 2016-10-10 2020-12-08 Nokia Solutions And Networks Oy Throughput in communications network
EP3536016B1 (en) * 2016-11-04 2020-04-08 Telefonaktiebolaget LM Ericsson (PUBL) Ue, network node and methods for handling data packets
US10893440B2 (en) * 2016-11-04 2021-01-12 Huawei Technologies Co., Ltd. Network hotspot control method and related device
US10321503B2 (en) * 2016-12-11 2019-06-11 Motorola Mobility Llc Method and apparatus for attaching a remote unit to a mobile core network via a standalone untrusted non-3GPP access network
CN108235376B (zh) * 2016-12-21 2020-03-06 电信科学技术研究院 一种用户面锚点选择方法及装置
US10542454B2 (en) * 2017-02-10 2020-01-21 Mediatek Inc. Control and management of reflective QoS
WO2018145879A1 (en) * 2017-02-10 2018-08-16 Sony Corporation Communications system, infrastructure equipment, communications device and methods
US10476914B2 (en) * 2017-02-16 2019-11-12 Htc Corporation Device and method for performing an internet protocol multimedia subsystem service
US10511993B2 (en) * 2017-03-15 2019-12-17 Nokia Technologies Oy Buffer status reporting and new quality of service flows on default bearer in next generation radio access networks
WO2018176441A1 (zh) * 2017-04-01 2018-10-04 华为技术有限公司 用户鉴权方法和装置
US10772148B2 (en) * 2017-04-28 2020-09-08 Kt Corporation Method and apparatus for managing PDU session between base station and core network in next-generation wireless network
WO2019071472A1 (zh) * 2017-10-11 2019-04-18 华为技术有限公司 一种业务策略创建方法及装置
US10931545B2 (en) * 2017-11-29 2021-02-23 Gigamon Inc. Policy-based sampling of network flows at a network visibility node
US11368873B2 (en) * 2017-12-15 2022-06-21 Huawei Technologies Co., Ltd. Method and system of packet aggregation
US11632676B2 (en) * 2018-01-09 2023-04-18 Qualcomm Incorporated Service-based access stratum (AS) security configuration
CN111466131B (zh) * 2018-01-24 2023-01-13 中兴通讯股份有限公司 用于在多个接入之间分割流量的方法和计算设备
US10986528B2 (en) 2018-02-15 2021-04-20 Huawei Technologies Co., Ltd. Tracking QoS violated events
EP3777460A1 (en) * 2018-04-06 2021-02-17 Lenovo (Singapore) Pte. Ltd. Determining remote unit behavior parameters
US11323934B2 (en) 2018-04-09 2022-05-03 Nokia Technologies Oy Session context conversion
US20190313311A1 (en) 2018-04-09 2019-10-10 Mediatek Inc. Apparatuses, service networks, and methods for handling plmn-specific parameters for an inter-plmn handover
US10911979B2 (en) * 2018-04-09 2021-02-02 Mediatek Inc. AT commands for 5G session management
US20190349805A1 (en) * 2018-05-11 2019-11-14 Mediatek Inc. User equipments and methods for handling an update on quality of service (qos) flow to data radio bearer (drb) mapping
US11026124B2 (en) 2018-07-02 2021-06-01 Mediatek Inc. Enhanced handling on 5G QoS operations
US11039369B2 (en) 2018-08-10 2021-06-15 Mediatek Inc. Handling 5G QoS rules on QoS operation errors
US11800408B2 (en) * 2018-08-14 2023-10-24 Telefonaktiebolaget Lm Ericsson (Publ) Method for advance notification of changes to network QoS capabilities
CN110856273B (zh) * 2018-08-20 2021-07-20 华为技术有限公司 会话管理方法、设备及系统
PL3847844T3 (pl) * 2018-09-03 2023-02-06 Telefonaktiebolaget Lm Ericsson (Publ) Transport przepływów danych przez sieci komórkowe
US10791485B2 (en) * 2018-10-16 2020-09-29 Cisco Technology, Inc. Systems and methods for quick user datagram protocol internet connection (QUIC) with multipath
KR102598405B1 (ko) 2018-10-19 2023-11-03 현대자동차 주식회사 자동차의 배기가스 정화장치 및 그 제어방법
TWI674808B (zh) * 2018-11-01 2019-10-11 財團法人資訊工業策進會 無線通訊系統及控制平面之管理之切換方法
MX2021005281A (es) * 2018-11-12 2021-06-18 Ericsson Telefon Ab L M Metodo y aparato para la administracion de sesiones.
WO2020102512A1 (en) * 2018-11-16 2020-05-22 Idac Holdings, Inc. Enabling a non-public network communication
CN111294224B (zh) * 2018-12-10 2022-04-22 华为技术有限公司 用于测量服务质量信息的方法和装置
CN112997529B (zh) * 2018-12-12 2023-12-05 瑞典爱立信有限公司 用于处理无线通信网络中的服务质量的策略节点、用户平面节点、控制平面节点及其中的方法
US11190971B2 (en) * 2019-02-22 2021-11-30 Apple Inc. UE assistance application detection and policy control in QoS deployment
US11533669B2 (en) * 2019-04-26 2022-12-20 Cisco Technology, Inc. Enterprise network fabric extension across mobile networks
DK3788819T3 (da) 2019-05-02 2022-07-04 Ericsson Telefon Ab L M Tilvejebringelse af GPSI i forbindelse med PDU-session(er)
CN110474969B (zh) 2019-07-29 2021-07-16 华为技术有限公司 会话管理方法及装置
CN114615154B (zh) * 2019-08-26 2024-06-25 阿里巴巴集团控股有限公司 服务质量管理的方法及装置、通信系统
WO2021049794A1 (ko) * 2019-09-10 2021-03-18 삼성전자 주식회사 전력 및/또는 발열 제어를 구현하는 방법 및 그 전자 장치
US11582066B2 (en) 2019-12-19 2023-02-14 Cisco Technology, Inc. Techniques for extending a cellular quality of service bearer through an enterprise fabric
US11375024B1 (en) * 2021-02-22 2022-06-28 T-Mobile Innovations Llc Programmable networking device for user plane function
US11463900B2 (en) * 2021-03-07 2022-10-04 Verizon Patent And Licensing Inc. Systems and methods for application-anonymous rule authorization and enforcement in a wireless network
US11910229B2 (en) 2021-03-07 2024-02-20 Verizon Patent And Licensing Inc. Systems and methods for selectable application-specific quality of service parameters in a wireless network
FR3121812B1 (fr) * 2021-04-07 2023-10-13 Commissariat Energie Atomique Procédé et dispositif d’orchestration de l’exécution de mécanismes dans un réseau sans fil
CN113316098B (zh) * 2021-04-20 2022-10-21 新华三技术有限公司 一种建立业务通道、公网对讲的方法和公网对讲设备
US20220377389A1 (en) * 2021-05-12 2022-11-24 Tencent America LLC Method for using 5g edge application servers for live streaming of user-generated content
WO2022252188A1 (en) * 2021-06-03 2022-12-08 Huawei Technologies Co., Ltd. Method, device and computer-readable memory for communications within a radio access network
CN113784397A (zh) * 2021-09-10 2021-12-10 腾讯科技（深圳）有限公司 一种数据处理方法、设备以及可读存储介质
CN113784396A (zh) * 2021-09-10 2021-12-10 腾讯科技（深圳）有限公司 一种数据处理方法、设备以及可读存储介质
CN114666265B (zh) * 2022-03-28 2024-04-02 阿里巴巴（中国）有限公司 数据传输方法、装置、计算设备及介质

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1458148A1 (en) * 2003-03-10 2004-09-15 Sony International (Europe) GmbH Quality of Service (QoS) -aware handover procedure for Ad-Hoc networks
US8018881B2 (en) 2004-07-19 2011-09-13 Ericsson Ab Admission control and policing in wireless packet data communication system
US20060045128A1 (en) * 2004-09-01 2006-03-02 Lila Madour Per flow quality of service (QoS) enforcement for downlink data traffic
US8854965B1 (en) * 2005-07-20 2014-10-07 Avaya Inc. Flow label systems and methods
FI20051320A0 (fi) * 2005-12-22 2005-12-22 Nokia Corp Menetelmä pakettivirtojen kohdentamiseksi siirtoteille viestintäjärjestelmässä
EP2015596A4 (en) * 2006-04-28 2012-09-19 Fujitsu Ltd QOS SERVER IN A MOBILE COMMUNICATION SYSTEM
US8194540B2 (en) * 2007-08-08 2012-06-05 Samsung Electronics Co., Ltd. Apparatus and method for managing quality of service of service flow in wireless communication system
US20090190471A1 (en) 2008-01-10 2009-07-30 Mahendran Arungundram C Method and Apparatus for Optimized Session Setup with Network-Initiated QoS Policy Control
US8194549B2 (en) * 2008-05-09 2012-06-05 At&T Mobility Ii Llc Femto cell access point passthrough model
CN101277315A (zh) * 2008-05-21 2008-10-01 中兴通讯股份有限公司 一种互联网业务的服务质量控制方法
WO2010066295A1 (en) * 2008-12-10 2010-06-17 Telefonaktiebolaget Lm Ericsson (Publ) Token-based correlation of control sessions for policy and charging control of a data session through a nat
CN102273263A (zh) * 2009-01-06 2011-12-07 夏普株式会社 移动通信系统、QoS控制站和移动台
US8675577B2 (en) * 2010-12-20 2014-03-18 Intel Corporation Signaling techniques for a multimedia-aware radio and network adaptation
CN102883377B (zh) * 2011-07-12 2017-12-12 中兴通讯股份有限公司 服务质量处理方法及装置
CN104081826B (zh) * 2012-03-16 2018-04-13 Lg 电子株式会社 用于在无线通信系统中处理nas信令请求的方法和装置
WO2014157912A1 (ko) * 2013-03-27 2014-10-02 엘지전자 주식회사 무선 통신 시스템에서 액세스 네트워크 선택을 위한 방법 및 이를 위한 장치
US9432873B2 (en) 2013-05-20 2016-08-30 Nokia Technologies Oy Differentiation of traffic flows for uplink transmission
CN110337150B (zh) * 2014-04-21 2023-06-27 华为技术有限公司 承载控制方法及系统
CN105491557B (zh) * 2014-09-15 2020-04-21 中兴通讯股份有限公司 一种实现能力开放的系统、方法及能力开放平台
KR102628626B1 (ko) * 2015-08-07 2024-01-25 삼성전자 주식회사 단말 및 그 통신 방법
AU2016336442B2 (en) * 2015-10-06 2019-04-04 Kodiak Networks Inc. System and method for tuning PTT over LTE
US10277515B2 (en) 2016-04-04 2019-04-30 Qualcomm Incorporated Quality of service (QOS) management in wireless networks

Also Published As

Publication number Publication date
TW201737747A (zh) 2017-10-16
CN113452626B (zh) 2022-03-25
US10277515B2 (en) 2019-04-30
KR20190088576A (ko) 2019-07-26
SG11201807205XA (en) 2018-10-30
CN108781381B (zh) 2021-08-06
KR20180125151A (ko) 2018-11-22
EP3562202B1 (en) 2021-08-25
EP3440868A1 (en) 2019-02-13
ES2893238T3 (es) 2022-02-08
AU2017247128A1 (en) 2018-09-13
BR112018070319A2 (pt) 2019-01-29
EP3562202A1 (en) 2019-10-30
US20170289046A1 (en) 2017-10-05
KR102038792B1 (ko) 2019-10-30
US10645007B2 (en) 2020-05-05
CN108781381A (zh) 2018-11-09
EP3440868B1 (en) 2020-05-06
TWI730059B (zh) 2021-06-11
WO2017176399A1 (en) 2017-10-12
KR102177090B1 (ko) 2020-11-10
CN113452626A (zh) 2021-09-28
AU2017247128B2 (en) 2021-07-22
CA3016549A1 (en) 2017-10-12
US20190020590A1 (en) 2019-01-17
SG10202013154PA (en) 2021-02-25

Similar Documents

Publication Publication Date Title
ES2810866T3 (es) Gestión de calidad de servicio (QoS) en redes inalámbricas
ES2806373T3 (es) Funcionamiento conjunto con tecnologías de acceso por radio heredadas para conectividad con redes centrales de próxima generación
JP6819804B2 (ja) 無線端末、第２のコアネットワークノード、及びこれらの方法
JP6689336B2 (ja) 装置、コアネットワークノードおよび通信システム
US11510258B2 (en) Direct user equipment to user equipment without data network access identifier
US10321496B2 (en) Inter-PGW handover architecture
US11228560B2 (en) Mobility functionality for a cloud-based access system
KR102469973B1 (ko) 통신 방법 및 장치
BR112017006490B1 (pt) Método para comunicações com base em rede cêntrica de informação,estação base, e, dispositivo sem fio
JPWO2018029932A1 (ja) 無線アクセスネットワークノード、無線端末、及びこれらの方法
US11546805B2 (en) Time sensitive communications between user equipment
US11576219B2 (en) User equipment, control apparatus, and communication control method