ES2829581T3 - Procedimiento y aparato para proporcionar el flujo de calidad de servicio (QOS) en un sistema de comunicación inalámbrica - Google Patents

Abstract

Un procedimiento de un nodo de red, que comprende: transmitir un primer mensaje con una configuración de portador de radio de datos, DRB, a un equipo de usuario, UE, para establecer un DRB predeterminado para una sesión de unidad de datos de protocolo, PDU, en el que la configuración del DRB incluye una configuración de ID de flujo QoS, QFI, usada indicar si un campo QFI está presente o no en el enlace ascendente para el DRB predeterminado y la configuración de QFI siempre se establece en un valor que indica que el campo QFI está presente en el enlace ascendente para el DRB predeterminado (1205); establecer el DRB predeterminado con la presencia del campo QFI en el enlace ascendente (1210); y recibir una PDU de protocolo de adaptación de datos de servicio, SDAP, con el campo QFI a través del DRB predeterminado del UE (1215).

Description

DESCRIPCIÓN

Procedimiento y aparato para proporcionar el flujo de calidad de servicio (QOS) en un sistema de comunicación inalámbrica

Esta divulgación generalmente hace referencia a las redes de comunicación inalámbrica, y más particularmente, a un procedimiento y aparato para proporcionar el flujo QOS en un sistema de comunicación inalámbrica.

Con el aumento rápido de la demanda de la comunicación de grandes cantidades de datos a y desde dispositivos de comunicación móvil, las redes móviles tradicionales de comunicación de voz evolucionan a redes que se comunican con paquetes de datos de Protocolo de Internet (IP). Tal comunicación de paquetes de datos de IP puede proporcionar servicios de comunicación de voz sobre IP, multimedia, multidifusión y servicios de comunicación bajo demanda a los usuarios de dispositivos de comunicación móvil.

Una estructura de red ilustrativa es una Red de Acceso de Radio Terrestre Universal Evolucionada (E-UTRAN). El sistema E-UTRAN puede proporcionar un alto flujo de datos para realizar los servicios de voz sobre IP y multimedia mencionados anteriormente. Una nueva tecnología de radio para la próxima generación (por ejemplo, 5G) se discute actualmente por la organización de estándares 3GPP. En consecuencia, los cambios al cuerpo actual del estándar 3GPP se presentan y consideran actualmente para evolucionar y finalizar con el estándar 3GPP.

CONVIDA WIRELESS en el "Formato de encabezado SDAP", 3GPP DRAFT, R2-1707351, analiza el formato de encabezado del Protocolo de adaptación de datos de servicio (SDAP) para el propósito de QoS reflectante NAS o QoS reflectante AS.

Sumario

Los métodos y aparatos se divulgan desde la perspectiva de un nodo de red y se definen en las reivindicaciones independientes adjuntas. Las reivindicaciones dependientes adjuntas definen las realizaciones preferentes de las mismas. En una realización, el procedimiento incluye que el nodo de red transmita un primer mensaje con una configuración de DRB (Portador de radio de datos) a un UE (Equipo de usuario) para establecer un DRB predeterminado para una sesión de PDU (Unidad de datos de protocolo), en el que la configuración DRB incluye una configuración ^q Fⁱ (ID de flujo QoS) usada para indicar si un campo QFI está presente o no en el enlace ascendente para el DRB predeterminado y la configuración QFI siempre se establece en un valor que indica que el campo QFI está presente en el enlace ascendente para el DRB predeterminado. El procedimiento incluye además el nodo de red que establece el DRB predeterminado con una presencia del campo QFI en el enlace ascendente. El procedimiento también incluye el nodo de red que recibe una PDU del SDAP (Protocolo de adaptación de datos de servicio) con el campo QFI a través del DRB predeterminado del UE.

Breve descripción de los dibujos

La Figura 1 muestra un diagrama de un sistema de comunicación inalámbrica de acuerdo con una realización ilustrativa.

La Figura 2 es un diagrama de bloques de un sistema transmisor (conocido además como red de acceso) y un sistema receptor (conocido además como equipo de usuario o UE) de acuerdo con una realización ilustrativa. La Figura 3 es un diagrama de bloques funcionales de un sistema de comunicación de acuerdo con una realización ilustrativa.

La Figura 4 es un diagrama de bloques funcionales del código del programa de la Figura 3 de acuerdo con una realización ilustrativa.

La Figura 5 es una reproducción de la Figura 12-1 del 3GPP TS 38.300 v0.4.1.

La Figura 6 es una reproducción de la Figura A.6-1 del 3GPP TS 38.300 v0.4.1.

La Figura 7 es una reproducción de la Figura 5.7.1-1 del TS 23.501 v1.0.0.

La Figura 8 es la reproducción de la Figura 1 de 3GPP R2-1707159.

La Figura 9 es la reproducción de la Figura 2 de 3GPP R2-1707159.

La Figura 10 es la reproducción de la Figura 3 de 3GPP R2-1707159.

La Figura 11 es la reproducción de la Figura 4 de 3GPP R2-1707159.

La Figura 12 es un diagrama de flujo de acuerdo con una realización ilustrativa.

La Figura 13 es un diagrama de flujo de acuerdo con un ejemplo útil para comprender la invención.

La Figura 14 es un diagrama de flujo de acuerdo con un ejemplo útil para comprender la invención.

Descripción detallada

Los sistemas y dispositivos de comunicación inalámbrica ilustrativos descritos más abajo emplean un sistema de comunicación inalámbrica, que soporta un servicio de difusión. Los sistemas de comunicación inalámbrica se implementan ampliamente para proporcionar diversos tipos de comunicación tales como voz, datos, y semejantes. Estos sistemas pueden basarse en acceso múltiple por división de código (CDMA), acceso múltiple por división de tiempo (TDMA), acceso múltiple por división de frecuencia ortogonal (OFDMA), acceso inalámbrico 3GPP LTE (Evolución a largo plazo), 3GPP LTE-A o LTE-Advanced (Evolución a largo plazo avanzada), 3GPP2 UMB (Banda ancha ultra móvil), WiMax, o algunas otras técnicas de modulación.

En particular, los dispositivos de sistemas de comunicación inalámbrica ilustrativos que se describen a continuación pueden diseñarse para soportar uno o más estándares, como el estándar ofrecido por un consorcio llamado "Proyecto de Asociación de 3ra Generación" denominado en la presente memoria 3GPP, que incluye: TS 38.300 v0.4.1, "NR; NR y NG-RAN Overall Description; Stage 2"; TS 23.501 v1.0.0, "System Architecture for the 5G System; Stage 2"; R2-1707159, "SDAP Header Format", Ericsson; R2-1707160, "Reflective QoS and Presence of Flow-ID", Ericsson; R2-1707161, "QoS Flow Remapping Within the Same Cell and in Handover", Ericsson; S2-170065, "Discussion on Reflective QoS activation using C-plane and U-plane", Huawei y HiSilicon; Nota del presidente de la reunión 3GPP RAN2#98; 3GPP RAN2 NR Nota del presidente de la reunión Ad Hoc#2; TS 38.323 v0.0.5, "NR; Packet Data Convergence Protocol (PDCP) specification"; Discusión por correo electrónico 3GPP [NR-AH2#08] [NR UP] En ejecución anexo TS 37.324 "Draft 37324-010-v1.doc"; R2-1705780, "QoS flow ID in AS Reflective QoS", CMCC; R2-1704648, "Discussion on reflective QoS", ZTE; R2-1704649, "Discussion on the SDAP PDU format", ZTE; TS 23.401 v14.0.0, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".

La Figura 1 muestra un sistema de comunicación inalámbrica de acceso múltiple. Una red de acceso 100 (AN) incluye grupos de antenas múltiples, uno que incluye 104 y 106, otro que incluye 108 y 110, y un adicional que incluye 112 y 114. En la Figura 1, sólo se muestran dos antenas para cada grupo de antenas, sin embargo, pueden usarse más o menos antenas para cada grupo de antenas. El terminal de acceso 116 (AT) está en comunicación con las antenas 112 y 114, donde las antenas 112 y 114 transmiten información al terminal de acceso 116 a través del enlace delantero 120 y reciben información desde el terminal de acceso 116 a través del enlace inverso 118. El terminal de acceso (AT) 122 está en comunicación con las antenas 106 y 108, donde las antenas 106 y 108 transmiten información al terminal de acceso (AT) 122 a través del enlace directo 126 y reciben información desde el terminal de acceso (AT) 122 a través del enlace inverso 124. En un sistema FDD, los enlaces de comunicación 118, 120, 124 y 126 pueden usar la frecuencia diferente para la comunicación. Por ejemplo, el enlace directo 120 puede usar una frecuencia diferente entonces a la usada por el enlace inverso 118.

Cada grupo de antenas y/o el área en donde se diseñan para comunicarse se refiere a menudo como un sector de la red de acceso. Cada grupo de antenas se diseña para comunicarse con terminales de acceso en un sector de las áreas cubiertas por la red de acceso 100.

En la comunicación a través de los enlaces directos 120 y 126, las antenas de transmisión de la red de acceso 100 pueden usar la formación de haz para mejorar la relación señal-ruido de los enlaces directos para los terminales de acceso 116 y 122 diferentes. Además, una red de acceso que usa la formación de haz para transmitir a terminales de acceso dispersados aleatoriamente a través de su cobertura provoca menos interferencia a los terminales de acceso en las celdas vecinas que una red de acceso que transmite a través de una sola antena a todos sus terminales de acceso.

Una red de acceso (AN) puede ser una estación fija o estación base usada para comunicarse con las terminales y también puede denominarse punto de acceso, un Nodo B, una estación base, una estación base mejorada, un Nodo B evolucionado (eNB), un Nodo B de próxima generación o alguna otra terminología. Un terminal de acceso (AT) puede denominarse además un equipo de usuario (UE), un dispositivo de comunicación inalámbrica, un terminal, un terminal de acceso o alguna otra terminología.

La Figura 2 es un diagrama de bloques simplificado de un sistema transmisor 210 (conocido además como la red de acceso) y un sistema receptor 250 (conocido además como terminal de acceso (AT) o equipo de usuario (UE)) en un sistema MIMO 200. En el sistema transmisor 210, los datos de tráfico para un número de hilos de datos se proporciona desde una fuente de datos 212 a un procesador de datos de transmisión (TX) 214.

Preferentemente, cada hilo de datos se transmite a través de una antena de transmisión respectiva. El procesador de datos TX 214 formatea, codifica, e intercala los datos de tráfico para cada hilo de datos en base a un esquema de codificación particular seleccionado para ese hilo de datos para proporcionar los datos codificados.

Los datos codificados para cada hilo de datos pueden multiplexarse con el dato piloto mediante el uso de técnicas OFDM. El dato piloto es típicamente un patrón de datos conocido que se procesa de manera conocida y puede usarse en el sistema receptor para estimar la respuesta del canal. El piloto multiplexado y los datos codificados para cada hilo de datos se modulan (es decir, se asignan símbolos) en base a un esquema de modulación particular (por ejemplo, BPSK, QPSK, M-PSK o M-QAM) que se selecciona para ese hilo de datos para proporcionar símbolos de modulación. La velocidad de datos, codificación y modulación para cada hilo de datos puede determinarse mediante instrucciones realizadas por el procesador 230.

Los símbolos de modulación para todos los flujos de datos entonces se proporcionan a un procesador TX MIMO 220, que puede procesar además los símbolos de modulación (por ejemplo, para OFDM). El procesador TX MIMO 220 entonces proporciona N^t secuencias de símbolos de modulación para N^t transmisores (TMTR) 222a al 222t. En ciertas realizaciones, el procesador TX MIMO 220 aplica los pesos de la formación de haz a los símbolos de los hilos de datos y a la antena desde la que se transmite el símbolo.

Cada transmisor 222 recibe y procesa una secuencia de símbolos respectiva para proporcionar una o más señales analógicas, y condiciona además (por ejemplo, amplifica, filtra, y convierte hacia arriba) las señales analógicas para proporcionar una señal modulada adecuada para la transmisión a través del canal MIMO. Las señales moduladas N^t desde los transmisores 222a al 222t entonces se transmiten desde las antenas N^t 224a a la 224t, respectivamente. En el sistema receptor 250, las señales moduladas transmitidas se reciben por las antenas N^r 252a a la 252r y la señal recibida desde cada antena 252 se proporciona a un receptor (RCVR) respectivo 254a al 254r. Cada receptor 254 condiciona (por ejemplo, filtra, amplifica y convierte hacia abajo) una señal recibida respectiva, digitaliza la señal condicionada para proporcionar muestras, y procesa además las muestras para proporcionar una secuencia de símbolos "recibida" correspondiente.

Un procesador de datos RX 260 entonces recibe y procesa las secuencias de símbolos recibidas N^r desde los receptores N^r 254 en base a una técnica de procesamiento del receptor particular para proporcionar las secuencias de símbolos "detectadas" N^t. El procesador de datos RX 260 entonces demodula, desintercala, y decodifica cada hilo de símbolos detectado para recuperar el dato de tráfico para el hilo de datos. El procesamiento por el procesador de datos RX 260 es complementario al realizado por el procesador TX MIMO 220 y el procesador de datos TX 214 en el sistema transmisor 210.

Un procesador 270 determina periódicamente qué matriz de codificación previa usar (discutido más abajo). El procesador 270 formula un mensaje de enlace inverso comprendiendo una porción de índice de matriz y una porción de valor de intervalo.

El mensaje de enlace inverso puede comprender diversos tipos de información respecto al enlace de comunicación y/o el hilo de datos recibido. El mensaje de enlace inverso entonces se procesa por un procesador de datos TX 238, que recibe además el dato de tráfico para un número de hilos de datos desde una fuente de datos 236, modulados por un modulador 280, condicionados por los transmisores 254a al 254r, y transmitidos de vuelta al sistema transmisor 210.

En el sistema transmisor 210, las señales moduladas desde el sistema receptor 250 se reciben por las antenas 224, se condicionan por los receptores 222, se demodulan por un demodulador 240, y se procesan por un procesador de datos RX 242 para extraer el mensaje de enlace de reserva transmitido por el sistema receptor 250. El procesador 230 entonces determina qué matriz de codificación previa usar para determinar los pesos de la formación de haz entonces procesa el mensaje extraído.

Al regresar a la Figura 3, esta figura muestra un diagrama de bloques funcionales simplificado alternativo de un dispositivo de comunicación. Como se muestra en la Figura 3, el dispositivo de comunicación 300 en un sistema de comunicación inalámbrica puede usarse para realizar los UE (o AT) 116 y 122 en la Figura 1 o la estación base (o AN) 100 en la Figura 1, y el sistema de comunicaciones inalámbricas es preferentemente el sistema LTE. El dispositivo de comunicación 300 puede incluir un dispositivo de entrada 302, un dispositivo de salida 304, un circuito de control 306, una unidad de procesamiento central (CPU) 308, una memoria 310, un código de programa 312, y un transceptor 314. El circuito de control 306 ejecuta el código de programa 312 en la memoria 310 a través de la CPU 308, que controla de esta manera un funcionamiento del dispositivo de comunicaciones 300. El dispositivo de comunicaciones 300 puede recibir señales introducidas por un usuario a través del dispositivo de entrada 302, tal como un teclado o teclado numérico, y puede emitir imágenes y sonidos a través del dispositivo de salida 304, tal como un monitor o altavoces. El transceptor 314 se usa para recibir y transmitir señales inalámbricas, que entrega señales recibidas al circuito de control 306, y que emite señales generadas por el circuito de control 306 de forma inalámbrica. El dispositivo de comunicación 300 en un sistema de comunicación inalámbrica puede usarse además para realizar la AN 100 en la Figura 1.

La Figura 4 es un diagrama de bloques simplificado del código de programa 312 mostrado en la Figura 3. El código de programa 312 incluye una capa de aplicación 400, una porción 402 de Capa 3 y una porción 404 de Capa 2, y está acoplada a una porción 406 de Capa 1. La porción de la Capa 3 402 realiza generalmente el control de recursos de radio. La porción de la Capa 2404 realiza generalmente el control de enlace. La porción de la Capa 1 406 realiza generalmente las conexiones físicas.

La 3GPP TS38.300 describió la capa SDAP (Protocolo de adaptación de datos de servicio) y QoS de la siguiente manera:

6.5 Subcapa SDAP

Los principales servicios y funciones de SDAP incluyen:

- Mapeo entre un flujo QoS y un portador de radio de datos;

- Marcado de ID de flujo QoS (QFI) en paquetes DL y UL.

Se configura una única entidad de protocolo de SDAP para cada sesión de PDU individual, excepto para DC, donde se pueden configurar dos entidades (una para MCG y otra para SCG; véase la subcláusula 12).

12 QoS

La arquitectura de QoS en NG-RAN se muestra en la Figura 13-1 y se describe a continuación:

- Para cada UE, 5GC establece una o más sesiones de PDU.

- Para cada UE, la NG-RAN establece uno o más Portadores de Radio de Datos (DRB) por Sesión de PDU. El NG-NG-RAN mapea paquetes que pertenecen a diferentes sesiones de PDU a diferentes DRB. Por tanto, la NG-RAN establece al menos un DRB por defecto para cada sesión de PDU indicada por 5GC al establecer la sesión de PDU.

- Los filtros de paquetes de nivel NAS en el UE y en el 5GC asocian los paquetes UL y DL con los flujos QoS. - El mapeo de nivel AS en el UE y en la NG-RAN asocia los flujos QoS UL y DL con DRB.

[La Figura 12-1 de 3GPP TS 38.300 v0.4.1, titulada "Arquitectura QoS", se reproduce como Figura 5] El NG-RAN y el 5GC aseguran la calidad del servicio (por ejemplo, confiabilidad y retardo de destino) al mapear paquetes a los flujos QoS y DRB apropiados. Por lo tanto, existe un mapeo de 2 etapas de los flujos de IP a los flujos QoS (NAS) y de los flujos QoS a los DRB (Access Stratum).

En el NG-RAN, el portador de radio de datos (DRB) define el tratamiento del paquete en la interfaz de radio (Uu). Un DRB sirve paquetes con el mismo tratamiento de reenvío de paquetes. Se pueden establecer DRB separados para los flujos QoS que requieren un tratamiento de reenvío de paquetes diferente. En el enlace descendente, NG-RAN mapea los flujos QoS a los DRB en base al marcado NG-U (ID de flujo QoS) y los perfiles de QoS asociados. En el enlace ascendente, el UE marca los paquetes del enlace ascendente sobre Uu con el QFI con el fin de marcar los paquetes reenviados al CN.

En el enlace ascendente, NG-RAN puede controlar el mapeo de los flujos QoS al DRB de dos formas diferentes: - Mapeo reflectante: para cada DRB, el UE supervisa los QFI de los paquetes de enlace descendente y aplica el mismo mapeo en el enlace ascendente; es decir, para un DRB, el UE mapea los paquetes de enlace ascendente que pertenecen a los flujos QoS correspondientes a los QFI y la sesión de PDU observadas en los paquetes de enlace descendente para ese DRB. Para habilitar este mapeo reflectante, NG-RAN marca los paquetes de enlace descendente sobre Uu con QFI.

Es FFS si el marcado con un QFI se puede configurar de forma semiestática (para no incluir el ID de flujo QOS cuando no sea necesario).

- Configuración explícita: además del mapeo reflectante, la NG-RAN puede configurar por RRC un enlace ascendente "Mapeo de flujo QoS a DRB".

La precedencia del mapeo configurado de RRC y la QoS reflectante es FFS (¿se puede actualizar la QoS reflectante y así anular un mapeo configurado de RRC? ¿O un ID de flujo QoS configurado al mapeo de DRB siempre tiene prioridad sobre un mapeo reflectante?)

Si un paquete UL entrante no coincide ni con un RRC configurado ni con un "ID de flujo QoS al mapeo de DRB" reflectante, el UE mapeará ese paquete con el DRB por defecto de la sesión de PDU.

Dentro de cada sesión de PDU, depende de NG-RAN cómo mapear múltiples flujos QoS a un DRB. El NG-RAN puede mapear un flujo GBR y un flujo que no es GBR, o más de un flujo GBR al mismo DRB, pero los mecanismos para optimizar estos casos no están dentro del ámbito de la estandarización. El momento de establecer los DRB no predeterminados entre NG-RAN y UE para el flujo QoS configurado durante el establecimiento de una sesión de PDU puede ser diferente del momento en que se establece la sesión de PDU. Depende de NG-RAN cuando se establecen DRB no predeterminados.

En DC, los flujos QoS que pertenecen a la misma sesión de PDU pueden mapeados con diferentes tipos de portadores (ver subcláusula 4.5.2) y, como resultado, puede haber dos entidades SDAP diferentes configuradas para la misma sesión de PDU: una para MCG y otra para SCG (por ejemplo, cuando un portador MCG y un portador SCG se usan para dos flujos QoS diferentes).

El soporte para la sesión de PDU mapeada a diferentes portadores está pendiente de conclusiones en SA2 y RAN3.

Anexo A (informativo):

Manejo de QoS en RAN

Cuándo y si incluir el QFI en su totalidad o en forma abreviada y el RQI en SDAP es FFS.

Todos los nombres y parámetros de los mensajes son FFS.

Estos reflejan el estado actual y es posible que deban actualizarse en base a otras decisiones.

A.6 Flujo QoS UL iniciado por UE

La siguiente Figura muestra un ejemplo de flujo de mensajes cuando el UE AS recibe un paquete UL para un nuevo flujo QoS para el que no existe un QFI para el DRB.

[Figura A.6-1 de 3GPP TS 38.300 v0.4.1, titulada "Paquete UL con un nuevo flujo QoS para el que no existe un mapeo en UE", se reproduce como la Figura 6]

0. La sesión de PDU y los DRB (incluido un DRB predeterminado) ya se han establecido.

1. El UE AS recibe un paquete con un nuevo QFI de UE NAS.

2. El UE usa el QFI del paquete para mapearlo a un DRB. Si no hay un mapeo del QFI a un DRB en la tabla de mapeo AS para esta sesión de PDU, entonces el paquete se asigna al DRB predeterminado.

3. El UE envía el paquete en el DRB predeterminado. El UE incluye el q Fi en el encabezado SDAP si se ha configurado SDAP para este DRB.

4. gNB envía paquetes UL por NG-U e incluye el QFI correspondiente.

5. Si gNB desea usar un nuevo DRB para este flujo QoS, configura un DRB. También puede optar por mover el flujo QoS a un DRB existente mediante el uso de la señalización RRC o los procedimientos de mapeo reflectante AS descritos anteriormente. Los detalles de esto se muestran en la Figura X.2-1 y la Figura X.3-1.

6. Los paquetes UL recibidos en UE AS con QFI se envían a través del DRB decidido por la tabla de mapeo de QFI a DRB. Si se configura en la etapa 5, los paquetes de datos de UL incluyen una marca de QoS (igual o correspondiente a QFI) en el encabezado SDAP.

La 3GPP TS 23.501 modelo de QoS especificado para NR (New RAT/Radio) de la siguiente manera:

5.7 modelo QoS

5.7.1 Descripción general

El modelo QoS 5G admite un marco basado en flujo QoS. El modelo QoS 5G admite tanto los flujos QoS que requieren una tasa de flujo de bits garantizada como los flujos QoS que no requieren una tasa de flujo de bits garantizada. El modelo QoS 5G también admite QoS reflectante (consulte la cláusula 5.7.5).

El flujo QoS es la mejor granularidad de diferenciación de QoS en la sesión de PDU. Un ID de flujo QoS (QFI) se usa para identificar un flujo QoS en el sistema 5G. El tráfico del plano de usuario con el mismo QFI dentro de una sesión de PDU recibe el mismo tratamiento de reenvío de tráfico (por ejemplo, programación, umbral de admisión). El QFI se transporta en un encabezado de encapsulación en N3 (y N9), es decir, sin ningún cambio en el encabezado del paquete e2e. Puede aplicarse a los PDU con diferentes tipos de carga útil, es decir, paquetes IP, PDU no estructuradas y tramas Ethernet. El QFI será único dentro de una sesión de PDU.

NOTA 1: La vigilancia del tráfico del plano de usuario (por ejemplo, la imposición de MFBR) no se considera una diferenciación de QoS y la realizan las UPF en un nivel de granularidad SDF.

Cada flujo QoS (GBR y no GBR) está asociado con los siguientes parámetros de QoS (los detalles de los parámetros se describen en la cláusula 5.7.2):

- Indicador de QoS 5G (5QI).

- Prioridad de asignación y retención (ARP).

Cada flujo QoS de GBR está asociado además con los siguientes parámetros de QoS (los detalles se describen en la cláusula 5.7.2):

- Tasa de bits de flujo garantizada (GFBR): UL y DL;

- Tasa máxima de bits de flujo (MFBR): UL y DL;

- Control de notificaciones.

Cada flujo QoS no GBR puede además estar asociado con el siguiente parámetro de QoS (los detalles se describen en la cláusula 5.7.2):

- Atributo de QoS reflectante (RQA).

Se admiten dos formas de controlar los flujos QoS:

1) Para los flujos QoS no GBR con 5QI estandarizados, el valor de 5QI se usa como QFI como se define en la cláusula 5.7.4 y se usa un ARP predeterminado. En este caso, no se requiere señalización N2 adicional en el momento en que comienza el tráfico para los flujos QoS correspondientes; o

2) Para los flujos QoS GBR y no GBR, todos los parámetros de QoS necesarios correspondientes a una QFI se envían como perfil de QoS a (R)AN, UPF en el establecimiento de sesión de PDU o en el establecimiento/modificación del flujo QoS.

Nota del editor: Ya sea más allá de los 5QI estandarizados, también los valores de 5QI pre configurados pueden usarse más como valores de QFI es FFS.

Los parámetros de QoS de un flujo QoS se proporcionan al (R)AN como un perfil de QoS sobre N2 en la sesión de PDU o en el establecimiento del flujo QoS y cuando se usa NG-RAN cada vez que se activa el plano de usuario. Los parámetros de QoS también se pueden preconfigurar en el (R)AN para flujos QoS que no son GBR (es decir, sin necesidad de señalizarlos a través de N2).

El UE realiza la clasificación y marcado del tráfico del plano de usuario de UL, es decir, la asociación del tráfico de enlace ascendente a los flujos QoS, en base a las reglas de QoS. Estas reglas pueden ser señalizadas explícitamente a través de N1 (en el establecimiento de sesión de PDU o establecimiento de flujo QoS), pre configuradas en el UE o derivadas implícitamente por UE de QoS reflectante. Una regla de QoS contiene un identificador de regla de QoS, el QFI del flujo QoS, uno o más filtros de paquetes y un valor de precedencia. Puede haber más de una regla de QoS asociada con el mismo QFI (es decir, con el mismo flujo QoS).

Se requiere una regla de QoS predeterminada para cada sesión de PDU. La regla de QoS predeterminada es la única regla de QoS de una sesión de PDU que puede no contener ningún filtro de paquetes (en este caso, se debe usar el valor de precedencia más alto (es decir, la prioridad más baja)). Si la regla de QoS predeterminada no contiene un filtro de paquetes, la regla de QoS predeterminada define el tratamiento de los paquetes que no coinciden con ninguna otra regla de QoS en una sesión de PDU.

Nota del editor: Es FFS si existe, además, la necesidad de que se proporcionen al UE reglas de QoS autorizadas previamente.

El SMF asigna el QFI para cada flujo QoS y deriva sus parámetros de QoS de la información proporcionada por el PCF. Cuando es aplicable, la SMF proporciona el QFI junto con el perfil de QoS que contiene los parámetros de QoS de un flujo QoS al (R)AN. La SMF proporciona la plantilla SDF (es decir, el conjunto de filtros de paquetes asociados con la SDF recibida de la PCF) junto con la precedencia SDF y la QFI correspondiente a la UPF que permite la clasificación y el marcado del tráfico del plano de usuario. Cuando corresponda, el SMF genera la(s) regla(s) de QoS para la sesión de PDU asignando identificadores de regla de QoS, agregando el QFI del flujo QoS, configurando los filtros de paquetes en la parte UL de la plantilla SDF y configurando la regla de QoS precedencia a la precedencia SDF. A continuación, las reglas de QoS se proporcionan al UE, lo que permite la clasificación y el marcado del tráfico del plano de usuario de UL.

Nota del editor: Algunas aplicaciones, por ejemplo, IMS, requieren también la parte DL de la plantilla SDF en la regla de QoS. Si el DL de la plantilla SDF debe enviarse para cada regla de QoS es FFS.

En la Figura 5.7.1-1 se ilustra el principio de clasificación y marcado del tráfico del plano de usuario y la correspondencia de los flujos QoS con los recursos de AN.

[La Figura 5.7.1-1 de TS 23.501 v1.0.0, titulada "El principio de clasificación y marcado del plano de usuario para flujos QoS y mapeo a recursos AN", se reproduce en la Figura 7]

En los paquetes de datos entrantes de DL, se clasifican en base a plantillas SDF de acuerdo con su precedencia SDF (sin iniciar señalización N4 adicional). La CN transmite la clasificación del tráfico del plano de usuario que pertenece a un flujo QoS a través de una marca de plano de usuario N3 (y N9) mediante el uso de un QFI. La AN vincula los flujos QoS a los recursos de la AN (es decir, portadores de radio de datos en el caso de 3GPP RAN). No existe una relación estricta de 1:1 entre los flujos QoS y los recursos de AN. Depende de la AN establecer los recursos de AN necesarios para hacer corresponder los flujos QoS con los DRB de modo que el UE reciba la QFI (y se pueda aplicar los QoS reflectantes (véase la cláusula 5.7.5)).

En UL, el UE evalúa los paquetes UL contra los filtros de paquetes en las reglas de QoS en base al valor de precedencia de las reglas de QoS en orden creciente hasta que se encuentra una regla de QoS coincidente (es decir, cuyo filtro de paquetes coincide con el paquete UL). El UE usa el QFI en la regla de QoS correspondiente para vincular el paquete UL a un flujo QoS. A continuación, el UE vincula los flujos QoS a los recursos de AN.

Si no se encuentra ninguna coincidencia y la regla de QoS predeterminada contiene uno o más filtros de paquetes de enlace ascendente, el UE descartará el paquete de datos de enlace ascendente.

Las siguientes características se aplican al procesamiento del tráfico de enlace descendente:

- La UPF asigna el tráfico del plano de usuario a los flujos QoS en base a las plantillas SDF

- La UPF realiza la aplicación Session-AMBR y también realiza el recuento de PDU para soportar la tarificación. - La UPF transmite las PDU de la sesión de la PDU en un solo túnel entre 5GC y (R)AN, la UPF incluye la QFI en el encabezado de encapsulación. Además, la UPF puede incluir una indicación de activación de QoS reflectante en el encabezado de encapsulación.

- La UPF realiza el marcado de paquetes a nivel de transporte en el enlace descendente, por ejemplo, configurando el punto de código DiffServ en el encabezado IP externo. El marcado de paquetes de nivel de transporte puede basarse en 5QI y ARP del flujo QoS asociado.

- (R)AN mapea las PDU de los flujos QoS a los recursos específicos de acceso en base al QFI y las características y parámetros asociados de QoS 5G, también teniendo en cuenta el túnel N3 asociado con el paquete de enlace descendente.

NOTA 2: Los filtros de paquetes no se usan para vincular flujos QoS a recursos específicos de acceso en (R)AN.

- Si se aplica QoS reflectante, el UE crea una nueva regla de QoS derivada. El filtro de paquetes en la regla de QoS derivada se deriva del (es decir, el encabezado del) paquete DL, y el QFI de la regla QoS derivada se establece de acuerdo con el QFI del paquete DL.

Las siguientes características se aplican para el procesamiento del tráfico de enlace ascendente:

- El UE usa las reglas de QoS almacenadas para determinar el mapeo entre el tráfico del Plano de Usuario UL y los flujos QoS. El UE transmite las UL PDU usando el recurso específico de acceso correspondiente para el flujo QoS en base al mapeo proporcionado por RAN.

- El (R)AN transmite las PDU por el túnel N3 hacia la UPF. Al pasar un paquete UL de (R)AN a CN, el (R)AN determina el valor QFI, que se incluye en el encabezado de encapsulación de la UL PDU, y selecciona el túnel N3.

- El (R)AN realiza el marcado de paquetes de nivel de transporte en el enlace ascendente, el marcado de paquetes de nivel de transporte puede basarse en el 5QI y ARP del flujo QoS asociado.

- La UPF verifica si las QFI en las UL PDU están alineadas con las reglas de QoS proporcionadas al UE o derivadas implícitamente por el UE (por ejemplo, en el caso de QoS reflectante).

- La UPF realiza la ejecución de Session-AMBR y el recuento de paquetes para cargar.

Para las sesiones de UL Classifier PDU, UL y DL Session-AMBR se aplicarán en la UPF que admite la funcionalidad UL Classifier. Además, la sesión DL-AMBR se aplicará por separado en cada UPF que termine la interfaz N6 (es decir, sin requerir interacción entre las UPF) (véase la cláusula 5.6.4).

Para las sesiones de PDU con múltiples hosts, UL y DL Session-AMBR se aplicarán en la UPF que soporta la funcionalidad de punto de ramificación. Además, la sesión DL-AMBR se aplicará por separado en cada UPF que termine la interfaz N6 (es decir, sin requerir interacción entre las UPF) (véase la cláusula 5.6.4).

NOTA 3: La sesión DL-AMBR se aplica en cada UPF que termina la interfaz N6 para reducir el transporte innecesario de tráfico que puede ser descartado por la UPF que realiza la funcionalidad UL Classifier/Branching Point debido a que la cantidad de tráfico de enlace descendente para la sesión PDU excede el DL. Sesión-AMBR. El (R)AN aplicará el límite Máx BitRate (UE-AMBR) en UL y DL por UE para flujos QoS no GBR. El UE realizará la limitación de la tasa de UL sobre la base de la sesión de la PDU para el tráfico no GBR mediante el uso de Session-AMBR, si el UE recibe un Session-AMBR.

La aplicación del límite de velocidad por sesión de PDU se aplica a los flujos que no requieren una tasa de bits de flujo garantizada. El MBR por SDF es obligatorio para los flujos QoS de g Br pero opcional para los flujos QoS que no son de GBR. El MBR se aplica en la UPF.

El control de QoS para las PDU no estructuradas se realiza en el nivel de sesión de la PDU. Cuando se configura una sesión de PDU para transferir PDU no estructuradas, el SMF proporciona el QFI que se aplicará a cualquier paquete de la sesión de PDU a la UPF y al UE.

Nota del editor: Si el control de QoS de nivel de flujo QoS es compatible con las PDU no estructuradas y de qué manera es FFS.

El documento 3GPP R2-1707159 discutió el formato de encabezado SDAP de la siguiente manera:

2.1 Modo transparente para SDAP

Como se acordó en la última reunión, hay casos en donde el encabezado SDAP no es necesario (por ejemplo, cuando se opera en modo LTE DC hacia EPC o cuando la red no tiene la intención de usar ningún mapeo reflectante). Cuando la red no configura el encabezado SDAP, se podría modelar esto de manera que la capa SDAP esté ausente. Sin embargo, esto hace que el protocolo tenga un aspecto diferente en función de la configuración de RRC. Por lo tanto, una solución más limpia es modelar la ausencia del encabezado SDAP como "modo transparente SDAP" como ya se hizo en varios otros protocolos 3GPP. De esta manera, SDAP siempre se puede dibujar sobre PDCP. Además, una SDU de PDCP es siempre una PDU del SDAP.

Propuesta 1 Cuando el RRC desconfigura el encabezado SDAP, esto se modela como modo transparente SDAP.

2.2 Formato de encabezado SDAP

En la reunión RAN297-bis, se tomó la decisión de incluir el ID de flujo en el encabezado SDAP y alinear el byte del encabezado. Sin embargo, la cuestión de la longitud del ID de flujo permanece abierta. Los tamaños posibles de ID de flujo van desde 7 bits hasta 16 bits cuando se supone que el encabezado SDAP es de uno o dos bytes y el valor QFI definido máximo en la tabla QFI definida por SA es 79 [1]. El intervalo de valores de ID de flujo con 7 bits ya debería ser suficiente, ya que permite que existan 128 flujos en una sesión de PDU. Tener un intervalo de ID de flujo más grande requiere que UE asigne más recursos para el mapeo de flujo a DRB.

Tabla 1: Arquitectura del sistema 3GPP TS23.501 para el sistema 5G, Stage2, V0.4.0 (2017-04)

En base a la entrada de SA2, se les dirá a los UE si un paquete DL requiere una actualización del mapeo de SDF a flujo de nivel NAS. Proponemos que haya una indicación de un bit en el encabezado DL. Cuando el bit se pone a 1, el UE indica al NAS que determinará y posiblemente actualizará el mapeo SDF-to-Flow en base al Flow-ID presente en el encabezado SDAP [2].

Propuesta 2 El encabezado SDAP DL incluye una indicación NAS-RQI de 1 bit que indica si el UE creará (o actualizará) una regla de QoS derivada del UE.

De manera similar, para NAS RQI, podría haber una indicación de bit AS RQI en el encabezado SDAP que indique si el UE creará o actualizará un flujo QoS a la correspondencia DRB. Tener la indicación NAS y AS RQI requeriría que el encabezado SDAP sea de 2 bytes suponiendo que una longitud de ID de flujo de 6 bits no sea suficiente. La Figura 1 muestra el encabezado cuando existen AS y NAS RQI en el encabezado. La longitud del ID de flujo está entre 7 y 16.

[La Figura 1 de 3GPP R2-1707159, titulada "Encabezado SDAP DL con ID de flujo de 8 bits, NAS-RQI, AS-RQI y campo reservado de 6 bits", se reproduce como la Figura 8]

Observación 1 En DL, cuando los campos NAS-RQI y AS-RQI están presentes y el ID de flujo es mayor que 7 bits, el encabezado SDAP crece a 2 bytes

Tener NAS-RQI y AS-RQI permite que el transmisor gNB omita el ID de flujo AS en el encabezado del enlace descendente cuando no se establecen ni el bit NAS RQI ni el bit AS RQI. Esto permitiría reducir el tamaño del encabezado a un octeto en todos los paquetes DL que no deberían activar ninguna actualización de filtro. Pero, por supuesto, también resultaría en un tamaño de encabezado SDAP variable. Dicho encabezado se presenta en la Figura 1.

[La Figura 2 de 3GPP R2-1707159, titulada "Encabezado SDAP DL con NAS-RQI de 1 bit, AS-RQI de 1 bit e ID de flujo omitidos (AS RQI = 0)", se reproduce como la Figura 9]

La variación de la longitud del encabezado en el encabezado SDAP y agrega complejidad cuando, por ejemplo, ROHC necesita identificar el punto de inicio del paquete IP en la capa PDCP.

Teniendo en cuenta que actualizar el mapeo de ID de flujo a DRB es significativamente más fácil que la actualización de los filtros NAS, no creemos que deba agregarse una indicación tan explícita. Sin esa indicación, una longitud de encabezado de un byte proporciona espacio para una longitud de ID de flujo de 7 bits.

Desde la perspectiva de mapeo de DRB a ID de flujo en UE, no es deseable tener un intervalo de ID de flujo más largo que el requerido, ya que se requiere UE para mantener la tabla de mapeo de flujo a DRB. El intervalo de 128 ID de flujo es suficiente para los casos de uso que existen actualmente [1].

El encabezado SDAP de enlace descendente resultante se muestra en la Figura 3.

[La Figura 3 de 3GPP R2-1707159, titulada "Encabezado SDAP DL con ID de flujo de 7 bits y NAS-RQI", se reproduce como la Figura 10]

Propuesta 3 El encabezado SDAP DL y UL contiene un ID de flujo de 7 bits

Para UL, el ID de flujo proporciona información al gNB desde la cual gNB puede observar la marca de QoS que se encuentra en el encabezado NG3 UL. No se requiere NAS-RQI. Por lo tanto, el encabezado UL resultante tiene un bit de reserva (R) para su uso posterior, como se muestra en la Figura 4.

[La Figura 4 de 3GPP R2-1707159, titulada "Encabezado SDAP UL cuando se usa ID de flujo de 7 bits", se reproduce como la Figura 11]

Propuesta 4 El encabezado SDAP UL tiene un bit de reserva (R) para uso posterior.

En la reunión anterior, algunas empresas propusieron tener PDU de control para la capa SDAP. La información transportada por la PDU de control estaría relacionada con el estado de uso de NAS y AS. Esta información se puede llevar con los métodos propuestos anteriormente. Además, la señalización RRC cubre las características de QoS, lo que haría que la información del elemento de control fuera redundante. Dado que la capa SDAP se usa actualmente solo con QoS y actualmente está estrechamente acoplada con la entidad PDCP, la PDU de control agregaría complejidad que puede no estar justificada con los beneficios. Además, el encabezado SDAP dinámico introduce complejidad en la implementación de ROHC, ya que ROCH debe conocer la posición del paquete IP. Alternativamente, tener un encabezado SDAP al final evitaría los problemas de ROCH pero introduciría el acoplamiento del encabezado SDAP con la información de longitud de la SDU de PDCP. Analizar desde el final con encabezados dinámicos crearía complejidad para el analizador del receptor, ya que el receptor necesitaría predecir la longitud del encabezado SDAP o indicar lo contrario.

Propuesta 5 Los encabezados de control no se introducen en la capa SDAP.

Propuesta 6 El encabezado SDAP se coloca al comienzo de la PDU.

El documento 3GPP R2-1707160 discutió la QoS reflectante y la presencia del ID de flujo de la siguiente manera: Presencia del encabezado SDAP e ID de flujo QoS

Para habilitar la QoS reflectante, la RAN marca los paquetes de enlace descendente sobre Uu con un ID de flujo QoS. El UE marca los paquetes de enlace ascendente sobre Uu con el ID de flujo QoS con el fin de marcar los paquetes reenviados a la CN.

RAN2-97bis acordó que ...

Los paquetes DL sobre Uu no están marcados con "ID de flujo" al menos en los casos donde el mapeo reflectante UL AS y la QoS reflectante NAS no están configurados para DRB.

El encabezado de la capa AS incluye el "ID de flujo" de UL en función de la configuración de la red

El documento RAN2-98 discutió el tema nuevamente y concluyó lo siguiente:

1. La ID del flujo QoS está presente una vez que la QoS reflectante de AS está activa. FFS si siempre está presente.

2. Se debe informar a gNB cuando se activa la QoS reflectante de la capa NAS (por ejemplo, se puede usar). La QoS reflectante de NAS se maneja mediante FFS y depende de cómo/cuándo se proporcionará.

3. RAN2 admitirá un modo en donde el encabezado SDAP no está presente y se configura por DRB. Si se configura, FFS cómo se manejan los diferentes campos.

Presencia dinámica del ID de flujo QoS

La viñeta 3 anterior implica que el eNB configura por RRC para cada DRB si el UE incluirá o no el encabezado SDAP en las SDU de PDCP de enlace ascendente y si el encabezado de SDAP está presente en las SDU de PDCP de DL. De acuerdo con la viñeta 1, debe discutirse más a fondo si el "ID de flujo QoS", una vez que se configura SDAP, "está siempre presente" o si puede estar presente solo de forma dinámica. Para lograr esto último, el encabezado SDAP necesitaría indicar con un bit la presencia del "ID de flujo QoS". Dado que tal indicación consumiría un bit en sí misma, no permitiría reducir el tamaño del encabezado SDAP por debajo de un octeto. Por lo tanto, consideramos que es más eficiente apuntar a un encabezado SDAP que tenga un tamaño fijo de un byte (si está configurado para estar presente por RRC).

Propuesta 1 Si el SDAP está configurado para un DRB mediante RRC, el "ID de flujo QoS" está presente en los paquetes UL y DL en ese DRB (no habilitado/deshabilitado dinámicamente).

Reconfiguración de la presencia del encabezado SDAP

Dado que el UE y la red deben saber en cualquier momento qué SDU de PDCP contienen un encabezado SDAP, la presencia de este encabezado solo debe cambiarse mediante una re configuración sincronizada, es decir, conexión/re configuración RRC que incluye información de control de movilidad. Cabe señalar que esto aún requiere que la entidad receptora de PDCP informe a la entidad SDAP para cada PDU PDCP entregada si el encabezado SDAP está presente. Si uno quisiera evitar eso, RAN2 debería restringir la configuración del encabezado SDAP a la configuración completa (fullConfig). Sin embargo, consideramos aceptable permitir habilitar/deshabilitar el encabezado SDAP durante un traspaso.

Propuesta 2 El eNB puede cambiar la presencia del encabezado SDAP sólo mediante un traspaso, es decir, una re configuración sincronizada.

Debido a la decisión de convertir SDAP en un protocolo separado por encima de PDCP, el compresor y descompresor RoHC (que se especifica que son parte de PDCP) ahora deben mirar en la PDU del SDAP y trabajar con SDAP SDU (el paquete IP). Si bien este no es un diseño agradable, creemos que con las dos propuestas anteriores tanto el UE como la red tienen toda la información necesaria para realizar RoHC.

Observación 1 En base a la configuración de RRC, las entidades de compresor y descompresor RoHC en el UE y en el lado de la red pueden determinar la posición del paquete IP dentro de cada PDU PDCP, es decir, si un encabezado SDAP está presente o no.

Conclusión

En base a la discusión en la sección 2, proponemos lo siguiente:

Propuesta 1 Si el SDAP está configurado para un DRB mediante RRC, el "ID de flujo QoS" está presente en los paquetes UL y DL en ese DRB (no habilitado/deshabilitado dinámicamente).

Propuesta 2 El eNB puede cambiar la presencia del encabezado SDAP sólo mediante un traspaso, es decir, una re configuración sincronizada.

Referencias

R2-1707159. Formato de encabezado SDAP. Ericsson, RAN2-98-AH, Qingdao, RP de China, 27-29 de junio de 2017

R2-1707161. QoS Flow Remapping Within the Same Cell and in Handover. Ericsson, RAN2-98-AH, Qingdao, RP de China, 27-29 de junio de 2017

Anexo: Acuerdos relacionados con QoS en reuniones anteriores

RAN2-95 discutió los principios básicos del marco NR QoS y alcanzó los siguientes acuerdos:

En RAN2-95bis se lograron algunos acuerdos adicionales y se resolvió el primero de los FFS anteriores:

RAN2#96:

> FFS si el campo QoS es agregado por PDCP o una nueva capa de protocolo por encima de PDCP.

RAN2 Ad-Hoc de enero de 2017:

RAN2-97 Atenas:

RAN2-97bis Spokane (abril de 2017)

El documento 3GPP R2-1707161 discutió la reasignación del flujo QoS dentro de la misma celda y en el traspaso de la siguiente manera:

2.1 Actualización del flujo QoS a filtros DRB

En RAN2-96 se discutió cómo la red puede cambiar un mapeo de flujos UL a DRB y RAN2 acordó que "El UE" supervisa de forma continua "el ID de flujo QoS en paquetes PDCP de enlace descendente y actualiza el ID de flujo QoS reflectante al mapeo de DRB en el enlace ascendente en consecuencia".

Las palabras "de forma continua" se ponen entre comillas porque las empresas querían estudiar si realmente todos y cada uno de los paquetes DL necesitaban ser analizados.

Creemos que esta es la forma más sencilla de permitir que el eNB actualice el mapeo redirigiendo los paquetes de un flujo de DL a un DRB diferente. Por ejemplo, si el UE observa inicialmente un paquete de enlace descendente con ID de flujo X en DRB 1, crea un filtro "Flujo a DRB" que mapea paquetes de enlace ascendente con ID de flujo X a DRB 1. Pero si el UE observa posteriormente un paquete de enlace descendente con ID de flujo X en DRB 2, debería cambiar el filtro para el flujo X de modo que también los paquetes UL se mapeen a DRB 2.

Mientras tanto, SA2 acordó sin embargo que el CN debería indicar dinámicamente en el encabezado del paquete N3 (plano de usuario) que el UE usará los encabezados de este paquete para crear o actualizar el mapeo de QoS reflectante del nivel NAS:

Tabla 1: Arquitectura del sistema 3GPP TS23.501 para el sistema 5G, Stage2, V0.3.1 (2017-03)

En base a la entrada de SA2 de que se les dirá a los UE si un paquete DL requiere una actualización del mapeo de SDF-to-flow de nivel NAS, sugerimos copiar esa indicación en el encabezado SDAP.

Propuesta 5 Si el bit NAS-RQI en un encabezado SDAP DL se establece en 1, el UE indica al NAS que determinará y posiblemente actualizará el mapeo SDF-a-Flujo en base al ID de flujo presente en el encabezado SDAP.

Hasta ahora, RAN2 asumió que el UE actualizará el mapeo de flujo a DRB de nivel AS en base a todos los paquetes DL recibidos que contienen un ID de flujo. Se podría considerar cambiar esto para que el UE actualice también el mapeo de nivel AS solo si se le indica explícitamente que lo haga. Sin embargo, para lograr esto, el encabezado SDAP necesitaría comprender un segundo bit que indique por separado pero de manera similar si el UE actualizará el mapeo de flujo a DRB mediante el uso del ID de flujo en el encabezado del paquete. Obviamente, esto solo dejaría 6 bits para el ID de flujo y, por lo tanto, probablemente conduciría a encabezados SDAP de 2 octetos si se considera que 6 bits son demasiado pequeños. Se puede encontrar más discusión sobre los posibles formatos de encabezado en 0. En ese artículo llegamos a la conclusión de que el ID de flujo en el encabezado SDAP debería ser de 7 bits.

Propuesta 6 La longitud del ID de flujo para DL y UL en el encabezado SDAP es de 7 bits.

Propuesta 7 Dado que el bit NAS-RQI solo se necesita en los encabezados DL SDAP, el encabezado SDAP Ul tiene un bit de reserva (R).

2.2 Reordenamiento de paquetes al reasignar el flujo QoS a otro DRB

Algunas empresas observaron en la última reunión que la reasignación de un flujo QoS a un DRB diferente puede provocar una entrega de paquetes fuera de secuencia. Esto puede suceder cuando los paquetes iniciales del flujo terminan en un DRB de baja prioridad y los paquetes subsiguientes se asignan a un DRB de alta prioridad debido a una asignación de flujo a d Rb actualizada. Estamos de acuerdo con esta observación, pero creemos que la red puede evitar esto al realizar el re-mapeo en una ocasión donde las colas están vacías. Sin embargo, puede que no siempre sea posible garantizar esto para la dirección del enlace ascendente. Pero al menos para la reasignación inicial de un DRB predeterminado a otro DRB, es probable que las capas superiores todavía estén en la fase de establecimiento de comunicación inicial (por ejemplo, TCP ^sYⁿ/SYN-ACK, configuración de seguridad TLS, HTTP GET) y, por lo tanto, normalmente habrá Serán muy pocos paquetes en vuelo que puedan adelantarse unos a otros.

Observación 2 Cuando el NW vuelve a mapear un flujo a un DRB diferente durante la fase de transacción inicial del flujo, es poco probable que se reordenen los paquetes debido a que hay pocos paquetes en vuelo.

Observación 3 Cuando el NW vuelve a mapear un flujo a un DRB diferente, puede minimizar el riesgo de reordenarlo posponiéndolo para ocasiones en donde los búferes están vacíos o al menos pequeños.

También se mencionó que el reordenamiento de paquetes en el re-mapeo del flujo podría evitarse mediante una función de reordenamiento adicional por flujo QoS (por encima de PDCP). Sin embargo, de acuerdo con las observaciones anteriores, no vemos la necesidad de una funcionalidad (compleja) en el lado de la UE.

Si RAN2 cree que el riesgo de reordenar paquetes en la reasignación de QoS-Flow (en dirección de enlace ascendente) es inaceptablemente grande, sugerimos buscar una solución relativamente simple como la siguiente: Al detectar una reasignación de un flujo a un DRB diferente (de forma reflectante o explícita), el transmisor PDCP copias todas las PDU PDCP aún no RLC-ACKed a la entidad PDCP del DRB de destino. Esto puede resultar en algunos duplicados, pero esos no importan para las capas superiores. Dado que de todos modos asumimos que normalmente habrá solo unos pocos paquetes en vuelo durante la fase inicial de una transferencia de archivos, la ineficacia debido a los (pocos) duplicados sería insignificante para la reasignación del QoS reflectante inicial descrita anteriormente. Por supuesto, el enfoque también evitaría reordenar a nivel de IP si la red re-mapea un flujo durante el traspaso.

Mover (en lugar de copiar) los datos a otro DRB evitaría la sobrecarga, pero requeriría volver a procesar las PDU PDCP ya procesadas previamente del DRB de origen.

Propuesta 8 La funcionalidad adicional del UE para evitar una posible entrega fuera de orden cuando se vuelve a mapear un flujo QoS a un DRB diferente (mediante señalización explícita o mediante la actualización de la asignación del QoS reflectante) no debe ser presentado. Propuesta 9 Si la Propuesta 8 no es aceptable (es decir, si RAN2 cree que se evitará el reordenamiento debido a la reasignación del flujo QoS), el transmisor PDCP copiará todas las PDU PDCP que aún no hayan recibido el RLC ACK a la entidad PDCP del DRB de destino.

2.3 Orden de precedencia del mapeo reflectante y configurado

RAN2-96 aún no está de acuerdo "La precedencia del mapeo configurado RRC y el QoS reflectante". Básicamente, hay tres opciones:

1) Un mapeo configurado por RRC anula cualquier mapeo reflectante para ese flujo.

2) Un mapeo reflectante recién derivado anula un mapeo configurado previamente por RRC.

3) El UE aplica siempre el mapeo más reciente, es decir, proporcionado por RRC o derivado por QoS reflectante

Creemos que la segunda opción introduciría una dependencia indeseable entre la configuración de RRC y el plano de usuario. Por ejemplo, la configuración RRC (AS-Config) no representaría el mapeo que aplica el UE. Esto sería indeseable en caso de movilidad, ya que el UE no se comportaría como espera el nodo objetivo. También eliminaría la posibilidad de anular un mapeo de QoS reflectante anterior mediante una configuración dedicada.

La tercera opción adolece de posibles condiciones de carrera ya que puede que no sea completamente predecible si el UE recibió primero un paquete de datos DL o la conexión/re configuración RRC. Además, al igual que la segunda opción, existen ambigüedades sobre la movilidad.

En general, pensamos que la señalización RRC siempre debe tener prioridad sobre la señalización de control L2 y L1. Esto aseguraría una división limpia y evitaría cualquier ambigüedad. Además, durante la movilidad, este principio asegura que el eNB objetivo sea consciente de todas las asignaciones de QoS de UL configuradas aplicadas por el UE. Además de eso, también permitiría al eNB mapear un flujo QoS DL en un DRB diferente al flujo QoS UL con el mismo ID.

Propuesta 10 Si el eNB configura el UE con un "filtro de flujo QoS de enlace ascendente a DRB", anula cualquier mapeo reflectante para este flujo QoS.

2.4 Mantener del mapeo de QoS durante el traspaso

En el contexto de la movilidad entre celdas, debería discutirse si el UE mantiene los filtros de QoS UL reflectantes. Como se mencionó anteriormente, el eNB objetivo no conoce los filtros de QoS reflectantes del UE de AS-Config. Se podría considerar que el eNB de origen proporciona los mapeos de QoS de UL reflectantes al eNB de destino (por ejemplo, en AS-Context). Alternativamente, el nodo de destino puede cambiar el mapeo de QoS y enviar el nuevo mapeo al UE en el comando HO (conexión/re configuración RRC). Pero consideramos que esto es innecesariamente complejo y también introduciría un riesgo de desajuste entre los estados. Parece más sencillo que el UE mantenga un mapeo de QoS de UL reflectante siempre que exista el DRB con el que está asociado, es decir, también durante la movilidad normal de RRC. El UE libera el mapeo reflectante de UL QoS cuando el eNB libera el DRB con el que está asociado el mapeo.

Propuesta 11 El UE mantiene un mapeo de QoS de UL reflectante mientras exista el DRB con el que está asociado, es decir, también durante la movilidad normal de RRC y tras el cambio de tipo de portador. El UE libera el mapeo reflectante de UL QoS cuando el eNB libera el DRB con el que está asociado el mapeo.

La nota del presidente de RAN2#98 capturó los siguientes acuerdos realizados para la QoS relacionada:

La nota del presidente de RAN2 NR Ad Hoc #2 capturó los siguientes acuerdos realizados para la QoS relacionada:

El borrador de 3GPP TS 37.324 especificó el procedimiento de transferencia de datos SDAP y el mapeo del flujo QoS a DRB (portador de radio de datos) de la siguiente manera:

5.2 Procedimientos de transferencia de datos SDAP

5.2.1 Procedimientos de transferencia de datos UL

Al recibir una SDAP SDU de la capa superior para un flujo QoS,

- si no hay un flujo QoS almacenado a la regla de mapeo de DRB para el flujo QoS:

- la entidad SDAP correlacionará la SDU del SDAP con el portador por defecto;

- de lo contrario:

- la entidad SDAP correlacionará la SDU del SDAP con el DRB de acuerdo con el flujo QoS almacenado con la regla de correlación DRB;

- si el DRB al que se asigna esta SDAP SDU está configurado por la capa superior [3] con la presencia de un encabezado SDAP,

- la entidad SDAP construirá la PDU del SDAP como se especifica en la subcláusula 6.2.2.2;

- de lo contrario:

- la entidad SDAP construirá la PDU del SDAP como se especifica en la subcláusula 6.2.2.1;

- la entidad SDAP entregará la PDU del SDAP a las capas inferiores.

5.2.2 Procedimientos de transferencia de datos DL

En la recepción de una PDU del SDAP de capas inferiores,

- si el DRB desde el que se recibe esta PDU del SDAP está configurado por la capa superior [3] con la presencia de un encabezado SDAP, la entidad SDAP deberá:

- realizar la correspondencia de flujo QoS reflectante a DRB como se especifica en el apartado 5.3.2;

- recuperar la SDU del SDAP de la PDU del SDAP como se especifica en la subcláusula 6.2.2.2;

- de lo contrario:

- recuperar la SDU del SDAP del PDU del SDAP como se especifica en la subcláusula 6.2.2.1;

- entregar la SDU del SDAP recuperada a la capa superior.

5.3 Procedimiento de mapeo de flujo QoS a DRB

5.3.1 Configuración de mapeo de flujo QoS a DRB

Cuando la capa superior [3] configura un flujo QoS UL a la regla de mapeo DRB para una entidad SDAP:

- la entidad SDAP almacenará el flujo QoS de UL a la regla de mapeo de DRB.

5.3.2 flujo QoS reflectante al mapeo DRB

Para cada paquete DL recibido del flujo QoS, el UE comprobará el encabezado SDAP para el mapeo de QoS reflectante a DRB, como sigue:

- si se promulga el flujo QoS reflectante al mapeo de DRB:

la entidad SDAP almacenará el flujo QoS al mapeo DRB del paquete DL como el flujo QoS a la regla de mapeo DRB para los paquetes UL del flujo QoS.

El documento de 3GPP R2-1704648 propuso usar una PDU de control SDAP (Unidad de datos de protocolo) para configurar el flujo QoS a la asignación de DRB de la siguiente manera:

2.1 Notificación reflectante en Uu

Por logro capturado en [1] (anexo A como referencia), la RAN puede controlar el mapeo de enlace ascendente de flujo QoS a DRB ya sea mediante mapeo reflectante o configuración explícita. Y el mapeo reflectante se logra marcando paquetes DL sobre Uu con QFI (en adelante, denominado mapeo reflectante a través de PDU de datos SDAP).

La posibilidad de admitir la reasignación de DRB-flujo QoS se planteó durante la SI sin una decisión final. El problema se analiza en nuestra contribución complementaria y proponemos que se permita la reasignación de DRB de flujo QoS para casos de no traspaso (es decir, reasignación intracelular). Luego, de acuerdo con el logro indicado anteriormente, la RAN puede controlar la reasignación de DRB de flujo QoS de enlace ascendente mediante configuración explícita o mapeo reflectante a través de la PDU de datos SDAP. Sin embargo, tome el siguiente caso de reasignación enumerado en [2] como ejemplo:

- Si un paquete de UL entrante no coincide con un "ID de flujo QoS para mapeo de DRB", el UE mapeará el paquete con el DRB por defecto de la sesión de PDU. Cuando el gNB recibe el paquete, puede decidir reasignar el flujo QoS UL a otro DRB apropiado.

Si el gNB controla la reasignación a través de una configuración explícita, se introducirán una sobrecarga de señalización de RRC adicional y un retardo adicional. Si bien si el gNB controla la reasignación a través de la PDU de datos SDAP, debe tenerse en cuenta que para UL principalmente tráfico, tal vez no haya llegada de datos DL en ese momento. Entonces, el control de la reasignación puede retrasarse hasta la llegada del primer paquete DL. El retraso impredecible puede tener un impacto negativo en la experiencia del usuario. El análisis anterior también es válido para los otros tres casos de reasignación enumerados en [2].

Para abordar el problema, un enfoque posible es introducir una PDU de control SDAP para el mapeo reflectante de enlace ascendente (en adelante, denominada PDU de control SDAP para el mapeo reflectante). Por ejemplo, si se mapea un flujo QoS a un DRB a través de la PDU de control de SDAP, la QFI del flujo QoS debe incluirse en la PDU de control de SDAP y la PDU de control de SDAP se envía a través del DRB al que se espera que el flujo QoS sea asignado.

- La PDU de control SDAP para mapeo reflectante se puede introducir además del mapeo reflectante a través de la PDU de datos SDAP: Cuando el gNB decide controlar el mapeo/reasignación de enlace ascendente de QoS Flow-DRB a través del mapeo reflectante, si no hay datos DL disponibles en ese momento, el control a través de la PDU de control SDAP o el control mediante la ^p D^u de datos SDAP o,

- La PDU de control SDAP para mapeo reflectante se puede introducir en lugar del mapeo reflectante a través de la PDU de datos SDAP: Siempre que el gNB decida controlar el mapeo/reasignación de enlace ascendente de QoS Flow-DRB a través del mapeo reflectante, control a través de la PDU de control SDAP.

Durante el estudio en SI, la mayoría de las empresas proponen desacoplar la QoS reflectante NAS y el mapeo reflectante AS. El objetivo se puede lograr con la introducción de la PDU de control SDAP que reemplaza el mapeo reflectante a través de la PDU de datos SDAP. Y si se acuerda introducir la PDU de control SDAp para mapeo reflectante, el formato de la PDU de control SDAP se puede encontrar en nuestra contribución complementaria. Observación 1. Si con la introducción de la PDU de control SDAP para reemplazar el mapeo reflectante a través de la PDU de datos SDAP, se puede lograr el objetivo de desacoplar la QoS reflectante NAS y la cartografía reflectante AS.

Con el análisis anterior, proponemos:

Propuesta1 Introducir la PDU de control SDAP para mapeo reflectante.

Propuesta 2. La PDU de control SDAP se puede introducir para reemplazar o adicional al mapeo reflectante a través de la PDU de datos SDAP.

En RAN2#97bis [3], se acuerda que:

- Los paquetes DL sobre Uu no están marcados con "ID de flujo" al menos para los casos en donde el mapeo reflectante UL AS y la QoS reflectante NAS no están configurados para DRB.

Entonces, la pregunta es ¿cuándo deben marcarse los paquetes DL sobre Uu con "ID de flujo"?

De acuerdo con el logro en SA2 [4] (Anexo B como referencia), si se usa la QoS reflectante NAS, el UE necesita confiar en los paquetes DL para derivar las reglas de QoS. La regla de QoS derivada incluye el filtro de paquetes, QFI, valor de precedencia. Entre las reglas de QoS derivadas, el filtro de paquetes y QFI solo pueden derivarse de los paquetes DL. Entonces, obviamente, el QFI también debería incluirse en los paquetes DL con el propósito de QoS reflectante NAS.

Observación 2. Los paquetes DL sobre Uu deben marcarse con QFI para el propósito de QoS reflectante NAS.

La QoS reflectante del NAS es crear una regla de QoS para un flujo QoS de enlace ascendente en el UE. Y por logro en [1], el momento para establecer los DRB no predeterminados y cómo mapear los flujos QoS a DRB depende de la decisión de RAN. En el momento de crear una regla de QoS para un flujo QoS de enlace ascendente a través de QoS reflectante NAS, lo más probable es que haya próximos paquetes de enlace ascendente para este flujo QoS específico. Si el flujo QoS no está mapeado a ningún DRB en ese momento, el mapeo reflectante AS puede usarse al mismo tiempo para mapear este flujo QoS de enlace ascendente específico a un DRB establecido. En este caso, si se sigue usando la PDU de datos SDAP para el mapeo reflectante AS, QFI debe incluirse en los paquetes DL tanto para el propósito de QoS reflectante NAS como para el mapeo reflectante AS.

Observación 3. La QoS reflectante NAS y el mapeo reflectante AS pueden tener lugar simultáneamente sobre la Uu.

Observación 4. Si sigue usando la PDU de datos SDAP con el propósito de QoS reflectante AS, los paquetes DL sobre Uu deben marcarse con QFI para el propósito de QoS reflectante NAS y/o mapeo reflectante AS.

Con la introducción de QFI en paquetes DL con el propósito de reflejar, si el UE debe monitorear "de forma continua" el QFI en paquetes DL o no, se deja abierto al final de la fase SI. Teniendo en cuenta el alto volumen de datos en NR, surge la preocupación de que se introducirá una alta sobrecarga de procesamiento así como complejidad si se requiere que el UE supervise de forma continua el ID de flujo QoS en cada paquete DL [5]. Además, como se analizó anteriormente, si se sigue usando la PDU de datos SDAP con el propósito de QoS reflectante AS, el QFI debe incluirse en los paquetes DL con el propósito de QoS reflectante ⁿA^s y mapeo reflectante AS. Entonces, si solo tiene QFI en los paquetes DL, el UE que recibe un paquete DL con QFI no puede discriminar si es para QoS reflectante NAS o mapeo reflectante AS, por lo que debe realizar ambos tipos de verificación reflectante en cualquier momento. De esta forma, se introducirá una sobrecarga de procesamiento innecesaria.

Para abordar los problemas anteriores, se deben introducir indicadores en los paquetes DL para informar a UE si el QFI está incluido en los paquetes DL o no y si es para QoS reflectante ⁿA^s y/o mapeo reflectante AS. El UE necesita realizar una verificación reflexiva solo si se indica que el QFI está incluido. Y el UE realiza una comprobación reflectante NAS y/o comprobación reflectante AS de acuerdo con las instrucciones de los indicadores. El detalle de la inclusión de los indicadores en el encabezado SDAP se discutirá en nuestra contribución complementaria [6].

Propuesta 3. Si se sigue usando la PDU de datos SDAP con el propósito de QoS reflectante AS, se deben introducir indicadores en los paquetes DL para informar si QFI está incluido o no y si es para QoS reflectante NAS y/o mapeo reflectante AS.

Para el mapeo reflectante de AS, el mapeo de flujo QoS a DRB se determina por el propio gNB, depende de gNB determinar cuándo hacer uso del mapeo reflectante de AS. Por lo tanto, el gNB sabe bien cuándo se requiere el mapeo reflectante AS y genera la p Du de control SDAP o la PDU de datos SDAP para el mapeo reflectante en consecuencia.

Mientras que para la QoS reflectante NAS, por logro en SA2 [4], la QoS reflectante se puede activar a través del plano de usuario o el plano de control a través de la indicación de QoS reflectante (RQI). Si se activa a través del plano de usuario, el RQI se incluirá en el encabezado de encapsulación de los paquetes DL en el punto de referencia N3. Con la recepción de RQI, el gNB sabe que se requiere el QoS reflectante NAS e incluye el QFI en los paquetes DL en consecuencia. Si se activa a través del plano de control, el RQI solo se indica al UE a través del punto de referencia N1 [4]. El gNB no tiene idea de cuándo incluir el QFI en los paquetes DL. Por lo tanto, se debe informar a SA2 que para el caso de QoS reflectante activada a través del plano de control, el RQI también debe ser informado al gNB, por ejemplo, a través de la señalización N2.

Propuesta 4. Informar a SA2 que el RQI debe ser informado al gNB también en caso de que la QoS reflectante se active a través del plano de control.

2.2 Precedencia del mapeo configurado por RRC y el mapeo reflectante

La precedencia del mapeo configurado por RRC y el mapeo reflectante AS aún se deja abierta ahora [1]. Durante la discusión en SI, se discute la solución del problema pero sin considerar la ocurrencia del problema en sí, es decir, en qué escenarios ocurrirá el problema. La suposición razonable es que una vez que se decida el mapeo de DRB de flujo QoS en el gNB, se mantendrá en uso sólo si se necesita reasignación de DRB de flujo QoS. En otras palabras, la cuestión de la precedencia del mapeo reflectante y configurado por RRC solo debe considerarse si se permite la reasignación del flujo QoS-DRB.

Propuesta 5. La cuestión de la precedencia del mapeo reflectante y configurado por RRC sólo debe considerarse si se permite la reasignación de flujo QoS a DRB.

El gNB decide el mapeo del flujo QoS a DRB de acuerdo con los perfiles de QoS por flujo QoS, teniendo en cuenta la condición de radio en RAN (por ejemplo, calidad del enlace de radio, condición de carga, etc.). Ni los perfiles de QoS ni las condiciones de radio en RAN cambiarán con frecuencia. Por lo tanto, se puede evitar que se lleve a cabo otra reasignación de flujo QoS a DRB inmediatamente después de la anterior. En otras palabras, prácticamente, el gNB iniciará una nueva reasignación solo después de la finalización de la reasignación anterior. Y el gNB conoce claramente el mapeo de DRB de flujo QoS más actualizado en UE. Dado lo anterior, proponemos que el UE siempre debe aplicar el mapeo más reciente, es decir, ya sea explícitamente proporcionado por RRC o derivado por mapeo reflectante.

Propuesta 6. El UE siempre debería aplicar el mapeo más reciente, es decir, ya sea explícito proporcionado por RRC o derivado por mapeo reflectante.

2.3 Manejo del mapeo del flujo QoS a DRB durante el traspaso

De acuerdo con el acuerdo en RAN2#97bis, "Lossless HO" se puede lograr si el objetivo usa la misma configuración de DRB y el mismo mapeo de DRB de flujo QoS como fuente. Por lo tanto, para el propósito de "Lossless HO", toda la información de mapeo DRB de flujo QoS en el origen debe enviarse al destino. Y el UE debe mantener todo el mapeo DRB de flujo QoS adquirido de la fuente (incluyendo tanto el mapeo configurado a través de la señalización RRC como el mapeo reflectante) durante el traspaso y la actualización de acuerdo con la decisión de destino correspondiente.

Propuesta 7. Reenviar toda la información de mapeo DRB de flujo QoS desde el origen al destino.

Propuesta 8. El UE debe mantener todo el mapeo de DRB de flujo QoS adquirido de la fuente durante el traspaso y actualizarlo de acuerdo con la decisión de destino correspondiente.

De acuerdo con 3GPP TS 23.501, el flujo QoS es generalmente la mejor granularidad de diferenciación de QoS en la sesión de PDU. La sesión de PDU proporciona una asociación entre un UE y una red de datos que proporciona un servicio de conectividad de PDU.

De acuerdo con 3GPP TS 38.300, se especifica una nueva capa AS (estrato de acceso), llamada SDAP (Protocolo de adaptación de datos de servicio), para proporcionar funciones, por ejemplo, mapeo entre un flujo QoS y un portador de radio de datos (DRB) y marcar el ID de flujo QoS (QFI) tanto en paquetes DL como en paquetes UL. Además, cada entidad SDAP está asociada con una sesión de PDU. Hay al menos un DRB (por ejemplo, DRB predeterminado) para cada sesión de PDU. Cada PDU del SDAP puede contener al menos un paquete IP. Cada PDU del SDAP puede contener un encabezado SDAP (si está configurado para UL y/o DL). El encabezado SDAP puede indicar al menos un QFI usado para identificar un flujo QoS para el que el paquete IP proviene del flujo QoS. Una PDU de SDAP podría ser una s Du de PDCP. Además, la red puede controlar el mapeo de flujo(s) de QoS a DRB en mapeo explícito RRC o mapeo reflectante.

En general, se supone que cada flujo QoS puede configurarse para usar un DRB mediante el mapeo explícito o el mapeo reflectante de RRC (Control de recursos de radio). Si un DRB (por ejemplo, DRB predeterminado o DRB no predeterminado/dedicado) sirve solo un flujo QoS UL, la red puede no configurar el DRB con la presencia de un encabezado SDAP para UL, lo que reduce la sobrecarga de señalización y ahorra recursos de radio.

La Figura 6, que es una reproducción de la Figura A.6-1 de 3GPP TS 38.300 v04.1, ilustra un escenario de flujo QoS de UL iniciado por UE. El UE inicia un nuevo flujo QoS de UL (el segundo flujo QoS de UL), por ejemplo, en base a parámetros de QoS pre configurados. Si no hay mapeo del QFI a un DRB en la tabla de mapeo AS para esta sesión de PDU, el segundo flujo QoS de UL se mapeará a un DRB predeterminado de la sesión de PDU. En caso de que ya exista un flujo QoS UL en curso (el primer flujo QoS UL) asignado a este DRB predeterminado y el DRB predeterminado no está configurado con la presencia del encabezado SDAP para UL actualmente, el gNB no conocerá del segundo flujo QoS UL cuando se reciben las PDU UL SDAP correspondientes al segundo flujo QoS UL del UE. En esta situación, la QoS objetivo del segundo flujo QoS de UL no se cumpliría porque gNB no establecería un nuevo DRB para el segundo flujo QoS ni mapearía el segundo flujo QoS a un DRB existente de acuerdo con los parámetros de QoS del segundo flujo QoS. Además, los paquetes IP incluidos en esas PDU del SDAP del segundo flujo QoS UL no serían distinguidos por la red central (por ejemplo, UPF) porque el filtro de paquetes corresponde al primer flujo QoS UL. Como resultado, los paquetes IP se descartarían, lo que provocaría la pérdida de datos y el desperdicio de recursos.

Se podrían considerar varias soluciones que se describen a continuación.

Alternativa 1: El UE indica preferencia/necesidad de presencia de encabezado SDAP

Dado que el UE sabe si un DRB debe servir a múltiples flujos QoS de UL, el UE comprende si se necesita la presencia de un encabezado SDAP en el DRB. En caso de que el UE inicie el segundo flujo QoS de UL, el UE sabe que el DRB predeterminado configurado actualmente sin presencia de encabezado SDAP servirá al primer flujo QoS de UL existente y al segundo flujo QoS de UL. En este momento, el UE podría transmitir una primera indicación al gNB para indicar que se necesita la presencia de un encabezado SDAP en el DRB predeterminado. En base a la primera indicación, el gNB re configura el DRB predeterminado con la presencia del encabezado SDAP. En caso de que el UE libere el segundo flujo QoS de UL, el UE podría transmitir una segunda indicación al gNB para indicar que la presencia del encabezado SDAP en el DRB predeterminado no es necesaria. En base a la segunda indicación, el gNB re configura el DRB predeterminado sin presencia de encabezado SDAP. La primera indicación y/o la segunda indicación podrían enviarse mediante, por ejemplo, señalización física, elemento de control de MAC, señalización PDCP (Protocolo de convergencia de datos de paquetes), señalización RRC o señalización SDAP (por ejemplo, PDU de control SDAP). La primera indicación y la segunda indicación también podrían indicar la preferencia/necesidad de presencia del encabezado SDA^p en un DRB no predeterminado (por ejemplo, un segundo DRB).

Alternativa 2: El UE proporciona información sobre el establecimiento o la liberación de un flujo QoS iniciado por UE

En caso de que el UE inicie el segundo flujo QoS de UL, el UE podría transmitir una primera información de asistencia al gNB para informar que el UE inicia el segundo flujo QoS de UL. El UE podría determinar transmitir la primera información de asistencia si sabe que el DRB predeterminado configurado actualmente sin presencia de encabezado SDAP servirá al primer flujo QoS de UL existente y al segundo flujo QoS de UL. Además, el UE podría determinar no transmitir la primera información de asistencia si sabe que el DRB predeterminado está configurada actualmente con la presencia de un encabezado SDAP. En base a la primera información de asistencia, el gNB re configura el DRB predeterminado con la presencia del encabezado SDAP.

En caso de que el UE libere el segundo flujo QoS de UL, el UE podría transmitir una segunda información de asistencia al gNB para informar que el UE libera el segundo flujo QoS de UL. El UE podría determinar transmitir la segunda información de asistencia si sabe que el DRB predeterminado configurado actualmente con la presencia del encabezado SDAP servirá solo al primer flujo QoS de Ul . Además, el UE podría determinar no transmitir la segunda información de asistencia si sabe que el DRB predeterminado configurado actualmente con la presencia del encabezado SDAP todavía está sirviendo múltiples flujos QoS de UL (por ejemplo, el primer flujo QoS de UL y un tercer flujo QoS de UL). En base a la segunda información de asistencia, el gNB re configura el DRB predeterminado sin la presencia del encabezado SDAP.

En la primera información de asistencia, se podría incluir información/regla de QoS o parámetros del segundo flujo QoS de UL. En la segunda información de asistencia, se podría incluir una identidad del segundo flujo QoS de UL (por ejemplo, QFI) o un índice de la información/regla o parámetros de QoS (informado en la primera información de asistencia). La primera información de asistencia y/o la segunda información de asistencia se podrían enviar a través de, por ejemplo, señalización física, elemento de control MAC, señalización PDCP, señalización RRC o señalización SDAP.

En base a la primera información de asistencia que indica el establecimiento del segundo flujo QoS de UL, el gNB puede (indicar al UE que) establezca un segundo DRB en el UE y configurar el UE para usar el segundo DRB para servir el segundo flujo QoS de UL. En base a la segunda información de asistencia que indica la liberación del segundo flujo QoS de UL, el gNB puede (indicar al UE que) liberar el segundo DRB usado para servir el segundo flujo QoS de UL en el UE.

Dado que el segundo flujo QoS de UL lo inicia el UE, el propio UE puede liberar el segundo flujo QoS de UL cuando no se necesita el segundo flujo QoS de UL. En caso de que el DRB predeterminado proporcione solo el primer flujo QoS de UL, el gNB puede cambiar el DRB predeterminado de una presencia de encabezado SDAP a ninguna presencia de encabezado SDAP (en base a, por ejemplo, en las alternativas anteriores). Como resultado, la presencia del encabezado SDAP en el DRB predeterminado cambiaría una y otra vez.

En general, 3GPP R2-1707160 propone cambiar la presencia del encabezado SDAP mediante un traspaso. En el traspaso, el UE restablecerá la capa MAC, restablecerá la capa PDCP y la capa RLC para todos los RB que se establecen de acuerdo con el sistema LTE heredado, como se describe en la discusión por correo electrónico 3GPP [NR-AH2#08] [NR UP] En ejecución el anexo TS 37.324 "Draft 37324-010-vl .doc". Como resultado, todos los búferes en la capa MAC y la capa RLC se vacían. Por lo tanto, el uso de un procedimiento de traspaso para cambiar la presencia del encabezado SDAP en el DRB predeterminado parece ser excesivo porque es posible que todas las PDU almacenadas en los búferes necesiten ser retransmitidas, lo que desperdicia muchos recursos de radio.

Alternativa 3: el DRB predeterminado se inicia con la presencia de OFI en el enlace ascendente

Para asegurarse de que el gNB pueda identificar un nuevo flujo QoS iniciado por un UE durante una sesión de PDU en curso, el DRB predeterminado de la sesión de PDU debe iniciarse con presencia de QFI en el enlace ascendente. El UE puede iniciar el DRB por defecto cuando recibe una configuración de DRB (por ejemplo, incluida en un mensaje de RRC) del gNB. La configuración del DRB puede incluir una configuración de QFI que indique la presencia de QFI para el DRB predeterminado. También es factible que el gNB no incluya la configuración de QFI y el UE solo aplique la presencia de QFI para el DRB predeterminado. Por consiguiente, el gNB también debería iniciar el DRB predeterminado para recibir PDU del SDAP desde el UE.

Con el QFI en una PDU del SDAP transmitido en el DRB predeterminado en el enlace ascendente, el gNB puede identificar el nuevo flujo QoS de UL para que el gNB pueda transmitir el paquete IP incluido en la PDU del SDAP a la red central (por ejemplo, UPF) a través de manejo (por ejemplo, un túnel correspondiente al nuevo flujo QoS de UL) y luego el paquete IP puede pasar el filtro de paquete correspondiente.

Más específicamente, el QFI se incluye en un encabezado SDAP de una PDU del SDAP transmitida a través del DRB predeterminado desde el UE al gNB. El encabezado SDAP contiene al menos el campo QFI. Si el encabezado SDAP contiene solo el campo QFI, el concepto podría reemplazarse ya que el DRB predeterminado se inicia con la presencia del encabezado SDAP en el enlace ascendente.

En principio, el gNB no reconfiguraría la ausencia de QFI para el DRB predeterminado si el gNB no puede asegurarse de que el UE no inicie nuevos flujos QoS. En esta situación, QFI para el DRB predeterminado siempre está presente. De lo contrario (es decir, el UE no iniciará nuevos flujos QoS nuevos), el gNB puede reconfigurar la ausencia de encabezado SDAP para el DRB predeterminado en caso de que solo se asigne un flujo QoS al DRB predeterminado.

De esta manera, las alternativas introducidas anteriormente (por ejemplo, Alternativa 1 y Alternativa 2) parecen no ser necesarias en términos de esfuerzos de protocolo y sobrecarga de señalización.

Además, la red central (por ejemplo, UPF) podría iniciar un tercer flujo QoS de UL asociado con la sesión de PDU en el UE. La red central (por ejemplo, SMF) proporciona parámetros de QoS del tercer flujo QoS de UL al gNB. En base a los parámetros de QoS del tercer flujo QoS de UL, el gNB puede establecer un DRB dedicado en el UE y configurar el UE para usar el DRB dedicado para servir el tercer flujo QoS de UL. El documento de 3GPP R2-1704648 menciona que la mayoría de las empresas proponen desacoplar la QoS reflectante NAS y el mapeo reflectante AS. Por tanto, el gNB puede configurar el UE para que sirva al tercer flujo QoS de UL mediante el uso de un mapeo reflectante.

Dado que es posible que ningún flujo QoS DL corresponda al tercer flujo QoS UL (es decir, ninguna PDU DL SDAP usa un QFI asociado con el tercer flujo QoS UL), el U^e no puede crear la regla de mapeo reflectante para el tercer flujo QoS UL, para usar el DRB predeterminado para servir el tercer flujo QoS de UL. En esta situación, el DRB predeterminado no puede satisfacer la QoS del tercer flujo QoS de UL.

En general, el documento 3GPP R2-1704648 propone usar la PDU de control SDAP para ayudar al UE a crear la regla de mapeo reflectante. Esta solución parece factible, pero genera complejidades y sobrecarga de señalización. Por ejemplo, el gNB no puede saber si el Ue recibe una p Du de control SDAP que indique el tercer flujo QoS de UL (por ejemplo, el QFI correspondiente incluido en la PDU de control SDAP) en el DRB dedicado, de modo que el gNB transmitiría la PDU de control SDAP varias veces hasta el UE transmita las PDU del SDAP de UL del tercer flujo QoS de UL en el DRB dedicado.

En su lugar, podrían usarse otras soluciones que se describen a continuación.

Alternativa 4: El perfil de QoS proporcionado a gNB indica la dirección del tráfico (por ejemplo, solo UL, solo DL o bidireccional)

Cuando un flujo QoS es iniciado por la red central (por ejemplo, SMF), la red central proporciona un perfil de QoS relacionado con el flujo QoS al gNB. En general, el perfil de QoS no considera las direcciones de tráfico, por ejemplo, UL o DL si NR sigue el concepto LTE (como se describe en el documento 3GPP TS 23.401) en donde la red central EUTRAN (por ejemplo, MME) inicia un portador EPS (Sistema de paquetes evolucionado) y una estación base EUTRAN ( por ejemplo, eNB) configura la asociación entre el portador EPS y un DRB. Si un LTE UE tiene tráfico UL que pertenece al portador EPS, usa el DRB para la transmisión del tráfico UL. Si el tráfico DL que pertenece al portador EPS llega a la estación base EUTRAⁿ , la estación base EUTRAN usa el DRB para transmitir el tráfico DL al UE LTE. En otras palabras, en LTE, el mapeo de portador de EPS a DRB para UL no depende del mapeo de portador de EPS a DRB para DL. En NR, el mapeo del flujo QoS a DRB para UL puede depender del mapeo del flujo QoS a DRB para DL. Si el mapeo del flujo QoS a DRB para DL no está disponible, no se debe usar la regla de mapeo reflectante.

Por lo tanto, el perfil de QoS debe incluir información sobre la dirección del tráfico en cada flujo QoS para que el gNB pueda saber si el mapeo del flujo QoS a DRB para DL está disponible o no. Por ejemplo, el perfil/los parámetros de QoS relacionados con el tercer flujo QoS de UL indica un QFI y tráfico en (solo) la dirección de UL. De esta manera, el gNB configura el UE para usar el DRB dedicado para proporcionar el tercer flujo QoS de UL a través del mapeo explícito de RRC. Si el perfil/los parámetros de QoS relacionados con el tercer flujo QoS de UL indica un q Fi y tráfico en la dirección de UL y DL, el gNB puede configurar el UE para usar el DRB dedicado para servir el tercer flujo QoS de UL mediante mapeo reflectante.

Alternativa 5: un flujo QoS que no debe ser atendido por el DRB predeterminado usa mapeo explícito de RRC

En general, la Alternativa 4 es factible, pero provocaría esfuerzos de protocolo en la definición de la dirección del tráfico. Otra solución podría ser que el gNB debería usar la forma explícita de RRC para configurar un flujo QoS con la asignación del flujo QoS a un DRB si el DRB es un DRB dedicado, es decir, el DRB no es un DRB predeterminado.

Dado que el gNB usa la señalización RRC para establecer un DRB dedicado para servir el tercer flujo QoS de UL, la señalización de RRC puede incluir información sobre la asignación del tercer flujo QoS de UL al DRB dedicado porque la información no causa una sobrecarga de señalización significativa.

Si el gNB configura el flujo QoS con mapeo reflectante y se usa la Alternativa 3, el gNB conocerá el tercer flujo QoS de UL usando el DRB predeterminado. Y luego el gNB transmite una señalización RRC que indica el mapeo del tercer flujo QoS de UL al DRB dedicado al UE.

De todos modos, la forma explícita de RRC se usará para el mapeo del tercer flujo QoS de UL al DRB dedicado. Por lo tanto, esta alternativa parece la más simple en términos de esfuerzos de protocolo.

La Figura 12 es un diagrama de flujo 1200 de acuerdo con una realización ilustrativa de un nodo de red. En la etapa 1205, el nodo de red transmite un primer mensaje con una configuración de DRB a un UE para establecer un ^d R^b predeterminado para una sesión de PDU, en el que la configuración de DRB incluye una configuración de QFI usada para indicar si un campo QFI está presente o no en el enlace ascendente para el DRB predeterminado y la configuración QFI siempre se establecen en un valor que indica que el campo QFI está presente en el enlace ascendente para el DRB predeterminado. Preferentemente, es posible que no se permita al nodo de red transmitir un segundo mensaje al UE para reconfigurar la configuración de QFI para el DRB predeterminado para que no haya presencia del campo QFI.

En la etapa 1210, el nodo de red establece el DRB predeterminado con la presencia del campo QFI en el enlace ascendente. Preferentemente, un encabezado en la PDU del SDAP podría incluir al menos el campo QFI.

En la etapa 1215, el nodo de red recibe una PDU del SDAP con el campo QFI a través del DRB predeterminado del UE.

Preferentemente, el nodo de red podría transmitir un paquete de IP (Protocolo de Internet) incluido en la PDU del SDAP a una red central. Además, el nodo de la red podría ser una estación base. Además, la estación base podría ser un gNB.

Con referencia de nuevo a las Figuras 3 y 4, en una realización ilustrativa de un nodo de red, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para permitir que el nodo de red (i) transmita un primer mensaje con una configuración de DRB a un UE para establecer un DRB predeterminado para una sesión de PDU, en el que la configuración de DRB incluye una configuración de QFI usada para indicar si un campo QFI está presente o no en el enlace ascendente para el DRB predeterminado y la configuración de QFI siempre se establece en un valor que indica que el campo QFI está presente en el enlace ascendente para el DRB predeterminado, (ii) para establecer el DRB predeterminado con una presencia del QFI campo en enlace ascendente, y (iii) para recibir una PDU del SDAP con el campo QFI a través del DRB predeterminado desde el UE. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones y etapas descritas anteriormente u otras descritas en la presente memoria.

La Figura 13 es un diagrama de flujo 1300 de acuerdo con un ejemplo de UE. En la etapa 1305, el UE recibe un primer mensaje con una configuración de DRB desde un nodo de red, en el que la configuración de DRB indica al UE que inicie un DRB predeterminado para una sesión de PDU y no incluye información de la configuración QFI para el DRB predeterminado en el enlace ascendente. Preferentemente, el UE puede no recibir un segundo mensaje del nodo de red para cambiar la configuración de QFI para el DRB predeterminado a ninguna presencia de QFI (es decir, QFI para el DRB predeterminado siempre está presente).

En la etapa 1310, el UE inicia el DRB predeterminado con presencia de QFI en el enlace ascendente. En la etapa 1315, el UE transmite una PDU del SDAP con un QFI a través del DRB predeterminado al nodo de red. Preferentemente, un encabezado en la PDU del SDAP podría incluir al menos un campo de QFI. Además, podría incluirse un paquete IP en la PDU del SDAP para transmitir a una red central. La red central podría ser una UPF (función de plano de usuario) o una SMF (función de gestión de sesión), como se describe en el documento 3GPP TS 23.501. El nodo de red podría ser una estación base (por ejemplo, gNB).

Con referencia de nuevo a las Figuras 3 y 4, en un ejemplo de un UE, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para permitir que el UE (i) reciba un primer mensaje con una configuración del DRB desde un nodo de red, en el que la configuración del DRB indica al UE que inicie un DRB predeterminado para una sesión de PDU y no incluye información de configuración QFI

para el DRB predeterminado en el enlace ascendente, (ii) para iniciar el DRB predeterminado con una presencia de QFI en el enlace ascendente, y (iii) para transmitir una PDU del SDAP con un QFI a través del DRB predeterminado al nodo de red. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones y etapas descritas anteriormente u otras descritas en la presente memoria.

La Figura 14 es un diagrama de flujo 1400 de acuerdo con un ejemplo de un nodo de red. En la etapa 1405, la red transmite un primer mensaje con una configuración de DRB a un UE, en el que la configuración del DRB indica al UE que inicie un DRB predeterminado para una sesión de PDU, y la configuración del DRB incluye información de una configuración de QFI para el DRB predeterminado en enlace ascendente o no incluye información de la configuración de QFI para el DRB predeterminado en el enlace ascendente.

Preferentemente, el nodo de red no puede transmitir un segundo mensaje al UE para cambiar la configuración de QFI para el DRB predeterminado a ninguna presencia de QFI (es decir, QFI para el DRB predeterminado siempre está presente). Además, es posible que el nodo de red no establezca la configuración de QFI para el DRB predeterminado en el enlace ascendente para que no haya presencia de QFI en el enlace ascendente.

En la etapa 1410, el nodo de red inicia el DRB predeterminado con presencia de QFI en el enlace ascendente.

En la etapa 1415, el nodo de red recibe una PDU del SDAP con un QFI a través del DRB predeterminado del UE. Preferentemente, un encabezado en la PDU del SDAP podría incluir al menos un campo de QFI.

Preferentemente, el nodo de red podría transmitir un paquete IP incluido en la PDU del SDAP a una red central. El nodo de red podría ser una estación base (por ejemplo, gNB). La red central podría ser una UPF o una SMF, como se describe en el documento 3GPP TS 23.501.

Con referencia de nuevo a las Figuras 3 y 4, en un ejemplo de un nodo de red, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para permitir que el nodo de red (i) transmita un primer mensaje con una configuración de DRB a un UE, donde la configuración de DRB indica al UE que inicie un DRB predeterminado para una sesión de PDU, y la configuración de DRB incluye información de una configuración QFI para el DRB predeterminado en el enlace ascendente o no incluye información de la configuración QFI para el DRB predeterminado en el enlace ascendente, (ii) para iniciar el DRB predeterminado con una presencia de QFI en el enlace ascendente y (iii) para recibir un PDU del SDAP con QFI a través del DRB predeterminado del UE. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones y etapas descritas anteriormente u otras descritas en la presente memoria.

Diversos aspectos de la divulgación se han descrito anteriormente. Debe ser evidente que las enseñanzas en la presente memoria pueden realizarse en una amplia variedad de formas y que cualquier estructura específica, función, o ambas que se divulga en la presente memoria es simplemente representativa. En base a las enseñanzas en la presente memoria un experto en la técnica debe apreciar que un aspecto divulgado en la presente memoria puede implementarse independientemente de cualesquiera otros aspectos y que dos o más de estos aspectos pueden combinarse de diversos modos. Por ejemplo, puede implementarse un aparato o puede practicarse un procedimiento mediante el uso de cualquier número de los aspectos expuestos en la presente memoria. En adición, tal aparato puede implementarse o tal procedimiento puede practicarse mediante el uso de otra estructura, funcionalidad, o estructura y funcionalidad en adición a o además de uno o más de los aspectos expuestos en la presente memoria. Como un ejemplo de algunos de los conceptos anteriores, en algunos aspectos pueden establecerse canales concurrentes en base a las frecuencias de repetición del pulso. En algunos aspectos pueden establecerse canales concurrentes en base a la posición o desplazamientos del pulso. En algunos aspectos pueden establecerse canales concurrentes en base a las secuencias de salto de tiempo. En algunos aspectos pueden establecerse canales concurrentes en base a las frecuencias de repetición del pulso, las posiciones o desplazamientos del pulso, y las secuencias de salto de tiempo.

Los expertos en la técnica entenderán que la información y las señales pueden representarse mediante el uso de cualquiera de una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, las instrucciones, los comandos, la información, las señales, los bits, los símbolos, y los chips que pueden referenciarse a lo largo de la descripción anterior pueden representarse por tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticas, campos o partículas ópticas, o cualquier combinación de los mismos.

Los expertos apreciarían además que los diversos bloques, módulos, procesadores, medios, circuitos, y etapas de algoritmos lógicos ilustrativos descritos en relación con los aspectos divulgados en la presente memoria pueden implementarse como hardware electrónico (por ejemplo, una implementación digital, una implementación analógica, o una combinación de las dos, que pueden diseñarse mediante el uso de la codificación de origen o alguna otra técnica), diversas formas de código de programa o diseño que incorporan instrucciones (que pueden referirse en la presente memoria, para conveniencia, como "software" o "módulo de software"), o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, diversos componentes, bloques, módulos, circuitos, y etapas ilustrativos se han descrito anteriormente generalmente en términos de su funcionalidad. Si tal funcionalidad se implementa como hardware o software depende de la solicitud particular y las restricciones de diseño impuestas en el sistema general. Los expertos en la técnica pueden implementar la funcionalidad descrita de diversos modos para cada solicitud particular, pero tales decisiones de implementación no deben interpretarse como que provocan una desviación del ámbito de la presente divulgación.

En adición, los diversos bloques, módulos, y circuitos lógicos ilustrativos descritos en relación con los aspectos divulgados en la presente memoria pueden implementarse dentro o realizarse por un circuito integrado ("IC"), un terminal de acceso, o un punto de acceso. El IC puede comprender un procesador de propósito general, un procesador de señal digital (DSP), un circuito integrado de aplicación específica (ASIC), una matriz de puerta programable en campo (FPGA) u otro dispositivo lógico programable, puerta discreta o lógica de transistor, componentes de hardware discretos, componentes eléctricos, componentes ópticos, componentes mecánicos, o cualquier combinación de los mismos diseñados para realizar las funciones descritas en la presente memoria, y pueden ejecutar códigos o instrucciones que se encuentran dentro del IC, fuera del IC, o ambos. Un procesador de propósito general puede ser un microprocesador, pero en la alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador, o máquina de estados convencionales. Un procesador puede implementarse además como una combinación de dispositivos informáticos, por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de dSp , o cualquier otra tal configuración.

Se entiende que cualquier orden o jerarquía específicos de las etapas en cualquier procedimiento divulgado es un ejemplo de un enfoque de muestra. En base a las preferencias de diseño, se entiende que el orden o jerarquía específicos de las etapas en los procedimientos pueden reorganizarse mientras que permanecen dentro del ámbito de la presente divulgación.

Las etapas de un procedimiento o algoritmo descritas en relación con los aspectos divulgados en la presente memoria pueden realizarse directamente en el hardware, en un módulo de software ejecutado por un procesador, o en una combinación de los dos. Un módulo de software (por ejemplo, que incluye instrucciones ejecutables y datos relacionados) y otros datos pueden encontrarse en una memoria de datos tal como la memoria RAM, la memoria flash, la memoria ROM, la memoria EPROM, la memoria EEPROM, los registros, un disco duro, un disco extraíble, un CD-ROM, o cualquier otra forma de medio de almacenamiento legible por ordenador conocido en la técnica. Puede acoplarse un medio de almacenamiento de muestra a una máquina tal como, por ejemplo, un ordenador/procesador (que puede referirse en la presente memoria, por conveniencia, como un "procesador") de manera que el procesador puede leer información (por ejemplo, el código) desde y escribir información al medio de almacenamiento. Un medio de almacenamiento de muestra puede ser integral al procesador. El procesador y el medio de almacenamiento pueden encontrarse en un ASIC. El ASIC puede encontrarse en el equipo del usuario. En la alternativa, el procesador y el medio de almacenamiento pueden encontrarse como componentes discretos en el equipo de usuario. Además, en algunos aspectos cualquier producto de programa por ordenador adecuado puede comprender un medio legible por ordenador que comprende códigos que se relacionan con uno o más de los aspectos de la divulgación. En algunos aspectos un producto de programa de ordenador puede comprender materiales de envase.

Aunque la invención se ha descrito en relación con diversos aspectos, se entenderá que la invención es capaz de modificaciones adicionales. La presente solicitud pretende cubrir cualquiera de las variaciones, usos, o adaptaciones de la invención siguiendo los principios generales de las mismas, que incluyen tales desviaciones de la presente divulgación como que están dentro de la práctica conocida o habitual en la técnica. La invención se define en las reivindicaciones independientes adjuntas.

Claims (10)

REIVINDICACIONES

1. Un procedimiento de un nodo de red, que comprende:

transmitir un primer mensaje con una configuración de portador de radio de datos, DRB, a un equipo de usuario, UE, para establecer un DRB predeterminado para una sesión de unidad de datos de protocolo, PDU, en el que la configuración del DRB incluye una configuración de ID de flujo QoS, QFI, usada indicar si un campo QFI está presente o no en el enlace ascendente para el DRB predeterminado y la configuración de QFI siempre se establece en un valor que indica que el campo QFI está presente en el enlace ascendente para el DRB predeterminado (1205);

establecer el DRB predeterminado con la presencia del campo QFI en el enlace ascendente (1210); y recibir una PDU de protocolo de adaptación de datos de servicio, SDAP, con el campo QFI a través del DRB predeterminado del UE (1215).

2. El procedimiento de la reivindicación 1, en el que al nodo de red no se le permite transmitir un segundo mensaje al UE para reconfigurar la configuración de QFI para el DRB predeterminado a la ausencia del campo QFI.

3. El procedimiento de la reivindicación 1 o 2, en el que un encabezado en la PDU del SDAP incluye al menos el campo QFI.

4. El procedimiento de una cualquiera de las reivindicaciones 1 a 3, en el que el nodo de red transmite un paquete de Protocolo de Internet, IP, incluido en la PDU del SDAP a una red central.

5. El procedimiento de una cualquiera de las reivindicaciones 1 a 4, en el que el nodo de red es una estación base o un Nodo B de próxima generación, gNB.

6. Un nodo de red, que comprende:

un circuito de control (306);

un procesador (308) instalado en el circuito de control (306); y

una memoria (310) instalada en el circuito de control (306) y acoplada operativamente al procesador (308); en el que el procesador (308) se configura para ejecutar un código de programa (312) almacenado en la memoria (310) para:

transmitir un primer mensaje con una configuración de portador de radio de datos, DRB, a un equipo de usuario, UE, para establecer un DRB predeterminado para una sesión de unidad de datos de protocolo, PDU, en el que la configuración del DRB incluye una configuración de ID de flujo QoS, QFI, usada indicar si un campo QFI está presente o no en el enlace ascendente para el DRB predeterminado y la configuración de QFI siempre se establece en un valor que indica que el campo QFI está presente en el enlace ascendente para el DRB predeterminado (1205);

establecer el DRB predeterminado con la presencia del campo QFI en el enlace ascendente (1210); y recibir una PDU de protocolo de adaptación de datos de servicio, SDAP, con el campo QFI a través del DRB predeterminado del UE (1215).

7. El nodo de red de la reivindicación 6, en el que el nodo de red no puede transmitir un segundo mensaje al UE para reconfigurar la configuración de QFI para el DRB predeterminado a la ausencia del campo QFI.

8. El nodo de red de la reivindicación 6 o 7, en el que un encabezado en la PDU del SDAP incluye al menos el campo QFI.

9. El nodo de red de una cualquiera de las reivindicaciones 6 a 8, en el que el nodo de red transmite un paquete de Protocolo de Internet, IP, incluido en la PDU del SDAP a una red central.

10. El nodo de red de una cualquiera de las reivindicaciones 6 a 9, en el que el nodo de red es una estación base o un Nodo B de próxima generación, gNB.